これはバードウォッチャのデータベースの例です。 3つのエンティティ（BirdSpecies、Location、Observer）があるとします。エンティティObservationを使用するには、これら3つのすべてが必要です。それらがなければ何の観察もない。ユニークな番号IDを持つ弱いエンティティ
上記の要件によって、弱いエンティティObservationが作成されていると私は理解しています。しかし、同じ人が同じ場所に何度も同じ種を見つけることができたらどうでしょうか？次に、エントリは一意ではありません。
私の質問では、Observationのプライマリキーは各観測ごとに順番に増えていて、エンティティはまだ弱いエンティティです。
私は、新しいエンティティの弱点はその関係によって調整されていると考えています。今はその主キーがどのようなものかと思います。
これを理解するには、順番に増加する数字の代わりに、各観測に固有の日時があるとします。これは、3つのエンティティのうちの1つを削除しても観察がないという事実は変わりません。
弱いエンティティは、単一の親エンティティの主キーと別の属性によって識別されます。弱いエンティティは、通常、全体の一部です。 Observation（サロゲートキーを導入しない）は弱いエンティティではなく、3者関係です。
同じ種の同一人物が同じ場所に複数の観測を記録するには、Observationのリレーションとプライマリキーに日付/時刻値を含めるか、または非プライムカウント列を使用して観察。リレーションには重複したエントリが存在しないことを覚えておいてください。したがって、区別する列がなくても一意ではなく、複数のエントリを記録することができます。しかし、SQL DBMSは適切なリレーショナルではなく、足で自分自身を撃つことができます。
代理キーを導入すると、その関係を結合エンティティに変換します。サロゲートキーで識別されるエンティティは、常に独自の属性で識別されるため、強いエンティティです。サロゲートキーを使用すると、重複するエントリを記録することができます。サロゲートキーは、他の属性のユニークキーで補完されることがよくあります。
弱いエンティティは、その関係によって定義されるのではなく、そのエンティティの親エンティティのキーに依存することによって定義されます。 https://en.wikipedia.org/wiki/Weak_entityを参照してください。または、Peter Chenの「エンティティリレーションシップモデル - データの統一された見方」を読んでください。 – reaanb