Database Management System

CS-116
E-R Model

Ms. Jyoti Snehi

Department of Computer Science and Engineering
Chitkara University, Punjab
DBMS Ms. Jyoti Snehi GP-19,21,27 1
 ER Model

• Entity-relationship (E-R) model is an effective and standard method

of communication amongst different designers, programmers and
end-users who tend to view data and its use in different ways.
• It is a non-technical method, which is free from ambiguities and
provides a standard and a logical way of visualising the data.
• It gives precise understanding of the nature of the data and how it is
used by the enterprise.
• E-R modelling is a high-level conceptual data model developed to
facilitate database design.
• A conceptual data model is a set of concepts that describe the
structure of a database and the associated retrieval and update
transactions on the database.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 2
 E-R Model

DBMS Ms. Jyoti Snehi GP-19,21,27 3

 ER Model

• It is independent of any particular database management system

(DBMS) and hardware platform.
• E-R model is also defined as a logical representation of data for an
enterprise.
• It was developed to facilitate database design by allowing
specification of an enterprise schema, which represents the overall
logical structure of a database.
• It is sometimes regarded as a complete approach to designing a
logical database schema.
• It is very useful in mapping the meanings and interactions of real-
world enterprise onto a conceptual schema.
• Many database design tools draw on concepts from the E-R model.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 4
 ER Model

• E-R model provides the following four main semantic concepts to

the designers:
– Entities: which are distinct objects in a user enterprise.
– Relationships: which are meaningful interactions among the
objects.
– Attributes: which describe the entities and relationships. Each
such attribute is associated with a value set (also called domain)
and can take a value from this value set.
• The ER model also has an associated diagrammatic representation, the ER
diagram, which can express the overall logical structure of a database
graphically.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 5
 Database Design Process

The main phases of database design are:

• Requirements Analysis:
– The very first step in designing a database application is to
understand what data is to be stored in the database, what
applications must be built on top of it, and what operations are
most frequent and subject to performance requirements.
• Conceptual Database Design:
– The information gathered in the requirements analysis step is
used to develop a high-level description of the data to be stored
in the database, along with the constraints that are known to hold
over this data.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 6
 Database Design Process

• Logical Database Design:

– We must choose a DBMS to implement our database design, and
convert the conceptual database design into a database schema in
the data model of the chosen DBMS.
• Schema Refinement:
– The fourth step in database design is to analyze the collection of
relations in our relational database schema to identify potential
problems, and to refine it.
– In contrast to the requirements analysis and conceptual design
steps, which are essentially subjective, schema refinement can be
guided by some elegant and powerful theory.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 7
 Database Design Process

• Physical Database Design:

– In this step we must consider typical expected workloads that
our database must support and further refine the database design
to ensure that it meets desired performance criteria. This step
may simply involve building indexes on some tables.
• Security Design:
– In this step, we identify different user groups and different roles
played by various users.
– For each role and user group, we must identify the parts of the
database that they must be able to access and the parts of the
database that they should not be allowed to access.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 8
 ER Model Symbols

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

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 9
 Naming Conventions

• When designing a database schema, the choice of names for entity

types, attributes, relationship types, and (particularly) roles is not
always straightforward.
• One should choose names that convey, as much as possible, the
meanings attached to the different constructs in the schema.
• We choose to use singular names for entity types, rather than plural
ones, because the entity type name applies to each individual entity
belonging to that entity type.
• In our ER diagrams, we will use the convention that entity type and
relationship type names are in uppercase letters, attribute names
have their initial letter capitalized, and role names are in lowercase
letters.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 10
 Entity and Entity Set

• An entity is an object in the real world that is distinguishable from

other objects.
• An entity is described using a set of attributes.
• It is often useful to identify a collection of similar entities, such a
collection is called an entity set.
• An entity may be an object with a physical or conceptual existence
– Examples of physical entity: a particular person, car, house,
employee, etc.
– Examples of conceptual entity: a company, a job, a university
course, etc.

Ms. Jyoti Snehi GP-19,21,27

DBMS 11
 Design Issues

• Use of Entity Sets versus Attributes

• Use of Entity Sets versus Relationship Sets
• Binary versus n-ary Relationship Sets
• Placement of Relationship Attributes

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 12
 Components of ER Diagram

DBMS Ms. Jyoti Snehi GP-19,21,27 13

 Entity

• What is an Entity?
• Has its own identity that distinguishes it from other entities.
– Examples:
• Person: PROFESSOR, STUDENT
• Place: STORE, UNIVERSITY
• Object: MACHINE, BUILDING
• Event: SALE, REGISTRATION
• Concept: ACCOUNT, COURSE

DBMS Ms. Jyoti Snehi GP-19,21,27 14

 Entity
(Entity Type vs. Entity Instances)

• Entity Type is a collection of entities that share common properties or

characteristics.

STUDENT CLASS PROFESSOR

• Entity Instance is a single occurrence of an entity type.

STUDENT
– Entities should always be placed in a rectangle!

DBMS Ms. Jyoti Snehi GP-19,21,27 15

 Entity Types
(Naming Guidelines)

Entity type name should be:

– A singular noun and in capital letters.
– Descriptive and specific to the organization.
– Concise.
– Named for the result of the event, not the activity or process of
the event.

DBMS Ms. Jyoti Snehi GP-19,21,27 16

 University Entity-Relationship Diagram

Entity

DBMS Ms. Jyoti Snehi GP-19,21,27 17

 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.

DBMS Ms. Jyoti Snehi GP-19,21,27 18

 Entity Types

• Entity types can be classified as being strong or weak entity.

• An entity type that is not existence-dependent on some other entity
type is called strong entity type.
• The strong entity type has a characteristic that each entity
occurrence is uniquely identifiable using the primary key attribute(s)
of that entity type.
• An entity type that is existence-dependent on some other entity type
is called weak entity type.
• The week entity type has a characteristic that each entity occurrence
cannot be uniquely identifiable using only the attributes associated
with that entity type.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 19
 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.

DBMS Ms. Jyoti Snehi GP-19,21,27 20

 Attributes

• Each Entity has a set of Attributes

• Attribute is a property or characteristic of an entity that is of
interest to the organization.
– Example:
• STUDENT: Student_ID, Student_Name, Phone_Number,
Major

DBMS Ms. Jyoti Snehi GP-19,21,27 21

 Attributes

Student

Student_ID
Student_Address
Student_Phone

DBMS Ms. Jyoti Snehi GP-19,21,27 22

 Attributes
(Defining Guidelines)

• An attribute definition should:

– State what the attribute is and why it is important.
– Make clear what is and isn’t included in the attribute's value.
– Define any aliases.
– Indicate if the attribute is required or not.
– Indicate any relationships with other attributes.

DBMS Ms. Jyoti Snehi GP-19,21,27 23

 Attributes

• Candidate Key = is an attribute that uniquely identifies each

instance of an entity type.
• Identifier = A candidate key that has been selected as the unique,
identifying characteristic of an entity type. (Should be underlined).
• Other types of Attributes: multivalued, required, optional,
composite, and derived.

DBMS Ms. Jyoti Snehi GP-19,21,27 24

 Criteria for Selecting Attributes

• Choose a candidate key that will not change

its value.
• Choose a candidate key that has valid values
and not be null.
• Avoid using codes, such as a 2 digit warehouse
location.

DBMS Ms. Jyoti Snehi GP-19,21,27 25

 Attributes and their types

• Each entity has attributes—the particular properties that describe it.

For example, an EMPLOYEE entity may be described by the
employee’s name, age, address, salary, and job.
• Several types of attributes occur in the ER model:
– Simple attribute
– Composite attribute
– Derived attributes
– Single-valued attribute
– Multi-valued attribute

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 26
 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.

DBMS Ms. Jyoti Snehi GP-19,21,27 27

 Simple vs. Composite attribute

• A simple attribute cannot be subdivided.

– Examples
• Age, Gender, and Marital status
• A composite attribute can be further subdivided to yield additional
attributes.
– Examples
• ADDRESS: Street, City, State, Zip
• PHONE NUMBER: Area code, Exchange number

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 28
 Derived attribute

• Derived attribute is not physically stored within the database

instead, it is derived by using an algorithm.
– Example 1: Late Charge of 2% can be computed by using
InvoiceAmt
• LateCharge =InvoiceAmt * 0.02
– Example 2: AGE can be derived from the date of birth and the
current date.
• AGE = int(Date() – Emp_Dob)/365)

• Note: GP-27

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 29
Single vs. Multi-valued attribute

• Single –valued attributes can have only a single (atomic) value.

– Examples:
• A person can have only one social security number.
• A manufactured part can have only one serial number.
• A single-valued attribute is not necessarily a simple attribute.
• Multi-valued attributes can have many values.
– Examples:
• A person may have several college degrees.
• A person may have more than one mobile numbers

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 30
 Keys

• Primary key is a column of a table or a set of columns that helps to

identify every record present in that table uniquely.
• Candidate Keys are those attributes that uniquely identify rows of a
table. The Primary Key of a table is selected from one of the
candidate keys.
• Super Key is the set of all the keys which help to identify rows in a
table uniquely. This means that all those columns of a table than
capable of identifying the other columns of that table uniquely will
all be considered super keys.
• Foreign Key is used to establish relationships between two tables. A
foreign key will require each value in a column or set of columns to
match the Primary Key of the referential table.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 31
 Keys

• Composite Key is a set of two or more attributes that help identify

each tuple in a table uniquely. The attributes in the set may not be
unique when considered separately.
• Alternate Key: A table can have multiple choices for a primary key;
however, it can choose only one. So, all the keys which did not
become the primary Key are called alternate keys.
• Unique Key is a column or set of columns that uniquely identify
each record in a table. A unique Key differs from a primary key
because it can have only one null value, whereas a primary Key
cannot have any null values.

Ms. Jyoti Snehi GP-19,21,27

DBMS 32
 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

DBMS Ms. Jyoti Snehi GP-19,21,27 33

 Relationships

• Relationships are associations between one or more entity types.

• Are the “glue” that holds together components of an E-R model.
• The degree of a relationship = is the number of entity types that
participate in a relationship.
– There are 3 common relationships:
1. Unary (degree one)
2. binary (degree two)
3. Ternary (degree three)

DBMS Ms. Jyoti Snehi GP-19,21,27 34

University Entity-Relationship Diagram

Relationship

DBMS Ms. Jyoti Snehi GP-19,21,27 35

 Relationships
(Naming Guidelines)

• A relationship name should:

Be a verb phrase, such as Is_assigned_to.
Avoid vague names, such as “Has”.

DBMS Ms. Jyoti Snehi GP-19,21,27 36

 Unary Relationship

• Relationship between the instances of one

entity type.

Is_married_to Manages
EMPLOYEE
PERSON

DBMS Ms. Jyoti Snehi GP-19,21,27 37

 Binary Relationship

• Relationship between the instances of two

entity type.

Is_assigned
PARKING Contains
EMPLOYEE
SPACE PRODUCT
PRODUCTS
LINE

One-to-One One-to-Many
DBMS Ms. Jyoti Snehi GP-19,21,27 38
Can also have many to many!
 Ternary Relationship

• A simultaneous relationship among instances

of three entity types.

PART

VENDOR WAREHOUSE
Supplies

DBMS Ms. Jyoti Snehi GP-19,21,27 39

 Relationship Cardinalities

• Mandatory Cardinalities = The entity must

participate in another entity.
• Optional Cardinalities = The entity has a the
option to participate in another entity.

DBMS Ms. Jyoti Snehi GP-19,21,27 40

 Starting an ERD

1. Define the Entities.

2. Define the Relationships.
3. Add attributes to the relationships.
4. Add cardinality to the relationships.
5. Don’t forget to use proper naming
conventions and symbol representation.

DBMS Ms. Jyoti Snehi GP-19,21,27 41

 Relationships

• 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.

DBMS Ms. Jyoti Snehi GP-19,21,27 42

• 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.

DBMS Ms. Jyoti Snehi GP-19,21,27 43

• 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.

DBMS Ms. Jyoti Snehi GP-19,21,27 44

• 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.

DBMS Ms. Jyoti Snehi GP-19,21,27 45

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.

DBMS Ms. Jyoti Snehi GP-19,21,27 46

E-R diagram with multivalued and
derived attributes:

DBMS Ms. Jyoti Snehi GP-19,21,27 47

 ER Diagram

DBMS Ms. Jyoti Snehi GP-19,21,27 48

 Designing the General Hardware
Company Database

DBMS Ms. Jyoti Snehi GP-19,21,27 7-49

 Designing the Good Reading
Bookstores Database

DBMS Ms. Jyoti Snehi GP-19,21,27 7-50

 Designing the World Music
Association Database

DBMS Ms. Jyoti Snehi GP-19,21,27 7-51

 Designing the World Music
Association Database

DBMS Ms. Jyoti Snehi GP-19,21,27 7-52

 Designing Rent-A-Car

DBMS Ms. Jyoti Snehi GP-19,21,27 7-53

 Class- Assignment

Design E_R Model for COVID MANAGEMENT

Time: 30 Minutes
GP-21,27

DBMS Ms. Jyoti Snehi GP-19,21,27 7-54

 Codd’s 12 Rules

• In 1985, Dr. Codd published a list of 12 rules that concisely defined

an ideal relational database.
• These rules have been used as a guideline for the design of all
relational database systems since then.
• These rules are based upon the foundation principle, which states
that for any system to be called a relational database management
system, the relational capabilities must be able to manage it
completely.

Dr. Sachendra S. Chauhan - G32

 Rules

• Rule 1: The Information Rule

– All information in the relational database is represented in
exactly one and only one way—by values in tables.
• Rule 2: Guaranteed Access Rule
– Each and every datum (atomic value) is guaranteed to be
logically accessible by resorting to a combination of table name,
primary key value, and column name.
• Rule 3: Systematic Treatment of NULL Values
– NULL values are supported in the fully relational RDBMS for
representing missing information in a systematic way,
independent of data type.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 56
 Rules

• Rule 4: Dynamic Online Catalog Based on the Relational Model

– The database description is represented at the logical level in the
same way as ordinary data, so authorized users can apply the
same relational language to its interrogation as they apply to
regular data.
• Rule 5: Comprehensive Data Sublanguage Rule
– A relational system may support several languages and various
modes of terminal use. However, there must be at least one
language whose statements are expressible by some well-defined
syntax, as character strings and whose ability to support. data
definition, view definition, data manipulation, integrity
constraints, authorization and transaction boundaries.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 57
 Rules

• Rule 6: View Updating Rule

– All views that are theoretically updateable are also updateable by
the system. This rule deals with views, which are virtual tables
used to give various users of a database different views of its
structure. It’s one of the most challenging rules to implement in
practice, and no commercial product fully satisfies it today.
• Rule 7: High-Level Insert, Update, and Delete
– The capability of handling a base relation or a derived relation as
a single operand applies not only to the retrieval of data but also
to the insertion, update, and deletion of data.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 58
 Rules

• Rule 8: Physical Data Independence

– Application programs and terminal activities remain logically
unimpaired whenever any changes are made in either storage
representation or access methods.
– Applications must still work using the same syntax, even when
changes are made to the way in which the database internally
implements data storage and access methods.
• Rule 9: Logical Data Independence
– Application programs and terminal activities remain logically
unimpaired when information preserving changes of any kind
that theoretically permit unimpairment are made to the base
tables.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 59
 Rules

• Rule 10: Integrity Independence

– Integrity constraints specific to a particular relational database
must be definable in the relational data sublanguage and storable
in the catalog, not in the application programs.
– The database must support a minimum of the following two
integrity constraints:
• Entity integrity: No component of a primary key is allowed
to have a NULL value.
• Referential integrity: For each distinct non-NULL foreign
key value in a relational database, there must exist a
matching primary key value from the same domain.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 60
 Rules

• Rule 11: Distribution Independence

– The data manipulation sublanguage of a relational DBMS must
enable application programs and terminal activities to remain
logically unimpaired whether and whenever data are physically
centralized or distributed.
• Rule 12: Non-Subversion Rule
– If a relational system has or supports a low-level (single-record-
at-a-time) language, that low-level language cannot be used to
subvert or bypass the integrity rules or constraints expressed in
the higher-level (multiple-records-at-a-time) relational language.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 61
 Relational Model Concepts

• The relational model represents the database as a collection of

relations.
• In the relational model terminology, a row is called a tuple, a
column header is called an attribute, and the table is called a
relation.
• The data type describing the types of values that can appear in each
column is represented by a domain of possible values.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 62
 Characteristics of Relations

• Ordering of Tuples in a Relation.

– A relation is defined as a set of tuples.
– Mathematically, elements of a set have no order among them;
hence, tuples in a relation do not have any particular order.
– In other words, a relation is not sensitive to the ordering of
tuples. However, in a file, records are physically stored on disk,
so there always is an order among the records.
– This ordering indicates first, second, ith, and last records in the
file.
– Similarly, when we display a relation as a table, the rows are
displayed in a certain order.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 63
 Characteristics of Relations

• Ordering of Values within a Tuple and an Alternative Definition

of a Relation.
– According to the definition of a relation, an n-tuple is an ordered
list of n values, so the ordering of values in a tuple and hence of
attributes in a relation schema is important.
– However, at a more abstract level, the order of attributes and
their values is not that important as long as the correspondence
between attributes and values is maintained.
– An alternative definition of a relation can be given, making the
ordering of values in a tuple unnecessary.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 64
 Characteristics of Relations

• Values and NULLs in the Tuples.

– Each value in a tuple is an atomic value; that is, it is not divisible
into components within the framework of the basic relational
model.
– Composite and multi-valued attributes are not allowed.
– This model is sometimes called the flat relational model.
– Multi-valued attributes must be represented by separate
relations.
– NULL values are used to represent the values of attributes that
may be unknown or may not apply to a tuple.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 65
 Characteristics of Relations

• Interpretation (Meaning) of a Relation.

– The relation schema can be interpreted as a declaration or a type
of assertion.
– For example, the schema of the STUDENT relation asserts that,
a student entity has a Name, RollNo, Home_phone, Address,
Office_phone, Age, and Gpa.
– Each tuple in the relation can then be interpreted as a fact or a
particular instance of the assertion.
– A tuple asserts the fact that there is a STUDENT whose Name is
Ravi Kumar, RollNo is 902003016, Age is 19, and so on.
– The relational model represents facts about both entities and
relationships uniformly as relations.

DBMS Dr. Ms.

Sachendra S. Chauhan
Jyoti Snehi - G32
GP-19,21,27 66
 Aggregation

• Aggregation is a process in which a single entity alone is not able to

make sense in a relationship so the relationship of two entities acts
as one entity. I know it sounds confusing but don’t worry the
example we will take, will clear all the doubts.
• Aggregration Example

DBMS Ms. Jyoti Snehi GP-19,21,27 67

 Convert ER Diagram into Relational Model

When the user creates the ER diagram of any database, then he/she has
a need to convert the created ER model into the relational model
(Tables). Because, the relational model can be easily and directly
implemented in the RDBMS software like MySQL, MS-SQL, and Oracle. 
An Entity Relationship diagram contains strong entities with a different
type of attributes and relationship set between the tables. 

DBMS 68
 Rule 1: Strong Entity with Simple Attributes

The Strong entity with simple attributes is represented by a single table in the relational
model. In this rule, simple attributes of an entity are taken as fields of the table. And, the
key attribute is specified as the primary key of the corresponding table. 

DBMS 69
Rule 1: Strong Entity with Simple Attributes

Example:
In this example, a strong entity Employee in the ER diagram is represented by the Employee table in the relational model. And, the
five attributes of Employee entity selected as the fields of the employee table. And, the Emp_ID acts as the primary key of the
table. 
DBMS 70
Rule 2: Strong Entity with Composite Attributes

The Strong entity with Composite attributes is represented by a single table in

the relational model.
In this rule, the simple attributes of composite attributes are taken as columns
of the relational table, but the composite attributes are not taken as a column
in the table. And, the key attribute is specified as the primary key of the
corresponding table. 

Example: 
In this example, a strong entity Employee in the ER diagram contains one
composite attribute.  
After conversion, a strong entity Employee is represented by the Employee
table in the relational model. And, the attributes of the Name ( composite
attribute ) selected as the fields of the employee table. And, the Emp_ID acts
as the primary key of the table. 

DBMS 71
Rule 2: Strong Entity with Composite Attributes

DBMS 72
Rule 3: Strong Entity with Multi-valued Attributes

The Strong entity with multi-valued attributes is represented by two tables in the
relational model. 
In this rule, one relational table contains the primary key and the multi-valued
attributes of the strong entity. And, the other relational table contains the primary
key and other simple attributes.

Example: 
In this example, the strong entity Employee contains three simple attributes and
two multi-valued attributes in the ER diagram. 
After conversion, Employee entity is represented by the two tables in the
relational model.
The attributes of the first table are Emp_ID and Email_ID. The attributes of
another table are Emp_ID, Name, and Age. 

DBMS 73
Rule 3: Strong Entity with Multi-
valued Attributes

DBMS 74
Rule 4: Convert Relationship Set into Relationship
Table

The Relationship set in ER diagram is represented by only one table in the relational
model. 
In this rule, the key attributes of the participating entity set are taken as the attributes of
the relationship table in the relational model. And, if there is any attribute of relationship
set in the ER diagram, then that attribute is added as attributes of the relationship
table.  

Example:
In this example, two strong entities Employee and Department are related to each
other with a relationship Works-In. 
After Conversion, the key attributes Emp_ID and Dept_ID of Employee and
Department entity will be the attributes of Works-In table in the relational model. And,
the attribute (Works_From) of Works-In relationship set is taken as the another field of
relationship table. 

DBMS 75
Rule 4: Convert Relationship Set into Relationship Table

DBMS 76