Principles and Rules for Section → Metadata Management
|
|
| This page presents the list of field tips which are relevant to the current section. For the complete listing of Field Tips, please go to Field Tips Home Page |
|
To filter your listing for a specific section, please click the relevant hyperlink : |
| Execution Making-it-Happen -
Discipline of Execution → 'Executable' Strategy → Focus & Money-Machine → 'Value' management → 'Capabilities' management → Execution Intensity → Human Capital → Resilience & Flexibility → Anticipation & Intelligence → Execution Scorecard → Leadership & Work-Discipline → Entraprenurial Execution → |
| Enterprise Intelligence -
BI End-to-End → Data Quality → Data-Warehouse/Mart → Data Analysis/OLAP → Metadata Management → |
| Functional Management -
Customer Management → Sales & Distribution → |
| Vendor- IT Tool Domain -
Vendor-tool Evaluation → BI End User Tools → BI platform Tools → Data Management Tools → |
|
|
|
|
|
|
Enabling Metadata Generation for Unstructured Content
|
Unstructured content in an organization is typically the last phase of evolution of a metadata environment. Most of the unstructured content is linked to business metadata. You can use various tools for content management, collaboration management and business process management to enable automatic generation of Metadata. There are some more basic methods like using shared drives and encouraging standard templates.
|
|
| |
| |
|
New Data Standards- What about existing data and applications?
|
As an organization develops enterprise level data standards, it has to figure out the approach and plan for existing data and applications. One cannot have a big-bang conversion approach. Data Steward needs to drive a road-map, which focuses on the business case driven priorities, and also does a piggy-back on the mega IT initiatives.
|
|
| |
| |
|
How to integrate stand-alone BI environments- Gradual Approach
|
We recommend to go for phased approach for BI environment integration against a big-bang method. The reasons are lack of business and IT stamina, testing our assumptions, maintain stability and to develop our expertise. The phased approach should first go for integrating the plumbing work like ETL, followed by more front-end integration.
|
|
| |
| |
|
Which Metadata Architecture to use and when
|
Organizations have failed in the past to have integrated physical metadata repository, due to the reasons of technology diversity, lack of standards and sheer lack of stamina. As independent and multiple metadata repositories get developed, the more realistic solution is to have integration of these repositories while allowing them to function independently.
|
|
| |
| |
|
Don't rely too much on Meta Data Tools to enforce Business Intelligence
|
Meta Data Tools in today's world have great capabilities , however it
is safer to have the business rules enforced through the dimensional
models and databases within OLAP, Staging and Data Warehouse.
|
|
| |
| |
|
Do not separate the parent and child line item data
|
In cases like invoice, purchase orders and Job Card, there are header items
and detailed items. One should always combine both the levels into a single
fact table.
|
|
| |
| |
|
Always Use Conformed Dimensions
|
Conformed Dimensions concept says that if you have a customer dimension, the
contents of the dimensional table, the name of the dimension and its attributes,
data structures, key assignment etc should be exactly the same. In other words,
there should not be two different customer dimensions in the same data warehouse.
|
|
| |
| |
|
Dimensional model has to be aligned to the Entity-Relationship
|
The cardinality of relationship between any two entities (refer entitiy
relationship model ) have to be reflected equally in a dimensional model or
else you will get an information management/business intelligence platform which
is inconsistent with the organization data model
|
|
| |
| |
|
Maintain a trail of the key dimensional elements from source system to loaded
|
Sometime due to specific query needs and for audit-ability of your information,
you would need to maintain a link between source to end information.
|
|
| |
| |
|
Documenting your data-integration system
|
There is no data-integration system, which can fully self-document the data
integration flow and process.
|
|
| |
| |
|
Dimensional models can be extensible and scalable
|
If there are new business requirements which need a change in your current
dimensional model, you may not have to build net set of schemas.
|
|
| |
| |
|
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.
|
|
| |
| |
|
Store as much detailed and granular data in data warehouse as possible
|
DW implementation is a big initiative. The use of data warehouse
is unpredictable and may not be limited to summary level queries and for data
analysis only.
|
|
| |
| |
