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