Murphy’s Law: “If anything can go wrong, it will”. This is to be read by you as “The server will probably crash the night before the project is due”.
Morals:
1. Do NOT start the project the night before it is due.
2. If you chose to disregard 1.at least start the day before as support is only available during normal business hours and they are your only hope in the event that the server does crash.
Project Description
Students in teams of 3 are required to select an application that needs a database and build a database application from start to finish.
We reserve the right to create a group of 4 in the case that the class size is not evenly divisible by three.
There are several features we are looking for. We envision this project as an E-commerce application. You are welcome to change that but you will have to convince us that your project has equal complexity/functionality. There should be at least two parties in your application, and there should be interactions between the parties. In the E-commerce realm, these would be the buyer and the seller.
Your application should use a database and the interactions between the buyers and seller should involve querying and updates of your database. Furthermore, you will have to provide your customers with the ability to provide their billing information (disregard security issues) and log the transaction, in case there is a future dispute. Also, implement shopping cart functionality, in case the user wants to return and pay later.
Whatever project you decide to do make sure it fits the above specifications. Also, you should have at least four entities and whatever relationships between them. Your database tables should contain at least 25 entries each.
Philosophy
Throughout the quarter we have several homework assignments designed to ensure that you know how to do each of the tasks required to successfully build a database application. However, building a full database application from scratch allows you to control the process; instead of having the pieces decided for you, you must make all of the decisions by yourself. Part of this process is that you will see how design decisions made at the beginning will affect your final project.
Goals
· 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 (this should not be the main focus of the project)
· Writing the code needed to embed the database system in a web-based application
Schedule
There are a number of intermediate deadlines that you must meet in order to ensure a successful project; these steps are also listed on the schedule for the course. Each group is required to have a project web site; this web site will serve both as a method for ensuring that groups are meeting the checkpoints, and to allow groups to see what other groups are doing. Descriptions for each of the required checkpoints are on separate pages.
·
January 12 Groups decided
·
January 19 Informal Project Description
·
February 7 Proposal Due
·
February 28 Project Report Due
· March 7 Completed Project
Suggested projects
Some of the projects below have links to real E-commerce sites. You are not expected, by any means, to duplicate the complexity or the functionality of these sites; the links are there to give you an idea of what a complicated version of our project would look like, and maybe give you some design ideas.
Movies domain:
In this domain you would be modeling entities movies, their actors, directors, genres, playing times, reviews. There exist several sources on the WWW from which you can get data to populate such a database. You can support various queries such as finding specific playing times, finding movies in Seattle directed by a given director. You can also support updates to the reviews section of the database (e.g., viewers giving their own opinions). Another functionality is to provide personal profiles of people (i.e., the movies they like) and then try to recommend movies to them based on profiles of viewers with similar tastes. (see http://www.moviefone.com/)
In this domain you would be modeling entities such as books, their authors, topics (which may be a complex hierarchy). You may also model various attributes of the authors, the institutions they belong to, etc. You can support a buy/sell service of used books, books used in specific university courses. A personal profile, similar to the one for movies is also a possibility. Pointing an interested buyer to a web source to buy a book is also an interesting option.
Apartments:
This domain would require modeling apartments and their properties, areas of town and their various properties (e.g., bus lines, crime rate distance from various landmarks). You would provide an interface for offering apartments for rent, finding apartments. Some data can be found from the Seattle Times and other sources.
Model entities such as videos, their titles, actors, directors, etc. and their respective properties and relationships. Provide a web interface so that the user can look for videos by director, title, artists, etc. The user should then be able to put in their card info and address and rent the video (assume your company is something like www.kozmo.com). A rep from the company should later be able to log on and input info that the rented movies are returned. Make sure that the user cannot return movies that he/she did not rent.
Airplane
tickets on-line:
You get the idea…