企业大钥匙

Question

很长时间以来，我一直在从事ODS和数据仓库的工作。两者都在集成来自炉管应用程序的各种数据源。ODS的一个用途是向其他炉管应用程序提供数据。

想象一下，一个应用程序维护一个人员数据库，而另一个应用程序管理跟踪销售。有时候，销售应用程序可能需要减少一些人员，让他们从中挑选，比如向某个员工提供销售/佣金。

销售应用程序可以查询ODS以获得人员列表。这允许人事应用程序改变其数据结构，ODS修改ETL过程以适应这种变化。因此，使用该数据的所有其他应用程序都不会受到更改的影响。

这个销售应用程序需要将一个PersonnelID保存到自己数据库中的销售/佣金记录中。但是，下一次更新ODS时，如果使用的是满载技术，则关键将发生变化。由于存储在Sales数据库中的PersonnelID是一个单独的数据库，因此没有直接的方式来级联这种更改。

这就产生了一种挑战，即对ODS所作的任何更改都必须非常谨慎，甚至可能限制某些设计，因为外部应用程序依赖于这些密钥，永远不会改变。我通常会避免向用户公开密钥，但在这种情况下，似乎有必要允许外部应用程序在自己的应用程序中引用企业级实体。

对于ODS中可用的查找表也是如此，其中查找表有键和文本。

在ODS满载之后，我可以确保密钥在数据库中满足参考完整性，但对于使用这些键的外部数据库则不满足。由于ODS的某些部分目前编码为满载，这将导致密钥重新生成，因此我需要对ETL进行增量编码，以便外部数据库可以引用这些密钥，而不必担心它们会更改。

当您有一个企业范围的数据源，而其他应用程序使用该数据并需要在该数据中存储引用实体的外键时，会使用什么技术？如何在不增加对该数据的访问的情况下尽可能地解耦外键引用？

目前，我正在使用表值函数提供对数据的访问。我之所以选择这种方法，是因为它允许参数、连接和对底层表的解耦访问，这些访问可能会在以后发生更改。

Answer 1

你必须遵守这些规则：

1. OLTP应用程序不会更改键。
2. ODS生成自己的业务智能密钥。
3. Datawarehouse数据库从不引用OLTP键，必须使用ODS生成的密钥(步骤2)。

除非你每天晚上做一个满负荷的工作，否则就没有办法依靠上述任何一条规则。

试图从OLTP获取“delta”(仅更改数据)在大型企业系统(如Siebel、SAP等)中通常是一场噩梦，除非您的ETL提供“连接器”(针对ERP和类似工具的固定查询)，而且您对源OLTP系统有专门知识。即便如此，由于此类企业模式的复杂性，通常情况下也会比较困难。

再说一遍，你必须遵守上面的规则，而且很可能，没有别的办法了。金球，有一套很好的书籍关于这个主题，如果你愿意挖掘更多。