Die von Don Chamberlin und Ray Boyce bei IBM erfundene Structured Query Language (SQL) ist die Standardprogrammiersprache für die Interaktion mit relationalen Datenbankmanagementsystemen, die es Datenbankadministratoren ermöglicht, Datenzeilen auf einfache Weise hinzuzufügen, zu aktualisieren oder zu löschen. Ursprünglich unter dem Namen SEQUEL bekannt, wurde es aufgrund eines Markenrechtsproblems zu SQL vereinfacht. SQL Queries ermöglichen es den Benutzern auch, mit nur wenigen Codezeilen die Daten aus Datenbanken abzurufen. Angesichts dieser Abhängigkeit ist klar ersichtlich, warum relationale Datenbanken manchmal auch als „SQL-Datenbanken“ bezeichnet werden.  

Anhand des obigen Beispiels können Sie mit dem folgenden Code eine Abfrage erstellen, um die zehn wichtigsten Transaktionen nach Unternehmen für ein bestimmtes Jahr zu finden:

SELECT COMPANY_NAME, SUM(TRANSACTION_AMOUNT)

FROM TRANSACTION_TABLE A

LEFT JOIN CUSTOMER_TABLE B

ON A.CUSTOMER_ID = B.CUSTOMER_ID

WHERE YEAR(DATE) = 2022

GROUP BY 1

ORDER BY 2 DESC

LIMIT 10

Die Möglichkeit, Daten auf diese Weise zu verknüpfen, hilft uns, die Redundanz in unseren Datensystemen zu verringern. So können die Datenteams eine einzige Mastertabelle für die Kunden pflegen, anstatt diese Informationen zu duplizieren, wenn es in Zukunft eine weitere Transaktion gibt. Don Chamberlin geht in diesem Whitepaper näher auf die Geschichte von SQL ein (Link befindet sich außerhalb von IBM).

Bevor es relationale Datenbanken gab, verwendeten Unternehmen ein hierarchisches Datenbanksystem mit einer baumartigen Struktur für die Datentabellen. Diese frühen Datenbankmanagementsysteme (DBMS) ermöglichten es den Benutzern, große Datenmengen zu organisieren. Sie waren jedoch sehr komplex, oft an eine bestimmte Anwendung gebunden und nur begrenzt in der Lage, bestimmte Daten aufzuspüren. Diese Einschränkungen führten schließlich dazu, dass der IBM Forscher Edgar F. Codd 1970 ein Paper (Link befindet sich außerhalb von IBM) (PDF, 1,5 MB) mit dem Titel „A Relational Model of Data for Large Shared Data Banks“ veröffentlichte, in dem das relationale Datenbankmodell vorgestellt wurde. In diesem vorgestellten Modell konnten Informationen ohne spezielle Computerkenntnisse abgerufen werden. Er schlug vor, Daten basierend auf aussagefähigen Beziehungen als Tupel oder Attribut-Wert-Paare anzuordnen. Gruppen von Tupeln wurden als Relationen bezeichnet, die letztlich die Zusammenführung von Daten über Tabellen hinweg ermöglichten.

Im Jahr 1973 startete das San Jose Research Laboratory – heute als Almaden Research Center bekannt – ein Programm namens System R (R steht hierbei für relational), um diese relationale Theorie mit einer, wie es hieß, „branchentauglichen Implementierung“ zu beweisen. Das Programm wurde schließlich auch zu einem Testfeld für SQL, sodass es sich in kurzer Zeit weiterverbreiten konnte. Doch auch die Übernahme von SQL durch Oracle tat der Popularität des Unternehmens bei Datenbankadministratoren keinen Abbruch.

1983 führte IBM die DB2-Familie relationaler Datenbanken ein, die so genannt wurde, weil es sich um IBMs zweite Familie von Datenbankmanagementsoftware handelte. Heute ist DB2 eines der erfolgreichsten Produkte von IBM, das weiterhin täglich Milliarden von Transaktionen in der Cloud-Infrastruktur verarbeitet und die Grundlage für Anwendungen des maschinellen Lernens bildet.

Während relationale Datenbanken die Daten in einem tabellarischen Format strukturieren, haben nicht-relationale Datenbanken kein so starres Datenbankschema. Tatsächlich organisieren nicht-relationale Datenbanken die Daten je nach Datenbankart unterschiedlich. Unabhängig von der nicht-relationalen Datenbankart zielen sie alle darauf ab, die mit relationalen Modellen verbundenen Probleme der Flexibilität und Skalierbarkeit zu lösen, die für unstrukturierte Datenformate wie Text, Video und Bilder nicht ideal sind. Zu diesen Arten von Datenbanken gehören:

• Schlüssel-Wert-Speicher: Dieses schemafreie Datenmodell ist in einem Wörterverzeichnis von Schlüssel-Wert-Paaren organisiert, wobei jedes Element einen Schlüssel und einen Wert hat. Der Schlüssel könnte z. B. eine Warenkorb-ID in einer SQL-Datenbank sein, während der Wert ein Array von Daten ist, z. B. jedes einzelne Element im Warenkorb des Benutzers. Dies wird häufig zum Caching und Speichern von Benutzersitzungsdaten verwendet, z. B. bei Warenkörben. Dies ist jedoch nicht ideal, wenn Sie mehrere Datensätze auf einmal abrufen müssen. Redis und Memcached sind Beispiele für Open-Source-Datenbanken mit diesem Datenmodell.

• Dokumentenspeicher: Wie der Name schon sagt, speichern Dokumentendatenbanken Daten als Dokumente. Diese Datenbanken sind für die Verwaltung halbstrukturierter Daten geeignet, wobei die Daten in der Regel im JSON-, XML- oder BSON-Format gespeichert werden. Dadurch werden die Daten bei der Verwendung in Anwendungen zusammengehalten und der Übersetzungsaufwand für die Nutzung der Daten wird reduziert. Entwickler erhalten auch mehr Flexibilität, da Datenschemata nicht über alle Dokumente hinweg übereinstimmen müssen (z. B. Name vs. Vorname). Dies kann jedoch bei komplexen Transaktionen problematisch sein und zu fehlerhaften Daten führen. Gängige Anwendungsfälle für Dokumentdatenbanken sind Content-Management-Systeme und Benutzerprofile. Ein Beispiel für eine dokumentorientierte Datenbank ist MongoDB, die Datenbankkomponente des MEAN-Stack.

• Spaltenübergreifender Speicher: Diese Datenbanken speichern Informationen in Spalten, sodass die Benutzer nur auf die benötigten Spalten zugreifen können, ohne zusätzlichen Speicher für irrelevante Daten zu benötigen. Diese Datenbank versucht, die Schwächen von Schlüsselwert- und Dokumentenspeichern zu beheben, aber da die Verwaltung dieses Systems komplexer sein kann, wird es nicht für neuere Teams und Projekte empfohlen. Apache HBase und Apache Cassandra sind Beispiele für quelloffene, spaltenübergreifende Datenbanken. Apache HBase baut auf dem Hadoop Distributed Files System auf, das eine Möglichkeit zur Speicherung kleiner Datensätze bietet, die in vielen Big-Data-Anwendungen verwendet wird. Apache Cassandra hingegen wurde entwickelt, um große Datenmengen auf mehreren Servern und in Clustern zu verwalten, die sich über mehrere Rechenzentren erstrecken. Es wird für eine Vielzahl von Anwendungsfällen eingesetzt, z. B. für Social-Networking-Websites und Datenanalysen in Echtzeit.

• Graphspeicher: Diese Art von Datenbank enthält in der Regel Daten aus einem Wissensdiagramm. Die Datenelemente werden als Knoten, Edges und Eigenschaften gespeichert. Jedes Objekt, jeder Ort und jede Person kann ein Knoten sein. Ein Edge definiert die Beziehung zwischen den Knoten. Graphdatenbanken werden zur Speicherung und Verwaltung eines Netzes von Verbindungen zwischen Elementen innerhalb des Graphen verwendet. Neo4j (Link befindet sich außerhalb von IBM) ist ein graphbasierter Datenbankdienst auf Java-Basis mit einer Open-Source-Community-Edition, bei der die Nutzer Lizenzen für Online-Backup- und Hochverfügbarkeitserweiterungen oder eine lizenzierte Version mit Backup und Erweiterungen im Paket erwerben können.

NoSQL-Datenbanken priorisieren auch die Verfügbarkeit gegenüber Konsistenz.

Wenn Computer über ein Netzwerk laufen, müssen sie immer entscheiden, ob sie konsistente Ergebnisse (bei denen jede Antwort immer gleich ist) oder eine hohe Betriebszeit, die sogenannte „Verfügbarkeit“ bevorzugen. Dies wird als „CAP-Theorie“ bezeichnet, die für „Consistency, Availability, or Partition Tolerance“ (Konsistenz, Verfügbarkeit oder Partitionstoleranz) steht. Relationale Datenbanken gewährleisten, dass die Informationen stets synchron und konsistent sind. Einige NoSQL-Datenbanken, wie z. B. Redis, ziehen es vor, immer eine Antwort auszugeben. Das bedeutet, dass die Informationen, die Sie bei einer Abfrage erhalten, einige Sekunden lang – vielleicht sogar bis zu einer halben Minute – falsch sein können. Auf Social-Media-Websites bedeutet dies, dass ein altes Profilbild angezeigt wird, während das neueste erst wenige Augenblicke alt ist. Die Alternative könnte eine Zeitüberschreitung oder ein Fehler sein. Bei Bank- und Finanztransaktionen hingegen kann ein Fehler und eine erneute Übermittlung besser sein als alte, falsche Informationen.

Eine vollständige Übersicht über die Unterschiede zwischen SQL und NoSQL finden Sie unter „SQL- vs. NoSQL-Datenbanken: Was ist der Unterschied?“.

Der Hauptvorteil des relationalen Datenbankkonzepts ist die Möglichkeit, durch die Verknüpfung von Tabellen aussagekräftige Informationen zu erstellen. Die Verknüpfung von Tabellen ermöglicht es Ihnen, die Beziehungen zwischen den Daten zu verstehen, oder wie die Tabellen miteinander verbunden sind. SQL bietet die Möglichkeit, Abfragen zu zählen, zu addieren, zu gruppieren und auch zu kombinieren. SQL kann grundlegende mathematische Funktionen und Zwischensummen sowie logische Transformationen durchführen. Analysten können die Ergebnisse nach Datum, Name oder einer beliebigen Spalte ordnen. Diese Eigenschaften machen den relationalen Ansatz zum beliebtesten Abfragetool in der heutigen Geschäftswelt.

Relationale Datenbanken haben im Vergleich zu anderen Datenbankformaten mehrere Vorteile:

Bedienungskomfort

Aufgrund ihrer Produktlebensdauer hat sich eine größere Gemeinschaft rund um relationale Datenbanken gebildet, was zum Teil ihre weitere Verwendung begünstigt. Mit SQL ist es auch einfach, Datensätze aus mehreren Tabellen abzurufen und einfache Transformationen wie Filterung und Aggregation durchzuführen. Die Verwendung von Indizes in relationalen Datenbanken ermöglicht es ihnen auch, diese Informationen schnell zu finden, ohne jede Zeile der ausgewählten Tabelle zu durchsuchen.

Während relationale Datenbanken in der Vergangenheit als starrere und unflexiblere Datenspeicheroption angesehen wurden, ändern Fortschritte in der Technologie und DBaaS-Optionen diese Wahrnehmung. Zwar ist der Aufwand für die Entwicklung von Schemata im Vergleich zu NoSQL-Datenbankangeboten immer noch höher, doch relationale Datenbanken werden mit der Migration in Cloud-Umgebungen immer flexibler.

Reduzierte Redundanz 

Relationale Datenbanken können Redundanz auf zwei Arten beseitigen. Das relationale Modell selbst reduziert die Datenredundanz durch einen Prozess, der als Normalisierung bekannt ist. Wie bereits erwähnt, sollte eine Kundentabelle nur eindeutige Datensätze von Kundeninformationen protokollieren, anstatt diese Informationen für mehrere Transaktionen zu duplizieren.

Gespeicherte Verfahren tragen auch dazu bei, sich wiederholende Arbeit zu reduzieren. Wenn zum Beispiel der Datenbankzugriff auf bestimmte Rollen, Funktionen oder Teams beschränkt ist, kann eine gespeicherte Prozedur bei der Verwaltung der Zugriffskontrolle helfen. Durch diese wiederverwendbaren Funktionen bleibt den Anwendungsentwicklern mehr Zeit für die Erledigung wichtigerer Aufgaben.

Einfaches Backup und Disaster-Recovery 

Relationale Datenbanken sind transaktional. Sie gewährleisten, dass der Zustand des gesamten Systems zu jedem Zeitpunkt konsistent ist. Die meisten relationalen Datenbanken bieten einfache Export- und Importoptionen, die das Sichern und Wiederherstellen einfach machen. Diese Exporte können sogar erfolgen, während die Datenbank ausgeführt wird, was die Wiederherstellung bei einem Ausfall erleichtert. Moderne, cloudbasierte relationale Datenbanken können eine fortlaufende Spiegelung durchführen, sodass der Datenverlust bei der Wiederherstellung in Sekunden oder weniger gemessen werden kann. Die meisten cloudverwalteten Dienste ermöglichen es Ihnen, Read Replicas zu erstellen, wie z. B. IBM® Cloud Databases for PostgreSQL. Diese Read Replicas ermöglichen es Ihnen, eine schreibgeschützte Kopie Ihrer Daten in einem Cloud-Rechenzentrum zu speichern. Replicas können auch zu Lese-/Schreibinstanzen für die Notfallwiederherstellung hochgestuft werden.