ETL 中的分层数据

Question

我是 ETL 工具的新手，但我发现它们都适用于平行模型。 IE。如果您的数据需要一些图形对象转换（即检查父字段或其他依赖项），则非常不方便（可以通过非规范化等来解决以映射到更简单的 RDB 模型）。我想问一下我理解是否正确。以及为什么 ETL 避免使用更易于理解的面向业务对象的模型。是否有支持Document相关或OOP相关转换的ETL？

Answer 1

我不确定我是否完全理解这个问题，但需要考虑一些想法：

• 大多数ETL范式来自数据集成和决策支持领域，即来自数据仓库设计和实现。这个世界传统上是面向关系数据库的，大多数数据源以数据库表或 CSV 文件的形式存在。这可能是“平行模型”的一个原因。
• 简单的数据模型对于高吞吐量性能很有用，并且在大多数情况下不会过度限制：ETL 工具用于数据密集型任务。
• 我所知道的大多数工具都假设源记录是相互独立处理的，它们不会相互影响。然而，情况并非总是如此，因为某些工具可以聚合数据（例如 Informatica 聚合器元素） - 数据模型不再那么平坦。
• 扩展平面模型的其他示例包括检查外键依赖关系（“父字段”）、字典表（甚至 Web 服务）的使用、执行任意操作的外部类的定义（“OOP”）等。但是，ETL 数据模型总是停留在较低的抽象层次上。

Answer 2

Altova MapForce 可以处理分层数据。

Answer 3

我认为这是一个非常有洞察力的问题。自从几十年前发明 ETL 以来，我们一直以同样的方式进行它。仅仅因为过去这样做并不意味着我们应该继续这样做。 30 年前“正确”的做事方式现在不一定是正确的。如果从定义业务规则的对象层次结构开始，那么平面 ETL 的东西正是您最终不会得到的......