星型数据结构设计.docVIP

星型数据库设计 by Craig Utley 介绍 创建一个星型数据库(Star Schema Database)是数据仓库开发中最重要的步骤之一。要知道这一步骤有多重要，就需要了解一个标准的在线事务处理系统(OLTP) 是如何转移到最终的星型数据库系统(也叫OLAP系统)。 作为初学者，当你考虑如何建立一个数据仓库的时候，以下问题一定会让你犯晕： 什么是数据仓库(Data Warehouse)？什么是数据集市(Data Mart)？ 什么是星型数据库(Star Schema Database)？ 为什么我需要一个星型数据库(Star Schema Database)？ 星型数据库不符合范式标准，使用中会出问题吗？ 上面这些术语的具体意思是什么？ 本文将帮你澄清上述问题，并告诉你如何来创建一个数据仓库，为你们单位的决策服务。 术语 通常，读者都会对每个章节或者书本最后附录里的术语列表感到厌烦。但是我还是不得不把这些术语放到前面来介绍。这样做的目的不是为了让你更早地觉得厌烦，而是为我们后面讨论做好准备。因为在数据仓库领域，各个组织对相同的术语都有不同的定义。数据仓库学院()曾尝试统一定义这些术语和概念。在本文中，我会给出我自己认为的最好的理解。但是请注意，我并不是在给数据仓库学院代言。 OLTP OLTP代表在线事务处理(Online Transaction Processing)。这是一种标准的，范式化的数据库结构。OLTP是专门为事务处理设计的，要求插入(insert)、修改(update)、删除(delete)操作一定要快。设想一个订单录入的呼叫中心(call center)，工作人员不停地接受呼叫，并把所有订单和订单条目的详细内容录入到数据库中。在这种情况下，数据库的性能显得至关重要，插入(修改、删除)速度要设法达到最快。为达到这一目的，数据库的数据一般都不会有冗余，保留尽可能少的数据。 OLAP和星型(Star Schema) OLAP代表在线分析处理(Online Analytical Processing)。不同的人对OLAP有不同的理解。在这里，我们认为OLAP和Star Schema在很大程度上是可以互换的概念，一个星型数据库就是一个OLAP系统。这跟微软所说的OLAP不一样，微软将OLAP概念扩展到了用他们的产品OLAP Service创建出来的立方体结构(cube structure)上面。我们定义，任何存放只读的(read-only)、历史的(historical)、聚合(aggregated)的数据的系统都是OLAP系统。 另外，我们认为OLAP/Star Schema系统就是数据仓库。这样理解不会产生任何问题，虽然在数据仓库中，为了提高查询速度而经常使用立方体结构(cube structure)。 数据仓库(Data Warehouse)和数据集市(Data Mart) 你可能认为我把两个完全不同的概念混在了一起，实际上，数据仓库和数据集市只是在范围上不一样，而在创建方法和流程上完全一致。所以我把它们放在一起讨论。 数据仓库(或者数据集市)是为了日后查询而采取的一种数据存储方法。这种查询几乎总是用来为某个单位的决策服务的。这也是为什么许多数据仓库都被认为是决策支持系统(DSS, Decision-Support System)。有些人会坚持认为不是所有的数据仓库都是DSS，有些数据仓库只是纯粹的数据归档。可是我们为什么会花时间和精力去创建一个星型数据库，还有立方体结构？目的是为了提高查询速度。这些查询通常要花费大量时间。人们为什么愿意花大量时间去查看数据？可能是为了发现某种趋势。如果是为了发现趋势，那你可以发誓他们是在做某个决定，比如说需要订购多少原材料。还是为决策服务！ 数据仓库和数据集市都是为了存储任何只读的(read-only)、历史的(historical)、聚合的(aggregated)数据的一种存储机制。 只读的，就是说数据不会被更改。如果某个用户要查看昨天某种产品的销售信息，那他不应该有权限去修改销售值，除非已经知道那个销售值有错误。 历史的，可能只是几分钟以前的数据，但一般都指至少一天前的数据。数据仓库都会保存某个阶段，比如五年以来的数据。而标准的OLTP系统通常只保存当前的，或者是活动的数据。比如在订购表中，当商品完成发货并确认客户已经接收，就可以把定购信息转移到归档表中。 聚合的。当我们说数据仓库和数据集市存放聚合值的时候，我们要强调一个典型数据仓库中，都有许多层的聚合(agg