商业分析指南/数据建模和数据文档

商业数据是任何组织的关键资产。数据中包含的信息在组织运营、报告和衡量组织绩效方面发挥着重要作用。信息系统提供了捕获和共享数据以及监控业务绩效的手段。健全的数据结构是普遍需要的，以确保数据完整性和最大程度地减少未来的应用程序维护成本。为信息应用程序创建“正确”的数据存储涉及数据治理、了解数据流以及开发可靠的基础，以确保持续的可靠性、稳定性和投资的最大效益。

商业数据

数据治理和安全

对信息系统的投资对于构建新应用程序、修改现有应用程序或购买和迁移到 COTS（商用现成）解决方案来说可能非常高。为了确保这些投资能获得最大回报，可以通过数据治理和安全的形式实施控制。这些控制可能存在于组织细分内部、跨细分或跨整个组织。一些控制甚至具有全球性质，由国际协议决定并遵循公认标准。

数据治理涉及谁负责组织数据以及如何执行治理决策和流程。数据治理可能采用一种或多种不同的方法。这些包括

• 自上而下 - 决策具有权威性，影响整个组织
• 自下而上 - 与数据相关的决策在较低级别制定（例如，命名约定）
• 自中心向外 - 通常涉及聘用顾问来考虑所有利益相关者的治理需求并提出组织范围的建议（对于批准的决策，会导致自上而下的决策）
• 孤岛内 - 多个组根据集体协议制定治理标准。

数据治理的目标包括确保商业数据的质量和安全、数据符合组织标准、总体数据规则和定义，以及确保数据可信。

业务所有权

在创建新的信息系统时，应用程序通常由一个或多个业务程序领域或部门赞助。组织数据治理要求识别那些将“拥有”数据的个人。这些所有者将负责监督、与组织的治理委员会协调、符合采用的标准和法律以及确保数据访问权限。一个“所有者”可能负责应用程序域内的数据，或者责任可能分散在多个所有者之间，分布在一组集成应用程序中。无论如何确定组织内数据所有者（或所有者），项目数据需求的批准都将来自该所有者角色。

消除冗余

数据冗余是当同一信息在同一个或多个数据存储中被多次捕获时造成的。如今大多数信息系统都由基于 Edgar Codd最初设计的关联模式构建的数据存储支持。这种类型的模式最大限度地减少了冗余并确保数据完整性。与数据冗余相关的问题围绕着这些数据的多个实例之间的冲突，并导致与数据相关的更高的运营成本。这些成本包括与数据输入、检索和维护相关的成本。它们还构成安全威胁，因为它们在数据中引入了异常——无法确保最终用户查看的是单个真相版本。适当的数据定义确保识别任何冗余，并在实际设计系统之前对其进行纠正或缓解，从而降低相关的开发和持续维护成本。

数据文档

应用程序数据的文档对于确保对数据中包含的信息有共同的理解以及确保该信息的可靠性至关重要。业务分析师通常负责为信息系统项目创建数据文档，并将此文档与治理流程和规则保持一致。文档工件将跨越整个 SDLC，从启动到实施。

数据流图

纽约州工人赔偿申报

跟踪数据在应用程序中的流动包括识别将得到支持的数据源、转换和目标。目标包括数据存储和使用数据的下游流程。数据源可以在组织内部和组织之间共享，或者可能涉及外部实体。它们包括数据输入、现有数据库、计算机文件以及来自外部应用程序的数据流。确定数据源后，定义必须执行的转换或操作数据的流程。这些流程包括将数据从源格式转换为目标格式。目标包括数据库、文件、报告和接收转换流程输出的外部应用程序。数据流图捕获此信息以进行验证和设计目的。

互联网上有很多教程可以参考来创建数据流图。一般来说，在渲染数据输入、处理和数据输出方面保持一致性将实现以下目标：以一种易于理解的方式定义数据流，以便那些将审查和验证图内容的人能够理解。图像右侧包含使用 Yourdon/DeMarco 符号的数据流图示例。

数据定义

车辆所有者数据表

捕获数据元素定义最常用的格式是数据字典。该工件对于数据治理以及确保所有利益相关者对数据是什么都有共同的理解至关重要。数据字典中通常包含的信息包括数据所在位置的识别（信息系统、关系表）、确切的数据库字段或数据元素、数据元素代表的内容以及元素的格式。右侧图像提供了一个数据字典可能是什么样子的示例。

通用数据矩阵

通用数据矩阵 - D = 定义；P = 提供；U = 使用

在项目的需求收集阶段，当需要进行跨多个应用程序的数据集成，或进行某种程度的主数据管理 (MDM)，或进行某种形式的组织数据治理时，会使用常用数据矩阵。它是一种数据字典的形式，包含治理域的范围。为了构建这种矩阵，数据元素将根据治理域列出，并提供有关该数据与与其交互的组织单元或应用程序之间的信息。应构建此类型的图表以包含与所考虑问题相关的的信息（参见右侧图像）。

考虑一个信息系统，它使用来自其他组织（内部）应用程序的外部数据元素。这些元素的定义、含义和格式对于集成至关重要。在治理成熟度高的组织中，客户名（例如）将在整个组织中具有相同的数据元素定义和格式。实际上，大多数组织并未在整个组织范围内完全统一所有数据定义；在确定集成工作项目需求时，应使用常用数据矩阵对集成项目的数据元素进行汇总。在这种情况下，矩阵中包含的信息（矩阵单元格）可能包含数据元素格式信息，以识别可能需要对数据进行的任何转换以将其与项目信息集成。

数据需求建模

为了建立新的应用程序和进行应用程序增强，在较高层次上对数据进行建模可以为设计工作提供指导。通常，业务分析师不参与应用程序的实际开发，但与项目相关的需求将决定支持项目可交付成果所需的哪些数据，反之亦然。与将高级业务需求细化为功能需求，然后详细说明到设计规范一样，概念数据模型可以作为定义逻辑数据模型和物理数据模型的起点。

概念模型

基本概念数据模型示例

根据Merriam-Webster词典，概念描述了对事物的想法，或者其工作原理。概念数据模型说明了组织想要或需要捕获的信息。它是一个高级、面向业务的模型，捕获运营数据需求：组织需要捕获哪些数据？对这个问题的回答将识别需要探索以定义需求的数据“实体”。概念数据模型代表了企业为了支持组织或项目领域内存在的业务流程而需要的信息。

这种类型的模型非常高层次，指导应用程序数据存储的设计。它展示了需要捕获信息的“事物”或实体（名词），并指示这些识别出的“事物”之间的高级关系。该模型独立于用于实施解决方案的任何技术，不包括诸如主键或实体属性之类的细节。概念数据模型在项目的需求收集阶段最有帮助，并且在为问题域定义逻辑模型后可以丢弃。

逻辑实体关系模型

所有者-车辆逻辑数据模型

逻辑数据模型包含支持应用程序所需的实体，关于每个实体的信息（包括属性和唯一标识符），以及实体之间所需的关系。这种类型的模型可以参考概念数据模型，但识别的实体关系结构被修改以支持（在较高层次上）技术解决方案域。

依赖于RDBMS平台的应用程序通常会使用实体关系 (ER) 图格式来说明逻辑数据模型。每个不同的实体都用相关的属性定义，这样每个属性都特定于该实体，并且仅针对该实体。对模型中的数据进行规范化确保在创建物理数据模型时，数据架构设计将确保不会发生数据异常 - 也就是说，存储在数据库中的数据将具有完整性，并且用户可以依赖这些数据。

物理数据模型

物理数据模型 - 所有者-车辆表

物理数据模型为支持业务运营的数据结构提供了详细的规范。逻辑数据模型通常使用基线项目功能需求进行完成，并且被扩展和修改以符合用于存储数据的架构。这可能反映任何类型的架构 - 关系数据库或 XML 数据存储都需要这种规范。美国卫生与公众服务部将这种类型的数据模型定义为“逻辑数据模型 (LDM) 的特定于数据库的实现”。

物理数据模型包括表和列的定义（对于关系数据库）或模式和元素（对于 XML 数据库），域（属性或元素）值，物理数据类型，约束，唯一键和索引。关系及其基数，XML 扩展，特定 RDBMS 架构信息，可空性和值长度/精度是通常包含在模型中的其他定义。物理数据模型可以使用生成创建数据库所需代码的工具创建。这些工具通常还提供逆向工程数据库的功能，为现有应用程序生成物理数据模型。