Techniques BABOK Guide v3, 10.15
Data Modelling
In short A data model describes the things a business keeps information about, what it records about each, and how they relate. It gives business experts and developers a shared structure to check requirements against, and it often uncovers requirements nobody had mentioned.
Based on: IIBA, BABOK® Guide v3, technique 10.15 “Data Modelling”; D. Paul, D. Yeates, J. Cadle (eds.), Business Analysis (BCS), 2nd ed., ch. 11; A. Belin, UML for IT business analysts, training slides (Luxoft, 2005); business analysis training materials.
On this page
What it is#
The BABOK Guide describes data models at three levels:
- Conceptual — the business view: the main entities and relationships, in business words.
- Logical — adds attributes, keys and normalization rules that keep the data consistent.
- Physical — how a specific database will store it. This is usually design work for the technical team.
The building blocks are entities (or classes in UML): real or abstract things with attributes. Attributes are single facts about an entity, each with a name, description, type and allowed values; details go into the data dictionary and value rules into business rules. Relationships (associations) connect entities and state cardinality at both ends: zero or more, one or more, exactly one, a range. Models can also show generalization, composition and aggregation, plus metadata: what an entity represents, when and why it changes, who uses it, and security or privacy limits.
ER diagrams, as the BCS book presents them#
The BCS book uses an entity-relationship notation with these conventions:
- An entity is a box named with a singular noun. Distinguish the entity type (Bike) from an occurrence (one particular bike). A key is the attribute or attributes that identify one occurrence.
- A relationship is a line that should read as a sentence in both directions.
- A crow’s foot at one end means “many”; a plain end means “one”.
- A solid line half means “must”; a dashed half means “may”. This shows whether each side can exist without the other.
- One-to-one relationships are often a sign that two entities should be merged.
- Many-to-many relationships are resolved into two one-to-many relationships through a link entity, which holds facts about the relationship itself (dates, quantities). Name it with a noun form of the original verb.
- An exclusivity arc shows that an occurrence takes part in only one of several relationships.
UML class models#
In the BCS book’s class notation, a class box has three compartments: name, attributes and operations. Associations carry multiplicity written as numbers or ranges (1, *, 0..1). An association class holds data about the link itself. Generalization lets specialized classes inherit shared attributes and operations from a general class.
Belin adds a business analyst’s view of two concepts developers often own:
- Aggregation — a whole–part relationship where a part can belong to several wholes at once, such as a product listed in several catalogs. Model it, then state which rules apply to the whole and which to the parts.
- Polymorphism — define an operation once on the general class; a subtype that does it differently gets its own version. You then avoid writing “if type X do this, if type Y do that” in requirements, and new subtypes fit in later.
When to use it#
Use a data model when the solution stores and reuses information, when you integrate or migrate data, or when stakeholders disagree about what information exists. The BABOK Guide places it in Specify and Model Requirements.
Start with a concept model or glossary if the vocabulary is still unsettled. Expect that readers need to learn the notation, and that a full model can go beyond what any single stakeholder knows, so review parts with the right experts.
How to do it#
- Find candidate entities in nouns from requirements, forms, reports and the glossary.
- Draw relationships and write each as two sentences: “Each customer may make one or more bookings. Each booking must be made by exactly one customer.”
- Set cardinality and optionality for both ends.
- Resolve many-to-many relationships with link entities and give them attributes.
- Add key attributes, then the rest; push definitions to the data dictionary.
- Look for generalization where several entities share most attributes.
- Validate by reading the sentences aloud with business experts and walking real examples through the model.
- Hand over the logical model to designers; stay involved when physical choices affect business rules.
Example#
The Workshop (a fictional chain of bike-repair workshops) models its booking and repair data:
View as text
Customer 1 ---- 0..* Booking each customer may make many bookings Workshop 1 ---- 0..* Booking each booking is at exactly one workshop Booking 1 ---- 0..1 Repair Order a booking may become one repair order Mechanic 1 ---- 0..* Repair Order Repair Order 1 ---- 1..* Part Usage 0..* ---- 1 Spare Part Supplier 1 ---- 0..* Spare Part
The analyst first drew “repair order uses spare part” as many-to-many. Resolving it into the link entity Part Usage (from the verb “use”) surfaced new attributes: quantity, price charged, and whether the part was under warranty. That became a new reporting requirement for the owner.
For bikes, a general class Bike (frame number, brand, owner) has a specialization E-Bike with battery type. The operation estimate repair time is defined once on Bike; E-Bike has its own version because battery checks add time. The requirement stays one sentence, not a list of cases.
Common mistakes#
- Designing tables too early → stay conceptual or logical until the business structure is agreed.
- Plural or vague entity names (“Data”, “Records”) → use singular business nouns.
- Repeating groups inside an entity (supplier name on every part) → make a separate entity and relate it.
- Missing optionality → decide “must” or “may” for each end; this is where many business rules hide.
- Leaving many-to-many unresolved → add a link entity and ask what you need to know about the link.
- Showing only current state → ask whether history matters (status changes, price changes).
- Skipping business review → read relationships aloud; experts can check sentences even if they cannot read the notation.
Checklist#
- Entities have singular business names and definitions.
- Every relationship reads correctly in both directions.
- Cardinality and optionality are set at both ends.
- Many-to-many relationships are resolved with link entities.
- Key attributes are identified; details are in the data dictionary.
- Generalizations are used where subtypes share most attributes.
- Business experts have validated the model with real examples.
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015, technique 10.15 “Data Modelling”.
- D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010, ch. 11 (ER diagrams and class models).
- A. Belin. Business Analysis: The Initiation Phase (UML for IT business analysts), training slides. Luxoft, 2005 (aggregation and polymorphism from the analyst’s point of view).
- Business analysis training materials (Requirements Analysis and Design Definition module).