数据库学习第三天
今日内容
1 主键约束以及自动增长
2 外键约束
3 数据库的设计
4.范式
5.数据库的备份和恢复
主键约束以及自动增长
主键约束:primary key。
1 注意:
(1). 含义:非空且唯一
(2). 一张表只能有一个字段为主键
(3). 主键就是表中记录的唯一标识
2 在创建表时,添加主键约束如:create table stu(id int primary key,name varchar(30));
3 删除主键
– 错误写法: alter table stu modify id int ;
正确写法:ALTER TABLE stu DROP PRIMARY KEY;
(和之前删除唯一约束一样,不是正常的语句)
4 创建完表后,添加主键:ALTER TABLE stu MODIFY id INT PRIMARY KEY;
5 自动增长:
(1) 概念:如果某一列是数值类型的,使用 auto_increment 可以来完成值的自动增长
(2)在创建表时,添加主键约束,并且完成主键自增长:create table stu(id int primary key auto_increment,name char(20));
(3)删除自动增长:ALTER TABLE stu MODIFY id INT;
(4) 添加自动增长:ALTER TABLE stu MODIFY id INT AUTO_INCREMENT;
(一般来说自动增长都是在创建主键的时候和主键一同使用的。这种用法不常见。)
外键约束
外键约束:foreign key,让表和表之间产生关系,从而保证数据的正确性。
比如表一是员工表,其中每个员工都有自己的部门编号,又创建了一个表叫做部门表,其中有每个部门编号对应的部门名称,如果给员工表中的部门编号添加一个在部门表中找不到的部门编号,就会报错来保证你添加的数据的正确性,另外这时候如果某个部门被删除了,这时候原本员工表中的该部门编号就没有意义了,因此可以添加级联删除,保证删除的时候原本员工表中的部门编号也得到考虑,在删除部门数据的时候会将员工表中的数据也一并得到删除,来保证数据的正确性,如果没有添加,系统就不会允许你删除,另外当部门表中的某个部门的编号得到更新之后,原来员工表中的数据也行该得到更新,这时候可以使用级联更新来保证该功能的实现,如果没有添加,系统就不会允许你更新。
-
在创建表时,可以添加外键
* 语法:create table 表名( .... 外键列, constraint 外键名称 foreign key (外键列名称) references 主表名称(主表列名称) );
-
删除外键
:ALTER TABLE 表名 DROP FOREIGN KEY 外键名称;
-
创建表之后,添加外键:
ALTER TABLE 表名 ADD CONSTRAINT 外键名称 FOREIGN KEY (外键字段名称) REFERENCES 主表名称(主表列名称);
这里有一点需要注意连接外键的时候主表也就是上例中的部门表中的被连接的列必须设置唯一约束,不然就会报错外键的级联操作
- 添加级联操作
语法:ALTER TABLE 表名 ADD CONSTRAINT 外键名称 FOREIGN KEY (外键字段名称) REFERENCES 主表名称(主表列名称) ON UPDATE CASCADE ON DELETE CASCADE
;
2. 分类:
1. 级联更新:ON UPDATE CASCADE
2. 级联删除:ON DELETE CASCADE
- 添加级联操作
数据库的设计
数据库的设计
- 多表之间的关系
数据库的设计主要就是去掌握以下关系分类知道每种分类下怎么建表
1. 分类:
1. 一对一(了解):
* 如:人和身份证
* 分析:一个人只有一个身份证,一个身份证只能对应一个人
2. 一对多(多对一):
* 如:部门和员工
* 分析:一个部门有多个员工,一个员工只能对应一个部门
3. 多对多:
* 如:学生和课程
* 分析:一个学生可以选择很多门课程,一个课程也可以被很多学生选择 - 实现关系:
-
一对多(多对一):
* 如:部门和员工
* 实现方式:在多的一方建立外键,指向一的一方的主键。
* -
多对多:
* 如:学生和课程
* 实现方式:多对多关系实现需要借助第三张中间表。中间表至少包含两个字段,这两个字段作为第三张表的外键,分别指向两张表的主键。
*
3. 一对一(了解):
* 如:人和身份证
* 实现方式:一对一关系实现,可以在任意一方添加唯一外键指向另一方的主键。
*
但是实际上我们可以直接将右边的表和左边的表进行合并。没必要弄成两个表,然后用外键连接,只不过是徒增麻烦了。
-
数据库设计的范式
-
数据库设计的范式
* 概念:设计数据库时,需要遵循的一些规范。要遵循后边的范式要求,必须先遵循前边的所有范式要求设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。
目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。- 分类:
-
第一范式(1NF):每一列都是不可分割的原子数据项
也就是说这种某一列下面还可以再分的情况不出现就满足了一范式。(表中的系可以再分)
这样就满足了一范式,但是它有图上所说的三种严重的问题,这时候使用二范式。这里可以看到学号和课程名称合并起来称为码,但是姓名,系名,系主任,是部分依赖与学号的,分数是完全依赖于学号和课程名称的,因此要对表进行拆分 -
第二范式(2NF):在1NF的基础上,非码属性必须完全依赖于码(在1NF基础上消除非主属性对主码的部分函数依赖)
* 几个概念:
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. 码:如果在一张表中,一个属性或属性组,被其他所有属性所完全依赖,则称这个属性(属性组)为该表的码
例如:该表中码为:(学号,课程名称)
* 主属性:码属性组中的所有属性
* 非主属性:除过码属性组的属性
*
可以看到我们拆成了两张表,选课表和学生表,其中选课表中的学号和课程组成码,分数完全依赖于该码,学生表中姓名,系名,系主任也都完全依赖与学号,要解决后面两个问题就要使用三范式,这里可以看到系名依赖于学号,系主任又依赖于系名,因此产生了传递依赖,只要把这个传递依赖给处理掉,就可以完成三范式的构成。 -
第三范式(3NF):在2NF基础上,任何非主属性不依赖于其它非主属性(在2NF基础上消除传递依赖)
这时候只要再拆分出来一张表就解决了传递依赖,成功达成三范式!
数据库的备份和恢复
-
命令行:
* 语法:
* 备份: mysqldump -u用户名 -p密码 数据库名称 > 保存的路径。如:
*
不要登陆了之后再备份哦,要直接在没登陆mysql的时候进行备份
* 还原:
1. 登录数据库
2. 创建数据库(这里也可以创建不同名字的库,这时候备份成功之后数据还是一样写进去)
3. 使用数据库
4.执行命令:source 文件路径如:
- 图形化工具: