Data Modeling - Entity Relationship Diagrams-1.pdf

Data Modeling
(Part – 1)
Presented by:
Mr. S. Christalin Nelson
2/20/2024 Christalin Nelson | Systems Cluster | SOCS 2

At a Glance
• Terminologies & Constraints
• Using High-Level Conceptual Data Models for Database Design
• Sample Database Application
• Entity Types, Entity Sets, Attributes, Keys, and Value Sets
• Relationship Types, Relationship Sets, Roles, and Structural Constraints
• Weak Entity Types
• Refining ER Design for COMPANY Database
• ER Diagrams, Naming Conventions, and Design Issues
• Relationship Types of Degrees Higher than Two
3
2/20/2024
Christalin Nelson | Systems Cluster | SOCS
3 of 59

2/20/2024
Few Terminologies (1/2)
• Domain
– Consists of Name, Data type, Format
– Set of atomic values
• Several Attributes can have the same domain
– Example: Domain named "Phone number" can have attributes home_phone,
office_phone, mob_phone
• Relation – Table name
• Relation Schema (or) Relation Intension
– Includes Table Name, List of Attributes
• Relation State (or) Relation Extension
• Relation instance – Single row (or) tuple
4 of 59

2/20/2024
Few Terminologies (2/2)
• Degree or Arity – No. of Attributes
• Tuples are considered as facts about a relation (or) values satisfying the predicate
• Relations represent
– Facts about entities
– Facts about relationships
• Tuple Ordering
• Attribute Ordering
• Basic Relational model
– Composite and Multivalued attributes are not allowed
– Also called a flat relational model
5 of 59

2/20/2024
Types of Constraints (1/6)
• Inherent model based constraints or Implicit constraints
– Example:
• A relation cannot have duplicate tuples
• Schema-based constraints or Explicit constraints
– Example:
• Domain constraints
• Constraints on NULLs
• Key constraints
• Entity Integrity constraints
• Referential integrity constraints
6 of 59

2/20/2024
• Application-based or semantic constraints or business rules
– Specified and enforced on a relational database or by using general-purpose constraint
specification language
– Example
• The salary of an employee should not exceed salary of employee’s supervisor at DB update
– Mechanisms: Triggers, Assertions
• Data Dependencies
– Example:
• Functional and Multivalued dependencies
– Used with Normalization
7 of 59

2/20/2024
• State constraints (or) Static constraints
– Constraints discussed so far
– Define the constraints that a valid state of DB must satisfy
• Transition constraints (or) Dynamic constraints
– Enforced by application programs or specified using active rules and triggers
– Example:
• Salary of an employee can only increase
8 of 59

2/20/2024
• Domain Constraint
– The value of each attribute must be an atomic value
• Meanings for NULL values
– (1) Not Applicable
• E.g. Person with no college degree would have “null” for “College_degrees” attribute
– (2) Unknown value – Value exists but is missing or unavailable
• E.g. Height attribute of a person
– (3) Unknown value – Does not know if value exists
• E.g Home_phone attribute of a person
9 of 59

2/20/2024
• Key constraints
– Specified on individual relations
– Every table has at least one “Superkey” (subset of attributes)
– “Superkey” can have redundant attributes
– “Key” cannot have redundant attributes
– Any “Superkey” formed from a single attribute is also a “Key”
– Rules
• (1) “Superkey” & “Key” for each tuple should be distinct => “Unique” constraint
• (2) “Key” is a “minimal superkey”
– i.e. Removal of an attribute will compromise “Unique” constraint
– A relation schema may have more than one “key” => termed as “Candidate key”
• One candidate is identified as “Primary key”
10 of 59

2/20/2024
• Entity Integrity constraint
– Specified on individual relations
– No “Primary key” value can be NULL
• Referential integrity constraints
– Specified between two relations
– “Foreign key” in a dependent relation
– Rules
• (1) Attributes of FK should have the same domain as of PK
• (2) Value of FK = value of PK (or) null
– FK can refer to another tuple in its own relation
11 of 59

2/20/2024
Data Modeling using ER Model
• Data Application
– Database, Application program that implements DB Queries and updates
– DB design + Software Engineering (Design, Implementation, Testing of Appln.)
• Entity-Relationship (ER) model
– Popular high-level conceptual data model
– ER diagrams
• Diagrammatic notation associated with the ER model
• Enhanced-ER (EER) model
– Includes concepts such as specialization, generalization, inheritance, and union types
(categories)
• Unified Modeling Language (UML)
– Object modeling
12 of 59

2/20/2024
Using High-Level Conceptual Data Models (1/4)
• Requirements collection and analysis
– DB designers interview prospective DB users to understand and document data
requirements & functional requirements
• Result-1: Concise set of users’ requirements specified in a detailed and complete form
• Result-2: User-defined operations/transactions applied to the DB
– Note:
• Techniques used to specify functional requirements in Software design include DFD,
Sequence diagrams, scenarios
• Functional Analysis
– Identify high-level user queries and operations
13 of 59

Main phases of database design
2/20/2024
14 of 46
14 of 59

2/20/2024
• Conceptual design
– Includes
• Concise description of Data requirements
• Detailed descriptions of entity types, relationships, and constraints
• Use the basic data model operations to specify high-level user queries and operations
• Note: Does not include implementation details
– Result: Conceptual schema of high-level data model
– Used to communicate with non-technical users
– Used as a reference to ensure that all users’ data requirements are met and do not
conflict
15 of 59

2/20/2024
• Logical design (or) data model mapping
– Transform Conceptual schema from High-level data model into Implementation data
model
• Actual implementation of DB using a commercial DBMS with an implementation data
model (like Relational or Object-relational DB model)
– Result: DB schema (Conceptual/Logical Schema in the data model of a specific DBMS)
– Often automated or semi-automated within the DB design tools
• Physical design phase
– Internal storage structures, file organizations, indexes, access paths, and physical
design parameters for the database files are specified
Result: Internal schema
• Application program development
16 of 59

2/20/2024
Sample Database Application
• COMPANY Database – Description
– Employee
• Each employee has a name, social security number, address, salary, sex (gender), and birth date
• Each employee works for one department and can work on several projects that other
departments can control – Track the current no. of hours per week that an employee works on
each project
• Track the direct supervisor of each employee (who is another employee)
• A particular employee manages the department – Track the start date when an employee began
managing the department
– Department
• Each department has a unique name, a unique number and may have several locations
• Can control several projects
– Project
• Each project has a unique name, a unique number, and a single location
– Dependents
• Each dependent has a first name, sex (gender), birth date, and relationship to the employee.
• Track the dependents of each employee for insurance purposes
17 of 59

18
2/20/2024
18 of 59

2/20/2024
Entities and their Attributes (1/5)
• ER model describes data as Entities, Relationships, and Attributes
• Entities
– Things in the real world with independent existence
• Attributes
– Properties that describe an entity
– Types
• Composite vs. Simple (atomic) attributes
• Single-valued vs. Multi-valued attributes
• Stored vs. Derived attributes
• NULL values (Not Applicable & Unknown)
• Complex attributes
19 of 59

2/20/2024
• Composite vs. Simple (atomic) attributes
– Attributes that are not divisible are called simple (or) atomic attributes
– Composite attributes are divided into smaller subparts (basic attributes)
• Useful to model situations in which a user sometimes refers to composite attribute as a
unit but at other times refers specifically to its components
• Value of composite attribute = Concatenation of values of its component simple attributes
– Components of a composite attribute are given within parentheses () & separated with commas
» Example: Address (Street_address(Number, Street, Apartment_number), City, State, Zip)
• Can form a hierarchy (Pic)
20 of 59

2/20/2024
• Single-valued vs. Multi-valued attributes
– Singled-valued attributes have a single value for a particular entity
• Example: “Age” is a single-valued attribute of a person
– Multi-valued attributes have a set of values for the same entity
• May have lower & upper bounds to constrain the number of values allowed for each entity
• Multivalued attributes are mentioned using braces {}
– Example: “color” attribute for a car is {blue, red}
21 of 59

2/20/2024
• Stored vs. Derived attributes
– Values of Stored attributes are given by the user and stored
– Values of Derived attributes should be derived
• Derived from the related attributes of an entity
– Example: “Age” and “Birth_date” attributes of a person
» Age attribute (Derived attribute), Birth_date attribute (Stored attribute)
• Derived from related entities
– Example: Attribute “Number_of_employees” of a DEPARTMENT entity can be derived by
counting the number of employees working for that department
22 of 59

2/20/2024
• Complex attributes
– Composite and multivalued attributes can be nested arbitrarily
– Example: Attribute “Address_phone” of a person who can have >1 residence, and each
residence can have a single address and multiple phones
{
Address_phone (
{Phone(Area_code, Phone_number)},
Address(Street_address(Number, Street, Apartment_number), City, State, Zip)
)
}
Note: Here “Address” and “Phone” are composite attributes
23 of 59

2/20/2024
Entity Types, Entity Sets, Keys, and Value Sets (1/4)
• Entity type
– Collection (or set) of entities that have the same attributes
– Describes Schema (Intension) for the set of entities
24 of 59

2/20/2024
• Key attribute
– Table has one/more attributes whose values are distinct for each entity in entity set
• Some entity types have >1 key attribute
• Composite Key Attribute: Combination of attribute values must be distinct for each entity
– Satisfies the key or uniqueness constraint
– Note:
• There is no concept of a primary key in the ER model
• The primary key will be chosen during mapping to a relational schema (Relational Model)
• Weak Entity Type
– An entity type without even one key attribute
25 of 59

Entity type
Rectangular box enclosing
the entity type name
Attribute names
Enclosed in ovals & are
attached to their entity
type by straight lines
Composite attributes
Attached to their
component attributes by
straight lines
Multivalued attributes
Displayed in double ovals
Key attribute
Its name underlined inside
the oval
2/20/2024
26 of 59

2/20/2024
• Value sets (or domain of values) of Attributes
– Set of values that may be assigned to that attribute for each entity
– Note:
• Value sets are not displayed in ER diagrams
• Specified using the basic data types available in most programming languages
– An attribute (A) of entity set (E) whose value set is V can be defined as a function from E to the
power set P(V) of V
• A : E → P(V)
– Value of attribute(A) for entity (e) is A(e)
• NULL value is represented by empty set
• For single-valued attributes, A(e) is restricted to a singleton set for each entity(e) in E
• There is no restriction on multivalued attributes
• For a composite attribute (A), the value set V is the power set of the Cartesian product of P(V1),
P(V2), ..., P(Vn), where V1, V2, ..., Vn are the value sets of the simple component attributes that
form A:
– V = P (P(V1) × P(V2) × ... × P(Vn))
27 of 59

2/20/2024
Sample Database Application
• COMPANY Database – Description
– Employee
• Each employee has a name, social security number, address, salary, sex (gender), and birth date
• Each employee works for one department and can work on several projects that other
departments can control – Track the current no. of hours per week that an employee works on
each project
• Track the direct supervisor of each employee (who is another employee)
• A particular employee manages the department – Track the start date when an employee began
managing the department
– Department
• Each department has a unique name, a unique number and may have several locations
• Can control several projects
– Project
• Each project has a unique name, a unique number, and a single location
– Dependents
• Each dependent has a first name, sex (gender), birth date, and relationship to the employee.
• Track the dependents of each employee for insurance purposes
28 of 59

2/20/2024
Initial Conceptual Design of COMPANY Database
29 of 59

2/20/2024
Relationship Types, Relationship Sets (1/3)
• Relationship
– An attribute of one entity type refers to another entity type – represent references as
relationships, and not as attributes
• Relationship Types
– As with Entity types & Entity sets, a Relationship type and its corresponding
Relationship set are referred to by the same name, R
• A relationship type(R) among ‘n’ entity types E1, E2, ..., En defines a set of associations (or) a
relationship set among entities from these entity types
• Each relationship instance (ri) in R is an association of entities, where the association
includes exactly one entity from each participating entity type
– Each of the entity types E1, E 2, ..., En is said to participate in the relationship type R; similarly,
each of the individual entities e1, e2, ..., en is said to participate in the relationship instance ri =
(e1, e2, ..., en).
30 of 59

2/20/2024
Relationship Types, Relationship Sets (2/3)
• Example:
– Consider a relationship type WORKS_FOR between two entity types EMPLOYEE and
DEPARTMENT, which associates each employee with the department for which the
employee works in the corresponding entity set
• Each relationship instance in the relationship set WORKS_FOR associates one EMPLOYEE
entity and one DEPARTMENT entity
31 of 59

2/20/2024
32 of 59

2/20/2024
Relationship Degree
• Degree of a relationship type
– Number of participating
entity types
– Examples
• WORKS_FOR relationship is
of degree two (Binary)
• SUPPLY relationship is of
degree three (Ternary)
33 of 59

2/20/2024
Relationship as Attributes
• Binary relationship type can be thought of in terms of attributes
– Consider WORKS_FOR relationship type
• The attribute called ‘Department’ of EMPLOYEE entity type, where the value of
‘Department’ for each EMPLOYEE entity is a reference to the DEPARTMENT entity for which
that employee works.
– The concept of representing relationship types as attributes is used in a class of data
models called functional data models
• In object DBs, relationships can be represented by reference attributes, either in one
direction or in both directions as inverses
• In relational DBs, “foreign keys” are a type of reference attribute used to represent
relationships
34 of 59

2/20/2024
Role Names and Recursive Relationships (1/2)
• Role names
– Role name signifies role that a participating entity plays in each relationship instance
– Example:
• In WORKS_FOR relationship type, EMPLOYEE plays the role of employee/worker and
DEPARTMENT plays the role of department/employer
• Recursive relationships
– The same entity type participates in >1 relationship types in different roles
– The role name should be specified
– Example:
• SUPERVISION relationship type relates an employee to a supervisor, where both employee
and supervisor entities are members of the same EMPLOYEE entity set. Here EMPLOYEE
entity type participates twice in SUPERVISION in the role of supervisor & role of supervisee
35 of 59

36
2/20/2024
36 of 59

2/20/2024
Binary Relationship Constraints (1/5)
• The constraints limit the possible combinations of entities that may participate in
the corresponding relationship set
• Types
– Cardinality ratio
– Participation constraint
• Cardinality ratio
– Specifies the maximum no. of relationship instances that the entity can participate in
– Possible cardinality ratios for binary relationship types are 1:1, 1:N, N:1, and M:N
– Example: WORKS_FOR binary relationship type, DEPARTMENT:EMPLOYEE is of
cardinality ratio 1:N
• Each department can be related to (employs) any number of employees, but an employee
can be related to (work for) only one department
37 of 59

2/20/2024
38 of 59

2/20/2024
39 of 59

2/20/2024
• Participation constraint
– Specifies whether the existence of an entity depends on it being related to another
entity via relationship type
– Specifies the minimum no. of relationship instances that each entity can participate in
(sometimes called minimum cardinality constraint)
– Types: Total & Partial
• Examples:
– A company policy states that “every employee must work for a department”. An employee entity
can exist only if it participates in at least one WORKS_FOR relationship instance. This is called
Total Participation (or) Existence Dependency.
– Every employee is not expected to manage a department. The participation of EMPLOYEE in the
MANAGES relationship type is Partial Participation.
40 of 59

2/20/2024
• Structural Constraints
– Cardinality ratio and Participation Constraints are together considered as structural
constraints of a relationship type
• ER Notation
– Cardinality ratios: Display 1, M, and N on the diamonds
– Total participation: Double line connecting participating entity type to the relationship
– Partial participation: Single line
• Note:
– Either specify no minimum (partial participation) or a minimum of one (total participation)
– Specify a specific minimum number on participation in the relationship, such as 4 or 5
41 of 59

2/20/2024
Attributes of Relationship Types (1/2)
• Relationship types can also have attributes, similar to those of entity types.
– Example
• ‘Hours’ attribute for the WORK_ON relationship type to track the number of hours per
week that an employee works on a particular project
• ‘Start_date’ attribute for the MANAGES relationship type to track the date on which a
manager started managing a department via an attribute
42 of 59

2/20/2024
Attributes of Relationship Types (2/2)
• Migration of Attribute of Relation Type => Attribute of Entity Type
– Attributes of 1:1 relationship types => can be migrated to any one entity type
• Example: ‘Start_date’ attribute for MANAGES relationship can be an attribute of either
EMPLOYEE or DEPARTMENT, although conceptually it belongs to MANAGES
– Attributes of 1:N relationship types => can be migrated only to entity type on the N-
side of the relationship
• Example: If WORKS_FOR relationship has an attribute ‘Start_date’ that indicates when an
employee started working for a department, this attribute can be included as an attribute
of EMPLOYEE
– For M:N relationship types => No Migration
• Example: The value of ‘Hours’ attribute of the M:N relationship WORKS_ON is determined
by an employee-project combination and not separately by either entity
43 of 59

2/20/2024
Weak Entity Type (1/4)
• Entity Type that do not have key attributes of their own
– vs. Strong Entity Type
• Identifying relationship
– Relates weak entity type (Child or subordinate entity type) to Owner (Parent or
Dominant) entity type
• Entities of a weak entity type are identified by being related to specific entities from owner
– Always has a total participation constraint or existence dependency
• Note: Not every existence dependency results in a weak entity type
– Example: DRIVER_LICENSE entity cannot exist unless it is related to a PERSON entity, even
though it has its own key (License_number). Hence is not a weak entity.
44 of 59

2/20/2024
• Example
– Entity type DEPENDENT is related to EMPLOYEE via a 1:N relationship. Each employee
entity is said to OWN the dependent entities that are related to it.
• Note: Two dependents of two distinct employees may, by chance, have the same values for
Name, Birth_date, Sex, and Relationship, but they are still distinct entities. They are
identified as distinct entities ONLY after determining the employee entity to which each
dependent is related.
• Partial key or Discriminator
– Attribute that uniquely identifies weak entities that are related to same owner entity
– Example: The attribute ‘Name’ of DEPENDENT is the partial key
45 of 59

2/20/2024
• Notation used in ER diagrams
– Weak entity type and it’s identifying relationship: Surround their boxes and diamonds
with double lines
– Partial key attribute: underlined with a dashed or dotted line
• Weak entity types can also be represented as complex (composite, multivalued)
attributes
– Example: Specify a multivalued attribute ‘Dependents’ for EMPLOYEE, which is a
composite attribute with component attributes Name, Birth_date, Sex, and
Relationship
46 of 59

2/20/2024
• Any number of levels of weak entity types can be defined
– i.e. An owner entity type may itself be a weak entity type
• A weak entity type may have >1 identifying entity type
• A weak entity type may have an identifying relationship type of degree >2
47 of 59

2/20/2024
Refining ER Design for COMPANY Database
• Change attributes that represent relationships into relationship types
• Determine cardinality ratio and participation constraint of each relationship type
Relation Type Relation between
Cardinality
Ratio
Participation Constraint Attribute
WORKS_FOR DEPARTMENT and EMPLOYEE 1:N
EMPLOYEE total
participation
DEPARTMENT total
participation
Nil
MANAGES EMPLOYEE and DEPARTMENT 1:1
EMPLOYEE partial
participation
DEPARTMENT total
participation
Start_date
CONTROLS DEPARTMENT and PROJECT 1:N
DEPARTMENT partial
partcipation
PROJECT total
participation
Nil
SUPERVISION
EMPLOYEE (supervisor role) and
EMPLOYEE (supervisee role)
1:N
EMPLOYEE (supervisor
role) partial participation
EMPLOYEE (supervisee
role) partial
participation
Nil
WORKS_ON EMPLOYEE and PROJECT M:N
EMPLOYEE total
participation
PROJECT total
participation
Hours
DEPENDENTS_OF EMPLOYEE and DEPENDENT 1:N
EMPLOYEE partial
participation
DEPENDENT total
participation
Nil
48 of 59

2/20/2024
Proper naming of Schema Constructs
• Choose names that convey meanings attached to different constructs in the
schema
• Entity types: Singular names rather than plural ones
• Entity type names: Nouns, uppercase letters
• Attribute names: Nouns, Initial letter is capitalized
• Role names: lowercase letters
• Relationship type names: Verbs, uppercase letters
– Choose binary relationship names to make the ER diagram readable from left to right
and from top to bottom
• This issue arises because each binary relationship can be described starting from either of
the two participating entity types
49 of 59

2/20/2024
Identifying
50 of 59

2/20/2024
Alternative Notations for ER Diagrams (1/2)
• Specify structural constraints on relationships
– Replace cardinality ratio and participation constraints. Associate a pair of integer
numbers (min, max) with each participation of an entity type E in a relationship type
R, where 0 ≤ min ≤ max and max ≥ 1
– Note: For Participation constraints
• Partial participation (min = 0)
• Total participation (min > 0)
51 of 59

52
2/20/2024
52 of 59

2/20/2024
Choosing between Binary & Higher-Degree Relationships (1/5)
• A relationship type(R) of degree(n) will have n edges in an ER diagram, one
connecting R to each participating entity type
53 of 59

2/20/2024
• Three binary relationships cannot replace a ternary relationship, they may do so
under certain additional constraints
– Example: Existence of three relationship instances (s, p), ( j, p), and (s, j) in
CAN_SUPPLY, USES, and SUPPLIES, respectively, does not necessarily imply that an
instance (s, j, p) exists in ternary relationship SUPPLY
54 of 59

2/20/2024
• Some database design tools permit only binary relationships
– Ternary relationships are represented as weak entity types with no partial key and
with three identifying relationships
• Example: The weak entity type SUPPLY is identified by a combination of its three owner
entities from SUPPLIER, PART, and PROJECT
55 of 59

2/20/2024
• A weak entity type with a ternary (or n-ary) identifying relationship type
– The weak entity type can have a partial key and several owner entity types
56 of 59

2/20/2024
• Represent ternary relationship as a regular entity type by introducing an artificial
or surrogate key
– Example: Ternary relationship SUPPLY is converted to a regular entity type by using
artificial Key attribute Supply_id. Three binary N:1 relationships relate SUPPLY to the
three participating entity types.
57 of 59

2/20/2024
Constraints on Ternary (or Higher-Degree) Relationships
• Two Notations to be used for fully specifying structural constraints on higher-degree
relationships
– First notation is based on the cardinality ratio notation of binary relationships
• If among the three cardinalities, one participation has cardinality specified as 1, then the key
will be the combination of the other two participants
– Example: Relationship set of SUPPLY is a set of relationship instances (s, j, p), where s - SUPPLIER, j -
PROJECT, and p - PART. Suppose that the constraint exists that for a particular project-part
combination only one supplier will be used, then, any relationship instance (s, j, p) is uniquely
identified in relationship set by its (j, p) combination, which makes (j, p) a key for the relationship set
• If all three cardinalities are M or N, then the key will be the combination of all three participants
– Second notation is based on (min, max) notation for binary relationships
• This constraint have no bearing on determining the key of a higher-degree relationship
• Specifies a constraint that places restrictions on how many relationship instances each entity
can participate in
58 of 59

2/20/2024 Christalin Nelson | Systems Cluster | SOCS 59

Data Modeling - Entity Relationship Diagrams-1.pdf

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Data Modeling - Entity Relationship Diagrams-1.pdf

Similar to Data Modeling - Entity Relationship Diagrams-1.pdf (20)

More from Christalin Nelson

More from Christalin Nelson (16)

Recently uploaded

Recently uploaded (20)

Data Modeling - Entity Relationship Diagrams-1.pdf