Modelowanie bazy danych do rejestracji sprzedaży. Część 1

Właściwe przechowywanie danych sprzedażowych i późniejsze ich łączenie może prowadzić do stworzenia modelu predykcyjnego o wysokim stopniu dokładności. W tym i kilku następnych artykułach przeanalizujemy projekt bazy danych do rejestrowania sprzedaży.

Każdy żyje ze sprzedaży czegoś.

Robert Louis Stevenson

W dzisiejszym świecie sprzedawanie produktów jest wszechobecne. Sprzedawcy, którzy mają dostęp do niezawodnych narzędzi, które wykorzystują dane historyczne do analizowania trendów i umożliwiają przedsiębiorstwu odpowiednie dostosowywanie strategii biznesowych, mają przewagę nad konkurencją. Istnieje wiele parametrów, które mogą wpływać na wyniki firmy:aktualna globalna sytuacja ekonomiczna, lokalizacja klientów, wiek, stan majątkowy i cywilny oraz historia poprzednich kontaktów lub sprzedaży do klientów.

Zaczniemy od bardzo prostego przykładu:model bazy danych do sprzedaży w kawiarni . W kolejnych artykułach rozszerzymy model o sprzedaż produktów w innych branżach.

Model sprzedaży

W tym artykule przeanalizujemy tylko część modelu, która zawiera dane sprzedaży z brakującymi innymi częściami.

Nadal mamy powiązania z brakującymi tabelami i przyjrzymy się modelowi jako czarnej skrzynce, zakładając, że poniższe informacje są poprawne dla tabeli sale :

• user_has_role_id odnieś się do identyfikatora w user_has_role (jak przedstawiono w moim poprzednim artykule w sekcji „Dodano składnik czasu”) i przechowuje informacje o użytkowniku, który utworzył rekord sprzedaży

Model ten umożliwia nam tworzenie rekordów sprzedaży z wieloma pozycjami. Każda pozycja jest powiązana z produktem z naszego katalogu. Moment, w którym generujemy sprzedaż, może być inny niż moment, w którym sprzedaż jest opłacana. Na przykład dla filiżanki kawy te chwile będą się różnić w ciągu minut lub godzin. Jeśli nasz sklep sprzedawał urządzenia telekomunikacyjne, różnica może wynosić kilka dni, może nawet miesięcy.

Stoły

Przyjrzyjmy się definicji tabeli i wyjaśnijmy cel i użycie atrybutów.

Najważniejszą tabelą w modelu jest product . Służy do przechowywania informacji o produktach, które będziemy oferować naszym klientom. Produkty są zazwyczaj dostarczane do klienta i opłacane jednorazowo, zazwyczaj w momencie dostawy. Ponadto produkty to zwykle przedmioty fizyczne, takie jak samochody, telefony, opakowania cukru lub filiżanki kawy.

W następnych artykułach porozmawiamy o sprzedaży niefizycznych rzeczy (usług).

Atrybuty w product tabela to:

• name – nazwa produktu w systemie
• price_per_unit – koszt produktu na sztukę (np. 1 filiżanka kawy kosztuje 1,8 euro, 1 samochód kosztuje 17 500 euro, 1 kg ryżu kosztuje 2 euro)
• basic_unit – jednostka bazowa przy sprzedaży produktu (np. sztuka, kg, litr)
• tax_percentage – procent ceny za jednostkę, który ma zostać naliczony jako podatek. Musimy założyć, że procent podatku nie byłby taki sam dla wszystkich produktów
• limited – to pole jest ustawione na True, jeśli mamy ograniczoną ilość na magazynie, a False w przeciwnym razie (np. możemy zamówić dowolną ilość potrzebną do naszego sklepu u dystrybutora)
• in_stock – if limited=True ten atrybut pokazuje, ile mamy do sprzedania
• active_for_sale – jeśli ten atrybut jest False, to obecnie nie oferujemy tego produktu do sprzedaży, w przeciwnym razie możemy zaoferować go klientom

Listę produktów, które możemy zaoferować klientom, możemy uzyskać za pomocą następującego zapytania:

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

Tabela sale_status to po prostu prosty słownik, który zawiera wszystkie statusy, jakie sprzedaż może mieć w systemie (np. „paragon wydany”, „paragon zapłacony”).

Atrybuty w tabeli i ich znaczenie to:

• time_created – czas wygenerowania rekordu sprzedaży w systemie (np. automatyczny czas utworzenia rekordu, kiedy wygenerowaliśmy sprzedaż kawy w naszej kawiarni lub ręcznie dodany czas, jeśli sobie tego życzymy)
• time_paid – generalnie możemy spodziewać się, że część sprzedaży zostanie opłacona w ciągu kilku dni lub nawet miesiąca po utworzeniu (np. jeśli dostarczymy oprogramowanie i stworzymy paragon, w niektórych krajach możemy poczekać do 90 dni na zapłatę, jeśli wszystko minie prawo)
• sale_amount – pierwotna kwota przeznaczona do obciążenia klienta
• sale_amount_paid – kwota, którą klient faktycznie zapłacił. Może być null, ponieważ w chwili, gdy tworzymy rachunek, nie zawsze mamy te informacje
• tax_amount – suma wszystkich kwot podatku za pozycje na tym paragonie
• sale_status_id – odniesienie do sale_status stół
• user_has_role_id – odniesienie do użytkownika i jego roli w momencie wprowadzenia paragonu do systemu

Wystawioną i opłaconą kwotę (zgodnie z time_created) możemy uzyskać w określonym czasie za pomocą zapytania:

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;

Aby otrzymać dokładną kwotę zapłaconą w określonym czasie, musimy użyć zapytania takiego:

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

Poniższe zapytanie obliczy wydaną i zapłaconą kwotę w okresie czasu, przy czym data wydania i data płatności są sprawdzane osobno:

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

We wszystkich przykładach @start_time i @end_time to zmienne zawierające czas rozpoczęcia i czas zakończenia okresu, dla którego chcemy sprawdzić wydaną i opłaconą sumę.

Tabela sale_item łączy produkty i sprzedaż. Oczywiście musimy założyć, że będziemy mieć wiele przedmiotów na jednym paragonie, więc potrzebujemy, aby ta tabela była w relacji wiele do wielu.

Atrybuty i ich znaczenie to:

• quantity_sold – ilość sprzedanego produktu i naliczona przy tej sprzedaży/paragonie (np. 3 kawy)
• price_per_unit – taka sama wartość jak product.price_per_unit w momencie utworzenia sprzedaży. Musimy to zapisać, ponieważ price_per_unit w product stół może się zmieniać w czasie
• price – produkt quantity_sold i price_per_unit; mała redundancja, która pomaga nam uniknąć tego obliczenia w zapytaniach. Ogólnie suma wszystkich cen towarów należących do tej samej sprzedaży powinna być równa sale.sale_amount
• tax_amount – kwota podatku za tę pozycję na paragonie
• sale_id – identyfikator sprzedaży, do której należy ten przedmiot
• product_id – identyfikator produktu powiązany z tym produktem

Moglibyśmy teraz łatwo sporządzić prosty raport, ile produktów/usług sprzedaliśmy w danym okresie i za jaką cenę.

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