more on relational databases, including 1 to 1, 1 to many and many to many relationships please use...
TRANSCRIPT
More on relational databases, including 1 to 1, 1 to many and
many to many relationships
Please use speaker notes for additional information!
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:For example, in a relational database there are three possible relationships:
1 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 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.
Employee tableEmployee table
Employee ID (KEY)
Employee Name
Employee Address
Employee Department
Employee Medical Plan
etc.
1 to 1 relationship1 to 1 relationship
Year end tax tableYear end tax table
Employee ID (KEY)
Employee Gross Pay
Employee Fed Taxes
Employee State Taxes
etc.
1 to many relationship1 to many relationship
Donor TableDonor Table
Donor ID # (KEY)
Donor Name
Donor City
etc.
Donation TableDonation 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
1 to many relationship1 to many relationship
Inventory TableInventory Table
Item # (KEY)
Item Name
On Hand
On Order
Reorder Point
Vendor #
etc.
Vendor TableVendor 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.
Many to many relationshipMany to many relationship
Movie TableMovie Table
Move # (KEY)
Movie Name
etc.
Star TableStar Table
Star Id # (KEY)
Star Name
etc.
Bridge TableBridge Table
Movie #
Star ID #
Salary
(KEY)
111 …
222…
333...
1000…
2000…
3000…
4000...
1113000…
1114000…
2221000…
2222000…
2224000…
3332000…
3334000...
Student relational database system
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
Student relational database system
Student relational database system
STUDENT TABLE:
Student Idno - this is the primary key since all information relates to itNameAddressPhoneSocial Security # - this is a candidate key since it could be used as a primary keyMajor codeDate enrolledOther 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 keyMajor nameChair department
Student relational database system
Student relational database system
STUDENT COURSE TABLE:
Student IdnoCourse code Primary keySemester course takenGrade
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 keyCourse nameNumber 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.