Datenbank-Modelle

Es gibt unterschiedliche Möglichkeiten, Daten in Datenbanken zu speichern. Je nach Anforderung an die Speicherung und die Abruf- und Such-Möglichkeiten wählt man ein entsprechendes Modell.

Das relationale Datenbank-Modell ist wohl das gängigste. Es basiert mathematisch auf der Mengenlehre und speichert Daten in Tabellen ab. In der einfachsten Form kann das eine Excel-Tabelle sein. Geht man einen Schritt weiter, wählt man das Programm "Microsoft Access", was eine seit 1991 existierende relationale Datenbank ist. Sie haben dieses Programm übrigens auf Ihrem Computer auch installiert! Hier sehen Sie einen Ausschnitt aus einer Tabelle mit Kunden-Daten:

Es ist dasjenige Datenbank-Modell, welches wir in diesem Kurs in den weiteren Kapiteln behandeln. Daten werden u.a. mit Hilfe der Abfrage-Sprache "SQL" gesucht und gefiltert.

Relationale Datenbanken sind in der Regel sauschnell, wenn es darum geht, Tabellen beispielsweise zu sortieren oder in einer Spalte nach einem Wert zu suchen, beispielsweise nach einem Nachnamen. Der Grund dafür liegt daran, dass nebst der eigentlichen Tabelle, welche aus vielen Spalten besteht, sog. Indizes (Singular: Index) angelegt werden können. Diese Indizes bilden nur einzelne Spalten ab und können beispielsweise sortiert werden. Auch, wenn die eigentliche Tabelle mit den Daten drin nicht sortiert ist, lässt sie sich durch den Index sehr schnell sortieren.

Will man Daten in einer relationalen Datenbank speichern, dann geschieht dies eben in Tabellen. Und wenn Sie die obige Beispiel-Tabelle anschauen, dann sehen Sie, dass jede Spalte relativ wenig Daten enthält. Ein Firmenname, ein Vorname oder ein Ort (nur, um ein paar Beispiele zu nennen) enthalten wohl fast nie Text mit 1000 Zeichen Länge. Das ist in der Regel viel kürzer. Andere Spalten enthalten Zahlen, beispielsweise Postleitzahlen oder Länder-Codes.

Relationale Datenbanken sind in ihrer Grundform jedoch ziemlich schlecht im Speichern grösserer Daten wie grosse Word-Dokumente, Bilder oder Videos. Dazu sind multimediale Datenbank-Modelle besser geeignet. Es handelt sich hierbei teilweise immer noch um relationale Datenbanken, aber mit der zusätzlichen Möglichkeit, Bilder, Videos und generell Dokumente zu "verschlagworten", das heisst, wichtige Meta-Informationen wie Videolänge, Grösse der Datei, Änderungsdatum, etc. in der Datenbank zu speichern. Die eigentliche Medien-Datei wird dann allenfalls ausserhalb des Datenbank-Systems gespeichert, meist im Dateisystem.

SQL-Abfragen von relationalen Datenbanken liefern präzise Ergebnisse. Beispielsweise wollen wir wissen, welche Kund\*innen im letzten Monat Schuhe mit Schuhgrösse grösser als 41 bestellt haben. Vielleicht haben wir gerade eine Aktion am Laufen und wollen genau diese Personen mit einem Werbe-E-Mail anschreiben. Bei solchen Abfragen in relationalen Datenbanken kriegen wir präzise Antworten.

Bei Multimedia-Datenbanken ist ein präzises Suchergebnis unter Umständen gar nicht möglich. Wir möchten beispielsweise wissen, welche Sonnenuntergänge in unserer Bild-Datenbank vorhanden sind. Vielleicht haben wir als Meta-Daten sog. Tags verwendet, und ein Tag könnte "Sonnenuntergang" heissen. Somit kann mir die Multimedia-Datenbank alle Bilder mit dem Tag "Sonnenuntergang" liefern. Das wäre wieder eine stinknormale SQL-Abfrage. Aber Multimedia-Datenbanken bieten beispielsweise auch eine spezielle Suche an, das sog. "Retrieval", welches direkt im Bildmaterial nach Ähnlichkeiten sucht und so versucht, Sonnenuntergänge zu finden.

Eine weitere Möglichkeit ist es, Daten in ganz normalen Text-Dateien zu speichern, diese aber mit Hilfe von XML oder JSON zu strukturieren. Im folgenden Bild sind Ausschnitte von zwei Text-Dateien abgebildet, links im JSON-Format, rechts im XML-Format:

Gängige Programmiersprachen bieten Libraries, welche den Zugriff auf solche Daten ermöglichen. Die Abfragesprache SQL wurde ursprünglich zwar für relationale Datenbanken erfunden, wird aber in ähnlicher Schreibweise häufig auch bei diesen anderen Datenbank-Modellen verwendent; einfach, weil es die gängigste Abfrage-Sprache ist.

Der Vorteil von text-basierten Datenbanken (egal, ob JSON, XML oder sonstwas) ist, dass man die Datenbank mit einem einfachen Texteditor (z.B. "Notepad" in Windows oder "nano" in Linux) öffnen kann. Die Daten sind sofort lesbar. Eine relationale Datenbank weist ein sog. "binäres" Format auf. Wenn Sie eine solche Datei mit einem Text-Editor öffnen, kriegen Sie zum grossen Teil nur Buchstabensalat angezeigt:

Text-basierte Datenbanken sind nicht so schnell wie relationale Datenbanken, weil hier immer die ganze Datei sequenziell durchsucht werden muss, wenn man etwas sucht. Ebenfalls fehlt die Möglichkeit, auf gewissen Feldern einen Index zu setzen (um beispielsweise danach zu sortieren). Dafür sind die Daten ohne speziell zu installierenden Programmen sofort lesbar und auch veränderbar. Öffnen Sie die Datei einfach in einem Text-Editor. Zugegeben, obige Darstellung ist aber überhaupt nicht "user-friendly". XML-Files können aber ohne Probleme in Excel geöffnet werden. Und dann sieht es plötzlich wieder ganz anständig wie eine Tabelle aus:

Auch JSON-Dateien lassen sich ohne Problem in Excel öffnen, z.B. über diesen Punkt im Menüband:

Seit Big Data, also seit dem Zeitpunkt, als Firmen begannen, mehr oder weniger zufällig x-beliebige Daten zu speichern, z.B. über unser Smartphone, über all die Geräte im Haushalt, welche eine Wifi-Verbindung haben, etc., fallen ungemein viele, aber auch ungemein unstrukturierte Daten an.

Relationale Datenbanken weisen immer eine klare Struktur auf. In jeder Tabelle ist für jede Spalte klar definiert, was und in welchem Format darin gespeichert wird. Die Spalte "Name" darf beispielsweise Text enthalten. Die Spalte "Kunden-Segment" darf beispielsweise ausschliesslich Zahlen zwischen 1 und 9 enthalten. Und die Spalte "Zuletzt geändert" darf ausschliesslich ein korrektes Datum und eine Uhrzeit, einen sog. Timestamp, enthalten.

Bei Big Data ist diese Stukturiertheit nicht mehr gegeben. Einerseits haben wir Gesundheitsdaten einer Smartwatch, dazu passende örtliche Daten des verknüpften Smartphones. Dann Daten der Waschmaschine (aha, die Kund\*in wäscht immer dann auf 30°C mit Sparprogramm, wenn sie weniger als 30min joggt. Joggt sie länger, wäscht sie auf 40°C ohne Sparprogramm), welche irgendwie in Verbindung gebracht werden müssen. Und dann haben wir noch Daten vom Personenlift im Haus.

Der Begriff "NoSQL" bezieht sich auf Datenbank-Modelle, welche mit grossen Datenmengen und unstrukturierten Daten im Bereich Big Data zurecht kommen.

"NoSQL" kann je nach Quelle was Unterschiedliches heissen:

• NoSQL für "kein SQL"
• NoSQL für "not only SQL"

Obwohl es vor ein paar Jahren Versuche gab, reine Datenbanken ohne jegliches SQL zu entwickeln. Ein solches Produkt ist beispielsweise MongoDB. Wenn wir bei MongoDB von einer "NoSQL-Datenbank" sprechen, dann meinen wir in der Tat: KEIN SQL. MongoDB enthält keine Tabellen im klassischen Sinn, sondern die Daten werden in einem JSON-ähnlichen Format gespeichert.

Um Daten aus einer SQL-Datenbank rauszuholen, gibt es folgenden Befehl:

SELECT name, age FROM users WHERE age > 18;

Bei MongoDB sieht der gleiche Befehl wie folgt aus:

db.users.find({ age: { $gt: 18 } }, { name: 1, age: 1 })

Unterdessen die grossen Anbieter von relationalen Datenbanken ihre Software mit Funktionalitäten für Big Data erweitert. Dann spricht man bei einer "NoSQL-Datenbank" eben eher davon, dass sie "nicht nur" SQL kann, sondern auch andere Auswertungsmöglichkeiten.