其实建模的文章写了不少了，但是都还停留在什么星型、雪花型这些比较粗浅的内容层面。
其实，建模这件事情是个能力要求非常高的技术活儿。而且这个活儿不是说公司牛、技术牛就能搞定的，这件事情直接决定项目的成败。
就在 2021 年 2 月份，IBM因为一个数仓项目失利，赔了客户好几亿。其中一个原因就是因为IBM叫过去的人，没有按照 Teradata（天睿）的金融服务逻辑数据模型（FSLDM）去设计企业数据仓库EDW。
我作为吃瓜群众，就喜欢看热闹。而且，这里面的建模可以好好跟你聊聊。
这是个啥项目？
起因是这样的，有一家英国保险公司，叫Direct Line，2014 年整了一个项目“Best for Customer”，跟所有保险公司一样，这个项目的核心是为客户服务。
他们本来想把所有的客户数据都归归拢，放到企业数据仓库EDW 里，然后上面架设一个新的平台，所有保险业务都在这上面跑。数据打通了，业务流程也就能更顺畅，客户价值也能发挥到最大。
你看，想的是不是很好？没毛病啊！
整个项目的架构呢，也是早就设计好的。数仓用的是 Teradata 的 Database14，数据迁移、ETL 用的是 Informatica 的产品，也是世界顶尖产品。数据模型就用 Teradata 的金融服务逻辑数据模型FSLDM。
有些同学对这两个产品有些陌生啊。ETL 工具刚才说过了，Teradata 就好玩了。这么跟你说吧，Teradata 一度是全球数仓界最牛的公司，没有之一。这个称号不是我说的啊，是客户说的。Teradata 建的各种数据模型，早就是业界标杆了。
那出问题了？
按理来说，熟悉的业务，强大的技术，加上IBM、Teradata 和 Informatica 这么强大的组合，又给了足够的时间。虽然有一些新系统的建设和新旧系统的切换，但是这都是有完善的解决方案的，不应该出现啥问题。
但是恰恰就是这不可能出问题的项目，最终让IBM赔钱了。
这次争议的核心点之一，就是Direct Line 公司说IBM没有按照 Teradata 的金融服务逻辑数据模型（FSLDM）去搞设计。明明 Teradata 这边已经有标准模型了，还要不断重复建已有的实体。
原话是：“过以一种毫无章法、毫无根据的方式来复制和粘贴，以扩展该模型，结果破坏了设计集成层，使得 EDW 难以填充、维护和理解”。这句话的评价真的是太崩溃了。
明眼人一看就知道，IBM和 Teradata 之间肯定有什么不可调和的矛盾。我估摸着是这样的：IBM 要去做项目，但是关系没搞好，Teradata 一直就没鸟他，也不给资料，也不给支持，然后 IBM 就只好自己干。自己干呢，又没有 Teradata 的支持，就只好根据自己这边的经验搞建设了，最后搞的稀碎。
最后，IBM 在 2016 年移交全部代码，由 Teradata全盘接手，推到重来。你说这事闹的。
这还没算完。东家把 IBM 给告了！官司打了好几年。反正双方都你来我往，说自己没问题呗。这个案子到今年 2 月才判下来，我看的是赔了 3 个多亿啊。
