Niedoceniona migracja bazy danych SQL (2/2)
Kontynuując wątek związany z migracją danych z poprzedniego wpisu. Przystępując do prac nad migracją danych programiści / inżynierowie często skupiają się nad aspektem technicznym oraz fizyczną transformacją danych. Niestety większość problemów jest jednak dużo bardziej złożona i często niezwiązana z aspektem technicznym.
Jak podejść do migracji danych?
Nasze doświadczenia pokazują, że ewentualnych trudności, które mogą wystąpić w czasie migrowania danych między systemami należy szukać w:
- 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.
1 komentarze
olo26 września 2016 12:57
dobry art., pamiętam jak próbowałem podobnymi argumentami przekonać w dużej firmie zespół księgowych, prezesów i innych "z góry" że wymienione zagrożenia są poważne i mogą spowodować chaos nad którym nie zapanują. Dodatkowo cena 50 tyś. za migracje jaką zażądałem została wyśmiana. Podziękowaliśmy sobie nawzajem za współpracę. Firma zdecydowała się na tańsze rozwiązanie i zatrudniła inną firmę do tej operacji. Po 3 tygodniach skontaktowali się ze mną że godzą się na moje warunki. Podniosłem cenę do 80 tyś. zł. bez problemu się zgodzili, ale co się napociłem to tylko ja wiem.
Zgłoś