Übersicht zu Datenmodellen

Grundlagen zur Verwendung von
Datenbankmanagementsystemen
Vorlesung im Wintersemester 2007/08
(Abschnitt Datenmodelle)
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
1
Übersicht Datenmodelle
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
2
Zielstellung Datenmodells
Für die Analyse, das Design und die Realisierung eines
betrieblichen Informationssystems werden Notationen, Methoden
und Werkzeuge benötigt, um auf der konzeptionellen Ebene einen
Teil der realen Welt darzustellen. Für die Basis der Informationen
(im engeren Sinne die Daten) ist dies das Datenmodell. Durch die
Modellbildung wird die Welt vereinfacht, diskretisiert, idealisiert,
andererseits aber für eine systematische Darstellung zugänglich
gemacht.
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
3
Modell der
Informationsverarbeitung
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
4
Begriff des Datenmodells
Ein Datenmodell bietet ein formales Konzept zur Beschreibung von
Datenbankstrukturen, welche Informationsstrukturen eines
Ausschnittes aus der realen Welt, dem so genannten Diskursbereich
(auch Universum of Discurse) repräsentieren. Ein Datenmodell kann
somit als ein Plan verstanden werden, welcher
Informationsstrukturen beschreibt und der angibt in welcher Weise
diese Informationsstrukturen untereinander in Beziehung stehen.
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
5
Verwendete Begriffe im
Kontext des Datenmodells
§ Objekte (Entity) der realen Welt (z.B. konkretes Fahrzeug)
§ Objektklassen (Entity-Typ) z.B. allgemein Fahrzeug
§ Merkmale zur Beschreibung eines Objektes - Attribute
§ Werte der Merkmale – jedes Attribut kann Werte aus einem
bestimmten Wertebereich annehmen
§ Beziehungen – zwischen Entities (z.B. ein Audi 80 hat 4 Räder R14)
§ Beziehungstypen – Entity-Typ Fahrzeug hat Räder
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
6
Hierarchisches Datenbankmodell
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
7
Hierarchisches
Datenbankmodell
Das hierarchische Datenbankmodell ist eng mit den IBM-Produkten
IMS (Information Management System) bzw. DL/I (Data Language I)
verbunden. Diese Entwicklungen gehen bis in die Jahre 1964/65
zurück. Das Grundkonzept ist die Ablage von Daten in Segmenten
in physischen hierarchischen Baumstrukturen (physical data base).
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
8
Hierarchisches
Datenbankmodell
Quelle: Schreiter, D.: Lehrbrief Datenbanken – Grundlagen, Technische Universität Dresden
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
9
Hierarchisches
Datenbankmodell
Merkmale 1:
§ Entities und deren Beziehungen zueinander werden auf der
Grundlage der Graphentheorie dargestellt
- Knoten (Entities)
- Kanten (Beziehungen)
§ Die Datensätze sind in einer strengen Baumstruktur angeordnet
§ Es kann nur ein Schlüssel verwendet werden
§ Ein Datensatz ist nur über seinen Vorgänger (genau einer) erreichbar
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
10
Hierarchisches
Datenbankmodell
Merkmale 2:
§ Zwei-Ebenen Architektur (es fehlt das externe Schema)
§ Datenbanksprache von IMS ist DL/1 (Data Language One)
- Keine Interaktive Version von DL/1 verfügbar
- DL/1 eingebettet in PL/1, COBOL, System/370 Assembler
§ Auch die interne Ebene ist im Zugriff des Anwendungsprogrammierers
- Keine Datenunabhängigkeit
§ Navigierende Operationen
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
11
Hierarchisches
Datenbankmodell
Vorteile:
Ein wichtiger Vorzug des hierarchischen Modells besteht darin, dass
wir in unserer Umwelt häufig hierarchische Strukturen antreffen. Von
daher ist also eine bestimmte Vertrautheit und Gewohnheit im
Umgang mit hierarchischen Strukturen zu verzeichnen, was die
Modellierung und die Benutzung der hierarchischen Modelle
vereinfacht.
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
12
Hierarchisches
Datenbankmodell
Nachteile 1:
§ Die Prozeduralität der Operationen ist auch bei hierarchischen
Modellen notwendig. Der Benutzer muss bei voller Kenntnis der
Struktur des Waldes navigierend zugreifen.
§ Beziehungsmengen, die eine m:n-Abbildung realisieren, sind relativ
aufwendig zu modellieren und führen ggf. zu Redundanzen.
§ Die Updateoperationen „Einfügen“ und „Löschen“ erfordern
besondere Aufmerksamkeit wegen der strengen Ordnung der Sätze
in einem Baum.
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
13
Hierarchisches
Datenbankmodell
Nachteile 2:
§ Aufwendige Reorganisation bei Speicherbereichsüberschreitungen
§ Sehr unflexibel, da die Beziehungen zwischen Entities bereits beim
Entwurf der Datenbank festgelegt werden müssen (schwer zu
verändern).
§ Jedes Entity ist immer und nur über das zugehörige Wurzel-Entity
als Einstiegspunkt in die Hierachie und über einen gerichteten Pfad
erreichbar
§ Verwendung der Datenbank erfordert weit reichende Kenntnisse der
internen Struktur der Datenbank
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
14
Netzwerkorientiertes Datenbankmodell
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
15
Netzwerkorientiertes
Datenbankmodell
Die Definition des Netzwerkmodells (auch CODASYL-Modell) geht
auf die Arbeiten der Data Base Task Group des CODASYL
(Conference on Data Systems Language) Systems Committees von
1971 zurück. Ziel war die Standardisierung der Datenbanksprachen
(z.B. DML und DDL), wesentliche Datenbankeigenschaften wie die
Datenunabhängigkeit blieben aber unberücksichtigt.
Vertreter: UDS von Siemens
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
16
Netzwerkorientiertes
Datenbankmodell
Quelle: Schreiter, D.: Lehrbrief Datenbanken – Grundlagen, Technische Universität Dresden
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
17
Netzwerkorientiertes
Datenbankmodell
Merkmale:
Wesentliches Strukturierungsmerkmal ist die Ablage von
Daten in Satzarten (record types), die untereinander in
beliebigen Beziehungen (set type, owner-member
Beziehung) stehen können. Auf dieser Grundlage
können komplexe Netzstrukturen abgebildet werden.
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
18
Netzwerkorientiertes
Datenbankmodell
UDS – ein netzwerkorientiertes Datenbanksystem:
§ Entwickelt im Kontext des Betriebssystems Siemens BS2000
§ UDS besitzt keinen Optimierer
§ Datenbankabfragesprache
- eingebettet in COBOL, Assembler, Fortran, Pascal
- Interaktive Anfragesprache IQS – Interactive Query System
§ Weitgehend konform zur ANSI-SPARC Architektur
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
19
Netzwerkorientiertes
Datenbankmodell
Vorteile (aus der Sicht der Datenmodellierung):
§ Redundanzfreie Abbildung von Datenstrukturen
§ Mehrere Strukturierungsmöglichkeiten
§ Beliebige Beziehungen zwischen Satztypen
§ Schneller Zugriff auf eingerichteten Wegen
Die Modellierung ist relativ einfach, besonders dadurch, da es
eindeutige Regeln für die Modellierung von m:n-Abbildungen gibt.
Wenn die Modellierung mit dem Netzwerkmodell erfolgt, dann ist es
als Vorteil anzusehen, dass es leistungsfähige DBMS gibt, die
Netzwerkschemata verarbeiten.
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
20
Netzwerkorientiertes
Datenbankmodell
Nachteile:
§ Darstellung beliebig komplexer Strukturen – unübersichtlich
§ Kenntnis des Zugriffspfad beim Anwendungsprogrammierer
§ Beziehungen zwischen Entities sind beim Entwurf festzulegen
§ Schwierigkeit vorhandene Beziehungen nochmals zu verändern
§ Aufwendige Reorganisation bei Speicherbereichsüberschreitungen
§ Verwendung der Datenbank erfordert weit reichende Kenntnisse der
internen Struktur der Datenbank
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
21
Objektorientiertes Datenbankmodell
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
22
Grundmerkmale der
Objektorientierung
§ Klassen
- Struktur und Verhalten von Objekten (Instanzen)
- Verhalten definiert durch Methoden und Nachrichten
§ Kapselung
- Zustände von Objekten sind von außen nicht sichtbar
- Zustände können nur über Methoden gelesen/verändert werden
§ Klassenhierachien
- Vererbung (Aspekt der Spezialisierung)
- Substituierbarkeit
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
23
Abkürzungen im Kontext
eines OODBS
§ OID - Objektidentifikator
§ OODBMS - Objektorientiertes Datenbankmanagementsystem
§ OODBS – Objektorientiertes Datenbanksystem
§ OODM - Objektorientiertes Datenmodell
§ OQL – Object Query Language
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
24
Entwurf auf Basis der
UML-Notation
§ Standard der OMG (Object Management Group)
§ Gemeinsame Betrachtung von Daten und Funktionen
§ Breite Akzeptanz in der Industrie
§ ER-Modell ßà Klassendiagramm
§ UML bietet sehr umfangreiche Modellierungsmöglichkeiten
- Datenbankentwurf benötigt nur geringen Teil
- Objektorientierte Eigenschaften nicht im Relationenmodell umsetzbar
§ UML-Modell kann die Aufgabenstellungen ER-Modells übernehmen
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
25
Objektorientiertes
Datenbankmodell
Das objektorientierte Datenbankmodell (auch Objektdatenmodell –
kurz ODM) entspricht der Synthese vom objekt-orientierten Konzept
und Datenbankmodell. Hier ist der „impedance mismatch“ zwischen
Programmiersprache und DBMS aufgehoben, da beide Paradigmen
übereinstimmen und somit eine explizite Abfragesprache (wie z.B.
SQL bei relationalen DBMS) nicht mehr erforderlich ist.
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
26
Objektorientiertes
Datenbankmodell ODMG
§ Objektmodell – Konzepte eines OODBS
§ Object Definition Language ODL
(Definition eines Datenbank-schema)
§ Object Query Lanaguage OQL –
deklarative objektorientierte
Anfragesprache (Obermenge SQL2)
§ Sprachanbindungen/Mappings (C++,
Java, …)
§ January 2000, ISBN 1-55860-647-5
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
27
Objektrelationales Datenbankmodell
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
28
Objektrelationales
Datenbankmodell
Hierbei handelt es sich um ein relationales Datenbankmodell mit
einem objektorientierten Aufsatz. Zur Zeit bieten die ORDBMS aber
zu ihrem relationalen Datenbankmodell nur zusätzlich objektorientierte
Features an. Das heißt, dass hier der „impedance mismatch“ noch
nicht aufgehoben ist und somit die ORDBMS auch nicht im vollen
Umfang die Anwendungsbereiche der OODBMS abdecken!
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
29
Objektrelationales
Datenbankmodell
§ Strukturierte Objekte – aus den vorhandenen Datentypen können
komplexere Strukturen definiert werden
§ Untertypen – Aus existierenden Typen können durch
Spezialisierung neue Untertypen gebildet werden (Vererbung)
§ Erweitertes und erweiterbares Typsystem - Erweiterung des
relationalen Datenmodells um neue Typen (z.B. Multimedia)
§ Referenzen – Zwischen Datenelementen können Beziehungen
abgebildet werden die nicht über Fremdschlüsselbeziehungen
abgedeckt werden
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
30
Relationales Datenbankmodell
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
31
Relationales
Datenbankmodell
§ Das Relationenmodell wurde 1970 von Codd eingeführt. (Dafür gab
es den Turing-Award, die höchste Auszeichnung für Informatiker)
§ Das Modell hat sich in der Praxis als Basis für die DBMS
durchgesetzt, und es ist zugleich mathematisch fundiert
§ Das Modell basiert auf Relationen, also Teilmengen eines
kartesischen Produkts.
§ Einfacher ist die Vorstellung: Eine Relation ist eine Tabelle
§ Vereinfacht: Im Relationenmodell wird alles als Tabelle modelliert
und als Zeile in einer Tabelle gespeichert
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
32
Relationales
Datenbankmodell
Eine Relation R(A1, A2, …, An) ist eine benannte Menge von nTupeln, wobei ein n-Tupel eine Anordnung von n atomaren, dass
heißt einfachen und nicht weiter zerlegbaren Attributen A1, A2, …, An
ist. Jedem Attribut ist ein so genannter Definitionsbereich (Domain)
zugeordnet, der die zulässigen Werte festlegt. Die Beschreibung
einer Relation umfasst den Namen der Relation und deren Attribute
sowie die zugehörigen Domains.
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
33
Relationales
Datenbankmodell
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
34
Primär- und Fremdschlüssel
§ Zu jeder Relation R gibt es ein Attribut Ax bzw. eine Kombination (z.B.
A1 und A2) von Attributen die als Primärschlüssel fungieren.
§ Über den Primärschlüssel können Tupel (Zeilen bzw. Sätze einer
Relation) eindeutig identifiziert werden.
§ In den Relationen Kunde bildet das Attribut KNr und in Konto das
Attribut KtoNr geeignete Primärschlüssel.
§ Beziehungen zwischen Relationen können über so genannte
Fremdschlüssel realisiert werden.
§ In der Relation Konto ist das Attribut KNr ein solcher Fremdschlüssel,
mit dem der Inhaber eines Kontos durch einen Verweis auf den
Primärschlüssel der Relation Kunde repräsentiert wird.
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
35
Primär- und Fremdschlüssel
Die Fremdschlüsselbedingung verlangt, dass das durch einen
Fremdschlüssel referenzierte Tupel in der Datenbank existiert, d.h.,
dass in der referenzierten Relation ein entsprechender
Primärschlüsselwert definiert sein muss. In diesem Zusammenhang
wird auch von der referenziellen Integrität gesprochen.
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
36
Relationenenalgebra
Die Relationenalgebra stellt den operationalen Teil des relationalen
Datenbankmodells dar. Sie bildet mit ihren Operationen das
mathematische Fundament und Bewertungskriterium für relatrionale
Anfragesprachen.
- Relationenalgebra ist abgeschlossen (Operationen werden auf
Relationen angewandt und erzeugen wiederum Relationen)
- Operationen können verkettet und damit komplexe Anfragen formuliert
werden. (unter Beachtung der Verträglichkeitsbedingungen)
Quelle: Hausotter, A.: Datenorganisation, in Wirtschaftsinformatik,
Fachbuchverlag Leipzig
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
37
Relationenenalgebra
§ Mengentheoretische Operatoren
- Vereinigung ∪
- Durchschnitt ∩
- Kartesisches Produkt x
§ Relationale Operatoren
- Selektion σP (R) – zeilenweise Teilmenge der Relation R, enthält
alle Tupel die das Selektionsprädikat P erfüllen
- Projektion πAttributsliste (R) – spaltenweise Teilmenge der Relation
R, mit den in der Attributsliste spezifizierten Attributen
- Verbund ⋈ - Verknüpfung zweier Relationen über Attribute mit
übereinstimmenden Domains
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
38
Relationenenalgebra
Begriff der Menge
Eine Menge als Zusammenfassung von bestimmten wohl
unterschiedenen Objekten zu einem Ganzen ist ein fundamentaler
Begriff in der Mathematik:
A = {a1, a2, a3, …an}
ai – Elemente d. Menge A à a2 ∈ A
In der Menge spielt die Reihenfolge der Elemente keine Rolle, es gibt
keine Wiederholung der Elemente
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
39
Relationenenalgebra
Vereinigung, Durchschnitt, Differenz
§ Gegeben seien zwei Mengen A und B. Ein Element x gehört genau
dann zur Vereinigung A ∪ B (gelesen: „A vereinigt mit B“), wenn x ∈ A
oder x ∈ B.
§ Gegeben seien zwei Mengen A und B. Ein Element x gehört genau
dann zum Durchschnitt A ∩ B (gelesen: „A geschnitten mit B“), wenn
x ∈ A und x ∈ B.
§ Gegeben seien zwei Mengen A und B. Ein Element x gehört genau
dann zur Differenz A \ B (gelesen: „A ohne B“), wenn x ∈ A und x ∉ B.
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
40
Relationenenalgebra
Kartesisches Produkt
Seien a und b beliebige Elemente. Dann bezeichnet (a,b) ein
geordnetes Paar, bestehend aus erster und zweiter Koordinate.
Das kartesische Produkt (Kreuzprodukt) zweier Mengen A und B ist
die Menge aller geordneten Paare, deren erste Koordinate ein
Element von A und deren zweite Koordinate Element von B ist.
A x B {(a,b) | a ∈ A und b ∈ B}
Beispiel:
A = {Peter, Heiner, Gerd}
B = {Wernigerode, Magdeburg}
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
41
Relationenenalgebra
Begriff der Relation
Eine Relation zwischen zwei Mengen A und B ist eine Teilmenge R
des kartesischen Produkts der beiden Mengen:
R⊆AxB
ist eine zweistellige Relation, da zwei Mengen bei der Bildung
beteiligt sind
Beispiel:
R⊆AxB={
(Peter, Wernigerode),
(Heiner, Magdburg),
(Gerd, Magdeburg)
}
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
42
Konzeptioneller und
logischer Entwurf
ER-Modellierung unter
Verwendung des
Freeware DatenbankDesigners der
Hochschule Harz
Copyright by
Dipl. Ing. Dipl. Inf.
Michael Wilhelm
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
43
Wichtige SQL-Kommandos DDL
§ CREATE (DROP) SCHEMA – Definition (Entfernen) eines DB-Schemas
§ CREATE (DROP) DOMAIN - Definition (Entfernen) eines Datentyps
§ CRATE (DROP) TABLE - Definition (Entfernen) einer Basistabelle
§ CREATE (DROP) VIEW - Definition (Entfernen) einer View
§ ALTER TABLE – Umstrukturieren einer Basistabelle
§ GRANT, REVOKE – Vergabe und Entzug von Zugriffsrechten
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
44
Wichtige SQL-Kommandos DML
§ SELECT FROM WHERE– Datenbankabfrage
§ INSERT INTO – Einfügen von Zeilen
§ DELETE FROM – Löschen von Zeilen
§ TRUNCATE TABLE – Löschen aller Datensätze
§ UPDATE – Aktualisieren von Zeilen
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
45
Beispiel von Relationen I
CREATE TABLE "KONTO"
(
"KTO_NR"
INTEGER NOT NULL,
"K_NR"
VARCHAR(5) NOT NULL,
"KTO_STAND"
FLOAT,
CONSTRAINT "PK_KONTO" PRIMARY KEY ("KTO_NR")
CONSTRAINT "FK_KONTO_1"
FOREIGN KEY ("K_NR") REFERENCES "KUNDE" ("K_NR")
);
Relation KONTO à
WS07/08 – DBS Part 3
KTO_NR
K_NR
1234
K2
344,49
2345
K4
-12,34
2867
K1
2000,45
4456
K5
23,45
3322
K2
-66,50
2222
K4
22,30
Prof. Dr. Andreas Schmietendorf
KTO_STAND
46
Beispiel von Relationen II
CREATE TABLE "KUNDE"
(
"K_NR"
VARCHAR(5) NOT NULL,
"NAME"
VARCHAR(10),
"VORNAME" CHAR(10),
"GEB_DAT"
DATE,
CONSTRAINT "PK_KUNDE" PRIMARY KEY ("K_NR")
);
Relation KUNDE à
WS07/08 – DBS Part 3
K_NR
NAME
VORNAME
GEB_DAT
K2
Meier
Axel
02.11.1976
K4
Müller
Peter
30.06.1922
K3
Schulz
Heiner
23.12.1945
K1
Lehmann
Susanne
05.05.1980
K5
Schmidt
Uwe
02.09.1978
K6
Schuster
Uta
30.03.1966
Prof. Dr. Andreas Schmietendorf
47
Beispiel von Relationen III
KTO_NR
K_NR
1234
K2
344,49
2345
K4
-12,34
2867
K1
2000,45
4456
K5
23,45
3322
K2
-66,50
2222
K4
22,30
Relation KUNDE à
WS07/08 – DBS Part 3
KTO_STAND
ß Relation KONTO
K_NR
NAME
VORNAME
GEB_DAT
K2
Meier
Axel
02.11.1976
K4
Müller
Peter
30.06.1922
K3
Schulz
Heiner
23.12.1945
K1
Lehmann
Susanne
05.05.1980
K5
Schmidt
Uwe
02.09.1978
K6
Schuster
Uta
30.03.1966
Prof. Dr. Andreas Schmietendorf
48
Selektion
§ σKTO_STAND<0 (KONTO)
§ Auswahl von Konten mit negativen Kontostand
§ Deskriptive Anfrage mittels SQL:
SELECT KTO_NR, K_NR, KTO_STAND
FROM KONTO
WHERE KTO_STAND < 0
§ Ergebnis:
WS07/08 – DBS Part 3
KTO_NR
K_NR
2345
K4
-12,34
3322
K2
-66,50
Prof. Dr. Andreas Schmietendorf
KTO_STAND
49
Projektion
§ πK_NR (KONTO)
§ Auswahl der Spalte mit den Kundennummern
§ Deskriptive Anfrage mittels SQL:
SELECT DISTINCT K_NR
FROM KONTO
§ Ergebnis:
K_NR
K2
K4
K1
K5
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
50
Natürlicher Verbund
§ KONTO ⋈KONTO.K_NR=KUNDE.K_NR KUNDE
§ Deskriptive Anfrage mittels SQL:
SELECT KTO_NR, KUNDE.K_NR, KTO_STAND, NAME
FROM KONTO, KUNDE
WHERE KONTO.K_NR = KUNDE.K_NR
§ Ergebnis:
KTO_NR
WS07/08 – DBS Part 3
K_NR
KTO_STAND
NAME
1234
K2
344,49
Meier
2345
K4
-12,34
Müller
2867
K1
2000,45
4456
K5
23,45
3322
K2
-66,50
Meier
2222
K4
22,30
Müller
Prof. Dr. Andreas Schmietendorf
Lehmann
Schmidt
51
Anfrageoperationen auf Tabellen
§ Selektion σ (Sigma) - Zeilen einer Tabelle auswählen
§ Projektion π - Spalten einer Tabelle auswählen
§ Verbundoperationen |X| - Verbindungen von Tabellen bzw. Views
§ Umbenennung β - Umbenennung von Attributsnamen
§ Mengenoperationen (z.B. Vereinigung, Differenz und Durchschnitt)
WS07/08 – DBS Part 3
Prof. Dr. Andreas Schmietendorf
52