Implementacja struktur hierarchicznych w relacyjnym modelu danych

Rozdział 22 Implementacja struktur hierarchicznych w relacyjnym modelu danych Streszczenie. Problem reprezentacji danych hierarchicznych w modelu relacyjnym istnieje od momentu powstania tego modelu. Pomimo komercyjnego sukcesu i powszechnego wykorzystania systemów relacyjnych zagadnienia dotyczące efektywnego przechowywania i przetwarzania danych hierarchicznych pozostają nadal otwarte. Na przestrzeni lat opracowano wiele alternatywnych modeli reprezentacji danych hierarchicznych w modelu relacyjnym. Żaden z nich nie jest doskonały. Istnieje zatem potrzeba szukania nowych rozwiązań. Propozycja jednego z nich jest celem niniejszego opracowania. Prezentowane rozwiązanie stanowi integrację modelu listy sąsiedztwa z modelem zbiorów zagnieżdżonych. Korzyścią wynikającą z takiej integracji jest możliwość modyfikacji struktury hierarchii w intuicyjny i prosty sposób znany z modelu listy sąsiedztwa oraz wydobywanie danych za pomocą czystego SQL z wydajnością właściwą dla modelu zbiorów zagnieżdżonych. Ponadto zaproponowano interpretację teoriomnogościową modelu zbiorów zagnieżdżonych. 1 Wstęp Od początku swojego istnienia, relacyjny model danych krytykowany był za brak możliwości efektywnej obsługi danych hierarchicznych. Dane tego typu z łatwością można było przechowywać i przetwarzać w systemach hierarchicznych. Relacyjne bazy danych zyskały jednak akceptację przemysłu i stały się kluczowym elementem Systemów Informatycznych. Pomimo upływu ponad 30 lat problem reprezentacji danych hierarchicznych w modelu relacyjnym nie doczekał się jednoznacznego rozwiązania. Wynika to w dużej mierze z trudności wydajnej implementacji rekurencji w silnikach bazodanowych. Celem niniejszego rozdziału jest przedstawienie obecnego stanu wiedzy odnośnie reprezentacji danych hierarchicznych w relacyjnych bazach danych oraz zaproponowanie własnego modelu. Podstawowe kwestie, które należy rozważyć analizując poszczególne rozwiązania to łatwość odwzorowania struktury hierarchicznej na postać relacji, efektywność przetwarzania takiej reprezentacji oraz przejrzystość wykonywania na niej zapytań. Adam Przybyłek: Uniwersytet Gdański, Katedra Informatyki Ekonomicznej, ul. Armii Krajowej 119/121, 81-824 Sopot, Polska email: adam@univ.gda.pl

A. Przybyłek Ponadto w przypadku zapytań oczekuje się, aby można było je formułować w czystym SQL 1, co nie w każdym modelu jest możliwe. Reszta pracy ma następujący układ. W podrozdziale drugim sprecyzowano pojęcie danych hierarchicznych. Podrozdział trzeci zawiera przegląd znanych modeli reprezentacji danych hierarchicznych w postaci relacji. Ponieważ dwa z nich - model listy sąsiedztwa oraz model zbiorów zagnieżdżonych należą do najczęściej wykorzystywanych oraz stanowią szkielet zaproponowanego w tej pracy rozwiązania, ich szczegółowej analizy dokonano osobno w kolejnych podrozdziałach. Dla modelu zbiorów zagnieżdżonych zaproponowano interpretację na gruncie teorii mnogości. Przedostatni rozdział to wkład do obecnego dorobku w rozważanej dziedzinie. Zawiera propozycję integracji modelu listy sąsiedztwa z modelem zbiorów zagnieżdżonych w celu uniknięcia ich ograniczeń przy jednoczesnym wykorzystaniu mocnych stron. Dla proponowanego rozwiązania przedstawiona została implementacja w systemie PostgreSQL. 2 Dane hierarchiczne w ujęciu teorii grafów Hierarchia jest naturalnym sposobem organizacji danych takich jak: struktura organizacyjna firmy, hierarchia zależności szef-podwładny, katalog produktów pogrupowanych w kategorie, klasyfikacja roślin, struktura plików i katalogów w komputerze, struktura wątków na grupie dyskusyjnej. Wymienione dane przyjęło się określać jako hierarchiczne. Wspólną cechą danych hierarchicznych jest możliwość przedstawienia ich w postaci struktury węzłów połączonych krawędziami. Węzły reprezentują obiekty, a krawędzie zależności typu rodzic-dziecko między obiektami. W strukturze tej tylko jeden węzeł, zwany korzeniem nie ma rodzica. Każdy inny węzeł ma dokładnie jednego rodzica. Węzeł może mieć zero lub wiele dzieci. W teorii grafów strukturę tego typu nazywa się drzewem z wyróżnionym korzeniem. Formalna definicja brzmi następująco[1]: Drzewo z wyróżnionym korzeniem to acykliczny graf spójny, w którym wyróżniony jest jeden węzeł, nazwany korzeniem. Na potrzeby niniejszej pracy został wykorzystany akademicki przykład - struktura organizacyjna fikcyjnej firmy (rys. 1). Węzły reprezentują pracowników firmy (identyfikator; nazwisko; imię; pensja), a krawędzie zależności szef-podwładny. (1; King; Rafał; 7000) (2; Sobol; Kamil; 3000 ) (3; Kowalski; Jan; 5000) (4; Kiwa; Anna; 2500 ) (5; Tkacz; Ewa; 3000) (6; Ziemba; Adam; 2500 ) (7; Nowak; Tomasz; 4500 ) (8; Kurczak; Beata; 2500) (9; Lewandowski; Marcin; 3000) (10; Decewicz; Karol; 2000 ) Rys. 1. Schemat organizacyjny jako przykład danych hierarchicznych 1 Na potrzeby niniejszego opracowania termin "czysty SQL" odnosi się do standardu SQL/92 (zwanego też SQL2) i jest używany w celu podkreślenia braku elementów proceduralnych oraz rekurencji. 216

Implementacja struktur hierarchicznych w relacyjnym modelu danych Dane hierarchiczne można z łatwością przedstawić w hierarchicznej bazie danych [2]. Wynika to z tego, że struktury danych oferowane przez bazy hierarchiczne - typy węzłów oraz związki rodzic-dziecko, są zgodne ze strukturą danych hierarchicznych [3]. Problem pojawia się jednak w momencie potrzeby zapisania takich danych w systemie relacyjnym. Systemy relacyjne jako jedyną strukturę danych udostępniają relację. Należy zatem przyporządkować różnowartościowo drzewom relacje, w taki sposób, aby istniała efektywna metoda przekształcenia niżej wymienionych operacji wykonywanych na drzewach, na operacje wykonywane na relacjach. Do operacji tych należą: dodanie węzła, usunięcie węzła wraz ze wszystkimi potomkami, zmiana rodzica (przeniesienie gałęzi drzewa), znalezienie potomków/przodków węzła w zadanych pokoleniach, znalezienie węzłów leżących na ścieżce między zadanymi węzłami. 3 Przegląd modeli reprezentacji danych hierarchicznych Pomimo, że zagadnienie reprezentacji danych hierarchicznych w postaci relacji jest dobrze znane w społeczności bazodanowców, nie doczekało się prostego i efektywnego rozwiązania. Opracowano wiele modeli, z których żaden nie jest wolny od wad, a wybór każdego z nich uzależniony jest od konkretnych zastosowań. Przedstawione w niniejszym opracowaniu modele reprezentują drzewa w postaci dwóch tabel 2 : node i entity (rys. 2). Tabele te powiązane są związkiem 1:1 po kolumnach. Tabela node koduje strukturę hierarchii, a tabela entity opisuje obiekty związane z poszczególnymi węzłami. Podejście takie sprawia, że tabela entity jest niezależna od przyjętego modelu i zależy tylko od atrybutów obiektu związanego z węzłem. Z kolei tabela node zależy od sposobu kodowania hierarchii, ale jest niezależna od dziedziny przedmiotowej, z której pochodzą dane. node... opis węzła entity attribute1... Rys. 2. Model ogólny reprezentacji danych hierarchicznych Najbardziej intuicyjne i proste rozwiązanie dostarcza model oparty o listę sąsiedztwa (ang. adjacency list model) [4], [5], [6], nazywany dalej modelem AL. W modelu tym struktura hierarchii kodowana jest w postaci dwukolumnowej tabeli. Wartość pola pierwszej kolumny identyfikuje węzeł dziecka, a wartość pola drugiej kolumny identyfikuje węzeł jego rodzica. Zaletą modelu AL jest łatwość dodania nowych wierzchołków oraz usunięcia całej gałęzi. Wady uwidaczniają się w momencie wykonywania zapytań. Wydobycie niektórych informacji wymaga rozszerzenia SQL o elementy proceduralne lub rekurencyjne. Rozszerzenia takie oferuje coraz więcej producentów baz danych. Jednak ze względu na ich ograniczoną wydajność w przypadku dużych ilości danych, są mało przydatne. Powstały więc modele alternatywne. 2 W literaturze przedmiotu modele te często przedstawiane są w postaci jednej tabeli. Ponieważ takie rozwiązanie jest mniej elastyczne i narusza zasady normalizacji, w niniejszej pracy modele te zostały zdekomponowane na dwie tabele. 217

A. Przybyłek Częściową poprawę wydajności wydobywania danych w modelu AL zaproponował David Rozenshtein [7]. Modyfikacja polega na dodaniu do tabeli node kolumny level, służącej do przechowywania - w formie jawnej - odległości od korzenia. Informacja ta umożliwia przeszukiwanie drzewa metodą wszerz. Największym uznaniem w społeczności bazodanowców cieszy się model zbiorów zagnieżdżonych (ang. nested sets model) [4], [5], [8], [6], nazywany dalej modelem NS, oraz jego modyfikacje. Model ten z każdym węzłem wiąże dwie wartości kodujące jego pozycję w hierarchii. Wartości te wraz z identyfikatorem węzła przechowywane są w tabeli node. Reprezentacja ta umożliwia wydajne wydobywanie danych za pomocą czystego SQL. Kłopoty sprawia jednak wykonywanie tak prostych operacji jak wstawianie i usuwanie węzłów. Trudności te wynikają po pierwsze z ustalenia wartości sztucznych pól reprezentujących hierarchię, a po drugie z częstego przeliczania tych wartości dla dużej liczby węzłów w trakcie modyfikacji struktury drzewa. W wyniku prób usprawnienia modelu NS ze względu na operacje modyfikacji struktury drzewa powstał model zagnieżdżonych interwałów (ang. nested intervals model) [9]. Ogranicza on proces przeliczania wartości kodujących pozycję w hierarchii tylko do tej gałęzi drzewa, która jest modyfikowana. Kolejny model - zmaterializowanych ścieżek (ang. materialized path model) [5], [8] opiera się na przechowywaniu przez każdy węzeł ścieżki do korzenia. Ścieżka ta reprezentowana jest w postaci napisu składającego się z identyfikatorów kolejnych węzłów, oddzielonych specjalnymi znakami. Wykonywanie zapytań sprowadza się do wykonywania operacji tekstowych na napisie reprezentującym ścieżkę. 4 Model listy sąsiedztwa Lista sąsiedztwa to najprostszy w zrozumieniu i implementacji model umożliwiający przechowywanie danych hierarchicznych w postaci relacji. Struktura hierarchii implementowana jest za pomocą listy sąsiedztwa zawierającej identyfikator węzła dziecka oraz identyfikator jego rodzica. Krawędzie reprezentowane są zatem bezpośrednio w postaci rekordu w tabeli node (rys. 3). rodzic dziecko node id_parent opis węzła opis rodzica entity attribute1... Rys. 3. Model listy sąsiedztwa Tabela node posiada związek rekurencyjny rodzic-dziecko, który mówi, że węzeł w drzewie może być rodzicem wielu dzieci oraz dzieckiem tylko jednego rodzica. Definicja obiektu (zapisanie rekordu w tabeli entity) nie musi oznaczać, że staje się on częścią drzewa. Natomiast każdy węzeł tworzący drzewo (rekord w tabeli node) musi być skojarzony z opisującym go obiektem. Ponieważ istnieje jeden węzeł, który nie ma rodzica - korzeń drzewa, stąd związek opisujący rodzica jest opcjonalny. Operacje znajdowania rodzica lub dzieci, dodawania węzłów oraz zmiany rodzica są bardzo proste i mogą być zrealizowane w czystym SQL. W porównaniu do innych modeli szczególnie efektywnie realizowana jest ta ostatnia. Za pomocą czystego SQL może być 218

Implementacja struktur hierarchicznych w relacyjnym modelu danych również wykonana operacja usuwania całej gałęzi. Wymaga to jednak nałożenia na kolumnę id_parent więzów integralności referencyjnej w postaci kaskadowego usuwania. Wykonanie zapytań operujących na wielu poziomach hierarchii za pomocą czystego SQL jest bardzo ograniczone i mało elastyczne. Przykładowo znalezienie potomków lub przodków danego węzła w ściśle określonym pokoleniu wymaga wykonania tylu samozłączeń tabeli node, ile wynosi różnica pokoleń między tymi węzłami. Z kolei wyszukanie wszystkich węzłów na ścieżce między dwoma węzłami, o których nie wiadomo na jakich są poziomach, w ogóle nie jest możliwe za pomocą czystego SQL. Ponieważ każdy węzeł ma wskaźnik na swojego rodzica, naturalnym i eleganckim sposobem rozwiązania tego typu zadań jest wykorzystanie rekurencji. Popularność modelu opartego o listę sąsiedztwa sprawiła, że najwięksi dostawcy baz danych udostępnili w swoich produktach rozszerzenia rekurencyjne [2], [5]. Wadą jest jednak brak kompatybilności między poszczególnymi rozwiązaniami. Przykładowo Oracle oferuje złączenie rekurencyjne w postaci klauzuli CONNECT BY. Z kolei DB2 posiada bardziej ogólne wsparcie rekurencji w postaci konstrukcji WITH RECURSIVE, zdefiniowanej w SQL3. Natomiast SQL Server 2005 jako mechanizm rekurencji dostarcza T-SQL. Niestety wszystkie z wymienionych implementacji są mało wydajne. Przy dużych ilościach danych hierarchicznych czas ich przetwarzania w modelu AL jest nie do przyjęcia. Ponadto istnieją bazy danych nie posiadające bezpośredniego wsparcia dla przetwarzania danych hierarchicznych. W takim przypadku można wykorzystać rozszerzenia proceduralne, co nie jest zbyt wygodne w zapytaniach ad-hoc, lub wykorzystać inny model przechowywania danych hierarchicznych. 5 Model zbiorów zagnieżdżonych Zależności hierarchiczne mogą być reprezentowane w postaci jawnej, jak w modelu AL lub zakodowanej. Postać zakodowana pomimo, że zwykle jest mniej intuicyjna, dostarcza tych samych informacji. W modelu NS zależności hierarchiczne zakodowane są za pomocą wartości atrybutów lft i rgt związanych z każdym węzłem (rys. 4). node lft rgt Rys. 4. Model zbiorów zagnieżdżonych opis węzła entity attribute1... Odpowiednie wartości lft i rgt można ustalić wykorzystując rekurencyjną funkcję visitdfs (listing 1). Funkcja ta przechodzi drzewo metodą w głąb, poczynając od węzła przekazanego jako argument. Listing 1. Pseudokod funkcji visitdfs visitdfs(node) if (node.lft = NULL) then node.lft := 1 count := node.lft for i := 1 to node.numberofchilds node.child(i).lft := count + 1 count := visitdfs( node.child(i) ) node.rgt := count + 1 return node.rgt 219

A. Przybyłek Po wywołaniu funkcji visitdfs na korzeniu drzewa z rys. 1, poszczególne węzły zostały oznaczone jak na rys. 5. 1 (1,20) 2 (2,3) 3 (4,13) 4 (14,15) 5 (16,19) 6 (5,6) 7 (7,12) 8 (17;18) 9 (8,9) 10 (10,11) Rys. 5. Reprezentacja danych hierarchicznych za pomocą drzewa Zależnościom hierarchicznym między tak oznaczonymi węzłami można nadać interpretację teoriomnogościową. Niech z węzłem v i będzie skojarzony zbiór V i ={lft i, lft i+1, lft i+2,..., rgt i }. Wówczas relacja bycia przodkiem/potomkiem w drzewie odpowiada relacji inkluzji na skojarzonych zbiorach w następującym sensie: węzeł v y jest przodkiem węzła v x, co zapisujemy v y f v x, jeżeli V y V x. Ponadto powiemy, że węzeł v y jest rodzicem węzła v x wtedy i tylko wtedy, gdy zbiór skojarzony z v y jest przecięciem po wszystkich zbiorach skojarzonych z przodkami v x, lub równoważnie ( v y f vx ) ( z yvz f vx vz f v y ). Analogicznie definiujemy pojęcia potomka i dziecka. Oczywiście węzeł v i jest liściem jeżeli moc zbioru V i wynosi 2, a korzeniem jeżeli liczba 1 V i. Przedstawiając zbiory w formie graficznej otrzymujemy równoważną drzewu reprezentację danych hierarchicznych (rys. 6), wyjaśniającą nazwę modelu - zbiory zagnieżdżone. 2 3 1 7 5 6 9 10 4 8 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Rys. 6. Reprezentacja danych hierarchicznych za pomocą zbiorów Model NS został wprowadzony i wypromowany przez Joe Celko. Umożliwia wydajne wydobywanie danych za pomocą czystego SQL. Przewaga nad modelem AL widoczna jest w szczególności wtedy, gdy należy wydobyć dane z poddrzewa o nieznanej wysokości. Wykorzystanie atrybutów lft i rgt umożliwia wydobycie całej gałęzi drzewa mającej początek w określonym węźle za pomocą tylko jednego złączenia. Model NS umożliwia także 220

Implementacja struktur hierarchicznych w relacyjnym modelu danych wydobycie węzłów leżących na ścieżce między dwoma dowolnymi węzłami drzewa. Przykłady kwerend do omawianego modelu zawiera listing 2. Listing 2. Przykłady kwerend do modelu NS --wyświetlić dla każdego węzła poziom w hierarchii SELECT node., COUNT(*) as level FROM node n, node parent WHERE n.lft BETWEEN parent.lft AND parent.rgt GROUP BY n.; --wyświetlić węzeł v wraz z potomkami SELECT des.* FROM node des, node n WHERE n. = :v AND des.lft BETWEEN n.lft AND n.rgt; --wyświetlić przodków węzła v SELECT anc.* FROM node n, node anc WHERE anc.lft < n.lft AND anc.rgt > n.rgt AND n. = :v ORDER BY anc.rgt; --wyświetlić wspólnych przodków węzła v1 i v2 SELECT anc.* FROM node n1, node n2, node anc WHERE anc.lft < n1.lft AND anc.rgt > n1.rgt AND anc.lft < n2.lft AND anc.rgt > n2.rgt AND n1. = :v1 AND n2. = :v2 ORDER BY anc.lft; --wyświetlić ścieżkę między węzłami v1 i v2 przy założeniu 3, że v1 f v2 SELECT n2.*, ( SELECT COUNT(*) FROM node n WHERE n.lft BETWEEN n1.lft AND n1.rgt AND n2.lft BETWEEN n.lft AND n.rgt) AS path_number FROM node n1, node n2, node n3 WHERE n1. = :v1 AND n3. = :v2 AND n2.lft BETWEEN n1.lft AND n1.rgt AND n3.lft BETWEEN n2.lft AND n2.rgt ORDER BY path_number; Podstawowym ograniczeniem modelu NS jest jego efektywne zastosowanie wyłącznie do hierarchii rzadko zmieniających się w czasie. Przyczyną tego ograniczenia są niestabilne wartości kodujące hierarchię. Przy wstawianiu/usuwaniu węzła lub zmianie jego rodzica należy przeciętnie zmodyfikować około połowy z wszystkich wartości służących do kodowania hierarchii. Ponadto operacji wymagających reorganizacji struktury drzewa nie można wykonać za pomocą pojedynczej instrukcji i zwykle wykorzystuje się do tego rozszerzenia proceduralne. 6 Integracja modelu AL z modelem NS Dokonana w poprzednich rozdziałach analiza modelu AL oraz NS sugeruje, że żaden z nich nie jest doskonały, a decyzja o wykorzystaniu jednego z nich zależy od konkretnej sytuacji. W modelu AL w łatwy sposób, posługując się czystym SQL, można zrealizować operacje takie jak dodanie i usunięcie węzła, zmiana rodzica, wyszukanie dzieci lub rodzica. Z kolei 3 Brak tego założenia sprawia, że kwerenda staje się wielokrotnie dłuższa. 221

A. Przybyłek w modelu NS operacje te wymagają rozszerzeń proceduralnych w celu automatycznego przeliczenia wartości pól lft i rgt. Biorąc zaś pod uwagę możliwości przetwarzania danych znajdujących się na wielu poziomach hierarchii (i możliwe, że na nieznanej liczbie poziomów), model AL wypada słabiej. Struktura modelu AL wymaga, w tego typu zadaniach, rozszerzeń proceduralnych lub rekurencyjnych. Natomiast w modelu NS można to zrobić efektywniej i prościej, używając czystego SQL. W niniejszym rozdziale zaproponowano integrację obu modeli w taki sposób, aby wykorzystać zalety każdego z nich. Schemat proponowanego modelu przedstawia diagram z rys. 7. Oddzielenie struktury hierarchii od danych opisujących węzły ułatwiło integrację obu modeli oraz zminimalizowało redundancję danych. rodzic dziecko node_al id_parent opis węzła opis rodzica entity attribute1... opis węzła node_ns lft rgt Rys. 7. Integracja modelu listy sąsiedztwa z modelem zbiorów zagnieżdżonych Dla tabeli node_al utworzono wyzwalacz, który w momencie wykonania operacji modyfikacji (wstawienie, usunięcie, aktualizacja wiersza) wywołuje funkcję modify_ns (listing 3). Zadaniem funkcji modify_ns jest przekształcenie operacji modyfikacji w modelu AL na odpowiadające im operacje w modelu NS i wykonanie ich na tabeli node_ns. Kod PL/pgSQL funkcji modify_ns przedstawiono na listingu 3. 222 Listing 3. Kod PL/pgSQL funkcji modify_ns CREATE OR REPLACE FUNCTION modify_ns() RETURNS trigger AS ' DECLARE parentrgt node_ns.lft%type; oldlft node_ns.lft%type; oldrgt node_ns.rgt%type; rozstep INTEGER; BEGIN IF TG_OP = ''INSERT'' THEN SELECT INTO parentrgt rgt FROM node_ns WHERE = NEW.id_parent; IF NOT FOUND THEN parentrgt:=1; END IF; UPDATE node_ns SET lft = CASE WHEN lft > parentrgt THEN lft + 2 ELSE lft END, rgt = CASE WHEN rgt >= parentrgt THEN rgt + 2 ELSE rgt END WHERE rgt >= parentrgt; INSERT INTO node_ns VALUES ( NEW., parentrgt, (parentrgt+1) ); END IF; IF TG_OP = ''UPDATE'' THEN SELECT INTO parentrgt rgt FROM node_ns WHERE = NEW.id_parent; IF NOT FOUND THEN parentrgt:=1; END IF; SELECT INTO rozstep rgt-lft+1 FROM node_ns WHERE = OLD.; UPDATE node_ns SET lft = CASE WHEN lft > parentrgt THEN lft + rozstep ELSE lft END, rgt = CASE WHEN rgt >= parentrgt

Implementacja struktur hierarchicznych w relacyjnym modelu danych THEN rgt + rozstep ELSE rgt END WHERE rgt >= parentrgt; SELECT INTO oldlft, oldrgt lft, rgt FROM node_ns WHERE = OLD.; UPDATE node_ns SET lft = lft + (parentrgt - oldlft), rgt = rgt + (parentrgt - oldlft) WHERE lft >= oldlft AND rgt <= oldrgt; UPDATE node_ns SET lft = CASE WHEN lft > oldrgt THEN lft - rozstep ELSE lft END, rgt = rgt - rozstep WHERE rgt > oldrgt; END IF; IF TG_OP = ''DELETE'' THEN SELECT INTO oldlft, oldrgt lft, rgt FROM node_ns WHERE = OLD.; DELETE FROM node_ns WHERE lft >= oldlft AND rgt <= oldrgt; rozstep := oldrgt - oldlft + 1; UPDATE node_ns SET lft = CASE WHEN lft > oldrgt THEN lft - rozstep ELSE lft END, rgt = CASE WHEN rgt > oldrgt THEN rgt - rozstep ELSE rgt END WHERE rgt > oldrgt; END IF; RETURN NULL; END; ' LANGUAGE 'plpgsql'; Zaproponowany model zawiera pełną funkcjonalność modelu AL, umożliwia wydobywanie danych z wydajnością właściwą dla modelu NS oraz dodatkowo daje nowe możliwości związane z wykonywaniem zapytań wykorzystujących oba modele jednocześnie (Listing 4). Ceną tych udogodnień są narzuty związane z dwukrotnym przechowywaniem danych o strukturze drzewa. Listing 4. Przykład kwerendy do modelu zintegrowanego --dla każdego pracownika podległego pod najwyższy szczebel wyświetlić łączne zarobki jego i wszystkich podległych mu pracowników SELECT e_lev1.firstname, e_lev1.lastname, sum(e.salary) FROM node_al root, node_al n_lev1_al, node_ns n_lev1_ns, node_ns des, entity e, entity e_lev1 WHERE n_lev1_al.=n_lev1_ns. AND root.id_parent is null AND e.=des. AND e_lev1.=n_lev1_al. AND n_lev1_al.id_parent=root. AND des.lft BETWEEN n_lev1_ns.lft AND n_lev1_ns.rgt GROUP BY e_lev1., e_lev1.firstname, e_lev1.lastname; 7 Podsumowanie i wnioski W niniejszym rozdziale przedstawiono najczęściej wykorzystywane modele reprezentacji danych hierarchicznych w modelu relacyjnym. Szczególnie skoncentrowano się na modelach AL oraz NS. Dla modelu NS zaproponowano interpretację na gruncie teorii mnogości. Po przeanalizowaniu obu modeli zauważono, że słabe strony każdego z nich są mocnymi stronami drugiego. Słabą stroną modelu AL jest wyszukiwanie danych z wielu poziomów 223

A. Przybyłek hierarchii, natomiast słabą stroną modelu NS są operacje modyfikacji struktury hierarchii. Zaproponowano więc integrację obu modeli w taki sposób, aby modyfikacja struktury hierarchii odbywała się w tak prosty sposób jak w modelu AL, a wyszukiwanie danych było możliwe w sposób znany zarówno z jednego, jak i drugiego modelu. Utworzony model poprzez mechanizm wyzwalaczy automatycznie synchronizuje strukturę hierarchii pochodzącą z modelu NS ze strukturą pochodzącą z modelu AL. Takie podejście ukrywa przed końcowym użytkownikiem konieczność przeliczania wartości lft i rgt kodujących hierarchię podczas wstawiania, usuwania i aktualizacji danych oraz eliminuje konieczność posługiwania się rozszerzeniami SQL w trakcie wydobywania danych. W proponowanym modelu można wykonywać zarówno operacje modyfikacji struktury hierarchii w sposób właściwy dla modelu AL, jak i zaawansowane operacje wydobywania danych w identyczny sposób jak dla modelu zbiorów zagnieżdżonych. Literatura 1. K.A. Ross, Ch.R.B Wirght, Matematyka dyskretna, PWN, Warszawa 2005 2. J.D. Ullman, J.Widom, Podstawowy wykład z systemów baz danych, WNT, Warszawa 2001 3. P. Beynon-Davies, Systemy baz danych, WNT, Warszawa 2000 4. J. Celko, SQL, Zaawansowane techniki programowania, MIKOM, Warszawa 1999 5. J. Celko, SQL, Trees and Hierarchies in SQL for Smarties, Morgan Kaufmann, San Francisco 2004 6. R.J. David Burke, Traversing Trees in SQLBase, Centura Pro, Volume 4, Number 4-5, 1999 7. Magazyn SQL FORUM, Vol. 3, No. 4, 1995 8. V. Tropashko, Trees in SQL: Nested Sets and Materialized Path, www.dbazine.com, 2005 9. V. Tropashko, Nested Intervals Tree Encoding in SQL, SIGMOD Record, Vol. 34, No. 2, 2005 224