© saicle/Shutterstock.com
PHP Magazin
Datenmodellierung in nicht relationalen Datenbanken

Datenmodellierung in nicht relationalen Datenbanken

„Erstelle ein korrekt normalisiertes Datenbankschema!“ lautet eine beliebte Übungsaufgabe für angehende Informatiker. Das Erkennen und Beseitigen von Redundanzen geht irgendwann ins Blut über und wird alltägliches Handwerkszeug. Doch was ist zu beachten, wenn die Datenbank nicht relational ist, sondern aus dem Kanon der „neuen“, nicht relationalen Datenbanken à la MongoDB, CouchDB, Riak oder Redis stammt?

Jan Steemann


Längst sind nicht relationale Datenbanken, häufig etwas nichtssagend als „NoSQL“-(Not-only-SQL-)Datenbanken bezeichnet, im technologischen Mainstream und in Real-Life-Projekten angekommen. Systemarchitekten ersetzen das relationale Datenbanksystem komplett durch einen der Newcomer oder nehmen für Spezialaufgaben Vertreter dieser Spezies ins Architekturportfolio auf.

Für Entwickler bedeutet das ein Umdenken bei der Modellierung ihrer Persistenzschicht. Die Modellierung in relationalen Datenbanken beruht auf der Erstellung eines normalisierten Relationenmodells mit Tupeln und Relationen, die sich dann nahezu direkt in ein Tabellensystem umwandeln lassen. Im Vordergrund bei der Modellierung steht die Frage: „Wie sind meine Daten strukturiert und welche Antworten habe ich in meinen Daten?“ Beim Modellieren für NoSQL-Datenbanken steht typischerweise die Frage im Mittelpunkt: „Wie will ich auf die Daten zugreifen, welche Fragen an die Daten habe ich?“, verbunden mit: „Welche Möglichkeiten bietet die Datenbank, die Daten zu strukturieren und abzufragen?“

Schöne, bunte NoSQL-Welt

Bei relationalen Datenbanken erfolgt der Zugriff auf Daten über ein im Großen und Ganzen gemeinsames Datenmodell, das auf Tabellen mit Zeilen und strikt typisierten Spalten beruht. SQL ist als halbwegs standardisierte Abfragesprache und Zugriffsmöglichkeit etabliert.

Die NoSQL-Welt ist deutlich heterogener: Mittlerweile existieren etwa 150 NoSQL-Datenbanken am Markt [1], die die unterschiedlichsten Ansätze verfolgen: Einige fokussieren sich auf die horizontale Skalierbarkeit. Andere betonen die flexiblen Abfragemöglichkeiten. Wieder andere wollen jede Aufgabe als Graphenproblem betrachten und lösen.

NoSQL-Datenbanken speichern also ganz unterschiedliche Datenstrukturen: Key/Value, Dokumente, Graphen usw. Standardisierungsbemühungen im Bereich Abfragen, wie z. B. UnQL [2] oder JSONiq [3] als interoperable Abfragesprachen, waren bisher nicht erfolgreich bzw. stehen erst am Anfang. Das ist angesichts der heterogenen Ansätze auch nicht sonderlich erstaunlich.

NoSQL-Datenmodelle im Überblick

Die folgende Einteilung gibt einen ersten Überblick, welche Datenbankmodelle sich häufig in der NoSQL-Welt finden:

Simple Key-Value Stores stellen einen einfachen Datenbanktyp dar. Sie bilden Schlüssel (Keys) auf Werte (Values) ab. Die Schlüssel sind eindeutig und damit das Äquivalent zu einem Primary Key in einer relationalen Datenbank. Die Werte selbst sind für simple Key-Value Stores meist „opaque“: Sie we...

PHP Magazin
Datenmodellierung in nicht relationalen Datenbanken

Datenmodellierung in nicht relationalen Datenbanken

„Erstelle ein korrekt normalisiertes Datenbankschema!“ lautet eine beliebte Übungsaufgabe für angehende Informatiker. Das Erkennen und Beseitigen von Redundanzen geht irgendwann ins Blut über und wird alltägliches Handwerkszeug. Doch was ist zu beachten, wenn die Datenbank nicht relational ist, sondern aus dem Kanon der „neuen“, nicht relationalen Datenbanken à la MongoDB, CouchDB, Riak oder Redis stammt?

Jan Steemann


Längst sind nicht relationale Datenbanken, häufig etwas nichtssagend als „NoSQL“-(Not-only-SQL-)Datenbanken bezeichnet, im technologischen Mainstream und in Real-Life-Projekten angekommen. Systemarchitekten ersetzen das relationale Datenbanksystem komplett durch einen der Newcomer oder nehmen für Spezialaufgaben Vertreter dieser Spezies ins Architekturportfolio auf.

Für Entwickler bedeutet das ein Umdenken bei der Modellierung ihrer Persistenzschicht. Die Modellierung in relationalen Datenbanken beruht auf der Erstellung eines normalisierten Relationenmodells mit Tupeln und Relationen, die sich dann nahezu direkt in ein Tabellensystem umwandeln lassen. Im Vordergrund bei der Modellierung steht die Frage: „Wie sind meine Daten strukturiert und welche Antworten habe ich in meinen Daten?“ Beim Modellieren für NoSQL-Datenbanken steht typischerweise die Frage im Mittelpunkt: „Wie will ich auf die Daten zugreifen, welche Fragen an die Daten habe ich?“, verbunden mit: „Welche Möglichkeiten bietet die Datenbank, die Daten zu strukturieren und abzufragen?“

Schöne, bunte NoSQL-Welt

Bei relationalen Datenbanken erfolgt der Zugriff auf Daten über ein im Großen und Ganzen gemeinsames Datenmodell, das auf Tabellen mit Zeilen und strikt typisierten Spalten beruht. SQL ist als halbwegs standardisierte Abfragesprache und Zugriffsmöglichkeit etabliert.

Die NoSQL-Welt ist deutlich heterogener: Mittlerweile existieren etwa 150 NoSQL-Datenbanken am Markt [1], die die unterschiedlichsten Ansätze verfolgen: Einige fokussieren sich auf die horizontale Skalierbarkeit. Andere betonen die flexiblen Abfragemöglichkeiten. Wieder andere wollen jede Aufgabe als Graphenproblem betrachten und lösen.

NoSQL-Datenbanken speichern also ganz unterschiedliche Datenstrukturen: Key/Value, Dokumente, Graphen usw. Standardisierungsbemühungen im Bereich Abfragen, wie z. B. UnQL [2] oder JSONiq [3] als interoperable Abfragesprachen, waren bisher nicht erfolgreich bzw. stehen erst am Anfang. Das ist angesichts der heterogenen Ansätze auch nicht sonderlich erstaunlich.

NoSQL-Datenmodelle im Überblick

Die folgende Einteilung gibt einen ersten Überblick, welche Datenbankmodelle sich häufig in der NoSQL-Welt finden:

Simple Key-Value Stores stellen einen einfachen Datenbanktyp dar. Sie bilden Schlüssel (Keys) auf Werte (Values) ab. Die Schlüssel sind eindeutig und damit das Äquivalent zu einem Primary Key in einer relationalen Datenbank. Die Werte selbst sind für simple Key-Value Stores meist „opaque“: Sie we...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang