数据库系统原理之数据库应用设计与开发实例

Posted 2023-04-05 小乔的博客

数据库应用设计与开发实例

第一节 需求描述与分析

在此，结合某高校个性化课程在线选课的实际需求，给出一个简化的需求分析

一、功能性需求

1 管理员后台模块

• 学生信息管理
• 教师信息管理
• 课程信息管理
• 班级信息管理

2 学生使用模块

• 查询课程
• 浏览所选课程
• 查询成绩

3 教师使用模块

• 我的课程
• 登分

二、非功能性需求

在线选课系统

浏览器/服务器(B/S) 结构

• 选课系统质量需求：
  • 可靠性
  • 正确性
  • 兼容性
  • 健壮性

第二节 系统设计

自顶向下 功能模块结构图

一、功能模块设计

• 登录验证模块
• 管理员后台模块
  • 学生信息管理模块
  • 教师信息管理模块
  • 课程信息管理模块
  • 院系信息管理模块
• 学生使用模块
  • 查询课程模块
  • 浏览已选课程模块
  • 选课及退选模块
  • 成绩查询模块
• 教师使用模块
  • 我的课程模块
  • 登分模块

二、数据库设计

1 确定实体

• 学生实体用于描述学生的基本信息，包括学号、姓名、性别、密码等信息。
• 教师实体用于描述教师的基本信息，包括教师工号、姓名、性别、年龄、职称、密码登信息。
• 课程实体用于描述课程的基本信息，包括课程号、课程名、学分、时间、地点、类别、开课学院、限选人数等信息。
• 院系实体用于描述院系的基本信息，包括院系名称、办公地点、教师人数等信息。
• 系统管理员实体用于描述系统管理员的基本信息，包括姓名、ID号、密码登信息。

注意：在数据库设计时，实体的描述信息可根据实际需求进行增加或删减，如果实体的属性较多，在构建 E-R 模型时不一定需要把所有的属性都标识在E-R 模型上，可以另外用文字说明，这样也使得 E-R 模型简明清晰，便于分析。

2 局部信息结构

• 学生-课程 “选修” 多对多（M：N）
• 教师-课程 “授课” 一对多（1：N）
• 教师-院系 “属于” 一对多（1：N）
• 学生-院系 “属于” 一对多（1：N）
• 系统管理员-学生 “管理” 多对多 （M：N）
• 系统管理员-教师 “管理” 多对多 （M：N）
• 系统管理员-课程 “管理” 多对多 （M：N）
• 系统管理员-院系 “管理” 多对多 （M：N）

3 全局信息结构

• 首先将学生-课程E-R图、教师-课程E-R图，教师-院系E-R图、学生-院系E-R图合并成为一个较大的局部信息结构。
  • 学生-教师-课程-院系 E-R 图
• 将 系统管理员-学生、系统管理员-教师、系统管理员-课程、系统管理员-院系的E-R图合并成为一个较大的局部信息结构。
  • 系统管理员-学生-教师-课程-院系 E-R 图
• 最后，将 学生-教师-课程-院系 E-R 图和系统管理员-学生-教师-课程-院系 E-R 图合并成为一个本系统的全局 E-R 图。

4 逻辑结构与规范化设计

转换为关系模式，主码用下划线标识

• 学生（学号、姓名、性别、登录密码、院系编号）
• 院系（院系编号、系名、学生人数、教师人数、办公地点）
• 教师（职工号、姓名、性别、年龄、职称、登录密码、院系编号）
• 课程（课程号、课程名称、课程类别、学分、上课时间、上课地点、开课学院、限选人数、职工号）
• 系统管理员（ID号、姓名、登录密码）
• 选修（学号、课程号、成绩）
• 管理学生（管理员 ID 号、学号、操作时间）
• 管理院系（管理员 ID 号、院系编号、操作时间)
• 管理教师（管理员 ID 号、职工号、操作时间）
• 管理课程（ 管理员 ID 号、课程号、操作时间)

E-R 图 关系模式 第三范式

院系

院系编码（院系编号、系名）

院系（院系编号、学生人数、教师人数、办公地点）

课程

课程编码（课程号、课程名称）

课程（课程号、课程类别、学分、上课时间、上课地点、开课学院、限选人数、职工号）

第三节 系统实现

1 数据库的实现

• 创建数据库

mysql> create database db_xuanke;
Query OK, 1 row affected (0.00 sec)

mysql>

• 创建表
  • 学生信息表 student
  • 院系编码表 deptcode
  • 院系表 department
  • 教师表 teacher
  • 课程编码表 coursecode
  • 课程表 course
  • 系统管理员表 administrator
  • 选修表 electing
  • 管理学生表 adminstu
  • 管理院系表 admindept
  • 管理教师表 adminteacher
  • 管理课程表 admincourse

2 系统功能的实现

• 实现数据库行为
  • 安全控制
  • 管理学生
  • 数据库保护
  • 事务与并发控制
  • 数据查询与统计报表
• 实现应用软件的业务逻辑

第四节 系统测试与维护

1 登录验证功能测试

2 管理员后台主要功能测试

• 学生信息管理功能
• 课程信息管理功能

3 学生使用模块功能测试

4 教师使用模块功能测试

本文来自博客园，作者：QIAOPENGJUN，转载请注明原文链接：https://www.cnblogs.com/QiaoPengjun/p/17288085.html

数据库设计与 ER 模型 - 数据库系统原理

数据库系统生存周期

       数据库应用系统的开发是一项软件工程，一般具有信息的采集、组织、加工、抽取、综合、传播等功能，但又有自己的特点，所以称为 数据库工程。

       数据库应用系统从开始规划、设计、实现、维护到最后被新的系统取代而停止使用的整个周期，称为 数据库系统生存期。

       数据库系统生存期一般可划分成下面七个阶段：

       （1）规划：是数据库系统生存周期的第一步。在规划阶段需要做的工作是：通过了解用户的实际需求，明确该系统需要实现的目标和任务，确定数据库系统的总目标。

               规划阶段需要做的工作有：

                  a. 系统的调查。

                  b. 可行性分析。

                  c. 确定数据库系统的总目标，并对应用单位的工作流程进行优化和制定项目开发计划。

       （2）需求分析：准确了解、分析用户需求。

               需求分析阶段需要做的工作有：

                  a. 分析用户活动，产生业务流程图。

                  b. 确定系统范围，产生系统关联图。

                  c. 分析用户活动涉及的数据，产生数据流图。

                  d. 分析系统数据，产生数据字典。

       （3）概念设计：概念结构设计是数据库设计最重要的阶段，通过对用户需求进行综合，归纳和抽象，形成一个独立于具体 DBMS 的概念模型。

               概念设计的主要步骤分三步完成：

                  a. 进行数据抽象，设计局部概念模型。

                  b. 将局部概念模型综合成全局概念模型。

                  c. 评审。

       （4）逻辑设计：将概念结构设计转换为某个 DBMS 支持的数据模型。

       （5）物理设计：为逻辑结构模型选择一个合适于应用的物理结构。

       （6）数据库的实现：运用 DBMS 提供的数据库语言及宿主语言，根据逻辑设计和物理设计的结果建立数据库，开发应用程序，并试运行。

       （7）数据库运行和维护：在数据库系统运行过程中，搜集系统运行的数据来评价系统性能，进一步对系统进行调整和修改。

 

ER 模型的基本概念

• ER 模型

       ER 模型是人们认识客观世界的一种方法、工具。ER 模型的基本元素是实体、联系和属性。ER 模型就是利用实体及其之间的联系来描述事物，一个联系可能涉及多个实体，它所涉及的实体集个数称为该联系的元数，ER 模型中用联系类型的约束来限制参与联系的实体的数目。

       ER 模型的设计过程基本上是两大步：

1. 先设计实体类型。（此时不要涉及“联系”）
2. 再设计联系类型。（考虑实体间的联系）

       具体设计时，有时“实体”与“联系”两者之间的界限是模糊的。数据库设计者的任务就是要把现实世界中的数据以及数据间的联系抽象出来，用“实体”与“联系”来表示。

• 采用 ER 模型的数据库概念设计

       采用 ER 模型进行数据库概念设计分为三步进行：

       （1）设计局部 ER 模型。

               a. 确定局部结构范围。

               b. 定义实体。

               c. 定义联系。

               b. 属性分配。

       （2）设计全局 ER 模型。

               a. 确定公共实体类型。

               b. 局部 ER 模型的合并。

               c. 消除冲突。

       （3）全局 ER 模型的优化。

               a. 合并实体类型。

               b. 消除冗余属性。

               c. 消除冗余联系。

 

关系模型的基本概念

       用二维表格结构表示实体集，用关键码表示实体间联系的数据模型，称为 关系模型。

• 关系模型的基本术语

       基本术语有：字段（属性）、字段值（属性值）、记录（元组）、二维表格（元组集合、关系或实例），括号中的表述为关系模型中的术语。

       关系中属性的个数称为 元数，元组的个数称为 基数。

       键：由一个或几个属性组成。（注意，键不一定是唯一的一个属性）

       超键：在关系中能唯一标识元组的属性集。（注意，超键也是一个属性集，不一定只是一个属性）

       候选键：不含有多余属性的超键。

       主键：用户选作元组标识的一个候选键。

       外键：与某个关系的主键相应的属性在另一个关系中出现，此时，该主键就是另一关系的外键。如有两个关系 S 和 SC，其中 S# 是关系 S 的主键，S# 也在关系 SC 中出现，此时 S# 就是关系 SC 的外键。

• 关系模型的三类完整性规则

1. 实体完整性规则：要求关系中元组在组成主键的属性上不能有空值。
2. 参照完整性规则：要求不能引用不存在的实体。
3. 用户定义完整性规则：由具体应用环境决定，系统提供定义和检验这类完整性的机制。

 

ER 模型到关系模型的转换规则

       关系数据库的逻辑设计的结果是一组关系模式的定义，由于关系模型的固有优点，逻辑设计把概念设计的结果（即全局 ER 模型）转换成初始关系模式集，使设计过程形式化的进行，并且结果可以验证。

       ER 模型的主要成分是实体类型和联系类型，转换算法就是如何把实体类型、联系类型转换成关系模式。

       对于实体类型，可以这样转换：将每个实体类型转换成一个关系模式，实体的属性即为关系模式的属性，实体标识符即为关系模式的键。

       对于联系类型，要根据不同的情况做不同的处理。转换的规则是：

1. 如果实体间的联系是一对一的联系，将一个关系的键作为外键放在另一个关系中。
2. 如果实体间的联系是一对多的联系，则将“一”端的关系的键作为外键放在“多”端的关系中。
3. 如果实体间的联系是多对多的联系，则将联系类型也单独转换成一个关系，该关系称为交叉关系。这个关系的键由与联系相关联的实体的键组合而成，联系的属性成为这个交叉关系的属性。

 

ER 模型实例分析

       假设要建立一个企业数据库，该企业有多个下属单位，每一单位有多个职工，一个职工仅隶属于一个单位，且一个职工仅在一个工程中工作，但一个工程中有很多职工参加工作，有多个供应商为各个工程供应不同设备。（这种语句就是典型的三元联系类型 M：N：P）

       单位的属性有：单位名、电话。

       职工的属性有：职工号、姓名、性别。

       设备的属性有：设备号、设备名、产地。

       供应商属性有：姓名、电话。

       工程的属性有：工程名、地点。

       请完成如下处理：

1. 设计满足上述要求的 ER 图。
2. 将该 ER 图转换为等价的关系模式。
3. 根据你的理解，用下划线标明每个关系中的主键。

       （1）满足要求的 ER 图如下（实体属性用椭圆形画出，这里略…）：

      

       （2）转换后的关系模式和主键如下（红色表示有下划线的主键，紫色表示有波浪线的外键，破折号表示联合住建，第6小项就是联合主键又分别是其余3个关系的外键）：

1. 单位（单位名、电话）
2. 职工（职工号、姓名、性别、单位名、工程名）
3. 工程（工程名、地点）
4. 供应商（姓名、电话）
5. 设备（设备号、设备名、产地）
6. 供应关系（工程名-设备号-供应商姓名、数量）  注：此处的“数量”属性是根据题意推测出来的。

 

增强的 ER 模型

• 弱实体与强实体

       一个实体对于另一个实体（称为强实体）具有很强的依赖关系，而且该实体主键的一部分或全部从其强实体中获得。则称该实体为弱实体。用双线矩形框表示。

• 子类和超类的定义

       当较低层次上实体类型表达了与之联系的较高层上的实体类型的特殊情况时，就称较高层上实体类型为超类型，较低层上实体类型为子类型。子类继承超类的全部属性。

 

TEST

1. 为什么关系中的元组没有先后顺序？且不允许有重复元组？

（1）关系就是元组的集合，而集合不考虑元组的先后顺序问题。（2）关系中每个元组一定会有属性标识符用来区分每一个元组，属性值是不同的，所以不会出现完全一样的元组，从集合论的观点来看，也不会出现重复元素。