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.
- Download metadata at environment or table level to an excel file and bulk update definitions and re-import the excel
- Enrich metadata in the application at table or column level by manually filling in the definitions for the required technical and business fields
- 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
Project Browser |
Organizing the Project and Mapping browser
|
Metadata Browser |
Organizing and Managing Metadata Metadata is scanned and displayed according to
|
Mapping Grid |
Source to Target Mapping Grid
|
Mapping Tabs |
Mapping Tabs
|
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:
-
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.
# |
Naming Convention |
Mapping Name |
1 |
TargetSysName_SubjectArea Source SysName_MapBusinessName |
IDS_PROV_CAPS- CNY_T_ADJUDICATED_PROVIDERS |
2 |
SourceSysName_TargetSysName_MapBusinessName |
CAPS-CNY_ IDS_ADJUDICATED_PROVIDERS |
3 |
SourceSysName_PhysicaTargetTableName |
CAPS-CNY_ADJUDICATED_PROVIDERS_DIM |
4 |
SourceSysName_MappingBusinessName |
CAPS-CNY_ADJUDICATED_PROVIDERS |
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
Comments
0 comments
Please sign in to leave a comment.