---
title: "Modelowanie danych: od ERD do ontologii firmy"
url: "https://majchrzycki.com/blog/modelowanie-danych-od-erd-do-ontologii-firmy"
description: "ERD pokazuje strukturę bazy, a ontologia porządkuje znaczenie pojęć między systemami. Praktyczna ścieżka dla MŚP na przykładzie zamówienia."
---

# Modelowanie danych: od ERD do ontologii firmy

17 lutego 2026· Aktualizacja: 29 września 2026·4 min czytania·Krzysztof Majchrzycki

Temat: [Ontologia firmy](https://majchrzycki.com/blog/filar/ontologia-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](https://majchrzycki.com/blog/filar/ontologia-firmy). Jeśli dopiero poznajesz słownictwo, zacznij od [prostego wyjaśnienia ontologii, taksonomii i grafu](https://majchrzycki.com/blog/ontologia-taksonomia-model-danych-prosto-dla-msp). 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](https://medium.com/timbr-ai/from-erds-to-ontologies-why-data-modelers-are-making-the-switch-6e37f04dc324) 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](https://majchrzycki.com/blog/dlaczego-dzialy-roznie-licza-termin-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](https://www.w3.org/TR/owl2-primer/) do opisu pojęć oraz [SHACL](https://www.w3.org/TR/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](https://majchrzycki.com/blog/ontologia-i-bazy-grafowe-w-ai-dla-msp).

## 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](https://majchrzycki.com/wspolpraca). Dopiero po tej pracy wybór platformy staje się porównaniem rozwiązań tego samego problemu.

-   Dane i analityka
-   Agenci AI

## Uporządkuj pierwszy krok z AI

Bezpłatny poradnik pomaga wybrać proces, pytania diagnostyczne i kolejność działań.

[Pobierz poradnik](https://majchrzycki.com/darmowy-poradnik-transformacji-ai-dla-firmy)

Strony poradnika transformacji AI: rysunki i opisy cyfrowego modelu firmy

## Czytaj dalej

-   [Ontologia, taksonomia i model danych prostym językiem](https://majchrzycki.com/blog/ontologia-taksonomia-model-danych-prosto-dla-msp)
-   [Ontologia i bazy grafowe w AI: co jest potrzebne MŚP?](https://majchrzycki.com/blog/ontologia-i-bazy-grafowe-w-ai-dla-msp)
-   [Protégé Desktop i WebProtégé: ontologia dla AI OS](https://majchrzycki.com/blog/protege-ontologia-ai-os)
-   [Jak zbudować ontologię firmy i podłączyć do niej dane?](https://majchrzycki.com/blog/jak-zbudowac-ontologie-firmy-dane-reguly-agenci)