关系型数据库知识总结

菜鸟拙见，望请纠正

一：设计

阶段

1：规划阶段：确定是否需要使用数据库，使用哪种类型的数据库，使用哪个数据库产品。

2：概念阶段：概念阶段的主要工作是收集并分析需求。

识别需求，主要是识别数据实体和业务规则。该阶段将参考或产出多种文档，比如“用例图”，“数据流图”以及其他一些项目文档。该阶段结束要可以回答如下问题。

需要哪些数据？数据该被怎样使用？哪些规则控制着数据的使用？谁会使用何种数据？客户想在核心功能界面或者报表上看到哪些内容？数据现在在哪里？数据是否与其他系统有交互、集成或同步？主题数据有哪些？核心数据价值几何，对可靠性的要求程度？

3：逻辑阶段：逻辑阶段的主要工作是绘制E-R图，或者说是建模。E-R图以描述实体间的关系。还需考虑属性的域（值类型、范围、约束）。

4：实现阶段：实现阶段主要针对选择的RDBMS定义E-R图对应的表，考虑属性类型和范围以及约束。

5：物理阶段：在实际物理设备商部署数据库并测试和调优。

原则

命名规范：

表——“模块名_表名”。表名最好不要用复数，不要过长。

存储过程——使用“proc_”前缀。

视图——使用“view_”前缀。

触发器——使用“trig_”前缀。

定义实体关系的原则

当定义一个实体与其他实体之间的关系时，需要考量如下：

牵涉到的实体 ：识别出关系所涉及的所有实体。

所有权： 考虑一个实体“拥有”另一个实体的情况。

基数 ：考量一个实体的实例和另一个实体实例关联的数量。

关系与表数量

描述1:1关系最少需要1张表。

描述1:n关系最少需要2张表。

描述n:n关系最少需要3张表。

范式将帮助我们来保证数据的有效性和完整性。规范化的目的如下：

消灭重复数据。

避免编写不必要的，用来使重复数据同步的代码。

保持表的瘦身，以及减从一张表中读取数据时需要进行的读操作数量

最大化聚集索引的使用，从而可以进行更优化的数据访问和联结。

减少每张表使用的索引数量，因为维护索引的成本很高。

规范化旨在——挑出复杂的实体，从中抽取出简单的实体。这个过程一直持续下去，直到数据库中每个表都只代表一件事物，并且表中每个描述的都是这件事物为止。

关系模式与范式

候选键：若一个属性集能唯一标识一个元组，又不含有多余属性，那么这个属性集称为候选键

主键：及设计者设计数据库时选作元组标识的一个候选键

主属性：包含在任一一个候选键的属性称为主属性

函数依赖：某个属性集决定另一个属性集时，称另一属性集依赖于该属性集。

部分函数依赖：

范式：

关系数据库设计的目的是为了生成一组关系模式，使我们能够既不必存储不必要的冗余信息，又能方便地获取信息。为了是我们方便的达到这个目的，范式设计应运而生。

第一范式：

数据库表的每一列都是不可分割的基本数据项，同一列不能有多个值。及每一列不可再分及满足第一范式。

第二范式：

在第一范式的基础上，每一个非主属性完全依赖于主关键字。完全依赖及不能存在仅依赖主关键字的一部分属性。

第三范式：

在第二范式的基础上，每个非主属性都不传递依赖于候选键时，则为第三范式。

传递依赖：若X→Y，Y→A，并且Y→X，A不是Y的子集，则称A传递依赖于X。及主属性不能通过一个以上的路径走到非主属性。

当我们不能同时满足以下三个设计目标：

• BCNF。
• 无损连接。
• 保持函数依赖。

我们可以放弃BCNF而接受相对较弱的第三范式（3NF）。因为3NF总能找到无损连接并保持依赖的分解

每个BCNF都属于第三范式；

BC范式：

如果关系模式R的所有不平凡的，完全的函数依赖的决定因素（左边的属性集）都是候选码，则R€BCNF，即左边的都是候选键（注意不是主属性）

如果一个关系模式达到了第三范式，并且它只有一个候选键，或则他的候选键都是单属性，那么就达到了BCNF

如果对F+中所有形如 α→β 的函数依赖，其中 α⊆R 且 β⊆R，下面的定义至少有一个成立：

• α→β 是平凡函数依赖（即 β ⊂ α）。（一般来说，平凡函数依赖并没有讨论意义，讨论的都是非平凡函数依赖，即 β ∉⊂ α 的情况）
• α 是模式R的超码。

字符集选择

在能够完全满足应用当下和未来几年发展的前提下，尽量使用小的字符集。应为更小的字符集意味着能够节省空间、减少网络传输字节数，同时由于存储空间小间接的提升了系统的性能。

不同的数据库有不同的字符集应用级别，分别为服务器级别、库级别、表级别、字段级别，通常推荐使用库级别或者表级别。因为库级别或者表级别在保有灵活性的同时，兼顾数据间字符集的统一，这可以给开发省去很多处理字符集的麻烦。

数据类型的选择

1：固定长度和可变长度：

固定长度会空格补全

2：浮点数与定点数

在MySQL中float、double是浮点数，decimal是定点数。

浮点数优势：在长度一定的情况下，浮点数能表示更大的数据范围。

浮点数缺点：精度问题。

二：实体关系模型（ER图）

E-R模型在将现实世界中事实的含义和相互关联映射到概念模式方面非常有用，因此，许多数据库设计工具都利用了E-R模型的概念。E-R模型所采用的三个主要概念是：实体集、关系集和属性。

• 实体：实体是世界中可以区别于其他对象的“事件”或者“物体”，例如，学校里的每个学生、学生选修的每门课程等都是一个实体。
• 属性：属性是实体集中每个成员具有的描述性性质。例如，学生的姓名，学号等。
• 实体集：实体集就是就有相同类型及属性的实体集合，比如，学校里的所有学生，学生选修的所有课程等。
• 关系：关系是多个实体间的相互关联。例如，小明选修语文课程。
• 关系集：关系集是同类关系的集合。例如，所用学生选修课程的集合。

矩形框——研究对象即实体

菱形框——表示关心——框中计入联系名

椭圆形框：对象的组成部分——实体的属性

矩形与矩形之间要有菱形间隔——实体与实体之间要有联系类型

椭圆与椭圆之间不能连线，椭圆可以连接矩形和菱形——实体包含属性，联系包含分支解释

1:1 读作一对一，夫妻双方的男生和女生

1:n 读作一对多，表示1个实体关联多个实体的关系，一个手机只属于一个人，但一个人可以有多部手机，代表一的一方在菱形的临近出设置为1，代表多的一方在菱形出设置为n

n: m 读作多对多，表示多个实体关联多个实体

其中，（学号，姓名，年龄，性别）为学生的属性，（成绩）为选修关系的属性，（课程号，课程名，学分）为课程的属性。学生和课程之间的关系是多对多，即一个学生可以选择多门课程，一门课程可以被多个学生选修。

工具：

VISIO

亿图ProcessOn

主流关系型数据库对比

事务提交方式：

MYSQL 自动提交，Oracle 不自动提交

分页查询：

MYSQL 的 limit

Oracle 的 where rownum <=20

事务隔离级别：

MySQL 是 read commited 的隔离级别，

而 Oracle 是 repeatable read 的隔离级别

事务：

MySQL 在 innodb 存储引擎的行级锁的情况下才可支持事务，而 Oracle 则完全支持事务

持久性：

MySQL 是在数据库更新或者重启，则会丢失数据，Oracle 把提交的 sql 操作线写入了在线联机日志文件中，保持到了磁盘上，可以随时恢复。

并发性：

MySQL 以表级锁为主，对资源锁定的粒度很大，如果一个 session 对一个表加锁时间过长，会让其他 session 无法更新此表中的数据。

虽然 InnoDB 引擎的表可以用行级锁，但这个行级锁的机制依赖于表的索引，如果表没有索引，或者 sql 语句没有使用索引，那么仍然使用表级锁。

Oracle 使用行级锁，对资源锁定的粒度要小很多，只是锁定 sql 需要的资源，并且加锁是在数据库中的数据行上，不依赖与索引。所以 Oracle 对并发性的支持要好很多。

复制：

MySQL:复制服务器配置简单，但主库出问题时，丛库有可能丢失一定的数据。且需要手工切换丛库到主库。

Oracle:既有推或拉式的传统数据复制，也有 dataguard 的双机或多机容灾机制，主库出现问题是，可以自动切换备库到主库，但配置管理较复杂。

主键：

MYSQL 支持主键自增

Oracle 不知此主键自增。