Internal and External Matchings

There are three more issues here:

• the name of the Jelly View has to be stated for each decomposed Prolog program,
• the Jelly View has to have a description of its parameters in terms of database: column names and their data types,
• the Prolog program needs to have access to relations in the database which provide extensional knowledge.

The first two items are covered by so-called the External Matching. The third one is covered by the Internal Matching.

The External Matching provides relationships between the Jelly View name, its parameters in terms of database, and the program. The Internal Matching provides relationships between predicates used by the program, and the relations. The inference engine becomes a data source for the database by the External Matching, and the database becomes a data source for the inference engine by the Internal Matching. The ERD from Figure 8.1 should be extended with the Matchings. The program part remains the same. The extended ERD is given in Figure 8.3.

Figure 8.3: External Matching, Internal Matching and Logic Program, Entity Relationship Diagram.

The following description concerns External Matching section in Figure 8.3. Comparing Figure 8.1 with Figure 8.3, program is changed to table-predicate to indicate its purpose better. It establishes a relationship between the database and the inference engine. A name of the Jelly View is listed as table-predicate.table. In order to generate the data, an appropriate goal will be called which is a predicate name in table-predicate.predicate. The number of arguments of the Jelly View matches the arity of goal, which is (N). The column names and their data types are provided by tp-argument relation.

The following description concerns Internal Matching section in Figure 8.3. The Internal Matching provides access to the database from the inference engine. It maps database relations into Prolog predicates. The mapping is provided by predicate-table relation. If there is a need to access a relation, then its name is listed in predicate-table.table and a corresponding predicate name is listed as predicate-table.predicate. The inference engine gets access to the relation using the predicate name. The arity of the predicate is indicated as predicate-table.arity, which is also the number of columns in the relation.

The program is binded to the Jelly View by consist_of relationship. Each program has some number of internal matching mappings, which are provided by has relationship between table-predicate and predicate-table. In this way, clauses and predicate-to-table mappings can be reused in different programs. Two or more programs can share some of the clauses and some of the Internal Matching mappings.

The detailed course of action, when a user query is issued, is listed below.

1. The user issues a SQL query.
2. The query is preprocessed in order to check if it refers to a Jelly View.
3. If the query refers to a Jelly View, which means that there is a tuple in table-predicate matching the Jelly View name and arity, then:
   1. Assemble the program using table-predicate, clause, argument, and logical operator entities.
   2. Provide the predicate-relation mappings for the current program, listed in predicate-table entity to the inference engine.
   3. Launch the inference engine, and generate the state of the Jelly View, appropriate column names and data types of the view are provided by tp-argument.
4. Process the query, and return the reply to the user.