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

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

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!

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

Project Part III

Midterm Part III

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

Midterm Part IV

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

Midterm Part IV Movie_CastID

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

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?

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

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

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

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

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)

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

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.

Hockey League ER Diagram 1:N – Mandatory-Mandatory

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

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

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

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

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

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

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

Normalization Example Blackboard Assignments > In-Class Activities

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

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

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

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

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

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

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.