# Andere Typen von Datenbanken – Zusammenfassung **Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–44** --- ## 1. Hierarchische Datenbanken (Folien 2–14) ### Konzept - Vermutlich die **ältesten Datenbanken**, heute nur noch historische Bedeutung - Bei Bedarf durch relationale Datenbanken simulierbar - Datenbestand: Datensätze mit fester oder variabler Struktur - Semantische Beziehungen sind **fest programmmäßig durch Verweise** implementiert (Vorgänger-Nachfolger-Prinzip) ### Vorteile - Theoretisch sehr schnelle Such-, Einfüge- und Änderungsvorgänge ### Nachteile - **Unflexible baumartige Struktur** - Mit der Zeit werden Zugriffe langsamer (Einfüge-/Löschoperationen) → Baum muss in Gleichgewicht gebracht werden (zeit- und speicheraufwendig) ### Merkmale - Gut geeignet für: **Dateisysteme**, LDAP, Internet-Domänen, Stücklisten - Datensätze können mehr als zwei Verweise enthalten → nicht nur binäre, sondern auch **n-äre Bäume** - Knoten können auf Bäume mit anders strukturierten Datensätzen verweisen (Bäume/Unterbäume = Entitätstypen) - Nicht-hierarchische Beziehungen: durch verkettete Listen implementiert ### IMS von IBM - Älteste, bis heute eingesetzte hierarchische Datenbank - Komponenten: Datenbank, IMS Explorer, IMS SOAP Gateway, IMS Java Connector, IMS Data Provider .NET --- ## 2. Netzartige Datenbanken (Folien 15–17) ### Konzept - Entstehen aus hierarchischen DB durch **Verweisfelder für Rückwärtsbewegung** - **Verallgemeinerung** der hierarchischen Datenbanken - Unterschiedliche Entitätstypen vertreten, Beziehungen durch besondere Art der Datensätze modelliert ### Vorteile - Theoretisch vielfältige Verweise möglich ### Nachteile - Unflexible netzartige Struktur - Modellierung der Beziehungen eingeschränkt - Saubere Trennung der Entitätstypen kaum möglich ### Merkmale - Geeignet für: **geografische Elemente**, Makrostrukturen des Internets - Jeder Knoten kann mehrere Vorgänger und Nachfolger haben - Semantische Darstellung der Beziehungen meist programmiert - Bekannter Vertreter: **UDS** (Universal Datenbank System) von Siemens - Ca. 20 Jahre im Einsatz, dann durch **relationale Datenbanken verdrängt** --- ## 3. Verteilte Datenbanken (Folien 18–25) ### Konzept - **Verbund von mehreren** (meist relationalen) Datenbanken - Zusammenfassung von Informationseinheiten auf **mehreren Knoten** (Computern), über ein Netzwerk verbunden - **Metadaten** (Zugriffsdaten) in einer übergeordneten Datenbank zusammengefasst - Verteilte Transaktionen bestehen aus Teil-Transaktionen in den Komponenten-Datenbanken ### Vorteile - Optimale Darstellung der Unternehmensstruktur durch lokale Datenbestände - Unabhängigkeit der Teil-Datenbanken voneinander - Orts-, Plattform- und Netzwerkunabhängigkeit - Ständiger Betrieb - Effizienz durch parallele Verarbeitung - Transparenz der Anfragen und Anweisungen - Ergebnis- statt Sourcedaten-Transfer ### Nachteile - Vorbereitungsaufwand (Konzepte, Planung, Koordination) - Zusätzliche Administration der Metadaten (Backup/Restore, Konsistenz) - Aufwendige Entwicklung der Abfragen - Abhängigkeit von Lauffähigkeit der einzelnen Teil-Datenbanken ### Entwurf Wie bei konventionellen relationalen DB, plus zusätzliche Schritte: 1. **Fragmentierungsschema** erstellen 2. **Zuordnungsschema** erstellen ### Fragmentierung Relationen werden in disjunkte Fragmente zerlegt: - **Horizontale Zerlegung** – Datensätze nach Kriterien zusammengefasst (z.B. Status='Prof') - **Vertikale Zerlegung** – Attribute zusammengefasst (z.B. Vorname + Nachname) - **Kombinierte Zerlegung** – horizontal + vertikal Anforderungen: - **Vollständigkeit** – Rekonstruktion ergibt vollständige Datenbank - **Disjunktion** – Fragmente überlappen sich nicht ### Zuordnung (Allocation) - Fragmente auf Knoten verteilen (theoretisch redundanzfrei) - Aus Sicherheits-/Leistungsgründen: **Replikation** - Benutzer arbeiten idealerweise nur mit dem Gesamtschema (Transparenz) ### Verteilte Transaktionen - DBMS muss globale Transaktion in **Teil-Transaktionen** zerlegen - Entweder alle erfolgreich oder alle zurückgesetzt - Jede Teil-DB muss **UNDO- und REDO-Funktionalität** beherrschen - **Two-Phase-Commit**: prepare → ready/failed → commit/abort --- ## 4. Objektorientierte Datenbanken (Folien 26–29) ### Konzept - Idee der OO: Daten und Aktionen (Methoden) zusammen bringen → **Kapselung** - Idee der DB: Daten und deren **Beziehungen** modellieren, unabhängig von Aktionen - Diese beiden Ideen sind **schwer zu vereinbaren** ### Eigenschaften - Vorteilhaft bei **Klassenhierarchien** unter Daten - Komplexe Objekte speicher- und abrufbar - **Keine Normalisierung** - Abfragen langsamer als bei relationalen DB - Geringe Kompatibilität zu allgemeinen Anwendungen ### Beispiele - **db4o** – geringe Speichergröße, für Java/.NET, keine SQL-Abfragesprache (QBE wird unterstützt), unterstützt Transaktionen (COMMIT, ROLLBACK) - **Oracle** – objektrelationaler Ansatz: Objekttypen (analog zu Klassen) mit Daten, Funktionen und Prozeduren, instanziierbar in PL/SQL --- ## 5. No-SQL-Datenbanken (Folien 30–43) ### Konzept - **No-SQL = Not only SQL** – betont die Existenz anderer Datenbanken neben relationalen - Relationale DB bleiben wichtig für Anwendungen mit strengen Konsistenz-/Sicherheitsanforderungen ### Gründe für No-SQL - Enorm große Datenvolumen (TiB- und PiB-Bereiche) - Kurze Laufzeiten der Abfragen nötig - Konsistenz nicht vorrangig (Daten meist nur abgefragt) - **Verfügbarkeit vor Konsistenz** (z.B. DNS) - Speicher für relationale DB wird teuer ### Eigenschaften - Einfaches/schwaches/kein Schema - Einfache horizontale und vertikale **Skalierung** (horizontal bevorzugt) - **BASE-Prinzip** statt ACID - Keine Normalformen, keine JOINs, denormalisiert - Hohe Leistung und Verfügbarkeit dank **Replikation** ### BASE vs. ACID | BASE | ACID | |---|---| | **B**asically **A**vailable – Verfügbarkeit ggf. auf Kosten der Konsistenz | **A**tomic – Transaktion ununterbrechbar | | **S**oft State – Konsistenz an Entwickler delegiert | **C**onsistent – konsistenter Zustand gewährleistet | | **E**ventually Consistent – Abfragen auch bei inkonsistentem Zustand | **I**solated – Transaktionen verletzen einander nicht | | | **D**urable – ausgefallene Transaktion gefährdet eigene Daten nicht | ### Vertreter der No-SQL-Datenbanken #### Document-Stores - **Schemafrei**, Daten in Dokumenten mit eindeutiger ID - Keine einheitliche Struktur, verschachtelbar - Felder können verschiedene Datentypen und Arrays haben - Hohe Skalierbarkeit - Beispiele: **MongoDB, CouchDB** (halb-strukturierte Formate: XML, JSON) - Nachteil: keine Normalisierung → Datenredundanz möglich, Konsistenz durch Anwendung #### Key-Value-Stores - Nur **Schlüssel und zugehörige Werte** gespeichert - Einfaches Schema, Schlüssel sortierbar - Werte: Zahlen, Zeichenketten, Listen, Dokumente, Tabellen (nicht einheitlich) - Daten im **Hauptspeicher (In-Memory)** oder auf Datenträger (On-Disc) - Beispiele: **Berkeley DB, Redis, Amazon DynamoDB** - Schnelle einfache Abfragen, aber komplexe Beziehungen schwer zu implementieren #### Wide-Column-Stores - Datensätze haben **unterschiedliche Struktur** (schemafrei) - Milliarden von Feldern pro Datensatz möglich - Feldstruktur: Spaltenname (Schlüssel), Daten, Zeitstempel - **Column Families** für zusammenhängende Spalten - Beispiele: **MS Azure Cosmos DB, Cassandra** - Gut für Big Data Analytics / DWH - Nicht verwechseln mit spaltenorientierten relationalen DB (die haben festes Schema) #### XML-Datenbanken - Daten im **XML-Format** gespeichert - Abfragesprache: **XPath** - Beispiel: **BaseX** - Schnell für ganze Dokumente, langsam bei großen Datenmengen - Fehlende Operationen wie COMMIT, ROLLBACK - Eher **Verarbeitungssysteme für XML-Dokumente** als echte Datenbanken #### Graph-Datenbanken - Daten in drei Klassen: **Knoten, Attribut, Kante** (Graph-Struktur) - Knoten = Tupel (Datensätze), Kanten = Beziehungen - Effektiv für **"wer-kennt-wen"**-Informationen - Nachteile: keine einheitliche Abfragesprache, keine direkten Zugriffe auf Knoten via Attributen ### Fazit Die No-SQL-Datenbanken sind **sehr effektiv in ihrem Spezialgebiet**.