数据库基础

zdb呀

已于 2024-05-21 16:12:46 修改

阅读量378

点赞数 3

分类专栏： # MySQL 文章标签：数据库 mysql

于 2024-04-08 20:16:33 首次发布

本文链接：https://blog.csdn.net/qq_39236499/article/details/137522377

版权

MySQL 专栏收录该内容

18 篇文章 2 订阅

订阅专栏

文章目录

1. 数据库、数据库管理系统、数据库系统、数据库管理员

数据库：DataBase，DB，就是信息的集合，或者说数据库是由数据库管理系统管理的数据的集合。
数据库管理系统：DataBase Management System，DMS，是一种操纵和管理数据库的大型软件，通常用于建立、使用和维护数据库。
数据库系统：Data Base System，DBS，由软件、数据库和数据库管理员组成。
数据库管理员：DataBase Administrator，负责全面管理和控制数据库系统。

2. 元组、码、候选码、主码、外码、主属性、非主属性

元组：是关系数据库的基本概念，关系是一张表，表中的每行（即数据库中的每条记录）就是一个元组，每列就是一个属性。在二维表中，元组也称为行。
候选码：若关系中的某一属性或属性组的值能唯一的标识一个元组，而其任何子集都不能再标识，则称该属性组为候选码。例如：在学生实体中，“学号”是能唯一的区分学生实体的，同时又假设“姓名”、“班级”的属性组合足以区分学生实体，那么{学号}和{姓名，班级}都是候选码。
主码：也叫主键，主码是从候选码中选出来的。一个实体集中只能有一个主码，但可以有多个候选码。
外码：也叫外键。如果一个关系中的一个属性是另外一个关系中的主码，则这个属性为外码。
主属性：候选码中出现过的属性成为主属性。比如关系工人（工号，身份证，姓名，性别，部门），显然工号和身份证号都能唯一标识这个关系，所以都是候选码。工号、身份证这两个属性就是主属性。如果主码是一个属性组，那么属性组中的属性都是主属性。
非主属性：不包含在任何一个候选码中的属性称为非主属性。比如在关系学生（学号，姓名，年龄，性别，班级）中，主码是“学号”，那么其他的“姓名”、“年龄”、“性别”、“班级”就都可以称为非主属性。

3. ER图

Entity Relationship Diagram，实体联系图，提供了表示实体类型、属性和联系的方法。

ER图由3个要素组成：

实体：通常是现实世界的业务对象，当然使用一些逻辑对象也可以。比如对于一个校园管理系统，会涉及学生、教师、课程、班级等等实体。在ER图中，实体使用矩形框表示。
属性：即某个实体拥有的属性，属性用来描述组成实体的要素，对于产品设计来说可以理解为字段。在ER图中，属性使用椭圆形表示。
联系：即实体与实体之间的关系，在ER图中用菱形来表示，这个关系不仅有业务联系关系，还能通过数字表示实体之间的数量对照关系。例如，一个班级会有多个学生就是一种实体间的联系。

下图是一个学生选课的 ER 图，每个学生可以选若干门课程，同一门课程也可以被若干人选择，所以它们之间的关系是多对多（M: N）。另外，还有其他两种实体之间的关系是：1 对 1（1:1）、1 对多（1: N）。
在这里插入图片描述

4. 数据库范式

数据库设计范式：数据库表的设计依据。

第一范式：要求任何一张表必须有主键，每一个字段原子性不可再分。
第二范式：建立在第一范式的基础之上，要求所有非主键字段完全依赖主键，不要产生部分依赖。
第三范式：建立在第二范式的基础之上，要求所有非主键字段直接依赖主键，不要产生传递依赖。

按照以上范式设计数据库表，可以避免表中数据的冗余，空间的浪费。

第一范式

最核心，最重要的范式，所有表的设计都需要满足。
必须有主键，并且每一个字段都是原子性不可再分。

学生编号 	学生姓名 		联系方式
------------------------------------------
1001		张三		zs@gmail.com,1359999999
1002		李四		ls@gmail.com,13699999999
1001		王五		ww@163.net,13488888888

上表不满足第一范式

原因：第一，没有主键；第二，联系方式可以分为邮箱地址和电话：

学生编号(pk)		 学生姓名		邮箱地址		 联系电话
---------------------------------------------------------
1001				张三		 zs@gmail.com	 1359999999
1002				李四		 ls@gmail.com	 13699999999
1003				王五		 ww@163.net		 13488888888

第二范式

建立在第一范式的基础之上，要求所有非主键字段必须完全依赖主键，不要产生部分依赖

学生编号	学生姓名   教师编号  教师姓名
----------------------------------------------------
1001		张三		001		王老师
1002		李四		002		赵老师
1003		王五		001		王老师
1001		张三		002		赵老师

多对多关系！（1个学生可能有多个老师，1个老师有多个学生）

上表满足第一范式；修改

学生编号教师编号，两个字段联合做主键，复合主键（PK: 学生编号+教师编号）

学生编号+教师编号(pk)		学生姓名  		教师姓名
----------------------------------------------------
1001		001			  张三			王老师
1002		002			  李四			赵老师
1003		001			  王五			王老师
1001		002			  张三			赵老师

上表不满足第二范式：张三”依赖1001，“王老师”依赖001，显然产生了部分依赖。

修改：使用三张表来表示多对多的关系

学生表

学生编号(pk)		学生名字
------------------------------------
  1001				张三
  1002				李四
  1003				王五
		

教师表

教师编号(pk)		 教师姓名
--------------------------------------
	001				王老师
	002				赵老师

学生教师关系表

id(pk)			学生编号(fk)			教师编号(fk)
------------------------------------------------------
1					1001					001
2					1002					002
3					1003					001
4					1001					002

总结：多对多设计，三张表，关系表两个外键！

第三范式

第三范式建立在第二范式的基础之上，要求所有非主键字典必须直接依赖主键，不要产生传递依赖。

学生编号（PK） 学生姓名 	  班级编号  	 班级名称
---------------------------------------------------------
 1001		  张三		01			一年一班
 1002		  李四		02			一年二班
 1003		  王五		03			一年三班
 1004		  赵六		03			一年三班

1对多关系！（一个教室中有多个学生）

满足第一范式，有主键（学生编号）。
满足第二范式，因为主键不是复合主键，没有产生部分依赖。主键是单一主键。

不满足第三范式：一年一班依赖01，01依赖1001，产生了传递依赖。

修改：

班级表：一

班级编号(pk)			班级名称
----------------------------------------
 01						一年一班
 02						一年二班
 03						一年三班

学生表：多

学生编号（PK） 	 学生姓名 		班级编号(fk)
-------------------------------------------
 1001				张三			01			
 1002				李四			02			
 1003				王五			03			
 1004				赵六			03