Niedoceniona migracja bazy danych SQL (2/2)

Jak podejść do migracji danych?

• Niespójne dane. Umowy, w których data początku jest późniejsza niż data końca umowy? Faktury, w których nasz system podzieli 100 złotych na 0 jednostek. Jak przenieść takie dane i co wstawić w docelowym systemie.  Kto ma odpowiadać za wyczyszczenie danych?
• Interpretacja danych. 30 czerwca, 30 czerwca 23:59.997 czy 1 lipca godzina 00 – to ta sama data końca obowiązywania umowy? Czy umowa została faktycznie zawarta w 1900-01-01, czy może data zawarcia jest nieznana? Co oznacza kolumna IdOther?
• Konieczność utworzenia słownika.  Warszawa, Wszawa, Wa-wa, Wrszawa – ile będziemy mieć stolic Polski w słowniku po uruchomieniu automatycznego procesu migracji? Jak pozbyć się błędów i duplikatów?  A co ze Świdnicą, Czarną czy Bolesławcem (powiaty i gminy o identycznych nazwach) - czy innymi danymi, w których ten sam tekst oznacza dwa fizyczne byty?
• Brakujące pola. REGON dla firmy, Nazwisko panieńskie matki, współrzędne geolokalizacyjne. A jeżeli stara aplikacja przechowywała tyko kwoty brutto, a nowa potrzebuje stawki VAT, która mogła zmienić się na przestrzeni lat? Co zrobić, jeżeli nasza aplikacja zależy od tych danych, a nie ma ich w bazie źródłowej? Czy trzeba ręcznie przeglądać każą pozycję faktury z dziennikiem ustaw, szukając obowiązującej stawki VAT?
• Utrata danych – Co z danymi, których nie ma gdzie umieścić w strukturze nowej aplikacji – czy należy je zachować, czy tracimy je bezpowrotnie wraz ze starym systemem? Np. Baza CV lub Leadów z dopiskami w stylu – zadzwonić po 19 marca?
• Konwencje w danych. Czy wiemy siadając do procesu migracji, że faktura o numerze rozpoczynającym się od DL kwota 150 oznacza 150 dolarów a od FVR oznacza 150 zł? A czy klient 012/O1 ma coś wspólnego z klientem 012?
• Wiedza domenowa (a raczej jej brak). Baza danych, w której zamiast nazw pól znajdujemy długą listę Id rekordu, id pola, wartość. Czy na pewno nasi inżynierowie mają wiedzę domenową, aby prawidłowo zanalizować? Czy rozpoznają znaczenie np. poszczególnych pól standardu MARC21, czy innego standardu formatu branżowego?

Przykład ze standardu MARC21

• Automatyka nowej aplikacji. Co się stanie po przeniesieniu danych ze starego systemu reklamacyjnego? Czy nagle 100 tys. osób nie dostanie maili p.t. „Twoja reklamacja została odrzucona/zaakceptowana?” Czy system księgowy nie stwierdzi, że ma setki zaległych faktur do automatycznego zapłacenia i wykona automatyczne przelewy?

Powyższa lista przykładowych problemów jest na pewno niepełna, ale mam nadzieję, że przekonałem czytelnika, iż projekt migracji danych to coś zdecydowanie więcej niż umiejętność przeczytania daty z Oracle i włożenia jej do MySql lub odwrotnie.