Although this Party structure is flexible and, therefore, easily stores data from different areas, there is an ongoing debate as to where to capture the definitions for the terms that are now abstracted. For example, the Customer entity has been replaced in this model with a Role Type Code of "5," which means a Customer. In light of this, I asked the Design Challengers: Where do we capture what a Customer is? More generically, where should we capture the definitions for the concepts we abstracted?
The Response
Four options are available to us to store the definitions for the concepts we abstracted: 1) add a Role Type Definition field, 2) subtype, 3) define through views, and 4) use a data dictionary or metadata repository.
Add Role Type Definition. Some of the instances in Role Type from the model in Figure 1 are listed in Figure 2.
One obvious place to store the customer definition is within this same abstract entity, and to rename Role Type Description to Role Type Name. Then add a new data element called Role Type Definition Text, which will store the definitions for the concepts that have been abstracted. For the terms we abstracted, such as Customer, we now have a place for the definition (see Figure 3).
Sai Koduri, manager, along with a majority of the data management professionals who responded to this challenge, recommend this approach. Sai adds that abstracting the definition in this way allows the definition to be extracted by many different tools (such as Excel or BusinessObjects) and available to end users of the applications.
Subtype. Abstraction can make it more difficult for business professionals to see their business in the data model. Therefore, we can improve the acceptance of the data model by subtyping Party Role and storing the definitions in these subtypes. For example, we can add Customer, Supplier and Employee entities and store their definitions within these respective entities (see Figure 4).
A number of data management professionals - including Enterprise Data Architect Walter Heyse, Data Architect Graeme Smith and Consulting Data Architect Michael Brackett would recommend this approach. Michael adds that it is much easier to write data integrity rules if the specific entities are used.
Define through views. We can also build views in the physical data model that "unabstract" the Party/Role model and bring back Customer and other concepts that were abstracted. We could then store the definitions in these views. Siva Yannapu, data architect, suggests this approach. This technique can also be used in combination with the first technique to reduce the amount of abstract structures in a reporting layer.
Use a data dictionary or metadata repository. If we want to make definitions accessible to as many people in the organization as possible, we may choose to store them in a data dictionary or metadata repository instead of in a data modeling tool. A number of responders to this challenge, including Chaya Patamalla, senior DBA, and Don Rognlien, enterprise architect, recommend this approach. If this option is chosen, Don recommends mapping these definitions to enterprise level services so that architects, designers, developers and business professionals can discover and reuse: "You may find you have established a 'unified data layer' in your infrastructure and that your MDM and BI efforts have been raised to a new level of maturity."
So there are several options for storing definitions of terms that have been abstracted. Which one is best for you? It depends. ("It depends" is always the right answer.) Are you looking for low support costs and maximum design flexibility? Go for the first option and add a Role Type Definition field. Do you want to make the model more meaningful to the business? Use the second option by subtyping those concepts that were abstracted. Are you comfortable with storing definitions in physical views? Go for the third option. Looking for a central place to manage definitions? The data dictionary or metadata repository option is for you.
Steve Hoberman is currently a data modeling consultant and instructor. He taught his first data modeling class in 1992 and has educated more than 10,000 people about data modeling and business intelligence techniques since then. Steve balances the formality and precision of data modeling with the realities of building software systems with severe time, budget, and people constraints. In his consulting and teaching, he focuses on templates, tools, and guidelines to reap the benefits of data modeling with minimal investment. Steve is the author of five books on data modeling, the founder of the Design Challenges group, and inventor of the Data Model Scorecard.
