假设我们有一个从主键外的属性到主键内的属性的函数依赖关系。我们怎样才能摆脱这种依赖（我直觉上认为这很糟糕）？如何摆脱关键依赖？
特别地，假设我们有以下功能依赖关系：
CS -> T
T -> C
其中CS是主键。在我的例子，它发生是幸运也TS最初可以是主键，这样的情况被转换为：
TS -> C
T -> C
这实际上是一个情况下，我们没有进入关键依赖了，但我们有部分的依赖，这可以很容易地通过拆分表我们可以解决到两个表如下
| T | C |
和
| T | S |
但如果TS不是主键？我们怎样才能摆脱的最初依赖关系/异常？
任何“进入密钥”在将关系分解为Boyce-Codd标准形式（BCNF）时，给定关系R中的依赖关系将被删除。
BCNF确保所有依赖关系为“来自全键”的“”。
看here如何分解成BCNF形式。
编辑
而对于完整起见，其它的2型依赖性 - 被分解以2NF和传递依赖除去部分依赖被进一步分解成3NF除去。因此，通过进一步分解成BCNF你去除基本上所有的三种类型的依赖关系（部分，传递，到密钥）
首先，关于术语的说明：“主键”是用于一个关系 术语由关系数据库管理系统 管理，而在归一化理论 中通常使用的术语是“超级密钥”和“候选密钥”，或者简称为“密钥”。
其次，在你的榜样，你都在问：
如何才能摆脱这种依赖的（我直觉地认为它是坏的）？
的一点是，依赖其实是不好的，因为你有异常的关系（在这种情况下，冗余）的感觉，但你不能摆脱 这种异常，而无需其他异常现象，即正在失去功能依赖。
事实上，你可以转换模式中BCNF，用下面的分解 模式：
R1 <（CT）， {T→C}>
R2 <（ST）， { }>
但是，如您所见，依赖关系CS→T不再保留，因为没有 subschema包含所有这三个属性。这比冗余性更差，因为您可能会在数据库中引入不一致性，即 是违反该依赖性的情况。
在实际上，这是一个典型的例子，其中所述模式是已经在第三范式（3NF） ，即，根据定义，允许从 组不属于关键属性的相关性，以一个属性，其是关键 （称为“主要”属性）的一部分。
因此，这种异常是普遍接受的，并且关系不分解。