Datenbank-Grundlagen – DBMS, SQL, NoSQL & ACID

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernen Sie die wichtigsten Grundlagen moderner Datenbanken kennen:

Definition: Was ist eine Datenbank und ein DBMS?
Warum Datenbanken? Vorteile gegenüber Dateisystemen
DBMS-Typen: Relational, NoSQL, NewSQL im Überblick
Datenmodelle: Relational, Dokument, Key-Value, Graph, Column-Family
ACID-Prinzip: Atomicity, Consistency, Isolation, Durability
Normalisierung: 1NF, 2NF, 3NF und BCNF
ER-Diagramme: Entity-Relationship-Modellierung
SQL vs. NoSQL: Wann welches System?
Best Practices: Enterprise-Empfehlungen
FAQ: Häufige Fragen zu Datenbanken

1. Was ist eine Datenbank?

Definition

Eine Datenbank ist eine strukturierte Sammlung von Daten, die elektronisch gespeichert und verwaltet wird. Ein DBMS (Database Management System) ist die Software, die diese Daten organisiert, sichert und für Anwendungen zugänglich macht.

Im Enterprise-Umfeld sind Datenbanken das Herzstück jeder Anwendung: Sie speichern Kundendaten, Bestellungen, Produkte, Logs, Metriken und praktisch jede Information, die ein Unternehmen produziert. Ohne zuverlässige Datenbanken funktionieren weder Webshops, Banksysteme noch ERP-Lösungen.

Die drei Säulen moderner Datenbanken: Struktur (wie Daten organisiert sind), Integrität (Konsistenz und Korrektheit) und Performance (schnelle Zugriffe auch bei großen Datenmengen).

             Warum Datenbanken statt Dateien?
            Zentrale Verwaltung: Daten werden einmal gespeichert, von vielen genutzt
Datenintegrität: Constraints verhindern ungültige Daten
Transaktionen: ACID garantiert konsistente Änderungen
Gleichzeitiger Zugriff: Mehrere Nutzer können parallel arbeiten
Sicherheit: Granulare Berechtigungen, Verschlüsselung
Backup & Recovery: Professionelle Sicherungsstrategien

        

2. DBMS-Typen und Datenmodelle

Je nach Anwendungsfall kommen unterschiedliche Datenbank-Typen zum Einsatz. Die Wahl des richtigen DBMS ist eine der wichtigsten Architekturentscheidungen.

Relational (RDBMS)

Tabellen, SQL, ACID

Daten werden in Tabellen mit Zeilen und Spalten gespeichert. Beziehungen über Fremdschlüssel.

Starke Datenkonsistenz (ACID)
SQL als Standardsprache
Komplexe Joins möglich
Schema-basiert

Beispiele: PostgreSQL, MySQL, Oracle, SQL Server, MariaDB

Dokument

JSON, flexibel, skalierbar

Daten als JSON/BSON-Dokumente. Schema-flexibel, ideal für halbstukturierte Daten.

Flexibles Schema
Horizontale Skalierung
JSON-native
Eingebettete Dokumente

Beispiele: MongoDB, CouchDB, Amazon DocumentDB

Key-Value

Extrem schnell, Caching

Einfache Schlüssel-Wert-Paare. Extrem schnell für Lese-/Schreibzugriffe.

Sub-Millisekunde Latenz
In-Memory Option
Perfekt für Caching
Einfache API

Beispiele: Redis, Memcached, DynamoDB, Riak

Graph

Beziehungen, Netzwerke

Knoten (Nodes) und Kanten (Edges). Ideal für vernetzte Daten und Beziehungen.

Schnelle Traversierung
Soziale Netzwerke
Betrugserkennung
Empfehlungssysteme

Beispiele: Neo4j, Amazon Neptune, JanusGraph

Column-Family

Big Data, Analytics

Spalten-basierte Speicherung. Optimal für analytische Abfragen und Big Data.

Massive Skalierung
Hohe Schreibperformance
Zeitreihen-Daten
Data Warehousing

Beispiele: Apache Cassandra, HBase, ScyllaDB

Zeitreihen

IoT, Monitoring, Metrics

Spezialisiert auf zeitlich geordnete Daten. Ideal für IoT, Monitoring, Metriken.

Hohe Schreibrate
Zeitbasierte Abfragen
Automatische Aggregation
Daten-Retention

Beispiele: InfluxDB, TimescaleDB, Prometheus

3. Das ACID-Prinzip

ACID ist das Fundament zuverlässiger Transaktionen in Datenbanken. Die vier Buchstaben stehen für essentielle Eigenschaften, die Datenintegrität garantieren.

ACID – Die vier Säulen der Transaktionssicherheit

Jede Datenbank-Transaktion (z.B. eine Überweisung) muss vier Eigenschaften erfüllen, um Datenkonsistenz zu garantieren. Ohne ACID würden Banksysteme, Bestellsysteme und praktisch alle Enterprise-Anwendungen nicht funktionieren.

A

Atomicity (Atomarität)

Eine Transaktion wird ganz oder gar nicht ausgeführt. Keine halben Sachen.

Überweisung: Beide Konten müssen aktualisiert werden – oder keine.

C

Consistency (Konsistenz)

Die Datenbank wechselt von einem konsistenten in einen anderen konsistenten Zustand.

Kontostand darf nie negativ werden, wenn Regel das verbietet.

I

Isolation (Isolation)

Parallele Transaktionen beeinflussen sich nicht gegenseitig.

Zwei Überweisungen gleichzeitig laufen unabhängig voneinander.

D

Durability (Dauerhaftigkeit)

Eine bestätigte Transaktion ist permanent gespeichert, auch bei Stromausfall.

Nach "Commit" ist die Buchung sicher auf Festplatte.

ACID vs. BASE (NoSQL)

Viele NoSQL-Datenbanken opfern striktes ACID zugunsten von Skalierbarkeit und folgen dem BASE-Prinzip:

Basically Available – System ist immer erreichbar
Soft State – Zustand kann sich ohne Input ändern
Eventually Consistent – Konsistenz kommt mit der Zeit

Entscheidungshilfe: Finanzsysteme brauchen ACID. Social Media, IoT, Logs können mit BASE leben.

4. Normalisierung

Normalisierung ist der Prozess, eine Datenbank so zu strukturieren, dass Redundanzen vermieden und Anomalien verhindert werden. Ziel: Ein sauberes, wartbares Datenmodell.

1

1. Normalform (1NF)

Alle Attribute sind atomar – keine verschachtelten Listen oder Arrays in einer Zelle.

❌ Telefon: "0171-123, 0172-456"
✅ Zwei separate Datensätze

2

2. Normalform (2NF)

1NF + alle Nicht-Schlüssel-Attribute hängen vollständig vom Primärschlüssel ab (nicht nur von einem Teil).

❌ Bestellung(AuftragID, ProduktID, Produktname)
✅ Produkte in eigener Tabelle

3

3. Normalform (3NF)

2NF + keine transitiven Abhängigkeiten – Nicht-Schlüssel-Attribute hängen nicht voneinander ab.

❌ Mitarbeiter(ID, AbtID, AbtName)
✅ Abteilungen in eigener Tabelle

B

Boyce-Codd-NF (BCNF)

Strengere Form der 3NF. Jede Determinante ist ein Kandidatenschlüssel.

Selten benötigt, aber wichtig bei komplexen Abhängigkeiten zwischen Attributen.

Normalisierung vs. Denormalisierung

Normalisierung reduziert Redundanzen und verbessert Datenintegrität – ideal für OLTP (Transaktionen).

Denormalisierung fügt bewusst Redundanzen hinzu, um Joins zu vermeiden – ideal für OLAP (Analytics, Data Warehouses).

Praxis-Regel: Normalisiere beim Schreiben (OLTP), denormalisiere beim Lesen (OLAP).

5. ER-Diagramme (Entity-Relationship)

ER-Diagramme sind die visuelle Sprache der Datenbankmodellierung. Sie zeigen Entitäten, ihre Attribute und Beziehungen – die Blaupause für jede relationale Datenbank.

Die drei Bausteine eines ER-Diagramms

Entität (Entity)

Ein Objekt oder Konzept, über das Daten gespeichert werden. Wird als Rechteck dargestellt.

Beispiele: Kunde, Produkt, Bestellung

Attribut (Attribute)

Eine Eigenschaft einer Entität. Wird als Ellipse dargestellt.

Beispiele: Name, Preis, Datum

Beziehung (Relationship)

Verbindung zwischen Entitäten. Wird als Raute dargestellt.

Beispiele: "kauft", "gehört zu", "enthält"

Kardinalitäten – Beziehungen verstehen

1:1 (Eins-zu-Eins): Ein Mitarbeiter hat genau einen Dienstausweis
1:n (Eins-zu-Viele): Ein Kunde hat viele Bestellungen
n:m (Viele-zu-Viele): Studenten belegen mehrere Kurse, Kurse haben mehrere Studenten → benötigt Junction-Tabelle

Tipp: Jede n:m-Beziehung wird in der Datenbank über eine Zwischentabelle (Junction Table) aufgelöst.

6. SQL vs. NoSQL

Die Wahl zwischen SQL und NoSQL ist eine der wichtigsten Architekturentscheidungen. Beide Ansätze haben ihre Stärken – es gibt kein "besser", nur "passender".

SQL (Relational)

Strukturiert, ACID, Joins

Starke Schema-Validierung
ACID-Transaktionen
Komplexe Joins und Aggregationen
Ausgereifte Tools und Ökosystem
Vertikale Skalierung (größere Server)
Ideal für strukturierte Geschäftsdaten

NoSQL

Flexibel, skalierbar, schnell

Schema-flexibel (JSON, Key-Value)
Horizontale Skalierung (mehr Server)
Extrem hohe Schreib-/Lese-Raten
Ideal für Big Data und Echtzeit
Verteilte Architekturen
Perfekt für halbstukturierte Daten

Beliebte Datenbanken im Vergleich

Datenbank	Typ	Lizenz	Stärken	Einsatz
PostgreSQL	Relational	Open Source	ACID, Erweiterbar, JSON-Support	Enterprise, Geodaten
MySQL	Relational	Open Source	Einfach, schnell, verbreitet	Web-Anwendungen
MongoDB	Dokument	SSPL	Flexibel, JSON-nativ	Content, Kataloge
Redis	Key-Value	BSD	In-Memory, sub-ms Latenz	Caching, Sessions
Cassandra	Column-Family	Apache	Massiv skalierbar, ausfallsicher	Big Data, IoT
Neo4j	Graph	GPL	Beziehungs-Traversierung	Soziale Netzwerke, Empfehlungen
InfluxDB	Zeitreihen	MIT	Zeitbasierte Abfragen	Monitoring, IoT
Oracle	Relational	Proprietär	Enterprise-Features, Support	Banken, Konzerne

             Entscheidungshilfe
            SQL wählen bei: Finanzsystemen, Bestellungen, klassischen Geschäftsanwendungen, komplexen Abfragen
NoSQL wählen bei: Katalogen, Content, IoT-Daten, Echtzeit-Analytics, massivem Traffic
Polyglot Persistence: In modernen Architekturen werden oft mehrere DB-Typen kombiniert – jede für ihre Stärke

        

7. Enterprise Best Practices

Bewährte Prinzipien für zuverlässige, performante und sichere Datenbanken im Enterprise-Umfeld.

Datenbankdesign

Normalisierung für OLTP-Systeme
ER-Diagramme vor der Implementierung
Angemessene Datentypen wählen
Constraints für Datenintegrität
Benennungskonventionen etablieren

Performance

Indizes für häufige Abfragen
EXPLAIN/ANALYZE nutzen
Verbindungspools verwenden
N+1-Query-Problem vermeiden
Caching-Strategie (Redis, Memcached)

Sicherheit

Prinzip der geringsten Rechte
Prepared Statements gegen SQL-Injection
Verschlüsselung (at rest & in transit)
Audit-Logs aktivieren
Regelmäßige Sicherheitsaudits

Backup & Recovery

3-2-1-Regel befolgen
Regelmäßige Recovery-Tests
PITR (Point-in-Time-Recovery)
Replikation für Hochverfügbarkeit
Disaster-Recovery-Plan dokumentieren

Skalierung

Read-Replicas für Lese-Last
Sharding bei großen Datenmengen
Vertikale vs. horizontale Skalierung
Connection Pooling
Auto-Scaling in der Cloud

Monitoring

Slow-Query-Logs analysieren
Metriken: CPU, RAM, IOPS, Connections
Alerting bei Schwellwerten
Query-Performance überwachen
Kapazitätsplanung betreiben

8. FAQ – Häufige Fragen & Antworten

Häufige Fragen zu Datenbanken

Wann sollte ich SQL und wann NoSQL verwenden?

Die Wahl hängt von Ihrem Use Case ab:

SQL (z.B. PostgreSQL, MySQL): Bei strukturierten Daten, komplexen Beziehungen, Transaktionen, Finanzsystemen, wo ACID wichtig ist
NoSQL (z.B. MongoDB, Redis): Bei flexiblen Schemata, halbstukturierten Daten (JSON), massivem Traffic, horizontaler Skalierung
Polyglot Persistence: In modernen Systemen werden oft beide kombiniert – SQL für Kerndaten, NoSQL für Caching/Sessions/Logs

Faustregel: Im Zweifel mit SQL starten – es ist vielseitiger als oft angenommen. Moderne SQL-Datenbanken (PostgreSQL) unterstützen auch JSON und NoSQL-ähnliche Features.

Was ist der Unterschied zwischen einem Index und einem Primärschlüssel?

Beide beschleunigen Abfragen, aber mit unterschiedlichen Eigenschaften:

Primärschlüssel: Eindeutige Identifikation jeder Zeile, implizit indexiert, nur einer pro Tabelle, NOT NULL
Index: Kann auf beliebigen Spalten liegen, mehrere pro Tabelle möglich, beschleunigt WHERE/ORDER BY/JOIN

Wichtig: Indizes beschleunigen Lesezugriffe, verlangsamen aber Schreibzugriffe (INSERT/UPDATE). Deshalb nur dort einsetzen, wo häufig abgefragt wird.

Was ist eine Transaktion und warum ist sie wichtig?

Eine Transaktion ist eine logische Einheit von Datenbankoperationen, die entweder komplett oder gar nicht ausgeführt wird.

Beispiel Überweisung:

Konto A: -100 €
Konto B: +100 €

Beide Operationen müssen gemeinsam gelingen oder beide abbrechen. Ohne Transaktion könnte bei einem Fehler Geld verloren gehen oder aus dem Nichts entstehen.

SQL: BEGIN ... COMMIT (oder ROLLBACK bei Fehler)

Was ist SQL-Injection und wie schütze ich mich?

SQL-Injection ist eine Angriffstechnik, bei der Angreifer schädlichen SQL-Code in Eingabefelder einschleusen.

Beispiel (unsicher):

SELECT * FROM users WHERE name = '" + userInput + "'

Schutzmaßnahmen:

Prepared Statements: Parameter statt String-Konkatenation
ORMs: Object-Relational Mapper (z.B. Entity Framework, SQLAlchemy)
Input-Validierung: Eingaben prüfen und säubern
Least Privilege: DB-User mit minimalen Rechten

Wie entscheide ich mich zwischen verschiedenen SQL-Datenbanken?

Die wichtigsten SQL-Datenbanken im Vergleich:

PostgreSQL: Feature-reich, extensibel, JSON-Support, ideal für komplexe Anwendungen
MySQL/MariaDB: Einfach, schnell, weit verbreitet, ideal für Web-Apps
SQL Server: Microsoft-Ökosystem, gute Enterprise-Features, Windows-Integration
Oracle: Enterprise-Standard, teuer, für Banken und Konzerne
SQLite: Embedded, keine Server, ideal für mobile Apps und kleine Projekte

Empfehlung für die meisten Projekte: PostgreSQL – es bietet die beste Balance aus Features, Performance und Kosten.

Was ist das N+1-Query-Problem und wie löse ich es?

Das N+1-Query-Problem tritt auf, wenn für jedes Element einer Liste eine separate Abfrage ausgeführt wird.

Beispiel (ineffizient):

1 Query: Alle Bestellungen laden
N Queries: Für jede Bestellung den Kunden laden

Lösungen:

JOIN: Beide Tabellen in einer Query verknüpfen
Eager Loading: In ORMs (z.B. .Include() in Entity Framework)
Data Loader: In GraphQL-APIs
Batch-Loading: IDs sammeln und gemeinsam abfragen

Wie skaliere ich eine Datenbank bei wachsendem Traffic?

Skalierungsstrategien für Datenbanken:

Vertikale Skalierung (Scale Up): Größerer Server (mehr CPU, RAM, SSD) – einfach, aber begrenzt
Read-Replicas: Mehrere Kopien für Lesezugriffe – entlastet die Haupt-DB
Caching: Redis/Memcached für häufig abgefragte Daten
Sharding: Daten auf mehrere Server verteilen (z.B. nach User-ID)
Horizontale Skalierung (Scale Out): Mehr Server hinzufügen – komplexer, aber praktisch unbegrenzt

Empfehlung: Zuerst optimieren (Indizes, Queries), dann cachen, dann Read-Replicas, dann Sharding.

Was ist der Unterschied zwischen OLTP und OLAP?

Zwei grundlegend verschiedene Datenbank-Paradigmen:

OLTP (Online Transaction Processing): Viele kurze Transaktionen, normalisierte Daten, Fokus auf Schreibgeschwindigkeit und Konsistenz. Beispiele: Bestellsysteme, Banking.
OLAP (Online Analytical Processing): Komplexe analytische Abfragen über große Datenmengen, denormalisierte Daten (Star/Snowflake Schema), Fokus auf Lesegeschwindigkeit. Beispiele: Data Warehouses, Business Intelligence.

Praxis: Die meisten Unternehmen nutzen beide: OLTP für operative Systeme, OLAP für Analysen und Berichte. ETL-Prozesse (Extract, Transform, Load) synchronisieren die Daten zwischen beiden.

Zusammenfassung

             Die wichtigsten Punkte
            Datenbank: Strukturierte Sammlung von Daten, verwaltet durch ein DBMS
DBMS-Typen: Relational (SQL), Dokument, Key-Value, Graph, Column-Family, Zeitreihen
ACID: Atomicity, Consistency, Isolation, Durability – Grundlage zuverlässiger Transaktionen
Normalisierung: 1NF, 2NF, 3NF, BCNF – für saubere, redundanzfreie Datenmodelle
ER-Diagramme: Visuelle Modellierung von Entitäten, Attributen und Beziehungen
SQL vs. NoSQL: Keine Frage von "besser", sondern von "passender"
Indizes: Beschleunigen Lesezugriffe, verlangsamen Schreibzugriffe
Transaktionen: Logische Einheiten, die ganz oder gar nicht ausgeführt werden
Best Practices: Design, Performance, Security, Backup, Skalierung, Monitoring
PostgreSQL: Oft die beste Allround-Wahl für neue Projekte

        

Bereit für den nächsten Schritt?

Mit diesen Grundlagen haben Sie das Fundament für professionelles Datenbank-Management gelegt. Vertiefen Sie Ihr Wissen in den folgenden Kapiteln zu spezifischen SQL-Befehlen, NoSQL-Datenbanken oder Performance-Optimierung.

Weiter zu SQL-Datenbanken

Weiterführende Themen

SQL-Datenbanken

PostgreSQL, MySQL, Oracle – die Welt der relationalen Datenbanken im Detail.

Zu SQL-Datenbanken

NoSQL-Datenbanken

MongoDB, Redis, Cassandra – moderne NoSQL-Lösungen für spezielle Anforderungen.

Zu NoSQL-Datenbanken

SQL-Befehle

SELECT, INSERT, UPDATE, DELETE – die wichtigsten SQL-Befehle mit Beispielen.

Zu SQL-Befehlen

Datenbank-Optimierung

Indizes, Query-Optimierung, Caching – Performance-Tuning für Datenbanken.

Zur Optimierung