域键范式（DKNF）是在数据库模式设计过程中应用的规范化设计原则，特别是在关系数据库的上下文中。 DKNF 最初由 Ronald Fagin 于 1981 年提出，旨在解决其他标准化形式（例如 Boyce-Codd 范式 (BCNF) 和第三范式 (3NF)）引起的潜在异常。
DKNF 是一个稳健的设计概念，旨在消除冗余并更新数据库模式中的异常，同时保持与其他规范化形式的合规性。本质上，DKNF 确保每个域约束（属性的所有有效值的集合）由一个键或键组合强制执行。要实现 DKNF，数据库模式必须满足以下条件：
- 对域中的数据施加的所有约束都必须是键、整个键的结果，而除了键之外什么都没有（相对于所考虑的表和属性）。
- 数据库中的任何属性都应该完全依赖于可以确定它的所有键。
实现 DKNF 在数据库模式的设计和效率方面具有许多好处。这些好处包括：
- 消除冗余： DKNF确保所有非键属性完全依赖于主键，从而减少数据库模式内数据冗余的机会。
- 改进的数据完整性：通过密钥强制执行所有域约束，DKNF 通过确保仅有效数据存储在数据库中来维护数据完整性。
- 减少更新异常：使用 DKNF 模式，数据更改不太可能导致不一致，因为每个非键属性完全依赖于主键。这降低了更新异常的风险，例如删除、插入和修改异常。
为了说明 DKNF 的概念，让我们考虑一个例子。假设有一个电子商务应用程序的数据库，其中包含产品、订单和客户的单独实体。一个订单可以有多个产品，一个客户可以下多个订单。在这种情况下，Orders 表的主键将是 OrderID 和 CustomerID 的组合，Order Products 表的主键将是 OrderID 和 ProductID 的组合。
如果数据库模式不是 DKNF，则可能存在属性仅部分依赖于组合键的情况。例如，假设“产品价格”属性存储在“订单产品”表中。在此场景中，如果一个订单中的一种产品的价格发生更改，则所有其他订单中相同产品的价格也应更改，以保持一致性。这是由非 DKNF 架构设计导致的更新异常的示例。
为了将架构引入 DKNF，可以将 Product Price 属性移至 Products 表，使其完全依赖于 ProductID 主键。这消除了架构中更新异常的风险并保持了数据完整性。
在AppMaster ，我们的no-code平台旨在通过利用DKNF等规范化设计原则的概念来帮助用户创建全面且高效的数据库模式。我们的可视化数据建模工具使用户能够定义和管理实体之间的关系，确保生成的模式符合 DKNF 和其他规范化形式。
AppMaster生成的应用程序遵循数据库设计的最佳实践，例如采用域键范式 (DKNF)，以确保从小型企业到高负载企业应用程序的各种用例的可扩展、高性能应用程序。我们的平台允许公民开发人员以简化的方式利用 DKNF 和其他关键原则的力量，使他们能够创建高效且优化的应用程序，而无需广泛的数据库设计专业知识。
