Data modelling (BABOK 10.15, spelled data modeling in the US) is the technique for describing the entities of a domain, their attributes and the relationships among them, so that analysts and implementers share one set of meanings [1]. A data model comes at three levels: conceptual, logical and physical [2]. For the CBAP exam, know which level answers which question, who uses it, and how an entity-relationship diagram (ERD) reads.
Last verified: October 2026 (IIBA CBAP page, BABOK Guide v3 technique 10.15 page on IIBA KnowledgeHub, study summaries of 10.15).
What data modelling is in BABOK 10.15
A data model is a description of the things a business keeps information about, what it records about each, and how those things connect. BABOK frames its purpose as providing "a common set of semantics for analysis and implementation" [1]. The full section sits behind an IIBA member login, so the details below are checked against independent study summaries of 10.15 [2].
In practice the model is usually a diagram supported by text descriptions [2]. The diagram shows structure; the text carries definitions and rules.
| Fact | Value |
|---|---|
| BABOK section | 10.15 Data Modelling [1] |
| Model levels | Conceptual, logical, physical [2] |
| Elements | Entities, attributes, relationships, diagrams, metadata [2] |
| Typical diagram | Entity-relationship diagram (ERD) [2, 3] |
| Main task use | Specify and Model Requirements (7.1) |
| CBAP weight of that knowledge area | 30% (Requirements Analysis and Design Definition) [4] |
Why data modelling matters on the CBAP exam
Data modelling matters because it sits in the largest part of the exam. Requirements Analysis and Design Definition carries 30% of the CBAP blueprint, and the exam has 120 scenario-based questions in 210 minutes [4]. Our map of all 50 BABOK techniques by knowledge area shows Data Modelling in task 7.1, next to Data Dictionary, Glossary and Concept Modelling.
The exam rarely asks you to draw a model. It gives a scenario and asks which technique, or which level of model, fits. Typical triggers:
- Two systems store the same customer differently, and the team needs one agreed structure.
- A business sponsor needs to approve scope, and the draft model is full of keys and data types.
- Developers ask how many addresses a customer may have, and nobody has written it down.
If you are preparing, the CBAP exam page has practice questions across all six knowledge areas.
The three levels: conceptual, logical and physical data model
The three levels differ in detail and audience: a conceptual model sets scope in business terms, a logical model adds full structure without technology, and a physical model describes the actual database [2, 3].
| Conceptual | Logical | Physical | |
|---|---|---|---|
| Question it answers | What things does the business care about? | What exactly do we record and how is it structured? | How is the database built? |
| Technology | Independent of any solution or technology [2] | Independent of technology [3, 5] | Specific to a database product |
| Typical content | Major entities and their relationships; scope [3] | Entities, attributes, relationships, cardinality, business names [5] | Tables, columns, data types, keys, indexes |
| Rules applied | Few | Normalisation rules for integrity [2] | Performance, concurrency, security [6] |
| Main users | Sponsors, business stakeholders, BAs | BAs, data architects, developers | Implementation subject matter experts [2] |
| BA role | Builds and validates it | Often builds or co-builds it | Usually reads it, rarely writes it |
Three details trip people up.
- Logical is not physical with fewer columns. One business architect lists what a logical model holds: entities, relationships, cardinality and attributes with business names. Data types and foreign keys are left out "since those are physical design considerations" [5].
- Conceptual is not a concept model. A conceptual data model still talks in entities and relationships. A concept model (10.11) is about business vocabulary and verb wordings (see below).
- The levels can be one model at different depths. Many teams evolve a single diagram from conceptual to logical, then hand it to a database designer.
Data modelling elements: entities, attributes, relationships, diagrams, metadata
BABOK describes a data model through five elements [2].
Entities
An entity is something the organisation needs to keep information about. It can be physical (a vehicle), organisational (a branch), abstract (a policy) or an event (a booking) [2]. In BABOK, the same role can be played by a class or a data object, which is why the definition says "entities, classes or data objects" [1].
Attributes
An attribute is one piece of information that describes an entity, such as a booking date. Each attribute carries a name, its allowed values or meaning, and a description [2]. That list is where data modelling hands over to the data dictionary.
Relationships
A relationship is a business association between two entities, such as customer places booking. Its specification states the minimum and maximum number of occurrences on each side [2]. That pair of numbers is cardinality, which part 2 of this series will cover in depth.
Diagrams
The usual diagram is the ERD [2]. An ERD is made of entities, relationships and attributes and also shows cardinality [3]. Object-oriented teams draw class diagrams for the same purpose, which is why the BABOK definition also mentions classes [1].
Metadata
Metadata is optional information about the model itself: what each entity represents, when and why it was created or changed, and how it is used [2]. In practice this can be as simple as a version history and a short note per entity.
How to read an ERD: crow's foot basics
Crow's foot is an ERD notation in which each end of a relationship line carries two symbols, one for the minimum and one for the maximum [7]. Peter Chen is credited with ER modelling in the 1970s [3], and the crow's foot symbol traces back to a 1976 paper by Gordon Everest, who first called it the "inverted arrow" [7].
| Symbol | Meaning |
|---|---|
| Empty circle (ring) | Minimum zero: optional [7] |
| Bar across the line | One [7] |
| Three-pronged crow's foot | Many [7] |
The symbol next to the entity is the maximum; the one closer to the middle of the line is the minimum [7]. That gives four standard endings [7, 8]:
| Ending | Reads as | Range |
|---|---|---|
| Bar + bar | One and only one | 1..1 |
| Ring + bar | Zero or one | 0..1 |
| Bar + crow's foot | One or many | 1..N |
| Ring + crow's foot | Zero or many | 0..N |
Read each end from the other entity's side: "one customer places zero or many bookings; each booking belongs to exactly one customer." When both sides say many, the model usually needs an associative entity in between, such as an enrolment record between student and course [8].
A worked example: a physiotherapy clinic
The fastest way to see the three levels is to model one small domain three times. Assume a clinic chain moving bookings from spreadsheets to a new system.
Step 1. Conceptual model with the business. The BA lists nouns from the spreadsheets and staff interviews: patient, therapist, clinic, appointment, treatment plan. The diagram shows only boxes and lines: a patient books appointments, a therapist works at clinics, an appointment follows a treatment plan. The clinic manager can approve this as scope.
Step 2. Logical model with the delivery team. The BA adds attributes and cardinality in business names:
| Entity | Key attributes | Relationship |
|---|---|---|
| Patient | Patient number, name, date of birth, phone | Has zero or many appointments |
| Therapist | Therapist number, name, speciality | Works at one or many clinics |
| Clinic | Clinic code, address | Hosts zero or many appointments |
| Appointment | Date, start time, status | Belongs to one patient, one therapist, one clinic |
| Treatment plan | Diagnosis, planned sessions | Covers one or many appointments |
The therapist-to-clinic link is many-to-many, so the team adds an associative entity, clinic assignment, with the days each therapist works there. No data types, no keys.
Step 3. Physical model by the database designer. Tables, primary and foreign keys, a status code table, and an index on appointment date. The BA reviews it against the logical model to check that nothing was lost, rather than drawing it.
Step 4. Record the details elsewhere. Allowed values for appointment status go into the data dictionary, and the rule "a patient may not hold two appointments at the same time" goes into the business rules catalogue.
Data modelling vs concept modelling vs data dictionary
These three techniques overlap, so the exam likes to mix them up: a concept model fixes the meaning of words, a data model fixes structure, and a data dictionary fixes the details of each data element [6, 8].
| Concept Modelling (10.11) | Data Modelling (10.15) | Data Dictionary (10.12) | |
|---|---|---|---|
| Main question | What do our terms mean? | What do we store and how does it connect? | What exactly is each data element? |
| Core content | Noun and verb concepts | Entities, attributes, relationships | Names, aliases, values, descriptions |
| Audience | Business stakeholders | Requires some IT background [6] | Analysts, developers, testers |
| Typical form | Terms and verb wordings | ERD or class diagram | Table or repository [8] |
Our deep dive on the concept modelling technique (BABOK 10.11) covers the vocabulary side, and the guide to the data dictionary technique (BABOK 10.12) covers element-level detail. A useful exam heuristic: meaning problem, concept model; structure problem, data model; field-definition problem, data dictionary.
Data modelling in real practice
In practice, data modelling appears in thousands of job ads, but only a small share of them are BA roles, and BAs tend to own the conceptual and logical levels while tools generate the physical one.
| Signal | What it shows |
|---|---|
| UK permanent IT job ads citing data modelling, 6 months to 12 October 2026 [9] | 1,863 ads, median salary £70,000; 49 of them (2.63%) titled Business Analyst |
| UK permanent Business Analyst ads, same period [10] | 1,516 ads; SQL in 8.91% and data analysis in 7.65%; data modelling is not among the listed skills |
Practitioner accounts describe a similar split. A BA training site notes that physical models are generated from database software and BAs mostly review them to understand the current state, while BA-level models still have to be built by hand [11]. A BA trainer who leads business-focused ERD sessions adds that most ERDs people see look complicated because they are automated output from physical designs, not abstractions of business concepts [12]. Her practical advice: start from the glossary or nouns in existing documents, sketch on paper, ask "one-to-many or many-to-one?" for each pair, and keep the notation consistent with the organisation [12].
Experts disagree on data modelling
Practitioners agree on the elements, but not on how many levels are worth the effort or who should draw them.
1. The three levels are useful and distinct. Study guides and tool vendors present conceptual, logical and physical as clear steps with different audiences [2, 3, 6]. A business architect defines the logical model as business-named and technology-free [5].
2. The levels are fuzzier than they look. The data modelling professor credited with crow's foot notation argues that the common definitions are "quite fuzzy" and asks whether all data models, even conceptual ones, are in fact logical [7, 13].
3. The logical model often adds little. An agile data methodologist writes that logical data models are rarely used on agile teams and, on traditional teams, "rarely seem to add much value in practice" [14]. He describes conceptual models as the usual way to explore domain concepts with stakeholders, and sees physical models as useful on both agile and traditional teams that use relational databases [14].
4. Data modelling belongs to the business, not only to database design. A 2013 white paper on business-oriented data modelling argues that modelling is often misperceived as a technical discipline for database design. Its remedy: focus on the business before the data, and use techniques suited to nontechnical stakeholders [15]. The BA trainer above makes the same point from project work [12].
5. Modern data teams have stopped modelling, and that is a problem. A data engineering newsletter author writes that in the modern data stack modelling has given way to ad hoc queries because of the spread of agile practices, engineering-led organisations and implementation friction. His conclusion is that it "can't afford to die" [16].
The real dispute is between positions 1 and 3: whether a separate logical model is worth maintaining. The exam follows BABOK and position 1.
Usage considerations for data modelling
Data modelling pays off when a solution stores or exchanges structured data, and it costs the most when it is done at the wrong level for the audience. BABOK lists strengths and limitations for each technique; because the 10.15 text is gated, the points below come from the practitioner sources cited, not from the guide.
- Use it when a solution touches structured data and stakeholders need one consistent vocabulary before development starts [17].
- Match the level to the audience. Business sponsors can approve a conceptual model; a physical diagram full of keys is hard for them to follow [12, 15].
- Do not reverse-engineer and call it analysis. A diagram generated from a database shows the current build, not what the business needs [11, 12].
- Keep it alive. A model nobody maintains drifts from the database and from the business; agree who updates it.
- Pair it with text. The diagram needs definitions and rules beside it [2].
Common misconceptions
- "Data modelling is a developer task." BABOK lists it as a business analysis technique, and the conceptual and logical levels are mostly analysis work [1, 11].
- "An ERD is always physical." An ERD can be drawn at any level; a conceptual ERD shows the major entities with little detail [3, 12].
- "Cardinality is a database detail." Minimum and maximum occurrences are part of the relationship specification [2], and they record business decisions, such as whether an appointment can exist without a patient.
- "The data model replaces the data dictionary." The model shows structure; the dictionary defines each element [8].
Practice Questions
Question 1. A sponsor must approve the scope of a new loyalty programme. The analyst's draft data model shows primary keys, data types and indexes, and the sponsor cannot follow it. What should the analyst do?
A. Add a legend explaining keys and data types B. Present a conceptual data model with major entities and relationships only C. Replace the model with a data dictionary D. Ask the database designer to present the model
Answer: B. The conceptual level is technology-independent and built for scope decisions with business stakeholders [2, 3]. A legend does not fix the wrong level, and a dictionary lists elements without showing scope.
Question 2. Two departments use the word "account" for different things, and every requirements meeting stalls on what it means. Which technique addresses the root cause?
A. Data modelling B. Concept modelling C. Data dictionary D. State modelling
Answer: B. This is a vocabulary problem. Concept modelling organises business terms and their meanings; a data model would inherit the confusion [6].
Question 3. On an ERD, the line between Order and Order Line shows a bar and a bar at the Order end and a ring and a crow's foot at the Order Line end. Which statement is correct?
A. Each order line belongs to zero or many orders B. Each order has exactly one order line C. Each order has zero or many order lines, and each order line belongs to exactly one order D. Each order must have at least one order line
Answer: C. Ring plus crow's foot reads zero or many; bar plus bar reads one and only one [7, 8]. Option D would need a bar, not a ring, as the minimum.
Conclusion: the gap between BABOK data modelling and real BA work
BABOK presents data modelling as one technique with three clean levels; in real work, BAs own the upper levels and tools or data teams own the rest.
| Area | Standard | Reality | Delta |
|---|---|---|---|
| Conceptual model | Technology-free scope model [2] | Built by BAs with stakeholders, often by hand [11, 12] | No gap |
| Logical model | Full structure without technology [2, 5] | Often skipped on agile teams [14] | Under-used |
| Physical model | Used by implementation experts [2] | Generated from database tools; BAs review [11] | Reduced to review |
| Job demand | Core BABOK technique [1] | Few of the ads citing it are BA roles; not among listed BA skills [9, 10] | Under-used |
| Data teams | Common semantics for implementation [1] | Ad hoc queries replace models in some teams [16] | Under-used |
For the exam, learn the three levels, the five elements and the four crow's foot endings as BABOK describes them. For the job, expect to draw conceptual and light logical models with the business, read physical models generated by others, and argue for a model where nobody has one.
Related topics
- Diagrams in practice for business analysts: building a visual knowledge base where data models live next to process models.
- Requirements architecture: how models, including data models, fit together into one structure.
- Definitional vs behavioural business rules: where cardinality rules end and business rules begin.
FAQ
What is the difference between conceptual, logical and physical data models?
A conceptual model shows the main entities and relationships in business terms and is used to agree scope. A logical model adds attributes and cardinality but stays independent of technology. A physical model adds tables, keys and data types for a specific database. In BABOK 10.15, all three are levels of the same technique.
Do business analysts create physical data models?
Usually not. Physical models are typically generated from database tools and owned by designers or developers, and BAs review them to understand the current state. BAs more often build conceptual and logical models with stakeholders.
Is an ERD the same as a data model?
No. An ERD is the usual diagram for a data model, but the model also includes text: definitions, metadata and rules. Teams using object-oriented design may draw a class diagram instead of an ERD.
What does crow's foot notation mean on an ERD?
Each end of a relationship line carries a minimum and a maximum symbol. A ring means zero, a bar means one and the three-pronged foot means many. So ring plus crow's foot reads "zero or many", and bar plus bar reads "one and only one".
Sources
- BABOK Guide v3, 10.15 Data Modelling (IIBA KnowledgeHub)
- BA Techniques: Data Modelling (Fhyzics)
- ER Diagram Tutorial (Lucid)
- Certified Business Analysis Professional (CBAP) (IIBA)
- What information should be included in a logical data model? (Modern Analyst)
- Concept Model vs. Data Model (Adaptive US)
- Crow's Foot Notation (Redgate)
- Process, Data and Non-Functional Requirements Modeling (Open Exam Prep, CCBA guide)
- Data Modelling jobs, UK, 6 months to October 2026 (ITJobsWatch)
- Business Analyst jobs, UK, 6 months to October 2026 (ITJobsWatch)
- What Software Tools Business Analysts Use for Data Modeling (Bridging the Gap)
- How to Create an Entity Relationship Diagram (ERD) (Bridging the Gap)
- Conceptual vs. Logical vs. Physical Data Models (Gordon C. Everest, University of Minnesota)
- Data Modeling 101 (Agile Data)
- Getting the Business into Business-Oriented Data Modeling (TDWI white paper, 2013)
- The Death of Data Modeling, Pt. 1 (Data Products, 2022)
- Modeling and Analysis Techniques (Open Exam Prep, ECBA guide)