Generally we use an ER model to know the concept of database design and this model consists of a collection of entities(real world objects)where each of these entities will be interconnected with each other with conditions and dependencies(i.e. one entity is dependent on another).
ER Modeling basic concepts
The basic concepts of ER model consists of
1. Entity or Entity type
These are the general concepts which help to create an ER diagram and produce an ER model. With the help of these any database design can be created and viewed to know the concept in that database design.
An Entity can be anything a real-world object or animation which is easily identifiable by anyone even by a common man.
Eg: In a company’s database Employee, HR, Manager are considered as entities, where each of these entity will be having their own attributes. An entity is represented by a rectangular box. See Figure 3.5.
1. Strong Entity
2. Weak Entity
3. Entity Instance
A Strong entity is the one which doesn’t depend on any other entity on the schema or database and a strong entity will have a primary key with it (i.e. a unique id which other entities will not have in their attributes).It is represented by one rectangle.In the above example it is a strong entity because it has a primary key(a unique id) as the roll no because for every one roll no varies and it will not be same.
A weak entity is dependent on other entities and it doesn’t have any primary key like the Strong entity. It is represented by double rectangle.
Here the marks is the weak entity and there are no unique id or primary key for that entity. So they are dependent on the existence of the other entity. See Table 3.3
Entity : Instances
Human : Male , Female
Animals : Dog, cats, lion
Jobs : Engineer, Doctor, Lawyer
Actors : Ajith, Vijay, Vikram
Electronics : Laptop, Mobile
Instances are the values for the entity if we consider animals as the entity their instances will be dog, cat, cow… Etc. So an Entity Instance denotes the category values for the given entity.
An attribute is the information about that entity and it will describe, quantify, qualify, classify, and specify an entity. An attribute will always have a single value, that value can be a number or character or string.
1. Key Attribute
2. Simple Attributes
3. Composite Attributes
4. Single Valued Attribute
5. Multi Valued Attribute
Generally a key attribute describes a unique characteristic of an entity.
The simple attributes cannot be separated. It will have a single value for that entity. For Example: Let us consider the name as the attribute for the entity employee and here the value for that attribute is a single value. See Figure 3.7
The composite attributes can be sub-divided into simple attributes without change in the meaning of that attribute. For Example: In the above diagram the employee is the entity with the composite attribute Name which are sub-divided into two simple attributes first and last name.
A single valued attribute contains only one value for the attribute and they don’t have multiple number of values. For Example:Age- It is a single value for a person as we cannot give ‘n’ number of ages for a single person,therefore it is a single valued attribute. See Table 3.4
Table: 3.4 Single Valued Attributes
Age : 3
Roll no : 85
In the above table are the some examples for single valued attributes. See Figure 3.8
A multi valued attribute has more than one value for that particular attribute.For Example:Degree - A person can hold n number of degrees so it is a multi-valued attribute.
In Table 3.5 are some examples for Multi valued attributes.
In ER Model, relationship exists between two entities. Three types of relationships are available and the Entity-Relationship(ER) diagram is based on the three types listed below.
One-to-One relationship: Consider two entities A and B. one-to -one (1:1) relationship is said to exist in a relational database design, if 0 or 1 instance of entity A is associated with 0 or 1 instance of entity B, and 0 or 1 instance of entity B is associated with 0 or 1 instance of entity A.
One-to-Many relationship: Consider two entities A and B. one- to-many (1:N) relationship is said to exist in a relational database design, for 1 instance of entity A there exists 0 or 1 or many instances of entity B, but for 1 instance of entity B there exists 0 or 1 instance of entity A.
Many-to-Many relationship: Consider two entities A and B. many -to-many (M:N) relationship is said to exist in a relational database design, for 1 instance of entity A there exists 0 or 1 or many instances of entity B, and for 1 instance of entity B there exists 0 or 1 or many instance of entity A.
In reality one-to-one are in less usage, where as one-to-many and many-to-many are commonly used. However in relational databases, many- to-many are converted into one-to-many relationships.
It is a finite set of liples in the RDBMS systems relation instances never have duplicate . E.g if Works-for is the relationship between the Employee entity
and the department entity, then Ram works for Comp.sc department, shyam works for electrical department ..etc are relationship instances of the relationship, works for.
The number of entity types involved is known as Degree of relationship. One – Unary, Two – Binary, Three – Ternary.E.g An employee of an organization acts as manager of few other employees. It also connects one entity to itself as a loop. so manager-of is unary. Similarly employee works- fordepartment, connects two entities and is binary. If a customer purchase an item, it involves shop keeper also and is a ternary relationship.
It is defined as the number of items that must be included in a relationship.ie number of entities in one set mapped with the number of entities of another set via the relationship. The three classifications in Cardinality are one -to- one, one-to-many and Many-to-Many. See Figure 3.9-3.11
In the above example we have two entities Person and Vehicle. If we consider a person driving vwchicle, then we have one-to-one relationship between Person and Vehicle. See Figure 3.10
In the above example, Customer places the Order is a one-to-many relationship
Here the customer can place multiple orders and the order is related to only one customer. See Figure 3.11
The example of many-to-many relationship is Students registering the Courses. A student can register more than one courses and A course can be registered by many students. Hence it is many-to-many.