強いエンティティタイプと弱いエンティティタイプの例
weakおよびstrong entity typeのきちんとした説明についてGoogleで調べてみましたが、完全には理解していません。
強いエンティティタイプと弱いエンティティタイプの例を教えてもらえますか？
弱いエンティティとは、別のエンティティが所有している場合にのみ存在できるエンティティです。例：ROOMは、BUILDINGにのみ存在できます。一方、タイヤは、CARにアタッチせずに存在できるため、強力なエンティティと見なされる場合があります。
試してみると、質問はエンティティタイプが強く、答えは弱いです。質問は常にそこにありますが、答えには質問が存在する必要があります。
会社の保険契約は従業員と扶養家族に保険をかけます。被雇用者は従業員なしでは存在できません。つまり、従業員の扶養家族である場合を除き、扶養家族として保険に加入することはできません。
weak entityは、独自の属性では完全に識別できないエンティティであり、属性としてforeign keyを取ります（通常、関連するエンティティの主キーを取得します）。
例
部屋の存在は、ホテルの存在に完全に依存しています。そのため、部屋はホテルの弱体として見ることができます。
別の例は
銀行がもう存在しない場合、特定の銀行の銀行口座は存在しません。
強い存在
他のエンティティなしで存在できます。
例
Customer(customerid, name, surname)
弱いエンティティ
それは支配的なエンティティに依存し、強力なエンティティなしでは存在できません。
例
Adress(addressid, adressName, customerid)
弱いエンティティは、存在が他のエンティティに依存するため、依存エンティティとも呼ばれます。このようなエンティティは、E-Rダイアグラムで二重の輪郭の長方形で表されます。
強力なエンティティは、独立したエンティティとも呼ばれます。
./ Database/DataModels/RelationalDataModel/WeakEntity
おそらく、次の2つの要因で記述できます。
- DEPENDENCE：識別エンティティセットの存在に依存します（合計、1対多の関係）。
- IDENTIFICATION：主キーはありません。部分キー（またはディスクリミネーター）があります。識別には別のテーブルの主キーを使用する必要があります。
質問と回答を保持するデータベースを考えると、質問は強い存在になり、回答は弱い存在になります。したがって、Question（id、text）およびAnswer（number 、question_id、text）がテーブルになります。しかし、なぜアンサーの表は弱い実体なのでしょうか？
質問表への依存性。すべての回答は1つの質問（仮定）に関連付けられているため、単独で回答することはできません。そのため、1つの質問をして自分で答える人がいるので、他の人を助けたり、好みが増えたりします。
質問の主キーからの識別。質問は、他の質問にも識別子が存在する可能性のある回答によって回答される可能性があるため、回答を特定することはできません（そのidが番号識別子であると仮定します）。回答テーブルの主キー：（number、question_id）。
多値属性の問題を解決するために、弱いエンティティが存在します。
多値属性には2つのタイプがあります。 1つは、学生の属性としての「趣味」などのオブジェクトの単純に多くの値です。生徒はさまざまな趣味を持つことができます。学生のエンティティセットに趣味を残すと、「趣味」はもはや一意ではなくなります。趣味として別のエンティティセットを作成します。次に、趣味と生徒を必要に応じてリンクします。趣味のエンティティセットは、関連エンティティセットになりました。弱いかどうかについては、各エンティティがそれを識別するのに十分な一意の識別子を持っているかどうかを確認する必要があります。多くの意見では、趣味の名前はそれを識別するのに十分な場合があります。
他のタイプの複数値属性の問題には、それを修正するための弱いエンティティが必要です。食料品在庫システムに設定されたアイテムエンティティを考えてみましょう。アイテムはカテゴリアイテムですか、それとも実際のアイテムですか？顧客は同じ商品を一度に一定の金額で購入できますが、同じ商品を別の時間に別の金額で購入することもできるため、これは重要な質問です。同じアイテムですが、異なるオブジェクトのものを見ることができます。アイテムは複数値の属性になりました。最初にカテゴリアイテムを実際のアイテムと分離することで解決します。 2つは現在、異なるエンティティセットです。カテゴリアイテムには、通常考えているアイテムと同様に、アイテムの説明的な属性があります。冗長な問題を抱えることができないので、実際のアイテムは説明的な属性を持つことができません。実際のアイテムは、日付とアイテムの量のみを持つことができます。必要に応じてリンクできます。次に、一方が他方の弱いエンティティであるかどうかについて話しましょう。記述属性は、カテゴリアイテムエンティティセットの各エンティティを識別するのに十分すぎます。実際のアイテムには日時と金額のみがあります。レコード内のすべての属性を引き出しても、エンティティを識別することはできません。ちょうど時間と量だと考えてください。実際のアイテムエンティティセットは、弱いエンティティセットです。カテゴリアイテムエンティティセットから重複するプライムキーを使用して、セット内の各エンティティを識別します。
検索エンジンを数時間閲覧した後、ここに素晴らしいERDの例があるサイトに出会いました： http://www.exploredatabase.com/2016/07/description-about-weak-entity-sets-in- DBMS.html
ERDを再作成しました。残念ながら、彼らは弱いエンティティの主キーを指定しませんでした。
建物に1つだけのアパートメントを含めることができる場合、部分的な識別者の部屋番号は作成されないようです（つまり、破棄されます）。