SAC Classifieds - 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. classifieds 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 find in the classified section of a newspaper. With

the university taking over the business, the store closed and no longer offers this service. Other services

exist but they lack the ability to properly handle this new domain because they were not designed to offer

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 effective 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 classified website to serve this need.

Recently the SAC has been trying to become the information hub to students both on campus and off,

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 classified listings of students and staff. 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 fit 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 MTA’s 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 fly 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 haven’t

previously registered then they will be asked to fill 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 flow 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 simplifies

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 off into separate tables allows for simple modification 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 identifier for user

username VARCHAR The user’s MTA username

password VARCHAR The user’s password (stored as a SHA1 hash of the actual password)

name VARCHAR The user’s full name

mailbox INTEGER The user’s 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 user’s password is only temporary.

5.3 Book entity

book id INTEGER Unique identifier 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 identifier 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 identifier 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 identifier 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 identifier 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 identifier 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 identifier 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 identifier for user privilege

priv name INTEGER Combined identifier for user privilege

5.10 Category entity

cat id INTEGER Unique identifier for categories

cat name VARCHAR The category name

5.11 Price Cond entity

price cond id INTEGER Unique identifier 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 idIf 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