Lecture 3. Wednesday, September 3, 2014

Transcription

1 Lecture 3 Wednesday, September 3, 2014

2 ER Diagrams Last week, we covered ER diagrams which allow us to show entities, attributes, and relationships The last component of an ER diagram is the cardinality of the relationships Cardinality tells us more about the relationship between two entities It tells us (generally) how many of each entity make up the relationship, and whether the relationship is required 1

3 Cardinality: How many? First, there are three types of cardinality regarding how many of each entity make up the relationship o One-to-one o One-to-many o Many-to-many 2

4 How many? One-to-one (1-1) o There can only be one item in each entity of the relationship o Often used when databases did not allow you to set individual permissions by table o Example: If two entities are Student and Social Security Numbers (again, separated due to security), each student has one SSN, and each SSN can belong to one person o Represented in an ER diagram as shown on the right Student has SSN 3

5 How many? One-to-many (1-M) o One entity could have more than one items of the second entity related to it o Example: If two entities are Student and Advisor, each student has one academic advisor, but each academic advisor can only have one multiple advisees o Represented in an ER diagram as shown on the right the many entity of the relationship contains a crowsfoot where the line reaches the rectangle of the entity Advisors advise Students 4

6 How many? Many-to-many (M-M) o Each entity has more than one items of the other entity related to it o Example: If two entities are Students and Courses, each student takes multiple courses, and each course has multiple students enrolled o Represented in an ER diagram as shown on the right both entities have a crowsfoot where the line reaches the rectangle of the entity Students take Courses 5

7 Cardinality: Is it required? The second part of cardinality tells us whether a relationship between two entities requires that at least one of either of the entities must exist 6

8 Is it required? Example o Example: If two entities are Courses and Meeting Reservation o Meeting Reservation consists of days of the week, start/end time, and a building/room o 1-M relationship (courses can have multiple meeting reservations, but each meeting reservation only holds one course) Does a course require at least one meeting reservation? o NO o Online courses and independent studies are two examples of courses that do not have meeting reservations on the schedule Does a course reservation require at least one course? o YES o Rooms are not scheduled to be empty! 7

9 Is it required? We represent this on an ER diagram by placing a line (one) on any entity of a relationship that must exist, and circle (zero) on any entity of a relationship that does not have to exist Courses meet at Meeting Reservation 8

10 Is it required? There can be instances where items from both, neither, or only one entity are required in one-to-one, one-to-many, and many-to-many relationships 9

11 Keys There are two types of keys that can be associated with a field in a table: o Primary key o Foreign key 10

12 Primary Keys A unique field (or fields) with in a table of data Automatically indexed to allow for faster searching Examples: o Students: WIN (only one student can have the a particular WIN) o Courses: Termcode + CRN (several courses can have the same CRN, as they are reused, but only one per term) Every table should have one but does not have to have one 11

13 Primary Keys They should be something that will not change o Example: Although cell phone number is a unique thing that only a single person can have at once, it can change so it is not ideal o WHY? The primary key is used to link related tables together, and a primary key that could change recreates the redundancy that relational databases are supposed to eliminate! If there are no ideal candidates in the existing fields, an auto-incrementing ID field can be created 12

14 Foreign Keys Fields within data that link to fields in other related tables (usually the primary key) Again, indexed to allow for faster searching Examples: o Students has WIN has a primary key o The table with registrations would have WIN as a foreign key 13

15 Normalization The process of removing redundancy from the design of a database Normal forms have been developed over the years: o First Normal Form o Second Normal Form o Third Normal Form o Boyce Codd Normal Form o Fourth Normal Form o Fifth Normal Form o Domain Key Normal Form We will focus on the first three normal forms 14

16 Why normalize databases? To avoid anomalies with updating, inserting, and deleting information 15

17 Update Anomalies Update anomalies occur because multiple records need to be updated to change one piece of information Example: If John Smith moves, his address would need to be updated once for every course he has taken STUDENT ADDRESS COURSE John Smith 123 Main St CS 325 John Smith 123 Main St CS 391 John Smith 123 Main St MTH South St 246 South St 246 South St Steve Davis 789 Franklin St CS 225 MTH 202 MTH 231 CS

18 Delete Anomalies Delete anomalies occur because removing one piece of information deletes another Example: If Steve Davis drops CS 325, we no longer have his address STUDENT ADDRESS COURSE John Smith 123 Main St CS 325 John Smith 123 Main St CS 391 John Smith 123 Main St MTH South St 246 South St 246 South St Steve Davis 789 Franklin St CS 225 MTH 202 MTH 231 CS

19 Insert Anomalies Insert anomalies occur because inserting one piece of information requires knowing another Example: If Matt Ross adds MTH 231, we also need to know his address STUDENT ADDRESS COURSE John Smith 123 Main St CS 325 John Smith 123 Main St CS 391 John Smith 123 Main St MTH South St 246 South St 246 South St Steve Davis 789 Franklin St CS 225 MTH 202 MTH 231 CS

20 First Normal Form First Normal Form (1NF) rids the table of repeating groups or arrays An entity is in 1NF if o Every attribute represents only one value o There are no repeating groups or arrays o Each row is unique Example: Consider the following table which shows which courses a student is registered for 19

21 First Normal Form This table is not in 1NF because of the array of courses This table, corrected to 1NF, would be NAME John Smith ADVISOR ADVRRM COURSES Koch SLC 422 CS 325, CS 391, MTH 231 Sullivan SLC 415 CS 225, MTH 202, MTH

22 First Normal Form This would be the corrected table in 1NF NAME John Smith John Smith John Smith ADVISOR ADVRRM COURSES Koch SLC 422 CS 325 Koch SLC 422 CS 391 Koch SLC 422 MTH 231 Sullivan SLC 415 CS 225 Sullivan SLC 415 MTH 202 Sullivan SLC 415 MTH

23 Second Normal Form Second Normal Form (2NF) rids the table of functional dependencies To convert a table to 2NF, it must first be in 1NF Items in an entity in 2NF should be dependent upon a key, not the item itself Example: Go back to the table we just created in 1NF 22

24 Second Normal Form This table is not in 2NF because the name and advisor are not dependent upon the course, and this information should rely on a key The corrected table in 2NF would be (next slide ) NAME John Smith John Smith John Smith ADVISOR ADVRRM COURSES Koch SLC 422 CS 325 Koch SLC 422 CS 391 Koch SLC 422 MTH 231 Sullivan SLC 415 CS 225 Sullivan SLC 415 MTH 202 Sullivan SLC 415 MTH

25 Second Normal Form To correct the table, we move all information associated with the student and not the course/ registration into another table, linked with a key This would give us the following tables in 2NF 24

26 Second Normal Form Students WIN NAME ADVISOR ADVRRM John Smith Koch SLC 422 Sullivan SLC 415 Registrations WIN COURSES CS CS MTH CS MTH MTH

27 Third Normal Form Third Normal Form (3NF) rids the table of transient dependencies dependencies that do not rely upon the primary key created/used in 2NF To convert a table to 3NF, it must first be in 2NF Example o Go back to the table we just created in 2NF o Is it in 3NF? No! o Why? The advisor s office is not associated with the student (the key of this new table), but the advisor o To convert this to 3NF, we split the advisor information out of the student table to get 26

28 Third Normal Form Students WIN NAME ADVISOR John Smith Faculty WIN NAME OFFICE Koch SLC Sullivan SLC