I just started learning database and I'm confused with using one to many vs many to many relationship.
so I came up with a simple example on the relation beside customer and food.
Customers orders food.
1)If i use one to many relationship, I will say that A customer can order MANY food.
Base on the above diagram,
1)bob orders noodles and rice
2)jane orders noodles and crab
1)If i use many to many relationship, I will say that MANY customer can order MANY food.
1)bob orders noodles and rice
2)jane orders noodles and crab
I keep seeing it as the same thing.
bob still orders noodles and rice
and
jane still orders noodles and crab
regardless whether I use one to many or many to many relationships. correct me if I am wrong.
The food sample does work well for a one-to-many relationship: One customer can order many dishes.
The many-to-many relationship is better described by a book sample:
An author can write many books (that would be a one-to-many relationship). But he can have co-authors also involved - one book can have many authors.
The one-to-many relationship diagram is probably misleading because noodles appears twice, while you should only have one record (like you correctly have in the many-to-many diagram).
Your example is a many-to-many relationship: a customer can order many food items, and the same food items can be ordered by many customers.
If you model it as a one-to-many relationship, you are either saying that the customer can order only one item, or that the item can be ordered by one customer only.
Don't confuse participation with cardinality: the term "one-to-many" says that an entity occurrence (a single record, e.g. noodles) on the "one" side of the relationship can occur only once, while an entity occurrence (e.g. Bob) on the "many" side can occur ... many times.
An example of one-to-many relationship, in the noodle-restaurant-chain scenario:
an employee works for a branch (and one branch only), while
the same branch will have many employees working there.
Your Customer and Food example is many-to-many.
One Food type will be eaten by many Customer.
Similarly one Customer can eat multiple Food.
so, many to many means 1-n from both the sides.
Author and Book is the right example of one-to-many given that Book has no co-authors. Otherwise, it is also an example of many-to-many.
Related
I have a question which I feel might be simple. I am relatively new to databases. I was looking at this conceptual ERD and saw these relationships between Seat -> Musical_Performance & Customer -> Booking
Customer has 1..6 -> 0..* AND Musical_Performance 1..1 -> 100..1500
What relationships are these. Is Customer to Booking a many to many relationship and is
Musical_Performance to Seat a one to many?
Really confused about this and would appreciate anyone helping me out
You are right. Musical_Performance is one to many with seat. For each Musical Performance you can have multiple seats (100 to 1500).
Customer to Booking is many to many, each customer can have multiple booking (0 or more) but each booking can be connected just to 1-6 specific customers. This is probably comes to represent that you can book something for a family for example so one booking will have all of the family members customers.
WHat you have, looks like a Chen style ERD. These numbers can describe a minimum, or an optional:mandatory relationship. In this specific case, I'm not sure what they are relating to, but dig in:
https://www.smartdraw.com/entity-relationship-diagram/
and
https://www.lucidchart.com/pages/er-diagrams
and
https://www.oreilly.com/library/view/learning-mysql/0596008643/ch04s03.html
for more information.
I'm making an E/R diagram for doctors and patients. At one point the database description says that each patient has a primary physician so does that imply a many to one relationship between the patients and doctors since each patient has a primary physician or should I stick with a many to many relationship since a single patient could have many doctors.
So you have sort of answered your own question. There are actually two relationships: a many to many relationship between patients and doctors they encounter in general. a many to one relationship between patients and specifically their one primary physician.
Having trouble figuring out relations in this scenario:
I want to create a checkbox list for income types. The UI will present as "What types of income do you receive?". The choices, to keep things simple, could be full-time, part-time and retirement.
Part of me thinks this is a one-to-many relation, and thereby won't necessitate an association table because one individual can have one or more income types. However, taking things literally, "full-time" employment can relate to many individuals. In this case, I won't be showing a summary table of how many of the individuals are "full-time", I am just dealing with one person and determining what their employment status is.
But I don't think of "full-time" as an entity, like, for example, actors and movies - where many actors can be in many movies and many movies can have many different actors.
I guess what's tripping me up is that a user can select more than one option, as opposed to a radio-button list or drop down list.
In this case, which is it?
many-to-many: Person to Employment Type.
Many Persons may share a single Employment Type.
A single Person may have several Employment Types.
Having said that, I've no idea how rich is your business model, but I'd attach Employment Type to an entity called Employment that would refer Employment Type by a many-to-one association (rather than referring it straight from Person).
From my point of view this is a many-to-many relationship.
Full-Time is an entity (suppose a INCOME_TYPES table), exactly like an actor or a movie.
Since you tell us, you won't showing the things income-type-side but only individual-side, there are two alternatives:
De-normalize your schema and put 3-fields in the INDIVIDUALS table. This is not very nice.
If you do some of the things code-side, you can use a bitmask.
for example, 1 is for Full-time, 2 is for Part-Time and 4 is for retirement.
It depends on whether you have the income type as a separate table or whether it is just a string.
For separate table it is many-to-many: Each person has multiple income types. Each income type has multiple persons.
Here is the background:
Bottles are acquired from the suppliers by placing orders. Some bottle types may be ordered from more than
one supplier. Each order involves only a single supplier but may include more than one bottle type. Usually
orders are filled completely by the suppliers, but occasionally an order must be filled with multiple shipments,
due to a back-order condition at the supplier. WWWC maintains careful records of what quantities are
ordered and what quantities are received, as well as when the bottles are ordered and when they are
received, and the actual price charged for the bottles.
The conceptual model of bottle is: Bottle{ID, Capacity, Shape, Material, Color, Cost, Quantity}
The conceptual model of Supplier is: Supplier{ID, Name, Phone#, Address, Contact_Name}.
Till now, I know that the relationship between Bottles and Suppliers are many-to-many.
Here is the photo of the E-R relationship, just omit attributes(you can get them from the conceptual model above).
As far as I know, converting from ER relationship to logical diagram under the many-to-many relationship, I need to create another table to represent the relationship.
So I create another table called: Purchase, which contains follow attributes: SID(Supplier ID), BID(Bottle ID), Ordered_Quantity, Received_Quantity, When_Ordered， When_Received.
My Question is: How to use lines to connect those three tables to establish the relationship?
I think you mean something like in the image below. Crow's foot notation is used here but more notations are possible such as idef1x. Most ER modeling tools support multiple of these notation techniques. This example is made with Dezign
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.