第8章
数据架构
数据架构是企业架构（Enterprise Architecture，EA）的一部分。Zachman认为企业架构是构成组织的所有关键元素和关系的综合描述，而企业架构框架（EAF）是一个描述企业架构方法的蓝图。经过近30年的发展，企业架构理论已经相当成熟，目前，国际上影响力比较大的企业架构框架有Zachman框架、DoDAF框架、FEAF框架、TOGAF框架等。一个完整的企业架构通常被划分为业务架构、应用架构、数据架构和技术架构，如图8-1-1所示。
图8-1-1 企业架构划分
在企业架构中，业务架构描述了企业各业务之间相互作用的关系结构和贯彻企业业务战略的基本业务运作模式；数据架构将企业业务实体抽象为信息对象，将企业的业务运作模式抽象为信息对象的属性和方法，建立面向对象的企业数据模型，数据架构实现从业务模式向数据模型的转变，业务需求向信息功能的映射，企业基础数据向企业信息的抽象；应用架构以数据架构为基础，建立支撑企业业务运行的各个业务系统，通过应用系统的集成运行，实现企业信息自动化流动。
8.1 数据架构概述
依据美国电气及电子工程师协会标准IEEE/ANSI 1471/2000和国际化标准组织ISO/IEC/ IEEE 42010/2011的定义，架构是某些事物的基本组织，体现在其组成部分、它们彼此的关系、它们和环境的关系，以及它们的设计原则和演进。所以数据架构的基本组织/架构元素是：数据组件、数据组件之间的关系、数据组件和环境的关系，以及数据组件的设计原则和演进记录。
参考企业架构国际标准TOGAF（The Open Group Architecture Framework），数据组件的类型有数据实体、逻辑数据组件和物理数据组件。数据模型是数据组件、组件之间的连接关系和关系基数的图形呈现。
图8-1-2展示了TOGAF企业架构内容元模型中定义的数据实体、业务服务/流程和应用等相关架构元素的关系。
图8-1-2 企业架构内容元模型中的相关元素
数据实体是数据的封装，可被业务领域专家认知为某种事物。逻辑数据实体可绑定到应用、存储库和服务上。
逻辑数据组件是将相关数据实体封装到有边界的区域以便保留逻辑位置，例如外部采购信息。
物理数据组件用于将相关数据实体封装到有边界的区域以便保留物理位置。例如采购订单对象，由采购订单表头和采购订单项对象节点组成。
8.2 框架设计
8.2.1 数据分布
工业企业在采购、生产、销售到客户服务等过程中，无不伴随着数据的产生、流转和运用。通过有效的组织、存储、分发和管理可实现在不同业务线之间的数据共享。狭义的数据架构可以用来特指数据分布，包括数据业务分布与数据应用（系统）分布。数据业务分布指数据在业务各环节的CRUD关系；数据系统分布指单一系统中数据架构与系统各功能模块的引用关系，以及数据在多个系统间的引用关系。数据业务分布是数据系统分布的基础和驱动。
对于拥有众多分支机构的大型工业集团企业，数据是集中存放还是分散存放是数据分布设计中重要的考虑内容。从地域角度看，数据分布有数据集中存放和数据分布存放两种模式。这两种数据分布模式各有其优缺点，需要综合考虑自身需求确定具体的数据分布策略。
一般的数据分布常采用“操作型业务系统数据库+操作型数据存储库（+数据仓库）+数据集市”的方式。业界领先的实践（如数据中台）一般结合面向服务架构（SOA）、商业智能（BI）技术和数据虚拟化技术，利用数据整合平台将数据仓库中的数据转变为能被其他系统所访问的数据服务，为那些需要满足BI需求、访问数据仓库数据的系统提供访问路径。
1. 数据目录
数据目录作为数据共享交换的基础数据，对促进企业内部数据共享与交换、对外上报和公示相关信息都非常重要。
可以自动或者手动从不同信息资源中抽取数据并生成需要的数据目录。信息资源包括任何数据湖、数据仓库、数据集市、生产系统数据库，以及其他被确定为有价值、可共享的数据资产实体。数据目录是数据管理、数据管控和数据治理的核心。
数据目录可以是一种图形化的数据资产管理工具，它提供了多层次的图形化展现，并具备各种力度的控制能力，满足业务使用、数据管理、开发运维不同应用场景的图形查询和辅助分析需求。
2. 数据资源全景图
数据资源全景图是企业全部数据资产的总体视图，既包括数据分布、流向和交互关系，又包括数据治理、数据服务和数据后期应用的完整视图，是企业资产管理和运营的重要基础。数据资源全景图如图8-2-1所示。
图8-2-1 数据资源全景图（示例）
3. 数据地图分布应用
数据地图分布应用是指站在数据资产全景图的视角查看企业各数据域，在每一个数据域下，可以识别企业各项业务的核心数据主题，明确各个主题间的交互关系，将数据实体分类，形成企业级数据地图。
构建企业数据地图的意义在于弄清楚企业的数据资产，未来可在此基础上明晰数据在系统和业务中的分布和流向，保证企业内部信息系统之间共享数据的一致性，亦可在此基础上开展数据建模、主数据管理、数据标准化等数据管控、治理工作。
8.2.2 数据主题域
数据主题域是最高层级的，以各个主题概念及其之间的关系为基本构成单元的数据主题集合。企业应划分统一的数据主题域，形成统一的企业数据视图，如图8-2-2所示。
图8-2-2 工业企业数据分布（示例）
1. 战略发展类主题
战略发展类主题主要涵盖以下主题。
“战略规划”主题：包括战略规划编制信息、规划执行信息、股本结构信息、债权人信息、股权人员信息、高管人员信息。
“计划与预算管理”主题：包括计划编制维度、计划编制信息、计划执行信息、计划考核信息、预算科目、预算编制信息、预算目标、预算执行信息、预算考评信息。
“投资管理”主题：包括投资需求、投资执行信息、投资方案、投资评估、市场兼并收购信息、投资后评估信息。
“绩效管理”主题：包括企业绩效目标、考核标准、考核指标、考核结果。
2. 管理支持类主题
管理支持类主题主要涵盖以下主题。
“财务管理”主题：包括会计凭证、会计科目、金融机构、应付账款、应收账款、固定资产、内部订单、成本费用信息、财务三大报表。
“人力资源管理”主题：包括组织机构信息、岗位信息、员工信息、薪酬福利信息、招聘信息、员工考勤信息、培训课程信息、职业生涯规划信息、员工绩效考评信息。
“物资管理”主题：包括采购计划、采购方案、寻源文件、采购订单、采购合同、出入库单、物资领料单、物资调拨单、配送计划信息、物资配送信息、承运商信息、配送监控信息、合同监造信息、到货接收单。
“项目管理”主题：包括项目基本信息、项目科研信息、项目计划信息、项目进度信息、项目施工信息、项目成本信息、项目安全质量信息、项目效益评估信息、项目概预结算信息。
“内控审计管理”主题：包括风险评估标准、风险事件库、风险评估报告、审计信息、审计项目、控制活动、专项检查信息。
3. 生产执行类主题
生产执行类主题主要涵盖以下主题。
“生产管理”主题：包括生产年度/月度计划、日排产计划、生产工单、作业指令、物料消耗信息、生产成本信息、产品化验结果等。
“生产调度管理”主题：包括生产调度计划、调度标准指令集、标准问题集、调度指令下达信息、调度问题、调度日志、应急事件。
“HSE管理”主题：包括风险/隐患信息、事故/事件信息、安全检查计划、安全检查记录、应急预案、应急物资与装备、职业病记录，污染源检测信息、节能减排计划、节能减排量。
“科技与工艺管理”主题：包括生产技术标准、工艺专利信息、科技项目信息。
“设备管理”主题：包括设备台账信息、设备功能位置、设备配套计划、设备采购计划、设备领用记录、设备维修计划、故障类型、设备维修记录、设备资产折旧信息。
8.2.3 数据关联关系
1. 基本概念
（1）实体。
实体是一个系统内可定义的事物或概念，如人/角色（例如学生）、对象（例如发票）、概念（例如简介）或事件（例如交易）（注：在实体关系图中，“实体”通常用来代替“表”，但它们是一样的）。在考虑实体时，可以尝试把它们想成名词。在ER实体关系模型中，实体显示为圆角矩形，其名称位于上方，其属性列在实体形状的主体中。图8-2-3为ERD（实体关系图）中实体的一个用例。
图8-2-3 一个实体用例
（2）属性。
属性也被称为列（Row），意思是持有它的实体的属性或特性。
一个属性有一个描述属性的名称和一个描述属性种类的类型，例如代表字符串的varchar，代表整数的int。当为物理数据库开发绘制ERD时，应使用目标RDBMS支持的类型，以确保设计和物理数据库一致。
图8-2-4中的ERD示例显示了一个包含属性的实体。
图8-2-4 一个包含属性的实体
（3）主键。
主键（Primary Key，PK），是一种特殊的实体属性，用于界定数据库表中的记录的独特性。一张表中不能只有一个主键属性值的记录，证明身份的ID便是典型的例子。两个人即使姓名相同，ID也不会一样，若身份证明是一张表，那么ID便是主键了。图8-2-5中的ERD示例显示了拥有主键属性“ID”的实体“Product”，以及数据库中表记录的预览。第三个记录是无效的，因为ID“PDT-0002”的值已被另一个记录使用。
图8-2-5 主键（ERD）
（4）外键。
外键（Foreign Key，FK），是对主键的引用，用于识别实体之间的关系。请注意，有别于主键，外键不必是唯一的，多个记录可以共享相同的值。图8-2-6中的ERD示例包含一系列的实体，其中一个外键用于引用另一个实体。
图8-2-6 外键（ERD）
（5）关系。
两个实体之间的关系表示这两个实体以某种方式相互关联。例如，学生可能参加课程，因此实体“学生”与“课程”相关，而这一关系在ERD中则以连接线表示。
（6）基数。
基数定义了在一个实体与另一个实体的关系里，某方可能出现的次数。例如，一个团队有许多球员，若把这一关系呈现于ERD中，那么团队和球员之间是一对多的关系。
2. 三种关系
在ERD中，三种常见的主要关系是一对一、一对多和多对多。
（1）一对一。
一对一关系主要用于将实体分成两部分，简洁地将信息呈现，使读者更容易理解。图8-2-7显示了一对一关系的例子。
图8-2-7 一对一关系
（2）一对多。
一对多关系是指两个实体X和Y之间的关系，其中X的一个实例可以连接Y的许多实例，而Y的一个实例仅可以连接X的一个实例。图8-2-8显示了一对多关系的一个例子。
图8-2-8 一对多关系
（3）多对多。
多对多关系是指两个实体X和Y之间的关系，其中X可以连接Y的许多实例，反之亦然。图8-2-9显示了一个多对多关系的例子。请注意，多对多关系在物理ERD中被定义为一对一对多的关系。
图8-2-9 多对多关系
2. 数据血缘关系
数据血缘关系是指数据从产生、处理、流转到消亡过程中，数据之间形成的一种类似于人类社会血缘关系的关系。和人类社会血缘关系不同的是，同一个数据可以有多个来源（多个“父亲”）。一个数据可以是多个数据经过加工而生成的，而且这种加工过程可以有多个。
（1）表级血缘关系。
针对表结构的情况，最终用户和运维用户最需要关注目标表中每个字段的数据的来源有哪些。即建立源表、源字段与目标表、目标字段的映射关系。一个目标表可以对应多个来源表的字段，比如：姓名字段，可能来自户籍人口表，也可能来自流动人口表，也就意味着这两张表合并起来的人口，才是这个区域的所有人口。
（2）字段级血缘关系。
从当前记录出发，可以按时间查看该记录所有的变更过程。一条记录的生成可能对应两个表的两条记录，这种对应是可跟踪的。
如果再精细跟踪，就可以做到字段级血缘分析，可以与表结构的血缘分析完美呼应。单击某一个字段，可查看该字段的血缘关系。
3. 数据流转关系
数据流转线路表现的是数据的流转路径。数据流转线路从数据流入节点向主节点汇聚，又从主节点流出向数据流出节点扩散。
数据流转线路表现了三个维度的信息，分别是方向、数据更新量级、数据更新频次。方向默认从左到右流转；数据更新量级通过线条的粗细来表现——线条越粗则表示数据量级越大，线条越细则表示数据量级越小；数据更新频次用线条中线段的长度来表现，线段越短则表示更新频次越少，线段越长则表示更新频次越多，一根实线则表示只流转一次。
数据流转通过系统间的接口进行交换和传输。图8-2-10是比较典型的企业数据流转架构，其中业务系统中的数据由统一数据交换平台流转分发给传统关系型数据库和非关系型大数据平台，数据仓库和大数据平台汇总这些数据后，供各个应用集市分析使用。
图8-2-10 企业数据流转架构
8.3 数据建模
数据模型是一种工具，用来描述数据、数据的语义、数据之间的关系，以及数据的约束等。实体关系图经常被用来描述现实世界中的数据模型。当我们理解了实际问题的需求之后，需要用一种方法来表示这种需求，数据模型就是用来描述这种需求的。
数据模型依据抽象层次可分类为概念数据模型、逻辑数据模型和物理数据模型。概念数据模型和逻辑数据模型是需求分析的产出，而物理数据模型是设计活动的产出。数据模型是呈现数据需求、分析和设计的规格说明书。
数据模型中常见的术语如下。
（1）实体（Entity）：现实世界中的对象，可以具体到人、事、物。就一般企业而言，实体是业务专家认知的某种事物，如采购订单、产品、服务、客户等。
（2）属性（Attribute）：实体所具有的特性。属性用来描述实体，是组成实体的数据定义、格式和值域，如采购订单编号、产品编号、客户电话等。
（3）键属性（Key Attribute）：可唯一识别数据实体实例（Instance）和数据库表行记录的属性，如客户编号可识别不同客户。每个实体一般都有主键（Primary Key）属性，也可能有外键（Foreign Key）属性。
（4）关系（Relationship）：实体和实体之间的关系。可通过连线（Connection）表示，关系可帮助辨识主键和外键。
（5）范式（Normal Form）：规范实体中属性之间的依赖和分解关系，如第一范式（1st NF）强调的是属性的原子性，即属性不能够再被分解成其他属性。
图8-3-1是信息工程数据建模中常用的图形符号。
图8-3-1 信息工程数据建模中常用的图形符号
在设计数据库时，一般都要求能符合第三范式（3rd Normal Form，3NF）。第三范式必须是第二范式（2nd Normal Form，2NF），所有非主键属性必须能直接依赖于主键，而且其他属性间不能存在传递依赖关系。
第二范式必须是第一范式，此外，还需满足两个条件：
（1）实体/表必须有一个主键；
（2）没有包含在主键中的属性必须完全依赖主键，而不能只依赖主键的一部分。
符合第三范式可保证数据的完整性和一致性，这是数据质量的最低要求。在特殊情况下（例如为了提高系统性能），允许不符合第三范式，但是数据的完整性和一致性需要通过特殊控制来保证。
8.3.1 概念数据模型
高阶的概念数据模型可以是数据实体和主题领域的目录清单及组成关系。图8-3-2描述了产品主题域、采购主题域、库存主题域，以及各主题域包含的数据实体。
图8-3-2 概念数据模型
在概念层次，主要工作是发现核心流程（产生客户价值的流程）使用的数据实体（人、事、物），将它们以清单的方式列出，并分组到对应的主题域。
8.3.2 逻辑数据模型
从概念数据模型中选取与采购订单实体相关的产品及其库存和位置，分析每个实体的属性、主键和外键，可以得到简化的逻辑数据模型。图8-3-3中未列出所有的实体属性，如采购时间、订单状态、到货时间、交货地点、财务信息等。
图8-3-3 逻辑数据模型
逻辑数据模型在转换为物理数据模型时，必须解决实体之间的多对多关系，常用的方法就是将多对多关系转换成关联型实体（Associative Entity）。例如将图8-3-3中的采购订单和产品之间的多对多关系转换为“采购订单×产品”实体和两个一对多关系，范例如图8-3-4所示。
图8-3-4 优化的逻辑数据模型
实体“采购订单×产品”是采购订单录入流程的主要数据源，实体“产品×供应商”是产品供应流程的数据源，实体“产品×需求”是产品开发流程的数据源，而实体“客户×需求”是客户需求分析流程的数据源。
8.3.3 物理数据模型
物理数据模型也可以用统一建模语言（UML）的类图表示，需要将逻辑数据模型中的属性细化，如库存位置编号可分解为通道（Aisle）、货架（Shelf）、层（Level）、容器（Bin）等。
逻辑数据模型的采购订单为了符合第三范式，需要被分解为两个实体——采购订单表头和采购订单细项。
对于图8-3-5中的物理数据模型，市场上的许多数据建模工具都可生成这样的模型：例如用SQL的数据定义语言（Data Definition Language，DDL）建立数据库，来支持应用系统的开发。在产生SQL数据定义语言之前，需要先定义属性/字段的详细信息。例如“产品编号”的数据类型是字符，长度是10，需要将CHAR()修改为CHAR(10)。
图8-3-5 物理数据模型
8.3.4 数据模型开发方法
数据模型开发方法取材于TOGAF（The Open Group Architecture Framework，开放组体系结构框架）的架构开发方法（Architecture Development Method，ADM），它一共有10个阶段，如图8-3-6所示。
图8-3-6 数据模型开发方法
架构开发方法是一个在全球被广泛使用和证明的方法论，它的特色是迭代和循环，专门用来处理业务需求。
预备阶段进行准备工作：确定受影响的组织范围，发现架构工作需求，确认治理和支持框架，建立架构组织、识别架构原则，调整TOGAF框架，以及制订工具与技术的实施战略和计划。
架构开发阶段包含：
阶段A——架构愿景；
阶段B——业务架构；
阶段C——信息系统架构（数据架构和应用架构）；
阶段D——技术架构，代表了完整的企业架构开发。
阶段E——依据架构蓝图开发解决方案（架构实施项目）；
阶段F——迁移规划的工作内容；
阶段G——架构开发和解决方案的实施治理；
阶段H——架构变更管理只覆盖架构变更管理，不包含一般的变更管理。
阶段A到阶段H都必须依据需求开发，开发完成后需要验证，当需求能被满足后才能通过评审和验收。
阶段C包含了数据架构和应用架构的开发，可从任意一个架构开始。建议先从数据架构的开发开始，再进行应用架构的开发。利用数据模型的开发方法可以定制阶段C的数据架构的开发方法，主要包括如下9大步骤。
（1）选择参考数据模型、数据视图和工具；
（2）梳理当前数据模型，作为基线；
（3）定义未来数据模型，作为目标；
（4）进行基线和目标数据模型的差距分析；
（5）消除差距，定义数据模型发展路线图及需要的数据组件；
（6）解决跨架构景观的影响；
（7）引导正式的利益相关者审查；
（8）定稿数据模型；
（9）创建数据模型文件。
数据架构的输入包括：
（1）架构工作请求书；
（2）能力评估；
（3）沟通计划；
（4）企业和数据架构组织模型；
（5）已裁剪的企业和数据架构框架；
（6）数据架构原则；
（7）架构工作说明书；
（8）架构愿景；
（9）架构存储库；
（10）架构定义文件初稿（含业务架构）；
（11）架构需求规格初稿，其中包括差距分析结果和相关技术需求；
（12）架构路线图的业务架构组件。
数据架构的输出包括：
（1）架构工作说明书（Statement Of Work，SOW）；
（2）经验证的数据架构原则或新的数据架构原则；
（3）架构定义文件初稿（含业务架构与数据架构）；
（4）架构需求规格初稿；
（5）架构路线图的数据架构组件。
架构定义文件输出物包含数据架构组件，内容如下：
（1）基线数据架构（当前的实际情况）。
（2）目标数据架构，其中包括：
①业务/概念数据模型；
②逻辑数据模型；
③数据管理流程模型；
④数据实体/业务功能矩阵。
（3）与选定视点对应的数据架构视图（针对关键利益相关者的关注）。
架构需求规格输出物包含数据架构组件，内容如下：
（1）差距分析结果；
（2）数据互操作性需求；
（3）为了与架构变更保持一致，业务架构可能需要改变的地方；
（4）对即将设计的技术架构存在的约束；
（5）最新的业务/应用/数据需求（如果符合实际情况）。
数据架构阶段中常用的模型/视图如下：
（1）数据实体/数据组件目录；
（2）数据实体/业务功能矩阵；
（3）应用/数据矩阵；
（4）概念数据图；
（5）逻辑数据图；
（6）数据传播图；
（7）数据安全图；
（8）数据迁移图；
（9）数据生命周期图。
本章精要
数据架构便于企业运营决策者以数据视角分析整个企业的数据分布与业务域之间的关系，是企业了解自身价值和制定战略决策的最重要依据。数据架构从跨业务、跨级层、跨应用系统的视角统一对数据进行组织和规划，提高数据集中存储和跨系统间数据共享的效率。
数据架构设计可满足企业信息化各层级要求：一是经营管理更加集中，实现业务集约化管理；二是业务更加融合，按照业务主线深度集成所有业务流程，实现企业整体资源共享与业务协作；三是决策更加智能，实现经营决策智能分析、管理控制智能处理、业务操作智能作业，深化数据分析利用能力，提高管理决策支撑能力。