企业信息化工厂
- 数据集市中的一致性，由于企业信息化工厂的数据集市是从集成仓库中获得信息的，因此至少从维度建模的角度来看，一致性维护的问题减少了。尽管合并不同数据源的问题依然在，但是负担主要在设计者身上。尽管压力降低了，但是数据集市的设计者仍然应该计划并用文档说明一致性。
- 跨数据集市的一致性，因为数据集市是为部门级用户组织分析型数据库，跨数据集市的一致性要求也被放宽了。如果有过程维度不一致情况下，需要开发另外的数据集市。在企业信息化工厂体系结构中，数据集市内的一致性是非常重要的，没有必要规划跨数据集市的一致性，尽管这样做能够消除因支持跨功能分析而进行的额外的开发。
独立型数据集市
- 与不一致性共存，通常商业目标需要考虑利益问题，但没有足够的资金开发企业级的一致性战略，或者有没支持战略规划阶段的政策都是常见的。
- 一致性实践，如果团队能够确定具有企业范围的维度，全面考虑满足的企业需求和需要它们的操作源，开发的维度效果就比较好，这些维度能在区分其他的区域需求被具体化，而不是将他们设计限制于开发的解决方案。
- 维度改装，将已经存在的数据仓库基础设施可通过改装维度成为一致性维度。设计模式为，将不一致的维度中的每一行映射到对应企业维度模型的表中。添加企业维度模型中缺少的附加属性。在独立型数据集市中，采用映射的方法重新分配事实表外键以便能够引用一致性维度。表面合理，但是简短的说明并没有考虑到数据的不一致性，并且完全忽略了对查询独立型数据集市的前端应用程序的影响问题。在数据方面，在两个不一致维度表行间建立一对一匹配是不可能的。同样严峻的考验来自于对前端报表和应用程序的影响。内容的变化也可能受影响
维度表的功能内容
维度表的集合是星型模型的关联部分
- 维度表键
- 维度表很宽
- 文本属性
- 维度表中的某些属性经常不会与其中的其他属性直接相关
- 非规范化，维度表是扁平的，不是规范化的
- 上钻与下钻，维度表中的属性提供了获取从高层次汇总的信息到低层次细节信息的能力
- 多层次结构
- 更少的记录
维度表的数据内容
提供丰富和全面的维度属性集合，每个新增的数据都将会显著地提高分析的可能性。
- 公共组合，在操作型系统中，经常采用的方法是将数据元素尽可能分解为构成其内容的U盾哦个组件。采用这种方法，可以将不同组件按照需要加以合并，例如客户姓名可以分解并以first_name、middle_initial、last_name的方式存储。与操作型模式不同，维度模式还应包含这些组件的各种组合。
- 代码与描述符，在操作型系统中，通常将某一领域中的可列值以代码的形式表示，同时使用另外的表来描述这些代码。这样做的目的是方便对可列值得维度并提高存储效率。从分析 和应用的角度考虑，代码和描述都是可用的维度。
- 标志以及标志值，在操作性系统中，如果列的值为布尔类型，通常将它作为标志。在维度设计时，这些标志可用于过滤查询，或者分组事实，通过采用描述型的值存储标志，可以方便地使用标志。
- 多列组合字段，操作型系统通常包含由多个部分组合而成的字段列，每个部分各自具有不同的含义。在维度设计时，全部的属性江北存储，用于分割该数据的多个子属性也将被存储，如果这些子属性是代码，那么还要增加对应的描述值。
- 带有数字值的维度，如果一个属性通常用于聚集或者汇总，那么它就是事实，如果通常被用于提供聚集或者汇总的环境，那么它就是维度。
- 行为维度与混合属性，利用行为模式分析事实是一种强有力的分析技术。基于事实计算得到的维度称为行为维度。行为分组作为维度。若对行为分组的更新不太频繁，采用这样的方法将会起到很好的效果。如果行为分组在每次使用时都需要更新，该方法可能更加合理。但是问题在于需要耗费更多的时间，因为在每次执行报表时都需要计算分组情况。
行为维度
行为问题是一种基于队过去维度成员行为进行分组或过滤事实的方法，行为维度将事实转换为维度，以确保获得请打的分析能力，不需要使用复杂查询或者详细处理的分析。
在查询期间将事实转换为维度
- 识别问题中设计的每个维度成员的过去行为
- 将这些信息作为研究当前行为的查询的一部分
由于处理的需要，采用此种方式的查询不能很好的执行。为解决此问题，通常需要在批量处理窗口起家指定行为表报，以便在用户请求时，该报表已经被缓存并为查看做好准备。当然这种方式破坏了正常循环获得答案。差生了新问题。但是注意，中断用户不能将行为报表组合到一起。
设计并使用行为维度
- 与另一个维度的过去关联，行为属性可用于获取维度行信息的历史关联，这些信息通常存储在另外一个表中。如果没有行为维度，过去的关联只能通过查询事实表获得，通常关联的维度是日期，并被添加到维度表中表示过去的重大事件。
- 历史事实，行为属性也能捕获维度表中关于有效存放事件具有历史意义的事实，就想在属性名称上所体现，历史事实可以用来过滤，聚合，或者是获得订单查询结果。
- 分类事实，尽管历史事实在查询限制方面是有效的，如果需要用来推进分组，它就变得不那么有效。
行为维度设计要素
必须仔细考虑维护的含义。维度具有缓慢变化特征将导致表大小快速增长，而且他们频繁地更新将给ETL带来巨大的压力。
行为属性的更新频率使ETL负担过重，需要最新信息的情况极少发生，可以通过查询事实来生成报表。
维度表中的组合维度
维度属性分组到维度中，用于表示引用信息的主要分类。杂项维度将那些本身没有相似性的属性收集起来，如果将规范化理论应用到维度表中，结果称为雪花模式。即使不采用规范化理论，雪花模式也仍然可以作为特定软件工具使用。维度设计完全接纳对信息的冗余存储。
- 基于相似性的组合维度，维度表包含组合维度属性以表示引用信息的主要分类，这些分类往往带有强烈的业务特征。
- 无相似性的杂项维度，在某些情况下，创建一个不存在实际关系的维度表时有用的，采用该技术有益于需要控制快速变化维度表的生长速度的情况。
- 雪花模式及其支架表，维度表中存在大量冗余，使用实体关系建模时，采用规范化理论从关系设计中消除此类冗余。不要采用规范化理论知道维度表的设计工作。需要采用雪花模式和支架表的情况是一种特例而不能当做规则来使用
- 冗余带来的好处，性能、可用性和一致性。在进行维度设计时应该容忍冗余的存在，详尽地存储每一个维度属性，将大大提高系统性能，增强可用性，确保在多个应用中保持一致。规范化理论更适合于操作型系统而不是分析型系统
维度表特性
与实体关系模型不同，维度模型不能揭示相互关联的属性之间的关系，上下文关系易于传递给事实表，而天然存在的相关性则由维度表中共存的属性表示。
关联维度属性的两种方法
- 描述环境的明确的关系，每个事实表都有一个引用维度表的外键，这些引用为事实表提供了维度环境，这些链接也可以看做提供了维度表之间存在的关系
- 描述亲和性的隐含关系，维度模型还包含不能通过连接而明确的关系。维度属性之间的关系可能隐含在他们的共存的表中，这些关系只在单独的环境中存在，表示自然亲和性不是基于过程活动的关系。
如何确定连个维度是否属于同一维度
最好的方法是考虑属性在何处相关，在何处使用。例如考虑是否具有自然的亲和性，或者在不同环境中是否有关系，或者那些趋向于共享稳定关系的属性可能被储存在一起，或者那些仅存在事件、事务或条件等情况下相关的属性，可以将他们归入不同的事实表中，存在疑惑不定时，可以考虑不同设计方法的可浏览性。
基于亲和性分组维度 ，通常根据自然亲和性将维度分组为不同的表，另一方面，一些属性只能基于事务或活动发生关联。当连个维度属性共享一个自然亲和性关系，并且同时出现在一种环境中，他们属于同一个维度表。当他们的关系由事务或活动来决定，并且存在于不同的环境中，应该将他们放置在不同的维度表中。
可浏览性测试，如果难以确定连个属性是否属于同一维度表，可以考虑他们的被使用的情况。