Loading...
Please wait, while we are loading the content...
Similar Documents
Multiple Inheritance and the Closure of Set Operators in Class Hierarchies
| Content Provider | Semantic Scholar |
|---|---|
| Author | Pfaltz, John L. French, James C. |
| Copyright Year | 1992 |
| Abstract | In this report, we establish essential closures in class hierarchies of database systems that support set operations, such as union and intersection, in their query language. In particular, we rigorously demonstrate that multiple inheritance is an implementation requirement, as is the formal treatment of the class hierarchies as lattices with defined least upper, and greatest lower, bound operators. Multiple Inheritance and the Closure of Set Operators in Class Hierarchies † John L. Pfaltz James C. French Institute for Parallel Computation University of Virginia, Charlottesville VA Two capabilities seem essential in new database implementations — class inheritance and set operations. In the course of designing and prototyping ADAMS, a distributed database language developed in the Institute for Parallel Computation at the University of Virginia, we sought implementation semantics for both of these key concepts. They are non-trivial; our initial intuitive semantics turned out to be flawed. We began by assuming an underlying, object based [Weg87] entity database model which is compatible with extended entity-relationship models [Che76, TYF86], many semantic models [AbH87, PeM88], and to which the relational model can be easily extended by adjoining a unique symbolic identifier to every tuple — as is common in many implementations. In short, this entity model, developed in the remainder of this section is intended to be a purely vanilla model with no surprises, of which more practical systems are refinements. On this we define (in Section 2) the concept of the "compass" of a class, which then forms the basis of our set operation semantics (in Section 3). One consequence of this semantic analysis will be the need for multiple inheritance [AbH87, Car84, Tou86], even though, as Peckham and Maryanski [PeM88] note, it "can be difficult to control". Its control can be facilitated [PFG91] by implementing classes as entities themselves in well-defined lattices with the associated least upper bound, and greatest lower bound, operators. 1. Entity Database Model The key presupposition of the entity database model is that the database is implemented by creating uniquely identifiable entities. We impose a type structure on entities, or objects, by assigning them to a class. All entities in the class, for example the class PERSON, will share common properties, such as name, home_address, age, and social_security_number. We will also assume the existence of subclasses. Most semantic and object-oriented databases use an IS_A construct to support the concept of class and subclass. Brachman [Bra83] correctly notes that inheritance as defined by the IS_A construct is really little more than convenient syntactic shorthand for incrementally creating subclasses, so we will ignore actual inheritance mechanisms per se. The important feature that is abstracted in the entity database model is the very existence of classes and subclasses, which can be declared by what ever syntactic formalism is convenient. For example, the class DOCTOR, with the additional properties speciality, training, and office_address, might be a subclass of PERSON. The class PERSON may also subsume a subclass PATIENT, with the additional properties case_history, complaint, and outstanding_amount_due. In these preceding examples, classes and subclasses have been characterized by properties which are called attributes in both relational and object-oriented terminology. For our purposes, we will assume that a class attribute is a singled valued function, f , of a single variable x where x denotes the unique identifier of an entity instance within the class. The image of f may be a value (e.g. printable string or icon), or some other entity. Permitting f to be set-valued as in DAPLEX [Shi81] will not alter the generality of our approach. In most database systems, classes are defined in terms of their associated attribute properties. But they can also be defined by imposing predicate restrictions on class membership. For example, we might choose to declare JUVENILE to be a subclass of PERSON, with the restriction that age < 21. The preceding intuitive introduction to classes, subclasses, and a class hierarchy in the entity database model can be made more formal. Let F = { f i } denote a set of functions associated with a particular |
| File Format | PDF HTM / HTML |
| Language | English |
| Access Restriction | Open |
| Content Type | Text |
| Resource Type | Article |
