Metodyka projektowania systemów z intensywnie

V Konferencja PLOUG
Zakopane
Październik 1999
Metodyka projektowania systemów z intensywnie
wykorzystywanymi danymi
Krzysztof Jankiewicz
[email protected]
Instytut Informatyki Politechniki Poznańskiej
Poznań, ul. Piotrowo 3a
Autor
Mgr inż. Krzysztof Jankiewicz, asystent w Instytucie Informatyki Politechniki Poznańskiej. Jest absolwentem
Wydziału Elektrycznego (dyplom w 1996 roku). Zainteresowania badawcze związane są z zaawansowanymi
systemami baz danych i systemami rozproszonymi. Doświadczenie zawodowe obejmuje: projektowanie
i implementację rozproszonych systemów informatycznych, administrowanie systemami komputerowymi,
działalność szkoleniową i dydaktyczną.
Streszczenie
W większości systemów informatycznych istnieją podzbiory intensywnie wykorzystywanych danych przez
aplikacje generujące raporty i analizy. Przykładem mogą być dane personalne pracowników w systemie
kadrowym, studenci w systemie dziekanatowym czy pacjenci w oprogramowaniu szpitala. Do takich danych
odwołuje się 80-90% aplikacji służących do generowania raportów. Silna zależność implementacji tych
aplikacji od schematu bazy danych powoduje, że pojedyncze modyfikacje schematu, pociągają za sobą
konieczność kosztownych rekonstrukcji tych wszystkich aplikacji. Metodyka projektowania aplikacji
uwzględniająca powyższy fakt może w istotny sposób zmniejszyć koszty tworzenia i utrzymania aplikacji
generujących raportów. Polega ona na wyodrębnieniu na etapie projektowania możliwie największą części
wspólnej aplikacji – raportów, i zaimplementowaniu jej we współdzielonym module programowym.
Powyższa metoda zostanie zilustrowana przykładem systemu Kadrowo-Płacowego wdrożonego
i eksploatowanego na Politechnice Poznańskiej.
Wstęp
W
znacznej
większości
systemów
informatycznych
istnieją
podzbiory
intensywnie
wykorzystywanych danych. Do takich danych odwołuje się ponad 80% modułów raportujących systemu,
większość formularzy ekranowych, znacząca liczba generowanych zapytań. Silna zależność
implementacji aplikacji od schematu bazy danych powoduje, że pojedyncze modyfikacje schematu
pociągają za sobą konieczność kosztownych rekonstrukcji licznych jej modułów.
Metodyka uwzględniająca powyższą niedogodność może w istotny sposób zmniejszyć koszty
tworzenia i utrzymania aplikacji. Przy projektowaniu systemów z intensywnie wykorzystywanymi
danymi nie należy zapominać o starannym dostosowaniu ich struktury pod względem efektywności.
Odpowiednie indeksy, klastry oraz struktury danych będą miały kluczowe znaczenie w sprawnym
działaniu tych systemów.
Raporty oraz standardowe metody ich tworzenia
Przez raport będziemy rozumieli moduł programowy, wykorzystywany do tworzenia raportów
papierowych. Na budowę standardowego raportu utworzonego za pomocą Oracle Reports składają się
między innymi:
•
Parametry systemu – decydują o tym jakiego formatu ma być dany raport (binarny, tekstowy,
HTML, PDF), jakie jest jego przeznaczenie (plik, drukarka, podgląd) itd.
•
Parametry użytkownika – mogą wpływać na selekcję w zapytaniach występujących w raporcie
oraz na wygląd samego raportu. Mogą być one inicjowane albo za pomocą formularza
parametrów, albo za pomocą tworzonej programowo listy parametrów. Ten drugi przypadek
występuje najczęściej podczas uruchamiania raportu z innego modułu np. formularza.
•
Model danych – w jego wnętrzu umieszcza się zapytania wykorzystywane w raporcie, dzieli się
je na grupy i podgrupy np. jednostki organizacyjne, rodzaje stanowisk, pracownicy. Tworzy
odpowiednie
połączenia
pomiędzy zapytaniami.
Budowa
modelu
danych
ma
swoje
odzwierciedlenie w rozkładzie – wyglądzie samego raportu.
•
Rozkład – służy do ustalania wyglądu raportu, układu elementów na stronie, czcionek,
marginesów, numerów stron, itd.
•
Formularz parametrów – element wizualny, na którym umieszcza się pola pozwalające nadać
wartości parametrom użytkownika. Jest on wyświetlany podczas uruchomienia raportu. Pola na
nim umieszczone mogą mieć jedynie postać pól edytowalnych lub list wartości.
Oracle Reports dostarcza nam kilku mechanizmów wspomagających tworzenie raportów operujących
na określonym z góry podzbiorze danych, wszystkie jednakże, oprócz swych niewątpliwych zalet
posiadają pewne ograniczenia.
2
Zapytanie współdzielone w pliku tekstowym
Raporty mogą korzystać z zapytań znajdujących się w plikach tekstowych. Współdzielenie takiego
pliku jest dobre tylko w przypadku zbioru raportów udostępniających dane w bardzo podobny sposób.
Bardzo trudno jest zapewnić możliwość różnorodnej prezentacji danych w zależności od raportu, np.
danych zagregowanych i nie, z różnymi grupami na zapytaniu itd. Parametry istniejące w zapytaniu
muszą mieć swoje odzwierciedlenie w każdym raporcie. Zmiana w parametrach zapytania powoduje
konieczność zmiany parametrów we wszystkich modułach. Zaletą tego rozwiązania jest to, że w
przypadku zmian schematu bazy danych dostosowanie do niej raportów może ograniczyć się tylko do
zmian zapytania we współdzielonym pliku.
Szablony
Rozwiązanie, które zostało udostępnione w Oracle Developer Release 2.1. w znakomity sposób
potrafi przyspieszyć tworzenie modułów operujących na tym samym zbiorze danych. Możemy utworzyć
szablon, który będzie posiadał odpowiednie parametry, rozbudowane zapytanie, odpowiedni rozkład. Na
jego podstawie tworzymy wszystkie potrzebne raporty. Pozostaje nam tylko dostosowanie parametrów,
zmodyfikowanie zapytania i rozkładu do charakteru każdego z raportów.
Problemy
Oto problemy, które pojawiają się podczas tworzenia i utrzymywania raportów napisanych przy
wykorzystaniu standardowych mechanizmów.
•
Konieczność tworzenia formularzy parametrów – dla każdego raportu trzeba utworzyć odrębny
formularz parametrów.
•
Ograniczenia w sposobie parametryzacji – nie istnieje możliwość wyboru dowolnego podzbioru
danych, np. pracowników z kilku konkretnych jednostek organizacyjnych wyłączając z tego
dyrektorów.
•
Różnice w parametryzacji poszczególnych modułów - bardzo często bywa tak, że ściśle określony
podzbiór danych chcemy poddać analizie za pomocą wielu różnych raportów. Jeżeli zbiór
parametrów jednego z nich odbiega od zbioru parametrów drugiego, to może zaistnieć taki
przypadek, kiedy nie będzie możliwe uzyskanie za pomocą tych dwóch raportów takiego samego
podzbioru danych.
•
Brak możliwości przekazywania parametrów pomiędzy raportami – każdorazowo przy
uruchamianiu raportu wszystkie jego parametry należy ustawiać od początku i to niezależnie od tego
czy poprzednio był uruchamiany ten sam moduł czy też nie.
•
Konieczność wprowadzania warunków WHERE do zapytań - każdy parametr w większości
przypadków ma swoje odzwierciedlenie w zapytaniach raportu. W większości zapytań istnieją
warunki selekcji i w każdym z nich należy prawidłowo uwzględnić parametryzację.
3
•
Trudna pielęgnacja w przypadku zmian schematu bazy danych - każda zmiana schematu bazy
danych powoduje konieczność modyfikacji odpowiednich raportów. Nie istnieje mechanizm
propagacji zmian, który automatycznie przenosiłby poprawki naniesione w jednym raporcie na
pozostałe, z nim komplementarne. Ponadto ze względu na złożoność takiej operacji, jak i
indywidualne cechy każdego z raportów nawet trudno sobie wyobrazić jak taki mechanizm miałby
działać i jakiego typu zmiany schematu mógłby obejmować.
•
Trudności w śledzeniu dostępu do danych – w większości współczesnych systemów baz danych,
w których występują dane osobowe, istnieje konieczność przechowywania informacji o tym kto i
kiedy miał dostęp do określonych danych. Dlatego też istotne jest aby istniał mechanizm śledzenia i
składowania parametrów wywoływanych raportów.
•
Konieczność częstej modyfikacji menu aplikacji – za każdym razem kiedy powstaje nowy raport
należy dostosować menu aplikacji do możliwości jego uruchomienia.
Opis rozwiązania problemu
Chcąc zlikwidować bądź też zminimalizować powyższe niedogodności stworzyliśmy w systemie
Kadry i Płace'2000 specjalną metodykę tworzenia i utrzymywania raportów operujących na intensywnie
wykorzystywanym zbiorze danych. Polega ona na wyodrębnieniu na etapie projektowania możliwie
największej części wspólnej aplikacji - raportów, i zaimplementowaniu jej we współdzielonym module
programowym.
Było to o tyle istotne, że w naszym systemie kadrowym praktycznie 95% wszystkich raportów
operuje na danych osobowych pracowników.
Współdzielony moduł programowy składa się z sześciu elementów:
•
Tabeli K_REP_REPORTS zawierającej informacje dotyczące poszczególnych raportów.
•
Formularza parametryzującego PRZYGOTUJ_RAPORT.
•
Tabeli K_REP_PARAMS przechowującej parametry wywołania określonego raportu.
•
Tabeli K_REP_AUDITS pełniącej rolę archiwum dotyczącego tego kto i kiedy uzyskiwał informacje
dotyczące określonych danych osobowych.
•
Perspektywy KVR_PRACOWNICY będącej głównym źródłem danych dla raportów.
•
Pakietu K2000_REPORTS zawierającego funkcje pomocnicze w przekazywaniu parametrów.
Zależności pomiędzy elementami modułu programowego obrazuje poniższy rysunek:
4
Tabela zawierająca
informacje dotyczące
poszczególnych raportów
„k_rep_reports”
Formularz
parametryzujący
„Przygotuj_raport”
Tabela z parametrami
uruchomienia raportów
„k_rep_params”
Perspektywa
„kvr_pracownicy”
Informacje o tym kto, kiedy
i z jakimi parametrami
uruchamiał określone
raporty
„k_rep_audits”
Pakiet zawierający funkcje
pomocnicze
„k2000_reports”
Poszczególne
raporty
Rysunek 1. Zależności pomiędzy elementami modułu programowego.
Tabela K_REP_REPORTS
Jest to tabela pomocnicza dla formularza parametrów. Zawiera ona następujące informacje:
•
Nazwę, krótki opis oraz domyślny tytuł raportu.
•
Nazwę pliku, w którym zawarta jest definicja raportu.
•
Informacje dotyczące parametryzacji raportu.
•
Informacje o domyślnych ustawieniach raportu.
Dzięki niej użytkownik ma możliwość, za pomocą zwykłej listy, wybrania raportu, który chce w danej
chwili wykonać. Dzięki nazwie pliku formularz parametryzujący uruchamia odpowiedni raport.
Informacje dotyczące parametryzacji dostosowują formularz zgodnie z charakterem i właściwościami
wykonywanego raportu. Informacje o domyślnych parametrach raportu, pomagają użytkownikowi
wybrać zakres żądanej informacji oraz sposób jej prezentacji.
Formularz parametryzujący PRZYGOTUJ_RAPORT
Formularz ten, wykonany przy użyciu narzędzia Oracle Forms, przejął rolę wszystkich formularzy
parametrów istniejących w poszczególnych raportach. Realizuje on wybór następujących elementów:
5
•
raportu, który ma zostać uruchomiony;
•
jego przeznaczenia (plik, podgląd, drukarka) i formatu (binarny, tekstowy, HTML, PDF);
•
zakresu informacji, która ma pojawić się na raporcie;
•
kolejności umieszczenia informacji;
•
wyglądu i roli raportu (szczegółowy, ogólny - podsumowujący).
Za pomocą informacji w tabeli K_REP_REPORTS jest on dostosowywany do wywołania każdego
z wymienionych w niej raportów. Dzięki możliwości określenia wyglądu raportu – drukowania lub nie
każdej z jego składowych możemy np. z raportu podającego informacje o dochodach poszczególnych
pracowników uzyskać raport o wydatkach miesięcznych poszczególnych jednostek, bądź też całej
uczelni. Funkcjonalność Oracle Forms w przeciwieństwie do Oracle Reports nie ogranicza nas do wyboru
żądanych parametrów tylko za pomocą list wartości. Można dzięki temu np. wybrać pracowników z
dowolnego podzbioru jednostek. Wszystkie ustawienia przekazywane są do tabeli K_REP_PARAMS
Tabela K_REP_PARAMS
Jest to tabela przechowująca dane dotyczące parametrów wywołania określonego raportu. Zawiera
ona informacje, za pomocą której raport wykonuje dokładnie to, czego żąda użytkownik. Dodatkowo,
inicjuje kolejne uruchomienia formularza parametrów. Dzięki temu nie ma potrzeby ponownego
ustawiania wszystkich parametrów raportu, w przypadku gdy chcemy go wykonać jeszcze raz. Ponadto
można w ten sposób uruchomić całkowicie inny raport z takimi samymi parametrami, a co za tym idzie z
identycznym podzbiorem informacji. Osiągamy w ten sposób możliwość analizy tych samych danych z
różnych punktów widzenia.
Oprócz tabeli K_REP_PARAMS istnieje cały szereg tabel pomocniczych do przechowywania
zbiorów wartości takich jak np. jednostki organizacyjne czy też poszczególni pracownicy.
Oczywiście w przypadku zastosowania obiektowo – relacyjnej bazy danych możemy zbiory wartości
przechowywać bezpośrednio w K_REP_PARAMS.
Zawartość tabeli K_REP_PARAMS możemy w zależności od przeznaczenia podzielić następująco:
•
parametry wykorzystywane w perspektywie KVR_PRACOWNICY
•
parametry dotyczące wyglądu raportu, drukowania lub nie poszczególnych składowych, treści tytułu,
podziału stron itd. Przeznaczone są one dla pakietu K2000_REPORTS, a za jego pośrednictwem
trafiają do wywoływanego raportu.
Tabela K_REP_AUDITS
Rolą jej jest przechowywanie parametrów wywołań poszczególnych raportów wraz z czasem
wywołania i nazwą użytkownika. Każde uruchomienie raportu powoduje przepisanie odpowiednich
informacji z tabeli K_REP_PARAMS do K_REP_AUDITS. Format przechowywanych danych może być
6
dowolny, od samych parametrów wywołania, do informacji o poszczególnych danych osobowych
udostępnionych w takim raporcie.
Perspektywa KVR_PRACOWNICY
Stanowi ona serce całego systemu. Parametryzowana jest za pomocą informacji w K_REP_PARAMS,
przez co udostępnia ściśle określony podzbiór danych dla każdego z raportów. Zakres perspektywy musi
być odpowiednio szeroki aby zaspokoić pod względem informacyjnym jak największą liczbę raportów.
Minimalizujemy w ten sposób liczbę dodatkowo włączanych tabel i złożoność samych zapytań wewnątrz
raportów. Z drugiej strony należy pamiętać o efektywności systemu, dlatego nie można doprowadzić do
sytuacji kiedy raporty ze swej natury proste i często uruchamiane byłyby wykonywane w czasie nie
satysfakcjonującym użytkownika. W takim przypadku należy rozważyć możliwość uproszczenia
perspektywy lub wyłączenia niedogodnych raportów ze zbioru wywoływanego w opisywany sposób.
Pakiet K2000_REPORTS
Posiada on w sobie szereg funkcji udostępniających dane zawarte w relacji K_REP_PARAMS. Pełni
on rolę pomocniczą i jego istnienie jest opcjonalne w całej konstrukcji. Tym niemniej ułatwia on
budowanie poszczególnych raportów. Może również przekazywać informacje przechowywane w innych
częściach systemu a dotyczące np. standardowych treści nagłówków, wyglądu logo, czy sposobu
drukowania numerów stron.
Raporty – czyli to co pozostaje.
Zdecydowana większość raportów nie posiada żadnych parametrów użytkownika, a co za tym idzie
formularza parametrów. Zapytania składają się z projekcji żądanych atrybutów, prostej klauzuli FROM –
zazwyczaj ograniczającej się tylko do perspektywy KVR_PRACOWNICY, klauzuli WHERE, w której
występują co najwyżej warunki połączeniowe z innymi relacjami oraz warunki związane z ewentualnymi
parametrami użytkownika. Praktycznie każda część rozkładu jest sparametryzowana. Ze względu na
warunki występujące w rozkładzie raportu warto skorzystać z możliwości tworzenia raportów z
wykorzystaniem szablonów.
Przykładowy raport, wykorzystujący opisany mechanizm, posiada formularz parametrów, w którym
wybierana jest składowa płacy poddawana analizie (PARAMETR1). Jedyne zapytanie raportu wygląda
następująco:
select RODZAJ_STANOWISKA, CZLOWIEK, WYMIAR_ZATRUDNIENIA,
JEDNOSTKA, STANOWISKO,
decode(:PARAMETR1, 'WZ',
nvl(WYNAGRODZENIE_BRUTTO, nvl((STAWKA_GODZ * 178 * WYMIAR_ZATRUDNIENIA),0)),
'DF',DODATEK_FUNK,0) DO_ANALIZY
from
KVR_PRACOWNICY
ORDER BY K2000_REPORT.SORTUJ(JEDNOSTKA, JO_LP, NAZWISKO, IMIE, IDENTYFIKATOR);
W zapytaniu użyto parametru :PARAMETR1 do wyboru odpowiedniego składnika wynagrodzenia.
Selekcja informacji dokonuje się w perspektywie. Parametryzacja ma miejsce w formularzu
7
parametryzującym PRZYGOTUJ_RAPORT. Sortowanie odbywa się na podstawie funkcji SORTUJ z
pakietu K2000_REPORT.
Rozkład przykładowego raportu pokazano na rysunku poniżej.
Nagłówek raportu
Tytuł raportu
Linia podziału strony
Nagłówek informacji
szczegółowych
Informacje szczegółowe
Podsumowanie dla jednostki
Podsumowanie dla raportu
Rysunek 2 Przykładowy rozkład raportu
Ważniejsze elementy rozkładu to:
•
Nagłówek raportu –
standardowy dla
wszystkich raportów,
definiowany
przez
pakiet
K2000_REPORTS.
•
Tytuł raportu – domyślny dla każdego raportu, z każdorazową możliwością zmiany przez
użytkownika.
•
„Bezbarwna” linia podziału strony – drukowana lub nie, decyduje o tym czy każda jednostka ma
rozpoczynać się na nowej stronie.
•
Nagłówek informacji szczegółowych – drukowany lub nie, wedle woli użytkownika.
•
Informacje szczegółowe – drukowane lub nie. Nie wydrukowanie ich powoduje, że otrzymujemy
raport jedynie z podsumowaniem, w ten sposób możemy zmienić charakter raportu.
•
Podsumowanie dla jednostki – drukowane lub nie.
•
Podsumowanie dla raportu – drukowane lub nie.
•
Pole F_NAZWA_INSTYTUTU mające swoje źródło w polu JEDNOSTKA (patrz zapytanie) może
przyjąć stałą wartość ‘WSZYSTKIE JEDNOSTKI’, co daje nam możliwość uzyskania wydruku bez
podziału na jednostki.
8
Zalety proponowanego rozwiązania
Wyodrębnienie z raportów ich wspólnej części i zaimplementowanie jej w oddzielnym module
programowym daje wiele wymiernych korzyści:
•
Znaczne zmniejszenie czasu tworzenia każdego z raportów – ograniczenie liczby elementów
wewnątrz raportu spowodowało, że jedyną czasochłonną operacją przy jego budowie jest
zdefiniowanie rozkładu.
•
Możliwość tworzenia raportów przez osoby bardzo słabo znające schemat bazy danych –
zapytania zostały uproszczone do tego stopnia, że nie potrzebna jest znajomość schematu bazy
danych. Selekcja odpowiednich rekordów oraz łączenie relacji wykonywane jest na poziomie
perspektywy.
•
Zminimalizowanie możliwości wystąpienia błędów – zlikwidowanie złożoności zapytań wewnątrz
raportów spowodowało zmniejszenie możliwości wystąpienia błędów w interpretacji danych lub też
w samych zapytaniach.
•
Częściowe zlikwidowanie formularzy parametrów w raportach – większość parametrów
wybierana jest w formularzu parametryzującym. Wewnątrz raportów pozostały jedynie te, które są
dla nich wyjątkowe.
•
Możliwość przekazywania parametrów pomiędzy raportami – istnienie tabeli przechowującej
ustawienia parametrów pozwoliło na wywoływanie różnych raportów z tymi samymi parametrami.
•
Możliwość śledzenia operacji użytkowników – istnienie tabeli z parametrami wiąże się
z wykonywaniem określonych operacji na bazie danych przy wywoływaniu raportu. Dzięki temu
procedura magazynująca informacje o dostępie użytkownika do określonych danych za
pośrednictwem raportu może być zaimplementowana na poziomie bazy danych – jako trigger
założony na tabeli z parametrami. Alternatywą tego rozwiązania jest zaimplementowanie
odpowiedniego mechanizmu w formularzu parametryzującym. W obydwu przypadkach operacja ta
będzie realizowana jest w jednym, ściśle określonym miejscu aplikacji.
•
Centralne dodawanie funkcjonalności – zmiana formularza parametryzującego oraz perspektywy,
na której operują raporty powoduje zmianę funkcjonalności wszystkich raportów bez konieczności
ingerencji w każdy z nich.
•
Zwiększenie możliwości parametryzacji – istnieją znacznie bardziej rozbudowane możliwości
związane z interakcją z użytkownikiem. Można wykorzystać „niestandardowe” dla raportów
elementy sterujące takie jak: pola wyboru, pola opcji, listy wyboru itd. Dzięki temu wybór żądanej
informacji dokonywany jest w sposób bardziej przejrzysty i elastyczny.
•
Zwiększenie funkcjonalności – każdy raport jest parametryzowany przez współdzielony formularz
parametryzujący stanowiący połączenie (sumę parametrów) wszystkich formularzy parametrów,
które występowałyby wewnątrz pojedynczych raportów.
9
•
Zlikwidowanie konieczności przekazywania parametrów – standardowo, jeżeli zdecydujemy się
oprzeć parametryzację o zewnętrzny formularz, musimy przekazywać dane z formularza do raportu.
Każda modyfikacja formularza pociąga za sobą modyfikację raportu z nim związanego.
Zastosowanie tabeli z parametrami i przekazywanie ich, za jej pośrednictwem, do perspektywy i
pakietu likwiduje tą konieczność. Każda przebudowa formularza parametryzującego pociąga za sobą
zmianę tylko w definicji perspektywy, propagując się automatycznie na wszystkie raporty.
•
Odporność na zmiany w schemacie bazy danych – zastosowanie perspektywy pozwala na
oddzielenie schematu relacji od zapytań istniejących w raportach. Zmiana definicji perspektywy oraz
przebudowa formularza parametryzującego umożliwia, w zdecydowanej większości przypadków,
ukrycie zmiany schematu relacji przed raportami.
•
Możliwość zmiany wyglądu i charakteru raportów – parametryzacja elementów rozkładu raportu
umożliwia jego modyfikacje na poziomie wywołania. Tak jak już wspominaliśmy pozwala to na
wygenerowanie samych podsumowań, zmianę tytułu, szybką modyfikację nagłówków w przypadku
zmiany adresu czy telefonu firmy.
Możliwe modyfikacje i uwagi do przedstawionego rozwiązania
Najbardziej kontrowersyjnym elementem w architekturze modułu był sposób przekazywania
parametrów
do
raportów.
Najprostszym
rozwiązaniem
byłoby
uruchamianie
raportów
przy
wykorzystaniu listy parametrów. Wymagałoby to jednak istnienia w każdym raporcie odpowiednich
parametrów użytkownika. Każda zmiana w liście parametrów spowodowana np. dodaniem dodatkowego
parametru implikowałaby konieczność modyfikacji odpowiednich raportów. Dlatego też zdecydowaliśmy
się na zastosowanie innej metody.
Jednym z pomysłów było wykorzystanie zmiennych pakietowych. Raport wykonywany jest w
osobnej sesji dlatego też sam musi inicjować zmienne pakietowe. Formularz parametryzujący wpisywał
informacje do tabeli z parametrami w postaci pojedynczego rekordu, a następnie przekazywał jego
identyfikator do raportu. Raport przed rozpoczęciem działania wpisywał uzyskane z tabeli parametry do
zmiennych pakietowych, które z kolei były odczytywane przez perspektywę. Mimo pozornej złożoności
rozwiązania wymagało to jedynie odpowiedniej procedury inicjalizującej w każdym z raportów.
Ostatecznie zrezygnowaliśmy jednak ze zmiennych pakietowych i zaszyliśmy tablicę z parametrami
bezpośrednio w perspektywie. Jedynym parametrem, który należało przekazać do perspektywy był
identyfikator rekordu z odpowiednimi parametrami. Najlepszym rozwiązaniem byłoby przekazanie tegoż
identyfikatora do raportu, a stamtąd do perspektywy. Biorąc jednak pod uwagę sekwencyjny sposób
pracy użytkowników systemu Kadry i Płace’2000, polegający na uruchamianiu tylko jednego raportu
jednocześnie, zdecydowaliśmy się na pewne uproszczenie. Każdy z użytkowników ma swój „prywatny”
wiersz w tabeli parametrów charakteryzowany przez nazwę użytkownika. Dzięki temu nie ma
konieczności przekazywania jakiegokolwiek parametru, a ponadto można „ustawioną” perspektywę
wykorzystywać również w innych elementach systemu – nie tylko w raportach.
10
Opisane rozwiązanie zostało dokładnie zweryfikowane podczas budowy przez Instytut Informatyki
PP systemu Kadry i Płace’2000, wdrożonego i funkcjonującego na Politechnice Poznańskiej od ponad
dwóch lat. Wykorzystywane jest ono w przypadku zdecydowanej większość raportów oraz wszystkich
modułów generujących dane do MS Excel’a. Rozbudowa systemu mająca miejsce na przełomie roku
98/99, a spowodowana reformą ZUS oraz ustawą o ochronie danych osobowych, wykazała ponownie
wyjątkową przydatność zastosowanej metody.
11