MODELING AND IMPLEMENTING FUNCTIONALLY-NORMALIZED PROCESSING TRANSACTIONS
Distintegrated, massively-redundant data creates a massively redundant, and extremely complex amount of application program code. As enterprises use data modeling techniques to build shared, subject-oriented, intelligently-normalized and flexible databases, complementary techniques for designing the automated processes (transactions) have become 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 a programmed transaction can perform on a data structure. Once a Conceptual Data Model is complete, abstracting the necessary Create, Update, and Delete transactions becomes almost trivially quick and easy, and can save substantial amounts of analytical time and effort, and then substantial time and effort in programming and testing. Consider: if an enterprise manages to change its ways, so that it builds a single, shared CUSTOMER database, there really only needs to be a single transaction/program which CREATES a new CUSTOMER in the database. The logic which must be applied to edit and validate the incoming data about the new CUSTOMER must be exactly the same logic (and should be shared by) the UPDATE transactions which will be used to change data about a CUSTOMER when necessary. There only needs to be a single DELETE transaction which will be used to remove a CUSTOMER from the database, and it of course will do whatever logical checks are necessary to ensure that the business rules about retaining a CUSTOMER in the database are properly applied before the DELETE operation can be completed. When an enterprise has CUSTOMER data stored in scores, or hundreds of different and usually disintegrated data stores, the programming to properly Create, Update, and Delete a CUSTOMER from any one of those data stores is invariably redundant, and usually extremely inconsistent; this is the source of most data quality problems, and it easily resolved when single-source, shared data structures are modeled, designed, and built. In other words, cleaning up the redundant, inconsistent data mess also cleans up the redundant, inconsistent application code mess! 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. Disintegrated Application 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 Synchronizing 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 to 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:
RETURN TO TOP OF PAGE