USOS i SOWA - PWSZ Elbląg
Transkrypt
USOS i SOWA - PWSZ Elbląg
Państwowa WyŜsza Szkoła Zawodowa w Elblągu Instytut Informatyki Stosowanej USOS i SOWA Przygotował Podsiadło Robert. 1 Wstęp W trakcie korzystania z obu programów na „mojej” uczelni (PWSZ Elbląg), zdano sobie sprawę, Ŝe dane studentów muszą być wprowadzane dwa razy, tj. w dziekanacie do systemu USOS i osobno w bibliotece do systemu SOWA. Podwójne wprowadzanie danych doprowadziło niejednokrotnie do powstawania błędów a ponadto zajmuje mnóstwo czasu. Powstała idea Ŝeby ograniczyć to do jednego razu. Rozwiązanie tego problemu stało się tematem mojej pracy dyplomowej. USOS Program jest produktem polskim. USOS (Uniwersytecki System Obsługi Studiów) powstał na MIM UW (Wydział Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego). System składa się z dwóch części: • • właściwej aplikacji USOS, wykonanej w architekturze dwuwarstwowej (przetwarzanie i składowanie danych odbywa się w jednym module) z wykorzystaniem narzędzi firmy Oracle (Forms i Reports oraz serwera baz danych Oracle), a przeznaczonej do wykorzystania przez pracowników administracji uczelnianej (głównie dziekanatów), systemu USOSweb, wykonanego jako aplikacja internetowa w architekturze trójwarstwowej (przetwarzanie i składowanie danych następuje w dwóch osobnych modułach) z zastosowaniem języka PHP oraz serwera baz danych MySQL i przeznaczonej dla studentów i wykładowców. Aplikacja USOSweb korzysta z danych systemu USOS replikowanych dwukierunkowo (dwukierunkowe rozprowadzanie danych, zarówno od serwera, jak i od klientów) w trybie wsadowym według określonego harmonogramu, ponadto w niektórych wdroŜeniach integruje w swoim interfejsie dostęp do innych aplikacji uczelni, nie stanowiących integralnej części systemu USOS. SOWA To takŜe produkt polski, komercyjny do obsługi biblioteki. Program współpracuje z serwerem aplikacji SOWA, z którym komunikuje się protokołem TCP/IP. Dzięki temu program Obsługi WypoŜyczalni moŜe być eksploatowany zdalnie, np. przez odległe filie biblioteczne, pracujące na katalogu centralnym zasobów. 2 Analiza Dane w USOS są gromadzone w bazie Oracle. Natomiast SOWA zapisuje dane w formacie *.dbf. Bazy danych formatu dBase (z rozszerzeniem .dbf) mają prostą konstrukcję, są popularne i moŜna ich uŜyć w wypadku, gdy nie ma dostępu do tradycyjnych baz, jak MySQL Oracle czy Postgres. Pliki baz danych dBase posiada określoną budowę. KaŜdy plik typu DBF posiada swój nagłówek oraz rekordy, w których zapisane są dane. Nagłówek natomiast dzieli się jeszcze na dwie części: opisową oraz definicji pól rekordów. PoniŜej znajduje się opis budowy nagłówka: Część opisowa Nazwa Wielkość Type 1 Year Month Day RecCount Location RecordLen Reserved 1 1 1 4 2 2 20 Opis Wersja pliku DBF. MoŜe przyjąć wartości: 3H - plik DBF w wersji dBase III 83H - plik DBF skojarzony z polem MEMO (DBT) Rok ostatniej modyfikacji (dwie ostatnie cyfry) Miesiąc ostatniej modyfikacji Dzień ostatniej modyfikacji Liczba rekordów w pliku PołoŜenie w pliku pierwszego rekordu Wielkość rekordu (w bajtach) Niewykorzystane Definicja pól rekordów Nazwa Wielkość FieldName 11 FieldType 1 FieldAddress FieldLen FieldDec Reserved 4 1 1 14 Opis Nazwa pola rekordu. Zapisana jest ona wielkimi literami. Składa się 10 znaków i ostatniego (11) kodu #0. Typ danego pola. MoŜe przyjmować następujące wartości: 'C' - znakowe 'N' - numeryczne 'L' - logiczne 'D' - data 'M' - MEMO PołoŜenie danego pola w rekordzie Długość danych Długość liczb po kropce (jeśli to liczba rzeczywista) Niewykorzystane 3 Definicja pól rekordu zajmuje więc 32 bajty, tyle samo, co część opisowa. By dowiedzieć się ile w pliku jest pól rekordów naleŜy od Location (połoŜenie pierwszego rekordu pliku) odjąć 32 (wielkość części opisowej nagłówka). Teraz wiemy ile zajmuje pamięci definicja pól rekordów. Dodajemy jeden, gdyŜ nagłówek zakończony jest specjalnym bajtem o wartości 0DH i dzielimy przez wielkość definicji jednego pola rekordu, czyli 32. Trochę to zakręcone, ale nie ma lepszej metody. Za nagłówkiem znajdują się dane. Jest ich RecCount * RecordLen bajtów danych. Cały plik zakończony jest znakiem #26. Dane dla SOWA-y MoŜliwe jest otwarcie pliku z rozszerzeniem *.dbf przez program MS Exel (rozszerzenie *.csv) więc dane pobrane z Oracle równie dobrze mogły by zostać zapisane do pliku *.csv. JednakŜe aby moŜliwe było zapisanie danych w kolejnych kolumnach bazy SOWA dane musiały by zostać pobrane z Oracle w następującej postaci: "Nazwisko imię"|"Z.IIS"|"2009-09-30"|"Elbląg"|"A"|"11267"|"0552390909"|"kod pocztowy"|"miasto"| "ulica i nr domu zamieszkania"|" kod pocztowy "|" miasto "|" ulica i nr domu uczelni"|"pesel"|"męszczyzna/kobieta" 1 - nazwisko imię 2 - kod studiów (składa się z 2 członów w postaci X.YYY X oznacza system studiów - S dla studentów stacjonarnych Z dla studentów niestacjonarnych YY jest skróconą nazwą instytutu czyli IIS lub IPJ lub IP lub IE 3 - data końca studiów w formacie YYYY-MM-DD 4 - miasto urodzenia 5 - kod dokumentu - zawsze przyjmuje wartość A 6 - numer albumu 7 - telefon domowy 8 - kod pocztowy adresu stałego 9 - miasto adresu stałego 10 - ulica adresu stałego 11 - kod pocztowy adresu korespondencji (jeŜeli osoba podała adres kor) 12 - miasto adresu korespondencji (jeŜeli osoba podała adres kor) 13 - ulica adresu korespondencji (jeŜeli osoba podała adres kor) 14 - pesel 15 - płeć K lub M Pozostaje jeszcze problem porównania danych zaciągniętych z Oracle z bazą SOWY, poniewaŜ dane nie powinny się dublować. Tego tematu jeszcze nie przeanalizowałem. Jestem w trakcie prowadzenia badań. 4