在商业智能中使用 N 层

N 层可能是一个虚伪的术语

我认为在商业智能系统的上下文中使用术语“N 层”是不明智的。在事务系统中，“N 层”描述了具有应用程序服务器、ESB 或其他网络中间层的分布式系统。数据仓库系统的工作方式与此不同，因此该术语可能会引起混淆。

分离数据和功能逻辑

您可以根据尽可能原始的数据构建一个系统，然后在其上放置一个转换层，然后由报告层使用。转换层可以采用以下形式：

• 一系列数据库视图。

• 来自报告工具（例如报告模型或 Business Objects Universe）的元数据层。称为“企业信息集成”的一类工具将元数据层的概念扩展为内存中 ETL 工具，允许报告或功能逻辑层实现复杂的转换。然而，这种方法实施起来很麻烦，并且没有被广泛使用，除非有什么东西阻止实施更传统的 ETL 架构。

• 一套具有自己的 ETL 的数据集市。

根据您的示例，这将为您提供“数据”、“功能逻辑”和“表示”层。一些数据仓库系统的实现有点像这样，尽管它（至少恕我直言）可能是一种反模式。将业务逻辑推向 ETL 下游的一些问题包括：

• 根据您的功能逻辑介质的功能，可能的转换功能可能会受到限制，从而导致抽象泄漏，从而限制放置在它们之上的任何临时报告工具的价值。Ad-hoc 工具需要行为一致的干净数据，并且数据确实必须采用能够很好地与该工具配合使用的格式。
  
  如果数据不一致、不干净且格式不正确，您实际上只能使用定制的 SQL 数据报告或构建辅助数据集市以支持临时设施。依赖数据集市往往会激增大量临时的三级 ETL 过程，这些过程具有重叠但微妙的不一致功能。这往往会产生协调和数据质量问题，并且无法提供“单一的事实来源”。
  
  通常，这种情况会产生大量维护工作量并削弱用户社区的信心。

• 未针对报告进行优化的数据库架构可能性能不佳。

• “原始数据”意味着数据以与源相当同构的形式保存，这与任何符合数据的概念都是互斥的。

• 如果需要进行审计，“原始数据”通常也可以从暂存区和存档区获得。你会得到一类“只想要数据”的超级用户，这些人可能有很大的政治影响力。允许这种情况与数据仓库项目一起继续进行会导致“单一事实来源”的目标失败。
  
  如果仓库有适当的一致数据机制（例如操作数据存储），那么这应该提供单一来源。处理相互矛盾的定义和坚持自己的烟囱式系统的用户社区本身就是一个完整的话题。

尽管如此，这比预期的更常见。我认为人们遇到以这种方式实施的数据仓库项目的主要原因是，如果您对转换逻辑的要求很复杂，那么 ETL 工具很难使用。ETL 工具通常具有简化架构和将逻辑混入报告层的效果，这会显着降低数据仓库计划的有效性。中央数据库的工作量和存在给人一种数据仓库的错觉，但几乎没有提供任何好处。

数据仓库的另一个 N 层视图

人们可以将“数据”、“功能逻辑”和“表示”解释为组织更完善的数据仓库系统中的 ETL 和报告过程。在这种情况下，“数据”可以解释为暂存层，“功能逻辑”在 ETL 中实现，呈现维度数据存储和/或数据集市套件，“报告”通过报告和临时查询实现套房。

被认为是有害的

出于这个原因，我认为“N 层”的概念没有帮助，甚至有点虚伪。这听起来很像中间件公司或咨询公司可能在白皮书中描述的东西——一个有缺陷甚至有点误导性的理论概念，但在纸面上听起来不错。