FOR FREE CONTENT

Attributes to Relationship

 

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 modelwe 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).