mirror of
https://github.com/theoleuthardt/hwr-notes.git
synced 2026-06-06 01:01:08 +00:00
docs: add obsidian hwr docs
This commit is contained in:
theoleuthardt
parent
b2636f4b92
commit
850aa3455d
245 changed files with 30757 additions and 0 deletions
2721
Datenbanken/Zusammenfassungen/Gesamtzusammenfassung.md
Normal file
2721
Datenbanken/Zusammenfassungen/Gesamtzusammenfassung.md
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,417 @@
|
|||
# Modellierung – Zusammenfassung
|
||||
**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–112**
|
||||
|
||||
---
|
||||
|
||||
## 1. Einführung (Folien 1–32)
|
||||
|
||||
### 1.1 Definitionen (Folien 3–6)
|
||||
|
||||
**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
|
||||
|
||||
### 1.2 Modellierung (Folien 7–9)
|
||||
|
||||
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:**
|
||||
1. **Richtigkeit** — Nicht beweisbar, nur durch Experimente überprüfbar und widerlegbar
|
||||
2. **Zulässigkeit** — Logisch eindeutig formuliert, ohne Widersprüche
|
||||
3. **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.
|
||||
|
||||
### 1.3 Datenhaltung (Folien 10–14)
|
||||
|
||||
Zwei grundsätzliche Formen:
|
||||
1. **Herkömmliche Form (Dateien):** Datenverwaltung in die Anwendung integriert → enormer Entwicklungsaufwand, kaum Datenaustausch
|
||||
2. **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
|
||||
|
||||
### 1.4 Architektur (Folien 15–18)
|
||||
|
||||
**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
|
||||
|
||||
### 1.5 Datenbankbenutzer (Folien 19–20)
|
||||
|
||||
| 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 |
|
||||
|
||||
### 1.6 Entwicklung (Folien 21–24)
|
||||
|
||||
- **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).
|
||||
|
||||
### 1.7 Arten von Datenbanken (Folien 25–28)
|
||||
|
||||
| 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.8 Prinzipien von E.F. Codd (Folien 29–32)
|
||||
|
||||
Die **12 Regeln von Codd** definieren eine relationale Datenbank:
|
||||
|
||||
1. Vollständige Verwaltung über relationale Fähigkeiten
|
||||
2. **Darstellung von Informationen:** Alle Informationen als Werte in Tabellen
|
||||
3. **Zugriff auf Daten:** Über Tabellenname + Primärschlüssel + Spaltenname
|
||||
4. **Systematische Behandlung von Nullwerten:** Durchgängig gleich als unbekannt/fehlend
|
||||
5. **Struktur:** Systemkatalog auf derselben logischen Ebene wie die Daten
|
||||
6. **Abfragesprache:** Mindestens eine Sprache mit vollständigem Befehlssatz (DDL, DML, Integrität, Autorisierung, Transaktionen)
|
||||
7. **Aktualisieren von Sichten:** Theoretisch aktualisierbare Sichten müssen vom System aktualisierbar sein
|
||||
8. **Abfragen und Bearbeiten:** Unterstützung für Einfügen, Aktualisieren und Löschen ganzer Tabellen
|
||||
9. **Physikalische Datenunabhängigkeit:** Logischer Zugriff unabhängig von physikalischen Methoden
|
||||
10. **Logische Datenunabhängigkeit:** Tabellenstruktur-Änderungen ohne Einfluss auf Anwendungslogik
|
||||
11. **Unabhängigkeit der Integrität:** Integritätsregeln in der DB-Sprache definierbar, nicht umgehbar
|
||||
12. **Verteilungsunabhängigkeit:** Logischer Zugriff unverändert bei verteilten Datenbanken
|
||||
|
||||
---
|
||||
|
||||
## 2. Mengenlehre (Folie 33)
|
||||
|
||||
Die Mengenlehre bildet die mathematische Grundlage der Theorie relationaler Datenbanken. Behandelt in separatem Skript (b_Mengenlehre). Themen: Definition, Eigenschaften, Operationen, Zahlenmengen, Dimensionen.
|
||||
|
||||
---
|
||||
|
||||
## 3. ANSI-SPARC-Modell (Folien 34–38)
|
||||
|
||||
### 3.1 Drei-Schichten-Architektur (Folien 35–37)
|
||||
|
||||
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 |
|
||||
|
||||
### 3.2 Phasen des Datenbankentwurfs (Folie 38)
|
||||
|
||||
1. **Anforderungsanalyse** → Spezifikation (Pflichtenheft)
|
||||
2. **Konzeptueller Entwurf** → Konzeptuelles Schema (ERM)
|
||||
3. **Logischer Entwurf** → Logisches Schema (Tabellen)
|
||||
4. **Physischer Entwurf** → Physisches Schema (Datenträger)
|
||||
|
||||
---
|
||||
|
||||
## 4. Anforderungsanalyse (Folien 39–50)
|
||||
|
||||
### 4.1 Kurzfassung (Folien 40–42)
|
||||
|
||||
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:**
|
||||
1. Identifikation von Organisationseinheiten
|
||||
2. Identifikation der zu unterstützenden Aufgaben
|
||||
3. Anforderungs-Sammelplan (zu befragende Personen)
|
||||
4. Anforderungs-Sammlung
|
||||
5. Filterung (Verständigkeit und Eindeutigkeit prüfen)
|
||||
6. Satzklassifikationen (Objekte, Beziehungen, Operationen, Ereignisse)
|
||||
7. Formalisierung/Systematisierung (ins Pflichtenheft übertragen)
|
||||
|
||||
**Ergebnisse der Anforderungsanalyse:**
|
||||
- **Informationsanforderungen:** Beschreibung von Objekten/Attributen und Beziehungen/Attributen
|
||||
- **Datenverarbeitungsanforderungen:** Beschreibung von Prozessen
|
||||
|
||||
### 4.2 Beispiel: Universitätsschema (Folien 43–46)
|
||||
|
||||
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
|
||||
|
||||
### 4.3 Beispiel: Krankenhaus-Modell (Folien 47–50)
|
||||
|
||||
Objekte: Ärzte, Pflegepersonal, Patienten mit deren Beziehungen (behandelt, betreut) und Prozessen (Behandlungsplan erstellen).
|
||||
|
||||
---
|
||||
|
||||
## 5. Konzeptueller Entwurf (Folien 51–87)
|
||||
|
||||
### 5.1 Entity-Relationship-Modell (ERM) (Folien 51–54)
|
||||
|
||||
Auf Basis der Anforderungsanalyse wird ein konzeptuelles ERM erstellt. Das konkrete DBMS wird noch nicht betrachtet.
|
||||
|
||||
**Beispiele:**
|
||||
- **Uni-Schema:** Studenten, Vorlesungen, Professoren, Assistenten mit Beziehungen hören, prüfen, lesen, arbeitenFür, voraussetzen
|
||||
- **Krankenhaus-Schema:** Arzt, Patient, Pflegepersonal mit Beziehungen behandelt, betreut
|
||||
|
||||
### 5.2 Modellierungsstrukturen in Peter-Chen-Notation (Folie 55)
|
||||
|
||||
| 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 |
|
||||
|
||||
### 5.3 Entitätstypen (Folie 56)
|
||||
|
||||
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.
|
||||
|
||||
### 5.4 Beziehungstypen (Folie 57)
|
||||
|
||||
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.
|
||||
|
||||
### 5.5 Attribute (Folien 58–62)
|
||||
|
||||
**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) |
|
||||
|
||||
### 5.6 Schlüssel und Primärschlüssel (Folien 63–65)
|
||||
|
||||
- **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
|
||||
|
||||
### 5.7 Rekursive Beziehungen (Folie 66)
|
||||
|
||||
Beziehungen zwischen Entitäten desselben Entitätstyps. Dabei werden **Rollen** zugeschrieben.
|
||||
|
||||
**Beispiele:**
|
||||
- Vorlesungen → voraussetzen (Vorgänger/Nachfolger)
|
||||
- Softwareprodukt → Versionsnummer
|
||||
- Polizisten → im Zweierteam patrouillieren
|
||||
|
||||
### 5.8 Funktionalitäten (Folien 67–76)
|
||||
|
||||
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).
|
||||
|
||||
### 5.9 (min,max)-Notation (Folien 77–78)
|
||||
|
||||
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
|
||||
|
||||
### 5.10 Mehrstellige Beziehungen (Folien 79–80)
|
||||
|
||||
- **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
|
||||
|
||||
### 5.11 Spezielle Konzepte (Folien 82–87)
|
||||
|
||||
#### Komposition / Schwache Entitäten (Folie 83)
|
||||
Existenz eines Entitätstyps ist von der Existenz eines anderen abhängig (**has-a**).
|
||||
- Beispiel: Konto existiert nur in Zusammenhang mit einer Bank
|
||||
|
||||
#### Generalisierung (Folien 84–86)
|
||||
Abstraktion auf Ebene der Entitätstypen (**is-a**). 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 (Folie 87)
|
||||
Verschiedene Entitätstypen bilden in ihrer Gemeinsamkeit einen neuen Entitätstyp (**has-a**).
|
||||
- Beispiel: Fahrrad besteht aus Rahmen (Rohre, Lenker) und Rad (Speiche, Felge)
|
||||
|
||||
---
|
||||
|
||||
## 6. Logischer Entwurf (Folien 88–112)
|
||||
|
||||
### 6.1 Definitionen (Folien 89–90)
|
||||
|
||||
- **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
|
||||
|
||||
### 6.2 Relationale Darstellung (Folien 91–93)
|
||||
|
||||
**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.
|
||||
|
||||
### 6.3 Konvertierungsregeln ERM → Relational (Folie 93)
|
||||
|
||||
**Regeln für Entitätstypen:**
|
||||
1. Neue Tabelle (Entitäts-Tabelle) bilden
|
||||
2. Alle Attribute des Entitätstyps inkludieren
|
||||
|
||||
**Regeln für Beziehungstypen:**
|
||||
1. Neue Tabelle (Beziehungs-Tabelle) bilden
|
||||
2. Primärschlüssel aller verbundenen Entitätstypen inkludieren → bilden i.d.R. den PK der Beziehungstabelle
|
||||
3. Attribute des Beziehungstyps inkludieren
|
||||
|
||||
### 6.4 Vereinfachung der Darstellungen (Folien 94–106)
|
||||
|
||||
#### 1:1-Beziehungen (Folien 95–97)
|
||||
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 (Folien 98–99)
|
||||
- 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 (Folien 100–101)
|
||||
- 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)
|
||||
|
||||
### 6.5 Beispiel: Uni-Schema als Tabellen (Folien 102–103)
|
||||
|
||||
| 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 |
|
||||
|
||||
### 6.6 Wichtige Bemerkung (Folien 109–111)
|
||||
|
||||
**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)
|
||||
|
||||
Im Unterricht wird auf diese Meinung verzichtet (Verständnis halber), obwohl sie in der Wirtschaft sehr verbreitet ist.
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung der Kernthemen
|
||||
|
||||
| Thema | Kernaussage |
|
||||
|---|---|
|
||||
| Datenbank vs. Dateien | DB bietet Redundanzvermeidung, Mehrbenutzerbetrieb, Zugriffskontrolle |
|
||||
| Codds 12 Regeln | Definieren eine relationale DB im strengen Sinne |
|
||||
| ANSI-SPARC-Modell | Drei Ebenen: extern, konzeptionell, intern → Datenunabhängigkeit |
|
||||
| Anforderungsanalyse | Objekt-, Beziehungs- und Prozessbeschreibungen erstellen |
|
||||
| ERM – Peter-Chen | Entitäten (Rechteck), Beziehungen (Raute), Attribute (Oval), Schlüssel (unterstrichen) |
|
||||
| Funktionalitäten | 1:1, 1:N, N:M; (min,max)-Notation für genaue Kardinalitäten |
|
||||
| Spezielle Konzepte | Komposition (has-a, schwache Entität), Generalisierung (is-a), Aggregation (has-a) |
|
||||
| Logischer Entwurf | ERM → Tabellen; Vereinfachung bei 1:1 und 1:N durch Wegfall der Beziehungstabelle |
|
||||
| Fremdschlüssel | Bei 1:N wird PK der 1-Seite als FK in die N-Seite eingefügt |
|
||||
|
|
@ -0,0 +1,157 @@
|
|||
# Modellierung – Fallbeispiel – Zusammenfassung
|
||||
**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–16**
|
||||
|
||||
---
|
||||
|
||||
## 1. Überblick (Folie 1)
|
||||
|
||||
Das Fallbeispiel behandelt die **Modellierung einer Rechnung** und folgt dem Schema:
|
||||
1. Beispiel-Rechnungen betrachten
|
||||
2. Mini-Welten beschreiben
|
||||
3. Konzeptuellen Entwurf für jede Mini-Welt erstellen
|
||||
4. Logischen Entwurf für jede Mini-Welt erstellen
|
||||
5. Fazit
|
||||
|
||||
---
|
||||
|
||||
## 2. Beispiel-Rechnungen (Folien 2–5)
|
||||
|
||||
Es werden verschiedene reale Rechnungen als Ausgangspunkt gezeigt, aus denen die relevanten Entitätstypen und Beziehungen abgeleitet werden.
|
||||
|
||||
---
|
||||
|
||||
## 3. Mini-Welten – Entitätstypen (Folien 6–8)
|
||||
|
||||
Aus den Rechnungen werden **mindestens 3 Entitätstypen** identifiziert:
|
||||
|
||||
### 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)
|
||||
|
||||
**Hinweis:** Kundeninformation wird bewusst vernachlässigt. Es gibt viele abgeleitete Attribute.
|
||||
|
||||
### Formale Notation
|
||||
|
||||
Entitätstypen als Mengen:
|
||||
```
|
||||
E = { e } = { [ Attr1, Attr2, ..., AttrN ] }
|
||||
```
|
||||
|
||||
**Feste Entitätstypen (in beiden Mini-Welten gleich):**
|
||||
```
|
||||
Rechnung = { [ RgNr, Datum, Gesamtpreis, GesamtMwSt ] }
|
||||
Artikel = { [ ArtNr, ArtBezeichnung, EP, MwStSatz ] }
|
||||
```
|
||||
|
||||
**Beziehungen:**
|
||||
- Rechnung **besteht aus** Rechnungspositionen
|
||||
- Rechnungsposition **beinhaltet** Artikel
|
||||
|
||||
---
|
||||
|
||||
## 4. Mini-Welt 1 (Folien 9–11)
|
||||
|
||||
### Ansatz
|
||||
Alle Rechnungen werden **durchgehend** betrachtet. Gleiche Kombinationen [RechnPosNr, Menge] werden **zusammengefasst** (laut Mengenlehre nach G. Cantor: keine doppelten Elemente).
|
||||
|
||||
**Beispiel:** Wenn in Rechnung A die erste Zeile 2 Tastaturen enthält und in Rechnung B die erste Zeile 2 Drucker, ist für beide nur ein Element [1, 2] zuständig.
|
||||
|
||||
```
|
||||
Rechnungsposition = { [ RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
|
||||
```
|
||||
|
||||
### Konzeptueller Entwurf (Folie 10)
|
||||
|
||||
| Beziehung | Funktionalität |
|
||||
|---|---|
|
||||
| Rechnung — besteht aus — Rechnungsposition | **M : N** |
|
||||
| Rechnungsposition — beinhaltet — Artikel | **N : 1** |
|
||||
|
||||
### Logischer Entwurf (Folie 11)
|
||||
|
||||
```
|
||||
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 ] }
|
||||
```
|
||||
Dabei wird ArtNr als Fremdschlüssel eingefügt.
|
||||
|
||||
---
|
||||
|
||||
## 5. Mini-Welt 2 (Folien 12–14)
|
||||
|
||||
### Ansatz
|
||||
**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** (anders als in Mini-Welt 1, wo sie verloren geht).
|
||||
|
||||
```
|
||||
Rechnungsposition = { [ LfndNr, RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
|
||||
```
|
||||
|
||||
### Konzeptueller Entwurf (Folie 13)
|
||||
|
||||
| Beziehung | Funktionalität |
|
||||
|---|---|
|
||||
| Rechnung — besteht aus — Rechnungsposition | **1 : N** |
|
||||
| Rechnungsposition — beinhaltet — Artikel | **N : 1** |
|
||||
|
||||
### Logischer Entwurf (Folie 14)
|
||||
|
||||
```
|
||||
Rechnung = { [ RgNr, Datum, Gesamtpreis, GesamtMwSt ] }
|
||||
Artikel = { [ ArtNr, EP, MwStSatz, ArtBezeichnung ] }
|
||||
Rechnungsposition = { [ LfndNr, RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
|
||||
besteht_aus = { [ RgNr, LfndNr ] }
|
||||
beinhaltet = { [ ArtNr, LfndNr ] }
|
||||
```
|
||||
|
||||
**Vereinfachung** (beide 1:N-Beziehungen auflösen):
|
||||
```
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## 6. Fazit (Folie 15)
|
||||
|
||||
Beide Mini-Welten bilden den Sachverhalt ab. Welches Modell besser ist, hängt von den zuvor angeforderten Kriterien ab (z. B. Leistung/Geschwindigkeit).
|
||||
|
||||
**Empfehlung:**
|
||||
- Beide Modelle implementieren
|
||||
- Antwortzeiten bei größerem Datenumfang vergleichen
|
||||
- Häufigste Abfragen vergleichen, seltene ebenfalls
|
||||
|
||||
---
|
||||
|
||||
## 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) |
|
||||
205
Datenbanken/Zusammenfassungen/c_Algebra - zusammenfassung.md
Normal file
205
Datenbanken/Zusammenfassungen/c_Algebra - zusammenfassung.md
Normal file
|
|
@ -0,0 +1,205 @@
|
|||
# Relationale Algebra – Zusammenfassung
|
||||
**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–16**
|
||||
|
||||
---
|
||||
|
||||
## 1. Definitionen (Folien 1–3)
|
||||
|
||||
### Formale Sprachen für Relationen
|
||||
|
||||
Es gibt zwei formale Sprachen für die Behandlung von 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** (Structured Query Language).
|
||||
|
||||
**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.
|
||||
|
||||
---
|
||||
|
||||
## 2. Operatoren im Detail (Folien 4–15)
|
||||
|
||||
### 2.1 Selektion σ (Folie 4)
|
||||
|
||||
Filtert Zeilen einer Relation anhand eines Prädikats. Das Prädikat wird für **jede Zeile** geprüft.
|
||||
|
||||
**Beispiele:**
|
||||
```
|
||||
σ_{Semester > 10}(Studenten)
|
||||
→ Ergebnis: MatrNr 24002 (Xenokrates, 18), MatrNr 25403 (Jonas, 12)
|
||||
|
||||
σ_{Name = 'Sokrates'}(Professoren)
|
||||
→ Ergebnis: PersNr 2125, Sokrates, C4, Raum 226
|
||||
```
|
||||
|
||||
### 2.2 Projektion π (Folie 5)
|
||||
|
||||
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`).
|
||||
|
||||
### 2.3 Zusammenhang Algebra ↔ SQL (Folien 6–7)
|
||||
|
||||
| Relationale Algebra | SQL |
|
||||
|---|---|
|
||||
| **π** (Projektion) | **SELECT** |
|
||||
| **σ** (Selektion) | **WHERE** |
|
||||
|
||||
**Beispiele:**
|
||||
|
||||
| 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 (Folie 7)
|
||||
|
||||
**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!)
|
||||
```
|
||||
|
||||
### 2.4 Umbenennung ρ (Folie 8)
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
### 2.5 Vereinigung ∪ (Folien 9–10)
|
||||
|
||||
**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**.
|
||||
|
||||
```sql
|
||||
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] }
|
||||
```
|
||||
|
||||
### 2.6 Differenz — (Folien 11–13)
|
||||
|
||||
**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:**
|
||||
```sql
|
||||
-- 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;
|
||||
```
|
||||
|
||||
### 2.7 Schnittmenge ∩ (Folie 14)
|
||||
|
||||
Die Schnittmenge ist **kein Grundoperator**, kann aber abgeleitet werden:
|
||||
|
||||
```
|
||||
A ∩ B = A — (A — B) = B — (B — A)
|
||||
```
|
||||
|
||||
**SQL-Umsetzung:**
|
||||
```sql
|
||||
-- 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');
|
||||
```
|
||||
|
||||
### 2.8 Kartesisches Produkt × und Join (Folie 15)
|
||||
|
||||
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))
|
||||
```
|
||||
|
||||
Oder ausführlich mit expliziter Umbenennung:
|
||||
```
|
||||
π_{s.Name, v.Titel}(σ_{v.VorlNr=h.VorlNr ∧ h.MatrNr=s.MatrNr}(
|
||||
ρ_s(Studenten) × ρ_v(Vorlesungen) × ρ_h(hoeren)))
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
| 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 (σ + ×) |
|
||||
406
Datenbanken/Zusammenfassungen/d_SQL - zusammenfassung.md
Normal file
406
Datenbanken/Zusammenfassungen/d_SQL - zusammenfassung.md
Normal file
|
|
@ -0,0 +1,406 @@
|
|||
# SQL – Zusammenfassung
|
||||
**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–96**
|
||||
|
||||
---
|
||||
|
||||
## 1. Überblick (Folie 2)
|
||||
|
||||
SQL-Befehle sind in vier Kategorien unterteilt:
|
||||
|
||||
| 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 |
|
||||
|
||||
---
|
||||
|
||||
## 2. Datentypen (Folien 3–5)
|
||||
|
||||
**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) |
|
||||
|
||||
---
|
||||
|
||||
## 3. Einfache Befehle (Folien 6–11)
|
||||
|
||||
### DDL – Tabellen anlegen und löschen
|
||||
|
||||
```sql
|
||||
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
|
||||
|
||||
```sql
|
||||
-- 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:
|
||||
|
||||
```sql
|
||||
-- Professoren, die Assistenten haben
|
||||
SELECT p.Name, p.Raum
|
||||
FROM Professoren p,
|
||||
(SELECT DISTINCT Boss FROM Assistenten) a
|
||||
WHERE p.PersNr = a.Boss;
|
||||
```
|
||||
|
||||
### Allgemeine SELECT-Syntax (Folie 11)
|
||||
|
||||
```sql
|
||||
SELECT column1, column2
|
||||
FROM table1, table2
|
||||
WHERE condition
|
||||
GROUP BY column1, column2
|
||||
HAVING condition
|
||||
ORDER BY column1, column2;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Erweiterungen (Folien 12–14)
|
||||
|
||||
### Sortieren
|
||||
```sql
|
||||
SELECT PersNr, Name, Rang FROM Professoren
|
||||
ORDER BY Rang DESC, Name ASC;
|
||||
```
|
||||
|
||||
### Duplikate eliminieren
|
||||
```sql
|
||||
SELECT DISTINCT Rang FROM Professoren;
|
||||
```
|
||||
|
||||
### Platzhalter (nur mit LIKE)
|
||||
- `_` — genau ein Zeichen
|
||||
- `%` — beliebig viele Zeichen (auch keines)
|
||||
|
||||
```sql
|
||||
SELECT * FROM Professoren WHERE Rang LIKE 'W_';
|
||||
SELECT * FROM Professoren WHERE Name LIKE 'T%eophrastos';
|
||||
```
|
||||
|
||||
### IN / NOT IN
|
||||
```sql
|
||||
SELECT Name FROM Studenten WHERE Semester IN (1, 2, 3);
|
||||
|
||||
SELECT Name FROM Professoren
|
||||
WHERE PersNr NOT IN (SELECT gelesenVon FROM Vorlesungen);
|
||||
```
|
||||
|
||||
### ALL / ANY
|
||||
```sql
|
||||
-- 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);
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Anfragen über mehrere Relationen (Folien 15–20)
|
||||
|
||||
**Vorgehensweise:**
|
||||
1. Kreuzprodukt aus Tabellen bilden
|
||||
2. Relevante Zeilen und Felder ausschneiden
|
||||
|
||||
**Wichtigste Voraussetzung:** Information über Verbindung zwischen Tabellen (Join-Prädikat).
|
||||
|
||||
```sql
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## 6. Operator JOIN (Folien 21–53)
|
||||
|
||||
### 6.1 Motivation (Folie 21)
|
||||
|
||||
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.
|
||||
|
||||
### 6.2 Innere JOINs (Folien 23–30)
|
||||
|
||||
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
|
||||
|
||||
```sql
|
||||
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
|
||||
|
||||
```sql
|
||||
SELECT p.Name Professor, a.Name Assistent
|
||||
FROM Professoren p JOIN Assistenten a ON p.PersNr = a.Boss;
|
||||
```
|
||||
|
||||
### 6.3 Äußere JOINs (Folien 31–37)
|
||||
|
||||
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** |
|
||||
|
||||
### 6.4 Semi-JOINs (Folien 38–46)
|
||||
|
||||
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) |
|
||||
|
||||
```sql
|
||||
-- Semi-JOIN
|
||||
SELECT L.* FROM L INNER JOIN R ON L.x = R.x;
|
||||
SELECT L.* FROM L INNER JOIN R USING (x);
|
||||
```
|
||||
|
||||
### 6.5 SQL-Implementierung (Folien 47–53)
|
||||
|
||||
| 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 |
|
||||
|
||||
---
|
||||
|
||||
## 7. Anfragebearbeitung (Folien 54–58)
|
||||
|
||||
### Ablauf einer SQL-Anweisung
|
||||
|
||||
1. **Parser** → Syntax prüfen
|
||||
2. **Optimizer** → Optimalen Zugriffsplan erstellen
|
||||
3. **Row Source Generator** → Ausführungsplan auf physische Ressourcen
|
||||
4. **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) |
|
||||
|
||||
---
|
||||
|
||||
## 8. Indizes (Folien 59–95)
|
||||
|
||||
### 8.1 Überblick (Folie 59)
|
||||
|
||||
| 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 ] }`
|
||||
|
||||
### 8.2 Lineare Listen (Folien 60–64)
|
||||
|
||||
**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
|
||||
|
||||
### 8.3 Binärbäume (Folien 65–75)
|
||||
|
||||
**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.
|
||||
|
||||
### 8.4 Hashing (Folien 76–90)
|
||||
|
||||
**Funktionsprinzip:**
|
||||
1. Für jeden Datensatz wird ein Schlüssel gebildet
|
||||
2. Hash-Funktion ordnet dem Schlüssel einen kurzen Hash-Wert zu
|
||||
3. Hash-Wert dient als Index in der Hash-Tabelle
|
||||
4. 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:**
|
||||
1. **Modulo:** HW = Key % Basis (Primzahlen empfohlen)
|
||||
2. **Abschneiden:** Key² berechnen, dann von links/rechts kürzen
|
||||
3. **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)
|
||||
|
||||
### 8.5 Bitmap-Indizes (Folien 92–95)
|
||||
|
||||
**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
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
| Thema | Kernaussage |
|
||||
|---|---|
|
||||
| SQL-Kategorien | DDL (Struktur), DML (Daten), DCL (Rechte), TCL (Transaktionen) |
|
||||
| Einfache Befehle | CREATE, INSERT, UPDATE, DELETE, SELECT |
|
||||
| JOINs | Inner (NATURAL, Theta), Outer (LEFT, RIGHT, FULL), Semi (⋉, ⋊, ⊲, ⊳) |
|
||||
| Anfragebearbeitung | Parser → Optimizer (RBO/CBO) → Row Source Generator → Execution Engine |
|
||||
| Suchverfahren | Full Table Scan, Index-Scan (schnellste), Hash-Scan |
|
||||
| Binärbäume | O(log n) Suche; AVL/balanciert halten; Preorder/Inorder/Postorder |
|
||||
| Hashing | O(1) Durchschnitt; Kollisionsbehandlung; Modulo/Abschneiden/Zerlegung |
|
||||
| Bitmap-Indizes | Für geringe Kardinalität; Bit-Spalten pro Wert; schnelle logische Operationen |
|
||||
423
Datenbanken/Zusammenfassungen/e_NFs - zusammenfassung.md
Normal file
423
Datenbanken/Zusammenfassungen/e_NFs - zusammenfassung.md
Normal file
|
|
@ -0,0 +1,423 @@
|
|||
# Normalisierung – Zusammenfassung
|
||||
**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–41**
|
||||
|
||||
---
|
||||
|
||||
## 1. Einführung (Folien 1–6)
|
||||
|
||||
### Was ist Normalisierung?
|
||||
|
||||
Die relationale Darstellung einer entworfenen Datenbank kann noch **verfeinert** werden. Die Basis dafür bilden die **Normalformen** der Tabellen.
|
||||
|
||||
**Normalisierung** = Aufteilung von Attributen in mehrere Relationen (Tabellen) mithilfe der Normalisierungsregeln, sodass eine Struktur entsteht, die **keine vermeidbaren Redundanzen** mehr enthält.
|
||||
|
||||
### Ziele der Normalisierung
|
||||
|
||||
| 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 (z. B. lange Laufzeiten, große Anzahl der Tabellen)
|
||||
- Jede nächste Normalform **basiert auf der vorigen**
|
||||
|
||||
### Funktionale Abhängigkeit (Folie 4)
|
||||
|
||||
**Definition:** Man betrachtet eine Relation, X und Y sind Mengen der Attribute. 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 (Folie 5)
|
||||
|
||||
| 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 |
|
||||
|
||||
### Überblick Normalformen (Folie 6)
|
||||
|
||||
Die Normalformen bilden eine **aufsteigende Kette**: 1NF → 2NF → 3NF → BCNF → 4NF → 5NF
|
||||
|
||||
---
|
||||
|
||||
## 2. Erste Normalform – 1NF (Folien 7–16)
|
||||
|
||||
### Definition (Folie 8)
|
||||
|
||||
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 der 1NF
|
||||
|
||||
- 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 – dieser ist erst für weitere Normalformen nötig
|
||||
|
||||
### Mini-Welt-Beispiele: Adresse (Folien 9–10)
|
||||
|
||||
| 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 (Folien 12–13)
|
||||
|
||||
**Ausgangstabelle (nicht in 1NF):**
|
||||
```
|
||||
Wagen = { [ WagenID, Beschreibung, Status, Ankunft, Station ] }
|
||||
PK = [WagenID, Ankunft]
|
||||
```
|
||||
|
||||
**Problem:** 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 (Folien 14–16)
|
||||
|
||||
**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** – Produkt und Preis werden getrennt, jede Kombination ist eine eigene Zeile:
|
||||
|
||||
| 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 |
|
||||
|
||||
**Erweitertes Beispiel (Folie 15–16):** Tabelle mit Produkt+Herkunftsland und Menge+V.art als nicht-atomare Felder → Zerlegung in 7 separate Spalten (Vertragsdatum, Kunde, Produkt, Herkunftsland, V-Art, Lieferadresse, Menge). In 1NF ist hier **kein PK nötig**.
|
||||
|
||||
---
|
||||
|
||||
## 3. Zweite Normalform – 2NF (Folien 17–24)
|
||||
|
||||
### Definition (Folie 17)
|
||||
|
||||
Eine Tabelle liegt in **2NF** vor, wenn sie:
|
||||
1. In **1NF** vorliegt
|
||||
2. 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 (Folie 18)
|
||||
|
||||
Felder, die nur vom **Teil des Primärschlüssels** abhängig sind, werden zusammen mit dem Teilschlüssel in **neue Tabellen ausgelagert**:
|
||||
|
||||
```
|
||||
Vorher: PK = [S1, S2] → alle Felder
|
||||
Nachher: Tabelle 1: PK = [S1, S2] → Felder die vom ganzen PK abhängen
|
||||
Tabelle 2: PK = [S2] → Felder die nur von S2 abhängen (DepS2)
|
||||
```
|
||||
|
||||
### Beispiel: Bahnwagen (Folie 19)
|
||||
|
||||
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 (Folien 20–22)
|
||||
|
||||
**PK festgelegt:** [Vertragsdatum, Kunde, Produkt]
|
||||
|
||||
**Analyse der Abhängigkeiten:**
|
||||
- [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**
|
||||
|
||||
**Aufteilung:**
|
||||
```
|
||||
T-1 = { [ Vertragsdatum, Kunde, Produkt, Herkunftsland, Menge ] }
|
||||
T-2 = { [ Produkt, Herkunftsland ] } ← falls V-Art unabhängig
|
||||
T-3 = { [ Kunde, Lieferadresse ] }
|
||||
```
|
||||
|
||||
Wenn [V-Art] nur von [Produkt] abhängig ist, wird T-2 weiter aufgeteilt:
|
||||
```
|
||||
T-3-1 = { [ Produkt, Herkunftsland ] }
|
||||
T-3-2 = { [ Produkt, V-Art ] }
|
||||
```
|
||||
|
||||
### Beispiel: Bestellungen (Folie 23)
|
||||
|
||||
| RNr | ArtNr | LagerOrt | Anzahl |
|
||||
|---|---|---|---|
|
||||
| 100100 | 1010 | 22 | 1 |
|
||||
| 100100 | 1020 | 15 | 2 |
|
||||
| 100103 | 1040 | 13 | 10 |
|
||||
|
||||
Bei ArtNr : LagerOrt = 1:1 gibt es **zwei Schlüsselkandidaten**: [RNr, ArtNr] und [RNr, LagerOrt]. Die **2NF ist in beiden Fällen verletzt**, da [LagerOrt] vom Teilschlüssel [ArtNr] abhängt (bzw. umgekehrt).
|
||||
|
||||
**Lösung:**
|
||||
```
|
||||
Tabelle 1 = { [ RNr, ArtNr, Anzahl ] }
|
||||
Tabelle 2 = { [ ArtNr, LagerOrt ] }
|
||||
```
|
||||
|
||||
### ERM-Bezug (Folie 24)
|
||||
|
||||
Wenn man vom **ERM ausgeht** und den konzeptuellen Entwurf korrekt in den logischen umwandelt, kommt man direkt zu Tabellen, die die 2NF nicht verletzen – die Normalisierung ist dann nicht nötig.
|
||||
|
||||
---
|
||||
|
||||
## 4. Dritte Normalform – 3NF (Folien 25–28)
|
||||
|
||||
### Definition (Folie 25)
|
||||
|
||||
Eine Tabelle liegt in **3NF** vor, wenn sie:
|
||||
1. In **2NF** vorliegt
|
||||
2. 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, um eine perfekte Balance aus **Redundanz, Performance und Flexibilität** zu gewährleisten. Es gibt Sonderfälle (z. B. wissenschaftlicher Bereich), wo weiter normalisiert werden muss.
|
||||
|
||||
### Vorgang (Folie 26)
|
||||
|
||||
Funktionale Abhängigkeiten unter Nicht-PK-Feldern werden durch **Aufteilung der Tabelle** aufgelöst:
|
||||
|
||||
```
|
||||
Vorher: PK = [S1, S2], Feld F hängt von DepF ab (beide Nicht-PK)
|
||||
Nachher: Tabelle 1: [S1, S2, F] ← F bleibt als FK
|
||||
Tabelle 2: [F, DepF] ← F wird PK der neuen Tabelle
|
||||
```
|
||||
|
||||
### Beispiel: Bahnwagen (Folie 27)
|
||||
|
||||
Aus der 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 ist vom WagenType abhängig):
|
||||
```
|
||||
W121a = { [ WagenID, WagenType ] }
|
||||
W122a = { [ WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
|
||||
```
|
||||
|
||||
**Variante b** (Baujahr ist vom WagenType unabhängig):
|
||||
```
|
||||
W121b = { [ WagenID, WagenType, Baujahr ] }
|
||||
W122b = { [ WagenType, Leergewicht, Kapazitaet, Hersteller ] }
|
||||
```
|
||||
|
||||
### Beispiel: Kunden (Folie 28)
|
||||
|
||||
**Ausgangstabelle:** `{ [ KundenID, Adresse, Telefon ] }`
|
||||
|
||||
Wenn Adresse und Telefon voneinander unabhängig sind (nur vom PK KundenID abhängig), ist die Tabelle bereits in 3NF. Falls nicht → Aufteilung:
|
||||
```
|
||||
Tabelle 1 = { [ KundenID, Adresse ] }
|
||||
Tabelle 2 = { [ KundenID, Telefon ] }
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Boyce-Codd-Normalform – BCNF (Folien 29–30)
|
||||
|
||||
### Definition (Folie 29)
|
||||
|
||||
Eine Tabelle liegt in **BCNF** vor, wenn sie:
|
||||
1. In **3NF** vorliegt
|
||||
2. **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 (Folie 30)
|
||||
|
||||
| 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 (ein Verein betreibt nur eine Sportart, aber zu einer Sportart gehören mehrere Vereine)
|
||||
|
||||
**Schlüsselkandidaten:** [Name, Sportart] und [Name, Verein] → **Überlappung** (Name)
|
||||
|
||||
**Problem:** [Sportart] hängt vom Nicht-Schlüssel-Feld [Verein] ab → verletzt BCNF
|
||||
|
||||
**Lösung:**
|
||||
```
|
||||
Tabelle 1 = { [ Name, Verein ] }
|
||||
Tabelle 2 = { [ Sportart, Verein ] }
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Vierte Normalform – 4NF (Folie 31)
|
||||
|
||||
### Definition
|
||||
|
||||
Eine Tabelle liegt in **4NF** vor, wenn sie:
|
||||
1. In **BCNF** vorliegt
|
||||
2. Nur **semantisch verbundene** Nichtschlüsselattribute sich in der Tabelle befinden
|
||||
|
||||
Die 4NF trennt **semantisch (thematisch, inhaltlich) unabhängige** Entitäten durch Aufteilung der Tabelle.
|
||||
|
||||
### Beispiel: Bahnwagen
|
||||
|
||||
Aus der 3NF: `W122a = { [ WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }`
|
||||
|
||||
[Leergewicht] und [Kapazitaet] werden **viel öfter** verwendet als [Hersteller] und [Baujahr] (historische Bedeutung) → **unterschiedliche Semantik** → werden nie gleichzeitig benötigt.
|
||||
|
||||
**Aufteilung in 4NF:**
|
||||
```
|
||||
W122a1 = { [ WagenType, Leergewicht, Kapazitaet ] } ← technische Daten
|
||||
W122a2 = { [ WagenType, Hersteller, Baujahr ] } ← historische Daten
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. Fünfte Normalform – 5NF (Folien 32–34)
|
||||
|
||||
### Definition (Folie 32)
|
||||
|
||||
Eine Tabelle liegt in **5NF** vor, wenn sie:
|
||||
1. In **4NF** vorliegt
|
||||
2. 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 1: Touristik-Firma (Folie 33)
|
||||
|
||||
```
|
||||
T10 = { [ PersID, TourNr, Trans-Unternehmen ] } ← PK = alle drei Attribute
|
||||
```
|
||||
|
||||
Keine mehrwertigen Abhängigkeiten, da die drei Felder zusammen eine informative Einheit bilden. Trotzdem zerlegbar in:
|
||||
|
||||
```
|
||||
T11 = { [ PersID, TourNr ] }
|
||||
T12 = { [ PersID, Trans-Unternehmen ] }
|
||||
T13 = { [ TourNr, Trans-Unternehmen ] }
|
||||
```
|
||||
|
||||
Diese drei Tabellen können durch JOIN wieder die Originaltabelle herstellen.
|
||||
|
||||
### Beispiel 2: Hersteller-Produkt-Person (Folie 34)
|
||||
|
||||
| HerstID | ProduktID | PersID |
|
||||
|---|---|---|
|
||||
| 1 | Stift | 006 |
|
||||
| 1 | Ordner-L | 007 |
|
||||
| 1 | Kopierpapier | 007 |
|
||||
| 2 | Ordner-Z | 006 |
|
||||
| 3 | Kopierpapier | 007 |
|
||||
|
||||
**Zerlegung in 5NF:**
|
||||
```
|
||||
TA = { [ HerstID, ProduktID ] }
|
||||
TB = { [ PersID, ProduktID ] }
|
||||
TC = { [ HerstID, PersID ] }
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. Bedeutung des ERM (Folien 35–41)
|
||||
|
||||
### ERM als Alternative zur Normalisierung (Folie 35)
|
||||
|
||||
- Für die Praxis ist es empfehlenswert, dass Tabellen sich in **3NF** befinden
|
||||
- Höhere Normalformen sind eher für **theoretische Untersuchungen** wichtig
|
||||
- In der Praxis gelten Richtlinien (z. B. Geschwindigkeit), die manchmal den Verzicht auf 3NF (sogar 2NF) erfordern
|
||||
|
||||
**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.
|
||||
|
||||
### Anomalien ohne Normalisierung (Folien 36–38)
|
||||
|
||||
**Beispiel:** Eine 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 ... |
|
||||
|
||||
**Probleme (Anomalien):**
|
||||
|
||||
| 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 (Folie 39)
|
||||
|
||||
**Ergebnis der Normalisierung:**
|
||||
```
|
||||
Mitarbeiter = { [ PersID, Name, AbtNr ] }
|
||||
Abteilung = { [ AbtNr, Abteilung ] }
|
||||
arbeitet_an = { [ PersID, ProjNr ] }
|
||||
Projekt = { [ ProjNr, ProjBeschreibung ] }
|
||||
```
|
||||
|
||||
### ERM-Ansatz liefert dasselbe Ergebnis (Folie 40)
|
||||
|
||||
Wenn man mit dem **ERM anfängt** (konzeptuellen Entwurf richtig durchführt):
|
||||
|
||||
```
|
||||
Abteilung (1) — gehört zu — (N) Mitarbeiter (M) — arbeitet an — (N) Projekt
|
||||
```
|
||||
|
||||
Die Überführung in die relationale Darstellung liefert **dieselben Tabellen** wie die Normalisierung → ERM und Normalisierung sind **komplementäre Ansätze** zum gleichen Ziel.
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
| Normalform | 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 ] }
|
||||
```
|
||||
|
|
@ -0,0 +1,273 @@
|
|||
# Transaktionen – Zusammenfassung
|
||||
**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–31**
|
||||
|
||||
---
|
||||
|
||||
## 1. Definition (Folien 1–2)
|
||||
|
||||
### Integrität und Transaktionen
|
||||
|
||||
**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
|
||||
|
||||
---
|
||||
|
||||
## 2. Beispiel (Folie 3)
|
||||
|
||||
Zwei ganze Zahlen A und B (Datenbestand):
|
||||
|
||||
```
|
||||
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
|
||||
|
||||
---
|
||||
|
||||
## 3. Anforderungen (Folien 4–5)
|
||||
|
||||
### Allgemeine Anforderungen (Folie 4)
|
||||
|
||||
| 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.
|
||||
|
||||
### ACID-Eigenschaften (Folie 5)
|
||||
|
||||
| Eigenschaft | Beschreibung |
|
||||
|---|---|
|
||||
| **A**tomicity (Atomarität) | Entweder **alle** Befehle oder **gar keine** werden ausgeführt |
|
||||
| **C**onsistency (Konsistenz) | Transaktion hinterlässt nach Beendigung einen **konsistenten Datenzustand**, ansonsten komplettes Zurücksetzen |
|
||||
| **I**solation | Nebenläufige Transaktionen beeinflussen sich **nicht gegenseitig**; jede wird logisch so ausgeführt, als wäre sie die einzig aktive |
|
||||
| **D**urability (Dauerhaftigkeit) | Wirkung einer erfolgreich abgeschlossenen Transaktion bleibt **dauerhaft** erhalten, auch nach Systemfehler |
|
||||
|
||||
---
|
||||
|
||||
## 4. Zustände einer Transaktion (Folie 6)
|
||||
|
||||
```
|
||||
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 |
|
||||
|
||||
---
|
||||
|
||||
## 5. Synchronisation (Folien 7–8)
|
||||
|
||||
### Definition
|
||||
|
||||
**Synchronisation (Mehrbenutzersynchronisation)** = Koordinierung von mehreren Benutzerprozessen, eng verbunden mit der Ausführung der Transaktionen.
|
||||
|
||||
### Ausführungsarten
|
||||
|
||||
| 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. Probleme bei paralleler Ausführung (Folien 9–26)
|
||||
|
||||
### Übersicht (Folie 10)
|
||||
|
||||
Bei Zugriff auf **denselben Datenbestand** können folgende Probleme entstehen:
|
||||
1. **Lost Update**
|
||||
2. **Dirty Read**
|
||||
3. **Non-Repeatable Read**
|
||||
4. **Phantom Read**
|
||||
|
||||
Diese Probleme können durch **Isolation** (verschiedene Sicherheitsstufen) vermieden werden.
|
||||
|
||||
### Isolationsstufen – allgemein (Folie 11)
|
||||
|
||||
- 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
|
||||
|
||||
### 6.1 Lost Update (Folien 12–17)
|
||||
|
||||
**Problem:** Die von einer Transaktion geänderten Daten werden von einer anderen Transaktion überschrieben.
|
||||
|
||||
**Variante 1 – Direkt (Folie 12):**
|
||||
```
|
||||
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 (Folie 13):**
|
||||
```
|
||||
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`
|
||||
|
||||
### 6.2 Dirty Read (Folien 18–19)
|
||||
|
||||
**Problem:** 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).
|
||||
|
||||
### 6.3 Non-Repeatable Read (Folien 20–21)
|
||||
|
||||
**Problem:** 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).
|
||||
|
||||
### 6.4 Phantom Read (Folie 22–23)
|
||||
|
||||
**Problem:** Ä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** löst auch dieses Problem in Oracle.
|
||||
|
||||
### Trade-off der Isolationsstufen (Folie 24)
|
||||
|
||||
| Niedrigere Stufe | Höhere Stufe |
|
||||
|---|---|
|
||||
| Erlaubt gleichzeitigen Zugriff | Vermindert Probleme |
|
||||
| Mehr mögliche Nebenwirkungen | Mehr Systemressourcen |
|
||||
| Höhere Performance | Höhere Blockierungswahrscheinlichkeit |
|
||||
|
||||
### Isolationsstufen nach ANSI/ISO SQL92 (Folien 25–26)
|
||||
|
||||
| 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:** Der SQL-Standard schreibt diese Stufen vor, aber konkrete Datenbanken unterstützen sie **unterschiedlich**.
|
||||
|
||||
---
|
||||
|
||||
## 7. Synchronisationsstrategien (Folie 27)
|
||||
|
||||
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 |
|
||||
|
||||
---
|
||||
|
||||
## 8. Synchronisationsverfahren (Folien 28–30)
|
||||
|
||||
### 8.1 Sperrbasierte Synchronisation (Folie 28)
|
||||
|
||||
Wird **oft eingesetzt**. Idee:
|
||||
|
||||
| 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 (Folie 29)
|
||||
|
||||
| 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 |
|
||||
|
||||
### 8.2 Zeitstempelbasierte Synchronisation (Folie 30)
|
||||
|
||||
Wird **selten eingesetzt**. Idee:
|
||||
|
||||
| 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**.
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
| Konzept | Beschreibung |
|
||||
|---|---|
|
||||
| **Transaktion** | Atomare Operation: alles oder nichts (COMMIT/ROLLBACK) |
|
||||
| **ACID** | Atomicity, Consistency, Isolation, Durability |
|
||||
| **Lost Update** | Überschreiben von Änderungen → SERIALIZABLE |
|
||||
| **Dirty Read** | Lesen nicht festgeschriebener Daten → READ COMMITTED |
|
||||
| **Non-Repeatable Read** | Unterschiedliche Leseergebnisse → SERIALIZABLE |
|
||||
| **Phantom Read** | Geänderte Zeilenanzahl → SERIALIZABLE |
|
||||
| **Sperrbasiert (2PL)** | Wachstums- und Schrumpfphase, shared/exclusive locks |
|
||||
| **Zeitstempelbasiert** | Ordnung nach Transaktions-Zeitstempeln |
|
||||
|
|
@ -0,0 +1,138 @@
|
|||
# Speicherstrukturen – Zusammenfassung
|
||||
**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–11**
|
||||
|
||||
---
|
||||
|
||||
## 1. Überblick (Folie 2)
|
||||
|
||||
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) |
|
||||
|
||||
---
|
||||
|
||||
## 2. Datenträger (Folien 3–7)
|
||||
|
||||
### Tablespace (Folie 3)
|
||||
|
||||
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 (Folie 4)
|
||||
|
||||
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 (Folie 5)
|
||||
|
||||
| Typ | Beispiele |
|
||||
|---|---|
|
||||
| **Logische Objekte** | Tabellen, Indizes, User, Prozeduren |
|
||||
| **Physische Objekte** | Tablespace, Datenbankdatei, Segment (Extent), Block |
|
||||
|
||||
### CREATE TABLE mit Storage-Klausel (Folie 5)
|
||||
|
||||
```sql
|
||||
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 (Folie 6)
|
||||
|
||||
```sql
|
||||
-- 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 (Folie 7)
|
||||
|
||||
| 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 |
|
||||
|
||||
---
|
||||
|
||||
## 3. Arbeitsspeicher (Folien 8–10)
|
||||
|
||||
### System Global Area – SGA (Folien 8–9)
|
||||
|
||||
| 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 (Folie 10)
|
||||
|
||||
Beinhaltet Informationen, die für die **Steuerung der gesamten Oracle-Prozesse** notwendig sind.
|
||||
|
||||
### User Global Area – UGA (Folie 10)
|
||||
|
||||
Beinhaltet Informationen, die einem **aktuell verbundenen Benutzer** zugeordnet sind (Sitzung).
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
| Ebene | Struktur | Funktion |
|
||||
|---|---|---|
|
||||
| **Datenträger** | Tablespace | Container für Anwendungsdaten |
|
||||
| | Datenbankdatei | Physische Dateien im Tablespace |
|
||||
| | Segment/Extent | Erweiterbare Speichereinheit für Tabellen/Indizes |
|
||||
| | Block | Kleinste I/O-Einheit |
|
||||
| | Rollback-Segment | Daten vor Änderung (UNDO) |
|
||||
| | Redo-Log-Datei | Daten nach Änderung (REDO) |
|
||||
| **Arbeitsspeicher** | SGA | Globaler Speicher: Buffer-Cache, Dirty List, Redo-Log-Buffer, Shared Pool, Large Pool, Java Pool |
|
||||
| | PGA | Prozesssteuerung |
|
||||
| | UGA | Benutzer-Sitzungsdaten |
|
||||
|
|
@ -0,0 +1,314 @@
|
|||
# Sicherungskonzepte – Zusammenfassung
|
||||
**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–49**
|
||||
|
||||
---
|
||||
|
||||
## 1. Einführung (Folien 1–12)
|
||||
|
||||
### Datensicherheit (Folie 3)
|
||||
|
||||
**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 (ab 2005: IT-Grundschutz-Kataloge) unter www.bsi.bund.de
|
||||
|
||||
### Schadenskategorien (Folien 5–6)
|
||||
|
||||
| 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 |
|
||||
|
||||
### Relevante Gesetze (Folie 7)
|
||||
|
||||
| Gesetz | Kürzel | Jahr |
|
||||
|---|---|---|
|
||||
| Bundesdatenschutzgesetz | BDSG | 1990/2003/2009 |
|
||||
| Telekommunikationsgesetz | TKG | 2004 |
|
||||
| Telemediengesetz | TMG | 2007 |
|
||||
| Signaturgesetz | SigG | 2001 |
|
||||
| Diverse Landesdatenschutzgesetze | — | — |
|
||||
|
||||
### Grundprinzipien der Sicherheit (Folien 8–12)
|
||||
|
||||
| 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.
|
||||
|
||||
---
|
||||
|
||||
## 2. Integrität (Folien 13–23)
|
||||
|
||||
### Definition (Folie 14)
|
||||
|
||||
**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 (Folie 15)
|
||||
|
||||
| Ebene | Beschreibung |
|
||||
|---|---|
|
||||
| **Datenbank** (bessere Lösung) | Klauseln in DDL-Anweisungen |
|
||||
| **Anwendung** (zusätzliche Lösung) | Programmcode der Anwendung |
|
||||
|
||||
**Vorteile der DB-Ebene** (Folie 16):
|
||||
- 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 (Folie 17)
|
||||
|
||||
- **DML:** INSERT, UPDATE, DELETE
|
||||
- **DDL:** ALTER, DROP, RENAME
|
||||
|
||||
### Aktionen bei Integritätsverletzung (Folie 18)
|
||||
|
||||
| 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 (Folie 19)
|
||||
|
||||
Die Werte eines **Fremdschlüssels** müssen auch als Werte des **Primärschlüssels** vorhanden sein.
|
||||
|
||||
### Constraint-Typen (Folie 20)
|
||||
|
||||
| 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 (Folien 21–22)
|
||||
|
||||
```sql
|
||||
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 (Folie 23)
|
||||
|
||||
**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 |
|
||||
|
||||
---
|
||||
|
||||
## 3. Rechte (Folien 24–31)
|
||||
|
||||
### User/Schema-Konzept in Oracle (Folie 25)
|
||||
|
||||
- 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 (Folie 26)
|
||||
|
||||
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 (Folie 27)
|
||||
|
||||
| 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 (Folie 28)
|
||||
|
||||
| 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 (Folien 29–31)
|
||||
|
||||
```sql
|
||||
-- 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).
|
||||
|
||||
---
|
||||
|
||||
## 4. Backup (Folien 32–49)
|
||||
|
||||
### Definition (Folien 33–34)
|
||||
|
||||
**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:**
|
||||
1. Wiederherstellung nach Absturz
|
||||
2. Wiederherstellung eines bestimmten Zeitpunkts für Statistik (z. B. Jahresbericht)
|
||||
3. 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 (Folien 35–38)
|
||||
|
||||
**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 (Folie 39)
|
||||
|
||||
| Tool | Beschreibung |
|
||||
|---|---|
|
||||
| **exp/imp** | Ältere Versionen |
|
||||
| **expdp/impdp** | Neuere Versionen (Data Pump) |
|
||||
| **RMAN** | Recovery Manager |
|
||||
|
||||
**Weitere Tools (Folie 40):** Linux (cp, tar, bzip, gzip, dd), Windows (copy, Server-Sicherung), Drittanbieter (Acronis, Paragon, Fwbackups, Bacula).
|
||||
|
||||
### Backup-Medien (Folien 41–42)
|
||||
|
||||
| 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
|
||||
- 4. Sicherung: Großvater wird zum Sohn überschrieben, Rollen rotieren
|
||||
- Je mehr Datenträger, desto sicherer
|
||||
|
||||
### Backup-Methoden (Folie 43)
|
||||
|
||||
| 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 (Folien 44–47)
|
||||
|
||||
| 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 (Folie 48)
|
||||
|
||||
| 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.
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
| Bereich | Kernkonzepte |
|
||||
|---|---|
|
||||
| **Grundprinzipien** | Authentifizierung, Autorisierung, Protokollierung |
|
||||
| **Integrität** | Semantisch, Referentiell, Logisch; Constraints (PK, FK, NOT NULL, UNIQUE, CHECK); Trigger |
|
||||
| **Rechte** | DAC/MAC, System-/Objektprivilegien, Rollen, GRANT/REVOKE |
|
||||
| **Backup** | Hot/Cold, Normal/Inkrementell/Differenziell, RAID ≠ Backup, Generationsprinzip |
|
||||
163
Datenbanken/Zusammenfassungen/i_DWKonzepte - zusammenfassung.md
Normal file
163
Datenbanken/Zusammenfassungen/i_DWKonzepte - zusammenfassung.md
Normal file
|
|
@ -0,0 +1,163 @@
|
|||
# Data Warehouse Konzepte – Zusammenfassung
|
||||
**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–19**
|
||||
|
||||
---
|
||||
|
||||
## 1. Konzepte (Folie 2)
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## 2. OLAP (Folien 3–5)
|
||||
|
||||
### 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
|
||||
|
||||
---
|
||||
|
||||
## 3. ROLAP und MOLAP (Folien 6–8)
|
||||
|
||||
### 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
|
||||
|
||||
---
|
||||
|
||||
## 4. Lebenszyklus eines Data Warehouse (Folien 9–13)
|
||||
|
||||
### 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
|
||||
|
||||
---
|
||||
|
||||
## 5. Vergleich OLTP und OLAP (Folie 14)
|
||||
|
||||
| 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 |
|
||||
|
||||
---
|
||||
|
||||
## 6. ETL – Extract, Transform, Load (Folie 15)
|
||||
|
||||
### 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
|
||||
|
||||
---
|
||||
|
||||
## 7. Funktionsweise – Hypercube-Operationen (Folien 16–17)
|
||||
|
||||
Grundlage: **Mehrdimensionaler Hypercube** mit Dimensionen wie Zeitperioden, Produkte, Abteilungen und Werten wie Absatzvolumen.
|
||||
|
||||
### Navigationsoperationen
|
||||
- **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
|
||||
|
||||
### Hierarchische Navigation
|
||||
- **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
|
||||
|
||||
---
|
||||
|
||||
## 8. Varianten (Folie 18)
|
||||
|
||||
- **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
|
||||
199
Datenbanken/Zusammenfassungen/j_AndereDB - zusammenfassung.md
Normal file
199
Datenbanken/Zusammenfassungen/j_AndereDB - zusammenfassung.md
Normal file
|
|
@ -0,0 +1,199 @@
|
|||
# Andere Typen von Datenbanken – Zusammenfassung
|
||||
**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–44**
|
||||
|
||||
---
|
||||
|
||||
## 1. Hierarchische Datenbanken (Folien 2–14)
|
||||
|
||||
### Konzept
|
||||
- Vermutlich die **ältesten Datenbanken**, heute nur noch historische Bedeutung
|
||||
- Bei Bedarf durch relationale Datenbanken simulierbar
|
||||
- Datenbestand: Datensätze mit fester oder variabler Struktur
|
||||
- Semantische Beziehungen sind **fest programmmäßig durch Verweise** implementiert (Vorgänger-Nachfolger-Prinzip)
|
||||
|
||||
### Vorteile
|
||||
- Theoretisch sehr schnelle Such-, Einfüge- und Änderungsvorgänge
|
||||
|
||||
### Nachteile
|
||||
- **Unflexible baumartige Struktur**
|
||||
- Mit der Zeit werden Zugriffe langsamer (Einfüge-/Löschoperationen) → Baum muss in Gleichgewicht gebracht werden (zeit- und speicheraufwendig)
|
||||
|
||||
### Merkmale
|
||||
- Gut geeignet für: **Dateisysteme**, LDAP, Internet-Domänen, Stücklisten
|
||||
- Datensätze können mehr als zwei Verweise enthalten → nicht nur binäre, sondern auch **n-äre Bäume**
|
||||
- Knoten können auf Bäume mit anders strukturierten Datensätzen verweisen (Bäume/Unterbäume = Entitätstypen)
|
||||
- Nicht-hierarchische Beziehungen: durch verkettete Listen implementiert
|
||||
|
||||
### IMS von IBM
|
||||
- Älteste, bis heute eingesetzte hierarchische Datenbank
|
||||
- Komponenten: Datenbank, IMS Explorer, IMS SOAP Gateway, IMS Java Connector, IMS Data Provider .NET
|
||||
|
||||
---
|
||||
|
||||
## 2. Netzartige Datenbanken (Folien 15–17)
|
||||
|
||||
### Konzept
|
||||
- Entstehen aus hierarchischen DB durch **Verweisfelder für Rückwärtsbewegung**
|
||||
- **Verallgemeinerung** der hierarchischen Datenbanken
|
||||
- Unterschiedliche Entitätstypen vertreten, Beziehungen durch besondere Art der Datensätze modelliert
|
||||
|
||||
### Vorteile
|
||||
- Theoretisch vielfältige Verweise möglich
|
||||
|
||||
### Nachteile
|
||||
- Unflexible netzartige Struktur
|
||||
- Modellierung der Beziehungen eingeschränkt
|
||||
- Saubere Trennung der Entitätstypen kaum möglich
|
||||
|
||||
### Merkmale
|
||||
- Geeignet für: **geografische Elemente**, Makrostrukturen des Internets
|
||||
- Jeder Knoten kann mehrere Vorgänger und Nachfolger haben
|
||||
- Semantische Darstellung der Beziehungen meist programmiert
|
||||
- Bekannter Vertreter: **UDS** (Universal Datenbank System) von Siemens
|
||||
- Ca. 20 Jahre im Einsatz, dann durch **relationale Datenbanken verdrängt**
|
||||
|
||||
---
|
||||
|
||||
## 3. Verteilte Datenbanken (Folien 18–25)
|
||||
|
||||
### Konzept
|
||||
- **Verbund von mehreren** (meist relationalen) Datenbanken
|
||||
- Zusammenfassung von Informationseinheiten auf **mehreren Knoten** (Computern), über ein Netzwerk verbunden
|
||||
- **Metadaten** (Zugriffsdaten) in einer übergeordneten Datenbank zusammengefasst
|
||||
- Verteilte Transaktionen bestehen aus Teil-Transaktionen in den Komponenten-Datenbanken
|
||||
|
||||
### Vorteile
|
||||
- Optimale Darstellung der Unternehmensstruktur durch lokale Datenbestände
|
||||
- Unabhängigkeit der Teil-Datenbanken voneinander
|
||||
- Orts-, Plattform- und Netzwerkunabhängigkeit
|
||||
- Ständiger Betrieb
|
||||
- Effizienz durch parallele Verarbeitung
|
||||
- Transparenz der Anfragen und Anweisungen
|
||||
- Ergebnis- statt Sourcedaten-Transfer
|
||||
|
||||
### Nachteile
|
||||
- Vorbereitungsaufwand (Konzepte, Planung, Koordination)
|
||||
- Zusätzliche Administration der Metadaten (Backup/Restore, Konsistenz)
|
||||
- Aufwendige Entwicklung der Abfragen
|
||||
- Abhängigkeit von Lauffähigkeit der einzelnen Teil-Datenbanken
|
||||
|
||||
### Entwurf
|
||||
Wie bei konventionellen relationalen DB, plus zusätzliche Schritte:
|
||||
1. **Fragmentierungsschema** erstellen
|
||||
2. **Zuordnungsschema** erstellen
|
||||
|
||||
### Fragmentierung
|
||||
Relationen werden in disjunkte Fragmente zerlegt:
|
||||
- **Horizontale Zerlegung** – Datensätze nach Kriterien zusammengefasst (z.B. Status='Prof')
|
||||
- **Vertikale Zerlegung** – Attribute zusammengefasst (z.B. Vorname + Nachname)
|
||||
- **Kombinierte Zerlegung** – horizontal + vertikal
|
||||
|
||||
Anforderungen:
|
||||
- **Vollständigkeit** – Rekonstruktion ergibt vollständige Datenbank
|
||||
- **Disjunktion** – Fragmente überlappen sich nicht
|
||||
|
||||
### Zuordnung (Allocation)
|
||||
- Fragmente auf Knoten verteilen (theoretisch redundanzfrei)
|
||||
- Aus Sicherheits-/Leistungsgründen: **Replikation**
|
||||
- Benutzer arbeiten idealerweise nur mit dem Gesamtschema (Transparenz)
|
||||
|
||||
### Verteilte Transaktionen
|
||||
- DBMS muss globale Transaktion in **Teil-Transaktionen** zerlegen
|
||||
- Entweder alle erfolgreich oder alle zurückgesetzt
|
||||
- Jede Teil-DB muss **UNDO- und REDO-Funktionalität** beherrschen
|
||||
- **Two-Phase-Commit**: prepare → ready/failed → commit/abort
|
||||
|
||||
---
|
||||
|
||||
## 4. Objektorientierte Datenbanken (Folien 26–29)
|
||||
|
||||
### Konzept
|
||||
- Idee der OO: Daten und Aktionen (Methoden) zusammen bringen → **Kapselung**
|
||||
- Idee der DB: Daten und deren **Beziehungen** modellieren, unabhängig von Aktionen
|
||||
- Diese beiden Ideen sind **schwer zu vereinbaren**
|
||||
|
||||
### Eigenschaften
|
||||
- Vorteilhaft bei **Klassenhierarchien** unter Daten
|
||||
- Komplexe Objekte speicher- und abrufbar
|
||||
- **Keine Normalisierung**
|
||||
- Abfragen langsamer als bei relationalen DB
|
||||
- Geringe Kompatibilität zu allgemeinen Anwendungen
|
||||
|
||||
### Beispiele
|
||||
- **db4o** – geringe Speichergröße, für Java/.NET, keine SQL-Abfragesprache (QBE wird unterstützt), unterstützt Transaktionen (COMMIT, ROLLBACK)
|
||||
- **Oracle** – objektrelationaler Ansatz: Objekttypen (analog zu Klassen) mit Daten, Funktionen und Prozeduren, instanziierbar in PL/SQL
|
||||
|
||||
---
|
||||
|
||||
## 5. No-SQL-Datenbanken (Folien 30–43)
|
||||
|
||||
### Konzept
|
||||
- **No-SQL = Not only SQL** – betont die Existenz anderer Datenbanken neben relationalen
|
||||
- Relationale DB bleiben wichtig für Anwendungen mit strengen Konsistenz-/Sicherheitsanforderungen
|
||||
|
||||
### Gründe für No-SQL
|
||||
- Enorm große Datenvolumen (TiB- und PiB-Bereiche)
|
||||
- Kurze Laufzeiten der Abfragen nötig
|
||||
- Konsistenz nicht vorrangig (Daten meist nur abgefragt)
|
||||
- **Verfügbarkeit vor Konsistenz** (z.B. DNS)
|
||||
- Speicher für relationale DB wird teuer
|
||||
|
||||
### Eigenschaften
|
||||
- Einfaches/schwaches/kein Schema
|
||||
- Einfache horizontale und vertikale **Skalierung** (horizontal bevorzugt)
|
||||
- **BASE-Prinzip** statt ACID
|
||||
- Keine Normalformen, keine JOINs, denormalisiert
|
||||
- Hohe Leistung und Verfügbarkeit dank **Replikation**
|
||||
|
||||
### BASE vs. ACID
|
||||
|
||||
| BASE | ACID |
|
||||
|---|---|
|
||||
| **B**asically **A**vailable – Verfügbarkeit ggf. auf Kosten der Konsistenz | **A**tomic – Transaktion ununterbrechbar |
|
||||
| **S**oft State – Konsistenz an Entwickler delegiert | **C**onsistent – konsistenter Zustand gewährleistet |
|
||||
| **E**ventually Consistent – Abfragen auch bei inkonsistentem Zustand | **I**solated – Transaktionen verletzen einander nicht |
|
||||
| | **D**urable – ausgefallene Transaktion gefährdet eigene Daten nicht |
|
||||
|
||||
### Vertreter der No-SQL-Datenbanken
|
||||
|
||||
#### Document-Stores
|
||||
- **Schemafrei**, Daten in Dokumenten mit eindeutiger ID
|
||||
- Keine einheitliche Struktur, verschachtelbar
|
||||
- Felder können verschiedene Datentypen und Arrays haben
|
||||
- Hohe Skalierbarkeit
|
||||
- Beispiele: **MongoDB, CouchDB** (halb-strukturierte Formate: XML, JSON)
|
||||
- Nachteil: keine Normalisierung → Datenredundanz möglich, Konsistenz durch Anwendung
|
||||
|
||||
#### Key-Value-Stores
|
||||
- Nur **Schlüssel und zugehörige Werte** gespeichert
|
||||
- Einfaches Schema, Schlüssel sortierbar
|
||||
- Werte: Zahlen, Zeichenketten, Listen, Dokumente, Tabellen (nicht einheitlich)
|
||||
- Daten im **Hauptspeicher (In-Memory)** oder auf Datenträger (On-Disc)
|
||||
- Beispiele: **Berkeley DB, Redis, Amazon DynamoDB**
|
||||
- Schnelle einfache Abfragen, aber komplexe Beziehungen schwer zu implementieren
|
||||
|
||||
#### Wide-Column-Stores
|
||||
- Datensätze haben **unterschiedliche Struktur** (schemafrei)
|
||||
- Milliarden von Feldern pro Datensatz möglich
|
||||
- Feldstruktur: Spaltenname (Schlüssel), Daten, Zeitstempel
|
||||
- **Column Families** für zusammenhängende Spalten
|
||||
- Beispiele: **MS Azure Cosmos DB, Cassandra**
|
||||
- Gut für Big Data Analytics / DWH
|
||||
- Nicht verwechseln mit spaltenorientierten relationalen DB (die haben festes Schema)
|
||||
|
||||
#### XML-Datenbanken
|
||||
- Daten im **XML-Format** gespeichert
|
||||
- Abfragesprache: **XPath**
|
||||
- Beispiel: **BaseX**
|
||||
- Schnell für ganze Dokumente, langsam bei großen Datenmengen
|
||||
- Fehlende Operationen wie COMMIT, ROLLBACK
|
||||
- Eher **Verarbeitungssysteme für XML-Dokumente** als echte Datenbanken
|
||||
|
||||
#### Graph-Datenbanken
|
||||
- Daten in drei Klassen: **Knoten, Attribut, Kante** (Graph-Struktur)
|
||||
- Knoten = Tupel (Datensätze), Kanten = Beziehungen
|
||||
- Effektiv für **"wer-kennt-wen"**-Informationen
|
||||
- Nachteile: keine einheitliche Abfragesprache, keine direkten Zugriffe auf Knoten via Attributen
|
||||
|
||||
### Fazit
|
||||
Die No-SQL-Datenbanken sind **sehr effektiv in ihrem Spezialgebiet**.
|
||||
Loading…
Add table
Add a link
Reference in a new issue