DB設計とアソシエーションに困っています（Rails)

Question

はじめに

私は現在、Railsを使ってシフト作成アプリを開発中の者です。

制作途中のサイトのイメージ↓

DBのER図↓

###解説

• 2行目はMeetingモデルによってイベント行事を記入する場所
• 1列目はStaff_nameモデルに名前を登録し、each文で引っ張ってきて表示
• プルダウン式のSELECTフォームはShiftモデルに登録した内容を表示

というような過程でここまで表示できたのですが、これだとデータベースに保存できないことに気づき、、、（笑）
行き詰ってしまいました。

##やりたいこと

SELECTフォームで入力した内容を保存したいです。
例えば1日のテスト君3は早番のような感じ。
Staff_nameとShiftを多対多の関係でつなげる方法があるのかな、と思いますが、同時にdateカラムもつけたいので、そのあたりをどう表せばいいのかなと思っています。
わからないことやほかに知りたいことも答えますので、どなたかご教授お願い致します。

Comments

[urbainleverrier]

私の理解不足なのですが、なぜ「データベースに保存できない」と思われたのですか？
また、ここではUserに紐付けされるというより、staffが重要なドメインであるような気がします。なぜUserに紐付けしようとされたのですか？

[YusufHigh]

返信ありがとうございます！
私のイメージでは、上の図で説明しますが、最終的には「1日のテスト君１は早番」、「4日のテスト君３は遅番」というデータをDBに保存したいと思っています。そのため事前にUserに紐づけしたStaff_nameとShiftにそれぞれスタッフ名、シフトの内容を登録しておき、そこから引っ張ってくる形をとりました。
スタッフ名とシフト内容はそれぞれStaff_nameとShiftでCRUD操作が行えるようにしています。
Meetingはただ単にイベントを追加するためのものなのでUserに紐付けています。
私が説明下手で申し訳ございません。納得されませんでしたら、もっとおっしゃってください！

[YusufHigh]

「データベースに保存できない」という点につきましては、上の図まで作り上げて、とりあえず適当にシフト内容を入力し、翌週のページを表示してそのあとすぐ元の週に戻してみました。すると先ほどの入力が反映されていませんでした。
もしそのまま反映させるのであれば、どのスタッフの（Staff_name)、いつ(date)、何を（Shift)という3つのデータカラムをもつテーブルを作成する必要があるのかなと思いますが、これをどう表すのかにとまどっています。

[urbainleverrier]

ありがとうございます。
おそらく、Userはログインなどに関わる認証コンテキストの部分ですから、Userとstaffは概念的に異なるのかと思われます。
また、Shiftのコンテキストにおいてはstaffというメンバーとshiftの内容、日付などが関わってくるのではないかと思います。
ですから、Shiftのテーブルには日付、staff_id、content(or shift_content_id)という内容になるのではないですか？

とはいうものの、実際の場面に即した設計を行うには、十分にその利用用途を知っている方にしかできません。
例えば、shiftを作成する人が誰かという概念やそのshiftに所属できる人の概念もあるんじゃないかなと思います。認証に密接に関わってくる部分もあるでしょうから、その辺の事情を考慮した納得のいく回答を得るにはなかなか難しいかもしれません。

[YusufHigh]

丁寧なお返事ありがとうございます！
確かに設計者の概念が関わる問題ですね。
それにShiftはUserに紐づけせずに、Staff_nameへ紐付けしていいですね！
ただし確認ですが、Shiftテーブルに日付とstaff_idを入れるとする場合、そのスタッフのシフトを毎回入力する形になりますよね？
大体シフトの内容というのは何パターン(早番、遅番、早上がりなど)かに決まっているので、あらかじめいくつかシフトパターンを用意しておいて、スタッフとシフトを日付とともにつなぎ合わせようかと考えておりました。
この場合はStaff_nameとShiftを多対多の関係にする必要はないでしょうか？
何度も質問して申し訳ございません。

[urbainleverrier]

ここでShiftというのはパターンが格納されているもののことですよね。staffとそのパターンがどのような関係になっているのかいまいちわかっていません。

何かフローを表すようなshiftの申請を表すデータがあって、そこには申請者(staff)、shiftのパターン、時刻などが記載されているはずです。直接的に多対多のような関係になる理由を「私が」今理解していないので、お答えできかねます。すみません。

Answer 1

コメント欄で指摘されている点と共通しますが、まずUserとStaffの関連がよくわかりません。

持っている項目から推察するに、Userはこのシステムの利用者だと思います。

で、「Staffもこのシステムの利用者」であるなら、StaffからUserの関連があるのはおかしくない気はします（Userが親でStaffはその派生となる親子関係）。ただし、そうであるなら、Staffテーブルには「name」等は不要だと思います。（Userテーブルを参照すれば良いため）

また、シフトに関する関連は全てStaffに対するものであって、Userとは関連しないはずです。例えばこれがコンビニの勤務シフト管理システムだとすると、「オーナー」とか「フランチャイズ本部の人間」がUserであってもStaffではない、というケースが考えられるためです。

そしてShiftテーブルについてですが、これが「早番」「遅番」などの「シフトという概念の定義（シフトのパターン）」であるなら、「シフト管理」テーブルのようなものを別途作成し、そこに「StaffのId」「日付」「ShiftのId」を保存すれば、たぶんやりたいことが表現できる気がします。

大体シフトの内容というのは何パターン(早番、遅番、早上がりなど)かに決まっているので、あらかじめいくつかシフトパターンを用意しておいて、スタッフとシフトを日付とともにつなぎ合わせようかと考えておりました。

これは「シフト管理」テーブル的なものに登録（追加）する時に参照する情報として、Staffテーブルに「Shift初期値」みたいな項目として「ShiftのId」を持っておくか、別テーブルにそういう関連情報を持たせておくのが普通かなと。

---

追記
「Shift」というテーブル名が「シフトのパターン」だというのは直感的にわかりにくいので「ShiftPattern」等の具体的な名前にした方が良いと思います。

---

追記２
質問文中にはこのプログラムのユースケースをちゃんと記載してください。上記回答は画面のコピーがER図がら色々と察して（想像して）書いてますが、そこが違った場合に全く意味をなさない回答になってしまいます。
「あなたにしかわからない情報」はちゃんと書きましょう。

Comments

[YusufHigh]

貴重なご意見ありがとうございます！
なるほど、、、そこまで深く考えて質問しておりませんでした。。。申し訳ございません。
もう一度改めて考え直してみます！