MySQL课件精讲：从E-R图到候选码的数据库设计核心

简介：这套《MySql数据库原理及应用》课件汇总共1个文件（pptx格式），压缩包大小13.29MB，覆盖整本教材的教学内容。资源面向数据库初学人员、高校师生及自学MySQL的读者，系统讲解数据库系统基础知识与MySQL应用实践，包括数据模型、E-R图、关系模型、DDL/DML/DCL等核心概念，并对比Access、Oracle、SQL Server、MySQL、SQLite等常见数据库管理系统，能帮助学习者建立完整知识框架。课件以任务驱动方式组织，如“体验数据库的应用”“掌握数据库系统的基本概念”“使用MySQL”等，结构清晰，便于课堂讲授或自主复习。已有122人学习该资源，适合作为备课参考、考试复习或MySQL入门使用的实用教学资料。

1. 一套MySQL课件能解决什么：别把数据库入门背成概念

我最早下载《MySql数据库原理及应用课件汇总整本书电子教案全套课件完整版ppt教学教程.pptx》时，以为它就是一份普通的课堂演示文档，直到完整过了一遍才发现，它的价值是把数据库入门最绕的几个概念——数据模型、E-R图、关系模型、候选码与主码——按教学节奏排好了。很多人学MySQL卡住，不是SQL写不溜，而是搞不清一张业务表到底是怎么从现实世界抽象出来的。这份课件恰好补的就是这一段。它从任务1-1到任务1-3，先对比Access、Oracle、SQL Server、MySQL、SQLite五类数据库，再拆解数据模型三层抽象，最后落到关系模型的字段级概念。适合零基础学生、转行自学者，也适合要快速备课的讲师直接改用自己的教学素材。

2. 数据模型的三层抽象：为什么说E-R图是数据库设计的起点

课件任务1-2开头就抛出一个容易让人犯困的问题：数据模型分概念模型、逻辑模型和物理模型三层。很多初学者觉得这是纯理论，跳过不看，结果后面画E-R图、定主键、建索引全在踩坑。实际上这三层就是数据库设计的完整映射链：概念模型回答“业务里有什么”，逻辑模型回答“怎么用表表达”，物理模型回答“表怎么存下来”。一个实体从现实世界走进数据库，必然要穿过这三层。

2.1 概念模型：现实世界的第一层抽象

概念模型的定义是：表示实体类型及实体间的联系，独立于计算机系统。它强调语义表达，要求概念简单、清晰，便于用户和数据库设计人员之间交流。注意“独立于计算机系统”这七个字——它不关心你最后用MySQL还是Oracle，不关心字段长度，不关心索引怎么建，只关心业务里有哪些实体、这些实体之间是什么关系。

课件里举了两张E-R图：班级学生E-R图、课程学生E-R图。前者是1:N关系，一个班级有多个学生；后者是M:N关系，一个学生选多门课程，一门课程被多个学生选。这两张图放在一起，其实在提醒一个关键问题：联系本身是否携带属性。学生“属于”班级这个联系没有属性，但学生“选”课程这个联系有“成绩”这个属性——成绩既不属于学生，也不属于课程，它属于“选课”这件事。这是初学画E-R图最容易忽略的地方。

我一般会用一个四步清单辅助识别实体：谁在参与业务？它有哪些稳定属性？它和其他实体有没有联系？联系有没有属于自己的属性？拿“学生选课”场景走一遍：学生（学号、姓名、性别、出生日期、专业），课程（课程号、课程名、学分），联系是“选课”，属性是“成绩”。这个清单列完，概念模型基本就成型了。

注意：联系属性不能挂到任意一侧实体上，否则后面转关系模式时会漏字段。成绩一旦挂到学生表里，一个学生选多门课就没法存。

2.2 逻辑模型与物理模型：分层不是教学套路

课件明确指出，逻辑数据模型主要有网状模型、层次模型和关系模型三种，它既要面向用户，也要面向系统。层次模型用树结构表达数据关系，网状模型用图结构，关系模型用二维表。放在今天的工程语境里，绝大多数业务系统用的都是关系模型；少部分特殊场景会用文档型或图数据库，那是另一套建模思路，课件里的层次和网状模型现在更多是历史沿革作用，理解即可。

物理模型则与具体的数据库管理系统、操作系统和硬件相关。课件有个说法很实在：DBMS为了保证独立性和可移植性，把大部分物理实现工作交给系统自动完成，设计者只需要设计索引、聚集等特殊结构。这意味着你平时建表时写的字段类型和主键，更多属于逻辑模型范畴；而索引落在哪个存储引擎、用B+树还是哈希索引，才是物理模型层面的事。

三层模型我用一张表做了对照整理，方便拿课件片段做笔记：

2.3 E-R图符号与落地画法

课件给出了标准E-R图画法：矩形框表示实体型，框内写实体名；椭圆形框表示属性，用无向边连接实体和属性；菱形框表示联系，框内写联系名，用无向边连接菱形框和有关实体，在边旁注明联系类型1:1、1:N或M:N。如果联系本身有属性，也把属性和菱形框用无向边连起来。这套符号体系是1976年P.P.Chen提出的E-R模型，到今天仍然是数据库设计沟通的通用语言。

画E-R图的顺序不要跳：先定实体，再定属性，然后画联系，最后标注基数。反着来的后果是属性满天飞，等转关系模式时找不到实体边界。以课程学生场景为例，完整走一遍：实体是“学生”和“课程”；学生属性有学号、姓名、性别、出生日期、专业，课程属性有课程号、课程名、学分；联系是“选课”，类型M:N；联系属性是“成绩”。其中学号和课程号分别作为两侧实体的标识属性，这个标识属性就是下一章候选码的雏形。

注意：E-R图里联系基数的标注要精确到业务含义。一个学生选几门课、一门课被几个学生选，必须回到真实业务里去问，不能拍脑袋。基数标错，后面拆表方案全错。

3. 关系模型拆到字段级：候选码、主码与关系模式的落地理解

课件在讲完概念模型后，直接进入关系模型的术语细节。这一段看上去像名词解释，实际上是你设计表结构的所有理论依据：表为什么能唯一辨识一行？主键为什么不能随意用复合字段？关系模式怎么写才能让建表不返工？把这些术语落到一张具体的学生表上，比背定义有用得多。

3.1 从二维表说起：关系、元组、属性、域和分量

关系模型里，一个关系就是一张二维表。课件给了一张学生表，包含姓名、性别、出生日期、专业和学号。这五个术语要能对着表指认出来：

属性的型和值要分开理解。型的层面是属性名和值域，比如“性别”的域是“男/女”，值的层面是具体某个学生填了“男”还是“女”。课件表格里有个细节值得注意：出生日期写的是1999-02-30，这显然是不存在的日期，但它展示了“型”和“值”的偏差——值域定义了取值范围，不代表录入的数据就一定合法。这个坑在第五章节会详细展开。

这里还要明确关系和关系模式的区别：关系模式是型，是“对关系的描述”，通常写成关系名（属性1，属性2，…，属性n）；关系是值，是实际存进去的数据集合。同样一张学生表结构，可以存入不同年级的学生数据，结构不变，数据在变。

3.2 候选码与主码：为什么码是关系模型的命门

候选码的定义有两个要点：一是属性或属性组的值能唯一标识一个元组，二是从这个属性组中去掉任何一个属性后，它就不再具有唯一标识能力。第二个要点叫作“最小性”，是新手最容易忽略的约束条件。

拿学生表举例：学号本身能唯一标识一名学生，去掉学号不行，所以学号是候选码。姓名呢？重名概率太高，不满足唯一性，不是候选码。如果把（学号，姓名）作为组合，它能唯一标识元组，但去掉姓名仍然唯一，不满足最小性，所以它不是候选码。很多自学者翻车就翻在这里：看到组合键能定位到行，就直接当主键用，完全没做“去掉一个属性再试一次”的验证。

课件还引入了全码的概念：最极端情况下，关系模式的所有属性共同组成候选码，这就是全码。最典型的例子是只有两个属性的选课表（学号，课程号），候选码就是全部属性。主属性是候选码中的属性，非主属性是不包含在候选码中的属性。比如选课表里学号和课程号都是主属性，如果加一个“成绩”字段，成绩就是非主属性。

3.3 关系模式的写法与建表转换

关系模式的书面写法有固定规范：关系名后跟括号括起的属性列表，主码属性加下划线标注。例如：

• 学生（学号，姓名，性别，出生日期，专业）
• 课程（课程号，课程名，学分）
• 选课（学号，课程号，成绩）

下划线标的是主码，也就是最终建表时的主键。从E-R图转关系模式有一条通用规则：1:1联系可以并入任意一侧实体，1:N联系在N侧实体中加入1侧实体的主码作为外键，M:N联系必须单独拆成一张中间表，联系自身的属性全部放进中间表。课程学生场景就是标准M:N，选课表同时承接学号、课程号和成绩三个字段。

课件是PPT格式，没法直接演示建表，我在自学或备课时会补一个验证脚本，把关系模式落成真正的MySQL表结构：

CREATE TABLE student ( stu_id CHAR(10) PRIMARY KEY, stu_name VARCHAR(20) NOT NULL, gender CHAR(1), birth_date DATE, major VARCHAR(50) );

逻辑说明：stu_id是主码，选CHAR定长类型是因为学号长度固定，用VARCHAR反而让存储多一个长度前缀；stu_name用VARCHAR和NOT NULL，姓名不允许为空；birth_date用DATE类型，方便后面做日期运算和排序。这一步是把“关系模式”翻译成“物理表”的必经路径，也是检验你前面概念有没有真正理解的最好方式。

4. 从Access到MySQL：选型逻辑与一套可复现的上手路线

课件任务1-1做了件容易被低估的事：把Access、Oracle、SQL Server、MySQL、SQLite五个数据库全部摆出来过了一遍。表面看是在做名词介绍，实际上这是教学场景里很聪明的选型铺垫——让初次接触数据库的人知道，MySQL不是唯一选择，但它是入门成本最低的那一个。

4.1 五种数据库放在一起比：课件第一课其实是一张选型清单

课件对每个数据库的定位讲得很明确。Access以Microsoft Jet数据库引擎为核心，跟随Office默认安装就能用，适合小型企业桌面应用，对初学者非常友好；Oracle是当前使用最广泛的关系数据库之一，强调数据大量性、持久性、共享性和可靠性，适合处理海量数据的大型企业；SQL Server当时分企业版、标准版和工作组版，版本分层清晰，面向Windows生态；MySQL开源、体积小、速度快、使用灵活，很多中小型网站选它做后台；SQLite是嵌入式数据库，几百K内存就能跑，处理速度甚至比MySQL和PostgreSQL都快。

我按教学需要把这些信息整理成一张选型对照表：

这套对比表也是面试常被追问的“数据库选型”问题的起点。我的判断标准很朴素：并发规模几十到几百的中小型应用，MySQL是最稳选择；嵌入式离线场景，SQLite优先；大型企业核心交易系统，Oracle或云数据库托管更靠谱；过分迷信“大库一定更强”反而会把简单项目拖进高运维成本的坑。

4.2 MySQL上手路线：安装与登录的常见做法

课件里“使用MySQL”的任务对安装细节讲得比较概括，我在实际教学中通常会补上下面这套操作，否则新手第一步就卡在环境上。安装MySQL社区版，选当前LTS版本即可，注意不要和MySQL企业版混淆。Windows环境常见的坑是服务注册失败和3306端口被占用，Linux环境则要区分是用的源码包、rpm包还是Docker镜像，三种方式的问题表现完全不同。

# 以源码包为例的初始化与启动，Windows 和 Linux 通用 mysqld --initialize-insecure # 初始化，root 初始密码为空，适合学习环境 mysqld --install # Windows 下注册为系统服务 net start mysql # 启动服务 mysql -u root -p # 登录，提示输密码时直接回车

逻辑说明：--initialize-insecure会让root生成空密码，省去了找临时密码的麻烦，学习环境里最高效；生产环境则改用--initialize，MySQL会随机生成一个临时密码写到data目录下的日志文件中，登录后必须立刻改密码。--install在Linux下不适用，Linux通常用systemctl start mysqld。如果是Docker方式，还要注意端口映射和数据卷挂载，容器删了数据就没了，这是另一个高频翻车点。

登录成功后，先建库建表，把字符集问题在源头掐死：

CREATE DATABASE school DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE school; CREATE TABLE student ( stu_id CHAR(10) PRIMARY KEY, stu_name VARCHAR(20) NOT NULL, gender CHAR(1), birth_date DATE, major VARCHAR(50) );

逻辑说明：CREATE DATABASE时显式指定utf8mb4字符集，而不是依赖MySQL默认配置，这一步能避免后续大量中文乱码问题；utf8mb4是UTF-8的超集，能正确存emoji和生僻字。COLLATE选general_ci，排序规则够用不做区分大小写比较。

4.3 增删改查：先练四条DML，再谈DDL和DCL

课件区分了数据库语言的三类：DDL定义结构、DML操作数据、DCL控制权限。实际练习时我会让学员先死磕四条DML，因为它们对应业务里最高频的操作——插入、查询、更新、删除。在命令行环境下写完再拿去和图形工具对比，你会发现GUI工具容易把SQL语法错误过滤掉，不利于建立实时反馈。

INSERT INTO student VALUES ('20201061', '张三', '男', '1999-02-30', '计算机技术'); SELECT * FROM student WHERE major = '计算机技术'; UPDATE student SET major = '计算机应用' WHERE stu_id = '20201061'; DELETE FROM student WHERE stu_id = '20201061';

逻辑说明：INSERT是写入一条完整元组，字段顺序要和表结构一致；UPDATE和DELETE必须带WHERE条件，否则就是全表更新、全表删除——这是初学者最容易造成事故的操作，我见过不止一次有人把UPDATE漏掉WHERE导致整张表数据被改坏。上面日期值故意写了一个不存在的1999-02-30，MySQL在默认配置下会照单全收，具体原因和处理方法下面专门讲。

5. 课件自学避坑：五个拿着PPT翻车的高频问题

PPT课程最大的问题是：概念讲得清楚，但没告诉你真实环境里哪些地方会反常识地出错。下面五个坑是我在教学和项目维护中反复遇到的，每一条都按“现象→原因→解决”拆开说。这些坑课件里基本都没提，但你不踩一遍，后面做项目时迟早要交学费。

5.1 非法日期居然能写进DATE字段

现象：照着课件里的学生表录入数据，把出生日期写成1999-02-30，INSERT成功，SELECT也能查出来，没有任何报错。等到做年龄计算或按生日排序时，结果全乱。

原因：MySQL在默认sql_mode非严格模式下，不校验DATE类型的日期合法性。课件里那张示例表本身就有这个脏数据，初学者照着录，MySQL只负责存进去，不负责判断日期是否真实存在。

解决：建库前设置严格模式，让MySQL对非法日期说“不”：

SET SESSION sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY';

如果你用的是MySQL 8.0.16以上版本，还可以用CHECK约束兜底：

CREATE TABLE student ( birth_date DATE, CONSTRAINT chk_birth CHECK (birth_date >= '1900-01-01' AND birth_date <= CURDATE()) );

逻辑说明：STRICT_TRANS_TABLES把非法日期从“警告后写入”提升为“直接报错”；NO_ZERO_DATE和NO_ZERO_IN_DATE禁止'0000-00-00'这类零值。CHECK约束在8.0.16之前会被解析但不会强制执行，很多老教程没更新这一点，照抄后以为有约束实际没有。

注意：课件表格里的教学数据不等于可用的样例数据。凡是动手建库，先把脏数据清一遍再导入。

5.2 候选码没做最小性验证，联合主键建错

现象：设计学生表时，觉得学号加姓名最保险，设成UNIQUE KEY甚至主键。等到入库时发现，姓名有重名，学号正常，但复合唯一约束把本该存进来的数据挡在门外；或者反过来，只设了主键没加唯一约束，业务上真正唯一的单号重复入库了。

原因：对候选码的“最小性”理解不到位。复合键（学号，姓名）去掉姓名依然唯一，它不满足候选码定义，本不该被当作候选码使用。

解决：建表前把所有可能的唯一属性列出来，逐个做“去掉一个再验唯一性”的测试。学号能单独标识，就定学号为主键，姓名重名风险高，不用管它。如果有备用唯一键，比如身份证号，可以用UNIQUE约束加上：

CREATE TABLE student ( stu_id CHAR(10) PRIMARY KEY, id_card CHAR(18) UNIQUE, stu_name VARCHAR(20) NOT NULL );

逻辑说明：这里主键和UNIQUE键并不冲突，主键保证系统内标识稳定，UNIQUE键保证业务上不允许重复。两者分开设计，比强行做成复合主键干净得多。

5.3 MySQL 8连接不上：认证插件不兼容

现象：用Navicat、DBeaver或老版本JDBC驱动连接MySQL，报错信息类似Authentication plugin 'caching_sha2_password' cannot be loaded，或者Access denied for user 'root'@'localhost'。命令行下用mysql -u root -p却能正常登录，说明密码没错，问题出在连接工具和认证方式上。

原因：MySQL 8默认使用caching_sha2_password认证插件，而老客户端和驱动只支持mysql_native_password。5.7及之前的老版本没有这个问题，所以网上一搜全是老方案，对不上号。

解决：先把root密码玩明白，再用ALTER USER切换认证：

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码'; FLUSH PRIVILEGES;

逻辑说明：IDENTIFIED WITH指定认证插件，mysql_native_password是兼容性最好的老插件；FLUSH PRIVILEGES刷新权限表让修改立即生效。从安全角度讲，如果客户端都支持caching_sha2_password就不必切换，项目里优先考虑客户端兼容性再决定。

5.4 Excel导入MySQL中文全部变成问号

现象：把Excel里的中文数据导入MySQL后，SELECT出来全是??????，表字段注释也乱码。更气人的是，只有部分是问号，另一部分正常，数据看起来像被“咬了一口”。

原因：字符集链路不一致。Excel或CSV另存为时默认编码是GBK/ANSI，而MySQL表是utf8mb4，两边各说各话。图形工具导入时如果没指定源文件编码，就会把GBK字节按UTF-8解释，中文直接变成乱码。

解决：统一字符集链路，CSV先另存为UTF-8编码，再通过命令行导入并显式指定字符集：

mysql -u root -p --default-character-set=utf8mb4 school < data.sql

逻辑说明：--default-character-set=utf8mb4让客户端以UTF-8语义处理输入文件，前提是文件本身已经是UTF-8编码。Excel另存为CSV时有个暗坑：它经常默认存成带BOM的UTF-8，或直接存成ANSI，导入前先用文本编辑器确认编码格式。我的习惯是：凡是涉及CSV导入，第一步永远是检查编码和分隔符。

5.5 M:N联系不拆中间表，选课数据越存越乱

现象：画完“课程学生E-R图”后直接建表，把课程名塞进学生表里加一列“已选课程”。一个学生选了三门课就得存三行，每次查这个学生的课程列表还要去重，成绩字段更没地方放。

原因：把M:N联系错误地当成了1:N。一个学生选多门课程、一门课程被多个学生选，这种双向多对多的关系，如果没有中间表承载，数据冗余和更新异常会同时爆发。

解决：严格按E-R图转换规则，M:N拆中间表，联系属性放中间表：

CREATE TABLE course ( course_id CHAR(10) PRIMARY KEY, course_name VARCHAR(50) NOT NULL, credit TINYINT ); CREATE TABLE sc ( stu_id CHAR(10), course_id CHAR(10), score TINYINT, PRIMARY KEY (stu_id, course_id), FOREIGN KEY (stu_id) REFERENCES student(stu_id), FOREIGN KEY (course_id) REFERENCES course(course_id) );

逻辑说明：sc表是“选课”联系落成的中间表，联合主键（stu_id, course_id）同时起到唯一约束和去重作用；score放在sc表里，表达的是“某学生某课程的成绩”这个联系属性。外键让数据库自行保证引用的学生和课程必须真实存在，这一步在课件里没有直接给出，但它是E-R图到关系模式转换的标准落点。

6. 把课件变成训练场：一次完整的E-R图到建库验证练习

课件看十遍不如动手做一遍。我拿“学生选课”当综合练习，把整份课件的核心知识点串成一条验证链路。

6.1 从一张E-R图到一个可验证的库

场景设定：学生选课，联系为M:N，联系属性是成绩。先写关系模式：学生（学号，姓名，性别，出生日期，专业），课程（课程号，课程名，学分），选课（学号，课程号，成绩）。注意选课表的主码是复合的，加下划线时两个属性都要标。

然后按父表先建、子表后建的顺序落成SQL脚本：

CREATE TABLE student ( stu_id CHAR(10) PRIMARY KEY, stu_name VARCHAR(20) NOT NULL, birth_date DATE ); CREATE TABLE course ( course_id CHAR(10) PRIMARY KEY, course_name VARCHAR(50) NOT NULL, credit TINYINT ); CREATE TABLE sc ( stu_id CHAR(10), course_id CHAR(10), score TINYINT, PRIMARY KEY (stu_id, course_id), FOREIGN KEY (stu_id) REFERENCES student(stu_id), FOREIGN KEY (course_id) REFERENCES course(course_id) );

脚本建完后做四个验证动作。第一，插入重复选课记录，联合主键应当报错，这验证候选码设计正确。第二，插入不存在学生的选课记录，外键应当拦截，这验证表间引用完整性。第三，用事务临时插入一条数据再回滚，验证事务边界：BEGIN; INSERT ...; ROLLBACK;，SELECT确认数据没留下。第四，如果你带学生做并发实验，两个事务同时插入同一个（学号，课程号）组合，会有一个事务进入锁等待或直接报死锁，这是InnoDB行锁机制在起作用——也就是热搜里常说的数据库死锁问题的真实来源。基础练完，后续再摸锁分类、事务隔离级别就有抓手了。

刚到项目组带新人时，我习惯直接扔官方文档，结果对方卡在环境三天，问下来才知道连主键选型都没概念。从那以后我每次拿到新的数据库课件，都强制自己先走一遍E-R图→关系模式→建表→插入脏数据测试的流程，确认这条链路能完整跑通再往下学。这套课件虽然只是PPT，但把它当作训练场反而比直接上手项目更不易漏概念。希望帮到你。

本文还有配套的精品资源，点击获取