Modellering af en database til registrering af salg. Del 1

Korrekt lagring af salgsdata og senere kombination af dem kan føre til at skabe en forudsigelig model med høj nøjagtighed. I denne og de næste par artikler analyserer vi et databasedesign til registrering af salg.

Alle lever af at sælge noget.

Robert Louis Stevenson

I dagens verden salg af produkter er allestedsnærværende. Og sælgere, der har adgang til robuste værktøjer, der udnytter historiske data til at analysere tendenser og sætter en virksomhed i stand til at justere forretningsstrategier i overensstemmelse hermed, har en fordel i forhold til deres konkurrenter. Der er masser af parametre, der kan påvirke virksomhedens resultater:den aktuelle globale økonomiske situation, kundernes placering, alder, materiale og ægteskabelig status og historie om tidligere kontakter eller salg til kunder.

Vi starter med et meget simpelt eksempel:en databasemodel for salg i en kaffebar . I de efterfølgende artikler vil vi udvide modellen til at sælge produkter i andre brancher.

Salgsmodel

I denne artikel analyserer vi kun en del af modellen, der indeholder salgsdata, hvor andre dele mangler.

Vi har stadig forbindelser til manglende tabeller, og vi vil se på modellen som en sort boks, forudsat at følgende er korrekt for tabel sale :

• user_has_role_id se id i user_has_role (som præsenteret i min tidligere artikel i afsnittet "Tidskomponent tilføjet") og gemmer oplysninger om den bruger, der oprettede salgspost

Denne model gør det muligt for os at oprette salgsrekorder med flere varer. Hver vare er relateret til et produkt fra vores katalog. Det øjeblik, hvor vi genererer et salg, kan være anderledes end det øjeblik, hvor salget er betalt. For eksempel, for en kop kaffe vil disse øjeblikke afvige i løbet af få minutter eller timer. Hvis vores butik solgte telekommunikationsenheder, kan forskellen være et par dage, måske endda måneder.

Tabeller

Lad os tage et kig på tabeldefinitionen og forklare formålet med og brugen af ​​attributter.

Den vigtigste tabel i modellen er product . Det bruges til at gemme detaljer om produkter, vi tilbyder til vores kunder. Produkter leveres normalt til en kunde og betales for én gang, normalt på leveringstidspunktet. Produkter er også normalt fysiske genstande som biler, telefoner, pakker med sukker eller kopper kaffe.

Vi vil tale om salg af ikke-fysiske ting (tjenester) i de næste artikler.

Attributter i product tabellen er:

• name – navnet på produktet i systemet
• price_per_unit – produktpris pr. enhed (f.eks. koster 1 kop kaffe 1,8 euro, 1 bil koster 17.500 euro, 1 kg ris koster 2 euro)
• basic_unit – basisenhed, når vi sælger et produkt (f.eks. styk, kg, liter)
• tax_percentage – procent af prisen_per_enhed, der skal opkræves som skat. Vi må antage, at afgiftsprocenten ikke ville være den samme for alle produkter
• limited – dette felt er sat til True, hvis vi har en begrænset mængde på lager og False ellers (vi kan f.eks. bestille enhver mængde, vi har brug for til vores butik, fra en distributør)
• in_stock – if limited=True denne egenskab viser, hvor mange vi har til rådighed til at sælge
• active_for_sale – hvis denne egenskab er falsk, tilbyder vi i øjeblikket ikke produktet til salg, ellers kan vi tilbyde det til kunder

Vi kan få en liste over produkter, vi kan tilbyde til kunder med følgende forespørgsel:

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

Tabellen sale_status er blot en simpel ordbog, der indeholder alle statusser, som et salg kan have i systemet (f.eks. "kvittering udstedt", "kvittering betalt").

Attributter i tabellen og deres betydning er:

• time_created – tidspunkt, hvor en salgspost blev genereret i systemet (f.eks. automatisk tidspunkt for, hvornår posten blev oprettet, da vi genererede et salg for kaffe i vores kaffebar eller et manuelt tilføjet tidspunkt, hvis vi ønsker det)
• time_paid – generelt kan vi forvente, at nogle salg vil blive betalt inden for et par dage eller endda en måned efter oprettelsen (hvis vi f.eks. leverer software og opretter en kvittering, kan vi vente op til 90 dage på at blive betalt i nogle lande, hvis alt går loven)
• sale_amount – oprindeligt beløb beregnet til at blive opkrævet hos kunden
• sale_amount_paid – beløb, som kunden faktisk har betalt. Den kan være nul, fordi vi i øjeblikket opretter en kvittering ikke altid har disse oplysninger
• tax_amount – summen af ​​alle afgiftsbeløb for poster på den kvittering
• sale_status_id – henvisning til sale_status tabel
• user_has_role_id – reference til bruger og hans rolle i det øjeblik, han eller hun indtastede kvitteringen i systemet

Vi kan få det udstedte og betalte beløb (i henhold til time_created) inden for en periode med en forespørgsel som denne:

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;

For at få det nøjagtige beløb betalt inden for en periode skal vi bruge en forespørgsel som denne:

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

Forespørgslen nedenfor vil beregne det udstedte og betalte beløb inden for en periode, hvor udstedelsesdatoen og betalingsdatoen er markeret separat:

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

I alle eksempler @start_time og @end_time er variabler, der indeholder starttidspunktet og sluttidspunktet for den periode, som vi ønsker at kontrollere udstedt og betalt SUM for.

Tabellen sale_item forbinder produkter og salg. Selvfølgelig må vi antage, at vi har flere varer på én kvittering, så vi har brug for denne tabel for at have et mange-til-mange forhold.

Attributter og deres betydninger er:

• quantity_sold – mængde af produkt, der blev solgt og opkrævet på det pågældende salg/kvittering (f.eks. 3 kaffer)
• price_per_unit – samme værdi som product.price_per_unit på det tidspunkt, hvor salget blev oprettet. Vi er nødt til at gemme det, fordi price_per_unit i product tabel kan ændre sig over tid
• price – produkt af quantity_sold og price_per_unit; en lille redundans, der hjælper os med at undgå denne beregning i forespørgsler. Generelt skal summen af ​​alle varepriser, der hører til det samme udsalg, være lig med sale.sale_amount
• tax_amount – afgiftsbeløb for den pågældende vare ved modtagelsen
• sale_id – salgs-id, som denne vare tilhører
• product_id – produkt-id relateret til denne vare

Vi kunne nu nemt lave en simpel rapport, hvor mange produkter/ydelser vi solgte i periode og til hvilken pris.

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