Unit 1: Entity-Relationship Model

Unit 1: Entity-Relationship
Model.
2020/2021
Contents
1.1. Introduction.
1.2. Basic concepts.
1.3. Entities.
1.4. Attributes.
1.5. Relationships.
1.6. Constraints.
1.7. Associative entity.
1.8. Enhanced E-R Model.
1.9. Translation of the E-R Model to the Relational Model.
1.10. Understanding the E-R model.
1.1. Introduction.
● A data model is the result of modeling the data of a system.
You won’t start building a house without a model (the plan
made by an architect).
● A data model describes the data, relationships between
different data, semantics associated with data and
constraints of consistency.
● The data model is an essential way to communicate with the
Database Administrator (the one responsible to ensure the
correct and efficient operation of the System Databases).
Levels of data
abstraction
1.1. Introduction.
● Different data models are defined according to the level of
abstraction that we are studying: logical or conceptual models,
models based on registers, physical models, etc. One of the
most widely used models at the logical/conceptual level is the
Entity-Relationship (E-R) Model.
● The E-R Model was proposed by Peter Chen in 1976 to

represent conceptually problems of the real world.
1.1. Introduction.
● ER data model was developed to facilitate database design by
allowing specification of an enterprise schema that
represents the overall logical structure of a database.
● ER data model describes graphically data addressed to

users, and does not intend to describe how data will be
stored internally.
1.1. Introduction.
● An ER model is a conceptual data model that views the real
world as entities and relationships.
● An ER model is useful for a DB designer in 3 ways:
1. It can be mapped to relational model.
2. It can be used to communicate the design of the database

to the end user.
3. It’s independent of a concrete DBMS software.

1.1. Introduction.
● Database design process:
Analysis ER Model Relational Model

It’s based on the perception of the real world as a collection of basic objects called
entities and the relationships between these objects. The information we need from
entities or relationships are the attributes.
Generated with creately.com

Main components:
● Entities
● Relationships
● Associative entities
● Attributes
1.3. Entities.
● An entity is a ‘thing’ or ‘object’ of the real world that is
distinguishable from all other objects. Examples: consumer
goods, customers, invoices, students, professors, books, …
● To name the object the singular form is usually used.

● The entity is the set of these objects as a group.
● The instances, occurrences, or members of an entity are each
of the individual objects that are part of an entity.
1.3. Entities.
● Some authors define:
○ Entities are like objects in OO programming. Entity sets

are like the classes. (Entities=Instances and Entity
Sets=Entities).
1.3. Entities.
Every entity must have the following characteristics:
● Each instance must be unambiguously identified (there must

be some way to differentiate two individual instances of an
entity).
● Each entity plays a role within the system (the system will not
work without accessing its members –instances–).
● Each entity can be described by one or more elementary data
(attributes). The attributes are applied to each instance of the
entity.
1.3. Entities.
Some author call this table the relationship set for the relationship
and the members of the relationship set are the rows of the table.
1.3. Entities: Types.
● Weak entities:
● Strong entities: ○ The ones that depends on a strong
○ The ones whose existence does not entity for its existence.
depend on the existence of any other ○ It is denoted by the double rectangle.
entity in a schema. ○ Weak entity do not have a identifier,
○ It is denoted by a single rectangle. instead it has a partial identifier (or
○ A strong entity always has the primary discriminator) that uniquely
attribute or identifier in the set of discriminates the weak entities. The
attributes that describes the strong entity identifier of a weak entity is a
(we will see this later). It indicates that composite identifier formed from
each entity in a strong entity set can be the primary attribute of the strong
uniquely identified. entity and discriminator of the weak
entity.
Example 1: In the below ER Diagram, ‘Payment’ is the

weak entity. ‘Loan Payment’ is the identifying
relationship and ‘Payment Number’ is the partial Example 3: The bank account of a particular bank has no
identifier. Main identifier of the Loan along with the existence if the bank doesn’t exist anymore.
partial identifier would be used to identify the records.
Example 4: A company may store the information of
strong weak dependants (Parents, Children, Spouse) of an Employee. But
entity entity the dependants don’t have existence without the employee. So
Dependent will be weak entity type and Employee will be
Identifying Entity type for Dependant.
Other examples:
Strong entity | Weak entity
Order | Order Item
Example 2: The existence of rooms is entirely Host | Logins
dependent on the existence of a hotel. So room can be
seen as the weak entity of the hotel.
Copied from: https://www.geeksforgeeks.org/weak-entity-set-in-er-diagrams/

● Another way to see weak entities is that occasionally instances of an entity need “help” to identify
them uniquely.
● Example of football players:
○ name is almost a key for football players, but there might be two with the same name.
○ number is certainly not a key, since players on two teams could have the same number.
○ But number, together with the team name related to the player by Plays-on should be unique.
● PLAYER is weak if in order to identify instances inside it we need to follow one or more many-one
relationships from PLAYER and include the identifier of the related entities from the connected entity
TEAM.
● A weak entity has one or more many-one relationships to other
(supporting) entity.
○ Not every many-one relationship from a weak entity need be
supporting.
● The key for a weak entity is its own underlined (dashed) attributes and
the keys for the supporting entity.
● When Do We Need Weak Entity Sets?
○ The usual reason is that there is no global authority capable of
creating unique ID’s (surrogate key).
○ Example: it is unlikely that there could be an agreement to assign
unique player numbers across all football teams in the world.
1.4. Attributes.
● They are the data that we need to keep from each entity, associative entity or
relationship.
● PROFESSOR: SSN, name, e-mail, phone number, address, etc.
● teachs: year.
● SUBJECT: name, studies, hours, course.
1.4. Attributes: Types.
1.- Simple and Single-Valued: It is an attribute consisting of only one
field. Example: SSN (in the United States, a Social Security number).
2.- Composite: It is an attribute consisting of multiple fields. Example:

name consisting of first name, middle name and last name. It is denoted
by many ellipses containing individual field names joined to a single
ellipse containing the composite attribute.
3.- Multivalued: It is an attribute that has multiple values.
Example: phone number and e-mails can have multiple values for
a person. It is denoted by coinciding ellipses.
4.- Derived: It is an attribute that is not physically stored in the

database can be extracted from existing attributes. Example: age
can be extracted from the difference between date of birth and
current date. It is denoted by dotted ellipses.
5.- Identifier or Primary Attribute: An identifier (primary
key in the relational model) is one or more attributes in an
entity that uniquely identifies an entity occurrence (i.e. no
other entity occurrence can contain the same key). Example:
employee id, account number, etc. Its denoted by an ellipse
with an underline underneath the attribute name.
5.- Identifier or Primary Attribute:
● Often, people introduce attributes (=”artificial identifiers”) whose role is to

serve as an identifier for entities.
● Companies assign employee IDs to all employees, and these IDs are
carefully chosen to be unique numbers. But employees have a SSN,
Students IDs in universities, driver license numbers, automobile registration
numbers, etc.
● Only use an “artificial” identifier if you can not use as identifier one of the
attributes that already exist in the entity.
6.- Discriminator or Partial Identifier: For weak entity, the attribute that
uniquely identifies it is called as a discriminator. Example: Receipt number
when payment is a weak entity depending on the loan entity. It is denoted by an
ellipse with dotted underline underneath the attribute name.
Receipt Number
1.5. Relationships.
● Entities are linked to each other by relationships.
● Every relationship must have a name.
● A relationship does not exist by itself. It needs the entities to make sense.
● There may be instances of CUSTOMER or ITEM that do not have any

PURCHASES associated. However, there is no point in a PURCHASE
instance that does not have a CUSTOMER and an associated ITEM.
1.5. Relationships.
● A relationship is defined as the association among several entities.

● An instance of CUSTOMER may be associated with 0 or more occurrences of
ITEM, and vice versa.
● An instance of the PURCHASE relationship represents an association
between 1 occurrence of CUSTOMER and 1 occurrence of ITEM.
1.5. Relationships.
● The relationship represents something that must be remembered in the system,
something that can not be calculated or derived from other data in the system.
● The relationship that can be calculated or derived from other data must NOT be
represented.
x
x x
1.5. Relationships: Types.
1.- Unary (or Recursive) Relationship: Relationship which associates an entity
of the same type to itself. Example: A person belonging to the Employee entity is
the manager of other person of the same Employee entity using a relationship
works-for.
● An employee has a boss, and an employee is boss of 0
or more employees. What does it happen to the owner
of the enterprise?
● A person has a father and a mother, and a person can

be father or mother of 0 or more persons. What does it
happen with couples of the same gender?
2.- Binary Relationship: Relationship which associates one entity to another
entity. Example: Employee entity is related to Department entity using a
relationship works-for.
3.- Ternary Relationship: Relationship in which 3 entities are associated to each
other using a single relationship (“enrolls” needs the 3 entities to exist). Example:
Student enrolls for a concrete subject (or course) that has a concrete teacher.
Student, Subject and Teacher are 3 entities which together take part in the
relationship enrolls.
4.- Quaternary Relationship: Here 4 entities take part in the relationship and
together have to co-exist to make the relationship possible. Example: Student
studies for a Subject using a particular Book under a particular Teacher.
5.- N-ary Relationship: Here n-entities take part in a relationship simultaneously
to make the relationship to exist..
VERY IMPORTANT: N-ary Relationship be understood as a unit. The relationship must be studied
from the perspective of each of the participating objects. It is the set of all those perspectives who
completely describes the interrelation.
● Strong relationship: Relationship which associates several strong entities.
Example:
● Weak relationships: Relationship which associates several weak entities.

Example:
1.5. Relationships: Attributes of a relationship.
We wish to record the salary
associated with a contract.
Can’t associate it with the Actor entity

because an actor/actress might get
different salaries for different movies.
Doesn’t make sense to associate it

with a studio or with a movie.
However, it’s appropriate to associate

a salary with the (actor movie, studio)
triple in the relationship set for the
Contract relationship.
1.6. Constraints.
An E-R diagram has certain constraints to which the contents

of the database system must conform to. The two main types
constraints are:
● Cardinality or degree of a relationship.
● Optional relationships.
1.6. Constraints: Cardinality or degree of a relationship.
One-to-one (1:1)
● This is where one occurrence of an entity relates to only one
occurrence in another entity.
● A one-to-one relationship rarely exists in practice, but it can.
However, you may consider combining them into one entity.
● For example, an employee has assigned a company car (the
employee will drive only a concrete car of the company).
● Therefore, there is a one-to-one relationship between employee
and company car.
Source: here.
One-to-Many (1:N)
● Is where one occurrence in an entity relates to many
occurrences in another entity.
● For example, taking the employee and department entities
shown on the previous page, an employee works in one
department but a department has many employees.
● Therefore, there is a one-to-many relationship between
department and employee.
Source: here.
Many-to-Many (M:M or M:N or N:M)
● This is where many occurrences in an entity relate to many
occurrences in another entity.
● For example, an employee may work on several projects at the
same time and a project has a team of many employees.
● Therefore, there is a many-to-many relationship between employee
and project.
Source: here.
1.6. Constraints: Optional Relationships.
● A relationship may also be optional. Either end of
the relationship can include zero occurrences as
an option. This is defined by the business rules
of the system being implemented.
● Taking the three examples, the business rules
may be like this:
○ Not all employees have assigned a
company car. A car may not have assigned
an employee.
○ A new department is created with no
employees in it. But an employee MUST
have a department
○ A new project is defined with no employees
working on it. A new employee starts within
the company but he/she couldn’t have any
project assigned.
Source: here.
1.6. Constraints: Optional Relationships.
1 or (1,1) -> 1 and only 1
0,1 or (0,1) -> 0 or 1
N or (0,N) -> 0 or more
1,N or (1,N) -> 1 or more
N+ -> more than 1
(not 0, not 1)
1.6. Constraints: Cardinality or degree of a relationship
(Crow’s Foot).
Source: https://www.cs.dartmouth.edu/~cs61/Resources/ERD_Relationship_Symbols_Quick_Reference.pdf
More info: https://stackoverflow.com/questions/33781451/crows-feet-one-vs-one-and-only-one
(Crow’s Foot).
(Crow’s Foot).
MySQL
Workbench…
BUT THIS IS
RELATIONAL
MODEL!!
1.6. Constraints: Cardinality or
degree of a relationship.
Chen notation
More things about Chen’s notation here.

Check other ways to represent the same:
● http://codex.cs.yale.edu/avi/db-book/db6/slide-dir/PPT-dir/ch7.ppt
● http://www.cs.toronto.edu/~jm/2507S/Notes04/EER.pdf
Let’s work
P01:
● Exercise 1
● Exercise 4
● It represents something that works as an entity and

as a relationship at the same time.
● Represents a relationship with information to be
maintained and/or to be interrelated with other
entities.
PERFORM works as (original idea is here):
● Entity: Because you can keep information

associated with the performance of a
procedure (date, hour, etc.), and because
it is necessary to interrelate it with the
EQUIPMENT entity.
● Relationship: Because it connects
PROCEDURE entities and NURSE
entities. The relationship is as follows:
- PROCEDURE and NURSE exist by
themselves (regardless whether a
procedure is ever performed or not).
- PERFORM only exists as the result
of the partnership between
PROCEDURE and NURSE.
1.- We don’t keep if the nurses use
equipment in a procedure.
We keep equipment used by every
2.- nurse in the performance of a
procedure. Nurses must use
equipment! What does it happens
if a nurse don’t use any
3.- equipment?
We keep equipment used by every

nurse nurse in the performance of a
procedure. But we can have nurses
who didn’t use equipment.
1.- Procedure (id, name)
Nurse (id, name, surname) We don’t keep if the nurses use
Perform (proid*, nurid*, date) equipment in a procedure.
2.- Procedure (id, name) We keep equipment used by every

Nurse (id, name, surname) nurse nurse in the performance of
Perform (proid*, nurid*, equid*,date) a procedure. Nurses must use
Equipment (id, name) equipment! What does it happens
if a nurse don’t use any
equipment?
3.-
Procedure (id, name)
We keep equipment used by every Nurse (id, name, surname)
nurse nurse in the performance of a Perform (proid*, nurid*,date)
procedure. But we can have nurses Equipment (id, name)
who didn’t use equipment. Use (proid*, nurid*, date, equid*)
Source: https://stackoverflow.com/questions/47150141/what-is-the-right-way-to-use-associative-entity?rq=1
Let’s work
P01:
● Exercise 6
1.8. Enhanced E-R Model.
● Appears due to the insufficiency of the E-R model for complex
applications.
● EER stands for Enhanced ER or Extended ER.
● EER Model Concepts:
○ Includes all modeling concepts of basic ER
○ Additional concepts (we’ll only see a simple version):
■ subclasses/superclasses
■ inheritance (attribute and relationship inheritance)
■ specialization/generalization
1.8. Subclasses and superclasses.
● A subclass (subtype) is a subset of occurrences of a

entities of the same type (superclass or supertype)
that need to be represented separately by application
needs.
● All these occurrences have some common
characteristic. E.g., secretary, technician, engineer, etc.,
could be subclasses of the a superclass called
Employee.
superclass
(supertype)
subclasses
(subtypes)
● There may not be an occurrence in any subclass that is
not a member of the superclass, but there may be
occurrences of a superclass that do not belong to any
subclass.
● The hierarchy or relationship between a subclass and
the corresponding superclass is said to be of type is_a
or is_a_type_of.
● Engineer is_a Employee, Technician is_a Employee,
etc.
● Note: An entity that is member of a subclass represents
the same real-world entity as some member of the
superclass:
○ The subclass member is the same entity in a distinct
specific role.
○ An entity cannot exist in the database merely by being a
member of a subclass; it must also be a member of the
superclass.
○ A member of the superclass can be optionally included as a
member of any number of its subclasses.
1.8. Enhanced E-R Model. Inheritance.
SSN will be
the identifier
for the
subentities
● Example:
○ A salaried employee who is also an engineer belongs to the two
subclasses:
■ ENGINEER, and
■ SALARIED_EMPLOYEE
■ (and it belongs also to the superclass!!)
○ It is not necessary that every entity in a superclass be a member of
some subclass
1.8. Enhanced E-R Model. Inheritance.
● Inheritance...
○ a) … of attributes: The members of the subclasses inherit the attributes of
the superclasses to which they belong. E.g.: Given a specialization Employee
in Secretary, Technician, Engineer, the birth_date of a Secretary is the
attribute of the Employee entity who represents him/her. In addition,
subclasses may have their own attributes. E.g.: typing_speed as a Secretary
attribute.
○ b) ... of relations: a member entity inherits all the relations established for its
superclass. In addition, subclasses can establish their own relationships.
E.g.: If EMPLOYEE has a relationship called “WORKING”, it also applies to
the SECRETERY subclass emtity. However, the HOURLY_EMPLOYEE
inherits also the “WORKING” relationship but also have its own relationship
“BELONGS_TO”.
1.8. Enhanced E-R Model. Specialization.
● Specialization is the process of defining a set of subclasses of a

superclasses. Two ways of specialization:
○ Specific Attributes: Certain attributes can only be applied to some
occurrences of the superclass entity set. These will form the subclass.
E.g.: given a specialization Employee in Secretary, Technician,
Engineer, etc., typing_speed as attribute of Secretary.
○ Specific relationships: Sometimes only a subset of the superclass
occurrences participate in certain relationships. E.g.: given a
specialization Employee in Salaried, Hourly, ..., only the occurrences
of Salaried are related to Trade_Union.
1.8. Enhanced E-R Model. Generalization.
● Generalization is the reverse of the specialization process.
● Several classes with common features are generalized into a
superclass:
○ Original classes become its subclasses.
● Example: CAR, TRUCK generalized into VEHICLE.
○ Both CAR and TRUCK become subclasses of the superclass
VEHICLE.
○ We can view CAR and TRUCK as a specialization of VEHICLE.
○ Alternatively, we can view VEHICLE as a generalization of CAR
and TRUCK.
1.8. Enhanced E-R Model. Generalization.
Generalizing
CAR and
TRUCK into
the
superclass
VEHICLE
1.8. Enhanced E-R Model. Relation between
Specialization/generalization and subclass/superclass.
● Specialized class are often called as subclass while

generalized class are called superclass, probably inspired by
object oriented programming.
● For example, Technician is a specialization of Employee or
Technician is a subclass of the superclass Employee. We call
this phenomenon as generalization/specialization. In the
example here Employee is generalized entity class while
Technician and Faculty are specialized class of Employee.
Let’s work
P01:
● Exercise 5
Database Relational Physical

Model (E/R) schema storage
E/R Tables: Complex file
diagrams row names: organization and
attributes index structures.
rows: tuples
DBA DBMS
E-R Model Relational Model

entity relation
relationship relation (when N:M)
associative entity relation (when N:M)
attribute attribute
identifier primary key
1.9. Translation of the E-R
Model to the Relational Model.
Many-to-Many (M:N)
● SUBJECT (code, name, hours)
● STUDENT (NIF, name, birth_date)
● SUB_STU (MARK, ?)
By inheriting as attributes the primary keys:
● SUB_STU (mark, NIF*, code*)
A primary key must be found for the new relation (usually, the
union of the two inherited keys is a minimum key):
● SUB_STU ( NIF*, code*, mark)
Note: If you change the relationship “SUB_STU” for a
associative entity the procedure is just the same.
Many-to-Many (M:N)
● STUDENT (NIF, name, birth_date)
● SUB_STU (MARK, ?)
By inheriting as attributes the primary keys:
● SUB_STU (mark, NIF*, code*)
A primary key must be found for the new relation (usually, the
union of the two inherited keys is a minimum key):
● SUB_STU ( NIF*, code*, date, mark)
Note: If you change the relationship “SUB_STU” for a
associative entity the procedure is just the same.
One-to-Many (1:N)
● DEPARTMENT (code, name, building)
● SUBJECT (code, name, hours, dept_code*)
● Problems:
○ In case the ratio is 0:N causes NULL values in the foreign key.
○ It is not normal for an interrelation 1:N to have attributes, but in the
case that we have attributes in the relationship we must study if the
attributes will become part of the "N" relation or if we need another
table.
One-to-one (1:1)
● BOOKING (locator, model, start_date, end_date)
● CONTRACT (contract_num, model, car, locator*)
● Questions:
1. BOOKING (locator, model, start_date, end_date)
CONTRACT (contract_num, model, car, locator*)
2. BOOKING (locator, model, start_date, end_date,
contract_num, model, car)
NOTE: In option 2 contract_num
is not a foreign key.
MULTIPLE RELATIONSHIPS
AND ASSOCIATIVE ENTITY:
● STUDENT (NIF, name, address,
birth_date)
● PROFESSOR (SSN, name, address)
● ASSESSMENT (sub_code*, NIF*,
prof_SSN*, mark)
Recursive Relationships:
● PERSON (NIF, name)
● MARRIAGE(NIF*, NIF_partner*,
start_date, end_date)
● PERSON (ID, name, ID_mother*,
ID_father*)
○ Can ID_mother/ID_father be
NULL?
● SUBJECT (ID, name, hours)
● PREREQUISITE (ID*, ID_PRE*)
Weak entities:
Multivalued attributes: Create a new
relation that includes the primary key
of the relation and another field with
the attribute (the combination will be
the primary key, sometimes only the
attribute can be PK).
Derived attribute: Delete them (you

can calculate them in a select
EMPLOYEE (SSN, fname, mname, lname,
sentence). birth_date)
EMPLOYEE_EMAIL (SSN*, e-mail)
Composited attributes: Decompose
them.
Specialization (we can have

employees not secretary, technician,
enginner):
EMPLOYEE (SSN, fname, mname,

lname, birth_date, address, job_type)
SECRETARY(SSN*, typing_speed)
TECHNICIAN(SSN*, tgrade)
ENGINEER(SSN*, eng_type)
Generalization (we don’t have

vehicles that aren’t a truck or a car):
CAR (plate_number, price,

max_speed, num_passengers)
TRUCK (plate_number, price,

num_of_axles, tonage)
Specialization (overlapping parts can

be both manufactures or purchased):
PART (PartNo, Description, MFlag,

DrawingNo, ManufactureDate,
BatchNo, PFlag, SupplierName,
ListPrice)
- MFlag is true if the part is

manufactured.
- PFlag is true if the part is
purchased.
See:
● http://tinman.cs.gsu.edu/~raj/4710/sp03/ch9-part1.pdf
● https://utexas.instructure.com/files/35778319/download?download_f
rd=1
1.10. Understanding the E-R model with examples.
● An order has only an item in it…
● Price must be stored in the orders because it can change (but it won’t change
in the orders still done!!)
CUSTOMER (id, name)
ITEM (code, name, price)
ORDER (cust_id*, item_code*, date,

price, qty)
1.10. Understanding the E-R model with examples.
● An order may have many items in it…
● Price must be stored in the orders because it can change (but it won’t change
in the orders still done!!)
CUSTOMER (id, name)
ITEM (code, name, price)
ORDER (num, date, cust_id*)
ORDER-ITEM (order_num*, item_code*, price, qty)

Let’s work
Do all the list P01!!

Sources.
● M. J. Ramos, A. Ramos and F. Montero. Sistemas gestores de bases de
datos (Chapter 1, pag. 18-28). McGrawHill: 1th Edition, 2006.
● Abraham Silberschatz, Henry F. Korth and S. Sudarshan. Database
System Concepts (Chapter 7). McGrawHill: 6th Edition, 2010.
● Apunts de la UIB del professor Miquel Manresa (1996).
● https://www.studytonight.com/dbms/
● https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
● http://comet.lehman.cuny.edu/jung/cmp420758/Chapter4.pdf
● http://webhome.cs.uvic.ca/~thomo/courses/csc370Spring2009/index.html
● http://tinman.cs.gsu.edu/~raj/4710/sp03/ch9-part1.pdf
● https://utexas.instructure.com/files/35778319/download?download_frd=1

Unit 1: Entity-Relationship Model

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 1: Entity-Relationship Model

Uploaded by

Copyright:

Available Formats

Unit 1: Entity-Relationship

● The E-R Model was proposed by Peter Chen in 1976 to

● ER data model describes graphically data addressed to

● An ER model is useful for a DB designer in 3 ways:

1. It can be mapped to relational model.

2. It can be used to communicate the design of the database

3. It’s independent of a concrete DBMS software.

Analysis ER Model Relational Model

Generated with creately.com

● To name the object the singular form is usually used.

○ Entities are like objects in OO programming. Entity sets

● Each instance must be unambiguously identified (there must

Example 1: In the below ER Diagram, ‘Payment’ is the

Copied from: https://www.geeksforgeeks.org/weak-entity-set-in-er-diagrams/

2.- Composite: It is an attribute consisting of multiple fields. Example:

4.- Derived: It is an attribute that is not physically stored in the

● Often, people introduce attributes (=”artificial identifiers”) whose role is to

● There may be instances of CUSTOMER or ITEM that do not have any

● A relationship is defined as the association among several entities.

● A person has a father and a mother, and a person can

● Weak relationships: Relationship which associates several weak entities.

Can’t associate it with the Actor entity

Doesn’t make sense to associate it

However, it’s appropriate to associate

An E-R diagram has certain constraints to which the contents

0,1 or (0,1) -> 0 or 1

N or (0,N) -> 0 or more

1,N or (1,N) -> 1 or more

N+ -> more than 1

More things about Chen’s notation here.

● It represents something that works as an entity and

● Entity: Because you can keep information

We keep equipment used by every

2.- Procedure (id, name) We keep equipment used by every

● A subclass (subtype) is a subset of occurrences of a

● Specialization is the process of defining a set of subclasses of a

● Specialized class are often called as subclass while

Database Relational Physical

E-R Model Relational Model

Derived attribute: Delete them (you

Specialization (we can have

EMPLOYEE (SSN, fname, mname,

Generalization (we don’t have

CAR (plate_number, price,

TRUCK (plate_number, price,

Specialization (overlapping parts can

PART (PartNo, Description, MFlag,

- MFlag is true if the part is

CUSTOMER (id, name)

ITEM (code, name, price)

ORDER (cust_id*, item_code*, date,

CUSTOMER (id, name)

ITEM (code, name, price)

ORDER (num, date, cust_id*)

ORDER-ITEM (order_num*, item_code*, price, qty)

Do all the list P01!!

You might also like

ORDER (cust_id, item_code, date,

ORDER-ITEM (order_num, item_code, price, qty)