1 Rückblick SELECT mit mehreren Relationen Inner Join CROSS JOIN NATURAL JOIN CONDITION JOIN COLUMN...

Rückblick

SELECT mit mehreren Relationen Inner Join

CROSS JOIN NATURAL JOIN CONDITION JOIN COLUMN NAME JOIN

Self Join Outer Join

LEFT OUTER JOIN RIGHT OUTER JOIN FULL OUTER JOIN

Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

Rückblick

ORDER BY (asc / desc) NULL-Werte und 3wertige Logik

IS NULL IS NOT NULL Wahrheitswerte für Terme Wahrheitswerte für Vergleichsausdrücke Wahrheitswerte für logische Ausdrücke Wahrheitstabellen (Wahrheitstafeln)

Ausblick

Funktionale Abhängigkeiten Normalformen Zerlegungen Sichten / Views Übungen Bibliothek

NormalformenFunktionale

Abhängigkeiten

Zerlegungen

Normalformen

Gute von schlechten Datenbank-Schemata unterscheiden können!

Normalformen

Gesucht:

ein zuverlässiges Verfahren zur Erkennung eines schlechten Schemadesigns

ein zuverlässiges Verfahren zur Erzeugung eines guten Schemadesigns

Normalformen

Gute Datenbankschemata ermöglichen die Herleitung aller benötigten

Daten aus den Basisrelationen schränken die Möglichkeit inkonsistente

Daten darzustellen weitgehend ein stellen die Daten möglichst redundanzfrei dar ermöglichen gute Performance bei Zugriffen verhindern Mutationsanomalien

Normalformen

Durch die Zerlegung von Tabellen wird für manche Queries ein zusätzlicher Join notwendig.

Dies beeinträchtigt die Performance!!!

Folglich müssen triftige Gründe für eine Zerlegung vorliegen, um die potentiellen Performanceverluste aufzuwiegen.

Normalformen

Gute Datenbankschemata

Unvermeidbarer Zielkonflikt zwischen

der Forderung nach guter Performance

und Redundanzfreiheit!!!

Mutationsanomalien

Einfügeanomalien (Insert-Anomalie)

Änderungsanomalien (Update-Anomalie)

Löschanomalien (Delete-Anomalie)

Mutationsanomalien

(Beispiel 1)

Abteilungsmitarbeiter

M# Name Strasse Ort A Bezeichnung

M19M1M7M4

SchweizerMeierHuberBecker

HauptstrasseLindenstrasseMattenwegWasserweg

ZürichLiestalBaselLiestal

A6A3A5A6

FinanzInformatikPersonalFinanz

Mutationsanomalien

Einfügeanomalie

Falls man eine neue Abteilung z.B. A9 mit dem Namen „Marketing“ erfassen will, ist dies nur möglich, wenn man auch einen Mitarbeiter dafür erfasst, auch wenn es noch keinen gibt.

Ein NULL-Wert für Mitarbeiter ist nicht möglich, da M# Teil des Schlüssels ist.

Mutationsanomalien

Änderungsanomalie

Soll z.B. die Bezeichnung der Abteilung A6 von „Finanz“ in „Finance“ geändert werden, muss die Änderung bei sämtlichen Mitarbeitertupeln der Abteilung vollzogen werden, obwohl sich nur ein einziger Sachverhalt ändert.

Mutationsanomalien

Update in SQL

UPDATE Abteilungsmitarbeiter

SET Bezeichnung = 'Finance'

WHERE Bezeichnung ='Finanz';

Mutationsanomalien

Löschanomalie

eine Löschanomalie liegt vor, wenn eine Information ungewollt verloren geht.

Wenn man z.B: in der Tabelle „Abteilungsmitarbeiter“ Mitarbeiter M1 löscht, geht die Abteilung „Informatik mit der Abteilungsnummer „A3“ verloren.

Mutationsanomalien

DELETE

DELETE FROM Abteilungsmitarbeiter

WHERE M# = M1;

Mutationsanomalien

Um Probleme der Redundanz und die dabei auftretenden Änderungsanomalien in den Griff zu bekommen, bietet sich folgende Lösung an:– Es wird eine Überführung des

Ausgangsschemas in spezielle andere Schemata vorgenommen, die die genannten Probleme nach Möglichkeit vermeiden. Dies entspricht einer Zerlegung in Normalformen. (Normalisierung)

Mutationsanomalien

Beispiel 2

Angenommen, wir hätten

LIEFERANT(LName, LAdresse) liefert(LName, ArtName, Preis)

zusammengefaßt in L_INFO(LName, LAdresse, ArtName, Preis)

Mutationsanomalien

Beispiel 2

Die Lieferantenadresse „LAdresse“ muß dann für jede Lieferung wiederholt werden. Dies führt zu potentiellen Inkonsistenzen infolge von Redundanz.

Mutationsanomalien

Beispiel 2• Update-Anomalie

Beim Ändern der Adresse LAdresse muß dies in jedem Tupel geschehen, in dem der zugehörige Lieferant vorkommt.

• Insert-Anomalie:Ein Lieferant mit Adresse kann nicht erfaßt werden, wenn er momentan noch nichts liefert. NULL für ArtName ist nicht erlaubt, da ArtName Teil des Schlüssels ist

• Delete-Anomalie:Falls man die Artikel eines Lieferanten löscht, verliert man ungewollt auch dessen Adresse

Bei einer Zerlegung von „L_INFO“ in „Lieferant“ und „liefert“ verschwinden diese Probleme.

Funktionale Abhängigkeit

Zwischen Attributen einer Tabelle

Funktionale Abhängigkeiten

DefinitionSeien R(A1, ..., An) ein Relationenschema und und X,Y {A1, ..., An}.

Y heißt funktional abhängig von X (geschrieben X Y) genau dann, wenn gleiche Attributwerte für X auch gleiche Attributwerte für Y erzwingen. X Y heißt dann FD (functional dependency) für R(A1, ..., An).

Die Definition ist „identisch“ mit der mathematischen Definition einer Funktion:

f: X Y / f X x Y

( x X, y, z Y: (x,y) f und (x,z) f ) y = z

(Zu einem Zeitpunkt / in einem DB-Zustand)

Beispiel (L_INFO)

LName LAdresse ArtName Preis

'Kahn' 'Seestr. 9' 'Käse' 1.99

'Kahn' ??? 'Wurst' 1.19

Ist der Attributwert ??? irgendwie herleitbar?

Da LName Primärschlüssel in LIEFERANT ist, wissen wir, daß „LAdresse“ von LName funktional abhängig ist.

Folglich muß ??? gleich Seestr. 9 sein.

Die Redundanz wurde durch die FD {Lname} {LAdresse} bewirkt.

Für Relationenschemata, die aus dem E/R-Design entstanden sind, ergeben sich folgende FDs:

Repräsentiere R(A1, ..., An) den Entity-Typ R und sei X Schlüsselkandidat von R.

dann gilt: X Y für alle Y {A1, ..., An }

Für Relationenschemata, die aus dem E/R-Design entstanden, ergeben sich folgende FDs:

Repräsentiere R(A1, ..., An) eine N:1-Relationship zwischen E1 und E2 und habe E1 den Schlüsselkandidaten X. dann gilt: X Y für alle Y {A1, ..., An }

Beispiele für FDs In LIEFERANT gilt:

{LName} {LAdresse}. In liefert gilt:

{LName, ArtName} {Preis}. In KUNDE gilt:

{KName} {KAdresse, Saldo}.

Beispiele für FDs

triviale FD: {LName} {LName}

aber auch: {LName, ArtName} {LAdresse, Preis}

Bemerkung:

FDs sind Zusicherungen über die Semantik der ,,realen Welt``, d.h. sie sind nicht beweisbar. (intensional)

Manche FDs werden automatisch vom DBS überwacht, wie z.B. der Primärschlüssel

Definition Erfüllung funktionaler Abhängigkeiten (extensional):

Seien r eine Instanz von R(A1, ..., An), X,X {A1, ..., An}. Die Instanz r erfüllt X Y , wenn für alle Tupel r gilt: [X] =[X] impliziert [Y] = [Y].

Bemerkung:

Falls X Y für R gilt, so muß X Y in jedem r erfüllt sein.

Falls X Y nicht gilt, kann X Y durch ein r erfüllt sein oder auch nicht.

Beispiel (Postleitzahlen):Wir betrachten die deutschen Postleitzahlen. In den meisten Fällen ist die Postleitzahl durch Stadt und Straße eindeutig bestimmt, z.B.

{München, Dachsteinstr.} 81825

Von Ausnahmefällen, wie z.B.

{München, Dachauerstr. 1-147} 80335 {München, Dachauerstr. 149-181} 80636

wollen wir im folgenden abstrahieren.

Sei PLZBUCH(Stadt,Straße,PLZ)

gegeben mit den nicht-trivialen FDs F= { {Stadt,Straße} {PLZ}, {PLZ} {Stadt} }.

wir können von folgenden Mengen von Schlüsselkandidaten ausgehen:

schlüsselkand(PLZBUCH) = {{Stadt,Straße},{PLZ}}

Für die funktionale Abhängigkeit gelten für Attributmengen A, B einer Relation R folgende Regeln:

A B bB A {b}

Für die funktionale Abhängigkeit gelten für Attributmengen A, B, C einer Relation R folgende Regeln:

A B B A (triviale FD)

A B A C B C

A B und B C A C (Armstrongsche Regeln)

Wenn S ein Schlüssel von R ist, dann gilt für alle B:

Wenn S S' dann gilt: S' B

Volle Funktionale Abhängigkeit

Eine Menge von Attributen B ist von einer Attributmenge A voll funktional abhängig, wenn gilt:

1) A B

2) es gibt kein A' mit A' A, A' A, mit: A' B

Mit Hilfe der vollen Funktionalen Abhängigkeit lässt sich der Begriff des Schlüsselkandidaten präzise definieren:Eine Menge von Attributen A einer Relation R ist Schlüsselkandidat der Relation R, wenn für jede Menge B von Attributen von R gilt:B ist voll funktional abhängig von A.

Normalformen

Normalformen (1NF)

erste Normalform

Eine Relation ist in erster Normalform (1NF), wenn alle ihre Attribute nur atomare (elementare) Attributwerte besitzen.

Normalformen (2NF)

Zweite Normalform (2NF):Eine Tabelle ist in zweiter Normalform, wenn jedes nicht dem Schlüssel angehörende Attribut funktional abhängig ist vom Gesamtschlüssel nicht aber von den Schlüsselteilend.h: es gibt kein Attribut ausserhalb des Schlüssels, das schon von einem Teil des Schlüssels funktional abhängig ist.

Normalformen

Zweite Normalform (2NF):Eine Tabelle ist in zweiter Normalform, wenn sie in erster Normalform ist und wenn jedes Nichtschlüsselattribut von jedem Schlüsselkandidaten voll funktional abhängig ist.

Normalformen (2NF)

Ein Attribut ist voll funktional abhängig von einem zusammengesetzten Schlüsselkandidaten, falls es nicht funktional abhängig ist von einem Teil des Schlüsselkandidaten.

Normalformen (Beispiel)

M# Name Ort P

HuberMeier

BaselLiestal

{P1,P9}{P7,P11,P9}

Projektmitarbeiter (unnormalisiert)

M# Name Ort P#

M7M7M1M1M1

HuberHuberMeierMeierMeier

BaselBaselLiestalLiestalLiestal

P1P9P7P11P9

Projektmitarbeiter (in erster Normalform)

Normalformen (1 NF) (2 NF)M# Name Ort P#

M7M7M1M1M1

HuberHuberMeierMeierMeier

BaselBaselLiestalLiestalLiestal

P1P9P7P11P9

Projektmitarbeiter (in erster Normalform)

M#M# P#

Name Ort M7M7M1M1M1

P1P9P7P11P9

HuberMeier

BaselLiestal

Mitarbeiter (2NF)Zugehörigkeit (2NF)

Normalformen (2NF)

Zweite Normalform (2NF):die 2 NF kann nur verletzt werden

• wenn eine Relation einen zusammengesetzten Schlüssel hat

• und die Relation mindestens ein Attribut besitzt, das nicht zum Schlüssel gehört

Normalformen (2NF)

Zerlegungdurch Zerlegung der Ausgangsrelation in eine Relation mit voll funktional abhängigen Attributen und eine weitere Relation mit teilabhängigen Attributen können Relationen in der 2. NF gewonnen werden.

Normalformen (2NF)

Alternative FormulierungA ist ein Primattribut, wenn A Element

eines Schlüsselkandidaten ist.

R ist in 2 NF, wenn es keine nicht-trivialen funktionalen Abhängigkeiten T A gibt, wobei T eine echte Untermenge eines Schlüsselkandidaten ist und A kein Primattribut enthält.

Normalformen (3 NF)

Dritte Normalform (3NF):Eine Tabelle ist in dritter Normalform, wenn sie in zweiter Normalform ist

und keine funktionalen Abhängigkeiten zwischen Attributen erlaubt, die keine Schlüsselattribute sind.

Normalformen (3 NF)

Dritte Normalform (3NF):Eine Tabelle ist in dritter Normalform, falls sie in 2NF ist und kein Nichtschlüsselattribut von irgendeinem Schlüsselkandidaten transitiv abhängig ist.

Transitive Abhängigkeit

heisst über Umwege funktional abhängig sein:

A B und B C A C

Normalformen (3 NF)

Dritte Normalform (3NF):Die dritte Normalform kann nur verletzt werden, wenn eine Relation neben dem Schlüssel (einfach oder zusammengesetzt) mindestens zwei zusätzliche Attribute hat, die keine Attribute eines Schlüsselkandidaten sind.

Normalformen (3NF)

Beispiel:

(S1#, S2#, A, B)

Voraussetzung:S1#, S2# sind die beiden Schlüsselattribute

Falls S2# A ist die Relation nicht 2NF

Falls A B ist die Relation nicht in 3NF

Normalformen (3NF)

Beispiel:

R ( S1#, S2#, A, B)

Normalformen (3NF)

Beispiel 2:

mitarbeiter(emp_nr, name, ort, abt_nr, abt_name)

Verletzt 3NF, wegen funktionaler Abhängigkeit zwischen abt_nr und abt_name

Normalformen (4NF / 5NF)

Die Normalformen 4 und 5 sind in der

Praxis von geringer Bedeutung und

werden deshalb hier nicht behandelt.

Zerlegungen

Zerlegung

Durch eine geeignete Zerlegung eines schlechten Schemas kann man die bekannten Design-Anomalien beseitigen.

Im folgenden identifizieren wir dazu ein Schema R(A1, ... An) mit der Menge seiner Attribute R={A1, A2, ..., An}.

Zerlegung

Definition (Zerlegung):

Die Zerlegung eines Relationenschemas R = {A1 ... An} ist dessen Ersetzung durch eine Menge von Relationenschemata

= {R1, ... , Rk} mit Ri R und R = R1 ... Rk.

Die Ri müssen dabei nicht disjunkt sein. Für eine gute Zerlegung sollte aber bestimmte Eigenschaften aufweisen

Zerlegung

Beispiel (Zerlegung):

L_INFO = {LName, LAdresse, ArtName, Preis},

LIEFERANT = {LName, LAdresse} und

liefert = {LName, ArtName, Preis}.

Offensichtlich ist = {LIEFERANT, liefert} eine Zerlegung von L_INFO. Diese Zerlegung bereinigte einige der in L_INFO aufgetretenen Anomalien. Umgekehrt stellt sich die Frage, ob man L_INFO eindeutig aus der Zerlegung zurückgewinnen kann?

ZerlegungBeispiel (Zerlegung mit Verlusten):Daß dies im allgemeinen nicht der Fall ist, zeigt folgendes Beispiel:

AA BB BC C

r r1 r2

Die Instanz r ist durch einen Natural Join aus den Projektionen r1 und r2 nicht rekonstruierbar.

Zerlegung

Es gilt: = {R1, R2} ist eine Zerlegung von R.

r1 = A,B(r), r2 = B,C(r)

Jedoch gilt: r r1 |x|r1.B =r2.B r2

Die Instanz r ist demnach im allgemeinen durch einen Natural Join aus den Projektionen r1 und r2 nicht rekonstruierbar.

Zerlegung

Definition (Verlustfreie Zerlegung bzgl. F):

• Sei = {R1, ... , Rk} eine Zerlegung von R und F

eine Menge von FDs auf R. Die Zerlegung besitzt einen verlustfreien Join bezüglich F, wenn für jede Instanz r von R, die F erfüllt, gilt:

• r = R1(r) |x| ... |x| Rk(r) • Die Wiedergewinnung der ursprünglichen Information

aus der Zerlegung ist also für solche möglich, die einen verlustfreien Join besitzen. heißt dann auch verlustfreie Zerlegung bzgl. F.

Zerlegung

Eine verlustfreie Zerlegung für jede Instanz r, die F erfüllt, erfordert:

– keine dangling Tupel in den Projektionen,

– vollständige Kombinationen in R.

ZerlegungBeispiel 2 (Dangling Tupel):

r AA BB BC C

17 21 45 17 21 21

504569

Ausgangspunkt: r1 und r2; r ist natural join von r1 und r2.Die anschliessende Zerlegung führt wieder zu einem Verlust.Ursache für den Verlust bei der Zerlegung sind in diesem Fall Tupel ohne natürlichen Joinpartner in r2. Solche Tupel ((50,69) in r2) heissen auch dangling Tupel

Sichten / Views

Sichten (Views)

Eine (Daten)Sicht ist eine virtuelle Tabelle.

In Sichten werden Informationen aus mehreren Tabellen zusammen geführt.

Eine Sicht wird nicht physikalisch langfristig gespeichert, sondern bei jeder Nutzung neu mittels einer zugeordneten Abfrage aus den aktuellen Daten der involvierten Tabellen neu berechnet.

Sichten (Views)

Eine Datensicht verhält ich bei Abfragen wie eine reale Tabelle.

Abfragen an Sichten können genau so formuliert werden wie Abfragen an Tabellen.

Es sind Verbünde (Joins) mit anderen Tabellen oder Datensichten möglich.

Sichten erlauben auch Datenmanipulationen

Sichten (Views)

(Daten)Sichten gehören zum externen Schema des ANSI-SPARC-Architektur.

Sie ermöglichen es zusammengehörige Daten für den Benutzer wieder zusammenhängend zugänglich zu machen, so dass sich dieser nicht um das redundanzarme konzeptionelle Schema kümmern muss.

Sichten (Views)

Resultate von Berechnungen werden nicht in die Basisrelationen des logischen (konzeptionellen) Datenbankschemas aufgenommen.

Sie können aber sinnvoll in Sichten eingebracht und so auch weiter verarbeitet werden – solche Sichten erlauben allerdings keine Updates

Sichten (Views)

Datensichtdefinition in SQL (Syntax):

CREATE VIEW viewname [(spaltenliste)]

AS abfrage

[WITH [CASCADED | LOKAL] CHECK OPTION]

„ abfrage „ ist dabei eine beliebige Abfrage. Die ORDER BY-Klausel ist darin nicht zulässig.

Sichten (Views)

Die Angabe der Spaltennamen (spaltenliste) kann entfallen, wenn die Spaltennamen der „abfrage“ übernommen werden sollen.

WITH CHECK OPTION formuliert Integritätsregeln für UPDATE-Operationen.

Sichten (Views)

Beispiel:CREATE VIEW kundenadr AS

SELECT kundennr, name, strasse, plz,ort

FROM kunde;

SELECT *

FROM kundenadr

ORDER BY kundennr

Sichten (Views)

CREATE VIEW rechnung AS

SELECT be.bestellnr, be.lieferdatum AS datum,

po.bestellmenge, po.liefermenge AS menge,

po.mwst, po.gesamtpreis AS preis,

ku.kundennr,ku.name,ku.strasse, ku.plz, ku.ort,

ar.artikelnr ar.verpackkung AS packung,

ar.bezeichnung ar.lagerplatz AS lager

FROM bestellung be

JOIN kunde ku ON be.kundennr = ku.kundennr

JOIN position po ON be.bestellnr = po.bestellnr

Join artikel ar ON po.artikelnr = ar.artikelnr

WHERE be.lieferdatum IS NOT NULL;

Sichten (Views)

Mit der View „rechnung“ lässt sich sehr einfach eine Rechnung „drucken" z.B.:

SELECT bestellnr, datum, menge, preis, name, artikelnr

FROM rechnung

WHERE bestellnr = 4711;

Sichten (Views)

CHECK OPTION

Änderung von Daten mittels Sichten

CREATE VIEW kunden_freiburg AS

SELECT kundennr, name, strasse, plz, ort

FROM kunde

WHERE ort = „Freiburg“;

UPDATE kunden_freiburg

SET ort=„Offenburg“

WHERE kundennr = 3612;

Sichten (Views)

CHECK OPTION

Die UPDATE-Anweisung führt dazu, dass Kunde 3612 nicht mehr in der Sicht „kunden_freiburg“ auftaucht.

Durch die CHECK OPTION kann ein solches Update verhindert werden.

Sichten (Views)

CHECK OPTION

CREATE VIEW kunden_freiburg AS

SELECT kundennr, name, strasse, plz,ort

FROM kunde

WHERE ort = „Freiburg“

WITH CHECK OPTION;

Ein Update wie vorher geschildert, wird dadurch zurück gewiesen.

Sichten (Views)

Aus Normalisierungsgründen werden beim logischen Datenbankentwurf meist keine Spalten in den Basisrelationen aufgenommen, die durch Berechnungen aus vorhandenen Attributwerten einzelner Tupel abzuleiten sind.Beispiel:Wert des Lagerbestandes pro Artikelbestandswert = listenpreis * bestand

Mit Sichten ist dies jedoch sinnvoll möglich!

Sichten (Views)

Folgende Sicht zeigt den berechneten „bestandswert“ an.

CREATE VIEW artikel_bestandswert ASSELECT artikelnr, listenpreis, bestand,

listenpreis * bestand AS bestandswertFROM artikel;

In der Spalte „bestandswert“ sind automatisch keine Update und INSERT-Operation zulässig.

Bibliotheks-anwendung

Buch Autor

Buch-auflage

Buch-exemplar

Benutzer

hatvorgemerkt

leihtaus

Autorvon

Schlagwortvon

ISBN Titel

Verlag

ANr Name

Vorname

BNr Name

Adresse

VornameBibNr

Auflage

hatAufl

hatExemp

n mStandort

Tabellenmodell

Autor(Anr, Name, Vorname)Buch(ISBN, Titel, Verlag, Ort)Autor-von(Anr, ISBN)Schlagwort(SNr, Wort)Schlagwort-von(SNr, ISBN)Buchauflage(Auflage, Preis, Jahr, ISBN)Buchexemplar(BibNr, Standort, ISBN, Auflage)Benutzer(BNr, Name, Vorname, Adresse)Leiht-aus(BibNr, BNr, Datum)Hat-vorgemerkt(BNr, BibNr, Datum)

CREATE TABLE Autor (

ANr INTEGER PRIMARY KEY,

Name CHAR(30) NOT NULL,

Vorname CHAR(30)

CREATE TABLE Buch (

ISBN INTEGER PRIMARY KEY,

Verlag CHAR(30) NOT NULL,

Titel CHAR(30) NOT NULL,

Ort CHAR(30)

Autor-von

CREATE TABLE Autor-von (

ISBN INTEGER,

ANr INTEGER,

PRIMARY KEY ( ISBN, ANr),

FOREIGN KEY ISBN REFERENCES Buch ON DELETE CASCADE ON UPDATE CASCADE,

FOREIGN KEY ANr REFERENCES Autor ON DELETE CASCADE ON UPDATE CASCADE

Schlagwort

CREATE TABLE Schlagwort (

SNr INTEGER PRIMARY KEY,

Wort CHAR(30) NOT NULL

Schlagwort von

CREATE TABLE Schlagwort-von (ISBN INTEGER

FOREIGN KEY REFERENCES Buch,SNr INTEGER

FOREIGN KEY REFERENCES Schlagwort,

PRIMARY KEY ( ISBN, SNr));

Buchauflage

CREATE TABLE Buchauflage (ISBN INTEGER,Auflage INTEGER,Preis NUMERIC(8,2),Jahr CHAR(4),PRIMARY KEY(ISBN, Auflage),FOREIGN KEY ISBN REFERENCES Buch

ON DELETE CASCADE ON UPDATE CASCADE);

Buchexemplar

CREATE TABLE Buchexemplar (BibNR INTEGER PRIMARY KEY,Standort CHAR(10),ISBN INTEGER NOT NULL,Auflage INTEGER NOT NULL,FOREIGN KEY ISBN REFERENCES Buchauflage

ON DELETE CASCADE ON UPDATE CASCADE,FOREIGN KEY Auflage REFERENCES Buchauflage

ON DELETE CASCADE ON UPDATE CASCADE);

Benutzer

CREATE TABLE Benutzer (

BNr INTEGER PRIMARY KEY,

Name CHAR(30) NOT NULL,

Vorname CHAR(30) NOT NULL,

Adresse CHAR(60) NOT NULL

Leiht-aus

CREATE TABLE leiht-aus (

BibNr INTEGER FOREIGN KEY REFERENCES Buchexemplar,

BNr INTEGER FOREIGN KEY REFERENCES Benutzer,

PRIMARY KEY (BNr, BibNr)

Hat-vorgemerkt

CREATE TABLE hat-vorgemerkt (BibNr INTEGER FOREIGN KEY

REFERENCES Buchexemplar,BNr INTEGER FOREIGN KEY

REFERENCES Benutzer,Datum DATE,PRIMARY KEY (BNr, BibNr));

Bibliothek SQL-Aufgaben

• Buch einfügen: (Andreas Meier, Relationale Datenbanken,

Springer, Berlin, 4. Auflage, 2001, ISBN=3-540-41468-1, (Schlagworte: Datenbank, Informatik), Preis 45.90 DM, Bibliotheksnr 111)

• Buch updaten• Ändern Sie das zugeordnete Schlagwort

"Datenbank" des eingegebenen Buches mit einem SQL-Kommando in "Relationale Datenbank" ab

INSERT INTO Buch

(ISBN, Titel, Verlag, Ort) VALUES (3540414681, 'Relationale Datenbanken', 'Springer', 'Berlin');

INSERT INTO Buchauflage

(ISBN, Auflage, Preis, Jahr) VALUES (3540414681, 4, 45.90, '2001');

INSERT INTO Buchexemplar

(ISBN, Auflage, BibNr, Standort) VALUES (3540414681, 4, 111, NULL);

INSERT INTO Schlagwort

(SNr,Wort) VALUES (1, 'Datenbank'), (2, 'Informatik');

INSERT INTO Schlagwort-von

(SNr,ISBN)

VALUES (1, 3540414681 ), (1, 3540414681 );

Update Schlagwort

SET Wort = 'Relationale Datenbank'

WHERE SNr =1

• Benutzer erfassen: (Peter Georgi, 78462 Konstanz Inselgasse 25)

Benutzer updaten (Peter Georgi 78462 Konstanz Obere Laube

22) Benutzer löschen

(Peter Georgi 78462 Konstanz Obere Laube 22)

Buch löschen (Andreas Meier ...)

• Benutzer erfassen: (Peter Georgi, 78462 Konstanz Inselgasse 25)

INSERT INTO Benutzer(BNr, Name, Vorname, Adresse)VALUES(1, 'Georgi', 'Peter'‚ '78462 Konstanz Inselgasse 25');

• Benutzer updaten: (Peter Georgi, 78462 Konstanz Obere Laube

UPDATE BenutzerSET Adresse = '78462 Konstanz Obere Laube 22'

WHERE BNr=1;

• Benutzer / Buch löschen:

DELETE FROM BenutzerWHERE BNr = 1;

DELELTE FROM BuchWHERE ISBN=3540414681;

Ausleihe Benutzer Peter Georgi leiht das erfasste Buch

von Andreas Meier am 7.3.2002 aus.

Vormerkung Marianne Weber merkt das erfasste Buch am

8.3.2002 vor.

Rückgabe Peter Georgi gibt das Buch am 10.3.2002

zurück.

Ausleihe Benutzer Peter Georgi leiht das erfasste Buch

von Andreas Meier am 7.3.2002 aus.

INSERT INTO leiht-aus(BibNr, BNr, Datum)VALUES(111,1,DATE'07-03-2002');

VormerkungMarianne Weber merkt das bereits erfasste Buch am

8.3.2002 vor. INSERT INTO Benutzer

(BNr,Name, Vorname,Adresse)(2, 'Weber', 'Marianne', '78462 Konstanz Konradigasse 7');

INSERT INTO hat-vorgemerkt(BibNr,BNr,Datum) VALUES (111,2,DATE'08-03-2002');

Rückgabe Peter Georgi gibt das Buch am 10.3.2002

zurück. DELETE FROM leiht-aus

WHERE BibNr=111;

1 Rückblick SELECT mit mehreren Relationen Inner Join CROSS JOIN NATURAL JOIN CONDITION JOIN COLUMN...

Documents

Transcript of 1 Rückblick SELECT mit mehreren Relationen Inner Join CROSS JOIN NATURAL JOIN CONDITION JOIN COLUMN...

MODEL ANSWER - WordPress.com · The SQL OUTER JOIN returns all rows from both the participating tables which satisfy the join condition along with rows which do not satisfy the join

1 Intro to JOINs SQL INNER JOIN SQL OUTER JOIN SQL FULL JOIN SQL CROSS JOIN Intro to VIEWs Simple VIEWs Considerations about VIEWs VIEWs as filters ALTER.

Structure Query Language (SQL) · 1 abhi 1 DELHI 2 adam 2 MUMBAI 3 alex 3 CHENNAI null null 7 NOIDA null null 8 PANIPAT 6.15.3 Full Outer Join The full outer join returns a result

CS 327E Lecture 9scohen/cs327e_fall16/slides/... · 2017-01-25 · Suppose we replace the inner join on Student and Enrollment in the query below with a left-outer join. What additional

How to retrieve data from two tables - faculty.tnstate.edufaculty.tnstate.edu/Oracle10g/text/Chapter 4.pdf · • Describe the differences between an inner join, a left outer join,

Inner Join vs. Outer Join Information Retrieval from Relational Databases 1.

More queries Outer joins and summary queries. Inner and outer joins An Inner join only returns matching rows from two tables –E.g. if I join the customer.

which case would you use a FULL OUTER JOIN?--> You want all unmatched data from both tables.

Inner and outer joins SQL examples and the Join block _ Datamartist.pdf

Extraktion und Induktion von Ontologien und Lexikalisch Semantischen Relationen

Relationen mellem teori og praksis - AUprojekter.au.dk/fileadmin/ · Relationen mellem teori og praksis en sammenligning af pædagog- og læreruddannelsen The Relation between Theory

Jianfeng Jia (UC Irvine) Pregelix: Big(ger) Graph Tyson ...pregelix.ics.uci.edu/slides/Pregelix- Big(ger) Graph Analytics on A... · Index Full outer join Index Left outer join. Data

Advanced Queries 1 2 · 339 Advanced Queries 1 2 • left outer join • make table query • outer join • right outer join • SELECT statement • subquery • unequal join

TRAINING & CONSULTING Cours de base en informatique - … · 6.1 INNER JOIN 79 6.2 LEFT et RIGHT OUTER JOIN 81 6.3 FULL OUTER JOIN 83 ... • Teradata Différences:

Outer Banks Presbyterian Church · December 2015 Outer Banks Presbyterian Church Christmas Eve Candlelight Worship Service Thursday, Dec. 24 5:00 pm Join us for our Christmas Eve

Baze de date - runceanu.ro · ORACLE Join-uri SQL 1999 Cartesian Product Cross join Equijoin Natural join Non-equijoin Using clause Outer join Full (two sided) outer joins Self join

En studie om relationen mellan subjektivt v¤lbefinnande, socialt st¶d och ledarskap

Terry Purcell IBM Silicon Valley Lab · 2016. 10. 8. · Brute force data scanning ... Give DB2 12 Optimizer a Chance ... • Push join predicates inside UA legs or Outer Join query

SQL Query Joins - Syracuse University · Outer Join An outer join selects all of the records from one database table and only those records in the second table that have matching

Outer Join SQL