Niedoceniona migracja bazy danych SQL (1/2)

Przygotowując się do wymiany jakiegokolwiek systemu informatycznego należy wziąć pod uwagę migrację danych – jest to niestety często bagatelizowany etap projektu, który w trakcie realizacji równie często się komplikuje, powodując opóźnienia projektów.

Zadanie zaplanowane na tydzień, po pół roku przestaje cieszyć.

Producenci oprogramowania na zamówienie oraz zespoły developerskie swoją uwagę skupiają wyłącznie na funkcjonalności nowych aplikacji. A jak pokazuje doświadczenie – to nieodpowiednia jakość i spójność danych niejednokrotnie są przyczynami problemów w funkcjonowaniu systemów. Ogromnym błędem popełnianym przez wdrożeniowców jest traktowanie migracji danych, jako zadania o wyłącznie technicznym charakterze - tymczasem jest ono zarówno techniczne, jak i biznesowe.

Przy tworzeniu nowej aplikacji obok tematu migracji danych z poprzedniego systemu, pojawia się również stwierdzenie o integracji lub synchronizacji danych. Zanim zaczniemy prace warto upewnić się, że mamy na myśli to samo, co klient.

Jak należy traktować migrację danych?

Jeżeli aplikacja ma korzystać z danych wprowadzonych w innej aplikacji to zwykle jest to jeden z poniższych przypadków.

• Jednorazowa migracja przed startem aplikacji. Stosunkowo najprostsza sytuacja. Przed uruchomieniem aplikacji w środowisku produkcyjnym usuwamy dane testowe i wgrywamy dane ze starego systemu. Podstawowym problemem jest transformacja danych i sprawdzenie ich poprawności.
• Jednorazowa migracja po starcie aplikacji. Aplikacja startuje dla wybranej grupy nowych klientów, którzy stają się jej testerami. Po ustabilizowaniu się aplikacji należy przenieść dane ze starego systemu. W stosunku do poprzedniego przypadku pojawia się konieczność wykrycia, które dane ze starego systemu odpowiadają danym już istotnym w nowym systemie. Należy też ustalić, które dane są aktualne.
• Migracja przyrostowa. W tym przypadku dane przenosimy stopniowo ze starego systemu do nowego. W tym przypadku dodatkowo należy zadbać o to, aby nie duplikowały się dane wspólne dla każdej fazy migracji.
• Synchronizacja. Z perspektywy developerów - najgorszy przypadek. Dane są wkładane i do starych systemów i do nowych i odpowiednie zmiany muszą się między systemami propagować. Jest to jednocześnie najczęstszy przypadek w dużych firmach posiadających wiele równoległych systemów informatycznych.
• Integracja. Przypadek, w którym nie przenosimy danych, ale część danych wymaganych do działania systemu znajduje się w innych aplikacjach. Należy zastanowić się, jakie są wymagania, co do niezawodności i wydajności – może się okazać, że musimy jednak kopiować część danych, aby zabezpieczyć sprawne działanie aplikacji.

Istotna jest również wartość biznesowa migrowanych danych. To od niej zależy jak musimy podejść do potencjalnie błędnych danych. Inaczej można podejść, jeżeli dla nowego systemu reklamacyjnego migrujemy dotychczasowych klientów aplikacji handlowej, a inaczej, jeżeli migrujemy dane na podstawie, których będziemy wystawiać klientom faktury. O ile w pierwszym przypadku najwyżej pechowy klient drugi raz poda swoje dane (i jest to dopuszczalne) o tyle w drugim nie chcemy, aby klient z niepoprawnym NIPem był zwolniony z czynszu za wynajem pomieszczeń biurowych.

W skrajnym przypadku, jeżeli nie zrozumiemy się z klientem, może się okazać, że w wycenie pojawi się napisanie prostych skryptów transformujących dane, a zakres prac obejmuje przeglądanie i sprawdzanie ręcznie 100 tys rekordów w bazie pod kątem ich poprawności, rekord po rekordzie.

Mam nadzieję, że poniższy tekst spowoduje, że u czytelnika zapali się sygnał ostrzegawczy, jeżeli mimochodem gdzieś w specyfikacji nowego projektu znajdzie stwierdzenie o konieczności przeniesienia danych lub integracji ze starym systemem.

Tyle tytułem pierwszej części - w następnej postaram się opowiedzieć o wybranych problemach, na które można natrafić przy migracji danych.