Moss L.T., Atre S. Business intelligence roadmap: The complete project lifecycle for decision-support applications
Подождите немного. Документ загружается.
[ Team LiB ]
Bibliography and Additional Reading
Adelman, Sid, and Larissa Terpeluk Moss. Data Warehouse Project Management.
Boston, MA: Addison-Wesley, 2000.
Aiken, Peter H. Data Reverse Engineering: Slaying the Legacy Dragon. New York:
McGraw-Hill, 1995.
Brackett, Michael H. Data Resource Quality: Turning Bad Habits into Good Practices.
Boston, MA: Addison-Wesley, 2000.
———. The Data Warehouse Challenge: Taming Data Chaos. New York: John Wiley &
Sons, 1996.
Hackney, Douglas. Understanding and Implementing Successful Data Marts. Reading,
MA: Addison-Wesley, 1997.
Imhoff, Claudia, Lisa Loftis, and Jonathan G. Geiger. Building the Customer-Centric
Enterprise: Data Warehousing Techniques for Supporting Customer Relationship
Management. New York: John Wiley & Sons, 2001.
Kimball, Ralph, and Richard Merz. The Data Webhouse Toolkit: Building the Web-
Enabled Data Warehouse. New York: John Wiley & Sons, 2000.
Kimball, Ralph, Laura Reeves, Margy Ross, and Warren Thornthwaite. The Data
Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and
Deploying Data Warehouses. New York: John Wiley & Sons, 1998.
Ponniah, Paulraj. Data Warehousing Fundamentals: A Comprehensive Guide for IT
Professionals. New York: John Wiley & Sons, 2001.
Sperley, Eric. The Enterprise Data Warehouse: Planning, Building, and
Implementation. Upper Saddle River, NJ: Prentice Hall, 1999.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
301/631
[ Team LiB ]
Chapter Ten. Step 10: Meta Data
Repository Design
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
302/631
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
303/631
Chapter Overview
This chapter covers the following topics:
Things to consider when designing a meta data repository or when evaluating
meta data repository vendor products
How the shortcomings of early meta data initiatives contributed to failures to
effectively manage meta data
The multitude of meta data sources we now have to manage in a BI decision-
support environment
The advantages and disadvantages of three different types of implementation
strategies: a centralized meta data repository, either built or licensed (bought);
a decentralized meta data repository; and a distributed meta data solution
enabled through the use of Extensible Markup Language (XML) tags
The advantages and disadvantages of two different types of meta data
repository designs: an entity-relationship (E-R) design and an object-oriented
(OO) design
Detailed examples of the product and vendor evaluation process
Brief descriptions of the activities involved in meta data repository design, the
deliverables resulting from those activities, and the roles involved
The risks of not performing Step 10
Things to Consider
Existing Meta Data Repository
Do we already have a meta data repository?
Do we have to expand it? Do we have to add more meta data
components? Or expand the functionality?
Who is keeping the meta data repository up-to-date?
Who is using it? How are they using it? What parts of the meta data
repository are they using?
Do they like it? Are there any complaints?
If we do not have a meta data repository, how are we coping
without one?
Why do we not have one? Lack of budget? Lack of resources? Lack
of understanding?
Meta Data Repository Products
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
304/631
Are there meta data repository products that will satisfy our meta
data requirements? Or do we have to build a meta data repository
from scratch?
How many of our meta data requirements cannot be satisfied by
the meta data repository products on the market? How important are
those meta data requirements?
Can the meta data repository products be enhanced to meet those
specific meta data requirements?
Which meta data repository products have import and export
capabilities?
Interfaces
How will we automate the interfaces from the meta data repository
to other tools that have their own meta data dictionaries, for example,
computer-aided software engineering (CASE), extract/transform/load
(ETL), and online analytical processing (OLAP) tools? Will we have to
buy additional middleware?
Do the other tools from which we have to extract meta data have
import and export capabilities? Are those tools XML-enabled?
How will we deliver the meta data to the business people? Through
reports? Through a help function? Through a Web interface?
Will it be hard for the business people to learn how to use the meta
data repository interfaces? What training do we have to develop?
Staffing
Will we need more staff to install, enhance, and maintain a licensed
meta data repository product?
Will we need more staff to design, build, and maintain our own
custom-built meta data repository?
The term meta data is not new, and efforts to manage meta data are not new either.
What is new is the increased awareness that meta data is an important extension to
business information and that managing meta data is therefore mandatory. Another
important recognition is that new tools and techniques for managing meta data are
needed—and are becoming available.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
305/631
[ Team LiB ]
Meta Data Silos
Data administrators have tried to inventory, define, and organize meta data since
the early 1980s. Most data administrators used generic data dictionary products
(meta data repositories used to be called data dictionaries); only few tried to design
and build their own. Some of the generic data dictionary products were rather
sophisticated and expandable, and they could store most of the required meta data
components. However, there were multitudes of problems associated with these
early efforts.
Populating these early data dictionaries required a manual effort, which was
time consuming and tedious, as all manual efforts are.
The lack of technical skills on the part of most data administrators prevented
them from expanding the data dictionary products with custom features to
make them more useful.
The reporting capabilities of the early data dictionary products were less than
desirable. Some products did not even have application programming interface
(API) capabilities that would allow data administrators to generate customized
reports.
The immature technologies used in most early data dictionaries (which were
mainframe products) did not provide automated interfaces, easy-to-use
graphical user interface (GUI) displays, or context-sensitive help functions.
The lack of standards (or the lack of enforcement of standards) created an
insurmountable burden for the data administrators who had to resolve
conflicting and inconsistent data names, data definitions, and data domains.
No management appreciation for the value of meta data made meta data a low
priority in most organizations. Business managers and business executives, as
well as some information technology (IT) managers, viewed meta data as
systems documentation, which they considered important but could live
without.
No cross-organizational initiatives existed in organizations, except departmental
initiatives usually spearheaded by data administrators in IT. Therefore, many
business managers and business executives did not understand the value of the
effort and did not buy into it. The popularity of data warehouse initiatives in the
1990s helped raise the understanding of the value of cross-organizational
initiatives.
Because of these problems, data administration efforts to manage meta data were
only marginally successful in the past. On many projects, these efforts were even
considered project obstructions because of the extra time it took to define and
capture the meta data when the technicians were eager to rush into coding. IT
managers and business managers often asked, "Why aren't we coding yet?
"—obviously, they perceived writing programs as the only productive project
development activity.
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
306/631
Sources of Meta Data
It was not until the advent of cross-organizational BI initiatives and the associated
plethora of BI tools that meta data started to receive its proper recognition. People
began to realize that these BI tools, with their own sets of meta data in their own
proprietary dictionary databases, were creating the all-too-familiar problems of
redundancy and inconsistency, only this time with meta data. Knowledge workers,
business analysts, managers, and technicians were getting very frustrated with the
tangled web of meta data silos (Figure 10.1).
Figure 10.1. Meta Data Silos
Meta data cannot be avoided, especially technical meta data, because database
management systems (DBMSs) and most tools do not function without it. It is their
"language." For example, meta data instructs the DBMS what type of database
structures to create, tells the ETL tool what data to transform, and lets the OLAP tool
know how to aggregate and summarize the data. Different meta data components
are stored in different tools, and none of the tools (except a meta data repository) is
designed to store all the other meta data components from all the other tools. For
example:
CASE tools store the business meta data for the logical data model components
and the technical meta data for the physical data model (logical database
design) components.
DBMS dictionaries store the technical meta data for the database structure,
such as databases, tables, columns, indices, and so on.
ETL tools store the technical meta data about source-to-target data mappings
and the transformation specifications, which are used by these tools to perform
their ETL processes.
Data-cleansing tools store the business meta data for data domains and for
business rules that allow these tools to identify data quality problems. They also
store the cleansing specifications, which are used by these tools to perform
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
307/631
their data-cleansing functions.
OLAP tools store the technical meta data of the tables and columns in the BI
target databases, the report definitions, and the algorithms for deriving,
aggregating, summarizing, and in other ways manipulating BI data.
Data mining tools store the technical meta data about the various analytical
models and the algorithms for the data mining operations.
As with vendors of other relatively new software and middleware product lines, the
vendors of meta data repository products are competing for dominance, which slows
down standardization of the product line. As a result, organizations end up with a
tangled web of disparate and distributed meta data scattered across the proprietary
dictionaries of their tools. To manage this situation, they now have to extract,
merge, and accurately integrate meta data from these tool dictionaries, which can be
as much of a challenge as extracting, merging, and accurately integrating business
data from the operational systems.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
308/631
[ Team LiB ]
Meta Data Repository Solutions
The solution to meta data silos is clearly an enterprise-wide meta data repository
approach. This can be accomplished in one of three ways:
One centralized meta data repository database solution1.
A decentralized meta data solution that uses one integrated meta model but
physically distributes the meta data across multiple databases
2.
A distributed XML-enabled solution in which the meta data is XML-tagged and
stored (kept) in the different types of proprietary tool dictionaries on different
platforms
3.
Regardless of which meta data repository solution is
chosen, meta data repository projects and subprojects
are large and costly. Therefore, any meta data repository
solution should be built in iterations.
Centralized Meta Data Repository
A centralized meta data repository is the most popular solution and the easiest to
implement because there is only one database, either relational or object-oriented,
and only one application to maintain (Figure 10.2).
Figure 10.2. Centralized Meta Data Repository
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
309/631
Updating the meta data repository does not have to be coordinated across
databases, and retrieving the meta data from the repository can easily be
accomplished with a simple GUI front end or Web application. A centralized meta
data repository solution can either be custom built or licensed from a vendor.
Custom-built repository: Designing and building a customized centralized
meta data repository is an alternative that should be considered. Since the
meta data repository solution should be enterprise-wide, the meta models
(both logical and physical) will be generalized and not application-specific. This
means that there will not be a meta data repository for a marketing application
and another one for a sales application; instead, there will be one centralized
meta data repository for all applications. The advantages and disadvantages of
building a customized centralized meta data repository are similar to those of
building a customized business application (Table 10.1).
Table 10.1. Advantages and Disadvantages of a
Custom-Built Centralized Meta Data Repository
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
310/631