低质量数据建模十宗罪
- 没有准确捕获到需求(如没有知道需要兼容旧系统)
- 数据模型不完整(包括文档的不完整)
- 各层模型与其扮演角色不匹配
- 数据结构不合理
- 抽象化不够,造成模型不灵活
- 没有或者不遵循命名规范
- 缺少数据模型的定义和描述
- 数据模型可读性差(包含ER图)
- 元数据与数据不匹配
- 数据模型与企业标准不一直(各个项目有各个项目的标准确没有统一的企业标准)
三个月之内只有我知道,三个月之后只有上帝知道。
牵一发而动全身
清·龚自珍《自春徂秋偶有所感触》
交流性: 观看数据模型就可以知道一个公司的运作方式, 模型可以交流想法。帮助理解已有应用程序,了解业务。
概要
实体
通常是名词
人 事 等抽象化对象
如员工,公司等
实体对应数据库就是表,实体就是一行行数据。
很多重要实体都会在概念模型中去定义,而在逻辑模型阶段会逐步去完善。
沟通
理解每个人员的观点,需要阅读大量相关文档,资讯与业务相关的问题,专心聆听 尽可能提出大量问题,捕获需求。
- 询问场景
- 确认实体
- 与客户确认(将不用的实体去掉,确认流程正确性)
- 建模
循环这四步
5W1H
Pattern分类
可以独立存在的实体为强实体,需要依赖其他实体的实体为弱实体。
主实体不依赖其他的实体,能够独立存在的实体。
对于父实体的逻辑划分,一对多的关系。
一对一的关系。
属性
属性的一些特性
一些特性需要作为模型的描述内容记录下来,一些需要在数据库层面有所体现
- 强制 还是 可选?
- 原子 还是 组合?直接 还是 派生?
- 单值 还是 多值?
- 是否是可选键?
- 属性的数据类型是什么?
- 属性是否有默认值?
- 派生属性是如何计算的?
属性可以使用自己定义的域。
域
属性的所有取值范围的集合,可以理解为自定义的数据类型,并可以加一些约束。
相当于一个新的数据类型,可以应用在属性中。
关系
用问题确定关系
在概念模型会出现多对多关系,逻辑模型里需要把多对多关系消除掉。
键
候选键:一个或多个属性的组合,可以唯一确定一个实体的一个实例。
可选键:候选键中,没有选中的其他键,称为可选键。
主键:从候选键中,选中用来作为唯一标识的属性或者属性组,被称为主键。
- 唯一性,不可重复
- 强制性,不可为空
- 永久性,不可改变
- 最小集合,不可掺杂多余属性
单键:主键如果是一个属性,称为单键。
复合键:主键如果是多个属性的组合,称为复合键。
自然键与代理键
自然键:已经真实存在的键,通常具有商业价值,比如身份证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 数据仓库某种操作需要记录日志
列
主体_描述事物
待完善
https://www.bilibili.com/video/BV1gf4y1E7cY?p=6