07 Modeling Guidelines

8/3/2019 07 Modeling Guidelines

1/24

Master Data Services Training Guide

Modeling Guidelines

Portions developed by Profisee Group, Inc.

2010 Microsoft


2/24

7 :: 2 Master Data Services Training Guide

MDM: A Multifaceted Discipline

Master Data Management is a multi-faceted discipline that covers a wide range of subject areas

from data quality to data governance.

The focus of this sectionand for the entire classis an overview of some of the components

and approaches to building a comprehensive and effective master data model in Microsoft SQL

Server Master Data Services.


3/24

Master Data Services Training Guide 7 :: 3

Objectives

This section will begin with an overview of the key components of a master data model:

Entities Hierarchies: explicit, derived and derived with explicit cap

Attributes: domain-based, free-form and file

Collections

Member types: leaf and consolidated.

Following the dive into model components, this section presents suggested guidelines and

considerations when creating and deploying master data models:

The relationship between entities and attributes

When and how to use certain types of hierarchies

How to make the most effective use of business rules

The benefits of versioning and version frequencies.

This section is a useful reference when undertaking a new project or model implementation.


4/24


Model Components: Entity

A Master Data Services database may contain one or more master data models. A model

typically represents a common subject area such as customers, products, financial accounts and

locations. An entity is the foundation of a Master Data Services model. It represents a list of

itemsoften referred to as members or elementsthat share common characteristics. As

examples, an entity City contains a list of cities; an entity Color contains a list of colors. One or

more entities reside in model.

An attribute, or property, further defines or modifies an entity. For example population is an

attribute that further describes a city. An attribute is classified as domain-based, free-form, or

file. Free-form attributes are further classified as text, number, date/time, or link. Every entity

has, at a minimum, two system attributes: Code and Name. Code is required, must be unique

throughout the entity, and often represents the natural key for a source system. Name is optional,but recommended. It further describes the data element and typically appears on reports.


5/24


Model Components: Domain-based Attribute

One of the three attribute types that you may create is domain-based attributes. A domain-

based attribute is an attribute that uses an entity as its data source. For those familiar with

relational database theory, an entity is equivalent to a table, an attribute is equivalent to a column

in the table. A domain-based attribute is a column that essentially acts as a foreign key.

As will be discussed later in this section, domain-based attributes form the basis for derived

hierarchies.

To further describe domain-based attributes, consider an example of three entities, or tables:

1. States

2. Cities

3. Regions

The State entity contains three domain-based attributes:

1. Capital

2. Most Populous

3. Region

The list of capitals and most populous cities is derived from City; the list of regions is from the

Region entity.


6/24


Extending the example a step further, each city is assigned a state or province attribute. The list

of available states is derived from the state entity. A more advanced use of domain-based

attributes is to create an attribute that refers to the same entity to which the attribute is associated.

In this example, Sister City refers to the same list of cities. The term recursive hierarchy is often

used to describe this scenario.


7/24


Model Components: Free-form Attribute

The second type of attribute is free-form. As the name implies, free-form attributes are not

restricted to a domain-list. Data entry is restricted to the data type defined when the attribute is

created. A free-form attribute is assigned one of the following four data types:

1. Text

2. Numeric

3. Date

4. Link, or URL

When assigning or updating attributes, Master Data Services ensures that the data corresponds to

the attribute data type.

A free-form attribute is equivalent to a standard column in SQL Server.

The third attribute type is file. Once defined, it enables users to upload files to Master Data

Services. The next section will cover this in more detail.


8/24


Model Components: Explicit Hierarchies

Hierarchies are typically a key component of a model; they form the basis for data analysis and

reporting.

Browse through a companys annual report; survey an internal managerial report. In both of

these scenarios, hierarchies are prevalent and a critical means to display financial dataIncome

Statements, Balance Sheets, sales by territory, etc. One of the key benefits of Master Data

Services is the ability to use existing master data elements to create a myriad of different types of

hierarchieseach designed to support a specific need. Through business rules and other forms of

automation, many of the hierarchies are subjected to rigorous business requirements.

Master Data Services distinguishes between explicit and derived hierarchies. Each explicithierarchy is associated with a single entity. The addition of the first explicit hierarchy to an entity

introduces consolidated member types.

Leaf member types are directly associated with entities.

Consolidated members are associated with explicit hierarchies.

Consolidated members possess a distinct set of attributes (that are shared across

hierarchies).

An entity contains zero or more user-defined explicit hierarchies. Explicit hierarchies introducetwo system attributes, Code and Name, for consolidated members. Code must be unique

throughout the hierarchies and entity.


9/24


Hierarchy Definition: Explicit vs. Derived

The most important difference to understand between explicit and derived hierarchies is that

derived hierarchies are formed via attribute relationships and employ multiple entities. Explicit

hierarchies have ragged level depths and reside within a single entity.

For those familiar with Microsoft SQL Server Analysis Services (or other multidimensional

analysis solutions), explicit hierarchies resemble parent-child hierarchies; derived hierarchies

equate to attribute-based or level-based hierarchies.


10/24


When modeling hierarchies for your master data models, it is critical to invest the time to

understand the business and system requirements, so that you select the most efficient hierarchy

type.

This table depicts further differences between the hierarchy types.


11/24


Hierarchy Definition: Derived Hierarchy with anExplicit Cap

A derived hierarchy with an explicit cap blends a derived and explicit hierarchy. It is formed bylinking related attributes and then connecting an explicit hierarchy at the top.

The diagram below illustrates the benefits of using Master Data Services to manage hierarchies.

Customers are maintained in a customer entity and each is assigned to a customer group

(attribute). The Customers-by-Location derived hierarchy enables you to analyze and report by

geography. The derived hierarchy with an explicit cap on the left makes use of the same entity

and attributes and then inserts an existing explicit hierarchy. Changes to the underlying data are

automatically reflected in both hierarchies.


12/24


Model Components Recap

The next three illustrations put together the individual components of a master data model

helping to paint a cohesive picture of how they relate to the other components that make up a

model.


13/24



14/24


Model Development: Preliminary Considerations

Having covered the basic components of a model, the remainder of this section will present some

general modeling guidelines for consideration during the design and implementation of a Master

Data Services model.

The following presents a set of proven steps to build and deploy a high-quality master data

model using Master Data Services. This approach leverages the power of Master Data Services

to avoid some of the more mundane technical data modeling techniques. It encourages model

builders to build and populate the model while it is still being designed. Because it is easy to

alter and update a model, real data can and should be analyzed and loaded to help validate

assumptions. This approach produces documentation of the model and yields a working pilot,

prototype or proof of concept.

No model exists in isolation. Before building a model it pays to enumerate and agree on the

stakeholders and boundaries of the model. An organization may have 20 or more systems that

could potentially subscribe to a model. Furthermore, the model could have hundreds of

attributes. While it is technically possible to implement a model that feeds this many systems

with this many attributes, it is a good idea to limit the scope and set boundaries for the initial

model. Master Data Services simplifies the process of adding new attributes and subscriptions,

so starting small does not hinder future scalability.


15/24


Model Development: Major Steps

The below list and diagram illustrate the key steps a Master Data Services modeler should

consider during the design phase:

1. Identify entities

2. Define attributes

a. Free-form

b. Domain-based

3. Identify hierarchies

4. Implement relationships

a. Explicit hierarchy

b. Derived (domain-based) hierarchy

5. Group attributes

The process is typically quite iterative as the model evolves over time. Each step is covered in

specific detail in the ensuing sections.


16/24


Identify Entities and Attributes

This is a listing of the major, important entities within a model; for example, department,

division and centernot gender and postal code. Common domain-based attributes can be listed

simply as attributes and dont need to be identified as entities. It is clear that gender ora yes-no

flag should be restricted to a domain.


17/24


Attribute Definition


18/24


Identify Relationships

Hierarchies are generally easy to identify and difficult to design. Subscribing systems have

hierarchal requirements that must be modeled in Master Data Services.

It is generally easier to maintain derived hierarchies than explicit hierarchies. If a hierarchy isexplicit, it is important to determine if it is complete or not (mandatory or non-mandatory).

Some hierarchies do not follow simple rules. These hierarchies must be modeled as collections

or synthesized from data from several domains.


19/24


Identify Hierarchies

Statutory and managerial reports are often good sources for existing hierarchies. Prevailing

business intelligence systems and data warehouses are also good candidates to survey. Manyretain dimension hierarchies. In many cases it is helpful to interview employees to understand

how they analyze the business and market. The interview process often yields unforeseen

opportunities for new hierarchies.


20/24


Implement Relationships


21/24


Define Business Rules

By building a test model, users will be able to visualize relationships, test assumptions and alter

the initial design. A test model will also serve as the platform to build business rules,

notifications and user roles.


22/24


Define Version Management Processes

It is unlikely that the initial prototype will be perfect. When reviewing the model, take the time

to adjust early assumptionsall the way back to attributesand begin to apply user roles and

attribute groups. With the initial model completed, the focus can shift to building customsubscriptions (if necessary) and preparing a versioning plan and user-defined flags.


23/24


Integrating Master Data Services

Its important to identify and design key integration points. This includes data sources, or

systems that will populate Master Data Servicesone-time or recurring. It also includes systems

that will subscribe to the Master Data Services model.


24/24

Other Considerations

This concludes some general modeling guidelines. Other points to consider:

Data governance is an important component of a successful MDM implementation Adopting common naming conventions and notations is important

Carefully define and manage a models ongoing development as it evolves from

development to test to production

As noted earlier prototypes and proofs-of-concept are helpful.

Documents

07 Modeling Guidelines