NoSQL und Dokumentendatenbanken (Document Stores)

NoSQL und Dokumentendatenbanken (Document Stores)

https://bildung.social/@oerinformatik/

https://oer-informatik.de/documentstore

NoSQL, Dokumentendatenbank, Document Store, MongoDB, JSON, Einbetten, Referenzieren, Zeitreihendatenbank, Big Data, CAP-Theorem, BASE, ACID

tl/dr; (ca. 25 min Lesezeit): Nicht alle Daten passen gut in Tabellen. Der Artikel zeigt zuerst, was ein Datenbanksystem einer Tabellenkalkulation voraushat. NoSQL-Datenbanken speichern Daten als Schlüssel-Wert-Paare, Dokumente, Spaltenfamilien, Graphen oder Zeitreihen; Zeitreihendatenbanken sind auf Messwerte spezialisiert. Im Mittelpunkt stehen die Dokumentendatenbanken (Document Stores): Der Artikel ordnet ihre Fachbegriffe den relationalen zu, zeigt, wie aus Tabellenzeilen Dokumente werden und wann man Daten einbettet oder referenziert, wie man mit MongoDB abfragt, welche Risiken ein flexibles Schema hat, stellt BASE dem ACID-Prinzip gegenüber, erklärt Big Data mit den drei V und gibt eine Entscheidungshilfe: relationale oder dokumentenorientierte Datenbank [AI-Assisted]? (Zuletzt geändert am 28.10.2026)

Dieser Artikel baut auf der Kann-Liste der Artikel Das Relationenmodell und JSON auf.

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Relationale Datenbanken sind seit Jahrzehnten der Standard: Tabellen mit festen Spalten, Schlüssel und Fremdschlüssel, Abfragen mit SQL, Transaktionen nach dem ACID-Prinzip. Für Bestellungen, Buchungen und Rechnungen ist das genau richtig. Aber was ist mit einem Produktkatalog, in dem ein E-Bike ganz andere Merkmale hat als ein Fahrradschloss? Mit Millionen von Sensormesswerten pro Tag? Mit den Daten einer App, die jede Woche neue Felder bekommt? Hier spielen NoSQL-Datenbanken ihre Stärken aus. Im Mittelpunkt dieses Artikels steht die bekannteste Gruppe, die Dokumentendatenbanken (Document Stores). Sie speichern ihre Daten als JSON-Dokumente; wie JSON notiert wird, erklärt der Artikel JSON.

Das Beispiel: der Medienbestand einer Stadtbibliothek

Eine Stadtbibliothek verleiht Bücher, Filme und Brettspiele. Jede Medienart hat eigene Merkmale: Bücher haben eine ISBN und eine Seitenzahl, Filme eine Laufzeit und eine Altersfreigabe, Brettspiele eine Spielerzahl und eine Spieldauer. Im relationalen Modell gibt es dafür drei unbefriedigende Lösungen:

• eine breite Tabelle medium mit allen Spalten für alle Medienarten – bei einem Buch bleiben laufzeit_min, fsk, spieler_min und spieler_max leer (NULL),

• je Medienart eine eigene Tabelle – jede neue Medienart (Hörbuch, Tonie-Figur, Nähmaschine) erfordert eine Änderung des Datenbankschemas und des Programmcodes,

• eine Merkmalstabelle merkmal(medium_id, name, wert) – flexibel, aber alle Werte sind Text, und für jede Anzeige braucht man einen JOIN.

Ein Buch mit allen seinen Angaben ist eigentlich ein zusammengehöriges Ding. Genau so speichert es eine Dokumentendatenbank:

{
  "_id": 4711,
  "art": "Buch",
  "titel": "Sternenstaub über Sennestadt",
  "isbn": "978-3-16-148410-0",
  "seiten": 192,
  "autorinnen": ["Mara Lindqvist"],
  "schlagworte": ["Jugendbuch", "Umwelt"],
  "ausleihbar": true
}

Das Brettspiel steht in derselben Sammlung, hat aber andere Felder – und das ist erlaubt:

{
  "_id": 5120,
  "art": "Brettspiel",
  "titel": "Hafenkräne",
  "spieler": { "min": 3, "max": 4 },
  "spieldauer_min": 75,
  "ausleihbar": false
}

Warum überhaupt ein Datenbanksystem?

Viele Datenbestände beginnen als Tabellenkalkulation: eine Liste der Geräte, der Wartungen, der Kund*innen. Das geht gut, solange eine Person mit wenigen Hundert Zeilen arbeitet. Wächst der Bestand, wird die Datei langsam, mehrere Personen überschreiben sich gegenseitig, und niemand weiß mehr, welche Kopie aktuell ist. Ein Datenbankmanagementsystem (DBMS) – ob relational wie MariaDB oder NoSQL wie MongoDB – löst diese Probleme:

Die Tabellenkalkulation bleibt ein gutes Werkzeug zum Auswerten und Darstellen – die Daten kommen dann aus der Datenbank (z. B. als CSV-Export).

Was bedeutet NoSQL?

NoSQL wird heute meist als „Not only SQL“ gelesen: Gemeint sind Datenbanksysteme, die ihre Daten nicht im relationalen Modell (Tabellen mit festen Spalten und Fremdschlüsseln) ablegen. „Nicht nur“ deshalb, weil viele dieser Systeme durchaus eine SQL-ähnliche Abfragesprache anbieten und umgekehrt relationale Systeme wie MariaDB, MySQL oder PostgreSQL inzwischen JSON-Spalten verarbeiten können. NoSQL ist also kein Gegensatz zu SQL, sondern eine Ergänzung.

Die NoSQL-Systeme werden nach ihrem Datenmodell in vier große Gruppen eingeteilt:

Daneben gibt es Zeitreihendatenbanken (siehe unten), Suchmaschinen-Indizes, Vektordatenbanken (für die Ähnlichkeitssuche, z. B. bei KI-Anwendungen), Objektdatenbanken (speichern Objekte einer Programmiersprache direkt), ältere hierarchische und netzwerkartige Datenbanken sowie Systeme, die mehrere Modelle gleichzeitig unterstützen (multi-model).

Der wesentliche Unterschied in einem Satz: SQL-Datenbanken speichern Daten relational in Tabellen mit festem Schema und logischen Verknüpfungen und werden einheitlich mit SQL abgefragt; NoSQL-Datenbanken speichern Daten nicht relational in anderen Formaten (Dokumente, Schlüssel-Wert-Paare, Graphen …), meist mit flexiblem Schema und herstellerspezifischen Abfrage-APIs. SQL-Datenbanken spielen ihre Stärken bei stark verknüpften Daten und Transaktionen aus, NoSQL-Datenbanken bei wechselnden oder unstrukturierten Daten und sehr großen, verteilten Datenmengen.

Zeitreihendatenbanken für Messwerte

Sensoren liefern im Sekunden- oder Minutentakt Messwerte: Temperatur, Luftfeuchte, CO₂, Stromverbrauch, Position. Jeder Datensatz besteht im Kern aus einem Zeitstempel, einem Messwert und wenigen Metainformationen (Tags), z. B. Sensor und Raum:

klima,raum=A104,sensor=klima-a104 co2=812,temp=21.4 1793091600

(Beispiel im Line Protocol von InfluxDB: Messung, Tags, Felder, Zeitstempel – hier in Sekunden; ohne Angabe der Genauigkeit erwartet InfluxDB Nanosekunden.)

Eine Zeitreihendatenbank (time series database, z. B. InfluxDB, TimescaleDB, Prometheus) ist für genau diese Daten optimiert. Vorteile gegenüber anderen Datenmodellen:

• Schnelles Schreiben: Neue Werte werden fast immer am Ende angehängt; das System ist auf sehr viele Schreibvorgänge pro Sekunde ausgelegt.

• Zeitbezogene Abfragen sind eingebaut: Mittelwert, Minimum, Maximum je Zeitfenster („Durchschnitt der letzten Stunde je Raum“), Lücken füllen, Trends.

• Aufbewahrungsregeln: Alte Rohdaten werden automatisch gelöscht oder zu Stunden- oder Tageswerten verdichtet (Downsampling).

• Starke Kompression: Aufeinanderfolgende Zeitstempel und ähnliche Werte lassen sich sehr gut komprimieren.

• Einfache Skalierung auf große Datenmengen, oft verteilt auf mehrere Server.

Und eine relationale Datenbank? Sie kann Messwerte in einer Tabelle messwert(zeit, sensor_id, wert) speichern. Fortlaufende Messwerte stehen aber untereinander in keiner Beziehung, sie folgen nur zeitlich aufeinander. Fremdschlüssel, JOINs, Normalisierung und Transaktionen über mehrere Tabellen werden kaum gebraucht, kosten aber Ressourcen; bei sehr vielen Werten wachsen Tabelle und Indizes schnell, und das Löschen alter Daten wird aufwendig. Für Stammdaten der Sensoren (Standort, Typ, Grenzwerte) ist die relationale Datenbank dagegen gut geeignet – häufig werden beide kombiniert.

In Aufgaben und in der Praxis begegnen Dir am häufigsten die Dokumentendatenbanken – um sie geht es im Rest des Artikels.

Dokumente in JSON-Notation

Dokumentendatenbanken speichern jeden Datensatz als Dokument in der JavaScript Object Notation (JSON). Für diesen Artikel genügen die Grundregeln:

• Ein Objekt steht in geschweiften Klammern { } und enthält Schlüssel-Wert-Paare "schluessel": wert; der Schlüssel steht immer in doppelten Anführungszeichen.

• Ein Array steht in eckigen Klammern [ ] und enthält eine geordnete Liste von Werten.

• Werte sind Zeichenketten ("Momo"), Zahlen (192, 21.5), Wahrheitswerte (true, false), null oder wieder Objekte und Arrays. Dadurch lassen sich Daten beliebig tief verschachteln.

Syntax, Datentypen, typische Fehler und die Prüfung mit JSON Schema erklärt ausführlich der Artikel JSON. Wie sich JSON gegenüber den Austauschformaten XML und CSV schlägt, zeigt der Artikel Datenaustauschformate.

Begriffe: von der Tabelle zum Dokument

Eine Dokumentendatenbank ist ähnlich gegliedert wie eine relationale Datenbank – die Begriffe heißen nur anders:

Der wichtigste Unterschied steckt in der letzten Zeile: Alle Zeilen einer Tabelle haben dieselben Spalten. Die Dokumente einer Collection dürfen unterschiedliche Felder haben (schemafrei bzw. flexibles Schema). MongoDB speichert die Dokumente intern im binären Format BSON (Binary JSON), das zusätzliche Datentypen wie Datum, Ganzzahl, Dezimalzahl und ObjectId kennt. Nach außen arbeitest Du mit JSON-ähnlicher Notation.

Von Tabellen zu Dokumenten

Angenommen, die Bibliothek hat ihre Filialen und die dort aufgestellten Abholschränke bisher relational gespeichert:

Schritt 1: Tabellen in JSON umwandeln

Die einfachste Umwandlung bildet die Tabellen 1:1 ab:

• jede Tabelle wird ein Array (bzw. eine Collection),

• jede Zeile wird ein Objekt (Dokument),

• jede Spalte wird ein Feld – der Spaltenname ist der Schlüssel, der Inhalt der Wert,

• Zahlen stehen ohne, Texte mit Anführungszeichen, NULL wird null,

• der Fremdschlüssel bleibt ein ganz normales Feld.

[
  { "filiale_id": 1, "name": "Stadtbibliothek Mitte", "stadtteil": "Mitte" },
  { "filiale_id": 2, "name": "Stadtteilbibliothek Nord", "stadtteil": "Schildesche" }
]

[
  { "schrank_id": 10, "filiale_id": 1, "standort": "Eingang Neumarkt", "faecher": 48 },
  { "schrank_id": 11, "filiale_id": 1, "standort": "Parkhaus", "faecher": 24 },
  { "schrank_id": 12, "filiale_id": 2, "standort": "Haupteingang", "faecher": 32 }
]

Damit hast Du zwar JSON, aber noch keine Stärke der Dokumentendatenbank genutzt: Die Daten einer Filiale sind weiterhin auf zwei Collections verteilt.

Schritt 2: einbetten

Die Bibliotheks-App zeigt die Abholschränke immer zusammen mit der Filiale an, und jede Filiale hat nur wenige Schränke. Dann gehören die Schränke in das Filialdokument – als Array von eingebetteten Dokumenten (embedded documents):

[
  {
    "filiale_id": 1,
    "name": "Stadtbibliothek Mitte",
    "stadtteil": "Mitte",
    "abholschraenke": [
      { "schrank_id": 10, "standort": "Eingang Neumarkt", "faecher": 48 },
      { "schrank_id": 11, "standort": "Parkhaus", "faecher": 24 }
    ]
  },
  {
    "filiale_id": 2,
    "name": "Stadtteilbibliothek Nord",
    "stadtteil": "Schildesche",
    "abholschraenke": [
      { "schrank_id": 12, "standort": "Haupteingang", "faecher": 32 }
    ]
  }
]

Beachte: Der Fremdschlüssel filiale_id entfällt in den eingebetteten Schränken, denn die Zugehörigkeit ergibt sich aus der Verschachtelung. Die schrank_id darf bleiben, wenn Schränke einzeln angesprochen werden sollen. Jetzt liefert ein einziger Lesezugriff alles, was die App braucht – ohne JOIN.

Einbetten oder referenzieren?

Eine harte Grenze gibt es zusätzlich: Ein MongoDB-Dokument darf höchstens 16 MB groß sein. Wer alle Ausleihen eines beliebten Buches einbettet, stößt irgendwann daran.

Eingebettete Daten sind bewusst redundant: Würde man den Namen der Autorin in jedes Buchdokument kopieren, müsste man eine Namensänderung in allen Büchern nachziehen. Dokumentendatenbanken nehmen diese Redundanz in Kauf, um schneller lesen zu können – die Normalisierung relationaler Datenbanken verfolgt das umgekehrte Ziel (siehe Normalisierung).

Mit Dokumenten arbeiten (MongoDB)

In MongoDB greifst Du nicht mit SQL zu, sondern über eine Programmierschnittstelle (API) mit Methoden wie find(), insertOne() oder updateOne() – aus der MongoDB-Shell mongosh oder aus Java, Python, JavaScript & Co. Die Filter sind selbst JSON-Dokumente:

// alle ausleihbaren Bücher mit mehr als 300 Seiten, nur Titel und Seiten anzeigen
db.medien.find(
  { art: "Buch", ausleihbar: true, seiten: { $gt: 300 } },
  { titel: 1, seiten: 1 }
)

// Brettspiele ab 2 Spieler*innen: Punktnotation für eingebettete Felder
db.medien.find({ "spieler.min": { $lte: 2 } })

// Filter auf ein Array: findet alle Dokumente, deren Array "schlagworte" den Wert enthält
db.medien.find({ schlagworte: "Umwelt" })

// neues Dokument einfügen
db.medien.insertOne({ art: "Hörbuch", titel: "Momo", laufzeit_min: 412 })

// Feld ändern ($set) und Element an ein Array anhängen ($push)
db.medien.updateOne({ _id: 4711 }, { $set: { ausleihbar: false }, $push: { schlagworte: "Klassiker" } })

Zum Vergleich die erste Abfrage in SQL: SELECT titel, seiten FROM medium WHERE art = 'Buch' AND ausleihbar = TRUE AND seiten > 300; – anders als hier liefert MongoDB bei der Projektion { titel: 1, seiten: 1 } zusätzlich das Feld _id mit, solange es nicht mit _id: 0 ausgeblendet wird. Felder, die in einem Dokument fehlen, erfüllen eine Bedingung wie seiten > 300 einfach nicht – das Dokument erscheint nicht im Ergebnis.

Auch relationale Systeme können inzwischen mit JSON umgehen: MariaDB kennt den Datentyp JSON (intern LONGTEXT mit Prüfung JSON_VALID) und Funktionen wie JSON_VALUE(spalte, '$.spieler.min') oder JSON_ARRAYAGG(). Für einzelne flexible Merkmale in einer sonst relationalen Datenbank ist das oft der pragmatische Weg.

Flexibles Schema: Chance und Risiko

Das flexible Schema ist der größte Vorteil von Dokumentendatenbanken: Ein neues Feld (z. B. barrierefrei bei den Abholschränken) kann sofort gespeichert werden, ohne ALTER TABLE, ohne Migration und ohne Ausfallzeit. Das beschleunigt die Entwicklung, besonders in frühen Projektphasen und bei Daten, deren Struktur sich häufig ändert.

Die Kehrseite: Wenn die Datenbank nichts prüft, prüft niemand. Typische Datenqualitätsprobleme sind

• uneinheitliche Feldnamen (seiten, Seiten, seitenzahl),

• wechselnde Datentypen ("seiten": "192" als Text in einem, 192 als Zahl im anderen Dokument),

• fehlende Pflichtfelder (ein Medium ohne titel).

Gegenmaßnahmen: eine klare Datenmodellierung trotz Schemafreiheit (dokumentierte Felder), Prüfung im Programm vor dem Speichern, und die Schemavalidierung der Datenbank (in MongoDB per $jsonSchema), die Dokumente mit falschen Typen oder fehlenden Pflichtfeldern zurückweist. Wie ein solches Schema aufgebaut ist, zeigt der Artikel JSON.

Verteilte Datenbanken: ACID, CAP und BASE

Relationale Datenbanken garantieren für Transaktionen die ACID-Eigenschaften (Atomicity, Consistency, Isolation, Durability) – ausführlich erklärt im Artikel Datenbankkonzepte. Auf einem Server ist das gut machbar. Viele NoSQL-Systeme sind aber dafür gebaut, Daten auf viele Server zu verteilen (Replikation für Ausfallsicherheit, Sharding für große Datenmengen).

Skalierung: nach oben oder in die Breite

• Vertikale Skalierung (scale up): ein größerer Server mit mehr CPU, RAM und schnelleren SSDs. Einfach, aber teuer und irgendwann am Ende.

• Horizontale Skalierung (scale out): mehr Server, die sich die Daten und die Last teilen. Theoretisch fast unbegrenzt, aber die Server müssen sich über die Daten abstimmen.

Relationale Datenbanken skalieren klassisch vertikal; viele NoSQL-Datenbanken sind von Anfang an für die horizontale Skalierung ausgelegt.

Das CAP-Theorem

Ein verteiltes System soll drei Dinge leisten:

• Consistency (Konsistenz): Alle Knoten liefern zur gleichen Zeit denselben, aktuellen Stand.

• Availability (Verfügbarkeit): Jede Anfrage bekommt eine Antwort.

• Partition tolerance (Partitionstoleranz): Das System arbeitet weiter, auch wenn die Netzwerkverbindung zwischen Knoten unterbrochen ist.

Das CAP-Theorem (Eric Brewer, 2000) besagt: Bei einer Netzwerkstörung (P) muss sich ein verteiltes System entscheiden, ob es konsistent bleibt (und dann Anfragen ablehnt) oder verfügbar bleibt (und dann eventuell veraltete Daten liefert). Beides zugleich geht nicht. Deshalb ist es schwer, in verteilten Datenbanken alle ACID-Eigenschaften einzuhalten und gleichzeitig eine hohe Verfügbarkeit zu erreichen.

BASE statt ACID

Viele NoSQL-Systeme entscheiden sich für Verfügbarkeit und arbeiten nach dem BASE-Prinzip:

• Basically Available: Das System antwortet grundsätzlich immer, auch bei Teilausfällen.

• Soft State: Der Zustand kann sich ändern, ohne dass gerade jemand schreibt, weil Änderungen noch zwischen den Knoten verteilt werden.

• Eventually Consistent: Wenn keine neuen Änderungen kommen, sind nach kurzer Zeit alle Kopien wieder gleich (letztendliche Konsistenz).

Ob das tragbar ist, hängt von den Daten ab: Wenn eine Anzeige einige Sekunden lang einen alten Stand zeigt, ist das meist unkritisch. Wenn dagegen zwei Personen gleichzeitig den letzten freien Platz buchen oder ein Kontostand doppelt abgebucht wird, braucht man strenge Konsistenz.

Die Grenzen verschwimmen übrigens: MongoDB unterstützt seit Version 4.0 Transaktionen über mehrere Dokumente mit ACID-Garantien (zunächst in Replica Sets, seit Version 4.2 auch in verteilten Sharded Clusters), und es gibt verteilte SQL-Datenbanken. Die Faustregel „relational = ACID, NoSQL = BASE“ beschreibt die ursprüngliche Ausrichtung, nicht jedes heutige Produkt.

Big Data: wenn klassische Modelle an Grenzen stoßen

Big Data bezeichnet Datenmengen, die so groß, so schnell entstehend oder so vielfältig sind, dass klassische Datenbanken und Auswertungsverfahren sie kaum noch verarbeiten können. Beschrieben wird Big Data mit den drei V:

• Volume (Menge): Datenmengen im Bereich von Tera- bis Petabyte, z. B. die Positionsdaten Tausender Fahrzeuge über Jahre.

• Velocity (Geschwindigkeit): Die Daten entstehen sehr schnell und sollen oft in Echtzeit verarbeitet werden, z. B. viele Sensorwerte pro Sekunde.

• Variety (Vielfalt): strukturierte (Tabellen), halbstrukturierte (JSON, Protokolle) und unstrukturierte Daten (Bilder, Videos, Texte, Audio) gemischt.

Oft kommen Veracity (Verlässlichkeit, Datenqualität) und Value (der Nutzen, der sich aus den Daten ziehen lässt) hinzu. Mehr zu Big Data im Zusammenspiel mit Edge- und Cloud-Computing steht im Artikel Edge, Fog und Cloud.

Eignen sich ER-Modell und relationales Datenmodell für Big Data? In der klassischen Form nur eingeschränkt: Das ER-Modell setzt voraus, dass die Struktur der Daten vorab bekannt und fest ist – unstrukturierte oder sich ständig ändernde Daten passen nicht in ein festes Tabellenschema. Relationale Datenbanken skalieren vor allem vertikal und kommen bei sehr hohen Schreibraten an Grenzen. Für Big Data werden deshalb meist NoSQL-Datenbanken (Spaltenfamilien, Dokumente, Zeitreihen), verteilte Dateisysteme und Data Lakes eingesetzt. Für die gut strukturierten Teile (Kundendaten, Verträge, verdichtete Kennzahlen im Data Warehouse) bleibt das relationale Modell sinnvoll; es gibt auch verteilte SQL-Datenbanken. Eine gute Antwort entscheidet sich also klar und begründet mit der Art der Daten.

Relational oder dokumentenorientiert? Eine Entscheidungshilfe

Für eine relationale Datenbank sprechen z. B.: Die Daten sind klar strukturiert und stark miteinander verknüpft; Geld, Bestände oder Plätze werden gebucht (Transaktionssicherheit, ACID); die referentielle Integrität soll das DBMS sicherstellen; vielfältige Auswertungen mit SQL sind nötig; das Team kennt SQL.

Für eine dokumentenorientierte Datenbank sprechen z. B.: Die Datensätze haben unterschiedliche oder sich häufig ändernde Felder; zusammengehörige Daten werden fast immer gemeinsam gelesen; die Datenmenge oder die Zahl der Zugriffe ist sehr groß und soll auf viele Server verteilt werden; die Daten kommen ohnehin als JSON (z. B. aus einer REST-API) und sollen so weiterverarbeitet werden.

In der Praxis kombinieren viele Systeme beide Welten (polyglotte Persistenz): Bestellungen und Rechnungen in MariaDB, der Produktkatalog in einer Dokumentendatenbank, Sitzungsdaten in Redis.

Wenn Du in einer Aufgabe eine Variante vorschlagen sollst, gilt: Entscheide Dich klar für eine Variante und begründe mit Argumenten, die zum Anwendungsfall passen. „NoSQL ist moderner“ ist kein Argument, „Die Räume haben je nach Typ unterschiedliche Ausstattungsmerkmale, die sich ohne Schemaänderung speichern lassen“ schon.

Typische Missverständnisse

• „NoSQL heißt: kein SQL.“ – Gemeint ist „nicht nur SQL“ bzw. „nicht relational“. Viele Systeme haben SQL-ähnliche Abfragesprachen.

• „Schemafrei heißt: Ich muss nichts modellieren.“ – Gerade die Frage „einbetten oder referenzieren?“ verlangt eine sorgfältige Modellierung, die sich an den Zugriffen der Anwendung orientiert.

• „NoSQL ist immer schneller.“ – Schneller ist das Lesen zusammengehöriger Daten in einem Dokument. Auswertungen über viele Dokumente oder viele Beziehungen sind in einer relationalen Datenbank oft einfacher und schneller.

• „Zahlen in Anführungszeichen sind auch Zahlen.“ – "192" ist ein String. Sortieren und Rechnen funktionieren dann nicht wie erwartet.

Leitfragen

1. Was bedeutet NoSQL, und welche vier Arten von NoSQL-Datenbanken gibt es? Nenne für jede ein Einsatzbeispiel. Antwort

NoSQL wird meist als „Not only SQL“ gelesen und meint Datenbanksysteme, die ihre Daten nicht im relationalen Modell ablegen. Es gibt Schlüssel-Wert-Datenbanken (z. B. Cache oder Sitzungsdaten), Dokumentendatenbanken (Produktkataloge, Profile), Spaltenfamilien-Datenbanken (große Mengen an Messwerten oder Protokollen) und Graphdatenbanken (Wegenetze, Empfehlungen); siehe Abschnitt „Was bedeutet NoSQL?“.

2. Welche relationalen Fachbegriffe entsprechen Collection, Document und Field? Antwort

Eine Collection (Sammlung) entspricht einer Tabelle, ein Document (Dokument) einem Datensatz bzw. einer Zeile und ein Field (Feld) einer Spalte bzw. einem Attribut. Das Feld _id übernimmt die Rolle des Primärschlüssels; siehe Abschnitt „Begriffe: von der Tabelle zum Dokument“.

3. Wie wandelst Du zwei über einen Fremdschlüssel verbundene Tabellen in JSON um, und wie bettest Du die Kind-Datensätze in das Elterndokument ein? Wann solltest Du lieber referenzieren? Antwort

Zuerst wird jede Tabelle ein Array, jede Zeile ein Objekt und jede Spalte ein Feld; der Fremdschlüssel bleibt ein normales Feld. Beim Einbetten nimmst Du die Kind-Datensätze als Array in das Elterndokument auf und lässt den Fremdschlüssel weg, weil sich die Zugehörigkeit aus der Verschachtelung ergibt. Referenzieren ist besser, wenn die Daten oft einzeln gelesen oder geändert werden, unbegrenzt wachsen können oder von vielen Dokumenten gebraucht werden (n:m); siehe Abschnitt „Schritt 1: Tabellen in JSON umwandeln“, Abschnitt „Schritt 2: einbetten“ und Abschnitt „Einbetten oder referenzieren?“.

4. Nenne Kriterien, in denen sich relationale und dokumentenorientierte Datenbanken unterscheiden, und gib die jeweilige Ausprägung an. Antwort

Datenmodell (Tabellen mit Fremdschlüsseln vs. verschachtelte Dokumente in Collections), Schema (fest vs. flexibel), Abfragesprache (standardisiertes SQL vs. herstellerspezifische API), Beziehungen (JOIN vs. Einbetten), Redundanz (gering durch Normalisierung vs. bewusst höher), Skalierung (vor allem vertikal vs. vor allem horizontal) sowie Transaktionen (ACID vs. ursprünglich BASE); siehe Abschnitt „Relational oder dokumentenorientiert? Eine Entscheidungshilfe“.

5. Warum ist es schwer, in einer verteilten Datenbank ACID und hohe Verfügbarkeit zugleich zu erreichen, und was bedeutet BASE? Antwort

Nach dem CAP-Theorem muss sich ein verteiltes System bei einer Netzwerkstörung entscheiden, ob es konsistent bleibt und Anfragen ablehnt oder verfügbar bleibt und eventuell veraltete Daten liefert. Viele NoSQL-Systeme wählen die Verfügbarkeit und arbeiten nach BASE: Basically Available, Soft State und Eventually Consistent, d. h. nach kurzer Zeit sind alle Kopien wieder gleich; siehe Abschnitt „Das CAP-Theorem“ und Abschnitt „BASE statt ACID“.

6. Für welche Daten einer Anwendung würdest Du eine relationale, für welche eine dokumentenorientierte Datenbank vorschlagen – und mit welchen Argumenten? Antwort

Relational speicherst Du klar strukturierte, stark verknüpfte Daten und alles, was gebucht wird (Geld, Bestände, Plätze), weil dort ACID, referentielle Integrität und SQL-Auswertungen zählen. Dokumentenorientiert eignen sich Daten mit wechselnden Feldern, die meist zusammen gelesen werden, sehr große Datenmengen oder Daten, die ohnehin als JSON ankommen, etwa ein Produktkatalog. Entscheide Dich klar und begründe mit Argumenten aus dem Anwendungsfall; siehe Abschnitt „Relational oder dokumentenorientiert? Eine Entscheidungshilfe“.

7. Welche Vorteile hat ein DBMS gegenüber einer Tabellenkalkulation, und welche Vorteile bietet eine Zeitreihendatenbank für Messwerte? Antwort

Ein DBMS erlaubt gleichzeitigen Mehrbenutzerzugriff, schützt die Daten mit Benutzerkonten und Rechten, sichert die Integrität durch Datentypen und Schlüssel, bietet Transaktionen, ist auch bei großen Datenmengen schnell und lässt sich im Betrieb sichern. Eine Zeitreihendatenbank schreibt fortlaufende Messwerte (Zeitstempel, Wert, Tags) sehr schnell, bietet eingebaute Zeitfunktionen (Mittelwert je Zeitfenster), löscht oder verdichtet alte Daten automatisch und komprimiert stark; siehe Abschnitt „Warum überhaupt ein Datenbanksystem?“ und Abschnitt „Zeitreihendatenbanken für Messwerte“.

8. Was bedeutet Big Data, und passt dafür das relationale Modell? Antwort

Big Data sind Datenmengen, die durch Volume (Menge), Velocity (Geschwindigkeit) und Variety (Vielfalt) klassische Datenbanken überfordern. ER-Modell und relationales Modell setzen eine feste, vorab bekannte Struktur voraus und skalieren vor allem vertikal; für unstrukturierte, schnell entstehende Daten sind NoSQL-Datenbanken und verteilte Speicher besser geeignet, für strukturierte Teile bleibt das relationale Modell sinnvoll; siehe Abschnitt „Big Data“.

Links und weitere Informationen

• Voraussetzungen auf oer-informatik.de: Das Relationenmodell, JSON, Normalisierung, Datenbankkonzepte: Transaktionen und ACID

• Verwandte Beiträge: REST-Grundlagen (JSON als Austauschformat von Web-APIs), Datenaustauschformate: CSV, XML und JSON vergleichen, Edge, Fog und Cloud: Big Data und Predictive Maintenance, MQTT (Sensordaten übertragen)

• Übungen: Übungsaufgaben zu NoSQL und Dokumentendatenbanken

• zum Nachschlagen: MongoDB-Handbuch (englisch): Dokumente, Datenmodellierung, Abfragen und MongoDB: Limits and Thresholds

• zum Nachschlagen (MariaDB): MariaDB: JSON-Funktionen

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “NoSQL und Dokumentendatenbanken (Document Stores)” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/documentstore veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/db-design/datenbankentwurf. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]