Dlaczego informatyzacja zaczyna się od finansów?
Wdrożenie Zintegrowanego Systemu Zarządzania Politechnika Wrocławską w zakresie Kadr. Płac. Finansów oraz Rachunkowości Zarządęzęj
Informatyzacja usług wiąże się w dużym stopniu z upowszechnieniem dostępu do komputerów PC. Na Politechnice Wrocławskiej nastąpiło to w drugiej połowie lat osiemdziesiątych. Wtedy też rozpoczęła się nowa era dla służb finansowych uczelni. Do tego czasu były co prawda tworzone systemy związane ze sferą zarządzania, lecz ich stopień wdrożenia rzadko przekraczał fazę eksploatacji próbnej. Pierwsze systemy na PC były jednostanowiskowe, tworzono je w języku programowania PASCAL. Ich budową zajmował się zespól informatyków działający przy służbach finansowych Politechniki. Na początku lat dziewięćdziesiątych pojawiły się systemy sieciowe. Wówczas podstawowym językiem programowania stał się Clipper.
Większość obecnie służących służbom finansowym systemów zbudowana została przez informatyków z Działu Informatyzacji w technologii „dbf” (CLIPPER). Wśród najważniejszych z punktu widzenia działalności służb finansowych systemów i modułów są: PŁACE, PODATKI, ZUS, F-K (finanse i księgowość) i KADRY. Dla funkcjonowania całej uczelni jest bardzo istotne, by charakteryzowały się one wysoką niezawodnością, odpomościąna awarie i bezpieczeństwem danych.
Są to systemy transakcyjne, a więc takie, które służą do rejestrowania i przetwarzania informacji o zdarzeniach (gospodarczych, finansowych, związanych z zarządzaniem personelem, itp.) obsługiwanych przez dany system, np. w systemie kadrowo-płacowym będzie to przyjęcie pracownika, wypłata wynagrodzenia, awans pracownika. Wprowadzenie lub obliczenie wszystkich niezbędnych informacji związanych z danym zdarzeniem określa się mianem transakcji.
Budowanie systemów transakcyjnych za pomocą przestarzałych i prostych narzędzi, takich jak Clipper, prowadzi do tworzenia baz plikowych, w których informacja składająca się na system zapisywana jest w oddzielnych zbiorach (plikach), np. zapisanie informacji o pracowniku i jego składnikach wynagrodzeń wymaga utworzenia co najmniej dwóch zbiorów, nie licząc zbiorów pomocniczych (słowniki, zbiory indeksowe). Wszelkie operacje na tych plikach wykonywane są na poziomie systemu operacyjnego (DOS), który nic nie wie o zależnościach logicznych występujących pomiędzy zbiorami. Stąd bardzo trudno utrzymać w nich spójność danych, tzn. zgodność danych we wszystkich zbiorach składających się na system. Uszkodzenie jednego ze zbiorów (np. gdy podczas zapisywania danych nastąpi awaria na łączach), może w istotny sposób zmienić rezultaty przetwarzania danych, np. naliczenia płac. Spójność danych w bazach plikowych naruszana jest również w momencie realizacji transakcji wymagającej zapisu do więcej niż jednego zbioru. Może się to zdarzyć np. podczas zapisywania wprowadzanych danych o nowym pracowniku: inny program może czytać te dane w momencie, gdy nie wszystkie zbiory zostały już zaktualizowane.
Używanie baz plikowych (dbf) w odniesieniu do dużych, mocno ze sobą powiązanych systemów pracujących w sieci rozległej, do której dostęp mają wszyscy pracownicy (i nie tylko oni) prowadzi do powstania bardzo niestabilnej struktury. Stwarza ona szereg zagrożeń, z których najważniejsze to:
1) ryzyko utraty integralności danych
Poszczególne tabele oraz związane z nimi indeksy przechowywane są w oddzielnych plikach. Z plikami tymi nie jest związany żaden system zarządzania bazą danych (SZBD), tak jak to ma miejsce w przypadku SQL-owych baz danych (np. ORACLE). Stąd bardzo łatwo można naruszyć spójność danych. Mało tego! O ile administrator sieci nie zauważy takiego defektu, należy liczyć sięz groźnymi konsekwencjami wynikającymi z pracy programu z niespójnymi danymi.
2) niedostateczne bezpieczeństwo da-
Bazy plikowe wymagają przydzielenia uprawnień poszczególnym użytkownikom na poziomie zbiorów, a nie funkcji, jak to mamiejscew przypadku dużych baz relacyjnych. Oznacza to, że użytkownik ma dostęp do danych nie tylko z poziomu udostępnionych mu programów (funkcji systemu), ale również za pomocą innych narzędzi związanych z systemem operacyjnym (np. może skasować lub skopiować cały plik). Niesie to za sobą ryzyko świadomego lub nieświadomego uszkodzenia danych lub kradzieży informacji, przy czym niemożliwe jest wykrycie ewentualnych sprawców tego typu działań.
3) brak sprawnego i efektywnego administrowania aplikacją
Brak gotowych SZBD dla baz plikowych utrudnia administrowanie aplikacją, co bezpośrednio wpływa na bezpieczeństwo i integralność danych.
Wady systemów transakcyjnych są rezultatem nie tylko użytego narzędzia; wynikają
Eil 171