ER 模型中有三个要素,分别是实体、属性和关系
实体
,可以看做是数据对象,往往对应于现实生活中的真实存在的个体。在 ER 模型中,用 矩形
来表示。实体分为两类,分别是 强实体
和 弱实体
。强实体是指不依赖于其他实体的实体;弱实体是指对另一个实体有很强的依赖关系的实体。
属性
,则是指实体的特性。比如超市的地址、联系电话、员工数等。在 ER 模型中用 椭圆形
来表示。
关系
,则是指实体之间的联系。比如超市把商品卖给顾客,就是一种超市与顾客之间的联系。在 ER 模型中用 菱形
来表示。关系又可以分为 3 种类型,分别是一对一、一对多、多对多。
ER 模型看起来比较麻烦,但是对我们把控项目整体非常重要。如果你只是开发一个小应用,或许简单设计几个表够用了,一旦要设计有一定规模的应用,在项目的初始阶段,建立完整的 ER 模型就非常关键了。开发应用项目的实质,其实就是 建模
。
这里以 电商业务
设计为案例,由于电商业务太过庞大且复杂,所以我们做了业务简化,比如针对SKU(StockKeepingUnit,库存量单位)和SPU(Standard Product Unit,标准化产品单元)的含义上,我们直接使用了SKU,并没有提及SPU的概念。本次电商业务设计总共有8个实体,如下所示。
其中, 用户
和 商品分类
是强实体,因为它们不需要依赖其他任何实体。而其他属于弱实体,因为它们虽然都可以独立存在,但是它们都依赖用户这个实体,因此都是弱实体。知道了这些要素,我们就可以从强实体 用户
开始给电商业务创建 ER 模型了,如图:
有了这个 ER 模型,我们就可以从整体上 理解
电商的业务了。刚刚的 ER 模型展示了电商业务的框架,但是只包括了订单,地址,用户,购物车,评论,商品,商品分类和订单详情这八个实体,以及它们之间的关系,还不能对应到具体的表,以及表与表之间的关联。我们需要把 属性加上
,用 椭圆
来表示,这样我们得到的 ER 模型就更加完整了。
因此,我们需要进一步去设计一下这个 ER 模型的各个局部,也就是细化下电商的具体业务流程,然后把它们综合到一起,形成一个完整的 ER 模型。这样可以帮助我们理清数据库的设计思路。
接下来,我们再分析一下各个实体都有哪些属性,如下所示:
地址实体
包括用户编号、省、市、地区、收件人、联系电话、是否是默认地址用户实体
包括用户编号、用户名称、昵称、用户密码、手机号、邮箱、头像、用户级别购物车实体
包括购物车编号、用户编号、商品编号、商品数量、图片文件url订单实体
包括订单编号、收货人、收件人电话、总金额、用户编号、付款方式、送货地址、下单时间订单详情实体
包括订单详情编号、订单编号、商品名称、商品编号、商品数量商品实体
包括商品编号、价格、商品名称、分类编号、是否销售,规格、颜色评论实体
包括评论id、评论内容、评论时间、用户编号、商品编号商品分类实体
包括类别编号、类别名称、父类别编号这样细分之后,我们就可以重新设计电商业务了,ER 模型如图:
通过绘制 ER 模型,我们已经理清了业务逻辑,现在,我们就要进行非常重要的一步了:把绘制好的 ER模型,转换成具体的数据表,下面介绍下转换的原则:
实体
通常转换成一个 数据表
;多对多
的关系 ,通常也转换成一个 数据表
;1 对 1
,或者 1 对多
的关系,往往通过表的 外键
来表达,而不是设计一个新的数据表;属性
转换成表的 字段
首先看强实体转换成数据表
用户实体
转换成用户表
CREATE TABLE
user_info
(
id bigint UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '编号',
user_name VARCHAR(200) COMMENT '用户名称',
nick_name VARCHAR(200) COMMENT '用户昵称',
password VARCHAR(200) COMMENT '用户密码',
phone_num VARCHAR(20) COMMENT '手机号',
email VARCHAR(200) COMMENT '邮箱',
head_img VARCHAR(200) COMMENT '头像',
user_level VARCHAR(200) COMMENT '用户级别',
PRIMARY KEY (id)
)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE=utf8mb4_general_ci COMMENT='用户表';
商品分类实体
转换成商品分类表 (base_category) ,由于商品分类可以有一级分类和二级分类,比如一级分类有家居、手机等等分类,二级分类可以根据手机的一级分类分为手机配件,运营商等,这里我们把商品分类实体规划为两张表,分别是 一级分类表
和 二级分类表
,之所以这么规划是因为一级分类和二级分类都是有限的,存储为两张表业务结构更加清晰。
CREATE TABLE
base_category1
(
id bigint UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '编号',
name VARCHAR(100) NOT NULL COMMENT '分类名称',
PRIMARY KEY (id)
)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE=utf8mb4_general_ci COMMENT='一级分类表';
CREATE TABLE
base_category2
(
id bigint UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '编号',
name VARCHAR(100) NOT NULL COMMENT '二级分类名称',
category1_id bigint COMMENT '一级分类编号',
PRIMARY KEY (id)
)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE=utf8mb4_general_ci COMMENT='二级分类表';
再把弱实体转换为数据表
地址实体
转换成地址表 (user_address)
CREATE TABLE
user_address
(
id bigint UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '编号',
province VARCHAR(255) COMMENT '省',
city VARCHAR(255) COMMENT '市',
user_address VARCHAR(255) COMMENT '详细地址',
user_id bigint UNSIGNED COMMENT '用户id',
consignee VARCHAR(50) COMMENT '收件人',
telephone VARCHAR(20) COMMENT '联系方式',
default_mark TINYINT COMMENT '是否默认(1:是 0:否)',
PRIMARY KEY (id)
)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE=utf8mb4_general_ci;
订单实体
转换成订单表 (order_info)
CREATE TABLE
order_info
(
id bigint UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '编号',
consignee VARCHAR(50) COMMENT '收件人',
consignee_tel VARCHAR(20) COMMENT '联系方式',
total_amount DECIMAL(10,2) COMMENT '总金额',
user_id bigint UNSIGNED COMMENT '用户id',
payment_way VARCHAR(20) COMMENT '付款方式',
delivery_address VARCHAR(255) COMMENT '送货地址',
create_time DATETIME COMMENT '下单时间',
PRIMARY KEY (id)
)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE=utf8mb4_general_ci COMMENT='订单表';
订单详情实体
转换成订单详情表 (order_detail) ,如下所示。(用于体现多对多关系的,见下节)
CREATE TABLE
order_detail
(
id bigint UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '订单详情编号',
order_id bigint UNSIGNED COMMENT '订单编号',
sku_id bigint COMMENT 'sku_id',
sku_name VARCHAR(200) COMMENT 'sku名称',
sku_num INT COMMENT '购买个数',
create_time DATETIME COMMENT '操作时间',
PRIMARY KEY (id)
)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE=utf8mb4_general_ci COMMENT='订单明细表';
购物车实体
转换成购物车表 (cart_info)
CREATE TABLE
cart_info
(
id bigint UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '编号',
user_id bigint UNSIGNED NOT NULL COMMENT '用户id',
sku_id bigint UNSIGNED COMMENT 'skuid',
sku_num INT COMMENT '数量',
img_url VARCHAR(255) COMMENT '图片链接',
PRIMARY KEY (id)
)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE=utf8mb4_general_ci COMMENT='购物车表';
评论实体
转换成评论表 (sku_comment)
CREATE TABLE
sku_comment
(
id bigint UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '编号',
user_id bigint UNSIGNED NOT NULL COMMENT '用户编号',
sku_id bigint UNSIGNED NOT NULL COMMENT '商品编号',
COMMENT VARCHAR(255) COMMENT '评论内容',
create_time DATETIME COMMENT '评论时间',
PRIMARY KEY (id)
)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE=utf8mb4_general_ci COMMENT='商品评论表';
商品实体
转换成商品表(sku_info)
CREATE TABLE
sku_info
(
id bigint UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '商品编号',
price DECIMAL(10,2) COMMENT '价格',
sku_name VARCHAR(255) COMMENT '商品名称',
sku_desc VARCHAR(2000) COMMENT '商品描述',
category3_id bigint UNSIGNED COMMENT '三级分类id(冗余)',
color VARCHAR(50) COMMENT '颜色',
sale_mark TINYINT COMMENT '是否销售(1:是 0:否)',
PRIMARY KEY (id)
)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE=utf8mb4_general_ci;
这个ER 模型中的多对多的关系有1 个,即 商品
和 订单
之间的关系,同品类的商品可以出现在不同的订单中,不同的订单也可以包含同一类型的商品,所以它们之间的关系是多对多。针对这种情况需要设计一个独立的表来表示,这种表一般称为 中间表
。
我们可以设计一个独立的 订单详情表
,来代表商品和订单之间的包含关系。这个表关联到 2个实体,分别是订单、商品。所以,表中必须要包括这 2个实体转换成的表的主键。除此之外,我们还要包括该关系自有的属性商品数量,商品下单价格以及商品名称。即上面已经创建的订单详情表order_detail,这里再看一遍
CREATE TABLE
order_detail
(
id bigint UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '订单详情编号',
order_id bigint UNSIGNED COMMENT '订单编号',
sku_id bigint COMMENT 'sku_id',
sku_name VARCHAR(200) COMMENT 'sku名称',
sku_num INT COMMENT '购买个数',
create_time DATETIME COMMENT '操作时间',
PRIMARY KEY (id)
)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE=utf8mb4_general_ci COMMENT='订单明细表';
如商品评论表中,user_id和sku_id定义为外键。注意,一般不在数据库层面设置外键约束,因为外键会导致性能下降
,对性能影响是负面的。而是通过应用层做数据的 一致性检查
来使得数据满足外键功能。
任何一个基于数据库的应用项目,都可以通过这种 先建立 ER 模型
,再 转换成数据表
的方式,完成数据库的设计工作。创建 ER 模型不是目的,目的是把业务逻辑梳理清楚,设计出优秀的数据库。不要为了建模而建模,要利用创建 ER 模型的过程来整理思路,这样创建 ER 模型才有意义。
注意:这个原则并不是绝对的,有时候我们需要牺牲数据的冗余度来换取数据处理的效率
一律小写
,不同单词采用 下划线
分割。须见名知意。显式指定字符集
,并且字符集只能是utf8或者utf8mb4。权限最小原则
英文字母
开头 。缩写
。如:公司 ID,不要使用corporation_id, 而用corp_id 即可。冗余索引
。 比如:如果表里已经存在key(a,b),则key(a)为冗余索引,需要删除。表锁
,期间阻塞对于该表的所有写入,对于业务可能会产生极大影响。