Database Modeling and Design - Database Systems - page 85

5.4 The Extended Relational Model
Even with the conventions above, the E-R model was found lacking in its treatment of
certain scenarios. Recognizing this, Codd and Date introduced an alternate extended
relational model (which for convenience will be abbreviated as the XR model), the
essence of which is described here (for more details, see [Date, 1990] and [Date, 2004]).
The XR model makes no distinction between entities and relations; an entity is a
special kind of relation. Structural and integrity aspects are more extensive and precisely
defined than those of the E-R model. The XR model introduces its own special operators
apart from those of the basic relational model. Additionally, entities (and relationships)
are represented as a set of E-relations and P-relations.
The model includes a formal catalog structure by which relationships can be made
known to the system, thus facilitating the enforcement of integrity constraints implied by
such relationships.
As you will see later in the course, it turns out that the XR model forms the basis of
how the system catalog is handled in most contemporary DBMS suites. We shall therefore
spend a few moments to look at the main features of the model.

5.4.1 Entity Classifications
Under the XR model, the following entity classifications hold:

• Kernel entities

• Characteristic entities

• Designative entities

• Associative entities

• Sub-type/super-type entities

Kernel Entities: Kernel entities are those entities that have independent existence.
They are what the database is really about. For example, in an inventory system, kernel
entities might be Purchase Order , Receipts of Goods (Invoice), Inventory Item ,
Department and Issuance of Goods (to various departments). Referring to the example
used in the previous section, kernel entities would be Suppliers , InventoryItems ,
Projects, Employees , and Departments .
Characteristic Entities: Characteristic entities describe other entities. For instance
(referring to Figure 5-2b ), Dependent is a characteristic of Employee . Characteristics are
existence-dependent on the entity they describe.
Designative Entities: An entity, regardless of its classification, can have a property
(attribute) whosefunction is to designate (reference) some other entity, thus implementing
a 1:M relationship. For instance (referring to Figure 5-2b ), Employee is designative of
Department , and Project is designative of Employee (due to relationship ProjMgr ). Put
another way, a designation is the implementation of an M:1 relationship. The designating
entity is the entity on the “many-side” of a 1:M relationship. Note that a characteristic entity
is necessarily designative since it designates the entity on which it is existence-dependent.
Note however, that a designative entity is not necessarily characteristic. Entities Project ,
Employee , and Dependent amplify these points (see Figure 5-2 ).