WILLIAM G. SMITH & ASSOCIATES INFORMATION RESOURCE MANAGEMENT SEMINARS AND CONSULTING "CLEANING UP THE WORLD'S DATA MESSES"

MODELING AND IMPLEMENTING NORMALIZED TRANSACTIONS

As enterprises use data modeling techniques to build sharable, subject-oriented, and flexible databases, new complementary techniques for designing the automated processes (transactions) have become apparent, and in fact, mandatory. The same principles which make subject normalization of data so desirable apply equally well to the design of functionally-normalized automated transactions. Normalizing data ensures that the same data is never stored twice (unless intentionally necessary); functional normalization of transactions ensures that the same function is never programmed twice, saving time, effort and cost. It further ensures that when the enterprise desires to change its rules about how something is done, the required re-programming load is unbelieveably quick and inexpensive compared to current dis-integrated, redundant systems. Using these modeling techniques, it is possible to quickly design and build sharable, stable, flexible, non-redundant, complementary, and provably correct automated transactions which represent distinct logical units of work in the business.

This form of modeling is based on the simple "CRUD" principle: Create, Retrieve, Update, and Delete - the four fundamental actions that an automated transaction can perform on a data structure. Once a Conceptual Data Model is complete, abstracting the necessary CRUD transactions becomes almost trivially quick and easy, and can save substantial amounts of time and effort. CRUD-oriented transactions are readily implemented using modern programming languages and client/server divisions of labor. This seminar is the automated-process complement to the Conceptual Data Modeling and Logical/Physical Data Modeling seminars, which are strongly recommended prerequisites. (Also note that we offer a combined seminar (Integrated Process and Data Modeling) which presents data and process modeling in the general-to-specific, but interleaved sequence which is typical in real-life practice.)

TOPICAL OUTLINE

• Introduction to IRM concepts
  • IRM-land vs. Dis-integrated System-land
  • The IRM View
  • The Shared Data Benefit
  • The Famous CRUD Principle
  • The Benefits of CRUD-Oriented Transactions
• Functional Business Modeling overview
  • Purpose, Form, and Content of Functional Business Model
  • Functional Decomposition
  • Information Requirements at Activity Level of Decomposition
  • Functional Model Examples
• Conceptual Data Modeling Overview
  • Purpose, Form, and Content of Conceptual Data Model
  • Entity and Relationship Rules
  • E/R Diagram
  • Modeling States of Entities
  • Definition of Entities and Relationships
• Conceptual Transaction Modeling
  • Purpose, Form, and Content of Conceptual Transaction Model
  • Basic Transaction Types and Purpose of Each
  • Conceptual Transaction Specification Pro Forma
  • Conceptual Transaction Modeling Steps
    • 1. Modeling Create Transactions from the Conceptual Data Model
      • General Rules for Create Transactions
      • Method for Identifying Create boundaries from E/R Diagram
      • Example Create Transaction Specification
    • 2. Modeling Delete Transactions from the Conceptual Data Model
      • General Rules for Delete Transactions
      • Typical Method for Identifying Delete Boundaries from E/R Diagram
      • Example Delete Transaction Specification
    • 3. Modeling Update Transactions from the Conceptual Data Model and Functional Model
      • General Rules for State Update Transactions
      • Abstracting State Updates from Entity State/Transition Diagrams
      • Abstracting Non-state Updates from Functional Model
      • Example Update Transaction Specification
    • 4. Modeling Retrieve Transactions from the Functional and Conceptual Data Models
      • General Rules for Retrieve Transactions
      • Typical Methods for Identifying Retrieve Boundaries from Functional Model and Conceptual Data Model
      • Example Retrieve Transaction Specification
    • 5. Reviewing and Synchronizing the Functional Model, Conceptual Data Model and the Conceptual Transaction Model
• Logical Transaction Modeling
  • Logical Transaction Modeling Definitions
  • Refining Conceptual Transactions to Logical Level of Detail
    • Logical Transaction Specification Pro Forma
  • Formally Specifying Interfaces Between Transactions
    • Interface Definition Pro Forma
  • Formally Specifying Dataviews (Inputs/Outputs) to/from Transactions
    • Dataview Definition Pro Forma
  • Forming, Defining and Normalizing Required Data Elements
    • Data Element Definition Pro Forma
  • Reviewing and Synchronizing the Logical Transaction Model and the Logical Data Model
• Logical Data Modeling Overview
  • Purpose, Form and Content of Logical Data Model
  • Logical Data Modeling Definitions
  • Logical Data Modeling Steps
  • Interleaving Logical Transaction and Logical Data Modeling Steps
• Physical Transaction and Data Modeling
  • General Logical to Physical Transform
  • Physical Modeling Issues
  • Physical Modeling Steps
    • 1. Define Physical Design Objectives and Weights
    • 2. Define Physical Implementation Environment
    • 3. Define First-Cut Physical Data Model
      • General Logical to Physical Data Transform
      • General Logical to Physical Transaction Transform
      • Short Detour into the Realm of Distributed Data and Update
        • Distribution Modeling Steps
        • Effect of Physical Data Distribution on Transaction Specifications
    • 4. Decide Stored vs. Virtual Derived Data and Adjust Models
    • 5. Project Volume and Growth and Adjust Models
    • 6. Define Security and Integrity Requirements and Adjust Models
    • 7. Define Transaction Performance Requirements and Adjust Models
      • Realities of Optimizing Transaction Performance
      • Possible Adjustments to Affect Transaction Performance
    • 8. Define Ad Hoc Retrieval Requirements and Adjust Data Model
    • 9. Assess Alternative Physical Models Against Design Objectives
    • 10. Finalize Physical Data and Transaction Specs
    • 11. Specify Control Transactions
    • 12. Adjust Transactions for Programming Language/Technology-Specifics \
• Workshops
  • Create Transaction Modeling
  • Delete Transaction Modeling
  • State Update Transaction Modeling
  • Non-state Update Transaction Modeling
  • Retreive Transaction Modeling
  • Conceptual -> Logical Transaction Transform

DURATION: 5 days

TARGETED AUDIENCES (recommended maximum number of attendees - 25)

• IS/IRM Management
• Process/Conceptual, Logical, Physical Transaction Modelers, Systems Analysts
• Programmers
• Conceptual, Logical, Physical Data Modelers
• Database Administrators
• Physical Database Designers
• Development Project Managers
• Business persons participating in development projects

PREREQUISITES:

• Conceptual Data Modeling: the Entity/Relationship Model
• Logical and Physical Data Modeling