Conceptual Modeling of Data

Prof. S. Mehrotra
Information and Computer Science
Department
University of California at Irvine
Outline
 Database design process
 Entity/Relationship Model
 Entity sets
 Relationship sets
 Constraints on entity sets
 Constraints on relationship sets
 Weak entity sets
 Superclass/subclass relationships
 Aggregation
 Good Design Principles
 Examples
Conceptual Database Design
ODL C++
C++ based
Embedding
OODBMSs
ODL Smalltalk
Embedding
Abstract ODL
Smalltalk based
OODBMSs
Relations

E/R
Relational DBMSs
Ideas and
information

The design process depends upon the target DBMS

•E/R and ODL are popular models used for conceptual design
•ODL -- Object Definition Language is an emerging standard for OODBMSs
Database Design Process
miniworld
Requirement Analysis

functional requirements Data requirements

functional analysis conceptual design

conceptual schema

application design logical design

logical schema
high level specs (in DBMS model)

transaction implementation physical design

application programs Physical schema

Functional Design Database Design

Database Design Tools
 Help partially automate the design cycle.
 Graphical interface to specify conceptual schemas.
 Partially automated techniques to map to logical (DBMS
dependent) model.
 Features of a good design tool:
 Iterative: errors /shortcomings of original design found later can be
corrected without full restart.
 Interactive: any design choices made by system during design should
be based on interaction with designer.
 Feedback: a designer’s change made at logical and/or physical levels
should be automatically translated to changes at higher levels.
 Example Design tools: ERwin by LogicWorks.
 Database design tools integrated into CASE tools and
supported by most modern DBMSs.
Requirements of a Conceptual
Data Model
 Expressiveness: should be expressive enough to
allow modeling of different types of relationships,
objects and constraints of the miniworld.
 Simplicity: non-specialists should be able to
understand
 Minimality: few basic powerful concepts that are non-
overlapping
 Diagrammatic Representation: to ease interpretation
 Formality: There should be no ambiguity in the
specification
Overview of Entity/Relationship
(E/R) Model
 Entities
 Relationships
 Roles of entities in a relationship
 Constraints on entities:
 domain constraints
 key constraints
 Constraints on relationships
 Cardinality Constraints (mapping constraints in SKS)
 Participation Constraints (existence dependencies in SKS)
 Weak Entity Sets
 Multiway relationships
 Subclass/superclass Relationships
 Aggregation
Entiities and Entity Sets
 Entities
 nouns, ‘things’ in the world.
 E.g., students, courses, employees, departments, flights,
patients, ...
 Attributes
 properties of entities.
 E.g., course name, deptname, departure time, age,
room#, ...
 Entity set -- a set of entities that have the same
attributes.
 In OO terminology, an entity set is similar to a class, and
an entity similar to an instance
Attributes
 single-valued vrs multi-valued:
 color of car could be multi-valued
 salary of employee is single-valued
 atomic vrs composite:
 age of a person is atomic
 address of a person could be composite
 stored vrs derived:
 derived attributes are those that can be derived from
other attributes or entities, e.g., age can be derived
from date of birth.
 All other attributes are stored attributes
 Relationships
 Relationship:
 association between multiple entities
 Relationship Set:
 set if relationships over the same entity sets
 Binary, Ternary, 4-nary, … relationship sets
Cust-Account
Relationship set account
customer

259 10000
sam 62900 main austin

305 20000

pat 62901 north urbana 245 2400

364 200000
Visualizing ER Relationships as a
Table

Customer Account Row in the table

John 1001 represents the pair of
Megan 1001 entities participating
in the relationship
Megan 2001

Relationship Set Corresponding to the Relationship Cust-Account

ER Diagram -- graphical
representation of ER schema
cust name
street
balance
acct number
ssno city

customer custacct account

opening date

•Entity set -- rectangles; attributes -- ellipses; dashed ellipse -- derived

attribute; double ellipse -- multivalued attribute; relationship set --
diamonds; lines connect the respective relationship set with entity sets;
•Relationship sets may have 1 or many attributes associated with them --
known as relationship attributes.
Roles in a Relationship
 The function that an entity plays in a
relationship is called its role
 Roles are normally not explicitly specified
unless the meaning of the relationship needs
clarification
 Roles needed when entity set is related to
itself via a relationship.
manager
employee works for

worker
Constraints on Entity Sets
 Key Constraint:
 With each entity set a notion of a key can be associated.
 A key is a set of attributes that uniquely identify an entity in entity
set.
 Examples:
 designer may specify that {ssno} is a key for a entity set customer
entity with attributes {ssno, accountno, balance, name, address}
 designer may specify that {accountno} is also a key , that is, no joint
accounts are permitted.
 Denoted in ER diagram by underlining the attributes that form a key
 multiple keys may exist in which case one chosen as primary key
and underlined. Other keys called secondary keys either not
indicated or listed in a side comment attached to the diagram.
Constraints on Entity Sets (cont.)

 Domain constraint:
 with each simple attribute a domain is associated. The
value of the attribute for each entity is constrained to be in
the domain.
Cardinality Constraints on
Relationship Sets
 Consider binary relationship set R between entity sets A
and B
 One to one: an entity in A is associated with at most
one entity in B, and an entity in B is associated with
atmost one entity in A.
 an employee has only one spouse in a married-to relationship.
 Many to One: An entity in A is associated with at most
one entity in B, an entity in B is associated with many
entities in A.
 an employee works in a single department but a department
consists of many employees.
Cardinality Constraints on
Relationship Sets (cont.)

 Many to Many: An entity in A is associated with many

entities in B, and an entity in B is associated with
many entities in A.
 A customer may have many bank accounts. Accounts may
be joint between multiple customers.
Multiplicity of Relationships

Many-to-many Many-to-one One-to-one

multiplicity of relationship in ER diagram represented by an

arrow pointing to “one”
Many to Many Relationship

customer custacct account

opening date

Customer Account Start Date Customer Account Start Date

John 1001 Jan 20th 1999 John 1001 Jan 20th 1999
Megan 1001 March 16th 1999 Megan 1001 March 16th 1999
Megan 2001 Feb 18th 1994
legal legal

 Multiple customers can share an account

 Many accounts may have one owner
Many to One Relationship

customer custacct account

opening date

Customer Account Start Date Customer Account Start Date

John 1001 Jan 20th 1999 John 1001 Jan 20th 1999
Megan 1001 March 16th 1999 Megan 1001 March 16th 1999
Megan 2001 Feb 18th 1994

Illegal legal

 Multiple customers can share an account but one

customer can have only one account.
Relationship Attribute in a Many
to One Relationship

customer custacct account

opening date

 In a Many-One relationship, relationship attributes

can be repositioned to the entity set on the many
side.

customer custacct account

opening date
One to One Relationship

customer custacct account

opening date
Illegal
Customer Account Start Date
 1 customer can have 1 John 1001 Jan 20th 1999
account. Megan 1001 March 16th 1999

 One account can be owned Illegal

by 1 customer Customer Account Start Date
Megan 1001 March 16th 1999
 relationship attributes can Megan 2001 Feb 18th 1994
be shifted to either of the Legal
entity sets Customer Account Start Date
Megan 1001 March 16th 1999
John 2001 Feb 18th 1994
Participation Constraints
 Participation of an entity set A in the
relationship set R1 can be total
 Each entity in entity set A is constrained to be
related to other entities via relationship R1.
 Examples
 participation of entity set employee in the
relationship belongs-to with the entity set
department may be total.
 Each employee must belong to at least one
department.
Participation Constraints
 total participation is also called existential
dependency
 If an entity does not have a total participation
in a relationship, it is said to have a partial
participation
 In ER diagram, total participation represented
using a double line between the relationship
and entity set that totally participates in the
relationship
Example
Ss# name amount loandid

N N
customer borrower loans

N
N
Belongs-to

1
N
Customer-of branch

•Keys: ss#, loanid, branchid branchid location

•Cardinality constraint: each loan belongs to a single branch

•Participation constraints:
•Each customer must be a customer of atleast one branch
•Each loan must belong to some branch
Weak Entity Sets
 Entity sets that do not have sufficient attributes to form a key are called
weak entity sets.
 A weak entity set existentially depend upon (one or more) strong entity
sets via a one-to-many relationship from whom they derive their key
 A weak entity set may have a discriminator (or a partial key) that
distinguish between weak entities related to the same strong entity
 key of weak entity set = Key of owner entity set(s) + discriminator
Weak Entity Sets (cont.)
cust name
street
acct number balance
ssno
city

customer custacct account

opening date
log

 Transaction is a weak entity

set related to accounts via log transaction
relationship. Trans#

 Trans# distinguish different

transactions on same account
A Chain of Weak Entity Sets
city Located in state

 Names of state are unique and form the key.

 Names of city are unique only within a state
Located in

(e.g., 24 Springfield’s within the 50 states).

 Names of streets are unique within a city.
street
Multiple cities could have streets with the
same name.

Example illustrating that a weak entity set might itself

participate as owner in an identifying relationship with
another weak entity set.
A Weak Entity Set with Multiple
Owner Entity Sets
title
movie
review

reviewer
rating
name
 Reviewers review movie and assign a rating -- thumb
up/thumbs down.
 Review is a weak entity set whose owner sets correspond
to both the movie and the reviewer entity sets.
 Key for the review entity set = key of movie + key of
reviewer
 Multiway Relationships
 Usually binary relationships (connecting two E.S.) suffice.
 However, there are some cases where three or more E.S. must be
connected by one relationship.
 Similar to binary relationship, cardinality and participation
constraints defined over multiway relationships
Customer Account Branch
branchName John 1001 Irvine
Megan 1001 LA
key
Megan 2001 Tokyo
key
branch
social- acct#
security CAB Relationship Set

customer CAB account

balance
 Cardinality Constraint over
Multiway Relationships
branchName
key

key branch Customer Account branch

social- John 1001 Irvine
security acct#
Megan 1001 Dallas
Megan 1002 Tokyo
customer CAB account Megan 1001 Tokyo
Illegal: Megan has account
Many to Many to 1 relationship balance 1001 at 2 branches

 Interpretation: Customer Account branch

John 1001 Irvine
 Each pair of customer and Megan 1001 Dallas
account determine the branch Megan 1002 Tokyo
(that is, have a single branch Megan 1003 Tokyo
related to them).
Legal
Cardinality Constraint over
Multiway Relationships
branchName
key

key branch
social- Customer Account branch
security acct#
John 1001 Irvine
CAB account Megan 1001 Dallas
customer
Megan 1002 Tokyo
Megan 1003 Tokyo
Many to1 to 1 relationship balance
Illegal: Megan has 2 accounts
in Tokyo Branch
 Interpretation:
Customer Account branch
 Each (customer, branch) related John 1001 Irvine
to a single account Megan 1001 Dallas
 Each (customer, account) pair Megan 1002 Tokyo
related to a single branch John 1002 Tokyo
Legal
Cardinality Constraint over
Multiway Relationships
branchName
key
Customer Account branch
key branch John 1001 Irvine
social-
security acct# Megan 1001 Dallas
Megan 1002 Tokyo
customer CAB account John 1002 Tokyo
Illegal: Both John and
1 to1 to 1 relationship balance Megan have account 1002 in
Tokyo Branch
 Interpretation:
 Each (customer, branch) related to a single account
 Each (customer, account) pair related to a single
branch
Customer Account branch
 Each (branch, account) pair can have single John 1001 Irvine
customer Megan 1001 Dallas
Megan 1002 Tokyo

Legal
Representing Ternary Relationship
Using Binary Relationships
branch

branch
customer
customer CAB account
CB
AB
Customer Account branch
C2 A1 B1
C1 A2 B1 customer CA account
C1 A1 B2

The CAB relationship Set cannot be represented using the Schema

consisting of binary relationships shown above!!

 Hence, above Schema using binary relationships does

not correctly capture the information represented by
the ternary relationship.
Representing Ternary Relationship
Using Binary Relationships
CAB

branch

C’ B’ A’
customer
customer CAB account

customer branch account

 The CAB relationship is represented as a weak entity

set that depends upon the customer, branch and
account entity sets.
 This schema using binary relationship fully captures
the ternary relationship.
Representing Ternary Relationship
Using Binary Relationships
branch
branch

customer
customer CAB account
customer
customer CAB account
branch

customer
customer CAB account

 Previous mapping technique works for many-many-many

relationship.
 How to convert the many-many-1, many-1-1, 1-1-1 ternary
relationships into binary relationships?
 In general, it is always possible to convert any ternary (or multiway
relationship) into a collection of binary relationships without losing
information!!
 However, the conversions can be quite complex and resulting
unnatural schemas
Limitations of the Basic ER
Model Studied So Far
 Lots of times an entity set has members that have
special properties not associated with all the
members of the entity set.

 E.g., the set of checking accounts and savings

accounts are a subset of the set of accounts.
Checking has a overdraft amount, and savings has a
interest-rate.
Limitations of the Basic ER
Model Studied So Far
 How to represent this in the ER model:
 associate an attribute -- account-type with the accounts entity set
 Problems:
 different attributes may be associated with the account depending on its
type
 checking: overdraft amount
 savings: interest rate
 depending upon its type, savings and checking accounts may participate in
different relationships.
 Another approach:
 entity sets: checking, savings, and accounts.
 relationships: 1-1 between checking and accounts, and 1-1 between
savings and accounts
 Problems:
 Not intuitive: checking and savings are represented as entities different
from accounts, even though they are accounts
 Redundancy of information: info about accounts represented both in
checking / savings as well as account entity set
 Potential Errors: Same account could be erroneously associated with both
checking as well as savings.
Subclass/Superclass Relationships
account#
account

balance

ISA

savings checking

interest rates overdraft amount

 savings and checking are subclasses of the account entity set

 account is a superclass of savings and checking entity sets
 An entity in a subclass has to belong to superclass as well -- that is, every
savings account is also an account. Similarly every checking account is also an
account
 Attribute Inheritance: subclasses inherit all the attributes of the superclass.
Similarly, subclasses inherit all relationships in which the superclass participates
Reason why Superclass/Subclass
relationships arise in ER Schemas
 Superclass and Subclass relationships arise during schema
design due to the process of specialization and generalization
 Specialization: process of classifying a class of objects into
more specialized subclasses
 E.g., during design, we begin with an employee entity set. We then
specialize the employee set into different types of employees.
 Generalization: Reverse of specialization -- it is a process of
synthesis of two or more (lower level) entity sets to produce
a higher-level entity set.
 E.g., during design, we have identified a car, a sports utility vehicle,
and a truck. We generalize these classes to create an automobile
entity set.
Types of Class/Subclass
Relationships
 Disjoint vrs Overlapping:
 if the subclasses of the entity set do not overlap then it is
disjoint (denoted by a ‘d’ next to ISA triangle).
 Else, overlapping (denoted by a ‘o’ next to ISA triangle)
 Total vrs Partial:
 If an entity in a superclass belongs to atleast one of the
subclasses, then total. (denoted by a double line from
superclass to ISA triangle)
 Else, partial
 Key of entity set corresponding to the subclass is the
same as the key for the superclass.
Superclass/Subclass Lattice
Class/Subclass relationships might form a hierarchy (tree)
or a lattice
person

o
ISA

employee aluminus student

d
ISA d ISA

student grad undergrad

staff faculty assistant

o
ISA

RA TA
Multiple Inheritance
 In a class/subclass relationship, the subclass inherits all its
attributes from the superclass.
 If a subclass has 2 or more superclasses, then subclass
inherits from all the superclasses (multiple inheritance)
 How should conflicts be resolved?
 Example:
 Employee Entity Set: with an attribute country denoting the country
of citizenship
 Asians Entity Set: with an attribute country denoting the country
from which a particular person originated.
 Asian_Employee Entity set is a subclass of both Employee and
Asians. However, what does country attribute of the
Asian_Employee correspond to.
 ER model mute on multiple inheritance
Limitations of ER Model

We wish to represent that an employee works on

a specific project possibly using multiple tools
project
employee
works_using

incorrect since it requires tools

each project to use tools

work
employee project

using
relationships among
relationships not
permitted in ER! tools
Aggregation

employee project
works

using

N
tools

 Treat the relationship set work and the entity sets employee and
projects as a higher level entity set-- an aggregate entity set
 Permit relationships between aggregate entity sets and other
entity sets
Representation without
Aggregation in ER Model

employee project
works

using
redundant
relationship!
tools

employee project
EP

works using
awkward schema!

tools
Review of ER Model
 Basic Model:
 Entities : strong, weak
 Attributes associated with entity sets and relationships
 Relationships: binary, ternary, ...
 Role of entity sets in a relationship
 Constraints on entity set: domain constraints, key constraint
 Constraint on relationships: cardinality -- 1-1, 1-N, M-N,
participation (also called existential) --total vrs partial
 Extended Model:
 Notion of superclass and subclass
 Superclass/subclass relationships: disjoint vrs overlapping, total
vrs partial
 Notion of aggregation
E/R Design Cycle
 Good design important since schemas do not
change often
 The first version is almost always wrong.
Typical Schema Design Cycle
1: Requirement Analysis: Learn about the application.
– what problem does the application solve, what questions does the application ask
about the data, what data does the application need to answer these questions.
2: Design a trial schema
-- top-down strategy: define high level concepts and then use successive
refinements
-- bottom-up strategy: start with schema containing basic abstractions and then
combine or add to them
3: Evaluate schema for quality and completeness.
-- consider the future: how is the application likely to change? Account for
change
4: Iterate until satisfied
Schema Design Issues
 Observation: there may be multiple ER schemas
describing the same target database or miniworld.
 Decisions that need to be made:
 whether to use an attribute or entity set to represent an object
 whether to model a concept as a relationship or an entity set
 whether to use ternary relationship or a set of binary ones
 whether to use a strong entity set of a weak entity set
 whether using generalization/specializations is appropriate
 whether using aggregates is appropriate
 Unfortunately, there are no straightforward answers to
these questions
 No two design teams will come up with the same design.
 However, there are some simple design principles that
should be followed during ER design.
E/R Design Principles
 Schemas should not change often. So store frequently
changing information as instances.
 currently each project consists of 10 members. Since later
projects may have more or less employees, do not hard code the
10 employees as 10 attributes of the project entity
 Schemas should prevent representing the same facts
multiple times (avoid redundancy).
 An attribute/relationship is redundant if deleting it does not
result in a loss of any information
 redundancy may cause:
 wastage of space in storing data
 application programming to be more difficult -- applications need to
update all instances of a fact else risk inconsistency of database
 Consistent and clear naming policy for attributes,
entities, and relationships
Redundant Attributes
dept # mgr start date emp ssno

department manages employee

start date

Managers start date stored twice -- redundancy.

Redundant Relationship
is-customer-of
supplier

supplies

project
item

used-by

•The fact that a project is-customer-of a supplier can be derived from the
relationships between supplier and item and between item and project.
•That is, a project is-customer-of a supplier if there is a item that the supplier
supplies which is used by the project.
•Redundancy analysis can be tricky -- if supplies is a N:N relationship, then
schema does not contain redundancy.
A Design Problem
 We wish to design a database representing
cities, counties, and states in the US.
 For states, we wish to record the name,
population, and state capital (which is a city).
 For counties, we wish to record the name, the
population, and the state in which it is located.
 For cities, we wish to record the name, the
population, the state in which it is located and
the county in which it is located.
Uniqueness assumptions:
 Names of states are unique.
 Names of counties are only unique within a
state (e.g., 26 states have Washington
Counties).
 Cities are likewise unique only within a state
(e.g., there are 24 Springfields among the 50
states).
 Some counties and cities have the same name,
even within a state (example: San Francisco).
 All cities are located within a single county.
Design 1: Bad design
Popu. name

states
Co. name
Co. Popu.
Located-in2

cities
capital
County Population
Ci. Popu. Ci. name repeated for each city
Design 2 -- good design
Co. Popu.
Co. name Popu. name

Located -
counties states
in1

Belongs-to

cities
capital

Ci. Popu. Ci. name

Another Design Problem
 We wish to design a database consistent with the
following facts.
 Trains are either local trains or express trains, but never
both.
 A train has a unique number and an engineer.
 Stations are either express stops or local stops, but
never both.
 A station has a name (assumed unique) and an address.
 All local trains stop at all stations.
 Express trains stop only at express stations.
 For each train and each station the train stops at, there
is a time.
Design 1: Bad design

Does not capture the constraints that express trains only stop only at express
stations and local trains stop at all local stations
Design 2: Better Design
sname saddress
number engineer

time stations
trains

StopsAt2 d
d IS
IS time A
A
stopsAt1

Express stations Local stations

Express train Local train