Semester Project
Tom Kelliher, CS 318
Jan. 28, 2002
This project description is adapted from the following:
-
http://www.stern.nyu.edu/~vassalos/class/db/
-
http://www.cs.umd.edu/class/fall2001/cmsc424-0101/
-
http://courses.cs.vt.edu/~cs4604/
You will find it useful to visit these sites and poke around.
The goal of the semester project is to implement an application of a
database system. This includes:
- Finding an application for which a database system would be required.
- Modeling the domain of the application, and defining the application
functionalities.
- Designing and implementing the schema.
- Populating the database.
- Building the application.
Projects will be done in groups of 3--4 students.
Students are encouraged to pick an application domain that excites them,
provided it has a nontrivial database component. See the suggestions
below.
Every project should illustrate the following features:
- Conceptual design of the domain.
- Schema design for the application.
- Sophisticated querying.
- Database updates.
- Use of multiple views.
A web front end to the application, using PHP, is expected.
Here are some guidelines that should help you make project decisions. Of the
following, the first three guidelines are the most important.
- Effective use: Try to make effective use of as much of the course
material as possible. As we progress through this course, try to
incorporate what we learn into your projects. For example, use joins,
aggregates, indexes, triggers, etc.
- Completeness: The project must be complete and stable enough for a
good demonstration at the end of the course. This requirement is very
important. If you are unable to give a reasonable demonstration, your
project grade will suffer greatly.
- Database size: All project databases must be of nontrivial size. You
may interpret nontrivial based on your application. However, (1) there
should be at least 10 nontrivial relations; and (2) the total number of
attributes times the total number of tuples should be at least 5000. (These
are guidelines only; if you feel your application warrants exceptions, come
see me during office hours.)
- Practicality: The application you build should be of practical use to
a sizeable community (at least in the foreseeable future).
- Innovation: The more innovative ideas you include in your project,
the more credit you will receive.
- Miscellany: In addition to the above, your project grade will take
into account factors such as teamwork, overall effort, timeliness, answers
to questions about the project, justification of design decisions, and
intermediate and final project reports.
There are several milestones we will follow to help you with assessing
progress:
- Groups formed: Feb. 1.
- Proposals: Feb. 8.
- E/R design: Feb. 22.
- Formal specification: Mar. 8.
- Sample end to end application: Apr. 5.
- Project demonstration, outside of class by appointment: week of
Apr. 29--May 2.
- Final project report due: May 3.
Each group is permitted two ``slide'' days, although the groups formed, the
project demonstration, and the final project report due date are hard
deadlines --- no slides permitted. Otherwise, 10% of the final project
grade will be deducted for each day a milestone is late. Deliverables are
due by 5:00 PM on the due date.
One member from each group must send an e-mail to Send mail to kelliher AT DOMAIN goucher.edu
with:
- The members of the group.
- The group name.
- The URL of the group web page. Note: all documents posted to the
group web page must be readable using Netscape running on any OS platform.
This rules out posting MS Word documents, for example. You may post PDF
documents.
Be sure to consider the following in selecting your partners:
- Project interests.
- Working style.
- Goals.
- Target grade.
- Availability outside of class.
- Strengths and weaknesses.
Do not be shy about interviewing potential partners --- you are forming a
short-term business venture. For the purpose of creating the formal
specification, I would suggest that each group contain at least one person
from the software engineering class of fall 2000.
Students must put on their group web pages (this should only be a page or
less long):
- Project description: what is the domain, what aspects of the domain
will be modeled by the database.
- What are the application specifications? I.e., what functionality will
the system provide?
- What is the role of each project member in the project?
- Schedule: what are the landmarks in your work.
- Other, more specific comments if appropriate.
The proposals are meant to get you to start thinking about the project, get
into groups and create a plan. All group proposals must be unique. Send
an e-mail containing the URL of your proposal to the entire class
(GC_CS_318_001_SPRING_2002@gnav.goucher.edu
) once your group has
posted its completed proposal.
Each group must post to their project web site:
- E/R diagrams.
- Relational schemas.
- A written description detailing exactly what data their database will
contain.
Each group must post to their web site:
- What data they will have in their final application.
What tables are you creating, containing what pieces of information each.
(That means revisiting your design and figuring out for good what tables
you need to create, taking into account the principles of good design and
your desired functionality.)
- What constraints exist and how they are modeled.
- What functionality the final application will have; each project
should have at least one cool feature. (The tasks each user of the system
(including the system administrators) will be able to perform with your
application.)
- Updated division of labor.
Each group must post to their project web site:
- A couple of screen shots of their application running a simple query:
getting the data from the database, and putting it into a simple
version of the final application of the project.
Each group must have a demo of their project.
By May 3, each group must have on their web site in its final form (no
working after the deadline):
- A short description of the finished project.
- A description of how this differed from their formal specifications,
if at all.
- Documentation for their application. The documentation should
address the person who will be installing and maintaining the application.
(That is, the system administrator, not the end user.)
Also by May 3, each student is required to email me with the
following information:
- How long did you work on the project?
- What did you like the best about the project?
- What did you like the least about the project?
- What helped you learn the best in the project?
- What distracted from your learning in the project?
- If you could change the way that the project was organized, what would
you change?
Answering these brief questions will help me make future projects better.
The following ideas are merely suggestions --- you have to flesh out your
specific application. Also see:
- Movies and reviews database.
- Online store (books, CDs, mp3s etc).
- Support browsing, searching, shopping cart, personalization.
- Model and include product information such as hierarchy of book
topics, or music genres.
- Apartments.
- Model apartments and their properties, areas of town and their
various properties (e.g., bus lines, crime rate distance from various
landmarks).
- Offer apartments for rent, browse apartments, query using specific
criteria.
- Library DB.
- Search collections, check status.
- Integrate with the Goucher Library DB (hard).
- Job classifieds database.
- Openings, contacts, references, reviews, requirements, bidding, ...
- Database of web sites.
- Model web sites: topic, URL, organization to which they belong,
other sites they point to, reviews of the site, quality, etc.
- Update capability: New sites, new reviews of sites.
- Browse and search capabilities.
- Personalization.
See Yahoo.com for a partial inspiration.
- Room scheduler.
- Historical stock price data.
- retrieve, parse, and store stock price information from *public
domain* sources over time.
- implement browsing and querying that can be used to discover
trends, records, trivia.
- Goucher administrative database.
Simple idea, you have to come up with interesting functionality. GNAV,
perhaps?
- Personal Information Manager (PIM)
- contacts, addresses, phones, ...
- appointments.
- diary
- to-do list
Thomas P. Kelliher
Mon Jan 28 08:50:00 EST 2002
Tom Kelliher