Alpha Team Project Report
SYS 2202
4/28/2010
Tommy Noonan (ten9w)
Joe Angello (jea6t)
Ramit Garg (rkg4u)
Ray Lee (rl4am)
This page is for executive Summary
Executive Summary: 1-2 pages at most. Should include a succinct list, possibly as bullets,
summarizing the technical highlights of your implementation.
Table of Contents
Problem Definition ....................................................................................................................................... 3
Alternatives .................................................................................................................................................. 4
Alternatives ............................................................................................................................................... 4
Analysis of Alternatives....................................................................................................................... 10
Recommendation ....................................................................................................................................... 12
Implementation.......................................................................................................................................... 14
References .................................................................................................................................................. 20
Appendices ................................................................................................................................................. 21
Organization for Written Report
This is our First Deliverable
This can be included in our problem definition or even our executive summary
System Objectives:
 Allow users to add, edit, and delete music data
 Allow users to easily query for music data
 Minimize redundancy
 Allow multiple people to access database at once
 Efficiently manage database editing (prevent edits to the same field at the same time)
 Ensure data integrity
This can be included in our executive summary or problem definition
Use-Cases:
Actors: Public, Industry, and Database System
 Search for Artist or Artists (Public & Industry <=> Database System )
 Search for Song Name (Public & Industry <=> Database System )
 Search for Album (Public & Industry <=> Database System )
 Search for Artist’s record label (Public & Industry <=> Database System )
 Search for Artist’s Relationships (Public & Industry <=> Database System )
 Search for purchase location (i.e. I-tunes, websites, physical stores) (Public & Industry <=>
Database System )
 Search for Genres (Public & Industry <=> Database System )
 Search for number of songs for an Artist (Public & Industry <=> Database System )
 Search for number of albums for an Artist (Public & Industry <=> Database System )
 Search for available audio sources (i.e. mp3, CD, 8-track, record) (Public & Industry <=>
Database System )
 Add a song (include Artist, Album, Genre, song length, Rating) (Industry <=> Database System )
 Allow users to rate a song (Public <=> Database System )
o Record user’s information
 Create user profile (Public & Industry <=> Database System )
o Public User Profile: Name, address, age, income, race, email address
o Industry User Profile: Name, Company Associated with, position, email address
 Search for Album sales (Public & Industry <=> Database System )
 Delete a Song (Industry <=> Database System )
 Edit data within a song column (Industry <=> Database System )
 Search for music by time period (Public & Industry <=> Database System )
Both diagrams could be included in either the executive summary or problem definition
Objectives:
To accurately
acquire and display
information
surrounding the
music industry
To prevent
anomalies
To eliminate deletion
anomalies
To eliminate
insertion anomalies
Use Case:
To ensure data
integrity
To eliminate
redundancy
To administer editing
privileges
To flag contradictory
data entries
To query and display
requested
information
To minimize search
time
To clearly display
search results
To effectively
manage data input
and manipulation
To enforce editing
priveleges
To enforce data
domains
This can be used for the six pages of alternatives needed. We also need to include a picture of our
final database design since we have changed it around since deliverable two
Entities Used to Develop Alternatives:

Purchase Location

Record Label

Artist (name, awards, relationships,
o Song (Genre, sales, title, duration, features, rating, release date)
o Album (Sales, title, rating, release date,
ER Diagram Showing Alternatives:
ALPHA SOLUTION:
LINKING ARTIST WITH ONLY SONG INSTEAD OF ALBUM:
MAKING ALBUM AN ATTRIBUTE OF SONG AND AWARD AN ATTRIBUTE OF ARTIST
MAKING BAND ITS OWN ENTITY
THIS CAN BE USED FOR THE ANALYSIS OF OUR ALTERNATIVES
Analysis of Alternatives:
The Alpha ER:
 This is the baseline for our database structure evaluation.
Linking Artist with only Song instead of Album
 Pros- In today’s music world, consumers are buying individual songs more so than buying an
entire album. With MP3 use at an all time high, customers are more likely to link songs directly
to the artist instead of through the album.
 Cons- The trend from CD’s to MP3 is recent. In the past, album names were mainly used to
distinguish the artist.
Making Album an Attribute of Song and Award an Attribute of Artist
 Pros- There is not a lot of information for albums and awards outside of their name, so making
them attributes could cut down the number of entities in the database
 Cons – It is possible for a song to be on two different albums. If this occurs, it creates
redundancy in the tables. If an artist wins multiple awards, the entire rows would have to be
repeated with just a change in the “Award” attribute.
Making Band its own Entity
 Pros- Artists can be a part of two bands, so having Band an independent entity will remove the
need of repeated rows with just the “Band” attribute changed in the Artist tuple. There is also
more information besides a “name” that people would want to know about a band.

Cons- This would require another table for members, which would increase the size of the
database, thus slowing the down the process of querying. Ergo, it would be more inefficient
compared to the database prior to this change.
RECOMMENDATION
Discuss how we came up with our final database
Include cutting purchase location, the decision not to use band as a table
IMPLEMENTATION
More detail on the technical aspects or our project
Instructions on using the website
Very simple “google like” design
Parts of the website that worked really well
Queries, adding and editing songs
Problems we encountered and suggestions on how to avoid them in the future
Linking edits in all of the forms, making the grand form,
Recommendations for project 2.0
Possibly find a way to incorporate band in our database as well as artist