Master Data Services Training Guide. Modeling Guidelines. Portions developed by Profisee Group, Inc Microsoft

Transcription

1 Master Data Services Training Guide Modeling Guidelines Portions developed by Profisee Group, Inc Microsoft

2 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 section and for the entire class is 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. 7 :: 2 Master Data Services Training Guide

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. Master Data Services Training Guide 7 :: 3

4 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 items often referred to as members or elements that 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. 7 :: 4 Master Data Services Training Guide

5 Model Components: Domain-based Attribute One of the three attribute types that you may create is domain-based attributes. A domainbased 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. Master Data Services Training Guide 7 :: 5

6 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 :: 6 Master Data Services Training Guide

7 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. Master Data Services Training Guide 7 :: 7

8 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 company s annual report; survey an internal managerial report. In both of these scenarios, hierarchies are prevalent and a critical means to display financial data Income 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 hierarchies each 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 explicit hierarchy 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 introduce two system attributes, Code and Name, for consolidated members. Code must be unique throughout the hierarchies and entity. 7 :: 8 Master Data Services Training Guide

9 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. Master Data Services Training Guide 7 :: 9

10 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. 7 :: 10 Master Data Services Training Guide

11 Hierarchy Definition: Derived Hierarchy with an Explicit Cap A derived hierarchy with an explicit cap blends a derived and explicit hierarchy. It is formed by linking 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. Master Data Services Training Guide 7 :: 11

12 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. 7 :: 12 Master Data Services Training Guide

13 Master Data Services Training Guide 7 :: 13

14 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. 7 :: 14 Master Data Services Training Guide

15 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. Master Data Services Training Guide 7 :: 15

16 Identify Entities and Attributes This is a listing of the major, important entities within a model; for example, department, division and center not gender and postal code. Common domain-based attributes can be listed simply as attributes and don t need to be identified as entities. It is clear that gender or a yes-no flag should be restricted to a domain. 7 :: 16 Master Data Services Training Guide

17 Attribute Definition Master Data Services Training Guide 7 :: 17

18 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 is explicit, 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. 7 :: 18 Master Data Services Training Guide

19 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. Many retain 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. Master Data Services Training Guide 7 :: 19

20 Implement Relationships 7 :: 20 Master Data Services Training Guide

21 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. Master Data Services Training Guide 7 :: 21

22 Define Version Management Processes It is unlikely that the initial prototype will be perfect. When reviewing the model, take the time to adjust early assumptions all the way back to attributes and begin to apply user roles and attribute groups. With the initial model completed, the focus can shift to building custom subscriptions (if necessary) and preparing a versioning plan and user-defined flags. 7 :: 22 Master Data Services Training Guide

23 Integrating Master Data Services It s important to identify and design key integration points. This includes data sources, or systems that will populate Master Data Services one-time or recurring. It also includes systems that will subscribe to the Master Data Services model. Master Data Services Training Guide 7 :: 23

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 model s ongoing development as it evolves from development to test to production As noted earlier prototypes and proofs-of-concept are helpful. 7 :: 24 Master Data Services Training Guide