原创文章,欢迎转载,转载请注明出处(作者和链接)。
第一章
1、数据库概念
数据库是一组相关记录的自描述集合。数据库是“自描述”的,是因为它包含了其内容的描述性信息(称为元数据)。数据库是组织、存储、管理、加工数据的仓库。
关系数据库是一组相关表的自描述集合。表通过存储公共列的链接值来关联。
SQL:结构化查询语言。处理关系数据库中的表的国际语言。使用SQL可以将不同的表连接到一起,显示存储在各个表中的数据,创建新表,查询、插入、更新、删除表中数据。
第二章
1、术语说明
表/文件中的行 元组/纪录
表/文件中的列 属性/字段
2、键的类型
键(key)是表中用来标识行的一列或多列。唯一键标识一行,非唯一键可标识多行。
例如:EMPLOYEE 表 EmployeeNumber 是唯一键,因为一个 EmployeeNumber 值可以唯一地确定一行,这样“显示所有 EmployeeNumber 为 200 的雇员”的查询将返回一行。(键唯一)
再例如:EMPLOYEE 表 中department就是非唯一键。它是键,因为它用于标识行,但它不是唯一的,因为一个department的值可能会确定多行。这样“显示所有deparment的值为acc的行”的查询将会返回多行。
1)复合键
包含两个或更多属性的键成为复合键。
类似于单列键,复合键也可以是唯一或者非唯一的。
2)候选键与主键
候选键是唯一标识表中每一行的键。候选键可以是单列键,也可以是复合键。
主键(primary key)是DBMS(数据库管理系统)用于唯一标识表中每一行的候选键。
候选键可以有多个,而主键只有一个。
例如:有EMPLOYEE 表: EMPLOYEE (EmployeeNumber, FirstName, LastName, Department, Email, Phone)
用户告诉我们,EmployeeNumber是唯一键,Email是唯一键,复合键(FirstName, LastName, Department)也是唯一键。在设计数据库时,需要选择一个候选键作为主键,我们选择使用EmployeeNumber作为主键。
就像美国大选,希拉里(候选键),川普(候选键)都是候选者,然而最终只能选择其一胜任总统(主键)。可以将候选键作为“竞选”主键的候选者,且只有一个候选者能赢得竞选。
3)代理键
代理键是一个唯一的数值,附加到表上作为表的主键。每次创建行时由 DBMS 分配代理键的唯一值,该值永远不变。
理想的主键是较短的数字值,且永远不变。有时,表没有理想的主键,数据库设计人员将添加代理键如 PropertyID 。
代理主键的值对于用户没有任何意义,因此通常在表单或报表中隐藏它们。
MySQL使用AUTO_INCREMENT函数自动分配代理键的数值。
4)外键与参照完整性
将一个表的值放入第二个表来表示关联,所使用的值是第一个表的主键值(有必要时可包括复合主键值)。此时,在第二个表中保存这些值的属性成为外键。
主键与外键的列名不一定相同,唯一的要求是它们的值集必须相同。
例如:以下两个表EMPLOYEE和保存部门数据的DEPARTMENT 表:
EMPLOYEE (EmployeeNumber, FirstName, LastName,Department, Email, Phone)和
DEPARTMENT (DepartmentName, BudgetCode, OfficeNumber, DepartmentPhone)
下划线标明的分别为两个表的主键。现在假设 EMPLOYEE 中的Department字段包含雇员所属部门的名称。而DEPARTMENT中的DepartmentName也包含这些名称。因此,EMPLOYEE 中的 Department 是 DEPARTMENT 的外键,用斜体表示。
因此应声明以下规则:
EMPLOYEE 中 Department 的值必须在 DEPARTMENT 的 DepartmentName 中存在对应项
这个规则成为参照完整性约束。只要看到一个外键,就总是能看到与之相关的参照完整性约束。
为什么需要参照完整性约束规则呢?假设我们没有这个规则,那么外键就失去了作为两个表的关联的作用。
3、NULL值的问题
NULL 值是表的某个单元格中缺失的值。
DBMS 产品允许指定列中能否有NULL 值。
4、函数依赖与规范化
1)函数依赖
函数依赖指一个属性(或属性集合)值决定另一个属性(或属性集合)值的情况。
例如:假设袋子里装着红、蓝或黄三种物品中的一种,再假设红色的物品重5磅,蓝色的重5磅,黄色的重 7 磅。如果一个朋友看过袋子里的物品,并告诉您它的颜色,您就可以告诉她物品的重量。如前面的例子所示,可以得出:
ObjectColor → Weight
因此可以说,Weight函数依赖于ObjectColor,或者ObjectColor决定Weight。称ObjectColor为决定因子。这个关系没有涉及任何等式,但函数依赖仍成立。只要给定ObjectColor的值,就能确定物品的重量。
另外,假设红色的物品是圆的,蓝色的是方的,黄色的也是方的,就可以说:
ObjectColor → Shape
即 ObjectColor决定Shape。将上述两个关系合并在一起:
ObjectColor→(Weight, Shape)
即 ObjectColor决定Weight和Shape。
另一种表示这些关系的方法就是将它们放入表中。即关系表。如果将其称为 OBJECT 表,并使用 ObjectColor 作为主键,就可以将该表写为:
OBJECT (ObjectColor, Weight, Shape)
使用该表的原因是要存储函数依赖的实例 ,这里存储的内容表达了ObjectColor → (Weight, Shape)函数依赖。
2)再论主键与候选键
具体而言,表的主键可以定义为该表中一个或多个可以通过函数决定其他所有属性的属性。该定义也适用于候选键。
3)规范化
一个表应只有一个主题,所以规范化(normalization)定义为如下过程:将一个具有多个主题的表分割为一组表,使每个表只有一个主题。
例如:以下表
ADVISER_LIST (AdviserID, AdviserName, Department, Phone, Office,StudentNumber, StudentName)
这个表的主键是什么?
根据主键和候选键的定义,主键必须是决定其它所有属性的属性。唯一具有这个特征的属性只有StudentNumber,若给定StudentNumber的值,就可以确定其它所有属性的值:
StudentNumber → (AdviserID, AdviserName, Department, Phone, Office,StudentName)
因此该表可以表示成(下划线代表主键):
ADVISER_LIST (AdviserID, AdviserName, Department, Phone, Office,StudentNumber, StudentName)
然而该表存在修改问题。比如,每名教师的数据会在表中重复多次,但对每个学生只有一次,这就意味着对教师数据的更新需要执行很多次。假如某位教师更换了办公室,就需要修改其在学生表中的每一行。如果他有20名学生,那么就需要修改20次。从列表中删除一名学生时,还可能出现另一个修改问题。如果删除了某教师唯一的学生,就会删除该学生及其教师的数据。
仔细看看上述表,就会发现有一个涉及教师数据的函数依赖:
AdviserID → (AdviserName, Department, Phone, Office)
也就是说,这个表的结构存在问题,因为它有一个与主键无关的函数依赖。AdviserID是函数依赖中的决定因子,但它不是该表的候选键,更不可能成为主键。
4)表的设计原则
(1) 在结构良好的表中,每个决定因子都必须是候选键。
(2) 非结构良好的表应分解成两个或多个结构良好的表。
规范化就是检查并修改表使其结构良好的过程。
5)规范化过程
(1) 标识表的所有候选键。
(2) 标识表中的所有函数依赖。
(3) 检查函数依赖的决定因子。如果某决定因子不是候选键,则表的结构就不好。此时:
a. 把函数依赖的列放在它自己的新表中。
b. 把函数依赖的决定因子作为新表的主键。
c. 将决定因子的副本作为原表中的外键。
d. 在新表和原表之间创建参照完整性约束。
(4) 根据需要,多次重复步骤(3),直至每个表的决定因子都是候选键。
快乐学习
开心成长