RML™ Requirements Model 6 - The Business Data Diagram (BDD)

Even if you don't know what it is called, we have all used one of these or something similar to it. You know, the last time you were playing the timed, trivia, board game. If Bob is Joe's uncle, Jessica is Bob's cousin, Paul is Jessica's father, and Joe is Paul's grandfather, what is Paul to Joe? Then you team stares blankly for a few seconds while someone scrambles for a pencil to start charting it out. Chances are you drew a BDD to figure out how those people were related (however poorly drawn the diagram was).

A Business Data Diagram is an essential component of the RML™ tool set. The BDD shows the relationships between entities included in a project, and the cardinalities between these entities. This diagram will look very similar to an Entity Relationship Diagram (ERD) if you are familiar with those, however it is a conceptual data model only, in other words – a BDD does not represent a physical data model (or even the fact that there is a database). We use this name as to not confuse anyone that may be familiar with ERDs, falsely implying a database design. Example included:

Why should you want to use the BDD? Because its fun to play connect the data objects, or more practically, when you have other data models. When you have other models, this is a good way to show the relationships of the data objects. Creating this with the other models also helps you make sure you aren't missing data objects. Be sure to take note of all the 1's and n's in the diagram. These are there to help you understand many-to-many/many-to-one-/one-to-one relationship types. In the example above, it is saying that each customer can have many orders associated, but each order can only relate to one customer.

Be careful to not add fields and other specific details regarding the data. This is not a database schema . That would be designing the system and we don't want to do that. That being said, a database admin could use this diagram to understand the relationships that will need to be supported in the database. If the requirements are not related to this presentation of information, it might be a good idea to skip this diagram.

Once you create this model, for each data object, you can then look at how each object is created, read, updated, deleted, copied, and moved within the system. This will help you identify additional systems that may be involved and use cases to be described. I commonly add these types of diagrams at the start of a high level view of a set of functionality so that the reader can get an idea for the data interactions before they get to the use cases, test cases, etc. that make up the meaningful requirement information.