Structuring System

Data Requirements

Conceptual Data Modeling

Process (leads to programs)

Logic (leads to programs)

DFD

Decision Table, Structured English

Data (leads to DB)

Conceptual Data Model, Logical Data Model, Physical Data

Model

Conceptual Data Modeling

Conceptual data modeling: a detailed

model that captures the overall structure of
data in an organization.

Independent of any database management

system (DBMS) or other implementation
considerations.

Chapter 9

2008 by Prentice Hall

Entity-Relationship Diagram (E-R

Diagram)

Example
At the primitive
DFD level,
Briefly,
- Entity types
- Attributes
- Relationship
Data Store
-> Entity Type
Data elements
associated with
data flows
-> Attributes

Conceptual Data Modeling

Conceptual Data Model (Lecture 7) and

Logical Data Model (Lecture 8)

Independent of any database management

system (DBMS) or other implementation
considerations

Physical Data Model (Design phase and

Database Design Course)

Process of Data Modeling

Develop a data model for the current system

Develop a new conceptual data model that includes

all requirements of the new system

In the design stage, the conceptual data model is

translated into

a logical design and then

a physical design

Deliverables of Conceptual Data

Modelling

Primary deliverable is an entity-relationship (E-R)

diagram

As many as 4 E-R diagrams are produced and

analyzed

E-R diagram that covers data needed in the projects

application (isolated, new)
E-R diagram for the application being replaced (isolated,
old)
E-R diagram for the whole database from which the new
applications data are extracted (whole, new)
E-R diagram for the whole database from which data for
the application system being replaced is drawn (whole,
old)

Deliverables and Outcome

(cont.)

Second deliverable is a set of entries about

data objects to be stored in repository or
project dictionary.

Data dictionary
Attribute name
Permission
Data type
Source
Used by
Definition of terms
Domain

Chapter 9

2008 by Prentice Hall

11

Gathering Information for

Conceptual Data Modelling

Two perspectives

Top-down

Data model is derived from an intimate understanding of

the business.

Bottom-up

Data model is derived by reviewing specifications and

business documents.

Introduction to EntityRelationship (E-R) Modeling

Entity-Relationship data model (E-R

model): a detailed, logical representation of
the entities, associations and data elements
for an organization or business area.

Attributes
Entity Types
Relationship

Entity-relationship diagram (E-R diagram):

a graphical representation of an E-R model.
13

Guidelines for Attribute Names

Noun
Unique within the same entity type
Follow a standard format

Student_GPA, not GPA_of_Student

Similar attributes of different entity types

should use similar but distinguishing names

Faculty_Residence_City_Name and
Student_Residence_City_Name

Guidelines for Attribute Names

An attribute definition states what the

attribute is and possibly why it is important

Separate documentation

An attribute definition should make it clear

what is included and what is not

Emp_Salary is the amount of money paid each

month exclusive of any benefits, bonus,
reimbursements, or special payments.

Guidelines for Attribute Names

Aliases can be used

Specify the source of values for the attribute

Specify if a value for the attribute is required or

optional

Specify if a value for the attribute may change

NULL?

Constant?

Indicate any relationships an attribute has with other

attributes

Identifier Attributes

Candidate key
Attribute (or combination of attributes) that
uniquely identifies each instance of an entity type
Example : Employee_ID for EMPLOYEE

Identifier

A candidate key that has been selected as the

unique identifying characteristic for an entity type

Identifier Attributes

Single attribute

Employee_ID

Multiple attributes

Home_Team, Visiting_Team
Employee_Name, Employee_Address

Identifier Attributes
(cont.)
1. Choose a candidate key that will not change its
value.

Emp_Name and Address combination is a poor choice

2. Choose a candidate key that will never be null.

1. Avoid using intelligent keys.

The first two digits of Student_ID indicate nationalities

2. Consider substituting single value surrogate keys for

large composite keys.

Use Game_ID instead of Home_Team and Visiting_Team

Multivalued Attributes

An attribute that may take on more than one

value for each entity instance

Other Attribute Types

Required attribute: an attribute that must have

a value for every entity instance.

Optional attribute: an attribute that may not

have a value for every entity instance.

Composite attribute: an attribute that has

meaningful component parts.

Derived attribute: an attribute whose value can

be computed from related attribute values.

Chapter 9

2008 by Prentice Hall

23

Entity Types

A true data entity type will have many possible

instances, each with a distinguishing
characteristics, as well as one or more other
descriptive pieces of data

Example

Person: EMPLOYEE, STUDENT, PATIENT

Place: STORE, WAREHOUSE, STATE

Not MY_CAR

Event: SALE, REGISTRATION, RENEWAL

Not MMU

Object: MACHINE, BUILDING, PRODUCT

Not PRESIDENT

Not MJ_CONCERT_2009

Concept: ACCOUNT, COURSE

Not BUDGET_2009

Entity Guidelines

Singular noun

Descriptive and specific

PURCHASE_ORDER or CUSTOMER_ORDER
Not just ORDER

Concise

Not PURCHASE _ORDER_TO_SUPPLIER

Guidelines for Entities

An entity type definition must include

the characteristic or combination of characteristics which

make an entity instance unique (key attribute)

Clear explanation what entity instances are included and

not included

A customer is a person that has placed an order from us or

that we have contacted to promote our products. A customer
does no include persons who buy our products through our
distributors.

A description of when an instance of the entity type is

created or deleted.

Guidelines for Entities

An entity type definition must include

When in instance might change into an instance

of another entity.

A bid for a construction company becomes a contract

once it is accepted

What history is to be kept about entity instances

Relationships

Verb or verb phrase

Relationship: an association between the

instances of one or more entity types that is
of interest to the organization.

Chapter 9

2008 by Prentice Hall

31

Degree of Relationship

Degree: number of entity types that participate in a

relationship
Three cases

Unary (Recursive): between two instances of one entity type

Binary: between the instances of two entity types
Ternary: among the instances of three entity types

Unary Relationships

Binary Relationships

Ternary Relationship

Cardinality

The number of instances of entity B that can or must be

associated with each instance of entity A

Minimum Cardinality
The minimum number of instances of entity B that may be
associated with each instance of entity A

Maximum Cardinality
The maximum number of instances of entity B that may be
associated with each instance of entity A

Mandatory vs. Optional Cardinalities

Specifies whether an instance must exist or can be absent in the
relationship

Cardinality Constraints

Guidelines for Defining Relationships

Use verb or verb phrase

Avoid vague names

Explains what action is being taken and why

Give examples to clarify the action
Explain any optional participation

Such as: Has, Is_related_to

What conditions lead to zero associated instances

Explain the reason for any explicit maximum

cardinality

Guidelines for Defining Relationships

Explain any restrictions on participation in the

relationship

An employee cannot supervise him- or herself,

and cannot supervise other employees if his or
her job classification level is below 4

Explain the extent of history that is kept in the

relationship

Associative Entities

An associative entity is:

An entity
A relationship

It is a relationship that data modeller chooses

to model as an entity type.

Because it has associated attributes

Example

Supertypes and Subtypes

Subtype: a subrouping of the entities in an

entity type that shares common attributes or
relationships distinct from other subtypes

Supertype: a generic entity type that has a

relationship with one or more subtype

Rules for Supertype/Subtypes

Relationships

Total specialization: an entity instance of the

supertype must be an instance of one of the
subtypes

Partial specialization: an entity instance of the

supertype may or may not be an instance of one of
the subtypes

Disjoint: an entity instance of the supertype can be

an instance of only one subtype

Overlap: an entity instance of the supertype may be

an instance of multiple subtypes

Business Rules

E-R diagram concentrates on the structure of data.

Business rules are specifications that preserve the

integrity of the logical data model (usually relational
schema)
Four types

Entity integrity: unique, non-null identifiers (PK)

Referential integrity constraints: rules governing
relationships (FK)
Domains: valid values for attributes (Data Types)
Triggering operations: other business rules regarding
attribute values (Triggers)

Domains

The set of all data types and ranges of

values that an attribute can assume

Several advantages
1. Verify that the values for an attribute are valid
2. Ensure that various data manipulation
operations are logical
3. Help conserve effort in describing attribute
characteristics

Triggering Operations

An assertion or rule that governs the validity of data

manipulation operations such as insert, update and
delete
Components:
User rule: statement of the business rule to be
enforced by the trigger
Event: data manipulation operation that initiates the
operation
Entity Name: name of entity being accessed or
modified
Condition: condition that causes the operation to be
triggered
Action: action taken when the operation is triggered

Packaged Data Models

Generic data models that can be applied and

modified for an organization
Two categories
Universal
Industry-specific

Benefits
Reduced implementation time and cost
High-quality modelling