問題タブ [3nf]

コースで提供されているスライドは、説明がなく、推論方法の例を示しているだけだと感じているため、合成アルゴリズムと候補キーの検索に関していくつかの問題があります。

したがって、単一の関係 R[ABCDE] を持つリレーショナル スキーマがある場合、機能的な依存関係: {AB->CD, C->AD, E->B},

これまでのところ、私はここにたどり着きました: 正規のシェルは: C={AB->C, C->D, E->B} で、候補キーは: EB AE と EC です。

1) 合成アルゴリズムを適用して、ロスレスで依存関係を保持する 3NF 分解を見つけます。

分解が実際にロスレスで依存関係が保持されているかどうかを確認する方法は知っていますが、そこに到達する方法は知りません。下記を参照してください：

i) F のカノニカル カバー C を構築する

ii) C'={X 結合 Y | X->Y "所属" Consol(C)} これは私が知っている

iii) C を C' のサブセットと定義し、別の関係に含まれるすべての関係を削除します。これは、私が正しいと思うかどうかを知っています。

iv) C が R のスーパーキーを既に含んでいる場合、C2 を C と定義します。このステップがわかりません。

2) 3) で得られた分解が BCNF にもあるかどうかを徹底的に動機づける。

前もって感謝します！

関係を考えると、R = ABCDE

そして、この FD のセット:

候補キーを見つけることができますABE(正しいですか?)

この関係 R を 3NF に分解する必要があります。

私が理解できないのは、どの程度まで分解するのですか? 候補キーと FD を考慮されていると思いますが、具体的なプロセスはどのようなものですか。私が見たものはすべて、この小さな問題に適用するには密度が高すぎました。

Database Management Systems book から: リレーション SNLRWH (各文字は属性を表す) と次の機能依存関係が与えられます。

• S->SNLRWH (S は PK)
• R->W

私の試み：

• まず、これは 3NF ではありません。2 番目の FD では、R に W が含まれておらず、R にキーが含まれておらず、W がキーの一部でもありません。
• 第二に、それは2NFである/ない。2 番目の FD を調べると、W は R に依存しており、R はキーの一部ではありません。立ち往生。

複数のシステムを備えた従来の IT 環境があり、それぞれに顧客に関する同じデータを参照する独自のデータベースがあります。つまり、販売システム、会計システム、および運用システムであり、これらはすべて同じ顧客、アカウント、および製品に関するデータを持っています。

場合によっては、このデータは 2nf に格納され、場合によっては 3nf に格納されます。この 2 つを統合するためのベスト プラクティスまたは既知のアルゴリズムはありますか?

たとえば、3nf 販売システムで顧客に変更を加え、2nf オペレーション システムで顧客に関する同じ情報を確実に更新する方法はありますか?

ありがとう、

イアン

ツリーのノードである要素を表す MySQL テーブルがあります。要素には ID と、同じテーブル内の別の要素を参照する parent_id 要素があります (最上位要素の場合は null になる可能性があります)。これらの要素をローカル (同じ親を持つ要素) とグローバル (ツリーをフラットにしてリストとして表示したい) の両方でソートできるようにしたいと考えています。親ノード内の要素を並べ替えることができる local_sorting_key を各要素に与えましたが、ツリー全体を再帰的に並べ替える機能が必要です。

私が行ったことは、新しいフィールド global_sorting_key を追加することです。これは、親 (要素に親がある場合) の global_sorting_key と local_sorting_key を連結したものです。これにより、各要素の並べ替えキーを再帰的に設定し、テーブル全体を簡単に取得して SQL を使用して並べ替えることができます。ただし、local_sorting_key を変更しても global_sorting_key が変更されず、内部の不整合が生じるため、このソリューションは正規化されていません。

3NF を維持しながら、簡単な方法で問題を解決するにはどうすればよいですか?

FDが A--> B の場合、関係 R(A,B,C,D) の最高正規形は何ですか? CD--> B; A--> CD; CD--> A ? 答えを出すだけでなく、この種の問題を解決するための段階的なアプローチも教えてください。

私は次のテーブルデザインを持っています:

WORK_ACTION_TYPE_ID が単純なルックアップである場合

アクション タイプが動的チェックリストの場合、CHECKLIST_CLASS_IDプログラムで使用するチェックリストの詳細をアクションが認識できるようにするために が必要です。CHECKLIST_CLASS_IDこのアクション定義が動的チェックリストでない場合、フィールドは適用されないため、このデザインは好きではありません。この事実を切り離す最善の方法がわかりません。

したがって、私のテーブルは 3NF ではなく 2NF であると言うのが正しいかもしれません。もしそうなら、3NFに到達するにはどうすればいいですか??

冗長性により、ユーザーが特定の情報を不注意に削除する可能性があることは知っていますが、それは 2NF にのみ適用されたと思います。3NFはどうですか？3NF にも推移的な関係があることは知っています。しかし、それは 2 つの決定要因の間で相反するものであるため、問題の性質が異なるに違いないと思います。また、3NF には他に問題はありますか?

私が所有し、読んだ本を含むデータベースを作成しています。私が所有して読んでいる本 (または「タイトル」) と、私が所有して読んでいるその本の版 (または「冊子体の紙」) の両方を追跡したいと考えています。

Book と Edition は多対多です。私は『Democracy in America』という本の複数の版を所有しています。私はまた、「誰がために鐘は鳴る」というものを含む、いくつかの本 (または「タイトル」) を含む「ヘミングウェイ」という版を所有しています。

したがって、本と版の間の架け橋が必要です。私のテーブルは次のとおりです。

Book (book_pk*,title)
Edition (edition_pk*,ISBN,year)
Book_Edition (book_fk,edition_fk)

Book_Edition テーブルには複合主キーが含まれているというのは正しいと思います。

今、私は Read テーブルに取り組んでいます。このテーブルには、私が読んだ本と、それらを読んだ日付が含まれます。これまでの読み取りテーブルには次のものが含まれています。

読み取り (read_pk,date,note)

ただし、Read テーブルを自分の書籍やエディションに関連付ける必要があります。この場合、book_fk と edition_fk は推移的に依存しているように見えます。では、どうすれば第 3 正規形に準拠できるのでしょうか。

オプション 1:
Read テーブルを次のように変更します: Read (read_pk,date,note,book_fk,edition_fk)

オプション 2:
Book_Edition テーブルを次のように変更します: Book_Edition (book_edition_pk,book_fk,edition_fk)
Read テーブルを次のように変更します: Read (read_pk,date,note,book_edition_fk)

オプション 3: ???

任意の洞察をいただければ幸いです。これが他の場所で扱われている場合はお詫び申し上げます。有望に見えるいくつかの投稿を見ましたが、相対的なn00bとして、それらを解読して自分の状況に適用することができませんでした.

sqlvogel ごとに編集:
依存関係の特定を試してみましょう。つまり、フィールド A が変更された場合にフィールド B が変更される必要がある、または変更される可能性がある場所を特定しようとしています。本 (「タイトル」と「綴じられた紙のコレクション」の両方) は本質的に永久的なものであるため、これは難しいと思います。タイトル、ISBN、または年のフィールドを編集する唯一の機会は、データ入力エラーがある場合です。特定の edition_pk の ISBN が間違って入力されている場合、同じ edition_pk の年も間違って入力されている可能性がわずかに高くなりますが、それは依存関係ですか?

読み取りテーブルに関しては、状況は似ていると思います。本を読むたびにレコードが作成され、理論的には編集されることはありません。特定の日に読まれた本と版を特定したい。データ入力エラーがある場合、1 つまたは複数のフィールドに影響する可能性があります。特に、間違った book_fk が入力された場合は、間違った edition_fk も入力された可能性が高くなります。繰り返しますが、それは私が心配すべき依存関係ですか?

依存関係について考えるときに他に考慮すべきことはありますか?