共计 2976 个字符，预计需要花费 8 分钟才能阅读完成。
当海豹突击队奉行其座右铭“慢即顺畅，顺畅即快”时，他们可能也在同时探讨构建数据模型。海豹突击队抉择了这个短语来揭示其参与者 不要焦急 但要三思而行地行事。数据建模做 一样 通过帮忙企业设计和更新 数据架构成心地。
应用数据建模生成的数据表示，业务团队在开始编码之前传播零碎需要并解决设计问题。但高层管理人员没有急躁在动荡的经济中期待数据模式。相同，他们心愿每个人当初都能更快地解决数据和流程！数据建模如何通过提供三思而行和及时的信息而不变得无关紧要来适应这些条件？
在 DATAVERSITY 的 企业数据世界 (EDW) 在“古代数据建模问题和挑战”小组中，参与者分享了数据建模的第一手教训，以及它如何持续扭转数据行业。
以下专家发言：
- John O’Brien：首席参谋兼首席执行官 辐射参谋
- 唐娜·伯班克 (Donna Burbank)：董事总经理 寰球数据策略
- Karen Lopez：高级项目经理和架构师 信息参谋
- Pascal Desmarets：创始人兼首席执行官 黑果糖
所有四个人都探讨了当初和将来的数据建模问题和挑战。
数据建模持续增长
对于那些认为数据建模跟不上业务倒退速度的人，Donna Burbank 提出异议：“数据建模没有隐没，只会持续增长，”她说。
这个主题在小组成员的评论中失去了回应。因为以下起因，数据建模持续增长：
- 数据架构复杂性的减少：Karen Lopez 留神到记住数以千计的数据库系统的艰难。她说，“我无奈理解他们的产品和服务，更不用说他们的性能了。”Pascal Desmarets 将这个想法扩大为 多语言持久性，其中“组织以不同类型的技术存储雷同的数据。”此外，“公司必须从现有零碎中提取和集成数据以满足他们的其余需要，”John O’Brien 说。这种日益减少的复杂性意味着组织须要更新现有的数据模型。
- 数据建模自助服务选项的减少：依据 O’Brien 的说法，数据消费者有更多抉择，尤其是在数据筹备方面。因而，商人和公众领有了构建和参加“交互式数据可视化”的工具，洛佩兹指出。Burbank 批准：她认为自助服务的改良激励每个人都参加数据建模，包含小型博物馆、非营利组织和医疗保健组织。更好的自助服务意味着更多的人在建模。
- 恪守隐衷和数据法规：即便公司最后从未打算进行数据建模，他们也必须在公布其合规数据产品时这样做。Desmarets 提到团队回过头来对数据应用程序进行逆向工程以确保他们满足 材料规定，例如欧洲通用数据保护条例 (GDPR)。
数据建模代表业务了解
数据建模超过了 JSON 文件等技术：“数据建模代表了您对业务的了解，”O’Brien 说。
JSON 与业务了解
查看公司的 JSON 文件并确定开发人员对业务的理解水平。
公司应用 JSON 语言“以自描述的形式构建数据。然而你如何形容它会影响数据存储形式的品质和效率，”Desmarets 说。
JSON 因其易于捕捉和传输数据而吸引了公司。只需通过关上正确的文件并更改其 外围价值 代码中的字符串。
O’Brien 正告说，这些疾速的 JSON 更新通过扭转业务需要强烈地表白了本人，因而它们可能会导致上游的问题。如果业务需要仍不明确，外部客户会解压收到的 JSON 数据产品并看到不稳固且不可预测的后果。
为了事后避免这些问题，Burbank 激励公司约定一种通用语言来形容存储在 JSON 中的数据。“当团队将技术和业务数据结构分割起来时，组织会更好地了解他们所做的事件，”伯班克察看到。
应用 DataOps 加深业务了解
Lopez 将就共同语言达成统一的想法更进了一步。她的数据建模解决以各种形式传输数据的集成，例如 XML、JSON、通用分隔文件和镶木地板。她留神到，当工程师们切换到另一种语言格局时，匆忙应用一种语言格局的问题和经验教训会被从新探讨。
她说，“人们给每一块代码起一个名字。然而，团队在没有领导的状况下并不知道那个团块意味着什么。”侥幸的是，一些 数据运维 工具和流程帮忙组织定义不同代码块的作用。
DataOps 应用模型来帮忙公司无效地开发和交付剖析。然而，这样做须要的不仅仅是几个治理数据库的数据库管理员 (DBA)。
此外，DataOps 须要商人。Lopez 认为，让她的“数据业余同行参加设置、定义和参加 DataOps”将疏导他们与 IT 单干并改良数据模式，无论应用何种编程语言。
拥抱应用程序的疾速倒退
Desmarets 强调，数据建模者及其工具必须反对组织生成的应用程序的疾速倒退。其余小组成员也反对这种对更麻利的数据建模的需要。
可怜的是，正如 O’Brien 指出的那样，“一种旧观点曾经成为事实，即数据建模须要很长时间并且须要太多剖析。”然而，这种刻板印象并不合乎企业在开发数据产品时所需的增量办法。
组织必须随时重构其数据需要和构造。Desmarets 补充说，向云的迁徙和疾速的应用程序变更迫使数据建模反对所有这些变动。
为了跟上疾速倒退的步调，小组成员提出了以下倡议：
- 元数据即代码：自动化元数据，无关数据的信息，有助于更快地连贯技术和业务定义。Desmarets 认为公司能够通过应用数据平台中编码的元数据来理解如何应用、解释和解决他们的数据。
- 工具改良：Burbank 发现 PowerPoint 和在线白板或 Meri 板能够更好地翻译业务需要。PowerPoint 容许用户在较高的概念级别传播数据建模，而可视化白板数字化使业务重点更轻，能够进行更多迭代并做出更多反馈。然而，正如 Burbank 指出的那样，“咱们须要更快、更好和不同的工具来解释业务部门之间的数据架构。”
- 模型驱动的数据库设计：Lopez 激励数据建模人员采纳模型驱动的数据设计以实现敏捷性并作为 DevOps 的一部分。在这种办法中，数据建模人员解决所有设计的束缚、规定和其余要求。“团队取得 数据品质 他们为此进行了打算，并应用定义的状态结构来掂量开发人员的施行状况，”洛佩兹说。
- 将数据模型与应用离开的语义 / 形象层：正如 O’Brien 强调的那样，要更快地示意技术代码须要正确。领有更好的直观工具来辨别其数据平台中的数据模型无望通过共享技术和业务了解更快地实现目标。
论断：爱你的数据
为了更顺利、更快地进行数据建模，Lopez 建议您“酷爱您的数据”。当用户发现他们的数据有用且有价值，并且具备足够的数据品质时，他们就会喜爱他们的数据。
Lopez 看到组织在数据品质方面进行了更重要的投资，因为任何人都能够在没有 DBA 参加的状况下染指并为他们的数据建模。正如 O’Brien 察看到的，这种自力更生使数据建模变得无形并与了解业务相干。
对于 Desmarets，酷爱您的数据须要 麻利数据建模. 他看到古代数据建模者可能在生产中应用现有的数据架构模式，并从最后的数据库抉择中移除。因而，取得爱护数据所需的数据品质意味着在下一次迭代后通过数据建模获取现有数据并确保其合规。
因为一直变动的业务需要，Burbank 看到了技术变动，因为公司从现有数据架构中提取和集成，并为另一个目标从新示意它。在这个过程中，业务部门之间须要有足够的异花授粉，对公司的数据进行概念建模，并在代码中示意进去。
为了酷爱他们的数据，公司须要一种通用语言，企业和开发人员能够应用这种语言来迭代现有数据结构。这种语言来自于通过替换数据架构思维来桥接业务和技术。
为了酷爱他们的数据，公司必须采取审慎、迭代的办法，应用数据模型来领导。这种策略会给海豹突击队留下深刻印象。
