Meta Data Repository as Navigation Tool

Meta data is not new; it has always been part of operational systems. It can be found in systems documentation, record layouts, database catalogs, and data declaration sections in programs. The role of meta data in an operational environment was always viewed as systems documentation, which was mainly used by the technicians who maintained the operational systems. When some of the systems documentation (meta data) became outdated , the technical staff had enough skills to read through the actual programming code to extract the information they were looking for, such as the meaning and content of a data element. Thus, more often than not, meta data was treated as an afterthought.

In a BI decision-support environment, meta data takes on a new level of importance. A new audience has to be serviced, namely, the business people. Meta data helps them locate, manage, understand, and use the data in the BI target databases. Meta data has a new role: navigation, not just documentation. Business people ordinarily do not have the technical skills, nor the time or desire , to decipher programming code. They also do not want to stay dependent on the IT department to interpret the meaning and content of the data after it has been manipulated by the programs. Rather than calling a programmer, a business person should be able to access the meta data, which would then help him or her effectively navigate through the BI decision-support environment and interpret the BI data. As illustrated in Figure 7.1, meta data describes what data is available in which BI target database, where the data came from, how to access it, how to drill down to the detailed data for closer examination, and how to use it.

Figure 7.1. Using a Meta Data Repository as a Navigation Tool

Data Standardization

If business data had been stored and used in a consistent, approved manner all along, the data redundancy and inconsistency problems that currently plague many operational systems would not exist to the extent they do today. Unfortunately, bad habits die hard. Developers and business people still explicitly or implicitly reuse the business data in operational systems for different purposes. For example, developers still explicitly redefine data elements in their programs, and business people still implicitly redefine (invent new codes for) existing data elements to capture unrelated information. Documentation of these redefinitions also remains poor or nonexistent. If any documentation exists, it is rarely distributed to everyone in the organization who needs it, and it is very seldom kept up-to-date. Therefore, business people continue to invent their own business rules and create their own redundant data along with redundant processes.

Every BI project team must address this existing data chaos and must make every attempt to promote the standardization of data. While standardizing the business data for the BI decision-support environment, the BI project team should document all changes made to the data so that everyone can be aware of them. This documentation takes the form of meta data in the meta data repository. For example, a source data element could be renamed to conform to new naming standards, or data values could be filtered, added, or transformed to enforce a business rule. In both cases, the BI data in the BI target database would no longer match the source data in the source file or source database. The meta data would provide the navigation between the two.

Using BI applications without knowing that the business data was changed and how it was changed can be a frustrating experience that can eventually end with the business people no longer wanting to use the BI applications at all. That would be devastating since one of the most important aspects of a BI decision-support initiative is to provide an easy-to-use, intuitive way for the business people to access and query the data. An easy-to-use application means the business people:

• Have no need to be relational technology experts

• Have no need to know Structured Query Language (SQL)

• Have no need to know the physical structure of the databases

• Have no need to know the location of their data

• Have no need to guess the meaning of the data

• Have no need to search for the required information