Kapitel 1+2

Datenbank Implementierungstechniken.md

@@ -1,21 +1,610 @@
 # Motivation und Grundlagen
+## Aufgaben und Komponenten eines DBMS
+Prinzipien: Die neun Codd’schen Regeln
+1. Integration: einheitliche, nichtredundante Datenverwaltung
+2. Operationen: Speichern, Suchen, Ändern
+3. Katalog: Zugriffe auf Datenbankbeschreibungen im Data Dictionary
+4. Benutzersichten
+5. Integritätssicherung: Korrektheit des Datenbankinhalts
+6. Datenschutz: Ausschluss unauthorisierter Zugriffe
+7. Transaktionen: mehrere DB-Operationen als Funktionseinheit
+8. Synchronisation: parallele Transaktionen koordinieren
+9. Datensicherung: Wiederherstellung von Daten nach Systemfehlern
+
+Betrachtete Fragestellung
+![](Assets/DBimpl-ebenen.png)
+
+**Zentrale Komponenten**
+- **Anfrageverarbeitung** : Planung, Optimierung und Ausführung deklarativer Anfragen
+- **Transaktionsverwaltung** : Koordination und Synchronisation von Transaktionen, Durchführung von Änderungen, Sicherung der ACID-Eigenschaften
+- **Speichersystem** : Organisation der Daten im Hauptspeicher und auf dem Externspeicher für effizienten Zugriff und Persistenz
+
+## Relationale vs. nicht-relationale DBMS
+**Relationale DBMS**
+- Basis: **Relationenmodell** = Daten in Tabellen strukturiert
+- Beziehungen über Werte (= Fremdschlüssel),
+    Integritätsbedingungen
+- **SQL** als standardisierte Anfragesprache
+- kommerziell erfolgreichstes Datenmodell: Oracle, IBM DB2,
+    MS SQL Server, SAP HANA, ...
+
+| WEINE | WeinID            | Name | Farbe | Jahrgang    | Weingut |
+| ----- | ----------------- | ---- | ----- | ----------- | ------- |
+| 1042  | La Rose Grand Cru | Rot  | 1998  | Château ... |
+| 2168  | Creek Shiraz      | Rot  | 2003  | Creek       |
+| 3456  | Zinfandel         | Rot  | 2004  | Helena      |
+| 2171  | Pinot Noir        | Rot  | 2001  | Creek       |
+| 3478  | Pinot Noir        | Rot  | 1999  | Helena      |
+| 4711  | Riesling Reserve  | Weiß | 1999  | Müller      |
+| 4961  | Chardonnay        | Weiß | 2002  | Bighorn     |
+
+**Kritik an RDBMS / SQL**
+- nicht skalierbar
+    - Normalisierung von Relationen, viele Integritätsbedingungen zu prüfen
+    - kann man in RDBMS auch vermeiden!
+- starre Tabellen nicht flexibel genug
+    - schwach typisierte Tabellen (Tupel weichen in den tatsächlich genutzten Attributen ab)
+          - viele Nullwerte wenn alle potentiellen Attribute definiert
+          - alternativ Aufspaltung auf viele Tabellen
+          - Schema-Evolution mit **alter table** unflexibel
+    - tatsächlich in vielen Anwendungen ein Problem
+- Integration von spezifischen Operationen (Graphtraversierung, Datenanalyse-Primitive) mit Stored Procedures zwar möglich führt aber oft zu schwer interpretierbarem Code
+
+**NoSQL-Systeme**
+- Datenmodelle
+    - KV-Stores
+    - Wide Column Stores
+    - Dokumenten-orientierte Datenhaltung
+    - Graph-Speicher
+    - ...
+- Anfragesprache -> unterschiedliche Ansätze:
+    - einfache funktionale API
+    - Programmiermodell für parallele Funktionen
+    - angelehnt an SQL-Syntax
+    - ...
+- Beispiele
+  - dokumentenorientierte Datenbanksysteme: MongoDB
+      - semistrukturierte Dokumente in JSON- bzw. BSON-Format
+      - Anfragen: CRUD erweitert um dokumentspezifische Suche
+  - Graph-Datenbanksysteme: Neo4j
+      - Property Graphen als Datenmodell: Knoten und Kanten mit Eigenschaften
+      - Anfragesprache Cypher
+      - Muster der Form "Knoten -> Kante -> Knoten ..."
+
+## OLTP, OLAP und HTAP
+### OLTP vs OLAP
+|                            | Online Transactional Processing (OLTP)                                            | Online Analytical Processing (OLAP)                          |
+| -------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------ |
+|                            | -> Klassische operative Informationssysteme                                       | -> Data Warehouse                                            |
+|                            | Erfassung und Verwaltung von Daten                                                | Analyse im Mittelpunkt = entscheidungsunterstützende Systeme |
+|                            | Verarbeitung unter Verantwortung der jeweiligen Abteilung                         | Langandauernde Lesetransaktionen auf vielen Datensätzen      |
+|                            | Transaktionale Verarbeitung: kurze Lese-/ Schreibzugriffe auf wenigen Datensätzen | Integration, Konsolidierung und Aggregation der Daten        |
+|                            | ACID-Eigenschaften                                                                |                                                              |
+|                            |                                                                                   |
+| **Anfragen**               |                                                                                   |
+| Fokus                      | Lesen, Schreiben, Modifizieren, Löschen                                           | Lesen, periodisches Hinzufügen                               |
+| Transaktionsdauer und -typ | kurze Lese- / Schreibtransaktionen                                                | langandauernde Lesetransaktionen                             |
+| Anfragestruktur            | einfach strukturiert                                                              | komplex                                                      |
+| Datenvolumen einer Anfrage | wenige Datensätze                                                                 | viele Datensätze                                             |
+| Datenmodell                | anfrageflexibel                                                                   | analysebezogen                                               |
+| Antwortzeit                | msecs ...secs                                                                     | secs ...min                                                  |
+|                            |                                                                                   |
+| **Daten**                  |                                                                                   |
+| Datenquellen               | meist eine                                                                        | mehrere                                                      |
+| Eigenschaften              | nicht abgeleitet, zeitaktuell, autonom, dynamisch                                 | abgeleitet / konsolidiert, historisiert, integriert, stabil  |
+| Datenvolumen               | MByte ...GByte                                                                    | GByte ...TByte ...PByte                                      |
+| Zugriffe                   | Einzeltupelzugriff                                                                | Tabellenzugriff (spaltenweise)                               |
+
+**OLTP: Beispiel**
+```sql
+BEGIN ;
+SELECT KundenNr INTO KNr
+FROM Kunden WHERE email = '...';
+INSERT INTO BESTELLUNG VALUES (KNr, BestNr, 1);
+UPDATE Artikel SET Bestand = Bestand-1
+WHERE ArtNr = BestNr;
+COMMIT TRANSACTION ;
+```
+
+**OLAP: Beispiel**
+```sql
+SELECT DISTINCT ROW Zeit.Dimension AS Jahr,
+    Produkt.Dimension AS Artikel,
+    AVG(Fact.Umsatz) AS Umsatzdurchschnitt,
+    Ort.Dimension AS Verkaufsgebiet
+FROM (Produktgruppe INNER JOIN Produkt ON Produktgruppe.
+    [Gruppen-Nr] = Produkt.[Gruppen-ID]) INNER JOIN
+    ((((Produkt INNER JOIN [Fact.Umsatz] ON Produkt.[Artikel-Nr]
+    = [Fact.Umsatz].[Artikel-Nr]) INNER JOIN Order ON
+    [Fact.Umsatz].[Bestell-Nr]= Order.[Order-ID]) INNER JOIN
+    Zeit.Dimension ON Orders.[Order-ID] =
+    Zeit.Dimension.[Order-ID]) INNER JOIN Ort.Dimension ON
+    Order.[Order-ID] = Ort.Dimension.[Order-ID]) ON
+    Produktgruppe.[Gruppen-Nr] = Produkt.[Gruppen-ID]
+GROUP BY Produkt.Dimension.Gruppenname, Ort.Dimension.Bundesland,
+Zeit.Dimension.Jahr;
+```
+
+### HTAP
+- HTAP = Hybrid Transactional and Analytics Processing
+- Ziel: schnellere Geschäftsentscheidungen durch "Echtzeit"-Verarbeitung
+- OLAP und OLTP auf der gleichen Datenbank: naheliegend aber große technische Herausforderung
+    - sehr unterschiedliche Workloads (Anfrage- und Lastprofile)
+    - Transaktionsverwaltung: gegenseitige Beeinflussung von Änderungs- und Leseoperationen reduzieren
+    - unterschiedliche Datenorganisation (physisch, logisch)
+- Herausforderungen
+  - Analytical (OLAP) und Transactional processing (OLTP)
+    - verschiedene Zugriffscharakterisiken
+    - verschiedene Performance-Ziele (Latenz vs. Durchsatz)
+  - => Unterschiedliche Optimierungen notwendig
+
+## Disk- vs. Main-Memory-Systeme**
+**Traditionelle Annahmen**
+- Daten sollen dauerhauft aufbewahrt werden
+- Datenbank >> Hauptspeicher
+- Disk >> Hauptspeicher
+- Hauptspeicher = flüchtiger (volatiler) Speicher
+- Disk-IO dominiert Kosten
+
+**Speicherhierarchie**
+![](Assets/DBimpl-speicherhierarchie.png)
+
+**Eigenschaften von Speichermedien**
+|                 | Primär   | Sekundär  | Tertiär      |
+| --------------- | -------- | --------- | ------------ |
+| Geschwindigkeit | schnell  | langsam   | sehr langsam |
+| Preis           | teuer    | preiswert | billig       |
+| Stabilität      | flüchtig | stabil    | stabil       |
+| Größe           | klein    | groß      | sehr groß    |
+| Granulate       | fein     | grob      | grob         |
+
+**Speichermedien**
+- **Primärspeicher**
+    - Primärspeicher: Cache und Hauptspeicher
+    - sehr schnell, Zugriff auf Daten fein granular: theoretisch jedes Byte adressierbar (Cachelines)
+- **Sekundärspeicher**
+    - Sekundärspeicher oder Online-Speicher
+    - meist Plattenspeicher, nicht-flüchtig
+    - Granularität des Zugriffs gröber: Blöcke, oft 512 Bytes
+    - Zugriffslücke: Faktor 10^5 langsamerer Zugriff
+- **Tertiärspeicher**
+    - Zur langfristigen Datensicherung (Archivierung) oder kurzfristigen Protokollierung (Journale)
+    - üblich: optische Platten, Magnetbänder
+    - "Offline-Speicher" meist Wechselmedium
+    - Nachteil: Zugriffslücke extrem groß
+
+
+**Transferraten HDD vs. SSD**
+![](Assets/DBimpl-Transferrate.png)
+
+**Konsequenz für disk-basierte Systeme**
+- blockbasierter Zugriff mit typischen Blockgrößen ≥ 4 KB
+- speziell für Magnetplatten Optimierung auf sequentielle Zugriffe
+       - Disklayout: Organisation der Daten auf der Disk = fortlaufende Folge von Blöcken
+       - sequentielles Lesen und Schreiben
+- Zugriffslücke zwischen Hauptspeicher und Disk durch Caching verbergen (Lokalität von Zugriffen ausnutzen)
+
+**Main-Memory-Datenbanken**
+- klassische Annahmen nicht mehr zutreffend:
+    - Systeme mit Hauptspeicher im TB-Bereich verfügbar
+    - Datenbank kann komplett im Hauptspeicher gehalten werden (muss aber dennoch persistent sein)
+- **Main-Memory-** oder **Hauptspeicher-** Datenbanken: Ausnutzung der großen Hauptspeicher und Multicore-Architekturen
+       - Beispiele: SAP HANA, Oracle TimesTen, SQL Server Hekaton, Hyper, MemSQL, ...
+       - Besonderheiten: hauptspeicheroptimierte Datenstrukturen (Main-Memory-Scans), Persistenz trotz volatilem Speicher, Datenkompression, Nebenläufigkeitskontrolle
+
+
+## Klassische 5-Schichtenarchitektur
+**Fünf-Schichtenarchitektur**
+- Architektur für klassische DBMS
+- basierend auf Idee von Senko 1973
+- Weiterentwicklung von Härder 1987
+- Umsetzung im Rahmen des IBM-Prototyps _System R_
+- genauere Beschreibung der Transformationskomponenten
+    - schrittweise Transformation von Anfragen/Änderungen bis hin zu Zugriffen auf Speichermedien
+    - Definition der Schnittstellen zwischen Komponenten
+
+**5-Schichtenarchitektur: Funktionen**
+![](Assets/DBimpl-5-schichten-funktionen.png)
+
+**5-Schichtenarchitektur: Objekte**
+![](Assets/DBimpl-5-schichten-objekte.png)
+
+Erläuterungen
+- mengenorientierte Schnittstelle **MOS** :
+    - deklarative Datenmanipulationssprache auf Tabellen und Sichten (etwa SQL)
+- durch Datensystem auf satzorientierte Schnittstelle **SOS** umgesetzt:
+       - navigierender Zugriff auf interner Darstellung der Relationen
+       - manipulierte Objekte: typisierte Datensätze und interne Relationen sowie logische Zugriffspfade (Indexe)
+       - Aufgaben des Datensystems: Übersetzung und Optimierung von SQL-Anfragen
+- durch Zugriffssystem auf interne Satzschnittstelle **ISS** umgesetzt:
+       - interne Tupel einheitlich verwalten, ohne Typisierung
+       - Speicherstrukturen der Zugriffspfade (konkrete Operationen auf B+-Bäumen und Hashtabellen), Mehrbenutzerbetrieb mit Transaktionen
+- durch Speichersystem Datenstrukturen und Operationen der ISS auf interne Seiten eines virtuellen linearen Adressraums umsetzen
+       - Manipulation des Adressraums durch Operationen der Systempufferschnittstelle **SPS**
+       - Typische Objekte: interne Seiten, Seitenadressen
+       - Typische Operationen: Freigeben und Bereitstellen von Seiten, Seitenwechselstrategien, Sperrverwaltung, Schreiben des Logs
+- durch Pufferverwaltung interne Seiten auf Blöcke der Dateischnittstelle **DS** abbilden
+       - Umsetzung der DS-Operationen auf Geräteschnittstelle erfolgt durch BS
+
+## Neue Entwicklungen
+Anforderungen aus neuen Anwendungen
+- Nicht-Standard-Datenmodelle (siehe NoSQL-Systeme)
+- flexibler Umgang mit Datenstrukturen (JSON, Schema on Read, ...)
+- beschränkte (Lookups) vs. erweiterte (z.B. Graphoperationen, Datenanalysen) Anfragefunktionalität
+- Skalierbarkeit zu Big Data (massiv parallele/verteilte Systeme)
+- dynamische Daten / Datenströme
+- ...
+
+**Entwicklungen im Hardware-Bereich**
+- Multicore- und Manycore-Prozessoren: 64+ Cores
+    - Nutzung erfordert Parallelisierungstechniken und Nebenläufigkeitskontrolle
+- Memory Wall: Hauptspeicherzugriff als Flaschenhals
+    - RAM-Zugriff 60 ns, L1-Cache: 4 CPU-Zyklen -> Cache-optimierte Strukturen
+- Datenbank-Accelerators
+    - Hardware-unterstütztes Datenmanagement: FPGA, GPU als Coprozessoren, Highspeed-Netzwerk, SSDs als zusätzliche Cache-Ebene, ...
+- Persistenter Memory: nicht-volatiler Speicher
+    - Instant Restart / Recovery von Main-Memory-Datenbanken
+
+**Zusammenfassung**
+- Datenmanagementfunktionalitäten in vielen Softwaresystemen erforderlich
+- nicht auf Implementierung kompletter DBMS beschränkt, sondern für nahezu alle datenintensiven Systeme: auch in Suchmaschinen, Datenanalyseanwendungen, eingebetteten Systemen, Visualisierungssystemen, Steuerungssystemen, Entwicklungsumgebungen, ...
+- gemeinsame Aufgaben / Komponenten: Datenorganisation und -verwaltung (Indexstrukturen), Transaktionsverwaltung / Nebenläufigkeitskontrolle / Recovery, Anfrageverarbeitung
+- betrifft Datenstrukturen und Algorithmen
 
 # Speicherstrukturen für Datenbanken
+## Speicher- und Sicherungsmedien
+Speichermedien
+- verschiedene Zwecke:
+    - Daten zur Verarbeitung bereitstellen
+    - Daten langfristig speichern (und trotzdem schnell verfügbar halten)
+    - Daten sehr langfristig und preiswert archivieren unter Inkaufnahme etwas längerer Zugriffszeiten
+- Speicherhierarchie:
+    1. Extrem schneller Prozessor mit Registern
+    2. Sehr schneller Cache-Speicher
+    3. Schneller Hauptspeicher
+    4. Langsamer Sekundärspeicher mit wahlfreiem Zugriff
+    5. Sehr langsamer Nearline-Tertiärspeicher bei dem die Speichermedien automatisch bereitgestellt werden
+    6. Extrem langsamer Offline-Tertiärspeicher, bei dem die Speichermedien per Hand bereitgestellt werden
+
+Zugriffslücke in Zahlen
+- Zugriffslücke: Unterschiede in den Zugriffsgeschwindigkeiten auf den verschiedenen Speicherebenen
+
+| Speicherart              | Zugriffszeit | CPU cycles | typische Kapazität         |
+| ------------------------ | ------------ | ---------- | -------------------------- |
+| CacheSpeicher            | 6 ns         | 12         | 256 KB (L2) bis 32 MB (L3) |
+| Hauptspeicher            | 60 ns        | 120        | 1 GB bis 1.5 TB            |
+| Zugriffslücke $10^5$     |              |            |
+| Magnetplattenspeicher    | 8-12 ms      | 16*10^6    | 160 GB bis 4 TB            |
+| Platten-Farm oder -Array | 12 ms        | 24*10^6    | im TB- bis PB-Bereich      |
+
+Typische Merkmale von Sekundärspeicher
+| Merkmal         | Kapazität | Latenz  | Bandbreite           |
+| --------------- | --------- | ------- | -------------------- |
+| 1983            | 30 MB     | 48.3 ms | 0.6 MB/s             |
+| 1994            | 4.3 GB    | 12.7 ms | 9 MB/s               |
+| 2003            | 73.4 GB   | 5.7 ms  | 86 MB/s              |
+| 2009            | 2 TB      | 5.1 ms  | 95 MB/s              |
+| 2019 SSD (NVMe) | 2 TB      | ??      | seq.read 3.500 MB/s  |
+|                 |           | ??      | seq.write 1.600 MB/s |
+
+Solid State Disk (SSD)
+- basierend auf EEPROMs in NAND- oder NOR-Technologie
+- Arrays (=Flash-Block mit ca. 128 KB) von Speicherzellen, entweder ein Bit (SLC) oder 2-4 Bit (MLC)
+- MLC sind langsamer und haben verkürzte Lebensdauer
+- initial ist jedes Bit auf 1 gesetzt, durch Reprogrammieren auf 0
+- Löschen zurück auf 1 nur für ganzen Block
+- Konsequenz: langsames Löschen (Lesen = 25 μs, Löschen = 2 ms), begrenzte Lebensdauer (ca. 100.000    Lösch-Schreib-Zyklen)
+- Schnittstelle: SATA oder PCIe (NVMe)
+
+![](Assets/DBimpl-SSD.png)
+
+SSDs in DBMS
+- klassische, auf sequenzielles Lesen ausgerichtete, Strategien von DBMS nutzen die Stärken von Flash-Speicher nicht aus
+- kleinere Blockgrößen lassen sich effizient adressieren, sollten aber ein Vielfaches der Flash-Seiten sein
+- wahlfreie Lesezugriffe sind effizienter als auf Magnetplatten, sollten aber auf Größen von ca. 4 bis 16 MB begrenzt werden
+- konkurrierende IO-Zugriffe sind bis zu einem gewissen Maße ohne negativen Performanzeinfluss durchführbar
+
+**Speicherarrays: RAID**
+- Kopplung billiger Standardplatten unter einem speziellen Controller zu einem einzigen logischen Laufwerk
+- Verteilung der Daten auf die verschiedenen physischen Festplatten übernimmt Controller
+- zwei gegensätzliche Ziele:
+    - Erhöhung der Fehlertoleranz (Ausfallsicherheit, Zuverlässigkeit) durch Redundanz
+    - Effizienzsteigerung durch Parallelität des Zugriffs
+
+Erhöhung der Fehlertoleranz
+- Nutzung zusätzlicher Platten zur Speicherung von Duplikaten (Spiegeln) der eigentlichen Daten => bei Fehler: Umschalten auf Spiegelplatte
+- bestimmte RAID-Levels (1, 0+1) erlauben eine solche Spiegelung
+- Alternative: Kontrollinformationen wie Paritätsbits nicht im selben Sektor wie die Originaldaten, sondern auf einer anderen Platte speichern
+- RAID-Levels 2 bis 6 stellen durch Paritätsbits oder Error Correcting Codes (ECC) fehlerhafte Daten wieder her
+- ein Paritätsbit kann einen Plattenfehler entdecken und bei Kenntnis der fehlerhaften Platte korrigieren
+
+Erhöhung der Effizienz
+- Datenbank auf mehrere Platten verteilen, die parallel angesteuert werden können => Zugriffszeit auf große Datenmengen verringert sich fast linear mit der Anzahl der verfügbaren Platten
+- Verteilung: bit-, byte- oder blockweise
+- höhere RAID-Levels (ab Level 3) verbinden Fehlerkorrektur und block- oder bitweises Verteilen von Daten
+- Unterschiede:
+    - schnellerer Zugriff auf bestimmte Daten
+    - höherer Durchsatz für viele parallel anstehende Transaktionen durch eine Lastbalancierung des Gesamtsystems
+
+
+RAID-Levels
+![](Assets/DBimpl-Raid-level-1.png)
+![](Assets/DBimpl-Raid-level-2.png)
+
+| Level | Striping blockweise | Striping bitweise | Kopie | Parität | Parität dedizierte Platte | Parität verteilt | Erkennen mehrerer Fehler |
+| ----- | ------------------- | ----------------- | ----- | ------- | ------------------------- | ---------------- | ------------------------ |
+| 0     | √                   |
+| 1     |                     |                   | √     |
+| 0+1   | √                   |                   | √     |
+| 2     |                     | √                 |       | √       |
+| 3     |                     | √                 |       | √       | √                         |
+| 4     | √                   |                   |       | √       | √                         |
+| 5     | √                   |                   |       | √       |                           | √                |
+| 6     | √                   |                   |       | √       |                           |                  | √                        |
+
+**Sicherungsmedien: Tertiärspeicher**
+- weniger oft benutzte Teile der Datenbank, die eventuell sehr großen Umfang haben (Text, Multimedia) "billiger" speichern als auf Magnetplatten
+- aktuell benutzte Datenbestände zusätzlich sichern (archivieren)
+- Tertiärspeicher: Medium austauschbar
+    - offline: Medien manuell wechseln (optische Platten, Bänder)
+    - nearline: Medien automatisch wechseln (_Jukeboxes_, _Bandroboter_)
+
+Langzeitarchivierung
+- Lebensdauer, Teilaspekte:
+- physische Haltbarkeit des Mediums garantiert die Unversehrtheit der Daten: 
+  - 10 Jahre für Magnetbänder, 
+  - 30 Jahre für optische Platten, 
+  - Papier???
+- Vorhandensein von Geräten und Treibern garantiert die Lesbarkeit von Daten: 
+  - Geräte für Lochkarten oder 8-Zoll-Disketten?
+- zur Verfügung stehende Metadaten garantieren die Interpretierbarkeit von Daten
+- Vorhandensein von Programmen, die auf den Daten arbeiten können, garantieren die Wiederverwendbarkeit von Daten
+
+
+## Struktur des Hintergrundspeichers
+Verwaltung des Hintergrundspeichers
+- Abstraktion von Speicherungs- oder Sicherungsmediums
+- Modell: Folge von Blöcken
+    ![](Assets/DBimpl-5-schichten-funktionen.png)
+- Alternativen:
+    - jede Relation oder jeder Zugriffspfad in genau einer Betriebssystem-Datei
+    - ein oder mehrere BS-Dateien, DBS verwaltet Relationen und Zugriffspfade selbst innerhalb dieser Dateien
+    - DBS steuert selbst Magnetplatte an und arbeitet mit den Blöcken in ihrer Ursprungsform ( _raw device_ )
+- Warum nicht immer BS-Dateiverwaltung?
+    - Betriebssystemunabhängigkeit
+    - In 32-Bit-Betriebssystemen: Dateigröße 4 GB maximal
+    - BS-Dateien auf maximal einem Medium
+    - betriebssystemseitige Pufferverwaltung von Blöcken des Sekundärspeichers im Hauptspeicher genügt nicht den Anforderungen des Datenbanksystems
+
+Blöcke und Seiten
+- Zuordnung der physischen Blöcke zu Seiten
+- meist mit festen Faktoren: 1, 2, 4 oder 8 Blöcke einer Spur auf eine Seite
+- hier: "ein Block — eine Seite"
+- höhere Schichten des DBS adressieren über Seitennummer
+
+Dienste des Dateisystems
+- Allokation oder Deallokation von Speicherplatz
+- Holen oder Speichern von Seiteninhalten
+- Allokation möglichst so, dass logisch aufeinanderfolgende Datenbereiche (etwa einer Relation) auch möglichst in aufeinanderfolgenden Blöcken der Platte gespeichert werden
+- Nach vielen Update-Operationen: Reorganisationsmethoden
+- Freispeicherverwaltung: doppelt verkettete Liste von Seiten
+
+Abbildung der Datenstrukturen
+- Abbildung der konzeptuellen Ebene auf interne Datenstrukturen
+- Unterstützung durch Metadaten (im Data Dictionary, etwa das interne Schema)
+
+| Konz. Ebene      | Interne Ebene   | Dateisystem/Platte |
+| ---------------- | --------------- | ------------------ |
+| Relationen ->    | Log. Dateien -> | Phys. Dateien      |
+| Tupel ->         | Datensätze ->   | Seiten/Blöcke      |
+| Attributwerte -> | Felder ->       | Bytes              |
+
+- Beispiel: jede Relation in je einer logischen Datei, diese insgesamt in einer einzigen physischen Datei
+
+
+## Seiten, Sätze und Adressierung
+### Seite
+- Block:
+    - kleinste adressierbare Einheit auf Externspeicher
+    - Zuordnung zu Seiten im Hauptspeicher
+- Aufbau von Seiten
+    - Header
+       - Informationen über Vorgänger- und Nachfolger-Seite
+       - eventuell auch Nummer der Seite selbst
+       - Informationen über Typ der Sätze
+       - freier Platz
+    - Datensätze
+    - unbelegte Bytes
+
+Seitenorganisation
+- Organisation der Seiten: doppelt verkettete Liste
+- freie Seiten in Freispeicherverwaltung
+![](Assets/DBimpl-seitenorganisation.png)
+
+Seite: Adressierung der Datensätze
+- adressierbare Einheiten
+    - Zylinder
+    - Spuren
+    - Sektoren
+    - Blöcke oder Seiten
+    - Datensätze in Blöcken oder Seiten
+    - Datenfelder in Datensätzen
+- Beispiel: Adresse eines Satzes durch Seitennummer und Offset (relative Adresse in Bytes vom Seitenanfang)
+
+Seitenzugriff als Flaschenhals
+- Maß für die Geschwindigkeit von Datenbankoperationen: Anzahl der Seitenzugriffe auf dem Sekundärspeicher (wegen Zugriffslücke)
+- Faustregel: Geschwindigkeit des Zugriffs ⇐ Qualität des Zugriffspfades ⇐ Anzahl der benötigten Seitenzugriffe
+- Hauptspeicheroperationen nicht beliebig vernachlässigbar
+
+
+Einpassen von Datensätzen auf Blöcke
+- Datensätze (eventuell variabler Länge) in die aus einer fest vorgegebenen Anzahl von Bytes bestehenden Blöcke einpassen: Blocken
+- Blocken abhängig von variabler oder fester Feldlänge der Datenfelder
+       - Datensätze mit variabler Satzlänge: höherer Verwaltungsaufwand beim Lesen und Schreiben, Satzlänge immer wieder neu ermitteln
+       - Datensätze mit fester Satzlänge: höherer Speicheraufwand
+
+Verschiedene Satztypen
+![](Assets/DBimpl-satztypen.png)
+
+Sätze fester Länge
+- SQL: Datentypen fester und variabler Länge
+    - _char(n)_ Zeichenkette der festen Länge _n_
+    - _varchar(n)_ Zeichenkette variabler Länge mit der Maximallänge _n_
+- Aufbau der Datensätze, falls alle Datenfelder feste Länge:
+    1. Verwaltungsblock mit Typ eines Satzes (wenn unterschiedliche Satztypen auf einer Seite möglich) und Löschbit
+    2. Freiraum zur Justierung des Offset
+    3. Nutzdaten des Datensatzes
+
+Sätze variabler Länge
+- im Verwaltungsblock nötig: Satzlänge _l_, um die Länge des Nutzdaten-Bereichs _d_ zu kennen
+    ![](Assets/DBimpl-variable-länge-1.png)
+- Strategie a)
+    ![](Assets/DBimpl-variable-länge-2.png)
+- Strategie b)
+    ![](Assets/DBimpl-variable-länge-3.png)
+
+Speicherung von Sätzen variabler Länge
+- Strategie a): Jedes Datenfeld variabler Länge $A_i$ beginnt mit einem _Längenzeiger $al_i$, der angibt, wie lang das folgende Datenfeld ist
+- Strategie b): Am Beginn des Satzes wird nach dem Satz-Längenzeiger _l_ und der Anzahl der Attribute ein Zeigerfeld $ap_1 ,..., ap_n$ für alle variabel langen Datenfelder eingerichtet
+- Vorteil Strategie b): leichtere Navigation innerhalb des Satzes (auch für Sätze in Seiten => TID)
+
+Anwendung variabel langer Datenfelder
+- "Wiederholgruppen": Liste von Werten des gleichen Datentyps
+       - Zeichenketten variabler Länge wie _varchar(n)_ sind Wiederholgruppe mit _char_ als Basisdatentyp, mathematisch also die Kleene’sche Hülle $(char)∗$
+       - Mengen- oder listenwertige Attributwerte, die im Datensatz selbst denormalisiert gespeichert werden sollen (Speicherung als geschachtelte Relation oder Cluster-Speicherung), bei einer Liste von _integer_ -Werten wäre dies $(integer)∗$
+       - Adressfeld für eine Indexdatei, die zu einem Attributwert auf mehrere Datensätze zeigt (Sekundärindex), also $(pointer)∗$
+
+Blockungstechniken: Nichtspannsätze
+- jeder Datensatz in maximal einem Block
+    ![](Assets/DBimpl-nichtspannsätze.png)
+- Standardfall (außer bei BLOBs oder CLOBs)
+
+Blockungstechniken: Spannsätze
+- Spannsätze: Datensatz eventuell in mehreren Blöcken
+    ![](Assets/DBimpl-spannsätze.png)
+
+Adressierungstechniken
+![](Assets/Dbimpl-adressierungstechniken.png)
+
+Adressierung: TID-Konzept
+- Tupel-Identifier (TID) ist Datensatz-Adresse bestehend aus Seitennummer und Offset
+- Offset verweist innerhalb der Seite bei einem Offset-Wert von _i_ auf den _i_ -ten Eintrag in einer Liste von Tupelzeigern (Satzverzeichnis), die am Anfang der Seite stehen
+- Jeder Tupel-Zeiger enthält Offsetwert
+- Verschiebung auf der Seite: sämtliche Verweise von außen bleiben unverändert
+- Verschiebungen auf eine andere Seite: statt altem Datensatz neuer TID-Zeiger
+- diese zweistufige Referenz aus Effizienzgründen nicht wünschenswert: Reorganisation in regelmäßigen Abständen
+
+
+TID-Konzept: einstufige Referenz
+![](Assets/DBimpl-tid-einstufig.png)
+
+TID-Konzept: zweistufige Referenz
+![](Assets/DBimpl-tid-zweistufig.png)
+
+## Alternative Speichermodelle
+- bisher klassisches N-äres Speichermodell (NSM), auch "row store"
+- Vorteile:
+    - gesamter Datensatz kann mit einem Seitenzugriff gelesen werden
+    - leichte Änderbarkeit einzelner Attributwerte
+- Nachteil:
+    - werden nur wenige Attributwerte benötigt, müssen trotzdem immer alle Attributwerte gelesen werden -> unnötiger IO-Aufwand
+- Alternativen: spaltenorientierte Speichermodelle
+    - Zerlegung einer _n_ -stelligen Relation in eine Menge von Projektionen (z.B. binäre Relation)
+    - Identifikation (und Rekonstruktion) über eine Schlüsselspalte oder Position
+
+Spaltenorientierte Datenorganisation
+![](Assets/DBimpl-spaltenorientierte-db.png)
+
+Alternative Speichermodelle: DSM
+- Decomposition Storage Model (DSM) -> column stores
+    - alle Werte einer Spalte (Attribut) werden hintereinander gespeichert
+    - Adressierung über Position
+        ![](Assets/DBimpl-dsm.png)
+- Kompression einfach möglich (z.B. Run length encoding)
+- effizientere Scanoperationen (Feldoperationen -> bessere Cache-Nutzung)
+- jedoch: Updateoperationen sind komplexer, Lesen aller Spalten aufwendiger
+- Einsatz bei leseoptimierten Datenbanken
+
+Ein Full-Table-Scan in NSM
+- Im NSM-Modell stehen alle Tupel einer Tabelle sequenziell hintereinander auf einer Datenbankseite.
+  ![](Assets/Dbimpl-full-table-scan-nsm.png)
+
+Ein "Full-Table-Scan" in DSM
+- Im DSM-Modell stehen alle Werte eines Attributs sequenziell hintereinander auf einer Datenbankseite.
+    ![](Assets/DBimpl-full-table-scan-dsm.png)
+- Alle Daten, die für den "l_shipdate Scan" geladen werden sind
+auch dafür relevant.
+
+Alternative Speichermodelle: PAX
+- Partition Attributes Across (PAX) als Kompromiss
+    - NSM: alle Spalten eines Satzes auf der gleichen Seite
+    - DSM: vertikale Partitionierung, Miniseiten für jeweils eine Spalte
+    ![](Assets/DBimpl-PAX.png)
+
+## Main-Memory-Strukturen
+Speicherstrukturen für Main-Memory-Datenbanken
+- Vermeidung der seiten-basierten Indirektion (über Seitenadresse, Puffer)
+- Hauptspeicherzugriffe als neuer Bottleneck ("Memory Wall")
+- Cache-freundliche Datenstruktur: Hauptspeicherzugriffe tatsächlich nicht byteweise, sondern in Cachelines (64 Bytes)
+- Speicherlayout: Row Store vs. Column Store - abhängig vom Workload (Reduzierung der Cache Misses)
+- ggf. Partitionierung für Multicore-Systeme
+- Kompression der Daten zur Reduktion des Speicherbedarfs
+- Persistenz weiterhin notwendig, z.B. über Logging
+- Bsp.: In-Memory-Datenstruktur für relationale Column Stores
+       - pro Spalte = Feld von Attributwerten
+       - Kompression der Attributwerte (siehe Kapitel 8)
+       - ggf. Strukturierung in Segmemten (Chunks) für bessere Speicherverwaltung, NUMA-Effekte
+
+
+## Speicherorganisation in konkreten DBMS
+Oracle: Datenbankstruktur
+    ![](Assets/DBimpl-oracle-dbstruktur.png)
+
+Oracle: Blöcke
+    ![](Assets/Dbimpl-oracle-blöcke.png)
+
+Oracle: Aufbau von Datensätzen
+    ![](Assets/DBimpl-oracle-datensatz.png)
+- Kettadresse für _Row Chaining_ : Verteilung und Verkettung zu großer Datensätze (> 255 Spalten) über mehrere Blöcke
+- row id = (data object identifier, data file identifier, block identifier, row identifier)
+
+Zusammenfassung
+- Speicherhierarchie und Zugriffslücke
+- Speicher- und Sicherungsmedien
+- Hintergrundspeicher: Blockmodell
+- Einpassen von Sätzen in Seiten
+- Satzadressierung: TID-Konzept
 
 # Caching und Pufferverwaltung
+## Aufgaben
+Aufgaben der Pufferverwaltung
+- Puffer: ausgezeichneter Bereich des Hauptspeichers
+- in Pufferrahmen gegliedert, jeder Pufferrahmen kann Seite der Platte aufnehmen
+- Aufgaben:
+    - Pufferverwaltung muss angeforderte Seiten im Puffer suchen => effizienteSuchverfahren
+    - parallele Datenbanktransaktionen: geschickte Speicherzuteilung im Puffer
+    - Puffer gefüllt: adäquate Seitenersetzungsstrategien
+    - Unterschiede zwischen einem Betriebssystem-Puffer und _einem Datenbank-Puffer_
+    - spezielle Anwendung der Pufferverwaltung: Schattenspeicherkonzept
+![](Assets/DBimpl-pufferverwaltung.png)
 
-# Indexierung von Daten
+Mangelnde Eignung des BS-Puffers
+- Natürlicher Verbund von Relationen _A_ und _B_ (zugehörige Folge von Seiten: _Ai_ bzw. _Bj_ )
+- Implementierung: _Nested-Loop_
+    ![](Assets/DBimpl-bs-puffer.png)
+- Ablauf
+    - FIFO: $A_1$ verdrängt, da älteste Seite im Puffer
+    - LRU: $A_1$ verdrängt, da diese Seite nur im ersten Schritt beim Auslesen des ersten Vergleichstupels benötigt wurde
+- Problem
+    - im nächsten Schritt wird das zweite Tupel von $A_1$ benötigt
+    - weiteres "Aufschaukeln": um $A_1$ laden zu können, muss $B_1$ entfernt werden (im nächsten Schritt benötigt) usw.
 
-# Baumbasierte Indexstrukturen
-
-# Hashing
-
-# weitere Indexstrukturen
-
-# Kompression
-
-# Datenbankoperationen
-
-# Grundlagen der Anfragenverarbeitung
-
-# Physische Optimierung
+## Suche von Seiten und Speicherzuteilung
+Suchen einer Seite
+- Direkte Suche:
+    - ohne Hilfsmittel linear im Puffer suchen
+- Indirekte Suche:
+    - Suche nur noch auf einer kleineren Hilfsstruktur
+    - _unsortierte und sortierte Tabelle_ : alle Seiten im Puffer vermerkt
+    - _verkettete Liste_ : schnelleres sortiertes Einfügen möglich
+    - _Hashtabelle_ : bei geschickt gewählter Hashfunktion günstigster Such- und Änderungsaufwand