Database Analysis

Chapter 2: Modeling Data in the

Organization
 Objectives
• Define key terms
• 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
• Convert many-to-many relationships to associative entities

2
The overall Steps to analyze, design and
implement databases

“Business rules “
 Business Rules
Business rule
• A statement that defines or constrains some
aspect of the business. It is intended to assert
business structure or to control or influence
the behavior of the business.
• Example:  “A student may register for a section
of a course only if he or she has successfully
completed the prerequisites for that course.”

4
 A Good Business Rule is:
• Declarative–what, not how
• Precise–clear, agreed-upon meaning
• Atomic–one statement
• Consistent–no conflicts internally and
externally
• Expressible–structured, natural language- no
misinterpretation
• Distinct–non-redundant
• Business-oriented–understood by business
people
5
 Gathering business rules
• In descriptions of business functions, events,
policies, units, stakeholders, and other objects.
• Can be found in interview notes during
requirements collection sessions or organizational
documents (e.g., personnel manuals, policies,
contracts, marketing brochures, and technical
instructions)
• Identified by asking questions about the who, what,
when, where, why, and how of the organization
 Business Rule Grammar
<entity> <minimum cardinality> <relationship>
<maximum cardinality> <entity>

<CUSTOMER> <may> <Submit> <any number>

<ORDER>
 A Good Data Name is:

• Related to business, not technical, characteristics

• Meaningful and self-documenting ( avoid using generic
words e.g. Person)
• Unique  (e.g., Home Address vs Campus Address).
• Readable
• Composed of words from an approved list
• Repeatable (same person at different times should
develop exactly or almost the same name)
•  Follow a standard syntax

8
 Data Definitions

• Explanation of a term or fact

– Term–word or phrase with specific meaning
(e.g., Course)
– Fact–association between two or more terms
(e.g., A course is a module of instruction in a
particular subject area.” This definition associates
two terms: module of instruction  and subject area)

9
Guidelines for good data definition
– Gathered in conjunction with systems
requirements
– Accompanied by diagrams
– Iteratively created and refined
– Achieved by consensus
 Enterprise Database Modeling

Business Rules Conceptual Data Model

-Data names (Entity-Relationship Diagram)
-Data definitions

A enterprise data model identifies the highest-level

relationships between the different entities. Features of
enterprise data model include:
– Important entities and the relationships among them.
– No attribute is specified.
– No primary key is specified.
 Modeling Entity-Relationship
• Entity-Relationship (ER) Model (E-R model)  is a detailed, logical
representation of the data for an organization or for a business area.

• It is based on the notion of real-world entities and relationships

among them.

• ER Model creates entity set, relationship set, general attributes, and

constraints.

•  ER Model is expressed as an entity-relationship diagram (E-R diagram,

or ERD),  which is a graphical representation of an E-R model.
ER Diagrams
 Modeling Entities
• Entities: Any real-world thing about which an enterprise records data.
 Entity Type– a collection of entities that share common properties or characteristics
(often corresponds to a table)
 Entity instance–a single occurrence of an entity type (person, place,
object, event, concept (often corresponds to a row in a table)

14
 Entities
• Person: EMPLOYEE, STUDENT
• Place: WAREHOUSE, COUNTRY
• Object: BUILDING, MACHINE
• Event: SALE, REGISTRATION
• Concept: ACCOUNT, COURSE

EMPLOYEE DEPENDENT CERTIFICATE

Strong entity Weak entity

Associative entity
15
 Entities (cont.)
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
– Must have an identifier
• SHOULD NOT BE:
– A user of the database system
– An output of the database system (e.g., a report)
16
 Strong vs. Weak Entities
• Strong entities
– exist independently of other types of entities
– has its own unique identifier
– represented with single-line rectangle
• Weak entity
– dependent on a strong entity…cannot exist on its own
– does not have a unique identifier
– represented with double-line rectangle
• Identifying relationship
– links strong entities to weak entities
– represented with double line diamond

17
 Strong vs. Weak Entities (cont.)

Identifying relationship Weak entity

Strong entity
18
 Modeling Attributes
• Attributes –property or characteristic of an entity or relationship type
(often corresponds to a field in a table)
 Attributes
• Classifications of attributes:
– Required versus Optional Attributes
– Simple versus Composite Attribute
– Single-Valued versus Multivalued Attribute
– Stored versus Derived Attributes
– Identifier Attributes

20
A composite attribute

An attribute broken into

component parts
 Entity with a multivalued attribute (Skill) and
derived attribute (Years_Employed)
What’s wrong with this?

Multivalued:
Derived
an employee can have
from date employed and current date
more than one skill

© Prentice Hall, 2002 22

An attribute that is both multivalued and composite

This is an example
of time-stamping

© Prentice Hall, 2002 23

A composite attribute

An attribute
broken into
component parts

Entity with multivalued attribute (Skill) and derived attribute

(Years_Employed)

Multivalued
Derived
an employee can have
from date
more than one skill
employed and
current date
24
 Attributes (cont.)
Identifiers (Keys)
• Identifier (Key)–An attribute (or combination
of attributes) that uniquely identifies
individual instances of an entity type
• Simple versus Composite Identifier
• Candidate Identifier–an attribute that could be
a key…satisfies the requirements for being an
identifier

25
 Attributes (cont.)

Identifier Key
The key is underlined
 Composite key attribute

The key is composed

of two subparts

© Prentice Hall, 2002 27

 Attributes (cont.)

Guidelines for Identifier Key:

– 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
• ?  Game_Number

28
 Modeling Relationships
• A relationship is an association representing an interaction
among the instances of one or more entity types that is of
interest to the organization.

SHIP
SUPPLIER PART

WORK FOR
EMPLOYEE COMPANY

© Prentice Hall, 2002 29

 Relationships
• Relationship Types vs. Relationship Instances
– The relationship type is modeled as lines between
entity type
– The relationship instance is modeled between specific
entity instances entities (corresponds to primary key-
foreign key equivalencies in related tables).

• Associative Entity–combination of relationship

and entity.

30
 Relationship types and instances

a) Relationship type
(complete)

b) Relationship
instances

31
 Relationships (cont.)

₋ Relationships can have attributes

These describe features pertaining to the association between the entities
in the relationship

attribute of the relationship

The relationship type is modeled as the

diamond and lines between entity types
 Relationships (cont.)
A relationship with an attribute

Here, the date completed attribute pertains specifically to the

employee’s completion of a course…it is an attribute of the
relationship

33
 Relationships (cont.)
Two entities can have more than one type of
relationship between them (multiple relationships)
Employees and departments

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

34
 Relationships (cont.)

Degree of Relationships

• It is the number of entity types that

participate in it
– Unary Relationship
– Binary Relationship
– Ternary Relationship

35
 Relationships (cont.)
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
36
 Relationships (cont.)

a) Unary relationships

37
 Relationships (cont.)
b) Binary relationships

38
 Relationships (cont.)
c) Ternary relationship

Note: a relationship can have attributes of its own

39
 Relationships (cont.)
Cardinality of Relationships
First: One-to-One (1:1)

Each entity in the relationship will have exactly one related entity

Is managed by
Department Manager
Manages
 Relationships (cont.)
Cardinality of Relationships
• Second: One-to-Many (1:N) OR Many to one
(M:1)

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.

Has
Patient Patient History
Belong
 Relationships (cont.)
Cardinality of Relationships
• Third: Many -to-Many (M:M OR N:M)
Entities on both sides of the relationship can have many related
entities on the other side.

Work on
Employee project
Worked by
 Relationships (cont.)
• Cardinality constraints (Modality)
• It is the number of instances of one entity that
can or must be associated with each instance of
another entity
• Minimum Cardinality
– If zero, then optional
– If one or more, then mandatory
• Maximum Cardinality
– The maximum number
 Relationships (cont.)
Examples of cardinality constraints (cont.)

a) Mandatory cardinalities

A patient history is A patient must have recorded at

recorded for one and only least one history, and can have
one patient many
44
 Relationships (cont.)
Examples of cardinality constraints (cont.)

b) One optional, one mandatory

A project must be assigned An employee can be assigned to

to at least one employee, any number of projects, or may
and may be assigned to not be assigned to any at all
many 45
 Relationships (cont.)
Examples of cardinality constraints (cont.)

c) Optional cardinalities

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

46
 Relationships (cont.)

Cardinalities

Mandatory one

Mandatory many

Optional one

Optional many
47
 Associative Entities
• An entity has attributes

• A relationship links entities together

• When should a relationship with attributes instead be an
associative entity?
– All relationships for the associative entity should be many
– The associative entity could have meaning independent of the other
entities
– The associative entity preferably has a unique identifier, and should also
have other attributes
– The associative entity may participate in other relationships other than
the entities of the associated relationship

48
 Associative Entities (cont.)
A binary relationship with an attribute

Here, the date completed attribute pertains specifically to the

employee’s completion of a course…it is an attribute of the
relationship

49
 Associative Entities (cont.)

Associative entity is like a relationship with an attribute, but it is

also considered to be an entity in its own right.

Note that the many-to-many cardinality between entities in the

previous slide has been replaced by two one-to-many
relationships with the associative entity.

50
 Relationship symbols Attribute symbols

Entity symbols

An associative entity : A
special entity that is also
a relationship

Relationship degrees
specify number of entity
types involved

Relationship
cardinalities specify
how many of each
entity type is allowed
51
Activity