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

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

ただいまの
回答率

90.52%

  • SQL

    2386questions

    SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

  • データベース

    698questions

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

  • データベース設計

    145questions

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

【マスタ設計】サロン予約サイトのモデル化

解決済

回答 3

投稿 編集

  • 評価
  • クリップ 0
  • VIEW 216

teratailler

score 24

はじめて本格的なデータベース設計をします。
周りに誰も相談出来る人がいないのでどうかご回答のほどよろしくお願いします。

 前提

具体的なイメージを共有したいので、サービスはホットペッパービューティーを例にしてご質問させていただければと思います。
各サロンは独立していて、それぞれが施術メニューを持っており、それぞれが予約を受け付けることができ、それぞれがそれぞれの情報を編集できるというイメージです。

 質問内容

サロンがメニュー毎に、施術可能時間(必須)、予約期限(任意)、期間限定公開(任意)を設定できるようにする場合、テーブル設計はどのようにするのがベターでしょうか?

<言葉の定義>

  • 施術可能時間(必須入力)
    いわゆる営業時間。
    このメニューは夜限定とか有りうるので、あえてサロン毎ではなくメニュー毎に持っている。
  • 予約期限(任意入力)
    施術可能時間のオプションのようなもの。
    この施術を受けるにはいついつまでに予約が必要といった設定。
  • 期間限定公開(任意入力)
    期間限定商品のようなもの。
    ある時期限定のメニュー等、ある一定期間のみ予約を受け付けたい場合に設定。

 やったこと

とりあえず以下のようなイメージで考えてみましたが、これが正しいのかも判別がつかない状況です。
もっと良いモデルの設計があるのではないかと思うのですが、今のスキル的にこれが自分の中でベストな答えです。

サロンテーブル

サロンID 名前
1 サロンA
2 サロンB

メニューテーブル

メニューID サロンID 名前
1 1 パーマ
2 1 カット
3 2 クリスマス限定カラー

時間テーブル

時間ID メニューID 施術可能日 施術可能時間(自) 施術可能時間(至) 予約期限日 予約期限時間
1 1 10:00 20:00 20:00
2 1 10:00 20:00 20:00
3 1 10:00 20:00 20:00
4 1 10:00 21:00 20:00
5 1 10:00 21:00 20:00
6 1 10:00 20:00 20:00
7 2 10:00 20:00 null null
8 2 10:00 20:00 null null
9 2 10:00 20:00 null null
10 2 10:00 21:00 null null
11 2 10:00 21:00 null null
12 2 10:00 20:00 null null
13 3 2018-12-24 10:00 20:00 2018-12-23 22:00
14 3 2018-12-25 10:00 20:00 2018-12-23 22:00

※メニュー毎に365日分のレコードが出来ると恐ろしいことになるので、基本は日付単位で持つのではなく、曜日単位で持ち、アプリ側で現在日付をもとに判定するように設計してみました。
※パーマ(メニューID=1)は基本前日(月は休み)の20:00までに予約が必要ということを表しています。
※カット(メニューID=2)はいつでも予約できるということを表しています。
※クリスマス限定カラー(メニューID=3)は特定日のみ施術可能かつ、前日の22:00まで予約が必要ということを表しています。

よろしくお願いします。

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

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

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

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • m6u

    2018/06/22 12:30

    施術可能日、曜日なのか、日付なのか、データ型はそこまで柔軟じゃないのではっきりさせるべきかと。

    キャンセル

  • teratailler

    2018/06/22 12:35

    両方です。よって文字列型を想定してます。あまりよろしくない感じはするのですがそれに変わる設計案がスキル的に思い浮かばず「期間限定公開」に対応するための苦肉の策です。方針としては質問にも記載しました「メニュー毎に365日分のレコードが出来ると恐ろしいことになるので、基本は日付単位で持つのではなく、曜日単位で持ち」です

    キャンセル

回答 3

checkベストアンサー

+2

思い付くままにざっくりと列挙すると、

サロン(ID,名称,住所,電話番号,営業曜日時間_月~日)※住所は予約の際の地域での絞り込み想定
サロン営業時間特記(ID,サロンID,営業休業区分,開始日時,終了日時)※上記とは異なるイレギュラーを登録

メニュー(ID,サロンID,メニュー名,所要時間,料金)
コース(ID,サロンID,コース名,所要時間,限定開始日時,限定終了日時)
コースメニュー(ID,サロンID,コースID,メニューID) ※コースの構成要素。

予約(ID,サロンID,コースID,予約日時,利用者ID)
予約オプション(ID,予約ID,メニューID)

上記を元に日付を与えて展開。

追記

リンク先見ていなかったので、ちらっと見た上で再考して修正しました。
最終形というわけではなく、サロン側が操作する視点、利用者が操作する視点など、それらの視点で必要な形で取り出せるか、追加更新ができるかなどで、ブラッシュアップしていく必要はあると思います。
予約に関しても、店側のキャパシティに関する情報も必要でしょうし。
キリが無いので、こういった切り口もあるよというのが伝わっていれば良いのですが。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+1

サロンとメニューと時間はマスタなわけですよね。
紐づけをするテーブルを作ってみては?
ざっくりとした考え方ですが、
マスタテーブルに別のマスタテーブルのIDは持ちません。

サロンID 名前
1 サロンA
2 サロンB
メニューID 名前
1 パーマ
2 カット
3 カラー
時間ID 割愛
1 ほげほげ
2 げほげほ

雑過ぎですが紐づけテーブルの例

サロンメニュー時間ID サロンID メニューID 時間ID
1 1 1 1
2 1 2 2
3 2 3 1

時間テーブルが煩雑すぎます。
非稼働日のほうが少ないのであれば、非稼働日から考えると何かいい考えが浮かぶかもしれません。
あとは、非稼働日と特殊な稼働日で分けて考えるとか。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

サロンAとサロンBで同じメニューを扱うことがあるのであれば、
メニューテーブルは独立させて、時間テーブルにサロンIDを入れても良いのでは、と思いました。
メニューにサロンがあるわけではなく、サロンにメニューがあるわけですし(所属とか帰属の関係の問題)

5W1H的に考えるといいかもしれません

いつ(何時に)
どこで(どのサロンで)
なにを(どのメニューを)

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/06/22 12:39 編集

    > サロンAとサロンBで同じメニューを扱うことがあるのであれば
    店舗ごとに独立しているのでそれはないです。

    > メニューテーブルは独立させて、時間テーブルにサロンIDを入れても良いのでは
    営業時間と捉えるとそうなりますよね。実際はメニューの利用可能時間です。
    夜限定のメニュー等、そのメニューを予約できる時間は最終的にメニューに紐づく想定です。

    キャンセル

  • 2018/06/22 12:45

    > 店舗ごとに独立しているのでそれはないです。
    言葉が足りずに申し訳ないですが、そういう意味ではないです。
    サロンとメニューを紐付けしてしまうと柔軟な対応ができないことを指摘しています。
    提示の例ですと、サロンBでもカットを扱うことになったとき、サロンB用のカットの行を追加するのは汎用性に欠けませんか?
    同じカットだとして価格帯が違うのであればそれも要件が抜け落ちていることになるので質問に追記していただきたく。

    今の状態だと時間テーブルとメニューテーブルをわけているメリットがあまりありません。

    キャンセル

  • 2018/06/22 12:57 編集

    > サロンBでもカットを扱うことになったとき、サロンB用のカットの行を追加するのは汎用性に欠けませんか?

    それだとサロンBがメニュー名を更新したらサロンAのメニュー名も変わりませんか?
    サロンAがすでに紐づけされているカットをサロンBにも紐づけさせるわけですよね

    > 同じカットだとして価格帯が違うのであればそれも要件が抜け落ちていることになるので質問に追記していただきたく。

    すみません、価格や数量等細かい属性に関する情報についてはノイズになると思ったのであえて割愛しています。

    > 今の状態だと時間テーブルとメニューテーブルをわけているメリットがあまりありません。

    すみません、なぜでしょうか?

    キャンセル

  • 2018/06/22 13:05

    > それだとサロンBがメニュー名を更新したらサロンAのメニュー名も変わりませんか?
    サロンAがすでに紐づけされているカットをサロンBにも紐づけさせるわけですよね

    質問内の要件だけではそこまで汲み取れませんでした。
    あくまで「サロンがメニュー毎に~~設定する」ということで、メニュー自体は誰が持っているかというところですね。
    サロン側の権限(どこまで触れるか)などもあわせて要件として追記しておいてもらえると助かります。

    >> 同じカットだとして価格帯が違うのであればそれも要件が抜け落ちていることになるので質問に追記していただきたく。
    > すみません、価格や数量等細かい情報についてはノイズになると思ったのであえて割愛しています。

    なかったため、今起きている認識の齟齬が起きています。
    提示可能な情報はなるべく全て提示すべきと思います。
    特に今回のような「設計」となると1つでも項目が漏れてしまうと成り立たなくなります。

    >> 今の状態だと時間テーブルとメニューテーブルをわけているメリットがあまりありません。
    >すみません、なぜでしょうか?

    既に述べたとおりです。
    必要な要件が抜けているので、質問内容に追記してください。
    ※ただ、今コメントいただいた内容だと私の回答はあまり参考にならないので追記した上で他の回答を待つことになりそうです

    キャンセル

  • 2018/06/22 13:21

    説明不足すみませんでした。
    ご回答ありがとうございました。
    要件については補足しておきます。

    キャンセル

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

  • ただいまの回答率 90.52%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る

  • SQL

    2386questions

    SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

  • データベース

    698questions

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

  • データベース設計

    145questions

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