哪位对数据挖掘(Data Mining)有研究，麻烦说来听听。(300分)

给些连接、主要介绍的站点吧？不过不要太泛泛而谈。
有电子版图书就更好了。
目的：基因数据的搜集和处理。数据量会非常大，至少要 nn G

早点来，占个好位置。

gz

这里看看，http://atiger.best.163.com/
好像还有一本书 data mining :concepts and technical

我觉得对于国内而言，信息化尚未普及，电脑，网络使用率也很低，
数据挖掘主要用来调查企业个人的潜在行为和信息，因此觉得国内
搞这些东西意义不大，信息量还没有那么大，而且只是限于部分群
体。

蚊子说的 http://atiger.best.163.com/ 这里有些意思。
不过Data Mining这本书...还没有找到。
to Adnil，预计进行基因库的分析，数据量上没有问题。
希望大家继续讨论

Data Mining：data mining :concepts and technical 的书，
我星期天在广州书城看到有,好像是中文版的，四楼,现在买书太贵了，
暂时用不上，就没买，买别的书瘦了荷包 3xx.

摘自ibm:
Data Miner
Solution-Based Data Mining
Bob Angell
Specific, solution-based data marts could save businesses time and money.
On a recent consulting engagement, my team was asked to solve a specific business problem for a financial services company. We had to format, manipulate, transform, summarize, and calculate the company-provided customer data to prepare for data mining, a process that took several months. And at the end of all the time and effort, the company learned ... nothing. Or, more accurately, it learned that the information it had was not the right information for solving that particular business problem.
Projects such as this one squander a company's time and resources, but itdo
esn't have to be that way. If companies consider what information they might need for each particular business problem they wish to solve at the data mart design stage, they could save time and money - and make the data mining analyst's job a lot easier. This solution-based approach to database design, development, and implementation plays off the current generation of data mining tools to maximize the success of data mining projects.
I'll explain how a solution-based design can help, plus offer examples of three common business problems and the design considerations for each.
The Foundation
New developments in data mining tools combined with current databases' ability to accommodate knowledge discovery activities create the foundation for a solution-based approach. Although it wasn't long ago that analysts had to generate their own data sets, data mining tools have come a long way since then
. Flat-files used in some of the earlier data mining tools have given way to data repositories. Most data mining tools today read and write to most federated databases, and some can manipulate, update, and mine directly from these data sources.
Now that a few of the data mining tools are mature, data miners can turn their attention to how to construct a data mart that will simplify data mining efforts. Thinking about the data elements needed to solve a particular business problem before building the data mart and considering what extracting, processing, transformations, and analysis will be needed will help data mining projects succeed. Although data miners aren't generally responsible for data mart design, getting involved in the process early will help those who will be designing, developing, and deploying the data marts get it right the first time.
Solution-based data mining leads to smaller, more concise data marts: Each one stores only the information necessary to solve the business problem at hand. A few specialized data marts would serve as extensions of your data warehouse.
Many older database designs are insufficient or inappropriate for decision support, though they might be fine for transaction processing. But even different decision-support tasks require different information. To identify your most profitable customers, the data extracts, loads, and analysis you'd perform differ greatly from those you'd use to find out which products your customers are purchasing. Answering these questions requires extremely different approaches. Analyst involvement in the design process is essential to get the design right the first time.
Design Solutions
Many companies suffer through years of evolving data structures. Often, their struggles result from overlooking some basics, such as constraint checking or orphaned dependencies. Another common error is to create molecular data, when successful data mining requires atomic data. Combining critical data elements creates a molecular mess. (For example, when the data element "Mr. John Robert Smith Jr." is manifested as a single entry in a database field, it is considered molecular data. In contrast, when all the information is in individual pieces in separate fields, the data is considered atomic.) Calculations, deltas, standard deviations, and other additional modifications fit into an atomic database structure. You simply need to be able to find the elements that created the modifications.
These considerations hold true for almost any data mart. Now I'll explain some design considerations for specific, common business problems.
Customer profitability. To answer the question, "Who are my most profitable customers?", you first need to define what your business considers a profitable customer. Because profitability can be defined and calculated in many different ways, this step is critical. For this example, let's assume you're calculating profitability at the customer (rather than household or account) level. After you settle on a definition of profitability, you can use data-driven discovery techniques (such as clustering) to segment the customer records. The database records for this problem should be rolled up into a summary format for the appropriate level, giving the analyst only one record per level (or customer, in this example). In addition, the database must contain complete demographic information (such as name, city, state, ZIP Code, and so on). Calculating age, duration with the company (most likely represented in days), and profitability score (usually from 0 to 1, with 1 representing the more profitable the customer) would help the analyst save time when solving this business problem. Bydo
ing everything possible ahead of time, the solution-based data mart lets the analyst spend less time manipulating and transforming the data to be mined. And the preparations for the data mart can reveal missing data, wrong data elements, and other factors that could seriously undermine any data mining project. Once the business problem is solved, the process can be automated.
Fraud detection. Because of the many implications for the word "fraud," you might hear this task referred to as entity profiling. This business problem consists of profiling an entity (usually a person) and creating an alert when the entity triggers an event that deviates too much (or too little) from the normal range. Credit card profiling is a common example. Several years ago, decision-support techniques revealed that the following scenario would most likely occur with a lost or stolen card:
An unauthorized individual recovers the card.
The individual goes to a gas station and tries to place a $3 to $5 transaction to determine if it is a "hot" card. The small purchase attempt initially was not enough to trigger suspicions at the credit card company.
If the transaction is successful, the individual will try to max out the card within a short period of time. If the transaction is unsuccessful, the individual will make an excuse (that the card is old, for example) and pay cash instead. Generally, the clerk suspects nothing.
Today, many companies have extensive profiles on purchase behavior and other customer propensities. I live in Salt Lake City and recently traveled to Houston for business. Late one night, I received a phone call from my credit card company minutes after making a large purchase. They noticed that a series of recent transactions on my card didn't fit the past credit card behavior and didn't take place where I was most likely to use the card. The sequence of events flagged what is called a "statistical outlier," a deviation from the normal parameters in place from my previous credit card activity. In this example, although it appeared that the credit card was stolen, legitimate but unusual circumstances created the outlier. The company's database will update my profile to reflect this new behavior.
When designing for fraud detection, make sure the data mart is designed to record every transaction and capture sequences of events (for example, the small charge followed by a series of large charges detailed in the steps I mentioned). An identifier for flagging fraudulent transactions is also very important. Other calculations and deltas might be needed, depending on the quality and quantity of data that exists. Once again, the entity profile data mart could become an automated solution, allowing companies to respond quickly to potential business risks and safeguard their business assets.
Loyalty card profiling. Many companies want to understand not only who their customers are, but also what kind of behavior they might exhibit. Combining customer purchase histories with demographics and other information can help companies design retail store layout, develop cross-sell and up-sell opportunities, and create targeted or customized marketing opportunities. As a result, many retail outlets are now tracking customer purchases through the use of what is called a "loyalty card." This card lets the company link your items purchased (your market basket) with your demographic and, in some cases, psychographic data. Understanding customer preferences and behavior is the goal of most businesses today.
Database design is the key to market basket analysis and loyalty card profiling. The data mart must collect and store all point-of-sale (POS) data. It must also link the appropriate loyalty card number with the items purchased. Once you know the basket relationships, you can incorporate all the demographic information to create a profile of the individuals creating these relationships. The POS data should be formatted so that each item purchased is a separate record. Once a solution is properly constructed, an analyst could take advantage of combining it with other solution-based data marts for other retail problems. Solution-based data marts are modular and can be used as building blocks to help solve a more complex set of problems.
Making an Impact
Despite your best efforts, you may not be able to convince your company to use separate solution-based data marts. Nevertheless, you can still have a positive impact on database design by making sure these questions are addressed:
Will the design accommodate easy access to data (for example, addressing internal and external data, multiple sources, and so on)?
Will the design make it easier to extract data?
How easy will it be to manipulate data (such as roll-ups, joins, and derived attributes)?
Which tools will be included for seeing the data (for example, OLAP tools, reports, descriptive statistics, and interactive visualization)?
Will it be easy to store and manage data? Is temporary storage available? What should bedo
ne with remaining information? Can data preparation steps be archived for reuse as model metadata?
Does the design accommodate sharing work with others (by providing code libraries, collaboration tools, source code control, and so on)?
Are elements in place for distributing results (such as model libraries for scoring in production, models that know about data preparation requirements, libraries that make it easy to run scoring of archived models without intervention from the original analyst)?

还有机械工业的电子书数据挖掘
给个地址，给你mail

事实上，数据仓库和数据挖掘，对于国内大部分企业是用不上的，但是对一些
像移动，银行，电信，金融等企业，还是有一定的发展前景的；首先他们有钱，
建的起数据仓库，给的起主题分析的价钱，另外他们这些企业也积累了大量的历史
数据，从这些数据中发掘对企业发展有用的信息，对他们也是一种迫切都要求；
别的中小企业，别说数据仓库，就连MIS系统。可能都懒得上；

关注

www.Chinapub.com有 数据仓库技术简介
你用這個查一下吧，我有原文，但它是HTML的，圖不能粘上來。
数据仓库技术简介

??数据仓库是近年来兴起的一种新的数据库应用。在各大数据库厂商纷纷宣布产品支持数据仓库并提出一整套用以建立和使用数据仓库的产品是，业界掀起了数据库热。比如INFORMIXGONGSIDE公司的数据仓库解决方案；ORACLE公司的数据仓库解决方案；Sybase公司的交互式数据仓库解决方案等等。这同时也引起了学术界的极大兴趣，国际上许多重要的学术会议，如超大型数据库国际会议（VLDB），数据工程国际会议（Data Engineering）等，都出现了专门研究数据仓库（Data Warehousing，简记为DW）、联机分析处理（On-Line Analytical Processing,简记为OLAP）、数据挖掘（Data Mining, 简记为DM）的论文。对我国许多企业而言，在建立或发展自己的信息系统常常困扰于这样的问题：为什么要在原有的数据库上建立数据仓库？数据仓库能否代替传统的数据库？怎样建立数据仓库？等等。本章将简要介绍一下用到的数据仓库技术背景，并在下一章结合数据清理系统设计实例，更深一步阐述数据仓库技术在现实中的重大意义
§1 从数据库到数据仓库
??传统的数据库技术是以单一的数据资源，即数据库为中心，进行事务处理、批处理、决策分析等各种数据处理工作，主要的划分为两大类：操作型处理和分析型处理(或信息型处理)。 操作型处理也叫事务处理，是指对数据库联机的日常操作，通常是对一个或一组纪录的查询和修改，主要为企业的特定应用服务的，注重响应时间，数据的安全性和完整性；分析型处理则用于管理人员的决策分析，经常要访问大量的历史数据。而传统数据库系统优于企业的日常事务处理工作，而难于实现对数据分析处理要求，已经无法满足数据处理多样化的要求。操作型处理和分析型处理的分离成为必然。
??近年来，随着数据库技术的应用和发展，人们尝试对DB中的数据进行再加工，形成一个综合的，面向分析的环境，以更好支持决策分析，从而形成了数据仓库技术(Data Warehousing，简称DW)。作为决策支持系统(Decision-making Support System，简称DSS)，数据仓库系统包括：
??① 数据仓库技术；
??② 联机分析处理技术(On-Line Analytical Processing，简称OLAP)；
??③ 数据挖掘技术(Data Mining，简称DM)；
??数据仓库弥补了原有的数据库的缺点，将原来的以单一数据库为中心的数据环境发展为一种新环境：体系化环境。如图1.1所示：

图1.1数据仓库体系化环境





??1.1 什么是数据仓库
??业界公认的数据仓库概念创始人W.H.Inmon在《建立数据仓库》一书中对数据仓库的定义是：数据仓库就是面向主题的、集成的、不可更新的(稳定性)、随时间不断变化（不同时间）的数据集合，用以支持经营管理中的决策制定过程
??数据仓库中的数据面向主题，与传统数据库面向应用相对应。主题是一个在较高层次上将数据归类的标准，每一个主题对应一个宏观的分析领域：数据仓库的集成特性是指在数据进入数据仓库之前，必须经过数据加工和集成，这是建立数据仓库的关键步骤，首先要统一原始数据中的矛盾之处，还要将原始数据结构做一个从面向应用向面向主题的转变；数据仓库的稳定性是指数据仓库反映的是历史数据的内，而不是日常事务处理产生的数据，数据经加工和集成进入数据仓库后是极少或根本不修改的；数据仓库是不同时间的数据集合，它要求数据仓库中的数据保存时限能满足进行决策分析的需要，而且数据仓库中的数据都要标明该数据的历史时期。
??数据仓库最根本的特点是物理地存放数据，而且这些数据并不是最新的、专有的，而是来源于其它数据库的。数据仓库的建立并不是要取代数据库，它要建立在一个较全面和完善的信息应用的基础上，用于支持高层决策分析，而事务处理数据库在企业的信息环境中承担的是日常操作性的任务。数据仓库是数据库技术的一种新的应用，而且到目前为止，数据仓库还是用关系数据库管理系统来管理其中的数据。
??1.2 数据仓库的产生
??计算机系统的功能从数值计算扩展到数据管理距今已有三十多年了。最初的数据管理形式主要是文件系统，少量的以数据片段之间增加一些关联和语义而构成层次型或网状数据库，但数据的访问必须依赖于特定的程序，数据的存取方式是固定的、死板的。到了1969年，E.F.Codd博士发表了他著名的关系数据模型的论文。此后，关系数据库的出现开创了数据管理的一个新时代。
??近几十年来，大量新技术、新思路的涌现出来并被用于关系型数据库系统的开发和实现：客户/服务器系统结构、存储过程、多线索并发内核、异步I/O、代价优化，等等，这一切足以使得关系数据库系统的处理能力毫不逊色于传统封闭的数据库系统。而关系数据库在访问逻辑和应用上所带来的好处则远远不止这些，SQL的使用已成为一个不可阻挡的潮流，加上近些年来计算机硬件的处理能力呈数量级的递增，关系数据库最终成为联机事务处理系统的主宰。
整个80年代直到90年代初，联机事务处理一直是数据库应用的主流。然而，应用在不断地进步。当联机事务处理系统应用到一定阶段后，用户便发现单靠拥有联机事务处理已经不足以获得市场竞争的优势，他们需要对其自身业务的运作以及整个市场相关行业的情况进行分析，而做出有利的决策。这种决策需要对大量的业务数据包括历史业务数据进行分析才能得到。在如今这样激烈的市场竞争环境下，这种基于业务数据的决策分析，我们把它称为联机分析处理，比以往任何时候都显得更为重要。如果说传统联机事务处理强调的是更新数据库--向数据库中添加信息，那么联机分析处理就是从数据库中获取信息、利用信息。因此，著名的数据仓库专家Ralph Kimball写道："我们花了二十多年的时间将数据放入数据库，如今是该将它们拿出来的时候了。"
??事实上，将大量的业务数据应用于分析和统计原本是一个非常简单和自然的想法。但在实际的操作中，人们却发现要获得有用的信息并非如想象的那么容易，这主要表现在以下几点：
??· 所有联机事务处理强调的是密集的数据更新处理性能和系统的可靠性，并不关心数据查询的方便与快捷。联机分析和事务处理对系统的要求不同，同一个数据库在理论上都难以做到两全。
??· 业务数据往往存放于分散的异构环境中，不易统一查询访问，而且还有大量的历史数据处于脱机状态，形同虚设。
??· 业务数据的模式针对事务处理系统而设计，数据的格式和描述方式并不适合非计算机专业人员进行业务上的分析和查询。
??因此有人感叹：20年前查询不到数据是因为数据太少了，而今天查询不到数据是因为数据太多了。针对这一问题，人们设想专门为业务的统计分析建立一个数据中心，它的数据从联机的事务处理系统中来、从异构的外部数据源来、从脱机的历史业务数据中来…… 。这个数据中心是一个联机的系统，它是专门为分析统计和决策支持应用服务的，通过它可以满足决策支持和联机分析应用所要求的一切。这个数据中心就叫做数据仓库。这个概念在90年代初被提出来。如果需要给数据仓库一个定义的话，那么数据仓库就是一个作为决策支持系统和联机分析应用数据源的结构化数据环境。数据仓库所要研究和解决的问题就是从数据库中获取信息的问题。
??那么数据仓库与数据库(主要指关系数据库)又是什么关系呢?回想当初，人们固守封闭式系统是出于对事务处理的偏爱，人们选择关系数据库是为了方便地获得信息。我们只要翻开C.J.Date博士的经典之作《An Introduction to Database Systems》便会发现：今天数据仓库所要提供的正是当年关系数据库所要倡导的。然而，由于关系数据库系统在联机事务处理应用中获得的巨大成功，使得人们已不知不觉将它划归为事务处理的范畴；过多地关注于事务处理能力的提高，使得关系数据库在面对联机分析应用时又遇到了新的问题--今天的数据仓库对关系数据库的联机分析能力提出了更高的要求，采用普通关系型数据库作为数据仓库在功能和性能上都是不够的，它们必须有专门的改进。因此，数据仓库与数据库的区别不仅仅表现在应用的方法和目的方面，同时也涉及到产品和配置上的不同。
以辨证的眼光看，数据仓库的兴起实际是数据管理的一种回归，是螺旋式的上升。今天的数据库就好比当年的层次数据库和网状数据库，它们面向事务处理；今天的数据仓库就好比是当年的关系数据库，它针对联机分析。所不同的是，今天的数据仓库不必再为联机事务处理的特性而无谓奔忙，由于技术的专业化，它可更专心于联机分析领域的发展和探索
??数据仓库的概念一经出现，就首先被用于金融、电信、保险等主要传统数据处理密集型行业。国外许多大型的数据仓库在1996-1997年建立。那么，什么样的行业最需要和可能建立数据仓库呢？有两个基本条件：第一，该行业有较为成熟的联机事务处理系统，它为数据仓库提供客观条件；第二，该行业面临市场竞争的压力，它为数据仓库的建立提供外在的动力。
§2 数据仓库中的数据组织
?? 数据仓库中数据的四个基本特征在本章§1中已经介绍过了，下面就要分析清楚这些问题：数据仓库存储哪些数据呢？数据如何组织，存储？组织形式有哪些？等等。通过对数据仓库中存放的数据内容及其组织形式的介绍，本节将对这些问题做出回答，以加深对数据仓库数据四个基本特征的理解。 2.1 数据仓库的数据组织结构
一个典型的数据仓库的数据组织结构如图1.2所示:
数据仓库中的数据分为四个级别：早期细节级、当前细节级、轻度综合级、高度综合级。源数据经过综合后，首先进入当前细节级，并根据具体需要进行进一步的综合，从而进入轻度综合级乃至高度综合级，老化的数据将进入早期细节级由此可见，数据仓库中存在着不同的综合级别，一般称之为"粒度"。粒度越大，表示细节程度越低，综合程度越高。
数据仓库中还有一种重要的数据--元数据（metadata）。元数据是"关于数据的数据"，如在传统数据库中的数据字典就是一种元数据。在数据仓库环境下，主要有两种元数据：第一种是为了从操作性环境向数据仓库转化而建立的元数据，包含了所有源数据项名、属性及其在数据仓库中的转化；第二种元数据在数据仓库中是用来和终端用户的多维商业模型/前端工具之间建立映射，此种元数据称之为DSS元数据，常用来开发更先进的决策支持工具。
关于元数据，下面的章节还会做进一步的阐述。

图1.2 DW数据组织结构




??2.2 粒度与分割
?? 1． 粒度
??粒度是数据仓库的重要概念。粒度可以分为两种形式，第一种粒度是对数据仓库中的数据的综合程度高低的一个度量，它既影响数据仓库中的数据量的多少，也影响数据仓库所能回答询问的种类。在数据仓库中，多维粒度是必不可少的。由于数据仓库的主要作用是DSS分析，因而绝大多数查询都基于一定程度的综合数据之上的，只有极少数查询涉及到细节。所以应该将大粒度数据存储于快速设备如磁盘上，小粒度数据存于低速设备如磁带上。
还有一种粒度形式，即样本数据库。它根据给定的采样率从细节数据库中抽取出一个子集。这样样本数据库中的粒度就不是根据综合程度的不同来划分的，而是有采样率的高低来划分，采样粒度不同的样本数据库可以具有相同的数据综合程度。
??2． 分割
??分割是数据仓库中的另一个重要概念,它的目的同样在于提高效率。它是将数据分散到 各自的物理单元中去,以便能分别独立处理。有许多数据分割的标准可供参考:如日期、地 域、业务领域等等,也可以是其组合。一般而言,分割标准总应包括日期项,它十分自然而且分割均匀。
?? 2.3 数据仓库的数据组织形式
??这里简单介绍数据仓库中常见的数据组织形式：
????1. 简单堆积文件: 它将每日由数据库中提取并加工的数据逐天积累并存储起来。
????2. 轮转综合文件: 数据存储单位被分为日、周、月、年等几个级别。在一个星期的七天中，数据被逐一记录在每日数据集中；然后,七天的数据被综合并记录在周数据集中；接下去的一个星期，日数据集被重新使用，以记录新数据。同理,周数据集达到五个后，数据再一次被综合并记入月数据集。以此类推。轮转综合结构十分简捷，数据量较简单堆积结构大大减少。当然，它是以损失数据细节为代价的，越久远的数据，细节损失越多。
????3. 简化直接文件: 它类似于简单堆积文件，但它是间隔一定时间的数据库快照，比如每隔一星期或一个月作一次。
????4. 连续文件: 通过两个连续的简化直接文件，可以生成另一种连续文件，它是通过比较两个简单直接文件的不同而生成的。当然，连续文件同新的简单直接文件也可生成新的连续文件。
对于各种文件结构的最终实现，在关系数据库中仍然要依靠"表"这种最基本的结构。
??2.4 数据仓库的数据追加
??如何定期向数据仓库追加数据也是一个十分重要的技术。我们知道,数据仓库的数据是 来自OLTP的数据库中，问题是我们如何知道究竟哪些数据是在上一次追加过程之后新生成 的。常用的技术和方法有:
　　??·时标方法: 如果数据含有时标，对新插入或更新的数据记录，在记录中加更新时的时标，那么只需根据时标判断即可。但并非所有的数据库中的数据都含有时标。
????·DELTA文件: 它是由应用生成的,记录了应用所改变的所有内容。利用DELTA文件效率 很高，它避免了扫描整个数据库，但同样的问题是生成DELTA文件的应用并不普遍。此外，还有更改应用代码的方法，使得应用在生成新数据时可以自动将其记录下来。但应用成千上万，且修改代码十分繁琐，这种方法很难实现。
　　??·前后映象文件的方法: 在抽取数据前后对数据库各作一次快照，然后比较两幅快照的不同从而确定新数据。它占用大量资源，对性能影响极大，因此并无多大实际意义。
????·日志文件: 最可取的技术大概是利用日志文件了，因为它是DB的固有机制，不会影响O LTP的性能。同时，它还具有DELTA文件的优越性质，提取数据只要局限日志文件即可，不用扫描整个数据库。当然,原来日志文件的格式是依据DB系统的要求而确定的，它包含的数据对于数据仓库而言可能有许多冗余。比如，对一个记录的多次更新，日志文件将全部变化过程都记录下来；而对于数据仓库，只需要最终结果。但比较而言，日志文件仍然是最可行的一种选择。

§3 数据仓库的关键技术

??那么，数据仓库都有哪些组成部分和关键技术呢？与关系数据库不同，数据仓库并没有严格的数学理论基础，它更偏向于工程。由于数据仓库的这种工程性，因而在技术上可以根据它的工作过程分为：数据的抽取、存储和管理、数据的表现以及数据仓库的设计的技术咨询四个方面。为此，我们将分别讨论每一个环节。
??3.1 数据的抽取
??数据的抽取是数据进入仓库的入口。由于数据仓库是一个独立的数据环境，它需要通过抽取过程将数据从联机事务处理系统、外部数据源、脱机的数据存储介质中导入到数据仓库。数据抽取在技术上主要涉及互连、复制、增量、转换、调度和监控等几个方面。数据仓库的数据并不要求与联机事务处理系统保持实时的同步，因此数据抽取可以定时进行，但多个抽取操作执行的时间、相互的顺序、成败对数据仓库中信息的有效性则至关重要。
在技术发展上，数据抽取所涉及的单个技术环节都已相对成熟，其中有一些是躲不开编程的，但整体的集成度还很不够。目前市场上所提供的大多是数据抽取工具。这些工具通过用户选定源数据和目标数据的对应关系，会自动生成数据抽取的代码。但数据抽取工具支持的数据种类是有限的；同时数据抽取过程涉及数据的转换，它是一个与实际应用密切相关的部分，其复杂性使得不可嵌入用户编程的抽取工具往往不能满足要求。因此，实际的数据仓库实施过程中往往不一定使用抽取工具。整个抽取过程能否因工具的使用而纳入有效的管理、调度和维护则更为重要。从市场发展来看，以数据抽取、异构互连产品为主项的数据仓库厂商一般都很有可能被其它拥有数据库产品的公司吞并。在数据仓库的世界里，它们只能成为辅助的角色。
??3.2 数据的存储和管理
??数据仓库的真正关键是数据的存储和管理。数据仓库的组织管理方式决定了它有别于传统数据库的特性，同时也决定了其对外部数据表现形式。要决定采用什么产品和技术来建立数据仓库核心，则需要从数据仓库的技术特点着手分析
??数据仓库遇到的第一个问题是对大量数据的存储和管理。这里所涉及的数据量比传统事务处理大得多，且随时间的推移而累积。从现有技术和产品来看，只有关系数据库系统能够担当此任。关系数据库经过近30年的发展，在数据存储和管理方面已经非常成熟，非其它数据管理系统可比。目前不少关系数据库系统已支持数据分割技术，能够将一个大的数据库表分散在多个物理存储设备中，进一步增强了系统管理大数据量的扩展能力。采用关系数据库管理数百个GB甚至到TB的数据已是一件平常的事情。一些厂商还专门考虑大数据量的系统备份问题，好在数据仓库对联机备份的要求并不高。
??数据仓库要解决的第二个问题是并行处理。在传统联机事务处理应用中，用户访问系统的特点是短小而密集；对于一个多处理机系统来说，能够将用户的请求进行均衡分担是关键，这便是并发操作。而在数据仓库系统中，用户访问系统的特点是庞大而稀疏，每一个查询和统计都很复杂，但访问的频率并不是很高。此时系统需要有能力将所有的处理机调动起来为这一个复杂的查询请求服务，将该请求并行处理。因此，并行处理技术在数据仓库中比以往更加重要。
大家可以注意以下，在针对数据仓库的TPC-D基准测试中，比以往增加了一个单用户环境的测试，成为"系统功力"（QPPD）。系统的并行处理能力对QPPD的值有重要影响。目前，关系数据库系统在并行处理方面已能做到对查询语句的分解并行、基于数据分割的并行、以及支持跨平台多处理机的群集环境和MPP环境，能够支持多达上百个处理机的硬件系统并保持性能的扩展能力。
??数据仓库的第三个问题是针对决策支持查询的优化。这个问题主要针对关系数据库而言，因为其它数据管理环境连基本的通用查询能力都还不完善。在技术上，针对决策支持的优化涉及数据库系统的索引机制、查询优化器、连接策略、数据排序和采样等诸多部分。普通关系数据库采用B树类的索引，对于性别、年龄、地区等具有大量重复值的字段几乎没有效果。而扩充的关系数据库则引入了位图索引的机制，以二进制位表示字段的状态，将查询过程变为筛选过程，单个计算机的基本操作便可筛选多条记录。由于数据仓库中各数据表的数据量往往极不均匀，普通查询优化器所得出得最佳查询路径可能不是最优的。因此，面向决策支持的关系数据库在查询优化器上也作了改进，同时根据索引的使用特性增加了多重索引扫描的能力。
??以关系数据库建立的数据仓库在应用时会遇到大量的表间连接操作，而连接操作对于关系数据库来说是一件耗时的操作。扩充的关系数据库中对连接操作可以做预先的定义，我们称之为连接索引，使得数据库在执行查询时可直接获取数据而不必实施具体的连接操作。数据仓库的查询常常只需要数据库中的部分记录，如最大的前50家客户，等等。普通关系数据库没有提供这样的查询能力，只好将整个表的记录进行排序，从而耗费了大量的时间。决策支持的关系数据库在此做了改进，提供了这一功能。此外，数据仓库的查询并不需要像事务处理系统那样精确，但在大容量数据环境中需要有足够短的系统响应时间。因此，一些数据库系统增加了采样数据的查询能力，在精确度允许的范围内，大幅度提高系统查询效率。
??总之，将普通关系数据库改造成适合担当数据仓库的服务器有许多工作可以做，它已成为关系数据库技术的一个重要研究课题和发展方向。可见，对于决策支持的扩充是传统关系数据库进入数据仓库市场的重要技术措施。
数据仓库的第四个问题是支持多维分析的查询模式，这也是关系数据库在数据仓库领域遇到的最严峻的挑战之一。用户在使用数据仓库时的访问方式与传统的关系数据库有很大的不同。对于数据仓库的访问往往不是简单的表和记录的查询，而是基于用户业务的分析模式，即联机分析。如图1.3所示，它的特点是将数据想象成多维的立方体，用户的查询便相当于在其中的部分维(棱)上施加条件，对立方体进行切片、分割，得到的结果则是数值的矩阵或向量，并将其制成图表或输入数理统计的算法。

图 1.3 联机分析数据处理示意图

??关系数据库本身没有提供这种多维分析的查询功能，而且在数据仓库发展的早期，人们发现采用关系数据库去实现这种多维查询模式非常低效、查询处理的过程也难以自动化。为此，人们提出了多维数据库的概念。多维数据库是一种以多维数据存储形式来组织数据的数据管理系统，它不是关系型数据库，在使用时需要将数据从关系数据库中转载到多维数据库中方可访问。采用多维数据库实现的联机分析应用我们称之为MOLAP。多维数据库在针对小型的多维分析应用有较好的效果，但它缺少关系数据库所拥有的并行处理及大规模数据管理扩展性，因此难以承担大型数据仓库应用。这样的状态直?quot;星型模式"在关系数据库设计中得到广泛的应用才彻底改变。几年前，数据仓库专家们发现，关系数据库若采用"星型模式"来组织数据就能很好地解决多维分析的问题。"星型模式"只不过是数据库设计中数据表之间的一种关联形式，它的巧妙之处在于能够找到一个固定的算法，将用户的多维查询请求转换成针对该数据模式的标准SQL语句，而且该语句是最优化的。"星型模式"的应用为关系数据库在数据仓库领域打开绿灯。采用关系数据库实现的联机分析应用称为ROLAP。目前，大多数厂商提供的数据仓库解决方案都采用ROLAP。
??在数据仓库的数据存储管理领域，从当今的技术发展来看，面向决策支持扩充的并行关系数据库将是数据仓库的核心。在市场上，数据库厂商将成为数据仓库的中坚力量。
??3.3 数据的表现
??数据表现是数据仓库的门面。这是一个工具厂商的天下。它们主要集中在多维分析、数理统计和数据挖掘方面。
多维分析是数据仓库的重要表现形式，由于MOLAP系统是专用的，因此，关于多维分析领域的工具和产品大多是ROLAP工具。这些产品近两年来更加注重提供基于Web的前端联机分析界面，而不仅仅是网上数据的发布。
??数理统计原本与数据仓库没有直接的联系，但在实际的应用中，客户需要通过对数据的统计来验证他们对某些事物的假设，以进行决策。与数理统计相似，数据挖掘与数据仓库也没有直接的联系。而且这个概念在现实中有些含混。数据挖掘强调的不仅仅是验证人们对数据特性的假设，而且它更要主动地寻找并发现蕴藏在数据之中的规律。这听起来虽然很吸引人，但在实现上却有很大的出入。市场上许多数据挖掘工具其实不过是数理统计的应用。它们并不是真正寻找出数据的规律，而是验证尽可能多的假设，其中包括许多毫无意义的组合，最后由人来判断其合理性。因此，在当前的数据仓库应用中，有效地利用数理统计就已经能够获得可观的效益。
?? 3.4 数据仓库设计的技术咨询
??在数据仓库的实施过程中，有一些更为基本的问题需要解答。它们包括：数据仓库提供哪些部门使用？不同的部门怎样发挥数据仓库的决策效益？数据仓库需要存放哪些数据？这些数据以什么样的结构存放？数据从哪里装载？装载的频率多少为合适？需要购置哪些数据管理的产品和工具来建立数据仓库？等等。这些问题依赖于特定的数据仓库系统，属于技术咨询的范畴。
??事实上，数据仓库决不是简单的产品堆砌，它是综合性的解决方案和系统工程。在数据仓库的实施过程中，技术咨询服务至关重要，是一个不可缺少的部分，它甚至于比购买产品更为重要。目前，数据仓库的技术咨询主要来自数据仓库软件产品的供应商和独立的针对数据仓库技术的咨询公司。
??3.5 数据仓库技术九十年代来的进展
??90年代以来,计算机技术,尤其是数据库技术的发展为DSS提供了技术支持;激烈的市场竞争促进了高层次决策人员对DSS的实际需求。两方面的共同作用,促成了以DW为核心、以O-LAP和DM工具为手段建设DSS的可行方案。数据库技术的发展 DW需要以下数据库技术的支持。
??(1)高性能数据库服务器 DW的应用不同于传统DB的OLTP应用。传统DB的应用是操作型的,而DW的应用是分析型的,它需要高性能的DBMS核心的支持,以使较快地获得分析结果,这通常需数秒至数分钟。虽然比OLTP的响应时间长一些,但由于分析型应用涉及的数据量大,查询要求复杂,因此,对DBMS核心的性能要求更高,同DBMS必须具有良好的查询优化机制。
??(2)并行数据库技术 DW中的数据量大,而且随着时间的延长,新的数据还会不断进入。DW中的数据库通常是GB甚至TB级的,可谓是超大规模数据库(VLDB)。而并行数据库技术是存储和管理VLDB,并提供对VLDB复杂查询处理的有效技术。
??(3)数据库互操作技术 DW中的数据大多来自企业或行业中业已运行的OLTP数据库或外部的数据源。这些数据库常常是异构的,甚至是文件系统中的数据。DW必须从这些异构数据源中定期抽取、转换和集成所需要的数据,并把它们存入DW中。因此,异构数据源之间的互访和互操作技术是必需的。

2 散光兄：my email := ahxia@21cn.com
大家继续up.

多人接受答案了。