I'm developing a web application about TV shows. And i need help with the database design.
I made a list of what i need, but i can't figure out how to design it. I have the basic tables. Series, episodes, seasons etc. What i can't do is how to relate people with episodes/series. Here is my list:
There should be multiple people type. Actor/director/writer/guest etc.
I don't think creating seperate table for each type is a good idea. So there should be one people table. And i need to store the type somewhere.
A person may be in 1 or many series.
This can be done with people_serie table with foreign keys to people and series tables. But i need a way to relate a person to episodes too.
An actor may play 1 or many roles.
This can be done with person_role table.
This is where its getting complicating.
A role may be in 1 or many episodes in a serie.
A person may belong to more than one type in a serie. Ex: actor AND director
I hope i make it clear what the problem is.
Well, you're correct not to split the People table.
the first thing to do is add a Roles table, that will contain role id and role title (each column should be unique - you don't want 2 different ids for the Actor role...)
TblRoles
RoleId RoleTitle
-------------------
1 Director
2 Writer
3 Actor
Then you add a PersonToSeries table, that will hold it's own id, the person's id and the series's id.
This table will hold every person ever working on that series, being a regular staff member or a 1 episode guest.
TblPersonToSeries
PTSId PersonId SeriesId
---------------------------
1 1 1
2 3 8
3 4 7
The next table you will need is a PersonToEpisode table, that will hold the PersonToSeries id and the episode id, and the role id.
In this table you only need to keep integer ids so it's very light weight, and you will specify for each record in PersonToSeries the episodes it is relevant for.
TblPersonToEpisode
PTEPTSId RoleId
-------------------
1 2
2 3
3 1
When a person is usually the director of a series, but makes a guess appearance in an episode of that series, you can simply add 2 rows in PersonToEpisode for that PersonToEpisode with a different role id. (one for Actor and one for Director)
TblPersonToEpisode
PTEPTSId RoleId
-------------------
13 1
13 2
Related
I have a teacher who doesn't like to explain to the class but loves putting up review questions for upcoming tests. Can anyone explain the image above? My main concern in the red underline which shows that supplier and supplierPhone are repeated values. I thought that repeated values occurred when there were many occurrences of the same item in a column.
Another question I have is that if the Supplier is a repeating value, why isnt Part_Name a repeating value because they both have 2 items with same names in their columns.
Example:
It's repeated because the result of the tuple is always the same. E.g. ABC Plastics will always have the same phone number, therefore having 2 rows with ABC Plastics means that we have redundant information in the phone number.
Part1 Company1 12341234
Part2 Company1 12341234
We could represent the same information with:
Part1 Company1
Part2 Company1
And
Company1 12341234.
Therefore having two rows with the same phone number is redundant.
This should answer your second question as well.
Essentially you're looking for tuples such that given the tuple (X, Y) exists, if there exists another tuple (X, Y') then Y' = Y
Looks like five tables to me.
model (entity)
modelid description price
1 Laserjet 423.56
1 256 Colour 89.99
part (entity)
partid name
PF123 Paper Spool
LC423 Laserjet cartridge
MT123 Power supply
etc
bill_of_materials (many to many relationship model >--< part )
modelid partid qty
1 PF123 2
1 LC423 4
1 MT123 1
2 MT123 2
supplier (entity)
supplier_id phone name
1 416-234-2342 ABC Plastics
2 905.. Jetson Carbons
3 767... ACME Power Supply
etc.
part_supplier (many to many relationship part >--< supplier )
part_id supplier_id
PF123 1
LC423 2
MT123 3
etc.
You have one row in model, part, supplier for each distinct entity
You have rows in bill_of_materials for each part that goes into each model.
You have a row in part_supplier for each supplier that can furnish each part. Notice that more than one part can come from one supplier, and more than one supplier can furnish each part. That's a many-to-many relationship.
The trick: Figure out what physical things you have in your application domain. Then make a table for each one. Then figure out how they relate to each other (that's what makes it relational.)
Note: This is not an inventory controlling system. I am just trying to map which medication given to which patient. I am not considering how many medication packets etc. Just a single medication event
I am having a sudden confusion with database relationships, even after working with them for years. Below is my situation.
I have a table called patient where it will hold the information of patients. I have another table called medication where it will hold the medicines prescribed for patients.
I want to find the relationship, so I asked the below questions from me.
Can one patient have many medicine prescribed? - Answer: YES
Can one prescribed medicine have many patients? - Answer: No (ex: you can't give a patient a paracetamol to drink, take it out and give it to someone else)
I need to create the foreign key of patient in medication table. I'm confused, because my answer for 1st question tell me it is one to many relationship while the answer for 2nd says me it is one to one relationship.
What is the exact relation when I am planning to add the foreign key of patient in medication table?
Below is my structure
It somewhat depends on the kind of structure of your tables.
Example 1
Patient:
PatientID Name
--------- ----
1 John
2 Matt
Patient_Medication:
PrescriptionID PatientID Name
-------------- --------- ------------
1 1 Antacid
2 1 Paracetamol
3 2 Asthma inhaler
You are in a one to many relationship. Patient John can have multiple medications in prescription table.
Example 2
Patient:
PatientID Name
--------- ----
1 John
2 Matt
3 Katie
Medication:
MedicationID Name
------------ ----
1 Antacid
2 Paracetamol
3 Asthma inhaler
Patient_Medication:
ID PatientID MedicationID
--- --------- ------------
1 1 (John) 1 (Antacid)
2 1 (John) 2 (Paracetamol)
3 2 (Matt) 3 (Asthma inhaler)
4 3 (Katie) 2 (Paracetamol)
5 3 (Katie) 3 (Asthma inhaler)
This situation is a many-to-many relationship where many patients can have many medications and vice versa. Usually Patient_Medication is called a junction table.
Your second question:
Can one prescribed medicine have many patients? - Answer: No (ex: you can't give a patient a paracetamol to drink, take it out and give it to someone else)
I guess here you have assumed that prescribing a medication and actually consuming that mediation (actual tablet) in real world is the same thing.
The medication table is just a name holder for the medication.
Your answer would have been correct if your table "Medication" would be storing actual instances of medication.
E.g.
Medication
Id Name
1 Paracetomol 25mg Instance 1
2 Paracetomol 25mg Instance 2
3 Paracetomol 25mg Instance 3
Now here, table is actually containing medication instances which can not be consumed by two patients. And here your answer "No" is, I guess, correct.
The other thing is, as you said you are not working on inventory system, and just trying to map medication, you are still attached to real world inventory item which cannot be consumed by two patients.
Here you are mixing inventory item in a system where inventory item is not required.
I think the relationship should actually be many-to-many. A given patient record could point to several different medications, and similarly a given medication record could point to several different patients.
One way to implement this would be to create a third table which maps patients to medications (or medications to patients, if you prefer to think of it that way). This table might look like this:
id | patient_id | medication_id | date
1 | 1 | 1 | 2016-12-19
2 | 1 | 2 | 2016-12-18
3 | 2 | 2 | 2016-12-18
The above data would imply that patient 1 took medications 1 and 2, and medication 2 was also being taken by patient 2. I also added a date, which might be a proxy for a given patient visit.
The medication_id could be a unique identifier for a given pack of medication delievered. In another table, each unique medication would be related to a parent table for that medication.
Update:
Your current schema does not look far off, except that the table you labelled medication is actually a bridge table between patients and their medication dosages. You would need a third table which stores the metadata for each medication. This metadata would be constant for all medication dosages, e.g. type of drug, cost, etc.
Could your confusion be the result of not having defined what the medication table actually represents. It seems to me that your are confusing type of medicine and actual packets.
So what kind of relationship are you trying to model? Are you doing a system that can do inventory of how much medicine you have, or are you doing a patient system that can tell you how many patients are getting a particular medication.
I think your answer to question two is wrong, many patients can be on the same medication. The number of packets you have in stock should be handled in a separate table where you could hold information on things like how many packets you have, what their location is and so on.
So you need at least three tables
patient - holds the patient
medication - holds the types of medication
patient_medication - holds the information on what types of medication the patient is on
you can then add things like another table to hold information on how much of a medication you have and where it's stored if that is relevant to the system.
It's not wrong to say that the association is one-to-many in one direction, and one-to-one in the other direction. When planning a database, I often advise people to write out the associations in both directions:
Each patient can have zero or more medications
Each medication belongs to one and only one patient
This helps to determine the cardinality of the relationship and clarify functional dependencies. When only one direction is specified, it can be difficult to distinguish one-to-many from many-to-many associations.
When talking about the relationship as a whole, we take an "overhead perspective" and ignore the perspective of individual entities, so we would call this example one-to-zero-or-more, or commonly just one-to-many.
Many-to-many relationships look like two one-to-many associations when you view it from the perspective of individual entities on either side.
I have to create a DB for a game and for the active games I need to save 2 user id's from the users table.
Normally I would use the field user_id in my activegames table to have the reference, but how do I do this with 2 users the same time?
Like user_id1 and user_id2?
Keeping the CakePHP database structure along the convention?
Same question regarding the selected weapons for an active game. Just one would be weapon_id but the player can select up to 4 of them?
weapon_id1, weapon_id2, weapon_id3, weapon_id4?
What is here best practice?
I look forward to your answers!
Kind regards!
You are thinking in 1-1 relations. Try 1-n relations. A "link" table that contains two columns. First is game_id, second is player_id.
This table can have any number of rows for one game. Thus no specific number of players.
player table
id name
1 John Doe
2 jane Doe
game table
id title
1 A special game
game_players relation table
game_id player_id
1 1
1 2
You can do the same with weapons (or anything else)
I would like to create a relational database in which there are two tables Users and products. Each item of each table can be related to many items of the second table.
My current implementation is as follows:
Two main tables-
->Users
User ID
UserInfo
->Products
Product ID
ProductInfo
Two different lookuptables
->UserToProduct
UserID
ProductID
->ProductToUSer
ProductID
UserID
Each time a relation from a user to a product is added, i just add an extra row to the first lookup table, and vice versa.
Is this the right way to do it? Are there any standard models for such scenarios that I can refer to?
You don't need two lookup tables, all you need is users_products. As far as resources, there are zillions, just google "database many to many".
UPDATE
Consider this data:
products
------------
id info
------------
1 car
2 flute
3 football
users
------------
id info
------------
10 bob
20 tim
30 manning
Now, as a simple example, let's say manning owns a football and and a car. Let's say tim owns a flute and a football. Now here's your lookup table:
users_products
----------------------
user_id product_id
----------------------
20 2
20 3
30 3
30 1
That's it. Now you can do queries like "give me all the users that have cars", or "give me all the cars that a user has", etc.
Cheers
You really don't need or want two different lookup tables. You should just have one (either of your tables, UserToProduct or ProductToUser, would be fine). The primary key of the lookup table should be a composite key consisting of both ProductID and UserID.
I have a table User that stores user information - such as name, date of birth, locations, etc.
I have also created a link table called User_Options - for the purpose of storing multi-value attributes - this basically stores the checkbox selections.
I have a front-end form for the user to fill in and create their user profile. Here are the tables I have created to generate the checkbox options:
Table User_Attributes
=====================
id attribute_name
---------------------
1 Hobbies
2 Music
Table User_Attribute_Options
======================================
id user_attribute_id option_name
--------------------------------------
1 1 Reading
2 1 Sports
3 1 Travelling
4 2 Rock
5 2 Pop
6 2 Dance
So, on the front-end form there are two sets of checkbox options - one set for Hobbies and one set for Music.
And here are the User tables:
Table User
========================
id name age
------------------------
1 John 25
2 Mark 32
Table User_Options
==================================================
id user_id user_attribute_id value
--------------------------------------------------
1 1 1 1
2 1 1 2
3 1 2 4
4 1 2 5
5 2 1 2
6 2 2 4
(in the above table 'user_attribute_id' is the ID of the parent attribute and 'value' is the ID of the attribute option).
So I'm not sure that I've done all this correctly, or efficiently. I know there is a method of storing hierarchical data in the same table but I prefer to keep things separate.
My main concern is with the User_Options table - the idea behind this is that there only needs to be one link table that stores multi-value attributes, rather than have a table for each and every multi-value attribute.
The only thing I can see that I'd change is that in the association table, User_Options, you have an id that doesn't seem to serve a purpose. The primary key for that table would be all three columns, and I don't think you'd be referring to the options a user has by an id--you'd be getting them by user_id/user_attribute_id. For example, give me all the user options where user is 1 and user attribute id is 2. Having those records uniquely keyed with an additional field seems extraneous.
I think otherwise the general shape of the tables and their relationships looks right to me.
There's nothing wrong with how you've done it.
It's possible to make things more extensible at the price of more linked table references (and in the composition of your queries). It's also possible to make things flatter, and less extensible and flexible, but your queries will be faster.
But, as is usually the case, there's more than one way to do it.