Object-Relational Mapping

that relates a row in the INSURANCE table with a row in (figure 7). The EMPLOYEE_PROJECT table contains two
the EMPLOYEE table, and there is only one row in the columns: one column with a foreign key to the EMPLOYEE
INSURANCE table for any row in the EMPLOYEE table. This table and one column with a foreign key to the PROJECT
foreign-key column maps to the object model via a refer- table. Thus, join tables with two foreign keys map to rela-
ence in each domain class that refers to the other. tionships of domain classes that have multivalued fields
In a normalized relational schema, relationships in on both sides.
which many rows of one table are related to many rows Embedded. For improved encapsulation, it may be
of another table are represented by join tables, in which useful to model a collection of fields in a domain class as
each row of the join table contains a foreign key to each a separate class. This mapping concept is called embedded,
of the related tables. If multiple rows of an EMPLOYEE because the columns for the embedded class are embed-
table are related to multiple rows of a PROJECT table, a ded in the same table as the mapped domain class.
third table is needed to maintain a normalized schema As shown in figure 8A, an Employee class might con-
tain fields representing a

_{O ne to One Mapping} home address. These are mapped to columns in the Employee Insurance

_{0.. 1 1} EMPLOYEE table. Figure 8B -id : int4 -employee : Employee shows a different mapping -department : Department -carrier : int4

-insurance : Insurance -groupId : int4 ^{for the same schema using} an embedded Address class that is mapped to the same <<table>> <<table>>

_{EMPLOYEE INSURANCE} columns in the same table. Dependent. A common -ID : int4 ^<<FK>> -CARRIER : int4

-DEPARTMENT : int4 -EMPLOYEE : int4 ^{pattern in domain object
-GROUP_ID : int4} models is composition, in
F _{IG 6} which the life cycle of one
collection of instances is
dependent on another. In
the database, the tables
that store the dependent
instances are indistinguish-
able from other tables. The
behavior of the domain
Project model, however, requires
0..*
-employees : Set<Employee> ^{that if the relationship}
from the owning instance
is removed, then the
<<table>> <<table>>
EMPLOYEE PROJECT rows corresponding to
^<<FK>> _{-ID : int4} <<FK>> _{-ID : int4} the dependent instances
should also be removed.

In figure 9, the skills relationship is marked as dependent, and if a Skill is removed from the skills collection of the owning

M any to Many Mapping Employee 0 ..* -projects : Set<Project>

<<table>>

EMPLOYEE_PROJECT -EMPLOYEE_ID -PROJECT_ID