Assignment 2 Grades
Summary
This assignment was simultaneously an excercise in database design and in communication about database design. Unfortunately, sloppy communication makes it impossible to evaluate the design. When you see a comment like "Why is this not a FK?" on your assignment, keep in mind that the points are probably being subtracted not failing to making an attribute a foreign key (or an int or a date or optional) but for failing to explain the decision. Similarly, if you draw a relationship (or two) between an employee and a currency unit, I am sure you have your reasons - but they need to be explained, at least by labeling the relation ("gets paid in" or "updates the rate").
Grade distribution
| Grade | Freq |
| 100 | 2 |
| 90 | 3 |
| 86 | 2 |
| 79 | 1 |
| 75 | 3 |
| 70 | 2 |
| 66 | 1 |
| 63 | 2 |
| 0 | 3 |
Description
Must be at least two pages in length
The introduction must make it clear what problem you are trying to solve. (I can't evaluate the appropriateness of your design if I don't know what it is supposed to do.)
Use of the database must be discussed beyond a bullet-point list (either through usecases with details or in some other reasonable format).
Specific points
No clear problem statement: -5
The introduction doesn't give enough information about the domain: -5
Insufficient discussion of use: -5 to -10
Data Dictionary
Must make clear what each entity represents
Attributes must be explained. (It's ok to skip explanations for some self-explanatory items if others are explained.) It should be clear which attributes are required and which are optional.
You should either include foreign keys and label them as such or explain otherwise how the tables would be linked.
Specific points
Missing explanation of what entities represent: -2 to -5 (depending on how obvious it is)
Missing explanation of all or unclear attributes: -2 to -5
No mention of what attributes are required / can be null: -5
Misc. inconsistencies: up to -10
Entities explained in terms of unexplained acronyms (e.g. "TCP Price" vs. "XDF Price"): up to -5
Common issues for which I did not take off points:
Names don't make good primary keys because they change. "World Bank" may become "World Development Fund" tomorrow, "Apple Computers" may become "Microsoft Apple" tomorrow. Will your database handle such a change easily?
It doesn't make much sense to have tables with just one column.
At this point, I would have preferred you to describe the domains in higher-level terms like "URL" of "File Path" rather than "String" or "Date/Time" rather than "YYYY-MM-DD" (in the latter case, the database might not even give you much choice of how your dates are represented).
ER Diagram
The relations must be labeled. In many cases it is impossible to see whether a relation is drawn correctly, because there it is not clear what it is supposed to represent.
The diagram must match the data dictionary (e.g., if the DD says a FK is required, you can't have the relationship marked as "0 or 1"). In case of such a mismatch, I took off points either in the ER Diagram section or in the DD section, for mismatches, but not both.
Specific points:
Simple multiplicity mismatch: -1 to -5
Missing relation names: -5
Seriously confused diagram: up to -20
Note that diagrams that didn't make sense to me and lost a lot of points probably would have made more sense if the relations were labeled.