Perspektywy (views) w Systemie Zarządzania Bazą Danych Oracle

część I

Robert Wrembel
Politechnika Poznańska, Instytut Informatyki
ul. Piotrowo 3A, 60-965 Poznań
e-mail: Robert.Wrembel@cs.put.poznan.pl

Bardzo ważnym mechanizmem w systemach baz danych jest
perspektywa. Intuicyjnie, perspektywa jest swego rodzaju „oknem”,
przez które użytkownik bazy danych widzi udostępniane przez nią dane. W
tradycyjnych systemach relacyjnych baz danych, perspektywy są wykorzystywane
m.in. do: (1) ograniczenia i autoryzacji dostępu do danych, (2) zapewnienia
logicznej niezależności danych przez odseparowanie aplikacji od schematu
konceptualnego bazy danych, (3) uproszczenia schematu bazy danych, (4)
prezentowania tych samych danych w różny sposób. Inną, wykorzystywaną
szeroko dziedziną zastosowań perspektyw są magazyny danych i systemy
rozproszone. Zadaniem perspektyw jest tutaj, po pierwsze, integracja danych
pochodzących z różnych geograficznie rozproszonych źródeł, po drugie,
replikacja danych rozproszonych w celu skrócenia czasu dostępu do nich i po
trzecie, materializowanie wyników czasochłonnych zapytań. Do tego celu są
stosowane migawki (ang. snapshots), zwane również perspektywami
zmaterializowanymi
(ang. materialized views). Istniejące na rynku systemy
zarządzania bazami danych wspierają mechanizm perspektyw zarówno
niematerializowanych, jak i zmaterializowanych. Niniejszy artykuł jest poświęcony
zagadnieniom perspektyw w Systemie Zarządzania Bazą Danych Oracle.

1. Wprowadzenie

W systemach baz danych perspektywa (ang. view) jest strukturą
logiczną opartą o zapytanie do bazy danych, umożliwiającą dostęp do
podzbioru atrybutów i rekordów jednej lub wielu tabel. Oznacza to, że
perspektywa nie posiada własnych danych, lecz udostępnia tylko te dane, które
są wynikiem zapytania ją definiującego. Inaczej jest w przypadku tzw. perspektywy
zmaterializowanej
(ang. materialized view). Perspektywa taka posiada własne
trwałe dane – będące wynikiem zmaterializowania danych wyznaczonych przez
zapytanie definiujące tę perspektywę.

Dane gromadzone i przetwarzane przez przedsiębiorstwa są
zwykle przechowywane w systemach informatycznych posiadających różne
struktury i wykorzystujących różne modele danych (np. hierarchiczne,
relacyjne, obiektowe), w dokumentach tekstowych, czy arkuszach kalkulacyjnych.
Ponieważ przedsiębiorstwa, instytucje, organizacje (producenci danych) są często
geograficznie rozproszone, więc same dane mają również charakter
rozproszony. Heterogeniczność i rozproszenie informacji utrudnia do nich dostęp
i ich analizę. Z tego powodu istnieje potrzeba integracji tych informacji.

W praktyce stosuje się dwie technologie integracji danych,
tzw. system sfederowanych baz danych (ang. federated database system)
[ERS99] i technologię magazynu danych (ang. data warehouse) [WKM00,
JLVV00, CAAT01]. W obu przypadkach perspektywy są wykorzystywane jako mechanizm
zintegrowanego dostępu do danych.

Nawet w przypadku homogenicznego środowiska rozproszonego
(wykorzystującego ten sam model danych, ten sam system zarządzania bazą
danych, identyczne struktury danych w każdym z węzłów) zachodzi potrzeba
integracji danych i replikacji danych. Replikacja ma na celu skrócenie czasu
dostępu do danych znajdujących się w zdalnych węzłach oraz uniezależnienie
się od czasowej niedostępności tych węzłów i awarii sieci.

W systemach magazynów danych dane są eksplorowane za pomocą
złożonych zapytań zawierających od kilku do kilkudziesięciu operacji łączenia,
filtrowania, grupowania i agregowania danych. Są to tzw. zapytania typu OLAP
(ang. On Line Analytical Processing). Ze względu na złożoność zapytań OLAP
oraz rozmiary adresowanych przez nie danych, czas wykonania tych zapytań może
trwać dziesiątki minut, a nawet godziny. Kluczowym problemem staje się więc
efektywność systemu bazy danych. Jednym z rozwiązań zwiększających
efektywność systemu jest materializowanie częściowych/pośrednich wyników
najczęściej wykonywanych zapytań za pomocą perspektyw zmaterializowanych.

Niniejszy artykuł jest poświęcony zagadnieniom perspektyw
w Systemie Zarządzania Bazą Danych Oracle8i i Oracle9i. Artykuł
składa się z trzech części. W części pierwszej zostaną omówione:
koncepcja perspektywy relacyjnej, jej własności i cele stosowania (punkt 2)
oraz wykorzystanie perspektyw w zapytaniach i poleceniach modyfikacji danych –
DML (punkt 3). Część druga artykułu będzie poświęcona replikacji danych i
wykorzystaniu migawek (perspektyw zmaterializowanych) w tym kontekście. Zostaną
tu przedstawione m.in.: koncepcja migawki, sposoby jej definiowania i odświeżania,
grupy odświeżania oraz słownik bazy danych udostępniający informacje na
temat migawek. Część trzecia artykułu będzie omawiała zagadnienia poświęcone
optymalizacji zapytań z wykorzystaniem perspektyw zmaterializowanych.

2. Perspektywa relacyjna

2.1. Podstawowe własności perspektywy

Perspektywa stosowana w systemach relacyjnych posiada następujące
własności:

  1. Perspektywa bazuje na tabelach, na innych perspektywach
    lub jednocześnie na tabelach i perspektywach, nazywanych odpowiednio tabelami
    i perspektywami bazowymi (ang. base tables, base views).

  2. Z użytkowego punktu widzenia, perspektywa ma strukturę
    taką samą jak tabela, a więc jest zbiorem rekordów o określonych
    atrybutach. Na poziomie fizycznym perspektywa różni się od tabeli tym, że
    nie posiada własnych danych. W konsekwencji, na atrybutach perspektywy nie
    można definiować indeksów.

  3. W słowniku bazy danych perspektywa jest przechowywana w
    postaci zapytania ją definiującego. Zapytanie skierowane do perspektywy
    jest łączone z zapytaniem ją definiującym, a następnie tak przetworzone
    zapytanie jest kierowane do tabel bazowych.

2.2. Cele stosowania perspektywy

W tradycyjnych systemach relacyjnych baz danych podstawowe
cele stosowania perspektyw są następujące:

  1. Autoryzacja dostępu do danych
    Ponieważ perspektywy udostępniają tylko podzbiór rekordów i ich atrybutów
    zawartych w tabelach bazowych, ukrywają w ten sposób dane przed nieupoważnionym
    użytkownikiem. Użytkownicy otrzymują prawa dostępu do perspektyw,
    natomiast nie otrzymują praw dostępu do tabel bazowych.
    Przykładem stosowania perspektyw do ukrycia pewnych informacji jest słownik
    bazy danych. W ramach tego słownika wyróżnia się perspektywy
    przeznaczone dla użytkowników bazy danych (np. w systemie Oracle: user_db_links,
    user_triggers) oraz perspektywy przeznaczone dla administratorów
    bazy danych, udostępniające więcej informacji niż perspektywy dla użytkowników
    (np. w systemie Oracle: dba_db_links, dba_triggers).

  2. Ułatwienie dostępu do danych
    W przypadku częstych odwołań do tych samych tabel przy pomocy tych samych
    lub nieznacznie zmodyfikowanych skomplikowanych zapytań, zaleca się użycie
    tych zapytań do zdefiniowania odpowiedniej perspektywy. Odwołania do tej
    perspektywy umożliwiają pobranie tych samych danych co poprzednio, lecz za
    pomocą znacznie prostszych zapytań.
    Przykładem stosowania perspektyw w celu ułatwienia dostępu do danych jest
    słownik bazy danych, np. w systemie Oracle: perspektywy dba_tablespaces,
    dba_data_files, dba_rollback_segs.

  3. Możliwość prezentowania tych samych danych w różny
    sposób
    W definicji perspektywy mogą wystąpić np. wyrażenia arytmetyczne operujące
    na atrybutach tabel bazowych i literałach. Umożliwia to wstępne
    przetworzenie danych z tabel bazowych i ich prezentację w postaci
    (formacie) preferowanej przez użytkownika.

  4. Logiczna niezależność danych
    Aplikacje korzystające z bazy danych za pomocą perspektyw nie wymagają
    modyfikacji w przypadku zmodyfikowania tabel bazowych. W przypadku zmiany
    schematu tabel bazowych należy zmodyfikować wyłącznie definicję
    odpowiednich perspektyw tak, aby ich schemat pozostał taki, jak poprzednio.
    Wówczas aplikacje nie będą wymagały żadnej modyfikacji.

  5. Możliwość wprowadzenia dodatkowego poziomu ograniczeń
    integralnościowych
    Ograniczenia te są zawarte w definicji perspektywy i rozszerzają listę
    ograniczeń integralnościowych związanych z tabelami bazowymi (np.
    klauzula with check option w systemie Oracle).

Perspektywy zmaterializowane pozwalają dodatkowo m.in. na:

  1. Integrację danych pochodzących z rozproszonych homo- i
    heterogenicznych źródeł danych oraz uniezależnienie użytkowników od
    konieczności dostępu do rozproszonych danych źródłowych [ERS99,
    JLVV00].

  2. Materializowanie częściowych wyników najczęściej
    wykonywanych zapytań OLAP, przez co możliwe jest skrócenie czasu
    odpowiedzi na takie zapytania [Rous98, GuMu99].

2.3. Rodzaje perspektyw

Ze względu na postać zapytania definiującego perspektywę,
perspektywy można podzielić na proste i złożone. Perspektywa
jest prostą jeżeli zapytanie ją definiujące:

  • odwołuje się wyłącznie do jednej tabeli bazowej;

  • nie wykorzystuje funkcji języka SQL w celu przetwarzania
    wartości atrybutów udostępnianych przez perspektywę;

  • nie wykorzystuje wartości wyliczanych, np. pensja*podatek;

  • nie wykorzystuje funkcji grupowych (np. suma, średnia);

  • nie wykorzystuje klauzul connect by oraz start
    with
    (system Oracle);

  • nie wykorzystuje operatora distinct i
    operatorów zbiorowych (np. suma, część wspólna)

Perspektywy bazujace na pojedynczej tabeli
Rys. 1. Perspektywy bazujące na pojedyńczej tabeli

Na rysunku 1 przedstawiono dwie perspektywy typu prostego,
bazujące na tabeli T1. Pierwsza z nich, oznaczona jako V1 udostępnia
wszystkie atrybuty wybranych rekordów, natomiast perspektywa V2 udostępnia
wybrane atrybuty wszystkich rekordów tabeli bazowej.

Drugim rodzajem perspektywy jest perspektywa złożona. Dla
tego rodzaju perspektywy zapytanie ją definiujące nie spełnia przynajmniej
jednego warunku przedstawionego dla perspektywy prostej.

Przykład perspektywy opartej o dwie tabele bazowe
przedstawiono na rysunku 2. Perspektywa taka może udostępniać podzbiór połączonych
rekordów, wybrane atrybuty wszystkich połączonych rekordów lub podzbioru
tych rekordów.

Perspektywa bazujaca na dwóch tabelach
Rys. 2. Perspektywa bazująca na dwóch tabelach

Rodzaj perspektywy decyduje o możliwościach uaktualniania
danych przez nią udostępnianych (zob. punkt 3.2).

3. Wykorzystanie perspektywy w zapytaniach i poleceniach DML

Do perspektywy można się odwoływać w zapytaniach w taki
sam sposób jak do tabel. Natomiast w przypadku próby modyfikowania danych
tabel bazowych poprzez perspektywę należy się liczyć z dużymi
ograniczeniami.

3.1. Przetwarzanie zapytań kierowanych do perspektywy

W przypadku skierowania zapytania do perspektywy, system zarządzania
bazą danych (SZBD) łączy to zapytanie
z zapytaniem definiującym perspektywę, m.in.:

  • w klauzuli select pojawia się wspólna część
    zbioru atrybutów wyspecyfikowanych w zapytaniu użytkownika i zapytaniu
    definiującym perspektywę;

  • w klauzuli where pojawiają się warunki
    wyboru pochodzące zarówno z zapytania użytkownika, jak i definicji
    perspektywy (łączone operatorem and).

Następnie, tak przetransformowane zapytanie jest kierowane
do tabel bazowych perspektywy.

Przykładowo, rozważmy perspektywę sprzedaż_sklepów,
opartą o tabele sklepy i sprzedaż o schematach przedstawionych
poniżej. Atrybut sklepy.sklep_id jest kluczem podstawowym tabeli sklepy.
Natomiast klucz podstawowy tabeli sprzedaż stanowi trójka atrybutów sprzedaż.produkt_id,
sprzedaż.sklep_id, sprzedaż.data. Atrybut sprzedaż.sklep_id
jest kluczem obcym wskazującym na sklepy.sklep_id.

SQL> desc sklepy



























NameNull?Type
---------
SKLEP_IDNOT NULLNUMBER(3)
NAZWANOT NULLVARCHAR2(20)
MIASTONOT NULLVARCHAR2(15)


SQL> desc sprzedaz




































Name Null? Type
--- --- ---
PRODUKT_ID NOT NULL NUMBER(4)
L_SZTUK NOT NULL NUMBER(3)
CENA_JEDN NOT NULL NUMBER(7,2)
DATA NOT NULL DATE
SKLEP_ID NOT NULL NUMBER(3)

Perspektywa sprzedaż_sklepów udostępnia informacje
o sprzedaży produktów w poszczególnych sklepach miasta Poznania.

create view sprzedaz_sklepow (sklep, produkt, l_sztuk,
cena_jedn, data)
as
select
sk.nazwa, sp.produkt_id, sp.l_sztuk, sp.cena_jedn,
sp.data
from sklepy sk, sprzedaz sp
where sk.sklep_id = sp. sklep_id
and sk.miasto = 'Poznań';

Do perspektywy tej skierowano poniższe zapytanie o sprzedaż produktów w
maju 2001 roku.

select sklep, produkt, l_sztuk, cena_jedn
from sprzedaz_sklepow
where data like '%05.2001';

Zapytanie to zostanie połączone z zapytaniem definiującym
perspektywę i przetransformowane przez moduł wykonujący SQL do równoważnego
zapytania opartego o tabele bazowe perspektywy sprzedaż_sklepów. Do
bazy danych trafi ostatecznie poniższe zapytanie na tabelach bazowych.

select sk.nazwa, sp.produkt_id, sp.l_sztuk, sp.cena_jedn
from sklepy sk, sprzedaz sp
where sk.sklep_id = sp. sklep_id
and sk.miasto = 'Poznań'
and data like ‚%05.2001’;

Innym rodzajem perspektywy, jest tzw. perspektywa in-line,
która jest tworzona dynamicznie w czasie wykonania zapytania. Perspektywa taka
to zapytanie występujące w klauzuli from innego zapytania. Jako
przykład wykorzystania tego rodzaju perspektywy rozważmy zapytanie wyznaczające
pięć pierwszych sklepów, które sprzedały towary za największą kwotę.
Jest to tzw. zapytanie typu top-N.

Przykładowe zapytanie (w systemie Oracle8i) z
perspektywą typu in-line zostało przedstawione poniżej:

select *
from (select nazwa, sum(l_sztuk*cena_jedn)
from sprzedaz sp, sklepy sk
where sp.sklep_id=sk.sklep_id
group by nazwa
order by sum(l_sztuk*cena_jedn) desc)
where rownum < 6;

3.2. Możliwości modyfikowania danych poprzez perspektywę

W zapytaniach perspektywa może być stosowana w sposób
identyczny, jak tabela. Natomiast możliwości bezpośredniego modyfikowania
danych udostępnianych przez perspektywę są ograniczone.

3.2.1. Ograniczenia systemowe na modyfikowalność perspektywy

Jeżeli perspektywa jest prosta i dodatkowo udostępnia
wszystkie atrybuty, których wartość jest obowiązkowa (not null),
to za pomocą takiej perspektywy można wstawiać dane do jej tabeli bazowej,
modyfikować dane widoczne przez tę perspektywę i je usuwać.

Jeżeli perspektywa prosta zawiera atrybuty wyliczane przez
funkcje SQL lub wyrażenia arytmetyczne, to za jej pomocą można stawiać i
modyfikować dane pod warunkiem że wartości wyliczane pozostają puste (przy
wstawianiu) i nie są modyfikowane. Natomiast usuwanie rekordów jest zawsze możliwe.

Jeżeli natomiast perspektywa jest oparta o połączenie, to
można przez nią uaktualniać dane pochodzące wyłącznie z tabeli zawierającej
klucz obcy (foreign key). Usuwanie rekordów jest również możliwe,
jednak warunki wyboru rekordów muszą zostać wyspecyfikowane z wykorzystaniem
atrybutów tabeli zawierającej klucze obce i/lub atrybuty połączeniowe.
Wstawianie rekordów jest zabronione.

Jeżeli perspektywa bazuje na łączeniu tabel w schemat
gwiazdy (por. rysunek 3a), wówczas operacje modyfikowania i usuwania mogą
dotyczyć wyłącznie tabeli T3. Natomiast jeżeli perspektywa bazuje na
tabelach łączonych w hierarchię (por. rysunek 3b), to operacje modyfikowania
i usuwania danych mogą dotyczyć wyłącznie tabeli T6.

Łaczenie tabel w schemat gwiazdy i hierarchię
Rys. 3. Łączenie tabel w schemat gwiazdy i hierarchię

Jeżeli perspektywa jest oparta o połączenie zewnętrzne
(ang. outer join), wówczas jedyną możliwą operacją jest wyszukiwanie danych
za jej pomocą.

W systemie Oracle informacje na temat atrybutów
perspektyw, które można uaktualniać są dostępne za pomocą perspektywy słownika
danych USER_UPDATABLE_COLUMNS. Jej schemat jest następujący
















































NazwaWartość NULL?Typ
---------------
OWNERNOT NULLVARCHAR2(30)
NOT NULL
TABLE_NAMENOT NULLVARCHAR2(30)
COLUMN_NAMENOT NULLVARCHAR2(30)
UPDATABLE VARCHAR2(3)
INSERTABLE VARCHAR2(3)
DELETABLE VARCHAR2(3)

Wartością atrybutu table_name są zarówno nazwy
tabel użytkownika jak i jego perspektyw. Dla każdego atrybutu perspektywy (column_name)
podawana jest informacja o możliwości modyfikowania wartości tego atrybutu (updatable),
wstawiania rekordu zawierającego wartość tego atrybutu (insertable)
oraz usuwania rekordu zawierającego wartość tego atrybutu (deletable).
Wartością każdego z trzech atrybutów, tj. updatable, insertable,
deletable jest YES lub NO.

Przykładowo, poniższe zapytanie wyświetla z USER_UPDATABLE_COLUMNS
informacje o perspektywie sprzedaż_sklepów.

select * from user_updatable_columns
where table_name = `SPRZEDAZ_SKLEPOW`;

Jego wynik, uzyskany w systemie Oracle8i,
przedstawiono poniżej. Wynika z niego, że jedynym atrybutem, którego wartości
nie można ani modyfikować, ani wstawiać poprzez perspektywę rekordu do
tabeli zawierającej ten atrybut, ani usuwać z niej rekordu, jest sklep.
Atrybut ten należy do tabeli sklepy, a więc tej, która zawiera klucz
podstawowy. Pozostałe atrybuty perspektywy pochodzą z tabeli sprzedaż,
tj. zawierającej klucz obcy do tabeli sklepy. Dla tych atrybutów
dozwolone są wszystkie operacje – insert, update i delete.


























































OWNERTABLE_NAMECOLUMN_NAMEUPDINSDEL
------------------------------------
SCOTTSPRZEDAZ_SKLEPOW
NONONO
SCOTTSPRZEDAZ_SKLEPOWPRODUKTYESYESYES
SCOTTSPRZEDAZ_SKLEPOWL_SZTUKYESYESYES
SCOTTSPRZEDAZ_SKLEPOWCENA_JEDNYESYESYES
SCOTTSPRZEDAZ_SKLEPOWDATAYESYESYES

Należy tu zwrócić uwagę na ważny fakt. Pomimo, że powyższa
zawartość USER_UPDATABLE_COLUMNS sugeruje możliwość wstawiania
rekordów za pomocą perspektywy, to w rzeczywistości jednak taka operacja będzie
niedozwolona i zakończy się komunikatem:

ORA-01779: cannot modify a column which maps to a non key-preserved
table

Dozwolone jest natomiast dla perspektywy sprzedaż_sklepów
usuwanie rekordów z tabeli sprzedaż i modyfikowanie wartości tych
rekordów, np.

delete from sprzedaz_sklepow where sklep='DOMIX';

3.2.2. Wyzwalacz instead-of perspektywy

Omówione wyżej ograniczenia dotyczące modyfikacji danych
poprzez perspektywę można zastąpić własnym sposobem modyfikowania zawartości
tabel bazowych perspektywy. Do tego celu służy wyzwalacz instead-of
definiowany dla perspektywy.

Jako przykład wykorzystania tego wyzwalacza rozważmy trzy
następujące tabele: klienci_poznań, klienci_kraków, klienci_pozostali,
każda o identycznym schemacie, przedstawionym poniżej:

SQL> desc klienci_poznan



























Nazwa Wartość NULL? Typ
---- ---- ----
KLIENT_ID NOT NULL NUMBER(2)
NAZWISKO NOT NULL VARCHAR2(10)
MIASTO NOT NULL VARCHAR2(10)

Tabele te posłużyły do zdefiniowania perspektywy w następujący
sposób:

create view v_klienci
as select * from klienci_poznan
union
select
* from klienci_krakow
union
select
* from klienci_pozostali;

W celu zapewnienia możliwości wstawiania rekordów przez tę
perspektywę należy zdefiniować dla niej wyzwalacz instead-of.
Przykładowy kod takiego wyzwalacza został przedstawiony poniżej:

create or replace trigger v_kl_modyfikacja
instead of insert on v_klienci
begin
if :new.miasto='Poznań'
then insert into klienci_poznan
values (:new.klient_id, :new.nazwisko, :new.miasto);
elsif :new.miasto='Kraków'
then insert into klienci_krakow
values (:new.klient_id, :new.nazwisko, :new.miasto);
else
insert into klienci_pozostali
values (:new.klient_id, :new.nazwisko, :new.miasto);
end if;
end;

Klauzula instead of umożliwia wskazanie
zdarzenia, które spowoduje uruchomienie wyzwalacza. W klauzuli tej wykorzystuje
się słowa kluczowe insert, update, delete
umożliwiające zdefiniowanie wyzwalacza reagującego odpowiednio na wstawienie,
uaktualnienie, usunięcie rekordów dostępnych za pomocą perspektywy.

Bibliografia

[CAAT01] Corey M., Abbey M., Abramson I., Taub B.: Oracle8i
Data Warehousing. Osborne/McGraw-Hill, 2001, ISBN 0-07-212675-2

[ERS99] Elmargamid A., Rusinkiewicz M., Sheth A.: Management
of Heterogeneous and Autonomous Database Systems. Morgan Kaufmann Publishers,
Inc. 1999, ISBN 1-55860-216-X

[GuMu99] Gupta A., Mumick I.S.: Materialised Views:
Techniques, Implementations, and Applications. MIT Press, 1999, ISBN
0-262-57122-6

[JLVV00] Jarke M., Lenzerini M., Vassiliou Y., Vassiliadis
P.: Fundamentals of Data Warehouses. Springer-Verlag, 2000, ISBN 3-540-65365-1

[O8SSql] Dokumentacja techniczna – Oracle8i Server. Oracle8i
SQL Reference, rel. 8.1.6

[OraCE] Materiały szkoleniowe Oracle Polska: Oracle8i: New
Features for Administrators

[Rous98] Roussopoulos N.: Materialized Views and Data
Warehouses. SIGMOD Record, Vol. 27, No. 1, 1998, pp. 21-26

[WiWr95] Wieczerzycki W., Wrembel R.: Perspektywy w
relacyjnych bazach danych. Informatyka 8/95

[WJZ99] Wrembel R. Jezierski J., Zakrzewicz M.: System Zarządzania
Bazą Danych Oracle7 i Oracle8. Wydawnictwo NAKOM, 1999, ISBN 83-86969-34-2

[WKM00] Wrembel R., Królikowski Z., Morzy M.: Magazyny
danych – stan obecny i kierunki rozwoju. Pro Dialog, nr 10, 2000, pp. 75-93,
ISBN 83-86969-43-1, ISSN 0867-6011

[Wre00] Wrembel R.: Perspektywy (views) w systemach baz
danych: aktualny stan technologii. VI Konferencja Użytkowników i Deweloperów
Oracle – PLOUG’00, Zakopane, październik 2000, pp. 83-98, ISSN 1641-2117