Download as pdf or txt
Download as pdf or txt
You are on page 1of 34

Chapter six

part Two
Logic modelling and conceptual data modelling
Modeling logic with decision tables
• A decision table is a diagram of process logic where the logic is reasonably
complicated.
• Decision table:
A matrix representation of the logic of a decision;
it specifies the possible conditions for the decision and the resulting actions.
• The table has three parts:
1. the condition stubs,
2. the action stubs, and
3. the rules.
Decision tree parts
• Condition stubs
The part of a decision table that lists the conditions relevant to the
decision.
• It contains the various conditions that apply to the situation the table is modeling.
• Action stubs
The part of a decision table that lists the actions that result for a given set
of conditions.
• Rules
The part of a decision table that specifies which actions are to be followed
for a given set of conditions.
Procedures of constructing decision tables
1. Name the conditions and the values that each condition can assume.
• Determine all of the conditions that are relevant to your problem and then determine all of the values each
condition can take
2. Name all possible actions that can occur.
• The purpose of creating decision tables is to determine the proper course of action given a particular set of
conditions.
3. List all possible rules.
• When you first create a decision table, you have to create an exhaustive set of rules. Every
possible combination of conditions must be represented.
4. Define the actions for each rule.
• Now that all possible rules have been identified, provide an action for each rule.
5. Simplify the decision table.
• Make the decision table as simple as possible by removing any rules with impossible actions.
Conceptual data modelling
• In the previous parts, you learned how to show data store (data at rest),
in a DFD.
• But the natural structure of data was not shown.
• DFDs use CASEs, and various processing logic techniques show:
• How, where and when data are used or changed in an IS, but these techniques
do not show:
• Definitions, structure and relationship within the data.
• Data modelling develops these missing, and crucial, descriptive pieces
of a system.
Why data model is important?
• systems developers believe that a data model is the most important part of the
statement of information system requirements.
• This belief is based on the following reasons.
• First, the characteristics of data captured during data modeling are crucial in the design of
databases, programs, computer screens, and printed reports.
• Second, data, not processes, are the most complex aspects of many modern information
systems and hence require a central role in structuring system requirements
• Third, the characteristics about data (e.g., length, format, and relationships with other data)
are reasonably permanent and have significant similarity for different organizations in the
same business.
Conceptual data modelling
• A conceptual data model is a representation of organizational data.
• Purpose - to show as many rules about the meaning and interrelationships
among data as are possible
• A conceptual data model is
• A detailed model that captures the overall structure of organizational data that
is independent of any database management system or other
implementation considerations.
• Done in parallel with other requirement analysis and structuring
steps during system analysis.
The relationship between data modelling and the
SDLC
• Enterprise –wide data model (E-R with only entities)
• Conceptual data model (E-R with only entities for specific project)

Planning

• Conceptual data models


• Data model Maintenan
Analysis
ce (E-R with attributes)
evolution

• Database and file Implemen • Logical data model (relational)


Design
definitions (DBMS- tation and physical file and database
specific code) design (file organizations)
Deliverables and outcomes
• The primary deliverable from the conceptual data modeling step
within the analysis phase is an E-R diagram.
E-R diagram (ERD)
• The most common format used for data modeling is entity relationship (E-R)
diagramming.
• An Entity-Relationship (ER) diagram provides a graphical model of the things that
the organization deals with (entities) and how these things are related to one
another (relationships).
• An ER diagram is a high-level, logical model used by both end users and database
designers to document the data requirements of an organization.
• The model is classified as “high-level” because it does not require detailed
information about the data.
• It is called a “logical model” because it provides a conceptual understanding of
the data – opposite of physical model – physical definition of data in data store
Entity-relationship data model (E-R model)

• 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.
• An E-R model is normally expressed as an entity-relationship diagram
(E-R diagram), which is a graphical representation of an E-R model.
introduction to E-R Modelling

• The basic E-R modeling notation uses three main constructs:


• Data entities,
• Relationships, and
• Their associated attributes.
• Several different E-R notations exist, and many CASE and E-R drawing
programs support multiple notations.
• For simplicity, we have adopted one common notation for this study; this
notation uses the so-called Crow’s foot symbols and places data attribute
names within entity rectangles.
Symbols and definitions of ERD

Entity Attributes Relationships Key


Attributes

Weak Entity Weak


Multivalued Relationships Composite
Attributes Attributes
Entities
• Entities are things (tangible or intangible). Like a person, place, object,
event, meeting, purchase, or concept in the user environment about
which the organization wishes to maintain data.
• An entity has its own identity that distinguishes it from each other
entity.
• Some examples of entities follow:
• Person: EMPLOYEE, STUDENT, PATIENT
• Place: STORE, WAREHOUSE, STATE
• Object: MACHINE, BUILDING, AUTOMOBILE, PRODUCT
• Event: SALE, REGISTRATION, RENEWAL
• Concept: ACCOUNT, COURSE, WORK CENTER
Entity type
• There is an important distinction between entity types and entity instances.
• An entity type (sometimes called an entity class) is a collection of entities
that share common properties or characteristics.
• Each entity type in an E-R model is given a name. Because the name represents a
class or set, it is singular. Also, because an entity is an object, 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
Entity instance
• 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 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
Basic E-R notations
Entity types Attributes

Entity name
Identifier
Strong Weak
Partial identifier
Optional
[derived]
Associative
(multivalued)
Composite (…)
Crow’s foot notations

Relationship degrees

Unary
Binary

Ternary
Relationship cardinality

Mandatory Mandatory Optional Optional


one Many one many
Naming and Defining Entity Types
• Clearly naming and defining data, such as entity types, are important tasks during
requirements determination and structuring.
• Guidelines for naming and defining entity types
• 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.
• For example, in a university database, use REGISTRATION for the event of a student
registering for a class rather than STUDENT REGISTRATION FOR CLASS.
Attributes
• Attributes (or fields) represent facts about an entity.
• entity type has a set of attributes associated with it.
• A named property or characteristic of an entity that is of interest to the
organization.
• Following are some typical entity types and associated attributes:
• STUDENT: Student_ID, Student_Name, Home_Address, Phone_Number,
Major
• AUTOMOBILE: Vehicle_ID, Color, Weight, Horsepower
• EMPLOYEE: Employee_ID, Employee_Name, Payroll_Address, Skill
Naming and Defining Attributes
• Often several attributes have approximately the same name and meaning.
• Guidelines for care careful naming of attributes
• An attribute name is a noun (such as Customer_ID, Age, or Product_Minimum_Price).
• An attribute name should be unique.
• No two attributes of the same entity type may have the same name, and it is desirable, for
clarity, that no two attributes across all entity types have the same name.
• To make an attribute name unique and for clarity, each attribute name should follow a
standard format.
• For example, your university may establish Student_GPA, as opposed to
GPA_of_Student, as an example of the standard format for attribute naming.
• Similar attributes of different entity types should use similar but distinguishing names;
• for example, the city of residence for faculty and students should be, respectively,
Faculty_Residence_City_Name and Student_Residence_City_Name
Candidate Keys and identifiers
• Every entity type must have an attribute or set of attributes that
distinguishes one instance from other instances of the same type.

• A candidate key is an attribute (or combination of attributes) that


uniquely identifies each instance of an entity type.
• A candidate key for a STUDENT entity type might be Student_ID.

• Sometimes a combination of attributes is required to identify a unique


entity.
• For example, consider the entity type GAME for a basketball league
Others
• Identifier
A candidate key that has been selected as the unique, identifying characteristic for an entity type.
• Multivalued attribute
An attribute that may take on more than one value for each entity instance
• 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.
Relationship
• Relationship is
An association between the instance of one or more entity types that is of
interest to the organization.
• An association usually means that an event has occurred or that there
exists some natural linkage between entity instances

• Relationships are the glue that holds together the various components
of an E-R model
Conceptual Data Modeling and the e-R Model

• The last section introduced the fundamentals of the E-R data modeling
notation— entities, attributes, and relationships.
• The goal of conceptual data modeling is to capture as much of the
meaning of data as possible.
• The more details (business rules) about data that we can model, the better the
system we can design and build.
• Further, if we can include all these details in a CASE repository, and if
a CASE tool can generate code for data definitions and programs, then
the more we know about data, the more code we can generate
automatically.
Degree of a Relationship
• Degree
The number of entity types that participate in a relationship.

• The degree of a relationship is the number of entity types that


participate in that relationship.
• The three most common relationships in E-R models are
• unary (degree one),
• binary (degree two), and
• ternary (degree three).
Unary relationship
• Also known as recursive relationship
• A relationship between instances of one entity type; also called recursive
relationship.

Manages
Is_married_to
PERSON Employee Team Stands_after

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


Binary relationship
• A relationship between instances of two entity types. This is the most
common type of relationship encountered in data modeling.

PARKING PRODUCT contains


EMPLOYEE is_assigned PRODUCT
SPACE LINE
One-to-many
One-to-one

registered_for COURSE
STUDENT
Many-to-many
Ternary relationship

• A simultaneous relationship among instances of three entity types.

Part

Vendor Warehouse
Supplies

Shipping_mode
_unit_cost
Cardinalities in Relationships
• Suppose there are two entity types, A and B, connected by a relationship.
• Cardinality
the number of instances of entity B that can (or must) be associated with each instance of
entity A.
• Minimum and Maximum Cardinalities
• The minimum cardinality of a relationship is the minimum number of
instances of entity B that may be associated with each instance of entity A.
• When the minimum cardinality of a relationship is one, then we say that entity B is a
mandatory participant in the relationship.
• The maximum cardinality is the maximum number of instances.
• For our example, this maximum is “many” (an unspecified number greater than one).
Business rules and conceptual data modelling

• 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 about the
integrity of those
• 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
Domain
The set of all data types and values that an attribute can assume
• Triggering operation (trigger)
An assertion or rule that governs the validity of data manipulation operations such
as insert, update, and delete; also called a trigger
• A triggering operation normally includes the following components:
1. User rule. A concise statement of the business rule to be enforced by the
triggering operation.
2. Event. The data manipulation operation (insert, delete, or update) that
initiates the operation.
3. Entity name. The name of the entity being accessed and/or modified.
4. Condition. The condition that causes the operation to be triggered.
5. Action. The action taken when the operation is triggered.
Summary of Conceptual Data Modeling with E-R Diagrams

• The purpose of E-R diagramming is to capture the richest possible


understanding of the meaning of data necessary for an information
system or organization.
• Besides the aspects shown in this chapter, there are many other
semantics about data that E-R diagramming can represent.
• Read more @
• Hoffer et al. (2016).
• Hoberman et al. (2012).
End of chapter six

You might also like