Team One
Final Database Report
May 4, 2010
Team One
Anna Corrigan – amc3rb
Kathleen Hudgins – klh4cr
Marisa Mutty – mlm5ca
Greta Slotness – gls9b
1
Executive Summary
Project Motivation
Music fans often want to be able to research their favorite artists and songs to learn more about
them. It is sometimes daunting to search the entire internet for information about such a specific topic.
This website is an efficient way for users to have their questions answered about their favorite artists.
Users will be allowed to pick from a list of thirteen predetermined questions and choose which artist for
which they would like to know the answer. This website will make the search for information about an
artist or performing group a "one stop shop" for music fans.
Assumptions
The project team had to make a few assumptions in designing and implementing our webpage
system. Before the design is fully implemented for the 'client', they must confirm or deny each
assumption made because many of the features of the website rely on them. The assumptions that the
project team made include:
 choosing the 13 queries that we feel a fan might want to perform most often.
 trusting the user against SQL injection attacks.
 trusting that the users will not make record label accounts at will.
 deciding that an artist would not be logging themselves in to the website unless they are
registered as a fan.
 queries performed are based on data in the database currently, which is limited but will be
continually updated.
 recording labels will want to enter, edit, and delete data about the artists they support, and
eventually will have pages similar to those of artists.
Major Alternatives Considered
There were three major alternatives considered throughout this project.
 Alternative 1 uses a single relation for all types of users. This means that for some users, there
will be NULL attributes because those attributes don't apply to that user. This alternative has
each artist within a group as a separate tuple which helps to eliminate the NULL attributes of a
Group and ensures that each member of a group is included in the database.
 Alternative 2 divides the instances of a user into 4 main categories: Artist, Recording Label, Fan,
and Administrator. This alternative reduces the number of NULL attributes per user by creating
a more efficient and reasonable schema for dealing with multiple users. This alternative also
contains a "Group" relation. This allows the user to find all the members of a specific Group.
This could pose problems for groups that are not very big which will result in NULL entries for
those spots that are not filled by a member.
 Alternative 3 allows administrators and recording labels to be separate user types, but with very
similar functionality as far as inserting, updating, and deleting data. This alternative makes use
of a fan log-in and an administrator log-in. This alternative has each artist within a group as a
separate tuple which helps to eliminate the NULL attributes of a Group and ensures that all
members are included in the database.
Recommendation
Alternative 3 is the chosen implementation for the database design. This implementation
condenses users into three basic categories: fans, administrators, and recording labels. This way, the
2
team can restrict the ability to modify the database to database administrators and recording labels.
Database administrators must be able to maintain the database. Additionally, it will be helpful to allow
recording labels to update the database as artists record new songs or as record sales go up. Separating
administrators and recording labels into two groups allows additional information to be saved about
recording labels. This information will likely be useful in the future as the web tool is improved because
then information specific to recording labels will be easily retrievable. This will make new queries easier
and allows for the possibility of creating a new webpage for each recording label. Alternative 3 also
deals well with performing groups. Rather than trying to put all of the members of a group in the same
tuple, a "group" tuple, each artist is given his own tuple. This prevents anomalies as some artists
perform individually and as part of a group, so no artist is represented twice. Also, this allows the most
detail about each artist to be recorded. Since there is no way to insert a list as an attribute, this also
prevents having a large number of "member" attributes, many of which would be NULL, in the group
table. Therefore, alternative 3 was chosen because it allows for the simplest implementation which
fulfills the database functions and allows for future improvements.
The schema for Alternative 3 is:
Fan(username, password, name, location, birthday, gender, Occupation, faveGenre, faveArtists,
incomeRange, faveBeer)
Administrator(username, name, password)
RecordingLabel(username, name, password, location, Website)
Artist(username, name, hometown, birthDate, deathDate, photo, gender, performingGroup,
famousRelatives, RelationshipToFamousRelatives)
Note: name is the primary key but username is an alternate key.
Discography(performingGroup, albumTitle, releaseDate, format, numberOfSongs, genre,
featuredArtists, numberOfRecordsSold, relatedConcertTour, recordingLabel)
Songs(title, performingGroup, album, length, genre, single)
Technical Features of Web Implementation

Log-In to website: Users have the ability to log-in to our website. This provides a few important
features of our website, including user type differentiation as well as allowing the user to have
saved personal information. There are three different types of users on our website, which
include Fans, Record Labels, and Administrators. Fans insert information about their age,
location, and favorite artists and genre which allows them to perform queries about other fans
preferences and locations. Currently, the Record Label type and the Administrator have the
same functionality, but further work on the website will restrict Record Label's functionality
3




slightly. Therefore, right now record labels and administrators both log-in under the same log-in
box.
o To test the website: A fan username is acorrigan4 and the password is *** and an
administrator username is admin and the password is music.
Perform queries: Any type of user can perform a query on the data in the database. Queries are
predefined, but allow the user to input the specific artist, song, album, or location of interest
into the form and get custom results. There are 13 queries to choose from, which were decided
upon based on what the design team felt fans might want to know most of the time. The code
for these queries takes the values that the user submitted to create an organized table of
relevant results.
View artist pages: Any user can also visit the artist pages. The user selects which artist from the
database they would like to view (the list is created on-the-fly from the entries in the Artist
table), and a page displays a picture of the artist, his/her personal information, and their
albums. The code for this aspect of the website does not consist of static arguments for each
artist, but instead gets the values directly from the database once the user submits which
artist's page they want to view.
Insert, Update, and Delete data: Only admins and recording label users have this capability. The
user is taken to a form specific to the table they wish to modify and once they press submit the
values from the form are inserted into a SQL query to perform the insertion, update, or deletion.
Because the page posts to itself throughout the entire process, extra code was needed to ensure
that the page wasn't forgetting posted values after each update. In each form, the team added
hidden input fields to carry over old posted values to the page.
Differentiate between users: The web implementation can differentiate between user types, a
feature which limits the functionality of Fan users, and allows Admin users and Record Label
users total functionality. Instead of having a generalized "Person" table with additional tables for
each specific user type (Fan, Administrator, and Recording Label), the design team decided to
delete the Person table and include the information from that table in each of the specific typed
tables. In this way, the table that the account is in determines their type (instead of giving each
user an attribute for their type.)
4
Table of Contents
Executive Summary
Table of Contents
Problem Definition
Objectives
Use Cases
Alternative Generation
Alternative Evaluation
Recommendation
Implementation
Technical Aspects of Implementation
Instructions on How to Use
Successful Aspects of the Project
Problems Encountered
Cautions for Next Time
Recommendations for Version 2.0
Division of Work within the Team
References
Appendix
pg. 2
pg. 5
pg. 6
pg. 7
pg. 8
pg. 13
pg. 16
pg. 16
pg. 17
pg. 17
pg. 17
pg. 18
pg. 19
pg. 19
pg. 20
pg. 21
pg. 22
pg. 23
5
Problem Definition
Currently, there is no public website system which stores or displays information about music
recordings and artists. How is one supposed to find out all the artists that Rihanna has done a duet with?
Or what other albums were released the same month the first Beatles album was released? A variety of
stakeholders could potentially benefit if information about artists, groups, individual recordings, and
collections of recordings was integrated together and easy to find. Music industry personnel would have
an easy online tool available at their fingertips to get feedback about how the public feels about certain
genres or artists. It will even be possible to find this information for fans of a certain income range or
that live in a certain area. Fans could get up-to-date information about artists’ songs and albums. Artists
could see what kinds of fans prefer their music, or artists could easily look at their own past record sales.
In order to realize all of these benefits and more, pertinent information must be aggregated
together in an easily accessible place. The simple solution to this problem is to create a user-friendly
online database system which allows members of the public and the music industry to create personal
accounts, search for certain artists or recordings, and perform unique queries on these topics. An easyto-use web interface should access the needed data from the database via already encoded queries.
Administrators must be able to update the database as new music is released. Both users and
administrators should be able to access this information through queries. Creating such a database and
web interface will allow users to find the information that is useful or interesting to them.
6
Objective Tree
Provide users with access to reliable
musical recording information
Minimize time
and number of
steps involved
in data entry,
editing, and
deletion
Maximize ease of performing
online queries
Minimize
response time
of the
database
Minimize inaccurate or unwanted
information changes
Support
databse with
user-friendly
interface for
performing
queries
Minimize
redundancy,
update
anomalies, and
deletion
anomalies
Figure 1: Objective Tree
7
Protect
information
against
changes by
unauthorized
users
Store users'
account
information
Use Cases
Figure 2: Use Case Diagram
This is a diagram of the possible use cases for the database and web-tool.
*Use cases with an asterisk mean these use cases do not apply to the current implementation. They are
for the future, more advanced “Version 2.0.”
**The webmaster is only an actor in use cases associated wither version 2.0.
8
Use Case Create Personal Account
Preconditions:
The user has access to a computer with the internet
The user is aware of the website
The user opens the website
Basic Flow:
1.
The user locates and clicks the “Create New Account” button on the website
2.
The user is prompted to fill out mandatory fields including:
First and Last Name
Email Address
User Log-In Name
User Password (and confirm)
Security question and answer (in version 2.0 only)
3.
The user clicks the “Create” button
4.
The user receives a confirmation email that their account has been created (version 2.0
only)
5.
The use case ends.
Alternate Flows:
User is an administrator
·User clicks the “Create New Account” button
·The system displays the create account fan page and a link to create an administrator page
·The administrator clicks the link
·The system displays the appropriate form to create an account for an administrator
·The use case continues from step 2
The user leaves one of the fields blank (version 2.0)
·After step 3, the website will inform user they have left a field blank
·This will serve as a reminder that all fields are required to create an account
·User is prompted to enter valid information into those fields
·User clicks “Create” again
·Proceed with Steps 4 and 5
User does not receive confirmation email after step 3 (version 2.0)
·The user can follow a link on the user account creation page to check their account status
·The user is prompted to recheck email address
·If email address was entered incorrectly, user can correct it and proceed with steps 3-5
·If email address is correct, user can resubmit and proceed with steps 3-5
·If email address is correct and user still does not receive and email they can call user support to
get help in finishing creation of the account
Post Conditions:
User is able to log in with username and password
User is able to use features for registered users.
Use Case Make Queries
Preconditions:
The administrator, recording label, or fan is logged into the system. The main page is displayed.
The user’s request is one of the predetermined query options.
9
Basic Flow:
1.
The user selects the query.
2.
The user hits the appropriate “Search” or “Go” button.
3.
The system displays a form to the user asking the user to input the needed information to
perform the query.
4.
The user inputs the appropriate data and clicks the “Submit” button.
5.
The system searches the database for the correct information and performs the query.
6.
The system displays the appropriate data to the user.
7.
The user finds the information he wanted.
8.
The user logs out of the system.
9.
The use case ends.
Alternate Flows: (Some of these are only applicable to the future 2.0 version)
The user desires more in-depth information about one of the returned tuples.
·The use case proceeds as above for steps 1-5.
·The user selects the data item about which he desires more information.
·The user clicks the appropriate button, such as “find co-stars” or “other movies with this actor”,
depending on what information he wants to obtain.
·The system prints the desired information to the screen.
·The use case continues from step 6.
The user desires more in-depth information about one of the returned tuples. The desired information
does not have an associated button.
·The use case proceeds as above for steps 1-5.
·The user enters the query in SQL language in the appropriate text field.
·The user hits the “Search” or “Go” button.
·The system performs the query on the database.
·The system prints the desired information to the screen.
·The use case continues from step 6.
The user does not initially find the desired information
·The use case proceeds as above for steps 1-5.
·The user does not find the information he wanted.
·The user begins the process again, starting from step 1.
Post Conditions:
The user has the desired information.
The user is logged out of the system.
Use Case Log-In
Preconditions:
The fan, administrator, or recording label (from here on referred to generally as user) has an account.
The user knows their log-in name and password.
The user knows how to log-in.
Basic Flow:
1.
The user opens the system.
2.
The system displays a log-in screen with a space for the username and a space for the
password to be entered for fans and for administrators.
10
3.
The user enters his username in the “username” field and his password in the “password”
field under either “fan” if the user is a fan or “administrator” if the user is a database
administrator or recording label.
4.
The user hits the enter button.
5.
They system logs the user into his account.
6.
The system displays the “transfer” page to the user, allowing the user to continue or to go
back.
7.
The user clicks the continue button.
8.
The system displays the appropriate home page to the user based on his position (fan or
administrator/ recording label).
9.
The use case ends.
Alternate Flows:
The user enters an incorrect username or password.
·Steps 1-4 proceed as above.
·The system does not recognize the username/password combination.
·The system prints “incorrect username or password” to the screen and displays a “back”
button.
·The user clicks the back button.
·The system displays the log-in screen again.
·The use case continues from step 3.
The user forgot his password. (This is only applicable for the future 2.0 version of the web-tool).
·Steps 1-2 proceed as above.
·The user clicks on the appropriate button indicating he forgot his password.
·The system displays a screen asking for the user’s username and email.
·The user inputs the correct information and hits enter.
·The system verifies that the username and email correspond to the same user.
·The system sends an email to the user informing him of his password.
·The use case proceeds from step 3.
Post Conditions:
The user is logged into the system as the appropriate type of user (fan or administrator/recording label).
Use Case Log-Out
Preconditions:
The user is logged into the system.
The user has finished using the database and is ready to log out.
The user is at the main screen.
Basic Flow:
1.
The user clicks on the log-out button.
2.
The system logs the user out of the database system.
3.
The use case ends.
Alternate Flows:
The user closes the system before logging out.
·The user clicks on the exit button.
·The system logs the user out of the database system.
·The database system closes.
11
·The use case ends.
Post Conditions:
The user is logged out of the system.
Use Case Maintain Recording Artists’ Pages
Preconditions:
The music industry employee is logged into the database system. The system is displaying the main
screen.
The music industry employee knows what changes to make to the database.
The music industry employee knows what section/table to look in to find and edit the information.
Basic Flow:
1.
The music industry employee clicks on the appropriate button to insert information in the
database.
2.
The system displays a screen with a form for choosing the appropriate table to edit.
3.
The employee clicks on the appropriate button to select the appropriate table/section.
4.
The system displays a form to input the new data.
5.
The employee inputs the new data.
6.
The system records the new information and stores it in the database.
7.
The employee logs out.
8.
The use case ends.
Alternate Flows:
The music industry employee needs to delete data, not add it.
·The music industry employee clicks on the appropriate button to delete information in the
database.
·The system displays a screen with a form for choosing the appropriate table to edit.
·The employee clicks on the appropriate button to select the appropriate table/section.
·The system displays a form to delete the appropriate data.
·The employee fills out the form correctly and submits it.
·The use case continues from step 6
The music industry employee needs to edit existing data.
·The music industry employee clicks on the appropriate button to update information in the
database.
·The system displays a screen with a form for choosing the appropriate table to edit.
·The employee clicks on the appropriate button to select the appropriate table/section.
·The system displays a form to change the appropriate data.
·The employee fills out the form to update the appropriate data
·The use case continues from step 6
Post Conditions:
The database contains the changes made by the music industry employee. The information should be
up-to-date. When the information is called by someone visiting an artists’ page, the new, correct, up-todate information should be displayed.
The employee is logged out of the system.
12
Alternative Generation
Alternative 1- Relations
Artist(name, hometown, birth-date, death date, photo, gender, group, famous relatives)
Discography(performing group, album title, release date, format, number of songs, genre, featured
artists, number of records sold, related concert tour, recording label)
Songs(title, group, album, length, genre, single)
User(username, name, password, location, age, gender, faveGenre, faveArtists, savedQueries)
Type(recording label, fan, artist, administrator)
Figure 3: ER Diagram for Alternative 1
13
Alternative 2- Relations
Group(name, member names, albums recorded, date formed, date broken up, number of members)
Artist(name, hometown, birth-date, death date, photo, gender, famous relatives)
Discography(album title, group, release date, format, number of songs, genre, featured artists, number
of records sold, related concert tour, recording label)
Songs(title, group, album, length, genre, single)
Person: (username, password) is a
Artist(name)
Recording Label(music industry)(name, location, position)
Fan(name, location, age, gender, faveGenre, faveArtists, savedQueries)
Administrator/webmaster(name)
Figure 4: ER Diagram for Alternative 2
14
Alternative 3- Relations
Fan(username, password, name, location, birthday, gender, Occupation, faveGenre, faveArtists,
IncomeRange, faveBeer)
Administrator(username, name, password)
RecordingLabel(username, name, password, location, Website)
Artist(username, name, hometown, birthDate, deathDate, photo, gender, performingGroup,
famousRelatives, RelationshipToFamousRelatives)
Note: name is the primary key but username is an alternate key.
Discography(performingGroup, albumTitle, releaseDate, format, numberOfSongs, genre,
featuredArtists, numberOfRecordsSold, relatedConcertTour, recordingLabel)
Songs(title, performingGroup, album, length, genre, single)
Figure 5: ER Diagram for Alternative 3
15
Alternative Evaluation
All of the alternatives have strengths and weaknesses to be considered before implementation
can occur. The most significant difference between the alternatives is the schema for users of the
database. Alternative 1 uses a single relation for all types of users. This means that included are some
attributes that do not apply to all user types, resulting in a number of NULL attributes. Alternative 2
takes a different approach in which users are split up into different instances of a user with distinct
attributes. The instances are: Artist; Recording Label; Fan; and Administrator. All of these instances are
weak entities of the strong entity “person”. The person table only has the attributes username and
password. Overall, this alternative allows for more specific collection of demographics for each type of
user without creating unnecessary NULL attributes. This is the more efficient and reasonable schema
for dealing with many users. However, the difference in what users will be able to do with the database
and web tool does not require this many groups of users. Everyone will be able to search the database
for information. However, some people will be allowed to update the database using insert, update, and
delete methods. Database administrators and recording labels both should have this power because the
database administrators need to be able to fix errors and recording labels need to be able to add up-todate information to the database as new music comes out. Alternative 3 lumps database administrators
and recording labels into the same kind of user as far as functionality, but still leaves them in their own
separate tables. This is better because database administrators and recording labels function the same
way in regard to this website and database; however, this option leaves open the possibility of creating
web pages for each record label (similar to the existing artist pages) and stores more information about
record labels which will likely be useful in future versions of the web tool.
Another difference between the alternatives is Alternative 2 contains a “Group” relation to be able to
find all members of a group in one place. Because we cannot use a list in the Group relation, we would
have to put in many members’ spots. Since many groups would not need all given spots, this would
result in many NULL attributes. Also, really long groups may not have spots for all members. This would
not be as easy to implement, either, since we would have to enter some individuals in both the artist
and the group category since some artists perform individually and in groups. Although options 1 and 3
both involve a separate tuple for each artist within a group, these methods offer a better option for
dealing with groups because it eliminates a great deal of NULL attributes and ensures that each group
member can be included in the database.
Recommendation
Overall, alternative 3 is the best choice for representing the necessary data that users will need
to access. Alternative 3 is the chosen database design. This alternative condenses the types of users into
three categories, saving storage space in the database while still differentiating between user who can
update the database (administrators and recording labels) and users who cannot (fans). Although
administrators and recording labels currently both have the same abilities with regard to updating and
modifying the database, we decided to put them in two different categories because future queries may
involve retrieving information about recording labels. This alternative allows administrators and
recording labels to function the same way for now, but makes future improvements of the web tool
much easier. Overall, alternative 3 has the most efficient and easiest way to differentiate between
different users.
Alternative 3 also deals well with the issue of performing groups. Rather than trying to put all the
members of a group in the same tuple, a “group” tuple, each artist is given his own tuple. This also
prevents anomalies as some artists perform individually and as part of a group. Additionally, this allows
for detailed information to be found about individual group members, such as a certain member’s date
16
of birth or hometown. Putting an entire group in one tuple does not allow for this kind of detail.
Therefore, alternative 3 allows for the most accurate information that can provide the needed data to
users in the most efficient fashion.
The main differences among the alternatives are the way the alternatives differentiate between users
and the way that the alternatives deal with music groups and their members. Alternative 3 has the
superior implementation for dealing with both of these. Therefore, alternative three was deemed the
best design for this project as it is the most efficient and easiest way to set up the database given the
scope of this project.
Implementation
Technical Aspects of Implementation
The web implementation involves lots of technical aspects. One of them is the artist pages that
fans can access. The pages are made on the fly from the tuple in the database whose name field
matches the user’s choice. Each page includes a picture of the artist, as well as their personal
information like their birthday, performing group, and other famous relatives
All queries follow the same basic skeleton code. They start with html code for the heading and
background of each page, as well as script that enables the “back” button. Next the php code begins
and connects to the database using the host name, username, password, and database name of the
database we want to use (Team One). Next a variable is usually defined by pulling the user’s input from
the form on the previous page. Another variable is defined as the query using SQL query language.
Queries consisted of the traditional SELECT FROM WHERE statements with the appropriate conditions
(based on the user's input). The WHERE statements contain the ucase() function that ensures that the
query works no matter what type of capitalization the user inputs. When necessary, the GROUP BY
function was also used to tidy up the query results. Two different types of methods were used to print
out the tables with the results based on what worked best with each answer. The first type is a static
function that sets up a table in html code that then pulls variables from the query and the previous code
to fill the columns and rows. The other type is a dynamic function that uses loops to pull the field names
and results of the query to create rows (results) and columns (field names) and match them correctly.
Users are able to create an account for the website if they do not have one already. This is done
with the use of two code files. The first one sets up a page with a number of forms that allows the user
to input all of their information (name, username, password, location, etc.) and click submit before
moving on to the main page of the site. The second file extracts the input from the forms on the
previous page and puts them into the database using an INSERT INTO function for the correct table (fan,
administrator, or recording label).
In addition, a lot of the technical work of the webpage went into getting forms to dynamically
update themselves instead of taking the user to a new page after some sort of submission. This was the
guiding design for both the home page (involving selection of a query) and the insert, update, and delete
pages that administrators can access. For the insert, update, and delete pages, the user selects the table
that they wish to modify and a certain form will appear lower on the page that they can insert
information into. Technically, this involved a reasonable amount of extra code to get the page to post all
variables correctly, but it seems to flow much better for the user so it is preferred.
Instructions on How to Use
The URL is: http://www.faculty.virginia.edu/sys2202/2010/Team%20One/page1.html
One of the fan usernames is acorrigan4 and the password is ***. Another fan username is
doggie and the password is smart. One of the administrator usernames is admin and the password is
17
music. One of the recording label usernames is appleLabel and the password is test. More users of all
kinds are included in the database. These are just some examples, and they are summarized in the table
below.
Type
Username
Password
Fan
acorrigan4
***
Fan
doggie
smart
Administrator
admin
music
Recording Label
appleLabel
test
After typing in the URL into the web browser, you come across the homepage of Music ONE Inc.
On this webpage are two logins: one for fans and one for administrators. If you are not registered or
don’t have an account, you can create one at the bottom of the page.
Clicking on the ‘Create account’ link will bring you to a page where you can enter information to
create an account as a fan. If you are a recording label, you can create an account by clicking on the
record label link. After entering your information, click on the ‘Create Account!’ button. This will bring
you to a confirmation page confirming that the account has been created. Clicking on the ‘Continue’
button will bring you to the main screen where you can query the database or view the page of a chosen
artist.
If you are a fan, enter your username and password and click the ‘Enter Website!’ button. You
will then be brought to a validation page with a ‘Continue’ or ‘Go back’ button. Clicking the ‘Continue’
button will bring you to the main screen query page. Clicking the ‘Go back’ button will bring you back to
the previous page.
If you are an administrator or record label, enter your username and password under the
administrator login and click the ‘Enter Website!’ button. You will then be brought to the same
validation page as the fan with the options of continuing or returning to previous page. Clicking on the
‘Continue’ button will bring you to the main screen query page that will allow you to query the
database. It also provides options for inserting, updating, or deleting an entry. Clicking on the ‘Go back’
button will bring you back to the previous page.
Once you have gained access into the main screen query page, you can query the database
through a variety of predetermined queries as well as view the page of a chosen artist.
Successful Aspects of the Project
Successful aspects of our web implementation include user log-in and type-differentiation
among users; getting a page to post to itself and appear dynamic to the user; and artist ‘profile’ pages.
The website relied heavily on having usernames and types for users, in order to ensure that
information in the database was only modifiable by certain people. The database consisted of three
tables grouped by user-type: one for Fans, one for Recording Labels, and another for Admins. We
initially had a type for Artists themselves but figured that they wouldn’t have the time to log on to our
website nor would it provide a route for publicity. Only recording label users and admins have access to
the insert, update, and delete pages so that the data in the database has protection from casual editing,
deleting, or inserting of entries. At this point we don’t have a system for checking the changes that are
performed by recording label users, but that would be a strong feature to include just so that all
information has to be cleared by the admin before it actually makes it to the database.
Another successful feature of the website was the implementation of getting the page to update
itself instead of taking the user to a new page after any sort of submission. Even though this didn’t
consist of much technical addition to our code, it still made a huge impact on the aesthetics of the
website. Before this feature we had to simply list all the user options in a row on the page, which was
18
hard to navigate and confusing for the user. Inclusion of dynamic and specific forms for information
entry greatly simplifies the webpage.
The design team was also incredibly pleased by the success of artist pages. These pages include
a picture of the artist, as well as their personal information. Artist pages are necessary for this website
because they add a picture of the artist (something that we were originally storing but not using) and
they display all of the artist’s information to the user. Additionally, the page includes all of the songs on
each CD that the artist performed on. Although this information can be found quickly with a query from
the homepage, it is more concise and organized presented this way.
19
Problems Encountered
Problem
Solution
INSERT, UPDATE, DELETE was a
significant challenge, specifically
because values of the change were
dropped whenever the page reloaded.
Defined hidden input fields to store the values so they
would carry over for the remainder of the process.
The log-in page would not let users in.
This was a result of our query being
Use SQL to check that username and password exist and
too complicated, so it was probably
find the tuple that matches in both fields.
dropping some variables on along the
way.
Some of the queries were not working
due to a number of problems. The
most common were:
non-matching variable names
made sure that all team members are kept updated about
changes in variable names and that the correct variable
names are being used in the code and the database
variables that returned incorrect or
NULL values
ensured that variables were defined as pulling from the
correct data source or form input
proper quotations
variables need to be in single quotes when they are
inside the double quotes that surround the entire query
field names that are key words in SQL change field names to be something other than an SQL
(ex: "group" was read as GROUP)
key word
spaces after "="
eliminate spaces
inconsistent form input types with
database input types
ensure that all types are consistent in the code and
within the database
Picture on website kept overlapping
with title text
made an image that included the title so they would
always be together but not overlap
Cautions for Next Time:
The best way to make sure everything runs smoothly is to make sure the team is organized and all on
the same page. This is especially important for little details like variable names and coding syntax. It is
also important to double check throughout the process that the variable names and types in the code
match with those in the database. It is also important to note that the KompoZer program for interface
kept shutting down and not saving. Be sure to save frequently and take it slow to avoid it shutting
down.
Apart from these, the rest of the problems encountered were due to inexperience with coding in this
language and using the interface program. We learned from all our mistakes, so little things like spaces
after "=" and quotation types would be less frequent.
20
Recommendations for Version 2.0
There are a few aspects of the website that we didn’t have the time or technical skills to include
in Version 1.0. The website is lacking a system for fans to propose their own data insertions, updates,
and deletions to the website admin, as well as a checking system for the changes proposed by the
record label. The website also includes about 13 premade forms for specific queries on the database,
but there will always be fans with new searches to perform and questions to answer.
Version 2.0 should include a system for the fans to insert new data or update or delete existing
data, with a checking system of course. Fans might notice that something is spelled incorrectly, or want
to add brand new albums or songs to the database before the admin gets to them. Users would be able
to essentially propose any changes that would not become permanent until confirmed or revised by an
admin. This would not only allow the fans to feel more connected to the website but would also
potentially decrease the amount of information that the admin has to enter, since the fans will be
helping out.
Additionally, because we are allowing Record Labels to insert, update, and delete, we are
essentially giving them all the powers of the website administrator. In the next version of the website,
their changes should be screened before becoming permanent, only to ensure that there is no false
information going into the database.
Version 2.0 will also include many more possible queries to perform on the data, based on
recommendations by the fans. The website in its current version clearly has limited options for searching
among the data, but these query options will be drastically expanded for version 2.0. We might also
include the original idea of giving the users their own text area to enter SQL statements, although this
would involve extensive work to ensure that they could not perform SQL injection attacks or
delete/insert data at their will. The database will also be populated with much more data, especially
new releases that have come out since the first release.
The new version would additionally include pages for each Record Label, similar to those for
each Artist. The page would include the location and website of the record label, as well as a list of all
the Artists with whom they have contracts. In this way, record labels would have much more
representation on our website than they do currently.
Lastly, version 2.0 will provide much more protection against user actions, specifically being able
to create recording label accounts at will and SQL injection into our forms. In the current version, users
can create recording label accounts by simply clicking a button from the normal Create Account page.
Once they've created a recording label account, they are able to insert, update, and delete data as if
they were a recording label. Additionally, the team wasn't able to fully protect against any injection
attacks in all of our forms. There are numerous text entry boxes where users could enter all sorts of SQL
statements that could be detrimental to our database. The next version will remove all quotes,
parentheses, and other punctuation from $_POST[] sources in order to defend possible injection attacks.
21
Division of Work
Figure 6
22
References
w3schools.com. Refsnes Data, 1999-2010. Web. April-May, 2010. < w3schools.com>.
Wikipedia. Wikimedia Foundation. Web. April-May, 2010. <wikipedia.org>.
- (for artist, CD, and song data to populate the database)
Picture References:
http://uclaextensionmusic.files.wordpress.com/2010/02/music-notes.jpg
http://image.pollstar.com/WeblogFiles/pollstar/0904170839441011357_661507_v1.jpg
http://www.hartdynamics.com/artists/pics/carterbeauford.jpg
http://atlanticcityhotels.files.wordpress.com/2010/01/carrie-underwood1.jpg
http://capitalcitymama.files.wordpress.com/2008/07/dave-matthews-rca04.jpg
http://dumbfoundedone.files.wordpress.com/2008/02/george-harrison-george-harrison.jpg
http://joeyc.files.wordpress.com/2009/04/lady-gaga-latex-1jpg.jpeg
http://2020proof.files.wordpress.com/2007/12/cmartin.jpg
http://api.ning.com/files/125vlzDTitom7tRhclfCzJoaQCZWrz8-Fc*15GntJR-BunUcYGgd9x*SDYM0UFR/guyberryman.jpg
http://userserve-ak.last.fm/serve/_/19361199/Jon+Buckland+johnny.jpg
http://www.sfu.ca/~smbarber/john-lennon.jpg
http://blog.zap2it.com/thedishrag/legacyimages/photos/uncategorized/2008/06/02/john_mayer_1.jpg
http://www.babble.com/CS/blogs/famecrawler/2009/02/paul-mccartney-coachella.jpg
http://www.boston.com/ae/music/blog/ringo.jpg
http://www.contactmusic.com/pics/l/ascap_2_100408/sara_bareilles_1818721.jpg
http://www.coffeeandbars.com/wp-content/uploads/2009/08/kesha.jpg
http://upload.wikimedia.org/wikipedia/commons/8/84/Stefan_Lessard.jpg
http://ecx.images-amazon.com/images/I/B1kOOR1DlqS._SL600_.jpg
http://upload.wikimedia.org/wikipedia/commons/e/e8/TaylorSwiftApr09.jpg
23
Appendix
Additional Use Cases which are only applicable to the future version 2.0 of the web tool:
Use Case Maintain Website and Data (only applicable to version 2.0)
Preconditions:
The webmaster has access to the website with a password that gives authority to make changes to the
data
Basic Flow:
1.
The webmaster opens the website and logs in when prompted
2.
The webmaster receives the request for updates
3.
The webmaster finds the information that needs to be updated
4.
The webmaster exchanges the new information for the old information in that part of the
website
5.
The system saves these changes
6.
The webmaster checks GUI of website to make sure it is functioning properly and meets
the needs of users
7.
The webmaster makes any necessary changes in the GUI
8.
The system saves these changes
9.
The webmaster logs out of account
10. The use case ends
Alternate Flows:
The webmaster does not receive any requests for updates
·Check with employees to see if there was a mistake
·If so, attain request and proceed with steps 3-10
·If not, proceed with steps 6-10
The system will not save the data
·Proceed with steps 1-4 as above
·Manually save information to an external source, such as a disc or external hard drive
·Proceed with steps 6 and 7
·Manually save again
·End with steps 9 and 10
Post Conditions:
The webmaster has fulfilled all update requests for the database so that all data is up-to-date and
accurate for the website
Use Case Update Personal Information (Only applicable in version 2.0)
Preconditions:
The user has created an account with the website
The user desires to update their information stored in their account
Basic Flow:
1. User logs into website with username and password
2. User clicks on “My Profile” button on webpage
3. User is given the option of updating their personal information
4. User chooses this option by clicking on that link
24
5. User is shown the five fields mentioned in the previous use case and prompted to make any
desired changes
6. Other optional fields, such as phone number, address, and demographic information (including
likes and dislikes of music) will be available if the user wants to fill those out as well
7. User will update any information they wish to update
8. User hits “submit” button
9. User will receive a confirmation email about the changes
10. Use case ends.
Alternate Flows:
The user deletes information from one of the required fields
·After step 8, the website will inform user they have left a field blank
·This will serve as a reminder that all fields are required to create an account
·User is prompted to enter valid information into those fields
·User clicks “Create” again
·Proceed with Steps 9 and 10
User does not receive confirmation email after step 8
·The user can follow a link on the user account creation page to check their account status
·The user is prompted to recheck email address
·If email address was entered incorrectly, user can correct it and proceed with steps 8-10
·If email address is correct, user can resubmit and proceed with steps 8-10
·If email address is correct and user still does not receive and email they can call user support to
get help in finishing creation of the account
Post Conditions:
User account contains accurate information about account holder
User account contains additional information the user wishes to be stored in the database
Use Case Record New Music (Only applicable in version 2.0)
Preconditions:
The recording label is logged into the website. The system is displaying the insert screen.
The employee knows the music information, such as artist, genre, and title.
The music recording is already on the computer and it is in the proper format.
Basic Flow:
1.
The recording label selects the appropriate table to add the music to.
2.
The employee clicks on the appropriate button to import a new song to the database (this
is likely the add or insert button.)
3.
The recording label selects the recording to be added and clicks the button to upload it to
the system.
4.
The system uploads the recording to the database.
5.
The employee enters the associated information, such as artist, genre, and title.
6.
The employee clicks the button to save these changes.
7.
The system saves this information.
8.
The employee logs out of the system.
9.
The use case ends.
Alternate Flows:
25
The song (or a version of the song) already exists in the database. The employee wants to put in a
second copy or version.
·Steps 1-4 proceed as above.
·The employee enters the name of the song followed by “version 2” or another similar indicator
that this is the second recording of the song in the database in the “name” field.
·The employee enters the artist, genre, etc.
·The use case continues from step 6
The song is already in the database and the employee does not want to put in a second copy.
·Steps 1-6 proceed as above.
·The system displays an error message informing the employee that a recording with the same
key already exists in the database.
·The use case continues from step 8.
Post Conditions:
The correct song is in the database (the appropriate number of times).
The song’s identifying and other associated information is complete and stored in the database.
The employee is logged out of the system.
Use Case Submit Data Update Request (only applicable in version 2.0)
Preconditions:
The music industry employee is logged into the system.
The employee knows what request to make.
The webmaster has the authority to change information in the database.
Basic Flow:
1.
The employee clicks the appropriate button to make a data update request.
2.
The system displays a screen with a text box, in which the request can be entered.
3.
The employee describes the request in as much detail as necessary. Specifically, the
request should include if data needs to be added, deleted, or inserted, where this must occur,
and what information the correct update specifies.
4.
The employee hits the appropriate submission button.
5.
The system sends this electronic request to the webmaster, along with the identification
and email information of the employee who sent it.
6.
The webmaster logs into the system, if he is not already logged in. (See the use case login.)
7.
The webmaster receives the request.
8.
The webmaster makes the appropriate changes in the database.
9.
The system saves these changes.
10. The system sends an email or notification to the employee, telling him that the changes
have been made.
11. The employee checks the database to make sure that the change has been made correctly.
12. The webmaster logs out of the system.
13. The employee logs out of the system.
14. The use case ends.
Alternate Flows:
The employee submits a request that is not detailed enough for the webmaster to know what needs to
be changed.
26
·Steps 1-7 proceed as above.
·The webmaster sends an email to the employee who made the request asking for more details.
The webmaster specifies what exactly is confusing or nebulous.
·The employee resubmits the request with more information.
·The use case continues, starting again at step 4.
The webmaster makes an incorrect change.
·Steps 1-11 proceed as above.
·The employee sees that the changes have not been made correctly.
·The employee sends another data update request, specifying that data has been incorrectly
updated. The employee specifies what the old request said, what change was made incorrectly,
and what exactly needs to be fixed.
·The use case proceeds as above starting at step 4.
Post Conditions:
The database contains correct, up-to-date information.
The webmaster is logged out of the system.
The music industry employee is logged out of the system.
27