XML Daten in eine relationale Table umwandeln

Das interessante an der Konvertierung von XML Dateien in eine relationale Tabelle ist die Vorgehensweise, die aus einer dreidimensionalen Repräsentation der XML Datei eine zweidimensionale Repräsentation erstellt.

Normalerweise ist es üblich sich XML Dateien als zweidimensionalen Baum vor zu stellen, wie es im Document Object Model (DOM) der Fall ist. Dabei bilden die Tiefe der Verschachtelungen der Tags (Tag=Kennzeichnung einer Information) die Tiefe des Baumes und die Tags die Knoten des Baumes. Dabei ist zu beachten, dass der gleiche Tag mehrmals auf einer Ebene vorkommen kann. Betrachtet man diese Wiederholung der Tags als einen Datensatz, so entsteht eine dreidimensionale Darstellung. Zusammengefasst bedeutet dies: die erste Dimension ist die Verschachtelungstiefe, die zweite sind die Tagbezeichner pro Ebene (Knoten im Baum) und die dritte Dimension sind die Datensätze pro Tag (Wiederholungen eines Tags). So ist es zum Beispiel üblich Qualitätsberichte von Krankenhäusern in XML Dateien zu speichern. Dabei wird in der zweidimensionalen Baumstruktur der Tags die Art der Information unterschieden und in der dritten Dimension die Datensätze gespeichert. Die Art unterscheidet sich zum Beispiel durch unterschiedliche Leistungsstellen und Zusatzinformationen, wie der Adresse des Krankenhauses.

Die Schwierigkeit besteht nun darin, aus der hierarchischen Struktur eine zweidimensionale Tabelle zu erstellen. Dabei ist die Herausforderung, automatisch fest zu stellen, an welcher Stelle sich ein Datensatz, d.h. eine Reihe der Tabelle, befindet. Nimmt man an, das ein Datensatz auf der zweit tiefsten Ebene im Hierarchiebaum endet, da die Daten auf der tiefsten Ebene liegen und somit eine Ebene höher ausreichend wäre um den Datensatz zu kennzeichnen, so geht die Strukturierungsmöglichkeiten der Datensätze in unterschiedliche Zweige des Baumes verloren. Vielmehr sind diese Strukturierungsmöglichkeiten notwendig, um Daten-Objekte, wie sie üblich sind, zu Repräsentieren. Die Schwierigkeit steigert sich unter der Berücksichtigung, dass ein Datensatz in einem Datensatz liegen kann. Zum Beispiel können in einem Baum mehrere Abteilungen enthalten sein, welche jedoch unterschiedliche Datensätze der Krankheitsarten beinhalten.

Ein Lösungsansatz ist die Wiederholung der Tags pro Datensatz als Kennzeichen für den Beginn eines Datensatzes zu verwenden. Das Erstellen "Einer" Tabelle ist damit nicht möglich. Jedoch ist es möglich zu erkennen, an welchen Stellen die Tabellen sich befinden, denn Verschachtelungen der Tabellen können hiermit erkannt werden. Der tiefste Datensatz in der Verschachtelung ist dabei derjenige, dessen Tags sich zuerst wiederholen. Der äußerste Datensatz ist dann der Baum selbst.

Mein naiver Ansatz eines Algorithmus ist das „Sammeln“ der Tags. Es wird dabei mit Depth-First durch den Baum gelaufen und die Werte der in Frage kommenden Tags gesammelt. Beim Sammeln wird eine Liste mit relevanten Tags gefüllt. Wird ein Tag im Baum gefunden, welcher in der Liste schon einen Wert enthält, so werden die Werte aller bisherigen Tags in der Liste ausgegeben und gelöscht.

Diese Programmiererfahrung hat mir dazu beigetragen, die Struktur und die Möglichkeiten der Datenspeicherung in einer XML Datei zu erkennen. Vielleicht erging es Euch genauso.

Viele Grüße von Sebastian

Warum dynamic_cast?

Nach reiflicher Überlegung, und dazu gehört auch dieser interessante Fall der Separierung von Daten und Algorithmen, welcher kontrovers zum OOP Paradigma (Daten und Methoden zu vereinen) steht und in der rechten Abbildung dargestellt ist, bin ich darauf gekommen, dass dynamic_cast in erster Linie zur Einschränkung des Polymorphismus sinnvoll ist. Dies verschiebt logische Fehler in die Compile-Zeit.



Hier kennzeichnet sich auch der wichtigste Unterschied zwischen Template und Polymorphismus ab. Templates bleiben vollständig typisiert zur Compile-Zeit.

Außerdem ist mir in diesem Zusammenhang mit Hilfe von Claudius aufgefallen, dass der Polymorphismus ein Werkzeug zur untypisierten Programmierung ist. In diesem Sinne ist daher der dynamic_cast eine Wiederherstellung der typisierten Programmierung. So ermöglicht C++ eine erstrebenswerte Freiheit der Programmierung mit spezifischen und unspezifischen Typen. Dies Variationsmöglichkeit sollte/ist die optimale Lösung in der Frage Pro/Contra un-/spezifischen Datentypen. Jetzt liegt es nur noch am Programmierer sich einen unspezifischen Datentyp mit Hilfe des Polymorphismus zu erstellen. Man denke dabei einfach an den + Operator, welchen es schon bei Strings und bei Floats gibt. Wir nehmen dann das Werkzeug des Polymorphismus und erstellen uns ein Objekt, welches String und Float intern verwaltet und schreiben noch einen entsprechenden + und = Operator für diese verwaltende Objekt. Schon haben wir das Objekt, welchem sowohl Strings als auch Floats zugewiesen werden könne.


Ist PHP nicht eigenlich mit einer typisierten Programmiersprache geschrieben worden?

==> Resumee / Regel

der beiden Fragen "Warum Templates vs. Polymorphismus?" und "Warum dynamic_cast?"

Verwende Templates bei Algorithmen, welche um eine Funktionalität erweitert werden oder mit unterschiedlichen Datentypen arbeiten sollen.
Verwende Polymorphismus, wenn das OOP Paradigma bestehen bleibt. D.h. die Daten und der Algorithmus nicht getrennt werden. Die Algorithmen sind dann nur spezifisch für diese Daten.
(Nebenbei: die Frage der Responsibility bleibt unverändert. Die Objekte sind für das Laden und Löschen der Daten aus dem Speicher verantwortlich.)

--
Grüße

Warum Templates & Iterators statt Polymorphismus?

Contra:

• Die Templates der Iteratoren machen den Code komplizierter.
  
• Befinden sich Templates in Libraries, muss länger kompiliert werden. Zudem muss der gesamte Code zur Verfügung stehen.
  

Pro:

• Es ist bei Verwendung von Iteratoren nicht notwendig eine Basisklasse zu verwenden, welche die gesamte Funktionalität der abgeleiteten Klasse abbildet. D.h. das umständliche erweitern der Basisklasse entfällt bei Iteratoren.
  
• Code ist schneller, da keine Table-look-ups notwendig sind.
  

Mir ist noch unklar, weshalb es wirklich Sinn macht, diese zusätzliche Programmiersprache "Templates" in der Programmiersprache zu haben. (Es heißt, Templates haben die Funktionalität einer Programmiersprache.)

Vielleicht wird es bei der nächsten Frage ersichtlich.

--
Grüße