食料品配達データモデル

オンラインで食料品を注文する方法がある場合は、それを使用してみませんか？この記事では、食料品店の配送システムの背後にあるデータモデルについて説明します。

庭から何かを選んですぐに準備することで、今でも特別な気持ちになりますが、それは私たちが頻繁にできることではありません。今日の速いペースではそれができません。実際、店に行って食料品を「選ぶ」ことができない場合もあります。したがって、時間を節約し、アプリを使用して必要なものを注文することは理にかなっています。私たちの注文は私たちの家に表示されます。特別な採れたての気分にはならないかもしれませんが、テーブルには食べ物があります。

このようなアプリケーションの背後にあるデータモデルは、今日の記事のトピックです。

食料品配達データモデルには何が必要ですか？

このモデルの考え方は、アプリケーション（Web、モバイル、またはその両方）を使用して、登録済みの顧客が注文を作成できるようにすることです（当店の製品で構成されています）。その後、この注文は顧客に配信されます。明らかに、これをサポートするために顧客データと利用可能なすべての製品のリストを保存します。

顧客は、さまざまなアイテムをさまざまな数量で含む複数の注文を行うことができます。顧客の注文を受け取ったら、店舗の従業員に通知して、必要なアイテムを見つけて梱包できるようにする必要があります。（これには1つ以上のコンテナが必要になる場合があります。）最後に、コンテナは一緒にまたは別々に配送されます。

アプリ自体では、顧客と従業員は、配達が行われた後、メモを挿入して相手を評価できる必要があります。

データモデル

データモデルは、次の3つのサブジェクト領域で構成されています。

アイテムとユニット
顧客と従業員
注文

各サブジェクトエリアは、リストされている順序で表示されます。

セクション1：アイテムとユニット

アイテムとユニットから始めましょう サブジェクトエリア。モデルのごく一部ですが、2つの非常に重要なテーブルが含まれています。

ユニット テーブルには、在庫内のアイテムに割り当てるユニットに関する情報が格納されます。このテーブルの値ごとに、2つのUNIQUE値を格納します： unit_name （例：「キログラム」）および unit_short （例：「kg」）。 unit_shortに注意してください unit_nameの略語です。。

このサブジェクトエリアの2番目のテーブルはitem 。在庫にあるすべてのアイテムが一覧表示されます。アイテムごとに、以下を保存します：

item_name –そのアイテムに使用する一意の名前。
価格 –そのアイテムの現在の価格。
item_photo –このアイテムの写真へのリンク。
説明 –アイテムの追加のテキストによる説明。
unit_id –ユニットを参照します 辞書であり、そのアイテムの測定に使用される単位を示します。

ここではいくつか省略していることに注意してください。最も重要なものは、在庫アイテムが現在売りに出されているかどうかを示すフラグです。なぜこれを持っていないのですか？少なくとも1つの追加フィールド（フラグ）と別のテーブル（各アイテムの履歴変更を保存するため）が必要になります。簡単にするために、在庫にあるすべてのアイテムも販売可能であると想定しました。

私が省略した2番目に重要なことは、倉庫のステータスを追跡することです。私の想定では、すべてを1つの中央倉庫から発送し、常に利用可能なアイテムを用意します。アイテムがない場合は、お客様に通知して、同様のアイテムを交換して提供します。

セクション2：顧客と従業員

顧客と従業員 サブジェクト領域には、顧客および従業員のデータを格納するために必要なすべてのテーブルが含まれています。この情報は、モデルの中心部分で使用します。

従業員 表には、関連するすべての従業員（食料品の包装業者や配達員など）のリストが含まれています。従業員ごとに、 first_nameを保存しますおよびlast_name および一意のemployee_code 価値。 id列もUNIQUE（およびこのテーブルの主キー）ですが、従業員IDとして別の実際の値（VAT番号など）を使用することをお勧めします。したがって、 employee_codeがあります。フィールド。

従業員のログインの詳細、従業員の役割、および役割の履歴を追跡する方法を含めていないことに注意してください。この記事で説明されているように、これらは簡単に追加できます。

次に、モデルに顧客を追加します。これにはさらに2つのテーブルが必要です。

顧客は地理的にセグメント化されるため、都市が必要になります 辞書。食料品の配達を提供する都市ごとに、 city_nameを保存しますおよびpostal_code 。これらが一緒になって、このテーブルの代替キーを形成します。

顧客は間違いなくこのモデルの最も重要な部分です。彼らはプロセス全体を開始するものです。お客様の完全なリストをcustomerに保存します テーブル。お客様ごとに、以下を保存します：

first_name –顧客の名。
last_name –顧客の名前。
user_name –アカウントの設定時に顧客が選択したユーザー名。
パスワード –顧客がアカウントを設定するときに選択したパスワード。
time_inserted –このレコードがデータベースに挿入された瞬間。
confirmation_code –登録コード中に生成されたコード。このコードは、メールアドレスを確認するために使用されます。
time_confirmed –電子メールによる確認が行われたとき。
contact_email –確認メールとしても使用される顧客のメールアドレス。
contact_phone –顧客の電話番号。
city_id –都市のID 顧客が住んでいる場所。
アドレス –お客様の自宅の住所。
delivery_city_id –都市のID 顧客の注文をどこに配達するか。
delivery_address –優先配送先住所。これは、顧客の自宅の住所と同じにすることができます（ただし、同じである必要はありません）。

セクション3：注文

このモデルの中心的で最も重要な部分は、注文です。 サブジェクトエリア。ここでは、注文を行い、顧客に配達されるまでアイテムを追跡するために必要なすべてのテーブルを確認できます。

プロセス全体は、顧客が注文したときに始まります。これまでに行われたすべての注文のリストは、 placed_orderにあります テーブル。 orderはSQLで予約されているキーワードであるため、「order」ではなく、意図的にこの名前を使用しました。注文ごとに、以下を保存します：

customer_id –顧客のID この注文を出しました。
time_placed –この注文が行われたときのタイムスタンプ。
詳細 –その順序に関連するすべての詳細（構造化されていないテキスト形式）。

   delivery_city_id  –   cityへの参照  この注文の配送先。
   delivery_address  –この注文の配送先住所。
   grade_customer  ＆ grade_employee  –注文完了後に従業員と顧客から与えられた成績。その瞬間まで、この属性にはNULL値が含まれています。顧客の成績は、彼らが私たちのサービスにどれほど満足していたかを示します。従業員の成績は、顧客が次に注文するときに何を期待するかについての情報を提供します。

 
 注文の過程で、顧客は1つ以上のアイテムを選択します。アイテムごとに、必要な数量を定義します。各注文に関連するすべてのアイテムのリストは、  order_itemに保存されます  テーブル。このテーブルのレコードごとに、関連する注文のID（ Placed_order_id ）を保存します ）、アイテム（ item_id  ）、希望する数量、および price  この注文が行われたとき。
 
 何に加えて 配達を希望する場合、顧客は希望する配達時間も定義します  。注文ごとに、  deliveryに1つのレコードを作成します  テーブル。これにより、 delivery_time_plannedが記録されます 追加のテキストメモを挿入します。  Placed_order_id  このレコードが挿入されるときに、属性も定義されます。残りの2つの属性は、その配信を従業員に割り当てるときに定義されます（ employee_id  ）および注文が配達された日時（ delivery_time_actual  。
 
 注文ごとに1回の配達しかないように見えるかもしれませんが、常にそうであるとは限りません。注文ごとに2つ以上の配信が必要になる場合があります。それが、配信データを新しいテーブルに配置することを選択した主な理由です。
 
 注文の処理を開始すると、従業員は1つ以上のボックスにアイテムを梱包します。各ボックス   box_codeによって一意に定義されます 配信に割り当てられます（ delivery_id  ）。その箱を用意した従業員のIDも保存します。
 
 各ボックスには、1つ以上のアイテムが含まれます。したがって、  item_in_box   テーブルには、ボックスへの参照を保存する必要があります  テーブル（ box_id  ）および  item   テーブル（ item_id  ）、およびそのボックスに配置された数量。最後の属性、 is_replacement  、は、アイテムが別のアイテムの代替品であるかどうかを示します。交換品を箱に入れる前に、従業員が顧客に連絡することが期待できます。そのアクションの結果の1つは、顧客が交換アイテムに同意することです。もう1つは、注文全体をキャンセルすることです。
 
 モデルの残りの3つのテーブルは、ステータスとコメントに密接に関連しています。
 
 まず、考えられるすべてのステータスを  status_catalogに保存します  。各ステータスは、その status_nameによって一意に定義されます 。 「注文作成済み」、「注文済み」、「アイテムパック済み」、「輸送中」、「配達済み」などのステータスが期待できます。
 
 ステータスは、自動（プロセスの一部が完了した後）または場合によっては手動（注文に問題がある場合など）のいずれかで注文に割り当てられます。利用可能なすべての注文ステータスは、  order_statusに保存されます  テーブル。 2つのテーブルからの外部キーに加えて（  status_catalog   およびplaced_order   ）、このステータスが割り当てられたときの実際のタイムスタンプを保存します（ status_time  ）および追加の詳細 テキスト形式で。 
 
 このモデルのファイナルテーブルはnotes   テーブル。このテーブルの背後にある考え方は、特定の注文（ Placed_order_id ）に関連するすべての追加コメントを挿入することです。 ）。コメントは、従業員または顧客が挿入できます。レコードごとに、 employee_idの1つだけ またはcustomer_id フィールドには値が含まれます。もう1つはNULLになります。このメモがシステムに挿入された瞬間を保存します（ note_time  ）および note_text  。
 食料品配達データモデルにどのような変更を加えますか？
 
 今日は、顧客と従業員の両方の観点から、Webおよびモバイルの食料品配達アプリをサポートできるデータモデルについて説明しました。この記事ですでに述べたように、このモデルを改善する方法はたくさんあります。お気軽にご提案ください。このモデルに何を追加するか、モデルから削除するかを教えてください。または、この構造をまったく異なる方法で編成することもできます。コメントセクションでお知らせください！