6.1—6.2、6.5、6.12 模型、键与范式¶

本页要点：数据库与管理软件分开；用三级模式解释独立性；先求所有候选键再判断范式；分解同时检查无损与依赖保持。保留旧页中E-R记法与完整性约束的详细解释；SQL、索引和事务各自指向专题。

6.1 数据库系统结构图¶

flowchart TB
  A[外模式：柜员视图] -->|外／概念映像| C[概念模式：全库表、联系与约束]
  B[外模式：风控视图] -->|外／概念映像| C
  C -->|概念／内映像| D[内模式：文件、页与索引组织]

图D2从多个局部视图读到统一逻辑描述，再读到存储实现。外/概念映像可吸收部分逻辑变更，概念/内映像可吸收物理变化；独立性依赖映像及兼容设计，不表示随意删掉业务字段也无需改应用。SQL产品的schema命名空间不等同这里的唯一全局概念模式。以增加索引为例，改变的是内模式，应用仍用同一逻辑查询，体现物理数据独立性；若概念模式拆表后通过兼容视图保持旧应用接口，体现逻辑数据独立性的设计目标。这里两级映像是层间转换关系，不要求某产品存在两个同名实体文件。

独立教材依据为开普敦大学数据库课程第1章ANSI/SPARC三层，本轮实际读取external、conceptual、internal及两类independence正文：多个局部外模式、统一全局描述、一个内模式及接口吸收变化。该材料Physical data independence段有一处“not transparent”与相邻“无需改外模式”和前段“transparent”相矛盾，本页采用其一致的层间隔离定义，不照抄该疑似否定笔误。

6.2 候选键：闭包必须算到底¶

本节函数依赖、闭包与下一节范式分解的独立依据为《Database System Concepts》作者公开第7章Normalization讲义：Functional Dependency Theory、Closure of Attribute Sets、Normal Forms及Lossless Decomposition各节。本轮已实际读取；其无损二元分解判据明确以函数依赖约束为前提。手册例题只提供待核查线索。

函数依赖X→Y表示任意合法关系实例中，同一X值只能对应同一Y值；不能只因当前小样本碰巧不重复就断言成立。Armstrong规则包括自反（Y属于X则X→Y）、增广（X→Y则XZ→YZ）、传递（X→Y且Y→Z则X→Z），用于推导依赖，不是SQL执行顺序。

求闭包从X自身开始，反复应用左部已包含的依赖，直到不再增加属性。闭包覆盖全属性则为超键，还要删除任一组成属性都不再覆盖，才是候选键。例如回忆版2024题52：U={A,B,C,D,E,H}，F={A→B,B→DH,A→H,C→E}，AC闭包从AC加入B、H，再由B加入D，由C加入E，得全体；A、C都不在任何右部，无法由别的属性推出，故唯一候选键AC。来源答案写“两候选码A、B”不成立。

手册23页例A→B、B→C、C→D时唯一候选键为A；再加入D→A后，A、B、C、D每一个单属性都能沿环推出全体，四个都是候选键，不是手册写的只有A和D。只出现在非平凡依赖右部的属性通常无需加入最小键，但位置速判前必须规范依赖，最终以闭包和最小性为准。

6.5 从异常到规范化¶

同一混合表里的插入、删除和修改异常¶

设教学表员工网点(员工号,员工名,网点号,网点名)，员工号为键，且业务规定员工号→网点号、网点号→网点名。最小数据为(E1,甲,B1,东城)、(E2,乙,B1,东城)，同一个网点事实重复两次。

异常	在上述业务约束下的具体表现	原因
插入异常	新设B2“西城”尚无员工，不能在员工号必填且没有占位员工的表里只登记这个网点	网点存在事实被迫依附员工行
修改/更新异常	B1改名“东城支行”，若只改E1行，E2仍为“东城”，同一B1出现两个名称	一次事实变更需要多处同步
删除异常	删除B1最后一名员工的记录时，B1名称也消失，尽管网点仍应保留	删除员工事实连带丢失另一类事实

删除异常可从上面两行依次删至最后一行观察；不是说删除任意员工都一定丢失网点。拆为员工(员工号,员工名,网点号)和网点(网点号,网点名)后，新网点可独立登记、改名只改一行、删除员工不必删除网点；外键及删除策略另行约束。这里的“更新异常”广义可统称三类，狭义修改异常指中间一项，不是并发章节的丢失更新。

依据：本轮实际读开普敦大学第9章Insertion、Amendment、Deletion anomalies，其Scenario 2解释无预订无法登记事件、改名需改多处和删除丢失事件信息。上表是按相同机制构造的独立教学数据，并非来源原表。对应H-6.5-06。

范式约束的是模式及业务函数依赖，不是某张表当前行数。1NF要求每个属性值在该域的模型中是单值；例如把多个电话号码塞成一个可拆列表会阻碍按电话号码约束，通常另建电话号码表。2NF要求每个非主属性完全依赖于每个候选键；(学号,课程号)→成绩而学号→姓名，姓名只靠半个键，故拆学生表与选课表。

3NF的精确定义：每个非平凡依赖X→A，X是超键或A是主属性。教学上常说消除非主属性对候选键的传递依赖；例如账号→网点号→网点名，网点名应放到网点表。BCNF（Boyce-Codd范式）更强：每个非平凡依赖的决定因素X必须是超键，不允许用“右边是主属性”例外。

3NF但非BCNF例：R(学生S,课程C,教师T)，依赖SC→T、T→C。候选键为SC和ST，三属性都是主属性；T→C右边是主属性故不违反3NF，但T不是超键故违反BCNF。拆为TC、ST无损，却不能只靠各表依赖直接约束原SC→T，说明BCNF分解可能不保持依赖。

4NF针对独立的多值事实：人P有多门课程C、多个电话T且二者独立，放在PCT中会生成课程×电话的组合；拆PC和PT消除交叉冗余。精确条件是每个非平凡多值依赖X↠Y的X为超键，不是禁止一切多值依赖。

无损与保持依赖是两件事。二分R→R1,R2在函数依赖模型下，公共属性能决定其中一个子模式全部属性，可保证无损；例如账号→客户号，把R(账号,客户号,姓名)拆为(账号,客户号)、(客户号,姓名)，在客户号→姓名成立时公共客户号决定第二表，连接不产生伪元组。保持依赖要求子模式投影依赖的并能推出原依赖；3NF可构造兼具无损和依赖保持的分解，BCNF通常可无损但不一定依赖保持。规范化减少特定冗余，不保证查询一定变慢，更不等于不用索引或可以随意反规范化。

6.12 E-R转换的数量算例与条件¶

设计按需求分析→概念E-R→逻辑关系及规范化→物理索引与存储→实施→运行维护展开。实体、属性、联系与参与约束的详解沿用下文；例如每员工属于一部门的1:n联系，把部门外键放员工端，不能反放一个“员工号”到部门表来承载全部员工。

回忆版2022题50假定10个实体、3个1:1、4个1:n、5个m:n，所有实体独立成表，1:1及1:n均并入既有表，m:n单建联系表且无其他新增表：关系/主键约束数=10+5=15，外键约束数=3+4+2×5=17。组合主键按一个约束计，不按组成列数计；弱实体、多值属性、独立保存1:1联系等设计改变时，不能继续机械套E+c与a+b+2c。

本轮资料依据¶

手册PDF物理22—24、28页6.1—6.2、6.5、6.12；回忆版2022题46—50、54、88—89（8—9、13页），2024题52（21页）。本次实际访问开普敦大学数据库课程第9章核对BCNF、4NF与分解，PostgreSQL18约束核对主键、外键及NULL。本轮另实际读取开普敦大学第2章的Theoretical foundations、Attribute、Domain与Tuple段，核对关系集合无重复/无行顺序及属性、域、元组术语；重访清华大学出版社教材节选§3.1.2设计阶段、§3.2.1—3.2.2实体联系与Chen符号、§3.2.3转换规则，支持1:1可合并、1:n并入n端、m:n独立成表。该节选页面未标书名，不推定书名；三级模式及两级映像的补充独立依据见本页开头所列开普敦大学第1章读取记录，具体支持范围与原文疑似笔误按该记录保留，不沿用此前“尚未取得原文”的旧状态。以下旧正确讲解保留供详细阅读。

1. 数据管理三阶段¶

人工管理阶段是人管数据，数据与业务程序没有明确分离，容易重复、丢失、出错且共享困难。文件系统阶段由各应用程序分别管理文件，虽然效率提高，但存在数据冗余、不一致、共享困难以及程序与数据耦合强等问题。数据库系统阶段由 DBMS 统一管理数据，支持共享、并发、事务、故障恢复、权限控制和 SQL 查询。

独立依据：本轮实际读取《Database System Concepts》第7版作者公开第1章Introduction讲义的Purpose of Database Systems部分，其文件处理问题包括冗余与不一致、访问困难、数据孤立、完整性、原子性、并发和安全；支持本段文件系统局限与DBMS职责，不作为“人工管理—文件系统—数据库”三阶段划分或完整DBS人员构成的逐项证据。

数据库系统的重要优势是数据独立性：物理独立性指改变存储方式不影响应用程序；逻辑独立性指改变逻辑结构不影响应用程序。

2. 三级模式与两级映像¶

三级模式从外到内为：

模式	含义	银行例子
外模式	用户视图或子模式，单个用户看到的数据结构	柜员只看到账号、户名、余额
模式	全库逻辑结构，包括表和联系	客户表、账户表、交易表
内模式	实际存储方式，包括文件组织、索引、压缩	按 B+ 树或其他结构存储

一个数据库只有一个模式和一个内模式，但可以有多个外模式。外模式/模式映像保证逻辑数据独立性；模式/内模式映像保证物理数据独立性。客户表增加字段但柜员视图和程序无需修改，属于前者；改变存储结构或增加索引而应用 SQL 不变，属于后者。

“模式只有一个”如何理解¶

三级模式中间的“模式”特指概念模式/全局逻辑模式，是对一个数据库整体逻辑结构的统一描述。“一个”是在数全局描述，不是在数表，也不是说只能有一种表结构。

例如同一个银行数据库包含客户表（客户号、姓名）、账户表（账号、客户号、余额）、交易表（交易号、账号、金额），还有主键、外键及余额等业务约束。这些表的结构、联系和约束共同组成一个数据库模式。每张表有自己的关系模式，多个关系模式共同构成全库的一个概念模式，不能把“一个关系模式”与“一个数据库模式”混为一谈。

柜员看到账号和余额，风控人员看到客户负债与逾期情况，可以有不同的外模式；这些局部视图都建立在同一套全局逻辑定义上，并不意味着数据库有多个概念模式。可类比“全校只有一份统一的整体设计，但不同人员可以查看不同的局部视图”。

需要区分三个边界：

“一个数据库”是讨论范围，不是说一个 DBMS 实例只能管理一个数据库。
“模式”描述结构与约束，“实例”描述某一时刻的具体数据；新增一条客户记录通常改变实例，不改变模式。增加一个字段则改变模式，“只有一个”不表示模式永远不能修改。
SQL 产品中的 schema 常指对象命名空间，例如 sales.orders 与 hr.employees。一个数据库可以有多个这种 schema，不与三级模式中的一个全局概念模式矛盾；两处术语的抽象层次不同。

DBMS性能：计数单位与负载一起给¶

吞吐量是单位时间完成的工作量：TPS按约定事务计，QPS按查询/请求计；一个转账事务可执行多条SQL，两者不能默认相等。响应时间是请求发出至结果返回的耗时，可能含排队、执行、锁等待及通信；平均值之外应看P95/P99等尾部延迟。并发度是同时进行的会话或请求数，连接数包含空闲连接时不能直接当作活动并发。资源指标包括CPU利用率、内存/缓存命中、磁盘IOPS（每秒I/O次数）、带宽（字节/秒）及I/O延迟，它们用于定位瓶颈，不等同业务TPS。

例：10秒内成功完成200个、每个含3次查询的事务，在限定无额外查询且每次成功事务均执行3次查询时，吞吐为20 TPS、60 QPS。若增加客户端数后TPS几乎不变而P99上升，可能已排队或争锁，不能仅凭“并发更大”判性能改善。比较DBMS必须保持数据量、读写比例、SQL/事务定义、硬件、缓存冷热、持久化配置和错误/重试计数口径可比。

依据：本轮实际读取PostgreSQL18 pgbench的Description与样例解释，其输出分别列客户端、完成/失败事务、平均延迟与TPS，并注明TPS是否排除初始建连时间；本段P95/P99和资源指标为测量口径解释，不声称该样例已报告这些指标，也未实际执行压测。对应R-2022-028，优化机制续见索引页。

面向对象数据库：复合对象与操作¶

复合对象由其他值或对象组成，可含嵌套结构、集合及对象引用。例如教学对象订单O1包含收货地址（省、市、街道）和明细集合，每个明细引用商品对象并带数量。沿O1→明细→商品读取名称，是对象导航；调用增加明细(商品,数量)可检查数量与订单状态后修改内部结构。面向对象模型把身份、结构及方法放在同一抽象中，对象标识不必等于所有属性值：两份地址相同的订单仍是不同对象。

复合对象不是关系表里的“复合主键”，也不等于把JSON字符串存入一列就获得对象数据库。包含与引用须区分：订单明细可能依附订单生命周期，但被多张订单引用的商品不能因删一张订单就自动删除。级联、共享引用、事务与持久性均须按具体产品设计，不把组合结构当成无需约束的保证。

依据：本轮实际读取开普敦大学第16章的Capturing semantics（存在依赖、关联、分类）及Combining structure and behaviour、Messages、Methods、Class definitions，支持结构与行为结合及类型相关操作；对象导航和订单结构是教学解释，未核某对象数据库API。该旧课程对关系库能力的历史评价不泛化为现代SQL限制。对应R-2022-054。

3. 码与外码¶

超码能唯一标识一行但不要求最小；候选码是最小超码；主码是选定的候选码；主属性属于至少一个候选码，非主属性不属于任何候选码。候选码的判断是先看能否唯一标识记录，再检查去掉任一字段后是否仍唯一。

外码是本表引用另一张表主码或候选码的字段或字段组合。本表是参照关系，被引用表是被参照关系。外码通常可以为空（若允许 NULL），否则必须引用已存在的值；外码不要求唯一，一张表可以有多个外码。多对多联系表的组合主码成员也可以同时是外码。

4. E-R 模型转换¶

E-R（Entity-Relationship，实体-联系）模型是概念数据模型：先用业务人员和设计人员都容易理解的方式，描述系统关心的对象、对象特征以及对象之间的业务联系，再转换为关系表。它关注“业务中有什么、彼此如何关联”，不是 SQL 表结构图，也不是数据流图。资料1 资料2

Chen 记法：图形元素与含义¶

考试常用的是 Chen 记法。要先认符号，再读名称和连线：

图形	表示什么	怎么读
矩形	实体型（Entity Type）	现实世界中可区分的一类对象，如客户、账户、课程。矩形写实体名。
椭圆	属性（Attribute）	描述实体或联系的特征，如客户姓名、账户余额、选课成绩。椭圆写属性名，并连接到所属实体或菱形联系。
菱形	联系（Relationship）	实体型之间的业务关系，通常用动词/动宾短语命名，如“拥有”“选修”“开设”。菱形连接参与联系的实体。
直线	连接或参与	把实体与其属性连接，或把实体与联系连接；线本身不是实体或关系。
属性名下划线	键属性/实体码	表示能够唯一标识该实体型中一个实体的属性；若需多个属性共同标识，应标明复合码。

关键理解：菱形表示“实体型之间的联系”，不是把两个实体合并成一个实体；关系名通常是业务动作。联系本身也可以有属性，例如“学生—选修—课程”中的“成绩”属于一次选课联系，不能只归给学生或课程。资料1

属性的常见扩展符号¶

复合属性：一个属性可拆成多个组成部分，如地址拆为省、市、街道；Chen 记法常画一个父椭圆，再连接子椭圆。
多值属性：一个实体可能有多个该属性值，如客户联系电话；传统 Chen 记法用双椭圆。关系模型通常将多值属性拆到独立关系表，而不是重复列 phone1、phone2。
派生属性：可由其他数据计算得到，如账户年龄可由开户日期计算；常用虚线椭圆表示。是否存储派生值属于后续实现设计。
键属性：用于区别实体的属性，通常在属性名下划线，如客户号；键也可以是属性组合。
可空/可选属性：若某属性对部分实体没有值，需在概念说明或数据字典中表达可选性；不同教材和建模工具的 E-R 图形符号不完全统一，不要擅自把某个工具图标当作通用 Chen 符号。

弱实体与识别联系¶

若某类对象不能仅凭自身属性独立唯一标识，且其存在依赖另一个实体，称为弱实体。传统 Chen 记法常用双矩形表示弱实体、双菱形表示其识别联系；弱实体的部分键（若有）与所属强实体的键组合起来标识弱实体。资料3

例如订单明细通常依赖订单存在：一张订单可有多条明细，明细可用“订单号 + 行号”标识。把 line_no 单独当全库唯一键通常不符合业务语义；订单删除时明细如何处理还应在关系模型中明确外键动作。

基数与参与约束¶

联系基数（cardinality）说明一个实体实例最多能与另一侧多少个实例相关联。双实体联系常见：

基数	含义	银行业务例子
1:1	两边每个实例至多关联另一边一个实例	假定每张卡至多绑定一个账户、每账户至多绑定一张卡；是否必须绑定另看参与约束，并非所有银行业务都如此
1:n	一侧一个实例可关联多条另一侧实例，反向至多一个	一个客户可拥有多个账户，每个账户归属一个客户
m:n	两侧一个实例都可关联对侧多个实例	一个账户可持有多个理财产品，一个产品也可被多个账户持有

读图时必须说明方向：“一个客户对多个账户”与“一个账户对一个客户”共同构成 1:n；不能只看到 1:n 而不说哪一端是 1、哪一端是 n。不同画图约定可能把基数标在不同位置，必须看每条边旁的标注及图例。三元或更高元联系描述多个实体共同参与的一次业务事件，不能总是拆成若干二元联系而不损失语义。资料1 资料2

基数不等于参与约束：1:n 描述最大关联数量；是否“至少参加一次”是最小基数/参与约束。若每个账户必须属于一个客户，则账户端最小参与数为 1；若客户可以暂时没有账户，则客户端最小参与数为 0。按“每个本端实体能参加几次联系”的 (min,max) 记法，客户端可写 (0,n)，账户端可写 (1,1)，不要与传统 1:n 比率标注的位置混读。传统 Chen 记法中全参与用双线、部分参与用单线，依据大学课程资料核对。资料3

一个完整的 Chen 图示例¶

Chen E-R图：学生选修课程，成绩属于选修联系

图为教学构造，不是从来源复制的原图。读图过程：先找矩形“学生”“课程”，再找菱形“选修”，最后看属性及 m:n。一个学生可选多门课，一门课可被多个学生选择；“成绩”连接菱形，因为它由某学生选某门课的配对决定，不能只放在学生或课程实体上。学号、课程号下划线表示实体码。单线表示本例不要求全参与，不代表数据库有数据流从左向右流动。

对应关系模式：Student(student_id PK, name)、Course(course_id PK, course_name)、Enrollment(student_id PK/FK, course_id PK/FK, grade)。这里假定每个学生对同一课程最多有一条选课记录；如要支持跨学期重修，应扩充学期/开课班等标识或设计选课编号，不能机械地只用两列组合键。

另一个例子是客户与账户的 1:n 联系：一个客户可拥有多个账户，每个账户最多关联一个客户。若业务规定账户必须归属客户，还要表达账户的全参与；单有 1:n 不能推出“账户一定有客户”。

从 E-R 图转换成关系模式¶

实体型 → 关系表：实体属性成为表列，实体码成为主键。例：Customer(customer_id PK, name)。
1:n 联系 → 外键放在 n 端：例：Account(account_id PK, customer_id FK, balance)。如联系本身有属性且每个 n 端实例只对应一个 1 端实例，联系属性通常也能放到 n 端表。
m:n 联系 → 新建联系表：把两端实体的主键作为外键放入联系表；常用两端主键组合作为复合主键，联系自己的属性也放入该表。例：Holding(account_id PK/FK, product_id PK/FK, share)。
1:1 联系 → 选一端放另一端外键：优先考虑全参与一端，以减少空值；被放入外键的一端应加 UNIQUE 以保证至多匹配一个对象，并按业务要求决定是否 NOT NULL。若联系属性或生命周期需要独立管理，也可单独建表。
弱实体 → 表中包含所属强实体键：弱实体表的主键通常由强实体主键和弱实体部分键组成；强实体键同时是外键。
多值属性 → 独立表：例如 CustomerPhone(customer_id FK, phone)，常用 (customer_id, phone) 作为复合主键。

易错点¶

Chen 记法中菱形是联系，矩形是实体型，椭圆是属性；菱形不是属性，也不是“关系数据库表”。
图中写的是实体型/概念，不是具体记录；“客户”是实体型，“客户号 C1001 的某个客户”才是实体实例。
联系可以有自己的属性，如选课成绩、开户日期、持有份额；建模时不要把联系属性随意塞进一侧实体。
1:n 只告诉基数方向，不自动说明必选/可选。最大数为 1 不等于最小数也为 1。
m:n 联系转换为关系模型时必须有联系表；否则无法正确记录多个配对及每次联系自己的属性。
1:1 转换时，外键还需 UNIQUE，否则数据库实际允许多行引用同一对象，变成 1:n；是否 NOT NULL 取决于是否全参与。
区分 Chen 概念 E-R 图和 Crow's Foot/乌鸦脚图：后者常把实体画成带属性的框，并在连线端用圆圈、短线、三叉脚表达可选性和多端，也能用于逻辑建模，不只是物理表结构图；不同记法不可混读。资料2 资料4

本节资料与记法说明¶

本节以考试常见的 Chen 记法及数据库设计基础教材为主。概念符号、扩展属性和参与约束在教材或工具中可能有变体，遇到题目应优先服从题图图例；转换规则按传统关系模型教学口径整理。

资料1：清华大学出版社教材节选，第3章“数据存储设计与Access数据库管理”：已读页面未标明书名，不推定具体书名；用于核对 E-R 概念、基本符号及关系转换。
资料2：IBM — What is an Entity Relationship Diagram?：用于核对 ERD 用途、属性及记法差异。该页 Chen 小节将全参与/部分参与的单、双线写反，与大学课程资料冲突；本笔记不采用该处表述，以资料3为准。
资料3：Emory University — ER diagram notation：弱实体与全参与等概念符号补充。
资料4：MySQL Workbench — Adding Foreign Key Relationships Using an EER Diagram：EER 工具中的 identifying relationship、外键及关联表实现说明。该资料是工具/表模型记法，不作为 Chen 符号定义依据。

5. 范式¶

1NF 要求字段不可再分；2NF 在 1NF 基础上消除非主属性对复合候选码的部分依赖；3NF 在 2NF 基础上消除非主属性对候选码的传递依赖。口诀：1NF 装一个值，2NF 别只靠半个码，3NF 别绕道。在满足 1NF 的前提下，若所有候选码均为单属性，则不存在对候选码的部分函数依赖，可满足 2NF；不能只检查选定的主码，因为关系中可能还有复合候选码。

储蓄业务表 deposit(客户号, 账号, 客户姓名, 余额, 开户网点) 若主码为 (客户号, 账号)，客户姓名只依赖客户号、余额和开户网点只依赖账号，存在部分依赖，可拆成客户表、账户表和业务表。账户表若含网点编号、网点名称、网点电话，网点名称和电话经网点编号传递依赖账号，应拆成 account(账号, 余额, 网点编号) 与 branch(网点编号, 网点名称, 网点电话)。

范式越高通常冗余越低，但连接可能增多；反规范化是在读性能确实重要时有控制地保存冗余数据，具体取舍待核验。

6. 完整性约束与视图¶

完整性约束是数据库对允许存入的数据状态设定的规则。已启用的约束在相应检查时点发现违规后，DBMS 会拒绝操作或提交，避免错误数据进入或破坏表间关系。关系数据库基础通常归纳为实体完整性、参照完整性和用户定义完整性；PRIMARY KEY、FOREIGN KEY、UNIQUE、NOT NULL、CHECK 是 SQL 约束机制，DEFAULT 是相关的默认值机制，不是与三类经典完整性并列的新类别。以下规则以教材概念为主，产品行为由官方文档交叉核对。资料1 资料2 资料3

三类经典完整性¶

类型	要保证什么	典型规则	常见 SQL 实现
实体完整性	每行能被可靠地区分，主标识不可缺失	主键值唯一且非空；复合主键中的每个组成列都非空	`PRIMARY KEY`
参照完整性	表之间的引用不悬空	子表外键为空（若允许），或匹配被引用表中的键	`FOREIGN KEY ... REFERENCES`
用户定义完整性	业务数据满足具体领域规则	余额不少于透支下限、金额大于 0、状态在允许集合中	`CHECK`、`NOT NULL`、数据类型、触发器或应用逻辑等

实体完整性：主键约束具体做什么¶

关系表中的主键（primary key）用于唯一标识一行。单列主键要求该列的值不重复且非 NULL；复合主键要求整组列值组合唯一，并且组成主键的每一列都非 NULL。主键不一定必须是单列，也不一定要有业务含义，可以使用自然键或代理键。

CREATE TABLE account (
    account_id BIGINT PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    balance DECIMAL(12, 2) NOT NULL CHECK (balance >= 0)
);

CREATE TABLE holding (
    account_id BIGINT NOT NULL REFERENCES account(account_id),
    product_id BIGINT NOT NULL,
    share DECIMAL(8, 4) NOT NULL CHECK (share > 0),
    PRIMARY KEY (account_id, product_id)
);

account_id 确保每个账户行有且只有一个可用主标识；holding 的复合主键允许一个账户持有多个产品，也允许一个产品被多个账户持有，但不允许同一账户与同一产品组合重复。若持仓记录需要保留多笔交易而不是每对账户/产品一行，就应把交易编号加入键或另设独立主键，键的设计取决于“哪一条事实应当唯一”。

主键是一组列的约束，不等同于“某个字段看起来不重复”。若候选键有多个，只选其中一个作为主键，其余候选标识可用 UNIQUE 加 NOT NULL 等约束表达。每表通常定义一个主键约束；其他唯一业务标识用唯一约束。

重点：复合主键判断示例。键为 (account_id, product_id) 时，(1001, 10) 与 (1001, 20) 可以同时存在，单列账户号重复不是违规；再次插入 (1001, 10) 或插入 (1001, NULL) 则不符合该主键约束。不能误写为给两个列分别声明 PRIMARY KEY，也不能把组合唯一误读为“每列各自唯一”。PostgreSQL、SQL Server 和 Oracle 官方文档均明确支持复合主键并要求主键各列非空。资料1 资料2 资料3

易错：数据库允许不声明主键，不代表实体标识不重要。部分 SQL 产品允许创建没有显式主键的表；教材中的实体完整性规则与产品是否强制要求建表时声明主键要分开。自增或序列只是生成值的机制，不应当代替显式唯一/主键约束；主键约束也不等于聚簇索引。

主键、唯一约束与空值¶

PRIMARY KEY 同时表达唯一和非空；单个表通常只能定义一个主键约束，但它可包含多列。
UNIQUE 表达唯一性，不自动等同于主键；是否允许一个或多个 NULL、如何比较多个 NULL，SQL 产品和配置可能不同，跨数据库题目不要假设行为完全一致。
NOT NULL 只禁止空值，不保证不同记录之间唯一。
DEFAULT 只在插入时省略该列或显式请求默认值时提供默认值，不等于 NOT NULL，也不保证业务规则成立。
CHECK (amount > 0) 约束金额范围，但若 amount 可以为 NULL，SQL 的三值逻辑可能使检查结果为 UNKNOWN；许多 DBMS 会将其视为没有违反 CHECK。因此要“必填且大于 0”应写成 NOT NULL 与 CHECK 两项约束。

以上 NULL 与约束规则主要依据 PostgreSQL 18 文档；其中主键和 CHECK 的基本行为也可对照 Oracle 文档，唯一约束的 NULL 差异不作跨产品统一假设。资料1 资料3

易错题：UNIQUE 允许几个 NULL¶

用户提供的截图题问“UNIQUE 唯一约束允许字段存在什么”，选项为多个 NULL、至多 1 个 NULL、禁止 NULL、重复值；题库给出 B“至多 1 个 NULL”。该答案符合 SQL Server 普通单列 UNIQUE 约束的行为，但题干没有注明产品，不能把它当作所有 SQL 数据库的通用结论。SQL Server 官方说明

场景	单列 UNIQUE 对 NULL 的常见行为
SQL Server 普通单列 UNIQUE，列允许 NULL	至多一行是 NULL，符合本题 B
PostgreSQL 默认 UNIQUE，列允许 NULL	可以有多个 NULL，默认不把不同 NULL 当作重复键
PostgreSQL UNIQUE NULLS NOT DISTINCT	将 NULL 按不区分处理，单列时至多一个 NULL
UNIQUE 同时声明 NOT NULL	不允许 NULL

题目作答与知识理解分开：本题按题库口径选 B；遇到明确注明 PostgreSQL、其他产品或特殊索引条件的题，按对应实现判断。普通单列 UNIQUE 不允许重复的非空值，所以截图中 D“重复值”并不成立，不能因 NULL 行为存在差异就认为 D 正确。复合 UNIQUE(a,b) 约束的是整组键值，单独一列可以重复，不能套用“每一列至多一个 NULL”的简单口诀。PostgreSQL 差异见资料1。

参照完整性：外键与删除/更新动作¶

外键保证子表引用的父行确实存在。外键值可以为 NULL（前提是列允许空值），或者匹配被引用表中受唯一性约束的键。复合外键按列组匹配；部分列为空时的具体处理可受 MATCH 规则和数据库实现影响，若要求整组要么全填、要么全空，宜另加显式检查。

父表键被更新或父行被删除时，外键可配置 RESTRICT/NO ACTION、CASCADE、SET NULL、SET DEFAULT 等动作（支持与时机因 DBMS 而异）：

RESTRICT / NO ACTION：若仍有子行引用，则阻止操作；两者在检查时机等细节上可能不同。
CASCADE：父键更新或父行删除时，将动作传播到匹配子行；谨慎使用，防止意外级联删除。
SET NULL：把子表外键置空，要求该列允许 NULL。
SET DEFAULT：设为默认值，默认值仍须满足外键等约束。

用户定义完整性：规则放在哪里¶

优先用数据库声明式约束表达可由当前行或键关系清楚表示的规则，例如 NOT NULL、CHECK、UNIQUE、外键。数据类型限制值的基本形式；CHECK 常表达同一行内的范围和列间关系；需要跨行统计、依赖其他表复杂状态或涉及副作用的规则，通常需要唯一/排斥约束、触发器、事务逻辑或应用层配合。不要把所有业务规则都塞进一个简单 CHECK：不同 DBMS 对 CHECK 能引用的内容有边界，且跨行条件可能在并发下失效。

完整性约束与安全防护手段¶

二者目标不同但可以协作：

手段	核心问题	例子	不负责什么
完整性约束	数据是否合法、关系是否一致？	主键唯一、外键有效、余额范围受限	不判断当前用户是否有权读取该行
视图	用户看到哪些列/行，能否用简化接口操作？	只向柜员展示账号、户名、余额，隐藏证件号	视图定义本身不自动撤销用户对基表的权限，也不等同于加密
授权/角色（GRANT/REVOKE）	谁能对哪个对象做什么操作？	柜员仅有视图 `SELECT` 权限，无基表敏感列权限	不保证用户提交的数据满足业务规则
行级安全策略	用户能访问哪些行？	客户只能读写属于自己的账户行	不代替主键、外键等数据约束
审计日志	谁在何时做了什么？	记录查询、授权变更或敏感数据访问	主要用于追溯，不是阻止所有越权行为的唯一措施
加密/脱敏	数据泄露后如何降低可读性或限制暴露？	静态加密、传输加密、显示时脱敏	不代替访问控制，也不自动保证数据业务正确

视图如何帮助安全：可以只投影允许公开的列，或用条件筛选允许访问的行；再把 SELECT 权限授予视图、撤销对底层表的直接权限，以减少重复授权并形成受控访问接口。仅仅“创建了视图”并不等于隔离成功：如果用户仍有基表权限，仍可绕过视图查询敏感列。视图的行过滤、可更新性、执行者权限与安全选项也有产品差异，敏感系统需验证权限链及相关安全配置。

对比例子：CHECK (balance >= 0) 防止任何写入路径把余额写成负数（规则允许的例外除外），这是完整性；给柜员一个不包含证件号码的视图，并只授予该视图读取权限，是最小权限和数据暴露面控制；两者同时使用，才能兼顾“数据正确”和“访问受控”。

视图与角色联合授权示例¶

下面是 PostgreSQL 默认所有者权限视图的示例，假定表、角色已创建，且由有权的管理角色执行；customer_private 包含证件号等敏感列：

CREATE VIEW customer_public AS
SELECT customer_id, customer_name
FROM customer_private;

REVOKE ALL PRIVILEGES ON customer_private FROM PUBLIC;
REVOKE ALL PRIVILEGES ON customer_private FROM teller_role;
GRANT SELECT ON customer_public TO teller_role;

重点：视图把“允许看到的数据范围”封装成一个接口，角色把同类用户的授权集中管理；新增柜员时分配角色，而不是逐人、逐表重复配置。示例不能独立证明系统已隔离：还须检查用户从其他角色继承的权限、列级授权、对象所有权、超级用户身份及其他访问路径；REVOKE 不会自动消除所有间接权限。PostgreSQL 的 security_invoker 视图会改变基表权限检查主体，不能不加区分地套用这个示例。行过滤视图还应考虑 security_barrier 等产品安全机制。资料4 资料5

易错：WITH CHECK OPTION 不等于表的 CHECK 约束。可更新视图若有 WHERE branch_id = 1，加 WITH CHECK OPTION 可要求经该视图插入/更新后的行仍满足视图条件；它不自动限制绕过视图直接写基表的操作，也不授予或撤销权限。表上的 CHECK 则约束表数据，适用于受其检查的写入路径。资料4

边界：安全领域的“完整性”（CIA 中的 I）强调防止或发现未经授权的修改，范围比关系数据库的实体/参照完整性更广。完整性约束和安全并非互斥：授权可防止非法修改，约束可阻止被授权用户写入违规值。但“有权把姓名改成另一个合法字符串”仍可能造成事实错误；约束只能保证已声明规则，不能证明所有数据都真实。

进阶易错：以 PostgreSQL 为例，RLS 行级策略不能简单当作“超级用户也无法绕过”的隔离；超级用户、具有 BYPASSRLS 属性的角色和通常情况下的表所有者有绕过行为。主键、唯一约束和外键检查也有独立于行可见性的检查路径，报错信息可能泄露某键是否存在。因此完整性检查与访问控制需要同时设计，而非互相替代。资料6 PostgreSQL 行过滤视图的安全屏障也不能阻止所有通过执行时间等推断信息的旁路，应按威胁模型设计。资料7

易错点：

实体完整性考主键唯一且非空；UNIQUE 通常不自动禁止 NULL，不能简单等同主键。
复合主键要求组合唯一，单列值可以重复，但每个主键列均不能为 NULL。
外键值不要求唯一；多个子行可以引用同一父行。外键列允许 NULL 时，空值通常不表示“引用了某个父行”。
CHECK 不总能代替 NOT NULL；必填且满足条件时两者要分别声明。
完整性约束解决“数据是否合规”，权限和视图解决“谁能看/改哪些数据”；二者不是同一种保护。
视图只是安全设计的一部分；若基表权限未撤销，用户可能绕开视图。视图也不能替代审计、加密和身份认证。
参照完整性主要由外键保证；只在应用代码里检查而不在数据库设约束，仍可能被并发写入、其他程序或人工 SQL 绕过。

视图是由查询定义的虚表，通常存储定义而非实际数据。它可以简化复杂查询、限制暴露列和行、提供逻辑独立性；含聚合、GROUP BY、DISTINCT 或多表连接的视图通常不能直接更新。不同数据库产品对可更新视图的细节待核验。

本节官方资料与适用范围¶

本节为网络资料核对后的学习补充，不冒充原教材原文；SQL 示例为教学构造。主键基本规则由三家官方文档交叉验证，NULL、可更新视图、授权链及约束检查时机等差异以相应产品文档为准。

资料1：PostgreSQL 18 — Constraints：主键/复合主键、CHECK 与 NULL、唯一约束、外键与检查边界。
资料2：Microsoft SQL Server — Create primary keys：单表一个主键约束、复合主键各列非空、组合唯一、非聚簇主键。
资料3：Oracle Database 26 — Data Integrity：声明式约束、主键、外键、CHECK、约束状态。
资料4：PostgreSQL 18 — CREATE VIEW：权限检查、可更新视图、CHECK OPTION、security_barrier 与 security_invoker。
资料5：Microsoft Learn — 介绍数据库和对象权限：表/视图权限、最小权限和所有权链；SQL Server 专用语法不泛化为所有产品。
资料6：PostgreSQL 18 — Row Security Policies：行级策略、特权绕过、约束检查与潜在信息泄露。
资料7：PostgreSQL 18 — Rules and Privileges：视图权限、security_barrier 的用途与局限。

考前易错速记¶

事务具有原子性、一致性、隔离性和持久性（ACID）。隔离级别需要结合脏读、不可重复读和幻读判断；事务日志通常遵循 WAL（先写日志后写数据），redo 保障持久性，undo 支持原子性。查询本身不写入事务日志，查询行为应由审计日志或慢查询日志记录，用于合规追溯和性能调优。

SQL 中 WHERE 筛选行，HAVING 筛选分组后的结果，聚合条件放在 HAVING。等值连接按指定列相等连接，列名不必相同且连接列可能出现两次；自然连接按同名列连接并去重。范式可速记为：1NF 每个字段装一个值，2NF 消除对复合码的部分依赖，3NF 消除传递依赖。

来源：专业课速记/09_考前必背清单.md

V-1至V-2查漏：数据模型、数据库设计与关系基础。 数据模型用数据结构、操作和完整性约束描述现实世界，层次模型以树组织、网状模型允许多种联系、关系模型以二维关系表示；考试中常把“关系”误当成表格外观，实质还包括元组、属性、域和约束。设计通常经历需求分析→概念设计（E-R）→逻辑设计（关系模式、规范化）→物理设计（文件、索引、分区）→实施与运维。场景：银行先抽取客户、账户、交易实体，再确定联系和主外键。易错边界：概念模型不等于物理表；关系的元组无序、属性名不能重复；规范化降低冗余但不保证业务事实真实。

V-4 安全性与完整性。 安全性回答“谁能访问什么、做什么”，机制是身份认证→授权/角色→最小权限→视图或行列过滤→审计与告警→定期回收权限；完整性回答“数据是否满足规则”，机制是主键/唯一、外键、NOT NULL、CHECK、事务和触发器。场景：柜员只能读取脱敏视图，账户余额必须满足非负约束，交易引用已存在账户。易错边界：加密不等于授权，视图不等于自动隔离，CHECK 不一定替代 NOT NULL；外键保证引用存在，不保证金额业务上合理。

V-5 数据库设计流程。 需求分析形成数据项、业务规则和事务清单；概念设计画实体、属性、联系及基数；逻辑设计转换关系模式并确定候选码、主外键、范式；物理设计选择索引、分区、存储和备份策略；实施阶段建库、装载、测试、迁移；运行阶段监控、调优和变更评审。场景：交易系统先保证账户—交易的参照关系，再按查询频率设计时间索引。易错边界：先建索引再理解业务会造成过度索引；1:n 外键通常在 n 端，m:n 必须建联系表；逻辑独立性不意味着可以随意改业务语义。

V-6 分布式数据库。 分布式数据库把逻辑统一的数据分布在多个网络节点，通过分片、复制、路由和协调完成访问。典型步骤是按业务键水平/垂直分片→建立副本→确定一致性协议和故障转移→路由查询→监控重平衡。场景：按客户地域分片交易库，跨地域报表通过汇总或分布式查询完成。易错边界：分布式不等于高可用，复制不等于强一致；CAP 讨论网络分区发生时一致性与可用性的取舍，不能简单说“三者只能选两个”而忽略分区条件；跨分片事务成本高，分片键选择会影响热点。

V-7 NoSQL、非结构化与时序数据。 NoSQL 是非关系数据库的统称，键值、文档、列族、图数据库分别适合简单键查、半结构文档、宽表分析和关系遍历；非结构化数据指文本、图片、音视频等不能直接按固定表格表达的数据；时序数据按时间产生，常带设备标识、时间戳和测量值。机制：先按访问模式选择模型→设计主键与分区→设置保留/压缩/聚合策略→以最终一致或事务能力满足场景。场景：日志用文档库，设备监控用时序库，社交关系用图库。易错边界：NoSQL 不是“没有任何结构”，CAP 不是 NoSQL 专属；时序数据也可存关系库，关键是写入频率、时间范围查询和保留策略；非结构化不代表不需要元数据和质量治理。

V-8 多模态数据。 多模态数据同时包含文本、图像、语音、视频、表格或传感器信号。结构上，文本常按文档、段落和分块组织；图像包含像素、格式、尺寸及空间元数据；音视频包含采样、帧、编码和时间轴；各模态还需要统一实体标识、时间戳和来源元数据。管理上可用对象存储保存原始文件，用元数据目录、权限策略、版本和生命周期管理索引对象；全文索引和向量索引可作为检索入口，但向量不能替代原始文件或授权记录。处理核心机制是采集与脱敏→统一标识和时间/空间对齐→分别编码或提取特征→跨模态融合→联合检索/推理→质量和权限校验。场景：客服把语音、工单文本和设备图片关联分析，金融审核联合身份证图像与申请文本。易错边界：把多种文件放在一起不等于完成多模态融合；时间戳、实体对齐和标签一致性决定结果；模型输出仍需人工复核、隐私保护和可追溯。

流程对比速记。 集中式数据库重点是单节点事务与约束，分布式数据库增加分片、复制、协调和网络故障处理；关系库强调模式与连接，NoSQL 更强调访问模式和横向扩展；结构化数据易于模式校验，非结构化数据仍需元数据、索引和生命周期管理。

V-1-01 DB、DBMS 与 DBS 的定义和组成。 定义：数据库（DB）是长期存储、按一定模型组织、可共享的相关数据集合，包含业务数据及描述结构、约束等的元数据；数据库管理系统（DBMS）是管理数据库的软件；数据库系统（DBS）是包含数据库、DBMS、应用系统、硬件及操作系统等支撑环境和相关人员（如 DBA、开发者、用户）的整体。机制：应用向 DBMS 提交定义、查询或更新请求，DBMS 通过查询处理、存储管理、事务并发控制、恢复、完整性检查和权限管理访问 DB，并维护系统目录。场景：银行的账户与交易数据属于 DB，管理它们的软件属于 DBMS，连同柜面应用、服务器和管理人员构成 DBS。边界：DB 是数据集合而不是管理软件，DBMS 不等于整个 DBS；数据库系统的人员和环境不能只用几张表代替。

V-1-02 概念、逻辑与物理模型的映射。 定义：概念模型抽象业务实体、属性、联系和业务约束；逻辑模型按选定数据模型组织结构与约束；物理模型描述具体存储和访问路径。机制：将概念 E-R 中的客户、账户及 1:n 联系映射为逻辑关系 Customer(customer_id, name)、Account(account_id, customer_id, balance)，用主外键表达标识与联系，再按查询负载映射为物理文件组织、索引和分区等设计。场景：先确认“每账户属于一个客户”，再设账户表客户外键，最后为常用客户查账户访问设计索引。边界：设计阶段的“概念模型→逻辑模型→物理模型”不是三级模式的“两级映像”；三级模式中的概念模式描述全局逻辑结构，不能直接等同于概念设计阶段的 E-R 图；同一逻辑结构可有不同物理实现，索引不能替代业务约束。

V-1-04 事务的业务前提与受影响行数检查。 定义：事务是按业务要求作为一个整体提交或回滚的操作序列，ACID 不会自动补齐错误或遗漏的业务规则。机制：以不允许透支的同币种内部转账为例，先明确金额大于 0、付款与收款账号不同、双方存在且状态允许、调用者有权操作、付款余额充足；在同一事务中以唯一账号及状态、余额条件执行扣款，立即检查扣款受影响行数为 1，再按唯一账号与可收款状态入账并检查受影响行数为 1，记录交易，全部符合才提交，任一失败则回滚。场景：转账 100 元时，条件扣款将余额检查与更新结合，并配合适当锁或隔离机制协调账户状态等并发变化，避免先查余额再无条件扣款。边界：SQL 未报错不等于业务成功，更新 0 行可能是账户不存在、状态不符或余额不足，非预期多行也必须失败；行数统计口径须核对驱动与 DBMS，不能把“匹配行”与“实际修改行”混为一谈；事务内的有效行数检查不代替权限、币种、限额和并发规则，提交结果不明时重试还需唯一业务流水及幂等处理，不能再次盲目扣款。

V-2-01 关系是域上元组的集合。 定义：设域为 D1, D2, …, Dn，一个 n 元关系 R 是笛卡尔积 D1 × D2 × … × Dn 的子集，即由符合语义及约束的 n 元组构成的集合。机制：先由各域限定每一分量可取值，再用关系模式中的属性及完整性约束限定哪些元组能够进入关系；关系实例是某时刻的元组集合。场景：账户关系从“账号域 × 客户号域 × 余额域”的所有可能组合中，选取实际有效的账户元组，而不是存储全部组合。边界：数学关系没有重复元组，元组无先后顺序；属性按名称识别，调整展示列序并不改变其业务含义；SQL 查询默认可保留重复结果，结果顺序需 ORDER BY 指定，不能把 SQL 表或查询结果的全部行为直接等同于纯关系集合。

V-2-02 元组、属性、域与值域例。 定义：元组是关系中的一条记录，属性是描述对象某一特征的命名列，域是某属性允许取值的集合；“值域”在此按允许值范围理解，不是该列当前已出现值的集合。机制：由类型、范围、枚举和非空等约束落实域要求，例如教学关系 Account(账号, 状态, 余额) 中，账号域为恰好 6 位十进制数字组成的字符串集合，状态域为 {正常, 冻结, 销户}，余额域为本例允许的非负、两位小数金额；('000123', '正常', 500.00) 是一个元组，状态 是属性，正常 是其一个属性值。场景：录入账户时拒绝状态“未知”或负余额，并用字符串保存账号的前导零。边界：基础字符串类型并不能自动限制长度、字符内容或状态枚举，需相应约束；域不要求不同属性互不重叠，非负余额只是本例不透支规则；SQL 的 NULL 是缺失/未知信息标记，不应当成普通金额值或字符串“NULL”。

V-6 分布式查询的分解与汇总。 定义：分布式查询是在逻辑统一的数据上发出查询，由多个节点共同执行并形成结果。机制：协调方根据分片目录定位数据，将全局查询分解为节点子查询，尽量下推过滤、投影和可分解聚合以减少传输，再收集中间结果执行合并、跨节点连接、最终聚合或排序。场景：统计各地域账户的全行平均余额时，各分片返回本地余额总和与有效余额计数，协调方用总和之和除以计数之和，而不是直接平均各地平均值。边界：跨节点连接可能需要搬运数据，COUNT(DISTINCT ...) 等不能直接相加；副本须避免重复计数，时间点一致的报表需要相应快照/一致性支持；节点失败时不能把缺失分片悄悄当成零并宣称结果完整。

V-6 跨节点事务协调。付款账户和收款账户分属不同分片时，需要约定扣款与入账怎样共同完成。跨节点原子提交可采用两阶段提交，但是否支持及故障处理方式取决于实现；准备、提交决定和阻塞边界统一见数据一致性与基础设施§2：2PC、TCC与Saga。

V-7 键值数据库的结构与读写。 定义：键值模型以唯一键关联一个值，核心结构是“键→值”映射，值可为字节串或其他由实现支持的内容。机制：按键定位记录，读取取得对应值，写入新增或替换键对应值，删除移除映射；应用需根据实现提供的原子操作或并发控制避免读改写覆盖。场景：以会话标识为键保存会话内容，或按用户编号读取缓存结果。边界：不能只因值里存了 JSON 就假定支持按内部字段过滤、连接或索引；键查能力也不自动提供多键事务、持久性或缓存一致性保证。

V-7 文档数据库的结构与读写。 定义：文档模型以文档为记录单位，文档包含命名字段、嵌套对象和数组等结构，通常按集合组织。机制：通过文档标识读取或写入文档，也可按字段条件查询，并利用已建立且受支持的字段索引缩小扫描范围；更新可针对整篇文档或实现支持的字段路径。场景：商品目录为不同品类保存公共字段与差异化规格，按品类和价格查询。边界：模式灵活不等于没有结构与校验，字段类型、必填项和版本仍需治理；字段更新、索引与跨文档事务能力取决于实现，不能假定嵌套结构天然消除所有关联查询。

V-7 列族数据库的结构与读写。 定义：列族（宽列）模型以行键标识记录，把相关列组织为列族，适于稀疏且列集合可变化的数据组织。机制：按预期访问模式设计行键与分区，写入某行的列值，读取按行键定位并选取所需列；模型及实现支持时可在行键范围内扫描，通常需提前组织能直接命中查询的数据。场景：将设备编号与时间组织成行键，按设备读取一段遥测记录及所需指标列。边界：列族模型不等于分析型关系库的列式物理存储；键序和范围扫描能力须以实现为准，不能默认任意列过滤高效或天然支持跨行连接与事务；不当行键可能造成热点。

V-7 图数据库的结构与遍历。 定义：图模型用节点表达实体、用边表达联系，节点和边可携带属性，边的方向及类型表达关系语义。机制：写入节点、边及其属性；查询先按标识或索引定位起点，再沿指定方向和边类型扩展邻接节点，结合属性条件、路径长度与去重规则进行遍历或路径匹配。场景：从某账户出发沿转账关系追踪有限跳数的关联账户，分析资金联系。边界：多跳遍历仍可能因高连接度而爆炸，需要限制深度、时间范围和结果规模；路径存在不等于因果或违法证据，图结构也不自动保证查询更快或事务更强。

V-7 非结构化数据库的管理职责。 定义：面向非结构化数据的数据库或管理系统，负责组织、检索和治理不能直接用固定二维表完整表达的文本、图片、音视频等内容及其元数据。机制：为原始内容建立稳定标识和存储定位，管理格式、来源、版本及关联元数据，通过内容解析生成全文索引或特征索引，并落实权限、审计、备份恢复、质量校验和生命周期策略；原始文件可在对象/文件存储中，数据库维护受控引用与索引。场景：档案系统保存扫描件，登记归属、版本和访问权限，利用 OCR 文本索引查找并回溯原件。边界：OCR、特征与索引是派生结果，不能替代原件；文件存储本身不等于完整数据库管理，需协调内容与元数据的更新、删除和权限，解析误差也不能当成已核实事实。

V-7 时序数据库的定义与核心机制。 定义：时序数据库是针对带时间戳的连续观测或事件数据及其访问模式进行优化的数据库，记录通常含时间戳、设备/序列标识及测量字段。机制：写入时可按序列与时间分区、批量追加，并按约定处理迟到、重复和乱序数据；范围查询先限定序列与时间区间，借助时间索引或分区裁剪缩小扫描；聚合按时间窗口计算计数、均值、最大值等，并可生成降采样结果；保留策略按数据时间和规则清理到期明细，按需更久保存汇总。场景：监控设备每秒温度，查询某设备最近一小时记录、计算每分钟均温，按业务规定保留明细与长期趋势。边界：时序数据库不只是“有时间列的表”，普通关系库也能承载时序数据；窗口边界、时区、事件时间与写入时间、迟到处理及保留删除须明确，降采样无法还原全部明细，不能在聚合尚未完整时直接删除原始记录；具体压缩、去重及保留执行能力以实现为准。