Data Vault

[小水牛]

不知道大家对Data Vault了解吗？看了简单的介绍，说是一种混合的数据仓库建模方法，解决了3NF和星型模型的缺陷。有谁对此有深入的了解吗，
可以介绍下。

[Qing]

我也很想知道。

这个概念也应该出来很久了吧，不过看来一直没有流行起来。我在ttnn里面搜了一下，在06年的时候，在谈论hub-spoke的时候谈到过，不过也没有展开。

请dw建模大虾们来普及一下...

2008/12/19 小水牛 <Lucia...@gmail.com>

不知道大家对Data Vault了解吗？看了简单的介绍，说是一种混合的数据仓库建模方法，解决了3NF和星型模型的缺陷。有谁对此有深入的了解吗，

可以介绍下。。。

[小水牛]

据称是2000年左右就出来了，提出这个data vault的人想申请专利来着，在2005年的时候被驳回了。
据说Inmon很赞赏他的做法。

On Dec 19, 10:55 am, Qing <happys...@gmail.com> wrote:
> 我也很想知道。
> 这个概念也应该出来很久了吧，不过看来一直没有流行起来。我在ttnn里面搜了一下，在06年的时候，在谈论hub-spoke的时候谈到过，不过也没有展开。
>
> 请dw建模大虾们来普及一下...
>

> 2008/12/19 小水牛 <Lucian.n...@gmail.com>

>
>
>
> > 不知道大家对Data Vault了解吗？看了简单的介绍，说是一种混合的数据仓库建模方法，解决了3NF和星型模型的缺陷。有谁对此有深入的了解吗，

> > 可以介绍下。。。- Hide quoted text -
>
> - Show quoted text -

[小水牛]

不是之前有建模高手的吗，怎么不冒泡了？

> > - Show quoted text -- Hide quoted text -

[Solo Zhu]

其实data vault的中文意思应该叫做数据保险箱（不知道有没有别的中文称呼）
其实我们现在常说的3NF和星型模型都是有一些弊端的，特别是对于一些常用的维度的变化，即便我们现在有SCD的，但是总体来说，企业的数据大了，变化
多了，SCD的存储和效率都存在问题，特别是维度的结构变化了，比如说长度等。
所以就提出了data vault的概念
它应该说是3NF和星型模型的一种混合，兼容了两种模型的优势，
Data Vault通常可以分为三种类型，中心体，链接体和附属体
中心体：
中心体主要是存储一些日常用的一些业务关键码，比如客户号，发票号，流水号等等。它包括三个要素
代理键：这就是一些操作性的组件，包括客户号，发票号等等
装载时间戳：这里可以理解为ETL进行日加载的时间。
数据源：就是可以追索到的原系统，比如，CRM，ERP等
比如我们的客户号在不同的系统分别为CDS001和001，那么在中心体的表中就有两条记录

链接体：是3NF的多对多关系的物理表现形式，它表现的是多个业务键之间的关系。包含以下特征:
　　代理键
　　代理键间的映射关系
　　装载时间戳：这里可以理解为ETL进行日加载的时间。
数据源：就是可以追索到的原系统，比如，CRM，ERP等

附属体：业务领域中的其余信息可能随着时间而变化，所以附属体必须有能力存储新的或者变化的各种粒度的数据，他们将被存储在附属体内。如类别、产品、供
应商、命令细节、命令、顾客、托运人和雇员，他只是包含仅非外键属性，具有一下特征
主键1-》映射中心体的主键或者链接体的主键
主键2-》装载时间戳
选择型主键：顺寻代理键，他可能有多个值，比如账单或者地址信息
数据源：记录数据的来源系统

> > - Show quoted text -- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[Solo Zhu]

这种模式对于复杂的，可变的业务系统而做的数据仓库比较适用
中心体可以记录每一次的变化的信息内容，
举一个比较简单的例子，我们现在有类别信息和产品信息
类别名称是业务键，类别的ID号是代理键，我们可以建立表：HUB_Category
产品名称是业务键，产品的ID号是代理键，我们可以建立表：HUB_Product
供应商名称是业务键， ID号是代理键，我们可以建立表：HUB_Supplier

如：
Create Table Hub_Category (
CategoryID int NOT NULL,
CategoryName nvarchar(15) NOT NULL,
LOAD_DATE DateTime Not Null,
RECORD_SOURCE nvarchar(12) not null,
Primary Key (CategoryID)
)
现在供应商想买一个某类中的某个产品，这就是一种关系，可以建立链接体的表： LNK_PRODUCTS

Create Table LNK_PRODUCTS (
ProductID int NOT NULL,
CategoryID int NOT NULL,
SupplierID int NOT NULL,
LOAD_DATE DateTime Not Null,
RECORD_SOURCE nvarchar(12) not null,
Primary Key (ProductID),
Foreign Key (SupplierID) references HUB_Supplier,
Foreign Key (CategeoryID) references HUB_Category
)

至于供应商交易的具体信息就是属于附属信息了，但是需要分开理解，供应商交易的信息和产品交易的信息，这是这对不同的业务实体的，所以有产品的附属信息
表和供应商的附属信息表了，如一下是产品交易的附属信息表：
Create Table SAT_Products (
ProductID int NOT NULL,
LOAD_DATE DateTime Not Null,
QuantityPerUnit nvarchar(20),
UnitPrice money,
UnitsInStock smallint,
UnitsOnOrder smallint,
ReOrderLevel smallint,
Discontinued bit,
RECORD_SOURCE nvarchar(12) not null,
Primary Key (ProductID,LOAD_DATE)
Foreign Key (ProductID) references HUB_Products
)
通过主键和 HUB_Products ，以及LNK_PRODUCTS关联，然后通过LNK_PRODUCTS中的（SupplierID ，
LOAD_DATE DateTime）找到具体的供应商交易信息。

> > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[Solo Zhu]

这里仅提供一些简单的资料，希望高手们能给予更多的支持

[yy_lv]

曾经看过下关于Data Vault的文档，从中文翻译过来有叫“数据拱顶模型”的。
相对于3NF和星型模型，Data Vault用接近现实的描述方式来表示数据。Hub(实体)，标识的是一个不变的实体，即每人的身份
证号只有一个，而且唯一标识一个人；Link(链接)，表示实体间的业务联系，如供应商与产品间的关系（两个实体），可以用Link来标识这两个实体间
的关系；Satellite，表示实体及链接的属性描述，这里考虑到了实体及链接属性的渐变特点，如某人的住址发生了变化，在Satellite里通过
时间戳记录了信息的变化。从总体来说，DataVault就是利用这三类“组件”来构建了对现实世界的描述（是否有点像逻辑模型中的ER图？）。
曾经做了一下3NF向Data Vault的转变，由于Data Vault强调实体的相对独立性，对业务的灵活描述，使得数据表及表间
的关联增多。

这是我的一点想法，欢迎大家拍砖.....

[Solo Zhu]

呵呵 数据拱顶模型的称呼似乎比较正确，实体就是这个模型的两端和顶部，链接就是桥梁，至于附件描述应该都是通路了。

> > 可以介绍下。- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[小水牛]

有了解IBM IIW的吗？Data Vault中的Hub和IIW的anchor有什么区别？
感觉Data Vault在EDW使用比较适合一些，也难怪Inmon会推荐使用，在Data Marts中使用，应该不合适。维度建模的两个优点：一
个是直观，二是高性能都不能体现出来。说实话没看出来它怎么解决了维度建模和3NF的缺点。

> > - 显示引用的文字 -- Hide quoted text -