Version of 23 November 2007

Included below are a number of absolute requirements
for your report

From the Projects schedule page: Your completed project, Project version 3, is due 11:59 Tuesday, December 4th, immediately before the last class of the semester. Hardcopies are also required and are due the next morning, before the last class on Wednesday the 5th. In particular this will allow you to hand in any hand-drawn items such as E-R designs, which should be as neat and as well-laid out as you can manage.

While grading the Project version 2 handins, I compiled many notes about the points that need emphasis in the Final Project. Those notes lead to the set of requirements described below. I suggest that you print out this page and keep it for reference while you are finishing up.

The required components and organization of your Final Project report

The list below is a step-by-step description of what should be in your Final Project Report. You are strongly urged to follow it. It's not as hard to do as you might think, because your task will consist primarily of just rearranging what is already in your version 2 report. It's not unusual to have such a dictated template, so it's worth having the experience of writing to one. You'll probably find that following the structure below makes your job easier. If you do deviate from the form below, describe how your organization differs and why you chose it. The components listed are required, unless stated otherwise. Following the list, aspects of some of the items are discussed in more detail.

1. The title section should include, first, a fully descriptive title. Then the information: your name, course, date, that it's the Final Report.
2. The Summary. This should be a summary of the entire report, not an introduction. An easy way to create a summary is to include a comment describing the point of each major section in the entire report. Another name for this section is the Abstract.
3. A brief description of the motivation for the design, e.g., a particular business or sports application.
4. A simple E-R diagram including cardinalities but including no attributes, followed by a paragraph or so describing it. This should be followed by a list with one sentence for each entity and each relationship.
5. A separate discussion of the cardinalities in the E-R diagram.
6. A careful discussion that describes which transformation rules in Sec. 6.2 were used and what tables they led to. Refer to the rules by number.
7. Now list and discuss the major attributes, including keys and foreign keys. Refer to full create statements that are probably best placed in an appendix. Discuss important points such as the choice of keys.
8. Then list the tables in the way described below.
9. Briefly describe the data you inserted or loaded into the tables in your database. There is no need to describe this for each table.
10. Describe scenarios, examples of the use of your database, and then the types of queries and updates it leads to.
11. List one or two of each of the major types of SQL commands that you have used on your database. Each should have a sample of the results, as well as a discussion of the design and effect of each SQL command you list.
12. At this point, you can give some further details about the technology you used - the database server system, source of external data, etc.
13. If you built an application, you can describe it here. You can include some code snippets, preferentially as pseudocode. Any extensive discussion of your application should be placed in an appendix.
14. Follow all of this by a general discussion of what you've done, including your successes, problems encountered, etc.
15. A brief conclusion section should round out your report.
16. For completeness, include a proper citation at the end of the report to our textbook. Follow the standard form, as in reference [2] on page 72.

Your audience

In your Final Project, or in virtually anything you ever write, you must always keep in mind your intended audience, the people who will read what you write (a report, presentation, web page, email, etc.) For this report, target a reader who is a student in Computer Science who took a database course a while ago and needs to be reminded of various things. Do not assume your reader is your instructor or another student in the class - then you would gloss over too many things, and as a grader I would then not be sure whether you actually understand something or not, unless you had explained it. And of course, don't assume that your reader knows nothing about databases, because then there would be too much to explain - you'd have to explain even the simplest things. Tread a middle course.

It always helps for you to refer to specific sections and pages in the book, so I can be sure you've paid attention to what's there.

E-R diagrams first and foremost - Transformation rules then define tables

Chapter 6 in the textbook carefully explains that an E-R design can be methodically transformed into specifications for tables. You should not discuss your tables before you describe your E-R design. All tables should follow directly from your E-R design. The classic update, insert, and delete anomalies that can occur (first part of Sec. 6.5) can largely be avoided by careful attention to the E-R design itself and to the proper use of the six transformation rules in Sec. 6.2.

The proper use of the transformation rules require that you correctly include the cardinalities in your E-R diagrams. You should of course realize that some relationships do not lead to the creation of tables, but some relationships require that you generate the corresponding tables.

Like editing, there is no such thing as just drawing a diagram - the only way to achieve a good diagram is to sketch, edit, and sketch again, until it's right. For an E-R diagram, for example, you should sketch it on paper, find ways to improve it, and then sketch it again. Only after all this should you draw the final one you hand in. Look to the examples of E-R diagrams in the book for guidance.

Presenting your tables

• In the body of your report, never display more than the table header and one representative tuple.
• If you have a large number of attributes, too wide for the page, display them vertically in a list. Or you could only show the important ones and put the full list in an appendix.
• To keep your headers and tables narrow on a page, you can consider using short names for attributes and following the header/tuple pair of rows with a list of the short names and long readable names or brief definitions.
• If you wish to show more tuples, put them in an appendix. But never include more than four or five tuples per table, even in an appendix. More should be in a separate file, e.g., an SQL dump file.
• The amount of data in your tables: You will not get a better grade because you have a large amount of data in your database. A small amount is typically all that's needed to demonstrate your design. If you do have a lot of data, I suggest that you have two versions of your database - a small one to demonstrate what you've done and a large one that you have built from some source because you find the data interesting. If you have 10,000 tuples, don't even send them. Just mention it and only show or send a small subset of them.

Discussing your SQL

You should always present your SQL statements as part of a discussion about the underlying concepts. Or put more simply, you should explain the principles behind them. For example, if you use a query on a view, use a query that you have been able to simplify because the query is simpler than would be required if you had not created the view. So don't just list a bunch of SQL statements with no discussion. Don't list many simple ones - there's not a lot to say about them.

If you have built an application in Python or JDBC or other, that includes SQL commands embedded in the code, then you must create copies of the SQL commands and list and describe them separately. I will not dig through your code to find them when grading.

"Envisioning" your database - Issues of design, scale, and complexity

What I mean by this is that you are required to describe things that would be needed for your database if it was far larger and more dynamic than the one you create. For example, certain queries on a very large version of you database could be speeded up by the appropriate indexes. So create the indexes for yours and explain how they would help. Similarly, even if you have created a "static" database - some earlier season for some sport, imagine that you are building one for an ongoing season for which you would need to do inserts, and for multiple updates that are tightly related, you would need to use transactions. Then write out commands for those inserts and transactions. Ditto deletions - imagine that something had been inserted by mistake and needs to be deleted and then give an example.

You should describe the application you imagine, but you are not required to build it.

You will need to have some use for your database to motivate and specify your database. In addition you can describe some scenarios, what a user would do at an interface, a real one you build or merely one you describe. Note carefully here that you can describe how a finished system would work without having to take the time and energy to build it. You can describe its operation in words or draw a GUI on paper, by hand, or using a drawing program.

CSU430 is a database design course, not an application development course. Your grade will be based on what you do and describe about database design and database principles. You are welcome to build an application. If you do, it only needs to be enough to demonstrate the database behind it. If you have a major application project to pursue that is backed by a database, you should do it on your own time - you shouldn't let it interfere with your work in this course. You can continue working on your own projects after the course is over. Then your startup, then success, the IPO, NASDAQ, the world ;-)

Appendices

You probably will need to include one or more appendices. These are for important or supplementary material that would clutter and interrupt your main text, the body of your Report. Typical ones are:

• A "technology" appendix describing the platform, server, and server version used, MySQL, SQL Server, Oracle, etc. If you developed an application, e.g., a LAMP or WAMP one, describe it, PL used, etc.
• Code such as Python or Java (JDBC). You may only need to include portions of your code to make your point. You are required to list any embedded SQL in your code separately. If you want to include all your code, that can be zipped up in a file attached to your email.
• SQL table creation, loading, queries, inserts, and updates. The number of these should not be small. Only include samples of them in the body of the paper, typically some that are non-trivial, such as transactions and triggers.
• Extensive screenshots, beyond one or two that you might have in the body, if you created a GUI/web-page.

Formatting and design of your Report

Your report should be laid out in such a way that it is easy to skim and read. There should be section headings, and possibly, subsection headings. There should be a blank line between paragraphs, even if they are indented. Sometimes, bulleted or numbered lists are the best way to present information.

Return to CSU430 Fall 2007 homepage. or RPF's Teaching Gateway or homepage