JSON

JSON Daten verstehen…

Daten im JSON Format verstehen. Wieso, weshalb und wie — eine Einführung!

Henrik Massow
9 min readDec 27, 2019

Kürzlich brauchte ich beruflich die Besteuerungsgrundlagen für einige Investmentfonds. In den letzten Jahren bin ich diesen Informationen oft tagelang hinterher gerannt, bekam dann gescannte PDF-Dateien, musste diese dann abtippen und und und…

Irgendwie kam mir dann dieses Jahr eine “verwegene” Idee!

He, Henrik, dachte ich, wir schreiben das Jahr 2019, immerhin sind 50 Jahre seit der Mondlandung vergangen, wir alle reden von Digitalisierung, wo soll eigentlich das Problem sein, versuch’ doch mal die Daten in maschinell verarbeitbarer Form anzufragen.

Dann könnte ich die Daten in Power BI, Alteryx oder weiß Gott welchen Tools verarbeiten.

Tja, so dachte ich! — Und schrieb dann gleich noch: “Die Daten können Sie uns gern als csv, txt oder als JSON-File übermitteln…”.

Ich ging ehrlicherweise davon aus, dass dies nun wirklich keine absolut verrückte Sache wäre, schließlich müssen die Fonds-Verwalter die Daten ja auch in Steuererklärungsformulare eintragen und werden dies kaum per Schreibmaschine tun.

Es gibt also elektronische Daten und es gibt eine Struktur (sei es nur die Seiten- und Zeilennummer des jeweiligen Vordrucks) und es gibt den dazugehörigen Wert…

Doch leider habe im Anschluss an meine Anfragen wieder mal etwas gelernt. Etwas erschreckendes über unser Land der Dichter, Denker und Erfinder. Ich frage mich wirklich, wie ein Land auf diesem Niveau Jahr für Jahr Exportweltmeister werden???

Wie kann es sein, dass zwar in allen Häusern von Produktivität und Digitalisierung gesprochen wird, es gleichzeitig aber als best practise Ansatz gilt, dass Daten von einem System ins Nächste durch Werkstudenten übertragen werden und das Ergebnis der Bearbeitung dann per PDF übermittelt wird, damit auch der Nächste wieder einen Werkstudenten mit dem Abtippen der PDF beschäftigen kann… 👿

Wie kann es sein, dass wir alle immer mehr mit digitalen Daten arbeiten und uns gleichzeitig die Entscheidung über Art der Ablage, Struktur und des Transports unserer Daten aus der Hand nehmen lassen und irgendwelchen Nerds überlassen? Wie kann es sein, dass wir keine Ahnung von unseren Werkzeugen haben?

Let’s talk about data

Ich möchte daher im Folgenden einfach mal ein wenig über die gängigsten Datenformate schreiben und insbesondere das JSON-Format für IT-Laien vorstellen…

Strukturierte Daten

Aus meiner Sicht gibt es keinen Grund, dass wir Daten heutzutage noch von Werkstudenten abtippen lassen (müssen). Daten sollen einfach strukturiert transportiert werden,

  • möglichst schlank,
  • möglichst lesbar für Menschen,
  • möglichst universell verwendbar.

Das Zauberwort ist hier: Struktur. Um Daten automatisiert zu verarbeiten, brauchen wir Algorithmen, die mit den Strukturen umgehen können. Denn letztlich geht es einem Computer nicht anders, als uns Menschen: Mit einem wirren Zeichensalat auf einem Schmierzettel können wir nichts anfangen, mit einem Text, einer Tabelle oder einer Codierung geht es hingegen sehr gut.

Die Struktur kann hochgradig komplex oder absolut trivial sein, entscheidend ist, wir brauchen eine Struktur.

TXT und CSV

Im Laufe der Zeit sind daher viele Ideen entwickelt worden, um Daten strukturiert ablegen und transportieren zu können.

Wir alle haben schon mal TXT oder CSV Dateien gesehen. Hier einige Beispiele (mit Fake-Daten):

Semikolon als Trennzeichen
Komma als Trennzeichen
Tabulator oderLeerzeichen als Trennzeichen

Die vorgezeigten Methoden haben durchaus ihre Vorteile.

  • Eine Textdatei zeilenweise zu beschreiben ist in nahezu jeder modernen Programmiersprache sehr einfach und effektiv umsetzbar.
  • Eine Textdatei zeilenweise zu lesen ist ebenfalls nahezu in jeder modernen Programmiersprache mit wenigen Zeilen möglich und kann selbst bei riesigen Datenmengen durchaus performant gelöst werden.
  • Derartige Dateien sind (mehr oder weniger gut) für Menschen lesbar.
  • Diese Dateien haben kaum Ballast, d.h. bis auf die Trennzeichen, ist jede Zahl und jedes Zeichen tatsächlich auch Teil unserer Daten.

Gleichzeitig geht diese Art der Datenspeicherung durchaus mit erheblichen Nachteilen einher.

So gibt es in der Praxis keinen echten Standard. Es existieren schier unendliche Varianten von Trennzeichen: Komma, Semikolon, Tabulator, ein oder zwei Leerzeichen, Bindestriche…

Auch die Zeichen für einen Zeilenumbruch (die wir in der Regel nicht sehen) können je nach System (Windows vs. UNIX) unterschiedlich sein und zu einigem Kopfzerbrechen führen.

Der für mich wesentlichste Nachteil ist aber, dass wir auf diese Weise kaum eine Chance haben, verschachtelte (hierarchische) Daten auf einfache Weise abzulegen. So etwas geht in Tabellenform nur, wenn entweder die Anzahl der verschachtelten Daten vorher bekannt ist, indem dann zusätzliche Spalten hinzugefügt werden oder, falls die Anzahl nicht bekannt oder sehr groß ist (1:N Beziehungen), dadurch dass durch Normalisierung der Daten, mehrere Tabellen (Dateien) mit Verweisen aufeinander erzeugt werden.

XML

Ja, ich weiß, mit XML kann man so wahnsinnig toll hierarchische und verschachtelte Daten beschreiben, Schemata vorgeben und Validierungen ermöglichen… blablabla

Sehen wir uns eine XML-Datei der oben verwendeten Daten an.

Was für ein sinnloser Friedhof unnützer Zeichen!

Wir haben die Größe der Datei mal eben um 300% erhöht, obwohl wir die gleichen Daten transportieren. Und wirklich lesbar für Menschen ist dies auch nicht mehr und wir haben noch nicht mal stark verschachtelte Daten. 😆

Das schlimmste an XML-Dateien ist aber, dass es nicht nur Tags (<irgendwas></irgendwas>) gibt, sondern die Tags auch noch Attribute enthalten können.

Was ist also die richtige Vorgehensweise?

Ohne Attribut:

<Adresse>
<AdressType>Postfach</AdressType>
<AdrZeile1>Weihnachtsmann</AdrZeile1>
<Postfach>100</Postfach>
<PLZ>00000</PLZ>
<Ort>Nordpol</Ort>
</Adresse>

Oder mit Attribut:

<Adresse AdressType="Postfach">
<AdrZeile1>Weihnachtsmann</AdrZeile1>
<Postfach>100</Postfach>
<PLZ>00000</PLZ>
<Ort>Nordpol</Ort>
</Adresse>

Linus Torvalds hat meines Erachtens alles zu XML gesagt, was man zu XML wissen muss.

“XML is crap. Really. There are no excuses. XML is nasty to parse for humans, and it’s a disaster to parse even for computers. There’s just no reason for that horrible crap to exist.”
– Linus Torvalds, 2014

“XML ist Mist. Ja wirklich. Es gibt keine Ausreden. XML ist für Menschen schlecht zu analysieren, und selbst für Computer ist es eine Katastrophe. Es gibt einfach keinen Grund dafür, dass dieser schreckliche Mist existiert.”
– Linus Torvalds, 2014 (Übersetzung durch Autor)

So, das Einzige, was Sie an dieser Stelle zu XML mitnehmen müssen daher:

Wann immer Sie in einem Projekt stecken und Ihnen will jemand mit XML kommen: Wenn möglich, verhindern Sie es!

Notfalls schreiben Sie sich das Zitat von Linus Torvalds auf und bringen Sie es!

JSON

Ein ziemlich coole Alternative ist JSON. An dieser Stelle lohnt es sich, aus der deutschen Wikipedia zu zitieren:

Die JavaScript Object Notation (JSON) ist ein kompaktes Datenformat in einer einfach lesbaren Textform und dient dem Zweck des Datenaustausches zwischen Anwendungen. […] JSON wird zur Übertragung und zum Speichern strukturierter Daten eingesetzt. Es dient als Datenformat bei der Datenübertragung (Serialisierung). Insbesondere bei Webanwendungen […] wird es […] zum Übertragen von Daten zwischen dem Client und dem Server häufig genutzt. — Wikipedia

Wenn etwas für Webanwendungen taugt, wo es um schnelle Übertragung geht, dann kann es für sonstige Datenanwendungen nicht schlecht sein, oder?

Wie sieht das JSON-Format nun also aus? Hier ein Beispiel unser obigen Daten.

Da es sich bei Datensätzen im JSON-Format grundsätzlich um gültige JavaScript Objekte handeln soll, beginnt und endet jedes Objekt mit einer geschweiften Klammer {} .

Jedes Objekt (wenn es nicht ausnahmsweise leer ist) besteht auf beliebig vielen Name/Wert-Paare. Der jeweilige Schlüssel/Name muss immer eine Zeichenkette sein, also mit Anführungszeichen beginnen und enden.

Der Wert kann hingegen verschiedene Formate annehmen. Zwischen Schlüssel und Wert liegt stets ein Doppelpunkt : und Name/Werte-Paare werden durch Komme ( , ) getrennt.

{"Name":"Lehmann", "Vorname":"Klaus", "Alter":45, "Gehalt":1500.47 }

Als Werte sind die folgenden Datentypen möglich:

  • Zeichenketten (“ABCD”)
  • Zahlen (z.B. 154 oder 154.23 oder 0 oder 0.05)
  • null (steht nicht für 0, sondern für die Abwesenheit eines Wertes)
  • true/false
{ 
"Name":"Lehmann",
"Vorname":"Klaus",
"Alter":45,
"Gehalt":1500.47,
"Ehefrau":null,
"HatEinAuto":true,
"HatEineImmobilie":false
}

Weiterhin können Objekte beliebig geschachtelt werden, d.h. auch Objekte können Werte eines Schlüssel/Wert-Paares sein.

{ 
"Name":"Lehmann",
"Vorname":"Klaus",
"Alter":45,
"Gehalt":1500.47,
"Ehefrau":null,
"HatEinAuto":true,
"HatEineImmobilie":false,
"Hund":{
"Name":"Bello",
"Rasse":"Golden Retriever",
"hatSchonMalGebissen":false,
"Hütte":{
"GrößeInQm":2.15,
"Material":"Holz",
"Winterfest":false,
"Marke":"Eigenbau"
}
}
}

Mehrere Datentypen und Objekte können in einem Array (vulgo: Liste) zusammengefasst werden. Ein Array beginnt und endet mit einer eckigen Klammer [], als Trennzeichen dient ein Komma (,).

[{},{},{}]    Array mit drei leeren Objekten

Hier noch mal ein komplexeres Beispiel.

{ 
"Name":"Lehmann",
"Vorname":"Klaus",
"Alter":45,
"Gehalt":1500.47,
"Kinder":[ // Array/Liste von Kindern
{
"Vorname":"Marie",
"Name":"Lehmann",
"Mutter":{ ... }
},
{
"Vorname":"Georg",
"Name":"Müller",
"Mutter":{ ... }
}
],
"HatEinAuto":true,
"HatEineImmobilie":false,
"Hund":{
"Name":"Bello",
"Rasse":"Golden Retriever",
"hatSchonMalGebissen":false,
"Hütte":{
"GrößeInQm":2.15,
"Material":"Holz",
"Winterfest":false,
"Marke":"Eigenbau"
}
},
"Lottozahlen":[ 1, 23, 26, 34, 42, 44 ] // Array/Liste von Zahlen
}

Einschub:

Wir können mit JSON auch Bilder hin und her schicken. Nicht perfekt performant, aber es geht. Nämlich als Base64 codierte Zeichenkette.

{"imgLink": "9j/4AAQSkZJRgABAQAAAQABAAD/4QCORXhpZgAASUkqA
[.....]
IKo9jW4C2GoALtRbELIvTcuwgjOoedU0lsNYiXUDag/moegm11H6jEHxP09pDBHE5EEBWZrNlpQR5aD2c27uOBwMNxZnzswrUQADGEBsenSCRWxGrSQKrUrHDnV5pAg0ivKUr5o39ZBBOnux3C6rNNuRi0UF85mImzWVy0RqNJHeRvzWqppB/ykFgt1VHb3r2azm4tzp4uh79v8Avj5Z/Tz6gaAPFEe/0P8Arh54rKj+7/vbDXk0dNcE/wA/t+mIQbWKuRVgH7X/AHeFhyCaPNqfqK5+x4o3iQy3dm6qx7+4/wC+Icnzbcdh/t9sEQSyaTR79/fCsvsa7HY/bE3O5bUQBwtAH3J3/wBdvthlz2obWb2sn2v2Hb9cQJDXkcgDi9+32xHKdtxfNd8S4JzuLO4v6bf84RmplJ9Ir/nEIxzMGwPeq/Tt+uIcymz9cSAhwgg4tETI/kYTX88SVYfXHBv2wRbkPQxAqSTxX9TWGYxz/r/fv2xxl2+n9McQVt7/AO2BB5H/2Q=="
}

Dieser, in Wirklichkeit hunderte Zeilen lange, Zeichensalat wird tatsächlich von jedem Browser zu diesem wunderschönen Bild dekodiert.

Hafen von Warnemünde — Henrik Massow

Warum JSON?

Nach diesem kurzen Einschub und nachdem wir geklärt haben, was JSON kann und wie JSON funktioniert, bleibt noch die Frage offen: warum JSON?

O.K. im Gegensatz zu reinen CSV bzw. TXT-Dateien können wir mit JSON sehr einfach hierarchische Daten abbilden. Das ist aus meiner Sicht ein erheblicher Vorteil!

Der Preis dafür ist, dass wir es dann mit nicht normalisierten Daten zu tun haben, wobei viele CSV bzw. TXT-Dateien die ich gesehen habe, auch nicht gerade besonders normalisiert waren, denn oft sind sie ja das Ergebnis von JOIN-Abfragen also eines klassischen Denormalisierungs-Prozesses.

Wir können in JSON aber ohne weiteres auch ein relationales Modell bauen (siehe folgender Kasten), so dass der Nachteil leicht wieder ausgeglichen werden kann, hier zeigt sich der zweite Vorteil von JSON: — JSON ist unglaublich flexibel.

{"Abteilungen": [
{"id":1, "name":"IT", "Boss":"Stromberg"},
{"id":2,"name":"Accounting", "Boss":"Prof. Boerne"}
],
"Mitarbeiter":[
{"name":"Lehmann", "Abteilung": 1},
{"name":"Schulze", "Abteilung": 1},
{"name":"Schmidt", "Abteilung": 2},
]}

Den zweiten Preis den wir zahlen, ist eine erhöhte Dateigröße. Dies liegt daran, dass wir nun nicht mehr einfach einen Tabellenkopf haben, sondern den Tabellenkopf im Prinzip in jedem Datensatz wiederholen. Gegenüber XML sind wir aber immer noch im Vorteil, denn dort wird jeder Tabellenkopf sogar noch doppelt geschrieben, als Eröffnungs- und als Abschluss-Tag.

Aber JSON bietet tatsächlich einen riesigen Vorteil. In Nahezu jeder Programmiersprache können wir mit wenigen Zeilen JSON-Daten in bekannte Strukturen der jeweiligen Programmiersprache umwandeln und natürlich wieder zurück!

D.h. selbst wenn Sie an dieser Stelle sagen: Ich kann und will nicht programmieren! Sie werden aber immer jemanden finden, der Ihnen für eine JSON-Datei ein Script schreiben kann.

JavaScript/node.js

Der einzige Code den man sich hier merken muss ist JSON.parse(...) und umgekehrt, um aus einem Array oder einem Objekt einen JSON-String zu erzeugen: JSON.stringify(...) .

Lesen einer JSON-Datei in Node.js:

const fs = require('fs');let rawdata = fs.readFileSync('MOCK_DATA.json');
let data = JSON.parse(rawdata);
//Fertig, jetzt kommt die Kür, suchen nach einem Mitarbeiter in den //Datenconst employeeOfChoice =
data.find(employee=>employee["last_name"]==='Ferreira');
console.log(employeeOfChoice);

Python

Für die meisten Fälle geht es so…

import jsonwith open('MOCK_DATA.json') as json_file:
data = json.load(json_file)

Für Datenanalysen geht es auch mit der Pandas Bibliothek recht einfach.

import pandas as pddataframe = pd.read_json('MOCK_DATA.json')print(dataframe)

Online-Tools

Im Web gibt es außerdem noch eine Reihe cooler Tools, die JSON-Daten formattieren, strukturieren und umwandeln können.

Eines dieser super Tools ist https://codebeautify.org/jsonviewer.

Nachfolgend nur einige Impressionen, wie wir unsere Daten mit dem Tool per Knopfdruck umstrukturieren und darstellen können.

Fazit

Sollten Sie gelegentlich mit strukturierten Daten arbeiten, was wahrscheinlich ist, dann beschäftigen Sie sich doch ein wenig mit der Art und Weise, wie diese Daten abgelegt und transportiert werden können.

Je mehr wir in unserem täglichen Job mit Daten arbeiten müssen, um so mehr müssen wir auch lernen, mit Datenver- und bearbeitung umzugehen und die Wahl der Datenformate nicht irgendwelchen Nerds zu überlassen.

JSON kann eine gute Alternative zu unterkomplexen csv-und überkomplexen xml-Dateien sein.

Dann können übrigens auch Werkstudenten wieder sinnvolle Tätigkeiten ausführen, statt Daten abzutippen.

--

--

Henrik Massow
Henrik Massow

No responses yet