私は自分のリーグではないデータベース設計の問題に出くわしました。そして、私の頼りになるDBAの第一人者が消防訓練に出かけています。
本質的に、私は次の主キー（簡潔にするためにPK）を持つテーブルを持っています。
child_id integer
parent_id integer
date datetimechild_idそして、parent_idエンティティテーブルへの外部キーです。「子」テーブル自体にも「親」テーブルへの外部キーが含まれています。loはそれぞれ、child_id常にparent_id上記のテーブルで想定されているものと同じものを参照します。実際、この2つを同期させるための追加のコードがあることがわかります。
これにより、この熱狂的な正規化の初心者は「代わりに冗長性を削除する必要があります！」と言います。
私は次のように分解します。
Table_1 PK:
child_id integer
date datetime
Table_2 PK:
parent_id integer
date datetime
Table_3: (already exists)
child_id integer PRIMARY KEY
parent_id integer FOREIGN KEYそして、これらの人たちを自然な方法で結合すると、元のテーブルが回復します。この5NFを作ったのは私の理解です。
しかし、今ではビジネスルールが隠されていることに気づきました。
通常、特定child_idのに関連付けられている日付は、対応するに関連付けられている日付のサブセットである必要がありますparent_id。最初のテーブルがこのルールを適用していることがわかります。
日付が大きくなりすぎるまで自由に表1に追加できるため、私の分解ではルールを適用しません。
これは私をここに導き、次の質問があります：
この分解は5NFですか？私はそれが挿入異常を許可すると言うだろうが、また次のそれ自体、Wikiの例に従うように見えるこのガイドを。「私が強調したもの」というフレーズは、「3つの別個のレコードタイプからなる正規化された形式からすべての真の事実を再構築できる」という特別な休止を与えます
Table_1。この分解が気に入らないとしましょう（気に入らない）。テーブルとコードをそのままにしておくことが実際的な解決策であることを私は自由に認めます。しかし、理論的には、最初のテーブルから離れてビジネスルールを保持するように制約を分解または追加する方法はありますか？