I really like The Business Data Diagram (BDD), described in RML™ Requirements Model 6 – The Business Data Diagram (BDD), because it gives me a big-picture understanding of the data involved in a system. I’ve found that there are some common mistakes people make when creating these diagrams, so I’m addressing three of them.

Mistake #1:  Modeling Attributes as Separate Objects

I once saw a BDD that showed a User business object that was related one-to-one with business objects for First Name, Last Name, Middle Name, and Date of Birth. All of these were just attributes of the User object.  Whenever you have an object which is only related to one other object in a one-to-one relationship, you should review it to see if you really have a separate object, or just an attribute of an object. Making this decision is a little bit art, but there are some guidelines to help:

• Do the objects exist separately in the real world? If yes, then keep them as separate objects. For example, orders and invoices exist and are processed separately in the real world, so even though they may have a one-to-one relationship, they are separate objects. On the other hand, first name decoupled from the user is usually pretty meaningless. 
• Does the business user think about the objects as separate things? If yes, then you could keep them as separate objects. For example, I once worked on a system which processed orders. Order status was just an attribute of an order. But, the business community thought of it as a standalone entity so strongly that we modeled it separately to support effective communication. 
• Does the object have relationships to other objects which you have not modeled? For large systems, we frequently drill into subject areas and create BDDs for just the subject area; not all system objects are included in the model. For example, we could be looking at a web page for a product family where the product family has a one-to-one relationship with the page, so it appears to simply be an attribute of the page. However, when we look at the whole system, we find out that the product family is part of a product hierarchy which includes product lines and product models. Since it exists as a concept separate from the page, we model it separately.

Mistake #2: Showing Indirect Relationships as Direct Relationships

Understanding whether relationships are direct or indirect demonstrates a deeper understanding of the data dependencies. A relationship is direct when it is dependent upon nothing else to exist—such as I am directly related to my mother. A relationship is indirect when it is dependent upon another relationship to exist, such as I am related to one grandmother through my father and another through my mother. I cannot be related to a grandmother without first being related to a mother or father.

Showing a direct relationship between me and my grandmothers would be misleading. It would imply that this relationship could exist without the relationship to my mother and father. Why does this matter? Someone cutting scope on a family tree system could say “hmm… a person is related to both mother and grandmother, let’s cut the mother relationship for the first release of the software and build it in later.” You have to have the correct relationships to understand the dependencies of the data.

Mistake #3:  Confusing Relationships with the Business Rules that Govern Them

I frequently see people try to use the BDD to model the business rules which govern the relationships of the business objects. Each RML™ model provides a specific slice of information. Other than the cardinality of the relationships, the business rules that govern the relationships are not part of the BDD. 

I recently looked at a BDD for a Monopoly®-style game which included properties, color groups, and houses.  As a refresher: each property is part of a color group. Houses can only be purchased for a property if the player owns all properties in the color group. The BDD related the houses directly to the color group, because of the business rule about when houses may be purchased. But, houses are on properties. They are directly related to properties and indirectly to color groups through the properties. The BDD does not model the business rule about when houses may be purchased, it only shows the relationships between houses and other business objects. 

You just have to accept the limitations of the BDD. Well, mostly accept them—I’ve been known to add a text box to a BDD with “Key Business Rules” where I state the key rules that govern the relationships. I’ve found there’s a strong tendency to want to review the BDD and key rules about the relationships at the same time; providing this extra information actually speeds up the review process.