Specifying a database: documenting what the database is supposed to contain and how to go about the overall design task itself
Databases rely on the waterfall model commonly referenced with Software Engineering. Think before doing
Elucidate (discuss), analyze, then specify
Steps to follow
Requirements - Find out what the user wants
Specification - Gather and write down details including cost and time
Feedback the specification to the user
Redo the specification and repeat 2.1 if necessary
Design a database to meet the specification from step 2
Check the design against the specification
Development - A contract is negotiated and development begins
Software is tested against the design from step 3
Implementation - The finished product is delivered to the user
User tests the software
Maintenance - Make minor changes to support the database throughout its life
Retirement - Start all over once the database or software becomes obsolete
Abstraction
Abstractly: File names of people we know
Concretely, “We will file first, middle, and last names (20 characters each) of people we know, so we can retrieve the names in alphabetical order by last name; and we will put this data in a spreadsheet format in package x.”
ER Design
Select one primary entity from the database requirements description and show attributes to be recorded for that entity. Label keys if appropriate and show some sample data.
Use structured English for entities, attributes, and keys to describe the elicited database.
Examine attributes in the primary entity (possibly with user assistance) to find out if information about one of the attributes is to be recorded.
3a. If information about an attribute is needed, then make the attribute an entity, and then
Define the relationship back to the original entity.
If another entity is appropriate, draw the second entity with its attributes. Repeat step 2 to see if this entity should be further split into more entities.
Connect entities with relationships if relationships exist.