6.7 Data Modeling & Process Modeling Techniques

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:

---

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:

1. Context Diagram (Level 0): High-level view showing the entire system as a single process node connected to external entities (sinks/sources).
2. Level 1 DFD: Decomposes the single system process into major sub-processes, primary data stores, and internal data flow pipelines.
3. 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:

---

Practical Example: Modeling an Order Processing System

A senior BA models an online retail order flow using both ERD and BPMN 2.0:

1. 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.
2. 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.