Modellierung einer Datenbank zur Erfassung von Verkäufen. Teil 1

Die richtige Speicherung von Verkaufsdaten und deren spätere Kombination kann zur Erstellung eines Vorhersagemodells mit hoher Genauigkeit führen. In diesem und den nächsten Artikeln analysieren wir ein Datenbankdesign zur Erfassung von Verkäufen.

Jeder lebt davon, etwas zu verkaufen.

Robert Louis Stevenson

In der heutigen Welt Produkte verkaufen ist allgegenwärtig. Und Vertriebsmitarbeiter, die Zugang zu robusten Tools haben, die historische Daten nutzen, um Trends zu analysieren und es einem Unternehmen ermöglichen, Geschäftsstrategien entsprechend anzupassen, haben einen Vorteil gegenüber ihren Konkurrenten. Es gibt viele Parameter, die sich auf die Unternehmensergebnisse auswirken können:die aktuelle globale Wirtschaftslage, der Standort der Kunden, das Alter, der materielle und Familienstand und die Geschichte früherer Kontakte oder Verkäufe an Kunden.

Wir beginnen mit einem sehr einfachen Beispiel:einem Datenbankmodell für Verkäufe in einem Café . In nachfolgenden Artikeln erweitern wir das Modell auf den Verkauf von Produkten in anderen Branchen.

Verkaufsmodell

In diesem Artikel analysieren wir nur einen Teil des Modells, der Verkaufsdaten enthält, während andere Teile fehlen.

Wir haben immer noch Verbindungen zu fehlenden Tabellen und betrachten das Modell als Blackbox, wobei wir davon ausgehen, dass Folgendes für die Tabelle sale :

• user_has_role_id beziehen Sie sich auf die ID in user_has_role (wie in meinem vorherigen Artikel im Abschnitt „Zeitkomponente hinzugefügt“) und speichert Informationen über den Benutzer, der den Verkaufsdatensatz erstellt hat

Dieses Modell ermöglicht es uns, Verkaufsaufzeichnungen mit mehreren Artikeln zu erstellen. Jeder Artikel bezieht sich auf ein Produkt aus unserem Katalog. Der Moment, in dem wir einen Verkauf generieren, kann sich von dem Moment unterscheiden, in dem der Verkauf bezahlt wird. Bei einer Tasse Kaffee zum Beispiel unterscheiden sich diese Momente innerhalb von Minuten oder Stunden. Wenn unser Shop Telekommunikationsgeräte verkauft hat, kann der Unterschied einige Tage, vielleicht sogar Monate betragen.

Tabellen

Werfen wir einen Blick auf die Tabellendefinition und erläutern den Zweck und die Verwendung von Attributen.

Die wichtigste Tabelle im Modell ist product . Es wird verwendet, um Details zu Produkten zu speichern, die wir unseren Kunden anbieten. Produkte werden normalerweise an einen Kunden geliefert und einmalig bezahlt, normalerweise zum Zeitpunkt der Lieferung. Außerdem sind Produkte in der Regel physische Objekte wie Autos, Telefone, Zuckerpackungen oder Kaffeetassen.

Wir werden in den nächsten Artikeln über den Verkauf von nicht-physischen Dingen (Dienstleistungen) sprechen.

Attribute im product Tabelle sind:

• name – der Name des Produkts im System
• price_per_unit – Produktkosten pro Einheit (z. B. 1 Tasse Kaffee kostet 1,8 Euro, 1 Auto kostet 17.500 Euro, 1 kg Reis kostet 2 Euro)
• basic_unit – Basiseinheit, wenn wir ein Produkt verkaufen (z. B. Stück, kg, Liter)
• tax_percentage – Prozent des als Steuer zu erhebenden Preises pro Einheit. Wir müssen davon ausgehen, dass der Steuerprozentsatz nicht für alle Produkte gleich wäre
• limited – Dieses Feld ist auf True gesetzt, wenn wir eine begrenzte Menge auf Lager haben, andernfalls auf False (z. B. können wir jede Menge, die wir für unseren Shop benötigen, bei einem Händler bestellen)
• in_stock – Wenn limited=True zeigt dieses Attribut an, wie viele wir zum Verkauf haben
• active_for_sale – Wenn dieses Attribut falsch ist, bieten wir dieses Produkt derzeit nicht zum Verkauf an, andernfalls können wir es Kunden anbieten

Mit der folgenden Abfrage können wir eine Liste der Produkte abrufen, die wir unseren Kunden anbieten können:

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))

Die Tabelle sale_status ist nur ein einfaches Wörterbuch, das alle Status enthält, die ein Verkauf im System haben kann (z. B. „Kassenbon ausgestellt“, „Kassenbon bezahlt“).

Attribute in der Tabelle und ihre Bedeutung sind:

• time_created – Zeitpunkt, zu dem ein Verkaufsdatensatz im System generiert wurde (z. B. automatischer Zeitpunkt, zu dem der Datensatz erstellt wurde, als wir einen Verkauf für Kaffee in unserem Café generierten, oder ein manuell hinzugefügter Zeitpunkt, wenn wir dies wünschen)
• time_paid – Im Allgemeinen können wir davon ausgehen, dass einige Verkäufe innerhalb weniger Tage oder sogar eines Monats nach der Erstellung bezahlt werden (z. B. wenn wir Software liefern und eine Quittung erstellen, können wir in einigen Ländern bis zu 90 Tage auf die Zahlung warten, wenn alles klappt das Gesetz)
• sale_amount – ursprünglicher Betrag, der dem Kunden in Rechnung gestellt werden soll
• sale_amount_paid – Betrag, den der Kunde tatsächlich bezahlt hat. Es kann null sein, da wir im Moment, in dem wir einen Beleg erstellen, diese Informationen nicht immer haben
• tax_amount – Summe aller Steuerbeträge für Artikel auf diesem Beleg
• sale_status_id – Verweis auf sale_status Tabelle
• user_has_role_id – Verweis auf den Benutzer und seine Rolle zum Zeitpunkt der Eingabe des Belegs in das System

Wir können den ausgestellten und bezahlten Betrag (gemäß time_created) innerhalb eines bestimmten Zeitraums mit einer Abfrage wie dieser abrufen:

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;

Um den genauen gezahlten Betrag innerhalb eines bestimmten Zeitraums zu erhalten, müssen wir eine Abfrage wie diese verwenden:

SELECT SUM(sale.sale_amount_paid) AS amount_paid 
FROM sale
WHERE sale.time_paid >= @start_time 
AND sale.time_paid <= @end_time;

Die folgende Abfrage berechnet den ausgestellten und gezahlten Betrag innerhalb eines Zeitraums, wobei das Ausstellungsdatum und das Zahlungsdatum separat geprüft werden:

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

In allen Beispielen @start_time und @end_time sind Variablen, die die Start- und Endzeit des Zeitraums enthalten, für den wir die ausgestellte und bezahlte SUM überprüfen möchten.

Die Tabelle sale_item verbindet Produkte und Vertrieb. Natürlich müssen wir davon ausgehen, dass wir mehrere Artikel haben werden auf einem Beleg, also brauchen wir diese Tabelle, um eine Viele-zu-Viele-Beziehung zu haben.

Attribute und ihre Bedeutung sind:

• quantity_sold – Produktmenge, die verkauft wurde und mit diesem Verkauf/Kassenbon verrechnet wird (z. B. 3 Kaffees)
• price_per_unit – gleicher Wert wie product.price_per_unit in dem Moment, in dem der Verkauf erstellt wurde. Wir müssen es speichern, weil price_per_unit im product Tabelle kann sich im Laufe der Zeit ändern
• price – Produkt von quantity_sold und price_per_unit; eine kleine Redundanz, die uns hilft, diese Berechnung in Abfragen zu vermeiden. Im Allgemeinen sollte die Summe aller Artikelpreise, die zu demselben Verkauf gehören, gleich dem sale.sale_amount sein
• tax_amount – Steuerbetrag für diesen Artikel bei Erhalt
• sale_id – ID des Verkaufs, zu dem dieser Artikel gehört
• product_id – Produkt-ID zu diesem Artikel

Wir könnten jetzt ganz einfach einen einfachen Bericht darüber erstellen, wie viele Produkte/Dienstleistungen wir im Zeitraum verkauft haben und zu welchem ​​Preis.

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