Morning Guys,
Im struggling to see how these following tables can be broken up into 3NF, I Know the rules based on normalizing but cannot seen any data that needs to be moved here is how the tables look:
PlaylistID, PlaylistName, TrackID, Trackname, AlbumID, AlbumTitle, GenreID, GenreName, TrackSeconds, TrackBytes
The question is not very clear, but here goes
You should create a separate table for each ID column... and then move into that table all the related columns:
Playlist(ID, Name)
Track(ID, Name, Seconds, Bytes, AlbumID, GenreID)
Album(ID, Title)
Genre(ID, Name)
Since you will probably want to have the same track in more than one playlist, you need a many-to-many relation, which you should handle with a relation table:
PlaylistTrack(PlaylistID, TrackID)
This satisfies the 3NF, as the playlist name, the album title and the genre name are not repeated on multiple rows.
Related
First and foremost, I want to say I do not have any code to back this at this point. I am trying to conceptualize an idea. So, apologies in advance.
Basic rundown. I have a database full of shows that each can have multiple genres, such as show A can be an action, adventure, drama. Typical, right? Right now, as I have my database set up to have columns such as genre_1, genre_2, genre_3. This is terrible, I know, which is why I am redoing it.
I am wanting to create a table full of genres, then have a table with the show information, then have a table to relate those two. So, the primary keys in the genre and show tables would be foreign keys in the genre-show table.
I'm pretty sure this is the best way to go about this one-to-many relationship, but let me know if there is something I'm missing.
My problem is, I'm uncertain of how I would, for say, list all shows that are in the action OR adventure genres, or list all shows that are in action AND adventure genres.
I'm fairly, kind of familiar with joins, but on my knowledge I can't figure out how I would query that.
Ultimately, what I am looking to do is be able to query my DB and say "Give me every show that has action and adventure genres" and then be on my way.
I hope this make sense. Thank you in advance for your time / answers, I truly appreciate it.
One to many 101:
Main Table:
id (primary key, auto_increment),
name,
datecreated (datetimestamp),
dateupdated (datetimestamp)
Many-to-one A
id (primary key, auto_increment),
main_id (foreign key)
name,
datecreated (datetimestamp),
dateupdated (datetimestamp)
Many-to-one B
id (primary key, auto_increment),
main_id (foreign key)
name,
datecreated (datetimestamp),
dateupdated (datetimestamp)
Now you may join up as many, Many-to-one tables as you need thusly:
select
*
from
main left join
table_a on main.id = table_a.main_id left join
table_b on main.id = table_b.main_id
where
main.id = X
You will receive back many rows, but each row will have duplicates of the main object but include all many-to-ones. This is called Denormalization.
Or you may prefer to do sub loops whereby you run one query to get your main objects, and then within a subloop for each many-to-one, you use the main.id to find the main_id.id rows that match your object.
I'm creating a database based on Pokemon but I'm currently stumped on inserting Pokemon with different moves.
Each Pokemon has a move set, so not just one move, but many. However, as I attempt to insert the Pokemon with its variable-length amount of moves into the table, MySQL ignores the previous ones and only inserts the last move.
In short: how do I insert multiple records of the same Pokemon but with its different move?
[I guess a good similar real-world example would be a Person having multiple email addresses. How would I go about inserting that into a table?]
The problem is that you're implementing it as a one-to-one relationship, but what you have is a many-to-many relationship (each Pokemon has many moves, each move can be learned by many pokemon).
What you'd probably want to do is have 2 tables.
Table 1: Pokemon
ID, Name, Move1ID, Move2ID, Move3ID, Move4ID, Types etc.
Table 2: Moves
ID, Name, PP, Power, type etc.
Then you could use another table which contains all the join information between those 2 tables. You'd have multiple rows containing the same Pokemon ID and multiple rows containing the same Move ID, but the [Pokemon ID, Move ID] combination would be unique.
Table 3: PokemonMoves
PkID, MoveID
Then you could just do a join from the Pokemon table to the Moves table via this relationship table
SELECT *
FROM Pokemon AS p
LEFT JOIN PokemonMoves AS pm on p.ID = pm.PkID
LEFT JOIN Moves AS m ON m.ID = pm.MoveID
There are lots of posts on SO about many-to-many relationships, this looks like a good place to start: Many to many relationship?
Well, what do the tables look like? (and is their structure under your control?)
If you are constrained to a single "Email" field, the only way I see you can associate multiple email addresses with a single record(=person) is to treat the Email field as a comma (or whatever) delimited list.
If you control the structure however, you can switch to a one-to-many relationship between "Person"s and "Email"s - something like:
tblPerson
[id]
tblEmailAddresses
[person_id]
[email]
You'd query that like this:
SELECT id, email
FROM tblPerson INNER JOIN tblEmailAddresses ON
id = person_id
WHERE id = <person you're interested in>
Which would return as many records as that person has email addresses.
Hard to say exactly how the insert would look without seeing your code/data, but you could do something like:
sID = <whatever>
For each sEmail in EmailCollection
INSERT INTO tblEmailAddresses
(person_id, email)
VALUES (sID, sEmail)
Next
I will create 3 tables in mysql:
Movies: id-name-country
Tv-Series: id-name-country
Artists: id-name-country
Instead of entering country information into these tables seperately, i am planning to create another table:
Countries: id-country
And i will make my first three tables take country data from Countries table. (So that, if the name of one country is misspelled, it will be easy just to correct in one place. Data in other tables will be updated automatically.
Can i do this with "foreign keys"?
Is this the correct approach?
Your approach so far is correct, ONLY IF by "country" in Tv-Series and Artist you mean country ID and NOT a value. And yes you can use foreign keys (country id in tv-series and artist is a foreign key linking to Countries);
Edit:
Side note: looking at your edit I feel obliged to point out that If you are planning to link Movie/TV-Show with artist you need a 4th table to maintain normalization you've got so far.
Edit2:
The usual way to decide whether you need tables is to check what kind of connection 2 tables or values have.
If it's 1 to many (like artist to country of origin), you are fine.
If you have Many to many, like Movie with Artist where 1 artist can be in multiple movies and 1 movie can have multiple artists you need a linking table.
If you have 1 to 1 relation (like customer_ID and passport details in a banking system, where they could be stored separately in customer and Passport tables, but joining them makes more sense because a banks only hold details of 1 valid passport for each customer and 1 passport can only be used by 1 person) you can merge the tables (at the risk of not meeting Normalization 3 criteria)
I have the following tables:
users (id, first_name, last_name)
category (id, name)
rank(id, user_id, rank)
Each user can belong to several categories. And all users are in the rank table and have a value between 0.0 and 1.0, where 0 is the lowest rank and 1 is the highest. I’d like to setup additional tables to create the following webpage:
A visitor to the page (identified by either one of the recorded ids in the user table, or a numeric representation of their ip address) chooses a category and is presented with two randomly chosen users from the users table such that:
1) the visiting user_id has not seen this pairing in a period of 24 hours
2) the two users belong to the chosen category
3) the two users are within 1 rank value of each other. Let me explain that last criteria - if the ranks were sorted, the two chosen users would have adjacent ranks.
This is a hard one and I can’t for the life of me figure it out how to do this effeciently
I truly appreciate any help on this front.
Thanks
You just need two more tables and the rest go in your website logic.
user_category(user_id, category_id)
user_pairing(first_user_id, second_user_id, last_seen)
The first table is to represent a ManyToMany relationship between the users and the category, and the second one is for the users pairing.
I agree with #Yasel, i want to add that you properly want another table
candidate(first_user_id, second_user_id);
this table is used to pre-calculate the candidates for each user, this candidate table is prepopulated every hour/day, so when each first_user_id, second_user_id is assigned, this pair is removed from candidate table and moved into user_pairing table. so each time you only need to query candidate table which should be efficient.
I had a question about whether or not my implementation idea is easy to work with/write queries for.
I currently have a database with multiple columns. Most of the columns are the same thing (items, but split into item 1, item 2, item 3 etc).
So I have currently in my database ID, Name, Item 1, Item 2 ..... Item 10.
I want to condense this into ID, Name, Item.
But what I want item to have is to store multiple values as different rows. I.e.
ID = One Name = Hello Item = This
That
There
Kind of like the format it looks like. Is this a good idea and how exactly would I go about doing this? I will be using no numbers in the database and all of the information will be static and will never change.
Can I do this using 1 database table (and would it be easy to match items of one ID to another ID), or would I need to create 2 tables and link them?
If so how exactly would I create 2 tables and make them relational?
Any ideas on how to implement this? Thanks!
This is a classical type of denormalized data base. Denormalization sometimes makes certain operations more efficient, but more often leads to inefficiencies. (For example, if one of your write queries was to change the name associated with an id, you would have to change many rows instead of a single one.) Denormalization should only be done for specific reasons after a fully normalized data base has been designed. In your example, a normalized data base design would be:
table_1: ID (key), Name
table_2: ID (foreign key mapped to table_1.ID), Item
You're talking about a denormalized table, which SQL databases have a difficult time dealing with. Your Item field is said to have a many-to-one relationship to the other fields. The correct things to do is to make two tables. The typical example is an album and songs. Songs have a many-to-one relationship to albums, so you could structure your ables like this:
Table Album
album_id [Primary Key]
Title
Artist
Table Song
song_id [Primary Key]
album_id [Foreign Key album.album_id]
Title
Often this example is given with a third table Artist, and you could substitute the Artist field for an artist_id field which is a Foreign Key to an Artist table's artist_id.
Of course, in reality songs, albums, and artists are more complex. One song can be on multiple albums, multiple artists can be on one album, there are multiple versions of the same song, and there are even some songs which have no album release at all.
Example:
Album
album_id Title Artist
1 White Beatles
2 Black Metallica
Song
song_id album_id Title
1 2 Enter Sandman
2 1 Back in the USSR
3 2 Sad but True
4 2 Nothing Else Matters
5 1 Helter Skelter
To query this you just do a JOIN:
SELECT * FROM Album INNER JOIN Song ON Album.album_id = Song.album_id
I don't think one table really makes sense in this case. Instead you can do:
Main Table:
ID
Name
Item Table:
ID
Item #
Item Value
Main_ID = Main Table.ID
Then when you do queries you can do a simple join