tm 4-1 copyright © addison wesley longman, inc. & dr. chen, business database systems chapter 4...

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 Administration

Gonzaga University

Spokane, WA 99258

[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


Problem Solving for Modeling a Database Project

Business ProblemStudy and Analyze

w/Team

ER or EER or OO

?????

Normalization(3NF)

User interview & Integrated Model

?????

?????


Relation• Definition: A relation is a ______, ______-

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

NOTE: all relations are in 1st Normal form


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)


Key Fields

• Keys are special fields that serve two main purposes:– _______ keys are unique identifiers of the relation in

question. Examples include employee numbers, social security numbers, etc. This is how we can guarantee that all rows are unique

– _______ 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 (a single field) or composite (more than one field)

• Surrogate key• Keys usually are used as indexes to speed up the

response to user queries (More on this in Ch. 5)


Sample E-R Diagram (Figure 2-1)


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)


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)


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


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/200X Surveys 10/7/200X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/200X110 Chris Lucero Info. System 43,000 SPSS 1/12/200X C++ 4/22/200X190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/200X Java 8/12/200X

EMPLOYEE


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

EmpID Name DeptName Salary Course Date Title Completed100 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

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

Figure 4-2 (b) EMPLOYEE2 relation


Fig. 4-2: Eliminating multi-valued attributes

(b) EMPLOYEE2 Relation (Normalized)


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

EMPLOYEE2


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)


Integrity Constraints• _________ Integrity – rule that 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 – don’t allow delete of “parent” side if related rows exist in “dependent” side

• Cascade – automatically delete “dependent” side rows that correspond with the “parent” side row to be deleted

e.g., DROP TABLE tablename CASCADE CONSTRAINTS; (p.110 of Oracle 11g)

• Set-to-Null – set the foreign key in the dependent side to null if deleting from the parent side not allowed for weak entities


Referential integrity

constraints are drawn via arrows from dependent to

parent table

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

pk

pk

cpk/pk

pk

fk

fkfk


Figure 4-6 SQL table definitions

Referential integrity constraints are

implemented with foreign key to primary key references


CUSTOMER

Customer_ID Customer_Name Customer_Address

123 John Smith S. 34 Freya, Spokane345 Allen Stone 45 A St. Cheney489 Mary Jones E. 21 Trent, Spokane789 Kent Watson 23 Y Ave. Spokane…

Referential Integrity (Addition and Deletion)

PK

ORDER

Order_ID Order_Date Customer_ID

OR-002 9/21/1998 123OR-003 9/30/1998 345OR-004 10/1/1998 123OR-004 10/2/1998 489… 642

FK

STUDENTpk fk

SID SLNAME … SPIN FID100 Miller 8891 1… …

105 Connoly 9188 3

FACULTY pk fk

FID FLNAME … LOCID … FPIN1 Cox 53 1181… … …5 Brown 57 9899

LOCATION pkLOCID BLDG_CODE ROOM CAPACITY

45 CR 101 150… …57 LIB 222 1

pk fk (FACULTY) (STUDENT)

RULES: 1. You can’t add a record to the table with fk, (e.g., STUDENT) unless

there is a corresponding record in the table with pk. 2. You can’t delete a record in the table with pk (e.g., FACULTY) if there is a record in the

table with fk. Order of entering data into the database: LOCATION FACULTY STUDENT Order of deleting data from the database:STUDENT FACULTY LOCATION


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 for a well-structured relation:– Insertion Anomaly– Deletion Anomaly– Modification Anomaly




EMPLOYEE2

Is EMPLOYEE2 a Well-Structured relation?




EMPLOYEE2


Is EMPLOYEE2 a Well-Structured relation?

No/Yes

WHY?


__________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


________ 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); 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 Date Title Completed100 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)


Seven Cases of Transforming EE-R Diagrams into Relations

1. Map Regular Entities

2. Map Weak Entities

3. Map Binary Relationships

4. Map Associative Entities

5. Map Unary Relationships

6. Map Ternary (and n-ary) Relationships

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

EMPLOYEE

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


Break ! (Ch. 4 - Part I)

In class exercise#1-I (a) (p.193), apply Figure 2-8.

HW# 1-I (c), applyFigure 2-11.a

Fig. 3-8:Figure 2-8




w/Team

ER or EER or OO


Normalization(3NF)


?????



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 CK?

[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


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)


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


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


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 keys



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


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

fkfkcpk



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


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.


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;


Break ! (Ch. 4 - Part II)

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

Fig. 3-8:

Figure 3-6(b)

Partial Specialization


Break ! (Ch. 4 - Part II)

In class exercise (another set)(p.193)Transform it to relations (NOT 3NF)#2-III (b)(Figure 3-7a)(see next slide)

HW#2-III (c)(Figure 3-9)


(a) Disjoint rule

Fig. 3-7: Examples of disjointness constraints


Fig. 3-9: Subtype discriminator (overlap rule)




w/Team

ER or EER or OO


Normalization(3NF)


Normalization


IMPLEMENTATION


Next Topic

• Next topic is the most important topic (theory) in this database management class.

• What is it?• Normalization


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


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 (minimize) anomalies– Insertion Anomaly – adding new rows forces user to

create duplicate data– Deletion Anomaly – deleting rows may cause a loss of

data that would be needed for other future rows– 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


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 CourseTitle

a composite key


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• Modification – giving a salary increase to employee

100 forces us to update multiple records

Because are two themes (entity types – what are they?) in this one relation (two themes, entity types, were combined). This results in duplication, and an unnecessary dependency between the entities

Why do these anomalies exist?


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


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.


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


Figure 4-2 (a)

Figure 4-2 (b)


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 _____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 DateCompleted

EmpID 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

EMPLOYEE1

EmpID 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

3NF

Is there any ano-maly (ies)?


Third Normal Form

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

• Other examples









Remove Multivalued Attributes





Remove Partial Dependencies

Remove _________Dependencies


Extra example-1: Relation with transitive dependency

(a) SALES relation with simple data

Cust_ID Name Salesperson Region

8023 Anderson 101 South

9167 Bancroft 102 West

7924 Hobbs 101 South

6837 Tucker 103 East

8596 Eckersley 102 West

7018 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 South

9167 Bancroft 102 West

7924 Hobbs 101 South

6837 Tucker 103 East

8596 Eckersley 102 West

7018 Arnold 104 North

SALES



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 101

9167 Bancroft 102

7924 Hobbs 101

6837 Tucker 103

8596 Eckersley 102

7018 Arnold 104

Salesperson Region

101 South

102 West

103 East

104 North

S_PERSON


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

Insertion anomaly?Deletion anomaly?Modification anomaly?

?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 ?

Summary on Normalization: from 1NF to 2NF












Remove ________Attributes


Remove _______Dependencies

Remove ______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 ________

_____________ (up to 3NF)

(more relations produced)

(more tables created)



END of CHAPTER 4

In class exercise(p.193)#3- a,b,c,d

HW (using Visio)(p.193-194)#7 - a,b,c,d,e,fBonus#8 – a,b,c,d

In-class Quiz next class


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;

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

See sample on the Bb


MVC_Hospital

Create 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.txt 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.


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

For those have database background.

pk

pk: primary keyfk: foreign key

pkfk

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

pkfk

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


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

• Transitive DependenciesSTUDENT1(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)

tm 4-1 copyright © addison wesley longman, inc. & dr. chen, business database systems chapter 4...

Documents