搜索
事实表每个数据仓库都包含一个或者多个事实数据表。事实数据表可能包含业务销售数据，如现金登记事务所产生的数据，事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据（事实），并且这些数字信息可以汇总，以提供有关单位作为历史的数据，每个事实数据表包含一个由多个部分组成的索引，该索引包含作为外键的相关性维度表的主键，而维度表包含事实记录的特性。事实数据表不应该包含描述性的信息，也不应该包含除数字度量字段及使事实与维度表中对应项的相关索引字段之外的任何数据。包含在事实数据表中的“度量值”有两中：一种是可以累计的度量值，另一种是非累计的度量值。最有用的度量值是可累计的度量值，其累计起来的数字是非常有意义的。用户可以通过累计度量值获得汇总信息，1.例如。可以汇总具体时间段内一组商店的特定商品的销售情况。非累计的度量值也可以用于事实数据表，单汇总结果一般是没有意义的，2.例如，在一座大厦的不同位置测量温度时，如果将大厦中所有不同位置的温度累加是没有意义的，但是求平均值是有意义的。一般来说，一个事实数据表都要和一个或多个维度表相关联，用户在利用事实数据表创建多维数据集时，可以使用一个或多个维度表。维度表维度表可以看作是用户来分析数据的窗口，纬度表中包含事实数据表中事实记录的特性，1.有些特性提供描述性信息，2.有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息，维度表包含帮助汇总数据的特性的层次结构。例如，包含产品信息的维度表通常包含将产品分为食品、饮料、非消费品等若干类的层次结构，这些产品中的每一类进一步多次细分，直到各产品达到最低级别。在维度表中，每个表都包含独立于其他维度表的事实特性，例如，客户维度表包含有关客户的数据。维度表中的列字段可以将信息分为不同层次的结构级。以下几个概念取自SQLServer联机丛书。星型架构一种关系数据库结构，该结构中在位于架构中心的单个事实数据表中维护数据，其它维度数据存储在维度表中。每个维度表与事实数据表直接相关，且通常通过一个键列联接到事实数据表。星型架构用在数据仓库中。事实数据表数据仓库架构中的中央表，它包含联系事实与维度表的数字度量值和键。事实数据表包含描述业务（如银行事务或产品销售）内特定事件的数据。维度表数据仓库中的表，其条目描述事实数据表中的数据。维度表包含创建维度所基于的数据。再举个实际的例子。银行对存款记账，A表中存放实际数据，包括账号、所属机构号、存款金额等，B表存放机构号和机构名称的对应关系。则A是事实表，B是维表。简单的说：1、事实表就是你要关注的内容；2、维表就是你观察该事务的角度，是从哪个角度去观察这个内容的。例如，某地区商品的销量，是从地区这个角度观察商品销量的。事实表就是销量表，维表就是地区表。数据仓库的物理模型较常见的操作型数据库的物理模型有很大不同。最明显的区别是：操作型数据库主要是用来支撑即时操作，对数据库的性能和质量要求都比较高，为了防止“garbagein，garbageout”，通常设计操作型数据库的都要遵循几个范式的约束，除非少数情况下为了性能进行妥协，才可能出现冗余。而数据仓库的建立并不上为了支撑即时操作，或者说，数据仓库的数据是来源于即时操作产生的数据，而不是直接来源于即时操作。所以它的数据质量是由操作性系统来保证的，而不是由几个范式来保证的。而且为了更好的跟踪历史信息，以及更快的产生报表，数据仓库的物理模型中存在着大量冗余字段。数据仓库的物理模型分为星型和雪花型两种。所谓星型，就是将模型中只有一个主题，其他的表中存储的都是主题的一些特征。比如货物销量的主题仓库中，每次出售记录是事实表，而时间，售货员，商品是维度，都和事实表有联系，组织起来就是星型。而如果更细化来看，商品是有种类，产地，价格等特征的，从这个角度来看，有两个主题，一个是商品出售，一个是商品本身。组织起来就是雪花型。实际项目中，由于操作型系统业务的复杂性导致本身产生了大量的数据，所以，组织起来也以雪花型居多。那么围绕着主题，该如何设计事实表和维度表呢？也是有规律可循的。事实表和维度表的分界线事实表是用来存储主题的主干内容的。以日常的工作量为例，工作量可能具有如下属性：工作日期，人员，上班时长，加班时长，工作性质，是否外勤，工作内容，审核人。那么什么才是主干内容？很容易看出上班时长，加班时长是主干，也就是工作量主题的基本内容，那么工作日期，人员，工作性质，是否外勤，工作内容是否为主干信息呢？认真分析特征会发现，日期，人员，性质，是否外勤都是可以被分类的，例如日期有年-月-日的层次，人员也有上下级关系，外勤和正常上班也是两类上班考勤记录，而上班时长和加班时长则不具有此类意义。所以一般把能够分类的属性单独列出来，成为维度表，在事实表中维护事实与维度的引用关系。在上述例子中，事实表可以设计成如下WorkDateEmployeeID，WorkTypeID，Islegwork，Content，而时间，员工，工作类型，是否外勤则归为维度表。总的来看，和其他建立主外键关系的表也都一样。但是维度表的建立是需要有层次的（虽然不是必须，但是也是典型特征），而事实表的建立是针对已经发生的事实的，是历史数据的存档，也就是说是不应该修改的。以测试部测试软件的Bug为例。每个Bug都是一个事实。这个Bug的状态在数据字典里可能设计成新建，转派，修复，拒绝等等。那么在事实表中Bug表中有一个字段为Status。当测试员或者开发人员改变了这个状态的值，事实表中该如何更新呢？是直接更新Status还是什么其他的方式？显然，为了能够追踪这个Bug的历史信息，应该是重新插入一条新的记录。那么这和以往的数据库设计有什么区别呢？可以看出对于原始记录和新插入的记录，其他字段全部是相同的，也就是全部冗余的。如果以BugID作为主键，这时候会发现主键都是冗余的（当然，插入之前只能删除主键）。所以可以看出，事实表一般是没有主键的。数据的质量完全由业务系统来把握。例如，在AdventureWorksDW数据库中，事实表是类似于如此事实表中的外键是指向维度表的，那么维度表又有什么特征呢？以时间维度为例可以看出，维度表一般是有主键的。代表该类物质的一个单一个体，其他的字段一般都是有层次关系的，例如2009年2月19日是主键，那么它会有年--月--日这样的层次，为了方便统计，年月日不会在做聚合的时候才计算出来，而是在维护记录时已经计算出来。那么这些字段的冗余是否值得呢？可以这样解释：维度表的数据一般是比较少的，这个少是指相对事实表来讲的。因为事实表是与日俱增，而维度表则增长缓慢，所以绝对数字也不会太大。在事实表和维度表做连接查询的时候，会产生与事实表一样大的数据量，如果还需要groupbyYear（TimeKey）的话，其一是会增加计算，其二是由于引入了计算，索引会失效。这个代价比引入冗余字段要大的多。以AdventureWorks为例，它总共引入了日历年-月-日，财年-月-日，还有日历年-周-日，财年-周-日等等多个层次。那么它在每个层次不同级别上做聚合都是不需要引入函数来做Year（TimeKey），Month（TimeKey）这样的运算。总的说来，事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。如何定义数据库表之间的关系2007-12-2817:32:35|分类：数据库|字号大中小订阅特别说明数据库的正规化是关系型数据库理论的基础。随着数据库的正规化工作的完成，数据库中的各个数据表中的数据关系也就建立起来了。在设计关系型数据库时，最主要的一部分工作是将数据元素如何分配到各个关系数据表中。一旦完成了对这些数据元素的分类，对于数据的操作将依赖于这些数据表之间的关系，通过这些数据表之间的关系，就可以将这些数据通过某种有意义的方式联系在一起。例如，如果你不知道哪个用户下了订单，那么单独的订单信息是没有任何用处的。但是，你没有必要在同一个数据表中同时存储顾客和订单信息。你可以在两个关系数据表中分别存储顾客信息和订单信息，然后使用两个数据表之间的关系，可以同时查看数据表中每个订单以及其相关的客户信息。如果正规化的数据表是关系型数据库的基础的话，那么这些数据表之间的关系则是建立这些基础的基石。出发点下面的数据将要用在本文的例子中，用他们来说明如何定义数据库表之间的关系。通过Boyce-CoddNormalForm（BCNF）对数据进行正规化后，产生了七个关系表：Books:{Title*,ISBN,Price}Authors:{FirstName*,LastName*}ZIPCodes:{ZIPCode*}Categories:{Category*,Description}Publishers:{Publisher*}States:{State*}Cities:{City*}现在所需要做的工作就是说明如何在这些表之间建立关系。关系类型在家中，你与其他的成员一起存在着许多关系。例如，你和你的母亲是有关系的，你只有一位母亲，但是你母亲可能会有好几个孩子。你和你的兄弟姐妹是有关系的——你可能有很多兄弟和姐妹，同样，他们也有很多兄弟和姐妹。如果你已经结婚了，你和你的配偶都有一个配偶——这是相互的——但是一次只能有一个。在数据表这一级，数据库关系和上面所描述现象中的联系非常相似。有三种不同类型的关系：一对一：在这种关系中，关系表的每一边都只能存在一个记录。每个数据表中的关键字在对应的关系表中只能存在一个记录或者没有对应的记录。这种关系和一对配偶之间的关系非常相似——要么你已经结婚，你和你的配偶只能有一个配偶，要么你没有结婚没有配偶。大多数的一对一的关系都是某种商业规则约束的结果，而不是按照数据的自然属性来得到的。如果没有这些规则的约束，你通常可以把两个数据表合并进一个数据表，而且不会打破任何规范化的规则。一对多：主键数据表中只能含有一个记录，而在其关系表中这条记录可以与一个或者多个记录相关，也可以没有记录与之相关。这种关系类似于你和你的父母之间的关系。你只有一位母亲，但是你母亲可以有几个孩子。多对多：两个数据表里的每条记录都可以和另一个数据表里任意数量的记录（或者没有记录）相关。例如，如果你有多个兄弟姐妹，这对你的兄弟姐妹也是一样（有多个兄弟姐妹），多对多这种关系需要引入第三个数据表，这种数据表称为联系表或者连接表，因为关系型系统不能直接实现这种关系。建立关系在开始着手考虑建立关系表之间的关系之前，你可能需要对数据非常熟悉。只有在熟悉数据之后，关联会比你刚开始的时候更明显。你的数据库系统依赖于在两个数据表中找到的匹配值来建立关系。如果在数据库系统中发现了一个匹配值，系统将从两个数据表中提取数据并创建一个虚拟的记录。例如，你可能想要查看某个特定的作者所写的全部书籍，在本文中，系统将从“Books”和“Authors”这两个数据表中查找相关的匹配值。需要注意的是，在大多数情况下，查询的结果是动态的，这意味着对这条虚拟记录所做的任何改动都将可能作用到底层的数据表上，这一点是非常重要的。进行匹配的值都是主键和外键的值。（关系模型不要求一个关系必须对应的使用一个主键来确定。你可以使用数据表中的任何备选关键字来建立关系，但是使用主键是大家都已经接受的标准。）主键（primarykey）唯一的识别表中的每个记录。而外键（foreignkey）只是简单的将一个数据表中的主键存放在另外一个数据表中。同样地，对于你来说也不需要做太多的工作——只是简单地将主键加到关系表中，并将其定义为外键。唯一需要注意的是，外键字段的数据类型必须和主键的数据类型相同。但是有些系统可以允许这条规则有一个例外，它允许在数字和自动编号（autonumbering）字段（例如在SQL服务器系统中访问Identity和AutoNumber）之间建立关系。此外，外键的值可以是空（Null），尽管强烈建议在没有特别原因的情况下，不要让外键为空。你有可能永远都不会有机会来使用需要这项功能的数据库。现在回到我们的示例关系表，并开始输入合适的