Q&A
ER図の見方がわからないという問題でしょうか？
概略
以前このような質問をして、アドバイスを頂いたのでそれを元にテーブル定義とリレーションを行った。
環境
Laravel 6.5.0
Homestead
質問に際してやったこと・作ったもの
テーブルの登録内容
テーブルの登録内容2
想定しているER図
Laravel Entity Relation Diagram Generatorが出力したER図
tinkerでのテスト
質問したいこと
Laravelでの主キーかつ外部キーのテーブルとの適切なリレーションができているのか判断がつかないので、想定している挙動がなされているかご指摘いただきたいです。
なぜ判断がつかないのかというとLaravel Entity Relation Diagram Generatorが出力したER図においてbusiness_hoursテーブルfacilitiesテーブルとでbelongToは成立するのですが、HasManyの関係が成り立っていないように見えるからです。
意図としてはFacilityモデルからopenとcloseが拾いたい、つまり施設と営業時間を登録しているテーブルは分けるけれど、施設ID（facilitesのID）からその施設の営業時間を取得できる状態にしたいというものです。
tinkerで画像のように検証してみたところを見ると問題ないように見えるのですが、前述のことが気になり質問させていただきました。
備考
Laravel Entity Relation Diagram Generatorが出力したER図のpassword_resetの部分はLaravelのAuth認証を導入したときのデフォルトのままになっているだけなので無視していただければ幸いです。
追記
質問が分かりづらいということで補足をさせていただきます。
前回の質問 から今回の質問のER図を使うことを想定しているシステムの簡単なワイヤーフレームとアクティビティ図を追加。
作ろうとしているシステムの参考元
上記のURLの利用日時からの登録の部分を元に以下のようなシステムを作りたい。
####簡単なワイヤーフレーム
####今回質問したい箇所に関わる簡単なアクティビティ図
以上のシステムを作ろうとして、想定したER図が画像の3枚なのですが、4枚目の画像(Laravelでマイグレーションした後のリレーションを図にしてくれるライブラリ)を見るとbussiness_hours belongsTo facilitiesは成り立っているけれども、facilities hasMany bussiness_hours の関係性が成り立っているようには一見見えないけれども問題はないのだろうかという質問です。
親テーブルと子テーブルが1対1でデータを持っているということですか？
それって正規化する必要がないってことではないのですか？
というコメントについてですがfacilitiesとbussiness_hoursでテーブルが分けているのは営業時間テーブルは別に作り、それを施設テーブルにリレーションさせるのが良いとアドバイスを受けた結果です。
なお、先程前回の質問の回答者の方から改めてコメントを頂いてIntegrerになっていないidについてはIntegerないしBigIntegerにして、やはりオートインクリメントにするべきなのではとのことなので再度検討をしています。
Laravel歴1ヶ月で成果物を作るに当たってテーブル定義・設計をしっかり考えるのは今回初めてなので、そもそもリレーションの関係性の考え方が間違っている可能性と前回の質問で頂いたアドバイスを私が理解しきれていないで、間違って解釈している可能性も否めず、ここまでの私の説明もいまいち的を射たものだはないようで大変申し訳無いです。
ちょっと説明がよくわかりません
親テーブルと子テーブルが1対1でデータを持っているということですか？
それって正規化する必要がないってことではないのですか？
以前、テーブル設計についてこのような質問(https://teratail.com/questions/225110)をした際に、回答して頂いた方のアドバイスを元に想定したテーブル設計が、画像の3枚ER図なのですが、4枚目の画像(Laravelでマイグレーションしたテーブルのリレーションを図にしてくれるライブラリ)を見るとbussiness_hours belongsTo facilitiesは成り立っているけれども、facilities hasMany bussiness_hours の関係性が成り立ってないのでは？ という質問です。
facilitiesとbussiness_hoursでテーブルが分かれてるのは営業時間テーブルは別に作り、それを施設テーブルにリレーションさせるのが良いとアドバイスを受けた結果です。
Laravel歴1ヶ月で成果物を作るに当たってテーブル定義・設計をしっかり考えるのは今回初めてなので、そもそもリレーションの関係性の考え方が間違っている可能性と前回の質問で頂いたアドバイスを私が理解しきれていないで、間違って解釈している可能性も否めないです……
以前からの質問などそれなりの経緯や背景があるようですし、質問に追記された方が回答する際のヒントになります
回答1件
0
ベストアンサー
前回の回答をした私が言っても意味がないかと思いますが、現在のERで問題なさそうに見えます。
Laravel Entity Relation Diagram Generator
これを使ったことがないので憶測ですが
BelongsTo、HasMany等は、Modelの情報から生成しているのではないでしょうか？
ただ、各種はLaravelに習ってintger/biginteger型でオートインクリメントの方が良いと思います
投稿2019/11/28 07:36
総合スコア5036
前回に引き続き回答ありがとうございます。
最初に申し上げますとmikkameさんを責めているわけではく、一重に私が未熟故の悩みなのでその辺りはご承知おきください。
Laravel Entity Relation Diagram Generatorに関してはそれで間違ってません。
モデルに記述は一応してるのですが反映されないのでおや？ となった次第です。
idが文字列等になっているのは、１つはユーザーIDとかぶらないようにA001といった感じでつけたいのと施設テーブルと営業時間テーブルは管理者しか触らないのでオートインクリメントにする必要もあまり無いのではというのと、もう1つ予約情報のidがUUIDなのはUUIDshoterと併用して、予約番号としてユーザーに問い合わせの際必要なものとして控えさせたいという意図が一応あるというのがあります。
あまり、スマートではないのかもしれませんが……
> 施設テーブルと営業時間テーブルは管理者しか触らないのでオートインクリメントにする必要もあまり無いのではというのと
こちらは管理者が全ての施設、営業時間のIDを把握していれば良いのですが
担当者が変わったりすると覚え直す or 一覧と見比べて採番する必要があります。
連番にすることで、人間が考慮する必要がなくなります。
また、運用者がITリテラシーが高いとも限らないので・・・（ユニークにしてくださいで伝わらなかったり）
ポートフォリオとするなら比較的一般的な連番を採用すると良いでしょう。
UUIDは衝突する可能性が低いですが、天文学的数字で衝突する可能性があるので
特に必要なければ連番が良いのではと思います。
本人確認のため必要であれば、連番+ランダムな数字数桁でよいかと思います。
この場合は衝突する可能性が0です。
idをすべて連番にしてしまうと各テーブルzerofillで調整しても、外部キーで使ったときに主キーとの可読性が良くなく、例えばreservesテーブルにおいて、id=001、user_id_=1、facility_id=0001のようになるところを、idはuuidにし、user_id_=1、facility_id=A001のようにしたほうがレコードが見やすいのではと思ってのことでしたが、再度検討してみます。
ただ、予約番号については確かにidが連番だったとしても、それを取得してあとからランダム英数字などを生成したものを結合させればそれで済むのでそちらの方向で行こうと思います。
ユニークでやるならUUIDをと思っていましたが、こちらのほうが初制作の身としては詰まるところを減らせそうですし。
一般的にLaravelのIDはオートインクリメントで連番にすることが通例かと思います
（デフォルトのマイグレーションファイルもそうなっているはずです）
可読性を気にするなら、getterを設定し、出力時にpurefix、padを追加し整形してあげる方が良いかと思います
コメントが消えていたので再度。
確かに、Laravelだと連番にしたほうが通例としてもLaravelを使うということから見ても一番問題がおきなさそうなのでその線で検討をしたいと思います。
ただ、Laravelではzerofillが使えない(https://www.cyberbrain.co.jp/news/detail/157/)ということなので、そのあたりどうするべきか悩ましいところです。
あなたの回答
tips
プレビュー
