Datenbank

Aus besserwiki.de
Eine SQL Select-Anweisung und ihr Ergebnis

In der Informatik ist eine Datenbank eine organisierte Sammlung von Daten, die elektronisch gespeichert und abgerufen werden. Kleine Datenbanken können in einem Dateisystem gespeichert werden, während große Datenbanken auf Computerclustern oder in einer Cloud untergebracht sind. Der Entwurf von Datenbanken umfasst formale Techniken und praktische Überlegungen, einschließlich Datenmodellierung, effizienter Datendarstellung und -speicherung, Abfragesprachen, Sicherheit und Schutz sensibler Daten sowie Fragen der verteilten Datenverarbeitung, einschließlich der Unterstützung von gleichzeitigem Zugriff und Fehlertoleranz.

Ein Datenbankmanagementsystem (DBMS) ist die Software, die mit Endbenutzern, Anwendungen und der Datenbank selbst interagiert, um die Daten zu erfassen und zu analysieren. Die DBMS-Software umfasst darüber hinaus die Kernfunktionen, die zur Verwaltung der Datenbank bereitgestellt werden. Die Gesamtheit der Datenbank, des DBMS und der zugehörigen Anwendungen kann als Datenbanksystem bezeichnet werden. Häufig wird der Begriff "Datenbank" auch frei verwendet, um sich auf das DBMS, das Datenbanksystem oder eine mit der Datenbank verbundene Anwendung zu beziehen.

Informatiker können Datenbankmanagementsysteme nach den von ihnen unterstützten Datenbankmodellen klassifizieren. Relationale Datenbanken haben sich in den 1980er Jahren durchgesetzt. Diese modellieren Daten als Zeilen und Spalten in einer Reihe von Tabellen, und die große Mehrheit verwendet SQL zum Schreiben und Abfragen von Daten. In den 2000er Jahren wurden nicht-relationale Datenbanken populär, die unter dem Begriff NoSQL zusammengefasst werden, da sie andere Abfragesprachen verwenden.

Eine Datenbank, auch Datenbanksystem genannt, ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe einer Datenbank ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern und benötigte Teilmengen in unterschiedlichen, bedarfsgerechten Darstellungsformen für Benutzer und Anwendungsprogramme bereitzustellen.

Die gebräuchlichste Form einer Datenbank ist eine relationale Datenbank. Die Struktur der Daten wird durch ein Datenbankmodell festgelegt.

Zu unterscheiden ist der hier beschriebene Begriff der Datenbank (bestehend aus DBMS und Daten) von Datenbankanwendungen: Letztere sind (häufig zur Anwendungssoftware gehörende) Computerprogramme, die ihre jeweils individuell erforderlichen Daten unter Nutzung eines Datenbanksystems verwalten und speichern. Beispiele: Auftragsverwaltung, Bestellwesen, Kunden- und Adressverwaltung, Rechnungserstellung.

Im Sprachgebrauch werden gelegentlich (und begrifflich unkorrekt) auch nicht mit Datenbanksystemen verwaltete Daten als „Datenbank“ bezeichnet: eine Menge thematisch zusammenhängender Dateien.

Terminologie und Überblick

Formal bezieht sich eine "Datenbank" auf einen Satz zusammengehöriger Daten und die Art und Weise, wie diese organisiert sind. Der Zugriff auf diese Daten erfolgt in der Regel über ein "Datenbankmanagementsystem" (DBMS), das aus einem integrierten Satz von Computersoftware besteht, die es den Benutzern ermöglicht, mit einer oder mehreren Datenbanken zu interagieren und auf alle in der Datenbank enthaltenen Daten zuzugreifen (auch wenn es Einschränkungen geben kann, die den Zugriff auf bestimmte Daten beschränken). Das DBMS bietet verschiedene Funktionen, die die Eingabe, Speicherung und den Abruf großer Informationsmengen ermöglichen, und bietet Möglichkeiten zur Verwaltung der Organisation dieser Informationen.

Aufgrund der engen Beziehung zwischen diesen beiden Begriffen wird der Begriff "Datenbank" oft beiläufig verwendet, um sowohl eine Datenbank als auch das DBMS zu bezeichnen, mit dem sie verwaltet werden.

Außerhalb der Welt der professionellen Informationstechnologie wird der Begriff "Datenbank" häufig für eine beliebige Sammlung zusammengehöriger Daten verwendet (z. B. eine Tabellenkalkulation oder eine Kartei), da die Größe und die Nutzungsanforderungen in der Regel den Einsatz eines Datenbankmanagementsystems erfordern.

Bestehende DBMS bieten verschiedene Funktionen, die die Verwaltung einer Datenbank und ihrer Daten ermöglichen und sich in vier Hauptfunktionsgruppen einteilen lassen:

  • Datendefinition - Erstellung, Änderung und Löschung von Definitionen, die die Organisation der Daten festlegen.
  • Aktualisierung - Einfügen, Ändern und Löschen der eigentlichen Daten.
  • Abruf - Bereitstellung von Informationen in einer Form, die direkt oder zur Weiterverarbeitung durch andere Anwendungen genutzt werden kann. Die abgerufenen Daten können in einer Form zur Verfügung gestellt werden, die im Wesentlichen der in der Datenbank gespeicherten Form entspricht, oder in einer neuen Form, die durch Änderung oder Kombination vorhandener Daten aus der Datenbank gewonnen wird.
  • Verwaltung - Registrierung und Überwachung von Benutzern, Durchsetzung der Datensicherheit, Überwachung der Leistung, Aufrechterhaltung der Datenintegrität, Umgang mit der Gleichzeitigkeitskontrolle und Wiederherstellung von Informationen, die durch ein Ereignis wie einen unerwarteten Systemausfall beschädigt wurden.

Sowohl eine Datenbank als auch ihr DBMS entsprechen den Grundsätzen eines bestimmten Datenbankmodells. Der Begriff "Datenbanksystem" bezieht sich auf das Datenbankmodell, das Datenbankmanagementsystem und die Datenbank.

Physikalisch gesehen sind Datenbankserver dedizierte Computer, die die eigentlichen Datenbanken enthalten und auf denen nur das DBMS und die zugehörige Software laufen. Bei den Datenbankservern handelt es sich in der Regel um Multiprozessor-Computer mit großzügigem Arbeitsspeicher und RAID-Festplatten-Arrays für eine stabile Speicherung. Hardware-Datenbankbeschleuniger, die über einen Hochgeschwindigkeitskanal mit einem oder mehreren Servern verbunden sind, werden ebenfalls in Umgebungen für die Verarbeitung großer Mengen von Transaktionen eingesetzt. DBMS sind das Herzstück der meisten Datenbankanwendungen. DBMS können um einen benutzerdefinierten Multitasking-Kernel mit eingebauter Netzwerkunterstützung herum aufgebaut sein, aber moderne DBMS stützen sich in der Regel auf ein Standardbetriebssystem, um diese Funktionen bereitzustellen.

Da DBMS einen bedeutenden Markt darstellen, berücksichtigen die Computer- und Speicherhersteller die DBMS-Anforderungen häufig in ihren eigenen Entwicklungsplänen.

Datenbanken und DBMS können nach dem/den von ihnen unterstützten Datenbankmodell(en) (z. B. relational oder XML), dem/den Computertyp(en), auf dem/denen sie laufen (von einem Server-Cluster bis zu einem Mobiltelefon), der/den für den Zugriff auf die Datenbank verwendeten Abfragesprache(n) (z. B. SQL oder XQuery) und ihrer internen Technik, die sich auf Leistung, Skalierbarkeit, Belastbarkeit und Sicherheit auswirkt, kategorisiert werden.

Geschichte

Die Größe, die Fähigkeiten und die Leistung von Datenbanken und ihren jeweiligen DBMS sind um Größenordnungen gewachsen. Diese Leistungssteigerungen wurden durch den technologischen Fortschritt in den Bereichen Prozessoren, Computerspeicher, Computerspeicherung und Computernetzwerke ermöglicht. Das Konzept einer Datenbank wurde durch das Aufkommen von Speichermedien mit direktem Zugriff, wie z. B. Magnetplatten, ermöglicht, die Mitte der 1960er Jahre allgemein verfügbar wurden; frühere Systeme basierten auf der sequentiellen Speicherung von Daten auf Magnetbändern. Die anschließende Entwicklung der Datenbanktechnologie lässt sich anhand des Datenmodells oder der Struktur in drei Epochen unterteilen: navigational, SQL/relational und post-relational.

Die beiden wichtigsten frühen navigatorischen Datenmodelle waren das hierarchische Modell und das CODASYL-Modell (Netzwerkmodell). Diese Modelle zeichneten sich durch die Verwendung von Zeigern (oft physische Festplattenadressen) aus, um Beziehungen von einem Datensatz zum anderen zu verfolgen.

Das relationale Modell, das erstmals 1970 von Edgar F. Codd vorgeschlagen wurde, wich von dieser Tradition ab, indem es darauf bestand, dass Anwendungen nach dem Inhalt von Daten suchen sollten und nicht durch die Verfolgung von Links. Das relationale Modell verwendet eine Reihe von buchähnlichen Tabellen, von denen jede für eine andere Art von Entität verwendet wird. Erst Mitte der 1980er Jahre wurde die Computerhardware leistungsfähig genug, um den breiten Einsatz von relationalen Systemen (DBMS plus Anwendungen) zu ermöglichen. Anfang der 1990er Jahre jedoch dominierten relationale Systeme in allen großen Datenverarbeitungsanwendungen, und auch 2018 sind sie noch immer vorherrschend: IBM Db2, Oracle, MySQL und Microsoft SQL Server sind die meistgesuchten DBMS. Die vorherrschende Datenbanksprache, standardisiertes SQL für das relationale Modell, hat die Datenbanksprachen für andere Datenmodelle beeinflusst.

Objektdatenbanken wurden in den 1980er Jahren entwickelt, um die Unannehmlichkeiten der objekt-relationalen Impedanzübereinstimmung zu überwinden, was zur Prägung des Begriffs "post-relational" und zur Entwicklung hybrider objekt-relationaler Datenbanken führte.

Die nächste Generation postrelationaler Datenbanken wurde in den späten 2000er Jahren als NoSQL-Datenbanken bekannt und führte schnelle Key-Value-Stores und dokumentenorientierte Datenbanken ein. Eine konkurrierende "nächste Generation", die als NewSQL-Datenbanken bekannt ist, versuchte neue Implementierungen, die das relationale/SQL-Modell beibehielten und gleichzeitig darauf abzielten, die hohe Leistung von NoSQL im Vergleich zu kommerziell verfügbaren relationalen DBMSs zu erreichen.

1960er Jahre, navigationale DBMS

Grundstruktur des navigationalen CODASYL-Datenbankmodells

Die Einführung des Begriffs Datenbank fiel mit der Verfügbarkeit von Direktzugriffsspeichern (Disketten und Trommeln) ab Mitte der 1960er Jahre zusammen. Der Begriff stellte einen Gegensatz zu den bandgestützten Systemen der Vergangenheit dar und ermöglichte eine gemeinsame interaktive Nutzung anstelle der täglichen Stapelverarbeitung. Das Oxford English Dictionary zitiert einen Bericht der System Development Corporation of California aus dem Jahr 1962 als den ersten, der den Begriff "Datenbank" in einem spezifischen technischen Sinne verwendet.

Mit der zunehmenden Geschwindigkeit und Leistungsfähigkeit von Computern entstand eine Reihe von Allzweck-Datenbanksystemen, von denen Mitte der 1960er Jahre eine Reihe kommerziell genutzt wurde. Das Interesse an einem Standard begann zu wachsen, und Charles Bachman, Autor eines solchen Produkts, des Integrated Data Store (IDS), gründete die Database Task Group innerhalb von CODASYL, der für die Entwicklung und Standardisierung von COBOL zuständigen Gruppe. 1971 legte die Database Task Group ihren Standard vor, der allgemein als CODASYL-Ansatz bekannt wurde, und schon bald kam eine Reihe von kommerziellen Produkten auf den Markt, die auf diesem Ansatz basierten.

Der CODASYL-Ansatz bot Anwendungen die Möglichkeit, in einem verknüpften Datensatz zu navigieren, der zu einem großen Netzwerk geformt war. Anwendungen konnten Datensätze mit einer von drei Methoden finden:

  1. Verwendung eines Primärschlüssels (bekannt als CALC-Schlüssel, typischerweise durch Hashing implementiert)
  2. Navigation durch Beziehungen (sogenannte Sets) von einem Datensatz zum anderen
  3. Durchsuchen aller Datensätze in einer sequentiellen Reihenfolge

Spätere Systeme fügten B-Bäume hinzu, um alternative Zugriffspfade zu ermöglichen. Viele CODASYL-Datenbanken enthielten auch eine deklarative Abfragesprache für Endbenutzer (im Gegensatz zur Navigations-API). CODASYL-Datenbanken waren jedoch komplex und erforderten einen erheblichen Schulungsaufwand, um nützliche Anwendungen zu erstellen.

IBM hatte 1966 auch ein eigenes DBMS, das als Information Management System (IMS) bekannt wurde. IMS war eine Entwicklung von Software, die für das Apollo-Programm auf dem System/360 geschrieben wurde. Das Konzept von IMS ähnelte im Allgemeinen dem von CODASYL, verwendete jedoch eine strenge Hierarchie für sein Modell der Datennavigation anstelle des Netzwerkmodells von CODASYL. Beide Konzepte wurden später aufgrund der Art und Weise, wie auf die Daten zugegriffen wurde, als Navigationsdatenbanken bekannt: Der Begriff wurde durch Bachmans Turing Award-Präsentation The Programmer as Navigator von 1973 populär. IMS wird von IBM als eine hierarchische Datenbank eingestuft. IDMS und die TOTAL-Datenbanken von Cincom Systems werden als Netzwerkdatenbanken eingestuft. IMS ist auch 2014 noch im Einsatz.

1970er Jahre, relationale DBMS

Edgar F. Codd arbeitete bei IBM in San Jose, Kalifornien, in einer der Zweigstellen, die sich hauptsächlich mit der Entwicklung von Festplattensystemen befassten. Er war mit dem Navigationsmodell des CODASYL-Konzepts unzufrieden, insbesondere mit dem Fehlen einer "Suchfunktion". Im Jahr 1970 verfasste er eine Reihe von Papieren, die einen neuen Ansatz für den Aufbau von Datenbanken skizzierten, der schließlich in dem bahnbrechenden A Relational Model of Data for Large Shared Data Banks gipfelte.

In diesem Papier beschrieb er ein neues System für die Speicherung und Arbeit mit großen Datenbanken. Anstatt die Datensätze in einer Art verknüpften Liste von Freiform-Datensätzen wie in CODASYL zu speichern, bestand Codds Idee darin, die Daten in einer Reihe von "Tabellen" zu organisieren, wobei jede Tabelle für eine andere Art von Entität verwendet wurde. Jede Tabelle würde eine feste Anzahl von Spalten mit den Attributen der Entität enthalten. Eine oder mehrere Spalten jeder Tabelle wurden als Primärschlüssel bezeichnet, durch die die Zeilen der Tabelle eindeutig identifiziert werden konnten; bei Querverweisen zwischen Tabellen wurden stets diese Primärschlüssel und nicht die Festplattenadressen verwendet, und bei Abfragen wurden die Tabellen auf der Grundlage dieser Schlüsselbeziehungen verbunden, wobei eine Reihe von Operationen auf der Grundlage des mathematischen Systems der relationalen Kalkulation (von der das Modell seinen Namen hat) verwendet wurde. Durch die Aufteilung der Daten in eine Reihe von normalisierten Tabellen (oder Relationen) sollte sichergestellt werden, dass jeder "Fakt" nur einmal gespeichert wird, was die Aktualisierungsvorgänge vereinfachte. Virtuelle Tabellen, so genannte Views, konnten die Daten auf unterschiedliche Weise für verschiedene Benutzer darstellen, aber Views konnten nicht direkt aktualisiert werden.

Codd verwendete mathematische Begriffe, um das Modell zu definieren: Relationen, Tupel und Domänen anstelle von Tabellen, Zeilen und Spalten. Die heute bekannte Terminologie stammt aus frühen Implementierungen. Später kritisierte Codd die Tendenz, dass praktische Implementierungen von den mathematischen Grundlagen, auf denen das Modell basiert, abweichen.

Im relationalen Modell werden Datensätze mit virtuellen Schlüsseln "verknüpft", die nicht in der Datenbank gespeichert sind, sondern nach Bedarf zwischen den in den Datensätzen enthaltenen Daten definiert werden.

Die Verwendung von Primärschlüsseln (benutzerorientierte Bezeichner) zur Darstellung tabellenübergreifender Beziehungen anstelle von Plattenadressen hatte zwei Hauptgründe. Aus technischer Sicht ermöglichte sie die Verlagerung und Größenänderung von Tabellen ohne teure Reorganisation der Datenbank. Codd interessierte sich jedoch mehr für den Unterschied in der Semantik: Die Verwendung expliziter Bezeichner erleichterte die Definition von Aktualisierungsoperationen mit sauberen mathematischen Definitionen und ermöglichte die Definition von Abfrageoperationen in der etablierten Disziplin der Prädikatenkalkulation erster Ordnung; da diese Operationen saubere mathematische Eigenschaften haben, können Abfragen auf beweisbar korrekte Weise umgeschrieben werden, was die Grundlage für die Abfrageoptimierung bildet. Im Vergleich zu den hierarchischen oder Netzwerkmodellen gibt es keinen Verlust an Ausdruckskraft, obwohl die Verbindungen zwischen den Tabellen nicht mehr so explizit sind.

In den hierarchischen und Netzwerkmodellen durften Datensätze eine komplexe interne Struktur haben. So kann beispielsweise die Gehaltsentwicklung eines Mitarbeiters als "Wiederholungsgruppe" innerhalb des Mitarbeiterdatensatzes dargestellt werden. Im relationalen Modell führte der Prozess der Normalisierung dazu, dass solche internen Strukturen durch Daten in mehreren Tabellen ersetzt wurden, die nur durch logische Schlüssel miteinander verbunden sind.

Ein gängiger Anwendungsfall für ein Datenbanksystem ist zum Beispiel die Erfassung von Informationen über Benutzer, deren Namen, Anmeldeinformationen, verschiedene Adressen und Telefonnummern. Beim navigatorischen Ansatz würden alle diese Daten in einem einzigen Datensatz mit variabler Länge gespeichert werden. Beim relationalen Ansatz würden die Daten in eine Benutzertabelle, eine Adresstabelle und eine Telefonnummern-Tabelle (z. B.) normalisiert werden. In diesen optionalen Tabellen würden nur dann Datensätze erstellt, wenn die Adresse oder Telefonnummern tatsächlich angegeben wurden.

Neben der Identifizierung von Zeilen/Datensätzen anhand logischer Bezeichner anstelle von Festplattenadressen änderte Codd auch die Art und Weise, wie Anwendungen Daten aus mehreren Datensätzen zusammenstellen. Anstatt von den Anwendungen zu verlangen, dass sie die Daten Datensatz für Datensatz durch Navigation in den Verknüpfungen sammeln, sollten sie eine deklarative Abfragesprache verwenden, die ausdrückt, welche Daten benötigt werden, und nicht den Zugriffspfad, über den sie gefunden werden sollten. Die Suche nach einem effizienten Zugriffspfad zu den Daten wurde zur Aufgabe des Datenbankmanagementsystems und nicht des Anwendungsprogrammierers. Dieser Prozess, der als Abfrageoptimierung bezeichnet wurde, beruhte auf der Tatsache, dass Abfragen in Form von mathematischer Logik ausgedrückt wurden.

Codds Arbeit wurde von zwei Personen in Berkeley aufgegriffen, Eugene Wong und Michael Stonebraker. Sie starteten ein Projekt mit dem Namen INGRES, das mit Mitteln finanziert wurde, die bereits für ein geografisches Datenbankprojekt bereitgestellt worden waren, und mit studentischen Programmierern, die den Code entwickelten. Ab 1973 lieferte INGRES seine ersten Testprodukte, die im Allgemeinen 1979 für den breiten Einsatz bereit waren. INGRES ähnelte dem System R in vielerlei Hinsicht, einschließlich der Verwendung einer "Sprache" für den Datenzugriff, bekannt als QUEL. Mit der Zeit wurde INGRES auf den aufkommenden SQL-Standard umgestellt.

IBM selbst führte eine Testimplementierung des relationalen Modells, PRTV, und eine Produktionsimplementierung, Business System 12, durch, die beide inzwischen eingestellt wurden. Honeywell schrieb MRDS für Multics, und jetzt gibt es zwei neue Implementierungen: Alphora Dataphor und Rel. Die meisten anderen DBMS-Implementierungen, die gewöhnlich als relational bezeichnet werden, sind eigentlich SQL-DBMS.

1970 begann die Universität von Michigan mit der Entwicklung des Informationsmanagementsystems MICRO, das auf dem mengentheoretischen Datenmodell von D.L. Childs basierte. MICRO wurde vom US-Arbeitsministerium, der US-Umweltschutzbehörde und von Forschern der University of Alberta, der University of Michigan und der Wayne State University zur Verwaltung sehr großer Datenmengen eingesetzt. Es lief auf IBM-Großrechnern unter Verwendung des Michigan Terminal System. Das System blieb bis 1998 in Betrieb.

Integrierter Ansatz

In den 1970er und 1980er Jahren wurden Versuche unternommen, Datenbanksysteme mit integrierter Hardware und Software zu entwickeln. Die zugrunde liegende Philosophie war, dass eine solche Integration eine höhere Leistung bei geringeren Kosten bieten würde. Beispiele hierfür waren IBM System/38, das frühe Angebot von Teradata und die Datenbankmaschine von Britton Lee, Inc.

Ein weiterer Ansatz zur Hardwareunterstützung für die Datenbankverwaltung war der CAFS-Beschleuniger von ICL, ein Hardware-Plattencontroller mit programmierbaren Suchfunktionen. Langfristig waren diese Bemühungen im Allgemeinen erfolglos, da spezialisierte Datenbankmaschinen nicht mit der rasanten Entwicklung und dem Fortschritt von Allzweckcomputern Schritt halten konnten. Daher sind die meisten Datenbanksysteme heute Softwaresysteme, die auf einer Allzweck-Hardware laufen und einen Allzweck-Computer als Datenspeicher nutzen. Diese Idee wird jedoch von einigen Unternehmen wie Netezza und Oracle (Exadata) für bestimmte Anwendungen weiterverfolgt.

Ende der 1970er Jahre, SQL-DBMS

IBM begann in den frühen 1970er Jahren mit der Arbeit an einem Prototypsystem, das als System R lose auf Codds Konzepten basierte. Die erste Version war 1974/5 fertig, und dann wurde mit der Arbeit an Mehrtabellensystemen begonnen, in denen die Daten aufgeteilt werden konnten, so dass nicht alle Daten für einen Datensatz (von denen einige optional sind) in einem einzigen großen "Brocken" gespeichert werden mussten. Spätere Mehrbenutzerversionen wurden 1978 und 1979 von Kunden getestet, und zu diesem Zeitpunkt wurde eine standardisierte Abfragesprache - SQL - hinzugefügt. Codds Ideen erwiesen sich als praktikabel und CODASYL überlegen, was IBM dazu veranlasste, eine echte Produktionsversion von System R zu entwickeln, die als SQL/DS und später als Database 2 (IBM Db2) bekannt wurde.

Die Oracle-Datenbank von Larry Ellison (oder einfacher: Oracle) entstand auf der Grundlage der IBM-Papiere über System R. Obwohl die Implementierungen von Oracle V1 bereits 1978 abgeschlossen waren, kam Ellison erst 1979 mit Oracle Version 2 vor IBM auf den Markt.

Stonebraker wandte die Erkenntnisse aus INGRES an, um eine neue Datenbank, Postgres, zu entwickeln, die heute als PostgreSQL bekannt ist. PostgreSQL wird häufig für globale, unternehmenskritische Anwendungen verwendet (die Registrierungsstellen für .org- und .info-Domänennamen nutzen es als primären Datenspeicher, ebenso wie viele große Unternehmen und Finanzinstitute).

In Schweden wurde Codds Aufsatz ebenfalls gelesen und Mimer SQL wurde Mitte der 1970er Jahre an der Universität Uppsala entwickelt. Im Jahr 1984 wurde dieses Projekt in ein unabhängiges Unternehmen umgewandelt.

Ein anderes Datenmodell, das Entity-Relationship-Modell, tauchte 1976 auf und gewann an Popularität für das Datenbankdesign, da es eine vertrautere Beschreibung als das frühere relationale Modell betonte. Später wurden Entity-Relationship-Konstrukte als Datenmodellierungskonstrukt für das relationale Modell nachgerüstet, und der Unterschied zwischen den beiden Modellen ist inzwischen irrelevant.

1980er Jahre, auf dem Desktop

Die 1980er Jahre läuteten das Zeitalter der Desktop-Computer ein. Die neuen Computer ermöglichten ihren Benutzern Tabellenkalkulationen wie Lotus 1-2-3 und Datenbanksoftware wie dBASE. Das dBASE-Produkt war leicht und für jeden Computerbenutzer sofort verständlich. C. Wayne Ratliff, der Schöpfer von dBASE, erklärte: "dBASE unterscheidet sich von Programmen wie BASIC, C, FORTRAN und COBOL dadurch, dass ein Großteil der schmutzigen Arbeit bereits erledigt ist. Die Datenmanipulation wird von dBASE und nicht vom Benutzer durchgeführt, so dass sich der Benutzer auf seine Arbeit konzentrieren kann und sich nicht mit den schmutzigen Details des Öffnens, Lesens und Schließens von Dateien und der Verwaltung der Speicherplatzzuweisung herumschlagen muss." dBASE war in den 80er und frühen 90er Jahren einer der meistverkauften Softwaretitel.

1990er Jahre, objektorientiert

In den 1990er Jahren wurde mit dem Aufkommen der objektorientierten Programmierung die Art und Weise, wie Daten in verschiedenen Datenbanken gehandhabt wurden, erweitert. Programmierer und Designer begannen, die Daten in ihren Datenbanken als Objekte zu behandeln. Das heißt, wenn sich die Daten einer Person in einer Datenbank befanden, wurden die Attribute dieser Person, wie z. B. ihre Adresse, Telefonnummer und ihr Alter, nun als zu dieser Person gehörig betrachtet und nicht mehr als fremde Daten. Dies ermöglicht es, Beziehungen zwischen Daten auf Objekte und ihre Attribute und nicht auf einzelne Felder zu beziehen. Der Begriff "object-relational impedance mismatch" beschreibt die Unannehmlichkeiten bei der Übersetzung zwischen programmierten Objekten und Datenbanktabellen. Objektdatenbanken und objektrelationale Datenbanken versuchen, dieses Problem zu lösen, indem sie eine objektorientierte Sprache (manchmal als Erweiterung von SQL) anbieten, die Programmierer als Alternative zu rein relationalem SQL verwenden können. Auf der Programmierseite versuchen Bibliotheken, die als objekt-relationale Mappings (ORMs) bekannt sind, das gleiche Problem zu lösen.

2000er Jahre, NoSQL und NewSQL

XML-Datenbanken sind eine Art von strukturierten, dokumentenorientierten Datenbanken, die Abfragen auf der Grundlage von XML-Dokumentenattributen ermöglichen. XML-Datenbanken werden meist in Anwendungen eingesetzt, bei denen die Daten als eine Sammlung von Dokumenten mit einer Struktur betrachtet werden, die von sehr flexibel bis sehr starr reichen kann: Beispiele sind wissenschaftliche Artikel, Patente, Steuererklärungen und Personalakten.

NoSQL-Datenbanken sind oft sehr schnell, benötigen keine festen Tabellenschemata, vermeiden Verknüpfungsoperationen durch Speicherung denormalisierter Daten und sind für eine horizontale Skalierung ausgelegt.

In den letzten Jahren gab es eine starke Nachfrage nach massiv verteilten Datenbanken mit hoher Partitionstoleranz, aber gemäß dem CAP-Theorem ist es für ein verteiltes System unmöglich, gleichzeitig Konsistenz-, Verfügbarkeits- und Partitionstoleranzgarantien zu bieten. Ein verteiltes System kann zwar zwei dieser Garantien gleichzeitig erfüllen, aber nicht alle drei. Aus diesem Grund verwenden viele NoSQL-Datenbanken die so genannte eventuelle Konsistenz, um sowohl Verfügbarkeits- als auch Partitionstoleranzgarantien mit einem reduzierten Maß an Datenkonsistenz zu bieten.

NewSQL ist eine Klasse moderner relationaler Datenbanken, die darauf abzielt, die gleiche skalierbare Leistung von NoSQL-Systemen für die Online-Transaktionsverarbeitung (Lese- und Schreibvorgänge) zu bieten, während gleichzeitig SQL verwendet wird und die ACID-Garantien eines herkömmlichen Datenbanksystems beibehalten werden.

Anwendungsfälle

Datenbanken werden zur Unterstützung interner Abläufe in Unternehmen und zur Unterstützung von Online-Interaktionen mit Kunden und Lieferanten verwendet (siehe Unternehmenssoftware).

Datenbanken werden zur Speicherung von Verwaltungsinformationen und spezielleren Daten wie technischen Daten oder Wirtschaftsmodellen verwendet. Beispiele hierfür sind computergestützte Bibliothekssysteme, Flugreservierungssysteme, computergestützte Ersatzteillagersysteme und viele Content-Management-Systeme, die Websites als Sammlungen von Webseiten in einer Datenbank speichern.

Klassifizierung

Eine Möglichkeit, Datenbanken zu klassifizieren, ist die Art ihres Inhalts, z. B. bibliografische, Dokument-Text-, statistische oder Multimedia-Objekte. Eine andere Möglichkeit ist ihr Anwendungsbereich, zum Beispiel: Buchhaltung, Musikkompositionen, Filme, Bankwesen, Produktion oder Versicherungen. Ein dritter Weg ist die Unterscheidung nach technischen Aspekten, wie z. B. der Datenbankstruktur oder dem Schnittstellentyp. In diesem Abschnitt werden einige der Adjektive aufgeführt, die zur Charakterisierung der verschiedenen Arten von Datenbanken verwendet werden.

  • Eine In-Memory-Datenbank ist eine Datenbank, die sich hauptsächlich im Hauptspeicher befindet, aber in der Regel durch einen nichtflüchtigen Computerdatenspeicher gesichert wird. Hauptspeicherdatenbanken sind schneller als Festplattendatenbanken und werden daher häufig dort eingesetzt, wo die Reaktionszeit von entscheidender Bedeutung ist, wie z. B. in Telekommunikationsnetzgeräten.
  • Eine aktive Datenbank enthält eine ereignisgesteuerte Architektur, die auf Bedingungen innerhalb und außerhalb der Datenbank reagieren kann. Mögliche Einsatzgebiete sind Sicherheitsüberwachung, Alarmierung, statistische Erfassung und Autorisierung. Viele Datenbanken bieten aktive Datenbankfunktionen in Form von Datenbank-Triggern.
  • Eine Cloud-Datenbank stützt sich auf die Cloud-Technologie. Sowohl die Datenbank als auch die meisten ihrer DBMS befinden sich "in der Wolke", während die Anwendungen von Programmierern entwickelt und später von den Endnutzern über einen Webbrowser und offene APIs gepflegt und verwendet werden.
  • Data Warehouses archivieren Daten aus operativen Datenbanken und oft auch aus externen Quellen wie Marktforschungsunternehmen. Das Warehouse wird zur zentralen Datenquelle, die von Managern und anderen Endnutzern verwendet werden kann, die möglicherweise keinen Zugang zu den Betriebsdaten haben. Beispielsweise können Verkaufsdaten zu wöchentlichen Gesamtwerten aggregiert und von internen Produktcodes in UPCs umgewandelt werden, damit sie mit ACNielsen-Daten verglichen werden können. Zu den grundlegenden und unverzichtbaren Komponenten des Data Warehousing gehören die Extraktion, die Analyse und das Mining von Daten, die Umwandlung, das Laden und die Verwaltung von Daten, um sie für die weitere Verwendung verfügbar zu machen.
  • Eine deduktive Datenbank kombiniert logische Programmierung mit einer relationalen Datenbank.
  • Eine verteilte Datenbank ist eine Datenbank, bei der sich sowohl die Daten als auch das DBMS über mehrere Computer erstrecken.
  • Eine dokumentenorientierte Datenbank ist für die Speicherung, den Abruf und die Verwaltung dokumentenorientierter oder halbstrukturierter Informationen konzipiert. Dokumentorientierte Datenbanken sind eine der Hauptkategorien von NoSQL-Datenbanken.
  • Ein eingebettetes Datenbanksystem ist ein DBMS, das eng in eine Anwendungssoftware integriert ist, die den Zugriff auf gespeicherte Daten erfordert, und zwar so, dass das DBMS vor den Endbenutzern der Anwendung verborgen ist und wenig oder gar keine laufende Wartung erfordert.
  • Endbenutzer-Datenbanken bestehen aus Daten, die von einzelnen Endbenutzern entwickelt wurden. Beispiele hierfür sind Sammlungen von Dokumenten, Tabellenkalkulationen, Präsentationen, Multimedia- und anderen Dateien. Es gibt mehrere Produkte zur Unterstützung solcher Datenbanken. Einige von ihnen sind viel einfacher als vollwertige DBMS und verfügen über elementare DBMS-Funktionen.
  • Ein föderiertes Datenbanksystem umfasst mehrere verschiedene Datenbanken, jede mit ihrem eigenen DBMS. Es wird von einem föderierten Datenbankmanagementsystem (FDBMS) wie eine einzige Datenbank behandelt, das mehrere autonome DBMS, möglicherweise unterschiedlicher Art (in diesem Fall wäre es auch ein heterogenes Datenbanksystem), transparent integriert und ihnen eine integrierte konzeptionelle Sicht bietet.
  • Manchmal wird der Begriff Multi-Datenbank als Synonym für föderierte Datenbank verwendet, obwohl er sich auch auf eine weniger integrierte (z. B. ohne FDBMS und ein verwaltetes integriertes Schema) Gruppe von Datenbanken beziehen kann, die in einer einzigen Anwendung zusammenarbeiten. In diesem Fall wird in der Regel Middleware für die Verteilung verwendet, die in der Regel ein atomares Festschreibungsprotokoll (ACP), z. B. das Zwei-Phasen-Festschreibungsprotokoll, umfasst, um verteilte (globale) Transaktionen über die teilnehmenden Datenbanken hinweg zu ermöglichen.
  • Eine Graphdatenbank ist eine Art von NoSQL-Datenbank, die Graphstrukturen mit Knoten, Kanten und Eigenschaften zur Darstellung und Speicherung von Informationen verwendet. Allgemeine Graphdatenbanken, die jeden Graphen speichern können, unterscheiden sich von spezialisierten Graphdatenbanken wie Triplestores und Netzwerkdatenbanken.
  • Ein Array-DBMS ist eine Art von NoSQL-DBMS, das die Modellierung, Speicherung und Abfrage von (in der Regel großen) mehrdimensionalen Arrays wie Satellitenbildern und Klimasimulationsergebnissen ermöglicht.
  • In einer Hypertext- oder Hypermedia-Datenbank kann ein beliebiges Wort oder ein Textstück, das ein Objekt darstellt, z. B. ein anderes Textstück, ein Artikel, ein Bild oder ein Film, mit diesem Objekt verlinkt werden. Hypertext-Datenbanken sind besonders nützlich, wenn es darum geht, große Mengen an unterschiedlichen Informationen zu organisieren. Sie eignen sich z. B. für die Organisation von Online-Enzyklopädien, in denen die Benutzer bequem im Text herumspringen können. Das World Wide Web ist also eine große verteilte Hypertext-Datenbank.
  • Eine Wissensdatenbank (abgekürzt KB, kb oder Δ) ist eine spezielle Art von Datenbank für das Wissensmanagement, die die Mittel für die computergestützte Sammlung, Organisation und Abfrage von Wissen bereitstellt. Es handelt sich auch um eine Sammlung von Daten, die Probleme mit ihren Lösungen und damit verbundenen Erfahrungen darstellen.
  • Eine mobile Datenbank kann auf einem mobilen Computergerät mitgeführt oder von diesem synchronisiert werden.
  • Operative Datenbanken speichern detaillierte Daten über die Abläufe in einem Unternehmen. Sie verarbeiten in der Regel relativ große Mengen an Aktualisierungen durch Transaktionen. Beispiele hierfür sind Kundendatenbanken, die Kontakt-, Kredit- und demografische Informationen über die Kunden eines Unternehmens aufzeichnen, Personaldatenbanken, die Informationen wie Gehalt, Sozialleistungen und Qualifikationsdaten über die Mitarbeiter enthalten, Warenwirtschaftssysteme, die Details über Produktkomponenten und den Teilebestand aufzeichnen, sowie Finanzdatenbanken, die die Geld-, Buchhaltungs- und Finanzgeschäfte des Unternehmens verfolgen.
  • Eine parallele Datenbank zielt darauf ab, die Leistung durch Parallelisierung von Aufgaben wie dem Laden von Daten, dem Aufbau von Indizes und der Auswertung von Abfragen zu verbessern.
Die wichtigsten parallelen DBMS-Architekturen, die durch die zugrunde liegende Hardware-Architektur bedingt sind, sind:
  • Shared-Memory-Architektur, bei der sich mehrere Prozessoren den Hauptspeicher sowie andere Datenspeicher teilen.
  • Shared-Disk-Architektur, bei der jede Verarbeitungseinheit (in der Regel bestehend aus mehreren Prozessoren) über einen eigenen Hauptspeicher verfügt, aber alle Einheiten den übrigen Speicher gemeinsam nutzen.
  • Shared-Nothing-Architektur, bei der jede Verarbeitungseinheit über einen eigenen Hauptspeicher und andere Speicherplätze verfügt.
  • Probabilistische Datenbanken verwenden Fuzzy-Logik, um aus unpräzisen Daten Rückschlüsse zu ziehen.
  • Echtzeit-Datenbanken verarbeiten Transaktionen so schnell, dass das Ergebnis sofort zurückkommt und bearbeitet werden kann.
  • Eine räumliche Datenbank kann Daten mit mehrdimensionalen Merkmalen speichern. Zu den Abfragen solcher Daten gehören ortsbezogene Abfragen wie "Wo ist das nächstgelegene Hotel in meiner Gegend?".
  • Eine zeitliche Datenbank verfügt über eingebaute zeitliche Aspekte, z. B. ein zeitliches Datenmodell und eine zeitliche Version von SQL. Genauer gesagt umfassen die zeitlichen Aspekte in der Regel die Gültigkeitsdauer und die Transaktionsdauer.
  • Eine terminologieorientierte Datenbank baut auf einer objektorientierten Datenbank auf, die oft für einen bestimmten Bereich angepasst ist.
  • Eine Datenbank für unstrukturierte Daten ist für die überschaubare und geschützte Speicherung verschiedener Objekte gedacht, die nicht auf natürliche und bequeme Weise in herkömmliche Datenbanken passen. Dazu können E-Mail-Nachrichten, Dokumente, Journale, Multimedia-Objekte usw. gehören. Der Name kann irreführend sein, da einige Objekte stark strukturiert sein können. Die gesamte mögliche Objektsammlung passt jedoch nicht in einen vordefinierten strukturierten Rahmen. Die meisten etablierten DBMS unterstützen inzwischen unstrukturierte Daten auf verschiedene Weise, und es entstehen neue spezielle DBMS.

Datenbank-Management-System

Connolly und Begg definieren ein Datenbankmanagementsystem (DBMS) als ein "Softwaresystem, das es den Benutzern ermöglicht, den Zugriff auf die Datenbank zu definieren, zu erstellen, zu pflegen und zu kontrollieren". Beispiele für DBMS sind MySQL, PostgreSQL, Microsoft SQL Server, Oracle Database und Microsoft Access.

Das DBMS-Akronym wird manchmal erweitert, um das zugrunde liegende Datenbankmodell anzugeben, wobei RDBMS für das relationale, OODBMS für das objektorientierte und ORDBMS für das objektrelationale Modell steht. Andere Erweiterungen können auf andere Merkmale hinweisen, wie z. B. DDBMS für ein verteiltes Datenbankmanagementsystem.

Die von einem DBMS bereitgestellten Funktionen können sehr unterschiedlich sein. Die Kernfunktionalität ist das Speichern, Abrufen und Aktualisieren von Daten. Codd schlug die folgenden Funktionen und Dienste vor, die ein vollwertiges Allzweck-DBMS bieten sollte:

  • Speicherung, Abruf und Aktualisierung von Daten
  • Benutzerzugänglicher Katalog oder Datenwörterbuch zur Beschreibung der Metadaten
  • Unterstützung von Transaktionen und Gleichzeitigkeit
  • Möglichkeiten zur Wiederherstellung der Datenbank, falls sie beschädigt wird
  • Unterstützung für die Autorisierung des Zugriffs und der Aktualisierung von Daten
  • Unterstützung des Zugriffs von entfernten Standorten aus
  • Durchsetzung von Beschränkungen, um sicherzustellen, dass die Daten in der Datenbank bestimmten Regeln entsprechen

Im Allgemeinen ist auch zu erwarten, dass das DBMS eine Reihe von Dienstprogrammen für die Zwecke bereitstellt, die zur effektiven Verwaltung der Datenbank erforderlich sind, einschließlich Import-, Export-, Überwachungs-, Defragmentierungs- und Analyse-Dienstprogrammen. Der Kernteil des DBMS, der zwischen der Datenbank und der Anwendungsschnittstelle interagiert, wird manchmal als Datenbank-Engine bezeichnet.

Häufig verfügen DBMS über Konfigurationsparameter, die statisch und dynamisch eingestellt werden können, z. B. die maximale Größe des Hauptspeichers auf einem Server, den die Datenbank nutzen kann. Der Trend geht dahin, den Umfang der manuellen Konfiguration zu minimieren, und für Fälle wie eingebettete Datenbanken ist die Notwendigkeit, eine Null-Verwaltung anzustreben, von größter Bedeutung.

Die großen Unternehmens-DBMS werden immer größer und leistungsfähiger und können während ihrer gesamten Lebensdauer Tausende von Arbeitsjahren in die Entwicklung investiert haben.

Frühe Mehrbenutzer-DBMS erlaubten in der Regel nur, dass sich die Anwendung auf demselben Computer befand und der Zugriff über Terminals oder Terminalemulationssoftware erfolgte. Die Client-Server-Architektur war eine Entwicklung, bei der sich die Anwendung auf einem Client-Desktop und die Datenbank auf einem Server befand, so dass die Verarbeitung verteilt werden konnte. Daraus entwickelte sich eine mehrschichtige Architektur mit Anwendungsservern und Webservern, wobei die Endbenutzerschnittstelle über einen Webbrowser erfolgt und die Datenbank nur direkt mit der angrenzenden Schicht verbunden ist.

Ein Allzweck-DBMS bietet öffentliche Anwendungsprogrammierschnittstellen (API) und optional einen Prozessor für Datenbanksprachen wie SQL, damit Anwendungen geschrieben werden können, die mit der Datenbank interagieren und sie manipulieren. Ein spezielles DBMS kann eine private API verwenden und speziell an eine einzelne Anwendung angepasst und mit dieser verknüpft werden. Ein E-Mail-System führt beispielsweise viele der Funktionen eines Allzweck-DBMS aus, wie das Einfügen und Löschen von Nachrichten, die Bearbeitung von Anhängen, das Nachschlagen in Blocklisten, das Zuordnen von Nachrichten zu einer E-Mail-Adresse usw. Diese Funktionen sind jedoch auf das beschränkt, was für die Bearbeitung von E-Mails erforderlich ist.

Anwendung

Die externe Interaktion mit der Datenbank erfolgt über ein Anwendungsprogramm, das über eine Schnittstelle mit dem DBMS verbunden ist. Dies kann von einem Datenbanktool, mit dem Benutzer SQL-Abfragen textuell oder grafisch ausführen können, bis hin zu einer Website reichen, die eine Datenbank zur Speicherung und Suche von Informationen verwendet.

Anwendungsprogramm-Schnittstelle

Ein Programmierer kodiert Interaktionen mit der Datenbank (manchmal auch als Datenquelle bezeichnet) über eine Anwendungsprogrammschnittstelle (API) oder über eine Datenbanksprache. Die gewählte API oder Sprache muss vom DBMS unterstützt werden, möglicherweise indirekt über einen Präprozessor oder eine Überbrückungs-API. Einige APIs zielen darauf ab, datenbankunabhängig zu sein; ODBC ist ein allgemein bekanntes Beispiel. Andere gängige APIs sind JDBC und ADO.NET.

Datenbanksprachen

Bei Datenbanksprachen handelt es sich um spezielle Sprachen, die eine oder mehrere der folgenden Aufgaben ermöglichen, die manchmal als Untersprachen unterschieden werden:

  • Datenkontrollsprache (DCL) - steuert den Zugriff auf Daten;
  • Datendefinitionssprache (DDL) - definiert Datentypen, wie z. B. das Erstellen, Ändern oder Löschen von Tabellen und die Beziehungen zwischen ihnen;
  • Datenmanipulationssprache (DML) - führt Aufgaben wie Einfügen, Aktualisieren oder Löschen von Datenvorkommen aus;
  • Datenabfragesprache (DQL) - ermöglicht die Suche nach Informationen und die Berechnung von abgeleiteten Informationen.

Datenbanksprachen sind spezifisch für ein bestimmtes Datenmodell. Bemerkenswerte Beispiele sind:

  • SQL vereint die Funktionen der Datendefinition, der Datenmanipulation und der Abfrage in einer einzigen Sprache. Es war eine der ersten kommerziellen Sprachen für das relationale Modell, obwohl es in einigen Punkten vom relationalen Modell, wie es von Codd beschrieben wurde, abweicht (zum Beispiel können die Zeilen und Spalten einer Tabelle geordnet werden). SQL wurde 1986 ein Standard des American National Standards Institute (ANSI) und 1987 der International Organization for Standardization (ISO). Die Standards wurden seitdem regelmäßig weiterentwickelt und werden (in unterschiedlichem Maße) von allen gängigen kommerziellen relationalen DBMS unterstützt.
  • OQL ist ein Standard für Objektmodellsprachen (von der Object Data Management Group). Er hat das Design einiger neuerer Abfragesprachen wie JDOQL und EJB QL beeinflusst.
  • XQuery ist eine Standard-XML-Abfragesprache, die von XML-Datenbanksystemen wie MarkLogic und eXist, von relationalen Datenbanken mit XML-Funktionen wie Oracle und Db2 und auch von In-Memory-XML-Prozessoren wie Saxon implementiert wird.
  • SQL/XML kombiniert XQuery mit SQL.

Eine Datenbanksprache kann auch Funktionen enthalten wie:

  • DBMS-spezifische Konfiguration und Speicher-Engine-Management
  • Berechnungen zur Veränderung von Abfrageergebnissen, wie Zählen, Summieren, Mittelwertbildung, Sortieren, Gruppieren und Querverweise
  • Durchsetzung von Beschränkungen (z. B. in einer Kfz-Datenbank, die nur einen Motortyp pro Fahrzeug zulässt)
  • Version der Abfragesprache als Anwendungsprogrammierschnittstelle zur Vereinfachung für den Programmierer

Eine Datenbank stellt als Schnittstelle eine Datenbanksprache für die folgenden Zwecke zur Verfügung:

  • Datenabfrage und -manipulation (DML)
  • Verwaltung der Datenbank und Definition der Datenstrukturen (DDL)
  • Berechtigungssteuerung (DCL)

Bei den relationalen DBMS sind diese Kategorien in einer Sprache (SQL) vereint, bei anderen Systemen existiert aber durchaus eine Trennung in Form unterschiedlicher Sprachen.

Speicherung

Der Datenbankspeicher ist der Container für die physische Materialisierung einer Datenbank. Er umfasst die interne (physische) Ebene der Datenbankarchitektur. Er enthält auch alle Informationen (z. B. Metadaten, "Daten über die Daten" und interne Datenstrukturen), die benötigt werden, um bei Bedarf die konzeptionelle Ebene und die externe Ebene aus der internen Ebene zu rekonstruieren. Datenbanken als digitale Objekte enthalten drei Schichten von Informationen, die gespeichert werden müssen: die Daten, die Struktur und die Semantik. Die ordnungsgemäße Speicherung aller drei Schichten ist für die zukünftige Bewahrung und Langlebigkeit der Datenbank erforderlich. Für die dauerhafte Speicherung der Daten ist im Allgemeinen die Datenbank-Engine, auch "Storage Engine" genannt, zuständig. Obwohl der Zugriff auf ein DBMS in der Regel über das zugrundeliegende Betriebssystem erfolgt (und oft die Dateisysteme des Betriebssystems als Vermittler für das Speicherlayout verwendet werden), sind die Speichereigenschaften und Konfigurationseinstellungen für den effizienten Betrieb des DBMS äußerst wichtig und werden daher von den Datenbankadministratoren sorgfältig gepflegt. Während des Betriebs eines DBMS befindet sich die Datenbank immer in mehreren Speicherarten (z. B. im Arbeitsspeicher und in externen Speichern). Die Datenbankdaten und die zusätzlich benötigten Informationen, möglicherweise in sehr großen Mengen, sind in Bits kodiert. Die Daten befinden sich im Speicher typischerweise in Strukturen, die völlig anders aussehen als die Daten auf der konzeptionellen und externen Ebene, aber in einer Weise, die versucht, die Rekonstruktion dieser Ebenen zu optimieren (so gut wie möglich), wenn sie von Benutzern und Programmen benötigt wird, sowie für die Berechnung zusätzlicher Arten von benötigten Informationen aus den Daten (z. B. bei der Abfrage der Datenbank).

Einige DBMS unterstützen die Angabe, welche Zeichenkodierung für die Speicherung von Daten verwendet wurde, so dass mehrere Kodierungen in derselben Datenbank verwendet werden können.

Verschiedene Low-Level-Datenbank-Speicherstrukturen werden von der Speichermaschine verwendet, um das Datenmodell zu serialisieren, damit es auf das gewünschte Medium geschrieben werden kann. Techniken wie die Indizierung können zur Verbesserung der Leistung eingesetzt werden. Die herkömmliche Speicherung ist zeilenorientiert, aber es gibt auch spaltenorientierte und Korrelationsdatenbanken.

Materialisierte Ansichten

Um die Leistung zu steigern, wird häufig Speicherredundanz eingesetzt. Ein gängiges Beispiel ist die Speicherung von materialisierten Ansichten, die aus häufig benötigten externen Ansichten oder Abfrageergebnissen bestehen. Die Speicherung solcher Ansichten erspart die kostspielige Berechnung bei jeder Abfrage. Die Nachteile von materialisierten Ansichten sind der Overhead, der entsteht, wenn sie aktualisiert werden, um sie mit den ursprünglichen aktualisierten Datenbankdaten synchron zu halten, und die Kosten für die Speicherredundanz.

Replikation

Gelegentlich verwendet eine Datenbank Speicherredundanz durch Replikation von Datenbankobjekten (mit einer oder mehreren Kopien), um die Datenverfügbarkeit zu erhöhen (sowohl zur Verbesserung der Leistung bei gleichzeitigen Zugriffen mehrerer Endbenutzer auf dasselbe Datenbankobjekt als auch zur Gewährleistung der Ausfallsicherheit im Falle eines Teilausfalls einer verteilten Datenbank). Aktualisierungen eines replizierten Objekts müssen über die Objektkopien hinweg synchronisiert werden. In vielen Fällen wird die gesamte Datenbank repliziert.

Sicherheit

Die Datenbanksicherheit befasst sich mit den verschiedenen Aspekten des Schutzes des Datenbankinhalts, seiner Eigentümer und seiner Benutzer. Sie reicht vom Schutz vor absichtlichen unbefugten Datenbanknutzungen bis hin zu unbeabsichtigten Datenbankzugriffen durch unbefugte Entitäten (z. B. eine Person oder ein Computerprogramm).

Bei der Datenbankzugriffskontrolle geht es darum, zu kontrollieren, wer (eine Person oder ein bestimmtes Computerprogramm) auf welche Informationen in der Datenbank zugreifen darf. Die Informationen können bestimmte Datenbankobjekte (z. B. Datensatztypen, bestimmte Datensätze, Datenstrukturen), bestimmte Berechnungen über bestimmte Objekte (z. B. Abfragetypen oder bestimmte Abfragen) oder die Verwendung bestimmter Zugriffspfade zu ersteren (z. B. die Verwendung bestimmter Indizes oder anderer Datenstrukturen zum Zugriff auf Informationen) umfassen. Datenbankzugriffskontrollen werden von speziell autorisiertem Personal (vom Eigentümer der Datenbank) festgelegt, das spezielle geschützte Sicherheits-DBMS-Schnittstellen verwendet.

Dies kann direkt auf individueller Basis oder durch die Zuweisung von Einzelpersonen und Privilegien zu Gruppen oder (in den ausgefeiltesten Modellen) durch die Zuweisung von Einzelpersonen und Gruppen zu Rollen erfolgen, denen dann Berechtigungen zugewiesen werden. Die Datensicherheit verhindert, dass unbefugte Benutzer die Datenbank einsehen oder aktualisieren können. Mit Hilfe von Passwörtern wird den Benutzern der Zugriff auf die gesamte Datenbank oder auf Teilmengen davon, die so genannten "Subschemata", gewährt. Eine Mitarbeiterdatenbank kann zum Beispiel alle Daten eines einzelnen Mitarbeiters enthalten, aber eine Gruppe von Benutzern kann berechtigt sein, nur die Gehaltsabrechnung einzusehen, während andere nur Zugriff auf die Arbeitsgeschichte und medizinische Daten haben. Wenn das DBMS die Möglichkeit bietet, die Datenbank interaktiv einzugeben und zu aktualisieren sowie sie abzufragen, ermöglicht diese Fähigkeit die Verwaltung persönlicher Datenbanken.

Bei der Datensicherheit geht es im Allgemeinen um den Schutz bestimmter Datenpakete, sowohl physisch (d. h. vor Beschädigung, Zerstörung oder Entfernung; siehe z. B. physische Sicherheit) als auch bei der Interpretation dieser Daten oder von Teilen davon in aussagekräftige Informationen (z. B. durch Betrachtung der Bitfolgen, aus denen sie bestehen, um bestimmte gültige Kreditkartennummern zu ermitteln; siehe z. B. Datenverschlüsselung).

Die Änderungs- und Zugriffsprotokollierung zeichnet auf, wer auf welche Attribute zugegriffen hat, was geändert wurde und wann es geändert wurde. Protokollierungsdienste ermöglichen später ein forensisches Datenbank-Audit, indem sie Zugriffsereignisse und Änderungen aufzeichnen. Manchmal wird Code auf Anwendungsebene verwendet, um Änderungen aufzuzeichnen, anstatt diese in der Datenbank zu belassen. Die Überwachung kann so eingerichtet werden, dass Sicherheitsverstöße aufgedeckt werden. Daher müssen Unternehmen die Datenbanksicherheit aufgrund der vielen Vorteile, die sie bietet, ernst nehmen. Organisationen werden vor Sicherheitsverletzungen und Hackerangriffen wie Firewall-Eingriffen, Virenverbreitung und Ransomware geschützt. Dies trägt zum Schutz der wichtigsten Unternehmensdaten bei, die auf keinen Fall an Außenstehende weitergegeben werden dürfen.

Das RDBMS speichert die relationalen Daten auf einem Speichermedium. Neben den eigentlichen Daten werden ebenfalls Informationen über die Datenbankschemata und Zugriffsrechte von Benutzern gespeichert. Letztere sind wichtig, um die Datensicherheit zu garantieren. Dazu gehört sowohl Schutz gegen Datenverlust als auch Schutz gegen unerlaubten Zugriff. Die Metadaten eines DBMS werden auch als das data dictionary oder Katalog des Systems bezeichnet.

Ein weiterer wichtiger Aspekt von Datenbanken ist das Sichern des Datenbestandes durch Backups. In der Praxis ist dies oft ein nicht zu vernachlässigendes Performance-Problem, da während eines Backups Daten nur sehr eingeschränkt modifiziert werden dürfen.

Transaktionen und Gleichzeitigkeit

Datenbanktransaktionen können verwendet werden, um ein gewisses Maß an Fehlertoleranz und Datenintegrität nach der Wiederherstellung nach einem Absturz zu erreichen. Eine Datenbanktransaktion ist eine Arbeitseinheit, die in der Regel eine Reihe von Operationen in einer Datenbank kapselt (z. B. Lesen eines Datenbankobjekts, Schreiben, Erfassen oder Freigeben einer Sperre usw.), eine Abstraktion, die in Datenbanken und auch anderen Systemen unterstützt wird. Jede Transaktion hat genau definierte Grenzen in Bezug darauf, welche Programm-/Codeausführungen in dieser Transaktion enthalten sind (vom Programmierer der Transaktion über spezielle Transaktionsbefehle festgelegt).

Das Akronym ACID beschreibt einige ideale Eigenschaften einer Datenbanktransaktion: Atomarität, Konsistenz, Isolation und Dauerhaftigkeit.

Migration

Eine Datenbank, die mit einem DBMS erstellt wurde, ist nicht auf ein anderes DBMS übertragbar (d.h. das andere DBMS kann sie nicht ausführen). In manchen Situationen ist es jedoch wünschenswert, eine Datenbank von einem DBMS zu einem anderen zu migrieren. Die Gründe dafür sind in erster Linie wirtschaftlicher Art (verschiedene DBMS können unterschiedliche Gesamtbetriebskosten (TCO) haben), funktioneller und betrieblicher Art (verschiedene DBMS können unterschiedliche Fähigkeiten haben). Die Migration umfasst die Umwandlung der Datenbank von einem DBMS-Typ in einen anderen. Die Transformation sollte (wenn möglich) die datenbankbezogene Anwendung (d.h. alle zugehörigen Anwendungsprogramme) intakt halten. Daher sollten die konzeptionelle und die externe Architekturebene der Datenbank bei der Transformation beibehalten werden. Es kann erwünscht sein, dass auch einige Aspekte der internen Architekturebene beibehalten werden. Eine komplexe oder große Datenbankmigration kann ein kompliziertes und kostspieliges (einmaliges) Projekt sein, was bei der Entscheidung für eine Migration berücksichtigt werden sollte. Dies gilt trotz der Tatsache, dass es Tools gibt, die bei der Migration zwischen bestimmten DBMS helfen können. In der Regel stellt ein DBMS-Anbieter Tools zur Verfügung, die beim Import von Datenbanken aus anderen gängigen DBMS helfen.

Aufbau, Wartung und Tuning

Nach dem Entwurf einer Datenbank für eine Anwendung ist der nächste Schritt die Erstellung der Datenbank. In der Regel kann ein geeignetes Allzweck-DBMS für diesen Zweck ausgewählt werden. Ein DBMS stellt die erforderlichen Benutzerschnittstellen zur Verfügung, die von Datenbankadministratoren verwendet werden, um die Datenstrukturen der benötigten Anwendung innerhalb des jeweiligen Datenmodells des DBMS zu definieren. Andere Benutzerschnittstellen dienen zur Auswahl der benötigten DBMS-Parameter (z. B. sicherheitsrelevante Parameter, Parameter für die Speicherzuweisung usw.).

Wenn die Datenbank fertig ist (alle Datenstrukturen und andere benötigte Komponenten sind definiert), wird sie in der Regel mit den anfänglichen Anwendungsdaten gefüllt (Datenbankinitialisierung, die in der Regel ein eigenes Projekt ist; in vielen Fällen unter Verwendung spezieller DBMS-Schnittstellen, die Masseneinfügung unterstützen), bevor sie in Betrieb genommen wird. In einigen Fällen wird die Datenbank in Betrieb genommen, obwohl sie keine Anwendungsdaten enthält, und die Daten werden während des Betriebs gesammelt.

Nachdem die Datenbank erstellt, initialisiert und befüllt wurde, muss sie gepflegt werden. Es kann sein, dass verschiedene Datenbankparameter geändert werden müssen und die Datenbank für eine bessere Leistung getunt werden muss; die Datenstrukturen der Anwendung können geändert oder hinzugefügt werden, neue verwandte Anwendungsprogramme können geschrieben werden, um die Funktionalität der Anwendung zu erweitern, usw.

Sicherung und Wiederherstellung

Manchmal ist es wünschenswert, eine Datenbank in einen früheren Zustand zu versetzen (aus vielen Gründen, z. B. wenn die Datenbank aufgrund eines Softwarefehlers beschädigt wurde oder wenn sie mit fehlerhaften Daten aktualisiert wurde). Um dies zu erreichen, wird gelegentlich oder kontinuierlich ein Backup durchgeführt, wobei jeder gewünschte Datenbankzustand (d.h. die Werte der Daten und ihre Einbettung in die Datenstrukturen der Datenbank) in speziellen Backup-Dateien aufbewahrt wird (es gibt viele Techniken, um dies effektiv zu tun). Wenn ein Datenbankadministrator beschließt, die Datenbank in diesen Zustand zurückzubringen (z. B. durch Angabe dieses Zustands durch einen gewünschten Zeitpunkt, an dem sich die Datenbank in diesem Zustand befand), werden diese Dateien zur Wiederherstellung dieses Zustands verwendet.

Statische Analyse

Statische Analysetechniken für die Softwareüberprüfung können auch im Szenario der Abfragesprachen angewendet werden. Insbesondere das *Abstract interpretation framework wurde auf den Bereich der Abfragesprachen für relationale Datenbanken ausgeweitet, um solide Approximationstechniken zu unterstützen. Die Semantik von Anfragesprachen kann entsprechend geeigneter Abstraktionen der konkreten Datendomäne abgestimmt werden. Die Abstraktion von relationalen Datenbanksystemen hat viele interessante Anwendungen, insbesondere für Sicherheitszwecke, wie z.B. feinkörnige Zugangskontrolle, Wasserzeichen, usw.

Verschiedene Merkmale

Andere DBMS-Funktionen können sein:

  • Datenbankprotokolle - Diese helfen dabei, eine Historie der ausgeführten Funktionen zu führen.
  • Grafikkomponente zur Erstellung von Grafiken und Diagrammen, insbesondere in einem Data-Warehouse-System.
  • Abfrageoptimierer - Führt bei jeder Abfrage eine Abfrageoptimierung durch, um einen effizienten Abfrageplan (eine Teilreihenfolge (Baum) von Operationen) zu wählen, der zur Berechnung des Abfrageergebnisses ausgeführt wird. Kann spezifisch für eine bestimmte Speicher-Engine sein.
  • Tools oder Hooks für den Datenbankentwurf, die Anwendungsprogrammierung, die Wartung von Anwendungsprogrammen, die Analyse und Überwachung der Datenbankleistung, die Überwachung der Datenbankkonfiguration, die DBMS-Hardwarekonfiguration (ein DBMS und die zugehörige Datenbank können sich über Computer, Netzwerke und Speichereinheiten erstrecken) und die zugehörige Datenbankzuordnung (insbesondere bei einem verteilten DBMS), die Speicherzuweisung und die Überwachung des Datenbanklayouts, die Speichermigration usw.

Zunehmend wird der Ruf nach einem einzigen System laut, das all diese Kernfunktionen in ein und demselben Build-, Test- und Deployment-Framework für Datenbankmanagement und Quellcodekontrolle vereint. In Anlehnung an andere Entwicklungen in der Softwarebranche vermarkten einige solche Angebote als "DevOps für Datenbanken".

Entwurf und Modellierung

Process of database design v2.png

Die erste Aufgabe eines Datenbankdesigners besteht darin, ein konzeptionelles Datenmodell zu erstellen, das die Struktur der in der Datenbank zu speichernden Informationen widerspiegelt. Ein gängiger Ansatz hierfür ist die Entwicklung eines Entity-Relationship-Modells, häufig mit Hilfe von Zeichentools. Ein weiterer beliebter Ansatz ist die Unified Modeling Language. Ein erfolgreiches Datenmodell spiegelt den möglichen Zustand der externen Welt, die modelliert wird, genau wider: Wenn Personen beispielsweise mehr als eine Telefonnummer haben können, ermöglicht es die Erfassung dieser Informationen. Der Entwurf eines guten konzeptionellen Datenmodells erfordert ein gutes Verständnis der Anwendungsdomäne; typischerweise müssen tiefgreifende Fragen zu den Dingen gestellt werden, die für eine Organisation von Interesse sind, wie z. B. "Kann ein Kunde auch ein Lieferant sein?", oder "Wenn ein Produkt mit zwei verschiedenen Verpackungsformen verkauft wird, sind diese das gleiche Produkt oder unterschiedliche Produkte?", oder "Wenn ein Flugzeug von New York über Frankfurt nach Dubai fliegt, ist das ein Flug oder zwei (oder vielleicht sogar drei)?". Die Antworten auf diese Fragen legen die Terminologie für die Entitäten (Kunden, Produkte, Flüge, Flugsegmente) und ihre Beziehungen und Attribute fest.

Bei der Erstellung des konzeptionellen Datenmodells werden manchmal die Geschäftsprozesse oder die Analyse der Arbeitsabläufe im Unternehmen herangezogen. Dies kann dazu beitragen, festzustellen, welche Informationen in der Datenbank benötigt werden und welche weggelassen werden können. Dies kann zum Beispiel bei der Entscheidung helfen, ob die Datenbank sowohl historische als auch aktuelle Daten enthalten muss.

Nach der Erstellung eines konzeptionellen Datenmodells, mit dem die Benutzer zufrieden sind, besteht der nächste Schritt darin, dieses in ein Schema zu übersetzen, das die relevanten Datenstrukturen innerhalb der Datenbank implementiert. Dieser Prozess wird oft als logischer Datenbankentwurf bezeichnet, und das Ergebnis ist ein logisches Datenmodell, das in Form eines Schemas ausgedrückt wird. Während das konzeptionelle Datenmodell (zumindest theoretisch) unabhängig von der Wahl der Datenbanktechnologie ist, wird das logische Datenmodell in Form eines bestimmten Datenbankmodells ausgedrückt, das von dem gewählten DBMS unterstützt wird. (Die Begriffe Datenmodell und Datenbankmodell werden oft synonym verwendet, aber in diesem Artikel verwenden wir Datenmodell für den Entwurf einer bestimmten Datenbank und Datenbankmodell für die Modellierungsnotation, die verwendet wird, um diesen Entwurf auszudrücken).

Das am weitesten verbreitete Datenbankmodell für allgemeine Datenbanken ist das relationale Modell, genauer gesagt das relationale Modell, das durch die Sprache SQL dargestellt wird. Der Prozess der Erstellung eines logischen Datenbankentwurfs unter Verwendung dieses Modells verwendet einen methodischen Ansatz, der als Normalisierung bekannt ist. Ziel der Normalisierung ist es, sicherzustellen, dass jeder elementare "Fakt" nur an einer Stelle gespeichert wird, so dass Einfügungen, Aktualisierungen und Löschungen automatisch die Konsistenz wahren.

Die letzte Phase des Datenbankdesigns besteht darin, die Entscheidungen zu treffen, die sich auf Leistung, Skalierbarkeit, Wiederherstellung, Sicherheit usw. auswirken und vom jeweiligen DBMS abhängen. Dies wird oft als physischer Datenbankentwurf bezeichnet, und das Ergebnis ist das physische Datenmodell. Ein wichtiges Ziel in dieser Phase ist die Datenunabhängigkeit, d. h., dass die zur Leistungsoptimierung getroffenen Entscheidungen für die Endbenutzer und Anwendungen unsichtbar sein sollten. Es gibt zwei Arten der Datenunabhängigkeit: Physische Datenunabhängigkeit und logische Datenunabhängigkeit. Das physische Design wird hauptsächlich durch Leistungsanforderungen bestimmt und erfordert eine gute Kenntnis der erwarteten Arbeitslast und der Zugriffsmuster sowie ein tiefes Verständnis der vom gewählten DBMS angebotenen Funktionen.

Ein weiterer Aspekt des physischen Datenbankdesigns ist die Sicherheit. Sie umfasst sowohl die Definition der Zugriffskontrolle auf Datenbankobjekte als auch die Festlegung von Sicherheitsstufen und -methoden für die Daten selbst.

Modelle

Zusammenstellung von fünf Arten von Datenbankmodellen

Ein Datenbankmodell ist eine Art Datenmodell, das die logische Struktur einer Datenbank festlegt und grundsätzlich bestimmt, auf welche Weise Daten gespeichert, organisiert und manipuliert werden können. Das bekannteste Beispiel für ein Datenbankmodell ist das relationale Modell (oder die SQL-Annäherung an das relationale Modell), das ein tabellenbasiertes Format verwendet.

Zu den gängigen logischen Datenmodellen für Datenbanken gehören:

  • Navigationsspezifische Datenbanken
    • Hierarchisches Datenbankmodell
    • Netzwerkmodell
    • Graphische Datenbank
  • Relationales Modell
  • Entity-Relationship-Modell
    • Erweitertes Entity-Relationship-Modell
  • Objektmodell
  • Dokumentenmodell
  • Entitäts-Attribut-Wert-Modell
  • Sternschema

Eine objektrelationale Datenbank kombiniert die beiden verwandten Strukturen.

Physische Datenmodelle umfassen:

  • Invertierter Index
  • Flache Datei

Andere Modelle sind:

  • Mehrdimensionales Modell
  • Array-Modell
  • Mehrwertiges Modell

Spezialisierte Modelle sind für bestimmte Datentypen optimiert:

  • XML-Datenbank
  • Semantisches Modell
  • Inhaltsspeicher
  • Ereignisspeicher
  • Zeitreihenmodell

Externe, konzeptionelle und interne Sichten

Traditionelle Sicht auf die Daten

Ein Datenbankmanagementsystem bietet drei Sichten auf die Datenbankdaten:

  • Die externe Ebene definiert, wie jede Gruppe von Endbenutzern die Organisation der Daten in der Datenbank sieht. Eine einzelne Datenbank kann eine beliebige Anzahl von Sichten auf der externen Ebene haben.
  • Die konzeptionelle Ebene vereinigt die verschiedenen externen Sichten zu einer kompatiblen Gesamtsicht. Sie stellt die Synthese aller externen Sichten dar. Sie liegt außerhalb der Reichweite der verschiedenen Datenbankendbenutzer und ist eher für Entwickler von Datenbankanwendungen und Datenbankadministratoren von Interesse.
  • Die interne Ebene (oder physische Ebene) ist die interne Organisation der Daten innerhalb eines DBMS. Hier geht es um Kosten, Leistung, Skalierbarkeit und andere betriebliche Aspekte. Sie befasst sich mit dem Speicherlayout der Daten und verwendet Speicherstrukturen wie Indizes, um die Leistung zu verbessern. Gelegentlich werden Daten einzelner Sichten (materialisierte Sichten) gespeichert, die aus generischen Daten berechnet werden, wenn die Leistung eine solche Redundanz rechtfertigt. Sie gleicht die Leistungsanforderungen aller externen Sichten aus, die möglicherweise miteinander in Konflikt stehen, und versucht so, die Gesamtleistung aller Aktivitäten zu optimieren.

Während es in der Regel nur eine konzeptionelle (oder logische) und physische (oder interne) Sicht auf die Daten gibt, kann es eine beliebige Anzahl verschiedener externer Sichten geben. Dies ermöglicht es den Benutzern, die Datenbankinformationen aus einer eher geschäftsbezogenen als aus einer technischen, verarbeitungstechnischen Sicht zu sehen. Beispielsweise benötigt die Finanzabteilung eines Unternehmens die Zahlungsdaten aller Mitarbeiter als Teil der Ausgaben des Unternehmens, nicht aber die Daten über die Mitarbeiter, die im Interesse der Personalabteilung liegen. Die verschiedenen Abteilungen benötigen also unterschiedliche Sichten auf die Datenbank des Unternehmens.

Die dreistufige Datenbankarchitektur bezieht sich auf das Konzept der Datenunabhängigkeit, das eine der Hauptantriebskräfte für das relationale Modell war. Die Idee ist, dass Änderungen auf einer bestimmten Ebene keine Auswirkungen auf die Ansicht auf einer höheren Ebene haben. So wirken sich beispielsweise Änderungen auf der internen Ebene nicht auf Anwendungsprogramme aus, die mit Hilfe von Schnittstellen auf konzeptioneller Ebene geschrieben wurden, was die Auswirkungen von physischen Änderungen zur Verbesserung der Leistung verringert.

Die konzeptionelle Sicht bietet eine indirekte Ebene zwischen intern und extern. Einerseits bietet sie eine gemeinsame Sicht auf die Datenbank, unabhängig von verschiedenen externen Sichtstrukturen, und andererseits abstrahiert sie von den Details, wie die Daten gespeichert oder verwaltet werden (interne Ebene). Im Prinzip kann jede Ebene, und sogar jede externe Ansicht, durch ein anderes Datenmodell dargestellt werden. In der Praxis verwendet ein DBMS in der Regel dasselbe Datenmodell sowohl für die externe als auch für die konzeptionelle Ebene (z. B. ein relationales Modell). Die interne Ebene, die innerhalb des DBMS verborgen ist und von dessen Implementierung abhängt, erfordert einen anderen Detaillierungsgrad und verwendet eigene Arten von Datenstrukturtypen.

Die Trennung von externer, konzeptioneller und interner Ebene war ein wesentliches Merkmal der Implementierungen des relationalen Datenbankmodells, das die Datenbanken des 21. Jahrhunderts dominiert.

Forschung

Die Datenbanktechnologie ist seit den 1960er Jahren ein aktives Forschungsthema, sowohl im akademischen Bereich als auch in den Forschungs- und Entwicklungsgruppen von Unternehmen (z. B. IBM Research). Die Forschungstätigkeit umfasst Theorie und Entwicklung von Prototypen. Zu den bemerkenswerten Forschungsthemen gehören Modelle, das Konzept der atomaren Transaktionen, verwandte Techniken zur Steuerung der Gleichzeitigkeit, Abfragesprachen und Methoden zur Optimierung von Abfragen, RAID und vieles mehr.

Im Bereich der Datenbankforschung gibt es mehrere Fachzeitschriften (z. B. ACM Transactions on Database Systems-TODS, Data and Knowledge Engineering-DKE) und jährliche Konferenzen (z. B. ACM SIGMOD, ACM PODS, VLDB, IEEE ICDE).

Bedeutung

Datenbanksysteme sind heute ein zentraler Bestandteil der Unternehmenssoftware. Damit stellen sie einen kritischen Teil vieler Unternehmen und Behörden dar. Von der Verfügbarkeit, Vollständigkeit und Richtigkeit der Daten hängt die Aktionsfähigkeit eines Unternehmens ab. Die Datensicherheit ist daher ein wichtiger und gesetzlich vorgeschriebener Bestandteil der IT eines Unternehmens oder einer Behörde.

Komponenten eines Datenbanksystems

Datenbankmanagementsystem

Das Datenbankmanagementsystem (DBMS) ist die eingesetzte Software, die für das Datenbanksystem installiert und konfiguriert wird. Das DBMS legt das Datenbankmodell fest, hat einen Großteil der unten angeführten Anforderungen zu sichern und entscheidet maßgeblich über Funktionalität und Geschwindigkeit des Systems. Datenbankmanagementsysteme selbst sind hochkomplexe Softwaresysteme.

Für Datenbankmanagementsystem wird (selten) auch der Begriff Datenbankverwaltungssystem (DBVS) verwendet.

Gängig ist die Abkürzung RDBMS für ein relationales Datenbankmanagementsystem.

Beispiele

  • Alle Banken und Versicherungen arbeiten mit Datenbanksystemen, in der Regel mit relationalen DBMS. Im Datenbanksystem sind alle Kunden- und Kontoinformationen, Buchungen und andere Daten strukturiert abgelegt. In diesem Einsatzumfeld haben Datenschutz und Datensicherheit hohe Priorität. Datenbanksysteme werden hier zum Tagesgeschäft (OLTP) sowie periodisch oder ad-hoc zu beliebigen anderen Zwecken (wie im Marketing, Controlling, Rechnungswesen und vielen anderen Bereichen; siehe auch OLAP) verwendet.
  • Faktisch alle mittelständischen Unternehmen und Großkonzerne arbeiten zur Ressourcenplanung mit ERP-Systemen, deren Datenteil in Form von Datenbanksystemen vorliegt.
  • Dieser Artikel in seiner in der Wikipedia vorliegenden Fassung wird neben allen anderen dort enthaltenen Artikeln durch ein Datenbanksystem verwaltet (Wikipedia-Technik).
  • Marktforschungsinstitute tragen eigene und Fremddaten in Data-Warehouses (Datenlagern) zusammen.

Funktionen eines DBMS

Die wesentlichen Funktionen von heutigen Datenbankmanagementsystemen sind:

  • Speicherung, Überschreibung und Löschung von Daten
  • Verwaltung der Metadaten
  • Vorkehrungen zur Datensicherheit
  • Vorkehrungen zum Datenschutz
  • Vorkehrungen zur Datenintegrität
  • Ermöglichung des Mehrbenutzerbetriebs durch das Transaktionskonzept
  • Optimierung von Abfragen
  • Ermöglichung von Triggern und Stored Procedures
  • Bereitstellung von Kennzahlen über Technik und Betrieb des DBMS

Datenintegrität

Die Integrität der Daten kann durch Constraints sichergestellt werden. Dies sind Regeln im Managementsystem, die beschreiben, wie Daten verändert werden dürfen. Der wichtigste Vertreter bei relationalen Datenbanksystemen ist der Foreign Key Constraint. Dieser verhindert, dass Daten gelöscht werden können, die von einer anderen Tabelle noch benötigt, d. h. über einen Foreign Key referenziert werden. Siehe Hauptartikel referentielle Integrität.

Andere Integritätsbedingungen regeln zum Beispiel, ob Duplikate erlaubt sind oder welche Inhalte einzelne Datenfelder enthalten dürfen („Bereichsintegrität“, inkl. Prüfung auf erlaubte Leerinhalte).

Abfrageoptimierung

Auswertungsplan in Form eines Operatorbaums

Damit Daten abgefragt und verändert werden können, stellt das DBMS eine Datenbanksprache zur Verfügung. Eine Abfrage an das Datenbanksystem wird dabei zunächst in die logischen Operationen der relationalen Algebra übersetzt. Danach werden sogenannte Datenbankoperatoren ausgewählt, die die logische Operation tatsächlich auf den Daten ausführt. Die Wahl der Operatoren und die Reihenfolge ihrer Ausführung nennt man das Erstellen eines Ausführungsplans durch den Abfrageoptimierer. Der Optimierer ist ein besonders komplexer Teil der Datenbanksoftware und hat wesentlichen Einfluss auf die Effizienz des Gesamtsystems.

Bei der Abfrageoptimierung spielen Indizes eine wichtige Rolle. Sie dienen dazu, schnell einen bestimmten Datensatz zu finden. Welche Daten einen Index erhalten, wird mit dem Datenbankschema festgelegt, kann aber später von einem Datenbankadministrator angepasst werden.

Anwendungsunterstützung

Zur Unterstützung von Datenbankapplikationen bieten Datenbanksysteme Trigger und Stored Procedures an. Ein Trigger löst eine Aktion in der Datenbank aus, wenn ein bestimmtes Ereignis eingetreten ist, häufig bei Einfüge- oder Änderungsoperationen. Stored Procedures dienen dem Ausführen von Scripten in der Datenbank. Da Stored Procedures innerhalb des Datenbanksystems ausgeführt werden, sind sie oft der effizienteste Weg, Daten zu manipulieren. Datenbanken, die Trigger und Stored Procedures unterstützen, heißen auch aktive Datenbanken.

Mehrbenutzerfähigkeit

Für den Zugriff auf die Daten werden Berechtigungen verwaltet. Ohne Berechtigung kann die entsprechende Operation nicht durchgeführt werden.

Für den (pseudo-)gleichzeitigen Zugriff mehrerer Anwendungen bzw. Anwender regelt das DBMS Konkurrenzsituationen.

  • Es werden Sperren (engl. locks) verwaltet.
  • Es werden Systemprotokolle (engl. logs bzw. log files) verwaltet.
  • Die Datenbank arbeitet transaktionsorientiert.

Diese Gruppe von Anforderungen zeichnet Datenbanksysteme im engeren Sinne gegenüber funktional erweiterten Dateisystemen aus.

Fehler in einer Datenbank, die durch unzulässigen parallelen Datenbankzugriff auftreten, werden Anomalien im Mehrbenutzerbetrieb genannt.

Verschiedene Formen von Datenbanksystemen

Ausrichtung

Klassischerweise unterscheidet man eine Ausrichtung des Systems auf viele kleine Abfragen (OLTP) oder lang andauernder Auswertungen (OLAP). Es ist aber durchaus gängig, dass dasselbe System beiden Anforderungen gerecht werden muss und zum Beispiel tagsüber für den OLTP- und nachts für den OLAP-Betrieb „gefahren“ wird. Ein Datenbankadministrator arbeitet dann unterschiedliche Konfigurationen aus (Hauptspeicher des Servers, Prozess-Anzahl, Optimierungsstrategie beim Zugriff etc.).