1

我正在研究使用 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

人 - 人名 - 全名 - 登录

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

SELECT
   hash_func(o.order_ref) as hash_key_order,
   hash_func(c.customer_ref) as hash_key_customer,
   hash_func(p.login) as hash_key_person,
   o.orderid, 
   c.customerid,
   p.login
FROM
   order o inner join customer c on o.customerid = c.customerid
   inner join person p on o.salespersonid = p.personid

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

SELECT
   hash_func(o.order_ref) as hash_key_order,
   o.orderid, 
   c.customerid,
   p.personid
FROM
   order o

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

4

2 回答 2

1

我不太确定为什么有一个复杂的 SELECT 语句来填充订单。此外，我认为关于 Data Vault 的范例可能存在一些混淆。您想要使用 Data Vault 执行的操作是从源系统中读取所有数据。

这意味着首先您要将表加载Order到似乎使用 Data Vault 建模的核心 DWH 中。然后你会对 , 做同样的事情Customer，Person依此类推。直到您稍后需要让您的声明工作的所有数据都在核心 DWH 中。

每个实体都有自己的哈希键，具体取决于实体。例如对于Order表，这可能是id.

现在，当所有内容都加载到 Data Vault 中时，您可以在数据之上重新创建业务规则。这意味着，如果您使用代理键，您可能需要重新创建它们。如果代理键是事先在数据库中创建的，并且它们具有商业价值，请使用它们。

但这取决于 id 的使用。正如我之前评论的那样，您首先需要知道业务如何处理您提供的案例。然后，您将每个数据单独加载到 Data Vault 中。然后您继续重新创建您作为示例添加的语句。

所以：

  • 复制数据
  • 重新创建业务规则（如果订单没有客户会发生什么）
  • 创建视图/持久表
  • 使用数据
于 2018-02-16T17:11:03.507 回答
0

问题是您没有导出 BK。您正在导出代理键。在您的查询中将 o.orderid 更改为 o.order_ref 等，一切都应该就位。不幸的是，人们不了解 ID 背后的原因。它们是用于性能和管理目的的内部数据库元素，与业务无关。

个人电脑

于 2018-02-26T05:20:26.130 回答