top of page
Keet Malin Sugathadasa

Basic Concepts of Entity Relationship Modelling in Database Systems


The world that we live in can be abstracted out as a simple model which can be used to solve many existing problems. The primary concept of Object Oriented Programming is to build a model which is abstracted out from the real world, is just a bunch of classes and relationships. But the power of these models is immense to a level which provides massive advantages over real world functionalities. Identifying the world that you live in, as bits and bytes, will help you see the world in a way you can process it. This is what computer modeling does to real time problems. Seeing the world with objects and relationships is what we do in any basic computer program. The following image depicts the basic idea of abstracting out real world concepts into computer models.

Entity Relationship diagrams, short for ER diagrams, is where you identify entities or objects in a given scenario and map the relationships between these entities. This mapping from real world concepts to entities is a very confusing task where the definitions are a bit vague from what I see. So, in this blog, I address the basic definitions of each of the important scenarios and give you the general idea on how to draw your own ER diagram for given problem of interest. This article is structured as follows.

  1. What is an Entity

  2. What is a Relationship

  3. Introduction to Entity-Relationship Model (Diagram)

  4. Entity Relationship Diagrams

  5. Generalization and Specialization in ER Diagrams

  6. Weak Entity Sets

  7. Major Design Decisions in ER Modelling

What is an Entity

In simple terms, and entity is an existing or real thing. This is something that exists itself, as a subject or as an object, actually or potentially, concretely or abstractly, physically or not. The existence of such an entity is what is important. There are many different definitions for entities, in different fields like Computer Science, Philosophy etc. In general, entities can be considered as nouns. The following example will make it clear for you. Please note that the identification of entities and how you interpret them can vary from person to person.

Eg: A Dog Kills a Cat.

In this example, we can consider Dog and Cat as nouns of this sentence. So, they could be considered as two entities. Some people might call these, entity instances, and make "Animal" as an entity. According to Chen's Definition, an "Entity" can be any instance, whereas "Entity Type" is the main class of entities. An entity-type is a category. An entity, strictly speaking, is an instance of a given entity-type. There are usually many instances of an entity-type. Because the term entity-type is somewhat cumbersome, most people tend to use the term entity as a synonym for this term. Let us see more on this, in the below sections. For now, just try and understand what an entity is. Another example is given below.

Eg: A Man Owns a Car and a House

Here, you can decide what kind of abstraction you want. An entity is an abstraction from complexities of a domain. And the level of abstraction can always be picked by the designer. Here, we can pick "Man", "Car" and "House" to be three different entities. Alternatively, we can decide to have "Man" and "Possession" as two entities and include car and house has instances under possession.

Each entity in a given domain, can have its own attributes. These attributes help the designer to easily explain the properties of an entity and identify the necessary information needed. An example of attributes for a student entity is given below.

There are different kinds of attributes, which can be used to describe entities.

1) Simple Attributes: These are values which cannot be divided further. Simple atomic values. (Eg: Height)

2) Composite Attributes: These values are a collection of simple attributes. (Eg: Address: has a number, street name, city, country etc) - Shown as two different attributes of Name.

3) Derived Attributes: These values are derived from existing values. (Eg: Age: can be derived from Birthday and current date) - Shown by a dotted ellipse.

4) Single Value Attributes: The entity can have only one value for this attribute. (Eg: National ID Card Number)

5) Multi Value Attributes: The entity can have more than one value for this attribute. (Eg: Phone Number: where a student may have multiple numbers) - Shown by a double ellipse.

Entity Sets

An entity set is a set of entities of the same type that share the same properties. We use this reference to simply call all the entities at once of a selected type. Each entity in a given entity set should have a unique way of identifying it. These are called "Keys." These keys help us uniquely identify each of the necessary entities. Given below are the thee different types of keys, that can be used. This is followed by an example.

1) Super Key: One or more attributes that can be used together to uniquely identify that entity, from the given entity set.

2) Candidate Key: A minimal super key, that can be used to uniquely identify an entity. A super key can be a set of attributes used to uniquely identify an entity. Removing an attribute from it, can still have a chance of making it a super key. But in candidate keys, we can;t remove any attributes, because that will kill the uniqueness of the entity. There can be multiple candidate keys for a given entity.

3) Primary Key: A primary key, is one of the candidate keys, chosen by the designer to uniquely represent the entity. There can only be one Primary Key. Each candidate key, is a candidate for the primary key, of a given entity.

What is a Relationship

A relationship basically explains how one entity is related to another. In the above section, I mentioned that Entities can be considered as Nouns. Similarly, "Relationships" can be considered as verbs. Some examples are given below.

Eg: A Boy Marries a Girl

The identified entities can be Boy and Girl. And the Relationship can be Marry.

Here, the two entities are connected by a relationship. It is important to identify relationships correctly, since that is what explains the logic behind the entities in a given domain. In basic terms, the association between entities can be referred to as a relationship.

Introduction to Entity-Relationship Model (Diagram)

An Entity Relationship Model, which is also known as a ER Model, explains the relationships between objects (entities), within a given domain of interest. An entity relationship model consists of three major components.

  1. Entity

  2. Relationship

  3. Cardinality

Every ER Model has entities and relationships between these entities, that explains how the entities are connected to each other. The cardinality gives the relationships between objects, in terms of numbers. An example ER Diagram is shown below. An ER Model is the model that we develop from real world concepts, and an ER Diagram is what we use to represent the ER Model.

An ER Diagram, is a basic flowchart that identifies how entities in a given domain, interact with each other as a flow of events. The cardinality of ER diagrams is important, as it shows the number of entities which are connected to another selected entity. It makes the life easy for the programmer as well as the reader, to understand the type of relationship each entity has, over others. Let's now have a look at how cardinality works in ER Diagrams.

Cardinality in ER Diagrams

1) One to One

One entity set from A, can be associated with at most one entity set from B and vice versa.

Eg: One student can only have one Passport, and one Passport can have only one student.

2) One to Many

One entity set from A, can be associated with many entity sets from B, and any entity set from B, can only be associated with a single entity from A.

Eg: One Mother can be associated with many children, but a Child can only be associated with one mother.

3) Many to One

One entity set from A, can be associated with only one entity set from B. And One entity set from B, can be associated with a many entity sets from A.

Eg: Siblings can have only one Mother, and one Mother can have many children who are siblings.

4) Many to Many

One entity set from A, can be associated with many entity sets from B, and vice versa.

Eg: A person from A can be friends with any person in B, and a person in B can be friends with many people in A.

Degree of a Relationship

The degree of a relationship describes the number of entities which are participating in a given relationship. In general, may relationships are Binary.

  1. Binary - 2 Degree

  2. Tertiary - 3 Degree

  3. n-ary - n degree

When entities are participating in relationships, the participating entities can have constraints known as Participation Constraints.

Participation Constraints

There are two different kinds of Constraints that can be enforced between entities and relationships.

  1. Total Participation

  2. Partial Pariticipation

Total Participation is where each entity in the participating entity set, has to be involved in the specified relationships. In diagrams, this is depicted by a double line. (See image Below).

Eg: Human Entity, with the Relationship Born. All human entities must take part in the relationship born

Partial Participation is where some entities may take part in the relationship, whereas some might not.

Eg: Student Entity, with the Relationship Studies.. Some students may decide not to study, where as some might study.

Entity Relationship Diagrams

When we are drawing ER Diagrams, we can use different kinds of notations to cater to our purpose. A list of different notations that can be used, are given below.

Some of the general notation rules are as follows.

  • Entity Set - Rectangles

  • Attributes - Listed inside the entity rectangle

  • Primary Key Attribute - Underline the Primary Key from the list of attributes.

  • Relationships Sets - Diamonds Represent the Relationship sets.

  • Relationship Attributes - Indicated by a dashed line, within a square.

  • Complex Attributes - Represented within the list of attributes as given below.

Generalization and Specialization in ER Diagrams

One of the major advantages in using ER Diagrams for modeling a real life problem, is that it gives the power of creating hierarchical structures, within the model itself. This could be in various forms, such as inheritance, abstraction etc. With this feature, we can go deep into the model, as well as view from the top of the model, with different levels of views, defined by the designer him/herself. These are usually referred to as extended features of ER Diagrams.

Weak Entity Sets

A weak entity is considered to be an entity, that cannot be uniquely identified by its attributes alone. These attributes require a foreign key in conjunction with its own attributes, to form a primary key. So, basically it is an entity set without a primary key. To understand more on this, you need to understand what identifying entity sets are. Let's consider the following example.

  • course - {course_id, tittle, credits}

  • section - {course_id, sec_id, semester, year, building}

In this, you can see that the entity section is a weak entity set, because it is using a foreign key to create its own primary key. Else, this would not be possible. The identifying entity set in this example is the entity set named "Course". This is because, it helps the weak entity set to identify itself.

The relationship between the weak entity set and the identifying entity set is known as an Identifying Relationship. There should always be a total participation from weak entity set to Identifying Relationship. From the weak entity set to identifying entity set, it should be a Many to One relationship. The attributes in the weak entity set, which support to form the primary key within it, are known as Discriminators.

The following image depicts this example clearly. The notation is explained as well.

  • Identifying relationship is denoted by a double diamond.

  • The discriminator of a weak entity set is underlined with a dashed line.

Major Design Decisions in ER Modelling

  • The use of an attribute or entity set to represent an object

  • Whether a real-world concept is best expressed by an entity set or a relationship set

  • The use of a ternary relationship versus a pair of binary relationships

  • The use of a strong or weak entity set

  • The use of specialization/generalization –contributes to modularity in the design

  • The use of aggregation –can treat the aggregate entity set as a single unit without concern for the details of its internal structure.

 

References

2,128 views0 comments
bottom of page