Professional Documents
Culture Documents
Chapter Six Sad Part 2
Chapter Six Sad Part 2
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
Entity name
Identifier
Strong Weak
Partial identifier
Optional
[derived]
Associative
(multivalued)
Composite (…)
Crow’s foot notations
Relationship degrees
Unary
Binary
Ternary
Relationship cardinality
• 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.
Manages
Is_married_to
PERSON Employee Team Stands_after
registered_for COURSE
STUDENT
Many-to-many
Ternary relationship
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