| Query language examples must query something, and so this chapter needs a sample data set. For its data, this chapter uses an object model from a gourmet potato chip company that is just starting out and has only a few customers. As Figure 15.1 shows, the package sjm.examples.chips contains the chip data as an object model. Figure 15.1. The sjm.examples.chips package. This package contains an object model of customers and their chip orders.  The ChipBase class contains a complete object model of customers and their orders for chips. Figure 15.2 shows the ChipBase static methods that return these three classes of object. Figure 15.2. The ChipBase database. This class returns a dictionary of chips keyed by chip ID, a dictionary of customers keyed by customer ID, and an unkeyed vector of orders.  ChipBase.chip() returns a dictionary of all the types of chips the company supplies . This dictionary uses the ChipID as a key, something that allows an axiom source to retrieve chips by ID. The ChipBase.customer() method returns Customer objects in a Dictionary keyed by CustomerID . The ChipBase.order() method returns Order objects as a Vector , without any key information. Figures 15.3, 15.4 and 15.5 show the object model as it would appear in a set of tables. Figure 15.3. A chip table. The types of chips a company offers.  Figure 15.4. An order table. Standing monthly customer orders for bags of chips.  Figure 15.5. A customer table. Customer ID and name .  The data in these tables is accessible through static methods on the ChipBase class. To make this data available to the logic engine in sjm.engine , you must create Fact objects from this data, load them into a Program object, and query this program. The class ChipSource in sjm.examples.query provides this service, creating a Program object with the data from the preceding figures. You can print this program with this statement: package sjm.examples.query; import sjm.engine.*; /** * This class shows the chip facts that * <code>ChipSource</code> makes available. */ public class ShowChipSource { public static void main(String[] args) { System.out.println(ChipSource.program()); } } Running this program prints the following: chip(1007, Saddle Horns, 9.95, 10.0, Sunflower); chip(1004, Jim Bob's Jumbo BBQ, 12.95, 16.0, Safflower); chip(1003, Four Corner Crispitos, 8.95, 12.0, Coconut); chip(1002, Coyote Crenellations, 9.95, 12.0, Coconut); chip(1001, Carson City Silver Dollars, 8.95, 12.0, Safflower); customer(12116, Zeldis, Kim); customer(11158, Shumacher, Carol); customer(11156, Hasskins, Hank); customer(12122, Houston, Jim); order(11156, 1001, 2); order(11156, 1004, 1); order(11158, 1007, 4); order(12116, 1002, 2); order(12116, 1003, 2); order(12122, 1004, 2); order(12122, 1007, 2); 15.2.1 Facts, Objects, and Rows Converting objects into facts falls under the topic of object/relational mapping. One object in an object model usually represents one object in a problem domain, such as a machine or a customer. A logic program models the domain object as one fact, and a relational database models the domain object as one row in a database table. Java objects that represent domain objects are objects of the same class; all the rows of a relational table are, of course, members of the same table. Java instances are tightly bound to Java classes, and relational table rows are tightly bound to tables. The affiliation of facts in a program to related facts is much looser. The role of a Java class or relational table appears in a logic program as the collection of structures in a logic program that have the same functor and the same number of terms. The number of terms in a structure is its arity. Figure 15.6 shows the correspondences of modeling elements in Java, relational databases, and logic programming. Figure 15.6. Modeling correspondences. The fields of object-oriented programming, relational programming, and logic programming use different words for similar concepts.  Here is one fact from the chip data source: chip(1004, "Jim Bob's Jumbo BBQ", 12.95, 16, "Safflower") You could model this information as any of the following: Java as well as relational databases give names and types to object attributes. Logic engines such as the one in sjm.engine are much more lax in how they define object attributes. A logic engine relies on all facts with the functor chip and arity 5 having their attributes in the same position. A logic engine query for a type of chip matches a query with functor chip and arity 5 against all facts with this same functor and arity. We return to the topic of issuing queries in Section 15.5, "Translating User Queries to Engine Queries," after a look at Jaql. |
