- DBMS Tutorial
- What is Database Management System (DBMS)?
- Components of DBMS
- Applications of DBMS
- Three Schema DBMS Architecture
- Difference between DBMS and RDBMS?
- Difference between File Oriented System and DBMS
- Types of Data Models
- DBMS Schema and Instances
- Data Independence and Data Abstraction
- Database Users and Administrator
- DBMS Languages and Interfaces
DBMS ER Model
DBMS Relational Data Model
ER Model Design Issues
The following are the ER Model design issues:
- Use of Entity Sets versus Attributes
- Use of Entity Sets versus Relationship Sets
- Binary versus Entry Relationship Sets
- 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:
- An employee entity set with attribute employee-name.
- The phone entity set with attributes cell phone-number and location.
- 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:
- The information is saved multiple times, losing storage space.
- 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.