10.2 Metadata and IEBI
10.2 Metadata and IEBI Given that metadata provides meaning to data, we can certainly understand that metadata is used throughout the entire life cycle of any system, from analysis and design through construction and implementation. Ultimately, metadata comes into play in the day-to-day use of the system. The nature of IEBI gives an added importance to metadata. As we have said throughout this book, IEBI systems are distinct in their nature from traditional Enterprise Resource Planning (ERP) systems. This difference amplifies the need for quality metadata. If we were to place metadata importance on a scale of 1 to 10, in a traditional ERP system we might give it a 6 or 7. Sure, metadata is important, but it wasn't necessarily critical in ERP systems. The metadata may not have been of the best quality, if it was present at all, yet these systems operated just fine. The lack of metadata was really a burden on the shoulders of those maintaining the system. In IEBI, however, metadata would rate a 9 or 10. Metadata is important to the designers and developers as well as to those who use the system on a daily basis. Figure 10.1 presents the flow of data through an IEBI system. This data flow differs from the data flows presented in previous chapters. In this figure we have added the flow of metadata through the system. In examining this data flow, we see how metadata is used in the flow of information from the operational system to the business strategist. Most of this is what we would expect to see. Metadata is the basis for the Extraction, Transformation, and Loading (ETL) processes that incorporate the operational data into the data ware house. It defines the mapping of the data from the source to the target. The transformation of the data also uses metadata to define the domain of values for a particular field in both the source and target systems. Figure 10.1. Metadata in IEBI. What is unique about IEBI? Why is metadata so much more important to the data warehouse? One might argue that every system receives input. Is it simply that the data warehouse input comes from another information system? Actually, it is that the data comes for many other systems. Figure 10.1 shows the incorporation of more than mere data into the data warehouse. Metadata is also brought into the data warehouse to form a central metadata repository. Even in the best of situations, where we have a single instance upon which the operational system is based, we still have to deal with conflicting metadata. Figure 10.2 illustrates this point. The figure presents an international organization in which the data warehouse derives customer data from Accounts Receivable (A/R) from both Germany and the United States. The system also receives customer information from an external source, let us say a system that provides demographic data. It should be a simple matter to compile all this data into one system. Note the difference, though, in the address. In Germany, the address is composed of a province rather than a state. The domain of valid provinces is different from those of valid states. We can also see that the way in which the address is stored for the external system is different from the addresses received from the A/R system. Figure 10.2. Metadata use in the ETL process. These issues are resolved within the metadata. It is within the metadata that we devise a consensus on the meaning of the data. Ultimately, the various definitions from each separate system, along with the mapping of the source to the target, are stored in the central metadata repository. Metadata is also of critical importance to another IEBI system user: the business strategist. In traditional operational environments, the user may have little or no concern for metadata. He or she is probably satisfied with knowing the format of the data and the domain of acceptable values. The business strategist, however, is often just as concerned with the metadata as with the data itself. While the strategist may not describe his or her needs as being metadata, he or she typically asks questions answered only by metadata. What is the source of the data? When was this data collected? What elements does this data include? This is all metadata. If we think about it, we can see that metadata is used in the very construction of the reports and analyses developed by the business strategist. The strategist selects data from the data warehouse by specifying the parameters of the report or query. These parameters are metadata. In addition to drilling into the data itself, the strategist may also be interested in drilling into the metadata. He or she might drill to the source of the data displayed on the screen or when it was extracted from the source system. In Chapter 2, I referred to a time when I had to justify the cost of a BI system to a board of directors. During the presentation, I put up my matrices of data showing the cost of the current system and the remarkable savings incurred through implementation of its replacement. As I stood up there sweating in front of them (this was the culmination of 10 months' work), I was grilled by the CEO. "Where did you get these numbers?" "How was that computed?" He was asking for the metadata. Imagine if I had this displayed in some ad hoc query tool. With each question, I would be able to simply select the data item and drill down into the data's metadata. Imagine the strength of the data if right then and there I was able to validate the data on the screen. In addition to showing the actual numbers, I could present the way in which the numbers were calculated as well as the history of the data, such as its source and age. |
 | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 113