简介这套《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树还是哈希索引才是物理模型层面的事。三层模型我用一张表做了对照整理方便拿课件片段做笔记模型层次面向对象关注内容典型产物概念模型用户、设计人员实体、属性、联系E-R图逻辑模型用户、数据库系统数据结构、数据操作、完整性约束关系模式、表结构物理模型DBMS、操作系统、硬件存储结构、索引、聚集建表语句、索引设计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都快。我按教学需要把这些信息整理成一张选型对照表数据库核心特点典型场景学习成本AccessJet引擎驱动向导化操作小型企业、个人桌面应用低SQL Server版本分层与Windows生态绑定中大型企业应用中高Oracle分布式能力海量数据与高可靠性大型企业核心业务高MySQL开源免费体积小速度快中小型网站、互联网应用低SQLite嵌入式资源占用极低嵌入式设备、移动端低这套对比表也是面试常被追问的“数据库选型”问题的起点。我的判断标准很朴素并发规模几十到几百的中小型应用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生成空密码省去了找临时密码的麻烦学习环境里最高效生产环境则改用--initializeMySQL会随机生成一个临时密码写到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-30MySQL在默认配置下会照单全收具体原因和处理方法下面专门讲。5. 课件自学避坑五个拿着PPT翻车的高频问题PPT课程最大的问题是概念讲得清楚但没告诉你真实环境里哪些地方会反常识地出错。下面五个坑是我在教学和项目维护中反复遇到的每一条都按“现象→原因→解决”拆开说。这些坑课件里基本都没提但你不踩一遍后面做项目时迟早要交学费。5.1 非法日期居然能写进DATE字段现象照着课件里的学生表录入数据把出生日期写成1999-02-30INSERT成功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 rootlocalhost。命令行下用mysql -u root -p却能正常登录说明密码没错问题出在连接工具和认证方式上。原因MySQL 8默认使用caching_sha2_password认证插件而老客户端和驱动只支持mysql_native_password。5.7及之前的老版本没有这个问题所以网上一搜全是老方案对不上号。解决先把root密码玩明白再用ALTER USER切换认证ALTER USER rootlocalhost 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-setutf8mb4 school data.sql逻辑说明--default-character-setutf8mb4让客户端以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但把它当作训练场反而比直接上手项目更不易漏概念。希望帮到你。本文还有配套的精品资源点击获取