Interaktive Schulungsoberfläche für relationale Normalisierung in SQL und flexible Dokumentmodelle in MongoDB.
SQL + MongoDB
Relationen & Regeln
SQL-Track · Schritt 2 / 5
Qualitätsprüfung
Die Oberfläche zeigt den Weg von Excel-Rohdaten über Qualitätsprobleme und Bereinigung bis zur relational normalisierten Datenbank.
Schulungsfluss aktiv
Schritt 2: Datenqualitätsanalyse — Bevor wir normalisieren, müssen wir verstehen, was alles kaputt ist.
Die automatische Analyse hat folgende Probleme in den Excel-Daten gefunden:
Excel speichert Daten oft als Text. Verschiedene Nutzer geben Daten in verschiedenen Formaten ein. Eine relationale DB erzwingt ein einheitliches DATE-Format.
Telefonnummern kommen in mindestens 6 verschiedenen Formaten vor. In einer DB würde man ein einheitliches Format erzwingen oder die Nummer vor dem Speichern normalisieren.
⚠️ Inkonsistente Straßen-Schreibweisen
raw_kunden.Strasse46 betroffen
str., straße
Dieselbe Straße wird unterschiedlich geschrieben: "Hauptstraße", "Hauptstr.", "Hauptstrasse". In einer normalisierten DB könnte man eine Straßentabelle mit eindeutigen IDs nutzen.
⚠️ Gemischte Dezimaltrenner (Punkt und Komma)
raw_produkte.Preis186 betroffen
Mit Komma: 337,21 | Mit Punkt: 224.0
Deutsche Excel-Versionen nutzen Komma als Dezimaltrenner, englische den Punkt. Beim Import entstehen so fehlerhafte Zahlenwerte. Eine DB nutzt DECIMAL und akzeptiert nur ein Format.
⚠️ Inkonsistente Kategorie-Schreibweisen
raw_produkte.Kategorie25 betroffen
Auto . | Auto & Motorrad | Bücher | Bürob. | Bürobedarf | Elekt. | elektronik | Garten | Haush. | Haushalt | Kleid. | KLEIDUNG | Kosme. | KOSMETIK | Leben. | lebensmittel | möbel | musik | Spiel. | spielzeug | Sport | Tierb. | Tierbedarf | Werkz. | werkzeug
Dieselbe Kategorie erscheint in verschiedenen Schreibweisen: "Elektronik", "ELEKTRONIK", "elektronik", "Elekt.". In einer normalisierten DB gäbe es eine Kategorietabelle mit festen IDs.
⚠️ 1. Normalform verletzt: Mehrere Werte in einer Zelle
Die 1. Normalform verlangt: Jede Zelle enthält genau EINEN atomaren Wert. Hier stehen mehrere Produkte in einer Zelle, getrennt durch Semikolon. Das macht Abfragen wie "Welche Bestellungen enthalten Produkt X?" extrem schwierig.
Bestellung hat Kundenname="Ottilie Schmid", Kundenort="Ulm" — diese Info steht schon in der Kundentabelle!
In Excel werden Kundendaten oft in die Bestelltabelle kopiert. Problem: Wenn sich eine Adresse ändert, muss man sie an VIELEN Stellen ändern (Update-Anomalie). In einer relationalen DB reicht ein Fremdschlüssel auf die Kundentabelle.
⚠️ Inkonsistente Schlüsselformate
raw_kunden.Kundennummer41 betroffen
Mit Nullen: K00001 | Ohne Nullen: K2
Kundennummern existieren als "K1" und "K00001" — Excel verliert führende Nullen wenn man Zellen nicht als Text formatiert. Eine DB nutzt AUTO_INCREMENT Integer-IDs.
Diese Bestellungen verweisen auf Kundennummern, die in der Kundentabelle NICHT existieren. In einer relationalen DB verhindert ein FOREIGN KEY solche Inkonsistenzen.
⚠️ Inkonsistente Einheiten und Formate
raw_produkte.Gewicht500 betroffen
g: 10100 g | g: 10370 g | g: 11020 g | g: 11070 g | g: 11090 g | g: 11350 g | g: 11760 g | g: 11810 g | g: 11850 g | g: 11970 g | g: 120 g | g: 12080 g | g: 12120 g | g: 12300 g | g: 12330 g | g: 12400 g | g: 1260 g | g: 12710 g | g: 13610 g | g: 13710 g | g: 13800 g | g: 13870 g | g: 140 g | g: 1420 g | g: 14260 g | g: 14570 g | g: 15710 g | g: 15750 g | g: 15820 g | g: 15940 g | g: 16260 g | g: 16360 g | g: 16800 g | g: 16980 g | g: 17170 g | g: 17270 g | g: 17330 g | g: 17540 g | g: 17640 g |
Gewichte erscheinen mit verschiedenen Einheiten (kg, g, KG, Kg) oder ganz ohne Einheit. Eine DB würde ein DECIMAL-Feld mit definierter Einheit nutzen.
Auch Bestelldaten kommen in verschiedenen Formaten. Filtern nach Zeiträumen ist so kaum möglich.
⚠️ Abweichende Schreibweisen zwischen Tabellen
raw_bestellungen.Kundenname13 betroffen
ANDREAS KAISER ≠ Andreas Kaiser | FELIX VOGT ≠ Felix Vogt | GEORG WOLF ≠ Georg Wolf | JAN KUHN ≠ Jan Kuhn | JASMIN KAISER ≠ Jasmin Kaiser | JULIA KUHN ≠ Julia Kuhn | JULIA WOLF ≠ Julia Wolf | MANFRED SCHMID ≠ Manfred Schmid | NORBERT MEYER ≠ Norbert Meyer | PHILIPP SCHOLZ ≠ Philipp Scholz | REGINA LORENZ ≠ Regina Lorenz | TANJA BAUER ≠ Tanja Bauer | VERA FISCHER ≠ Vera Fischer
Der Kundenname in Bestellungen weicht von der Kundentabelle ab (z.B. GROSSBUCHSTABEN, Umlaute als ue/oe). Das ist das Kernproblem der Redundanz: Daten an mehreren Stellen → Inkonsistenz!