核心/自定义事实表
核心/自定义事实表
提问于 2017-01-10 22:00:38
我有一个按顺序/行粒度定义的事实表。每个订单都属于某个垂直的，并且每个垂直都有自定义属性来描述它的数据。我希望能够允许用户在所有订单之间进行查询，而不管是垂直的，但是当查询垂直特定的数据时，可以通过垂直特定的属性进行筛选。
这是我计划如何构造这个，但如果这看起来是一个好的设计，或者如果这是坏的，请推荐另一个方法。
事实表将包含VerticalKey FK。这些是我计划要做的总经理：
- DimVertical (超级型/核心)
- VerticalKey (Auto Increment)
- OrderId (Alternate key)
- 直通车(亚型/自定义)
- VerticalKey (Key Id from DimVertical.VerticalKey)
- CustomAttributeABC
- CustomAttributeDEF
- CustomAttributeGHI
- 双体垂直-摩托车(亚型/定制)
- VerticalKey (Key from DimVertical.VerticalKey)
- CustomAttribute123
- CustomAttribute456
为了跨所有订单进行查询，只需对超级类型DimVertical进行连接。但是，当我想要通过垂直的特定属性进行查询时，我只需要包含可选的子类型维度。
这看起来是个好办法吗？其次，如果这是一种很好的方法，那么让我们假设"OrderType“是一个超级类型属性，这样它就可以进入DimVertical维度了，这不好吗？我对此表示怀疑，因为我知道您不应该有一个标头维度，这是某种程度上是这样的，但我不知道如何支持“自定义”订单头搜索功能。
提前感谢！
回答 1
Stack Overflow用户
发布于 2017-01-14 18:58:06
在理论中，有三种可能的类层次结构映射到关系模式：
- 每类层次结构表
- 每个子类表
- 每个混凝土级表
如果我对你说得对，你会按照每个子类策略遵循表。这可能很好，但在不知道数据的情况下是不能评论的。
最好的方法是简单地设置一个具有重要数据的样例模式；您将很快看到访问查询是否执行并且创建起来很简单。
根据我的经验，数据仓库设计中使用的一种方法是按类层次结构表(即所有子类都在一个表中实现)，因为
- 访问是有效的(没有联接)和
- 可能的不一致性(即您可以在摩托车记录中存储汽车属性)的缺点是数据仓库中的，而不是关键的，因为一致性通常是通过紧密的ETL作业而不是由数据库完成的。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/41579207
复制相关文章
相似问题
腾讯云开发者
