数据库中存放很多表,设计数据库就是设计表。表是对现实生活中一些事务的抽象。

要设计数据库就要明白表的关系,也要知道数据库设计的一些准则,也称范式。

数据库的设计直接影响了项目开发的难易程度,也直接影响了项目开发完后运行的性能。

一、多表之间的关系

1、一对多(或多对一),如部门和员工,一个部门有多个员工,一个员工只能对应一个部门。

2、多对多,学生和课程,一个学生可以选择很多课程,一个课程也可以被很多学生选择。

3、一对一,如人和身份证,一个人只有一个身份证,一个身份证只能对应一个人。开发中,一对一的关系很少存在,了解即可。

1、多表关系_一对多关系实现

如:部门和员工

创建表时如何实现一对多的关系呢?在多的一方建立外键去指向一的一方的主键

2、多表关系_多对多关系实现

如:学生和课程

创建表时如何实现多对多的关系呢?需要借助第三张中间表,中间表至少包含两个字段,这两个字段作为第三张表的外键,分别指向两张表的主键

注意:每一对不应该重复,故需要设置联合主键。

联合主键,如下所示:

ALTER TABLE sys_user_role  ADD  CONSTRAINT PK_user_role PRIMARY KEY( user_id, role_id);

3、多表关系_一对一关系实现

如:人和身份证

创建表时如何实现一对一的关系呢?在任意一方添加唯一外键去指向一的一方的主键。注意:需要让外键唯一,唯一约束。

4、一对一关系案例

如果是一对一关系,一般都会合成一张表。但是也有特殊情况:即使是一对一关系也要进行垂直拆分!

ap_article 文章基本信息表

ap_article_config 文章配置表

ap_article_content 文章内容表

将一个表的字段分散到多个表中,每个表存储其中一部分字段。

 

 

分表的好处:

(1)、减少IO争抢,减少锁表的几率,查看文章概述和文章详情互不影响。

(2)、充分发挥高频数据的操作效率,对文章概述数据操作的高效率不会被操作文章详情数据的低效率所拖累。

 ap_article_content表的效率比较低,因为该表的content字段为longtext类型(longtext字段对应的属性的类型为String),内容比较多时,效率就比较慢。而ap_article表的效率相对比较快,拆分之后,操作ap_article表是高效率的,操作ap_article_content是低效率的。我们经常操作ap_article不会被ap_article_content影响。

5、一对多和多对多关系案例

旅游线路分类、旅游线路、用户

一个旅游线路分类对应多个旅游线路,一个线路对应一个分类。分类表和线路表是一对多的关系。故在多的一方添加外键指向一的一方的主键。

一个用户对应多个旅游线路,一个线路可以被多个用户所收藏。故线路表和用户表是多对多的关系。

-- 创建旅游线路分类表 tab_category
-- cid 旅游线路分类主键,自动增长
-- cname 旅游线路分类名称非空,唯一,字符串 100
CREATE TABLE tab_category (
    cid INT PRIMARY KEY AUTO_INCREMENT,
    cname VARCHAR(100) NOT NULL UNIQUE
);
-- 创建旅游线路表 tab_route
/*
rid 旅游线路主键,自动增长
rname 旅游线路名称非空,唯一,字符串 100
price 价格
rdate 上架时间,日期类型
cid 外键,所属分类
*/
CREATE TABLE tab_route(
    rid INT PRIMARY KEY AUTO_INCREMENT,
    rname VARCHAR(100) NOT NULL UNIQUE,
    price DOUBLE,
    rdate DATE,
    cid INT,
    FOREIGN KEY (cid) REFERENCES tab_category(cid)
);
/*创建用户表 tab_user
uid 用户主键,自增长
username 用户名长度 100,唯一,非空
password 密码长度 30,非空
name 真实姓名长度 100
birthday 生日
sex 性别,定长字符串 1
telephone 手机号,字符串 11
email 邮箱,字符串长度 100
*/
CREATE TABLE tab_user (
    uid INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(100) UNIQUE NOT NULL,
    PASSWORD VARCHAR(30) NOT NULL,
    NAME VARCHAR(100),
    birthday DATE,
    sex CHAR(1) DEFAULT '',
    telephone VARCHAR(11),
    email VARCHAR(100)
);
/*
创建收藏表 tab_favorite
rid 旅游线路 id,外键
date 收藏时间
uid 用户 id,外键
rid 和 uid 不能重复,设置复合主键,同一个用户不能收藏同一个线路两次
*/
CREATE TABLE tab_favorite (
    rid INT, -- 线路id
    DATE DATETIME,
    uid INT, -- 用户id
    -- 创建复合主键
    PRIMARY KEY(rid,uid), -- 联合主键
    FOREIGN KEY (rid) REFERENCES tab_route(rid),
    FOREIGN KEY(uid) REFERENCES tab_user(uid)
);

在sqlyog中的架构设计器中展示如下:

二、数据库设计的范式

1、概念

设计数据库时,需要遵循的一些规范。要遵循后边的范式要求,必须先遵循前边的所有范式要求。

设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小

目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。一般情况下,遵守了前三种范式,数据库的设计就没有什么问题了

2、分类

第一范式(1NF):每一列都是不可分割的原子数据项。

第二范式(2NF):在1NF的基础上,非码属性必须完全依赖于码(在1NF基础上消除非主属性对主码的部分函数依赖)。

第三范式(3NF):在2NF基础上,任何非主属性不依赖于其它非主属性(在2NF基础上消除传递依赖)。

由于系这一列可以分割为两列,故不满足每一列都是不可分割的原子数据项的要求。修改如下就变成原子列了。

如上,遵循了第一范式。第一范式是数据库设计表的基本要求,所有的表都遵循第一范式。

存在的问题:

(1)、存在非常严重的数据冗余。

(2)、数据添加存在问题,如果现在新增了一个系,如计算机系,数据不合法。如下所示:

(3)、数据删除存在问题,张无忌同学毕业了,删除数据时,会将系得数据一起删除。

上述三个问题导致数据库的设计不合适。

3、几个概念

1)、函数依赖:A-->B,如果通过A属性(属性组)的值,可以确定唯一B属性的值。则称B依赖于A。

例如:学号-->姓名。  

2)、完全函数依赖:A-->B, 如果A是一个属性组,则B属性值的确定需要依赖于A属性组中所有的属性值

例如:(学号,课程名称) --> 分数

3)、部分函数依赖:A-->B, 如果A是一个属性组,则B属性值得确定只需要依赖于A属性组中某一些值即可。

例如:(学号,课程名称) -- > 姓名

4)、传递函数依赖:A-->B, B -- >C . 如果通过A属性(属性组)的值,可以确定唯一B属性的值,再通过B属性(属性组)的值可以确定唯一C属性的值,则称 C 传递函数依赖于A

例如:学号-->系名,系名-->系主任

5)、:如果在一张表中,一个属性或属性组,被其他所有属性所完全依赖,则称这个属性(属性组)为该表的码

学号没有被其他所有属性依赖,因为不能通过学号属性确定唯一的其他属性,因为通过学号不能确定唯一的分数,所以码为学号和课程名称。

第二范式要消除部分依赖,由于分数是完全依赖于码(学号和课程名称),而姓名、系名、系主任只依赖于学号,故是部分依赖。

现在需要做表的拆分

分数(非主属性)完全依赖与码(学号和课程名称),这样,非主属性完全依赖于主属性。

学号为主属性,姓名、系名、系主任完全依赖学号。

例如:该表中码为:(学号,课程名称)

主属性:码属性组中的所有属性。

非主属性:除过码属性组的属性。

现在虽然解决了非常严重的数据冗余,但是数据添加和数据删除都存在问题。张无忌毕业了会将系的数据一起删除。

第三范式可以解决上述问题。第三范式消除传递依赖。

学生表中,现在姓名和系名完全依赖与学号,不存在传递依赖。

系表中,系主任完全依赖于系名。

现在的三种表遵循第三范式。解决了添加数据的问题,即在系表中添加系名(计算机系)和系主任没有问题。也解决了删除数据的问题,张无忌毕业了,经济学仍然被保留着。

在实际工作中,应用这些范式来验证你设计的表是否合理。

posted on 2022-01-03 12:18  周文豪  阅读(173)  评论(0编辑  收藏  举报