I'm working on a database project about music and albums in MySQL, where i make a list over some popular artists, their most sold album, and the songs contained within them. But i suddenly got really uncertain of what to do when it comes to filling in the name of the songs for each album. Should i make an individual table for each list of songs, or should all the songs (about 50 of them in total from all the albums) from all the different artists (5 different artists) be filled inn in the same table (i'm eventually gonna export the data and connect it to a PHP folder
Hope the question was clear
All the songs should be in one "Songs" table. Then you create a column "Album ID" in that table which is a foreign key back to the ID column in the albums table. This is how you know which song belongs to which album. (And of course you have the same kind of relationship between "album" and "artist".)
This is called a "one-to-many" relationship and is one of the basic principles of relational database design.
If you ever find yourself creating multiple tables to represent the same kind of data item, you know you've gone wrong.
N.B. If you want to support the idea that the same song (or track probably, to be more accurate, since many different recordings of a song could potentially be made) can be included on multiple albums, then you'll need to implement a "many-to-many" relationship where you have an extra table in between "albums" and "songs" which holds Album ID and Song ID. Each would be a foreign key back to the Albums and Songs tables, respectively. And to ensure no duplication, both fields would be specified as a Compound Primary Key. That way you can list the same Song ID in that table many times against different albums. Same again if you want to have that flexibility in the relationship between "artists" and "albums".
This might be a good time to take a break and study relational database design and data normalisation concepts in some more detail, then you can start to see these patterns for yourself and make the right decision in your schema designs.
Similarly to this question about databases for playlists you should also use one table for the albums and one table for the songs.
Additionally you might also need a table for artists, etc.
Related
I need help with a project for my university programme. The task is to design a database using MySQL and creating ER- and EER-Diagrams for it. The database I want to create is my music library.
My main entities will be Song, Artist, Album and Publisher. Since one Song can have multiple arists, how do I represent that in my design/diagram? My understanding is that that attribute can usually have only a single value.
I hope you can help me with this.
ERD Solution
So you actually have a many-to-many relationship because a song can be sung by many artist and an artist can sing many songs. Therefore, you need a junction table to represent a many-to-many relationship in an ERD.
I'm trying to create a database schema using information pulled from the themoviedb api.
I thought I was doing ok until I went to add in the television series, then I got really confused.
The TMDb API seems to treat television series and movies as completely separate things. It further divides television listings into series, seasons, and episodes.
For example there is a separate cast listing for television seasons (season regulars) and individual episodes (guest cast). I have no idea how to reflect all this in the database.
I've tried my best to model everything below, but I think there's something wrong somewhere. Please ignore the datatypes.
Role can be either writer, director, or actor.
http://imgur.com/a/1WKQB
Hi user2146821,
Your database design looks good, with the exception of how to display the relations between regular cast and guest cast members, as you've expressed.
Currently, you are approaching the scenario by having a singular join table between Movie, TV Seasons, TV Episodes and Person. This creates a table for which you cannot have either a singular primary key nor a correct composite primary key, as you will have nulls for any given record.
In the linked image above, you can see another way of handling this relationship - you create three join tables, each with Person on one side and a corresponding table on the other (either Movie, TV Season or TV Episode). This eliminates nulls from the join tables, allows for composite primary keys to be formed in the joins tables and structures the database in a more meaningful way.
I will try my best to phrase this in a way that makes sense. I am working on a database project for my beginning database management course that uses a fictional scenario of a bookstore owner who wants me to create a database for them.
Essentially, the tables (or entities) that I have come up with are as follows:
Customer,
Product,
Order,
orderLine,
Book,
Author,
Publisher
To put it simply, I need configure this so that I can track both books and other nonbook items from sales. The issue that I am running into with this is that when I tried to just have one products table, I ran into the issue that books have a bunch of attributes that other items (such as bakery items). If I put books with other items, then there would be a whole lot of empty cells where there is no author/publisher/genre. From what my textbook has taught me so far, a composite table is needed for an orderDetail-type table, where the orderNumber and productNumber would combine. But here, I would need to somehow combine two seperate KEY attributes (for books and other items) into one order table, or some other method. This is especially confusing to me since some customers might buy a combination of books an other items in a single order, or they might only buy one type of thing. I was thinking that the ISBN would be an excellent identifier key for the Book table. What kind of configuration would I need to track orders like this?
Add one more table , product-props and store attributes in that table. you can keep all products in one table i.e books and other items as well. you can move author, publisher as props of this as well
I'm working for a database project that my professor gave to me and now i'm designing the relational schema of database.
I have three entity types album, photo and video that means an album can contain both of them, but I have no idea how to tie them up together.
I'm a beginner in this field so please give me some advice what to do ?
I assume an album can contain several photos and videos. You can create a table joining them. This table can have essentially fours columns: the id of the album, the id of the photo or video, a flag distinguishing whether photo or video, and an index to define the order of the items within an album.
It can of course have an own ID (drawn from a sequence or via autoincrement), a timestamp when it was created, a userid by whom etc.
Can several copies of the same photo belong to an album?
I am building a music streaming site, where users will be able to purchase and stream mp3's. I have a subset entity diagram which can be described as follows:
I want to normalise the data to 3NF. How many tables would I need? obviously I want to avoid including partial dependancies, which would require more tables than just album, artist, songs - but I'm not sure what else to add? Any thoughts from experience?
Well, you've done the ER level. You need to identify Keys and Attributes before you can work out Functional Dependencies. There is a fair amount of work to do before you get to 3NF. Eg. Song Titles are duplicated.
Also, there are questions:
is the site selling Albums, Songs, or both ? (I've modelled both)
if both, how do you track a sale or download ?
do you care about the same Song title recorded by different Artists ?
Anyway, here is a resolved ▶Entity Relation Diagram◀, at least for the info provided. It is closer to 5NF than 3NF, but I cannot declare it as such, because it is not complete.
Readers who are unfamiliar with the Standard for Modelling Relational Databases may find ▶IDEF1X Notational◀ useful.
It uses a simple Supertype-Subtype structure, the Principle of Orthogonal Design. The Item that is sold ie either an Album xor a Song.
Feel free to ask clarifying questions.
You will need 4 tables: Artists, Songs, Albums, and AlbumSongs.
The last one is required since the exact same song (=same edit/version...) could be included in several albums, so you have there a m-to-m relationship.
I agree with iDevelop but with 1 extra table. Here is how I would model it.
Tables: Artist, Song, Album, AlbumSongMap, SingleInfo
If the song was a released as a single on a different date, you can get that from SingleInfo. The single may have been released with some cover art that is different from the album art. You would store the singles art in SingleInfo. MAYBE a song can be released as a single multiple times, with new cover art or something so it could possibly be a 1-many relation. Otherwise it is 1-1.
If you can join Song with SingleInfo that means it was released as a single. If you can join Song with Album (using the map) then you will find all the album's it was released under.
A digital enhancement to an old song is a new song. (or at least a different binary). You may want to further normalize Song to allow storage of digital enhancements without duplicating songName, etc.
When you switch over from ER modeling to relational modeling (tables), you need one table for each entity. You also need a table for some relationships.
In the diagram you've given us, both relationships are many to one. Many to one relationships do not require a table. You can get away with adding foreign keys to entity tables. Therefore the answer to your question is 3 tables: Artists, Albums and Songs.
However, I question your ER diagram. It seems to me that the "contains" relationship is really many to many. An album clearly contains many songs. But a given song can appear on more than one album. So there should be an arrowhead on the line that connects "contains" to "album".
If you accept this revision to your ER model, then the number of tables increases to 4: Artists, Albums, Songs, and Contains.
A similar argument might be made for Artist and Song. If two artists collaborate on a single song, (e.g. Dolly Parton and Kenny Rogers singing "Islands in the Stream" together,
then you might want to model "produces" as a many to many relationship. Now you need 5 tables: Artists, Albums, Songs, Contains and Produces.
Artists, Albums, and Songs are going to require a PK that identifies the corresponding entity. Entity integrity demands that the correspondence bewteen entity instances and table rows be one-to-one.
The Contains and Produces tables can be built without a separate Id attibute. You will need a pair of FKs in each of these tables, and you can declare a compound PK for each table consisting of the two FKs.
Referential integrity demands that you enforce the validity of FK references, either in your programs or by declaring a references constraint in the DB. I strongly prefer declaring the constraint in the DB.