Dane jak utrapienie

Spójność danych nie bierze się znikąd, nie musi być jednak wynikiem morderczego wysiłku sztabu ludzi. O jakości danych trzeba myśleć na etapie projektowania systemów.

Spójność danych nie bierze się znikąd, nie musi być jednak wynikiem morderczego wysiłku sztabu ludzi. O jakości danych trzeba myśleć na etapie projektowania systemów.

Przenoszenie istniejących danych do nowego systemu to jedno z trudniejszych zagadnień szeroko rozumianego wdrożenia, przede wszystkim dlatego że stare i nowe struktury danych rzadko kiedy do siebie przystają. Nie byłoby to być może aż tak kłopotliwe, gdyby projektanci systemów: źródłowego i docelowego trzymali się jakichś w miarę jasnych reguł. Praktyka przeczy jednak wszelkim zasadom - nawet tym, wydawałoby się, zdroworozsądkowym. Spektakularnym tego przykładem mogą być różne podejścia do porcjowania informacji w bazie, a dokładnie powszechny brak atomizacji pól danych prowadzący do chaotycznego poszukiwania sensu w galimatiasie tabel i pól.

Pokłony dla formalizmu

Wyniesienie danych z systemu dotychczasowego do nowego są zwane konwersją. To tylko jeden z wielu elementów skomplikowanego procesu, jakim jest zmiana systemu, ale jakże istotny! To trudne zadanie można zrealizować na cztery sposoby.

Pierwsza metoda to konwersja bezpośrednia. To najbardziej ryzykowne przedsięwzięcie, polegające na radykalnej zamianie dotychczasowego systemu na nowy. Takie podejście zakłada, że w razie niepoprawnego działania nowego oprogramowania użytkownicy nie będą dysponować rozwiązaniami alternatywnymi, ale równocześnie nie mają już możliwości powrotu do stanu poprzedniego. Sprawa jest, delikatnie mówiąc, bardzo ryzykowna.

Drugi sposób to konwersja równoległa - systemy stary i nowy funkcjonują równolegle, aż do momentu osiągnięcia przez nowy system stanu pełnej niezawodności. Procedura tego rodzaju jest kosztowna i uciążliwa, dane muszą być bowiem wprowadzane równolegle w obu systemach. Arytmetycznie rzecz biorąc, ilość pracy się podwaja, co w wielu przypadkach skutecznie tę metodę wyklucza.

Kolejne podejście to konwersja pilotowa - początkowo tylko wyznaczona część przedsiębiorstwa wykorzystuje nowy system, wypróbowując jego działanie przed rozpowszechnieniem go w całej firmie. Metoda ta jest bezpieczna i niezbyt uciążliwa finansowo, jej stosowanie natomiast może rozciągać projekt w czasie.

I wreszcie czwarty sposób rozwiązania problemu - konwersja fazowa. W tym przypadku wprowadzanie nowego systemu jest wykonywane etapowo - nowe moduły sukcesywnie zastępują dotychczas używane. Problemy w tym przypadku to czasochłonność i konieczność koordynacji obiegu informacji między różnymi systemami.

Zasady normalizacji baz danych zakładają, że pola powinny zawierać niepodzielne jednostki informacyjne, zwane niekiedy wartościami atomowymi. Praktyka nie znosi formalizmu, wiadomo. Autor projektu może dowolnie dysponować swoimi pomysłami i jeśli tylko nie zaburzają one struktury funkcjonalnej oprogramowania, mogą być kształtowane wg jego woli, bardziej lub mniej formalnie.

Należy jednak pamiętać, że formalizm nie został wprowadzony, aby utrudniać ludziom życie, lecz po to, by wynikały z niego konkretne korzyści, które istnieją obiektywnie, nawet jeśli na pierwszy rzut oka nie są oczywiste. Normalizację docenia się późno - zwykle wtedy, gdy, chcąc nie chcąc, trzeba wykonać konwersję danych w warunkach "partyzanckich" bez wsparcia autora systemu mającego odejść w niebyt. Dopiero wtedy dostrzega się, z jaką pieczołowitością normalizacji warto jednak - pomimo wszystkich jej bolesności - przestrzegać.

Z życia wzięte

Wdzięcznym obiektem do prezentacji skutków braku normalizacji są pola zawierające wszelkie informacje adresowe. Niechcący utrudniać SOBIE życia autorzy oprogramowania wolą raczej wpisywać wszystkie dane w jednym polu, niż wyodrębniać miasto, ulicę, kod pocztowy, numer domu i mieszkania. Wkrótce okazuje się, że to, co w pierwszym etapie wydaje się wygodne, zaczyna mocno doskwierać.

Oto przykład. Program, który na podstawie zwartego pola adresowego ma drukować nalepki adresowe, nigdy nie wykona tego w sposób zadowalający - sformatowanie wydruku stanie się bólem głowy, ponieważ będzie on mieć dokładnie taki format, w jakim został wprowadzony do bazy. Ponieważ modyfikacje adresów będą ciągle wywoływać problemy, w pewnym momencie ktoś podejmie decyzję, aby zaimplementować dodatkową funkcję analizującą zawartość pola adresowego.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200