一个好的数据模型应该考虑处理的业务流程的上下文，然后用通知支持该流程的决策所需的数据类型来处理该上下文。但是实现这个过程并不是这么容易的。

长期以来，数据模型一直是数据工程师和数据科学家的抽象领域。造成混淆的部分原因是，总是在模型的技术（或物理）结构中讨论数据模型。物理上，指的是数据元素和数据集的技术名称，数据库和数据转换的技术名称，以及最终用户和许多IT员工几乎不了解或不了解的R和Python等编程语言的术语。

这导致公司无法承受的用户和IT业务分析师队伍中对数据模型的原始恐惧，这种恐惧阻碍了针对企业最终目标的数据模型的开发，而这种模型并没有进入数据技术领域，很少有人会从中受益。要改变这种思维方式，业务分析师必须直接参与定义数据模型-但他们不必在业余时间参加数据科学和编程课程来完成这项工作。

定义业务需求

数据模型需要解决什么业务问题？这是一个自动化的贷款决策过程吗？还是针对特定牛群的牛饲料中使用的最佳配料的配方设计师？

业务分析师最有能力与用户合作并可视化所需的业务流程和数据。分析人员还可以用简单的英语描述这些需求。得到的结果是一个逻辑数据模型，通常以气泡图的形式显示所需的不同数据，并附带说明以解释如何处理数据。

在执行此操作时，业务分析师仍将重点放在业务需求上。不必担心必须使用哪些数据集，系统或编程模块来实现业务模型。

与IT和数据科学合作

一旦形成了数据气泡的逻辑图表，并描述了处理该数据需要发生的情况，业务分析师就会与IT或数据科学见面。

这些人将数据模型的逻辑模型转换为物理模型，以IT术语定义了数据存储，系统内部，需要编写的程序等。

IT工程师和数据科学家需要此物理数据模型来完成工作，但是对业务分析师的需求却很少。业务分析师仅需要具有技术术语和流程的工作知识，可以与IT进行高层沟通，并充当与最终用户的联络人，以确保保持数据模型和应用程序的开发不变当然还有业务用例。

试用并安装数据模型的结果

数据模型和应用程序一旦构建，最终用户就可以试用它们了。在此过程中，业务分析师扮演着至关重要的角色，充当用户与IT /数据科学之间的联络人。在此过程中，将对分析应用程序进行微调，签名，然后将其安装在生产环境中。

在许多方面，业务分析师在数据建模中扮演的角色与分析师过去所做的工作并没有太大的不同。分析师定义了用户对应用程序的需求，阐明了基本的业务设计，通过IT扩展了流程，并最终在生产中试用和安装了该应用程序。

尽管可能需要一些术语和技术来掌握与技术人员进行数据模型的讨论，但是了解数据建模的基础知识和词汇并不困难。应该鼓励CIO和业务分析人员，他们现在必须适应数据建模以及如何最好地为业务提供结果并灌输对其用户的信心。

0

好文不易，鼓励一下吧！