微科社区,轻松开发从此开始! 请登陆 免费注册

微科社区

当前位置:首页 > 数据库 > 数据仓库 >

数据仓库中的表(维度表或事实表)主键到底应

时间:2017-01-11 04:01  浏览:努力统计中...
在很多书籍中都讲到数据仓库的表的主键最好是自增长的int型,理由是当数据量很大的情况下,int比字符型的查询速度要快很多。 但是在实际项目中,真的是使用自增长的int型吗? 在我
在很多书籍中都讲到数据仓库的表的主键最好是自增长的int型,理由是当数据量很大的情况下,int比字符型的查询速度要快很多。

但是在实际项目中,真的是使用自增长的int型吗? 在我理解中,如果使用自增长的int型的话,存在以下问题:

1、当某个维度表需要重新抽取的时候(即删除该维度表所有数据),如果源数据库中少了一条维度记录的话,则在事实表中引用原先该维度记录的key会找不到。


使用自增长的int型作为维度表和事实表的主键的话,还会存在哪些弊端??

在数据仓库表的主键类型上,你们有什么看法??





用代理键还是用用业务上的键这个也不是一定的,也要是考虑多方面因素的
如业务系统比较规范,变动也极小的情况下,而且etl过程中也不会涉及到多系统之间的标准化过程,则直接使用业务键较好
另外,使用代理键也并不是简单的用序列,代理键的规则选不好的话,ETL的转换量都可能会增多不少


upup

请各位TX积极讨论自己的观点,谢谢

我一定会给分的

没人顶啊,只好自己顶

SOS

我的想法是,
如果考虑到方便简单的话,那我会选择直接用业务键作主键,但是如果需要用到渐变维度,或保留历史更新事实表数据的话,用业务主键就做不到了,只能自建主键。

但是如果建自增长主键的话,又会有问题,比如说我要重新抽取最近两天的数据,我就先把事实表中的两天内的数据删除,维度表中两天内的新增数据给删除,但是这样也会有问题,当你无法确定这些维度表中新增的数据被哪几个事实表所引用的话,那么删除维度表后,这些事实表中所引用那些已删除的维度外键的记录就会无法匹配。

如何来解决这个问题呢??? 有没有比较好的项目实施经验???

int比varchar2又能快多少?差别很小吧




大数据量的数据仓库是可以看出效果来的



同意搂主对渐变维度时,建立无实际业务意义列的作为主键的解决方法,但是还是建议在数据仓库中,即使现在没有渐变情况发生也尽量使用无意义键做为主键,一是查询性能可以得到保证,二是给将来可能会出现的渐变留下更好的扩展性。无意义键列可以是自增,也可以是按某种规则生成。

在SQL2005里你可以在表属性中查看它被哪几个表引用(其他数据库也应该都有这个功能),而事实表(或者雪花型结构中的维度表)记录的外键列值和维度表记录的主键列值,对应是相同的。如果知道了要删除维度表记录的主键了,那么到事实表中(雪花型结构的维度表中)找相对应的记录是很方便的。不知道这是否能解决楼主所说的“无法确定维度表中新增数据被哪几个表引用的的“的问题。


我觉得重新抽取比较麻烦,需要判断数据仓库中所有表,如果该数据仓库很大,就相当麻烦。不知道有什么好的建议?

还有如果这样一条记录,该记录在前天被修改过一次,昨天又被修改过一次,现如果需要重新抽取这两天的历史数据,则会把抽取开始时间定为前天的0点,那么在前天修改过的那条修改记录的动作将不会被保存进数据库,这样就会造成漏掉数据, 这一点又该如何避免??


如果数据仓库系统数据不很大,全部抽取是可以的,但如果数据量非常大,那全量抽取就不可取了。
重新抽取一般很少用,一般是系统在抽取时出现宕机等灾难性问题时可能会对以前的抽取工作再重新处理一次。尽量减少不必要的删除重新抽取操作。

数据仓库数据是用来分析的状态一般是稳定的,尽量不对数据仓库做删除操作。即使要做删除操作也有两种方式可以选择:一种是物理删除,就是楼主说的那种直接从表中删掉。另一种是逻辑删除,即数据还在数据库表中,但该表有一列用作标记该纪录是否处于“已删除”状态。这样用户有了新的需求变更也能挽回原来的数据记录。

数据仓库毕竟是做分析用的,对数据的删除偶尔一次是可以的,数据仓库管理员应该有这个权力。但应尽量杜绝决频繁删除操作。尤其是用户的删除操作更应避免。不然你改一次我改一次分析就乱套了。具体情况和用户协调清楚,充分分析他们的需求。制定合适的数据加载机制!

这个和规划方案有关,如果需求中明确要分析历史变化,那么代理键的时候就是必须的,那么自增长的int/number型就是必须的。如果没这明确需求,或者近期没必要,那么可暂时直接用业务主键。
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线------