任何一个二目关系都属于bcn范式的原因是：a->b，其中a必定为候选码，因为候选码的定义就是候选码是能够唯一标识关系中某一个元组的一个属性或属性集，也叫候选键，而a可以标识关系中的任意一个属性和属性集
情况一：如果两个属性都是候选码（a->b,b->a），那么这两个属性的关系就是不包含非主属性的关系，那么就代表只要候选码之间满足a->b（a表示的是候选码而非候选码的一部分，并且没有传递的候选码之间的依赖），由二目关系可知是满足条件的。
情况二：如果b是非主属性(a->b)，那么只要满足b的非主属性完全函数依赖于a并且非传递函数依赖于a就可以，显然是满足的。
数据依赖代表的是属性与属性之间的约束关系，其中属性并不代表单个属性也不代表属性集，而是都包含。
外模式（又称用户模式）：是用户看到的数据视图，由逻辑设计阶段生成（基于概念模型转换为逻辑模型后，针对不同用户需求设计）；
物理设计阶段：核心是确定数据的物理存储方式（如存储结构、索引设计等），生成的是物理模型，与外模式无关。
概念模型是独立于 DBMS 和硬件设备的抽象模型，其核心是描述现实世界的信息结构（比如 E-R 模型），目的是统一业务人员与技术人员对数据的理解，不涉及具体的数据库软件或硬件环境。
而依赖于 DBMS 和硬件的是物理模型（描述数据在存DBMS 是 "数据库管理系统（Database Management System）" 的缩写，是管理数据库的核心软件，核心作用是统一管理数据的存储、访问、维护，同时提供数据安全、并发控制等功能，是用户与数据库之间的 "接口"。
核心功能
数据定义：提供 SQL 语句（如 CREATE TABLE）定义数据库的结构（表、视图等）；
数据操作：支持增删改查（INSERT、DELETE、UPDATE、SELECT）；
数据控制：管理用户权限（如 GRANT、REVOKE），保障数据安全；
事务管理：保证数据操作的原子性、一致性、隔离性、持久性（ACID）；
并发控制：避免多用户同时操作数据导致的冲突。储设备上的具体存储方式）和逻辑模型（如关系模型，需适配特定 DBMS）。
- 物理模型：依赖 DBMS + 硬件设备
物理模型是数据在存储介质上的具体实现方式，需同时适配：
硬件设备：比如存储结构（磁盘分区、块大小）、IO 性能优化，依赖服务器的硬件配置；
DBMS：比如索引类型（B 树索引 / 哈希索引）、存储引擎（InnoDB/MyISAM），需符合特定 DBMS 的语法和功能限制。
- 逻辑模型：仅依赖 DBMS
逻辑模型是数据的逻辑结构描述（如关系模型的表、字段、主键），只需要适配DBMS 的类型：
比如关系型 DBMS（MySQL）对应关系模型（表结构）；
非关系型 DBMS（MongoDB）对应文档模型（JSON 结构）；
但逻辑模型不涉及硬件细节，只与 DBMS 的语法规则相关。
- 补充：概念模型（无依赖）
概念模型（如 E-R 模型）是现实世界的抽象，既不依赖 DBMS，也不依赖硬件，是独立于技术的业务层模型。
简言之：
物理模型：DBMS + 硬件 双依赖；
逻辑模型：仅依赖 DBMS；
概念模型：无依赖。
互相函数依赖：当X→Y且Y→X时，说明 X 和 Y 可以互相唯一决定对方，这种关系称为互相函数依赖（也叫 "等价函数依赖"）。
平凡函数依赖：指Y是X的子集（如{X,Y}→X）。
传递函数依赖：是X→Y、Y→Z且Y不→X时的依赖关系（如学号→班级、班级→班主任）。
完全函数依赖：是X的任何真子集都不能决定Y（如{学号,课程号}→成绩）。
关系模式规范化的核心目标是减少数据冗余，避免更新 / 插入 / 删除异常，从而维护数据的一致性。数据一致性就是 "数据库里的信息始终是统一、不冲突的"，这也是规范化、事务管理等数据库设计的核心目标之一。
关系模式规范化理论主要解决的问题就是如何构造合适的数据逻辑结构。