维度表事实表

关注

转载最新推荐文章于 2026-05-23 10:32:12 发布 2.4k 阅读 AI 写同款· GEO 优化 ›

【Bug已解决】Context window exceeded / Token limit reached — Claude Code 上下文窗口超限解决方案 Claude Code 长会话中报上下文窗口/Token 超限，本质是对话历史、文件内容、工具结果累积超过 200K 上限。文中给出 /clear、/compact、分批读大文件、限制工具输出、配置 autoCompact 等完整方案。阅读详情

转至：http://www.cnblogs.com/47613593/archive/2009/02/20/1394581.html

维度表示你要对数据进行分析时所用的一个量, 比如你要分析产品销售情况, 你可以选择按类别来进行分析,或按区域来分析. 这样的按..分析就构成一个维度。前面的示例就可以有两个维度：类型和区域。另外每个维度还可以有子维度（称为属性），例如类别可以有子类型，产品名等属性。

下面是两个常见的维度表结构：

产品维度表：Prod_id, Product_Name, Category, Color, Size, Price
时间维度表：TimeKey, Season, Year, Month, Date

而事实表是数据聚合后依据某个维度生成的结果表。它的结构示例如下：

销售事实表：Prod_id(引用产品维度表), TimeKey(引用时间维度表), SalesAmount(销售总量，以货币计), Unit(销售量)

上面的这些表就是存在于数据仓库中的。从这里可以看出它有几个特点：

1. 维度表的冗余很大，主要是因为维度一般不大(相对于事实表来说的)，而维度表的冗余可以使事实表节省很多空间。
2. 事实表一般都很大，如果以普通方式查询的话，得到结果一般发的时间都不是我们可以接受的。所以它一般要进行一些特殊处理。如SQL Server 2005就会对事实表进行如预生成处理等。
3. 维度表的主键一般都取整型值的标志列类型，这样也是为了节省事实表的存储空间。

事实表和维度表的分界线

事实表是用来存储主题的主干内容的。以日常的工作量为例，工作量可能具有如下属性：工作日期，人员，上班时长，加班时长，工作性质，是否外勤，工作内容，审核人。那么什么才是主干内容？很容易看出上班时长，加班时长是主干，也就是工作量主题的基本内容，那么工作日期，人员，工作性质，是否外勤，工作内容是否为主干信息呢？认真分析特征会发现，日期，人员，性质，是否外勤都是可以被分类的，例如日期有年-月-日的层次，人员也有上下级关系，外勤和正常上班也是两类上班考勤记录，而上班时长和加班时长则不具有此类意义。所以一般把能够分类的属性单独列出来，成为维度表，在事实表中维护事实与维度的引用关系。

在上述例子中，事实表可以设计成如下
WorkDate EmployeeID，WorkTypeID，Islegwork，Content，
而时间，员工，工作类型，是否外勤则归为维度表。

总的来看，和其他建立主外键关系的表也都一样。但是维度表的建立是需要有层次的（虽然不是必须，但是也是典型特征），而事实表的建立是针对已经发生的事实的，是历史数据的存档，也就是说是不应该修改的。以测试部测试软件的Bug为例。每个Bug都是一个事实。这个Bug的状态在数据字典里可能设计成新建，转派，修复，拒绝等等。那么在事实表中Bug表中有一个字段为Status。当测试员或者开发人员改变了这个状态的值，事实表中该如何更新呢？是直接更新Status还是什么其他的方式？显然，为了能够追踪这个Bug的历史信息，应该是重新插入一条新的记录。那么这和以往的数据库设计有什么区别呢？可以看出对于原始记录和新插入的记录，其他字段全部是相同的，也就是全部冗余的。如果以BugID作为主键，这时候会发现主键都是冗余的（当然，插入之前只能删除主键）。所以可以看出，事实表一般是没有主键的。数据的质量完全由业务系统来把握。

例如，在AdventureWorks DW数据库中，事实表是类似于如此

事实表中的外键是指向维度表的，那么维度表又有什么特征呢？以时间维度为例

可以看出，维度表一般是有主键的。代表该类物质的一个单一个体，其他的字段一般都是有层次关系的，例如2009年2月19日是主键，那么它会有年--月--日这样的层次，为了方便统计，年月日不会在做聚合的时候才计算出来，而是在维护记录时已经计算出来。那么这些字段的冗余是否值得呢？可以这样解释：维度表的数据一般是比较少的，这个少是指相对事实表来讲的。因为事实表是与日俱增，而维度表则增长缓慢，所以绝对数字也不会太大。在事实表和维度表做连接查询的时候，会产生与事实表一样大的数据量，如果还需要group by Year（TimeKey）的话，其一是会增加计算，其二是由于引入了计算，索引会失效。这个代价比引入冗余字段要大的多。以AdventureWorks为例，它总共引入了日历年-月-日，财年-月-日，还有日历年-周-日，财年-周-日等等多个层次。那么它在每个层次不同级别上做聚合都是不需要引入函数来做Year（TimeKey），Month（TimeKey）这样的运算。

总的说来，事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。

维是分析问题的角度，每一维代表一个统一的访问数据仓库中信息的路径。

在实际问题中，有些维包含多个层次。

事实是各个维度的交点，是对某个特定事件的度量，只有当特定维值的组合没有造成空穴时，一个事实才会存在。事实的数量属性称为度量。

事实数据和维度数据的识别必须依据具体的主题问题而定。“事实表”，用来存储事实的度量（measure）及指向各个维的外键值。维表用来保存该维的元数据，即维的描述信息，包括维的层次及成员类别等所产生的数据，事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据（事实），并且这些数字信息可以汇总，以提供有关单位作为历史的数据，每个事实数据表包含一个由多个部分组成的索引，该索引包含作为外键的相关性纬度表的主键，而维度表包含事实记录的特性。事实数据表不应该包含描述性的信息，也不应该包含除数字度量字段及使事实与纬度表中对应项的相关索引字段之外的任何数据。

包含在事实数据表中的“度量值”有两中：一种是可以累计的度量值，另一种是非累计的度量值。最有用的度量值是可累计的度量值，其累计起来的数字是非常有意义的。用户可以通过累计度量值获得汇总信息，例如。可以汇总具体时间段内一组商店的特定商品的销售情况。非累计的度量值也可以用于事实数据表，单汇总结果一般是没有意义的，例如，在一座大厦的不同位置测量温度时，如果将大厦中所有不同位置的温度累加是没有意义的，但是求平均值是有意义的。

一般来说，一个事实数据表都要和一个或多个纬度表相关联，用户在利用事实数据表创建多维数据集时，可以使用一个或多个维度表。

再举个实际的例子。银行对存款记账，A表中存放实际数据，包括账号、所属机构号、存款金额等，B表存放机构号和机构名称的对应关系。则A是事实表，B是维表。

维度表可以看作是用户来分析数据的窗口，纬度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息，维度表包含帮助汇总数据的特性的层次结构。例如，包含产品信息的维度表通常包含将产品分为食品、饮料、非消费品等若干类的层次结构，这些产品中的每一类进一步多次细分，直到各产品达到最低级别。

在维度表中，每个表都包含独立于其他维度表的事实特性，例如，客户维度表包含有关客户的数据。维度表中的列字段可以将信息分为不同层次的结构级。

简单的说：
    1、事实表就是你要关注的内容；
    2、维表就是你观察该事务的角度，是从哪个角度去观察这个内容的。

    例如，某地区商品的销量，是从地区这个角度观察商品销量的。事实表就是销量表，维表就是地区表。