【问题标题】:Merging identical tables but maintaining separate referential integrity合并相同的表但保持独立的参照完整性
【发布时间】:2009-09-09 17:13:58
【问题描述】:

考虑一个带有事实表的维度模型,例如(fk_dim1value, fk_dim2value, ..., value),其中fk_X 列是对应平凡维度表dim1value (id, value), dim2value (id, value), 等的外键。

这些事实和维度表是从不同来源自动收集的,所以它们有很多......而且它们是多余的:所有维度值表在结构上都是相同的,(id, value),表示文本值的简单集合没有进一步的语义(唯一的区别是在各种事实表中引用它们的不同外键)。稍后可能会出现不那么琐碎的维度类型,但不同类型维度的集合仍然很小。

所以我想将维度表合并到一个表dimvalue (fk_dim, dimvalue_id, value) 中,其中fk_dim 引用一个表dimension (dim_id, name),而dimvalue_id 仅在每个维度中是唯一的。然后合成自然主键:(fk_dim, dimvalue_id)

事实表外键列现在都引用同一个表,dimvalue (fk_dim, dimvalue_id, value) ...但当然每一列都与特定维度相关联,因此仍应仅限于具体引用该维度的值(a统一表的水平分区dimvalue)。

有没有(明智的)方法可以做到这一点?

我的意思是“半复合”外键,即对复合 PK 的“切片”的单列引用,其他列具有固定值。 “完全复合”的 FK 是 FOREIGN KEY (col1, col2) REFERENCES dimvalue (fk_dim, dimvalue_id),但这里的 fk_dim 是固定的,因此键的“home”侧只是一列,引用 dimvalue 主键的第二列;类似FOREIGN KEY (fk_dim7value) REFERENCES dimvalue (fk_dim=7, dimvalue_id)

这样的事情可能吗?还是我在最后一段中迷失了方向?我应该放弃整个dimvalue 表的外键,然后添加检查约束以按维度限制吗?还是引用完整性要求我放弃更多,只接受所有单独的相同表?

(约束对写入性能的影响并不重要;读取性能是设计目标。)

【问题讨论】:

    标签: sql database postgresql foreign-keys referential-integrity


    【解决方案1】:

    您已经陈述了这些关键考虑因素

    • 数据是从不同的系统收集的,因此我认为这是一个“报告”表,而不是“操作”或“事务”类型系统
    • 每个事实表每行包含1条业务数据,即“价值”列
    • 您的事实表似乎只包含一个“度量”或“事实”
    • 写入性能无关紧要,只有读取性能才是目标。这证实了我的结论,即这是一个“报告”表

    考虑到您追求快速读取性能,我会选择“大桌子”设计。诚然,大表设计对于事务系统来说是可怕的,但这不是一个。我的意思是大桌子 表(DIM1VALUE,DIM2VALUE,DIM3VALUE,DIM4VALUE....DIMNVALUE,FACTVALUE)

    无论如何,您的维度表只有 1 列业务数据,因此请跳过查找。索引每一列(事实值除外),然后测试您的查询的性能。

    在加载大表时,您可以检查数据质量的值并标记/解决超出预期范围的值。

    现在,如果您的维度表数量过多,您可以将大表拆分为基于逻辑用法进行分组的组,例如,如果维度中的 10 个属性始终一起使用,则将它们放在 BIGTABLE1 中,等等。

    【讨论】:

    • 谢谢;你是对的,它是一个“报告”模式,但我不喜欢“大表”方法。它会扩大事实表的宽度(维度值可能很宽),使查询 I/O 变得繁重。它不会为我节省太多,因为无论如何我经常可以避免加入维度表。它会将我与这个唯一的微不足道的维度值模型联系起来,这不是永久性的(我不清楚,抱歉;我已经修改了这个问题。)
    猜你喜欢
    • 2010-09-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-12-30
    • 1970-01-01
    • 2013-06-17
    • 2010-12-29
    • 2011-09-17
    相关资源
    最近更新 更多