Get documents about "A III - III Betrieblicher Einsat
Shared by: pengxiang
-
Stats
- views:
- 26
- posted:
- 6/27/2010
- language:
- German
- pages:
- 60
Document Sample
A III. Datenbanksysteme
und Modellierung
Datenbanken als Basis betrieblicher
Informationssysteme
Datenmodellierung - Konzepte und
Methoden
Aufbau und Anwendung relationaler
Datenbanksystem
A III. - 1
Einsatz von Datenbanksystemen:
Motivation und Ziele
Daten und Informationen als Grundlage
betrieblicher Entscheidungs- und
Führungsprozesse
» Daten für Markt- und Wettbewerbsanalysen
» Daten zur Abweichungsanalysen mit dem Ziel der
Planung, Steuerung und Kontrolle
» Kennzahlen in einem Führungsinformationssystem
Daten als Grundlage der operativen
Massenverarbeitung, z.B.
» Daten für die Fakturierung
» Daten für die Erstellung des Jahresabschlusses
A III. - 2
Warum DV-gestützte
Datenverwaltung?
Beispiel Verwaltung eines
Studentensekretariats:
notwendige Informationen wie
beispielsweise Name, Studienrichtung,
Alter, Krankenversicherung usw. lassen
sich auch mit einem Karteikasten verwalten
Problem der “Karteikastenorganisation”
A III. - 3
Traditionelle Dateiverarbeitung
Vorläufer der heutigen Datenbanktechnik
war die traditionelle Dateiverarbeitung
» Anwendungsprogramme greifen auf
Dateien zu, in denen die zu
verarbeitenden Daten enthalten sind
» Datenverwaltung wird vollständig im
Rahmen der Anwendungsprogramme
durchgeführt, beispw. Einfügen, Löschen
oder Ändern von Daten,
Speicherverwaltung etc.
A III. - 4
Phasen des Datenbankentwurfs
Grobe Vorgehensweise beim
Datenbankentwurf
» Informationsbedarfsanalyse:
– Ermittlung, welche Informationen für die zu erfüllende
Fachaufgabe relevant und in der Datenbank abzubilden sind
» Entwurf des konzeptuellen Schemas:
– formalisierte Beschreibung der relevanten Informationen
unabhängig vom Datenbankmodell und -system
» Entwurf des logischen Schemas:
– Transformation des konzeptuellen Schemas in das
vorliegende Datenbankmodell
A III. - 5
Grundlagen der
Datenmodellierung
• Vorab allgemeine Definitionen:
• Daten: Standardisierte Repräsentanten realer oder
fiktiver Sachverhalte.
• Modell: Zeitpunktbezogenes Abbild eines
Realitätsausschnittes. Ein Modell kann nicht die
ganze Realität abbilden. Von Details, die für den
Zweck des Modells unrelevant erscheinen, wird
abstrahiert.
A III. - 6
Grundlagen der
Datenmodellierung
• Darstellung/Beschreibung der relevanten Daten
eines Unternehmens
• aus Unternehmensgesamtsicht
• unabhängig vom verwendeten Datenbanksystem bzw.
Datenmodell
• unabhängig von der externen Sicht und von spezifischen
Anwendungen
• Datenmodelle beschreiben
anwendungsübergreifend
• Objekte und ihre Eigenschaften auf der Basis von
Fachbegriffen
• die Beziehungen zwischen diesen Fachbegriffen
A III. - 7
Ziele der Datenmodellierung
• Datenmodelle haben das Ziel, die
Informationsverarbeitung einer Unternehmung in bezug
auf ihre Informationsobjekte verbindlich zu regeln,
um
• Zusammenhänge im Unternehmen besser zu verstehen
• den Informationsaustausch zu verbessern durch eine
standardisierte Kommunikationsbasis
• mehrere Bedeutungen eines Begriffs: zum Beispiel Ertrag,
Erfolg, Gewinn, Umsatz etc.
• Synomyme: "Rechnung" und "Offener Posten"
A III. - 8
Ziele der Datenmodellierung
•Aber: "Kulturelle Probleme" bei der
Durchsetzung einer standardisierten
Kommunikationsbasis!
• eine Basis für die Anwendungsentwicklung sowie das
Datenbankdesign zu schaffen, die sich an dem
generierten Datenmodell orientieren.
A III. - 9
Methoden der Datenmodellierung
• Entity Relationship Model (ERM) basiert auf einer
Entwicklung von Chen
• ERM ist die wohl bekannteste und auch in der Praxis am
häufigsten verwendete Methode zur Datenmodellierung
• Abbildung eines Realitätsausschnittes mittels eines ERM
basiert auf folgenden Elementen
• Entity (Entität)
• Relationsship (Beziehung)
• Property (Attribut, Eigenschaft)
A III. - 10
Entity, Beziehung
• Entity
• Definition: "a thing which can be distinctly identified"
(reales Objekt, abstraktes Konzept, Ereignis)
• Beispiele: Mitarbeiter, Abteilung, Produkt, Vorlesung
DWM, Konzertbesuch usw.
• Beziehung
• Definition: "an association among entities"
• Beispiele: Bestellung (Entity: Produkt, Kunde)
A III. - 11
Attribut
• Attribut
• Definition: Eigenschaft, die ein Entity oder eine
Beziehung beschreibt
• Beispiele: Alter einer Person, Professor einer
Vorlesung, Orchester oder Gruppe eines Konzerts
A III. - 12
Kardinalitäten des ERM nach Chen
• 1:1-Beziehungstyp
• 1:n-Beziehungstyp
• n:m-Beziehungstyp
A III. - 13
Übertragung eines ERM in Tabellen
• 1:n-Beziehung
Mitarbeiter Abteilung
Pers_nr Nachname Vorname Geschlecht Strasse PLZ Wohnort BLZ Abt_Nr Gehalt Position Abt_Nr Bezeichnung
13 Heilmann Wolfgang 1 Holzgasse 25 6000 Frankfurt 61000000 1 5890 Techniker 1 Verkauf/Industrie
45 Schmidt Maria 2 Südring 105 6000 Frankfurt 42000000 4 3460 Kundenbetreuer
34 Gerber Klaus 1 Jägerstr. 46 6000 Frankfurt 35090000 2 4500 Kundenbetreuer 2 Verkauf/Einzelhandel
76 Huber Michael 1 Am Hang 34 6200 Wiesbaden 51090000 3 3800 Kundenbetreuer
32 Müller Renate 2 Hauptstr. 123 6000 Frankfurt 78060000 5 6790 Rechnungswesen 3 Einkauf
66 Säcker Claudia 2 Leierweg 45 6050 Offenbach 24080000 6 4750 Rechnungswesen
15 Lindner Susanne 2 Am Weinberg 15 6200 Wiesbaden 61080000 3 2980 Kundenbetreuer 4 Wartung/Service
3 Reuß Matthias 1 Köhlerstr. 31 6500 Mainz 54000000 4 6300 Kundenbetreuer
19 Hermann Horst 1 Frankfurter Str. 102 6050 Offenbach 24080000 2 5630 Rechnungswesen 5 Elektrowerkstatt
28 Anders Otto 1 Karlstr. 1 6000 Frankfurt 42000000 1 4680 Rechnungswesen
6 Buchhaltung
47 Kilb Richard 1 Obergasse 67 6200 Wiesbaden 45060000 1 3750 Kundenbetreuer
30 Reuter Dirk 1 Lichtener Str. 72 6500 Mainz 12076000 5 6210 Techniker
89 Langer Anneliese 2 Felsenstr. 32 6000 Frankfurt 78060000 4 3490 Techniker
76 Tiersch Jörg 1 Klosterstr. 29 6000 Frankfurt 35090000 3 2790 Rechnungswesen
86 Neumann Jürgen 1 Mainstr. 12 6000 Frankfurt 61000000 4 3750 Kundenbetreuer
23 Jacob Eva 2 Mittlere Str. 98 6200 Wiesbaden 51090000 2 6580 Kundenbetreuer
51 Wagner Stefan 1 Gutenaustr. 45 6500 Mainz 54000000 3 5640 Rechnungswesen
79 Silcher Angela 2 Heilegenstr. 82 6000 Frankfurt 42000000 6 4900 Kundenbetreuer
A III. - 14
Übertragung eines ERM in Tabellen
• n:m-Beziehung
Kunde
Kunden-Nr. Name PLZ Ort BLZ Bankname Konto
3 Hewlett Packard 65432 Frankfurt 51000000 Deutsche Bank 5378405
5 IBM 62374 Frankfurt 62000000 Nassauische Sparkasse 93994
8 Siemens 63271 Frankfurt 36000000 Dresdner Bank 9969974
Artikel Kauft
Art_Nr Bezeichnung Kunden-Nr Art_Nr
02 Druckerpatrone schwarz 3 02
24 Druckerpapier DIN A4 weiss 3 24
25 Druckerpapier DIN A3 weiss 5 24
36 Kopierpapier DIN A4 weiss 5 36
39 Kopierpapier DIN A5 gelb 5 51
51 Disketten 1.4 MB 8 02
8 24
8 36
A III. - 15
Grundlagen relationaler
Datenbanksysteme
• Entwicklung von Codd [Codd 70]
• Daten werden in Tabellen (=Relationen) dargestellt
• Tabelle besteht aus
• Name der Tabelle
• Menge von Datensätzen (=Tupel)
• Menge von Attributen; die Wertebereiche dieser
Attribute werden als Domänen bezeichnet
A III. - 16
Beispiel: Relation Kunde
Kunden- Name Strasse PLZ Wohnort Kontonr BLZ Rabatt
nummer (%)
25 Honeywell Friedenstr. 34 5450 Neuwied 739495 45090000 20
64 IBM Kaiser-Ring 10 6500 Mainz 94588324 35070000 10
35 Müller AG Waldstr. 123 6200 Wiesbaden 5632734 51090000 20
46 Epson Rheinstr. 73 6000 Frankfurt 63744 61000000 10
66 Schmidt KG Sonnenstr. 243 6000 Frankfurt 8377402 87000000 15
67 Kühne&Nagel Industriestr. 12 6200 Wiesbaden 748288 51090000 10
99 Köbig Flachstr. 45 6500 Mainz 8474700 47700000 12
A III. - 17
Spezieller Attributtyp: Schlüssel
• Primärschlüssel (Primary Key):
Attribut mit eindeutig identifizierender Eigenschaft; kann
sich aus einem oder mehreren Attributen
zusammensetzen. In unserem Beispiel ist die
Kundennummer Primärschlüssel der Relation Kunde
(Kennzeichnung durch Unterstreichung).
• Sekundärschlüssel (Secondary Key):
jedes beliebige Attribut, das nicht Primärschlüssel ist und
klassifizierende Eigenschaften haben kann.
A III. - 18
Spezieller Attributtyp: Schlüssel
• Schlüsselkandidat (Candidate Key):
Attribut, das nicht als Primärschlüssel verwendet wird,
diese Funktion aber übernehmen könnte
• Fremdschlüssel (Foreign Key):
Ein Attribut einer Relation B wird als Fremdschlüssel
bezeichnet, wenn es nicht Primärschlüssel von B ist,
aber Primärschlüssel der Relation A ist.
A III. - 19
Beispiel: Fremdschlüssel BLZ
in Relation KUNDE
KUNDE
Kunden-Nr. Name PLZ Ort BLZ Konto
3 Hewlett Packard 65432 Frankfurt 51000000 5378405
5 IBM 62374 Frankfurt 62000000 93994
8 Siemens 63271 Frankfurt 36000000 9969974
BLZ Bankname
BANK 36000000 Dresdner Bank
51000000 Deutsche Bank
62000000 Nassauische Sparkasse
A III. - 20
Beispiel für einen Datenbankentwurf
Tabelle: KUNDE
KNr Firma Straße Postleitzahl Ort Status
Tabelle: AUFTRAG
ANr KNr ADatum LDatum
Tabelle: BESTELLT
ANr PNr Menge VPreis
Tabelle: PRODUKT
PNr Bezeichnung Preis
Tabelle: LAGER
PNr Ort Menge
A III. - 21
Normalisierung von Relationen
• Ziele der Normalisierung
• Integritätssicherung
• Redundanzfreie Speicherung
• "lesbare" Relationen generieren
Normalisierung wird durch Zerlegung von
Relationen erreicht.
A III. - 22
Normalisierung von Relationen
• im folgenden: Demonstration des Prozesses der
Normalisierung anhand eines Beispiels
• Die Tabelle zur Darstellung von Lieferanten einer
Unternehmung sei nun durch folgende Attribute
beschrieben.
• Lieferant (Lieferanten#, Lieferantenname, Straße, PLZ,
Wohnort, Kontonummer, BLZ, Bank, Teilenummern,
Teilenamen)
A III. - 23
Die 1. Normalform (1NF)
Eine Relation befindet sich in 1. Normalform (1NF),
wenn alle Attributwerte atomar sind.
• Bedingung erfüllt?
• Lösungsmöglichkeiten
A III. - 24
Zerlegung der Relation
• Überführung der Relation in 1NF durch Zerlegung der
Relation LIEFERANT in zwei Relationen
Relation Lieferant (Lieferanten#, Lieferantenname,
Straße, PLZ, Wohnort, Kontonummer, BLZ, Bank).
Relation Lieferung (Lieferanten#, Teil#, Teilname,Menge,
Datum)
• Diese Relationen genügen der ersten Normalform
(1NF).
A III. - 25
Die 2. Normalform (2NF)
Eine Relation befindet sich in der zweiten
Normalform, wenn sie sich in 1NF befindet und jedes
Attribut vom gesamten Primärschlüssel (und nicht nur
von Teilen des Primärschlüssels) voll funktional
abhängig ist.
• Bedingung erfüllt?
A III. - 26
Weitere Zerlegung der Relation
• Es ist also eine dritte Relation TEILE einzuführen. Das
Relationenschema hat nun folgendes Aussehen und
befindet sich in 2NF:
Relation Lieferant (Lieferanten#, Lieferantenname,
Strasse, PLZ, Wohnort, Kontonummer, BLZ, Bank).
Relation Lieferung (Lieferanten#, Teil#, Menge,
Datum).
Relation Teile (Teil#, Teilname).
A III. - 27
Die 3. Normalform (3NF)
Ein Relationenschema befindet sich in der dritten
Normalform (3NF), wenn es sich in 2NF befindet und
zudem keine transitiven Abhängigkeiten aufweist.
• Unter transitiver Abhängigkeit versteht man die funktionale
Abhängigkeit eines Nicht-Schlüsselattributes einer Relation R
von einem anderen Nicht-Schlüsselattribut in R.
• Eine solche funktionale Abhängigkeit besteht in der Relation
LIEFERANT bezüglich BLZ => Bank. Da BLZ nicht
Primärschlüssel der Relation LIEFERANT ist, handelt es sich um
eine transitive Abhängigkeit.
A III. - 28
Ergebnis:Relationsschema in 3NF
• Wir erhalten nun folgendes Relationenschema, das in
3NF vorliegt:
Relation Lieferant (Lieferanten#, Lieferantenname, Strasse, PLZ,
Kontonummer, BLZ).
Relation Lieferung (Lieferanten#, Teil#,Menge, Datum).
Relation Teile (Teil#, Teilname).
Relation Bank (BLZ, Bankname)
Relation Ort (PLZ, Wohnort)
A III. - 29
Beurteilung der Normalisierung
• Vorteile der Normalisierung
• Redundanzfreie Speicherung,
d.h. jedes Faktum ist nur einmal in der Datenbank
gespeichert
• Sicherung der Integrität:
Integrität bedeutet, daß keine sich widersprechenden
Fakten in der Datenbank gespeichert sind.
A III. - 30
Beurteilung der Normalisierung
• Nachteile der Normalisierung
• Normalisierungsaufwand
• Schlechteres Laufzeitverhalten bei der
Zusammenfügung (Join) mehrerer Relationen
• beim Datenbankentwurf sind somit die "Kosten" und
"Nutzen" der Normalisierung abzuwägen
• Normalisierung bis 3NF (oder weniger!) ist in der Regel
ausreichend
A III. - 31
Datenmanagement auf der Basis
der relationalen Sprache SQL
• SQL (Structured Query Language) ist die
Standardsprache für relationale Datenbanken
• Normierung von SQL durch ISO und ANSI
• bildet die Basis aller gängigen relationalen
Datenbanksysteme
A III. - 32
Die relationale Sprache SQL
SQL als
• Data Definiton Language:
Anlegen von Tabellen/Relationen
• Data Manipulation Language:
Ändern der Daten in Tabellen/Relationen
• Query Language:
Generierung von Abfragen zur Extraktion von
Daten aus einer oder mehreren
Tabellen/Relationen
A III. - 33
SQL als Data Definition Language
• Aufgabe der Data Definition Language (DDL; synonym:
Data Description Language): Generierung des
intensionalen Relationenschemas
• SQL als DDL beinhaltet drei grundlegende Befehle
• Anlegen einer Relation (create)
• Ändern des Schemas einer Relation (alter)
• Löschen einer Relation (drop)
A III. - 34
Anlegen einer Relation
• SQL-Befehl zum Anlegen des intensionalen Schemas einer
Relation:
CREATE TABLE <tablename>
(<attributname_1> <datentyp_1>, <attributname_2>
<datentyp_2>, ...<attributname_n> <datentyp_n>);
• Beispiel: Anlegen einer Relation Auftrag, die aus den Attributen
Auftragsnummer, Kundennummer, Datum und Mitarbeiternummer
des Kundenbetreuers besteht:
CREATE TABLE AUFTRAG
(auftrags_no number(4) not null,
kunden_no number(4),
datum date,
mitarbeiter_no number(4));
A III. - 35
Allgemeine Datentypen
• number (x) = ganzzahliger numerischer x-
stelliger Wert
• number (x,y) = numerischer Wert mit x-y Vorkomma-
und y Nachkommastellen
• char(x) = alphanumerische Zeichenkette mit x
Zeichen
• date = Datum
A III. - 36
SQL als Data Manipulation Language
• SQL als DML dient der Veränderung der extensionalen Datensicht
und beinhaltet drei grundlegende Befehle:
Einfügen von Tupeln (insert)
insert into <tablename> values (<wert_1>,
<wert_2>, ..., <wert_n>);
Ändern von Tupeln (update)
update <tablename> set <attributsname> =
<arithmetischer Ausdruck>
Löschen von Tupeln (delete)
delete from <tablename> where <bedingung>
A III. - 37
Beispiele für SQL-Befehle:
Anlegen einer Tabelle
• Anlegen einer Tabelle Mitarbeiter mit den Attributen
Mitarbeiter
M_Nr number (3) M_Nr Name Abt_Nr Gehalt Geschlecht
Name char (20)
Abt_Nr number (3)
Gehalt number (5)
Geschlecht char (10)
• SQL> create table Mitarbeiter (M_Nr number (3),
Name char (20), Abt_Nr number (3), Gehalt number
(5), Geschlecht char (10))
A III. - 38
Beispiele für SQL-Befehle:
Einfügen von Datensätzen
insert into mitarbeiter values (1, “Müller”, 1,
2500, “männlich”)
M_Nr Name Abt_NR Gehalt Geschlecht
1 Müller 1 2500 männlich
Weitere Datensätze einfügen...
M_Nr Name Abt_NR Gehalt Geschlecht
1 Müller 1 2500 männlich
2 Schulz 1 3500 weiblich
3 Maier 3 4000 männlich
4 Fischer 3 3500 weiblich
5 König 7 3900 weiblich
A III. - 39
Beispiele für SQL-Befehle:
Ändern von Tabellen
Beispiel 1: Alle Mitarbeiter bekommen von jetzt an 1 Prozent mehr
Gehalt
SQL>update mitarbeiter set gehalt = gehalt*1,01
Ergebnis:
M_Nr Name Abt_NR Gehalt Geschlecht
1 Müller 1 2525 männlich
2 Schulz 1 3535 weiblich
3 Maier 3 4040 männlich
4 Fischer 3 3535 weiblich
5 König 7 3939 weiblich
A III. - 40
Beispiele für SQL-Befehle:
Ändern von Tabellen
Beispiel 2: Alle Mitarbeiter der Abteilung 1 bekommen 10 Prozent
mehr Gehalt
SQL>update mitarbeiter set gehalt = gehalt*1,1
where Abt_Nr=1
Ergebnis:
M_Nr Name Abt_NR Gehalt Geschlecht
1 Müller 1 2750 männlich
2 Schulz 1 3850 weiblich
3 Maier 3 4000 männlich
4 Fischer 3 3500 weiblich
5 König 7 3900 weiblich
A III. - 41
Beispiele für SQL-Befehle:
Ändern von Tabellen
Beispiel 3: Alle Mitarbeiter der Abteilung 1, die weiblich sind,
bekommen 100 DM mehr Gehalt
SQL>update mitarbeiter set gehalt = gehalt + 100
where Abt_Nr=1 and Geschlecht="weiblich"
Ergebnis:
M_Nr Name Abt_NR Gehalt Geschlecht
1 Müller 1 2500 männlich
2 Schulz 1 3600 weiblich
3 Maier 3 4000 männlich
4 Fischer 3 3500 weiblich
5 König 7 3900 weiblich
A III. - 42
Beispiele für SQL-Befehle:
Löschen von Datensätzen
Beispiel: Abteilung 1 wird geschlossen und keiner der Mitarbeiter wird
weiterbeschäftigt
SQL>delete from mitarbeiter where Abt_Nr=1
Ergebnis:
M_Nr Name Abt_NR Gehalt Geschlecht
3 Maier 3 4000 männlich
4 Fischer 3 3500 weiblich
5 König 7 3900 weiblich
A III. - 43
Spezielle Zusätze für Datentypen zur
Integritätssicherung
• not null => Attribut muß für jeden Tupel einen
Wert haben
• unique => Attribut darf für verschiedenen Tupel
keine identischen Werte haben
• primary key => not null und unique
• references => sichert Integrität bei
Fremdschlüsselbeziehungen
• check => definiert Wertebereiche einer Domäne
A III. - 44
Beispiel
SQL> create table bankleitzahl (blz number(10)
primary key, bankname char (20));
SQL > create table mitarbeiter(
pers_nr number(5) primary key,
nachname char(20), vorname char(15),
geschlecht char(10), strasse char(20),
plz number(5), wohnort char(20),
blz number(10) references bankleitzahl,
abt_nr number(2), gehalt number(7)
check(gehalt between 2000 and 1000000));
A III. - 45
SQL als Query Language (QL)
• Query Language: Abfragesprache zur Extraktion von Daten bzw.
Informationen aus der Datenbank
=> Anwendung des Select-Befehls
• Einfachster Select-Befehl: Vollständige Anzeige aller Tupel einer
Relation
=> select * from <tablename>
A III. - 46
Beispiele für SQL-Befehle
• Beispiel: Anzeige der kompletten Relation Mitarbeiter
SQL > select * from mitarbeiter;
Mitarbeiter
Pers_nr Nachname Vorname Geschlecht Strasse PLZ Wohnort BLZ Abt_Nr Gehalt Position
13 Heilmann Wolfgang 1 Holzgasse 25 6000 Frankfurt 61000000 1 5890 Techniker
45 Schmidt Maria 2 Südring 105 6000 Frankfurt 42000000 4 3460 Kundenbetreuer
34 Gerber Klaus 1 Jägerstr. 46 6000 Frankfurt 35090000 2 4500 Kundenbetreuer
76 Huber Michael 1 Am Hang 34 6200 Wiesbaden 51090000 3 3800 Kundenbetreuer
32 Müller Renate 2 Hauptstr. 123 6000 Frankfurt 78060000 5 6790 Rechnungswesen
66 Säcker Claudia 2 Leierweg 45 6050 Offenbach 24080000 6 4750 Rechnungswesen
15 Lindner Susanne 2 Am Weinberg 15 6200 Wiesbaden 61080000 3 2980 Kundenbetreuer
3 Reuß Matthias 1 Köhlerstr. 31 6500 Mainz 54000000 4 6300 Kundenbetreuer
19 Hermann Horst 1 Frankfurter Str. 102 6050 Offenbach 24080000 2 5630 Rechnungswesen
28 Anders Otto 1 Karlstr. 1 6000 Frankfurt 42000000 1 4680 Rechnungswesen
47 Kilb Richard 1 Obergasse 67 6200 Wiesbaden 45060000 1 3750 Kundenbetreuer
30 Reuter Dirk 1 Lichtener Str. 72 6500 Mainz 12076000 5 6210 Techniker
89 Langer Anneliese 2 Felsenstr. 32 6000 Frankfurt 78060000 4 3490 Techniker
76 Tiersch Jörg 1 Klosterstr. 29 6000 Frankfurt 35090000 3 2790 Rechnungswesen
86 Neumann Jürgen 1 Mainstr. 12 6000 Frankfurt 61000000 4 3750 Kundenbetreuer
23 Jacob Eva 2 Mittlere Str. 98 6200 Wiesbaden 51090000 2 6580 Kundenbetreuer
51 Wagner Stefan 1 Gutenaustr. 45 6500 Mainz 54000000 3 5640 Rechnungswesen
79 Silcher Angela 2 Heilegenstr. 82 6000 Frankfurt 42000000 6 4900 Kundenbetreuer
A III. - 47
Selektionsoperatoren
• Select-Grundoperatoren
• Projektion
• Selektion
• Join
A III. - 48
Allgemeine Operatoren:
Projektion
• Projektion: generiert aus einer Relation B eine Relation A, indem
eine Teilmenge der Attribute der Relation B in A eingehen.
SQL> select <attributname_1>,
<attributname_2>,<attributname_n> from
<tablename>
• Beispiel: Auswahl der Attribute pers_nr, vorname, nachname und
gehalt aus der Relation Mitarbeiter
A III. - 49
Projektion
• SQL >select pers_nr, vorname, nachname, gehalt from
mitarbeiter; Pers_Nr. Vorname Nachname Gehalt
13 Wolfgang Heilmann 5890
45 Maria Schmidt 3460
34 Klaus Gerber 4500
76 Michael Huber 3800
32 Renate Müller 6790
66 Claudia Säcker 4750
15 Susanne Lindner 2980
3 Matthias Reuß 6300
19 Horst Hermann 5630
28 Otto Anders 4680
47 Richard Kilb 3750
30 Dirk Reuter 6210
89 Anneliese Langer 3490
76 Jörg Tiersch 2790
86 Jürgen Neumann 3750
23 Eva Jacob 6580
51 Stefan Wagner 5640
79 Angela Silcher 4900
• Werden durch eine Projektion mehrere identische Tupel
generiert, so sind die identischen Tupel nach der
relationenlehre zu entfernen. Diese Forderung wird von den
meisten relationalen Datenbanken jedoch nicht unterstützt.
A III. - 50
Projektion
• SQL> select position from MITARBEITER;
Position
Techniker
Kundenbetreuer
Kundenbetreuer
Kundenbetreuer
...
• Um wirklich nur die unterschiedlichen Berufe zu erhalten, ist
folgender SQL-Befehl auszuführen:
• SQL> select distinct(position) from MITARBEITER;
Position
Techniker
Kundenbetreuer
Rechnungswesen
A III. - 51
Selektion
• Selektion: generiert aus einer Relation B eine Relation A durch
Bildung einer Teilmenge der Tupel, die einer bestimmten
Bedingung genügen
SQL> select * from <tablename> where <bedingung>
• Beispiel: Auswahl aller Mitarbeiter der Abteilung 3
SQL >select * from mitarbeiter where abt_nr=3;
Pers_Nr Name Vorname Geschlecht Strasse PLZ Wohnort BLZ Abt_Nr Gehalt Position
76 Huber Michael 1 Am Hang 34 6200 Wiesbaden 51090000 3 3800 Kundenbetreuer
15 Lindner Susanne 2 Am Weinberg 15 6200 Wiesbaden 61080000 3 2980 Kundenbetreuer
76 Tiersch Jörg 1 Klosterstr. 29 6000 Frankfurt 30590000 3 2790 Rechnungswesen
51 Wagner Stefan 1 Gutenaustr. 45 6500 Mainz 54000000 3 5640 Rechnungswesen
A III. - 52
SQL: Logische und arithmetische
Operatoren
• SQL unterstützt die logischen Operatoren
and
or
not
• SQL unterstützt die arithmetischen Operatoren
=
>
<
>=
<=
!=
A III. - 53
Beispiele für die Anwendung logischer
und artithmetischer Operatoren
Auswahl aller Mitarbeiter, die in Abteilung 3 arbeiten und weiblich (geschlecht=2)
sind
SQL>select * from mitarbeiter where abt_nr=3 and
geschlecht=2;
Pers_Nr Name Vorname Geschlecht Strasse PLZ Wohnort BLZ Abt_Nr Gehalt Position
15 Lindner Susanne 2 Am Weinberg 15 6200 Wiesbaden 61080000 3 2980 Kundenbetreuer
Auswahl aller Mitarbeiter, die entweder in Abteilung 3 oder Abteilung 4
arbeiten
SQL>select * from mitarbeiter where abt_nr=3 or abt_nr=4;
Pers_Nr Nachname Vorname Geschlecht Strasse PLZ Wohnort BLZ Abt_Nr Gehalt Position
45 Schmidt Maria 2 Südring 105 6000 Frankfurt 42000000 4 3460 Kundenbetreuer
76 Huber Michael 1 Am Hang 34 6200 Wiesbaden 51090000 3 3800 Kundenbetreuer
15 Lindner Susanne 2 Am Weinberg 15 6200 Wiesbaden 61080000 3 2980 Kundenbetreuer
3 Reuß Matthias 1 Köhlerstr. 31 6500 Mainz 54000000 4 6300 Kundenbetreuer
89 Langer Anneliese 2 Felsenstr. 32 6000 Frankfurt 78060000 4 3490 Techniker
76 Tiersch Jörg 1 Klosterstr. 29 6000 Frankfurt 35090000 3 2790 Rechnungswesen
86 Neumann Jürgen 1 Mainstr. 12 6000 Frankfurt 61000000 4 3750 Kundenbetreuer
51 Wagner Stefan 1 Gutenaustr. 45 6500 Mainz 54000000 3 5640 Rechnungswesen
A III. - 54
Beispiele für die Anwendung logischer
und artithmetischer Operatoren
• Auswahl aller Mitarbeiter, die ein Gehalt zwischen 4000 und 5000
DM beziehen und weiblich sind, oder die ein Gehalt zwischen 5000
und 6000 DM beziehen und männlich sind
SQL>select * from mitarbeiter where (gehalt>4000
and gehalt<5000 and geschlecht=2) or (gehalt
between 5000 and 6000 and geschlecht=1);
Pers_Nr Nachname Vorname Geschlecht Strasse PLZ Wohnort BLZ Abt_Nr Gehalt Position
13 Heilmann Wolfgang 1 Holzgasse 25 6000 Frankfurt 61000000 1 5890 Techniker
66 Säcker Claudia 2 Leierweg 45 6050 Offenbach 24080000 6 4750 Rechnungswesen
19 Hermann Horst 1 Frankfurter Str. 102 6050 Offenbach 24080000 2 5630 Rechnungswesen
51 Wagner Stefan 1 Gutenaustr. 45 6500 Mainz 54000000 3 5640 Rechnungswesen
79 Silcher Angela 2 Heilegenstr. 82 6000 Frankfurt 42000000 6 4900 Kundenbetreuer
A III. - 55
Join
• Der Join-Operator verbindet zwei oder mehr Relationen über
Attribute zu einer neuen Relation.
• SQL>select <attributname_1>, <attributname_2>,
..., <attributname_n> from <tablename_1>,
<tablename_2>, ..., <tablename_m> where <Join-
Bedingung>
• Existieren in verschiedenen zu verbindenden Relationen Attribute
mit identischem Namen, ist diesen Attributen der Name der
zugehörigen Relation (gefolgt von einem Punkt) voranzustellen
(siehe folgendes Beispiel)
A III. - 56
Join
KUNDE
Kunden-Nr. Name PLZ Ort BLZ Konto
3 Hewlett Packard 65432 Frankfurt 51000000 5378405
5 IBM 62374 Frankfurt 62000000 93994
8 Siemens 63271 Frankfurt 36000000 9969974
BLZ Bankname
BANK 36000000 Dresdner Bank
51000000 Deutsche Bank
62000000 Nassauische Sparkasse
SQL >select Kunden-Nr., Name, PLZ, Ort, KUNDE.BLZ,
Konto, Bankname from KUNDE, BANK where
KUNDE.BLZ=BANK.BLZ
Kunden-Nr. Name PLZ Ort BLZ Bankname Konto
3 Hewlett Packard 65432 Frankfurt 51000000 Deutsche Bank 5378405
5 IBM 62374 Frankfurt 62000000 Nassauische Sparkasse 93994
8 Siemens 63271 Frankfurt 36000000 Dresdner Bank 9969974
A III. - 57
Join
Mitarbeiter
Pers_nr Nachname Vorname Strasse BLZ Konto_nr Abt_Nr
13 Heilmann Wolfgang Holzgasse 25 610 000 00 1837475 1
45 Schmidt Maria Südring 105 420 000 00 83849 4
34 Gerber Klaus Jägerstr. 46 350 900 00 378193 2
76 Huber Michael Am Hang 34 510 900 00 896843 3
32 Müller Renate Hauptstr. 123 780 600 00 47105 5
66 Säcker Claudia Leierweg 45 240 800 00 19384 6
15 Lindner Susanne Am Weinberg 15 610 800 00 782736 3
3 Reuss Matthias Köhlerstr. 31 540 000 00 2521 4
19 Hermann Horst Karlstr. 1 240 800 00 46784 2
28 Anders Otto Obergasse 67 420 000 00 3567834 1
Abteilung Bank
Abt_Nr Bezeichnung BLZ Bankname
1 Verkauf/Industrie 610 000 00 Deutsche Bank Frankfurt
2 Verkauf/Einzelhandel 420 000 00 Commerzbank
3 Einkauf 350 900 00 City Bank
4 Wartung/Service 510 900 00 Wiesbadener Volksbank
5 Elektrowerkstatt 780 600 00 Nassauische Sparkasse
6 Buchhaltung 240 800 00 Sparkasse Offenbach
610 800 00 Deutsche Bank Wiesbaden
540 000 00 Mainzer Sparkasse
450 600 00 Sparkasse Wiesbaden
120 760 00 Mainzer Volksbank
A III. - 58
Join
• SQL> select Pers_nr, Nachname, Vorname,
Mitarbeiter.Abt_nr, Bezeichnung, Konto_Nr,
Mitarbeiter.BLZ, Bankname from Mitarbeiter,
Abteilung, Bank where
Mitarbeiter.Abt_nr=Abteilung.Abt_nr and
Mitarbeiter.BLZ=Bank.BLZ
Pers_nr Nachname Vorname Abt_Nr Bezeichnung Konto_Nr BLZ Bankname
13 Heilmann Wolfgang 1 Verkauf/Industrie 1837475 610 000 00 Dt. Bank Fft
45 Schmidt Maria 4 Wartung/Service 83849 420 000 00 Commerzbank
34 Gerber Klaus 2 Verkauf/Einzelhandel 378193 350 900 00 City Bank
76 Huber Michael 3 Einkauf 896843 510 900 00 Wiesbad. V.bank
32 Müller Renate 5 Elektrowerkstatt 47105 780 600 00 Nassauische Spk.
66 Säcker Claudia 6 Buchhaltung 19384 240 800 00 Spk. Offenbach
15 Lindner Susanne 3 Einkauf 782736 610 800 00 Dt. Bank Wiesb.
3 Reuss Matthias 4 Wartung/Service 2521 540 000 00 Mainzer Spk.
19 Hermann Horst 2 Verkauf/Einzelhandel 46784 240 800 00 Spk. Offenbach
28 Anders Otto 1 Verkauf/Industrie 3567834 420 000 00 Commerzbank
A III. - 59
Spezielle Operatoren
Sortieren von Datensätzen
• Am Ende des Select-Statements steht der Zusatz
=>order by <column> [desc];
• Beispiel: Absteigendes (durch den Zusatz “desc”) Sortieren der
Relation Kunde nach dem Namen:
• SQL> select * from kunde order by Kundenname desc;
Kunden_Nr Kundenname Strasse PLZ Ort
45 Siemens Niederstr. 92 6000 Frankfurt
84 Schott Glaswerke Mainzer Str. 106 6500 Mainz
92 Paul & Co Hirtenstr. 82 6000 Frankfurt
26 Müller KG Industriestr. 18 6200 Wiesbaden
10 Lufthansa AG Friedrichstr. 82 6000 Frankfurt
51 IBM Moselstr. 84 6000 Frankfurt
25 ESWE Kirchstr. 29 6200 Wiesbaden
73 Elster AG Steingartenstr. 27 6205 Mainz-Kastel
93 Daimler-Benz Sternstr. 20 6000 Frankfurt
A III. - 60
