Project Guidelines, Part 1

As the course progresses you will be building a substantial database application for a real-world scenario of your choosing. This will involve designing a relational schema for the database, and creating an actual database using a relational database management system. You will populate the database with sample data, write interactive queries and modifications on the database, and develop user-friendly tools for manipulating the database.

Some Mechanics for Project Assignments

Throughout the project, your deliverables will be due on the day and time as given on Eureka. Assignments submitted after the due date/time may not receive credit. For all submitted work, include your name (both within and in the name of the submission) and contact information. As always when submitting more than one file or document, you should create a tar or zip file that when expanded will create a folder having your name. For this project, you may optionally append an indication of the deliverable contained therein.

Choosing Your Database Project

For your first task, you must identify the domain you would like to manage with your database. I suggest that you pick an application domain that interests you, since you'll be working on the same problem for the rest of the semester. I predict that if you pick something about which you are excited -- a hobby, material from another course, a research project, etc. -- you will maximize what you learn from this class (not to mention maximizing your fun in the process). You must also consider what purpose your proposed database will serve. Think about the types of queries you would want to ask of your database. If you cannot come up with interesting questions to ask of the data, then your project will probably be painful to complete.

Try to pick an application that is relatively substantial, but not too enormous. For example, after expressing it in the entity-relationship model, you might want your design to have in the range of five to seven entity sets, and a similar or slightly larger number of relationships. A reasonable design might have a total number of entity sets plus relationships in the 10-18 range; I will look askance at proposals having more or fewer. Be aware, however, that entity sets or relationships that should be represented by attributes instead (a matter we'll discuss in class) do not count. If in doubt, pick a more complex domain and then only model a sufficiently rich subset.

Entity-Relationship diagram

Having settled on a problem domain for your project, your next step is to construct an entity-relationship diagram. Your entity-relationship diagram should reflect a moderate number of entity sets and relationships -- in the 10-18 range. You should already be thinking about the types of queries you want to run. In other words, what is the intended purpose of the database? The answer to this question should guide your modeling process.

You should certainly include different kinds of relationships (i.e., many-one, many-many, one-one) and different kinds of data (strings, integers, etc.), but your application is not required to use features such as subclassing, multiway relationships, or weak entity sets, if they are not appropriate for your application.

  1. Create an entity-relationship diagram for your proposed database. As always, don't forget to underline key attributes and include arrowheads and rounded arrows indicating the multiplicity of relationships. If there are weak entity sets, indicate them by doubled shapes, as described in class. I suggest you use a drawing tool for this part of the assignment, although a scanned pdf of a neatly drawn diagram is acceptable.
  2. Use the method for translating an E/R diagram to relations that we covered in class and in the text in order to produce a set of relations from your E/R design. Specify your relational schema using the notation introduced in class and be sure to underline key attributes.
  3. Are there any flaws in the relational database schema you get from step 2? Are there opportunities to combine relations without introducing redundancy? If so, indicate these, and if not, indicate that you found none. Are there examples of non-BCNF relation schemas? If so, do you want to decompose them? For each opportunity to combine or decompose relations, decide whether or not to do so, and explain your reasoning briefly (e.g., explain what queries you expect will be typical for your database, and tell how the design you pick facilitates them). Is there anything you still don't like about the schema (e.g., attribute names, relation structure, duplicated information, etc.)? If so, modify the relational schema to something you prefer. You will be working with this schema quite a bit, so it's worth spending some time to make sure you're happy with it.

Project 1 Deliverable Requirements

Write a document that describes in words the database application you propose to work with throughout the course. Your description should be brief and relatively informal but should include sufficient motivation to explain why this is an interesting database proposal and sufficient description to discern that your scope is not too large or too small. If there are any unique or particularly difficult aspects of your proposed application, please point them out. Your description will be graded on suitability, completeness and conciseness.

In your submission, include your entity-relationship diagram as described above. Don't forget to save a copy of your E/R diagram for later reference and revision as you work on subsequent parts of the PDA.