sql >> データベース >  >> RDS >> Database

おいしい料理(およびデータ)の提供–レストランのデータモデル

    レストランを経営する上でデータベース設計はどのような役割を果たしますか?レストランデータベースのデータモデルはどのようになりますか?この記事で調べてください。

    レストランでは、既製の料理を提供しています。これは世界中で繁栄しているタイプのビジネスであり、多くの場合フレアがあります。人々はレストランに行くのがとても快適で、次の食事に関しては幅広い選択肢を期待し始めています。

    ニューヨーク市だけでも、24,000を超える飲食店があります。これらには、テイクアウト(ピザ、サブショップ、中華料理のテイクアウトなど)、デリ、カフェ、高級レストランが含まれます。次のことわざは、レストラン業界に非常によく当てはまります。それは事実上彼らの普遍的な使命声明です:

    彼らがもう一度それを見て、彼らの友人や家族を連れて行きたいと思うように、あなたがうまくやっていることをしてください。

    ウォルトディズニー

    レストランにデータベースが必要な理由

    レストラン経営は簡単な仕事ではありません。日常のタスクを追跡して実行することになると、最も経験豊富なレストラン経営者でさえ、簡単に管理できる以上のものを持っている可能性があります。収益性の高いレストランを運営するには、在庫/在庫の管理、無駄の最小化、テーブルの管理(特にピーク時)、顧客に優しいメニューの維持、効率的な注文の実行、レストランスタッフの監督が必要です。それはかなりたくさんです!

    レストラン管理システムは、最小限の手動介入でこれらの活動のほとんどを実行する必要があります。彼らが顧客を幸せに保つことができるように、それはマネージャーに正確な情報を提示しなければなりません。これは、メニューやレストランの機能に適切な変更を加えることを意味する場合があります。

    レストランデータモデル

    この記事は、レストラン(外食またはテイクアウト)の本格的なデータモデルの設計に関するものです。また、レストラン業界の人々が日常の活動で遭遇する2つの大きな問題についても取り上げます。最後に、これらの機能を既存のシステムに組み込むために必要な変更について検討します。

    データモデルについて詳しく説明するときに、特定のユーザーロールについて説明します。これらの役割は、実際には次のようなスタッフメンバー向けです。

    • マネージャー–レストランの在庫、給与、従業員のスケジュール、指標を管理します
    • ホスト–ゲストを収容し、サーバーをテーブルに割り当てます
    • ウェイター(サーバーとも呼ばれます)–顧客の注文をキッチンに運び、準備された注文を顧客に配達します
    • スーパーバイザー(シェフまたはヘッドクックとも呼ばれます)–キッチンでのタスクを監督し、料理人にタスクを割り当てます
    • クック–スーパーバイザーから受け取った注文の詳細を読み取り、料理を準備し、準備ができたらスーパーバイザーに通知します
    • Busboy –使用されているテーブルを追跡します。テーブルをクリーンアップし、必要に応じてステータスを更新します

    レストランビジネスのデータモデルには、次の基本的な機能が必要です。

    • KOT(キッチン注文トークン)管理
    • KOD(キッチンオーダーデリバリー)管理
    • メニュー管理

    これらの各機能について詳しく見ていきましょう。

    KOT(キッチン注文トークン)管理

    これは、データモデルの最も重要な部分です。さまざまなチャネルを通じて顧客から注文の詳細を収集することがすべてです。なぜさまざまなチャネル?オンラインやモバイルアプリ、電話、ウェイターや他の従業員など、注文にはいくつかの方法があります。顧客が注文するたびに、KOT(キッチン注文トークン)が生成されます。最終的に、KOTはキッチンスタッフによって準備されます。

    テーブルを作成しますkot 、予備注文の詳細を保持します。このテーブルには次の列があります:


    列名 説明
    Id このテーブルの主キー
    order_channel_id 注文が行われるチャネル。
    dine_in_table_sitting_id 注文が発生したテーブル。この列は、外食注文の場合にのみ入力されます。
    order_in_time 注文がシステムにログインしたときのタイムスタンプ
    order_out_time キッチンスタッフが注文を配達したときのタイムスタンプ
    staff_id 注文を収集する人のID。食事注文の場合、この列には注文を収集するウェイターのIDが保持されます。他の設定では、このIDは「SYSTEM」になります。
    kot_status_id KOTの現在のステータスを定義します。


    一度に1つのテーブルから収集された注文は、1つのkot_idの下にタグ付けされていることを指摘しておきます 。同じテーブルが後でさらにアイテムを注文した場合、システムは別のkot_idを生成し、そのIDでこれらすべての新しいアイテムにタグを付けます。結局、すべてのkot_ids 同じテーブルの場合は、最終的な請求書に一緒に追加されます。

    KOT管理には、次のような追加の静的テーブルとトランザクションテーブルが必要です。

    • order_channel –この表には、レストランが注文を受け入れるために使用するチャネルに関する詳細が含まれています。一般的な例としては、オンライン、食事、持ち帰り(持ち帰り)などがあります。
    • dine_in_table_sitting –これは、テーブル占有データを格納するトランザクションテーブルです。その列にはdine_in_table_idが含まれます 、dine_in_timedine_out_timenum_person_sitting 、およびcustomer_id 。ホストが顧客をテーブルに割り当て、システムに情報を入力するとすぐに、レコードがこのテーブルに挿入されます。任意の時点でテーブルの現在の占有ステータスを取得するために、これが使用されるテーブルです。

      この機能を構築するとします。すべてのレストランテーブルの現在の占有状況を示すSQLは次のとおりです。

      SELECT 
        b.id as table_id,
        c.area_desc,
        CASE 
          WHEN a.dine_in_table_id IS NULL THEN ‘VACANT’ 
          ELSE ‘OCCUPIED’
        END AS current_table_status
      FROM dine_in_table_sitting a, dine_in_table b, dine_in_table_area
      WHERE a.dine_in_table_id (+) = b.id
      	AND b.dine_in_table_area = c.id
      	AND a.dine_out_time IS NULL;
      

    • kot_status –このテーブルには、KOTのすべての可能なステータスが保持されます:受注済み注文中注文の配信 、など
    • kot_menu_item –このトランザクションテーブルには、KOT内のすべてのアイテムの詳細が格納されます。また、KOTとmenu_itemの間の関係も定義します。 。 menu_item_id およびquantity kot_idに対するフィールド 注文したアイテムとその必要量を示します。

    KOD(キッチンオーダーデリバリー)管理

    レストランのパフォーマンスの大部分は、キッチン内のKOTの管理に要約されます。通常、スーパーバイザーはウェイター、他の従業員、またはオンラインシステムからKOTを収集します。次に、スーパーバイザーはメニュー項目を1人以上の料理人に割り当てます。料理人はアイテムを準備し、監督者に渡します。次に、ウェイターまたは別のスタッフが注文を収集して顧客に配達します。

    しかし、KOD管理に含まれるのはそれだけではありません。リソースの管理、材料の備蓄、残りの在庫の定期的な更新、および必要に応じた新しい在庫の要求も、キッチンの日常業務の一部です。スーパーバイザーは、特にピーク時に、キッチンのシームレスな実行において重要な役割を果たします。システムがスーパーバイザーの職務を複製できる場合、そのシステムは「スマート」または「インテリジェント」と見なされます。これは、ほとんどの場所でほぼ不可能です。

    この複雑な管理のモデルを構築するために、KOD 。このテーブルは、次の列で構成されています。


    列名 説明
    Id このテーブルの主キー
    kot_menu_item_id キッチンスタッフが現在取り組んでいるKOTアイテムを示します
    staff_id アイテムを準備している料理人のIDを保存します
    kod_status_id アイテムの現在のステータスを表示します


    メニュー管理

    このコンポーネントは、KOTおよびKODの管理と同じくらい重要です。メニューは、視覚的な表現と提供する料理の両方で、顧客を引き付ける最初のものの1つです。そのため、すべてのレストラン経営者は、メニューをできるだけ魅力的に保つように努めています。

    メニューの詳細を保持する別のテーブルを作成しましょう。メニューに通常表示されるすべての詳細の列を追加します:


    列名 説明
    Id テーブルの主キー
    Item_name メニュー項目の短縮名
    Item_category_id アイテムの料理カテゴリを示します:イタリア料理、コンチネンタル料理など。
    Item_desc 材料リストやアイテムの準備方法(焼き、蒸しなど)などのアイテムの詳細が含まれています
    Item_image アイテムの派手な画像。
    cost アイテムの費用


    データを使用して実際のレストランの問題を解決する

    いくつかの問題は、外食産業の世界では非常に一般的です。特に、テーブルに座って食事をとるのに、長い待ち時間を考えています。これらの問題は、レストランのデータをより適切に整理して使用することで、少なくとも部分的に解決できることがよくあります。

    食事の場では、テーブルを長時間待たなければならないことほど、顧客にとって迷惑なことはほとんどありません。ピーク時の顧客の待ち時間を最小限に抑えるには、個々のテーブルのステータスを注意深く監視する必要があります。テーブルとスタッフの適切な管理がない場合、顧客の待ち時間は長くなり始めます。待ち時間が長すぎると、顧客は離れて、すぐにサービスを提供できる別のレストランを探す可能性があります。

    このデータモデルに特定の変更を導入することで、この懸念に対処できます。これらの変更は次のようになります:

    1. リアルタイムのテーブル管理を追加します。これは、テーブルの可用性、ステータストラッキング、使用率をデジタル化して管理する方法です。
    2. スタッフの効率を測定し、効果的な労働力計画を可能にすることで、テーブルの所要時間を短縮します。たとえば、清掃員を集めて、テーブルまたはテーブルのグループにスタッフを割り当てます。
    3. 個々のテーブルのリアルタイムのステータスをマネージャーの画面に公開して、マネージャーが保留中のアクティビティを監視できるようにします。

    もう一つの問題は、顧客に食べ物を待たせることです。食事をする顧客と持ち帰りの顧客の両方にとって、これは、食事をする人に直接ステータスの更新を提供することによって助けることができます。ここでは、個々のKOTのステータスを監視することが重要です。 KOTがキッチンで進行すると、そのステータスがKOT テーブル。このメカニズムにより、注文のステータスについて顧客にリアルタイムの更新が提供されます。




    このレストランのデータモデルを改善するにはどうすればよいですか?

    レストランのオーナーや運営者が顧客を引き付けて維持するために考え出している革新的なアイデアはたくさんあります。例:

    • 多くの場合、顧客ロイヤルティプログラムを実行します。これらは顧客のロイヤルティアカウントを維持し、訪問や購入などごとにゲストにポイントを提供します。ダイナーは、さまざまな報酬(通常、無料の食事、小切手のパーセンテージ、または無料の食事)を好きなときに、これらのポイントを現金化できます。 。
    • 一部の飲食店では、メニュー項目を可能な限りカスタマイズ可能にしています。サラダやパスタの材料を選択したり、特定の食事制限を満たすために食品を代用したりすることができます。

    在庫管理は、レストランを収益性の高いものにする上で重要な役割を果たすもう1つの分野です。

    これらの機能をこのデータモデルに組み込むことはできますか?以下のコメントセクションであなたの考えを共有してください。


    1. PDOException「ドライバーが見つかりませんでした」

    2. Oracle:重複するキーの更新について

    3. SQL Server 2016:データベースを復元する

    4. MariaDB DATABASE()の説明