数据库复习题二

本复习题有一和二
此处为复习题二
觉得有用请点赞！

数据库系统与应用的知识点

一、 根据客户的问题进行需求分析（调查分析用户活动 、收集和分析需求数据，确定系统边界 画数据流图、数据字典）
二、 概念设计：画ER图 重点
三、 逻辑设计：关系模式（利用函数依赖、范式规范关系,闭包） 重点
四、 物理设计：确定存储方式、索引、数据结构
五、 实现：创建数据库、数据表、修改表、删除表、数据操纵（添加数据、修改数据、删除数据） 重点
六、 查询：单表查询，多表查询（连接查询、子查询） 重点
七、 程序设计：存储过程

详细内容：

一、概念设计：画ER图 重点

绘制Ｅ－Ｒ图的步骤
（1）首先确定实体类型。
（2）确定联系类型（1：1，1：N，M：N）。
（3）把实体类型和联系类型组合成E—R图。
（4）确定实体类型和联系类型的属性。
（5）确定实体类型的键，在E—R图中属于键的属性名下画一条横线。

二、逻辑设计：关系模式（利用函数依赖、范式规范关系） 重点

1、关系模式（Relational Schema):由一个关系名以及它所有的属性构成。

格式： 关系名（属性名1，属性名2，…，属性名n）
在SQL Server中对应的表结构为：
表名（字段名1、字段名2，… ,字段名n）

2、ER图转换为关系模式

 转换原则
• 将E-R图转换为关系模型实际上就是将实体、属性和联系转换成关系模式。
• 在转换中要遵循以下原则：
（1）一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的键就是关系的键。
（2）一个联系转换为一个关系模式，与该联系相连的各实体的键以及联系的属性均转换为该关系的属性。该关系的键有三种情况：
– 如果联系为1:1，则每个实体的键都是关系的候选键；
– 如果联系为1:n，则n端实体的键是关系的键；
– 如果联系为n:m，则各实体键的组合是关系的键。

3、数据库范式

基本概念
 实体：现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”，它也可以是虚拟的，如“老师与学校的关系”。
 属性：二维表中的每一列称为关系的一个属性。
 元组：表中的一行就是一个元组。
 域（Domain）：属性所对应的取值变化范围叫属性的域。
 分量：元组的某个属性值。在一个关系数据库中，它是一个操作原子，即关系数据库在做任何操作的时候，属性是“不可分的”。否则就不是关系数据库了。
 主键（Primary Key）：能唯一标识关系中不同元组的属性或属性组称为该关系的候选关键字。
 外键（Foreign Key）：如果关系R的某一（些）属性A不是R的关键字，而是另一关系S的关键了，则称A为R的外来关键字。
第一范式（1NF）：属性不可分

第二范式（2NF）：符合1NF，并且，非主属性完全依赖于码。

 第三范式（3NF）符合2NF，并且，消除传递依赖
 上面的“学生上课表新”符合2NF，可以这样验证：两个主属性单独使用，不用确定其它四个非主属性的任何一个。但是它有传递依赖！
 在哪呢？问题就出在“老师”和“老师职称”这里。一个老师一定能确定一个老师职称。
 有什么问题吗？想想：
小结：
在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：
 第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；
 第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；
 第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。
 没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。

练习1：设某商业集团的仓库管理系统

数据库有三个实体。
一是“公司”实体，属性有公司编号、公司名、地址等；
二是“仓库”实体，属性有仓库编号、仓库名、地址等；
三是“职工”实体，属性有职工编号、姓名、性别等。
公司与仓库间存在“隶属”联系，每个公司管辖若干仓库，每个仓库只能属于一个公司管辖；
仓库与职工间存在“聘用”联系，每个仓库可聘用多个职工，每个职工只能在一个仓库工作，仓库聘用职工有聘期和工资。
（1）试画出ER图，并在图上注明属性、联系的类型。
（2）将ER图转换成关系模式，并注明主键和外键。

公司（公司编号，公司名，地址）
仓库（仓库编号，仓库名，地址，公司编号）FK：公司编号
职工（职工编号，姓名，性别）
聘用（职工编号，仓库编号，聘期，