I'm coding a data warehouse in data vault model. But actually I'm not sure how to work with transaction data. I have the following attributes

I have a hub table for Service, a hub table for Status and a hub table for Time, but it's not based on minutes.

The question is? Are the transaction data link tables? How would/do you design this? thanks for your comments

我正在研究使用 datavault 2.0 方法。我了解散列并尝试应用它的原因。我想在数据库的“暂存”阶段应用它，而不是将其加载到 DV 中。

如果表中有业务键，那么很容易将其应用到该表（可能成为集线器）。但是有像“orderdetail”这样的表（可能成为链接），它们通过代理键多次引用其他元素。

临时表是否应该同时包含每个外键的代理序列以及引用实体 BK 的散列？

示例：如果我有一个带有 customerId 代理序列的订单表，但客户表有一个用作 BK 的 CUST-000xxx 引用，我是否应该在订单和客户之间执行“连接”以解析“CUST-000xxx”所以我可以散列它并将其包含在订单临时表中？

我在想，当从暂存区加载 DV 中的数据时，这可能会解决，但是在那个特定时刻，暂存区中可能不存在客户参考，因为订单可能只是一个新订单没有改变的现有客户。

DV 2.0 规定，所有使用哈希的业务都是为了提高性能并简单地并行加载数据，而无需在 DV 本身中进行昂贵的查找。因此，这个问题通常是如何解决的。

在此处添加示例：

订单 - orderid - customerid - order_ref - salespersonid

客户 - customerid - customer_ref

人 - 人名 - 全名 - 登录

为了填充订单，我应该像这样在源数据库中加入：

或者是在 datavault 中解析的外键解析，因此查询更简单，例如：

这对我来说不是很清楚。我的理解是，通过散列避免了昂贵的查找，因此不为外键在暂存时生成散列对性能没有贡献？

我有一个基于星型模式的数据模型。它存储三个日期元素。我将它们整合到一个角色扮演维度中，以避免重复的日期。我想将我的数据存储到核心 DWH 中的数据保险库模型中，并将星型模式显示为视图。但是现在，我不确定如何处理角色扮演模型的问题。我应该在日期实施三个单独的 Hubs 和 Sats 吗？并将它们放在视图层中？或者我可以实现一个日期中心 + sat 并将它们引用到链接表三次（到三个不同的日期）？

此致

我已经端到端地阅读了数据保险库书籍，但我仍在尝试解决与您如何填充链接表（如何为此获取所有哈希）相关的一个特定问题。来自 scalefree:massally parallel processing的博客，它演示了可以以完全并行的方式加载卫星和集线器，但它没有涉及与链接表相关的很多细节。

链接需要哈希键，因此以某种方式来自多个表的“业务键”来建立关系，这就是它们所做的，它们记录集线器之间的关系。在填充这些链接表时，没有很好的解释或深入的解释如何检索相关实体的业务键。

对于像“客户”这样的特定表，集线器和卫星很容易：只需将业务密钥转换为哈希并并行加载它们。

但是来自 OLTP 的客户详细信息表或事务表需要某种形式的连接来查找客户的业务密钥或查找事务中的所有相关实体（产品、客户、商店等），因为这些表通常不会将（所有）业务​​密钥作为属性存储在表中。

如果我假设 staging 是增量加载并被截断的，那么 staging 并不一定要加载所有实体才能在那里执行连接。如何解决这一困境并创造出有效的设计？

1. 加入源 OLTP 系统中的表以从那里生成业务密钥并将它们作为散列从那里传播？（如果业务密钥选择不正确，这最终会出错）
2. 使用持久暂存区，所以永远不要截断？（然后总是可以加入那里的任何表来解决）
3. 对代理键使用某种索引-> 业务键并从那里执行查找？（进一步最小化 I/O，是增量分段和持久分段之间的混合）。
4. 其他方法...？

本质上，为 OLTP 系统的所有外键关系生成哈希的最佳实践是什么？

我对硬规则 (rawvault) 和软规则 (businessrules) 有疑问。

我的示例是一个源系统有一个名为 Pets 的非规范化表，其中 Pets 包含 Cats、Dogs 和 Birds，它们通过类型代码（1 - 猫、2 - 狗、3 - 鸟）进行区分。

我的问题是关于将数据加载到 Rawvault 与业务保险库时的硬规则与软规则。加载 Pets 表时，是否可以在 rawvault 中创建 h_cat、h_dog 和 h_bird 集线器，并根据类型代码 1 过滤源表 pets 到 h_cat，类型代码 2 到 h_dog，类型代码 3 到 h_bird？这是硬规则还是软规则？

或者

当基于类型代码过滤数据时，我们是否应该在 rawvault 中创建 h_pet 集线器，使数据尽可能靠近源，在 businessvault 中创建 h_cat、h_dog 和 h_bird，因为这将被归类为软规则？

我们有一个项目用于将数据从外部源加载到 Data Vault 数据仓库中。数据是雇主和雇员之间的工资报表。

在开始建模时，我们找到两个业务密钥，即雇主的公司 ID 和员工的社会安全号码 (SSN)。基于此，我们得到两个中心，一个用于雇主，一个用于员工。在这两个中心之间添加链接时，我们注意到，对于雇主和雇员的每个组合，可能（将会）有不止一个工资报表。这意味着我们不能用两个集线器和一个链接来模拟这种关系。

从逻辑上讲，这可以通过添加第三个工资报表中心来处理。然后我们可以为所有这三个集线器建立一个链接。我们的问题是我们没有任何用于薪水报表的业务密钥！

作为一种解决方法，我唯一的想法是使用公司 ID、SSN 和薪水报表期间为薪水报表生成人工业务密钥。在数据仓库中生成业务密钥确实感觉不对，但我们还有其他选择吗？是否可以使用 Data Vault 进行不同的建模？

任何想法和想法都受到高度赞赏。

我正在使用 2 类数据保险库，目前正在开发一个功能，以尝试模拟数据立方体，以便某些用户从特定快照中快速提取数据。

目前，我可以通过转换连接（或 where 子句）上的参数来修改代码以使其工作，但这会导致 100,000 条记录的性能降低 3 秒。

对于性能是否可以执行

在 return 语句之前的某个地方，或者在一开始的时候。

代码块 - 如果 UTC 值通过则工作

什么是所需的查询形式，因为转换只需要执行一次，而不是针对每条记录。

我试图保管的一个源系统包含一组两个表，它们作为实体属性值表运行。我想知道人们用来将这些表移动到 Data Vault 2.0 模型中的最佳方法是什么。

我们的一个数据源每天发送一个包含数据汇总的提要。定期快照。例如：

我知道在数据库原始库中对此进行建模的两种方法：

多活动卫星

在这里，我们允许每个卫星的每个集线器键具有多行。

这很容易实现，但我们现在对卫星有一个双时元素。

快照中心

第二个解决方案添加了一个额外的中心，它只存储日期列表和日期和商店之间的交集链接。

第二种解决方案感觉更干净，但需要更多连接。

哪个是正确的模型？有没有更好的解决方案？

我是 Data Vault 的新手，请原谅我的无知。我目前正在使用 Data Vault 2.0 并行提升和建模 Raw Data Vault。我几乎没有假设，需要帮助来验证它们。

1) 单个集线器被建模用于：

a）产品（持有pk-Product_Hkey，BK，元数据），

b) 客户（持有 pk-Customer_Hkey,BK,Metadata），

c) 存储（保存 pk-Store_Hkey、BK、元数据）。现在，涉及所有上述业务对象的销售 Txn 应建模为链接表

d) 链接表 - Sales_Link（保存 pk-Sales_Hkey、Sales Txn ID、Product_Hkey(fk)、Customer_Hkey(fk)、Store_Hkey(fk)、元数据）和一个 Satellite 需要关联到链接表，其中包含一些关于链接的描述性数据。上述方法有效吗？

我对上述链接表的理由是因为我将销售 Txn ID 视为非 BK，因此销售 Txn 必须托管在链接而不是集线器中。

2）运营数据有不同类型的客户。（零售，专业）。所有客户（与类型无关）都应在一个中心建模，并且应通过建模与客户中心相关的不同卫星（一个用于零售，一个用于专业）来区分客户类型。以上有效吗？

我研究了在线技术论坛，但得到了相互矛盾的理论，所以我在这里发布。

这里没有适用的代码