数据库设计

时间：2020-05-17 00:46:55 阅读：85 评论：0 收藏：0 [点我收藏+]

标签：员工上架就是 email 一个名称表之间 mamicode 传递

一、多表关系介绍

1.多表之间具有哪些关系?

一对一关系
- 例:人和身份证
  - 一个人只能有一张身份证,一张身份证只能对应一个人.
一对多/多对一关系
- 例:部门和员工
- 一个员工只能对应一个部门,一个部门可以对应多个员工.
多对多
- 例:学生与课程
- 一门课程可以被多个学生选择,一个学生可以选择多门课程.

2.多表关系一对多关系实现

在多的一方建立外键,指向一的一方的主键.

3.多表关系-多对多关系实现

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

4.多表关系一对一关系实现

一对一关系的实现,可以在任意一方添加唯一外键指向另一方的主键.

5.多表关系案例

案例分析
- 线路分类、线路、用户的关系
  - 一个线路分类可以有多条旅游线路（1--n）
  - 一个用户可以选择多条旅游线路，一个旅游线路可以被多个用户收藏（n--m）
    - 需要中间表，来存储两个表的主键

示例代码

 -- 创建旅游线路分类表 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)
 );

二、范式概述

范式就是设计数据库时需要遵循的一些规范.
设计关系型数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范被称为不同的范式,各种范式呈递归规范,越高的范式数据冗余越小.
范式的分类
- 第一范式(INF)
- 第二范式(2NF)
- 第三范式(3NF)
- 巴斯-科德(BCNF)
- 第四范式(4NF)
- 第五范式(5NF[完美范式]
总结
- 一般数据库的设计负责第三范式即可,数据库符合的范式越高,代表表越多,表越多代表表之间的关系越复杂,虽然符合的范式高,但是不利于SQL语句的书写.
- 要求越高，表越复杂，表越复杂，查询效率越低。为了提高效率，数据可以存在一定的冗余。