问题标签 [data-vault]

晚上所有，

我一直在努力解决这个问题，由于某种原因，我似乎无法让我的逻辑以我期望的方式返回。

我有 3 个数据表以及 3 个业务概念链接表。

• 表格1
• 表2
• 表3

规则：

• 表 1 可以链接到表 2
• 表1可以直接链接到表3
• 表1可以通过表2间接链接到表3

我已经尝试了一些变化，但是它似乎截断了记录。

解释起来有点尴尬，但总的来说，我需要表 1 中的所有数据，并且只有表 2 和表 3 中的数据与表 1 直接/间接相关。表 2 和表 3 不一定必须有相关经营理念。

预期回报是； 任何帮助将不胜感激

我想了解更多关于如何将 NoSQL 数据库集成到以关系模型为中心的架构（根据 Data Vault 2.0 标准构建）的信息。有没有人知道我可以在哪里对这个主题进行自我教育。这目前不在 Dan Lindstedt 的最新著作中！

我只是在阅读有关Data Vault 建模的内容，据我了解，集线器仅包含密钥（和记录源）。所以我想知道为什么我应该创建那些集线器表，只是为了存储记录源？只有卫星和链接还不够吗？

顺便说一句：我正在寻找数据保险库形式的简单 mysql 表以供下载和使用。

维基百科关于 Data Vault 的文章中提到了代理和业务密钥。在此处输入链接描述。此处提到了保留的密钥。

1. 根据 wikipedia article，为中心/卫星或链接指定代理键不是强制性的。但是，在链接中，必须为其连接的集线器指定代理键。如果在集线器中指定代理键不是强制性的，我将如何在链接表中输入它们？

2. 代理键与业务键。连接结构需要代理键。业务密钥用于唯一标识一个项目。但是我们也可以通过代理键来做到这一点，不是吗？业务键和代理键之间的主要区别是什么，为什么我不能只使用代理键作为业务键，反之亦然？

3. 在后来的文章中，他们写道：

Hub 表 - 包含业务密钥和保留密钥。保留密钥是一对一映射到业务密钥的密钥。相比之下，代理键包括时间，一个业务键可以有多个代理键。这解释了键的名称，在代理键增加时插入新版本的行会保留它。为什么我们需要保留密钥？可以有很多来源，因此我们不能使用业务密钥，因为它在不同的源系统中可能具有不同的类型或不同数量的属性。

由于资源众多，同一项目可能有不同的业务密钥。但是这个特定的项目将由一个保留的密钥唯一标识。我理解对了吗？因此，这意味着代理键映射到不同的业务键，而不是一对一的。

例子。 假设我们有一个中心“员工”，其中包含来自两个不同部门的两个不同的业务密钥。有一个员工 A。会计部门的员工 A 将拥有业务密钥 AT654，而项目部门的员工 A 将拥有业务密钥 PR454。该中心将为该雇主提供两个条目：

但是我怎样才能合并代理键呢？即，在哪种情况下会增加（如“这解释了键的名称，在代理键增加时插入新版本的行时保留”）？

有人可以给我一个使用保留密钥、业务密钥和代理密钥的示例（情况）吗？

我有一个带有 Gender 属性的 Person Satellite。在源系统中，此属性的值可以是：F、M、FEMALE 或 MALE。以下两种方法中哪一种是 Data Vault 建模的正确方法？

1. 将来自来源的数据存储在 Gender 中，并在 Business Vault 或 Data Marts 中将值标准化为 FEMALE 和 MALE

2. 创建一个交叉引用表以将 F 映射到 FEMALE 并将 M 映射到 MALE，同时加载 Person Satellite，使用交叉引用表将 F 转换为 FEMALE 并将 M 转换为 MALE。

我正在使用支持列压缩的 Amazon Redshift。

我正在设计一个使用 Data Vault 模型的数据仓库。我的数据仓库中有一个名为 Specialty 的实体。这些专业有一个基于其代码的查找表，该查找表具有从 Specialty_CD 到描述的一对一映射。此查找表（因为专业代码可以改变含义）和我保管库中的所有卫星表都有数据条目的历史记录。

我遇到了一个奇怪的案例，我想将 Data Vault 中名为“Professional”的另一个实体链接到 Specialty 实体，其中一个专业人员可以拥有多个专业。但是，专业实体没有中心。我当前的解决方案只有一个专业中心，其中包含每个专业人士的业务密钥和业务密钥哈希，一个将专业 BK 哈希映射到专业实践的专业的专业代码的链接表，以及从专业代码到描述的查找表。这里的问题是链接表将集线器连接到查找表，而不是另一个集线器。我不禁觉得这打破了 Data Vault 模型。这是否违反了 Data Vault 模型的规则？这会破坏我整个模型的正常化吗？

我觉得为专业创建一个中心会导致额外的数据检索连接。由于专业代码已经是专业描述的唯一标识符，我宁愿只为这个专业实体提供一个查找表，而不是为我不需要的专业实体提供一个集线器和额外的卫星。尤其是因为它只是在数据仓库中服务于一个特殊代码的定义和描述的目的。

欢迎对这种情况提出任何建议。在这种情况下，通过将集线器链接到查找表是否会破坏数据库？为这个专业实体创建一个中心和卫星是否值得在检索时进行开销和额外的连接？

谢谢！

我的数据保管库中有一个实体，该实体具有集线器、卫星表以及与其他具有集线器的实体的链接。我的数据保险库中有一个单独的实体，它仅用于作为查找表的单一目的。查找表是从唯一代码编号到描述的简单转换。

我很好奇将业务键从集线器关联到查找表的代码的“链接”表是否是一种糟糕的做法。我看到的唯一另一种选择是将这个查找表实体变成一个集线器，其中包含所有代码编号和一个包含所有描述的卫星表。这似乎效率低下，并且每次都会导致一个额外的查询，而不是拥有一个查找表。

任何建议表示赞赏。谢谢你。

伙计们，

快速版本：当我的 HUB_SAT 中有多个域查找引用时，我应该如何对 HUB、SAT 和 LINK 建模？如果您要从源模式中对这些进行通用建模，您将如何区分应该是 LINK 的 FK 和应该是 References 的 FK？

长版：

我正在构建一个通用解决方案，用于从现有的 3NF MSSQL 模式生成 DV 模型。在我的源数据库中，我有一个巨大的域引用表，其中包含大部分业务查找键

• 键 INT（唯一）
• 类型 ID INT
• 说明 VARCHAR
• 发布代码
• ...与讨论无关的其他一些领域

如我所见，链接到此表有四种基本选择

1. 将其创建为 HUB，然后为每个引用它的业务 HUB 生成 LINK 表
2. 将其创建为单个 ReferenceLookup 表并在 SAT 表中包含 R_ReferenceID
3. 使用 R_ReferenceID 为每个 TypeID 和来自 SAT 的链接创建一个单独的 ReferenceLookup 表
4. 为每个 TypeID 创建单独的 HUB 并生成 LINK 表
5. 使用 LINK_SAT 表创建单个 LINK 表，以保存 LINK 映射的参考值的详细信息

其中#3 感觉是最好的设计（但也是最难正确建模的——尤其是在我的情况下，查找表对类型表有一个 FK）

从 Wikipedia for DataVault中，参考表是从卫星中引用的，但从未与物理外键绑定。

我的通用代码基于BIML DataVault 演练中解释的设计模式

我正在查看源模式中的所有表，以确定它们是 HUB（有 PK 和多个 FK 以及不是 FK 的字段）、SAT（有 PK 并且只有一个 FK）还是 LINK（有 PK，多个 FK并且所有字段都在PK / FK中）

然后我建立：

• 具有 HUB_ID 和源 PK 的 HUB
• 具有 HUB 源表的非 FK 字段的 SAT
• 源 SAT 表的 SAT
• 来自源 LINK 表的 LINK
• 来自 HUB FK 关系的链接

这一切都达到了一定程度（即我有上面所有的表格）但是有一些非常宽的表格，其中大量的字段只是 R_RefID 字段，所有字段都在同一个 HUB 上查找，并且它们都与引用参考表的实体表上的 FK

EG 源资产表具有以下参考字段 - 资产类型 - 资产用途 - 资产经理 - 资产出资者 - ...

所以在初步模型中我有：

• ASSET_HUB (HubID, Asset_ID)
• ASSET_SAT (SAT_ID, BuildDate, DisposalDate, ....)
• Lookup_HUB (Hub_ID, LookupID)
• ASSET_Lookup_1_LINK) (Link_ID,ASSET_HUB_ID,Lookup_HUB_ID)
• ASSET_Lookup_2_LINK) (Link_ID,ASSET_HUB_ID,Lookup_HUB_ID)
• ASSET_Lookup_3_LINK) (Link_ID,ASSET_HUB_ID,Lookup_HUB_ID)
• ASSET_Lookup_4_LINK) (Link_ID,ASSET_HUB_ID,Lookup_HUB_ID)

但是无法确定每个 LINK 表在域模型中代表什么

您将如何询问模式以确定该表是否是真正的 HUB 候选表，或者它是否应该是 REF 表，以及您将如何确定 FK 应该被视为 LINK 还是 SAT.R_RefID。我追求的是策略而不是代码（但我不会拒绝提供的代码:)）我的源数据库是 SQL2008R2，我的开发环境是 SQL2016_Dev

回应 tobi6：

在源系统中，业务实体有许多属性字段，它们只是 XXX_ID 类型，它们从域引用表中查找它们的描述符。如果您将此域引用表建模为 HUB，那么您要么必须为每个查找有单独的链接表（LINK 表是自动生成的，因为业务实体上有一个 FK），或者具有 LINK_SAT 的多个活动 LINK 记录来识别哪个您正在跟踪的属性（实际上这会创建第 5 个设计模式选项）。如果我将域引用表标记为 REFerence，那么 XXX_ID 将保留在 HUB_SAT 中，这感觉像是一个更好的解决方案，但一般难以建模。即我如何确定业务实体 FK 是否应该创建 LINK、LINK 和 LINK_SAT 或 SAT.R_RefID

1. 在数据仓库项目中，为什么我们需要在从登陆/暂存区数据库传输数据集市（使用 Kimball 方法）中的数据之前使用 DataVault 建模？即为什么我们不能使用 Kimball 方法将数据直接从着陆/集结区数据库传输到最终数据集市？

2. 必须这样做吗？

我遇到了我觉得不对劲的数据库架构。它适用于一小群开发人员......我将不胜感激有关此设计的任何意见。

这是系统的简化描述。所有 3rd NF 数据库（客户、会计、费率、曝光）

我们有 4 个范式 DB：

• 客户数据库：维护客户和组织信息

• 汇率数据库：从第 3 方系统获取汇率

• Exposure DB：联系第三方系统获取我们的银行账户和交易信息

• 会计数据库：进一步计算财务风险和预测

我们有以下数据库用于数据仓库

• SQL Server 分析服务：星型模式

• 立方体

数据库拆分： 我们的 4 个数据库（Client、Rate、Exposure、Accounting）是拆分数量的 4 个 SQL Server，但它们都运行在同一个物理服务器上。这些数据库需要彼此的数据，例如我们有一个用于所有数据库的组织表……或者其他数据库中需要速率。

分析服务： 我们有星型模式和分析服务。我的理解是Data Vault可以用作生成 Start Schema 的来源……。但我们并没有为此目的使用我们的Data Vault 。我们使用 SSIS 直接从Client、Rate、Exposure 和 Accounting DB 读取数据，并直接填充启动模式。

问题：

1. 当我们需要使用这些拆分数据库中的数据时，拆分数据库是一个好主意吗？

2. 是否有一个好的来源/博客来解释什么时候拆分数据库是个好主意？

3. 将表从源数据库复制到目标数据库是一个好的解决方案吗？我觉得跨数据库查询比将这么多表复制到多个 DBa 中要简单和高效得多。