Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

SQL Grundkurs 1: Die Sprache erlernen

Constraint-Arten und Wirkung

Testen Sie unsere 2013 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Verschaffen Sie sich mit diesem Video einen Überblick über Constraints und wie sie sich im DB-Umfeld auswirken.

Transkript

Dieses Video gibt Ihnen einen grundlegenden Überblick über Constraints. Constraints, zu deutsch Einschränkungen, sind Regeln, die auf Datenbank-Ebene bzw. auf Tabellen-Ebene direkt erzwungen werden. Man spricht auch von Business Rules Geschäftsregeln die hier definiert werden können. Diese Constraints sind eigene Objekte, die erstellt werden. Sie haben auch einen eigenen Namen, aber sie sind fix an eine Tabelle gebunden. Diese Constraints prüfen die definierten Regeln für diese Tabelle und erzwingen sie. Wird eine Tabelle gelöscht, werden die mit ihr verbundenen Constraints automatisch mit gelöscht. Constraints prüfen bei DML-Anweisungen, also beim Einfügen, Ändern und Löschen von Daten, bevor diese Änderungen durchgeführt werden. D.h., es erfolgt kein Rollback in gewisser Form, D.h., die Änderungen werden nicht rückgängig gemacht, sondern sie werden von vornherein gar nicht zugelassen. Die Regeln, die von Constraints definiert werden, sind absolut. Sie können auf keine Art und Weise umgangen werden, solange ein Constraint aktiv ist. Selbst ein Administrator kann ein Constraint nicht umgehen. Ein Constraint kann nicht umgangen werden, es kann nur deaktiviert oder entfernt werden. Solange es aktiv ist, gilt es absolut und gegen die Regel, die durchgesetzt wird, kann nicht verstoßen werden. Dadurch sind Constraints in der Praxis ein sehr wertvolles und hilfreiches Mittel, um die Konsistenz von Daten aufrecht zu erhalten. Von welchen Constraint-Arten sprechen wir überhaupt innerhalb einer relationalen Datenbank? Das bekannteste Constraint ist das Primary Key Constraint. Fast jeder, der mit einer Datenbank zu tun hat, kennt den Begriff Primary Key, Primärschlüssel. Unique Key, oder eindeutiger Schlüssel, ist eine weitere Form. Foreign Key, oder Fremdschlüssel, das ist das, was man allgemein als Beziehung bezeichnet. Ein Check Constraint setzt einfache Regeln, die an Ausdrücke gebunden sind, durch. Abhängig vom System, werden teilweise auch die Einschränkungen auf NotNull und der Standardwert über ein Constraint implementiert. Die in der Praxis bedeutenden sind die ersten 4 in dieser Auflistung. Wollen wir uns die nun etwas genauer ansehen. Der Primärschlüssel erzwingt einerseits Eindeutigkeit. D.h., in der Spalte oder den Spalten die den Primärschlüssel definieren, kann kein Wert doppelt eingetragen werden. Wird ein Primärschlüssel definiert, ist er zudem automatisch als NotNull definiert, ohne dass man das separat angeben muss. Für einen Primärschlüssel wird automatisch ein Index erstellt, der einen schnelleren Zugriff auf die Werte innerhalb der Spalte oder der Spalten ermöglicht. In einer relationalen Datenbank sollte eigentlich jede Tabelle einen Primärschlüssel haben, auch wenn es technisch nicht immer für jede erforderlich ist. Im Idealfall erstellt man für Tabellen, für die man eigentlich keinen Primärschlüssel bräuchte aus logischer Sicht, physisch irgendeinen künstlichen Schlüssel, eine ID, die im Minimalfall automatisch vergeben wird. Ein Primärschlüssel kann nicht nur aus einer, sondern auch aus mehreren Spalten bestehen. Man spricht dann von einem zusammengesetzten Schlüssel. Zusammengesetzte Schlüssel verwendet man dann, wenn eine Spalte allein Eindeutigkeit nicht definieren kann. Ein Beispiel dazu: Bei uns in Österreich besteht die Sozialversicherungsnummer aus zwei Teilen, einer vierstelligen Nummer plus dem Geburtsdatum. Beide alleine für sich sind nicht eindeutig. Die Kombination dieser beiden aber ist eindeutig und damit geeignet als zusammengesetzter Primärschlüssel. Pro Tabelle kann nur ein Primary Key definiert werden, wie der Name auch schon sagt. D.h., es ist nicht möglich, mehrere Primärschlüssel festzulegen. Personen, die dieses Video ansehen und meiner Generation angehören, werden sicher mit dem Begriff etwas anfangen, wenn ich sage, für den Primary Key gilt das "heilende Prinzip" in diesem Zusammenhang. Ein Constraint, das dem Primary Key sehr ähnlich ist, ist der Unique Key. Auch hier wird Eindeutigkeit erzwungen. Ausnahmsweise ist hier "Null" erlaubt, wobei in der Praxis das nicht immer wirklich gut verwendbar ist, z.B. muss auch der Null-Wert beim Microsoft SQL Server eindeutig sein, sprich er kann nur einmal vergeben werden. Bei Oracle können Null-Werte beliebig viele vergeben werden, aber alle Werte, die nicht "Null" sind, müssen eindeutig sein. Das macht meiner Meinung nach auch Sinn, und hier ist es auch verwendbar. Aber das ist eben nicht bei allen Systemen so. Genauso wie beim Primary Key wird beim Unique Key ein Index automatisch erstellt. Auch für den Unique Key gilt, dass er aus ein oder mehreren Spalten bestehen kann. Der entscheidende Unterschied zwischen Primary und Unique Keys ist, dass es von einem Unique Key mehrere für eine Tabelle geben kann. Ich gebe Ihnen ein Beispiel für den Einsatz eines Unique Keys. Stellen Sie sich vor, Sie haben eine Datenbank im medizinischen Bereich. In dieser Datenbank werden Patientendaten gespeichert. Sie möchten die Sozialversicherungsnummer des Patienten aber nicht als Primary Key definieren, da Sie dafür lieber eine eigene Patientennummer, oder Patienten-ID verwenden möchten. Dennoch möchten Sie in der Patiententabelle erzwingen, dass die Sozialversicherungsnummer eindeutig ist. Deshalb können Sie zusätzlich zum Primary Key weitere Unique Keys verwenden, um auch in anderen, weiteren Spalten Eindeutigkeit zu erzwingen. So erzwingen Sie die Eindeutigkeit der Sozialversicherungsnummer in der Patiententabelle über einen Unique Key. Auch der Foreign Key, also die Definition einer Beziehung, ist über ein Constraint implementiert. Ein Foreign Key verweist auf den Primary Key einer anderen Tabelle und spannt so eine Beziehung auf. In einer Foreign Key Spalte dürfen nur jene Werte erhalten sein, die in der referenzierten Spalte der anderen Tabelle vorkommen, oder er kann "Null" sein. Das ist auch ein entscheidender Unterschied zu einem Primary Key, der nicht "Null" sein darf - Foreign Key ist von sich aus "Null". Wenn Sie also wollen, dass ein Fremdschlüssel immer ausgefüllt werden soll, dann muss das NotNull bei der Definition der Tabelle separat definiert werden. Z.B., Sie wollen, dass in der Rechnungstabelle immer eine Kundennummer für den Kunden, für den die Rechnung erstellt wird, erfasst werden muss. Dann reicht es nicht, einen Fremdschlüssel für die Kundennummer zu definieren, sondern es muss separat definiert werden, dass NotNull für diese Spalte gelten muss. Anderes Beispiel: Sie möchten Kunden akademische Grade zuweisen. Damit nur bestimmte, gültige akademische Grade verwendet werden können, definieren Sie einen Fremdschlüssel auf eine eigene Tabelle hin, in der alle möglichen akademischen Grade gespeichert sind. Das heißt aber noch lange nicht, dass in dieser Fremdschlüssel-Spalte in der Kundentabelle immer ein akademischer Grad eingetragen werden muss. Sie können ja nicht alle zwingen, auf einmal Akademiker zu sein. D.h., Null-Werte sind erlaubt, aber wenn Sie etwas eintragen, dann darf es nur etwas sein, das in der referenzierten Tabelle enthalten ist. Zusätzlich können Sie für einen Foreign Key kaskadierende Änderungen definieren. Man nennt es auch Änderungs- und Löschweitergabe. Dies bedeutet, dass Sie ausnahmsweise in einer Primärschlüssel-Spalte etwas ändern dürfen, auch wenn über einen Fremdschlüssel darauf referenziert wird. Zum Beispiel: Sie referenzieren in einer Rechnungstabelle auf eine Kundennummer. In dem Moment, wo einem Kunden eine Rechnung zugewiesen ist, kann die Kundennummer nicht mehr geändert werden. Ist die Änderungsweitergabe aktiv, können Sie die Kundennummern in der Kundentabelle sehr wohl ändern. In allen zugeordneten Rechnungen wird dann automatisch die Kundennummer mit geändert. Löschweitergabe würde z.B. bedeuten, Sie speichern die Interessen für Kunden in einer eigenen Tabelle und referenzieren mit der Kundennummer. Sobald einem Kunden ein Interesse zugeordnet ist, könnte dieser Kunde nicht mehr gelöscht werden. Ist aber die Löschweitergabe zwischen dem Kunden und seinen Interessen definiert, kann der Kunde sehr wohl gelöscht werden. Wenn er gelöscht wird, werden aber alle seine Interessens- zuordnungen automatisch mit gelöscht. Das nächste Constraint, das ich Ihnen erläutern möchte, ist das Check Constraint. Das Check Constraint wird verwendet um einfache Gültigkeitsregeln, Geschäftsregeln, zu implementieren. Was heißt in diesem Zusammenhang einfach? Einfach heißt, Sie müssen über einen SQL-Ausdruck definierbar sein. Das könnte z.B. bedeuten, dass die Mindestlänge der Eingabe 5 Zeichen beträgt. Das könnte bedeuten, dass in einem Datensatz der Beginn-Zeitpunkt vor einem End-Zeitpunkt in einer anderen Spalte liegen muss. D.h., Sie können nur auf Inhalte innerhalb desselben Datensatzes zugreifen. Sie können z.B. prüfen, ob für eine Raumreservierung die Beginn-Zeit vor der End-Zeit liegt. Sie können nicht prüfen, ob die Reservierung sich mit einer anderen überschneidet, denn dazu müssten Sie mit einem anderen Datensatz vergleichen, und das ist mittels Check Constraint nicht möglich. Genauso wenig können Sie auf die Inhalte anderer Tabellen zugreifen, D.h., für die Überprüfung der Regel müssen Sie mit dem auskommen, was innerhalb des Datensatzes zur Verfügung steht, den Sie gerade prüfen. Sie können über diesen Tellerrand nicht hinausblicken. Für komplexere Geschäftsregeln müssen sogenannte Trigger programmiert werden, das ist aber nicht mehr Standard-SQL, sondern damit begeben wir uns bereits in die datenbankseitige Programmierung. Sie haben in diesem Video einen Überblick über die 4 wichtigsten Constraints, Einschränkungen, erhalten. Primary Key um Eindeutigkeit für einen Datensatz zu erzwingen, Foreign Key um Beziehungen zwischen Tabellen zu erzeugen, Unique Key - um eindeutige Spalten zusätzlich zum Primärschlüssel zu definieren und Check Constraint, um einfache Gültigkeitsregeln auf Tabellen-Ebene zu erzwingen.

SQL Grundkurs 1: Die Sprache erlernen

Arbeiten Sie sich in die Grundlagen der Datenbanksprache SQL am Beispiel von Microsoft SQL Server, Oracle und MySQL ein und lassen Sie sich die praktische Nutzung erklären.

14 Std. 40 min (112 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!