Übungsaufgaben zu Datenaustauschformaten

Je Möglichkeit 1 Punkt, zum Beispiel:

• Websuche nach „GTFS“ bzw. der Dateiendung,

• Dokumentation oder Spezifikation des Formats lesen (Website des Verkehrsverbunds bzw. des Formats),

• beim Verkehrsverbund nachfragen,

• in Fachforen oder Online-Communitys fragen,

• Fachliteratur oder Handbücher nutzen,

• einen KI-Chatbot fragen und die Antwort an einer verlässlichen Quelle prüfen.

• Textformat: Die Datei enthält nur Zeichen einer Zeichenkodierung (z. B. ASCII oder UTF-8), gegliedert durch Zeilenumbrüche. Sie lässt sich mit jedem Texteditor öffnen, lesen und bearbeiten (2 Punkte).

• Binärformat: Die Datei speichert die Daten im internen Format eines Programms (z. B. Zahlen als Gleitkommawerte, komprimierte Daten). Im Editor erscheint nur Zeichensalat; lesen und verarbeiten kann sie nur ein Programm, das das Format kennt (2 Punkte).

Die ZIP-Datei selbst ist binär (komprimiert); die darin enthaltenen .txt-Dateien sind Textdateien und lassen sich nach dem Entpacken im Editor öffnen.

Je richtige Zuordnung 0,5 Punkte: 1 JPG, 2 ISO, 3 CSV, 4 PDF, 5 TIFF, 6 ZIP.

Es ist eine CSV-Datei mit dem Komma als Trennzeichen und einer Kopfzeile (1 Punkt). Der Name enthält selbst ein Komma; ohne Anführungszeichen würde es als Trennzeichen gelesen, und die Zeile hätte ein Feld zu viel. Die Anführungszeichen kennzeichnen den Wert als ein Feld (1 Punkt).

Eine Möglichkeit genügt (2 Punkte), zum Beispiel:

• Importfunktion der Datenbank nutzen, z. B. LOAD DATA INFILE mit Komma als Trennzeichen und " als Feldbegrenzer oder den CSV-Import eines Verwaltungswerkzeugs,

• ein kleines Skript (z. B. in Python) schreiben, das die Datei liest, die benötigten Spalten auswählt und die Datensätze einfügt,

• ein vorhandenes Werkzeug bzw. einen Konverter für GTFS-Daten verwenden.

Dabei auf die Zeichenkodierung (UTF-8) achten, damit „Gütersloh“ richtig ankommt.

Je Format 2 Punkte (1 Punkt je Merkmal), zum Beispiel:

• CSV (Comma-Separated Values): Textdatei, ein Datensatz je Zeile, Felder durch ein Trennzeichen (Komma, Semikolon) getrennt, meist mit Kopfzeile; flache Struktur ohne Verschachtelung und ohne Datentypen; sehr wenig Overhead.

• XML (Extensible Markup Language): textbasiertes, hierarchisches Format; Elemente mit Start- und Endtag, die Text, Attribute oder weitere Elemente enthalten; genau ein Wurzelelement; prüfbar gegen DTD oder XSD; häufig bei SOAP-Webservices und E-Rechnungen.

• JSON (JavaScript Object Notation): textbasiertes, hierarchisches Format; Objekte in geschweiften Klammern mit Schlüssel-Wert-Paaren, Arrays in eckigen Klammern; eigene Datentypen (String, Number, Boolean, null); kompakt; häufig bei REST-Schnittstellen.

ba) Je Zeile 0,75 Punkte (Kopfzeile und drei Datensätze), 1 Punkt für ein einheitliches Trennzeichen:

beginn;raum;titel;format;livestream
10:00;A.001;KI-Assistenten im Unterricht – was geht, was nicht?;Vortrag;ja
11:00;C.110;Reparieren statt wegwerfen: Laptops retten;Workshop;nein
12:45;B.201;Barrierefreie Videos: Untertitel und Gebärdensprache;Workshop;nein

Mit dem Komma als Trennzeichen muss der erste Titel in Anführungszeichen stehen, weil er selbst ein Komma enthält: 10:00,A.001,"KI-Assistenten im Unterricht – was geht, was nicht?",Vortrag,ja.

bb) 1 Punkt Prolog mit Kodierung, 2 Punkte Wurzelelement, 2 Punkte je Session ein Element, 2 Punkte Daten in Kindelementen (oder Attributen):

<?xml version="1.0" encoding="UTF-8"?>
<sessionplan>
  <session>
    <beginn>10:00</beginn>
    <raum>A.001</raum>
    <titel>KI-Assistenten im Unterricht – was geht, was nicht?</titel>
    <format>Vortrag</format>
    <livestream>ja</livestream>
  </session>
  <session>
    <beginn>11:00</beginn>
    <raum>C.110</raum>
    <titel>Reparieren statt wegwerfen: Laptops retten</titel>
    <format>Workshop</format>
    <livestream>nein</livestream>
  </session>
  <session>
    <beginn>12:45</beginn>
    <raum>B.201</raum>
    <titel>Barrierefreie Videos: Untertitel und Gebärdensprache</titel>
    <format>Workshop</format>
    <livestream>nein</livestream>
  </session>
</sessionplan>

Andere wohlgeformte Strukturen sind ebenfalls richtig, z. B. <session beginn="10:00" raum="A.001" format="Vortrag" livestream="ja">KI-Assistenten …</session>.

CSV hat sehr wenig Overhead: Es enthält außer den Werten nur Trennzeichen und Zeilenumbrüche. Dadurch sind die zu übertragenden Datenmengen klein, die Funkübertragung ist kurz, und der Mikrocontroller kann die Zeilen mit wenig Rechenaufwand und Speicher zerlegen – das schont den Akku (2 Punkte). Da die Sessiondaten flach sind (eine Zeile je Session), braucht es keine Verschachtelung.

Geg.: 52 Zeichen, davon 51 ASCII-Zeichen und ein Umlaut (ä)

Ges.: Speicherbedarf in UTF-8 und UTF-16

• UTF-8: ASCII-Zeichen 1 Byte, ä 2 Byte: 51 \cdot 1\,\text{Byte} + 1 \cdot 2\,\text{Byte} = \underline{\underline{53\,\text{Byte}}} (1 Punkt)

• UTF-16: jedes dieser Zeichen 2 Byte: 52 \cdot 2\,\text{Byte} = \underline{\underline{104\,\mathrm{Byte}}} (1 Punkt)

Der Speicherbedarf verdoppelt sich ungefähr, weil UTF-16 auch für die ASCII-Zeichen 2 Byte braucht; UTF-8 kommt bei überwiegend lateinischen Texten mit fast einem Byte je Zeichen aus (1 Punkt). In reinem ASCII ließe sich der Titel gar nicht speichern, weil ASCII kein „ä“ kennt.

Je erklärter Fehler 1 Punkt:

• Dateityp: Die Daten liegen als PDF statt als CSV-Datei vor; ein PDF ist ein Druckformat und kann nicht als CSV eingelesen werden.

• Trennzeichen: In der Zeile von Marco Brenner steht zwischen Nachname und Ticketart ein Komma statt eines Semikolons; die Zeile hat dadurch nur drei statt vier Felder.

• Datumsformat: Das Datum ist uneinheitlich (2027-01-14 statt TT.MM.JJJJ wie in den übrigen Zeilen).

• Ungültiger Wert: Den 31.02.2027 gibt es nicht.

• Zeichenkodierung: „Öztürk“ zeigt, dass die Datei in UTF-8 gespeichert, aber als Windows-1252 gelesen wurde; richtig ist „Öztürk“. Die Kodierung muss vereinbart werden.

Je richtige Zeile 1 Punkt:

Achtung: liefertermin ist ein String, denn JSON hat keinen Datumstyp; das Format (ISO 8601) muss vereinbart sein. Für stueckpreisNetto ist auch Float vertretbar; Geldbeträge werden im Programm oft als Dezimaltyp verarbeitet, um Rundungsfehler zu vermeiden.

ba) 1 Punkt Array, je Objekt 1,5 Punkte (Schlüssel in doppelten Anführungszeichen, Zahlen ohne Anführungszeichen):

[
  { "schloss_id": 1, "schliessanlage_id": 1, "art": "Bügelschloss", "modell": "Urban 270" },
  { "schloss_id": 2, "schliessanlage_id": 1, "art": "Rahmenschloss", "modell": "Cargo" }
]

bb) 2 Punkte für das äußere Objekt mit den Daten der Schließanlage, 2 Punkte für das eingebettete Array, 2 Punkte für die Schloss-Objekte:

{
  "schliessanlage_id": 1,
  "code": "VS-7Q4K2M9",
  "anzahl_schluessel": 3,
  "schloesser": [
    { "schloss_id": 1, "art": "Bügelschloss", "modell": "Urban 270" },
    { "schloss_id": 2, "art": "Rahmenschloss", "modell": "Cargo" }
  ]
}

Der Fremdschlüssel schliessanlage_id in den Schloss-Objekten kann entfallen, weil sich die Zugehörigkeit aus der Verschachtelung ergibt; er darf aber auch stehen bleiben.

2 Punkte für eine geeignete Auswahl (JSON oder XML), je 2 Punkte für ein passendes Pro- und Kontra-Argument, zum Beispiel:

• JSON – Pro: einfach und kompakt zu erzeugen, die Shop-Software nutzt JSON schon für die Schnittstelle zu Lipper SchließTec, eingebaute Datentypen. Kontra: kein Datumstyp, Formate (z. B. für Datum) müssen vereinbart werden; Prüfung über JSON Schema weniger verbreitet als XSD; keine Kommentare.

• XML – Pro: hoher Grad an Standardisierung, Struktur und Datentypen lassen sich mit einem XML-Schema streng prüfen, bei Behörden weit verbreitet (z. B. XRechnung). Kontra: aufwendiger zu erzeugen, viel Overhead durch Start- und Endtags.

DOCX ist nicht geeignet: Es ist ein binäres Office-Format für Layout und Darstellung, kein Datenaustauschformat, und lässt sich nicht zuverlässig automatisch auslesen (keine Punkte für die Wahl von DOCX).

Je Vorteil 2 Punkte, zum Beispiel:

• JSON ist kürzer, weil Endtags fehlen; dadurch werden weniger Daten übertragen.

• JSON ist schneller zu lesen und zu verarbeiten (einfachere Syntax, weniger Aufwand beim Parsen).

• JSON hat eingebaute Arrays, z. B. für die Liste positionen; in XML müssten Elemente wiederholt werden.

• JSON kennt Datentypen wie Number und Boolean ("bestaetigt": true); in XML ist jeder Wert zunächst Text.

• JSON lässt sich in JavaScript direkt als Objekt verwenden und ist Standard bei REST-Schnittstellen.

Alle drei sind offene, textbasierte Formate: Die Daten stehen im Klartext in der Datei, die Struktur der Daten (welche Felder in welcher Reihenfolge) können Sender und Empfänger selbst festlegen, und fast jedes Programm und jede Programmiersprache kann sie unabhängig von Hersteller und Betriebssystem lesen und schreiben (2 Punkte).