The Data Model Resource Book: Volume 3: Universal Patterns for Data Modeling by Len Silverston

Author:Len Silverston [Silverston, Len]
Language: eng
Format: epub
ISBN: 9781118080832
Goodreads: 11046593
Publisher: Wiley
Published: 2011-03-21T04:00:00+00:00

Level 1 Contact Mechanism Pattern

A common approach for data models (and data modelers) is to model the specific contact mechanism needs for an enterprise in order to better understand these requirements. This type of approach should show all of the different types of contact mechanisms for an entity, as well as the different classifications of the contact mechanism, such as the purposes, usages, and/or priority of the contact mechanisms. One option for accommodating this need is to create a very specific data model of contact mechanisms, and you can use the Level 1 Contact Mechanism Pattern as a template for this approach. This pattern will provide a very easy approach to understanding the data requirements to help start creation of a model where each of the contact mechanisms is defined as an attribute of the containing or owning entity. The purpose or usage is explicitly shown in the attribute name, for example, ship to postal address part 1, where “postal address” is the type of contact mechanism, “ship to” is the purpose, and “part 1” represents the first line of the address.

As we have pointed out in other chapters, many data modelers find it very difficult to reconcile this style of data modeling with more normalized styles of logical data modeling that may view these attributes as repeating groups (because there could be many “ship to” addresses) that need to be broken out into their own entity in order to allow any number of contact mechanisms. Thus, you may view this type of model as bad modeling that needs to be unlearned and discarded. But is this really the case? Yes, this style of model has flaws and weaknesses that need to be understood; for example, when more contact mechanisms are required or additional types of contact mechanisms are required, the data model needs to be changed to accommodate these needs. However, this type of model also has benefits that should also be understood. They can be useful under some circumstances, for example, if the number and type of contact mechanisms are very stable and unchanging or if you need a means to understand the data requirements by modeling them very specifically. Furthermore, this type of specific modeling appears in many legacy implementations. For this reason, a data professional should know its strengths and weaknesses.

In this type of data modeling the data professional explicitly captures the contact mechanism information as attributes of the entity. For example, a data professional may interview a salesperson and hear her say something like, “We capture the street name, an apartment number, the zip code of the address, the city, the state, an email address, and a contact number. This is enough for us to process the order!” This leads the data professional to capture attributes of order address part 1, order apt address part (for the apartment number), order postal code (for the zip code), order city, order state, order email address, and sales contact number.

But as a data modeler you may ask yourself,

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.