Stromy v SQL

11. 1. 2006 | Pavel Szalbot | Různé | 14618×

Stromy lze s pomocí jazyka SQL sázet, kácet i česat vícero způsoby. Ukážeme si jeden klasický a dva pokročilejší.

Stromy

Definice

Pojmem strom se zpravidla označuje neorientovaný graf, jehož každé dva vrcholy jsou spojeny právě jednou cestou (pokud nerozumíte, zkuste se podívat třeba do wiki - graf, strom).

Strom může reprezentovat vybranou hierarchickou (stromovou) strukturu a ta je předmětem toho článku. Kde že jste mohli strom mimo park zahlédnout? Zajisté jste se s nimi setkali minimálně v diskusních fórech ABCLinuxu.cz, nebo při nakupování v internetovém obchodě, na jehož kategoriích výrobků si budeme práci se stromovou strukturou prezentovat. Důvodem je několik "zajímavých" akcí, jež se v internetovém obchodě provádějí. Uložištěm našeho stromu bude RDBMS komunikující jazykem SQL (konkrétně MySQL a v jednom případě i PostgreSQL).

Jaký strom zasadit?

V perexu jsem naznačil, že si ukážeme celkem tři příklady reprezentace stromu v SQL. Než si z nich vůbec začneme vybírat, měli bychom si ujasnit to, co od stromu budeme očekávat. Aplikace typu internetový obchod může provádět následující akce:

• základní práce se stromem - CRUD operace s uzly (kategoriemi) (Create, Retrieve, Update, Delete)
• rozbalení stromu ve vybraném uzlu
• nalezení všech "podkategorií" dané kategorie (pro různé filtry, ale také zobrazení všech výrobků z kategorie a jejich podkategorií)
• zobrazení cesty k vybranému uzlu od kořene

Operací s hierarchickou strukturou bude pravděpodobně více a mnohé mohou být efektivněji provedeny na aplikační úrovni (např. načtením celé struktury a jejím zpracováním namísto několika SQL dotazů). Ponechme je ale stranou a zkusme se podívat, co nám nabízí samotné SQL. Vzhůru do lesů!

Sebereferenční tabulky

Prvním způsobem uložení hierarchické struktury v SQL tabulce budou tzv. sebereferenční tabulky, definující strom seznamem následníků. Sebereferenční tabulky využívají vazby rodič-syn/dcera v hierarchické struktuře přítomné. Pro jednoduchost budeme předpokládat, že každý uzel má nanejvýš jednoho rodiče.

Uvažujme následující hierarchii kategorií:

SQL tabulka by mohla být vytvořena příkazem:

 CREATE TABLE categories(
  id INT NOT NULL PRIMARY KEY, 
  name VARCHAR(32), 
  parent INT NOT NULL);

a její obsah by vypadal takto:

+----+---------------------+--------+
| id | name                | parent |
+----+---------------------+--------+
|  1 | Operační systémy    |      0 |
|  2 | Unix                |      1 |
|  3 | Linux               |      1 |
|  4 | Windows             |      1 |
|  5 | Red Hat	    	   |	  3 |
|  6 | Mandriva            |      3 |
+----+---------------------+--------+

Jak vidíte, každý uzel má unikátní identifikátor (číslo ID) a také jsme mu přiřadili rodiče. Všimněte si, že kategorie "Operační systémy" má ve sloupci parent nulu, i když žádná taková kategorie v tabulce není. Její syny budeme označovat jako kořenové kategorie a pro ni samotnou nebudeme požadovat rodiče.

Podívejme se teď na operace, které nás při práci se stromovou strukturou budou otravovat.

CRUD operace jsou vcelku triviální. Vkládání zajistí prostý INSERT. Při odebírání bychom měli dbát na to, abychom dle potřeby rekurzivně smazali i uzly-syny, což je v košatém stromě docela náročné. Přesun uzlu (a celého jeho podstromu!) v rámci stromu, tj. změnu jeho rodiče, realizujeme jednoduchým UPDATE.

Zobrazení podstromu provedeme podobně jako smazání - rekurzivně vybereme všechny potomky právě zpracovávaného uzlu. Podotkněme, že výhoda načtení celého stromu a jeho zpracováním aplikací sice ušetří práci databázi, ale nelze ji dost dobře použít při získávání všech výrobků patřících do kategorií podstromu, kterých může být velmi mnoho.

Rozbalení stromu dle vybrané kategorie je variací na téma zobrazení podstromu s tím, že do hloubky jdeme jen po cestě od kořene k rozbalovanému uzlu. Nalezení této cesty je při této reprezentaci znovu náročné.

Předností sebereferenčních tabulky je jejich jednoduchost - při práci s ní si bohatě vystačíte se znalostí rekurze. Cenou ovšem bude neúměrné zatížení databázového serveru zvláště v případě, že se stromem budete pracovat často, což se u internetového obchodu děje obvykle s každou zobrazenou stránkou, či když strom bude hezky košatý (uzly mají mnoho potomků) a vysoký (mnoho generací potomků). Odlehčit si můžete jistou úrovní cachování stránek, nicméně časem se nejspíš poohlédnete po výkonnějším řešení.

Genealogické stromy

A narazíte možná na genealogické stromy. Genealogický strom také využívá vazbu rodič-syn mezi uzly, ale navíc pro každý uzel definuje i tzv. genealogický identifikátor. Tento identifikátor je unikátní pro každý uzel a dají se z něj vyčíst informace o jeho předcích (rodičích, prarodičích, prapra...) i potomcích. Identifikátor potomka totiž získáme tak, že za identifikátor předka připojíme identifikátor potomka.

Zvolíme-li za identifikátor písmeno abecedy, pak bude naše rozšířená tabulka obsahovat tyto záznamy:

+----+---------------------+--------+------+
| id | name                | parent | path |
+----+---------------------+--------+------+
|  1 | Operační systémy    |      0 |    A |
|  2 | Unix                |      1 |   AA |
|  3 | Linux               |      1 |   AB |
|  4 | Windows             |      1 |   AC |
|  5 | Red Hat      	   |	  3 |  ABA |
|  6 | Mandriva            |      3 |  ABB |
+----+---------------------+--------+------+

CRUD operace tentokrát váže několik nepříjemných podmínek. Jednou z nich je omezení počtu potomků dle volby uložení identifikátoru (v případě písmen abecedy smít uzel mít "jen" 26 přímých potomků). Vložení nového uzlu do stromu provedeme tak, že zjistíme genealogický identifikátor rodiče a za identifikátor uzlu zvolíme nejmenší možné písmeno abecedy, které je na dané úrovni volné (úrovní rozumíme množinu přímých potomků rodiče). Zaveďme proto požadavek, aby na sebe identifikátory sourozenců lexikálně navazovaly.

Odstraňení uzlu je velmi snadné. Stačí smazat všechny uzly, jejichž genealogický identifikátor začíná identifikátorem odstraňovaného uzlu. Pokud bychom v naší hierarchii chtěli z nabídky odstranit podstrom s kořenovou kategorií "Linux", provedli bychom SQL příkaz:

DELETE FROM categories WHERE genealogical LIKE 'AB%';

Tím nám ovšem může vzniknout mezera na úrovni mazaného uzlu (Linux), což si nepřejeme a musíme proto po smazaní uzlu aktualizovat identifikátory postižených uzlů.

Přesun uzlu provedeme příslušnou změnou umístění (změna rodiče) a následnou aktualizací identifikátorů.

Poznamenejme, že návaznost identifikátorů se nakonec zdá být spíše na škodu, jelikož nám práci docela komplikuje, nicméně se bez procedury na odstranění hluchých míst ve stromu nejspíš neobejdeme.

Zobrazení kompletního podstromu je poněkud svízelné. Sice nám postačí SELECT s klauzulí ORDER BY genealogical, aplikace ovšem často požaduje, aby byl výstup abecedně setříděn. Tuto komplikaci lze vyřešit už během CRUD operací, totiž vkládáním nových uzlů na správné místo. Cenou je bohužel režie spojená s tříděním a následnou aktualizací identifikátorů.

Chcete-li si ušetřit nepříjemnosti s nedostatkem písmen a přepočítáváním po mazání, můžete použít jiný identifikátor. V praxi se často používá např. speciální oddělovač následovaný číselnou sekvencí. Identifikátor uzlu Red Hat by byl "/1/3/5&qout;.

Konečně nalezení cesty k uzlu zařídí:

SELECT * FROM categories WHERE 'ABB' LIKE genealogical||'%'
nebo
SELECT * FROM categories WHERE 'ABB' LIKE concat(genealogical, '%')

Nested set aneb DFS strom

Posledním a dle mého názoru nejvýkonnějším řešením je tzv. nested set reprezentace stromu. (Pozn.: Tento název používá Joe Celko a z různých článku se zdá, že není sám. Ačkoli podstatu uložení informace o uzlech charakterizuje čitelně i pro základních grafových algoritmů neznalé, lepší název by mohl být DFS strom.) Podívejme se nejprve na tabulku:

+----+---------------------+--------+------+-------+
| id | name                | parent | left | right |
+----+---------------------+--------+------+-------+
|  1 | Operační systémy    |      0 |    1 |    12 |
|  2 | Unix                |      1 |    2 |     3 |
|  3 | Linux               |      1 |    4 |     9 |
|  4 | Windows             |      1 |   10 |    11 |
|  5 | Red Hat	    	   |	  3 |    5 |     6 |
|  6 | Mandriva            |      3 |    7 |     8 |
+----+---------------------+--------+------+-------+

Vychází ze sebereferenční tabulky, kterou rozšiřuje atributy left a right. Jejich hodnoty jsou získány průchodem stromu DFS (depth first search) algoritmem. Pseudokód algoritmu:

 DFS(graf)
  foreach uzly_grafu as uzel do
    uzel->barva = bila
  done
  cas = 0
  foreach uzly_grafu as uzel do
    if uzel->barva = bila
      DFS-PROJDI(uzel)
  done
  end

DFS-PROJDI(uzel)
  uzel->barva = seda
  cas = cas + 1
  uzel->nalezen = cas
  foreach sousede[uzel] as soused do
    if soused->barva = bila
      DFS-PROJDI(soused)
  done
  uzel->barva = cerna
  uzel->opusten = cas

Algoritmus začíná voláním funkce DFS, které je předán zkoumaný graf. Ta nastaví barvu všech uzlů na bílou (uzel dosud nebyl navštíven), seřídí čas a následně prochází uzly grafu s tím, že pokud je uzel bílý, zavolá funkci DFS-PROJDI. DFS-PROJDI přebarví uzel na šedou (byl navštíven, ale dosud se zpracovává), zvedne čas o jedničku a použije jej jako čas navštívení uzlu a poté rekurzivně prochází dosud nenavštívené sousedy uzlu předaného jako parametr. Jakmile jsou všichni sousedé zpracování, přebarví uzel na černou (zpracování dokončeno), nastaví čas opuštění uzlu a vrací se.

Čas navštívení a opuštění uzlu se použijí jako hodnoty atributů left resp. right v SQL tabulce. Lepší představu o výsledku můžete získat z obrázku.

Všimněte si, že interval <left;right> libovolného uzlu je podintervalem intervalu vlastního rodiče (odtud nested set = vnořené množiny). Tato vlastnost plyne z toho, jak DFS prochází strom a ukladá časy a právě ona nám ulehčí práci s hierarchickou strukturou v SQL.

Podívejme se na operace, které chceme nad strukturou provádět. Všechny podkategorie zvolené kategorie získame jednoduchým SELECTem:

SELECT * FROM categories WHERE left >=x AND right <=y

Oproti rekurzi sebereferenčních tabulek podmíněnou mnoha dotazy či spíše přenosem většího množství dat jsme ve výhodě, ovšem genealogický identifikátor umožňuje totéž, ač s nutností použití pomalejšího operátoru LIKE. Získat výstup setříděný podle názvu uzlů je tentokrát o něco jednodušší. Po každé CRUD operaci totiž musíme aplikovat DFS algoritmus na celý strom znovu. Aby DFS generoval časy s ohledem na abecední pořadí uzlů, stačí naštěstí jen vhodně připravit pořadí uzlů, ve kterém jsou algoritmem zpracovávány (nezapomeňte abecedně setřídit i pole sousede[uzel]).

Cestu k uzlu nalezneme také velmi jednoduše. Stačí si uvědomit, že každý předek uzlu byl navštíven dříve a opuštěn později než uvažovaný uzel.

SELECT * FROM categories WHERE left <= x AND right >=y

DFS strom se zdá být velmi vhodný pro statické, či málo upravované struktury. Uplatnění si však zajisté najde i v případě potřeby vyhledávání ve velmi rozsáhlých hierarchických strukturách.

Závěr

Předvedli jsme si tři možné reprezentace hierarchické struktury v SQL databázích. Jejich přednosti a nevýhody je třeba zvážit vždy s ohledem na konkrétní využití, přičemž společnou výhodou se jeví zvláště přenositelnost mezi různými databázovými servery. Dle předložených indicií a zdrojů na internetu si zajisté zvolité správnou reprezentaci pro požadované použití.

       

Komentáře

[diverman]

Dobrej článek. Přidávám nějaké odkazy do slovníku:
SŘBD
RDBMS
PostgreSQL
MySQL

[3018736794024648]

<ohraný vtip> Proč pařez není strom?

Protože obsahuje kružnice. </ohraný vtip>

[Martin Beránek]

ale divil by ses kolik lidi to nezna

[Věroš]

Moji kolegové ten vtip nejen neznají, ale ani se mu nesmějí A to jsem si na něj ráno taky vzpomněl.

[twain]

A vite, ze strom neni nic jineho nez souvisly les? Miluju teorii grafu :).

[Jiří Hlinka]

Díky za tenhle článek!
Jirka

[100rk]

Pred casem vysel podobny clanek na interval.cz: http://interval.cz/clanek.asp?article=3801

[Pavel 'lingeek' Szalbot]

Interval bohužel nečtu, to bych ten článek možná nedopsal. Ale zaujalo mě pojmenování "Modified Preorder Tree Traversal Algoritmus" .

[Leoš Literák]

Ze podobny clanek vysel jinde pro nas neni zadne kriterium. To bychom nemohli vydavat skoro nic, protoze vzdycky by se ve svete naslo neco podobneho. Dulezite ale je, aby clanek byl originalni. Coz Pavluv clanek je.

[100rk]

Moje reakce byla myslena jen jako dalsi informacni zdroj na toto tema. Nepodsouvejte mi prosim jine umysly.

[Leoš Literák]

Nic jsem vam nepodsouval. Jen jsem sdelil nase kriteria.

[Tom Hlava]

Děkuji za pěkný článek.
Rád bych se zeptal:
Nebude u varianty "DFS" nutné zajistit, aby při CRUD operaci byl průchod stromem prováděn v jednom okamžiku pouze jedním procesem?
Stačí standardní trasakce, nebo nějaká vyšší úroveň izolace? - nebude nakonec potřeba zamknout na dobu průchodu celou tabulku?

[Pavel 'lingeek' Szalbot]

Záleží na tom, co potřebujete. Pokud vyloženě nesmí dojít k práci s nekonzistentními daty, zřejmě potřebujete buď exclusive (table) lock u InnoDB (MyISAM) tabulek MySQL, nebo serializable level u PostgreSQL. U jiných RDBMS analogicky...

[Vladimir Kralik]

Velmi dobry clanok. Dakujem.

[hajma]

oba odkazy na wiky jsou shodné, opravte si to

[Pavel 'lingeek' Szalbot]

Strom -> http://cs.wikipedia.org/wiki/Strom_%28graf%29

[morpho]

Zdravim, clanek je super. Dle meho nazoru by tohle meli vyucovat jiz na strednich technickych skolach. Obcas se v praci setkavam s novymi spolupracoviky kteri se honosi titulem ing, ale znaji jen Sebereferenční tabulky.

V Oracle jsou pro stromy primo embedded funkce, je neco podobneho i v MySQL nebo Postgree?

Morpho

[Pavel 'lingeek' Szalbot]

PostgreSQL má modul ltree v contribu viz třeba výborný článek na Rootu.

[Pavel Janousek]

No pokud vyuka abstraktnich datovych typu/struktur je v podani jisteho, dnes jiz Profesora, tak se ani k tem sebereferencnim tabulkam nedostanete...

[JP]

Pan studoval v Brně, není-liž pravda?

[zde]

Kterou školu? Tady je těch technik, kde se informatika učí, povícero...

[Murdej]

No to já znám jednoho ing co udělal strom který měl maximálně 3 úrovně a měl pro každou větev zvlášť tabulku :)

[Trained.Monkey]

Diky za skvely clanek, jsem jeden z "PHP programatoru",ale snazim se polepsit, hlavne posledni algoritmus mi prijde docela vychytany.

[Honza]

Chtěl bych upozornit, že definujete strom jako speciální případ neorientovaného grafu, ale v databázi i na obrázku jej chápete jako orientovaný. V neorientovaném stromu nemají pojmy jako potomek nebo předek co dělat. Ale jinak zajímavý článek.

[Pavel 'lingeek' Szalbot]

Správně. Jsem rád, že si toho někdo všimnul. Orientaci jsem nakonec vypustil, abych to už nekomplikoval - nechtěl jsem zabřednout v definicích (i když by to vyspravila jedna věta). Hierarchická struktura už ovšem orientaci potřebuje a tu jsem spolu s označením "stromová" používal.

[zde]

Moc jsem nepochopil proč se pro DFS strom uzlům přiřazují DVĚ čísla. IMHO by úplně stačilo jen očíslovat uzly v depth-first pořadí, ušetří se jednak jeden sloupec, navíc doména toho zbylého bude poloviční (ušetří se jeden bit).

Pro vyhledání podstromu pak pro daný kořen X stačí vyhledat uzly x, pro které X <= x < Y, kde Y je nejmenší větší sybling k X. K jeho zjištění je sice potřeba dalšího dotazu, ale obvykle když potřebuji kompletní podstrom uzlu X, zobrazuji někde poblíž i všechny jeho syblings, takže je to zadarmo.

Jo a taky si myslím že i "hloupý" rekurzivní výpis by mohl být docela rychlý, kdyby se prováděl breadth-first. Lidé nemají rádi hluboké hierarchie, určitě ne při nakupování- hloubka stromu zřejmě nepřesáhne 4-5. Mějme dejmetomu strom hloubky 5, hledáme podstrom uzlu v hloubce 3 (uprostřed): stačí nám 2 dotazy! Nač to komplikovat?

[zde]

Jo a vůbec- proč je strom při tom číslování barven? Vždyť je to úplně zbytečné. Jo a taky jednu z těch dvou inkrementací počitadla jde taky zrušit, tj 'right' jednoho node může být klidně rovno 'left' toho node, který v prohledávání do hloubky následuje.

def Renumber (node, counter):
    node.left = counter; counter++
    for i in node.get_child_list ():
        counter = Renumber (i, counter)
    node.right = counter; counter++
    return counter
Renumber (root, 1)

[Fin]

IMHO lepsi reseni lepsi nez DFS strom: Trees in SQL databases

[Andrej]

Na začiatok sa chcem poďakovať za článok. Zhodou okolností práve píšem bakalársku prácu na rovnakú tému, preto by som sa chcel spýtať, či by mi niekto nevedel poradiť vhodnú literatúru. Vyšlo niečo k stromovým dátam aj v češtine alebo slovenčine?, za odpoveď vopred ďakujem.....