SAC Classieds - Database Design

Jock Gemmell, Kevin Green, David Rathbun

March 8, 2007
1 Project Domain
This project will consist of creating a set of web pages that will allow users to post items that they wish to
sell (i.e. classieds in the newspaper). These items will be stored in a database that other users will be able
to view and search. The posters of items will be able edit and delete their own postings from the database.
There will also be administrators that will be able to view all postings and remove any inappropriate postings.
The administrators will also have other rights that ordinary users can not access.
2 Customer Desires
The Flying A, a Mount Allison clothing business, used to send out emails to students containing information
about sublets, items for sale, and other things you would nd in the classied section of a newspaper. With
the university taking over the business, the store closed and no longer oers this service. Other services
exist but they lack the ability to properly handle this new domain because they were not designed to oer
accommodating features. The MTA Co-op on Proboards and Student Administrative Council (SAC) forums
can be used to post information about things and threads about selling items. The problem with this is that
there is no easy way of searching or organizing the information to make it easily available. Facebook ads
can be used to sell items but there is a cost for posting. Posters on bulletin boards can be eective because
they convey the information easily and properly, but lack an easy way of searching, mass distribution, and
cost money.
Therefore the SAC decided that they needed to develop their own classied website to serve this need.
Recently the SAC has been trying to become the information hub to students both on campus and o,
therefore it crucial that the new site be both widely accessible and easy to use. The goal of the database
driven website is to hold all relevant information for the classied listings of students and sta. The original
decisions about relevant information were given by the SAC in Figure 4. From this, the initial database
design was constructed.
3 Development Environment
This project will be developed to t in with the current MTA SAC website as an addition module. It will
be developed seperately from the MTA SAC and then merged with the site upon completion and testing.
The MTA SAC currently hosts their site on an external UNIX server running an Apache web server and
will soon be transfering its page over to servers operated by MTAs Computing Services Department. Both
the current and future location for the site are running PHP4 and MySQL 4. These are the tools used for
development of this project as they are fairly simple to use and available freely to the public.
Code will be developed either locally on independant machines and uploaded to the site using FTP or
will be edited on the y by using a secure shell and text based editors. The site will be backed up frequently
to help recover from any mistakes that may occur throughout the development process.
4 Current Design
The MTA SAC site already has some of the basic structures setup for use within this project. The user
management of the site will be done through the MTA SAC website as it already has the functions required
to perform these operations. The users will log in using their MTA username and password. If they havent
previously registered then they will be asked to ll in information such as their mailbox number or a brief
personal biography.
A templating system similar to the one used by the MTA SAC will be used to create consistency through-
out the various pages. Keeping with the same ow as the current site will make it simpler and more intuitive
for the users to navigate the site. This templating system is built to accomodate modules for menus based
on user and administrative rights, only showing what a given user is allowed to do.
5 Database Design
The overall design of the database came from Figure 4. These concept were then translated into tables that
are keyed by unique, auto-incrementing intergers. The use of integer keys was chosen because it simplies
passing of ids through various functions and cuts down on repetition of text in multiple tables. Through
discussions with the client we decided to add in a couple of very simple additional tables to help store some
repeated values. E.g. Price Cond, and Category. Although these could have been implemented as ENUMs,
breaking them o into separate tables allows for simple modication of the lists with less chance of currupting
the table on a given change.
2
5.1 Structure
The database will consist of 10 tables; User, Book, Category, Book Listing , Carpool Listing, Item Listing,
Sublet Listing, User Priv, Price Cond, Item Photo. The primary keys for each entity (table) are written in
bold-italic, unique keys are written in bold, foreign keys are written in teletype, and descriptions of all
the attributes are provided below.
5.2 User entity
user id INTEGER Unique identier for user
username VARCHAR The users MTA username
password VARCHAR The users password (stored as a SHA1 hash of the actual password)
name VARCHAR The users full name
mailbox INTEGER The users text mailbox
registered BOOL If the user has successfully be registered
banned BOOL If the user has been banned from the site
temp pass BOOL If the users password is only temporary.
5.3 Book entity
book id INTEGER Unique identier for book
ISBN short VARCHAR The International Standard Book Number 10
ISBN long VARCHAR The International Standard Book Number 13
last edited by INTEGER The last user to have edited the book entry
title VARCHAR The title of the book
edition VARCHAR The edition of the book
publisher VARCHAR The publisher of the book
year DATETIME The year the book was published
author VARCHAR The author of the book
3
5.4 Book Listing entity
book list num INTEGER Unique identier for book listing
user id INTEGER The user that owns the listing
book id INTEGER The book being listed
price cond id INTEGER The price condition of the listing
price INTEGER The price the user wants for the book
courses used VARCHAR The course codes for the books being used (comma separated)
condition VARCHAR The condition of the book
expire time DATETIME The removal time of the book listing
5.5 Carpool Listing entity
carpool id INTEGER Unique identier for carpool listing
user id INTEGER The user who created the carpool listing
start loc VARCHAR The starting location of the driving route
end loc VARCHAR The destination of the driving route
frequency ENUM The frequency of travel
num space INTEGER The number of available seats
expire time DATETIME The removal time of the carpool listing
5.6 Item Listing entity
item id INTEGER Unique identier for item listing
user id INTEGER The user who created the item listing
price cond id INTEGER The price condition of the listing
cat id INTEGER The category identier of the item
title VARCHAR The title of the item
description TEXT The description of the item
condition VARCHAR The condition of the item
price INTEGER The price of the item
expire time DATETIME The removal time of the item listing
4
5.7 Sublet Listing entity
sublet list num INTEGER Unique identier for sublet listing
user id INTEGER The user who created the sublet listing
price cond id INTEGER The price condition of the sublet listing
address VARCHAR The address of the sublet
walking dist INTEGER The walking distance to campus
num rooms ENUM The number of rooms available
description TEXT The description of the sublet listing
price INTEGER The price of the sublet listing
expire time DATETIME The removal time of the sublet listing
occupancy INTEGER The number of total rooms
type ENUM Choice of (summer, roommate, school)
5.8 Item Photo entity
photo id INTEGER Unique identier for photos
item id INTEGER The item contained in the photo
photo small BLOB The thumbnail version of the photo
photo large BLOB The larger version of the photo
5.9 User Priv entity
user id INTEGER Combined identier for user privilege
priv name INTEGER Combined identier for user privilege
5.10 Category entity
cat id INTEGER Unique identier for categories
cat name VARCHAR The category name
5.11 Price Cond entity
price cond id INTEGER Unique identier for price conditions
cond name VARCHAR The price condition name
6 Functional Dependencies and Normalization
Our database is normalized using Third Normal Form. Each one of the keys functionally determines every
attribute in its table. There also exists other functional dependencies, but they do not violate third normal
form.
5
These functional dependencies are:
username every attribute of the Users table
ISBN short every attribute of the Book table
ISBN long every attribute of the Book table
cat name cat id
cond name price cond id
If we used the Boyce-Codd method then these functional dependencies would be violations and restruc-
turing would need to take place. In our application, the current structure is optimal because all violations
are one to one dependencies with the keys of their table. Functional dependencies also exist based on foriegn
keys which can be seen in Fig 1.
6
Figure 1: Database Design
7
Figure 2: E/R Diagram showing basic structure of the database
8
Figure 3: Use cases that the site and database are based on
9
Figure 4: Design ideas presented by the S.A.C.
10