|
| |
Relational Design and Database Creation
RELATIONAL DESIGN MILESTONE:
Deadline: Friday, March
26th, in class, turn in your project notebook
After the proposal divider:
 | any revised
proposal, if required, clearly marked with a Last modified: date, |
| your original proposal,
including my comments and annotations, along with all prior proposals with
annotations. |
After the model divider:
| your revised
model, if required, clearly marked with a Last modified: date, |
| your original model,
including my comments and annotations. |
Make sure that your
latest model included here corresponds with the design given in the next
section! This does not mean that you cram intersection tables, tables due
to multi-valued attributes, and other tables resulting from normalization into
the model --- tables do not belong in your model, only entities/objects!
It does mean that if you decide to change the cardinality of a relationship
between entities/objects, or if you remove or add an entity/object while doing
the design, that you modify the model to reflect that.
After the (newly created and
inserted) design divider
| Recall that each logical item in the design
section should have a last modified date. |
| An annotated enumeration of functional
dependencies (the set F) for your full database design. Each FD should
be accompanied by a short rationalization as to why (with respect to the
real-world enterprise) this functional dependency should hold. Note that
I want you to cover everything that should hold, but I do not need the closure
of F, nor do I necessarily want the canonical cover for F, as I would rather
have FD's that "make sense" relative to the real-world enterprise. |
| Next, give me the set of
relational schema derived from your E-R model of the database. Each
schema definition should clearly indicate the name of the schema, the set of
attributes, along with brief descriptions of the attributes, the data types of
the attributes and, if the set of acceptable values comes from a more limited
set than the data type allows, an enumeration or precise specification of that
set, and the primary key. Also please note if more than one candidate
key exists for the relation. |
| For those relations where you
will need to be performing joins to access data from other tables, indicate
the foreign keys, that is, the non-primary key that is used in a join
condition with the corresponding primary key from another relation. |
| A print-out of a nicely
formatted SQL script whose contents is the set of SQL create statements
to realize your database design in Oracle. Please make the file easy to
read and use comments to describe each table and any attributes whose names do
not make their use self-evident, and group relations together and relate them
back to the E-R model from whence they came. In practice, you will have
a corresponding SQL script to drop the full set of tables from your
database, so that you can iteratively refine your database schema creation. |
|
PLEASE
NOTE: insert statements do not belong with the database design.
Please do not include them here. |
|