|
| |
Final
Project Phase
FINAL VERSION MILESTONE
Deadline: Monday, May
3rd, in class, turn in your project notebook
Cover Page:
The cover page should appear before the
first divider and should include detailed information including the author,
date, professor, class, and a title for your completed class project. You
may include additional information as desired.
For all of the sections that follow, make sure
that the latest version of the required element is on top and reflects the
final database design. Neatness counts and you should seriously
consider whether or not you want hand-written or hand drawn elements to
represent your final product.
1. After the proposal divider:
 | any revised
proposal, if required, clearly marked with a Last modified: date, |
| any intervening proposal
modifications, |
| your original proposal,
including my comments and annotations, along with all prior proposals with
annotations. |
2. After the model divider:
| your revised
model, if required, clearly marked with a Last modified: date, |
| any intervening model
modifications, |
| your original model,
including my comments and annotations. |
3. After the design divider
| your revised
design, if required, clearly marked with a Last modified: date, |
| any intervening design
modifications, |
| your original design,
including my comments and annotations. |
| This includes your justification that your
database is in BCNF. |
4. After the contents divider
| A dated printout of the results of
a SELECT * for every table in your final design. If you have added
content to any or your tables during the course of designing your
queries (and this is very common) then you should show this new content here,
as well as retain the record of the original content. |
| Explain what prompted all changes in the
database population. |
| Guidelines for readable output (monospaced
and one tuple per output line) from the last milestone apply here as well.
Refer to the population milestone for complete details. |
New Sections
5. After the queries divider
| Begin with a set of SQL scripts, one per SQL
query being demonstrated. These should be well commented and describe in
enterprise-terms the purpose of the query and the rationale for how it is
structured. I am not asking for relational algebra, but the prose should
be rich enough that I understand what is attempted without close inspection of
the SQL. |
| The SQL scripts should then be followed by a
print-out of the result of running the scripts. Each should be clearly
labeled and the output should follow the same readability guidelines as the
population milestone. |
| The composition of the queries should conform
to that described in class:
 | At least eight (8) substantially-different
and structurally-different representative queries, including at least some
"innovative ones" |
| Note that you can use an sqlplus prompt
command to give additional information, like the purpose of the query to the
user, and will be helpful in separating what results go with what queries. |
| Ensure there is at least one join, at least
one nested query, at least one appropriate use of an aggregate function (such
as min(), max(), avg(), sum(), etc.) within a select statement; at least one
group-by, and at least one compound where condition (with at least a couple of
sub-conditions that are other than join conditions). Note that these are
structurally different and these requirements are not in-addition-to
the query count of eight given above. |
|
| Make sure you have enough sample data so that
these results make a meaningful demonstration. |
5. After the reports divider
| Begin with a set of SQL scripts, one per
report being demonstrated. These should be well commented and describe in
enterprise-terms the purpose of the report, how it relates to the user(s)
generating and/or receiving the report. Remember that while queries are
supposed to answer a particular question, the purpose of a report is to
provide a summary of more of the content of the database. Sometimes the
difference really comes down to quantity: while a query generates a single
tuple or a small set of tuples, a report may generate dozens or more tuples.
In general, a report is designed to be more human readable and to present
information in tabular form. See section 5.3.2 of your textbook for
another example. |
| The SQL scripts should then be followed by a
print-out of the result of running the scripts. Each should be clearly
labeled and the output should follow the same readability guidelines as the
population milestone. |
| The composition of the queries should conform
to that described in class:
| At least three (3) substantially-different
and structurally-different representative reports. |
| At least two of your reports should be based
on queries involving more than one table. You may employ concatenation
to put together a full name or an address into a more readable form. You
may also employ more than one query to construct a report. For instance,
you may have a table with sales of a particular item or set of items, and then
also compute a sales total. |
|
| Make sure you have enough sample data so that
these results make a meaningful demonstration. |
| The purpose of these reports is to
demonstrate how your database might be used, and so should not just be output
of a table. Ask yourself what would be most useful for the target user
of the database. |
6. After the discussion divider
| Discussion #1: How can this implemented
database now be used?
| You must provide a full page of discussion
about how your particular database, now implemented, can be used within your
proposal's scenario. |
| Be specific about how it may be used to meet
some of the goals of your original proposal, or how it may be used in
different ways that you've thought of since writing the proposal. |
| For those of you who concern yourself with
how long, this page (or more) should be 12 pt Times Roman font, double spaced,
with no more than 1 inch margins (top, bottom, left, right) |
| Don't use formatting tricks to "fill out" the
page with blank lines at the top, or between paragraphs, etc. |
|
| Discussion #1: How can this implemented
database now be maintaned?
| You must provide a full page (or more) of
discussion about how your particular database, can be maintained over time.
Who updates the data and with what frequency? What kinds of different
interfaces do you envision for maintenance? |
| What kind of issues might arise with regard
to keeping the database current and useful over time? Can any of these
processes be automated, and if so, from what source and be what mechanism? |
| For those of you who concern yourself with
how long, this page (or more) should be 12 pt Times Roman font, double spaced,
with no more than 1 inch margins (top, bottom, left, right) |
| Don't use formatting tricks to "fill out" the
page with blank lines at the top, or between paragraphs, etc. |
|
7. After the source code divider
| As discussed in class, I would like a
permanent record of your work. In particular, I would like a CD burned
with everything that I would need to re-create your database, including
scripts for table creation, database population, and all queries and reports. |
| Also include a printed list that contains the
names of all files on the CD, with at least a categorized description of their
purpose. |
| Step by step instructions for creating and
populating your database. These last two items should also be included
in a file named README at the root of the CD filesystem. |
8. After the misc divider
| Anything else that you wish me to consider
when grading your project. This may include, but is not limited to
anything you have done to give a more user-friendly interface. So
efforts in OCI programming, or Perl access, or PHP and Web access would all
fall into this category. |
| If you tried something, but it did not work
out, you should give yourself a chance for partial credit here as well. |
| If you have made some extra effort, and you
want to make sure that I do not overlook it while grading your project,
mention it/show it off here! |
Remember, a well-done project can be a package
to add to your portfolio and may well be something you could bring to
interviews, or possibly even use as a reference for future databases that you
design.
|