Autorenliste[Bearbeiten]

Diesen Text stammt aus dem Wikipedia-Artikel w:Referenzielle Integrität, den ich weitgehend (etwa zu 70%) verfasst habe. Allerdings ist man dort der Meinung, dass dieser Text nicht ins Wikipedia gehört, weil er zu technisch und detailliert ist. Daher stelle ich diesen Text erst mal hier hin zur weiteren Bearbeitung.

Im Wikipedia-Artikel werde ich diesen Text dann entsprechend kürzen. Mein Ziel ist es, dass die beiden Artikel im Wikibooks und Wikipedia sich nicht mehr überschneiden, sondern ergänzen. Mithilfe ist jederzeit willkommen. --Julius-m 22:22, 8. Jan. 2008 (CET)[Beantworten]

Dieser Artikel basiert auf dem Artikel w:Referenzielle Integrität aus dem freien Projekt wikipedia und steht unter der GNU Lizenz für freie Dokumentation und der CC-by-sa 3.0. Gemäß den Lizenzbestimmungen ist hier die Liste der Autoren zum Exportzeitpunkt 08. Jan. 2008 00:00:00 UTC wiedergegeben.

Benutzer

Softeis, Edits:7

Julius-m, Edits:5

Complex, Edits:2

Sparti, Edits:2

Diba, Edits:1

Nicky knows, Edits:1

Knospe, Edits:1

Sallynase, Edits:1

Jpp, Edits:1

IP-Adressen

An dem Artikel haben keine IP's mitgearbeitet oder sie sind hier nicht angegeben.

Einen fertig ausgefüllten Textbaustein erstellt Duesentrieb's Contributor Tool auf dem Wikimedia Toolserver. Ist die Liste lang, ist es zweckmäßig, dafür eine neue Seite zu erstellen und von der Seite mit den importierten Inhalten darauf zu verweisen.

Diskussion[Bearbeiten]

Kapitel überarbeiten[Bearbeiten]

Hallo Julius, ich bin (wie du vielleicht beobachtet hast) inzwischen erheblich weiter. Vor allem kannst du unter Beispieldatenbank nachlesen, was ich dazu anmerke und noch ändere.

Ich möchte dich deshalb bitten, ob du die Seite Fremdschlüssel-Beziehungen überarbeiten könntest. Mir schwebt (unter Berücksichtigung der beiden DDL-Kapitel DDL - Struktur der Datenbank und DDL - Einzelheiten) vor, dass dabei etwas weniger Theorie gebracht wird und die Befehle mit ihren Optionen möglichst vereinheitlicht werden. Dabei sollten (soweit es geht) nur Optionen verwendet werden, die es in mehreren DBMS in (fast) gleicher Weise gibt, siehe auch die Dokumentationen in den Weblinks.

Wenn du dich nicht zu einer solchen Überarbeitung in der Lage siehst, werde ich es machen und dir vor der Veröffentlichung Gelegenheit zur Stellungnahme geben. (Aber ich hoffe, dass das nicht nötig wird; am Buch fehlen noch genug andere Abschnitte, vor allem sämtliche Übungen.)

Bitte beachte auch den Nachtrag zu Skript-ForeignKeys auf der Download-Seite, der noch um Optionen zu erweitern ist. Ich weiß, dass du dich bei diesem Thema nicht auf die Beispieldatenbank beschränken kannst, aber als Anhaltspunkt wäre es gut. Danke! -- Juetho 09:03, 23. Okt. 2009 (CEST)[Beantworten]

Hallo Juetho, bei DB2 ond Oracle muss man diese Optionen nicht unbedingt angeben DELETE RESTRICT ist default. Daher würde das so schon ausreichen. --Julius-m 21:02, 4. Nov. 2009 (CET)[Beantworten]

Begriffe für Haupttabelle / zugeordnete Tabelle[Bearbeiten]

Hallo, sind die hier gewählten Begriffe wirklich richtig definiert? Unter 'Haupttabelle' würde ich die Tabelle verstehen, in der die 'Hauptobjekte' geführt werden, die 'zugeordnete Tabelle' würde die den Hauptobjekten zugeordneten Objekte enthalten. Hier im Artikel wird das aber umgekehrt bezeichnet. Ich halte dies hier, zumal keine Quellen genannt sind, insbesondere auch sprachlich für unkorrekt: Unter 'Haupt' werden üblicherweise 'wichtigere', hierarchisch übergordnete Dinge verstanden, 'zugeordnet' ist hier im Zusammenhang uneindeutig. MS Access bezeichnet diese beiden Seiten mit 'Tabelle' und 'verwandte Tabelle' - was aber zugegebenermaßen auch an Eindeutigkeit 'zu wünschen übrig' lässt. --93.204.110.127 10:04, 15. Mai 2012 (CEST)[Beantworten]

Auf mögliche Missverständnisse und fehlende Eindeutigkeit kann ich doch nicht noch klarer hinweisen als im Abschnitt Die Definition.

Die Begriffe Haupttabelle und zugeordnete Tabelle stammen nicht aus Quellen (welcher Art auch immer). Ich wollte den möglichen Missverständnissen, die ich schließlich erläutere, aus dem Wege gehen und habe mich um eigene Begriffe bemüht.

Als Haupttabelle sehe ich diejenige Tabelle an, die die "eigentlichen" Informationen enthält, also z.B. die Liste der Versicherungsverträge (erstes Beispiel kurz vorher in der Aufstellung "Beziehungen definieren"). Ein Versicherungsvertrag ist darauf angewiesen, dass Versicherungsnehmer, Fahrzeug und Mitarbeiter bekannt sind und zum Vertrag gehören. Insofern halte ich die Formulierung "zugeordnete Tabelle" für hinreichend eindeutig. (Ein Begriff "zugehörige Tabelle" wäre weniger eindeutig, weil die Mitarbeiter auch zu den Abteilungen und zu den Schadensfällen gehören, die Fahrzeuge zu den Schadensfällen usw.)

Ich bin selbstverständlich offen für bessere Formulierungen: mindestens genauso klar, verständlich und eindeutig, dabei möglichst nicht länger. -- Jürgen 10:36, 15. Mai 2012 (CEST)[Beantworten]

Hallo und Danke. Den Abschnitt 'Definition' hatte ich nicht gelesen, ich war per 'find' auf den Text gestoßen.

Zu deinem Beispiel: Wie kann jemand sagen, was die 'eigentlichen Informationen' sind? Beide Tabellen enthalten Informationen. Was 'wichtiger' ist, hängt vom Blickwinkel der Betrachter und der jeweiligen Situation ab.

Vor allem kommt es darauf an, wer von wem 'abhängig' ist; das 'zugeordnet' ist hierzu ein ungeeigneter Ausdruck und wirklich missverständlich. Ich habe ihn anderswo praktisch auch noch nie vorgefunden. Auch sind 'Master-' und 'Haupt-' sprachlich so eng miteinander verwandt, dass auch das nur zu Missverständnissen führen kann. Das mit deinen "eigenen Begriffen" mag gut gemeint gewesen sein, liegt aber m.E. gründlich daneben. Die Wikipedia nennt das 'Theoriefindung' und drängt nicht umsonst auf eine gute Beleglage.

Mein Vorschlag: Verwenden von Master- und Detailtabelle mit Hinweis auf 'abhängig' - bei Beibehaltung und ggf. Ergänzung (verwandt?) deiner (sinnvollen und wichtigen) Hinweise unter Definition.

Grüße von --93.204.110.127 11:00, 15. Mai 2012 (CEST)[Beantworten]

Also aus einer Begriffsdeutung eine Theoriefindung konstruieren zu wollen halte ich für eine ziemlich plumpe Keule. -- ThePacker 13:01, 15. Mai 2012 (CEST)[Beantworten]

Es gibt gute Gründe in einem Einsteigerbuch für Muttersprachler deutsche Begriffe zu verwenden, auch wenn sie nicht geläufig sind. Denn in dem deutschen Begriff findet man aus dem deutschen Sprachverständnis heraus einen Draht zu dem Gegenstand, um dessen Beschreibung es geht. Später (im Laufe der Zeit) kann man immer noch die genormten Begriffe verwenden, bei einem Einsteigerbuch ist das nicht zwanglsläufig notwendig. Wenn ich jemandem Unbedarften ein Use-case-diagramm nahebringen möchte, assoziiere ich bei demjenigen ein abstraktes Konzept mit einem abstrakten Begriff, den derjenige ebenso erlernen muss. Wenn ich ihm aber sage, dass es ein Anwendigsfalldiagramm ist, hat er zumindest eine Vorstellung davon, was ein solches Diagramm in wirklichkeit bescheibt. Später kann derjenige immer noch use-case dazu sagen. -- ThePacker 13:08, 15. Mai 2012 (CEST)[Beantworten]

Theoriefindung oder Begriffsfindung, das macht keinen großen Unterschied. Jedenfalls ist von meiner Seite alles gesagt. Ich kritisiere niemanden, denke aber, wenn es schon unterschiedliche Bezeichnungen gibt, darf man nicht noch weitere hinzu-erfinden - zumal ich die Begründung für die o.g. Begriffe zweifelhaft finde; s.o. WP-Nutzer VÖRBY, 15.5.12 / 14:33 Uhr / ergänzt: 16.5. 13:05h

Auch nach längerem Nachdenken kann ich mich nicht damit anfreunden, die Begriffe "Master" und "Detail" zu verwenden.

Ich schreibe deutsch. Anglizismen will ich nur erwähnen, aber selbst nur dann benutzen, wenn es nicht anders geht (wie mangels brauchbarer Alternativen bei VIEW oder DOMAIN).
Gerade zum Begriffspaar Master/Detail habe ich widersprüchliche Erklärungen gelesen und erwähnt.
Auf die "passende" Erklärung per Beispiel auf der Wikipedia-Seite habe ich hingewiesen. Leider ermöglicht die Beispieldatenbank keinen vergleichbaren Fremdschlüssel; sonst hätte ich diese Erklärung übernommen und angepasst.
Jedes Begriffspaar stößt an seine Grenzen, sobald Ring-Verkettungen und rekursive Fremdschlüssel betrachtet werden. Dann ist jede beteiligte Tabelle gleichzeitig Master und Detail.

Insofern bitte ich doch darum, die von mir benutzten Begriffe nur als Formulierungshilfe zur Erläuterung des Sachverhalts zu verstehen. -- Jürgen 09:29, 17. Mai 2012 (CEST)[Beantworten]

Hallo Jürgen, ich verstehe deine Bedenken. Mein wesentlicher Einwand ist aber, dass du hier wieder neue Begriffe prägst/verwendetst. Auf die Schnelle fand ich die unter A/B genannten Begriffe:
(in Klammer: in der Praxis zusammen mit der Bezeichnung unter A benutzt; ?=hier nicht eindeutig)

A: 1=Primär(tabelle) 2=Master, 3=Parent 4=referenzierte Tabelle (Ein Access-Buch)
B: verknüpfte(?1), Child(3), abhängig, Detail(2), verwandt(?), 'Tabelle mit dem Fremdschlüssel'

Wenn du Denglisch ablehnst, könntest du ja 'Primär' und 'abhängig' verwenden - weil deine Bezeichnungen eben wirklich missverständlich sind - und die Wikipedia als globales Wissenswerk sollte hier nicht noch zur Verbreitung solcher Missverständnisse beitragen.
Auch scheint mir zum Thema noch ein Missverständnis vorzuliegen: Bei der RI, Löschweitergabe etc. sind keine Tabellen, sondern Datensätze die Wirkungsebene. Besonders bei rekursiven Beziehungen wird das deutlich. Aus diesem Unterschied resultiert wohl auch dein Hinweis auf 'gleichzeitig Master und Detail'; in einer bestimmten Beziehung (=/= Beziehungstyp!) ist immer klar, wer Master- und wer Detail-SATZ ist. Dass die Definition von RI auf Tabellenebene erfolgt, hat hiermit wenig zu tun, sondern kommt daher, dass alle Festlegungen (selbstverständlich) auf der Typ-Ebene definiert werden: Beziehungstyp, Entitytyp etc.
Auch meine Hinweise zur sprachlichen Uneindeutigkeit von zugeordnet bzw. der Verwandtschaft (Haupt- und Master) bitte ich nochmal zu überdenken. WP:VÖRBY, 17.5. 13:24h

Danke für diese Erläuterungen, auf dieser Grundlage kommen wir doch noch zur Übereinstimmung. (Bei den strittigen Bezeichnungen geht es doch immer um Tabellen, nicht um Datensätze, auch wenn die Auswirkungen die Datensätze betreffen.) Mit dem Begriff "Primärtabelle" kann ich mich auf jeden Fall anfreunden. Bei der "anderen" Tabelle könnte auf einen ausdrücklichen Begriff ganz verzichtet werden; dafür wird dann abwechselnd "verknüpft, abhängig, zugeordnet" verwendet.

Bist du damit einverstanden, oder hältst du weitere Änderungen für sinnvoll? Möchtest du das gleich selbst erledigen? (Hast du eigentlich einen SUL-Account?) -- Jürgen 15:59, 17. Mai 2012 (CEST)[Beantworten]

OK, mit 'Primärtabelle' und wahlweise umschreibenden Bezeichnungen für die abhängigen Datensätze (ohne neue Begriffe) kann ich gut leben.

Ja, es werden meist die TABELLEN so bezeichnet - weil bei der Konfiguration/Definition/Festlegung von BEZIEHUNGSTYPEN Entitäten (= hier Einzelsätze) keine Rolle spielen, sondern dies auf der TYPEBENE von Entitäten (= hier 'Tabellen') geschieht. Dabei werden nicht die Tabellen konfiguriert, sondern die Beziehungsgtypen - und die Tabellen treten dabei nur in der ROLLE primär vs. abhängig auf.

In WP habe ich einen Account, für Wikibooks gilt der aber wohl nicht. In Deinem 'Buch' möchte ich nicht eingreifen, habe aber vor, den WP-Artikel RI erheblich zu 'straffen'; siehe Disk dort.

Grüße von VÖRBY, 17.5.12 21:44h

Soll ICH die Änderungen vornehmen? WP:VÖRBY, 5.6.12 10:42h

Keine Bange, es steht bei mir auf der Agenda. Bis Ende dieser Woche habe ich noch dringende, wichtige Angelegenheiten zu erledigen. Ich werde aber nicht heulen, wenn du es übernehmen willst. -- Gruß Jürgen 11:32, 5. Jun. 2012 (CEST)[Beantworten]

Hallo Jürgen, ich habe den Change vorgenommen. Allerdings hattest du beide Begriffe ähnlich häufig verwendet, sodass ich auch beide geändert habe: 'Haupttabelle' auf Detailtabelle und 'zugeordnete' auf Primärtabelle. Dabei habe mit 'FIND' gearbeitet und hoffe, alle Textstellen gefunden zu haben). Bei den Definitionen habe ich die verschiedenen Bezeichnungen auch eingetragen. Den Warnhinweis habe ich rausgenommen; er ist jetzt nicht mehr nötig, weil die Bezeichnungen eindeutig sind. Den Inhalt des Artikels habe ich sonst unverändert gelassen. Ich denke, dein Artikel ist jetzt begrifflich konsistenter als vorher, er verwendet jetzt nur offizielle Begriffe und ich hoffe, du bist mit der Überarbeitung einverstanden. Grüße von WP:VÖRBY, 5.6.12 18:36h

Danke, Vörby. Ich habe mir jetzt endlich die Zeit nehmen können und danke für die Bearbeitung. Ich werde die Warnung allerdings wieder aufnehmen, denn jetzt steht da:

In einem Datensatz der Detailtabelle stehen keine Einzelheiten der betreffenden Spalte.

Wieso heißt sie "Detailtabelle", wenn sie gerade keine Einzelheiten enthält? Das ist doch genau der Widerspruch, der mich zu den seltsamen Formulierungen veranlasste. Ich werde versuchen, im einleitenden Abschnitt ganz auf diese Bezeichnungen zu verzichten und im dann folgenden Text auf deinen Sachverstand zurückzugreifen, und hoffe, dass ich dabei deine Formulierungen nicht kaputt mache. -- Jürgen 17:35, 16. Jun. 2012 (CEST)[Beantworten]

Erledigt. Ich habe folgende Änderungen vorgenommen:

Umformulierung des letzten Absatzes im Abschnitt "Beziehungen definieren"
"Definition" als Aufzählung
Warnung eingefügt und mit den folgenden Absätzen erläutert
Gänsefüßchen im Text weitgehend entfernt; da die Begriffe jetzt "offiziell" verwendet werden, kann auf die Gänsefüßchen verzichtet werden
Bei Übung 1 hat die (bisherige) Aussage 5 IMHO keinen Sinn mehr; ich habe sie gestrichen.

In der Hoffnung, dass du hier noch einen Blick drauf wirfst, wäre es nett zu wissen, ob diese Änderungen auch deinen Vorstellungen entsprechen. -- Jürgen 18:24, 16. Jun. 2012 (CEST)[Beantworten]

Hallo Jürgen, ich hatte die Umbenennungen nur 1:1 (ähnlich wie Suchen:Ersetzen) vorgenommen, sodass es durchaus sein kann, dass einige Texte/Beispiele ... keinen Sinn mehr ergeben. Mit dem übrigen Inhalt habe ich mich nicht befasst. Zu deinen Änderungen.

Was soll 'Keine Einzelheiten der betreffenden Spalte' aussagen? Welcher Spalte? Da meintest du wohl, 'keine Einzeldaten des referenzierten Primärdatensatzes'. Hier liegt m.E. auch ein wesentlicher Schwachpunkt deines Artikels: Mit den Schlüsseln werden DATENSÄTZE miteinander verbunden, keine TABELLEN und auch keine SPALTEN/ATTRIBUTE; Fremdschlüssel und Primärschlüssel sind lediglich die 'Vehikel', mit denen die Beziehung (zwischen Datensätzen!!!) hergestellt wird. Der letzte Satz bei 'Die Definition' (Eine Spalte in der Detail-Tabelle wird über den Fremdschlüssel verknüpft mit dem Primärschlüssel in der Primärtabelle) ist also grundlegend falsch. Ebenso im Beispiel 'Alter Table <Detailtabelle> ...': Eine Tabelle selbst sollte man nicht als Master- oder Detailtabelle bezeichnen, sondern diese Rolle kommt ihr nur im Rahmen eines bestimmten Beziehungstyps zu. Das Beispiel 'Foreignkey' passt aber.
Die Warnung halte ich für nicht mehr erforderlich: Wo Begriffe im entgegengesetzten Sinn verstanden werden könnten, ist mir nicht klar - weil jetzt 'Haupttabelle' oder 'zugeordnet' nicht mehr verwendet wird. Siehe auch die Aussagen zu Begriffen in WP:Referentielle Integrität.
Zum Stil deines 'Buches' hätte ich persönlich auch mehrere/viele Fragezeichen zu setzen. Beispiele:

(1) Da heißt es "Im letzten Abschnitt hieß es, dass in der ersten Tabelle ...". Ist das nun Inhalt oder eine Diskussion? Das ist schwer verständlich.

(2) Der erste Abschnittt fällt einfach 'mit der Tür ins Haus', ohne Einleitung etc.

(3) Weiterhin: Dein Artikel beschreibt eigentlich Fremschlüssel. Was wir diskutiert hatten (die Begriffe), sind aber Aspekte zu 'referentielle Integrität'. Das sind zwei unterschiedliche Themen.

Grüße von WP:VÖRBY, 18.6.12 16:21h, ergänzt: 20.6.12 18.20h

Ist es jetzt - mit zusätzlichen Formulierungen vor allem in den Einleitungen - besser?

Übrigens ist dieses Kapitel ursprünglich (lange vor meiner Zeit) aus dem RI-Artikel der WP hervorgegangen. Da die Zielsetzung des SQL-Buchs schon damals eine Einführung war und keine Einführung in die RDBMS-Theorie sein sollte, passte der Bezug auf die Fremdschlüssel (als praktische Maßnahme) besser.

Mein Stil lässt sich wohl nicht mehr ändern; dafür habe ich mich zu lange mit dem Buch beschäftigt. Es sei denn, es sollte in die Tonne getreten werden.

] -- Jürgen 11:36, 26. Jun. 2012 (CEST)[Beantworten]

Hallo Jürgen, ich habe mir deine letzten Korrekturen angesehen. Da du jetzt immer 'Einträge in ...' schreibst, ist der Bezug auf die Datensätze gegeben; die alte Aussage 'Tabellen stehen in Beziehung' wäre also damit eliminiert.
Bei den Beispielen habe ich nicht SO genau hingesehen. Aber die Aussage 'Ein UPDATE in der Primärtabelle ist immer möglich, ohne die Werte in der Detailtabelle zu beachten.' könnte kritisch sein - wenn dabei ein Update eines Alternativschlüssels erfolgt. Entweder ist das dann (bei Existenz abhängiger Daten) doch nicht möglich oder es ist 'Änderungsweitergabe' definiert; in beiden Fällen wäre eine Bemerkung hilfreich: 'Update wir abgelehnt' oder 'automatischer Update der Fremdschlüssel'. Oder ich hab das nicht richtig gelesen.
Zu den den Tabellenbezeichnungen in den Beispielen nochmal mein Hinweis: Eine Tabelle ist nicht explizit eine Primär- oder abhängige Tabelle, sondern nur im Zusammenhang mit genau einem Beziehungstyp. Das wird bei kaskadierenden RI-Regeln deutlich, da kann nämlich eine Tabelle in einer Beziehung der Master und in einer anderen das Child sein. Vielleicht kannst du das nochmal überprüfen.
Ich wünsche Dir weiterhin viel Erfolg! WP:VÖRBY 1.7.2012 18:36

Danke für die weitgehende Zustimmung.

Zu deiner Kritik wegen der UPDATE-Aussage: Dabei handelt es sich um eine Übung "welche Aussage ist wahr, welche falsch". Die Lösung dazu habe ich noch ergänzt: In dieser Ausschließlichkeit ist die Aussage falsch (das stand schon vorher da); jetzt steht noch ein Hinweis auf die ID dabei. Auf das Problem der ID (sollte eigentlich unveränderlich sein) weise ich mehrfach hin.

Dass die Tabellenbezeichnungen nur bei einer bestimmten Beziehung gelten, habe ich jetzt an den Anfang von "Begriffe" eingefügt. Bei den Kombinationen stand es schon vorher; aber jetzt steht es schon am Anfang und gilt deshalb auch für die Syntax-Übersichten. -- Jürgen 09:00, 2. Jul. 2012 (CEST)[Beantworten]

Dein 'Buch' ist ja jetzt i.Z. mit der Eingangsfrage ok. Und die 'monierten' Texte im Wesentlichen auch. Nochmal kurz: (RI-)Beziehungen kann man nicht nur über den Primärschlüssel (der sollte wirklich nicht änderbar sein), sondern auch über einen (eindeutigen) Alternativschlüssel führen; das meinte ich unter UPDATE.

Tabellenbezeichnung vs. Rollenbezeichnung: Ich denke, das ist auch ok so, Primärtabelle steht ja in <>.

Mach's gut! VÖRBY, 4.7.2012 19:00

Constraint[Bearbeiten]

@Robbit Hier die angekündigte Begründung, warum ich diese Änderung rückgängig gemacht habe:

Dein zweiter Satz ist eher kompliziert formuliert. Auch nach wiederholtem Durchlesen ist mir nicht klar, ob nach deiner Interpretation CONSTRAINT Auswirkungen auf die Rahmenbedingungen eines Fremdschlüssels hat und ggf. welche.
Im Kapitel DDL - Einzelheiten habe ich so formuliert: "Das Schlüsselwort CONSTRAINT selbst ist nur erforderlich bei Verwendung des Namens; ansonsten würden die Schlüsselwörter der einzelnen Bedingungen ausreichen." Das entspricht der Festlegung im SQL-Standard (Abschnitt 10.8 S. 503; Quelle SQL-2003 Documents Teil 2): "Specify the name of a constraint..."
Auch laut Tabellendefinition im SQL-Standard (Abschnitt 11.6 S. 545) besteht eine constraint definition aus:
[ <constraint name definition> ] <table constraint> [ <constraint characteristics> ]
Der Name ist also optional; die characteristics werden in Einführung in SQL nicht behandelt. Über weitere Beziehungen zwischen dem constraint-Namen und der Geltung einer Einschränkung kann ich nichts finden.
Das Kapitel "Fremdschlüssel" befasst sich gezielt damit. Wenn ein Fremdschlüssel definiert wird, soll er verwendet werden. Also wird seine Gültigkeit im Rahmen dieses Kapitels vorausgesetzt (bzw. angestrebt). Nach dem SQL-Standard (Abschnitt 11.8 S. 549 ff.) gibt es keine besonderen Bedingungen für eine referential constraint definition in Abhängigkeit davon, ob es eine constraint name definition gibt oder nicht. Es gibt einen einzigen Hinweis (Note 256 S. 551) auf die Bedeutung von constraint name definition, nämlich: "specifies when a constraint is effectively checked". Für eine Einführung wie in diesem Buch ist es unwesentlich, wann ein DBMS eine Einschränkung konkret prüft. In diesem Kapitel werden Fremdschlüssel definiert und benutzt; also ist es nur wesentlich, dass die Einschränkung geprüft wird.

Bitte lass mich wissen, wenn ich deine Überlegungen falsch verstanden habe oder wenn ich auch unter Berücksichtigung meiner o.g. Gedanken und Prüfungen etwas falsch dargestellt habe. (Nebenbei: Nach den Wikibooks-Regeln sollen bei fertigen Büchern wichtige Änderungen zuerst auf einer Diskussionsseite angesprochen werden.) -- Danke! Jürgen 12:45, 19. Feb. 2016 (CET)[Beantworten]