結婚式の組織のデータモデル

結婚式は多くの場合、多くのゲスト、食べ物、飲み物、音楽、そしてダンスで、歓喜とお祝いを伴います。しかし、これはすべて、適切な準備と調整なしには実現できません。すべてがスムーズに実行されるように、データモデリングが結婚式の整理にどのように役立つかを詳しく見てみましょう。

予備的背景

典型的な結婚式がどのようなものかはほとんどの人が知っていますが、データモデルに影響を与える可能性のあるいくつかの側面を簡単に検討することは害にはなりません。

結婚式のパートナー

ほとんどの伝統的な文化では男性と女性の間で儀式が行われますが、他の社会でも同性結婚が行われます。私たちのデータモデルは、すべての可能性に対応できるように設計する必要があります。

規模と複雑さ

結婚式は、そのサイズ、期間、および複雑さで大きく異なります。小規模で控えめな機会もあれば、壮大なお祝いもあります。たとえば、クロアチアでは、カップルが市庁舎で結婚し、ゲストの前で指輪と誓いを交換し、式典後の夕食に出席するか、家に帰るという簡単な結婚式を行うことができます。他の国では、結婚式は非常に手の込んだものになる可能性があります。結婚式には、独身最後のパーティー、交渉、夕食、複数の式典などが含まれる場合があります。場合によっては、これらの儀式は数日間続き、いくつかの異なる場所で行われることがあります！繰り返しになりますが、これらの状況を処理するためにデータモデルを準備する必要があります。

最終的な結果と費用

ほとんどの場合、カップルはお祝いの後に結婚し、すべての費用（家賃、飲食、バンドなど）の請求書を受け取ります。彼らは、これらすべての費用を自分たちで処理するために代理店を雇うことを決定するかもしれませんし、あるいは彼ら自身でそれをすべて処理することを選択するかもしれません。いずれにせよ、これらの状況を説明する必要があります。

データモデル：概要

この記事のデータモデルは、次の5つのセクションで構成されています。

場所
パートナー、製品、およびサービス
結婚式
参加者
請求書

これらの各領域について、上記の順序で徹底的に説明します。データモデルの開発に取り組む際、結婚式を主催する代理店の役割を引き受けます。

セクション1：場所

Locations セクションには、他の多くのデータモデルで使用できるユニバーサルテーブルがあります。先に述べたように、結婚式全体が1つの場所で行われることもあれば、複数の場所にまたがる可能性もあります。このセクションの表について詳しく説明しましょう。

country テーブルには、結婚式が行われる国に関する情報が格納されます。ほとんどの場合、この国は私たちの代理店の場所と一致しますが、私たちが国際的に活動している場合はそうではないかもしれません。この表の各国は、そのcountry_nameによって一意に定義されています。。

次に、結婚式が開催されるすべての町や村のリストを保存する必要があります。この情報はcity テーブル。都市ごとに、名前と郵便番号、および都市が所在する国を保存します。

このサブジェクトエリアの最後のテーブルはlocation 。場所は、市庁舎、教会、公園など、より具体的です。場所ごとに、その名前とその場所が存在する都市のIDへの参照を保存します。これら2つの属性の組み合わせにより、このテーブルの一意のキーが形成されます。

場所については、電車や飛行機などで式典が行われるという珍しいケースをカバーしないように、ここでは控えめなアプローチを取っていることに注意してください（この場合、「場所」には複数の都市が含まれる場合があります）。これらのケースをカバーしたい場合は、モデルにいくつかの変更を加える必要があります。

セクション2：パートナー、製品、およびサービス

データモデルの中心部分に進む前に、協力しているすべてのパートナーのリストと、それらが提供する製品とサービスを保存する必要があります。これを実現するために、5つのテーブルを使用します。

まず、提携しているすべてのパートナーのリストがpartner 辞書。パートナーごとに、固有のpartner_codeを保存しますおよびpartner_name 。

もちろん、私たちのパートナーは、ケータリング、バンドの整理、オーディオおよびビデオ機器のセットアップ、家賃サポートの提供など、結婚式関連のサービスを提供します。基本的に、あなたが考えることができるものはすべて、何らかの形で結婚式に関連している可能性があります。このサービスのリストをservice 辞書。サービスごとに、以下を保存します：

service_code –特定のサービスを一意に示すために内部で使用する値。
service_name –サービスの名前。異なるサービスが同じ名前を共有する可能性があることに注意してください。これは、2人のパートナーがたまたま同じサービスを提供している場合に発生します。同じサービスタイプに同じ名前を使用すると、同じサービスの価格を比較しやすくなるため、さらに望ましいでしょう。
description –サービスのオプションのテキストによる説明。
picture –関連するサービス画像が保存されている場所へのリンク。
price –このサービスの現在の価格。式典に出席する予定の人数など、さまざまな要素を最初に評価せずに価格を決定できない場合は、NULLの値を含めることができます。

provides_service 表は、パートナーが提供するサービスのリストに関連しています。 partner_idの一意の組み合わせごとにおよびservice_id 、パートナーが提供するサービスの性質と、サービスが現在利用可能かどうかの詳細なテキストによる説明を保存します。

また、製品とそのパートナーとの関係に関する情報を保存するためのテーブルも必要です。 product テーブルはservice ただし、名前が示すように、製品に固有のものです。この表には、指輪、衣装、装飾品、花、家具など、ほとんどの結婚式に欠かせないすべての可能な製品が格納されています。

このセクションの最後の表は、provides_product テーブル。 provides_service 表。ただし、サービスではなく製品に固有のものです。問題の製品を提供しているパートナーを指定します。

セクション3：結婚式

ついにデータモデルの中心であるWeddingsにたどり着きました。セクション。他のセクションのテーブルを参照する5つの新しいテーブルが含まれています。このセクションの独自のテーブルは、モデルの今後の部分でも参照されることに注意してください。

wedding 表には、私たちが組織している/関与したすべての結婚式の完全なリストが保存されます。結婚式ごとに独自のwedding_codeが割り当てられます。セレモニー全体の予定された開始時間と終了時間も保存し、この情報が利用可能になるたびに実際の開始時間と終了時間を更新します。さらに、budget_plannedを保存します値なので、少なくともこれにかかる費用の見積もりがあります。結婚式に関連する他のすべての詳細はデータモデルの他の領域に保存されるため、今のところ本当に必要なのはこれだけです。

ここでのアイデアは、各結婚式を一連のイベントとして扱うことです。イベントは、希望する製品/サービスのオファー、拒否および承認されたオファー、およびその他の関連する詳細に関連します。これがどのように機能するかをよりよく理解するために、結婚式全体を次のイベントに分割することができます：計画段階、独身/独身パーティー、式典、およびアフターパーティー/ディナー。もちろん、これらは最も一般的な結婚式のイベントのほんの一部です。すべての結婚式のイベントは、イベントテーブルに保存されます。 event 一意のIDがあります。

各イベントは1つの結婚式に関連付けられており、1つの場所に関連付けられているか、まったく関連付けられていません。後者の場合は、イベントがより概念的である場合に発生します、計画フェーズなど（実行する必要のある単一の場所がないため）。実際の結婚式自体と同様に、イベントには計画された実際の開始/終了時間、および計画された予算があります。ここでは、場所に関して物事を単純にしていることに注意してください。イベントに複数の場所が含まれる場合は、データモデルを調整する必要があります。

次に、イベントに関連するすべてのサービスと製品を保存します。そのために、次の3つのテーブルを使用します：status 、product_included 、およびservice_included 。

status tableは、特定のイベントの製品およびサービスに関連するすべてのステータスを追跡する辞書です。これには、製品/サービスが提供されたか、受け入れられたか、拒否されたかを示すフラグ変数が含まれます。このテーブルのレコードごとに、一意のstatus_nameを保存します。

このセクションの残りの2つの表は、product_included およびservice_included 、構造的および概念的に互いに似ています。イベントごとに、提供された製品とサービスのリストを保存し、承認または却下された場合はステータスを変更します。これら2つのテーブルのレコードごとに、次の一般的な属性を保存します。

event_id –関連するイベントへの参照。
provides_product_id / provides_service_id –パートナーが提供している製品/サービスの表への参照。
price –製品/サービスの提案価格。この価格は、特別オファーを提案する場合、登録されている標準価格とは異なる場合があります。
current_status_id –status このレコードが提供されたか、受け入れられたか、拒否されたかを示す辞書。

セクション4：参加者

大規模な結婚式を企画している場合は、出席を計画しているほとんどのゲストに精通している可能性があります。もちろん、あなたが招待するゲストは、あなたの友人や親戚であっても、友人や同僚など、あなたが個人的に知らない他の人々を連れてくる可能性があります。このセクションでは、結婚式に招待されたゲストの完全なリストとその役割を保存します。

person 表には、結婚式に参加しているすべての個人のリストが含まれています。個人ごとに、固有のperson_codeを保存しますと姓名。もちろん、必要に応じて詳細を追加することもできます。

次に、結婚式中に引き受けることができるすべての可能な役割を定義します。これらの役割には、「ゲスト」、「ベストマン」、「花婿付け添人」、「花嫁介添人」、「花嫁」、「花婿」などが含まれます。役割ごとに、一意のrole_nameのみを保存しますこの表で。人は特定の結婚式のために1つの役割しか引き受けることができません。

次に、結婚式を参加者に関連付けます。 participate テーブルには、テーブルへの参照のみが含まれますwedding 、person 、およびrole 。 wedding_idの組み合わせおよびperson_id このテーブルの代替キーとして機能します。

結婚式はいくつかのイベントで構成されますが、すべての参加者がこれらに関与するわけではありません。したがって、この情報を個別に保存する必要があります。 in_event テーブルには、テーブルevent およびparticipate 。すべての追加情報はdetailsに保存されますテキスト属性。

セクション5：請求書

ほぼ完了です。データモデルの最後のセクションでは、結婚式に関連する費用を追跡できます。エキサイティングですよね？

通常、1つのinvoice 結婚式ごとですが、必要に応じてさらに生成することもできます。うまくいけば、私たちがカップルに請求する合計金額は、私たちの計画された予算とほぼ一致しますが、常にそうであるとは限りません。請求書ごとに、次の情報を保存します：

wedding_id –請求書が発行された結婚式への参照。
time_created –請求書が生成されたときのタイムスタンプ。
due_date –請求書の支払いが必要な日付。
invoice_amount –支払わなければならない合計金額。
payment_time –支払いが実際に発行されたときのタイムスタンプ。もちろん、支払いが行われるまで、この属性にはNULLの値が含まれます。
paid –請求書が支払われたかどうかを示すフラグ。この属性は、payment_timeがすぐに「True」に設定されます。更新されます。

モデルの最後の表は、請求されたアイテム自体に関するものです。これらはinvoice_item テーブル。レコードごとに、次の詳細を保存します：

item_name –特定のアイテムに選択した名前。
item_price –その特定のアイテムに関連する価格。
invoice_id –関連する請求書のID。
service_included_id –請求書アイテムが関連するサービスのID。問題のアイテムが実際にサービスに関連していない場合、または請求書に適用した単なる追加料金である場合は、この属性をNULLに設定できます。
product_included_id –請求書アイテムが関連する製品のID。問題のアイテムが実際にどの商品にも関連していない場合、または請求書に適用した単なる追加料金である場合は、この属性をNULLに設定できます。

概要

これは、このデータモデルの要約です。繰り返しになりますが、企業の情報を整理する上でデータモデリングがいかに有用であるかがわかります。

すでに述べたように、簡単にするためにデータモデルから省略したものがたくさんあります。たとえば、私たちのモデルは、理想的にはオファー履歴、財務詳細などを追跡する必要があります。

何か提案があれば、以下にお知らせください。ご意見をお聞かせください。