当海豹突击队奉行其座右铭“慢即顺畅，顺畅即快”时，他们可能也在同时讨论构建数据模型。海豹突击队选择了这个短语来提醒其参与者 不要着急 但要深思熟虑地行事。数据建模做 一样 通过帮助企业设计和更新 数据架构故意地。
使用数据建模生成的数据表示，业务团队在开始编码之前传达系统需求并解决设计问题。但高层管理人员没有耐心在动荡的经济中等待数据模式。相反，他们希望每个人现在都能更快地处理数据和流程 ！数据建模如何通过提供深思熟虑和及时的信息而不变得无关紧要来适应这些条件？
在 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 看到了技术变化，因为公司从现有数据架构中提取和集成，并为另一个目的重新表示它。在这个过程中，业务部门之间需要有足够的异花授粉，对公司的数据进行概念建模，并在代码中表示出来。
为了热爱他们的数据，公司需要一种通用语言，企业和开发人员可以使用这种语言来迭代现有数据结构。这种语言来自于通过交换数据架构思想来桥接业务和技术。
为了热爱他们的数据，公司必须采取审慎、迭代的方法，使用数据模型来指导。这种策略会给海豹突击队留下深刻印象。
