6.7 Data Modeling & Process Modeling Techniques
Key Takeaways
- 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.
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.
A business analyst is modeling an online university registration system and establishes that a Student can enroll in multiple Courses, and each Course can contain multiple Students. How must this relationship be represented in a Logical Entity Relationship Diagram (ERD)?
During process modeling for an automated claims portal, the BA needs to indicate that when a claim exceeds $50,000, two independent tasks—Conduct Fraud Review AND Perform Financial Audit—must both execute simultaneously before the process can continue. Which BPMN 2.0 gateway symbol should the BA use?
A technical architect asks the BA for a high-level diagram illustrating the entire enterprise core system as a single process box, showing only external data sources, sinks, and boundary data flows. What artifact should the BA provide?
What is the primary conceptual difference between a Data Flow Diagram (DFD) and a BPMN Process Flow Diagram?