第六范式，重构查询，高效实现

Question

我发现 Hugh Darwen 为避免我的数据库中的空值而写的这篇论文：链接，它描述了如何以第 6 范式实现数据库，以便您可以避免空值。语言教程 D 中描述了逻辑。我了解如何将所有这些逻辑转换为 SQL Server。但是在最后他展示了在当前的数据库管理系统中可以很好地实现这一点，然后我看到了我需要实现的部分：

• 重组查询：可以完成，但可能执行得很糟糕。最好将 PERS_INFO 存储为一个单独的表，以便分解产生的表可以作为到它的映射来实现。但是当前的技术并没有将物理存储与逻辑设计完全分开。也许是下一代软件工程师需要解决的问题？

它建议将 PERS_INFO 存储为一个单独的表，但这到底意味着什么？我将如何在 SQL Server 中实现它？

Answer 1

最好将 PERS_INFO 存储为一个单独的表，以便分解产生的表可以作为到它的映射来实现。但是当前的技术并没有将物理存储与逻辑设计完全分开。

他说的是 dbms 将其存储为单个表，而不是您将其存储为单个表。

关系模型本身没有提及物理存储。它只要求“数据库被用户感知为表。。在物理层，实际上，该系统是免费的存储数据的任何方式，它喜欢。” （数据库系统简介，第 7 版，CJ 日期，第 61 页）

所以 Darwen 是说如果数据库设计者声明了一组 6NF 表，连同他们的

• 候选键，
• 分布式密钥，
• 外键，
• 外来分布式密钥，
• 等等，

然后 dbms 可以自由地

• 将那组 6NF 表实现为 SQL 表空间中的单个表，
• 对用户隐藏该单表实现，以及
• 向用户公开一组与数据库设计者声明的 6NF 表无法区分的可更新视图。

说了这么多，您也许可以通过在封面上创建单个表（可以这么说）来解决缺乏 dbms 支持的问题，并创建一组与您的 6NF 设计无法区分的可更新视图。撤销对单个表的权限，并要求所有用户仅使用可更新视图。您不能做的是让 dbms 仅根据一系列逻辑上正确的 6NF CREATE TABLE 语句来处理所有这些细节。