Upload
alldrich-lehr
View
111
Download
1
Embed Size (px)
Citation preview
Datenbankanbindungen
Grundlagen von Datenbanken
Datenbankabfragen
Thomas Hödlmoser, ICP systems
DI Thomas Hödlmoser 2
Ziele dieser Schulung
• Was ist eine Datenbank• Nutzungsmöglichkeiten• Arten von Datenbanken• notwendige Hard- bzw.
Software• Planung von
Datenbankstrukturen• Daten-
abfragemöglichkeiten
DI Thomas Hödlmoser 3
Praktische Inhalte
• Planung und Aufbau einer Datenbankstruktur
• Erstellen von Datenbankabfragen
• Problemlösungen und Fragen????
DI Thomas Hödlmoser 4
Agenda
• Mittwoch: – Datenbanken allgemein– Datenbanktypen– Datenbankarchitekturen– Datenbank Aufbau und Organisation– Der Datenbankentwurf– Das relationale Datenmodell
• Donnerstag:– Praktische Übung Datenbankdesign und –erstellung– Datenbankabfragesprache SQL – Grundkomponenten– Datendefinition
DI Thomas Hödlmoser 5
Agenda
• Freitag:– Einfache SQL-Abfragen– Änderungen an Tabelleninhalten mittels SQL– Praktische Beispiele SQL
DI Thomas Hödlmoser 6
Datenbanken - allgemein
DI Thomas Hödlmoser 7
Warum Datenbanken?
• Herkömmliche Speicherung in Dateisystemen
DI Thomas Hödlmoser 8
Warum Datenbanken?
• Probleme:– Redundanzen
» Mehrfache Speicherung von Daten
– Inkonsistenzen» Gleichzeitige Änderung von Daten von mehreren Benutzern möglich
– Datenschutzprobleme» Zugriff auf Dateien kann nicht stark genug eingeschränkt werden
– Fehlende Datenunabhängigkeit» Verwalten der Daten nur durch entsprechende Software (z.B. Explorer)
DI Thomas Hödlmoser 9
Warum Datenbanken?
• Sinn der Datenbank:– Logische Datenunabhängigkeit– Physikalische Datenunabhängigkeit– Prozedurale und nichtprozedurale Schnittstellen– Effiziente Abarbeitung von Datenbankoperationen– Minimale Datenredundanz– Datenintegrität– Konkurrierender Datenzugriff– Datensicherheit– Datenschutz
DI Thomas Hödlmoser 10
Warum Datenbanken?
• Logische Datenunabhängigkeit
– Es existiert eine logische Struktur der Datenbank
– Jeder Benutzer sieht nur „seine“ relevanten Daten
DI Thomas Hödlmoser 11
Warum Datenbanken?
• physikalische Datenunabhängigkeit
– Unabhängigkeit zwischen logischer und physikalischer Struktur
– Änderung der physikalische Struktur möglich ohne die logische Struktur zu ändern
DI Thomas Hödlmoser 12
Warum Datenbanken?
• Prozedurale und nichtprozedurale Schnittstellen
– Unterscheidung Entwickler - Anwender
– Entwickler: Prozedurale Schnittstellen (C++, Java, Basic,…)
– Anwender: nichtprozedurale Schnittstellen (Anwendungssoftware)
DI Thomas Hödlmoser 13
Warum Datenbanken?
• Effiziente Abarbeitung der Datenbankoperationen
– Verarbeitungszeit eines „Jobs“ sehr wichtig (responsetime)
– Viele „Jobs“ müssen parallel ausgeführt werden (Internet)
– Optimale Nutzung der Prozessorleistung (AS/400)
DI Thomas Hödlmoser 14
Warum Datenbanken?
• Minimale Datenredundanz
– Reduktion des Speicherbedarfs
– Verwaltungsaufwand bei Datenänderung wird geringer
– Abhängig vom Datenbankdesign des Entwicklers
DI Thomas Hödlmoser 15
Warum Datenbanken?
• Datenintegrität
– Unsinnige Daten werden geprüft, und zurückgewiesen
– Standardplausibilitätsprüfungen (z.B. 30. Februar)
– Plausibilitätsprüfungen des Entwicklers (z.B. Jahrgang > 1890)
DI Thomas Hödlmoser 16
Warum Datenbanken?
• Konkurrierender Datenzugriff
– Viele gleichzeitige Zugriffe auf die gleichen Daten
– Datenbank muss Zugriffe richtig abarbeiten
Konto Nr. 1234 Kontostand EUR 10.000,--
Person 1 Abhebung EUR 5.000,-- Person 2 Abhebung EUR 5.000,--
Kontostand ?
DI Thomas Hödlmoser 17
Warum Datenbanken?
• Datensicherheit
– Herstellung des letzten konsistenten Datenstandes nach Ausfall von Hard od. Software
– Wiederhergestellter Datenstand muss verifizierbar sein (Buchungen)
DI Thomas Hödlmoser 18
Warum Datenbanken?
• Datenschutz
– Schutz gegen unerlaubten Zugriff (z.B. Mitarbeitergehälter)
– Zugriff kann auf spezielle Daten eingeschränkt werden
DI Thomas Hödlmoser 19
Datenbanktypen
DI Thomas Hödlmoser 20
Datenbanktypen
• Übergang Dateisystem - Datenbank– Speicher auf Magnetplatten (60er Jahre)– 1. Datenbanksysteme (70er Jahre)
• Hierarchisches Datenbankmodell• Netzwerkdatenbanken• Relationale Datenbanken• Objektorientierte Datenbanken
DI Thomas Hödlmoser 21
Datenbanktypen
• Hierarchisches Datenbankmodell (Vater-Sohn Darstellung)
K unde A
B este llung A 1 B este llung A 2 B este llung A 3
P o sten A 11 P o sten A 11 P o sten A 21 P o sten A 31 P o sten A 32 P o sten A 33
– Für jeden Knoten (Kunde, Bestellung, Posten) 1 Datensatz– Redundante Datendarstellung
DI Thomas Hödlmoser 22
Datenbanktypen
• Netzwerkdatenbanken
A bteilung A
M itarbeiter 1
M itarbeiter 2
M itarbeiter 3
M itarbeiter 1 - P ro jekt G W
P ro jekt M E
P ro jektX Y
P ro jekt G W
P ro jekt S T
M itarbeiter 1 - P ro jekt X Y
M itarbeiter 2 - P ro jekt X Y
M itarbeiter 3 - P ro jekt X Y
M itarbeiter 3 - P ro jekt M E
M itarbeiter 3 - P ro jekt S T
DI Thomas Hödlmoser 23
Datenbanktypen
• Relationale Datenbanken
A bte ilung P ro jektM itarbe iterbeschäf tig t arbeite t an1 n n m
– Beziehungen werden benannt und im ER –Diagramm dargestellt
– Beziehungen wird Kardinalität zugeordnet (1:n; n:m,…)
DI Thomas Hödlmoser 24
Datenbanktypen
• objektorientierte Datenbanken OODB
– Objekt-Klassen enthalten Attribute, Beziehungen und Methoden
– Dzt. Unterstützen nur wenige Datenbanksysteme OODB
Klasse Abteilung
// A ttributeN am eN r.
//B eziehungenbeschäf tig t < M itarbeiter>
//M ethodenum benennen()neuerM itarbeiter()
Klasse Mitarbeiter
// A ttributeN am eW o hno rt
//B eziehungenarbeitet_ in <A bteilung>arbeitet_an <P ro jekt>
//M ethodenabteilungswechsel()entlassen()
Klasse Projekt
// A ttributeN am eB eschreibung
//B eziehungenbearbeite t_vo n <M itarbeiter>
//M ethodenerzeugen()abschliessen()
beschäf tig tarbeitet_ in
arbeitet_anbearbeite t_vo n
DI Thomas Hödlmoser 25
Datenbankstruktur
DI Thomas Hödlmoser 26
Datenbankstruktur
• Zentralisierte Datenbanksysteme
• Verteilte Datenbanksysteme
• Client-Server Datenbanken
• Parallele Datenbanken
DI Thomas Hödlmoser 27
Datenbankstruktur
• Zentralisierte Datenbanksysteme
Zentralrechner
K no ten 1 K no ten 2 K no ten 3 K no ten 4
N etzwerkA nwendung
D atenbank
D aten
- Zentralrechner übernimmt alle Aufgaben
- „dumme“ Terminals
- Einfache Administration
DI Thomas Hödlmoser 28
Datenbankstruktur
• Verteilte Datenbanksysteme
- Logisch zusammengehörige Teildatenbanken
- Datenbanksystem kümmert sich um das Zusammenführen der Daten
- Geographische Trennung möglich (Filialen)
K no ten 1
A nwendung
D atenbank
D aten
K no ten 2
A nwendung
D atenbank
D aten
K no ten 3
A nwendung
D atenbank
D aten
K no ten4
A nwendung
D atenbank
D aten
N etzwerk
DI Thomas Hödlmoser 29
Datenbankstruktur
• Vorteile verteilter Datenbanksysteme
- Lokale Autonomie (Daten sind gespeichert wo sie benötigt werden)
- Zuverlässigkeit und Verfügbarkeit (erhöht durch Redundanz)
- Leistung (Parallelarbeit, geringerer Netzwerkverkehr)
- Erweiterbarkeit (Hinzufügen neuer Knoten)
DI Thomas Hödlmoser 30
Datenbankstruktur
• Nachteile verteilter Datenbanksysteme
- Mangel an praktischen Erfahrungen (selten eingesetzt)
- Komplexität (Synchronisation, Replikation,..)
- Dezentrale Verwaltung (erhöhter Verwaltungsaufwand)
- Sicherheit ist komplizierter zu realisieren
- Kosten für Software und Hardware
DI Thomas Hödlmoser 31
Datenbankstruktur
• Client – Server Datenbanken
- Datenbankabfragen und Anzeigeprogramme sind getrennt
- Client und Serverprogramme können auf einen Rechner laufen
- definierte Abfragesprache zwischen Client und Server (SQL)
S erv er2. B earbeitung
2. B earbeitungClient 2
C lient 1
3. A ntwo rt
1. A nfo rderung
1. A nfo rderung3. A ntwo rt
DI Thomas Hödlmoser 32
Datenbankstruktur
• Parallele Datenbanksysteme
– Mehrere Prozessoren, Platten und Hauptspeicher
– Daten werden auf verfügbare Platten verteilt
– Datenbankabfragen werden zerlegt, und parallel abgearbeitet
DI Thomas Hödlmoser 33
Datenbankstruktur
• Parallele Datenbanksysteme
– Shared Memory Architektur (Shared Everything Architektur)
– Shared Nothing Architektur
– Shared Disk Architektur
DI Thomas Hödlmoser 34
Datenbankstruktur
Shared Memory Architektur (Shared Everything Architektur)
Prozessor 1 Prozessor 2 Speicher 1 Speicher 2
Platte 1 Platte 2 Platte x
Hochgeschwindigkeitsnetz
DI Thomas Hödlmoser 35
Datenbankstruktur
Shared Nothing Architektur
Prozessor 1 Prozessor 2
Speicher 1 Speicher 2
Platte 1 Platte 2
Prozessor n
Speicher n
Platte n
Hochgeschwindigkeitsnetz
DI Thomas Hödlmoser 36
Datenbankstruktur
Shared Disk Architektur
Prozessor 1 Prozessor 2
Speicher 1 Speicher 2
Platte 1 Platte 2
Prozessor n
Speicher n
Platte n
Hochgeschwindigkeitsnetz
DI Thomas Hödlmoser 37
Datenbankaufbau und Organisation
DI Thomas Hödlmoser 38
Datenbankaufbau
• Wichtigste Aufgaben des Datenbanksystems
– Trennung von Datenspeicher und Anwendungsprogrammen
– Logische Datenunabhängigkeit (logische Struktur)
– Physische Datenunabhängigkeit (Strukturänderung möglich)
DI Thomas Hödlmoser 39
Datenbankaufbau
• 3-Ebenen Modell nach ANSI-SPARC 1978
Transformationsregeln
externe Ebenebenutzerdefinierte Sichten (Ausschnitte)
Sicht 1 Sicht 2 Sicht n
konzeptionelle Ebenelogische Gesamtsicht
interne Ebenephysikalische Beschreibung(Datenorganisation im Speicher)
konzeptionelles Schema
Transformationsregeln
internes Schema
D a te n b a n k
DI Thomas Hödlmoser 40
Datenbankaufbau
• Externe Ebene
– Darstellungen der Daten für den Benutzer
– Benutzer sieht nur die für ihn relevanten Daten
– Zugriffsberechtigungen werden hier festgelegt
DI Thomas Hödlmoser 41
Datenbankaufbau
• konzeptionelle Ebene
– Daten nach Anwendungsbereich (z.B. alle Abteilungsdaten)
– Logische Zusammenhänge zwischen Daten werden definiert
DI Thomas Hödlmoser 42
Datenbankaufbau
• interne Ebene
– Organisation der Daten auf dem Speichermedium
– Benutzer sieht diese Struktur nicht
– Design der internen Ebene ist verantwortlich für die Funktionsweise der Datenbank
DI Thomas Hödlmoser 43
Datenbankaufbau
• Datenbankmanagementsystem DBMS - Aufgaben
– Ist die eigentliche Datenbanksoftware
z.B. Oracle, MySQL, Access, Centura, Sybase,…
– Übernimmt die Verwaltung der Daten
– Prüft Datenzugriffsrechte des Benutzers
– Prüft die Datenintegrität aufgrund des konzeptionellen Schemas
DI Thomas Hödlmoser 44
Datenbankaufbau
• Datenbankmanagementsystem DBMS - Aufgaben
– Führt die Datensicherung (Recovery) nach Systemabstürzen durch
– Ist verantwortlich für die Datensynchronisation
– Verwaltet die verschiedenen Transaktionen der Benutzer
DI Thomas Hödlmoser 45
Datenbankaufbau
• Datenbankmanagementsystem DBMS - Komponenten
– Data Dictonary / Repositories
– Logbuch
– Utilities zur Fehleranalyse
– CASE – Anwendungen (für Entwurf von Softwareanwendungen)
DI Thomas Hödlmoser 46
Datenbankentwurf
DI Thomas Hödlmoser 47
Datenbankentwurf
• Datenbanklebenszyklus– Analyse
– Planung
– Entwicklung
– Testen
– Eigentlicher Betrieb
DI Thomas Hödlmoser 48
Datenbankentwurf
• Entwurfsphasen
Anforderungsanalyse
konzeptioneller Entwurf
logischer Entwurf
Entwurf der Verteilung im Netz
Physischer Entwurf / Implementierung
Test und Validation
Anwendung und W artung
DI Thomas Hödlmoser 49
Datenbankentwurf
• Datenbankentwurfsphasen (Wasserfallmodell)
Anforderungsanalyse
konzeptioneller Entwurf
logischer Entwurf
Entwurfsverfeinerung
Implementierung
A n fo rd e ru n g en
k on z ep tion e llesS c h em a
log is ch es S ch em a
verfe in e rteslog is ch es S ch em a
p h ys is c h es S c h em a
Auswahl des DBS
Dokumentation
DI Thomas Hödlmoser 50
Datenbankentwurf
• Das Entity – Relationship Modell (ER-Modell)
– Hilfsmittel für den Datenbankentwurf
– Unabhängig vom Datenmodell bzw. DBMS
– Grundlage für die physikalische Struktur der Datenbank
DI Thomas Hödlmoser 51
Entity – Relationship Modell
• Elemente des ER-Modell
– Entities (Entitäten), Entity-Sets
– Attribute (Eigenschaften), Domänen
– Schlüssel und Primärschlüssel
– Beziehungen (Relationships), Kardinalität (Komplexität)
DI Thomas Hödlmoser 52
Entity – Relationship Modell
• Entities – Unterscheidbare Dinge aus der realen Welt– Entitäten unterscheiden sich durch ihre Eigenschaften
z.B. Abteilung Forschung
Mitarbeiter Huber
Projekt 1234
DI Thomas Hödlmoser 53
Entity – Relationship Modell
• Entity-Sets– Eine Menge (Sammlung) von Entities mit gleichen
Eigenschaften
z.B. Alle Abteilungen
Alle Mitarbeiter
Alle Projekte
DI Thomas Hödlmoser 54
Entity – Relationship Modell
• Attribute (Eigenschaften) – Charakterisieren eine Entität, eine Entitätsmenge oder eine
Beziehung– Attribute besitzen einen Namen und einen Wert
z.B. Abteilung
Abteilungsnummer
Projektname
Projektnummer
Mitarbeitername
DI Thomas Hödlmoser 55
Entity – Relationship Modell
• Domäne – Beschreibt den zulässigen Wertebereich eines Attributes– Können feste Werte sein, Wertebereiche oder Datentypangaben
z.B. Abteilung Forschung, Entwicklung, Konstruktion
Projektnummer 1 - 9999
Projektbeginn tt.mm.jjjj
DI Thomas Hödlmoser 56
Entity – Relationship Modell
• Schlüssel
– Setzt sich aus einem oder mehreren Attributen zusammen
– Sollte so kurz wie möglich aber so lange wie nötig sein
– Dient zur schnellen Suche einer Entität in einer Entitätsmenge
DI Thomas Hödlmoser 57
Entity – Relationship Modell
• Primärschlüssel – Ermöglicht eine eindeutige Indentifizierung einer Entität in einer
Entitätsmenge
– Wert kommt pro Entitätsmenge nur einmal vor
– Eine Entitätsmenge kann nur einen Primärschlüssel besitzen
DI Thomas Hödlmoser 58
Entity – Relationship Modell
• Primärschlüssel
Projekt
Projektnummer Projektname Projektbeginn
Entitätsmenge PROJEKT besitzt den Primärschlüssel PROJEKTNUMMER
Person
Geburtsdatum PLZ W ohnort
NameStrasse
Entitätsmenge PERSON besitzt einen Primärschlüssel, der aus den AttributenNAME und GEBURTSDATUM besteht
DI Thomas Hödlmoser 59
Entity – Relationship Modell
• Domäne – Beschreibt den zulässigen Wertebereich eines Attributes– Können feste Werte sein, Wertebereiche oder Datentypangaben
z.B. Abteilung Forschung, Entwicklung, Konstruktion
Projektnummer 1 - 9999
Projektbeginn tt.mm.jjjj
DI Thomas Hödlmoser 60
Entity – Relationship Modell
• Relationships (Beziehungen) – Beschreiben die Wechselwirkungen bzw. Abhängigkeiten von
Entitäten– Beziehungen unterscheiden sich durch ihre Eigenschaften– Beziehungen können auch Attribute enthalten– Rekursive Beziehungen beschreiben Assoziationen zwischen
zwei Entitäten der gleichen Entitätsmenge
z.B. Mitarbeiter Huber arbeitet an Projekt 1234
DI Thomas Hödlmoser 61
Entity – Relationship Modell
• Beziehungsmenge– Sammlung von Beziehungen gleicher Art– Darstellung im ER-Modell als Raute
arbeitet anMitarbeiter Projekt
arbeitet anMitarbeiter Projekt
Tätigkeit Prozent
DI Thomas Hödlmoser 62
Entity – Relationship Modell
• Kardinalität– Legt fest wie viele Entitäten einer Entitätsmenge mit einer Entität
einer anderen Entitätsmenge in Beziehung stehen können
z.B. wieviele Mitarbeiter an einen Projekt mitarbeiten
1 : 1 Beziehung (1 Person ist verheiratet mit 1 Person)1 : n Beziehung (Abteilung – Mitarbeiter)n : m Beziehung (Mitarbeiter – Projekt)
DI Thomas Hödlmoser 63
Entity – Relationship Modell
• Konstrukte des ER Modells
– Entitätsmenge
– Attribut (Eigenschaft)
– Primärschlüssel
– Relation (Beziehung) 1 n
DI Thomas Hödlmoser 64
Das relationale Datenmodell
DI Thomas Hödlmoser 65
Das relationale Datenmodell
• 1970 vom Mathematiker E. F. Codd entwickelt
• Heute am weitesten verbreitet
• Beschreibt die physikalische Datenbankstruktur
• Datenmanipulationssprache SQL ist Standard
• Datenbank besteht aus einer Menge von Relationen
DI Thomas Hödlmoser 66
Das relationale Datenmodell
• Relation– Darin werden die Daten gespeichert– Ist eine Menge von Datensätzen (Tupeln)– Hat die Form einer Tabelle – Modelliert Entities und Beziehungen aus dem ER-Modell
DI Thomas Hödlmoser 67
Das relationale Datenmodell
• Kennzeichen einer Relation– Eindeutiger Name– Mehrere Attribute (Spalten)– Keine bis beliebig viele Tupel (Tabellenzeilen od. Datensätze)– Einen einzigen Wert pro Attribut in einem Tupel (Tabellenzelle)– Einen Primärschlüssel
• Dieser identifiziert jedes Tupel eindeutig
• Dessen Wert ändert sich nicht (für jeden Datensatz)
DI Thomas Hödlmoser 68
Das relationale Datenmodell
• Aufbau einer Relation
Nummer Name PLZ Ort Strasse
1 Huber 5020 Salzburg Plainstrasse 17
2 Maier 5071 Wals Unterfeldstr. 17
Attribut, Spalte, Feld
Tupel, Datensatz
DI Thomas Hödlmoser 69
Das relationale Datenmodell
• Schlüssel
– Primärschlüssel
– Index (Sekundärindizes)
– Fremdschlüssel
DI Thomas Hödlmoser 70
Das relationale Datenmodell
• Primärschlüssel
– Identifiziert jedes Tupel einer Relation eindeutig
– Kann ein Attribut bzw. eine Attributskombination sein
– Besitzt eine Relation keine eindeutigen Schlüsselfelder muss eine Identifikationsnummer hinzugefügt werden
DI Thomas Hödlmoser 71
Das relationale Datenmodell
• Index (Sekundärindizes)
– Dient dem schnelleren Zugriff auf Tupel (Sortierungen)
– Das Füllen von Tabellen dauert allerdings länger (bei vielen Indizes)
DI Thomas Hödlmoser 72
Das relationale Datenmodell
• Fremdschlüssel
– Attribut einer Relation das eine Beziehung zu einem Primärschlüssel einer anderen Relation beinhaltet.
z.B. Beinhaltet jedes Tupel der Relation Mitarbeiter ein Attribut Abteilungsnummer. Dies ist der Primärschlüssel in der Relation Abteilung
DI Thomas Hödlmoser 73
Das relationale Datenmodell
• Normalisierung des Datenbankschemas
– Redundanzen zu vermeiden
– Übersichtlicher und einfacher Aufbau der Datenbank
– Ermöglichen einer einfachen Datenpflege
DI Thomas Hödlmoser 74
Das relationale Datenmodell
• Nicht normalisierte Datenstruktur
– Eine Eigenschaft eines Datensatzes enthält eine Liste
PersonalNr Name AbtNr AbtBezeichnung ProjNr ProjBeschreibung
0003 Huber 3 Verkauf 1,
2,
3
Kundenumfrage,
Verkaufsmesse,
Teileanalyse
DI Thomas Hödlmoser 75
Das relationale Datenmodell
• 1. Normalform einer Relation
– Relation ist zweidimensional (Zeilen und Spalten)– Jeder Datensatz kommt nur einmal vor– In jedem Datensatz befinden sich Daten die zu einem Objekt
gehören– Für jede Eigenschaft ist nur ein Wert eingetragen
DI Thomas Hödlmoser 76
Das relationale Datenmodell
• 2. Normalform einer Relation
– Jedes Nicht-Schlüsselfeld ist vom Primärschlüssel abhängig
DI Thomas Hödlmoser 77
Das relationale Datenmodell
• 3. Normalform einer Relation
– Alle Datenfelder sind nur vom gesamten Schlüssel abhängig– Untereinander treten keine Abhängigkeiten auf– Ist ein Nichtschlüsselfeld über ein anderes Nichtschlüsselfeld
identifizierbar spricht man von transitiver Abhängigkeit– z.B. PLZ - Ort
DI Thomas Hödlmoser 78
Das relationale Datenmodell
• Transformation ER-Modell in relationales Modell (physikalische Struktur)
arbeitet anMitarbeiter Projekt
P ro jek tN rP rozen tTä tig ke it B esch re ib u n g
A n sch riftV o rn am e
besteht ausAbteilung
N ach n am eP erson a lN r
P os it ion
B eze ich n u n gA b te ilu n g sn r
1 n n m
DI Thomas Hödlmoser 79
Beispiel S-Designor
• Beispiel ER-Diagramm eingeben in S-Designor• Automatische Erstellung physikalische DB-Struktur
arbeitet anMitarbeiter Projekt
P ro jek tN r B esc h re ib u n g
A n s c h riftV o rn am e
besteht ausAbteilung
N ac h n am eP ers on a lN r
B eze ic h n u n gA b te ilu n g s n r
1 n n m
A b te ilu n g s le ite r
ist vorgesetzt
1 n
DI Thomas Hödlmoser 80
Planung einer Datenbank
DI Thomas Hödlmoser 81
Datenbankplanung
• Vorgehensweise:
– Anforderungsanalyse
– Konzeptionelles Schema
– Logischen Datenbankentwurf
– Physikalischer Datenbankentwurf (Relationales Datenmodell)
DI Thomas Hödlmoser 82
Datenbankplanung - Beispiel
Auftraggeber ist eine Bibliothek oder Bücherei. Für diese soll eine
Datenbank entwickelt werden, welche den Bücherbestand und die
Entlehner (Leser) verwaltet.
Für jedes Buch sollen einige Stichworte festgelegt werden, die den
Inhalt charakterisieren.
Alle Stichworte seien in einem Thesaurus zusammengefasst, der
auch die Häufigkeit enthalten soll, wieviele Literaturquellen zu einem
Stichwort vorhanden sind
Es soll möglich sein durch logische Kombination von Stichworten, die
entsprechenden Quellen zu finden.
DI Thomas Hödlmoser 83
Datenbankplanung - Beispiel
Folgende Abfragemöglichkeiten sollten gegeben sein:
- Welche Buchbestände sind vorhanden?- Welche Leser sind registriert?- Welche Bücher sind ausgeliehen?- Von welchen Lesern sind Ausleihfristen überschritten?- Angaben über Autoren (Name, Anschrift, Tel,…)- Angaben über Verlage?
DI Thomas Hödlmoser 84
SQLStructured Query Language
DI Thomas Hödlmoser 85
SQL-allgemeines
• Entwickelt aus der Sprache SEQUEL von IBM
• Ziel ist möglichst einfache Sprache zur Abfrage von Daten
• 1986 wurde SQL zum Standard erklärt als SQL1 (SQL-86)
• Derzeit Aktuell SQL2 (SQL-92)
DI Thomas Hödlmoser 86
SQL-allgemeines
• Sprachumfang wird untergliedert in 3 Conformance Level
– Entry Level
– Intermediate Level
– Full Level
DI Thomas Hödlmoser 87
SQL-allgemeines
• Entry Level
– Wird von nahezu allen DBMS unterstützt
– Entspricht dem Standard von 1989
– Umfasst Befehle zum Anlegen von Datenbanken und Tabellen
– Bearbeitung und Verwaltung von Datenbanken und Tabellen
DI Thomas Hödlmoser 88
SQL-allgemeines
• Intermediate Level
– Zusätzliche Funktionalitäten
– Zusätzlicher Zeit-Datentyp
– Mengenoperationen
– Dynamisches SQL
DI Thomas Hödlmoser 89
SQL-allgemeines
• Full Level
– Enthält weitere Verwaltungsfunktionen
– Bis jetzt nur unvollständig in den DBMS integriert
DI Thomas Hödlmoser 90
SQL-allgemeines
• Sprachumfang von SQL
– Data Definition Language (Datenbank bzw. Tabellenerstellung)
– Data Query Language (Abfragen von Daten)
– Data Manipulation Language (Bearbeitung von Datensätzen)
– Data Control Language (Benutzeranlage, Zugriffsrechtsvergabe)
DI Thomas Hödlmoser 91
SQL-allgemeines
• Grundelemente der SQL-Sprache
– Literale („Salzburg“, „Maier“, 1234)
– Begrenzer , ( ) < > . : = + - * / >= <=
– Namen (Bezeichner für Objekte der Datenbank)
– Reservierte Wörter (Befehle der Sprache SQL z.B. SELECT)
DI Thomas Hödlmoser 92
SQL-allgemeines
• Datentypen der SQL-Sprache
– Numerische Datentypen (int, smallint, real,…)
– Alphanumerische Datentypen (char(), varchar(), text,…)
– Datentypen für Datum und Zeit (datetime, smalldatetime)
– Binäre Datentypen und der Dateityp bit (binary(), imgage(), bit)
DI Thomas Hödlmoser 93
SQL-allgemeines
• Prädikate der SQL-Sprache
– Kennzeichnen logische Bedingungen die auf Datensätze angewendet werden
– Alle Vergleichsoperatoren
– BETWEEN, IN, LIKE, NULL, ALL, ANY, EXISTS
DI Thomas Hödlmoser 94
SQL-allgemeines
• Skalare Funktionen der SQL-Sprache
– Numerische Funktionen (abs(), log(),)
– Datumsfunktionen (yy, dd,…)
– Zeichenkettenfunktionen (trim(), upper(),…)
– BLOB-Funktionen für Datentyp text bzw. image
– Systemfunktionen (datalength(), …)
DI Thomas Hödlmoser 95
SQL
• Zusammensetzung der SQL-Statements
Select nachname, vorname from mitarbeiter where personalnummer=1
create unique index ABTEILUNG_PK on ABTEILUNG (ABTEILUNGSNUMMER asc);
create table ABTEILUNG( ABTEILUNGSNUMMER INTEGER not null , BEZEICHNUNG VARCHAR(50) not null , ABTEILUNGSLEITER INTEGER not null , primary key (ABTEILUNGSNUMMER));
DI Thomas Hödlmoser 96
SQL
• Vorgehensweise beim Erstellen einer Datenbank
– Anlegen der Datenbank (Container für Tabellen)
– Erstellen der benötigten Tabellen (Festlegen der Struktur)
– Füllen der Tabellen mit Datensätzen
– Datenauswertung bzw. -änderung
DI Thomas Hödlmoser 97
SQL
• Anlegen der Datenbank
Create database [if not exists] beispieldatenbank [user ‚benutzername‘ password ‚passwort‘;
Die Create Database Anweisung legt eine neue Datenbank im DBMS an.
• Verwenden einer Datenbank
use beispieldatenbank;
DI Thomas Hödlmoser 98
SQL
• Löschen einer Datenbank
drop database [if not exists] beispieldatenbank;
Die Create Database Anweisung legt eine neue Datenbank im DBMS an.
• Datenbanken anzeigen
show databases;
DI Thomas Hödlmoser 99
SQL
• Erstellen von Tabellen
create table MITARBEITER
(
PERSONALNUMMER INTEGER [DEFAULT Standardwert | NULL | NOT NULL [AUTO_INCREMENT]
ABTEILUNGSNUMMER INTEGER [DEFAULT Standardwert | NULL | NOT NULL [AUTO_INCREMENT]
primary key (PERSONALNUMMER)
);
DI Thomas Hödlmoser 100
SQL
• Beispiele für Definitionen von Datenfeldern
NACHNAME VARCHAR(50)
Personalnummer integer not null
anzahl default 1
Beschreibung default ‚Projektbeschreibung‘
DI Thomas Hödlmoser 101
SQL
• Ändern von bestehenden Tabellen
Alter table Mitarbeiter add Telefonnummer char(80) default ‚unbekannt‘
Alter table mitarbeiter add primary key (personalnummer
DI Thomas Hödlmoser 102
SQL
• Einfügen von Daten
Insert into projekt (projektnummer, beschreibung) values (1, ‚projektbeschreibung‘);
• Abfragen der Daten
Select * from projekt;
DI Thomas Hödlmoser 103
SQL
• Einfügen von Daten mit Abfrage von anderen Daten
Insert into projekt (projektnummer, beschreibung) select * from tabelle2;
• Ändern von Daten
Update Mitarbeiter set nachname=‚maier‘, Adresse=‚Salzburg‘ where personalnummer=10;
DI Thomas Hödlmoser 104
SQL
• Löschen von Daten
Delete from Mitarbeiter where Personalnummer=15;
DI Thomas Hödlmoser 105
SQL
• Daten abfragen
Select * from Mitarbeiter;
Select Nachname, Vorname from Mitarbeiter;
Select Nachname, Vorname from Mitarbeiter where Adresse like ‚%5020%‘;
Select * from mitarbeiter order by Nachname asc;
Select adresse as Anschrift, Vorname as name2 from Mitarbeiter;
DI Thomas Hödlmoser 106
SQL
• Daten abfragen
Select distinct nachname * from Mitarbeiter;
Select * from mitarbeiter where nachname = ‚huber‘ limit 10;
Select * from mitarbeiter where Personalnummer between 100 and 1000;
Select ort as Wohnort, count(*) from Mitarbeiter group by ort;
Select nachname count(*) from Mitarbeiter group by ort having count(*)>5;