An attribute may be added to a Relationship: [Important for examination]
As every entity has some attributes like we also put attributes to relationship.
Case 1:
We can put start date at the relationship to inform that an employee has joined the department on that start_date. Actually, it is difficult to maintain attributes to relationship.
If we try to shift that start date to the N side of the relationship that is, Employee side, it will not be possible. Because one department consists of many employees and it is not possible to keep start date of all employees to a particular department.
But we can shift start date to the 1 side of the relationship that is, the Department side because there is no chance of multi-valued attribute.
Note: If there is an attribute at relations, we always shift this attribute to an entity at side 1cardinality in the ER diagram.
Case 2:
If it is 1 : 1 then we can shift the attribute start date to either Employee or Department side.
But if there is total partition, it is better to shift the start date to total partition side.
Case 3:
Here we can’t shift Hours attribute relationship to any entity side because both relations is many to many.
In both cases, it becomes multiple valued data and we can’t manage it. In that, we should keep attributes to relation.
Latter when we convert ER-diagram to Relational model, we create a separate table for start date along with key attribute of Employee and Project.
Please follow chapter ER diagram to relational model
Gate questions related to attribute to relationship
GATE 2005 IT Question 21
Consider the entities 'hotel room', and 'person' with a many to many relationship 'lodging' as shown below:
If we wish to store information about the rent payment to be made by person (s) occupying different hotel rooms, then this information should appear as an attribute of
A. Person
B. Hotel Room
C. Lodging
D. None of these
Solution:
As we know if the relationship is many : many, we can’t put any new attribute to either hotel room or person (we have seen earlier the reason). It is better to add the attribute at relationship loading.
So, option (c) is the correct answer.
Strong and Weak Entity
Strong Entity: An entity set that has a key is called as Strong entity set (or Regular Entity Set)
Weak Entity: An entity set that does not have a key attribute is called as Weak Entity Set.
Because of weak entity has no key attribute, it always depends on one strong entity.
Example:
Say a company maintains employee table and as well as employee’s dependents.
Dependent table totally depends on the employee table and the company need not identify a uniquely dependent table. So, the dependent table need not have any key attribute and it is a weak entity.
And definitely, employee table has a key attribute so, the employee table is a strong entity.
When we make the relationship between a strong entity and the weak entity then this relationship is called identifying relationship.
ER diagram representation:
In the case of a weak entity, it references an attribute from a strong entity or makes a composite key.
Weak Entity with the relationship is always total participation.
To know about participation and cardinality follow: Introduction of Relationship
Followings are the points that should be remembered:
# A relationship set in which a weak entity set participates is known as a Weak relationship, which is also known as Identifying relationships.
# A weak entity can be identified uniquely only by considering some of its attributes in conjunction with the primary key of another entity, which is called the identifying owner.
# The weak entity set must have total participation in the identifying relationship set.
# The cardinality set of the owner entity set to the weak relationship set is 1:N (One-to-many).
Q. A weak entity___________
(a) is an entity with no attributes besides its key.
(b) inherits part of its key from the ‘parent’ entities to which it is related.
(c) is an entity with no key.
(d) None of these.
Solution:
Option (b) is a correct answer.
Explanation:
Because of weak entity has no key attribute, it always depends on one strong entity. So, weak is always inherits part of its key (strong entity).