Database 核心/自定义事实表

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

以下是我计划如何组织这一点，但如果这看起来是一个好的设计，我想输入，如果这是坏的，请推荐另一种方法

事实表将包含VerticalKey FK。以下是我计划制作的DIM：

DIM垂直（超类型/核心）

• 垂直键（自动递增）
• 医嘱ID（备用密钥）

DIM垂直车辆（子类型/自定义）

• VerticalKey（DimVertical.VerticalKey中的键Id）
• 自定义属性
• 自定义属性定义
• 海关总署署长

DIM垂直摩托车（子类型/自定义）

• VerticalKey（DimVertical.VerticalKey中的关键点）
• 客户属性123
• 自定义属性456

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

这似乎是一个好方法吗？其次，如果这是一种很好的方法，比如说“OrderType”是一个超级类型属性，因此它可以进入DimVertical维度，这是不是很糟糕？我质疑这一点，因为我知道你不应该有一个标题维度，这是什么样的，但我不知道如何支持“自定义”订单标题搜索能力

提前谢谢

在中，有三种可能的类层次结构到关系模式的映射：

• 每个类层次结构的表

• 每个子类的表

• 每种混凝土等级的表

如果我没弄错的话，您可以按照表中的每个子类策略进行操作。这可能很好，但在不知道您的数据的情况下，无法对其进行评论

最好的方法是简单地建立一个包含非平凡数据的样本模式；您将很快看到access查询是否执行并且是否易于创建

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

• 访问有效（无连接）并且
• 可能不一致的缺点（即，您可以将汽车属性存储在摩托车记录中）在数据仓库中不重要，因为一致性通常是通过clening ETL作业而不是通过数据库来完成的