hwr-notes/Datenbanken/Zusammenfassungen/j_AndereDB - zusammenfassung.md

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
Basically Available – Verfügbarkeit ggf. auf Kosten der Konsistenz	Atomic – Transaktion ununterbrechbar
Soft State – Konsistenz an Entwickler delegiert	Consistent – konsistenter Zustand gewährleistet
Eventually Consistent – Abfragen auch bei inkonsistentem Zustand	Isolated – Transaktionen verletzen einander nicht
	Durable – 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.