读DAMA数据管理知识体系指南09数据建模（上）

1.       数据建模

1.1.         数据建模是发现、分析和确定数据需求的过程，用一种称为数据模型的精确形式表示和传递这些数据需求

1.2.         数据建模是数据管理的一个重要组成部分

1.3.         建模过程中要求组织发现并记录数据组合的方式

1.4.         数据模型有助于组织能够理解其数据资产

1.5.         最为常见的6种模式

• 1.5.1.           关系模式

• 1.5.2.           多维模式

• 1.5.3.           面向对象模式

• 1.5.4.           事实模式

• 1.5.5.           时间序列模式

• 1.5.6.           NoSQL模式

1.6.         每种模式又可以分为3层模型

• 1.6.1.           概念模型

• 1.6.2.           逻辑模型

• 1.6.3.           物理模型

1.7.         每种模型都包含一系列组件，如实体、关系、事实、键和属性

1.8.         一旦建立了模型，就需要对其进行质量审查

1.9.         一旦得到批准，后续还需要对其进行维护

2.       有效的数据管理

2.1.         提供有关数据的通用词汇表

2.2.         获取、记录组织内数据和系统的详细信息

2.3.         在项目中作为主要的交流沟通工具

2.4.         提供了应用定制、整合，甚至替换的起点

3.       目标和原则

3.1.         目标是确认和记录不同视角对数据需求的理解，从而使应用程序与当前和未来的业务需求更加紧密地结合在一起，并为成功地完成广泛的数据应用和管理活动奠定基础，如主数据管理和数据治理计划

3.2.         良好的数据建模会降低支持成本，增加未来需求重复利用的可能性，从而降低构建新应用的成本

3.3.         数据模型是元数据的一种重要形式

3.4.         确认和记录不同视角的理解有助于

• 3.4.1.           格式化

  • 3.4.1.1.            数据模型是对数据结构和数据关系的简洁定义

  • 3.4.1.2.            格式化的定义赋予数据规范的结构，减少在访问和保存数据时发生异常的概率

  • 3.4.1.3.            通过展现数据中的结构和关系，数据模型使数据更容易被使用

• 3.4.2.           范围定义

  • 3.4.2.1.            数据模型可以帮助解释数据上下文的边界，以及购买的应用程序包、项目、方案或实施的现有系统

• 3.4.3.           知识保留记录

  • 3.4.3.1.            数据模型通过以书面的形式获取知识来保存系统或项目的企业信息

  • 3.4.3.2.            给未来项目提供原始记录

  • 3.4.3.3.            数据模型有助于更好地理解一个组织、一个业务方向、一个已存在的应用，也有助于理解修改现有数据结构所带来的影响

  • 3.4.3.4.            数据模型可被重复利用，可以帮助业务专业人员、项目经理、分析师、建模师和开发人员了解环境中的数据结构

  • 3.4.3.5.            建模师帮助他人理解信息蓝图

4.       数据建模和数据模型

4.1.         数据建模最常用在系统开发与系统维护的工作环境中，也称为系统开发生命周期(SDLC)

4.2.         数据建模可以用于更广泛的领域（如业务和数据架构、主数据管理和数据治理计划）​，其直接的结果不是在数据库，而是对组织数据的理解

4.3.         模型是现实中事物的一种表征或者想要创造事物的一种模式

• 4.3.1.           一个模型可以包含一个或多个图表

• 4.3.2.           模型图可以使人们通过标准化的符号快速领会其内容

• 4.3.3.           地图、组织架构图和建筑蓝图都是日常模型的例子

4.4.         数据模型描述了组织已经理解或者未来需要的数据

• 4.4.1.           数据模型包含一组带有文本标签的符号，这些符号试图以可视化方式展现数据需求并将其传递给数据建模人员，以获得一组特别的数据

4.5.         模型是一种文档形式，用于记录数据需求和建模过程产生的数据定义

4.6.         数据模型是用来将数据需求从业务传递到IT，以及在IT内部从分析师、建模师和架构师到数据库设计人员和开发人员的主要媒介

5.       建模的数据类型

5.1.         在任何既定组织中适合于建模的数据类型反映了组织或项目需要数据模型的优先级

5.2.         静态数据

• 5.2.1.           类别信息(Category Information)

  • 5.2.1.1.            用于对事物进行分类和分配事物类型的数据

• 5.2.2.           资源信息(Resource Information)

  • 5.2.2.1.            实施操作流程所需资源的基本数据

  • 5.2.2.2.            资源实体有时被称为参考数据

• 5.2.3.           业务事件信息(Business Event Information)

  • 5.2.3.1.            在操作过程中创建的数据

  • 5.2.3.2.            事件实体有时被称为交易性业务数据

• 5.2.4.           详细交易信息(Detail Transaction Information)

  • 5.2.4.1.            详细的交易信息通常通过销售系统（商店或在线应用）生成

  • 5.2.4.2.            还可以通过社交媒体系统、其他互联网交互（单〈双〉击流等）和机器上的传感器产生

    5.2.4.2.1.             传感器可以是船只和车辆的部件、工业组件或个人设备（全球定位系统、射频识别、无线等）​

  • 5.2.4.3.            这种类型的详细信息可以被聚合，用于派生其他数据，并用以分析趋势，类似于业务时间信息的使用方式

  • 5.2.4.4.            这种类型的数据（大容量或快速变化）通常被称为大数据

5.3.         部分“动态数据”也可以建模

• 5.3.1.           系统的方案，包括用于消息传递和基于事件的系统的协议和方案等

6.       实体

6.1.         实体(Entity)的定义是有别于其他事物的一个事物

• 6.1.1.           实体是一个组织收集信息的载体

• 6.1.2.           实体有时被称为组织的一组名词。一个实体可以被认为是一些基本问题的答案——谁、什么、何时、何地、为什么、怎么办或这些问题的综合

6.2.         实体的别名

• 6.2.1.           通用术语“实体”可以使用其他名称表示

• 6.2.2.           最常见的是使用“实体类型”代表一类事物

• 6.2.3.           实体实例是特定实体的具体化或取值

• 6.2.4.           实体别名会根据模型类型(Scheme)而变化

  • 6.2.4.1.            在关系模型中经常用到“实体”这个术语

  • 6.2.4.2.            在维度模型中经常使用“维度”和“事实表”等术语

  • 6.2.4.3.            在面向对象模型中经常使用“类”或“对象”等术语

  • 6.2.4.4.            在基于时间模型中经常使用“中心”​“卫星”​“链接”等术语

  • 6.2.4.5.            在非关系型数据库模型中经常使用“文件”或“节点”等术语

• 6.2.5.           实体别名(Entity Aliases)也会根据模型抽象程度不同而有所不同

  • 6.2.5.1.            概念模型中的实体一般被称为概念(Concept)或术语(Term)

  • 6.2.5.2.            逻辑模型中的实体被称为实体(Entity)（其他称呼取决于不同模型类型）​

  • 6.2.5.3.            在物理模型中，实体的称呼根据数据库技术的不同也不一样，最常见的称呼是表(Table)

6.3.         实体的图形表示

• 6.3.1.           通常采用矩形（或带有圆边的矩形）代表实体，矩形的中间是实体的名称

6.4.         实体的定义

• 6.4.1.           实体的定义对于任何数据模型所描述的业务价值都有巨大贡献

• 6.4.2.           属于核心元数据

• 6.4.3.           高质量的定义澄清了业务词汇表的含义，并有助于精确管理实体之间关系所描述的业务规则

  • 6.4.3.1.            帮助业务和IT专业人员针对业务和应用程序设计做出明确的决策

• 6.4.4.           高质量的数据定义的特征

  • 6.4.4.1.            清晰(Clarity)

    6.4.4.1.1.             定义应该易于阅读和理解，采用简单清晰的语言表述，没有晦涩的首字母缩写词或难于解释的歧义术语表达

  • 6.4.4.2.            准确(Accuracy)

    6.4.4.2.1.             定义是对实体的精准和正确的描述，应由相关业务领域的专家进行审查，以确保其准确性

  • 6.4.4.3.            完整(Completeness)

    6.4.4.3.1.             定义要尽量全面，所包括的内容都要体现

    6.4.4.3.2.             在定义标识符时，标识符的唯一性范围应包括在定义中说明

7.       关系

7.1.         关系(Relationship)是实体之间的关联

7.2.         关系捕获概念实体之间的高级别交互、逻辑实体之间的详细交互以及物理实体之间的约束

7.3.         关系的别名

• 7.3.1.           通用术语“关系”也可以用其他名称来表示

• 7.3.2.           关系的别名(Relationship Aliases)根据模型不同而变化

  • 7.3.2.1.            在关系模型中经常使用术语“关系”​

  • 7.3.2.2.            在维度模型中经常使用术语“导航路径”​

  • 7.3.2.3.            在NoSQL非关系型数据库模型中经常使用诸如“边界”或“链接”等术语

• 7.3.3.           关系别名也可以根据模型抽象程度而有所不同

  • 7.3.3.1.            在概念和逻辑级别上的关系就被称为“关系”​，

  • 7.3.3.2.            在物理级别上的关系可能会采用其他名称表示，如“约束”或“引用”等

    7.3.3.2.1.             主要取决于具体的数据库技术

7.4.         关系的图形表示

• 7.4.1.           关系在数据建模图上通常显示为线条

• 7.4.2.           关系通过关系数据库中的外键来表示，在非关系型数据库中通过边界或链接来表示

7.5.         关系的基数

• 7.5.1.           在两个实体之间的关系中，基数(Cardinality)说明了一个实体（实体实例）和其他实体参与建立关系的数量

• 7.5.2.           基数由出现在关系线两端的符号表示

  • 7.5.2.1.            对于关系，如果没有基数，那么人们最多只能说两个实体以某种方式相连

  • 7.5.2.2.            对于基数而言，只能选择0、1或多（​“多”的意思是超过“1”个）​

• 7.5.3.           数据规则是通过基数指定来强制执行的

7.6.         关系中涉及实体的数目被称为关系的元数(Arity)，最常见的有一元关系、二元关系以及三元关系

• 7.6.1.           一元关系(Unary Relationship)也被称为递归关系(Recursive Relationship)或自我引用关系(Self-referencin

Relationship)

• 7.6.1.1.            只包含一个实体。一对多的递归关系描述了一种层级关系，而多对多的关系描述的是一种网络或图表

• 7.6.1.2.            在层级关系中，一个实体最多拥有一个父实体（或称上级实体）​

• 7.6.1.3.            在关系模型中，子实体处于关系中的“多”的一边，而父实体处于关系中的“一”的一边

• 7.6.1.4.            在关系网络中，一个实体可以拥有多个父实体

• 7.6.2.           涉及两个实体的关系被称为二元关系(Binary Relationship)

  • 7.6.2.1.            在二元关系的传统数据模型中，最常见的二元关系包含两个实体

• 7.6.3.           及三个实体的关系被称为三元关系(Ternary Relationship)

7.7.         外键

• 7.7.1.           通常用在物理数据建模中表示关系，在逻辑数据建模中，有时也用这种方法表示关系

• 7.7.2.           当在两个实体之间定义关系时，可以隐式地创建外键，这取决于数据库技术或数据建模工具，以及所涉及的两个实体是否具有相互依赖性

• 7.7.3.           外键体现在关系中的“多”的一边的实体，即子实体中

8.       属性

8.1.         属性(Attribute)是一种定义、描述或度量实体某方面的性质

• 8.1.1.           属性可能包含域

8.2.         实体中属性的物理展现为表、视图、文档、图形或文件中的列、字段、标记或节点等

8.3.         属性的图形表示

• 8.3.1.           在数据模型中，属性通常在实体矩形内的列表中描述

8.4.         标识符

• 8.4.1.           标识符(Identifiers)也称为键，是唯一标识实体实例的一个或多个属性的集合

• 8.4.2.           键的结构类型

  • 8.4.2.1.            单一键(Simple Key)是唯一标识实体实例的一个属性

• 8.4.2.2.            代理键也是一种单一键

  8.4.2.2.1.             代理键是表的唯一标识符，通常是一个计数符，由系统自动生成

  8.4.2.2.2.             代理键是一个整数，其含义与其数值无关

  8.4.2.2.3.             代理键具有技术功能，不应对数据库的最终用户可见

• 8.4.2.3.            组合键(Compound Key)是一组由两个或多个属性组成的集合，这些属性一起唯一地标识一个实体实例

• 8.4.2.4.            复合键(Composite Key)包含一个组合键和至少一个其他单一键、组合键或非键属性

• 8.4.3.           键的功能类型

  • 8.4.3.1.            超键(Super Key)是唯一标识实体实例的任何属性集

• 8.4.3.2.            候选键(Candidate Key)是标识实体实例的最小属性集合，可能包含一个或多个属性（如一个单一键或复合键）​

  8.4.3.2.1.             最小意味着候选键的任意子集都无法唯一标识实体实例

  8.4.3.2.2.             一个实体可以有多个候选键

  8.4.3.2.3.             候选键可以是业务键（有时称为自然键Natural Key）​

  >   8.4.3.2.3.1.              业务键(Business Key)是业务专业人员用于检索单个实体实例的一个或多个属性
  >   8.4.3.2.3.2.              业务键和代理键是互斥关系
  

• 8.4.3.3.            主键(Primary Key)是被选择为实体唯一标识符的候选键

  8.4.3.3.1.             即使一个实体可能包含多个候选键，但只有一个候选键能够作为一个实体的主键

• 8.4.3.4.            备用键(Alternate Key)是一个候选键，虽然也是唯一的，但没有被选作为主键

  8.4.3.4.1.             备用键可用于查找特定实体实例

  8.4.3.4.2.             通常，主键是代理键，而备用键是业务键

• 8.4.4.           标识关系与非标识关系

  • 8.4.4.1.            独立实体是指其主键仅包含只属于该实体的属性

  • 8.4.4.2.            非独立实体是指其主键至少包含一个来自其他实体的属性

    8.4.4.2.1.             非独立实体至少含有一个标识关系

  • 8.4.4.3.            在关系模式中，大多数数据建模图用矩形符号表示独立实体，非独立实体则用圆角矩形表示

  • 8.4.4.4.            标识关系是指父实体（关系图中一端实体）的主键作为外键被继承到子实体主键的一部分

  • 8.4.4.5.            在非标识关系中，父实体的主键仅被继承为子实体的非主外键属性