本文主要是介绍数据仓库——特殊类型的星型模式，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
特殊类型的星型模式
通过维度表示的事物通常可以按照类别或者类型细分。有时想要在维度表中记录的属性类型是多样的。
尽管类型相同，但是却存在很大差别。在此情况下，维度模型的设计者处于两难境地，一方面希望跨越所有类型来研究业务过程，另一方面希望使用特定类型的属性来研究每个特定的类型。
数据仓库必须反映出过程分析和度量的所有方法。如果受限于单个的分析观点，数据仓库的整个效应将会大大降低。管理层可能想要分析全局的类型，使用可共享的事实和维度。当专注于某个特定类型时，也可能需要做更详细的表达，使用特定类型的素有事实和维度，不能实现这些功能将会破坏整个解决方案的价值。
使用单一星型模式
建立包含所有可能属性的单一星型模式，该方法是完全有效的，允许企业进行跨类型的分析或者进行特定类型的分析，包含在查询或报表中的属性确定了关注点。
缺点 ：有时在单一星型模式中包含所有属性是不现实的，在技术方面，维度的频繁变化可能导致产生过多的属性。单一事实表也可能存在语义缺陷。合并素有可能属性的星型模式可能会导致无意义的报表。
核心和自定义星型模式
核心和自定义维度表
核心星型模式包括所有公共属性且支持跨所有类型的分析，特定类型的自定义星型模式包括所有的核心属性以及任何特定类型的属性。
为了成功实现核心/自定义设计，需要使用核心维度和每个特定类型的自定义维度之间的公共属性具有一致性。
有时存在自定义属性却没有自定义事实的情况，但是自定义事实表仍然可以避免分析意外。物理实现可以采用独立且不同的核心和自定义表的方式。或者使用数据库视图来实现。
异构维度属性能通过设计多个维度表来处理，核心维度包含所有公共属性；自定义维度包含核心属性和特定类型的属性。
- 一致性属性：核心和自定义维度的公共属性应该是一致的，这意味着他们必须在结构和内容方面是相同的。
- 公共代理键：核心和自定义维度表共享一个公共键域。可以将核心维度看做每个自定义维度的公共属性的联合。
- 缓慢变化维度：类型2缓慢变化会对核心/自定义设计产生明显不良的影响。当变化的值恰巧在一个自定义列时会发生一个奇怪的副作用。在自定义表中，发生变化的项和旧行和新行是完全不同的，其他所有方面，新旧版本均相同。
核心和自定义事实表
强烈建议在设计相应的自定义事实表时，避免由此可能带来的分析混乱，实现不需要物理表；视图或类似的备选方案就足够了。
- 用于所有类型的相同事实：如果为所有类型记录了相同的事实，就能发现维度的核心或者自定义版本嫩通过分析情况按需求被连接到事实表。在跨所有类型分析时，使用核心版本表；分析将被限制在公共维度属性上，当分析某个特定的类型时，使用自定义版本；分析包含特定类型的属性。通过公共键值域可以方便地获得交互能力。注意，可能产生任何连接到自定义维度的查询都隐含地受到特定类型事实表的约束。可以通过建立一个特定的自定义副本来解决没每个副本只包含一个特定产品类型的行，结果是一个核心和自定义星型模式的集合。（建立视图）
- 特定类型的事实：当特殊事实与特定类型关联时，自定义事实表称为必要的，核心事实表包含所有事实的行。并且将包含所有类型的公共事件。为每个类型建立自定义事实表，这些事实表包含核心事实以及任何特定类型的事实表。对维度表，一致性是必须考虑的事情；公共事实表必须具有相同的结构和内容。
- 分析需要首先选择适当的星型模式。跨所有类型的分析使用核心星型模式实现；分析将被限制与核心事实和维度中。需要针对某个特定类型的事实或者为敌的分析将使用适当的自定义星型模式执行，分析将被限制于特定类型的事务中。
其他注意事项
- 重叠自定义维度：有时在一个维度中存在多个类型等级，当在类型中存在类型时，可能想要设计多重等级的自定义星型模式。在此情况下，创建的自定义事实表中包含冗余是不可避免的，可以选择一个基于视图的解决方案来避免产生冗余事实表，甚至是冗余维度表。
- 使用支架表：针对核心/自定义主题的不同方法力图消除自定义表中核心属性的冗余。这种防范能节约空间，但是受限于雪花模式的潜在缺点。
- 使用具有核心维度的层次桥接表：涉及实体的集合似乎参与了某种层次的情况，但是又不能明确层次的等级。常常发生在区域或者组织架构中，解决这个问题的关键在于认识到一组事物具有不同的属性。虽然在没有源系统作为同一事物的例子来表示他们，同时没有业务员以这种方式描述他们，当发现他们都被用来汇总行为时，共性是明显的哪些被看做一组不同的维度，实际上是未被发现的核心维度的自定义版本。
- 有时，两个或者多个维度在使用后才发现他们具有一些相同的核心属性，一种选择是忽略该问题并且通过一个复杂的报表过程来协调数据。已经创建了自定义维度，而常见的属性没有一致性的名称或者数据类型，并且他们也不存在可共享的关键域。在构建核心维度要求对原始表进行调整，调整他们的内容，重新分配键值，如此一开，在关联的事实表上会产生连锁反应，外键引用被更新，现存的报表也要求用SQL重写。
使用通用属性
通用属性的使用试图用一个列的集合来捕获类型的多样性，在维度表中，描述核心属性的列集合通过一系列多用途的列来补充，目的是随着类型来变化。
在存储信息时，这一设计是十分灵活的，允许为大量类型存储自定义属性并且都存储在单一表中，有的类型可以利用所有的通用属性，其他的类型使用其中的一些，只要拥有足够的适当数据类型的通用列，就可以适合任意属性，同样的技术可以用来捕获事实表的变化。
尽管存储信息十分灵活，当检索信息时，通用设计往往会失去灵活性，因为列名采用通用定义，所以构建查询时需要引用列中信息。同样查询结构将需要与解码的属性标签重新打包，标准的查询和报表软件往往不能支持这样的需求。
通用属性的使用通常是不受欢迎的，因为会导致不易获取数据，然而若将其与自定义开发的应用程序结合，便有助于获得良好的分析体验。
这篇关于数据仓库——特殊类型的星型模式的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
