1. CSIS 115 Database Design and Applications for Business
Dr. Meg Fryling
“Dr. Meg”
Fall 2012
@SienaDrMeg
#csis115
© 2012 Meg Fryling

2. Agenda Midterm Feedback/Questions
Chapter 6: Translating ER Diagrams to Relations
Enforcing minimum cardinalities
Chapter 3: The Relational Model and Normalization

3. Heads-Up Next Quiz (Monday, 11/19)
Minimum cardinality and referential integrity (including cascade updates and deletes)
How to enforce and what those constraints mean.
As usual, can have cheat sheet!

4. Homework Chapter 3: The Relational Model and Normalization
Project Part III – Convert ER Diagram to DB Design
First fix ER Diagram to reflect feedback from Project Part II (rewrite), as needed.
Make sure you read the assignment requirements!
Turn back in your last ER diagram
Due Wednesday, 11/14 by start of class

5. Project Part III

6. Midterm Part III

7. Midterm Part III FKs in citation entity
Relationship between DRIVER and VEHICLE instead of VEHICLE and CITATION

8. Midterm Part IV

9. Midterm Part IV Cascade update if PK can change
Cascade delete on weak tables and tables created to establish M:N relationship
ActorName one field
Name fields should be required
Index all FKs

10. Midterm Part IV
Movie_CastID

11. Open Database
Blackboard Assignments > In-Class Activities > 5 - ER (Conceptual) to DB (Physical)

12. Update Parent Primary Key?
Your company has decided it wants the “Accounting and Finance” department to be department number 150 instead of 100.
Can you change it?
Why or why not?

14. Warning! Don’t use spaces in table or field names
You will run into problems with your queries.

15. Let’s Try It!
Update to reflect this design.

16. Let’s Try It!
Update to reflect this design.

17. Summary 1:1 Relationships
1:1 relationship, first entity optional
FK constraint – not required (NULL)
FK Indexed (No duplicates)
1:1 relationship, first entity required
FK constraint – required (NOT NULL)
NOTE: We do not have a way, without programming, to enforce a required second entity

18. How would you implement a 1:N relationship that is also optional-mandatory?
Set foreign key to required
Index foreign key and allow duplicates
Index foreign key and do not allow duplicates
Make foreign key the primary key as well
No can do!
Answer: E (we can’t implement without programming)

19. Summary 1:N Relationships
1:N relationship, parent optional
FK constraint – not required (NULL)
FK Indexed (Duplicates OK)
1:N relationship, parent required
FK constraint – required (NOT NULL)
NOTE: We do not have a way, without programming, to enforce a required child entity

20. Hockey League ER Diagram 1:N – Mandatory-Optional
We can’t actually enforce the maximum of 3 for coaches. That would require programming.
Make sure you enforce minimum cardinalities.

21. Hockey League ER Diagram 1:N – Mandatory-Mandatory

22. Let’s Try It! Back to HR Database
Update 1:M “belongs-to” relationship between DEPARTMENT and EMPLOYEE to enforce Mandatory-Optional (M-O) minimum cardinality

23. Hockey League ER Diagram M:N – Optional-Optional
This becomes two 1:N – mandatory-optional relationships

24. Recursive Relationships
Previous rules apply!
1:1 and 1:N add foreign key to table
M:N need to add a new table

25. Hockey League ER Diagram M:N – Optional-Optional
This becomes two 1:N – mandatory-optional relationships

26. Now, you do it! Don’t forget your translation “cheat sheet”
Blackboard
Assignments > In-Class Activities > 5 – ER (Conceptual) to DB (Physical)
Phase 4 only

27. Transforming a Data Model into a Database Design
Entity may become primary key (or use surrogate key)
Entity attributes become table fields (columns)
1) Represent each entity with a table
2) Normalize tables as necessary
Use foreign keys
Add additional tables for N:M relationships
3) Represent relationships
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

28. Normalization
Normalization is a process of analyzing a table to ensure that it is well formed and contains a single entity
We may need to split tables.
More specifically, if a relation (table) is normalized (well formed), rows can be inserted, deleted, or modified without creating anomalies
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition)
© 2008 Pearson Prentice Hall

29. Normalization Example
Blackboard Assignments > In-Class Activities

30. Deletion Anomalies
If we delete Advisor 3, we lose all the information regarding the Marketing Department.
The structure of the table forces us to lose facts about 2 different things!!!

31. Insertion Anomalies
To enter department data we are forced to enter unrelated data
Structure of table forces us to enter facts about two entities when we just want to enter facts about one

32. Update Anomalies
If we need to update FirstName, LastName, or no problem.
What if we need to update “Computer Science” to “Computer Science - Information Science”?
What bad thing can happen?

33. Update Anomalies
If we need to update FirstName, LastName, or no problem
If we update DeptCode or DeptName, we may create a data inconsistency
Which DepartName is correct?

34. Normalizing for Data Integrity
Data integrity problems happen when data are duplicated
Normalized tables eliminate data duplication
General goal of normalization is to construct tables so every table has a single topic or theme
One fact – one place!
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

35. Normalization
Normalization: Process of converting a poorly structured table into two or more well-structured tables. Problem with these tables below is they have two independent themes: Employees and Department.
Table before update
Some rows show DeptNo 100 is “Accounting and Finance” and others show DeptNo 100 is “Accounting.” Which one is correct?
Table after update – what’s wrong?
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

36. Normalization Steps
Create a new table for separate theme (repeated data).
Keep a copy of the new table’s primary key in the original table as a foreign key.
Create relationship between original and new table.