大维度
大维度很深，有很多记录。大维度很宽，有很多属性。满足任何一种情况，都可以说这是个大维度。
由于数据量很大，很多包含大维度的数据仓库功能可能会很慢，效率很低，需要设计有效的方法，原则正确索引或者采用其他优化技术处理以下问题
- 向大维度表填充数据
- 非限制维度的浏览功能，尤其是那些属性基数较小的维度
- 多维度限制属性值的浏览时间
- 对事实表的查询涉及大维度表时，效率低
- 为处理第二类修改需要增加额外的记录
多层次的结构
大维度通常拥有多层次的结构，不同的业务需要的不同属性可能不同。
快速变化中的大维度
在大多情况下，第二类修改适合处理快速变化的维度:
- 如果维度表扁平，它允许在许多维度中不同属性间进行对称浏览
- 即使加入了额外的维度表行，维度表的基本结构依然不变
- 只有当最终用户的查询涉及修改过的属性时，同一个客户的多行记录展现出来，对其他的查询是看不出有多行记录的
将大维度分解成一个或者多个比较简单的小维度表: - 将快速变化的属性放到另一个维度表中，而缓慢变化的属性放在原来的表里面
废弃维度 :
一些标志与文本，不会在维度表中出现，如何处理 - 忽略掉所有标志和文本。可能会丢掉一些有用的信息
- 将标志和文本原封不动地放在事实表中，会增大事实表
- 为每个标志和文本建立一个独立的维度，大大增加维度表的数目
- 只保留那些有意义的标志和文本，将所有有用的标志放在一个单独的废弃的维度中，废弃维度中的属性对涉及标记文本的查询来说是有用的
分解大型维度
任意分隔维度表，虽然该方法解决了数据管理员提供的问题，但也带来的一系列的问题。
-
连接选择，对于表本身来说不是问题，然而这可能导致混淆，并且可能为自动建立查询的商业智能工具带来问题
- 事实表外键声明，将每个维度表行表示成两部分，导致两个 维度表共享相同的代理键。提供完整的维度表示。事实表中的外键引用了涉及的表，但是关系型数据库管理系统却不能对这种双重引用进行配置。一个外键只适用于一个表。
- ETL处理，对ETL开发人员来说，将表分裂为两部分踢出了独特的挑战。
-
分隔维度方法的替代方法
- 两个维度，当某个维度具有海量属性时，这一情况通常可以作为存在两个相异维度的标志。如果确定存在相异维度，可以重新设计维度，将其划分为两个表，每一个 表都有各自的代理键，这连个维度将通过事实表分享明确的关系。
- 将自由形态的文本字段定位到支架表，由大量属性造成的过长的行通常是在维度表中包含多个自有形态的文本字段的结果。他们可以被重新定位到不同的表中，并且用外键引用进行替换。
- 寻找子类型，在很多情况下，维度表包含大量的属性组，每个属性组只作为所在行的一个子集。在包含特殊子类型属性的情况中，维度行的规模可以通过建立仅包含共享属性核心的维度和相互独立的自定义维度来控制。当需要分析所有子类型，使用核心维度，当只研究特定子类型时，使用自定义维度。
- 考虑微型维度，将维度属性的子集分离，使用子集作为被称为微型维度的新维度的基础。与杂项维度类似，此类表的属性不表示单独户的分析概念，新维度表能顾通过心智可浏览性开销来缓解属性的规模问题。
- 与其他维度一样，微型维度表被分配了一个代理键，与分隔维度不同的是，微型维度不共享原始维度表的代理键，原始维度和微型维度没有一对一关系，事实表将使用不同的外键来引用原始维度和微型维度。
- 当表增长过快或存在大量的类型2属性，导致对变化的处理成为瓶颈时，一个或多个微型维度可能会有用，将不稳定的属性移动到微型维度表，用所有可能值填充。
- 采用微型维度破坏了可浏览性，维度表和微型维度之间只通过事实关联，但是用户很少希望去构建针对某个大型维度最详细的浏览查询。提供维度和微型维度间有限的可浏览性是可能的。可以通过在引用微型维度中添加外键来实现。通过将微型维度中的键保存在维度中以实现交叉可浏览性也存在限制，只能获得微型维度中的当前信息，并未保存历史信息。
- 如果需要的话，维度和微型维度表之间的全部历史关系，可以通过设计额外的事实表得以保留。
角色维度和别名的使用
业务过程的度量可以包含维度的多个实例。
单一表，多重关系 ,维度表可以参与事实表中多个关系，每个关系称作一个角色。
利用别名来存取角色，历史数据库视图，创建不同的维度表视图来表示每个角色，采用适当的外键列将事实表与每个视图连接。SQL别名也可以
避免空值
一个不太规范却实际的解决方案是当数据无效时存储特定的值。如0或者N/A来表示。
空值带来的问题
- 空值是没有意义的，但它与空白、空串或者零值存在明显的区别。
- 空值不代表任何事物，不能被认为是等同于任何事物，甚至不能与其他的空值等同。如果涉及空值，任何传统的比较都要失败。
- 不要允许在外键列中使用空值，即时为存储NULL值，也需要替换维度列的连接语法并创建维度NULL实例值。
- 当事实表和维度表之间的关系可选择时，随着空值而来的问题能通过在维度表中创建特殊的行来加以避免。该行将会被不包含对应的维度细节的事实行引用。
- 采用特殊行的方法避免了一些与空值相关的负面影响，但是仍然影响可浏览性，需要在查询时果粒橙特殊的行。
特殊情况行的用途
- 可选关系，事实表和维度表之间的可选关系并不常见，但是的确存在，当不是事实表的部分粒度时，可选维度能被接受。
- 无效数据，在事实表中加载数据行时，当与实务关联的产品无效时，可以将一个特别行添加到产品维度中。
- 迟到的数据，有事数据仓库在获得相关细节前就获得事务，这种情况发生在加载间隔短或者史诗加载数据的环境。当事务的细节尚不存在时，将事实与维度表中的用于指示位置产品的特殊行关联。避免了将事务排除在数据仓库之外的可能，以便队未来能够获得事务并对其进行更新。
- 未来事件，涉及时间，当事实表行代表一些涉及期限的事务时，采用记录一队日期的方式是非常有效的：事务的有效日期和截止日期。