1.Several students from different departments may participate one project. Each project has at least one student member.
2.Each student may or may not participate the projects, but one student can participate several projects at the same time.
In 1st statement, the relationship of student and project is M-1. But in the 2nd statement, the relationship of student and project is 1-M
If I want to express their relationship in a single ER digram, should I use the M-1 or 1-M? Or is my ER diagram wrong?
ER Relation
Related
There are four requirement!
There are schools, students, and clubs.
Every student attends one and only one school; every school has more than one student.
Every student may optionally join one club; every club has more than one student.
Every club belongs to one school; some schools have more than one club,
some schools have none.
Any student may work as an assistants for only one school; every
school may have one assistant at most.
How to draw the 4th requirement in my picture
It's called relation you will insert a middle relation. So for example
(student)0,1 ---> (assistant) <----0,1(School)
So the trick is to create a new entity. And you throw those relation. A student may be or not be an assistant (0,1 means that) and a school may have or not have one assistant.
I am learning about ER modelling about Database systems. My problem is that there is a entity called books,enitity named user and I want to create a borrows relationship between user and book with attribute issue date. I modelled it as described but it was pointed that borrows cannot be a relationship because a same user can borrow a book twice. Can anybody explain me what this is as I am using issue data as an attribute so records in borrows relationship would not collide as I will use PK as userid,bookid and issue date. How can I model this accurately? I am a little confused in this.
In the ER model, entity relations consist of attributes of a single entity set, in which the PK identifies only one entity set. Relationship relations have a composite PK that represents two or more entity sets.
Your question uses a composite PK that represents two entity sets (userid and bookid) and a value set (issue date). Strictly speaking, it's neither an entity relation nor a relationship relation. It's a combination of a relationship relation (two entity keys) and a weak entity set (issue date functions similar to a weak key). If we want to be creative, we might call it a weak relationship.
If I was forced to draw an ER diagram for this, I might present it like this:
The ER model isn't a complete logical model (unlike the relational model) and there are some situations which aren't handled well or at all. This is one of those situations.
As per description, User and Book are the entities.
One user can borrow an instance of book.
Similary, one user can borrow multiple instances of book, whether It can be same
instance or various instances.
So every transaction between the User and Book has the Issue Date.
Neither the user nor the book has the Issue Date.
Here, the relationship between User and Book are Many to Many.
The Bridge table is Transaction. We can name it as Borrow also as per your interest.
Now, The user has one to many transactions.
Every Book has one to many transactions.
Every transaction is a combination of a User and Book.
Note: Since every user can have the same book multiple times and at the same day. So we can have a composite primary key of user_id, book_id and Issue_timestamp as there is a chance of redundancy in the Issue Date in the same combination.
In some ER diagrams there are attributes on the relation.In what occasions should we use attributes on the relation
Attributes on relationships allow you to record facts about the relationship as opposed to one of the entities that make up the relationship. Some examples:
A marriage between two people has a date and venue
A student's class allocation may have an assigned seat
Popularity ratings by customers on products
Here's an ER example of an attribute on a relationship between student and class:
While the semantics of ER seem familiar and aid its popularity, logically the distinction between entities and relationships is artificial and unnecessary. Entities can have composite keys, and unary relations aren't unusual from an n-ary relational point of view.
I'm a bit confused on what a many to many relationship is. I'm wondering if the following is a many to many relationship:
A student at a school has many clubs. A club at a school has many students. Let's say that the student has many attributes: firstname, lastname, phone, age, email, etc. A club only has one attribute: a name.
When I make a new club, I want to be able to give the club a name and one or more students. Upon making the club, I want that club to be associated with those students and those students to be associated with that club.
When I make a new student, I want to be able to give the student a firstname, last name, etc, and one or more clubs. Upon making the student, I want that student to be associated with those clubs and those clubs to be associated with that student.
I also want to display a club's students and a student's clubs on their show pages.
I've read that a many to many relationship is when you have a join table that lets you access common attributes of the resulting students and clubs, but there are no common attributes in my case.
Do I have a many to many relationship here? If so, do I use a HABTM or has_many, through relationship?
Actually yes you DO have common attributes.
You stated yourself that a Student has many Clubs
And a Club has many Students.
What is in common? Students and Clubs.
What now follows is to define what a Student and a Club actually are, which you already did.
A Student is a combination of firstname, last name, etc... What you have not specified is what makes a Student UNIQUE. A club also must be defined as to what will make it UNIQUE. While for academic purposes, you could say the name is what makes it unique, in real live, that would probably not be the best solution.
Usually for performance purposes, each student is given a unique Autoincrement ID (which is a number).
Same thing can be done with the Club.
You create a 3rd table which is what creates the Many to Many relation.
In that 3rd table, you have 2 columns. One with the Unique Index for the Student, and the other column with the Unique Index for the Club. You simply add an entry on that table in which you wish to relate a student to a club.
Since you can have many students assigned to the same club, and you can have many clubs assigned to the same student, you have a many to many relation.
Edit: As mentioned in another answer, your 3rd table should also declare the combined indexes as unique, so that you don't add the same entry multiple times.
You have a many to many
Create an id for each table that is unique for that table typically an auto incrementing int.
Then a third table that is a junction/intersect table call it X.
Put a row in X with the student id and club id if the student has the club and vice versa. It would have a unique composite key in table X across both id's in it.
The composite would guarantee no duplicate rows in X
Yes indeed there is a many-to-many relationship here, use HABTM. Also, why do you say that there are no attributes in common? Club names and student names are definitely common attributes in this case.
I am trying to understand the concept of ER modelling, but I do not yet succeed. I have designed the ER model about movie database, but I do not know wheather it is a good design and how to connect the entities:
between Actor and Film i want to say "actor can play in each film only once" and at the same time "many actors can play in many movies" -- is it 1 to 1 relation or many to many?
and HOW do we need to think about entities ans relations between them? relations to one user, one film, one actor, one director, or in general?
UPDATE: new question : should the relation between Director and Film be 1 to many or many to many? I want to say : "one director can have many films && many directors can have may films" ??
Think about it like this: There are many movies. There are many actors. It makes sense that you would only want to include each actor in a particular movie once, but otherwise you want to be able to "mix and match" the movies and actors to express the relationship.
Looking at your diagram, you don't seem to have any fields which express the relationship between Film and Actor - those lines need to match actual fields. Read up on foreign keys: http://en.wikipedia.org/wiki/Foreign_key
The relationship between Actor and Movie that you want is actually many-to-many. You can express this with a "join table" (you'd need to add this to your diagram).
Something like this would work:
FilmActor
-------
uidFilm
uidActor
And put a unique constraint on those two fields together so it can't be duplicated (i.e. the same Actor can't appear in a Film twice)