Mapowanie danych między systemami polega na określeniu, z którego pola pochodzi dana wartość, do którego pola ma trafić i czy po drodze wymaga przekształcenia. Dobre mapowanie uwzględnia nie tylko nazwy pól, ale także ich znaczenie biznesowe, typy danych, formaty, słowniki wartości oraz sposób postępowania z brakującymi lub nietypowymi danymi. Najwygodniej zapisać te ustalenia w jednej tabeli, która stanie się specyfikacją dla osób wdrażających integrację.
Co to jest mapowanie pól danych?
Mapowanie pól danych to przyporządkowanie elementów znajdujących się w systemie źródłowym do odpowiadających im elementów systemu docelowego. Nie zawsze oznacza ono proste kopiowanie wartości z jednej kolumny do drugiej.
Załóżmy, że system CRM przechowuje dane klienta w polach customer_id, first_name, last_name i status, natomiast system docelowy oczekuje pól external_id, full_name i customer_status. Identyfikator można przenieść bez zmian, ale imię i nazwisko trzeba połączyć w jedną wartość. Status może z kolei wymagać zamiany na kod używany przez drugi system.
Mapowanie jest potrzebne wszędzie tam, gdzie dwa rozwiązania inaczej opisują te same informacje. Dotyczy to zarówno bezpośrednich integracji aplikacji, jak i elektronicznej wymiany danych, w której informacje przekazywane pomiędzy systemami również muszą mieć strukturę zrozumiałą dla odbiorcy.
Najważniejsze jest znaczenie danych. Pole o nazwie date w jednym systemie może przechowywać datę utworzenia rekordu, a w drugim datę realizacji zamówienia. Sama zgodność nazw nie wystarcza więc do stwierdzenia, że pola można ze sobą połączyć.
Jak mapować dane między systemami krok po kroku?
Mapowanie warto rozpocząć jeszcze przed implementacją wymiany danych. Im dokładniej opisane są zasady, tym mniej decyzji trzeba podejmować później podczas konfiguracji lub programowania integracji.
Określ system źródłowy, docelowy i zakres danych
Najpierw trzeba ustalić kierunek przepływu. Należy wskazać, który system jest źródłem informacji, który je odbiera oraz jakie obiekty biznesowe będą wymieniane.
Przykładowy zakres może wyglądać następująco:
- klient z CRM trafia jako kontrahent do ERP,
- zamówienie ze sklepu internetowego trafia do systemu magazynowego,
- informacja o dostępności produktu wraca z magazynu do sklepu.
Już na tym etapie warto określić, czy dane płyną tylko w jednym kierunku, czy mają być synchronizowane w obie strony. Nie trzeba natomiast rozstrzygać zasad mapowania na podstawie samego kanału transmisji. Pola trzeba dopasować niezależnie od tego, czy wykorzystano API czy wymianę plików.
Zbierz opis pól po obu stronach
Aby prawidłowo ustalić, jak dopasować pola między systemami, potrzebna jest większa ilość informacji niż lista ich technicznych nazw.
Dla istotnych pól warto znać:
- nazwę techniczną,
- znaczenie biznesowe,
- typ danych,
- dopuszczalną długość,
- informację, czy pole jest wymagane,
- przykładową wartość,
- dopuszczalne wartości lub używany słownik.
Przykładowe dane są szczególnie przydatne, ponieważ ujawniają różnice niewidoczne w samej dokumentacji. Pole opisane jako tekst może w praktyce zawierać kod, numer z zerami na początku albo wartość składającą się według określonego wzorca.
Dopasuj pola źródłowe do docelowych
Najprostszy przypadek to relacja jeden do jednego. customer_id może zostać przypisane do external_id, jeżeli oba pola przechowują ten sam identyfikator i mają zgodne wymagania.
Nie każde mapowanie jest jednak tak proste. Możliwe są również sytuacje, w których:
- kilka pól źródłowych tworzy jedno pole docelowe,
- jedno pole źródłowe trzeba rozdzielić na kilka pól,
- pole źródłowe nie ma odpowiednika,
- system docelowy wymaga informacji, której źródło nie przechowuje.
Przykładem pierwszego przypadku jest połączenie first_name i last_name w full_name. Odwrotna sytuacja pojawia się, gdy źródło przechowuje cały adres w jednym polu, a system docelowy oczekuje osobno ulicy, numeru budynku, kodu pocztowego i miejscowości.
Szczególnej uwagi wymaga pole obowiązkowe po stronie odbiorcy, jeżeli źródło nie dostarcza odpowiedniej wartości. Wtedy trzeba świadomie określić, skąd informacja zostanie pobrana, czy może zostać wyliczona, czy można zastosować ustaloną wartość domyślną. Nie powinno się pozostawiać takiej decyzji do przypadkowego rozstrzygnięcia podczas implementacji.
Określ potrzebne transformacje danych
Po wskazaniu pola źródłowego i docelowego należy sprawdzić, czy wartość może zostać przeniesiona bez zmian.
Transformacją może być między innymi:
- połączenie kilku wartości,
- rozdzielenie jednej wartości na kilka części,
- zmiana sposobu zapisu tekstu,
- przeliczenie jednostki,
- konwersja liczby do oczekiwanego formatu,
- usunięcie znaków, które nie powinny trafić do systemu docelowego,
- zmiana formatu daty.
Różne formaty dat w integracji są częstym przykładem problemu, który łatwo przeoczyć. Jeden system może przechowywać datę jako 13.08.2026, a drugi oczekiwać zapisu 2026-08-13. W przypadku czasu trzeba dodatkowo ustalić sposób reprezentacji godziny i strefy czasowej, jeżeli ma ona znaczenie dla wymienianych informacji.
Reguła powinna być opisana jednoznacznie. Zamiast wpisywać w dokumentacji jedynie „konwersja daty”, lepiej określić format wejściowy, format oczekiwany po stronie docelowej i zasady postępowania z wartością, której nie da się poprawnie przekształcić.
Zmapuj słowniki wartości
Mapowanie słowników wartości w integracji jest potrzebne wtedy, gdy dwa systemy opisują ten sam stan za pomocą innych kodów.
System źródłowy może korzystać ze statusów:
NEW,ACTIVE,BLOCKED.
System docelowy może natomiast posługiwać się kodami:
1,2,9.
W specyfikacji trzeba wtedy zapisać jednoznacznie:
NEW->1,ACTIVE->2,BLOCKED->9.
Samo wskazanie, że pole status jest mapowane na customer_status, nie wystarczy. Bez osobnego mapowania wartości system docelowy może otrzymać kod, którego nie rozumie.
Trzeba również ustalić zachowanie na wypadek pojawienia się nowej wartości. Jeżeli administrator pierwszego systemu doda status SUSPENDED, integracja nie powinna samodzielnie zgadywać jego znaczenia. Reguła powinna określać, czy taka wartość ma zostać odrzucona, oznaczona do wyjaśnienia, czy przekształcona zgodnie z wcześniej ustalonym mechanizmem.
Określ zasady dla pustych i nieprawidłowych wartości
Warto rozróżnić brak pola, pustą wartość, null oraz wartość niezgodną ze słownikiem. W zależności od systemu mogą one oznaczać coś innego.
Dla każdego istotnego pola należy ustalić, co zrobić, gdy wartość nie istnieje. Możliwe rozwiązanie zależy od wymagań konkretnej integracji. Czasami poprawne będzie pozostawienie pola pustego, innym razem zastosowanie wartości domyślnej, a przy danych wymaganych konieczne może być zatrzymanie przetwarzania danego rekordu.
Najważniejsze, aby zasada była wcześniej opisana i nie zależała od przypadkowej interpretacji osoby wdrażającej połączenie.
Jak powinna wyglądać tabela mapowania danych?
Tabela mapowania danych pozwala zebrać najważniejsze ustalenia w jednym miejscu. Dzięki temu analityk, właściciel biznesowy i osoba wdrażająca integrację pracują na tej samej specyfikacji.
Przykładowa tabela może wyglądać tak:
| Pole źródłowe | Przykładowa wartość | Pole docelowe | Reguła mapowania | Wymagane | Uwagi |
|---|---|---|---|---|---|
customer_id | 45821 | external_id | bez zmian | tak | identyfikator źródłowy |
first_name + last_name | Jan + Kowalski | full_name | połącz ze spacją | tak | dwa pola do jednego |
status | ACTIVE | customer_status | ACTIVE -> 2 | tak | mapowanie słownika |
created_at | 13.08.2026 | created_at | zmień na 2026-08-13 | tak | ujednolicony format daty |
phone | +48 600 000 000 | phone_number | zastosuj ustaloną normalizację | nie | pole opcjonalne |
W rzeczywistym projekcie tabelę można rozszerzyć o typ danych źródłowych i docelowych, maksymalną długość, wartość domyślną, dopuszczalne kody czy komentarz biznesowy.
Dobra tabela nie jest jedynie spisem nazw pól. Powinna pozwalać innej osobie zrozumieć, jak dokładnie ma powstać wartość docelowa, bez konieczności domyślania się reguł.
Na co uważać podczas mapowania danych?
Jednym z najczęstszych błędów jest automatyczne łączenie pól tylko dlatego, że mają podobne nazwy. customer_number może być identyfikatorem technicznym w jednym systemie, a numerem widocznym na dokumentach w drugim. Najpierw trzeba więc porównać znaczenie biznesowe.
Problemem bywają także niezgodne typy danych. Kod produktu zapisany w jednym systemie jako liczba może w innym występować jako tekst. Ma to znaczenie zwłaszcza wtedy, gdy wartość może zaczynać się od zera lub zawierać litery.
Trzeba sprawdzić również długość pól. Jeżeli system źródłowy pozwala zapisać 500 znaków opisu, a docelowy przyjmuje tylko 100, przed uruchomieniem integracji należy ustalić sposób postępowania z dłuższą treścią. Automatyczne obcięcie wartości bez uzgodnienia może prowadzić do utraty istotnej informacji.
Podobnie należy traktować wartości, dla których nie istnieje odpowiednik w drugim systemie. Brak mapowania nie powinien automatycznie oznaczać pominięcia danych. Najpierw trzeba stwierdzić, czy pole jest rzeczywiście niepotrzebne, czy też wymaga dodatkowej reguły.
W przypadku słowników warto uwzględnić nie tylko obecne kody, ale również sytuację, w której jeden z systemów zacznie wysyłać nową wartość. Dzięki temu wiadomo z góry, jak integracja ma reagować na dane spoza ustalonego zestawu.
Jak sprawdzić, czy mapowanie jest kompletne?
Przed przekazaniem specyfikacji do wdrożenia warto przejrzeć ją od strony systemu docelowego. Każde potrzebne pole powinno mieć określone źródło albo świadomie ustaloną regułę postępowania w przypadku braku wartości.
Należy sprawdzić przede wszystkim:
- czy każde wymagane pole docelowe ma źródło danych,
- czy znane są typy i formaty wartości,
- czy opisano wszystkie potrzebne transformacje,
- czy zmapowano wartości słownikowe,
- czy określono zasady dla pustych i nieznanych wartości,
- czy uwzględniono ograniczenia długości pól,
- czy do reguł dołączono przykładowe dane,
- czy osoba nieuczestnicząca w analizie potrafiłaby wdrożyć mapowanie bez zgadywania.
Tak przygotowana specyfikacja powinna zostać jeszcze zweryfikowana na danych typowych oraz przypadkach brzegowych. Szczegółowe przygotowanie scenariuszy należy już do testowania integracji między systemami, dlatego samo mapowanie powinno przede wszystkim dostarczyć testowalnych i jednoznacznych reguł.
Najlepszym kryterium jakości mapowania jest prostota odpowiedzi na cztery pytania: skąd pochodzi wartość, dokąd trafia, jak należy ją przekształcić i co zrobić, gdy nie da się zastosować standardowej reguły. Jeżeli dla każdego istotnego pola odpowiedzi są jednoznaczne, specyfikacja nadaje się do wykorzystania podczas implementacji.
