这是最好的时代,这是最坏的时代,这是智慧的时代,这是愚蠢的时代;这是信仰的时期,这是怀疑的时期;这是光明的季节,这是黑暗的季节;这是希望之春,这是失望之冬;人们面前有着各样事物,人们面前一无所有;人们正在直登天堂;人们正在直下地狱。
我也要与时俱进了,被itpub2.0牵着尾巴,拼命的奔跑,不停的灌水...
8 关于数据仓库维度数据处理的方法探究系列——父子维
上一篇 /
下一篇 2008-02-13 17:20:06
/ 个人分类:数据仓库专区
父子维度通俗的话来讲,这个表是自反的,即外键本身就是引用的主键;类似这样的关系,如公司组织结构,分公司是总公司的一部分,部门是分公司的一部分,当然如果定义得好的话员工是部门的一部分;通常公司的组织架构并非处在等层次上的,例如总公司下面的部门看起来就和分公司是一样的层次。因此父子维的层次通常不固定的。8I4i,Pkv`05、父子维概述
5.1概述
父子维度基于两个维度表列,这两列一起定义了维度成员中的沿袭关系。一列称为成员键列,标识每个成员;另一列称为父键列,标识每个成员的父代。该信息用于创建父子链接,该链接将在创建后组合到代表单个元数据级别的单个成员层次结构中。(微软SQLServer2000联机帮助概念)
通俗的话来讲,这个表是自反的,即外键本身就是引用的主键;类似这样的关系,如公司组织结构,分公司是总公司的一部分,部门是分公司的一部分,当然如果定义得好的话员工是部门的一部分;通常公司的组织架构并非处在等层次上的,例如总公司下面的部门看起来就和分公司是一样的层次。因此父子维的层次通常不固定的。

5.2实现
因为父子维的复杂的自引用关系,如果按照缓慢维度的全历史记录方式来处理,必然导致逻辑关系混乱,处理起来比较棘手;任何一个组织的变动(修改名称,更改引用,新增等等操作)将会引起其下属节点相应的变动;任何一个意外都会导致整个结构的变化,同时发生意外后所带来的逻辑关系很难理顺。而SQLServer2000中Analysis Service对于这种急剧的变化处理并不稳定。
因此建议按照缓慢变化维的覆盖方式解决,即只根据主键这个唯一标志进行判断是否是新增还是修改。
代码
--父子维度表 CREATE TABLE t_dem_xxx ( IDVARCHAR(20) NOT NULL, SuperIDVARCHAR(20) NOT NULL, NameVARCHAR(50) CONSTRAINT PK_t_dem_xxx PRIMARY KEY (SurID) ) go CREATE TABLE t_tmp_xxx ( IDVARCHAR(20) NOT NULL, SuperIDVARCHAR(20) NOT NULL, NameVARCHAR(50) CONSTRAINT PK_t_tmp_xxx PRIMARY KEY (ID) ) Go CREATE PROCEDURE p_dem_xxx AS --维度抽取存储过程 BEGIN DECLARE @numNUMERIC(10,0) SELECT @num = COUNT(*) FROM t_dem_xxx --如果原表为空,构造缺省值 IF @num = 0 BEGIN INSERT INTO t_dem_xxx (ID,SuperID,Name) SELECT '-2','0','NULL值' INSERT INTO t_dem_xxx (ID,SuperID,Name) SELECT '-1','0','缺失外键' END --根据主键插入在维度表中找不到的基础数据 INSERT INTO t_dem_xxx ( ID, SuperID, Name ) SELECT a.ID,a.SuperID,a.Name FROM t_tmp_xxx a LEFT OUTER JOIN t_dem_xxx b ON a.ID = b.ID WHERE b.ID IS NULL --根据主键更新原基础表中变化的各属性字段 UPDATE t_dem_xxx SET SuperID = a.SuperID, Name = a.Name FROM t_tmp_xxx A,t_dem_xxx B WHERE a.ID = b.ID AND b.ID NOT IN ('-1','-2') END 1s{0M&R
]0 |
导入论坛
引用链接
收藏
分享给好友
推荐到圈子
管理
举报
TAG: