3

データベース モデリングを行っているときに弱いエンティティを使用することはありませんが、今のところ問題ないようです。私は通常、各エンティティにプライマリ (自動生成) キーを与えることで、問題全体を無視しました。

ただし、存在が他のエンティティに完全に依存している場合、一部のエンティティは弱いはずであると言及している投稿に出くわしました。

しかし一方で、主キーを形成するのに十分な属性を持たないセットとして弱いエンティティを参照する人もいます。つまり、データベース内のすべてのエンティティは、自動インクリメント キーを与える前は最初は弱いということです。

弱いエンティティの重要性と、それらを使用しない場合の結果について、概要を説明していただけますか? 各エンティティに主な自動生成キーを与えて、それを強力にしないのはなぜですか?

アップデート：

代理キーを作成し、外部キーを使用してそれを親エンティティに関連付ける代わりに、親エンティティの主キー + 識別子によって弱いエンティティを識別する必要がある理由を誰かが説明できますか (更新と削除のカスケード変更を使用)。

4

3 に答える 3

2

例として、複数の注文品目を持つ注文を取り上げます。弱いエンティティは、独自のテーブルに格納された個々の項目になります。それらの主キーは、注文の主キーに単純な整数 (注文内でのみ一意である 1、2、3 など) を加えたものである可能性があります。列、それらのキーは 2 つの列にまたがり、その方法でのみ一意です。

注文が削除された場合は、注文品目を削除する必要があります。単独では意味がありません。それらを弱体にしているのは、このつながりです。一方が削除されると、もう一方が削除されます。

各注文項目に独自の主キーを与える場合でも、それらを注文項目に関連付ける必要があります。つまり、注文項目の外部キーを入れるか、相互参照テーブルを用意する必要があります。(注文から品目番号を知る必要がある場合もあります。これは、単純な整数列を追加することを意味します...そして、この時点で、自動生成されたものなしでキーを持つのに十分な数を追加しました.) デザインパターンの場合所有しているサブアイテムのうち、これらの選択肢のいずれかは少しやり過ぎです。

複雑な主キーを使用すると、オーダーとライン オーダー アイテム間の関係も強化されます。このスキーマでは、ライン アイテムを複数のオーダーに割り当てることはできません。

もう 1 つの考慮事項は、両方のテーブルがそのキーを持っているため、注文項目の主キーに従って注文と注文品目を分割できることです。(シャーディングは通常、通常の列よりも主キーに基づいて実行する方が簡単です。)

階層的な封じ込めが常に望ましいとは限りません。しかし、これは非常に一般的に発生するパターンであるため、明確にしておくとよいでしょう。この場合、複合キーを使用できます。ここで、明細項目をサブ項目として (つまり、含まれている) 注文項目を使用して、明細項目が注文に関して 1 対多であるだけでなく、明細項目が所有されており、注文とは独立して存在しないと言っています —単一の注文オブジェクトを作成するために構成された品目。

これに合わせて、(すべての) 品目の個別のキー スペースを (グループとして一緒に) 管理するつもりはありませんが、代わりに注文のキー スペースを借用して拡張します。システムに明細項目用の個別のキー スペースを維持するように依頼する代わりに、手動で (つまり、あまり形式的ではありませんが) 注文に戻る外部キー関係を維持し、整数の明細項目を (注文の外部参照とは) むしろ別々に維持します。注文内の品目番号を含む複合キー全体の一意性を確保するようシステムに要求できます。

もちろん、注文に関連付けられていない項目を追加することはできませんが、複合サブキーを使用すると、別の項目と重複するものを追加することもできません (例:同じオーダーに 2 つの項目 #3 を追加することはできません)。

これにより、ラインアイテムの生産者と消費者は、それらが独立したアイテムとしてではなく、オーダー内およびオーダーの一部として含まれていると考えるように強制されます。つまり、オーダーを介してラインアイテムを参照するように強制されます。 、その明細項目の 1 つを参照することによって、注文への参照を「無料」で取得します。(また、そのような外部キーの一部として順序への参照も持っているため、複合外部キーのその順序部分だけを使用して、グループ化または結合することもできます。)

于 2013-01-06T16:35:46.907 に答える
1

私は最近、湖の測定値のために大量のデータ サンプルを管理しなければならないプロジェクトに取り組みました。このプロジェクトでは、次のようなテーブルがありました。ここにrecordsは、場所とアップローダーごとの湖の測定値のコレクションがありsamples、実際の湖の測定値 (温度や強度など) が含まれています。

CREATE TABLE records(
    email TEXT REFERENCES users(email),
    lat DECIMAL,
    lon DECIMAL,
    depth TEXT,
    upload_date TIMESTAMP,
    comment TEXT,
    PRIMARY KEY (upload_date,email)
);

CREATE TABLE samples(
    date_taken TIMESTAMP,
    temp DECIMAL,
    intensity DECIMAL,
    upload_date TIMESTAMP,
    email TEXT,
    PRIMARY KEY(date_taken,upload_date,email),
    FOREIGN KEY (upload_date,email) REFERENCES records(upload_date,email)
);

samplesに依存する弱いエンティティとしてモデル化されましたrecords。ご存知のように、これはすべての外部キーが から継承recordsされ、 の 1 つの行を識別するために使用されることを意味しsamplesます。しかし、代わりにエンティティにすることにした場合はどうなるでしょうか? いくつかの異なる方法で見ることができます。

  1. からの主キーはrecords存在せずsamples、あなたが提案するように、ある種の任意の自動インクリメント タイプ ID を割り当てる必要があります。各レコードには数千のサンプルが含まれており、ユーザーはサンプルを現場で記録したレコードの一部と考えています。彼らはレコードごとにサンプルを参照することを期待し samplesているため、実際に属するレコードへの明確なマッピングがない非常に大きなテーブルができます。

  2. または、単に弱いエンティティとしてモデル化するのではなく、行でそれ自体を識別できるようにする必要があることを認識しているため、 andrecordsを割り当てます。これら 2 つのエントリを外部キーにすると、気付かないうちに弱いエンティティが作成されてしまいます。そうでない場合は、データベースが行うのではなく、アプリケーション層がとが にも存在することを確認する責任を負う必要があります。upload_dateemailupload_dateemailrecords

この場合、samples脆弱なエンティティ (主キーに外部キーを含む) を作成するのが最も簡単なオプションです (そして最も理にかなっています)。

概要

エンティティが実際に弱い場合は、エンティティを弱いものとしてモデル化する必要があります。エンティティ自体を識別するために別のキーの一部を必要とする (主キーの一部である外部キーを持つ) エンティティがある場合、そのエンティティはおそらく脆弱です。

弱いエンティティを使用しないようにシステムを改造できますか? おそらく、関連付けられていないサンプルが必要な場合は、それらのupload_dateand をemailnull にすることができる必要があります。つまり、それらは主キーになく、弱いエンティティにはなりません。1で説明したようなことをしなければなりません。

于 2013-01-06T16:48:09.483 に答える
0

主キーは一意である必要があります。永遠に。それだけです。テーブル内のデータがそれを提供しない場合は、当然、代理キーを作成します。

今、それらは何ですか。自然キーは 1 つまたは複数の既存の列で構成されますが、代理キーは余分に追加された列であり、通常は自動インクリメンタルです。

自然キーの良い例は、countriesテーブル内の ISO 国コードです。ここに自動インクリメント列を追加しても、何も得られません。それどころか、既に ISO コードがすぐそこにあるため、一部のクエリでは、countries テーブルで JOIN を実行する必要がなくなります。

悪いもの、contactsテーブル内の名前 (または複数の列)。そのため、この場合は代理キーを使用することをお勧めします。

それが私がそれについて考える方法であり、疑わしいレイアウトの問題に遭遇することはめったにありません。

UPDATE実用的なヒント:主キーを構成する列に対して実行しないでください。その行を削除して、新しい値で再挿入します。これにより、多くの頭痛を軽減できます。

于 2013-01-06T17:13:54.880 に答える