Onsite Seminar
Logical Data Modeling for Business Analysts
The purpose of this course is to present data modeling to business analysts in terms and with deliverables to which business analysts can readily relate. While constructs of data modeling will be discussed, they will be discussed from the perspective of the business analysts, not that of the data or database administrator.
Objectives
Upon completion of this course attendees will:
- Be able to participate meaningfully in data modeling sessions
- Understand the significance of the data modeling concepts and terms
- Know what questions facilitate data modeling
- Understand how to read a data model.
Who Should Attend
Business analysts, systems analysts, requirement analysts and project managers
Course Outline
Introduction
What is data modeling and where does it fit into the development life cycle?
- Types of projects
New development
Major maintenance
Minor maintenance
- Levels of development
Planning
Analysis
Design
Construction
- Types of development
Forward engineering
Reverse engineering
The development cycle
Where data modeling fits
- Levels of models
Conceptual models
Logical models
Physical models
- Types of Systems
Standard
Maintenance
RAD
Conversion
- The impact of this on data modeling
- The value of data modeling
- The role of communication
Overview of Business Analysis for Data Modeling A quick overview of what is done in business analysis for data modeling
- What is business analysis?
- What do business analysts do?
- What don’t business analysts do?
- What do data analysts do?
- Forms of Modeling
Object modeling (e.g., data modeling)
Process modeling
Transition modeling
Modeling metrics
Data Modeling
A more detailed description of data modeling. Though the typical constructs of data modeling are presented, the focus is on the impact they have on understanding business requirements. Data modeling will generate questions you cannot think of without data modeling.
- What is data modeling?
- Data modeling and scope
- What are its rules?
- Data modeling is a natural graphic language
- The data model as a mirror of the business
- What
are its constructs?
Entity
Attribute - Relationship
As a two-way street
As enforcement of business rules - Identifier
Simple vs compound
Natural vs business vs surrogate - Multiple relationships
- Recursion
1 : 1
1 : M
M : M - Subtyping
- Derivations
Calculations
Inferences - Types of entities
Dependent
Independent - Integrity and the data model
What is integrity?
Why is it important?
How can you achieve it? - What is the business relevance of these constructs
- Functional dependency
What it is
Why it is important - How do you read a data model?
- Metadata
- Domains
- Subject Areas
- Abstraction
Generalization
Subtyping
Forms of data abstraction - Practices to avoid
Metadata
Several points are key to understanding metadata. Metadata is important, very important. Metadata should be created as the data model is created, not after it is created. Metadata is a big job. Metadata must be published in a medium that is practical for the user.
- What it is
- Types of it
- Why it is important
- The role of the BA in
- How to create it
- How to collect it
- How to publish it
- Naming standards
- Class word standards
Business Rules
Business rules are constraints that the business must observe. This chapter pulls together some formal concepts on business rules.
- Definition of
- Types of
- Structural rules
- Conditions
- Action assertions
- The importance and relevance of metrics
The components of metrics
The metric formula
How to analyze metrics for data and process
Normalization
Normalization is not an unnatural act. It is a simple process for eliminating redundancy from a model. Redundancy has business implications. This chapter will explain normalization in simple terms and illustrate the consequence of redundant data.
- What is normalization?
- Why is it important?
- What are its rules?
- Why is redundancy such an issue?
- What are the rules for non-redundancy?
Using Process Models
You can’t do data modeling only by doing data modeling. So how can you take advantage of process models and other deliverables that business analysts are comfortable with.
- Definition of process modeling
- The meaning of a process
- Components of a process
- What are business processes?
- The structure of a process
Use Case Modeling
Use cases are very popular today. How do use cases fit into the spectrum of data modeling? How can you use a use case model to assist with data modeling? Does data modeling have to be driven primarily by use cases or can you do data modeling in and of itself?
- Introduction to Use Cases
- Overview of Use Cases
- Defining Scope
Use Case Modeling
Basic Use Case Definition
Scenarios
Detailed Use Case Definition
Refining Use Cases
Use Cases and Other Forms of Modeling
State Transition Modeling
There are three ways to model any phenomenon: the object that it consists of; the processes that it does; the changes in state that it experiences. This chapter deals with the third of these and how this relates to data modeling.
- Definition
- Application of state transition modeling
- Components
- Rules for state transition modeling
- Example of state transition modeling
Information Gathering
A formal consolidation of ways to do information gathering.
- Interviews
- Facilitated sessions
- Other forms of information gathering
- Forms of Information Discovery
Event analysis
Stakeholder analysis
Process analysis
Object analysis
Interviews
Facilitated sessions
Rapid Application Development (RAD)
What is RAD and how can this assist with stable data models?
- Definition of RAD
- Characteristics of RAD
- Types of prototypes
- Applicability of RAD
Interaction Analysis
Validating that data models are stable is as important as doing the model in
the first place. How can you do this validation? Are some forms better than
others? Which ones are more business oriented?
- Definition of interaction analysis
- Methods of performing interaction analysis
- Applicability of each method
- The use of the CRUD matrix
- The use of data usage maps
- The use of views analysis
Duration
3 days
Course Format
Lecture, group discussion, exercises
Instructor
Tom Haughey
To request a quote for this in-house seminar
Please call (973)379-7212 or email info@debtechint.com
Return to Onsite Seminars Table of Contents
