Einführung zu Datenbanken

Einführung

In einem kleinen Unternehmen sind die Netzwerkadministratoren oder Entwickler gleichzeitig auch Datenbankadministratoren (DBAs). In größeren Unternehmen kann es Dutzende von DBAs geben, die sich auf die vielen verschiedenen Aspekte von Design und Architektur bis hin zu Wartung, Entwicklung usw. spezialisieren. Unabhängig davon, in welchem Bereich der IT Sie arbeiten, müssen Sie an der einen oder anderen Stelle Daten speichern, und es kann nicht schaden, wenn so gut wie jeder etwas über Datenbanken und deren Funktionsweise weiß.

Das Ziel dieses Tutorials ist es, diese grundlegende Einführung zu geben. Wir werden die Grundlagen dessen erklären, was eine Datenbank eigentlich ist, einen Blick auf die Geschichte werfen, relationale Datenbanken verstehen, uns mit einigen grundlegenden Konzepten von Spalten und Zeilen beschäftigen, andere Arten von Datenbanken ansprechen, uns mit einigen zusätzlichen Konzepten vertraut machen und das Ganze mit einem kurzen Überblick über die wichtigsten kommerziellen Systeme auf dem heutigen Markt abschließen.

Außer grundlegenden Computerkenntnissen sind für dieses Tutorial keine weiteren Voraussetzungen erforderlich.

Was ist eine Datenbank?

Eine Datenbank ist im Allgemeinen eine organisierte Sammlung von Daten. Genauer gesagt ist eine Datenbank ein elektronisches System, das den einfachen Zugriff auf Daten sowie deren Bearbeitung und Aktualisierung ermöglicht.

Mit anderen Worten, eine Datenbank wird von einer Organisation als elektronisches Mittel zum Speichern, Verwalten und Abrufen von Informationen verwendet. Die Datenbank ist einer der Eckpfeiler der Unternehmens-IT, und ihre Fähigkeit, Informationen auf strukturierte und kontrollierte Weise zu organisieren, zu verarbeiten und zu verwalten, ist der Schlüssel zu vielen Aspekten der Effizienz moderner Unternehmen. (Siehe auch: Transaktionsprozess-System)

Datenbanken gehen jedoch weit über die reine Speicherung von Daten hinaus. Wie wir später sehen werden, können die inhärente Logik und die Effizienz, mit der die Daten gespeichert und abgerufen werden, ein unglaublich leistungsfähiges Geschäftsinstrument für ein Unternehmen darstellen. Dies gilt vor allem dann, wenn Datenbanken für die Erstellung von Berichten und für Business-Intelligence-Funktionen richtig genutzt werden.

Die Verwendung und Bedeutung von Datenbanken in der heutigen Welt

Welche Art von Unternehmen benötigt also eine Datenbank und kann von deren Einsatz profitieren? Nun, die kurze Antwort lautet: Jedes Unternehmen oder jede Organisation, die eine große Anzahl von Kunden oder Produkten verwalten muss. Mit “groß” meinen wir mehr, als ein menschliches Gehirn speichern kann – sehr viel mehr.

Skeptiker könnten an dieser Stelle immer noch einwenden, dass es unzählige kleine Läden gibt, deren Inhaber mit Hilfe des bewährten Hauptbuchs und des Taschenrechners den Bestand und die Gewinne/Verluste im Auge behalten und damit gut zurechtkommen. Das stimmt, aber der Einsatz einer elektronischen Datenbank kann sich auch für sehr kleine Unternehmen lohnen. Ein Hauptbuch kann zum Beispiel keine Simulation durchführen, um die Gewinne zu extrapolieren, wenn das Geschäft den Preis für Kugelschreiber um 2 Cent erhöht. Das kann eine Datenbank leisten. Das Hauptbuch kann keinen Bericht erstellen, der die Nachbestellungen für alle Artikel auflistet, um dem Geschäftsinhaber zu zeigen, welche Artikel zu welchen Zeiten im Jahr nachbestellt werden sollten. Auch das kann eine Datenbank leisten. Eine Datenbank kann den Geschäftsinhaber sogar automatisch per E-Mail oder Textnachricht benachrichtigen.

Der größte Nutzen von Datenbanken ist jedoch nach wie vor auf große Organisationen mit Hunderttausenden, Millionen oder Zehn Millionen von Kunden und Produkten beschränkt, die eine große Anzahl von Einzeldaten für ihre Kunden speichern müssen. So benötigt beispielsweise eine Geschäftsbank die persönlichen Daten aller ihrer Millionen Kunden, wie Name, Geburtsdatum, Adresse, Sozialversicherungsnummer usw. Jeder Kunde wiederum bringt eine weitere Datensammlung hervor, die von den Produkten abhängt, für die er sich angemeldet hat, z. B. Kontotyp, Kontonummer, Kontostand, Hypothekenbetrag, Kreditkartendarlehen, Rückzahlungszeitraum usw. Eine dritte Datensammlung bezieht sich auf die spezifischen Transaktionen des Kunden, z. B. Zeitpunkt der Transaktion, Betrag, Restbetrag, Bankgebühren, noch zu tilgender Kreditbetrag usw.

Es liegt auf der Hand, dass ein einziger Kunde in sehr kurzer Zeit eine riesige Datenmenge erzeugen kann. Multipliziert man dies mit Millionen von Kunden, wird schnell klar, warum eine effiziente Datenspeicherung und -abfrage nicht nur eine gute Idee ist, sondern auch absolut notwendig, um zu verhindern, dass der Betrieb der Datenbank zum Erliegen kommt.

Aber halt. Vor der Einführung von Computern und diesen neumodischen Datenbanken kamen die Unternehmen doch auch gut zurecht, oder? Sicher. Aber wenn Sie von der Leistungsfähigkeit von Datenbanken aufgrund ihrer Fähigkeit, die Effizienz und die Transaktionsgeschwindigkeit zu erhöhen, noch nicht überzeugt sind, dann bedenken Sie Folgendes: Ihre Konkurrenten sind effizienter und bieten einen besseren Service als Sie, weil sie Datenbanksysteme verwenden.

Geschäftsbanken sind ein Paradebeispiel für den Einsatz von Datenbanken in modernen Unternehmen. Andere Branchen, die in hohem Maße auf Datenbanken angewiesen sind, sind Versicherungen, Krankenhäuser und Gesundheitswesen, Schulen und Hochschulen, das verarbeitende Gewerbe, Telekommunikationsunternehmen sowie Hotels und das Gastgewerbe.

Datenbanken sind in der Tat das, was der Begriff sagt – die Basis oder der Pool von (zusammenhängenden) Daten, auf denen die Datensysteme eines Unternehmens aufgebaut werden sollten. Es ist nicht übertrieben zu sagen, dass ohne Datenbanken der Computer am Arbeitsplatz kaum mehr wäre als eine effizientere Schreibmaschine!

Geschichte der Datenbanken

Es ist wichtig, sich zunächst bewusst zu machen, dass die organisierte, systematische Methode der Speicherung von Datensätzen, die wir kennen und auf die wir uns in Datenbanken verlassen, keine Erfindung der letzten Zeit ist. Neu ist vielmehr die Computerisierung dieser Methode seit den 1960er Jahren. Beachten Sie, dass auch papierbasierte Aufzeichnungen, einschließlich der Buchführung auf der Grundlage von Büchern, (technisch) alle Formen einer Datenbank sind. Das heißt, eine Datenbank muss nicht unbedingt computerisiert sein. Die Computerisierung hat nur ein Datenbankmanagementsystem (DBMS) hervorgebracht, das natürlich um Größenordnungen leistungsfähiger, genauer und fähiger ist als das, was ein einfaches Hauptbuch oder ein mickriges menschliches Gehirn leisten kann. Und obwohl wir den Begriff “Datenbank” meist im Zusammenhang mit dem DBMS verwenden, sind die beiden nicht dasselbe; alle Daumen (DBMS) sind Finger (Datenbanken), aber nicht alle Finger sind Daumen.

Die alten Ägypter benutzten ausgeklügelte Aufzeichnungssysteme, um den Bestand der Getreideernten zu erfassen. Die Bibliothek von Alexandria verwendete eine ausgeklügelte Methode, um eine große Anzahl von Büchern und Schriftrollen zu verwalten. Dies waren alles frühe Beispiele für Datenbanken, auch wenn ihre Fähigkeiten natürlich lächerlich wären im Vergleich zu den enorm leistungsfähigen computerisierten DBMS des 21. Jahrhunderts.

Aber schon damals, als sich die gesamte Computertechnik noch im Stadium des Einzellers befand (in den 1960er Jahren), konnten sich viele Menschen vorstellen, dass Computer wirklich nützlich sein würden, wenn sie eine Möglichkeit zum zuverlässigen Speichern und Abrufen von Daten bieten könnten. Die Entwicklung von Datenbanken vollzog sich daher fast im Gleichschritt mit der allgemeinen Entwicklung und dem Wachstum der damaligen Computerkapazitäten. Der Comupter wurde zum Speichergerät. Mit zunehmender Festplattenkapazität und Prozessorgeschwindigkeit wuchsen auch die Speicherkapazität und der Funktionsumfang der zeitgenössischen Datenbankangebote. Ein wichtiger Schritt war Mitte der 1960er Jahre die Umstellung von Bandspeichern auf Direktzugriffsspeicher oder Festplatten. Diese Umstellung ermöglichte einen interaktiven Datenzugriff mit mehreren Arbeitsschritten, im Gegensatz zu der für Bänder erforderlichen Stapelverarbeitung mit nur einem Bediener.

Die ersten Datenbanksysteme waren navigatorischer Natur. Das bedeutet, dass Anwendungen Daten mit Hilfe von Zeigern verarbeiteten und lasen, die in die Daten selbst eingebettet waren. Der Zeiger führte zum nächsten Datenelement und konnte doppelt verlinkt werden, so dass eine Verknüpfung sowohl zu den vorherigen als auch zu den nächsten Datenelementen möglich war. Dies ist vergleichbar mit der Funktionsweise von Hyperlinks auf einer Webseite, die den Leser von der aktuellen Seite zu einer verwandten Webseite führen. Die beiden wichtigsten Datenmodelle zu dieser Zeit waren das hierarchische Modell, das durch das IMS-System von IBM verkörpert wurde, und das Codasyl- oder Netzwerkmodell. Doch all diese Modelle wurden durch die Entwicklung des relationalen Modells durch einen brillanten Informatiker namens E.F. Codd überholt und zu interessanten Fußnoten der Geschichte degradiert.

E.F. Codd und das relationale Modell

Das relationale Modell war eine radikale Abkehr vom vorherrschenden hierarchischen Modell, da es sich auf die Möglichkeit konzentrierte, eine Datenbank nach dem Inhalt zu durchsuchen, anstatt einem verknüpften Navigationssystem zu folgen. Dies bot den großen Vorteil, dass Datenbanken wachsen und immer mehr Daten speichern konnten, ohne dass die Anwendungen, die auf diese Daten zugriffen, geändert oder umgeschrieben werden mussten. Im Wesentlichen hat Codd im Alleingang einen Weg gefunden, das Skelett oder die Struktur der Datenbank von den in der Datenbank gespeicherten Datensätzen zu trennen. Dieses Modell war so elegant, dass es bis heute der De-facto-Standard für das Datenbankdesign ist, wobei solche Datenbanken als relationale Datenbanken bezeichnet werden. Es gibt einige sehr wichtige nicht-relationale Datenbanken (insbesondere mit dem Aufkommen von Big Data und Web 2.0), aber das relationale Modell wird immer noch für die überwältigende Mehrheit der kommerziellen Datenbankangebote verwendet.

Heutzutage würde der Name E.F. Codd bei den meisten Menschen, selbst bei vielen in der IT-Branche, ein lässiges “E.F. wer?” hervorrufen. Seine Arbeit hat jedoch direkt zu den enormen Vorteilen und der Effizienz relationaler Datenbanken geführt. Sein Beitrag zur Welt der Informatik ist vergleichbar mit dem Beitrag von Sir Isaac Newton zur Welt der Physik.

Codd besuchte das Oxford College und studierte Mathematik und Chemie. Während des Zweiten Weltkriegs arbeitete er als Pilot bei der Royal Air Force, bevor er 1948 in die USA ging, um als mathematischer Programmierer für IBM zu arbeiten. Nachdem er ein Jahrzehnt in Kanada verbracht hatte, kehrte er 1963 in die USA zurück und erhielt 1965 seinen Doktortitel.

1970 veröffentlichte Codd für IBM eine Arbeit über Datenmanagement mit dem Titel “A Relational Model of Data for Large Shared Data Banks”. Das riesige Unternehmen hatte jedoch über sein Informationsmanagementsystem (IMS) stark in das hierarchische Modell investiert, und die Führungskräfte von Big Blue waren nicht daran interessiert, einen Konkurrenten für eine ihrer eigenen lukrativen Produktlinien zu entwickeln. Mit einer List, die man selten bei Akademikern oder Wissenschaftlern antrifft, zeigte Codd sein Modell heimlich ausgewählten IBM-Kunden, die von seiner Überlegenheit kaum überzeugt werden mussten. Die einflussreichen Kunden übten ihrerseits Druck auf dieselben IBM-Führungskräfte aus, das Modell zu entwickeln, und diese setzten das Modell widerwillig (und, wie man sich vorstellen kann, mit stiller Wut auf Codd) in das IBM-Projekt Future Systems ein, wobei das System selbst als System R bekannt wurde.

Die Chefs waren jedoch immer noch nicht bereit, IMS zu bedrohen, und sabotierten Codds Arbeit, indem sie das System R-Projekt in die Hände von Entwicklern legten, die damit nicht vertraut waren. Die Entwickler versäumten es also, Codds eigene Alpha-Sprache für die Entwicklung zu verwenden und entschieden sich stattdessen für eine viel einfachere Sprache namens SEQUEL. Dies erwies sich jedoch als Glücksgriff, denn SEQUEL ist viel einfacher zu verstehen und zu benutzen. Aus urheberrechtlichen Gründen wurde der Name in SQL geändert und ist Datenbankentwicklern und -administratoren heute als die Sprache der Wahl zum Schreiben von Datenbankabfragen sehr vertraut.

Ein kluger junger Geschäftsmann, der sein eigenes Datenbanksystem entwickelte, las 1979 auf einer Konferenz über SQL. Er erkannte ihre Überlegenheit und kopierte die Sprache in ein Datenbankprodukt seines eigenen kleinen Unternehmens. Der Geschäftsmann hatte zuvor auch Codds Arbeit über das relationale Modell gesehen und war davon überzeugt, dass dies der richtige Weg für Datenbanksysteme war. Er baute sein eigenes Produkt darauf auf, auch wenn IBM sich weigerte, den Code von System R mit ihm zu teilen. Zur Erinnerung: IBM war nicht an dem relationalen Modell interessiert. Das kleine Unternehmen ist ziemlich groß geworden; heute ist es als Oracle Corp. bekannt. Der Geschäftsmann heißt Larry Ellison, und seine Überzeugung hat ihn zu einem der reichsten Menschen der Welt gemacht. Das zeigt nur, wie sehr IBM das Potenzial von Codds relationalem Modell falsch eingeschätzt hat. In der Tat ist Oracle DB heute die am häufigsten verwendete relationale Datenbank für Unternehmen.

Die relationale Datenbank

Wie wir bereits gesehen haben, hat die Arbeit von E.F. Codd das relationale Modell von Datenbanken als die eindeutig überlegene Methode der Datenspeicherung etabliert. Die Eleganz des relationalen Modells bei der Speicherung und Bearbeitung von Daten war so effektiv, dass es seit den späten 1970er Jahren keinem der vielen Anwärter auf den Thron gelungen ist, es zu stürzen.

Schauen wir uns also einmal genau an, wie das relationale Modell funktioniert. Eine relationale Datenbank ist im Wesentlichen eine Gruppe von Tabellen oder, um den technischen Namen zu verwenden, Entitäten (siehe Regeln 0 und 1 in Codds 12 Regeln für relationale Datenbanken). Jede Tabelle besteht aus Zeilen (Tupeln) und Spalten (Attributen). Zwischen den Tabellen bestehen Beziehungen, die dadurch definiert sind, dass eine bestimmte Spalte in einer Tabelle auf eine Spalte in einer anderen Tabelle verweist.

Das ist die grundlegende Definition einer relationalen Datenbank. Aber wie Sie gleich sehen werden, kann es noch viel komplizierter werden. Eines der grundlegenden Konzepte relationaler Datenbanken ist zum Beispiel das der referentiellen Integrität. Diese Regel besagt, dass Beziehungen zwischen Tabellen immer konsistent bleiben müssen. Mit anderen Worten: Jedes Feld, das sich in einem Fremdschlüssel befindet, muss mit dem Primärschlüssel übereinstimmen, auf den der Fremdschlüssel verweist. Daher müssen alle Aktualisierungen oder Löschungen eines Primärschlüsselfeldes entweder auch auf alle seine Fremdschlüssel angewendet werden oder dürfen nicht stattfinden. Dieselbe Einschränkung gilt auch für Fremdschlüssel; alle Aktualisierungen (aber nicht unbedingt Löschungen) müssen entweder auch auf den entsprechenden übergeordneten Primärschlüssel zurück übertragen werden oder sind nicht zulässig.

Die Idee der referentiellen Integrität lässt sich am besten anhand einer Illustration erklären. Nehmen wir an, dass es in der Datenbank einer Bank zwei Tabellen gibt: die Tabelle CUSTOMER_MASTER, in der die grundlegenden Daten der Kunden/Kontoinhaber gespeichert werden, und die Tabelle ACCOUNTS_MASTER, in der die grundlegenden Daten der Bankkonten gespeichert werden. Um jeden Kunden/Kontoinhaber in der Tabelle CUSTOMER_MASTER eindeutig zu identifizieren, erstellen wir eine Primärschlüsselspalte, die wir CUSTOMER_ID nennen.

Sie sehen, dass wir zur Identifizierung des Kunden, zu dem ein bestimmtes Bankkonto in der Tabelle ACCOUNTS_MASTER gehört, auf einen bestehenden Kunden in der Tabelle CUSTOMER_MASTER verweisen müssen. Das bedeutet, dass wir auch in der Tabelle ACCOUNTS_MASTER eine Spalte CUSTOMER_ID anlegen müssen. Dies wird als Fremdschlüssel bezeichnet. Diese Spalte ist etwas Besonderes, weil die Werte, die sie enthält, keine neuen Werte sind, die man einfach herbeizaubern kann. Sie müssen auf identische, vorhandene Werte in der Primärschlüsselspalte einer anderen Tabelle verweisen, in diesem Fall auf die Spalte CUSTOMER_ID der Tabelle CUSTOMER_MASTER

Klar soweit? Gut. Nun bedeutet referentielle Integrität einfach, dass Sie keinen CUSTOMER_ID-Wert in CUSTOMER_MASTER bearbeiten können, ohne auch den entsprechenden Wert in der Tabelle ACCOUNTS_MASTER zu bearbeiten. Wenn Sie die Kunden-ID von Andrew Smith in CUSTOMER_MASTER ändern, müssen Sie sie auch in ACCOUNTS_MASTER ändern. Das macht durchaus Sinn, wenn Sie darüber nachdenken. Wie würden wir sonst die Konten von Andrew Smith mit ihm verknüpfen? Denken Sie daran, dass die Tabelle ACCOUNTS_MASTER keine Informationen über die Kontoinhaber enthält, außer dass ihre CUSTOMER_IDs als Fremdschlüssel gespeichert sind. Wenn nach derselben Logik eine Kunden-ID in der Tabelle “Bankkonten” ohne eine entsprechende Kunden-ID in der Tabelle “KUNDEN_MASTER” existieren darf, bedeutet dies in der Regel, dass ein Bankkonto ohne einen Kontoinhaber existieren kann, was natürlich keinen Sinn ergibt.

Verfolgt man diesen Gedankengang nun ein wenig weiter, so muss man, wenn man eine Kunden-ID in CUSTOMER_MASTER löscht, auch alle entsprechenden Einträge in ACCOUNTS_MASTER löschen. Dies ist einfach die Manifestation einer sauberen Folgeaktion im wirklichen Leben: Wenn jemand kein Kunde mehr ist, müssen Sie auch seine Bankkonten löschen.

Die 12 Regeln der relationalen Datenbanken

Als das relationale Modell in den frühen 1980er Jahren für das Datenbankdesign in Mode kam, war Codd zunächst verwirrt und dann verärgert über die Tendenz aller anderen Datenbankanbieter, ihren Produkten den relationalen Namen aufzudrücken, selbst wenn er nicht zutraf. Er stellte eine Liste mit 12 Regeln auf, anhand derer er feststellte, ob eine Datenbank als “relational” bezeichnet werden konnte. Seine Schwierigkeiten mit IBM erreichten zu dieser Zeit ihren Höhepunkt, und er verließ das Unternehmen, um mit einem anderen Dozenten/Berater namens Chris Date eine eigene Beratungsfirma zu gründen.

Im Folgenden finden Sie Codds 12 Regeln oder, wie manche sie nennen, 12 Gebote. Eigentlich sind es 13, aber sie sind von 0 bis 12 durchnummeriert, daher der Name. Wir werden sie ausführlicher betrachten, wenn wir uns mit den Merkmalen relationaler Datenbanken befassen, und dann auf sie verweisen, damit Sie Codds Regeln wirklich im Zusammenhang verstehen können. In grober Form machen diese Regeln für diejenigen, die nicht im Datenbankbereich arbeiten, nicht viel Sinn, aber wie dem auch sei, es geht los:

0. Grundregel
Ein relationales Datenbankmanagementsystem muss seine gespeicherten Daten ausschließlich mit seinen relationalen Fähigkeiten verwalten.

1. Informations-Regel
Alle Informationen in der Datenbank sollten auf eine und nur eine Weise dargestellt werden – als Werte in einer Tabelle.

2. Garantierte Zugriffsregel
Jedes einzelne Datum (atomarer Wert) ist garantiert logisch zugänglich, indem auf eine Kombination aus Tabellenname, Primärschlüsselwert und Spaltenname zurückgegriffen wird.

3. Systematische Behandlung von Nullwerten
Nullwerte (die sich von leeren Zeichenketten, Leerzeichenfolgen, Nullen oder anderen Zahlen unterscheiden) werden im vollständig relationalen DBMS unterstützt, um fehlende Informationen systematisch und unabhängig vom Datentyp darzustellen.

4. Dynamischer Online-Katalog auf der Grundlage des relationalen Modells
Die Beschreibung der Datenbank wird auf der logischen Ebene auf die gleiche Weise dargestellt wie gewöhnliche Daten, so dass autorisierte Benutzer die gleiche relationale Sprache für die Abfrage verwenden können, wie sie es für normale Daten tun.

5. Umfassende Daten-Subsprachen-Regel
Ein relationales System kann mehrere Sprachen und verschiedene Arten der Terminalnutzung unterstützen. Es muss jedoch mindestens eine Sprache geben, deren Aussagen nach einer wohldefinierten Syntax als Zeichenketten ausgedrückt werden können und deren Fähigkeit, alle folgenden Punkte zu unterstützen, nachvollziehbar ist:

Definition von Daten
Definition von Ansichten
Datenmanipulation (interaktiv und programmgesteuert)
Integritätsbeschränkungen
Autorisierung
Transaktionsgrenzen (Beginn, Commit und Rollback)
6. Regel für die Aktualisierung von Sichten
Alle Ansichten, die theoretisch aktualisiert werden können, können auch vom System aktualisiert werden.

7. High-Level Insert, Update und Delete
Die Fähigkeit, eine Basisrelation oder eine abgeleitete Relation als einen einzigen Operanden zu behandeln, gilt nicht nur für das Abrufen von Daten, sondern auch für das Einfügen, Aktualisieren und Löschen von Daten.

8. Physische Datenunabhängigkeit
Anwendungsprogramme und Terminalaktivitäten bleiben logisch unbeeinträchtigt, wenn Änderungen an der Speicherdarstellung oder den Zugriffsmethoden vorgenommen werden.

9. Logische Datenunabhängigkeit
Anwendungsprogramme und Terminalaktivitäten bleiben logisch unbeeinträchtigt, wenn informationserhaltende Änderungen jeglicher Art – und solche, die eine Beeinträchtigung theoretisch zulassen – an den Basistabellen vorgenommen werden.

10. Integritätsunabhängigkeit
Integritätsbeschränkungen, die für eine bestimmte relationale Datenbank spezifisch sind, müssen in der relationalen Datensubsprache definierbar und im Katalog speicherbar sein, nicht in den Anwendungsprogrammen.

11. Verteilungsunabhängigkeit
Die Datenmanipulations-Subsprache eines relationalen DBMS muss es Anwendungsprogrammen und Terminalaktivitäten ermöglichen, logisch unbeeinträchtigt zu bleiben, unabhängig davon, ob die Daten physisch zentralisiert oder verteilt sind.

12. Nicht-Subversions-Regel
Wenn ein relationales System über eine Sprache der unteren Ebene (ein Datensatz pro Zeiteinheit) verfügt oder diese unterstützt, kann diese Sprache der unteren Ebene nicht verwendet werden, um die Integritätsregeln oder -beschränkungen zu untergraben oder zu umgehen, die in der relationalen Sprache der höheren Ebene (mehrere Datensätze pro Zeiteinheit) ausgedrückt werden.

Grundlegende Datenbank-Konzepte

Im Folgenden werden wir uns mit einigen wichtigen Datenbankkonzepten und Datenobjekten befassen. Jeder Datenbankadministrator, der etwas auf sich hält, muss mit diesen absolut vertraut sein. Und sie sind nicht nur theoretisch; praktisch alle DBAs werden fast täglich mit diesen Konzepten und Objekten zu tun haben. Sie sind für die Datenbankverwaltung das, was die Kenntnis des menschlichen Körpers für die Medizin ist.

Wir werden jeden Begriff hier nur kurz definieren. Um die Konzepte besser zu verstehen, folgen Sie den Begriffsverknüpfungen und besuchen Sie den Abschnitt “Verwandte Begriffe”, um zu verstehen, wie jedes Konzept mit anderen Konzepten im Bereich der Datenbankadministration zusammenhängt und zusammenarbeitet.

Tabellen

Die Tabelle ist die grundlegende Einheit zur Datenspeicherung in einer relationalen Datenbank. Tabellen bestehen aus Spalten und Zeilen. Die Spalten sind die Attribute oder Eigenschaften, die wir ausdrücken wollen, während die Zeilen die eigentlichen Daten enthalten, mit einem (oder keinem) Element pro Zeile. Denken Sie an das Layout einer Tabellenkalkulation; dies ist der logischen Organisation einer relationalen Tabelle sehr ähnlich.

Ein einfaches Beispiel für die Tabellen in der Datenbank einer Geschäftsbank finden Sie unten.

Beziehung

Beziehungen sind DER Grund, warum relationale Datenbanken so gut funktionieren. Wenn Sie nur ein einziges Konzept über Datenbanken lernen, ist dies das richtige. Wie der Name schon sagt, sind Beziehungen der Kern von relationalen Datenbanken.

In relationalen Datenbanken besteht eine Beziehung zwischen zwei Tabellen, wenn eine der Tabellen einen Fremdschlüssel hat, der auf den Primärschlüssel der anderen Tabelle verweist. (Mehr zu Fremd- und Primärschlüsseln in Kürze).

In dem folgenden Diagramm sehen Sie Beispiele für Beziehungen. Beispielsweise verweist das Feld (Spalte) AccountTypeID in der Tabelle AccountTypes auf die Spalte AccountTypeID der Tabelle Customer.

Zeile

Eine Zeile, auch Datensatz genannt, stellt eine Reihe von Daten über ein bestimmtes Element dar. Jeder Datensatz in einer Tabelle hat genau dieselbe Struktur, aber natürlich unterschiedliche Daten. Denken Sie an die Zeilen in einer Excel-Tabelle – das Konzept der Zeilen in einer Datenbank ist sehr ähnlich. Jede Zeile in einer Tabelle besteht aus unterschiedlichen Datenelementen, mit einem (oder null) Elementen für jede Spalte der Tabelle. Zeilen werden auch als Tupel bezeichnet, obwohl dieser Begriff nicht sehr gebräuchlich ist.

Unten sehen Sie ein Beispiel für einen Datensatz oder eine Zeile:

Einfaches Beispiel für eine Datenbanktabelle

Spalte

Eine Spalte ist eine bestimmte Menge von Werten in einer Tabelle desselben Typs. Sie definiert ein bestimmtes Attribut der Tabelle oder der Daten. Wir können zum Beispiel eine Spalte namens CUSTOMER_SURNAME in einer Tabelle erstellen. Dies ist eine selbsterklärende Spalte, deren Zweck es ist, Nachnamen von Kunden zu speichern, einen Wert für jede Zeile. Denken Sie auch hier an die Zeilen in einer Excel-Tabelle, und Sie werden eine ziemlich gute Vorstellung davon haben, wie Spalten in einer relationalen Tabelle funktionieren.

Primärschlüssel (primary key)

Ein Primärschlüssel ist eine spezielle Spalte oder Kombination von Spalten, die jeden Datensatz (Zeile) in der Tabelle eindeutig identifiziert. Die Primärschlüsselspalte muss für jede Zeile eindeutig sein und darf keine Nullen (Nicht-Werte) enthalten.

Der Primärschlüssel ist zusammen mit dem eng verwandten Konzept des Fremdschlüssels (foreign key) die wichtigste Methode zur Definition von Beziehungen. Primärschlüssel können auch aus einer Kombination von Spalten bestehen. Beispielsweise ist ein Kalendermonat für viele Unternehmen eine kurzfristige Finanzperiode. Um einen Zeitraum eindeutig zu identifizieren, können Sie daher die Monatsspalte und die Jahresspalte kombinieren, z. B. Mai 2011, um einen Primärschlüssel zu bilden, der jeden einzelnen Finanzzeitraum eindeutig identifiziert.

Fremdschlüssel (foreign key)

Wir können nicht über das Yin der Primärschlüssel sprechen, ohne das Yang der Fremdschlüssel zu erwähnen. Die beiden gehen Hand in Hand. Ein Primärschlüssel definiert einen Datensatz eindeutig, während ein Fremdschlüssel verwendet wird, um auf denselben Datensatz in einer anderen Tabelle zu verweisen.

Nehmen wir an, in der Datenbank einer Geschäftsbank gibt es eine Spalte CUSTOMER_ID als Primärschlüssel in der Tabelle CUSTOMER_MASTER. Damit wird jeder Kunde eindeutig identifiziert. Nehmen wir weiter an, dass dieselbe Tabelle auch andere relevante Kundeninformationen in anderen Spalten enthält, wie z. B. KUNDENNAME, VORNAME, SOZIALSPEZIALNUMMER, KUNDE, KUNDEN_GESCHLECHT usw.

Wir haben auch eine andere Tabelle mit dem Namen LOANS_MASTER, in der wir die an die Kunden derselben Bank vergebenen Kredite erfassen. In dieser Tabelle benötigen wir nur noch eine einzige Spalte, um festzustellen, welcher Kunde einen bestimmten Kredit erhalten hat. Wir können diese Spalte CUSTOMERID nennen, und sie verweist auf die Spalte CUSTOMER_ID in der Tabelle CUSTOMER_MASTER. Alle anderen Kundeninformationen (Name, Geschlecht, Sozialversicherungsnummer usw.) brauchen wir nicht in der Darlehenstabelle zu speichern. Das ist die Eleganz des relationalen Modells.

SQL

Die Structured Query Language (SQL) ist die gängige Sprache für die Verwaltung und Bearbeitung von Daten in relationalen Datenbanken. Mit SQL lassen sich Daten abfragen, einfügen, aktualisieren und ändern. Alle großen relationalen Datenbanken unterstützen SQL, was Datenbankadministratoren (DBAs), die Datenbanken auf verschiedenen Plattformen betreuen müssen, das Leben sehr erleichtert. Die Beherrschung von SQL ist in der Regel eines der ersten Dinge, die ein DBA zu Beginn seiner Karriere lernen muss. Beachten Sie, dass manche Leute SQL als ein Wort aussprechen, zu Deutsch “Folge”.

Beachten Sie, dass sich die SQL-Sprache von SQL Server, einer relationalen Datenbankplattform von Microsoft, unterscheidet. Die Verwendung des Oberbegriffs SQL kann für Anfänger verwirrend sein.

Die meisten kommerziellen RDBMS-Plattformen haben ihre eigenen, angepassten SQL-Implementierungen, die jedoch in der Regel vollständig mit dem Standard-SQL kompatibel sind.

Andere Arten von Datenbanken

Datenbanken vs. Tabellenkalkulationen

“Excel speichert auch meine Daten, und ich kann sie mit Hilfe von Filtern abrufen und bearbeiten, sie mit anderen Dateien und Arbeitsblättern verknüpfen und erweiterte Funktionen wie VLOOKUP, PivotTable usw. ausführen. Wozu brauche ich also diese ausgefallene Datenbank, von der Sie sprechen? Ihr IT-Leute wollt mir doch nur Geld aus der Tasche ziehen. Nein, meine Excel-Tabellen sind völlig ausreichend!”

Kommt Ihnen das bekannt vor? Vielleicht ja, wenn Sie schon einmal als Datenbankberater für kleine Unternehmen gearbeitet haben. Auf den ersten Blick scheint es, dass viele der Funktionen, die Datenbanken bieten, viel einfacher (und billiger!) mit Tabellenkalkulationen erreicht werden können. Die Tabellenkalkulation hat jedoch eine Reihe von Einschränkungen, die sie für die Verwaltung bestimmter Daten ungeeignet machen:

• Tabellenkalkulationen sind im Allgemeinen nicht für den Zugriff mehrerer Benutzer geeignet. Wenn Sie in einem Unternehmen arbeiten, in dem gemeinsam genutzte Dateien verwendet werden, sind Sie wahrscheinlich schon einmal auf die ärgerliche Fehlermeldung “Datei ist durch einen anderen Benutzer gesperrt” gestoßen. Selbst wenn eine bestimmte Art von Tabellenkalkulation über eine gewisse Mehrbenutzerfunktionalität verfügt, ist diese relativ begrenzt. Datenbanken hingegen können den Mehrbenutzerzugriff perfekt handhaben, selbst bei einer Mischung aus Lese- und Schreibzugriff für dieselben Daten.
• Tabellenkalkulationen bieten eine schlechte Datenvalidierung und -integrität. Es gibt wenig, was einen Ihrer Benutzer daran hindert, die Daten in einer Excel-Datei vollständig zu löschen. Natürlich können Sie Passwörter für Arbeitsblätter verwenden, aber diese bieten nur ein sehr begrenztes Maß an Sicherheit und können niemanden davon abhalten, die gesamte Datei zu löschen. Datenbanken können eine fein abgestufte Sicherheit bieten und die Benutzer sogar vor ihren eigenen Fehlern schützen. Eine Datenbankanwendung lässt sich beispielsweise leicht so einrichten, dass beim Anlegen eines Kunden auch die Sozialversicherungsnummer eingegeben werden muss.
• Abfragen und Berichte sind eine Funktion, die Tabellenkalkulationen nicht gut beherrschen. Die Möglichkeit, Abfragen über einen Datensatz durchzuführen, ist äußerst nützlich. Zugegeben, Tabellenkalkulationen bieten einige rudimentäre Möglichkeiten zur Erstellung von Berichten über Filter und Diagramme, aber der Vergleich mit SQL-Abfragen in Datenbanken, die mehrere Tabellen verbinden und komplexe Operationen durchführen können, ist so, als würde man Fred Flinststones Auto mit einer brandneuen Mercedes S-Klasse, dem Inbegriff der Automobiltechnik, vergleichen.
• Die Computerressourcen werden durch die Bearbeitung großer Tabellenkalkulationen stark beansprucht. Datenbanken können mühelos Daten in der Größenordnung von Millionen von Zeilen speichern und zugänglich machen, die in Hunderten von Tabellen organisiert sind, die alle auf einem einfachen Server laufen, ohne dass man ins Schwitzen kommt. Versuchen Sie einmal, die Anzahl der Zeilen in Ihrer Excel-Datei auf Hunderttausende von Zeilen zu erhöhen, und beobachten Sie, was mit der Reaktionszeit Ihres Computers passiert.

Tabellenkalkulationen sind viel einfacher zu erstellen und zu pflegen. Datenbanken erfordern mehr Investitionen, sowohl in finanzieller Hinsicht als auch in Bezug auf die Ausbildung der Mitarbeiter. Die Belohnung dafür ist jedoch ein viel robusteres und sichereres System zur Speicherung und Abfrage von Daten. Der Punkt, an dem Sie von Tabellenkalkulationen auf ein datenbankgestütztes System umsteigen sollten, ist dann erreicht, wenn Sie eine oder mehrere der folgenden Fragen mit “Ja” beantworten können:

• Werden die in Tabellenkalkulationen gespeicherten Daten langfristig oder regelmäßig benötigt, im Gegensatz zu einer einmaligen Bearbeitung?
• Benötigen mehrere Personen Zugriff auf diese Daten?
• Müssen Sie sich gegen Fehleingaben absichern?
• Müssen die Daten vor versehentlicher Verfälschung geschützt werden?

Relationale Datenbanken

Wie wir bereits festgestellt haben, sind die Gründe für die Dominanz relationaler Datenbanken Einfachheit, Robustheit, Flexibilität, Leistung, Skalierbarkeit und Kompatibilität bei der Verwaltung allgemeiner Daten.

Um all dies bieten zu können, müssen relationale Datenbanken jedoch intern unglaublich komplex sein. Eine relativ einfache SELECT-Anweisung kann beispielsweise Hunderte von möglichen Abfrageausführungspfaden haben, die der Optimierer zur Laufzeit auswertet. All dies bleibt uns als Benutzern verborgen, aber unter der Haube bestimmt das RDBMS den “Ausführungsplan”, der die Anfragen am besten beantwortet, indem es Dinge wie kostenbasierte Algorithmen verwendet.

Die meistverkaufte Limousine Amerikas in den 2000er Jahren war der Toyota Camry, und es ist nicht schwer zu verstehen, warum. Der Camry ist in vielen der Kategorien, die zur Beurteilung von Autos herangezogen werden, wie Sicherheit, Benzinverbrauch, Innenraumvolumen, Zuverlässigkeit und einigen anderen, nicht der Beste. Dennoch liegt er in jeder Kategorie in der Nähe der Spitze, was ihm eine Gesamtbewertung beschert, die ihn an die Spitze bringt. Was, so werden Sie sich fragen, hat eine mittelgroße Familienlimousine mit unserer Diskussion über Datenbanken zu tun? Wie der Camry zeichnet sich auch die relationale Datenbank nicht durch eine der Qualitäten einer guten Datenbank aus, aber sie erfüllt alle Bereiche gut, so dass sie als Standardlösung gilt.

Mit dem Aufkommen des Web 2.0 und insbesondere des Cloud-basierten Computings ist der Bedarf an webfähigen Datenbanken gestiegen, um unvorstellbar große Mengen an Inhalten bereitzustellen, zu speichern und zu verwalten. Inhalte wie die Nutzerprofile und Beiträge von Facebook für Millionen von Menschen auf der ganzen Welt, die Milliarden von Suchanfragen und Webcrawls anderer Websites von Google, die Millionen von gespeicherten Nutzerdokumenten und -dateien von Dropbox, die Millionen von Auktionsangeboten von eBay und so weiter. Das Schlagwort für diesen Bereich lautet allgemein “Big Data”.

Bei all diesen webzentrierten Datenbanken ist das Hauptproblem die Skalierbarkeit. Da immer mehr Anwendungen in Umgebungen mit massiven Arbeitslasten eingeführt werden (man denke nur an die vielfältigen Webdienste, die heute im Web verfügbar sind), können sich ihre Skalierungsanforderungen sehr schnell ändern und sehr groß werden. Relationale Datenbanken lassen sich gut skalieren, aber in der Regel nur, wenn die Skalierung auf einem einzigen Server erfolgt. Wenn die Kapazität dieses einen Servers erreicht ist, muss die Last auf mehrere Server verteilt werden, was zu einer so genannten verteilten Datenverarbeitung führt. Dies ist der Zeitpunkt, an dem die Komplexität relationaler Datenbanken mit ihrem Skalierungspotenzial kollidiert. Versuchen Sie, eine Skalierung auf Hunderte oder Tausende von Servern vorzunehmen, und die Komplexität wird überwältigend. Die Eigenschaften, die RDBMS so attraktiv machen, sind genau die gleichen, die auch ihre Eignung als Plattform für große verteilte Systeme drastisch einschränken.

Um Cloud-Dienste rentabel zu machen, mussten die Anbieter diese Einschränkung in Angriff nehmen, denn eine Cloud-Plattform ohne einen schnell skalierbaren Datenspeicher ist nahezu nutzlos. Um den Kunden einen skalierbaren Speicherplatz für Anwendungsdaten zu bieten, mussten die Anbieter eine neue Art von Datenbanksystem implementieren, das sich zwanghaft auf die Skalierbarkeit konzentriert – auf Kosten der anderen Vorteile, die relationale Datenbanken mit sich bringen. Im Folgenden werden wir uns diese neuen, nicht-relationalen Datenbanken genauer ansehen.

Nicht-relationale Datenbanken

Eine der größten Einschränkungen relationaler Datenbanken besteht darin, dass jedes Element nur ein Attribut enthalten kann. In dem Bankbeispiel, das wir uns vorhin angesehen haben, muss (oder besser gesagt sollte) jeder Aspekt der Beziehung eines Kunden zu einer Bank als separate Zeilenelemente in separaten Tabellen gespeichert werden. Die Stammdaten des Kunden befinden sich in einer Tabelle, die Kontodaten in einer anderen Tabelle, die Darlehensdaten in einer weiteren, die Anlagen in einer anderen Tabelle usw. Alle diese Tabellen sind durch Relationen oder Primär- und Fremdschlüssel miteinander verknüpft.

Nicht-relationale Datenbanken, insbesondere die Schlüssel-Wert-Speicher oder Schlüssel-Wert-Paare einer Datenbank, unterscheiden sich grundlegend von diesem Modell. Mit Schlüssel-Wert-Paaren können Sie mehrere zusammengehörige Elemente in einer “Zeile” von Daten in derselben Tabelle speichern. Wir setzen das Wort “Zeile” in Anführungszeichen, weil eine Zeile hier nicht wirklich dasselbe ist wie die Zeile einer relationalen Tabelle oder einer Tabellenkalkulation, obwohl es zum Vergleich immer noch nützlich ist, sie so zu nennen. In einer nicht-relationalen Tabelle für dieselbe Bank würde beispielsweise jede Zeile die Daten des Kunden sowie seine Konto-, Kredit- und Anlagedaten enthalten. Alle Daten, die sich auf einen Kunden beziehen, würden bequem in einem einzigen Datensatz gespeichert.

Dies scheint eine offensichtlich bessere Methode zur Datenspeicherung zu sein. Warum in aller Welt verwenden wir dann immer noch relationale Datenbanken statt dieses Modells? Nun, das Problem mit Key-Value-Speichern ist, dass sie im Gegensatz zu relationalen Datenbanken keine Beziehungen zwischen Datenelementen erzwingen können. In unserer Key-Value-Datenbank würden beispielsweise die Kundendaten (Name, Sozialversicherungsnummer, Adresse, Kontonummer, Kreditbearbeitungsnummer usw.) alle in einem einzigen Datensatz gespeichert (anstatt in mehreren Tabellen, wie im relationalen Modell). Die Transaktionen des Kunden (Kontoabhebungen, Kontoeinzahlungen, Kreditrückzahlungen, Bankgebühren usw.) werden ebenfalls in einem einzigen Datensatz gespeichert.

Im relationalen Modell gibt es eine eingebaute und narrensichere Methode, um die Geschäftslogik auf der Datenbankebene zu gewährleisten und durchzusetzen, zum Beispiel, dass eine Abhebung dem richtigen Bankkonto belastet wird. In Key-Value-Speichern liegt diese Verantwortung direkt bei der Anwendungslogik. Viele Menschen sind sehr nervös, wenn es darum geht, diese entscheidende Verantwortung nur der Anwendung zu überlassen, weshalb relationale Datenbanken in absehbarer Zeit nicht verschwinden werden.

Wenn es jedoch um webbasierte Datenbanken geht, steht der Aspekt der strikten Durchsetzung von Geschäftsregeln oft weit unten auf der Prioritätenliste. Ganz oben auf der Liste steht die Fähigkeit, eine große Anzahl von Benutzeranfragen zu bedienen, in der Regel reine Leseanfragen. Auf einer Website wie dem riesigen Online-Auktionshaus eBay.com beispielsweise stöbern die meisten Benutzer lediglich in den eingestellten Artikeln (reine Lesevorgänge). Nur ein Bruchteil dieser Nutzer gibt tatsächlich Gebote ab oder reserviert die Artikel (Lese- und Schreibvorgänge).

Und bedenken Sie, dass wir von Millionen, manchmal Milliarden von Seitenaufrufen pro Tag sprechen. Die Eigentümer einer solchen Website sind eher an einer schnellen Reaktionszeit interessiert, um ein schnelleres Laden der Seite für die Benutzer der Website zu gewährleisten, als an den traditionellen Prioritäten der Durchsetzung von Geschäftsregeln oder der Gewährleistung eines Gleichgewichts zwischen Lese- und Schreibvorgängen. Dies lässt sich auch auf andere große, bekannte Websites im Internet übertragen – Google, Facebook, Amazon, Twitter usw.

Relationale Datenbanken können so angepasst und eingerichtet werden, dass sie umfangreiche Nur-Lese-Operationen ausführen können (durch Data Warehousing und Data Marts) und somit potenziell auch solche Kunden bedienen können. Die eigentliche Herausforderung besteht jedoch in der mangelnden Skalierbarkeit des relationalen Modells, wie wir bereits erwähnt haben. Hier können nicht-relationale Modelle wirklich glänzen. Sie können die Datenlast problemlos auf Dutzende, Hunderte und im Extremfall (wie bei der Google-Suche) sogar Tausende von Servern verteilen. Da jeder Server nur einen kleinen Prozentsatz der gesamten Benutzeranfragen bearbeitet, ist die Antwortzeit für jeden einzelnen Benutzer sehr gut. Obwohl es dieses Modell der verteilten Datenverarbeitung auch für relationale Datenbanken gibt, ist es sehr mühsam zu implementieren. Denn das relationale Modell besteht auf Datenintegrität auf allen Ebenen, und diese muss auch dann gewahrt bleiben, wenn auf die Daten von mehreren verschiedenen Servern aus zugegriffen und sie verändert werden. Dies ist der Grund dafür, dass das nicht-relationale Modell die bevorzugte Architektur für Web 2.0-Anwendungen wie Cloud-Computing und soziale Netzwerke ist.

Einige Beispiele für nicht-relationale Datenbanken, die auf bekannten Websites eingesetzt werden, sind SimpleDB von Amazon und BigTable von Google Search. Andere nicht-relationale Engines, die entweder als Open-Source oder im Handel erhältlich sind, sind CouchDB, Mongo, Drizzle und das ungewöhnlich benannte Project Voldemort.

Datenbanken vs. Data Warehouses

Ein Data Warehouse ist eine spezielle Art von Datenbank, die für Abfragen, Berichte und Analysen optimiert ist. Die Daten in einem Data Warehouse sind fast immer schreibgeschützt und stammen in der Regel aus der operativen Datenbank und anderen Systemen. Sie werden dann so eingerichtet, dass sie in regelmäßigen Abständen mittels Extraktions-, Transformations- und Ladeprozessen (ETL) in das Warehouse hochgeladen werden, um sie in eine Form zu bringen, die sich besser für Berichte und tiefergehende Analysen eignet. Die genauen Einzelheiten dieser Umwandlung sind komplex, so dass wir sie hier nicht näher erläutern wollen. Der Hauptvorteil der Berichterstattung mit Data Warehouses gegenüber den Transaktionsdatenbanken des Unternehmens besteht darin, dass Warehouses eine viel bessere und feinere Datenanalyse für den Geschäftsgebrauch ermöglichen. Die Verwendung eines Data Warehouse entlastet auch das Transaktionssystem, das für große Unternehmen sehr anstrengend sein kann, vor allem zum Quartalsende oder zum Jahresende. Darüber hinaus bewahren Data Warehouses eine klare und vollständige Historie aller Daten auf, auch wenn das transaktionale System diese Möglichkeit möglicherweise nicht bietet.

Ein gutes Beispiel für die Nützlichkeit von Data Warehousing ist die Finanzdienstleistungsbranche. Banken nutzen ihre Data-Warehousing-Fähigkeiten in der Regel für eingehende Prognosen und Planungen. Sie nutzen Muster und Trendanalysen, um Fragen zu beantworten wie:

• Welches sind die Kundentypen, bei denen die Wahrscheinlichkeit eines Kreditausfalls am größten ist? Gibt es einen Zusammenhang zwischen dem Einkommen eines Kunden, seinem Kreditrückzahlungsverhalten und seinen Abhebungen am Geldautomaten und seiner Fähigkeit zur Kreditrückzahlung?
• Welches ist die beste Jahreszeit, um z. B. gewerblichen Landwirten eine Finanzierung anzubieten? Benötigen sie in der Regel kurz vor oder kurz nach der Erntezeit oder in der Mitte des Anpflanzungszyklus finanzielle Unterstützung?
• Warum führen so viele Studenten ihre Konten bei uns nicht weiter, nachdem sie ihren Abschluss gemacht und einen Arbeitsplatz gefunden haben? Welche Funktionen oder Vorteile erhalten sie von anderen Banken, die wir nicht anbieten?

Data Warehouses sind auch in anderen Branchen nützlich, z. B. bei der Analyse von Versicherungsbetrug und dem Abgleich von Mustern, bei der Analyse von Telekommunikationsanrufen, bei Wetter- und Klimavorhersagen in der Landwirtschaft und in vielen anderen Bereichen.

Ein gutes Beispiel für die Leistungsfähigkeit der von Data Warehouses angebotenen Analysen ist die bekannte Geschichte eines großen Einzelhandelsunternehmens. Nach der Analyse der Daten aus dem Data Warehouse fiel den Geschäftsleitern ein verblüffender Trend auf: Die Verkäufe von Windeln und Babynahrung in den späten Abendstunden gingen mit einem sprunghaften Anstieg von Getränken, insbesondere von Dosenbier, einher. Nach einigem Kopfzerbrechen und stundenlanger Untersuchung dieser späten Kunden kam die Antwort schließlich ans Licht. Es handelte sich um frischgebackene Eltern, vor allem junge Väter, die von ihren Frauen oder Freundinnen losgeschickt wurden, um Windeln für das Baby zu kaufen, und die gestressten jungen Väter beschlossen, dass sie dabei auch gleich ein Getränk zu sich nehmen könnten, um sich zu entspannen. Das Einzelhandelsgeschäft platzierte daraufhin beide Warengruppen in den Gängen näher beieinander, um noch mehr von diesem Markt abzugreifen, und konnte so seinen Umsatz mit alkoholischen Getränken nach 21 Uhr verdreifachen.

Wie Sie sehen, unterscheiden sich Data Warehouses von typischen Datenbanken dadurch, dass sie für komplexere Datenanalysen verwendet werden. Dies unterscheidet sie von Transaktionsdatenbanken, deren Hauptzweck darin besteht, operative Systeme zu unterstützen und alltägliche Berichte in kleinem Umfang zu liefern. Data Warehousing muss manchmal auch eng mit der Marktforschung und anderen Abteilungen zusammenarbeiten.

Andere wichtige Datenbankkonzepte

Wir haben die grundlegenden Datenbankkonzepte besprochen, aber das sind nicht die einzigen. Es gibt auch andere wichtige sekundäre Konzepte und Datenstrukturen, die es wert sind, kennengelernt zu werden. In diesem Abschnitt werden wir einen kurzen Blick auf diese werfen.

Indizes

Ein Index in einem RDBMS ist eine Datenstruktur, die eng mit Tabellen und Spalten zusammenarbeitet, um Datenabrufe zu beschleunigen. Er funktioniert so ähnlich wie der Index am Anfang eines Buches. Mit anderen Worten, er bietet einen Bezugspunkt, der es Ihnen ermöglicht, die gewünschten Daten schnell zu finden und darauf zuzugreifen, ohne das gesamte Buch (die Datenbank) durchforsten zu müssen.

Schema

Ein Schema ist die Struktur hinter der Datenorganisation. Es ist eine visuelle Übersicht darüber, wie die verschiedenen Tabellen zueinander in Beziehung stehen. Es dient dazu, die zugrunde liegenden Geschäftsregeln abzubilden und zu implementieren, für die die Datenbank erstellt wurde.

Die Oracle DB hat eine etwas andere Definition von Schema. Hier bezieht sich das Schema auf die Sammlung von Datenbankobjekten eines Benutzers. Der Name des Schemas und der Benutzername sind identisch, haben aber unterschiedliche Funktionen, d. h. ein Benutzer kann gelöscht werden, während seine Sammlung von Objekten (Schema) in der Datenbank intakt bleibt und sogar einem anderen Benutzer neu zugewiesen werden kann.

Nachstehend sehen Sie ein Beispiel für ein einfaches Datenbankschema:

Normalisierung

Normalisierung ist der Prozess der (Neu-)Organisation von Daten in einer Datenbank, so dass zwei grundlegende Anforderungen erfüllt werden: Es gibt keine Datenredundanz (alle Daten werden nur an einem Ort gespeichert), und die Datenabhängigkeiten sind logisch (alle verwandten Datenelemente werden zusammen gespeichert). In der Datenbank einer Bank sollten beispielsweise alle statischen Kundendaten, wie Name, Adresse und Alter, zusammen gespeichert werden. Alle Kontoinformationen, wie z. B. Kontoinhaber, Kontoart, Kontofiliale usw., sollten ebenfalls zusammen gespeichert werden; sie sollten auch getrennt von den statischen Kundendaten gespeichert werden.

Die Normalisierung ist aus vielen Gründen wichtig, vor allem aber, weil sie es den Datenbanken ermöglicht, so wenig Speicherplatz wie möglich zu beanspruchen, was zu einer höheren Leistung führt. Es gibt mehrere inkrementelle Arten der Normalisierung, die recht komplex werden können.

Beschränkungen

In der Welt der RDBMS bedeutet Einschränkung genau dasselbe wie in der realen Welt. Eine Einschränkung ist eine Beschränkung der Art von Daten, die Sie in eine bestimmte Spalte eingeben können. Einschränkungen werden immer für Spalten definiert. Eine gängige Einschränkung ist die Nicht-Null-Beschränkung. Sie legt einfach fest, dass alle Zeilen in einer Tabelle einen Wert in der Spalte haben müssen, der als nicht null definiert ist.

Transaktionen (Commits und Rollbacks)

Stellen Sie sich vor, eine Bank baut ihre Datenbanksysteme auf. Stellen Sie sich vor, das System stürzt ab, wenn gerade eine Überweisung im Gange ist. Große Probleme, nicht wahr? Dies ist der Grundgedanke einer Transaktion: Alle Elemente einer Reihe von Änderungen müssen zusammen durchgeführt werden. Wenn Sie bei einer einfachen Überweisung ein Konto belasten, müssen Sie einem anderen Konto eine Gutschrift erteilen.

In relationalen Datenbanken wird das Speichern einer Transaktion als Commit bezeichnet, und das Rückgängigmachen nicht gespeicherter Änderungen als Rollback. Das ist die grundlegende Definition, aber es wird noch komplizierter, wenn man bedenkt, dass Datenbanken normalerweise mehrere Benutzer gleichzeitig bedienen müssen. Was passiert, wenn andere Benutzer die gleichen Daten abfragen, bevor die Transaktionen gespeichert werden? Zu welchem Zeitpunkt sehen die anderen Benutzer die gespeicherten Daten? Alle RDBMS müssen in der Lage sein, diese Fragen zufriedenstellend zu beantworten, und sie tun dies durch die Commit/Rollback-Funktionen.

Datenbanken müssen auch Fehlertoleranz bieten, selbst im Falle eines Festplattenausfalls. Wenn Daten übertragen werden, muss es eine hundertprozentige Garantie dafür geben, dass die Daten auch tatsächlich gespeichert werden. Relationale Datenbanken verfügen über ausgeklügelte Methoden, um dies zu erreichen, z. B. zweiphasige Commits und die Verwendung von Protokolldateien.

ACID

Der Begriff ACID bezieht sich hier nicht auf psychedelische Substanzen, mit denen DBAs besser arbeiten können. Vielmehr handelt es sich um ein Akronym, das vier äußerst wünschenswerte Eigenschaften eines jeden RDBMS beschreibt:

• Atomarität: Dies bezieht sich auf die Fähigkeit einer Datenbank, eine Transaktion entweder vollständig zu verarbeiten oder vollständig rückgängig zu machen.
• Konsistenz: Die Datenbank sollte sicherstellen, dass alle darin geschriebenen Daten allen in der Datenbank spezifizierten Regeln und Beschränkungen folgen.
• Isolierung: Transaktionen müssen sicher und unabhängig voneinander verarbeitet werden, ohne sich gegenseitig zu beeinträchtigen.
• Dauerhaftigkeit: Die Datenbank muss sicherstellen, dass alle festgeschriebenen Transaktionen dauerhaft gespeichert werden und nicht versehentlich gelöscht werden können, auch nicht bei einem Datenbankabsturz.

Sperrung von Datenbanken

Wie wir bereits gesehen haben, ermöglichen Datenbanken mehreren Benutzern den gleichzeitigen Zugriff auf einen Datensatz. Daher stellt sich unweigerlich die Frage, wie man mit Situationen umgeht, in denen zwei oder mehr Benutzer auf dieselben Daten zugreifen oder sie aktualisieren wollen. RDBMS lösen dieses Problem durch den Einsatz von Sperren.

Es gibt verschiedene Arten von Sperren, z. B. Sperren auf Transaktions- oder Datenebene, die lediglich ein einzelnes Datenfeld sperren; Sperren auf Zeilenebene, die einen ganzen Datensatz sperren, während Sperren auf Tabellenebene den Zugriff auf eine ganze Tabelle beschränken. Wie Sie sehen, ist der letzte Sperrtyp besonders restriktiv. Sie wird daher nur verwendet, wenn es unbedingt notwendig ist, z. B. wenn tabellenweite Daten geladen oder tabellenweite Sicherungen durchgeführt werden.

Übrigens können Tabellenkalkulationen nur Sperren auf Tabellenebene verwenden. Dies ist ein Paradebeispiel für ihre Unterlegenheit im Vergleich zu Datenbanken. Wenn Sie in einer Büroumgebung arbeiten, ist es Ihnen wahrscheinlich schon einmal passiert, dass Sie bei der Arbeit an einer gemeinsam genutzten Excel-Tabelle die lästige Meldung “Datei ist von einem anderen Benutzer gesperrt” erhalten. Sperren sind eine wichtige Methode zur Implementierung der ACID-Eigenschaften (Atomicity, Consistency, Isolation, Durability) eines RDBMS.

Die häufigste Art der Sperre ist die Sperre auf Datenebene oder die Transaktionssperre. Sie erfolgt in der Regel für den Benutzer völlig unsichtbar. Wenn ein Benutzer ein bestimmtes Datenelement aktualisiert (aber nicht unbedingt festschreibt), wird es gesperrt, damit andere Benutzer keine weiteren Änderungen daran vornehmen können. Der andere Benutzer kann jedoch weiterhin dieselben Daten lesen. Dies ist eine nette Funktion von RDBMS. Zu diesem Zeitpunkt sehen die anderen Benutzer nur den “alten” Wert des Datenelements, der vor den Änderungen bestand. Sobald der Hauptbenutzer die Änderung festschreibt (speichert), sehen alle Benutzer, die jetzt die Daten abfragen, den neuen, aktualisierten Wert. Denken Sie daran, dass der Begriff “neuer Wert” auch eine Löschung der vorhandenen Daten beinhalten kann, in diesem Fall ist das Feld jetzt ein Nullwert.

Wenn der Benutzer stattdessen die Änderung verwirft und ein Rollback durchführt, sehen die anderen Benutzer immer noch dieselben Daten, können aber jetzt auch das Datenelement aktualisieren.

Wenn ein Benutzer versucht, ein Element zu ändern, das bereits von einem ersten Benutzer gesperrt wurde, erhält der zweite Benutzer entweder eine Fehlermeldung oder das System bleibt für kurze Zeit stehen, während er darauf wartet, dass der erste Benutzer die Änderung entweder bestätigt (speichert) oder zurücknimmt (rückgängig macht).

Eine kuriose Situation kann entstehen, wenn zwei Benutzer jeweils ein Datenelement gesperrt haben und dann beide versuchen, auf genau das Datenelement zuzugreifen, das der andere Benutzer besitzt, und eine Änderung daran vorzunehmen. In diesem Fall besteht die Möglichkeit, dass das Element auf unbestimmte Zeit gesperrt wird, während jeder Benutzer auf den anderen wartet. Dies wird als Deadlock bezeichnet, und die meisten RDBMS verfügen über eine Methode, um dies zu erkennen und aufzulösen. Das System wählt in der Regel einen Benutzer nach dem Zufallsprinzip aus und macht dessen Änderungen rückgängig, wodurch die von diesem Benutzer gesperrten Daten wieder freigegeben werden und der Deadlock beendet wird.

Sie können sich vorstellen, dass das Sperren eine teure Aktivität ist, die Datenbank- und Computerressourcen kostet. Systeme, die schreibintensive Datenbanken beherbergen, müssen robust genug sein, um die durch Sperren verbrauchten Ressourcen zu unterstützen, insbesondere die CPU. Außerdem müssen die Anwendungen so konzipiert sein, dass sie Daten so selten wie möglich sperren. Eine Möglichkeit, dies zu erreichen, besteht darin, die Fähigkeit zur Datenspeicherung in die Anwendung selbst einzubauen. Sobald ein Datenelement aus der Datenbank gelesen wird, sollte die Anwendung alle Änderungen intern durchführen, ohne vorher mit der Datenbank zu interagieren. Erst wenn der Benutzer auf “Speichern” klickt, schreibt die Anwendung das Element schnell zurück in die Datenbank. Dadurch wird die Zeitspanne, in der sich ein Datenelement aus Sicht der Datenbank in einem Schwebezustand befindet, d. h. “geändert”, aber noch nicht “bestätigt” oder “zurückgenommen” wurde, minimiert.

Sperren auf Tabellenebene sind, wie bereits erwähnt, sehr restriktiv, da sie eine ganze Tabelle sperren. Obwohl sie nur selten verwendet werden, sind sie bei einigen Operationen von unschätzbarem Wert, z. B. bei Massen-Uploads von Daten oder bei der Reorganisation fragmentierter Daten für eine ganze Tabelle. In solchen Fällen ist es zweckmäßig, sicherzustellen, dass kein anderer Benutzer für die Dauer der Operation auf die Tabelle zugreifen kann, und die Sperre sollte sofort freigegeben werden, wenn die Operation beendet ist. Daher werden diese Sperren in der Regel nur von DBAs für diese speziellen Operationen verwendet. Sperren auf Tabellenebene müssen normalerweise explizit angegeben werden; standardmäßig verwendet das RDBMS Sperren auf Zeilenebene oder auf Transaktionsebene.

Kommerzielle RDBMS-Systeme

Wir haben nun den größten Teil der Grundlagen von relationalen Datenbanken behandelt. Sie sind der am weitesten verbreitete Datenbanktyp auf dem Markt und darüber hinaus eine der wichtigsten Arten von Software, gleichauf mit Betriebssystemen, Büroanwendungen und Spielen.

Es wird Sie also nicht überraschen zu hören, dass die großen, erfolgreichen RDBMS-Anbieter zu den Titanen der Softwarebranche gehören und nicht nur in der Softwarewelt, sondern auch in den Mainstream-Nachrichten und der Kultur ein Begriff sind. Namen wie Oracle und Microsoft sind allgegenwärtig und selbst Nicht-IT-Fachleuten sehr vertraut.
Viele RDBMS-Anbieter bringen sowohl verwandte als auch völlig andere Produkte auf den Markt. Allen gemeinsam ist jedoch, dass das RDBMS eine ihrer wichtigsten Produktlinien ist. Sie hören genau zu und bemühen sich, Feedback vom Markt einzuholen, was in der Softwarebranche nicht immer der Fall ist.

Aus geschäftsstrategischen Gründen arbeiten viele ihrer Produkte jedoch nicht gut mit den Angeboten der Konkurrenz oder mit anderer Software zusammen. So ist beispielsweise SQL Server von Microsoft nur für das Windows-Betriebssystem erhältlich, das ebenfalls von Microsoft stammt. Es gab Beschwerden, dass Oracle DB nicht so gut mit dem Windows-Betriebssystem zusammenarbeitet wie mit Linux usw.

Ein zunehmender Trend in der Branche ist die Konsolidierung und Bündelung des RDBMS mit anderer Software desselben Herstellers, z. B. einem bevorzugten Betriebssystem oder anderer ergänzender Software wie:

• Zusätzliche Datensicherheitsmodule, wie z.B. Oracle DataGuard,
• Integration mit einer Entwicklungsplattform, wie z.B. Microsofts .NET,
• All-in-One-Plattformen, die Hardware und Software kombinieren, wie z. B. Oracle Exadata oder Microsoft Trefis.

Wir werden nun einen kurzen Blick auf einige kommerzielle RDB-Angebote und die dahinter stehenden Unternehmen werfen:

Oracle

Oracle ist einer der Giganten in der Welt der RDBMS. Das Unternehmen wurde 1977 von dem charismatischen, abenteuerlustigen CEO Larry Ellison gegründet und ist heute dank seines Flaggschiffprodukts Oracle DB ein milliardenschwerer Gigant in der Welt der kommerziellen Datenbanken. Darüber hinaus stellt Oracle eine verwirrende Vielzahl anderer Produkte her, von Middleware über Enterprise Resource Planning-Systeme bis hin zu Customer Relationship Management (CRM)-Angeboten. Viele dieser Produkte wurden nicht selbst entwickelt, sondern durch die Übernahme anderer Softwareunternehmen wie PeopleSoft, Siebel Systems, Sun Microsystems und BEA Systems erworben. Mehrere dieser Produkte wurden mit gemischtem Erfolg in das Middleware-Produkt Fusion integriert.

Die Oracle DB wird häufig in Datenbanken auf Unternehmensebene eingesetzt. Sie ist in verschiedenen Editionen erhältlich, um unterschiedlichen Anforderungen gerecht zu werden. Oracle DB ist vollständig kompatibel mit der SQL-Sprache, obwohl es auch seine eigene Version namens SQL*Plus unterhält. Oracle DB ist das führende RDBMS mit einem Marktanteil von 48,8 Prozent am RDBMS-Markt (Stand: Ende 2011).

Interessant ist, dass Oracle im Jahr 2009 Sun Microsystems, den Lizenzinhaber von MySQL, einem der wichtigsten Konkurrenten von Oracle DB, übernommen hat. Damit verfügt Oracle über zwei RDBMS-Angebote. Oracle DB und MySQL sollten sich jedoch nicht gegenseitig behindern, da sie in leicht unterschiedlichen Marktsegmenten tätig sind und leicht unterschiedliche Bedürfnisse befriedigen.

Microsoft

Microsoft ist mit seinem Produkt SQL Server ein weiterer großer Junge in der Welt der RDBMS-Software, obwohl das Unternehmen eher für sein universelles Windows-Betriebssystem und die Office-Suite mit ihren Office-Produktivitätsprogrammen bekannt ist.

SQL Server wurde um 1989 zusammen mit Sybase-Systemen entwickelt, aber die beiden Unternehmen trennten sich und entwickelten getrennte Produkte. Microsoft behielt den Namen SQL Server und Sybase entschied sich, sein Angebot in Adaptive Server Enterprise umzubenennen, um Verwechslungen mit dem SQL Server von Microsoft zu vermeiden. Das RDBMS läuft nur auf der Windows-Betriebssystemreihe.

SQL Server verwendet eine proprietäre Abfragesprache namens T-SQL, die dem Standard-SQL sehr ähnlich und mit ihm kompatibel ist. Das RDBMS hat einen Marktanteil von etwa 20 Prozent (Stand Ende 2011), der in den letzten Jahren aber auch gestiegen ist.

SQL Server und Oracle DB haben viele Gemeinsamkeiten, angefangen bei den Datenstrukturen über die Methoden der Transaktionsverarbeitung bis hin zu den Datenbankobjekten. Wie Oracle DB unterstützt auch SQL Server erweiterte ETL-Vorgänge (Extraktion, Transformation, Laden), die bei der Übertragung von Daten in Data Warehouses helfen. Beide bieten auch erweiterte Berichtsfunktionen.

Postgres

Postgres, auch bekannt als PostgreSQL, ist eine relationale Open-Source-Datenbank, die auch Datenbankobjekte unterstützen kann. Sie ist nicht im Besitz einer einzelnen Person, sondern wird von der PostgreSQL Global Development Group gepflegt, einer engagierten Gruppe von Freiwilligen, die von Unternehmen aus dem Bereich der Open-Source-Softwareentwicklung wie RedHat und EnterpriseDB verwaltet und beschäftigt wird.
Postgres ist unter Linux, Windows und MacOS verfügbar.

MySQL

MySQL ist ein weiteres Open-Source-RDBMS. Es handelt sich um ein vollwertiges Datenbanksystem, das von dem schwedischen Unternehmen MySQL AB gesponsert wird, welches sich nun im Besitz von Oracle befindet, nachdem dessen Muttergesellschaft Sun Microsystems 2010 von Oracle aufgekauft wurde.

MySQL ist sehr beliebt für webbasierte Backend-Datenbanken, entweder einzeln oder als Teil des Linux, Apache, MySQL, PHP (LAMP)-Stacks, der zur Bereitstellung von webzentrierten Anwendungen verwendet wird.

DB2

Wie SQL Server und Oracle DB ist auch DB2 von IBM ein objektorientiertes RDBMS mit vollem Funktionsumfang, das von einem der wichtigsten Anbieter in der Softwarebranche stammt. Ursprünglich wurde es in den frühen 80er Jahren ausschließlich für IBMs Mainframes entwickelt und später auf andere Plattformen wie Linux, Unix, Windows (LUW) und IBMs eigenes OS/2 portiert.

Es ist ein weit verbreitetes kommerzielles RDBMS und hat auch eine kleine kostenlose Version für Entwickler namens Express-C. Im Jahr 2009 brachte IBM die Version 9.7 von DB2 heraus, die sich eng an die Funktionen des Marktführers Oracle DB anlehnt. Dies hat dazu beigetragen, dass das Unternehmen einige Umsätze erzielen konnte, da es Oracle-erfahrenen Datenbankexperten den Einstieg in die Arbeit mit DB2 erleichtert.

Fazit

Herzlichen Glückwunsch – Sie haben es bis hierher geschafft!
Wir haben buchstäblich nur an der Oberfläche gekratzt. Schließlich beschäftigen sich viele Menschen eine ganze berufliche Laufbahn lang mit Datenbanken; da gibt es viel zu lernen! Lassen Sie uns zusammenfassen, was wir hier behandelt haben:

• Eine Datenbank ist im allgemeinsten Sinne eine organisierte Sammlung von Daten. Genauer gesagt ist eine Datenbank ein elektronisches System, das den einfachen Zugriff auf Daten sowie deren Bearbeitung und Aktualisierung ermöglicht.
• Jedes Unternehmen oder jede Organisation, die eine große Anzahl von Kunden oder Produkten im Auge behalten muss, kann von einer Datenbank profitieren, wobei große Organisationen am meisten profitieren.
• Die ersten Datenbanksysteme waren navigatorischer Natur. Das bedeutet, dass Anwendungen Daten mit Hilfe von Zeigern verarbeiteten und lasen, die in die Daten selbst eingebettet waren.
• Die frühen hierarchischen und Netzwerk-Datenmodelle wurden durch das relationale Modell von E.F. Codd übertroffen.
• Das relationale Modell war eine radikale Abkehr vom vorherrschenden hierarchischen Modell, da es sich auf die Möglichkeit konzentrierte, eine Datenbank nach dem Inhalt zu durchsuchen, anstatt einem verknüpften Navigationssystem zu folgen.
• Es gibt einige sehr wichtige nicht-relationale Datenbanken (insbesondere mit dem Aufkommen von Big Data und Web 2.0), aber das relationale Modell wird immer noch für die überwältigende Mehrheit der kommerziellen Datenbankangebote verwendet.
• Eine relationale Datenbank ist im Wesentlichen eine Gruppe von Tabellen oder, um den technischen Namen zu verwenden, Entitäten (siehe Regeln 0 und 1 in Codds 12 Regeln für relationale Datenbanken). Jede Tabelle besteht aus Zeilen (Tupeln) und Spalten (Attributen). Zwischen den Tabellen bestehen Beziehungen, die dadurch definiert sind, dass eine bestimmte Spalte in einer Tabelle auf eine Spalte in einer anderen Tabelle verweist.
• Es gibt 13 “Regeln”, die bestimmen, ob eine Datenbank als “relational” bezeichnet werden kann.
• Die Tabelle ist die grundlegende Einheit zur Datenspeicherung in einer relationalen Datenbank. Tabellen bestehen aus Spalten und Zeilen.
• Beziehungen sind DER Grund, warum relationale Datenbanken so gut funktionieren.
• In relationalen Datenbanken besteht eine Beziehung zwischen zwei Tabellen, wenn eine der Tabellen einen Fremdschlüssel hat, der auf den Primärschlüssel der anderen Tabelle verweist.
  Eine Zeile, auch Datensatz genannt, stellt eine Reihe von Daten über ein bestimmtes Element dar. Jeder Datensatz in einer Tabelle hat genau dieselbe Struktur, aber natürlich unterschiedliche Daten.
• Eine Spalte ist ein bestimmter Satz von Werten in einer Tabelle desselben Typs. Sie definiert ein bestimmtes Attribut der Tabelle oder der Daten.
• Ein Primärschlüssel ist eine spezielle Spalte oder Kombination von Spalten, die jeden Datensatz (Zeile) in der Tabelle eindeutig identifiziert. Die Primärschlüsselspalte muss für jede Zeile eindeutig sein und darf keine Nullen (Nicht-Werte) enthalten.
• Der Primärschlüssel ist zusammen mit dem eng verwandten Konzept des Fremdschlüssels die wichtigste Methode zur Definition von Beziehungen. Ein Primärschlüssel definiert einen Datensatz eindeutig, während ein Fremdschlüssel verwendet wird, um auf denselben Datensatz in einer anderen Tabelle zu verweisen.
• Structured Query Language (SQL) ist die gängige Sprache für die Verwaltung und Bearbeitung von Daten in relationalen Datenbanken. SQL kann zum Abfragen, Einfügen, Aktualisieren und Ändern von Daten verwendet werden.
• Tabellenkalkulationen und Datenbanken haben einige ähnliche Fähigkeiten, aber die Tabellenkalkulation hat eine Reihe von Einschränkungen, die sie für die Verwaltung einiger Datensituationen ungeeignet machen.
• Eine der größten Einschränkungen relationaler Datenbanken besteht darin, dass jedes Element nur ein Attribut enthalten kann. Nicht-relationale Datenbanken, insbesondere die Schlüssel-Wert-Speicher oder Schlüssel-Wert-Paare einer Datenbank, unterscheiden sich grundlegend von diesem Modell. Mit Schlüssel-Wert-Paaren können Sie mehrere zusammenhängende Elemente in einer “Zeile” von Daten in derselben Tabelle speichern.
• Ein Data Warehouse ist eine spezielle Art von Datenbank, die für Abfragen, Berichte und Analysen optimiert ist. Der Hauptvorteil der Berichterstellung mit Data Warehouses im Gegensatz zu den Transaktionsdatenbanken des Unternehmens besteht darin, dass Warehouses eine viel bessere und feinere Datenanalyse für den Geschäftsgebrauch ermöglichen.
  Ein Index in einem RDBMS ist eine Datenstruktur, die eng mit Tabellen und Spalten zusammenarbeitet, um Datenabrufe zu beschleunigen.
• Ein Schema ist die Struktur hinter der Datenorganisation. Es ist eine visuelle Übersicht darüber, wie verschiedene Tabellen miteinander in Beziehung stehen.
• Normalisierung ist der Prozess der (Neu-)Organisation von Daten in einer Datenbank, so dass sie zwei grundlegende Anforderungen erfüllen: Es gibt keine Datenredundanz (alle Daten werden nur an einem Ort gespeichert), und die Datenabhängigkeiten sind logisch (alle verwandten Datenelemente werden zusammen gespeichert).
  In der Welt der RDBMS bedeutet Einschränkung genau dasselbe wie in der realen Welt. Eine Einschränkung ist eine Beschränkung der Art von Daten, die Sie in eine bestimmte Spalte eingeben können.
• In relationalen Datenbanken wird das Speichern einer Transaktion als Commit bezeichnet, und das Rückgängigmachen nicht gespeicherter Änderungen als Rollback.
• ACID ist ein Akronym für Atomicity Consistency Isolation Durability, die vier äußerst wünschenswerten Eigenschaften eines RDBMS.
• Oracle ist einer der Giganten in der Welt der RDBMS. Sein Flaggschiffprodukt ist Oracle DB.
• Microsoft ist mit seinem Produkt SQL Server ein weiterer großer Junge in der Welt der RDBMS-Software, obwohl das Unternehmen eher für sein universelles Windows-Betriebssystem und die Office-Suite mit ihren Office-Produktivitätsprogrammen bekannt ist.
• Andere kommerzielle RDBMS-Systeme sind Postgres, MySQL und DB2.