1Problem i cel projektu

Sieć posiadająca wiele sklepów i produktów potrzebuje nie tylko informacji o całkowitym przychodzie. Do podejmowania decyzji biznesowych konieczne jest również ustalenie:

• które produkty i kategorie generują największy zysk,
• jak zmieniają się wyniki w czasie,
• które placówki osiągają najlepsze rezultaty,
• czy poziom zapasów odpowiada bieżącej sprzedaży,
• gdzie występuje ryzyko braku produktów,
• gdzie środki są zamrożone w nadmiernym zapasie.

Przygotowałam analizę odpowiadającą na następujące pytania:

• jaki jest łączny przychód, koszt produktów, zysk brutto na sprzedaży i marża brutto,
• które kategorie i produkty osiągają najlepsze wyniki,
• jak przychód zmienia się miesiąc do miesiąca i rok do roku,
• czy pod koniec analizowanego okresu widoczne jest przyspieszenie lub osłabienie sprzedaży,
• które sklepy i typy lokalizacji osiągają najlepsze wyniki,
• jaka jest aktualna wartość zapasów,
• które kombinacje sklep–produkt mają zbyt niski, optymalny lub nadmierny zapas,
• gdzie występuje brak zapasu pomimo wcześniejszej sprzedaży,
• gdzie zapas pozostaje w sklepie mimo braku sprzedaży.

Projekt przygotowałam jako kompletną analizę biznesową wykonaną w SQL, a nie tylko zbiór pojedynczych zapytań technicznych.

2Dane

Dane pochodzą z publicznego zbioru Maven Analytics i przedstawiają fikcyjną sieć sklepów z zabawkami działającą w Meksyku.

Dane sprzedażowe obejmują okres od 1 stycznia 2022 roku do 30 września 2023 roku.

Tabela inventory przedstawia aktualny stan zapasów. Umożliwia ocenę ich poziomu i struktury, ale nie pokazuje historycznych zmian stanów magazynowych.

Źródło danych: Mexico Toy Sales – Maven Analytics

3Struktura bazy danych

Główną tabelą transakcyjną jest tabela sales. Każdy rekord sprzedaży jest powiązany z konkretnym produktem i sklepem. Tabela inventory również łączy produkty ze sklepami, ale przedstawia aktualny stan magazynowy dla konkretnej kombinacji sklep–produkt.

W analizowanej bazie:

• sale_id jest kluczem głównym tabeli sales,
• product_id jest kluczem głównym tabeli products,
• store_id jest kluczem głównym tabeli stores,
• połączenie store_id + product_id tworzy klucz złożony tabeli inventory,
• kolumny product_id i store_id pozwalają łączyć tabele podczas analizy.

W bazie źródłowej relacje nie były fizycznie zdefiniowane jako klucze obce. Na potrzeby dokumentacji utworzyłam w DBeaverze diagram ERD z relacjami wirtualnymi:

• sales.product_id → products.product_id,
• sales.store_id → stores.store_id,
• inventory.product_id → products.product_id,
• inventory.store_id → stores.store_id.

Widoku vw_products_clean nie umieściłam na diagramie, ponieważ utworzyłam go podczas przygotowania danych i nie należy on do czterech tabel źródłowych.

4Kontrola jakości i przygotowanie danych

Przed rozpoczęciem właściwej analizy sprawdziłam jakość, kompletność i spójność danych.

Kontrola obejmowała:

• liczbę rekordów w każdej tabeli,
• brakujące wartości,
• duplikaty kluczy głównych,
• duplikaty klucza złożonego w tabeli inventory,
• zgodność identyfikatorów produktów i sklepów pomiędzy tabelami,
• zakres dat sprzedaży,
• produkty, których cena była niższa lub równa kosztowi,
• kompletność kombinacji sklep–produkt w tabeli zapasów.

Nie znalazłam brakujących wartości, zduplikowanych kluczy, niezgodnych identyfikatorów ani produktów sprzedawanych po cenie niższej lub równej kosztowi.

Koszty i ceny produktów były zapisane jako tekst zawierający symbol waluty. Utworzyłam widok vw_products_clean, w którym usunęłam symbol waluty i przekształciłam wartości do typu DECIMAL(10,2). W ten sposób przygotowałam jednolitą warstwę danych do dalszych obliczeń bez zmieniania tabeli źródłowej.

Dla 50 sklepów i 35 produktów istnieje 1 750 możliwych kombinacji sklep–produkt. Tabela inventory zawiera 1 593 rekordy, dlatego dla 157 kombinacji brakuje informacji o zapasie.

Nie potraktowałam brakujących rekordów jako zapasu równego zero, ponieważ dane nie wskazują, czy produkt nie jest oferowany w danym sklepie, czy odpowiedni rekord nie został zapisany.

5Zakres analizy i struktura skryptów SQL

Podzieliłam kod projektu na sześć tematycznych skryptów:

1. 01_data_quality.sql – kontrola jakości, kompletności i spójności danych,
2. 02_data_preparation.sql – przygotowanie widoku z oczyszczonymi kosztami i cenami produktów,
3. 03_sales_and_profitability.sql – analiza sprzedaży, zysku, marży, kategorii i produktów,
4. 04_time_analysis.sql – analiza miesiąc do miesiąca, rok do roku i średnich kroczących,
5. 05_store_analysis.sql – wyniki i rankingi sklepów oraz typów lokalizacji,
6. 06_inventory_analysis.sql – wartość zapasów, pokrycie sprzedaży zapasem i klasyfikacja pozycji magazynowych.

W zapytaniach wykorzystałam między innymi:

• złączenia INNER JOIN i LEFT JOIN,
• wspólne wyrażenia tabelowe CTE,
• widok SQL,
• funkcje agregujące,
• instrukcję CASE,
• funkcje COALESCE i NULLIF,
• konwersję typów danych,
• funkcje okna LAG i RANK,
• średnie kroczące, rankingi w obrębie kategorii i porównania okresów.

6Wybrane rozwiązanie SQL – klasyfikacja zapasów

Jednym z najważniejszych elementów projektu było określenie poziomu zapasu dla każdej zapisanej kombinacji sklep–produkt.

Najpierw zagregowałam sprzedaż z ostatnich trzech miesięcy dostępnych w zbiorze, a następnie połączyłam ją z aktualnym stanem zapasu. Na tej podstawie obliczyłam średnią miesięczną sprzedaż oraz liczbę miesięcy, na które powinien wystarczyć obecny zapas.

stock_coverage_months_cte as
(
    select
        *
        ,round(units_sold_last_3_months / 3.0, 2)
            as avg_monthly_units_sold
        ,stock_on_hand
            / nullif(units_sold_last_3_months / 3.0, 0)
            as stock_coverage_months_exact
    from inventory_sales_cte
),
inventory_status_cte as
(
    select
        *
        ,case
            when stock_on_hand = 0 then 'Out of Stock'
            when units_sold_last_3_months = 0
                and stock_on_hand > 0 then 'No Sales'
            when stock_coverage_months_exact < 1 then 'Low Stock'
            when stock_coverage_months_exact <= 3 then 'Optimal Stock'
            else 'Overstock'
        end as inventory_status
    from stock_coverage_months_cte
)

Funkcja NULLIF zabezpiecza obliczenie przed dzieleniem przez zero. Za pomocą instrukcji CASE przypisałam każdej pozycji jeden z pięciu statusów: brak zapasu, niski zapas, zapas optymalny, nadmierny zapas lub brak sprzedaży.

Rozdzielenie kolejnych etapów pomiędzy CTE ułatwiło mi kontrolę obliczeń i pozwoliło oddzielić przygotowanie danych od właściwej klasyfikacji.

Pełne zapytanie znajduje się w repozytorium projektu.

7Najważniejsze wyniki

Wynik całej sieci

Obliczyłam zysk brutto na sprzedaży jako różnicę pomiędzy przychodem a kosztem produktów. Dane nie zawierają kosztów operacyjnych sklepów, dlatego wynik nie oznacza zysku netto.

Rentowność kategorii

Kategoria Toys wygenerowała najwyższy przychód i zysk brutto, ale jednocześnie osiągnęła najniższą marżę – 21,20%.

Electronics wygenerowała 1 001 437,00 USD zysku brutto przy przychodzie wynoszącym 2 246 771,25 USD. Oznacza to wynik zbliżony do kategorii Toys przy przychodzie niższym o ponad połowę. Marża brutto Electronics wyniosła 44,57%.

Wyniki części kategorii były silnie skoncentrowane na pojedynczych produktach:

• Colorbuds odpowiadał za 69,63% przychodu kategorii Electronics,
• Lego Bricks odpowiadał za 46,90% przychodu kategorii Toys.

Trend sprzedaży

Przychód od stycznia do września 2023 roku był o 30,86% wyższy niż w analogicznym okresie 2022 roku. Pod koniec analizowanego okresu dynamika sprzedaży jednak osłabła.

Dane kończą się we wrześniu 2023 roku, dlatego nie można jednoznacznie stwierdzić, czy osłabienie oznaczało trwałą zmianę trendu, czy było efektem sezonowym.

Wyniki sklepów i typów lokalizacji

Najwyższy przychód osiągnął sklep Maven Toys Ciudad de Mexico 2: 554 553,43 USD przychodu, 169 856,00 USD zysku brutto na sprzedaży i 30,63% marży brutto.

Sklepy typu Downtown wygenerowały najwyższy łączny przychód, ale stanowią większość sieci – 29 z 50 placówek.

Najwyższy średni przychód na jeden sklep osiągnęły lokalizacje Airport – 429 907,53 USD, czyli o 48,81% więcej od średniej dla całej sieci. Wynik ten dotyczy jednak tylko trzech sklepów, dlatego powinien być traktowany jako sygnał do dalszej analizy, a nie samodzielna podstawa decyzji o rozwoju tego typu lokalizacji.

Stan i struktura zapasów

Łączna wartość aktualnego zapasu według kosztu produktów wyniosła 300 209,58 USD.

Tylko 23,04% zapisanych kombinacji sklep–produkt miało optymalny poziom zapasu. Kolejne 58,82% miało zapas wystarczający na mniej niż jeden miesiąc, a w przypadku 77 kombinacji zapas wynosił zero pomimo sprzedaży w poprzednich trzech miesiącach.

Nadmierny zapas oraz zapas produktów bez sprzedaży miały łączną wartość 48 969,77 USD, co odpowiadało 16,31% wartości całego zapasu.

8Wnioski i rekomendacje biznesowe

Analiza pokazała jednoczesne występowanie dwóch przeciwstawnych problemów: ryzyka utraty sprzedaży z powodu braków i niskich stanów oraz zamrożenia środków w nadmiernym zapasie i produktach bez sprzedaży.

Na podstawie wyników analizy rekomendowałabym:

• przeanalizowanie w pierwszej kolejności pozycji bez zapasu i z niskim zapasem,
• ustalanie priorytetów uzupełnienia na podstawie tempa sprzedaży oraz zysku jednostkowego,
• sprawdzenie możliwości przesunięcia produktów pomiędzy sklepami,
• ograniczenie kolejnych zamówień lub zastosowanie działań promocyjnych dla produktów z nadmiernym zapasem i bez sprzedaży,
• ochronę dostępności produktów Colorbuds i Lego Bricks ze względu na ich duży udział w wynikach całych kategorii,
• analizę cen, struktury asortymentu i kosztów zakupu w kategoriach o niskiej marży,
• dalsze monitorowanie sprzedaży po wrześniu 2023 roku przed zmianą prognoz lub planów zakupowych,
• porównanie asortymentu, natężenia ruchu i kosztów działania sklepów Airport przed podjęciem decyzji o rozwoju tego typu lokalizacji.

9Założenia i ograniczenia analizy

Określiłam poziomy rentowności na podstawie marży brutto:

• wysoki – marża brutto co najmniej 30%,
• średni – marża brutto od 25% do 29,99%,
• niski – marża brutto poniżej 25%.

Progi te są założeniem analitycznym przyjętym na potrzeby projektu, a nie standardem branżowym.

Obliczyłam zysk brutto na sprzedaży jako różnicę pomiędzy przychodem a kosztem produktów. Zbiór nie zawiera kosztów operacyjnych sklepów.

Obliczyłam pokrycie zapasu na podstawie średniej miesięcznej sprzedaży z okresu od lipca do września 2023 roku.

Zdefiniowałam statusy zapasów następująco:

• niski zapas – poniżej jednego miesiąca sprzedaży,
• zapas optymalny – od jednego do trzech miesięcy sprzedaży,
• nadmierny zapas – powyżej trzech miesięcy sprzedaży.

Tabela inventory przedstawia aktualny stan zapasów. Nie umożliwia analizy ich historycznych poziomów ani dokładnego określenia wartości sprzedaży utraconej z powodu braku produktu.

Nie potraktowałam brakujących rekordów w tabeli zapasów jako zerowego zapasu.

Dane sprzedażowe kończą się we wrześniu 2023 roku, dlatego ocena późniejszego trendu wymagałaby danych z kolejnych miesięcy.

10Dalszy rozwój projektu

Projekt mogłabym rozszerzyć o:

• dashboard prezentujący najważniejsze wyniki,
• dane historyczne dotyczące poziomu zapasów,
• koszty operacyjne poszczególnych sklepów,
• analizę rotacji zapasów,
• prognozowanie zapotrzebowania,
• wyznaczenie poziomów zapasu uruchamiających nowe zamówienie po uzupełnieniu danych o czas dostawy i zapas bezpieczeństwa,
• automatyczne alerty dla produktów z niskim lub nadmiernym zapasem,
• bardziej szczegółową analizę wpływu daty otwarcia sklepu i typu lokalizacji na wyniki.

11Czego się nauczyłam

Podczas pracy nad projektem przećwiczyłam projektowanie kompletnej analizy SQL, w której kolejne zapytania prowadzą od kontroli danych do wniosków biznesowych.

Rozwinęłam umiejętności obejmujące:

• sprawdzanie jakości, kompletności i spójności danych,
• pracę z kilkoma powiązanymi tabelami,
• rozpoznawanie kluczy głównych, obcych i złożonych,
• przygotowanie widoku z oczyszczonymi danymi,
• budowę wieloetapowych zapytań z użyciem CTE,
• wykorzystanie funkcji okna do rankingów i porównań okresów,
• obliczanie średnich kroczących,
• zabezpieczanie obliczeń przy użyciu NULLIF i COALESCE,
• tworzenie klasyfikacji za pomocą CASE,
• definiowanie założeń i ograniczeń analizy,
• interpretowanie wyników technicznych w kontekście biznesowym,
• formułowanie rekomendacji bez wykraczania poza zakres dostępnych danych,
• uporządkowanie projektu i opublikowanie go w repozytorium GitHub.

Projekt pokazał mi, że dobra analiza SQL nie kończy się na otrzymaniu poprawnego wyniku zapytania. Równie ważne jest sprawdzenie jakości danych, opisanie przyjętej logiki, wskazanie ograniczeń oraz przełożenie wyników na informacje przydatne dla biznesu.

12Repozytorium

Repozytorium zawiera:

• cztery źródłowe pliki CSV,
• sześć uporządkowanych tematycznie skryptów SQL,
• szesnaście wyeksportowanych wyników zapytań,
• diagram ERD,
• opis projektu, założeń analitycznych, wyników i rekomendacji.

Zobacz na GitHubie

1Business problem and project goal

A chain with many stores and products needs more than information about total revenue. Business decisions also require an understanding of:

• which products and categories generate the highest profit,
• how results change over time,
• which stores achieve the strongest results,
• whether inventory levels reflect current sales,
• where there is a risk of product shortages,
• where funds are tied up in excess inventory.

I prepared an analysis answering the following questions:

• what are total revenue, product cost, gross profit on sales and gross margin,
• which categories and products achieve the best results,
• how revenue changes month over month and year over year,
• whether sales accelerate or weaken near the end of the analyzed period,
• which stores and location types achieve the best results,
• what the current inventory value is,
• which store-product combinations have low, optimal or excess inventory,
• where inventory is unavailable despite previous sales,
• where stock remains in a store despite no sales.

I prepared the project as a complete business analysis in SQL rather than only a collection of individual technical queries.

2Data

The data comes from a public Maven Analytics dataset and represents a fictional toy store chain operating in Mexico.

The sales data covers the period from 1 January 2022 to 30 September 2023.

The inventory table presents current inventory levels. It supports an assessment of their level and structure but does not show historical changes in inventory.

Data source: Mexico Toy Sales – Maven Analytics

3Database structure

The main transactional table is sales. Each sales record is linked to a specific product and store. The inventory table also connects products and stores, but it presents the current inventory level for a specific store-product combination.

In the analyzed database:

• sale_id is the primary key of the sales table,
• product_id is the primary key of the products table,
• store_id is the primary key of the stores table,
• the combination of store_id + product_id forms the composite key of the inventory table,
• the product_id and store_id columns allow the tables to be joined during analysis.

Relationships in the source database were not physically defined as foreign keys. For project documentation, I created an ERD in DBeaver using virtual relationships:

• sales.product_id → products.product_id,
• sales.store_id → stores.store_id,
• inventory.product_id → products.product_id,
• inventory.store_id → stores.store_id.

I did not include the vw_products_clean view in the diagram because I created it during data preparation and it is not one of the four source tables.

4Data quality and preparation

Before starting the main analysis, I checked data quality, completeness and consistency.

The checks covered:

• the number of records in each table,
• missing values,
• duplicate primary keys,
• duplicate composite keys in the inventory table,
• product and store identifier consistency across tables,
• the sales date range,
• products with a price lower than or equal to cost,
• the completeness of store-product combinations in the inventory table.

I found no missing values, duplicate keys, inconsistent identifiers or products sold at a price lower than or equal to cost.

Product costs and prices were stored as text containing a currency symbol. I created the vw_products_clean view, removed the currency symbol and converted the values to DECIMAL(10,2). This allowed me to prepare a consistent data layer for further calculations without changing the source table.

There are 1,750 possible store-product combinations for 50 stores and 35 products. The inventory table contains 1,593 records, so inventory information is missing for 157 combinations.

I did not treat the missing records as zero inventory because the data does not indicate whether a product is unavailable in a given store or whether the relevant record was not captured.

5Analysis scope and SQL script structure

I divided the project code into six thematic scripts:

1. 01_data_quality.sql – data quality, completeness and consistency checks,
2. 02_data_preparation.sql – a view with cleaned product costs and prices,
3. 03_sales_and_profitability.sql – sales, profit, margin, category and product analysis,
4. 04_time_analysis.sql – month-over-month, year-over-year and moving-average analysis,
5. 05_store_analysis.sql – store and location type performance and rankings,
6. 06_inventory_analysis.sql – inventory value, stock coverage and inventory classification.

The queries use:

• INNER JOIN and LEFT JOIN,
• common table expressions (CTEs),
• an SQL view,
• aggregate functions,
• the CASE expression,
• COALESCE and NULLIF,
• data type conversion,
• the LAG and RANK window functions,
• moving averages, category-level rankings and period comparisons.

6Selected SQL solution – inventory classification

One of the most important elements of the project was determining the inventory level for each recorded store-product combination.

I first aggregated sales from the final three months available in the dataset and then joined them with current inventory. Based on this, I calculated average monthly sales and the number of months that current stock should cover.

stock_coverage_months_cte as
(
    select
        *
        ,round(units_sold_last_3_months / 3.0, 2)
            as avg_monthly_units_sold
        ,stock_on_hand
            / nullif(units_sold_last_3_months / 3.0, 0)
            as stock_coverage_months_exact
    from inventory_sales_cte
),
inventory_status_cte as
(
    select
        *
        ,case
            when stock_on_hand = 0 then 'Out of Stock'
            when units_sold_last_3_months = 0
                and stock_on_hand > 0 then 'No Sales'
            when stock_coverage_months_exact < 1 then 'Low Stock'
            when stock_coverage_months_exact <= 3 then 'Optimal Stock'
            else 'Overstock'
        end as inventory_status
    from stock_coverage_months_cte
)

The NULLIF function prevents division by zero. Using the CASE expression, I assigned each item to one of five statuses: out of stock, low stock, optimal stock, overstock or no sales.

Splitting the stages across CTEs made it easier for me to verify the calculations and separate data preparation from the classification itself.

The full query is available in the project repository.

7Key results

Overall chain performance

I calculated gross profit on sales as the difference between revenue and product cost. The dataset does not include store operating costs, so this result is not net profit.

Category profitability

Toys generated the highest revenue and gross profit, but it also had the lowest margin at 21.20%.

Electronics generated USD 1,001,437.00 in gross profit on revenue of USD 2,246,771.25. This means it achieved a result close to Toys with less than half the revenue. The Electronics gross margin was 44.57%.

Results in some categories were highly concentrated in individual products:

• Colorbuds accounted for 69.63% of Electronics revenue,
• Lego Bricks accounted for 46.90% of Toys revenue.

Sales trend

Revenue from January to September 2023 was 30.86% higher than in the same period of 2022. However, sales momentum weakened near the end of the analyzed period.

The data ends in September 2023, so it is not possible to determine conclusively whether the slowdown represented a lasting trend change or a seasonal effect.

Store and location type performance

Maven Toys Ciudad de Mexico 2 generated the highest revenue: USD 554,553.43 in revenue, USD 169,856.00 in gross profit on sales and a gross margin of 30.63%.

Downtown stores generated the highest total revenue, but they account for most of the chain: 29 of 50 stores.

Airport locations achieved the highest average revenue per store at USD 429,907.53, which was 48.81% above the chain average. However, the result is based on only three stores, so it should be treated as a signal for further analysis rather than a stand-alone basis for expanding this location type.

Inventory level and structure

The total current inventory value at product cost was USD 300,209.58.

Only 23.04% of recorded store-product combinations had an optimal inventory level. A further 58.82% had less than one month of stock coverage, and 77 combinations had no inventory despite sales in the previous three months.

Overstocked products and products with inventory but no sales had a combined value of USD 48,969.77, equivalent to 16.31% of total inventory value.

8Business conclusions and recommendations

The analysis identified two opposing problems occurring at the same time: the risk of lost sales due to stockouts and low inventory, and funds tied up in overstocked products and products with no sales.

Based on the results, I would recommend:

• reviewing out-of-stock and low-stock items first,
• prioritizing replenishment based on sales velocity and unit profit,
• checking whether products can be transferred between stores,
• limiting further orders or using promotional activity for overstocked products and products with no sales,
• protecting the availability of Colorbuds and Lego Bricks because of their large contribution to category results,
• reviewing pricing, product mix and purchasing costs in low-margin categories,
• continuing to monitor sales after September 2023 before changing forecasts or purchasing plans,
• comparing product mix, customer traffic and operating costs of Airport stores before deciding whether to expand this location type.

9Analytical assumptions and limitations

I defined profitability levels based on gross margin:

• high – gross margin of at least 30%,
• medium – gross margin from 25% to 29.99%,
• low – gross margin below 25%.

These thresholds are analytical assumptions adopted for the project, not an industry standard.

I calculated gross profit on sales as the difference between revenue and product cost. The dataset does not include store operating costs.

I calculated stock coverage using average monthly sales from July to September 2023.

I defined inventory statuses as follows:

• low stock – less than one month of sales coverage,
• optimal stock – one to three months of sales coverage,
• overstock – more than three months of sales coverage.

The inventory table presents current inventory. It does not support an analysis of historical inventory levels or an exact calculation of sales lost because a product was unavailable.

I did not treat missing records in the inventory table as zero inventory.

The sales data ends in September 2023, so evaluating the later trend would require data from subsequent months.

10Further development

I could extend the project with:

• a dashboard presenting the key results,
• historical inventory data,
• operating costs for individual stores,
• inventory turnover analysis,
• demand forecasting,
• reorder levels after adding lead-time and safety-stock data,
• automatic alerts for products with low or excess inventory,
• a more detailed analysis of how store opening date and location type affect performance.

11What I learned

During the project, I practiced designing a complete SQL analysis in which successive queries move from data checks to business conclusions.

I developed skills in:

• checking data quality, completeness and consistency,
• working with several related tables,
• identifying primary, foreign and composite keys,
• preparing a view with cleaned data,
• building multi-stage queries with CTEs,
• using window functions for rankings and period comparisons,
• calculating moving averages,
• protecting calculations with NULLIF and COALESCE,
• creating classifications with CASE,
• defining analytical assumptions and limitations,
• interpreting technical results in a business context,
• formulating recommendations without going beyond the available data,
• organizing the project and publishing it in a GitHub repository.

The project showed me that a good SQL analysis does not end with a correct query result. Checking data quality, explaining the adopted logic, identifying limitations and translating results into useful business information are equally important.

12Repository

The repository includes:

• four source CSV files,
• six SQL scripts organized by topic,
• sixteen exported query results,
• an ERD,
• the project description, analytical assumptions, results and recommendations.

View on GitHub