I have the following album table:
album_id(PK)
album_name
artist_name
year
songs
My candidate keys are {id} and {album_name, artist_name}.
Now I am going to normalize the table till 3NF, and I would like to know the reason behind the data of artist_name column being redundant.
1NF
Goal: columns should be atomic.
Result:
album:
album_id(PK)
album_name
artist_name
year
song:
song_id(PK)
album_id(FK)
song_name
2NF
Goal: No partial functional dependencies of non-prime attributes (columns that don't exist in any candidate key) on candidate keys.
Solution: I couldn't find any partial functional dependencies.
3NF
Goal: No transitive functional dependencies of non-prime attributes on candidate keys.
Solution: I couldn't find any transitive dependencies.
Problem
Although the tables above seem normalized, there's the following problem: the data in the artist_name column is redundant. An artist with multiple albums will have their name stored multiple times, which we are against.
What am I missing?
i would create a table called artist and in there store the artist id and name and in the album table have a reference to that using a foreign key constraint. So where you would have artist name in album this would change to artist id. It wouldn't be a issue if you just have the name like you do now but if you have additional data that you would need to store for a artist then you would have to create the table anyway which would break the current design as you would have the name in the album table and the rest of the information in the artist table.
The main goal of normalization is to reduce redundancy. With the artist name being in the album table if you ever needed the name of a artist and additional artist info then you would have to include the album table and the artist table which wouldn't make sense and you wouldn't have any other columns besides name to link the tables together or duplicate the data in two places both the album and artist table which would violate the 1st normal form.
Also, with the name being in the album table your data would be split across two tables. The artists name isn't really a dependency on album but on the artist entity. This violates values stored in a column should be of the same domain principle of the 1st normal form.
Related
I am currently learning database for an upcoming school semester, So I'm practicing with the books I currently have. I have books by multiple authors and authors with multiple books. Also books with multiple categories.
So I made three tables. A books table (with all the books information, including the author), an authors table (with the authors name, address, ect) and a categories table (since some books have multiple categories). Since some books have multiple authors and some authors have multiple books, I made a junction table called AuthorsBooks and filled it with information. By best practice, is it ok to NOT put authors with only one book in that (AuthorsBooks) table? Also, I created a BooksCategory junction table and put the books with multiple categories into that table. What would be the best way to link those two tables? By book title? Thanks.
In general your approach sounds correct with a few exceptions.
So I made three tables
Here's my count, based on your descriptions:
Authors
Books
Categories
AuthorsBooks
BooksCategories
A books table (with all the books information, including the author)
This is incorrect. At the point you realized you need AuthorsBooks, there is no reason to have author as part of the Books table. Any column(s) you used to implement that should be removed from Books.
By best practice, is it ok to NOT put authors with only one book in
that (AuthorsBooks) table?
Absolutely not. You created the right structure with AuthorsBooks. It supports any number of authors for a book.
Also, I created a BooksCategory junction table and put the books with
multiple categories into that table. What would be the best way to
link those two tables?
By Keys. Every table should have a primary key, and in your case the keys should be integers that get incremented with each new row.
Here's an outline of the table structure and standard naming.
Books
-----
id integer auto_increment primary key
title varchar(150)
Categories
----------
id integer auto_increment primary key
name varchar(60)
BooksCategories
---------------
books_id integer primary key (foreign key for Books.id)
categories_id integer primary key (foreign key for Categories.id)
I am developing a web based music application. I get struck into a confusion related to MySQL columns.
Problem is like this:
I have album table:
album_id
album_name
album_year
Now the problem is: an album can contains multiple tracks (identified by track_id). Now how to store multiple track id's in album table?
I am novice to MySQL.
You have to create another table, lets name it album_has_tracks.
It has following structure:
album_id track_id
1 1
1 2
1 3
2 4
2 5
2 6
That is named relations and that is one of the point, that MySQL is named relational database. Both of the album_id and track_id are foreign keys and represent columns with their ids. After that, to get the data of the tracks, you have to use JOIN. So that are the basic you have to read about.
I would suggest you to read some basic about relational databases, for example here.
You need to find some tutorials on relational database design.
You wouldn't store the tracks in the album table, you would create an album tracks table with, for example, track_id, album_id, track_name
The album_id in the tracks table would be set as a foreign key linked to the album table and you would set its value in the track entries to the matching album_id from the album table.
How to structure tables for songs and playlists?
My thought was to create a table of playlists titles and id's then a playlists songs table that holds the songs unique id and the playlist which it belongs to. The other plan a new table for each playlist and store song information in each table for the playlist.
Would this be a good approach or is creating new tables bad for performance or any other reason?
How about something like this?
Songs:
id title length artist_id
Artists:
id name
Playlists:
id title user_id
Playlists_Songs:
playlist_id song_id
Users:
id name email
In terms of relational design, you need two tables for playlists, one holding the playlistname (key, playlistname), one for the actual playlists (key,playlistkey,trackid)
Table for tracks holding mp3 tag details (key, track title, artist key, album .... Etc)
Table for Artists (key, name, band). You can break it down further applying the principle that you should not duplicate data for instance holding a playlistname in more than one table. By creating views, you knit all this together
However, if you are using android, this database already exists.
I need to make a table 'Movies' which will have columns:
ID Title Description Category etc
And another one called 'Movie_Categories' containing, for example
ID Category
1 Action
2 Adventure
3 Triller
but since category in table Movies will have multiple choices what is the correct way to do this?
should i use comma-separated values like someone said in this post Multiple values in column in MySQL or is there a better way?
This is a many-to-many relationship.
You need a join table to make it right, such as :
CREATE TABLE film_category (
category_id int,
film_id int,
PRIMARY KEY (category_id, film_id)
);
DO NOT GO FOR COMMA-SEPARATED VALUES. NEVER.
Having said that. Bear in mind that when you have a so called many-to-many relationship, that is, a relationship where you can have one category with many movies and one movie with many categories, you will always need to generate an additional table.
This table will only need the Primary Keys of each of the other 2 tables and will have a compound key.
So the schema will end up being:
Movies(ID, Title, Description, Category)
Categories(ID, Category)
Movies_Categories(ID_Movie, ID_Category)
In bold are the primary keys.
In order to get all the categories for a movie you will just have to join each of the three tables.
A final comment about having multi-valued fields is that your table will not be in First Normal Form which will, sooner or later, give you lots of headaches.
The last thing to do is have a non normalized table by storing comma separated values.
*You should have a table movies and a table for categories.
You should create a mapping table which will map the movieId to the categoryId*
I was wondering if there is some way to combine two indexes into third to make sort of serial number... For example:
If I want to create music database
I would start with table artists with
-artist_name
-artist_id (Primary key)
-....
Then table albums with
-album_name
-album_id (P.k.)
-...
And then table songs with
-song_title
-song_id
Let's say artist would be X with artist_id - 12345
Then album Y with album_id - 678
And I want song_id to be 12345.678.xxx (dots only for visualization of the idea, length of artist_id and album_id would be constant)
My question is. Is something like possible?
Because I have a feeling that this would perform much more better search through database.
Not only that in my song_id I have full information of artist and album (I don't need to use foreign keys than), it should speed up any query about songs from the same album or other albums of the same artist. All information in one index and it needs only some kind of extraction.
Or maybe its just mine minimal knowledge about MySQL? :)
Keep artist_id and album_id as separate columns in the songs table and include proper foreign key relationships and indexes. This will give you the best combination of data integrity and query performance.