Study guide
8.2 Data Flow Diagrams & Value Chains
DAMA Certified Data Management Professional CDMP
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & DMBoK Framework
1.1 CDMP Exam Details & Strategy 1.2 The DMBoK Framework 1.3 Data Management Organization & Roles
2 Chapter 2: Data Governance (Part A)
2.1 Data Governance Principles & Drivers 2.2 Operating Models & Structures 2.3 Policies, Standards, and Procedures
3 Chapter 2: Data Governance (Part B)
2.4 Data Stewardship 2.5 Governance Metrics & Implementation
4 Chapter 3: Data Modeling and Design (Part A)
Section 3.1: Conceptual, Logical, and Physical Models Section 3.2: ERD Notations & Relational Modeling Section 3.3: Normalization
5 Chapter 3: Data Modeling and Design (Part B)
3.4 Dimensional Modeling 3.5 Naming Standards & Modeling Best Practices
6 Chapter 4: Data Quality (Part A)
Section 4.1: Data Quality Dimensions Section 4.2: Data Quality Policy & Rules Section 4.3: DMAIC & DQ Improvement Lifecycle
7 Chapter 4: Data Quality (Part B)
4.4 Root-Cause Analysis & Remediation 4.5 DQ Metrics, Tools, and Reporting
8 Chapter 5: Metadata Management (Part A)
5.1 Business, Technical, and Operational Metadata 5.2 Metadata Lineage & Impact Analysis 5.3 Repository Architectures
9 Chapter 5: Metadata Management (Part B)
5.4 Standards and Semantics 5.5 Metadata Governance & Integration
10 Chapter 6: Master and Reference Data Management
6.1 Master vs Reference Data 6.2 MDM Repository Architectures 6.3 Match-Merge & Identity Resolution 6.4 Reference Data Governance & Standards
11 Chapter 7: Data Warehousing and Business Intelligence
7.1 DW Architectures: Inmon vs Kimball 7.2 Data Warehousing Storage & Load Patterns 7.3 BI Delivery & OLAP 7.4 Data Marts & Enterprise Data Warehouses
12 Chapter 8: Data Architecture
8.1 Enterprise Data Architecture & Zachman Framework 8.2 Data Flow Diagrams & Value Chains 8.3 Architecture Frameworks & Standards
13 Chapter 9: Document and Content Management
9.1 Records Management & ECM 9.2 Retention, Disposal, and E-Discovery 9.3 ARMA GARP Principles & Taxonomies
14 Chapter 10: Data Integration and Interoperability
Section 10.1: Integration Patterns & Technologies Section 10.2: Replication & Virtualization Section 10.3: Canonical Models & Integration Standards
15 Chapter 11: Data Security
Section 11.1: Security Principles: CIA Triad & Privacy Section 11.2: Access Control & Encryption Section 11.3: Security Regulations & Standards
16 Chapter 12: Data Storage and Operations
Section 12.1: Database Technologies & DBA Roles Section 12.2: Backup, Recovery, and High Availability Section 12.3: Performance Tuning & Operations
17 Chapter 13: Big Data and Data Science
13.1 Big Data V's & Technologies
18 Chapter 14: Data Ethics
14.1 DMBoK Data Ethics Framework
19 Chapter 15: Data Management Process and Maturity
15.1 Maturity Assessment Frameworks
8.2 Data Flow Diagrams & Value Chains
Key Takeaways Explain This Topic AI
Data lineage operates at two levels: horizontal (system-to-system movement) and vertical (conceptual-to-physical alignment).
Data Flow Diagrams (DFDs) capture data movement but omit control logic like loops, execution timing, or decisions.
Gane-Sarson notation uses rounded rectangles for processes and open-ended rectangles for data stores, whereas Yourdon-DeMarco uses circles and parallel lines.
Level 0 Context Diagrams define system boundaries and external entities, deliberately omitting database structures and internal data stores.
Last updated: July 2026
System-to-System Lineage
Data lineage tracks the origin, movement, transformations, and destinations of data as it flows across the enterprise. It is a critical component of metadata management and data architecture. Lineage can be viewed at different levels of granularity:
System-to-System Lineage (Horizontal Lineage) : Shows how data moves between different software applications, operational databases, file stores, and message queues. For example, data originating in an ERP system flows to an operational data store (ODS), then to an Enterprise Data Warehouse (EDW), and finally to a Power BI report.
Column-Level Lineage (Vertical/Detailed Lineage) : Maps individual attributes or columns from source systems through transformations to target tables.
Lineage is essential for several key enterprise capabilities:
Regulatory Compliance : Meeting guidelines like BCBS 239 (Basel Committee on Banking Supervision) or GDPR (General Data Protection Regulation) by proving the origin, transformations, and processing path of reporting data.
Impact Analysis : Understanding which downstream reports, systems, or databases will break if a source database column or structure is modified.
Root Cause Analysis : Troubleshooting data quality issues in a dashboard or report by tracing the calculations and data pathways back to the original entry point.
Data Flow Diagrams (DFDs)
A Data Flow Diagram (DFD) is a graphical representation of the path of data through an information system. It models how data is input, transformed, stored, and output. DFDs do not show control flow (loops, branches, or conditional decisions); they focus purely on the flow of data.
DFD Components
Every DFD consists of four basic symbols:
Processes : Tasks or transformations that manipulate data (e.g., validate card, calculate tax).
Data Stores : Repositories where data is held (e.g., customer database, log file).
External Entities (Sources/Sinks) : Actors or systems outside the scope of the diagram that send or receive data (e.g., Customer, Payment Gateway).
Data Flows : Pipelines through which data travels (indicated by arrows).
Notational Standards: Gane-Sarson vs. Yourdon-DeMarco
The CDMP exam frequently tests the differences between Gane-Sarson and Yourdon-DeMarco notations. Below is a detailed comparison of their symbols:
DFD Component Gane-Sarson Notation Yourdon-DeMarco Notation
Process Rounded rectangle, often divided into three sections (process number, description, physical location) Circle or bubble
Data Store Open-ended rectangle (two horizontal parallel lines closed on the left, open on the right) Two simple parallel horizontal lines
- External Entity Shaded square or double-lined square Flat rectangle
- Data Flow Directed solid line arrow Directed solid line arrow
- Levels of DFDs
DFDs are designed hierarchically to represent different levels of abstraction:
Level 0 (Context Diagram) : The highest level. It models the entire system as a single process bubble, showing only external entities and the data flows entering or leaving the system boundary. Important: Data stores are typically not shown at Level 0, as they are considered internal to the system.
Level 1 : Decomposes the single Level 0 process into major sub-processes, revealing internal data stores and the data flows between them.
Level 2 (and lower) : Explodes Level 1 processes into more detailed sub-processes for software development and detailed architectural design.
Mapping Business Value Chains
A value chain , a concept popularized by Michael Porter, is a series of business activities that add value to a product or service. Data is the key enablement mechanism across the value chain. Data architects map data flows directly to business value chains to ensure that IT systems support core business strategies.
Value chain mapping involves:
Identifying Primary Activities : Mapping data flows that support inbound logistics, operations, outbound logistics, marketing, and customer service.
Identifying Support Activities : Mapping data flows for procurement, human resources, technology development, and infrastructure.
Data Product Maps : Visualizing data products as they move through value streams. A data product is a reusable, high-quality data asset designed for specific business applications (e.g., a "Customer 360" data product).
CRUD Matrix : Mapping which business processes Create, Read, Update, or Delete (CRUD) specific data entities. This helps align processes with data architecture.
Worked Example: Customer Order Lifecycle DFD
To illustrate how data flow diagrams function within a business value chain, consider the following order-to-cash lifecycle trace:
Context Diagram (Level 0) : A single process bubble "Order Management System". The external entities are the "Customer" (who sends Order Request, receives Invoice) and "Credit Bureau" (which receives Verification Request, sends Credit Score). No databases are shown at this stage because the focus is solely on the boundaries of the system and its external interactions.
Level 1 DFD :
The "Customer" sends the Order Request flow to Process 1.1: "Verify Order Details" (rounded rectangle in Gane-Sarson).
Process 1.1 checks customer credit by sending data to the Credit Bureau, receives the score, and then passes valid order details to Process 1.2: "Authorize Payment".
Process 1.2 writes transaction details to the "Transactions DB" (open-ended rectangle data store) and forwards authorization status to Process 1.3: "Fulfill Order".
Process 1.3 reads inventory status from the "Inventory DB" and sends a shipping request to the Warehouse external entity.
CRUD Matrix Integration : In this scenario, Process 1.1 performs a "Read" on Customer Data, Process 1.2 performs a "Create" on Transaction Data, and Process 1.3 performs an "Update" on Inventory Data. This maps directly to the enterprise's data governance policies regarding CRUD permissions.
Exam Trap: Context Diagrams and Data Stores
A recurring exam trap involves the Context Diagram (Level 0 DFD). Questions may ask if a database should be shown on a Context Diagram. The answer is no . Databases and data stores are internal components of the system boundary. The Context Diagram only models the system as a whole and its interactions with external entities. Showing internal data stores violates Level 0 design rules. Another common trap is confusing Gane-Sarson's rounded rectangle process symbol with Yourdon-DeMarco's circle.