Database Modeling & Design Fourth Edition- P22 pdf

@Spy
92 CHAPTER 5 Transforming the Conceptual Data Model to SQL
The many-to-many relationship is shown as optional (Figure 5.3c)
and results in a new table; it could also be defined as mandatory (using
the word “must” instead of “may”); both cases have the foreign keys
defined as “not null.” In many-to-many relationships, foreign key con-
straints on delete and update must always be cascade, because each
entry in the SQL table depends on the current value or existence of the
referenced primary key.
5.1.3 Ternary and n-ary Relationships
An n-ary relationship has (n + 1) possible variations of connectivity: all n
sides with connectivity “one;” (n – 1) sides with connectivity “one,” and
one side with connectivity “many;” (n – 2) sides with connectivity “one”
and two sides with “many;” and so on until all sides are “many.”
The four possible varieties of a ternary relationship are shown in Fig-
ure 5.5 for the ER model and Figure 5.6 for UML. All variations are trans-
formed by creating an SQL table containing the primary keys of all enti-
ties; however, in each case the meaning of the keys is different. When all
three relationships are “one” (Figure 5.5a), the resulting SQL table con-
sists of three possible distinct keys. This arrangement represents the fact
that three FDs are needed to describe this relationship. The optionality
constraint is not used here because all n entities must participate in
every instance of the relationship to satisfy the FD constraints. (See
Chapter 6 for more discussion of functional dependencies.)
In general the number of entities with connectivity “one” deter-
mines the lower bound on the number of FDs. Thus, in Figure 5.3b,
which is one-to-one-to-many, there are two FDs; in Figure 5.5c, which is
one-to-many-to-many, there is only one FD. When all relationships are
“many” (Figure 5.5d), the relationship table is all one composite key,
unless the relationship has its own attributes. In that case the key is the
composite of all three keys from the three associated entities.

Foreign key constraints on delete and update for ternary relation-
ships transformed to SQL tables must always be cascade, because each
entry in the SQL table depends on the current value of, or existence of,
the referenced primary key.

Teorey.book Page 92 Saturday, July 16, 2005 12:57 PM
@Spy
5.1 Transformation Rules and SQL Constructs 93
Figure 5.5 ER model: ternary and n-ary relationships
Technician
Notebook
Project
1
1
1
uses-
notebook
Functional dependencies
uses_notebook
emp_id project_name notebook_no
35
35
42
42
81
93
93
alpha
gamma
delta

epsilon
gamma
alpha
beta
5001
2008
1004
3005
1007
1009
5001
A technician uses exactly
one notebook for each project.
Each notebook belongs to one
technician for each project. Note
that a technician may still work
on many projects and maintain
different notebooks for different
projects.
create table (emp_id char(10),technician
create table (project_name char(20),project
create table (notebook_no integer,notebook
create table (emp_id char(10),uses_notebook
primary key (emp_id));
primary key (project_name));
primary key (notebook_no));
project_name char(20),
notebook_no integer not null,
primary key (emp_id, project_name),
foreign key (emp_id) references

on delete cascade on update cascade,
foreign key (project_name) references
on delete cascade on update cascade,
foreign key (notebook_no) references
on delete cascade on update cascade,
unique (emp_id, notebook_no),
unique (project_name, notebook_no));
technician
project
notebook
(a) One-to-one-to-one ternary relationship
emp_id, project_name notebook_no
emp_id, notebook_no project_name
project_name, notebook_no emp_id
→
→
→
Teorey.book Page 93 Saturday, July 16, 2005 12:57 PM
@Spy
94 CHAPTER 5 Transforming the Conceptual Data Model to SQL
Figure 5.5 (continued)
Employee
LocationProject
N
1
1
assigned-
to
Functional dependencies
assigned_to

emp_id project_name loc_name
48101
48101
20702
20702
51266
51266
76323
forest
ocean
ocean
river
river
ocean
hills
B66
E71
A12
D54
G14
A12
B66
Each employee assigned to a
project works at only one location
for that project, but can be at a
different location for a different
project. At a given location, an
employee works on only one
project. At a particular location,
there can be many employees

assigned to a given project.
create table (emp_id char(10),employee
create table (project_name char(20),project
create table (loc_name char(15),location
create table (emp_id char(10),assigned_to
primary key (emp_id));
emp_name char(20),
primary key (project_name));
primary key (loc_name));
project_name char(20),
loc_name char(15) not null,
primary key (emp_id, project_name),
foreign key (emp_id) references
on delete cascade on update cascade,
foreign key (project_name) references
on delete cascade on update cascade,
foreign key (loc_name) references
on delete cascade on update cascade,
unique (emp_id, loc_name));
employee
project
location
(b) One-to-one-to-many ternary relationships
emp_id, loc_name project_name
emp_id, project_name loc_name
→
→
Teorey.book Page 94 Saturday, July 16, 2005 12:57 PM
@Spy
5.1 Transformation Rules and SQL Constructs 95

Figure 5.5 (continued)
Project
EngineerManager
N
1N
assigned-to
Functional dependency
manages
emp_idproject_name mgr_id
4106
4200
7033
4200
4106
7033
4106
4106
alpha
alpha
bet
a
bet
a
gamma
delta
delta
iota
27
27
32

14
71
55
39
27
Each engineer working on a
particular project has exactly one
manager, but a project can have
many managers and an engineer
may have many managers and
many projects. A manager may
manage several projects.
create table (project_name char(20),project
create table (mgr_id char(10),manager
create table (emp_id char(10),engineer
create table (project_name char(20),manages
primary key (project_name));
primary key (mgr_id));
primary key (emp_id));
mgr_id char(10) not null,
emp_id char(10),
primary key (project_name, emp_id),
foreign key (project_name) references
on delete cascade on update cascade,
foreign key (mgr_id) references
on delete cascade on update cascade,
foreign key (emp_id) references
on delete cascade on update cascade);
project
manager

engineer
(c) One-to-many-to-many ternary relationships
project_name, emp_id mgr_id→
Teorey.book Page 95 Saturday, July 16, 2005 12:57 PM
@Spy
96 CHAPTER 5 Transforming the Conceptual Data Model to SQL
Figure 5.5 (continued)
Employee
ProjectSkill
N
NN
skill-used
Functional dependencies
skill_used
emp_id
project_name
skill_type
101
101
101
101
102
102
102
105
electronics
electronics
algebra
calculus
mechanics

mechanics
algebra
geometry
electronics
electronics
algebra
set theory
mechanics
mechanics
geometry
topology
Employees can use different skills
on any one of many projects, and
each project has many employees
with various skills.
create table (emp_id char(10),employee
create table (skill_type char(15),skill
create table (project_name char(20),project
create table (emp_id char(10),skill_used
primary key (emp_id));
emp_name char(20),
primary key (skill_type));
primary key (project_name));
skill_type char(15),
project_name char(20),
primary key (emp_id, skill_type, project_name),
foreign key (emp_id) references
on delete cascade on update cascade,
foreign key (skill_type) references
on delete cascade on update cascade,

foreign key (project_name) references
on delete cascade on update cascade);
None
employee
skill
project
(d) Many-to-many-to-many ternary relationships
Teorey.book Page 96 Saturday, July 16, 2005 12:57 PM