Kapitel 7 – SQL - Jurijs Skripte

Seite 1 von 4
www.jurijs-skripte.de.vu
DBMS - Kapitel 7
Kapitel 7 – SQL
TYPKOMPATIBILITÄT ZWISCHEN SPALTEN IST DANN GEGEBEN, WENN:
- Sie vom selben Basisdatentypen sind
- Sich beide Wertebereiche aus CHAR zusammensetzen
- Sich beide aus beliebigen nummerischen Basisdatentypen beziehen
- Definition „Prädikat“: Ein Ausdruck, der eine Aussage über Werte macht
True, False bzw. Aussage kann nicht ermittelt werden (Falls Nullmarke beteiligt ist)
NULLMARKE
- Definition: Nullmarke NULL ist spezieller Platzhalter, der zu jedem Wertebereich automatisch
hinzugefügt wird und immer dann genutzt werden kann, wenn die Spalte entweder nicht
zutreffend oder ihr Wert nicht bekannt ist. Nullmarken stellen individuelle Werte dar, was
insbesondere heißt, dass sie nicht ohne weiteres miteinander vergleichbar sind
- Dienen zur einheitlichen und konsistenten Behandlung von unbekannten Werten wird die
Nullmarke (NULL) verwendet, die es in allen Datentypen gibt.
- Bedeutungen: Wert vorhanden, aber noch nicht bekannt/festgelegt; Eigenschaft (vielleicht/ganz
sicher) nicht vorhanden.
Weil es unterschiedliche Bedeutungen gibt. Ein Vergleich zweier Nullmarken liefert: Nicht
bekannt/feststellbar
BENUTZERDEFINIERTE WERTEBEREICHE
- Basieren auf Basisdatentypen und schränken diese ein & können wie Basisdatentypen genutzt
werden
REGELN BEIM ANLEGEN VON TABELLEN:
1. Jede Zeile steht für ein unabhängiges Datenbankobjekt
2. Die Zeilen & Spalten müssen als ungeordnet betrachtet werden
3. Für alle Basistabellen muss es Schlüsselkandidaten geben (Schlüsselkandidateigenschaft)
4. Die Werte einer Spalte sind atomar und gehören genau einem Wertebereich an
5. Auf Datenbankebene sind Tabellennamen & auf Tabellenebene Spaltennamen eindeutig
EINTEILUNG VON INTEGRITÄTSBEDINGUNGEN (IB) (NACH EBENEN)
- Spaltenbezogene IB → Wertebereichseinschränkungen, Spaltenvorbelegungen,
Zustandsübergänge (z.B. NOT NULL-Spezifikation; PRIMARY KEY; UNIQUE; CHECK-Anweisung…)
Werden beim Anlegen der Spalte festgelegt oder auch am Tabellenende
Können auch in Form von Anfragen dargestellt werden
- Beziehungsintegrität (=Beziehung zwischen den Daten). Damit das DBMS die Korrektheit &
Vollständigkeit der Beziehungen überwachen kann, sollte das DBMS diese kennen.
Beziehungen werden mithilfe von Fremdschlüsseln & Beziehungstabellen modelliert
- Tabellenbezogene IB: Umfassen Eigenschaften von Spalten (=Schlüsselbeziehungen) & zeilen- und
spaltenübergreifende Integritätsbedingungen
Diese 3 IB heißen Tabellenzusicherungen/constraints und werden im Rahmen des CREATE
TABLE-Befehls spezifiziert
- Allgemeine IB/Schemazusicherungen: Beziehen sich auf Tabellen oder tabellenübergreifend auf
Ausschnitte des konzeptuellen Schemas
- Ablauf-/operationale IB: Kontroll- und Überwachungsmaßnahmen, die paralleles Arbeiten an
Datenbeständen ermöglichen
5 TYPEN VON INTEGRITÄTSBEDINGUNGEN NACH CODD
- Integritätsbedingungen auf Wertebereichen
- Integritätsbedingungen auf Spalten
- Integritätsbedingungen auf Zeilen
- Referenzielle Integrität
- Benutzerdefinierte bzw. allgemeine Integritätsbedingungen (Trigger)
Zusammenfasser: Jurij Weinblat, SoSe 2010. Alle Angaben ohne Gewähr. Quelle: Internetrecherche,
Vorlesungsunterlagen von Prof. Dr. Rainer Unland, Mitschriften (Universität Duisburg-Essen)
Seite 2 von 4
www.jurijs-skripte.de.vu
DBMS - Kapitel 7
STATISCHES VS. DYNAMISCHE IB
- Statisch: Die oben genannten. Diese Bedingungen müssen in einem Zustand erfüllt werden
- Dynamisch: Müssen beim Übergang zwischen Zuständen gelten. → IN SQL NICHT möglich…
PROBLEME MIT INTEGRITÄTSBEDINGUNGEN
- IB werden häufig an der falschen Stelle spezifiziert
- IB können sich widersprechen. Da dies ein NP-vollständiges Problem ist, kann das DBMS solche
Widersprüche nicht erkennen
- Definition „konsistenter Datenbankzustand aus DBMS-Sicht“: Wenn alle im konzeptuellen
Datenbankschema spezifizierten Bedingungen bzw. Zusicherungen erfüllt sind
- Definition „konsistenter Datenbankzustand aus logischer Sicht“: Die Auswertung aller konjunktiv
(AND-) verknüpften Zusicherungen als Ergebnis TRUE liefern muss
BEHANDLUNG VON INTEGRITÄTSVERLETZUNGEN
- Es gibt eine spezielle Statusvariable zur Abfrage von Integritätsverletzungen
- Verstößt eine Anweisung gegen eine Zusicherung/CONSTRAINT, wird sie abgelehnt
- Wird eine Integritätsverletzung erst nach Aktionsdurchführung festgestellt, wird die betroffene
Transaktion über ein ROLLBACK-Befehl komplett rückgängig gemacht
SCHLÜSSEL
- Schlüsselkandidaten werden mit UNIQUE gekennzeichnet
- Primärschlüssel werden mit PRIMARY KEY gekennzeichnet
Beide Eigenschaften können bei der Zeilendefinition oder am Tabellenende erfolgen
- Definition „Referenzielle Integrität“: Besteht zwischen zwei Tabellen T1 und T2 eine über
Fremdschlüssel aufgebaute Beziehung, stellt referenzielle Integrität sicher, dass in
Fremdschlüsseltabelle T2 keine Fremdschlüssel existieren können, die nicht in T1 als Wert des
entsprechenden Schlüsselkandidaten bzw. Primärschlüssels vorhanden sind.
- Bei zyklischen Fremdschlüsselbeziehungen muss zuerst eins der beiden CONSTRAINTS mithilfe von
DEFERRED abgeschaltet werden und am Ende per IMMEDIATE reaktiviert werden
ÄNDERUNGEN AN TABELLEN/SPALTEN
- Neue Spalten werden grundsätzlich am Tabellenende erstellt
- Spalteneigenschaften lassen sich nur sehr bedingt ändern
- Prinzipiell können im Nachhinein Schlüsselkandidaten & Fremdschlüssel ergänzen. Dabei müssen
die bereits vorhandenen Datensätze den damit verbundenen Auflagen genügen
LÖSCHEN
- Wird eine Haupttabelle gelöscht, auf die andere Tabellen über Fremdschlüssel verweisen, so
können über den CASCADE-Befehl die entsprechenden Zeilen in den Untertabellen auch
automatisch gelöscht werden
- Die RESTRICT-Option hingegen würde ein Löschen verhindern
- Zusicherungen können stets direkt gelöscht werden
BEMERKUNGEN
- NOT NULL bedeutet, das Einfüge- und Änderungsoperationen zurückgewiesen werden, die an die
entsprechenden Stellen NULL eintragen wollen → TransakNonsabbruch
- Tabellenbezogene CHECK-Klauseln: Können spalten- und tabellenübergreifend wirken, wobei
letztere besser auf Schemaebene zu implementieren sind.
MENGENOPERATIONEN
- UNION (ALL) → Vereinigung
- EXCEPT → Different
- INTERSECT → DurchschniQ
Zusammenfasser: Jurij Weinblat, SoSe 2010. Alle Angaben ohne Gewähr. Quelle: Internetrecherche,
Vorlesungsunterlagen von Prof. Dr. Rainer Unland, Mitschriften (Universität Duisburg-Essen)
Seite 3 von 4
www.jurijs-skripte.de.vu
DBMS - Kapitel 7
ABARBEITUNGSREIHENFOLGE UND SEMANTIK BASISKLAUSELN
1. FROM → Erstellen einer Ausgangstabelle
2. WHERE → Auswählen der gewünschten Zeilen
3. GROUP BY → Bilden von Untertabellen
4. HAVING → Auswählen von Untertabellen
5. SELECT → Anpassung der AQribute
6. ORDER BY → SorNerung des Ergebnisses
SICHTEN
- Definition: Eine virtuelle Tabelle, die durch ihren Namen, ihre Spalten und eine
Abbildungsvorschrift, die festlegt, wie eine Sicht aus Basistabellen und anderen Sichten zu bilden
ist, beschrieben ist
- Ist ähnlich wie eine vordefinierte Anfrage verstanden werden, die immer dann ausgeführt wird,
wenn eine SQL-Anfrage auf die Sicht Bezug nimmt
Sichtenarten:
- Spaltenverändernde Sicht: Entsteht aus Basistabellen durch Hinzufügung, Weglassung oder
Umbenennung von Spalten
- Mengenreduzierende Sicht: Entsteht aus Basistabellen durch weglassen von Zeilen
- Verbundsicht: Entsteht aus mehreren Basistabellen durch Verbunde
Eigenschaften:
- Sichten ermöglichen logische Datenunabhängigkeit, da Änderungen, die die Sicht nicht betreffen,
die Funktionsweise der Anwendung nicht beeinflussen
- Daten können der Anwendung so präsentiert werden, wie diese die Daten erwartet
- Ermöglicht Datensicherheit, da bestimmte Datengezielt ausgeblendet werden können
Ändern von Sichten
- Es existiert nicht immer eine eindeutige Abbildungsvorschrift, die Änderungen an Sichten an die
Basistabellen „weiterreichen“ kann
Wenn z.B. durch Projektion ausschließlich Nicht-Prime-Attribute verbleiben
Bei Duplikateliminierung
Vorschriften in SQL-92, die Änderungen an Sichten ermöglichen
- Die FROM-Klausel muss sich auf genau eine Tabelle bzw. änderbare Sicht beziehen
- GROUP BY & HAVING sind verboten
- Die Duplikateliminierung ist verboten
- Im WHERE-Teil darf es keine weiteren SQL-Blöcke geben
- Keine Aggregatfunktionen oder arithmetischen Ausdrücken im SELECT-Teil
AUTORISIERUNG UND ZUGRIFFSKONTROLLE
Prinzip des „Eigentums an Informationen“
Nur der Ersteller hat die vollen Rechte über seine Daten
Prinzip der „Weitergabe von Privilegien“
Der Eigentümer darf seine Privilegien weitergeben
AUDITING
- Um Datenbankzugriffe zu protokollieren werden diese in einer speziellen Datei festgehalten
Das Pflegen einer solchen Datei kostet Ressourcen!
STRATEGIEN FÜR DEN DATENZUGRIFF
- Optimistisch: Es ist alles erlaubt, was nicht verboten ist
- Pessimistisch: Es ist alles verboten, was nicht erlaubt ist
Von SQL genutzt (jedem Datenbankobjekt ist ein Besitzer zugeordnet)
DATENBANKPROZEDUREN & TRIGGER
- Existieren eigentlich zur Integritätssicherung, können aber auch anders genutzt werden
Zusammenfasser: Jurij Weinblat, SoSe 2010. Alle Angaben ohne Gewähr. Quelle: Internetrecherche,
Vorlesungsunterlagen von Prof. Dr. Rainer Unland, Mitschriften (Universität Duisburg-Essen)
Seite 4 von 4
www.jurijs-skripte.de.vu
DBMS - Kapitel 7
Datenbankprozeduren (Stored Procedures)
- Können eine in einer beliebiger Programmiersprache geschriebene Routine auszuführen
- Machen das DBMS turingvollständig
Trigger
- Eine spezielle Form der Datenbankprozedur
- Wird durch den Eintritt eines bestimmten Ereignisses ausgeführt (z.B. Datenmanipulation)
- Besteht aus: Name, Auslöser/Ereignis, Bedingung, Aktion
Probleme mit Triggern
- Widersprüche und Deadlocks
- Rekursion (insbesondere unendliche Rekursion)
- Abarbeitungsreihenfolge: In welcher Reihenfolge sollen Trigger ausgeführt werden, die auf das
gleiche Ereignis reagieren?
- Effizienz: Nach jedem Ereignis ist zu prüfen, ob ein Trigger ausgelöst werden muss
- Datensicherheit: Trigger dürfen Benutzern nicht Rechte bescheren, die ihnen nicht zustehen
ASSERTIONS / ZUSICHERUNGEN
- Sind auf Schemaebene definiert → Tabellenübergreifende Integritätsbedingungen
- SQL-spezifisch
- Müssen einen festen Namen haben, da es kein Vaterobjekt für sie gibt
Zusammenfasser: Jurij Weinblat, SoSe 2010. Alle Angaben ohne Gewähr. Quelle: Internetrecherche,
Vorlesungsunterlagen von Prof. Dr. Rainer Unland, Mitschriften (Universität Duisburg-Essen)