問題タブ [candidate-key]

候補キーに NULL 値を設定できないことを理解しています。しかし、候補キー自体が、主要な属性と呼ばれる多くの属性の組み合わせである可能性があります。これらの主要な属性は値として NULL を持つことができますか?

よろしく、

一連の FD の下でクロージャを計算する方法について混乱しています。私が持っている実際の質問は

関係 R{A, B, C, D, E} は次の FD を満たす: A→D AB → CE→B

この一連の FD の下で {A,E}+ の閉包を計算します。また、候補キーは何ですか？

これが私が答えだと思ったものですが、私が正しいかどうかはわかりません。オンラインで調べてみましたが、実際には何も役に立ちませんでした。うまくいけば、ここの誰かが私を助けてくれます。

候補キーは A です。

これは正しいです？また、フォーマットが奇妙に見える理由もわかりません....コード用に4つのスペースをインデントしました....

次の列を持つテーブルがあるとします。

• person_id (主キー)
• ファーストネーム
• 苗字
• 誕生日

{first_name, last_name} の組み合わせにも一意の制約があります (同じ名前を持つ人が増えることはわかっていますが、例を単純にしたいと思います)。この表が第 3 正規形かどうかを知りたいです。

私の推論（編集前）：

• すべてのフィールドにはアトミック値のみを含めることができるため、テーブルは第 1 正規形になります。
• 候補キーは、1) person_id、2) [first_name, last_name] です。
• 非プライム属性は誕生日だけです。
• 属性誕生日は、候補キー 1 の一部に機能的に依存していません (候補キー 1 には属性が 1 つしかないため、これはとにかく不可能です)。
• 属性誕生日は、候補キー 2 の一部に機能的に依存していません
• したがって、この表は第 2 正規形です。
• 属性 birthday (is/is not) は候補キー 1 に非推移的に依存します
• 属性 birthday は、候補キー 1 に非推移的に依存しています。

質問（編集前）：

私が答えられない質問は、誕生日が非推移的に person_id に依存しているかどうかです。機能的には、この ID 番号と誕生日の間にはまったく関係がありません。

1. これは、推移的な依存関係 (誕生日は [first_name, last_name] に依存し、各組み合わせ [first_name, last_name] は ID にマップされる) があり、したがって 3NF ではないことを意味しますか?
2. これは、依存関係がまったくないということであり、したがって 3NF ではないということですか?
3. 私は難しい言葉を誤解していますか? この表は 3NF ですか?

私の推論（編集後）：

• person_id がわかれば、彼の名、姓、誕生日がわかるので、FD には {pe​​rson_id} -> {first_name}、{person_id} -> {last_name}、{person_id} -> {birthday} があります。
• 人の名前と姓がわかれば、その人の person_id と誕生日がわかるので、FD {first_name, last_name} -> {person_id} と {first_name, last_name} -> {birthday} があります。

• 人の誕生日を知っている場合、その人の person_id や名前については何も知らないため、誕生日から別の (セットの) 属性への FD はありません。

• すべてのフィールドにはアトミック値のみを含めることができるため、テーブルは第 1 正規形になります。

• 候補キーは 1) {person_id}、2) {first_name, last_name} です。
• 非プライム属性は {birthday} だけです。
• 属性 {birthday} は、CK 1 の一部の FD ではありません (CK 1 には属性が 1 つしかないため、とにかく不可能です)。
• 属性 {birthday} は CK 2 の一部で FD ではありません

• したがって、この表は第 2 正規形です。

• FD {person_id} -> {birthday} があるため、属性 {birthday} は CK 1 に非推移的に依存します。

• FD {first_name, last_name} -> {birthday} があるため、属性 {birthday} は CK 2 に非推移的に依存します。
• したがって、この表は第 3 正規形です。

依存関係 {person_id} -> {first_name, last_name} -> {birthday} がありますが、直接の依存関係 {person_id} -> {birthday} もあるため、この依存関係は推移的ではありません。

質問（編集後）：

私は本の FD の事前定義されたセットを持っていないので、FD が正しいかどうかわかりません。誰かがこれを確認できますか、または正しく見えない場合は、この実際の例で FD を見つける方法を示してもらえますか?

3 番目の推論 (2 回目の編集):

FD:

• 人物の person_id しか知らない場合は、その人物の名、姓、誕生日がわかります (同じ person_id を持つ人物が複数存在することはありません)。
  • FD: {person_id} -> {first_name}
  • FD: {person_id} -> {last_name}
  • FD: {person_id} -> {誕生日}
• {person_id} を含むスーパーセットを考慮する必要がなくなりました
• 人の名のみを知っている場合、この人の他のフィールドはわかりません (同じ名を持つ人が複数いる可能性があります)。
  • FD ではない: {first_name} -> {person_id}
  • FD ではない: {first_name} -> {last_name}
  • FD ではない: {first_name} -> {birthday}
• 人物の last_name しか知らない場合、この人物の他のフィールドはわかりません (同じ last_name を持つ人物が複数存在する可能性があります)。
  • FD ではない: {last_name} -> {person_id}
  • FD ではない: {last_name} -> {first_name}
  • FD ではない: {last_name} -> {birthday}
• ある人の誕生日しか知らない場合、その人の他のフィールドはわかりません (同じ誕生日の人が複数いる可能性があります)。
  • FD ではない: {birthday} -> {person_id}
  • FD ではない: {誕生日} -> {first_name}
  • FD ではない: {誕生日} -> {姓}
• 人の姓と名がわかれば、その人物の ID と生年月日がわかります (姓名が同じ人が複数存在することはありません)。
  • FD: {first_name, last_name} -> {person_id}
  • FD: {名、姓} -> {誕生日}
• {first_name, last_name} を含むスーパーセットを考慮する必要がなくなりました
• 人の名前と誕生日がわかっている場合、この人の他のフィールドはわかりません (同じ名前と誕生日を持つ人が複数いる可能性があります)。
  • FD ではない: {first_name, birthday} -> {person_id}
  • FD ではない: {first_name, birthday} -> {last_name}
• 人物の姓と誕生日がわかっている場合、この人物の他のフィールドはわかりません (姓と誕生日が同じ人物が複数存在する可能性があります)。
  • FD ではない: {last_name, birthday} -> {person_id}
  • FD ではない: {last_name, birthday} -> {first_name}

通常形:

• すべての属性には単一の値のみを含めることができるため、テーブルは第 1 正規形です。

• FD を見ると、1) {person_id}、2) {first_name, last_name} の 2 つの候補キーがあります。

• 非プライム属性は {birthday} だけです。
• 属性 {birthday} は、CK 1 の一部の FD ではありません (CK 1 には属性が 1 つしかないため、とにかく不可能です)。
• 属性 {birthday} は、CK 2 の一部の FD ではありません (つまり、FD {first_name} -> {birthday} または FD {last_name} -> {birthday} はありません)。

• したがって、この表は第 2 正規形です。

• S -> X かつ X -> T かつ not(X -> S) となるような X が存在する場合、S は推移的に T を決定します。

• S = CK1 = {person_id} および T = {birthday} とします。S -> X および X -> T となる唯一の X は、X = {first_name, last_name} の場合です。ただし、X -> S も成立します。したがって、S は非推移的に T を決定します。
• S = CK2 = {first_name, last_name} および T = {birthday} とします。S -> X および X -> T となる X は、X = {person_id} の場合のみです。ただし、X -> S も成立します。したがって、S は非推移的に T を決定します。
• したがって、この表は第 3 正規形です。

この質問を作成するときに提案されたように、私は間違いなく多くの異なる関連投稿をチェックしました。また、オンライン ソースと同様の問題からさまざまなサンプル問題を実行しました。ただし、具体的には以下の問題に固執しています。

次の関係 R と、R に保持される機能依存関係のセット S が与えられた場合、R のすべての候補キーを見つけます。あなたの作品を見せてください。

最初に、属性をグループに分けました。左側のみ、右側のみ、両側にある属性 (それぞれ D、ABCE、F) です。また、D の閉包を計算する必要があることもわかっています。ここで行き詰まります。一見すると、この問題を解決できないように見えますが、そうではありません。また、(AD)、(BD)、(CD)、(ED) の閉包を計算してみました。これは、D = D の閉包だと思ったからです。何か考えはありますか?

おはよう！一対多の関係が発生する可能性があるキーの一意のリストを維持するためのトリックを探しています。

問題

私は職場で恐ろしく正規化されていないデータベースを使用していますが、残念ながら再設計は問題外です。これに似た多数の推移的および部分的なキーの依存関係を含む 1NF マスター テーブルがあります。

IDの一意のリストを取得する必要があることがよくありGroupますが、通常は要件によってフィールドも要求Group_Descされます。残念ながら、アップストリームのデータ入力制限が不十分なため、この説明フィールドには複数のエントリが含まれる可能性があり、ほとんどのデータ プルでフィールドが一意である必要がGroupあるため、重複が発生する可能性があります。Group私の目的では、 1対 1Group_Descの関係を維持できる限り、どのレコードを取得するかはあまり気にしません。GroupGroup_Desc

Inline View大規模なクエリでフィールドを参照する必要があるときはいつでもとして参照する醜い解決策を思いつきましたGroup_Descが、これはパフォーマンスを低下させます。

質問

同じクエリ内で複数の値の単一行を繰り返しプルバックするためのパフォーマンスに適したトリックを誰かが持っていますか? 引き戻しGroupて、最初Group_Descに表示されるものだけを表示できるようにしたいと思います。

私は次のようなものを想定しています：

仲間の開発者がこのRANK関数を可能な解決策として挙げましたが、それを使用して値を削除する方法がわかりませんでした。

あなたが提供できるどんな助けも大歓迎です！

- - - - - - - - 編集 - - - - - - - - - - -

そのため、追加の分析を行った結果、元の相関サブクエリの省略が原因で実行プランが過度に長くなっていることを突き止めることができました。いくつかの述語を追加することで、オプティマイザーはより良い計画を作成することができ、実行時間が約 12 分から 2 分に短縮されました。これは私の期待に沿ったものです。

私は、Ponder Stibbons が以下で提案した Analytics ソリューションをかなり試しました。彼のソリューションは非常に洗練されており、この質問の回答として選択しましたが、主に自分で利用できたインデックスが原因で、元のソリューションよりも実行時間が大幅に遅かったため、この特定のクエリでは使用できませんでした。相関サブクエリ。

公正な比較において、Analytics ソリューションが Correlated SubQuery ソリューションと同等かそれ以上に実行されることに疑いの余地はありません。この問題に関する皆様のご支援に感謝いたします。

私は、リレーション R の候補キーとスーパーキーを見つけることを求める教科書の演習を行っています。

候補キーを解決しましたが、スーパーキーを解決する方法がわかりません。私は少し混乱しています。

リレーション スキーマと関数の依存関係は次のとおりです。

そのため、それを解いた後、{A、AB}が候補キーであることがわかりました。このためのスーパーキーを見つける方法がわかりません。どんな助けでも大歓迎です。皆さん、ありがとうございました。