Star schema (schemat gwiazdy) — dlaczego dane w raporcie wyglądają inaczej niż w systemie ERP

Jak system ERP przechowuje dane — i dlaczego tak musi być

System ERP jest zoptymalizowany pod jedno zadanie: efektywne wprowadzanie i aktualizowanie danych. Jeśli zmienię adres kontrahenta w jednym miejscu, zmiana jest widoczna wszędzie — w fakturach, rozrachunkach, historii. To się nazywa normalizacja danych i jest właściwym rozwiązaniem dla systemu, który obsługuje setki transakcji dziennie.

Konsekwencja jest taka, że jedna faktura w systemie ERP to minimum kilka powiązanych zbiorów danych: nagłówek dokumentu z numerem, datą i kwotą, pozycje faktury z każdym towarem lub usługą, informacja o płatności z terminem i stanem rozrachunku, dane kontrahenta z adresem i NIP-em. Żeby wyświetlić jedno zdanie — "faktura od ABC Sp. z o.o., 12 000 zł, zaległa od 30 dni" — system musi złączyć je wszystkie w jednym zapytaniu.

To działa doskonale gdy system obsługuje 10–20 takich zapytań dziennie. Działa fatalnie gdy raport analityczny musi odpowiedzieć na to pytanie dla 500 faktur z ostatnich 2 lat, z filtrem po budynku, miesiącu i statusie płatności — i zrobić to przy każdym kliknięciu użytkownika.

Czym jest star schema

Star schema — schemat gwiazdy — to model danych zoptymalizowany pod odpowiadanie na pytania analityczne. Zamiast normalizować dane (każda informacja raz, wszędzie jako odniesienie), star schema spłaszcza je do dwóch typów tabel.

Tabele faktów przechowują zdarzenia biznesowe — każde jako jeden rekord z mierzalnymi wartościami. fact_invoices to każda faktura z kwotą, datą, statusem i identyfikatorami wskazującymi na kontrahenta, budynek i datę. fact_payments to każda płatność. fact_costs to każdy koszt. Jeden rekord — jedno zdarzenie.

Tabele wymiarów przechowują atrybuty do filtrowania i grupowania. dim_tenant to każdy kontrahent z nazwą, NIP-em, segmentem i typem działalności. dim_building to każdy budynek z nazwą, miastem i typem. dim_date to każdy dzień w kalendarzu z rokiem, kwartałem, miesiącem, tygodniem i informacją czy to dzień roboczy. Użytkownik Power BI nigdy nie widzi tych tabel bezpośrednio — widzi filtry, suwaki i segmenty danych. Star schema to fundament, który sprawia, że te filtry działają natychmiastowo.

To samo pytanie — dwa podejścia

Pytanie: "Pokaż mi wszystkie niezapłacone faktury per budynek per miesiąc za ostatnie dwa lata."

Różnica jest odczuwalna od razu. Przy 10 filtrach w raporcie — budynek, rok, miesiąc, kontrahent, status faktury, waluta, kategoria kosztu — każde kliknięcie to nowe zapytanie. Na star schema: natychmiastowa odpowiedź. Na bazie operacyjnej ERP: użytkownik czeka po każdym kliknięciu i w końcu przestaje klikać.

Co to oznacza w praktyce

Czerwona lampka w ofercie dostawcy

Jeżeli dostawca systemu BI proponuje "podłączymy Power BI bezpośrednio do Optimy" — bez wzmianki o modelu danych, warstwie pośredniej czy strukturze analitycznej — to jest sygnał ostrzegawczy. Oznacza:

• Wolne raporty — Power BI odpytuje operacyjną bazę przy każdym kliknięciu filtru
• Niespójne liczby — każdy raport definiuje logikę osobno, różne działy widzą różne wartości
• Brak historii — zmiany w systemie ERP (aktualizacja adresu kontrahenta, korekta dokumentu) mogą nadpisywać dane historyczne retroaktywnie
• Każde nowe pytanie od zera — brak wspólnego modelu danych oznacza brak możliwości łatwego rozszerzenia raportów

To nie jest kwestia gustu architektonicznego — to kwestia funkcjonalności raportu w codziennym użyciu.

Podsumowanie

Star schema to nie techniczna fanaberia — to powód, dla którego raport działa w sekundę zamiast w minutę i dlaczego liczby z raportu zawsze się zgadzają niezależnie od tego, kto je generuje. Każdy porządnie zbudowany system BI ma ją pod spodem, nawet jeśli użytkownik nigdy nie słyszał tej nazwy. Użytkownik Power BI widzi filtry i wykresy — star schema sprawia, że każdy klik na nie odpowiada natychmiastowo.

Najczęstsze pytania