Modelowanie danych: od ERD do ontologii firmy

Nie trzeba porzucać diagramu ERD, żeby zbudować ontologię firmy. ERD pomaga zaprojektować i utrzymać konkretne tabele, klucze oraz relacje w bazie. Ontologia odpowiada na inne pytanie: co „klient”, „zamówienie” i „termin realizacji” znaczą dla całej firmy, także wtedy, gdy ich dane leżą w kilku systemach. W polskim MŚP najczęściej warto zacząć od małego modelu pojęciowego nad istniejącymi danymi, a nie od migracji wszystkich baz.

Ten artykuł rozwija filar ontologii firmy. Jeśli dopiero poznajesz słownictwo, zacznij od prostego wyjaśnienia ontologii, taksonomii i grafu. Tu skupiam się na przejściu od schematu technicznego do wspólnego modelu biznesowego.

Co dobrze pokazuje ERD?

Diagram związków encji opisuje strukturę danych konkretnej aplikacji: tabele lub encje, atrybuty, klucze oraz powiązania. W systemie sprzedażowym zobaczymy customers, orders i order_items. Klucz obcy w orders wskazuje rekord klienta. To dobra podstawa do ustalenia integralności i implementacji zapytań.

Kłopot pojawia się, gdy obok stoi ERP, CRM, sklep i arkusz. Każdy może mieć własną tabelę klientów, własny identyfikator i inną definicję statusu zamówienia. ERD każdego systemu nadal jest poprawny, lecz nie rozstrzyga automatycznie, czy client_id w CRM oznacza tę samą firmę co customer_no w ERP. Nie wyjaśnia też, czy „aktywny klient” to ktoś z otwartą ofertą, umową czy zakupem w ostatnim roku.

Tekst Timbr.ai o przejściu od ERD do ontologii trafnie zwraca uwagę na ukryte znaczenie relacji. Jest jednak materiałem dostawcy rozwiązania. Obietnic skrócenia zapytań lub automatycznego wnioskowania nie należy przenosić na dowolną firmę. Relacja „dostawca dostarcza część” nie jest z natury przechodnia: jeśli A dostarcza B, a B dostarcza C, nie wynika z tego, że A dostarcza C.

Co dodaje ontologia?

Ontologia nazywa typy obiektów, relacje, właściwości i ograniczenia w języku firmy. Może powiedzieć: „zamówienie klienta” ma jednego właściciela handlowego, dotyczy określonej wersji oferty i może mieć wiele dostaw. Relacja „realizuje” ma inne znaczenie niż „planuje realizować”. Do każdego pojęcia warto przypisać właściciela definicji i źródło danych.

Pytanie	ERD jednej aplikacji	Ontologia firmy
Gdzie zapisano zamówienie?	Tabela, klucz i pole statusu	Źródło rekordu oraz jego odpowiednik w innych systemach
Co znaczy „zamówienie przyjęte”?	Kod lub wartość pola	Definicja i warunek biznesowy uzgodniony między działami
Jak połączono zamówienie z klientem?	Klucz obcy w bazie	Znaczenie relacji, reguła identyfikacji i wyjątki
Kto może użyć danych?	Mechanizm uprawnień bazy	Właściciel pojęcia i wymagania dostępu, które muszą zostać wdrożone w systemach

Ontologia nie zastępuje uprawnień, transakcji ani jakości danych. Definicja „aktywny klient” nie sprawi, że stare rekordy zduplikowanych klientów same się połączą. Podobnie graf pojęć nie przeniesie automatycznie zmian do ERP. To kontrakt znaczenia, który trzeba odwzorować w danych i aplikacjach.

Przykład: „klient” i „termin realizacji” w trzech źródłach

Załóżmy hipotetyczną firmę handlowo-serwisową. CRM przechowuje potencjalnych klientów i osoby kontaktowe. ERP ma kontrahentów, faktury oraz zamówienia. Arkusz działu usług zawiera planowane daty wykonania. Raport „opóźnione zamówienia aktywnych klientów” daje trzy różne wyniki, zależnie od tego, kto go przygotuje.

Zacznij od czterech decyzji definicyjnych. Czy klientem jest osoba czy firma? Kiedy lead staje się klientem? Która data jest terminem obiecanym, a która wewnętrznym planem? Jak połączyć rekordy bez ryzykownego dopasowania tylko po nazwie? Odpowiedzi zapisz wraz z wyjątkami: oddział tej samej firmy, zmiana NIP, kilku płatników, zamówienie złożone przez pośrednika.

Dopiero potem mapuj pola. crm.account_id i erp.contractor_no mogą wskazywać ten sam typ obiektu „Kontrahent”, ale regułę ich łączenia trzeba przetestować. planned_date z arkusza i promised_date z ERP nie powinny trafiać do jednej właściwości „termin”. Dzięki temu agent AI lub raport może odpowiedzieć: „planowana data jest późniejsza od obiecanej”, podając oba źródła i moment ich aktualizacji.

To przykład dydaktyczny. Nie zakłada, że firma ma wskazane systemy ani że problem rozwiąże konkretny produkt. Podobne konflikty definicji opisuje artykuł o różnych sposobach liczenia terminu realizacji.

Jak przejść od ERD do modelu pojęciowego?

1. Wybierz pytanie biznesowe. Nie modeluj całej organizacji na zapas. Weź jedno pytanie, na które obecne raporty odpowiadają sprzecznie.
2. Zbierz istniejące schematy. ERD, słowniki pól, raporty i próbki rekordów pokażą faktyczne źródła, a nie tylko deklarowaną architekturę.
3. Uzgodnij definicje z właścicielami procesu. Rozdziel klienta, kontakt, kontrahenta i płatnika; rozpisz statusy i zdarzenia zmieniające ich znaczenie.
4. Narysuj mały model pojęciowy. Typy obiektów i nazwane relacje wystarczą na początek. Dodaj ograniczenia tylko tam, gdzie wynikają z procesu.
5. Powiąż pojęcia z polami i identyfikatorami. Zapisz pochodzenie, odświeżanie i sposób rozwiązania konfliktu między źródłami.
6. Sprawdź pytanie na danych i wyjątkach. Porównaj wynik z ręcznie ocenioną próbką. Zapisz przypadki, dla których model nie potrafi rozstrzygnąć tożsamości lub stanu.

Jeśli firma potrzebuje przenośnych, formalnych definicji, może rozważyć OWL 2 do opisu pojęć oraz SHACL do walidacji grafu RDF. To opcje techniczne, a nie obowiązkowy pierwszy krok MŚP. Czasem wystarczą zatwierdzony słownik, tabele mapujące i testy danych. Gdy relacje trzeba intensywnie przeszukiwać, osobnym pytaniem jest wybór grafu i bazy grafowej.

Kiedy pozostać przy ERD i SQL?

Jeżeli aplikacja ma jedno wiarygodne źródło, mało spornych pojęć i stabilne raporty, dodatkowa warstwa pojęciowa może zwiększyć koszt utrzymania bez poprawy decyzji. Zostań przy istniejącym modelu i dopisz definicje do miejsc, w których pojawiają się niejasności. Ontologia zaczyna się opłacać, gdy to samo słowo znaczy co innego w różnych działach, relacje między systemami decydują o wyniku albo agent ma korzystać z danych bez zgadywania znaczenia kolumn.

Pierwszy wynik pracy nie musi być bazą grafową. Powinien nim być model, który właściciele danych rozumieją i potrafią przetestować. Jeśli w firmie brakuje mapy źródeł i odpowiedzialności, zobacz zakres audytu i mapy danych we współpracy. Dopiero po tej pracy wybór platformy staje się porównaniem rozwiązań tego samego problemu.