1. More on relational databases, including 1 to 1, 1 to many and many to many relationships Please use speaker notes for additional information!

2. When designing a relational database you need to be aware of the relationships between the pieces of data and between the tables that you create. For example, in a relational database there are three possible relationships: 1 For example, if you keep name address information on one table and year end tax information on another table and each table has one record for each employee than the data is in a one to one relationship. 1 Many For example, if a donor has given multiple donations you have a one to many relationship. Each donor has given multiple donations but each donation was given by one and only one donor. Therefore there is one record for the donor on the donor table and multiple records for about the donations the donor has given on the donation table. Many For example, if you have a table of movies and a table of stars, you have a many to many relationship. One movie can have many stars and one star can be in many movies.

3. Employee table Employee ID (KEY) Employee Name Employee Address Employee Department Employee Medical Plan etc. 1 to 1 relationship Year end tax table Employee ID (KEY) Employee Gross Pay Employee Fed Taxes Employee State Taxes etc.

4. 1 to many relationship Donor Table Donor ID # (KEY) Donor Name Donor City etc. Donation Table Donor ID# Drive # Date Contribution Amount (KEY) One donor can make multiple donations so there is a one to many relationship between the records in the donor table and the records in the donation table. 111John Doe Fall River … 222Ann Brown Taunton... 11110005120250000 11110007210225000 11120009150230000 20010003190205000

5. 1 to many relationship Inventory Table Item # (KEY) Item Name On Hand On Order Reorder Point Vendor # etc. Vendor Table Vendor # (KEY) Vendor Name Contact Name 1111……..100 2222…...200 3333..….100 4444…...300 5555…...200 6666……..100 100... 200... 300... Note that Vendor # is stored on the Inventory table because an Item can only have one Vendor. The Item # could not be stored in the Vendor Table because a Vendor can provide many items.

6. Many to many relationship Movie Table Move # (KEY) Movie Name etc. Star Table Star Id # (KEY) Star Name etc. Bridge Table Movie # Star ID # Salary (KEY) 111 … 222… 333... 1000… 2000… 3000… 4000... 1113000… 1114000… 2221000… 2222000… 2224000… 3332000… 3334000...

7. Student relational database system We are going to design tables for a system to contain student information. Think of this as the type of information that would be needed for a transcript. We need: Information about the student: idno, name and address, major etc. Information about the courses the students have taken including grade Tables that will allow us to get the name of the major and the name of the course

8. Student relational database system STUDENT TABLE: Student Idno - this is the primary key since all information relates to it Name Address Phone Social Security # - this is a candidate key since it could be used as a primary key Major code Date enrolled Other information related directly to the student This table has information about the student. All of it must be dependent on the primary key. Clearly we need major information about the major as well, but that cannot be stored on the student table because the name of the major and the chair of the department directly relate to the major code, not to the student idno. Carrying them on the student table would break the rules of normalization. Therefore we need a major table. MAJOR TABLE: Major code - this is the primary key Major name Chair department

9. Student relational database system STUDENT COURSE TABLE: Student Idno Course code Primary key Semester course taken Grade Information about the courses the student has taken can not be kept on the STUDENT TABLE because they are a reoccurring group and thus break the rules of normalization. Essentially if we were to attempt to carry course information on the STUDENT TABLE we would have to determine how many slots we need (the maximum number of courses a student would be allowed to take). This is not practical and it definitely breaks the first normal form rule. The primary key has to be made up of more than one column/field because each student is allowed to take more than one course. The combination of student idno and course code and semester course was taken means that we will have a separate record for each time a course was taken by a student. The relation between student and student course table is a one to may relationship. One student can take many courses. COURSE TABLE: Course code - Primary key Course name Number credits We cannot keep the course name in the STUDENT COURSE TABLE because the course name directly relates to the course code. This breaks normalization rules. Practically speaking, we would not want to carry the course name in the STUDENT COURSE TABLE because if the course name changes we have to change it on any record. By carrying it on a separate COURSE TABLE, if the name changes we only have one place to enter that change.