用信息来支持更有事实依据的决策制定过程。
业务人员复杂的思考过程 能在系统上直观的通过数据、比大小的方式判断 （政企圈的号码识别（可能会考虑很多情况）最后给个指数）
数据内容在标识方面应该是见名知义
对仓库中的数据进行切割处理的分离与合并操作
操作数据的存储(ODS,Operational Data Store)
事实表
富有意义的业务描述符号的使用，减少出现误解的可能性
操作编码通常包含一些信息在里面，比如，开头两位数字可能标识业务行业，而另外两位数字可能标识地域分布。 取出含义并容易用来进行过滤、成组或者形成报表的分开的维度属性形式提供给用户。 维度表时常描述业务中的层次关系。
粒度就是同一维度下，数据的粗细程度，如果对粒度方面的内容很清楚，那么维度的确定就很容易了
四步维度设计过程： 1、选取要建模的业务处理过程 2、定义业务处理的粒度 3、选定用于每个事实表行的维度 4、确定用于形成每个事实表行的数字型事实
原子型数据是所收集的最详细的信息，这样的数据不能再做进一步的细分。 应优先考虑为业务处理获取最有原子性的信息而开发维度模型。
数据仓库几乎总是要求在每个维度可能得到的最低粒度上对数据进行表示的原因，并不是因为查询想看到每个低层面的行，而是因为查询希望以精确的方式对细节知识进行抽取。
原子型数据可为分析方面提供最大限度的灵活性，因为它可以接受任何可能形式的约束，并可以以任何可能的形式出现。 维度模型的细节性数据是基本不变的
销售面积是商场的一个不变属性，并且作为报表约束或者行标题使用的情况比用做求和的可加分量要多得多。 因为这些原因，可以确信销售面积是属于商场的维度表。
必须避免在事实表中出现空关键字，在这方面显得比较合适的设计师在对应的维度表中包括一行来标识该维度对度量值不可用。
赞成将四个维度糅合在一起，基于如下考虑： 1、既然四个因果机制是高度相关的，那么组合起来的单个维度就不会比分开的任何一个大许多； 2、组合起来的单个维度能够高效地进行浏览，以弄清各种不同的价格降低、广告、展销与优惠券是如何在一起应用的。 在维度表中所进行的浏览，并不能解释促销对哪家商场和哪种产品产生了影响，这类信息放在事实表中。 赞成四个维度分开，基于如下考虑： 1、在用户分开考虑这些机制时，分开的维度对业务群体来说更容易理解。这一点在业务需求调研期间就会暴露出来。 2、独立维度的管理相对组合维度管理，表现的更加直接了当。以后如果新增了其他维度，比较方便。
非事实型事实表：不具有度量指标，仅仅能够捕获所涉及的关键字之间的关系； 什么产品属于促销之列却没有卖出？1：某天促销产品的范围；2：销售事实表确定卖出了什么产品
退化的事务编号维度：比如POS事务编号这样的固有操作型票据编号，应该自然而然地放在事实表中，而不用连接到维度表。 退化维度在事实表粒度表示单个事务或者事务分列项目时是很常见的，因为它表示了父实体的唯一标识符。
当形成的单个新维度比分开的维度的笛卡尔积显著地小，那么意味着对维度合成方式的选取是适当的。 ●维度表的规范化会增加维度表或子维度表的数量，在查询数据时需要更多的外键联合，因此会降低查询性能。 ●雪花模式实现维度表的规范化，有利于节省空间。 ●由于维度表与子维度表存在多重联合，所以雪花模式查询比星形模式查询更复杂。 ●对于使用数据仓库系统的业务用户而言，使用雪花模式的难度更大，因为他们操作的数据库表比星形模式多。 ●创建汇总表，并将它（们）与相应的维度表建立联合，可以减少执行时间，提高查询性能。
存在特别多的维度一般都预示了不同维度并不是完全独立的，而应该组合成单个维度这样的一个迹象。 将体系的元素在事实表中表示成分开的维度，是维度建模方面的一种错误做法。
要避免在数据仓库关键字中包括带有技巧性的内容，查询和数据存取应用都不应该在关键字上存在内置的相关性，因为这样的逻辑容易变得无效。
数据仓库中维度和事实表之间的每个连接都应该没有明确含义的整形代理关键字来建立。
page85
如果觉得《【读书笔记】数据仓库工具箱 维度建模指南》对你有帮助，请点赞、收藏，并留下你的观点哦！
