Selbsttest-Unterlage · Kompaktversion

📚 Datenbanken — Kompakt-Spickzettel

1 · Grundlagen

Datenbasis = strukturierte Datensammlung (Symbol: Zylinder). DBMS = verwaltet Zugriff, Speicherung, Datenmodell, Mehrbenutzer, Sicherheit, Datenschutz. Bsp: Access, MySQL, PostgreSQL, Oracle, SAP HANA.

ANSI/SPARC — 3 Schichten

1 · ExternNutzersicht
nur relevante Daten
Multi-User, Rechte

→

2 · Konzeptionellalle Entities +
Beziehungen
wertfrei, stabil

→

3 · Internphysische Speicherung
Indizierung, Sortierung
technisch, verborgen

2 · Betriebskonzepte

Typ	Merkmal	Vor-/Nachteil	Beispiele
Stand-Alone	lokal, 1 Nutzer	einfach, keine Rechte	dBase, Access, Filemaker
File-Share	Netz-Zugriff, Verwaltung lokal je Client	+ keine Redundanz / − hoher Netzverkehr, schlechte Sperren	—
Client-Server	Verwaltung zentral auf Server	+ Sicherheit/Leistung/Flexibilität / − braucht DBA	Oracle, DB2, SQL Server, MySQL, MAXDB

3 · Datenmodelle / DB-Arten

Modell	Prinzip	Beispiele
Hierarchisch	Baum, 1 Vorgänger/Datensatz → Redundanz möglich	IMS DB
Netzwerk	mehrere Vorgänger → m:n möglich, weniger Redundanz	—
Relational	Tabellen + Beziehungen, Standard seit 1970, schwach bei Big Data	MySQL, SQL Server, SQLite
Objekt	Daten + Funktionen OO, mächtig aber komplex	db4o
Objektrelational	relational + OO kombiniert	PostgreSQL

NoSQL (4 Arten)

Art	Prinzip	Beispiele
Key-Value	Schlüssel-Wert-Paare, flexibel	Amazon Dynamo, BigTable
Dokument	strukturiert/unstrukturiert, CMS/Blogs	MongoDB, BaseX
Graph	vernetzte Daten, Beziehungen (soz. Netzwerke)	Neo4j, HyperGraphDB
Spaltenorientiert	spaltenweise Speicherung, gut für Analysen	Cassandra, Sybase IQ

4 · Designprozess (4 Phasen)

1 · Analyse

Kundenanforderungen ermitteln/strukturieren → informelle Problembeschreibung ("Miniwelt")

2 · Konzeptionell

ER-Modell erstellen: Entitätstypen, Attribute, Beziehungen, Kardinalitäten

3 · Logisch

Transformation ins relationale Modell, Normalisierung, PK/FK festlegen

4 · Physisch

Implementation: physische DB via SQL, Datentypen, Wertebereiche, Indizes

5 · ER-Modell — Grundbegriffe

Entität = konkretes Objekt ("Herr Maier") · Entitätstyp = Gattung gleichartiger Entitäten ("Person")
Attribut = Dateneigenschaft (Name, Preis…) · Schlüsselattribut = eindeutig, unterstrichen dargestellt
Beziehung = Raute ◇, verbindet 2 Entitätstypen; bei m:n kann die Beziehung selbst Attribute haben (z. B. FlussNr, MaxTiefe)

Kardinalitäten

Typ	Beispiel
1:1	Mitarbeiter ↔ genau eine Personalakte
1:n	Gebäude ↔ mehrere Räume (Raum gehört nur zu 1 Gebäude)
m:n	Kunde ↔ mehrere Artikel, Artikel ↔ mehrere Kunden

Beispieldiagramm: Kunde – Bestellung – Produkt

Kunde

Name

Adresse

1:N

gibt auf

1:N

Bestellung

Bestell_Nr

Datum

1:N

enthält

1:N

Produkt

Name

Preis

Beispiel-ERM: Lehrer – Kurs – Schüler

Lehrer

PersonalNr

Vorname

Nachname

unterrichtet

Kurs

KursID

Name

Halbjahr

belegt

Schüler

SchuelerID

Vorname

Nachname

Geburtsdatum

Strasse, PLZ, Ort

6 · Relationales Modell

Relation/Tabelle = Relationsname + Spalten (Attribute) + Zeilen (Datensätze/Tupel)
Datensatz = Datenfelder · Attributwert = konkreter Wert je Feld

Primärschlüssel (PK) — genau 1 pro Tabelle

Eindeutigkeine Duplikate

Minimalmöglichst wenige Spalten

UnveränderlichWerte ändern sich nicht

Fremdschlüssel (FK): verweist auf PK einer anderen/derselben Tabelle; gleicher Datentyp wie PK; 0, 1 oder mehrere FK pro Tabelle möglich.

Transformationsregeln ER → Relational

Jeder Entitätstyp → eigene Tabelle (mit allen Attributen)
Jede Tabelle braucht PK (ggf. künstlicher Schlüssel)
1:n → PK der "1"-Seite als FK in die "n"-Seite
m:n → eigene Verbindungstabelle mit PKs beider Seiten als FK (+ eigene Attribute möglich)

Kunde

ID (PK)

Name

Adresse

Bestellung

Bestell_Nr (PK)

Datum

Kunden_ID (FK → Kunde)

Bestellposition

ID (PK)

Bestell_Nr (FK)

Produkt_Nr (FK)

Preis, Menge

7 · Normalisierung — Fachbegriffe

Begriff	Definition
Normalisierung	Redundanz reduzieren → Anomalien vermeiden, Konsistenz erhöhen
Datenredundanz	gleiche Info mehrfach gespeichert
Datenkonsistenz	Daten sind widerspruchsfrei/korrekt
Änderungsanomalie	mehrfach gespeicherte Daten → beim Ändern werden Kopien übersehen
Einfügeanomalie	Daten nur zusammen mit anderen erfassbar (z. B. MA ohne Abteilung)
Löschanomalie	Löschen entfernt ungewollt weitere Daten (Abteilung löschen → MA-Daten weg)
Referenzielle Integrität	FK-Werte müssen in PK-Tabelle existieren

8 · Normalformen (Flug-Beispiel)

Ausgangslage: unnormalisierte Tabelle mit mehreren Flügen pro Kunde in einer Zelle.

1 NF — alle Attribute atomar

Keine Mengen/Listen → jede Kunde-Flug-Kombination bekommt eine eigene Zeile:

Kunde	Name	Flug	Ziel	Land	Fluggesellschaft
K1013	Meier, R.	M107	Paris	F	Moeve
K1013	Meier, R.	AT286	Edmonton	CA	AirTrans
K8516	Schulz, B	AT286	Edmonton	CA	AirTrans

2 NF — voll funktional vom ganzen PK abhängig

Aufteilen, da Name nur von Kunde, und Ziel/Land/Fluggesellschaft nur von Flug abhängen:

Kunden 2NF

Kunde (PK)

Name

Flüge 2NF

Flug (PK)

Ziel, Land, Fluggesellschaft

Flugbuchungen 2NF

Kunde (FK)

Flug (FK)

3 NF — keine transitive Abhängigkeit

Land → Fluggesellschaft wäre transitiv über Flug abhängig → weiter aufteilen:

Flüge 3NF

Flug (PK)

Ziel → FK

Ziele 3NF (neu)

Ziel (PK)

Land

Ergebnis 3NF: Kunden, Flugbuchungen, Flüge (ohne Land), Ziele — Abhängigkeit Land→Fluggesellschaft aufgelöst.

Weitere Normalformen

Form	Regel
BCNF	alle funktionalen Abhängigkeiten gehen vom PK aus
4NF	keine mehrwertigen Abhängigkeiten
5NF	nur triviale Verbundabhängigkeiten

Nachteile der Normalisierung: viele kleine Tabellen → Leistungsprobleme (langsamer) · viele künstliche Schlüssel/Verknüpfungen → höhere Komplexität, mehr Fehleranfälligkeit · zusätzliche Schlüssel = mehr Speicherbedarf (= eine Art Redundanz)

9 · Vollständiges Beispiel-Schema (Schule)

ERM: Lehrer —1:n— unterrichtet —n:m— belegt —Schüler (über Kurs)

Lehrer

ID (PK)

Vorname, Name, Kuerzel

Kurs

ID (PK)

Name, Halbjahr, Kuerzel

LehrerID (FK)

Kursbelegung (löst m:n)

ID (PK)

Note

SchuelerID (FK)

KursID (FK)

Schueler

SchuelerID (PK)

Vorname, Nachname, Geburtsdatum, Geschlecht

AnschriftID (FK)

Anschrift

AnschriftID (PK)

Strasse, HausNr, PLZ, Ort

Beziehungen: Schüler (1)–(N) Kursbelegung · Kurs (1)–(N) Kursbelegung · Kurs (N)–(1) Lehrer · Schüler (N)–(1) Anschrift

Merksätze zur Reihenfolge

DesignAnalyse

→

Konzeptionell (ERM)

→

Logisch (Relational + Norm.)

→

Physisch (SQL)

Normalform1NF (atomar)

→

2NF (voll v. PK abh.)

→

3NF (keine transitive Abh.)

→

BCNF → 4NF → 5NF