 |
|||||||||
|
COMP210: Database Design (F'06)
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 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
2006 Sample 2004 Sample 2003 Sample 2002 Sample |
3% | Sep 14 | An initial draft of the proposal must be submitted on September 14th. The proposal is a text description of the eventual database: rules, exceptions, and potential questions it should answer. I will then return this draft, unmarked, but with suggestions on adjusting the scope of your proposed project. |
| Sep 28 | The final proposal is due September 28th. This version of the proposal should incorporate some or all of the recommended changes, 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 3% of the term mark. | ||
|
E-R Model
2006 Sample 2004 Sample 2003 Sample 2002 Sample |
10% | Oct 12 | This deliverable is composed of the Entity-Relationship model diagram and accompanying E-R dictionary. |
|
DDL Schema
2006 Sample 2004 Sample 2003 Sample 2002 Sample |
8% | Oct 26 | This deliverable consists of both a relational schema diagram and the SQL DDL scripts necessary to produce the schema. |
|
DML Population
2006 Sample 2004 Sample 2003 Sample 2002 Sample |
6% | Nov 9 | This deliverable is made up of one or more SQL DML scripts that populate the relational schema. |
|
DML Queries
2006 Sample 2004 Sample 2003 Sample 2002 Sample |
8% | Nov 23 | This deliverable is a set of SQL DML scripts that query the database to answer the questions originally posed in the proposal, among others. |
| 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 converted into a schema, was the schema correctly and adequately populated, etc.
Effort is admittedly 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 evolve as the term progresses, you will be allowed and encouraged to make changes to your project, but all such changes must be fully documented and incorporated into updated versions of each affected deliverable. That is, if you changed your DDL Schema, then presumably your E-R 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 given to that deliverable. 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 correctness marks deducted from that deliverable (rounded down to the nearest half-mark). To qualify for these marks, you must fully document each correction that you have made.