I en hierarkisk databasemodel organiseres data som et træ: poster er ordnet i forældre/barn-relationer. Hver forælder kan have mange børn, men hvert barn har kun én direkte forælder. Alle attributter for en bestemt post grupperes under en entitetstype (svarende til en tabel i andre modeller), og relationerne mellem entitetstyper realiseres som 1:N (en-til-mange) mappinger.

I praksis svarer en entitetstype i den hierarkiske model til en tabel i relationelle systemer: hver post er en række, og hver attribut er en kolonne. Forskellen er, at relationerne er indlejrede og peges på via forældre–barn-links frem for via fremmednøgler og joins. De mest anerkendte og anvendte hierarkiske databaser er IMS udviklet af IBM og Windows Registry fra Microsoft.

Struktur og navigation

Modellen har typisk en enkelt rod (root) og en entydig sti ned til hver post. Navigation foregår ved at følge pointere fra forældre til børn (og i nogle implementeringer også tilbage til forældre). Dette gør det effektivt at hente hele undertræer eller følge hierarkiske stier, men mindre velegnet til vilkårlige krydsrelationer mellem poster.

  • Rod: øverste node (f.eks. virksomhed)
  • Forældre: en node der har én eller flere underordnede noder
  • Barn: en underordnet node med præcis én direkte forælder

Eksempel

Et typisk eksempel er organisationsstrukturen:

  • Virksomhed
    • Afdeling A
      • Medarbejder 1
      • Medarbejder 2
    • Afdeling B
      • Medarbejder 3

I dette eksempel er relationen mellem afdeling og medarbejder en 1:N-relation: én afdeling — mange medarbejdere. I en ren hierarkisk model kan en medarbejder kun være knyttet til én afdeling.

Fordele

  • Ydeevne ved hierarkiske forespørgsler: Hurtig adgang til data, der ligger i samme undertræ (f.eks. hente alle medarbejdere i en afdeling).
  • Enkel struktur: Let at forstå og visualisere som træer.
  • Effektiv lagring af indlejrede data: God til konfigurationsdata og systemregistre (fx Windows Registry).

Begrænsninger

  • Stiv relationsmodel: Vanskeligt at repræsentere mange-til-mange-relationer uden duplikation eller ekstra strukturer.
  • Redundans: Gentagelse af data kan være nødvendig, hvilket øger risiko for inkonsistens.
  • Skemaforandringer: Ændringer i hierarkiet kan være komplicerede og dyre at implementere i store træer.
  • Begrænset forespørgselssprog: Mange hierarkiske systemer mangler standardiserede, deklarative query-sprog som SQL; navigation er ofte procedurebaseret.

Sammenligning med andre modeller

Modellen adskiller sig fra:

  • Netværksmodellen: Tillader mere komplekse, mange-til-mange-forbindelser ved hjælp af sætningssæt og krydspejlinger.
  • Relationelle databaser: Bruger tabeller og joins, hvilket giver stor fleksibilitet til at udtrykke komplekse relationer uden fysisk duplikation.
  • Dokument- og hierarkiske formater (f.eks. JSON, XML, DOM): Disse er konceptuelt tætte på den hierarkiske model og egner sig godt til indlejrede data, men tilbyder typisk mere fleksibilitet i praksis.

Anvendelsestilfælde

  • Systemregistre og konfigurationsdata (fx Windows Registry).
  • Store, faste hierarkier som organisationsstrukturer eller kataloger.
  • Applikationer der kræver hurtig adgang til hele undertræer uden komplekse krydsforespørgsler.

Praktiske bemærkninger

Når du vurderer at bruge en hierarkisk database, overvej om dine data naturligt passer til en enkelt forælderstruktur, og om de fleste forespørgsler er hierarkiske (fx hente underordnede eller hele grene). Hvis dine data ofte kræver mange-til-mange-relationer eller fleksible krydsjoins, er en relationel eller netværksbaseret tilgang ofte mere hensigtsmæssig.

Historisk har hierarkiske systemer som IMS været udbredte i store transaktionssystemer, og elementer af hierarkisk arkitektur findes stadig i moderne teknologier (f.eks. dokumentdatabaser, konfigurationsregistre og filsystemer).