dataflux qmdm solution - sas · 2016-12-20 · dataflux qmdm solution user's guide i contact...

DataFlux qMDM Solution

This page is intentionally blank

DataFlux qMDM Solution

User’s Guide

Version 3.2

September 5, 2012

This page is intentionally blank

DataFlux qMDM Solution User's Guide i

Contact DataFlux DataFlux Corporate Headquarters

Toll Free: (877) 846-3589

Tel: (919) 447-3000

Fax: (919) 447-3100

940 NW Cary Parkway, Suite 201

Cary, NC 27513

USA

DataFlux West

Tel: (818) 906-7638

Fax: (818) 907-6012

15300 Ventura Boulevard, Suite 523

Sherman Oaks, CA 91403

USA

Technical Support

Phone: 1-919-531-9000 Email: [email protected] Web: http://dataflux.com/MyDataFlux-Portal.aspx

Documentation Support

Email: [email protected]

mailto:[email protected]?subject=DataFlux%20Technical%20Support

http://dataflux.com/MyDataFlux-Portal.aspx

mailto:[email protected]?subject=Include%20Doc%20ID:%20and/or%20Topic/Chapter%20Title

ii DataFlux qMDM Solution User's Guide

Table of Contents Introduction ....................................................................................1

Audience for This Document ............................................................. 1

Conventions Used in This Document .................................................. 1

Typographical Conventions ............................................................ 2

Syntax Conventions ...................................................................... 2

Path Conventions .......................................................................... 2

Reference Publications ..................................................................... 2

qMDM Overview ..............................................................................3

What's New in qMDM 3.2 .................................................................. 4

How qMDM Works ........................................................................... 4

DataFlux Solution Architecture .......................................................... 4

Development ............................................................................... 4

Run Time ..................................................................................... 5

DataFlux qMDM Solution Components ............................................. 6

DataFlux Data Management Studio ................................................. 6

DataFlux Process Jobs and Real-time Business Services ..................... 7

Quality Knowledge Base ................................................................ 7

DataFlux Data Management Server ................................................. 7

DataFlux Authentication Server ...................................................... 7

Solution Databases ....................................................................... 7

Master Data Manager Web Application ............................................. 8

Deployment Models ......................................................................... 8

Physical Deployment Model ............................................................ 8

Virtual Deployment Model .............................................................. 8

Integrating Other Applications with qMDM .......................................... 9

DataFlux qMDM Solution User's Guide iii

Understanding qMDM .................................................................... 11

The Enterprise Environment ............................................................ 11

Which Data Is Most Important to Your Business? ............................ 11

Data Profiling ............................................................................. 11

What Are Entities? ......................................................................... 12

How Are Entities Related? ............................................................... 13

Hierarchies ................................................................................ 13

Relationships ............................................................................. 13

How Are Entities Constructed? ........................................................ 14

Inside the Cleansing Process ........................................................ 14

Inside the Clustering Process ....................................................... 16

Inside the Survivorship Process .................................................... 19

Deploying qMDM ........................................................................... 20

Adding Metadata ........................................................................... 20

Entity Type Definition .................................................................. 20

Attribute Definition ..................................................................... 22

Cluster Conditions....................................................................... 26

Relationship Types ...................................................................... 27

Sample Metadata ........................................................................ 27

Generating Jobs ............................................................................ 28

Loading the qMDM Hub .................................................................. 29

Managing Updates ...................................................................... 30

Pushing and Pulling Source System Changes .................................. 31

Cluster Changes and Hierarchies .................................................. 31

Recovering from Load Problems .................................................... 31

Trimming Historical Data ............................................................. 32

Migrating from a Master Data Management Foundation Hub ................ 32

iv DataFlux qMDM Solution User's Guide

Migrating Metadata ..................................................................... 32

Importing Source Systems and Languages ..................................... 32

Importing Master Data Management Foundation Metadata ............... 33

Migrating Instance Data .............................................................. 33

Reporting on the qMDM Hub ........................................................... 40

Enabling the Master Data Dashboard Report .................................. 40

Auditing and Reporting ................................................................ 40

Business Processes and the Entity Lifecycle .................................. 42

Configuring Business Processes ....................................................... 42

Enabling Lifecycle Workflows ........................................................ 42

Packaging .................................................................................. 43

Generating an Edit Job ................................................................... 43

Workflow Logging .......................................................................... 44

Handling Roles .............................................................................. 45

Make Live Processing ..................................................................... 46

Data Masking ................................................................................ 47

Defining Roles ............................................................................... 48

Enabling Advanced Search ........................................................... 48

Interaction with Data Management Server Permissions ...................... 49

Managing Access ........................................................................... 49

Designing Jobs .............................................................................. 49

Overview of Master Data Manager User Interface ......................... 51

Logging On ................................................................................... 51

User Interface Elements ................................................................. 52

Header ...................................................................................... 53

Navigation Pane and Risers .......................................................... 54

Information Pane ........................................................................ 54

DataFlux qMDM Solution User's Guide v

Common Elements ...................................................................... 54

Reports Riser ................................................................................ 61

Reports Riser Overview .................................................................. 61

Report Types.............................................................................. 61

Reports Tree .............................................................................. 62

Reports Riser Toolbar .................................................................. 62

Running Reports ............................................................................ 63

Master Data Dashboard Report ........................................................ 66

Drill-Through Reports .................................................................. 68

Workflows Dashboard Report .......................................................... 68

Workflows Riser ............................................................................ 70

Workflows Riser Overview .............................................................. 70

Workflow Types .......................................................................... 70

Workflows Tree .......................................................................... 71

Workflow Tables ......................................................................... 71

Assigned Workflow Editor ............................................................... 74

Submitted Workflow Editor ............................................................. 76

Master Data Riser .......................................................................... 78

Master Data Riser Overview ............................................................ 79

Entity Search Panel ..................................................................... 79

New Button ................................................................................ 79

Tabs and Split Panes ................................................................... 80

Searching for Master Data Records .................................................. 81

Search Types ............................................................................. 81

Search Criteria ........................................................................... 83

Search Results Tree .................................................................... 86

Working with Search Results ........................................................... 86

vi DataFlux qMDM Solution User's Guide

Search Results Toolbar ................................................................ 87

Entity Editors ................................................................................ 88

Entity Editor Tabs ....................................................................... 89

Entity Editor Toolbar ................................................................... 90

Working with Entity Properties ........................................................ 90

Relationship Tables ..................................................................... 92

Working with Clusters .................................................................... 92

Cluster Table .............................................................................. 93

Comparing Records ..................................................................... 94

Moving Contributor Records ......................................................... 96

Working with Hierarchies .............................................................. 100

Creating and Viewing Hierarchies ................................................ 101

Editing Hierarchies .................................................................... 102

Working with Entity Relationships .................................................. 104

Creating Entity Relationships ...................................................... 104

Exploring Entity Relationships .................................................... 106

Retiring Entity Relationships ....................................................... 112

Tagging Entities .......................................................................... 114

Retiring Entities ........................................................................... 114

Working with Entity History .......................................................... 115

Definitions Riser .......................................................................... 117

Definitions Riser Overview ............................................................ 118

Definition Types ....................................................................... 120

Definitions Tree ........................................................................ 120

Definition Table ........................................................................ 121

Entity Type Definitions ................................................................. 123

Entity Type Editor ..................................................................... 123

DataFlux qMDM Solution User's Guide vii

Property Editor ......................................................................... 127

Attribute Editor ........................................................................ 128

Cluster Condition Editor ............................................................. 132

Relationship Type Editor ............................................................ 134

Hierarchy Type Definitions ............................................................ 136

Hierarchy Type Editor ................................................................ 137

Association Tables ....................................................................... 138

Role Association Tables ............................................................. 138

Entity Association Tables ........................................................... 139

Association Table Toolbar .......................................................... 139

Role Definitions ........................................................................... 140

Role Editor ............................................................................... 140

Source System Definitions ............................................................ 141

Source System Editor ................................................................ 142

Language Definitions ................................................................... 143

Language Editor ....................................................................... 143

Appendix A: Examples ................................................................. 145

Example 1: Creating an Abstract Entity Type................................ 145

Example 2: Creating a Concrete Entity Type ................................ 161

Example 3: Creating Entity Relationships ..................................... 172

Appendix B: Legal Information .................................................... 182

DataFlux qMDM Solution User's Guide 1

Introduction This document provides conceptual and technical information for the DataFlux® Quality

Master Data Management (qMDM) Solution, including:

qMDM features and capabilities

Modeling entities within qMDM

Building and deploying qMDM jobs and services

Building and deploying business processes in support of qMDM operations

Using the qMDM Master Data Manager, a browser-based interface from which users

can create and manage a qMDM hub

Audience for This Document

Conventions Used in This Document

Reference Publications

Audience for This Document

The DataFlux qMDM Solution User's Guide is intended for data stewards and end users of

the qMDM system.

qMDM data stewards are responsible for the following:

Determining and configuring entity metadata

Supporting the operation of the qMDM hub by adding metadata and instance data

Managing entities within the qMDM hub throughout their lifecycle

Assisting end users as required

Data stewards should have knowledge of the business requirements for a master data

management initiative, and skills in the following areas:

Data or object modeling

Using DataFlux Data Management Studio to build jobs and services

qMDM end users are responsible for creating, updating, and reviewing information in the

qMDM hub, and using the information for business purposes.

Conventions Used in This Document

This document uses several conventions for special terms and actions.

2 DataFlux qMDM Solution User's Guide

Typographical Conventions

The following typographical conventions are used in this document.

Typeface Description

Bold Bold text signifies a button, action, file name, or directory path. Bold text is

also used to denote user interface elements such as riser and dialog names.

Italic Italicized text identifies document and topic titles.

Monospace Monospace font is used for code examples.

Syntax Conventions

The following syntax conventions are used in this document.

Syntax Description

[] Brackets [] are used to indicate variable text, such as version numbers.

# The pound # sign at the beginning of example code indicates a comment that is

not part of the code.

Path Conventions

Various products and operating systems may use different paths for default locations. This

document uses the Windows 7 path in examples. The following examples display the

differences in paths for Windows and UNIX operating systems.

Windows

drive:\Users\username\AppData\Roaming\DataFlux\DataManagement\version\Repositories\

Accelerators\qMDM

UNIX

/opt/dataflux/dms/qMDM

Reference Publications

This document may reference other DataFlux publications, including:

DataFlux qMDM Solution Administrator's Guide

DataFlux Data Management Server Administrator's Guide

DataFlux Data Management Studio User's Guide

DataFlux Quality Knowledge Base Online Help

DataFlux Expression Language Reference Guide

Documentation provided with this software is located in the installation folder for DataFlux

Data Management Studio. Many of the documents listed can be found on the MyDataFlux

Portal under Documentation.

http://www.dataflux.com/Resources/DataFlux-Resources/Customer-Care-Portal.aspx

http://www.dataflux.com/Resources/DataFlux-Resources/Customer-Care-Portal.aspx


qMDM Overview The DataFlux qMDM Solution is a combination of software, templates, documentation, data

model, and services that provide the functionality and processes necessary to build and

maintain a master entity database. An entity can be a customer, product, patient, site, or

any business data object that you define. You can also define attributes for each entity, as

well as transformations that support data quality and identity management functionality.

The qMDM hub is a set of tables and table relationships that contain entity information and

required entity keys and linking information to provide end users or other applications with

a complete view of an entity and its relationships with other entities. In addition, the qMDM

hub can be used as the single source for creating and maintaining survivor records, which

can be used in other applications or processes. The original source system IDs, which are

important to other enterprise applications or data sources, are also maintained in the qMDM

hub to facilitate linking activities with other data providers or consumers.

The DataFlux qMDM Solution includes the following features:

Batch and real-time modes

Entity matching, de-duplication, and survivor record creation

Entity linking through hierarchies and relationships

Data quality functionality such as address verification, standardization, and parsing

Fielded and advanced search capabilities

Adding, modifying, and retiring qMDM entities and hierarchies

Metadata management for entities, attributes, and transformations

Historical tracking: changes saved for contributor records and survivor records

Reporting: batch, dynamic, and dashboards/scorecards

Built on mature DataFlux Data Management Platform that enables data access, data profiling, data monitoring, data quality, and data enrichment

What’s New in qMDM 3.2

How qMDM Works

DataFlux Solution Architecture

Deployment Models

Integrating Other Applications with qMDM


What's New in qMDM 3.2

New functionality for qMDM 3.2 includes:

Perform actions from lists: The User interface has been enhanced to allow more actions to

be performed from lists of objects. See the action menu for the lists to see the actions that

are available.

Audit history is now available from entity editors: A new tab is present in the Entity Editor,

which displays the history of records in the cluster.

Import and export of models: Data Stewards can now import and export metadata as a

.met file. The .met file format has been enhanced to support all of the qMDM capabilities.

How qMDM Works

Generally speaking, qMDM extracts business information from your data sources; validates

and standardizes the data, ensuring that it is correct and meets your business standards;

and consolidates the information into a single view of the information available from all the

data sources. The organizational data that you provide can be customer data, product data,

services data, or data for other entity types. qMDM has the ability to update your data using

both internal and external information. You can also store data, maintain and manage it,

and use qMDM to provide the most complete and accurate information to your entire

organization.

DataFlux has crafted qMDM to help you manage and improve your data. qMDM provides

general data management and data quality tools. A rigorous methodology, used for data

integration products of all types, is applied to the problem of integrating disparate

enterprise data. DataFlux has experience with various customer databases in a wide array

of industries that includes financial services, retail, telecommunications, manufacturing, and

health care. DataFlux can provide solutions for your organization that offer the accurate and

reliable information you need to make critical business decisions.


DataFlux Solutions are built on a sophisticated Data Management Platform that provides

both development-time and run-time support for applications.

Development

During development, DataFlux Data Management Studio provides the ability to design and

test processes (batch jobs) and real-time services (data jobs), which can then be deployed

and run using:

DataFlux Data Management Server

Scripting using a command line interface

Data Management Studio directly

The DataFlux Data Management Platform relies on the Quality Knowledge Base (QKB) for

data quality processing. The QKB provides capabilities such as standardization of data and

computation of match codes. The QKB is used both during development and at run time.


Run Time

At run time, DataFlux Solutions employ a multi-tier architecture that consists of

Presentation, Business, and Data tiers.

The Presentation tier hosts the Web interface in a Servlet 2.5 compliant container

and includes a Java™ application server and a browser. Batch interfaces may be

available for some operations such as bulk loads and updates.

The Business tier runs on a DataFlux Data Management Server and is implemented

using DataFlux Data Management Studio processes (batch jobs) and real-time

services (data jobs). It implements a Service Oriented Architecture (SOA) that

enables any system to use its services through SOAP requests. Common Web service

standards are used to maintain simplicity when integrating DataFlux Solutions with

other systems.

Authentication within the Business tier runs on a DataFlux Authentication Server, in

which you can authorize user permissions for DataFlux applications, assign roles and

security restrictions, and define authentication parameters for accessing other

systems, such as the database, for each user or group.

The real-time or transactional component of the qMDM Master Data Manager

interfaces with other applications through an SOA environment. Specifically, the

ability to call business services hosted on Data Management Server is accomplished

through Web services. Process jobs can also be used as business services that accept

data on a record-by-record basis. This enables users to use qMDM data and services

within an enterprise architecture.

The Data tier hosts the supporting data and metadata for the system, which consists

of a relational database such as Oracle® or Microsoft® SQL Server®. The data model

is documented and accessible to third-party tools and can also be accessed through Data Management Studio jobs.

The following diagram is a graphical representation of how the components fit together.



DataFlux qMDM Solution Components

The main components of the DataFlux qMDM Solution are:

DataFlux Data Management Studio

DataFlux Process Jobs and Real-time Business Services

Quality Knowledge Base


DataFlux Authentication Server

Solution Databases

Master Data Manager Web Application

DataFlux Data Management Studio

DataFlux Data Management Studio is a graphical user interface (GUI) based application that

provides access to other DataFlux tools and services. You can use Data Management Studio

for job flow management and customization, to manage data source connections, to

manage user accounts through DataFlux Authentication Server, to deploy and execute jobs


on the DataFlux Data Management Server, and to run batch jobs and data services within a

Windows® environment.

DataFlux Process Jobs and Real-time Business Services

A DataFlux process job is a multi-step data management process that can be run from Data

Management Studio, from Data Management Server, or from a command line interface or

script. Real-time business services, also called data jobs, are deployed through Data

Management Server and are used by the Master Data Manager Web application to provide

data to the application through SOAP calls.

Quality Knowledge Base

The Quality Knowledge Base (QKB) contains the files, file relationships, and metadata

needed to correctly parse, match, standardize, and otherwise process data as required for

qMDM. The QKB can be customized to meet an organization's needs. The QKB can support

different locales to support processing for many different languages.


The DataFlux Data Management Server enables data management and integration

processes to be deployed across an entire IT environment. qMDM uses batch jobs and real-

time services deployed through Data Management Server to manage the master data hub

and to provide data through the Web interface and reports. Data Management Server

handles all aspects of database connectivity and service availability through SOAP calls.

Note: In many instances, it is advised to have at least two Data

Management Servers working together through network load

balancing/failover hardware or software, to achieve the desired results for

performance and meet server uptime goals, particularly for real-time service

processing.

DataFlux Authentication Server

The DataFlux Authentication Server enables a system administrator to define which users

have access to the Master Data Manager, which users have administrator rights, and which

users have permissions to access reports and other services. Processes running through

Data Management Server connect to Authentication Server to determine the proper level of

access for each user.

Note: The Authentication Server determines the user's groups and roles

(authentication), while the Data Management Server determines the level of

access (authorization).

Solution Databases

DataFlux Solutions rely on access to a Database Management System (DBMS), such as

Oracle or SQL Server, to act as a repository for metadata about the Solution and its

contents, and also to retain the data that is used by the Solution. The Master Data Manager

component of the qMDM Solution requires two database schemas for its operation.


Master Data Manager Web Application

The Master Data Manager is a Web-based application that enables users to create and

manage a qMDM hub, including:

Defining new entity types and their attributes

Searching for data within the qMDM hub

Creating and updating data within the qMDM hub

The Master Data Manager is deployed on a Servlet 2.5 compliant container through a Java

application server.

Deployment Models

qMDM supports two approaches for storing information about master data entities in the

qMDM hub:

Physical deployment model - This model assumes that all the information

necessary to construct a complete survivor record for an entity is stored in the

qMDM hub.

Virtual deployment model - This model assumes that minimal information used for identity management is stored in the qMDM hub.

In both models, source system keys are also stored in the qMDM hub so that information

used to identify and describe entities can be recorded. This supports the ability to link or

reference source system data, provides traceability for the contributor records, and

describes key relationships with the data as it exists in the qMDM hub.

Physical Deployment Model

The physical deployment model is the most common type of deployment. With this

approach, uniquely identifying information for entities is stored in the qMDM hub, along with

other dependent attributes. Accessing the survivor record can be accomplished by querying

the qMDM hub by itself, without the need to refer to the Systems of Record. This approach

simplifies the task of constructing the survivor record, but results in higher storage

requirements.

Virtual Deployment Model

The virtual deployment model uses the qMDM hub framework to drive qMDM functionality.

Similar to the physical deployment model, the virtual deployment model has several tables

that track and relate unique entities. However, the attributes that are not used for the

identity management process are not stored in the qMDM hub. This means that the source

system keys that are recorded for each incoming entity are used to access the originating

systems and retrieve additional attributes as necessary to provide a complete view of each

entity. This approach minimizes the storage requirements, but complicates the task of

constructing a survivor record.

The process of querying originating source systems and joining the information stored in the

qMDM hub can be accomplished with the DataFlux Data Management Platform; however,

qMDM does not provide this functionality out of the box.


Integrating Other Applications with qMDM

There are two common methods of integrating other end-user or enterprise applications, as

well as other Extraction, Transformation, and Loading (ETL) software, with the qMDM

Solution.

The first method is direct-database or flat-file access, running batch load or batch

update processes. In this case, the Data Management Server can connect directly to

data sources, transform the data, and load it into the qMDM hub.

The second method is communicating with the Data Management Server using Web

services. Any application or process that can make a Web service call can send data to

the qMDM hub through Data Management Server and receive data from the qMDM hub in the same manner.

In practice, both of these methods will typically be used to interact with qMDM. In some

cases it may make sense to communicate directly with Data Management Server from an

application integration layer of an enterprise application such as Siebel® or SAP®. In other

cases, using an enterprise messaging mechanism such as TIBCO® or webMethods® may be

more practical if that infrastructure has already been deployed within your organization.

You also have the option of making Web service calls directly from a .NET or Java

component or application that can utilize Web services. This may be common in

circumstances where internally designed and built operational or reporting processes need

to interact with the Data Management Server to access customer or service data inside the

qMDM hub.


qMDM Solution Integration


Understanding qMDM The Enterprise Environment

What Are Entities?

How Are Entities Related?

How Are Entities Constructed?

The Enterprise Environment

It is important to understand the environment in which qMDM will be deployed. The source

systems that provide the data for qMDM will have a large impact on the implementation

choices that you make.

Which Data Is Most Important to Your Business?

Asking this question can help guide you in identifying the best place to apply qMDM in your

organization. The data that should be considered for incorporation into qMDM is:

Data that represents the nouns of your business. Customers, Partners, Products, and

Services are examples of entities that many organizations may have in common.

Data that exists in multiple silos. It does not matter if the silos are a result of

acquisition or in-house development—any redundant data can pose a risk to your organization.

When starting a master data management initiative, your business needs should be

considered first and foremost. All of your data does not need to be managed as master

data. Do not use:

Data that rarely changes. Reference data can be much easier to synchronize across

the enterprise because it rarely changes. Crafting master data for static data may not

provide a return on investment for the required effort.

Data that is not shared. If there is a data set that is only used by one part of your

business, the merge and reconciliation aspects of a master data management

initiative are less valuable. Your time may be better spent incorporating more highly leveraged data into a master data management system.

Data Profiling

It may not be obvious where the entities in your organization are defined or being used.

Data profiling can help you discover which enterprise systems contain entity information

and their attributes, including identifiers. With this information, you will begin to understand

more about your master data management implementation.

Which source systems are involved? Which entities do they manage?

In qMDM, entities are constructed from records from source systems, where the data

originally resides. Some examples of source systems are Enterprise Resource Planning

(ERP) systems, accounts receivable systems, and payroll systems. Data profiling can


help to discover similarities between the source systems in an enterprise, thereby

suggesting entities for incorporation into a qMDM hub.

How are the entities identified?

By identifying the keys used within each source system, you can identify strategies for

matching the same entity across different source systems.

What attributes do the entities manage?

As you reconcile the views of an entity that have been adopted by each source

system, you can begin to formulate the data needs of the qMDM entity.

What steps are needed to address quality issues in each of the systems?

Standardization of data elements within a qMDM hub provides better entity results,

and a consistent view of the data.

Do the different systems provide different levels of accuracy and reliability?

A customer-facing system may well be more current, accurate, and reliable than

third-party enrichment data that is only occasionally refreshed. In this case,

survivorship rules can be implemented to capture the best data from the most

trustworthy system.

How big will the eventual data set be?

Addressing operational issues (such as database sizing), and ensuring that processing

time is available in the schedule for the expected volumes, are critical for success.

How frequently does the data change in each system?

Especially in the case of Extraction, Transformation, and Loading (ETL) scenarios

where the qMDM hub is updated at regular intervals, it is important to know the

latency associated with those updates: Is it acceptable for the qMDM hub data to lag

behind the source system by a week, or a day? Or must the qMDM hub data always

be up-to-date, thereby requiring a real-time interaction between the systems?

Knowing the answers to these kinds of questions will ensure that stakeholders have realistic expectations from the qMDM system.

What Are Entities?

A qMDM entity is a survivor record that is constructed from contributing data from the

source systems in the enterprise. This section explains more about entities within the qMDM

hub.

An entity has a type, where the types represent the nouns of your business. For example,

an entity can be an individual, organization, product, or service.

qMDM does not predefine which data your entities require. Instead, qMDM accepts metadata

about your entities and modifies the hub accordingly. This metadata includes the following:

Attributes are the data elements used by your entities. Attributes are analogous to

columns in a database table. Examples include addresses, email addresses, and

dimensions. Attributes have metadata that describes them, such as data type, length,

and whether the attribute is a required value for a particular entity.

Cluster conditions are the rules used to determine which records contribute to the

survivor record.

Relationship types describe which entity types are related to other entity types, and

how the entity types are related.


Parent entity type references enable entities to inherit definitions from their

ancestors. For example, the top-level qMDM entity type (named ENTITY) defines a set

of attributes that are used to maintain instance data in the hub. Because every other

entity type derives (either directly, or through other entity types) from the ENTITY

entity type, modeling these attributes in the derived types is unnecessary. Attributes, cluster conditions, and relationship types are all inherited by derived entity types.

The metadata is collectively known as an entity type, which describes the information that

is used by all the instance data for that type. The metadata is used in several ways in the

operation of the qMDM hub:

The entity type information (including the attributes) is used to construct tables in the

hub, where each attribute is expressed as a column. These tables are regular

database tables, and can be used by reporting and other line-of-business applications.

The cluster conditions are used to generate DataFlux batch jobs and data services that

drive the operation of the hub. You can use these services to add, query, and retire

information in the hub (among other operations).

The metadata is used at run time to determine how to present the contents of the hub, including the layout of forms and tables.

How Are Entities Related?

Entities often maintain relationships among one another. For example, Companies employ

People, or Cities are part of a Geographic region. The qMDM hub supports relationships

between entities by constructing hierarchies, or by modeling relationships between entity

types.

Hierarchies

Hierarchies represent a set of parent-child relationships between entities. The nature of the

relationship is not specified, and it always takes the form of a tree structure with a single

root entity. Hierarchies are useful in modeling taxonomies and other domains where there is

a unifying concept that provides the ability to relate entities in a tree-like structure.

Hierarchies in qMDM are modeled in terms of allowed entity types. For example, you can

model an Employee hierarchy type that allows both Company and Employee entity types.

Note that qMDM does not require a particular structure for a hierarchy, and allows entities

to appear multiple times within the hierarchy (although an entity is not allowed to be its

own sibling).

Relationships

Relationships take the form of directed binary relationships that are modeled between two

entity types. A relationship type defines one entity type as the "source" of the relationship,

and the other entity type as the "target" of the relationship. Optionally, each relationship

type can describe conditions that enable qMDM to determine if two entities are related.

Relationships can be more expressive than hierarchies in several ways:

They denote a particular kind of relationship, whereas hierarchies only denote that the

entities are somehow related.


Relationships can be used to describe cyclic graphs, whereas hierarchies are limited to

tree structures.

Multiple relationships between two entities can be modeled and captured in the model, whereas a hierarchy would only allow one relationship to be formed.

How Are Entities Constructed?

Each entity in the qMDM hub is represented by a set of records, loaded from source

systems, that have undergone the following processes:

Cleansing - Data quality, standardization, and other transformations are applied to

the incoming records to ensure that the data meets business requirements. The

cleansing process removes irregularities, standardizes values so that records can be

compared, and computes match codes, which are used in the clustering process.

Records that do not meet (or cannot be made to meet) the standards are redirected

for further processing.

Clustering - Based on criteria specified by the entity type, records that represent the

same entity are clustered. The criteria include sets of attributes to identify records

that contribute to an entity. For example, if two customers have the same name,

email address, and phone number, you can provide a cluster condition that specifies

that the customers should be considered as part of the same entity—even if the

records' source systems do not share any primary keys.

Survivorship - The records in the cluster are used to construct a single survivor

record (also known as the best record or golden record) based on rules that are specified by the entity type.

The following sections provide additional details on each of these processes.

Inside the Cleansing Process

Inside the Clustering Process

Inside the Survivorship Process

Inside the Cleansing Process

The cleansing step is a key component of qMDM. The qMDM hub should keep a clean,

standardized version of each core attribute that matches the semantics of the attribute

type.

The possibilities for validation rules are unlimited. A rule can accomplish simple tasks such

as determining whether a field is null, or more complex tasks such as cross-field

calculations.

The following are examples of logical validation rules for qMDM:

Full Name - Propercases the name field.

Address - Performs address verification, including augmenting the record with

missing fields that can be provided by third-party services or databases.

Telephone - Removes records with no area code.


Enabling Data Quality

qMDM can perform data cleansing and standardization by using the extensive DataFlux suite

of data profiling and data quality nodes, including the Quality Knowledge Base (QKB).

Standardized values and other transformed attributes can and should be stored with the

original data in the qMDM hub. For more information on the available standardization

schemes, refer to the DataFlux Quality Knowledge Base Online Help. In order for the QKB to

function, the record must be associated with a locale which guides interpretation of the

data. This is provided by the MDM_LANGUAGE_ID attribute, which is part of every entity

type (the ID is used to look up the QKB locale based on its value).

In addition to standardizing values, you can use the QKB to compute match codes that

assist in clustering similar records into a survivor record. Match codes must be modeled as

attributes, and become part of the entity record as part of the data ingestion processing.

For more information on match codes, see Inside the Clustering Process.

Note: Remember that if you are creating standardized values or match

codes, they should be modeled as attributes in the metadata as well.

Standardized attributes and match codes are collectively referred to as flux attributes. A flux

attribute is always associated with another attribute.

To make it easy to reuse the data cleansing and data quality processing, the standardized

and match code computations must occur in the mdm_stnd_<entity_type>.ddf job. This

job is referenced by the parts of qMDM that need to use a consistent view of standardized

attributes. For example, both data loading and search jobs can use standardized values and

match codes.

To process data in different languages or from different countries at the same time, you

must load all the required locales into the QKB both in your Data Management Studio design

environment and on the Data Management Server. Then, you must modify the atomic-level

jobs that clean data and generate match codes so that the appropriate algorithms are used.

Adding Locale Support

To support additional locales:

You must have a valid and supported QKB license for each locale that you want to

use.

You must update the embedded mdm_stnd_<entity_type>.ddf job with the

processing for the additional locales.

You must update your language definitions to include the new locale, which is used to verify the data when adding information to the hub.

Note: You will need individual license codes in your Data Management Studio and Data

Management Server license files to enable you to utilize more than one locale in your qMDM

system. By default, you are licensed to use one locale. In most cases, the licensing is for US

English, but this may vary according to your needs.


Inside the Clustering Process

Clustering helps to identify unique and related entities. First, you must determine which

fields can be used to identify related records. These are usually combinations of attributes,

which may include standardized values or match codes that were computed in the cleansing

step. For example, to determine unique entities in your database, you might set up the

following rule.

If... Then...

... these fields match:

FULL NAME (Match Code)

ADDRESS LINE 1 (Match Code)

CITY NAME (Match Code)

POSTAL CODE (Match Code)

Or… these fields match:

FULL NAME (Match Code)

CUSTOMER_ID

... a cluster has been identified that contains

several records representing the same

individual.

You can use similar logic to find match

clusters for organizations, households, and

so on.

Clustering Rule

Successful identity management uses as many fields as possible to limit the potential for

false matches. For example, if you use only full name fields for match criteria, the result

may be hundreds of instances of John Smith, most of which are not duplicates because they

live at different addresses. The inclusion of address information in the matching criteria

significantly improves the matching and linking results in this case. The entity type should

specify as many cluster conditions as needed to define the identity criteria.

Notes:

1. We recommend building indexes for attributes that are used in the clustering

process. For large hubs, the use of an index can speed up the processing

significantly.

2. Different database types can handle empty strings differently. For example,

Oracle converts empty strings into NULLs, while SQL Server preserves the

empty strings. This can cause anomalous results, especially when these values

are used in cluster conditions. We recommend that you test your data carefully,

and ensure that null fields and empty strings are being handled as you expect in

your jobs.

When records are brought into the qMDM hub, any of the following conditions can occur:

The record is unique, and does not match any records in the qMDM hub. In this case,

a new cluster is created. A survivor record is created for the cluster.

The record matches records in exactly one other cluster. In this case, the record is

added to the existing cluster, the cluster's previous survivor record is retired, and a

new survivor record is constructed from all the active contributor records.

The record matches records in more than one cluster. In this case, the qMDM hub also

looks at the clusters that are matched to determine if any of the matches present are

records that have been manually moved. The presence of moved records indicates

that the natural clustering process either overmatched or undermatched the data, and


should not be used. By default, qMDM will proceed as follows. This processing can be

changed by modifying the jobs that assign records to clusters

(mrm_add_<entity_type>.ddf and add_update<entity_type>.ddf).

o If there are "natural" clusters that do not consist of moved records, the record is

clustered with these records. If more than one natural cluster matches, the

clusters are collapsed into the oldest cluster (which generally has the lowest

value of MDM_ENTITY_CLUSTER_ID).

o If all the clusters are "forced" (that is, have moved records), the record is

placed in the oldest cluster (for example, the cluster that has the lowest value of

MDM_ENTITY_CLUSTER_ID).

o In either case, existing survivor records are retired, and a new survivor record is generated.

In all cases, when an incoming record is already represented in the hub (based on its

MDM_SRC_SYS_ID and MDM_SRC_SYS_REC_ID fields), the previous contributor is retired.

This prevents data that has been replaced in the source system from being used in

clustering and survivorship decisions.

Note that if a bulk update includes two or more records with the same values for

MDM_SRC_SYS_ID and MDM_SRC_SYS_REC_ID, the hub is unable to determine which

record is the most recent. In this situation, all the records will be applied to the hub. If your

source data allows you to prefer one record over another one, consider filtering out the

other records before providing the data to the bulk jobs.

How Are Entities Identified?

Entities are constructed from contributing records that are selected based on cluster

conditions for the entity type. The cluster conditions encode matching rules, which are used

to bring records with the same sets of values together. You can use any attribute within the

cluster condition. However, if you choose the raw values from the incoming records, you

may miss some matches. For example, if two records use different cases for a customer

name but are otherwise identical, the matching rules will place these records in different

clusters. By leveraging the cleansing process, you can improve the match results:

Standardizing values with the QKB enables case and common derivations (such as 'Robert',

'Bob', and 'Rob') to be normalized.

Using match codes allows fuzziness to be built into the process, as discussed in the following

section.

Using Match Codes

Match code generation is probably the most critical aspect of using qMDM. Match codes

ensure that data that shares fundamental similarities will come together into match clusters

when match codes are compared. When used in groups with conditional logic, match codes

provide a powerful way to match and link records that do not contain obvious similarities.

Match codes are used where a degree of fuzziness is required to find all potential matches

or relationships.

For example, to identify all the records in a data set where Ronald Jeffries exists, you could

simply scan the data set for exact matches. However, that approach may miss Ron Jeffries

and Ronnie Jefferys, who may be the same person. Using match codes, qMDM can identify


these entities as potential duplicates, and qMDM will process business rules to determine

the nature of their relationship.

This section contains examples that show how match codes are used.

The following two name strings are considered a match.

Input Data Match Code

Bob Brauer MYLY$$M@M$$$$$$

Mr. Robert Brauer MYLY$$M@M$$$$$$

Generally, match processing is applied to several fields simultaneously. Records are

considered to match if data strings from each field produce the same match codes. For

example, assume that a cluster condition is defined that uses the Name and Organization

fields from a contact table as input.

Input Data Name Organization Match Code (Name) Match Code (Organization)

Bob Brauer DataFlux MYLY$$M@M$$$$$$ 8~GWX$$$$$$$$$$

Mr. Robert Brauer DataFlux Corp MYLY$$M@M$$$$$$ 8~GWX$$$$$$$$$$

Robert Brauer General Motors MYLY$$M@M$$$$$$ B3Y4G~$$$$$$$$$

The first and second records match, because both have the same match codes for Name

and Organization. The third record does not match either of the other records, because the

match code generated for the Organization field differs from those of the other records.

Note: The match code data fields for most QKB locales are set at 40

characters. There are some QKB locales (for example, French) that have a

longer match code data field.

Note: Clustering rules can use any combination of match codes,

standardized values, or raw input.

In Data Management Studio, you should cleanse the data prior to matching for

standardization or display purposes. You are not required to parse or standardize data prior

to matching. However, the master data management methodology calls for parsing and

standardization, because in addition to generating the match codes from the data, you also

want to store the data in a clean and valid format.

Match Definitions

The Data Management Studio Match Codes node uses many match definitions for various

data types and performs specific matching techniques and algorithms on each of those

types. For example, the logic used to match name fields is very different from that used to

match address fields. If a field is to be included in a match job for a given table, you must

associate one of the available field types with that field. The accuracy of a match can be

adversely affected by not choosing the field type that most closely resembles the data in the

field. For example, the phrases William Street and Bill Street would be considered duplicates

using the Name match definition, but they would not be considered duplicates using the

Address match definition.


Match Sensitivity

Match sensitivity defines how closely the Data Management Studio Match Codes node

compares data to determine if duplicate records exist. Adjusting the sensitivity provides the

flexibility needed to accurately identify a wide array of duplicate and near-duplicate records.

You must apply one of the available match sensitivities to each field that is used to identify

duplicate records. The sensitivity and match definition combine to make up the match job

for the selected field.

Match sensitivity uses DataFlux proprietary data quality algorithms to create match codes

that are clustered together to identify the duplicate and near-duplicate records contained in

a database. You can apply a sensitivity level from 50 to 95. Adjusting the sensitivity level

will increase or decrease the accuracy and precision of the generated match codes. The

default sensitivity level is 85.

If the Exact option is specified in the Match Definition field for a given record, a

character-by-character match will be performed on the specified field. You can select the

number of characters on which to match. These numbers are available in the Sensitivity

field. Exact sensitivity does not use any of the DataFlux data quality algorithms. It clusters

data in the same manner as in a SQL ORDER BY statement.

Inside the Survivorship Process

After the clustering process is complete, qMDM will have identified a set of records that are

logically part of the same entity. You can use qMDM to add survivorship rules that use these

records to create a survivor record.

For example, when establishing the identity of unique entities, you may find that you have

two similar addresses listed for a particular individual. The business logic has identified

these two records as matches, but qMDM must determine which address should be used as

the standard.

Your rules should process the related clusters of information and pull together the correct

pieces to create an accurate whole. In the earlier example of how to determine unique

entities in the database, a rule might state that when you have near-duplicate address

information, you should use the address that comes from the Customer Relationship

Management (CRM) system, because the addresses are updated more regularly than in the

other source systems.

qMDM can translate this rule into usable business logic to correctly identify that individual.

All of the logic used for identity management is completely customizable within qMDM.


Deploying qMDM This section describes the actions that must be performed to prepare the qMDM hub for use.

Adding Metadata

Generating Jobs

Loading the qMDM Hub

Migrating from a Master Data Management Foundation Hub

Reporting on the qMDM Hub

Adding Metadata

To support different kinds of entities, qMDM uses metadata extensively to describe the

information that it manages. Every entity and attribute in the system has associated

metadata that tells qMDM what it is and how it should be handled. One of the first tasks in a

qMDM deployment is determining the entities and their attributes that are to be managed

by qMDM.

Metadata can be entered into the system either from the Master Data Manager Definitions

riser, or by using a batch job to load metadata definitions that are located in text files. In

either case, metadata must be loaded prior to the introduction of instance data.

After metadata has been added to the hub, data stewards can generate jobs using the

Master Data Manager user interface (from the Definitions riser, use the Generate Jobs

option on the Entity Type Editor toolbar). We recommend that you start with the generated

jobs and adjust them according to your needs.

Entity Type Definition

Attribute Definition

Cluster Conditions

Relationship Types

Sample Metadata

Entity Type Definition

Entity types are the different kinds of entities that you will manage in the qMDM hub. Each

entity type has the following required attributes, which must be added to the system in

order to manage instances of that type. Entity type metadata is stored in the

MDM_ENTITY_TYPES table.

Attribute Description

MDM_ENTITY_TYPE Entity type name, for example, COMPANY,

INDIVIDUAL, or PRODUCT. Used to create a table

within the DBMS to store records for this entity type.



MDM_ENTITY_TYPE_DESC Entity type description.

MDM_ENTITY_TYPE_ID Unique entity type identifier. Automatically generated

by qMDM.

MDM_PARENT_ID The MDM_ENTITY_TYPE_ID of a parent entity type,

which contributes its metadata to this entity type.

MDM_ABSTRACT Allows or restricts instantiation of this entity type.

MDM_ENTITY_TYPE_LABEL Display label of the entity type in the Master Data

Manager.

MDM_ENTITY_TYPE_SORT_ORDER Controls the entity type's sort order in Master Data

Manager selection lists (for example, the Entity Type

list in the Create Entity dialog and the Target Entity

Type list in the Relationship Type Editor). To hide the

entity type and its associated attributes in the Master

Data Manager, enter either zero (0) or a negative

value.

MDM_GOLIVE_DTTM Date and time when the entity type is made live.

Automatically generated by qMDM.

MDM_LAST_MOD_DTTM Date and time when the entity type was last modified.

Automatically generated by qMDM. Use this attribute in

combination with MDM_GOLIVE_DTTM to determine if

the metadata has changes that have not been applied

to the qMDM hub.

MDM_OPSEQ Internal version identifier, incremented on every

change.

MDM_VALID_FROM_DTTM Date and time when the entity type is published for the

first time. Automatically generated by qMDM.

MDM_VALID_TO_DTTM Date and time when the entity type is retired.


Inherited Metadata

An entity type can inherit metadata from another entity type by specifying the PARENT_ID

of the other entity type. When metadata is inherited, it is available for use within the entity

type.

The ENTITY entity type defines the following required attributes. These attributes are

inherited by every other entity type in the hub.


MDM_ENTITY_TYPE_ID Foreign key reference to the MDM_ENTITY_TYPES table,

which identifies the type of the entity.

MDM_LANGUAGE_ID Foreign key reference to the MDM_LANGUAGES table, which

identifies the locale to be used when processing the record

with the QKB.

MDM_ENTITY_ID The primary key for the MDM_ENTITY table. Each record in

the hub has a unique value.

MDM_ENTITY_CLUSTER_ID The cluster that includes this record. Each record in the hub is

part of exactly one cluster at a time.

MDM_SRC_SYS_ID Foreign key reference to the MDM_SRC_SYS table, which

identifies the source system for the record. qMDM defines two



source systems: one for the Master Data Manager user

interface (for changes from the user interface), and another

for the hub itself, which always consists solely of survivor

records.

MDM_SRC_SYS_REC_ID An opaque identifier for the originating source system. By

using the source system ID along with the source system

record ID, the hub can trace records back to the original

source data.

MDM_VALID_FROM_DTTM The earliest date and time at which the data in the record

should be considered valid.

MDM_VALID_TO_DTTM The latest date and time at which the data in the record

should be considered valid. It is recommended that

MDM_VALID_TO_DTTM be either left blank (in database

terms, set this value to null) or set to a date where the data

should no longer be used.

Clustering and nomination of survivor records should only use

information that has not expired. For example, clustering only

uses records where the following condition exists:

MDM_VALID_FROM_DTTM <= current time and

(MDM_VALID_TO_DTTM is null or current

time < MDM_VALID_TO_DTTM)

Entities are retired by changing the MDM_VALID_TO_DTTM

attribute to the current time.

Abstract Entity Types

An entity type can be designated as abstract, which prevents instances of that entity type

from being created. Abstract entity types can be useful for modeling purposes, where (for

example) an attribute can be modeled once, and inherited by other, concrete entity types.

Attribute Definition

Attributes define the data elements that collectively constitute the information represented

by an entity type. As part of the data profiling phase, the necessary attributes for each

entity type should be identified, along with standardization rules and any other necessary

data quality rules. Attribute metadata is stored in the MDM_ATTRS table.

These attributes are then merged with a small set of attributes required for qMDM hub

operation. These attributes are defined by the ENTITY entity type and are inherited by any

derived entity types. By building on this base, you can extend qMDM to support any kind of

entity.

Attributes have a number of properties, such as a name (used for uniqueness constraints

within the hub), presentation parameters such as labels and display controls, and an

associated data type, which identifies how the attribute is stored within the hub.

The information in the attribute definition is used to construct a column of the same name,

with the data type, length (if any), and constraints as indicated by the metadata. In order

for the entity type to be published successfully, the attribute name must be compatible with

any restrictions imposed by the underlying database.


Note: The total number of attributes that can be modeled on an entity

type is subject to database limits. qMDM uses dynamic SQL to support flexible

models, so the number of attributes that can be supported is a function of the

length of the attribute names expressed as a comma-delimited list. For

example, with Oracle the maximum size of this list is 4000 bytes, which

allows for approximately 129 attributes if each attribute uses the full 30 byte

name.

Shorter names will allow a greater number of attributes, while encrypted

attributes will consume approximately 5 times the space of an unencrypted

attribute.


MDM_ATTR_CONSTRAINT Lists or regex strings used for validation of Master Data

Manager input fields used to populate the attribute. Can

be blank.

MDM_ATTR_DATATYPE_ID Attribute data type identifier. Constrained by

MDM_ATTR_DATATYPES table.

MDM_ATTR_DESC Attribute description. Can be blank.

MDM_ATTR_ID Unique attribute identifier. Automatically generated by

qMDM.

MDM_ATTR_LENGTH For string values, the size of the field.

MDM_ATTR_NAME Descriptive attribute name.

MDM_CLUSTER_DISPLAY_ORDER Results table display order of the attribute on the

Cluster Members tab of the Master Data Manager

Entity Editor. Enter zero (0) to hide the attribute in the

Master Data Manager.

MDM_DEF_ATTR_LABEL Display label of the attribute in the Master Data

Manager.

MDM_DISPLAY_GROUP_NAME Name used for group headers in the Master Data

Manager. Used to group attributes that share a

relationship.

MDM_ENCRYPT_FLAG Indicates whether the data for the attribute is encrypted

in the database.

MDM_ENTITY_TYPE_ID Attribute entity type identifier. Constrained by

MDM_ENTITY_TYPES table.

MDM_FORM_DISPLAY_ORDER Display order of the attribute in the Master Data

Manager Entity Editor. To hide the attribute in the

Master Data Manager, enter either zero (0) or a

negative value.

MDM_HIER_DISPLAY_FLAG Indicates whether to show the attribute when viewing

entity relationship hierarchies. Every entity type must

have exactly one attribute like this.

MDM_OPSEQ Internal version identifier, incremented on every

change.

MDM_PARENT_ATTR_ID For flux attributes only, this is a reference to the

attribute that is used to compute the match code or

standardized value.

MDM_READONLY_FLAG Indicates whether the attribute can be modified from

the Master Data Manager. Enter Y to specify that the



attribute cannot be modified.

MDM_REQUIRED Indicates whether the attribute is required for the data

type with which it is associated. Enter Y to specify that

the attribute is required. Attempts to store a record

without the required attributes being set will be

disallowed. Within the data model, required attributes

are stored in a table column with a NOT NULL

constraint.

MDM_SEARCH_DISPLAY_ORDER Display order of the attribute in the search form on the

Master Data Manager Master Data riser. To hide the

attribute in the Master Data Manager, enter either zero

(0) or a negative value.

MDM_TABLE_DISPLAY_ORDER Results table display order of the attribute on the

Master Data Manager Master Data riser. To hide the

attribute in the Master Data Manager, enter either zero

(0) or a negative value.

MDM_VALID_FROM_DTTM Date and time when the attribute is published for the

first time. Automatically generated by qMDM.

MDM_VALID_TO_DTTM Date and time when the attribute is retired.


Attribute Data Types

Following are the supported data types for qMDM attributes.

Data Type Description

String Presented in the Master Data Manager user interface as a single-line text entry

field, with a maximum length of 4000 bytes.

Text Presented as a multi-line text entry field, with a maximum length of 4000

bytes.

List Presented as a drop-down selection list, with the values provided by a

semicolon-delimited string in the attribute's constraint field. The constraint

field is limited to 200 bytes, including the semicolon delimiters. If the attribute

is not marked as a required field, there is also a blank choice to indicate that

there is no value for this attribute.

Date Presented as a text field with an attached calendar widget. Clicking in the text

field enables you to choose the date from the widget. Dates do not include a

timestamp component.

Timestamp A timestamp is a date with a time component, and is presented and edited in

the same way. Note that changes to the default time must be entered into the

text field directly.

Boolean Presented as a drop-down selection list with the values 'Yes' and 'No'. If the

attribute is not marked as a required field, there is also a blank choice to

indicate that there is no value for this attribute.

Integer Presented as a text field, which will accept up to 10 digits.

Real Real fields are limited to 31 digits in total length, with up to 5 digits behind the

decimal point. In database terms, these are numbers with a precision of 31

and a scale of 5.

URL Presented as a text field with a link widget to the right. Clicking the link widget

opens a new browser window or tab for the URL specified in the text field. URL


Data Type Description

fields can be up to 4000 bytes in length.

Note that no validation of the URL is performed.

Presentation Metadata

You can control the order in which attributes appear in various elements of the Master Data

Manager user interface by specifying ordinal values in the MDM_SEARCH_DISPLAY_ORDER,

MDM_TABLE_DISPLAY_ORDER, MDM_CLUSTER_DISPLAY_ORDER, and

MDM_FORM_DISPLAY_ORDER attributes.

Attribute UI Element

MDM_SEARCH_DISPLAY_ORDER Entity search form.

MDM_TABLE_DISPLAY_ORDER Entity search results tables.

MDM_CLUSTER_DISPLAY_ORDER Cluster table on Entity Editor Cluster Members tab.

MDM_FORM_DISPLAY_ORDER Entity Editor Properties tab.

The ordinal values are used to designate where in the Master Data Manager user interface

the element is placed, with lower-numbered items appearing vertically above those with

higher numbers. The table views (for example, entity search results tables and Entity Editor

cluster tables) will display the items from lowest to highest and from left to right.

The display order attributes all follow the same rules. Enter either zero (0) or a negative

value to hide the attribute in the Master Data Manager user interface, or enter a value

greater than 0 to show the attribute in the corresponding user interface element (see the

following table). Fields appear in the order specified by their attributes' display order values.

An attribute will not appear in the search form or search results if data masking has been

applied to the attribute in either the current entity type or any of its derived types.

Including sufficient padding between the attribute sort order values is recommended. This

will allow for future attributes to be added, or for attributes to be reorganized.

Attribute Modifiers

The following additional modifiers can be used to alter the processing of the data within

your hub.

Modifier Description

MDM_HIER_DISPLAY_FLAG This modifier must be set to Y for exactly one attribute for

each entity type. This attribute is used when selecting a value

to use as the entity's name in the Master Data Manager, and

is processed as a required field (including a NOT NULL

constraint for the column in the database).

MDM_READONLY This modifier will cause the Master Data Manager to display

values, but will not allow changes to the values. This can be

useful, for example, to prevent users from attempting to

modify the standardized values, which are computed, in

preference to the non-standardized values.

MDM_REQUIRED When you model an attribute as a required attribute, qMDM


Modifier Description

uses that information to add a NOT NULL constraint in the

database. Attempts to load a record that does not have a

value for a required attribute will be disallowed by the

database.

Note: If you retire a required attribute, the NOT NULL

constraint is still present and can lead to difficulties when

adding more data. Because the attribute is retired, it is not

presented in the Master Data Manager user interface; and

because it is required, if it does not have a value, it cannot be

added to the hub. qMDM cannot drop the NOT NULL constraint

automatically, because the attribute may be involved in

indices that need to be rebuilt. You should involve your

database administrator if you need to retire a required

attribute, and ensure that the NOT NULL constraint is

dropped, and any indices that reference the attribute have

been rebuilt.

MDM_ENCRYPT_FLAG qMDM provides the ability to encrypt sensitive data in the

hub. The data is encrypted while it is stored in the database,

but is transparent to the qMDM application. To enable

encryption for an attribute, set the Encrypt Flag field to Yes in

its attribute definition. After an attribute is published, this flag

is set to read-only and cannot be modified. For this reason, it

is important to decide which attributes to encrypt before an

attribute/entity type is published and its jobs are generated.

The following limitations apply:

Database limitations for encryption apply.

Only string fields can be encrypted. To encrypt integer

values (for example, social security numbers or credit

card numbers), they should be defined as string fields in

the input data.

Use of encrypted fields in cluster conditions and

relationship type definitions is not supported.

Encrypting flux attributes (attributes holding

standardization and match code values) is not supported.

Cluster Conditions

Cluster conditions are sets of attributes that are used to provide an identity to an entity. If

records have the same identity, they become part of the same cluster, and are used when

constructing the survivor record for the cluster. This enables data from disparate systems to

be matched as a way of consolidating information in the hub.


Relationship Types

Relationship types describe a linkage between two entity types. For example, you may want

to maintain a linkage between a Manager and his or her Employees. If the data provided to

the hub includes information that enables the Manager/Employee relationship to be

determined automatically (for example, by including the Manager's employee ID in the

Employee entity), then these relationships can be determined automatically by the hub and

used to explore the resulting graphs of objects within the Master Data Manager user

interface.

Sample Metadata

qMDM provides the following sample entity types, which demonstrate the concepts that are

used to construct a hub. You can use these samples for installation verification, or as study

guides to understand how the hub works.

Part - Represents a product with dimensions.

o Part includes a classification code attribute that can be used (for example) with

the DataFlux Accelerator for Materials Data Classification (MDC).

Note: For more information on the DataFlux Accelerator for MDC, please

contact your DataFlux account representative.

o Part includes a supplier name attribute that supports a one-to-many relationship

with the Company entity type.

o Part also provides a set of lifecycle workflows (which must be enabled), which

demonstrate a simple approval cycle when creating or updating Part data from

the Master Data Manager user interface.

Party - An abstract entity type used to define common attributes, cluster conditions,

and relationship types for Individual and Company.

o Party defines the name attribute shared by both Individual and Company, which

enables search capabilities for entity types derived from it. You can search for

Parties as a way of retrieving both Individuals and Companies.

o Party provides a standardization job (mdm_stnd_party.ddf) that should be

either referenced or reimplemented by derived entity types.

Individual - Represents a person as a kind of Party. Individual builds on Party to

introduce additional attributes for a shipping address, do not call processing, and

demographic information.

o Individual provides a standardization job (mdm_stnd_individual.ddf) that

references the Party standardization job.

o Individual extends the cluster conditions defined by Party.

Company - Represents an organization as a kind of Party. Company builds on Party

to introduce fax and Web site attributes, and adds a relationship type that can be

used to derive relationships to Parts.

o Company provides a standardization job (mdm_stnd_company.ddf) that

references the Party standardization job.


o Company extends the cluster conditions defined by Party.

Generating Jobs

Many of the jobs that you use in qMDM will have a similar structure. The Master Data

Manager user interface makes it easy to generate jobs that embody these default behaviors.

After creating the metadata for an entity type, you can use the Generate Jobs option from

the Entity Type Editor toolbar to create and publish jobs to the Data Management Server.

Selecting this option generates the jobs listed in the following table.

Note: Not all of these jobs will be required in all cases. For example,

abstract entity types will generally support search operations but will not

support any of the other jobs. The unnecessary jobs are shown as dimmed in

the Generate Jobs dialog.

Name Description

mdm_stnd_<entity_type>.ddf Computes standardized and match

codes for use in searches and creating

new records.

mdm_query_survivor_<entity_type>.ddf Searches the hub for matching records

based on specified criteria.

mdm_query_relationship_<entity_type>.ddf Searches the hub for related records

based on specified criteria.

mdm_query_cluster_<entity_type>.ddf Searches for contributor records for a

specified entity.

mrm_add_<entity_type>.ddf Adds new records to the hub from the

Master Data Manager user interface.

mrm_edit_<entity_type>.ddf Supports lifecycle workflows from the


mrm_move_<entity_type>_records.ddf Supports moving records between

clusters.

mrm_revert_move_<entity_type>.ddf Reclusters moved records so they can

cluster according to the conditions

specified by the entity type.

add_update_<entity_type>.djf Bulk-loads data into the hub.

mdm_archive_<entity_type>.djf Removes retired records from the hub.

We suggest that you start with these templates, and modify them according to your needs.

When modifying these jobs, look for comments that provide information on how to modify

the job, as shown in the following examples.


Sample Job Template

Comments Inside Job

Loading the qMDM Hub

qMDM provides sample jobs that demonstrate how to load records into the qMDM hub using

batch interfaces. These jobs are named add_update_<entity_type>.djf, and can be

generated using the Master Data Manager user interface. The sample jobs generally read

their data from a file, perform the previously described clustering and survivorship steps,

and then add the data to the qMDM hub.

Each add_update_<entity_type>.djf job starts with an Echo node that provides defaults

for parameters used by the jobs, such as:

The file name for the data

Database credentials

Parameters controlling the use of bulk load mechanisms such as the Oracle sqlldr or SQL Server bcp utilities

These parameters can be updated in the Echo node, or provided on the command line using

dfwfproc. For more details on running jobs from the command line, see the DataFlux Data

Management Studio User's Guide.


The sample jobs use the metadata defined for the entity type to ensure that all the required

fields (including the label attribute and the QKB locale) are present. Without these values,

the data cannot be written to the database. Records that fail this check are written to a file,

where they can be corrected and replayed.

For optimized bulk loading, configure the jobs to use the appropriate database utility by

specifying IS_MAX_LOAD = Y on the Inputs tab for the Echo node. Update the other

inputs to specify your credentials, database server, database, and input file.

Note: Running more than one occurrence of an

add_update_<entity_type>.djf job when IS_MAX_LOAD = Y is not

supported. The DBMS-provided bulk load utilities make changes directly to

the underlying database storage that will conflict when running multiple

occurrences of the job. If IS_MAX_LOAD = N, multiple occurrences of the

job can be run simultaneously.

SQL Server

If you are using a SQL Server database, you will need to generate the .bcp files used to

load the staging tables and place them in [qMDM Install Dir]\Accelerators\DataFlux

qMDM Solution 3.2\sample\scripts:

mdm_company_st.bcp

mdm_individual_st.bcp

mdm_part_st.bcp

For more information on generating .bcp files and adjusting the generated files to match

the input data files as prepared by the job, see http://msdn.microsoft.com/en-

us/library/ms191479.aspx. The sample jobs generate their files by placing the field names

in alphabetical order, which does not necessarily correspond to the table structure.

Managing Updates

It is possible to reprocess every row that might have changed in a weekly update using the

same manner, but this is not the most efficient way to handle changes. If each source

system could be made to record changes to its own records and identify new or deleted

records, then just those changes could be selected and processed as updates against the

qMDM hub. The delta files could be created using any Extraction, Transformation, and

Loading (ETL) process, or using DataFlux, assuming it can access the files themselves.

However, if changed, added, or deleted records cannot be found prior to direct qMDM hub

interaction, then it is still possible to preprocess the data file and get better performance

from the main qMDM hub update process. Data clustering and survivor record creation, or

survivorship, together are the slowest processes in qMDM. While at initial batch load time

this can be designed to run quickly because much of it can be done in memory, when the

customer hub is already loaded, the process must first query the database to find similar

rows and then clustering and survivor record creation can take place.

Rather than recluster the entire hub or even recluster for every possible new or updated

customer record on its way into the qMDM hub, we can identify the types of changes in data

updates bound for the qMDM hub. By determining the rows in the update set that are new,

or that could create changes to clusters, or those that will not affect clusters and are

unchanged, we can route only a subset of the batch update through the more intensive

clustering processing, in this case the new rows and the possible cluster-changing rows.

http://msdn.microsoft.com/en-us/library/ms191479.aspx

http://msdn.microsoft.com/en-us/library/ms191479.aspx


Other rows can be dropped or sent through a much more efficient DataFlux process that can

be used to update attributes that do not have any clustering or survivor record implications.

DataFlux can be used for this process or any other tools with data access and data

comparison capabilities.

The main requirement for this type of procedure is to have constant unique identifiers in

source systems. The source system record ID and source system code are saved with every

entity in the qMDM hub. Using these keys, we can relate what is currently in the qMDM hub

to potential updates to the qMDM hub, and categorize the types of updates prior to initiating

the load process.

Pushing and Pulling Source System Changes

DataFlux recommends a three-step strategy for the update process:

The first step is to run batch processes on source systems that pull out potentially

changed data.

The second step is to sift through the potential updates and categorize the data into

groups bound for the qMDM hub.

The third step is to take the new and modified data, and run it through a DataFlux

process to update the qMDM hub.

Cluster Changes and Hierarchies

Hierarchies consist of relationships between entities. When clusters are merged or retired,

this may affect the hierarchies.

Clusters can merge in response to a record being moved manually through the Master Data

Manager user interface, or as the result of an update that matches multiple clusters. When

a merge occurs, qMDM will apply the same changes to any related hierarchies. Nodes that

were previously merged will be replaced with a single reference to the new entity, which

also has the same child nodes of the previously separated clusters.

Clusters can be retired by using the Retire option from the Master Data Manager Entity

Editor. When an entity is retired, the hierarchy nodes for that entity are also retired. This

enables you to react to the retirement by updating the hierarchies according to your needs.

Recovering from Load Problems

The sample jobs write the incoming data into a staging table (one per entity type) prior to

updating the qMDM hub. Only after the data has been successfully staged will the data be

applied to the qMDM hub. If a problem occurs during the load operation, the transaction is

rolled back. The records remain in the staging table, and the qMDM hub remains available

and consistent.

The MDM_PROCESS_CONTROL table contains information about all the load jobs and their

status, and can be used to determine the staging ID. Failing loads are identified by the

column in the MDM_PROCESS_CONTROL table, which has a unique value for each load

process, and can be used to recover from the failure by either deleting those records from

the staging table, or restarting the go live process.


Trimming Historical Data

The qMDM hub continues to expand with each insert and update. Retired and not-yet-active

records are maintained in the hub. This information can be used for historical tracking

purposes. No data is deleted during normal qMDM operation, although if the information is

no longer needed, it can be moved to offline storage to free up resources.

The exact requirements for removing data from the qMDM hub can vary greatly. qMDM

provides a sample job that is suitable for customization. Within the job there are highlighted

notes on how to modify the job for your particular entity type. The

mdm_archive_<entity_type>.djf job, in its original state, is used to generate archive

files for the entity type. It cannot be accessed through the Master Data Manager; you must

run it manually. The mdm_archive_<entity_type>.djf job is generated using the Master

Data Manager User interface. The job does the following:

Generates the archive files for expired audit records, expired error records, affected

hierarchy records, expired cluster members, and expired transpose records.

Deletes any expired audit records, expired error records, affected hierarchy records,

expired cluster members, and expired transpose records.

Cleans empty clusters.

Cleans up entities from the database.

Migrating from a Master Data Management Foundation Hub

If you have used Data Management Studio to create a Master Data Management Foundation

hub, you can migrate the metadata and instance data from that hub into qMDM.

Note: For more information on the Master Data Management Foundation

feature, see the Using Master Data Management Foundation section of the

DataFlux Data Management Studio User's Guide.

Migrating Metadata

The metadata maintained by Master Data Management Foundation is a subset of the

metadata maintained by qMDM. After migrating the metadata, you should plan to review

the entity type definition, and augment the metadata with presentation metadata (for

example, configuring which attributes will appear in the Master Data Manager search and

editor interfaces).

To migrate data from Master Data Management Foundation, you must configure a data

source for the Master Data Management Foundation hub, and you must know the schema

name for the hub.

Importing Source Systems and Languages

The source systems that provide data to the Master Data Management Foundation hub, and

the language for the hub, may or may not be known to qMDM. You can import the source

systems and languages defined in the Master Data Management Foundation hub by using

the migrate_mdf_meta.ddf job, available in the sample\templates\meta directory.


You will need to configure the Echo node at the top of the job, and ensure that the

MDF_DSN and MDF_SCHEMA inputs correspond to your hub.

When you run the job, it will import any source systems and languages that are not already

known to the qMDM hub.

Importing Master Data Management Foundation Metadata

Master Data Management Foundation entity types are configured from XML files with a .met

extension. These files include information about an entity type, its attributes, and its cluster

conditions, but lack the presentation information that qMDM requires to display the instance

data within the Master Data Manager user interface. After importing a .met file, you should

review the entity type definition, and augment the metadata appropriately.

Use load_met.djf batch job, available in the templates\meta directory, to load these files

into the hub.

1. In the Echo node, set the metFile variable to the fully qualified path of your .met

file.

2. Set the locale variable to the name of the locale to use during the import. Only one

locale can be imported from a .met file and it should match the locale used to

generate the .met file originally.

Note: The load_met job is intended for the initial load of metadata in the

hub, therefore, objects that already appear in the hub will not be reprocessed

during job execution. If you would like to merge the .met file into an existing

hub (potentially including updates to existing objects), use the import

facilities provided by Master Data Manager. Refer to Definitions Riser

Overview - Import Model for additional information.

Migrating Instance Data

After the metadata has been synchronized, you can use the Master Data Manager user

interface to generate the jobs to support the imported entity type. For more information on

generating jobs for an entity type, see Entity Type Editor.

One of the jobs generated by this process is add_update_<entity_type>.djf. The

MDF_DSN and MDF_SCHEMA variables required for this job must be supplied in the Echo

node of this job. To import data from a Master Data Management Foundation hub, the Read

Input Data job node must be modified.

In the Read Input Data job node, the nodes shown in green are either newly added or

modified for migrating Master Data Management Foundation instance data. The following

sections provide details on each individual node. Where applicable, <entity_type> should

be replaced with the entity type name.


add_update_<entity_type>.djf Job

Data Source Node

Set the Data Source node to read only user-defined attributes along with

MDM_SRC_SYS_ID, MDM_SRC_SYS_REC_ID, and MDM_LANGUAGE_ID from the Master

Data Management Foundation hub.


Set the output names for MDM_SRC_SYS_ID and MDM_SRC_SYS_REC_ID as follows.

Set Datetime Node

In the Set Datetime node, initialize the curr2_dttm variable.


Get MDF Src Sys Node

In the Get MDF Src Sys node, set the source systems known to Master Data Management

Foundation. The date range comparison excludes retired source systems from the results.


Join Src Sys Path Node

In the Join Src Sys Path node, determine the source system for the incoming data by

joining on the source system ID. Be sure to include the MDM_SRC_SYS_PATH value, which

is used to determine which qMDM source system is being referenced.

Get Existing Src Sys Node

In the Get Existing Src Sys node, get the known qMDM source systems (and their path

columns MDM_SRC_SYS_PATH) to allow transformation from Master Data Management

Foundation source system identifiers to qMDM source system identifiers.


Join Src Sys Id Node

In the Join Src Sys Id node, join the records based on the path information for the source

systems.


Adjust Src Sys Id Node

In the Adjust Src Sys Id node, replace the Master Data Management Foundation source

system ID with the corresponding qMDM source system ID.


Dump Failing Records Node

Modify the Dump Failing Records node to reflect the input node fields.

Reporting on the qMDM Hub

Enabling the Master Data Dashboard Report

Before running the qMDM Master Data Dashboard report, you must first generate data for

the report. A batch job named dashboard_stats.djf is provided in the

templates\dashboard directory as part of the qMDM installation. Running this job will

update the metrics that the report presents. Running the job again will remove the previous

metrics and regenerate the data. You may want to use a task scheduler such as 'at' or 'cron'

to run this job at regular intervals.

Auditing and Reporting

DataFlux developers often use Data Management Studio to analyze data in the qMDM hub

using data profiling metrics. These metrics make it possible to preview the structure of data,

providing valuable insight into its quality and integrity in an effort to meet an organization's

specific needs. With Data Management Studio, you can easily find and correct defects within

the data, maintaining data quality and integrity by:

Selecting and connecting to multiple databases of your choice through ODBC without

worrying about the sources being local, over a network, on a different platform, or at

a remote location.

Creating virtual tables using business rules from your data sources to scrutinize and

filter your data.

Simultaneously running multiple data metrics operations on different data sources.


Running primary and foreign key analysis, as well as redundant data analysis, to

maintain the referential integrity of your data.

Monitoring the structure of your data as you change and update your content.

Using qMDM Transpose Tables for Reporting

When the metadata for entities is defined and loaded, a qMDM database transpose table is

created for each entity. For example, if you create an entity named CUSTOMER, a qMDM

database table named MDM_CUSTOMER_TT is created. This table manages the attribute

information for records of the corresponding entity type. The MDM_ENTITY and

MDM_ENTITY_CLUSTER_MEMBERS tables manage additional metadata about the

record, such as the expiration date and cluster membership. When new CUSTOMER data is

added to the qMDM hub, a new row is added to each of these tables, and a new row of data

is added to the MDM_CUSTOMER_TT table.

After the data is stored in this format, it is available in a view that brings additional useful

fields together to facilitate reporting and querying the qMDM hub. For COMPANY, an

MDM_COMPANY_TV view is created, joining data from the MDM_COMPANY_TT,

MDM_LANGUAGES, and MDM_ENTITY_CLUSTER_MEMBERS tables. The result is a view

with all contributor, survivor, active, and inactive records for the COMPANY entity type.

Generally, users will not want the contributor or inactive records in a result set when

reading from this table. Users typically want the active survivor records. For standard

reports against this table, your select query should include the following in the WHERE

clause:

mdm_src_sys_id=1 and mdm_valid_from_dttm <= (current date) and

(mdm_valid_to_dttm is null or mdm_valid_to_dttm > (current date))

In the query, (current date) should be replaced with the appropriate function for your

database:

Oracle - sysdate

SQL Server - getdate()


Business Processes and the Entity

Lifecycle qMDM embeds a workflow engine in support of the entity lifecycle, which allows

administrators to describe business processes that must be fulfilled before a change is made

available in the qMDM hub. By using workflows to support the entity lifecycle, you can

collaborate on the creation or update of an entity without having the intermediate steps

reflected in the survivorship for the entity. You can establish review cycles before changes

are made live, route tasks to people or roles for completion, and monitor the state of the

workflow as it progresses.

The business processes that are deployed on the workflow engine are optional; if you prefer

not to use workflows as part of the entity lifecycle, you do not have to do anything different.

If you choose to use the workflow support, you will need to describe business processes for

each entity type that handles the processing associated with creating and updating entities.

The workflow engine bundled with qMDM is from OSWorkflow 2.8.0 , which is a lightweight

and reasonably powerful business process engine. Additional tools and documentation are

available from OpenSymphony at http://www.opensymphony.com/osworkflow/. The

following implementation details will help you make the most of the engine within qMDM.

Configuring Business Processes

Generating an Edit Job

Workflow Logging

Handling Roles

Make Live Processing

Configuring Business Processes

The DataFlux qMDM Solution incorporates the OpenSymphony OSWorkflow workflow engine

with Master Data Manager. If you plan to use workflows as part of your qMDM installation,

the information in this section will help you to configure and package them for deployment.

This section assumes an understanding of OpenSymphony Workflow (OSWorkflow). For

more information, see the OpenSymphony documentation at

http://www.opensymphony.com/osworkflow/.

Enabling Lifecycle Workflows

By default, only the tag entity workflow is enabled in the OSWorkflow workflow engine. If

you want to enable additional workflows to support entity lifecycles, you must configure the

[webapp]\WEB-INF\conf\qmdm-workflow.xml file to include those workflows, and

ensure that the workflow engine references this file.

The workflowFactory section of qmdm-workflow.xml identifies the file used to identify

workflow processes:

http://www.opensymphony.com/osworkflow/

http://www.opensymphony.com/osworkflow/

<bean id="workflowFactory"

class="com.opensymphony.workflow.spi.hibernate.SpringWorkflowFactory" init-

method="init">

<property name="resource"><value>com/dataflux/solutions/cdi/opensymphony/tag-

workflow.xml</value></property>



<property name="reload"><value>true</value></property>

</bean>

To enable the sample entity lifecycle workflows, change the reference to tag-

workflow.xml (shown in bold above) to workflows.xml.

For more information on building and deploying additional workflow definitions, refer to the

DataFlux qMDM Solution User's Guide.

Packaging

OSWorkflow loads its workflow definitions from the classpath; therefore, the workflow

descriptors must appear in a location where Java can find them:

WEB-INF\classes, as individual files

WEB-INF\lib, as a jar file

By default, the workflows are packaged in dfx-qmdm-workflows.jar and placed in WEB-

INF\lib. dfx-qmdm-workflows.jar must contain a file called workflows.xml, that

identifies the resources provided by the jar, for example:

<workflows>

<workflow name="create_part" type="resource"

location="com/dataflux/solutions/cdi/opensymphony/create-part.xml"/>

<workflow name="update_part" type="resource"

location="com/dataflux/solutions/cdi/opensymphony/update-part.xml"/>



<workflow name="tag_entity" type="resource"

location="com/dataflux/solutions/cdi/opensymphony/tag-entity.xml"/>

</workflows>

The resources listed here represent the set of workflows supported by the system. Note that

the paths are relative to the WEB-INF\classes directory, or the root of the jar file, as

appropriate.

To deploy new workflows, an administrator must perform the following steps. Similar steps

apply to removing workflows from the system:

1. Deploy the workflows on the server by copying individual files under the correct path

in WEB-INF\classes, or by updating dfx-qmdm-workflows.jar using a tool such

as WinZip or jar to include those files on the correct path.

2. Update the workflows.xml file to reference the new workflows.

Generating an Edit Job

To avoid constructing a new record every time an entity transitions through a workflow,

qMDM uses a special edit service that is aware of the workflow status of an entity. The edit

service will create a new record if this is the first step or if a new entity is being created, or

update an existing record if the entity is already in a workflow. This service is similar to the

mrm_add_<entity_type> services and must be generated for each entity type that will

support workflows.

The edit job takes into account the presence of an entity ID, and either creates a new

record if an entity ID does not exist, or finds the appropriate record from the database if an

entity ID exists. If a workflow record does exist, the existing record is updated.

Workflow Logging

OSWorkflow stores the workflow definitions on the file system, and refers to labels by their

IDs in the data model. This approach complicates queries; however, qMDM provides an

MDM_WORKFLOWS table to simplify reporting.

Workflows are required to log their start and completion in the MDM_WORKFLOWS table.

Two actions are provided to simplify this requirement.

To log the start of a workflow, add the following post-function to the initial action for the

workflow:

<workflow>

<initial-actions>



<action id="1" name="Start Workflow">

…

<results>

…

</results>

<post-functions>

<function type="class">

<arg name="class.name">

com.dataflux.solutions.cdi.workflow.LogWorkflowStart

</arg>

</function>

</post-functions>

</action>

</initial-actions>

To log the completion of a workflow, add the following post-function to the final step in the

workflow:

<step id="4" name="Finished">

<actions>

<action id="8" name="Finished" auto="true" finish="true">

…

<post-functions>



com.dataflux.solutions.cdi.workflow.LogWorkflowCompletion

</arg>

</function>

</post-functions>

</action>

</actions>

</step>


Handling Roles

OSWorkflow does not understand Authentication Server groups, which qMDM interprets as

roles. Some conventions in the workflow specification itself are required to support this. A

workflow definition is an XML file. Every step within it can be assigned an owner. The

sample implementation has been written so that either a user identity or a role can appear

as the owner of a particular step. For example, the first step in the tag-entity workflow sets

the owner to the MDM_Steward role:

<action id="1" name="Start Workflow">

<results>

<unconditional-result id='1' old-status="Finished"

status="Review" step="1" owner="MDM_Steward"/>

</results>

…

When the assigned tasks are enumerated, the roles that the user has been assigned are

factored in, and this task will appear for all stewards. If a task is assigned to multiple

people, there could be conflicts as multiple people attempt to complete the task. The design

of the workflow can be relied upon to handle this problem by introducing Accept and

Release actions in the workflow to change the assigned user from a role to an individual.

This action uses a function object named Caller to determine the principal that has invoked

this action, then sets the owner to that value. This removes the task from the other

stewards and assigns it to an individual:

<action id="2" name="Accept">

<restrict-to>

<conditions>

…

</conditions>

</restrict-to>

<pre-functions>


<arg name="class.name">com.opensymphony.workflow.util.Caller</arg>

</function>

</pre-functions>

<results>

<unconditional-result old-status="Finished"

status="Reviewing" step="1" owner="${caller}"/>

</results>

<post-functions>

…

</post-functions>

</action>

Releasing the task is similar. The conditions require that the task be in the proper state and

that only the owner is allowed to perform this action. If those conditions are met, the owner

is then set to the MDM_Steward role and releases the task to be handled by all of the

stewards again:

<action id="3" name="Release">

<restrict-to>

<conditions type="AND">

<condition type="class">

<arg

name="class.name">com.opensymphony.workflow.util.StatusCondition</arg>

<arg name="status">Reviewing</arg>

</condition>


<condition type="class">


com.opensymphony.workflow.util.AllowOwnerOnlyCondition

</arg>

</condition>

</conditions>

</restrict-to>

<results>

<unconditional-result old-status="Finished"

status="Review" step="1" owner="MDM_Steward"/>

</results>

<post-functions>

</post-functions>

</action>

Make Live Processing

Editing entities is different from non-workflow edits, in that the changes are not committed

until the workflow reaches a step that makes the changes live. The workflow can continue

on beyond this point, as needed. To keep workflow edits separate, they are stored with

dates in the far future, which precludes them from participating in actions such as searches

and clustering. The workflow edits are stored using a job that is capable of updating existing

records (and does not result in the creation of a new contributor record, which is the usual

operation).

The Master Data Manager is used to make changes live, to minimize the interdependencies

of the workflow engine, Data Management Server, Authentication Server, and Master Data

Manager. When the set of available transitions is returned to the Master Data Manager, the

service looks for an action named MakeLive:

<action id="7" name="MakeLive">

<restrict-to>

…

</restrict-to>

<results>

…

</results>

</action>

When the MakeLive action is detected, the Master Data Manager reads the staged entity,

stores it as a new contributor record, and removes the record that was created by the

workflow. The Master Data Manager then computes the next set of transitions, and returns

it to the application.

Note: Entity lifecycle workflows are required to have an action named

MakeLive.


Data Masking When constructing a centralized repository for use across an enterprise, data governance

precepts require security. Organizations need the ability to secure access to data, to restrict

access to people and systems with a legitimate business use for the data, and to audit

changes to the data. Data masking is concerned with restricting access based on business

requirements. By configuring data masking, you can control which groups have access to

different kinds of information. You can specify controls for:

Wholesale restriction to information about an entity type. For example, a subset of

users may have access to COMPANY data, while being unable to access PART data.

Coarse-grained restriction to attributes within an entity type. For example, a subset of

users may have access to COMPANY data, while being unable to access contact

information modeled within the COMPANY entity type. Access is either allowed or

denied. There is no support for allowing attributes to be viewed but not edited, for

example, beyond the existing MDM_READONLY modifier for an attribute.

Wholesale restriction to hierarchy types. This restriction recognizes that hierarchies

represent another channel to access information about an entity. In this case, the

information is about the relationships in which an entity is involved. For example, if a

user does not have access to the COMPANY entity type, that user should not have access to hierarchies where COMPANY entities can appear.

If you do not want to use the qMDM data masking capability, no action is required. By

default, all access is granted. However, when an explicit grant is made to one of the

controlled types of information, grants for that information become mandatory:

If no access rule is defined, access is allowed.

If an access rule is defined and the user has at least one role required by the rule,

access is granted. This includes the case where the user has a role with the root

permission set, which grants access to everything.

If the user does not have any roles required by the rule, access is denied.

Note: For entity types, the label attribute must be accessible. For example, if the entity

type has been explicitly granted, but the label attribute has been restricted, the entity type

itself is restricted.

All configured constraints must be satisfied before access is granted. This is most important

in the case of hierarchies, where users require access to both the hierarchy types and the

entity types that are contained in the hierarchy. Hierarchies are constrained to only allow

certain entity types. To access a hierarchy, a user must have roles that allow access to both

the hierarchy type and all the entity types that can be referenced by that hierarchy type.

Defining Roles

Interaction with Data Management Server Permissions

Managing Access

Designing Jobs


Defining Roles

Roles represent a set of privileges within the qMDM system and are identified by the groups

to which a user identity is assigned within the Authentication Server. The roles must also be

registered with qMDM, because the Authentication Server may have groups defined that are

not used by qMDM. For example, the PUBLIC group is present in every Authentication

Server installation, but by default has no meaning within qMDM. Users may belong to

multiple groups, and the set of roles for a user is a combination of roles from all the groups

to which the user belongs.

At least one role must be defined as having all privileges, as denoted by the IS_ROOT

attribute of the role. Users with this role have access to everything within qMDM and are

responsible for administering the system, including both instance data and metadata. By

default, the metadata files use the MDM_Steward group for this purpose.

When creating additional roles for data masking, you should consider the needs of the users

of the information stored within qMDM. The roles should be defined at the appropriate

granular level to provide access to the information and nothing else. For example, consider

these cases:

Alice in Payroll requires both employee address information and employee financial

information.

Bob in Human Resources requires employee address information, but does not require

employee financial information.

Charlie in Manufacturing does not require any employee information.

This situation requires two roles in addition to the MDM_Steward role:

Alice should be assigned a PAYMASTER role, which grants access to the employee

entity type and the financial attributes.

Bob should be assigned an HR role, which grants access to the employee entity type,

but does not have any particular restrictions on attributes. Bob will not be able to

access any financial attributes because Alice's role restricts access to that information.

Charlie is not assigned either role. Since Alice and Bob's roles restrict access to the employee entity type, Charlie will not be able to access any employee data.

If another employee, David, requires access to financial attributes, a new role can be

created that has access to those attributes. Then Alice and David would both be assigned

that role, or a new role could be created just for David's use.

Enabling Advanced Search

The Advanced search function will be available from the Entity Search panel on the Master

Data riser if a role that is assigned to the user has been granted the

mdm_enable_adv_search permission. The Advanced search function enables users to

submit arbitrary queries to the database and is intended for advanced users only. The SQL

will be submitted to the database as written and may result in long-running queries, as well

as updates or deletions of data within the qMDM hub.


Interaction with Data Management Server Permissions

On Data Management Server, you can configure permissions that either allow or deny

access to jobs to users and groups. In some cases, there are entity type–specific jobs that

can be controlled effectively by using permissions. In other cases, only one job provides

access to all the entity types. Because of this difference, not all security configurations can

be handled with permissions alone. Also, permissions are insufficient to provide control over

individual attributes because they operate at the job level, and cannot handle interactions

where a user has been granted access to a hierarchy type, but not the entities within the

hierarchy. For these reasons, permissions should be considered a necessary but insufficient

component of data security, which is augmented by the qMDM data masking capability.

For more information on Data Management Server permissions, see the DataFlux Data

Management Server Administrator's Guide.

Managing Access

Access can be granted through batch interfaces. The add_sample_meta.djf job provides

an example of loading authorization information from text files. Access can also be granted

interactively using the association tables available from the Master Data Manager

Definitions riser. Batch interfaces will be easier to use if you have a large number of

authorizations to set up.

Note: Authorization changes made after a user logs on, are not recognized

until the user logs off and logs on again.

Designing Jobs

The data masking implementation operates in the Business tier of qMDM, which requires

that extensions or modifications to the jobs provided by qMDM take data masking into

account:

Jobs that must make authorization decisions should use a variable named

MDM_USER_ROLES, which is a comma-delimited string of roles assigned to the

current user.

Jobs that access metadata should use one of the query_auth jobs in the system, for

example, mrm_query_auth_entityType.ddf, to take advantage of the role checking

that these jobs perform. If you choose not to reference these jobs, you should study

their operation to ensure that your implementation meets the same requirements.

Jobs that query the database directly should join with the appropriate table back to

the roles table, and ensure that the queries factor in retirement status for

authorization records and adhere to the grant decisions as outlined above. For

example, to determine the entity types that are accessible to a user with the MDM_BIZUSER role, the following query might be used. select et.mdm_entity_type_id,et.mdm_entity_type from mdm_entity_types et where

mdm_entity_type_id in

(

select etr.mdm_entity_type_id from mdm_entity_type_roles etr

where sysdate between etr.mdm_valid_from_dttm and etr.mdm_valid_to_dttm


and etr.mdm_role_id in

(select mdm_role_id from mdm_roles

where mdm_role_name in ('MDM_BIZUSER'))

union

select et2.mdm_entity_type_id from mdm_entity_types et2

where et2.mdm_entity_type_id not in

(select mdm_entity_type_id from mdm_entity_type_roles

where sysdate between mdm_valid_from_dttm and mdm_valid_to_dttm)

union

select et2.mdm_entity_type_id from mdm_entity_types et2 where 0 <

(select count(1) from mdm_roles

where sysdate between mdm_valid_to_dttm and mdm_valid_from_dttm

and mdm_role_name in ('MDM_BIZUSER') and mdm_is_root='Y')

The three clauses in the sub-select check the following conditions:

1. If there is an active grant for the user based on the roles, the entity type is included.

2. If there are no active grants, the entity type is included.

3. If the user has any super-user roles, the entity type is included.

Note: Role names are tested using the in predicate, because any user can

have more than one role.

Note: Role names should be compared in a case-insensitive manner.


Overview of Master Data Manager User Interface The DataFlux® qMDM Solution uses a browser-based user interface called the Master Data

Manager, which provides a powerful, flexible, and efficient means of configuring and using

qMDM.

Master Data Manager User Interface

Logging On

User Interface Elements

Logging On

To log on to the qMDM Master Data Manager user interface, complete the following steps.

For more information on the Master Data Manager user interface elements, see User

Interface Elements.


1. Your qMDM administrator will give you the URL to access Master Data Manager.

Browse to this address to display the Master Data Manager logon page.

2. On the Master Data Manager logon page, enter your user ID and password.

3. Select the locale that you want to use for this Master Data Manager session. All

Master Data Manager user interface elements will be displayed in the selected locale's

language.

4. Click Log On to display the Master Data Manager user interface.

User Interface Elements

The Master Data Manager user interface contains the following main elements. In addition,

the user interface contains several common elements.

Header

Navigation Pane and Risers

Information Pane


Master Data Manager User Interface

Header

The header at the top of the Master Data Manager user interface contains a toolbar that

shows the user ID of the currently logged-on user. The following buttons are also located on

the header toolbar.

Header Toolbar

Help - Opens the HTML-based DataFlux qMDM Solution User's Guide (this document)

in a new browser window or tab.

Overview - Displays overview information that describes the capabilities of the

currently selected riser and provides useful links to more information. The overview

information also appears whenever there is no other content to display for a riser.

About - Opens an About Master Data Manager dialog with the following two tabs:

o About - Displays qMDM version information, the user ID of the currently

logged-on user, and copyright information.

o System Configuration - Displays the computer name, DataFlux plugin paths,

Data Management Server version, server information, QKB version, OS version,

database product and version, and Java version.

Log off - Logs the current user off the system.


Navigation Pane and Risers

The navigation pane on the left side of the Master Data Manager user interface contains

the following four riser bars (risers), which correspond to the main functional areas of

qMDM.

Riser Description

Reports Enables you to run qMDM predefined reports, including both batch reports and

dynamic reports (reports that expect user input).

Workflows Provides access to the qMDM system tasks for which you are responsible.

Master

Data

Enables you to search for, edit, create, and retire master data entities and

hierarchies.

Definitions Used by the data steward to update qMDM metadata, including entity and

attribute definitions. The Definitions riser is available only to users who have

an administrative role.

When you navigate to a different riser, any information or data that is displayed on the

current riser will remain on the riser, unless the Master Data Manager session times out and

closes, or you log off without saving the data.

Information Pane

When you open content from a riser, it appears in the information pane on the right side

of the Master Data Manager user interface.

If no content has been opened for the selected riser, the information pane displays overview

information that describes the capabilities of the riser and provides useful links to more

information. You can also display the overview information for a riser by clicking the

Overview button on the Master Data Manager header toolbar. To return to the content that

you had opened, double-click any element in the riser.

Common Elements

Tabs

Pane Split Bars

Navigation Trees

Tables

Paging Controls

Toolbars

Editors

Forms and Field Sets

Tabs

Tabs in the Master Data Manager information pane make it possible to have many activities

in progress simultaneously.


If you open a large number of tabs, there may not be sufficient room to show them all.

When this happens, an overflow menu appears on the right, providing access to the tabs

that cannot be displayed because of space limitations.

Each tab has a context menu with Close Tab, Close Other Tabs, and Close All Tabs

options. To display the context menu for a tab, right-click the tab. You can close a tab by

clicking the X icon on the right side of the tab.

Tab Context Menu

Pane Split Bars

To resize the split panes on the Master Data riser, click and drag the vertical and horizontal

split bars located between the panes.

Pane Split Bars

Navigation Trees

Hierarchical information is generally presented in navigation trees in the Master Data

Manager navigation pane.


Navigation Tree with Context Menu

Navigation trees show the relationships between the elements graphically. Examples

include:

Open tabs on the Master Data riser, which are arranged in a tree based on the object

types that are opened on the tabs

Entity relationships expressed as hierarchies on the Master Data riser

Attribute displays on the Definitions riser, where standardized and match code

attributes are presented as children of the attribute with which they are associated

Navigation trees consist of a series of nodes that can be expanded (+) and collapsed (-) to

manage the display of information.

You can double-click a node in a navigation tree (or right-click the node and select Open

from the context menu) to display the details of an item.

Tables

The Master Data Manager commonly presents lists of objects in a tabular form. These tables

show a subset of the information associated with the objects. All entries in a table will be of

the same kind of object.

You can double-click a table row (or right-click the row and select Open from the context

menu) to display the details of an item. Some editors may support more than one view. For

example, an Entity Editor can display the properties of a record, the members of the cluster,

the hierarchies where the entity is referenced, and the entity's relationships with other

entities. If the editor supports more than one view, the context menu will provide an Open

as option that enables you to access those views directly.

Sorting Tables

To sort a table column in either ascending or descending order, click the column header.

Sorted columns will display up or down arrows to indicate the sort direction.

Showing or Hiding Table Columns

To show or hide a table column, right-click the column header. From the context menu,

select the column that you want to show or hide. A check mark beside a context menu

option indicates that the corresponding column is visible.


Table Context Menu with Visible and Hidden Columns

Paging Controls

Master Data Manager search results and other windows or panes that display database data,

may have multiple pages of results. Navigation between pages is made easier with the

paging controls. The paging format is [Record Range] of [Total Records].

In the following example, records 1–50 out of 481 total records are shown.

Paging Controls

To go to the first page, previous page, next page, or last page, navigate using the standard

arrow controls.

Toolbars

Toolbars at the top of Master Data Manager reports, editors, and tables may contain the

following options. Other options may also appear, depending on the context. Many of the

toolbars contain an Actions menu with all of the available options. The most commonly

used options are also available directly from the toolbar.

Open - Opens a report, editor, or table.

Print - Prints the current report, editor, or table contents.

Note: The Print option will process the information currently displayed in the

browser. If you need access to the complete report, editor, or table contents, use the

Export option instead.

Export - Displays a secondary menu with options for exporting the current report,

editor, or table contents in either comma-separated values (CSV), PDF, or Excel

format.


Export Menu

Save - Saves the report, editor, or table contents.

Reset - Discards changes and resets the report, editor, or table to its original state.

New - Creates a new entity, hierarchy, or definition.

Retire - Retires an entity, hierarchy, or definition.

Note: Only data stewards can retire definitions.

Editors

Editors are form-based presentations for single objects. They typically enable you to modify

the data that they present, although not all information may be modifiable directly. Forms

generally provide access to more data than navigation trees or tables, and include a toolbar

with additional options.

Editors are opened in response to Open actions, or to double-clicking a navigation tree

node or a table row.

Some editors contain tabs that expose different facets of an object. For example, the

Definitions riser Entity Type Editor provides tabs that present defined attributes, cluster

conditions, and relationship types for the entity type. Similarly, the Master Data riser

Entity Editor provides tabs that show the contributor records for an entity survivor record,

the hierarchies in which the entity appears, and a graphical representation of the entity's

relationships with other entities.

Forms and Field Sets

Many parts of the Master Data Manager user interface use forms to group related fields into

field sets. You can expand or collapse a field set by clicking the expand/collapse

buttons.

Required fields are marked with asterisks (*) and have a light yellow background color.

Read-only fields appear dimmed.

Invalid field entries are marked with a red jagged border and an error indicator. You can

hover the mouse over the error indicator to view information about the invalid field entry.


Form with Required and Read-Only Fields and Invalid Field Entry

For date fields, you can either enter the date directly or click inside the field to display a

calendar. From the calendar, click on a valid month and year that you want to load. Click

the backward or forward buttons to access a valid year.

Click anywhere outside the calendar to hide it.


Calendar

Note: Use a four-digit year when entering dates directly; otherwise, you

may encounter unexpected results. For example, 10/10/1970 is preferable to

10/10/70.


Reports Riser The Reports riser enables you to run predefined reports and to view report results. From

the Reports riser, you can access reports that have been deployed on the Data

Management Server where qMDM is deployed.

Reports Riser

Reports Riser Overview

Running Reports

Master Data Dashboard Report

Workflows Dashboard Report

Reports Riser Overview

Report Types

qMDM provides the following two report types:

Dashboards

Data Management Server reports


Dashboards

The Master Data Dashboard report and Workflows Dashboard report display various metrics

about the qMDM hub and workflows in the hub.

Note: The Dashboard reports are available only to users who have an

administrative role.

Data Management Server Reports

Data Management Server reports are batch jobs and data services that have been built with

Data Management Studio and deployed along with the other jobs that are provided with

qMDM. There are two types of Data Management Server reports:

Batch reports run asynchronously and typically generate HTML output. Previous runs

of a batch report appear in the reports tree as child nodes under the report node.

Dynamic reports run synchronously. Dynamic report results appear on tabs in the

information pane. The results for each report appear on a separate tab.

Note: For both batch reports and dynamic reports, report names must

begin with rpt in order to appear in the reports tree. All reports must be

published to Data Management Server. Batch reports must be placed in

batch_jobs\qMDM, and dynamic reports must be placed in

data_services\qMDM. Additional folders under qMDM will not be

processed.

Reports Tree

On the Reports riser, the available reports appear in a navigation tree.

Note: The Dashboards node in the reports tree appears only for users

who have an administrative role.

Reports Tree

Reports Riser Toolbar

The toolbar above the reports tree contains an Action menu with the following options.


Reports Riser Toolbar - Action Menu

Open - Opens the selected report in the reports tree.

Refresh - Refreshes the reports tree.

Delete - Deletes HTML files created by reports that you have run.

Running Reports

To run a report, double-click its node in the reports tree (or right-click the node and select

Open from the context menu). Depending on the report, you may be prompted to enter

additional input parameters in the Enter Report Parameters dialog. Note that the

parameters for a report will vary based on the report, and may differ from the example

shown here.

Enter Report Parameters Dialog

Batch reports prompt for a time-out value. The default time-out value is 300 seconds.

Specifying a time-out value of 0 seconds indicates that the job will not time out.

When a batch report starts, it displays a notification that the report process has started.


Batch Report Started Notification

Batch reports provide a notification when the report has completed.

Batch Report Complete Notification

After a batch report has completed, its output appears in the reports tree. To open the

report output on a separate tab, double-click its node in the tree (or right-click the node and

select Open from the context menu).

Viewing Report Results

Dynamic report results appear on tabs in the information pane. The results for each report

appear on a separate tab.


Report Results

Some reports may also generate HTML output. In such cases, a link to the HTML file

appears below the report name. The link indicates the date and time when the report was

generated. To open the HTML file in another window, double-click the report (or right-click

the report and select Open from the context menu).

To delete an HTML file generated by a report, select its node in the reports tree and select

Actions > Delete from the reports riser toolbar (or right-click the node and select Delete

from the context menu).

Report Results Toolbar

The toolbar at the top of a report results tab contains an Action menu with the following

options.

Report Results Toolbar - Action Menu

Run Report - Displays the Enter Report Parameters dialog, from which you can

change the report parameters and rerun the report.

Open - Enabled only if the report includes the field MDM_ENTITY_CLUSTER_ID.

Selecting the Open option opens a selected entity record in an Entity Editor with the

Properties tab displayed. From the Properties tab, you can view and modify an


entity's attribute values and relationships with other entities. For more information,

see Working with Entity Properties. You can also right-click a report row and select

Open (or Open as) from the context menu.

Open as - Displays a secondary menu with the following options:

o Open Contributors - Opens a selected entity record in an Entity Editor with the

Cluster Members tab displayed. From the Cluster Members tab, you can

view and modify cluster information for the entity. For more information, see

Working with Clusters.

o Open Hierarchies - Opens a selected entity record in an Entity Editor with the

Hierarchies tab displayed. From the Hierarchies tab, you can view and modify

hierarchies associated with the entity. For more information, see Working with

Hierarchies.

o Open Relationship Diagram - Opens a selected entity record in an Entity

Editor with the Relationship Diagram tab displayed. From the Relationship

Diagram tab, you can explore entity relationships graphically. For more

information, see Exploring Entity Relationships.

o Open History - Opens the entity record in an Entity Editor with the History tab

displayed. From the History tab, you can review changes to the entity over

time.

Tag Entity - Tags a selected entity record from the report results to be added to a

workflow. For more information, see Tagging Entities. You can also right-click a report

row and select Tag Entity from the context menu.

Print - Prints the report results.

Export - Displays a secondary menu with options for exporting the report results in

CSV, PDF, or Excel format.


The Master Data Dashboard report displays various metrics about the qMDM hub.

Notes:

1. The Master Data Dashboard report is available only to users who have an

administrative role.

2. The data in the Master Data Dashboard report is generated by a batch job,

which the qMDM administrator should run at regular intervals.



The Master Data Dashboard report displays the following metrics:

Record counts of active and retired contributor and survivor records

Minimum, maximum, and average cluster sizes by entity types

Changes in qMDM hub contents over time

Contributors to an entity type by source system


Batch load history, including the number of records and clusters that were added as part of the batch load process

Drill-Through Reports

From the tables in the Entity Snapshot and Data Source Snapshot sections of the Master

Data Dashboard report, you can access drill-through data quality reports by right-clicking

the desired table rows and selecting Open from the context menu. The drill-through reports

include the following information, and will appear in separate browser windows or tabs:

Counts of null and non-null attributes for each user-defined attribute

Minimum and maximum values for each attribute


The Workflows Dashboard report displays the following metrics about the workflows in the

qMDM hub:

Note: The Workflows Dashboard report is available only to users who have

an administrative role.

By Status (Active, Cancelled, or Completed)

By Priority (High, Medium, or Low)

By Entity Type and Submitter (the stacked bars show the breakdown by priority)

By age and Entity Type (not shown)

By last modification and Entity Type (not shown)


Workflows Riser The Workflows riser provides an overview of work in progress in the qMDM hub. From the

Workflows riser, you can review and complete tasks that have been assigned to you, or

monitor the progress of tasks that you have submitted.

Workflows Riser

Workflows Riser Overview

Assigned Workflow Editor

Submitted Workflow Editor

Workflows Riser Overview

Workflow Types

qMDM supports two types of workflows:

Operational workflows are those that do not result in changes to data. An example

is the Tag option provided in Entity Editors. The Tag option is used to draw attention

to a record, but it does so without changing the data.

Lifecycle workflows always result in changes to data. When workflows have been

configured for create or update operations, the creation or modification of a record will


generate a workflow that must be completed before the record is introduced into the qMDM hub.

An entity can exist in more than one workflow. As the workflows complete, the entity record

is clustered and a new survivor is created for it, in the order in which the workflows

complete. The entities in lifecycle workflows are available only through the Workflows

riser. Master data searches will not return records that are in the process of being updated,

although the original entity record will still be available.

Workflows Tree

On the Workflows riser, assigned and submitted workflows appear in a navigation tree.

Workflows Tree

Workflow Tables

When you open the Assigned Workflows or Submitted Workflows node from the definitions

tree, the corresponding Assigned Workflows or Submitted Workflows table is displayed on a

tab in the information pane. Each workflow table appears on a separate tab.

Assigned Workflows - Tasks can be assigned to you as an individual, or can appear

in the Assigned Workflows table because you have a role that is capable of performing

the task.

Submitted Workflows - Tasks that you have generated appear in the Submitted Workflows table so that you can monitor their progress.

Assigned Workflows Table


A task can appear in both the Assigned Workflows and Submitted Workflows tables if you

are the task originator and have been assigned the task, or if you have a role that is

capable of completing the task. Although the task appears in both tables, you can only

change the status of the task if you open it from the Assigned Workflows table.

Double-click a task in the Assigned Workflows table to open it in the Assigned Workflow

Editor. Double-click a task in the Submitted Workflows table to open it in the Submitted

Workflow Editor.

Workflow Table Toolbar

The toolbar at the top of an Assigned Workflows table contains an Action menu with the

following options.

Assigned Workflows Table Toolbar - Action Menu

Open - Opens a task from the workflow table.

Print - Prints the workflow table.

Refresh - Refreshes the workflow table.

In the Submitted Workflows table, the Action menu on the toolbar includes the following

additional options.

Submitted Workflows Table Toolbar - Action Menu

Cancel - Cancels a workflow.

Delete - Deletes a workflow that has been either completed or canceled. Selecting

this option deletes the information about the workflow itself, but does not modify any entity data.

For both the Assigned Workflows and Submitted Workflows tables, the following options

appear on the right side of the toolbar, and control the operation of the workflow filter.

Workflow Table Toolbar - Filter Options

Filter text - Filters the workflow table entries to those whose Title and Entity fields

contain the entered text. The filtering is case insensitive.

Apply - Applies the specified filter to the workflow table.

Reset - Resets the filter.

Show/Hide Filter - Shows or hides the workflow filter panel.


Workflow Filter

The workflow filter can be used to restrict the set of workflows that appear in the Assigned

Workflows and Submitted Workflows tables.

Assigned Workflows Table with Filter

Each category supported by the filter includes an All check box, which is automatically

selected when all the entries are deselected.

The numbers to the right of a value indicate how many workflows have that value. The blue

bar provides an at-a-glance perspective of the proportion of elements within the category.

Each category is scaled against its own values, so there will always be at least one bar in

each category that is displayed at full width, even if the numbers in each category are

different.

If one or more values are selected within a category, the filter will show the counts for

workflows for the other (unselected) values within that category. You can use these counts

to determine how many additional workflows would appear in the list if you applied those

filter values.

When you modify the filter by selecting a check box, the other categories will appear

shaded, to indicate that the number of workflows represented by that category may no

longer be correct with respect to the new filter criteria. After the filter is applied, the counts

will be updated.

You can also use the text entry field at the top of the filter to restrict the set of workflows

that appear in the list. Any workflows that have the filter text as a part of either their title or

their entity name will appear in the list. (Note that the results of this filtering will also be

affected by other workflow filter settings.) The text comparison is case insensitive. Wildcard

characters are not supported.



Double-click a task in the Assigned Workflows table to open it in the Assigned Workflow

Editor. From the Assigned Workflow Editor, you can view more details about the task, view

and modify the entity behind the task, and update the task's status.

You can also optionally update any available properties when you update the task's status.

For example, you can update the Notes field with any commentary needed to complete the

task.



The Assigned Workflow Editor contains general information about the task and its current

state along with information about the entity associated with the workflow.

The information displayed in the Status section of the Assigned Workflow Editor includes

the following:

The workflow name, submitter's ID, and submission date

The current pending step of the workflow and the user or role assigned to perform

that step

Any properties associated with the workflow

The information displayed in the MDM Identifiers and Personal Information sections

depends on the type of entity associated with the workflows: the same metadata rules used

to build Entity Editors on the Master Data riser are used here.

You must select an action from the Actions list before you can interact with any other part

of the Assigned Workflow Editor. After you have selected an action, you can edit the

properties of the workflow and/or the attributes of the associated entity.

Assigned Workflow Editor Toolbar

The toolbar at the top of an Assigned Workflow Editor contains the following options.

Assigned Workflow Editor Toolbar

Save - Saves changes to the task and any changes made to the associated entity.

When you update the state of the workflow by performing an action, it is possible that

the task will no longer be your responsibility. If this occurs, the following message

appears, and the Assigned Workflow Editor closes automatically.

Workflow Action Saved Message

Reset - Discards changes to the task and the associated entity, and resets the

Assigned Workflow Editor to its original state.

Show Original/Show Current - Toggles the entity displayed in the Assigned

Workflow Editor between the original record submitted with the workflow and the most recently updated record.



Double-click a task in the Submitted Workflows table to open it in the Submitted Workflow

Editor. From the Submitted Workflow Editor, you can view the task's current status, the

user to whom the task is assigned, and the entity behind the task.

When a workflow completes, the completion date is automatically filled in by qMDM.



Submitted Workflow Editor Toolbar

The toolbar at the top of a Submitted Workflow Editor contains the following options.

Submitted Workflow Editor Toolbar

Cancel - Cancels the workflow, and discards any changes that have been made to the

entity.

Delete - Deletes completed workflows from qMDM.

Show Original/Show Current - Toggles the entity displayed in the Submitted

Workflow Editor between the original record submitted with the workflow and the most recently updated record.


Master Data Riser The Master Data riser enables business users and data stewards to search for, edit, create,

and retire master data items that have been brought into qMDM. A user's role determines

the user's level of access to entities and their attributes.

Master Data Riser

Master Data Riser Overview

Searching for Master Data Records

Working with Search Results

Entity Editors

Working with Entity Properties

Working with Clusters

Working with Hierarchies

Working with Entity Relationships

Tagging Entities

Retiring Entities


Master Data Riser Overview

Entity Search Panel

From the Entity Search panel on the left side of the Master Data riser, you can search for

master data entities and hierarchies. For more information, see Searching for Master Data

Records.

Entity Search Panel

New Button

Clicking the New button above the Entity Search panel displays the Create Entity

dialog, from which you can create a new master data entity record.

Create Entity Dialog


Tabs and Split Panes

Search results and editors appear on tabs on the right side of the Master Data riser. The

tabs make it possible to have many activities in progress simultaneously.

The right side of the Master Data riser is divided into left, right, and bottom split panes

that enable you to rearrange your open tabs as needed. By default, the left split pane is

active, and the right and bottom split panes are hidden. You can resize the split panes by

clicking and dragging their vertical and horizontal pane split bars.

Tabs and Split Panes

To move an existing, open tab to a different split pane, right-click the tab. The tab context

menu provides options to move the tab to the other split panes. For example, if the tab that

you want to move is currently open in the left split pane, the tab context menu shows Move

Right and Move Down options.

Note: The Move options on the tab context menu appear only on the

Master Data riser.


Searching for Master Data Records

Searching is a key component of the Master Data riser. From the Entity Search panel on

the left side of the riser, you can specify the desired search criteria. Click Search to locate

records that match the specified criteria. The search results will appear on a tab in the

information pane. You can refine your search by altering the search criteria—the results will

appear on the same search results tab. To keep your current search results and generate a

new tab, click Clear. This will reset your search criteria, and subsequent searches will

appear on a new tab. Changing the Search Type, the Entity Type, or the Hierarchy Type

always clears the search criteria, and will generate a new search results tab when the

search is run.

For information on actions that you can perform on search results, see Working with Search

Results.

Note: By default, SQL Server searching is case insensitive. If you need to enable case-

sensitive search capabilities, ensure that your database is initialized accordingly. For more

details, see your database documentation.

Search Types

You can search the qMDM hub for both entities and hierarchies, based on criteria that you

provide.

qMDM provides Basic, Advanced, and Hierarchy search types. Select the desired search type

from the Search Type menu at the top of the Entity Search panel.

Search Type Menu

Basic and Advanced Entity Searches

In a Basic entity search, the search form in the Entity Search panel is constructed from the

entity type's metadata. Only attributes that have been configured to appear by an

administrator are shown on the form. The attributes are configurable on the Definitions

riser.


Entity Search Panel - Basic Entity Search

Some users have access to Advanced entity searches, in which database queries can be

designed. These queries can contain database-specific functions for complex match criteria.

The SQL is submitted to the database as written, and may result in long-running queries, as

well as updates or deletions of data within the qMDM hub.

Entity Search Panel - Advanced Entity Search


Both Basic and Advanced searches locate clusters that match the specified criteria, although

the matches may occur in a contributor record and not in the survivor record.

Hierarchy Searches

In a Hierarchy search, qMDM searches for hierarchies based on their name, description, or

hierarchy type.

Entity Search Panel - Hierarchy Search

Search Criteria

You can enter the following search criteria in the Entity Search panel.

Entity Types

The Entity Type menu presents the available entity types. This menu shows active (non-

retired) entity types that have been published for use.

To appear in the Entity Type menu, an entity type must be published and active, must

have a sort order that is greater than zero, and must have a label attribute defined in its

metadata. Additionally, if the entity type has been modeled as an abstract entity type, it

must have at least one concrete, derived entity type that meets these criteria.

Entity Type Menu


Search By

The Search By menu applies only for Basic entity searches. The Search By menu contains

the following options.

Search By Menu

DataFlux Match - Uses match codes during searches and enables fuzzy matching

capabilities. If match codes are not available for the fields, qMDM attempts to use

standardized fields. If match codes or standardized fields are not available, qMDM

searches for an exact match.

Similar Match - Uses database-specific, approximate match functions. For Oracle and

SQL Server, the soundex() function is used in combination with an exact match. This

is because soundex() does not support some values, such as numbers and dates.

Case Insensitive - Disregards the search term case.

Exact Match - Searches for the input string exactly as it was entered.

Note: The Search By menu is not available for Advanced entity searches. If needed,

write your advanced query using the soundex() and upper() database functions for

Similar Match and Case Insensitive search modes. There are no database functions that

are equivalent to the DataFlux Match search mode. However, you can use wildcard

characters and comparison operators such as LIKE instead.

Show Retired

Select or clear the Show Retired check box. If this option is selected, retired entities are

included in the search results—the search displays both active and retired survivor records.

If this option is not selected, retired entities are not included in the search results.

SQL Where Field and Attribute Browser

For Advanced entity searches, the Entity Search panel displays an SQL Where field in

which you can manually enter SQL statements.


SQL Where Field and Attribute Browser

Both WHERE and AND are implied in the SQL statements, and a ? character is added to each

statement automatically. Replace the ? character with the value for which you want to

search.

You can double-click one or more attribute names from the Attribute Browser list to add

them to an SQL statement. The attributes that appear in this list are the same attributes

that appear for Basic entity searches. They are configurable on the Definitions riser.

Note: Entering SQL DELETE, UPDATE, and INSERT statements is not

supported. Incorrect or inadequately written queries may cause the system to

become unresponsive. Query failures will produce an error message.

A sample query in the SQL Where field might look as follows:

FULL_NAME = '?' AND ADDRESS1 = '?'

An example querying all COMPANY entities with names beginning with the letter B might

look as follows:

NAME LIKE 'B%'

An example querying all COMPANY entities with contributor records from source system ID

= 3 might look as follows:

MDM_SRC_SYS_ID = 3

Hierarchy Search Options

For Hierarchy searches, the following search options are available:

Name - Hierarchy name.

Description - Hierarchy description.

Hierarchy Type - Drop-down menu containing hierarchy type options. Only active

hierarchy types appear in the Hierarchy Type menu. After a hierarchy type is retired,

it will not appear in the menu.


Hierarchy Type Menu

Search Results Tree

Search results are displayed in navigation trees below the Entity Search panel.

Entity Search Results Tree

Hierarchy Search Results Tree

Working with Search Results

Successful master data searches return one or more records, which are displayed on tabs in

the information pane.

For Basic and Advanced entity searches, only survivor records are displayed. You can

display contributor records by opening the survivor record in an Entity Editor and selecting

the Cluster Members tab. If the Show Retired option was enabled in the search criteria,

any retired records are also displayed. Retired records are displayed as dimmed in the

search results table, to help you distinguish active and retired entities.


Entity Search Results with Retired Records

Hierarchy Search Results

Search Results Toolbar

The toolbar at the top of a search results table contains an Action menu with the

following options.

Search Results Toolbar - Action Menu

Open - Opens a record from the search results table.

o In entity search results tables, selecting this option opens a selected entity

record in an Entity Editor with the Properties tab displayed. From the

Properties tab, you can view and modify an entity's attribute values and

relationships with other entities. For more information, see Working with Entity

Properties.

o In hierarchy search results tables, selecting this option opens a selected

hierarchy in a Hierarchy Editor.


Open as - Available only in entity search results tables. Displays a secondary menu

with the following options:

o Open Contributors - Opens a selected entity record in an Entity Editor with the




o Open Hierarchies - Opens a selected entity record in an Entity Editor with the



Hierarchies.

o Open Relationship Diagram - Opens a selected entity record in an Entity

Editor with the Relationship Diagram tab displayed. From the Relationship

Diagram tab, you can explore entity relationships graphically. For more



displayed. From the History tab, you can review changes to the entity over time.

Tag - Available only in entity search results tables. Tags a record from the search

results table to be added to a workflow. For more information, see Tagging Entities.

Retire - Retires the selected entities. For more information see Retiring Entities.

Print - Prints the search results table.

Export - Displays a secondary menu with options for exporting the search results table in CSV, PDF, or Excel format.

Entity Editors

Entity Editors are used to view, modify, tag, and retire entity records. You can open an

entity record in an Entity Editor by selecting either the Open or Open as option from any of

the following locations:

Report results

Entity search results

Hierarchy Editors

Other Entity Editors

Each entity record appears in its own Entity Editor. If you attempt to open an entity record

again, the same editor will be used.


Entity Editor

Entity Editor Tabs

An Entity Editor contains the following four tabs:

Properties - Enables you to view and modify an entity's attribute values and


Properties.

Cluster Members - Enables you to view and modify cluster information for an entity.

The cluster information includes the record displayed on the Properties tab, as well

as active and retired contributor and survivor records. For more information, see


Hierarchies - Enables you to view and modify hierarchies associated with an entity.

For more information, see Working with Hierarchies.


Relationship Diagram - Enables you to explore an entity's relationships with other

entities graphically. For more information, see Exploring Entity Relationships.

History - the History tab allows you to review changes to the entity over time. For more information, see Working with Entity History.

Entity Editor Toolbar

The toolbar at the top of an Entity Editor contains an Action menu with the following

options.

Entity Editor Toolbar - Action Menu

Save - Saves the entity record, and creates a new contributor record and survivor

record. The previous records are preserved for historical audit purposes.

If you have loaded a contributor record into the Entity Editor and made changes, that

record must be saved before you can make other changes to other contributor

records.

Note that survivorship rules defined by the data stewards may result in survivor

records that do not contain your modifications. However, the contributor record will be

maintained as you entered it.

Note: If the Save option is disabled, this indicates that the entity definition has an

issue that will prevent it from being successfully deployed. Most commonly, there are

one or more duplicated attributes; the duplication may be an inherited attribute.

Examine the attributes, cluster conditions, and relationship types for warnings and

errors, and correct any problems to continue.

Reset - Discards changes and resets the Entity Editor to its original state.

Retire - Retires the cluster if a survivor record or the last contributor record in a

cluster is loaded into the Entity Editor. For more information, see Retiring Entities.

Tag - Tags the entity record to be added to a workflow. For more information, see

Tagging Entities.

Print - Prints the entity record.

Working with Entity Properties

From the Properties tab of an Entity Editor, you can view and modify the properties of an

entity, including both fields and relationships with other entities. The Properties tab is

displayed by default when you open an entity record in an Entity Editor.


Note: You can also use an Entity Editor's Relationship Diagram tab to

explore an entity's relationships with other entities graphically. For more


Entity Editor - Properties Tab

The fields and relationships that appear on the Properties tab are configured by a data

steward in the metadata for an entity. For more information on controlling the display of

information in Entity Editors, see Entity Type Definitions.


Note: When specifying URLs in an Entity Editor, you must include the

protocol portion of the URL for the linking capability to function properly. For

example, use 'http://www.dataflux.com' instead of 'www.dataflux.com'. To

browse to a URL from an Entity Editor, click the Open URL Link button.

Relationship Tables

The relationship tables at the bottom of the Properties tab show an entity's relationships

with other entities. You can use the New Relationship and Retire Relationship options

from a relationship table to create new entity relationships or to retire existing relationships.

Relationship Table Toolbar

The toolbar at the top of a relationship table contains an Action menu with the following

options.

Relationship Table Toolbar - Action Menu

New Relationship - Displays the New Relationship dialog. In this dialog, you can

search for and select additional entities for which you want to create new

relationships. For more information, see Creating Entity Relationships.

Open - Opens the selected entity relationship from the relationship table in an Entity

Editor.

Retire Relationship - Displays the Retire dialog. From this dialog, you can retire the

selected entity relationship. For more information, see Retiring Entity Relationships.

Tag - Tags the selected entity record to be added to a workflow. For more

information, see Tagging Entities.

Refresh - Refreshes the relationship table.

Print - Prints the relationship table.

Export - Displays a secondary menu with options for exporting the relationship table

in CSV, PDF, or Excel format.

Working with Clusters

The following topics are covered in this section:

Cluster Table

Comparing Records


Moving Contributor Records

Cluster Table

By default, the Properties tab is displayed when you open an entity record in an Entity

Editor. To work with entity clusters, select the Cluster Members tab. The Cluster

Members tab displays a cluster table that shows both contributor and survivor records.

Note: If desired, you can include retired contributor records in the cluster

table by using the Show Retired option on the cluster table toolbar.

Entity Editor - Cluster Members Tab

The New Record section of the cluster table shows the record that will be saved by the

Save option. The data in this section is synchronized with the data shown in the Entity

Editor until you make a change. After a change is made, you can view but not modify other

records in the cluster using the Entity Editor until you either save or reset the changes. The

record that you originally modified will continue to be displayed in the New Record section

until the changes are saved or reset, even if you load another record into the Entity Editor.

Cluster Table Context Menu

To load the selected record into the Entity Editor, double-click the row in the New Record

section, or right-click the row and select Open from the context menu.

To modify the new record using information from a cluster member or survivor, select the

desired record, right-click the cell with the desired information, and select Update Current

from the context menu. You can modify the new record in this manner even if the

Properties tab is displaying a different contributor or survivor record. This option does not

appear on the context menu for cells containing read-only properties.

Cluster Table Toolbar

The toolbar at the top of a cluster table contains an Actions menu with the following

options.


Cluster Table Toolbar - Action Menu

Open - Loads an entity (contributor or survivor record) from the cluster table into an

Entity Editor.

Tag - Tags an entity for addition to a workflow. For more information, see Tagging

Entities.

Retire - Retires the entity from the hub.

Compare - Compares the selected record with the other members of the cluster. You

can also right-click a record and select Compare from the context menu. For more

information, see Comparing Records.

Move to New Cluster - Moves one or more selected contributor records into a newly

created cluster. For more information, see Moving Contributor Records.

Revert Move - Reclusters selected contributor records that have been previously

moved to another cluster. For more information, see Reverting Moved Records.

Show/Hide Retired - Toggles the cluster table to either include or exclude retired

entities. If included, retired contributor and survivor records appear dimmed in the

table.

Refresh - Refreshes the cluster table.

Print - Prints the cluster table.

Export - Displays a secondary menu with options for exporting the cluster table in


Comparing Records

It is sometimes easier to look at a pair of records side-by-side to see the differences

between them. You can use the Compare option on the cluster table toolbar to compare

the selected record with the other members of the cluster.

The Compare dialog compares the selected record against the record that appears in the

New Record section of the cluster table. This will usually be the current survivor record for

the cluster, but could be any record that has been loaded into the Entity Editor. The New

Record appears on the right, and the selected record appears on the left. Note that if the


selected record and the New Record are the same, a different record from the cluster will be

selected.

Compare Dialog

The differences between the records are highlighted, and you can use the context menu or

update the New Record with the field value from the selected record if the values are

different, and if the attribute has not been marked as read-only.

When a field has been updated, the attribute name is shown in bold text, and the context

menu changes to provide a Clear option, which reverts the field to its original value, or (if

the value in the record on the right is different) provides an Update Current option to

replace the value.

If you only want to see the differences between the two records, selecting the Show

differences only check box at the bottom of the dialog will show only fields whose values

are different.

Compare Dialog Toolbar

The toolbar at the top of the Compare dialog contains the following options. You can use

these options to perform actions on the records on the right side of the dialog.

Compare Dialog Toolbar

Tag - Tags the entity to be added to a workflow. For more information, see Tagging

Entities.

Move to New Cluster - Moves one or more selected contributor records into a newly

created cluster. For more information, see Moving Contributor Records.


Retire - Retires the cluster if a survivor record or the last contributor record in a cluster is loaded into the Entity Editor. For more information, see Retiring Entities.

Use the Previous and Next arrow buttons on the right side of the toolbar to scroll

through the cluster's records one at a time. When you select a new record for the right side

of the dialog, the display changes to highlight differences between the New Record and the

Current record.

When you are finished comparing and/or updating the New Record, click the OK button at

the bottom of the Compare dialog to apply your changes to the New Record, or click the

Cancel button to discard your changes. Note that after you click OK, the New Record is

updated, but has not yet been saved. You must use the Entity Editor's Save option to apply

your changes to the hub.

Moving Contributor Records

In some cases, the cluster conditions that have been configured for the entity might not

work as intended. Records can be overmatched, resulting in clusters that are too large, as

records that do not belong to the entity are incorrectly associated. Records can also be

undermatched, resulting in too many clusters for what should be the same entity. When this

happens, you can use the Master Data Manager to adjust the clusters manually.

In the case of overmatched records, you may need to move one or more contributor records

to a new cluster. In the case of undermatched records, you may need to move one or more

contributor records to an existing cluster.

Moving a record indicates that the cluster conditions are not processing the record as

intended, so updates to the record are processed differently. In particular, an update to a

moved record (based on its source system ID and source system record ID) will never cause

clusters to merge together, even if the update matches multiple clusters. If qMDM allowed

the merge, the move operation would be undone.

Similarly, if an incoming record matches both the original and target clusters (but does not

match based on source system ID and source system record ID), the incoming record will

be placed in the original cluster. By default, qMDM prefers clusters that do not have moved

records over clusters that have moved records.

Notes:

Only entities of the same entity type definition can be moved to an existing cluster.

For example, you cannot move a COMPANY contributor record to an existing PART

cluster.

Survivor records are always generated as part of the qMDM hub's operation and

cannot be moved.

Retired entities (contributor and survivor records) cannot be moved to either a new

cluster or an existing cluster.

Records cannot be moved into retired clusters.

If you move the last contributor record out of a cluster, the entire cluster will be retired.


Moving Contributor Records to a New Cluster

To move one or more contributor records to a new cluster, complete the following steps:

1. From the cluster table on the Cluster Members tab, select the record or records that

you want to move.

2. From the cluster table toolbar, select Actions > Move to New Cluster. A

confirmation dialog similar to the following appears. If desired, edit the default

comment text. For example, you may want to add text to describe why the records

are being moved. Click OK to perform the move operation.

3. After the move completes, a new Entity Editor will open for the moved record. On the

Cluster Members tab of the new Entity Editor, you will see the moved record along

with a note icon. You can hover the mouse over the note icon to view the comment

text that was entered in the previous step.


4. The move operation generates new survivor records for the clusters involved in the

move. You can confirm that the record was moved out of the cluster, and that a new

survivor was created for the cluster, by selecting the Show Retired toolbar option for

the original cluster. Retired records appear dimmed in the cluster table.

Moving Contributor Records to an Existing Cluster

To move one or more contributor records to an existing cluster, complete the following

steps. Note that the Entity Editor Cluster Members tabs for both the source and the target

of the move operation must be visible.

1. Use the tab context menus to display the source and target Entity Editors in separate

split panes.

2. Select the Cluster Members tab in both Entity Editors.

3. From the source cluster table, select the contributor record or records that you want

to move. Drag and drop the record or records to the target cluster table. Release the

mouse button when the icon appears.


4. A confirmation dialog similar to the following appears. If desired, edit the default

comment text. For example, you may want to add text to describe why the record or

records are being moved. Click OK to perform the move operation.

5. When the action completes, the cluster tables in both Entity Editors will be refreshed,

showing the result of the move. Note icons appear over both the source and target

records. You can hover the mouse over the note icons to view the text that was

entered in the previous step.


Reverting Moved Records

You can use the Revert Move option on the cluster table toolbar to recluster a record that

was previously moved. Reverting a move operation causes the record to recluster against

the hub data using the defined cluster conditions. The Revert Move option is enabled only

when a previously moved record is selected.

Note the following about reverting a moved record:

If a retired record is being reverted, the retired record is not reclustered, but qMDM

"forgets" that it has been moved. This prevents the move operation from affecting

records with the same source system ID/record ID that may be loaded into the hub in

the future.

If the record being reverted is the last contributor in the cluster, the entire cluster is

retired.

When you select the Revert Move option, you are prompted to confirm the operation. If

desired, you can edit the default comment text to describe why the records are being

reprocessed.

Revert Move Confirmation Dialog

After the operation completes, if the Entity Editor for the cluster in which the reverted

record is placed is already open, it is made active. Otherwise, a new Entity Editor is opened.

The reverted record appears in the cluster table on the Cluster Members tab, along with a

note icon. You can hover the mouse over the note icon to view the message entered when

the record was reverted.

Working with Hierarchies


Editor. To create and modify hierarchies for the entity, select the Hierarchies tab.

Hierarchies are used to capture relationships between entities. For example, you can build

hierarchies between a household and the people that constitute that household, or between

a company and its suppliers. Hierarchies express relationships through simple parent-child

relationships between entities.

Hierarchies have names and descriptions, which helps to distinguish one hierarchy from

another.


Hierarchies also have an associated hierarchy type, which restrict the kinds of entities that

can appear in hierarchies of that type. For example, you would not want to have a Vehicle

entity in an Organization-to-Employee hierarchy.

Creating and Viewing Hierarchies

Hierarchies are created from the Hierarchies tab in an Entity Editor. When you create a

new hierarchy, the entity that appears in the Entity Editor is assigned as the root (or top-

level) node in the hierarchy. You can also open existing hierarchies from the Hierarchies

tab, or through hierarchy search results. After a hierarchy is opened, you can add entities to

or remove entities from the hierarchy.

Each hierarchy appears in its own editor. If you attempt to reopen a hierarchy, the same

editor will be used.

Entity Editor - Hierarchies Tab

Hierarchy Table Toolbar

The toolbar at the top of a hierarchy table contains an Action menu with the following

options.

Hierarchy Table Toolbar - Action Menu

New Hierarchy - Displays a Create New Hierarchy dialog, from which you can

create a new hierarchy.


Create New Hierarchy Dialog

Edit - Displays an Edit Hierarchy dialog, from which you can edit an existing

hierarchy.

Edit Hierarchy Dialog

Open - Opens a selected hierarchy table entry in a Hierarchy Editor. You can also

right-click a hierarchy table entry and select Open from the context menu.

Retire - Retires the hierarchy.

Refresh - Refreshes the hierarchy table.

Print - Prints the hierarchy table.

Export - Export the data in CVS, PDF or Excel format.

Editing Hierarchies

Once you have created a hierarchy, you can drag and drop entities from the entity search

results to an open Hierarchy Editor. You can also drag and drop contributors and surviving

records to the Hierarchy Editor.


Hierarchy Editor

In order for the drag and drop to work correctly, you must have two split panes available

and visible: one split pane containing your source entities or source search results, and

another split pane containing your target Hierarchy Editor. You must drag and drop on an

entity node for the drop to complete.

Notes:

Entities that are not defined in a hierarchy type for a given Hierarchy Editor cannot be

dragged and dropped onto the Hierarchy Editor.

An entity can exist in more than one generation or branch in a hierarchy.

You can select a single entity from the entity search results, or use the Ctrl + Shift and

Alt + Shift multi-select methods to select more than one entity.

Hierarchy Editor Toolbar

The toolbar at the top of a Hierarchy Editor contains an Action menu with the following

options.

Hierarchy Editor Toolbar - Action Menu

Save - Saves the hierarchy.

Reset - Discards changes and resets the Hierarchy Editor to its original state.

Open - Opens the entity record in an Entity Editor with the Properties tab displayed.

From the Properties tab, you can view and modify the entity's attribute values and


Properties.



o Open Contributors - Opens the entity record in an Entity Editor with the




o Open Hierarchies - Opens the entity record in an Entity Editor with the



Hierarchies.

o Open Relationship Diagram - Opens the entity record in an Entity Editor with

the Relationship Diagram tab displayed. From the Relationship Diagram

tab, you can explore entity relationships graphically. For more information, see

Exploring Entity Relationships.


displayed. From the History tab, you can review changes to the entity over

time.

Retire - Retires the entity from the hierarchy. All the entity's descendants will also be

retired.

Retire Entity - Retires the entity, but not the relationship. For more information, see Retiring Entities.

The Open, Open as, Tag, and Retire options are also available from a context menu,

which you can access by right-clicking a node in the Hierarchy Editor tree.

Working with Entity Relationships

Creating Entity Relationships

Exploring Entity Relationships

Retiring Entity Relationships

Creating Entity Relationships

You can create entity relationships from the following locations:

The entity graph on an Entity Editor's Relationship Diagram tab

A relationship table on an Entity Editor's Properties tab

The details panel table in the group view of an Entity Editor's Relationship Diagram tab

To create an entity relationship from an entity graph, select the desired entity node on the

graph, and select Actions > New Relationship to display the New Relationship dialog.

You can also right-click the entity node and select New Relationship from the context

menu.

In the New Relationship dialog, you can search for and select entities with which you want

to create relationships. From the Relationship Type drop-down list, select the relationship

type that you want to create. Based on the selected relationship type, the attribute drop-

down list will present the attributes that you can use to search for additional entities. Select


an attribute from the list, and use the adjacent text entry field to enter or select a search

value. Click Search to perform the search.

From the search results, select one or more entity records. Click OK to create the entity

relationship or relationships. The new entity relationships are shown on the entity graph.

New Relationship Dialog - Creating an Entity Relationship from an Entity Graph

To create an entity relationship from a table, select the New Relationship toolbar option to

display the New Relationship dialog. In the New Relationship dialog, you can search for

and select entities with which you want to create relationships. Select an attribute from the

attribute drop-down list, and use the adjacent text entry field to enter or select a search

value. Click Search to perform the search.


From the search results, select one or more entity records. Click OK to create the entity

relationship or relationships. The new entity relationships are inserted at the top of the

current page of the table (regardless of the current table sort order).

Note: When creating a relationship from a table, the New Relationship

dialog will not include the Relationship Type drop-down list because the

system can internally derive the type of relationship to create.

New Relationship Dialog - Creating an Entity Relationship from a Table

Exploring Entity Relationships


Editor. To explore the entity's relationships with other entities graphically, select the

Relationship Diagram tab.


Entity Editor - Relationship Diagram Tab

Relationship Diagram Panels

Relationship Diagram Toolbar

Relationship Diagram Group View

Relationship Diagram Panels

The Relationship Diagram tab contains the following three panels.

Entity Graph Panel

The entity graph (top left) panel portrays the relationships between entities as a directed

graph. Relationships between entities are indicated by arrows between the entity nodes.

You can expand the graph by selecting an entity node and either double-clicking the node or

selecting the Show Related option on the toolbar or filter panel. The set of relationship

types that is expanded is controlled by the filter panel selections (see below). You can also

right-click an entity node on the graph and select Show Related from the context menu.


Retired entities are not shown on the entity graph. The Relationship Diagram tab for a

retired entity record shows a 'Not available for retired records' message, and none of the

panels are available.

You can left-click and drag nodes to rearrange them on the entity graph. However, when

the Relationship Diagram tab is hidden, the entity graph is reset. The next time the tab is

shown, the nodes will be placed in their system-computed positions, rather than where they

were dragged.

To pan the entity graph, press Shift while left-clicking and dragging the graph.

To rotate the entity graph, press Ctrl while left-clicking and dragging the graph.

Filter Panel

The filter (top right) panel controls the relationship types that are shown when you expand

an object on the entity graph. You can expand or collapse the filter panel by clicking the

Show Filter and Hide Filter buttons. The filter panel is shown by default.

If you select a relationship (arrow) between two entity nodes on the entity graph, the filter

panel displays the relationship types that exist between the two entities.

Relationship Types in Filter Panel

If you select multiple entity nodes on the entity graph, the filter panel displays a 'Multiple

records selected' message.


Details Panel

The details (bottom) panel shows additional details for the selected object on the entity

graph.

If you select a single entity node on the entity graph, the details panel contains a table that

lists the attributes of the entity.

Entity Attributes in Details Panel

If you select multiple entity nodes on the entity graph, the details panel shows a 'Multiple

records selected' message.

Relationship Diagram Toolbar

The toolbar at the top of the Relationship Diagram tab contains an Action menu with

the following options.


Relationship Diagram Toolbar - Action Menu

Show Related - Expands the entity graph for the selected node based on the

relationship types that are selected in the filter panel.

Open Entity - Opens the selected entity record in an Entity Editor with the

Properties tab displayed. From the Properties tab, you can view and modify an

entity's attribute values and relationships with other entities. For more information,

see Working with Entity Properties.


o Open Contributors - Opens the selected entity record in an Entity Editor with

the Cluster Members tab displayed. From the Cluster Members tab, you can

view and modify cluster information for an entity. For more information, see


o Open Hierarchies - Opens the selected entity record in an Entity Editor with

the Hierarchies tab displayed. From the Hierarchies tab, you can view and

modify hierarchies associated with the record. For more information, see

Working with Hierarchies.

o Open Relationship Diagram - Opens the selected entity record in an Entity

Editor with the Relationship Diagram tab displayed.

o Open History - Opens history for the selected entity on the diagram. From the

History tab, you can review changes to the entity over time.

Remove From Diagram - Removes the selected node (and all nodes that are only

reachable through it) from the entity graph.




Tag - Tags the selected entity record to be added to a workflow. For more

information, see Tagging Entities.

Zoom Out - Zooms the entity graph out.

Zoom In - Zooms the entity graph in.

Reset Zoom - Resets the entity graph to the default zoom setting.

Fit to Area - Adjusts the entity graph so that it fits within the entity graph panel.


Relationship Diagram Group View

If an entity has more than a configured number of related entities, the entity graph switches

to a group view, in which the related entities are presented collectively as a group node.

Group nodes are indicated by rounded corners, as shown in the following example. The

number of entities in the group is shown in brackets [] on the group node.

Relationship Diagram - Group View

By default, up to 20 related entities are shown before the relationship diagram switches to

the group view. For information on changing this default, see the Configuring the Master

Data Manager section of the DataFlux qMDM Solution Administrator's Guide.

If you select a group node on the entity graph, the details panel shows the entities in the

group. You can select entity records from the details panel and use the Add to Diagram

option to add the records to the entity graph.

Group View Toolbar

The toolbar at the top of the details panel in the group view contains an Action menu

with the following options.


Relationship Diagram Group View Toolbar - Action Menu




Open - Opens the selected entity record from the details panel table in an entity

editor.

Add to Diagram - Adds the selected entity record from the details panel table to the

entity graph. When you add entity records from a group node to the graph, the entity

count shown in brackets on the group node is decremented accordingly.

Retire Relationship - Retires the selected entity relationship from the details panel

table. For more information, see Retiring Entity Relationships.

Tag - Tags the selected entity record from the details panel table to be added to a

workflow. For more information, see Tagging Entities.

Refresh - Refreshes the details panel table.

Print - Prints the details panel table.

Export - Displays a secondary menu with options for exporting the details panel table in CSV, PDF, or Excel format.

Retiring Entity Relationships

You can retire entity relationships from the following locations:

The entity graph on an Entity Editor's Relationship Diagram tab

A relationship table on an Entity Editor's Properties tab

The details panel table in the group view of an Entity Editor's Relationship Diagram

tab

Retiring an Entity Relationship from an Entity Graph

From the entity graph on an Entity Editor's Relationship Diagram tab, you can retire one

or more relationships between a single pair of entities—that is, one or more relationships

that share a single arrow on the diagram.

Note: Relationships between an entity and a group node cannot be retired.


To retire entity relationships from an entity graph, select the relationship arrow between the

two entity nodes. Each relationship represented by the selected arrow will be listed in the

filter panel. Select the check boxes corresponding to the relationships that you want to

retire, and click Retire Relationship. In the Retire dialog, select the desired option, and

click OK to confirm.

Selecting the Retire immediately option will retire the entity relationship after you

click OK.

Selecting the Retire at option will retire the entity relationship at a specified future time.

Retiring an Entity Relationship from a Table

To retire one or more entity relationships from a table, select the desired table rows and

select Actions > Retire Relationship. In the Retire dialog, select the desired option, and

click OK to confirm.

Selecting the Retire immediately option will retire the entity relationship after you

click OK.


Selecting the Retire at option will retire the entity relationship at a specified future time.

Tagging Entities

You can use the Tag option on the Entity Editor toolbar to tag an entity for addition to a

workflow.

An entity can be tagged more than once. Selecting the Tag toolbar option displays the Tag

Entity dialog, in which you can enter a title, priority, and notes for the workflow.

All the selected entity records will have the same title, priority, and notes, but each record

will appear in its own workflow.

Tag Entity Dialog

Retiring Entities

You can use the Retire option on the Entity Editor toolbar to retire an entity.

If there is a contributor record loaded that is not the last remaining record, that record will

be retired. Records are not deleted from qMDM, but they are no longer active. This is for

historical audit purposes as well as the ability to retrieve the cluster of an entity in the

future, if needed.

Selecting the Retire toolbar option displays the Retire Entity dialog.


Retire Entity Dialog

In the Retire Entity dialog, selecting the Retire immediately option will retire the record

after you click OK.

Selecting the Retire at option will retire the record at a specified future time.

Note: Retiring an object such as an entity type or attribute relationship,

will remove it from use. These objects cannot be created again without

manually removing the related artifacts from the database. For example, the

creation of an entity type will also create a corresponding table and view. The

entity type cannot be created again until the table and view are removed.

Working with Entity History

The history tab shows the creation, retirement, and movement of records within a cluster.

Entity History

All of the actions on the context menu match their counterparts in other sections. There is

also a filter toolbar located in the upper right corner of the history display. Use this filter to

expand or restrict the amount of historical data that is displayed. The default is set at 30

days. To see all history records, set the filter to zero.

The following action types are reflected in the history tab:

INSERT denotes a record being added to the hub.


RETIRE shows when the record was retired.

MOVE (OUT) shows that a record was moved out of the cluster.

MOVE (IN) shows that a record was moved in to the cluster.

The columns in the history display are fixed and are the same for every entity type. The

Modified by column reflects the user that performed an INSERT or RETIRE action, while the

Comment column displays a message reflecting user action for the record.


Definitions Riser From the Definitions riser, data stewards can maintain the model information for the

qMDM hub. This information includes the definitions of entity types, hierarchy types, roles,

source systems, and languages, and is used to manage and present information in the

qMDM hub and Master Data Manager.

The Definitions riser is available only to users who have an administrative role.

Definitions Riser

Definitions Riser Overview

Entity Type Definitions

Hierarchy Type Definitions

Association Tables

Role Definitions

Source System Definitions


Language Definitions

Definitions Riser Overview

From the Definitions riser, you can manage metadata definition types that appear in the

definitions tree. The Definitions riser toolbar contains an action menu with the following

options:

Definitions Riser Action Menu

Open - Opens the definition type selected in the tree.

Import Model - Opens the Import Model dialog where you choose a .met file for import.

Users of the Master Data Management Foundation feature of Data Management Studio

can export entity type definitions into entity definition (.met) files, which qMDM can

import to create new entity types. You can also import a .met file that was exported

from qMDM. (see Export Model, below).

Note: For more information on the Master Data Management Foundation feature,

see the Using Master Data Management Foundation section of the DataFlux Data

Management Studio User's Guide.

To import a .met file, select the Import Model option from the definitions riser action

menu. The Import Entity Type dialog appears, prompting you for a .met file to upload

to the Data Management Server. The file that you specify must be a .met format file.

Import Model Dialog

The contents of the .met file will be parsed, and presented in a popup from where you

can choose what you’d like to import into your hub:


Import Model Object Selection

When selections in this dialog are made, the dependencies are automatically included

as well. For instance, selecting the sample MANUFACTURES hierarchy type references

the PART and COMPANY entity types, which are derived from ENTITY and PARTY

respectively; and COMPANY has a relationship type defined that references

INDIVIDUAL, so selecting this hierarchy type also includes all of the entity types

automatically. Additionally, access to PART is restricted to users with the

MDM_POWERUSER role, so that role is selected as well.

Similarly, if you remove an item from the selection all the objects that depend on it

are removed from the selection.

When you import metadata using this interface, the objects in the hub are merged

with the objects represented in the .met file. Importing will not cause any previously

existing objects to be retired; import can only add to the hub. Any objects that were

previously retired in the hub but are present in the .met file are left unchanged.

Export Model - Opens a selection dialog that allows you to choose which parts of the

model are to be exported to a .met file. Only active objects are shown. You cannot export retired objects.


Export Model Dialog

Note: When you select Export Model, dependencies are automatically

included. For instance, if you select a hierarchy type, the entity types and

roles that are referenced by the hierarchy type are automatically added to the

selection. If an object is removed from the selection, all the objects that

depend on it are automatically removed from the selection.

Definition Types

Following are the metadata definition types managed from the Definitions riser:

Definition

Type

Description

Entity Types Manages user-defined entities and their attributes. Attributes are data

elements for their entity types, in much the same way that columns are part

of a table in a relational database.

Hierarchy

Types

Manages the hierarchy metadata for hierarchies that can be constructed on

the Master Data riser.

Roles Manages the roles that qMDM uses to grant user permissions.

Source

Systems

Manages the source systems where the contributor records in the qMDM hub

originate.

Languages Manages the languages that qMDM supports and their associated QKBs and

ISO locales.

Definitions Tree

On the Definitions riser, the available definition types appear in a navigation tree.


Definitions Tree

Definition Table

When you open a definition type from the definitions tree, the corresponding definition table

is displayed on a tab in the information pane. For example, opening the Entity Types

definition type displays the entity type definition table (shown below); opening the

Hierarchy Types definition type displays the hierarchy type definition table; and so on. Each

definition table is displayed on a separate tab.

Entity Type Definition Table

From a definition table, you can select and open definitions for viewing and editing.

Opening a row in the definition table adds a corresponding entry to the definitions tree.

Closing a definition tab removes the corresponding entry from the definitions tree. Closing

the definition table does not change the definitions tree.

Definition Table Toolbar

The toolbar at the top of a definition table contains an Action menu with the following

options.

Definition Table Toolbar - Action Menu

New [definition type] - Creates a new definition. The definition will be an instance

of the same type that appears in the definition table. For example, selecting this


option from the entity type definition table creates a new entity type definition;

selecting the option from the hierarchy type definition table creates a new hierarchy

type definition; and so on.

Open - Depending on the definition table type, opens the selected definition in the

appropriate editor, on a separate tab.

o For entity type definitions, selecting this option opens the definition in a

Property Editor (the Properties tab of an Entity Type Editor). To open an entity

type definition in one of the other available types of editors, use the Open as

options (see below).

o For hierarchy type definitions, selecting this option opens the definition in a

Hierarchy Type Editor.

o For role definitions, selecting this option opens the definition in a Role Editor.

o For source system definitions, selecting this option opens the definition in a

Source System Editor.

o For language definitions, selecting this option opens the definition in a Language

Editor.

Open as - Available only in entity type definition tables. Displays a secondary menu

with the following options:

o Open Attributes - Opens the selected entity type definition in an Attribute

Editor (the Attributes tab of an Entity Type Editor).

o Open Cluster Conditions - Opens the selected entity type definition in a

Cluster Condition Editor (the Cluster Conditions tab of an Entity Type Editor).

o Open Relationship Types - Opens the selected entity type definition in a

Relationship Type Editor (the Relationship Types tab of an Entity Type Editor).

Generate – For entity types only, generate jobs for the selected entity types.

Publish - For entity types only, publish the selected entity types.

Retire - Retire the entity type immediately, or at a specified time.

Show/Hide Retired - Toggles the definition table to either include or exclude retired

definitions. If included, retired definitions appear dimmed in the definition table.

Print - Prints the definition table.

Export - Displays a secondary menu with options for exporting the definition table in


Import - Available only in entity type definition tables. Imports an entity type

definition from an entity definition (.met) file that was previously exported using the

Master Data Management Foundation feature of Data Management Studio. For more

information, see Importing Entity Type Definitions.


Entity Type Definitions

Entity type definitions enable you to configure the metadata for the qMDM hub and Master

Data Manager and to define entity-specific attributes for clustering, match codes, and

standardization.

Notes:

1. The entity types shown in the following image are samples provided with qMDM,

and may not match the definitions in your qMDM hub. For more information on

these sample entity types, see Sample Metadata.

Entity Types

2. For step-by-step examples that demonstrate how to create, generate jobs for,

and publish an entity type definition, see Appendix A: Examples.

3. Entity type definitions can be imported from an entity definition (.met) file that

was previously exported using the Master Data Management Foundation feature

in Data Management Studio. For more information, see Importing Entity Type

Definitions.

Entity Type Editor

An Entity Type Editor is used to create a new entity type definition or to edit an existing

entity type definition. To display an Entity Type Editor, select and open a row in the entity

type definition table.


Entity Type Editor

From an Entity Type Editor, you can collaborate on an entity type definition and publish the

definition when you are ready to move it into production. Managing the lifecycle is done

through the Save, Generate Jobs, and Publish options on the Entity Type Editor toolbar.

This cycle can be repeated as necessary to achieve the correct definition for an entity type.

Entity Type Editor Tabs

An Entity Type Editor contains the following four tabs:

Properties - Displays a Property Editor, from which you can view and modify

properties for an entity type definition, such as the entity type's description and

parent type.

Attributes - Displays an Attribute Editor, from which you can create and modify

attributes for an entity type definition.

Cluster Conditions - Displays a Cluster Condition Editor, from which you can create

and modify cluster conditions for an entity type definition.

Relationship Types - Displays a Relationship Type Editor, from which you can create and modify relationship types for an entity type definition.


Entity Type Editor Toolbar

The toolbar at the top of an Entity Type Editor contains an Action menu with the

following options.

Entity Type Editor Toolbar - Action Menu

Save - Saves the entity type definition. You can make changes to the entity type

definition by adding attributes as needed.

Reset - Discards changes and resets the Entity Type Editor to its original state.

Retire - Retires the entity type definition. A retired entity type definition becomes

inactive but is not deleted from qMDM. A retired entity type definition can be viewed

as read-only but cannot be edited.

When an entity type is retired, all the entity types that are derived from it are also

retired, along with the attributes, clustering conditions, and relationship types for the

entity type or types.

If you have started editing an entity type but have not yet saved it, it will be updated

such that its parent becomes the parent of the entity type being retired.

Generate Jobs - Generates default batch jobs and data services in support of the

entity type. The generation process uses the metadata that has been saved in the

qMDM hub, and publishes .djf and .ddf files to your Data Management Server.

Note: Changes to the metadata definition (including the metadata for any parent

types) are not fully functional until the jobs for the type and any derived types have

been regenerated.

The Generate Jobs action presents a dialog from which you can select the jobs that

you want to generate. For example, you may not want to regenerate the

standardization job (mdm_stnd_<entity_type>.ddf) if you have customized it for

your needs.


Generate Jobs Dialog

For abstract entity types, not all jobs are required. For example, abstract entity types

will generally support search operations but will not support any of the other jobs. The

unnecessary jobs are shown as dimmed in the Generate Jobs dialog.

If you are generating jobs from the Entity Type list and have selected more than one

entity type in the list, the selections you make will apply to every entity type in the

selection. The job names will appear as ‘<MULTIPLE>’ instead of the entity type to

emphasize that you’re generating jobs for multiple entity types.

If you select the Overwrite existing files check box, files will be replaced on your

Data Management Server if they exist.

These jobs will generally need to be customized to incorporate your standardization

and match code generation requirements, cluster conditions, and survivorship rules.

Download the batch jobs and services to your Data Management Studio environment,

modify them, and then republish them on the server.

Publish - The publication step makes the entity type definition active. This includes

generating the tables used to store the data in your DBMS, as well as updating the

metadata that the Master Data Manager references when determining which entity types to display.


Property Editor

A Property Editor is used to view and modify properties for an entity type definition, such as

the entity type's description and parent type.

To display a Property Editor, select the Properties tab in an Entity Type Editor.

Property Editor

Property Editor Fields

A Property Editor contains the following fields.

Note: For information on the role association table at the bottom of a

Property Editor, see Association Tables.

Type - Required field. The entity type, which is used by the qMDM hub, bulk jobs,

data services, stored procedures, job generation, database naming conventions, and

processes that run outside of qMDM.

Description - The entity type definition description.


Parent Type - The parent entity type that contributes metadata to the entity type. All

entity types ultimately derive from the ENTITY entity type, which is the default.

Abstract - Indicates whether the entity type is an abstract entity type. Selecting this

option indicates that instances of the entity type cannot be created. Deselecting this

option indicates that instances of the entity type can be created (the entity type is

referred to as concrete).

Last Modified - Read-only field. The date and time when the entity type definition

was last updated. This date is automatically updated when the entity type definition is

saved.

Last Published - Read-only field. The date and time when the entity type definition

was last published.

Label - Required field. The entity type display name. The display name is used by the

Master Data riser searches and hierarchies.

Sort Order - Required field. Controls the entity type's sort order in Master Data

Manager selection lists (for example, the Entity Type list in the Create Entity dialog

and the Target Entity Type list in the Relationship Type Editor). To hide the entity

type and its associated attributes in the Master Data Manager selection lists, enter

either zero (0) or a negative value.

Valid From - Read-only field. The valid from date, on which the entity type definition

is active. This date is automatically set when a new entity type definition is created,

and is automatically updated when the entity type definition is saved.

Valid To - Read-only field. The valid to date, on which the entity type definition is

inactive or retired. This date is automatically updated when the entity type definition is retired.

Attribute Editor

An Attribute Editor is used to create and modify attributes for an entity type definition.

To display an Attribute Editor, select the Attributes tab in an Entity Type Editor.


Attribute Editor

Attributes Tree

The left side of an Attribute Editor displays the associated attributes for an entity type in a

navigation tree. Attributes that share the same Group field value (see the following

Attribute Editor Fields section) are visually grouped as parent and child nodes. Click an

attribute node in the tree to load the attribute into the Attribute Editor. A newly added or

modified attribute is marked with an asterisk (*).

The attributes and the higher-level groups are placed in the attributes tree according to

their respective Display Order values (see the following Attribute Editor Fields section).

Sufficient padding between attributes should be included to allow for future attributes to be

added, or for attributes to be reorganized.


Attributes Tree

Attribute Editor Toolbar

The toolbar at the top of an Attribute Editor contains an Actions menu with the following

options.

Attribute Editor Toolbar - Action Menu

New Attribute - Creates a new attribute.

New Flux Attribute - Creates a new flux attribute (an attribute that contains

standardized or match code values) based on a selected attribute in the attributes

tree. A flux attribute is always associated with another attribute.

Flux attributes are used for field mappings in the various entity data services and bulk

jobs, such as standardization jobs.

A flux attribute appears as a child node of the selected attribute in the attributes tree.

qMDM assigns a default name for a flux attribute by adding a 'DF_' prefix and a '_MC'

(match code) suffix to the parent attribute name. For flux attributes containing

standardized values, we recommend changing the default '_MC' suffix to a more

meaningful suffix such as '_STND'.

Retire - Retires the attribute. A retired attribute becomes inactive but is not deleted

from qMDM. A retired attribute can be viewed as read-only but cannot be edited.

An attribute cannot be retired if it is used in either a cluster condition or a relationship

type match condition.

Note: For information on considerations when retiring required attributes, see the discussion of the MDM_REQUIRED modifier in Attribute Modifiers.


Attribute Editor Fields

An Attribute Editor contains the following fields.

Notes:

1. For information on the role association table at the bottom of an Attribute

Editor, see Association Tables.

2. For information on setting the Search Display Order, Form Display Order,

Table Display Order, and Cluster Display Order values, see Presentation

Metadata.

Name - Required field. The attribute name.

Group - Groups similar attributes together in the Entity Editor. The groups are the

collapsible/expandable field sets in the Entity Editor.

Note: If you enter a new Group value (one that is not already known to qMDM),

and you subsequently want to use a different locale for a Master Data Manager

session, you will need to log on specifying the other locale and create the Group

value in that locale's language. If you enter an existing Group value for which the

corresponding value for a different locale already exists, the other locale's value will

be used, with no further modifications needed.

Label - Required field. The attribute display name.

Label Attribute - Required field. Indicates whether the attribute will be used as the

entity's name wherever it is used in the Master Data Manager (for example, in tabs,

riser navigation trees, messages, and hierarchies). Every entity type must have one

attribute denoted as its label attribute. For example, you may choose to use either the

company name or a stock ticker as the label attribute for a COMPANY entity type

definition.

Description - The attribute description.

Data Type - Required field. Maps the attribute to a given data type: String, Text, List,

Date, Timestamp, Boolean, Integer, Real, or URL. The data type determines how the

attribute data is stored and accessed in the database. By default, all newly defined

attributes are set to the String data type.

Length - Corresponds to the Data Type field. Fields with List, String, or Text data

types require a default length with a minimum length of 1. Fields with other data

types will ignore this length.

Required - Indicates whether the attribute is required or optional in the Entity Editor.

Constraint - Indicates whether the attribute has a regular expression constraint that

requires the incoming attribute data to match the defined regular expression. If the

attribute data does not match this constraint, the data will be marked as invalid.

Typical attributes that have constraints include phone numbers, addresses, and email

addresses.

Fields with a list data type have built-in constraints that limit specific characters, for

example, M, F, and U for Gender. Semicolons (;) act as delimiters. Other constraints

specify the allowable format for input characters as regular expressions. For more


information about regular expressions, refer to the DataFlux Expression Language

Reference Guide.

Encrypt Flag - Indicates whether the attribute is encrypted in the database. This field

can be modified only if the attribute or the entity type has not been published. After

the attribute or entity type is published, this field becomes a read-only field.

Search Display Order - Required field. Indicates the attribute's display order in the

entity search form.

Form Display Order - Required field. Indicates the attribute's form display order on

the Entity Editor Properties tab.

Table Display Order - Required field. Indicates whether the attribute will appear in a

specific column order in entity search results tables.

Cluster Display Order - Required field. Indicates whether the attribute will appear in

a specific column order in the cluster table on the Entity Editor Cluster Members tab.

Read Only - Indicates whether the attribute is editable or read-only in the Entity

Editor. Read-only fields and labels appear dimmed. In most cases, except the select

menu, the text inputs are shown as static text. The select menus are shown as

disabled menus.

Valid From - Read-only field. The valid from date, on which the attribute is active.

This date is automatically updated when the entity type is published.

Valid To - Read-only field. The valid to date, on which the attribute is inactive or

retired. This date is automatically updated when the attribute is retired.

Inherited Attributes

If the attribute is inherited from another entity type, you will only be able to change the

display properties. Other values must be changed in the context where the attribute is

defined. If the inherited attribute has been modified, the Attribute Editor will display a

message similar to the following. Use the Reset link on the right to remove the override.

Changes will not be applied until the entity type is saved.

Cluster Condition Editor

A Cluster Condition Editor is used to create and modify cluster conditions for an entity type

definition. Records that have the same values for the attributes specified in the cluster

condition will be clustered together.

To display a Cluster Condition Editor, select the Cluster Conditions tab in an Entity Type

Editor.


Cluster Condition Editor

The Condition (top) section of the editor lists the cluster conditions that have been defined

for an entity type. You can double-click a condition in the list to load it into the Edit

Condition (bottom) section, where you can add attributes to and remove attributes from

the condition by either double-clicking or using the arrows.

The condition list includes conditions that are inherited by the entity type (for example, the

source system ID/source system record ID condition from ENTITY). However, inherited

conditions cannot be modified in the Cluster Condition Editor. To update an inherited

condition, you must open an Entity Type Editor on the entity type where the condition is

defined.

When you use the Generate Jobs option from the Entity Type Editor, the cluster conditions

that you define in the Cluster Condition Editor will be automatically added to the jobs that

need this information.

Cluster Condition Editor Toolbar

The toolbar at the top of a Cluster Condition Editor contains an Action menu with the

following options.

Cluster Condition Editor Toolbar - Action Menu


Add Condition - Creates a new cluster condition that has no attributes associated

with it.

Retire - Retires the selected cluster condition from the list of cluster conditions associated with the entity type definition.

Relationship Type Editor

A Relationship Type Editor is used to create and modify relationship types for an entity type

definition. Relationship types describe the kinds of relationships that can exist between the

associated entity types. Relationship types define source and target entity types, and have

optional match conditions that can be used to determine if two entities are related.

To display a Relationship Type Editor, select the Relationship Types tab in an Entity Type

Editor.

Relationship Type Editor


The left side of the editor shows a list of relationship types that are defined with the entity

type as the source entity type. Selecting a relationship type on the left side of the editor

updates the fields on the right side. You can use the New toolbar option to create a new

relationship type, or use the Retire option to retire an existing relationship type.

The relationship type list includes relationships that are inherited by the entity type.

However, inherited relationship types cannot be modified in the Relationship Type Editor. To

update an inherited relationship type, you must open an Entity Type Editor on the entity

type where the relationship type is defined.

Relationship Type Editor Toolbar

The toolbar at the top of a Relationship Type Editor contains an Action menu with the

following options.

Relationship Type Editor Toolbar - Action Menu

New - Creates a new relationship type.

Retire - Retires the selected relationship type.

Relationship Type Editor Fields

The Properties panel at the top right of a Relationship Type Editor contains the following

fields. Use these fields to change the information associated with the relationship type.

Note: The Sort Order and Inverse Sort Order fields control whether the

relationship type appears in the Entity Editor. To prevent the relationship type

from appearing in the Entity Editor, enter either zero (0) or a negative value

in these fields. To show the relationship type in the Entity Editor, enter a

value greater than zero. Sufficient padding should be included to allow for

future relationship types to be added, or for relationship types to be

reorganized.

Type - Required field. The relationship type name.

Note: Relationship type names must be unique.

Label - The relationship type's display name.

Inverse Label - The display name used by the target entity type when presenting

the relationship.

Description - A description of the relationship type.

Target Entity Type - The entity type that appears on the other end of the

relationship.

Note: Changing the target entity type will remove any match conditions that have

been defined for the relationship type.


Sort Order - Required field. Indicates the relationship type's form display order in the

Entity Editor for the source entity type.

Inverse Sort Order - Required field. Indicates the relationship type's form display

order in the Entity Editor for the target entity type.

Valid From - Read-only field. The valid from date, on which the relationship type is

active. This date is automatically updated when the entity type is saved.

Valid To - Read-only field. The valid to date, on which the relationship type is inactive or retired. This date is automatically updated when the relationship type is retired.

Defining Match Conditions for a Relationship Type

Below the Properties panel, a match table with a set of match conditions appears. You can

identify the attributes in the source and target entity types that are used to relate instances

of their entity types automatically.

To create new match conditions, do the following:

1. Select one attribute from the Source Attribute tree and one attribute from the

Target Attribute tree.

2. Select the New Match option on the match table toolbar.

3. Continue adding matches one by one until you have fully specified a single match

condition.

All the attributes in one group are used when determining if two entities are related. To

create additional groups, use the New Group option on the match table toolbar, and then

add matches as above. Use the up and down arrows on the toolbar to rearrange groups of

attributes, or use the Delete option to remove a match.

Notes:

1. When creating match conditions, the source and target attributes must have

comparable data types. For example, an Integer attribute cannot be compared

against a String attribute.

2. The source and target attributes must be unique within each group. If there are

redundant rules within a group, they will be automatically merged when you

save the entity type.

Hierarchy Type Definitions

Hierarchy type definitions enable you to define hierarchy types that are used to build

hierarchies of entities. The hierarchy types determine the types of entities that can exist

within a hierarchy. Entity type definitions that are not included in a hierarchy type definition

will not be allowed within that hierarchy. Hierarchy type definitions are used by the Master

Data riser and panels for creating and editing hierarchies.

Note: The hierarchy types shown in the following image are samples

provided with qMDM, and may not match the definitions in your qMDM hub.


Hierarchy Types

Hierarchy Type Editor

A Hierarchy Type Editor is used to create a new hierarchy type definition or to edit an

existing hierarchy type definition. To display a Hierarchy Type Editor, open a definition from

a hierarchy type definition table.

Hierarchy Type Editor

Hierarchy Type Editor Toolbar

The toolbar at the top of a Hierarchy Type Editor contains an Action menu with the

following options.

Hierarchy Type Editor Toolbar - Action Menu


Save - Saves the hierarchy type definition.

Reset - Discards changes and resets the Hierarchy Type Editor to its original state.

Retire - Retires the hierarchy type definition. A retired hierarchy type definition

becomes inactive but is not deleted from qMDM. A retired hierarchy type definition can be viewed as read-only but cannot be edited.

Hierarchy Type Editor Fields

A Hierarchy Type Editor contains the following fields.

Note: For information on the entity and role association tables at the

bottom of a Hierarchy Type Editor, see Association Tables.

Type - Required field. The display name associated with the hierarchy type definition.

Description - Required field. The hierarchy type definition description.

Valid From - Read-only field. The valid from date, on which the hierarchy type

definition is active. This date is automatically set when a new hierarchy type definition

is created, and is automatically updated when the hierarchy type definition is saved.

Valid To - Read-only field. The valid to date, on which the hierarchy type definition is

inactive or retired. This date is automatically updated when the hierarchy type definition is retired.

Association Tables

Role and entity association tables are used to apply data masking to master data

definitions.

Role Association Table

Entity Association Table

Role Association Tables

Role association tables appear in the following editors:


Property Editors (the Properties tab of an Entity Type Editor)

Attribute Editors (the Attributes tab of an Entity Type Editor)

Hierarchy Type Editors

Users who have the roles listed in a role association table have been granted access to the

definition. Roles that are not listed cannot access the information. There are two important

exceptions to this rule:

Data stewards (administrators) are always able to access all system functions and

data.

If no permissions have been explicitly granted, the definition is deemed public, and all users can access it.

Note: Changing roles that are inherited from an entity type must be done from the

Entity Type Editor for the parent entity type. For example, given entity types Parent and

Child, you cannot remove a role that is defined by Parent using the Entity Type Editor for

Child—you must use the Entity Type Editor for Parent to remove the role.

Entity Association Tables

Entity association tables appear only in Hierarchy Type Editors. Entity types that are listed

in an entity association table have been granted access to the definition. Entity types that

are not listed cannot access the definition.

Association Table Toolbar

For both role and entity association tables, the toolbar at the top of the table contains an

Action menu with the following options.

Association Table Toolbar - Action Menu

Add Association - Displays an Add Association dialog in which you can add a role

or entity association to a definition.

Add Association Dialogs for Role and Entity Associations

Retire - Removes a role or entity association.


Role Definitions

Role definitions enable you to manage permissions for qMDM user groups. Roles are used to

restrict specific entities and hierarchy types from being viewed or modified. For more

information on qMDM user groups, see the Creating User Groups and Users section of the

DataFlux qMDM Solution Administrator's Guide.

Note: The roles shown in the following image are samples provided with

qMDM, and may not match the definitions in your qMDM hub.

Roles

Role Editor

A Role Editor is used to create a new role definition or to edit an existing role definition. To

display a Role Editor, open a definition from a role definition table.

Role Editor

Role Editor Toolbar

The toolbar at the top of a Role Editor contains an Action menu with the following

options.

Role Editor Toolbar - Action Menu

Save - Saves the role definition.

Reset - Discards changes and resets the Role Editor to its original state.

Retire - Retires the role definition. A retired role definition becomes inactive but is

not deleted from qMDM. A retired role definition can be viewed as read-only but

cannot be edited.


Role Editor Fields

A Role Editor contains the following fields:

Name - Required field. The display name associated with the role definition.

Description - The role definition description.

Is Root - A system indicator used to determine whether the role has administrative

responsibilities. Denotes a super user, with access to all system functions and data.

Enable Advanced Search - A system indicator used to determine whether the role

has the ability to use the Advanced search feature on the Master Data riser.

Valid From - Read-only field. The valid from date, on which the role definition is

active. This date is automatically set when a new role definition is created, and is

automatically updated when the role definition is saved.

Valid To - Read-only field. The valid to date, on which the role definition is inactive or retired. This date is automatically updated when the role definition is retired.

Source System Definitions

Source system definitions enable you to define source systems associated with entity data.

The source system is used to determine where entity data and cluster information originally

came from.

Note: The source systems shown in the following image are samples

provided with qMDM, and may not match the definitions in your qMDM hub.

Source Systems

The following sample source systems are included with qMDM, and are required for correct

operation:

Best Record - A source system representing the qMDM hub. All survivor records

appear in this source system.

MD Manager - A source system representing the Master Data Manager. All records

created by the Master Data Manager appear in this source system.


Source System Editor

A Source System Editor is used to create a new source system definition or to edit an

existing source system definition. To display a Source System Editor, open a definition from

a source system definition table.

Source System Editor

Source System Editor Toolbar

The toolbar at the top of a Source System Editor contains an Action menu with the

following options.

Source System Editor Toolbar - Action Menu

Save - Saves the source system definition.

Reset - Discards changes and resets the Source System Editor to its original state.

Retire - Retires the source system definition. A retired source system definition

becomes inactive but is not deleted from qMDM. A retired source system definition can be viewed as read-only but cannot be edited.

Source System Editor Fields

A Source System Editor contains the following fields:

Name - Required field. The display name associated with the source system

definition.

Description - The source system definition description.

Path - Read-only field. Applicable only for source system data that is migrated from

DataFlux Master Data Management Foundation (see Migrating from a Master Data

Management Foundation Hub). Used to correlate the source system with its

representation in the Master Data Management Foundation hub, where it is referred to

as a source table.

Valid From - Read-only field. The valid from date, on which the source system

definition is active. This date is automatically set when a new source system definition

is created, and is automatically updated when the source system definition is saved.


Valid To - Read-only field. The valid to date, on which the source system definition is

inactive or retired. This date is automatically updated when the source system

definition is retired.

Language Definitions

Language definitions enable you to register languages that are used to associate entity data

with a given locale. Standardized values and match codes will be computed based on the

language associated with the entity data.

Note: To use the language locale features with standardizations and match

codes, you must have a valid QKB license for the language that you want to

use.

Languages

The English (US) language is included with qMDM by default.

Language Editor

A Language Editor is used to create a new language definition or to edit an existing

language definition. To display a Language Editor, open a definition from a language

definition table.

Language Editor

Language Editor Toolbar

The toolbar at the top of a Language Editor contains an Action menu with the following

options.

Language Editor Toolbar - Action Menu

Save - Saves the language definition.


Reset - Discards changes and resets the Language Editor to its original state.

Retire - Retires the language definition. A retired language definition becomes

inactive but is not deleted from qMDM. A retired language definition can be viewed as read-only but cannot be edited.

Language Editor Fields

A Language Editor contains the following fields:

Name - Required field. The display name associated with the language definition.

MDM QKB Locale - Required field. QKB locale abbreviation that matches the QKB

locale. The format is [ISO 3166-1-alpha-2] [ISO 3166-1-alpha-3] (two-letter country

code followed by three-letter country code). For example:

o United States = [EN][USA] = ENUSA

o Germany = [DE][DEU] = DEDEU

o France = [FR][FRA] = FRFRA

MDM ISO Locale - Required field. ISO 3166-1-alpha-3 code (three-letter country

code). For example:

o United States = USA

o Germany = DEU

o France = FRA

Is Default - Indicates whether the language definition is the default used by qMDM.

There can be only one default language definition for the system.

Valid From - Read-only field. The valid from date, on which the language definition is

active. This date is automatically set when a new language definition is created, and is

automatically updated when the language definition is saved.

Valid To - Read-only field. The valid to date, on which the language definition is

inactive or retired. This date is automatically updated when the language definition is

retired.


Appendix A: Examples The following examples demonstrate how to create qMDM entity types and entity

relationships. The examples are intended to be used in the order listed, because each

example builds on the previous example.

Example 1: Creating an Abstract Entity Type

Example 2: Creating a Concrete Entity Type

Example 3: Creating Entity Relationships

Example 1: Creating an Abstract Entity Type

The example presented in this section creates an abstract entity type named Vehicle with

VIN (vehicle identification number), Manufacturer, Model, Year, and Plate attributes, as well

as a DF_VIN_MC flux attribute. The example defines a single cluster condition based on the

DF_VIN_MC flux attribute, and defines two relationship types: Owner and Driver.

Because Vehicle is modeled as an abstract entity type, instances of this entity type cannot

be created. Instead, concrete entity types must be created in order to use this metadata in

the qMDM hub. The example presented in Example 2: Creating a Concrete Entity Type

creates a concrete entity type named Car, which inherits metadata from the Vehicle entity

type.

Open an Entity Type Editor

1. On the Master Data Manager Definitions riser, double-click the Entity Types node in

the definitions tree to display the entity type definition table.

Notice that the definition table contains the ENTITY (top-level) entity type, from which

all other qMDM entity types inherit metadata. The table also contains the sample

entity types that are provided with qMDM: Party, Individual, Company, and Part.

2. In the entity type definition table, click the New Entity Type button on the toolbar to

open an Entity Type Editor.


3. Continue with the following sections to complete the fields on the Entity Type Editor

Properties, Attributes, Cluster Conditions, and Relationship Types tabs.

Define Entity Type Properties

1. In the Entity Type Editor, the Properties tab appears by default, displaying a

Property Editor. The Property Editor is used to view and modify properties for an

entity type definition, such as the entity type's description and parent type.

2. In the Entity Type panel of the Property Editor, enter the following:

a. In the Type field, enter 'VEHICLE' as the entity type.

b. In the Description field, enter 'Abstract Vehicle type; extend with concrete

types' as the entity type description.

c. Leave the Parent Type field set to its default value, 'ENTITY'. This value

specifies the parent entity type that will contribute metadata to the Vehicle

entity type.


d. Select the Abstract check box. Selecting this option indicates that Vehicle will

be an abstract entity type, meaning that instances of this entity type cannot be

created.

3. In the Display panel of the Property Editor, enter the following:

a. In the Label field, enter 'Vehicle' as the label for the entity type.

b. In the Sort Order field, enter '1' as the sort order for the entity type. This will

put the Vehicle entity type near the top of the various selection lists within the


4. Notice that the Last Modified and Last Published fields in the Entity Type panel

and the Valid From and Valid To fields in the Validity panel are blank. The Last

Modified, Last Published, and Valid From fields will be automatically completed

when you save and publish the entity type definition in later steps. The Valid To field

will remain blank until the entity type definition is retired. Retiring an entity type

definition is not covered in this example.

5. Click the Save button on the Entity Type Editor toolbar to save the changes. The

Property Editor should now look as follows.


Define Attributes

1. In the Entity Type Editor, select the Attributes tab to display the Attribute Editor. The

Attribute Editor is used to create and modify attributes for an entity type definition.

Notice that the attributes tree on the left side of the Attribute Editor already contains

a default set of attributes for the Vehicle entity type. These attributes are

automatically inherited from the ENTITY (top-level) entity type.

2. Using the following table as a guide, add five new attributes to the Vehicle entity type:

VIN, Manufacturer, Model, Year, and Plate. To add a new attribute, click the New

Attribute button on the Attribute Editor toolbar. Note the following:

An entity type definition must have exactly one designated Label Attribute.

The Label Attribute can be inherited from the parent entity type. Label

attributes are always and implicitly required.


The Length field is not applicable for Integer attributes.

The Search Display Order values for the five new attributes (90, 92, 94, 96,

and 98, respectively) were selected because they are lower than 100, which is

the lowest Search Display Order value for the attributes that are inherited

from the ENTITY (top-level) entity type. This will cause the five new attributes

to appear above the MDM Identifiers group containing the inherited attributes,

in the search form on the Master Data riser.

Attribute

Editor Field

Attribute 1

Value

Attribute 2

Value

Attribute 3

Value

Attribute 4

Value

Attribute 5

Value

Name VIN MANUFACTURER MODEL YEAR PLATE

Group Vehicle

Information

Vehicle

Information

Vehicle

Information

Vehicle

Information

Vehicle

Information

Label Vehicle

Identification

Number

Manufacturer Model Year Plate

Label

Attribute

Yes No No No No

Description Vehicle

Identification

Number

Vehicle

manufacturer

Vehicle

model

designation

Year of

manufacture

Current

plate

number

Data Type String String String Integer String

Length 50 50 50 N/A 10

Required No No No No No

Constraint (leave blank) (leave blank) (leave

blank)

(leave blank) (leave

blank)

Encrypt

Flag

No No No No No

Search

Display

Order

90 92 94 96 98

Form

Display

Order

90 92 94 96 98

Table

Display

Order

90 92 94 96 98

Cluster

Display

Order

90 92 94 96 98

Read Only No No No No No

3. Notice that the Valid From and Valid To fields in the Validity panel are blank. The

Valid From field will be automatically completed when you save and publish the

entity type definition in later steps. The Valid To field will remain blank until the

entity type definition is retired. Retiring an entity type definition is not covered in this

example.


Attribute Editor should now look as follows. Notice that the five new attributes now


appear in the attributes tree.

Define Flux Attribute for VIN Attribute

1. The next step is to define a flux attribute based on the VIN attribute. The flux

attribute will be used for field mapping in the standardization job for the Vehicle entity

type (mdm_stnd_vehicle.ddf).

In the Attribute Editor, select the VIN attribute in the attributes tree. From the

Attribute Editor toolbar, select Actions > New Flux Attribute. A flux attribute

named DF_VIN_MC appears as a child node of the VIN attribute in the attributes tree.

qMDM automatically assigns the attribute name by adding a 'DF_' prefix and a '_MC'

(match code) suffix to the original attribute name.


2. Enter the following information in the other Attribute Editor fields for the DF_VIN_MC

attribute.

Attribute Editor Field Attribute Value

Group Vehicle Information

Label VIN Match Code

Label Attribute No

Description VIN Match Code

Data Type String



Length 40

Required No

Constraint (leave blank)

Encrypt Flag No

Search Display Order 0

Form Display Order 0

Table Display Order 0

Cluster Display Order 0

Read Only No


Attribute Editor should now look as follows.


Define Cluster Conditions

1. In the Entity Type Editor, select the Cluster Conditions tab to display the Cluster

Condition Editor. The Cluster Condition Editor is used to create and modify cluster

conditions for an entity type definition. Records that have the same values for the

attributes specified in the cluster condition will be clustered together.

Notice that there is a default cluster condition already defined for the entity type. This

cluster condition is automatically inherited from the ENTITY (top-level) entity type.

Also, notice that the five previously added attributes appear in the Available list in the

Edit Condition section of the Cluster Condition Editor. The previously added flux

attribute (DF_VIN_MC) also appears in the list.

2. Click the Add Condition button on the Cluster Condition Editor toolbar.

3. In the Edit Condition section, double-click the DF_VIN_MC flux attribute in the

Available list to transfer it to the Selected list.



Cluster Condition Editor should now look as follows.

Define Relationship Types

1. In the Entity Type Editor, select the Relationship Types tab to display the

Relationship Type Editor. The Relationship Type Editor is used to create and modify

relationship types for an entity type definition. Relationship types describe the kinds of

relationships that can exist between the associated entity types. Relationship types

define source and target entity types, and have optional match conditions that can be

used to determine if two entities are related.


2. Using the following table as a guide, add two relationship types to the entity type:

Driver and Owner. To add a new relationship type, click the New button on the

Relationship Type Editor toolbar.

Notice that the Target Entity Type for the Owner relationship type is Party. Both

Individual and Company are concrete subtypes of Party, which provides for the fact

that both individuals and companies can own a vehicle. The Target Entity Type for

the Driver relationship type is Individual, which provides for the fact that only a

person can actually drive a vehicle.

Note: This example does not demonstrate defining match conditions for a

relationship type, which is an optional step. Instead, the example presented in

Example 3: Creating Entity Relationships demonstrates manually constructing entity

relationships.

Relationship Type

Editor Field

Relationship Type 1

Value

Relationship Type 2

Value

Type DRIVER OWNER

Label Driven By Owned By


Relationship Type

Editor Field

Relationship Type 1

Value

Relationship Type 2

Value

Inverse Label Drives Owns

Description Used to associate people

with vehicles they drive

Used to associate people

with vehicles they own

Target Entity

Type

Individual Party

Sort Order 10 20

Inverse Sort

Order

10 20

3. Notice that the Valid From and Valid To fields in the Properties panel are blank.

The Valid From field will be automatically completed when you save and publish the



example.


Relationship Type Editor should now look as follows.


Generate Jobs

1. After you have created and saved the Vehicle entity type definition, the next step is to

generate default batch jobs and data services in support of the entity type. From the

Entity Type Editor, select Actions > Generate Jobs or click the Generate Jobs

button on the toolbar.


2. In the Generate Jobs dialog, select all three available jobs:

mdm_stnd_vehicle.ddf, mdm_query_survivor_vehicle.ddf, and

mdm_query_relationship_vehicle.ddf.

Notice that several of the listed jobs are shown as dimmed in the Generate Jobs

dialog, because these jobs are not required for abstract entity types.

3. Click OK to generate the jobs.

The job generation process uses the metadata that has been saved in the qMDM hub,

and publishes the mdm_stnd_vehicle.ddf, mdm_query_survivor_vehicle.ddf,

and mdm_query_relationship_vehicle.ddf jobs to your Data Management Server.

Add Match Code Generation to the Standardization Job

The steps in this section add match code generation to the standardization job for the

Vehicle entity type (mdm_stnd_vehicle.ddf).

1. On the Data Management Servers riser in Data Management Studio, select and log

on to the Data Management Server. Expand the Real-Time Data Services folder and

the qMDM folder, and locate the mdm_stnd_vehicle.ddf job.


2. Right-click the mdm_stnd_vehicle.ddf job, and select Export. From the Export To

Folder dialog, export the job to your qMDM repository folder.

3. On the Folders riser in Data Management Studio, locate and open the

mdm_stnd_vehicle.ddf job in the qMDM repository folder.

4. Add a Match Codes node between the Check locale node and the Field Layout 1

node. The Match Codes node will generate match codes for the selected fields when

the job is run. Match codes enable fuzzy matching of fields.

5. Double-click the Match Codes node to display its properties dialog. In the properties

dialog, do the following:

a. Double-click the VIN match code field in the Available list to transfer it to the

Selected list.

b. In the Definition column, select 'Text'.


c. Leave the Sensitivity value set to its default of 85.

d. In the Output Name column, enter 'DF_VIN_MC'.

e. Select the Generate null match codes for blank field values check box.

Selecting this option causes null match codes to be created for null or blank

input field values. This prevents null or blank field values from being clustered

together.

The properties dialog should now look as follows. Click OK to save the changes.

6. Save and close the mdm_stnd_vehicle.ddf job.

7. On the Data Management Servers riser, right-click the Real-Time Data Services

folder, and select Import. Import the modified mdm_stnd_vehicle.ddf job from

your qMDM repository folder to the Data Management Server.


Publish the Entity Type Definition

1. The final step is to publish the Vehicle entity type definition. From the Entity Type

Editor, select Actions > Publish or click the Publish button on the toolbar.

Publishing the entity type definition makes the definition active. This includes

generating the tables used to store the data in your DBMS, as well as updating the

metadata that the Master Data Manager references when determining which entity

types will be presented in the user interface.

2. Click OK in the confirmation dialog to publish the definition.

Because Vehicle has been defined as an abstract entity type, instances of this entity type

cannot be created. You can verify this by selecting the Master Data riser and clicking the

New button at the top of the riser to create a new entity. Notice that the Vehicle entity

type does not appear on the Entity Type menu in the Create Entity dialog.

Example 2: Creating a Concrete Entity Type

The example presented in this section builds on the Vehicle example presented in Example

1: Creating an Abstract Entity Type. Because the Vehicle entity type is modeled as abstract,

instances of this entity type cannot be created. Instead, concrete entity types must be

created in order to use this metadata in the qMDM hub. This example creates a concrete

entity type named Car, which inherits metadata from the Vehicle entity type.

Open an Entity Type Editor

1. On the Master Data Manager Definitions riser, double-click the Entity Types node in

the definitions tree to display the entity type definition table.


Notice that the definition table contains the ENTITY (top-level) entity type, from which

all other qMDM entity types inherit metadata. The table also contains the sample

entity types that are provided with qMDM: Party, Individual, Company, and Part, as

well as the Vehicle entity type created in the previous example.

2. In the entity type definition table, click the New Entity Type button on the toolbar to

open an Entity Type Editor.


3. Continue with the following sections to complete the fields on the Entity Type Editor

Properties and Attributes tabs.

Note: This example does not include steps for completing the fields on the Entity

Type Editor Cluster Conditions and Relationship Types tabs. Instead, the Car

entity type will inherit cluster conditions and relationship types from the Vehicle

(parent) entity type.

Define Entity Type Properties

1. In the Entity Type Editor, the Properties tab appears by default, displaying a

Property Editor. The Property Editor is used to view and modify properties for an

entity type definition, such as the entity type's description and parent type.

2. In the Entity Type panel of the Property Editor, enter the following:


a. In the Type field, enter 'CAR' as the entity type.

b. In the Description field, enter 'Automobile' as the entity type description.

c. In the Parent Type field, select 'VEHICLE' as the parent entity type that will

contribute metadata to the Car entity type.

d. Leave the Abstract check box deselected. Deselecting this option indicates that

Car will be a concrete entity type, meaning that instances of this entity type can

be created.

3. In the Display panel of the Property Editor, enter the following:

a. In the Label field, enter 'Car' as the label for the entity type.

b. In the Sort Order field, enter '2' as the sort order for the entity type. This will

cause the Car entity type to immediately follow the Vehicle entity type (which

has a sort order of '1') in the various selection lists within the Master Data

Manager user interface.

4. Notice that the Last Modified and Last Published fields in the Entity Type panel

and the Valid From and Valid To fields in the Validity panel are blank. The Last

Modified, Last Published, and Valid From fields will be automatically completed

when you save and publish the entity type definition in later steps. The Valid To field

will remain blank until the entity type definition is retired. Retiring an entity type

definition is not covered in this example.


Property Editor should now look as follows.


Define Attributes

1. In the Entity Type Editor, select the Attributes tab to display the Attribute Editor. The

Attribute Editor is used to create and modify attributes for an entity type definition.

Notice that the attributes tree on the left side of the Attribute Editor already contains

a default set of attributes for the Car entity type. The first eight attributes are

automatically inherited from the ENTITY (top-level) entity type. The last five attributes

and the DF_VIN_MC flux attribute are inherited from the Vehicle entity type created in

Example 1: Creating an Abstract Entity Type.


2. Using the following table as a guide, add a Capacity attribute to the Car entity type.

To add a new attribute, click the New Attribute button on the Attribute Editor

toolbar.

Note that the Search Display Order value 99 for the Capacity attribute was selected

because it is lower than 100 (the lowest Search Display Order value for the

attributes that are inherited from the ENTITY entity type), and higher than 98 (the

Search Display Order value for the Plate attribute that is inherited from the Vehicle

entity type). This will cause the Capacity attribute to appear immediately after the

Plate attribute, in the search form on the Master Data riser.



Name CAPACITY

Group Vehicle Information

Label Number of Passengers

Label Attribute No

Description Number of Passengers

Data Type Integer

Length N/A

Required No

Constraint (leave blank)

Encrypt Flag No

Search Display Order 99

Form Display Order 99

Table Display Order 99

Cluster Display Order 99

Read Only No

3. Notice that the Valid From and Valid To fields in the Validity panel are blank. The

Valid From field will be automatically completed when you save and publish the



example.


Attributes tab should now look as follows. Notice that the Capacity attribute now

appears in the attributes tree.


Generate Jobs

1. After you have created and saved the Car entity type definition, the next step is to

generate default batch jobs and data services in support of the entity type. From the

Entity Type Editor, select Actions > Generate Jobs or click the Generate Jobs

button on the toolbar.


2. In the Generate Jobs dialog, select the Select all check box.

3. Click OK to generate the jobs.

The job generation process uses the metadata that has been saved in the qMDM hub,

and publishes the selected jobs to your Data Management Server.

Add Match Code Generation to the Standardization Job

The steps in this section modify the mdm_stnd_car.ddf standardization job to reference

the mdm_stnd_vehicle.ddf standardization job, so that the Car entity type uses the

standardization defined by the Vehicle entity type.

1. On the Data Management Servers riser in Data Management Studio, select and log

on to the Data Management Server. Expand the Real-Time Data Services folder and

the qMDM folder, and locate the mdm_stnd_car.ddf job.

2. Right-click the mdm_stnd_car.ddf job, and select Export. From the Export To

Folder dialog, export the job to your qMDM repository folder.

3. On the Folders riser in Data Management Studio, locate and open the

mdm_stnd_car.ddf job in the qMDM repository folder.


4. Double-click the Check locale node to display its properties dialog. On the

Expression tab, declare an integer variable named 'vehicle_offset', and set the

variable to 'car_offset'. Click OK to save the changes.

5. Add a Data Job Reference node between the Check locale node and the Field

Layout 1 node. The Data Job Reference node will use the mdm_stnd_vehicle.ddf

job to compute the VIN match code.

Double-click the Data Job Reference node to display its properties dialog. In the

properties dialog, match each field with its corresponding parameter in the

mdm_stnd_vehicle.ddf standardization job. Note that the 'car_offset' field does not

have a corresponding parameter.


Click the Additional Outputs button to display the Additional Outputs dialog.

6. In the Additional Outputs dialog, select the 'car_offset' field as an additional field

that should be returned from the mdm_stnd_car.ddf standardization job. Click OK

to save the changes.

7. Click OK to close the properties dialog for the Data Job Reference node.

8. Save and close the mdm_stnd_car.ddf job.


9. On the Data Management Servers riser, right-click the Real-Time Data Services

folder, and select Import. Import the modified mdm_stnd_car.ddf job from your

qMDM repository folder to the Data Management Server.

Publish the Entity Type Definition

1. The final step is to publish the Car entity type definition. From the Entity Type Editor,

select Actions > Publish or click the Publish button on the toolbar. Publishing

the entity type definition makes the definition active. This includes generating the

tables used to store the data in your DBMS, as well as updating the metadata that the

Master Data Manager references when determining which entity types will be

presented in the user interface.

2. Click OK in the confirmation dialog to publish the definition.

Because Car has been defined as a concrete entity type, instances of this entity type can be

created. You can verify this by selecting the Master Data riser and clicking the New

button at the top of the riser to create a new entity. Notice that the Car entity type appears

on the Entity Type menu in the Create Entity dialog.

Example 3: Creating Entity Relationships

The example presented in this section demonstrates the following:

creating an instance of the Car entity type created in Example 2: Creating a Concrete

Entity Type

creating Owned By and Driven By entity relationships for the entity

exploring the Owned By and Driven By entity relationships graphically


The example also illustrates the inheritance of presentation metadata specified for the Car

entity type and for the Vehicle entity type created in Example 1: Creating an Abstract Entity

Type.

Create Entity

1. On the Master Data Manager Master Data riser, click the New button to display

the Create Entity dialog.

2. In the Create Entity dialog, select the Car entity type, and click OK to open an Entity

Editor. The Entity Editor Properties tab appears by default, displaying a Property

Editor.

Notice that the Property Editor contains a Vehicle Information panel. This panel

label is based on the Group values of the five attributes created for the Vehicle entity

type. See the Define Attributes section in Example 1: Creating an Abstract Entity

Type.

The Vehicle Information panel contains Vehicle Identification Number,

Manufacturer, Model, Year, and Plate fields. These field labels are based on the

Label values of the five attributes created for the Vehicle entity type. These attributes

are inherited by the Car entity type. The Vehicle Information panel also contains a

Number of Passengers field. This field label is based on the Label value of the

Capacity attribute created for the Car entity type. See the Define Attributes section in

Example 2: Creating a Concrete Entity Type.


3. In the Property Editor, enter the following values for the fields in the Vehicle

Information panel:

a. In the Vehicle Identification Number field, enter 'A94875'.

b. In the Manufacturer field, enter 'Acme Car Company'.

c. In the Model field, enter 'FastRide GT'.

d. In the Year field, enter '2012'.

e. In the Plate field, enter 'ABC-1234'.

f. In the Number of Passengers field, enter '4'.

4. Click the Save button on the Entity Editor toolbar to save the changes.

Create Entity Relationships

1. Notice that the Property Editor contains Driven By and Owned By panels below the

Vehicle Information panel. These panels correspond to the Driver and Owner

relationship types created for the Vehicle entity type (see the Define Relationship

Types section in Example 1: Creating an Abstract Entity Type). These relationship

types are inherited by the Car entity type.

Expand both panels by clicking their panel expand buttons.


2. In the Driven By panel, do the following:

a. Click the New Relationship button on the toolbar to display the New

Relationship dialog. In the New Relationship dialog, you can search for and

select entities with which you want to create relationships.

b. From the drop-down list in the New Relationship dialog, select 'Full Name'. In

the adjacent field, enter 'Abbey Cata'.


c. Click Search to perform the search.

d. Select the 'ABBEY CATA' entity record from the search results. Click OK to

create the Driven By entity relationship.


3. In the Owned By panel, do the following:

a. Click the New Relationship button on the toolbar to display the New

Relationship dialog.

b. From the drop-down list in the New Relationship dialog, select 'Full Name'. In

the adjacent field, enter 'Colburn Banking'.

c. Click Search to perform the search.

d. Select the first listed 'Colburn Banking' entity record from the search results.

Click OK to create the Owned By entity relationship.


4. The Property Editor should now look as follows. Notice that the previously created

entity relationships now appear in the Driven By and Owned By panels.


Explore Entity Relationships

1. In the Property Editor, select the Relationship Diagram tab to explore the

previously created entity relationships graphically. For more information on this

feature, see Exploring Entity Relationships.

2. On the Relationship Diagram tab, select the A94875 entity node in the entity graph

(top left) panel. Leave the All check box in the filter (top right) panel selected. Click

the Show Related button.


3. The entity graph panel now displays nodes for the 'Abbey Cata' and 'Colburn Banking'

entity records. The arrows between the nodes indicate the entities' Driven By and

Owned By relationships with the A94875 entity. Click each node, and notice that the

details (bottom) panel shows additional details for the entity.

Note: If needed, you can left-click and drag the nodes to rearrange them on the

entity graph. To pan the entity graph, press Shift while left-clicking and dragging the

graph. To rotate the entity graph, press Ctrl while left-clicking and dragging the

graph.


Appendix B: Legal Information Copyright © 1997 - 2012 DataFlux Corporation LLC, Cary, NC, USA. All Rights Reserved.

DataFlux and all other DataFlux Corporation LLC product or service names are registered trademarks or trademarks of, or licensed to, DataFlux Corporation LLC in the USA and other countries. ® indicates USA registration.

The scanning, uploading, and distribution of this book via the Internet or any other means without the permission of the publisher is illegal and punishable by law. Please purchase only authorized electronic editions and do not participate in or encourage electronic piracy of copyrighted materials. Your support of others' rights is appreciated.

DataFlux Legal Statements

DataFlux Solutions and Accelerators Legal Statements

DataFlux Legal Statements

Apache Portable Runtime License Disclosure

Copyright © 2008 DataFlux Corporation LLC, Cary, NC USA.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Apache/Xerces Copyright Disclosure

The Apache Software License, Version 3.1

Copyright © 1999-2003 The Apache Software Foundation. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: "This product includes software developed by the Apache Software Foundation (http://www.apache.org)." Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear.

4. The names "Xerces" and "Apache Software Foundation" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected].

5. Products derived from this software may not be called "Apache", nor may "Apache" appear in their name, without prior written permission of the Apache Software Foundation.

THIS SOFTWARE IS PROVIDED "AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT

LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


This software consists of voluntary contributions made by many individuals on behalf of the Apache Software Foundation and was originally based on software copyright (c) 1999, International Business Machines, Inc., http://www.ibm.com. For more information on the Apache Software Foundation, please see http://www.apache.org.

Boost Software License Disclosure

Boost Software License - Version 1.0 - August 17, 2003

Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the "Software") to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following:

The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

DataDirect Copyright Disclosure

Portions of this software are copyrighted by DataDirect Technologies Corp., 1991 - 2008.

Expat Copyright Disclosure

Part of the software embedded in this product is Expat software.

Copyright © 1998, 1999, 2000 Thai Open Source Software Center Ltd.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,

DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

gSOAP Copyright Disclosure

Part of the software embedded in this product is gSOAP software.

Portions created by gSOAP are Copyright © 2001-2004 Robert A. van Engelen, Genivia inc. All Rights Reserved.

THE SOFTWARE IN THIS PRODUCT WAS IN PART PROVIDED BY GENIVIA INC AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

IBM Copyright Disclosure

ICU License - ICU 1.8.1 and later [used in DataFlux Data Management Platform]


COPYRIGHT AND PERMISSION NOTICE

Copyright © 1995-2005 International Business Machines Corporation and others. All Rights Reserved.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, provided that the above copyright notice(s) and this permission notice appear in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting documentation.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder.

Microsoft Copyright Disclosure

Microsoft®, Windows, NT, SQL Server, and Access, are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Oracle Copyright Disclosure

Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates.

PCRE Copyright Disclosure

A modified version of the open source software PCRE library package, written by Philip Hazel and copyrighted by the University of Cambridge, England, has been used by DataFlux for regular expression support. More information on this library can be found at: ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/.

Copyright © 1997-2005 University of Cambridge. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Neither the name of the University of Cambridge nor the name of Google Inc. nor the names of their

contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR

IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Red Hat Copyright Disclosure

Red Hat® Enterprise Linux®, and Red Hat Fedora™ are registered trademarks of Red Hat, Inc. in the United States and other countries.


SAS Copyright Disclosure

Portions of this software and documentation are copyrighted by SAS® Institute Inc., Cary, NC, USA, 2009. All Rights Reserved.

SQLite Copyright Disclosure

The original author of SQLite has dedicated the code to the public domain. Anyone is free to copy, modify, publish, use, compile, sell, or distribute the original SQLite code, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any means.

Sun Microsystems Copyright Disclosure

Java™ is a trademark of Sun Microsystems, Inc. in the U.S. or other countries.

USPS Copyright Disclosure

National ZIP®, ZIP+4®, Delivery Point Barcode Information, DPV, RDI, and NCOALink®. © United States Postal Service 2005. ZIP Code® and ZIP+4® are registered trademarks of the U.S. Postal Service.

DataFlux is a non-exclusive interface distributor of the United States Postal Service and holds a non-exclusive license from the United States Postal Service to publish and sell USPS CASS, DPV, and RDI information. This information is confidential and proprietary to the United States Postal Service. The price of these products is neither established, controlled, or approved by the United States Postal Service.

VMware

VMware® virtual environment provided those products faithfully replicate the native hardware and provided the native hardware is one supported in the applicable DataFlux product documentation. All DataFlux technical support is provided under the terms of a written license agreement signed by the DataFlux customer.

The VMware virtual environment may affect certain functions in DataFlux products (for example, sizing and recommendations), and it may not be possible to fix all problems.

If DataFlux believes the virtualization layer is the root cause of an incident; the customer will be directed to contact the appropriate VMware support provider to resolve the VMware issue and DataFlux shall have no further obligation for the issue.

DataFlux Solutions and Accelerators Legal Statements

Components of DataFlux Solutions and Accelerators may be licensed from other organizations or open source foundations.

Apache

This product may contain software technology licensed from Apache.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

See the License for the specific language governing permissions and limitations under the License.

Creative Commons Attribution

This product may include icons created by Mark James http://www.famfamfam.com/lab/icons/silk/ and licensed under a Creative Commons Attribution 2.5 License: http://creativecommons.org/licenses/by/2.5/.

Google Web Toolkit

This product may include Google Web Toolkit software developed by Google and licensed under the Apache License 2.0.


JDOM Project

This product may include software developed by the JDOM Project (http://www.jdom.org/).

OpenSymphony

This product may include software technology from OpenSymphony. A copy of this license can be found here: http://www.opensymphony.com/osworkflow/license.action. It is derived from and fully compatible with the Apache license that can be found here: http://www.apache.org/licenses/.

Sun Microsystems

This product may include software copyrighted by Sun Microsystems, jaxrpc.jar and saaj.jar, whose use and distribution is subject to the Sun Binary code license.

This product may include Java Software technologies developed by Sun Microsystems,Inc. and licensed to Doug Lea.

The Java Software technologies are copyright © 1994-2000 Sun Microsystems, Inc. All rights reserved.

This software is provided "AS IS," without a warranty of any kind. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. DATAFLUX CORPORATION LLC, SUN MICROSYSTEMS, INC. AND THEIR RESPECTIVE LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN MICROSYSTEMS, INC. OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN MICROSYSTEMS, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Java Toolkit

This product includes the Web Services Description Language for Java Toolkit 1.5.1 (WSDL4J). The WSDL4J binary code is located in the file wsdl4j.jar.

Use of WSDL4J is governed by the terms and conditions of the Common Public License Version 1.0 (CPL). A copy of the CPL can be found here at http://www.opensource.org/licenses/cpl1.0.php.

dataflux qmdm solution - sas · 2016-12-20 · dataflux qmdm solution user's guide i contact...

Documents