Moss L.T., Atre S. Business intelligence roadmap: The complete project lifecycle for decision-support applications

Подождите немного. Документ загружается.

Advantages

Disadvantages

A customized database

design incorporates all

meta data requirements.

Full-time staff is needed to

maintain the meta data

repository database and the

meta data reports.

The front end for access

and the interfaces to tools

(ETL, OLAP, and so on) are

custom designed to meet

all requirements.

The front end for access and

the interfaces to tools must be

programmed and maintained,

both of which are time-

consuming processes.

Reports as well as help

functions are designed

exactly as desired.

The meta data repository

would have to be enhanced

periodically (sometimes

redesigned) because it cannot

be built with all functionality

from the start.

Technicians have full

control over the design and

functionality of the meta

data repository.

Content may become out of

synch with the proprietary

dictionaries of the tools and

the DBMS.

Licensed repository: Licensing (buying) a centralized meta data repository

product is an attractive alternative to building one. Losing some of the benefits

inherent in a customized solution is offset by gaining the advantages that come

with licensing a vendor product (Table 10.2).

Table 10.2. Advantages and Disadvantages of a Licensed

Centralized Meta Data Repository

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

311/631

Advantages

Disadvantages

Time is saved by not having

to design and build a meta

data repository database,

interfaces, front end, and

reports.

The "plain vanilla" version of the licensed

product will probably not satisfy all meta

data requirements. Therefore, a full-time

administrator is needed to maintain and

enhance the licensed product.

Most licensed meta data

repository products come

with interfaces, and most

come with a full set of APIs.

There will be a learning curve to become

familiar with the product's architecture,

interfaces, and APIs.

If the meta data repository

product is certified for the

tools where the meta data

resides, it will provide the

tool interfaces.

The more sophisticated the meta data

repository product is, the more expensive it

is, and the more skills the technicians need

to maintain it.

Decentralized Meta Data Repository

As the term implies, a decentralized meta data repository solution stores the meta

data in multiple databases in multiple locations (Figure 10.3).

Figure 10.3. Decentralized Meta Data Repository

Commonly accessed meta data components could be replicated across multiple

databases, but great care must be taken to keep those components consistent. A

gateway directs the meta data access calls to the appropriate database to retrieve

the desired meta data. There are some distinct advantages and disadvantages to this

solution, whether it is built in-house or licensed from a vendor (Table 10.3).

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

312/631

Table 10.3. Advantages and Disadvantages of a Decentralized

Meta Data Repository

Advantages

Disadvantages

Various owners can maintain

and manage their own sets of

meta data separately.

Controlling redundancy across multiple

meta data repositories and keeping the

meta data consistent is difficult.

Meta data repository databases

are smaller and easier to use

because each database contains

only those meta data

components that are of interest

to a specific group of business

people.

It will take longer to maintain and

manage multiple databases on multiple

platforms. There could also be

synchronization problems with new

DBMS releases.

Each meta data repository can

have its own meta model, that

is, its own customized design.

Communication among the custodians

of the various meta data repositories

will have to increase. Plus, it will

require maintaining a meta-meta

model, which is an integrated (merged)

overall architecture of multiple meta

models.

Reports can be customized for

each individual meta data

repository.

Relating meta data across various

databases may be difficult. For

example, business meta data is not

automatically linked to technical meta

data if they reside on different

databases.

A gateway makes the name and

location of the meta data

repository transparent to the

person accessing it.

The architecture of this solution is more

complicated and the learning curve to

use multiple databases with potentially

different designs may be high.

Distributed XML-Enabled Meta Data Solution

Although the most promising meta data repository answer is a distributed XML-

enabled meta data solution, it is also the most difficult to implement because it takes

the concept of a decentralized meta data repository to the next level. Rather than

storing meta data across multiple databases, in an XML-enabled solution the meta

data remains at its originating location, that is, in the various tool dictionaries

(Figure 10.4).

Figure 10.4. Distributed XML-Enabled Meta Data Solution

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

313/631

A gateway acts as a directory to the various locations where the meta data

components are stored (e.g., the DBMS system catalog tables or the ETL tool

dictionary). Vendors are vigorously exploring this "bleeding-edge" solution because it

reduces the necessity for double maintenance of the meta data. Double maintenance

refers to maintaining the meta data in the originating sources (DBMS and tool

dictionaries) as well as maintaining it in the separate meta data repository database.

Table 10.4 lists the advantages and disadvantages of this solution.

Table 10.4. Advantages and Disadvantages of a Distributed

XML-Enabled Meta Data Solution

Advantages

Disadvantages

XML tags enable access of meta

data across any type of data

storage through standardized

categorization and tagging of

meta data components.

The initial tagging of all meta data

with XML tags is a manual and

laborious process. Plus, XML tagging

cannot be used for all meta data.

Meta data never has to be

duplicated or moved from its

original source (except for

reporting purposes).

XML tags add to the storage

requirements for the dictionary

databases that store meta data

(DBMS and tool dictionaries).

A gateway makes the location of

the meta data transparent to the

person accessing it.

A meta-meta model has to be created

as a map of all the various types of

meta data storage, each of which is

designed according to its own unique

meta model.

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

314/631

Standard Web search engines

should be able to locate any meta

data anywhere.

DBMS and tool vendors must follow

industry standards

[*]

for meta data

XML tags in order to enable seamless

meta data access across all products.

Multiple standards need to be

supported.

Meta data and business data can

be coupled and transmitted

simultaneously.

Not all DBMSs and tools are XML-

enabled. This is a bleeding-edge and

unproven technology.

[*]

Meta data standards are being developed by two competing groups: the Meta Data Coalition

(MDC, influenced by Microsoft) and the Object Management Group (OMG, influenced by Oracle).

The jury is still out on which meta data standards will be adopted as the industry standards.

[ Team LiB ]

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

315/631

[ Team LiB ]

Designing a Meta Data Repository

If the decision is made to custom build a meta data repository in-house, you have to

choose between an E-R design and an OO design.

Entity-Relationship Design

Because an E-R design represents the meta data objects and their relationships

explicitly, and because E-R designs are intuitive and easy to understand, many

organizations choose this type of database design for their meta data repositories. To

illustrate the intuitiveness of an E-R design, assume that the physical meta model

contains four objects (Database, Table, Column, and Attribute) and that these

objects are related in a one-to-many cardinality, as shown in Figure 10.5.

Figure 10.5. Example of Entity-Relationship Design. (Short

vertical lines indicate "one," and the crow's feet indicate

"many.")

This type of database structure is easy enough to understand that technology-savvy

business people could write their own ad hoc Structured Query Language (SQL)

queries against it. However, if these ad hoc queries are executed against a large

centralized meta data repository, performance could be a problem. It is relatively

easy to write poorly performing SQL queries. In addition, since each meta data

object is implemented as a separate table, there will be dozens of tables, and some

queries will contain very complicated JOINs across many of these tables. This could

also affect performance.

Table 10.5 lists the advantages and disadvantages of E-R designs.

Table 10.5. Advantages and Disadvantages of Entity-

Relationship Designs

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

316/631

Advantages

Disadvantages

E-R designs are easy to read and

easy to understand.

Changes and enhancements may

require a database redesign, as well

as unload-ing and reloading the meta

data repository.

Because of the intuitive and

explicit nature of the design,

queries can be written with

relatively simple SQL statements.

The physical meta model is fairly

large, with many objects and many

relation-ships, which makes the

architecture somewhat complex.

E-R designs are easy to

implement as relational database

structures.

Meta data objects and their

relationships must be very well

defined and under-stood for the

physical meta model to be accurate.

Object-Oriented Design

As popular as E-R designs may be for meta data repository databases, OO designs

are more efficient. Since they are more abstract, they result in fewer tables, run

queries more efficiently, and are much easier to expand. Using the same example as

above, the OO model would contain only three objects, but these objects would be

more generic, as shown in Figure 10.6.

Figure 10.6. Example of Object-Oriented Design. (Short

vertical lines indicate "one," and the crow's feet indicate

"many.")

This type of database structure is not easy to understand, and business people will

probably not be able to write their own ad hoc SQL queries against it. It is not

intuitively obvious that the object named Object contains the instances (rows) for all

meta data objects, such as database instances, table instances, column instances,

attribute instances, and so on. It is also not obvious that the object named Object

Type differentiates the various meta data object instances by assigning the

appropriate label of Database, Table, Column, Attribute, and so on. And the

untrained eye would have an even more difficult time discerning that all relationships

between these object instances are reflected in the third object named Object

Relationship. However, it is easy to see that expanding this type of generic design is

as simple as adding new instances (rows) to these three objects (tables).

Table 10.6 lists the advantages and disadvantages of OO designs.

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

317/631

Table 10.6. Advantages and Disadvantages of Object-Oriented

Designs

Advantages

Disadvantages

OO designs are extremely

flexible; they will not need

any database redesigns when

changes are necessary.

Since the object named Object contains

all instances (rows) of meta data, this

table will become very large. This may

affect access performance.

OO designs are simplistic and

therefore easy to maintain

and to enhance.

Queries are much more difficult to write

and will require many recursive JOINs.

Advanced SQL knowledge is required.

OO designs are easy to

implement as object-oriented

database structures.

OO designs require a high learning curve.

The very abstract physical data model is

difficult to comprehend, and the extensive

rules take time to understand.

Designing and building your own meta data repository may not be within the scope

of your BI project. There may be no budget and no staff for a separate meta data

repository project. Maybe your organization would prefer to license (buy) a meta

data repository product. As with all off-the-shelf products, a licensed meta data

repository product will probably not be the perfect solution, but it may be the most

cost-effective one. It would certainly be better than ignoring meta data altogether.

[ Team LiB ]

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

318/631

[ Team LiB ]

Licensing (Buying) a Meta Data Repository

When selecting a meta data repository product (or any type of product), you should

never start with the question, "What is the best product of this type on the market?"

Instead, always start with the following questions:

What are our requirements?

Which requirements are:

- Mandatory (must have)

- Important (beneficial to have)

- Optional (nice to have)

Which products address our mandatory requirements?

Which products address our important requirements?

Compare each vendor's logical meta model (if one exists) or their physical meta

model (product design) with your logical meta model, and determine whether the

vendor's model covers all the meta data requirements reflected in your

"requirements meta model." At a minimum, the vendor's model must support all

your mandatory meta data requirements. If it does, find out if the vendor's meta

model and software can be expanded so that you can add your own features to

support your important meta data requirements. Expansion capabilities of meta data

repository products should include the following:

Adding meta data objects

Adding relationships

Changing inappropriate relationships

Adding meta-meta data attributes to the meta data objects

Changing the size and length of meta-meta data components

Customizing vendor-provided reports

Creating and storing code for additional reports

Importing meta data from other tools

Exporting meta data to other tools

Product Evaluation

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

319/631

Use standard evaluation techniques to select a meta data repository product. For

example, prepare a list of product evaluation criteria for your meta data

requirements and assign a weighting factor from 1 to 10 to each criterion (1 being

least important and 10 being most important), like the sample criteria list shown in

Table 10.7.

Notice that "Product can satisfy our mandatory meta data

requirements" is not a weighted criterion. If the product

cannot support the mandatory requirements, do not even

consider it.

Rate each product on all product evaluation criteria by assigning a rating on a scale

of 0 to 10 (0 means the product does not have that feature, 10 means that the

product feature is outstanding), as illustrated in the example in Table 10.8.

Multiply the product ratings by the criteria weighting factors to obtain final scores for

each product. Add up all the scores and list the products in the order of highest total

score down to lowest total score, as shown in Table 10.9.

Table 10.7. Example of Product Evaluation Criteria with

Weights

Criterion #

Product Evaluation Criteria

Weight

Product closely matches our logical meta model

Product can satisfy our important meta data requirements

Product can satisfy our optional meta data requirements

Product can be expanded

Product has interfaces

Product has a Web front end

Product has APIs

Table 10.8. Example of Product Ratings

Criterion #

Product

[*]

Autumn Dictionary

Helixor

Leeches

Repository

Springrep

Tamroller MDR

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

320/631