The EDM provides information that maps between the First Order Logic representation (obtained from the Property-theoretic representations that are produced by the parser) and the database specific Untyped Relational Calculus. This is the first step towards producing a database-specific SQL query. Formally, this information is represented as a set of equivalences of the form
where is a predicate in the first order logic, and are individual variables, and is any URC sentence.
In the program itself, the mapping rules are of the form used in the following extract:
name(X) <=> [X,*,*,*,*,*,*,*,*,*,*,*]:student. name(X) <=> [X,*,*,*,*,*,*]:staff. ... teach(X,Y) <=> exists(ab,[X,*,*,*,*,*,ab]:staff & [ab,Y]:staff_assign). teach(X,Y) <=> exists(ab,[X,*,*,*,*,*,ab]:staff & exists(ac,[Y,*,ac,*,*,*,*,*,*,*,*,*]:student & exists(bc,[ab,bc]:staff_assign & [ac,bc]:stud_course ))).
As can be seen, the mapping allows for lexical ambiquity with respect to the domain of the database.
The meaning ascribed to the variables on the right-hand-side depends upon the attribute that that position in the table stands for, as defined in the data model. It might be more appropriate to be able to define this in terms of the attribute directly, and then produce the appropriate Untyped Relational Calculus expression from this. Some of the interpretations of questions will require that a variable belongs to more than one domain as specified in the data model. This is non-sensical, and is ruled out.