Herr Professor Grust, als Juror für den Award "Germanys Best Database Project" die Frage an Sie: Wo liegt das Besondere an dieser Auszeichnung?
Grust: Das Thema Datenbanken wird in den meisten Unternehmen oft als Nebensache betrachtet, sozusagen als Pflicht, während große Projekte etwa zur IT-Infrastruktur als Kür gelten. Dabei ist der Aufbau einer effizienten Datenbank eine hochkomplexe und spannende Aufgabe, die viel technisches Know-how erfordert. Die Technologie hinter Datenbanksystemen erfährt in der IT vielleicht nicht genug Wertschätzung. Sie ist eine Teilwelt, die mehr Aufmerksamkeit verdient. Der Award kann einen Teil dazu beitragen.
--------------------------------------------------------------------------
Germany's Next Database Award: Frist verlängert - bewerben Sie sich bis zum 23. April 2010
Sie haben für Ihr aktuelles Datenbankprojekt innovative Technologien eingesetzt? Sie haben Herausforderungen im laufenden Projekt dennoch pragmatisch gelöst? Und Sie konnten so ein Datenbankprojekt umsetzen, das eine strategische Bedeutung für das gesamte Unternehmen hat?
Dann bewerben Sie sich jetzt für Germanys Next Database Award. Der Wettbewerb richtet sich an Projektleiter ebenso wie an CIOs aus mittelständischen und Großunternehmen. Hintergrundinformationen zu Bewerbung, Jury und Vergabe finden Sie unter http://www.computerwoche.de/databaseaward2010.
Der Bewerbungsschluss ist am 23. April 2010.
--------------------------------------------------------------------------
Was zeichnet eine technologisch ausgereifte Datenbank aus?
Grust: Ein Datenbanksystem besteht von seiner Struktur her aus zwei Schichten: Einer konzeptuelle Schicht als Träger der Applikationen und einer physischen, system-nahen Schicht. Beide Schichten müssen klar voneinander getrennt sein, damit spätere Anpassungen am System ohne Folgen für die Applikationsschicht sind.
Die konzeptuelle Schicht sollte zudem einer adäquaten Modellierung der modellierten Mini-Welt entsprechen, das heißt sie sollte nur den relevanten Ausschnitt der gesamten Datenwelt innerhalb eines Unternehmens abbilden. Tatsächlich beinhalten Datenbanken aber häufig irrelevante Informationen oder vernachlässigen relevante Daten.
Entsprechendes gilt dann auch für die physikalische Schicht. Sie muss sich am Applikationsprofil, also den tatsächlich auftretenden Anfragen und Datenmengen, orientieren. Häufig ist die Hardware stattdessen darauf ausgerichtet, Datenvolumen zu bewältigen, die in der Realität dann oft deutlich größer - oder auch kleiner - sind.
Worauf sind diese Fehler zurückzuführen?
Grust: Ich denke ein Grund für unsauber strukturierte Datenbanken liegt bisweilen darin, dass Entwickler dem Datenbanksystem nur bis zu einem gewissen Grad Selbstständigkeit zugestehen wollen. Man möchte am Ende die Kontrolle über die Prozesse und Daten nicht abgeben - das ist schade, denn so bleibt ein großes Potenzial von Datenbankfunktionalität ungenutzt.
Mehr als nur reine Datenhaltung
Was bedeutet das für die Arbeitsweise einer Datenbank?
Grust: Datenbanksysteme arbeiten mengenorientiert, das heißt sie verarbeiten die Daten nicht Schritt für Schritt, sondern generieren Mengen gleichartiger Antworten, was wesentlich effizienter ist. So geschieht die Datenverarbeitung wirklich in der Nähe der Daten. Generell gilt: eine Datenbank kann mehr leisten als nur die reine Datenhaltung. Applikationsentwickler sollten das Datenbanksystem stärker in seiner Funktion als Datenprozessor wahrnehmen.
Und welche Vorteile bringt diese Arbeitsweise?
Grust: Eine Datenbank, die derart mengenorientiert arbeitet, ermöglicht unter anderem eine wesentlich effizientere Kommunikation. Der Roundtrip - die Zeit vom Absenden einer Anfrage bis zum Erhalt der Antwort - ist deutlich schneller und ist deutlich seltener notwendig. Das spart nicht nur Zeit, sondern auch Energie. Dasselbe gilt für die Architektur der konzeptuellen Schicht: Bei einer hohen Anzahl von Applikationen, kommen die vielen notwendigen Kontextwechsel zwischen den Applikationen und dem Datenbanksystem teuer zu stehen. Auch die Entwicklung der Datenbankapplikationen selbst profitiert übrigens, weil mengenorientierte Abfragen oft viel natürlicher zu formulieren sind. Die Formulierung mengenorientierter Anfragen bedarf, zugegebenermaßen, eine gewisse Übung. Der resultierende Applikationscode ist aber oft kompakter und so gut wie immer deutlich effizienter.
Was sind die häufigsten Fehler, die bei Datenbankprojekten gemacht werden?
Grust: Es gibt wenigstens die folgenden fünf Aspekte, die ein Datenbankprojekt beeinträchtigen können:
Ein Problem ist die Repräsentation von Daten in Form von so genannten BLOBs (Binary Large Object Blocks), die beliebige Applikationsobjekte aufnehmen können. Die interne Struktur eines BLOBs bleibt der Datenbank allerdings verborgen, was die Anfrageverarbeitung ineffizient macht: das Datenbanksystem kann den BLOB-Inhalt lediglich unreflektiert reproduzieren. Die verwendete Datenbanktechnologie muss genauer auf die Struktur der Applikationsobjekte abgestimmt werden.
Funktionen des Datenbanksystems, wie die Rollenverwaltung oder Integritätstests, werden in der Applikation nachgebaut. Sie gehören aber in die Nähe der Daten.
Die Applikationsschicht betreibt das Datenbanksystem lediglich als passiven Datenbankspeicher. Die Leistungsfähigkeit des Anfrageprozessors wird nicht ausgenutzt.
Weiterhin ist es problematisch, ein Datenbanksystem auszuwählen, dessen Datendarstellung nicht zu den Daten des Projektes passt. In solchen Fällen wir dann häufig mit aufwändigen und verlustbehafteten Konvertern gearbeitet.
Bisweilen fehlen Dokumentationen über die Abbildung der modellierten Mini-Welt. Statt dessen bestehen die Dokumentationen aus einer Unmenge an SQL-DDL-Statements, die die Struktur der Datenbank nur unzureichend widergeben.
One-Fits-All-Modelle werden verschwinden
Bei den Datenbankmodellen sind relationale Datenbanken immer noch state-of-the-art - zu Recht?
Grust: Ja absolut, relationale Datenbanksysteme sind schon seit 35 Jahren tonangebend. Sie haben den Nerv getroffen zwischen theoretischer Handhabbarkeit und realitätsnaher Abbildung der Mini-Welten - weswegen sie auch heute noch aktuell sind. Relationale Datenbanksysteme der neuen Generation realisieren aber spezifische Erweiterungen. Diese sorgen dafür, dass auch andere Datentypen wie etwa XML oder Time Series Daten (zum Beispiel Tickerdaten von der Börse) verarbeitet werden können. Mithilfe anderen Erweiterungen sind Datenbanken in der Lage, neue Typen von Anfragen zu verstehen, wie sie typischerweise in Datawarehouse-Anwendungen auftreten.
Und wie sieht die Datenbank der Zukunft aus?
Grust: Die relationalen Datenbanken werden nicht verschwinden. Verschwinden werden voraussichtlich die One-Size-Fits-All-Modelle, bei denen ein Hersteller mit seinem Datenbankmodell alle Anwendungsfälle abecken möchte. Künftig werden statt dessen spezifischere Datenbanksysteme mithilfe von Erweiterungen dem einzelnen Anwendungsfall besser gerecht. Ein Beispiel dafür sind Main Memory Databases, die für eine bessere Ausnutzung des RAM sorgen oder Column Databases, die effizienter mit Datawarehouse-Anfragen umgehen können. Eine weitere Entwicklung wird die deutlich engere Integration von Datenbanksystemen und Programmiersprachen sein wie es beispielsweise Microsoft LINQ propagiert. In diesem Bereich gibt es gerade ein regelrechtes Momentum.