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 |
|---|---|
| **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**.