Ogólne informacje o Systemie Archiwizacji ZEUS System Archiwizacji ZEUS przeznaczony jest do opracowywania zasobów archiwalnych. Oprogramowanie powstało w wyniku wielomiesięcznej analizy potrzeb jednego z centralnych archiwów państwowych i składa się z modułów do ewidencji zasobów, ich udostępniania oraz modułu do wystawiania i drukowania dokumentów sprzedaży. System działa w oparciu o serwery relacyjnych baz danych Sybase, Oracle lub Microsoft. Dzięki swej innowacyjności, mimo iż powstał zaledwie 4 lata temu, jest wykorzystywany w takich organizacjach jak Instytut Pamięci Narodowej (w centrali w Warszawie i jedenastu oddziałach regionalnych), Muzeum II Wojny Światowej w Gdańsku, Archiwum Senatu RP, Narodowym Archiwum Cyfrowym. Dzięki zaawansowaniu technologicznemu i otwartości struktury bazy danych, zapewnia zgodność z aktualnymi standardami sprzętowo programowymi, co pozwala na szybkie budowanie zasobu, generowanie niezbędnej dokumentacji (np. Karty Eksponatów) przy jednoczesnej współpracy z systemami finansowo-księgowymi, systemami rozliczania pracy lub programami do automatycznego skanowania obrazów. Dzięki swojej modułowej budowie System Archiwizacyjny ZEUS jest silnie skalowalny ilość funkcjonalności (tzw,. modułów) i stanowisk można zwiększać wraz ze wzrostem potrzeb Instytucji. Moduł administracji pozwala na definiowanie praw dostępu do poszczególnych okien i funkcji a także śledzenie wprowadzanych modyfikacji i generowanie statystyk pracy archiwistów. Przykładowe ekrany systemu ZEUS
Wprowadzanie danych o fotografii Wprowadzanie danych o nośnikach
Ogólny opis mechanizmów stosowanych w bazie danych Systemu ZEUS System Archiwizacji ZEUS to podstawowe rozwiązanie informatyczne wykorzystywane w procesie opisywania zasobów Filmoteki Narodowej. System wspiera proces digitalizacji materiałów powiązanych z twórczością filmową (fotografie, wycinki prasowe, plakat, fragmenty materiałów wideo). Ogromne możliwości konfiguracji systemu powodują, że istniejąca struktura bazy danych zawiera szereg pól i obiektów używanych do definiowania GUI a także sposobów (interfejsów) komunikacji z zewnętrznymi systemami. Zestaw modułów programu i sposób ich implementacji zostały dostosowane do potrzeb Filmoteki Narodowej. Oprogramowanie bazuje na relacyjnej bazie danych firmy Oracle. W bazie danych przechowywane są dane opisowe i wskazania - odwołania http i ścieżki dostępu do plików. Dokumenty źródłowe (fotografie, skany plakatów, wycinki prasowe w postaci plików graficznych, opisy tekstowe będące efektem stosowania oprogramowania OCR) przechowywane są w postaci plików cyfrowych. Wszystkie operacje na bazie danych wykonywane są z użyciem mechanizmu transakcji. Identyczne mechanizmy powinny być stosowane przez projektowany system replikacji zasobów tak aby nowy serwis posiadał odpowiednie poziomy izolacji i nie blokował dostępu do poszczególnych tablic i rekordów. Dzięki zastosowaniu architektury klient-serwer, dane w postaci źródłowej przetwarzane są na stacjach klienckich, co umożliwia znaczną redukcję kosztów związanych z konfiguracją i mocą obliczeniową serwera. Baza danych systemu ZEUS zawiera informacje o położeniu plików źródłowych (np. pliki TIF) a także miniatur (skompresowane pliki JPG). System przechowuje informacje o czasie wprowadzenia oraz osobie modyfikującej istotne pola. Wymagane jest by nowy system wprowadzał odpowiednie zapisy do tablic (fakt odczytu danych, które mogą być newralgiczne). W systemie ZEUS istnieje możliwość stosowania wielopoziomowych ograniczeń i definiowania uprawnień dla poszczególnych użytkowników i funkcji. Każdy użytkownik posiada indywidualny login i hasło, które związane są z odpowiednim poziomem dostępu do poszczególnych komponentów. Wymagane jest aby interfejs umożliwiający import danych z systemu ZEUS wykorzystywał ten mechanizm. Informacje zawarte w poszczególnych tablicach (fragmenty sygnatury) wpływają także na wygląd interfejsu aplikacji. Poniższy przykład ilustruje zróżnicowanie wyglądu okien umożliwiających wprowadzanie i edycję tematu na podstawie przypisanie zbiorów.
Rys. 1 Okno wprowadzania informacji o filmie (drugi segment sygnatury F), widoczne m.in. pole umożliwiające określenie rodzaju i formatu filmu. Rys. 2 Okno wprowadzania informacji o osobach (biogramy), drugi segment sygnatury P (person).
Rys. 3 Okno wprowadzania danych o wydarzeniach (festiwale, premiery itp.) Drugi segment sygnatury T (Theme). Identyczny mechanizm powinien zostać zastosowany przy tworzeniu nowego serwisu www. Fakt stosowania opisywanego mechanizmu nie pozostaje bez wpływu na zakres replikowanych danych (zawartość poszczególnych pól może być różna dla różnych rodzajów informacji / tematów). Struktura bazy danych systemu ZEUS W bazie danych systemu nie istnieją funkcje i procedury wbudowane. Ze względu na konieczność rozproszonego przetwarzania danych (konwersja obrazów, tworzenie miniatur etc.) wszystkie procedury zostały utworzone w zewnętrznych narzędziach (Sybase Power Builder, Java, Ruby) i wykonywane są po stronie klienta. Kluczowe tablice systemu używają mechanizmu wyzwalaczy i widoków - automatyczne wyświetlanie danych do zreplikowania na podstawie zmian statusu rekordu (TRIGGERS ON INSERT OR UPDATE). Baza danych systemu ZEUS została zaprojektowana z wykorzystaniem narzędzi Sybase, w szczególności Sybase PowerDesigner. W bazach klasy ASA do wersji 10.0 nie występowały obiekty zwane paczkami bazodanowymi (Packages), zatem takie obiekty nie powstały dla kolejnych wersji struktury bazy ORACLE. System wykorzystuje szereg słowników danych. Wszystkie słowniki zostały szczegółowo opisane w dokumentacji zawierającej opis zawartości tablic. Tablice będące słownikami (dla użytkowników systemu) zostały nazwane odpowiednio X_SLOWNIK, gdzie X to oznaczenie tablicy,
która korzysta z danych zawartych w tablicy słownika. Wykonawca systemu otrzyma kompletną dokumentację struktury danych po podpisaniu umowy. Mechanizmy istotne z punktu widzenia działania interfejsów wymiany danych Nowe oprogramowanie powinno wykorzystywać następujące mechanizmy zaimplementowane w bazie danych systemu ZEUS: Mechanizm śledzenia modyfikacji Mechanizm widoków i wyzwalaczy (automatyczne tworzenie list do replikacji ) Mechanizm uwzględnienia statusów udostępnij w sieci www Mechanizm transakcji, Mechanizm znormalizowanego zapisu danych. Działanie powyższych mechanizmów jest identyczne dla każdej z tablic systemu ZEUS, nowy system powinien zostać zaprojektowany w taki sposób aby stosowane mechanizmy danych nie wpływały na działanie już zaimplementowanych rozwiązań. Uwaga! Zamawiający nie wyklucza, że w przyszłości baza danych będzie wykorzystywana również w innych systemach prezentacji zasobów, w związku z tym należy bezwzględnie stosować opisane poniżej reguły. Mechanizm śledzenia modyfikacji Mechanizm wykorzystuje tablice UZYTKOWNIK, MODYF_UZYTKOWNIK, MODYF_SLOWNIK. Relację pomiędzy tablicami przedstawia poniższy wykres. UZYTKOWNIK MODYF_ UZYTKOWNIK MODYF _SLOWNIK Opis zawartości poszczególnych tablic. UZYTKOWNIK ID_UZYTKOWNIK LOGIN HASLO IMIE Klucz główny, pole uzupełniane automatycznie Sposób w jaki użytkownicy logują się do systemu Sposób w jaki użytkownicy logują się do systemu, w polu wyświetlane są symbole,,* aby inni użytkownicy nie mogli odczytać jego zawartości Imię użytkownika
NAZWISKO WYSTAWIL_FV CZY_UP000 CZY_UP001 999 Nazwisko użytkownika Imię i nazwisko użytkownika używane jako podpis osoby wystawiającej faktury VAT i rachunki Uprawnienia pole określa czy dany użytkownik jest aktywny i może zalogować się do systemu. W aplikacji nie ma możliwości usuwania użytkowników (przechowywane są wszystkie informacje o wykonywanych przez nich czynnościach) Uprawnienia kolejne pola określają uprawnienia poszczególnych użytkowników do wykonywania odpowiednich funkcji (wstawianie nowych tematów, wystawianie faktur VAT, modyfikacja opisów itp.) Szczegółowa lista uprawnień zostanie załączona do instrukcji obsługi MODYF_UZYTKOWNIK ID_MODYFIKACJA Klucz główny, pole uzupełniane automatycznie ID_UZYTKOWNIKA Identyfikator użytkownika, który wprowadził modyfikację ID_RODZ_MODYF TABL_MODYF PN_MODYFIK_TABL CZAS_MOD UWAGI Klucz główny, pole wypełniane automatycznie Numer modyfikowanej tablicy Numer tablicy, w której dane zostały zmienione Data i czas modyfikacji w formacie,,yymmddhhmmss Dodatkowe uwagi dot. Usuwanych rekordów MODYF_SLOWNIK ID_RODZ_MODYF OPIS_MODYFIKACJA Klucz główny, pole wypełniane automatycznie Opis rodzaju modyfikacji np. Zmiana opisu obrazu, usunięcie tematu Każda operacja (wstawienie lub modernizacja rekordu) wykonana na danych opisujących zbiory Zamawiającego skutkuje wprowadzeniem do tablicy MODYF_UZYTKOWNIK nowego rekordu. Rekordy wstawiane są zgodnie z poniższym schematem. Nazwa kolumny Zawartość kolumny
ID_MODYFIKACJA ID_UZYTKOWNIKA ID_RODZ_MODYF 1 {autoincrement} 1 {foreign key} 1 {foreign key} TABL_MODYF 1 PN_MODYFIK_TABL 1 CZAS_MOD 120805123407 UWAGI S-F-123-43 Na podstawie rodzaju modyfikacji, użytkownika oraz sygnatury (pole UWAGI) możliwe jest sprawdzenie kto i kiedy zmodyfikował określony rekord. Wykorzystanie słownika modyfikacji pozwala na wyświetlenie wszystkich operacji określonego rodzaju np. pokaż wszystkie operacje Usuń zawartość słownika X. Mechanizm widoków i wyzwalaczy Wszystkie tablice z opisem zasobów posiadają odpowiedniki w postaci widoków. Nazwy widoków tworzone są zgodnie ze schematem NAZWA_TABELI_ZRODLOWEJ_INET np. dla tablicy MOVIE tworzony jest widok MOVIE_INET. Kwerenda SQL definiująca widok zawiera klauzulę WHERE, gdzie warunki stanowią kopię warunków tablicy źródłowej (jeśli istnieją) a także zwrot... AND CZY_ZMIANA = 1. Kolumna CZY_ZMIANA <INTEGER> może przyjmować jedną z dwóch wartości: 1 Rekord został zmieniony, powinien zostać wyeksportowany do systemu prezentacji zasobów w sieci www. 0 Rekord nie został zmieniony, nie powinien być wyświetlany w widoku...inet. Tablice, których zawartość jest replikowana do innej bazy danych posiadają również wyzwalacze (TRIGGERS), które w wyniku operacji INSERT i UPDATE zmieniają wartość kolumny CZY_ZMIANA na 1. Nowe rekordy posiadają wartość 1 w kolumnie CZY_ZMIANA, po ich skopiowaniu do innej bazy danych wartość ta powinna zostać zmieniona 0. Wprowadzenie modyfikacji danych w takiej tablicy spowoduje wywołanie mechanizmu wyzwalacza i zmianę statusu CZY_ZMIANA = 1. Wykorzystanie widoków (views) pozwala na maksymalne uproszczenie zapytań SQL zawierających definicję replikowanych danych a także pozwala na modernizację ich zawartości bez konieczności przebudowy całego mechanizmu. Mechanizm uwzględnienia statusów udostępnij w sieci www Każde z pól zawierających opis zasobów Wnioskodawcy posiada odrębne pole <INTEGER>, które określa czy jego zawartość powinna zostać przeniesiona do serwisu www. Kolumna ta może
przyjmować dwie wartości 0 NIE, 1 TAK. Przykładem może być tablica OSOBA. Jeśli tablica zawiera dwie kolumny IMIE i NAZWISKO, to również powinna zawierać kolumny IMIE_WWW i NAZWISKO_WWW. Poniżej przykłady replikacji danych w oparciu o zawartość kolumn _WWW. IMIE IMIE_WWW NAZWISKO NAZWISKO_WWW Odczytane dane JAN 0 NOWAK 0 JAN 0 NOWAK 1 NOWAK JAN 1 NOWAK 0 JAN JAN 1 NOWAK 1 JAN, NOWAK Tabela 1 Przykład replikacji danych w oparciu o zawartość kolumn odpowiadających za prezentację poszczególnych kolumn. Wykonawca powinien wykorzystywać widoki aby późniejsza przebudowa mechanizmu replikacji nie wiązała się z koniecznością przebudowy obiektów odpowiadających za kopiowanie danych. Wskazane jest użycie klauzuli IF... THEN... w definicji poszczególnych kolumn dla widoków (views). Mechanizm transakcji Transakcje to mechanizm wspierający utrzymanie spójności bazy danych, szczególnie w przypadku wystąpienia błędu bądź zerwania połączenia z serwerem. Domyślnie transakcje działają w trybie autocommit, co oznacza, że każda transakcja jest automatycznie zatwierdzana i powoduje zmiany w bazie danych. System ZEUS wykorzystuje mechanizm transakcji we wszystkich obiektach odpowiadających za wprowadzanie danych i ich edycję przez użytkowników. Identyczny mechanizm powinien być stosowany przy replikacji danych. Przykład: W konfiguracji bazy danych wyłączamy automatyczne zatwierdzanie: set autocommit=0; Konsekwencją jest konieczność zatwierdzenia transakcji (każda instrukcja SQL jest traktowana jako transakcja) i nie trzeba zaczynać transakcji od wyrażenia start transaction, natomiast każde polecenie SQL wymaga zatwierdzenia transakcji: commit; lub cofnięcia jej wyniku przez: rollback; Mechanizm replikacji powinien działać w oparciu o schemat: a. Pobieramy dane z systemu Zeus SELECT b. Wprowadzamy dane do serwisu WWW c. W przypadku kiedy dane zostały prawidłowo wstawione aktualizujemy statusy: CZY_ZMIANA = 0 d. W przypadku poprawnego wywołania poleceń SQL wywołujemy polecenia commit dla obu baz (w innym przypadku polecenia rollback).
Mechanizm znormalizowanego zapisu danych. System ZEUS wykorzystuje liczne słowniki, lokalizacja plików również określona jest w odrębnych tablicach SCIEZKA_DO_PLIKU, OBRAZ (poniżej fragment tabeli). SCIEZKA_DO_PLIKU ID_SCIEZKA OPIS_SCIEZKA Identyfikator ścieżki do podkatalogu, w którym zapisano plik Ścieżka do podkatalogu z obrazami OBRAZ ID_OBRAZ ID_SCIEZKA ID_TEMAT Klucz główny, pole wypełniane automatycznie Klucz obcy, pole wskazuje na jedną ze ścieżek do podkatalogów w których przechowywane są obrazy Klucz obcy, pole wskazuje na temat, którego dotyczy dany obraz WPROWADZIL Klucz obcy, identyfikator użytkownika, który wprowadził obraz do bazy danych OST_MODYFIKOWAL Klucz obcy, identyfikator użytkownika, który ostatnio modyfikował obraz Kolumna ID_SCIEZKA w tablicy obraz określa (w powiązaniu ze słownikiem) lokalizację pliku. Mechanizm taki powinien być bezwzględnie stosowany w systemie prezentacji www (umożliwia zmianę lokalizacji poszczególnych zasobów bez konieczności aktualizowania zawartości tablicy OBRAZ.