Logical Database Design and Relational Model Overview

CHAPTER 4: LOGICAL DATABASE DESIGN AND THE RELATIONAL MODEL Modern Database Management Modern Database Management 12 12th thEdition Edition Global Edition Global Edition Jeff Hoffer, Ramesh Jeff Hoffer, Ramesh Venkataraman Heikki Heikki Topi Venkataraman, , Topi

COMPONENTS OF RELATIONAL MODEL Data structure Tables (relations), rows, columns Data manipulation Powerful SQL operations for retrieving and modifying data Data integrity Mechanisms for implementing business rules that maintain integrity of manipulated data Chapter 4 4-2

RELATION A relation is a named, two-dimensional table of data. A table consists of rows (records ) and columns (attribute or field ). Requirements for a table to qualify as a relation: It must have a unique name. Every attribute value must be atomic (not multivalued, not composite). Every row must be unique (can t have two rows with exactly the same values for all their fields). Attributes (columns) in tables must have unique names. The order of the columns must be irrelevant. The order of the rows must be irrelevant. NOTE: All relations are in 1 1st st Normal form. Normal form. Chapter 4 4-3

CORRESPONDENCE WITH E-R MODEL E-R model Relations (tables) correspond with entity types and with many-to-many relationship types. Table Rows correspond with entity instances and with many-to-many relationship instances. Columns correspond with attributes. NOTE: The word relation same as the word relationship relation (in relational database) is NOT the relationship (in E-R model). Chapter 4 4-4

KEY FIELDS Keys are special fields that serve two main purposes: Primary keys Primary keys are unique identifiers of the relation. Examples include employee numbers, social security numbers, etc. This guarantees that all rows are unique. Foreign keys Foreign keys are identifiers that enable a dependent relation (on the many side of a relationship) to refer to its parent relation (on the one side of the relationship). Keys can be simple one field). Keys usually are used as indexes to speed up the response to user queries (more on this in Chapter 5). simple (a single field) or composite composite (more than Chapter 4 4-5

E-R model Figure 1-3 or 2-22 Figure 4-3 Schema for four relations (Pine Valley Furniture Company) Primary Key Foreign Key (implements 1:N relationship between customer and order) Combined, these are a composite primary key (uniquely identifies the order line) individually they are foreign keys (implement M:N relationship between order and product) Chapter 4 4-6

E-R MODEL () ER Associative Entity ER Chapter 4 4-7

INTEGRITY CONSTRAINTS Domain Constraints Allowable values for an attribute (See Table 4-1) Entity Integrity No primary key attribute may be null. All primary key fields MUST MUST contain data values. Chapter 4 4-8

Domain definitions enforce domain integrity constraints. Chapter 4 4-9

INTEGRITY CONSTRAINTS Referential Integrity rule states that any foreign key value (on the relation of the many side) MUST match a primary key value in the relation of the one side. (Or the foreign key can be null) For example: Delete Rules Restrict Restrict don t allow delete of parent side if related rows exist in dependent side Cascade Cascade automatically delete dependent side rows that correspond with the parent side row to be deleted Set Set- -to to- -Null Null set the foreign key in the dependent side to null if deleting from the parent side not allowed for weak entities Referential Integrity Chapter 4 4-10

Figure 4-5 Referential integrity constraints (Pine Valley Furniture) Referential integrity constraints are drawn via arrows from dependent to parent table ( parent) Chapter 4 4-11

SQL () Figure 4-6 SQL table definitions Referential integrity constraints are implemented with foreign key to primary key references. Chapter 4 4-12

TRANSFORMING E-R DIAGRAMS INTO RELATIONS (1) Mapping Regular Entities to Relations Simple attributes: E-R attributes map directly onto the relation Composite attributes: Use only their simple, component attributes Multivalued Attribute: Becomes a separate relation with a foreign key taken from the superior entity Table Chapter 4 4-13

Figure 4-8 Mapping a regular entity (a) CUSTOMER entity type with simple attributes (b) CUSTOMER relation Chapter 4 4-14

Figure 4-9 Mapping a composite attribute (a) CUSTOMER entity type with composite attribute (b) CUSTOMER relation with address detail Chapter 4 4-15

Figure 4-10 Mapping an entity with a multivalued attribute (a) Multivalued attribute becomes a separate relation with foreign key (b) One to many relationship between original entity and new relation Chapter 4 4-16

E_ID E_ID A B C E_Name E_Name E_Address E_Address John Taipei Mary Hsinchu Bob Taichung E_Skill E_Skill Java Python PHP, Java multi-valued attribute 1 table E_ID E_ID A B C E_Name E_Name E_Address E_Address John Taipei Mary Hsinchu Bob Taichung relation 1st normal form E_ID E_ID A B C C E_Skill E_Skill Java Python PHP Java ? Chapter 4 4-17

TRANSFORMING E-R DIAGRAMS INTO RELATIONS (2) Mapping Weak Entities Becomes a separate relation with a foreign key taken from the superior entity Primary key composed of: Partial identifier of weak entity ID Primary key of identifying relation (strong entity) Parent Chapter 4 4-18

Figure 4-11 Example of mapping a weak entity a) Weak entity DEPENDENT Chapter 4 4-19

Figure 4-11 Example of mapping a weak entity (cont.) b) Relations resulting from weak entity NOTE: the domain constraint for the foreign key should NOT allow null value if DEPENDENT is a weak entity Foreign key Composite primary key Chapter 4 4-20

E_ID E_ID A B E_Name E_Name John Mary D_FName D_FName Dad Dad Mom D_MName D_MName D_LName Sr Sr Sr D_LName Lin Lin Lin DOB DOB 8/10 1/10 6/10 Gender Gender M M F weak entity 1 table primary key E_ID E_ID A B E_Name E_Name John Mary D_FName D_FName Dad Dad Mom D_MName D_MName D_LName Sr Sr Sr D_LName Lin Lin Lin E_ID E_ID A B B DOB DOB 8/10 1/10 6/10 Gender Gender M M F Chapter 4 4-21

TRANSFORMING E-R DIAGRAMS INTO RELATIONS (3) Mapping Binary Relationships One One- -to to- -Many Many Primary key on the one side becomes a foreign key on the many side Many Many- -to to- -Many Many Create a new relation the primary keys of the two entities as its primary key One One- -to to- -One One Primary key on mandatory side becomes a foreign key on optional side new relation with Chapter 4 4-22

Figure 4-12 Example of mapping a 1:M relationship a) Relationship between customers and orders Note the mandatory one b) Mapping the relationship Again, no null value in the foreign key this is because of the mandatory minimum cardinality. Foreign key Chapter 4 4-23

C_ID C_ID A B C C_Name C_Name C_Address C_Address John Taipei Mary Hsinchu Bob Taichung C_Postal C_Postal 106 300 400 O_ID O_ID 001 002 003 OrderDate OrderDate 7/5 10/6 11/3 C_ID C_ID A B A C_ID C_ID A B C C_Name C_Name C_Address C_Address John Taipei Mary Hsinchu Bob Taichung C_Postal C_Postal O_ID 106 300 400 O_ID 001, 003 002 null O_ID O_ID 001 002 003 OrderDate OrderDate 7/5 10/6 11/3 Chapter 4 4-24

Figure 4-13 Example of mapping an M:N relationship a) Completes relationship (M:N) The Completes relationship will need to become a separate relation. Table ( Certificate ) Chapter 4 4-25

Figure 4-13 Example of mapping an M:N relationship (cont.) b) Three resulting relations Composite primary key Foreign key new Foreign key intersection relation Chapter 4 4-26

E_ID E_ID 1 2 3 E_Name E_Name E_DOB John Mary Bob E_DOB C_Completed C_Completed 1/10 (A,10/1), (B,10/5) 2/10 (A,10/1), (C,10/9) 6/20 (B,10/5) C_ID C_ID A B C C_Title C_Title ( Associative Entity ) 1 table 2 primary key foreign key ? E_ID E_ID E_Name E_Name E_DOB 1 John 2 Mary 3 Bob E_DOB 1/10 2/10 6/20 E_ID E_ID 1 1 2 2 3 C_ID C_ID A B A C B CDate CDate 10/1 10/5 10/1 10/9 10/5 C_ID C_ID A B C C_Title C_Title 1 1 1 1 1 1 Chapter 4 4-27

Figure 4-14 Example of mapping a binary 1:1 relationship a) In charge relationship (binary 1:1) Often in 1:1 relationships, one direction is optional Chapter 4 4-28

Figure 4-14 Example of mapping a binary 1:1 relationship (cont.) b) Resulting relations 1:1 Table Table ? Foreign key goes in the relation on the optional side, matching the primary key on the mandatory side ? Chapter 4 4-29

NurseID NurseID A B C NurseName NurseName Mary Sue Belle NurseBirthDate NurseBirthDate 7/1 5/1 4/8 CenterID CenterID CenterLocation CenterLocation 001 Taipei 002 Hsinchu NurseInCharge NurseInCharge A B DateAssigned DateAssigned 7/8 6/5 NurseID NurseID A B C NurseName NurseName Mary Sue Belle NurseBirthDate NurseBirthDate 7/1 5/1 4/8 ToCenter ToCenter DateAssigned DateAssigned 001 7/8 002 6/5 null null CenterID CenterID CenterLocation CenterLocation 001 Taipei 002 Hsinchu Chapter 4 4-30

TRANSFORMING E-R DIAGRAMS INTO RELATIONS (4) Mapping Associative Entities Identifier Not Assigned id Default primary key for the association relation is composed of the primary keys of the two entities (as in M:N relationship) Identifier Assigned id It is natural and familiar to end-users Default identifier may not be unique Chapter 4 4-31

Figure 4-15 Example of mapping an associative entity a) An associative entity Chapter 4 4-32

Figure 4-15 Example of mapping an associative entity (cont.) b) Three resulting relations Composite primary key formed from the two foreign keys Chapter 4 4-33

Figure 4-16 Example of mapping an associative entity with an identifier a) SHIPMENT associative entity Chapter 4 4-34

Figure 4-16 Example of mapping an associative entity with an identifier (cont.) b) Three resulting relations Primary key differs from foreign keys Chapter 4 4-35

E_ID E_ID 1 2 3 E_Name E_Name E_DOB John Mary Bob E_DOB C_Completed C_Completed 1/10 (A,10/1), (B,10/5) 2/10 (A,10/1), (C,10/9) 6/20 (B,10/5) C_ID C_ID A B C C_Title C_Title ( ) 2 foreign key CNO primary key E_ID E_ID E_Name E_Name E_DOB 1 John 2 Mary 3 Bob E_DOB 1/10 2/10 6/20 CNO CNO 001 002 003 004 005 E_ID E_ID 1 1 2 2 3 C_ID C_ID A B A C B CDate CDate 10/1 10/5 10/1 10/9 10/5 C_ID C_ID A B C C_Title C_Title 1 1 1 1 1 1 Chapter 4 4-36

TRANSFORMING E-R DIAGRAMS INTO RELATIONS (5) Mapping Unary Relationships One-to-Many Recursive foreign key in the same relation Many-to-Many Two relations: Table One for the entity type One for an associative relation in which the primary key has two attributes, both taken from the primary key of the entity Chapter 4 4-37

Figure 4-17 Mapping a unary 1:N relationship (a) EMPLOYEE entity with unary relationship (b) EMPLOYEE relation with recursive foreign key Chapter 4 4-38

Emp_ID Emp_ID 1 2 3 4 5 E_Name E_Name E_DOB John Mary Bob Peter Sue E_DOB Mgr_ID 1/10 2/10 6/20 3/20 9/20 Mgr_ID 4 4 1 null 4 Peter John Mary Sue Bob 1 1 ( ) primary key foreign key table Mgr_id Chapter 4 4-39

Figure 4-18 Mapping a unary M:N relationship (a) Bill-of-materials relationships (unary M:N) Associative Entity (b) ITEM and COMPONENT relations table 2 ( ) Chapter 4 4-40

2 ItemNo ItemNo 1 2 3 4 Desc Desc UCost UCost 800 100 200 20 8 1 2 1 ItemNo ItemNo 1 1 1 3 3 ComponentNo ComponentNo 2 3 4 2 4 Quantity Quantity 2 1 8 1 2 2 primary key ( ) foreign key composite primary key Chapter 4 4-41

TRANSFORMING E-R DIAGRAMS INTO RELATIONS (6) Mapping Ternary (and n-ary) Relationships One relation for each entity and one for the associative entity Associative entity has foreign keys to each entity in the relationship Chapter 4 4-42

Figure 4-19 Mapping a ternary relationship a) PATIENT TREATMENT Ternary relationship with associative entity Chapter 4 4-43

Figure 4-19 Mapping a ternary relationship (cont.) b) Mapping the ternary relationship PATIENT TREATMENT It would be better to create a surrogate key like Treatment#. But this makes a very cumbersome key Remember that the primary key MUST be unique. This is why treatment date and time are included in the composite primary key. Chapter 4 4-44

DATA NORMALIZATION Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that avoid unnecessary duplication of data unnecessary duplication of data The process of decomposing relations with anomalies to produce smaller, well well- -structured structured relations , avoid Chapter 4 4-45

WELL-STRUCTURED RELATIONS A relation that contains minimal data redundancy and allows users to insert, delete, and update rows without causing data inconsistencies Goal is to avoid anomalies Insertion Anomaly Insertion Anomaly adding new rows forces user to create duplicate data Deletion Anomaly Deletion Anomaly deleting rows may cause a loss of data that would be needed for other future rows Modification Anomaly Modification Anomaly changing data in a row forces changes to other rows because of duplication General rule of thumb: A table should not pertain to more than one entity type. entity Chapter 4 4-46

EXAMPLEFIGURE 4-2B Answer Yes: Unique rows and no multivalued attributes Question Is this a relation? Question What s the primary key? Answer Composite: EmpID, CourseTitle Chapter 4 4-47

entity ANOMALIES IN THIS TABLE Insertion Insertion can t enter a new employee without having the employee take a class (or at least empty fields of class information) Deletion Deletion if we remove employee 140, we lose information about the existence of a Tax Acc class Modification Modification giving a salary increase to employee 100 forces us to update multiple records Why do these anomalies exist? Because there are two themes (entity types) in this one relation. This results in data duplication and an unnecessary dependency between the entities. Chapter 4 4-48

FUNCTIONAL DEPENDENCIES AND KEYS Functional Dependency: The value of one attribute (the determinant determinant) determines the value of another attribute : Candidate Key: A unique identifier. One of the candidate keys will become the primary key E.g., perhaps there is both credit card number and SS# in a table in this case both are candidate keys. Each non-key field is functionally dependent on every candidate key. Chapter 4 4-49

Figure 4.22 Steps in normalization 3rd normal form is generally considered sufficient Chapter 4 4-50