関係データベースで識別関係と非識別関係の違い/説明を求めることに関して、いくつかの質問があります。
私の質問は、これらの専門用語のより簡単な用語を考えてもらえますか? ただし、技術用語は具体的で明確でなければならないことは理解しています。しかし、「別の名前」を付けることで、学生は背後にある概念により簡単に関連付けることができます。
実際には、コンピューター サイエンスのバックグラウンドがあまりない初めてのユーザーがより速く学習できるように、独自のデータベース モデリング ツールでより一般的な用語を使用したいと考えています。
乾杯！
子テーブルや従属テーブルが一般用語として使われているのをよく見かけます。識別関係を持つテーブルには、これらの用語のいずれかを使用できます
次に、参照テーブルが非識別関係を持つテーブルであるとします。
たとえば、PhoneNumbersは の子ですUsers。これは、電話番号がそのユーザーとの識別関係を持っているためです (つまり、 の主キーにPhoneNumbersは の主キーへの外部キーが含まれていますUsers)。
テーブルにはテーブルへの外部キーでUsersある列があるため、非識別関係になります。したがって、 referencesと言うことができますが、それ自体の子ではありません。stateStatesUsers States
属しているというのは、識別関係に適した名前だと思います。
「弱いエンティティ タイプ」は独自のキーを持たず、「部分キー」のみであるため、この弱いエンティティ タイプの各エンティティ インスタンスは、識別できるように他のエンティティ インスタンスに属している必要があります。これが「識別関係」です。 "。たとえば、大家はアパートと部屋のデータベースを持つことができます。部屋はkitchenまたはbathroomと呼ばれることがあり、その名前はアパート内で一意ですが、データベースにはkitchenという名前の部屋が多数あるため、これは単なる部分的なキーです。データベース内の部屋を一意に識別するには、この特定のアパートのキッチンであると言う必要があります。つまり部屋はマンション所属。
ER モデリングの「弱いエンティティ」という用語をお勧めします。
一部のモデラーは、主題をエンティティーおよびエンティティー間の関係で構成されていると概念化しています。これにより、エンティティ関係モデリング (ER モデリング) が生まれます。属性はエンティティまたは関係に関連付けることができ、データベースに格納される値は属性のインスタンスです。
ER モデリングを行う場合、「弱いエンティティ」と呼ばれるエンティティの一種があります。弱いエンティティのアイデンティティの一部は、弱いエンティティが属するより強いエンティティのアイデンティティです。
例として、注文処理システムでの注文が考えられます。注文は項目で構成され、各項目には製品 ID、単価、および数量が含まれます。ただし、すべての注文で品目に識別番号があるわけではありません。代わりに、品目は {品目番号、注文番号} で識別されます。つまり、正確に 1 つの注文の一部でない限り、品目は存在できません。項目番号 1 は、それが属している順序に関係なく最初の項目ですが、項目を識別するには両方の番号が必要です。
ER モデルをリレーショナル モデルに変換するのは簡単です。また、データの専門家であってもデータベースについて何も知らない人でも、理解しているデータの ER モデルに慣れるのは簡単です。
ER モデリングの必要性に激しく反対するモデラーは他にもいます。私はその一人ではありません。
「関係」（ER、私は推測する）などに遭遇するようなモデリングには、「技術的」、「正確」、または「明確」なものは何もありません。それもありえません。
A) ER モデリングは、データベースの定義全体を把握/表現するのに十分ではないため、常に必然的に非公式です。
B) 非常に多くの異なる ER 方言が存在するため、それらすべてがまったく同じ用語をまったく同じ意味で使用することは不可能です。最近、ER モデリングを教えている英国の大学で、私がいつも「エンティティ スーパータイプ」と呼んでいたのとまったく同じものに「エンティティ サブタイプ」という用語を使用していることがわかりました。
どうですか
を使用できますconnection。
IDが同じである2つのテーブル間に接続があります。
そのタイプのこと。