ModelingRelationships ORDB

Modeling relationships in object-relational databases
Christian Soutou
*
Universit e de Toulouse II, IUT B,

Equipe de Recherche Technologique ICARE, 1 Place Georges Brassens, 31703 Blagnac Cedex, France
Received 25 November 1999; received in revised form 21 March 2000; accepted 14 June 2000
Abstract
We propose an approach for designing an object-relational database. We inspect each case of semantic relationships
(one-to-one, one-to-many, many-to-many and n-ary). For each of these cases we list the dierent solutions for im-
plementation and propose some solutions. We also make a comparison with the relational data model. Our results can
be applied to current RDBMS including object extensions (Oracle8, DB2-IBM, InformixF F F). 2001 Elsevier Science
B.V. All rights reserved.
Keywords: Object-relational; Database modeling; Semantic relationships
1. Introduction
For the last years, most major database management systems (DBMS) vendors [5,8,26,27] have
been investing heavily into Object-Relational (OR) technology to provide the extensibility and
exibility that many companies are requiring today. Great theoretical advantage was supplied by
relational systems over CODASYL-based systems. Therefore, in order to achieve good perfor-
mance, some database designers felt the need to denormalize their data models. Paradoxically,
object-oriented databases retain some of the concepts of earlier database techniques such as
CODASYL structures (linked lists and pointers).
Object-relational database management systems (ORDBMS) are generally intended to manage
diverse data types and oer greater support for object-oriented programming language. These
new facilities integrate management of traditional elded data, of complex objects such as time-
series and of geospatial data and diverse binary media such as audio, video, images, and applets.
By encapsulating methods with data structures, an ORDBMS server can perform complex ana-
lytical and data manipulation operations for searching and transforming multimedia and other
complex objects. As an evolutionary technology, the OR approach has inherited both the
performance management features of its relational ancestor [9] and the exibility of its object-
oriented cousin [2,7,18]. Database designers can thus work with already-familiar tabular
Data & Knowledge Engineering 36 (2001) 79107
www.elsevier.com/locate/datak
*
Tel.: +33-5-62-74-75-83; fax: +33-5-62-74-75-87.
E-mail address: soutou@iut-blagnac.fr (C. Soutou).
0169-023X/01/$ - see front matter 2001 Elsevier Science B.V. All rights reserved.
PII: S 0 1 6 9 - 0 2 3 X ( 0 0 ) 0 0 0 3 5 - 5
structures and data denition languages while getting familiar with new object-management
possibilities. Some commercial products exist (OR-Compass, InfoModeler, Silverrun, Rational
Rose, Oracle Database DesignerF F F), which provide tools for conceptual modeling and also gen-
erate physical schemas either directly towards the database or inside a data denition language le.
According to Grimes [14,15], these tools are still immature and functionally incomplete. In
particular, they do not provide enough methodological or ad-hoc logical modeling assistance in
deciding how to implement semantic relationships. Few eorts have been made to oer guidelines
to design an OR-database. This paper attempts to ll that gap by providing a list of modeling
possibilities for each kind of semantic relationship and by making a comparison with the rela-
tional data model.
Before enumerating the several possibilities of implementing semantic relationships, it is es-
sential to understand the capabilities of the OR data model.
2. New features of the object-relational approach
The OR data model is an extension of the relational one [3,6,11,13,17,19,23,25,29]. It provides
Abstract Data Types (ADT, also called user-dened types) including complex data structures,
collections, encapsulation, inheritance and Object IDentity (OID). Collections are a means of
storing a series of data entries jointly associated to a corresponding row in the database. Col-
lections does not meet the rst normal form principle because collections can be viewed as nested
relations. Relational theorists long ago worked out which extensions to relational theory should
be required to support non-rst normal form databases [4,10,20]. The idea is to allow an array as
a datatype. More recent works have investigated nested relations [22] dene a partition normal
form which guarantees expected properties for nesting and unnesting and for keys of nested re-
lations [21] dene a normal form that characterizes redundancy in nested relations based on
functional and multivalued dependencies [28] provide an extension of functional dependencies in
order to propose object normal forms for object-oriented schemata.
Without a normalized database, it may be dicult to extract information without writing a
complex procedural code. These rules of normalization were important in relational modeling and
are still important in object-relational modeling. ORDBMS editors use object extension of SQL to
handle information in the database. If the database is not normalized, SQL may not work. The
concepts of collections and OIDs are in contradiction to the basic principles of the relational data
model. Indeed, contrary to relational data model which is based on the rst normal form, col-
lections are not. As for OIDs, contrary to the relational data model which is based on values
(relationships between tables are provided by foreign-key attributes acting as logical pointers),
they are implemented via physical references.
As regards pure object concepts, there are close similarities between objects and instances of
entities and between classes and entities. Object in classes usually map very closely to rows in
tables in the physical design. However there are important dierences between the relational and
the object approaches:
Encapsulation is a basic concept in object theory, which implies that no applications should
have direct access to a table. For example, rather than inserting records directly into a table,
the application has to call a method specically intended for insertion.
Inheritance is similar to relational subtyping.
80 C. Soutou / Data & Knowledge Engineering 36 (2001) 79107
There are pure object database products on the market that support persistent objects and fully
support both encapsulation and inheritance but they do not oer relational systems performance.
2.1. Using pointers to manage object identity
With ORDBMS, object identity is provided via pointers in tables, thus improving navigation
between objects by means of the query language. The join operator is no longer nedds to link two
or more tables as, in OR-SQL queries it is replaced by dotted notation. Let us consider an ex-
ample (Fig. 1) in which primary keys attributes are noted in bold and foreign keys in italic.
Relational SQL-queries (A) and (B) need a join (a procedural join has been made for the rst
query and a relational one for the second query).
Fig. 1. Relational tables.
C. Soutou / Data & Knowledge Engineering 36 (2001) 79107 81
(The dierent solutions to implement relationships in the OR data model will be studied in
Section 3.)
With an OR approach, for one-to-many relationships, we can privilege the navigation from
child-to-parent, from parent-to-child, both, or none. In Oracle8, pointers are supported by REF
attributes [5]. (In this paper, pointers attributes will be noted @, as illustrated in Fig. 2.)
Query (C) returns the OIDs contained in the dept column. The result shows that the third row
is dierent from the others (18th position) as it refers to department D2 whereas the other
pointers refer to department D1.
SELECT eXdept FROM Employee e; (C)
DEPT
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0000220208676644B00DFF11D48850204C4F4F5020676644AE0DFF11D48850204C4F4F5020
An OID can be extracted from an OR table by using the REF(a) operator (a being an alias for
the OR table).
Object-Relational SQL-queries (E) and (F) do not need a join because they use navigation
through the REF attribute dept. (The implicit joins are in bold in these queries.)
2.2. Using collection to represent a relationship
Each collection type describes a data unit made up of an indenite number of elements, all of the
same datatype. The collection types can be array types or table types. In Oracle8 array types are built
thanks to varray, and table types are built thanks to nested tables [12]. A varray is an ordered and
boundedset of dataelements. All elements of agivenarrayare of the same datatype. Eachelement has
an index, which is a number corresponding to the element's position in the array. Anested table is an
unorderedandunboundedset of dataelements, all of thesamedatatype. It hasasinglecolumn, andthe
typeof that columnis abuilt-intypeor anobject type. If anobject type, thetablecanalsobeviewedas a
multi-column table, with a column for each attribute of the object type.
If we privilege the parent-to-children data access, the relationship can be made via a collection
containing a set of pointers. In Oracle8 a nested table can be used (or a varray if you know exactly
the maximum cardinality.
Suppose that we use the nested table called emps in the OR table Department (see
Fig. 3). Oracle provide a new instruction THE to designate a nested table, an alias is also needed.
So we can use an implicit join via the pointer emp. The query (G) extracts child-records from a
predicate upon parent-records is more simple than the query (H) because of implicit joins.
Fig. 2. Childparent privileged.
We can see that query (F) is more complex than the previous one. The complexity (nested
cursor) comes both from using a collection of pointers and querying many parent-records re-
quiring a predicate upon child-records. Moreover the result in the SQL*Plus screen is not very
clear.
Inverse references can help formulate queries (from child to parent, in our example Fig. 3, a
pointer must be used from Employee to Department). Nevertheless redundant pointers must be
processed for each INSERT, UPDATE or DELETE.
2.3. A symmetrical solution
An additional table containing two pointers can be used. We call this solution the universal
solution because it ts every kind of semantic relationship (one-to-one, one-to-many, many-to-
many, recursive and n-ary). In our example, see Fig. 4, the primary key of additional table Be-
longs_to is composed of two pointer attributes.
In this symmetrical solution, queries (I) and (J) are facilitated because (i) implicit joins can be
used either in the SELECT or in the WHERE clause; (ii) only the additional table (here Belongs_to)
appears in the FROM clause. Moreover, there is no redundancy due to inverse references.
Fig. 3. Parent children privileged.
2.4. Referential integrity
According to the present SQL standard [1,16], a referential integrity constraint can specify
inclusion dependency between foreign key values in one table and primary key values in one or
more tables. Conversely, a pointer value always refers to one particular object in the database.
We have seen that pointers can help queries formulation. Strong typing is automatically
enforced in some commercial products (Oracle supports it via the SCOPE IS clause in a table
denition), but DELETE or UPDATE CASCADE are not provided and the user has to explicitly
Fig. 4. Universal solution.
compute the referential integrity. However it is possible to declare in Oracle8 a NOT NULL
constraint on a pointer-attribute. On the other hand, the object approach incites encapsula-
tion. Integrity constraint could be taken into account via methods. Pointers should not be
thought of as a replacement for referential integrity but rather as an additional database
mechanism.
3. Semantic relationships modeling
We enumerate the several possibilities for relationships modeling in the object-relational model.
For each kind of semantic relationships we make an analogy with the relational model. We do not
indicate here the best solution for a given relationship but Section 4 indicates some guidelines to
choose among those solutions. We propose a classication revealing the interest of using the new
features of ORDBMS.
The object-relational modeling alternatives we propose are semantically equivalent if the de-
signer includes some additional constraints if necessary. Here are two examples:
the solutions given in Figs. 1 and 2 are semantically equivalent if the attribute @dept is scoped
to refer to the table Department only;
the solutions given in Figs. 1 and 3 are semantically equivalent if two distinct records of nested
tables emps do not refer to the same object Employee.
3.1. Reasoning
Two object-relational mechanisms are available in order to implement semantic relationships:
collections (nested tables or varrays in Oracle8) and pointers. The question at stake is: ``Can we
represent a given relationship in an object-relational model by using collections and pointers?''
Fig. 5 illustrates our reasoning. Using a collection is noted { }, pointers are marked @. We do not
consider the solutions based on multiple nesting levels.
A possible though not fully interesting solution is to adopt a pure-relational design in an
ORDBMS (never using collections and pointers, only foreign key attributes) to implement rela-
tionships. ADTs and methods can however be dened. It may be a good approach for getting
familiar with object-relational principles. After that, the next step consists in including nested
tables and physical pointers in ADTs.
3.2. Terminology
We note R[(k
1
Y k
2
Y F F F Y k
k
)Y fk
1
5Y fk
2
5Y F F F Y fk
j
5, p
1
Y p
2
Y F F F Y p
m
[ a relation having:
k primary key attributes; note that k
i
can also be a foreign key (k
i
#) or can belong to one or
more foreign keys (k
i
Y k
i1
F F F)5;
j pure foreign key attributes; note that a foreign key can include more than one attribute (fk
i
,
fk
i1
...)#;
m non-key attributes (p
i
).
3.3. One-to-one relationships
The relational model oers four solutions to implement one-to-one relationships between two
relations R1 and R2. See Fig. 6 the three solutions (a), (b) and (c) using two relations with one or
two foreign key attributes with a UNIQUE constraint for each of them. The other solution (d)
involves an additional relation R3 including two foreign key attributes with a UNIQUE constraint
for each of them.
Solution (c) is redundant but can help for particular queries. Solutions (a) and (b) are sym-
metrical, so the designer must choose which is more appropriate to avoid getting null values in
foreign key attributes. Solution (d) can easily evolve but necessitates a join operator for each
query.
The object-relational model oers two ways of implementing one-to-one relationships using
either two or three relations without collection. It is however possible to use a collection but
these solutions make database design and manipulation more complex. We will not study these
cases.
Relational solutions (a) and (b) lead to object-relational solutions by substituting a pointer for
the foreign key attribute. Relational solutions (c) and (d) lead to object-relational solutions by
combining the use of foreign key attribute(s) and pointer(s).
For four solutions in the relational model, we have listed 12 object-relational solutions de-
scribed in Table 1 for implementing a one-to-one relationship:
Fig. 5. Reasoning.
Fig. 6. Four relational solutions for one-to-one relationships.
four are analogous to the relational solutions;
two use a pointer;
four are hybrids (use of a pointer and a foreign key attribute);
two use two pointers.
Fig. 7 illustrates the dierent possibilities for implementing a one-to-one relationship.
3.4. One-to-many relationships
The relational model oers two solutions to implement one-to-many relationships between two
relations R1 (parent) and R2 (child), see (Fig. 8). Solution (a) uses two relations with one foreign
key attribute in the child relation. Solution (b) uses additional relation R3 including two foreign
key attributes with a UNIQUE constraint for the one referring to the child relation.
Solution (a) is the most commonly used in database design. Solution (b) can easily evolve
towards other cardinality constraints one-to-one (adding a UNIQUE constraint in the relation R3)
or many-to-many (removing the UNIQUE constraint upon relation R3).
The object-relational model oers three ways for implementing one-to-many relationships. The
rst one consists in using only one relation with a collection (this case is very particular, and
remains the hierarchical model). The second way uses two relations with or without a collection,
pointers can also be used. The third way uses three relations without any collection, pointers can
also be used.
Table 1
One-to-one relationship
Relational model Object-relational model
R1[k
1
Y F F F[ (a) R1[k
1
Y F F F[ (1)
R2[k
2
Y F F F Y k
1
5[ R2[k
2
Y F F F Y k
1
5[
R1[k
1
Y F F F[ (2)
R2[k
2
Y F F F Y dp
1
[
R1[k
1
Y F F F Y k
2
5[ (b) R1[k
1
F F F Y k
2
5[ (3)
R2[k
2
Y F F F[ R2[k
2
Y F F F[
R1[k
1
Y F F F Y dp
2
[ (4)
R2[k
2
Y F F F[
R1[k
1
Y F F F Y k
2
5[ (c) R1[k
1
Y F F F Y k
2
5[ (5)
R2[k
2
Y F F F Y k
1
5[ R2[k
2
Y F F F Y k
1
5[
R1[k
1
Y F F F Y k
2
5[ (6)
R2[k
2
Y F F F Y dp
1
[
R1[k
1
Y F F F Y dp
2
[ (7)
R2[k
2
Y F F F Y k
1
5[
R1[k
1
Y F F F Y dp
2
[ (8)
R2[k
2
Y F F F Y dp
1
[
R1[k
1
Y F F F[R2[k
2
Y F F F[ (d) R1[k
1
Y F F F[R2[k
2
Y F F F[ (9)
R3[k
1
5Y k
2
5[ R3[k
1
5Y k
2
5[
R1[k
1
Y F F F[R2[k
2
Y F F F[ (10)
R3[dp
1
Y k
2
5[
R1[k
1
Y F F F[R2[k
2
Y F F F[ (11)
R3[k
1
5Y dp
2
[
R1[k
1
Y F F F[R2[k
2
Y F F F[ (12)
R3[dp
1
Y dp
2
[
Relational solution (a) leads to object-relational solutions by replacing the foreign key attribute
by a pointer or by using a collection in the parent relation. This collection contains either a
pointer towards the child relation or an attribute which can be used to refer to this relation.
Moreover, inverse references can also be used.
Relational solution (b) leads to object-relational solutions by combining the use of foreign key
attribute(s) and pointer(s). To make it simple, we will not discuss collection in the third relation.
For two solutions in the relational model, we have listed 12 object-relational solutions de-
scribed in Table 2 for implementing a one-to-many relationship:
two are analogous to the relational solutions;
one uses two relations without collection but with a pointer;
six use a collection containing either a set of pointers or a set of foreign key attributes;
three use a third relation containing one or two pointers.
Fig. 9 illustrates the dierent possibilities for implementing a one-to-many relationship.
3.5. Many-to-many relationships
The relational model oers one solution to implement many-to-many relationships between
two relations (R1 and R2), see Fig. 10. Solution (a) uses an additional relation R3 including two
foreign key attributes composing the primary key). Note that non-key attributes can appear in the
third relation.
The object-relational model oers two ways for implementing many-to-many relationships. The
rst one uses two relations, one of them contains a collection (with or without pointers). The
Fig. 7. One-to-one relationship with the object-relational model.
Fig. 8. Two relational solutions for one-to-many relationships.
second uses three relations, one of them may contain a collection (with or without pointers).
Anyway, if a collection is used, each attribute (key or non-key) of the relation R3 can be privi-
leged.
Table 2
One-to-many relationship
R1[k
1
Y F F F[ (a) R1[k
1
Y F F F[ (1)
R2[k
2
Y F F F Y k
1
5[ R2[k
2
Y F F F Y k
1
5[
R1[k
1
Y F F F[ (2)
R2[k
2
Y F F F Y dp
1
[
R1[k
1
Y F F F Y k
2
[ (3)
R2[k
2
Y F F F[
R1[k
1
Y F F F Y k
2
[ (4)
R2[k
2
Y F F F Y k
1
5[
R1[k
1
Y F F F Y k
2
[ (5)
R2[k
2
Y F F F Y dp
1
[
R1[k
1
Y F F F Y dp
2
[ (6)
R2[k
2
Y F F F[
R1[k
1
Y F F F dp
2
[ (7)
R2[k
2
Y F F F Y k
1
5[
R1[k
1
Y F F F Y dp
2
[ (8)
R2[k
2
Y F F F Y dp
1
[
R1[k
1
Y F F F[R2[k
2
Y F F F[ (b) R1[k
1
Y F F F[R2[k
2
Y F F F[ (9)
R3[k
1
5Y k
2
5[ R3[k
1
5Y k
2
5[
R1[k
1
Y F F F[R2[k
2
Y F F F[ (10)
R3[dp
1
Y k
2
5[
R1[k
1
Y F F F[R2[k
2
Y F F F[ (11)
R3[k
1
5Y dp
2
[
R1[k
1
Y F F F[R2[k
2
Y F F F[ (12)
R3[dp
1
Y dp
2
[
Fig. 9. One-to-many relationship with the object-relational model.
In the example illustrated in Fig. 11, the relational table Install has three attributes: softno,
pcno et dateinst.
In the object-relational model, there are four bases to work on, because we can privilege three
possible data accesses (via softno, pcno or dateinst) or neither of these attributes. These four
cases will be discussed in the following sections (Fig. 12 represents the solution in which no at-
tribute is privileged; Fig. 13 represents the solution in which attribute softno is privileged; Fig. 17
represents the solution in which attribute pcno is privileged; Fig. 18 represents the solution in
which attribute dateinst is privileged).
3.5.1. Privileged attribute
Object-relational solutions with no privileged attribute are based on the use of a third table
containing one or two pointers (instead of the foreign key attributes) and non key attributes.
3.5.2. Privileged attributes
In the example there are three attributes in the many-to-many relationship table. Each of these
three attributes can be privileged. These solutions are based on the use of an object-relational
Fig. 11. Relational database (many-to-many relationship).
Fig. 10. Relational solution for many-to-many relationships.
table including or not pointers and containing a collection from a group by clause. If data access is
privileged via the PCs, the collection consists in grouping by softno and dateinst. If data access
is privileged via the soft, the collection consists in grouping by pcno and dateinst and so on. Let
us assume that the user privileges data accesses via softs. The object-relational table Install_NF2
to dene includes two nested levels (Fig. 13). A collection pcnos is self-contained in the nested
table dates. Oracle8 does not permit multiple nesting levels.
One solution to avoid multiple nesting levels consists in dening a table with only one collection
by grouping on a particular attribute. In the example, records can be grouped by softno (Fig. 14).
We can use two solutions with one pointer:
replacing pcno by a pointer towards table PC;
replacing softno by a pointer towards table Soft.
We can also use a solution with two pointers replacing pcno by a pointer towards table PC
and softno by a pointer towards table Soft (Fig. 15).
The solutions without an additional table (such as Install in our example) require to dene, in
one parent table, a nested table including the child records with or without pointers. In the ex-
ample, Soft can be chosen to include the collection dates (Fig. 16). This solution can be derived
by replacing attribute pcno by a pointer towards the table PC.
Fig. 13. Many-to-many relationship with two nested levels.
Fig. 12. Many-to-many relationship with two pointers.
Other solutions can be found on the same basis by privileging other attributes (in our example
pcno and dateinst). See Fig. 17 describing the case where pcno is privileged. Fig. 18 shows
dateinst as a privileged attribute.
For one solution in the relational model, we have listed 16 object-relational solutions described
in Table 3 for implementing a many-to-many relationship without property.
Fig. 19 illustrates these solutions.
For one solution in the relational model, we have listed 16 4j object-relational solutions
described in Table 4 for implementing a many-to-many relationship with j properties:
Cases (7)(9) generate j solutions (3j). Cases (10), (11) and (12) are, respectively, symmetrical
about (7), (8) and (9); so they do not provide any additional solution. Cases (5) and (6) generates j
new solutions. The number of possible many-to-many relationships with j properties is
16 j 3j = 16 4j.
We can see that many-to-many relationships without property is a particular case (j =0). With
this formula, we nd the 16 solutions previously quoted. Fig. 20 presents these solutions.
3.6. N-ary relationships
3.6.1. Terminology
We note R[(a
1
Y a
2
Y F F F Y a
k
)#, b
+
1
Y b
+
2
Y F F F Y b
+
j
Y p
1
Y p
2
Y F F F Y p
m
[ an n-ary relation [24] having:
Fig. 14. Many-to-many relationship with one nested structure without pointer.
Fig. 15. Many-to-many relationship with one nested structure with two pointers.
Fig. 18. Many-to-many relationship with two nested levels (dateinst privileged).
Fig. 16. Many-to-many relationship with one nested structure without pointers.
Fig. 17. Many-to-many relationship with two nested levels (pcno privileged).
k primary key attributes; note that a
i
can also be a foreign key (a
+
i
#) or can belong to one or
more foreign keys (a
i
Y a
i1
F F F)*#;
j pure foreign key attributes; note that a pure foreign key can include more than one attribute
(b
i
Y b
i1
F F F)*;
Table 3
Many-to-many relationship without property
R1[k
1
Y F F F[R2[k
2
Y F F F[ (a) R1[k
1
Y F F F[R2[k
2
Y F F F[ (1)
R3[fk
1
5Y fk
2
5[ R3[fk
1
5Y fk
2
5[
R3[dp
1
Y fk
2
5[ (2)
R3[fk
1
Y dp
2
[ (3)
R3[dp
1
Y dp
2
[ (4)
R1[k
1
Y F F F[R2[k
2
Y F F F[ (5)
R3[k
1
Y k
2
[
R3[k
2
Y k
1
[ (6)
R1[k
1
Y F F F[R2[k
2
Y F F F[ (7)
R3[k
1
Y dp
2
[
R3[dp
1
Y k
2
[ (8)
R3[dp
1
Y dp
2
[ (9)
R3[k
2
Y dp
1
[ (10)
R3[dp
2
Y k
1
[ (11)
R3[dp
2
Y dp
1
[ (12)
R1[k
1
Y F F F Y k
2
[ (13)
R1[k
1
Y F F F Y dp
2
[ (14)
R2[k
2
Y F F F Y k
1
[
R1[k
1
Y F F F Y k
2
[ (15)
R2[k
2
Y F F F Y dp
1
[
R1[k
1
Y F F F Y dp
2
[ (16)
R2[k
2
Y F F F Y dp
1
[
Fig. 19. Many-to-many relationship without property.
m non-key attributes (p
i
);
n = k j is called degree of the n-ary relation. At a given degree n, an n-ary relation may have
various numbers of primary key attributes (k).
Let us consider an example of 3-ary relationship between Server, Department and Soft.
Many softs can be installed on servers by departments.
The only solution in the relational model for implementing an n-ary relationship is described in
Fig. 21. It requires an additional table including the n key attributes and optional non key at-
tributes (properties of the relationship). In our example Fig. 22, the 3-ary relationship has a
property (dateinst). Many-to-many relationships are particular cases of n-ary ones (n =2).
The object-relational model oers two ways for implementing an n-ary relationship:
Table 4
Many-to-many relationship with j properties
R1[k
1
Y F F F[R2[k
2
Y F F F[ (a) R1[k
1
Y F F F[R2[k
2
Y F F F[ (1)
R3[fk
1
5Y fk
2
5Y aY Y bY cY F F F Y j[ R3[fk
1
5Y fk
2
5Y aY bY cY F F F Y j[
R3[dp
1
Y fk
2
5Y Y aY bY cY F F F Y j[ (2)
R3[fk
1
Y dp
2
Y aY bY cY F F F Y j[ (3)
R3[dp
1
Y dp
2
R1[k
1
Y F F F[R2[k
2
Y F F F[ (5)
R3[k
1
Y k
2
Y aY bY cY F F F Y j[
R3[k
2
Y k
1
R3[aY k
1
Y k
2
Y bY cY F F F Y j[ (6a)
R3[bY k
1
Y k
2
Y aY cY F F F Y j[ (6b)
F F F
R1[k
1
Y F F F[R2[k
2
Y F F F[ (7)
R3[k
1
Y dp
2
Y aY bY cY F F F Y j[
R3[aY dp
2
Y k
1
R3[bY dp
2
Y k
1
F F F
R3[dp
1
Y k
2
R3[aY k
2
Y dp
1
R3[bY k
2
Y dp
1
F F F
R3[dp
1
Y dp
2
R3[aY dp
2
Y dp
1
R3[bY dp
2
Y dp
1
F F F
R3[k
2
Y dp
1
R3[dp
2
Y k
1
R3[dp
2
Y dp
1
aY bY cY F F F Y j[ (12)
R1[k
1
Y F F F Y k
2
R2[k
2
Y F F F Y k
1
[
R1[k
1
Y F F F Y dp
2
R2[k
2
Y F F F Y k
1
[
R1[k
1
Y F F F Y k
2
R2[k
2
Y F F F Y dp
1
[
R1[k
1
Y F F F Y dp
2
R2[k
2
Y F F F Y dp
1
[
using n tables among which a single table has to contain a collection;
using n 1 tables with or without one collection.
If a collection is used then each attribute of the relationship table can be de privileged. In our
example, four attributes can be privileged according to the data access (via Department, Soft,
Server or Install).
3.6.2. No privileged attribute
The solutions with no privileged attributes use an additional table including or not pointers (if
yes then one to n pointers can be used). The use of an additional table without pointer is the
relational solution.
If we implement our example with an additional table including one pointer, we can choose to
replace one of the three key attributes by a pointer (three solutions). If we want to use two
pointers, we can choose to replace two of the three key attributes by a pointer (three solutions).
Fig. 22 shows the unique solution with three pointers.
3.6.3. One privileged attribute
The solutions privileging one attribute use a collection coming from a grouping of records of
the relational table implementing the n-ary relationship. In our example let us assume that the
department is privileged. According to the data there can be many nesting levels (for an n-ary
Fig. 20. Many-to-many relationship with j properties.
Fig. 21. 3-ary relationship in the relational model.
relationship with j properties, the maximum number being n j 1). Only one nested level is
considered to simplify discussion. Fig. 23 shows that we can nd a triple level for our example (see
Fig. 24).
The equivalent one-nested-level table is described Fig. 25.
Fig. 23. 3-ary relationship with three pointers.
Fig. 22. 3-ary relationship in the relational model.
There are other solutions using pointers instead of key attributes. Fig. 26 shows a solution
replacing each key attribute by a pointer.
3.6.4. Other cases
In the example, the server, the soft or the installation date could also be privileged. For one
solution in the relational model, we have numbered (3n 2 2j) 2
n1
object-relational solu-
tions to implement an n-ary relationship with j properties.
Fig. 27 explains this number for n-ary relationship without properties (j =0). Fig. 28 explains
this number for n-ary relationship with j properties.
The number of solutions for n-ary relationships without properties is
n 2
n1
2
n
n 2
n
= 2
n
[na2 1 n[ = 2
n
[(n 2 2n)a2[ = (3n 2) 2
n1
X (I)
Many-to-many relationships without property are indeed particular cases of n-ary ones (n =2), we
nd (3 2 2) 2
1
= 16.
The number of solutions for n-ary relationships with j properties is
n 2
n1
2n (n j) 2
n
= 2
n1
[n 2 2n 2j[ = (3n 2 2j) 2
n1
X (J)
Many-to-many relationships with properties are indeed particular cases of n-ary ones (n =2), we
nd the same result as in Table 4: (3 2 2 2j) 2
1
= 16 4j.
4. Guidelines
This Section proposes some guidelines for choosing among the object-relational alternatives
described in Section 3. See Table 5.
Fig. 24. 3-ary relationship with a triple nested level.
5. Example
This Section contains an example explaining the translation from an UML diagram (here
created with Rational Rose) to an Oracle8 object-relational database schema (see Fig. 29).
This class diagram contains four relationships. Three of them are one-to-many: own,
subscribe and InternetConnexion, one is a many-to-many relationship (provide). Let us
consider own and InternetConnexion: solution (2) is chosen by adding two pointers in the
object-relational table PhoneLine, respectively, referring to Subscriber and Internet. For
own we assume that data access will mainly be done via the subscriber, so solution (3) is
chosen, which uses a collection in table Subscriber. This collection contains the data relating to
mobile phones for each subscriber. Solution (4) is chosen: the relationship provide is made by
means of an additional table containing two pointers, respectively, referring to Internet and
Provider.
Fig. 25. 3-ary relationship with a single nested level.
Fig. 26. 3-ary relationship with a single nested level and pointers.
The Oracle8 script to create types and tables is the following.
CREATE TYPE mobile_type AS OBJECT
(mobileNumber VARCHAR2(20), price NUMBER(6,2))
/
CREATE TYPE mobiles_type AS TABLE OF mobile_type
/
CREATE TYPE subscriber_type AS OBJECT
(subscriberNumber VARCHAR2(20), subscriberName VARCHAR2(30),
subscriberAddress VARCHAR2(50), mobiles mobiles_type)
/
CREATE TYPE internet_type AS OBJECT
(option VARCHAR2(5), pricePerMonth NUMBER(5,2),
additionalHour NUMBER(4,2))
/
CREATE TYPE phoneLine_type AS OBJECT
Fig. 27. Solutions for n-ary relationship without property.
(lineNumber VARCHAR2(20), localUnits NUMBER(8,2),
otherUnits NUMBER(10,2), baudRate NUMBER(10,2),
subscribe REF subscriber_type, connexion REF internet_type)
/
CREATE TYPE provider_type AS OBJECT
(URL VARCHAR2(200), providerName VARCHAR2(30),
manager VARCHAR2(30))
/
CREATE TYPE provide_type AS OBJECT
(firstContact DATE, endContract DATE,
connexion REF internet_type, provide REF provider_type)
/
CREATE TABLE Subscriber OF subscriber_type
(CONSTRAINT pk_subscriber PRIMARY KEY(subscriberNumber))
Fig. 28. Solutions for n-ary relationship with j properties.
NESTED TABLE mobiles STORE AS tabmobiles;
CREATE TABLE PhoneLine OF phoneLine_type
(CONSTRAINT pk_phoneLine PRIMARY KEY(lineNumber),
CONSTRAINT minimum_cardinality_subscribe subscribe NOT NULL);
CREATE TABLE Internet OF internet_type
(CONSTRAINT pk_internet PRIMARY KEY(option));
CREATE TABLE Provider OF provider_type
(CONSTRAINT pk_provider PRIMARY KEY(URL));
CREATE TABLE Historical OF provide_type
(CONSTRAINT existence_internet connexion NOT NULL,
CONSTRAINT existence_provider provide NOT NULL);
6. Conclusion
Contrary to the relational model, the object-relational one has no mathematical theory. Col-
lections does not meet the rst normal form and can be used for implementing semantic rela-
tionships with or without pointers Technology has so far provided no formal guidelines for the
Table 5
Guidelines
Relationship Object-relational alternatives
One-to-one Solutions (2), (4) enable to avoid declaring foreign key attributes and provides implicit join in queries.
For a given schema, one of this solution is available : the pointer must be in the table coming from an
entity or class having 0 as minimum cardinality ratio
Solutions (6)(8) avoid declaring foreign key attributes and provides implicit join in queries but inverse
references must be managed after each insert and delete instruction
Solutions (10)(12) provide an easy evolution of the database if cardinality ratios change
One-to-many Solution (2) enable to avoid declaring foreign key attributes and provides implicit join in queries
Solutions (3), (4) look like hierarchical relationships (redundancy can exist) and privilege data access
from a given table
Solutions (5)(8) privilege data access from a table
Solutions (10)(12) provide an easy evolution of the database if cardinality ratios change
Many-to-many Solutions (2)(4) provide implicit join in queries and facilitate database evolution if cardinality ratios
change
Solutions (5), (6) privilege data access from a given table
Solutions (7)(12) privilege data access from a given table and enable to avoid declaring foreign key
attributes
Solutions (13)(16) privilege data access from a table and inverse references must be managed after
each insert and delete instruction
N-ary Solutions using n 1 tables with pointer attributes and without collection enable to avoid declaring
foreign key attributes and provides implicit join in queries
Solutions with collections privilege data access from a given table
optimal place to use collections and pointers. There is a great need for tools and surveys providing
easy support of non-rst normal form structures and enabling developers to become more ex-
perienced in dealing with them. As the SQL language required for supporting non-rst normal
form structures is more complex, it is up to each designer to determine whether they want to
implement these structures. Collections should model relationships when there are no strong
integrity constraints and when there is a particular data access (via a separate relation). Pointers
can replace foreign key attributes if integrity constraints can be supported by the DBMS on this
kind of attribute.
It is very dicult to assess the impact of the dierent modeling alternatives. It essentially de-
pends on the DBMS used. In Oracle8, varray values are typically stored inline with respect to the
master row, which brings the advantage of direct performance, because the varray values are
always accessed simultaneously with the master record. Nested tables are similar to clustered
tables though they are not implemented in the same manner. A nested table is basically an ad-
ditional relational table. It is not stored inline with the master table as a clustered table is.
Therefore, nested tables inherently oer no performance benet. However, full scanning of a table
containing a varray involves scanning the contents of the varray, while querying a table that
contains a nested table would not require scanning the nested table itself. Collections can provide
better performance than a standard relational database, but require more complex queries for
data retrieving.
Table 6 lists up the dierent solutions we have numbered.
Let us consider a simple database example using three tables associated with one one-to-many
relationship and one many-to-many relationship with two properties. If integrity constraints are
not considered and according to the previous table, two solutions are oered for a relational
database and 384 for an object-relational one (16 16 (4 2)). Moreover the solutions based
on multiple nesting levels have not been taken into account.
Fig. 29. UML diagram.
For each kind of relationship (one-to-one, one-to-many, many-to-many and n-ary) there is an
analogous and symmetrical solution (analogous because this solution can be applied to each kind
of relationship, symmetrical because no attribute and no table are privileged for particular data
access). This universal solution consists in using an additional table to link one (or n) table(s)
without a collection and using only pointers to provide these links. Table 7 shows the universal
solution for each kind of relationship.
We have seen in Section 2 that this solution facilitates queries via implicit joints. There is no
notable diculty in inserting, updating or deleting object via pointers. Moreover the universal
solution facilitates the evolution of the database because no structure modication of tables is
required if a given relationship must be changed (e.g., from one-to-many to many-to-many and so
on). Table 8 lists up the advantages and drawbacks of this universal solution.
Table 8
Universal solution
Advantages Drawbacks
Queries facilitation (navigation via pointers) Increase the number of tables
Easy evolution of the database structure (change
of cardinality constraints)
Triggers variables (:OLD OLD.x and :NEW NEW.x) do not support REF REF attributes
(Oracle8)
It is possible to declare NOT NULL NOT NULL constraints
upon REF REF attributes (Oracle8). The consequence
is the ability to guarantee the consistence of
minimum cardinalities
It is not possible to declare UNIQUE UNIQUE and PRIMARY KEY PRIMARY KEY constraints upon
REF REF attributes (Oracle8). The consequence is (i) the diculty in guaranteing
the consistence of maximum cardinalities and (ii) the lack of performance
for large databases
Table 6
Number of solutions
Relationship Relational model Object-relational model
One-to-one 4 12
One-to-many 2 16
Many-to-many without property 1 16
Many-to-many with j properties 1 16 4j
N-ary without property 1 (3n 2) 2
n1
N-ary with j properties 1 (3n 2 2j) 2
n1
Table 7
Solutions for the universal solution
Relationship Object-relational model
One-to-one Solution (12)
One-to-many Solution (12)
Many-to-many Solution (4)
N-ary with j properties Rn 1[dp
1
Y dp
2
Y F F F Y dp
n
Y aY bY F F F Y j[
Acknowledgements
The author wishes to thank Evelyne Cabanis and Chantal Vadon, IUT B. The assistance of
Jean-Marie Mizstela Oracle is gratefully acknowledged. I would also like to thank anonymous
referees for theirs comments on an earlier version of this paper.
References
[1] ANSI/X3.135-1992, Database Language SQL.
[2] M. Atkinson, F. Bancilhon, D. de Witt, K. Dittrich, K. Ditttrich, D. Maier, S. Zdonik, The object-oriented database manifesto,
in: Proceedings of the First International Conference on Deductive and Object-Oriented Databases, Elsevier, New York, 1989.
[3] D. Beech, Collections of objects in SQL3, in: Proceedings of VLDB93.
[4] C. Beeri, P.A. Bernstein, Computational problems related to the design of normal form relational schema, ACM TODS 4 (1)
(1979).
[5] S. Bobrowski, Oracle8 Architecture, Oracle Press, 1997.
[6] C.J. Bontempo, C.M. Saracco, Supporting objects in a DBMS, InfoDB 7 (2) (1993).
[7] R.G.G. Cattell, Object Databases: The ODMG-93 Standard, Morgan Kaufman, Los Altos, CA, 1993.
[8] D. Chamberlin, Using the new DB2: IBMs Object-Relational Database System, Morgan Kaufman, Los Altos, CA, 1996.
[9] E.F. Codd, A relational model for large shared data banks, Commun. ACM 13 (6) (1970).
[10] E.F. Codd, Extending the relational model to capture more meaning, ACM TODS 4 (4) (1979).
[11] C.J. Date, H. Darwen, Foundation for Object/Relational Databases The Third Manifesto, Addison-Wesley, Reading, MA,
1998.
[12] P. Dorsey, J.R. Hudicka, Oracle8 Design Using UML Object Modeling, Osborne/Mc Graw-Hill, New York, 1999.
[13] G. Gardarin, Translating relational to object databases, Ingenierie des systemes d'information 2(3), Hermes, 1994.
[14] S. Grimes, Modeling object relational databases, Object-Relational Database Summit (http://www.dbsummit/or/grimes.html,
1998).
[15] S. Grimes, Object Relational Reality Check, Database Programming and Design on line (http://www.dbpd.com/9807feat.htm,
1998).
[16] ISO/IEC 9075:1992, Database Language SQL.
[17] W. Kim, Bringing object relational down to earth, Database Programming and Design on line (http://www.dbpd.com/
9707kim.htm, 1997).
[18] W. Kim, Object-oriented database systems: promises, reality and the future, in: Proceedings of VLDB93.
[19] G. Lohman, B. Lindsay, H. Pirahesh, K. Schiefer, Extension to starbust: object types functions and rules, Commun. ACM 34 (10)
(1991).
[20] A. Makinouchi, A consideration of normal form of not necessarily-normalized relation in the relational model of data, in:
Proceedings of VLDB77.
[21] W.Y. Mok, Y. Ng, D.W. Embley, A normal form for precisely characterizing redundancy in nested relations, ACM TODS 21 (1)
(1996).
[22] M.A. Roth, H.F. Korth, A. Schilberschatz, Extended algebra and calculus for nested relational databases, ACM TODS 13 (4)
(1988).
[23] C.M. Saracco, Universal Database Management A Guide to Object/Relational Technology, Morgan Kaufman, Los Altos, CA,
1998.
[24] C. Soutou, Relational database reverse engineering extraction of cardinality constraints, in: Data and Knowledge Engineering,
vol. 28, no. 2, Elsevier, North-Holland, 1998.
[25] M. Stonebraker, Inclusion of new types in relational database system, in: Readings in Database Systems, Morgan Kaufman, Los
Altos, CA, 1995.
[26] M. Stonebraker, D. Moore, Object Relational DBMSs, the Next Great Wave, Morgan Kaufman, Los Altos, CA, 1996.
[27] M. Stonebraker, G. Kemnitz, The POSTGRES next generation database management system, Commun. ACM 34 (11)
(1991).
[28] Z. Tari, J. Stokes, S. Spaccapietra, Object normal forms and dependency constraints for object-oriented schemata, ACM TODS
22 (4) (1997).
[29] P. Valduriez, Objets complexes dans les systemes de bases de donnees relationnnelles, Techniques et science informatique 6(5)
Hermes, 1987.
Christian Soutou is an Assistant Professor of Information Systems at the Institute of Technology, Department
of Telecommunications and Network Engineering, University Toulouse Le Mirail, France. He received his
Ph.D. in 1994 from the University Paul Sabatier Toulouse III. In 1995, he joined the ICARE team directed
by Professor Jean-Jacques Mercier. His research interests include object-relational databases, reverse engi-
neering and wireless databases. He is the author of the book Objet-relationnel sous Oracle8 in French,
published in March 1999 (Eyrolles Ed. Paris).

ModelingRelationships ORDB

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ModelingRelationships ORDB

Caricato da

Copyright:

Formati disponibili

Modeling relationships in object-relational databases

Potrebbero piacerti anche