Zgodność typów w migracji

Zgodność typów w migracji wymaga sprawdzenia, czy typy danych źródłowych mają odpowiedniki w systemie docelowym.

Na czym polega zgodność typów danych

Zgodność typów w migracji oznacza sprawdzenie, czy każda wartość zapisana w systemie źródłowym może zostać poprawnie zapisana i odczytana w systemie docelowym. Nie wystarczy porównać samych nazw kolumn. Trzeba zestawić typ logiczny danych, zakres dopuszczalnych wartości, sposób przechowywania, dokładność, możliwość przyjmowania wartości pustych oraz reguły konwersji. Kolumna zawierająca datę, kwotę, identyfikator albo opis tekstowy może mieć różne typy w obu systemach, a mimo to migracja będzie poprawna, jeżeli mapowanie zachowa znaczenie danych.

Najprostsze mapowania obejmują typy o podobnych właściwościach, na przykład liczby całkowite, liczby zmiennoprzecinkowe, tekst oraz wartości logiczne. Ryzyko pojawia się wtedy, gdy typ docelowy ma mniejszy zakres albo niższą dokładność. Przeniesienie liczby całkowitej do typu o ograniczonym zakresie może zakończyć się błędem lub przepełnieniem. Zapis liczby dziesiętnej w typie zmiennoprzecinkowym może natomiast zmienić jej reprezentację z powodu zaokrągleń. Dlatego zgodność należy oceniać na podstawie rzeczywistych danych i reguł używanych przez aplikację.

Mapowanie liczb, tekstu i dat

W przypadku liczb trzeba sprawdzić zarówno zakres, jak i dokładność. Typ przeznaczony do przechowywania wartości całkowitych nie zachowa części ułamkowej, dlatego nie może zastąpić typu dziesiętnego bez jawnej reguły zaokrąglania albo odrzucania części po przecinku. Dla kwot finansowych istotne są precyzja i skala, czyli liczba cyfr łącznie oraz liczba cyfr po separatorze dziesiętnym. Jeżeli system źródłowy przechowuje cztery miejsca po przecinku, a docelowy tylko dwa, migracja może trwale zmienić wartości.

Tekst wymaga kontroli długości oraz kodowania znaków. Skrócenie pola z dłuższego tekstu do krótszego może spowodować obcięcie danych. Z kolei niezgodność kodowania może prowadzić do zastąpienia polskich znaków innymi symbolami albo do błędów podczas importu. Należy również rozróżnić tekst przeznaczony na krótki identyfikator od pola wielowierszowego, ponieważ oba mogą wyglądać podobnie, lecz podlegać innym ograniczeniom.

Daty i czas powinny być sprawdzane razem z informacją o strefie czasowej oraz dokładnością ułamków sekund. Data zapisana bez czasu nie jest równoważna znacznikowi zawierającemu godzinę. Podczas konwersji trzeba ustalić, czy wartość ma oznaczać czas lokalny, czas uniwersalny, czy jedynie dzień kalendarzowy. W przeciwnym razie po migracji rekord może zostać przypisany do innego dnia albo otrzymać godzinę przesuniętą względem wartości źródłowej.

Walidacja przed i po przeniesieniu danych

Przed migracją tworzy się tabelę mapowania, w której dla każdej kolumny zapisuje się typ źródłowy, typ docelowy, dopuszczalny zakres, sposób konwersji oraz reakcję na wartości nieprawidłowe. Warto osobno oznaczyć konwersje bezstratne i takie, które mogą zmienić dane. Do drugiej grupy należą między innymi redukcja liczby miejsc dziesiętnych, skracanie tekstu, usuwanie czasu z daty oraz zamiana wartości niepustej na pustą.

Kontrola nie powinna ograniczać się do sprawdzenia, czy narzędzie migracyjne zakończyło pracę bez komunikatu błędu. Należy porównać liczbę rekordów, liczbę wartości pustych, zakresy liczb, długości tekstów, najwcześniejsze i najpóźniejsze daty oraz sumy kontrolne dla wybranych pól. Dla danych uporządkowanych można porównać całe zestawy rekordów po kluczu identyfikującym. Jeżeli kolejność rekordów nie ma znaczenia, porównanie powinno opierać się na wartościach, a nie na pozycji w pliku lub tabeli.

Test migracji powinien obejmować dane typowe, graniczne i błędne. Przykładami przypadków granicznych są największa i najmniejsza obsługiwana liczba, tekst o maksymalnej długości, pusty tekst, wartość pusta, data z końca zakresu oraz znak spoza podstawowego alfabetu. Wyniki trzeba przeanalizować także po uruchomieniu aplikacji, ponieważ poprawna technicznie konwersja może być niezgodna z oczekiwaniami kodu. Program może na przykład traktować pusty tekst inaczej niż brak wartości albo oczekiwać identyfikatora jako tekstu mimo jego liczbowego wyglądu.

Znaczenie typów dla działania aplikacji po migracji

Niezgodność typów często ujawnia się dopiero podczas filtrowania, sortowania, obliczeń lub zapisu nowych rekordów. Identyfikator przeniesiony z liczby do tekstu może przestać działać w porównaniu z inną tabelą, jeżeli aplikacja używa różnych reguł konwersji. Zmiana typu daty może wpłynąć na sortowanie i zakresy wyszukiwania. Zmiana typu logicznego może wymagać mapowania wartości takich jak 0 i 1, prawda i fałsz albo określone symbole tekstowe. Każdy taki przypadek powinien mieć opisaną regułę, a nie być pozostawiony automatycznej konwersji.

Przy diagnostyce problemu warto ustalić, na którym etapie powstała rozbieżność: podczas odczytu źródła, transformacji, zapisu do systemu docelowego czy późniejszego odczytu przez aplikację. Pomocne są próbki rekordów zapisane przed i po migracji oraz logi zawierające nazwę pola, rodzaj konwersji i informację o odrzuconej wartości. Nie należy umieszczać w logach całej zawartości pól, jeżeli mogłoby to ujawnić dane użytkowe. Najważniejsze jest zachowanie identyfikatora rekordu i technicznego opisu błędu, aby można było odtworzyć ścieżkę konkretnej wartości.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego w przypadku problemów z działaniem komputera po migracji można zlecić sprawdzenie sprzętu, systemu oraz podstawowej konfiguracji środowiska pracy. Sama zgodność typów pozostaje jednak zagadnieniem logicznym dotyczącym projektu danych, mapowania oraz testów wykonanych przed i po przeniesieniu.