Project for MCS-243: Relational Databases (January 2000)

This web page is intended to be a summary of some key points from our oral discussion of project expectations. If there is any conflict between the two, please call my attention to this.

Stage One, Due January 21st, 10:30am

For Friday, January 21st, I expect each project team to turn in an initial report that contains a provisional description of what functionality their system is intended to provide and what database structure it will use to provide that functionality.

Given that each team has decided to use a web-based interface, it seems to me that a succinct way to describe the intended functionality would be to center this description around a set of provisional web-page designs, with just enough English text to allow a reader to make sense of the roles the different pages will play in the bigger picture and what actions they will cause to happen. These initial web-page designs can be crude hand-drawn sketches, though if you already have some HTML written, you could use a browser printout instead.

With regard to the database structure, I believe each team has chosen to focus on an E-R (or UML) design approach, as opposed to normalizing a universal table. Therefore, a sensible way to present your design would be to center it around a collection of E-R (or UML) diagrams, with enough English text to help a reader make sense of them and tie them to the system's functionality, and with a list of additional integrity constraints you have already identified. Finally, you should show what progress you have made towards translating the E-R design into actual relational tables, for example by giving the SQL "create table" statements.

Stage Two, Due January 28th, 9:00am

There are two basic expectations for Friday, January 28th: a ten-minute oral presentation, and a final written project report.

If your team has a working system, it would be appropriate to include a demonstration in your oral report, and I will provide a projection system with which to do it. However, you will want to do more than just demonstrate: you will want to explain the system's purpose and briefly sketch the design that allows you to meet that need.

If your team does not have a working system, you will still want to convey what the general purpose of the system is, what more specific functionality it was planned to provide, and how your design attempted to support that functionality. To the extent time permits, you might also try to indicate how your team's actual achievements compared with your plans.

The written report should include again all the material from Stage One, but updated to reflect design changes that happened in the second week.

It should also include information on the SQL statements that are used to actually access and update the data, whether those statements are executed in an ad hoc fashion (directly with psql) or by your PHP3 web-based interface.

The PHP3 interface itself is also a suitable topic for your report, though it should not dominate: this is a relational database course.

Finally, it is important to include a list of what still needs to be done: lower priority features you didn't implement, special cases you don't properly handle, bugs you never did track down and eliminate, nice enhancements that occur to you now that the basic functionality is in place, etc. Is the system usable in its current state? Is it adequately robust, secure, tested, user friendly? If not, explain what areas still need work.