V Konferencja PLOUG
Zakopane
Październik 1999

Metodyka projektowania systemów z intensywnie

wykorzystywanymi danymi

Krzysztof Jankiewicz

[e-mail]

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.

2

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.

3

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ę.

4

• 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:

5

Perspektywa

„kvr_pracownicy”

Formularz

parametryzujący

„Przygotuj_raport”

Tabela zawierająca

informacje dotyczące

poszczególnych raportów

„k_rep_reports”

Tabela z parametrami

uruchomienia raportów

„k_rep_params”

Pakiet zawierający funkcje

pomocnicze

„k2000_reports”

Poszczególne

raporty

Informacje o tym kto, kiedy

i z jakimi parametrami

uruchamiał określone

raporty

„k_rep_audits”

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:

Rysunek 1. Zależności pomiędzy elementami modułu programowego.

6

• 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ć

7

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

8

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.

Podsumowanie dla raportu

Podsumowanie dla jednostki

Informacje szczegółowe

Nagłówek informacji

szczegółowych

Tytuł raportu

Nagłówek raportu

Linia podziału strony

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.

Rysunek 2 Przykładowy rozkład raportu

9

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.

10

• 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.

11

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.