Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 1 CHAPTER 4: LOGICAL DATABASE DESIGN AND THE RELATIONAL MODEL (PART I) Modern Database.

Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 1

CHAPTER 4:LOGICAL DATABASE DESIGN AND THE RELATIONAL MODEL (PART I)

Modern Database Management11th 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 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 constraintsPart 2: Use normalization to convert anomalous

tables to well-structured 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

Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall

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 53


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


RELATION 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:1. It must have a unique name.2. Every attribute value must be atomic

1. (not multivalued, not composite).3. Every row must be unique (can’t have two rows

with exactly the same values for all their fields).

4. Attributes (columns) in tables must have unique names.

5. The order of the columns must be irrelevant.6. The order of the rows must be irrelevant.

NOTE: all relations are in 1st Normal form


CORRESPONDENCE WITH E-R MODEL1. Relations (tables) correspond with entity

types and with many-to-many relationship types.

2. Columns correspond with attributes.3. 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

7

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 ATTRIBUTESFIG 4-2A

Identify the multivalued attributes for several records (entity instances)

9


REMOVING MULTIVALUED ATTRIBUTES FIG 4-2B

Simple ways of treating multivalued and composite attributes …

10


SCHEMAS The structure of the DB is described

through schemas Two common methods for

expressing schema:1. Short text statements (example: Slide

12) RELATION (attribute1, attribute2, attribute3, …) EMPLOYEE (Emp_ID, LastName, FirstName, …)

2. Graphical representation (example: Slide 13) Each relation represented by a rectangle

containing attributes RELATION

Attr1 Attr5

Attr4

Attr3Attr2


SHORT TEXT STATEMENT OF PVFC

Lines/curves with arrowhead are used to indicate the referencing relationship (referential integrity – Slides #13 and 17) between foreign key and primary key.

Graphical representation:

Primary key Foreign key


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)

Fig 4-3 Schema for four relations (graphical representation)Will be req’d the

most for HW

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


Figure 4-5 Referential integrity constraints (Pine Valley Furniture)

Referential integrity

constraints are drawn via arrows

from dependent to parent table …

From “M” to”1”Compared w next slide:

Note:

From … To …


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 Primary key can be composite

1:M relationship Prim. key on 1-sideForeign 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

19


20

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:1. Insertion anomaly2. Deletion anomaly3. 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:

1. Simple attributes: E-R attributes map directly onto the relation (Fig 4-8, next slide)

2. Composite attributes: Use only their simple, component attributes (Figure 4-9)

3. Multivalued attribute: Becomes a separate relation with a foreign key taken from the superior entity (Figure 4-10)

Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall24

(a) CUSTOMER entity type with simple attributes

Figure 4-8 Mapping a regular entity

(b) CUSTOMER relation

24


(a) CUSTOMER entity type with composite attribute

Figure 4-9 Mapping a composite attribute

(b) CUSTOMER relation with address detail


Figure 4-10 Mapping an entity with a multivalued attribute

One–to–many relationship between original entity and new relation

(a)

Multivalued attribute becomes a separate relation with foreign keyRef Slide #23

(b)

Q: from the left, who’s 1 and who’s M?

Imagine

tables?


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)


Figure 4-11 Example of mapping a weak entity

a) Weak entity DEPENDENT1.What is this?2.What is its

function/role?


NOTE: the domain constraint for the foreign key should NOT allow null value if DEPENDENT is a weak entity

Foreign key

Composite primary key(= ? + ?)

Figure 4-11 Example of mapping a weak entity (cont.)

b) Relations resulting from weak entity

“a foreign key taken from…” S#28



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)

The Completes relationship will need to become a separate relation

Will be treated as an associative entity


New intersection

relation

Foreign keyForeign key

Composite primary key

Figure 4-13 Example of mapping an M:N relationship (cont.)

b) Three resulting relations

Associative entity/intersection relation is always on the M-side

What can we say about arrow direction?

The old “Completes”

relationship


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


b) Resulting relations

Figure 4-14 Example of mapping a binary 1:1 relationship (cont.)

Foreign key goes in the relation on the optional side,matching the primary key on the mandatory side

Arrow points from _______ side to ____ side, from ______ key to ____ key

Practice the same for the STUDENT and PARKING_PERMIT relationship



Mapping Associative Entities Three relations will be created: one for

each of the original entities, and a third for the associative entity. Two situations:1. 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)

2. 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

a) An associative entity (will be transformed to an“Intersection Relation”)

Regular entity Associative entity Regular entity

Regular relation Intersection relation Regular relation


Figure 4-15 Example of mapping an associative entity (cont.)


1. Composite primary key - two primary key attributes from the other two relations

2. two foreign keys, referencing the other two entities

Associative entity/intersection relation is on _____-side; arrow points from ~~ to ~~


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.)


Primary key differs from

foreign keys - identifier assigned



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


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: …


Figure 4-18 Mapping a unary M:N relationship

(a) Bill-of-materials relationships (M:N)

(b) ITEM and COMPONENT relations

An associative

entity

How do I know??

Is_contained_in


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


b) Mapping the ternary relationship PATIENT TREATMENT

Remember that the

primary key MUST be

unique

Figure 4-19 Mapping a ternary relationship (cont.)

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 a

ssoc

iativ

e

entit

y


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


Figure 4-21 Mapping supertype/subtype relationships to relations

These are implemented as one-to-one relationships

Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 1 CHAPTER 4: LOGICAL DATABASE DESIGN AND THE RELATIONAL MODEL (PART I) Modern Database.

Documents

logical data model

relational data model

er data model

relational database

pearson education

database design slide

logical database design

current chapter