外键的精确定义与SQL FOREIGN KEY语法差异

外键的精确定义比[[候选键主键与外键的精确定义]]中给出的直觉版本更严谨：设R1 和R2是关系变量（可以相同），K是R1的一个键，FK是R2标题的一个子集，如果存在 一个针对R1属性的重命名序列，能把K映射为一个与FK具有完全相同属性（相同属性名 和类型）的K’，并且R2和R1在任何时刻都满足”R2中任意元组的FK取值都等于R1中某个 元组的K’取值”这条约束，那么FK就是外键，K是对应的目标键，这条约束叫参照约束， R2是参照关系变量、R1是被参照关系变量。这个定义特意强调了”重命名”这个技术 细节，原因在于外键约束的检验本质上依赖[[元组相等性的精确定义及其重要性]]—— 两个元组要比较相等，前提是它们必须有完全相同的属性名，而外键属性和目标键属性 名字往往不同（比如员工表EMP自我参照的例子里，MNO代表经理编号，参照的却是 ENO字段），所以需要先把目标键重命名成和外键相同的属性名，才能在语法上把这次 比较真正表达成合法的元组相等性检验。SQL在这一点上的做法明显不同：SQL里键和 外键的值本质是行而不是元组（行有排序，值靠位置对应），因此SQL的 FOREIGN KEY(B1,...,Bn) REFERENCES T1(A1,...,An)只要求对应位置的列Bi和Ai 类型相同，完全不要求名字相同（这就是为什么FOREIGN KEY(MNO) REFERENCES EMP(ENO)不需要任何重命名步骤就合法）。书中仍然建议尽可能让SQL外键列和目标 键列同名（呼应[[SQL列命名与位置依赖关系化使用SQL的实践规则]]），只在自参照 表、或同一张表的多个外键指向同一个目标键这两种确实无法完全遵守的场景下适当 妥协，但即便妥协也应尽量让至少一个外键列保持同名。原始的关系模型定义还额外 要求外键必须对应被参照关系变量的主键，但本书的立场不强求主键地位、也相应不 强求外键必须对应主键（SQL在这点上和本书立场一致）。