Datenqualität und Datenimport: Altdaten prüfen, bereinigen und übernehmen

Datenqualität und Datenimport: Altdaten prüfen, bereinigen und übernehmen

https://bildung.social/@oerinformatik/

https://oer-informatik.de/datenqualitaet-import

Datenqualität, Datenimport, Datenmigration, Altdaten, Staging-Tabelle, ETL, Stammdaten, Bewegungsdaten, MariaDB, ISO/IEC 25012

tl/dr; (ca. 37 min Lesezeit): Wenn ein neues System eingeführt wird, sollen fast immer alte Daten mit: aus Tabellenkalkulationen, CSV-Exporten oder einer Vorgänger-Datenbank. Der Artikel erklärt, woran man gute Datenqualität erkennt, welche Mängel in Altdaten und in Messdaten typisch sind und welche Folgen sie beim Import haben, wie sich Validierung und Verifizierung sowie Qualitätssicherung und Qualitätskontrolle unterscheiden, welche Wege der Datenübernahme es gibt (Bereinigen von Hand, Importprogramm, Staging-Tabelle, ETL), wie Du mit MariaDB Altdaten prüfst und welche Rolle Schlüssel und referenzielle Integrität beim Import spielen. Zum Schluss geht es um die Frage, ob sich ein Import überhaupt lohnt, und wie die Datenqualität im neuen System hoch bleibt [AI-Assisted]. (Zuletzt geändert am 27.10.2026)

Dieser Artikel baut auf den Kann-Listen der Artikel Relationenmodell und Normalisierung auf. Ein durchgerechnetes Beispiel mit SQL findest Du in der Lernsituation Let’s Meet: Beispiellösung zum Import.

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Ein neues System ist schnell entwickelt, verglichen mit dem Ärger, den alte Daten machen können. Fast jedes Softwareprojekt hat eine Vorgeschichte: Bisher wurde mit einer Tabellenkalkulation gearbeitet, mit einem Formular, einer selbstgebauten Access-Datenbank oder einer Software, deren Hersteller es nicht mehr gibt. Diese Daten sollen ins neue System. Dabei gilt der alte Merksatz der Informatik: Garbage in, garbage out. Ein noch so gutes Datenmodell nützt nichts, wenn die importierten Daten widersprüchlich, unvollständig oder doppelt sind.

Was heißt Datenqualität?

Daten sind dann von guter Qualität, wenn sie für ihren Zweck taugen (fitness for use). Eine Kundenliste, aus der nur ein Newsletter verschickt wird, muss andere Anforderungen erfüllen als die Stammdaten, aus denen Rechnungen erzeugt werden. Datenqualität ist deshalb immer relativ zu einer Verwendung.

Um Datenqualität zu beschreiben, nutzt man Kriterien (auch: Dimensionen). In der Praxis und in Aufgaben sind die folgenden Begriffe verbreitet; sie stammen aus der deutschsprachigen Fachliteratur und ähneln den Dimensionen, die die Deutsche Gesellschaft für Informations- und Datenqualität (DGIQ) beschreibt:

Normativ beschreibt die Norm ISO/IEC 25012 („Data quality model“) aus der Normenreihe ISO/IEC 25000 (SQuaRE) die Datenqualität mit 15 Merkmalen, darunter accuracy, completeness, consistency, credibility und currentness. Für personenbezogene Daten verlangt außerdem die DSGVO in Art. 5 Abs. 1 lit. d, dass Daten sachlich richtig und erforderlichenfalls auf dem neuesten Stand sind. Wer falsche Altdaten ungeprüft übernimmt, hat also nicht nur ein technisches Problem.

Neben diesen Begriffen begegnen Dir weitere Bezeichnungen, die Ähnliches meinen: Validität (Gültigkeit: Die Werte halten die festgelegten Regeln ein, entspricht der Zulässigkeit), Plausibilität (die Werte sind nicht nur formal zulässig, sondern auch glaubwürdig) und Quantität (es liegen genug Datensätze vor, damit eine Auswertung aussagekräftig ist). Wichtiger als der genaue Begriff ist, dass Du ein Kriterium mit einem passenden Beispiel erklären kannst.

Validieren, verifizieren, kontrollieren

Zwei Begriffspaare werden oft verwechselt.

Datenvalidierung prüft, ob Daten den festgelegten Regeln entsprechen: Datentyp, Format, Wertebereich, Pflichtfeld, Muster. Dafür braucht man keinen Blick in die Realität, deshalb lässt sich die Validierung gut automatisieren. Beispiel: Eine Lufttemperatur muss eine Zahl zwischen −40 °C und 60 °C sein, eine deutsche Postleitzahl hat genau fünf Ziffern.

Datenverifizierung prüft, ob Daten tatsächlich stimmen, also mit der Realität oder einer verlässlichen Quelle übereinstimmen. Beispiel: Gibt es die Maschine mit dieser Nummer wirklich (Abgleich mit dem Anlagenverzeichnis)? Wohnt die Kundin noch unter dieser Adresse (Abgleich mit einem Adressdienst oder Rückfrage)? Ein Wert kann gültig und trotzdem falsch sein: 22,5 °C besteht jede Validierung, auch wenn das Thermometer in der prallen Sonne hing.

Ebenso gehören zwei Begriffe aus dem Qualitätsmanagement zusammen:

• Qualitätssicherung umfasst alle vorbeugenden Maßnahmen, die dafür sorgen, dass gute Daten entstehen und gut bleiben: Erfassungsrichtlinien, Auswahllisten, Eingabeprüfungen, Constraints, Schulungen, klare Verantwortlichkeiten. Sie setzt am Prozess an.

• Qualitätskontrolle prüft nachträglich einen vorhandenen Datenbestand oder ein Ergebnis gegen festgelegte Anforderungen und stellt Abweichungen fest: Stichproben, Prüfabfragen, Kennzahlen wie Fehlerquote oder Anteil fehlender Werte. Sie setzt am Ergebnis an und zeigt, ob die Qualitätssicherung wirkt.

Bei einer Qualitätskontrolle von Daten legst Du fest, was geprüft wird (Kriterien wie Vollständigkeit, Plausibilität, Redundanzfreiheit), woran (Prüfregeln, Grenzwerte, Referenzdaten), in welchem Umfang (Vollprüfung oder Stichprobe), wer prüft und wie die Ergebnisse dokumentiert und an die Verantwortlichen zurückgemeldet werden.

Welche Maßnahmen gegen Qualitätsmängel ergriffen werden, ist auch eine wirtschaftliche Frage. Jede Maßnahme kostet (Arbeitszeit für die Bereinigung, Programmierung von Prüfungen, Schulungen, Software), und jeder Mangel verursacht Kosten (Fehlentscheidungen, Rückläufer, Nacharbeit, verärgerte Kundschaft). Zuerst lohnen sich die Maßnahmen, die mit wenig Aufwand viel Schaden vermeiden. Das sind meist Prüfungen bei der Erfassung, denn ein Fehler wird umso teurer, je später er entdeckt wird. Jeden Datensatz von Hand zu prüfen, lohnt sich dagegen nur, wenn ein einzelner Fehler sehr teuer wäre.

Strukturierte, semistrukturierte und unstrukturierte Daten

Wie gut sich Daten prüfen und auswerten lassen, hängt auch davon ab, wie stark sie strukturiert sind:

Ein Datensatz kann alle drei Arten enthalten: Ein Produktdatenblatt hat strukturierte Angaben (Artikelnummer, Gewicht in kg), eine semistrukturierte Eigenschaftsliste und einen unstrukturierten Beschreibungstext. Wo die Zuordnung nicht eindeutig ist, kommt es auf die Begründung an: „Farbe: gelb“ ist strukturiert, wenn nur Werte aus einer festen Liste erlaubt sind, und eher semistrukturiert, wenn dort auch „gelb mit roten Punkten“ stehen darf. Für Auswertungen werden semi- und unstrukturierte Daten in strukturierte überführt, etwa indem man aus einer Eigenschaftsliste einzelne Spalten macht.

Typische Mängel in Altdaten – und was sie beim Import anrichten

Als Beispiel dient die Ausleihliste einer Schulbibliothek. Sie wurde jahrelang in einer Tabellenkalkulation geführt und soll in eine neue Bibliothekssoftware mit relationaler Datenbank übernommen werden (Auszug aus rund 4.000 Zeilen):

Wenn Du diese Tabelle in die normalisierten Tabellen schueler, medium und ausleihe übernehmen willst, stößt Du auf mehrere Probleme. Bei der Beschreibung eines Problems lohnt es sich, immer den Mangel, ein konkretes Beispiel und die Folge zu nennen:

Weitere typische Mängel, die Dir in Altdaten begegnen:

• Falsche Zeichenkodierung (Mojibake): Aus „Düsseldorf“ wird Düsseldorf, wenn UTF-8-Text als Windows-1252 gelesen wurde. Folge: falsche Namen auf Rechnungen und Briefen, die Suche nach „Düsseldorf“ findet nichts.

• Verlorene führende Nullen: Hat eine Tabellenkalkulation die Postleitzahl 01067 als Zahl gespeichert, steht dort 1067. Folge: ungültige Adressen, Fehlzustellungen.

• Dezimal- und Prozentangaben: 19 %, 0,19 und 19 meinen dasselbe – oder auch nicht. Wird 0,19 als 0,19 % gelesen, ist der berechnete Steuerbetrag rund hundertfach zu klein.

• Veraltete Daten: Kund*innen, die es nicht mehr gibt, oder überholte Adressen. Folge: Zugänge für nicht mehr existierende Firmen, Post an falsche Adressen, verfälschte Statistiken.

• Ausreißer und unplausible Werte: Messwerte um den Faktor 10 zu groß (Komma vergessen), negative Mengen. Folge: falsche Auswertungen, falsche Entscheidungen.

Mess- und Sensordaten: Ausreißer, Lücken, Duplikate

Daten, die Maschinen und Sensoren automatisch erfassen, haben andere Schwächen als von Hand gepflegte Listen. Ein Beispiel ist der Export einer Wetterstation auf dem Schuldach, die alle zehn Minuten misst:

Wie Du mit solchen Datensätzen umgehst, hängt vom Zweck der Auswertung ab. Vorschläge solltest Du immer begründen:

• Löschen bzw. ausfiltern: Duplikate (die Information bleibt in der ersten Zeile erhalten) und Zeilen, in denen alle wesentlichen Werte fehlen.

• Korrigieren, wenn die Ursache sicher ist: 49 wird zu 4,9, wenn der Kommafehler im Export nachgewiesen ist; Kennung 01 wird zu WS-01; Zeitpunkte werden vereinheitlicht.

• Nachtragen, wenn sich der Wert aus einer anderen Quelle ermitteln lässt (Stammdaten, Protokoll einer Nachbarstation, Rückfrage bei der erfassenden Person).

• Ersetzen durch einen gekennzeichneten Ersatzwert (Default, Mittelwert der Nachbarwerte, Interpolation), wenn die Auswertung lückenlose Reihen braucht – nie stillschweigend.

• Markieren statt löschen, wenn unklar ist, ob ein Wert falsch ist: Ein extremer Wert kann ein echtes Ereignis sein (Sturmböe, Maschinenstörung) – und gerade das will man vielleicht finden.

• Ursache beheben: Negativer Wind oder 132 % Luftfeuchte deuten auf einen Fehler bei der Erfassung hin. Der Erfassungsprozess (Sensor, Kalibrierung, Export) muss überprüft werden, sonst kommen dieselben Fehler mit jeder Lieferung wieder.

Plausibilitätsregeln und Logging

Damit nicht jede Lieferung von Hand durchgesehen werden muss, formuliert man Plausibilitätsregeln, die ein Programm für jeden Datensatz prüft. Verstöße werden nicht einfach verworfen, sondern mit Zeitpunkt, Datensatz und verletzter Regel in eine Logdatei (ein Fehlerprotokoll) geschrieben, damit sie nachvollziehbar bleiben. Die Regeln haben die Form „Falls Bedingung, dann Log-Meldung (und ggf. Aktion)“:

• Falls die Temperatur außerhalb von −40 °C bis 60 °C liegt → Log-Meldung, Wert markieren.

• Falls sich die Temperatur gegenüber der vorherigen Messung derselben Station um mehr als 5 °C ändert → Log-Meldung „Sprung“.

• Falls alle Messwerte einer Zeile NULL sind → Zeile verwerfen, Log-Meldung „Datenlücke“.

• Falls es zu Station und Zeitpunkt schon einen Datensatz gibt → Duplikat verwerfen, Log-Meldung.

• Falls die Luftfeuchte nicht zwischen 0 % und 100 % liegt → Log-Meldung.

Auf den Auszug der Wetterstation angewendet, fallen das Duplikat, der Temperatursprung auf 49 °C und die Datenlücke automatisch auf:

Gute Regeln sind konkret (Grenzwert mit Einheit), prüfen feste Grenzen und Veränderungen gegenüber früheren Werten und legen fest, was mit dem Datensatz geschieht.

Rohdaten in Klassen einteilen

Manchmal ist nicht ein Mangel das Problem, sondern die Feinheit der Rohdaten. Sollen z. B. Lernvideos einer Plattform als „beliebt“, „durchschnittlich“ oder „wenig gefragt“ eingestuft werden, helfen exakte Werte wie 85, 2 oder 12 Aufrufe und Betrachtungsdauern von 12 s oder 6 min 7 s wenig: Der Unterschied zwischen 2 und 3 Aufrufen ist für die Aussage unerheblich, und einzelne Extremwerte verzerren die Auswertung. Man klassifiziert (diskretisiert) deshalb: Wertebereiche werden zu wenigen Klassen zusammengefasst, und mit den Klassen wird weitergearbeitet.

Für einen Vorschlag zur Einteilung gehst Du so vor:

1. Anzahl der Klassen festlegen (z. B. drei).

2. Grenzen so wählen, dass die mittlere Klasse den Durchschnitt enthält; Anhaltspunkte sind Durchschnitt, Spannweite und Extremwerte (oder Quantile).

3. Jede Kennzahl getrennt einteilen und angeben, wie die Klassen kombiniert werden (z. B. „beliebt, wenn mindestens eine Kennzahl in der oberen Klasse liegt und keine in der unteren“).

Beispiel: Ein Lernvideo wird im Durchschnitt 1,5-mal am Tag aufgerufen und 40 s lang angesehen, das beliebteste 30-mal am Tag und 4 min lang. Ein Vorschlag: Aufrufe unter 1 je Tag „wenig gefragt“, 1 bis unter 3 „durchschnittlich“, ab 3 „beliebt“; Betrachtungsdauer unter 30 s „wenig gefragt“, 30 s bis 1 min 30 s „durchschnittlich“, darüber „beliebt“. Andere Grenzen sind ebenso richtig, wenn sie nachvollziehbar begründet sind.

Stammdaten und Bewegungsdaten: Was soll überhaupt mit?

Bevor Du überlegst, wie Du importierst, solltest Du klären, was importiert werden soll. Dabei hilft die Unterscheidung:

• Stammdaten beschreiben Objekte, die über längere Zeit gleich bleiben und immer wieder gebraucht werden: Kund*innen, Händler, Artikel, Mitarbeitende, Medien einer Bibliothek.

• Bewegungsdaten (Transaktionsdaten) entstehen laufend durch die Geschäftsprozesse und beziehen sich auf Stammdaten: Bestellungen, Buchungen, Ausleihen, Kontrollen, Messwerte.

Stammdaten werden im neuen System sofort gebraucht; ihre Bereinigung lohnt sich fast immer. Bei Bewegungsdaten ist zu fragen, ob sie im neuen System wirklich gebraucht werden (z. B. für Auswertungen, Gewährleistung, Nachweise) oder ob es reicht, sie lesbar zu archivieren. Bewegungsdaten verweisen auf Stammdaten – sind die Stammdaten mangelhaft, lassen sich Bewegungsdaten nicht sauber zuordnen.

Wege der Datenübernahme

Grundsätzlich gibt es zwei Strategien, mit mangelhaften Daten umzugehen. Beide werden oft kombiniert:

1. Daten vor dem Import bereinigen: Die Fachabteilung (oder Du) korrigiert die Quelldaten von Hand oder mit Hilfsmitteln der Tabellenkalkulation – vereinheitlichen, Dubletten zusammenführen, fehlende Angaben nachtragen. Das ist bei wenigen Hundert Datensätzen realistisch, bei vielen Tausend sehr aufwendig.

2. Ein Importprogramm mit Fehlerbehandlung schreiben: Das Programm erkennt die unterschiedlichen Formate, wandelt sie um, prüft jeden Datensatz gegen Regeln und schreibt Datensätze, die es nicht sicher zuordnen kann, in ein Fehlerprotokoll, statt abzubrechen. Diese Datensätze werden anschließend von Hand geklärt. Das Programm ist aufwendig zu erstellen, lohnt sich aber bei großen Datenmengen oder wenn mehrfach importiert wird (z. B. mehrere Testimporte und der endgültige Import).

Technisch gibt es mehrere Möglichkeiten, einen Datenbestand von einem System in ein anderes zu migrieren:

In der Praxis landet man fast immer bei einer Variante des ETL-Prozesses mit einer Staging-Tabelle: Die Rohdaten werden zunächst unverändert in eine Zwischentabelle geladen, deren Spalten alle Text aufnehmen (z. B. VARCHAR). Dort lassen sich die Daten mit SQL untersuchen und umwandeln, ohne dass Datentypen oder Constraints den Ladevorgang abbrechen. Erst geprüfte Datensätze wandern in die eigentlichen Tabellen.

Weil Fachliteratur und Werkzeuge meist englischsprachig sind, lohnt es sich, die Begriffe zu kennen: extract (die relevanten Daten aus einer oder mehreren Quellen lesen), transform (bereinigen, vereinheitlichen, umrechnen, zusammenführen, in das Zielformat bringen), load (in die Zieldatenbank, das Zielsystem oder ein Data Warehouse schreiben), data cleansing (Bereinigung), data profiling (Datenprofil), staging area (Zwischenbereich) und data preparation (Datenaufbereitung). Bei der Datenaufbereitung für eine Analyse werden Rohdaten bereinigt, vereinheitlicht (normalisiert, z. B. Einheiten und Formate), fehlerhafte Werte entfernt oder durch gekennzeichnete Ersatzwerte ersetzt und nicht benötigte Spalten entfernt – im Kern dieselben Schritte wie beim Import.

Der Importprozess Schritt für Schritt

1. Zielmodell analysieren und Mapping festlegen: Welche alte Spalte landet in welcher neuen Tabelle und Spalte? Welche Datentypen, Pflichtfelder und Schlüssel gibt es im Ziel? Das Ergebnis ist eine Zuordnungstabelle (Mapping).

2. Altdaten exportieren und sichern: Bevor irgendetwas verändert wird, entsteht eine Sicherungskopie der Quelldaten. Jede Bereinigung muss nachvollziehbar und wiederholbar sein.

3. Rohdaten in die Staging-Tabelle laden.

4. Datenprofil erstellen (Data Profiling): Wie viele Datensätze gibt es? Wie viele Werte fehlen je Spalte? Welche Formate kommen vor? Welche Werte sind doppelt? So erkennst Du das Ausmaß der Probleme und kannst den Aufwand schätzen.

5. Vereinheitlichen und bereinigen: Formate standardisieren (Datum, Telefonnummern, Prozentangaben), Freitexte auf feste Werte abbilden, Dubletten zusammenführen, nicht mehr benötigte Spalten weglassen.

6. Validieren: Jeder Datensatz wird gegen Regeln geprüft (Pflichtfelder, Wertebereiche, Muster, Fremdschlüssel). Ist die Fehlerquote zu hoch, wird weiter bereinigt.

7. Laden und protokollieren: Gültige Datensätze kommen in die Zieltabellen – in der richtigen Reihenfolge: erst die Tabellen, auf die verwiesen wird (z. B. kunde), dann die verweisenden (z. B. adresse, bestellung). Abgewiesene Datensätze landen mit Grund im Fehlerprotokoll.

8. Abnehmen und dokumentieren: Die Fachabteilung prüft Stichproben und Summen (Anzahl Datensätze vorher und nachher, Summen von Beträgen). Das Vorgehen und alle Entscheidungen werden dokumentiert.

Praxis mit MariaDB: Altdaten in der Staging-Tabelle prüfen

Als Beispiel dient wieder die Ausleihliste der Schulbibliothek. Sie wurde als CSV-Datei exportiert (Trennzeichen Semikolon, erste Zeile mit Spaltennamen).

Rohdaten laden

CREATE TABLE import_ausleihe (
  datum     VARCHAR(20),
  schueler  VARCHAR(80),
  klasse    VARCHAR(10),
  medium    VARCHAR(100),
  rueckgabe VARCHAR(20),
  bemerkung VARCHAR(200)
);

LOAD DATA LOCAL INFILE 'ausleihliste.csv'
INTO TABLE import_ausleihe
CHARACTER SET utf8mb4
FIELDS TERMINATED BY ';' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\r\n'
IGNORE 1 LINES;

Alle Spalten sind bewusst Text, auch die Datumsangaben. So geht beim Laden nichts verloren (auch keine führende Null einer Postleitzahl oder Kundennummer), und kein Datensatz wird abgewiesen. Die Angabe CHARACTER SET muss zur tatsächlichen Kodierung der Datei passen – sonst entsteht genau beim Laden Mojibake.

Ein Datenprofil erstellen

Zuerst verschaffst Du Dir einen Überblick, wie viele Werte fehlen oder offensichtlich falsch sind:

SELECT COUNT(*)              AS datensaetze,
       SUM(schueler = '')    AS ohne_name,
       SUM(rueckgabe = '')   AS ohne_rueckgabe,
       SUM(rueckgabe <> '' AND rueckgabe NOT REGEXP '^[0-9]') AS rueckgabe_als_text
FROM import_ausleihe;

In MariaDB ergibt ein Vergleich 1 (wahr) oder 0 (falsch); SUM() zählt so die Treffer. Für den Auszug oben ergibt sich: 6 Datensätze, davon 1 ohne Namen, 1 ohne Rückgabe und 1 mit Text statt Rückgabedatum. Eine leere Rückgabe ist dabei nicht unbedingt ein Mangel: Sie kann auch bedeuten, dass das Buch noch ausgeliehen ist. Welche Schreibweisen in einer Spalte vorkommen, zeigt eine Gruppierung:

SELECT klasse, COUNT(*) AS anzahl
FROM import_ausleihe
GROUP BY klasse
ORDER BY klasse;

Bei 4.000 Zeilen siehst Du so auf einen Blick, dass es neben ITA24 auch ITA 24 gibt.

Formate und Dubletten finden

Mit regulären Ausdrücken (REGEXP) prüfst Du, ob Werte einem Muster entsprechen. Datumswerte im Format TT.MM.JJJJ:

SELECT datum, schueler
FROM import_ausleihe
WHERE datum NOT REGEXP '^[0-9]{2}[.][0-9]{2}[.][0-9]{4}$';

Ergebnis: die Zeile mit 2025-09-04. Achtung: Das Muster prüft nur die Form. 31.09.2025 passt zum Muster, ist aber kein gültiges Datum. Kalenderdaten prüfst Du zusätzlich, z. B. im Importprogramm (in Java wirft LocalDate.parse(text, DateTimeFormatter.ofPattern("dd.MM.uuuu").withResolverStyle(ResolverStyle.STRICT)) bei 31.09.2025 eine Exception).

Dubletten und Schreibvarianten findest Du, indem Du nach einer vereinheitlichten Form gruppierst (hier: Leerzeichen entfernt) und zählst, wie viele verschiedene Originalwerte dahinterstecken:

SELECT REPLACE(klasse, ' ', '') AS klasse_bereinigt,
       COUNT(DISTINCT klasse)   AS schreibweisen,
       GROUP_CONCAT(DISTINCT klasse SEPARATOR ' | ') AS varianten
FROM import_ausleihe
GROUP BY REPLACE(klasse, ' ', '')
HAVING COUNT(DISTINCT klasse) > 1;

Ergebnis: ITA24 mit zwei Schreibweisen (ITA24 | ITA 24). Personen wie „Yilmaz, Emre“ und „Emre Yılmaz“ findet SQL nur mit mehr Aufwand (Vor- und Nachname trennen, Kleinbuchstaben, Sonderzeichen ersetzen, Hilfsfunktionen wie SOUNDEX()). Am Ende entscheidet meist ein Mensch, ob zwei Einträge dieselbe Person meinen – „Schäfer, L.“ lässt sich ohne Rückfrage gar nicht zuordnen.

Fehler markieren statt abbrechen

Statt fehlerhafte Datensätze sofort zu löschen, ergänzt Du eine Prüfspalte und sammelst darin alle gefundenen Probleme:

ALTER TABLE import_ausleihe ADD COLUMN fehler VARCHAR(255) NULL;

UPDATE import_ausleihe
SET fehler = CONCAT_WS('; ', fehler, 'Datum nicht TT.MM.JJJJ')
WHERE datum NOT REGEXP '^[0-9]{2}[.][0-9]{2}[.][0-9]{4}$';

UPDATE import_ausleihe
SET fehler = CONCAT_WS('; ', fehler, 'Name fehlt')
WHERE schueler = '';

UPDATE import_ausleihe
SET fehler = CONCAT_WS('; ', fehler, 'Rückgabe nicht TT.MM.JJJJ')
WHERE rueckgabe <> ''
  AND rueckgabe NOT REGEXP '^[0-9]{2}[.][0-9]{2}[.][0-9]{4}$';

CONCAT_WS überspringt NULL-Werte, deshalb entsteht beim ersten Fehler kein führendes Semikolon, und mehrere Fehler eines Datensatzes stehen nebeneinander. Die Liste SELECT * FROM import_ausleihe WHERE fehler IS NOT NULL ist Dein Fehlerprotokoll für die Fachabteilung. Datensätze ohne Eintrag in fehler werden anschließend mit INSERT INTO … SELECT … umgewandelt (z. B. Datum mit STR_TO_DATE(datum, '%d.%m.%Y')) und in die Zieltabellen übernommen (siehe SQL: Datensätze einfügen). Die Rückgabe darf leer sein (Buch noch ausgeliehen), Werte wie zurück oder 17.9.25 werden aber markiert – ohne diese Prüfung würde STR_TO_DATE('17.9.25', '%d.%m.%Y') stillschweigend das Jahr 0025 ergeben. Ungültige Kalenderdaten wie 31.09.2025 passen dagegen zum Muster und bleiben unmarkiert; sie musst Du zusätzlich prüfen, z. B. im Importprogramm (siehe Abschnitt „Formate und Dubletten finden“).

Typische Fehlermeldungen beim Import

Ein Datentyp-Fehler ist übrigens nicht immer ein Datenfehler: Ist z. B. eine Rechnungsnummer im Zielmodell als Zahl definiert, enthalten die Altdaten aber Buchstaben (RE-2026-00457), dann ist das Zielmodell falsch.

Reihenfolge, Schlüssel und referenzielle Integrität

Fremdschlüssel sorgen dafür, dass ein Verweis nur auf einen vorhandenen Datensatz zeigen darf (referenzielle Integrität). Daraus folgt eine feste Reihenfolge – nicht nur beim Laden, sondern schon beim Anlegen: Eine Tabelle mit Fremdschlüssel (n-Seite der Beziehung) lässt sich mit FOREIGN KEY … REFERENCES erst anlegen, wenn die Tabelle der 1-Seite existiert. Für die Ausleihe heißt das: erst schueler und medium, dann ausleihe. Beim Löschen ist es umgekehrt.

Die Meldung „referenzielle Integrität verletzt“ tritt auch im laufenden Betrieb auf, etwa wenn jemand eine Rechnung für eine Kundin speichern will, die in der Kundentabelle noch nicht angelegt ist, oder wenn ein Datensatz gelöscht werden soll, auf den noch andere verweisen.

Manche Importfehler zeigen, dass das Zielmodell nicht stimmt. Ein typischer Fall ist ein zu knapp gewählter zusammengesetzter Primärschlüssel. Besteht der Schlüssel der Tabelle ausleihe nur aus (schueler_id, medium_id), kann dieselbe Person dasselbe Buch nur ein einziges Mal ausleihen – beim zweiten Mal meldet die Datenbank Duplicate entry. Korrigiert wird, indem man den Schlüssel um das unterscheidende Merkmal erweitert ((schueler_id, medium_id, ausleihdatum)) oder einen künstlichen Schlüssel ausleihe_id einführt und die fachliche Regel mit einem UNIQUE-Constraint absichert:

CREATE TABLE ausleihe (
  ausleihe_id   INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  schueler_id   INT UNSIGNED NOT NULL,
  medium_id     INT UNSIGNED NOT NULL,
  ausleihdatum  DATE NOT NULL,
  rueckgabe     DATE NULL,
  CONSTRAINT uq_ausleihe UNIQUE (schueler_id, medium_id, ausleihdatum),
  CONSTRAINT fk_aus_schueler FOREIGN KEY (schueler_id) REFERENCES schueler (schueler_id),
  CONSTRAINT fk_aus_medium   FOREIGN KEY (medium_id)   REFERENCES medium (medium_id)
);

Falsche Zeichenkodierung reparieren

Steht in den Altdaten Düsseldorf, wurde UTF-8-kodierter Text irgendwann als Windows-1252 gelesen und wieder gespeichert. Repariert wird, indem man den Text zurück in die Bytes von Windows-1252 umwandelt und diese Bytes als UTF-8 liest (in Python: text.encode('cp1252').decode('utf-8')). Wichtig: nur auf die betroffenen Datensätze anwenden – auf korrekten Text angewandt, bricht die Umwandlung mit einem Fehler ab (UnicodeDecodeError) oder verfälscht ihn.

Lohnt sich der Import überhaupt? Beurteilen und Stellung nehmen

Nicht jede Altdatenmenge ist es wert, mit großem Aufwand übernommen zu werden. Für eine Beurteilung wägst Du ab:

• Nutzen der Daten: Werden sie im neuen System gebraucht (laufende Geschäftsbeziehungen, Auswertungen über mehrere Jahre, Nachweise, Gewährleistung)? Stammdaten aktiver Kund*innen sind wertvoller als zehn Jahre alte Bewegungsdaten.

• Menge und Fehlerquote: Wie viele Datensätze sind betroffen, wie viele davon fehlerhaft? 30 fehlerhafte von 40 lohnen eher eine Nacherfassung, 300 von 30.000 eher ein Importprogramm mit Fehlerprotokoll.

• Aufwand: Händisches Bereinigen und ein Importprogramm mit Fehlerbehandlung kosten beide Zeit. Wird nur einmal importiert, ist ein aufwendiges Programm schwer zu rechtfertigen.

• Risiko: Falsch zugeordnete Datensätze sind oft schlimmer als fehlende – sie fallen nicht auf und verfälschen Ergebnisse.

• Recht und Datenschutz: Aufbewahrungspflichten (z. B. für Rechnungen) können verlangen, Daten weiter verfügbar zu halten – das heißt aber nicht, dass sie ins neue System müssen. Umgekehrt verlangt die DSGVO Datenminimierung und Speicherbegrenzung: Personenbezogene Daten, die niemand mehr braucht, sollten nicht migriert, sondern gelöscht werden.

• Alternativen: nur Stammdaten übernehmen und Bewegungsdaten archivieren (z. B. als schreibgeschützte Datenbank oder Export), nur die letzten Jahre übernehmen, Daten im neuen System neu erfassen lassen.

Eine gute Stellungnahme legt sich fest und begründet die Entscheidung mit den Gegebenheiten des Falls. Beide Richtungen können richtig sein:

• Gegen den Import: „Bereinigung und Importprogramm sind sehr aufwendig, die Daten sind nur eingeschränkt verwertbar. Der Import lohnt sich wegen der schlechten Datenqualität nicht; die alte Liste wird schreibgeschützt archiviert.“

• Für den Import: „Die Daten werden für die Auswertungen der nächsten Jahre gebraucht. Der höhere Aufwand für Bereinigung und ein Importprogramm mit Fehlerprotokoll muss deshalb in Kauf genommen werden.“

Ergebnisse an die Fachabteilung melden

Die Ergebnisse einer Datenprüfung gehen meist an Menschen, die keine SQL-Abfragen lesen: Fachabteilung, Auftraggeber oder Dienstleister. Eine kurze E-Mail oder Notiz sollte deshalb

• einen aussagekräftigen Betreff haben („Datenqualität Export Wetterstation März: Einschätzung und Vorschläge“),

• mit einer Anrede beginnen und mit einer Grußformel enden,

• die Einschätzung mit Kriterium und Beleg nennen („Die Vollständigkeit ist eingeschränkt: In 4 % der Zeilen fehlen alle Messwerte, z. B. am 02.03. um 08:30 Uhr.“),

• Maßnahmen vorschlagen und begründen (Bereinigung, Validierungsregeln, Standards für Formate und Einheiten, Prüfung der Erfassung),

• offene Fragen und die nächsten Schritte nennen.

Konkrete Zahlen und Beispiele aus den Daten überzeugen mehr als allgemeine Aussagen wie „die Daten sind schlecht“.

Datenqualität dauerhaft sichern

Nach dem Import soll die Qualität nicht wieder sinken. Die wichtigsten Maßnahmen setzen dort an, wo die Mängel in den Altdaten entstanden sind:

• Schlüssel statt Namen: Personen, Artikel und Kund*innen werden über eindeutige Schlüssel ausgewählt, nicht über frei getippte Namen.

• Auswahllisten statt Freitext: feste Werte über Auswahlfelder, Fremdschlüssel auf Werte-Tabellen oder ENUM.

• Eingabevalidierung in der Oberfläche: Datumsauswahl, Formatprüfung (Postleitzahl, E-Mail, USt-IdNr.), Wertebereiche, sofortige Rückmeldung mit verständlicher Fehlermeldung.

• Constraints in der Datenbank: NOT NULL, UNIQUE, CHECK, Fremdschlüssel und passende Datentypen (DATE, DECIMAL) – sie greifen auch dann, wenn ein anderes Programm oder ein Import an der Oberfläche vorbeischreibt (siehe SQL-DDL: Datentypen).

• Dublettenprüfung bei der Eingabe: Hinweis „Es gibt bereits eine Person mit diesem Namen und Geburtsdatum“ vor dem Speichern.

• Verantwortlichkeiten und Regeln: Wer pflegt welche Stammdaten? Erfassungsrichtlinien, regelmäßige Prüfberichte (z. B. Kund*innen ohne Bestellung seit drei Jahren), Pflege bei Änderungen.

Leitfragen

1. Was bedeutet „Datenqualität“, und welche Kriterien kannst Du nennen und an einem Beispiel erklären? Antwort

Daten haben gute Qualität, wenn sie für ihren Zweck taugen (fitness for use) – Datenqualität ist also immer relativ zu einer Verwendung. Kriterien sind z. B. Korrektheit (Geburtsjahr 1902 statt 2002 ist falsch), Vollständigkeit, Konsistenz, Einheitlichkeit, Eindeutigkeit, Redundanzfreiheit, Aktualität, Genauigkeit und Plausibilität; normativ beschreibt ISO/IEC 25012 die Datenqualität (siehe Abschnitt „Was heißt Datenqualität?“).

2. Welche typischen Mängel findest Du in einer manuell geführten Tabelle, und welche Folge hätte jeder Mangel bei einem Import in eine relationale Datenbank? Antwort

Typisch sind uneinheitliche Formate (Importprogramm bricht ab, Klassen werden doppelt angelegt), ungültige Werte wie 31.09.2025 (Datensatz wird abgewiesen oder falsch umgerechnet), Namen statt Schlüssel (Dubletten, falsche Zuordnung), Freitext statt fester Werte (falsche Auswertungen), fehlende Pflichtangaben (Zuordnung unmöglich, NOT NULL lässt den Import scheitern), widersprüchliche Daten und in Bemerkungen versteckte Informationen. Dazu kommen falsche Zeichenkodierung, verlorene führende Nullen und veraltete Daten. Nenne jeweils Mangel, Beispiel und Folge (siehe Abschnitt „Typische Mängel in Altdaten – und was sie beim Import anrichten“).

3. Worin unterscheiden sich Stamm- und Bewegungsdaten, und warum spielt das für die Entscheidung über einen Import eine Rolle? Antwort

Stammdaten beschreiben langlebige Objekte, die immer wieder gebraucht werden (Kund*innen, Artikel, Medien), Bewegungsdaten entstehen laufend in Geschäftsprozessen und verweisen auf Stammdaten (Bestellungen, Ausleihen). Stammdaten braucht das neue System sofort, ihre Bereinigung lohnt sich fast immer; bei Bewegungsdaten fragst Du, ob sie wirklich gebraucht werden oder ob eine Archivierung reicht – und ohne saubere Stammdaten lassen sie sich nicht zuordnen (siehe Abschnitt „Stammdaten und Bewegungsdaten: Was soll überhaupt mit?“).

4. Welche Wege gibt es, mangelhafte Daten dennoch zu importieren, und wofür ist eine Staging-Tabelle gut? Antwort

Du kannst die Daten vor dem Import von Hand bereinigen oder ein Importprogramm mit Fehlerbehandlung schreiben, das Formate umwandelt, Datensätze prüft und unklare Fälle ins Fehlerprotokoll schreibt; technisch gibt es Export und Import, ETL, Parallelbetrieb mit Replikation oder Neuaufbau mit Nacherfassung. Eine Staging-Tabelle nimmt die Rohdaten unverändert in Textspalten auf, sodass nichts verloren geht und kein Datentyp oder Constraint den Ladevorgang abbricht – dort prüfst und wandelst Du mit SQL, bevor geprüfte Datensätze in die Zieltabellen wandern (siehe Abschnitt „Wege der Datenübernahme“).

5. Welche Schritte umfasst ein Importprozess, und in welcher Reihenfolge müssen Tabellen mit Fremdschlüsseln geladen werden? Antwort

Die Schritte sind: Zielmodell analysieren und Mapping festlegen, Altdaten sichern, Rohdaten in die Staging-Tabelle laden, Datenprofil erstellen, vereinheitlichen und bereinigen, validieren, laden und protokollieren, abnehmen und dokumentieren. Beim Laden kommen zuerst die Tabellen, auf die verwiesen wird (z. B. kunde), dann die verweisenden (z. B. bestellung) – sonst meldet MariaDB eine Fremdschlüsselverletzung (siehe Abschnitt „Der Importprozess Schritt für Schritt“ und Abschnitt „Typische Fehlermeldungen beim Import“).

6. Wie findest Du mit SQL fehlende Werte, uneinheitliche Formate und Dubletten? Antwort

Fehlende Werte zählst Du im Datenprofil, z. B. mit SUM(schueler = ''), weil ein Vergleich in MariaDB 1 oder 0 liefert. Uneinheitliche Formate zeigt eine Gruppierung mit GROUP BY oder eine Musterprüfung mit NOT REGEXP '^[0-9]{2}[.][0-9]{2}[.][0-9]{4}$'. Dubletten und Schreibvarianten findest Du, indem Du nach einer vereinheitlichten Form gruppierst und mit HAVING COUNT(DISTINCT …) > 1 filterst (siehe Abschnitt „Ein Datenprofil erstellen“ und Abschnitt „Formate und Dubletten finden“).

7. Welche Gesichtspunkte wägst Du ab, wenn Du beurteilen sollst, ob sich ein Import lohnt? Antwort

Du wägst den Nutzen der Daten im neuen System, Menge und Fehlerquote, den Aufwand für Bereinigung und Importprogramm, das Risiko falsch zugeordneter Datensätze sowie Recht und Datenschutz (Aufbewahrungspflichten, Datenminimierung nach DSGVO) ab und prüfst Alternativen wie das Archivieren von Bewegungsdaten. Eine gute Stellungnahme legt sich fest und begründet mit den Gegebenheiten des Falls – dafür wie dagegen kann richtig sein (siehe Abschnitt „Lohnt sich der Import überhaupt? Beurteilen und Stellung nehmen“).

8. Mit welchen Maßnahmen bleibt die Datenqualität im neuen System hoch? Antwort

Hilfreich sind Schlüssel statt frei getippter Namen, Auswahllisten statt Freitext, Eingabevalidierung in der Oberfläche, Constraints in der Datenbank (NOT NULL, UNIQUE, CHECK, Fremdschlüssel, passende Datentypen), eine Dublettenprüfung bei der Eingabe sowie klare Verantwortlichkeiten, Erfassungsrichtlinien und regelmäßige Prüfberichte (siehe Abschnitt „Datenqualität dauerhaft sichern“).

9. Worin unterscheiden sich Datenvalidierung und Datenverifizierung, und was ist der Unterschied zwischen Qualitätssicherung und Qualitätskontrolle? Antwort

Die Validierung prüft, ob Daten festgelegten Regeln entsprechen (Datentyp, Format, Wertebereich, Pflichtfeld), z. B. ob eine Temperatur eine Zahl zwischen −40 °C und 60 °C ist. Die Verifizierung prüft, ob die Daten tatsächlich stimmen, z. B. durch Abgleich einer Maschinennummer mit dem Anlagenverzeichnis. Qualitätssicherung ist vorbeugend und setzt am Prozess an (Richtlinien, Eingabeprüfungen, Constraints, Schulungen), Qualitätskontrolle prüft nachträglich einen Datenbestand gegen Anforderungen (Stichproben, Prüfabfragen, Fehlerquoten) (siehe Abschnitt „Validieren, verifizieren, kontrollieren“).

10. Woran erkennst Du Probleme in Mess- und Sensordaten, und wie gehst Du mit ihnen um? Antwort

Typisch sind Duplikate, Ausreißer durch Einheiten- oder Kommafehler, Datenlücken (NULL), uneinheitliche Kennungen und Formate sowie unzulässige Werte (negative Geschwindigkeit, Luftfeuchte über 100 %). Je nach Zweck werden Datensätze begründet gelöscht, sicher korrigiert, aus anderen Quellen nachgetragen, durch gekennzeichnete Ersatzwerte ersetzt oder markiert; außerdem wird die Ursache bei der Erfassung behoben. Plausibilitätsregeln der Form „Falls Bedingung, dann Log-Meldung“ erkennen solche Fälle automatisch. Sind die Rohwerte für eine Einstufung zu fein, bildest Du wenige Klassen, deren mittlere den Durchschnitt enthält (siehe Abschnitt „Mess- und Sensordaten: Ausreißer, Lücken, Duplikate“).

Links und weitere Informationen

• Übungsaufgaben zu Datenqualität und Datenimport

• Let’s Meet: Beispiellösung zum Import (Lernsituation)

• Normalisierung und Anomalien

• Relationenmodell: Primär- und Fremdschlüssel

• SQL-DDL: Datentypen und SQL: Datensätze einfügen

• ISO/IEC 25012: Data quality model (Übersicht auf iso25000.com)

• MariaDB-Dokumentation: LOAD DATA INFILE

• MariaDB-Dokumentation: REGEXP

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Datenqualität und Datenimport: Altdaten prüfen, bereinigen und übernehmen” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/datenqualitaet-import veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/daten-ki/datenanalyse-ki. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 27.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]