リレーションの組み方・データ設計がわかりません。

Question

前提・実現したいこと

以下の三つの主体があります。

• プロジェクト
• チーム
• メンバー

そして、以下の要件を満たしたいです。

• チームとメンバーは多対多の関係

• チームとプロジェクトは多対多の関係

• プロジェクトからチームを通してメンバーを取得する時、メンバーをそれぞれのジョブタイトルと一緒に表示させたい。

• メンバーのジョブタイトルは、プロジェクトごとに変わる。

• 一つのプロジェクトの中では、メンバーによってジョブタイトルは変わる。

発生している問題

このジョブタイトルがプロジェクトごとに変わるというデータ設計の仕方がわからないです。

以下のようなER図を書いたところで止まってしまいました。

ER図

Comments

[ssasaki]

とりあえずER図の画像が見れないようです。

[d0futa]

コメントありがとうございます。更新しました。変わらないでしょうか？

[ssasaki]

正常に見れるようになりました。

[sazi]

> メンバーのジョブタイトルは、プロジェクトごとに変わる。
プロジェクトが決まればジョブタイトルは決まるという事で良い？

[d0futa]

コメントありがとうございます。追記しました。

一つのプロジェクトの中で、メンバーによってジョブタイトルは変わります。なので、プロジェクトが決まっても各メンバーのジョブタイトルはまだ決まりません。

Answer 1

プロジェクトとジョブというと、進捗などを表わすガントチャートで管理されるものが思い浮かびます。

その場合、ジョブというのは一つのエンティティです。
プロジェクトとジョブの組み合わせに、メンバー(※)が結び付くという関係でしょう。
※チームが結び付くというのも考えられますが、あくまでチームはメンバーを展開するための情報として利用すると考えた方が、複雑にならずに済みます。

質問のER図的に云うと、ジョブ（ここにジョブタイトル）とプロジェクト＋ジョブ＋メンバーのマップという構成になるかと思います。

※プロジェクト＋ジョブというマップとそのマップとメンバーの組み合わせの方が楽かもしれない

Answer 2

私の案をば

[チーム]-[メンバー]
の関係はそのままで良いと思います。(ただし中間テーブルはサロゲートキーを持たないことが多い)
これはマスターデータと考えていいでしょう。
[ジョブ]は微妙ですが、これもマスターデータと考えていいでしょう。
マスター側では[ジョブ]は紐づけません。

すると、トランザクションデータは多分こんな感じに紐づくと思います。。
[プロジェクト]-[ジョブ]-[メンバー]

最終的に
[チーム]-[メンバー]-[ジョブ]-[プロジェクト]
こんな感じでしょうか？

Comments

[d0futa]

回答ありがとうございます！
なるほど、チームとプロジェクトのリレーションを切り離すということでしょうか。
思いつきませんでした、、、とても参考になります。

Answer 3

ジョブタイトルについて説明が不足しているので考えてみましたがこんな感じが限界です

ジョブタイトルは1プロジェクトに1ジョブタイトルなのか、
その1プロジェクトの中でもユーザーによってジョブタイトルは変わるのかなど・・・

---

情報いただいたのでまた色々踏まえて考えた結果以下になりました

SQLのプロではないので参考程度にお願いします・・・。

質問がきっかけで良い勉強になってます。ありがとうございます。

Comments

[d0futa]

回答ありがとうございます！とても参考になります。
情報足りず申し訳ありませんでした。
プロジェクトの中で、ユーザーによってジョブタイトルは変わります。

[d0futa]

いえいえ、こちらこそご丁寧に回答いただいてとても感謝しております。

私が最初につくった状態から、ユーザーとプロジェクトの間に新たに中間テーブルを作成して、そこにジョブの情報を載せておくというイメージでしょうか。

Answer 4

単純に projects_table に job_title を追加するだけではダメなのでしょうか？
job_title は１つのプロジェクトで複数種類存在するのでしょうか？

Comments

[d0futa]

回答ありがとうございます！

はい、一つのプロジェクトの中でメンバーごとにジョブタイトルは変わります。。

説明不足申し訳ありません。