RDBMSがよく分からなくなってきました

Question

以上のようなテーブルがあったとします。
draw.ioで作った簡易的なテーブルではあるのですが、このt_accountというテーブルにあるDetailIdという属性はt_Detailというテーブルの主キーに紐付いていてこのテーブルは、Height(身長)、Weight(体重)という属性を持っているとします。
この時t_accountとt_Detailの関係性は1対1なのでしょうかそれとも1対多にあたるのでしょうか？
最初はDetailIdは複数のt_detailの属性と紐付けられるから1対多と思っていたのですが、よくよく考えたらこのt_Accountつまりアカウントを持っている人の身長、体重は複数を持てないので1対1なのではないかと感じました。更に考えるとt_accountにHeightとWeight属性を持たせることはできますし。。。

個人的にこの関係性は1対1のリレーションであるとは思うのですが、それを踏まえてわざわざテーブルを2つ作り1対1のリレーションにする理由って何なのでしょうか？1つのテーブルがごちゃごちゃしなくなるくらいにメリットが思いつかないのですが。。。
宜しくお願い致します。

Comments

[Orlofsky]

タイトルはどんなことを質問したいのか、想像できるものに変えてください。

Answer 1

テーブルの名称であるaccountとdetailについて考えてみましょう。
account自体は個人が主体ではありません。
和訳しても勘定など計算に関するものが殆どで個人と結びつくようなものではありません。
元々キーを管理するような意味合いです。

detailはそれに対する付加情報で、たまたま体重や身長ということだけだと思います。

身長や体重のように1:1になるものもあれば、1:多になるものもあります。
これらを拡張していくとすれば、軸となるものが必要でそれがaccountということになります。

また、キー同士の関係で1:1になるものでも、利用する機能に合わせて分割する場合もあります。
例えば、個人の様々な情報を入力する複数の画面を考えた時、一つのテーブルとするより画面ごとのテーブルに分割する方が、処理も楽ですしね。

追記

気付いた点について一つ。
t_accountの方にFKとしてdetailidがありますが、この関係だとt_detailの方が先に作成されていないとおかしいことになり、t_detailは身長と体重の組み合わせのパターンテーブルとして既に存在しているという事になります。
なのでその場合の関係は、t_detail⇒t_accountとして1:多ですね。

身長と体重として入力するような場合には、t_detailにFKとしてaccountidがあるのが正しい設計だと思います。

Answer 2

一対一関係のデータは一つのテーブルにまとめるというのがデータベース設計のセオリーです。
が、例外的に一対一にわける設計をした方がいいケースもあります。
下記辺りを参照。

【DB設計/オブジェクト指向】一対一テーブルを作った方が良いケース【 Rails】 - Qiita

また、一対一関係のテーブル設計なら、通常は主キー同士を結合する設計になります。

T_Account
-------------------
PK　AccountID

T_Datail
------------------
PK　AccountID
　　Height
　　Weight

しかし、提示のテーブル設計は、一対一の設計になっていません。
t_Account で、DetailID が主キーでないということは重複する可能性があるということなので、
t_Detail と t_Account は設計としては、一対多の設計になっているということです。
DetailID にユニーク属性を付加して一対一にするということも考えられますが、
そうならば、AccountID と DetailID と２つのキーを持たせる必然性がありません。

このような設計にしたということは、
t_Account が個人と一対一で結びついたデータでない、つまり、個人が複数のAccountを持つ可能性がある、
あるいは、T_Datail が個人と一対一で結びついたデータでない、
例えば、現時点での身長と体重は一つですか履歴も持たせる、
というような場合が考えられます。

提示のテーブル設計は実際のものではないと思いますので、
実際のデータなしに、実際にはありえないテーブル設計を見せられて、
どうこう議論しても意味はないと思われます。

実際のデータが本当に一対一の関係なのか、確認されてはどうですか。
本当に一対一の関係なら、上のリンク先にことに該当するか確認されればいいでしょう。

Comments

[sazi]

> t_Detail と t_Account は設計としては、一対多の設計になっているということです。
PK accountid , FK detailid ⇒ pk detailid
という関係なら、accountid に対して、detaiidという選択肢は持てても、1:多には成り得ませんよ

[sazi]

すいません。上記コメントは誤りです。
FKという視点で考えると1:多ですね。
t_detailが個人を表し、t_accountがログイン情報などを示すものと考えるのもありですね。
名称に惑わされてしまいました。というか関係が正なのか名前が正なのか正直分かりませんが。

[hatena19]

実際のデータなしに何が正しいかを議論しても始まらないということだと思います。
テーブル名やフィールド名も実体を表しているとは思えませんので。

Answer 3

アカウント情報には誰でもアクセスできても、
体重や身長といった個人情報には誰でもアクセスさせたくない場合は
それぞれわける意味もあると思います。

Answer 4

身長・体重の更新が頻繁に行われる可能性があるのであれば、
テーブルロック等を鑑みて、更新専用のテーブルとして分けているのではないでしょうか。

Answer 5

おっしゃる通り１つにまとめてもよいですが、
身体情報は、プライベートな情報なので、ここでは別テーブルにしている気がします。

アカウントID、パスワード、名前などは、t_accountとして、
そこに、どこまでまとめておくかでしょうか。
郵便番号、住所１，２、電話番号、勤務先など

検診などの場合は、時系列で複数回計測することになるので、
t_detailは、account_id, seq(履歴用にカウントアップ),weight,heightみたいに個人に対して、
複数レコードが発生します。

設計時にどういう目的で使用するかで変わるかと思います。

Answer 6

draw.ioは使ったことがありません。
ひとりの人の身長と体重が複数ありうるなんて通常は考えられません。だから、1対多である必要はありません。テーブルを設計した担当者に確認するのがいちばんの近道でしょう。
それが難しいなら、外部キー制約について のように、実際に親テーブルと子テーブルにどんなデータが入っているか、調べてみては？