Chapter 4 Logical Database Design and the Relational Model

TM 4-1Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems

Chapter 4Logical Database Design and

the Relational Model

Jason C. H. Chen, Ph.D.Professor of MIS

School of Business AdministrationGonzaga UniversitySpokane, WA [email protected]


Objectives• 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• Use normalization to convert anomalous tables to

well-structured relations

Conceptual Level

Internal Level

External Level

Conceptual Schema

Internal Schema

Levels of Database SchemasDifferent schemas are presented to different users

Internal to conceptual mapping

Conceptual to Internal mapping

Enterprise Data Model

Logical Schema

Physical Schema

PHASE I

PHASE II


Problem Solving for Modeling a Database Project

Business ProblemStudy and Analyze

w/Team

ER or EER or OO

?????

Normalization(3NF)

User interview & Integrated Model

?????

?????

IMPLEMENTATION

Should be included in the Term Project

PHASE I

PHASE II


• 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

Components of relational modelHow are they related to MVC?


Relation• Definition: A relation is a named, two-

dimensional table of data– Table is made up of rows (records), and columns

(attribute or field)• Not all tables qualify as relations• Requirements:

– Every relation has a unique name.– Every attribute value is atomic (not multivalued, not

composite)– Every row is unique (can’t have two rows with exactly

the same values for all their fields)– Attributes (columns) in tables have unique names– The order of the columns is irrelevant– The order of the rows is irrelevant


Correspondence with ER Model• Relations (tables) correspond with entity types and

with many-to-many relationship types• Rows correspond with entity instances and with many-

to-many relationship instances• Columns correspond with attributes

• NOTE: The word relation (in relational database) is NOT the same as the word relationship (in ER model)

First, we will review “Cardinality” andpk, fk, cpk

Next, we will study two types of representations for relations.

Associative Entity

Foundation of maintaining data integrity (anomaly) will also be discussed


Fig. 4-5: Referential integrity constraints (Pine Valley Furniture)

pk

pk

cpk/pk

pk

fk

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

Foreign Key (implements 1:N relationship between customer and order)


Fig. 4-3: Schema for four relations (Pine Valley Furniture) Graphical and Text Representations

CUSTOMER(Customer_ID,Customer_name,Address,City,State,Zip)

ORDER(Order_ID,Order_Date,Customer_ID)

ORDER_LINE(Order_ID, Product_ID,Quantity)

PRODUCT(Product_ID,Product_Description,Product_Finish,Unit_Price,On_Hand)


Additional Diagram should be created for your MVC Phase I


Fig. 4-1: EMPLOYEE1 Relation with sample data

EMPLOYEE1

EmpID Name DeptName Salary

100 Margaret Simpson Marketing 48,000140 Allen Beeton Accounting 52,000110 Chris Lucero Info. System 43,000190 Lorenzo Davis Finance 55,000150 Susan Martin Marketing 42,000


EMPLOYEE

EmpIDNameDeptNameSalary

EMPLOYEE

EmpIDNameDeptNameSalary{Course_Title, Date_Completed}

EmpID Name DeptName Salary Course_Title Date_Completed

100 Margaret Simpson

Marketing 48,000 SPSS, Surveys 6/9/201X, 10/7/201X

140 Allen Beeton Accounting 52,000 Tax Acc 12/8/201x110 Chris Lucero Info. System 53,000 SPSS, C++ 1/12/201X,4/22/201X190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS, Java 6/16/201X, 8/12/201X

Multi-valued

Can we implement a database as stated above? Why? (Y/N)How can we: 1) count # of courses an employee completed?How can we: 2) add a new course just completed today?

We will learn how to handle the issue of “Multi-Valued” attributes

Or, another way? Stated in the next slide


Fig. 4-2: Eliminating multi-valued attributes

(a) Table with repeating groups or multi-valued attributes (Un-Normalized)

EmpID Name DeptName Salary Course Date Title Completed

100 Margaret Simpson Marketing 48,000 SPSS 6/19/201X Surveys 10/7/201X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/201X110 Chris Lucero Info. System 43,000 SPSS 1/12/201X C++ 4/22/201X190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/201X Java 8/12/201X

EMPLOYEEBetter?

Any Problems?


EmpID Name DeptName Salary Course Date Title Completed100 Margaret Simpson Marketing 48,000 SPSS 6/19/201X Surveys 10/7/201X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/201X110 Chris Lucero Info. System 43,000 SPSS 1/12/201X C++ 4/22/201X190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/201X Java 8/12/201X

EmpID Name DeptName Salary Course Date Title Completed100 Margaret Simpson Marketing 48,000 SPSS 6/19/201X100 Margaret Simpson Marketing 48,000 Surveys 10/7/201X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/201X110 Chris Lucero Info. System 43,000 SPSS 1/12/201X110 Chris Lucero Info. System 43,000 C++ 4/22/201X190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/201X150 Susan Martin Marketing 42,000 Java 8/12/201X

Figure 4-2 (a) Table with repeating groups – how to “remove” them (and solve the problem)

Figure 4-2 (b) EMPLOYEE2 relation

EMPLOYEE Relation (Table)

Better? Problems?



100 Margaret Simpson Marketing 48,000 SPSS 6/19/200X100 Margaret Simpson Marketing 48,000 Surveys 10/7/200X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/200X110 Chris Lucero Info. System 43,000 SPSS 1/12/200X110 Chris Lucero Info. System 43,000 C++ 4/22/200X190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/200X150 Susan Martin Marketing 42,000 Java 8/12/200X

Fig. 4-2: Eliminating multi-valued attributes (b) EMPLOYEE2 Relation (Normalized)



Any Difference?

Better?Any

Problem?

???


Constraints• Domain Constraints

– Allowable values for an attribute.– A domain definition contains: domain name, data

type, size, meaning, and allowable values/range (if applicable).

• Entity Integrity– No primary key attribute may be null.

• Referential Integrity– A relationship between primary key and foreign key.

• Operational Constraints– Business rules (see Chapter 3)


Well-Structured Relations• A well-structured relation contains minimal

redundancy and allows users to insert, modify, and delete the rows in a table without errors or inconsistencies.

• The following anomalies should be removed (as possible as we could) for a well-structured relation:– Insertion Anomaly– Deletion Anomaly– Modification Anomaly




EMPLOYEE2

Is EMPLOYEE2 a Well-Structured relation?


Is EMPLOYEE2 a Well-Structured relation?

No/Yes_____WHY?

NO

NO – since there exists “anomalies” on addition, deletion

and modification (in general, redundancy) and with TWO

THEMES (employee and course)


Well-Structured Relations• A well-structured relation contains minimal

redundancy and allows users to insert, modify, and delete the rows in a table without errors or inconsistencies.

• The following anomalies should be removed (as possible as we could) for a well-structured relation:– Insertion Anomaly– Deletion Anomaly– Modification Anomaly


Insertion Anomaly: Inserting a new row, the user must supply values for both EmpID (PK) and CourseTitle (CPK and FK). This is an (insertion) anomaly, since the user should be able to enter employee data without knowing (supplying) course (title) data.


EMPLOYEE2


Deletion Anomaly: Deleting the employee number 140, it results in losing not only the employee’s information but also the course had an offering that completed on that date.


EMPLOYEE2


Modification Anomaly: If the employee number 100 gets a salary increase, we must record the increase in each of the rows for that employee (two occurences for this example); otherwise the data will be inconsistent.


EMPLOYEE2


Fig. 4-7: EMP_COURSE: Normalized Relations from EMPLOYEE2EMPLOYEE2EmpID Name DeptName Salary Course Date Title Completed


EmpID Course Title DateCompleted

100 SPSS 6/19/201X100 Surveys 10/7/201X 140 Tax Acc 12/8/201X110 SPSS 1/12/201X110 C++ 4/22/201X150 SPSS 6/19/201X150 Java 8/12/201X

EMP_COURSEIs

there any ano-maly

?


100 Margaret Simpson Marketing 48,000140 Allen Beet Accounting 52,000110 Chris Lucero Info. System 43,000190 Lorenzo Davis Finance 55,000150 Sususan Martin Marketing 42,000

EMPLOYEE1

??




w/Team

ER or EER or OO

Transformation to Relations

Normalization(3NF)


?????

Relations Transformation(Seven Cases)

IMPLEMENTATION

Should be included in the Term Project

PHASE I

PHASE II


Seven Cases of Transforming EE-R Diagrams into Relations

1. Map Regular Entities 2. Map Weak Entities3. Map Binary Relationships4. Map Associative Entities5. Map Unary Relationships6. Map Ternary (and n-ary) Relationships7. Map Supertype/Subtype Relationships


Transforming EE-R Diagrams into Relations

1. Map Regular Entities to Relations E-R attributes map directly onto the relation

(Fig. 4-8) Composite attributes: Use only their simple,

component attributes (Fig. 4-9). Multi-valued Attribute : Becomes a separate

relation with a foreign key taken from the superior entity (Fig. 4-10).


Fig. 4-8: Mapping the regular entity CUSTOMER

(a) CUSTOMER entity type

(b) CUSTOMER relation [Same name on relation and entity type]


Figure 4-9 Mapping a composite attribute

(a) CUSTOMER entity type with composite attribute

(b) CUSTOMER relation with address detail[Use only their simple, component attributes]


Fig. 4-10: Mapping an entity with a multivalued attribute(a) Employee entity type with multivalued attribute

EmployeeID EmployeeName EmployeeAddressEMPLOYEE

EmployeeID Skill

(b) Mapping a multivalued attribute

Multivalued attribute becomes a separate relation with foreign key

[Two relations created with one containing all of the attributes except the multi-valued attribute, and the second one contains the pk (on the first one) and the multi-valued attribute]

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

pk

cpk

fk


MVC_Hospital HWLogical Design Phase

Draw a entity-relationship diagram (enterprise model) for Mountain View community Hospital, based on the narrative description of the case and this handout (but the entities are from the five (5) figures shown above). You should create a file and turn in with a hardcopy (called MVC_Hospital_DD.docx) contains the following materials:

1. Read and employ materials from chapters 2,3 and 4.2. Include entities, associations (with detail cardinality), and attributes.3. Determine and draw the order of entering data

Next phase -- implementation, create SQL script file for table structure and data base (values).


MVC_HospitalPhase II.

(a) Create a graphical relation based on your final ERD (yours or my version) with pk, cpk, fk and field type, field size etc. such as JustLee_DDL. Name this file as MVC_PhaseI_ERD-2_Lastname_Firstname.docx

(b) a script file (MVC_PhaseII_Lastname_Firstname.SQL) that contains a set of commands of DROP, CREATE, and INSERT that performs the same functions as in the script file of Northwoods.sql

(c) Save your spooled file (both script file and result from SQL) as MVC_PhaseII_Spool_Lastname_Firstname.txt Upload three files: MVC_ERD2, *.sql and *.txt files to the Bb. Turn in ONLY spooled file. (*.txt)

Phase III. (a) Second script file (MVC_PhaseIII_QUERIES_Lastname_Firstname.SQL) containing a

set of SQL commands that answer the questions. Test the query one/time successfully.Note that you may need other SQL commands and create database views for the purpose of

answering questions easily. You may need to read other references related the SQL from the text book (e.g., Chapters 6 & 7 of the main text).

(b) Save the spooled file as MVC_PhaseIII_Spool_Lastname_Firstname.txt. Finally, you create a new file (*.docx) containing all work done from Parts I, II and save them in the file MVC_Hospital_Complete_Lastname_Firstname.docx.

(c) The file should contain your class and personal information, information for each question (re-type with question number) as well as each individual query and result.

Upload both *.sql and *.txt files to the Bb. Turn in only spooled file (*.txt)


Break ! (Ch. 4 - Part I)

In class exercise#1-III (a)(b) (p.158), apply Figure 2-8 (p.59)

HW# 1-III (c), applyFigure 2-11.a (p.65)

Fig. 3-8:Figure 2-8


#1-I(a), p.227

#1-I(b)

#1-III(a), p.158

#1-III(b)


Fig. 2-11: An associative entity (p. 64)

(a) Attribute on a relationship (Link Attribute/Associative)

#1-I (c)

37

#1-I (c)

EmployeeiD EmployeeName

EMPLOYEE

EmployeeID CourseID DateCompleted

CERTIFICATE

COURSE

CourseID CourseTitle

Birth_Date

38

#1-I (c)


EMPLOYEE


CERTIFICATE

COURSE


Birth_Date

{ Topic }

?

39

#1-I (c)


EMPLOYEE


CERTIFICATE

COURSE


Birth_Date

(see 3NF on the next Slide)

TopicCourseID

cpk

Answer to: #1-I (c) 3NF

Topic

Why?




w/Team

ER or EER or OO


Normalization(3NF)


?????


IMPLEMENTATION


Seven Cases of Transforming EE-R Diagrams into Relations

1. Map Regular Entities 2. Map Weak Entities3. Map Binary Relationships4. Map Associative Entities5. Map Unary Relationships6. Map Ternary (and n-ary) Relationships7. Map Supertype/Subtype Relationships


Transforming EER 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• Primary key of identifying relation

(strong entity) (Fig. 4-11)


Fig. 4-11: Example of mapping a weak entity

(a) Weak entity DEPENDENT

Fig. 4-11: (b) Relations resulting from weak entity

Question: Why need all FOUR attributes to be a CPK?

[Becomes a separate relation with a foreign key taken from the superior entity]

FK

PK

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


Transforming EE-R Diagrams Into Relations

3. Map Binary Relationships– One-to-Many - Primary key on the one side

becomes a foreign key on the many side (Fig. 4-12).

– Many-to-Many - Create a new relation with the primary keys of the two entities as its primary key (Fig. 4-13).

– One-to-One - Primary key on the mandatory side becomes a foreign key on the optional side (Fig. 4-14).


Fig. 4-12: Example of mapping a 1:M relationship(a) Relationship between customers and orders

Fig. 4-12: (b) Mapping the relationship [Primary key on the one side becomes a foreign key on the many side]

Note the mandatory one

Foreign key

Again, no null value in the foreign key…this is because of the mandatory minimum cardinality


MVC


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


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

b) Three resulting relations

New intersection

relationForeign key Foreign key

Composite primary key (cpk)

pk

pk


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.

mandatoryoptional


Fig. 4-14: (b) Resulting relations

[Primary key on the mandatory side becomes a foreign key on the optional side]

FK

PKSame domain as Nurse_ID

mandatory

optional



4. Map Associative Entities– 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) (Fig. 4-15)

– Identifier Assigned • It is natural and familiar to end-users.• Default identifier may not be unique. (Fig. 4-16).


Figure 4-15 Example of mapping an associative entity

a) An associative entity

B A

ABA

Order_IDProduct_ID

Identifier Not Assigned


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

b) Three resulting relations [Default primary key for the association relation is the primary keys of the two entities]

Composite primary key formed from the two foreign keys

cpk

fkfk

PK

PK

Identifier Not Assigned


Figure 4-16: Mapping an associative entity(a) Associative entity (SHIPMENT)

(b) Three resulting relations

[Default primary key for the association

relation is assigned]

Primary key differs from foreign keysfkfkPKIdentifier Assigned



5. Map Unary Relationships– One-to-Many

• Recursive foreign key in the same relation (Fig. 4-17).• A recursive FK is a FK in a relation that references the

PK values of that same relation. It must have the same domain as the PK.

– Many-to-Many - Bill-of-materials: 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. (Fig. 4-18).


Figure 4-17 Mapping a unary 1:N relationship(a) EMPLOYEE entity with unary relationship

(b) EMPLOYEE relation with recursive foreign key

A recursive FK is a FK in a relation that references the PK values of that same relation.It must have the same domain as the PK.

EmployeeID EmployeeName EmployeeDateOfBirth

EMPLOYEEManagerID

fk

pk


Figure 4-18: Mapping a unary M:N relationship

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

(b) ITEM and COMPONENT 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.

ItemNo ItemDescription ItemUnitCost

ItemNo ComponentNo QuantityCOMPONENT

ITEM PK

fk fkcpk



6. Map 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– (Fig. 4-19).


Figure 4-19 Mapping a ternary relationship

a) PATIENT TREATMENT Ternary relationship with associative entity

Physican_IDPatient_IDTreatment_Code


b) Mapping the ternary relationship PATIENT TREATMENT

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

A patient may receive a treatment one in the morning, then the same

treatment in the afternoon.

cpk

fk fk fk


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 very cumbersome

key…

It would be better to create a

surrogate key like Treatment#

How to create it with Oracle?


Transforming EER Diagrams into Relations

7. 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 (Fig. 4-20).


Figure 4-20 Supertype/subtype relationships


Figure 4-21 Mapping Supertype/subtype relationships to relations

These are implemented as one-to-one relationships

Display a table that contains all the attributes for SALARIED_EMPLOYEE

SELECT *FROM EMPLOYEE, SALARIED_EMPLOYEEWHRE Employee_Number=S_Employee_Number;


-- version A for service_charge_view that includes patient_no and Patient Name [for Query1(A)CREATE OR REPLACE VIEW service_charge_view (Patient_No,Patient_Name, Item_Code, Service_Charge) ASSELECT patient.patient_no, patient.p_first || ' ' ||patient.p_last, item.item_code, (item_charge*ITS.num_times_serviced)FROM patient, item, ITEM_SERVICE ITSWHERE item.item_code = ITS.item_codeAND ITS.patient_no = patient.patient_no ORDER BY patient.p_last;

Hint: You need to create VIEW (one or more) to help you create SQL efficiently and effectively

See sample on the Bb

CREATE OR REPLACE VIEW total_service_charge_view ASSELECT patient_name, sum(service_charge_view.service_Charge) Total_Service_ChargeFROM service_charge_viewGROUP BY patient_name;


Views

• Revisit and• With SET operators – for MVC mini case


Advanced Database View (continued)• Using SET Operators (e.g., UNION, INTERSECT etc.)

– Highly recommended for MVC mini-case

• CREATE VIEW <view_name> AS <view query specification> <SET operator> <view query specification>;

e.g.,CREATE OR REPLACE VIEW customers_view (f-1, f-2, …) ASSELECT <field-1> <field-2> …FROM <table-1> <table-2> …WHERE <condition>

SELECT <field-3> <field-4> …FROM <table-3> <table-4> …WHERE <condition>;

<SET Operator>

CREATE OR REPLACE VIEW merged_view (f-1, f-2, …) AS

SELECT FROM View_1

SELECT FROM View_2;/*Note: View_1 and View_2 have been

created previously. */

<SET Operator>


Break ! (Ch. 4 - Part II)

In class exerciseTransform it to relations (NOT 3NF)#2-III-a , (p.158, apply Figure 3-6.b (p.102)(read step 7, on p.141)HW#2-III-d, (p.158), apply Figure 3-10 (p.105)

Fig. 3-8:

Figure 3-6(b)

Partial Specialization


b) Partial specialization ruleFigure 3-6 Examples of completeness constraints (cont.)


72

#2-III-a (p.158) – from Fig3-6b (p. 102)


Figure 3-10 Example of supertype/subtype hierarchy


74

#2-III-d (p.158) – from Fig. 3-10 (p.105)


Data Normalization

• The process of decomposing relations with anomalies to produce smaller, well-structured and stable relations

• Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that avoid unnecessary duplication of data







With “Multi-valued” attribute Un-Normalized Form

No “Multi-valued” attribute


Example – Figure 4.2b

Question – Is this a relation? Answer – Yes: unique rows and no multivalued attributes

Question – What’s the primary key? Answer – EmpID and CourseTitlea composite key

General rule of thumb: a table should not pertain to more than one entity type


Functional Dependencies and Keys• Functional Dependency: The value of one attribute (the

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 (pk)


Figure 4-23: Representing Functional Dependencies (cont.)

(a) Functional dependencies in EMPLOYEE1 Fig. 4-2a)

(b) Functional dependencies in EMPLOYEE2 (Fig. 4-2b)


First Normal Form• No multivalued attributes• Every attribute value is atomic (singled-

value)• Fig. 4-2a is not in 1st Normal Form

(multivalued attributes) it is not a relation• Fig. 4-2b is in 1st Normal form (but not in a

well-structured relation)• All relations are in 1st Normal Form• The following example is not from the text

will be illustrated for Normalization process.







With “Multi-valued” attribute Un-Normalized Form

No “Multi-valued” attribute (1NF)


Second Normal Form• 1NF and every non-key attribute is fully

functionally dependent on the primary key.• Every non-key attribute must be defined by the

entire key (either a single PK or a CPK), not by only part of the key.

• No partial functional dependencies.• Fig. 4-2b is NOT in 2nd Normal Form


Table with Multivalued attributes

First normalform (1NF)

Second normalform(2NF)

Boyce-Codd normalform (BC-NF)

Fourth normalForm (4NF)

Fifth normalform (5NF)

Remove Multivalued Attributes

Remove remaining anomalies resulting from multiple candidate keys

Remove Multivalued Dependencies

Remove Remaining Anomalies

Figure: 4-22 Steps in normalization

Remove Partial Dependencies

Remove …Third normalform (3NF)


A Process of 1NF to 2NF (EMPLOYEE2 - - 1NF) (b) Functional Dependencies in EMPLOYEE2

EmpID CourseTitle Name DeptName DateCompletedSalary



Dependency on entire primary key

Dependency on only part of the key


Functional Dependencies in EMPLOYEE2

EmpID CourseTitle DateCompletedSalaryDeptNameName

Dependency on entire primary key

Dependency on only part of the key (partial dep.)

EmpID, CourseTitle DateCompletedEmpID Name, DeptName, Salary

Therefore, NOT in 2nd Normal Form!!



Partial Depend.

EMPLOYEE2

EmpID Name SalaryDeptName

EMPLOYEE1

EmpID CourseTitle DateCompleted

EMP_COURSE

2NF

3NF ?

Summary on Normalization: from 1NF to 2NF


EMPLOYEE2 (1NF)EmpID Name DeptName Salary Course Date Title Completed



100 Margaret Simpson Marketing 48,000140 Allen Beet Accounting 52,000110 Chris Lucero Info. System 43,000190 Lorenzo Davis Finance 55,000150 Sususan Martin Marketing 42,000

EMPLOYEE1EmpID Course Date Title Completed

100 SPSS 6/19/200X100 Surveys 10/7/200X 140 Tax Acc 12/8/200X110 SPSS 1/12/200X110 C++ 4/22/200X150 SPSS 6/19/200X150 Java 8/12/200X

EMP_COURSE

Summary on Normalization

3NFIs

there any ano-maly (ies)?


Third Normal Form

• 2NF and no transitive dependencies (functional dependency between non-key attributes.)

• Other examples





Third normalform (3NF)










Remove Transitive Dependencies


Extra example-1: Relation with transitive dependency

(a) SALES relation with simple data

Cust_ID Name Salesperson Region

8023 Anderson 101 South9167 Bancroft 102 West7924 Hobbs 101 South6837 Tucker 103 East8596 Eckersley 102 West7018 Arnold 104 North

SALES


What Anomalies might be in SALES relation?

• Insertion anomaly ?• Deletion anomaly ?• Modification anomaly?

WHY? Because it is …

Not in the 3NF (why?)(transitive dependency)

N

Cust_ID Name Salesperson Region

8023 Anderson 101 South9167 Bancroft 102 West7924 Hobbs 101 South6837 Tucker 103 East8596 Eckersley 102 West7018 Arnold 104 North

SALES

105 – new salesperson ???



CustID NameCustID SalespersonCustID Region All this is OK(2nd NF)



CustID NameCustID SalespersonCustID Region andSalesperson RegionAll this is OK(2nd NF)

BUTCustID Salesperson Region implies

Transitive dependency(not in 3rd NF)

CustID Region


Extra example-1: (b) Relations in 3NFRemove a transitive dependency


Extra example-1: Removing a transitive dependency

(a) Decomposing the SALES relation

SALES1

Cust_ID Name Salesperson

8023 Anderson 1019167 Bancroft 1027924 Hobbs 1016837 Tucker 1038596 Eckersley 1027018 Arnold 104

Salesperson Region

101 South102 West103 East104 North

S_PERSON

Insertion anomaly?Deletion anomaly?Modification anomaly?


Snum Origin Destination Distance

409 Seattle Denver 1,537618 Chicago Dallas 1,058723 Boston Atlanta 1,214824 Denver Los Angeles 1,150629 Minneapolis St. Louis 587

Extra example-2: Relation transitive dependencies

Transitive dependency?

?NF


Extra example-2: Relation transitive dependencies

Snum Origin Destination Distance

SHIPMENT

?NF

Snum Origin Destination 409 Seattle Denver 618 Chicago Dallas 723 Boston Atlanta 824 Denver Los Angeles629 Minneapolis St. Louis

Origin Destination Distance

Seattle Denver 1,537Chicago Dallas 1,058Boston Atlanta 1,214Denver Los Angeles 1,150Minneapolis St. Louis 587



Partial Depend.

EMPLOYEE2

EmpID Name SalaryDeptName

EMPLOYEE1

EmpID CourseTitle DateCompleted

EMP_COURSE

2NF

3NF ? (Yes)

Summary on Normalization: from 1NF to 2NF





Third normalform (3NF)










Remove Transitive Dependencies


Steps of Database Development

User view-1 User view-2 User view-3

…User view-N

Conceptual Schema (Model)

……

Logical Model(ERD or E/ERD)

Implementation(w/Physical Model)

(Seven) Relations Transformation

NORMALIZATION (up to 3NF)

(more relations produced)

(more tables created)



END of CHAPTER 4In class exercise(p.158)#3- a,b,c,d

HW (using Visio or Word)(p.158-159)#7 - a,b,c,d,e,f and#8 – a,b,c,dBonus: #9

In-class Quiz next class


MVC_HospitalPhase III: Create a script file:1. A script file (MVC_PhaseIII_QUERIES_Lastname_Firstname.SQL) containing a set of SQL commands that answer the questions. Test the query one/time successfully.Note that you may need other SQL commands and create database views (see pptx file for introducing VIEWS) for the purpose of answering questions easily. You may need to read other references related the SQL from the text book (e.g., Chapter 7 of McFadden).

2. Spool the script file and save it in the file MVC_Hospital_Spool_Lastname_Firstname.txt Finally, you create a new file (*.docx) containing all work done from Part I (including MVC_ERD2), II, III and save them in the file MVC_Hospital_Complete_Lastname_Firstname.docx. The file should contain your class information and personal information.

3. UPLOAD ALL three files (*.sql, *.txt and*.docx ) to the Bb by the deadline. Turn in ONLY the *.docx file.


-- version A for service_charge_view that includes patient_no and Patient Name [for Query1(A)CREATE OR REPLACE VIEW service_charge_view (Patient_No,Patient_Name, Item_Code, Service_Charge) ASSELECT patient.patient_no, patient.p_first || ' ' ||patient.p_last, item.item_code, (item_charge*ITS.num_times_serviced)FROM patient, item, ITEM_SERVICE ITSWHERE item.item_code = ITS.item_codeAND ITS.patient_no = patient.patient_no ORDER BY patient.p_last;



CREATE OR REPLACE VIEW total_service_charge_view ASSELECT patient_name, sum(service_charge_view.service_Charge) Total_Service_ChargeFROM service_charge_viewGROUP BY patient_name;


Views

• Revisit and• With SET operators – for MVC mini case


Advanced Database View (continued)• Using SET Operators (e.g., UNION, INTERSECT etc.)

– Highly recommended for MVC mini-case

• CREATE VIEW <view_name> AS <view query specification> <SET operator> <view query specification>;

e.g.,CREATE OR REPLACE VIEW customers_view (f-1, f-2, …) ASSELECT <field-1> <field-2> …FROM <table-1> <table-2> …WHERE <condition>

SELECT <field-3> <field-4> …FROM <table-3> <table-4> …WHERE <condition>;

<SET Operator>

CREATE OR REPLACE VIEW merged_view (f-1, f-2, …) AS

SELECT FROM View_1

SELECT FROM View_2;/*Note: View_1 and View_2 have been

created previously. */

<SET Operator>


Extra Slides

• You may study the following slides if you are interested.


Normalized vs. De-normalized

• We will study the concept and technique of “normalization and de-normalization” as well as OLTP and OLAP.

More on OLTP vs. OLAP

Fig. Extra-a: A simple database with a relation

between two tables.

• The figure depicts a relational database environment with two tables.

• The first table contains information about pet owners; the second, information about pets. The tables are related by the single column they have in common: Owner_ID.

• By relating tables to one another, we can reduce ____________ of data and improve database performance.

• The process of breaking tables apart and thereby reducing data redundancy is called _______________.

redundancy

normalization

For those have database background.

pk

pk: primary keyfk: foreign key

pk fk

• Most relational databases which are designed to handle a high number of reads and writes (updates and retrievals of information) are referred to as ________ (OnLine Transaction Processing) systems.

• OLTP systems are very efficient for high volume activities such as cashiering, where many items are being recorded via bar code scanners in a very short period of time.

• However, using OLTP databases for analysis is generally not very efficient, because in order to retrieve data from multiple tables at the same time, a query containing ________ must be used.

OLTP vs. OLAP (cont.)

joins

OLTP

pk

pk fk

• In order to keep our transactional databases running quickly and smoothly, we may wish to create a data warehouse. A data warehouse is a type of large database (including both current and historical data) that has been _____________ and archived.

• Denormalization is the process of intentionally combining some tables into a single table in spite of the fact that this may introduce duplicate data in some columns.

• The figure depicts what our simple example data might look like if it were in a data warehouse. When we design databases in this way, we reduce the number of joins necessary to query related data, thereby speeding up the process of analyzing our data.

• Databases designed in this manner are called __________ (OnLine Analytical Processing) systems.

OLTP vs. OLAP (cont.)

Fig. Extra-b: A combination of the tables into a single dataset.

OLAP

denormalized


Merging Relations(View Integration)

• In a project development process, there may be a number of separate E-R diagrams and user views created and some of them may be redundant.

• Therefore, some relations should be merged to remove the redundancy.


Merging Relations(View Integration - An example)

EMPLOYEE1( EmployeeID, Name, Address, Phone)

EMPLOYEE2(EmployeeID, Name, Address, Jobcode,

No_Years)

EMPLOYEE(EmployeeID, Name, Address, Phone, Jobcode, No_Years)


Merging Relations(Problems on View Integration)

Issues to watch out for when merging entities from different ER models:

Synonyms: Different names, same meaning. Homonyms: Same name, different meanings. Transitive Dependencies:

dependencies–even if relations are in 3NF prior to merging, they may not be after merging

Supertype/SubtypeMay be hidden prior to merging


Problems on View Integration• Synonyms: Different names, same meaning.

STUDENT1(StudentID, Name)STUDENT2(MatriculationNo,Name, Address)

STUDENT(SSN, Name, Address)• Homonyms: Same name, different meanings.

STUDENT1(StudentID, Name,Address)STUDENT2(StudentID,Name, Phone_No,Address)

STUDENT(StudentID,Name, Phone_No, Campus_Address, Permanent_Address)


Problems on View Integration• Synonyms: Different names, same meaning.

STUDENT1(StudentID, Name)STUDENT2(MatriculationNo, Name, Address)

STUDENT(SSN, Name, Address)• Homonyms: Same name, different meanings.

STUDENT1(StudentID, Name, Address)STUDENT2(StudentID, Name, PhoneNo, Address)

STUDENT(StudentID, Name, PhoneNo, CampusAddress, PermanentAddress)


Problems on View Integration• Transitive Dependencies

STUDENT1(StudentID, Major)STUDENT2(StudentID, Advisor) the result is ...

STUDENT(StudentID, Major, Advisor) ??NF

and after removing transitive dependencySTUDENT_Major(StudentID, Major) Major_Advisor(Major, Advisor)


Problems on View Integration• Supertype/Subtype

PATIENT1(PatientID, Name, Address)PATIENT2(PatientID, Room_No)

RESIDENT_PATIENT(PatientID, RoomNo)OUTPATIENT(PatientID, DateTreated)

Two subtypes are hidden prior to merging

PATIENT(PatientID, Name, Address)


Enterprise Keys

• Primary keys that are unique in the whole database, not just within a single relation

• Corresponds with the concept of an object ID in object-oriented systems


Figure 4-31 Enterprise keys

a) Relations with enterprise key

b) Sample data with enterprise key


Figure 4-31 Enterprise keys

c) Relations after adding PERSON relation

d) Sample data after adding PERSON relation


Logical Database Design

You have just learned and completed one of the most important concepts and theories, integrity constraints and normalization, for developing a quality of database.




w/Team

ER or EER or OO


Normalization(3NF)

User interviews & Integrated Model

Normalization


IMPLEMENTATION


MVC_Hospital HWLogical Design Phase

Draw a entity-relationship diagram (enterprise model) for Mountain View community Hospital, based on the narrative description of the case and this handout (but the entities are from the five (5) figures shown above). You should create a file and turn in with a hardcopy (called MVC_Hospital_DD.docx) contains the following materials:

1. Read and employ materials from chapters 2,3 and 4.2. Include entities, associations (with detail cardinality), and attributes.3. Determine and draw the order of entering data

Next phase -- implementation, create SQL script file for table structure and data base (values).


-- version 1 for charge_view that includes Patient NameCREATE OR REPLACE VIEW charge_view(Patient_No,Patient_Name, Item_Code, Charge) ASSELECT patient.patient_no, patient.p_first|| ' ' ||patient.p_last, pt_charg.item_code, (charge*num_times_admitted)FROM patient, pt_charg, itemWHERE item.item_code = pt_charg.item_codeAND patient.patient_no = pt_charg.patient_noORDER BY patient.p_last;




MVC_HospitalCreate two script files:1. a script file (MVC_Hospital_Lastname_Firstname.SQL) that contains a set of commands of DROP, CREATE, and INSERT that performs the same functions as in the script file of Northwoods.sql2. Second script file (MVC_Hospital_QUERIES_Lastname_Firstname.SQL) containing a set of SQL commands that answer the questions. Test the query one/time successfully.Note that you may need other SQL commands and create database views (see pptx file for introducing VIEWS) for the purpose of answering questions easily. You may need to read other references related the SQL from the text book (e.g., Chapter 7 of McFadden). 3. Spool (2) and save it in the file MVC_Hospital_Spool_Lastname_Firstname.LST. Finally, you create a new file (*.docx) containing all work done from Part I and save them in the file MVC_Hospital_Complete_Lastname_Firstname.docx. The file should contain your class information and personal information. 4. UPLOAD the .docx file to the Bb by the deadline.

Chapter 4 Logical Database Design and the Relational Model

Documents

Transcript of Chapter 4 Logical Database Design and the Relational Model