Wątpliwe, aby nawet jeden operator, mając do dyspozycji tylko jedno pole na adres, za każdym razem wpisywał go dokładnie w ten sam sposób. Wraz ze wzrostem liczby operatorów liczba formatów może okazać się bardzo długa. Można sobie wyobrazić różne style wpisywania danych adresowych - z kodem pocztowym lub bez, z nazwą ulicy na początku lub na końcu, z separatorami w postaci spacji lub przecinków itd. Kalejdoskop możliwych konfiguracji wydaje się niewyczerpany: gdzie dwóch operatorów, tam trzy style "uprawiania" danych. Odgórne zalecenia w kwestii jednolitego stylu też zazwyczaj się nie sprawdzają, może nawet nie tyle ze względu na złośliwość personelu, ile z powodu naturalnej skłonności człowieka do pomyłek. No i najważniejsze - przy swobodnym doborze formatu pola trudno wprowadzić informację z gotowej już listy miast, ulic i kodów, za każdym razem trzeba więc wpisywać je ręcznie.

Rozważmy zatem prosty przykład przeniesienia danych, gdzie w dotychczas używanym oprogramowaniu adres był informacją zawartą w jednym polu, podczas gdy w nowej wersji postanowiono wyodrębnić niezależne jednostki informacyjne.

Z załączonego w tabeli przykładu rozkładu danych wnioskujemy, że niezastosowany mechanizm algorytmiczny nie w każdym przypadku zadziałał poprawnie. Można oczywiście poszukiwać najlepszego algorytmu, mając jednak świadomość, że nie wszystko da się w miarę prosty sposób zaprogramować. Analiza wielu przypadków wymagałaby prawdopodobnie tak złożonych algorytmów, że koszty wytworzenia programu w celu jednorazowej migracji byłyby całkiem spore. Informacja występująca zaraz za kodem pocztowym może być z założenia nazwą miasta. Jakie jednak przyjąć założenia, gdy tego kodu nie podano, czego skutek pokazuje trzeci wiersz przykładowej tabeli? Tu przyjęto, że główna informacja, jeśli nie jest kodem pocztowym, stanowi nazwę miasta.

Analizator można oczywiście zaprząc do bardziej wytężonej pracy, np. nakazać, aby przyjmował, że dane mające charakter numeryczny (będące raczej tekstową reprezentacją cyfr), jeśli nie są kodem pocztowym, wskazują na to, że poprzedza je nazwa ulicy. Na tym nie koniec komplikacji. Mamy bowiem wieloczłonowe nazwy miast i ulic, w których separator raz występuje, a raz nie, z odstępami lub bez. Niektórzy operatorzy nie uznają przecinków, inni z kolei po przecinku nie stawiają spacji.

Kombinacje tego rodzaju niespójności można by mnożyć, a wraz z nimi pomysły na narzędzia służące do ich niwelowania.

Przepis na ból głowy

Utrata lub przeinaczenie informacji adresowych, jeśli nie stanowią one o podstawowym zakresie działania firmy utrzymującej ożywiony kontakt korespondencyjny ze swoimi klientami, nie jest jeszcze najgorszym z możliwych scenariuszy potencjalnych zaburzeń wynikających z rozbieżności w strukturze danych systemów starego i nowego. Ze znacznie gorszym efektem mamy do czynienia, gdy dane adresowe próbuje się wykorzystać do wiązania informacji z różnych, niespójnych ze sobą, baz danych. Niedawno doświadczyłem takiego przypadku przy okazji integracji dwóch systemów i muszę powiedzieć, że efekt nie był zachwycający.

Sytuacja była następująca: w każdym z dwóch niezależnych programów gromadzono pewne dane, które należało scalić w jeden spójny organizm. W jednej tabeli przechowywano nazwiska i numery PESEL, w drugiej zaś nazwiska i numery NIP. Obie tabele chciano scalić w jedną spójną bazę zawierającą nazwisko i oba identyfikatory. Nieszczęście polegało na tym, że każdy z systemów ewidencjonował te same osoby (klientów firmy), nadając im inne identyfikatory. Co oczywiste, jeden system nie wiedział o sposobie identyfikacji przyjętej w drugim. Gdyby istniały jednoznaczne identyfikatory osób, nie byłoby problemu - proste skojarzenie przez wspólny mianownik rozwiązałoby tę sprawę w kilka chwil. Brak wspólnego jednoznacznego systemu identyfikacji obiektów to typowa bolączka projektów integracyjnych prowadzonych na kanwie niezależnych zbiorów.

Ten niewdzięczny proceder trzeba jednak kiedyś w jakiś sposób zrealizować - raczej nie wchodziło w rachubę ponowne wprowadzanie wszystkich danych do nowego systemu. Przyjęto, że dane pochodzące z obu baz będą dodatkowo porównywane poprzez informacje drugorzędnie identyfikujące obiekty, a więc przez nazwisko i imię. Założenie o tyle niedoskonałe, że klientów o tych samych imionach i nazwiskach może być więcej, stąd nie jest to całkowicie pewny mechanizm weryfikacji. Jako dodatkowe kryterium przyjęto więc zgodność miejsca zamieszkania, a konkretnie nazwy miejscowości. Nazw ulic już nie uwzględniono, ponieważ wiązałoby to się ze zbyt dużą komplikacją analityczną.

Efekt tak przyjętej procedury był doskonały w 80%, tyle bowiem danych potrafiono przenieść automatycznie. Dane, które nie zakwalifikowały się podczas przenosin jako jednoznacznie pewne, przeniesiono bez uzupełniania jako przypadki do wyjaśnienia "na piechotę".

Przyczyny tej niedoskonałości porównawczej są dosyć oczywiste. Gromadząc dane w niespójnych systemach i zakładając nawet ich wzajemną strukturalną odpowiedniość, nigdy nie ma gwarancji, że są one po obu stronach aktualne i bezbłędne. W jednej bazie osoba może istnieć pod nazwiskiem panieńskim, podczas gdy w drugiej stan ten zmieniono.

Jeśli nawet założymy poprawność na tym poziomie, to nieuniknione są normalne pomyłki operatorów, z którymi automatyczna konwersja sobie nie radzi.

Nie traćmy nadziei

Opisując powyższe przypadki, chciałem pokazać, jak wielkie znaczenie dla spójności informacji ma właściwa struktura danych - dodajmy - zaproponowana już podczas projektowania systemu. Posiadanie systemów zintegrowanych, które niejako naturalnie rozstrzygają o wielu sprawach, może ułatwić życie i uchronić przed wydatkami - co, mam nadzieję, w sposób w miarę prosty i zrozumiały starałem się tu naświetlić. Ponieważ znaczenie spójnej i aktualnej informacji ciągle rośnie, trzeba starać się robić wszystko, aby tych jej cech nie utracić - choćby poprzez niefrasobliwą politykę projektowania oprogramowania. Jak głosi "starodawne" powiedzenie informatyczne: śmieci włożysz, śmieci wyjmiesz.