Chapter 4: Logical Database Design and the Relational Model Modern Database Management 11th Edition, International Edition Jeffrey A. Hoffer, V. Ramesh, Heikki Topi © 2013 Pearson Education

Chapter Outline The Relational (關聯式的) Data Model Integrity Constraints (完整性限制) Transforming EER Diagrams into Relations Introduction to Normalization Normalization Example Merging Relations

Learning Objectives Understand definitions of terms Properties of relations Properties of candidate keys Define first, second, and third normal form Describe problems from merging relations Transform E-R and EER diagrams to relations Create tables with entity and relational integrity constraints Use normalization to convert anomalous (異常的) tables to well-structured relations

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

NOTE: All relations are in 1st Normal form. 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 multi-valued, not composite). Every row must be unique (can’t have two rows with exactly the same values for all their fields). Every attribute (column) in a same table must have a unique name. The order of the columns must be irrelevant. The order of the rows must be irrelevant. NOTE: All relations are in 1st Normal form.

Example of Relation with Sample Data Figure 4-1 Employee1 Relation with Sample Data. 6

Relation with Multi-valued Attribute Figure 4-2(a) Table with repeating groups. 7

Correspondence (相當性) with E-R Model A relation (table) corresponds to an entity type and to a many-to-many relationship type. A row corresponds to an entity instance and to a many-to-many relationship instance. A column corresponds to an attribute. NOTE: The word relation (in relational database) is NOT the same as the word relationship (in E-R model).

Relational KEYS (索引、鍵) Keys are special attributes that serve two main purposes: Primary key is a unique identifier of a relation. Examples include employee numbers, social security numbers, etc. This guarantees that all rows are unique. Foreign key is an identifier that enables a dependent (依附 的、附屬的) (child) 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 (a single attribute) or composite (more than one attribute). Keys usually are used as indexes to speed up the response to user queries (more on this in Chapter 5).

Figure 4-3 Schema for four relations (Pine Valley Furniture Company) Primary Key Foreign Key (implements a 1:M relationship between customer and order) Composite Primary Key (uniquely identifies the order line) Composed from 2 foreign keys Implements a M:N relationship between order and product © 2013 Pearson Education Chapter 4 10

Integrity Constraints 1/2 To facilitate maintaining the accuracy and integrity of data in the database. Three Types : Domain (值域) Constraints Allowable values for an attribute (See Table 4-1) Entity Integrity Constraint Every relation has a primary key. All primary key attributes MUST have data. No primary key attribute may be null. A null is not a value, but rather it indicates the absence of a value.

Domain definitions enforce domain integrity constraints. 12/35/15 invalid 13/01/15 Domain definitions enforce domain integrity constraints. © 2013 Pearson Education Chapter 4 12

Integrity Constraints 2/2 Referential (參照的) Integrity Constraint : Referential integrity constraint : a rule states that either, each foreign key (FK) value (in the relation of the many side) MUST match a primary key (PK) value in the relation of the one side or, the foreign key must be null Association between tables are defined through the uses of FKs. 3 choices for DELETE RULE (of a parent record) to enforce referential integrity constraint Restrict : don’t allow delete a record in “parent” side if its related records exist in “child” side Cascade : automatically delete child-side rows when their related parent- side row is deleted Set-to-Null : if deleting a record from the parent side, set the foreign key of the related records in the child side to null (This choice is not allowed for weak entities, why ?)

Creating Relational Tables with SQL Figure 4-6 Example of SQL table definitions Table schema reference Entity Integrity Referential Integrity 14

Figure 4-5 Referential integrity constraints (Pine Valley Furniture) Referential integrity constraints are drawn via arrows from dependent to parent table Corresponding SQL © 2013 Pearson Education Chapter 4 15

Figure 4-6 SQL table definitions Table schema Referential integrity constraints are implemented with foreign key to primary key references. Important questions : What attribute is a FK? What FK references what table’s PK? © 2013 Pearson Education Chapter 4

Transforming EER Diagrams into Relations Mapping Regular Entities to Relations Simple attributes: E-R attributes map directly onto the relation Composite attributes: Use only their simple, component attributes Multi-valued Attribute: Becomes a separate relation with a foreign key taken from the parent entity

Figure 4-8 Mapping a regular entity (a) CUSTOMER entity type with simple attributes (b) The corresponding CUSTOMER relation of (a) © 2013 Pearson Education Chapter 4 18

Figure 4-9 Mapping a composite attribute (a) CUSTOMER entity type with composite attribute (b) The corresponding CUSTOMER relation of (a) © 2013 Pearson Education Chapter 4 19

Figure 4-10 Mapping an entity with a multi-valued attribute A multi-valued attribute becomes a separate relation with a foreign key The foreign key implementing a one–to–many relationship between original entity and new relation (b) 1:M (a) EMPLOYEE entity type with a multi-valued attribute Skill FK a composite PK

Transforming EER Diagrams into Relations (cont.) Mapping Weak Entities The weak entity becomes a separate relation with a foreign key (FK) taken from the primary key (PK) of the strong entity Primary key is composed of: The partial identifier of weak entity The primary key of identifying entity (strong entity) ERD Table Design

Identifying relationship Figure 4-11 Example of mapping a weak entity a) Weak entity DEPENDENT Identifying relationship Strong entity Weak entity © 2013 Pearson Education Chapter 4 22

Figure 4-11 Example of mapping a weak entity b) Relations resulting from weak entity Foreign key partial identifier of weak entity PK of identifying entity A composite primary key NOTE: the domain constraint for the foreign key should NOT allow null value since DEPENDENT is a weak entity © 2013 Pearson Education Chapter 4 23

Transforming EER Diagrams into Relations (cont.) Mapping a binary relationship One-to-Many (1:M) Primary key on the one side becomes a foreign key on the many side Many-to-Many (M:M) Create a new relation with the primary keys of the two related entities as its primary key One-to-One (1:1) Primary key on mandatory side becomes a foreign key on optional side

Figure 4-12 Example of mapping a 1:M relationship a) Relationship between customers and orders Note the mandatory one b) The corresponding relationship PK FK No null value in the foreign key. This is because of the mandatory minimum cardinality. © 2013 Pearson Education Chapter 4 25

Figure 4-13 Example of mapping an M:N relationship a) Completes relationship (an M:N relationship) The Completes relationship will need to become a separate relation. Schema design © 2013 Pearson Education Chapter 4 26

Figure 4-13 Example of mapping an M:N relationship (cont.) b) Three resulting relations PK Composite primary key FK new intersection relation FK PK © 2013 Pearson Education Chapter 4 27

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

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

Transforming EER Diagrams into Relations (cont.) Mapping An Associative Entity (2 cases) PK is not assigned by end-users Default primary key for the association relation is composed of the primary keys of the two entities (as in M:N relationship) PK is assigned by end-users It is natural and familiar to end-users Note default identifier may not be unique

Figure 4-15 Example of mapping an associative entity a) An associative entity Schema design © 2013 Pearson Education Chapter 4 31

Figure 4-15 Example of mapping an associative entity (cont.) b) Three resulting relations A composite primary key formed from the PKs of the two related entities © 2013 Pearson Education Chapter 4 32

Figure 4-16 Example of mapping an associative entity with an identifier a) SHIPMENT associative entity Schema design © 2013 Pearson Education Chapter 4 33

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

Transforming EER Diagrams into Relations (cont.) Mapping Unary Relationships Mapping a one-to-many relationship Add a recursive foreign key in the same relation Mapping a many-to-many relationship Add an associative relation The primary key of the relation has two attributes, Each is taken from the PK of the entity associated with the unary relationship Each attribute is a FK to the entity

Figure 4-17 Mapping a unary 1:M relationship (a) EMPLOYEE entity with unary relationship (b) EMPLOYEE relation with recursive foreign key © 2013 Pearson Education Chapter 4 36

Figure 4-18 Mapping a unary M:N relationship (a) Bill-of-materials relationships (M:N) (b) ITEM and COMPONENT relations FK FK Composite primary key

Transforming EER Diagrams into Relations (cont.) Mapping a ternary (and n-ary) relationship Convert the ternary relationship to an associative entity Add one relation for the associative entity The primary key of the relation has 3 attributes Each is taken from the PK of each entity associated with the ternary relationship Each attribute is a FK to each related entity

Figure 4-19 Mapping a ternary relationship a) PATIENT TREATMENT ternary relationship denoted as an associative entity Schema design © 2013 Pearson Education Chapter 4 39

Figure 4-19 Mapping a ternary relationship (cont.) b) Mapping the ternary relationship PATIENT TREATMENT Composite PK Assume a patient may be treated by a same doctor multiple times on a date. Remember that the primary key MUST be unique. This is why treatment date and time are included in the composite PK. But this makes a very cumbersome PK. It would be better to create a surrogate key (代用鍵) like Treatment#. © 2013 Pearson Education Chapter 4

Transforming EER Diagrams into Relations (cont.) Mapping a supertype/subtype relationship One relation for supertype and one for each subtype Supertype attributes (including PK and subtype discriminator) go into supertype relation Subtype attributes go into each subtype relation PK of supertype relation also becomes PK of subtype relation Establishing 1:1 relationship between supertype and each subtype, with supertype as primary table

Figure 4-20 Supertype/subtype relationships Schema design © 2013 Pearson Education Chapter 4 42

These are implemented as one-to-one relationships. Figure 4-21 Mapping supertype/subtype relationships to relations These are implemented as one-to-one relationships. © 2013 Pearson Education Chapter 4 43

Data Normalization (正規化、標準化) A process (Purpose) used to validate and improve the logical design of a relational database so that it satisfies certain data constraints that avoid unnecessary data duplication (重複) (Step) decomposing a relation with modification anomalies (更動的異常:資料更動時會發生的異常情形) into several smaller, well-structured relations

Main Goals of Data Normalization Minimize data redundancy (重複) to avoid modification anomalies and conserve storage space. Simplify the enforcement (執行) of referential integrity constraints. Make it easier to maintain data (insert, update, and delete) Provide a better database design that is an improved representation of an organization’s operations and a stronger basis for future growth.

A Well-Structured Relation A relation that contains minimal data redundancy, and allows users to insert, update, and delete data rows without causing data inconsistency Main design goal is to avoid modification anomalies Insertion Anomaly–adding new data rows forces user to create redundant data Deletion Anomaly–deleting data rows may cause a loss of data that would be needed Update Anomaly–changing the data of a data row forces changes to other rows due to data duplication General rule of thumb: A table should not pertain to more than one entity type.

Example–Figure 4-2b Question–Is this a relation? Answer–Yes: Unique rows and no multivalued attributes Question–What’s the primary key? Answer–Composite: EmpID, CourseTitle

Anomalies in this Table Insertion–can’t enter a new employee without having the employee take a class Deletion–if we remove employee 140, we lose information about the existence of a Tax Acc class Update–giving a salary increase to employee 100 forces us to update multiple records Why do these modification anomalies exist? Because there are two themes (entity types) in this one relation. This results in data duplication and an unnecessary data dependency between entity types.

Figure 4.22 Steps in normalization 3rd normal form is generally considered sufficient © 2013 Pearson Education Chapter 4 49

Functional Dependencies and Keys Functional Dependency (函數性的依附) A constraint between two attributes in which the value of one attribute is determined by the value of another attribute (the determinant (決定項) ). Candidate Key: An attribute, or a combination of attributes, that uniquely identifies a row in a relation. Example, A table contains credit card number and SS#. In this case both are candidate keys. The primary key is chosen from one of the candidate keys. Each non-key field must be functionally dependent on one of the candidate keys.

First Normal Form No multivalued attributes (no repeating groups) in the relation, i.e., every attribute value is atomic. A primary key has been defined, which uniquely identifies each row in the relation. Fig. 4-25 is not in 1st Normal Form (having multivalued attributes).  it is not a relation. Fig. 4-26 is in 1st Normal form. All relations are in 1st Normal Form.

Table with multivalued attributes, not in 1st normal form Primary key Note: This is NOT a relation. © 2013 Pearson Education Chapter 4 52

Note: This is a relation, but not a well-structured one. INVOICE (發貨單) table in 1st normal form no multivalued attributes unique rows (primary key uniquely identifies each row) Note: This is a relation, but not a well-structured one. Not a relation © 2013 Pearson Education Chapter 4 53

Anomalies in FIGURE4-26 Table Insertion– Not able to introduce a new product (say, Breakfast Table with ProductID 8) without adding the information OrderID. (PK : ProductID + OrderID) Deletion–if we delete the Dining Table from Order 1006, we lose information concerning this product (description, finish (拋光), and price). Update–changing the price of product ID 4 (Entertainment Center) requires update in multiple records Why do these anomalies exist? Because there are multiple themes (entity types) in one relation. This results in data duplication and an unnecessary data dependency between the entity types.

Second Normal Form A relation in 1NF, and Every non-key attribute of the relation is fully functionally dependent on the ENTIRE primary key, i.e., No partial functional dependencies Every non-key attribute must not be dependent on a part of the PK.

Figure 4-27 Functional dependency diagram for INVOICE PK = OrderID + ProductID (on OrderID & ProductID) (on OrderID) (on ProductID) OrderID  OrderDate, CustomerID, CustomerName, CustomerAddress : P.D. CustomerID  CustomerName, CustomerAddress ProductID  ProductDescription, ProductFinish, ProductStandardPrice : P.D. OrderID, ProductID  OrderQuantity Therefore, INVOICE is NOT in 2nd Normal Form

CONVERTING to 2NF Create a new relation by using the PK attribute(s) (determinant) of each partial dependency. This attribute(s) is the PK of the new relation FK of the old relation Find the nonkey attributes that are dependent on this PK attribute(s). Move them from the old relation to the new relation.

Figure 4-28 Result after removing partial dependencies Figure 4-28 Result after removing partial dependencies (Converting to 2NF) Before removing PDs Partial dependencies are removed, but there are still transitive dependencies.

Third Normal Form A relation that is in 2NF, and has no transitive dependencies Transitive dependency (AC due to AB & BC) A functional dependency between the PK and a non-key attribute that depends on the PK via another non-key attribute. Converting to 3NF Create a new relation for the non-key determinant (example : B of BC) causing a transitive dependency. The non-key determinant becomes PK in the new table, and stays as FK in the old table . Find all the attributes that are functionally dependent on the non-key determinant . Move them from old relation to new relation.

Transitive dependencies are removed. Figure 4-29 Result after removing transitive dependencies The relation schem Before transitive dependencies are removed. Transitive dependencies are removed. Getting it into Third Normal Form

Merging (整併) Relations Merging relations is also called view integration (In a large project) combining relations transformed from multiple ER models into common relations Issues to watch out for when merging entities from different ER models in a large project : Synonyms (同義字) – two or more attributes with different names but same meaning Homonyms (同形異義字) – attributes with same name but different meanings Transitive dependencies–even if relations are in 3NF prior to merging, they may not be in 3NF after merging Supertype/subtype relationships–may be hidden prior to merging

Enterprise Keys A primary key whose value is unique across all the relations in a database, not just unique in a single relation Corresponds to the concept of object ID in object-oriented systems

Figure 4-31 Enterprise keys a) Relations with enterprise key b) Sample data with enterprise key EMPLOYEE and CUSTOMER are subtypes of the OBJECT supertype. © 2013 Pearson Education Chapter 4 63

作業 下一次上課時交 作業 : 第四章 Problems and Exercises (227~235頁) 學號單號: 6 : a 7 : a, b, d, f 學號雙號: 8 : a, b, c, d

Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 65