ドメイン キー正規形式 (DKNF) は、データベース スキーマ設計のプロセス中に、特にリレーショナル データベースのコンテキストで適用される正規化された設計原則です。 DKNF は、ボイス・コッド正規形 (BCNF) や第三正規形 (3NF) などの他の正規化形式から生じる潜在的な異常に対処するために、1981 年に Ronald Fagin によって初めて導入されました。
DKNF は、他の正規化形式への準拠を維持しながら、冗長性を排除し、データベース スキーマの異常を更新することを目的とした堅牢な設計コンセプトです。基本的に、DKNF は、すべてのドメイン制約 (属性のすべての有効な値のセット) がキーまたはキーの組み合わせによって強制されることを保証します。 DKNF を実現するには、データベース スキーマが次の基準を満たす必要があります。
- ドメイン内のデータに課されるすべての制約は、キー、キー全体、およびキー以外の何ものでもないもの (考慮されているテーブルと属性の両方に関して) の結果である必要があります。
- データベース内の属性は、それを決定できるすべてのキーに完全に依存する必要があります。
DKNF を実現すると、データベース スキーマの設計と効率において多くの利点が得られます。これらの利点には次のものが含まれます。
- 冗長性の排除: DKNF は、すべての非キー属性が主キーに完全に依存することを保証し、それによってデータベース スキーマ内のデータの冗長性の可能性を減らします。
- データの整合性の向上: DKNF は、キーを通じてすべてのドメイン制約を強制することで、有効なデータのみがデータベースに保存されるようにしてデータの整合性を維持します。
- 更新異常の減少: DKNF スキーマを使用すると、キー以外のすべての属性が主キーに完全に依存するため、データへの変更によって不整合が発生する可能性が低くなります。これにより、削除、挿入、変更の異常などの更新の異常のリスクが軽減されます。
DKNF の概念を説明するために、例を考えてみましょう。製品、注文、顧客の個別のエンティティを持つ電子商取引アプリケーションのデータベースがあるとします。 1 つの注文に複数の製品を含めることができ、顧客は複数の注文を行うことができます。この場合、Orders テーブルの主キーは OrderID と CustomerID の組み合わせになり、Order Products テーブルの主キーは OrderID と ProductID の組み合わせになります。
データベース スキーマが DKNF にない場合、属性が部分的にのみ複合キーに依存するシナリオが発生する可能性があります。たとえば、Product Price 属性が Order Products テーブルに格納されているとします。このシナリオでは、1 つの注文で 1 つの製品の価格が変更された場合、一貫性を維持するために、他のすべての注文でも同じ製品の価格を変更する必要があります。これは、非 DKNF スキーマ設計に起因する更新異常の例です。
スキーマを DKNF に導入するには、Product Price 属性を Products テーブルに移動して、ProductID 主キーに完全に依存させることができます。これにより、スキーマの更新異常のリスクが排除され、データの整合性が維持されます。
AppMasterのno-codeプラットフォームは、DKNF などの正規化された設計原則の概念を活用して、ユーザーが包括的で効率的なデータベース スキーマを作成できるように設計されています。当社のビジュアル データ モデリング ツールを使用すると、ユーザーはエンティティ間の関係を定義および管理でき、結果として得られるスキーマが DKNF およびその他の正規化形式に準拠していることを確認できます。
AppMasterで生成されたアプリケーションは、ドメイン キー標準形式 (DKNF) の採用など、データベース設計のベスト プラクティスに従っており、中小企業から高負荷のエンタープライズ アプリケーションまで、さまざまなユースケースに対応するスケーラブルで高性能なアプリケーションを保証します。当社のプラットフォームを使用すると、シチズン開発者は DKNF やその他の重要な原則の力を簡素化された方法で活用でき、広範なデータベース設計の専門知識を必要とせずに、高効率で最適化されたアプリケーションを作成できます。
