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.)
Related
I have the 2 dimension tables and 1 fact table. They look like this:
Dimension table 1: Investor_DM
Investor_nr
Investor_name
1
Jack
2
Kelly
Dimension table 2: Company_DM
Company_nr
Company_name
1
Apple
2
Microsoft
Fact table: Positions
Company_nr
Investor_nr
InvestmentDate
InvestmentSize
1
1
2022-jan-02
$1,000
2
1
2022-feb-03
$1,500
1
2
2022-jun-02
$7,000
2
2
2022-jul-03
$7,500
I assigned Investor_nr and Company_nr as PK's in their respective dimension tables, and assigned FK's in the fact table in which I refer to the PK's.
What I want is when I look for data WHERE Investor_nr = '1', I only get the investments in the fact table of investor 1, etc. However, I still get all investments even though I have created one-to-many relationships between the tables. Same goes for the company dimension table.
This is my
SELECT *
FROM Positions
WHERE Investor_nr = '1'
;
query:
I would hope that if I SELECT * from all 3 tables, the Investor_nr's on each row correspond between the fact and dimension table, but this is not the case. Same goes for Company_nr.
What am I missing here? Am I using the wrong query, or are my relationships wrong?
I tried multiple queries, sometimes only on 1 table and sometimes 2 or 3 tables, but I always get data from investors I did not filter on.
Thanks!
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'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
Sorry for my ignorance about mysql and databases, but I'm kind of learning it.
So, suppose the following situation:
I have a table with definitions (ball_definitions) of balls of different colors:
id color
1 red
2 blue
3 green
...
N
where id is the primary value.
and I have a second table (persons) with definitions of persons:
id name
1 John
2 Peter
3 Michel
...
M
(where id is the primary key)
Now, I want to relate to each person, the amount of owned balls by that persons, conceptually, something like this:
john: 1 red ball, 3 green ball, 0 blue ball
peter: 3 red ball, 2 green ball, 1 blue ball.
...
In such a way that both the M and N can vary (for portability reasons).
My first tough was to let persons' table to have N columns where each column was referring to each color, but that is not portable (requires triggers of each change on the ball_definitions change, and it seems quite hard to query).
On the other hand, creating a new table with a "ManyToMany" relation:
persons_id ball_definitions_id amount
1 1 1
1 2 3
1 3 0
2 1 3
2 2 2
2 3 1
seemed to me a little effort when either the number of persons or the number of balls change.
Is there any better solution?
Cheers,
Jorge
No, there is no better solution.
When you have two tables that have an N to N (many to many) relationship you should use an intermediary table.
The alternative would be to create a column in the persons table for every type of ball, or create a column in the balls table for every person which is more effort than the solution you are describing. If you need to add more balls or persons, things get very complicated and messy. You described the best solution.
I am considering how to structure my MySQL database in e-commerce solution. To be more specific I am looking at the product structure.
These are the tables I have come up with so far. What do you think?
Explanation of structure
The application is multilingual. Therefore the product table are split in 2 tables.
If a products has e.g. 2 variants (Small, Medium) a total of 3 rows will be inserted. This is because each variant can have different information for each variant. When the product is shown on the webpage product 1 will be shown with a drop down box with Small & Medium. A product with no variants will naturally only insert 1 row.
products
id master product_number
1 0 123
2 1 456
3 1 678
products_descriptions
id product_id country_code image name description vat price
1 1 en-us image.jpg t-shirt Nice t-shirt 25 19.99
2 2 en-us image.jpg t-shirt Nice t-shirt 25 19.99
3 3 en-us image.jpg t-shirt Nice t-shirt 25 19.99
products_to_options
product_id option_id
2 1
3 2
options
id name
1 Small
2 Medium
Your Products table is schizophrenic, its entity is sometimes Product and sometimes Variant. This leads to very cumbersome behavior. For example, you'd like the question "how many different products do we have?" be answered by select count(*) from products, but here this gives the wrong answer, to get the correct answer you have to know the Magic Number 0 and query select count (*) from products where master=0. "List all products and how many variants we have for each" is another query that should be straightforward but now isn't. There are other anomalies, like the fact that the first line in products_descriptions is a shirt that has a price and a picture but no size (size is stored in the variants, but they have prices and pictures of their own).
Your problem sounds like you have products in two contexts: (1) something that can be displayed as an item in your store, and (2) something that can be ordered by your customer. (1) probably has a name like "Halloween T-Shirt" or so, and it probably has an image that the customer sees. (2) is what the customer orders, so it has a (1), but also a variant specification like "small" or maybe a color "red". It probably has a price, too, and an order_id so your shop can know what specific item to ship.
You should give each context an entity. Here's how i'd do it
displayable_product
id name
1 "Baseball Cap"
2 "T-Shirt"
orderable_product
id d_product_id order_id size color price
1 1 123 red 9.99
2 2 456 small 19.99
3 2 789 medium 21.99
displayable_content
id d_product_id locale name image
1 1 en_US "Baseball Cap" baseballcap.jpg
2 1 es_US "Gorra de Beisbol" baseballcap.jpg
3 2 en_US "Nice T-Shirt" nicetshirt.jpg
4 2 es_US "Camiseta" nicetshirt.jpg
You should probably use locale instead of country in the display tables to account for countries with more than one language (USA, Switzerland, and others), and you might separate the size and color into its own variants table. And if you need country-dependent data on the orderables (like different prices/currencies for shipping to different countries), you'd have to extract a country-dependent orderable_content table, too.