UNIT-1 (CHAPTER-2 ENTITY RELATIONSHIP MODEL)

SKYSPIN

UNIT-1 (CHAPTER-2 ENTITY RELATIONSHIP MODEL)

 ER Model - Basic Concepts

 

The ER model defines the conceptual view of a database. It works around real-world entities and the associations among them. At view level, the ER model is considered a good option for designing databases.

Entity

An entity can be a real-world object, either animate or inanimate, that can be easily identifiable. For example, in a school database, students, teachers, classes, and courses offered can be considered as entities. All these entities have some attributes or properties that give them their identity.
An entity set is a collection of similar types of entities. An entity set may contain entities with attribute sharing similar values. For example, a Students set may contain all the students of a school; likewise a Teachers set may contain all the teachers of a school from all faculties. Entity sets need not be disjoint.

Attributes

Entities are represented by means of their properties, called attributes. All attributes have values. For example, a student entity may have name, class, and age as attributes.
There exists a domain or range of values that can be assigned to attributes. For example, a student's name cannot be a numeric value. It has to be alphabetic. A student's age cannot be negative, etc.

Types of Attributes

• Simple attribute − Simple attributes are atomic values, which cannot be divided further. For example, a student's phone number is an atomic value of 10 digits.
• Composite attribute − Composite attributes are made of more than one simple attribute. For example, a student's complete name may have first_name and last_name.
• Derived attribute − Derived attributes are the attributes that do not exist in the physical database, but their values are derived from other attributes present in the database. For example, average_salary in a department should not be saved directly in the database, instead it can be derived. For another example, age can be derived from data_of_birth.
• Single-value attribute − Single-value attributes contain single value. For example − Social_Security_Number.
• Multi-value attribute − Multi-value attributes may contain more than one values. For example, a person can have more than one phone number, email_address, etc.

These attribute types can come together in a way like −

• simple single-valued attributes
• simple multi-valued attributes
• composite single-valued attributes
• composite multi-valued attributes

Entity-Set and Keys

Key is an attribute or collection of attributes that uniquely identifies an entity among entity set.
For example, the roll_number of a student makes him/her identifiable among students.

• Super Key − A set of attributes (one or more) that collectively identifies an entity in an entity set.
• Candidate Key − A minimal super key is called a candidate key. An entity set may have more than one candidate key.
• Primary Key − A primary key is one of the candidate keys chosen by the database designer to uniquely identify the entity set.

Relationship

The association among entities is called a relationship. For example, an employee works_at a department, a student enrolls in a course. Here, Works_at and Enrolls are called relationships.

Relationship Set

A set of relationships of similar type is called a relationship set. Like entities, a relationship too can have attributes. These attributes are called descriptive attributes.

Degree of Relationship

The number of participating entities in a relationship defines the degree of the relationship.

• Binary = degree 2
• Ternary = degree 3
• n-ary = degree

Mapping Cardinalities

Cardinality defines the number of entities in one entity set, which can be associated with the number of entities of other set via relationship set.

• One-to-one − One entity from entity set A can be associated with at most one entity of entity set B and vice versa.

• One-to-many − One entity from entity set A can be associated with more than one entities of entity set B however an entity from entity set B, can be associated with at most one entity.

• Many-to-one − More than one entities from entity set A can be associated with at most one entity of entity set B, however an entity from entity set B can be associated with more than one entity from entity set A.

• Many-to-many − One entity from A can be associated with more than one entity from B and vice versa.
  

  Introduction to Database Keys

  Keys are very important part of Relational database model. They are used to establish and identify relationships between tables and also to uniquely identify any record or row of data inside a table.
  A Key can be a single attribute or a group of attributes, where the combination may act as a key.
  
  
  

  ---

  Why we need a Key?

  In real world applications, number of tables required for storing the data is huge, and the different tables are related to each other as well.
  Also, tables store a lot of data in them. Tables generally extends to thousands of records stored in them, unsorted and unorganised.
  Now to fetch any particular record from such dataset, you will have to apply some conditions, but what if there is duplicate data present and every time you try to fetch some data by applying certain condition, you get the wrong data. How many trials before you get the right data?
  To avoid all this, Keys are defined to easily identify any row of data in a table.
  Let's try to understand about all the keys using a simple example.
      Let's take a simple Student table, with fields student_id, name, phone and age.
  
  

  Super Key

  Super Key is defined as a set of attributes within a table that can uniquely identify each record within a table. Super Key is a superset of Candidate key.
  

  In the table defined above super key would include student_id, (student_id, name), phone etc.

  Confused? The first one is pretty simple as student_id is unique for every row of data, hence it can be used to identity each row uniquely.
  Next comes, (student_id, name), now name of two students can be same, but their student_id can't be same hence this combination can also be a key.
  Similarly, phone number for every student will be unique, hence again, phone can also be a key.
  So they all are super keys.
  

  ---

  Candidate Key

  Candidate keys are defined as the minimal set of fields which can uniquely identify each record in a table. It is an attribute or a set of attributes that can act as a Primary Key for a table to uniquely identify each record in that table. There can be more than one candidate key.
  In our example, student_id and phone both are candidate keys for table Student.
  
• A candiate key can never be NULL or empty. And its value should be unique.
• There can be more than one candidate keys for a table.
• A candidate key can be a combination of more than one columns(attributes).

---

Primary Key

Primary key is a candidate key that is most appropriate to become the main key for any table. It is a key that can uniquely identify each record in a table.

For the table Student we can make the student_id column as the primary key.

---

Composite Key

Key that consists of two or more attributes that uniquely identify any record in a table is called Composite key. But the attributes which together form the Composite key are not a key independentely or individually.

In the above picture we have a Score table which stores the marks scored by a student in a particular subject.
In this table student_id and subject_id together will form the primary key, hence it is a composite key.

---

Secondary or Alternative key

The candidate key which are not selected as primary key are known as secondary keys or alternative keys.

---

Non-key Attributes

Non-key attributes are the attributes or fields of a table, other than candidate key attributes/fields in a table.

---

Non-prime Attributes

Non-prime Attributes are attributes other than Primary Key attribute(s)..

• Entity Relationship Diagram – ER Diagram in DBMS

  An Entity–relationship model (ER model) describes the structure of a database with the help of a diagram, which is known as Entity Relationship Diagram (ER Diagram). An ER model is a design or blueprint of a database that can later be implemented as a database. The main components of E-R model are: entity set and relationship set.
  

  What is an Entity Relationship Diagram (ER Diagram)?

  An ER diagram shows the relationship among entity sets. An entity set is a group of similar entities and these entities can have attributes. In terms of DBMS, an entity is a table or attribute of a table in database, so by showing relationship among tables and their attributes, ER diagram shows the complete logical structure of a database. Lets have a look at a simple ER diagram to understand this concept.
  

  A simple ER Diagram:

  In the following diagram we have two entities Student and College and their relationship. The relationship between Student and College is many to one as a college can have many students however a student cannot study in multiple colleges at the same time. Student entity has attributes such as Stu_Id, Stu_Name & Stu_Addr and College entity has attributes such as Col_ID & Col_Name.
  
  Here are the geometric shapes and their meaning in an E-R Diagram. We will discuss these terms in detail in the next section(Components of a ER Diagram) of this guide so don’t worry too much about these terms now, just go through them once.
  
  Rectangle: Represents Entity sets.
  Ellipses: Attributes
  Diamonds: Relationship Set
  Lines: They link attributes to Entity Sets and Entity sets to Relationship Set
  Double Ellipses: Multivalued Attributes
  Dashed Ellipses: Derived Attributes
  Double Rectangles: Weak Entity Sets
  Double Lines: Total participation of an entity in a relationship set
  

  Components of a ER Diagram

  
  As shown in the above diagram, an ER diagram has three main components:
  1. Entity
  2. Attribute
  3. Relationship
  

  1. Entity

  An entity is an object or component of data. An entity is represented as rectangle in an ER diagram.
  For example: In the following ER diagram we have two entities Student and College and these two entities have many to one relationship as many students study in a single college. We will read more about relationships later, for now focus on entities.
  
  Weak Entity:
  An entity that cannot be uniquely identified by its own attributes and relies on the relationship with other entity is called weak entity. The weak entity is represented by a double rectangle. For example – a bank account cannot be uniquely identified without knowing the bank to which the account belongs, so bank account is a weak entity.
  
  

  2. Attribute

  An attribute describes the property of an entity. An attribute is represented as Oval in an ER diagram. There are four types of attributes:
  1. Key attribute
  2. Composite attribute
  3. Multivalued attribute
  4. Derived attribute
  

  1. Key attribute:

  A key attribute can uniquely identify an entity from an entity set. For example, student roll number can uniquely identify a student from a set of students. Key attribute is represented by oval same as other attributes however the text of key attribute is underlined.
  
  

  2. Composite attribute:

  An attribute that is a combination of other attributes is known as composite attribute. For example, In student entity, the student address is a composite attribute as an address is composed of other attributes such as pin code, state, country.
  
  

  3. Multivalued attribute:

  An attribute that can hold multiple values is known as multivalued attribute. It is represented with double ovals in an ER Diagram. For example – A person can have more than one phone numbers so the phone number attribute is multivalued.
  

  4. Derived attribute:

  A derived attribute is one whose value is dynamic and derived from another attribute. It is represented by dashed oval in an ER Diagram. For example – Person age is a derived attribute as it changes over time and can be derived from another attribute (Date of birth).
  E-R diagram with multivalued and derived attributes:
  
  

  3. Relationship

  A relationship is represented by diamond shape in ER diagram, it shows the relationship among entities. There are four types of relationships:
  1. One to One
  2. One to Many
  3. Many to One
  4. Many to Many
  

  1. One to One Relationship

  When a single instance of an entity is associated with a single instance of another entity then it is called one to one relationship. For example, a person has only one passport and a passport is given to one person.
  
  

  2. One to Many Relationship

  When a single instance of an entity is associated with more than one instances of another entity then it is called one to many relationship. For example – a customer can place many orders but a order cannot be placed by many customers.
  
  

  3. Many to One Relationship

  When more than one instances of an entity is associated with a single instance of another entity then it is called many to one relationship. For example – many students can study in a single college but a student cannot study in many colleges at the same time.
  
  

  4. Many to Many Relationship

  When more than one instances of an entity is associated with more than one instances of another entity then it is called many to many relationship. For example, a can be assigned to many projects and a project can be assigned to many students.
  
  

  Total Participation of an Entity set

  A Total participation of an entity set represents that each entity in entity set must have at least one relationship in a relationship set. For example: In the below diagram each college must have at-least one associated Student.
  

    

  The Enhanced ER Model

  As the complexity of data increased in the late 1980s, it became more and more difficult to use the traditional ER Model for database modelling. Hence some improvements or enhancements were made to the existing ER Model to make it able to handle the complex applications better.
  Hence, as part of the Enhanced ER Model, along with other improvements, three new concepts were added to the existing ER Model, they were:
  
• Generalization
• Specialization
• Aggregration

Let's understand what they are, and why were they added to the existing ER Model.

---

Generalization

Generalization is a bottom-up approach in which two lower level entities combine to form a higher level entity. In generalization, the higher level entity can also combine with other lower level entities to make further higher level entity.
It's more like Superclass and Subclass system, but the only difference is the approach, which is bottom-up. Hence, entities are combined to form a more generalised entity, in other words, sub-classes are combined to form a super-class.

For example, Saving and Current account types entities can be generalised and an entity with name Account can be created, which covers both.

Specialization

Specialization is opposite to Generalization. It is a top-down approach in which one higher level entity can be broken down into two lower level entity. In specialization, a higher level entity may not have any lower-level entity sets, it's possible.

---

Aggregration

Aggregration is a process when relation between two entities is treated as a single entity.

In the diagram above, the relationship between Center and Course together, is acting as an Entity, which is in relationship with another entity Visitor. Now in real world, if a Visitor or a Student visits a Coaching Center, he/she will never enquire about the center only or just about the course, rather he/she will ask enquire about both.