MODELING DATA IN

ORGANIZATION

Modern Database Management

1
 OBJECTIVES

▪ Definition of terms
▪ Importance of data modeling
▪ Write good names and definitions for entities,
relationships, and attributes
▪ Distinguish unary, binary, and ternary relationships
▪ Model different types of attributes, entities,
relationships, and cardinalities
▪ Draw E-R diagrams for common business
situations

2
 OBJECTIVES
▪ Convert many-to-many relationships to
associative entities
▪ Model time-dependent data using time stamps

3
 BUSINESS RULES
▪ Statements that define or constrain some
aspect of the business
▪ Assert business structure
▪ Control/influence business behavior
▪ Expressed in terms familiar to end users
▪ Automated through DBMS software

4
 A GOOD BUSINESS RULE IS
▪ Declarative - what, not how
▪ Precise - clear, agreed-upon meaning
▪ Atomic - one statement
▪ Consistent - internally and externally
▪ Expressible - structured, natural language
▪ Distinct - non-redundant
▪ Business-oriented - understood by
business people

5
 A GOOD DATA NAME IS:
▪ Related to business, not technical,
characteristics
▪ Meaningful and self-documenting
▪ Unique
▪ Readable
▪ Composed of words from an approved
list
▪ Repeatable

6
 E-R MODEL CONSTRUCTS

▪ Entities:
• Entity instance - person, place, object,
event, concept (often corresponds to a
row in a table)
• Entity Type - collection of entities (often
corresponds to a table)

7
 E-R MODEL CONSTRUCTS

▪ Relationships:
• Relationship instance - link between
entities (corresponds to primary key-
foreign key equivalencies in related
tables)
• Relationship type - category of
relationship…link between entity types

8
 E-R MODEL CONSTRUCTS

▪ Attribute - property or characteristic of an

9
SAMPLE E-R DIAGRAM

10
 BASIC E-R NOTATION

Entity
Attribute
symbols
symbols

A special entity
that is also a Relationship
relationship symbols

Relationship
degrees specify
number of
entity types Relationship
involved cardinalities
specify how
many of each
entity type is
allowed
11
 WHAT SHOULD AN ENTITY BE?
SHOULD BE:
• An object that will have many instances in the
database
• An object that will be composed of multiple
attributes
• An object that we are trying to model
SHOULD NOT BE:
• A user of the database system
• An output of the database system (e.g., a report)

12
EXAMPLE OF INAPPROPRIATE ENTITIES

System System
user Inappropriate output
entities

Appropriate
entities

13
 ATTRIBUTES
Attribute - property or characteristic of an
entity or relationship type
Classifications of attributes:
• Required versus Optional Attributes
• Simple versus Composite Attribute
• Single-Valued versus Multivalued Attribute
• Stored versus Derived Attributes
• Identifier Attributes

14
 IDENTIFIERS (KEYS)
• Identifier (Key) - An attribute (or
combination of attributes) that uniquely
identifies individual instances of an entity
type
• Simple versus Composite Identifier
➢ Flight Key
• Candidate Identifier - an attribute that could
be a key…satisfies the requirements for
being an identifier

15
SIMPLE AND COMPOSITE IDENTIFIER
ATTRIBUTES
The identifier is boldfaced and underlined

16
 CHARACTERISTICS OF IDENTIFIERS
• Will not change in value
• Will not be null
• No intelligent identifiers (e.g., containing
locations or people that might change)
• Substitute new, simple keys for long,
composite keys

17
 A COMPOSITE ATTRIBUTE

An attribute
broken into
component parts

Entity with multivalued attribute (Skill)

Multivalued
an employee can have
Derived
more than one skill
from date
employed and
current date 18
SIMPLE EXAMPLE OF TIME-STAMPING

This attribute
that is both
multivalued and
composite

19
RELATIONSHIP TYPES AND INSTANCES
a) Relationship type

b) Relationship
instances

20
 DEGREE OF RELATIONSHIPS

Entities of
One entity two different
related to types related
another of to each other Entities of three
the same different types
entity type related to each
other
21
 CARDINALITY OF RELATIONSHIPS
One-to-One
• Each entity in the relationship will have exactly
one related entity
One-to-Many
• An entity on one side of the relationship can
have many related entities, but an entity on the
other side will have a maximum of one related
entity
Many-to-Many
• Entities on both sides of the relationship can
have many related entities on the other side
22
 EXAMPLES OF RELATIONSHIPS OF
DIFFERENT DEGREES
a) Unary relationships

23
 EXAMPLES OF RELATIONSHIPS OF
DIFFERENT DEGREES(CONT.…)
b) Binary relationships

24
 EXAMPLES OF RELATIONSHIPS OF
DIFFERENT DEGREES(CONT.…)
c) Ternary relationship

Note: a relationship can have attributes of its own

a) Mandatory Cardinalities

A patient history is A patient must have recorded

26
 EXAMPLES OF CARDINALITY CONSTRAINTS

b) One optional, one mandatory

A project must be An employee can be assigned

27
 EXAMPLES OF CARDINALITY CONSTRAINTS

a) Optional cardinalities

A person is
married to at most
one other person,
or may not be
married at all

28
 EXAMPLES OF MULTIPLE RELATIONSHIPS
a) Employees and Departments

Entities can be related to one another in more than one way

29
 EXAMPLES OF MULTIPLE RELATIONSHIPS
b) Professors and courses (fixed lower limit constraint)

Here, min
cardinality
constraint is 2

30