Jednym z częstszych w dzisiejszych czasach przypadków powstawania problemów z jakością danych jest konsolidacja systemów informatycznych, wynikająca z działań biznesowych, będących skutkiem integracji wewnętrznej systemów lub skutkiem fuzji i przejęć firm. Rzadko kiedy w takich bazach buduje się interfejsy sprzęgające oba obce systemy, bo najczęściej problem nie leży w technice współpracy oprogramowania, ale w logice danych.

Konieczność ujednolicenia metod identyfikacji obiektów jest tu celem nadrzędnym. W związku z zamierzoną konsolidacją jeden system będzie promowany do roli wiodącego, a drugi zostanie zdeklasowany do roli systemu schyłkowego. Dane z baz tego drugiego muszą zostać przekonwertowane do systemu miłościwie panującego i skonsolidowane z już tam istniejącymi. Nie byłoby z tym problemu, gdyby struktury obu systemów były w miarę przystające, ale zdarza się to niezmiernie rzadko. Zazwyczaj po obu stronach występuje niedopasowanie informacyjne powodujące, że w trakcie konwersji danych część atrybutów pozostaje niewykorzystana, gdyż w systemie docelowym nie występują. Gorsza jest sytuacja przeciwna, gdy w systemie źródłowym brakuje pewnej klasy danych wymaganych w bazie docelowej. O ile są to dane, które można na poły algorytmicznie uzupełnić (np. brakujące kody pocztowe przy nazwach miejscowości), to użytkownikom pozostanie korekta jakości wykonania tego procesu. Nie zawsze bowiem nazwa miejscowości skojarzona jest tylko z jednym kodem, w związku z czym dobór algorytmiczny jest w tym przypadku stochastyczny i wymaga późniejszego dookreślenia przez użytkownika dysponującego szerszą niż algorytm wiedzą i możliwościami analitycznymi. Dobrym przykładem algorytmicznej podatności na przekształcanie danych jest pozyskiwanie daty urodzenia z numeru PESEL, ale już nigdy odwrotnie. Są takie rodzaje informacji, których w żaden sposób algorytmicznie się nie podpowie i trzeba je wprowadzić ręcznie.

Wzorzec do ustalenia

W przypadku konsolidacji danych występuje jeszcze jeden problem - nazwijmy go problemem koagulacji danych - odróżniający ten zabieg od zwyczajnej konwersji, gdzie ilość danych pozostaje praktycznie niezmieniona. Otóż w tym przypadku może dojść do zjawiska zwielokrotniania informacji o przystających, ale nie wszystkich jednakowych cechach. Jeśli scalamy dwie bazy magazynowe o przybliżonym asortymencie, to z pewnością w docelowej bazie nieraz pojawią się podwójne obiekty tego samego rodzaju, ale opatrzone odmiennymi charakterystykami. Wiadomym jest, że niektóre cechy będą podlegały sumowaniu, a inne ulegną redukcji lub wręcz zostaną pominięte. Na przykład ilość towaru na stanie musi zostać zsumowana z obu źródeł danych, natomiast opis asortymentu, czyli tekstowa informacja charakteryzująca cechę nazewniczą wystarczy tylko jedna. Jeśli jakąś informację redukujemy wybierając z dwóch wartości jedną, zawsze pozostanie otwartą kwestią metoda postępowania: która z tych informacji awansuje do roli wzorca i zaistnieje na stałe w nowym systemie, a która przepadnie w niebycie.