学完数据库，我们对SQL SERVER 2008中的部分关键字有了大概的了解，下面我来总结一下几个比较重要的关键字：字段、属性、列、记录（元组）、表、主键、外键。

一、字段：某一个事物的一个特征，或者说是属性

在我们学vb时，总是用到控件的各种属性，比如name属性、captain属性、width属性等属性。类似，在这里的某一个字段就是对“员工“控件中的属性。

二、记录（元组）：事物特征的组合，可以描述一个具体的事物。

在vb中当我们将一个控件的所有的属性都设置好后，我们就可以对整个控件的样子有个一详细的了解。在数据库中也是这样，当我们在完成一条记录以后，一个员工的详细信息也就清楚了。元组是记录的另个一称呼。

三、表：记录的组合 表示同一类事物的组合

       表，相当于具有相似特征事物的一个集合。如同vb中许多具有具体属性的textbox控件。

四、列：字段的另一种称谓

五、元组：记录的另一种称谓

下面我们再来说一说另一个概念

六、主键：能唯一标识信息的事物

在说主键之前，先看上面一个表格，上述格式可以存储信息，但是某一天当出现两个姓名，性别、年龄都相同的张三时，就无法辨别，我们管这种现象叫做冗余，并且这两信息就无法辨别，所以这是就需要设置一个特定的东西来唯一的标识信息。所以我们就用编号来唯一标识员工的信息。那么我们管这个能唯一标识信息的事物叫做主键。即此表格的编号是主键。

七、外键：一个执行另个一个表的指针

在讨论外键之前，我们先看看先看看下面的图。

当在员工信息表中在填上部门、部门人数、部门地址等几个属性后。你发现了什么问题。或者说能不能把员工的信息和部门信息放到一起？

不能！！为什么？因为从前三名可以看出，如果几个人都属于一个部门，那么部门，人数，部门地址信息重复了三次，所以当有大量的人同属一个部门时再次会造成信息冗余。

现在我们该怎么办呢——看下表：

对，就是通过将连个信息表分开的方法，你看这样的话，部门信息的输入工作了少多了吧。但是当员工信息和部门信息两个表分开来写时，的确减少的信息冗余，但是如何建立关系呢？这时我们可以通过部门编号建立关系，此时的“部门编号”就是“员工信息”表（不是“部门信息”表）的关系链——外键。（注意在两个表分开写后，我们为“部门信息”增加一个主键“部门编号”当然如果不增加的话，部门名称同样可以成为“部门信息”表的主键）

此时的外键如同指向“部门信息”表中某一具体记录的地址指针（不懂指针的宝宝请暂时飘过），通过员工对应“指针”去部门信息表找对应的部门具体信息。

我们读不同的描写数据库的文章，会看到不同的概念名称，从某种意义上来讲，是公说公有理，婆说婆有理的问题，只是个人理解不同而称呼有异，这也给一些人，尤其是初学者带来一定的困扰，鉴于此，特整理《数据库常用专业术语的基本概念的定义与理解》这篇文章，行文参考了很多网上的资料(请原谅我不喜欢看书)，并加入了我自己的理解，如有谬误，请指正。

实体

实体是指现实世界中客观存在的并可以相互区分的对象或事物。至于如何定义一个实体，则会根据不同的需要，不同的视角有所不同，比如我们将生物作为实体，那么我们就考虑这个实体有哪些属性，首先生物是生命体，其次可繁殖等等，也可以将某一种生物当作一个实体看待，比如人这种生物，按照人种这一属性，可以分为黄色人种、亚美人种、蒙古人种、蒙古利亚人种等。就数据库而言，实体往往指某类事物的集合。也就是数据库表，可以是具体的人、事、物，也可以是抽象的概念、

实体属性

属性是实体之间相互区分的最基本特征，是对象或事物具象的描述。比如有两个人，一个姓名叫张三、一个叫姓名李四，那么姓名就是张三、李四这两个实体相互区分的属性。值得注意的是，实体属性依然会根据我们视角的不同而有不同的划分。

数据库

数据库就是存储数据的仓库，其本质是一个文件系统，数据按照特定的格式将数据存储起来，可视为电子化的文件仓库。数据库分为关系数据库与非关系数据库(NoSql数据库)。数据库实现了数据的新增、查询、更新、删除等操作，并提供了完善的数据管理相关的功能，如权限、事务等，并定义了表(实体)与表(实体)之间的关系。

数据库中以表为组织单位存储数据。表与实体之间应该是一一对应的关系，可以把表当作实体在数据库中的描述。数据库表描述的实体是具有一些列共同实体属性的数据的集合，比如学生表，描述了学生这一实体，而学校表描述了学校这一实体，将学生与学校分别建表存储。这里容易让人迷糊的是在个别时候，数据表中的一行记录也被叫做实体，这个确实也是对的，这是因为将学生看作实体与将某一个学生看作一个实体的时候我们的视角不一样了。是不是感觉很随意？是的就是这么随意。

字段

字段是数据表中实体所具有的某一特性，在关系数据库中，属性可以看作是“表的一列”。如上面学生这一尸体可能具有姓名、性别、年龄、爱好等属性，对应到学生表中则是姓名、性别、年龄、爱好等字段。

元组(记录/行)

表中的一行记录就是一个元组，元组也称为行。

分量(字段/属性)

元组的某个属性值叫做分量，实际上就是数据库中的字段，也即实体的属性。在一个关系数据库中，它是一个操作原子，即关系数据库在做任何操作的时候，属性是“不可分的”。否则就能满足数据库范式。

码(主键、主关键字)

码也就是我们常说的主键、主关键字，他们都是一个意思。

码是能唯一标识实体的属性，它是整个实体集的性质，而不是单个实体的性质。它包括外码、候选码和主码。表中可以唯一确定一个元组的某个属性(或者属性组)，如果这样的码有不止一个，那么大家都叫 候选码，我们从候选码中挑一个出来做老大，它就叫主码。

如果一个码包含了所有的属性，这个码就是全码。

一个属性只要在任何一个候选码中出现过，这个属性就是主属性

一个属性(或属性组)，它不是码，但是它别的表的码，它就是外码。

若关系中的某一属性或属性组的值能唯一的标识一个元组，而其任何真子集都不能再标识，则称该属性组为(超级码)候选码。

数据完整性约束

数据完整性约束指的是为了防止不符合规范的数据进入数据库，在用户对数据进行插入、修改、删除等操作时，DBMS自动按照一定的约束条件对数据进行监测，使不符合规范的数据不能进入数据库，以确保数据库中存储的数据正确、有效、相容。

我们常见的有：

not null(非空)约束：定义字段不能为空值，如果新增数据非空约束的字段值为空，则不能写入并报错。

unique(惟一)约束：用于指明创建惟一约束的列上的取值必须惟一。

primary key(主键)约束：用于定义基本表的主键，起唯一标识作用，其值不能为null,也不能重复，以此来保证实体的完整性。

foreign key(外键)约束：定义了一个表中数据与另一个表中的数据的联系。

check(校验)约束：用来检查字段值所允许的范围。DBMS每当执行delete,insert或update语句时，都对这个约束过滤。如果为true，则执行。否则，取消执行并提示错误。

依赖关系

数据依赖是一个数学概念，是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系，数据依赖是现实世界属性间相互联系的抽象，属于数据内在的性质。在计算机科学中，数据依赖是指一种状态，当程序结构导致数据引用之前处理过的数据时的状态。

复杂的数学公式推导有兴趣的朋友可以自行查看。

简单来说在数据库中依赖关系就是描述数据库不同字段(属性)之间的关系。比如管理员id 依赖仓库id， 物品id 依赖仓库id。在这个以来关系中管理员id 到物品id是存在依赖关系的，依赖关系对于理解数据库范式很重要。

部分依赖

部分函数依赖：设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。

举个例子：学生基本信息表R中（学号，身份证号，姓名）当然学号属性取值是唯一的，在R关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；所以姓名部分函数依赖与（学号，身份证号）；

完全依赖

完全函数依赖：设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。
例子：学生基本信息表R（学号，班级，姓名）假设不同的班级学号有相同的，班级内学号不能相同，在R关系中，（学号，班级）->（姓名），但是（学号）->(姓名)不成立，（班级）->(姓名)不成立，所以姓名完全函数依赖与（学号，班级）；

传递依赖

传递函数依赖：设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。
例子：在关系R(学号 ,宿舍, 费用)中，(学号)->(宿舍),宿舍！=学号，(宿舍)->(费用),费用!=宿舍，所以符合传递函数的要求；

范式

英文名称是 Normal Form，它是英国人 E.F.Codd(关系数据库的老祖宗)在上个世纪70年代提出关系数据库模型后总结出来的，范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。

在使用mysql中对表的设计，我们需要遵循三大范式。设计关系型数据库时，遵从不同的规范和要求，设计出合理的关系型数据库，这些不同的规范和要求称为不同的范式。各种范式呈递次规范，越高的范式数据库冗余越小。但也意味着数据库表关系越复杂。

若要遵循后面的范式必须遵循之前的范式。1NF<2NF<3NF<…>

目前关系数据库有六种范式：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF，又称完美范式)。

巴斯-科德范式因为并没有定义新的规范，只是对第三范式(3NF)的补充与完善，所以并没有命名为第四范式。

通常所用到的只是前三个范式，即：第一范式(1NF)，第二范式(2NF)，第三范式(3NF)。也即我们常说的设计数据库的三大范式。
1NF 一言以蔽之：“第一范式的数据表必须是二维数据表”，第一范式是指数据库的每一列都是不可分割的基本数据项，强调列的原子性，试题中某一属性不能拥有几个值。比如数据库的电话号码属性里面不可以有固定电话和移动电话值，如下图：

说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
再例如：

列1唯一确定列2, 列3, 列4, ...，即列2, 列3, 列4, ...不能再分裂出其它列。

假设有关系模式列1: 订单名; 列2: 商品。一个订单下可以有多个商品，即列2: 商品可以分裂成商品A, 商品B, 商品C, ...，所以列1: 订单名; 列2: 商品这样的关系模式不符合第一范式。

2NF

满足2NF的前提是必须满足1NF。此外，关系模式需要包含两部分内容，一是必须有一个（及以上）主键；二是没有包含在主键中的列必须全部依赖于全部主键，而不能只依赖于主键的一部分而不依赖全部主键。

定义听起来有点绕，不慌，直接看上图，只有全部的非主键列依赖于全部主键，才满足第二范式。

3NF 若某一范式是第二范式，且每一个非主属性都不传递依赖于该范式的候选键，则称为第三范式，即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。

举例来说：Employee(emp_id,emp_name,emp_age,dept_id,dept_name,dept_info)，当员工表中emp_id能够唯一确定员工员工信息，但是dept_name可由dept_id唯一确定，此时，该表不符合第三范式，此时可以删除除了dept_id之外的其他部门信息，把所有部门信息单独建立一张部门表。

再例如：
满足3NF的前提是必须满足2NF。另外关系模式的非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列m既依赖于全部主键，又依赖于非主键列n的情况。

定义听起来还是有点绕，不慌，直接看上图，只要非主键内部存在传递依赖，就不满足第三范式。

假设存在关系模式主键1: 课程编号; 列1: 教师名; 列2: 教师家庭地址。显然满足第一范式和第二范式，但是教师家庭地址传递依赖于教师名，所以不满足第三范式。

示例:

设有课程关系模式如下：R(C#, Cn, T, Ta)（其中C#为课程号，Cn为课程名，T为教师名，Ta为教师地址），并且假定不同的课程号可以有相同的课程名，每门课程只有一位任课教师，但每名教师可以有多门课程。关系R范式最高达到（）。

A）1NF
B）2NF
C）3NF
D）BCNF

【正确答案】B

【解析】

一个“课程号”确定一个“课程名”，确定一个“教师名”，确定一个“教师地址”，所以符合第一范式；

“课程号”是无重复的，所以“课程号”是主键，“课程名”、“教师名”、“教师地址”均是可重复的，所以它们都是非主键列并完全依赖于主键“课程号”，所以符合第二范式；

非主键列“教师地址”传递依赖于非主键列“教师名”，所以不符合第三范式，故选B。

BCNF 在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。

（1）所有非主属性对每一个码都是完全函数依赖；
（2）所有的主属性对于每一个不包含它的码，也是完全函数依赖；
（3）没有任何属性完全函数依赖于非码的任意一个组合。

R属于3NF，不一定属于BCNF，如果R属于BCNF，一定属于3NF。

假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：

(仓库ID, 存储物品ID) →(管理员ID, 数量)

(管理员ID, 存储物品ID) → (仓库ID, 数量)

所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：

(仓库ID) → (管理员ID)

(管理员ID) → (仓库ID)

即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。

非关系数据库

各个数据之间存在关联是关系型数据库得名的主要原因，为了进行join处理，关系型数据库不得不把数据存储在同一个服务器内，这不利于数据的分散，这也是关系型数据库并不擅长大数据量的写入处理的原因。相反NoSQL数据库原本就不支持Join处理，各个数据都是独立设计的，很容易把数据分散在多个服务器上，故减少了每个服务器上的数据量，即使要处理大量数据的写入，也变得更加容易，数据的读入操作当然也同样容易。

关系型数据库应用广泛，能进行事务处理和表连接等复杂查询。相对地，NoSQL数据库只应用在特定领域，基本上不进行复杂的处理，但它恰恰弥补了之前所列举的关系型数据库的不足之处。

典型的NoSQL数据库：临时性键值存储(memcached、Redis)、永久性键值存储(ROMA、Redis)、面向文档的数据库(MongoDB、CouchDB)、面向列的数据库(Cassandra、HBase)。

整篇参考自https://blog.csdn.net/weixin_39755003/article/details/110619027
https://blog.csdn.net/u014458048/article/details/56678698
https://blog.csdn.net/weixin_43971764/article/details/88677688
https://blog.csdn.net/weixin_28745975/article/details/113140462

第一章 绪论 讨论题2

1. 讨论关系的几个概念 举例说明关系、关系模式、域、元组、属性、分量、码。

1）关系是对现实世界的实体以及实体间的各种联系的描述。
关系模型中数据的逻辑结构是一张二维表

2）关系模式

关系模式是对关系的描述，描述的是关系的结构和本质特征
关系名（属性1，属性2，…，属性n） R(U)
例如：上述二维表对应的关系模式可以表示为：
学生（学号，姓名，年龄，性别，系，年级）

3)域： 是一组具有相同数据类型的值的集合。
例如：整数、实数、介于某个取值范围的整数、指定长度的字符串集合、{‘男’，‘女’}……

4)元组： 关系中的每个元素是关系中的元组，即二维表的每行对应一个元组，通常用t表示。
单元关系与二元关系
当列为1时，称该关系为单元关系（Unary relation）或一元关系
当列为2时，称该关系为二元关系（Binary relation）

5)属性： 关系中不同列可以对应相同的域，为了加以区分，必须对每列起一个名字，称为属性（Attribute）
例如上表中的学号，姓名，年龄，性别，系，年级均为属性。

6)分量： 具体某个元组中在某个属性上的具体取值。
例如: 上述二维表中第2个元组在年龄上的取值为：20

7）码：
候选码（Candidate key）： 若关系中的某一属性组的值能唯一地标识一个元组，而其子集不能，则称该属性组为候选码
简单的情况：候选码只包含一个属性
全码（All-key）： 最极端的情况：关系模式的所有属性组合是这个关系模式的候选码，称为全码（All-key）
主码： 若一个关系有多个候选码，则选定其中一个为主码（Primary key）
主属性： 候选码的诸属性称为主属性（Prime attribute）
不包含在任何侯选码中的属性称为非主属性（Non-Prime attribute）或非码属性（Non-key attribute）
例如：上述二维表中的学号，学号的值能唯一地标识每一个元组，所以学号是该二维表的候选码。

2.讨论两级数据模型与三级模式结构 讨论概念模型、逻辑模型、物理模型与三级模式结构的联系。

1）数据模型分为两类（两个不同的层次）
Ⅰ 概念模型也称信息模型，它是按用户的观点来对数据和信息建模，用于数据库设计。
Ⅱ 逻辑模型和物理模型
逻辑模型主要包括网状模型、层次模型、关系模型、面向对象数据模型、对象关系数据模型、半结构化数据模型等。按计算机系统的观点对数据建模，用于DBMS实现。
物理模型是对数据最底层的抽象，描述数据在系统内部的表示方式和存取方法，在磁盘或磁带上的存储方式和存取方法。
物理模型的具体实现是DBMS的任务，数据库设计人员要了解它，而一般用户不必考虑物理细节。

2）概念模型的用途
①概念模型用于信息世界的建模
②是现实世界到机器世界的一个中间层次
③是数据库设计的有力工具
④数据库设计人员和用户之间进行交流的语言
对概念模型的基本要求
①较强的语义表达能力
②简单、清晰、易于用户理解

3)从数据库应用开发人员角度看，数据库系统通常采用三级模式结构，是数据库系统内部的系统结构
从数据库最终用户角度看，数据库系统的结构分为:
单用户结构
主从式结构
分布式结构
客户-服务器
浏览器-应用服务器／数据库服务器多层结构等

4)模式（Schema）
①数据库逻辑结构和特征的描述
②是型的描述，不涉及具体值
③反映的是数据的结构及其联系
④模式是相对稳定的

5）实例（Instance）
①模式的一个具体值
②反映数据库某一时刻的状态
③同一个模式可以有很多实例
④实例随数据库中的数据的更新而变动

6）
7）模式（也称逻辑模式）
①数据库中全体数据的逻辑结构和特征的描述
②所有用户的公共数据视图
一个数据库只有一个模式
模式的地位： 是数据库系统模式结构的中间层
Ⅰ与数据的物理存储细节和硬件环境无关
Ⅱ与具体的应用程序、开发工具及高级程序设计语言无关
模式的定义
①数据的逻辑结构（数据项的名字、类型、取值范围等）
②数据之间的联系
③数据有关的安全性、完整性要求

8）外模式（也称子模式或用户模式）
①数据库用户（包括应用程序员和最终用户）使用的局部数据的逻辑结构和特征的描述
②数据库用户的数据视图，是与某一应用有关的数据的逻辑表示
③模式与外模式的关系：一对多
Ⅰ. 外模式通常是模式的子集
Ⅱ. 一个数据库可以有多个外模式。反映了不同的用户的应用需求、看待数据的方式、对数据保密的要求
④外模式与应用的关系：一对多
Ⅰ. 同一外模式也可以为某一用户的多个应用系统所使用
Ⅱ. 但一个应用程序只能使用一个外模式

9）内模式（也称存储模式）
（1）是数据物理结构和存取方式的描述
（2) 是数据在数据库内部的表示方式
① 记录的存储方式（例如，顺序存储，按照B树结构存储，按hash方法存储等）
② 索引的组织方式
③ 数据是否压缩存储
④ 数据是否加密
⑤ 数据存储记录结构的规定
（3) 一个数据库只有一个内模式

10）总结：
（1）模式： 描述的是数据的全局逻辑结构
（2) 外模式： 描述的是数据的局部逻辑结构
(3) 同一个模式可以有任意多个外模式 .
(4) 每一个外模式，数据库系统都有一个外模式／模式映象，定义外模式与模式之间的对应关系。映象定义通常包含在各自外模式的描述中
(5) 保证数据的逻辑独立性
① 当模式改变时，数据库管理员对外模式／模式映象作相应改变，使外模式保持不变
② 应用程序是依据数据的外模式编写的，应用程序不必修改，保证了数据与程序的逻辑独立性，简称数据的逻辑独立性

11）
(1) 模式／内模式映象定义了数据全局逻辑结构与存储结构之间的对应关系。
例如，说明逻辑记录和字段在内部是如何表示的
(2) 数据库中模式／内模式映象是唯一的
(3) 该映象定义通常包含在模式描述中
(4) 保证数据的物理独立性
① 当数据库的存储结构改变了（例如选用了另一种存储结构），数据库管理员修改模式／内模式映象，使模式保持不变。
② 应用程序不受影响。保证了数据与程序的物理独立性，简称数据的物理独立性。