Scribd
Upload
7 views

First Sub

Uploaded by

romanda4
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
7 views

First Sub

Uploaded by

romanda4
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Database Project 24/25

First Submission

Conceptual Modeling
L.EIC012 Databases

Group 1407:
Cláudia Mesquita (up202206173)
Pedro Camargo (up202102365)
Pedro Meireles (up202206180)

20th October, 2024


Context Description
The domain of this project is a music streaming application designed to
provide users with an expansive library of songs, albums, and playlists, while
also allowing personalized user experiences such as playlist creation and
membership service. This type of platform mimics popular music services like
Spotify or Apple Music.
The goal of the project is to design and implement a database capable of
supporting the core functionalities of a music streaming platform. The
database will manage the vast relationships between users, songs, artists,
albums, and playlists while ensuring that the data is efficiently stored.

User
The User class is central to the application and has as attributes a username,
an email, a password, a birth date, a join date, a subscription type (free or
premium), and a country. Premium users have different types of
subscriptions (like student or family). This type of user has to pay the
membership via card or PayPal.
A user can add another user as a friend, and import friends from Facebook.
A user can create playlists, follow artists and add songs to playlists.

Song
The Song class has as attributes a name and a duration. Each song belongs
to an album, a genre, and has lyrics attached to it. A song can potentially
involve multiple artists. Users can also interact with songs through playlists.

Artist
The Artist class has as attributes a name, a debut year, a bio, and the artist is
verified or not. An artist contributes to songs, either individually or
collaboratively, and creates albums. An artist can do concerts, which have a
date, a location and a ticket price related to it. Artists can also sell their own
merchandise through the service, which includes products like CDs, vinyls
and shirts.

Album
The Album class has as attributes a name and the year it was released. Each
album is created by an artist and contains multiple songs, which are
numbered.
Playlist
The Playlist class has as attributes a name, the username of the person who
created it, and the date it was created in. Users can create a custom playlist,
which consists of multiple songs. Each playlist belongs to one user, and it may
span several genres, artists, and albums.
A playlist name must be unique, a user is not allowed to have two playlists
with the same name.

Genre
The Genre class has only a name as an attribute. Each song belongs to a
single genre, but a genre can contain many songs.
Initial Concept Model
Generative AI Integration
ChatGPT

> We provided the AI with a screenshot of our initial UML and asked for
feedback and for ways to improve it.

- Suggestions for Improvement:

1. Listening History:

- Missing Entity: There is no Listening History entity. Since this is


critical for tracking which users listened to which songs (and
when), you should add a Listening History entity to track these
interactions.
- The Listening History entity could contain attributes like
listen_date, listen_time, and foreign keys user_id, song_id to
create a many-to-many relationship between User and Song.

2. Playlist-Song Relationship:

- Currently, Playlist and Song have a one-to-many relationship,


but a playlist usually contains multiple songs, and a song can
appear in multiple playlists. This should be a many-to-many
relationship, requiring a join table such as PlaylistSong.

3. Concert and Merchandise:

- These are interesting additions, but the current relationships


between Artist and Concert, Artist and Merchandise are
one-to-many. This makes sense for Concert but may need
adjustment for Merchandise, especially if multiple artists could
collaborate on a single piece of merchandise (such as a concert
tour). Consider if there are any many-to-many relationships here.

4. Cardinality Clarification:

- Some relationships are marked with *, but you should clarify


whether these are 1-to-many or many-to-many. For example, the
Song to Album relationship seems to be 1-to-many, but you
should ensure this is intentional.

5. Composite Keys and Constraints:

- You can consider adding constraints or composite keys for


important entities. For instance, in PaymentProvider, ensure that
each CreditOrDebitCard and PayPal account are uniquely
associated with a payment provider.

6. Lyrics Entity:

- The Lyrics entity only has a single attribute (text). You could add
more detail such as language or author to make it more useful,
or you might want to embed this as an attribute within the Song
entity instead of having it as a separate table.

- Other Considerations:

- Normalization: The model looks fairly normalized already. Ensure


that redundancy is avoided (e.g., don't repeat the same data
across multiple tables).
- Genre Entity: The Genre entity is fine, but ensure that the
relationship with Song is well defined (one song should belong to
one genre, but a genre should have multiple songs).
- Facebook Entity: The relationship between User and Facebook
should be carefully examined. If it's intended to capture external
social media links, it might be more efficient to make this
optional or an attribute of the User entity.
Final Concept Model

Improvement 1: Listening History


Suggestion accepted, we added the Listening History entity as an
association class with the following attributes: listen_date and listen_time.

Improvement 2: Playlist-Song Relationship


In our initial model, Playlist and Song already have a many-to-many
relationship, we believe this is a mistake committed by the AI.

Improvement 3: Concert and Merchandise


Suggestion declined, since in our relation Artist-Merchandise, a merchandise
item belongs to only one artist, that is, it cannot be collaborative.

Improvement 4: Cardinality Clarification


Suggestion accepted, the relation Song to Album was a one-to-many, but
now we updated our model to a many-to-one relation, since one album has
many songs.

Improvement 5: Composite Keys and Constraints


Suggestion declined, we decided not to add constraints or composite keys
for PaymentProvider, because the generalization already associates the
payment methods to the payment provider.

Improvement 6: Lyrics Entity


Suggestion accepted, we added two more attributes to the Lyrics entity:
provider and language.

You might also like