DAMA数据管理知识体系指南学习心得（7）-企业数据开发（上）

本次更新继续分享企业数据治理的相关学习心得，内容源自《DAMA数据管理知识体系指南》第5章部分内容，核心关于企业数据开发的概念与部分活动。

01

数据开发简介

数据开发是指分析、设计、实施、部署及维护数据解决方案以使企业的数据资源价值最大化。

数据开发是系统开发生命周期中项目活动的子集（但系统应用时间短，数据留存时间长，两者并不同步），专注数据需求的定义、数据解决方案的设计和实施。数据解决方案中最基本的组件是数据库和其他数据结构，其他解决方案组件包括信息产品（屏幕显示、报表）以及数据访问接口

02

数据开发活动

数据开发活动发生于系统开发和维护工作的关联环境中（即系统开发生命周期），这些活动大多以项目方式进行管理。信息系统定义并交付信息以支持业务职能，数据存储和信息产品是构成每个信息系统整体所必须的组件，有效的系统开发项目需保证数据、流程、和技术三者并重

数据建模方式

目前存在多种不同的数据建模方式，每种方法会使用不同的图形样式，不同的图形样式在语法上稍有不同。其中应用最为广泛的是UML（Unified Modeling Language）统一建模语言

一些实践者认为分别给对象和数据建模没有必要，也没有价值。虽然概念对象类与概念数据模型是对等的，但是逻辑和物理的数据模型常常与逻辑和物理的面向对象程序设计有很大差别

逻辑数据模型能够规范化数据属性，但对象模型不能

对象的属性表示在程序内存中的数据，而物理模型的属性则表示数据库中存储的数据，通常是作为关系型数据库基表中的列

数据建模是一种分析和设计方法：

定义和分析数据需求

设计满足需求的数据结构

数据模型是表现数据需求和设计的规格说明书及相关图形的完整集合，其目的是为了推动：

沟通理解：为不同层次和经验的人提供理解数据的桥梁

形式化：记录数据需求和数据相关业务规则的唯一且确切的定义

范围：数据关联环境和范围

尽管对于技术和流程有明确的定义，但是让数据在很多不同的应用中可用是需要技巧的

数据模型是一个复杂的处理过程，它不能损害数据的完整性和安全性的要求，良好的数据模型能够有效地理解，并准确地表达数据需求，以保证解决方案的质量

概念数据建模包含较多的分析活动，而物理数据建模中包含更多设计活动，而逻辑数据建模则两者兼而有之，且需平衡

数据建模第一步是分析信息需求，需要在一个或多个业务流程中确认业务的信息需求，业务流程所要消费的信息可定义为输入，而输出可以定位信息产品，这些信息产品的名称往往可以确定一个必需的业务词汇，数据建模以此为依据

概念数据模型建模

概念数据模型是业务重点相关的主题域内可视的、高阶的视角，它仅包括给定的领域和职能中基础和关键的业务实体，以及实体间的关系描述：

定义关键业务词汇的语义

反映与业务流程和应用功能相关联的数据

不依赖技术和使用过程中的关联环境

概念模型中包含用于定义每一个对象的词汇表，包括业务术语、关系术语、实体同义词和分类

为创建一个概念数据模型，要从主题域模型的某个主题开始，先确定那些对象包含在该主题领域内，以及它们之间如何关联

实体与关系

业务实体是组织感兴趣的事物（例如一个对象或者一个事件），数据实体是指业务认为重要并值得定义的数据集合，实体是一个名词：

谁：人员、组织、角色、客户、供应商等

事物：产品、服务、资源、原材料等

时间：事件、财政周期等

哪里：位置、地址、站点、网络节点等

为什么：政策、规则等

如何：机制、工具、文档、发票等

实体是特定业务实体的实例化（例如客户实体名可以为kobe、James、KD），实体会出现在概念或者逻辑数据模型中，概念业务实体描述关于数据收集相关目标，逻辑数据实体遵循范式和抽象规则

实体可以是独立的，也可以是非独立的，独立的实体不依赖任何其他实体而存在，不会参照数据模型中的任何其他实体

数据模型中需要将基数规则和参照完整性等业务规则表达为实体间的关系

基数规则：用于定义与两个实体间关系相关的某个实体的实例数量，例如每个人可以为0到多个公司工作

参照完整性：为确保正确有效的数值所定义的规则，例如每个公司必须聘用1个或多个人员

两个实体间的关系可能有以下3种类型

一对一

一对多

多对多

逻辑数据模型建模

逻辑数据模型是数据需求和控制数据质量相关业务规则的详细描述，通常用于支持特定的应用需求，与概念数据模型一样不依赖任何技术以及具体实施中的技术限制

一个逻辑数据模型通常从概念数据模型的拓展开始，将数据属性添加到每个实体，企业应该有命名标准以指导逻辑数据对象的命名

逻辑数据模型通过应用两种技术转换概念数据模型的结构

范式化：运用规则将业务的复杂性转化为稳定的数据结构的过程

抽象化：对实体数据、元素和关系的重新定义，通过消除细节以拓展结构使之能应用到更广的范围

范式化的基本目标是保证数据元素仅在一个位置出现，范式规则根据主键和外键整理数据元素，不同层次的范式规则使用更细的粒度和规范性来搜索正确的主键和外键

TIPS:

范式包括很多层级，包括第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、BCNF、第四范式（4NF）、第五范式（5NF）、第六范式（6NF），且下层包含前面所有的层次。由于篇幅的原因，有兴趣的小伙伴可自行搜索相关内容。

虽然范式建模可以避免数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦。但层级越高的范式设计出来的表越多,可能会增加查询所需时间，因此在数据仓库的维度建模、数据集市开发中常常会出现反范式设计。另外范式建模更多的应用于关系型数据库（SQL），NOSQL数据库中数据模型大多反范式。

属性、域、键

属性是实体的一种特性，有助于确认或者描述实体实例，例如“Student Last Name”，在逻辑数据模型中，业务实体就是企业词汇表中必需的名词，而属性则代表形容词，例如概念数据元素电话号码可以分解成多个逻辑数据元素如家庭、办公室传真，以及国家代码、地区代码等

对于在任何数据模型中的业务价值来说，实体和属性的定义都非常重要：

阐明业务词汇的含义，提供严谨的业务规则管理实体关系

制定明智的商务决策及应用设计决策

属性取值的完整集合即为域，一个属性不能在其对应的域之外取值，部分域对于具体的取值定义有数量限制，或者对取值的数量有最大或最小的限制

键（或候选键）代表一个或多个属性，其取值能够唯一地确认一个实体实例（如ID），候选键中有且仅有一个可成为主键（Primary key，缩写为PK，特点唯一且不能为空）

自然键与代理键，自然键是具有业务含义的主键，例如身份证上的身份编码（前3位代表省份。第二个3位代表地区，中间为出生日期），代理键与其相反，虽然提供主键的作用（随机生成）但并不包含业务逻辑，代理键因其不与业务耦合，更易维护，因此主键更多地使用代理键

外键（Foreign key，缩写为FK）是能够将某一实体关联到其它实体的属性，简单来说，外键是当两个实体存在关联时，同时出现在这两个实体中的属性，且能部分或全部识别其中一个或两个实体

物理数据模型建模

物理数据模型可以根据技术约束、应用方法、性能需求和建模标准等优化详细的数据需求和业务规则的实施工作，企业应通过一定的命名标准来指导物理数据对象命名

物理数据模型的设计需要决定：

每个数据表及数据列（关系数据库如sqlserver、DB2、oracle）、或文件和字段（非关系型数据库，如Mongodb、Hbase、neo4j）以及模式和元素（如XML schema）的技术命名

每个列或字段的逻辑域、数据类型、长度、非空属性

每个列和字段的默认值

主键和备用唯一键及索引

参考数值集合

▼