問題タブ [identifying-relationship]

違いを完全に把握できていません。両方の概念を説明し、実際の例を使用できますか?

私はこの質問を読みました：識別関係と非識別関係の違いは何ですか？

しかし、まだよくわかりません...私が持っているのは3つのテーブルです。

1. ユーザー
2. オブジェクト
3. ピクチャー

ユーザーは多くのオブジェクトを所有でき、個々のオブジェクトごとに多くの写真を投稿することもできます。私の直感は、これが識別関係であることを示しています。これは、objectsテーブルにuserIDが必要であり、picturesテーブルにobjectIDが必要だからです...

それとも私は間違っていますか？他のトピックの説明は、オブジェクトが実際にどのように接続されているかではなく、データベースがすでにコーディングされた後にデータベースが解釈する方法の理論的な説明に限定されています。データベースをどのように構築するかを考えるときに、識別するかどうかを決定する方法について少し混乱しています。

それで、私はデータベース設計における識別関係と非識別関係について読んでいますが、SOに関する多くの答えは私と矛盾しているようです。これが私が見ている2つの質問です：

1. 識別関係と非識別関係の違いは何ですか
2. 関係の特定または非特定を決定する際の問題

各質問の上位の回答を見ると、識別関係とは何かについて2つの異なるアイデアが得られているように見えます。

最初の質問の回答は、識別関係は「子テーブルの行の存在が親テーブルの行に依存する状況を説明している」と述べています。この例として、「著者は多くの本を書くことができますが（1対nの関係）、著者なしでは本は存在できません」などがあります。それは私には理にかなっています。

しかし、質問2の回答を読むと、「子供が親を特定するのであれば、それは特定の関係である」と書かれているので混乱します。次に、社会保障番号（個人の識別）などの例を示しますが、住所はそうではありません（多くの人が住所に住むことができるため）。私には、これは主キーと非主キーの間の決定の場合のように聞こえます。

私自身の腸の感覚（および他のサイトでの追加の調査）は、最初の質問とその応答が正しいことを示しています。ただし、データベース設計の理解に取り組んでいるので、何か間違ったことを学びたくないので、先に進む前に確認したかったのです。前もって感謝します。

@JoinColumnとの正確な違いは何@PrimaryKeyJoinColumnですか？

@JoinColumn外部キーの一部である列に使用します。一般的な列は次のようになります（たとえば、追加の属性を持つ結合テーブルの場合）。

列をPK（別名識別関係）にも昇格させるとどうなりますか？列がPKになっているので、次のタグを付ける必要があり@Idます。

今の質問は：

@Id+@JoinColumnはちょうど同じですか@PrimaryKeyJoinColumn？：

そうでない場合、何の@PrimaryKeyJoinColumnためにありますか？

データストレージの技術を学ぼうとして、私はできるだけ多くの確かな情報を取り入れようとしています. PerformanceDBA は、特に次の投稿にいくつかの非常に役立つチュートリアル/例を投稿しました:私のデータは正規化されていますか? およびリレーショナル テーブルの命名規則。このモデルのサブセットについては、すでにここで質問しました。

だから、彼が提示した概念を理解していることを確認するために、私は物事をさらに一歩か二歩進めて、概念を理解しているかどうかを確認したかった. したがって、この投稿の目的は、他の人も学ぶことができることを願っています. 私が提示するものはすべて、私にとって概念的なものであり、生産システムに適用するのではなく、学習するためのものです。私は PerformanceDBA のモデルを使用して作業を開始したので、PerformanceDBA からも情報を得ることができれば素晴らしいと思いますが、どなたからも情報を提供していただければ幸いです。

私はデータベース、特にモデリングに慣れていないので、このテーマに関する専門知識が不足しているため、常に適切な質問をしたり、自分の考えを明確に説明したり、適切な言葉遣いを使用したりするとは限らないことを最初に認めます。ですから、それを心に留めておいてください。私が軌道から外れた場合は、遠慮なく正しい方向に導いてください。

これに十分な関心がある場合は、これを論理フェーズから物理フェーズに移して、プロセスの進化を示し、スタックで共有したいと思います。ただし、論理ダイアグラム用にこのスレッドを保持し、追加の手順のために新しいスレッドを開始します。私の理解では、最後にMySQL DBを構築していくつかのテストを実行し、思いついたものが実際に機能するかどうかを確認します。

これが、この概念モデルで捉えたいもののリストです。V1.2用に編集

1. これの目的は、バンド、そのメンバー、および彼らが出演するイベントを一覧表示し、音楽やその他の商品を販売することです。
2. メンバーは友達とマッチングできます
3. メンバーは、バンド、音楽、イベントについてレビューを書くことができます。
   • メンバーはレビューを編集することができ、履歴は維持されますが、特定のアイテムについてメンバーごとに 1 つのレビューしかありません。
   • BandMembers は、関連付けられているバンドに関するレビューに 1 つのコメントを書く機会があります。バンド全体として、1 つのレビューにつき 1 つのコメントのみが許可されます。
   • その後、メンバーはすべてのレビューとコメントを評価できますが、特定のインスタンスごとに 1 回のみです。
4. メンバーは、お気に入りのバンド、音楽、商品、イベントを選択できます
5. バンド、曲、およびイベントは、ジャンルのタイプに分類され、必要に応じてサブジャンルにさらに分類されます。バンドまたはイベントが複数のジャンル/サブジャンルの組み合わせに分類されることは問題ありません。
6. 特定のバンドのイベントの日付、時間、場所が掲載され、メンバーはイベントに参加することを示すことができます。イベントは複数のバンドで構成することができ、同じ日に 1 つの場所で複数のイベントを開催することができます。
7. すべての当事者は少なくとも 1 つのアドレスに結び付けられ、アドレス履歴が保持されます。各当事者は、一度に複数の住所に関連付けることもできます (つまり、請求、配送、物理)。
8. Bands、BandMembers、一般メンバーのプロフィールが保存されます。

少し複雑かもしれませんが、プロセスが進化し、コミュニティからの情報が提供されるにつれて、うまくいけば多くの人にとって素晴らしい学習ツールになる可能性があります. 入力はありますか？

EDIT v1.1 PerformanceDBA への対応

U.3) これは、データベースにバンドの商品以外の商品がないことを意味します。正しい ？ それが私の最初の考えでしたが、あなたは私に考えさせました。おそらく、サイトは独自の商品やバンドの他の商品を販売したいと考えているでしょう。そのために作るmodがわからない。カタログ セクション全体の作り直しが必要ですか、それともバンドとの識別関係のみが必要ですか? 完全なアルバムまたは曲の両方を販売するための mod を試みました。いずれにせよ、どちらもダウンロードのみが可能な電子形式になります。そのため、アルバムは 2 つの個別のエンティティではなく、曲で構成されていると記載しました。

U.5) Favorite との循環関係について、あなたが何を提起しているかは理解できます。「その処理を識別するのは、何らかの形式の差別化 (FavoriteType) を備えた 1 つのエンティティのいずれかである」ということを知りたいのですが、その方法が明確ではありません。ここで何が欠けていますか？

u.6)「ビジネス ルール これはおそらくあなたが苦手な唯一の領域です。」<br> 正直な回答をありがとう。私はこれらに再度対処しますが、最初に私があなたに返信した回答で頭の中の混乱を解消したいと思っています.

Q.1)はい、承認済み、拒否済み、ブロック済みを希望します。これが論理モデルをどのように変更するかについて、あなたが何を指しているのかわかりませんか?

Q.2)ユーザーである必要はありません。BandMember としてのみ存在できます。それはあなたが求めているものですか？

軽微な問題

0、1、またはそれ以上… モデルを作成するときに、この点に注意するのを忘れていたことを認めます。このバージョンをそのまま提出し、将来のバージョンで対処します。物事を理解していることを確認するために、制約チェックについてもっと読む必要があります。

M.4)将来の OrderPurchase を想定しているかどうかによって異なります。ここでの意味を拡張できますか？

EDIT V1.2 PerformanceDBA の入力に応じて...

学んだ教訓。

1. 私は、識別/非識別とカーディナリティ (つまり、ジャンル/サブジャンル) の概念を混ぜ合わせており、一貫性を欠いて物事を悪化させていました。
2. 多対多の関係を描写してから物理モデルで展開できるため、論理ダイアグラムでは連想テーブルは必要ありません。
3. 私は多くの関係でカーディナリティを見落としていました
4. 効果的な動詞句を使用して関係を読み、達成したいことをモデル化していることを確認することの重要性.

U.2) このモデルの概念では、イベントの場所として会場を追跡することだけが必要です。それ以上のデータを収集する必要はありません。そうは言っても、イベントは特定の EventDate で開催され、会場で開催されます。会場では、特定の日に複数のイベントが開催され、場合によっては複数のイベントが開催されます。私の新しいモデルでは、 EventDate はすでに Event に関連付けられていると考えていました。したがって、Venue は EventDate との関係を必要としません。U.2) の下にリストされている 5 番目と 6 番目の箇条書きは、私の考えに疑問を投げかけています。ここで何か不足していますか？

U.3)アイテムとバンドの間のリンクをアイテムとパーティに移動する時が来ましたか? 現在のデザインでは、ご指摘のバンドに関係のない商品を販売する可能性はないと思います。

U.5)私は、個別のスーパータイプ/サブタイプの関係にするのではなく、あなたの入力に従って残しました。

追加の改訂

AR.1) FavoriteItem の演習を行った後、Item to Review には多対多の関係が必要であると感じたため、それが示されています。必要？

では、v1.3 に進みます

このバージョンでは、デザインを行ったり来たりして数日かかりました。論理的なプロセスが完了したら、正しい軌道に乗っているかどうかを確認したいので、学んだことと、このプロセスを経る初心者として直面した問題を深く掘り下げます。このバージョンの大きなポイントは、過去に欠けていたものを確認するためにいくつかのキーを投入する必要があったことです. マトリックスを実行するプロセスを経ることも、大きな助けになることがわかりました。いずれにせよ、PerformanceDBA からの情報提供がなければ、私は暗闇の中で迷子になっていたでしょう。私の現在のデザインは、私がまだそうであることを再確認するかもしれませんが、私は多くのことを学んだので、少なくとも懐中電灯を手に持っていることを知っています.

現時点では、識別関係と非識別関係についてまだ混乱していることを認めます。私のモデルでは、モデル化したい関係を結合するためだけに、null 以外の非識別関係を使用する必要がありました。この主題について多くのことを読んでいると、この主題について多くの意見の相違と優柔不断があるように思われるので、私は自分のモデルで正しいことを表していると思うことをしました。いつ強制するか (識別)、いつ解放するか (非識別)? 誰でも入力がありますか？

編集 V1.4

わかりました、V1.3 の入力を取り、この V1.4 用にクリーンアップしました

現在、属性を含めるために V1.5 に取り組んでいます。

編集 V1.6

さて、ここに投稿してからしばらく経ちましたが、このプロジェクトの作業はまだ進行中です。V1.4 の前回の投稿から多くの変更を含む V1.6 を投稿しています。このバージョンは、キーのさらなる進化を示しています。属性や AK や IE はまだ含まれていません。私は物理モデルの作業を開始し、それを使用して属性の作業を支援し、AK と IE の定義に関する問題に光を当てようとしました。論理モデルの次の投稿には、これらのキーと属性が含まれます。

私はこれを正しく行っているかどうかわからない奇妙なデータベース設計の問題を抱えています。私の現在の設計は非常に複雑なので、次の図では、家と居住者（実際のエンティティではない）を使用して比較して簡略化しています。

したがって、データベース設計のどの部分がどのように見えるかを次に示します。

標準状態：

• 複数の家
• 家ごとに複数のフロア
• フロアごとに複数のベッドルーム

それほど標準的ではない条件：

• 各居住者は複数の家に住むことができます
• 各居住者は、家ごとに複数の寝室を持つことができます
• 各居住者は、1つの家につき1つのフロアに1つのベッドルームしか持てません（これは注意が必要な部分です）。たとえば、1階に1つのベッドルーム、2階に1つのベッドルーム、3階に1つのベッドルームを持てますが、同じ場所に2つのベッドルームを持てることはできません。床

したがって、私が達成しようとしているのはこれです。アプリのデザインでは、私は知っていますhouse、私は知っています、floorそして私は知っていoccupantます。ユーザーが指定せずにこの情報で知る必要があるbedroomのoccupantは、これら3つの基準に基づいたものです。2つの解決策があります。1つ目は、occupants_has_bedroomsテーブルで主キーを、、occupants_idおよびbedrooms_floors_idにすることbedrooms_floors_houses_idです。ただし、bedrooms_id主キーを削除すると、テーブルは親との識別関係ではなくなります（bedrooms）。親なしでは存在できなかったので、それは識別関係です。したがって、4つのIDすべてを主キーとして保持する必要があるとのことです。私の2番目のオプションは、これら3つの値の間の一意のインデックスですが、これは、私がこれに間違ってアプローチしている可能性があると考えたときです。

どうすればこれを達成できますか？

データベース管理者向けに StackExchange に最初にこの質問を投稿しました: https://dba.stackexchange.com/questions/28356/should-this-be-an-identifying-relationship-or-not

しかし、私が推測するユーザーが不足しているようです。誰でもこれで私を助けることができますか？

編集: わかりました、私は非識別関係を持つことを選択しました。このようにして、ユーザーは患者、SpiProfessional、またはその両方になることができます。クエリを作成するときの作業は増えますが、うまくいくようです。皆さんの回答に感謝します。データベースの理解に貢献してくれました。

次の InvalidOperationException が発生します。

データベースへの変更は正常にコミットされましたが、オブジェクト コンテキストの更新中にエラーが発生しました。ObjectContext が矛盾した状態にある可能性があります。内部例外メッセージ: 参照整合性制約違反が発生しました: 参照制約を定義するプロパティ値が、リレーションシップ内のプリンシパル オブジェクトと依存オブジェクトの間で一貫していません。

これは、次のコードを実行すると発生します (ShipDates コレクションで Clear() を呼び出し、新しいインスタンスを追加する場所に注意してください)。

以下は、識別関係に関与する 2 つのクラスの関連部分です。

と：

変更中の既存の OrderPage がある場合、SaveChanges() でエラーが発生します。OrderPage で、ShipDates コレクション内の既存のすべての OrderPageShipDates を削除し、新しいインスタンスに追加し直す必要があります。

これを理解するのを手伝ってもらえますか? 前もって感謝します。

ああ、以下の応答について - GetOrder() 呼び出しで出荷日を明示的に読み込んでいます。そのコードは次のとおりです。

私には今直面している大きな課題があります。親の主キーと組み合わせた主キーを持つ弱いエンティティ「AFFILIATE」を持つ強力なエンティティ「クライアント」がある場合、データベースを設計しています。 "関係と総参加を持っています。しかし、私の問題は、SQL では、AFFILIATE の主キーをその識別子と親の主キーによって定義する必要があるため、1 対多の関係が非効率になることです。多くのid_client。私を助けてください。

product(id, name)モデル番号が異なる複数の製品グループを含む表があります。すなわち、{motor10、motor20、motor30、pipe10、pipe20、pipe30、wrench12、wrench20 など}。

product category{motor, pipe, wrench, uncategorized} などのカテゴリのみを含む、という名前の新しいテーブルを作成することにしました。

質問

アプリケーションの実用的な目的で (ER 図のモデル化などの理論的な目的ではなく)、識別関係または非識別関係を使用する必要がありますか?

私のユースケース 私の場合、製品がカテゴリなしでは存在できないように定義できます。ただし、製品がまだ分類されていない場合は、uncategorizedカテゴリに価値があります。カテゴリには、まだ製品が割り当てられていないエントリを含めることができます。

カテゴリは、私が実際に使用する必要のない架空の概念ですが、現在持っている一連の製品を分類するのに役立ちます. これはでっち上げのコンセプトであり、どのように使用したいのかわからないため、この問題に苦労していると思います。別名..テーブルを用意する必要はまったくありませんがproduct_category、さまざまな製品のグループ分けに役立つことは間違いありません。

これを識別関係にするには、一部のコードを修正して書き直す必要があります。多くのコードを書く前に、これを識別関係にしたいことを確認したかったのです。

...とはいえ、これを識別関係にしない場合はありますか?