Title: DDL

Feedback shared by this category's questions, if right: Die Antwort ist richtig.
Feedback shared by this category's questions, if partly right: Die Antwort ist teilweise richtig.
Feedback shared by this category's questions, if wrong: Die Antwort ist falsch.

Q: Was versteht man unter der Abkürzung DDL?

D [...]
D [...]
L [...]
A: ata / Data; efinition / Definition; anguage / Language
Feedback: DDL ist die Datendefinitionssprache, um Artefakte wie z.B. Tabellen, Indexe, Sequenzen, Trigger, Constraints im DBMS anlegen zu können und umfasst im Wesentlichen CREATE, ALTER, DROP.

Q: Mit welchem Befehl löscht man einen Constraint?
- DROP CONSTRAINT
- DELETE CONSTRAINT
- ALTER TABLE xyz DROP CONSTRAINT
- ALTER TABLE xyz DELETE CONSTRAINT
- Keine von allen
A: ALTER TABLE xyz DROP CONSTRAINT

Q: Die Programmierung von SQL-Befehlen muss case-sensitive erfolgen.
- Wahr
- Falsch
A: Falsch
Feedback: Der SQL-Übersetzer arbeitet nicht case-sensitiv, so dass bei der Programmierung von SQL-Befehlen die Groß-/Kleinschreibung von reservierten Wörtern völlig irrelevant ist. Lediglich bei Vergleichen z.B. in der WHERE-Klausel muss jedoch sehr wohl auf die passende Groß-/Kleinschreibung geachtet werden, da hier case-sensitiv die Inhalte von Datenspalten verglichen werden.

Q: Um in SQL etwas auf "Ungleichheit" zu überprüfen, nutzt man...
- =!
- <>
- !=
- UNLIKE
- UNEQUAL
A: <>; !=
Feedback: Die Vergleichsoperatoren für Ungleicheit sind: <> oder !=

Q: Mit welcher Funktion können Sie eine Zeichenkette in ein Datum konvertieren?
- KONVERT_DATE ('15.06.2004', 'DD.MM.RRRR')
- TRANSFORM_DATE ('15.06.2004', 'DD.MM.RRRR')
- TO_DATE ('15.06.2004', 'DD.MM.RRRR')
- MAKE_DATE ('15.06.2004', 'DD.MM.RRRR')
A: TO_DATE ('15.06.2004', 'DD.MM.RRRR')
Feedback: Richtig ist der Befehl: TO_DATE ('15.06.2004', 'DD.MM.RRRR') Die Formatmaske gibt an, wie die Zeichenkette zu interpretieren ist. DD für den Tag, MM für den Monat, RRRR für ein 4-stelliges Jahr. Trennzeichen ist hier der Punkt ".". Es können aber auch beliebige andere Trennzeichen verwendet werden. Für andere Formatierungen gibt auch noch weitere Formatmasken.

Q: Mit dem Befehl "ALTER TABLE ..." kann man
- eine Spalte hinzufügen
- eine Spalte umbenennen
- eine Spalte vergrößern
- eine Spalte löschen
- eine Tabelle umbenennen
- eine Tabelle löschen
- eine Tabelle erzeugen
A: eine Spalte hinzufügen; eine Spalte umbenennen; eine Spalte vergrößern; eine Spalte löschen
Feedback: Um eine Tabelle zu erzeugen, nutzt man den Befehl CREATE. Um eine Tabelle umzubenennen, nutzt man den Befehl RENAME. Um eine Tabelle zu löschen, nutzt man den Befehl DROP TABLE. Mit einem ALTER TABLE hingegen kann eine Spalte hinzugefügt, umbenannt, vergrößert oder auch gelöscht werden (und vieles mehr).

Q: Welche SQL-Anweisungen mit CONSTRAINTS sind syntaktisch korrekt?

CREATE TABLE patienten (
  patienten_id NUMBER(12) PRIMARY KEY,
  nachname VARCHAR2(50) NOT NULL,
  vorname VARCHAR2(20) NOT NULL,
  knz VARCHAR2(1) XXX

);

Wählen Sie aus, was für XXX eingesetzt werden kann, damit die Anweisung syntaktisch korrekt ist.
- CHECK (knz IN ('J','N'))
- CHECK (knz = ('J','N'))
- CHECK (knz = ALL ('J','N'))
- IN ('J','N')
- Alle Antworten sind falsch
A: CHECK (knz IN ('J','N')); CHECK (knz = ALL ('J','N'))
Feedback: RICHTIG sind: - CHECK (knz IN ('J','N')) - CHECK (knz = ALL ('J','N')) Beide CHECK-Bedingungen sind syntaktisch richtig, verfügen aber eine unterschiedliche Semantik. - Beim IN wird geprüft, ob der Wert der Spalte knz 'J' oder 'N' ist. - Beim =ALL wird geprüft, ob der Wert der Spalte knz die beiden Werte 'J' und 'N' hat. Diese Bedingung ist nicht erfüllbar, denn wie kann eine Spalte gleichzeitig zwei verschiedene Werte enthalten. Semantisch äquivalent wäre die Formulierung mit =ANY. FALSCH ist: Wenn ein Vergleichsoperand eine Menge kosntanter Werte ist, da hilft ein einfaches "=" nicht weiter, nur ein IN oder ein "=" mit ANY- oder ALL-Option. Dieses "IN ('J','N')" reicht syntaktisch auch nicht aus. Ein CHECK-Constraint startet mit "CHECK (spaltenname ...".

Q: In welchen Punkten unterscheidet sich ein PRIMARY KEY-Constraint von einem UNIQUE-Constraint?
- Primärschlüssel muss immer NOT NULL sein
- Ein UNIQUE-Schlüssel muss immer NOT NULL sein
- Primärschlüssel sind automatisch indiziert, UNIQUE-Schlüssel nicht.
- Es ist nur ein Primärschlüssel pro Tabelle zulässig, aber viele UNIQUE-Schlüssel.
- Ein Primärschlüssel darf nicht zusammengesetzt sein aus mehreren Spalten.
- Ein UNIQUE-Schlüssel darf nicht zusammengesetzt sein aus mehreren Spalten.
A: Primärschlüssel muss immer NOT NULL sein; Es ist nur ein Primärschlüssel pro Tabelle zulässig, aber viele UNIQUE-Schlüssel.
Feedback: Die Constraints UNIQUE und PRIMARY KEY unterscheiden sich in den beiden Punkten: - Es gibt pro Tabelle nur einen PRIMARY KEY aber beliebig viele UNIQUE-Schlüssel. - Die Spalten eines PRIMARY KEY sind implizit auch Pflichteingabespalten, während die Spalten des UNIQUE-Schlüssels auch leer sein dürfen.

Q: Welche SQL-Befehle lösen eine IMMEDIATE-Integritätsprüfung aus?
- ROLLBACK
- DELETE
- SELECT
- INSERT
- CHECK
- UPDATE
- COMMIT
- SAVE
- DROP
- CREATE
- ALTER
A: DELETE; INSERT; UPDATE
Feedback: Ziel der Integritätsprüfung sind ja semantisch korrekte Daten, d.h. Daten, die allen definierten Constraints genügen. Sind Constraints definiert und aktiviert, dann sind in der Datenbasis nur solche Daten persistent gespeichert, die die Constraints erfüllen, so dass man mit 100%-iger Sicherheit sagen kann, alle Daten sind korrekt. Problematische Aktionen in diesem Zusammenhang sind dann alle Datenmanipulationen, also INSERT, UPDATE, DELETE. Anfragen (SELECTs) sind in diesem Zusammenhang unkritische Aktionen, die keine Prüfung erfordern - es soll ja nichts gespeichert werden, nur angezeigt. Die drei DML-Befehle INSERT, UPDATE, DELETE lösen also IMMEDIATE-Integritätsprüfung aus. COMMIT beendet eine Transaktion und löst damit eine DEFERRED-Integritätsprüfung aus. ROLLBACK beendet zwar auch eine Transaktion, jedoch indem sie rückgängig gemacht wird. Eine Integritätsprüfung ist daher unnötig und wird nicht ausgeführt. DDL-Anweisungen (CREATE, ALTER, DROP) beinhalten ein implizites COMMIT, was dafür sorgt, dass jede DDL-Anweisung unmittelbar in die DICTIONARY-Tabellen eingetragen wird. Dieses implizite COMMIT hat zur Folge, dass DDL-Anweisungen immer auch eine Transaktion beenden und eine DEFERRED-Integritätsprüfung auslösen. SAVE, CHECK sind keine SQL-Befehle. Es gibt wohl das CHECK-Constraint, aber eine Prüfung wird damit nicht ausgelöst.

Q: Wann ist ein Constraint erfüllt in SQL?
- Wenn es zu FALSE ausgewertet wird.
- Wenn es zu TRUE ausgewertet wird.
- Wenn es zu UNKNOWN ausgewertet wird.
A: Wenn es zu TRUE ausgewertet wird.; Wenn es zu UNKNOWN ausgewertet wird.
Feedback: SQL basiert auf einer drei-wertigen Logik mit den drei Wahrheitwerten FALSE, TRUE und UNKNOWN. Ein Constraint in SQL ist erfüllt, wenn es zu TRUE oder zu UNKNOWN ausgewertet wird. Grund ist: Die Constraints werden bereits beim CREATE TABLE das erste Mal geprüft und damit über der leeren Tabelle. Wenn jetzt UNKNOWN wie FALSE behandelt würde, könnte der CREATE TABLE gar nicht ausgeführt werden. Der andere Punkt sind die (potentiell) leeren Spalten, für die die Constraints trotzdem erfüllt sein sollen. Z.B. kann bei einem Detail-Datensatz eine Fremdschlüsselspalte leer sein oder UNIQUE-Spalten dürfen leer sein, ohne dass das Constraint gleich verletzt ist. Achtung: Bei SELECT-Anfragen ist es anders, da wird UNKNOWN wie FALSE behandelt und ein Datensatz kommt nur in die Ergebnismenge, wenn die WHERE-Bedingung zu TRUE ausgewertet wurde.

Q: CONSTRAINTS sind eigene Datenbankobjekte, die unabhängig von einer Tabelle existieren.
- Wahr
- Falsch
A: Falsch
Feedback: Constraints werden nicht mit einem eigenen CREATE-Table-Befehl, sondern über ein ALTER-Table oder CREATE-Table angelegt.

Q: Betrachten Sie folgenden CREATE TABLE-Befehl:

CREATE TABLE Hierarchie (
  Angestellter VARCHAR2(20) NOT NULL,
  Vorgesetzter VARCHAR2(20) NOT NULL,
  PRIMARY KEY (Angestellter),
  FOREIGN KEY (Vorgesetzter) REFERENCES Hierarchie ON DELETE CASCADE);

Welche Aussage/n ist/sind korrekt?
- Dieser SQL-Befehl ist syntaktisch nicht korrekt.
- Dieser SQL-Befehl ist syntaktisch korrekt.
- Dieser SQL-Befehl bildet die Angestellten-Vorgesetzten-Beziehung semantisch nicht korrekt ab.
- Dieser SQL-Befehl bildet die Angestellten-Vorgesetzten-Beziehung semantisch korrekt ab.
A: Dieser SQL-Befehl ist syntaktisch korrekt.; Dieser SQL-Befehl bildet die Angestellten-Vorgesetzten-Beziehung semantisch korrekt ab.
Feedback: Ja, die CREATE-Anweisung ist syntaktisch korrekt. Ja, die Angestellten-Vorgesetzten-Beziehung wird hier semantisch korrekt abgebildet, weil der Fremdschlüssel der Vorgesetzten-Spalte auf den Primärschlüssel des Angestellten zeigt, der sein Vorgesetzter ist. z.B. Emil hat den Vorgesetzten Hugo: Angestellter Vorgesetzter ('Hugo','Anton'), ('Emil','Hugo'), Der 1. Datensatz ist der Mitarbeiter-Datensatz von Hugo und der 2. der von Emil. Der Fremdschlüssel des Emil-Datensatzes verweist auf den Mitarbeiter Hugo, der sein Vorgesetzter ist.

Q: Betrachten Sie die beiden folgenden CREATE TABLE-Befehle:

CREATE TABLE Zeitschrift (
  Zeitschrift_id INTEGER NOT NULL,
  Namen VARCHAR2(20) NULL,
  PRIMARY KEY (Zeitschrift_id)
);

CREATE TABLE Aufsatz (
  Aufsatz_id INTEGER NOT NULL,
  Titel VARCHAR2(20) NULL,
  Zeitschrift_id INTEGER NOT NULL,
  PRIMARY KEY (Aufsatz_id),
  FOREIGN KEY (Zeitschrift_id) REFERENCES Zeitschrift
);

Welche der beiden Tabellen kann zuerst gelöscht werden?
- Zeitschrift
- Aufsatz
A: Aufsatz
Feedback: Eine Tabelle mit einem Primary-Key (hier Zeitschrift mit Zeitschrift_id) , der als Foreign-Key in einer anderen Tabelle vorkommt, kann nicht gelöscht werden, solange die Verweistabelle noch existiert.

Q: Welche Constraints sind IMMEDIATE definierbar?
- PRIMARY KEY
- UNIQUE
- FOREIGN KEY
- NULL
- CHECK
A: PRIMARY KEY; UNIQUE; FOREIGN KEY; NULL; CHECK
Feedback: Alle fünf SQL-Constraints NULL, CHECK, FOREIGN KEY, PRIMARY KEY, UNIQUE sind unabhängig davon, ob sie Spalten- oder Tabellen-Constraint sind, als IMMEDIATE definierbar. Der Prüfungszeitpunkt "IMMEDIATE" (unmittelbar) bezeichnet die Prüfung unmittelbar, wenn die Datenmanipulation (INSERT, UPDATE, DELETE) eingegeben wird. Aus dem Syntax-Diagramm wird dies ersichtlich, weil für jeden Spalten-/Tabellenbedingungsausdruck die gelten und hinter denen verbergen sich u.a. die Optionen DEFERRED und IMMEDIATE.

Q: Betrachten Sie folgenden CREATE TABLE-Befehl:

CREATE TABLE Person (
  ID NUMBER PRIMARY KEY,
  NACHNAME VARCHAR2(20) PRIMARY KEY,
  TYP CHAR(1)
);

Welche Aussage/n ist/sind korrekt?
- Der CREATE-TABLE -Befehl wirft einen Fehler, weil eine Tabelle nur eine PRIMARY KEY haben kann.
- Der CREATE-TABLE -Befehl wirft keinen Fehler.
- Der CREATE-TABLE -Befehl wirft keinen Fehler, aber es wird nur der erste PRIMARY KEY erzeugt.
A: Der CREATE-TABLE -Befehl wirft einen Fehler, weil eine Tabelle nur eine PRIMARY KEY haben kann.
Feedback: Eine Tabelle kann nur einen PRIMRY KEY haben, der die physische Struktur der Tabelle festlegt.

Q: Welche der folgenden CHECK-Constraints sind korrekt?
- geschlecht VARCHAR2(1) CHECK (IN ('W', 'M'))
- geschlecht VARCHAR2(1) CHECK (geschlecht IN ('W' OR 'M'))
- geschlecht VARCHAR2(1) CHECK (geschlecht IN ('W', 'M'))
- Alle Antworten sind falsch
A: geschlecht VARCHAR2(1) CHECK (geschlecht IN ('W', 'M'))
Feedback: RICHTIG ist: geschlecht VARCHAR2(1) CHECK (geschlecht IN ('W', 'M')) Da die CHECK-Bedingung für Tabellen- und Spalten-Constraints die gleiche Syntax aufweist, startet die Bedingung nach der öffenenden Klammer immer mit einem Spaltennamen. Der IN-Operator erwartet als zweiten Operanden eine Komma getrennte Liste konstanter Werte (unterschiedliche Werte gleichen Datentyps ohne Wiederholungen) oder eine SELECT-Anfrage, daher sind die OR-Operatoren dort völlig fehl am Platz.

Q: Wie erzeugt man mit einem ALTER TABLE-Befehl einen TABLE-CONSTRAINT?
- Mit dem Zusatz MODIFY
- Mit dem Zusatz ADD
- Mit dem Zusatz INSERT
- Mit dem Zusatz PUSH
- Keine von allen
A: Mit dem Zusatz ADD
Feedback: Mit der Option ADD beim ALTER TABLE können Constraint einer bereits bestehenden Tabelle hinzugefügt werden. Die Option MODIFY gibt es nicht für CONSTRAINTS alleine, sondern nur für Spaltendefinitionen. Über diese kann ein CONSTRAINT indirekt geändert werden. Constraints "gehören" immer zu einem oder mehreren Attributen, so dass es für sie keine eigenen CREATE, ALTER, DROP-Befehle gibt. Constraints kännen temporär ausgesetzt werden, wenn die Einhaltung des Constraints anderweitig - Export aus externem System, Anwendung - sichergestellt werden kann.

Q: Jeder Column-Constraint (Spaltenbedingung) kann auch als Table-Constraint (Tabellenbedingung) geschrieben werden.
- Wahr
- Falsch
A: Wahr
Feedback: Ein Column-Constraint unterscheidet sich von einem Table-Constraint durch die Stellung im SQL-Befehl: Der Columns-Constraint wird durch ein Komma von der Spaltendefinition abgetrennt und kann sich nur auf einen Spalte beziehen.

Q: Was versteht man unter "Dangling-Datensätzen" in SQL?
- Datensätze, die nicht gesichert werden.
- Datensätze, denen Attributwerte fehlen.
- Geänderte Datensätze, deren Transaktion noch nicht abgeschlossen ist.
- Datensätze, deren Attributwerte aus der Join-Bedingung nur in einer Relation vorhanden sind.
A: Datensätze, deren Attributwerte aus der Join-Bedingung nur in einer Relation vorhanden sind.
Feedback: Werden Fremdschlüssel verwendet, so kann es zur sog. "Dangling Tuples"-Problematik kommen, bei der es darum geht, dass Datensätze, die noch von anderen Datensätze referenziert werden, gelöscht oder deren Schlüsselwert geändert wird und das anschließend Datensätze existieren, für deren Fremdschlüsselwerte es dann keinen passenden Datensatz in der ersten Tabelle mehr gibt. Analoge Probleme können bei Join-Operationen (Theta, Equi, Natural) auftreten. In die Ergebnismenge werden nur die Datensätze aufgenommen, die die Verknüpfungsbedingung erfüllen. Alle anderen fallen heraus, das sind die sog. "dangling tuples". Will man diese auch anzeigen lassen, muss man mit LEFT/RIGHT/FULL OUTER JOINs arbeiten.

Q: Welche CHECK-Bedingungen sind syntaktisch korrekt?

CREATE TABLE patienten (
  patienten_id NUMBER(12) PRIMARY KEY,
  nachname VARCHAR2(50) NOT NULL,
  vorname VARCHAR2(20) NOT NULL,
  knz VARCHAR2(1) CHECK ([...])
);
A: knz IN ('J','N') and knz = ALL ('J','N')
Gap 1 offers: knz = ('J','N'); knz IN ('J','N'); knz = ALL ('J','N'); ~

Q: Um in SQL etwas auf "Ungleichheit" zu überprüfen, nutzt man...
- =!
- <>
- !=
- UNLIKE
- UNEQUlAL
A: <>; !=
Feedback: Die Vergleichsoperatoren für Ungleicheit sind: <> oder !=

Q: Welche SQL-Anweisungen mit CONSTRAINTS sind syntaktisch korrekt?

CREATE TABLE patienten (
  patienten_id NUMBER(12) PRIMARY KEY,
  nachname VARCHAR2(50) NOT NULL,
  vorname VARCHAR2(20) NOT NULL,
  knz VARCHAR2(1) XXX

);

Wählen Sie aus, was für XXX eingesetzt werden kann, damit die Anweisung korrekt ist.
- CHECK (knz IN ('J','N'))
- CHECK (knz = ('J','N'))
- CHECK (knz = ALL ('J','N'))
- IN ('J','N')
- Alle Antworten sind falsch
A: CHECK (knz IN ('J','N')); CHECK (knz = ALL ('J','N'))
Feedback: RICHTIG sind: - CHECK (knz IN ('J','N')) - CHECK (knz = ALL ('J','N')) Beide CHECK-Bedingungen sind syntaktisch richtig, verfügen aber eine unterschiedliche Semantik. - Beim IN wird geprüft, ob der Wert der Spalte knz 'J' oder 'N' ist. - Beim =ALL wird geprüft, ob der Wert der Spalte knz die beiden Werte 'J' und 'N' hat. Diese Bedingung ist nicht erfüllbar, denn wie kann eine Spalte gleichzeitig zwei verschiedene Werte enthalten. Semantisch äquivalent wäre die Formulierung mit =ANY. FALSCH ist: Wenn ein Vergleichsoperand eine Menge kosntanter Werte ist, da hilft ein einfaches "=" nicht weiter, nur ein IN oder ein "=" mit ANY- oder ALL-Option. Dieses "IN ('J','N')" reicht syntaktisch auch nicht aus. Ein CHECK-Constraint startet mit "CHECK (spaltenname ...".

Q: Wann ist ein Constraint erfüllt in SQL?
- Wenn es zu FALSE ausgewertet wird.
- Wenn es zu TRUE ausgewertet wird.
- Wenn es zu UNKNOWN ausgewertet wird.
A: Wenn es zu TRUE ausgewertet wird.; Wenn es zu UNKNOWN ausgewertet wird.
Feedback: Achtung: SQL basiert auf einer drei-wertigen Logik! D.h. es gibt die drei Wahrheitwerte: TRUE, FALSE, UNKNOWN. Ein Constraint in SQL ist erfüllt, wenn es zu TRUE oder zu UNKNOWN ausgewertet wird. Grund ist: Die Constraints werden bereits beim CREATE TABLE das erste Mal geprüft und damit über der leeren Tabelle. Wenn jetzt UNKNOWN wie FALSE behandelt würde, könnte der CREATE TABLE gar nicht ausgeführt werden. Der andere Punkt sind die (potentiell) leeren Spalten für die die Constraints trotzdem erfüllt sein sollen. Z.B. kann bei einem Detail-Datensatz eine Fremdschlüsselspalte leer sein oder UNIQUE-Spalten dürfen leer sein, ohne dass das Constraint gleich verletzt ist. ... Achtung: Bei SELECT-Anfragen ist es anders, da wird UNKNOWN wie FALSE behandelt und ein Datensatz kommt nur in die Ergebnismenge, wenn die WHERE-Bedingung zu TRUE ausgewertet wurde. Bei UNKNOWN oder FALSE wird der Datensatz "fallen gelassen".

Q: Wie erzeugt man mit einem ALTER TABLE-Befehl einen TABLE-CONSTRAINT?
- Mit dem Zusatz MODIFY
- Mit dem Zusatz ADD
- Mit dem Zusatz INSERT
- Mit dem Zusatz PUSH
- Keine von allen
A: Mit dem Zusatz ADD
Feedback: Mit der Option ADD beim ALTER TABLE können Constraint einer bereits bestehenden Tabelle hinzugefügt werden. Die Option MODIFY gibt es nicht für CONSTRAINTS selber, sondern nur für Spaltendefinitionen, die aber einen CONSTRAINT haben können. Constraints sind keine eigenständigen DB-Objekte, so dass es für sie keine eigenen CREATE, ALTER, DROP-Befehle gibt. Sie können nur durch entsprechende CREATE TABLE, ALTER TABLE, DROP TABLE-Befehle erzeugt, manipuliert oder gelöscht werden.

Q: Was versteht man unter der Abkürzung DQL?

D [...]
D [...]
L [...]
A: ata / Data; efinition / Definition; anguage / Language
Feedback: DDL ist die Datendefinitionssprache, um "Objekte" wie z.B. Tabellen, Indexe, Sequenzen, Trigger, Constraints im DBS anlegen zu können und umfasst im Wesentlichen CREATE, ALTER, DROP.

Q: Welche Abhängigkeiten werden mit dem Befehl "ALTER TABLE ..." gelöscht?
- Indizes, die auf der Tabelle definiert sind
- Constraints, die auf der Tabelle definiert sind
- Die Daten der Tabelle
- Trigger, die auf der Tabelle definiert sind.
- Views, die auf der Tabelle definiert sind
- eine Tabelle erzeugen
A: Indizes, die auf der Tabelle definiert sind; Constraints, die auf der Tabelle definiert sind; Die Daten der Tabelle; Trigger, die auf der Tabelle definiert sind.
Feedback: Bis auf die Views werden alle abhängigen Objekte gelöscht. Die Views bleiben als Definition erhalten, sind aber erst wieder benutzbar, wenn die Tabelle neu angelegt wird. Unter Oracle wird der Status in user_objects auf 'invalid' gesetzt und die View muss neu übersetzt werden.

Q: Was versteht man unter "Dangling-Datensätzen" in SQL?
- Datensätze, die nicht gesichert werden.
- Datensätze, denen Attributwerte fehlen.
- Geänderte Datensätze, deren Transaktion noch nicht abgeschlossen ist.
- Datensätze, denen bei Join-Operationen bzw. bei Fremdschlüsselbeziehungen die entsprechenden Datensätze in der anderen Tabelle fehlen, mit denen sie verknüpft werden können.
A: Datensätze, denen bei Join-Operationen bzw. bei Fremdschlüsselbeziehungen die entsprechenden Datensätze in der anderen Tabelle fehlen, mit denen sie verknüpft werden können.
Feedback: Werden Fremdschlüssel verwendet, so kann es zur sog. "Dangling Tuples"-Problematik kommen, bei der es darum geht, dass Master-Datensätze, die noch von Detail-Datensätze referenziert werden, gelöscht oder deren Schlüsselwert geändert wird und das anschließend Detail-Datensätze existieren, für deren Fremdschlüsselwerte es dann keinen passenden Datensatz in der Master-Tabelle mehr gibt. Das Einfügen von Master-Datensätzen ist immer unproblematisch, da eine Fremdschlüsselbedingung es zuläßt, dass es Master-Datensätze gibt, für die es keine Detail-Datensätze gibt. Analoge Probleme können bei Join-Operationen (Theta, Equi, Natural) auftreten. In die Ergebnismenge werden nur die Datensätze aufgenommen, die die Verknüpfungsbedingung erfüllen. Alle anderen fallen heraus, das sind die sog. "dangling tuples". Will man diese auch anzeigen lassen, muss man mit LEFT/RIGHT/FULL OUTER JOINs arbeiten.

Q: Welche Abhängigkeiten werden mit dem Befehl "ALTER TABLE ..." gelöscht?
- Indizes, die auf der Tabelle definiert sind
- Constraints, die auf der Tabelle definiert sind
- Die Daten der Tabelle
- Trigger, die auf der Tabelle definiert sind.
- Views, die auf der Tabelle definiert sind
A: Indizes, die auf der Tabelle definiert sind; Constraints, die auf der Tabelle definiert sind; Die Daten der Tabelle; Trigger, die auf der Tabelle definiert sind.
Feedback: Bis auf die Views werden alle abhängigen Objekte gelöscht. Die Views bleiben als Definition erhalten, sind aber erst wieder benutzbar, wenn die Tabelle neu angelegt wird. Unter Oracle wird der Status in user_objects auf 'invalid' gesetzt und die View muss neu übersetzt werden.

Q: Was versteht man unter der Abkürzung DDL?

D [...]
D [...]
L [...]
A: ata / Data; efinition / Definition; anguage / Language
Feedback: Die Data Definition Language (DDL) von SQL legt Artefakte wie z.B. Tabellen, Indexe, Sequenzen, Trigger, Constraints in der Datenbank und umfasst im Wesentlichen CREATE, ALTER und DROP.

Q: Mit welchem Befehl löscht man einen Constraint?
- DROP CONSTRAINT constraintname;
- DELETE CONSTRAINT constraintname;
- ALTER TABLE tabellenname DROP CONSTRAINT constraintname;
- ALTER TABLE tabellenname DELETE CONSTRAINT constraintname;
- Keine von allen
A: ALTER TABLE tabellenname DROP CONSTRAINT constraintname;

Q: Um in SQL Werte auf "Ungleichheit" zu überprüfen, nutzt man...
- =!
- <>
- !=
- UNLIKE
- UNEQUAL
A: <>; !=
Feedback: Die Vergleichsoperatoren für Ungleichheit sind: <> oder !=

Q: Mit welcher Funktion können Sie eine Zeichenkette in ein Datum konvertieren?
- KONVERT_DATE ('15.06.2021', 'DD.MM.RRRR')
- TRANSFORM_DATE ('15.06.2021', 'DD.MM.RRRR')
- TO_DATE ('15.06.2021', 'DD.MM.RRRR')
- MAKE_DATE ('15.06.2021', 'DD.MM.RRRR')
A: TO_DATE ('15.06.2021', 'DD.MM.RRRR')
Feedback: Richtig ist der Befehl: TO_DATE ('15.06.2021', 'DD.MM.RRRR') Die Formatmaske gibt an, wie die Zeichenkette zu interpretieren ist. DD für den Tag, MM für den Monat, RRRR für ein 4-stelliges Jahr. Trennzeichen ist hier der Punkt ".". Es können auch beliebige andere Trennzeichen verwendet werden. Für andere Formatierungen gibt auch noch weitere Formatmasken.

Q: In welchen Punkten unterscheidet sich ein PRIMARY KEY-Constraint von einem UNIQUE-Constraint?
- Ein Primärschlüssel darf nicht NULL sein.
- Ein UNIQUE-Attribut muss immer nicht NULL sein
- Primärschlüssel sind automatisch indiziert, UNIQUE-Attribute nicht.
- Es ist nur ein Primärschlüssel pro Tabelle zulässig, aber viele UNIQUE-Attribute.
- Ein Primärschlüssel darf nicht zusammengesetzt sein aus mehreren Attributen.
A: Ein Primärschlüssel darf nicht NULL sein.; Es ist nur ein Primärschlüssel pro Tabelle zulässig, aber viele UNIQUE-Attribute.
Feedback: Die Constraints UNIQUE und PRIMARY KEY unterscheiden sich in zwei Eigenschaften: - Es gibt pro Tabelle nur einen Primärschlüssel aber beliebig viele UNIQUE-Attribute. - Die Spalten eines PRIMARY KEY sind implizit auch Pflichteingabespalten, während die Spalten des UNIQUE-Schlüssels auch NULL sein dürfen.

Q: Wahr oder falsch? -  CONSTRAINTS sind eigene Datenbankobjekte, die unabhängig von einer Tabelle existieren können.
- Wahr
- Falsch
A: Falsch
Feedback: Constraints werden nicht mit einem eigenen CREATE-Table-Befehl, sondern über ein ALTER-Table oder CREATE-Table angelegt.

Q: Betrachten Sie folgenden CREATE TABLE-Befehl:

CREATE TABLE Person (
  ID NUMBER PRIMARY KEY,
  NACHNAME VARCHAR2(20) PRIMARY KEY,
  TYP CHAR(1)
);

Wählen Sie die richtigen Aussagen aus.
- Der CREATE-TABLE -Befehl wirft einen Fehler.
- Der CREATE-TABLE -Befehl wirft keinen Fehler.
- Der CREATE-TABLE -Befehl wirft keinen Fehler, aber es wird nur der erste PRIMARY KEY verwendet.
A: Der CREATE-TABLE -Befehl wirft einen Fehler.
Feedback: Eine Tabelle kann nur einen PRIMRY KEY haben, der alle Tupel einer Tabelle eindeutig identifiziert. Wenn er aus mehrrer Attributen besteht, muss eine Definition als Tabellen-Constraint erfolgen.

Q: Wahr oder falsch? - Jeder Column-Constraint (Spaltenbedingung) kann auch als Table-Constraint (Tabellenbedingung) geschrieben werden.
- Wahr
- Falsch
A: Wahr
Feedback: Ein Column-Constraint unterscheidet sich von einem Table-Constraint durch die Stellung im SQL-Befehl: Der Columns-Constraint wird durch ein Komma von der Spaltendefinition abgetrennt und kann sich nur auf eine Spalte beziehen.

Q: Was versteht man unter "Dangling-Datensätzen" in SQL?
- Datensätze, die nicht gesichert werden.
- Datensätze, denen Attributwerte fehlen.
- Geänderte Datensätze, deren Transaktion noch nicht abgeschlossen ist.
- Datensätze, deren Attributwerte aus der Join-Bedingung nur in einer Relation vorhanden sind.
A: Datensätze, deren Attributwerte aus der Join-Bedingung nur in einer Relation vorhanden sind.
Feedback: Werden Fremdschlüssel verwendet, so kann es zu "dangling" Tupeln kommen: Datensätze, die noch von anderen Datensätze referenziert werden, werden gelöscht oder deren Schlüsselwert wird geändert. Dadurch existieren Datensätze, für deren Fremdschlüsselwerte es dann keinen passenden Datensatz in der ersten Tabelle mehr gibt. Analoge Probleme können bei Join-Operationen (Theta-, Equi,- natürlicher) auftreten. In die Ergebnismenge werden nur die Datensätze aufgenommen, die die Verknüpfungsbedingung erfüllen. Alle anderen fallen heraus, das sind die sog. "dangling tuples". Will man diese auch anzeigen lassen, muss man mit den äußeren Joins arbeiten.