Moss L.T., Atre S. Business intelligence roadmap: The complete project lifecycle for decision-support applications
Подождите немного. Документ загружается.
Chapter Overview
This chapter covers the following topics:
Things to consider about implementation of BI applications
The two types of security implementations: centralized security and
decentralized security
How to perform a security gap analysis
The three types of backup procedures: incremental backup, high-speed
mainframe backup, and partial backup
Monitoring the utilization of computer, network, and personnel resources
Managing growth in data, growth in usage, and growth in hardware
Brief descriptions of the activities involved in implementation, the deliverables
resulting from those activities, and the roles involved
The risks of not performing Step 15
Things to Consider
Preparing for Production
Have we defined all the production libraries and production
databases?
Are the daily, weekly, and monthly extract/transform/load (ETL)
processes on the job scheduler?
Are the regularly scheduled application report programs on the job
scheduler?
Are the regularly scheduled meta data repository programs on the
job scheduler?
Is the operations staff ready to take over?
Have they approved the quality assurance (QA) test results? Do
they have any concerns?
Do we have to write operating procedures for the operations staff?
For all components of the BI application? Or just for the ETL process?
When will we copy all programs into the production libraries?
When will we load the production databases?
Security Considerations
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
421/631
What types of security measures do we need? What are we
securing?
How are we securing the data? The applications? The tools? The
interfaces?
Do the security measures have to include encryption and
decryption, especially for the Web-enabled access and analysis portion
of the BI application?
Are single-user authentication services of an enterprise information
portal part of this BI application?
Database Maintenance
What is our backup and recovery procedure?
What is our disaster recovery procedure?
How will database performance monitoring take place? What tools
will be used? Who is responsible for monitoring the databases?
How will we know if we have met the service-level agreement (SLA)
for performance?
How will we monitor growth in usage and growth in data volume?
Training and Support
Have the business people received training on using the BI
application?
Have the business people received training on using the meta data
repository?
Have the "power users" received training on writing efficient
queries in Structured Query Language (SQL)?
Is the help desk staff geared up to mentor the business people in
their use of the BI application, including the meta data repository?
Has the help desk staff received sufficient training?
If there is no help desk, who will support the business people?
Now that the BI application is built and tested, it is ready to be implemented in the
production environment. You can roll out the new BI application in two ways, all at
once as is done traditionally or in increments as briefly described in the section
below.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
422/631
[ Team LiB ]
Incremental Rollout
When planning the implementation, use the same iterative approach used when
developing the BI application and the meta data repository. The iterative approach,
or incremental rollout, works well because it reduces the risk of exposing potential
defects in the BI application to the entire organization. In addition, it gives you the
opportunity to informally demonstrate the BI concepts and the BI tool features to the
business people who were not directly involved in the BI project. Here are some
suggestions.
Start with a small group of business people. This small group should consist of
not only "power users" but also some less technology-savvy knowledge workers
and business analysts, as well as the primary business representative who was
involved in the development work as a member of the core team.
Treat the business people as customers—keeping customer care in mind.
Trouble-free implementation, interactive training, and ongoing support will help
you get their buy-in. Always ask yourself, "What is in it for the customers?"
Take the opportunity to test your implementation approach. You may consider
adjusting your implementation approach or modifying the BI application prior
to the full rollout (e.g., change cumbersome logon procedures).
It may be necessary to duplicate implementation activities at multiple sites.
Adding these sites slowly over time is easier than launching them all at the
same time.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
423/631
[ Team LiB ]
Security Management
Security features must be tested early during the first rollout. Security is often
overlooked in BI applications or is given superficial attention. Keep in mind that the
data in the BI target databases is the same data contained in the operational
systems. The common argument that security is not an issue for BI applications
because the data is aggregated and summarized holds true only if detailed data is
not available through drill-down features. In that case, the security measures for the
BI data do not need to be as stringent as the security measures imposed on the
same operational source data. However, most BI target databases store a fair
amount of detailed data in addition to the summaries. Therefore, the security
measures may be relaxed for some of the data but not for all.
Security Measures for BI Applications
Organizations that have strong security umbrellas on their mainframes are more
likely to pay attention to security measures for their BI applications on multi-tier
platforms. Organizations that have very lax security policies for their mainframes are
usually prone to treating security casually for their BI applications as well. These
organizations may unwittingly expose themselves to security breaches, especially if
they plan to deliver information from the BI target databases over the Web.
The following is an example of a security requirement that may need to be imposed
on a BI application. Suppose an organization wants to give its distributors the ability
to analyze their orders and shipments via a multidimensional BI application. To
prevent a distributor from searching through other distributors' sales data, there
would have to be a mechanism for restricting each distributor's access to only the
sales data pertaining to that particular distributor. In other words, some security
lock is required to prevent access to the competitors' sales data. This is not as
straightforward as it sounds.
No off-the-shelf umbrella security solutions can impose this kind of security.
This security requirement would have to be implemented through the various
security features of the database management system (DBMS) and of the
access and analysis tools used by the BI application.
The solution of imposing security at a table level may not be granular enough.
However, one possible way to achieve this type of security is to partition the
tables either physically or logically (through VIEWs). Partitioning will restrict
access solely to the appropriate distributor as long as both the fact tables and
the dimension tables are partitioned. Therefore, this method could become too
cumbersome.
An alternative may be to enhance the meta data with definitions of data
parameters, which could control access to the data. This form of security would
be implemented with appropriate program logic to tell the meta data repository
the distributor's identity, allowing the application to return the appropriate data
for that distributor only. This type of security measure will be only as good as
the program controlling it.
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
424/631
This example illustrates that the required security measures must be well considered
and that the security features of the DBMS and of the access and analysis tools must
be well understood and cross-tested. Complete reliance on one comprehensive
security package that has the capability to implement any and all types of security
measures is not a security solution because such a security package does not exist.
To get the security you need, you will most likely have to implement a number of
different security measures, including purchased security packages. However, be
sure to minimize the number of security packages you implement because one of two
things may happen.
Business people will be logging in through multiple security packages, using
multiple logon identifiers (IDs) and multiple passwords that expire at different
times. They will get frustrated very quickly if they have to go through different
logon procedures and remember different IDs and passwords for each
procedure. Complaints will run high.
1.
Business people will stop using the BI decision-support environment entirely
because it is too cumbersome. You do not want this to happen.
2.
A number of organizations avoid this problem by adopting a single-sign-on scheme,
which keeps the frustration level to a minimum but still allows tracking of any
security breaches, albeit in a less sophisticated way.
Security in a Multi-Tier Environment
Implementing security measures in a centralized environment is less complicated
than in a multi-tier environment. In a centralized environment, all security measures
can be implemented in one location because all the data is in one place. The goal of
centralized security is "one entry point, one guard." It is much easier to guard a
single door than multiple doors.
In a BI decision-support environment, keeping all the data in one central place is not
always feasible or desirable. If data needs to be stored in a distributed fashion in a
multi-tier environment, implementing security measures becomes much more
complicated. The list below briefly describes the steps involved.
Identify the end points in your network architecture and the paths connecting
the end points. Draw a diagram of your physical architecture, similar to Figure
15.1.
Figure 15.1. Example of a Physical Architecture Diagram
1.
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
425/631
Determine the connectivity paths (from the entry points) used to get to the
data. Draw a diagram with links and labels for the connectivity paths (Figure
15.2).
Figure 15.2. Example of a Connectivity Path Diagram
2.
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
426/631
Compare the paths with your existing security measures. You may already have
some security packages installed, and some of them may be sufficient to guard
a subset of the data. Draw a matrix for security gap analysis purposes (Figure
15.3).
Figure 15.3. Example of a Security Gap Analysis Matrix
3.
The security gap analysis matrix will help you identify where security is still needed
and what type of security is needed. Keep in mind the following points:
Password security may be the least expensive to implement, but it can be easily
violated.
DBMS security is the most important component of the security solution and
should override all other security measures that may contradict the data access
authority granted by the DBMS.
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
427/631
Encryption is not that prevalent in BI decision-support environments because of
the complicated encryption and decryption algorithms. Encryption and
decryption processes also degrade performance considerably. However, with
the frequent use of the Internet as an access and delivery mechanism,
encryption should be seriously considered to protect the organization from
costly security breaches.
Security for Internet Access
The Internet enables distribution of information worldwide, and the BI decision-
support environment provides easy access to organizational data. Combining the two
capabilities appears to be a giant leap forward for engaging in e-commerce.
However, carefully consider the implications of combining these technologies before
you decide to take the risk of potentially exposing sensitive organizational data
(Figure 15.4).
Figure 15.4. Security Considerations for Internet Access
Many product vendors are enabling Web access to databases in general, and some
vendors are allowing access to BI target databases in particular. This complicates the
concerns for:
The security of the BI decision-support environment in general
The security issues associated with allowing Web access to the organization's
data
The bottom line on security is that you need to define your security requirements
early in order to have time to consider and weigh all factors. If you opt to display the
data on the Web, spend extra time and money on authentication and authorization of
internal staff and external customers. If you are transmitting sensitive data to and
from external customers, consider investing in encryption and decryption software.
Authentication is the process of identifying a person, usually based on a logon
ID and password. This process is meant to ensure that the person is who he or
she claims to be.
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
428/631
Authorization is the process of granting or denying a person access to a
resource, such as an application or a Web page. In security software,
authentication is distinct from authorization, and most security packages
implement a two-step authentication and authorization process.
Encryption is the "translation" of data into a secret code. It is the most effective
way to achieve data security. To read an encrypted file, you must have access
to a secret key or password that enables you to decrypt it. Unencrypted data is
usually referred to as plain text, while encrypted data is usually referred to as
cipher text.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
429/631
[ Team LiB ]
Data Backup and Recovery
After spending several million dollars on your BI decision-support environment, you
want to make certain that you will never lose the content of the BI target databases
and that you will never be deprived of the analytical capabilities of the BI
applications for a long period of time.
There is a school of thought that says, "Don't worry about backing up your BI target
databases because that data is derived from other systems—if the data is destroyed,
simply rebuild it." This is a careless and expensive attitude when dealing with a very
large database (VLDB). Although backing up a database is time-consuming and
takes the database offline for several hours, the alternative of reloading years' worth
of data into a VLDB will take much longer—if it can be done at all. Not every
organization opts to keep all source extract files for years just in case it needs to
reprocess them.
It is mandatory to back up the BI target databases on a regular basis, but the sheer
size of VLDBs make this a technological challenge. Many of the hardware platforms
on which BI applications reside often have limitations on the amount of data that can
be backed up on a regular basis. These limitations are due to the slow speed of data
transfers between the server and the backup device. Several backup strategies are
available to mitigate this problem.
Incremental backup: One strategy is to take advantage of the grow-only
aspect of BI target databases (no updating of rows) by backing up only the
actual changes to a database (new rows) since the last update rather than the
entire database. This incremental ("net change") backup strategy is even
possible for most daily backups. However, since there are usually multiple
databases in the BI decision-support environment, and since the summarized
data must stay synchronized with the detail data, no loads or refreshes can
occur to any of these databases until the backups of all databases have
completed successfully.
High-speed mainframe backup: Another possibility is to use the mainframe
transfer utilities to pass BI data back to the mainframe for a high-speed
backup, which is supported only on the mainframe. Channel connects on the
mainframe allow speeds that cannot yet be approached on most midrange
servers. This is an expensive solution, but it is a robust one that usually works.
Partial backup: Another strategy relies on partitioning the database tables by
date to support partial backups. While one partition is being backed up, the
other partitions can remain available. Considerations about this strategy are
listed below.
- Databases, which support parallelization of backups, have a major
advantage with this strategy since multiple partitions can be backed up at
the same time.
- If your BI target databases are loaded daily, group multiple days into
one partition rather than setting up a new partition for each day. During
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
430/631