CHAPTER 3:Entity Relationship

(ER) Model
● Definition of key terms
● Entity and Entity Set
● Attributes
● Definition of an attribute
● Types of attributes
● Relationship and relationship set
● Specialization
● Weak entity
● Constraints of an ER model
● Participation constraints
● Key constraints
● Aggregation
● Exercise One
● Construction of the Entity Relationship Diagram
● Exercise Two
3.3.2 Conversion of the Entity Relationship Diagram into a Relational Model
Definition of key terms

⚫ ER model is used to show the Conceptual schema of an

organisation
⚫ The ER model describes data as entities,relationships, and
attributes.

◦Entities
◦Relationships
◦Attributes
Entity:

◦ "...anything (people, places, objects, events, etc.) about which we store

information (e.g. supplier, machine tool, employee, utility pole, airline seat,
etc.).”
◦ Tangible: customer, product
◦ Intangible: order, accounting receivable
◦ Look for singular nouns (beginner)
◦ BUT a proper noun is not a good candidate….
⚫ Entity - distinguishable “thing” in the real world
◦ Strong (or regular) entity - entities have an independent existence
(e.g. staff)

◦ Weak entity - existence dependent on some other entity (e.g. next

of kin)
● A weak entity is a type of entity which doesn’t have its key attribute. It
can be identified uniquely by considering the primary key of another
entity. For that, weak entity sets need to have participation.

Entity type name

(singular, no spaces,
capital letter at start of each word)

space for attributes

Attribute:

◦ Attributes are data objects that either identify or describe entities

(property of an entity).
◦ In other words, it is a descriptor whose values are associated with
individual entities of a specific entity type
● The process for identifying attributes is similar except now you want to look for and
extract those names that appear to be descriptive noun phrases.
⚫ Entity types have Attributes (or properties) which associate each entity
with a value from a domain of values for that attribute
⚫ Attributes can be
◦ simple (atomic) e.g. Surname; date of birth
◦ composite e.g. address (street, town, postcode)
◦ multi-valued e.g. phone number
◦ complex nested multi-valued and composite
◦ base or derived e.g. D.O.B. ; age
◦ key
⚫ Relationship types can also have attributes! (see later)
Relationship:

◦Relationships are associations between entities.

◦Typically, a relationship is indicated by a verb connecting
two or more entities.
◦Employees are assigned to projects
◦Relationships should be classified in terms of
cardinality.
● One-to-one, one-to-many, etc
⚫ A relationship is
“.. An association among entities (the participants)..”

⚫ Relationships link entities with each other

Name: verb, capital start letter,

arrow indicates direction in which
verb makes sense
 RELATIONSHIP: CONTRAINTS
⚫ The degree of a relationship type
◦ binary (connects 2 entity types)
◦ unary/ recursive (connects 1 entity type with itself)
◦ complex (connects 3 or more entity types)
● Ternary (connects 3)

⚫ Relationship constraints - cardinality

◦ one to one (1:1)
◦ one to many (1:m)
◦ many to many (m:n)
⚫ Relationship constraints – participation
◦ full/mandatory
◦ or partial/optional
⚫ Cardinality
⚫ Defines the numerical attributes of the relationship
between two entities or entity sets.

Different types of cardinal relationships are:

⚫ One-to-One Relationships
⚫ One-to-Many Relationships
⚫ May to One Relationships
⚫ Many-to-Many Relationships
Relationships: Degree
Binary relationship

Recursive (Unary) relationship -

example

Complex relationship –
here ternary

14
Relationships: Multiplicity
label lines to show cardinality and participation
0..1 “zero or one”
0..* “zero or more” optional
1..1 “one”
1..4 “between 1 and 4”
1..* “one or more”
mandatory

1..1 0..*

Entity1 has a 1:m relationship with Entity2;

participation for Entity2 is mandatory, for Entity1 optional.
15
Relationships example
Manages
Manager Department
1..1 0..3

responsibility [1..*]
dateAllocated

Each manager
Each manages UP TO 3
department is departments
Relationship
managed by (but need not manage
attributes
ONE manager any department)
16
Over to You now!
⚫ See if you can draw an E-R diagram for this scenario –
you are already familiar with this!
◦ “A student registers for up to 8 modules and each module has
many students on it. Record the student ID, their full name and
address and also each module ID and title. We also want to
hold the grade attained by each student for each module”
● Remember to show in your model:
● All primary keys,
● Entities
● Relationships
● Attributes

17
Unary Example with Data
A member of staff may supervise
◄ supervises another staff member, but a staff
member may be supervised by one
0..* or more staff members
Staff
0..1

STAFF
Member Age Supervisor
Grey 43 Black
Black 27
Brown 35 Black
White 33 Brown

18
Ternary Diagrams are Tricky!
“a client at a branch will be “a member of staff will register a
registered by one member of staff” client at one branch”

1..1 1..1
registe
Staff rs Branch

0..*
“a member of staff at a branch may
register many clients”
Client

Try to determine participation/cardinality by operating in pairs

19
Key Points
⚫ ERM
◦ Entities (strong, weak)
◦ Attributes (simple, composite, etc)
◦ Relationships
● Degree
● Cardinality
● participation

20
ER SYMBOLS
• Rectangles: This Entity Relationship Diagram symbol
represents entity types
• Ellipses : Symbol represent attributes
• Diamonds: This symbol represents relationship types
• Lines: It links attributes to entity types and entity types
with other relationship types
• Primary key: attributes are underlined
• Double Ellipses: Represent multi-valued attributes
⚫
DRAWING AN ER DIAGRAM
EXAMPLE
⚫ In a university, a Student enrolls in Courses. A student
must be assigned to at least one or more Courses. Each
course is taught by a single Professor. To maintain
instruction quality, a Professor can deliver only one
course
Step 1) Entity Identification

We have three entities

⚫ Student
⚫ Course
⚫ Professor
Step 2) Relationship Identification

We have the following two relationships

⚫ The student is assigned a course
⚫ Professor delivers a course
Step 3) Cardinality Identification

we know that,
• A student can be assigned multiple courses
• A Professor can deliver only one course
 Step 4) Identify Attributes
⚫ You need to study the files, forms, reports, data currently maintained by the organization to
identify attributes.You can also conduct interviews with various stakeholders to identify
entities. Initially, it’s important to identify the attributes without mapping them to a particular
entity.

⚫ Once, you have a list of Attributes, you need to map them to the identified entities. Ensure an
attribute is to be paired with exactly one entity. If you think an attribute should belong to
more than one entity, use a modifier to make it unique.

⚫ Once the mapping is done, identify the primary Keys. If a unique key is not readily available,
create one.

Entity Primary Key Attribute

⚫ Student Student_ID StudentName
⚫ ProfessorEmployee_ID ProfessorName
⚫ Course Course_ID CourseName

⚫ For Course Entity, attributes could be Duration, Credits, Assignments, etc. For the sake of ease
we have considered just one attribute.
Step 5) Create the ERD Diagram

⚫ A more modern representation of Entity Relationship

Diagram Example
CONSTRAINTS OF AN ER MODELS

⚫ A constraint is a rule that is used for optimization

purposes.
⚫ You can use primary key and foreign key constraints to
define relationships between tables.
⚫ Participation constraint specifies the presence of an
entity when it is related to another entity in a
relationship type
Conversion of the Entity Relationship Diagram
into a Relational Model
⚫ The first step in building a relational database from
an ERD is creating a table from each entity in the
data model.
⚫ Weak entities need slightly different handling than
regular entities, so we will address them separately,
starting with regular entities.
⚫ First, decide on a name for the table - this does not
have to be the same as the entity name!
⚫ Most attributes for the entity should be converted to
columns in the new table.
⚫ Do not create columns for derived attributes, as these
values are not intended to be stored.
⚫ Do not create columns for multivalued attributes; we will
address these later.
⚫ For composite attributes, create columns only for the
component attributes, not the composite itself.
⚫ As with entities, you will need to decide on a name for
each new column, which does not have to be the same
as the attribute name.
⚫ You will also need to specify a type and any constraints
for the column.
⚫ Constraints may be added as appropriate
⚫ Choose a key attribute (every regular entity should have at
least one) and use the column created from it as the
primary key for the new table.
⚫ If the entity has multiple key attributes, you will need to
decide which one makes most sense as a primary key.
⚫ Simpler primary keys are usually preferred over more
complex ones.
⚫ If desired, you can constrain the columns resulting from
other keys to be not null and unique similar to primary key
columns. For example, an employee table might use a
company generated ID number as its primary key, and also
include a column for a government issued ID number which
we would want to constrain to prevent duplicates.
E.G ERD for employee entity
preliminary conversion of the employee entity
into a relational table named employee:
Weak entities conversion
⚫ Weak entities are converted into tables in nearly the same way as regular
entities.
⚫ However, recall that a weak entity has no identifying key attribute. Instead,
it has a partial key, which must be combined with the key of the parent
entity.
⚫ example, the assembly line entity is weak. Its partial key, the number of
the assembly line within a particular factory, must be combined with the
factory identity for full identification.
⚫ The table created from a weak entity must therefore incorporate the key
from the parent entity as an additional column. The primary key for the new
table will be composed of the columns created from the parent key and
from the partial key.
⚫ Additionally, the column created from the parent key should be constrained
to always match some key in the parent table, using a foreign key
constraint.
⚫ Here is the ERD of assembly line and its parent entity, factory:
⚫ Using the explained guidelines, create tables factory and
assembly_line, and include a column in assembly_line for
values from the city column of factory.
⚫ A good choice of name for these “borrowed” columns is
to concatenate the original table and column names
together; in our case, this gives us the column factory_city.
⚫ (use the term “borrow” in reference to this process of
inserting a column in one table to hold values from the
primary key column of a related table.)
⚫ Here is the preliminary conversion of factory and the final
conversion of assembly line:
 Relationships
⚫ Relationships can be handled using a few different
approaches, depending on the cardinality ratio of the
relationship.
⚫ Most generally, we can create a table to represent the
relationship.
⚫ This kind of table is known as a cross-reference table, and
acts as an intermediary in a three-way join with the two (or
more) tables whose entities participate in the relationship.
⚫ As we will see, some cardinality ratios permit simpler
solutions.
⚫ Many-to-many relationships are the most general type
of relationship; a database structure accommodating
a many-to-many relationship can also accommodate
one-to-many or one-to-one relationships, as “one” is
just a special case of “many”
⚫ For example, the following ERD indicates a many-to-many
relationship between the entities vendor and part. A
computer part (such as an 8TB hard drive) can come from
multiple sellers, while sellers can sell multiple different
computer parts:
⚫ The vendor and part entities, their attributes, and the
supplies relationship connecting them
⚫ We create tables vendor and part following the guidelines
above, and then create the cross-reference table
vendor_part. (It is common to name a cross-reference
table using the names of the two tables being related,
although other schemes can of course be used.) Note that
the supplies relationship also has a relationship attribute,
price, which we can incorporate into the cross-reference
table.
⚫ The result, with some fictional data, is pictured as follows:
ERD
ER MODEL
Full model conversion ERD to ER model
⚫ collect together all of the tables produced from data
model, using the approach outlined above. For each
table we include a short explanation of how the table
relates to the data model. eg
Summary
• ER diagram is converted into the tables in relational model.
• This is because relational models can be easily implemented by
RDBMS like MySQL , Oracle etc.
⚫ While determining the minimum number of tables required for
binary relationships with given cardinality ratios, following thumb
rules must be kept in mind-
• For binary relationship with cardinality ration m : n , separate and
individual tables will be drawn for each entity set and relationship.
• For binary relationship with cardinality ratio either m : 1 or 1 : n ,
always remember “many side will consume the relationship” i.e. a
combined table will be drawn for many side entity set and
relationship set.
• For binary relationship with cardinality ratio 1 : 1 , two tables will be
required. You can combine the relationship set with any one of the
entity sets.
References
⚫ https://runestone.academy/ns/books/published/practical_db/PART2_DATA_MODEL
ING/03-ERD-to-relational/ERD-to-relational.html
⚫ https://www.gatevidyalay.com/tag/convert-er-diagram-to-relational-schema/
⚫ Visual Paradigm.
https://www.visual-paradigm.com/guide/data-modeling/what-is-entity-relationship-dia
gram.
⚫ Definition from Techopedia.
https://www.techopedia.com/definition/1200/entity-relationship-diagram-erd.
⚫ Definition & Overview | Lucidchart. https://www.lucidchart.com/pages/er-diagrams.
⚫ A Guide to the Entity Relationship Diagram (ERD) - Database Star.
https://www.databasestar.com/entity-relationship-diagram/.
⚫ All about ER model cardinality with examples | Gleek | Gleek.
https://www.gleek.io/blog/er-model-cardinality.html.
⚫ Conceptual Modeling using the Entity-Relationship Model - UC Davis.
https://web.cs.ucdavis.edu/~green/courses/ecs165a-w11/2-er.pdf.