As disheartening as it may sound to new graduates, even when you leave school never to return, you still must continue to learn. There are always new tasks to comprehend, and new tools to drive. And when one serves as a data modeler, one is always going to be exposed to new data. Fortunately, if one has a good foundation, acquainting with new data can be easily managed. Every new conceptual or logical data model is an opportunity to develop a deeper understanding about another subject area within an organization. One-on-one conversations, group meetings, digging through volumes of documentation that may or may not be accurate, any or all of these paths to knowledge will be engaged and likely repeated. Different organizations can have cultural differences as formidable as any encountered by anthropologists exploring primitive societies. But in learning about new data, the objectives are always the same.
First, one must understand the business objects in scope. Traditionally this is often referred to as listing the important “nouns” associated with the area at hand. Under ideal circumstances this is a trivial task that, if the correct business stakeholders are involved, should only take a few minutes. Do not worry about having a complete list at the start, it will be refined as you go. The next goal is understanding these objects and their interrelationships with each other. This understanding involves agreement among those in the conversation that such statements as, “A STORE has one or more CHECKOUT STATIONs” is true. Then continuing further, gaining a level of consensus on the definitions for what a STORE means, and what a CHECKOUT STATION means, along with similar clarifications on specific items. On occasion, these conversations can expose misunderstandings across an organization. But those possible misunderstandings are more often the exception as it is more likely that agreement is easily obtained. An important part of this conversation should discern what specific data items serve to identify each business object, such as a Store ID, or a Register ID, and so forth. It may even turn out that some objects have multiple identifiers that may be used.
After business object consensus, the next level of detail can be the most challenging, it is fleshing out the details of all the data items in scope. It could be a list of data items that must exist for a dashboard, or it may be that one must pull out the items in scope from a subject matter expert’s mind. Caution must be used if this is handled through interviews because people may try to distract you from your goals. When asking about data items in scope they may discuss all the data items they understand, or they may wish to elaborate in detail about the processes and steps they perform, without identifying if any data will be in scope. Keep bringing attention back to the goal of defining what's in scope. As the data items emerge, each data item must have a home—meaning each item should be functionally dependent on one of the identified business objects. Every item becomes another attribute of one of the business objects. Should we run across a data item that does not belong to one of our business objects, discussion should focus on where it does fit in. New objects may need to be created and discussed in detail just as the initial objects were. When these details are exhausted, one should have a drafted conceptual or logical data model which can be taken forward into working out a physical data model of whatever flavor is the goal, whether it be relational, dimensional, or even data vault. And the effective data modeler will have learned in detail about a new area within the business.