Za mało informacji

Innym odcieniem problemu z danymi nieco wiekowymi może okazać się zbyt mały ładunek informacyjny niesiony przez nie. Cóż, gdyby ktoś wcześniej mógł przewidzieć reperkusje tego, na pewno sprawa potoczyłaby się w przyszłości nieco lepszymi torami. Prosty przykład demonstrujący genezę tego zjawiska może wyglądać następująco. W osobowej bazie danych gromadzi się informacje o niepełnosprawności. Pierwotnie kod 0 oznaczał pełnosprawnego, a 1 niepełnosprawnego. Po kilku latach zmieniły się przepisy co do sposobu ewidencjonowania niepełnosprawności, zwiększające szczegółowość opisu z uwzględnieniem rodzaju niepełnosprawności. I tak przyjęto, że niesprawność narządów ruchu będzie kodowana jako 1, wzroku jako 2 a słuchu jako 3. Z braku lepszych rozwiązań, wszystkie historyczne zapisy pozostały niezmienione, co automatycznie spowodowało przypisanie wszystkich "starych" niepełnosprawnych do nowej grupy, co było prawdziwe zapewne tylko w jakiejś części. Przy następnej regulacji przepisów postanowiono określać również stopień tej niepełnosprawności, i tak, 10 oznaczało umiarkowaną niepełnosprawność narządów ruchu, a 11 znaczną ich niepełnosprawność. Analogicznie postąpiono z kwalifikacjami pozostałych niepełnosprawności. Skutkiem tych posunięć wszyscy archiwalni niepełnosprawni znaleźli się w aktualnej grupie z umiarkowaną niepełnosprawnością narządów ruchu. A więc wystarczy lekka zmiana (w tym wypadku rozszerzenie) zasad kwalifikacji, aby stanąć przed faktem niewydolności informacyjnej danych. Można w tym wypadku zasugerować utworzenie magazynującej pojęcia starsze grupy o odrębnym kodzie (znanym zwykle jako "inne"), co jest tylko częściowo skuteczne, gdyż należy zauważyć, że do tego worka trafialiby wszyscy niepełnosprawni z okazji każdego procesu rozszerzania kwalifikacji.

Przechowywać, gdy nie przeszkadza

W obu opisanych przypadkach, jak również w szeregu do nich podobnych, żadne automatyczne procedury korekcji czy konwersji nie wchodzą w grę, gdyż brakuje jednoznacznych odwzorowań starej i nowej streści. Wyjścia z tych sytuacji mogą być następujące:

- zgadzamy się na przechowywanie informacji aktualnie nieprawdziwej, jeśli nie blokuje to lub nie zakłóca procesu przetwarzania; warunkiem dopuszczającym do stosowania tego rozwiązania jest wiedza użytkowników dotycząca zjawiska, jego skali i datowania

- informację nieprzekształcalną w jej aktualny odpowiednik wkładamy do kontenera z napisem "inne", o ile sama aplikacja radzi sobie z tego rodzaju zapisami; najlepiej też informację datować, gdyż w worku tym, wraz ze zmianami przepisów, zasadami kwalifikacji czy wreszcie zmianami samych aplikacji i struktur danych, będą pojawiać się kolejne wpisy, ale niosące już odmienną treść - trzeba więc rozróżniać jedne "inne" od drugich.

W ślad za zmianami

O ile dane są w jakimś sensie tylko danymi opisującymi obiekt, ale nie biorą udziału w przetwarzaniu jako dane wejściowe dla zadania algorytmicznego, to ich nieprzystawalność na przestrzeni czasu nie odgrywa aż tak wielkiego zagrożenia. Znacznie gorzej ma się aplikacja (nie mówiąc o jej użytkownikach), która sięgnie do pewnych nieprzystających zapisów historycznych i proces obliczeniowy zakończy się błędnie - w sposób sygnalizowany lub nie. Zła długość łańcucha tekstowego, niewłaściwy format liczbowy, niedozwolone znaki - to typowy zestaw możliwych zakłóceń, jakie mogą wnieść wleczone za systemem, stare dane, z których korzystano kiedyś w przeszłości i które były tolerowane przez niegdysiejszą aplikację. Po którejś zamianie systemów zapomniano o testowaniu całościowym, ograniczając się jedynie do skontrolowania reakcji na jakość bieżących zestawów danych. I nagle ktoś, sięgając do przeszłości, zachwiał całą logiką nowego oprogramowania.