docs: add obsidian hwr docs

Datenbanken/Zusammenfassungen/j_AndereDB - zusammenfassung.md

@@ -0,0 +1,199 @@
+# 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**.