theo/hwr-notes

Fork 0

mirror of https://github.com/theoleuthardt/hwr-notes.git synced 2026-06-05 23:41:08 +00:00

theoleuthardt 850aa3455d docs: add obsidian hwr docs

2026-04-09 11:24:56 +02:00

105 KiB

Raw Blame History

Datenbanken – Gesamtzusammenfassung

Dozent: Prof. Dr. Arthur Zimmermann | HWR Berlin | 2026 | Semester 6

Inhaltsverzeichnis

1. Modellierung
2. Modellierung – Fallbeispiel
3. Relationale Algebra
4. SQL
5. Normalformen
6. Transaktionen
7. Speicherstrukturen (Oracle)
- 7.2 Datenträger (Tablespace, Segmente, Redo-Log)
- 7.3 Arbeitsspeicher (SGA, PGA, UGA)
8. Sicherungskonzepte
9. Data Warehouse Konzepte
10. Andere Typen von Datenbanken
11. Gesamtübersicht & Cheat-Sheet

1. Modellierung (b_Modellierung)

1.1 Einführung

Definitionen

Charakteristik der Informationen im Unternehmen:

Informationen bilden Entscheidungsgrundlagen
Informationen können aus unterschiedlichen Quellen stammen
Qualität hängt von Verfügbarkeit, Korrektheit und Vollständigkeit ab
Erhebung, Speichern und Verarbeiten erzeugt Aufwände
Aufgabengebiete sind durch Informationsbeziehungen verknüpft

Aspekte des Datenmanagements:

Architektur (Datenmodellierung)
Datentechnik (Hardware, Installation, Reorganisation, Sicherung)
Administration und Datennutzung

Anforderungen an Datenverwaltung:

Zentrale Verwaltung der Daten
Vermeidung/Einschränkung von Redundanzen
Vermeidung von Inkonsistenzen
Gemeinsame Nutzung durch verschiedene Anwendungen
Datenschutz und Datensicherung
Datenintegrität
Datenunabhängigkeit von Anwendungen

Definitionen:

Daten = Logisch strukturierte Informationseinheiten
Datenbank = Einrichtung für langfristige sichere Aufbewahrung von Daten

Modellierung

Ein Modell ist ein Abbild der realen Welt, das man mit Absicht erstellt, um bestimmte Probleme zu lösen.

Modellbildungsprozess: Reales Problem → Modell → Analyse/Simulation → Theoretische Lösung → Interpretation → Überprüfung → Reale Lösung

Kriterien eines Modells nach Heinrich Hertz:

Richtigkeit — Nicht beweisbar, nur durch Experimente überprüfbar und widerlegbar
Zulässigkeit — Logisch eindeutig formuliert, ohne Widersprüche
Zweckmäßigkeit — Keine überflüssigen Anteile; so einfach wie möglich, so kompliziert wie nötig

Modellierungsansätze: Verschiedene Modellierungssprachen führen zu verschiedenen semantischen Datenmodellen. Praktische Bedeutung haben insbesondere Entity-Relationship-Modellierung (ERM) und UML. Gängige Vorgehensweise: Erst ER-Modell, dann Konvertierung in relationales Modell.

Datenhaltung

Zwei grundsätzliche Formen:

Herkömmliche Form (Dateien): Datenverwaltung in die Anwendung integriert → enormer Entwicklungsaufwand, kaum Datenaustausch
Datenbanken: Datenbank = Datenmanagement + Daten. DBMS übernimmt Speicherung, Aufruf, Änderungen, Sortieren, Sicherungen

Vorteile von Datenbanken gegenüber Dateien:

Reduktion der Entwicklungskosten
Flexible Verarbeitung und Darstellung
Vermeidung von Redundanzen, Inkonsistenzen, Datenverlust
Zugriffskontrolle
Mehrbenutzerbetrieb
Hohe Verfügbarkeit

Dateien statt Datenbanken empfohlen bei:

Sehr kleinen, nicht-kommerziellen Anwendungen
Systemnahen Anwendungen
Verschiedenen Testumgebungen
Groben konzeptuellen Entwicklungen

Architektur

Client/Server-Architektur:

Client nimmt die Ressource in Anspruch (z. B. Darstellung)
Server stellt die Ressource zur Verfügung (z. B. Bearbeitung)

Oracle-Architektur:

SQL-Plus, SQL-Developer, Oracle Instant Client → Listener → Dispatcher → DBMS-Instanzen → Datenbestände
Multi-Tenant-Container und Real Application Cluster (RAC)

SQLite-Architektur (keine Client/Server-Architektur):

DBMS-Instanz direkt in die Anwendung eingebettet
Datenbestand als Dateien im Dateisystem

Datenbankbenutzer

Rolle	Aufgaben
DBA (Datenbankadministrator)	DB-Design, Softwareinstallation/-wartung, Speicherplatzverwaltung, Sicherheitsmechanismen, Backup/Recovery, Reorganisation, Systembeobachtung/Tuning
Anwendungsentwickler	Systemanalyse, SQL, Standard-Abfragen, Anwendungsentwicklung
Endanwender	Benutzung erstellter Programme, vorgefertigte/Ad-Hoc-Abfragen, QBE-Werkzeuge

Entwicklung

1960er Jahre: Jede Anwendung hat eigenes Datenmanagement und eigene Daten
1970er Jahre: Gemeinsames Datenmanagement, aber noch getrennte Datenbestände
Heute: Gemeinsames Datenmanagement und gemeinsame Datenbestände

Zugriff auf Datenbanken erfolgt programmatisch z. B. über JDBC (Java Database Connectivity).

Arten von Datenbanken

Art	Status
Hierarchische Datenbanken	Heute selten verwendet
Netzartige Datenbanken	Heute selten verwendet
Dokumentenbasierte Datenbanken	Selten verwendet (z. B. MongoDB)
Key-Value-Datenbanken	Begrenzte Bedeutung (z. B. BerkeleyDB)
Objektorientierte Datenbanken	Vorhanden
Relationale Datenbanken	Heute fast ausschließlich verwendet

Warum relationale Datenbanken dominieren:

Beziehungen und Entitäten werden gleich dargestellt → derselbe Verarbeitungsmechanismus
Relationale Algebra liefert umfangreiche und fortgeschrittene Operationen
Alle anderen DB-Typen lassen sich damit emulieren

1.2 Codds 12 Regeln

Die 12 Regeln von Codd definieren eine relationale Datenbank:

Vollständige Verwaltung über relationale Fähigkeiten
Darstellung von Informationen: Alle Informationen als Werte in Tabellen
Zugriff auf Daten: Über Tabellenname + Primärschlüssel + Spaltenname
Systematische Behandlung von Nullwerten: Durchgängig gleich als unbekannt/fehlend
Struktur: Systemkatalog auf derselben logischen Ebene wie die Daten
Abfragesprache: Mindestens eine Sprache mit vollständigem Befehlssatz (DDL, DML, Integrität, Autorisierung, Transaktionen)
Aktualisieren von Sichten: Theoretisch aktualisierbare Sichten müssen vom System aktualisierbar sein
Abfragen und Bearbeiten: Unterstützung für Einfügen, Aktualisieren und Löschen ganzer Tabellen
Physikalische Datenunabhängigkeit: Logischer Zugriff unabhängig von physikalischen Methoden
Logische Datenunabhängigkeit: Tabellenstruktur-Änderungen ohne Einfluss auf Anwendungslogik
Unabhängigkeit der Integrität: Integritätsregeln in der DB-Sprache definierbar, nicht umgehbar
Verteilungsunabhängigkeit: Logischer Zugriff unverändert bei verteilten Datenbanken

1.3 Mengenlehre (b_Mengenlehre)

Die Mengenlehre bildet die mathematische Grundlage der Theorie relationaler Datenbanken. Sie wurde von Georg Cantor entwickelt.

Definition (G. Cantor, 1895)

Eine Menge ist die Zusammenfassung von bestimmten wohlunterschiedenen Objekten unserer Anschauung oder unseres Denkens zu einem Ganzen.

Eigenschaften einer Menge

Die Natur der Elemente ist unerheblich
Alle Elemente sind unterschiedlich (keine Duplikate)
Bezeichnung: M = { e₁, e₂, ..., eₙ, ... }, eᵢ ∈ M
Die Reihenfolge der Elemente spielt keine Rolle

Beispiele: Menge aller Computer im Unternehmen · Menge der positiven Zahlen · Menge der Elektronen im Universum

Anzahl der Elemente:

endlich (z. B. Mitarbeiter einer Firma)
unendlich:
- abzählbar (z. B. ℕ, ℤ)
- unabzählbar (z. B. ℝ)

Quantoren

Symbol	Bedeutung
∀	Für alle Elemente (Allquantor)
∃	Es existiert mindestens ein Element (Existenzquantor)

Quantoren werden verwendet, um Aussagen in der Mengenlehre (und generell in der Mathematik) formal zu schreiben.

Operationen über Mengen

Folgende allgemeine Operationen sind über Mengen definiert:

Kartesisches Produkt (Kreuzprodukt)

A × B = { (a, b) | ∀ a ∈ A und ∀ b ∈ B }

Beispiel: A = { +, − }, B = { 1, 2, 3 } → A × B = { (+,1), (−,1), (+,2), (−,2), (+,3), (−,3) } = { +1, −1, +2, −2, +3, −3 }

Kartesisches Produkt mehrerer Mengen:

M₁ × M₂ × ... × Mₙ = { (m₁, m₂, ..., mₙ) | ∀ mᵢ ∈ Mᵢ, ∀ i ∈ [1,...,n] }

Die Elemente heißen n-Tupel:

n = 2: Paar (Dupel)
n = 3: Tripel
n = 4: Quadrupel
n = 5: Quintupel

Vereinigung

A ∪ B = { e | ∀ e, e ∈ A oder e ∈ B }

Zur Vereinigung gehören alle Elemente aus A und alle aus B (keine Verdoppelung der Elemente).

Durchschnitt (Schnittmenge)

A ∩ B = { e | ∀ e, e ∈ A und e ∈ B }

Zum Durchschnitt gehören die Elemente, die gleichzeitig zu A und zu B gehören.

Differenz

A — B = { e | ∀ e, e ∈ A und e ∉ B }

Zur Differenz gehören die Elemente aus A, die zu B nicht gehören.

Zahlenmengen

Symbol	Name	Definition
ℕ	Natürliche Zahlen	= { 0, 1, 2, 3, ... }
ℤ	Ganze Zahlen	= { ..., −3, −2, −1, 0, 1, 2, 3, ... }
ℚ	Rationale Zahlen	= { q \| ∃ x,y ∈ ℤ ⟹ q = x/y }
ℐ	Irrationale Zahlen	= { s \| ∀ x,y ∈ ℤ, y≠0 ⟹ s ≠ x/y }
ℝ	Reelle Zahlen	= ℚ ∪ ℐ
ℂ	Komplexe Zahlen	= { z = a+b×i \| ∀ a,b ∈ ℝ, i×i = −1 }

Inklusionen: ℕ ⊂ ℤ ⊂ ℚ ⊂ ℝ ⊂ ℂ

Operationen auf ganzen Zahlen: Addition, Subtraktion, Multiplikation, ganzzahlige Division (liefert Quotient und Rest – zwei unterschiedliche Operationen)

Operationen auf reellen Zahlen: Addition, Subtraktion, Multiplikation, reelle Division (liefert nur Quotient; kein Rest definiert)

Alle Mengen außer ℂ haben eine natürliche (lineare) Ordnung.

Dimensionen

Gegeben zwei Mengen R₁ und R₂ mit dim(R₁) = k und dim(R₂) = n:

Operation	Dimension des Ergebnisses
R₁ × R₂	k · n
R₁ ∪ R₂	∈ { max{k,n}, ..., k+n }
R₁ ∩ R₂	∈ { 0, 1, ..., min{k,n} }
R₁ — R₂	k − dim{ R₁ ∩ R₂ }

Relevanz für Datenbanken

Eine Relation (Tabelle) ist eine Untermenge des kartesischen Produkts mehrerer Datentypen
Keine Duplikate in Mengen → in relationaler Algebra gibt es keine doppelten Tupel (in SQL daher DISTINCT nötig)
Die Mengenlehre erklärt direkt, warum im Fallbeispiel (Mini-Welt 1) gleiche [RechnPosNr, Menge]-Kombinationen zusammengefasst werden müssen

1.4 ANSI-SPARC-Modell (Drei-Schichten-Architektur)

Das ANSI-SPARC-Modell gewährleistet Unabhängigkeit der Datenbank von Programmiersprache und Hardware:

Ebene	Bezeichnung	Inhalt
Externe Ebene	Anwendungs-Ebene	Benutzeroberflächen, Datensichten, API, Schnittstellen. Jede Sicht zeigt nur einen Teil der Daten
Konzeptionelle Ebene	Logische Ebene	Beziehungen, Daten. Relationales Datenmodell, ERM-Diagramme, Integritätsbedingungen, Zugriffsrechte
Interne Ebene	Physische Ebene	Art und Form der Speicherung. Dateien, Partitionen, Tablespaces, Zugriffsmechanismen

1.5 Phasen des Datenbankentwurfs

Anforderungsanalyse → Spezifikation (Pflichtenheft)
Konzeptueller Entwurf → Konzeptuelles Schema (ERM)
Logischer Entwurf → Logisches Schema (Tabellen)
Physischer Entwurf → Physisches Schema (Datenträger)

1.6 Anforderungsanalyse

Im Laufe der Anforderungsanalyse wird erfasst:

Welche Abteilungen mit der DB arbeiten
Welche Geschäftsprozesse unterstützt werden
Welche Daten involviert werden
Wie die Daten strukturiert sind
Qualitative und quantitative Anforderungen

Schritte nach A. Kemper:

Identifikation von Organisationseinheiten
Identifikation der zu unterstützenden Aufgaben
Anforderungs-Sammelplan (zu befragende Personen)
Anforderungs-Sammlung
Filterung (Verständigkeit und Eindeutigkeit prüfen)
Satzklassifikationen (Objekte, Beziehungen, Operationen, Ereignisse)
Formalisierung/Systematisierung (ins Pflichtenheft übertragen)

Ergebnisse der Anforderungsanalyse:

Informationsanforderungen: Beschreibung von Objekten/Attributen und Beziehungen/Attributen
Datenverarbeitungsanforderungen: Beschreibung von Prozessen

Drei Arten von Beschreibungen:

Objektbeschreibung (z. B. Uni-Angestellte):

Attribut	Typ	Länge	Identifizierend	Beispiel
PersonalNr	Char	10	ja	1234561234
Gehalt	Dezimal	8.2	nein	9000.11
Rang	String	4	nein	W3

Beziehungsbeschreibung (z. B. prüfen):

Beteiligte Objekte: Professor (Prüfer), Student (Prüfling), Vorlesung (Lehrstoff)
Attribute: Datum, Uhrzeit, Note

Prozessbeschreibung (z. B. Zeugnisausstellung):

Häufigkeit, Priorität, benötigte Daten, Datenmenge

1.7 Konzeptueller Entwurf – Entity-Relationship-Modell (ERM)

Auf Basis der Anforderungsanalyse wird ein konzeptuelles ERM erstellt. Das konkrete DBMS wird noch nicht betrachtet.

Modellierungsstrukturen in Peter-Chen-Notation

Element	Grafische Darstellung	Bedeutung
Entitätstypen	Rechteck	Objekte der realen Welt
Beziehungstypen	Raute	Bindungen zwischen Entitäten
Attribute	Oval/Kreis	Charakteristiken von Entitäten und Beziehungen
Funktionalitäten	Beschriftung an Verbindungslinien	Kardinalität der Beziehungen
Schlüssel	Unterstrichene Attribute	Identifizierende Attribute
Rollen	Beschriftung bei rekursiven Beziehungen	Rolle einer Entität in der Beziehung

Entitätstypen

Gegenstände sind Objekte der realen Welt, die zu Gegenstandstypen (Entitätstypen) abstrahiert werden:

"Zimmermann", "Merkel", "Meier" → Mensch
"VW", "Mercedes", "BMW" → Auto

Man arbeitet ausschließlich mit Entitätstypen (abstrakte Klassen), nicht mit einzelnen Instanzen.

Beziehungstypen

Beziehungen drücken Bindungen zwischen Entitäten aus. Nicht alle Entitätstypen müssen verbunden sein, aber ein alleinstehender Entitätstyp ohne Beziehung ist verdächtig.

Attribute

Attributierte Beziehungen: Wenn beide Entitätstypen semantisch gleiche Attribute haben, werden diese dem Beziehungstyp zugeordnet (z. B. Betrag bei "Kredit geben" zwischen Kunde und Bank).

Entscheidung Entitätstyp vs. Attribut:

Wird etwas durch anderes beschrieben → das Beschriebene ist Entitätstyp, das Beschreibende ist Attribut
Kann etwas durch nichts weiteres beschrieben werden → es ist ein Attribut

Attributtypen:

Typ	Beschreibung	Beispiel
Einfach	Ein Wert zu einem Zeitpunkt	Name = "Müller"
Mehrwertig	Mehrere Werte gleichzeitig	Ampel: rot + gelb
Zusammengesetzt	Besteht aus Teilattributen	Adresse: PLZ + Ort + Straße
Abgeleitet	Aus anderen Attributen berechnet	Bruttopreis = Netto × (1 + MwSt)

Schlüssel und Primärschlüssel

Schlüssel: Attributmenge, deren Werte eine Entität eindeutig identifizieren
Schlüsselkandidaten: Mehrere mögliche Schlüssel
Primärschlüssel (PK): Der Kandidat mit minimaler Länge, im ERM unterstrichen
Minimaler Schlüssel: Keine Untermenge des PK bildet selbst einen Schlüssel
Wichtig: Wahl eines anderen PK ändert das gesamte Modell

Rekursive Beziehungen

Beziehungen zwischen Entitäten desselben Entitätstyps. Dabei werden Rollen zugeschrieben.

Beispiele:

Vorlesungen → voraussetzen (Vorgänger/Nachfolger)
Softwareprodukt → Versionsnummer
Polizisten → im Zweierteam patrouillieren

Funktionalitäten

Funktionalität gibt an, wie viele Instanzen in einer Beziehung teilnehmen:

Typ	Beschreibung	Beispiel
1:1	Einer Entität aus E1 entspricht höchstens eine aus E2 (und umgekehrt)	Persönliche Daten ↔ Ansprechdaten
1:N	Einer aus E1 entsprechen mehrere aus E2, aber einer aus E2 höchstens eine aus E1	Schüler → Fahrausweise
N:M	Mehrere aus E1 entsprechen mehreren aus E2	Studenten ↔ Vorlesungen (hören)

Auflösung einer M:N-Beziehung: Wird in zwei 1:N-Beziehungen aufgebrochen durch Einführung eines neuen Entitätstyps (z. B. Hersteller ↔ Lieferant → Hersteller → Herstlr_Liefrnt ← Lieferant).

(min,max)-Notation

Genauere Angabe der Kardinalitäten als Standardfunktionalitäten:

min = 0: Entitäten, die an keiner Beziehung teilnehmen
*max = : Beliebig viele Entitäten

Beispiel Polyeder:

Polyeder (4,*) — Hülle — (1,1) Flächen
Flächen (3,*) — Grenze — (2,2) Kanten
Kanten (2,2) — StartEnde — (3,*) Punkte

Mehrstellige Beziehungen

Ternäre Beziehung: Zwischen 3 Entitätstypen
n-äre Beziehung: Zwischen n Entitätstypen
Sollten möglichst in binäre Beziehungen umgewandelt werden
Beispiel: "prüfen" (Student, Vorlesung, Professor) → neuer Entitätstyp "Prüfungen" mit binären Beziehungen

Spezielle Konzepte

Komposition / Schwache Entitäten (has-a): Existenz eines Entitätstyps ist von der Existenz eines anderen abhängig.

Beispiel: Konto existiert nur in Zusammenhang mit einer Bank

Generalisierung (is-a): Abstraktion auf Ebene der Entitätstypen. Gemeinsame Eigenschaften werden in einen Obertyp ausgelagert, spezifische bleiben bei den Untertypen.

Beispiel: Lebensmittel (gültig bis) und Eisenwaren (Garantiefrist) → Obertyp Produkt (Bezeichnung, Hersteller)

Aggregation (has-a): Verschiedene Entitätstypen bilden in ihrer Gemeinsamkeit einen neuen Entitätstyp.

Beispiel: Fahrrad besteht aus Rahmen (Rohre, Lenker) und Rad (Speiche, Felge)

1.8 Logischer Entwurf – Konvertierung ERM → Tabellen

Definitionen

Datentyp = Werte + Operationen (z. B. integer: +, -, *, /, mod)
Relation = Untermenge des kartesischen Produktes mehrerer Datentypen = Tabelle
Tupel = Zeile (Record, Datensatz)
Feld = Spalte (Attribut, Eigenschaft)
Schema = Namen aller Felder + Datentypen + Länge + Reihenfolge

Vorteile des relationalen Modells:

Entitäten und Beziehungen werden gleich als Tabellen dargestellt
Dieselben algebraischen Operationen für beide
Mathematisch begründet durch E.F. Codd

Notation:

RelationsName = { [ Feld1:Datentyp1, Feld2:Datentyp2, ... ] }

Beispiel: Auto = { [ KFZ:string, Modell:string, Gewicht:real, Baujahr:integer ] } Primärschlüssel wird unterstrichen.

Konvertierungsregeln

Regeln für Entitätstypen:

Neue Tabelle (Entitäts-Tabelle) bilden
Alle Attribute des Entitätstyps inkludieren

Regeln für Beziehungstypen:

Neue Tabelle (Beziehungs-Tabelle) bilden
Primärschlüssel aller verbundenen Entitätstypen inkludieren → bilden i.d.R. den PK der Beziehungstabelle
Attribute des Beziehungstyps inkludieren

Vereinfachung der Darstellungen

1:1-Beziehungen – Zwei Optionen:

Option A: Beide Entitäts-Tabellen zu einer Tabelle zusammenführen + Beziehungsattribute. Vorsicht: Datensätze können zu groß werden
Option B: Beziehungs-Tabelle weglassen, PK einer Entitäts-Tabelle als FK in die andere aufnehmen

1:N-Beziehungen:

Beziehungs-Tabelle weglassen
In die Tabelle auf der N-Seite den PK der Tabelle auf der 1-Seite als Fremdschlüssel (FK) einfügen
Beziehungsattribute ebenfalls in die N-Seiten-Tabelle

Schwache Entitäten:

Eigene Tabelle für schwache Entität
PK der referenzierten (starken) Entität wird Teil des PK der schwachen Entität (Unterschied zu normalen 1:N-Beziehungen, wo der FK nicht Teil des PK wird)

Beispiel: Uni-Schema als Tabellen

Tabelle	Felder
Professoren	PersNr, Name, Rang, Raum
Studenten	MatrNr, Name, Semester
Vorlesungen	VorlNr, Titel, SWS, gelesenVon (FK→Professoren)
Assistenten	PersNr, Name, Fachgebiet, Boss (FK→Professoren)
hören	MatrNr (FK), VorlNr (FK)
voraussetzen	Vorgänger (FK), Nachfolger (FK)
prüfen	MatrNr (FK), VorlNr (FK), PersNr (FK), Note

Wichtige Bemerkung

Keine Felder/PK/FK willkürlich in Tabellen hinzufügen! Nur laut Vereinfachungsregeln.

Ausnahmen:

ERM-bezogene Gründe (z. B. PID, MonsterID)
Auditing/Richtlinien (z. B. "Alle Zeilen müssen fortlaufend nummeriert werden")
Administrative Gründe (z. B. Fusion großer Datenmengen)
Anwendungsbezogene Gründe (z. B. OO-DB pflegen PK selbst)

Kontroverse um künstliche IDs: Einige Autoren empfehlen ausdrücklich künstliche IDs, weil:

PK soll keine semantischen Informationen enthalten
PK darf sich nicht mit der Zeit ändern
PK soll einfach aufgebaut sein (nicht aus mehreren Feldern)

2. Modellierung – Fallbeispiel (b_ModellierungFB)

Überblick

Modellierung einer Rechnung: Beispiel-Rechnungen betrachten → Mini-Welten beschreiben → Konzeptuellen Entwurf erstellen → Logischen Entwurf erstellen → Fazit

Identifizierte Entitätstypen

Artikel:

Artikelnummer (kann fehlen), Beschreibung (immer vorhanden), Einzelpreis (Netto), MwSt-Satz und MwSt-Betrag

Rechnungsposition:

Reihenfolgenummer (kann fehlen, aber wichtig), Menge / Anzahl der Artikel

Rechnung (übergeordnet):

Rechnungsnummer, Datum, Gesamtsumme (abgeleitetes Attribut), MwSt-Betrag der ganzen Rechnung (abgeleitetes Attribut)

Formale Notation:

Rechnung = { [ RgNr, Datum, Gesamtpreis, GesamtMwSt ] }
Artikel = { [ ArtNr, ArtBezeichnung, EP, MwStSatz ] }

Mini-Welt 1

Alle Rechnungen werden durchgehend betrachtet. Gleiche Kombinationen [RechnPosNr, Menge] werden zusammengefasst (laut Mengenlehre nach G. Cantor: keine doppelten Elemente).

Rechnungsposition = { [ RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }

Konzeptueller Entwurf:

Beziehung	Funktionalität
Rechnung — besteht aus — Rechnungsposition	M : N
Rechnungsposition — beinhaltet — Artikel	N : 1

Logischer Entwurf:

Rechnung = { [ RgNr, Datum, Gesamtpreis, GesamtMwSt ] }
Artikel = { [ ArtNr, EP, MwStSatz, ArtBezeichnung ] }
Rechnungsposition = { [ RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
besteht_aus = { [ RgNr, RechnPosNr, Menge ] }
beinhaltet = { [ ArtNr, RechnPosNr, Menge ] }

Vereinfachung (1:N-Beziehung "beinhaltet" auflösen):

Rechnungsposition = { [ ArtNr, RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }

Mini-Welt 2

Alle Rechnungspositionen aus allen Rechnungen werden individuell erfasst, auch wenn [RechnPosNr, Menge] gleich sind. Da Duplikate nach Cantor nicht zulässig sind, wird ein neues Attribut LaufendeNummer (LfndNr) eingeführt.

Konsequenz: Mehr Entitäten im Entitätstyp, mehr Redundanz, aber die Zuordnung jeder Position zu einer Rechnung bleibt erhalten.

Rechnungsposition = { [ LfndNr, RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }

Konzeptueller Entwurf:

Beziehung	Funktionalität
Rechnung — besteht aus — Rechnungsposition	1 : N
Rechnungsposition — beinhaltet — Artikel	N : 1

Logischer Entwurf (nach Vereinfachung beider 1:N-Beziehungen):

Rechnungsposition = { [ ArtNr, RgNr, LfndNr, RechnPosNr, Menge,
                        Zwischensumme, ZwischenMwSt ] }

Hinweis: LfndNr wird nicht für Verknüpfungen (Join-Prädikat) verwendet, hat wenig Semantik, muss aber gepflegt werden.

Vergleich der Mini-Welten

Aspekt	Mini-Welt 1	Mini-Welt 2
Beziehung Rechnung↔Position	M:N	1:N
Duplikate	Keine (zusammengefasst)	Individuell (via LfndNr)
Zuordnung Position→Rechnung	Geht verloren	Bleibt erhalten
Redundanz	Weniger	Mehr
Tabellen nach Vereinfachung	3 + besteht_aus	3 (alles in einer)

Empfehlung: Beide Modelle implementieren und Antwortzeiten bei größerem Datenumfang vergleichen.

3. Relationale Algebra (c_Algebra)

Formale Sprachen für Relationen

Sprache	Beschreibung
Relationale Algebra	Definiert Operationen über Relationen; Ergebnis ist wieder eine Relation (Geschlossenheit). Definiert was man will, nicht wie
Relationenkalkül	Deklarative Beschreibung gewünschter Ergebnisse

Die relationale Algebra bildet die Basis für SQL.

Beispiele Relationenkalkül:

{ k | k ∈ KUNDEN ∧ k.STATUS = "Aktiv" }
{ [a.NAME, f.TITEL] | a∈ACTOR ∧ f∈FILM ∧ a.ID=f.A_ID }

Grundoperatoren (vollständiger Satz)

Operator	Notation	Beschreibung
Selektion	σ_Prädikat(Relation)	Zeilen filtern nach Bedingung
Projektion	π_Attribute(Relation)	Spalten auswählen
Kartesisches Produkt	R1 × R2	Alle Kombinationen von Zeilen
Umbenennung	ρ_Alias(Relation)	Relation oder Attribute umbenennen
Vereinigung	R1 ∪ R2	Tupel aus beiden Relationen zusammenfassen
Differenz	R1 — R2	Tupel aus R1, die nicht in R2 vorkommen

Wichtig: Dieser Satz ist vollständig — alle anderen Operatoren lassen sich durch diese ausdrücken.

Operatoren im Detail

Selektion σ

Filtert Zeilen einer Relation anhand eines Prädikats. Das Prädikat wird für jede Zeile geprüft.

σ_{Semester > 10}(Studenten)
→ Ergebnis: MatrNr 24002 (Xenokrates, 18), MatrNr 25403 (Jonas, 12)

σ_{Name = 'Sokrates'}(Professoren)
→ Ergebnis: PersNr 2125, Sokrates, C4, Raum 226

Projektion π

Wählt bestimmte Spalten aus einer Relation aus.

π_{MatrNr, Name}(Studenten)
→ Ergebnis: Nur MatrNr und Name aller Studenten

π_{Rang}(Professoren)
→ Ergebnis: C3, C4 (Duplikate werden in relationaler Algebra eliminiert!)

Wichtig: In relationaler Algebra gibt es keine Duplikate, in SQL schon (deshalb DISTINCT).

Zusammenhang Algebra ↔ SQL

Relationale Algebra	SQL
π (Projektion)	SELECT
σ (Selektion)	WHERE

Anfrage	Algebra	SQL
Wie heißen die Professoren?	π_{Name}(Professoren)	`SELECT Name FROM Professoren;`
Name des Studenten mit MatrNr 25403?	π_{Name}(σ_{MatrNr=25403}(Studenten))	`SELECT Name FROM Studenten WHERE MatrNr = 25403`
Studenten mit >6 Semestern?	π_{Name,MatrNr}(σ_{Semester>6}(Studenten))	`SELECT Name, MatrNr FROM Studenten WHERE Semester > 6`

Reihenfolge der Operatoren

Grundsätzlich dürfen relationale Operatoren in zusammengesetzten Ausdrücken nicht vertauscht werden!

π_{Name,MatrNr}(σ_{Semester>6}(Studenten))     ← korrekt
σ_{Semester>6}(π_{Name,MatrNr}(Studenten))     ← FALSCH (Semester ist nach Projektion weg!)

Umbenennung ρ

Notwendig wenn:

Relationen gleich benannte Attribute besitzen, die beide in der Abfrage benötigt werden
Eine Relation mehrfach in einer Abfrage vorkommt (rekursive Beziehungen)

Umbenennung ist immer temporär (operatorbezogen).

ρ_{Relation-Alias}(Relation)           ← Relation umbenennen
ρ_{Attribut-Alias ← Attribut}(Relation) ← Attribut umbenennen

Vereinigung ∪

Voraussetzungen (Vereinigungskompatibilität):

Gleiche Anzahl von Attributen
Attribute gleich benannt
Gleichnamige Attribute haben denselben Datentyp

Zum Erfüllen der Kriterien können Projektion und Umbenennung verwendet werden.

Ergebnis: Selbes Schema wie die Operanden, Tupel zusammengefasst, Duplikate eliminiert.

SELECT Name FROM Studenten UNION
SELECT Name FROM Assistenten UNION
SELECT Name FROM Professoren;

Beispiel:

R = { [1, abc, 1.5], [2, def, 2.3] }
S = { [7, xyz, 4.4], [8, uvw, 6.7] }
R ∪ S = { [1, abc, 1.5], [2, def, 2.3], [7, xyz, 4.4], [8, uvw, 6.7] }

Differenz —

Gleiche Voraussetzungen wie bei Vereinigung.

Ergebnis: Selbes Schema, enthält Tupel aus R1, die in R2 nicht vorkommen.

R = { [1, abc, 1.5], [2, def, 2.3] }
S = { [2, def, 2.3], [7, xyz, 4.4] }
R — S = { [1, abc, 1.5] }

SQL-Umsetzung:

-- Variante 1: NOT IN
SELECT Name FROM Studenten WHERE MatrNr NOT IN
  (SELECT DISTINCT MatrNr FROM hoeren);

-- Variante 2: MINUS
SELECT MatrNr FROM Studenten
MINUS
SELECT DISTINCT MatrNr FROM hoeren;

Schnittmenge ∩

Die Schnittmenge ist kein Grundoperator, kann aber abgeleitet werden:

A ∩ B = A — (A — B) = B — (B — A)

SQL-Umsetzung:

-- Variante 1: INTERSECT
SELECT gelesenVon AS PersNr FROM Vorlesungen
INTERSECT
SELECT PersNr FROM Professoren WHERE Rang = 'C4';

-- Variante 2: IN (falls INTERSECT nicht verfügbar)
SELECT gelesenVon AS PersNr FROM Vorlesungen
WHERE PersNr IN
  (SELECT PersNr FROM Professoren WHERE Rang = 'C4');

Kartesisches Produkt × und Join

Komplexe Abfragen nutzen das kartesische Produkt mit anschließender Selektion (Equi-Join):

Anfrage: "Welche Studenten hören welche Vorlesungen?"

π_{s.Name, v.Titel}(σ_{h.VorlNr=v.VorlNr ∧ s.MatrNr=h.MatrNr}(
    Studenten s × Vorlesungen v × hoeren h))

Zusammenfassung Operatoren

Operator	Symbol	SQL-Entsprechung	Grundoperator?
Selektion	σ	WHERE	Ja
Projektion	π	SELECT	Ja
Kartesisches Produkt	×	FROM (Cross Join)	Ja
Umbenennung	ρ	AS	Ja
Vereinigung	∪	UNION	Ja
Differenz	—	MINUS / NOT IN	Ja
Schnittmenge	∩	INTERSECT / IN	Nein (ableitbar)
Join	⋈	JOIN ... ON	Nein (σ + ×)

4. SQL (d_SQL)

4.1 SQL-Kategorien

Kategorie	Abkürzung	Befehle
Data Definition Language	DDL	ALTER, COMMENT, CREATE, DROP, RENAME, TRUNCATE
Data Manipulation Language	DML	CALL, DELETE, EXPLAIN, INSERT, LOCK, MERGE, SELECT, UPDATE
Data Control Language	DCL	GRANT, REVOKE
Transaction Control Language	TCL	COMMIT, ROLLBACK, SAVEPOINT, SET TRANSACTION

4.2 Datentypen

Datentyp = Werte + Operationen

Oracle-Datentypen

Datentyp	Beschreibung
VARCHAR(n) / VARCHAR2(n)	Zeichenkette variabler Länge
CHAR(n)	Zeichenkette fester Länge
NUMBER(p, s)	Dezimale Zahl, p=Stellen (1–38), s=Nachkomma (-84–127), Werte bis ±10^125
DECIMAL(p, s)	Dezimale Zahl, Werte bis ±10^308
INTEGER	Ganze Zahl, -2.147.483.648 bis 2.147.483.647
DATE	Datum/Uhrzeit (sekundengenau)
RAW(n)	Binärdaten, 1–2000 Bytes
LONG RAW	Binärdaten bis 2 GiB
CLOB	Zeichenketten bis 4 GiB
BLOB	Binärdaten bis 4 GiB
CFILE / BFILE	Zeiger auf externe Dateien (Text/Binär)

4.3 Einfache Befehle

DDL – Tabellen anlegen und löschen

CREATE TABLE Professoren (
    PersNr  INTEGER NOT NULL,
    Name    VARCHAR(30) NOT NULL,
    Rang    CHARACTER(2),
    PRIMARY KEY(PersNr)
);

DROP TABLE Professoren;

DML – Einfügen, Löschen, Ändern

-- Einzelnes Tupel einfügen
INSERT INTO Professoren (PersNr, Name, Rang)
VALUES (30314, 'Cantor', 'W2');

-- Mehrere Tupel gleichzeitig
INSERT INTO Professoren (PersNr, Name, Rang) VALUES
(30314, 'Cantor', 'W2'),
(30315, 'Leibniz', 'W1'),
(30316, 'Plank', 'W1');

-- Einfügen mit verschachtelter Abfrage
INSERT INTO hoeren
SELECT MatrNr, VorlNr
FROM Studenten, Vorlesungen
WHERE Titel = 'Datenbanken';

-- Teilweises Einfügen (Rang wird NULL)
INSERT INTO Professoren (PersNr, Name)
VALUES (30317, 'Feuerbach');

-- Löschen
DELETE FROM Professoren;
DELETE FROM Professoren WHERE Rang = 'W3';

-- Ändern
UPDATE Studenten SET Semester = Semester + 1;

Inline-View

Eine SELECT-Anweisung mit einer weiteren SELECT-Anweisung in der FROM-Klausel:

SELECT p.Name, p.Raum
FROM Professoren p,
    (SELECT DISTINCT Boss FROM Assistenten) a
WHERE p.PersNr = a.Boss;

Allgemeine SELECT-Syntax

SELECT column1, column2
FROM table1, table2
WHERE condition
GROUP BY column1, column2
HAVING condition
ORDER BY column1, column2;

4.4 Erweiterungen

Sortieren

SELECT PersNr, Name, Rang FROM Professoren
ORDER BY Rang DESC, Name ASC;

Duplikate eliminieren

SELECT DISTINCT Rang FROM Professoren;

Platzhalter (nur mit LIKE)

_ — genau ein Zeichen
% — beliebig viele Zeichen (auch keines)

SELECT * FROM Professoren WHERE Rang LIKE 'W_';
SELECT * FROM Professoren WHERE Name LIKE 'T%eophrastos';

IN / NOT IN

SELECT Name FROM Studenten WHERE Semester IN (1, 2, 3);

SELECT Name FROM Professoren
WHERE PersNr NOT IN (SELECT gelesenVon FROM Vorlesungen);

ALL / ANY

-- ALL: Alle Bedingungen müssen erfüllt sein (AND)
SELECT Name FROM Studenten WHERE Semester >= ALL (7, 8, 9);

-- ANY: Mindestens eine Bedingung (OR)
SELECT Name FROM Studenten WHERE Semester >= ANY (7, 8, 9);

Aggregatfunktionen

Aggregatfunktionen berechnen einen einzelnen Wert aus einer Menge von Zeilen:

Funktion	Beschreibung	Beispiel
*COUNT()**	Anzahl aller Zeilen	Anzahl aller Studenten
COUNT(Spalte)	Anzahl nicht-NULL-Werte	Anzahl Studenten mit gesetztem Semester
SUM(Spalte)	Summe der Werte	Summe aller Gehälter
AVG(Spalte)	Durchschnitt	Durchschnittsnote
MIN(Spalte)	Kleinster Wert	Niedrigstes Semester
MAX(Spalte)	Größter Wert	Höchstes Semester

-- Anzahl aller Studenten
SELECT COUNT(*) FROM Studenten;

-- Durchschnittsnote
SELECT AVG(Note) FROM pruefen;

-- Anzahl verschiedener Ränge
SELECT COUNT(DISTINCT Rang) FROM Professoren;

GROUP BY

GROUP BY gruppiert Zeilen nach gemeinsamen Attributwerten, sodass Aggregatfunktionen pro Gruppe berechnet werden:

-- Anzahl Vorlesungen pro Professor
SELECT gelesenVon, COUNT(*) AS Anzahl
FROM Vorlesungen
GROUP BY gelesenVon;

-- Durchschnittsnote pro Vorlesung
SELECT VorlNr, AVG(Note) AS Schnitt
FROM pruefen
GROUP BY VorlNr;

Wichtig: In der SELECT-Klausel dürfen bei GROUP BY nur:

Spalten aus GROUP BY und/oder
Aggregatfunktionen stehen

HAVING

HAVING filtert Gruppen (analog zu WHERE für Zeilen). Wird immer nach GROUP BY angewendet:

-- Nur Professoren, die mehr als 2 Vorlesungen halten
SELECT gelesenVon, COUNT(*) AS Anzahl
FROM Vorlesungen
GROUP BY gelesenVon
HAVING COUNT(*) > 2;

Reihenfolge der Klauseln:

SELECT   ...          -- 5. Projektion
FROM     ...          -- 1. Tabellen bestimmen
WHERE    ...          -- 2. Zeilen filtern
GROUP BY ...          -- 3. Gruppen bilden
HAVING   ...          -- 4. Gruppen filtern
ORDER BY ...          -- 6. Sortieren

NULL-Werte

NULL bedeutet unbekannt / nicht vorhanden
Vergleiche mit NULL sind immer NULL (nicht TRUE oder FALSE)
Prüfung auf NULL: IS NULL / IS NOT NULL

-- Professoren ohne Raum
SELECT Name FROM Professoren WHERE Raum IS NULL;

-- Professoren mit Raum
SELECT Name FROM Professoren WHERE Raum IS NOT NULL;

Aggregatfunktionen ignorieren NULL-Werte (außer COUNT(*))

4.5 Anfragen über mehrere Relationen

Vorgehensweise:

Kreuzprodukt aus Tabellen bilden
Relevante Zeilen und Felder ausschneiden

Wichtigste Voraussetzung: Information über Verbindung zwischen Tabellen (Join-Prädikat).

SELECT p.Name Professor, a.Name Assistent
FROM Professoren p, Assistenten a
WHERE p.PersNr = a.Boss;    -- join-Prädikat (access-Prädikat)

Aliasse sind praktikabel und notwendig, wenn Felder mit gleichen Namen aus verschiedenen Tabellen involviert sind.

4.6 JOINs

Motivation

Ohne JOIN stehen Join- und Filter-Prädikate zusammen in WHERE. Der JOIN-Operator trennt diese:

JOIN ... ON: Join-Prädikat
WHERE: Filter-Prädikat

→ Erleichtert dem Optimizer die Arbeit.

Innere JOINs

Tupel ohne Partner gehen verloren.

Natürlicher Verbund (NATURAL JOIN):

Voraussetzung: Gleich benannte Attribute mit gleichem Datentyp
Verknüpft automatisch über gleichnamige Spalten
Join-Attribute erscheinen nur einmal im Ergebnis

SELECT MatrNr, Name, Titel
FROM Studenten NATURAL JOIN hoeren NATURAL JOIN Vorlesungen;

Allgemeiner Verbund (Theta-JOIN / INNER JOIN):

Beliebige Attribute und Bedingungen
Keine Attribute werden eliminiert

SELECT p.Name Professor, a.Name Assistent
FROM Professoren p JOIN Assistenten a ON p.PersNr = a.Boss;

Äußere JOINs

Tupel ohne Partner werden mit NULL ergänzt und bleiben im Ergebnis.

Typ	Beschreibung	SQL
LEFT OUTER JOIN	Alle Tupel der linken Relation bleiben, rechts ggf. NULL	`L LEFT OUTER JOIN R ON ...`
RIGHT OUTER JOIN	Alle Tupel der rechten Relation bleiben, links ggf. NULL	`L RIGHT OUTER JOIN R ON ...`
FULL OUTER JOIN	Alle Tupel beider Relationen bleiben, ggf. NULL	`L FULL OUTER JOIN R ON ...`

Beispiel LEFT OUTER JOIN:

L.A	L.B	L.C	R.D	R.E
a1	b1	c1	d1	e1
a2	b2	c2	NULL	NULL

Semi-JOINs

Liefern Tupel nur aus einer der beiden Relationen.

Operator	Symbol	Beschreibung	Formel
Semi-JOIN L mit R	L ⋉ R	Tupel aus L, die Partner in R haben	π_L(L ⋈ R)
Semi-JOIN R mit L	L ⋊ R	Tupel aus R, die Partner in L haben	π_R(L ⋈ R)
Anti-Semi-JOIN L	L ⊲ R	Tupel aus L ohne Partner in R	L — (L ⋉ R)
Anti-Semi-JOIN R	L ⊳ R	Tupel aus R ohne Partner in L	R — (L ⋊ R)

-- Semi-JOIN
SELECT L.* FROM L INNER JOIN R ON L.x = R.x;
SELECT L.* FROM L INNER JOIN R USING (x);

SQL-Schlüsselwörter

SQL-Schlüsselwort	Entsprechung
CROSS JOIN	Kartesisches Produkt
NATURAL JOIN	Natürlicher Verbund
INNER JOIN	Allgemeiner Verbund (Theta-JOIN)
LEFT OUTER JOIN	Linker äußerer Verbund
RIGHT OUTER JOIN	Rechter äußerer Verbund
FULL OUTER JOIN	Vollständiger äußerer Verbund

4.7 Anfragebearbeitung

Ablauf einer SQL-Anweisung

Parser → Syntax prüfen
Optimizer → Optimalen Zugriffsplan erstellen
Row Source Generator → Ausführungsplan auf physische Ressourcen
Execution Engine → Ergebnisse erzeugen

Optimizer-Algorithmen

Typ	Beschreibung
RBO (Rule-Based)	Intern festgelegte Regeln; veraltet
CBO (Cost-Based)	Interne Statistiken über Tabellen/Indizes; empfohlen

Wichtig: Statistiken müssen regelmäßig aktualisiert werden (Befehl ANALYZE). Optimizer-Hints möglich: /*+CHOOSE */, /*+ORDERED */

Suchverfahren

Methode	Voraussetzung	Geschwindigkeit
Full Table Scan	Keine geeigneten Indizes	Langsamste
Index-Scan	Geeigneter Index vorhanden	Schnellste (Rückgabe: RowID)
Hash-Scan	Keine Indizes; Hash-Werte werden generiert	Mittel

Join-Verfahren

Verfahren	Beschreibung
Verschachtelte Schleifen (Nested Loops)	Äußere Schleife + innere Schleife für jede Zeile
Sort-Merge-Join	Beide Tabellen sortieren, dann zusammenführen
Hash-Join	Hash-Tabelle für eine Tabelle, Suche mit Werten der anderen
Kartesisches Produkt	Bei fehlenden Verbindungsbedingungen
Index-Join	Indizes statt Tabellen verknüpfen (nur bei einspaltigen Indizes)

4.8 Indizes

Überblick

Index-Typ	Geeignet für	Beispiel
Konventionell (Binärbaum)	Spalten mit vielen unterschiedlichen Werten	PersID, Matrikelnummer
Bitmap	Spalten mit vielen gleichen Werten (geringe Kardinalität)	Geschlecht, Kategorie

Allgemeiner Aufbau: { [ Suchfeld, RowID ] }

Lineare Listen

Einfach verkettete Liste: Jedes Element hat Daten + Zeiger auf nächstes Element. Doppelt verkettete Liste: Zusätzlicher Rückwärts-Zeiger.

Operationen:

Anhängen am Ende (keine Sortierung): O(1)
Sortiertes Einfügen: O(n)
Löschen: Zeiger des Vorgängers auf Nachfolger setzen, Speicher freigeben

Binärbäume

Terminologie:

Begriff	Bedeutung
Wurzel (Root)	Einziger Knoten ohne Vorgänger
Blatt	Knoten ohne Nachfolger
Innerer Knoten	Weder Wurzel noch Blatt
Kante	Gerichtete Verbindung (Vorgänger → Nachfolger)
Ebene	Knoten mit gleicher Pfadlänge zur Wurzel
Tiefe	Gesamtzahl der Ebenen
Grad	Maximale Anzahl direkter Nachfolger

Suchaufwand: Logarithmisch O(log n) — aber kann zu O(n) degradieren wenn Baum entartet.

AVL-Baum: Höhe beider Teilbäume an jedem Knoten unterscheidet sich höchstens um 1.

Balancierter Baum: Höchstens letzte Ebene nicht vollständig besetzt. Jeder balancierte Baum ist ein AVL-Baum, aber nicht umgekehrt.

Durchlauf-Reihenfolgen:

Reihenfolge	Kürzel	Verwendung
Preorder	WLR	Baum linear auf Datenträger speichern
Inorder	LWR	Sortierte Liste erstellen → balancierten Baum erzeugen
Postorder	LRW	Geräte programmieren (erst Parameter, dann Operation)

Balancierung:

Offline: Kopie → Inorder-Liste → Binär einfügen → Ausgeglichener Baum. Einfach, aber Zugriffe gesperrt.
Online: Zur Laufzeit rekursiv ausgleichen. Kann kurzfristig zu Fehlern führen.

Hashing

Funktionsprinzip:

Für jeden Datensatz wird ein Schlüssel gebildet
Hash-Funktion ordnet dem Schlüssel einen kurzen Hash-Wert zu
Hash-Wert dient als Index in der Hash-Tabelle
Hash-Tabelle enthält Verweise auf Datensätze

Kollision: Zwei unterschiedliche Schlüssel erzeugen denselben Hash-Wert.

Kollisionsbehandlung:

Hashing mit Verkettung: Verkettete Listen an Hash-Tabellen-Einträgen
Lineares Hashing: Dynamische Tabellenerweiterung bei hohem Belegungsfaktor
Sondierung: Linear/quadratisch/zufällig in der Tabelle selbst suchen

Anforderungen an Hash-Funktionen:

Effizient berechenbar, geringer Speicherbedarf
Wenig Kollisionen (Gleichverteilung der Hash-Werte)
Einwegfunktion (Hash → Schlüssel nicht berechenbar)
Surjektivität (kein Hash-Wert unmöglich)
Lawineneffekt: 1 Bit Unterschied → mindestens halbe Bits der Hash-Werte unterschiedlich

Hash-Funktions-Beispiele:

Modulo: HW = Key % Basis (Primzahlen empfohlen)
Abschneiden: Key² berechnen, dann von links/rechts kürzen
Zerlegung & Addition: Key in gleich große Teile zerlegen und addieren

Binärbäume vs. Hashing:

Bäume: Garantie im Worst Case, Sortierung möglich, dynamische Größe
Hashing: Schneller im Durchschnitt O(1) vs. O(log n)

Bitmap-Indizes

Geeignet für:

Geringe Kardinalität (0,1%–1% unterschiedliche Werte)
Wenige Änderungen (Data Warehouse / OLAP)

Aufbau: Für jeden einzigartigen Wert eine Bit-Spalte. Pro Zeile steht 1 (Treffer) oder 0 (kein Treffer).

Vorteile:

Stark komprimiert → schnell lesbar
Mehrere Indizes kombinierbar
Logische Operationen (AND, OR) sehr schnell im Prozessor

Nachteile:

Immenser Wartungsaufwand bei Änderungen
Bandbreite der Prozessor-Kanäle wichtig
Können Deadlocks verursachen

5. Normalformen (e_NFs)

5.1 Einführung

Normalisierung = Aufteilung von Attributen in mehrere Relationen (Tabellen) mithilfe der Normalisierungsregeln, sodass eine Struktur entsteht, die keine vermeidbaren Redundanzen mehr enthält.

Ziele:

Ziel	Beschreibung
Redundanzbeseitigung	Nur notwendige Redundanz bleibt erhalten
Anomalienvermeidung	Funktionelle und transitive Abhängigkeiten werden aufgelöst
Klare Struktur	Erstellung eines klar strukturierten Datenbankmodells

Praktische Bedeutung:

Praktisch wichtig sind nur die ersten drei Normalformen (1NF, 2NF, 3NF)
Manchmal ist es sinnvoll, auf Normalformen aus Performancegründen zu verzichten
Jede nächste Normalform basiert auf der vorigen

5.2 Funktionale Abhängigkeit

Definition: Y ist von X funktional abhängig (X → Y), wenn für alle Tupel t1 und t2 gilt:

Wenn t1 ∩ X = t2 ∩ X, dann gilt auch t1 ∩ Y = t2 ∩ Y

Y hängt von X ab, wenn X die Werte von Y eindeutig bestimmt
X bestimmt alle anderen Attribute → X ist ein Superschlüssel
Ist X auch minimal, dann ist X ein Kandidat für Primärschlüssel

Arten der Abhängigkeit:

Art	Notation	Beschreibung
Funktionale Abhängigkeit	X → Y	X bestimmt Y eindeutig
Mehrwertige Abhängigkeit (multivalued)	X →→ Y	X bestimmt eine Menge von Y-Werten

5.3 Erste Normalform – 1NF

Eine Tabelle liegt in 1NF vor, wenn ihre Zellen nur atomare Werte beinhalten, d. h. sie enthalten nicht mehr als einen Wert (keine Auflistungen).

"Atomar" bedeutet: Die Werte können nicht weiter in kleinere Komponenten zerlegt werden, die einzeln einen Sinn im Anwendungsbereich ergeben.

Regeln:

Wiederholungsgruppen werden vermieden, indem jede Gruppe in eine separate Tabelle eingefügt und durch eine 1:N-Beziehung verbunden wird
Ob ein Attribut atomar ist, hängt stark von der Mini-Welt ab
Laut E. F. Codd müssen Tabellen in 1NF nicht unbedingt einen Primärschlüssel haben

Mini-Welt-Beispiele: Adresse:

Mini-Welt	Kontext	Atomar?
Logistik-Firma (Müll-Abfuhr)	PLZ, Straße, Hausnummer werden einzeln für Routenberechnung benötigt	PLZ, Straße, Hausnummer sind jeweils atomar
Buchhaltung (Gehaltsabrechnung)	Nur die gesamte Adresse wird für Briefversand benötigt	Gesamte Adresse ist als Ganzes atomar

Beispiel Bahnwagen:

Ausgangstabelle (nicht in 1NF): Feld "Beschreibung" enthält 'Wagentyp, Leergewicht, Kapazität, Hersteller, Baujahr' → nicht atomar

In 1NF gebracht:

W1 = { [ WagenID, Status, Ankunft, Station, WagenType,
         Leergewicht, Kapazitaet, Hersteller, Baujahr ] }

Beispiel Vertragsdaten:

Ausgangstabelle (nicht in 1NF):

Vertragsdatum	Kunde	Produkt
01.02.2010	Kohl	VW 30.000, BMW 40.000, Opel 40.000
03.01.2012	Schröder	VW 32.000, Mercedes 35.000

In 1NF gebracht:

Vertragsdatum	Kunde	Produkt	Preis
01.02.2010	Kohl	VW	30.000
01.02.2010	Kohl	BMW	40.000
01.02.2010	Kohl	Opel	40.000
03.01.2012	Schröder	VW	32.000
03.01.2012	Schröder	Mercedes	35.000

5.4 Zweite Normalform – 2NF

Eine Tabelle liegt in 2NF vor, wenn sie:

In 1NF vorliegt
Jedes Feld, das nicht zum Primärschlüssel gehört, vom ganzen Primärschlüssel abhängt

Regel: Besteht der Primärschlüssel nur aus einem Feld, liegt die Tabelle automatisch in 2NF vor.

Vorgang: Felder, die nur vom Teil des Primärschlüssels abhängig sind, werden zusammen mit dem Teilschlüssel in neue Tabellen ausgelagert.

Beispiel Bahnwagen: Die Felder [WagenType], [Leergewicht], [Kapazitaet], [Hersteller], [Baujahr] hängen nur von [WagenID] ab, aber nicht von [Ankunft] → nicht in 2NF.

Aufteilung in 2NF:

W11 = { [ WagenID, Ankunft, Status, Station ] }         ← PK = [WagenID, Ankunft]
W12 = { [ WagenID, WagenType, Leergewicht, Kapazitaet,
          Hersteller, Baujahr ] }                         ← PK = [WagenID]

Beispiel Vertragsdaten: PK = [Vertragsdatum, Kunde, Produkt]

[Herkunftsland] hängt nur von [Produkt] ab → verletzt 2NF
[Lieferadresse] hängt nur von [Kunde] ab → verletzt 2NF
[V-Art] hängt nur von [Produkt] ab → verletzt 2NF

Beispiel Bestellungen: Bei ArtNr : LagerOrt = 1:1 gibt es zwei Schlüsselkandidaten: [RNr, ArtNr] und [RNr, LagerOrt]. Die 2NF ist in beiden Fällen verletzt.

ERM-Bezug: Wenn man vom ERM ausgeht und den konzeptuellen Entwurf korrekt in den logischen umwandelt, kommt man direkt zu Tabellen, die die 2NF nicht verletzen.

5.5 Dritte Normalform – 3NF

Eine Tabelle liegt in 3NF vor, wenn sie:

In 2NF vorliegt
Alle Felder, die nicht zum Primärschlüssel gehören, voneinander unabhängig sind

Regel: Wenn nur ein Nichtschlüsselfeld in der Tabelle vorhanden ist, liegt die Tabelle automatisch in 3NF vor.

Wichtig: In der Praxis ist die 3NF oft ausreichend für eine perfekte Balance aus Redundanz, Performance und Flexibilität.

Vorgang: Funktionale Abhängigkeiten unter Nicht-PK-Feldern werden durch Aufteilung der Tabelle aufgelöst.

Beispiel Bahnwagen: Aus 2NF: W12 = { [ WagenID, WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] } [Leergewicht], [Kapazitaet], [Hersteller] und ggf. [Baujahr] sind vom Feld [WagenType] abhängig → nicht in 3NF.

Variante a (Baujahr vom WagenType abhängig):

W121a = { [ WagenID, WagenType ] }
W122a = { [ WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }

Variante b (Baujahr vom WagenType unabhängig):

W121b = { [ WagenID, WagenType, Baujahr ] }
W122b = { [ WagenType, Leergewicht, Kapazitaet, Hersteller ] }

5.6 Boyce-Codd-Normalform – BCNF

Eine Tabelle liegt in BCNF vor, wenn sie:

In 3NF vorliegt
Kein Teil eines Schlüsselkandidaten funktional von keinem Teil eines anderen Schlüsselkandidaten abhängig ist

Kern: BCNF behandelt die Abhängigkeiten zwischen Teilen mehrerer Schlüsselkandidaten, falls diese sich teilweise überlappen.

Regel: Gibt es nur einen Schlüsselkandidaten oder liegt keine Überlappung vor, befindet sich die Tabelle automatisch in BCNF.

Beispiel Sportvereine:

Name	Sportart	Verein
Schulz	Fußball	FC Berlin
Mayer	Fußball	FC Berlin
Zimmermann	Fußball	FC Marzahn
Mayer	Volleyball	VC Hamburg

Beziehung: Sportart : Verein = 1 : N. Schlüsselkandidaten: [Name, Sportart] und [Name, Verein] → Überlappung (Name). [Sportart] hängt vom Nicht-Schlüssel-Feld [Verein] ab → verletzt BCNF.

Lösung:

Tabelle 1 = { [ Name, Verein ] }
Tabelle 2 = { [ Sportart, Verein ] }

5.7 Vierte Normalform – 4NF

Eine Tabelle liegt in 4NF vor, wenn sie:

In BCNF vorliegt
Nur semantisch verbundene Nichtschlüsselattribute sich in der Tabelle befinden

Die 4NF trennt semantisch (thematisch, inhaltlich) unabhängige Entitäten durch Aufteilung.

Beispiel Bahnwagen: [Leergewicht] und [Kapazitaet] werden viel öfter verwendet als [Hersteller] und [Baujahr] (historische Bedeutung) → unterschiedliche Semantik.

W122a1 = { [ WagenType, Leergewicht, Kapazitaet ] }    ← technische Daten
W122a2 = { [ WagenType, Hersteller, Baujahr ] }         ← historische Daten

5.8 Fünfte Normalform – 5NF

Eine Tabelle liegt in 5NF vor, wenn sie:

In 4NF vorliegt
Nicht mehr in Tabellen eines geringeren Grades zerlegt werden kann

Kern: Die neuen Tabellen können jederzeit den ursprünglichen Zustand ohne Informationsverlust wieder herstellen (durch JOIN).

Nachteil: Man braucht in der Praxis ständig die ganzen Informationen und muss daher ständig die vereinfachten Tabellen wieder vereinigen (JOIN).

Beispiel Touristik-Firma:

T10 = { [ PersID, TourNr, Trans-Unternehmen ] }    ← PK = alle drei Attribute

Zerlegbar in:

T11 = { [ PersID, TourNr ] }
T12 = { [ PersID, Trans-Unternehmen ] }
T13 = { [ TourNr, Trans-Unternehmen ] }

Beispiel Hersteller-Produkt-Person:

TA = { [ HerstID, ProduktID ] }
TB = { [ PersID, ProduktID ] }
TC = { [ HerstID, PersID ] }

5.9 Anomalien ohne Normalisierung

Beispiel: Tabelle mit Mitarbeitern, Abteilungen und Projekten (nicht normalisiert):

PersID	Name	AbtNr	Abteilung	ProjNr	ProjBeschreibung
1	Anna	42	Second Level	BE	Bergland ...
1	Anna	42	Second Level	NO	Nordsee ...
2	Arnold	42	Second Level	NO	Nordsee ...
2	Arnold	42	Second Level	OG	Ostgipfel ...
3	Betty	53	First Dept	OG	Ostgipfel ...
3	Betty	53	First Dept	WO	West-Ozean ...
4	Chris	53	First Dept	WO	West-Ozean ...

Anomalie	Problem
Einfüge-Anomalie	Neuer Mitarbeiter mit mehreren Projekten → mehrere Zeilen, Vertippen möglich
Änderungs-Anomalie	Projektumbenennung → mehrere Zeilen ändern, Übersehen möglich
Lösch-Anomalie	Mitarbeiter löschen → mehrere Zeilen entfernen, Übersehen möglich

Normalisierung → 3NF:

Mitarbeiter   = { [ PersID, Name, AbtNr ] }
Abteilung     = { [ AbtNr, Abteilung ] }
arbeitet_an   = { [ PersID, ProjNr ] }
Projekt       = { [ ProjNr, ProjBeschreibung ] }

5.10 ERM als Alternative zur Normalisierung

Wichtige Erkenntnis: Wenn man vom ERM ausgeht und den konzeptuellen Entwurf korrekt in den logischen umwandelt (inkl. Vereinfachung), bekommt man ziemlich wahrscheinlich Tabellen in 3NF. ERM und Normalisierung sind komplementäre Ansätze zum gleichen Ziel.

Übersicht Normalformen

NF	Voraussetzung	Regel	Automatisch erfüllt wenn...
1NF	—	Nur atomare Werte in Zellen	Keine Auflistungen vorhanden
2NF	1NF	Jedes Nicht-PK-Feld hängt vom ganzen PK ab	PK besteht aus nur einem Feld
3NF	2NF	Nicht-PK-Felder sind voneinander unabhängig	Nur ein Nicht-PK-Feld vorhanden
BCNF	3NF	Keine Abhängigkeiten zwischen Teilen verschiedener Schlüsselkandidaten	Nur ein Schlüsselkandidat oder keine Überlappung
4NF	BCNF	Nur semantisch verbundene Nicht-PK-Attribute zusammen	Alle Attribute thematisch zusammengehörig
5NF	4NF	Nicht weiter in Tabellen geringeren Grades zerlegbar	Zerlegung würde Informationsverlust verursachen

Durchgängiges Beispiel: Bahnwagen

Ausgangstabelle:  { [ WagenID, Beschreibung, Status, Ankunft, Station ] }
→ 1NF:  W1   = { [ WagenID, Status, Ankunft, Station, WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
→ 2NF:  W11  = { [ WagenID, Ankunft, Status, Station ] }
        W12  = { [ WagenID, WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
→ 3NF:  W11  = { [ WagenID, Ankunft, Status, Station ] }
        W121 = { [ WagenID, WagenType ] }
        W122 = { [ WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
→ 4NF:  W122a1 = { [ WagenType, Leergewicht, Kapazitaet ] }
        W122a2 = { [ WagenType, Hersteller, Baujahr ] }

6. Transaktionen (f_Transaktionen)

6.1 Definition

Integrität (Konsistenz) der Datenbank = Zustand der Daten, in dem sie korrekt, vollständig und widerspruchsfrei sind.

Transaktion = Mehrere Operationen, die:

Entweder alle erfolgreich durchgeführt werden
Oder, falls ein Fehler vorliegt, die schon durchgeführten rückgängig gemacht werden müssen

Eigenschaften:

Transaktionen gewährleisten einen konsistenten Zustand der Datenbank
Sie versetzen den Datenbestand von einem konsistenten Zustand in einen anderen konsistenten Zustand
Eine Transaktion wird als atomare (ununterbrechbare) Operation betrachtet
Bei Fehlern werden Komponenten nicht rückgängig gemacht (zeitintensiv), sondern der zuvor gespeicherte Zustand wird wiederhergestellt

6.2 Beispiel

Zwei ganze Zahlen A und B:

T1 = { A=A+100; B=B+100; }
T2 = { A=A*2;   B=B*2;   }

Sequenzielle Ausführung → Konsistenz gewährleistet
Gemischte Operationen → Konsistenz nicht mehr gewährleistet

6.3 Anforderungen

Anforderung	Beschreibung
Gleichzeitige Verarbeitung	Mehrere Transaktionen müssen quasi-parallel verarbeitet werden
Fehlerbehandlung	Abgeschlossene Transaktionen bleiben bestehen, offene werden rückgängig gemacht
Organisation	Manuell (im Source-Code) oder automatisch
Zwischenpunkte	Daten erfolgreich durchgeführter Operationen können gespeichert werden
Abschlussarten	Nur COMMIT (erfolgreich) oder ROLLBACK (erfolglos)

Gründe für ROLLBACK: Systemfehler, Integritätsverletzungen, Deadlock, Benutzeranweisung.

6.4 ACID-Eigenschaften

Eigenschaft	Beschreibung
Atomicity (Atomarität)	Entweder alle Befehle oder gar keine werden ausgeführt
Consistency (Konsistenz)	Transaktion hinterlässt nach Beendigung einen konsistenten Datenzustand, ansonsten komplettes Zurücksetzen
Isolation	Nebenläufige Transaktionen beeinflussen sich nicht gegenseitig; jede wird logisch so ausgeführt, als wäre sie die einzig aktive
Durability (Dauerhaftigkeit)	Wirkung einer erfolgreich abgeschlossenen Transaktion bleibt dauerhaft erhalten, auch nach Systemfehler

6.5 Zustände einer Transaktion

BoT → Active → Committing → Änderungen festgeschrieben → EoT
         ↓          ↓
    Waiting for   ERROR
    resources       ↓
         ↓      Rolling back → Änderungen rückgängig gemacht → EoT
      DEADLOCK
         ↓
    ROLLBACK → Rolling back

Zustand	Beschreibung
BoT	Begin of Transaction
Active	Transaktion führt Operationen aus
Waiting for resources	Wartet auf gesperrte Ressourcen
DEADLOCK	Gegenseitige Blockierung erkannt
Committing	Änderungen werden festgeschrieben (COMMIT)
Rolling back	Änderungen werden rückgängig gemacht (ROLLBACK)
EoT	End of Transaction

6.6 Synchronisation

Synchronisation (Mehrbenutzersynchronisation) = Koordinierung von mehreren Benutzerprozessen, eng verbunden mit der Ausführung der Transaktionen.

Art	Beschreibung	Eigenschaft
Seriell	Transaktionen nacheinander	Absolut sicher, aber langsam; blockiert nachfolgende Transaktionen
Parallel	Transaktionen gleichzeitig	Nutzt Ressourcen besser aus
Serialisierung	Anordnung paralleler Operationen	Entspricht in der Wirkung der seriellen Ausführung, garantiert Konsistenz

6.7 Probleme bei paralleler Ausführung

Bei Zugriff auf denselben Datenbestand können folgende Probleme entstehen:

Lost Update

Die von einer Transaktion geänderten Daten werden von einer anderen Transaktion überschrieben.

Variante 1 – Direkt:

T1: update TabX set V=42;       T2: ...
T1: ...                          T2: update TabX set V=53;
T1: ...                          T2: commit;
T1: commit;                      T2: ...

→ Update von T2 geht verloren. Kommt in Datenbanken nicht vor, da T2 auf Freigabe wartet.

Variante 2 – Über lokale Variable:

T1: select V from TabX into W;  T2: ...
T1: W := W+1;                   T2: update TabX set V=53;
T1: update TabX set V=W;        T2: commit;
T1: commit;                     T2: ...

→ Update von T2 geht verloren. Kann durch höhere Isolationsstufe vermieden werden.

Lösung: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

Die Transaktion merkt sich die Daten, die zum Start der Transaktion festgeschrieben waren
Ändert eine andere Transaktion diese Daten, bricht die erste ab
Fehler: ORA-08177: can't serialize access for this transaction

Dirty Read

Eine Transaktion liest Daten, die eine andere Transaktion geändert, aber noch nicht festgeschrieben hat.

T1: ...                          T2: update TabX set V=42;
T1: select V from TabX;          T2: ...        ← T1 liest V=42
T1: ...                          T2: rollback;  ← V=42 war ungültig!

Lösung: Standard-Isolationsstufe in Oracle ist READ COMMITTED → verhindert Dirty Read automatisch. Dirty Read ist nur möglich mit READ UNCOMMITTED (in Oracle nicht verfügbar).

Non-Repeatable Read

Eine Transaktion liest zweimal dieselben Daten und bekommt unterschiedliche Ergebnisse.

T1: select V from TabX;         T2: ...
T1: ...                          T2: update TabX set V=42;
T1: ...                          T2: commit;
T1: select V from TabX;          T2: ...        ← anderer Wert!

Lösung: Isolationsstufe SERIALIZABLE (Standard READ COMMITTED lässt dies zu).

Phantom Read

Ähnlich Non-Repeatable Read, aber mit Anzahl der Zeilen statt Werten.

T1: select count(*) from TabX;  T2: ...
T1: ...                          T2: insert into TabX ...;
T1: ...                          T2: commit;
T1: select count(*) from TabX;   T2: ...        ← anderer Count!

Lösung: Isolationsstufe SERIALIZABLE.

6.8 Trade-off der Isolationsstufen

Niedrigere Stufe	Höhere Stufe
Erlaubt gleichzeitigen Zugriff	Vermindert Probleme
Mehr mögliche Nebenwirkungen	Mehr Systemressourcen
Höhere Performance	Höhere Blockierungswahrscheinlichkeit

6.9 Isolationsstufen nach ANSI/ISO SQL92

Isolationsstufe	Verhindert	Besonderheit
READ UNCOMMITTED	—	Dirty Read erlaubt; fehlt in Oracle
READ COMMITTED	Dirty Read	Standard in Oracle; Lesesperren werden kurz gesetzt und aufgehoben
REPEATABLE READ	Dirty Read, Non-Repeatable Read	Sperren für gesamte Transaktion; fehlt in Oracle
SERIALIZABLE	Dirty Read, Non-Repeatable Read, Phantom Read, Lost Update	Höchste Stufe; keine weiteren schreibenden Transaktionen auf dieselben Daten

Hinweis:

Die Isolationsstufe betrifft den Schreibvorgang nicht – eine Transaktion bekommt immer eine exklusive Sperre für alle zu ändernden Daten
Die Isolationsstufe wirkt auf die Lesevorgänge – definiert, wie Lesevorgänge von anderen Transaktionen abhängig sind
Der SQL-Standard schreibt diese Stufen vor, aber konkrete Datenbanken unterstützen sie unterschiedlich

6.10 Synchronisationsstrategien

Der Scheduler steuert die Ausführungsreihenfolge von Operationen verschiedener Transaktionen.

Strategie	Beschreibung
Pessimistisch	Scheduler verzögert Operationen, legt optimale Reihenfolge fest
Optimistisch	Scheduler schickt Operationen sofort zur Ausführung

6.11 Synchronisationsverfahren

Sperrbasierte Synchronisation

Wird oft eingesetzt.

Regel	Beschreibung
Jedes Datenobjekt hat eine Sperre	Tabelle, Datensatz, Attribut, Index, View
Sperren vor Benutzung	Jedes Objekt muss vor Zugriff gesperrt werden
Warten bei Sperre	Ist Objekt schon gesperrt, muss die Transaktion warten
Exklusivität	Nur eine Transaktion kann die Sperre halten
Lesesperre (shared lock)	Andere Transaktionen dürfen die Daten lesen
Schreibsperre (exclusive lock)	Andere Transaktionen dürfen Daten weder lesen noch ändern
Sperren aufheben	Am Ende der Transaktion werden alle Sperren aufgehoben

Löst: Alle Probleme außer Phantom Read.

2-Phasen-Sperrprotokoll – 2PL

Phase	Beschreibung	Sicherste Variante
Wachstumsphase	Viele Sperren werden angefordert, wenige freigegeben	Sperren werden nur gesetzt, nicht aufgehoben
Minderungsphase (Schrumpfphase)	Viele Sperren werden freigegeben, wenige angefordert	Sperren werden nur aufgehoben, nicht gesetzt

Zeitstempelbasierte Synchronisation

Wird selten eingesetzt.

Regel	Beschreibung
Eindeutiger Zeitstempel	Jede Transaktion bekommt einen eindeutigen Zeitstempel
Ordnung	Scheduler ordnet konkurrierende Operationen nach Zeitstempel
Objektstempel	Zu jedem Datenobjekt wird der Zeitstempel der letzten Operation gespeichert
Abweisung	Operation mit früherem Zeitstempel als der des Objektes wird abgewiesen
Reihenfolge	Transaktionen müssen laut Zeitstempelreihenfolge beendet werden

Löst: Alle Probleme außer Phantom Read.

7. Speicherstrukturen (g_Speicherstrukturen)

7.1 Überblick

Oracle verwaltet eigene Speicherstrukturen auf dem Datenträger und im Arbeitsspeicher zwecks effizienter und konsistenter Datenbearbeitung.

Ort	Strukturen
Datenträger	Tablespaces, Datenbankdateien, Segmente, Redo-Log-Dateien
Arbeitsspeicher	System Global Area (SGA), Program Global Area (PGA), User Global Area (UGA)

7.2 Datenträger

Tablespace

Ein Tablespace enthält theoretisch mehrere Tabellen und Indizes, verteilt auf mehrere Datenbankdateien.

Tablespace
├── Tabelle A, Tabelle B, Tabelle C
├── Index D, Index E
├── Datenbankdatei 1
└── Datenbankdatei 2

Hierarchie der Strukturen

Ein separates Tablespace ist für jede Anwendung gedacht (alle User, Tabellen, Indizes, Prozeduren).

Ebene	Beschreibung
Datenbank	Besteht aus mehreren Tablespaces
Tablespace	Besteht aus mehreren Datenbankdateien
Datenbankdatei	Besteht aus mehreren Segmenten (Extenten), zugeordnet zu Tabellen oder Indizes
Segment	Besteht aus mehreren Blöcken
Block	Kleinste Einheit, die gelesen/geschrieben werden kann

Ist eine Tabelle voll, kann sie durch ein Segment (Extent) erweitert werden.

Logische vs. Physische Objekte

Typ	Beispiele
Logische Objekte	Tabellen, Indizes, User, Prozeduren
Physische Objekte	Tablespace, Datenbankdatei, Segment (Extent), Block

CREATE TABLE mit Storage-Klausel

CREATE TABLE T (
    A INTEGER, B VARCHAR2(20)
)
TABLESPACE myTabSpc STORAGE (
    INITIAL      1M        -- Anfangssegment
    NEXT         500K      -- Extente (weitere Segmente)
    MINEXTENTS   1         -- minimale Anzahl der Segmente
    MAXEXTENTS   100       -- maximale Anzahl der Segmente
    PCTINCREASE  10        -- Größe der Segmente wächst um 10%
);

Tablespace-Verwaltung

-- Tablespace anzeigen
SELECT * FROM user_tablespaces;
SELECT * FROM dba_tablespaces;

-- Tablespace erstellen
CREATE TABLESPACE orion
DATAFILE 'c:\oracle\oradata\ora\orion.dbf'
SIZE 10M
AUTOEXTEND ON NEXT 200K MAXSIZE 200M;

-- Datenbankdatei hinzufügen
ALTER TABLESPACE orion
ADD DATAFILE 'c:\oracle\oradata\ora\orion2.dbf'
SIZE 10M AUTOEXTEND ON NEXT 100K MAXSIZE 800M;

-- Tablespace offline/online schalten
ALTER TABLESPACE orion OFFLINE IMMEDIATE;
ALTER TABLESPACE orion ONLINE;

-- Einzelne Datenbankdateien offline/online
ALTER DATABASE DATAFILE '...\orion3.dbf' OFFLINE DROP;
ALTER DATABASE DATAFILE '...\orion4.dbf' ONLINE;

Rollback-Segmente und Redo-Log-Dateien

Struktur	Funktion
Rollback-Segmente	Speichern Daten vor Änderungen; Anfragen lesen aus Rollback-Segmenten, solange Änderungen noch nicht COMMIT sind; in Oracle automatisch via Undo-Management im UNDO-Tablespace verwaltet
Redo-Log-Dateien	Enthalten schon durchgeführte Änderungen; ermöglichen Nachvollziehen der gesamten Datenänderungsgeschichte; werden zyklisch beschrieben und automatisch archiviert

7.3 Arbeitsspeicher

System Global Area – SGA

Komponente	Beschreibung
Database-Buffer-Cache	Enthält Datenblöcke (z. B. Zeilen einer Tabelle), die angezeigt/geändert werden müssen; lädt mehrere Zeilen (auch benachbarte) für hohe Zugriffsgeschwindigkeit; wird von speziellen Algorithmen verwaltet (Verdrängung nicht benötigter Daten)
Dirty List	Liste mit Blockadressen aus dem Database-Buffer-Cache, deren Daten geändert wurden; geänderte Blöcke werden nach COMMIT anhand der Dirty List in die Datenbank geschrieben
Redo-Log-Buffer	Protokolliert Daten vom Database-Buffer-Cache für den Fall eines unerwarteten Systemabsturzes
Shared Pool	Verarbeitet SQL-Anweisungen: Benutzerrechte prüfen, Existenz von Tabellen/Spalten prüfen, Syntax prüfen, Optimierung; nutzt Metadaten aus dem Data Dictionary (Tablespace SYSTEM)
Large Pool	Speicherplatz für System-Komponenten wie z. B. Recovery-Manager
Java Pool	Virtuelle Umgebung für Java-Anwendungen

Program Global Area – PGA

Beinhaltet Informationen, die für die Steuerung der gesamten Oracle-Prozesse notwendig sind.

User Global Area – UGA

Beinhaltet Informationen, die einem aktuell verbundenen Benutzer zugeordnet sind (Sitzung).

8. Sicherungskonzepte (h_Sicherungskonzepte)

8.1 Datensicherheit

Datensicherheit = Alle technischen und organisatorischen Maßnahmen zum Schutz der Daten vor Verfälschung, Zerstörung und unzulässiger Weitergabe.

Informationssicherheit ist nicht nur Technik, sondern auch abhängig von organisatorischen und personellen Rahmenbedingungen
Das BSI (Bundesamt für Sicherheit in der Informationstechnik) veröffentlicht das IT-Grundschutzhandbuch

8.2 Schadenskategorien

Kategorie	Beschreibung	Beispiel
Verlust der Verfügbarkeit	Grundlegende Informationen nicht vorhanden	Keine Geldtransaktionen, Online-Bestellungen oder Produktionsprozesse möglich
Verlust der Vertraulichkeit	Ungewollte Offenlegung von Informationen	Personenbezogene Daten, Umsatz, Marketing, Forschungsdaten gelangen an Konkurrenz
Verlust der Integrität	Gefälschte Daten	Fehlbuchungen, falsche Lieferungen, fehlerhafte Produkte
Verlust der Authentizität	Daten falscher Person zugeordnet	Zahlungsanweisungen zu Lasten Dritter, falsche digitale Willenserklärungen

8.3 Relevante Gesetze

Gesetz	Kürzel	Jahr
Bundesdatenschutzgesetz	BDSG	1990/2003/2009
Telekommunikationsgesetz	TKG	2004
Telemediengesetz	TMG	2007
Signaturgesetz	SigG	2001
Diverse Landesdatenschutzgesetze	—	—

8.4 Grundprinzipien der Sicherheit

Prinzip	Beschreibung
Authentifizierung	Subjekte (Benutzer, Rechner, Dienste) müssen ein Konto besitzen und sich mit gültigem Anmeldenamen + Kennwort anmelden; moderne DB erlauben auch Betriebssystem-Authentifizierung und Zertifikate
Autorisierung	System muss Zugriffsrechte implementieren: Leserechte (ohne Änderung), Änderungsrechte (inkl. Lesen), volle Rechte (inkl. Weitergabe); Verweigerung/Entziehung möglich
Protokollierung	Alle wichtigen Vorgänge müssen überwacht werden: Lesen/Ändern/Löschen, Anmeldung, DB-Start/Stop, Kontenverwaltung; Mindestangaben: wer, was, wann; in Oracle: Auditing

Beispiel Verletzung: Web-Server ordnet alle Anfragen einem pauschalen Konto zu → Verletzung der Authentifizierung → potenzieller Angreifer kann unsinnige Anfragen senden.

8.5 Integrität

Integrität (Konsistenz) = Zustand der Daten, in dem sie korrekt, vollständig und widerspruchsfrei sind.

Art	Beschreibung
Semantische Integrität	Werte gehören zum Wertebereich, richtige Datentypen, keine Tippfehler
Referentielle Integrität	Korrektheit der Primär- und Fremdschlüssel, Existenz der Verweise
Logische Integrität	Transaktionen, zusammengehörende Operationen

Gewährleistung der Integrität

Ebene	Beschreibung
Datenbank (bessere Lösung)	Klauseln in DDL-Anweisungen
Anwendung (zusätzliche Lösung)	Programmcode der Anwendung

Vorteile der DB-Ebene:

DB selbst gewährleistet Konsistenz → inkonsistente Zustände unmöglich
Ein-/Ausschaltbar (z. B. beim Import)
Standardisierte Möglichkeiten
Unabhängig von einzelnen Anwendungen
Schnellere Anwendungsentwicklung

Integritätsverletzende Operationen

DML: INSERT, UPDATE, DELETE
DDL: ALTER, DROP, RENAME

Aktionen bei Integritätsverletzung

Aktion	Beschreibung
Rollback	Abbrechen der Operation und Zurücksetzen auf Zustand davor
Cascade	Propagieren der Operation auf alle beteiligten Tabellen
Set Null	Betroffene Attribute auf NULL setzen

Referentielle Integrität

Die Werte eines Fremdschlüssels müssen auch als Werte des Primärschlüssels vorhanden sein.

Constraint-Typen

Constraint	Beschreibung
PRIMARY KEY	Attribut(e) bilden primären Schlüssel; automatisch wird Index angelegt (Oracle)
FOREIGN KEY	Attribut(e) bilden PK in einer anderen Tabelle
ON DELETE CASCADE	Löschen in PK-Tabelle löscht auch FK-Datensätze
NOT NULL	Attribut muss einen Wert haben
UNIQUE	Werte sind einmalig
CHECK	Logischer Ausdruck muss wahr sein

Beispiele

CREATE TABLE Studenten (
    MatrNr   INTEGER PRIMARY KEY,
    Name     VARCHAR(30) NOT NULL,
    Semester INTEGER CHECK Semester BETWEEN 1 AND 13
);

CREATE TABLE Professoren (
    PersNr INTEGER PRIMARY KEY,
    Name   VARCHAR(30) NOT NULL,
    Rang   CHAR(2) CHECK (Rang IN ('C2', 'C3', 'C4')),
    Raum   INTEGER UNIQUE
);

CREATE TABLE voraussetzen (
    Vorgaenger INTEGER REFERENCES Vorlesungen(VorlNr) ON DELETE CASCADE,
    Nachfolger INTEGER REFERENCES Vorlesungen(VorlNr) ON DELETE NO ACTION,
    PRIMARY KEY (Vorgaenger, Nachfolger)
);

CREATE TABLE pruefen (
    MatrNr INTEGER REFERENCES Studenten ON DELETE CASCADE,
    VorlNr INTEGER REFERENCES Vorlesungen,
    PersNr INTEGER REFERENCES Professoren,
    Note   NUMERIC(2,1) CHECK (Note BETWEEN 0.7 AND 5.0),
    PRIMARY KEY (MatrNr, VorlNr)
);

Trigger

Trigger = Prozedur/Funktion, die bei bestimmten Ereignissen automatisch gestartet wird.

Auslöser:

DML: INSERT, DELETE, UPDATE
DDL: CREATE, ALTER, DROP
An-/Abmeldung, Start/Stop der DB

Zeitpunkt:

Zeitpunkt	Beschreibung
BEFORE	Vor der Änderung
AFTER	Nach der Änderung
INSTEAD OF	Statt der Änderung

8.6 Rechte

User/Schema-Konzept in Oracle

Zentral: User (Benutzer), auch Schema genannt
Oracle-DB besteht aus verschiedenen Schemen, innerhalb derer ERM realisiert sind
Vordefinierte Benutzer: SYS und SYSTEM (alle Rechte)
Alle anderen Benutzer müssen erstellt und mit Rechten versehen werden

Zugriffsrichtlinien

Klare Richtlinien sollten festlegen: wer darf zugreifen, auf welche Ressourcen, welche Zugriffsart, an welchen Tagen/Uhrzeiten, von welchen Computern, wer erlaubt/informiert/protokolliert/abrechnet.

Sicherheitsmechanismen

Mechanismus	Beschreibung
DAC (Discretionary Access Control)	Regel: {O, S, R, P, F} – Objekte, Subjekte, Zugriffsrechte, Prädikat, Recht zur Rechtevergabe
MAC (Mandatory Access Control)	Hierarchie der Prozesse mit Markierungen (Einstufung); Kommunikation nur bei gleichem Niveau

Privilegien

Typ	Beispiele
Systemprivilegien	Anmeldung, Anlegen/Löschen von Tabellen/Benutzern/Prozeduren, Abfragen von Systemtabellen, Verwaltung von Tablespaces
Objektprivilegien	Abfragen von Tabellen, Ändern von Inhalten, Verwenden von Funktionen

Empfehlung: Sinnvolle Rollenmatrix erstellen; Benutzer bekommen keine Privilegien direkt, sondern über Rollen.

Benutzerverwaltung

-- Benutzer erstellen
DROP USER Student07;
CREATE USER Student07 IDENTIFIED BY system
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON users;

-- Passwort ändern
ALTER USER Student07 IDENTIFIED BY System01;

-- Rolle erstellen und Rechte vergeben
DROP ROLE StudentRole;
CREATE ROLE StudentRole;
GRANT CREATE session, CREATE table, CREATE view,
      CREATE synonym, CREATE procedure, CREATE trigger
TO StudentRole;
GRANT StudentRole TO Student07;

-- Objektprivilegien (direkt, nicht empfohlen)
GRANT SELECT ON Tabelle13 TO Student07, Student08;
GRANT INSERT, SELECT ON Student03.TabelleA TO Student07;
GRANT ALL ON database TO dba_user02;

-- Spalten-basierte Rechte
GRANT UPDATE (Spalte1), INSERT (Spalte2, Spalte3)
ON Tabelle52 TO Student07;

Befehle: Nur GRANT (Rechte vergeben) und REVOKE (Rechte entziehen).

8.7 Backup

Definition

Backup (Datensicherung) = Speicherung der Daten, mit der ein System nicht direkt arbeitet.

Eigenschaften:

Kann mehrere Dateien und Verzeichnisse beinhalten
Kann wie eine oder mehrere Dateien aussehen
Kann verschlüsselt und/oder komprimiert sein
Kann sich über mehrere Datenträger verbreiten

Backup-Archiv = Sammlung von mehreren Backups.

Zwecke:

Wiederherstellung nach Absturz
Wiederherstellung eines bestimmten Zeitpunkts für Statistik (z. B. Jahresbericht)
Wiederherstellung für planmäßige Funktionalität (z. B. Forschungsprojekte)

Regel: In allen nicht privaten Systemen muss man immer Backup planen und regelmäßig durchführen.

RAID

RAID (Redundant Array of Inexpensive/Independent Disks) ist kein Backup!

Eigenschaft	Beschreibung
Funktion	Redundante Speicherung auf mehreren Festplatten
Bei Ausfall	Daten können von anderer Platte gelesen/geschrieben werden
Hot-Swap	Kaputte Platte im laufenden Betrieb austauschbar
Software-RAID	Von fast allen Betriebssystemen unterstützt
Hardware-RAID	Betriebssystemunabhängig

RAID erfüllt keine Backup-Funktionen
RAID kann als Speicherort für Backup verwendet werden

Oracle Backup-Tools

Tool	Beschreibung
exp/imp	Ältere Versionen
expdp/impdp	Neuere Versionen (Data Pump)
RMAN	Recovery Manager

Weitere Tools: Linux (cp, tar, bzip, gzip, dd), Windows (copy, Server-Sicherung), Drittanbieter (Acronis, Paragon, Fwbackups, Bacula).

Backup-Medien

Medium	Beschreibung
DAS	Direct Attached Storage (lokale Festplatte)
NAS	Network Attached Storage (Netzwerk)
SAN	Storage Area Network (Netzwerk)
Magnetband	Bandlaufwerk mit Roboter, bis zu 4 GiB
CD/DVD/Blu-Ray	Optische Medien
USB-Geräte	Externe Speicher
FireWire-Geräte	Externe Speicher
Cloud	Sicherheit bedenklich

Generationsprinzip (Großvater-Vater-Sohn):

3 Datenträger rotierend: 1. Sicherung → Großvater, 2. → Vater, 3. → Sohn
1. Sicherung: Großvater wird zum Sohn überschrieben, Rollen rotieren
Je mehr Datenträger, desto sicherer

Backup-Methoden

Methode	Beschreibung
Online/Hot Backup	DB läuft weiter, Daten werden im laufenden Betrieb gesichert; Gefahr: nicht-konsistenter Zustand; DB liefert spezifische Lösungen
Offline/Cold Backup	DB wird heruntergefahren, geschlossene Dateien kopiert; Datenbestand ist immer konsistent

Sicherungsarten

Art	Umfang	Markierung?	Wiederherstellung	Vorteil/Nachteil
Normal	Alle ausgewählten Daten	Ja (als gesichert)	Nur diese Sicherung	Einfach, aber groß
Kopie	Wie Normal	Nein	—	Keine Auswirkung auf andere Strategien
Täglich	Nur heute geänderte Daten	Ja	—	Klein, tagesbezogen
Inkrementell	Nur seit letzter Sicherung geänderte Daten	Ja	Letzte Normal + alle Inkrementellen in Reihenfolge	Wenig Zeit/Speicher, aber aufwändige Wiederherstellung
Differenziell	Nur seit letzter normaler Sicherung geänderte Daten	Nein	Letzte Normal + letzte Differenzielle	Einfache Wiederherstellung, aber wachsende Größe

Sicherungsstrategien

Strategie	Beispiel
Nur normale Sicherungen	Monatlich
Normal + Inkrementell	Jährlich normal, monatlich inkrementell
Normal + Differenziell	Jährlich normal, monatlich differenziell

Wichtig: Anforderungen des Unternehmens und Speicherbedarf müssen berücksichtigt werden.

9. Data Warehouse Konzepte (i_DWKonzepte)

9.1 Konzepte

Drei Verarbeitungsarten:

Batch-Verarbeitung – klassische Stapelverarbeitung
OLTP = Online Transaction Processing – Tagesgeschäft
OLAP = Online Analytical Processing – Analyse und Auswertung

OLAP-Systeme sind unverzichtbare Instrumente zur Analyse umfangreicher und mehrdimensionaler Daten. Sie gewähren anwendungsspezifische Sichten und werden primär von Managern unterschiedlicher Ebenen verwendet.

9.2 OLAP

Gründe für OLAP:

Trennung von Tagesgeschäft und Auswertungen
Historisierte Daten mit Zeitraum-Bezug
Große Mengen von Nur-Lese-Daten (Permanenz)
Multidimensionale Datenmodelle
Gezielte Denormalisierung des ganzen Modells

Eigenschaften von OLAP:

Intuitive und interaktive Analyse der Daten
Flexible Darstellung aus unterschiedlichen Perspektiven
Basis: Hypercube (kartesisches Produkt)
Besondere Operationen: Rotation, Slice, Dice, Drill-Through, Drill-Across, Roll-Up, Drill-Down
Clients: Spezielle Programme oder Tabellenkalkulationstools (z.B. Excel)

Data Warehouse als OLAP-Datenbank dient:

Unterstützung strategischer Entscheidungen
Analyse von Tendenzen und Mustern über große Zeiträume
Bessere Entscheidungen durch bessere Informationen
Flexiblere Analysemöglichkeiten
Verlagerung der Analyse in Fachabteilungen
Geringere Berichterstellungskosten
Gemeinsame Informationsbasis im Unternehmen

9.3 ROLAP, MOLAP, HOLAP

ROLAP – Relationales OLAP

Basiert auf relationalen Datenbanken (Oracle, DB2)
Verwendet Star-Schema (Fakten- und Dimensionstabellen, 3NF bei Dimensionstabellen verletzt) und Snowflake-Schema (normalisiert)
Für hohes Datenvorkommen und große Nutzerzahlen geeignet

Vorteile:

Bewährte relationale Technologien für Abfragen, Verwaltung, Speicherung, Recovery, Archivierung
Sperrmechanismen und Transaktionen nicht benötigt

Nachteile:

Umfangreiche JOINs, Indizes, Table Scans nötig
Umfangreiche Aggregationen und Berechnungen

MOLAP – Multidimensionales OLAP

Basiert auf herstellerspezifischen Datenbanken
Optimiert für hohe Performance in multidimensionalen Datenstrukturen
Schnelle Aggregationen

Vorteile:

Hohe Performance
Am multidimensionalen Modell ausgerichtet

Nachteile:

Hoher Schulungsaufwand
Proprietäre Verwaltung
Oft fehlende Standardschnittstellen

HOLAP – Hybrides OLAP

Variante aus ROLAP und MOLAP.

9.4 Lebenszyklus eines Data Warehouse

Schritt A – Planung:

Analyse von Architektur und Infrastruktur
Definition der Ressourcen und Zeitvorgaben
Archivierungsstrategien
Verbindungsmöglichkeiten und Ladeprogramme

Schritt B – Spezifikation & Modellierung:

Ermittlung der Entitäten und Attribute
Geschäftsprozesse und -anwendungsfälle identifizieren
Ein-/Ausgabedaten und Detailierungsgrad festlegen
Logisches Datenmodell entsteht

Schritt C – Physischer Datenbankentwurf:

Star-Schema / Snowflake-Schema entwerfen
Aufheben der Normalisierung
Schlüssel, Indizierungsstrategien, Partitionierung festlegen

Schritt D – Befüllen des DWH:

Definition der Quellsysteme
Umformungsspezifikationen
Aktualisierungszyklus festlegen
ETL-Prozeduren definieren und testen
Automatisierung der Ladevorgänge, Backup- und Recovery-Prozeduren
Anwendungsentwicklung (Berichte, Dokumentation, Test)

Schritt E – Betrieb:

Test und Überprüfung der Daten
Schulung, Produktabnahme, Wartung
Verbesserungen und Weiterentwicklung
Performance-Untersuchungen

9.5 Vergleich OLTP und OLAP

Merkmal	OLTP	OLAP
Abfragen	Vorhersehbar, einzelne Datensätze	Komplex, unvorhersehbar
Daten	Ständige Änderungen	Statisch, unveränderbar
Datenstruktur	Normalisiertes Modell (nur notwendige Redundanz)	Denormalisiertes Modell (verständlich)
Fokus	Hohe Transaktionsrate	Aggregation – viele Fakten zu einem Fakt

9.6 ETL – Extract, Transform, Load

Extraktion

Periodischer, ereignisgesteuerter oder anfragegesteuerter Abzug
Komplette oder Delta-Übertragungen
Protokollierung der Änderungen und Übertragungen

Transformation (im Arbeitsbereich)

Datentypkonvertierung
Wertumsetzung
Schlüsselvergabe, -anpassung, -bereinigung
Zeitstempelvergabe
Datenverdichtung, -bereinigung

Laden

Übertragung der Daten aus dem Arbeitsbereich in das Data Warehouse

9.7 Hypercube-Operationen

Grundlage: Mehrdimensionaler Hypercube mit Dimensionen wie Zeitperioden, Produkte, Abteilungen und Werten wie Absatzvolumen.

Navigationsoperationen

Operation	Beschreibung
Rotation	Auswahl zweier konkreter Dimensionen (Drehung des Würfels)
Slice	Voller zweidimensionaler Ausschnitt aus dem Würfel
Dice	Mehrdimensionaler Ausschnitt (Untermenge, kleiner Würfel)
Drill-Across	Verbindung mehrerer Würfel gleicher Dimension zu einer Kette

Operation	Beschreibung
Drill-Down	Von oberer zu tieferer Ebene der Hierarchie
Roll-Up	Von tieferer zu oberer Ebene der Hierarchie
Drill-Through	Wenn Drill-Down nicht mehr möglich, wird neue Datenquelle (Würfel) angeschlossen

9.8 Varianten

Data Marts – Begrenzter Anwendungsbereich (z.B. eine Abteilung). Einfacher einzurichten als DWH, aber Konsistenzprobleme bei mehreren Data Marts
Operation Data Stores – Für aktuelle (tägliche) Auswertungen, unterstützen kaum langfristige Abfragen

10. Andere Typen von Datenbanken (j_AndereDB)

10.1 Hierarchische Datenbanken

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

10.2 Netzartige Datenbanken

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

10.3 Verteilte Datenbanken

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:

Fragmentierungsschema erstellen
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

10.4 Objektorientierte Datenbanken

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

10.5 No-SQL-Datenbanken (Not only SQL)

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

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. Relationale DB bleiben wichtig für Anwendungen mit strengen Konsistenz-/Sicherheitsanforderungen.

11. Gesamtübersicht & Cheat-Sheet

11.1 Datenbankentwicklungsprozess (Phasenmodell)

Anforderungsanalyse
    ↓
Konzeptueller Entwurf  →  ERM (Peter-Chen-Notation)
    ↓
Logischer Entwurf      →  Relationale Tabellen (Konvertierungsregeln)
    ↓
Normalisierung         →  1NF → 2NF → 3NF → BCNF → 4NF → 5NF
    ↓
Physischer Entwurf     →  Tablespaces, Indizes, Storage-Parameter
    ↓
Implementierung        →  SQL (DDL + DML) + Constraints + Trigger
    ↓
Betrieb                →  Transaktionen, Backup, Rechte, Monitoring

11.2 ERM → Relationale Tabellen – Kurzreferenz

ERM-Element	Konvertierungsregel
Entitätstyp	Eigene Tabelle; alle Attribute inkl. PK
N:M-Beziehung	Eigene Beziehungstabelle; PKs beider Seiten = PK der Beziehungstabelle
1:N-Beziehung	Kein eigene Tabelle; PK der 1-Seite als FK in die N-Seite
1:1-Beziehung	Option A: Zusammenführen; Option B: FK in eine der Tabellen
Schwache Entität	Eigene Tabelle; PK der starken Entität wird Teil des PK
Generalisierung	Obertyp-Tabelle + je eine Untertyp-Tabelle (PK des Obertyps als FK)
Mehrwertige Attribute	Eigene Tabelle + 1:N-Beziehung zur Entitätstabelle

11.3 Normalformen – Kurzreferenz

NF	Verletzung erkennen	Lösung
1NF	Zelle enthält mehrere Werte / Liste	Aufteilen in separate Zeilen oder Tabelle
2NF	Nicht-PK-Feld hängt nur von Teil des zusammengesetzten PK ab	Auslagern in neue Tabelle mit Teilschlüssel als PK
3NF	Nicht-PK-Feld hängt von einem anderen Nicht-PK-Feld ab (transitive Abhängigkeit)	Auslagern; abhängiges Feld wird PK neuer Tabelle
BCNF	Teil eines Schlüsselkandidaten hängt von Teil eines anderen Schlüsselkandidaten ab (Überlappung)	Aufteilen nach Schlüsselkandidaten
4NF	Nicht-PK-Felder sind semantisch unabhängig (unterschiedliche Verwendungshäufigkeit)	Nach Semantik trennen
5NF	Tabelle kann verlustfrei in kleinere Tabellen zerlegt werden	Vollständig zerlegen (JOIN-Rekonstruktion muss möglich sein)

11.4 Relationale Algebra – Vollständiger Operatorensatz

Operator	Notation	SQL	Grundoperator
Selektion	σ_P(R)	WHERE P	Ja
Projektion	π_A(R)	SELECT A	Ja
Kartesisches Produkt	R₁ × R₂	CROSS JOIN	Ja
Umbenennung	ρ_alias(R)	AS alias	Ja
Vereinigung	R₁ ∪ R₂	UNION	Ja
Differenz	R₁ — R₂	MINUS / EXCEPT	Ja
Schnittmenge	R₁ ∩ R₂	INTERSECT	Nein (= R₁ — (R₁ — R₂))
Join (Theta/Inner)	R₁ ⋈_P R₂	INNER JOIN ... ON P	Nein (= σ_P(R₁ × R₂))
Natural Join	R₁ ⋈ R₂	NATURAL JOIN	Nein
Left Outer Join	R₁ ⟕ R₂	LEFT OUTER JOIN	Nein
Right Outer Join	R₁ ⟖ R₂	RIGHT OUTER JOIN	Nein
Full Outer Join	R₁ ⟗ R₂	FULL OUTER JOIN	Nein
Semi-JOIN L	L ⋉ R	SELECT L.* ... INNER JOIN	Nein
Anti-Semi-JOIN L	L ⊲ R	NOT IN / NOT EXISTS	Nein

11.5 SQL – Vollständige SELECT-Syntax

SELECT [DISTINCT] spalten | *              -- Projektion (π)
    [, aggregatfunktion(spalte) [AS alias]]
FROM   tabelle1 [alias1]                   -- Quellen (×)
    [JOIN tabelle2 ON bedingung]           -- Verbund (⋈)
    [(SELECT ...) AS inline_view]          -- Inline View
WHERE  filterbedingung                     -- Selektion (σ)
    [AND | OR | NOT weiteresBedingung]
    [AND spalte LIKE 'muster']
    [AND spalte IN (wert1, wert2)]
    [AND spalte IS [NOT] NULL]
GROUP BY gruppierungsspalten               -- Gruppierung
HAVING aggregatbedingung                   -- Gruppenfilter
ORDER BY sortierspalte [ASC | DESC];       -- Sortierung

11.6 Transaktionen – ACID und Isolationsstufen

Problem	Tritt auf bei	Gelöst durch
Lost Update	Zwei parallele Updates auf gemeinsamer Variable	SERIALIZABLE
Dirty Read	Lesen nicht-committeter Änderungen	READ COMMITTED (Oracle-Standard)
Non-Repeatable Read	Zweifaches Lesen liefert andere Werte	SERIALIZABLE
Phantom Read	Zweifaches COUNT liefert andere Anzahl	SERIALIZABLE

Isolationsstufe	Lost Update	Dirty Read	NR Read	Phantom	Oracle
READ UNCOMMITTED	✗	möglich	möglich	möglich	nicht verfügbar
READ COMMITTED	✗	verhindert	möglich	möglich	Standard
REPEATABLE READ	✗	verhindert	verhindert	möglich	nicht verfügbar
SERIALIZABLE	verhindert	verhindert	verhindert	verhindert	verfügbar

11.7 Speicherstrukturen – Oracle-Hierarchie

Datenbank
 └── Tablespace (eine pro Anwendung)
      └── Datenbankdatei (.dbf)
           └── Segment / Extent (erweiterbare Speichereinheit)
                └── Block (kleinste I/O-Einheit)

Arbeitsspeicher:
 ├── SGA (System Global Area)
 │    ├── Database-Buffer-Cache (aktuelle Datenblöcke)
 │    ├── Dirty List (geänderte, noch nicht geschriebene Blöcke)
 │    ├── Redo-Log-Buffer (Änderungsprotokoll für Crash-Recovery)
 │    ├── Shared Pool (SQL-Parsing, Data Dictionary)
 │    ├── Large Pool (Recovery Manager)
 │    └── Java Pool (Java-Anwendungen)
 ├── PGA (Program Global Area) – Prozesssteuerung
 └── UGA (User Global Area)   – Sitzungsdaten je Benutzer

11.8 Backup-Entscheidungsmatrix

Kriterium	Normal	Inkrementell	Differenziell	Kopie
Umfang	Alle ausgewählten Daten	Seit letzter Sicherung	Seit letzter Normal	Wie Normal
Als gesichert markiert?	Ja	Ja	Nein	Nein
Wiederherstellung	Diese Sicherung allein	Letzte Normal + alle Inkrementellen	Letzte Normal + letzte Differenzielle	—
Speicherbedarf	Hoch	Gering	Mittel	Hoch
Wiederherstellungsaufwand	Gering	Hoch	Mittel	—

11.9 OLTP vs. OLAP vs. Data Warehouse

Merkmal	OLTP	OLAP / DWH
Zweck	Tagesgeschäft	Analyse / Entscheidungsunterstützung
Abfragen	Vorhersehbar, einfach, einzelne Sätze	Komplex, ad-hoc, viele Zeilen
Daten	Ständige Änderungen	Statisch, historisiert, Nur-Lesen
Schema	Normalisiert (3NF)	Denormalisiert (Star/Snowflake)
Transaktionen	Häufig, kurz	Selten / keine
Benutzer	Viele operative Benutzer	Wenige Analytiker / Manager
Index-Typ	Konventionell (B-Tree)	Bitmap-Indizes (geringe Kardinalität)

11.10 No-SQL-Datenbanken – Vergleich

Typ	Struktur	Beispiele	Stärke	Schwäche
Document-Store	Dokumente (JSON/XML)	MongoDB, CouchDB	Flexibles Schema	Keine Normalisierung
Key-Value-Store	Schlüssel → Wert	Redis, DynamoDB, Berkeley DB	Extrem schnell	Keine komplexen Beziehungen
Wide-Column-Store	Spaltenorientiert, schemafrei	Cassandra, Azure Cosmos DB	Milliarden Felder, Big Data	Kein festes Schema
XML-Datenbank	XML + XPath	BaseX	Dokumentverarbeitung	Kein COMMIT/ROLLBACK
Graph-Datenbank	Knoten + Kanten	Neo4j u.a.	Beziehungsgeflechte	Keine einheitliche Abfragesprache
Relational	Tabellen, Normalisierung	Oracle, PostgreSQL, MySQL	ACID, SQL, Flexibilität	Skalierung bei extremen Datenmengen

11.11 Wichtige Begriffe – Schnellreferenz

Begriff	Definition
Relation	Untermenge des kartesischen Produkts mehrerer Datentypen = Tabelle
Tupel	Zeile / Datensatz in einer Relation
Attribut / Feld	Spalte in einer Relation
Schema	Namen aller Felder + Datentypen + Länge + Reihenfolge
Primärschlüssel (PK)	Minimaler Schlüssel, der Tupel eindeutig identifiziert
Fremdschlüssel (FK)	Attribut, das auf PK einer anderen Tabelle verweist
Kardinalität	Anzahl der Tupel in einer Relation
Grad	Anzahl der Attribute einer Relation
Funktionale Abhängigkeit	X → Y: X bestimmt Y eindeutig
Transaktion	Atomare Folge von Operationen (alles oder nichts)
ACID	Atomicity, Consistency, Isolation, Durability
BASE	Basically Available, Soft State, Eventually Consistent
Deadlock	Zwei Transaktionen warten gegenseitig aufeinander
Serialisierbarkeit	Parallele Ausführung entspricht in der Wirkung einer seriellen
ETL	Extract, Transform, Load (Befüllung eines DWH)
OLTP	Online Transaction Processing (Tagesgeschäft)
OLAP	Online Analytical Processing (Analyse)
Hypercube	Mehrdimensionaler Datenwürfel als Basis für OLAP
Tablespace	Logischer Container für Datenbankobjekte in Oracle
Redo-Log	Protokoll durchgeführter Änderungen (für Crash-Recovery)
Rollback-Segment	Speicher für Datenzustand vor Änderungen (für UNDO)

105 KiB Raw Blame History Unescape Escape

Datenbanken – Gesamtzusammenfassung

Inhaltsverzeichnis

1. Modellierung (b_Modellierung)

1.1 Einführung

Definitionen

Modellierung

Datenhaltung

Architektur

Datenbankbenutzer

Entwicklung

Arten von Datenbanken

1.2 Codds 12 Regeln

1.3 Mengenlehre (b_Mengenlehre)

Definition (G. Cantor, 1895)

Eigenschaften einer Menge

Quantoren

Operationen über Mengen

Zahlenmengen

Dimensionen

Relevanz für Datenbanken

1.4 ANSI-SPARC-Modell (Drei-Schichten-Architektur)

1.5 Phasen des Datenbankentwurfs

1.6 Anforderungsanalyse

1.7 Konzeptueller Entwurf – Entity-Relationship-Modell (ERM)

Modellierungsstrukturen in Peter-Chen-Notation

Entitätstypen

Beziehungstypen

Attribute

Schlüssel und Primärschlüssel

Rekursive Beziehungen

Funktionalitäten

(min,max)-Notation

Mehrstellige Beziehungen

Spezielle Konzepte

1.8 Logischer Entwurf – Konvertierung ERM → Tabellen

Definitionen

Konvertierungsregeln

Vereinfachung der Darstellungen

Beispiel: Uni-Schema als Tabellen

Wichtige Bemerkung

2. Modellierung – Fallbeispiel (b_ModellierungFB)

Überblick

Identifizierte Entitätstypen

Mini-Welt 1

Mini-Welt 2

Vergleich der Mini-Welten

3. Relationale Algebra (c_Algebra)

Formale Sprachen für Relationen

Grundoperatoren (vollständiger Satz)

Operatoren im Detail

Selektion σ

Projektion π

Zusammenhang Algebra ↔ SQL

Reihenfolge der Operatoren

Umbenennung ρ

Vereinigung ∪

Differenz —

Schnittmenge ∩

Kartesisches Produkt × und Join

Zusammenfassung Operatoren

4. SQL (d_SQL)

4.1 SQL-Kategorien

4.2 Datentypen

Oracle-Datentypen

4.3 Einfache Befehle

DDL – Tabellen anlegen und löschen

DML – Einfügen, Löschen, Ändern

Inline-View

Allgemeine SELECT-Syntax

4.4 Erweiterungen

Sortieren

Duplikate eliminieren

Platzhalter (nur mit LIKE)

IN / NOT IN

ALL / ANY

Aggregatfunktionen

GROUP BY

HAVING

NULL-Werte

105 KiB

Raw Blame History