数据模型基本概念及建模方法论-logic
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
➢ 设计蓝图，指导整个数据仓库系统的建设 ➢ 业务语言，业务人员与技术人员沟通的手段和方法 ➢ 业务视图，独立于数据库技术实现
➢ 设计内容：实体、关系和属性 ➢ 建模方法：3NF的设计方法 ➢ 后续工作：物理数据模型的输入
✓7
物理数据模型
Physical Data Model（PDM）物理数据模型
✓32
物理数据库设计
物理数据 模型
系 统 体 系 结 构
元解
数据转换 数
决
据方
应用开发 管
案
理集
数据挖掘
成
设
服务
计 数据仓库管理
主要任务：
➢ 转换逻辑数据模型（LDM）为物理数据模型 ➢ 定义主索引、次索引 ➢ 非正规化处理（demoralizations） ➢ 数据库建立 ➢ 设计优化 ➢ 数据库功能测试
✓15
逻辑数据模型基本术语 (四)
关系 二元关系
父实体的一个实例严格关系子实体的0，1或多个实例的这种 关系是二元关系 基数 父、子实体实例的比例，如1：1，1：M
识别（型）关系
子实体实例唯一性的识别与父实体相关联，父实体的主键属 性成为子实体的主键属性
非识别（型）关系
子实体不需要与父实体的关系就可以确定实例唯一性,父实体 的主键属性成为子实体的非键属性
✓4
概念数据模型
Conceptual Data Model（CDM）概念数据模型
➢ 从全局上、宏观上介绍模型设计思路、范围和内容。 ➢ 主要组成元素
✓ 主题 ✓ 主题间关系 ✓ 主题中的重要实体 ✓ 实体间的相互关系
➢ 目标与用途
✓ 圈定建模的范围 ✓ 划分建设主题 ✓ 理清主要业务关系 ✓ 构造逻辑数据模型的框架
应 用
模 型
数
据
模
型
✓11
内容安排
什么是数据模型 数据模型相关术语 数据模型方法论 建模注意事项
✓12
逻辑数据模型基本术语 (一)
模型分类 概念数据模型 逻辑数据模型 物理数据模型 应用数据模型
模型结构 第三范式（3NF）结构 星型结构（多星型结构） 雪花型结构
3NF
基础数据模型
Star Schema
使用工具：
➢ ERWin
交付项目：
➢ 物理数据模型（PDM） ➢ 《物理数据模型说明书》 ➢ 《数据库描述语言DDL》
✓33
物理数据模型命名规范
序号 主题
1 PARTY 2 OFFER 3 FINANCE 4 LOCATION 5 ADVERTISEMENT 6 EVENT 7 NETWORK 8 REFERENCE CODE
➢ 设计目标：面向物理实施的具体细节 ➢ 输入条件
➢ 继承于逻辑数据模型 ➢ 依赖于所选择的数据库 ➢ 决定于业务需求和性能之间的平衡
➢ 设计内容
➢ 数据库、表和字段、索引 ➢ 需要作非正则化处理
➢ 后续工作：ETL、元数据管理和前端应用输入
✓8
应用数据模型
Application Data Model(ADM)应用数据模型
• 可选: 使用带样本数据的表格形式与用户进行确认 • 必须: 使用ER图制定最终版本的交付材料
✓28
STEP 3: 定义关系
1. 识别实体间的关系
2. 对于每一个关系 • 删除超出项目范围的关系 • 删除间接的关系 • 为每一个剩余的关系进行定义 • 识别每一个可用的关系的基数 (1:1, 1:M, M:M)
数据模型的基本概念 及建模方法论
内容安排
什么是数据模型 数据模型相关术语 数据模型方法论 建模注意事项
✓2
什么是数据模型？
以数学的方式对现实事物的一种抽象表达,…
特征： ➢ 内容：描述了数据、及其之间的关系 ➢ 形式：反映了数据的组织与管理形式 用途： ➢ (数据仓库)系统建设中的数据信息的蓝图 ➢ (数据仓库)系统建设的核心 ➢ 业务人员与IT人员沟通的语言和工具
Relationship
Nonkey Attribute
✓18
范式理论 NORMAL FORM
关系数据库:原子性
第一范式：
每个属性的值唯一
第二Th范e式K：E键Y值-依1s赖t Normal Form (1NF)
非T键h属e性W依H赖O所L有E的K主e键y 属- S性e。co（n不d 存Normal Form (2NF)
➢ 设计目标
➢ 满足最终用户对数据的访问（内容、形式要求） ➢ 满足应用系统对数据的存取（性能、存储要求）
➢ 主要特征
➢ 面向Power User和业务人员 ➢ 与具体的应用相关 ➢ 多维分析时一般采用星型结构或者雪花状结构
的设计方法 ➢ 是事实表和维度表的组合
✓9
逻辑数据模型与物理数据模型比较
包含内容 定位记录 使用名称
采集
存储 和管理
IT 用户
源数据
业务系统 业务系统
业务数据 外部数据
数据导入 析取 清洗 条件 剔除 家庭关系 加载
企业 数据仓库
关系数据库管理系统
从属数据集市
回答 业务问题
知识发现 数据挖掘 信息存取
工具
业务人员
聚集 统计 人工智能 神经网络
对象语言
多维 可视化 EIS/DSS电子表 开发
逻
辑
数
据
在部An分d键N属O性T就H决IN定G的非B键U属T性th）e Key - Third Normal Form (3NF)
第三范式:完全键值依赖
-- E. F. Codd
非键属性完全依赖且只依赖与键属性。
（不存在非主键属性依赖其他非主键属
性的情况）
BCNF
第四范式
第五范式
关系数据库理论中对于实体划分、实例（记录）设计的规则
✓23
内容安排
什么是数据模型 数据模型相关术语 数据模型方法论 建模注意事项
✓24
NCR数据仓库实施方Biblioteka Baidu论
规划
设计与实现
支持与增强
现成解决方案规划
修改
业务 探索
验证 解决 方案
逻辑 数据 模型
数
解解
据
详决 决
?仓
库 策 略 开
细方 方 数案 案 据准 实 分备 施
发
析就 建
业务 探索
解决 方案 定义
正则化
冗余数据 派生数据 开发人员
✓10
逻辑数据模型 实体、属性 主键 业务名称
物理数据模型 表、字段 主索引 物理名称（受限于DBMS）
3NF 建设
可能会按照性能、空间要求进行非正则化
无冗余数据 无派生数据 业务人员与建模人员
含冗余数据 包含派生数据 物理数据库设计人员
逻辑数据模型在数据仓库中的定位
✓5
逻辑数据模型
定义： 符号体系 使用逻辑建模语言 设计内容 定义数据与数据之间的逻辑关系 表现形式 以图形化的形式 反映内容 反映客户的业务规则 设计目标 达到数据组织的设计目标
✓6
逻辑数据模型
Logical Data Model （LDM） 逻辑数据模型
➢ 设计人员：业务人员、IT人员 ➢ 设计目标
✓17
逻辑数据模型基本术语 (示例)
Logical Data Model (LDM)
Example
Key Attribute
Cardinality One-to-many 1:M
Entity
Business Rule : • one customer invoice at least
contains one invoice item
✓16
逻辑数据模型基本术语 (五)
关系 确定关系
父实体的一个实例对应子实体的0、1或多个实例，并且子实体 的一个实例对应0或1个父实体的实例
非确定关系
多对多关系
子类关系
子类实体和所属父实体的关系
完全子类群
所属父实体的每个实例都能够与子类群的一个实体实例相关联
不完全子类群
所属父实体的每个实例不一定都有子类相关联
✓31
STEP 5: 确认模型 (2)
1. 通过回答以下问题，持续地对模型的范围进行验证: • 这一模型组件的含义、与业务的关系是什么？ • 这一模型组件驱动的业务需求是什么？
2. 对模型是否已经满足所有业务需求、业务问题及限制条件等，进行验证 3. 绝对不要考虑任何与物理实施相关的问题！ 4. 当所有回答业务需求所必须的数据已经齐备时，停止对模型进行优化
3. 参照完整性 • 确保每一个关系（PK/FK参照）是完整的、有效的
4. 为模型中可用的关系编写文档，使用FK定义关系 • 可选: 使用带样本数据的表格形式与用户进行确认 • 必须: 使用ER图制定最终版本的交付材料
✓29
STEP 4: 定义非键属性
1. 识别并定义相关的非键属性 2. 删除超出项目范围的属性 3. 根据直觉或经验将剩余的可用属性放入一个表中 4. 逐一验证每一个可用属性的摆放位置 5. 为模型中的每一个可用属性编写文档
Step 1: 定义业务需求与范围 Step 2: 定义实体 Step 3: 定义关系 Step 4: 定义非键属性 Step 5: 确认模型
✓26
STEP 1: 定义业务需求与范围
1. 确认已经理解全部业务需求 • 什么困难或问题需要解决？一般情况下这些问题主要关 系到增加收入或降低成本等 • 模型必须能够回答哪些业务问题？ • 有哪些业务功能必须处理？ • 有哪些业务限制存在？ • 是否每一个参与人员都可以共享他们的业务需求？
逻辑 数据 模型 设计
绪议
定制解决方案规划
物理数据库 设计
解
决 方 案 体 系 结
数据转换 元 解
数决
据方
应用开发
管案 理集
成
数 据 仓 库 评
构
设
数据挖掘
估
计
服务
数据仓库管理 (处理流程与操作)
解决方案支持
应用增强
逻辑数据 模型回顾 物理数据 库回顾
性能调整
容量规划
数据仓库的循环过程
✓25
逻辑数据模型设计步骤
✓19
违反第一范式
110
152
如果数Quantity属性被定义为“不是与Order相关，就是与Part相关”
例如：在OLTP系统中常见的字段复用现象，属此类问题 ✓20
违反第二范式
客户经理/地域 客户经理编号
依赖了复合主键的一部分
✓21
违反第三范式
依赖了非主键属性（不参与主键的外键属性）
✓22
✓3
数据模型的分类
数据仓库项目中数据模型可以分为以下几种：
➢ Conceptual Data Model （CDM） 概念数据模型 ➢ Logical Data Model （LDM） 逻辑数据模型 ➢ Physical Data Model（PDM）物理数据模型 ➢ Application Data Model（ADM）应用数据模型
• 可选: 使用带样本数据的表格形式与用户进行确认 • 必须: 使用ER图制定最终版本的交付材料 6. 在模型的最终交付文档中添加业务限制条件
✓30
STEP 5: 确认模型 (1)
根据需要重复以上步骤 1. 多次反复经常是必须的（需求、业务规则、操作的复杂性决定） 2. 模型中的任何变更都会带来连锁反应，因此需要非常认真的回顾 与评审： • 实体的变更经常影响关系的定义和属性的位置摆放 • 关系的变更经常影响属性的位置摆放 • 属性的位置的变更可能影响其他属性的摆放
汇总数据/已知应 用模型
Snowflake
星型结构的演变
✓13
逻辑数据模型基本术语 (二)
实体 独立型实体 依赖型实体
子类实体
主题域 层面
核心实体 关系实体 特征实体 分类实体
✓14
逻辑数据模型基本术语 (三)
属性： （描述真实或抽象事物相关联的特征或性质） 主键 （识别实体实例唯一性的属性、属性组） 可选键 （能识别实体实例唯一性的其他属性、属性组） 外键 （通过父实体到子实体关系转移到子实体的属性） 非键属性（不是实体主键属性的其他属性 ） 基础名 （外键的原来名称 ） 角色名 （外键的新名称，表明取值是父实体属性的子集 ） 鉴别器 （取值决定父实体实例属于哪个子类的属性 ）
✓34
缩写
PAR OFR FIN LOC ADT EVT NET CDE
中文
参与人 产品策划 账务 地理区域 市场营销 事件 网络资源 代码表
正则化LDM对数据库物理实现的优势
保留了更多的业务关系 更多的主索引选择 最佳的数据分布 更少的全表扫描 更多的连接选择 增强优化器使用更有利于提高性能的合并、聚合连接方法
最佳的数据分离（要耦合考度）虑正则化对数据库性能的要求
最佳的底层模型与用户分离 最佳的数据控制 每行更少的字段 最佳的与应用分离 更小的行 最佳的数据块大小 减少临时与永久日志空间 减少物理 I/O
2. 决定搜集需求的方法 • 回顾已经存在的资料（例如现存的报表） • 新的业务需求访谈 • 以上两种混合的方法
✓27
STEP 2: 定义实体
1. 制定初始的实体池（不加区分的实体集合） 2. 为每一个实体进行定义 3. 删除超出项目范围的实体 4. 为剩下的每一个实体定义主键 5. 为可用的实体编写文档
➢ 设计内容：实体、关系和属性 ➢ 建模方法：3NF的设计方法 ➢ 后续工作：物理数据模型的输入
✓7
物理数据模型
Physical Data Model（PDM）物理数据模型
✓32
物理数据库设计
物理数据 模型
系 统 体 系 结 构
元解
数据转换 数
决
据方
应用开发 管
案
理集
数据挖掘
成
设
服务
计 数据仓库管理
主要任务：
➢ 转换逻辑数据模型（LDM）为物理数据模型 ➢ 定义主索引、次索引 ➢ 非正规化处理（demoralizations） ➢ 数据库建立 ➢ 设计优化 ➢ 数据库功能测试
✓15
逻辑数据模型基本术语 (四)
关系 二元关系
父实体的一个实例严格关系子实体的0，1或多个实例的这种 关系是二元关系 基数 父、子实体实例的比例，如1：1，1：M
识别（型）关系
子实体实例唯一性的识别与父实体相关联，父实体的主键属 性成为子实体的主键属性
非识别（型）关系
子实体不需要与父实体的关系就可以确定实例唯一性,父实体 的主键属性成为子实体的非键属性
✓4
概念数据模型
Conceptual Data Model（CDM）概念数据模型
➢ 从全局上、宏观上介绍模型设计思路、范围和内容。 ➢ 主要组成元素
✓ 主题 ✓ 主题间关系 ✓ 主题中的重要实体 ✓ 实体间的相互关系
➢ 目标与用途
✓ 圈定建模的范围 ✓ 划分建设主题 ✓ 理清主要业务关系 ✓ 构造逻辑数据模型的框架
应 用
模 型
数
据
模
型
✓11
内容安排
什么是数据模型 数据模型相关术语 数据模型方法论 建模注意事项
✓12
逻辑数据模型基本术语 (一)
模型分类 概念数据模型 逻辑数据模型 物理数据模型 应用数据模型
模型结构 第三范式（3NF）结构 星型结构（多星型结构） 雪花型结构
3NF
基础数据模型
Star Schema
使用工具：
➢ ERWin
交付项目：
➢ 物理数据模型（PDM） ➢ 《物理数据模型说明书》 ➢ 《数据库描述语言DDL》
✓33
物理数据模型命名规范
序号 主题
1 PARTY 2 OFFER 3 FINANCE 4 LOCATION 5 ADVERTISEMENT 6 EVENT 7 NETWORK 8 REFERENCE CODE
➢ 设计目标：面向物理实施的具体细节 ➢ 输入条件
➢ 继承于逻辑数据模型 ➢ 依赖于所选择的数据库 ➢ 决定于业务需求和性能之间的平衡
➢ 设计内容
➢ 数据库、表和字段、索引 ➢ 需要作非正则化处理
➢ 后续工作：ETL、元数据管理和前端应用输入
✓8
应用数据模型
Application Data Model(ADM)应用数据模型
• 可选: 使用带样本数据的表格形式与用户进行确认 • 必须: 使用ER图制定最终版本的交付材料
✓28
STEP 3: 定义关系
1. 识别实体间的关系
2. 对于每一个关系 • 删除超出项目范围的关系 • 删除间接的关系 • 为每一个剩余的关系进行定义 • 识别每一个可用的关系的基数 (1:1, 1:M, M:M)
数据模型的基本概念 及建模方法论
内容安排
什么是数据模型 数据模型相关术语 数据模型方法论 建模注意事项
✓2
什么是数据模型？
以数学的方式对现实事物的一种抽象表达,…
特征： ➢ 内容：描述了数据、及其之间的关系 ➢ 形式：反映了数据的组织与管理形式 用途： ➢ (数据仓库)系统建设中的数据信息的蓝图 ➢ (数据仓库)系统建设的核心 ➢ 业务人员与IT人员沟通的语言和工具
Relationship
Nonkey Attribute
✓18
范式理论 NORMAL FORM
关系数据库:原子性
第一范式：
每个属性的值唯一
第二Th范e式K：E键Y值-依1s赖t Normal Form (1NF)
非T键h属e性W依H赖O所L有E的K主e键y 属- S性e。co（n不d 存Normal Form (2NF)
➢ 设计目标
➢ 满足最终用户对数据的访问（内容、形式要求） ➢ 满足应用系统对数据的存取（性能、存储要求）
➢ 主要特征
➢ 面向Power User和业务人员 ➢ 与具体的应用相关 ➢ 多维分析时一般采用星型结构或者雪花状结构
的设计方法 ➢ 是事实表和维度表的组合
✓9
逻辑数据模型与物理数据模型比较
包含内容 定位记录 使用名称
采集
存储 和管理
IT 用户
源数据
业务系统 业务系统
业务数据 外部数据
数据导入 析取 清洗 条件 剔除 家庭关系 加载
企业 数据仓库
关系数据库管理系统
从属数据集市
回答 业务问题
知识发现 数据挖掘 信息存取
工具
业务人员
聚集 统计 人工智能 神经网络
对象语言
多维 可视化 EIS/DSS电子表 开发
逻
辑
数
据
在部An分d键N属O性T就H决IN定G的非B键U属T性th）e Key - Third Normal Form (3NF)
第三范式:完全键值依赖
-- E. F. Codd
非键属性完全依赖且只依赖与键属性。
（不存在非主键属性依赖其他非主键属
性的情况）
BCNF
第四范式
第五范式
关系数据库理论中对于实体划分、实例（记录）设计的规则
✓23
内容安排
什么是数据模型 数据模型相关术语 数据模型方法论 建模注意事项
✓24
NCR数据仓库实施方Biblioteka Baidu论
规划
设计与实现
支持与增强
现成解决方案规划
修改
业务 探索
验证 解决 方案
逻辑 数据 模型
数
解解
据
详决 决
?仓
库 策 略 开
细方 方 数案 案 据准 实 分备 施
发
析就 建
业务 探索
解决 方案 定义
正则化
冗余数据 派生数据 开发人员
✓10
逻辑数据模型 实体、属性 主键 业务名称
物理数据模型 表、字段 主索引 物理名称（受限于DBMS）
3NF 建设
可能会按照性能、空间要求进行非正则化
无冗余数据 无派生数据 业务人员与建模人员
含冗余数据 包含派生数据 物理数据库设计人员
逻辑数据模型在数据仓库中的定位
✓5
逻辑数据模型
定义： 符号体系 使用逻辑建模语言 设计内容 定义数据与数据之间的逻辑关系 表现形式 以图形化的形式 反映内容 反映客户的业务规则 设计目标 达到数据组织的设计目标
✓6
逻辑数据模型
Logical Data Model （LDM） 逻辑数据模型
➢ 设计人员：业务人员、IT人员 ➢ 设计目标
✓17
逻辑数据模型基本术语 (示例)
Logical Data Model (LDM)
Example
Key Attribute
Cardinality One-to-many 1:M
Entity
Business Rule : • one customer invoice at least
contains one invoice item
✓16
逻辑数据模型基本术语 (五)
关系 确定关系
父实体的一个实例对应子实体的0、1或多个实例，并且子实体 的一个实例对应0或1个父实体的实例
非确定关系
多对多关系
子类关系
子类实体和所属父实体的关系
完全子类群
所属父实体的每个实例都能够与子类群的一个实体实例相关联
不完全子类群
所属父实体的每个实例不一定都有子类相关联
✓31
STEP 5: 确认模型 (2)
1. 通过回答以下问题，持续地对模型的范围进行验证: • 这一模型组件的含义、与业务的关系是什么？ • 这一模型组件驱动的业务需求是什么？
2. 对模型是否已经满足所有业务需求、业务问题及限制条件等，进行验证 3. 绝对不要考虑任何与物理实施相关的问题！ 4. 当所有回答业务需求所必须的数据已经齐备时，停止对模型进行优化
3. 参照完整性 • 确保每一个关系（PK/FK参照）是完整的、有效的
4. 为模型中可用的关系编写文档，使用FK定义关系 • 可选: 使用带样本数据的表格形式与用户进行确认 • 必须: 使用ER图制定最终版本的交付材料
✓29
STEP 4: 定义非键属性
1. 识别并定义相关的非键属性 2. 删除超出项目范围的属性 3. 根据直觉或经验将剩余的可用属性放入一个表中 4. 逐一验证每一个可用属性的摆放位置 5. 为模型中的每一个可用属性编写文档
Step 1: 定义业务需求与范围 Step 2: 定义实体 Step 3: 定义关系 Step 4: 定义非键属性 Step 5: 确认模型
✓26
STEP 1: 定义业务需求与范围
1. 确认已经理解全部业务需求 • 什么困难或问题需要解决？一般情况下这些问题主要关 系到增加收入或降低成本等 • 模型必须能够回答哪些业务问题？ • 有哪些业务功能必须处理？ • 有哪些业务限制存在？ • 是否每一个参与人员都可以共享他们的业务需求？
逻辑 数据 模型 设计
绪议
定制解决方案规划
物理数据库 设计
解
决 方 案 体 系 结
数据转换 元 解
数决
据方
应用开发
管案 理集
成
数 据 仓 库 评
构
设
数据挖掘
估
计
服务
数据仓库管理 (处理流程与操作)
解决方案支持
应用增强
逻辑数据 模型回顾 物理数据 库回顾
性能调整
容量规划
数据仓库的循环过程
✓25
逻辑数据模型设计步骤
✓19
违反第一范式
110
152
如果数Quantity属性被定义为“不是与Order相关，就是与Part相关”
例如：在OLTP系统中常见的字段复用现象，属此类问题 ✓20
违反第二范式
客户经理/地域 客户经理编号
依赖了复合主键的一部分
✓21
违反第三范式
依赖了非主键属性（不参与主键的外键属性）
✓22
✓3
数据模型的分类
数据仓库项目中数据模型可以分为以下几种：
➢ Conceptual Data Model （CDM） 概念数据模型 ➢ Logical Data Model （LDM） 逻辑数据模型 ➢ Physical Data Model（PDM）物理数据模型 ➢ Application Data Model（ADM）应用数据模型
• 可选: 使用带样本数据的表格形式与用户进行确认 • 必须: 使用ER图制定最终版本的交付材料 6. 在模型的最终交付文档中添加业务限制条件
✓30
STEP 5: 确认模型 (1)
根据需要重复以上步骤 1. 多次反复经常是必须的（需求、业务规则、操作的复杂性决定） 2. 模型中的任何变更都会带来连锁反应，因此需要非常认真的回顾 与评审： • 实体的变更经常影响关系的定义和属性的位置摆放 • 关系的变更经常影响属性的位置摆放 • 属性的位置的变更可能影响其他属性的摆放
汇总数据/已知应 用模型
Snowflake
星型结构的演变
✓13
逻辑数据模型基本术语 (二)
实体 独立型实体 依赖型实体
子类实体
主题域 层面
核心实体 关系实体 特征实体 分类实体
✓14
逻辑数据模型基本术语 (三)
属性： （描述真实或抽象事物相关联的特征或性质） 主键 （识别实体实例唯一性的属性、属性组） 可选键 （能识别实体实例唯一性的其他属性、属性组） 外键 （通过父实体到子实体关系转移到子实体的属性） 非键属性（不是实体主键属性的其他属性 ） 基础名 （外键的原来名称 ） 角色名 （外键的新名称，表明取值是父实体属性的子集 ） 鉴别器 （取值决定父实体实例属于哪个子类的属性 ）
✓34
缩写
PAR OFR FIN LOC ADT EVT NET CDE
中文
参与人 产品策划 账务 地理区域 市场营销 事件 网络资源 代码表
正则化LDM对数据库物理实现的优势
保留了更多的业务关系 更多的主索引选择 最佳的数据分布 更少的全表扫描 更多的连接选择 增强优化器使用更有利于提高性能的合并、聚合连接方法
最佳的数据分离（要耦合考度）虑正则化对数据库性能的要求
最佳的底层模型与用户分离 最佳的数据控制 每行更少的字段 最佳的与应用分离 更小的行 最佳的数据块大小 减少临时与永久日志空间 减少物理 I/O
2. 决定搜集需求的方法 • 回顾已经存在的资料（例如现存的报表） • 新的业务需求访谈 • 以上两种混合的方法
✓27
STEP 2: 定义实体
1. 制定初始的实体池（不加区分的实体集合） 2. 为每一个实体进行定义 3. 删除超出项目范围的实体 4. 为剩下的每一个实体定义主键 5. 为可用的实体编写文档