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.
Related
We had a discussion today related to W3 lecture case study about how many entities we need for each situation. And I have some confusion as below:
Case 1) An employee is assigned to be a member of a team. A team with more than 5 members will have a team leader. The members of the team elect the team leader. List the entity(s) which you can identify in the above statement? In this cases, if we don't create 2 entities for above requirement, we need to add two more attributes for each employee which can lead to anomaly issues later. Therefore, we need to have 2 entities as below:
EMPLOYEE (PK is employeeId) (0-M)----------------(0-1) TEAM (PK teamId&employeeId) -> 2 entities
Case 2) The company also introduced a mentoring program, whereby a new employee will be paired with someone who has been in the company longer." How many entity/ies do you need to model the mentoring program?
The Answer from Lecturer is 1. With that, we have to add 2 more attributes for each Employee, mentorRole (Mentor or Mentee) and pairNo (to distinguish between different pairs and to know who mentors whom), doesn't it?
My question is why can't we create a new Entity named MENTORING which will be similar to TEAM in Q1? And why we can only do that if this is a many-many relationship?
EMPLOYEE (PK is employeeId) (0-M)----------------(0-1) TEAM (PK is pairNo&employeeId) -> 2 entities
Thank you in advance
First of all, about terminology: I use entity to mean an individual person, thing or event. You and I are two distinct entities, but since we're both members of StackOverflow, we're part of the same entity set. Entity sets are contrasted with value sets in the ER model, while the relational model has no such distinction.
While you're right about the number of entity sets, there's some issues with your implementation. TEAM's PK shouldn't be teamId, employeeId, it should be only teamId. The EMPLOYEE table should have a teamId foreign key (not part of the PK) to indicate team membership. The employeeId column in the TEAM table could be used to represent the team leader and is dependent on the teamId (since each team can have only one leader at most).
With only one entity set, we would probably represent team membership and leadership as:
EMPLOYEE(employeeId PK, team, leader)
where team is some team name or number which has to be the same for team members, and leader is a true/false column to indicate whether the employee in that row is the leader of his/her team. A problem with this model is that we can't ensure that a team has only one leader.
Again, there's some issues with the implementation. I don't see the need to identify pairs apart from the employees involved, and having a mentorRole (mentor or mentee) indicates that the association will be recorded for both mentor and mentee. This is redundant and creates an opportunity for inconsistency. If the goal was to represent a one-to-one relationship, there are better ways. I suggest a separate table MENTORING(menteeEmployeeId PK, mentorEmployeeId UQ) (or possibly a unique but nullable mentorEmployeeId in the EMPLOYEE table, depending on how your DBMS handles nulls in unique indexes).
The difference between the two cases is that teams can have any number of members and one leader, which is most effectively implemented by identifying teams separately from employees, whereas mentorship is a simpler association that is sufficiently identified by either of the two people involved (provided you consistently use the same role as identifier). You could create a separate entity set for mentoring, with relationships to the employees involved - it might look like my MENTORING table but with an additional surrogate key as PK, but there's no need for the extra identifier.
And why we can only do that if this is a many-many relationship?
What do you mean? Your examples don't contain a many-to-many relationship and we don't create additional entity sets for many-to-many relationships. If you're thinking of so-called "bridge" tables, you've got some concepts mixed up. Entity sets aren't tables. An entity set is a set of values, a table represents a relation over one or more sets of values. In Chen's original method, all relationships were represented in separate tables. It's just that we've gotten used to denormalizing simple one-to-one and one-to-many relationships into the same tables as entity attributes, but we can't do the same for many-to-many binary relationships or ternary and higher relationships in general.
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.
can we have some thing like following ER?
Is it a technical fault or not?
To define a relationship there should be entity by the help of them you can show relation. so it is impossible to make relation without entity.
In your case if you want to use 2 relationship there should be 1 entity between them.
Example of real life
suppose you have two relation teacher and student. you can not say like i am teacher and student of XYZ.
But you can say like i am teacher of Xyz and student of abc.
Typr of relationship
One-to-many relationships
The most common relationship used when creating relational databases. A row in a table in a database can be associated with one or (likely) more rows in another table. An example of a one-to-many relationship is a single order has many items on that order. And since relationships work both ways it is not uncommon to hear reference to many-to-one-relationships as well.
One-to-one relationship
A row in a table is associated to one and only one row in another table. An example of a one-to-one relationship is a person can have one social security number and a social security number can only be assigned to one person.
In most cases there is no need for a one-to-one relationship as the contents of the two tables can be combined into one table.
Many-to-many relationships
When one or more rows in a table are associated with one or more rows in another table. An example of a many-to-many relationship is a table of customers who can purchase many different products and a table of products that can be purchased by many different customers.
I have to create a database and I want to know what would be the best solution.
Let's say I have to store information about students and teachers.
Should I make one single table containing all the personal information (name,email,phone password) to both students and teachers?
For additional information should I keep them in separate tables as ADD_TEACHERS and ADD_STUDENTS?
You may want to create a people table for the common data like name,email etc. You can then use a primary key column in this table, and if there has to be information specific to teacher (like course_instructor, head_teacher of class), then use that unique key from people as reference in your course_information table. Do the same for students too.
It sounds like your best route is to have a separate table for teachers and students. You'll have what is called a one-to-many relationship between teachers and students: one teacher, many students.
But that only covers one semester. When you consider other semesters, you have a many-to-many relationship between students and teachers.
In the end, you're best off with at least three tables: Teachers, Students, and teacher-to-student relationship.
First thing you have to do is Map the entity relationships (ER) and its attributes.then design the database and apply the normalization strategies.
In the proposed scenario students and teachers are different entities . and find out thier relationship
ONE student ONE TEACHER
MANY Students HAVE ONE TEACHER
MANY Students HAVE MANY TEACHERs
Then check out their attributes Example - Student(Name,Class,DOB)
It depends on how you are going to use the data. If you have a lot of use cases where you are interested in "persons", regardless of role, or if you have a lot of persons who are both teachers and students, you may want to learn the gen-spec design pattern, as it applies to relational tables.
See previous discussion.
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.