web-dev-qa-db-ja.com

人とユーザーの間に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
...
...

しかし、firstnamelastnameemailtelephonemessageテーブルで重複であることがわかります。

だから、私はそれを以下のようなpersonテーブルに参照することを考えています、

id
person_id
subject
content
...

しかし、同じメールを持つpersonとして、それは正しくないようです。 )、nameなどはメッセージを私にいくつでも送信できます彼らが望むように何度も、彼/彼女が提供する詳細を繰り返すことができます。

質問

  • それで、messagepersonの子として親にする必要がありますか、それとも別々のエンティティにする必要がありますか?

  • または、この問題を解決するためのより良い提案はありますか?

3
laukok

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
...
4
ypercubeᵀᴹ