Some Important topics related to ER Diagram(Modelling) with example3 min read
Posted On September 11, 2019
Here in this article we will be discussing about some Important topics related to ER Diagram(Modelling) with example.
N-ary Vs Binary relationships
N-ary relationships are usually converted to binary relationships for the sake of implementation ease. This can usually be done by the addition of new entity sets.
Note: N-ary relationships can have only one outgoing arrow.
Consider an n-ary relationship among entities student, department and course. The most plausible way is to have the arrow directed toward the student. This is because both the department and the course can have multiple students. A department can have multiple courses etc. A student can only belong to one particular department.
Class Hierarchies(Specialization and Generalization)
People –Students -Graduate -Undergraduate -Part time -Full time –Employees -Academic -Non-academic -Permanent -Contract
People can be specialized into Students and Employees (Specialization-Top Down Approach). Specialization is the process of identifying the subsets of a superclass (entity set) that share some special attributes.
Student and Employees can be generalized into People. (Generalization-Bottom Up Approach). Generalization is the process of identifying common characteristics from a collection of entity sets and creating a new set that possesses these characteristics.
Overlapping vs. Disjoint:
There is no entity common to the sub-classes
There is at least one entity common to the sub-classes.
Full vs. Partial:
All the entities of the super class belong to at least one of the sub-classes. Also known as covering.
At least one of the entities of the super class doesn’t belong to either of the sub-classes.
The two main reasons for identifying subclasses:
To add descriptive attributes that makes sense only for the entities in the sub-classes.
To identify the set of entities that participates in some relationship.
Design Issues during ER modeling
Entity vs. Attribute:
While identifying the attributes of an entity set, it is sometimes not clear whether a property should be modelled as an attribute or as an entity set. For example, the phone number of an employee. One option is to use the attribute phone_no. This is suitable is we only have to store one phone number per employee.
Another option is to create an entity set called phone_nos and have a relationship with employees. This is useful in two cases
We have to record more than one phone number.
We have to capture the structure of the phone number like country code, city code, number etc. This can be useful to conduct searches like all the phone numbers of a particular city.
Entity vs. Relationship:
Consider a relationship manages between two entity sets, employees and departments.(Some of the employees manage some departments). Suppose that each manager is given some budget to manage a department. In this case , given a department we know the manager (Assuming a key constraint) and also the budget given. But what if the budget is the sum that covers all the departments of the manager? In this case budget is the attribute of a specific manager and hence we must create a new entity set called managers which is a subclass of the employees entity and then associate the budget with the new entity set.