休日が近づいている今、サンタは世界中の子供たちにプレゼントを届けるためにいくつかの追加の助けを必要としています。今日は、サンタと彼のエルフがより効率的に作業するのに役立つデータモデルを開発します。
背景
サンタさんの仕事は非常に重要なので、時間どおりに成功するためにできる限りのことをする必要があります。ハワードが「ジングルオールザウェイ」で1つのターボマンのフィギュアを見つけようとしたときに遭遇したすべての問題を覚えておいてください。サンタを再び滑らせることはできません。そうしないと、サンタの評判が台無しになります。そこで、サンタさんの整理整頓を支援するために、サンタさんの活動を3つの主要なフェーズに分けます。
-
計画
まず、サンタはすべてを計画する必要があります。結局のところ、彼はエルフが何十億もの配達を理解しようとしているので、工場を走り回ってパニックに陥ることはできません。今年の手紙を読んで子供たちがどのような贈り物を望んでいるかを判断するだけでなく、前年度の傾向を分析して、いくつかの一般的な資料を収集したり、事前に贈り物を作成したりする必要があります。これにより、本番環境での作業を開始する際のバックログの一部を減らすことができます。
-
生産
計画段階の後、プレゼントの作成を開始する準備が整いました。サンタのエルフの助けを借りて、受け取ったウィッシュリストに従ってプレゼントをすばやく製造してパッケージ化することができます。ただし、プロセスをより効率的にするには、手元にあるすべての資料と情報を整理して、エルフが必要なものをできるだけ早く入手できるようにする必要があります。
-
配信
その瞬間がすぐに近づいています!サンタさんのトナカイはすべて揃っており、男自身が心配そうに時計をチェックしています。プレゼントはサンタさんのヘルパーによってそりにすぐに積み込まれています。この時点で、サンタは自分のスケジュールを最後に見て、すべての正しい住所と、考慮する必要のあるメモがあることを確認します。
使用する必要のある情報の種類について少し背景がわかったので、ようやくサンタのデータモデルの設計を開始できます。
データモデル
このデータモデルは、次の3つのセクションで構成されています。
- アイテム
- 人とウィッシュリスト
- 配信
これらのそれぞれを詳しく見てみましょう。
セクション1:アイテム
データモデルは、残りの2つのセクションの中心となる多くのテーブルを含むアイテムセクションから始まります。
item_type
テーブルは間違いなくここで最も重要なものです。この表には、サンタさんの工場で生産する必要のあるすべてのアイテムのリストが含まれています。アイテムごとに、次の情報を保存します:
-
item_name
—アイテムの名前。 プロパティ
—構造化された形式で保存され、作成されたアイテムのサイズ、形状、色、およびその他のプロパティを示すテキストのキーと値のペア。説明
—アイテムの構造化されていないテキストによる説明。
色など、一部のプロパティのみが異なる2つの類似したアイテムがある場合は、先に進み、それらを個別のレコードとしてテーブルに保存します。
データモデルの目的上、サンタはギフトを購入せず、代わりにエルフにすべてを家で生産するように命じると仮定します。アイテムの種類ごとに、満たす必要のある前提条件のリストがあります。これらは、労働力または木材、プラスチック、金属、塗料などの材料である可能性があります。考えられるすべての前提条件のリストを保存し、それらを作成する必要のある各アイテムに関連付ける必要があります。これを実現するために4つのテーブルを使用します。
これら4つのテーブルの最初は、前提条件です。
、名前が示すように、すべての可能な前提条件のリストを格納します。このテーブルのレコードごとに、一意の前提条件名、すべての追加のプロパティ
を保存します (今回は非構造化形式で)、および prerequisite_type
への参照 とユニット辞書。 prerequisite_type
辞書は、「労働」や「材料」など、すべての前提条件カテゴリのリストを格納するために使用されます。 ユニット
辞書は、前提条件を定量化するために使用するすべてのユニットのリストを格納するために使用されます。たとえば、労働力は時間または分で測定され、材料は生産コスト(ドル)、重量(キログラム)、または体積(リットル)で測定されることが期待できます。
このセクションの最後の表は、ウェアハウスです。
、これを使用して、アイテムと材料の両方の在庫の現在のステータスを追跡します(したがって、 item_type_id
およびprerequisite_id
外部キー)。これらの2つのキーのうち、任意の時点で値が含まれるのは1つだけです。これらのキーに加えて、最終的な数量
を保存します 特定のwarehouse_date
で利用可能でした 。
セクション2:人とウィッシュリスト
私たちのデータモデルの重要な部分であるこのセクションでは、子供たちがクリスマスツリーの下で見つけたいものを扱います。右から左に作業します。
右端の2つのテーブルはcountry
およびcity
。サンタさんに願い事リストを送った子供の場所を参照するときに、これら2つの表を使用します。 国
テーブルには、一意の country_name
のみが含まれます 属性と既存のすべての国
のリスト 。場所をより正確にするために、 cityを使用します
サンタが訪れる必要のあるすべての都市を保存するためのテーブル。この表の各都市について、以下を保存します:
-
city_name
—都市の名前。必ずしも一意ではありません。 -
postal_code
—市の郵便番号。 -
country_id
—都市が存在する国のID。前の2つの属性とともに、これはこのテーブルの一意のキーを形成します。 緯度
およびlongitude
—サンタが地図上で都市を見つけるのを助けたり、サンタが使用するナビゲーションシステムにその座標を入力したりするために使用されます。
もちろん、人がいなければ願い事はありません!すべての人のリストを人に保存します
テーブル。個人ごとに、 first_name
を保存します 、 last_name
、 birth_date
、および city
。また、その人の住所と、追加の delivery_details
も保存します。 サンタは考慮する必要があるかもしれません(人が煙突を持っていないことを示すメモなど)。
このセクションの最後の表には、完全な wish_listが含まれています。
これまでに作られたすべてのクリスマスの願いを保存します。それぞれの願いについて、私たちは知る必要があります:
-
person_id
—願い事をした人への言及。 -
item_type_id
—その人が要求したアイテム(タイプ)への参照。 数量
—ウィッシュで指定されたアイテムの希望数量。詳細code> —サンタが願いを叶えるのに役立つすべての詳細。
-
ts
—ウィッシュがシステムに保存された瞬間を示します。これは、ウィッシュが作成された年を決定するために重要です。 -
gift_id
—この願いを叶えるために配達されたギフトを示すギフトテーブルへの参照。
セクション3:配信
これで、データモデルの最も興味深い部分であるギフトと配達にようやく到達しました。
単一のアイテムが作成されたら、関連するレコードをアイテムに挿入します
テーブル。アイテムが作成されても、ギフトには割り当てられないため、 gift_id
アイテムが特定のギフトに関連付けられるまで、属性にはnullの値が含まれます。作成されたアイテムのタイプ( item_type_id
)も保存する必要があります )、およびその数量
。アイテムの数量はほとんど1ですが、特別な場合には異なる数量が予想されます(たとえば、複数のアイテムが1つのセットにまとめられている場合、これは非常に珍しいことですが、それでも可能です)。
次に、1つ以上のアイテムを組み合わせて、ギフトを作成します。
。 item.gift_id
を更新します 選択したアイテムをそのギフトに詰めたら。各ギフトは、関連する人物( person_id
)に配信されます )、追跡ステータス( current_status_id
)、およびサンタがギフトを配達する予定のタイムスタンプ( delivery_time_planned
)。 wish_list.gift_id
の値も更新します 正常に配信されたすべてのアイテムの属性。
このデータモデルの最後の2つのテーブルは、配信ステータスの追跡に関するものです。まず、ステータス
テーブルには一意のstatus_name
が含まれています gftの現在のステータスを参照するときに使用する値( gift.current_status_id
)。さらに、 status_history
テーブルには、データベース内のすべてのギフトのすべてのステータスのリストと、すべてのステータス更新のタイムスタンプ(ts)が格納されます。
うまくいけば、私たちのデータモデルは、サンタがもう1年の配達を成功させるのに役立ち、私たち全員が時間どおりにプレゼントを受け取ることができるようになります。クリスマスをテーマにしたSQLをもっと楽しみたい場合は、VertabeloAcademyが特別な24クエリのホリデーチャレンジを用意しています。どうぞチェックしてください! Vertabeloファミリーを代表して、素晴らしいクリスマスをお過ごしください。