Representing generalizations and exceptions in expert database systems

29

Representing Generalizations and Exceptions in Expert Database Systems

Richard G. RAMIREZ Decision and Information Systems, Arizona State University, Tempe, AZ 85287, USA

Ronald DATI'ERO Quantitative Business Analysis, Louisiana State University, Ba- ton Rouge, LA 70803, USA

Joobin CHOOBINEH Business Analysis and Research, Texas A & M University, College Station, TX 77843, USA

To further increase the decision support capabilities of database management systems, previous research has suggested the development of expert database systems by coupling expert systems to database management systems. One approach is to combine the capabilities of logic systems and relational databases. Logic allows the specification of general rules representing abstract knowledge, while database management systems provide efficient management of large masses of data representing specific facts. In many practical situations, general rules cannot or are not intended to describe every possible case, thus leading to the necessity of representing exceptions. A classification of exceptions is made in this paper, and their representation in expert database systems that combine logic and relational databases is discussed. In addition, a description is made of extensions needed to the relational language SQL to permit the specification of rules that allow exceptions.

1. Introduction

Combining database and knowledge base concepts can produce an expert database system - "'a database system, specifically a relational database system, to which a body of apphcation-specific expertise is appended" [13], or as defined in [26]: "a system for developing applications requiring knowledge-directed processing of shared information". Smith [26] claims that "the majority of the applications where a DBMS is currently used to- day would benefit from such a tool". A number of systems have been proposed that interface some common tool of expert systems (usually logic) to a database system (usually a relational database) resulting in systems such as KM-1 [12] and PRO- SQL [5].

Adding logic capabilities to a database system provides an efficient way of dealings with facts and general rules (about the facts). General rules are a powerful modeling tool to represent knowledge at a high level 6f abstraction, as opposed to data representing specific facts that is handled by

Keywords: Expert Database Systems, Exceptions, Generaliza- tion Rules, Derived Relations, Views, Relational Databases.

Ronald Dattero is a visiting professor at Louisiana State University. Previ- ously, he was on the faculty of Texas A & M University. He received his B.A. from Wayne State University, his M.S. from the University of California- Berkeley, and his Ph.D. from Purdue University. His research interests include artificial intelligence, database management , decision support systems, expert systems, and management science. He is a member of AAAI, DSI, liE, ORSA, and TIMS.

North-Holland Decision Support Systems 6 (1990) 29-44

, ~ ~ . k

Joobin Choobineh received the Ph.D. degree in management information sys tems from the Univers i ty of Arizona, Tucson, in 1985. He is an assistant professor of Information Systems in the Depar tment of Busi- ness Analysis and Research at Texas A & M University. His research interests are in the areas of database design, semantic data modeling, expert database systems, and applications of artificial intelligence to business problems. Dr. Choobineh is a member of

the Association for Comput ing Machinery and the IEEE Com- puter Society.

Richard G. Ramirez"s research interests focus on the interaction of databases, decision support systems, and artificial intelligence. Currently, an Ass is tan t Professor of Compu te r Information systems at Arizona State University, he graduated from Texas A & M University.

0167-9236/90/$3.50 © 1990, Elsevier Science Publishers B.V. (North-Holland)

30 R.G. Ramirez et aL / Generalizations and exceptions in expert database systems

conventional database systems. "Rules are easier to input, occupy less space, and are easier to change" [14]. Generalizations are found in many situations and reflect prescriptive knowledge (such as minimum admission requirements for students) as well as knowledge learned inductively from examples or experience (such as criteria for dis- ease recognition). The issue of interest in this paper is the representation of the knowledge that is expressed in the form of simple facts and general rules about those facts.

A general rule serves two purposes depending on whether it is used independently or in conjunc- tion with specific data. Consider for example the rule "all first-year Ph.D. students must take the Research Seminar". This rule, so stated and without mention of any names, is an abstract statement defining a departmental policy. The rule can, however, also serve as a procedure that can be applied to the list of students currently enrolled to obtain the names of the students who will take the Research Seminar.

Exceptions are present in almost any generalization since it is "often neither feasible to antic- ipate, nor desirable to capture all possible situations in the world" [3], and even if it were possible to capture complete information about a situation, it is unlikely that it would remain valid for a long time as the world changes rapidly [24]. Exceptions do not necessarily invalidate the rule but rather complement it with the special cases not antic- ipated by the rule. Reiter [21,22], for example, in discussing default reasoning, has noted that most of what we know about the world is "a lmost always" true and has given the classical example of penguins and birds, saying that although penguins are birds that don ' t fly, we still want it true of birds " in general" that they fly. In our example, there will be some PhD students that may not enroll in the Research Seminar in their first year or there may be a few exceptional MS students that will get special permission to enroll in this course. These "exceptional" students do not cause the rule to be considered invalid in the future, nor make a change in curriculum necessary, as there is a common understanding that the large majority of students will follow it. Modifying the rule to allow for all possible causes of exception would be impractical (perhaps impossible or requiring constant updates) and would obscure the reason for such rule.

The next section presents definitions of general rules and exceptions. Section 3 discusses their representations in expert database systems combining logic and relational databases. Section 4 discusses representative systems that integrate logic and relational databases and could be used to implement exceptions to rules. Section 5 intro- duces extensions to the SQL language to support rules and exceptions. The last section concludes the paper.

2. General Rules and Exceptions

Intuitively, a general rule is a statement that describes common features of individuals in a group. In Artificial Intelligence, a general rule is often found in learning [7] where the interest is to look at a group of objects in order to generalize (learn) something about them, and in default or non-monotonic reasoning, where a general statement is true in the absence of specific information against it [21]. Using different words, a general rule is a statement (a predicate) that is true for all (or most) of the individuals in a group.

It is customary to differentiate between two kinds of generalized statements: those about simple facts (classification or token-type relationship) and those about classes of objects (generalization or type-type relationship) [28]. As indicated be- fore, this paper centers on general rules about simple facts (and exceptions to those rules). Accordingly, we use the following definition.

Definition. Given a set P, R is a classification rule if R is a predicate such that for some elements of P, R evaluates to true.

Usually the classification rule R is not defined over the set P but on a superset S that includes P as a subset. Intuitively, this happens because P is a (often implicit) sample of a larger population.

Intuitively we know that few, if any, rules of practical significance can describe a population in such a way that every individual in the population satisfies the rule and those individuals outside the population do not satisfy it. In other words, we expect "exceptions" to occur to for a given rule.

A "good" general rule is a predicate that evaluates to true for most of the elements in that group, while a " b a d " general rule will be true only for some of those individuals. The idea of a clas-

R.G. Rarairez et aL / Generalizations and exceptions in expert database systems 31

sification rule is to describe a set P (a subset of S), but it is actually defining another set, com- posed of those elements in S which satisfy the rule. Following the standard terminology in databases, we will refer to this set as a "v iew" (i.e., a derived relation) and will provide the following definition:

Definition. Given a set S and a classification rule R, a view V on S is the subset of S for which R evaluates to true.

Fig. 1 shows the relationship of the sets S, P and V. Note that for a "good" classification rule, the sets V and P are identical or very dose, and there are few or no exceptions at all.

A classification rule allows the description of the set P in a concise form without having to list explicitly each element in P. However, as can be seen in fig. 1, the rule defines a set V that does not match exactly the set P that the rule attempts to describe. Therefore, in order to fully describe P it is necessary to give the "rule plus the exceptions to the rule", i.e., the rule plus an explicit listing of elements that should be omitted or added to the view defined by the rule. We will give the following definitions for exceptions:

Definition. Given a set S, a subset P of S, and a classification rule R, the set I of internal inclusions is the set of elements in P that do not satisfy the rule R.

Definition. Given a set S, a subset P of S, and a classification rule R, the set O of omissions is the set of elements in S - P (S difference P ) that satisfy the rule R.

The sets 1 and O are collectively called exceptions. The sets of exceptions are shown in fig. 2. In

$

Fig. 1. The population P and the set V are not exactly the same.

O

Fig. 2. The exceptions 1 and O correspond to the differences between P and II.

standard set notation, the relationship between the sets can be seen in the following notation: Given a set S and a rule R,

P c S ,

I = ( i l l , P , R( i ) --false),

o = ( o l o ~ ( s - e), R(o) = true},

V= { o I o ~ S , R ( v ) = t r u e } ,

D = V + I - O = P .

Using the sets of exceptions, the set P can be constructed by using the view V modified by the exceptions, and we will refer to this reconstructed set P as a derived relation with exceptions (DRE), defined as follows:

Definition. Given a set S, a subset P of S, a classification rule R on P, a view V on P, and sets of exceptions I and O (inclusions and omissions), a derived relation with exceptions D (DRE) is the set formed by V + I - O (V union I difference O).

The sets P and D (the DRE) are equivalent according to these definitions. However, there are assigned different interpretations. The set P is considered to be the population that the general rule attempts to describe. The D R E is considered the result of a (syntactical) manipulat ion of some sets regardless of meaning (see [19] for a discus- sion of interpretations). The distinction becomes important when the sets and operations are represented on a computer and the correspondence between the objects stored in the computer (char- acter strings, records) and their original meaning (employees, parts) must be made by the user (or perhaps the user's programs).

32 R.G. Rarairez et al. / Generalizations and exceptions in expert database systems

3 . C l a s s i f i c a t i o n R u l e s a n d E x p e r t D a t a b a s e S y s -

t e m s

The definition of classification rules does not specify an implementation vehicle. In this paper, we are concerned with expert database systems that are based on logic and relational databases. Logic is a natural choice for the representation of classification rules because they correspond naturally to predicates and because logic provides inferencing mechanisms from which statements can be combined and further knowledge obtained. Re- lational databases have a close relationship to logic [11] and represent the state of the art in commercial database systems. The combination of both has been discussed in many papers (see for example [4], [11], and [12]), as well as in the Japanese 5th Generation Project [10,17]. There- fore, in this section only a brief review of the relative strengths of both logic and relational databases is given to later focus on the specific issues associated with the representation of classification rules as well as the respective advantages and disadvantages of the available options.

3.1. Logic and databases

The strengths of logic for knowledge representation have been discussed in many places. Reiter [23] has given the following summary: - logic uses a simple notation and has a well

defined semantics, - conceptual economy - each fact or deduction

rule is represented once, independently of its different uses,

- representational uniformity - facts, hypotheses, implications, queries and views are all expressed in the same language,

- operational uniformity - proof theory is the sole mechanism for query evaluation,

- generality of inference and proof procedures - new facts can be deduced using the inference and proof procedures.

On the other hand, database management systems (DBMSs) provide a number of facilities that are absent in logic and logic programming. Brodie and Jarke [4] discuss the following advantages of DBMSs over current implementations of PRO- LOG, the most popular implementation of logic programming.

- efficient access to large fact bases, - multiple users using the database concurrently, - multiple views of the data, - database structure - efficient management and

programming of large databases benefits from structuring,

- set oriented optimization with management of permanent access paths (such as indexes),

- d a t a management, including recovery and security,

- transactions.

Broadly speaking, logic systems provide powerful representation and inference mechanisms, while DBMSs provide efficient handling of large databases, constraint checking, and data management facilities. An ideal system would integrate the advantages of logic and database systems. Such is the premise for the Japanese Fifth Generation Computer Systems Project [17], but although it is possible to build systems that interface a logic systems and a relational database system (see, for example, [11], [12], [5]), a number of issues (such as query optimization, integrity constraints, and distribution of inference) are yet to be solved for an efficient partitioning of tasks among the two systems. A survey of these issues can be found in [4].

3.2. Representing Classification Rules in Logic and Database Systems

In the remainder of this section the specific problem of implementing classification rules and their associated populations will be discussed. From section 2, it can be recalled that there are three basic elements to be represented explicitly: (a) the classification rule R, (b) the source population S, on which the rule R is applied, and (c) the exceptions, inclusions ( I ) and omissions (O), to the rule. The view V and the population P do not need to be explicitly represented because they can be generated from the population S using the classification rule. In logic, V and P can be generated using the inference or proof mechanism, while in relational databases, they can be generated using the "view" mechanism. An example using PROLOG is given in the appendix, and section 5 shows the implementation using extension to the SQL database language.

R.G. Ramirez et al. / Generalizations and exceptions in expert database systems 33

If we assume that a system combining logic and relational databases (such as KM-1 [12] or PRO- SQL [5]) can be used, the following options are then available to represent classification rules and facts:

1. Storing the classification rule, the exceptions and the population S in the logic subsystem, i.e., no DBMS is used.

2. Storing the classification rule and the exceptions in the logic subsystem, and the population S in the DBMS. The logic subsystem processes exceptions and requests the original data from the DBMS to generate the view and the derived relation with exceptions.

3. Storing the classification rule in the logic subsystem, and the population S and the exceptions in the DBMS. The derived relation with exceptions is formed by the logic subsystem using the rule and requesting the data from the DBMS.

4. Storing the classification rule, exceptions and original facts in the DBMS. The DBMS processes exceptions and original facts and makes available the derived relation with exceptions.

Other options to store rules, exceptions and the population S may exist, such as storing the classification rule in the DBMS, and exceptions and population S in the logic subsystem, but they are either infeasible or impractical. Hence, only the above four options will be discussed.

The four options can be analyzed using several criteria. We are concerned with the following:

- representation - ease and naturalness of representation,

- inference - how the generation of V and D is made, and how classification rules are combined,

- efficiency - how fast the generation of V and D is made as well as the ability to handle large populations,

- integrity - how the data can be prevented from corruption by invalid or conflicting data,

- data management - security and concurrency.

3.3. Alternative 1: Storing All Information in the Logic System

A first approach to supporting classification rules in expert database systems is to store both

rules and data exclusively in the logic system. A logic programming language such as PROLOG allows the representation of the rules directly (as clauses or logic statements), and also the representation of simple facts as assertions.

From a representation viewpoint, this alternative is the best as rules and facts are represented directly in the same uniform language. From an inference viewpoint, this alternative is also the most complete; logic provides a well defined inference mechanism that can be used to generate the derived sets as well as to combine several rules to provide further deduction capabilities. Further- more, the inference mechanism allows recursion. From an efficiency viewpoint, however, this alternative cannot access large databases as efficiency as a DBMS, and from a data management viewpoint, this alternative lacks the built-in features of a DBMS for integrity and security; there is also no (automatic) way of verifying contradictory or invalid exceptions as current implementations of logic programming do not support automatic integrity constraint checking. A contradictory exception occurs when a fact is considered simulta- neously as an inclusion and an exception, or when a inclusion or omission refers to a fact not in the population S. In addition most logic programming implementations only allow a single user, rather than multi-user concurrent access.

3.4. Alternative 2: Storing Rules and Exceptions in the Logic System

Under this alternative, the DBMS is left to manage the (presumably large) collection of data representing the original population S. The logic system stores the classification rule and the exceptions to the rule. The logic system is also responsible for the generation of the derived populations V and P.

From a representation viewpoint, this is still a very good alternative, similar to Alternative 1. The rule is naturally represented in logic, while the basic facts are represented as tuples in the relational database. From an inference viewpoint, this alternative offers the same advantages as Alterna- tive 1. From an efficiency viewpoint, this alternative offers the added advantage over Alternative 1 of handling the (large) number of facts through a relational database. The handling of these facts is more efficient and accessible to several simulta-

34 IL G. Ramirez et al. / Generalizations and exceptions in expert database systems

neous users. Alternative 2 does, however, adds to the efficiency problems of Alternative 1 the over- head caused by the communication between the logic and the database systems, as the inference mechanism is retained by the logic system. From the viewpoints of integrity and data management, Alternative 2 is an improvement over Alternative 1 with respect to population S. No such improvement exists over exceptions and there is also no (automatic) way of verifying contradictory or invalid exceptions.

This alternative seems convenient when a relational system is already managing a database, inference capabilities need to be added on top of the system, and the exceptions do not interfere with the programs using the database.

3.5. Alternative 3: Storing only the Rule in the Logic System

Alternative 3 goes a step beyond the previous alternative in that exceptions are considered basic data and are stored in the database together with the original population. This allows the building of a system where all simple facts are managed by the DBMS, while rules representing abstract and more generally information are handled by the logic system. The DBMS is now able, by using integrity constraint checking, of supplying some verification against contradictory exceptions.

From a representation viewpoint, this alternative is still convenient; the logic system allows easy representation of the rule and the DBMS easily represents simple facts. From an inference viewpoint, this alternative is similar to alternatives 1 and 2; the logic system is still responsible for forming the sets V and D and combining the classification rule with other logic statements. From an efficiency viewpoint, this alternative offers an inca'eased potential for efficiency as all data handling is done by the DBMS. There are some efficiency problems because the logic subsystem uses its inference mechanism to generate the DRE. From the integrity and data management viewpoints, this alternative is an improvement over the previous alternatives. The DBMS, by using integrity constraint checking (either automatically or incorporated to update programs) is able to verify for contradictory exceptions.

This alternative differs from the previous alternatives in that exceptions (as well as the original population S) are stored in the DBMS. The logic system stores the classification rule and is responsible for the generation of the derived populations. Presumably, thi s option allows the representation of all abstract (data independent) knowledge in the logic system, while keeping all specific data in the DBMS.

3.6. Alternative 4: Storing All Information in a Database System

Under this alternative, the classification rule, the exceptions and the original population are all stored by the DBMS. The DBMS is also responsible for the generation of the derived relations.

From a representation viewpoint, this alternative is not the most effective. In contrast to logic and logic programming, a classification rule must be represented as a view using view definition statements of languages such as SQL or QUEL. From an inference viewpoint, there is a decrease in capability (in terms of the current state of the art DBMSs). First, a DBMS is typically not able to express recursive classification rules, and, second, the classification rule (now a view definition) cannot be automatically combined with other logic statements to provide more inference. On the other hand, from an efficiency viewpoint there is a net gain, as queries are answered and the view and the DRE are formed using only the DBMS query answering mechanisms with the full benefit of query optimization and set-oriented operations. From the integrity and data management viewpoints, this is also the best alternative. The DBMS can verify against contradictory exceptions and there is only one deposit of data (the database).

This alternative seems the most convenient when limited inference capability is all that is needed a n d / o r there are large masses of data to be handled. Among the advantages are that most classification rules can be represented and the highest efficiency is obtained. There is also no need for an additional system other than the DBMS and therefore only one user interface needs to be supported. All the advantages of having a DBMS are retained such as concurrent access, security, and a variety of programming languages.

R.G. Ramirez et al. / Generalizations and *xceptions in expert database systems 35

4. Available Implementation Alternatives

In this section we study the systems that have been proposed or are available in the market for the development of systems using logic and relational databases. Subsection 4.1 describes systems that interface a logic programming language with a DBMS. Subsection 4.2 describes some systems that extend logic programming systems with data management capabilities, while subsection 4.3 describes systems that extend DBMSs with logic capabilities. Our purpose is to describe representative systems rather than making an extensive survey. A brief description of the advantages and disadvantages of these types of systems in general has been made in sections 2 and 3 of this paper and a more detailed analysis can be found in [4].

4.1. Systems Interfacing Logic and Relational Databases

These systems are characterized by having two independent systems that are linked together through some interface. Typically the logic system controls all operations and uses a relational DBMS as a backend. The logic system issues requests for data from the DBMS as needed by the deductive process. The two systems can be linked or coupled in a tight or loose way [30]. In a tight coupling, the logic systems issues requests for DBMS data as needed in the deductive process. In a loose coupling, the logic system requests for da.ta are executed once for each query or deductive plan.

What is perhaps the simplest link between a logic system and a DBMS is exemplified by the mechanism to link mic ro -PROLOG [15] and dBase II developed by Berghel [2]. This mechanism re- quires the conversion of dBase II files to micro- P R O L O G "programs" that are then read by a P R O L O G program and incorporated into the program's working memory. The conversion is executed as an additional step and does not involve modification of either mic ro-PROLOG or dBase II.

A step further are systems such as PROSQL, developed by Chang and Walker [5]. PROSQL links a P R O L O G interpreter with the S Q L / D S database management system. The P R O L O G program uses function calls to retrieve data from the DBMS. The function calls are similar to em- bedded SQL calls [8] except that PROSQL is able

to read an entire relation (the result of a SQL SELECT query) into the P R O L O G program's working memory as a collection of predicates.

Kellogg [12] has developed KM-1, a system using a logic-based deductive processor linked to a relational database machine. KM-1 runs on a Xerox 1100 Lisp machine and accesses an internal database as well as an external database system running on a Britton-Lee database machine. Rela- tions are categorized according to their type: "deduce", "search" or "computed" . Search relations are stored in one of the database systems, deduce relations are obtained through the logic system using other relations, and compute relations provide for arithmetic and other computations. A "deductive plan" is formulated for each query that contains the relations and operations necessary to answer the query. The database is accessed obtain the search relations needed only once per deductive plan and thus KM-1 is a loosely coupled system.

A hybrid system is exemplified by Arity Corpo- ration's SQL Development Package [1]. This package is actually a P R O L O G program that im- plements the SQL database language. The package can be run as a stand-alone program (although running under the control of the P R O L O G interpreter), operating as a DBMS, but also, since it is written in P R O L O G and runs under the control of the P R O L O G interpreter it can also be included as part of a P R O L O G program. The P R O L O G program can issue SQL commands that are im- mediately executed (in a manner similar to PRO- SQL) but it also has access to all the data struc- tures and facilities of the SQL implementation. While not intended as a production system, but rather as a research tool, the system is capable of running most SQL commands directly.

The availability of the above and similar system does not, unfortunately, indicate that logic programming and relational DBMSs can be easily interfaced. Zaniolo [31] lists the following issues remaining to be solved: (1) when should database goals be executed, (2) how should data be ex- changed to and from P R O L O G and the DBMS, (3) how can the translation of goals (queries) be optimized, and (4) how should recursive calls be supported. Zaniolo's "shor t - to-medium term solu- tion" assigns a navigational interpretation to both P R O L O G and database goals, and suggests using P R O L O G as a navigational query language for a

36 R.G. Ramirez et al. / Generalizations and exceptions in expert database systems

navigational DBMS, such as CODASYL-com- pliant and Entity-Relationship oriented DBMSs.

4.2. Systems Extending Logic Programming Imple- mentations

The approach taken for these systems is to extend a PROLOG or other logic programming processor to incorporate DBMS capabilities. This approach is not popular as the interface, probably because it raises most of the problems of tight integration of PKOLOG and a DBMS with potentially less capability [4]. For example, adding features such as data types would require pro- grammer discipline and are likely to be less efficient than having the semantics implemented directly in the underlying system.

Tsur and Zaniolo [29] report the development of LDL (Logical Data Language). LDL extends logic programming beyond PROLOG in the following ways: (1) no sequential order of execution in a procedure (rule) is assumed, (2) sets are primitive data objects, (3) a form of negation based on set-difference replaces PROLOG's negation by failure, and (4) schema definition and update facilities are included in the language. LDL is reportedly at the prototype stage and work continues.

Sciore and Warren [25] also report the development of a prototype system. They isolated the following concepts to be added to a PROLOG system: (1) disk pointers, indicating the location of a tuple on disk (2) tuple formats, as PROLOG systems typically use a LISP-like format for tuples that is not as efficient as the record-oriented format, and (3) sophisticated buffer management.

4. 3. Extending Relational DBMS

These systems do not completely provide the inferencing capability of logic programming as their query languages tend to stray afar from Horn clause logic, and research in this area seems to be focused on providing general abstract data type facilities to the query language [18]. Current offerings of relational DBMSs do not provide explicit support for deduction rules.

Stonebraker et al. [27] describe a proposed implementation for rules in the relational database system INGRES. While the proposal was considered potentially useful to provide alerting tri-

ggers, and to provide stored DBMS commands, it was also deficient in several important aspects. Some of these deficiencies were that the rule specification was extremely complex, and the result could depend on the order of execution.

Missikoff and Wiederhold [16] propose an evolutionary approach for database systems to have the full capabilities of (their description of) an expert database system. Their criteria for an EDS include that domain knowledge must be managed within the EDS and not delegated to outside procedures and a requirement for deductive power. The key feature of their proposal is a unified frame in which different forms of knowledge can be treated in the same fashion. This feature can only be achieved if there exists an underlying information model that can represent the different forms of knowledge in a homoge- neous fashion. This information model is outlined in their paper.

A concrete mechanism for classification rules in a relational database system has been proposed by Ramirez [9]. The proposal extends the view mechanism in SQL to allow for derived relations with exceptions (DREs) and is discussed in the following section.

5. An Implementation of Classification Rules with Exceptions in Relational Database Systems

Roughly speaking, when using a relational database system, a relation represents a population and each tuple in the relation corresponds to a unique individual in the population. Queries on the relation allow the extraction of subsets of the relation, as well as other " t ransformation" such as projections (eliminating some attributes) and the creation of aggregates (sums and averages, for example). A relational view (i.e., a virtual or derived relation) is defined by storing a query definition.

To represent a classification rule R and its associated sets, the population S, on which R is defined, is represented by a relation that we name "source relation". The classification rule is then represented as a view definition, and the "v iew V on S " is obtained by processing the view definition representing the classification rule. Since a classification rule is defined as a predicate, the

I S source relation

view predicate

S V (row) subset of S

transformation rule

V view

R.G. Ramirez et aL / Generalizations and exceptions in expert database systems

Fig. 3. The Process to Obtain a View or Derived Relation.

view V is, in re la t iona l terms, a tuple subset of the source relat ion.

The fol lowing two subsect ions show, first, how

37

to extend re la t iona l views to represent classif ica- t ion rules and except ions , and second, an imple- men ta t i on using the SQL language.

5.1. Extending Relational Views

Cons ide r an a rb i t r a ry view def in i t ion in a rela- t ional da tabase . I t can be seen as having two componen t s : a " v i e w p red i ca t e " and a " t r a n s f o r - ma t ion rule". The view p red ica t e selects tuples f rom a source re la t ion , and thus def ines a subset of the source rela t ion. The t r ans fo rma t ion rule " t r a n s f o r m s " the tuple subset in to ano the r tab le by e l imina t ing some a t t r ibu tes (projec t ion) , or by compu t ing aggregates (such as sums or averages) . Fig. 3 shows this process.

F o r a c lass i f ica t ion rule, using the process shown in fig. 3, it is a ssumed that each tup le in the source re la t ion represents an ind iv idua l in the

S source relation

view predicate

Sv

explicit listing

S I internal

inclusions

explicit listing

So omissions

S v + S t So

transformation rule

Ds

E L external DRE = D s + E inclusions

Fig. 4. The Process to Obtain Derived Relations with Excepuons.


population S. The view predicate represents the classification rule (i.e., a predicate). The "transformation rule" has (for the purposes of classification rules and of this paper) no effect other than perhaps eliminating some attributes from the re- suiting derived relation.

By separating a view definition into subsetting and transformation components, it is possible to extend the concept of relational views to derived relations with exceptions (DREs) allowing for inclusions and omissions. Fig. 4 shows these extensions to fig. 3. Internal inclusions (S I in fig. 4) are represented by tuples from the source relation which do not satisfy the rule (the view predicate) but must be added to Sv to be included in the DRE. Omissions (So in fig. 4) are tuples from the source relation which satisfy the view predicate (and therefore are in Sv) but must not be in- eluded in the derived relation. The transformation rule is applied to the set S v + S t - S O (the set union of Sv and S t difference So) to form a first derived relation. External inclusions are described by tuples not in the source relation (and therefore not in S v or St) that are included in the derived relation. Thus, the relation E is unioned to the result of "transforming" Sv + S t - So to form the final DRE. When S t, S O and E are empty relations, a DRE reduces to a conventional view, as the set S V + S t - S O will be the same as S v.

The reason for the term internal inclusions will now become clear. The relation S t defines tuples in the source relation that must be included in the DRE, and thus it corresponds to individuals in S that are also in P although they do not satisfy the classification rule. The mechanism shown in fig. 4 adds another relation, E, that corresponds to inclusion that are not present in the source relation. We call these external inclusions. The justification for introducing external inclusions lies in the additional flexibility they provide, particularly in the case where the transformation rule actually mod- ifies the tuples of Sv + St - So. Using this mechanism, it is possible to allow for exceptions in views that, for example, create aggregates such as sums and means from tuples in the source relation.

Internal inclusions (St) and omissions (So) do not need to be explicitly stored. Instead, they are more efficiently obtained by joining relations S with I and O, respectively. I and O are relations containing only the attributes needed to identify tuples in S, usually the primary key.

5.2. An Implementation Using SQL

The mechanism shown in fig. 4 can be implemented by extending the SQL language to allow the definition and processing of DRE's. A proposal for these extensions has been made in Ramirez et al. [20]. In this paper only the aspects that are relevant to classification rules are discussed. The reader unfamiliar with the SQL syntax should refer to [8] or [9].

A DRE is created or defined in a manner similar to the current CREATE TABLE or CREATE VIEW statements. Table 1 shows the form for the CREATE DRE statement, using a

Table 1 Syntax of the CREATE DRE Statement.

relation definition ::= create-table-statement [ create-view-statement [ create-dre-statement

create-table-statement =- (as defined in SQL)

create-view-statement =ffi CREATE VIEW view-name [(view-attributes}] AS subquery ... (as defined in SQL)

subquery ::= SELECT { source-attributes } FROM {source-relation} [WHERE view-selection-formula]

create-dre-statement =ffi CREATE DRE dre-name [BASED ON] VIEW [UPDATE [AS] [KEY [ INTERNAL [INCLUSIONS[ [EXTERNAL [INCLUSIONS[ [OMISSIONS

update-option ::ffi

[ ( dre-attributes } ] view-name update-option] {key attributes}] internal-spec] exteraal-spec] omission-spec]

VIEW ] HYPOTHETICAL RELATION ] NOT AL- LOWED

internal-spec ~= {internal attributes} [FROM internal-table]

external-spcc ::z YES I NO I [RELATION] external-table [(external-attri-

butes)]

omission-spec ~ffi {omission-attributes} [FROM omission- table}]

internal-attributes : : - {subset of source-attributes)

omission-attributes .ffi {subset of source-attributes)

R. G. Ramirez et al. / Generalizations and exceptions in expert database systems 39

Backus-Naur-like syntax. The different entries are as follows: 1. Names for the DRE and its attributes are given

in a manner similar to the standard CREATE VIEW statement.

2. The parameter BASED ON VIEW is required, and relates the definition of the DRE to the name of the view representing the classification rule.

3. The UPDATE AS parameter defines the treat- ment of updates to the DRE. The options are (a) as a regular view, (b) as a hypothetical relation, or (c) no updates will be allowed. A DRE can be updated as a view if the BASED- ON view is in itself updatable. Updating a DRE as a hypothetical relation results in no updates made to the source relation but, instead, updates are considered inclusions or omissions.

4. The KEY option allows the user to specify the attributes that define the key. It also specifies that all references (including internal inclusions and exclusions) to tuples will be made using the attribute selected as the key.

5. The INTERNAL INCLUSIONS and OMIS- SIONS parameters define the attributes that will be used to indicate these types of exceptions (in relations I and O). If the KEY option was used, this attribute must be defined over the same domain as the primary key of the BASED-ON view.

6. The EXTERNAL INCLUSIONS specification defines an optional table that will be unioned with the result of processing the BASED-ON

. \ view with the internal inclusions and omissions. As an example, consider the case described in

the appendix. A list of all customers is kept in the relation CUSTOMERS. Special discount promotions are made according to the rule "offer a promotion to customers whose last quarter purchasing volume was less than 70% of the forecast". The list of customers obtained by applying this rule to the relation CUSTOMERS is modified with inclusions and omissions, reflecting the fact that the promotion (because of its cost) should only be made to those customers that are likely to be influenced in their future purchase decisions. Omissions indicate customers that satisfy the rule (i.e., they bought less than 70% of the forecast) but

are not likely to increase purchases. Internal inclusions represent customers that do not satisfy the rule but are candidates to the promotion anyway. An additional relation, FOREIGN, stores data for individuals that are not current customers but to whom the promotion will be made.

The relation CUSTOMERS corresponds to the set S (the source relation), the :relation AD- DITION is used to represent the internal inclusions, the relation EXCLUSION for omissions, and the relation F O REIG N stores the external inclusions. These relations are defined using the standard CREATE TABLE statement. For sim- plicity, only the relation names and attributes are shown, as follows. CUSTOMER ( c # , name, forecast, actual, city,

type) ADDITION (name) EXCLUSION (name) F O REIG N ( c # , name, forecast, actual, city,

type) The rule "offer a promotion to customers whose

last quarter purchasing volume is less than 70% of the forecast" is represented by defining the view DECREASING as follows (SQL keywords are indicated by using uppercase letters, user-chosen names appear in lowercase): CREATE VIEW decreasing AS SELECT *

FROM customer W H ERE actual < forecast * 0.7; The DRE can be easily defined using the

CREATE DRE statement defined in table 1, as follows: CREATE DRE

BASED ON VIEW INTERNAL INCLUSIONS OMISSIONS EXTERNAL INCLUSIONS

promotions decreasing name n a n ' l e

RELATION foreign

The DRE will be named "PROMOTIONS" . The BASED ON VIEW clause established DE- CREASING as the view definition representing the rule. The IN TERN A L INCLUSIONS and OMISSIONS clauses specify that these exceptions will be referenced using the attribute NAME. Fi- nally, the EXTERNAL INCLUSIONS clause indicates that the relation F O R E I G N contains that type of exceptions.

40 R. G. Ramirez et a L / Generalizations and exceptions in expert database systems

5.3. Retrieving Data from a DRE

The CREATE D R E defines a virtual relation that will be handled in a manner somewhat similar to a conventional view (i.e., a derived relation). Since SQL allows views to be treated almost in the same way as base relations, a view (and a DRE) can be used in (almost) any place that a base table can be used with no modification to the syntax of the data manipulation statements. For DREs in particular, the following change in the semantics of the operations must be made. First, the SELECT statement must be internally modified to retrieve a D R E using the process shown in fig. 3. A SELECT to retrieve data from a DRE is transformed into the U N I O N of two SELECTs. The first select is in turn the result of "merging" the original SELECT with the definition of the view modified for internal inclusions and omissions. The second SELECT is simply the original SELECT applied to the relation containing external inclusions, if applica- ble. Table 2 shows the logical processing of a SELECT on a DRE.

Any valid query on a standard view can also be applied to a DRE. No changes are needed in the syntax of SQL statements for this purpose. A SELECT statement on a query will perform in the following way:

query: SELECT * F R O M promotions

Table 2 Retrieving from a DRE.

dre-retrieval-rule ~= SELECT FROM UNION SELECT FROM

modified view ~= SELECT FROM WHERE

[GROUP BY [HAVING

dre-attributes modified-view

dre-attributes external-table

view-attributes source-relation (view-predicate

OR internal-attributes IN (SELECT internal-attributes FROM internal-table))

AND NOT omission-attributes in (SELECT omission-attributes FROM omission-table)

. . .]

. . .]

treated as: SELECT F R O M W H E R E

U N I O N SELECT F R O M

customer (actual < forecast * .7

OR name IN (SELECT name F R O M AD- D I T I O N )

A N D N O T name in (SELECT name F R O M exclusion)

foreign

The semantics of the update statements in SQL must also be modified. When the view represents a classification rule as defined in this paper, the view is updatable if the source relation is updatable. In general, the source relation will be updatable if it is a base table or a row or column subset of a base table.

6. Concluding Remarks

This paper focused on classification rules in expert database systems. General rules are a powerful modeling tool to represent knowledge at a high level of abstraction. Classification rules represent the important case where a generalization is made on simple facts or objects. Exceptions are, however, present in almost any generalization. Formal definitions and examples of classification rules and exceptions were presented.

The formal definition of classification rules and exceptions does not specify any implementat ion vehicle. Four implementation alternatives that combine logic and relational database systems were assessed using several criteria. The alternatives ranged from totally using the logic system to totally using the relational database system with two alternatives coupling the two systems. Each alternative has its own advantages and disadvantages with no one alternative dominating the others.

Existing systems that implement some form of classification rules were described. A new approach that extends the relational language SQL to allow the specification of classification rules was detailed. This new approach extends the capa-


bilities of relational views to include exception handling. Work is ongoing to fully explore the capabilities of this new approach.

Appendix

An Example Using Logic Programming

The definition of a classification rule as a predicate suggests that a language such as predicate calculus would be appropriate for the representation of classification rules and the population described by it. P R O L O G [6] provides an implementation of a predicate calculus as well as extensions for conventional programming, and it will be used to provide an example. This appendix presents an example of a classification rule and its representation using logic programming. Section 5 of the paper uses this same example in the description of the proposed SQL extensions.

A.1. Background

Consider the hypothetical situation of XYZ Paper Inc., a company selling computer paper to medium and large data processing shops. Customer purchases are relatively constant and are made on a monthly basis. XYZ schedules sale promotions in which special discounts are given to customers which have decreasing their purchase volumes.

The rule followed by XYZ is to offer a discount to "customers whose last quarter purchasing volume is less than 70% of the forecast". The list of such customers is revised to exclude those for whom the promotion would not make difference (in order to avoid unnecessary costs). The list is also modified to include a few selected customers buying in excess of 70% of the forecast but who may increase purchasing volumes in the future.

This example is typical of the use of a classification rule. The rule defines the company 's policy and provides a mechanism to obtain an initial list, while the final list is obtained by deleting some customers and including others.

Exceptions to the rule occur for many different reasons. The following cases may explain omissions: a customer may have announced already its intention of switching to another supplier and therefore the promotion will not result in in- creased sales in the future, a customer may already have a contract guaranteeing a discount in return for exclusivity or high purchasing volume, and a customer is in the process of decentralizing operations and purchases. For internal inclusions, the reasons can be that a customer is considering switching to XYZ as the sole supplier and the promotion may make a difference in the decision.

External inclusions correspond to the case of individuals that not current customers but to whom the promotion will be offered anyway.

A.2. The Logic Programming Representation

The following correspondences exist between the situation depicted and the sets described in the article:

SET CASE

S V

O

E

the list of all customers the subset of customers whose actual purchases are less than 70% the forecast internal inclusions: customers whose purchases exceed 70% the forecast but who will be offered the promotion omissions: customers whose purchases are less than 70% the forecast but who will not be offered the promotion external inclusions: individuals who are not currently customers, but to whom the promotion will be made

A.2.1. Representing the Population S As described above, the population S corre-

sponds in this example to the list of all customers. It can be represented by cod inga P R O L O G assertion for each customer. All assertions have the same name and the same parameters.


C# Name Forecast Actual City Type

customer( 100, 'John Jenkins', 1200, 1000, customer( 108, 'Jett Properties', 600, 500, customer( 127 , 'American Firearms', 1300, 1500, customer( 135 , 'Magnolia Seafood', 1200, 900, customer( 182 , 'Morgan Building', 2100, 800, customer( 210, 'Valley Utilities', 7800, 10500, customer( 215, 'City of Phoenix', 5300, 3975. customer( 218, 'Valley School D.', 1200, 2000. customer( 237, 'T & L Roofing', 150, 275. customer( 249 , 'Southwest Printing', 4982, 4000 customer( 382, 'Blake College', 1200, 285 customer( 391, 'Long Valley Cy.', 2200, 1500 customer( 397, 'High Range City', 4100, 2000 customer( 398 , 'Swaggart College', 20500, 18241

'Houston', 4). 'Bryan', 3). 'Snook', 3). 'Phoenix', 3). 'Houston', 3). 'Snook', 1). 'Phoenix', 1). 'Snook', 2). 'Tucson', 3). 'Chicago', 3). 'Tucson', 2). 'Snook', 1). 'Range', 1). 'Orange', 2).

A.2.2. Representing the Rule and the View The rule "offer a promotion to customers whose

last quarter purchasing volume is less than 70% of the forecast" can be easily expressed in PROLOG by the clause.

promote(C#, Name, Forecast, Actual, City, Type) if

customer(C#, Name, Forecast, Ac- tual, City, Type), Actual < Forecast * 0.7.

Following the conventions of Clocksin and Mellish [6] for the PROLOG syntax, variable names are indicated by capitalizing their first letter (i.e., Name in the rule promote indicates a variable).

When the above rule is used to retrieve all facts satisfying it, we have the following view:

C~ Name Forecast Actual City Type

promote( 182 , 'Morgan Building', 2100, 8 0 0 , 'Houston', 3). promote( 382, 'Blake College', 1200, 285, 'Tucson', 2). promote( 391, 'Long Valley Cy.', 2200, 1500, 'Snook', 1). promote( 397, 'High Range City', 4100, 2 0 0 0 , 'Range', 1).

A.2.3. Representing Exceptions To represent internal inclusions, assume that

customers 'Valley Utilities' and 'T&L Roofing' will be offered the promotion. These customers are not included in the view. The representation can be made by listing their names (or another unique identifier such as customer number) in the following manner:

addition('Valley Utilities'). addition('T& L Roofing').

To represent omissions, assume that customers 'Blake College' and 'High Range City' will not be offered the discount although they qualify according to the rule. Note that these customers are

included in the view. The representation can be made as follows:

exclusion('Blake College'). exclusion('High Range City').

The assertion names "addition" and "exclusion" have, of course, no specific meaning in PROLOG. They were chosen only to make the example clear.

A.2.4. The Modified Representation of the Rule The representation of the rule must be mod-

ified to account for the internal inclusions and omissions. The modified representation becomes the following two statements:


promote(C-~, Name, Forecast, Actual, City, Type) if

customer(C#, Name, Forecast, Ac- tual, City, Type), Actual < Forecast * 0.7, not exclusion(Name).

promote(C~, Name, Forecast, Actual, City, Type) if

customer(C#, Name, Forecast, Ac- tual, City, Type), addition(Name).

The first statement can be interpreted as "a customer record will be selected if it satisfies the

rule and it is not an exclusion". The second statement can be interpreted as "a customer record will be selected if it is a customer record and it is marked as an inclusion". Both statements will be used by the PROLOG processor,, and a record will be selected if it satisfies either statement.

A. 2.5. Representing External Inclusions External inclusions correspond to individuals

not in the population S. Therefore all of their must be supplied. In PROLOG this representation can be easily made by using the same clause as for the rule:

C # Name Forecast Actual City Type

promote( 105, 'Karen Holtz', 1000, 0, 'Dallas', 2). promote( 128, 'Doris Shipman', 2000 0, 'Flagstaff', 3).

A.2.6. Forming the Derived Relation with Excep- tions

Using the statements given in section A.2.4 (the modified rule) and the external inclusion statements given in section A.2.5, the DRE can be

obtained with the following PROLOG query:

promote(C#, Name, Forecast, Actual, City, Type)

giving as a result the following table:

C Name Forecast Actual City Type

promote( 182, 'Morgan Building', 2100, 800, 'Houston', 3). promote( 201, 'Valley Utilities', 7800, 10500, 'Snook', 1). promote( 237, 'T&T Roofing', 150, 275, 'Tucson', 3). promote( 391, 'Long Valley Cy.', 2200, 1500, 'Snook', 1). promote( 105, 'Karen Hohz', 1000, 0, 'Dallas', 2). promote( 128, 'Doris Shipman', 2000, 0, 'Flagstaff', 3).

References

[1] Arity Corporation, 1986, The Arity/SQL Development Package, Arity Corporation, Concord, Massachusetts.

[2] Berghel, H.L., 1985, Simplified Integration of PROLOG with RDBMS, Data Base, Vol. 16, No. 3 (Spring), pp. 3-12.

[3] Borgida, A., and Williamson, K.E., 1985, Accommodating Exceptions in Databases, and Refining the Schema by Learning from Them, Proceedings of VLDB 1985, Stock- holm, Sweden.

[4] Brodie, M.L., and Jarke, M., 1986, On Integrating Logic Programming and Databases, in Expert Database Systems - Proceedings of the First International Workshop, L. Kerschberg (Ed.), The Benjamin/Cummings Publishing Company, Inc., Menlo Park, California, pp. 191-207.

[5] Chang, C.L., and Walker, A., 1986, PROSQL: A PRO- LOG Programming Interface with SQL/DS, in Expert Database Systems - Proceedings of the First International Workshop, L. Kersehberg (Ed.), The Benjamin/Cummings Publishing Company, Inc., Menlo Park:, California, pp. 233-246.

[6] CIocksin, W.F., and Mellish, C.S., 1981, Programming in PROLOG, Springer-Verlag, Berlin, West German,,,.

[7] Cohen, Paul R., and Feigenbaum Edward A.. 1982, The Handbook of Artificial Intelligence Vol. 3, Kaufmann Inc., Los Altos, CA.

[8] Date, C.J., 1985, A Guide to DB2, Addison-Wesley Pub- lishing Company, Reading, Massachusetts.

[9] Date, C.J., 1986. An Introduction to Database Systems:

4.4 R.G. Ramirez et al. / Generalizations and exceptions in expert database systems

Vol. 1, 4th edition, Addison-Wesley Publishing Company, Reading, Massachusetts.

[10] Furukawa, K., Takeuchi, A., Kunifuji, S., Yasukawa, H., Ohki, M., Ueda, K., 1984, Fifth Generation Computer Systems 1984: Proceedings of the International Con- ference on Fifth Generation Computer Systems 1984, North-Holland, Amsterdam.

[11] Gallaire, H., and Minker, J. (Eds.), 1978, Logic and Databases, Plenum Press, New York.

[12] Kellogg, C., 1986, From Data Management to Knowledge Management IEEE Computer, Vol. 19, No. 1, pp. 75-84.

[13] Kerschberg, L., 1985, Expert Database Systems (Workshop Review), Proceedings of ACM SIGMOD 1985, ACM SIGMOD, pp. 414-417.

[14] Kowaiski, R., 1978, Logic for Data Description, in Logic and Databases, Gallaire, H., and Minker, J. (eds.), Plenum Press, New York.

[15] McCabe, D., and Clark, K., 1982, micro-PROLOG: Pro- gramming in Logic, Logic Programming Associates, London.

[16] Missikoff, M., and Wiederhold, G., 1986, Towards a Uni- fied Approach for Expert and Database Systems, in Ex- pert Database Systems - Proceedings of the First Interna- tional Workshop, L. Kerschberg (Ed.), The Benjamin/ Cummings Publishing Company, Inc., Menlo Park, Cali- fornia, pp. 383-400.

[17] Moto-Oka, T. (Ed.) 1981, Fifth Generation Computer Systems: Proceedings of the International Conference on Fifth Generation Computer Systems, North-Holland, Amsterdam.

[18] Parker, D.S., Carey, M., Golshani, F., Jarke, M., Sciore, E., and Walker, A., 1986, Logic Programming and Data- bases, in Expert Database Systems - Proceedings of the First International Workshop, L. Kerschberg (Ed.), The Benjamin/Cummings Publishing Company, Inc., Menlo Park, California, pp. 35-48.

[19] Ramirez, R.G., 1987, Derived Relations with Exceptions, Ph.D. dissertation Texas A&M University.

[20] gamirez, R.G., Dattero, R., and Choobineh, J., 1986, Extensions of Relational Views to Derived Relations with Exceptions, submitted for publication.

[21] Reiter, R., 1978, On Reasoning by Default, Proc. TINLAP-2, Theoretical Issues in Natural Language Processing-2, University of Illinois at Urbana-Champaign, pp. 210-218, reprinted in Readings in Knowledge Repre- sentation. Brachman, R.L and Levesque, H.J., Morgan Kaufmann Publishers, 1985.

[22] Reiter, R., 1980. A Logic for Default Reasoning, Artificial Intelligence, Vol. 7. No. 2, pp. 81-132.

[23] Reiter, R., 1984, Towards a Logical Reconstruction of Relational Database Theory, in On Conceptual Modeling, Brodie, M.L., Mylopoulos, J., and Schmidt, J.W. (Eds.), Springer-Verlag, New York.

[24] Rich, E., 1983. Artificial Intelligence, McGraw-Hill, New York.

[25] Sciore, E., and Warren, D.S., Towards an Integrated Database-PROLOG System, in Expert Database Systems

- Proceedings of the First International Workshop, U Kerschberg (Ed.), the Benjamin/Cummings Publishing Company, Inc., Menlo Park, California, pp. 293-305.

[26] Smith, John Miles, 1986, Expert Database Systems: A Database Perspective, in Expert Database Systems - Pro- ceedings of the First International Workshop, L. Kersch- berg (Ed.), The Benjamin/Cummings Publishing Com- pany, Inc., Menlo Park, California, pp. 3-15.

[27] Stonebraker, M+, Woodfill, J., and Andersen, E., 1983, +'Implementation of Rules in Relational Data Base Sys- tems", 1EEE Data Engineering, December 1983.

[28] Tsichritzis, D., and Lochovsky, F., 1982, Data Models, Prentice-Hall, Englewood Cliffs, NJ.

[29] Tsur, S., and Zanioio, C., 1986, LDL: A Logic-Based Data-Language, MCC Technical Report Number DB-026- 86, February 11, 1986.

[30] Vassiliou, Y., Clifford, J., and Jarke, M., 1985. Access to Specific Declarative Knowledge by Expert Systems, Deci- sion Support Systems Vol 1 (1985), pp. 123-141.

[31] Zaniolo, C., 1986, PROLOG: a Database Query Language for All Seasons, in Expert Database Systems - Proceed- ings of the First International Workshop, L. Kerschberg (Ed.), The Benjamin/Cummings Publishing Company, Inc., Menlo Park, California, pp. 233-246.

Representing generalizations and exceptions in expert database systems

Documents

Transcript of Representing generalizations and exceptions in expert database systems