Wie man ein Datenbankschema liest und weiß, was man abfragen muss

SQL-Abfragen sind selten das Problem. Die eigentliche Herausforderung besteht darin, eine neue Datenbank zu öffnen und herauszufinden, wo sich die benötigten Daten tatsächlich befinden. Dieser Artikel zeigt Ihnen, wie Sie ein Datenbankschema lesen, damit Sie schnell verstehen, was Sie abfragen müssen und wo Sie anfangen sollen.

Mein Mann behauptet, dass das Schwierigste an der praktischen Anwendung von SQL nicht das Schreiben von Abfragen ist. Für ihn besteht die eigentliche Herausforderung darin, eine Datenbank zu öffnen, die er noch nie gesehen hat, und herauszufinden, wo sich die Dinge befinden. In welcher Tabelle sind die Benutzernamen gespeichert? Welche Spalte steuert einen Status? Was muss geändert werden, um ein Problem zu beheben oder einen Test freizugeben?

Er ist Software-Tester, und bei seinen Projekten bleibt selten Zeit, sich mit dem Datenbankschema vertraut zu machen. Meistens muss er sich einfach selbst zurechtfinden.

Wenn eine Dokumentation vorhanden ist, ist das hilfreich. Aber sehr oft ist das nicht der Fall – oder sie ist veraltet. Deshalb ist es so wertvoll, ein Datenbankschema schnell lesen zu können. So gelangt man ohne Rätselraten und Zeitverlust von „Ich habe Zugriff auf die Datenbank“ zu „Ich weiß, was ich abfragen muss“.

Das Üben mit mehreren unbekannten Schemata – wie denen, die in den Kursen von „LearnSQL.de“ verwendet werden – hilft Ihnen, sich auch ohne Dokumentation zurechtzufinden.

Dieser Artikel zeigt Ihnen, wie Sie genau das tun können.

1. Finden Sie zuerst die Kerntabellen

Jede Datenbank, unabhängig von ihrer Größe oder ihrem Zweck, verfügt über eine kleine Anzahl von Kerntabellen. Diese Tabellen stellen die wichtigsten Entitäten des Systems dar und sind der natürliche Ausgangspunkt für die meisten Abfragen.

Kern-Tabellen haben in der Regel einige gemeinsame Merkmale. Sie repräsentieren wichtige Geschäftsobjekte, werden von vielen anderen Tabellen über Fremdschlüssel referenziert, enthalten oft Datums-, Status- oder Eigentumsinformationen und haben in der Regel mehr Zeilen als rein technische oder Nachschlagetabellen.

In einem Online-Shopsystem umfassen Kerntabellen beispielsweise in der Regel customers, orders, productsund payments. Die meisten Fragen drehen sich darum, wer etwas gekauft hat, was gekauft wurde und wann. Tabellen wie order_items oder product_categories dienen dazu, Details hinzuzufügen, sind aber für sich genommen selten sinnvoll.

In einem Bankensystem finden Sie in der Regel Tabellen wie accounts, customers, transactionsoder loans. Auch hier beginnen die meisten Abfragen mit einer dieser Tabellen und werden dann mit anderen verknüpft, um zusätzliche Informationen wie Kontostatus, Salden oder Transaktionshistorie zu erhalten.

In der Praxis beginnen nützliche Abfragen entweder mit einer Kerntabelle und werden dann erweitert oder verbinden zwei Kerntabellen direkt miteinander. Um Kunden mit Bestellungen, Konten mit Transaktionen oder Produkte mit Verkäufen zu verknüpfen, muss man verstehen, wie Kerntabellen miteinander in Beziehung stehen. Wenn Sie mit der falschen Tabelle beginnen oder Kerntabellen falsch verknüpfen, werden Abfragen schwieriger zu verstehen und die Ergebnisse können leicht falsch interpretiert werden. Deshalb geht es beim Einstieg in eine neue Datenbank nicht nur darum, wichtige Tabellen zu finden, sondern auch darum, die Beziehungen zwischen ihnen zu verstehen.

In großen Systemen und Datenbanken gibt es selten nur einen Satz von Kerntabellen. Verschiedene Funktionsbereiche haben oft ihre eigenen „Schwerpunkte”. Wenn Sie beispielsweise von Kundendaten zu Rechnungsstellung oder Berichterstellung wechseln, arbeiten Sie effektiv mit einem neuen Bereich des Systems. Jeder Bereich hat seine eigenen Kerntabellen, und Onboarding bedeutet, zuerst diese Anker zu lernen, bevor man den Rest erkundet.

LearnSQL.de Die Kurse basieren auf realistischen Schemata, bei denen die Identifizierung der Kerntabellen der erste Schritt ist, bevor eine sinnvolle Abfrage geschrieben werden kann.

2. Lesen Sie Tabellennamen hinsichtlich ihrer Struktur, nicht nur ihrer Bedeutung

Tabellennamen beschreiben nicht nur, welche Daten gespeichert sind. Sie geben auch Auskunft darüber, wie Tabellen verwendet werden sollen und in welcher Beziehung sie zu anderen Teilen des Schemas stehen.

Einige Tabellen stellen eigenständige Entitäten dar, wie z. B. users, ordersoder products. Diese Tabellen beschreiben in der Regel reale Geschäftsobjekte und sind sichere Ausgangspunkte für Abfragen. Wenn jemand eine allgemeine Frage zu Kunden, Bestellungen oder Konten stellt, sind dies die Tabellen, nach denen Sie in der Regel zuerst suchen.

Andere Tabellen haben zusammengesetzte Namen, wie z. B. order_items, user_roles, customer_addressesoder account_transactions. Diese Tabellen stellen in der Regel Beziehungen oder detaillierte Komponenten einer Haupteinheit dar. Sie sind keine unabhängigen Objekte. Ihr Zweck besteht darin, andere Tabellen zu erweitern oder zu verbinden.

Wenn Sie einen zusammengesetzten Tabellennamen sehen, können Sie in der Regel einige Dinge annehmen. Die Tabelle hängt von einer anderen Tabelle ab, sie enthält viele Zeilen pro übergeordneter Entität und sie ist dafür gedacht, verbunden zu werden, nicht isoliert abgefragt zu werden. Beispielsweise order_items enthält in der Regel mehrere Zeilen für eine einzelne Bestellung, eine für jedes gekaufte Produkt. Eine direkte Abfrage ohne Verknüpfung mit orders führt oft zu doppelten Daten auf Auftragsebene. Ebenso user_roles kann mehrere Rollen für denselben Benutzer auflisten, und ausgehend von dieser Tabelle kann sich die Anzahl der Zeilen schnell vervielfachen, wenn Sie die Ergebnisse nicht explizit gruppieren oder filtern. Tabellen wie customer_addresses oder account_transactions verhalten sich auf die gleiche Weise: Sie speichern Detail- oder Beziehungsdaten und sind nur dann vollständig sinnvoll, wenn sie mit ihren übergeordneten Tabellen verbunden sind.

Tabellennamen geben oft Aufschluss darüber, wie Tabellen miteinander verbunden sind. In vielen Schemata folgen Fremdschlüssel einem einfachen Namensmuster: dem Namen der referenzierten Tabelle plus _id. Beispielsweise enthält eine Tabelle mit dem Namen order_items enthält fast immer eine order_id Spalte, die jede Zeile mit orders. Eine user_roles enthält in der Regel sowohl user_id und role_id, wodurch ihre Rolle als Verknüpfungstabelle offensichtlich wird.

Einige Schemata verwenden zusätzliche Namenskonventionen, die besonders in Analyse- oder Berichtsdatenbanken üblich sind. Tabellen, die mit _dim , stellen in der Regel Dimensionen dar, wie z. B. customer_dim oder product_dim. Diese Tabellen speichern beschreibende Informationen und ändern sich relativ langsam. Tabellen, die mit _factenden, wie z. B. sales_fact oder transactions_fact, enthalten in der Regel messbare Ereignisse oder Metriken und wachsen tendenziell schnell. Faktentabellen sind fast immer mit mehreren Dimensionstabellen verknüpft. Möglicherweise sehen Sie auch Suffixe wie _history und _log, die auf zeitbasierte oder Audit-Daten hinweisen. Diese Namen signalisieren, dass bei der Filterung nach Datum oder der Auswahl des aktuellen Status besondere Sorgfalt erforderlich ist.

Wenn Sie diese Muster frühzeitig erkennen, können Sie einen häufigen Fehler beim Onboarding vermeiden: jede Tabelle als gleichwertig zu behandeln. Tabellennamen geben Ihnen oft schon lange vor dem Schreiben Ihrer ersten Abfrage Aufschluss darüber, wo Sie beginnen, was Sie verknüpfen und was Sie als unterstützende Details behandeln sollten.

3. Scannen Sie die Spalten, bevor Sie die Daten anfassen

Bevor Sie explorative Abfragen ausführen, nehmen Sie sich einen Moment Zeit, um die Spaltenliste einer Tabelle zu scannen. Dies ist eine der schnellsten Methoden, um zu verstehen, wozu die Tabelle dient und wie sie in das Schema passt.

Achten Sie besonders auf einige Arten von Spalten. Primärschlüssel, die in der Regel mit id, geben an, was eine Zeile eindeutig identifiziert. Fremdschlüssel, die oft mit _id, zeigen, wie diese Tabelle mit anderen Tabellen verbunden ist. Datums- und Uhrzeitspalten geben Auskunft darüber, wann etwas passiert oder sich geändert hat. Status-, Typ- oder Flag-Spalten steuern häufig die Geschäftslogik.

Fremdschlüssel sind besonders wertvoll, wenn Sie eine neue Datenbank einrichten. In vielen Schemata folgen sie einem einfachen Benennungsmuster: dem Namen der referenzierten Tabelle plus _id. Eine Tabelle mit dem Namen order_items mit ziemlicher Sicherheit eine Spalte order_id Spalte. Eine user_roles enthält in der Regel sowohl user_id und role_id. Auch ohne die Daten zu lesen, geben Ihnen diese Spaltennamen genau Auskunft darüber, wie die Tabelle mit anderen Tabellen verknüpft werden sollte.

Spaltennamen geben auch Hinweise auf die Rolle einer Tabelle. Eine Tabelle mit mehreren Fremdschlüsseln ist in der Regel Teil einer größeren Struktur und steht selten für sich allein. Eine Tabelle mit mehreren Datumsspalten kann verschiedene Lebenszyklusereignisse verfolgen, wie z. B. Erstellung, Aktualisierungen oder Statusänderungen. Eine Tabelle mit einer Statusspalte ist häufig in Geschäftsprozesse und Filterlogik eingebunden.

Dieser schnelle Überblick über die Spalten verrät oft mehr als die Betrachtung von Beispielzeilen, insbesondere zu Beginn. Er hilft Ihnen, Beziehungen zu verstehen, Verknüpfungspfade zu erkennen und zu entscheiden, ob eine Tabelle für Ihre Frage relevant ist, bevor Sie Abfragen schreiben.

Die Übungen in den Kursen „LearnSQL.de” regen Sie dazu an, zunächst die Spaltennamen und Beziehungen zu studieren, was Ihrer Herangehensweise an eine neue Datenbank in realen Projekten entspricht.

4. Verwenden Sie kleine Erkundungsabfragen, um Annahmen zu bestätigen

Nachdem Sie sich ein mentales Modell des Schemas aufgebaut haben, ist es an der Zeit, es sorgfältig zu testen. In dieser Phase versuchen Sie noch nicht, eine geschäftliche Frage zu beantworten. Sie überprüfen, ob Ihr Verständnis der Tabellen und Beziehungen korrekt ist.

Ein üblicher erster Schritt ist die Betrachtung einer kleinen Stichprobe von Zeilen. Eine Abfrage wie

SELECT * 
FROM orders 
LIMIT 10;

zeigt schnell, welche Art von Daten die Tabelle tatsächlich enthält und ob diese mit Ihren Erwartungen hinsichtlich des Namens und der Spalten übereinstimmen.

Um zu verstehen, wie kategoriale Spalten verwendet werden, ist es hilfreich, eindeutige Werte zu überprüfen. Beispielsweise

SELECT DISTINCT status 
FROM orders;

alle möglichen Bestellstatus anzeigen und sofort erkennen lassen, ob die Spalte aktiv genutzt wird oder größtenteils leer ist.

Datums- und numerische Spalten sind wichtige Signale. Einfache Bereichsprüfungen helfen Ihnen, den Umfang und die Bedeutung der Daten zu verstehen. Eine Abfrage wie

SELECT MIN(created_at), MAX(created_at) 
FROM orders;

zeigt den von der Tabelle abgedeckten Zeitbereich und gibt Auskunft darüber, ob sie historische Datensätze, aktuelle Aktivitäten oder eine Mischung aus beidem enthält.

Der gleiche Ansatz funktioniert auch für numerische Spalten. Durch Überprüfen der Minimal- und Maximalwerte von Beträgen, Mengen oder Zählern können erwartete Bereiche, Einheiten oder Anomalien aufgedeckt werden. Beispielsweise kann durch Betrachten des minimalen und maximalen Bestellwerts oder Transaktionsbetrags schnell festgestellt werden, ob Werte in Cent oder ganzen Einheiten gespeichert sind oder ob Extremwerte vorliegen, die eine besondere Behandlung erfordern. Diese schnellen Bereichsprüfungen helfen dabei, Annahmen zu bestätigen, bevor Sie sich auf eine Spalte in Filtern, Berechnungen oder Aggregationen verlassen.

Gruppieren und Zählen sind besonders nützlich für die Validierung von Beziehungen. Beispielsweise

SELECT order_id, COUNT(*) 
FROM order_items 
GROUP BY order_id;

zeigt, wie viele Artikel eine Bestellung in der Regel enthält. Wenn Sie eine Zeile pro Bestellung erwartet haben und stattdessen mehrere Zeilen sehen, ist dies eine wichtige Korrektur Ihres mentalen Modells.

Diese explorativen Abfragen sind bewusst einfach gehalten. Sie dienen nicht der Analyse, sondern der Validierung. Sie helfen zu bestätigen, ob eine Tabelle eine Zeile pro Entität oder viele Zeilen speichert, ob Beziehungen sich wie erwartet verhalten und ob bestimmte Spalten sicher gefiltert werden können.

Diese Art der Schnellprüfung deckt oft frühzeitig Randfälle auf – unerwartete Status, fehlende Daten oder ungewöhnlich große Gruppierungen –, bevor sie in komplexeren Abfragen Probleme verursachen. Stellen Sie sich das wie eine Validierung Ihrer Karte vor, bevor Sie die Reise antreten.

Diese Art von explorativen Abfragen ist in der Praxis der „LearnSQL.de” üblich, wo kleine Überprüfungen Ihnen helfen, die Daten zu verstehen, bevor Sie die eigentliche Aufgabe lösen.

5. Beginnen Sie mit der Frage, nicht mit dem Schema

Das Denken in Entitäten wie Benutzern, Bestellungen, Produkten, Zahlungen oder Konten bietet Ihnen einen natürlichen Ausgangspunkt für die Abfrage. Sobald Sie wissen, welche Entitäten beteiligt sind, wird es viel einfacher zu entscheiden, wo Sie beginnen und wie Sie den Rest der Abfrage aufbauen.

Wenn Sie mit dem Schreiben einer Abfrage beginnen, starten Sie mit der Frage, die Sie beantworten müssen, und nicht mit der Liste der Tabellen. Das Öffnen einer neuen Datenbank und das sofortige Durchsuchen des Schemas führt oft zu unnötiger Komplexität.

Der effektivste Ansatz besteht darin, die Frage in einfacher Sprache zu formulieren und die betroffenen Entitäten zu identifizieren. Eine Anfrage nach dem Benutzernamen und der E-Mail-Adresse eines Benutzers verweist beispielsweise direkt auf die Benutzerentität und alle zugehörigen Profil- oder Kontotabellen. Eine Frage wie „Warum ist diese Bestellung blockiert?“ rückt sofort die Bestellung, ihren Status und damit verbundene Prozesse wie Zahlung oder Versand in den Fokus. Wenn die Aufgabe darin besteht, einen Status zu ändern, damit ein Prozess fortgesetzt werden kann, haben Sie es in der Regel mit einer Hauptgeschäftseinheit und der Tabelle zu tun, die deren aktuellen Status steuert.

Dieser Schritt wird oft übersprungen, macht aber einen erheblichen Unterschied. Ohne eine klare Frage erscheinen alle Tabellen gleichermaßen relevant. Mit einer definierten Frage und einer klaren Reihe von Entitäten kann der größte Teil des Schemas ignoriert werden.

LearnSQL.de Kurse formulieren Aufgaben als zu beantwortende Fragen, was Sie dazu zwingt, über Entitäten und Beziehungen nachzudenken, bevor Sie sich mit dem Schema befassen.

6. Folgen Sie Fremdschlüsseln wie einer Landkarte

Fremdschlüssel sind der zuverlässigste Leitfaden durch ein unbekanntes Schema.

Ein praktischer Ansatz besteht darin, von einer Kerntabelle auszugehen und den Fremdschlüsseln Schritt für Schritt nach außen zu folgen. Jeder Fremdschlüssel gibt Auskunft darüber, wie die Daten miteinander verbunden sind und welchen zusätzlichen Kontext Sie Ihrer Abfrage hinzufügen können. Wenn Sie beispielsweise in orders und einen customer_id, wissen Sie bereits, dass Sie eine Verknüpfung zu customers , um Kundendetails zu erhalten. Wenn orders enthält auch payment_identhält, deutet dies auf eine direkte Verknüpfung mit payments für den Zahlungsstatus oder die Zahlungsmethode. Wenn es kein payment_id , aber Sie finden order_id in payments, bedeutet dies, dass die Beziehung in die andere Richtung verläuft und Sie anhand dieses Fremdschlüssels eine Verknüpfung von Bestellungen zu Zahlungen herstellen sollten.

Die gleiche Logik gilt für benutzerbezogene Aufgaben. Wenn Sie mit users und profile_id, können Sie dieser bis profiles. Wenn Sie stattdessen user_id innerhalb von profiles, bedeutet dies, dass profiles von users und wieder damit verbunden werden sollte. Für Fragen der Zugriffskontrolle enthält eine Tabelle wie user_roles enthält in der Regel sowohl user_id und role_id, wodurch sie zu einer Brücke zwischen users und roles.

Wenn Sie Fremdschlüsseln folgen, stellen Sie sich bei jedem Schritt eine einfache Frage: Fügt diese Tabelle neue Informationen hinzu, die für meine ursprüngliche Frage relevant sind? Wenn die Antwort „Nein” lautet, hören Sie auf. Wenn Sie beispielsweise nur einen Benutzernamen und eine E-Mail-Adresse benötigen, verbinden Sie users mit roles und permissions ist in der Regel unnötig. Wenn Sie eine festgefahrene Bestellung bearbeiten, ist das Verknüpfen von orders mit customers, paymentsund shipments kann ausreichend sein, während das Verknüpfen von Marketing- oder Analysetabellen wahrscheinlich nur zu Unklarheiten führt.

Die meisten realen Abfragen benötigen keine tiefen Join-Ketten. Zwei bis vier Tabellen sind oft ausreichend. Weitergehende Join-Ketten erhöhen in der Regel die Komplexität ohne großen Nutzen und erhöhen das Risiko falscher Ergebnisse, insbesondere wenn Sie versehentlich One-to-Many-Joins einführen, die die Zeilenanzahl vervielfachen.

Behandeln Sie Fremdschlüssel als Karte und nicht als Herausforderung, alles zu erkunden.

Die Arbeit mit Schemata mit mehreren Fremdschlüsseln in den Kursen „LearnSQL.de” hilft dabei, die Gewohnheit zu entwickeln, Beziehungen Schritt für Schritt zu verfolgen, anstatt Tabellen blind zu verknüpfen.

7. Erstellen Sie Abfragen schrittweise

Wenn Sie mit einer unbekannten Datenbank arbeiten, ist das schrittweise Erstellen von Abfragen einer der sichersten und schnellsten Ansätze. Anstatt eine komplexe Abfrage auf einmal zu schreiben, erweitern Sie sie Schritt für Schritt und überprüfen Sie Ihre Annahmen in jeder Phase.

Beginnen Sie mit der Abfrage einer einzelnen Tabelle, in der Regel einer Kern-Tabelle, die für Ihre Frage relevant ist. So können Sie sicherstellen, dass Sie die richtigen Daten betrachten und dass die Grundstruktur Ihren Erwartungen entspricht.

Fügen Sie als Nächstes jeweils eine JOIN einmal hinzu. Überprüfen Sie nach jeder Verknüpfung, ob das Ergebnis noch sinnvoll ist. Achten Sie dabei auf die Anzahl der Zeilen und auf Duplikate. Wenn die Anzahl der Zeilen plötzlich stärker als erwartet ansteigt, ist dies oft ein Zeichen für eine Eins-zu-Viele-Beziehung, die eine Aggregation oder eine spezifischere Verknüpfungsbedingung erfordert.

Erst wenn die Struktur der Abfrage korrekt ist, sollten Sie mit dem Hinzufügen von Filtern beginnen. Das zu frühe Hinzufügen von WHERE zu früh Filter hinzufügen, können Probleme in den Verknüpfungen verdeckt werden, sodass es schwieriger wird, die Ursache für unerwartete Ergebnisse zu finden.

Dieser schrittweise Ansatz reduziert Fehler, erleichtert die Fehlersuche in Abfragen und hilft Ihnen, das Schema während der Arbeit besser zu verstehen. Mit der Zeit wird dies zu einer zuverlässigen Gewohnheit beim Einarbeiten in eine neue Datenbank.

Viele Übungen zum Thema „LearnSQL.de” sind so konzipiert, dass sie schrittweise gelöst werden können – beginnend mit einer Tabelle, schrittweises Hinzufügen von Verknüpfungen und Verfeinern der Abfrage im Laufe der Arbeit.

Üben Sie bewusst das Lesen von Schemata

Die meisten Menschen üben das Schreiben von SQL-Abfragen. Weit weniger üben das Verstehen von Schemata.

Deshalb ist es wichtig, strukturiert mit realistischen Schemata zu arbeiten. Kurse und Übungen, die Sie dazu zwingen, Tabellenstrukturen, Beziehungen und Absichten zu interpretieren, helfen Ihnen dabei, Fähigkeiten aufzubauen, die sich direkt auf reale Datenbanken übertragen lassen.

LearnSQL.de Die Kurse sind unter diesem Gesichtspunkt konzipiert. Sie bringen Ihnen reale Schemata näher und vermitteln Ihnen ein Verständnis für die Beziehungen zwischen Tabellen, bevor Sie sich mit der Abfragesyntax befassen. Das Ergebnis ist nicht nur besseres SQL, sondern auch eine schnellere Einarbeitung, wenn Sie bei der Arbeit mit einer neuen Datenbank konfrontiert werden.

Denn in der Praxis ist SQL selten der schwierige Teil. Das Schwierige ist, zu wissen, was man abfragen muss.