数据库-理论知识_dbs包括db、dbms和dba吗

简介

数据库系统dbs包括：数据库、硬件、软件（dbms、db）、人员（dba）

三级模式、两级映像：

1. 三级模式是外部层（用户）、概念层（sql）、内部层（db）:
   • 外模式(externalLevel)：面向应用程序，描述用户的数据视图(View,可用来实现权限等)
   • 内模式InternalLevel（又称为物理模式、存储模式）：面向物理上的数据库，描述数据在磁盘中如何存储；
   • 概念模式 ConceptualLevel（又称为模式、逻辑模式）：面向数据库设计人员，描述数据的整体逻辑结构。
2. 二级映像值得桥梁：外-概念、概念-内

二级映像的独立性

通过二级映像，体现了逻辑和物理两个层面的数据独立性

1. 逻辑独立性。外模式概念模式映像体现了逻辑独立性。逻辑独立性是指当修改了概念模式，不影响其上一层的外模式。例如，将基本表的“库存和销量”拆分到另一张表中，此时概念模式发生了更改，但可以通过改变外模式概念模式的映像，继续为用户提供原有的视图
2. 物理独立性。概念模式内模式映像体现了物理独立性。物理独立性是指修改了内模式，不影响其上层的概念模式和外模式。例如，在excel中将.xls文件另存为.xlsx文件，虽然更换了文件格式，但是打开文件后显示的表格内容一般不会发生改变。在数据库中，更换更先进的存储结构，或者创建索引以加快查询速度，内模式会发生改变。此时，只需改变概念模式内模式映像，就不会影响到原有的概念模式

数据库设计

共三个有产出物，记住每个产出对应的阶段。5、6不重要

1. 需求分析：即分析数据存储的要求，产出物有数据流图（DFD）、数据字典（DD）、需求说明书（SRS）。获得用户对系统的三个要求：信息要求、处理要求、系统要求。
2. 概念结构设计：就是设计ER图，也即实体联系图。工作步骤包括：选择局部应用、逐一设计分ER图、ER图合并。分ER图进行合并时，它们之间存在的冲突主要有以下3类。
   • 属性冲突。同一属性可能会存在于不同的分ER图中。
   • 命名冲突。相同意义的属性，在不同的分ER图上有着不同的命名，或是名称相同的属性在不同的分ER图中代表着不同的意义。（一般加表名前缀）
   • 结构冲突。同一实体在不同的分ER图中有不同的属性，同一对象在某一分ER图中被抽象为实体而在另一分ER图中又被抽象为属性。
3. 逻辑结构设计：将ER图，转换成关系模式（产出关系模式，加入范式，表状、网状解构等）。工作步骤包括：确定数据模型、将ER图转换成为指定的数据模型、确定完整性约束（小数点位数等）和确定用户视图。
4. 物理设计（没有产出）：步骤包括确定数据分布、存储结构和访问方式。（数据库读写分离等设计）
5. 数据库实施阶段：根据逻辑设计和物理设计阶段的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。
6. 数据库运行和维护阶段：数据库应用系统经过试运行即可投入运行，但该阶段需要不断地对系统进行评价、调整与修改。

数据模型

在数据库设计的概念产出er图，逻辑结构设计，产出关系模型。分为以下几种:

• 概念模型是从用户的角度进行建模的，是现实世界到信息世界的第一抽象，是真正的实体-联系模型。E-R模型
  1. 用E-R图来描述溉念数据模型，世界是由一组称作实体的基本对象和这些对象之间的联系构成的。在E-R模型中，使用椭圆表示属性（一般没有）、长方形表示实体、菱形表示联系，联系的两端要填写联系类型。多2条竖线的实体是弱实体，不带的是强实体，像员工和经理（弱实体）都可以归于员工实体
  2. 实体：客观存在并可相互区别的事物。可以是具体的人、事、物或抽象概念。如人、汽车、图书、账户、贷款。
     • 弱实体和强实体：弱实体依赖于强实体的存在而存在。
     • 实体集：具有相同类型和共享相同属性的实体的集合，如学生、课程。
  3. 属性：实体所具有的特性。
     • 属性分类：简单属性和复合属性；单值属性和多值属性；NULL属性；派生属性（可以通过其他属性运算出来，比如年龄可以根据出生日期)。
     • 域：属性的取值范围称为该属性的域。
     • 码(key):唯一标识实体的属性集。
  4. 联系：现实世界中事物内部以及事物之间的联系，在E-R图中反映为实体内部的联系和实体之间的联系。
     • 一对一（1：1）：联系可以放到任意的两端实体中，作为一个属性（要保证1：1的两端关联），也可以转换为一个单独的关系模式；
     • 一对多(1：N)：联系可以单独作为一个关系模式，也可以在N端中加入1端实体的主键； 如在emp表中加入1端的主键did，这和dj的foreignkey中放入子表中很相似
     • 多对多(M:N)：联系必须作为一个单独的关系模式，其主键是M和N端的联合主键。2种方式
       1. 关联表中建立 id、sid、cid三个字段
       2. 关联表中放置 sid-cid 联合主键，不用id主键。同时该表是令2张表的主键对应的外键。联合主键的表示是(主键1，主键2)，要用括号括起来表示
• 关系模型是二维表的形式表示的实体-联系模型，是将实体-联系模型转换而来的，经过开发人员设计的；
  1. 关系模型中数据的逻辑结构是一张二维表，由行列组成。用表格结构表达实体集，用外键标识实体间的联系。是表格结构，首行是属性，其它行为元组：
  2. 优点：建立在严格的数学概念基础上；概念单一、结构简单、清晰，用户易懂易用；存取路径对用户透明，从而数据独立性、安全性好，简化数据库开发工作。
  3. 缺点：由于存取路径透明（是隐蔽的意思，计算机中很多时候将计算机中很多外界看不到的部分称为是透明的，这与现实中某件事情是透明 的所表达的意思恰恰相反。），查询效率往往不如非关系数据模型。
• 网状模型表示实体类型及其实体之间的联系，一个事物和另外几个都有联系，形成一张网。
• 面向对象模型是采用面向对象的方法设计数据库，以对象为单位，每个对象包括属性和方法，具有类和继承等特点。

数据模型三要素：数据结构（所研究的对象类型的集合）、数据操作（对数据库中各种对象的实例允许执行的操作的集合）、数据的约束条件（一组完整性规则的集合）。

E-R模型转换为关系模型：E-R图是全局的设计概念，不适合进行计算机处理，为了适应关系数据库的处理，必须将E-R图转为关系模型。
E-R图是由实体、属性和联系三要素组成，而关系模型只有一个结构，所以我们使用以下方式进行转换：每个实体都对应一个关系模型，实体名对应关系模型中的名称，实体属性对应关系模型的属性，实体标识符（联系）对应关系模型的码（主键等约束）。

关系模型的代数计算

并（∪）：结果是两张表中所有记录数合并，相同记录只显示一次。
交（∩）：结果是两张表中相同的记录。
差：S1-S2,结果是S1表中有而S2表中没有的那些记录。
笛卡尔积（crossjoin）：S1XS2,产生的结果包括S1和S2的所有属性列，并且S1中每条记录依次和S2中所有记录组合成一条记录，最终属性列为S1+S2属性列，记录数为S1*S2记录数。
投影（π):实际是按条件选择某关系模式中的某列，列也可以用数字表示。$ \pi_{1,2}（S1 \times S2）$里面的数字代表第几列。相当于sql中的select选择(\sigma ):实际是按条件选择某关系模式中的某条记录。$ \pi_{1,2}\sigma 1>3 $ 。 等同于sql中的where
自然连接（Natural join $ \bowtie $）：显示全部的属性列，但是相同属性列只显示依次，显示2个关系模式中属性相同且值相同的记录。让具有公共相同属性的表进行连接。几元关系指表连接之后有多少个属性，即2张表属性之和-1 。
并且符号：And 条件并列 $ \land $ 或者$ \vee $

函数依赖

• 函数依赖：给定一个X,能唯一确定一个Y,就称X决定（确定）Y（$ x \rightarrow y , xy \rightarrow z $）
  $）,或者说Y依赖于X。例如：Y=X*X函数，此时X能确定Y的值，但是Y无法确定X的值，比如x=2,y=4,但是y=4无法确定x=2。
• 函数依赖又可扩展以下两种规则：
  1. 部分函数依赖：A可决定C,(A,B)，也可决定C,加括号表示1个组，也可表示为$ AB \rightarrow C $。既然A都可以决定C了，那么要不要B其实都无所谓了，所有这种就称之为部分函数依赖。
  2. 传递函数依赖：当A和B不相同时，A可决定B,B可决定C,则A可决定C,是传递函数依赖；若A和B相同，则不存在传递了，A就可以直接就可决定C。
• 函数依赖公理：函数依赖的公理系统是指一组用于推导和证明函数依赖的规则和公理集合。这些公理系统基本上是数学理论的扩展，包括以下公理和规则：
  • 自反律：对于任意属性集合X和Y,有$ X \subseteq Y $,则X→Y。符号表示为真子集，x属于y
  • 增广律：对于任意属性集合X、Y和Z,如果X→Y,那么XZ→YZ。
  • 合并律：对于任意属性集合X、Y和Z,如果X→Y和X→Z,那么X→YZ。
  • 分解律：对于任意属性集合X、Y和Z,如果X→YZ,则X→Y和X→Z。
  • 合成律：对于任意属性集合X、Y和Z,如果X→Y且Y→Z,那么XZ→YZ。
  • 传递律：对于任意属性集合X、Y和Z,如果X→Y且Y→Z,那么X→Z。

键与约束

键

• 超健：指能够唯一标识关系中每个元组的属性集合。换句话说，超键中的属性组合可以保证每个元组在关系中都是唯一的。举例：假设我们有一个学生表，包含以下属性：学号、姓名、性别、出生日期，那么，以下属性集合都是超键：{学号}、{学号，出生日期}、{姓名，性别，出生日期，因为这些属性组合都可以唯一标识每个学生。
• 候选键：若关系中的某一属性或属性组的值能唯一的标识一个元组，则称该属性或属性组为候选键。
• 主属性：包含在任何候选码中的属性称为主属性。
• 主键：从候选键中选取的一个属性或属性集合，作为表中元组的唯一标识符。举例：在上面的例子中，我们可以选择{学号}作为主键。

约束

• 外键：是指一个表中的属性，它引用另一个表中的主键。外键用于建立表之间的关系。
• 实体完整性约束：即主键约束，主键值不能为空，也不能重复。
• 参照完整性约束：即外键约束，外键必须是其他表中已经存在的主键的值，或者为空。
• 用户自定义完整性约束：自定义表达式约束，如设定年龄属性的值必须在0到180之间。

总结：

超键：能唯一标识记录的属性集合
候选键：最小的超键
主属性：包含在任何候选码中的属性称为主属性。基本上除了候选键之外的属性都是主属性
主键：任选一个候选键。也可认为候选键就是主键

范式

从er概念模型到关系模型的转换中所遵循的准则或指导思想。一般有5个范式，常见的是1NF、2NF、3NF、BCNF。
选择题中满足了3NF基本上不会满足BCNF

• 1NF：要求数据库表中的所有字段都是不可分割的原子值。像薪资分为基本工资和补贴，在一个表中就不符合
  用决定式子来分析是否符合1NF：
  用一个单一的关系模式学生来描述学校的教务系统：学生（学号，学生姓名，系号，系主任姓名，课程号，成绩)
  依赖关系（学号->学生姓名，学号->所在系，所在系->系主任姓名，（学号，课程号）->成绩）
• 2NF：在1NF的基础上，要求数据库表中的每个非主属性完全依赖于候选键。也就是说，一个表只描述一件事物，通俗地说，就是表中不能存在联合主键，按照定义，上面的
  学生表就不满足2NF，因为学号不能完全确定成绩（每个学生可以选多门课）。
  解决方案：将学生表分解为：
  学生（学号，学生姓名，系编号，系名，系主任）
  选课（学号，课程号，成绩）。
  每张表均属于2NF。
• 3NF：在2NF的基础上，要求数据库表中的每个非主属性不依赖于其它主属性。也就是说，数据表中的每一列都和主键直接相关，而不依赖于其它列。
  继续上面的实例，学生关系模式就不属于3NF,因为学生无法直接决定系主任和系名，是由学号->系编号，再由系编号->系主任，系编号->系名，因此存在非主属性对主属性的传递依赖，
  解决方案：将学生表进一步分解为：
  学生（学号，学生姓名，系编号）
  系（系编号，系名，系主任）
  选课（学号，课程号，成绩）
  每张表都属于3NF。
• BCNF: 规范化数据库设计的一种方法，它对关系型数据库中的表进行分解，其符合第三范式(3NF),同时尽量避免数据冗余和不一致性，提高数据的可靠性和完整性。
  假设仓库管理关系表（仓库ID,存储物品D,管理员ID,数量），且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。此关系模式已经属于了3NF,那么这个关系模式是否存在问题呢？我们来看以下几种操作：
  删除异常：当仓库被清空后，所有”存储物品ID”和”数量”信息被删除的同时，”仓库ID”和”管理员ID”信息也删除了。
  插入异常：当仓库没有存储任何物品时，无法给仓库分配管理员。
  更新异常：如果仓库换了管理员，则表中所有行的管理员D都要修改。
  解决方案：把仓库管理关系表分解为二个关系表
  • 仓库管理：（仓库ID,管理员ID):
  • 仓库：（仓库ID,存储物品1D,数量）。
    这样的数据库表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。

画依赖图，候选关键字只有出没有入的，即都是决定别人的

反规范化

反规范化技术：规范化设计后，数据库设计者希望牺牲部分规范化来提高性能。例如，获取到老师信息时，能顺便获取学生的信息，用空间换效率，避免频繁的联表查询
采用反规范化技术的益处：降低连接操作的需求、降低外码和索引的数目，还可能减少表的数目，能够提高查询效率，
可能带来的问题：数据的重复存储，浪费了磁盘空间；可能出现数据的完整性问题，为了保障数据的一致性增加了数据维护的复杂性，会降低修改速度。
具体方式：
增加冗余列：在多个表中保留相同的列，通过增加数据冗余减少或避免查询时的连接操作。
增加派生列：在表中增加可以由本表或其它表中数据计算生成的列，减少查询时的连接操作并避免计算或使用集合函数。如通过生日计算出年龄
重新组表：如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。
水平分割表：根据一列或多列数据的值，把数据放到多个独立的表中，主要用于表数据规模很大、表中数据相对独立或数据需要存放到多个介质上时使用。
垂直分割表：对表进行分割，将主键与部分列放到一个表中，主键与其它列放到另一个表中，在查询时减少IO次数

模式分解

模式分解：是关系数据库规范化设计中的一个重要概念。它指的是通过对关系模式进行拆分，来消除模式中的混合组合依赖，达到将模式分解为更小的模式的过程。一般分为以下
两种：

1. 是否保持函数依赖分解：对于关系模式R,有依赖集F，若对R进行分解，分解出来的多个关系模式，保持原来的依赖集不变，则为保持函数依赖的分解。另外，注意要消除掉冗余依赖（如传递依赖)
2. 有损无损分解：分解后的关系模式能够还原出原关系模式，就是无损分解，不能还原就是有损

是否保持函数依赖案例：设原关系模式R(A,B,C),依赖集F(A->B,B->C,A->C),将其分解为两个关系模式R1(A,B)和R2(B,C),此时R1中保持依赖A->B,R2保持依赖B->C,说明分解后的R1和R2是保持函依赖的分解，因为A->C这个函数依赖实际是一个冗余依赖，可以由前两个依赖传递得到，因此不需要管。

当分解为两个关系模式，可以通过以下定理判断是否无损分解：

• 定理：如果R的分解为p={R1,R2},F为R所满足的函数依赖集合，分解D具有无损连接性的充分必要条件是R1∩R2->(R1-R2)或者R1∩R2->(R2-R1)。
• 当分解为三个及以上关系模式时，可以通过表格法求解

总结：看是否有无损，就用交集算；看是否保持函数依赖，看分解后的能否推导出原函数依赖

并发控制和封锁协议

事务：由一系列DML操作组成，这些操作，要么全做，要么全不做，它从第一个DML操作开始，rollback、commiti或者DDL结束，拥有以下四种特性（acid属性），详解如下：

• (操作)原子性Atomicity:要么全做，要么全不做，例如银行转账，在没到最后一步完成转账之前，前面的所有操作都是无效的。
• (数据)一致性Consistency:事务发生后数据是一致的，例如银行转账，不会存在A账户转出，但是B账户没收到的情况。
• (执行)隔离性Isolation:任一事务的更新操作直到其成功提交的整个过程对其他事务都是不可见的， 不同事务之间是隔离的，互不干涉。(一个人在操作，其他人不可以操作)
• (改变)持续性Durability:事务操作的结果是持续性的。
  事务是并发控制的前提条件，并发控制就是控制不同的事务并发执行，提高系统效率，但是并发控制中存在下面三个问题：

1. 丢失更新：事务1对数据A进行了修改并写回，事务2也对A进行了修改并写回，此时事务2写回的数据会覆盖事务1写回的数据就丢失了事务1对A的更新。即对数据A的更新会被覆盖。
2. 不可重复读：事务2读A,而后事务1对数据A进行了修改并写回，此时若事务2再读A,发现数据不对。即一个事务重复读A两次会发现数据A有误。
3. 读脏数据：事务1对数据A进行了修改后，事务2读数据A,而后事务1回滚，数据A恢复了原来的值，那么事务2对数据A做的事是无效的，读到了脏数据。

其它时候并行操作，唯独操作数据的时候加锁，变为串行操作

锁协议

• X锁是排它锁（写锁）。若事务T对数据对象A加上x锁，则只允许T读取和修改A,其他事务都不能再对A加任何类型的锁，直到T释放A上的锁。
• S锁是共享锁（读锁）。若事务T对数据对象A加上S锁，则只允许T读取A,但不能修改A,其他事务只能再对A加S锁（也即能读不能修改)，直到T释放A上的S锁。

共分为三级封锁协议，如下：

1. 一级封锁协议：事务在格改数据之前必须先对其加X锁，直到事务结束才释放。可解决丢失更新问题。
2. 二级封锁协议：一级封锁协议的基础上加上事务T在读数据R之前必须先对其加S锁，读完后即可释放S锁。可解决丢失更新、读脏数据问题
3. 三级封锁协议：一级封锁协议加上事务T在读取数据R之前先对其加S锁，直到事务结束才释放，可解决丢失更新、读脏数据、数据重复读问题

sql答题技巧：对于选择题，如果看到属性名和AVG等函数，在select中出现，那一定是group by

nosql数据库

NoSQL:Non-Relational或者是Not Only SQL,泛指排关系型数据库，区分开关系型数据库，并且不保证关系型数据库的ACID特性。
NoSQL的分类：

• 列式存储数据库：跟传统的关系型数据库一样，数据按行列进行存储，这种类别通常用来应对分布式数据库的存储海量数据，比如HBase
• 键值对存储数据库：以key-vaue的形式来存储数据，特点是简单、容易部署，比如Redis
• 文档型数据库：类似于键值对数据库，可以看成是键值对数据库的升级版，允许嵌套键值，处理复杂数据的时候比传统的键值对存储效率高，比如MongoDB
• 图数据库：使用灵活的图形模型来存储数据，能够拓展到多个服务器上，适合存储通过图进行建模的数据，比如社交网络、交通网络等，常见的产品有Neo4)

NoSQL的特征：易拓展、大数据量、高性能、灵活的数据模型、高可用
NoSQL的框架分层（从下至上）：数据持久层、数据分布层、数据逻辑模型层和接口层，层次之间相辅而成，协调工作
NoSQL适用于哪些场景：数据模型比较简单、需要灵活性更强的系统、对数据性能要求高、不需要高度的数据一致性