Quick Contact

    ER Model Design Issues

    The following are the ER Model design issues:

    1. Use of Entity Sets versus Attributes
    2. Use of Entity Sets versus Relationship Sets
    3. Binary versus Entry Relationship Sets
    4. Aggregation versus Ternary Relationship
    Use of Entity Sets versus Attributes

    Suppose the entity set employee with attributes employee-name and cell phone number. It can be dispute that a cell phone is an entity in its own right with attributes cell phone-number and location (the department where the cell phone is located). If we take this factor of view, the employee entity set has to be redefined as follows:

    1. An employee entity set with attribute employee-name.
    2. The phone entity set with attributes cell phone-number and location.
    3. The relationship set emp-telephone, which indicates the relationship among employees and the cell phones that they have.

    The first distinction between these two definitions of an employee is that each employee has exactly one cell phone number related to him. In the second case, however, the definition states that employees may additionally have various cell phone numbers (containing zero) connected with them.

    Use of Entity Sets versus Relationship Sets

    To simplify whether an item is first-class expressed by using an entity set or a relationship set, consider that a bank loan is modelled as an entity. An opportunity is to model a loan as a relationship between clients and departments, with loan-number and amount as descriptive attributes. Each loan is defined by a relationship between a client and a department.

    If every loan is held via exactly one client and client is related with exactly one branch, the layout where a loan is defined as a relationship, perhaps satisfactory. However, with this design, we cannot describe conveniently a situation in which various clients keep a loan jointly. We have to represent a separate relationship for each holder of the joint loan. Then, we must reflect the values for the definitive attributes loan-number and amount in each such relationship. Each such relationship must have a similar value for the specific attributes loan-number and amount.

    Two problems appear as a result of the replication:
    1. The information is saved multiple times, losing storage space.
    2. Updates potentially leave the date in an inconsistent state, wherein the values differ in two relationships for attributes which can be speculated to have equal value.
    Binary versus n-ary Relationship Sets

    It is generally applicable to follow a number binary (n-ary, for n > 2) association set through various specific binary relationship sets. For integrity, assume the abstract ternary (n = 3) relationship set R, combining entity sets A, B and C. We replace the relation set R by an entity set E, and generate three relationship sets:

    • R_(A^’ ) connecting E and A
    • R_(B^’ ) connecting E and B
    • R_(C^’ ) connecting E and C

    If the relationship set R had any attributes, these are created to entity set E; otherwise, a special identifying attribute is developed for E (since each entity set should have at least one attribute to distinguish participants of the set). For each relationship (a_i,b_i,c_i) in the relationship set R, we develop a new entity〖 e〗_i in an entity set E. Then, in every of the three new relationship sets, we add a relationship as follows:

    • (e_i,a_i )in R_A
    • (e_i,b_i )in R_B
    • (e_i,c_i )in R_C

    We can accurately achieve this technique n-ary relationship sets. Thus, theoretically, we can limit the E-R model to involve only binary relationship sets.

    Aggregation versus Ternary Relationships

    The option among utilizing aggregation a ternary relationship is primarily distinct by the existence of a relationship that associates a relationship set to an entity set (or second relationship set). The option may also be guided using certain integrity constraints to we need to define.

    Consider the constraint that every sponsorship (of a task by a department) be monitored by at maximum one employee. We cannot define this constraint in phrases of the Sponsors2 relationship set. Also, we can get explicit the constraint by drawing an arrow from the aggregated relationship. Sponsors to the relationship Monitors. Thus, the display of such a constraint serves as another purpose for the usage of aggregation as opposed to a ternary relationship set.

    ER Model Design Issues
    Enroll Yourself in Live Training: DBMS Training

    Copyright 1999- Ducat Creative, All rights reserved.