Hierarchický model databáze: definice, struktura a příklady

Struktura a základní pojmy

Hierarchická databáze se skládá z těchto základních částí:

• Root (kořen) – počáteční uzel stromu, nemá rodiče.
• Uzel (záznam) – reprezentuje konkrétní entitu s vlastními atributy.
• Vazba rodič–dítě – uspořádání, kde rodič může mít více potomků (1 : N), zatímco každý potomek má pouze jednoho přímého rodiče.
• Typ entity – šablona záznamu se seznamem atributů. Ve smyslu modelování může být typ entity analogií k tabulce v relačním modelu, a jednotlivé záznamy k řádkům, přičemž atributy odpovídají sloupcům.

Vlastnosti a chování

• Navigační přístup – data se obvykle čtou průchodem stromem pomocí ukazatelů nebo cest od kořene k požadovanému uzlu (např. posun po parent/child ukazatelích).
• Jednoduché a rychlé čtení strukturovaných dat – pokud jsou dotazy dobře sladěné se stromovou strukturou (např. čtení celé větve), může být výkon velmi dobrý.
• Redundance – opakující se informace se často duplikují, pokud je potřeba realizovat vztahy N:M nebo kdy entita potřebuje více než jednoho rodiče (což hierarchický model přímo nepodporuje).
• Omezená flexibilita – změny struktury (přesuny uzlů, přidávání nových vztahů mezi již existujícími typy) mohou být složitější než v relačních modelech.

Příklady a implementace

Nejznámějšími a dlouhodobě používanými hierarchickými databázemi jsou IMS vyvinutá společností IBM a registr Windows společnosti Microsoft. Další vyskyty hierarchických principů najdeme v souborových systémech (adresářová stromová struktura), v LDAP (adresářové služby) nebo v některých starších podnikových systémech.

Výhody

• Efektivní pro scénáře, kde jsou vztahy přirozeně stromové (např. organizační struktury, katalogy, menu, adresářové struktury).
• Jednoduché a předvídatelné průchody dat, nízké nároky na spojování (joiny) pro typické dotazy.
• Dobrá rychlost při čtení celé větve nebo podstromu.

Nevýhody

• Špatná podpora pro vztahy mnoho‑k‑mnoha; často je potřeba duplikovat záznamy nebo vytvářet složité obcházení.
• Méně flexibilní při změnách schématu než relační modely.
• Pro některé typy dotazů (např. hledání napříč větvemi nebo opačnými vztahy) může být neefektivní.
• Nedostatek standardizovaných dotazovacích jazyků podobných SQL; přístup bývá navigační/programový.

Kdy použít hierarchický model

Hierarchický model volíme, pokud data přirozeně tvoří strom (např. stromová klasifikace produktů, organizační diagramy, konfigurace a nastavení v registrech či konfiguracích) a pokud budou převládající dotazy navigační (procházení větví). V moderních řešeních často nahradí tento model flexibilnější dokumentové databáze (JSON/XML) nebo relační/graph databáze podle požadavků na vztahy a dotazování.

Krátký příklad

Představte si organizační strom firmy:

• Generální ředitel (root)
  • Finanční ředitel
    • Účetní oddělení
    • Controlling
  • Technický ředitel
    • Vývoj
    • Testování

Taková struktura je pro hierarchický model ideální: rychle se načítá větev "Technický ředitel" včetně všech podřízených oddělení.

Závěr

Hierarchický model byl jedním z prvních přístupů k organizaci dat v databázových systémech a je stále užitečný tam, kde dominují stromové vztahy. Pro složitější vztahy a flexibilitu však dnes častěji volíme jiné modely (relační, dokumentové nebo grafové). Nicméně dědictví hierarchického modelu (např. v XML/LDAP a v registrech systémů) zůstává významné.