RailsでのDB設計について

Question

以下のように、会社、部署、社員のテーブルがあるとします。
これは例として作ったものでして、複数部署兼務などは考えないものとします。

companies
  id PK

departments
  id PK
  company_id

employees
  id PK
  company_id
  department_id

社員の所属会社を調べるとき、employees.department_idがあればemployees.company_idがなくても所属会社は一意に決まります。

しかしemployees.company_idをなくすと、会社に所属する全社員を取得するとき、全部署を取得してから各部署の所属社員を取得するか、includesなどを使ってJOINしてから絞り込みをすることになると思います。

なので、気分的には引っかかるものの、company_idとdepartment_id両方持たせる上記の設計にしたくなるのですが、これは普通でしょうか？

今回は推移関係が2段階だけでしたが、これが何段階にもなった場合はどうでしょうか？

Answer 1

DB設計の話でいけば、Orlofsky様のおっしゃる通りなのですが。
Railsは少し話が違います。

質問として、いまいちだったと思うのは

会社と部署という、包含関係はありそうだけれど全く違う構造になりそうなmodelを例に出し
包含関係がさらに追加された場合と言われてもOrlofsky様の回答しか引き出されないと思います。

Railsは基本的にtable（イコール）modelという概念で最適化されています。
これでなかなかの規模まで、なんとかなります。
また、Railsはしっかりとレールに乗った構築をしていれば
テーブルの構造に変更があっても、Railsの変更は最小限で済みます。
なので、設計はベターで行って、運用しながらベストを探る(案ずるより生むが易し)がRailsの基本となります。

というのを前提にして
もしその親子関係があるモデルというのが大グループ中グループ小グループみたいな感じでmodel(class)としての
機能がほぼ同じで、さらに細目グループが追加される可能性や小グループと中グループが入れ替わったり
中グループが消え小グループが大グループ直下になるとかいうことが起こり得るモデルなら
ancestryなるgem
をお勧めします。これはSQLアンチパターンを利用して包含関係を、activerecordに組み込んであるので
非常に使いやすいです。

Answer 2

どんなシステムでしょうか？

会社テーブルはともかく、部署は会社によってまったく異なるでしょうからテーブルにするでしょうか？必要なら部署名をそのまま社員テーブル？(顧客テーブル)に持つのでは？

システムの用途などは説明された方が良いです。

Comments

[vc3000]

実際に作りたいのは会社、部署のDBではないのです。この構造にだけ着目していただきたいです。
要は
employees.department_idがあればemployees.company_idがなくても所属会社は一意に決まります。
のような冗長性がある設計を許容するのはよくあることか？とお聞きしたかったのです。
システムの詳細が分からないと回答できなければ、一般論、理論的な説明だけでも良いです。
不勉強で知らないのですが、このような冗長性に呼び方はあるのでしょうか？あるいは、この冗長性を消去することを○○正規化と呼ぶ、とか。

[Orlofsky]

質問でも回答でも理解され易い文章を書くのはハードルが高いです。

通常第3正規化まで行います。ミッションクリティカルなシステムだったり、DWHのような大量なデータを扱う場合は、将来のことも考慮して
>employees.department_idがあればemployees.company_idがなくても所属会社は一意
なら正規化を崩してdepartmentsにcompany_nameを持たせる事でcompany_idを削ることも考えられます。ですが、その効果が微々たるものだったり、データ増減に伴うcompany_nameの設定がきちんとできなければ正規化をきちんと守ります。
複合キーを減らしたいのであればサロゲートキーを使う場合もあります。
https://www.google.co.jp/?gws_rd=ssl#q=%E3%82%B5%E3%83%AD%E3%82%B2%E3%83%BC%E3%83%88%E3%82%AD%E3%83%BC