Download (direct link):
Desc is qual(Y, Quail [Y] & Qual2[Y]).
Notice that the sentence:
“Who was 54 and who stood at Worthing?” has a different meaning, and a different interpretation:
Desc is qual(Yl, Quall[Y 1]) & Desc is qual(Y2, Qual2[Y2])
3 DATA MODELLING
The queiy language D&Qs is a domain calculus. This means that each vaiiable langes over the domain of values associated with an attribute. Each D&Qs constant represents an attribute value.
The inteipietation of a noun phrase may be, for example, a simple DESCRIPTION ‘Const’
oi a compound DESCRIPTION ‘Det-N-qual(X,Qual)’
In both examples the tefeience of the noun phiase is a gioup of values (a singleton containing the reference of ‘Const’ in the first case and, in the second, N values which satisfy ‘Qual’),
The interpretation of a noun phiase is theiefoie constiained to be a group of values, or a domain variable and a lule. It cannot refer to a whole tuple fiom a relation. Howevei, it will geneially be the case that natural language nouns do refer to some of the relations in a database In the ‘election’ database of the appendix, for example, the words ‘election’, ‘constituency’, and ‘person’ all lefei to relations. (‘Candidate’ on the other hand could simply refer to values of the ‘candidate’ attribute in the relation of that name.)
To enable such relations to be referred to, the QPROC data model is extended to include an identifying attribute for these relations. Any reference to the relation is interpreted as a reference to its identifying attribute. A relation with such an identifying attribute is termed an entityf relation. The domain over which its identifying attribute is defined is termed the entity domain. The introduction of entities to the relational model has been frequently suggested and implemented and it is justified by many reasons besides the above, A good explanation is in .
Having introduced entities, we can put them immediately to another use in the interpretation of “implicit joins”. An implicit join is required when two relations are used in a query with no mention of how they constrain each other. An example from the election application is
“the candidates in the election of what date?”
•f Note that no formal definition of ‘entity’ has been established. The current definition is theiefoie specific to QPROC
election id constituency date
candidate candidate party election vote
These two relations must be joined somehow to answer the query. QPROC’s rule for such implicit joins is that one of the relations, (Relationl), must be an entity, and its identifying attribute (‘Id’) must range over the same domain as some attribute, Att, of the other relation (Relation2)„ The constraint which holds between the two relations is that
Relationl.Id = Relation2.Att
3.2 Domain hierarchies
Another extension to the relational data model is imposed by the necessity to deal with hyponymy (see Chapter 2, section 4,2) Particularly important words in this context are interrogative pronouns such as “who”, “where”, “when”, etc These words map down onto more specific expressions on specific occasions. Thus in the query to the election database “Where did Smith stand?”, the specific meaning is “In which constituency did Smith stand?”
To deal with such words QPROC admits a hierarchy of domains, at the bottom of which are the actual database domains. The top of the hierarchy includes domains such as ‘location’ which are independent of any particular database. For each new database the built-in domains, such as ‘location’, are combined with the database domains (such as ‘constituency’) into a hierarchy. Two domains “match” if they are on the same branch of the hierarchy. The word “where” maps onto
If ‘location’ matches ‘consistency’ then “where” is interpeted as a hyponym of “which constituency”. The use of “matching” is described in section 4.3.3 below.
In QPROC the built-in domains are ‘thing’, ‘measure’, ‘location’, ‘date’, ‘person’. Two of these are also domain names in the election database, and so the hierarchy for that database is as shown in Fig. 5.13.
Fig, 5,13 — The domain hierarchy for the election database
3.3 Base and derived relations
The third extension to the relational model is the distinction between base and derived relations. The derived relations aie those that are introduced purely to support specific natural language words or expressions. Such relations cannot be employed in the interpretation of any query which does not specifically use the word or expression. The base relations are the normalised relations explicitly stored in the database.
We should perhaps mention that third normal form for the base relations is required to underlie QPROC just like formal query languages. If, for example, the election database had all the personal details in the candidate relation shown in Fig. 5.14, then queries like “Count the people with title ‘Prof’ ” would yield
candidate election name title