低质量数据建模十宗罪

1. 没有准确捕获到需求（如没有知道需要兼容旧系统）
2. 数据模型不完整（包括文档的不完整）
3. 各层模型与其扮演角色不匹配
4. 数据结构不合理
5. 抽象化不够，造成模型不灵活
6. 没有或者不遵循命名规范
7. 缺少数据模型的定义和描述
8. 数据模型可读性差（包含ER图）
9. 元数据与数据不匹配
10. 数据模型与企业标准不一直（各个项目有各个项目的标准确没有统一的企业标准）

三个月之内只有我知道，三个月之后只有上帝知道。

牵一发而动全身

清·龚自珍《自春徂秋偶有所感触》

交流性: 观看数据模型就可以知道一个公司的运作方式， 模型可以交流想法。帮助理解已有应用程序，了解业务。

概要

实体

通常是名词

人 事 等抽象化对象

如员工，公司等

实体对应数据库就是表，实体就是一行行数据。

很多重要实体都会在概念模型中去定义，而在逻辑模型阶段会逐步去完善。

沟通

理解每个人员的观点，需要阅读大量相关文档，资讯与业务相关的问题，专心聆听 尽可能提出大量问题，捕获需求。

1. 询问场景
2. 确认实体
3. 与客户确认（将不用的实体去掉，确认流程正确性）
4. 建模

循环这四步

5W1H

Pattern分类

可以独立存在的实体为强实体，需要依赖其他实体的实体为弱实体。

主实体不依赖其他的实体，能够独立存在的实体。

对于父实体的逻辑划分，一对多的关系。

一对一的关系。

属性

属性的一些特性

一些特性需要作为模型的描述内容记录下来，一些需要在数据库层面有所体现

1. 强制 还是 可选？
2. 原子 还是 组合？直接 还是 派生？
3. 单值 还是 多值？
4. 是否是可选键？
5. 属性的数据类型是什么？
6. 属性是否有默认值？
7. 派生属性是如何计算的？

属性可以使用自己定义的域。

域

属性的所有取值范围的集合，可以理解为自定义的数据类型，并可以加一些约束。

相当于一个新的数据类型，可以应用在属性中。

关系

用问题确定关系

在概念模型会出现多对多关系，逻辑模型里需要把多对多关系消除掉。

键

候选键：一个或多个属性的组合，可以唯一确定一个实体的一个实例。

可选键：候选键中，没有选中的其他键，称为可选键。

主键：从候选键中，选中用来作为唯一标识的属性或者属性组，被称为主键。

• 唯一性，不可重复
• 强制性，不可为空
• 永久性，不可改变
• 最小集合，不可掺杂多余属性

单键：主键如果是一个属性，称为单键。

复合键：主键如果是多个属性的组合，称为复合键。

自然键与代理键

自然键：已经真实存在的键，通常具有商业价值，比如身份证ID，护照编码，车牌号等等。可以是单键，也可以是复合键

代理键：完全没有商业意义，通常由当下的系统自动生成。都是单键

命名规范

遵从公司，项目命名规范
别用冠词，如 a, an, the之类的
别用代词，如 he, she, it, them之类的
尽量别用负方向的词，如not，no，non之类的
避免用间接词，比如in，on，of之类的
别用连词，比如and，or，but之类的
尽量避免动词
缩写必须大写

Index索引

IDX_名称

Key

PK_名字

外键

FK_名字
待完善

约束

CK_字段名称_类型

类型

• 唯一约束：_U
• 非空约束：_N
• 自定义Check：_C

例子：CK_EMPEMAIL_U

Job

JOB_

Sequence

SEQ_

存储过程

SP_

视图

名称_V

表

分类_名称

分类

• Master：MSTR 主数据 企业核心共享数据，各个应用都会使用到如：
  员工 个人
  公司 部门 合作伙伴 客户 组织
  产品 商品 原材料 半成品
• Reference：REF 参照表 通常为 某某分类 某某类型 如：国家 省份 城市 客户分类 客户消费等级 产品分类
• X Reference：XREF 主要解决多对多的连接问题 如：学生和班级的多对多关系
• Event(Transaction)：EVT 事件产生的数据 如：交易表 财务流水表 浏览记录 通话记录
• Header：HDR 标题 订单发送人 订单发送地址 订单总价格
• Detail：DTL 详情 单品 品名 品类 价格
• Interface：ITF 上游系统提供的接口表
• System：SYS 系统表 辅助功能的表 为了编程方便实现一些功能表这些表就称为系统表
• Log：LOG 数据仓库某种操作需要记录日志

列

主体_描述事物

待完善