Schreibe einen Kommentar

Moderne Werkzeuge für die rechnergestützte Statistik, Teil 2

Statistische Datenauswertung lebt vom Zusammenspiel zahlreicher Kompetenzen, Werkzeuge und Hilfsmittel. In Teil 1 dieses Artikels habe ich skizziert, welchen Anforderungen sich eine Statistiksoftware aus meiner Sicht heute stellen muss. In Teil 2 nun stelle ich verschiedene textbasierte Formate vor, die als Datenquellen eine relevante Rolle spielen.

Textbasierte Datenformate & Auszeichnungssprachen

Daten müssen vor der Analyse in der Regel auf irgendeine Weise aufbereitet, umgeformt und in geeignete(re) Speicherformate überführt werden. Speicherformate spielen auch in den Ausnahmefällen eine Rolle, in denen der Analyst bereits auf die elektronische Erfassung Einfluss nehmen kann. Jeder Arbeitsschritt, der in Handarbeit erledigt werden muss, zieht typische und nur begrenzt kontrollierbare Probleme nach sich (die u.a. mit der Vigilanz, mit Figur-Grund-Problemen und mit sensomotorischen Fehlleistungen zusammenhängen). Bei solchen Aufgaben können wir uns heute allerdings von einer Vielzahl leistungsfähiger und oft kostengünstiger Werkzeuge und Technologien unterstützen lassen. Sobald Daten ins Spiel kommen, arbeite ich nach zwei einfachen Prinzipien: (1) Handarbeit im Umgang mit Daten ist auf ein absolutes Minimum zu reduzieren; (2) maschinelle Verarbeitung der Daten muss so früh einsetzen, wie es das jeweilige Szenario zulässt, und sollte danach nicht mehr unterbrochen werden.

Allerdings korreliert die Umsetzung dieser Regeln zwangsläufig mit dem Kenntnisstand der betrauten Personen. Was für den Geek das Füllhorn der unbegrenzten Möglichkeiten ist, stellt für alle anderen ein Technologie-Labyrinth dar, das in Rekordzeit Symptome von Reizüberflutung und Desorientiertheit auslöst. Dabei lässt sich bereits mit überschaubarem Lernaufwand einiges erreichen – ein wenig strukturierte Orientierungshilfe und Vorsicht vor überzogenen Zielen vorausgesetzt.

Datenquellen sind zwar, wie mehrfach betont, heterogen, aber im Grunde ist es ganz einfach. Eine Datei enthält entweder binäre Daten, dann haben Sie hoffentlich eine Software, mit der sie sich direkt öffnen oder importieren lässt (wenn nicht, bekommen Sie unter Umständen ein größeres Problem). Oder die Daten liegen als reines Textformat vor, dann stehen automatisch immer mehrere Zugriffsmöglichkeiten zur Auswahl. Das impliziert allerdings, dass man die Möglichkeiten und Grenzen der wichtigsten Formate einschätzen kann.

Textbasierte Formate

„Reine Textdaten” werden so bezeichnet, weil sie grundsätzlich nur alphanumerische Zeichen, Satzzeichen und Leerraum enthalten, sonst nichts. Ein paar Beispiele, denen man in der Datenanalyse ständig begegnet:

1. tabellarische Daten fester Breite (durch Leerzeichenketten aneinander ausgerichtete Spalten);
2. tabulator- oder kommagetrennte Daten (Tabulatoren, Kommata oder Semikola als Spaltentrenner);
3. Schlüssel-Wert-Daten (jedes Datenfeld setzt sich aus drei Bestandteilen zusammen: seinem Namen, einem eindeutig definierten Trennzeichen und dem Feldinhalt);
4. strukturierte oder semi-strukturierte Textdaten (die keinem der offiziellen Standardformate folgen, aber irgendein Muster oder eine Regelhaftigkeit erkennen lassen);
5. unstrukturierte Textdaten.

Die Fälle 1 und 2 legen pro Zeile einen Fall ab, in Zeile 1 stehen häufig die Spaltenbezeichnungen, was aber nicht verpflichtend ist. Diese Formate sind die typischen Austauschformate zwischen Tabellenkalkulationen oder Datenbankverwaltungsprogrammen und werden deshalb auch von Statistiksoftware gut unterstützt.

Mit Format Nr. 3 lassen sich Datensätze in sich geschlossen und selbstbeschreibend in einer Datei ablegen (z.B. Exporte aus Online-Literaturdatenbanken), das heißt, selbst ein Fragment aus willkürlich herausgelösten Zeilen ließe sich ohne zusätzliche Information interpretieren, weil jedes Datenfeld immer durch seinen Schlüssel gekennzeichnet sein muss. Auch dieses Format lässt sich zwar prinzipiell gut maschinell verarbeiten, gebrauchsfertigen Im- und Export-Funktionen wird man aber eher selten begegnen.

Eine echte Herausforderung an die eigene Findigkeit und Erfahrung stellen dagegen die Kategorien 4 und 5 dar. Jedes erkennbare Muster kann genutzt werden, um den Inhalt mit einem maßgeschneiderten Parser zu zerlegen und der Weiterverarbeitung zuzuführen. Einen solchen Parser zu schreiben ist zwar nicht immer in ein paar Minuten erledigt, verbraucht aber trotzdem unter dem Strich oft weniger Zeit als eine Datenerfassung von Hand und ist dieser qualitativ in jedem Fall überlegen.

Technisch gesehen gibt es über diese Formate nicht viel zu lernen, alles in allem sind sie relativ trivial. Für manche Anwendungen haben sie sich dann auch als zu trivial herausgestellt – baumförmig verzweigte und verschachtelte Datenstrukturen lassen sich beispielsweise nicht (oder nicht gut) damit abbilden. Für solche Zwecke existieren bessere Lösungen – die Auszeichnungssprachen.

Auszeichnungssprachen

Der wachsende Bedarf an leistungsfähigen, maschinenlesbaren Datenformaten hat mit den Auszeichnungssprachen eine weitere Klasse textbasierter Formate hervorgebracht: syntaktisch strikter, mit komplexeren Ausdrucksmöglichkeiten und damit vielseitiger und robuster. Ich stelle hier ein paar der einflussreichsten Vertreter vor:

1. HTML (HyperText Markup Language): Das Format, vor dem Sie gerade sitzen (bzw. vor dem, was Ihr Browser daraus gemacht hat). HTML hat gewisse Ähnlichkeiten mit einem Schlüssel-Wert-Format. Allerdings beschreiben die Schlüsselelemente hier die Struktur, nicht den Inhalt; das Vokabular ist a priori festgelegt und begrenzt; darüber hinaus sind HTML-Dokumente immer baumförmig.
2.  XML (Extensible Markup Language): Entstammt der gleichen Sprachfamilie wie HTML. Das Vokabular ist im Gegensatz dazu nicht festgelegt, weshalb XML in seinen Ausdrucksmöglichkeiten mächtiger und flexibler ist, bei gleicher Robustheit.
3.  JSON (JavaScript Object Notation): Ursprünglich ein textbasiertes Format zur Beschreibung, Speicherung und Rekonstruktion von komplexen Datenobjekten, das heute auch über JavaScript und Webanwendungen hinaus zum Einsatz kommt. Hat vom Konzept her einige Ähnlichkeit mit XML (Expressivität, Flexibilität, Robustheit), ist aber syntaktisch einfacher gehalten und insgesamt weniger vielseitig.

Diese Formate haben zwei Vorzüge gemeinsam, die auch den Datenanalysten sehr interessieren:

(a) Es lassen sich erstens mehr oder minder beliebig strukturierte Datenspeichermodelle differenziert abbilden, und
(b) zweitens existieren viele ausgereifte Lösungen, solche Daten maschinell zu erzeugen und zu verarbeiten.

Das Schwergewicht und Universaltalent unter den Auszeichnungssprachen ist XML. Etablierte Vertreter von XML-Lösungen sind beispielsweise DocBook (ein Dokumentenformat für technisches Publizieren), MathML (zur Beschreibung mathematischer Formeln und Ausdrücke) und SVG (für Vektorgrafiken in XML). Daneben gibt es unter anderem eben auch XML-Lösungen für statistische Anwendungen (z.B. Triple-S XML, DDI(Vielleicht sollte ich das von Microsoft eingeführte Office-Speicherformat OOXML ebenfalls nicht zu erwähnen vergessen.)

Aus Sicht des (statistischen) Anwendungsentwicklers ergibt sich die Sonderstellung von XML, denke ich, aus der Kombination von zwei Eigenschaften. Die erste ist die Option, mit XML eigene Datenstrukturen so definieren zu können, dass sich die XML-Engine um die Prüfung auf Gültigkeit von Aufbau und Inhalt kümmert. Ich kann mich auf diesem Weg weitgehend von der Notwendigkeit befreien, in der Statistikanwendung haufenweise Validierungscode schreiben oder mögliche Fehler abfangen zu müssen.
Die zweite für mich ausschlaggebende Eigenschaft ist die Möglichkeit, Ablauf und Inhalt einer statistischen Anwendung sauber voneinander trennen zu können. Ein denkbarer Anwendungsfall wäre eine kleine Grafikproduktionsstraße in R, die zwei Serien von Diagrammen erzeugt, die eine in Deutsch, die andere in Englisch, bei ansonsten identischer Datengrundlage und Gestaltung. Der Code würde ausschließlich die Anweisungen zum Erzeugen der Diagramme enthalten (Diagrammtyp, Layout, etc.); im XML könnten beispielsweise der Pfad zur Datenquelle, die benötigten Gruppen lokalisierter Diagrammtitel und Achsenbeschriftungen sowie vielleicht ein Block zur Bemaßung und ein weiterer mit Angaben zum Farbschema abgelegt werden. (Wie weit ich die Abstraktion treiben möchte, entscheide ich selbst.)

Auszeichnungssprachen sind ein gutes Beispiel für die Vorteile der offenen Architektur von R. Auf dem Comprehensive R Archive Network CRAN liegen fertige Erweiterungspakete zur Verarbeitung von JSON, XML und HTML. Wer mehr oder Spezielleres braucht, sollte sich einmal beim Omegahat-Projekt umsehen, Duncan Temple Lang hat in puncto XML eine Menge interessanter Lösungen in Arbeit. Und wenn Sie Appetit bekommen haben – passende Literatur zu dieser reizvollen Materie ist nicht weit entfernt ;-) Möglich, dass Sie noch ein Regal brauchen werden.

Fazit und Feierabend (für heute)

Bei der Fülle an Möglichkeiten drängen sich ein paar Fragen auf. „Muss man das (alles) wissen?” — „Wenn ja – wo beginnen?” — „Wann reicht’s?” Ich versuche, mich kurz zu fassen. Nein, alles muss man nicht wissen und beherrschen. Niemand kann erwarten, dass Sie von jetzt auf gleich zum perfekten XML-Entwickler oder HTML-Spezialisten werden. Es ist aber gut, sich für den Anfang gerade soviel Überblick zu verschaffen, dass man lösungsorientiert vorgehen kann, sobald es darauf ankommt (vielleicht, wenn plötzlich eine Datentabelle im HTML-Format eingelesen werden muss).

Beginnen würde ich persönlich eher mit XML als mit HTML, erstens, weil Ihnen XML vielseitigere Möglichkeiten bietet, und zweitens, weil Sie alles, was Sie über XML lernen, automatisch auf HTML anwenden können, der Umkehrfall gilt dagegen nur mit Einschränkungen. Mit JSON kann man sich bei Gelegenheit einmal nebenbei befassen, und auch hier wird man viele Prinzipien aus XML wiedererkennen.

Aber vielleicht hat ja während der Lektüre bei Ihnen der Blitz der spontanen Begeisterung eingeschlagen, und Sie können sich kaum mehr zurückhalten. Dann geht es Ihnen, wie es mir mal gegangen ist — und ich muss sagen, der Gedanke gefällt mir.

Über den Autor:
Jörg Beyer hat an der Universität Marburg Psychologie studiert, eine intensive Statistikausbildung inbegriffen. Parallel hat er sich im Lauf der Zeit von allerhand cleveren Software-Werkzeugen begeistern lassen, mit denen sich große Datenmengen bewältigen, Routinearbeiten beschleunigen oder ungewöhnliche Aufgaben lösen lassen: Datenbankentwicklung und SQL, reguläre Ausdrücke, verschiedene Skriptsprachen, XML, R,… eine recht lange Liste, die immer in Gefahr ist, noch ein bisschen länger zu werden. Er arbeitet als Statistik-Consultant im Gesundheitswesen und als Übersetzer für wissenschaftliche und IT-Fachliteratur.

Sag's weiter:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert