Diese Fragen prüfen die Verbindungen zwischen Import, Aufbereitung, Qualität und Datenbanken. Die Sammlung wächst mit jeder fertigen Themenseite.
Datenbanken und SQL
Warum lässt sich in SQL nicht WHERE SUM(betrag) > 500 schreiben?
WHERE wird vor der Gruppierung ausgewertet, es gibt dort noch keine Summen
Richtig. Bedingungen auf Aggregaten gehören in HAVING, das nach GROUP BY läuft. Beides in einer Abfrage ist möglich und üblich.
SUM darf nur im SELECT stehen
Es darf auch in HAVING und in ORDER BY stehen. Die Einschränkung betrifft nur WHERE.
Die Klammern fehlen
Es ist kein Syntaxproblem, sondern eine Folge der Auswertungsreihenfolge.
Eine Abfrage WHERE rabatt <> 5 liefert deutlich weniger Zeilen als erwartet, und dieselbe Auswertung in pandas mit df[df["rabatt"] != 5] liefert mehr. Woher kommt der Unterschied?
In SQL ist der Vergleich mit NULL unbekannt und die Zeile fällt heraus, pandas vergleicht NaN als ungleich
Richtig. In SQL braucht es rabatt IS NULL OR rabatt <> 5. Dieselbe Logik steckt hinter NOT IN mit einem NULL in der Unterabfrage, das gar nichts liefert.
pandas rechnet falsch
Beide verhalten sich wie dokumentiert, nur verschieden.
Die Datentypen unterscheiden sich
Der Typ ist nicht die Ursache, sondern die Behandlung des fehlenden Werts.
Eine Auswertung verbindet Bestellungen mit Artikeln und liefert mehr Zeilen als es Bestellungen gibt. In welchen drei Werkzeugen ist das derselbe Fehler?
In SQL beim JOIN, in pandas bei merge und in dplyr bei left_join
Richtig. Immer ist der Schlüssel auf einer Seite nicht eindeutig. Die Gegenmittel heissen validate="many_to_one", relationship = "many-to-one" und vorher die Eindeutigkeit prüfen.
Nur in SQL, die anderen prüfen das automatisch
Keines der drei prüft ohne ausdrückliche Angabe.
Es ist kein Fehler, sondern gewollt
Gewollt nur bei einer echten viele-zu-viele-Beziehung, und dann weiss man es vorher.
Wann ist der Weg über eine SQLite-Datei einem direkten Einlesen der CSV-Datei überlegen?
Wenn die Datei zu gross für den Arbeitsspeicher ist oder mehrere Skripte denselben Zwischenstand brauchen
Richtig. Einmal einlesen, danach gezielt abfragen, statt jedes Mal alles zu laden. Zudem bleiben Typen erhalten, anders als bei CSV.
Immer, eine Datenbank ist schneller
Für eine kleine Datei ist der Umweg reiner Aufwand.
Nie, dafür braucht es einen Server
SQLite braucht keinen Server, es ist eine Datei.
Aufbereitung und Qualität
Eine Auswertung nach Monat zeigt für den Januar einen doppelt so hohen Wert wie erwartet, und der Datensatz umfasst zwei Jahre. Was ist der erste Verdacht?
Gruppiert wurde nach dem Monat als Text, also ohne Jahr
Richtig. %m oder der Monatsname wirft Januar 2025 und Januar 2026 in eine Gruppe. Richtig ist der Monatsanfang oder das Paar aus Jahr und Monat.
Die Datumsspalte wurde falsch eingelesen
Möglich, ergäbe aber eher verschobene Werte als eine verdoppelte Gruppe.
Der Januar hat mehr Tage als andere Monate
Der Unterschied von drei Tagen erklärt keine Verdopplung.
In einer Spalte fehlen fünf Prozent der Werte. Welche Frage ist wichtiger als die Anzahl?
Ob die Fälle mit Lücke sich von den übrigen unterscheiden
Richtig. Hängt das Fehlen mit Alter, Standort oder Gerät zusammen, verzerrt jedes Weglassen das Ergebnis. Der Vergleich der Gruppen mit und ohne Lücke kostet zwei Zeilen Code.
Ob die fehlenden Werte am Anfang oder am Ende stehen
Die Position ist selten von Bedeutung, ausser bei Zeitreihen.
Ob der Mittelwert ohne sie noch berechenbar ist
Berechenbar ist er immer, die Frage ist, was er dann beschreibt.
Derselbe Auswertungscode läuft in R und in Python und liefert bei den Klassengrenzen und beim Monatsende verschiedene Ergebnisse. Was ist die gemeinsame Ursache?
Beide Sprachen treffen an Randfällen eine Voreinstellung, und sie ist nicht dieselbe
Richtig. cut schneidet (a, b], case_when mit < schiebt den Randwert nach oben; beim 31. Januar plus einem Monat liefert R ohne %m+% sogar NA. Randfälle gehören ausgeschrieben und geprüft.
Eine der beiden Sprachen rechnet falsch
Beide rechnen wie dokumentiert, nur verschieden.
Es liegt an der Gleitkommagenauigkeit
Bei Kalender und Klassengrenzen geht es um Konventionen, nicht um Rundung.
Nach einem Join hat die Tabelle mehr Zeilen als vorher. Was ist die wahrscheinlichste Ursache?
Ein Fehler in der Join-Bedingung, es fehlt eine Klammer
Syntaxfehler führen zu einer Fehlermeldung, nicht zu zusätzlichen Zeilen.
Der Schlüssel ist auf der rechten Seite nicht eindeutig
Richtig. Zu jeder linken Zeile passen mehrere rechte, und jede Kombination wird eine eigene Zeile. Prüfen lässt sich das mit einer Zählung der Schlüsselwerte vor dem Join.
Ein LEFT JOIN statt eines INNER JOIN
Der behält Zeilen, er vervielfacht sie aber nicht.
Eine CSV-Datei wird eingelesen, und eine Spalte mit Messwerten landet als Text. Was ist zu tun?
Die Spalte nachträglich in Zahlen umwandeln und weiterarbeiten
Das behebt das Symptom und verdeckt die Ursache.
Nachsehen, welche Werte die Umwandlung verhindern
Richtig. Fast immer steckt etwas darin, das keine Zahl ist: ein Dezimalkomma, ein Tausendertrennzeichen, ein Platzhalter wie “k.A.” oder eine Fussnote. Der Fund gehört in die Bereinigung, nicht in eine stille Umwandlung.
Die Datei in Excel öffnen und speichern
Damit kommen weitere stille Umwandlungen dazu, etwa Zahlen, die zu Datumsangaben werden.