Alternatives
Our team developed multiple database alternatives before we settled on our final product. The
main entities we altered were the artist, song, and album tuples. We wanted to find an alternative that
ran well as a database (i.e. lacked redundancy) yet also made sense to the user in the way our
information was organized. We also took into account the extent at which users would be able query,
and how much and what type of information would be available. The following database schema are
our attempts at finding the best alternative for the project.
LINKING ARTIST WITH ONLY SONG INSTEAD OF ALBUM:
In this design, we took out the direct link between artist and album to make our database less
busy and due to growing user preferences. Otherwise, this schema is very similar to the alpha solution.
In order to link an artist with an album, the user must first go through the song table.
MAKING BAND ITS OWN ENTITY
This alternative includes the addition of several new tuples, Band_has_Artist, Band, and
Member. It was developed to give the user more information about the bands artists were playing in. It
differs from the alpha solution where Band is merely an attribute of the artist table. This schema
provides more information to the user but the addition of all the new tables would make querying very
slow and inefficient.
MAKING ALBUM AN ATTRIBUTE OF SONG AND AWARD AN ATTRIBUTE OF ARTIST
This alternative cuts down significantly on the number of tuples. The Album table is encapsulated within
the Song table with only the album name getting passed on as an attribute. The award table is also
deleted, with its information included in both the Song and Artist tables. This table allows for faster
query times, but it increases redundancy in the system.
PURCHASE LOCATION USED AS AN ENTITY:
This alternative includes Purchase Location as its own tuple in our database. This table would allow the
user to look up where they can buy the queried song/album. Using this alternative would provide more
information to the user at the cost of longer query times. It would also require a much long
implementation time to link the thousands of markets to buy music with each individual song/album.
ANALYSIS OF ALTERNATIVES
ALPHA SOLUTION
This alternative is our chosen schema to implement. We cut out unnecessary tuples such as
Band and Purchase Location. It maximizes query time, while still providing all the useful information to
the user.
LINKING ARTIST ONLY THROUGH SONG INSTEAD OF ALBUM
This alternative allows for faster query time than the Alpha Solution, but the music information
is not as available. This schema would also require a reduced implementation time without the need to
match up every artist with their respective albums. This solution was heavily considered at because of
the current state of today’s music world. CD and album sales are on the decline as music enthusiasts are
purchasing music by the song online in MP3 form. With this trend, album names are being phased out
because people no longer associate songs with an album, but as a single. Unfortunately, our database
will incorporate music from all eras, including those where users would distinguish artists from their
album names.
MAKING BAND ITS OWN ENTITY
This alternative cut down on the redundancy of our alpha solution. Many artists have been a part of
two bands, which would require entire rows to be repeated with only a change in the ‘band’ attribute.
Making band its own table will provide the user with more information with less repetition. It would
also allow the user to query by band name. Unfortunately this alternative requires three extra tables to
be created which would significantly increase the query time, making it less efficient. Also, this method
would be longer and much more difficult to implement with the addition of three tables.
MAKING ALBUM AND AWARD AN ATTRIBUTE OF SONG AND ARTIST
With the removal of the Album and the Award tables, our database will have fewer entities so queries
will be run faster and the implementation time will be shorter. There is little information outside of
award and album names, so reducing them to an attribute does not result in too much information loss.
Unfortunately, it is possible for a song to be on multiple albums and for artists to win multiple awards.
When this happens, our database would have unnecessary repeated rows with merely one attribute
changed. Users also lose the ability to query by album, ……
PURCHASE LOCATION AS AN ATTRIBUTE
We originally implemented our system with this alternative. As we were filling the database, we
decided that the value added by the Purchase Location table was not worth the inefficient query times
and the space it was taking up. There are thousands of music markets out there, and linking them to
each individual song and album is a daunting task.