Logical Database Design and the Relational Database

TM 6-TM 6-11Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database SystemsBusiness Database Systems

Logical Database Design andthe Relational Database

Professor Chen

School of Business Administration

Gonzaga University

Spokane, WA 99258


What is a Relation?

• A relation is a named, two-dimensional table of data.

• Each relation consists of a set of named columns and an arbitrary number of unnamed rows.

• Not all table are relations


Fig. 6-1: EMPLOYEE1 Relation with sample data

EMPLOYEE1

Emp_ID Name Dept_Name 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


Relational Definitions

• Relation– Every relation has a unique name.– Every attribute value is atomic (singled-value)

(Fig. 6-1)– Every row is unique.– Attributes in tables have unique names.– The order of the columns is irrelevant.– The order of the rows is irrelevant.


Fig. 6-2: Eliminating multi-valued attributes

(a) Table with repeating groups (Un-Normalized)

Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed

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


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

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


Fig. 6-2: Eliminating multi-valued attributes

(b) EMPLOYEE2 Relation (Normalized)


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

EMPLOYEE2


Relational Keys and Structures

• Primary Key

• Composite Key

• Foreign Key– One-to-Many Relationship– Many-to-Many Relationship

• Intersection Data

• Candidate Key

• Surrogate Key


Fig. 6-3: Schema for four relations (Pine Valley Furniture) Graphical Representation


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


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

• Operational Constraints– Business rules (see Chapter 4)


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

pk

pk

ck/pk

pk

fk

fkfk


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


Referential Integrity (Summary)

• Addition - you can’t add (insert) an ORDER record if Customer_ID (FK) does not exist (or does not match) a Customer_ID (PK) in the CUSTOMER table.

• Deletion - you can’t delete a CUSTOMER record if there is (are) related Customer_ID in the ORDER table.


Integrity Constraints

• Referential Integrity– A rule that states that either each foreign key

value must match a primary key value in the other relation or else the foreign key value must be null.

– For example: Delete Rules• Restrict

• Cascade

• Set-to-Null


Referential Integrity (Conclusion)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…

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

common fieldfk

pk

pk


Referential Integrity (Conclusion)

TABLE-1(CUSTOMER)

TABLE-(ORDER)

RULES:

1. You can’t add a record to TABLE- (or the table with fk) unless there is a corresponding record in TABLE-1 (or the

table with pk).

2. You can’t delete a record in TABLE-1 (or the table with pk) ifthere is a record in TABLE- (or the table with 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



TABLE-1 TABLE- (FACULTY) (STUDENT)

RULES:

1. You can’t add a record to TABLE- (or the table with fk,e.g., STUDENT) unless there is a corresponding record inTABLE-1 (or the table with pk).

2. You can’t delete a record in TABLE-1 (or the table with pk,e.g., FACULTY) if there is a record in TABLE- (or the tablewith fk).


Order of Entering Data and Referential Integrity

STUDENTpk fk


105 Connoly 9188 3

FACULTY pk fk



45 CR 101 150… …57 LIB 222 1

LOCATION

FACULTY

STUDENT

STUDENTpk fk


105 Connoly 9188 3

FACULTY pk fk



45 CR 101 150… …57 LIB 222 1

TABLE-1 TABLE- (FACULTY) (STUDENT)

RULES:

1. You can’t add a record to TABLE- (or the table with fk,e.g., STUDENT) unless there is a corresponding record inTABLE-1 (or the table with pk).

2. You can’t delete a record in TABLE-1 (or the table with pk, e.g., FACULTY) if there is arecord in TABLE- (or 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?


Is EMPLOYEE2 a Well-Structured relation?

NO!

WHY?


Insertion Anomaly: Inserting a new row, the user must supply values for both Emp_ID (PK) and Course_Title (CK 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); otherwise the data will be inconsistent.


EMPLOYEE2


Fig. 6-7: Normalized Relations from EMPLOYEE2EMPLOYEE2


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



Emp_ID Course_ Date_ Title Completed100 SPSS 6/19/199X100 Surveys 10/7/199X 140 Tax Acc 12/8/199X110 SPSS 1/12/199X110 C++ 4/22/199X150 SPSS 6/19/199X150 Java 8/12/199X

EMPLOYEE1 EMP_COURSE


Normalization

• Normalization is the process of decomposing relations with anomalies to produce smaller, well-structured and stable relations.


Data Normalization

• Normalization is a formal process for deciding which attributes should be grouped together in a relation (see Fig.6-7 next).

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


Fig. 6-7: Normalized Relations from EMPLOYEE2EMPLOYEE2





Emp_ID Course_ Date_ Title Completed

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

EMPLOYEE1 EMP_COURSE


Functional Dependencies and Keys• Functional Dependency: The value of one

attribute (the determinant) determines the value of another attribute.

• Candidate Key:An attribute, or combination of attributes, that uniquely identifies a row in a relation.

• A candidate key is always a determinant, while a determinant may or may not be a candidate key.

• Each non-key field is functionally dependent on every candidate key.


Fig. 6-22:Steps in normalization


First Normal Form

• Normal form is a state of a relation that results from applying simple rules regarding functional dependencies (or relationships between attributes) to that relation.

• No multi-valued attributes.

• Every attribute value is atomic.

• Fig. 6-2a, b.



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


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 CK), not by only part of the key.

• No partial functional dependencies.

• Fig. 6-1,6-23a


Fig. 6-23: A Process of 1NF to 2NF (EMPLOYEE2 - - 1NF)

(b) Functional Dependencies in EMPLOYEE2

Partial Depend.

Emp_ID Course_Title Name Dept_Name Date_CompletedSalary




Fig. 6-23: A Process of 1NF to 2NFEMPLOYEE1

Emp_ID Name SalaryDept_Name

(a) Functional dependencies in EMPLOYEE1 (2NF)


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


Emp_ID Name SalaryDept_Name

Emp_ID Course_Title Name Dept_Name Date_CompletedSalary

Partial Depend.

EMPLOYEE2

EMPLOYEE1

Emp_ID Course_Title Date_Completed

EMP_COURSE

2NF

3NF ?

Fig. 6-23: Summary on Normalization


EMPLOYEE2 (1NF)





Emp_ID Course_ Date_ Title Completed

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

EMPLOYEE1 (3NF) EMP_COURSE (3NF)

Fig. 6-23: Summary on Normalization


Third Normal Form

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

• Fig. 6-23, 6-24, 6-25.


Fig. 6-24: Relation with transitive dependency

(a) SALES relation with simple data


What Anomalies might be in SALES relation?

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


Fig. 6-24: (b) Transitive dependency in SALES relation

Cust_ID ---> Name, Salesperson, Region and

Salesperson ---> Region

therefore ...

Cust_ID ---> Region


Fig. 6-25: Removing a transitive dependency

(a) Decomposing the SALES relation


Fig. 6-25: (b) Relations in 3NF


Snum Origin Destination Distance

409 Seattle Denver 1,537618 Chicago Dallas 1,058723 Boston Atlanta 1,214824 Denver Las Angeles 1,150629 Minneapolis St. Louis 587353 Seattle Denver 1,537

Fig. 6-26: Another example with transitive dependencies

Insertion anomaly?Deletion anomaly?Modification anomaly?


Break !


Fig. 6-26: Another example with transitive dependencies

Snum Origin Destination Distance

SHIPMENT

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

Origin Destination Distance

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


Fig. 6-22:Steps in normalization


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 - A example)

EMPLOYEE1( Employee_ID, Name, Address, Phone)

EMPLOYEE2(Employee_ID, Name, Address, Jobcode,

No_Years)

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


Merging Relations(Problems on View Integration)

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

meanings.Transitive Dependencies: e.g. (Stu ID,

Major) (Stu ID, Advisor).

Supertype/Subtype.


Problems on View Integration

Synonyms: Different names, same meaning.STUDENT1(Student_ID, Name)

STUDENT2(Matriculation_No,Name, Address)

STUDENT(SSN, Name, Address)

Homonyms: Same name, different meanings.STUDENT1(Student_ID, Name,Address)

STUDENT2(Student_ID,Name, Phone_No,Address)

STUDENT2(Student_ID,Name, Phone_No, Campus_Address, Permanent_Address)



Synonyms: Different names, same meaning.STUDENT1(Student_ID, Name)

STUDENT2(Matriculation_No,Name, Address)

STUDENT(SSN, Name, Address)

Homonyms: Same name, different meanings.STUDENT1(Student_ID, Name,Address)

STUDENT2(Student_ID,Name, Phone_No,Address)

STUDENT2(Student_ID,Name, Phone_No, Campus_Address, Permanent_Address)



Transitive DependenciesSTUDENT1(Student_ID, Major)

STUDENT2(Student_ID, Advisor)

the result is ...

STUDENT(Student_ID, Major, Advisor)

and after removing transitive dependencySTUDENT(Student_ID, Major) STUDENT(Major, Advisor)



Supertype/SubtypePATIENT1(Patient_ID, Name, Address)

PATIENT2(Patient_ID, Room_No)

PATIENT(Patient_ID, Name, Address)INPATIENT(Patient_ID, Room_No)OUTPATIENT(Patient_ID, Date_Treated)


After learning one of most important database concepts and theories...

WHAT’S NEXT ?


Relational Definitions

• Tuple

• Attribute

• View


Relational Concepts

• Relational Algebra

• Relational Calculus

• Relational Operations– SELECT– PROJECT– JOIN

• Equijoin - Join field appears twice.

• Natural Join - Join field appears once.


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.

Logical Database Design and the Relational Database

Documents

Transcript of Logical Database Design and the Relational Database