8. ER模型
ER 模型中有三个要素,分别是实体、属性和关系。
实体,可以看做是数据对象,往往对应于现实生活中的真实存在的个体。在 ER 模型中,用矩形来表示。实体分为两类,分别是强实体和弱实体。强实体是指不依赖于其他实体的实体;弱实体是指对另一个实体有很强的依赖关系的实体。
属性,则是指实体的特性。比如超市的地址、联系电话、员工数等。在 ER 模型中用椭圆形来表示。
关系,则是指实体之间的联系。比如超市把商品卖给顾客,就是一种超市与顾客之间的联系。在 ER 模型中用菱形来表示。
注意:实体和属性不容易区分。这里提供一个原则:我们要从系统整体的角度出发去看,可以独立存在的是实体,不可再分的是属性。也就是说,属性不能包含其他属性。
8.1 关系的类型
在 ER 模型的 3 个要素中,关系又可以分为 3 种类型,分别是 一对一、一对多、多对多。
一对一:指实体之间的关系是一一对应的,比如个人与身份证信息之间的关系就是一对一的关系。一个人只能有一个身份证信息,一个身份证信息也只属于一个人。
一对多:指一边的实体通过关系,可以对应多个另外一边的实体。相反,另外一边的实体通过这个关系,则只能对应唯一的一边的实体。比如说,我们新建一个班级表,而每个班级都有多个学生,每个学生则对应一个班级,班级对学生就是一对多的关系。
多对多:指关系两边的实体都可以通过关系对应多个对方的实体。比如在进货模块中,供货商与超市之间的关系就是多对多的关系,一个供货商可以给多个超市供货,一个超市也可以从多个供货商那里采购商品。再比如一个选课表,有许多科目,每个科目有很多学生选,而每个学生又可以选择多个科目,这就是多对多的关系。
8.2 建模分析
ER 模型看起来比较麻烦,但是对我们把控项目整体非常重要。如果你只是开发一个小应用,或许简单设计几个表够用了,一旦要设计有一定规模的应用,在项目的初始阶段,建立完整的 ER 模型就非常关键了。开发应用项目的实质,其实就是建模。
我们设计的案例是电商业务,由于电商业务太过庞大且复杂,所以我们做了业务简化,比如针对SKU(StockKeepingUnit,库存量单位)和SPU(Standard Product Unit,标准化产品单元)的含义上,我们直接使用了SKU,并没有提及SPU的概念。本次电商业务设计总共有8个实体,如下所示。
- 地址实体
- 用户实体
- 购物车实体
- 评论实体
- 商品实体
- 商品分类实体
- 订单实体
- 订单详情实体
其中, 用户和商品分类是强实体,因为它们不需要依赖其他任何实体。而其他属于弱实体,因为它们虽然都可以独立存在,但是它们都依赖用户这个实体,因此都是弱实体。知道了这些要素,我们就可以
给电商业务创建 ER 模型了,如图:
在这个图中,地址和用户之间的添加关系,是一对多的关系,而商品和商品详情示一对1的关系,商品和订单是多对多的关系。 这个 ER 模型,包括了 8个实体之间的 8种关系。
(1)用户可以在电商平台添加多个地址;
(2)用户只能拥有一个购物车;
(3)用户可以生成多个订单;
(4)用户可以发表多条评论;
(5)一件商品可以有多条评论;
(6)每一个商品分类包含多种商品;
(7)一个订单可以包含多个商品,一个商品可以在多个订单里。
(8)订单中又包含多个订单详情,因为一个订单中可能包含不同种类的商品
8.3 ER 模型的细化
有了这个 ER 模型,我们就可以从整体上理解电商的业务了。刚刚的 ER 模型展示了电商业务的框架,但是只包括了订单,地址,用户,购物车,评论,商品,商品分类和订单详情这八个实体,以及它们之间的关系,还不能对应到具体的表,以及表与表之间的关联。我们需要把属性加上,用椭圆来表示,这样我们得到的 ER 模型就更加完整了。
因此,我们需要进一步去设计一下这个 ER 模型的各个局部,也就是细化下电商的具体业务流程,然后把它们综合到一起,形成一个完整的 ER 模型。这样可以帮助我们理清数据库的设计思路。
(1) 地址实体包括用户编号、省、市、地区、收件人、联系电话、是否是默认地址。
(2) 用户实体包括用户编号、用户名称、昵称、用户密码、手机号、邮箱、头像、用户级别。
(3) 购物车实体包括购物车编号、用户编号、商品编号、商品数量、图片文件url。
(4) 订单实体包括订单编号、收货人、收件人电话、总金额、用户编号、付款方式、送货地址、下单时间。
(5) 订单详情实体包括订单详情编号、订单编号、商品名称、商品编号、商品数量。
(6) 商品实体包括商品编号、价格、商品名称、分类编号、是否销售,规格、颜色。
(7) 评论实体包括评论id、评论内容、评论时间、用户编号、商品编号
(8) 商品分类实体包括类别编号、类别名称、父类别编号
8.4 ER 模型图转换成数据表
通过绘制 ER 模型,我们已经理清了业务逻辑,现在,我们就要进行非常重要的一步了:把绘制好的 ER模型,转换成具体的数据表,下面介绍下转换的原则:
(1)一个实体通常转换成一个数据表;
(2)一个多对多的关系,通常也转换成一个数据表;
(3)一个 1 对 1 ,或者 1 对多的关系,往往通过表的外键来表达,而不是设计一个新的数据表;
(4) 属性转换成表的字段。
其实,任何一个基于数据库的应用项目,都可以通过这种先建立 ER 模型,再转换成数据表的方式,完成数据库的设计工作。创建 ER 模型不是目的,目的是把业务逻辑梳理清楚,设计出优秀的数据库。我建议你不是为了建模而建模,要利用创建 ER 模型的过程来整理思路,这样创建 ER 模型才有意义。
9. 数据表的设计原则
综合以上内容,总结出数据表设计的一般原则:“三少一多”
- 数据表的个数越少越好
- 数据表中的字段个数越少越好
- 数据表中联合主键的字段个数越少越好
- 使用主键和外键越多越好
注意:这个原则并不是绝对的,有时候我们需要牺牲数据的冗余度来换取数据处理的效率。
10. 数据库对象编写建议
10.1 关于库
- 【强制】库的名称必须控制在32个字符以内,只能使用英文字母、数字和下划线,建议以英文字母开头。
- 【强制】库名中英文一律小写,不同单词采用下划线分割。须见名知意。
- 【强制】库的名称格式:业务系统名称_子系统名。
- 【强制】库名禁止使用关键字(如type,order等)。
- 【强制】创建数据库时必须显式指定字符集,并且字符集只能是utf8或者utf8mb4。创建数据库SQL举例:CREATE DATABASE crm_fund DEFAULT CHARACTER SET ‘utf8’ ;
- 【建议】对于程序连接数据库账号,遵循权限最小原则使用数据库账号只能在一个DB下使用,不准跨库。程序使用的账号原则上不准有drop权限。
- 【建议】临时库以tmp_ 为前缀,并以日期为后缀;备份库以 bak_ 为前缀,并以日期为后缀。
10.2 关于表、列
-
【强制】表和列的名称必须控制在32个字符以内,表名只能使用英文字母、数字和下划线,建议以英文字母开头
-
【强制】表名、列名一律小写,不同单词采用下划线分割。须见名知意。
-
【强制】表名要求有模块名强相关,同一模块的表名尽量使用统一前缀。比如:crm_fund_item
-
【强制】创建表时必须显式指定字符集为utf8或utf8mb4。
-
【强制】表名、列名禁止使用关键字(如type,order等)。
-
【强制】创建表时必须显式指定表存储引擎类型。如无特殊需求,一律为InnoDB。
-
【强制】建表必须有comment。
-
【强制】字段命名应尽可能使用表达实际含义的英文单词或缩写。如:公司 ID,不要使用corporation_id, 而用corp_id 即可。
-
【强制】布尔值类型的字段命名为is_描述。如member表上表示是否为enabled的会员的字段命名为 is_enabled。
-
【强制】禁止在数据库中存储图片、文件等大的二进制数据通常文件很大,短时间内造成数据量快速增长,数据库进行数据库读取时,通常会进行大量的随
机IO操作,文件很大时,IO操作很耗时。通常存储于文件服务器,数据库只存储文件地址信息。 -
【建议】建表时关于主键: 表必须有主键 (1)强制要求主键为id,类型为int或bigint,且为auto_increment 建议使用unsigned无符号型。 (2)标识表里每一行主体的字段不要设为主键,建议设为其他字段如user_id,order_id等,并建立unique key索引。因为如果设为主键且主键值为随机插入,则会导致innodb内部页分裂和大量随机I/O,性能下降。
-
【建议】核心表(如用户表)必须有行数据的创建时间字段(create_time)和最后更新时间字段(update_time),便于查问题。
-
【建议】表中所有字段尽量都是NOT NULL 属性,业务可以根据需要定义DEFAULT值。 因为使用NULL值会存在每一行都会占用额外存储空间、数据迁移容易出错、聚合函数计算结果偏差等问题。
-
【建议】所有存储相同数据的列名和列类型必须一致(一般作为关联列,如果查询时关联列类型不一致会自动进行数据类型隐式转换,会造成列上的索引失效,导致查询效率降低)。
-
【建议】中间表(或临时表)用于保留中间结果集,名称以tmp_ 开头。备份表用于备份或抓取源表快照,名称以bak_ 开头。中间表和备份表定期清理。
-
【示范】一个较为规范的建表语句:
CREATE TABLE user_info (`id` INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主键',`user_id` BIGINT ( 11 ) NOT NULL COMMENT '用户id',`username` VARCHAR ( 45 ) NOT NULL COMMENT '真实姓名',`email` VARCHAR ( 30 ) NOT NULL COMMENT '用户邮箱',`nickname` VARCHAR ( 45 ) NOT NULL COMMENT '昵称',`birthday` date NOT NULL COMMENT '生日',`sex` TINYINT ( 4 ) DEFAULT '0' COMMENT '性别',`short_introduce` VARCHAR ( 150 ) DEFAULT NULL COMMENT '一句话介绍自己,最多50个汉字',`user_resume` VARCHAR ( 300 ) NOT NULL COMMENT '用户提交的简历存放地址',`user_register_ip` INT NOT NULL COMMENT '用户注册时的源ip',`create_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',`update_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',`user_review_status` TINYINT NOT NULL COMMENT '用户资料审核状态,1为通过,2为审核中,3为未通过,4为还未提交审核',PRIMARY KEY ( `id` ),UNIQUE KEY `uniq_user_id` ( `user_id` ),KEY `idx_username` ( `username` ),
KEY `idx_create_time_status` ( `create_time`, `user_review_status` )
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '网站用户基本信息'
- 【建议】创建表时,可以使用可视化工具。这样可以确保表、字段相关的约定都能设置上。
10.3 关于索引
- 【强制】InnoDB表必须主键为id int/bigint auto_increment,且主键值禁止被更新。
- 【强制】InnoDB和MyISAM存储引擎表,索引类型必须为BTREE 。
- 【建议】主键的名称以 pk_ 开头,唯一键以 uni_ 或 uk_ 开头,普通索引以 idx_ 开头,一律使用小写格式,以字段的名称或缩写作为后缀。
- 【建议】多单词组成的columnname,取前几个单词首字母,加末单词组成column_name。如:
sample 表 member_id 上的索引:idx_sample_mid。 - 【建议】单个表上的索引个数不能超过6个。
- 【建议】在建立索引时,多考虑建立联合索引,并把区分度最高的字段放在最前面。
- 【建议】在多表 JOIN 的SQL里,保证被驱动表的连接列上有索引,这样JOIN 执行效率最高。
- 【建议】建表或加索引时,保证表里互相不存在冗余索引。 比如:如果表里已经存在key(a,b),则key(a)为冗余索引,需要删除。
10.4 SQL编写
- 【强制】程序端SELECT语句必须指定具体字段名称,禁止写成 *。
- 【建议】程序端insert语句指定具体字段名称,不要写成INSERT INTO t1 VALUES(…)。
- 【建议】除静态表或小表(100行以内),DML语句必须有WHERE条件,且使用索引查找。
- 【建议】INSERT INTO…VALUES(XX),(XX),(XX)… 这里XX的值不要超过5000个。 值过多虽然上线很快,但会引起主从同步延迟。
- 【建议】SELECT语句不要使用UNION,推荐使用UNION ALL,并且UNION子句个数限制在5个以内。
- 【建议】线上环境,多表 JOIN 不要超过5个表。
- 【建议】减少使用ORDER BY,和业务沟通能不排序就不排序,或将排序放到程序端去做。ORDERBY、GROUP BY、DISTINCT 这些语句较为耗费CPU,数据库的CPU资源是极其宝贵的。
- 【建议】包含了ORDER BY、GROUP BY、DISTINCT 这些查询的语句,WHERE 条件过滤出来的结果集请保持在1000行以内,否则SQL会很慢。
- 【建议】对单表的多次alter操作必须合并为一次对于超过100W行的大表进行alter table,必须经过DBA审核,并在业务低峰期执行,多个alter需整合在一起。 因为alter table会产生表锁,期间阻塞对于该表的所有写入,对于业务可能会产生极大影响。
- 【建议】批量操作数据时,需要控制事务处理间隔时间,进行必要的sleep。
- 【建议】事务里包含SQL不超过5个。因为过长的事务会导致锁数据较久,MySQL内部缓存、连接消耗过多等问题。
- 【建议】事务里更新语句尽量基于主键或UNIQUE KEY,如UPDATE… WHERE id=XX;否则会产生间隙锁,内部扩大锁定范围,导致系统性能下降,产生死锁。