Query: How to Organize Metadata and Mapping Environments in Data Intelligence Suite

Quick Access Sections:

• Organizing the Metadata Browser
• Organizing Projects and Subjects Areas
• Naming Conventions for Mappings

Organizing the Metadata Browser

There are two options for scanning metadata. Logical representation vs physical representation and organization of Enterprise Data Glossaries

Recommended Naming Conventions

• Physical Organization of Data Glossaries & Naming Conventions:

Use the same naming conventions already in place by DBA’s

System Name: Full System Name (e.g. EDW or Enterprise Data Warehouse, Customer Order Entry or COE) Environment name: Use standard naming conventions already in place to identify these environments (e.g. EDW-PRD, EDW-TEST, EDW-DEV etc.).

• Logical (Subject Area) Organization of Data Glossaries & Naming Conventions:

Organizing metadata into subject areas or groupings of tables is intended to make navigation for uses and data discovery easier. For Example, Facets healthcare system has over 2,000 tables broken into multiple subject areas (members, plan, network providers etc.).

System Name: Full System Name (e.g. Facets)

Environment Name: Environment names can be tied to subject areas such as

• Members
• Plan
• Providers
• Networks

Maintaining and Enriching Data Glossary Values

There are 3 ways to enrich and maintain business glossary values.

1. Download metadata at environment or table level to an excel file and bulk update definitions and re-import the excel
2. Enrich metadata in the application at table or column level by manually filling in the definitions for the required technical and business fields
3. Scan business definitions by scanning metadata from Modeling Tools like erwin, ER Studio

Introduction to Mapping Manager Module

The Mapping Manager Module provides an integrated view of Data Mappings, Metadata, Lineage and Impact Analysis.

1.     Project and Mapping Browser

Enables grouping and categorizing of mappings for fast navigation to mappings organized by project and subject areas.

2.     Metadata Browser

Provides central access to all Data Glossaries across the organization. Metadata can be scanned and organized either physically or logically according to logical schema or subject area groupings.

3.     Mapping Specification (Source to Target Mappings)

Enables customized viewing and editing of the source to target mapping specifications via an editable “excel- like” data mapping grid.

4.     Mapping Specification Detail Tabs

Enables customized views of extended attributes and processes to be managed alongside of the data mappings. The Detail tabs are configurable by customers.

Better Organization and Management of Data Glossaries (Technical Metadata) and Data Mappings

Organizing the Project & Mapping Browser

There is no wrong way of grouping and categorizing mappings. Projects and subject areas can be created to group and categorize data mappings according to customer’s needs.

The objective of grouping and categorizing mappings is to enable quick navigation to the data mappings for end users.

We recommend organizing a consistent naming convention and strategy for

• Projects
• Subject Areas
• Data Mapping

 Here are some of the best practices organizations are following with regard to grouping and categorizing mappings and the naming conventions they are using.

Creating Projects & Subject Areas

Projects can be named however customers choose, however we recommend coming up with some guidelines. We recommend Projects be defined according to target system or business initiative such as:

Project Names:

• Data Warehouse Project Name
• ODS Project Name
• Data Conversion Project Name
• External Data Feed / Customer/Vendor Name
• Blue Health Initiative (BCBS Association Outbound file data)
• SWIFT ISO Financial Conversion

Subject Areas:

Subject areas are used as a means to further group and categorize mappings beneath Projects. We recommend the following considerations when creating subject areas:

1. Logical subject areas

Recommended to group mappings of large systems according to subject areas so you can see all mappings which are related to that subject area. Consider the following where a large data Warehouse may be grouped into multiple subject areas such as:

• Members
• Providers
• Products
• Claims
• Etc

        2. Contributing source system

Recommended when many source system are feeding a target system or project and many mappings are involved within the subject area.

Creating Nested Subject Areas for further Grouping and Categorization

If you have many mappings which can “logically” be grouped under common categories nested subject areas can be created.

Consider creating nested subject areas when many mappings can be grouped by:

• Multiple contributing source systems
• Multiple business initiatives
• Business Partners (one or more business partners exchange many data mappings etc.).

Organizing “Nested” Subject Areas: Logical Subject Area Organization

Naming conventions for mappings

Although the mappings in the mapping manager can be used as flexibly as Microsoft Excel, we recommend creating your mappings based on a single target table basis (e.g. Meaning 1 mapping per target table being loaded).

Note: you can create single mapping with many source and many targets in a single mapping. The system allows for this capability).

As a best practice, it is RECOMMENDED to have a consistent naming convention used for naming mappings. The mapping name “ideally” should have business meaning to the reader. We recommend the following considerations when defining your mapping naming conventions:

1. Name Mapping should be comprised of a combination (One or More) of the following:

• TARGET SYSTEM NAMING (ABBREVIATED ACRONYM)
• SUBJECT AREA NAME (ABBREVIATED ACRONYN)
• SOURCE SYSTEM NAME (ABBREVIATED ACRONYM)
• MAPPING BUSINESS NAME (BASED ON TARGET TABLE/FILE BEING LOADED)
• PHYSICAL TABLE NAME (PHYSICAL NAME OF TARGET TABLE)

2. Recommended Naming Conventions to Consider:

erwin, Inc. recommends #1 below for fast readability and comprehensive understanding of the mapping logic based on the mapping name. The naming convention works really well if you have multiple mappings from several disparate source systems loading data to a single target table.

• Consider a Data Warehouse being fed data by 7 membership systems and loading data to a single membership table in the data warehouse. The naming convention will allow fast sorting based on contributing source systems and target table/mapping name.

Mapping Naming Convention Good Practice Example:

In the example below you can quickly see which mappings in the projects and subject areas are loading data from various systems. The EDW Products subject area is being loaded from the IDW Source and the business data is Benefits Detail.

By using consistent naming conventions you can also see the mappings in the PRODUCT subject are loading not only the EDW but also the IDS System/Environment. This information is easily understood by the consistent use of the naming convention used.

Mapping Naming Convention follows: Target_SubjectArea_Source_MappingBusinessName

•  Mapping Name = EDW_PROD_IDS_Benefits_Detail