Chapter 4: Logical Database Design and the Relational Model (Part I)

Presentation on theme: "Chapter 4: Logical Database Design and the Relational Model (Part I)"— Presentation transcript:

Chapter 4: Logical Database Design and the Relational Model (Part I)
Modern Database Management 11th Edition Jeffrey A. Hoffer, V. Ramesh, Heikki Topi We learned Database Analysis; We are moving into Database Design

Objectives Part 1: Define terms List five properties of relations
Disambiguation: “Data model” means E-R diagram; “Relational model” means what we are learning in the current chapter 1) short text statement, and 2) graphical representation Part 1: Define terms List five properties of relations State two 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 Part 2: Use normalization to convert anomalous tables to well-structured relations

Database Schema (Ch 1, Slide #40)
External Schema User Views Subsets of Conceptual Schema Can be determined from business-function/data entity matrices [Fig 1-6] DBA determines schema for different users Conceptual Schema E-R models – covered in Chapters 2 and 3 Internal Schema Logical structures–covered in Chapter 4 (Relational model) Physical structures–covered in Chapter 5

Introduction Logical DB design: process of transforming the conceptual data model (i.e., ERD) into a logical data model (i.e., models in this chap) Conceptual data modeling: getting the right requirements >>model the biz logic correctly Logical DB design: getting the requirements right >>correctly transform the biz logic for implementation An E-R data model is not a relational data model need normalization [2nd half of Ch 4] ERD is developed for the purpose of understanding biz rules, not structuring data for sound DB processing The last part is the goal of logical DB design

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 (attributes or fields). 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 1st Normal form

Correspondence with E-R Model
Relations (tables) correspond with entity types and with many-to-many relationship types. Columns correspond with attributes. Rows correspond with entity instances and with many-to-many relationship instances. We can express the structure of a relation by a shorthand notation (“text description”): RELATION (attribute1, attribute2, attribute3, …) Example: PRODUCT( … )  exercise NOTE: The word relation (in relational database) is NOT to be confused with the word relationship (in E-R model): …

Correspondence of terms
Entity (type) Entity instance Attribute Relation/Table Row Column Examples: STUDENT John Smith 3.5 (for GPA field) COMPANY STUD_CLUB EXAM

Key Fields Keys are special fields that serve two main purposes:
Primary keys are unique identifiers of the relation in question. - how we can guarantee that all rows are unique. 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). an attribute in a relation (table) of a database that serves as the primary key of another relation in the same database Keys can be simple (a single field) or composite (more than one field). Keys usually are used as indexes to speed up the response to user queries (Ch 5).

Removing multivalued attributes Fig 4-2a
Identify the multivalued attributes for several records (entity instances)

Removing multivalued attributes Fig 4-2b
Simple ways of treating multivalued and composite attributes …

Schemas The structure of the DB is described through schemas
Two common methods for expressing schema: Short text statements (example: Slide 12) RELATION (attribute1, attribute2, attribute3, …) EMPLOYEE (Emp_ID, LastName, FirstName, …) Graphical representation (example: Slide 13) Each relation represented by a rectangle containing attributes RELATION Attr1 Attr2 Attr3 Attr4 Attr5

Short Text Statement of PVFC
Primary key Foreign key Short Text Statement of PVFC Graphical representation: Lines/curves with arrowhead are used to indicate the referencing relationship (referential integrity – Slides #13 and 17) between foreign key and primary key.

Foreign Key (implements 1:N relationship between customer and order)
Fig 4-3 Schema for four relations (graphical representation) Primary Key Will be req’d the most for HW 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) The curvy arrows here indicate relationships (PK – FK pairs)

Integrity Constraints
Domain Constraints Allowable values for an attribute. See Table 4-1, P160 Other examples: Entity Integrity No primary key attribute may be null. All primary key fields MUST have data Referential integrity Primary key – Foreign key relationship (   Slide #16)

Domain definitions enforce domain integrity constraints

Integrity Constraints – Referential Integrity
Rule states that any foreign key value (in 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–don’t allow delete of “parent” side if related rows exist in “child” / “dependent” side Cascade–automatically delete “dependent” side rows that correspond with the “parent” side row to be deleted Set-to-Null–set the foreign key in the dependent side to null if deleting from the parent side  not allowed for weak entities Example using IS 312 DB

Note: From … To … Compared w next slide:
Figure 4-5 Referential integrity constraints (Pine Valley Furniture) Note: From … To Referential integrity constraints are drawn via arrows from dependent to parent table … From “M” to”1” Compared w next slide:

(1) Primary key appears… (2) Foreign key departs from… ends at…
Figure 1-3(b), P.11 (1) Primary key appears… (2) Foreign key departs from… ends at…

Summary of previous section
In ERD In Rel Schema Note Entity Table No space in table name Attribute Column attribute domains Primary key can be composite 1:M relationship Prim. key on 1-side Foreign on M-side Don’t flip the two ! ! ! M:N relationship New relation/table for the M:N relationship M:N   associative entity   table on its own Relationship arrow always points from ___-side to __-side; From _______ key to _______ key

Referential integrity constraints are implemented with
Figure 4-6 SQL table definitions Referential integrity constraints are implemented with foreign key to primary key references

Anomalies Three anomalies in this relation/table: Insertion anomaly
Deletion anomaly Modification anomaly (PP. 162~163)

Transforming EER Diagrams into Relations (PP. 165-6)
Three types of entities:

Transforming EER Diagrams into Relations
Mapping Regular Entities to Relations – handling attributes: Simple attributes: E-R attributes map directly onto the relation (Fig 4-8, next slide) Composite attributes: Use only their simple, component attributes (Figure 4-9) Multivalued attribute: Becomes a separate relation with a foreign key taken from the superior entity (Figure 4-10)

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

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

Figure 4-10 Mapping an entity with a multivalued attribute
Multivalued attribute becomes a separate relation with foreign key Ref Slide #23 (b) Imagine tables? Q: from the left, who’s 1 and who’s M? One–to–many relationship between original entity and new relation

Multi-valued attributes
The first relation EMPLOYEE has the primary key Employee_ID The second relation EMPLOYEE_SKILL has two attributes Employee_ID and Skill, which form the primary key

Transforming EER Diagrams into Relations (cont.)
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 Primary key of identifying relation (strong entity)

What is its function/role?
Figure 4-11 Example of mapping a weak entity a) Weak entity DEPENDENT What is this? What is its function/role?

“a foreign key taken from…” S#28
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 (= ? + ?) “a foreign key taken from…” S#28

Transforming EER Diagrams into Relations (cont.)
Mapping Binary Relationships One-to-Many–Primary key on the one-side becomes a foreign key on the many-side Many-to-Many–Create a new relation with the primary keys of the two entities as its primary key One-to-One–Primary key on the mandatory side becomes a foreign key on the optional side (curvy) Arrows indicating referential integrity constraints Points from M-side to 1-side From foreign key to primary key

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

Map binary many-to-many (M:N) relationships
If M:N relationship exists between entity types A and B, we create a new relation C, include as foreign keys in C the primary keys for A and B, these attributes, together, become the primary key of C

Figure 4-13 Example of mapping an M:N relationship
a) Completes relationship (M:N) Will be treated as an associative entity The Completes relationship will need to become a separate relation

Figure 4-13 Example of mapping an M:N relationship (cont.)
b) Three resulting relations The old “Completes” relationship Composite primary key New intersection relation Foreign key Foreign key What can we say about arrow direction? Associative entity/intersection relation is always on the M-side

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

Map binary 1:1 relationships
In a 1:1 relationship, the association in one direction is often optional one, while the association in the other direction is mandatory one think about STUDENT and PARKING_PERMIT The primary key of one of the relations is included as a foreign key in the other relation The primary key of the Mandatory side  The foreign key of the optional side

Figure 4-14 Example of mapping a binary 1:1 relationship (cont.)
b) Resulting relations Arrow points from _______ side to ____ side, from ______ key to ____ key Foreign key goes in the relation on the optional side, matching the primary key on the mandatory side Practice the same for the STUDENT and PARKING_PERMIT relationship

Transforming EER Diagrams into Relations (cont.)
Mapping Associative Entities Three relations will be created: one for each of the original entities, and a third for the associative entity. Two situations: Identifier Not Assigned Default primary key for the association relation is composed of the primary keys of the two entities (as in M:N relationship) Identifier Assigned (, when- ) It is natural and familiar to end-users Default identifier may not be unique

Figure 4-15 Example of mapping an associative entity
An associative entity (will be transformed to an “Intersection Relation”) Regular entity Associative entity Regular relation Intersection relation

Figure 4-15 Example of mapping an associative entity (cont.)
b) Three resulting relations Associative entity/intersection relation is on _____-side; arrow points from ~~ to ~~ Composite primary key - two primary key attributes from the other two relations two foreign keys, referencing the other two entities

Figure 4-16 Example of mapping an associative entity with
an identifier a) SHIPMENT associative entity In this situation, the associative entity type has a natural identifier that is familiar to end users – Shipment ID

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

Transforming EER Diagrams into Relations (cont.)
Mapping Unary Relationships One-to-Many: Recursive foreign key in the same relation Many-to-Many: Two relations: 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

Note the direction of the arrow!
Figure 4-17 Mapping a unary 1:N relationship (a) EMPLOYEE entity with unary relationship (b) EMPLOYEE relation with recursive foreign key Note the direction of the arrow! Examine the tables: …

An associative entity Figure 4-18 Mapping a unary M:N relationship
(a) Bill-of-materials relationships (M:N) Is_contained_in How do I know?? (b) ITEM and COMPONENT relations An associative entity

Transforming EER Diagrams into Relations (cont.)
Mapping Ternary (and n-ary) Relationships One relation for each entity, and one for the associative entity Associative entity has foreign keys to each of the regular entities in the relationship

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

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

Transforming EER Diagrams into Relations (cont.)
Mapping Supertype/Subtype Relationships One relation for supertype and for each subtype Supertype attributes (including identifier and subtype discriminator) go into supertype relation Subtype attributes go into each subtype; primary key of supertype relation also becomes primary key of subtype relation 1:1 relationship established between supertype and each subtype, with supertype as primary table The last three slides – 50~52 – wait till we learn Chap 3

Figure 4-20 Supertype/subtype relationships

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

Download ppt "Chapter 4: Logical Database Design and the Relational Model (Part I)"

Similar presentations