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

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

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

有些人认为我们可以开始构建一个应用程序 - 谁需要数据模型？其他人认为我们应该让开发人员创建或更改数据结构。有人说数据建模是敏捷开发的瓶颈。

我称之为“面向应用开发构建”（Just Build It）的方法。这些系统没有提供数据一致性，没有互操作性，没有数据质量，也没有敏捷性。此外，应用程序代码永远无法弥补糟糕的数据架构。它只会导致导致更多问题的解决方案。这是一个架构吗？是的 - 你可以称之为“烟筒式系统”（Silos of Systems），对我来说它是“烟筒式的贫民窟系统”（Silos of Slums）的架构。

敏捷开发或数据湖意味着应该没有设计吗？数据建模者的角色是否应该将开发人员所做的更改反向工程改造成数据模型？

显然，建议这样做的人认为数据模型只是一幅漂亮的图片。商业和管理层也许会有同样的感受，因为他们并不坚持首先设计数据架构。这里我的问题是你如何解决存留系统的问题，存留系统中有什么你如何弄清楚。

“面向应用开发构建”仅仅是为了避免数据建模的一种方式吗？是因为管理层不想为数据建模工具和数据建模资源付费吗？他们是否同意在没有制作蓝图的情况下建造水电站？

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

“面向应用开发构建”（ Just Build It ）方法是数据管理和数据设计不良的保证，导致非标准化的名称和定义，不一致的业务规则和较差的数据质量。

更糟糕的方法是复制现有字段以实现新目的。当多个主题存储在单个字段中时，会发生“数据重载”。重载使管理层不信任他们的商业智能（BI）报告，并且是数据仓库开发的祸根。它还会将数据的业务价值降至接近零。

举个例子：每个应用系统为其“权限”和“许可表单”开发了一个新应用模块。此外，他们为这个权限模块创建了一个单独的数据库这意味着他们使用不同的字段名称和属性在每个数据库中重复了大约75个实体（人员，地址，应用程序，权限......）。

这是典型的跟多依赖表扩展，很少有的数据管理，完全没有数据思维的做法。但最有说服力的是，他们无法通过权限类型或在整个企业的权限报表的简单管理需求。花费了大量时间将信息下载到Excel中，清理它并生成图表。

他们不认为权限/许可证和其他文件是通用的去申请，批准和支付过程的共同对象。他们没有考虑这些文档可以共存在由文档类型区分的公共中心表中。显然，对于面向对象原则如何应用于数据库设计也缺乏思考。

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

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

缺乏前向分析 - 需求定义和数据架构 - 占系统/项目故障的68％到80％。需求和数据设计错误也是最昂贵的修复方法0。从我的角度来看，缺失或比较差的数据建模是系统故障的主要原因。更重要的是，需要更改数据库的缺陷修复成本更高。

所以现实情况是，虽然有些人对数据建模非常负面，但他们从未给数据建模提供过机会，或者他们使用开发人员来完成数据建模的动作。但是你没有聘请管道装配工来设计蓝图。管理层倾向于聘请“数据科学家”（数据分析师的一个炫耀术语），但他们没有利用可以帮助他们进行系统开发的最强大的数据分析师 - 数据架构师。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

业务和管理利益相关者理解他们需要总帐来管理和投资他们的金融资产。一些相同的业务和管理利益相关者拒绝支持使用数据模型。他们认为没有必要将他们的数据视为他们必须管理和投资的资产。

数据建模是数据架构框架（DAF）最重要的标准之一。它是数据设计的基础，也是任何数据管理计划的基础。DAF应定义必须提供的设计产品，以确保良好的数据架构和项目成功。所有业务部门都必须接受并遵守DAF，确保他们向承包商提供的任何工作也遵循相同的标准。