MySQL数据库设计-CSDN博客

本文链接：https://blog.csdn.net/m0_58443686/article/details/132228928

数据完整性

一个数据库就是一个完整的业务单元，可以包含多张表，数据被存储在表中
在表中为了更加准确的存储数据，保证数据的正确有效，可以在创建表的时候，为表添加一些强制性的验证，包括数据字段的类型、约束

约束

主键primary key：物理上存储的顺序
非空not null：此字段不允许填写空值
唯一unique：此字段的值不允许重复
默认default：当不填写此值时会使用默认值，如果填写时以填写为准
外键foreign key：对关系字段进行约束，当为关系字段填写值时，会到关联的表中查询此值是否存在，如果存在则填写成功，如果不存在则填写失败并抛出异常
主键与外键的作用：保证数据稳定可靠
- 主键用于唯一标识每个记录
- 外键用于限制值必须在表中存在
- 虽然外键约束可以保证数据的有效性，但是在进行数据的crud（增加、修改、删除、查询）时，都会降低数据库的性能，所以不推荐使用
- 保证数据的有效性的方法：在逻辑层进行控制

数据类型

使用数据类型的原则是：够用就行，尽量使用取值范围小的，而不用大的，这样可以更多的节省存储空间
常用数据类型如下：
- 整数：int，bit
- 小数：decimal
- 字符串：varchar,char
- 日期时间：date, time, datetime
- 枚举类型：enum
特别说明的类型如下：
- decimal表示浮点数，如decimal(5,2)表示共存5位数，小数占2位
- char表示固定长度的字符串，如char(3) ，如果填充’ab’时会补一个空格'ab '
- varchar表示可变长度的字符串，如varchar(3) ，填充’ab’时就会存储'ab'
- 字符串text表示存储大文本，当字符大于4000时推荐使用
- 对于图片、音频、视频等文件，不存储在数据库中，而是上传到某个服务器上，然后在表中存储这个文件的保存路径
- 可以通过查看帮助文档查阅所有支持的数据类型

数值类型

类型	字节大小	有符号范围（Signed）	无符号范围（Unsigned）
TINYINT	1	-128 ~ 127	0 ~ 255
SMALLINT	2	-32768 ~ 32767	0 ~ 65535
MEDIUMINT	3	-8388608 ~ 8388607	-8388608 ~ 8388607
INT/INTEGER	4	-2147483648 ~2147483647	0 ~ 4294967295
BIGINT	8	-9223372036854775808 ~ 9223372036854775807	0 ~ 18446744073709551615

字符串

类型	字节大小	示例
CHAR	0-255	类型:char(3) 输入’ab’, 实际存储为`'ab '`, 输入’abcd’ 实际存储为 `'abc'`
VARCHAR	0-255	类型:varchar(3) 输入’ab’,实际存储为`'ab'`, 输入’abcd’,实际存储为`'abc'`
TEXT	0-65535	大文本

日期时间类型

类型	字节大小	示例
DATE	4	`'2020-01-01'`
TIME	3	`'12:29:59'`
DATETIME	8	`'2020-01-01 12:29:59'`
YEAR	1	`'2017'`
TIMESTAMP	4	`'1970-01-01 00:00:01' UTC ~ '2038-01-01 00:00:01' UTC`

数据库设计

针对关系型数据库的设计方法

关系型数据库建议在E-R模型的基础上，根据设计策划，抽取出来模型与关系，制定出表结构，这是项目开始的第一步
在开发中有很多设计数据库的软件，常用的如power designer，db desinger等，这些软件可以直观的看到实体及实体间的关系

范式(Normal Form)

目前有迹可寻的共有8种范式，一般需要遵守3范式即可
第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。
第二范式（2NF）：首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。
第三范式（3NF）：首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。
第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分它们的关键点在于，2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分；3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。

设计实例

不遵循1NF

考虑这样一个表：【联系人】（姓名，性别，电话）如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。

在这里插入图片描述

不遵循2NF

考虑一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。因为我们知道在一个订单中可以订购多种产品，所以单单一个 OrderID 是不足以成为主键的，主键应该是（OrderID，ProductID）。显而易见 Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。

可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多次重复的情况。

在这里插入图片描述

不遵循3NF

考虑一个订单表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键列都完全依赖于主键（OrderID），所以符合 2NF。不过问题是 CustomerName，CustomerAddr，CustomerCity 直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。