web-dev-qa-db-ja.com

機能的な依存関係からキーを決定する

私はデータベース理論のコースを受講していますが、一連の機能的な依存関係があるため、キーを推測する方法を読んだ後は明確ではありません。

問題の例があります：

リレーションのすべてのキーを検索R(ABCDEFG)機能依存性あり

AB → C
CD → E
EF → G
FG → E
DE → C
BC → A

以下のどれが鍵であるかを特定することにより、知識を証明します。

a. BCDEF             
b. ADFG           
c. BDFG           
d. BCDE

機能の依存関係を分解して、属性のいくつかの組み合わせが重要であると結論付ける方法を誰かに教えてもらえますか？私はこれらのタイプの問題に数多く直面することを期待しており、そのアプローチ方法を理解する必要があります。

databasefunctional-dependencies
44
David

FDを取得します。 AB→C

すべての属性が記載されるまで、たとえばABDEFG→CDEFG（これは、A-> AおよびB-> Bであることが自明であるため、ABDEFG→ABCDEFGと同等であることに注意してください）。

これは、ABDEFGがスーパーキーであることを示しています。

LHSがスーパーキーのサブセットであり、そのRHSにスーパーキーの他の属性が含まれている他のFDを確認します。

二つあります。 EF→GおよびFG→E。これらのRHSの属性をスーパーキーから削除します。これにより、2つのキーが得られます。これらは確かにスーパーキーですが、必ずしも削減できないわけではありません：ABDEFとABDFG。

ただし、AB→CおよびCD→Eから、ABD→Eも導出できます。したがって、ABDEFキーからEを削除することもできます。ここで厄介なのは、「他のFDをチェックする」と言ったとき、明らかにFDのセットのクロージャーに表示されるFD（つまり、与えられたFDのセットから派生するFD）もチェックする必要があることを意味する...そして、それは手作業で行うのは少し非現実的です...

結果が正しいかどうかを確認するのに役立つサイト：

http://raymondcho.net/RelationalDatabaseTools/RelationalDatabaseTools

これで、オプションcがキーであることを判別できるはずです。

31
Erwin Smout

まあ、これはかなり簡単なはずです。必要なのは、指定されたすべてのキーのクロージャーを取得し、Rのすべての属性が含まれているかどうかを確認することです。たとえば、BC-> AおよびBCはBCDEFのサブセットであるため、EF for FD EF->G。このクロージャーにはRのすべての属性が含まれているため、BCDEFがキーです。クロージャを取る主な目的は、特定の属性セットからすべての属性に「到達」できるかどうかを確認することです。クロージャーは、FDをナビゲートすることで実際に到達できる属性のセットです。

3
Parth Mehta

DB理論のコースを受講しているので、SQLの経験があると仮定して、理論を実装コンテキストに関連付けてみてください。

基本的に、リレーションは実装でテーブルと呼ぶものであり、キーはUNIQUE行を識別するために使用できる属性（読み取り列）のセットです（db理論ではこれはTupleになります）。ここで最も単純な例えは、キーが主キーであり、リレーション（テーブルの行）で単一のタプルを識別するために使用できる他の列のセットであるということです。そのため、これを行うための基本的な手順は次のとおりです（例Aを順を追って説明し、残りは試してみましょう）。

  1. 提案されたキーにないすべての属性をリストします（したがって、BCDEFにはAとGは含まれません）。

  2. 欠落している属性ごとに、機能依存関係のリストを調べて、提案されたキーが欠落している属性を推測できるかどうかを確認します。

                 a. So for A, you have BC -> A.  Since both B and C are in the proposed
                key BCDEF, you can infer that BCDEF -> A.  Your set now becomes
                BCDEFA.
             b. For G, again going through your FDs you find EF -> G.  Since both
                E and F are in BCDEFA, you can infer BCDEFA -> G.

BCDEFからAとGの両方を推測できたため、オプションaは関係ABCDEFGのキーです。これにはアルゴリズムがあり、おそらくコーステキストのどこかにあると思います。おそらく例もあります。パターンが直感的にわかるまで、手動でステップ実行する必要があります。

編集：私がこのアルゴリズムを探すためにテキストをさかのぼる理由は、それがdb理論コースであるので、あなたの試験が多肢選択とは対照的に書かれようとしているということです。これが当てはまる場合、コースのテキスト/メモで示されている表記法を体系的に追うことができれば、より部分的なクレジットが得られます。

主な目標は、キーを関係に変換することです。これにより、提案されたキーが実際にキーであることを証明する必要があります。

2
Dave

まあ、私はこのようなものの専門家ではないので、間違っている場合は修正しますが、私のアプローチは不可能な答えを排除することです

この場合：

fDはどれもB、D、またはFを「与える」ものではありません。これらはリレーションの一部であるため、B、D、およびFを含まないスーパーキーは存在できません...回答bを削除します（Bがありません）。 ..回答dを削除（Fがありません）

リレーションのすべての部分を取得するのに十分な情報が含まれている場合、残りの回答を確認しましょう

回答a（BCDEF）はB、C、D、E、Fを「与える」ので、FDを使用してAとGを見つける必要があります... AはBCから到達でき、GはEFから到達できるため、鍵です

回答c（BDFG）はB、D、F、Gを「与える」ので、FDを使用してA、C、Eを見つける必要があります... EはFGで到達できます... CはDEで到達できます（後FGでEに到達）...そして最後に、BCでAに到達できます（Cに到達した後）...

だから答えcはリレーション全体にこの方法でアクセスできるのである種のキーです...しかし、これが正式な定義に適合するのに十分かどうかはわかりません...推測する必要がある場合、私は言うでしょういや

1
DarkSquirrel42

コード

コードが長い説明以上にあなたに話しかける場合、機能の依存関係に基づいてキーを見つけるアルゴリズムの25行の実装があります。

https://github.com/lovasoa/find-candidate-keys/blob/master/find-candidate-keys.js

例

candidate_keys(["A","B","C","D","E","F","G"], [ [['A','B'], 'C'], [['C','D'], 'E'], [['E','F'], 'G'], [['F','G'], 'E'], [['D','E'], 'C'], [['B','C'], 'A'] ])は[["B","D","F","G"],["B","D","E","F"],["B","C","D","F"],["A","B","D","F"]]を返します

1
lovasoa