Modellera en databas för registrering av försäljning. Del 1

Att lagra försäljningsdata på rätt sätt och senare kombinera det kan leda till att man skapar en prediktiv modell med hög noggrannhet. I den här och de kommande artiklarna kommer vi att analysera en databasdesign för att registrera försäljning.

Alla lever på att sälja något.

Robert Louis Stevenson

I dagens värld, sälja produkter är allestädes närvarande. Och säljare som har tillgång till robusta verktyg som utnyttjar historiska data för att analysera trender och gör det möjligt för ett företag att anpassa affärsstrategier därefter, har en fördel gentemot sina konkurrenter. Det finns många parametrar som kan påverka företagets resultat:den nuvarande globala ekonomiska situationen, kundernas läge, ålder, material och civilstånd, och historik över tidigare kontakter eller försäljning till kunder.

Vi börjar med ett mycket enkelt exempel:en databasmodell för försäljning i ett kafé . I efterföljande artiklar kommer vi att utöka modellen till att sälja produkter i andra branscher.

Försäljningsmodell

I den här artikeln analyserar vi bara en del av modellen som innehåller försäljningsdata med andra delar som saknas.

Vi har fortfarande kopplingar till saknade tabeller och vi kommer att titta på modellen som en svart låda förutsatt att följande är korrekt för tabell sale :

• user_has_role_id se id i user_has_role (som presenterades i min tidigare artikel i avsnittet "Tidskomponent tillagd") och lagrar information om användaren som skapade försäljningsposten

Denna modell gör det möjligt för oss att skapa försäljningsrekord med flera artiklar. Varje artikel är relaterad till en produkt från vår katalog. Det ögonblick då vi genererar en försäljning kan skilja sig från det ögonblick då försäljningen är betald. Till exempel, för en kopp kaffe kommer dessa ögonblick att skilja sig åt på några minuter eller timmar. Om vår butik sålde telekommunikationsenheter kan skillnaden vara några dagar, kanske till och med månader.

Tabell

Låt oss ta en titt på tabelldefinitionen och förklara syftet med och användningen av attribut.

Den viktigaste tabellen i modellen är product . Den används för att lagra information om produkter vi kommer att erbjuda våra kunder. Produkter levereras vanligtvis till en kund och betalas för en gång, vanligtvis vid leveranstid. Dessutom är produkter vanligtvis fysiska föremål som bilar, telefoner, sockerpaket eller koppar kaffe.

Vi kommer att prata om att sälja icke-fysiska saker (tjänster) i nästa artiklar.

Attribut i product tabellen är:

• name – namnet på produkten i systemet
• price_per_unit – produktkostnad per enhet (t.ex. 1 kopp kaffe kostar 1,8 euro, 1 bil kostar 17 500 euro, 1 kg ris kostar 2 euro)
• basic_unit – basenhet när vi säljer en produkt (t.ex. styck, kg, liter)
• tax_percentage – procent av priset_per_enhet som ska debiteras som skatt. Vi måste anta att skatteprocenten inte skulle vara densamma för alla produkter
• limited – det här fältet är satt till True om vi har ett begränsat antal på lager och False annars (t.ex. vi kan beställa vilken kvantitet vi behöver för vår butik från en distributör)
• in_stock – if limited=True detta attribut visar hur många vi har tillgängliga att sälja
• active_for_sale – om detta attribut är falskt så erbjuder vi för närvarande inte den produkten till försäljning, annars kan vi erbjuda den till kunder

Vi kan få en lista över produkter vi kan erbjuda till kunder med följande fråga:

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 är bara en enkel ordbok som innehåller alla statuser som en försäljning kan ha i systemet (t.ex. "kvitto utfärdat", "kvitto betalat").

Attribut i tabellen och deras betydelser är:

• time_created – tidpunkt då en försäljningspost genererades i systemet (t.ex. automatisk tidpunkt då posten skapades när vi genererade en försäljning för kaffe i vårt kafé eller en manuellt tillagd tid om vi vill ha det)
• time_paid – generellt sett kan vi förvänta oss att en del försäljning kommer att betalas inom några dagar eller till och med en månad efter skapandet (t.ex. om vi levererar programvara och skapar ett kvitto kan vi vänta upp till 90 dagar för att få betalt i vissa länder, om allt går förbi lagen)
• sale_amount – ursprungligt belopp avsett att debiteras kunden
• sale_amount_paid – belopp som kunden faktiskt betalat. Den kan vara null eftersom vi för tillfället skapar ett kvitto inte alltid har denna information
• tax_amount – summan av alla skattebelopp för poster på det kvittot
• sale_status_id – referens till sale_status tabell
• user_has_role_id – referens till användaren och hans roll i det ögonblick han eller hon lade in kvittot i systemet

Vi kan få det utfärdade och betalda beloppet (enligt time_created) inom en tidsperiod med en fråga så här:

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;

För att få det exakta beloppet betalt inom en tidsperiod måste vi använda en fråga som denna:

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

Frågan nedan kommer att beräkna det utfärdade och betalda beloppet inom en tidsperiod med utfärdandedatum och betalningsdatum markerade 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 alla exempel @start_time och @end_time är variabler som innehåller starttid och sluttid för period för vilken vi vill kontrollera utfärdad och betald SUMMA.

Tabellen sale_item kopplar ihop produkter och försäljning. Naturligtvis måste vi anta att vi kommer att ha flera objekt på ett kvitto så vi behöver den här tabellen för att ha en många-till-många-relation.

Attribut och deras betydelser är:

• quantity_sold – kvantitet produkt som såldes och debiteras på försäljningen/kvittot (t.ex. 3 kaffe)
• price_per_unit – samma värde som product.price_per_unit i det ögonblick då försäljningen skapades. Vi måste spara det eftersom price_per_unit i product tabellen kan ändras över tiden
• price – produkt av quantity_sold och price_per_unit; en liten redundans som hjälper oss att undvika denna beräkning i frågor. I allmänhet bör summan av alla varupriser som hör till samma rea ​​vara lika med sale.sale_amount
• tax_amount – skattebelopp för den artikeln vid mottagandet
• sale_id – försäljnings-id som denna artikel tillhör
• product_id – produkt-id relaterat till denna artikel

Vi kunde nu enkelt göra en enkel rapport, hur många produkter/tjänster vi sålde under period och till vilket 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