5

データベースに 2 つのテーブルordersとorderHistory.

 -----------------                    -----------------------
 |  orders       |                    |  orderHistory       |
 -----------------                    -----------------------
 | orderID  (PK) |                    | historyLineID  (PK) |
 | orderDate     |                    | status              |
 | price         |                    | quantity            |
 -----------------                    -----------------------

orderは複数の を持つことができるようになりましhistory linesた。ただし、 ahistory lineは単独では存在できません。これは弱いエンティティと呼ばれるため、からのPKは tableのPKordersの一部である必要があると聞きました。orderHistory

質問

  1. これは本当に正しい弱いエンティティ関係ですか? それらを識別する他の方法はありますか？
  2. テーブルのPKをテーブルorderに追加しorderHistoryて、複合主キーにする必要がありますか?
  3. に新しいレコードを追加することにした場合orderHistory、新しい複合キーを追加するにはどうすればよいですか? (orderIDは table から入手できますordersが、historyLineID自動インクリメントする必要があります。)
  4. これを通常の1 対多の関係としてモデル化し、代わりにorderID外部キーとしてのみ追加することにした場合はどうなりますか? そうすることの短所は何ですか？
  5. すべてのテーブルが第 3 正規形である場合、Weak エンティティをまったく無視すると、設計の後半で問題が発生しますか?

ノート

orderID&は両方ともhistoryLineID代理キーです。前もって感謝します。

4

2 に答える 2

7

エンティティが弱いのは、独立して存在できないからではなく、独立して識別できないからです。したがって、弱いエンティティに「つながる」関係は、「識別」関係と呼ばれます。実際には、これは、親の主キーが子の PK の (通常は適切な) サブセットに移行されることを意味します ( 「弱いエンティティ」という用語は通常、主キーに関連して定義されますが、理論的にはどのキーにも適用できます)。

独立して存在することはできませんが、独立して識別できるエンティティを持つことは完全に正当です。つまり、非 NULL との非識別関係にあります。

質問する必要があります:単独historyLineIDで一意にすることも、 ?と組み合わせて一意にすることもできます。後者の場合は、弱いエンティティになるのではないかと思います。orderID

これは本当に正しい弱いエンティティ関係ですか?

あなたが私たちに示したものは弱いエンティティではありません - 親の PK は子の PK に移行されません。

それらを識別する他の方法はありますか？

基本的に 2 つのオプションがあります。

  • orderHistoryには複合 PK:{orderID, historyLineID}があり、ここでorderIDは FK です。ところで、この PK は「自然」と見なすことができます。

    ここに画像の説明を入力

  • orderHistoryには代理 PK:{orderHistoryID}がありorderIDますが、PK の外にあります。ただし、代替キーが必要{orderID, historyLineID}です。

    ここに画像の説明を入力

テーブル order の PK をテーブル orderHistory に追加し、それを複合主キーにする必要がありますか?

はい、これは上記の最初のオプションです。それ自体に子関係がない限りorderHistory、これも最善の解決策です。子供がいる場合orderHistory、いくつかの要因に応じて、これが最善の解決策である場合とそうでない場合があります。

これを、代わりに orderID が外部キーとして追加される通常の 1 対多の関係としてモデル化することにした場合はどうなりますか? そうすることの短所は何ですか？

これはどちらでもない。上記のように、フィールドは外部キーと (主または代替) キーの一部の両方にすることができます。

すべてのテーブルが第 3 正規形である場合、Weak エンティティをまったく無視すると、設計の後半で問題が発生しますか?

キーを正しく指定しない限り、3NF に到達することはできません。また、独立して識別できるエンティティと識別できないエンティティを考慮しないと、3NF に到達できません。

于 2012-05-18T19:29:54.353 に答える
0
  1. 依存性があるため実体関係は弱いですが、本質的に優柔不断の例です。注文には 1 つから複数の履歴行が含まれる場合がありますが、各履歴行には orderID が必要ですよね?

オプションと必須の関係のように聞こえます。したがって、orderId には orderHistory に「オプションの」属性があります... 2. 主キーを orderID と historyLineID の組み合わせにすることで、問題を部分的に解決できます。 3. orderID テーブルで複雑な関係を作成する必要があります。したがって、order.orderID に戻ってから、新しい historyLineID を作成する必要があります。そうしないと、まだ存在しないものを作成できません。4. これが本来あるべき姿です。この方法は、スクリプトに取り組む将来の人々にとって、そしておそらくあなた自身にとって、はるかに簡単に理解できます。外部キーを使用して、複数の historyLineID (子) を持つ orderID (親) を作成します。注文には複数の注文明細が含まれる可能性があるため、この方法がおそらく最適です。

リンク:ここにリンクの説明を入力します

于 2012-05-18T16:34:54.090 に答える