Herr Professor Grust, als Juror von "Germanys Next Database Award" 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.
Datenbanken beinhalten häufig irrelevante Informationen
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.
Germanys Next Database Award: Jetzt bewerben!
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.
Bewerbungsschluss ist Freitag, der 16. April 2010.
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össer - oder auch kleiner - sind.
Worauf sind 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 grosses Potential 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: EineDatenbank, 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, zugegebenermassen, eine gewisse Übung. Der resultierende Applikationscode ist aber oft kompakter und so gut wie immer deutlich effizienter.
Die fünf größten Fehler
Welches 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. Stattdessen bestehen die Dokumentationen aus einer Unmenge an SQL-DDL-Statements, die die Struktur der Datenbank nur unzureichend wiedergeben.
One-Fits-All-Modelle werden verschwinden
Bei den Datenbankmodellen sind die 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 stattdessen 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. (mec)