Data Modeling – Why is that Technique in the BABOK?

 (In my continuing coverage of BABOK® techniques, I plan to comment on all of the general and task-specific techniques. This week’s entry is about data modeling, a technique you may or may not be familiar with, but a sure source of CBAP® exam questions.)

The impetus for this blog comes from having just taught a successful training class in Data Modeling to a mixed groupData Model-Thumbnail of BAs, BI specialists, technical architects, and business SMEs (subject matter experts). What made it successful was not only the learning that took place, but also the students’ willingness and eagerness to apply this technique back on their jobs.

I’ve been doing and teaching data modeling for as long as any business analysis technique. Many organizations I encounter think of data modeling as being technical and not BA work. Of course I feel differently, and have long viewed logical data modeling as business analyst work. The IIBA® agrees by including this technique in the BABOK.

Regardless of how you or your organization categorize Data Modeling (DM), you need to be prepared to answer questions on it for the CBAP exam. Here is a short over view of some Dm essentials:

  • Data models capture the static data requirements of an organization for its ongoing business operations and decision support. It does that by defining and structuring entities, relationships between the entities, and adding detailed attributes into the entities. There is usually ancillary documentation you need to include that doesn’t fit strictly into the model. Two major styles of data models are entity-relationship diagrams (ERDs) and class diagrams.
  • Concepts. Entities are the basic building block of a data model. The BABOK goes a little abstract on us by categorizing these as “concepts.” No one I know of except a textbook refers to entities or classes as concepts. The BABOK does it because an entity could also be represented by a class if you are using UML (Unified Modeling Language). In short, a concept is an entity or class depending on the DM style employed, and the term may appear on an exam question. I’ll use the term “concept” interchangeably with entity and class.
  • Entities/Classes represent the people, places, things, processes, or events within the business. They have multiple instances that turn into rows in a relational database, and attributes, which become columns or fields in a database.
  • Relationships are significant business connections or associations between “concepts” (there – I used the term). Relationships can be “one-to-one,” “one-to-many,” or “many-to-many.” The BOK uses the term “cardinality” to refer to the number of entity elements that are associated, namely one or many. Relationships may also be categorized by being optional or mandatory, such as “zero or one” or “at least one.”
  • Attributes are the detailed facts about the “concept.” An ERD or class diagram typically lists the attribute name, relying on ancillary documentation for specifying domain ranges, the type of data an attribute can hold, and the definition of each attribute.

Here is an example data model, illustrating the terms above, and highlighting the four types of cardinality. Don’t be surprised on the CBAP exam if you are asked to interpret a diagram such as this. That type of question demonstrates the application of a technique, not just understanding the terminology.

 Data Model-Detailed

Data Modeling is an important requirements analysis technique, and one you are likely to be tested on. Make sure you understand this technique for the exam, and then work at applying Data Modeling on the job. I plan to blog about that in the future – after I finish all the BABOK techniques!

Leave a Reply

Your email address will not be published. Required fields are marked *