数据建模-今天还需要数据建模吗

译者前序

这是来自国外某博客一个文章，我之前曾经思考过这个问题，发现本文作者说的更系统些。在一个我国大部分企业的IT部门还是“程序流“的人有更多话语权和决策权，这也是很多企业数据战略的现状，暨由具有”程序流“思维的人来主导数据战略，恰好今天因为姚明的改革背景下，赛事男篮重夺亚洲冠军，人们抛出一个结论，还是专业的人管专业的事情。我想到数据战略也应该由有“数据流”思维的人主导，否则应用系统的烟筒式问题会换一种形式出现在数据应用上，我称之为“烟筒式数据分析“。

以谦卑的心态斟酌学习文中观点，在此特别感谢谷歌翻译，让我能节省太多时间。文中大部分是直译，理解有困难可以点击下面的英文原文去参照。

一、面向应用开发构建的架构模式

敏捷开发或数据湖意味着应该没有设计吗？

如果说要数据建模，在敏捷时代会被认为这成了瓶颈，还浪费时间。有些人认为我们可以直接开始构建一个应用程序，让开发人员自己创建或更改数据结构。

我称之为Just Build It的方法，结果导致这些系统数据不一致，无法互操作性，数据质量低，以及没有了真正的敏捷性。那些在应用程序代码级别的行为变成了一种徒劳，这永远无法弥补糟糕的数据架构，只会导致导致更多有问题的解决方案。

二、数据模型只是一张漂亮的图片吗？

商业和管理层并不坚持首先设计数据架构，我想问问他们：你们如何解决存留系统的问题，存留系统中有什么你如何弄清楚？

“面向应用开发构建”（ Just Build It ）方法是数据管理和数据设计不良的保证，导致非标准化的名称和定义，不一致的业务规则和较差的数据质量。这仅仅是为了避免数据建模的一种方式吗？是因为管理层不想为数据建模工具和数据建模资源付费吗？他们是否同意在没有制作蓝图的情况下建造水电站？

此外，开发人员没有适当的数据建模或数据管理设计方面的专业知识。开发人员方法是“表扩展”。在代码开发的一半时，他们会说，“哦，我们需要一个新的实体或数据元素”，所以让我们只添加一个表或列。

三、缺乏数据思维的架构模式

当多个主题存储在单个字段中时，更糟糕的方法是复制现有字段以实现新目的，这导致数据质量低下，不可信，这将数据的业务价值降至接近零。举个例子：每个应用系统都有一个“许可表单”的全新应用模块。他们不认为许可证是通用的共同对象，于是为这个模块创建了一个单独的数据库，这意味着他们在每个数据库中使用不同的字段名称和属性，这样就重复的出现了大约75个相同实体（人员，地址，应用程序，权限……）。

这不仅导致存在数据库和应用程序的孤岛，还存在商业智能（BI）输出的孤岛。我工作过的一个组织平均创建了15个BI报告变体，这些变量可能是一个“基础”报告。这意味着大约15倍的开发工作量和至少15倍的支持成本。

数据架构不仅仅是绘制漂亮的图片，它不仅是数据建模，也是关于有远见和应用架构原则来确保高质量的数据设计和项目成功，这是非常值得投入的成本。

四、项目失败的深层次原因

从我的角度来看，缺失或比较差的数据建模是系统故障的主要原因。缺乏前序需求定义和数据架构工作的分析是系统/项目故障的68％到80％原因。更重要的是，需要更改数据库的缺陷修复成本更高。

然而现实情况是，虽然有些人知道对数据建模的重要性，但他们从未真正重视数据建模，或者他们直接让开发人员自己去完成数据建模的工作，就这就像你没有聘请管道装配工来设计蓝图，而是让工人直接来安装。

（译者注：这在我接触的企业也非常普遍，缺乏了解全面数据的架构师正在成为企业数据利用的瓶颈。）

同样，有些人希望跳上Hadoop的旅行车，即使他们没有大数据。我可以想到一个案例，领导想要一个OLTP /关系系统的大数据解决方案。他们认为大数据意味着没有架构，没有建模，没有任何问题。人们想要一根魔法杖来解决所有问题！然而，对不起，那些仙女教母和她的魔法杖目前还不存在。现在，计算机科学更像是一种艺术形式，而不是一种科学。

我们需要的是将科学重新纳入计算机科学，所需要的是科学方法。

五、数据架构成熟度

应用程序开发的目的是快速构建它吗？或者重点应放在改进数据管理上？恕我直言，数据架构是数据管理计划中最重要的功能区域。这反过来又对数据质量（DQ）和应用程序开发产生直接影响。注意：

数据是方法论框架的第一个组成部分，如TOGAF、Zachman、BangEA。
数据当然是DAMA DMBOK的主要组成部分。公司谈论的数据非常重要，但他们不会说话。那么语义问题出现在哪里？您需要对自己的数据方法和流程进行评估。
您花在维护遗留系统上的费用是多少？这项工作有多少是由于设计不良的数据结构造成的？您是否跟踪此时间和费用类别？
数据架构是您系统开发方法的一个独特部分吗？
是否仔细估计了数据架构任务（是的，这很困难）并单独包括含在您的项目计划中？
数据架构可交付成果是否作为业务需求阶段的扩展而执行？
在应用程序开发开始之前，数据模型是否已完成并获得批准？
您的组织是否有数据架构师？
您的组织是否理解数据建模者和数据架构师之间的区别？
您的组织是否了解数据模型的用途？
您的组织是否知道规范数据模型是DAMA DMBOK的主要可交付成果之一？
您的组织是否使用规范数据模型作为所有项目特定模型/数据库的模板？

六、数据模型的目的是什么？

1.施工规范

如果您正在建造核电站，那么您是否只是建造它？不，假设这不是非法的，那也将是非常危险的。建筑师必须首先了解要求并设计施工蓝图。

当您需要数据库或数据交换有效负载时，数据模型就是您的蓝图。数据模型还定义了关系和元数据 – 数据类型，长度，约束和其他数据完整性规则。换句话说，数据模型是构造的规范。

组织应在使用内部资源或外部承包商启动项目之前完成数据建模。特别是，政府部门在进入RFP寻求解决方案之前应该执行数据建模/要求。这将实现更好的时间和成本估算，并减少昂贵的重新设计，返工，预算超支和合同冲突。

2.数据要求

数据模型的主要目的是识别或确认数据要求。换句话说，它实际上是业务需求定义的扩展。它还需要数据分析。如果企业没有足够详细地定义他们的需求以便能够导出数据需求，那么项目肯定不准备开始编程。有时（很多时候）记录的业务需求只是伪装成需求的某种陈述。

在许多项目中，我还必须充当业务分析师/架构师来定义精确的业务需求。数据建模识别并确定缺失或隐含的业务需求，并将其解释为数据需求。因此，它必须是发展阶段的强制性前提。

项目或迭代的目标不应该只是快速完成它。目标是为企业提供符合其总体需求的解决方案。数据建模的一个目标是在不破坏数据结构的情况下促进未来的应用程序功能。数据模型必须支持基于服务，基于组件和敏捷的开发。

许多组织不了解数据模型的目的。如果您正在尝试将敏捷方法应用于数据建模，我认为您错了！人们需要从大局出发，为解决方案提供全面的愿景。只有这样才能逐步构建应用程序，同时合理地确定数据结构不会中断。数据模型是解决方案开发的蓝图或精确规范。

七、设计不佳的症状是什么？

1.缺乏数据完整性

设计不佳的一个明显迹象是缺乏数据完整性，这意味着根据关系数据库之父EF Codd的规则。在数据库中找不到主键和外键，因此没有参考完整性，这是令人心痛的。设计不佳的一个明确标志是每个表的平均索引数小于3。应该始终有一个主键。应始终存在代码表的外键。我已经看到关系数据库由许多表组成，这些表没有链接或与任何其他表相关，甚至是其值被用作参考代码的表。

2.缺乏SQL技能

写得不好的SQL语句通常是最大的性能问题。图4仅列出了SQL清单中应该包含的两个示例。但是，如果WHERE子句中最重要的选择标准未定义为索引，即使编写良好的SQL也无法实现。坦率地说，我在许多组织中看到了同样令人震惊的缺乏SQL知识。这表明了对数据设计和SQL标准/技巧的需求。查看开发人员缺少SQL技能的更多示例。

3.面向开发人员的设计

数据模型/数据库的目标不是简化开发人员体验。它是为了提供最好的客户体验。使用神秘的缩写列名称可以使开发人员更容易。但这对客户的理解非常不利。它阻止了自助商业智能。相反，可以在不使用翻译器的情况下理解的商业语言名称应该是标准。

使用包含所有引用表的表格可以使开发人员更容易。但是您无法将子操作数据表链接到父参考代码表。您无法在数据模型中的表之间看到关系（作为行）。您无法强制执行参照完整性。

八、专注于元数据

流行语和短语在业界很流行，例如元数据是关于数据的数据。对我来说，最好将元数据视为对象的属性。列出表，列及其元数据需要花费大量的手动工作。一些组织试图解决业务单位和系统孤岛之间术语的差异。

1.业务术语表

Business Glossary流程可用于解决冲突的定义和分类。公司应该合并不同的定义并标准化同一对象的名称; 例如，客户，客户……例如，军队的每个分支可能具有不同的“ 准备 ” 定义和算法。定义标准化指标是词汇表或目录的另一种出色用途。

但组织不应该花时间在基于ISO，电话（ITU），旅行（IATA），地址（邮局）或其他国际标准的参考和主数据上。企业通常不知道地址和电话的正确标准。有多少人认为电话号码是数字的？错了，他们是可变的角色。相反，企业需要接受并采用这些标准。

可以购买COTS工具，使用建模工具附带的词汇表，或者轻松地使用MS Word或Excel作为词汇表。但是这些方法没有将数据元素的属性定义为定义数据库所需的精度级别。

2.数据字典

数据字典是主要的元数据工具。恕我直言，看到人们使用MS Word或Excel手动创建数据字典令人恼火。他们花了几个月钱。在几分钟内，人们可以使用数据建模工具对实际数据库进行逆向工程，并立即获得数据字典。

数据模型是权威数据字典。这是因为数据模型是应该用于设计，创建和修改实际数据库的工具。如果您反向工程或创建数据库模型，那么您将知道数据资产是什么，数据库和表使用它们的位置。只能通过在数据模型/存储库中记录此信息来提供上下文和描述。

“概念”数据字典将隐藏数据库设计所需的许多属性和细节，这些属性和细节与业务无关。最好的数据建模工具允许您根据受众显示/隐藏属性。

另一方面，许多组织不使用数据建模工具。在拥有数据模型的组织中，我可以依靠一方面的手指，我看到任何关于实体和属性的定义和目的的描述。我从未见过任何数据分析记录来确定如何真正使用列。我从未见过解释数据元素如何支持业务流程和目的的描述。没有跟踪数据元素的谱系。难怪业务认为他们需要一个“数据字典工具”。他们实际上可能有一个工具，但没有使用它以达到最佳效果。

我没有为任何已经实现单一（统一）数据字典的组织工作。这无论如何都是不切实际的，因为你不能拥有由系统孤岛组成的单一全域词典来源。保持最新状态也非常耗时，因为系统总是在变化，开发团队不会通知您更改。但是，真正的问题是系统在不使用数据建模工具的情况下进行了更改。

那么为什么要逆向工程数据库？一个原因是在开发集中服务或单一真实数据源仓库时分析源系统和目标系统的要求。这些服务需要标准化数据。这意味着您必须决定数据标准是什么以及未来的数据结构将支持这些服务。

3.规范企业数据模型

规范或企业数据模型（EDM）的目的不是捕获组织中的每个数据元素。应该捕获感兴趣的数据元素是组织希望规范和重用。因此，恕我直言，EDM的目的应该是提供每个项目特定模型必须使用的50％到80％实体的模板。这些实体是什么？

应使用企业数据模型来确保整个企业中的公共参考代码和主数据表是相同的。规范数据模型为所有未来系统中所需的标准化元数据定义数据字典。它为解决方案设计提供标准和构建块。换句话说，EDM提供真实数据字典的单一来源。

这意味着所有BI报告中的分类模式，层次结构，选择标准，维度，事实数据，列名称和核心主元数据（数据类型，长度，目的）都是一致的和一致的。这意味着整个组织的所有员工都“说同一种语言”。换句话说，您可以为所有未来的系统定义一次开发规范，从而实现互操作性和数据可信赖性。