In the simplest terms, a logical data model is a visual representation of the business rules and requirements covering the universe-of-discourse for a given solution or enterprise, along with some textual support. Keeping this in mind, the logical data model is a metaphor describing the piece of the organization under analysis. A first step in composing a logical data model is listing the entities, or business objects, that are within the scope of the solution in focus. These entities are the important nouns for the elements that exist or need to be created. The list can start off hitting the obvious items, others can be added later. Next, start working through the interrelationships of the business objects. Objects relate in a limited array of possibilities. There is a low end and a high end of occurrences; there is optional vs. mandatory—zero, one, only one, many. As an example, a CUSTOMER has zero to many ORDERs. Make sure you think through each direction. Flipping our CUSTOMER and ORDER gives us the idea that an ORDER has one and only one CUSTOMER. Every one of these relationships is a business rule that should be enforced by one’s finished solution.
Progress through every entity and identify the valid possibilities. What does each listed object relate to? Think through every rational relationship and make decisions. And again, make sure you address each direction of a relationship. As the pieces start taking shape, you may determine a few more objects that need to join the party. While the business objects and their relationships are taking shape, dig deeper into the nature of each object. What pieces of information, or attributes, need to exist for a given entity? A CUSTOMER entity might need a First Name, Last Name…. These attributes are additional business rules, such as “A customer must have a Last Name; A customer might have a First Name” and so forth. Of those attributes, decide which ones may serve to uniquely identify an instance of each object. Often this labeling is straight-forward and obvious, like using a “Customer Number” or an “Email Address” or whatever may be most relevant to your organization for the CUSTOMER object. And yet again, these choices too are business rules, “A customer is uniquely identified by a Customer Number.”
Is your model good or bad? Does it successfully convey an understanding of the focused-on-area? Or at least does it provide an understanding of the area given a certain perspective? The success or failure of your data modeling efforts is directly linked to this rationalizing of the business. A data model that accurately describes the organization will be considered good and fit-for-use. At the highest level, a good logical data model should make sense to business personnel. The reason for this connection is that the model involves logic, and not technology. Rational thought is all that is needed; no expertise in a specific technology or tool is required. If business personnel cannot relate, then perhaps the data model might need to be refined and simplified.
Building a logical data model can be done quickly. The steps for composing that logical data model are as set forward above. What are the objects of significance? How do they relate to each other? How does one identify an instance of each object? What things need to be known about those objects? What does EVERYTHING mean? As the answers to these questions are unraveled, the data model arises. Your data model is a creature built of logic and as such is something that can be easily digested by business personnel. Each and every item, be it entity, attribute, or relationship, is instantiating and riddled with business rules. And as one should expect, the business rules rule.