To fine tune and monitor the steps of querying in the DIOM environment we provide the capability for query tracing through a graphical interface. Each step of the query process can be monitored by the user.
Tracing the query is designed to show the user which repositories are being selected in the process and how the query is actually processed at each site. This can be a useful option perhaps when debugging or determining the role of a repository in answering a query. The query trace option is provided at the bottom of the expert query composition form in Figure 7.
When the query given in Figure 7 is executed with the query trace option, the first step in query tracing is query routing. The result is displayed in Figure 8, which gives a list of all repositories and highlights the repositories chosen for answering this query with the selected checkbox buttons. The user can tailor this list by adding or removing repositories to the query.
For the running example query in Figure 3, after applying query routing operations to the two IDL generalization interfaces Job and Company, the set of candidate information sources that are relevant to Job interface contains DR2, DR3, DR4, whereas the information sources that connect to the Company interface include DR6, DR7. Thus, the original IQL query is now reformulated as follows:
TARGET DR2, DR3, DR4, DR6, DR7
SELECT *
FROM Job, Company
WHERE Job->descrip contains 'multimedia'
AND (Company->country contains 'Canada' || 'USA')
AND Job->company=Company->name
Following the query routing step is the query decomposition step. A query decomposition tree (Figure 9) will be generated as the result of query decomposition, with each leaf node represents the subquery result from a single repository and the intermediate nodes represent the result of using a join or union operator on the results from the underlying connected nodes. For the query example in Figure 3, five subqueries are generated by the query decomposition step and are passed to the subsequent steps for further processing. The following is the result returned after the subquery translation step:
SubQ1: TARGET DR2
SELECT OpenJob.jobtitle, Job.start_wage, Job.description,
OpenJob.opendate
FROM Job, OpenJob
WHERE Job.description contains `multimedia' AND Job.jobtitle=OpenJob.jobtitle;
SubQ2 TARGET DR3
SELECT Positions.title, Positions.pay, Positions.description,
Positions.company
FROM Positions
WHERE Positions.description contains `multimedia';
SubQ3 TARGET DR4
SELECT JobList.position, JobList.description, JobList.organization
FROM JobList
WHERE JobList.description contains `multimedia';
SubQ2: TARGET DR6
SELECT A.name, A.street, A.city, A.state, A.country,
A.zip, B.description
FROM Business A, BusinessInterest B
WHERE A.country contains [`Canada' || `USA'] AND A.name=B.name;
SubQ5 TARGET DR7
SELECT A.name, A.address, A.city, A.province, A.country,
A.postal_code, A.homepage
FROM Companies A
WHERE A.country contain [`Canada' || `USA'];
The subquery SubQ1 and SubQ4 can be directly executed since both DR2 and DR6 are the repositories managed by a RDBMS. For the rest of the subqueries (i.e., SubQ2, SubQ3 and SubQ5), each needs to be mapped to an executable at the corresponding repository using the generic wrapper functions and the source-dependent wrapper functions (see Section 4.4 for detail).
Tracing query processing steps is also made possible through the query decomposition tree in Figure 9. For example, clicking on each leaf node will display the subquery that is to be executed at that repository and the result obtained. Clicking on the join or union operators will give the results of the operation over the data assembled from the lower connected nodes. Figure 10 an example subquery result returned from repository DR3.
Once all the subqueries are processed, the results are returned from the wrappers and assembled according to the original IQL query expression through semantic attachment operations [17,16]. Figure 11 shows a result of the initial query from Figure 7 in tabular format.