建模的文章已经写过不少了，但大多停留在星型、雪花型等较为基础的层面。实际上，建模是一项对专业技能要求极高的工作。这不仅需要公司具备强大的技术和实力，还需要精准地把握项目的核心需求，否则会直接影响项目的成败。

2021年2月，IBM因一个数仓项目失利，损失了几亿元人民币。其中一个主要原因在于，IBM派出的团队未能遵循Teradata的金融服务逻辑数据模型（FSLDM）进行企业数据仓库（EDW）的设计。

作为一个旁观者，我对此项目颇感兴趣。现在，让我们来看看这个项目具体是什么情况。

这家名为Direct Line的英国保险公司，在2014年启动了一个名为“Best for Customer”的项目，其核心目标是提升客户服务体验。为了实现这一目标，他们计划将所有客户数据整合到企业数据仓库中，并在此基础上搭建新的业务平台。这样一来，数据打通后，业务流程也会更加流畅，客户价值也能得到最大化体现。

这个构想听起来确实很不错，没有任何明显的缺陷。

该项目的架构设计早已完成。数仓采用的是Teradata的Database14，数据迁移和ETL工具则选择了Informatica的产品。至于数据模型，则使用了Teradata的金融服务逻辑数据模型（FSLDM）。尽管有些人可能对这两个产品不太熟悉，但它们都是行业内的顶级解决方案。Teradata在数据模型领域一直享有盛誉，其建立的数据模型已成为行业的标杆。

然而，项目进展并不顺利。理论上，熟悉业务、强大的技术支持以及IBM、Teradata和Informatica的强强联合，再加上充足的时间，应该能够顺利完成项目。然而，实际情况却并非如此。争议的核心之一是Direct Line认为IBM未按照Teradata的金融服务逻辑数据模型（FSLDM）进行设计。事实上，Teradata已经提供了标准模型，但IBM却反复构建已有实体，导致模型设计混乱，使得数据仓库难以填充、维护和理解。

这表明，IBM与Teradata之间可能存在某些无法调和的矛盾。IBM在执行项目时未能获得Teradata的支持，因此不得不依靠自身经验进行建设，最终导致项目失败。

2016年，IBM将全部代码移交给Teradata，后者推倒重来，重新设计。这起事件不仅让IBM蒙受巨大损失，还引发了法律诉讼，直至今年2月才尘埃落定，IBM被判赔偿3亿多元。

虽然我对IBM的具体情况并不关心，但我希望借此机会分享Teradata的金融服务逻辑数据模型（FSLDM）。这是一个复杂且重要的主题，值得深入探讨。如果本文的评论区超过30条评论，我会专门撰写一篇文章，详细解析Teradata的标准数仓模型FSLDM，让大家了解经典数仓模型是如何构建的。

此外，您还可以关注我的公众号“大数据架构师”，那里会有更多相关内容。