 |
|||||||||
|
COMP210: Database Design I (F'04)
Term Project
The term project is made up of a series of deliverables, each building towards the finished product: a complete relational database implementation.
Please remember that all deliverables must be submitted at the beginning of class (6:00 pm) on the date they are due. Late deliverables will be penalized 20% per working day, unless prior arrangements have been made with the instructor.
I will also build a parallel sample project, intended both as a reference for marking purposes and as a method to ensure that the individual student projects remain somewhat synchronized. The deliverables from my project will be posted to this page. Links to previous years' sample projects are also provided, but please note that the description and requirements of the deliverables may have changed since then.
To view the detailed description of each deliverable, click the links in the Deliverable column below. These descriptions will be posted to the site over the course of the term, and will also be handed out in class.
| Deliverable | Weight | Due Date | Description |
|---|---|---|---|
|
Proposal
2004 Sample 2003 Sample 2002 Sample |
5% | Sep 23 | An initial draft of the proposal must be submitted on September 23rd. The proposal outlines the general goals of the project: the "business" concept to be modelled, specific informational attributes that must be stored, and questions that the populated database will be expected to answer. I will then return this draft, unmarked, but with suggestions on adjusting the scope of your proposed project. |
| Oct 7 | The final proposal is due October 7th. This version of the proposal should incorporate some or all of the changes that I recommended, as well as any other modifications that came to light in the time since the initial draft was submitted. This version of the proposal will be graded and is worth 5% of the term mark. | ||
|
Conceptual Model
2004 Sample 2003 Sample 2002 Sample |
8% | Oct 21 | This deliverable is composed primarily of the Entity-Relationship model diagram describing the project design. |
|
Physical Design
2004 Sample 2003 Sample 2002 Sample |
8% | Nov 9 | The Physical Design is submitted as both a Relational Schema diagram of the design and the SQL DDL scripts used to produce the schema. The schema must also be implemented on the course's server, using either MySQL or PostgreSQL. |
|
DML Population
2004 Sample 2003 Sample 2002 Sample |
6% | Nov 25 | This deliverable is a set of SQL DML scripts that populate the relational schema. |
|
DML Queries
2004 Sample 2003 Sample 2002 Sample |
8% | Dec 9 | This deliverable is a set of SQL DML scripts that query the database to answer the questions originally posed by the client. |
| Total Weight: | 35% | ||
Evaluation
Each deliverable is evaluated differently due to the nature of the tasks involved. With the exception of the Final Proposal, the mark for each deliverable is made up of two components: correctness, and effort. The proposal's mark has only an effort component.
Correctness is based on whether the exercise was completed properly given the previous deliverable's outcome: were the requirements correctly modelled, was the conceptual model correctly normalized into a schema, was the schema correctly populated, etc.
Effort is admitedly more subjective and so is the smaller of the two components. The effort mark is based upon: the obvious effort expended, attention to detail, clarity of the solution and supporting documentation, conformance with notational and coding conventions, and neatness. I'm a bit of a stickler when it comes to neatness, so be warned.
Finally, since the scope of your project will likely change as the term progresses, you will be able to make changes to your project, but all such changes must be fully documented and the changes shown in updates to each affected deliverable (that is, if you changed your Physical Design, then presumably your Conceptual Model and Proposal also had to change). In other words, your project's documentation package must be completely up-to-date every time you submit it. You may wish to add a section in the latest deliverable that describes the changes, or resubmit the previous deliverables with the changes highlighted in some way. It's assumed that you will make these documentation changes; if any are missing, marks will be deducted from the total up to at most one-quarter of the deliverable's total mark. Regardless of how you choose to document changes, you must resubmit all previous copies of a deliverable that were marked by the instructor in your documentation package.
Resubmitting Corrected Deliverables
If you made mistakes or omitted necessary information for a particular deliverable, you may make the corrections and resubmit your changes together with the subsequent deliverable. If your changes are correct, you may earn back up to one-half of the marks deducted from that deliverable (rounded down to the nearest half-mark). To qualify for these marks, you must document each correction that you have made.