Objective: 

This is the most important assignment since everything builds up on it.  However you should plan on adding to and revising this database description throughout the term.

Select a topic for your database.  This will be the basis of the term long project.  Describe the data and the users interaction with the data in in approximately one to two pages.  

Pretend you are a consultant and this document is the database you are committing to produce (for a fixed price!).  In the real world this is a legal contract, you (or your company) will be required to produce the function you describe. If things are omitted, the user typically assumes that it is part of the deal.  This description of the database (not the system) is called a requirements document meaning you are required to produce what is described. 

This description will be the basis for your team members and other classmates, who are your pretend clients, to understand what the database is trying to accomplish. Your description will go through several drafts getting more and more detailed.

Assignment:

Briefly describe the organization that will use the database.  What kind of record keeping do they do now?  With a computer?  Which kind?  What hardware?  What software? Manual system?  (1 paragraph)

Focus on what kind of information (screens and/or reports) will be needed. Who will use the system?  Who will be in charge of gathering and inputting data?  Who will use the output information? Who means what position, such as clerk, manager, etc.    Who will be the contact, the person to interface with the database designer and describe requirement (this could be more than one person or organization).  Who will "sign off" on the database fulfilling client needs. 

Write 5 to 10 questions that the user will ask that require the data in the database be processed into information.  These questions will be answered by producing reports for paper of the screen. 

Describe the project so that a data model can be created.  The data model's strict syntactical rules mean that a non-ambiguous communication between designer and client will occur.  But people don't think in  E-R modeling diagrams, so preliminary requirements communications are typically done in English (or some language).  Produce this document or document plus Access tables.  Load both the MS Word description and the MS Access database onto virtual disk drive.   Post their availability and a VERY (2 to 3 sentence) brief summary on the Bulletin Board.

Details:

Select something with which you are familiar because you will be both the client and the database designer.  Select a topic that you enjoy.  

Try to find an actual user of such as system.  Perhaps there is one on the Internet.

Answer as many questions as you can in reasonable prose. Type your description using MS Word (if you have a different your word processor check it out with me first, can you "Save As" Microsoft Word?).  Upload your word processed document to your directory on the virtual disk drive.  Create a new thread for your plan on the Bulletin Board in the conference with your name.  Post the complete URL of your vistual hard drive and 3 to 5 sentences summarizing your database.

You will produce a one to two page document (using Word or some other word processor) that describes

1. the application users (audience) - who will provide the input?  Who will use the output?
2. what will the inputs be?  what will the outputs be?  Describe these in terms of the data items
3. what are the entities
4. what are the attributes of each entity

Some folk prefer to describe the Entities and Attributes by creating MS Access tables with detailed descriptions since they will have to enter it there eventually.  In other words they are using MS Access as their data dictionary.  The description of each attribute is very important. Validation rules should be explained.  Foreign keys should be noted.  Example data can be very descriptive. 

Work toward producing an E-R diagram.

Procedure: