background image
BNL) or Cognitive Metaphors (applying the Navigational Approach) to express the queries.The
Query Interface Generator dynamically builds the query interface using the Concept Trees, pro-
viding the user with the mechanisms to express conditions over attributes and to navigate through
the Concept Tree to choose the attributes in which the user is interested.
Basically, it takes as its first input the root concept of the Concept Tree previously selected by
the user, and operates according to the concept chosen. If the concept has a specialization (an "is-
a" relationship), the appropriate procedure allows the user to choose one of its specializations or
work with the general concept without considering its specializations.The query interface gen-
erated to perform this selection is based on a sentence in BNL or, if it exists, on the Cognitive
Metaphor associated to the "is-a" relationship. If the relationship is a Description relationship (has),
it offers the user the possibility of considering as many attributes and subconcepts as the user
wants, thus going down the Concept Tree. Again the interface is generated by using a sentence
in BNL or the cognitive metaphor associated to the "has" relationship.
Finally, the Query Interface Generator permits us to establish restrictions on the chosen attrib-
utes.To do this, the Query Interface Generator shows the user the Bounded Natural Language
or the Cognitive Metaphor associated to these attributes in the concept tree.
Query Builder and Distributor
As the user is expressing the query by navigating through the concepts on the Concept Tree,
the query is internally stored as an XML document. Depending on the concepts considered, the
query can be sent to all the Wrappers or only to one of them. In the example that follows, the
whole XML query will be sent to the Wrappers of all the databases in the federation because all
databases are involved. If the user had chosen "Emblem Book" in the first step, the query would
consider only concepts in the Emblem Book subtree and that query would be sent only to the
Emblem Book database.An example of an XML query is shown in illustration 4: table column (a).
Query Translator
XML queries must be translated into the language of each database (in our case, all of them
use SQL).To carry out this task, the Query Translators read the XML query and take, for each
concept or attribute, the fragment of the SQL statement (stored in the associated Mapping Tree)
needed to translate the condition for that concept or attribute.
Recall that illustration 3 shows a fragment of the Mapping Tree for the Emblem Book data-
base, which will be used to translate the XML query shown in illustration 4: table column (a).
There, the
tag can be distinguished for the attribute "Title." Notice that each mapping
is made up of three other elements named by
, and
tags.These elements
contain the fragments to be added to the corresponding part of the final SQL statement.
Different degrees of gray in illustration 4 depict the process followed by the Query Translator
of the Emblem Book Query System to build the final SQL statement. Each degree indicates a
fragment of XML and its corresponding SQL.
Illustration 5 shows the final SQL Early Spanish Press database.The process of building these
two SQL queries is similar to the one for Emblem Literature database. Since the Spanish Press
database is managed by Oracle 9i,
which has text retrieval capabilities, the SQL query includes
a "Contains" clause.This clause is offered by the Oracle interMedia package included in the Ora-
cle software since version 8i and allows for different types of text retrieval searches.
Oracle Corporation, http://www.
DC_Emblemsbook_180204 19.02.2004 11:26 Uhr Seite 103