質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Ruby

Rubyはプログラミング言語のひとつで、オープンソース、オブジェクト指向のプログラミング開発に対応しています。

Ruby on Rails

Ruby on Railsは、オープンソースのWebアプリケーションフレームワークです。「同じことを繰り返さない」というRailsの基本理念のもと、他のフレームワークより少ないコードで簡単に開発できるよう設計されています。

データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

Q&A

解決済

2回答

4933閲覧

【データベース設計】会社名、部署、社員テーブルを作る

no1knows

総合スコア3365

Ruby

Rubyはプログラミング言語のひとつで、オープンソース、オブジェクト指向のプログラミング開発に対応しています。

Ruby on Rails

Ruby on Railsは、オープンソースのWebアプリケーションフレームワークです。「同じことを繰り返さない」というRailsの基本理念のもと、他のフレームワークより少ないコードで簡単に開発できるよう設計されています。

データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

0グッド

0クリップ

投稿2020/01/19 18:16

編集2020/01/21 08:17

知りたいこと

データベース設計について、下記のデータ登録を踏まえて、どのようにすればより望ましいのかアドバイスいただければと思います。
※個人開発のため仕様書はありません。

データ登録の流れ

  1. その会社ではじめてメールアドレスを登録したものが管理者になる。
  2. 管理者が、会社名と自分の名前を登録する。
  3. 管理者が、会社名に紐付いた部署名を登録する。
  4. 管理者が、システム上から社員のメールアドレスを登録する。

⇒この時点で登録した社員のUserレコードが作成され、会社名が登録されている。
0. 管理者が、システムを利用して招待メールを送信する。
0. 社員が、招待メールを受信し、リンクをクリックして、登録画面へ遷移する。
0. 社員は、3.で紐付いた部署名を選択し、自分の名前を入力する。

#整理してみる
①**「データ登録の流れ3.」から、会社名と部署名は、1対多の関係
「データ登録の流れ4.」**から、Userレコードは、会社名が登録が必須

検討したテーブル

3つのテーブルを検討しました。
Cであれば適切なデータの持ち方でもあるのでのぞましいかと思いますが、空レコードを作るような考え方で問題はないのでしょうか?

A

1#中間テーブルをもつ形。 2 3Company 4| id | name | 5Department 6| id | name | 7USER 8| id | name | company_id | department_id | email | 9 10#「整理してみる①」を満たすための中間テーブルを準備するが、適切な形じゃない気がする。 11Company_Department 12| company_id | department_id | 13

B

1#会社名、部署名、社員の親子関係を表現した形 2 3Company 4| id | name | 5Department 6| id | name | company_id | 7 8#「整理してみる②」を満たすため、ユーザーレコードに会社名のカラムを追加した。結果、会社名に関連したカラムが重複し適切な形じゃない気がする。 9USER 10| id | name | company_id | department_id | email | 11

C

1#会社名、部署名、社員の親子関係を表現した形 2 3Company 4| id | name | 5 6#「データ登録の流れ2.」会社名登録の段階で、部署名未定の部署レコードを作っておく。 7Department 8| id | name | company_id | 9 10#「データ登録の流れ4.」社員のメールアドレスを登録する際は、事前に作っておいた部署未定のIDを利用する。 11USER 12| id | name | department_id | email | 13

どうぞよろしくおねがいします。


説明が不十分だったために質問を大幅に修正させていただきました。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答2

0

2の時点で部署名が決まっていないなら、少なくともuserとcompany_id は結びつきが無いと無理っぽいですけど。

管理者が、userにdepartment_idの結び付け迄行うならBでも良いでしょうけど、流動的に行うなら、以下の構成なら対応が可能ではないかと思います。
※department_idの結び付け時には、company_id も更新。

USER | id | name | company_id | department_id |

投稿2020/01/20 10:17

sazi

総合スコア25138

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

no1knows

2020/01/20 21:52

説明が不足しており申し訳ありません。 2の時点でuserとcompany_idは紐付いている形になります。 他の選択肢のご提案ありがとうございます!今後の参考にさせていただきます。
sazi

2020/01/21 00:29

質問のABC何れも、userとcompany_idは紐付いている、2の状態を保存できませんけど?
no1knows

2020/01/21 08:28

ご確認ありがとうございます。 「userとcompany_idは紐付いている」の中の「紐付いている」という言葉が外部キーで結ばれているという意味だとすると、誤用となります。 正しくは、外部参照している形になります。 うまく説明できていない部分が多々あったので、大幅に修正させていただきました。 できる限り丁寧に書いたつもりですが、このような形で伝わりますでしょうか?
guest

0

ベストアンサー

それぞれの関係性を正しくリレーションに落とし込めているのはBなので、これをベースにするのがいいかと思います。

その上で、パフォーマンスやフレームワーク的に厳しい場合はuser.company_idを新設する(正規化を崩す)ことを検討するのが良いかと。

投稿2020/01/20 01:04

tanat

総合スコア18709

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

no1knows

2020/01/20 21:50

ありがとうございます!Bで進めたいと思います。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問