核心/自定义事实表

Question

我在订单/行粒度上定义了一个事实表。每个订单都属于某个垂直方向，每个垂直方向都有用于描述其数据的自定义属性。我希望能够允许用户跨所有订单进行查询，而不考虑垂直方向，但在查询垂直方向特定的数据时，能够按垂直方向特定属性进行筛选。

以下是我计划如何构建它，但如果这看起来是一个好的设计，我希望能提供意见，如果不好，请推荐另一种方法。

事实表将包含VerticalKey FK。这些是我计划制作的Dims：

1. DimVertical(超类型/核心)

   • 垂直关键点(自动增量)
   • OrderId(备用密钥)

2. DimVertical Car(子类型/自定义)

   • VerticalKey(DimVertical.VolticalKey中的键Id)
   • 自定义属性ABC
   • 自定义属性DEF
   • 自定义属性GHI

3. DimVertical Motorcyle(子类型/自定义)

   • VerticalKey(DimVertical中的关键点。VerticalKey)
   • 自定义属性123
   • 自定义属性456

为了查询所有订单，只需对超类型DimVertical进行联接。但是，当我想通过特定于垂直方向的属性在特定垂直方向上进行查询时，我只会包括可选的子类型Dimension。

这看起来是个好方法吗？其次，如果这是一个很好的方法，假设"OrderType"是一个超类型属性，所以它可以进入DimVertical维度，这很糟糕吗？我质疑这一点，因为我知道你不应该有这样的表头维度，但我不知道如何支持"自定义"订单表头搜索功能。

提前感谢！

Answer 1

理论上有三种可能的类层次结构到关系模式的映射：

• 每个类层次结构的表

• 每个子类的表格

• 混凝土等级表

如果我说得对，你可以按照表的每个子类策略。这可能很好，但在不知道你的数据的情况下不能发表评论。

最好的方法是简单地用非平凡的数据设置一个示例模式；您将很快看到访问查询是否执行并且创建起来是否简单。

根据我的经验，数据仓库设计中常用的方法是每个类层次结构的表(即所有子类都在一个表中实现)，因为

• 访问有效(无联接)并且
• 可能的不一致性(即，您可以将汽车属性存储在摩托车记录中)的缺点是在数据仓库中不重要，因为一致性通常是通过执行ETL作业而不是通过数据库来实现的