Lie*_*oen 12 database data-warehouse
我认为问题很清楚.我的datawarehouse表中的某些列可能与主键有关系.但这是好的做法吗？它是非规范化的,所以永远不要再删除它(datawarehouse中的数据).希望问题有点清楚.
Dam*_*vic 10
我假设您在事实表中引用FK.在DW加载期间,将删除索引和任何外键以加速加载 - ETL过程负责处理密钥.
外键约束在插入和更新期间"激活"(这是在需要检查父表中是否存在键值时)以及在删除父表中的主键期间.它在读取过程中不起作用.删除DW中的记录(应该)是一个受控进程,它在从维度表中删除之前扫描任何现有关系.
因此,大多数DW没有将外键实现为约束.
FK约束在SQL Server上的Kimball维模型中运行良好.
通常,您的ETL需要查找维度表(通常在业务键上以处理缓慢变化的维度)以确定维度代理ID,而维度代理ID通常是标识,维度上的PK通常是维度代理id,已经是一个索引(可能是聚集的).
此时使用RI并不是写入的大量开销,因为它还可以帮助在开发期间捕获ETL缺陷.此外,将事实表的PK作为所有FK的组合也可以帮助捕获潜在的数据建模问题和双重加载.
如果您想制作星型模型的通用平面视图或表值函数,它实际上可以减少选择的开销.因为维度的额外内部连接保证只生成一行,所以优化器可以非常有效地使用这些约束来消除查找表的需要.如果没有FK约束,可能必须执行这些查找以消除维度不存在的事实.
问题很清楚,但"良好做法"似乎是错误的问题.
" 可以有FK"吗？
外键是在数据库修改期间保留完整性约束的机制.
如果您的DW是只读的(累积数据源而不回写),则不需要FK.
如果您的DW支持写入,则ETL通常需要在参与的数据源之间协调完整性保护(而不是它的Store等效项).此过程可能依赖于也可能不依赖于数据库中的FK.
所以正确的问题是:你需要它们吗？
(我能想到的另一个原因是关系文档 - 但是,这也可以在纸上/单独的文档中完成.)
在DW中使用FK约束就像戴着自行车头盔。如果ETL设计正确，从技术上讲您就不需要它们。就是说，如果我每次看到无错误的ETL时都拥有一百万美元，那么我将获得零美元。
直到您遇到FK约束导致性能问题的时候，我才说“离开”。清理引用完整性问题可能比从一开始就添加它们困难得多；-)