Übungsaufgaben zu NoSQL, Dokumentendatenbanken und JSON

Je Vorteil 1 Punkt für die Nennung, 1 Punkt für die Beschreibung mit Bezug zur Situation, z. B.:

• Mehrbenutzerzugriff: Die drei Kolleg*innen können gleichzeitig Störungen und Batteriewechsel eintragen, ohne sich gegenseitig Änderungen zu überschreiben; es gibt keine konkurrierenden Kopien der Datei mehr.

• Zugriffsschutz: Über Benutzerkonten und Rechte lässt sich festlegen, wer Sensoren anlegen darf und wer nur lesen darf, z. B. die Hausmeisterei.

• Datenintegrität: Datentypen, Pflichtfelder und eindeutige Schlüssel verhindern doppelte Gerätenamen, Tippfehler in Datumsangaben oder Sensoren ohne Raum.

• Leistung und Auswertung: Auch bei vielen Einträgen bleiben Abfragen schnell, und Auswertungen („alle Sensoren mit Batteriewechsel vor über einem Jahr“) sind per SQL möglich.

Je richtiger Art 1 Punkt, z. B.: Schlüssel-Wert-Datenbank, Dokumentendatenbank, Spaltenfamilien-Datenbank, Graphdatenbank, Zeitreihendatenbank, Objektdatenbank, Vektordatenbank.

Je richtiger Zuordnung 1 Punkt:

Je Seite 2 Punkte, z. B.:

• SQL-Datenbanken sind relationale Datenbanken: Die Daten liegen in Tabellen mit festem, vorab definiertem Schema, die über Schlüssel logisch verknüpft sind; abgefragt wird einheitlich mit der standardisierten Sprache SQL. Sie eignen sich besonders für strukturierte, stark verknüpfte Daten und Transaktionen.

• NoSQL-Datenbanken sind nicht relational: Sie speichern Daten in anderen Formaten, z. B. als Dokumente, Schlüssel-Wert-Paare, Graphen oder Zeitreihen, meist mit flexiblem Schema; statt einer einheitlichen Abfragesprache gibt es herstellerspezifische APIs. Sie eignen sich für wechselnde oder unstrukturierte Daten und sehr große, verteilte Datenmengen.

Geg.: 120 Sensoren, 1 Datensatz je Minute, 1.440 Minuten je Tag, 365 Tage

Ges.: Datensätze je Tag n_T und je Jahr n_J

n_T = 120 \cdot 1.440 = \underline{\underline{172.800\ \text{Datensätze}}}

(1 Punkt)

n_J = 172.800 \cdot 365 = \underline{\underline{63.072.000\ \text{Datensätze}}}

(1 Punkt)

Je Vorteil mit Beschreibung 2 Punkte, z. B.:

• Sie ist für Daten aus Zeitstempel, Messwert und wenigen Metainformationen (Sensor, Raum) optimiert und schreibt die rund 172.800 Datensätze am Tag sehr schnell weg.

• Zeitbezogene Abfragen sind eingebaut, z. B. der Mittelwert des CO₂-Gehalts je Raum in der letzten Stunde oder der Höchstwert je Schultag.

• Alte Daten werden automatisch gelöscht oder verdichtet, z. B. Rohwerte nach 30 Tagen nur noch als Stundenmittel; das begrenzt den Speicherbedarf.

• Die Daten werden stark komprimiert und lassen sich einfach skalieren, wenn weitere Schulen hinzukommen.

Messwerte (2 Punkte): Die Messwerte haben keine Beziehungen untereinander, sondern folgen nur zeitlich aufeinander. Eine relationale Datenbank könnte sie speichern, aber ihre Stärken (Fremdschlüssel, JOINs, Normalisierung, Transaktionen) würden kaum genutzt und brächten unnötige Komplexität und Ressourcenverbrauch; bei über 63 Millionen Datensätzen im Jahr wachsen Tabelle und Indizes stark, und das Löschen alter Werte ist aufwendig.

Sensorliste (2 Punkte): Die Sensorliste ist klein, klar strukturiert und mit Räumen, Störungen und Batteriewechseln verknüpft; hier zahlen sich festes Schema, referentielle Integrität, Mehrbenutzerzugriff und SQL-Auswertungen aus. Die Schul-IT kombiniert also sinnvoll beide Datenbankarten.

Big Data bezeichnet Datenmengen, die klassische Datenbanken und Auswertungsverfahren kaum noch bewältigen; beschrieben werden sie mit den drei V (je V 1 Punkt):

• Volume: sehr große Datenmengen (Tera- bis Petabyte), z. B. Positionsmeldungen Tausender Tracker über Jahre.

• Velocity: Die Daten entstehen sehr schnell und sollen oft in Echtzeit verarbeitet werden, z. B. viele Meldungen pro Sekunde.

• Variety: strukturierte, halbstrukturierte und unstrukturierte Daten gemischt, z. B. Positionen, Fotos eines gestohlenen Rads, Diebstahlanzeigen als Text.

Geg.: 8.000 Tracker, 45 min Fahrt je Tag, 1 Meldung je 30 s, 180 Byte je Meldung, 3.000 Räder gleichzeitig

Ges.: Datenmenge je Tag D_T und je Jahr D_J, Meldungen je Sekunde r

Meldungen je Rad und Tag (1 Punkt):

m = \frac{45 \cdot 60\,\text{s}}{30\,\text{s}} = 90

Datenmenge je Tag (1 Punkt):

D_T = 8.000 \cdot 90 \cdot 180\,\text{Byte} = 129.600.000\,\text{Byte} \approx \underline{\underline{0{,}130\,\text{GB}}}

Datenmenge je Jahr (1 Punkt):

D_J = 129.600.000\,\text{Byte} \cdot 365 = 47.304.000.000\,\text{Byte} = \underline{\underline{47{,}304\,\text{GB}}}

Meldungen je Sekunde zu Spitzenzeiten (2 Punkte):

r = \frac{3.000}{30\,\text{s}} = \underline{\underline{100\ \text{Meldungen je Sekunde}}}

Beurteilung mit Bezug auf mindestens zwei V (3 Punkte), z. B.: Die Datenmenge ist mit rund 47 GB im Jahr für heutige Server gut beherrschbar, sie allein macht noch kein Big Data. Kritischer ist die Geschwindigkeit: 100 Meldungen pro Sekunde (bei Wachstum deutlich mehr) müssen laufend gespeichert und für die Live-Ortung in Echtzeit ausgewertet werden. Kommen später Fotos, Diebstahlanzeigen oder Daten anderer Tracker-Modelle hinzu, wächst auch die Vielfalt. Die Positionsdaten zeigen also Merkmale von Big Data (vor allem Velocity), ohne beim Volumen schon an Grenzen zu stoßen. Eine andere, schlüssig begründete Beurteilung ist ebenfalls richtig.

Aussage mit Begründung (3 Punkte), z. B.: Für die Positionsdaten sind ER-Modell und relationale Shop-Datenbank wenig geeignet. Die Meldungen sind fortlaufende Messwerte ohne Beziehungen untereinander; sie entstehen schnell und in großer Zahl und würden die Shop-Datenbank mit Schreibzugriffen belasten, die für Bestellungen gebraucht wird. Ein festes Schema passt zudem schlecht, wenn neue Tracker-Modelle zusätzliche Felder senden. Besser ist eine Zeitreihen- oder Dokumentendatenbank für die Positionen; Abos, Kundendaten und Rechnungen bleiben relational in MariaDB, verknüpft über die Tracker-ID.

Je gefundenem und korrigiertem Fehler 1 Punkt:

• "lat": "52.0302" ist ein String; die Breite muss wie lon eine Zahl sein, sonst lässt sich nicht rechnen.

• 18,4 – Dezimalzahlen werden in JSON mit Punkt geschrieben (18.4); das Komma trennt Werte.

• 'akku_prozent' – Schlüssel und Strings stehen in doppelten Anführungszeichen.

• TRUE – Wahrheitswerte werden klein geschrieben (true).

• Das Komma nach dem letzten Wertpaar ist nicht erlaubt.

{
  "tracker_id": "CSB-TRK-000417",
  "zeit": "2027-03-15T07:42:30+01:00",
  "position": { "lat": 52.0302, "lon": 8.5325 },
  "geschwindigkeit_kmh": 18.4,
  "akku_prozent": 87,
  "in_bewegung": true
}

Je Datenart mit Begründung 1 Punkt, z. B.:

1. Abos und Rechnungen → relationale Datenbank (MariaDB): strukturierte, verknüpfte Daten, bei denen es um Geld geht; Transaktionen und referentielle Integrität sind wichtig, und die Daten liegen schon dort.

2. Positionsmeldungen → Zeitreihendatenbank (alternativ Dokumentendatenbank): viele fortlaufende Messwerte mit Zeitstempel, schnelles Schreiben, Zeitfunktionen für Routen, automatisches Löschen alter Positionen (auch aus Datenschutzgründen).

3. Tracker-Profile → Dokumentendatenbank: Jedes Modell hat andere Konfigurationsfelder; ein flexibles Schema nimmt neue Modelle ohne Schemaänderung auf.

Je Nachteil 2 Punkte (Nachteil 1 Punkt, Beschreibung mit Bezug zur Tabelle 1 Punkt), z. B.:

• Alle Werte sind Text (wert ist VARCHAR): Die Datenbank kann nicht prüfen, ob eine Akkukapazität wirklich eine Zahl ist; ein Filter „Akkukapazität ab 400 Wh“ vergleicht Texte ('500' > '1000') oder muss jeden Wert erst umwandeln.

• Für jede Produktseite ist ein JOIN nötig, und ein Artikel besteht aus vielen Zeilen in zwei Tabellen; das Programm muss die Zeilen wieder zu einem Objekt zusammensetzen. Ein Filter über zwei Merkmale (z. B. Akkukapazität und Motor) braucht sogar mehrere JOINs bzw. Unterabfragen.

• Keine Pflichtmerkmale und keine einheitlichen Namen: Ob jedes E-Bike eine Akkukapazität hat und ob sie überall „Akkukapazität“ heißt, kann die Datenbank nicht sicherstellen.

• Die Alternative, für jedes Merkmal eine eigene Spalte in artikel anzulegen, führt zu vielen leeren Feldern (NULL) und zu Schemaänderungen bei jedem neuen Produkttyp – beim Bügelschloss blieben z. B. Akkukapazität und Motor leer, beim E-Bike Sicherheitsstufe und Bügellänge.

Je richtiger Zuordnung 1 Punkt:

Tabelle artikel (3 Punkte: Array und Objekte 1 Punkt, Schlüssel-Wert-Paare 1 Punkt, Datentypen 1 Punkt):

[
  { "artikel_id": 2, "artikelnr": "RAD-EB-02", "bezeichnung": "E-Bike „Kanal“ Mittelmotor 500 Wh", "netto_preis": 2520.17, "konfigurierbar": false },
  { "artikel_id": 5, "artikelnr": "SCH-BUE-01", "bezeichnung": "Bügelschloss, gleichschließend", "netto_preis": 62.18, "konfigurierbar": true }
]

Tabelle artikel_merkmal (5 Punkte: je Objekt 1 Punkt):

[
  { "merkmal_id": 1, "artikel_id": 2, "merkmal": "Akkukapazität", "wert": "500", "einheit": "Wh" },
  { "merkmal_id": 2, "artikel_id": 2, "merkmal": "Motor", "wert": "Mittelmotor", "einheit": null },
  { "merkmal_id": 3, "artikel_id": 2, "merkmal": "Gänge", "wert": "8", "einheit": null },
  { "merkmal_id": 4, "artikel_id": 5, "merkmal": "Sicherheitsstufe", "wert": "12", "einheit": null },
  { "merkmal_id": 5, "artikel_id": 5, "merkmal": "Bügellänge", "wert": "230", "einheit": "mm" }
]

Bewertungshinweise:

• Da wert in der Tabelle ein Text ist, ist "500" die genaue Umwandlung; 500 als Zahl ist ebenfalls richtig.

• NULL wird zu null (ohne Anführungszeichen). Ein weggelassenes Feld einheit ist vertretbar, "NULL" als Text ist falsch (0,5 Punkte Abzug).

• Wahrheitswerte als true/false, Zahlen ohne Anführungszeichen und mit Dezimalpunkt. Statt false/true sind auch 0/1 vertretbar, weil MariaDB BOOLEAN als TINYINT(1) speichert.

• Ein Kommentar wie // artikel über dem Array ist kein gültiges JSON (kein Punktabzug, wenn er nur als Beschriftung außerhalb des Arrays steht).

[
  {
    "artikel_id": 2,
    "artikelnr": "RAD-EB-02",
    "bezeichnung": "E-Bike „Kanal“ Mittelmotor 500 Wh",
    "netto_preis": 2520.17,
    "konfigurierbar": false,
    "merkmale": [
      { "merkmal": "Akkukapazität", "wert": 500, "einheit": "Wh" },
      { "merkmal": "Motor", "wert": "Mittelmotor" },
      { "merkmal": "Gänge", "wert": 8 }
    ]
  },
  {
    "artikel_id": 5,
    "artikelnr": "SCH-BUE-01",
    "bezeichnung": "Bügelschloss, gleichschließend",
    "netto_preis": 62.18,
    "konfigurierbar": true,
    "merkmale": [
      { "merkmal": "Sicherheitsstufe", "wert": 12 },
      { "merkmal": "Bügellänge", "wert": 230, "einheit": "mm" }
    ]
  }
]

Bewertung (7 Punkte):

• Array merkmale im richtigen Artikeldokument, korrekt geklammert: je Artikel 1 Punkt (2 Punkte),

• fünf Merkmalsobjekte vollständig: je 0,5 Punkte (2,5 Punkte),

• Fremdschlüssel artikel_id in den eingebetteten Merkmalen entfällt (1 Punkt); die merkmal_id darf bleiben, muss aber nicht,

• Zahlenwerte als number, Text als string (1 Punkt), fehlende Einheit weggelassen oder null (0,5 Punkte).

Ebenfalls richtig ist ein eingebettetes Objekt statt eines Arrays, z. B. "merkmale": { "akkukapazitaetWh": 500, "motor": "Mittelmotor", "gaenge": 8 } – damit lassen sich die Merkmale sogar direkt filtern. Gefordert war aber ein Array; volle Punktzahl, wenn alle Merkmale korrekt enthalten sind.

Der Vorschlag ist nicht sinnvoll; die Bewertungen sollten in einer eigenen Collection liegen und auf den Artikel verweisen (Referenz über die Artikelnummer) (1 Punkt). Begründung (2 Punkte, je Argument 1 Punkt), z. B.:

• Die Zahl der Bewertungen ist nicht begrenzt und wächst ständig; das Artikeldokument würde immer größer (in MongoDB höchstens 16 MB je Dokument), und jede Produktseite lädt alle Bewertungen mit, auch wenn nur die ersten fünf angezeigt werden.

• Bewertungen werden unabhängig vom Artikel gelesen und geändert (z. B. „alle Bewertungen einer Kundin“, Löschung nach DSGVO, Freigabe durch die Moderation).

• Bewertungen enthalten personenbezogene Daten (Kundennummer); sie getrennt zu halten, erleichtert Zugriffsrechte und Löschfristen.

Andere begründete Stellungnahmen sind möglich, z. B.: nur die Durchschnittsnote und die drei neuesten Bewertungen einbetten, den Rest referenzieren.

Je richtiger Zeile 1 Punkt (7 Punkte; ergänzte Angaben fett):

Hinweis: JSON kennt nur den Typ number; ob im Programm int oder double passt, ergibt sich aus der Bedeutung (Stückzahl ganzzahlig, Gewicht mit Nachkommastellen). null ist ein eigener JSON-Datentyp; in Java bleibt die Variable vom Typ String, enthält aber null. JSON hat keinen Datumstyp: Datum und Uhrzeit stehen als String, üblicherweise im Format ISO 8601 (hier mit Zeitzonenabstand +02:00). Das Programm wandelt den String beim Einlesen in einen Datumstyp um.

Je gefundenem und korrigiertem Fehler 1 Punkt (7 Fehler):

1. Zeile 2: Kommentar // … ist in JSON nicht erlaubt (Information weglassen oder als Feld speichern, z. B. "hinweis": "…").

2. Zeile 4: Schlüssel bezeichnung steht nicht in Anführungszeichen.

3. Zeile 5: Dezimalkomma 62,18 – richtig 62.18 (so ist es außerdem ein zusätzliches, ungültiges Element ohne Schlüssel).

4. Zeile 6: True muss klein geschrieben werden: true.

5. Zeile 7: einfache Anführungszeichen um sicherheitsstufe – richtig "sicherheitsstufe".

6. Zeile 8: Komma nach dem letzten Array-Element "Gelbgrün",].

7. Zeile 8: Komma nach dem letzten Schlüssel-Wert-Paar vor der schließenden }.

Korrigierte Fassung:

{
  "_id": "SCH-BUE-01",
  "bezeichnung": "Bügelschloss, gleichschließend",
  "preis": { "netto": 62.18, "mwstSatz": 19 },
  "lieferbar": true,
  "sicherheitsstufe": 12,
  "farben": ["Schwarz", "Gelbgrün"]
}

Entscheidung 1 Punkt, je Argument 2 Punkte. Erwartet wird in der Regel: Bestellungen, Zahlungen und Rechnungen bleiben in der relationalen Datenbank (MariaDB). Argumente, z. B.:

• Transaktionssicherheit (ACID): Beim Bestellen müssen Bestellung, Bestellpositionen, Lagerbestand und ggf. Fertigungsauftrag gemeinsam oder gar nicht gespeichert werden; zwei Kund*innen dürfen das letzte E-Bike nicht gleichzeitig kaufen. Ein relationales DBMS garantiert das mit Transaktionen.

• Konsistenz und referentielle Integrität: Jede Bestellung gehört zu einem vorhandenen Kundenkonto, jede Position zu einem Artikel, jede Rechnung zu einer Bestellung. Fremdschlüssel lassen das DBMS das prüfen; in der Dokumentendatenbank müsste das Programm es selbst sicherstellen.

• Strukturierte Daten mit festen Pflichtangaben: Bestellungen und Rechnungen haben immer dieselben Felder (Pflichtangaben einer Rechnung); die Flexibilität eines Dokumentenschemas bringt hier keinen Vorteil.

• Auswertungen mit SQL: Umsatzauswertungen, Mahnwesen und Abgleich mit der Buchhaltung laufen bereits mit SQL; Wissen und Abfragen sind vorhanden.

Ein Vorschlag für die Dokumentendatenbank ist nur mit passender Begründung richtig, z. B.: Eine Bestellung wird als Ganzes gelesen (Bestellung mit Positionen als ein Dokument), und moderne Dokumentendatenbanken unterstützen ebenfalls Transaktionen über mehrere Dokumente.

Je Vorteil 3 Punkte (Vorteil 1 Punkt, Erläuterung 1 Punkt, Bezug zu RatzFahrt 1 Punkt). Drei aus:

• Flexibles Datenmodell (Schema): Dokumente einer Collection können unterschiedliche Felder haben; neue Felder lassen sich ohne Schemaänderung und ohne Ausfallzeit ergänzen. Bezug: Die frei wählbaren Zusatzmerkmale der Fahrtangebote und die Daten der neuen Schulen (z. B. andere Klassenbezeichnungen) lassen sich speichern, ohne für jedes Merkmal die Tabelle angebot zu ändern; neue Funktionen sind schneller umgesetzt.

• Schnelle Abfragen zusammengehöriger Daten: Alles, was zu einem Objekt gehört, liegt in einem Dokument; ein Lesezugriff genügt, es sind keine JOINs nötig. Bezug: Die Detailansicht eines Fahrtangebots mit Haltepunkt, Fahrzeug und Merkmalen wird mit einem Zugriff geladen – wichtig, wenn mehr Schulen und Flurmonitore gleichzeitig abfragen.

• Einfachere Entwicklung: Das JSON-ähnliche Format entspricht den Objekten im Programm; es wird weniger Code zum Umwandeln zwischen Tabellen und Objekten gebraucht. Bezug: Die App erhält über die REST-API ohnehin JSON; ein Chatverlauf oder ein Angebot kann nahezu unverändert gespeichert und ausgeliefert werden.

• Horizontale Skalierung und Verfügbarkeit: Die Daten können auf viele Server verteilt und an mehreren Standorten gespiegelt werden; fällt ein Server aus, bleibt das System erreichbar. Bezug: Mit drei Schulen steigen Datenmenge und Zugriffe; die geplanten Server in zwei Rechenzentren können sich die Last teilen und sich gegenseitig vertreten.

Weitere Vorteile, die sich aus dem Text ergeben, sind möglich.

Je Nennung 1 Punkt. Probleme, z. B.:

• uneinheitliche Feldnamen für dieselbe Angabe (freiePlaetze, freie_plaetze, plaetze), sodass Abfragen Dokumente übersehen,

• wechselnde Datentypen ("freiePlaetze": "2" als Text neben 2 als Zahl), sodass Vergleiche wie „größer als 0“ falsch ausgehen,

• fehlende Pflichtfelder (Angebot ohne Haltepunkt oder Uhrzeit),

• unterschiedliche Schreibweisen frei eingegebener Merkmale („Fahrradträger“, „Radträger“, „Fahrrad-Träger“),

• ungewollt gespeicherte personenbezogene Daten in zusätzlichen Feldern (Datenminimierung).

Gegenmaßnahmen, z. B.: Schemavalidierung der Datenbank (JSON Schema mit Pflichtfeldern und Datentypen), Prüfung der Eingaben im Backend vor dem Speichern, feste Auswahlliste für Merkmale statt Freitext, dokumentiertes Datenmodell.

Je Ausprägung 1 Punkt:

Andere sinnvolle Formulierungen sind richtig. Auch andere Kriterien wären möglich gewesen, z. B. Abfragesprache (standardisiertes SQL ↔ herstellerspezifische API) oder Redundanz (gering durch Normalisierung ↔ bewusst höher durch Einbetten).

Je Zeile 2 Punkte (Zuordnung 1 Punkt, Begründung 1 Punkt):

Nachrechnung zu 3 (zur Einordnung, nicht gefordert): 2 Meldungen pro Minute · 60 · 24 · 365 = 1.051.200 Meldungen je Player und Jahr; bei zwölf Playern (vier je Schule) 12.614.400, also rund 12,6 Mio.

Andere Zuordnungen mit stimmiger Begründung sind möglich (z. B. 3 als Dokumentendatenbank mit Zeitreihen-Collection).

• Bei verteilten Daten liegen Kopien auf mehreren Servern. Damit alle Server immer denselben, aktuellen Stand liefern (Konsistenz), muss jede Änderung vor dem Bestätigen mit allen Kopien abgestimmt werden (1 Punkt).

• Fällt die Netzwerkverbindung zwischen den Rechenzentren aus, ist diese Abstimmung nicht möglich. Das System muss dann entweder Anfragen ablehnen (konsistent, aber nicht verfügbar) oder mit dem eigenen, evtl. veralteten Stand weiterarbeiten (verfügbar, aber nicht konsistent) (1 Punkt).

• Beides zugleich ist bei einer Netzwerkstörung nicht möglich (CAP-Theorem: Consistency, Availability, Partition tolerance). Zudem verlangsamt die Abstimmung jede Transaktion (Sperren, Bestätigung über mehrere Server). Viele NoSQL-Systeme verzichten daher auf strenge Konsistenz und arbeiten nach BASE (basically available, soft state, eventually consistent) (1 Punkt).

Je Funktion 2 Punkte (Urteil 1 Punkt, Begründung 1 Punkt):

1. Tragbar. Die Anzeige ist ohnehin nur eine Übersicht und wird regelmäßig neu geladen (die Monitore fragen etwa einmal pro Minute ab). Zeigt ein Monitor ein gerade volles Angebot einige Sekunden zu lange, entsteht kein Schaden; gebucht wird ohnehin in der App. Wichtiger ist, dass die Anzeige auch bei einer Störung überhaupt etwas zeigt (Verfügbarkeit).

2. Nicht tragbar. Würden zwei Server gleichzeitig den „letzten freien Platz“ vergeben, wäre das Angebot überbucht; eine Person stünde am Haltepunkt ohne Platz. Die Buchung braucht strenge Konsistenz (atomares Prüfen und Herabsetzen der freien Plätze in einer Transaktion), lieber eine Fehlermeldung „bitte später erneut versuchen“ als eine Doppelbuchung. Deshalb bleibt die Buchung in der relationalen Datenbank bzw. läuft als Transaktion, die nur ein führender Knoten (primary) in einem Rechenzentrum bestätigt; ist die Verbindung gestört, nimmt das andere Rechenzentrum keine Buchungen an. Eine Bestätigung durch die Mehrheit der Knoten setzt mindestens drei Knoten voraus, z. B. einen dritten Standort als Schiedsknoten.

JSON, XML und CSV sind offene, textbasierte Formate, die nicht an einen Hersteller, ein Betriebssystem oder eine Programmiersprache gebunden sind (1 Punkt). Deshalb kann nahezu jedes System sie erzeugen und einlesen – hier die Datenbank der Schule, die Tabellenkalkulation der Verwaltung und das Mobilitätsportal (1 Punkt). Außerdem sind sie für Menschen mit einem einfachen Texteditor lesbar und prüfbar und lassen sich verlustfrei übertragen (1 Punkt).

Je Merkmal 1 Punkt, z. B.:

XML

• textbasiertes, hierarchisches Format (Baum aus Elementen),

• Elemente werden durch Start- und Endtag ausgezeichnet, zusätzlich Attribute,

• Struktur und Datentypen über DTD bzw. XML-Schema (XSD) prüfbar,

• Namensräume, Kommentare; häufig bei SOAP-Webservices und Branchenstandards (z. B. E-Rechnung).

JSON

• textbasiertes, hierarchisches Format aus Objekten { } mit Schlüssel-Wert-Paaren und Arrays [ ],

• eigene Datentypen (string, number, boolean, null),

• kompakt, keine Endtags, direkt in JavaScript nutzbar,

• Standardformat von REST-Webservices.

Je Format 2 Punkte (Aspekt 1 Punkt, Erläuterung mit Bezug 1 Punkt), z. B.:

• CSV: Die Statistik ist eine flache Tabelle (eine Zeile je Monat, Haltepunkt und Richtung). CSV hat fast keinen Overhead und lässt sich direkt in der Tabellenkalkulation der Verwaltung öffnen und weiterrechnen. (Absprachen nötig zu Trennzeichen, Dezimaltrennzeichen und Zeichenkodierung, z. B. UTF-8 wegen „Gütersloh“.)

• JSON: Das Mobilitätsportal erwartet die Daten über eine REST-API; JSON ist dort das übliche Format (application/json) und wird von fast allen Programmiersprachen und Standardprogrammen ohne Zusatzaufwand verarbeitet. Zahlen bleiben Zahlen (Datentypen), und die Statistik kann verschachtelt übergeben werden (z. B. je Schule ein Array von Haltepunkten).

Ergebnis: die Dokumente 101 und 106 (1 Punkt). Bei einem Array-Feld ist die Bedingung merkmale: "Fahrradträger" erfüllt, wenn das Array den Wert enthält – die Position im Array spielt keine Rolle (106).

Nicht im Ergebnis (je 0,75 Punkte, insgesamt 3 Punkte):

• 102: freiePlaetze ist 0, die Bedingung $gt: 0 („größer als 0“) ist nicht erfüllt.

• 103: Das Feld merkmale fehlt; ein fehlendes Feld erfüllt die Gleichheitsbedingung nicht.

• 104: Richtung „nach Hause“ statt „zur Schule“.

• 105: Haltepunkt in Herford; "haltepunkt.ort" greift per Punktnotation auf das Feld ort im eingebetteten Objekt haltepunkt zu.

Zum Vergleich in SQL (bei einer Tabelle angebot_merkmal):

SELECT a.* FROM angebot a
  JOIN haltepunkt h ON h.haltepunkt_id = a.haltepunkt_id
  JOIN angebot_merkmal m ON m.angebot_id = a.angebot_id
WHERE h.ort = 'Gütersloh' AND a.richtung = 'zur Schule'
  AND a.freie_plaetze > 0 AND m.merkmal = 'Fahrradträger';