1.1. 在数据建模中，域(Domain)代表某一属性可被赋予的全部可能取值

1.2. 域可以用不同的方式来表达

1.3. 域提供了一种将属性特征标准化的方法

1.4. 域中所有的值都为有效的值

1.4.1. 不在域中的值被称为无效的值

1.4.2. 属性中不应当含有其指定的域以外的值

1.5. 可以用附加的规则对域进行限制，这些限制规则被称为约束

1.5.1. 规则可以涉及格式、逻辑或两者皆有

1.6. 域可以用多种不同的方式定义

1.6.1. 数据类型(Data Type)

1.6.1.1. 域中的某一属性中的数据有特定的标准类型要求

1.6.2. 数据格式(Data Format)

1.6.2.1. 使用包括模板和掩码等格式的域

1.6.2.2. 如邮政编码和电话号码以及字符的限制（仅用字母数字代码，字母数字代码和某些特殊符号等），用这些格式来定义有效值

1.6.3. 列表(List)

1.6.3.1. 允许相同数据类型的所有值在一个或多个最小值和/或最大值之间的域

1.6.3.2. 有些范围可以是开放式的

1.6.4. 基于规则(Rule-Based)

1.6.4.1. 域内的值必须符合一定的规则才能够成为有效值

1.6.4.2. 规则包括将关系或组合中的值与计算值或其他属性值进行对比

2.1. 关系建模

2.1.1. 关系理论首先由Edward Codd博士在1970年提出

2.1.1.1. 在关系建模方法中，三层模型仅适用于关系型数据库，而概念模型和逻辑型模型可适用于其他数据库

2.1.1.1.1. 基于事实的建模方法与此类似

2.1.1.2. 集合理论

2.1.2. 关系模型设计的目的是精确地表达业务数据，消除冗余

2.1.2.1. 在减少数据存储冗余方面卓有成效

2.1.3. 关系模型特别适合设计操作型的系统，因为这类系统需要快速输入信息并精确地存储信息

2.1.3.1. 操作型系统支持事务的处理，为优化单个事务快速处理而生

2.1.4. 信息工程法IE、信息建模的集成定义IDEF1X、巴克表示法(Barker)和陈氏表示法(Chen)

2.1.4.1. 最常见的是信息工程法，该方法采用三叉线（俗称“鸭掌模型”）来表示基数

2.1.5. 在关系模型中，关系连线表示业务规则

2.2. 维度建模

2.2.1. 维度建模(Dimensional)的概念起源于20世纪60年代，由Gerneral Mills和达特茅斯学院(Dartmouth College)在一次联合研究项目中提出

2.2.1.1. 在维度模型中，数据组织的方式是为了优化海量数据的查询和分析

2.2.1.2. 在维度模型中，实体之间的连线表示用于说明业务问题的导航路径

2.2.1.3. 维度数据模型专注于特定业务流程的业务问题

2.2.2. 对于维度建模方法，三层模型仅适用于关系型数据库和多维数据库

2.2.3. 在维度模型中，事实表(Fact Tables)的行对应于特定的数值型度量值

2.2.3.1. 金额、交易量或个数等

2.2.3.2. 有些度量值是算法的结果，在这种情况下，元数据对于正确理解和使用至关重要

2.2.3.3. 事实表占据了数据库的大部分空间（90%是一个合理的经验法则），并且往往具有大量的行

2.2.4. 维度表

2.2.4.1. 维度表(Dimension Tables)表示业务的重要对象，并且主要包含文字描述

2.2.4.2. 维度是事实表的入口点或链接，充当“查询”或“报表”约束的主要来源

2.2.4.3. 维度通常是高度反范式的，通常占总数据的10%左右

2.2.4.4. 3种主要的变化类型

2.2.4.4.1. 第一类，覆盖(Overwrite)

2.2.4.4.1.1. 新值覆盖旧值

2.2.4.4.2. 第二类，新行(New Row)

2.2.4.4.2.1. 新值写在新行中，旧行被标记为非当前值

2.2.4.4.3. 第三类，新列(New Column)

2.2.4.4.3.1. 一个值的多个实例列在同一行的不同列中，而一个新值意味着将系列中的值向下一点写入，以便在前面为新值留出空间

2.2.4.4.3.2. 最后一个值被丢弃

2.2.5. 雪花模型(Snowflaking)的含义是将星型模式中的平面、单表、维度结构规范为相应的组件层次结构或网络结构

2.2.6. 粒度(Grain)这一概念是指事实表中的单行数据的含义或者描述，这是每行都有的最详细信息

2.2.6.1. 定义一个事实表中的粒度是维度建模的关键步骤之一

2.2.7. 一致性维度(Conformed Dimensions)是基于整个组织考虑构建的，而不是基于某个特定的项目

2.2.8. 一致性事实(Conformed Facts)使用跨多个数据集市的标准化术语

2.3. 面向对象建模

2.3.1. 面向对象的建模方法仅适用于关系型数据库和对象数据库

2.3.2. 统一建模语言(UML)是一种图形风格的建模语言

2.3.2.1. UML根据数据库的不同有着不同种类的表示法（类模型）

2.3.3. 每个类包含有相关的操作或方法（也称为“类行为”）

2.3.3.1. 由于类行为需要排序和计时，其只是松散地连接到业务逻辑中

2.4. 基于事实建模

2.4.1. 基于事实的建模(Fact-Based Modeling, FBM)方法起源于20世纪70年代末，是一种概念建模语言

2.4.2. 这类语言通常基于Fact-Based Modeling对象的特征，以及每个对象在每个事实中所扮演的角色来描述世界

2.4.3. 对象角色建模（Object Role Modeling, ORM或ORM2）是一种模型驱动的工程方法

2.4.3.1. 以典型的需求信息或查询的实例开始，这些实例在用户熟悉的外部环境中呈现，然后在概念层次上用受控自然语言所表达的简单事实来描述这些实例

2.4.3.2. 受控自然语言是受限制的无歧义的自然语言版本，因此所表达的语义很容易被人理解

2.4.4. 完全面向通信的建模(Fully Communication Oriented Modeling,FCO-IM)在注释和方法上与ORM相似

2.5. 基于时间建模

2.5.1. 基于时间的建模方法属于物理数据建模技术，主要用于关系型数据库环境中的数据仓库

2.5.2. 当数据值必须按照时间顺序与特定时间值相关联时，需要用到基于时间的建模(Time-Based)

2.5.3. 数据拱顶(Data Vault)是一组支持一个或多个业务功能领域，面向细节、基于时间且唯一链接的规范化表

2.5.3.1. 数据拱顶模型是一种混合方式，综合了第三范式和星型模式的优点

2.5.3.2. 数据拱顶模型专门为满足企业数据仓库的需求而设计的

2.5.3.3. 数据拱顶模型有3种类型的实体：中心表、链接表和卫星表

2.5.3.4. 数据拱顶模型设计的重点是业务的功能领域，中心表代表业务主键，链接表定义了中心表之间的事务集成，卫星表定义了中心表主键的语境信息

2.5.4. 锚模型(Anchor Model)适合信息的结构和内容都随时间发生变化的情况

2.5.4.1. 提供用于概念建模的图形语言，能够扩展处理临时数据

2.5.4.2. 锚建模(Anchor Modeling)有4个基本的建模概念：锚、属性、连接、节点

2.5.4.3. 锚模拟的是实体和事件，属性模拟了锚的特征，连接表示了锚之间的关系，节点用来模拟共享的属性

2.6. 非关系型建模

2.6.1. 非关系型数据库(NoSQL)是基于非关系技术构建的数据库的统称

2.6.2. No SQL方法严重依赖于底层数据库结构（文档、列、图或键值），因此也属于物理数据建模技术

2.6.3. 文档数据库

2.6.3.1. 文档数据库(Document Databases)通常将业务主题存储在一个称为文档的(Document)结构中，而不是将其分解为多个关系结构

2.6.4. 键值数据库

2.6.4.1. 键值数据库(Key-value Databases)只在两列中存储数据（键和值），其特性是可以在值列同时存储简单（如日期、数字、代码）和复杂（未格式化的文本、视频、音乐、文档、照片）的信息

2.6.5. 列数据库

2.6.5.1. 在4种类型的NoSQL数据库中，列数据库(Column-oriented Databases)最接近关系型数据库

2.6.5.1.1. 两者都有类似的方法，即将数据视为行和值

2.6.5.1.2. 不同的是，关系型数据库使用预定义的结构和简单的数据类型

2.6.5.2. 列数据库，如Cassandra，可以使用更复杂的数据类型，包括未格式化的文本和图像

2.6.5.3. 列数据库将每个列存储在自己的结构中

2.6.6. 图数据库

2.6.6.1. 图数据库(Graph Databases)是为那些使用一组节点就可以很好地表示它们之间的关系的数据而设计的，这些节点之间的连接数不确定

2.6.6.2. 图数据库最适用的例子是社交关系（节点是人）、交通网络（节点可以是公共汽车或火车站）或路径图（节点可以是街道十字路口或高速公路出口）

2.6.6.3. 图数据库最大的功能是在图中寻找最短路径或者最近的邻居，这些功能在传统的关系型数据库中实现是极其复杂的

2.6.6.4. 常见的图数据库包括Neo4 J、Allegro和Virtuoso等

3.1. 概念模式(Conceptual)

3.1.1. 概念模式体现了正在数据库中建模企业的“真实世界”视图，代表了企业当前的“最佳模式”或“经营方式”

3.2. 外模式(External)

3.2.1. 是数据库管理系统的各个用户操作与特定需求相关企业模型的子集

3.3. 内模式(Internal)

3.3.1. 数据的“机器视图”由内模式描述

3.3.2. 该模式描述了企业信息的存储表示形式

3.4. 3个层次通常分别在概念层次、逻辑层次和物理层次上进行细节展现

3.5. 在项目中，概念数据建模和逻辑数据建模是需求规划和分析活动的一部分，而物理数据建模属于设计活动

3.6. 概念数据模型

3.6.1. 概念数据模型(Conceptual Data Model, CDM)是用一系列相关主题域的集合来描述概要数据需求

3.6.2. 概念数据模型仅包括给定的领域和职能中基础和关键的业务实体，同时也给出实体和实体之间关系的描述

3.6.3. 关系线获取了关系数据模型中的业务规则

3.7. 逻辑数据模型

3.7.1. 逻辑数据模型(Logical Data Model, LDM)是对数据需求的详细描述，通常用于支持特定用法的语境中（如应用需求）

3.7.2. 逻辑数据模型不受任何技术或特定实施条件的约束

3.7.3. 逻辑数据模型通常是从概念数据模型扩展而来

3.7.4. 在关系逻辑数据模型中，通过添加属性来扩展概念数据模型

3.7.4.1. 属性通过应用规范化技术被分配给实体

3.7.4.2. 每个属性和它所在实体的主键之间都有非常强的关系

3.7.5. 在很多情况下，维度型逻辑数据模型是维度型概念数据模型的完全属性透视图

3.7.6. 关系型逻辑数据模型捕获业务流程的规则

3.7.7. 维度型逻辑数据模型捕获业务问题以确定业务流程的运行状况和性能

3.8. 物理数据模型

3.8.1. 物理数据模型(Physical Data Model, PDM)描述了一种详细的技术解决方案，通常以逻辑数据模型为基础，与某一类系统硬件、软件和网络工具相匹配

3.8.2. 物理数据模型与特定技术相关

3.8.3. 由于物理数据模型受实现技术约束，因此常常通过对结构进行组合（逆范式化）来提高检索性能

3.8.4. 规范模型(Canonical Model)是物理模型的一个变种，用于描述系统之间的数据移动

3.8.5. 视图(Views)是虚拟表，它提供了一种从多张包含或引用实际属性的表中查看数据的方法

3.8.6. 分区

3.8.6.1. 分区(Partitioning)是指拆分表的过程

3.8.6.2. 执行分区是为了方便存档和提高检索性能

3.8.6.3. 分区可以是垂直的（按列分组），也可以是水平的（按行分组）

3.8.6.4. 垂直分割

3.8.6.4.1. 为减少查询返回的结果集，可根据列的不同为某表创建子集

3.8.6.5. 水平分割

3.8.6.5.1. 为减少查询返回的结果集，使用某列的值作为区分创建子集表

3.8.7. 逆规范化

3.8.7.1. 逆规范化(Denormalization)是将符合范式规则的逻辑数据模型经过慎重考虑后，转换成一些带冗余数据的物理表

3.8.7.1.1. 逆规范化有意将一个属性放在多个位置

3.8.7.2. 将数据逆规范化的原因

3.8.7.2.1. 提前组合来自多个其他表的数据，以避免代价高昂的运行时连接

3.8.7.2.2. 创建更小的、预先过滤的数据副本，以减少昂贵的运行时计算和/或大型表的扫描

3.8.7.2.3. 预先计算和存储昂贵的数据计算结果，以避免运行时系统资源竞争

3.8.7.2.4. 最重要的是提高性能

3.8.7.3. 逆规范化还可以用于根据访问需要将数据划分为多个视图或副本表来加强用户安全性

3.8.7.4. 逆规范化处理由于存在数据冗余而引入了产生数据错误的风险

3.8.7.4.1. 只有在使用视图或分区进行物理设计还是无法满足效率要求时，才会选择逆规范化处理

3.8.7.4.2. 为确保正确地存储属性副本，执行数据质量检查是一个好办法

3.8.7.5. 一般来说，逆规范化只会提高数据库查询性能或提升用户安全操作

3.8.7.6. 在维度数据建模中，逆规范化被称为折叠(Collapsing)或合并(Combining)

3.8.7.6.1. 如果每个维度都被折叠成一个结构，生成的数据模型被称为星型模式(Star Schema)

3.8.7.6.2. 如果维度没有折叠，则生成的数据模型被称为雪花(Snowflake)