Konwersja systemów

Konwersja danych

Istotnym elementem modyfikacji systemu informatycznego jest konwersja danych z dotychczas używanych zasobów. Rzadko użytkownicy rezygnują z tej procedury, pozwalającej na przeniesienie ich dotychczasowego dorobku do nowego systemu. Najczęściej utrata danych stawia pod znakiem zapytania działalność firmy (np. systemy rozliczeń finansowych, bankowe).

Zastosowania informatyczne można podzielić na dwie grupy pod względem znaczenia danych historycznych:

  • bezwzględnie zależne - dane muszą być przeniesione do nowego systemu

  • niezależne - dane są przenoszone opcjonalnie.

    W systemach niezależnych od danych historycznych nie występuje zależność czasowa. Mogą to być systemy, gromadzące pewne informacje, które nie są ważne dla ciągłości funkcjonowania firmy, ukazują jedynie jej historię. Tego typu zastosowań jest niewiele - należą do nich systemy bibliograficzne, gdzie zachowanie ciągłości dostępu do danych w aktualnie używanym systemie jest niezwykle trudne, ale też nie jest konieczne. Wynika to ze skomplikowanej struktury danych w połączeniu z istotnymi zmianami formatu rekordów nowych edycji oprogramowania, powodujących, że konwersja staje się finansowo nieopłacalna lub czasami wręcz niemożliwa. Jest to przyczyną tego, że biblioteki na świecie oferujące dostęp on-line do swoich zasobów, dzielą je na roczniki według systemów informatycznych, w jakich były gromadzone - np. Biblioteka Kongresu USA. Użytkownik szukający informacji musi podać okres, w jakim jest ona pogrupowana. Podział ten to skutek wprowadzania nowych systemów informacyjnych w historii działalności, kiedy ilość zgromadzonych danych wykluczała ich ponowne wprowadzanie (setki tysięcy rekordów opisu tekstowego), a automatyczna konwersja nie była możliwa (znaczne różnice w formacie danych). W systemach tych nie ma konieczności gromadzenia wszystkich danych w obrębie baz jednolitego systemu informacyjnego, tym bardziej że dane nie są retrospektywnie modyfikowane.

    Problemy strukturalne i algorytmiczne

    Inną przyczyną, nie pozwalającą na skuteczną konwersję, jest niepoprawnie zaprojektowana struktura danych. Może ona wynikać ze źle wykonanego projektu poprzedniego systemu lub znacznych różnic w strukturze danych starego i nowego systemu. Niewłaściwy projekt systemu, gdzie dla pozornego uproszczenia dane umieszczano w obrębie jednego pola, mimo że powinny być rozłączne, stanowi przeszkodę w przeprowadzaniu automatycznej (programowej) konwersji. Niejednoznaczność sytuacji uniemożliwia opracowanie algorytmu, który identyfikowałby struktury danych zawsze w ten sam sposób. Nie ma znaczenia środowisko pracy systemu, zarówno w tradycyjnych, jak i w otwartych systemach - umożliwiających łatwą wymienialność danych. Najważniejsza jest wewnętrzna struktura obiektu, a nie sposób integracji środowisk.

    Struktury danych można podzielić na interpretowalne i nieintepretowalne algorytmicznie - przy założeniu ograniczonej złożoności algorytmów.

    Przykładem trudnej identyfikacji danych może być układ, gdzie w dotychczasowym systemie w jednym polu rekordu zapisywano adres jako całość, natomiast w nowym - wydzielone są osobne pola, w których wpisuje się nazwę miasta, ulicę, kod, numer domu i mieszkania. Umożliwienie wprowadzania wielu informacji, chociaż podobnych znaczeniowo, w jednym polu prowadzi do dowolności interpretacji, w związku z czym w komputerze różnie będą wpisywane te dane - np. nazwa miasta może pojawić się zarówno na pierwszej pozycji, jak i na drugiej. Interpretacja automatyczna tak wprowadzonych informacji wymagałaby stworzenia systemu inteligentnie rozstrzygającego, w jaki sposób kwalifikować poszczególne elementy pola. Jest to zadanie o tyle trudne, że przedłużałoby proces tworzenia nowego oprogramowania - nie wspominając o ogromnych kosztach z tym związanych - a nie dające s100% pewności nieomylności interpretacyjnej.

    Drugą trudnością jest niedomiar informacyjny. Jeżeli nowy system ma pole "województwo", którego w dotychczasowym opisie struktury nie było, wówczas rozstrzyganie o przynależności miasta do województwa w sposób programowy możliwe jest jedynie na bazie rozbudowanego systemu wiedzy, zawierającego powiązania wszystkich nazw miejscowości z ich położeniem. Natomiast o województwie powinien decydować kod pocztowy, ale przy stosowaniu dowolności wypełniania pola, wówczas może być brak danych.

    Stosując najprostsze algorytmy, których wynik prezentuje Tabela 1, uzyskujemy mylną interpretację danych w przypadkach niejednoznacznych. Zasada działania polega bowiem na pozycyjnej analizie zawartości pola "Adres". Pierwszy ciąg tekstowy traktowany jest jako nazwa miejscowości, drugi jako nazwa ulicy. Liczba występująca za nazwą ulicy jest numerem domu i mieszkania. Kod pocztowy może być poszukiwany na dowolnej pozycji ciągu i charakteryzuje się sześcioma znakami, ze znakiem po drugiej pozycji. Jako rozdzielniki między napisami rozróżniane są znaki „ - ” ze zbioru: "{spacja};{przecinek};{slash};{kropka}". Z wyniku konwersji danych można wnioskować, że algorytm działa poprawnie do momentu, kiedy zostanie zamieniona pozycja nazwy ulicy z nazwą miejscowości w rekordzie wejściowym. Modyfikując metodę analizy ciągu źródłowego, można uniknąć tego błędu. Określając, że nazwą ulicy jest ten ciąg znaków, za którym występuje numer nie będący kodem pocztowym, można otrzymać poprawny obraz danych wyjściowych. Poprawa algorytmu będzie skuteczna do momentu, gdy pojawi się adres nie zawierający numeru mieszkania. Wówczas interpretacja tego pola nie będzie możliwa z użyciem prostego mechanizmu rozstrzygającego.


  • TOP 200