MySQL数据库构建与管理 之 数据库设计概述.

Presentation on theme: "MySQL数据库构建与管理 之 数据库设计概述."— Presentation transcript:

1 MySQL数据库构建与管理 之 数据库设计概述

2 课程安排 学时分配： 32学时（上课）+32学时（上机） 考核： 平时成绩=作业20%+实践30%+考勤50%
总成绩=平时成绩60%+考试成绩40%

3 内容一览 本章抛开MySQL讲解关系数据库设计的相关知识，以“选课系统”为例，讲解“选课系统”数据库的设计流程。 1 2 3 4 数据库概述
E-R图 4 关系数据库设计

4 1.1 数据库概述 简单地说：数据库（Database或DB）是存储、管理数据的容器； 1
严格地说：数据库是“按照某种数据结构对数据进行组织、存储和管理的容器”。 总结：数据永远是数据库的核心。 1 关系数据库管理系统 2 关系数据库 3 结构化查询语言SQL

5 1.1.1 关系数据库管理系统 基于“关系模型”的数据库管理系统称为关系数据库管理系统（简称为RDBMS）。随着关系数据库管理系统的日臻完善，目前关系数据库管理系统已占据主导地位。 添加标题

6 1.1.1 关系数据库管理系统 截至目前，MySQL已经成功逆袭！ 2014年2月数据库流行度排行榜 2019/1/18 6
数据库知识网站DB-Engines的数据库产品流行度排名更新如期而至。在4月份的榜单中， Oracle的积分再次增长27.2，以总分 傲视群雄。MySQL在3月份再次逆袭，积分暴增47.24，成功反超微软SQL Server；而后者显示出疲软状态，积分降幅达到近几个月最大的40分，下滑到第三位。纵观榜单，前三位的数据库产品已经非常稳固，唯一悬念只在于第二位的争夺。 2014年2月数据库流行度排行榜 6

7 1.1.1 关系数据库管理系统 2014年3月数据库流行度排行榜 2019/1/18 7
在5月份的数据库流行度排名中，前三甲位置并未发生变化，但从积分情况来看，Oracle与SQL Server呈现出下滑趋势，尤其是后者，已经连续两个月出现积分大幅下滑的情况;MySQL“逆袭”，连续三个月积分呈两位数增长，目前已经坐稳榜眼位置; 2014年3月数据库流行度排行榜 7

8 1.1.1 关系数据库管理系统 2014年4月数据库流行度排行榜 2019/1/18 8
在本期排名中， Oracle虽然依旧占据榜首，但积分下滑趋势明显；“同门师弟”MySQL依旧排名第二， 在本期排名中， Oracle虽然依旧占据榜首，但积分下滑趋势明显；“同门师弟”MySQL依旧排名第二。 2014年4月数据库流行度排行榜 8

9

10 逆袭原因 1.1.1 关系数据库管理系统 MySQL提供的功能足够与商业数据库媲美 MySQL性能足够与商业数据库媲美
功能强大 逆袭原因 MySQL提供的功能足够与商业数据库媲美 性能优越 MySQL性能足够与商业数据库媲美 简单 MySQL体积小，便于安装 开源 MySQL源代码免费下载

11

12 1.1.1 关系数据库管理系统 通过“数据库管理系统”，数据库用户可以轻松地实现数据库容器中各种数据库对象的访问（增、删、改、查等操作），并可以轻松地完成数据库的维护工作（备份、恢复、修复等操作）

13 1.1.1 关系数据库管理系统 数据库用户无法直接通过操作系统获取数据库文件中的具体内容；
数据库管理系统通过调用操作系统的进程管理、内存管理、设备管理以及文件管理等服务，为数据库用户提供管理、控制数据库容器中各种数据库对象、数据库文件的接口。

14 添加标题 添加标题

15 数据加工： 1、现实世界 2、信息世界 3、计算机世界 数据模型： 1、实体模型：E-R模型（概念设计） 2、概念模型：关系模型（逻辑设计） 3、数据模型：规范化数据库结构

16 网状模型 层次模型 数据库管理 系统常用的 数学模型 关系模型 面向对象模型

17 1.1.2 关系数据库 关系数据库中所谓的“关系”，实质上是一张二维表。请看下面的课程表。 第2个字段（列） 第4个字段（列）
第1个字段（列） 第3个字段（列） 字段名（列名） 第1条记录 第2条记录 第3条记录 第4条记录 第5条记录

18 1.1.2 关系数据库 作为数据库中最为重要的数据库对象，数据库表的设计过程并非一蹴而就，上述课程表根本无法满足“选课系统”的功能需求。
事实上，数据库表的设计过程并非如此简单，本章的重点就是讨论如何设计结构良好的数据库表。

19 1.1.3 结构化查询语言SQL 结构化查询语言（Structured Query Language或简称为SQL）是一种应用最为广泛的关系数据库语言，该语言定义了操作关系数据库的标准语法，几乎所有的关系数据库管理系统都支持SQL。

20 学习重点

21 1.2 数据库设计的相关知识 数据库设计是一个“系统工程”，要求数据库开发人员： 1 熟悉“商业领域”的商业知识。 2
利用“管理学”的知识与其他开发人员进行有效沟通。 掌握一些数据库设计辅助工具。 商业知识和沟通技能 1 数据库设计辅助工具 2 3 “选课系统”概述 4 定义问题域 编码规范 5

22 1.2.1 商业知识和沟通技能 数据库技术解决的是“商业领域”的“商业问题”。
数据库开发人员有必要成为该“商业领域”的专家，与其他开发人员（包括最终用户）一起工作，继而使用数据库技术解决该“商业领域”的“商业问题” 。

23 1.2.2 数据库设计辅助工具 E-R图 类图 程序流程图 DFD 时序图 状态图 数据模型 工具 模型 技术 业务模型 Erwin
PowerDesigner Rational Rose Visio CASE工具 IDE工具 测试工具 VC++6.0 Visual studio Eclipse NetBeans 面向对象分析和设计技术 结构化分析和设计技术 软件测试技术 关系数据库设计技术 单元测试工具 功能测试工具 性能测试 工具

24 1.2.3 “选课系统”概述 限于篇幅，在不影响“选课系统”核心功能的基础上，适当地对该系统进行“定制”、“扩展”以及“瘦身”。

25 1.2.4 定义问题域 定义问题域是数据库设计过程中重要的活动，它的目标是准确定义要解决的商业问题。
“选课系统”亟需解决的“商业”问题有哪些？

26 1.2.5 编码规范 在编程的时候会考虑代码的可读性吗？你觉得代码可读性是需要考虑的问题吗？ 1. 代码不仅要自己能读懂，还要别人也能看懂？
2. 尽量做到可读，但时间紧任务重的时候就顾不上了？ 3. 代码只要自己能读懂就可以了？ 4. 代码写完就完了，不用管以后是否能读懂？ 5. 不知道，没有想过这个问题？

27 请记住：尽最大努力把方便留给别人和将来的自己。
建议大家遵循本书罗列的常用编程规范！

28 1.3 E-R图 1 实体和属性 E-R图设计的质量直接决定了关系数据库设计的质量。 关系 2 E-R图的设计原则 3

29 1.3.1 实体和属性 实体不是某一个具体事物，而是某一种类别所有事物的统称。
属性通常用于表示实体的某种特征，也可以使用属性表示实体间关系的特征 实体 属性 属性

30 1.3.2 关系 E-R图中的关系用于表示实体间存在的联系，在E-R图中，实体间的关系通常使用一条线段表示。

31 1.3.2 关系 基数表示一个实体到另一个实体之间关联的数目，基数是针对关系之间的某个方向提出的概念，基数可以是一个取值范围，也可以是某个具体数值 基数 基数 强制 可选

32 1.3.2 关系 元表示关系所关联的实体个数。 二元关系 一元关系 二元关系

33 1.3.2 关系 使用关联（Association）表示实体间关系的属性。 关联 关联

34 1.3.3 E-R图的设计原则 数据库开发人员通常采用“一事一地”的原则从系统的功能描述中抽象出来E-R图。 问题：
属性应该存在于、且只存在于某一个地方（实体或者关联）。 2 实体是一个单独的个体，不能存在于另一个实体中，成为另一个实体的属性。 3 同一个实体在同一个E-R图内，仅出现一次。 问题： 1、唯一标识：ISBN；2、属性多个值怎么处理； 3、一个实体提取多少个属性，实体与实体之间的联系

35 1.4 关系数据库设计 1．为E-R图中的每个实体建立一张表。
2．为每张表定义一个主键（如果需要，可以向表添加一个没有实际意义的字段作为该表的主键） 3．增加外键表示一对多关系。 4．建立新表表示多对多关系。 5．为字段选择合适的数据类型。 6．定义约束条件（如果需要）。 7．评价关系的质量，并进行必要的改进。

36 1.4.1 为每个实体建立一张数据库表 student(student_no,student_name,student_contact）
course(course_name,up_limit,description,status) teacher(teacher_no,teacher_name,teacher_contact) classes(class_name,department_name)

37 1.4.2 为每张表定义一个主键 关键字（key）：用以唯一标识表中的每行记录。
主键（Primary Key）：在所有的关键字中选择一个关键字，作为该表的主关键字，简称主键。

38 1.4.2 为每张表定义一个主键 主键有以下两个特征： （1）表的主键可以是一个字段，也可以是多个字段的组合（这种情况称为复合主键）。
（2）表中主键的值具有唯一性且不能取空值（NULL）；当表中的主键由多个字段构成时，每个字段的值都不能取NULL。 主键设计技巧，请参看本书内容。

39 1.4.2 为每张表定义一个主键 student(student_no,student_name,student_contact）
course(course_no,course_name,up_limit,description,status) teacher(teacher_no,teacher_name,teacher_contact) classes(class_no,class_name,department_name)

40 1.4.3 增加外键表示一对多关系 外键（Foreign Key）：如果表A中的一个字段a对应于表B的主键b，则字段a称为表A的外键，此时存储在表A中字段a的值，要么是NULL，要么是来自于表B主键b的值。

41 1.4.3 增加外键表示一对多关系 情形一：如果实体间的关系为一对多关系，则需要将“一”端实体的主键放到“多”端实体中，然后作为“多”端实体的外键，通过该外键即可表示实体间的一对多关系。

42 1.4.3 增加外键表示一对多关系 让学生记住所在班级，远比班级“记住”所有学生容易的多 。

43 1.4.3 增加外键表示一对多关系 情形二：实体间的一对一关系，可以看成一种特殊的一对多关系：将“一”端实体的主键放到另“一”端的实体中，并作为另“一”端的实体的外键，然后将外键定义为唯一性约束（Unique Constraint）。

44 1.4.3 增加外键表示一对多关系 PK

45 1.4.3 增加外键表示一对多关系 PK后的方案：student(student_no,student_name,
student_contact,class_no) course(course_no,course_name,up_limit, description,status,teacher_no) teacher(teacher_no,teacher_name,teacher_contact) classes(class_no,class_name,department_name)

46 1.4.4 建立新表表示多对多关系 情形三：如果两个实体间的关系为多对多关系，则需要添加新表表示该多对多关系，然后将该关系涉及到的实体的“主键”分别放入到新表中（作为新表的外键），并将关系自身的属性放入到新表中作为新表的字段。

47 1.4.4 建立新表表示多对多关系 teacher(teacher_no,teacher_name, teacher_contact)
classes(class_no,class_name,department_name) course(course_no,course_name,up_limit, description,status,teacher_no) student(student_no,student_name, student_contact,class_no) choose(choose_no,student_no,course_no,score,choose_time)

48 1.4.4 建立新表表示多对多关系

49 数据模型的要素和种类 数据模型是严格定义的一组概念的集合，这些概念精确地描述了系统的静态特征(数据结构)、动态特征(数据操作)和数据约束条件，这是数据模型的三要素。 数据结构:一张二维表、数据类型 数据操作：sql语言增删改查 数据约束条件：

50 1.4.5 为字段选择合适的数据类型

51 1.4.6 定义约束（Constraint）条件 常用的约束条件有6种： 主键（Primary Key）约束
外键（Foreign Key）约束 唯一性（Unique）约束 默认值（Default）约束 非空（Not NULL）约束 检查（Check）约束。

52 1.4.7 评价数据库表设计的质量 设计数据库时，有两个不争的事实。
 数据库中冗余的数据需要额外的维护，因此质量好的一套表应该尽量“减少冗余数据”。  数据库中经常发生变化的数据需要额外的维护，因此质量好的一套表应该尽量“避免数据经常发生变化”。

53 1.4.8 使用规范化减少数据冗余 冗余的数据需要额外的维护，并且容易导致“数据不一致”、“插入异常”以及“删除异常”等问题的发生。

54 1.4.8 使用规范化减少数据冗余

55 1.4.8 使用规范化减少数据冗余 规范化是通过最小化数据冗余来提升数据库设计质量的过程，规范化是基于函数依赖以及一系列范式定义的，最为常用的是第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。

56 1.4.8 使用规范化减少数据冗余 函数依赖：一张表内两个字段值之间的一一对应关系称为函数依赖。
第一范式：如果一张表内同类字段不重复出现，并且属性不可再分，该表就满足第一范式的要求。

57 1.4.8 使用规范化减少数据冗余 第一范式

58 1.4.8 使用规范化减少数据冗余 第二范式：一张表在满足第一范式的基础上，如果每个“非关键字”字段“仅仅”函数依赖于主键，那么该表满足第二范式的要求。 场景一：插入异常。 场景二：修改复杂。 场景三：删除异常。

59 1.4.8 使用规范化减少数据冗余 第二范式

60 1.4.8 使用规范化减少数据冗余 第三范式：如果一张表满足第二范式的要求，并且不存在“非关键字”字段函数依赖于任何其他“非关键字”字段，那么该表满足第三范式的要求。

61 1.4.8 使用规范化减少数据冗余 第三范式

62 1.4.9 避免数据经常发生变化 统计学生的个人资料时，如果读者是一名数据库开发人员，应该让学生上报年龄信息，还是让学生上报出生日期？
如何确保每一门课程选报学生的人数，不超过人数上限？

63 1.4.9 避免数据经常发生变化 方案一： course(course_no, course_no,course_name,
up_limit,description,status,teacher_no, available) 方案二：数据库表无需进行任何更改。

64

65

66 任务布置 任务1：描述“选课系统”的问题域。
任务2：将本书图1-7中“团购网站、顾客以及房源之间的三元关系表示方法 ”E-R图转化为关系（模式）。 任务3：使用笔纸或者word绘图工具，绘制“选课系统”的E-R图。 任务4：将“选课系统”的E-R图转化为关系（模式）。

67 Thanks