|
 |
 |
 |
 |
 |
WILLIAM G. SMITH & ASSOCIATES
INFORMATION RESOURCE MANAGEMENT SEMINARS AND CONSULTING
"CLEANING UP THE WORLD'S DATA MESSES"
|
INTEGRATED PROCESS AND DATA MODELING
As enterprises build sharable, subject-oriented, and flexible databases, it has become apparent that the same principles which make normalization of data so desirable apply equally well to the design of automated transactions (processes). Well-normalized data has very robust stability over time, is sharable by all business processes, is easy to maintain, easy to use, and is easy to change when necessary. Functionally-normalized transactions (no two do the same work) exhibit exactly the same benefits. When the data modeling discipline is coupled with its complementary transaction modeling discipline, the results are astonishingly beneficial to the enterprise: databases and programs which are extremely stable, consistent, non-redundant, sharable by all enterprise processes, and quick, easy and inexpensive to change when necessary: in short, the fulfillment of managing Information as an enterprise resource.
This skill-building seminar is the Grandaddy of the WGS&A seminar offerings: a combination of the Conceptual Data Modeling, Logical and Physical Data Modeling and Modeling and Implementing Normalized Transactions seminars, presented in a realistic, completely coordinated and synchronized step-by-step Conceptual, Logical, and Physical Data and Transaction Modeling sequence interleaving process/transaction modeling with data modeling at each level of detail. This is not only the best way to do this work, it also happens to be by far the fastest and cheapest way as well!
TOPICAL OUTLINE
- Introduction to IRM Concepts
- IRM Approach vs. "Dis-integrated Systems" Approach
- Shared Data Concept and its Power
- CRUD Principle; Functionally Normalizing Transactions
- Functional Business Modeling Overview
- Purpose, Form, and Content of Functional Business Model
- Functional Modeling Steps
- Example Functional Model
- Conceptual Data Modeling
- Purpose, Form, and Content of Conceptual Data Model
- Conceptual Data Modeling Steps
- 1. Detecting and qualifying entities
- Rules for Qualifying a Candidate Entity
- Entity Genus
- Example Entities
- 2. Diagramming Entities and Relationships
- E/R Diagram Symbols
- Different E/R Diagram Styles
- Detecting Candidate Relationships
- Rules for Qualifying a Candidate Relationship
- Relationship Naming Conventions
- Cardinality Notations
- Reading the E/R Diagram
- Instance Diagram
- The Normal Forms in the E/R Model
- Modeler's Best-Fit Decisions
- Merging/Synthesising Multiple E/R Diagrams
- Tips and Example Questions for Discovering/Qualifying Entities and Relationships
- Special E/R Constructs
- N-ary relationships
- Recursive Relationship
- Subtype/SupertypeConstruct
- Characteristic/Attributive Entity
- Associative Entity
- Relationship Roles
- Role Entity
- Exclusive/Alternative Relationships
- 3. Analyzing and Defining E/R States
- Multiple Entities vs. States Decision
- Multiple Relationships vs. States Decision
- State/Transition Analysis
- State/Transition Diagram
- State Variations
- General State Rules
- Building a State/Transition Diagram - Questions
- Capturing State Metadata in the Dictionary - Options
- State/Transition Analysis Tips
- Example Questions for State/Transition Analysis
- 4. Fully Defining Entities and Relationships
- Preparing and Presenting Business Issues for Decision
- Entity Definition Pro Forma
- Example Entity Definition
- Primary Key Rules
- Relationship Definition Pro Forma
- Example Relationship Definition
- Recording "In-Betweener" Business Rules
- Example Questions for Writing E/R Definitions
- 5. Reviewing and Stabilizing the E/R Model
- Functional/Conceptual Data Model Cross-Validation
- Stability Review
- Example Questions for Reviewing and Stabilizing Model
- The Meta-E/R (Repository) Model to Support Conceptual Data Modeling
- 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
- Purpose, Form and Content
- Logical Data Modeling Definitions
- Alternative Approaches
- Working Around Your CASE Tool
- Logical Model Diagrams
- Logical Modeling Steps
- 1. Identifying Pertinent Transactions/Dataviews for Analysis
- 2. Analyzing the Transaction/Dataview
- 3. Standardizing and Defining Required Data Elements
- 3.1 Detecting and Understanding Need and Meaning
- 3.2 Determining Entity or Relationship of Residence
- 3.3 Choosing Best Representation
- Rules for Data Elements
- Data Element Types
- Hnadling Derived Data Elements
- Cohesive Data Elements
- Data Elements to Represent States
- 3.4 Fully Defining the Data Element
- Data Element Definition Pro Forma
- Example Data Element Definition
- Data Element Domains and Synonyms
- 3.5 Naming the Data Element
- Example Data Element Naming Standards
- Use of Keyword Glossaries
- 3.6 Checking the Dictionary for Redundancy
- Setting Up the Dictionary for Semantic Search
- 3.7 Documenting New Data Elements in the Dictionary
- Example Logical Modeler's Questions for Data Elements
- 4. Diagramming and Normalizing the Dataview
- Bubblecharting Symbols
- Bubblechart/Logical Structure Rules
- Starting the Bubblechart
- Appending Attributes to the Correct Primary Key
- The Normal Forms
- First Normal Form Examples
- Bubblecharting Notes
- Recursive Relationship in Logical Model
- Multiple Relationships Between Same Entities
- Subtype/Supertype in Logical Model
- Characteristic Entity vs. Subordinate Data Group
- Relationship Roles in Logical Model
- Logical Modeler's Questions for Normalizing Data Elements
- 5. Fully Defining New LDG's, Associatoins, Entities, Relationships
- Logical Data Group Naming convention
- Logical Data Group Definition Pro Forma
- Example Logical Data Group Definition
- Key-to-Key Association Definition Pro Forma
- Example Association Definition
- 6. Verifying the Bubblechart
- Logicdal Modeler's Questions for Verifying
- 7. Synthesizing Bubblechart into Composite Logical Model
- Synthesis Example
- Meta-E/R Model After Synthesis
- 8. Reviewing and Stabilizing the Logical Data Model
- Synchronizing the Logical and E/R Models
- Synchronizing the Logical Data and Transaction Models
- Stability Review at Logical Model Level of Detail
- Logical Modeler's Questions for Reviewing
- Reviewing and synchronizing the Logical Data and Transaction Models
- 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
- Functional Business Modeling
- Detecting and Qualifying Entities
- E/R Diagramming
- Analyzing and Defining Entity States
- Defining Entities and Relationships
- Stability Review
- Modeling Conceptual Create Transactions
- Modeling Conceptual Delete Transactions
- Modeling Conceptual Update Transactions
- Modeling Conceptual Retrieve Transactions
- Logical Modeling of Transactions
- Data Element Discovery, Standardization, Normalization
- Synthesis into Composite Logical Data Model
- First Cut Physical Data Model
- Deciding Stored Derived Data
- Analyzing/Adjusting for Volume and Growth
- Analyzing/Adjusting for Security and Integrity Considerations
- Adjusting for Performance of Selected Critical Transactions
- Adjusting for Ad Hoc Ease of Use
- Designing Control Structures
DURATION: 15 days (do not have to be contiguous - typically done in three one-week sessions)
TARGETED AUDIENCES: (recommended maximum number of attendees - 25)
- IS/IRM Management
- Data Administrators/Data Base Administrators
- Conceptual/Logical/Physical Data Modelers
- Conceptual/Logical Process/Transaction Modelers, Systems Analysts
- Programmers/Analysts
- Development Project Managers
- Business persons participating in development projects
PREREQUISITES: none