Database Modeling & Design Fourth Edition- P22 pdf

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 t

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 FigFig-ure 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

Figure 5.5 ER model: ternary and n-ary relationships

Technician

Notebook Project

1

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 tabletechnician(emp_id char(10), create tableproject(project_name char(20), create tablenotebook(notebook_no integer, create tableuses_notebook(emp_id char(10),

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

→

→

→

Figure 5.5 (continued)

Employee

Location Project

N

1 assigned- 1

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 tableemployee(emp_id char(10),

create tableproject(project_name char(20),

create tablelocation(loc_name char(15),

create tableassigned_to(emp_id char(10),

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

→

→

Engineer Manager

N

assigned-to

Functional dependency

manages

emp_id

4106 4200 7033 4200 4106 7033 4106 4106

alpha alpha beta beta 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 tableproject(project_name char(20), create tablemanager(mgr_id char(10), create tableengineer(emp_id char(10), create tablemanages(project_name char(20),

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

Figure 5.5 (continued)

Employee

Project Skill

N

skill-used

Functional dependencies

skill_used

emp_id skill_type project_name

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 tableemployee(emp_id char(10),

create tableskill(skill_type char(15),

create tableproject(project_name char(20),

create tableskill_used(emp_id char(10),

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