database - 強いエンティティタイプと弱いエンティティタイプの例

Question

弱いエンティティタイプと強いエンティティタイプの適切な説明についてGoogleを調べようとしましたが、完全には理解していません。

誰かが私に強いエンティティタイプと弱いエンティティタイプの例を教えてもらえますか？

Answer 1

弱いエンティティとは、別のエンティティが所有している場合にのみ存在できるエンティティです。例：ROOMはBUILDINGにのみ存在できます。一方、TIREは、 CARに接続しなくても存在できるため、強力なエンティティと見なされる場合があります。

Answer 2

ただそれで遊ぶために、質問は強いエンティティタイプであり、答えは弱いです。質問は常にありますが、答えには質問が存在する必要があります。

例：「なぜ？」と聞かないでください。あなたのお父さんが化学の教授なら

Answer 3

弱いエンティティとは、それ自体の属性では完全に識別できないエンティティであり、外部キーを属性として使用します（通常、関連するエンティティの主キーを使用します）。

例

部屋の存在はホテルの存在に完全に依存しています。したがって、部屋はホテルの弱い存在と見なすことができます。
もう1つの例は
、特定の銀行の銀行口座が存在しない場合、その銀行は存在しません。

Answer 4

会社の保険契約は従業員と扶養家族に保険をかけます。DEPENDENTは従業員なしでは存在できません。つまり、従業員の扶養家族でない限り、扶養家族として保険に加入することはできません。DEPENDENTは、「EMPLOYEEhasDEPENDENT」という関係の弱いエンティティです。

Answer 5

強い実体

他のエンティティがなくても存在できます。

例

Customer(customerid, name, surname)

弱実体

それは支配的な実体に依存し、強い実体なしでは存在できません。

例

Adress(addressid, adressName, customerid)

Answer 6

複数値属性の問題を解決するために弱いエンティティが存在します。

複数値属性には2つのタイプがあります。1つは、学生の属性としての「趣味」などのオブジェクトの単純に多くの値です。学生は多くの異なる趣味を持つことができます。趣味を学生エンティティセットに残すと、「趣味」はもはやユニークではなくなります。趣味として設定された別のエンティティを作成します。次に、必要に応じて趣味と生徒をリンクします。ホビーエンティティセットは、連想エンティティセットになりました。弱いかどうかについては、各エンティティがそれを識別するのに十分な一意の識別子を持っているかどうかを確認する必要があります。多くの意見では、趣味の名前はそれを識別するのに十分である可能性があります。

他のタイプの複数値属性の問題は、それを修正するために弱いエンティティを必要とします。食料品在庫システムに設定されたアイテムエンティティを考えてみましょう。アイテムはカテゴリアイテムですか、それとも実際のアイテムですか？顧客は同じ商品を一度に一定の金額で購入できますが、同じ商品を別の時間に別の金額で購入することもできるため、これは重要な質問です。同じアイテムですが、オブジェクトが異なります。アイテムは複数値の属性になりました。まず、カテゴリアイテムと実際のアイテムを分離することで解決します。2つは異なるエンティティセットになりました。カテゴリアイテムには、通常考えているアイテムと同じように、アイテムの説明的な属性があります。冗長な問題が発生する可能性がないため、実際のアイテムに説明的な属性を設定することはできなくなります。実際のアイテムには、日時とアイテムの金額のみを含めることができます。必要に応じてリンクできます。それでは、一方が他方の弱実体であるかどうかについて話しましょう。記述属性は、カテゴリアイテムエンティティセット内の各エンティティを識別するのに十分すぎるほどです。実際のアイテムには、日時と金額のみが含まれます。レコード内のすべての属性を引き出しても、エンティティを識別できません。それは時間と量だけだと考えてください。実際のアイテムエンティティセットは、弱いエンティティセットです。カテゴリアイテムエンティティセットからの複製プライムキーを使用して、セット内の各エンティティを識別します。まだエンティティを識別できません。それは時間と量だけだと考えてください。実際のアイテムエンティティセットは、弱いエンティティセットです。カテゴリアイテムエンティティセットからの複製プライムキーを使用して、セット内の各エンティティを識別します。まだエンティティを識別できません。それは時間と量だけだと考えてください。実際のアイテムエンティティセットは、弱いエンティティセットです。カテゴリアイテムエンティティセットからの複製プライムキーを使用して、セット内の各エンティティを識別します。

Answer 7

./Database/DataModels/RelationalDataModel/WeakEntity

それはおそらく2つの要因で書くことができます：

• 依存関係：識別エンティティセットの存在に依存します（合計、1対多の関係）。
• 識別：主キーがありません。部分的なキー（またはディスクリミネーター）があります。識別には別のテーブルの主キーを使用する必要があります。

質問と回答を保持するデータベースについて考えると、質問は強いエンティティになり、回答は弱いエンティティになります。したがって、Question（id、text）とAnswer（number、question_id、text）がテーブルになります。しかし、なぜAnswerのテーブルは弱いエンティティなのですか？

• 質問テーブルへの依存。すべての回答は1つの質問（仮定）に関連しているため、それだけで回答することはできません。そのため、他の人を助けたり、好みを追加したりできるように、1つの質問をして自分で答える人がいます。

• 質問の主キーからの識別。質問は、他の質問にも識別子が存在する可能性のある回答によって回答される可能性があるため、回答を特定することはできません（そのIDが番号識別子であると想定）。回答テーブルの主キー:(番号、question_id）。

Answer 8

弱いエンティティは、その存在が他のエンティティに依存するため、依存エンティティとも呼ばれます。このようなエンティティは、ER図では二重の輪郭の長方形で表されます。

強力なエンティティは、独立したエンティティとも呼ばれます。

Answer 9

検索エンジンを数時間閲覧した後、ここに素晴らしいERDの例があるサイトに出くわしました：http：//www.exploredatabase.com/2016/07/description-about-weak-entity-sets-in-DBMS.html

ERDを再作成しました。残念ながら、彼らは弱い実体の主キーを指定しませんでした。

建物にアパートが1つしかない場合、部分識別室番号は作成されない（つまり破棄される）ようです。

Answer 10

弱いエンティティタイプ：他のエンティティのインスタンスにリンクされていないとインスタンスが終了できないエンティティは、弱いエンティティタイプと呼ばれます。独立して存在することはできません。例：私たちのPCは私たちに依存しており、それ自体で開閉することはありません。

強力なエンティティタイプ：他のエンティティタイプのインスタンスにリンクされているエンティティは、強力なエンティティタイプと呼ばれます。独立して終了できます。例：人はあらゆることを行うことができ、どこにでも行き、あらゆることを使うことができます

Answer 11

別のデータオブジェクトの存在に依存せずに存在できるデータオブジェクトは、ストロングデータオブジェクトと呼ばれます。

Answer 12

最初の強/弱参照タイプがARCに導入されました。非ARCでは、割り当て/保持が使用されています。強力な参照とは、このプロパティ/変数で参照しているオブジェクトを「所有」することを意味します。コンパイラは、このプロパティに割り当てたオブジェクトが、強力な参照でポイントしている限り、破棄されないように注意します。プロパティをnilに設定すると、オブジェクトは破棄されます。

弱参照とは、オブジェクトの存続期間を制御したくない、またはオブジェクトを「所有」したくないことを意味します。弱く参照しているオブジェクトは、少なくとも1つの他のオブジェクトがそのオブジェクトへの強い参照を保持しているため、存続するだけです。それが当てはまらなくなると、オブジェクトは破棄され、weakプロパティは自動的にnilに設定されます。iOSでの弱参照の最も頻繁な使用例は、IBOutlets、Delegatesなどです。

詳細については、以下を参照してください：http: //www.informit.com/articles/article.aspx?p= 1856389&seqNum=5