Académique Documents
Professionnel Documents
Culture Documents
Solution
The keys to remember when designing the database are that each table should store one specific
kind of information, and information should not be duplicated.
From the description, it is clear we need tables for students and courses. But how do we keep
track of student scores, enrollment, assignments, and course distribution. Do we need tables for
each of these? Here is what we know so far:
We need a table for Students that stores FirstName, LastName, StudentID, and Major.
We need a table for Courses that stores Department, CourseNumber, CourseName,
Semester, and Year.
We should have a table to store the Distribution for each course, including the Category
and Percent.
We should have a table to store the details of each Assignment, including PointsPossible
and Instance (so we know whether it is quiz 1 or quiz 2, for instance.)
We know that the following relationships exist
o A course can have 0 or more students, and a student can be enrolled in 0 or more
courses.
o A course will have 1 or more entries from the distribution table.
o An assignment must correspond to an entry from the distribution table, and each
entry from the distribution table can have 0 or more assignments associated with
it.
o For each assignment, there are scores for 0 or more students, and each student can
have scores recorded for 0 or more assignments.
Given these facts, we can construct the first draft of our entity-relationship (ER) model. Recall
that the Ns and Ms in the diagram indicate the cardinality of the relationships. For instance,
Students and Courses have a many-to-many relationship, whereas Courses and Distribution
have a one-to-many relationship.
Next, we need to have a primary key for each table. For Students, the StudentID will suffice,
since it is unique. Although a combination of Department, CourseNumber, Semester and Year
might uniquely identify a course, this is too complicated.
We will add a CourseID field as our primary key in Courses. Clearly nothing will uniquely
identify an entry in the Distribution, since two courses might have the same Category and
Percent. Therefore, we add DistributionID as the primary key. Similarly, we add AssignmentID
to Assignments. Version 2 of our ER-Model, with primary keys underlined, is given below.
Now we need to identify which of the entities (tables) are weak. That is, entities that depend on
other entities. For example, an entry in Distribution has to correspond to an entry in Courses,
so Distribution is weak. Similarly, an entry in Assignments depends on an entry in
Distribution, so Assignments is weak.
Our final ER Model shows the week entities and dependencies with double lines.
Now we are ready to convert the ER model into tables. We start by converting the non-weak
entities by simply listing all of the attributes. The non-weak entities here are Students and
Courses.
Now we add the weak entities by including the attributes, and adding as a foreign key the
primary key from the dependency. In our case, we have Distribution, which depends on
Courses, and Assignments, which depends on Distribution. The arrows in the diagram indicate
where the foreign keys are drawn from.
The next step involves dealing with one-to-one and one-to-many relationships. We have none
other than those dealt with just above. If we did, we would simply add to either table (in the oneto-one case) or the many-table the primary key from the other table.
Lastly, we need to deal with many-to-many relationships. Each of these involve two tables. For
each many-to-many relationship, we add a new table with a name relating to both tables that are
related, include as foreign keys the primary keys of the two related tables, and make that the
primary key of the new table. Also, add any attributes that are part of the relationship, and an
attribute to indicate order, if necessary.
We have two many-to-many relationshipsone between Students and Courses, and one
between Students and Assignments. The former requires no additional attributes, but the latter
requires an additional attribute to store the Points. The final list of tables is given below.
The final step is to convert the tables into SQL statements so we can create the tables in some
DBMS. Given the tables in Figure 6, this is fairly straightforward. Essentially the only choices
we still need to make are what data types to use for each attribute, and which attributes should
not be allowed to be NULL. If you think about it for a few minutes, you will realize that in our
tables, only the attribute Major is in any sense optional, so all other attributes will be required to
be not NULL. The SQL statements are given below.
Exercises
The following are the types of things you might want to do with the database. Think about how
you would do each of these. Can you use queries to get the information or perform the action, or
will you need to process the data after (or before) you extract it from the database?
1. Compute the average (or high or low) score on an assignment.
2. Compute the percentage grade for a student.
3. List all of the students in a given course.
4. List all of the students in a course and all of their scores on every assignment.
5. Add an assignment to a course.
6. Change the percentages of the categories for a course.
7. Add 2 points (or 10%) to the score of each student on an assignment. Or just to those
students whose last name contains a Q.
8. Compute the percentage grade for a student, where the lowest score for a given category
should be dropped.
Solution
We will give a much briefer solution to this problem. Here is what we know:
Exercises
Can you answer these questions by querying the database directly, or do you need to extract the
information first, and then manipulate it further? What queries would you use to do each?
1. How many songs are on album X?
2. How many albums did artist Y record?
3. How many bands is musician Z a member of? What are they? Which albums is he on?
4. How many different bands recorded song X?
5. How many albums do I have? How many bands are represented in my collection? How
many musicians are represented in my collection?
6. Are there any bands whose members are all from different countries?
7. How many albums contain at least 9 songs?