Übungsaufgaben zu Datenqualität und Datenimport

Je 1 Punkt:

Zwei Kriterien, je 1 Punkt für Kriterium mit Erläuterung und 1 Punkt für ein passendes Beispiel, z. B.:

• Aktualität: Die Daten entsprechen dem heutigen Stand. Beispiel: Viele Kontakte haben seit 2023 Schule, Betrieb oder E-Mail-Adresse gewechselt; die Einladung zum Call for Participation käme nicht an.

• Korrektheit: Die Daten stimmen mit der Realität überein. Beispiel: Tippfehler in einer E-Mail-Adresse (…@rrb-bielefled.de) oder ein falsch geschriebener Name.

• Eindeutigkeit: Jeder Datensatz ist eindeutig interpretierbar. Beispiel: Ein Kontakt „Klein, H.“ ohne Vornamen und E-Mail – ist das Hannah Klein oder jemand anderes?

• Relevanz: Die Daten erfüllen den Informationsbedarf. Beispiel: Für die Einladung werden Name, E-Mail-Adresse und frühere Sessions gebraucht, nicht aber die Menüwahl beim Mittagessen 2023.

• auch: Zuverlässigkeit, Genauigkeit, Verständlichkeit mit passendem Beispiel.

Je 2 Punkte für zwei Möglichkeiten, 2 Punkte für die begründete Beurteilung:

• Export und Import (Dump bzw. CSV): Die Tabellen werden aus Access in ein Austauschformat (CSV, JSON) exportiert und mit einem Importwerkzeug (z. B. LOAD DATA) unverändert in MariaDB geladen. Schnell und einfach, setzt aber voraus, dass Struktur und Qualität der Daten zum Ziel passen.

• ETL-Prozess: Die Daten werden aus Access extrahiert (Extract), in Struktur und Format an die neue Datenbank angepasst, bereinigt und geprüft (Transform, z. B. Dubletten zusammenführen, Rollen vereinheitlichen) und dann in die Zieltabellen geladen (Load).

• Parallelbetrieb mit Replikation: Beide Systeme laufen eine Zeit lang gleichzeitig, die Daten werden in beiden gehalten und synchronisiert; danach wird das alte System abgeschaltet.

• Neuaufbau mit Nacherfassung: Nur ausgewählte Daten werden übernommen oder neu erfasst.

Beurteilung (Beispiel): Geeignet ist ein ETL-Prozess. Die Daten haben deutliche Mängel (fehlende E-Mail-Adressen, Dubletten, uneinheitliche Rollen), und das Datenmodell der neuen Datenbank unterscheidet sich von der Access-Datenbank. Ein reiner Export und Import würde die Mängel übernehmen oder am Pflichtfeld scheitern. Ein Parallelbetrieb ist unnötig, weil die Access-Datenbank nach der Übernahme nicht mehr gebraucht wird. Auch eine andere Entscheidung ist richtig, wenn sie mit den Gegebenheiten begründet ist (z. B. Neuaufbau nur mit den Referent*innen, weil die alten Teilnahmen nicht gebraucht werden).

Drei Prozesse, je 3 Punkte (Prozess benannt und mit Bezug zum Fall beschrieben), z. B.:

• Datenmodelle analysieren und Zuordnung festlegen: Tabellen, Felder, Datentypen und Schlüssel der Access-Datenbank und der neuen Datenbank vergleichen und festlegen, welches alte Feld in welche neue Tabelle und Spalte kommt (Mapping), z. B. Feld „Rolle“ auf anmeldung.ticketart. Dabei wird auch geklärt, welche Daten überhaupt übernommen werden dürfen und sollen (nur Kontakte mit Einwilligung zur erneuten Kontaktaufnahme, keine Daten ohne Zweck).

• Daten sichern, analysieren und bereinigen: Sicherungskopie der Access-Datenbank anlegen, ein Datenprofil erstellen (fehlende E-Mail-Adressen, Dubletten, Schreibweisen), Dubletten zusammenführen, Werte vereinheitlichen, fehlende Angaben nachtragen oder Datensätze ausschließen.

• Übernahme vorbereiten (Algorithmus bzw. Importskript entwerfen, Schnittstelle bereitstellen): Ein Skript oder ETL-Werkzeug liest die Daten über eine Schnittstelle (ODBC-Verbindung oder CSV-Export) aus, wandelt sie um und vergibt neue Schlüssel; alte und neue IDs werden in einer Zuordnungstabelle festgehalten.

• Daten importieren: in der richtigen Reihenfolge laden (erst person und veranstaltung, dann anmeldung), zuerst als Testimport in eine Kopie der Datenbank.

• Fehlerprotokollierung und Dokumentation: Abgewiesene Datensätze mit Grund protokollieren und klären, das Vorgehen und alle Entscheidungen dokumentieren, Ergebnis vom Orga-Team abnehmen lassen.

Je 1 Punkt, z. B.:

• Anzahl der Datensätze vorher und nachher vergleichen (Kontakte abzüglich zusammengeführter Dubletten, Teilnahmen je Barcamp), abgewiesene Datensätze laut Fehlerprotokoll einrechnen.
• Stichproben: einzelne Personen (z. B. Gerhard Vogt) in alter und neuer Datenbank vergleichen.
• Prüfabfragen auf Pflichtfelder, Dubletten (gleiche E-Mail-Adresse) und Verweise ohne Partner.
• Summen oder Zählungen je Gruppe vergleichen (Referent*innen je Jahr, Sessions je Barcamp).
• Testlauf der Anwendung mit den importierten Daten (z. B. Probeversand der Einladung an das Orga-Team).

• Zuerst nutzer und haltepunkt (untereinander in beliebiger Reihenfolge), denn sie verweisen auf keine andere Tabelle. (1 Punkt)
• Danach fahrzeug, weil jedes Fahrzeug über nutzer_id auf einen vorhandenen Datensatz in nutzer verweisen muss. (1 Punkt)
• Zuletzt angebot, weil es über drei Fremdschlüssel auf nutzer, fahrzeug und haltepunkt verweist. (1 Punkt)

Begründung: Wegen der referenziellen Integrität darf ein Fremdschlüsselwert nur eingetragen werden, wenn der Datensatz auf der 1-Seite der Beziehung schon existiert. Sonst weist die Datenbank den Datensatz ab.

Je 2 Punkte:

Je 1 Punkt für drei passende Schritte, z. B.:

• Das Skript bricht nicht ab, sondern schreibt jeden abgewiesenen Datensatz mit Zeilennummer und Fehlermeldung in ein Fehlerprotokoll (oder in eine Fehlerspalte der Staging-Tabelle).
• Die Ursachen werden geklärt: Systematische Fehler (Dezimalkomma, Uhrzeit mit Punkt, Schreibweisen der Treffpunkte) behebt eine Umwandlung bzw. Zuordnungstabelle im Skript; Einzelfälle klärt die Schülervertretung (z. B. Sitzplätze nachfragen).
• Nur die korrigierten Datensätze werden erneut importiert; bereits übernommene bleiben unverändert, Dubletten verhindert der eindeutige Schlüssel.
• Abschließend werden die Zahlen abgeglichen (86 Fahrten = übernommene + begründet verworfene).

Erläuterung (2 Punkte): Der Primärschlüssel besteht nur aus fahrer_id und mitfahrer_id. Damit darf jede Kombination aus fahrer_id und mitfahrer_id nur ein einziges Mal vorkommen. Lukas’ Fahrten mit Niklas am Montag und am Donnerstag sowie in beide Richtungen (vier Datensätze) ließen sich nicht speichern; der zweite Datensatz würde mit Duplicate entry abgewiesen.

Korrektur (2 Punkte), eine der Möglichkeiten:

• Den Primärschlüssel um die unterscheidenden Merkmale erweitern: (fahrer_id, mitfahrer_id, wochentag, richtung).
• Oder einen künstlichen Schlüssel stammfahrt_id (PK, AUTO_INCREMENT) einführen und die Kombination (fahrer_id, mitfahrer_id, wochentag, richtung) mit UNIQUE absichern.

Zwei Gründe, je 2 Punkte, z. B.:

• Das Angebot verweist auf ein Fahrzeug, das es in fahrzeug nicht gibt – etwa weil Jonas ein neues Auto hat, das noch nicht angelegt wurde, oder weil eine falsche fahrzeug_id ausgewählt wurde.
• Der Treffpunkt ist noch nicht als Haltepunkt angelegt (z. B. ein neuer Treffpunkt in Halle), die eingetragene haltepunkt_id existiert also nicht.
• Der Datensatz von Jonas in nutzer existiert nicht (mehr), z. B. weil er versehentlich gelöscht wurde, sodass fahrer_id ins Leere zeigt.

SELECT i.zeile, i.ort, i.treffpunkt
FROM import_angebot i
LEFT JOIN haltepunkt h
       ON h.ort = i.ort AND h.name = i.treffpunkt
WHERE h.haltepunkt_id IS NULL
ORDER BY i.zeile;

Bewertung: LEFT JOIN von der Staging-Tabelle aus (1 Punkt), Verknüpfung über Ort und Name (1 Punkt), Bedingung IS NULL auf eine Spalte von haltepunkt (1 Punkt), Spaltenauswahl und Sortierung (1 Punkt). Gleichwertig ist eine Lösung mit WHERE NOT EXISTS (SELECT 1 FROM haltepunkt h WHERE h.ort = i.ort AND h.name = i.treffpunkt).

Ergebnis:

Die Staging-Tabelle mit diesen Daten steht in src/import_angebot.sql; sie setzt die Datenbank ratzfahrt voraus.

Vier der folgenden Probleme, je Problem 2 Punkte für die Beschreibung mit Beispiel aus dem Auszug und 1 Punkt für eine passende Folge:

Andere sachgerechte Probleme (z. B. Ansprechperson nur mit Initial „K. Nowak“, Information in der Bemerkungsspalte) sind ebenfalls richtig.

Je passendes Kriterium 1 Punkt, z. B.:

• Dublette → Redundanzfreiheit (auch: Eindeutigkeit)

• widersprüchliche Rabatte → Konsistenz (Widerspruchsfreiheit)

• uneinheitliche Formate → Einheitlichkeit

• ungültige Werte → Korrektheit bzw. Zulässigkeit/Plausibilität

• fehlende Angaben → Vollständigkeit

• „siehe Vertrag“ → Einheitlichkeit bzw. Vollständigkeit (der Wert steht woanders)

• falsche Zeichenkodierung → Korrektheit

• geschlossener Laden → Aktualität

Möglicher Weg (ETL-Prozess mit Staging-Tabelle):

1. Sicherungskopie der CSV-Datei anlegen; Mapping festlegen (welche Spalte in welche Tabelle/Spalte von kunde und adresse).

2. Die CSV-Datei unverändert in eine Staging-Tabelle import_haendler laden, deren Spalten alle Text (VARCHAR) sind. Zweck: Beim Laden geht nichts verloren und kein Datensatz wird abgewiesen; die Daten können dort mit SQL untersucht, vereinheitlicht und geprüft werden, ohne die Shop-Datenbank zu gefährden.

3. Mit Prüfabfragen Fehler finden und in einer Fehlerspalte markieren; Formate per SQL bzw. Importprogramm vereinheitlichen (Rabatt als Zahl, Datum als DATE, USt-IdNr. ohne Leerzeichen, Kodierung reparieren).

4. Was sich nicht automatisch klären lässt (Dublette Radhaus, „siehe Vertrag“, fehlende Angaben, geschlossener Laden), klärt Natalia Wróbel von Hand bzw. im Gespräch mit den Händlern; bei 37 Händlern ist das gut machbar.

5. Nur geprüfte Datensätze in der richtigen Reihenfolge (erst kunde, dann adresse) übernehmen, abgewiesene protokollieren, Ergebnis mit der Buchhaltung abnehmen.

Bewertung: 2 Punkte für einen nachvollziehbaren Weg (Bereinigung vor dem Import oder Importprogramm mit Fehlerbehandlung und Fehlerprotokoll), 2 Punkte für den Zweck der Staging-Tabelle. Ein rein manueller Weg („Natalia korrigiert die CSV-Datei, dann wird importiert“) ist bei 37 Datensätzen ebenfalls schlüssig.

SELECT REPLACE(ust_idnr, ' ', '') AS ust_idnr_bereinigt,
       COUNT(*)                   AS anzahl,
       GROUP_CONCAT(hnr ORDER BY hnr SEPARATOR ', ') AS haendlernummern
FROM import_haendler
WHERE ust_idnr <> ''
GROUP BY REPLACE(ust_idnr, ' ', '')
HAVING COUNT(*) > 1;

Ergebnis für den Auszug:

Bewertung: Leerzeichen entfernen mit REPLACE (1 Punkt), Ausschluss leerer Werte (1 Punkt), Gruppierung nach dem bereinigten Wert (1 Punkt), HAVING COUNT(*) > 1 (1 Punkt), Ausgabe von Anzahl und Händlernummern mit GROUP_CONCAT (1 Punkt). Ohne GROUP_CONCAT (nur Anzahl) 1 Punkt Abzug. Wer zusätzlich ust_idnr IS NOT NULL prüft, macht nichts falsch.

SELECT hnr, firma, ust_idnr
FROM import_haendler
WHERE ust_idnr IS NULL
   OR ust_idnr = ''
   OR REPLACE(ust_idnr, ' ', '') NOT REGEXP '^DE[0-9]{9}$';

Ergebnis für den Auszug:

Bewertung: Projektion (1 Punkt), fehlender Wert (1 Punkt), Musterprüfung mit REGEXP und Anker ^…$ (2 Punkte; ohne Anker 1 Punkt). Alternativ ohne regulären Ausdruck: LEFT(…, 2) <> 'DE' OR CHAR_LENGTH(…) <> 11 (dann prüft man allerdings nicht, ob die Zeichen 3 bis 11 Ziffern sind – 1 Punkt Abzug). Hinweis: In MariaDB unterscheidet REGEXP bei der Standardkollation nicht zwischen Groß- und Kleinschreibung; de123456789 würde also akzeptiert und sollte beim Übernehmen mit UPPER() vereinheitlicht werden.

Bewertung: je Zeile 1 Punkt für die Ursache, 1 Punkt für eine passende Abhilfe.

Zusatzhinweis (ohne Punkte): Alte Händlernummern als kunde_id zu verwenden, ist riskant – die IDs des neuen Systems werden per AUTO_INCREMENT vergeben und könnten später kollidieren. Besser ist eine eigene Spalte bzw. Zuordnungstabelle „alte Händlernummer → neue kunde_id“.

• Stammdaten beschreiben Objekte, die über einen längeren Zeitraum weitgehend gleich bleiben und in vielen Vorgängen wieder verwendet werden (1 Punkt).

• Bewegungsdaten entstehen laufend durch die Geschäftsprozesse, beziehen sich auf Stammdaten und sind an einen Zeitpunkt gebunden (1 Punkt).

• Zuordnung: Die Händlerdaten (Firma, Anschrift, USt-IdNr., Rabatt) sind Stammdaten, die Bestellungen der Bestellhistorie sind Bewegungsdaten (1 Punkt).

Beide Entscheidungen sind möglich; bewertet wird die Begründung mit Bezug auf den Fall (2 Punkte für die Abwägung, 1 Punkt für eine klare Entscheidung, 1 Punkt für eine schlüssige Begründung bzw. Alternative).

Gegen den vollständigen Import (Beispiel): Die Bestellungen bis 2020 lassen sich keinen heutigen Artikeln zuordnen (Freitext, ausgelaufene Artikelnummern); Rabatte sind nur als Endbetrag gespeichert, sodass sich Positionspreise nicht sauber rekonstruieren lassen. Für „Nachbestellen wie zuletzt“ genügen die letzten Bestellungen. Die Rechnungen sind für Buchhaltung und Aufbewahrungspflichten bereits im Buchhaltungsprogramm vorhanden. Der Aufwand für Bereinigung und ein Importprogramm steht daher in keinem Verhältnis zum Nutzen. Ich empfehle, höchstens die Bestellungen der letzten 12 bis 24 Monate mit gültigen Artikelnummern zu übernehmen und die übrige Historie als schreibgeschützten Export zu archivieren.

Für den Import (Beispiel): Die Händler und der Vertrieb wollen Umsatzentwicklungen über mehrere Jahre im Portal sehen; ohne Historie wirkt das neue Portal für langjährige Händler leer. Dann muss der höhere Aufwand in Kauf genommen werden: Freitext-Positionen werden als „Altartikel“ ohne Artikelbezug übernommen, Beträge als Gesamtsumme, und das Importprogramm protokolliert alle Bestellungen, die es nicht zuordnen kann.

Drei der folgenden Maßnahmen, je 1 Punkt für die Maßnahme und 1 Punkt für die Wirkung:

• Constraints in der Datenbank: z. B. UNIQUE auf die USt-IdNr., CHECK (ust_idnr REGEXP '^DE[0-9]{9}$') für deutsche Händler, Rabatt als DECIMAL(4,1) mit CHECK zwischen 0 und 100, Datum als DATE. Wirkung: Ungültige und doppelte Werte werden abgewiesen, egal über welches Programm sie hineinkommen.

• Eingabevalidierung im Portal: Pflichtfelder, Formatprüfung von PLZ, E-Mail und USt-IdNr. mit verständlicher Fehlermeldung, Datumsauswahl statt freier Eingabe. Wirkung: Fehler werden schon bei der Eingabe erkannt und von der Person korrigiert, die die richtigen Daten kennt.

• Auswahllisten statt Freitext: Land als Auswahl (ISO-Code), Rabatt aus festen Konditionsstufen statt „siehe Vertrag“. Wirkung: Einheitliche Werte, die automatisch verarbeitet werden können.

• Dublettenprüfung beim Anlegen: Hinweis, wenn USt-IdNr. oder ähnlicher Firmenname schon vorhanden sind. Wirkung: Keine doppelten Händlerkonten mehr.

• Selbstpflege durch die Händler: Händler pflegen Anschrift, Ansprechperson und E-Mail-Adresse im Portal selbst (Änderungen von Konditionen nur durch die Buchhaltung). Wirkung: Daten bleiben aktuell.

• Verantwortlichkeit und regelmäßige Prüfung: Natalia Wróbel ist für die Händlerstammdaten verantwortlich; ein monatlicher Prüfbericht listet z. B. Händler ohne Bestellung seit 12 Monaten oder Datensätze mit fehlenden Pflichtangaben. Wirkung: Veraltete und unvollständige Daten fallen auf und werden bereinigt.

• Einheitliche Kodierung (utf8mb4 durchgängig in Datenbank, Verbindung und Exporten). Wirkung: Keine falsch dargestellten Umlaute mehr.

Je 2 Punkte (Beschreibung und Beispiel):

• Extraktion (extract): Die benötigten Daten werden aus einer oder mehreren Quellen gelesen, und nur die für die Analyse relevanten Daten werden ausgewählt. Beispiel: den CSV-Export der Schweißzellen von Rahmenwerk OWL und die Prüfergebnisse der Endkontrolle einlesen, nur die Rahmen für CSB-Rad.

• Transformation (transform): Die Daten werden bereinigt und umgewandelt: Duplikate entfernen, Einheiten und Formate vereinheitlichen, ungültige Werte korrigieren oder markieren, Daten aus verschiedenen Quellen zusammenführen. Beispiel: Zeile 2 entfernen, Zeitstempel und Rahmen-Nr. vereinheitlichen, Schweißdaten über die Rahmen-Nr. mit den Prüfergebnissen verknüpfen.

• Laden (load): Die umgewandelten Daten werden in das Zielsystem geschrieben, z. B. ein Data Warehouse oder eine Analysedatenbank, in der sie abgefragt und dargestellt werden. Beispiel: in die Analysedatenbank von CSB-Rad laden; abgewiesene oder korrigierte Datensätze stehen im Log.

Vier der folgenden, je 1 Punkt:

• Duplikat: Zeilen 1 und 2 sind identisch.
• Ausreißer bzw. Einheitenfehler: Strom 0,179 in Zeile 3 (vermutlich in kA statt A exportiert, also 179 A).
• Uneinheitliche Formate: Zeile 4 mit Rahmen-Nr. ohne Präfix RW- und Zeitstempel im Format TT.MM.JJJJ hh:mm ohne Sekunden.
• Fehlender Wert: Schutzgas in Zeile 4 ist NULL.
• Unplausible bzw. unzulässige Werte: negative Nahtzeit (Zeile 6), Nahtzeit 1440 s (Zeile 7, entspricht 24 min).
• Nicht existierende Bezüge: Zelle S3 gibt es nicht (Zeile 7), Rahmen RW-26-00999 gehört nicht zu den gefertigten Rahmen (Zeile 8).
• Auffälliger, aber möglicherweise echter Wert: Schutzgas 0 l/min in Zeile 5 bei „nicht ok“.

Drei Vorschläge, je 1 Punkt für den Umgang und 1 Punkt für die Begründung, z. B.:

• Zeile 2 löschen: Sie ist ein exaktes Duplikat von Zeile 1; die Information bleibt erhalten, und die Naht würde sonst doppelt gezählt.
• Zeile 3 korrigieren (179 A), aber erst nach Rückfrage: Der Wert liegt um den Faktor 1000 neben allen anderen; wenn Rahmenwerk OWL bestätigt, dass die Zelle in diesem Fall kA exportiert, ist die Umrechnung sicher und wird im Transformationsschritt automatisiert.
• Zeile 4 vereinheitlichen und ergänzen: Präfix RW- ergänzen und Zeitstempel ins ISO-Format bringen; den fehlenden Schutzgaswert aus dem Anlagenprotokoll nachtragen lassen oder als fehlend markieren – nicht durch einen Durchschnitt ersetzen, weil gerade die nicht bestandenen Nähte untersucht werden sollen.
• Zeile 5 behalten und markieren: 0 l/min ist zwar außerhalb des Sollbereichs, erklärt aber vermutlich die poröse Naht (z. B. leere Gasflasche). Würde der Wert gelöscht, ginge die gesuchte Fehlerursache verloren.
• Zeilen 6 und 7: Nahtzeit als fehlend markieren und den Ermittlungsprozess überprüfen lassen: Negative Zeiten und 24 min sind physikalisch bzw. technisch nicht möglich; die übrigen Werte der Zeile bleiben nutzbar.
• Zeilen 7 und 8 zurückstellen und klären: Zelle S3 und Rahmen RW-26-00999 existieren nicht; ohne Rückfrage lassen sich die Werte keinem Rahmen sicher zuordnen.

• Datenvalidierung (2 Punkte): Prüfung, ob die Daten festgelegten Regeln und Kriterien entsprechen (Datentyp, Format, Wertebereich, Pflichtfeld). Beispiel (1 Punkt): Die Nahtzeit muss eine Zahl zwischen 35 s und 45 s sein → Zeile 6 (−38 s) und Zeile 7 (1440 s) fallen auf; oder: Die Rahmen-Nr. muss dem Muster RW-JJ-NNNNN entsprechen → Zeile 4.

• Datenverifizierung (2 Punkte): Prüfung, ob die Daten tatsächlich existieren und korrekt sind, durch Abgleich mit der Realität oder einer verlässlichen Quelle. Beispiel (1 Punkt): Abgleich der Rahmen-Nr. mit den Fertigungsaufträgen → RW-26-00999 wurde nicht gefertigt (Zeile 8); oder Abgleich der Zelle mit dem Anlagenverzeichnis → S3 existiert nicht (Zeile 7).

Zwei Regeln, je 2 Punkte (Bedingung mit Grenzwert und Einheit, Reaktion), z. B.:

• Falls der Strom außerhalb von 170 A bis 200 A liegt → Log-Meldung „Strom außerhalb des Sollbereichs“, Datensatz markieren.
• Falls der Schutzgaswert fehlt oder kleiner als 12 l/min ist → Log-Meldung „Schutzgas prüfen“.
• Falls die Nahtzeit größer als 90 s ist (doppelte Sollobergrenze) → Log-Meldung „Nahtzeit unplausibel“.
• Falls es zu Rahmen-Nr. und Zeitstempel schon einen Datensatz gibt → Duplikat verwerfen, Log-Meldung „Duplikat“.
• Falls die Zelle nicht S1 oder S2 ist → Log-Meldung „unbekannte Zelle“.
• Falls die Rahmen-Nr. nicht in den Fertigungsaufträgen von CSB-Rad vorkommt → Log-Meldung „Rahmen unbekannt“.

Je 1 Punkt, z. B.:

• Rohdaten sichern und bereinigen (Duplikate entfernen, fehlerhafte Werte korrigieren oder markieren),
• standardisieren bzw. normalisieren (einheitliche Formate für Zeitstempel und Rahmen-Nr., einheitliche Einheiten),
• fehlende oder fehlerhafte Werte durch gekennzeichnete Ersatzwerte ersetzen oder die Datensätze entfernen,
• nicht benötigte Spalten entfernen,
• Daten aus verschiedenen Quellen zusammenführen (Schweißdaten mit Prüfergebnissen über die Rahmen-Nr.).

• Einzelwerte schwanken stark (viele Rahmen mit 0 min, einzelne mit 47 min); ein einzelner Rahmen sagt wenig über ein Modell aus, und kleine Unterschiede (3 min oder 4 min) sind für die Einstufung unerheblich. (2 Punkte)
• Lösung: Werte je Modell zusammenfassen (Durchschnitt bzw. Quote) und anschließend klassifizieren: Wertebereiche zu wenigen Klassen zusammenfassen und mit den Klassen weiterarbeiten. Durch die Vereinfachung werden die Ergebnisse aussagekräftig. (2 Punkte)

Bewertung: drei Klassen, mittlere Klasse enthält den Durchschnitt (1 Punkt), Grenzen für die Nacharbeit (1,5 Punkte), Grenzen für die Reklamationen und Kombination (1,5 Punkte). Beispiel:

Ein Modell wird in die schlechtere der beiden Klassen eingestuft. „Cargo XL“ ist damit kritisch. Andere plausible Grenzen sind möglich.

• Strukturiert (1 Punkt): Rahmen-Nr., Prüfdatum und Ergebnis haben ein festes Format bzw. einen festen Wertebereich und passen in feste Spalten.
• Semistrukturiert (1 Punkt): Die Messwerte im JSON-Format tragen ihre Struktur über Schlüssel selbst, aber nicht jedes Protokoll enthält dieselben Felder, und die Liste der Nahtfehler ist unterschiedlich lang.
• Unstrukturiert (2 Punkte): Foto und Bemerkung haben kein vorgegebenes Schema; ihr Inhalt muss erst interpretiert werden (Bildauswertung, Text lesen), bevor er ausgewertet werden kann.

Abweichende Zuordnungen sind richtig, wenn sie begründet sind (z. B. „Ergebnis“ als semistrukturiert, falls dort auch Freitext erlaubt ist).

• Qualitätssicherung (2 Punkte): alle vorbeugenden, geplanten Maßnahmen, die dafür sorgen, dass die Daten von vornherein die Anforderungen erfüllen, z. B. feste Exportformate und Einheiten, Plausibilitätsprüfungen in der Zelle, Kalibrierung der Sensoren, Verantwortlichkeiten.
• Qualitätskontrolle (2 Punkte): nachträgliche Prüfung der gelieferten Daten gegen festgelegte Anforderungen, Feststellen von Abweichungen und Rückmeldung, z. B. Prüfregeln beim Import, Stichproben, Fehlerquote je Lieferung.

Je 1 Punkt, z. B.:

• Prüfkriterien und Prüfregeln festlegen (Vollständigkeit, Plausibilität, Redundanzfreiheit; Grenzwerte aus der Schweißanweisung),
• Umfang festlegen (Vollprüfung jeder Lieferung durch das Skript, zusätzlich Stichproben von Hand),
• Referenzdaten für den Abgleich (Fertigungsaufträge, Anlagenverzeichnis),
• Verantwortlichkeiten (wer prüft, wer korrigiert),
• Dokumentation der Ergebnisse und Rückmeldung an Rahmenwerk OWL, Kennzahlen wie Fehlerquote je Lieferung verfolgen.

Bewertung: sinnvoller Betreff 1 Punkt, E-Mail-Form (Anrede, Grußformel) 1 Punkt, zwei Einschätzungen mit Bezug auf den Auszug 4 Punkte, zwei Maßnahmen 4 Punkte. Andere Lösungen sind richtig, wenn sie sinnvoll begründet sind.

Betreff: Datenqualität Schweißdaten vom 05.10.2026 – Einschätzung und Vorschläge

Hallo Herr Petersen,

vielen Dank für den Auszug aus dem Export der Schweißzellen. Ich habe ihn auf seine Datenqualität geprüft:

1. Die Plausibilität und Genauigkeit einzelner Werte sind nicht ausreichend. Die Nahtzeit ist in einem Datensatz negativ (−38 s) und in einem anderen mit 1440 s unrealistisch hoch; der Strom von 0,179 bei Rahmen RW-26-00413 liegt vermutlich in kA statt A vor.
2. Einheitlichkeit und Konsistenz sind eingeschränkt: Eine Rahmen-Nr. hat kein Präfix, ein Zeitstempel hat ein anderes Format, ein Datensatz ist doppelt, und es gibt Angaben zu einer Zelle S3 und einem Rahmen RW-26-00999, die wir keinem Auftrag zuordnen können. Ein Schutzgaswert fehlt.

Wir schlagen vor:

• Standardisierung und Dokumentation: Wir legen gemeinsam ein festes Exportformat fest (Rahmen-Nr. immer RW-JJ-NNNNN, Zeitstempel im ISO-Format, alle Ströme in A) und beschreiben es in einer Schnittstellendokumentation.
• Validierung an der Quelle und beim Import: Ihre Zellen prüfen die Werte schon beim Speichern auf Plausibilität (Nahtzeit größer als 0 s, Zelle S1/S2). Unser Importskript prüft jede Lieferung zusätzlich gegen die Sollbereiche, entfernt Duplikate und schreibt Auffälligkeiten in ein Log, das wir Ihnen wöchentlich zurückmelden.

Den Schutzgaswert 0 l/min bei RW-26-00415 behalten wir bewusst: Er passt zu der porösen Naht, die wir in der Endkontrolle gefunden haben. Können Sie prüfen, ob es am 05.10. gegen 06:17 Uhr eine Störung der Gasversorgung an Zelle S2 gab?

Viele Grüße
(Name), Datenteam CSB-Rad GmbH