父子维度通俗的话来讲，这个表是自反的，即外键本身就是引用的主键；类似这样的关系，如公司组织结构，分公司是总公司的一部分，部门是分公司的一部分，当然如果定义得好的话员工是部门的一部分；通常公司的组织架构并非处在等层次上的，例如总公司下面的部门看起来就和分公司是一样的层次。因此父子维的层次通常不固定的。
5、 父子维概述
5.1概述
父子维度基于两个维度表列，这两列一起定义了维度成员中的沿袭关系。一列称为成员键列，标识每个成员；另一列称为父键列，标识每个成员的父代。该信息用于创建父子链接，该链接将在创建后组合到代表单个元数据级别的单个成员层次结构中。 (微软 SQLServer2000联机帮助概念 )
5.1概述
父子维度基于两个维度表列，这两列一起定义了维度成员中的沿袭关系。一列称为成员键列，标识每个成员；另一列称为父键列，标识每个成员的父代。该信息用于创建父子链接，该链接将在创建后组合到代表单个元数据级别的单个成员层次结构中。 (微软 SQLServer2000联机帮助概念 )
通俗的话来讲，这个表是自反的，即外键本身就是引用的主键；类似这样的关系，如公司组织结构，分公司是总公司的一部分，部门是分公司的一部分，当然如果定义得好的话员工是部门的一部分；通常公司的组织架构并非处在等层次上的，例如总公司下面的部门看起来就和分公司是一样的层次。因此父子维的层次通常不固定的。
5.2实现
因为父子维的复杂的自引用关系，如果按照缓慢维度的全历史记录方式来处理，必然导致逻辑关系混乱，处理起来比较棘手；任何一个组织的变动 (修改名称，更改引用，新增等等操作 )将会引起其下属节点相应的变动；任何一个意外都会导致整个结构的变化，同时发生意外后所带来的逻辑关系很难理顺。而 SQLServer2000中 Analysis Service对于这种急剧的变化处理并不稳定。
因为父子维的复杂的自引用关系，如果按照缓慢维度的全历史记录方式来处理，必然导致逻辑关系混乱，处理起来比较棘手；任何一个组织的变动 (修改名称，更改引用，新增等等操作 )将会引起其下属节点相应的变动；任何一个意外都会导致整个结构的变化，同时发生意外后所带来的逻辑关系很难理顺。而 SQLServer2000中 Analysis Service对于这种急剧的变化处理并不稳定。
因此建议按照缓慢变化维的覆盖方式解决，即只根据主键这个唯一标志进行判断是否是新增还是修改。
代码
-- 父子维度表
CREATE TABLE t_dem_xxx
(
ID VARCHAR(20) NOT NULL,
SuperID VARCHAR(20) NOT NULL,
Name VARCHAR(50)
CONSTRAINT PK_t_dem_xxx PRIMARY KEY (SurID)
)
go
CREATE TABLE t_tmp_xxx
(
ID VARCHAR(20) NOT NULL,
SuperID VARCHAR(20) NOT NULL,
Name VARCHAR(50)
CONSTRAINT PK_t_tmp_xxx PRIMARY KEY (ID)
)
Go
CREATE PROCEDURE p_dem_xxx
AS
-- 维度抽取存储过程
BEGIN
DECLARE
@num NUMERIC(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
本文转自baoqiangwang51CTO博客，原文链接：http://blog.51cto.com/baoqiangwang/310320
，如需转载请自行联系原作者
