Datenbanken sollen große Datenmengen permanent und möglichst effizient verwalten. Was vorgestern mit hierarchischen und relationalen Datenbanken begann, ist heute längst in verteilte Datenbankkonzepte, Big-Data-Ansätze und In-Memory-Technologien eingeflossen.
Mit meinem Kollegen Gottfried Vossen spreche ich im ersten Teil über die historischen Herausforderungen und den aktuellen State of the Art.
Im zweiten Teil diskutieren mein Kollege Gottfried Vossen und ich neue Ansätze, aber auch das Potential für Handy-Datenbanken, Künstliche Intelligenz und Datenmarktplätze.
Viel Vergnügen!
Literaturempfehlung:
- Lemahieu, W., vanden Broucke, S. & Baesens, B.: Principles of Database Management. 2018
https://www.amazon.de/Principles-Database-Management-Practical-Analyzing/dp/1107186129 - Elmasri, R. & Navathe, S. B.: Database Systems. 2016
https://www.amazon.de/Database-Systems-Ramez-Elmasri/dp/1292097612/ref=sr_1_1?qid=1559588206&refinements=p_27%3AShamkant+B.+Navathe&s=books&sr=1-1&text=Shamkant+B.+Navathe - Chen P.P.: The Entity-Relationship Model. 1976
http://bit.csc.lsu.edu/~chen/pdf/erd-5-pages.pdf - Codd E.F.: A Relational Model of Data for Large Shared Data Banks. 1970
https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
————————–
Wenn Ihnen unsere Folgen gefallen, dann freuen wir uns über eine 5-Sterne-Bewertung auf Ihrer Wunschplattform, damit auch andere auf diesen Podcast aufmerksam werden und wir das Angebot weiter verbessern können. Zeitaufwand: 1-2 Minuten.
In diesem Sinne: keep connected.
Herzlichst
Ihr
Axel Winkelmann
Transcript:
ERP-Podcast Folge 98 Eine kurze Geschichte der Datenbank Ein Interview mit Prof. Dr. Gottfried Vossen Datenbanken sollen große Datenmengen permanent und möglichst effizient verwalten. Was vorgestern mit hierarchischen und relationalen Datenbanken begann, ist heute längst in verteilten Datenbankkonzepte, Big-Data-Ansätze und In-Memory-Technologien eingeflossen. Mit meinem Kollegen Gottfried Vossen spreche ich im ersten Teil über die historischen Herausforderungen und den aktuellen State-of-the-Art.
Viel Vergnügen! Herzlich willkommen zum ERP-Podcast. Dem Podcast für alle, die sich aktiv mit dem Einsatz und der Gestaltung von Unternehmenssoftware und den daraus entstehenden Veränderungen und Potenzialen in Unternehmen auseinandersetzen wollen. Mit diesem Podcast möchte ich Sie mit eigenen Gedanken und Interviews bei der Gestaltung moderner IT-Konzepte nebenbei, also zum Beispiel beim Spazierengehen oder Autofahren, begleiten.
Damit möchte ich Ihnen in dieser von technologischen Veränderungen geprägten Zeit Informationen anbieten, die sich in Zeitschriften, Fachbüchern und wissenschaftlichen Artikeln in dieser Form nicht darlegen lassen und für die sich im hektischen Alltag ohnehin nicht die Zeit findet. Mein Name ist Axel Winkelmann. Ich bin Professor für Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität Würzburg.
So, herzlich willkommen zurück zum ERP-Podcast. Ich versuche ja jede Woche eine spannende, eine interessante Folge, ein interessantes Thema herauszuarbeiten und in der letzten Zeit haben wir uns ein bisschen beschäftigt mit Blockchain, mit letztendlich dann ja auch verteilten Daten. Das schien sehr, sehr gut anzukommen.
Ich habe relativ viele Rückmeldungen gekriegt und ich nehme das mal zum Anlass, den Gottfried Vossen, seines Zeichens Professor an der Universität Münster, und zwar für Informatik, für Datenbanken nochmal ins Gespräch zu holen. Ich würde mich nämlich gerne ein bisschen über die Geschichte von Datenbanken unterhalten. Ich glaube, das ist im Themenumfeld Unternehmenssoftware, ERP, ein ganz, ganz spannendes Thema und ich freue mich, dass du dir Zeit genommen hast.
Herzlich willkommen hier zurück im ERP-Podcast. Herzlich willkommen, Gottfried Vossen. Ja, vielen Dank, Axel.
Ich freue mich, noch ein zweites Interview gegeben zu dürfen. Das erste letztes Jahr fand ich sehr spannend. Ja, ich bin seit 1993 Professor für Informatik am Institut für Wirtschaftsinformatik an der Uni Münster.
Ich habe in Aachen studiert, ich habe 1974 angefangen, da war die Informatik noch ganz jung. Ich habe 1979 meine erste Datenbankvorlesung gehört, damals bei Joachim Biskup, über die Theorie relationaler Datenbanken. Das war eine Vorlesung, wie der Name schon sagt, Theorie von Datenbanken.
Das war damals, ja, das war, was man so machte und das hat eigentlich mein Interesse für das Gebiet entzündet. Ich habe mich dann damit beschäftigt, noch nicht in der Diplomarbeit, aber später in meiner Dissertation und auch in meiner Habilitation und bin dem Gebiet eigentlich bis heute treu geblieben. 1979 hast du gerade gesagt, das heißt, du bist jemand, der eigentlich das Thema Datenbanken noch nicht ganz vom Anfang, aber doch sehr, sehr lange verfolgt hat und uns heute wahrscheinlich auch einiges sagen kann.
Vom Anfang bis zur heutigen, vielleicht auch bis zur zukünftigen Entwicklung. Ich würde ganz, ganz vorne nochmal anfangen und zwar bei dem Thema, was sind Daten überhaupt? Ja, was sind Daten? Daten sind Abbilder einer realen Welt. Man speichert Daten, wenn man bestimmte Zusammenhänge aus der Realwelt sich merken will, aber relativ zu einem gewissen Abstraktionsprozess.
Also das ist das, was man tut, wenn man eine Datenbank aufbaut, also wenn man Datenmodellierung betreibt. Dann will man Daten sammeln über zum Beispiel einen Geschäftsbetrieb, über Personen, aber man möchte nicht unbedingt jedes Detail über den Geschäftsbetrieb oder jedes Detail über die Person oder die Zusammenhänge dazwischen sich merken, sondern man führt zunächst einen Abstraktionsprozess durch und der sorgt dafür, dass eben die wichtigen Dinge hoffentlich wichtigen verwahrt werden und die weniger wichtigen eben sich nicht in den Daten niederschlagen. Das hat man früher im Wesentlichen manuell gemacht.
Die ersten Datenbanken mussten wirklich händisch aufgebaut werden. Heutzutage läuft das natürlich vieles automatisiert. Gerade im Web, jeder Klick wird irgendwie notiert, jede Suchanfrage wird notiert.
Alles, was man im Web so macht. Ob das immer in einer Datenbank landet, ist eine ganz andere Frage, aber es entstehen heutzutage eben auf vielfache Weise Spuren einer Aktivität, einer Tätigkeit, die sich in Daten niederschlagen, in Daten setzen, die in irgendeiner Weise strukturiert sind und die man typischerweise sich merkt in irgendeiner Speicherform. Wenn ich irgendwo Vorträge halte, jetzt mal nicht Studierende, sondern irgendwo in der weiten Welt und ich versuche es ein bisschen näher zu bringen, was ist eigentlich Digitalisierung, über was reden wir hier eigentlich, dann setze ich meistens sehr zur Verwunderung der Leute gar nicht in der Softwarebranche an, sondern viel, viel früher, als der Mensch Hüllmalerei betrieben hat, als die Schrift erfunden wurde, später das Rechensystem erfunden wurde.
Also erstmal Sachen, die wir als ITler gar nicht so sehr im Kopf haben, wenn wir über Daten denken, aber letztendlich kommen wir ja aus der Zeit, wo wir erstmal abstrahiert haben von Objekten, von Subjekten, von Zuständen, von Transaktionen, um überhaupt festzuhalten, was passiert da eigentlich. Und dann kommt irgendwann die Software und wie ist die Software damit umgegangen, dass man Daten braucht, um Algorithmen arbeiten zu lassen? Also zunächst mal würde ich Hüllmalerei nicht mit Digitalisierung in Verbindung bringen, weil Hüllmalerei war ja vielfach mit irgendwelchen Symbolen oder auch mit Grafiken verbunden, wohingegen bei der Digitalisierung in dem Wort steckt ja das Wort Digit schon drin, das englische Wort für Ziffer und Digitalisierung setzt da ein, wo man anfängt Zusammenhänge nur noch in Ziffernfolgen genauer gesagt auszudrücken und wenn man es auf dem Computer macht, dann bleibt einem natürlich nichts anderes übrig, als es letztlich in 0 und 1 darzustellen. Und das ist glaube ich das, was die ersten Schritte der Digitalisierung ausmacht.
Ja, jetzt wird es philosophisch, aber darauf lasse ich mich jetzt nicht ein. Ja, ja. Gut, also wir sind in der Softwaretechnologie.
Ja, also Software braucht eben Daten, um funktionieren zu können. Ich möchte, wenn ich heutzutage eben Geschäftsbetrieb, Software einsetze, dann möchte ich was über meine Kunden wissen, ich möchte meine Bestellvorgänge abwickeln, ich möchte meine Lagerhaltung abwickeln und alles das basiert auf Daten. Das wird jetzt nochmal enorm beflügelt und beschleunigt durch die Entwicklung der künstlichen Intelligenz, wo man eben Algorithmen entwickelt, die lernfähig sind und wo man eben sagt, wir brauchen große Datenmengen, um die Algorithmen zu trainieren und damit sie eben das, was sie leisten sollen, dann auch irgendwann eigenständig tun können.
Das alles basiert auf Daten, das heißt Software ohne Daten kann ich mir eigentlich kaum vorstellen. Gehen wir mal ein bisschen zurück in der Geschichte. Die ersten Ansätze zur Datenverwaltung, wie sah das aus? Also die allerersten Ansätze, die finden sich heute noch in manchen Rechenzentren.
Die allerersten basierten auf einem hierarchischen Datenmodell. Da hat man versucht, das was man so in Fallsystemen praktiziert hatte, jahrelang schon, also irgendwelche Rekords, die in Felder unterteilt waren. Und in diesen Feldern waren dann die Daten gespeichert, also zum Beispiel Name, Vorname, Adresse und so weiter.
Diese Rekords zu verknüpfen, sodass man quasi in dem Netzwerk, was dadurch entstand, in irgendeiner Form navigieren konnte. Die erste Form waren sehr einfache Systeme, sogenannte hierarchische. Da waren das keine Netzwerke, sondern da war die Verknüpfungsstruktur ein Baum.
Und man wusste, wenn man z.B. ein bestimmtes Datum suchte, also die Person mit dem Nachnamen Winkelmann, dann musste man in der Wurzel des Baumes einsteigen und dann eben so eine Suchfahrt durchlaufen, bis man in irgendeinem Blatt ankam und entweder das gesuchte Datum gefunden hatte oder feststellte, sie ist nicht enthalten. Das hat man in der Folge, so in den 60er Jahren, in dem sogenannten Kodasyl-Modell, wurde das ein bisschen besser. Dann musste das nicht streng hierarchisch ablaufen, sondern da waren es dann wirklich Netzwerkstrukturen, wo man eben in mehr oder weniger beliebiger Weise hin- und herlaufen konnte.
Man brauchte immer noch einen Einstiegspunkt, aber man konnte dann flexibler durch dieses Netzwerk navigieren, wobei flexibel relativ zu sehen ist, weil die Anfragesprache, derer man sich bedienen musste, dann schon ziemlich umständlich war. Interessanterweise kommen solche Strukturen heute wieder. Als eine Form der sogenannten NoSQL-Datenbanken, also Not Only SQL, gelten ja heute die Graph-Datenbanken und in denen erlebt eigentlich diese grafische Darstellung, also die Netzwerkdarstellung von Daten der Renaissance.
Aber vielleicht kommen wir da später noch drauf. Das heißt, man hat Datenbanken geschaffen, eigene Software-Systeme oder war das Teil der Software, in unserem Fall der betriebswirtschaftlichen Software? Wie kann ich mir das am Anfang vorstellen, das Thema Datenbank? Man hat schon relativ früh eine relativ klare Trennung vorgenommen, so wie man das von Filesystemen kannte, also von Dateisystemen. Das war ja eigentlich immer so.
Man hat ein Programm, das Programm, wenn es auf Daten arbeiten muss, dann greift es auf irgendeine Datei zu. Die Datei wird von einem Dateisystem verwaltet, von einem Filesystem. Und bei Datenbanken war eigentlich die Idee, die Filesysteme ein klein bisschen intelligenter zu machen.
Also zum Beispiel mit einer speziellen Anfragesprache auszustatten oder eben später bei relationalen Systemen ging das eben wesentlich weiter, wo man eben sagte, wir wollen jetzt diese Systeme, die die Daten verwalten, ein bisschen intelligenter machen. Wir wollen denen Aufgaben überlassen, die bisher der Programmierer zur Verfügung hat, die aber den Programmierer von der eigentlichen Tätigkeit, von dem eigentlichen Kern der Software, die er entwickeln will, ablenken. Das typische Beispiel hier ist das Transaktionskonzept, was man dann später in relationalen Systemen natürlich sehr intensiv untersucht hat und was eben auch den relationalen Systemen dann zu ihrem großen Erfolg verholfen hat.
Ich frage nochmal, warum hat man das getrennt? Warum hat man die Logik der Software getrennt von der Datenbasis? Was war die Intention dahinter? Also eine Intention war sicherlich Austauschbarkeit. Ich kann mehrere Programme, wenn ich das trenne, kann ich verschiedene Programme auf dem gleichen Datenbestand arbeiten lassen. Andere Gründe waren sicherlich die Entwicklung.
Das wurde von unterschiedlichen Leuten entwickelt. Fallsysteme kamen mehr so aus dem Bereich der Betriebssysteme. Und die Software, die auf Daten arbeitet, die kam eben mehr aus den Anwendungen, insbesondere betrieblichen Anwendungen.
Von daher war diese Trennung, dafür gab es einerseits technische Gründe, aber dafür gab es sicherlich auch inhaltliche Gründe. Ich denke zum Beispiel an die ganze SAP-Entwicklung R2, später R3, wo das R ja für Realtime steht. Den Zugriff aus unterschiedlichen funktionalen Bereichen, eigenständigen Modulen auf die gleiche Datenbasis, das wäre natürlich nicht denkbar gewesen, wenn wir nicht ein zentrales Datenbankmodell gehabt hätten, oder? Ja, so ist das, genau.
Diese Trennung von Daten und Programmen, von der man schon relativ früh gesprochen hat, die ermöglicht es eben, dass viele unterschiedliche Programme auf die gleiche Datenbank zugreifen. Und dass ich die Datenbank oder den Datenbestand eben nicht jedes Mal ändern muss, um an das spezifische Programm anzupassen. Das Programm, was auch mit Daten arbeiten will, muss sich eben angucken, wie die Daten organisiert sind und muss darauf Rücksicht nehmen.
So, jetzt hast du gesagt, ganz am Anfang 60er-Jahre, Anfang der 70er-Jahre, hierarchisch, netzwerkartige Datenorganisation in solchen Datenbanken. Was ist dann passiert? Ja, dann hatte Ted Kott, als er bei IBM Alverdänen gearbeitet hat, die Erkenntnis, mal die logische Sicht auf eine Datenbank von der physischen zu trennen. Das war die Idee, die dem relationalen Modell zugrunde lag.
Ted Kott hat 1970 in den Communications ACM, sehr berühmtes Paper, veröffentlichte Relational Model for Large Shared Data Bank oder so ähnlich war der Titel. Und das war der Beginn einer, ja, das war ein gigantischer Durchbruch damals, das war der Beginn einer Welle in der Forschung, die man jahrzehntelang angehalten hat im Grunde. Und es war eine Welle der Entwicklung, die sich unter anderem IBM, aber auch Oracle relativ schnell gestürzt haben und haben gesagt, das ist die Zukunft.
Wir müssen ein System bauen, was auf diesem Modell basiert. Das relationale Modell sagt eben, ich habe als Benutzer eine Sicht auf Tabellen und mir ist völlig egal, wie die Tabellen intern implementiert werden. Also es war diese klare Trennung plötzlich von interner Struktur und logischer Struktur, also von konzeptioneller Sicht und interner Sicht.
Und das war eben bei den vorherigen Generationen, hierarchisches Netzwerkmodell nicht der Fall. Ich hatte ja schon gesagt, bei Netzwerk und hierarchisch war das eben eng verbunden. Da war die physische Sicht die gleiche wie die konzeptionelle.
Und Kott hat das zum ersten Mal aufgerufen. Kott war von Hause aus Mathematiker, genauer gesagt Logiker, also er hat das mit logischen Mitteln beschrieben, aber das haben dann andere Leute relativ schnell mehr zu wenig gemacht. IBM hat relativ schnell mit der Entwicklung eines Systems begonnen.
Das haben sie dann zehn Jahre später auf den Markt gebracht, das SQL Data System. Und wieder zwei Jahre später DB2. Und DB2 gibt es ja bis heute noch.
Oracle kam relativ schnell auch mit der ersten Datenbank raus. Das war damals ein Wettrennen zwischen Oracle und IBM. Und es gab dann relativ schnell Entwicklungen für Anfragesprachen.
Im Wesentlichen zwei. Das war das, was man heute als SQL kennt, also Standard Query Language, SQL, Structured Query Language. Da gibt es ja unterschiedliche Interpretationen.
Und an der University of Berkeley haben sie dann für das Ingress die Sprache Quell entwickelt. Das waren so zwei konkurrierende Entwicklungen. Oracle und IBM haben sich beide auf SQL gestürzt.
Und man hatte in SQL eigentlich so eine Reihe von Fragen, die man nicht so richtig, wo man noch relativ lange dran rumgeforscht hat. Also das war zum Beispiel die Behandlung von Nullwerten. Wenn ich einen Wert nicht kenne in der Datenbank, dann trage ich da einen Nullwert ein.
Aber ein Nullwert, so wie er in SQL-Systemen gehalten wird, der kann vieles bedeuten. Der kann bedeuten, ich kenne den Wert nicht. Es kann bedeuten, der Wert ist unbekannt.
Es kann bedeuten, der Wert ist nicht anwendbar. Und diese unterschiedlichen Semantiken, die sind in SQL-Systemen bis heute nicht realisiert. Gibt es einen einfachen Grund für… Man hat sich bei IBM relativ lange mit der Frage umgeschlagen, wie kann ich eigentlich Nullwerte vernünftig behandeln? Und dann kam Oracle mit dem Datenbank-System raus, und dann war alles erledigt.
Und man hat sofort das SQL-Data-System hinterhergeschoben. Und die Überlegungen zu SQL waren beendet. Das sind dann so, wie soll ich sagen, Entwurfssünden, die der Sprache bis heute anlasten.
Später hat sich keiner mehr damit beschäftigt. Da hatte dann keiner Lust, sich nochmal auf diese Anfänge zu besinnen und diese Fragen mal abschließend zu beantworten. Und darum ist es bis heute so tatsächlicher Anwendungssoftware und der eigentlichen Datenbank. Der Vorteil ist einleuchtend, aber es gab wahrscheinlich nicht nur Vorteile, oder? Es gab zunächst mal große Implementierungsprobleme. Also die relationalen Systeme in der Anfangszeit waren deutlich langsamer als die Netzwerkdatenbanken.
Und man hat sich dann natürlich mal überlegen müssen, wie… Also das ist klar, wenn ich eine Pontakette nachlaufe, wo ich den Einstiegspunkt kenne und dann relativ schnell von einem Datensatz zum nächsten navigieren kann, dann geht das im Allgemeinen nicht so schnell, als wenn ich eine Tabelle vor mir sehe. Ich muss erst mal spezifizieren, was will ich aus unterschiedlichen Tabellen zusammenbauen und mir dann überlegen, wie sieht das jetzt auf der physischen Seite aus. Das ist eben die Sache des Datenbanksystems.
In dem Moment, wo ich diese Trennung mache, also in logischer Sicht und physischer Sicht, in dem Moment hat der Benutzer, der mit der Datenbank interagiert oder das Programm, was auf die Datenbank zugreift, natürlich keinen Einfluss mehr auf die physische Sicht. Und das hat in der Anfangszeit zu großen Problemen geführt, weil man einfach sich überlegen musste in industriellen Anwendungen, in betrieblichen Anwendungen, da ist natürlich Speed, Performance ist immer wesentlich. Und das hat dazu geführt, dass man gesagt hat, wir müssen die relationalen Systeme einfach schnell machen.
Wir müssen die Performance verbessern, die sind im Moment so langsam, das geht nicht. Das hat viele Jahre gedauert, das hat aber auch viele sehr interessante Entwicklungen hervorgebracht. Eine der Entwicklungen, die mir sofort in den Sinn kommt oder ein Name, der mir sofort in den Sinn kommt zur Beschreibung von Datenstrukturen, eigentlich ist Chen, was hat der Kollege gemacht? Ja, Peter Chen hat, auf den geht das NCT Relationship Modell zurück.
Peter Chen hat sich in relativ früh, also schon Mitte der 70er Jahre, da waren die relationalen Systeme gerade auf dem Markt, die ersten, hat er sich überlegt, wie geht man eigentlich den Datenbankenberufsprozess vernünftig an. Und sein Vorschlag war, dass man das zunächst mal völlig unabhängig von dem spezifischen System macht, mit dem man später die Datenbank realisiert. Und dazu hat er eben das NCT Relationship Modell vorgeschlagen.
Er sagt, ihre Welt besteht im Wesentlichen aus zwei Dingen, nämlich aus Entitäten. Das sind Dinge der realen Welt, die eine eigene Identität haben, denen ich einen Schlüssel zuorten kann, und Beziehungen zwischen diesen. Das sind die Relationships.
Und damit kann ich im Grunde, Entitäten können Attribute haben, und Relationships können auch Attribute haben, und Relationships können auch eine Kardinalität haben, sie können auch zweistellig oder mehrstellig sein. Und das war so seine Vorstellung. Und die hat er damals propagiert in einem berühmten Papier, was 1976 in den ACM Transactions und Data Systems erschienen ist.
Ich glaube, sogar in der allerersten Ausgabe. Das hat enorme Forscher dazu motiviert, sich damit zu befassen. Das gab relativ schnell die ER-Konferenz, die gibt es heute noch.
Ich glaube, dieses Jahr in der 39. oder 40. Ausgabe oder so.
Oder sogar noch mehr. Seit 1978 gibt es die. Und das war die Idee zum Datenbankentwurf, einfach über die logische Sicht der Tabellen noch eine Sicht drüber zu setzen, die jetzt wiederum von den Tabellen völlig abstrahiert.
Und wenn ich meinen Datenbankentwurf in einem Entity Relationship formuliere, dann habe ich erstens mal eine gute Dokumentation, und zweitens bin ich unabhängig vom Zielmodell. Ich kann das dann übersetzen in ein relationales Modell, ich kann es auch in ein hierarchisches übersetzen oder in irgendetwas anderes. Aber ich habe ein implementierungsmodellunabhängiges Modell.
Das war die große Idee von Chen. Und das hat sich in Werkzeugen niedergeschlagen. Das ER-Win.
Das ist so ein Tool, das ist sehr bekannt, was man einsetzen kann, wo man heutzutage ER-Diagramme am Rechner entwickeln kann, interaktiv. Die werden dann automatisch in bestimmte andere Modelle übersetzt, z.B. in Tabellenstrukturen. Es hat viele Erweiterungen des ursprünglichen Modells gegeben.
Und man greift für sich irgendein Lehrbuch über die AMAX-Systeme. Und da gibt es natürlich mindestens ein dickes Kapitel über das Entity Relationship-Modell. Auch wenn wir bei der 39.
Ausgabe der Konferenz sind, das Thema ist sicherlich noch lange nicht abgeschlossen. Kommen wir mal zurück zu dieser relationalen Datenbank. Plötzlich verschiedene Software-Systeme, also Anwendungssysteme, die auf die gleichen Daten, auf die gleichen Datenbanken zugreifen konnten, auch zugreifen wollten.
Das bedeutete natürlich einiges auch für den Aufbau dieser Datenbank-Management-Systeme. Wie sind die aufgebaut? Was machen die einzelnen Teilbereiche so eines Software-Packages? Ja, man hat sich angewöhnt, das in Ebenen zu strukturieren. Also wenn im Wesentlichen, wenn eine Datenbank existiert, also wenn sie eingerichtet ist und wenn sie mit Daten gefüllt ist, dann bin ich in der Lage, Anwendungen darauf laufen zu lassen.
Anwendungen stellen typischerweise Anfragen an die Datenbank. Anfragen werden in einer Hochsprache wie SQL gestellt. SQL ist eine sogenannte deklarative Sprache.
Das heißt, ich muss deklarieren, die Eigenschaften, die mein Ergebnis haben soll, ohne aber gleichzeitig dem System zu sagen, wie es diese Ergebnisse produziert. Das wäre eine prozedurale Sprache. SQL ist deklarativ.
Das heißt, der Benutzer der Sprache kann sich im Grunde beliebig dumm einstellen. Also er kann seine Anfrage beliebig umständlich formulieren. Und es ist Aufgabe des Systems, dann eine Optimierung durchzuführen, die versucht, die Anfrage zu verbessern.
Bei Beibehaltung des Ergebnisses natürlich, ohne ein anderes Ergebnis zu produzieren. Und wobei man natürlich beim Optimieren, also das ist immer so der erste Schritt. Das System hat eine Optimierungsebene.
Ein Anfrageoptimierer, typischerweise kostenbasiert, der rechnet verschiedene mögliche Ausführungen durch und entscheidet sich dann für eine Preiswerte. Der Optimierer findet nicht notwendig das Optimum einer Ausführung, sondern der Optimierer hat die Aufgabe, die schlechteste Ausführung zu vermeiden. Dann die nächste Schicht ist die Transaktionsschicht.
Die Transaktionsverarbeitung hat die Aufgabe, mehrere Benutzer gleichzeitig am Markt arbeiten zu lassen. Das ist eine typische Anforderung. Und wenn ich mehrere sage, dann sind da häufig mehrere Tausend gemeint, weil man denke nur mal an so ein Fluchreservierungssystem wie Amadeus oder Sabre oder Kreditkarten, Systeme wie Mastercard oder Visa.
Die haben viele Tausend Transaktionen. Ich las jetzt neulich eine Zahl, Visa verarbeitet pro Sekunde 50.000 Transaktionen. Ich sag es nochmal, 50.000 pro Sekunde.
Und diese kommen dann in die unterste Schicht. Transaktionen müssen also in irgendeiner Weise synchronisiert werden. Da gibt es gewisse sogenannte Garantien.
Und auf der Ausführungsschicht brauche ich dann die Ebene der Datenschutung, die mir dann erlaubt, das Ganze auch effizient auszubauen. Also ich habe so verschiedene. Ich habe die Anfrageebene, oben sozusagen die Benutzerebene.
Darunter liegt die Optimierungsebene, die Transaktionsebene. Transaktionen sind auch das Transaktionskonzept. Manche Transaktionsverwaltung muss auch Fehlerbehandlung können.
Also wenn die Datenbank abstürzt, wenn die Datenbank stehen bleibt, dann muss die Transaktionsverwaltung, genauer das Recovery-System, wieder für Nahtloses wieder anfahren. Und ganz unten drunter ist so die Implementierungsschicht. Da sind dann die Datenstrukturen und letztlich die eigentlichen Daten.
Die typischerweise auf einem externen Speicher gehalten werden, viele Jahre lang auf Festplatten, der dann mit einem Datenbankpuffer im Hauptspeicher interagiert. Und heutzutage natürlich häufiger SSDs und so. Zwei Dinge fallen mir ein, die wir vielleicht an der Stelle einflechten können.
Das eine ist, wieder aus meiner ERP-Welt, ich erinnere mich, dass die SAP damals ja ursprünglich für die Industrie entwickelte Funktionalität hatte, die sie dann mit dem R3 oder SAP for Retail auch in die Handelswelt bringen wollte. Und sie hatten lange, lange Probleme mit diesen Datenmengen, die ganz unterschiedlich viel größer waren, als dass man das aus der Industrie kannte, überhaupt umzugehen. Das war sicherlich ein langjähriges Phänomen, was wir auch in den relationalen Datenbanken hatten.
Überhaupt mit diesen riesigen Datenmengen, du hast eben das Beispiel der Kreditkarten genannt, umzugehen. Und das Zweite, was mir spontan in den Sinn kommt, ich habe vor einiger Zeit, wir verlinken auch alle Podcast-Folgen, eine Podcast-Folge mit dem Gründer der Firma Pardasoft gemacht, auch ein langjähriger ERP-Hersteller, der sagt ganz klar, Teile unseres Software-Codes liegen heute in der Datenbank. Das heißt, Algorithmen werden gar nicht mehr losgelöst von der Datenbank programmiert, wie man das jetzt eigentlich denken sollte.
Ich meine, wir haben ja auch so angefangen, wie gesagt, die Datenbank oder das Datenbank-Management-System ist losgelöst vom Anwendungssystem, sondern der Algorithmus liegt direkt in der Datenbank. Warum macht man das? Ja, das war eine von vielen Entwicklungen, die man so in den 90er- und 2000er-Jahren gesehen hat. Die würde ich einordnen unter dem Oberbegriff aktive Datenbanken.
Also man hat immer mehr versucht, bestimmte Funktionalität in die Datenbank zu verlagern, so wie man das mit dem Transaktionskonzept ja schon von vornherein gemacht hat. Ein Transaktionskonzept liefert Garantien, die Datenbank in einem konsistenten Zustand zu halten, jede Transaktion atomar auszuführen und eben auch nach einem Crash wiederherzustellen. Das sind Garantien, um die sich der Programmierer nicht kümmern braucht.
Wenn ein Datenbanksystem keine Transaktionsverarbeitung hat, dann muss der Programmierer das per Hand machen. Und da hat man sich dann irgendwann gefragt, können wir das nicht mit noch anderen Funktionalitäten als nur Transaktionen machen, dass wir das der Datenbank überlassen? Wenn ich im Datenbankentwurf Integritätsbedingungen, also zum Beispiel Schlüssel definiere, dann erwarte ich ja auch, dass die Datenbank diese Schlüsselbedingungen automatisch überprüft und ich mich nicht darum kümmern muss. Und das hat dann dazu geführt, dass man gesagt hat, na ja, dann wäre es doch nett, wenn ich bestimmte Dinge in der Datenbank ablegen könnte und die Datenbank behandelt das dann genauso automatisch, wie sie das mit Integritätsprüfungen macht, wie sie das mit Transaktionen macht.
Und das sind zum Beispiel Trigger. Ein Trigger ist ein Programm, was das Auftreten bestimmter Events, bestimmter Ereignisse überwacht. Wenn das Ereignis eintritt, dann wird nochmal eine Bedingung überprüft, ob eine bestimmte Bedingung vorliegt.
Und wenn das der Fall ist, dann feuert der Trigger. Wie man sagt, dann wird einfach eine bestimmte Aktivität, ein Programm ausgeführt, was der Benutzer für diesen Fall vorgesehen hat. Das war so der Beginn der aktiven Datenbanken und das macht man eben unter Umständen inzwischen mit einer ganzen Reihe von Dingen, wo ich also ganze Programme in der Datenbank ablege und diese dann unter bestimmten Bedingungen ausführe.
Das hat auch zu prozeduralen Erweiterungen von SQL geführt. SQL ist ja eine Sprache, die aus der Sicht von Programmiersprachen stark eingeschränkt ist. Ich sagte eben, der Benutzer kann sich in der Formulierung von SQL-Anfragen ja beliebig dumm anstellen.
Und das Schöne daran ist, er kann im Grunde kein Programm formulieren, was endlos läuft. Also ich kann mit einer SQL-Anfrage nicht in eine Endlosschleife kommen, wo dann die Datenbank ewig beschäftigt wäre, mir kein Ergebnis liefert und ich weiß nicht warum. SQL ist so stark eingeschränkt, dass das nicht geht.
Aber viele Leute sagen natürlich, das ist aber nicht so schön. Wir sind ja in Programmiersprachen gewöhnt, eben alles programmieren zu können, was berechenbar ist, was durch Algorithmen berechenbar ist. Warum kann man das in SQL nicht? Und das hat zu vielen Erweiterungen geführt.
Ich habe mich damit selber auch mal so aus theoretischer Sicht ein bisschen beschäftigt. Mike Stonebreaker hat das vor vielen Jahren mal angeschoben mit seiner Idee Quell as a Data Type. Also die Quell as a Data Type war sozusagen die Idee zu sagen, ich lasse in Attributen, ich lasse anfragewertige Attribute zu.
Das heißt, ich habe eine Tabelle mit normalen Attributen. Jedes Attribut hat irgendwie einen Datentyp. Also es kann Integer sein oder Charakter oder Boolean.
Und manche Attribute haben den Datentyp Quell. Und wenn ein Attribut den Datentyp Quell hat, dann kann ich als Wert für dieses Attribut eine Quellanfrage speichern. Das heißt, wenn ich auf diesen Attributwert zugreife, wird dann diese Anfrage ausgeführt.
Und das war so die Stonebreaker-Idee. Und das haben ganz viele Leute dann irgendwie anders vorgestellt und haben dann eben SQL und auch andere Sprachen um höhere Funktionalität erweitert oder eben direkt gesagt, wir wollen das in der Datenbank ablegen. Das wurde auch gewünstigt durch die Entwicklung von objektorientierten Datenbanken.
Das war so ein großes Thema in den 80er Jahren, wo man gesagt hat, in Programmiersprachen machen wir doch im Grunde jetzt alles objektorientiert. Datenbanken machen wir aber alles immer noch relational. Und wenn wir jetzt aus einer objektorientierten Programmierumgebung auf eine Datenbank zugreifen wollen, dann müssen wir da einen ganz komischen Transformationsprozess zwischensetzen.
Warum? Und das hat dazu geführt, dass man sich überlegt hat, können wir nicht die Datenbanken auch stärker objektorientiert machen? Das war eine lange Diskussion. Da gab es viele Ansätze. Ich erinnere mich an das französische O2-System oder das amerikanische Object Store.
Es gab auch deutsche Entwicklungen. Und die haben im Grunde nie die Performance relationaler Systeme erreicht. Es gibt zwar inzwischen seit über 20 Jahren die sogenannten objektrelationalen Erweiterungen des relationalen Modells.
Also ich kann typisierte Relationen machen und solche Dinge. Aber im Grunde haben sich die objektorientierten Datenbanken nie wirklich durchgesetzt. Das hat hauptsächlich Performance.
Das ist das Schöne, wenn sich zwei Professoren unterhalten. Wenn man sich so richtig warm geredet hat. Ich brauche gar keine Stichworte mehr zu geben, weil Objektorientierung wäre für mich das nächste Stichwort.
Es macht wahnsinnig viel Spaß, mit dir darüber zu reden. Vielleicht kannst du noch mal kurz sagen, was bedeutet Objektorientierung? Was ist ein Objekt aus Sicht der Informatik? Aus Sicht der Informatik ist ein Objekt ein Mitglied einer Klasse. Und die Klasse bündelt im Prinzip Struktur und Verhalten.
Das ist so die wesentliche Idee. Also eine Klasse. Also analog eigentlich die Tabelle.
Die Tabelle ist eine Sammlung von Entitäten, wenn man die schon mal gefallenen Begriffe mal wiederverwenden darf. Und in einem Objekt mache ich aber ein bisschen mehr. Ich assoziiere mit dem Objekt eben nicht nur die Struktur, die sich ausdrückt in einer Sammlung von Attributen, die ich dem Objekt zuordne, sondern die Klasse bündelt sofort für diese Objekte ein Verhalten.
Also die Objekte verstehen bestimmte Messages und hinter den Messages liegen Methoden, die ich auf den Objekten der Klasse ausführen kann. Es geht noch ein bisschen weiter. Die Attribute einer Klasse können selber wieder objektwertig sein.
Das heißt, sie können andere Klassen referenzieren als Datentyp. Das heißt, man kann auch schon wieder fast so was wie eine Netzwerkstruktur aufbauen. Man sieht das so an UML-Klassendiagramen ganz schön.
Aber das ist im Wesentlichen der Kick. Also die Kapselung von Strukturen und Verhalten und die Anordnung dessen in einer Vererbungshierarchie. Vererbung ist auch ein wichtiges Konzept in dem Zusammenhang.
Ich kann klassenhierarchisch zueinander anordnen und muss dann nicht bei den Unterklassen die gesamte Struktur der Oberklassen wiederholen, sondern die wird einfach vererbt. Also wenn ich Personen habe, dann kann ich die eben in Studierende und Professoren spezialisieren. Alle Personen haben einen Namen, aber nicht jede Person hat zum Beispiel einen Gehalt oder eine Matrikelnummer.
Das sind eben dann die Spezialisierungen oder das, was mir die Spezialisierung zugeht. Das sind die Eigenschaften der Objektorientierung. Das kann man in relationalen Systemen inzwischen nachspielen.
Bei den sogenannten objektrelationalen kann ich also Tabellen mit einem bestimmten Typ ausstatten. Ich kann an dem Typ nicht nur die Attribute binden, sondern auch Methoden, die dann genau auf diesem Typ ausführbar sind. Ich kann Tabellen in einer Vererbungshierarchie anordnen und habe dann natürlich auch in SQL andere Möglichkeiten, mit diesen getypten Tabellen umzugehen.
Also ich kann in einer derselben Datenbahn getypte und nicht getypte Relationen haben. Die nicht getypten, das sind so die klassischen und die getypten, das sind so die Objektspeicher. Wie gesagt, es hat sich nicht so wirklich durchgesetzt, wenngleich der SQL-Standard das seit Langem enthält.
Und das hat im Wesentlichen Performancegründe. Relationale Systeme sind eben inzwischen so schnell, dass objektorientierte Systeme bis heute nicht mithalten können. Und auch andere Entwicklungen, also insbesondere die sogenannten NoSQL-Systeme, die neueren Systeme, auch die, die ja zum Teil eben genau entwickelt worden sind, um Big-Data-Probleme anzuhaben, also um mit großen Datenbeständen umzugehen, auch die tun sich zum Teil in der Performance schwer.
Jetzt haben wir schon einen Riesensprung gemacht und ich weiß, dass noch ganz viel vor uns liegt. Das Schlagwort Big-Data liegt noch vor uns. NoSQL oder NoSQL hast du schon kurz angetippt.
In-Memory müssen wir noch touchieren und so weiter und so fort. Ich habe meinen Zuhörern versprochen, ich bleibe immer bei so plus minus einer halben Stunde, was wir jetzt erreicht haben. Ich möchte dich aber einladen, direkt da in der nächsten Woche nochmal anzuschließen und ein bisschen in die Neuzeit der Datenbanksysteme zu gehen, was nicht heißt, dass das, worüber wir jetzt gesprochen haben, veraltet ist, sondern es lebt ja weiterhin.
Aber es ist natürlich ganz, ganz viel dazugekommen. Wenn du magst, lade ich dich herzlich ein, dass wir in der nächsten Woche direkt da anschließen und nochmal so ein bisschen in das schauen, was sich seitdem auch entwickelt hat in den letzten 10, 20 Jahren. Ja, gerne.
Das können wir gerne machen. Dann danke ich für heute, sag den Lesern oder Hörern vielmehr eine schöne Restwoche und wir hören uns in der nächsten Woche wieder. Vielen Dank.
Ihnen hat der ERP-Podcast gefallen und Sie konnten wertvolle Erkenntnisse gewinnen? Dann würde ich mich über eine Bewertung auf iTunes freuen, damit auch andere von diesem Podcast erfahren können. Eine Anleitung für die Bewertung finden Sie auf www.erp-podcast.de Dort finden Sie auch weitere Hinweise, Links und Aktualisierungen zu dieser Folge. Das war der ERP-Podcast für alle, die sich aktiv mit dem Einsatz und der Gestaltung von Unternehmenssoftware und den daraus entstehenden Veränderungen und Potenzialen in Unternehmen losgelöst von Fachzeitschriften, Büchern und wissenschaftlichen Veröffentlichungen, zum Beispiel beim Spazierengehen oder Autofahren, auseinandersetzen wollen.
Mein Name ist Axel Winkelmann. Ich bin Professor für Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität Würzburg.