Bryon K. Ehlmann
Department of Computer Science, Southern Illinois University Edwardsville, Edwardsville, IL 62026, USA
Keywords: ODMG Object Model, OODB systems, Constraint management, Object Relations
hip Notation (ORN).
Abstract: The Object Model defined in the ODMG standard for object data management systems (ODMSs) provides
referential integrity support for one-to-one, one-to-many, and many-to-many associations. It does not, how-
ever, provide support that enforces the multiplicities often specified for such associations in UML class dia-
grams, nor does it provide the same level of support for associations that is provided in relational systems
via the SQL references clause. The Object Relationship Notation (ORN) is a declarative scheme that pro-
vides for the specification of enhanced association semantics. These semantics include multiplicities and are
more powerful than those provided by the SQL references clause. This paper describes how ORN can be
added to the ODMG Object Model and discusses algorithms that can be used to support ORN association
semantics in an ODMG-compliant ODMS. The benefits of such support are improved productivity in devel-
oping object database systems and increased system reliability.
An object data management system (ODMS) allows
objects created and manipulated in an object-ori-
ented programming language to be made persistent
and provides traditional database capabilities like
concurrency control and recovery to manage access
to these objects. An object database management
system (ODBMS), one type of ODMS, stores the ob-
jects directly in an object database. An object-to-
database mapping (ODM), another type of ODMS,
stores the objects in another database system repre-
sentation, usually relational (Cattel et al., 2000).
The de facto standard for ODMSs is ODMG 3.0
(Cattel et al., 20
00), which was defined by the Ob-
ject Data Management Group (ODMG) consisting of
representatives from most of the major ODMS ven-
dors. This standard defines an Object Model to be
supported by ODMG-compliant ODMSs. The model
defines the kinds of object semantics that can be
specified to an ODMS. These semantics deal with
how objects can be named and identified and the
properties and behavior of objects. They also deal
with how objects can relate to one another, which is
the focus of this paper.
In addition to supporting generalization-
alization relationships, the Object Model sup-
ports one-to-one, one-to-many, and many-to-many
binary relationships between object types. These are
the non-inheritance, or structural, types of relation-
ships, which are termed associations in the Unified
Modeling Language (UML) (OMG, 2005), . For ex-
ample, a one-to-many association between carpools
and employees can be defined in the Object Model.
A carpool object is defined so that it can reference
many employee objects, and an employee object is
defined so that it can reference at most one carpool.
The Object Model prescribes that the ODMS
tomatically enforce referential integrity for all de-
fined associations. This means that if an object is de-
leted, all references to that object that maintain asso-
ciations involving that object must also be deleted.
This ensures that there are no such references in the
database that lead to nonexistent objects.
What has just been described is the extent of
support for as
sociations in the Object Model. What
is lacking is some additional, easily implementable
support for associations that could significantly im-
prove the productivity of developing object database
systems and the reliability of those systems.
For example, the Object Model, like the rela-
nal model, does not support the specification of
precise multiplicities. Such association constraints
are almost always present in the diagrams used to
model databases—the traditional Entity-Relationship
K. Ehlmann B. (2006).
In Proceedings of the First International Conference on Software and Data Technologies, pages 5-12
DOI: 10.5220/0001312600050012
Diagram (ERD) (Chen, 1976), where multiplicities
are termed cardinality constraints, and the UML
class diagram (OMG, 2005). For example, the mul-
tiplicity for the Employee class in the carpool–
employee association may be given as 2..* in a class
diagram, meaning that a carpool must be related to
two or more employees. Such association semantics,
documented during conceptual database design, are
sometimes lost during logical database design unless
supported by the logical data model, e.g., the Object
Model. If not supported, to survive, they must be
resurrected by the programmer during implementa-
tion and for object databases translated into cardinal-
ity checks on collections and into exception handling
code within relevant create and update methods.
The Object Model also does not support associa-
tion semantics that are equivalent to those supported
in standard relational systems via the
delete clause of the create table statement in SQL
(ANSI, 2003). Such semantics would, for instance,
allow one to declare an association between objects
such that if an object is deleted, all related objects
would be automatically deleted by the ODMS, i.e.,
on delete cascade. For example, if an organiza-
tion in a company were deleted, all subordinate or-
ganizations would be implicitly deleted. Such an as-
sociation semantic is required for an ODMS to pro-
vide support for composite objects.
Object Relationship Notation (ORN) was devel-
oped to allow these kinds of semantics, and others
often relevant to associations, to be better modeled
and more easily implemented in a DBMS (Ehlmann
et al., 1996, 2000, 2002). ORN is a declarative
scheme for describing association semantics that is
based on UML multiplicities.
In this paper we give a brief overview of ORN
and show how the ODMG Object Model can be ex-
tended to include ORN. We also discuss and illus-
trate algorithms that are available and can be used by
an ODMG-compliant ODMS to implement the asso-
ciation semantics as specified by ORN. The exten-
sion is very straightforward, and the algorithms are
relatively simple. The end-result is an enhanced Ob-
ject Model that supports more powerful association
semantics—in fact, more powerful than those sup-
ported by relational systems without having to code
complex constraints and triggers (Ehlmann and Ric-
cardi, 1996). By extending models with ORN and
providing the required mappings between them—
UML class diagram to Object Model to ODMS im-
plementation—we facilitate a model-driven devel-
opment approach and gain its many advantages
(Mellor et al., 2003).
The specific benefits here are a significant im-
provement in the productivity of developing object
database applications and an increase in their reli-
ability. Productivity is improved when translations
from class diagram models into object models are
more direct and when programmers do not have to
develop code to implement association semantics.
Currently, many developers working on many data-
base applications must implement, test, and maintain
custom code for each type of association, often “re-
inventing the wheel.” Reliability is increased when
the ODMS is responsible for enforcing association
semantics. Currently, developers sometimes fail to
enforce these semantics or inevitably introduce er-
rors into database applications when they do.
The remainder of this paper is organized as fol-
lows: section 2 gives a brief overview of ORN and
related work, section 3 shows how the ODMG Ob-
ject Model can be extended with the ORN syntax
and describes ORN semantics in terms of this model,
section 4 discusses and illustrates algorithms that
can be used to implement ORN semantics in an
ODMS that is based on the extended Object Model,
and section 5 provides concluding remarks. A com-
plete set of ORN-implementing algorithms is avail-
able on the author’s website (Ehlmann, 2006).
ORN describes association semantics at both the
conceptual, i.e., data modeling, and logical, i.e., data
definition, levels of database development, and can
be compared to other declarative schemes.
For data modeling, ORN has been integrated into
ERDs and UML class diagrams (Ehlmann and Yu,
2002). ORN extends a class diagram by allowing
binding symbols to be given with multiplicity nota-
tions. The bindings indicate what should happen
when links between related objects are destroyed, ei-
ther implicitly because of object deletions or explic-
itly. They indicate, for instance, what action the
DBMS should take when destroying a link would
violate the multiplicity at one end of an association.
The binding symbols (or the lack of them) provide
important semantics about the relative strength of
linkage between related objects and define the scope
of complex objects. For example, the association be-
tween a carpool, a complex object, and its riders can
be specified in an ORN-extended class diagram to
indicate that if the number of riders falls below two,
either because an employee leaves the company (an
employee object is deleted) or just leaves the carpool
(a link between an employee and a carpool is de-
stroyed), the carpool should be deleted.
For database definition, ORN has been imple-
mented within the Object Database Definition Lan-
guage (ODDL). ODDL is a language used to define
classes, attributes, and relationships to a prototype
ODMS named Object Relater Plus (OR+) (Ehlmann
and Riccardi, 1997). OR+ closely parallels ODMG
and is built on top of Object Store (Progress Soft-
ware, 2006). The integration of ORN into ODDL al-
lows a direct translation of association semantics
from an ORN-extended class diagram into the data-
base definition language and enables these semantics
to be automatically maintained by the DBMS. Using
ORN, the semantics for an association between em-
ployees and carpools as previously described can be
both modeled and implemented by the notation
|~X~<2..*-to-0..1>. No programming is needed.
In Ehlmann and Riccardi (1996), the power of
ORN in describing association semantics is com-
pared to that of other declarative notations proposed
for various object models and to that of the
clause of SQL. The comparison reveals that
the most unique aspect of ORN, and what accounts
for its ability to specify a larger variety of associa-
tion types, is that it provides for the enforcement of
upper and lower bound multiplicities and allows de-
lete propagation to be based on these multiplicities.
It also provides a declarative scheme at a conceptual
level of abstraction that is independent of database
type, object or relational. ORN can also be com-
pared to extensions to the ER model that others have
suggested to specify or enforce association seman-
tics, or structural integrity constraints (Balaban and
Shoval, 2002) (Bouzeghoub and Metais, 1991)
(Lazarivic and Misic, 1991). These extensions, how-
ever, are more procedural in nature.
3.1 Associations in ODL
In the ODMG Object Definition Language (ODL),
which defines the ODMG Object Model, an associa-
tion is defined by declaring a relationship traversal
path for each end of the association. A traversal path
provides a means for an object of one class to refer-
ence and access the related objects of a target class
(which is the same class in a recursive relationship).
Access to many target class objects requires the tra-
versal path declaration to include an appropriate
collection type, usually a set or list, that can contain
Figure 1: Class diagram for employee–carpool association.
Figure 2: ODL for employee–carpool association.
references of target class type. Access to at most one
target class object requires the declaration to include
a reference of target class type. A traversal path dec-
laration must also include the name of its inverse tra-
versal path. For example, the one-to-many relation-
ship between carpools and employees, discussed ear-
lier and modeled by the class diagram in Fig. 1,
would be declared in ODL as shown in Fig. 2. The
2..* multiplicity given in the class diagram must be
implemented by application code.
3.2 Adding ORN Syntax
Adding ORN to the Object Model is relatively
straightforward. Essentially, ODL is extended to al-
low an
<association> to be given for each declared
relationship. The syntax for an
<association>, which
is the syntax for ORN, is given in Fig. 3, and the
ORN-extended ODL syntax is given in Fig. 4.
To illustrate the syntax and semantics of ORN in
the context of the Object Model, a database contain-
ing the employee–carpool association as well as two
other associations is modeled by the ORN-extended
class diagram given in Fig. 5. In such a diagram, the
ORN bindings for a class (or role) in an association
are given as stereotype icons at the association end
corresponding to that class (or role). When no bind-
ing symbols are given for an association end (or
role), default bindings are assumed, the semantics of
which will be defined later.
The database modeled in Fig. 5 is implemented
by the ORN-extended ODL given in Fig. 6.
If an
<association> is not given for a relationship
in ODL (see Fig. 4), the default
<association> is
<0..1-to-0..1> for a one-to-one relationship, <0..1-to-
*> for a one-to-many, and <*-to-*> for a many-to-
Figure 3: ORN syntax diagrams.
Figure 4: Updated BNF for a relationship in ODL.
Figure 6: ODL for class diagram shown in Fig. 5.
multiplicity given for a traversal path in an <asso-
implies “many,” then the type of that tra-
versal path must be a collection.
The last issue to address in extending ODL is as-
sociation inheritance. In the Object Model, a rela-
tionship can be inherited by a class via the
relationship. For example, the declaration
SalesPerson extends Employee { ... } would mean
that the
SalesPerson class inherits the attributes, re-
lationships, and behavior of the
Employee class.
Thus, the
carpool traversal path as declared in the
Employee class in Fig. 6 would be inherited by the
SalesPerson class, allowing sales people to join car-
pools. When a relationship is inherited by a class, all
of the semantics defined by its
<association>, given
or defaulted, are also inherited.
Figure 5: ORN-extended UML class diagram.
many. These defaults give relationships the same
semantics as they have in the existing Object Model.
And, of course, the semantics of all <associa-
s defined in the ODL—defaulted, given, or in-
herited—must be maintained by the ODMS.
<association> given for a relationship need
only to be given for one of the traversal paths. If
given for both traversal paths, the
must be inverses of each other. For example, an
<association>, if given for riders in Fig. 6, must be
given as
<0..1-to-2..*> |~X~.
3.3 ORN Semantics in ODL Context
The semantics of the <multiplicity>s in an <associa-
are identical to those of the multiplicities de-
fined in UML (OMG, 2005). The semantics of the
<binding>s are given in Table 1.
When an <association> is given for a traversal
tp in class C, the multiplicity and binding given
after the
-to- apply to tp and to the target class, the
multiplicity and binding given before the
-to- apply
to the inverse
tp and to class C. For example, in Fig.
6, the multiplicity
0..1 and default bindings apply to
the traversal path
carpool and the target class Car-
, and the multiplicity 2..* and binding |~X~ apply
to the traversal path
riders and class Employee. If the
Previous papers have described ORN semantics
conceptually in terms of ER and class diagrams, e.g.
Ehlmann et al. (2002). The reader may review these
papers for a more detailed discussion of ORN. Here,
we focus more on describing ORN semantics in
terms of the Object Model, or ODL. Thus, instead of
Table 1: ORN binding semantics for the Object Model.
“association links” being conceptually “created” and
“destroyed,” “relationship references” (or, alterna-
tively, “traversal path references”) are “formed” and
“dropped.” Dropping a relationship or traversal path
reference also means dropping the corresponding in-
verse reference (in the inverse traversal path). Also,
bindings and multiplicities are now associated with
traversal paths as well as with the related classes.
This is convenient for identifying bindings and mul-
tiplicities in recursive relationships since the subject
class and related class, now called the “target class,”
are the same. Traverse path names can be equated to
role names given in UML class diagrams. In Table
1, traversal path names
and tp
are also role
names in the class diagram for relationship
As indicated in Table 1, association semantics
are derived from multiplicity semantics and the se-
mantics of the given bindings. For example, in the
|~X~<2..*-to-0..1> association between employees
and carpools, the
|~ symbol in the <binding> for the
Employee class means (from Table 1): on delete of
an Employee object, a
carpool reference (see Fig. 6)
can always be implicitly dropped, and the target
Carpool object is implicitly deleted when dropping
this reference violates the multiplicity
2..*. The X~
symbol means: a
carpool reference can always be
explicitly dropped, and the target Carpool object is
implicitly deleted when dropping this reference vio-
lates the multiplicity
2..*. The multiplicity 2..* is vio-
lated when a reference to one of just two employees
in a carpool, i.e., one of just two references in the set
riders, is dropped. The default <binding> for the Car-
pool class means (again, from Table 1): on delete of
a Carpool object, a reference in
riders (see Fig. 6)
can be implicitly dropped provided this does not vio-
late the multiplicity
0..1, and a reference in riders
can be explicitly dropped provided this does not vio-
late the multiplicity
0..1. A 0..1 multiplicity is never
violated by dropping a reference in
riders (or a car-
pool reference for that matter).
Below are more of the association semantics that
are modeled in Fig. 5 and implemented in Fig. 6.
They are described both conceptually and, within
brackets, in terms of Object Model.
If an employee [Employee object] is deleted, the
link to the employee’s organization is implicitly
destroyed [the object’s
organization reference to
its target Organization object is implicitly
dropped] (default binding and
* multiplicity).
If an organization [Organization object] is de-
leted, all descendant organizations [Organization
objects recursively referenced via
children] are
implicitly deleted (
' binding); however, an or-
ganization is not deleted if it has any employees
workers references any Employee objects]
(default binding and
1 multiplicity).
If a link between organizations is destroyed [if a
children reference (or its inverse parent refer-
ence) is dropped], the child organization and all
descendant organizations [Organization objects
recursively referenced via
children] are implicitly
deleted (
' binding); however, again, an organiza-
tion is not deleted if it has any employees (de-
fault binding and
1 multiplicity).
The implementation of ORN semantics in an
ODMG-compliant ODMS is described by giving the
algorithms required to create and delete objects and
form and drop relationship references. These opera-
tions become complex object operations in the con-
text of ORN. This means they may no longer in-
volve just one object or relationship reference but
may involve many objects, relationships, and rela-
tionship references in the scope of a complex object.
In Ehlmann (2006), we give the algorithms for
these operations by providing all related pseu-
docode, with commentary, for the
and Object::delete() methods, which are
associated with an object, and the
C::form_tp() and
C::drop_tp() methods, which are associated with a
declared traversal path
tp in a user-declared class C.
These methods are defined as part of the Object
Model (see Chapter 2 of Cattel and Douglas(2000)).
In this section, due to space constraints, we dis-
cuss these algorithms in general and illustrate them
by giving the algorithm for just the
method. The pseudocode shown in this section is
about one quarter of that given in Ehlmann (2006).
The algorithms have been developed by reverse
engineering the code for implementing ORN within
OR+. This is the same code executed when one uses
the ORN Simulation, a web-based, prototype model-
ing tool (Ehlmann, 2000). Thus, the algorithms are
well-tested but have a slightly different wrapping.
Their implementation of ORN semantics is un-
ambiguous in the presence of association cycles as
long as
<association>s do not contain a |– binding
for just one end of the association. By unambiguous,
we mean that the results of a complex object opera-
tion are independent of the order in which traversal
paths and the references in these paths are processed.
This property of ORN is discussed in detail and
proven in Ehlmann et al. (2002).
As stated in the introduction, the algorithms are
relatively simple; however, they depend on the
ODMS implementation supporting a nested transac-
tion capability. Nested transactions are needed to
implement the semantics of the
' (prime) binding and
are desirable so that the system can check multiplic-
ity violations at the end of a complex object opera-
tion, undoing the operation upon any exception and
thus making the complex object operation atomic.
The Object Model defines a Transaction Model,
which does not provide nested transactions. So, be-
fore giving the algorithms for the complex object
operations in Ehlmann (2006), we extend the Trans-
action Model to support nested transactions, at least
for the purpose of implementing the ODMS. We as-
sume such support for nested transactions and give
algorithms for transaction methods, focusing on the
actions required to support ORN semantics.
All methods are assumed to execute in the con-
text of a opened database
d, and methods new(), de-
lete(), form_tp ()
, and drop_tp ()
are assumed to exe-
cute within the scope of a user-defined transaction.
The pseudocode that expresses the algorithms is
some mixture of ODL, C++, Java, and English. We
have tried to stick as close as possible to the conven-
tions of ODL. Indention indicates control structure,
with appropriate
end’s often used to terminate com-
pound statements. The
try...handle...end handle con-
trol structure for exception handling is similar to
try {...} catch {...}. Methods for a class are in-
troduced with a header of the form
Method <vari-
.<method name>( ... ), where the <variable> is
used in the body of the method to refer to the object
on which the method is invoked, i.e., the implicit pa-
rameter and
this object in C++ and Java. A <method
name> begins with an underscore if it is to be in-
voked only by the ODMS implementation.
The algorithms are expressed using the variables
defined in Table 1.
Fig. 7 gives the
delete() method and two methods
that it uses,
_try_delete() and _enforce_binding().
The given
delete() replaces the primitive delete()
method as currently defined in the Object Model.
The remainder of this section briefly explains the
pseudocode in Fig. 7. For a more detailed explana-
tion and for the pseudocode of all methods invoked
by the
delete() algorithm, see Ehlmann (2006).
Figure 7: Method delete() in interface Object.
The algorithm for delete() uses these functions:
Type(o) – the type, or class, of object o, which is the
most specific type of
o in any type hierarchy.
LbM(tp) – the lower bound multiplicity for tp in the
<association> for the relationship represented by
traversal path
ImpB(tp) – the implicit destructibility binding for tp
(minus any
| symbol) in the <association> for the
relationship represented by traversal path
Inverse(tp) – the inverse traversal path of tp.
Refs( – the number of references in, which,
tp is a collection, is the cardinality of the col-
lection, i.e., and, if tp is a refer-
ence, is
0 if nil and 1 if not.
delete() method provides a nested transac-
tion that embeds the complex object operation, per-
mitting its effects on the database to be undone if an
exception occurs.
_try_delete() method is an indirectly recur-
sive method that may result in the implicit deletion
of many objects that are related directly or indirectly
to the object upon which it is invoked, designated
here as
a. Its invocation on an object must be dy-
namically bound to the method on the class repre-
senting the object’s most specific type. This ensures
_try_delete() processes all traversal path in-
stances involving the object.
The method first checks that object
a has not al-
ready been marked for deletion by invoking the
_deleted() method on the current transaction. If it
_try_delete() simply exits. If not, it marks object
a for deletion by invoking _mark_for_deletion().
The outer for each loop traverses every traversal
defined in (or inherited by) class A. For each
such path in object
a, the inner for each traverses all
references in the traversal path. The purpose here is
to attempt to implicitly drop each reference to a tar-
get object
b (including the inverse reference to a) so
that object
a can be deleted. The code first drops
each such reference by invoking the
method on a, which drops
’s reference to b and
’s reference to a. It
then invokes the method
_enforce_binding() on the
target object
b to enforce the implicit destructibility
ImpB(tp )
for the inverse traversal path tp
The last step of
_try_delete() actually deletes the
object but only if none of the
_enforce_binding() in-
vocations raise an exception.
The _enforce_binding() method is assumed for
simplicity to be defined in the interface
Object. The
method for one class in a relationship must be acces-
sible to the other class. The method enforces the de-
structibility binding semantics specified in Table 1.
b denotes the implicit parameter and tp
notes the explicit parameter since
is invoked on a target object to enforce the binding
for the inverse traversal path in that target object. It
is invoked after a reference to target object
b and its
inverse reference in the traversal path
have been
dropped by the caller. The
case statement executes
the appropriate code for the given
binding. The
_check_path_at_commit() is invoked to en-
sure that a lower bound constraint is rechecked at the
end of the complex object operation, i.e., within
commit() of the current, nested transaction.
In this paper, we have proposed adding ORN to the
ODMG Object Model and have referenced, illus-
trated, and discussed algorithms for implementing
ORN semantics in an ODMS. The shortcomings of
our proposal are that the Object Model is made
slightly more complex and ODMS implementations
must include a nested transaction capability. Despite
these shortcomings and regardless of whether or not
ORN is added to the ODMG standard, we believe
that vendors should strongly consider including
ORN as an extended feature to their ODMSs. We
conclude by summarizing the reasons:
ORN is a simple notation that allows the data-
base developer to specify a variety of association
semantics, which define the scopes of complex
and composite objects.
The extended ODL would facilitate a straight-
forward mapping of association semantics from a
conceptual database model, expressed as an
ORN-extended UML class diagram, to the logi-
cal database model, expressed in the ODL.
The ODMS would provide the same support for
associations that is provided by relational
DBMSs via the
SQL references clause plus sup-
port even more powerful association semantics.
If no
<association> is given for a traversal path,
the default
<association> corresponds to current
system capabilities. Thus, adding ORN is a pure
extension requiring no changes to the underlying
Object Model capabilities.
The implementation of this extension is rela-
tively simple as shown by the algorithms we
have made available and their implementation in
The benefits are increased database development
productivity and improved database integrity as
much less code needs to be developed and main-
tained by database application developers.
This work was partially supported by the NSF co-
operative agreement HRD-9707076.
Balaban, M. and Shoval, P., 2002. MEER – A EER model
enhanced with structure methods. Information Sys-
tems, 27 (4), 245-275.
Bouzeghoub, M. and Metais, E., 1991. Semantic modeling
and object oriented databases. In Proc. 17
Int’l VLDB
Conference, Barcelona, Spain. 3-14.
Cattel, R.G.G., Barry, D.K., Berler, M., Eastman, J., Jor-
dan, D., Russell, C., Schadow, O, Stanienda, T., and
Velez, F., 2000. The Object Database Standard:
ODMG 3.0. San Mateo, CA: Morgan Kaufmann.
Chen, P.P., 1976. The entity-relationship model: towards a
unified view of data. ACM Transactions on Database
Systems, 1(1), 1-36.
ANSI, 2003. Information technology - Database lan-
guages - SQL, Parts 1-4, New York, NY: American
National Standards Institute (ANSI). Available from:
Ehlmann, B.K. and Riccardi, G.A., 1996. A comparison of
ORN to other declarative schemes for specifying rela-
tionship semantics. Information and Software Tech-
nology, 38 (7), 455-465.
Ehlmann, B.K. and Riccardi, G.A., 1997. Object Relater
Plus: A Practical Tool for Developing Enhanced Ob-
ject Databases. In Proc. 13
Int’l Conference on Data
Engineering, Birmingham, England. 412-421.
Ehlmann, B.K., Rishe, N., and Shi, J., 2000. The formal
specification of ORN semantics. Information and
Software Technology, 42 (3), 159-170.
Ehlmann, B.K., Riccardi, G.A., Rishe, N., and Shi, J.,
2002. Specifying and enforcing association semantics
via ORN in the presence of association cycles, IEEE
Transactions on Knowledge and Data Engineering, 14
(6), 1249-1257.
Ehlmann, B.K. and Yu, X., 2002. Extending UML class
diagrams to capture additional association semantics.
In Proc. 20
IASTED Int’l Conf. on Applied Informat-
ics, Innsbruck, Austria. 395-401.
Ehlmann, B.K., 2002. A data modeling tool where asso-
ciations come alive. In Proc. 21
IASTED Int’l Conf.
on Modelling, Identification, and Control, Innsbruck,
Austria. 66-72. Available at
Ehlmann, B.K., 2006. Algorithms for the implementation
of ORN in an ODMG-compliant ODMS. Available
Mellor, S.J., Clark, A.N., and Futagami, T., 2003. Guest
editor’s introduction: Model-Driven Development.
IEEE Software, 20 (5), 19-25.
Lazarevic, B., Misic, V., 1991. Extending the entity-
relationship model to capture dynamic behavior.
European Journal of Information Systems, 1 (2), 95-
Progress Software, 2006. ObjectStore Interprise. Bedford,
MA: Progress Software. Available from:
OMG, 2005. Unified Modeling Language (UML) Specifi-
cation. Version 2.0. Object Management Group
(OMG). Available from: