System Analysis & Design – Week – 9 (Modeling logic with decision Tables)

Modeling logic with decision Tables

A decision table is a diagram of process logic where the logic is reasonably complicated.
All of the possible choices and the conditions the choices depend on are represented in tabular
form, as illustrated in the decision table in Figure 7-18. The decision table in Figure 7-18 models
the logic of a generic payroll system.
The table has three parts: the condition stubs, the action stubs, and the rules.
The condition stubs contain the various conditions that apply to the situation the table is modeling.
In Figure 7-18, there are two condition stubs for employee type and hours worked. Employee type
has two values: “S,” which stands for salaried, and “H,” which stands for hourly. Hours worked
has three values: less than 40, exactly 40, and more than 40. The action stubs contain all the
possible courses of action that result from combining values of the condition stubs.
There are four possible courses of action in this table: Pay Base Salary, Calculate Hourly Wage,
Calculate Overtime, and Produce Absence Report. You can see that not all actions are triggered
by all combinations of conditions. Instead, specific combinations trigger specific actions. The part
of the table that links conditions to actions is the section that contains the rules
(ref pg.86 for further explanations notes).

Page 1 of 5 © 2024
 System Analysis & Design – Week – 9 (Modeling logic with decision Tables)

Conceptual Data Modeling

A conceptual data model is a representation of organizational data. The purpose of a conceptual

data model is to show as many rules about the meaning and interrelationships among data as are
possible.

Conceptual data modeling is typically done in parallel with other requirements analysis and
structuring steps during systems analysis.
On larger systems development teams, a subset of the project team concentrates on data modeling
while other team members focus attention on process or logic modeling.
Introduction to E-R Modeling
An entity-relationship data model (E-R model) is a detailed, logical representation of the data for
an organization or for a business area.
The E-R model is expressed in terms of entities in the business environment, the relationships or
associations among those entities, and the attributes or properties of both the entities and their
relationships.
The basic E-R modeling notation uses three main constructs: data entities, relationships and their
associated attributes.
An entity is a person, place, object, event, or concept in the user environment about which the
organization wishes to maintain data. An entity has its own identity, which distinguishes it from
other entities.
An entity type is a collection of entities that share common properties or characteristics. An entity
instance is a single occurrence of an entity type.
We use a simple noun to name an entity type. We use capital letters in naming an entity type and, in
an E-R diagram, the name is placed inside a rectangle representing the entity.
E.g.

An entity instance (also known simply as an instance) is a single occurrence of an entity type. An
entity type is described just once in a data model, whereas many instances of that entity type may

Page 2 of 5 © 2024
 System Analysis & Design – Week – 9 (Modeling logic with decision Tables)

be represented by data stored in the database. For example, there is one EMPLOYEE entity type in
most organizations, but there may be hundreds (or even thousands) of instances of this entity type
stored in the database.

Example 1: there is usually one EMPLOYEE type but there may be hundreds of instances of this
entity type stored in a database. Each entity type has a set of attributes associated with it.

Example 2: for an entity STUDENT we have such attributes like: STUDENT NO, NAME,
ADDRESS, PHONE NO. Every entity must have an attribute or set of attributes that distinguishes
one instance from other instances of the same type

Naming and Defining Entity Types

When naming and defining entity types, you should use the following guidelines:

- An entity type name is a singular noun (such as CUSTOMER, STUDENT, or

AUTOMOBILE).
- An entity type name should be descriptive and specific to the organization. For example, a
PURCHASE ORDER for orders placed with suppliers is distinct from CUSTOMER ORDER
for orders placed by customers. Both of these entity types cannot be named ORDER.
- An entity type name should be concise (short and clear). For example, in a university database,
use REGISTRATION for the event of a student registering for a class rather than STUDENT
REGISTRATION FOR CLASS.
- Event entity types should be named for the result of the event, not the activity or process of the
event. For example, the event of a project manager assigning an employee to work on a project
results in an ASSIGNMENT

Attributes

Each entity type has a set of attributes associated with it. An attribute is a property or characteristic
of an entity. Following are some typical entity types and associated attributes:

STUDENT: Student_ID, Student_Name, Home_Address, Phone_Number, Major

We use an initial capital letter, followed by lowercase letters, and nouns in naming an attribute;
underscores may or may not be used to separate words.

Page 3 of 5 © 2024
 System Analysis & Design – Week – 9 (Modeling logic with decision Tables)

In E-R diagrams, we represent an attribute by placing its name inside the rectangle for the
associated entity.

Types of Attributes

• Atomic vs composite,

• Single valued vs multi valued,

• stored vs derived,

• NULL value and

• Key attributes

Example: Entity Relationship Model (ERD) CourseName

courseID
NoOfUnits

M 1
STUDENT Enrolled COURSE

DoB
studID

studName

Mapping cardinality constraints

- One-to One (1 : 1)
- One-to-Many (1 : M)
- Many-to-One (M :1)
- Many-to-Many (M : N)
Representing Super-types and Sub-types

- A subtype is a sub grouping of the entities in an entity type that is meaningful to the
organization. For example, STUDENT is an entity type in a university. Two subtypes of
STUDENT are GRADUATE STUDENT and UNDERGRADUATE STUDENT.
- A super-type is a generic entity type that has a relationship with one or more subtypes.
- Business Rules: Conceptual data modeling is a step-by-step process for documenting
information requirements, and it is concerned with both the structure of data and with rules
Page 4 of 5 © 2024
 System Analysis & Design – Week – 9 (Modeling logic with decision Tables)

about the integrity of those data.

Business rules are specifications that preserve the integrity of the logical data model. Four basic
types of business rules are as follows:

1. Entity integrity: Each instance of an entity type must have a unique identifier that is not null.
2. Referential integrity constraints: Rules concerning the relationships between entity types.
3. Domains: Constraints on valid values for attributes.
4. Triggering operations: Other business rules that protect the validity of attribute values.
- Domains: A domain is the set of all data types and ranges of values that attributes may assume.
- Triggering operations: A triggering operation (also called a trigger) is an assertion or rule that
governs the validity of data manipulation operations such as insert, update, and delete.

Role of Packaged Conceptual Data Models: There are two principal types of packaged data
models: universal data models applicable to nearly any business or organization and industry-
specific data models.

Universal Data Models

- Universal data models are templates for one or more of these subject areas and/or functions.
- All of the expected components of data models are generally included: entities, relationships,
attributes, primary and foreign keys, and even sample data.

Industry-Specific Data Models

- Industry-specific data models are generic data models that are designed to be used by
organizations within specific industries.
- These models are based on the premise that data model patterns for organizations are very
similar
- within a particular industry (“a bank is a bank”).
- However, the data models for one industry (such as banking) are quite different from those for
another (such as hospitals).

Page 5 of 5 © 2024