首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 数据库 > 数据库开发 >

数据仓库中的表(维度表或实事表)主键到底应该使用什么类型? 自增长int 还是直接用业务主键id

2013-01-02 
数据仓库中的表(维度表或事实表)主键到底应该使用什么类型? 自增长int 还是直接用业务主键id?在很多书籍中

数据仓库中的表(维度表或事实表)主键到底应该使用什么类型? 自增长int 还是直接用业务主键id?
在很多书籍中都讲到数据仓库的表的主键最好是自增长的int型,理由是当数据量很大的情况下,int比字符型的查询速度要快很多。

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

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


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

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




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

[解决办法]

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

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


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

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

[解决办法]
这个和规划方案有关,如果需求中明确要分析历史变化,那么代理键的时候就是必须的,那么自增长的int/number型就是必须的。如果没这明确需求,或者近期没必要,那么可暂时直接用业务主键。

楼主列举的案例,首先全部重新刷新维的情况,无论是否删除数据,对于整个数据质量体系都是有较大影响,一般不允许随便出现,除非主数据等外因的条件改变。如果一旦出现这样的需求,那么需要一次性对所有相关的事实表进行数据重新刷新,以保证数据质量,同时需要回归测试,代价较大。

热点排行