Study guide
6.7 Data Modeling & Process Modeling Techniques
CBAP Certified Business Analysis Professional Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Introduction & BACCM Framework
1.1 CBAP Exam Structure, Eligibility & Study Plan 1.2 The Business Analysis Core Concept Model (BACCM) 1.3 Key Concepts, Terms & Requirements Classification 1.4 Business Analysis Governance & Stakeholder Engagement Principles
2 Chapter 2: Business Analysis Planning and Monitoring
2.1 Plan Business Analysis Approach 2.2 Plan Stakeholder Engagement 2.3 Plan Business Analysis Governance 2.4 Plan Business Analysis Information Management 2.5 Identify Business Analysis Performance Improvements
3 Chapter 3: Elicitation and Collaboration
3.1 Prepare for Elicitation 3.2 Conduct Elicitation 3.3 Confirm Elicitation Results 3.4 Communicate Business Analysis Information 3.5 Manage Stakeholder Collaboration
4 Chapter 4: Requirements Life Cycle Management
4.1 Trace Requirements 4.2 Maintain Requirements 4.3 Prioritize Requirements 4.4 Assess Requirements Changes 4.5 Approve Requirements
5 Chapter 5: Strategy Analysis
5.1 Analyze Current State 5.2 Define Future State 5.3 Assess Risks 5.4 Define Change Strategy 5.5 Business Case Development & Financial Analysis
6 Chapter 6: Requirements Analysis and Design Definition
6.1 Specify and Model Requirements 6.2 Verify Requirements 6.3 Validate Requirements 6.4 Define Requirements Architecture 6.5 Define Design Options 6.6 Analyze Potential Value and Recommend Solution 6.7 Data Modeling & Process Modeling Techniques 6.8 Use Cases, User Stories & Acceptance Criteria Definition 6.9 Non-Functional Requirements & Solution Constraints
7 Chapter 7: Solution Evaluation
7.1 Measure Solution Performance 7.2 Analyze Performance Measures 7.3 Assess Solution Limitations 7.4 Assess Enterprise Limitations 7.5 Recommend Actions to Increase Solution Value
8 Chapter 8: Underlying Competencies, Techniques & Perspectives
8.1 Analytical Thinking, Problem Solving & Business Knowledge 8.2 Behavioral Characteristics & Interaction Skills 8.3 Core BABOK Techniques Master Review 8.4 Business Analysis Perspectives
6.7 Data Modeling & Process Modeling Techniques
Key Takeaways Explain This Topic AI
Data modeling progresses across Conceptual (business domain concepts), Logical (attributes and normalized entities), and Physical (database-specific schemas) levels.
Entity Relationship Diagrams (ERDs) define domain entities, attributes, primary/foreign keys, and cardinalities (1:1, 1:N, M:N).
Data Flow Diagrams (DFDs) decompose data transformations hierarchically across Context Level (Level 0), System Overview (Level 1), and Process Decomposition (Level 2).
BPMN 2.0 provides an international standard notation for process modeling using events, activities, gateways, sequence flows, pools, and swimlanes.
Selecting the correct modeling notation ensures clear communication between non-technical business stakeholders and software database engineers.
Last updated: August 2026
- 6.7 Data Modeling & Process Modeling Techniques
- Data Modeling Abstraction Levels
Data modeling structures an enterprise's information assets to support decision-making, transactional processing, and system architecture. BABOK® Guide v3 highlights three distinct levels of data modeling abstraction, each serving a specific stakeholder perspective:
Modeling Abstraction Level Primary Audience Key Components Included Technical Focus & Modeling Target
Conceptual Data Model Business Executives, Domain SMEs High-level domain concepts, major business entities, and business relationships. Defines business domain scope and vocabulary. Independent of software, databases, or attributes.
Logical Data Model Business Analysts, System Architects Normalized entities, attributes, primary/foreign keys, domain rules, and explicit cardinalities. Fully articulates data structures without detailing database vendor engine implementation.
Physical Data Model Database Administrators (DBAs), Developers Database tables, column data types, indexes, constraints, triggers, and storage partitioning. Specifies exact physical database implementation (e.g., PostgreSQL, Oracle, Snowflake schema).
Entity Relationship Diagrams (ERDs) & Cardinality Notations
An Entity Relationship Diagram (ERD) visualizes structural data entities and their logical associations. BAs must master cardinality notation to capture business rules precisely:
Entities: Represent discrete business concepts (e.g., Customer , Order , Invoice , Product ).
Attributes: Properties describing an entity (e.g., Customer_ID , Email_Address , Credit_Limit ).
Relationships & Cardinality: Define numerical constraints between entity instances:
One-to-One (1:1): One instance of Entity A connects to exactly one instance of Entity B (e.g., Employee to Corporate Passport ).
One-to-Many (1:N): One instance of Entity A connects to multiple instances of Entity B (e.g., Customer to Sales Orders ).
Many-to-Many (M:N): Multiple instances of Entity A connect to multiple instances of Entity B (e.g., Student to Course Enrolments ). M:N relationships must be resolved into associative entities in Logical ERDs. ERD CARDINALITY NOTATION TAXONOMY
- ┌───────────────────┬───────────────────┬───────────────────┬───────────────────┐
- │ EXACTLY ONE (1) │ ZERO OR ONE (0..1)│ ONE OR MORE (1..N)│ ZERO OR MORE (0..N)│
- ├───────────────────┼───────────────────┼───────────────────┼───────────────────┤
- │ ───┼──┼─── │ ───O──┼─── │ ───┼──<─── │ ───O──<─── │
- └───────────────────┴───────────────────┴───────────────────┴───────────────────┘
- Data Flow Diagrams (DFDs): Hierarchical Decomposition
Unlike process flows which show temporal sequence (when things happen), Data Flow Diagrams (DFDs) depict functional data transformations (how data moves and changes). DFDs use four standard symbols: External Entities (Squares), Processes (Rounded Rectangles/Circles), Data Stores (Open Rectangles), and Data Flows (Arrows).
DFDs decompose hierarchically across three standard levels:
Context Diagram (Level 0): High-level view showing the entire system as a single process node connected to external entities (sinks/sources).
Level 1 DFD: Decomposes the single system process into major sub-processes, primary data stores, and internal data flow pipelines.
Level 2 DFD: Further decomposes a specific Level 1 sub-process into detailed functional data transformation steps.
Business Process Model and Notation (BPMN 2.0) Standards
BPMN 2.0 is the global ISO standard (ISO/IEC 19510) for modeling operational workflows. Senior BAs must apply precise BPMN symbols:
BPMN Symbol Category Graphic Representation Operational Execution Standard
Events Circles (Single line = Start, Double line = Intermediate, Thick line = End) Triggers process execution (e.g., Message Received , Timer Expired , Error Thrown ).
Activities / Tasks Rounded Rectangles Work performed within a process. Sub-processes feature a [+] expand symbol.
Gateways Diamonds Controls process branching: Exclusive (X) = OR (one path), Inclusive (O) = AND/OR (multiple paths), Parallel (+) = AND (all paths concurrently).
Swimlanes & Pools Rectangular Enclosures Pools represent distinct organizations or systems. Swimlanes represent internal roles/departments.
Practical Example: Modeling an Order Processing System
A senior BA models an online retail order flow using both ERD and BPMN 2.0:
ERD Analysis: The BA defines a 1:N cardinality between Customer and Order , and resolves an M:N relationship between Order and Product by introducing an associative entity called OrderLineItem .
BPMN 2.0 Process: The process opens with a Start Event ( Order Submitted ), branches via a Parallel Gateway (+) to trigger Inventory Allocation and Payment Processing concurrently, and rejoins at an Exclusive Gateway (X) to evaluate payment success before reaching an End Event.
CBAP Exam Strategy & Distractor Analysis
DFD vs. Process Flow Distractor: Remember that DFDs do not show decision timing, loops, or control flows . If an exam question describes temporal branching ("If payment fails, wait 3 days"), select a Process Model (BPMN) rather than a DFD.
Exclusive vs. Parallel Gateways: Exclusive Gateways (X) select exactly one output path based on conditional logic. Parallel Gateways (+) execute all outgoing paths simultaneously without condition checking.
Logical ERD Resolves M:N Relationships: On the exam, remember that a Logical ERD cannot leave M:N relationships unresolved; they must be broken into two 1:N relationships via an associative join entity.