人とユーザーの間に1対1（1：1）の関係を実装する
シナリオの説明
このpersonテーブルをスーパー親（またはスーパータイプ）として持っています。
id
firstname
lastname
email
telephone
...
...
および子（またはサブタイプ）としてのuserテーブル
id
person_id (FK)
password
username
screenname
...
...
userを2回繰り返すことはできないため、これらは1対1（1：1）の関係にある必要があります。したがって、特定のperson行の特定のemail値は2回繰り返した。
次に、誰からのメッセージを格納するこのmessageテーブルがあります。
id
firstname
lastname
email
telephone
subject
content
...
...
しかし、firstname、lastname、email、telephoneはmessageテーブルで重複であることがわかります。
だから、私はそれを以下のようなpersonテーブルに参照することを考えています、
id
person_id
subject
content
...
しかし、同じメールを持つpersonとして、それは正しくないようです。 ）、nameなどはメッセージを私にいくつでも送信できます彼らが望むように何度も、彼/彼女が提供する詳細を繰り返すことができます。
質問
それで、
messageをpersonの子として親にする必要がありますか、それとも別々のエンティティにする必要がありますか？または、この問題を解決するためのより良い提案はありますか？
personテーブルがあります。
罰金（PK列の名前を変更しただけ）：
person
------
person_id PK
firstname
lastname
email
telephone
...
...
子としてのユーザーテーブル。ユーザーを2回繰り返すことはできないため、これらは1：1の関係である必要があります。
関係が1：1の場合（personがスーパータイプで、userがサブタイプであると仮定すると、person：
user
----
person_id PK FK to person(person_id)
password
username
screenname
...
...
したがって、person行の電子メールを2回繰り返さないでください。
person.email列にUNIQUE制約を追加します。
次に、誰からのメッセージも格納するこのメッセージテーブルがありますが、名、姓、電子メール、電話がメッセージテーブルに重複していることがわかります。なので、以下のような人物表を参考にしようと思っています。
細かい（以前の変更に合わせて調整）。ただし、誰がメッセージを送信し、誰が受信者であるかも保存する必要があります。
message
-------
message_id PK
sender_id FK to user(person_id) --- or to person(person_id)
receiver_id FK to user(person_id) --- that depends on your requirements
subject
content
...