Strukturierte Daten

Jan Burse, erstellt 17. Okt 2011 Jason brauchte ein Schiff, um das Ende der Welt zu erreichen, bei seiner Suche nach dem Goldenen Vlies. Heutzutage benötigen wir Behälter um Daten zu verschiffen. Relationale Datenbankverwaltungssysteme liefern uns nicht solche Behälter da die erste Normalform skalare Spaltenwerte impliziert. Würden wir uns strikt an die erste Normalform halten, so hätten wir mit einigen Einschränkungen bei der Realisierung und Wartung unseres Verkaufssystems zu rechnen. Die Schwierigkeit besteht darin einen Lösung zu finden die sich leicht mittels des JDBC Standard auf verschiedene Datenbankverwaltungssysteme übertragen lässt. Was macht das Datenbankdesign gemäss erster Normalform ineffizient? Das Beispiel auf das wir gestossen sind besteht aus einer kleinen List von MwSt. Zusammenfassungen die an jeden Auftrag angehängt werden. Die erste Normalform würde uns dazu zwingen die kleine Liste auf eine neue Tabelle zu verteilen die dann mit dem Bestellzettel über einen Fremdschlüssel verknüpft werden würde. Auf den Auftrag mit den MwSt. Zusammenfassung zuzugreifen würde zusätzliche Verbundoperationen bedingen. Die bessere Lösung wäre die Benutzung von komplexen Datentypen. Obwohl die JDBC Schnittstelle komplexe Datentypen wie Array und Struct unterstützt, besteht das Problem hier dass diese nicht von jedem Hersteller von Datenbankverwaltungssystemen bereitgestellt werden. Was macht Datenbanken in erster Normalform schwierig zu warten? Im Verkaufssystem besteht der Bedarf Subtypen abzubilden. Betrachten wir z.B. den Begriff eines Kunden. Ein Kunde kann grundsätzlich eine Person oder eine Firma sein. Falls er eine Firma ist können wir geneigt sein den Typ der Firma zusammen mit der Registrierungsnummer zu speichern. Diese Attribute sind bei einer Person nicht verfügbar. Die Theorie der relationalen Datenbanken schlägt verschiedene Methoden zur Modellierung von Subtypen vor. Wir können die Vereinigung der Attribute in einer Tabelle speichern und Gebrauch von Nullwerten machen. Oder wir benutzen eine Tabelle pro Subtyp. Das Resultat wird in beiden Fällen eine Überfrachtung des Datenbankschemas sein. Einige Datenbankverwaltungssysteme liefern eine eigene Unterstützung für Subtypen. Dies reduziert die Überfrachtung des Datenbankschemas jedoch nicht. Die Überfrachtung des Datenbankschemas ist besonders störend da unser Entwicklungsprozess auf der Matula Datenbankschicht basiert. Überfrachtung des Datenbankschemas würde unseren Entwicklungsprozess verlangsamen da die Schicht eine Codegenerierung aus dem Datenbankschema heraus fordert. Wir wären genötigt für jede kleine Erweiterung der Subtypen die Anwendung neu zu kompilieren und neu auszurollen. Wir entschieden uns daher nach Alternativen für die Abbildung von Subtypen und komplexe Objekte durch eine Verteilung über Tabellen zu suchen. Was einem als erstes in den Sinn kommt als Alternative sind XML wertige Attribute. XML ist fähig sowohl komplexe Objekte als auch Subtypen abzubilden. Die Validierung von XML ist ein Schritt der nicht notwendigerweise durch das Datenbankverwaltungssystem durchgeführt werden muss und auch anderswo stattfinden kann, sodass wir eine Überfrachtung des Datenbankschemas vermeiden könnten. Würden wir uns für XML wertige Attribute entscheiden entständen ähnliche Probleme wie mit komplexen Datentypen. Mit der letzten Version von JDBC gibt es auch eine Unterstützung eines XML Datentyps. Aber die mit XML in Zusammenhang stehende Funktionalität innerhalb des Datenbankverwaltungssystems variiert stark von Hersteller zu Hersteller. Ein XML wertiges Attribut würde uns deshalb nicht mehr als einen Typ Namen für zeichenbasierte grosse Objekte (CLOB) liefern. Wie die JDBC Anwendungsprogrammierschnittstelle zeigt wäre es unsere Aufgabe die Methode der Syntaxanalyse und -synthese, beziehungsweise des Musterabgleichs zu wählen. Wir entschieden uns daher für die Idee eines CLOB aber versuchten etwas Anderes bei der Kodierung der strukturierten Daten. Wir starteten mit der Darstellung durch die Methode toString() für die Java Klassen Vector und Hashtable. Aber unsere Entscheidung war keine Anführungszeichen für Zeichenketten zu verwenden. Stattdessen begonnen wir damit XML Entitäten zu benutzen. Wir wechselten auch von den Satzzeichen „=“ und „,“, zu den etwas natürlicheren Satzzeichen „:“ und „;“. Diese CLOBs liefern uns nun verschiedene Vorteile. Unser JSON Format ohne Anführungszeichen reduziert nicht nur den Speicherbedarf. Sie liefern uns auch eine automatisch Unterstützung für die Volltextsuche über mehrere Attributwerte hinweg. Wir durchsuchen den CLOB einfach mit dem gegebene Suchmuster. In den meisten Fällen ist es nicht nötig den Attributnamen im Suchmuster einzuschliessen. Der Grund dafür ist, dass verschiedene Wertebereiche oft auch verschiedene lexikalische Räume besetzten. So wird z.B. selten eine Person nach einer Stadt benannt, sodass eine Suche nach dem Wort „Zürich“ nur Treffer in einen Stadtattribut hat. Auf der anderen Seite liefert eine Suche nach dem Wort „Müller“ nur Treffer in einem Familiennamenattribut. Aber die Methode wäre zu langsam für spezielle Attribute. Für diese Attribute mussten wir zusätzliche Spalten und Indexe in der Datenbank anlegen. Die CLOBs und das JSON Format ohne Anführungszeichen liefert uns weitere Vorteile. Wir können nun das Verkaufssystem direkt zur Laufzeit mit neuen Attributen bestücken. Zu diesem Zweck haben wir einige Tabellen angelegt die der Schemadeklaration für das Verkaufssystem dienen. Die Schemadeklaration macht selber wieder Gebrauch von dem JSON Format ohne Anführungszeichen und erlaubt es uns automatisch Formulare für das Verkaufssystem abzuleiten. Die aktuelle Schemadeklaration ist sehr einfach gehalten. So gibt es z.B. noch keine Typendeklaration für skalare Typen. Wir haben einige Erweiterungen für die Zukunft geplant. Die Darstellung der Daten und die Deklaration des Schemas sind auch Wichtig für unser Ausgabesystem, welches wir in einem späteren Tagebucheintrag behandeln möchten.

Kommentare