我们读不同的描写数据库的文章，会看到不同的概念名称，从某种意义上来讲，是公说公有理，婆说婆有理的问题，只是个人理解不同而称呼有异，这也给一些人，尤其是初学者带来一定的困扰，鉴于此，特整理《数据库常用专业术语的基本概念的定义与理解》这篇文章，行文参考了很多网上的资料(请原谅我不喜欢看书)，并加入了我自己的理解，如有谬误，请指正。
实体
实体是指现实世界中客观存在的并可以相互区分的对象或事物。至于如何定义一个实体，则会根据不同的需要，不同的视角有所不同，比如我们将生物作为实体，那么我们就考虑这个实体有哪些属性，首先生物是生命体，其次可繁殖等等，也可以将某一种生物当作一个实体看待，比如人这种生物，按照人种这一属性，可以分为黄色人种、亚美人种、蒙古人种、蒙古利亚人种等。就数据库而言，实体往往指某类事物的集合。也就是数据库表，可以是具体的人、事、物，也可以是抽象的概念、
实体属性
属性是实体之间相互区分的最基本特征，是对象或事物具象的描述。比如有两个人，一个姓名叫张三、一个叫姓名李四，那么姓名就是张三、李四这两个实体相互区分的属性。值得注意的是，实体属性依然会根据我们视角的不同而有不同的划分。
数据库
数据库就是存储数据的仓库，其本质是一个文件系统，数据按照特定的格式将数据存储起来，可视为电子化的文件仓库。数据库分为关系数据库与非关系数据库(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