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