Database Reference
In-Depth Information
5.4.3 E-Relations and P-Relations
The original XR model specification prescribes the use of
E-relations
and
P-relations
.
The database would contain one
E-relation
for each entity type — a unary relation
that lists surrogates for all tuples of that entity (type). To illustrate, let us revisit the
manufacturing firm's partial database (Figure
5-2
) of previous discussions: Suppose for
a moment that the
Supplier
relation contains two tuples, the
InventoryItem
relation
contains three tuples, and the
Department
relation contains three tuples. A possible
internal representation of the E-relations for this scenario is illustrated in Figure
5-6a
. An
“E” is inserted in front of the original relation name (for example
E-Supplier
) to denote
the fact that this is an E-relation being represented. The percent sign (%) next to the
attributes (for example
Suppl%
) are used to denote the fact that these attributes are really
surrogates.
In addition to the E-relations concerned with tuples, a special binary E-relation
would be required to link so-called E-relations to the original relations. We will call
this the
host E-relation
. It is illustrated in Figure
5-6b
. This would allow users to relate
to the database using relation names that they are familiar with; translation would be
transparent to them.
Properties (attributes) for a given entity type are represented by a set of
P-relations
.
The P-relation stores all property characteristics and values of all tuples listed in the
corresponding E-relation. Properties can be grouped together in a single n-ary relation,
or each property can be represented by P-relation, or there can be a convenient number
of P-relations used; the choice depends on the designer. In the interest of simplicity,
let us assume the third approach; let us assume further, that there is a P-relation for
each E-relation. A convenient possible representation for the E-relations of Figure 5-6a
is illustrated in Figure
5-6c
. A “P” is inserted in front of the original relation name (for
example
P-Supplier
) to denote the fact that this is a P-relation being represented. Notice
also that each P-relation contains a foreign key that ensures that each tuple is referenced
back to its correspondent in the associated E-relation.
Carrying on with the assumption that there is a P-relation for each E-relation: In
addition to the basic P-relations, a special P-relation would be required to store the
characteristics of each property (to be) defined in the database. Let us call this the
host
P-relation
. It is represented in Figure
5-6d
. By including this relation, we allow users
the flexibility of adding new properties to a relation, modifying existing properties in a
relation, or deleting pre-existent properties from a relation. These changes are referred to
as
structural changes
to a relation; they will be amplified later in the course (chapter 11).
Figure 5-6a.
Illustrating E-relations
