Sales Management Customer Relationship Human Resources Business Performance BI & Data Quality IT Tools & Vendors

Sign-in   Register
Establishing 'Making it Happen' as a 'Formal & Predictable' Discipline
Principles and Rules Listing Page

Keep the same names and definitions for all data elements

This tip is basically for not to cut corners, when you are designing your dimensional model. Having some mapping tables to map inconsistent names of same data elements, is an almost criminal short-cut to having same names in the dimensional model design itself.
 
This page of 'Principles and Rules' is linked to:  Data Warehousing, Data Analysis/OLAP, BI platform Tools Evaluation, Metadata Management, Core Data Management Tools,

Sometimes the same data element carries different names in different dimensional tables, due to the following reasons..

  • Inconsistencies in data element names in source systems is so huge (like the same customer ID data element is named in ten different ways in ten different tables- cust_ID, CustomerID, C_ID..).
  • There being multiple teams designing different parts of the dimensional models.
  • Your dimensional model having evolved over time.

To accelerate the DW project, you may create a mapping table in metadata which can link these different names. You do it as you don't want to disturb your transformation routines, and want to have an alternate method to align your dimensional models.

The reason you should not do this is:

  • Data warehouse is storehouse. People may or may not choose to refer to the mapping tables or Meta-data definitions. This may severely impact the potential of DW, especially when you need drill across capabilities.
  • With field-names being different, you will end up having more transformation and loading routines to create and run.
  • The maintenance of dimensional model becomes more complex over time.
  • You end up promoting the culture of inconsistent naming in the DW and source system.

Benefits of same names and definitions across all schemas

  • High productivity: Same names mean that there is no confusion and same queries can be used in different schemas.
  • Automated joins across schemas: As you might see in the multi-cube architecture, you can join two schemas if they share a common dimension. With same names, it becomes easier to create these joins.

A good naming strategy has to be:

  • Intuitive and consistent: the naming approach should be easily understood and should be applied universally.
  • Extendible: With new facts and dimensions and attributes, the naming structure should be able to absorb these changes.
  • Easy to understand: Names should not be too cryptic. The names should be more in a business like language (Use Customer_ID instead of Cusid)
  • Should have identifiers linked to the business process, the dimension, fact table to which it belong etc.

Naming strategy should be defined by the dimensional modeling team as they have a got a wide view of all the dimensions and fact tables involved. Post the first draft, we have to go through the iterative process of fine-tuning given the feedback from business, technical and information managers.


Quick Feedback- Was this information helpful ?
Relevant Links to this page
Principles & Rules → Add extra buffer for ETL phase → Principles & Rules → Homework before interviews is must (Business Requirements Phase in Data Warehouse) → Principles & Rules → Excel is the competition, which should be challenged → Principles & Rules → Avoid Pure MOLAP → Practice Techniques → Field Tips Series- Streamlining & Cost-Reduction in Business Intelligence- Consolidate Data-Marts → Practice Techniques → Field Tips Series- Streamlining & Cost-Reduction in Business Intelligence- Licensing & Maintenance Contracts → Practice Techniques → Field Tips Series- Streamlining & Cost-Reduction in Business Intelligence- Governance & Standards → Practice Techniques → Field Tips Series- Streamlining & reducing cost of Business Intelligence- Evaluate Open Source → Principles & Rules → Master Data Management- Making a Right Start → Practice Techniques → How to integrate stand-alone BI environments- Gradual Approach → Principles & Rules → Business owned applications are a reality- Manage it → Principles & Rules → New Data Standards- What about existing data and applications? → Principles & Rules → Handle Each Time-stamp in the Fact Table as a separate dimension → Principles & Rules → Keep Aggregates and Details data in different Fact tables → Principles & Rules → Some considerations for Infrastructure in Data Warehouse → Principles & Rules → For Core BI platform go for a single, established and robust player → Principles & Rules → Don't be guided only by the business requirements for your Business Intelligence → Practice Techniques → Using Synonyms and Views → 
 
Back
 
Relevant links to this page
Add extra buffer for ETL phase
Homework before interviews is must (Business Requirements Phase in Data Warehouse)
Excel is the competition, which should be challenged
Avoid Pure MOLAP
Field Tips Series- Streamlining & Cost-Reduction in Business Intelligence- Consolidate Data-Marts
Field Tips Series- Streamlining & Cost-Reduction in Business Intelligence- Licensing & Maintenance Contracts
Field Tips Series- Streamlining & Cost-Reduction in Business Intelligence- Governance & Standards
Field Tips Series- Streamlining & reducing cost of Business Intelligence- Evaluate Open Source
Master Data Management- Making a Right Start
How to integrate stand-alone BI environments- Gradual Approach
Business owned applications are a reality- Manage it
New Data Standards- What about existing data and applications?
Handle Each Time-stamp in the Fact Table as a separate dimension
Keep Aggregates and Details data in different Fact tables
Some considerations for Infrastructure in Data Warehouse
For Core BI platform go for a single, established and robust player
Don't be guided only by the business requirements for your Business Intelligence
Using Synonyms and Views
Additional Channels
Principles & Rules
Free Templates
Glossary
Key Performance Indicators

Most Popular Zones with list of pages crossing 25000 hits  →→→ 
Maximising Sales Performance
Sales Compensation for Consistency
Sales force Training and Development
Sales Compensation administration
Variable Sales Cost
Sales Leads Management Concept
Read more...
  Customer Relationship Management
Customer Value and Profitability Data Management
Customer Value and Profitability Tips and Actions
Customer Knowledge and Organizational Knowledge
Exit barriers for Customer Retention
Customer Segmentation approach
Read more...
  Human Resources & Leadership
Developing Leaders- Few Leadership Traits
Customer Focus
Lead Change
Give feedback closer to the observation
Maximize the output first and then the potential
Read more...
 
 
Business Performance & Planning
Review Session should stay focused
A KPI should be simple -but it depends
Shifting the mind-set to leading Indicators- KPIs
Dashboard Health Checklist
Strategy Map Objectives Measures and Initiatives
Read more...
  Business Intelligence & Data Quality
Data Quality Organization Roles
Do not separate parent and child data
Data Warehouse Benefits Usage
Master Data Management
Data Warehouse Design and Architecture Overview
Read more...
  IT Vendors & Tools Management
OLAP Dimensional Model Change Management
Vendor Delivery Evaluation Governance
Data Integration Metadata Management
OLAP Scalability
OLAP Sever Database Tuning
Read more...