販売データを適切に保存し、後でそれを組み合わせると、高精度の予測モデルを作成できます。この記事と次のいくつかの記事では、売上を記録するためのデータベース設計を分析します。
誰もが何かを売って生きています。
Robert Louis Stevenson
今日の世界では、製品の販売 どこにでもあります。また、履歴データを活用して傾向を分析し、それに応じて企業がビジネス戦略を調整できるようにする堅牢なツールにアクセスできる営業担当者は、競合他社よりも有利です。会社の業績に影響を与える可能性のあるパラメータはたくさんあります。現在の世界経済の状況、クライアントの場所、年齢、物質的および結婚歴、以前の連絡先やクライアントへの販売の履歴などです。
非常に簡単な例から始めましょう。コーヒーショップでの販売用のデータベースモデルです。 。以降の記事では、モデルを他の支店での製品の販売にも拡張します。
販売モデル
この記事では、他の部分が欠落している販売データを含むモデルの一部のみを分析します。
不足しているテーブルへの接続はまだあります。次がテーブルのsale に対して正しいと仮定して、モデルをブラックボックスと見なします。
:
-
user_has_role_id
user_has_roleのidを参照してください
(以前の記事の「追加された時間コンポーネント」のセクションで示したように)販売記録を作成したユーザーに関する情報を保存します
このモデルにより、複数のアイテムを含む販売レコードを作成できます。各アイテムは、カタログの製品に関連しています。セールを生成する瞬間は、セールが支払われる瞬間とは異なる場合があります。たとえば、一杯のコーヒーの場合、これらの瞬間は数分または数時間で異なります。当店が通信機器を販売している場合、その差は数日、場合によっては数か月になる可能性があります。
テーブル
テーブルの定義を見て、属性の目的と使用法を説明しましょう。
モデルで最も重要なテーブルはproduct
。これは、クライアントに提供する製品の詳細を保存するために使用されます。製品は通常、クライアントに配達され、通常は配達時に一度だけ支払われます。また、製品は通常、車、電話、砂糖のパッケージ、コーヒーのカップなどの物理的なオブジェクトです。
次の記事では、非物理的なもの(サービス)の販売について説明します。
製品の属性
表は次のとおりです:
名前コード> –システム内の製品の名前
-
price_per_unit
–ユニットあたりの製品のコスト(たとえば、コーヒー1杯は1.8ユーロ、車1台は17,500ユーロ、米1 kgは2ユーロ) -
basic_unit
–商品を販売する際の基本単位(例:ピース、kg、リットル) -
tax_percentage
–税金として請求されるprice_per_unitのパーセント。税率はすべての製品で同じではないと想定する必要があります 制限付き
–このフィールドは、在庫が限られている場合はTrueに設定され、それ以外の場合はFalseに設定されます(たとえば、店舗に必要な数量をディストリビューターに注文できます)-
in_stock
– limit =Trueの場合、この属性は販売可能な数を示します -
active_for_sale
–この属性がFalseであり、現在その製品を販売していない場合、それ以外の場合はクライアントに提供できます
次のクエリを使用して、クライアントに提供できる製品のリストを取得できます。
SELECT product.id, product.price_per_unit, product.basic_unit, product.limited, product.in_stock FROM product WHERE product.active_for_sale = True AND (product.limited = False OR (product.limited = True and product.in_stock > 0))
テーブルsale_status
は、販売がシステムで持つことができるすべてのステータスを含む単純な辞書です(たとえば、「領収書が発行されました」、「領収書が支払われました」)。
テーブル
販売
このモデルで2番目に重要なテーブルです。これまでのところ、この表は、私たちが製品を販売したクライアントとは関係がありません。これは、コーヒーショップの例では、そのような情報を知る必要がないためです。パート2では、このような場合をカバーするようにモデルを拡張します。 表の属性とその意味は次のとおりです。
-
time_created
–システムで販売レコードが生成された時間(たとえば、コーヒーショップでコーヒーの販売を生成したときにレコードが作成された自動時間、または必要に応じて手動で追加された時間) -
time_paid
–通常、一部の売上は作成後数日または1か月以内に支払われると予想できます(たとえば、ソフトウェアを提供して領収書を作成した場合、一部の国では、すべてが完了した場合、支払われるまで最大90日待つことができます。法律) -
sale_amount
–クライアントに請求する予定の元の金額 -
sale_amount_paid
–クライアントが実際に支払った金額。領収書を作成する時点では、この情報が常にあるとは限らないため、nullになる可能性があります -
tax_amount
–その領収書のアイテムのすべての税額の合計 -
sale_status_id
–sale_statusへの参照
テーブル -
user_has_role_id
–ユーザーとユーザーがシステムにレシートを入力した時点でのユーザーの役割への参照
次のようなクエリを使用して、一定期間内に発行および支払われた金額(time_createdによる)を取得できます。
SELECT SUM(sale.sale_amount) AS amount_issued, SUM(sale.sale_amount_paid) AS amount_paid FROM sale WHERE sale.time_created >= @start_time AND sale.time_created <= @end_time;
一定期間内に支払われる正確な金額を取得するには、次のようなクエリを使用する必要があります:
SELECT SUM(sale.sale_amount_paid) AS amount_paid FROM sale WHERE sale.time_paid >= @start_time AND sale.time_paid <= @end_time;
以下のクエリでは、発行日と支払い日を別々にチェックして、一定期間内の発行額と支払い額を計算します。
SELECT SUM(CASE WHEN sale.time_created >= @start_time AND sale.time_created <= @end_time THEN sale.sale_amount END) AS amount_issued, SUM(CASE WHEN sale.time_paid >= @start_time AND sale.time_paid <= @end_time THEN sale.sale_amount_paid END) AS amount_paid FROM sale
すべての例で @start_time
および@end_time
発行済みおよび支払済みのSUMを確認する期間の開始時刻と終了時刻を含む変数です。
テーブルsale_item
製品と販売をつなぐ。もちろん、複数のアイテムがあると想定する必要があります 1つの領収書に記載されているため、このテーブルには多対多の関係が必要です。
属性とその意味は次のとおりです。
-
Quantity_sold
–販売され、その販売/領収書に請求される製品の数量(例:コーヒー3杯) -
price_per_unit
–product.price_per_unit
と同じ値 セールが作成された瞬間。price_per_unit
なので、保存する必要があります製品
テーブルは時間の経過とともに変化する可能性があります 価格
–Quantity_sold
の製品 およびprice_per_unit
;クエリでこの計算を回避するのに役立つ小さな冗長性。通常、同じセールに属するすべてのアイテムの価格の合計は、sale.sale_amount
と等しくなければなりません。-
tax_amount
–受領時のそのアイテムの税額 -
sale_id
–このアイテムが属する販売ID -
product_id
–このアイテムに関連する商品ID
これで、期間中に販売した製品/サービスの数と価格を簡単にレポートできるようになりました。
SELECT product.name, SUM(sale_item.quantity_sold) AS quantity, SUM(sale_item.price) AS price FROM sale, sale_item, product WHERE sale.id = sale_item.sale_id AND sale_item.product_id = product.id AND sale.time_created >= @start_time AND sale.time_created <= @end_time GROUP BY product.id