Metadata Management Tutorialmetaintegration.com/Products/MIMM/OEM/erwin/... · 3 Metadata...

Metadata Management Tutorial – Web Portal & Data Governance Using erwin Metadata Management (EMM)

P a g e 1 | 220

C o p y r i g h t © 2 0 1 8 , e r w i n I n c . a n d / o r i t s a f f i l i a t e s . A l l R i g h t s R e s e r v e d .

V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Metadata

Management

Tutorial

Web Portal & Data Governance

Using erwin Metadata Management

(EMM)


P a g e 2 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

TABLE OF CONTENTS

1 Introduction _______________________________________________________ 5

1.1 Conventions used in the tutorial _________________________________________ 6

1.2 Setting Up the Tutorial _________________________________________________ 7

2 About Data Governance and Metadata Management _____________________ 9

2.1 General data and metadata management discussion _______________________ 10 2.1.1 Data and metadata are everywhere! __________________________________________ 10 2.1.2 MITI’s strategy to support data and metadata management _______________________ 11

3 Metadata Harvesting _______________________________________________ 13

3.1 From Data Stores and Data Processes To Enterprise Architecture _____________ 14 3.1.1 Identify data stores & associated design tools ___________________________________ 14

3.2 Understanding This Tutorial’s Enterprise Architecture ______________________ 16 3.2.1 Catalog the Operational Data Stores __________________________________________ 16 3.2.2 Catalog the Data Processes. _________________________________________________ 18

3.3 Harvesting the Finance System Metadata _________________________________ 20 3.3.1 Harvest the Accounts Payable model __________________________________________ 20 3.3.2 Harvest the Accounts Receivable model _______________________________________ 33

4 Configuration Management _________________________________________ 36

4.1 Configuration Management ____________________________________________ 37

4.2 Populate the Published Configuration ___________________________________ 38 4.2.1 Bringing Model Formats into a Configuration ___________________________________ 38 4.2.2 Semantic lineage architecture _______________________________________________ 39 4.2.3 Warehouse dataflow architecture ____________________________________________ 44 4.2.4 Data Flow Architecture _____________________________________________________ 49 4.2.5 Metadata Explorer UI ______________________________________________________ 49

4.3 Metadata Explorer UI _________________________________________________ 50 4.3.1 Shapes __________________________________________________________________ 50

4.4 Attachments ________________________________________________________ 52

5 Metadata Search, Browsing and Analysis _______________________________ 54

5.1 Impact of Change Lineage _____________________________________________ 56

5.2 Data Source Lineage __________________________________________________ 59

6 Simple Data Governance with Business Glossary _________________________ 62

6.1 Overview of the Business Glossary features _______________________________ 64

6.2 Creating an abstract Business Glossary ___________________________________ 65 6.2.1 Create the Business Glossary ________________________________________________ 65 6.2.2 Populate the Business Glossary ______________________________________________ 66

6.3 Glossary derived from a Model _________________________________________ 72 6.3.1 Import the Model _________________________________________________________ 72 6.3.2 Create and Populate the glossary _____________________________________________ 72


P a g e 3 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

6.3.3 Update the configuration ___________________________________________________ 76

7 More Metadata Analysis ____________________________________________ 79

7.1 Terminology Usage (Impact) Analysis ____________________________________ 80 7.1.1 Trace Semantic Usage ______________________________________________________ 80

7.2 Trace Semantic Definition _____________________________________________ 85 7.2.1 Build Glossary to Glossary Mappings __________________________________________ 87

7.3 Embed the mapping __________________________________________________ 94

8 Data Governance with Business Glossary _______________________________ 95

8.1 Glossary Semantic Mapping and Term Classification ________________________ 96

8.2 Extending the Business Glossary with existing metadata ___________________ 106 8.2.1 Analyze potential metadata ________________________________________________ 106 8.2.2 Populate the Business Glossary _____________________________________________ 108

8.3 Normalization of Terminology _________________________________________ 111 8.3.1 Preventing redundancy ____________________________________________________ 111 8.3.2 Mapping terminology _____________________________________________________ 112

8.4 More Editing Terminology in the Metadata Explorer UI ____________________ 142

8.5 Report Glossary and Report Documenter ________________________________ 152

9 Data Mapping Specifications ________________________________________ 165

9.1 Constructing a data mapping specification _______________________________ 166

9.2 Simple Load _______________________________________________________ 167

9.3 Detailed data mapping specifications ___________________________________ 172 9.3.1 Include business names____________________________________________________ 174 9.3.2 Creating a map___________________________________________________________ 175

10 Advanced Business Glossary Workflow ________________________________ 181

10.1 Overview of the advanced Business Glossary features _____________________ 182 10.1.1 Glossary Workflow _____________________________________________________ 182 10.1.2 Workflow Roles ________________________________________________________ 182 10.1.3 Stewards _____________________________________________________________ 182 10.1.4 Workflow process options _______________________________________________ 183 10.1.5 Term management dashboards ___________________________________________ 183 10.1.6 Workflow transition buttons _____________________________________________ 183 10.1.7 Versions______________________________________________________________ 183 10.1.8 Categories ____________________________________________________________ 184 10.1.9 Relationships __________________________________________________________ 184 10.1.10 Flexible and optional workflow process ____________________________________ 184

10.2 Configuring the Glossary for Workflow __________________________________ 188 10.2.1 Configure the Glossary __________________________________________________ 188 10.2.2 Published configuration version __________________________________________ 191 10.2.3 Defining groups to support glossary roles ___________________________________ 193 10.2.4 Workflow Roles ________________________________________________________ 196

10.3 Glossary Workflow __________________________________________________ 199 10.3.1 Propose a draft ________________________________________________________ 199


P a g e 4 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

10.3.2 Edit _________________________________________________________________ 201 10.3.3 Review _______________________________________________________________ 205 10.3.4 Approve a term ________________________________________________________ 206 10.3.5 Publish _______________________________________________________________ 207

11 Semantic Mapping ________________________________________________ 209

11.2 Configuration Architecture Diagram ____________________________________ 213 11.2.1 Annotation ___________________________________________________________ 213

Appendix A __________________________________________________________ 215


P a g e 5 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

It is certainly possible to skip through the tutorials, and thus simply glean an

“management-level understanding” of erwin Metadata Management (EMM) and its use

within a metadata management environment. However, it is not recommended that one

try to skip parts of the tutorials and then try to go through later parts. When following

through the tutorial sections, it is very important to respect the order of the steps (and the

order sections/labs within each section). The results of preceding tutorials are re-used

and built upon in each successive lesson.

In addition, it is important to ensure complete understanding of the conceptual

background provided in the sections leading up to and supporting the tutorial material.

Thus, one should not simply jump into the tutorials with carefully reviewing the concepts

presented in that section.

As this document include hand-on tutorials, a great deal of specificity is required. This

detail includes specifying particular CASE, ETL, BI, etc., vendor’s tools. While erwin

Metadata Management (EMM) environment itself is capable of working with over 100

different versions of third-party tools (see

http://www.metaintegration.net/Products/MIMB/SupportedTools.html), it is necessary for

the clarity conciseness of the tutorials to limit the cadre of tools that will be referred to.

Please note that it is not necessary to have these tools on-hand to get the full benefit of

the tutorials. Remember also, though you may intend to use erwin Metadata

Management (EMM) suite of tools with many of the supported third-party tools not

specified in the tutorial, it is still quite valuable to learn the processes, methods and best

practices presented here. Then one may reuse what one has learned and apply that

knowledge and skill to the particular set of tools that are critical to one’s own enterprise.

Disclaimer Some of the features detailed in this document may not apply and/or be available for the

particular erwin Metadata Management (EMM) edition you may have.

1 Introduction

http://www.metaintegration.net/Products/MIMB/SupportedTools.html


P a g e 6 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

1.1 Conventions used in the tutorial

The following font conventions will be used throughout the tutorial.

User Interface item – New

Submenu item – New › Folder

Terminology item – model content item

Name or label reference – Accounts Payable


P a g e 7 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

1.2 Setting Up the Tutorial

This tutorial currently does not contain a separate orientation on the erwin Metadata

Management (EMM) toolset. Specific examples of how to perform the operations

required for this tutorial are provided in the next sections.

In order to create this structure in the repository for the tutorial, you will restore a backup

that includes the basic repository structure for the tutorial plus any metadata that you

cannot easily replicate. To do so

1. Sign in as Administrator 2. Go to MANAGE > Advanced Metadata Manager

3. In the Repository panel on the left right-click on the folder named Configuration and

select Delete.

4. Now, right-click on the Repository and select More… > Restore.


P a g e 8 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

5. Click Browse and navigate to the backup at and click More Options > Restore.

6. Select the following path:

C:\Temp\Models \Backups\Data Governance\

7. Click Restore 8. Refresh the browser.

Note how the metadata cataloged in the previous section are reflected in the tutorial

repository structure under the folders Tutorial/Metadata Management.


P a g e 9 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 1 - Model Connection Diagram for System Metadata Management Exercises

The above figure represents an overview of the tutorial that this document will lead one

through. While it appears here to be a fairly complicated diagram, this document will

decompose and will walk one through the data and metadata management concepts

encompassed.

The sample metadata represents what would be captured from operational finance based

systems, including the operational data stores (ODS), warehouse models (DW and

DWStaging), Big Data sources, XML messages and business intelligence (BI) data marts.

These will be from a variety of data modeling tools or directly from the sources

themselves. In addition, a Business Glossary and enterprise conceptual data model

(CDM) are also included and mapped to the operational system metadata.

2 About Data Governance and Metadata Management


P a g e 10 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

2.1 General data and metadata management discussion

Metadata management is not an end in and of itself. There has to be real return on

investment in what can be a very expensive and long term undertaking. The promise in

terms of having a well architected and interoperable information systems environment is

well understood by most people in the information management community. However,

as with any foundation, it must be solid, well thought out, and appropriate to the need. In

order to have an outrageously successful effort, then, the specific objectives must be very

clearly defined, the organization as a whole must be able to leverage the results of the

metadata efforts, and the infrastructure must be able to support all of the many methods,

design tools, etc., that an organization is using and will adopt into the future.

It has been said many times that “Metadata and Architecture assets will outlive the tools,

methodologies, and individuals used to produce them.” Thus, it is imperative that your

metadata be as independent as possible from a particular tool format, methodology or

process. Having incredibly valuable and expensive work “locked” into a particular tool

and methodology or process can spell doom for any metadata and data management

effort. Metadata must also be accessible to the widest possible audience within an

organization, in order to conclusively demonstrate to the technical and business

communities that metadata is a valuable (and accessible) corporate asset.

2.1.1 Data and metadata are everywhere!

One of the key reasons seen for integrating and managing metadata across an enterprise is

that, as we know, data is everywhere. The proliferation of different software applications

that can accomplish more and more specific tasks, and the incredible cost to develop new

ones, means that inter-operation, or enterprise application integration, with many

disparate data sources is the only way to provide an integrated enterprise. After decades

of trying, we have given up on the concept that there will be just one data source, virtual

or otherwise, and interoperability is now known to be the key to integration. If data must

exist in physically separate data stores, on a diverse array of platforms, then integrated

enterprise data architecture will be required to “link” the disparate and possibly redundant

data stores together via well-defined processes. Losing track of these “links” costs

organizations millions of dollars annually, by increasing the risk of system errors,

extending application development project timelines, increasing the cost/complexity of

building decision support systems, and countless other ways. The inability to trace

information across disparate processes and technologies has lead to a lack of trust by

business management about the reliability of the content of corporate information.

Having to then assure the quality of the information used to make the decision, inevitably

causes delays in key business decision making. Thus is born the need for metadata

repositories, metadata integration and management.


P a g e 11 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

What needs to be recognized, though, is that metadata is also everywhere. Data

Modeling tools abound in an organization, many with their own repositories, just about

every application has its own data dictionary, XML carries the metadata with it in the

message or document, and data flow mapping inter-relate all of it together. Thus, the

same difficult lesson applies: the truly effective and future proof way to integrate and

manage this metadata is interoperability and enterprise repository integration. There is

never going a single repository (metadata source), virtual or otherwise, and thus,

metadata exchange and repository interoperability are key to metadata integration.

2.1.2 MITI’s strategy to support data and metadata management

In order to succeed, then, one must have a good enterprise repository integration

environment. This philosophy is what the erwin Metadata Management (EMM)

repository solution and products are based upon. It is an integrated whole that can bridge

the technical and non-technical aspects of metadata, while simultaneously bridging the

chasm between the different metadata source and target systems that constitute any

modern information management environment.

Metadata is everywhere and erwin Metadata Management (EMM) provides data

governance metadata repository environment that is agnostic of data modeling tool

source or other data store metadata sources. Including the business glossary, data flow

mapping design, semantic mapper and bridges into big data, database technologies,


P a g e 12 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

XML, COBOL, etc., erwin Metadata Management (EMM) allows one to manage and

analyze the complete enterprise metadata life cycle across heterogeneous vendors.


P a g e 13 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

In order to design, build and maintain a metadata management environment, one must

identify and catalog the assets in the current environment. In general, this process is

broken into the cataloging of data stores, data processes and conceptual models.

3 Metadata Harvesting


P a g e 14 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

3.1 From Data Stores and Data Processes To Enterprise Architecture

3.1.1 Identify data stores & associated design tools

With that overview of the erwin Metadata Management (EMM), we may now return to

the general metadata management discussion. One of the first steps in populating the

repository and thus building up one’s metadata management environment is an inventory

of the metadata in your organization.

For the purposes of this document, the specific methodology used is immaterial. Instead,

from the MIR perspective it is most important to analyze

where the metadata resides

what technology is required to extract it (and ultimately forward-engineered)

what process or set of steps must be followed in order to ensure proper extraction

As was stated in previous sections, metadata is everywhere within any modern

information management organization. Also, there are many repositories that are

required to exist for each technology environment in order for it to perform properly. In

order for these sources and targets to provide a coherent and coordinated environment,

this metadata must be exchanged.

3.1.1.1 Interface technology issues

Fundamental to the repository is the ability to exchange metadata among the disparate

sources and targets that exist in the enterprise and those that will be adopted into the

future. The following table addresses how metadata is extracted from and returned to the

different sources.

Metadata

Source /

Target

POC Reverse

Engineering

Method

Reverse

Engineering

Contents

Forward

Engineering

Method

Forward

Engineering

Contents

Tool Name

and

Description

Point of

Contact /

Steward for

Tool

(Tool-

specific

metadata

bridge)

(Tool-

specific

contents, see

http://www.

metaintegrat

ion.net/Prod

ucts/MIMB/

Documentati

on/Supporte

dTools.html

for specific

details by

source)

(Tool-

specific

metadata

bridge)

(Tool-

specific

contents, see

http://www.

metaintegrat

ion.net/Prod

ucts/MIMB/

Documentati

on/Supporte

dTools.html

for specific

details by

target) Figure 2 - Classifying metadata sources and targets

http://www.metaintegration.net/Products/MIMB/Documentation/SupportedTools.html















P a g e 15 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Depending upon the particular source, there will most likely be different technology

related issues to consider when extracting metadata. Generally these issues revolve

around the type of interface required by the particular tool vendor. These interfaces may

be divided into three categories:

Issues related to these different technology approaches are summarized in the following

table and are also documented on the website:

Metadata Interface Type Examples Issues

Direct application

programming interface

(API)

Repository bridges

(e.g., erwin Mart)

Generally must have client

for repository with API

installed on repository server

Sometimes will not cross

OS-specific lines, e.g.,

COM/DCOM based API

requires a Windows-based

repository server

Import/Export file format Specific text or binary

formats

CSV text files

dumping tables from

repositories

XML files (standards

like OMG UML or

CWM XMI or

proprietary

Sometimes incomplete or

unreliable (try the export/re-

import roundtrip test)

Sometimes multiple

interpretations of the

standards like CDIF and

XMI

Native File Format Binary files of design

tools or repositories,

e.g., IBM Inforsphere

Data Architect .DBM,

or erwin Data Modeler

.ERWIN.

Text files, possibly

structured in a

language, e.g., erwin

Data Moder .XML or

Embarcadero

ER/Studio .DM1

Direct database access

(underlying

repository)

Reliable metadata when

exporting.

Possibility of corrupting

metadata when importing.

Proprietary solution specific

to the tool vendor

May again require vendor

API

Figure 3 - Types of metadata interfaces

Again, one should refer to the web site for specific details by source. It is highly

encouraged that any organization building a metadata management environment develops

a detailed set of tables like the ones above.


P a g e 16 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

3.2 Understanding This Tutorial’s Enterprise Architecture

As a business case, this document refers to the data management and metadata

management lifecycle associated with a financial system for a large organization, simply

referred to as “My Company.” It is comprised of several components and activities,

including:

Finance System:

o Physical legacy Accounts Payable (AP) system and reverse-engineered data

model

o Logical design and physical data model for Accounts Receivable (AR) system

o Logical-Physical DW Staging and Physical dimensional Star-Schema DB

Model

o Data Mapping Specifications

A conceptual layer

o Business Glossary maintained in erwin Metadata Management (EMM)

o And Enterprise Conceptual Data Model (CDM) created using a logical design

tool (erwin Data Modeler).

o Semantic Mappings

Metadata harvesting is the process of populating the repository with metadata from all of

the sources identified in the last section after cataloging the metadata sources and data

processes and associated metadata mappings. In order to do so in a well managed

process, one must first develop a catalog of the metadata in your organization.

3.2.1 Catalog the Operational Data Stores

Below is the completed Data Store Catalog for the tutorial scenarios. Normally, such a

table would take several iterations to complete in a large organization.


P a g e 17 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Metadata Source / Target

POC Reverse Engineering Method

Reverse Engineering Contents

Finance Accounts Payable (AP) erwin Reverse Engineering

Finance AP-AR POC

ER/Studio DM1 bridge

Physical RDBMS design reverse engineered from the SQL Server DB (MITI-AP.mdb) and commented in erwin.

Finance Accounts Receivable (AR) erwin Logical Physical Design

Finance AP-AR POC

erwin v 9.x XML bridge

Logical E-R and derived Physical RDBMS design for the SQL Server DB (MITI-AR.mdb) in erwin

Finance Data Warehouse Staging DB Logical Physical Design

Finance DW POC


Logical E-R and derived Physical RDBMS design for the SQL Server DB (MITI-FinanceDWStaging.mdb) in erwin

Finance Data Warehouse DB Logical Physical Design

Finance DW POC


Logical E-R and derived Physical RDBMS design for the SQL Server DB (MITI-FinanceDW.mdb) in erwin

Finance Vendor Mart DB

Finance BI POC SAP PowerDesigner PDM bridge

RDBMS model for the SQL Server DB (MITI-FinanceDW.mdb), BI cube design and packaging information


P a g e 18 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

3.2.2 Catalog the Data Processes.

Below is the completed Data Process Catalog for the tutorial scenarios. Normally, such a

table would take several iterations to complete in a large organization.


P a g e 19 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Data Process

Name

Description Process

Type

POC Data Source(s)

Finance

Accounts

Payable (AP)

to Finance DW

Staging ETL

Extracts from

the AP RDBMS

are loaded into

DW Staging

DB

Scheduled

ETL via

Informatica

DW POC Source: Accounts Payable

DB

Target: Finance DW

Staging DB

Finance

Accounts

Receivable

(AP) to

Finance DW

Staging ETL

Extracts from

the AR

RDBMS are

loaded into DW

Staging DB

Scheduled

ETL via

Informatica

DW POC Source: MITI-AR

Target: MITI-

FinanceDWStaging

Finance DW

Staging to DW

ETL

Extracts from

the DW Staging

RDBMS are

loaded into DW

RDBMS

Scheduled

ETL via

PL SQL

DW POC Source: MITI-

FinanceDWStaging

Target: MITI-FinanceDW

Finance DW to

Vendor Mart

Data Mapping

Specifications

erwin

Metadata

Manageme

nt (EMM)

UI

BI POC Source: MITI-FinanceDW

Target: MITI-VendorMart

Finance BI

Design to

Reporting

Stitching

between BI

design and

reporting

Real-time

BI

transformat

ions

BI POC Source: None

Target: None


P a g e 20 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

3.3 Harvesting the Finance System Metadata

After executing the tutorial restore structure script, the basic folder structure of the

repository is created. Now it is time to define models to represent the data stores and data

processes that were cataloged in the previous sections. This section of the tutorial will

deal with the mechanics of harvesting the metadata embedded in data stores and data

process tools.

Harvesting may be as automatic a process as one wishes to specify it. Most of the effort

involved is in the definition of connection information or bridge import parameters to

define how the particular bridge will import, or harvest, the metadata from that source.

Beyond that, harvesting is a scheduled or manual process, depending upon your work-

flow. The next sections walk one through the process of creating and harvesting the

appropriate models for My Company.

In the above diagram, one can see a lineage diagram at the model level of detail of the

complete Finance System for My Company. As described earlier, it is a fairly typical

architecture consisting of

Operational data stores (ODS) consisting of data entry and data management systems

Data integration or extract, transform and load (ETL) feeds to

A data warehouse consisting of

o A data warehouse staging (normalized) database

o A snowflake or star-schema dimensional database

Mart database for reporting.

We will now refer back to the metadata catalog that we developed earlier in order to

populate the repository with metadata.

As one may note from the metadata catalog, harvesting from the sources of metadata in

some cases require connectivity directly to a source tool repository and/or API.

However, for the purposes of this demonstration, all the metadata required for harvesting

will be either available directly in the tool format that a bridge can read (e.g., erwin Data

Modeler in XML format or Embarcadero ER/Studio Data Architect DM1 format), or will

be provided as an internal XML Metadata Interchange (MIR XMI), a proprietary format

of erwin Metadata Management (EMM) that faithfully represents the metadata captured

in the repository and via any of the bridges.

3.3.1 Harvest the Accounts Payable model

In erwin Metadata Management (EMM), expand the Repository Tree in the left hand

panel:


P a g e 21 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Note also, most of the metadata we will use will be harvested from an erwin Mart Server,

and is already harvested here in order to expedite the process. This is already present in

the Configuration folder. In fact, it is the metadata that are from other modeling tools,

specifically the Accounts Payable model that is not already harvested here. Thus, we

must first create it.

3.3.1.1 Create Accounts Payable Model Content

Right-click on the Data Stores > Other Modeling Tools folder and select New › Model:

In the Create Model dialog enter the name of the model content to be added: Accounts Payable. Also, enter a description for the model content:


P a g e 22 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

In the dialog, the Model Type data entry field allows one to specify the metadata bridge

to be used to import this model.

Click on the pull-down for the Model Type combo box and you will see the complete list

of bridges available for a model content to use to harvest metadata.

This list is continuously being updated and expanded as support is developed for more

bridges to more formats and tools.

Select the import bridge as shown below:


P a g e 23 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Now click on the Import Setup tab. In this tab, one specifies all the criteria, or bridge

parameters, required to harvest metadata for this model content. Most of the bridge

parameters are determined by the choice of bridge, in the Import from combo box.

Now, click on the show/hide control ( ) for the Help panel on the right side of the

dialog. The tool tip, or help text, for these selected bridge is then presented.

Note, there is a great deal of detailed information about the use of this bridge, including

requirements (e.g., this bridge will work with the .DM1 format files from ER/Studio

directly), special considerations, frequently asked questions, etc.

Now, click on the Model Selection parameter under the Value heading. Note, the tool

tip changes to this new scope.


P a g e 24 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

As the tool tip states, this is where one specifies which models (contained within the

.DM1 file) that the bridge should import. These files, unlike erwin Data Modeler .erwin

files, may contain up to one logical model and any number of physical models. This, this

parameter is provided to allow one to specify what should be imported. In this case, we

will import all the models.

Also, note the browse control ( ) on the right hand side of the File* data entry box.

Click on this control and the Select a File dialog appears. This dialog works quite like

any browse dialog for your operating system. Note, the location being browsed is on the

server where the bridge will run, in this case erwin Metadata Management (EMM)

Application Server, not your local drive. All file and path parameters used for harvesting

into erwin Metadata Management (EMM) are relative to this server. Thus, these files

must be visible to the Application Server, and the process it is running under (for more

sys admin type information about paths and processes on the Application Server, please

refer to the erwin Metadata Management (EMM)Readme.html documentation).

In this case, the file is at the following location within the temp directory the C: Drive on

the application server (you may need to contact your sys admin staff to discover where it

was installed in your environment):

C:\Temp\Models\MetadataManagement\Finance\EmbarcaderoErStudio\AccountsPayable.dm1


P a g e 25 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Additional parameters may be specified as needed in order to harvest the metadata in the

manner required for a particular application. However, at this stage, the default settings

are what we want.

Finally, in the lower left-hand corner of the dialog are a check box:

Set as Default – when set, indicates each time the model content is successfully

harvested, that new version is set to be the default version

Re-import only when changes are detected – when set, indicates each time

the model content is successfully harvested, a comparison is made and it only

updates the metadata in the repository if there are changes.

In this case, this option should be checked.

click the Create button and the model content will be created. You will be offered the

chance to import the model immediately. Click the No button.

3.3.1.2 Import Accounts Payable Model Content

As we did not specify any scheduling or triggering for this model content, we will

manually request that the bridge import a new version of the model content. As we just

created the model, you may simply click the Yes button. Otherwise, if you have a


P a g e 26 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

model and wish to import it later, right-click on the Accounts Payable model content

and select Import.

The Import: Accounts Payable dialog is presented.

Here one may specify a description for the version of the Accounts Payable model

content being imported. In addition, there is an Import Setup tab, where one may

change any of the import parameters for this and all subsequent harvesting or import

requests.

Then a confirmation dialog is presented when the import has completed. Click on the

No button and the model will be opened up from the repository.


P a g e 27 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

3.3.1.3 Review Accounts Payable Import Log

It is generally a good idea to review the log of the harvest operation (import and writing

to the repository database). To view the log after the import has completed, simply right-

click on the repository object you used to initiate the action (in this case the Accounts

Payable model content) and select View Log.

Now, the dialog is again presented with a list of all logs available.


P a g e 28 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Click on View Log for the only one in the list. The Log Messages dialog with the last

harvest log is presented.


P a g e 29 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

The log messages dialog is may be used to navigate through the log messages by using

the control on the bottom row of the dialog. The Show: selection control allows one to

filter the log messages to show only those of the specific level (error, warning, status, or

all) that one wishes to see.


P a g e 30 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

In addition, one may page through the log messages (if there are more than one pages),

refresh the dialog (to see more messages, thought the dialog refreshes regularly on its

own), and save the log messages to a file.

3.3.1.4 Review Accounts Payable Harvested Metadata in the Repository

3.3.1.4.1 Metadata Browser

After reviewing the logs and closing those dialogs, one may see the model in the

Metadata Browser. This time double click on the Accounts Payable model in the

Repository Panel.


P a g e 31 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

The Model Browser presents the metadata harvested in a tree-structured and

expand/contract navigation format, controlled by a profile (in this case the ER/Studio

profile). The icons, naming conventions, properties of the metadata objects, and

organization of the model is all presented in a manner that would be familiar to the actual

tool user (in this case data modelers using ER/Studio).

Like the Repository Tree panel, this is a hyperlinked tree, representing what is actually

more than just a hierarchy of objects in a tree format, with links to various associated

objects.

Now, hide the Repository Panel so as to have more room to view the model:


P a g e 32 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Note, the Model Directory panel shows the different models that were imported

(remember the selection of All Models in the bridge). Right-click on the Physcial model

and select Open.

Figure 4 - Open a model inside the Account Payable harvested model content

Note that the Properties panel on the right may be expanded and contracted (show and

hide) as needed to show metadata properties of the object selected in the model tree. In

the above screen capture, note the PONumber column is selected and the properties like

Definition are presented in the Properties panel.

The Actions control provides access to the same actions as would be available if you

right-clicked on the object in the Repository Tree panel.

3.3.1.4.2 Diagram Visualization

If the model was harvested from a tool which provides diagram information, one may

select a diagram in the browse tree and select Open, or select an object which would be

in a diagram (e.g., a table or column) and select Show in Diagram.


P a g e 33 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 5 - Accounts Payable model in the Diagram Visualizer

Note that the positioning, color, etc. are all faithfully captured by the bridge and rendered

by the Diagram Visualizer. Also, various diagrams may be presented, both physical and

logical.

3.3.2 Harvest the Accounts Receivable model

While most of the models to be used from erwin Data Modeler were already in the Mart

and thus already restored, there is one model that comes from a file. It is saved in both

the .erwin and .xml format. We will import from the .xml format to avoid the

requirement of having erwin DM installed locally.

Right-click the Configuration folder and select New › Model.


P a g e 34 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

In the Create Model dialog enter the name of the model content to be added: Accounts Receivable. Also, enter a description for the model content:

Select the import bridge as shown.

Now click the Import Setup tab.


P a g e 35 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

In this case, the file is at the following location within the temp directory the C: Drive on

the application server (you may need to contact your sys admin staff to discover where it

was installed in your environment):

C:\Temp\Models\MetadataManagement\Finance\CaErwin9Xml\AccountsReceivable.xml

In this case, the two other option should be checked.

click the Create button and the model content will be created. Click OK to import the

model immediately, the No to not view the model when imported.


P a g e 36 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

The data processes and data stores that were cataloged in a previous section are now

represented as models within the repository and they have been populated with metadata

(harvested). This section of the tutorial will deal with the mechanics of building

configurations and then stitching the metadata extracted from the data stores to the

metadata extracted describing the data processes.

4 Configuration Management


P a g e 37 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

4.1 Configuration Management

The configuration is an extremely important concept in erwin Metadata Management

(EMM). It is the scope for many operations, including lineage analysis, search, version

management, etc. In this way, what would otherwise be an overload of information

(everything in the repository), is instead well managed according to the configuration of

metadata one is interested in analyzing or manipulating.

A valid configuration consists of relationships between the configuration and a collection

of model content versions, mapping content versions and stitchings. Just as we have seen

in the previous sections, the model content versions relate to data stores and data

processes that have been harvested into the repository.

The erwin Metadata Management (EMM) accomplishes this management by the

definition and use of repository configurations. Imbedded within the UI is the

Configuration Manager. This tool provides a drag and drop based visual interface for

constructing configurations of models and mappings within the repository. A

configuration is represented by a configuration content within the repository.

Just as with model contents, configuration contents may have one or more versions.

This section describes the process of building these configuration content objects and

their use.


P a g e 38 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

4.2 Populate the Published Configuration

4.2.1 Bringing Model Formats into a Configuration

Open the Published configuration.

Drag the Mart model into the configuration Model Manager tab. Of course, there are a

number of models in the Mart model. Thus, you are presented with a dialog:

Click Yes and you are presented with the selection list. Select all the models except the

AR SQL Server one:

resulting in:


P a g e 39 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Now, we have the configuration populated with the models we need. It is time to move

to the configuration specific Metadata Explorer UI.

4.2.2 Semantic lineage architecture

Now, this is an interesting set of models. These models were created using the erwin

Data Modeler model derivation capability. Basically,

The logical only Receivables Design model was designed

Then the AR Physical was derived as a generic ODBC physical model from that

logical only model (using the Design Levels functions in erwin)

Then the two database specific models were derived for Oracle and DB2.


P a g e 40 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 6 - Model derivation in erwin Data Modeler

erwin Metadata Management (EMM) captures this derivational information when the

Mart is harvested. Thus, in this configuration you will see these relationships.

In this case, we are taking advantage of the fact that erwin Data Modeler already derived

these relationships and that the harvest from the Mart captured them as in erwin Metadata

Management (EMM). Thus, in this case, there are no edits required to the connections.

Instead, simply click on Build , and then go to the Architecture Diagram tab, click on

Edit in the header and re-arrange the models in the diagram like so:

Figure 7 - Derived model diagram

Note: Please use the Edit option in the header if the layout does not match that above.


P a g e 41 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Also, please note the blue dashed lines indicating semantic lineage for the derivation of

the models.

We will now add one more model to this semantic lineage, one that is a SQL Server

based instance of the AR Physical model. Drag the Accounts Receivable model that we

imported before into the configuration:

Figure 8 - Accounts Receivable model added to configuration

Remember, the Accounts Receivable model was imported directly from a .erwin file, not

from the mart, thus there will be no semantic derivational lineage available automatically.

However, we can simply “stitch” this model to the model it “could have been devived

from”, telling erwin Metadata Management (EMM) that there a semantic relationship

between the two. This parent model is the AR Physical (just as it is for the Oracle and

DB2 versions of the model).

To do sohen right click on the AR Physical model in the diagram and select Edit

Connections:


P a g e 42 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 9 - Edit Connection

Select the click on the second line in the table for the Physical Semantic Connection. This

is the connection to a physical model that is derived from this one. Then select the

Accounts Receivable model from the pull-down.:


P a g e 43 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 10 - Connection Editor Pull-down

Then click on OK . Click on Build , and you have a full semantic layout just as if the

model were derived in erwin itself:


P a g e 44 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 11 - Modified derivational lineage architecture

4.2.3 Warehouse dataflow architecture

Now, drag the Staging and Dimensional models into the configuration:


P a g e 45 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 1 - W

arehouse models in configuration

As described earlier, the architecture we are harvesting includes a staging data warehouse

database with data feeds from operational data stores, and a dimensional data warehouse

database with a data feed from the staging. This is a typical architecture and can readily

be represented in erwin Data Modeler defining Data Sources and Data Movement

Rules:


P a g e 46 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 2 - Data Movement Rules in erwin Data Modeler

These have already been defined in the two models. In the Dimensional model, a data

source (named FinanceStagingWarehouse) with data movement rules mapping back to

data structures that match what are in the Staging model. Then, the Staging model in turn

has two data sources, AccountsPayable and AccountsReceivable, with data movement

rules back to data structures that match what are in the AR SQL Server models and another

database not modeled in erwin, the Accounts Payable model modeled in Embarcadero

ER/Studio Data Architect.

However, while these data movement rules and source definitions exist in these erwin

models, there is no way in erwin to point to the other models (e.g., Dimensional to

Staging, or Staging to AR SQL Server and Accounts Payable), and thus the actual source

models are unknown when the mart was harvested in erwin Metadata Management

(EMM). We extend the understanding of erwin Metadata Management (EMM) by

creating stitchings, or linking models to connection definitions in a configuration. In this

way, we end up with an end-to-end mapping in the configuration.

Right-click on the Dimensional model and select Edit Connection:


P a g e 47 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 3 - Edit connection

you are presented with the connection editor showing any connections which need to be

resolved.

Figure 4 - Data process model content represented in the configuration Model Manager tab

Now, in this case, the data source is actually the Staging model and the default schema

(which is dbo for this SQL Server database model).

Once this is defined, click OK.


P a g e 48 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Then, do the same for the other model with a warning indicator next to it, the Staging

model:

Figure 5 - Open Connections for Staging model

Note, this time there are two data source connections, just as defined in erwin Data

Modeler. However, only the AccountsReceivable can be connected. It is the AR SQL Server model from the Mart. So, connect it here. Note, the schema you may select is

called _No_Name_ . This is because there was a schema definition in erwin Data

Modeler, but no name was assigned to it. Thus, when imported, the bridge assigned this

“name” to it for reference. Select that schema and click OK.

The missing model, is of course the Accounts Payable model we imported from

ER/Studio. We must include it in the configuration, so open the Repository Panel and

drag the model into the configuration. Remember, the .DM1 file contained more than

one model and we imported both of them. Thus, again you will be presented with a

dialog asking if you wish to only import individual models. Click Yes and then select the

Physical model.

Now, again right-click on the Staging model and select Edit Connection again and then

select the Physical model and dbo schema for the AccountsPayable connection. Note, the

name in the configuration is the name given to the model inside the source tool, in this

case Physical inside of ER/Studio. It is important to name models with meaningful names

when designing them.


P a g e 49 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

4.2.4 Data Flow Architecture

Finally, click on Build , and thengo to the Architecture Diagram tab. Use the Edit

function to arrange the boxes:

Figure 6 - Finance Architecture

4.2.5 Metadata Explorer UI


P a g e 50 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

4.3 Metadata Explorer UI

So far, we have spent our time in the metadata manager UI. This is not surprising as we

have been working with the management of the repository and configurations. There is a

second user interface, one that in fact is the first one presented when anyone logs in. The

metadata explorer UI is the presentation in which nearly all users will spend their time. It

allows one to perform all analysis, search, browsing, etc. activities as well as most

management tasks.

Right-click the Published configuration and select Open in Metadata Explorer.

Click MANAGE at the top and select Contents.

Click Diagram.

4.3.1 Shapes

Add annotations to the diagram, using the Shapes icon:

Then open the Properties panel and edit the text inside:

Right-click on the annotation and select Annotation Options and edit the font and colors

to match here:

Be sure to click Save in the upper right.


P a g e 51 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 52 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

4.4 Attachments

The erwin Metadata Management (EMM) allows one to attach any document to a model

(or configuration in the manager UI) in the repository. To do so from the metadata

explorer UI:

Click BROWSE at the top and select Data Modeling > Data Models.

Click the Staging DW model.

Then click the Attachments tab.

Simply drag and drop files into the browser window to add them as attachments.


P a g e 53 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 54 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

This section will detail how one uses the erwin Metadata Management (EMM) user

interface for model analysis. In the last sections we built the repository structure, defined

harvesting parameters and imported the metadata from the sources cataloged. We have

also connected this information end-to-end using the configuration management

capabilities. It is now time to apply the metadata analysis capabilities of erwin Metadata

Management (EMM) to the information in these configurations.

The configuration is the scope of analysis within erwin Metadata Management (EMM).

Open the metadata explorer UI and go to BROWSE > Architecture Diagram tab.

Note the different types of lineage arrows. The solid black lines are data lineage and the

dashed-blue are semantic lineage.

This section will detail how one uses the erwin Metadata Management (EMM) user

interface for model analysis. In the last sections we built the repository structure, defined

harvesting parameters and imported the metadata from the sources cataloged. We have

also connected this information end-to-end using the configuration management

capabilities. It is now time to apply the metadata analysis capabilities of erwin Metadata

Management (EMM) to the information in these configurations.

5 Metadata Search, Browsing and Analysis


P a g e 55 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 56 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

5.1 Impact of Change Lineage

One of the primary use cases is one where you wish to know what would happen if a

particular data element were changed. In the data architecture, where one has modeled

the source databases, data mapping rules and then stitched them end-to-end in a

configuration, one can ask the question “what data elements are downstream of this one

in the dataflow and thus would be impacted by a change to this element?”

This is generally referred to as forward lineage analysis, because it looks at the lineage

from the source on the left to downstream elements on the right.

In our case, let’s open the Accounts Receivable model by double-clicking on it or clicking

and selecting Open in Browser.

You are presented with the home page for this model.


P a g e 57 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Then go to the Tables – Entities tab, click the Customer table and click on the Data

Flow tab.

The lineage trace is a fully detailed trace of data flow lineage for detailed analysis. This

presentation allows one to narrow in on specific elements (e.g., a table) and how they

relate in terms of data flow and/or semantic lineage within a model, a model directory, or

a configuration.

In this case based upon the fact that Customer is at the beginning of the lineage, erwin

Metadata Management (EMM) defaulted to Data Impact. If one clicks on End Objects,

then a textual report is provided.


P a g e 58 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Note, by default the result is a dialog presenting where this information actually ENDS in

the data flow in the entire configuration, not the intermediary steps. In this case, it is at

the Dimensional model (as expected). erwin Metadata Management (EMM) knows this

because we stitched together all those separately harvested models in an earlier chapter

and erwin Metadata Management (EMM) harvested the data movement information from

the erwin Data Modeler models.

Of course, this is simply the short answer, as there may be interim models (objects) in

between, but it is the most pertinent answer if the goal, as it was here, was to determine

what end points would be impacted from and update to the Customer table.

The menu on the right shows options that control the level of detail and what is included

in the report.


P a g e 59 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

5.2 Data Source Lineage

As one would respect, when looking at the Dimensional model, this model is already

architected according to accounts receivable versus accounts payable. Thus, the most

interesting lineage query might be from the portion of the database which is shared across

these two, i.e., the GL Account table.

Click on the quick search box in the upper right and enter GL Account. The results are

long and thus we will press Enter and open the full search page.

Again, the result list is long. Click on the Show all icon or text in the Tables section.

Then click Display Filter Panel and pick the Dimensional DW model.

Now, click on GLAccount in the Dimensional DW model and go to the Data Flow tab.


P a g e 60 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Note, the option Data Lineage was automatically chosen by erwin Metadata Management

(EMM) as this table is in the last model in the data flow.

Some interesting information from this diagram:

- In the account payable system the invoice records finance account number and

although the naming varies, one can see a parallel architecture in accounts

receivable

- Also, note that any project, category and category-group association information

is coming from the Staging database alone.

Then go to the quick search and enter “Customer” and then press Enter.

Then click on Show All. Select any line and notice the icons on the right with all the

actions available.

Then, click on the Display grid icon:


P a g e 61 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Right click on any element and see the options available.


P a g e 62 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Data Governance can play a major role in developing a well managed data architecture,

which in turn is reflected in a flexible and efficient technical architecture. A metadata

management system, in particular, is a key tool in any governance process. In particular,

erwin Metadata Management (EMM) provides:

- A central portal into your technical architecture and how it interrelates

- Web based tools to support development, deployment/implementation and

management of a complete data architecture, such as

o An ISO 11179 based Business Glossary to capture, define, maintain and

implement an enterprise Business Glossary of terminology, data

definitions, code sets, domains, validation rules, etc.

o Semantic model harvesting from existing models and simple incorporation

into glossaries and including in the semantic mappings

o Logical/Conceptual Data Documenter to bring undocumented assets “into

the fold” and provide logical names, definitions, domains, business rules

and code set definitions to otherwise undocumented data stores in the

technical architecture

o Semantic Mapper to define relationships among the semantic layer assets

such as glossaries and model and the technical architecture

o Data Flow Mapper to define and/or document data processes which are or

will be a part of the technical architecture

o Full support for change management migration or forward and reverse

engineering

o Semantic usage and impact analysis and definition/lineage tracing and

reporting

- Collaboration acceleration capabilities in all facets erwin Metadata Management

(EMM) to facilitate administration, management and interaction within the data

governance process and the entire information management and technology

environment.

While the methods and processes of data governance can have a great many features in

common, in practice the actual business goals behind any data governance initiative vary

widely. While many governance initiatives have the long term goal of an on-going effort

to ensure that all the hard work early on is not lost, it is also critical to remember that

immediate (and agile) returns on investment are provided. It can also be the case that the

initiative truly is a one-time effort, solving a specific, high profile or profitable business

goal, which cannot be “bogged down” by a more rigorous and hopefully future proof

process or environment.

Because of these realities, erwin Metadata Management (EMM) is designed with a very

flexible and optional set of organizational, inter-relationship methods. It emphasizes:

The strength of a rigorous metadata definition with flexible extensibility of

attribution

6 Simple Data Governance with Business Glossary


P a g e 63 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

The power of tight integration, re-use and forward-reverse engineering with the

technical and semantic architecture that is the bread and butter of erwin Metadata

Management (EMM).

In particular, erwin Metadata Management (EMM) focuses the data governance process

in a Business Glossary.

This document is designed to help users navigate all of the features provided with the

Business Glossary and determine the best practice for them, based upon their own

specific requirements and current assets and capabilities. Instructions covering how to

use full features of the Business Glossary are provided are provided in detail and through

example in the Metadata Management Tutorial.

However, here is a brief overview of how the Business Glossary works.


P a g e 64 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

6.1 Overview of the Business Glossary features

In erwin Metadata Management (EMM), a Business Glossary is a self-contained

collection of categories and the terms sub-categories contained within each category. In

turn, the terms may be semantically mapped to objects throughout the rest of the

repository, such as tables and columns in a data model. Once mapped, one may perform

semantic lineage traces such as definition lookups and term semantic usage across any

configurations containing the Business Glossary, mappings and mapped objects.

Populating a Business Glossary can be as simple as dragging in an existing well

documented data model, via import from other sources via a CSV file format, or can be

populated directly via the user interface as well as during the process of classifying

objects in other data store models. In general, a combination of such methods are

employed in conjunction with one another.

In order to ensure that the Business Glossary is accurate, up-to-date, available to all who

need access to it and integrated properly with the rest of the metadata in the repository,

erwin Metadata Management (EMM) also provides a robust collection of Data

Governance tools and methodologies.

The Business Glossary may be part of your lineage, will appear in the repository panel

and when you open a Business Glossary, you will presented with a different UI than for

other (harvestable) models.

An important consideration when producing any semantic model (including a Business

Glossary) is to take advantage of the metadata sources with the most well defined

business metadata such as descriptions, domains, business rules, relationship definitions,

generalizations, etc. When populating a Business Glossary based upon one of these

metadata sources, erwin Metadata Management (EMM) will look for all of these types of

metadata and create equivalents within the Business Glossary. In addition, it can create a

new semantic mapping and create individual mappings between the newly create

Business Glossary equivalents and the specific metadata objects from which they were

constructed. In this way, one may perform sophisticated impact (where used) and reverse

lineage (show definition or meaning) type of lineage analysis.

In this case, we will use several methods for populating a glossary.


P a g e 65 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

6.2 Creating an abstract Business Glossary

If you have an external source of Business Glossary metadata that is not accessible via

the bridges (not harvestable), then you may use the CSV format import capability. In this

case, you may import categories terms and domains and all their properties. Many of

these external sources (e.g., on-line data dictionaries or other glossary type products) will

have additional properties or attribution on the objects that will become categories terms

and doamins in the Business Glossary after import. You may extend the Business

Glossary with any number of such addition custom attributes/attributes to support these in

the original source.

The actual format of the CSV file is provided in a sample in the erwin Metadata

Management (EMM) installation directory on the application server at:

conf\Glossary\GlossaryImportSample.csv

And is fully documented inside.

First, we will create and populate the Business Glossary that is highly abstract. In

general, as a quick start or the Business Glossary definition process, one may import

directly from an existing CSV file.

6.2.1 Create the Business Glossary

Open the metadata explorer UI. Go to MANAGE > Contents. Click Add and select

Glossary.

and name the new Business Glossary “Enterprise Glossary”. Then click on the OK button.


P a g e 66 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

6.2.2 Populate the Business Glossary

To populate the Business Glossary, we are going to use an existing spreadsheet that is

already defined for by our data governance and data administration staff. We will do this

from the Metadata Explorer UI.

Click Open.

An you are at the home page of the Enterprise Glossary in the Metadata Explorer UI

and click on the More ( ) icon and select Import Glossary Objects/Relationships.

Click the Browse… button, then navigate to

“C:\temp\Models\MetadataManagement\Finance\GlossaryCSV\

EnterpriseGlossaryObject.csv” as the location and click on the Import button.

Figure 7 - Import dialog

The CSV looks like this:


P a g e 67 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

This is a specific format that one must put the input in before importing.

The result is:


P a g e 68 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

The import from CSV produces a flat structure, but the glossary has the ability to cross-

link or reference terms with other others. Let’s do so for a few terms.

This activity, like all glossary editing functions, is to be performed in the Explorer UI.

Thus, we will need to include this glossary in our configuration.

Let’s start with the term Account. Navigate to Account Then we see the Account term:

Click the Relationships tab. Then click on the plus sign to add a relationship and choose

the More Specific relationship type.


P a g e 69 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

You are presented with a glossary navigation dialog, which allows you to select all the

terms that are more specific. In the Search box, type “Account” into the search and press

Enter (these are logical names, or term names, and thus unlikely to require wildcards as

there are spaces between words).

Figure 8 - More specific

There are many options, and as one might imagine this is an activity for a subject matter

expert or even data administrator. However, in this case the more specific examples

might include Finance Account, and then more specific even so would be Payable Account and Receivable Account.

Thus, select Finance Account and click OK. Then, click on Finance Account to navigate

to that term.


P a g e 70 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Note, the More General link back to Account. Now, we can add the More Specific links

to the other two terms Payable Account and Receivable Account.

You have now defined a glossary.

Open a term, e.g., Account Description:


P a g e 71 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 9 - Account Description term

Note, one can add full wiki-like documentation, Relationships among terms, and see the

edit log history for the term.

Note, although the Enterprise Glossary is now a part of the configuration, it is not

semantically linked to the rest of the architecture. We will next produce a glossary that is

linked directly to a Physical Data Model in the system, which we will then semantically

link to from this existing glossary.


P a g e 72 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

6.3 Glossary derived from a Model

Another way to define a glossary is to “bootstrap” it from a model imported from erwin

DM.

6.3.1 Import the Model

In this case, we are going to use the Dimensional DW model, which is already imported

as a part of the Mart model content.

6.3.2 Create and Populate the glossary

Create a new glossary named Finance Glossary. Go to MANAGE > Contents, click Add

> Glossary, provide a Name and Description.

Return to the metadata manager UI (MANAGE > Advanced Metadata Manager). Then,

drag the Mart model content into the Finance Glossary.


P a g e 73 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Pick the Dimensional DW model.

You will then be presented with a dialog box asking how to go about populating the

Business Glossary from the model:


P a g e 74 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Here you may specify:

Steward: the person (username) who is the point of contact on a term. We will

not assign this value for now and simply use the three groups defined earlier.

Category Name which is the name to provide the category, or organizational

structure (similar in behavior to a folder) within the Business Glossary which will

contain all of the populated elements. A Business Glossary may contain any

number of categories, and a category may also contain any number of categories.

Semantic Mapping: In addition, erwin Metadata Management (EMM) will

create a semantic mapping from this Business Glossary to the source model. This

way, the terms in the Business Glossary are already classified (semantically

mapped to the model elements), and will appear in the lineage reports. Of course,

this is only true if the model you dragged in is to be a part of your configuration

and lineage. In our case, that is not yet true, but will be.

Update the Semantic Mapping Name to Finance Glossary to Dimensional DW and click

on the Import button:


P a g e 75 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 10 - Glossary import log

Now, in the metadata explorer UI, go to BROWSE > Glossary > Hierarchy View and we

have:


P a g e 76 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 11 - Resultant glossary

You will see the import created four categories in the Business Glossary:

Business Rules containing the conceptual domains based upon the validation rules

defined for attributes and domains in the original Dimensional model

Dimensional DW containing the terms derived from the attributes and entities in

the original Dimensional model as well as subcategories for each subject area in

the original model. The name is the internal name of the model in erwin Data

Modeler.

Domains containing the conceptual domains based upon domain definitions

including data type information in the original Dimensional model

User Data Types which is empty for this model

6.3.3 Update the configuration

Now, we have a business glossary semantically mapped to the new Dimensional DW

model. However, this new semantic mapping is not in the current configuration.


P a g e 77 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Simply drag the Finance Glossary to Dimensional DW semantic mapping into the

Published configuration.

Go to BROWSE > Architecture diagram and let’s put this all together.


P a g e 78 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 79 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Now, let’s return to our analysis of the Finance system, this time taking advantage of the

Business Glossary.

7 More Metadata Analysis


P a g e 80 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

7.1 Terminology Usage (Impact) Analysis

One of the key use cases for any Business Glossary is to determine where a terms is

“used” (has a semantic link to) by elements within the larger system configuration that is

modeled in erwin Metadata Management (EMM). In this case, it is the Finance configuration.

7.1.1 Trace Semantic Usage

That is it. We are ready to trace semantic usage.

Recall that the use case is to determine where a terms is “used by” (has a semantic links

to) elements within the larger system configuration that is modeled in erwin Metadata

Management (EMM).

So, we need to find a term.

Go to the Metadata Explorer UI.

Click BROWSE Glossary Terms and enter “Customer” in the search in the upper

right:

Note, there are two Customer terms because we have two glossaries.

Click the one in the Finance Glossary:


P a g e 81 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

And we are at the Customer term home page.

Now, go to the Semantic Flow tab.

Figure 12 - Trace semantic usage

One may also select the term and then use the Trace Semantic Usage action icon in the

header of the list.

The result is a list of elements traced through the semantic lineage down to the physical

architecture.

Not surprisingly, as erwin Metadata Management (EMM) automatically populated the

business glossary based upon one-to-one mappings to the Dimensional DW model, the

trace is simply to the element this terms was generated from.

We can see this usage report as a graphical trace by simply using the Diagram option on

the left.


P a g e 82 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Please note that the above lineage only goes to Customer table in the Dimensional model.

Note also that the Customer term is also of Type Table.

This distinction becomes important when tracing semantic usage. A table or entity or

view is generically referred to as a classifier. And classifier level semenatic lineage is

greatly restricted as compared with feature level semantic lineage (a feature is a column,

attribute, etc.).

Let’s try the column level lineage. Go to the Relationships tab.

Then click on the empty space in the line for Customer ID or just on its icon ( ):


P a g e 83 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

And then click on the Trace Semantic Usage action icon:

Figure 13 - Trace Semantic Usage for Customer ID term (feature type)

Note, in this case there is a much broader impact. This is because, the trace semantic

usage function will also follow through the data flow architecture (like the data mappings

between the Staging and Dimensional models) for a feature, as long as there is no

transformation defined in the data flow (i.e., it is a “pass-through” mapping).

This is not the case with classifiers, as classifiers are not truly mapped, but are only

collections of items, some of which may be mapped and some of which may have

transformations.

Again, we can see this usage report as a graphical trace by simply using Graph option.

Click on the Expand the selected node icon and select To Column Level and the result

is:


P a g e 84 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Again, notice how erwin Metadata Management (EMM) automatically continues on the

“usage” trace by looking at the data flow impact. Hence, we see that a change in a

precise term can have large impact on the physical systems.


P a g e 85 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

7.2 Trace Semantic Definition

We can also use erwin Metadata Management (EMM) to look up definitions of fields in

the physical architecture, now that we have a Business Glossary and semantic lineage.

In the Metadata Explorer UI, go to BROWSE > Data Models > Accounts Payable >

Invoice.

Note, there are definitions for the tables and columns in this model. Not a surprise, as it

was imported from a modeling tool. However, we can also obtain definitions from the

glossary, even though we never mapped or classified these tables and columns to a

glossary. Because we have already captured the data flow from Accounts Payable to

Staging DW to Dimensional, then any glossary term that maps to an element that is in the

data flow can be used for the definition of this column or table in Accounts Payable.

Note, these inferred definitions will only be based upon passthrough lineage, i.e., lineage

without transformation. If a data flow trace has a transformation, the meaning is assumed

to be changed and it will not be included.

Click InvoiceDate and go to the Semantic Flow tab.


P a g e 86 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

The result is a number of possible definitions, including even based on a search in the

business glossary for additional terms and conceptual domains, as well as any other

physical data elements which have definitions which were in the path of the data flow

lineage trace or in the semantic trace.


P a g e 87 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

7.2.1 Build Glossary to Glossary Mappings

One may simply build up the classifications (semantic relationships from a glossary), but

this time between the Enterprise Glossary and Finance Glossary.

Click BROWSE Glossary Hierarchy and expand the Enterprise Glossary until you

get to the terms.

Note terms like Finance Document and Party. Very abstract and high-level.


P a g e 88 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 89 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

In particular, note Finance Document Amount. A Finance Document is any document

being exchanged in finance transactions, e.g., and invoice, purchase order, payment, etc.

Thus, a Finance Document Amount should relate to any amount on any of these

documents. We could simply define specification/generalization relationships among

those concepts in the Enterprise Glossary and then map those to the specific ones in the

Finance Glossary.

That is a good exercise for the reader.

However, we could also simply map directly from Finance Document Amount to the

specifics in the Finance Glossary. In turn then we would have an impact report on all

these amounts throughout all the systems even from the Enterprise Glossary, as the

Finance Glossary is already mapped with the Dimensional DW.

Let’s do so.

Either way, we must first build a semantic mapping from the Enterprise Glossary to the

Finance Glossary.

Go to MANAGE > Contents and click the plus sign and select Semantic Mapping and

complete it as follows:


P a g e 90 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Then layout the architecture diagram.

Click the Semantic Flow tab on the Finance Document Amount home page and click the

Map button. Note, because we already created a semantic mapping between these two

glossaries, that it only shows the Finance Glossary categories.


P a g e 91 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Expand the Dimensional DW category and click on the Terms tab in the dialog. Then

enter “amount” in the search filter.

Now, simply select the terms in the Finance Glossary that are amounts related to finance

documents (and not line items or general ledger amounts). Then click OK.


P a g e 92 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

And in the Diagram tab on the left:


P a g e 93 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 94 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

7.3 Embed the mapping

As we can both classify (embedded, system managed mapping) and semantically map

objects to other objects, it might be convenient to convert mappings to classifications.

This may be done in the Manager UI.

Right-click on the Finance Glossary to Dimensional DW semantic mapping. Select

Embed


P a g e 95 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

8 Data Governance with Business Glossary


P a g e 96 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

8.1 Glossary Semantic Mapping and Term Classification

As you can see the automatic population of a business glossary is a great boot-strapping

tool. However, it is not a final product. For instance, the example in the final chapter of

Part I of identifying all physical data elements impacted by a change in the payment

amount and associated amount fields used the existing Enterprise Conceptual Model with

generalizations (sub type/super type relationships) relating a common concept of Finance

Amount.

Part of the process of utilizing and extending the business glossary involves defining

these same types of generalizations within the business glossary itself.

At this point, it is time to use the Metadata Explorer UI, as you are going to be create

categories and terms in the repository.

Then go to BROWSE Business Glossary Glossaries.

Then click the Finance Glossary , click the Categories tab and click on the plus sign to

add a category:

Enter the name “Normalized Generalizations”:

Click OK.


P a g e 97 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Open that category. To add a term, click the Terms tab, then click the plus sign to add

terms, and create the term as shown below:

Now we will create the generalization links. Click the Relationships tab. Click the plus

sign and select More Specific.

In the Select Term(s) dialog, search for “amount”, select each term for which Finance Amount could be considered a generalization:


P a g e 98 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 99 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

and for each click the OK button.

Here are the suggested selections:


P a g e 100 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 14 - Terms which are more specific examples of a Finance Amount

Now, let’s see the results. Go to the Semantic Flow tab and click Diagram on the left.

You should see the entire usage diagram which is quite extensive for one term.


P a g e 101 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Note, if we expand the dbo nodes in both the Finance Glossary and Dimensional DW

PDM, you will see all the semantic maps you just created, showing that the term Finance

Amount is used by 8 other terms, which in turn are used by several columns in several

tables.

Now, this is one (good) way to define such generalizations that normalize the

terminology. It relies on the existence of only one glossary.

However, as you might imagine, one could separate the more conceptual or generalized

terminology into a separate glossary. In fact, we already have the basis for this. Just as

the Finance Glossary has been built based upon a data model that is fairly close to the

physical Dimensional DW PDM, we have a second glossary (the Enterprise Glossary) that

we imported from a CSV file. Perhaps, it would make sense for this organization to use

that glossary as the conceptual, enterprise wide glossary, for normalization of

terminology and ultimately for standardization.

Let’s do so now.

In order to define the same type of relationships between glossaries we will first create a

semantic mapping that will contain the semantic links among the terms.


P a g e 102 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Create this new semantic mapping, named “Enterprise to Finance Glossary” in the

Metadata Explorer UI:

Now, you may use the mapper to define links across from one glossary to the other.

Go to BROWSE > Glossary > Terms and filter to the Finance Glossary.

Let’s do the line item descriptions.

E.g., if one wanted to take the three terms in the Finance Glossary related to Line Item Descriptions and generalize them into a term in the Enterprise Glossary (left), one could

simply drag one of them from right to left and that will create a new term.

First specify “line item description” in the search box for the right-hand side. Then select

the category to add to on the left (use the X next to the search criteria to clear it and pick

a category). Then, drag and drop from the right to the left to extend the glossary one left.


P a g e 103 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 15 - Create a term by drag and drop

You will then be presented with the opportunity to change the Name and Description.

Here we will specify it as below:

Figure 16 - New name and definition

This way we have created a more general term. We may then map it to the other two

terms:


P a g e 104 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 17 - Finance Line Item Description

Here is another generalization term and relationships to define:

Figure 18 - Finance Document Number

Note, the use of the Mapping Reporter tab.


P a g e 105 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

And finally, we can even go back to the Finance Document Amount (which is already a

term in the Enterprise Glossary, no need to create a new term here) example and map to

all the specific finance amount type terms, this time mapping from the Enterprise Glossary to the Finance Glossary, rather than simply within the Finance Glossary:

Figure 19 - Finance Amount in the Enterprise Glossary as a generalization of these specific terms in

the Finance Glossary

With these generalization, we can now perform the same usage lineage trace for Finance

Amount and see all the locations where and update from Decimal(8,2) to Decimal(10,2)

is suggested, just as in Chapter 6 (Be sure to add the semantic mapping to the Finance configuration and build first):

Figure 20 - Semantic usage for Finance Document Amount


P a g e 106 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

8.2 Extending the Business Glossary with existing metadata

8.2.1 Analyze potential metadata

We will now extend the Business Glossary to include some concepts which are in the

PAYTRANS system.

Let’s take a look at what is in the PAYTRANS flat file message:

Figure 21 - PAYTRANS schema

In particular, if you scan through the features inside, the PTPYTYP has a derived type

(double click on the Derived Type link):

Figure 22 - PTPYTYP derived type


P a g e 107 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Which, in turn has a business rule. This is a coded data set, specifically with codes for

each type of payment coming from PAYTRANS.

Let’s see where this information goes. Trace the impact of this field by returning to the

PTPYTYP attribute and right-clicking and selecting Trace Data Impact. You will need to

the configuration again after all your edits to the glossary.

Here we have the graphical trace for the Finance configuration:

Figure 23 - Impact lineage trace for PTPYTYP

PTPYTYP is used to derive both the Payment Type and the Payment Status for a Payment in the Accounts Receivable database. However, clicking on the Payment Type in the

Payment table in Accounts Receivable, and navigating to its validation rule, we see a

valid value list that is quite different:


P a g e 108 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 24 - Payment Type and Payment Status valid value lists

From the thin grey line in the lineage which points to the Staging DW database, we know

that the exact same values are then passed to the Staging DW database. And it is the

Staging DW database where we derived the Payment Type and Payment Status defined in

the Finance Business Glossary. Thus, PTPYTYP is a new concept which is an example of

both Payment Status and Payment Type information. We should include it in the

Business Glossary.

8.2.2 Populate the Business Glossary

To do so, we can again drag the model, this time PAYTRANS, into the Business Glossary.

However, most of these terms are not going to stay, as they are not unique. So, we will

do something a little different this time.

First, we will specify that it should create a new category in the Business Glossary, so we

can identify it later:


P a g e 109 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 25 - Populating the Finance Business Glossary with PAYTRANS data elements

We should also create a semantic mapping (call it Finance Glossary to PAYTRANS)

between the Finance Glossary and the PAYTRANS model, as we will want to maintain

those connections:


P a g e 110 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 26 - New semantic mapping from the Finance Glossary to PAYTRANS


P a g e 111 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

8.3 Normalization of Terminology

8.3.1 Preventing redundancy

As one can imagine, many of the terms which could be added are really just new names

for an identical term. In particular, the PTAMT term mapped to the PTAMT field in the

PAYTRANS flat file is identical in definition to the Payment Amount term already in the

Business Glossary and mapping to the Payment Amount attribute in the Staging DW

model.

How do we know it is identical? One good indicator is in the data flow, and the lineage

impact trace will let us know (simple gray thin lines) that the data flow between the

PTAMT field in the PAYTRANS and the Payment Amount in the Staging DW database has

no transformation.

In fact, we can create the impact trace for the entire PAYTRANS schema:

Figure 27 - PAYTRANS impact lineage trace

And note that only three fields are not simple moves of the data:

- PTDT - PTNOTE - PTPYTYP

The others are simple moves and most likely have exactly the same meaning as a term

already in the Business Glossary. They are not needed for terminology.

Thus, we will concentrate on these three.


P a g e 112 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

8.3.2 Mapping terminology

We now have a much cleaner collection of terms, without a large number of

redundancies. We now have three additional potential terms which are not redundant:

PTNOTE

PTDT

PTPYTYP

For PTNOTE, it is truly a descriptive text field. However, the information is used in two

different places, including the descriptive field that the existing Payment Description

term is derived from. It is really a matter of choice how to correctly handle this example.

On the one hand, PTNOTE is a distinct element that has unique meaning. However, that

unique meaning is derived from the fact that the information is also used to create a

Partial Payment Reason in the Payment Assignment table in Accounts Receivable.

Looking at the actual ETL, or looking at the lineage report in the configuration, each

show that there is no transformation to PTNOTE as it is moved to Partial Payment Reason.

Thus, it contains information about the reason but merely as descriptive text.

Let’s err on the side of completeness, and add a term for the PTNOTE but give it a name

specify was it represents.

So, to create the term using the mapper, expand the source (Finance Glossary) side to the

PAYTRANS category, and drag the PTNOTE field from right-to-left (reverse) into the

source side:


P a g e 113 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 28 - Creating a term with a mapping

Now, let’s edit it like so:

And the term is created in the glossary with a mapping to PAYTRANS.


P a g e 114 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 29 - Term in glossary

Let’s edit, but this cannot be done here (not in the Metadata Manager UI). Also, to work

with the mapping in the Metadata Explorer UI, we should add it to the configuration. So,

close the mapping to ensure the changes are saved. Drag it into the Finance configuration

and build the configuration.

Figure 30 - Drag the mapping into the configuration and build

Then, returning to the Glossary, use the option Open in Metadata Explorer.

Figure 31 - Open in Metadata Explorer

And we can edit the term like so:


P a g e 115 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 32 - New name and description for PTNOTE term

In addition, we must associate this term with the others that are similar, specifically

Customer Payment Description. As this new term can refer to this term, it should be a

More Specific example of this other term.

To define those relationships, expand the Relationship sub panel for the term, click on the

plus sign and select More General

Figure 33 - Specify more general link

and select the term:


P a g e 116 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 34 - Associating more general terms with new term

Select Customer Payment Description, select and click the OK button.

Note the new relationship:


P a g e 117 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 35 - New relationships for the term

There is one more generalization to consider, i.e. the Partial Payment Reason. However,

no such term exists at this point so, we should add it.

Navigate to Finance Glossary dbo. Then click on the plus sign to add a term.

Figure 36 - Partial Payment Reason

Now, click on the plus sign to add Relationships and specify More Specific:


P a g e 118 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 37 - More specific relationship

Then select Payment Description with Reason and click the OK button.

Figure 38 - Defining relationship

Click on the original term (now linked as Payment Description with Reason).

Figure 39 - Click on link

Note the two relationships:


P a g e 119 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 40 - Both generalizations

This way, when one is requesting a usage lineage trace from either of those other terms,

this term and its related field in PAYTRANS will also be reported.

Now, a similar association might be made with PTDT. In this case, the date format of

PTDT is simply different. In other words, the meaning of PTDT term is the same as

Payment Date term. Thus, instead of creating a relationship, we will simply treat the

PTDT term as redundant with Payment Date and not create it in the Business Glossary.

In addition, there is no need to semantically map this field to the any Payment Date term

as the data flow means that the semantic definition lookup is already available:

Figure 41 - Semantic definition lookup for PTDT


P a g e 120 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Finally, we have PTPYTYP. In this case, it contains a code set which decodes to Payment Type and Payment Status. Thus, just like PTNOTE, PTPYTYP should be represented as a

more specific example of both Payment Type and Payment Status. Please update the

Business Glossary accordingly:


P a g e 121 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 122 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 123 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 42 - PTPYTYP as a more specific term to Payment Status and Payment Type

Turns out, the erwin model we used to harvest the Dimensional DW and ultimately was

used to populate the glossary does not have a business rule for Customer Payment Status,

and thus there are no code set definitions for it in the Finance Business Glossary. Thus,

we must look elsewhere for this information.

In particular, one could look at the ETL specification PAYTRANS to AR, as that is where

the transformation would be defined. Opening the model and then the target connection

(stitched to Accounts Receivable which has Payment Status and Payment Type) we see:


P a g e 124 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 43 - PaymentStatus and PaymentType code sets defined in the PAYTRANS to AR ETL

Here is a table of the values for copy and paste and reference: PTPYTYP

10 Payment Payment of an invoice in full

20 Partial Payment Partial payment of an invoice

21 First Partial Payment First partial payment of an invoice

22 Final Partial Payment

Final partial payment which should complete payment on an invoice

23 Partial Over Payment

Partial over payment which should complete payment on an invoice and includes more than the amount currently defined

30 Over Payment

Payment of more than the amount currently defined for an invoice

40 Other Payment

Payment not associated with an invoice

41 PO Payment

Payment for a purchase order that does not have an invoice associated with it

PaymentType C Payment by Check Check

E Payment by EFT EFT


P a g e 125 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

O Other Payment Other

W Payment by Wire Transfer Wire Transfer

PaymentStatus Over Paid Invoice Over Paid

Excessive payments made on invoice

Paid Invoice Paid Payment made in full to the invoice

Partial Payment Invoice Partially Paid

Partial payment of an invoice

Unpaid Invoice Unpaid No payments made to the invoice

Figure 44 - Table of code sets

Let’s add these to the Finance Business Glossary. Create a Business Rules category in the

Business Glossary, select Add Term and complete as follows:

Figure 45 - Payment Status Conceptual Domain

Then, create a category named Payment Status Values and enter the four payment

statuses as terms in that category:


P a g e 126 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 46 - Terms for Possible Values

Then, select all the codes and define them with a Type of Possible Value.


P a g e 127 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 47 - Multi-select and edit

Edit the Documentation section of each term entering the descriptive text in the table.


P a g e 128 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Associate the new code set terms with the business rule term: open Payment Status and

click on the plus sign next to Contains and select the four terms:


P a g e 129 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 48 - Edit Payment Status

Finally, link this back to the Customer Payment Type term as Represents:


P a g e 130 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 49 - Represents link

Now do the same for Payment Type: PaymentType C Check Payment by Check

E EFT Payment by EFT

O Other Other Payment

W Wire Transfer Payment by Wire Transfer


P a g e 131 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 132 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 133 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 134 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 135 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 136 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 50 - Payment Type, possible values, generalizations and links

and PTPYTYP: PTPYTYP

10 Payment Payment of an invoice in full

20 Partial Payment Partial payment of an invoice

21 First Partial Payment First partial payment of an invoice

22 Final Partial Payment

Final partial payment which should complete payment on an invoice

23 Partial Over Payment

Partial over payment which should complete payment on an invoice and includes more than the amount currently defined

30 Over Payment

Payment of more than the amount currently defined for an invoice

40 Other Payment

Payment not associated with an invoice

41 PO Payment Payment for a purchase order that does not


P a g e 137 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

have an invoice associated with it


P a g e 138 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 139 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 140 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 141 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 142 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

8.4 More Editing Terminology in the Metadata Explorer UI

As business users, including subject matter experts and stewards, are often the source, if

not the authority, concerning defining information for terminology in a business glossary.

However, most of these users will use the Metadata Explorer UI exclusively. This is why

erwin Metadata Management (EMM) placing these editing functions of the business

glossary terminology and categorization within the Metadata Explorer UI.

8.4.1.1 Users, Permission and Configuration

We have been working as Administrator, which has permissions to everything. Instead,

as a non-admin user (again Bob), one, of course, must have edit permissions on the

glossary. The Bob does not have these permissions at this time, so let’s assign them.

After all the changes from before, please go to the configuration and build.

We do not want all business analysts to have this permission, so we will create a new

group Glossary Editors which will.

Figure 51 - Creating the Glossary Editors group

Now, assign the Bob user to the group Glossary Editors:


P a g e 143 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 52 - Assign Bob to the Glossary Editors group

Then, right-click on the Finance Glossary and select Settings:

Figure 53 - Setting for Glossary

Select the Security tab and select Glossary Editors as an Editor for the glossary and click

Save:


P a g e 144 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 54 - Setting permissions on the glossary

Now, open the Metadata Explorer UI for the configuration and browse to the terms in the

glossary:

Figure 55 - Browse terms

So, a subject matter expert could quickly see what needs to be documented by specify a

filter such that it shows only those terms for which no Definition exists, like so:


P a g e 145 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 56 - Filter terms to those without Definition

Then, to edit a term, e.g., the first in the list is the Category_Number, simply click on it

to open it and click on the space below the Name of the term where the Definition

should be displayed:


P a g e 146 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 57 - Updating the definition of a term

Any other property works the same way, e.g., Data Type:

Figure 58 - Updating the Data Type for a term

Also, one may assign labels and comments as always:

Figure 59 - Assigning labels to a term

8.4.1.2 Bulk Editing

In fact, this idea of labeling a number of terms to be Jons Tasks sounds like a good idea.

However, one would not want to do so by opening up each term. So, let’s work in bulk.


P a g e 147 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Use the browser back button to return to the list of terms and note that your previous

filter is still applied. Use the Reset button in the Filters panel then close the panel.

Now, in order to label a large number of terms, first make sure that they are all shown on

the page by specifying the Items per page option to be large enough:

Figure 60 - Setting Items per page

Now, click on the Account row, then Shift-Click the Account Status row. Note, the

number of rows selected appears in the upper right:

Figure 61 - Number of rows selected

An the (Edit) and (Delete) icons appear next to it. This allows one to bulk edit the

properties of the selected terms or delete them in bulk.

Let’s add a few more terms to assign to Jon. Use the CTRL-Click or just the check-box

on the far left of each row you want to also include. Always try to click outside of an

area that is active (like the term name which will open the term).

Click on the (Edit) icon, and check the box next to Labels, specify the bulk action

Add, and pick JonsTasks as the label:


P a g e 148 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 62 - Bulk assignment of a label

And click OK.

Now, if you filter by JohnsTasks, you will have his to do list.

8.4.1.3 Grid View

Just as we did with browsing columns across models, one can use the grid view to view

and even edit in a spreadsheet like manner.

Switch to the grid view (Click on the icon) and note the current filter remains in

effect. We may now edit all the properties of these terms quickly and efficiently. Some

notes:

To edit a cell, double-click on the cell.

Not all cells will be editable. Those that are have a small gray tip at the lower

right of the cell.

If you use the tab key, it will move to the next cell to the right, unless that cell is

not editable. Then you must press the tab key several times to “pass over” the

fixed cells.

If you use the up or down arrow key, ou move a cell up or down that is the next

editable cell. You do not need to pass over those in the arrow key case.

Of course, all the quick filtering and bulk editing defined earlier works for the business

glossary grid view as well.


P a g e 149 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Let’s revisit the subject matter expert. Again, let’s quickly see what needs to be

documented by specify a filter such that it shows only those terms for which no

Definition exists, like so:

Figure 63 - Filter terms to those without Definition


P a g e 150 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Then, to edit the definitions, let’s move the column to the left (drag the column to where

you want), then double click on the first description and edit. You may do as many as

you want.

Figure 64 - Grid view editing

E.g., right-click on the cell in the with type Domain in the Type column:

Figure 65 - Quick filter

And select the first menu item and you have only terms of type Domain:


P a g e 151 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 66 - Quick filter result


P a g e 152 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

8.5 Report Glossary and Report Documenter

Finally, as we saw earlier with the Enterprise Conceptual Model, it is possible to

semantically map directly to report elements. We wish to do that again with the Business

Glossary, this time to produce a report glossary of terms to be associated with elements in

reports and the reports themselves. We will also take advantage of the report documenter

capability in this exercise.

Create a new semantic mapping named Finance Glossary to Tableau

Figure 67 - New semantic mapping

that maps between the Finance Glossary and Tableau model:

Figure 68 - Semantic Mapping from glossary to reporting

Now, again, we could populate this mapping in the mapper as we did before. However,

this time we will populate it from the Metadata Explorer UI using the Report Documenter

capability.


P a g e 153 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

So, close the semantic mapping, open the Finance configuration, add this new semantic

mapping

Figure 69 - Add semantic mapping to configuration

and layout the Architecture Diagram nicely:

Figure 70 - Architecture Diagram

Now, sign in as Bob in a new browser session and navigate to the MM Tutorial report in

BI Reporting (Browse Tableau Workbooks):


P a g e 154 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 71 - Select Workbooks

Click on MM Tutorial

Figure 72 - Report with Glossary panel

Note, the Glossary panel and plus sign icon. This appears because of the existence of the

semantic mapping we just defined in the configuration. This panel allows one to create a

report glossary, which is a set of links to glossary terms for this report and any of the

elements contained within the report.

Note, this icon (Link to term or plus sign) is disabled. This is because we do not have

sufficient privileges to edit the semantic mapping. So, return to the browser session

signed in as Administrator and set these permissions to the semantic mapping:


P a g e 155 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 73 - Settings for the semantic mapping

Define permissions:

Figure 74 - Setting security roles for semantic mapping

We already have permissions for the Finance Glossary as Bob is a member of Glossary Editors.

Now we may begin.

Return to the Bob session and navigate back to MMTutorial. Then, click on Outstanding

Customer Invoice Amts.


P a g e 156 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 75 - Outstanding Customer Invoice Amts page

and click on the plus sign (Link to term) in the bottom right of the page in the Glossary

panel:


P a g e 157 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 76 - Link to term dialog


P a g e 158 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Click on Create Category, and name it Reports.

Figure 77 - Create category

Open that Reports category and then click on Create Term. Give it the Description

“Invoices that are not in fully paid status”. Click OK.


P a g e 159 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 78 - Create term

And the link is shown:


P a g e 160 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 79 - Linked to glossary

So, we have associated a report with a glossary term and thus a definition. This should

be made available in an easy manner, and it is.

Use the browser back button to go back one screen to the MMTutorial page. Note the

Open Business Glossary icon in the upper right of the page.

Figure 80 - Glossary icon

Click on this and note the glossary lists all terms linked to this report and its contents.


P a g e 161 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 81 - Glossary report

And note that the worksheet (report) named Outstanding Customer Invoice Amts has the

definition we gave it:

Figure 82 - Definition of worksheet

However, where did all the other definitions come from? As we described before, these

definitions are based upon tracing the lineage (semantic and data flow) to hunt for

definitions. So, e.g., with the report Outstanding Customer Invoice Amts, we trace

directly back to the term in the Finance Glossary:


P a g e 162 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 83 - Direct semantic link

On the other hand, for Account Amount Available, it is a combination of a data flow

lineage trace back to the Dimensional DW PDM and then a semantic trace back to the

term Account Amount Available in the Finance Glossary.

Figure 84 - Definition lookup trace for Account Amount Available

Actually, as we saw before, there are many definitions possible for Account Amount

Available. This report only shows the highest priority one. In addition, in the report, one

may control which types of lineage traces are used to determine the possible definitions:

Figure 85 - Glossary report options

Note, there are some fields in the report, e.g., Purchase Order Amount, where we see

<Empty definition>. This is the result of locating a term or other object that is the


P a g e 163 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

highest priority, but it does not have a definition. This is simple to fix, of course. Simply

click on the object that there is not definition for:

Figure 86 - Object without definition

Which takes you to the page for that term and you may edit the definition:

Figure 87 - Editing the definition

Now, the report is updated (use the refresh browser button):

Figure 88 - Updated definition on report

In addition, there are some fields on reports that have no associated object at all. This

can be the situation when a field is unique to a report, often times because it a computed

field (computed in the report) so it cannot take advantage of the warehouse definitions,

and it does not have a direct semantic link to a term in the glossary.

To see these missing fields and any other object one can edit, click on the Edit button:

Figure 89 - Editing the glossary report


P a g e 164 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Note the number of items documented is presented (62 out of 91 possible). Also, note the

Add definition option. Now, for some “fields” in the report, they are not really seen by

the business user, e.g., Customer Dimension ID, and thus no definition is really required

and the glossary report will not show it. However, for others, the Customer Payments

report itself, we could click on the Add definition option, and then add a link to a

glossary element right here in the glossary report.


P a g e 165 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Some data flow processes are not harvestable using the bridges provided as a part of the

erwin Metadata Import/Export tool suite. Of course, if these processed are not modeled

in erwin Metadata Management (EMM), it will leave gaps in the lineage and impact

analysis answers and provide an incomplete picture of the physical architecture of your

systems.

In order to address these gaps and produce proper lineage and impact results, erwin

Metadata Management (EMM) has a data mapping specifications editing and

management toolset. Data Mapping Specifications are essentially simply high-level

logical (or notional) definitions of the way data “flows” from some number of source

models into elements of a target model. These mappings are specified using a simple

web based drag and drop type mapping specification editor and are defined using

descriptive text and one may also define pseudo operations using an operation editor.

In this chapter we will learn how to take advantage of these tools and capabilities.

9 Data Mapping Specifications


P a g e 166 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

9.1 Constructing a data mapping specification

The data mapping specifications form a content within erwin Metadata Management

(EMM) which defines logical mappings between source and target data stores. The data

stores themselves are modeled separately as model contents within erwin Metadata

Management (EMM) but external to the data mapping specifications, as shown in this

diagram:

Figure 90 - Mapping Specification Construction

Each data store model content is referenced as either a source, a target, or can be both a

source and target. One may then drag and drop objects (e.g., schemas, tables or columns)

in a data source onto objects in a data target, thus creating maps. These maps may then

be documented in descriptions or with more explicit operations.

Data Mapping Specifications

Data Source

Data Source

Data Target

Data Target

Model Model Model Model Model

Descriptive

Maps

Data Source


P a g e 167 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

9.2 Simple Load

Quite often, the gap in the lineage for metadata analysis is simply a direct load of data

from one datastore to another. In this case, it is fairly straight-forward to create a data

mapping specification to represent this data movement in erwin Metadata Management

(EMM), thus providing full lineage reporting through that mapping.

Let’s get started.

We have a new data mart which we wish to add to the system. Let’s import the model.

Create a new model in the named Vendor Mart. It is an SAP PowerDesigner 16.x model.

Import the model already provided at:

…\MetadataManagement\Finance\PowerDesignerPdm\VendorMart.pdm

Note, we have a nicely modeled data store:

Figure 91 - Diagram in Adjustments model


P a g e 168 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

This model looks like a close match to the Dimensional model. In fact, according to the

designers it should be, as they say it is a simple move (using some javascript based move

scripts) from the Dimensional database. So, let’s see if we are lucky and a simple schema

level map will work.

Now create a new data mapping by clicking Add > Data mapping:


P a g e 169 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Name the data mapping specifications as “Dimensional to Vendor Mart”. Then, click on

the Open button. You now have a data mapping home page.

We begin by creating a bulk mappings inside the Data Mapping. Click the Mappings

tab and click Create, and select Bulk Mapping. Now, click on the new bulk mapping.

Click the the Select button on the right side. Select the <no name> schema (common

in data models not to have a schema name) in the Vendor Mart model in the target

selection dialog:


P a g e 170 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Click the Select button on the left (source) side. Select the dbo schema in the

Dimensional DW model in the source selection dialog.

Now detect links and use the defaults in the dialog.

Note that all the target tables have mappings.

So, the mapping is complete with one action.


P a g e 171 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Click the Save button

Now go to the Architecture Diagram tab and edit the layout of the diagram to move the

mapping specification and new model as shown here:

Figure 92 - New Mart and mapping

We now have a good configuration, showing the mapping specification to the Vendor Mart. So, now when we trace lineage, say from the Vendor table in the Accounts Payable model, we now see this model as part of the impact trace:

Figure 93 - Lineage impact trace for Vendor


P a g e 172 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

9.3 Detailed data mapping specifications

In this scenario, we are presented with a data source which while not new is new to the

Finance configuration we have so far worked with. This new data store is a relational

database, and we have a good data model of it, so it is well documented.

Let’s import the model.

Create a new model named Adjustments. It is an erwin Data Modeler model:

Import the model already provided at:

C:\Temp\Models\MetadataManagement\Finance\Caerwin9Xml\Adjustments.xml

a nicely modeled data store for the logical model:

Figure 94 - Logical diagram in Adjustments model

While, the physical side is less obvious:


P a g e 173 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 95 - Physical diagram

However, the load process is a code based an application, and there is no easy way to

extract the mapping metadata from it.

There is some mapping documentation (text based) of the basic source-target

relationships involved and even some descriptive transformation text. We will use all of

this to build a logical representation of the mapping, called the data mapping

specifications.

Add a new Data Mapping. Name the data mapping specifications as “Adjustments to

Staging”. Then, click on the Open button.

You now have a data mapping home page. We begin by creating a query mapping inside

the data mapping. Click the Mappings tab and click Create, and select Query Mapping.

Then, select the target tables to map to.

Before we do so, however, it would be good to discuss mapping project management. In

particular, when defining a task for mapping, it is often important to first define a scope

for the mapping effort. In general, this scope is simply a specification of which source

and target elements should be included in the resulting mapping.


P a g e 174 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Secondly, one would like to track progress as the effort progresses. It could take some

time to collect the proper information to document and certify all of the mapping

definitions (and potentially operations). Thus, one would like to track the status of each

mapping and report on this.

erwin Metadata Management (EMM) provides the basic features to help manage a data

mapping specification workflow process, as show below:

Figure 96 - Data Mapping specification workflow process

9.3.1 Include business names

As it will be convenient to refer to elements by their business names when working with

a mapping specification (basically a business level object), please add the Business Name

column to the source and target side:

Create Mapping Specification

Define Scope of Mapping

Include Source and

Target Models

Include Source and

Target Tables Create

Content

Document Mapping Specifications

Drag and Drop Source Columns to

Targets

Edit Mapping Description

Optionally Edit Mapping

Operation

Approve / Certify

Mappings


P a g e 175 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 97 - Add business names

9.3.2 Creating a map

Returning to the dialog, filter the Content to the Staging DW (target) model:

According to the mapping documentation, we have three tables to target:


P a g e 176 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Customer Payment

GL Account

Vendor Payment

So, select these three table and click on the OK button.

We now have three mappings, one for each target table.

Open the first one, Customer Payment, and click on the Sources plus sign to include

source tables.

Note, from the mapping documentation, let’s see what the mapping documentation says: Customer payments are created for each adjustment which is >0.

Thus, filter to the Adjustments model and then select the Adjustment table.


P a g e 177 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Now try the Magic Wand to match the columns.

There are no matching column names, so we will have to map the columns manually.

At the column level, we see that Adjustment.TransactionAmount is used to populate

Customer Payment.PaymentAmount, Vendor Payment.PaymentAmount and GL Account. AmountAvailable. Expand the Adjustment source table and Customer Payment

target table and drag the TransactionAmount column to the PaymentAmount column,

creating a map:


P a g e 178 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Column level maps are seen as target defined, meaning that each column mapped in the

target defines an individual map which may have references to one or more source

column. In this way, this map just created is referred to as the Customer Payment.PaymentAmount map, and any description or operation is thus identified.

Note, the operation is already populated with the source column physical name

(Adj.TransAmt). One can simply drag and drop into the Operation to include additional

columns.

Let’s see what the mapping documentation says: Customer pay amount is derived from all adj amount

Thus, we need to make an entry to the Description for this mapping, copying in the line

of text from the mapping documentation except above.

Figure 98 - Pasted mapping

With that map completed, drag the following three source columns into the PaymentID

target column:

- AdjNum (Adjustment Number) - TransDT (Transaction Date)


P a g e 179 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

- TransSetNm (Transaction Set Name)

In this case, the target column is to be composed from the three source columns

identified. Enter the text “Based upon Adjustment Number, Transaction Date and

Transaction Set Name” in the Description field, either through typing only or also using

the drag and drop to populate the text.

With the mapping defined in this way, lineage will be shown but no meaningful operation

will be presented.

Finally, according to the requirement for the last column map to the PaymentDescription,

the column map should be:

Text constructed from Adjustment Reason and the decoded value of Adjustment Type Code depending upon the Transaction Set Name: - if Transaction Set Name is “Other” then it is a simple action with little information about type and so the type should not be included here Otherwise, the decoded value of Adjustment Type Code should be included in the description text.

Thus, drag the Adjustment Reason and Adjustment Type Code into the

PaymentDescription:

As one can see from the above description, some of the source information will come

from a lookup of the Adjustment Type Name and Adjustment Type Description in the

Adjustment Type table. Hence, we will need to drag and drop from columns in the

Adjustment Type table, and thus must have it opened on the source side.

Click on the Sources plus sign to include the Adjustment Type source table.

Filter to the Adjustments model and then select the Adjustment Type table.

Now, one may drag and drop the two columns into the PaymentDescription column on

the target side along with the Adjustment Type in the Adjustment Type Table and

populate the Description.

Click on the Mapping Reporter tab and note the maps as defined is presented:


P a g e 180 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Now go to the Architecture Diagram tab and edit the layout of the diagram to move the

mapping specification and new model as shown here:

Figure 99 - New Mart and mapping

We now have a good configuration, showing the mapping specification to the Staging DW. So, now when we trace lineage we will see this new database as part of the lineage.

You may do the rest by following the mappings as specified in the appendix.

In addition, you may update the mapping from a spreadsheet format.


P a g e 181 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

10 Advanced Business Glossary Workflow

In order to ensure that the Business Glossary is accurate, up-to-date, available to all who

need access to it and integrated properly with the rest of the metadata in the repository,

erwin Metadata Management (EMM) also provides a robust collection of Data

Governance tools and methodologies. The erwin Metadata Management (EMM)

Business Glossary provides a very flexible workflow and publication process that may

alternatively be quite sophisticated or quite simple depending upon one’s needs. In

addition, one may maintain any number of business glossaries, each with different

workflow and publication characteristics.

erwin Metadata Management (EMM) separates the publication process (making the

correct terminology available to the proper environments) from the term status/approval

process. This is a very important distinction and means one can avoid complex

publication hassles and potential roll-backs. It is in fact managed by the same robust

version and configuration management capabilities built into erwin Metadata

Management (EMM) and seen in earlier chapters. We will see how we take advantage of

these capabilities to support the workflow and in particular publication process.


P a g e 182 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

10.1 Overview of the advanced Business Glossary features

10.1.1 Glossary Workflow

By default, a Business Glossary will have no workflow requirement (including no

approval process). In this simple state changes made to the Business Glossary are

reflected immediately throughout the system. This is a very useful mode for

organizations that dod not want the complexity of a workflow process. It is also useful

for other organizations when they are first building and populating a Business Glossary

and related semantic mappings.

The erwin Metadata Management (EMM) also provides a very flexible and complete set

of possible workflow and publication processes that one may employ. Choose these

processes carefully, as once selected they cannot be undone or changed.

When your company would like to have a formal glossary development process that

involves multiple users you can enable the glossary workflow. The workflow is based

upon a common sequence of glossary activities around term proposal, review,

acceptance, publishing and depreciation. It is a flexible process that can be customized to

require only publishing activity, approval with or without review, approval and review by

one or multiple users, etc.

10.1.2 Workflow Roles

A user with the Administrator security role can enable the workflow and assign the

following workflow roles to Categories:

Editor

Reviewer

Approver

Publisher

A workflow role can be assigned to users and applies to all terms in the category. A

Category inherits all user-to-role assignments from the parent category and can have

additional ones.

10.1.3 Stewards

Stewards are users or groups of users who are assigned as point of contact to answer

questions for specific terms or entire categories. They have no special workflow role

assignments based upon their stewardship assignment.

Stewards are also the users (and groups of users) who are kept updated with workflow

status reports on terminology that they are stewards of and if a category is flagged for

notification.


P a g e 183 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

10.1.4 Workflow process options

The workflow process applies to terms, but not categories. All changes to Categories

made in the Manager UI are immediately visible (published) in the Explorer UI. When

the workflow is enabled you cannot delete a category that has published terms.

The most complete workflow possible is in the diagram below:

You can enable the workflow when you create the glossary or after. You cannot disable

the workflow after it has been enabled.

10.1.5 Term management dashboards

Workflow driven search criteria are available allowing one to efficiently organize terms

and identify what requires action at any given time. These include:

Show all my candidate terms

Show all my draft terms

Show all terms under my review

Show all terms pending my approval

Show all term ready for me to publish

10.1.6 Workflow transition buttons

When working with individual terms which are at some point in the workflow process,

workflow transition buttons prompt you with possible actions, e.g., if a term is in Draft status, then the action icons would include:

Start Review

Submit for Approval

Mark for Deprecation

Discard

10.1.7 Versions

The Business Glossary is one of the content types erwin Metadata Management (EMM)

supports. As a content, it can have multiple versions. You can employ different Business

Glossary workflow strategies that involve one, two and multiple versions of the glossary.

Here are some options:

Simple - single version

Dev vs. Prod - development and published versions

Snapshots - historical versions


P a g e 184 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

The Business Glossary may be part of your lineage, will appear in the repository panel,

and when you open a Business Glossary you will presented with a different UI than for

other (harvestable) models.

10.1.8 Categories

A Business Glossary is organized into categories, which may then contain terms or other

categories. Categorization can help with:

Subsetting by subject matter or organizational structure

Managing stewardship assignments (at the category level)

10.1.9 Relationships

Terms may be cross-linked in a wide variety of relationship types, including:

Synonyms

See Also

More General

More Specific

Contains

Contained By

Represents

Represented By

Simply edit a specific term to do so.

10.1.10 Flexible and optional workflow process

The Business Glossary provides a comprehensive yet flexible and even option draft and

candidate based edit/review/approve process (workflow). This workflow involves users

with Editor, Reviewer or Approver responsibilities. Anyone with Administrator security

role to the configuration may assign these workflow roles to users by setting these roles

at the category level. This may be done for groups of users as well as individual users.

In addition, the process of publication is idependent of the rest of the optional workflow

steps. Publication of a draft of a term in the glossary means that this new version is now

visible to users in the Metadata Explorer UI. In this way, one has full control over

publication and dissemination of terms independently of where they are in the workflow

process.


P a g e 185 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 100 - Complete Workflow diagram

Table of Business Glossary term publication status possible values:

Publication Status Description

New Term Candidate draft term before it is first published

Published Term Term that has been publised and the non-draft properties are visibile on the metadata explorer UI

Deprecated Term Term that has been deprecated after having been a published term. It is not longer visibile on the metadata

Publisher

Approver

Reviewer

Editor

Propose Candidate

Create Draft

Start Review

Draft

Under Review

Discard

Submit for Approval

Request Change

Recommend Approval

Send to Draft

Approve Reject Pending Approval

Approved

Published

Reject

Publish

Poof Mark for Deprecation

Deprecated


P a g e 186 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

explorer UI

Figure 101 - Term workflow status table

Status may be assigned term by term, or at the category level (all terms contained within).

In addition, the Metadata Explorer UI only shows assets which are in Approved status,

while the Metadata Manager UI allows one to search for assets by status and steward. For

example:

An Approver can list assets that are ready for approval, with the Reviewed status.

An Editor can list assets assigned to her/him as Steward that are in draft mode,

Candidate status.

A Reviewer can list assets in a particular category or the whole Business Glossary

that are under development, with Candidate status.

Basic Rules:

You can edit Candidate assets only.

An Editor can submit an asset for approval by setting its status to Reviewed.

An Editor can change the status back to Candidate to continue editing an asset.

Only and Administrator can assign a Steward to an asset.

Only an Approver or an Editor can change and asset’s status.

Permission View Reviewer

Update Editor

Administer Approver

Term Create No Yes Yes

Delete No Yes Yes

Edit Attributes No Yes* Yes*

Assign Steward

No No Yes*

Change Status

No Candidate<->Reviewed

Candidate, Reviewed, Approved

Category Create No Yes Yes

Delete No Yes Yes


Assign Steward

No No Yes

Domain Create No Yes Yes

Delete No Yes Yes



P a g e 187 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Assign Steward

No No Yes

Comment Yes Yes Yes

* When a user is steward (or when there is no steward assigned) and the Term is Candidate Figure 102 - Permissions and role table


P a g e 188 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

10.2 Configuring the Glossary for Workflow

10.2.1 Configure the Glossary

Next, the workflow settings. Go to the Workflow tab and click on the Enable Workflow

and Publishing checkbox and you will see the following:

Figure 103 - Enabling Workflow

A dialog box is presented warning you that this is a permanent operation. Once you

enable workflow for a glossary it cannot be removed.

Here are the options explained

Option Description

Allow any user to propose items

Terms may be proposed (creating a draft) by anyone. Otherwise, terms may only be proposed by the by the Editor.

Allow approval of terms Include workflow steps requiring approval of terms. Otherwise draft terms go straight to approved status

Allow review of terms If the approval workflow steps are enable in the above option, then this option will also include workflow steps requiring a review process. Otherwise, candidate terms go straight to already reviewed status.

Publish on Approval Eliminates the requirement to publish where all approved terms are automatically published to the Metadata Explorer UI. Otherwise, approved terms must be published in order to appear in the Metadata Explorer UI.

Figure 104 - Workflow options

We will leave all the defaults:


P a g e 189 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 105 - Workflow settings

And click the Save button.


P a g e 190 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 106 - Complete Workflow diagram

In the above diagram

The four workflow roles are the horizontal bands

Activities conducted by each role (expressed in the metadata explorer UI as

workflow buttons)

The process flow (arrow lines)

Draft/Published/Deprecated terms are ovals.

Basically, the process will be as follows:

Publisher

Approver

Reviewer

Editor

Propose Candidate

Create Draft

Start Review

Draft

Under Review

Discard

Submit for Approval

Request Change

Recommend Approval

Send to Draft

Approve Reject Pending Approval

Approved

Published

Reject

Publish

Poof Mark for Deprecation

Deprecated


P a g e 191 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

10.2.2 Published configuration version

Finally, we need to manage the Finance configuration to support the two versions of the

Enterprise Glossary. Currently, the Development version of the configuration is also the

Published one.

Figure 107 - Finance configuration versions

However, we want the default configuration (published) which is assigned to business

users by default to be the one that has the Published version of the Enterprise Glossary.

Thus, we should create a new configuration version which will be the default or

published version and will contain the Published version of the Enterprise Glossary.

Then the Development version of the Enterprise Glossary may contain he Development version of the Enterprise Glossary. Both will contain the same versions of all the other

models.

So, Create a Copy of the existing Development version of the Finance configuration.


P a g e 192 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 108 - Create a copy of the configuration

Rename the Development version to v7 and rename the new version to Development.

Figure 109 - Rename the versions

Then, open the v7 version of the Finance configuration and drag the Published version of

the Enterprise Glossary into the v7 version of the Finance configuration. the

configuration.


P a g e 193 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 110 - Drag and drop

Then, open the Development version of the Finance configuration and drag the

Development version of the Enterprise Glossary into the Development version of the

Finance configuration. the configuration.

Figure 111 - Drag and drop

Now, everything else will be performed in the metadata explorer UI. Mostly in the

Development version of the Finance configuration which contains the Development version of the Enterprise Glossary.

10.2.3 Defining groups to support glossary roles

So, let’s define four roles:

Group name

Username

Full Name of User

Description Default Configuration

Glossary Ed Edward Editor of the Glossary for Finance


P a g e 194 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Editors Tutorial

Glossary Reviewers

Reece Reece Reviewer of the Glossary for Tutorial

Finance

Glossary Approvers

Ann Angela Approver of the Glossary for Tutorial

Finance

Glossary Publishers

Paul Paul Publisher of the Glossary for Tutorial

Finance

Casual Users

Cass Ed Reece Ann Paul

Cassie Casual user of the Glossary Finance

Do so again by clicking on Tools Administration Groups and adding all four, e.g.:


P a g e 195 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 112 - Create group

Then, go to the Users tab and create the four users and assign each to one of the roles as

in the table above:

Figure 113 - Users

Be sure that they are also Stewards (all except for Casual Users) so they may be notified

of changes.

Then right-click on the Enterprise Glossary and select Settings, then go to the Security

tab and specify security roles as follows:


P a g e 196 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 114 - Security roles on glossary

Note, we have given the Glossary Editor security role to the Business Analysts group and

the Casual Users group. We did this so that Bob and Cass can take advantage of the

Allow any user to propose terms option.

As a final step so we can see what the average business user will see, let’s assign

10.2.4 Workflow Roles

Let’s assign workflow roles. Open glossary the Right-click on the Enterprise Conceptual

Model category and select Open in Metadata Explorer:


P a g e 197 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 115 - Metadata Explorer

Now, recall that with workflow enable, the Enterprise Glossary now has two active

versions, Published or Development. If you open the Published version, as most users

will by default, workflow roles are not assigned. Thus, you must first open the

Development version. One may see the version in the header.

Thus, if you are in the Published version, please use the More icon and select Open

Development Version:

Finally, click on the More actions icon and select Assign Workflow Roles:

Figure 116 - More actions

And we assign as follows:


P a g e 198 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 117 - Assign Workflow Roles

Note, we have assigned groups in most cases, but also the Business Analyst user is also

made a reviewer. In addition, the any users who are members of the Approver group will

have the Reviewer role.

OK, so let’s take a look at some of the glossary workflow steps. In particular, we will

again create some good generalizations to unify terminology in this glossary.


P a g e 199 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

10.3 Glossary Workflow

10.3.1 Propose a draft

In a session signed in as Cass, you will be signed in to the Metadata Explorer UI. Search

for terms in the Enterprise Glossary only that have “Amount” in the name.

Figure 118 - Terms with “Amount” in the name

Again, we see three groupings:

General Ledger account amounts

o Amount Budgeted

o Amount Encumbered

o Amount Expended

o Amount Funded

o And what should be a generalization but is not defined as one: Finance

Account Amount

Finance document amounts

o Late Payment Amount

o Finance Document Amount

o Finance Document Line Item Amount

Cass proposes to tackle the first generalization: Finance Amount, as a generalization of

Finance Account Amount and Finance Document Amount.

So, click on the plus sign in the Terms panel:

Figure 119 - Add Term


P a g e 200 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

And select Add Term:

Figure 120 - Finance Amount

Yet, after clicking the OK button, still Finance Amount is not in the list:

Figure 121 - Finance Amount in the glossary

Now, you might ask, where did it go? This is because you signed in as Cass and Cass get

the default or Published version of the configuration which contains the Published

version of the Enterprise Glossary.

To see the new term, you must sign in as a user that has access to the Development version of the Finance configuration which that contains the Development version of the

Enterprise Glossary.


P a g e 201 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Before we do this, it is important to note, because of this optional ability to propose draft

terminology in the glossary even though it is under workflow means that there is still

opportunity for crowd-sourcing extensions to the terminology while existing terms are

under tight control.

10.3.2 Edit

Now, to continue to work with this term, we must sign in as a user that has such access,

which is Ed.

Note, when you sign in as Ed, you also see the metadata explorer UI by default.

Figure 122 - Explorer UI for Ed

This is because the group he is a member of (Glossary Editors) was assigned a default

configuration.

Note also, in the upper right you see Edward @ Finance (v7). This pulldown indicates

your current environment, and indicates which user you are signed in as and which

configuration and version you are exploring. Thus, Ed, by default, sees the Published

version of the configuration. This is again because the group he is a member of (Glossary Editors) was assigned a default configuration and this is the default or published version

(v7).

To change configurations, your may right-click on that same pull-down.


P a g e 202 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 123 - Pull-down

Select Change Configuration:

Figure 124 - Change Configuration dialog

Then, pick the Finance (Development) line item.

You may also go to the glossary and use the more actions ( ) icon and select Open

development version:

Figure 125 - Open development version

Either way, navigate to the Enterprise Glossary and use the more actions ( ) icon and

select My Workflow Tasks:


P a g e 203 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 126 - Select option

And we have.

Figure 127 - My workflow tasks

Note, all terms that require Ed’s attention are listed here.

Normally, this report is e-mailed to Ed as he is a steward for this terminology and if one

set up notification (see online help). However, it is also available here in the UI.

Click on the line item and note the

Figure 128 - Select a line

So, let’s edit the term, so we click the Send to Draft button.

Provide a comment


P a g e 204 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 129 - Provide a comment

And it is in draft mode:

Figure 130 - List of terms

Now, click on the Finance Amount term name and we may edit the term:

Figure 131 - Edited term

Please make the same edits as above.

Note the workflow options which are defined earlier in this chapter.


P a g e 205 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Now click the Start Review button.

Figure 132 - Comment to reviewers

10.3.3 Review

Now, sign in as Reece (the reviewer). Again, in the upper right you see Reece @

Finance (v7).

You must change configurations to see the new term and changes, so go to the glossary

and use the more actions ( ) icon and select Open development version:

Figure 133 - Open development version

Either way, navigate to the Enterprise Glossary and use the more actions ( ) icon and

select My Workflow Tasks:

Figure 134 - Select option


P a g e 206 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

And we have.

Figure 135 - Workflow Tasks

We could click on the term to review it, but we already know that it is good. So we click

the Recommend Approval button.

Provide a comment

Figure 136 - Provide a comment

And it is ready for approval.

10.3.4 Approve a term

Now sign in as Ann the approver. Be sure to switch to the Development configuration

and thus glossary and use My Workflow Tasks.

Figure 137 - My workflow tasks as Ann

Click on Finance Amount and click the Approve button.


P a g e 207 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

10.3.5 Publish

So, the term is approved. However, there is still one more step.

Let’s return to Cass. Signing in as her and again looking at the list of terms


And we still do not see the Finance Amount term even though it is approved. Of course,

she only sees the default or published configuration version (v7) and thus the Published

version of the Enterprise Glossary. So, how do we publish the changes?

On way would be to do what we did in the Change Management chapter and create a

copy of the Development version and place that in the published configuration version.

However, while that is a reasonable process when trying to create a frozen snapshot of

your architecture, it is not reasonable each time a term is updated. Instead, one may use

the Publish workflow step to migrate the updates over to the Published version of the

glossary from the Development version.

To do this, sign in as Paul (the publisher). Be sure to switch to the Development configuration and thus glossary and use My Workflow Tasks.

Figure 139 - My workflow tasks as Ann


P a g e 208 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Click on Finance Amount and click the Publish button. Provide a comment.

Now, let’s return to Cass. Signing in as her and again looking at the list of terms


And Cassie can see the new term.


P a g e 209 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

11.1.1.1 Importing the semantic model

erwin Data Modeler, like many other data modeling tools, is oftentimes used to document

a conceptual data architecture as entities and attributes along with domains and business

rules. This tutorial is no exception. Saves as an erwin Data Modeler .XML file, there is

an Enterprise Conceptual Model which has high-level, highly normalized concepts for a

finance system.

Import this model from C:\Temp\Models\MetadataManagement\Finance\Caerwin9Xml:

Figure 141 - Importing the ECM

And include it in the configuration.

Drag this into the configuration.

11.1.1.2 Building the Semantic Mapping

The mapping content named ECM to Staging is a semantic mapping between a conceptual

model of a generalized finance type system and the actual staging database harvested

11 Semantic Mapping


P a g e 210 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

earlier. Ordinarily, one would import the two models (conceptual and physical) and then

map them using the Mapper.

However, this mapping has already been restored. And it is only necessary to reconnect

the source and target models.

Open the mapping:

Figure 142 - Semantic Mapping from ECM To StagingDW

Now, drag the Enterprise Conceptual model to the root of the source of the mapping

(where it also says Enterprise Conceptual Model) as show here:

Figure 143 - Reconnecting ECM to source of the semantic mapping

Then drag the Staging DW model to the root of the target of the mapping as show here:


P a g e 211 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 144 - Reconnecting Staging DW as the target of the semantic mapping

In addition, we want to populate the configuration with the semantic model and mapping

we just reconnected so that we may analyze them. Drag and drop the models and

mappings defined in the Information Management (IM) Semantic folder into the

configuration.

Let’s organize, and place the models and mapping in folder, using the plus sign to Add

Folder and dragging the models in like so:

Figure 145 - Folder organization for the Finance configuration

Now, Validate again.

Switch to the Architecture Diagram tab:


P a g e 212 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Figure 146 - Finance configuration architecture diagram

Finally, for the three configurations you created, be sure to Publish the configurations so

that business users may see them:

Figure 147 - Publishing a configuration


P a g e 213 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

11.2 Configuration Architecture Diagram

Now, let’s improve the diagram’s appearance.

11.2.1 Annotation

Add annotations to the diagram, using the Annotation icon:

Figure 148 - Add annotation

Then open the Properties panel and edit the text inside:

Figure 149 - Add text to annotation

Right-click on the annotation and select Annotation Options and edit the font and colors

to match here:


P a g e 214 | 220


V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )


P a g e 215 | 220

C o p y r i g h t © 2 0 1 8 , e r w i n I n c . a n d / o r i t s a f f i l i a t e s . A l l R i g h t s R e s e r v e d . V e r s i o n 2 0 1 8 R 1 ( 1 0 / 1 6 / 2 0 1 8 )

Mapping Specification:

Destination Feature Destination Class Operation Operation Description Source Feature Source Class

CheckNumber CustomerPayment Fixed “Adjustments" Check Number

InvoiceNumber CustomerPayment Fixed “Adjustments" Invoice Number

PaymentAmount CustomerPayment TransAmt Customer pay amount is derived from all adj amount (Transaction Amount)

TransAmt Adj

PaymentDate CustomerPayment TransDT Transformation of Transaction DateTime

TransDT Adj

PaymentDescription CustomerPayment AdjTxt Adjustment.AdjTyp Adjustment Type.AdjTyp AdjTypTxt AdjTypNm


AdjTxt Adj

PaymentDescription CustomerPayment AdjTxt Adjustment.AdjTyp Adjustment Type.AdjTyp

Text constructed from Adjustment Reason and the decoded value of Adjustment Type Code depending upon the Transaction Set Name:

AdjTyp Adj

Appendix A


P a g e 216 | 220


AdjTypTxt AdjTypNm - if Transaction Set Name is “Other” then it is a simple action with little information about type and so the type should not be included here Otherwise, the decoded value of Adjustment Type Code should be included in the description text.



AdjTyp AdjType



AdjTypTxt AdjType


P a g e 217 | 220




AdjTypNm AdjType

PaymentID CustomerPayment AdjNum TransDT TransSetNm

Based upon Transaction Set Name, Adjustment Number and DateTime

AdjNum Adj



TransDT Adj



TransSetNm Adj

PaymentStatus CustomerPayment Set to ”Paid in Full"

PaymentType CustomerPayment Fixed Adjustments" PaymentType"

AccountAmountAvailable GLAccount TransAmt Subtract Transaction Amount from the Account Amount Available for the fixed Adjustments" GLAccountNumber"

TransAmt Adj

GLAccountNumber GLAccount Fixed Adjustments" GLAccountNumber"

CheckNumber VendorPayment Fixed “Adjustments" Check Number

Description VendorPayment Adjustment Type.AdjTyp AdjTypTxt AdjTypNm

Text constructed from Adjustment Reason and the decoded value of Adjustment Type Code depending

AdjTxt Adj


P a g e 218 | 220


AdjTxt Adjustment.AdjTyp

upon the Transaction Set Name: - if Transaction Set Name is “Other” then it is a simple action with little information about type and so the type should not be included here Otherwise, the decoded value of Adjustment Type Code should be included in the description text.

Description VendorPayment Adjustment Type.AdjTyp AdjTypTxt AdjTypNm AdjTxt Adjustment.AdjTyp


AdjTyp Adj


Text constructed from Adjustment Reason and the decoded value of Adjustment Type Code depending upon the Transaction Set Name: - if Transaction Set Name is “Other” then it is a simple action with little information about type and so the type should not be included here Otherwise, the decoded value of Adjustment Type Code should be

AdjTyp AdjType


P a g e 219 | 220


included in the description text.



AdjTypTxt AdjType



AdjTypNm AdjType

PaymentAmount VendorPayment TransAmt Customer pay amount is derived from all adj amount (Transaction Amount)

TransAmt Adj

PaymentType VendorPayment Fixed “Adjustments" PaymentType

Status VendorPayment “Paid in Full" Status

VendorID VendorPayment Fixed “Adjustments" VendorID


P a g e 220 | 220


VendorInvoiceNumber VendorPayment Fixed “Adjustments" VendorInvoiceNumber

VendorPaymentID VendorPayment AdjNum TransDT TransSetNm


AdjNum Adj



TransDT Adj



TransSetNm Adj

Metadata Management Tutorialmetaintegration.com/Products/MIMM/OEM/erwin/... · 3 Metadata...

Documents

Transcript of Metadata Management Tutorialmetaintegration.com/Products/MIMM/OEM/erwin/... · 3 Metadata...