学会一种新的数据建模规范来提高数据仓库的效率

• 
• 
• 

换句话说，对数据库而言，一个联机事务处理系统查询和一个联机事务处理系统查询是直接对立的。当你考虑到程序的本质的时候就很容易看到这两种系统查询的分化：联机事务处理系统程序一般被众多的人使用，以在同一时刻处理一个商业事务；而联机分析处理系统程序一般只是分析者使用（在数量上远远少于联机分析处理系统程序的使用者），并且根本就不用来处理商业事务，但是在同一时间内能够处理大量的记录。

所以，当你进行数据仓库工作，即处理OLAP数据时，你都会考虑到以更高的效率来提高数据库的访问。

这两种系统查询的差别在哪里

当设计一个数据仓库服务OLAP程序时，你将不能忽视数据库访问。为什么不能呢？因为如果你忽视，你就无法得到一个具有合理性能的数据仓库。这是为什么呢？因为少量数据的大规模读取与大量数据的小规模读取在物理上是不一样的。

在一个典型的关系数据库环境中，当在表格中存储数据时，什么才是首选的组织方式？我们喜欢使用被规划化的数据，而这些数据按照数据选项之间的逻辑关系来划分。对于一个事务处理，这种做法很实用，我们很乐意使用这种方法。然而，试想如果在一个数据仓库中使用这一方法，结果会是怎么样？你自己可以想象一下，为了分析目的，你需要提取48个月的价格表记录，并计算物理记录的数目，这样做你是不是感到头昏脑胀？

目标一：不要在数据仓库中规则化数据

如果你不想规则化数据，那么在一个数据仓库中如何存储数据呢？可以把OLTP数据想象为郊区里没有规划的房子，每栋房子是一户人家，有的是大户人家，有的是小户人家，所有的房子被道路彼此连起来。而OLAP数据就是一个基本的独立的房子，而这些房子很容易集中起来（不需要道路）。

如果一个OLAP分析者为了分析而需要输入48个月的价目表记录，对于这种操作，最高效的数据读取是在每一次读取中获得最佳的数据块，这也意味着连续数据以数组形式而存放。也就说，由于你通过计算实体读取以提高你的查询效率，你将需要实体读取的最小数量，也就意味着连续数据与实体读取最大程度的接近。

 

目标二：连续逻辑存储=物理上最大存储

如果以十亿字节与一个数据库进行数据交换，那么在效率上可以有两种方法：数据必须存放在一个非常高效的结构，以及访问方法必须与结构相匹配。这看起来是不言而喻，但如果你平时都习惯于使用关系数据库，由此很难考虑到关系数据库的很多操作都会造成低效率化。

 

目标3：存储结构与访问方法应该匹配

设想我们将关系数据库当成一个无规化的房子，而解析数据库当成城市的一栋高楼大厦，你可以看到，对于访问路径的角度看，这两种数据库正好相反。关系数据库返回数据相当良好，因为我们知道访问的路径。然而，在一个数据仓库中，我们不知道访问的路径。所以，我们必须知道允许我们在一个多维的“大厦”中快速读取数据的结构。同样，我们可以知道我们在关系数据库中的位置，因为数据对象与其它数据对象都有一定的预先确定的关系。在一个数据仓库中，这些关系都没有得到很好的定义，接近(Proximity)通常只是我们主要的访问特性，因为我们是从一个水桶中“捞起”数据，而类似的对象都以连续次序而排列(物理上与逻辑上是相类似)。

进一步地考虑高楼大厦的比喻，一个数据仓库的存储是多维的。高楼大厦是一个扩大的立方体，而这一立方体正是我们想在存储仓库数据中建立的模型。由于我们需要的数据必需相关，但不能以RDMBS方式，我们需要为数据对象而建立相应的空间。可以通过在我们的数据模型中添加一维数而实现这一过程。

数据的形式

在不使用一个关系结构的情况下，如何在连续存储的数据对象中添加内容？你可以使用数据结构中的两个重要的概念来实现：star schema以及 cube。

星型模式(star schema )

在一个星型模式中，数据表格关联到一个中央“事实(fact)”表，这种周边的表格构成了中央的维数。中央表格包含周边表格引用的关键词。所以中央表格显得多余，但是由于这一结构的关系功能，在使用上只需要少量的开支。

data cube

这种结构即为星型模式的三维体现(事实上，星型模式可以为三维：立方、超立方、以及你所需要的多种维数)。在这一结构中，在表面上你只有一个立方体的信息，而存储这一立方体的表格构成了关键词和指针的一维表格，而这些关键词和指针为你指明了分析的数据。

所认，这些目标都是为了更能充分利用最大的逻辑和物理上的效率来存储和返回数据，这样我们的访问时间就会缩短，我们的数据读取的次数就会减少。因为这些效率的获得，在接下来的文章中，我将讲述到如何在Microsoft SQL Server 2000中执行data cube。

责任编辑：李宁

欢迎评论或投稿