弱肉強食について、Googleで調べてみたのですが、いまいちよくわかりませんでした。
どなたか、強いエンティティタイプと弱いエンティティタイプの例を教えていただけませんか?
弱いエンティティは、独自の属性では完全に識別できないエンティティであり、_foreign key_を属性として(通常、関連するエンティティの主キーを取ります)組み合わせて受け取ります。
例。
部屋の存在は、ホテルの存在に完全に依存しています。 したがって、部屋はホテルの_弱い実体_と見なすことができます。 別の例はです。 銀行が存在しない場合、特定の銀行の銀行口座は存在しません。
他のエンティティなしで存在できます。
例。
Customer(customerid, name, surname)
それは支配的な実体に依存し、強い実体なしでは存在できません。
例。
Adress(addressid, adressName, customerid)
。/ Database / DataModels / RelationalDataModel / WeakEntity 。
それはおそらく2つの要因で書くことができます:
-依存関係:識別エンティティセットの存在に依存します(合計、1対多の関係)。 -識別:主キーがありません。 部分的なキー(または識別子)があります。 識別には、別のテーブルの主キーを使用する必要があります。
質問と回答を保持するデータベースを考えると、質問は強力なエンティティであり、回答は弱いエンティティになります。 したがって、質問(id、テキスト)および回答(数値、question_id、テキスト)がテーブルになります。 しかし、なぜ回答の表は弱い実体なのか?
-質問表への依存。すべての回答は1つの質問(仮定)に関連しているため、それ自体ではできません。 そのため、私たちは1つの質問をして自分で答える人々がいて、他の人々を助け、特別な好みを得ることができます。
-質問の主キーからの識別。 他の質問にも識別子が存在する可能性のある回答によって質問に回答する可能性があるため、回答を特定することはできません(IDが数値識別子であると仮定)。 回答表の主キー:(数値、question_id)。
マルチバリューの属性問題を解決するために弱いエンティティが存在します。
マルチバリュー属性には2つのタイプがあります。 1つは、学生の属性としての「趣味」などのオブジェクトの単純に多くの値です。 学生は多くの異なる趣味を持つことができます。 趣味を学生エンティティセットに残すと、「趣味」はもはやユニークではなくなります。 趣味として別のエンティティセットを作成します。 次に、必要に応じて趣味と生徒をリンクします。 趣味のエンティティセットは、連想エンティティセットになりました。 弱いかどうかについては、各エンティティがそれを識別するのに十分な一意の識別子を持っているかどうかを確認する必要があります。 多くの意見では、趣味の名前はそれを識別するのに十分である可能性があります。
他のタイプのマルチバリュー属性問題は、それを修正するために弱いエンティティを必要とします。 食料品の在庫システムに設定された品目エンティティとしましょう。 アイテムはカテゴリアイテムですか、それとも実際のアイテムですか? 顧客は一度に同じアイテムを一定の量で購入できますが、同じアイテムを別の時間に別の量で購入することもできるため、これは重要な質問です。 同じアイテムですが、オブジェクトが異なります。 アイテムは現在、マルチバリューの属性です。 まず、カテゴリーアイテムを実際のアイテムと分けて解決します。 2つは異なるエンティティセットになりました。 カテゴリーアイテムには、通常考えるアイテムと同じように、アイテムの説明的な属性があります。 冗長な問題が発生しないため、実際のアイテムには説明的な属性がなくなります。 実際のアイテムは、アイテムの日付と金額のみを持つことができます。 必要に応じてリンクできます。 次に、一方が他方のかつての弱いエンティティであるかどうかについて話しましょう。 記述的属性は、カテゴリー項目エンティティセット内の各エンティティを識別するのに十分以上です。 実際のアイテムには日付と金額しかありません。 レコード内のすべての属性を削除しても、エンティティを特定することはできません。 それは時間と量だけだと思います。 実際の項目エンティティセットは弱いエンティティセットです。 カテゴリーアイテムエンティティセットからの重複するプライムキーを使用して、セット内の各エンティティを識別します。
検索エンジンを数時間閲覧した後、ここに優れたERDの例があるサイトを見つけました:http://www.exploredatabase.com/2016/07/description-about-weak-entity-sets-in-DBMS.html 。
ERDを再現しました。残念ながら、彼らは弱いエンティティの主要なキーを指定しませんでした。
。。
建物に1つだけのアパートしかない場合、部分的な差別者の部屋番号は作成されないようです(つまり、. 破棄)。
弱いエンティティタイプ: 他のエンティティのインスタンスにリンクされずにインスタンスが出られないエンティティは、弱いエンティティタイプと呼ばれます。 独立して存在することはできません。 例:私たちのPCは私たちに依存しており、PCはそれ自体で開閉しません。
強力なエンティティタイプ: 他のエンティティタイプのインスタンスにリンクされているエンティティは、強力なエンティティタイプと呼ばれます。 独立して終了できます。 例:人はあらゆることを行うことができ、どこにでも行くことができ、あらゆるものを使うことができます。
First Strong / Weak ReferenceタイプがARCに導入されています。非ARCでは、割り当て/保持が使用されています。 強力な参照とは、参照しているオブジェクトをこのプロパティ/変数で「所有」することを意味します。 コンパイラーは、このプロパティに割り当てたオブジェクトが、強い参照でポイントしている限り破棄されないように注意します。 プロパティをnilに設定すると、オブジェクトが破壊されます。
弱い参照とは、オブジェクトの寿命を制御したくない、またはオブジェクトを「所有」したくないことを示すことを意味します。 少なくとも1つの他のオブジェクトが強く参照しているため、参照しているオブジェクトは弱くしか存続しません。 それがもはや当てはまらないと、オブジェクトは破棄され、弱いプロパティは自動的にnilに設定されます。 iOSで弱い参照の最も頻繁な使用例は、IBOutlets、デリゲートなどです。
詳細については、http://www.informit.com/articles/article.aspxを参照してください?p = 1856389& seqNum = 5。