数据库考点之数据库设计（综合大题）

如题：2018年10月

分析：其实是书P55页有明确的叙述。关键是要理解“参照”。

个人定义的，外码作为主码的表（关系）为外表，而外码所在的表为内表。那么外表就是被参照表（可以理解为被动参照），而主动参照的内表就是参照表。

但这个主从关系，不能简单理解为主动与被动。类似于UML中聚合或是组合关系，内表是外表的一部分，所以外表是作为主关系的。这是很容易混淆。详见：软考《软件工程设计》

再如：不同与2019年10月及2019年4月题型，2018年10月，考察范式

36、设有关系模式R(读者号，姓名，单位号，单位名，图书号，书名，借阅日期，还书日期）存储读者倦阅图书等信息。

如果规定：每个读者只属于一个单位；每个读者可以借阅多本图书，每本图书也可以被多名读者借阅，每个读者也可以对某本图书多次借阅，但每个读者每本图书每天最多借一次。

分析：第一问，关键字，头脑第一反应是属性？？如何唯一表示这个关系就是关键字，也就是码的概念。

首先得明确这个是什么关系，题目明确给出是借阅读书，那么如何唯一表示呢？读者号，图书号这肯定是需要的，唯一标识这个人，其实还有书的信息？根据下面的提示，手画一下E-R图。

通过分析就很明显了，就是借阅这个关系，这其实很重要，因为据此可排除单位这个干扰项，还有个借书日期，所以写上读者号、图书号，借阅日期。

（2）、属于第几范式？这问，凭之前的积累，属于第一范式

还有个为什么？还是从E-R图分析，第2范式是存在非主属性对码的部分依赖。如姓名只依赖于读者号

（3）、删除读者借阅信息时会把读者基本信息删除。

（4）、不要被吓到，3范式，消除非主对码的传递函数依赖，其实就是将E-R图的关系分解写出来就可以了

单位（单位号，单位名）

读者（读者号，姓名，单位号）

图书（图书号，书名）

借阅（图书号，读者号，借书日期，还书日期）

看来，自考的难度也就如此吧，对于此题型，主要还是E-R图的知识内容，所以一定要先画出来，再分析题。

如题：2019年10月

答：1、E-R图：

2、读者(读者号，姓名，出生日期）

图书（图书号，图书名，作者，出版社，定价，类号）

类别（类号，类名）

借阅（图书号，读者号，借书日期，还书日期）也为外键，用绿色标识

主键用红色标识

3、

create table 类别
(类号 int primary key,类名 char（20）
);

这块即使没有复习，也不至于全军覆没，相比于软考，这里其实简单很多了。

尽管，软考时已经分析过这部分了，但属于分块的知识，没有系统的了解这块的内容，借着复习的机会，再看下有没有新鲜的东西！

关于数据库设计：

按照规范设计，将数据库的设计过程分为六个阶段：
A、系统需求分析阶段
B、概念结构设计阶段
C、逻辑结构设计阶段
D、物理结构设计阶段
E、数据库实施阶段
F、数据库运行与维护阶段
需求分析和概念结构设计独立于任何数据库管理系统。

系统需求分析阶段：

分为四步：

1、确定数据库范围：确定数据应支持哪些功能。

2、应用过程分析：根据上步确定的功能，分析每个功能要用到哪些数据、数据使用顺序、对数据处理等。数据库结构设计重要依据来源。可借助数据流图。参见《软考下午题数据流图》2019年10月2日，里的知识点。

3、收集与分析数据：可从静态结构、动态结构、数据约束三方面进行。

4、编写分析报告：业务人员与数据库设计人员共同语言。

概念结构设计阶段，书中只介绍了自顶向下方法

概念结构设计的目标是设计数据库的E-R模型图，确认需求信息的正确和完整。具体来说就是从需求分析中找到实体，确认实体的属性、确认实体的关系，画出ER图。

概念结构设计的步骤

第一步，数据抽象与局部E-R模型设计

A、数据抽象
在多层数据流中选择一个适当层次作为设计E-R图的出发点。
确定每个局部应用包含哪些实体，实体包含哪些属性，实体之间的联系
划分实体和属性的方法
分类：将一组具有某些共同特性和行为的对象抽象为一个实体。
聚合：将对象类型的组成成分抽象为属性。
B、局部E-R模型设计
局部E-R模型设计的原则是属性必须是不可分的数据项，不能再由放弃其他属性组成；属性不能与其他实体具有联系，联系只能发生在实体之间。
为简化E-R图，凡是能作为属性对待的，尽量作为属性。

第二步，全局E-R模型设计

集成各局部E-R模型，形成全局模型。视图集成的方法有两种：
A、多元集成法：一次性将多个局部E-R图合并为一个全局E-R图。
B、二元集成法：首先集成两个重要的局部E-R图，然后用累加的方法逐步将一个新的E-R图集成进来。
合并：
合并局部E-R图，消除冲突，初步生成E-R图。合并的关键是合理消除各局部E-R图的冲突。

冲突分类如下：

优化：
消除初步E-R图中不必要的冗余，生成基本的E-R图。
冗余数据：可由基本的数据导出的数据。
冗余联系：可由基本的联系导出的联系。

实例

教学管理系统的E-R图
实体：学生、专业、学院、课程
实体表要记录的属性：
学生（学号、姓名、性别、生日、籍贯、民族、简历、入学日期）

专业（专业号、专业名称、类别）
学院（学院号、学院名称、院长）
课程（课程号、课程名称、学分）

教学管理ER图：

逻辑结构设计阶段

逻辑结构设计的任务是将概念结构设计阶段完成的实体模型转换成特定的DBMS所支持的数据模型(也就是数据库的模式和外模式）的过程。逻辑结构设计的目的是将E-R图中的实体、属性和联系转换成为关系模式。

步骤如下图：

模型转换：将概念模型等价转换成DBMS所支持的关系模型。关系型数据库就是E-R图向关系模式转化。

如何将实体及实体间联系转换成关系模式，如何确定关系模式的属性及主码？

实体间关系转换遵循的原则：

一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的键就是关系的键。
一个联系转换为一个关系模式，与该联系相连的各实体的键以及联系的属性均转换为该关系的属性。

联系关系的键有三种情况：
如果联系为1:1，则每个实体的键都是关系的候选键
如果联系为1：n，zen端实体的见识关系的键
如果联系为n:m，则各实体的键的组合是关系的键
特殊情况：多元联系
多元联系在转换为关系模式时，与该多元联系相连的各实体的主键及联系本身的属性均转换为关系的属性，转换后所得到的的关系的主键为各实体键的组合

例子：

A、一个1:1关系可以转换为一个独立的关系模式，也可以与任意一端所对应的关系模式合并。

原实体对应关系模式分别为：
班级（班号，专业，人数）
班长（学号，姓名，专长）
将关系“管理”合并到实体“班级”对应的模式后为：
班级（班号，专业，人数，班长学号）
班长（学号，姓名，专长）
关系“管理”也可以合并到实体“班长”对应的模式，将关系“管理”合并到实体“班级”对应的模式后为：
班级（班号，专业，人数）
班长（学号，姓名，专长，班号）

B、一个1:n关系可以转换为一个独立的关系模式，也可以与n端所对应的关系模式合并。

实体对应的关系模式
系（系号，系名，系主任，电话）
教师（教师号，姓名，专业，职称，性别，年龄）
关系对应的关系模式
管理（教师号，系号）
合并到实体“教师”后（只能合并到“多”的一端的关系模型）：
教师（教师号，姓名，专业，职称，性别，年龄，系号）

C、一个m:n关系转换为一个关系模式。转换的方法为：与该关系相连的各实体的码以及关系本身的属性均转换为关系的属性，新关系的码为两个相连实体码的组合。
关系只能转换为独立模式，模式的属性由关系本身的属性及两个实体的键构成；主键由两端实体的键组合而成。

课程（课程号，课程名，学时，类别）实体表
学生（学号，姓名，性别，专业，出生日期，照片）实体表
选修（学号，课程号，分数）关系表

注：可以参考软考《E-R图转成关系规则及范式》

D、三个或三个以上实体间的多元关系转换为一个关系模式。
关系的属性：与该多元关系相连的各实体的码以及关系本身的属性
关系的码：各实体码的组合
“讲授”关系是一个三元关系，可以转换为如下关系模式，其中课程号、职工号和书号为关系的组合码：
　　讲授（课程号，职工号，书号）

数据模型优化-范式

数据库设计的三大范式如下：参考软考《E-R图转成关系规则及范式》这个文章分析了范式，还算是明白！
第一范式每一个分类必须是一个不可分的数据项。属性不可再分，确保每列的原子性。
第二范式要求每个表只描述一件事情，每条记录有唯一标识列。
第三范式数据库表中不包含已在其它表中已包含的非主关键字信息。

关系模式的规范化过程如下：
A、确定范式级别
考察关系模式的函数依赖关系，确定范式等级。
B、实施规范化处理
利用规范化方法和理论将关系模式规范化。
C、模式改进
合并：
将用于关联查询的具有相同主键的各表合并可提高查询效率
分解：
水平分解，将关系的元组分为若干子集，提高查询效率；垂直分解，把关系中经常一起使用的属性分解出来，形成一个子关系，提高执行效率。分解时要保持无损连接和函数依赖。

实例

教学管理系统
由ER模型转化为的关系模型：
学生（学号、姓名、性别、生日、籍贯、民族、入学日期、专业号）实体表
专业（专业号、专业名称、类别、学院号）实体表
学院（学院号、学院名称、院长）实体表
课程（课程号、课程名称、学分、学院号）实体表
成绩表（学号、课程号、成绩）关系表
在转换为关系模型时，一对多的联系都在相应的多方实体的关系中增加一个外键。
需求的增加：
如果教学管理系统还要管理教师教学安排，教师包括编号、姓名、年龄、职称，一个教师只能属于一个学院，一名教师可以上若干门课程，一门课程可以有多名老师来上，每个教师所上的每门课都有一个课堂号和课时数。

教师实体的ER图：

教学管理系统ER图：

关系表多对多
成绩表（学号，课程号，成绩，时间，地点）

子模式设计：进一步细分下关系及操作。

根据局部应用需求，利用视图（view)设计列符合局部用户需要的外模式。

应用应用程序说明：行为设计依据。

具体的程序编写

设计评价：正确性与合理性验证。

总结

物理结构设计阶段

对于给定的逻辑数据模型，选取一个最适合应用环境的物理结构。

此阶段的主要任务是：对关系建立索引和聚集来实现与应用相关数据的逻辑连接和物理聚集，以善对数据库的存取效率。

数据库的物理结构设计分为两步：

A、确定物理结构：存取方法和存储结构
B、评价物理结构：评价重点是时间和空间效率
根据具体的数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储结构(数据类型索引主键)。

确定物理结构

（1）存储结构的设计（聚集，一般是DBMS自己实现）
物理结构中，数据的基本存取单位是存储记录。
某一类型的所有存储记录的集合称为文件。
确定数据库存储结构时要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。例如消除一切冗余数据虽然能够节约存储空间，但往往会导致检索代价的增加，因此必须进行权衡，选择一个折中方案。
（2）数据存取路径的设计（索引建立）通过DBMS提供的命令实现
在关系数据库中，选择存取路径主要是指确定如何建立索引。例如，应把哪些域作为次码建立次索引，建立单码索引还是组合索引，建立多少个为合适，是否建立聚集索引等。
（3）数据存放位置的设计
为了提高性能，可将数据的易变部分、稳定部分、经常存取部分和存储频率较低部分分开存放。
（4）系统配置的设计
DBMS产品一般都提供了一些存储分配参数，供设计人员和DBA对数据库进行物理优化。初始情况下，系统都为这些变量赋予了合理的缺省值，但是这些值不一定适合每一种应用环境，在进行物理设计时，需要重新对这些变量赋值以改善系统的性能。

评价物理结构

物理结构设计过程中需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案，数据库设计人员必须对方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。
评价物理数据库的方法完全依赖于所选用的DBMS，主要是从定量估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。

数据库实施阶段

指根据逻辑设计和物理设计的结果，在计算机上建立起实际的数据库结构、装入数据、进行测试和试运行的过程。

数据库运行与维护阶段

只有数据库系统在运行，就需要不断地进行修改、调整和维护

数据库运行与维护的主要任务包括：
A、维护数据库的安全性与完整性
B、监测并改善数据库性能
C、重新组织和构造数据库