© Excellent backgrounds/Shutterstock.com
Java Magazin
Teil 1: Relationale Datenbanksysteme

Eine kleine Reise durch NoSQL

Not only SQL, kurz NoSQL, ist eine noch relativ junge Disziplin der Informatik, die sich mit Datenspeicherungstechnologien beschäftigt. NoSQL befindet sich in beständigem Wandel, was es schwer macht, eine strenge Definition zu geben. In dieser dreiteiligen Artikelserie wollen wir versuchen, die bisherige Entwicklung in groben Zügen nachzuvollziehen. Wir beginnen mit einem Rückblick auf die relationalen Datenbanksysteme.

Christian Mennerich, Joachim Arrasz


ArtikelserieTeil 1: Relationale DatenbanksystemeTeil 2: NoSQL-DatenbankenTeil 3: Ausblick

NoSQL ist momentan in aller Munde und erfährt eine Namensgebung und -prägung, die es sehr schwer macht, eine strenge Definition dafür zu geben, was sich genau hinter diesem Akronym verbirgt. Das ursprünglich erklärte Ziel von NoSQL war die Entwicklung von so genannten Web-Scale-Datenbanken [1], jedoch gibt es viele verschiedene Auffassungen und Meinungen über das, was unter NoSQL zu verstehen ist.

Wir wollen die Entstehung von NoSQL näher beleuchten und beginnen unsere dreiteilige Serie über NoSQL mit einem für das Verständnis notwendigen Rückblick auf die relationalen Datenbanken und die Probleme, die das relationale Datenmodell zu lösen versuchte. Im nächsten Artikel werden wir uns dann intensiver den NoSQL-Datenbanken selbst widmen, um im dritten Teil neue Trends zu prognostizieren und zu diskutieren.

Die Evolution der Speicherungstechnologien seit den 1970er-Jahren machen wir an drei Arbeiten fest, die uns durch unsere Serie begleiten werden.

Der Ausgangspunkt ist Codds Arbeit zu relationalen Datenbanksystemen [2] aus dem Jahr 1970, in der die Grundsteine des relationalen Datenbankmodells gelegt werden. Den Konsequenzen der zunehmenden Verteilung von Daten trägt der Beweis der Brewer’schen Vermutung Rechnung, der 2002 durch Gilbert und Lynch präsentiert wurde. Er ist als CAP-Theorem bekannt und stellt, streng interpretiert, ein „Wähle zwei aus drei“-Ergebnis dar, mit gewichtigen Implikationen für die verteilte Datenhaltung. Die dritte Arbeit ist die 2005 verfasste Absage an relationale Datenbanken als Universallösungen durch Stonebraker und Çetintemel [3]. Sie versetzte dem Vorgehen, für jedes Problem eine relationale Datenbank zu verwenden, den etablierten Todesstoß.

Codds Kritik und das relationale Datenmodell

Die in den 1960er-Jahren vorherrschenden Datenspeichertechnologien waren Systeme wie IBMs IMS oder IDS von General Electric, in denen Daten hierarchisch oder in Netzwerken organisiert sind. Codd formulierte drei wesentliche Kritikpunkte [2]:

Eine Applikation hängt direkt davon ab, wie die Daten auf dem Persistenzspeicher angeordnet sind (Ordering Dependence).Eine Anfrage an ein Datenbanksystem hängt direkt davon ab, welche Indexstrukturen definiert sind (Indexing Dependence).Eine Applikation hängt direkt davon ab, über welche Zugriffspfade die auf dem Speichersystem persistierten Daten untereinander vernetzt sind (Access Path Dependence).

Diese Abhängigkeiten ...

Java Magazin
Teil 1: Relationale Datenbanksysteme

Eine kleine Reise durch NoSQL

Not only SQL, kurz NoSQL, ist eine noch relativ junge Disziplin der Informatik, die sich mit Datenspeicherungstechnologien beschäftigt. NoSQL befindet sich in beständigem Wandel, was es schwer macht, eine strenge Definition zu geben. In dieser dreiteiligen Artikelserie wollen wir versuchen, die bisherige Entwicklung in groben Zügen nachzuvollziehen. Wir beginnen mit einem Rückblick auf die relationalen Datenbanksysteme.

Christian Mennerich, Joachim Arrasz


ArtikelserieTeil 1: Relationale DatenbanksystemeTeil 2: NoSQL-DatenbankenTeil 3: Ausblick

NoSQL ist momentan in aller Munde und erfährt eine Namensgebung und -prägung, die es sehr schwer macht, eine strenge Definition dafür zu geben, was sich genau hinter diesem Akronym verbirgt. Das ursprünglich erklärte Ziel von NoSQL war die Entwicklung von so genannten Web-Scale-Datenbanken [1], jedoch gibt es viele verschiedene Auffassungen und Meinungen über das, was unter NoSQL zu verstehen ist.

Wir wollen die Entstehung von NoSQL näher beleuchten und beginnen unsere dreiteilige Serie über NoSQL mit einem für das Verständnis notwendigen Rückblick auf die relationalen Datenbanken und die Probleme, die das relationale Datenmodell zu lösen versuchte. Im nächsten Artikel werden wir uns dann intensiver den NoSQL-Datenbanken selbst widmen, um im dritten Teil neue Trends zu prognostizieren und zu diskutieren.

Die Evolution der Speicherungstechnologien seit den 1970er-Jahren machen wir an drei Arbeiten fest, die uns durch unsere Serie begleiten werden.

Der Ausgangspunkt ist Codds Arbeit zu relationalen Datenbanksystemen [2] aus dem Jahr 1970, in der die Grundsteine des relationalen Datenbankmodells gelegt werden. Den Konsequenzen der zunehmenden Verteilung von Daten trägt der Beweis der Brewer’schen Vermutung Rechnung, der 2002 durch Gilbert und Lynch präsentiert wurde. Er ist als CAP-Theorem bekannt und stellt, streng interpretiert, ein „Wähle zwei aus drei“-Ergebnis dar, mit gewichtigen Implikationen für die verteilte Datenhaltung. Die dritte Arbeit ist die 2005 verfasste Absage an relationale Datenbanken als Universallösungen durch Stonebraker und Çetintemel [3]. Sie versetzte dem Vorgehen, für jedes Problem eine relationale Datenbank zu verwenden, den etablierten Todesstoß.

Codds Kritik und das relationale Datenmodell

Die in den 1960er-Jahren vorherrschenden Datenspeichertechnologien waren Systeme wie IBMs IMS oder IDS von General Electric, in denen Daten hierarchisch oder in Netzwerken organisiert sind. Codd formulierte drei wesentliche Kritikpunkte [2]:

Eine Applikation hängt direkt davon ab, wie die Daten auf dem Persistenzspeicher angeordnet sind (Ordering Dependence).Eine Anfrage an ein Datenbanksystem hängt direkt davon ab, welche Indexstrukturen definiert sind (Indexing Dependence).Eine Applikation hängt direkt davon ab, über welche Zugriffspfade die auf dem Speichersystem persistierten Daten untereinander vernetzt sind (Access Path Dependence).

Diese Abhängigkeiten ...

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