Datenqualität mit SQL prüfen — ein konfigurierbares Framework, das schlechte Daten generisch aufspürt

Schlechte Daten kündigen sich nicht an. Ein Alter von 200 Jahren, eine doppelte Kundennummer, ein Ländercode, den es nicht gibt — im Quellsystem fällt das niemandem auf. Erst wenn der ETL-Lauf die Sätze in die strikt modellierte Zielschicht schieben will, bricht der Load ab: an einem CHECK, an einem UNIQUE-Index, an einem Fremdschlüssel. Datenqualität mit SQL prüfen heißt, genau … Weiterlesen

ETL vs. ELT — woran du erkennst, welches Muster du wirklich gebaut hast

„Wir machen ETL.“ Der Satz fällt in fast jedem Daten-Team — und stimmt oft nicht. Wenn jede Transformation als Stored Procedure läuft, nachdem die Rohdaten bereits unverändert in eine Staging-Tabelle geladen wurden, dann ist das der Sache nach ELT. Das Etikett verdeckt, was wirklich passiert. Der Unterschied ETL vs. ELT entscheidet sich nicht an der Reihenfolge der Buchstaben, sondern … Weiterlesen

SQL-Konventionen // PL/pgSQL-Prozeduren, die man in zwei Jahren noch lesen kann

Wer eine Stored Procedure schreibt, schreibt sie für jemanden, der sie nicht kennt – meist für sich selbst, 18 Monate später, um 23 Uhr, während ein ETL-Lauf hängt. Lesbarkeit ist keine Kosmetik, sondern Debugging-Zeit. PostgreSQL zwingt einen zu fast nichts: Namen sind frei, Einrückung ist egal, ein RAISE EXCEPTION schluckt jeden inline-zusammengebauten Text. Genau deshalb driften Prozeduren-Sammlungen ohne Konvention innerhalb … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für date, datetime, datetime2 und time sicher anwenden

Wer einmal eine CSV-Spalte mit gemischten Datums-Formaten in eine datetime-Spalte importieren musste, weiß: Datenqualität beginnt bei der Typ-Konvertierung. SQL Server lässt einen mit style-Codes alleine, sobald das Format vom Standard abweicht — TRY_CONVERT deckt die dokumentierten Formate ab, alles andere braucht eine eigene Funktion. Das nimmst du mit: Voraussetzung: SQL Server 2017+ (für TRY_CONVERT-Styles 23/126), für die Postgres-Brücke PostgreSQL 12+. Inhalt Überblick Die wohl herausforderndste Konvertierung … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für bit sicher anwenden — Ja/Nein-Werte konvertieren

Datenqualität beginnt bei der Typ-Konvertierung — und bei bit-Spalten zeigt sich das schon beim Eingangswert: Yes/No-Informationen liegen in Legacy-Quellen in unterschiedlichsten Notationen vor (‚J‘, ‚Y‘, ‚ON‘, ‚1‘, ‚x‘, ‚-‚, …). SQL Servers eingebautes TRY_CONVERT(bit, …) deckt nur den Ziffern-Standard plus ‚true’/’false‘ ab — alles andere braucht eine eigene Konvertierungs-Funktion. Dieser Artikel beschreibt beides: was eingebaut funktioniert, wann eine fn_convert_bit-Funktion her muss und wie das Pendant in Postgres … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für float und real sicher anwenden

Datenqualität bei Gleitkomma-Spalten ist eine eigene Disziplin — und TRY_CONVERT(float, …) hat ein paar Eigenheiten, die im Import-Pfad gerne übersehen werden: eine leere Zeichenfolge wird zu 0 (statt zu NULL), ein Komma als Dezimaltrennzeichen führt zu NULL, und selbst nach einer sauberen Konvertierung ergibt 2 + 3.4 – 3.4 – 2 als float nicht exakt 0. Dieser Artikel sortiert die Regeln, zeigt das sichere Konvertierungs-Pattern und macht … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für money und smallmoney sicher anwenden

Wer einmal einen Kassen-Report mit Werten wie ‚1.234,56 €‘ aus einer CSV in eine SQL-Server-Datenbank importieren musste, kennt das Muster: TRY_CONVERT(money, ‚1,234.56‘) liefert 1234.5600. Doch TRY_CONVERT(money, ‚1.234,56‘) liefert NULL. Und selbst wenn der Import sauber läuft: money / 100 * 100 ist nicht zwangsläufig dasselbe wie der Ausgangswert. Kurzüberblick — was dieser Artikel klärt: Voraussetzung: SQL Server 2017+ (für TRIM im sicheren Pattern; vor 2017 als LTRIM(RTRIM(…))-Fallback). Kein Sample-Datensatz nötig … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für decimal und numeric sicher anwenden

Wer einmal einen Preis-Import gesehen hat, der aus ‚123,45 €‘ ein NULL macht statt der erwarteten Dezimalzahl, weiß: TRY_CONVERT(decimal(5, 2), ‚123,45‘) liefert NULL, weil das Komma als Dezimaltrennzeichen nicht erlaubt ist. Und selbst wenn das Komma weg ist: TRY_CONVERT(decimal(5, 2), ‚1234.56‘) ist auch NULL — diesmal wegen einer Vorkomma-Stelle zu viel. Auf einen Blick: Voraussetzung: SQL Server 2017+ (TRIM im sicheren Pattern; vor 2017 LTRIM(RTRIM(…))-Fallback). Postgres 12+ für … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für bigint, int, smallint und tinyint sicher anwenden

Datenqualität beginnt bei der Typ-Konvertierung — und bei Integer-Spalten zeigt TRY_CONVERT ein paar Eigenheiten, die im Import-Pfad gerne übersehen werden: eine leere Zeichenfolge wird zu 0 (statt zu NULL), jedes Dezimal- oder Tausendertrennzeichen führt zu einem NULL, und eine typisierte Dezimalzahl wird stillschweigend abgeschnitten — ohne Rundung. Dieser Artikel sortiert die Regeln, zeigt das sichere Konvertierungs-Pattern und reicht eine Postgres-Brücke nach. Kurzüberblick: … Weiterlesen

Datenqualität in einem ETL-Prozess — technische und fachliche Fehler erkennen, bevor sie das Zielsystem erreichen

Ein einziger nicht konvertierbarer Wert — ein Datum im falschen Format, eine Zahl mit dem falschen Dezimaltrennzeichen — und der ganze ETL-Lauf bricht ab. Datenqualität in einem ETL-Prozess heißt: solche Fehler proaktiv erkennen, protokollieren und isolieren, bevor sie das Zielsystem erreichen. Dieser Artikel ist der Einstieg in eine Serie, die genau das als Design Pattern umsetzt. TL;DR — … Weiterlesen