Relationale Datenbanken und das relationale Modell

Ein Kundenname, ein Bestelldatum und ein Preis sind Daten: festgehaltene Fakten. Eine Datenbank ist eine organisierte Sammlung zusammengehöriger Daten. Ein Datenbankmanagementsystem, kurz DBMS, ist die Software, die diese Sammlung speichert und verwaltet. PostgreSQL ist ein DBMS; die Datenbank store eines Ladens ist eine Sammlung, die PostgreSQL verwaltet.

Jede Information dort speichern, wo sie hingehört

Angenommen, eine Tabellenkalkulation wiederholt die Telefonnummer von Maria Garcia bei allen 14 ihrer Verkäufe. Ändert sich die Nummer, sind 14 Bearbeitungen nötig. Eine übersehene Zelle hinterlässt widersprüchliche Einträge. In einer relationalen Datenbank enthält customers die Angaben zu Maria nur einmal, unter customer_id 1. Jeder Verkauf speichert diese Kennung. Aktualisierst du ihre Telefonnummer in einer einzigen Kundenzeile, finden spätere Abfragen genau eine aktuelle Nummer.

Eine relationale Datenbank ordnet Fakten in Tabellen. „Relational“ kommt von Relation, dem mathematischen Namen für eine Tabelle. E. F. Codd stellte das Modell 1970 vor. Seine zentrale Trennung ist nützlich: Nutzer beschreiben die gewünschten Daten über Tabellen und Werte; das DBMS kümmert sich darum, wie diese Daten auf der Festplatte gefunden werden.

Regeln und gemeinsamer Zugriff

Eine Tabelle hat benannte Spalten, Datentypen und Integritätsbedingungen. Eine Integritätsbedingung ist eine Regel, die das DBMS prüft, etwa „eine Bestellung muss auf einen existierenden Kunden verweisen“. Diese Prüfungen schützen gemeinsam genutzte Daten, wenn mehrere Anwendungen dieselbe Datenbank verwenden. Wie streng Typen durchgesetzt werden, ist unterschiedlich: PostgreSQL weist Text wie 'twelve' in einer numerischen Preisspalte zurück, während gewöhnliche SQLite-Tabellen flexible Typen haben.

Ein DBMS verwaltet außerdem gleichzeitige Nutzer, Berechtigungen, Datensicherungen und Wiederherstellung. Zwei Mitarbeiter können an gemeinsamen Daten arbeiten, ohne getrennte Kopien einer Tabellenkalkulation auszutauschen. Berechtigungen können einem Berichtsnutzer erlauben, Verkäufe zu lesen, und zugleich einschränken, wer sie ändern darf. Ein Verfahren für Sicherung und Wiederherstellung hilft, Daten nach einem Ausfall wiederherzustellen.

Eine Gruppe von Änderungen zusammenhalten

Eine Transaktion behandelt mehrere Änderungen als eine Einheit: Entweder werden alle gespeichert oder keine. Um 200 $ zwischen Konten zu übertragen, muss der Betrag vom Girokonto abgezogen und dem Sparkonto gutgeschrieben werden. Unterbricht ein Ausfall die Überweisung, bevor sie abgeschlossen ist, kann das DBMS die unvollständige Transaktion rückgängig machen. Würde nur die Abbuchung gespeichert, bliebe ein falscher Kontostand zurück.

Eine Tabellenkalkulation bleibt nützlich für kleine Berechnungen und flexible Layouts. Eine Datenbank bietet eine festgelegte Struktur für gemeinsam genutzte Datensätze und Regeln. Ein Excel-Tabellenblatt ist fest auf 1.048.576 Zeilen begrenzt; Datenbanken verwalten routinemäßig viel größere Datenbestände, begrenzt durch Speicher, Hardware und die Grenzen des jeweiligen Produkts.

Unterschiedliche Daten, unterschiedliche Aufgaben

Strukturierte Daten passen in benannte Spalten, die jede Zeile hat. Semistrukturierte Daten wie JSON-Dokumente können in verschiedenen Datensätzen unterschiedliche Felder haben. Unstrukturierte Daten wie Audiodateien oder frei formulierte E-Mails haben kein festes tabellarisches Layout. Organisationen kombinieren relationale Datenbanken oft mit Dokumentdatenbanken, Schlüssel-Wert-Datenbanken oder Dateispeichern.

Auch die Art der Arbeitslast spielt eine Rolle. Ein transaktionsorientiertes System, auch OLTP genannt, erfasst alltägliche Vorgänge über viele kleine Lese- und Schreibzugriffe: eine Bestellung, eine Zahlung, eine Adressänderung. Ein analytisches System, kurz OLAP, liest viele gespeicherte Datensätze, um Fragen zu beantworten wie „Wie unterschieden sich die monatlichen Umsätze nach Region?“ Beide können relationale Tabellen und Schlüssel nutzen.

SQL, kurz für Structured Query Language, ist eine Sprache. PostgreSQL, MySQL, SQLite, Microsoft SQL Server und Oracle Database sind Produkte, die diese Sprache verwenden. SQL Server ist ein DBMS, kein anderer Name für SQL selbst.

Wie eine Anwendung an die Daten kommt

In einem Client-Server-System verwaltet ein Serverprogramm die Datenbank. Ein Client, etwa eine Website, ein Berichtswerkzeug oder ein Abfrageeditor, sendet Anfragen an diesen Server. PostgreSQL, MySQL, SQL Server und Oracle arbeiten üblicherweise so. Mit Werkzeugen wie psql, pgAdmin, DBeaver und SQL Server Management Studio können Menschen Datenbanken untersuchen und Anfragen senden.

Eine eingebettete Engine läuft innerhalb einer Anwendung. SQLite nutzt eine Bibliothek und eine gewöhnliche Datenbankdatei wie store.db, ohne separaten Datenbankserver. SQLite ist in Smartphones, Browsern und Desktop-Anwendungen verbreitet. Bei einem verwalteten Cloud-Dienst wie Azure SQL Database, Amazon RDS oder Google Cloud SQL betreibt ein Anbieter die Datenbankserver. „Verwaltet“ beschreibt, wer den Dienst betreibt; Tabellen und Schlüssel werden dadurch nicht durch ein anderes Modell ersetzt.

Eine DBMS-Installation kann mehrere Datenbanken verwalten, etwa store und payroll. Eine Verbindung wählt die zu verwendende Datenbank aus, sofern die Berechtigungen das erlauben.

Sag, welches Ergebnis du willst

SQL ist deklarativ: Es beschreibt das gewünschte Ergebnis, während das DBMS entscheidet, wie es dieses Ergebnis erhält. Lies diese Anweisung:

SELECT first_name, city
FROM customers
WHERE state = 'TX';

Sie fragt nach Vornamen und Städten aus den Kundenzeilen, deren Bundesstaat TX ist. Sie sagt nichts darüber, welche Seite auf der Festplatte zuerst gelesen wird. Großgeschriebene Schlüsselwörter machen die Anweisung leichter überschaubar; select und SELECT bedeuten dasselbe. Ein Semikolon beendet normalerweise eine Anweisung.

Die Aufgabe einer Anweisung erkennen

Manche Bücher ordnen SELECT einer eigenen Gruppe zu, der Datenabfragesprache. Entscheidend ist, was die Anweisung tatsächlich tut: Fügst du eine Spalte hinzu, änderst du die Struktur; fügst du einen Kunden hinzu, änderst du Daten.

SQL wurde 1986 ein ANSI-Standard und ist international als ISO/IEC 9075 genormt. Die Produkte ergänzen eigene Dialekte. Eine Begrenzung auf zehn Zeilen lautet LIMIT 10 in SQLite, PostgreSQL und MySQL, TOP 10 in SQL Server oder FETCH FIRST 10 ROWS ONLY in Standard-SQL und Oracle.

Text und weitere Datenbankobjekte lesen

Textliterale stehen in einfachen Anführungszeichen: 'TX'. Standard-SQL verwendet doppelte Anführungszeichen für Bezeichner wie Spaltennamen. Ein Apostroph innerhalb eines Texts wird verdoppelt: 'O''Brien' steht für O'Brien.

Eine Sicht ist eine gespeicherte Abfrage, die wie eine Tabelle verwendet wird; eine gewöhnliche Sicht speichert keine eigenen Zeilen. Ein Index ist eine Nachschlagestruktur, die helfen kann, Zeilen schnell zu finden. Die meisten Systeme indizieren Primärschlüssel automatisch. Gespeicherte Prozeduren und Funktionen sind gespeicherter Code, der sich über seinen Namen ausführen lässt.

Eine Tabelle speichert Fakten über eine Art von Dingen. Jede Zeile in customers beschreibt einen Kunden; jede Spalte enthält eine Eigenschaft. Am Schnittpunkt von Zeile und Spalte steht ein Wert.

Einen Datensatz quer lesen

Hier sind ausgewählte Kundenspalten:

Suche customer_id 4 und lies dann city: Die Stadt von Wei ist Seattle. Um herauszufinden, wer in Denver wohnt, liest du den Namen in der Zeile mit Denver: James Wilson. Eine benachbarte Zeile beschreibt einen anderen Kunden.

Die vollständige Tabelle hat acht Spalten: customer_id, first_name, last_name, email, phone, city, state und zip_code. Die Telefonnummer von James ist NULL: Der Wert fehlt, aber seine Zeile hat trotzdem die Spalte für die Telefonnummer.

Die Begriffe zuordnen

Ein Tupel ist eine ganze Zeile, nicht eine einzelne Zelle. Ein Attribut benennt eine Eigenschaft, die alle Zeilen haben. „Datensatz 4“ kann eine Kennung oder eine Anzeigeposition meinen; prüfe, was gemeint ist, denn Positionen können sich ändern.

Die Form abzählen

Der Grad zählt die Spalten, die Kardinalität einer Tabelle die Zeilen. Die vollständige Tabelle hat den Grad 8 und die Kardinalität 4. Die Darstellung oben zeigt sechs Spalten, ohne den Grad der Tabelle zu ändern.

Kommt ein Kunde hinzu, steigt die Kardinalität auf 5; der Grad bleibt 8. Kommt birth_date hinzu, steigt der Grad auf 9, und jede Zeile erhält einen Platz für diesen Wert, auch wenn er fehlt. Ein neuer Kunde fügt eine Zeile hinzu, keine Spalte.

Die Kardinalität einer Beziehung, etwa eins zu viele, beschreibt erlaubte Verknüpfungen, nicht die Zeilenanzahl einer Tabelle.

Qualifizierte Namen lesen

Spaltennamen sind innerhalb einer Tabelle eindeutig. orders.customer_id und customers.customer_id unterscheiden gleichnamige Spalten in verschiedenen Tabellen: Der Punkt trennt Tabellen- und Spaltennamen.

snake_case verwendet kleingeschriebene Wörter, die durch Unterstriche getrennt sind, wie in zip_code. Namen mit Leerzeichen müssen in SQL in Anführungszeichen stehen. Tabellennamen im Singular wie im Plural können funktionieren; verwende eine einheitliche Konvention.

Eine relationale Tabelle hat eine logische Struktur, die über ihr rechteckiges Aussehen hinausgeht. Im formalen Modell ist sie eine Menge von Zeilen. Mengen enthalten keine doppelten Elemente und haben keine Reihenfolge. Spalten werden über ihren Namen identifiziert; verschiebst du eine Spalte in einer Anzeige, ändert sich also nicht die Information, für die sie steht.

Die Identität ergibt sich nicht aus der Position

Ein DBMS kann Zeilen nach Änderungen, Löschungen oder einer geänderten Art, den Speicher zu lesen, in anderer Reihenfolge zurückgeben. „Die dritte Zeile“ ist keine dauerhafte Möglichkeit, einen Kunden zu identifizieren. customer_id 3 identifiziert Aisha auch dann, wenn ihre Zeile als erste erscheint. Braucht eine Abfrage eine bestimmte Reihenfolge, fordert sie diese mit ORDER BY an.

SQL-Tabellen unterscheiden sich von formalen Relationen: Ohne Primärschlüssel oder eine andere passende Eindeutigkeitsbedingung können sie identische Zeilen enthalten. Zwei Kopien von ('Coffee mug', 12.50) bieten in diesen Spalten keinen Wert, der sie unterscheidet. Ein Primärschlüssel gibt jeder Zeile eine eindeutige Kennung und verhindert vollständig doppelte Zeilen.

Eine Spalte, eine Domäne

Eine Domäne ist die Menge der Werte, die in einer Spalte zulässig sind. Eine Stückzahl hat einen Ganzzahltyp und braucht eventuell zusätzlich eine Regel, dass sie positiv sein muss. Ein Kürzel eines Bundesstaats ist Text, aber nicht jeder Textwert ist ein gültiges Kürzel. Datentypen und Integritätsbedingungen beschreiben dem DBMS die zulässigen Werte.

Alle Zeilen haben dieselben Spalten. Eine einzelne Bestellung kann keine zusätzliche Spalte für eine Geschenknotiz nur für sich bekommen. Die Tabelle kann für jede Bestellung eine Spalte gift_note haben, mit NULL dort, wo keine Notiz erfasst wurde. Auch optionale Angaben haben einen festgelegten Platz.

Einzelne Werte getrennt halten

Ein atomarer Wert ist ein einzelner Wert im Sinne des Zwecks der Spalte. Eine Zelle für die Telefonnummer mit dem Inhalt „512-555-0147, 512-555-0199“ enthält eine Liste mit zwei Nummern. Nur eine der Nummern zu finden, zu prüfen oder zu entfernen wird umständlich. Eine Tabelle customer_phones kann jeder Telefonnummer eine eigene Zeile geben, wobei customer_id zeigt, wem die Nummer gehört.

Atomar bedeutet nicht, dass jeder Textwert in seine kleinsten Teile zerlegt werden muss. Ein Städtename kann aus mehreren Wörtern bestehen und trotzdem ein einziger Stadtwert sein. Entscheidend ist, ob die Zelle eine einzelne Information der Art speichert, für die die Spalte steht, oder eine Sammlung, die getrennt behandelt werden sollte.

Einen Export aus einer Tabellenkalkulation kritisch lesen

Ein Blatt mit Verkäufen kann eine auf halber Höhe wiederholte Kopfzeile, eine unterste Zeile mit der Beschriftung „SUMME“ und einen als „12,50 (Angebot)“ geschriebenen Preis enthalten. Für Menschen sind das nützliche Gestaltungsentscheidungen, aber sie mischen verschiedene Arten von Inhalten in denselben Spalten.

So liest du das Blatt als relationale Tabelle:

1. Behandle die Spaltennamen als Kopfzeile, nicht als Verkaufsdatensätze.
2. Lass jede Datenzeile von genau einem Verkauf handeln; berechne die Summe aus diesen Zeilen.
3. Speichere den numerischen Preis getrennt von einer Anmerkung zum Verkauf.
4. Gib jedem Verkauf einen Schlüssel, damit seine Zeile identifiziert werden kann.

Eine Summenzeile zwischen den Verkäufen könnte als weiterer Verkauf gezählt oder ein zweites Mal zur Summe addiert werden. Eine Anmerkung, die in einem numerischen Preis steckt, verhindert gewöhnliche Rechenoperationen.

Logische Tabellen und physische Speicherung

Eine Tabelle ist das logische Bild der Daten für den Nutzer. Das DBMS kann ihre Daten in Dateien, Seiten und Indizes speichern, die für einen effizienten Zugriff angeordnet sind. Datenunabhängigkeit bedeutet, dass sich bei Änderungen an dieser physischen Anordnung weder die Tabellennamen noch die Bedeutung der Spalten noch die Anfragen der Anwendungen ändern müssen.

Ein Datentyp sagt einem DBMS, welche Art von Wert eine Spalte enthält und wie damit gearbeitet wird. Zahlen addieren, Texte vergleichen und Datumswerte ordnen sind unterschiedliche Operationen. Ein bekannter Typname kann sich außerdem je nach Datenbankprodukt unterschiedlich verhalten.

Zahlen: ganz, exakt und näherungsweise

In PostgreSQL, MySQL und SQL Server reicht INTEGER von −2.147.483.648 bis 2.147.483.647. BIGINT reicht bis 9.223.372.036.854.775.807; auch die Ganzzahlspeicherung von SQLite kann diesen Bereich erreichen.

Bei Dezimalzahlen ist die Genauigkeit die Gesamtzahl der Ziffern und die Dezimalstellenanzahl die Anzahl der Nachkommastellen. DECIMAL(8, 2) lässt sechs Ziffern vor dem Komma: Der Höchstwert ist 999.999,99. Der Preis 12,50 passt hinein, 1.234.567,00 nicht. PostgreSQL, MySQL, SQL Server und Oracle speichern Dezimalzahlen exakt. SQLite akzeptiert diese Deklaration, erzwingt aber weder Genauigkeit noch Dezimalstellenanzahl und kann Nachkommawerte als binäre Gleitkommazahlen speichern.

Gleitkommazahlen stellen viele Dezimalbrüche nur näherungsweise dar. In doppelter Genauigkeit ergibt die Addition von 0,1 und 0,2 den Wert 0,30000000000000004. SQLite behandelt diese Dezimalliterale als Gleitkommazahlen. PostgreSQL behandelt Dezimalliterale ohne Typangabe als exakte numerische Werte, sodass dieselbe geschriebene Rechnung dort exakt sein kann; ausdrücklich in doppelter Genauigkeit angegebene Werte zeigen die Näherung.

Text, Datumswerte und Flags

CHAR(n) ist Text fester Länge; PostgreSQL und SQL Server füllen kürzere Werte mit Leerzeichen auf. VARCHAR(n) erlaubt unterschiedliche Längen bis zu einer Obergrenze. SQLite ignoriert beide Längenangaben und füllt nicht auf. TEXT speichert lange Texte in SQLite, PostgreSQL und MySQL. SQL Server verwendet dafür VARCHAR(MAX) oder NVARCHAR(MAX); der ältere SQL-Server-Typ TEXT ist abgekündigt.

Ein DATE speichert ein Kalenderdatum, ein TIME eine Uhrzeit und ein TIMESTAMP in Standard-SQL Datum und Uhrzeit. Schreibe Datumswerte in der Form Jahr-Monat-Tag, etwa '2026-03-02', damit der 2. März nicht mit dem 3. Februar verwechselt wird. Typisierte Datumswerte haben ein internes Speicherformat; die Anwendung legt ihr Anzeigeformat fest. SQLite hat keinen eigenen Datumstyp und speichert meist ISO-Datumstext. SQL Server verwendet DATETIME2 für Datum und Uhrzeit: Dort bedeutet TIMESTAMP ROWVERSION, einen binären Versionszähler.

Ein BOOLEAN steht für TRUE oder FALSE oder für NULL, wenn der Wert fehlt. PostgreSQL hat einen booleschen Typ; SQL Server verwendet BIT, MySQL behandelt BOOLEAN als kleine Ganzzahl, und SQLite speichert die Flags als 1 und 0. Binäre Typen wie BLOB oder BYTEA in PostgreSQL speichern Bytes, etwa kleine Bilder. Größere Dateien werden oft separat gespeichert, und eine Tabelle enthält nur einen Pfad oder eine URL.

Typaffinität in SQLite

In gewöhnlichen SQLite-Tabellen ist ein deklarierter Typ eine Präferenz, die Typaffinität heißt. Eine INTEGER-Spalte wandelt '42' in die Zahl 42 um, kann 'abc' aber als Text behalten. Eine STRICT-Tabelle in SQLite weist Text zurück, der sich nicht in eine gültige Ganzzahl umwandeln lässt.

Beginne damit, was ein Wert bedeutet und wie er verwendet wird. Eine Postleitzahl (ZIP-Code) enthält Ziffern, aber niemand addiert Postleitzahlen, um eine aussagekräftige Summe zu erhalten. Eine Stückzahl enthält ebenfalls Ziffern, und Stückzahlen zu addieren ist nützlich. Das Aussehen allein ist ein schlechter Wegweiser für den Typ.

Fünf Fragen stellen

1. Was sind typische Werte, und welche Extremwerte müssen hineinpassen?
2. Wird mit den Werten gerechnet?
3. Müssen sie exakt sein, oder ist eine Näherung akzeptabel?
4. Wie müssen sie sortiert und verglichen werden?
5. Welche Größe passt zu realistischen künftigen Werten?

Geldbeträge und Messwerte

Geldbeträge müssen exakt sein. In PostgreSQL, MySQL und SQL Server kann ein Preis den Typ DECIMAL(8, 2) verwenden. Drei Artikel zu je 12,50 $ kosten genau 37,50 $. Binäre Gleitkommaspeicherung kann nach wiederholten Additionen winzige Fehler hinterlassen, sodass exakte Vergleiche unzuverlässig werden. In SQLite sorgt die Deklaration DECIMAL nicht für exakte Dezimalspeicherung; verwende für exakte Beträge ganzzahlige Centbeträge, sodass 12,50 $ als 1250 gespeichert wird.

Ein Messwert wie das Gewicht kann REAL verwenden, wenn kleine Rundungsdifferenzen akzeptabel sind. Lege die Einheit als Teil der Bedeutung der Spalte fest: weight_lb macht Pfund (lb) im Namen sichtbar. Ein numerischer Typ allein hält diese Einheit nicht fest.

Auch die Währung braucht eine Bedeutung. Mischt eine Tabelle Währungen, füge currency_code hinzu, etwa mit USD, EUR oder JPY. Die Anzahl der Nachkommastellen hängt von der Währung ab, und Beträge in verschiedenen Währungen müssen umgerechnet werden, bevor man sie addieren kann.

Codes und Namen sind Text

Verwende Text für Postleitzahlen, Telefonnummern, Kontonummern und Artikelnummern. Die Bostoner Postleitzahl '02108' verliert ihre führende Null, wenn sie in eine Ganzzahl umgewandelt wird. VARCHAR(10) kann auch ZIP+4 aufnehmen, etwa '02108-1234'. Telefonnummern können ein Pluszeichen, Leerzeichen und Bindestriche enthalten. Diese Zeichen gehören zur Darstellung einer Kennung und sind keine Rechenzeichen.

Plane Platz für echte Namen und Adressen ein. „Christopher Montgomery“ hat 22 Zeichen, daher ist VARCHAR(10) zu kurz. PostgreSQL und SQL Server weisen den Wert zurück; MySQL weist ihn im strikten Modus zurück und schneidet ihn andernfalls eventuell ab. SQLite speichert ihn, weil deklarierte Textlängen ignoriert werden. Ein großzügiges Feld variabler Länge vermeidet, dass gewöhnliche Namen abgewiesen werden, ohne für jede Zeile die maximale Länge zu reservieren.

Die Sortierung entlarvt eine falsche Wahl

Beim Sortieren von Text werden Zeichen verglichen. Als Text gespeicherte Zahlen können in der Reihenfolge '1', '10', '2', '25', '3' erscheinen. Eine numerische Spalte sortiert diese Werte numerisch. Wählst du für jedes Feld Text, verlagerst du Prüf- und Umwandlungsarbeit auf spätere Berechnungen.

Bei Datumswerten gibt es eine ähnliche Falle. Datumstext im US-Stil setzt '12/01/2025' in Textreihenfolge hinter '03/02/2026', obwohl Dezember 2025 früher liegt. Verwende einen Datumstyp oder in SQLite einheitlich formatierten ISO-Text, damit die Kalenderreihenfolge erhalten bleibt.

Die Typen eines Produkts zusammen lesen

Ein Produkt kann product_id INTEGER, sku VARCHAR(20), name VARCHAR(100), price DECIMAL(8, 2), weight_lb REAL, in_stock BOOLEAN und added_on DATE verwenden. Jeder Typ folgt einer Aufgabe: Identifikation, Speicherung eines Codes, ein Name, ein exakter Geldbetrag, ein Messwert, ein Flag oder ein Datum. In SQLite speicherst du den Preis als ganzzahligen Centbetrag und das Datum als ISO-Text.

NULL kennzeichnet einen fehlenden Wert. NULL unterscheidet sich von der Zahl Null, vom leeren Text '' und vom Text 'NULL'. Ein bekannter Rabatt von 0 bedeutet keinen Rabatt; ein Rabatt mit NULL bedeutet, dass der Betrag nicht erfasst ist. Eine NULL-fähige Spalte lässt fehlende Daten zu, während NOT NULL einen Wert verlangt.

Fehlen hat mehr als eine Bedeutung

Für James Wilson ist keine Telefonnummer erfasst. Bestellung 102 hat kein Versanddatum, weil sie noch nicht versandt wurde. Ein Firmenkunde hat womöglich keinen zutreffenden Nachnamen. Alle Fälle lassen sich mit NULL darstellen, aber NULL hält nicht fest, welcher Grund zutrifft. Ein Datenkatalog sollte die Bedeutung jeder Spalte angeben.

Leerer Text ist in PostgreSQL und SQLite ein vorhandener Textwert. Oracle behandelt leeren Text derzeit als NULL. Abfragewerkzeuge zeigen beides womöglich als scheinbar leere Zelle an; am Aussehen allein lassen sie sich also nicht unterscheiden.

Vergleiche können unbekannt sein

SQL-Vergleiche haben drei mögliche Ergebnisse: TRUE, FALSE und UNKNOWN. Ein Vergleich, an dem NULL beteiligt ist, auch NULL = NULL, ergibt UNKNOWN. Von zwei fehlenden Fakten ist nicht bekannt, dass sie denselben Wert haben.

Eine WHERE-Klausel behält nur Ergebnisse, die TRUE sind. Lies diese Bedingungen:

• phone IS NULL findet fehlende Telefonnummern.
• phone IS NOT NULL findet erfasste Telefonnummern.
• phone = NULL ergibt UNKNOWN und findet keine Zeilen.

Einen Vergleich zu verneinen bringt einen fehlenden Wert nicht zurück. Nimm zu den vier Kunden des Shops Daniel Brown hinzu, dessen Bundesstaat NULL ist. Die Bedingung state <> 'TX' behält CO, MA und WA: drei Zeilen. Daniel wird ausgeschlossen, weil der Vergleich seines Bundesstaats UNKNOWN ergibt. Sollen fehlende Bundesstaaten ebenfalls dabei sein, lautet die Bedingung state <> 'TX' OR state IS NULL.

Bedingungen sorgfältig verknüpfen

Stell dir UNKNOWN als „könnte TRUE oder FALSE sein“ vor. Ein Ergebnis steht nur fest, wenn beide Möglichkeiten zum selben Ausgang führen.

Berechnungen und Zusammenfassungen

Gewöhnliche Arithmetik mit NULL ergibt NULL: 5 + NULL ist NULL. Ein Positionspreis multipliziert mit einer fehlenden Stückzahl fehlt ebenfalls und ergibt nicht etwa den Wert Null. Verkettest du Text mit || und NULL, ergibt das in PostgreSQL und SQLite NULL; die Verkettung in Oracle behandelt NULL als leeren Text.

Zusammenfassende Funktionen überspringen NULL-Eingaben in der Regel. Bei fünf Kunden, darunter James und Daniel ohne Telefonnummer, zählt COUNT(*) alle fünf Zeilen. COUNT(phone) zählt die drei erfassten Telefonnummern. Der Durchschnitt von 4, NULL und 2 ist 3, weil die beiden bekannten Zahlen durch zwei geteilt werden; würde man NULL als Null behandeln, ergäbe sich fälschlich 2.

Verwende NOT NULL für Angaben, die vorhanden sein müssen, etwa ein Bestelldatum. Es erzwingt weder eine positive Zahl noch einen nicht leeren Text: Das sind eigene Regeln. Primärschlüssel verlangen eine Identität ohne NULL; gewöhnliche SQLite-Tabellen haben bei manchen Primärschlüsseldeklarationen eine historische Ausnahme, deshalb ist ein ausdrückliches NOT NULL dort wichtig.

Ein Schlüssel identifiziert eine Zeile über ihre Werte. Namen können sich wiederholen; Kundenkennungen unterscheiden Datensätze, sodass man sie lesen, ändern oder verknüpfen kann.

Eindeutigkeit und Minimalität prüfen

Ein Superschlüssel ist eine Spalte oder Spaltenkombination, die eine Zeile eindeutig identifiziert. Ein Schlüsselkandidat ist ein minimaler Superschlüssel: Entfernt man eine beliebige Spalte, geht diese Garantie verloren. Wähle einen Kandidaten als Primärschlüssel; die übrigen sind Alternativschlüssel.

Angenommen, employee_id, ssn und email sind jeweils Pflichtangaben und eindeutig. Dann ist jede dieser Spalten ein Schlüsselkandidat. (employee_id, department) ist ein Superschlüssel, aber kein Kandidat: employee_id allein identifiziert den Mitarbeiter. Ein wiederholter Nachname besteht den Eindeutigkeitstest nicht.

Vier Kunden mit verschiedenen Nachnamen begründen keinen Schlüssel: Ein fünfter kann denselben Namen haben. Die Eindeutigkeit muss für alle zulässigen künftigen Daten gelten. Eine Wiederholung widerlegt einen vorgeschlagenen Schlüssel; eine Stichprobe ohne Wiederholungen braucht trotzdem eine stützende Geschäftsregel.

Die Deklaration lesen

Eine Tabelle hat höchstens einen Primärschlüssel. Seine Werte sind eindeutig, und seine Spalten dürfen nicht NULL sein. Stabile Werte vermeiden wiederholte Änderungen an Verweisen. Achte auf PRIMARY KEY: Weder der Name einer Spalte noch ihre Position deklariert den Primärschlüssel.

Existiert Kunde 1, wird ein weiterer Kunde mit dem Schlüssel 1 abgewiesen. Ein weggelassener Schlüssel braucht einen Standardwert oder einen generierten Wert. INTEGER PRIMARY KEY in SQLite erzeugt eine Ganzzahl, wenn der Wert weggelassen oder als NULL angegeben wird. Einige andere Primärschlüsseldeklarationen in gewöhnlichen SQLite-Tabellen lassen aus historischen Gründen NULL zu; ein ausdrückliches NOT NULL, eine STRICT-Tabelle oder die Form mit ganzzahligem Primärschlüssel schließt diese Lücke.

Einen zusammengesetzten Schlüssel lesen

In enrollments(student_id, course_id, term, grade) kann ein Student mehrere Kurse belegen und einen davon in einem anderen Semester wiederholen. (student_id, course_id, term) identifiziert eine Einschreibung: ein zusammengesetzter Primärschlüssel, nicht drei getrennte Primärschlüssel.

Einzelne Bestandteile dürfen sich wiederholen, die vollständige Kombination nicht. Die meisten DBMS legen zum Nachschlagen einen Index für den Primärschlüssel an, aber der Schlüssel garantiert keine Reihenfolge der Abfrageausgabe.

Ein natürlicher Schlüssel stammt aus Daten der realen Welt, etwa die FIN (VIN) eines Fahrzeugs, die ISBN einer Buchausgabe oder das Kürzel eines Bundesstaats. Ein Surrogatschlüssel existiert nur, um eine Zeile zu identifizieren, oft als generierte Ganzzahl oder UUID.

Eine dauerhafte Kennung wählen

Bevorzuge eindeutige, stets vorhandene, stabile, kompakte Werte, die man unbedenklich weitergeben kann. Namen wiederholen sich; Telefonnummern und E-Mail-Adressen ändern sich oder werden geteilt. Sozialversicherungsnummern sind sensibel und für manche Kunden nicht verfügbar; verwendet man sie in verweisenden Tabellen, verbreitet sich diese Information.

Mit einer generierten customer_id behält Maria die Kennung 1, auch wenn sich ihre Kontaktdaten ändern. Ein natürlicher Schlüssel state_code wie TX kann gut funktionieren, weil er kompakt, standardisiert und in Adressdatensätzen nützlich ist.

Geschäftliche Kennungen eigens schützen

Dieselbe Person kann sich zweimal registrieren und zwei Surrogat-IDs erhalten. Die IDs unterscheiden Zeilen; doppelte Personen erkennen sie nicht.

Muss die E-Mail-Adresse jedes Konto identifizieren, verwende NOT NULL UNIQUE. UNIQUE allein erlaubt in PostgreSQL, SQLite und MySQL mehrere NULL-Werte. SQL Server erlaubt bei einer UNIQUE-Bedingung auf einer einzelnen Spalte normalerweise genau einen NULL-Wert. Vorhandensein und Eindeutigkeit sind getrennte Regeln.

Die verpflichtende, eindeutige E-Mail-Adresse ist ein Alternativschlüssel. Ändert sie sich, bleibt die Surrogat-Kundennummer in bestehenden Bestellungen unverändert. Ändert sich ein referenzierter Primärschlüssel, müssen auch die Verweise in den Kindtabellen konsistent bleiben.

Syntax für generierte Schlüssel erkennen

PostgreSQL kennt außerdem die ältere Form SERIAL. Löschungen, fehlgeschlagene Einfügungen und abgebrochene Vorgänge können Lücken hinterlassen. Die IDs 1, 2 und 4 kennzeichnen drei Zeilen, nicht vier. Wer neu nummeriert, um Lücken zu schließen, kann Verweise zerstören.

UUIDs erkennen

Eine UUID ist eine 128-Bit-Kennung, die meist als 36 Zeichen mit Bindestrichen geschrieben wird: 7c9e6679-7425-40de-944b-e07fc1f90ae7. Computer können sie unabhängig voneinander mit sehr geringem Kollisionsrisiko erzeugen; das ist nützlich, wenn Datensätze von mehreren Orten zusammengeführt werden.

UUIDs brauchen mehr Platz und sind schwerer zu lesen als kleine Ganzzahlen. Wähle danach, wie Datensätze erzeugt und referenziert werden. Beide Arten von Schlüsseln sind Etiketten: Ihr Höchstwert ist keine Zeilenanzahl, und ihre Reihenfolge muss nicht die zeitliche Abfolge von Ereignissen zeigen.

Ein Fremdschlüssel ist eine Spalte oder Spaltengruppe, die auf einen Primärschlüssel oder einen anderen geeigneten eindeutigen Schlüssel verweist. Die Tabelle mit dem Verweis ist die Kindtabelle; die Tabelle, auf die sie zeigt, ist die Elterntabelle. Ein Fremdschlüssel, der nicht NULL ist, muss zu einem existierenden Elternschlüssel passen, wenn die Integritätsbedingung durchgesetzt wird.

Einem Wert über Tabellen hinweg folgen

orders.customer_id verweist auf customers.customer_id. Bestellung 102 zeigt auf Kunde 2, James Wilson. Die Bestellungen 101 und 103 zeigen beide auf Kunde 1, Maria Garcia. Im Fremdschlüssel sind Wiederholungen erlaubt; der referenzierte Elternschlüssel ist eindeutig.

Diese Regel heißt referenzielle Integrität. Eine Bestellung für Kunde 99 wird abgewiesen, wenn Kunde 99 nicht existiert. Andernfalls wäre sie verwaist: eine Kindzeile ohne passende Elternzeile. Ein Name allein erzeugt keine Integritätsbedingung. Ein Fremdschlüssel namens placed_by kann trotzdem auf customer_id verweisen; die Verknüpfung entsteht durch den deklarierten Verweis, wobei die Schlüsselspalten zueinander passende Typen haben.

Optional oder verpflichtend

Eine NULL-fähige coupon_id kann NULL sein, wenn eine Bestellung keinen Gutschein hat. Eine als NOT NULL deklarierte customer_id verlangt, dass jede Bestellung einen Kundenverweis hat, und der Fremdschlüssel verlangt, dass dieser Kunde existiert. Beide Integritätsbedingungen wirken zusammen: Die eine verlangt einen Wert, die andere prüft den Verweis.

Fremdschlüssel müssen keine Tabellengrenzen überschreiten. In employees(employee_id, name, manager_id) kann manager_id auf employee_id in derselben Tabelle verweisen. Bei der Person an der Spitze des Unternehmens kann der Verweis auf die Führungskraft NULL sein.

Änderungen an Elternzeilen brauchen eine Regel

Mit der Standardaktion kann Kunde 1 nicht gelöscht werden, solange die Bestellungen 101 und 103 noch auf diese Kundin verweisen. Eine Kaskade von einer Bestellung auf ihre Positionen kann sinnvoll sein, weil diese Positionen zu genau dieser Bestellung gehören. ON UPDATE legt das entsprechende Verhalten fest, wenn sich ein Elternschlüssel ändert. Kaskadierung bedeutet nicht, dass das Löschen einer Kindzeile ihre Elternzeile löscht.

Zusammengesetzte Verweise und Durchsetzung

Wird eine Bestellposition durch (order_id, product_id) identifiziert, braucht eine Lieferung, die auf diese Position verweist, beide Spalten. Die Kombination muss zu einer existierenden Position passen. Bestellung und Produkt getrennt abzugleichen reicht nicht: Dieses Produkt kam in dieser Bestellung vielleicht nie vor. Ein verpflichtender zusammengesetzter Verweis deklariert alle seine Spalten als NOT NULL.

PostgreSQL, SQL Server, Oracle und MySQL mit seiner üblichen Engine InnoDB setzen deklarierte Fremdschlüssel durch. In SQLite musst du die Fremdschlüsselprüfung für jede Verbindung mit PRAGMA foreign_keys = ON; aktivieren und kontrollieren, bevor du dich darauf verlässt. Eine deklarierte, aber deaktivierte Integritätsbedingung kann die Zeilen nicht schützen. Fremdschlüssel führen Abfrageergebnisse auch nicht von selbst zusammen; eine Abfrage muss der Verknüpfung ausdrücklich folgen, meist über einen Join.

Um eine Beziehung zu bestimmen, stell zwei Fragen: „Wie viele Zeilen dort können mit einer Zeile hier verknüpft sein?“ und dann die umgekehrte Frage. Berücksichtige das Minimum ebenso wie das Maximum. Die heutige Stichprobe zeigt, was passiert ist; die Integritätsbedingungen beschreiben, was erlaubt ist.

Ein Kunde, viele Bestellungen

Ein Kunde kann keine oder mehrere Bestellungen aufgeben. Jede Bestellung des Shops gehört zu genau einem Kunden, weil orders.customer_id ein Fremdschlüssel ist, der nicht NULL sein darf. Das ist eine Eins-zu-viele-Beziehung. Der Fremdschlüssel gehört in orders, auf die „Viele“-Seite: Jede Bestellung speichert einen Kundenverweis.

Maria hat die Bestellungen 101 und 103; James hat Bestellung 102. Aisha und Wei haben keine. Dass sie in orders nicht vorkommen, ist zulässig. Ein Fremdschlüssel verlangt zu jeder Kindzeile eine Elternzeile, aber nicht, dass jede Elternzeile eine Kindzeile hat.

Eins zu eins braucht zusätzlich Eindeutigkeit

In user_profiles(user_id, bio, photo_url) sei user_id zugleich Primärschlüssel und Fremdschlüssel auf users. Jedes Profil verweist auf einen Nutzer, und ein Nutzer kann höchstens ein Profil haben, weil sich der Profilschlüssel nicht wiederholen kann. Ein Nutzer hat vielleicht noch kein Profil.

Ein Fremdschlüssel ohne Eindeutigkeit würde mehrere Profile für denselben Nutzer erlauben und ergäbe eins zu viele. Die Eindeutigkeitsbedingung ändert das Maximum. Solche getrennten Profiltabellen können optionale oder sensible Angaben vom Hauptdatensatz des Nutzers getrennt halten.

Viele zu viele nutzt eine Tabelle aus Paaren

Eine Bestellung kann mehrere Produkte enthalten, und ein Produkt kann in mehreren Bestellungen vorkommen. Eine Zwischentabelle, auch Brücken-, Verknüpfungs- oder Assoziationstabelle genannt, erfasst jede Paarung:

order_id verweist auf orders; product_id verweist auf products. Der zusammengesetzte Primärschlüssel (order_id, product_id) erlaubt dasselbe Produkt in verschiedenen Bestellungen, verhindert aber, dass dasselbe Paar zweimal vorkommt. Zwei Eins-zu-viele-Verknüpfungen setzen die Viele-zu-viele-Beziehung um.

quantity und unit_price gehören zur Paarung. Sie beschreiben, wie viel von diesem Produkt in dieser Bestellung verkauft wurde und welcher Preis damals verlangt wurde. Ein aktueller Produktpreis kann sich später ändern; er darf den historisch verlangten Betrag nicht überschreiben.

Für Bestellung 101 sind die beiden Positionsbeträge zwei Becher zu je 12,50 $, also 25,00 $, und ein Ladegerät zu 8,99 $. Zusammen kosten sie 33,99 $. Die Stückzahl gibt an, wie viele Becher gekauft wurden; zwei doppelte Becherpositionen zu speichern würde dem gewählten Schlüssel dieser Tabelle widersprechen.

Listen und feste Plätze vermeiden

Eine Zelle product_ids mit dem Textwert '11,12' versteckt mehrere Verweise in einem einzigen Textwert. Spalten wie product1, product2 und product3 legen eine feste Obergrenze fest und lassen ungenutzte Plätze zurück. Eine Zwischentabelle fügt für jede weitere Paarung eine Zeile hinzu und lässt das DBMS jeden Verweis einzeln prüfen.

Eine selbstreferenzierende Beziehung nutzt dasselbe Muster innerhalb einer Tabelle: Viele Mitarbeiter können über manager_id auf dieselbe Führungskraft verweisen. Die Führungskraft ist ebenfalls eine Mitarbeiterzeile. Lies jede Verknüpfung als Rolle, damit die Identität des Mitarbeiters und der Verweis auf die Führungskraft getrennt bleiben.

Ein Schema beschreibt Tabellen, Spalten, Datentypen und Integritätsbedingungen. Eine Ausprägung sind die zu einem bestimmten Zeitpunkt gespeicherten Daten. Kommt eine Bestellung hinzu, ändert sich die Ausprägung; kommt eine neue Spalte hinzu, ändert sich das Schema. Das Schema sagt, was gespeichert werden kann, die Zeilen sagen, was jetzt gespeichert ist.

Eine Kurzbeschreibung lesen

customers(customer_id, first_name, last_name, email, phone, city, state, zip_code) nennt eine Tabelle und ihre Spalten. In Notizen werden Primärschlüssel manchmal unterstrichen oder mit PK markiert und Verweise mit FK. So nennt zum Beispiel orders(order_id PK, customer_id FK → customers, order_date, shipped_date) den Hauptschlüssel und die Verknüpfung zum Kunden.

Eine vollständige Tabellendefinition lesen

CREATE TABLE orders (
  order_id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL REFERENCES customers (customer_id),
  order_date DATE NOT NULL,
  shipped_date DATE
);

Lies eine Spalte nach der anderen. order_id ist der ganzzahlige Primärschlüssel. customer_id ist eine Pflichtangabe und muss auf einen Kunden verweisen. order_date ist eine Pflichtangabe. shipped_date darf NULL sein. Diese Definition beschreibt die zulässige Struktur, keine Liste existierender Bestellungen.

Integritätsbedingungen beantworten unterschiedliche Fragen:

Ein Standardwert ersetzt keinen angegebenen ungültigen Wert. Hat status die Angabe DEFAULT 'pending' und lässt du den Status weg, wird 'pending' eingetragen; ein angegebener Wert muss trotzdem die übrigen Regeln der Spalte erfüllen.

Regeln für eine Bestellposition kombinieren

CREATE TABLE order_items (
  order_id INTEGER NOT NULL REFERENCES orders (order_id),
  product_id INTEGER NOT NULL REFERENCES products (product_id),
  quantity INTEGER NOT NULL CHECK (quantity > 0),
  unit_price DECIMAL(8, 2) NOT NULL,
  PRIMARY KEY (order_id, product_id)
);

Der Primärschlüssel am Ende umfasst zwei Spalten. Eine zweite Position für dieselbe Bestellung und dasselbe Produkt scheitert. Die Stückzahl 0 scheitert an der Prüfung. Eine fehlende Stückzahl scheitert an NOT NULL: Die Prüfung allein würde NULL zulassen, weil NULL > 0 UNKNOWN ergibt und nicht FALSE. Ein ausdrückliches NOT NULL auf beiden Schlüsselteilen vermeidet außerdem die historische Ausnahme von SQLite für zusammengesetzte Schlüssel mit NULL. Verwende in SQLite ganzzahlige Centbeträge für einen exakten unit_price; die Dezimaldeklaration allein sorgt nicht für exakte Speicherung.

Das Schema und seine Bedeutungen finden

In der SQLite-Shell zeigt .schema orders die Definition an; in psql von PostgreSQL beschreibt \d orders die Tabelle. Die Sichten INFORMATION_SCHEMA listen in PostgreSQL, MySQL und SQL Server strukturelle Metadaten auf. SQLite listet Objekte in sqlite_schema auf, und grafische Werkzeuge zeigen Tabellen und Spalten in einem Baum.

„Schema“ bezeichnet in Systemen wie PostgreSQL und SQL Server außerdem einen Namensraum. sales.orders bezeichnet die Tabelle orders im Schema sales. Ein Datenkatalog liefert Bedeutungen, die die Struktur nicht ausdrücken kann, etwa die Währung der Preise oder ob ein fehlendes Versanddatum „nicht versandt“ bedeutet. Um Zeilen zu sehen, liest eine Abfrage wie SELECT * FROM orders; die aktuelle Ausprägung.

Ein Schemadiagramm zeichnet jede Tabelle als Kasten. Der Titel nennt die Tabelle; der Inhalt listet die Spalten und oft ihre Typen auf. PK markiert Primärschlüssel, FK markiert Fremdschlüssel. Beziehungslinien zeigen, welcher Fremdschlüssel auf welchen Elternschlüssel verweist.

Zuerst die Art der Linie bestimmen

Manche Diagramme verwenden einen Pfeil vom Fremdschlüssel zum referenzierten Schlüssel. Ein Pfeil von orders.customer_id zu customers.customer_id beschreibt die Richtung des Verweises. Andere Werkzeuge beschreiben mit Endsymbolen, wie viele Zeilen verknüpft sein können. Sieh in der Legende des Diagramms nach: Die Richtung eines Pfeils und die Kardinalität einer Beziehung sind unterschiedliche Informationen.

Krähenfußsymbole lesen

In der Krähenfußnotation bedeutet ein Strich eins, ein Kreis null und ein Fuß mit drei Zinken viele. Jedes Linienende gibt ein Minimum und ein Maximum an. Das Symbol, das der Tabelle am nächsten ist, gibt das Maximum an, das andere das Minimum.

Wenn du von einer Tabelle aus liest, schau auf die Symbole neben der anderen Tabelle. Diese Symbole beschreiben, wie viele Zeilen dort zu deiner einen Ausgangszeile passen können.

Kunden und Bestellungen durchgehen

Die Linie im Shop hat neben customers die Symbole für genau eins und neben orders die Symbole für null oder mehr.

1. Beginne mit einem Kunden. Schau auf das Ende bei den Bestellungen: Der Kunde kann keine oder mehrere Bestellungen haben.
2. Beginne mit einer Bestellung. Schau auf das Ende bei den Kunden: Die Bestellung gehört zu genau einem Kunden.
3. Prüfe die Definition: Der Fremdschlüssel, der nicht NULL sein darf, steht in orders; diese Tabelle ist also die „Viele“-Seite, und jede Bestellung braucht einen gültigen Kunden.

Der Krähenfuß steht neben der Tabelle mit dem sich wiederholenden Fremdschlüssel. Liest du das nahe Ende, während du von derselben Tabelle ausgehst, kehrst du die Bedeutung um. Ein NULL-fähiger Kundenverweis würde das Ende bei den Kunden zu null oder eins ändern; er würde nicht jeden Kunden auf eine Bestellung beschränken.

Eine Zwischentabelle erkennen

Der Shop hat Eins-zu-viele-Verknüpfungen von orders zu order_items und von products zu order_items. Beide „Viele“-Enden treffen sich bei order_items. Die beiden Fremdschlüssel dieser Tabelle bilden ihren Primärschlüssel. Durch diese Struktur kann eine Bestellung mehrere Produkte enthalten und ein Produkt in mehreren Bestellungen vorkommen.

Das Diagramm beschreibt zulässige Verbindungen, nicht die heutigen Anzahlen. Es erlaubt, dass Maria mehrere Bestellungen hat und Aisha keine. Wie viele jede tatsächlich hat, erfährst du aus den Zeilen. Ein Minimum von eins von der Eltern- zur Kindseite kann eine zusätzliche Geschäftsregel ausdrücken; ein Fremdschlüssel allein verlangt nicht, dass eine Elternzeile Kindzeilen hat.

Verwandte Diagrammarten erkennen

Ein Entity-Relationship-Diagramm, das beim Entwurf entsteht, kann geschäftliche Entitäten zeigen, bevor Tabellen existieren. Diagramme nach Chen verwenden Ovale für Attribute und Rauten für Beziehungen. Ein Schemadiagramm zeigt die tatsächlichen Tabellen und ihre deklarierten Schlüssel. Beide helfen, Strukturen zu vermitteln, aber ihre Symbole müssen nach der jeweils eigenen Legende gelesen werden.

Finde jede gefragte Information und folge den Schlüsseln, die sie mit dem Ausgangsdatensatz verbinden. Namen können sich wiederholen oder ändern; gleiche stattdessen Schlüsselwerte ab.

Den Kunden einer Bestellung finden

„Wo wohnt der Kunde, der Bestellung 102 aufgegeben hat?“ folgt diesem Weg:

1. Finde Bestellung 102 über orders.order_id.
2. Lies ihre customer_id ab: 2.
3. Finde Kunde 2 über customers.customer_id.
4. Lies customers.city ab: Denver.

Die Bestellnummer 102 ist nicht die Kundenkennung. SQL-Joins automatisieren diese Schlüsselabgleiche; Anzeigepositionen verbinden die Datensätze nicht.

Produkte und eine historische Summe finden

Zu Bestellung 101 gehören diese Zeilen in order_items. Folge jeder product_id zu products, um den Namen zu finden:

Verwende den erfassten Positionspreis für den verlangten Betrag:

• Zwei Becher zu je 12,50 $ kosten 25,00 $.
• Ein Ladegerät zu 8,99 $ kostet 8,99 $.
• Summe: 33,99 $.

Der heutige Produktpreis könnte die Kosten einer alten Bestellung falsch wiedergeben. Bestellung 102 enthält eine Lampe zu 34,00 $; Bestellung 103 enthält vier Becher zu je 12,50 $, zusammen 50,00 $.

Fehlende Werte und Regeln deuten

Das Versanddatum von Bestellung 102 ist NULL, hier dokumentiert als „nicht versandt“. Prüfe es mit IS NULL, nicht mit einem Gleichheitsvergleich mit NULL.

Lies jede relevante Integritätsbedingung, wenn du eine Änderung beurteilst:

• Eine Position für Bestellung 104 scheitert, wenn diese Bestellung nicht existiert.
• Eine weitere Position mit dem Schlüssel (101, 11) scheitert, weil das Paar bereits existiert.
• Die Stückzahl 0 scheitert an der Prüfung auf eine positive Stückzahl.
• Das Standardverhalten des Fremdschlüssels verhindert das Löschen von Produkt 11, solange Positionen darauf verweisen.

Ein noch nicht verwendeter Schlüssel macht eine Zeile nicht gültig, wenn ihr Verweis ins Leere geht.

Die neuen Zeilen bestimmen

Kauft ein wiederkehrender Kunde zwei verschiedene vorhandene Produkte, kommen eine Zeile in orders und zwei Zeilen in order_items hinzu. Der Kunde und die Produkte existieren bereits. Wird ein neues Produkt angeboten, kommt eine Zeile in products hinzu, ohne dass dafür eine Bestellung nötig ist.