数据库「关系模型」的基本概念
关系数据库由表(table)的集合构成，每张表都被赋予唯一的「表名」。
比如说我们有一张「instructor」表，它存储有关「教师」的信息。
这张表有 4 列，ID、name、dept_name、salary，这个表的每一行记录了一位教师的相关信息。
一般来说，表中的一行代表了一组值之间的某种联系。
由于一张表就是这种联系的一个集合，这个表的概念和数学上的关系概念有着密切的关联，这也就是「关系数据模型」名称的由来。
在关系模型中有一些术语，比如说「关系」用来指代「表」，「元组」用来指代「行」，「属性」用来指表中的「列」。
基本操作与概念
关系数据模型的基础是表格，数据库系统通过这些表格存储数据，用户可以对它们执行以下操作：
查询：从表中获取数据。
插入：向表中添加新的数据行(元组)。
删除：从表中删除某一行数据。
更新：修改表中某一行的数据。
我们需要区分「数据库模式」和「数据库实例」两个概念：
模式：数据库的逻辑设计，就像建筑的蓝图，定义了数据的结构。
实例：在某一时刻数据库中数据的快照，就像建筑中当前的房间分布和物品摆放，可以随时间变化。
数据库实例的概念对应于程序设计语言中变量的概念，而关系模式的概念对应于程序设计语言中类型定义的概念。
实例变量可能随时间发生变化，类似地，随着关系被更新，关系实例的内容也会随时间发生变化。
原子性
关系(表)的每个属性都存在一个允许取值的集合，称为该属性的「域」。例如，salary 属性的域就是所有工资值的集合，而 name 属性的域就是所有教师名字的集合。
如果一个「域」中的每个值都不能进一步分解或拆开来表达更细的意义，那么该域就是「原子」的。
一个 age 属性的域可能是正整数，如 {1. 2. 3. ...};
一个 phone_number 属性的域可能是字符串，如 {"123-456-7890"}。
所以 phone_number 属性允许一个单元存储多个号码的集合(如["123-456", "789-101"])，这个集合中的每个号码本身又可以单独使用或分析，那么该属性的域不是原子的。
为什么原子性重要?
在存储和查询数据时，不需要额外解析或拆分复杂的数据结构。
如果属性只能存储一个值，那就可以减少数据不一致的问题。
符合第一范式，表中的每个单元格只能包含一个值，而不能是集合、数组或嵌套数据。
超码、候选码、主码
我们需要一种方式，用属性值来区分关系表中的每一行(元组)，保证没有两行的所有属性值完全一样。
超码
一个或多个属性的组合，只要能唯一标识每一行，就是超码。比如，ID是超码，ID + name也是超码。
候选码
从超码中挑出最小的一组，去掉多余属性，依然能唯一标识每一行。比如，如果ID已经能唯一标识，那ID + name就不能是候选码。
主码
从候选码里选出一个，作为表中区分每行的主要方式，就是主码。
主码代表真实世界中数据的唯一性约束。在数据库设计中，主码一般列在属性表最前面，E-R图中还会用下划线标出。
比如，在上面 instructor 这张表里，ID 就能唯一标识每个老师，所以 ID 是超码。
如果名字和部门的组合也能区分老师，那 ID + name 也能成为超码。
因为 ID 可以是候选码，那 ID 和名字的组合就不能算候选码了，因为多了「name」不必要的属性。
关系查询语言
关系查询语言用来从数据库获取信息，主要有三种类型，每种方式获取信息的方式不同，我们通过从 instructor 表中找到 salary > 80000 的教师，来展示查询语言。
命令式查询语言
详细告诉数据库执行哪些步骤，类似编程时一步步写明如何完成任务。
OPEN Instructor;WHILE NOT END_OF_FILE DO IF Salary > 80000 THEN PRINT Name, Salary; END IF; FETCH NEXT RECORD;END WHILE;CLOSE Instructor;
用户明确说明了要遍历表中的每一行，检查条件并打印符合要求的结果。命令式更像是手动操作，注重实现过程。
函数式查询语言
通过调用函数完成查询，每个函数处理特定任务，不影响系统状态，功能单一、独立。
Filter(Instructor, Salary > 80000)
函数会过滤出Salary大于80000的数据，函数的设计类似于map、filter等高阶函数，函数式通过函数处理数据，逻辑清晰但抽象。
声明式查询语言
用户只需描述想要的结果，而不需要关心怎么实现，数据库系统自动完成查询。
SELECT Name, Salary FROM Instructor WHERE Salary > 80000;
用户只表达了“想要哪些信息”，声明式直接表达需求，让数据库处理实现细节，不需要关心系统如何查询数据。
优势与局限性
关系型数据库通过预定义的表结构来存储和组织数据，数据以行和列的形式存储，并且每个表都有明确的模式(包括属性和数据类型)。
这种结构在处理固定、结构化的数据时非常高效，但对于那些需要灵活变动数据类型或结构的应用，关系型数据库的预定义结构就可能显得有些局限。
所以，在现代企业中，需要在高效处理和灵活性之间找到一个平衡点。
图片来源：Pixabay
