Data Modeling Using the EntityRelationship ER Data Model

1
Data Modeling Using the
Entity-Relationship (ER) Data Model

• Phases of Database Design
• Conceptual Design
• E-R model

Steps in DB Design
Requirements Definition
Data-oriented approach - because data are more
stable than the functions (or processes) in an
organization.
Develop ER Model
Normalized Tables
Design Application
2
Database Design and Conceptual Data Model

• Analogous to analysis phase of software
  development
• Requirement Collection and Analysis
• - Designers interview database users to
  understand and document data requirements.
• Functional Requirements
• - User defined operations to be applied on the
  database

3
Database Design and Conceptual Data Model (contd.)

• Conceptual Design
• -Conceptual schema a permanent description of
  database specifications.
• - Capture the semantics of the data description
  of data, constraints, relationships
• - No storage details needed

4
HISTORY OF DATA MODELS

• Description in high-level model
• - Close to the user' view of mini-world
• - Abstract concepts
• - Means of communication between the
  non-technical users and the developer
• - Allows user to influence design and is
  independent of any particular DBMS.
• Entity Relationship Data Model
• - developed by Peter Chen (1983)
• - basis for ANSI IRDS (Dolk Kirsch, 1987
  Winkler 1989)

5
Example COMPANY Database

• Requirements for the COMPANY Database
• - The company is organized into DEPARTMENTs. Each
  department has a name, number, and an employee
  who manages the department. We keep track of
  the start date of the department manager. A
  department may have several locations.
• -Each department controls a number of PROJECTs.
  Each project has a name, number, and is located
  at a single location.

6
Example COMPANY Database
(contd.)
- We store each EMPLOYEE's social security
number, address, salary, sex, and
birth date. Each employee works for one
department but may work on several projects. We
keep track of the number of hours per week that
an employee currently works on each project. We
also keep track of the direct supervisor of each
employee.
7
Example COMPANY Database
(contd.)
- Each employee may have a number of DEPENDENTs.
For each dependent, we keep their name, sex,
birth date, and relationship to the employee.
8
ER Model Concepts (Popular Conceptual model)

• Entities
• Specific objects or things in the mini-world
  that are represented in the database
  for example the EMPLOYEE John Smith, the Research
  DEPARTMENT, the ProductX PROJECT
• Attributes
• Properties used to describe an entity (or
  relationship) for example an EMPLOYEE entity
  may have a Name, SSN, Address, Sex, BirthDate.

9
ER Model Concepts (contd.)

• A specific entity will have a value for each of
  its attributes for example a specific employee
  entity may have Name'John Smith',
  SSN'123456789', Address'731 Fondren, Houston,
  TX', Sex'M', BirthDate'09-JAN-55'.
• Domain
• Possible values for an attribute for example M
  and F for the Sex attribute.

10
ER Model Concepts (contd.)

• Types of Attributes
• - Simple Each entity has a single atomic value
  for the attribute for example SSN or
  Sex. (i.e., single-valued)
• - Composite The attribute may be composed of
  several components for example Address(Apt,
  House, Street, City, State,
  ZipCode, Country) or Name(FirstName,
  MiddleName, LastName). Composition may form a
  hierarchy where some components are
  themselves composite.

11
ER Model Concepts (contd.)

• Multi-valued An entity may have multiple
  values for that attribute for example Color of
  a CAR or PreviousDegrees of a STUDENT. Denoted as
  Color or PreviousDegrees
• In general, composite and multi-valued attributes
  may be nested arbitrarily to any
  number of levels although this is rare.
  For example, PreviousDegrees of a STUDENT is a
  composite multi-valued attribute denoted by
  PreviousDegrees(College, Year, Degree,
  Field).

12
Entity Types and Key Attributes
- Entities with the same basic attributes are
grouped or typed into an entity type.
For example, the EMPLOYEE entity type or the
PROJECT entity type. - An attribute of an entity
type for which each entity must have a unique
value is called a key attribute of the entity
type. For example SSN of EMPLOYEE.
13
Entity Types and Key Attributes
(contd.)

• A key attribute may be composite. For example,
  VehicleRegistrationNumber is a key of the CAR
  entity type with components
  (Number, State).
• An entity type may have more than one key.
  for example, the CAR
  entity type may have two keys VehicleIdentificati
  onNumber and VehicleRegistrationNumber(Number,
  State).

14
Relationships and Relationship Types

• - A relationship relates two or more distinct
  entities with a specific meaning
  for example, EMPLOYEE John Smith works on
  the ProductX PROJECT or EMPLOYEE
  Franklin Wong manages the Research DEPARTMENT.
• - Relationships of the same type are grouped or
  typed into a relationship type.
  For example, the WORKS_ON
  relationship type in which EMPLOYEEs and PROJECTs
  participate, or the MANAGES
  relationship type in which
  EMPLOYEEs and DEPARTMENTs participate.

15
Relationships and Relationship
Types (contd.)

• The degree of a relationship type is the number
  of participating entity types. Both
  MANAGES and WORKS_ON are binary
  relationships.
• - More than one relationship type can exist with
  the same participating
  entity types for example, MANAGES
  and WORKS_FOR are distinct relationships between
  EMPLOYEE and DEPARTMENT participate.

16
Structural Constraints and Roles

• A relationship can relate two entities of the
  same entity type for example, a
  SUPERVISION relationship type relates
  one EMPLOYEE (in the role of supervisee ) to
  another EMPLOYEE (in the role of
  supervisor ). This is called a
  recursive relationship type
• A relationship type can have attributes for
  example, HoursPerWeek of WORKS_ON its value for
  each relationship instance
  describes the number of hours
  per week that an EMPLOYEE works on
  a PROJECT.

17
Structural Constraints and Roles (contd.)

• Structural constraints on relationships
• Cardinality ratio (of a binary relationship)
• 11, 1N, N1, or MN.
• Participation constraint
• (on each participating entity type) total
  (called existence dependency ) or partial.

18
Structural Constraints and Roles (contd.)

• Alternative (min, max) notation for relationship
  structural constraints
• - Specified on each participation of an entity
  type E in a
  relationship type R.
• - Specifies that each entity e in E participates
  in at least min and at most max relationship
  instances in R.
• - Default(no constraint) min0, maxn.
• - Must have minltmax, mingt0, maxgt1.
• - Derived from the mini-world constraints.

19
Structural Constraints and Roles (contd.)

• Examples
• A department has exactly one manager and an
  employee can manage at most one
  department.
• - Specify (1,1) for participation of EMPLOYEE
  in MANAGES
• - Specify (0,1) for participation of EMPLOYEE
  in MANAGES

20
Structural Constraints and Roles (contd.)
(b) An employee can work for exactly one
department but a department
can have any number of employees. - Specify
(1,1) for participation of EMPLOYEE in
WORKS_FOR - Specify (0,n) for participation of
DEPARTMENT in WORKS_FOR
21
Weak Entity Types

• An entity type that does not have a key attribute
• A weak entity type must participate in an
  identifying relationship type with an owner or
  identifying entity type
• Entities are identified by the combination of
• - A partial key of the weak entity type
• - The particular entity they are related to
  in the identifying entity
  type

22
Weak Entity Types (contd.)
Example Suppose that a DEPENDENT entity is
identified by the dependent's first name and
birthdate, and the specific EMPLOYEE that the
dependent is related to. DEPENDENT
is a weak entity type with EMPLOYEE as its
identifying entity type via the identifying
relationship type DEPENDENT_OF
23
Relationships of Higher Degree

• Relationship types of degree 2 are called
  binary
• Relationship types of degree 3 are called
  ternary and of degree n are called
  n-ary
• - In general, an n-ary relationship is not
  equivalent to n binary
  relationships

24
Enhanced Entity-Relationship Model (Concepts/Featu
res)

• Subclass/subtype, superclass/supertype
• Specialization -- define subclasses
• Generalization -- define superclass
• Constraints on Specialization
• Disjointness (Disjoint or Overlap)
• Completeness (Total or Partial Specialization)
• Inheritance.
• Hierarchies and Lattices
• Union Types (Categories)

25
Enhanced ER Model (EER)

• EER Model ER Model Extensions
• Extensions
• - Subclass (Specialization)
• - Superclass (Generalization)
• - Category
• - Attribute and Relation Inheritance

26
Subclass/Superclass

• Subclass Entities of an Entity type sharing a
  set of attribute which are grouped
  together
• Superclass The parent entity type from which
  subclasses are formed
• Class/Subclass relationship Relationship between
  a superclass and one of the subclasses
• Specialization The process of forming subclasses
  from a superclass

27
Subclass/Superclass (contd.)

• Type Inheritance Member of subclass possessing
  all attributes and relationships of a member of
  superclass
• Local Attributes Attributes that apply only to
  members of a subclass (a.k.a. specific attribute)
• Local Relationships Relationships applicable
  only to members of a subclass(a.k.a. specific
  relationships)
• Generalization Process of forming a supercalss
  from subclasses. (Functionally, inverse of
  specialization)

28
Specialization/Gerneralization Characteristics

• Several Specializations could be defined on the
  same entity type (Superclass)
• Specialization with single subclass is also
  permitted
• Predicate-defined subclass Specialization
  specified by a condition on the value some
  attribute of superclass. (a.k.a.
  condition-defined)
• Defining predicate Condition satisfied by all
  members of a predicate-defined subclass

29
Specialization/Gerneralization Characteristics
(contd.)

• Attribute-defined specialization All subclasses
  having membership condition on the same attribute
  of the superclass
• Defining Attributes No condition exists for
  determing membership in the subclass

30
Specialization/Generalization Constriaints

• Disjointness constraint Subclasses of the
  specialization must be disjoint (an entity is a
  member of at most one subclass)
• - Overlapping Subclasses not constrained to be
  disjoint
• Completeness Constraint
• - Total Every entity in superclass must be a
  member of some subclass (e.g.\HOURLY\_EMPLOYEE,
  SALARIED\_EMPLOYEE\

31
Specialization/Generalization Constriaints
(contd.)

• - Partial An entity in superclass may not be a
  member of any subclass
• Disjointness and Completeness are independent.
  (leads to 4 possible constraints on
  specialization)
• - Disjoint, Total
• - Disjoint, Partial
• - Overlapping, Total
• - Overlapping, Partial

32
Specialization Hierarchies and Lattices

• Subclass may have further subclasses, and so on.
• Specialization Hierarchy Every subclass
  participates in only one
  class/subclass relationship
• Specialization Lattice A subclass can
  participate in more than one
  class/subclass relationship
• Leaf Node A class that has no subclass

33
Specialization Hierarchies and Lattices (contd
.)

• Shared Subclass A subclass with more than one
  superclass
• Multiple Inheritance A shared subclass
  inheriting attributes and relationships from
  multiple (super) classes

34
Union Type/Categories

• Uniontype (Category) Subclass with
  class/subclass relationship with more than one
  superclass of different entity types
• Category is a subset of the union of its
  superclass
• An entity in Category is a member of only one of
  its superclass
• Category types Total or Partial

35
Coincidences between the ER Model and the Surface
Structure of English(P. Chen, 1983)
Symbol
ER Meaning
English Equivalent
Entity
Noun
Verb
Relationship
Attribute of Entity Relationship
Adjective
Adverb