Transcript Datenbankanbindungen

Datenbankanbindungen
Grundlagen von Datenbanken
Datenbankabfragen
Thomas Hödlmoser, ICP systems
Ziele dieser Schulung
•
•
•
•
Was ist eine Datenbank
Nutzungsmöglichkeiten
Arten von Datenbanken
notwendige Hard- bzw.
Software
• Planung von
Datenbankstrukturen
• Datenabfragemöglichkeiten
DI Thomas Hödlmoser
2
Praktische Inhalte
• Planung und Aufbau einer Datenbankstruktur
• Erstellen von Datenbankabfragen
• Problemlösungen und Fragen????
DI Thomas Hödlmoser
3
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
4
Agenda
• Freitag:
– Einfache SQL-Abfragen
– Änderungen an Tabelleninhalten mittels SQL
– Praktische Beispiele SQL
DI Thomas Hödlmoser
5
Datenbanken - allgemein
DI Thomas Hödlmoser
6
Warum Datenbanken?
• Herkömmliche Speicherung in Dateisystemen
DI Thomas Hödlmoser
7
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
8
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
9
Warum Datenbanken?
• Logische Datenunabhängigkeit
– Es existiert eine logische Struktur der Datenbank
– Jeder Benutzer sieht nur „seine“ relevanten Daten
DI Thomas Hödlmoser
10
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
11
Warum Datenbanken?
• Prozedurale und nichtprozedurale Schnittstellen
– Unterscheidung Entwickler - Anwender
– Entwickler: Prozedurale Schnittstellen (C++, Java, Basic,…)
– Anwender: nichtprozedurale Schnittstellen (Anwendungssoftware)
DI Thomas Hödlmoser
12
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
13
Warum Datenbanken?
• Minimale Datenredundanz
– Reduktion des Speicherbedarfs
– Verwaltungsaufwand bei Datenänderung wird geringer
– Abhängig vom Datenbankdesign des Entwicklers
DI Thomas Hödlmoser
14
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
15
Warum Datenbanken?
• Konkurrierender Datenzugriff
– Viele gleichzeitige Zugriffe auf die gleichen Daten
– Datenbank muss Zugriffe richtig abarbeiten
Konto Nr. 1234
Kontostand EUR 10.000,--
Person 2 Abhebung EUR 5.000,--
Person 1 Abhebung EUR 5.000,--
Kontostand ?
DI Thomas Hödlmoser
16
Warum Datenbanken?
• Datensicherheit
– Herstellung des letzten konsistenten Datenstandes nach Ausfall von
Hard od. Software
– Wiederhergestellter Datenstand muss verifizierbar sein (Buchungen)
DI Thomas Hödlmoser
17
Warum Datenbanken?
• Datenschutz
– Schutz gegen unerlaubten Zugriff (z.B. Mitarbeitergehälter)
– Zugriff kann auf spezielle Daten eingeschränkt werden
DI Thomas Hödlmoser
18
Datenbanktypen
DI Thomas Hödlmoser
19
Datenbanktypen
• Übergang Dateisystem - Datenbank
– Speicher auf Magnetplatten (60er Jahre)
– 1. Datenbanksysteme (70er Jahre)
•
•
•
•
Hierarchisches Datenbankmodell
Netzwerkdatenbanken
Relationale Datenbanken
Objektorientierte Datenbanken
DI Thomas Hödlmoser
20
Datenbanktypen
• Hierarchisches Datenbankmodell (Vater-Sohn Darstellung)
Kunde A
Bestellung A1
Posten A11
Posten A11
Bestellung A2
Posten A21
Bestellung A3
Posten A31
Posten A32
Posten A33
– Für jeden Knoten (Kunde, Bestellung, Posten) 1 Datensatz
– Redundante Datendarstellung
DI Thomas Hödlmoser
21
Datenbanktypen
• Netzwerkdatenbanken
Abteilung A
Mitarbeiter 1
Mitarbeiter 1 - Projekt GW
Projekt GW
Mitarbeiter 1 - Projekt XY
Mitarbeiter 2 - Projekt XY
ProjektXY
Mitarbeiter 2
Mitarbeiter 3 - Projekt XY
Mitarbeiter 3
Projekt ME
Mitarbeiter 3 - Projekt ME
Projekt ST
Mitarbeiter 3 - Projekt ST
DI Thomas Hödlmoser
22
Datenbanktypen
• Relationale Datenbanken
Abteilung
1
beschäftigt
n
Mitarbeiter
n
arbeitet an
m
Projekt
– Beziehungen werden benannt und im ER –Diagramm dargestellt
– Beziehungen wird Kardinalität zugeordnet (1:n; n:m,…)
DI Thomas Hödlmoser
23
Datenbanktypen
• objektorientierte Datenbanken OODB
Klasse Mitarbeiter
Klasse Abteilung
// Attribute
Name
Nr.
//Beziehungen
beschäftigt <Mitarbeiter>
//Methoden
umbenennen()
neuerMitarbeiter()
Klasse Projekt
// Attribute
Name
Wohnort
beschäftigt
arbeitet_in
//Beziehungen
arbeitet_in <Abteilung>
arbeitet_an <Projekt>
//Methoden
abteilungswechsel()
entlassen()
// Attribute
Name
Beschreibung
arbeitet_an
bearbeitet_von
//Beziehungen
bearbeitet_von <Mitarbeiter>
//Methoden
erzeugen()
abschliessen()
– Objekt-Klassen enthalten Attribute, Beziehungen und Methoden
– Dzt. Unterstützen nur wenige Datenbanksysteme OODB
DI Thomas Hödlmoser
24
Datenbankstruktur
DI Thomas Hödlmoser
25
Datenbankstruktur
• Zentralisierte Datenbanksysteme
• Verteilte Datenbanksysteme
• Client-Server Datenbanken
• Parallele Datenbanken
DI Thomas Hödlmoser
26
Datenbankstruktur
• Zentralisierte Datenbanksysteme
Knoten 1
Knoten 2
Knoten 3
Netzwerk
Knoten 4
Anwendung
Datenbank
- Zentralrechner übernimmt alle Aufgaben
- „dumme“ Terminals
- Einfache Administration
DI Thomas Hödlmoser
Daten
Zentralrechner
27
Datenbankstruktur
• Verteilte Datenbanksysteme
Anwendung
Anwendung
Datenbank
Datenbank
Daten
Daten
Knoten 1
Netzwerk
Knoten 2
Anwendung
Anwendung
Datenbank
Datenbank
Daten
Daten
Knoten 3
Knoten4
-
-
-
DI Thomas Hödlmoser
Logisch zusammengehörige
Teildatenbanken
Datenbanksystem kümmert sich
um das Zusammenführen der
Daten
Geographische Trennung möglich
(Filialen)
28
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
29
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
30
Datenbankstruktur
• Client – Server Datenbanken
Client 1
1. Anforderung
3. Antwort
Server
2. Bearbeitung
2. Bearbeitung
-
1. Anforderung
3. Antwort
Client 2
Datenbankabfragen und Anzeigeprogramme sind getrennt
Client und Serverprogramme können auf einen Rechner laufen
definierte Abfragesprache zwischen Client und Server (SQL)
DI Thomas Hödlmoser
31
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
32
Datenbankstruktur
• Parallele Datenbanksysteme
– Shared Memory Architektur (Shared Everything Architektur)
– Shared Nothing Architektur
– Shared Disk Architektur
DI Thomas Hödlmoser
33
Datenbankstruktur
Shared Memory Architektur (Shared Everything Architektur)
Prozessor 1
Speicher 1
Prozessor 2
Speicher 2
Hochgeschwindigkeitsnetz
Platte 1
Platte 2
Platte x
DI Thomas Hödlmoser
34
Datenbankstruktur
Shared Nothing Architektur
Hochgeschwindigkeitsnetz
Prozessor 1
Prozessor 2
Prozessor n
Speicher 1
Speicher 2
Speicher n
Platte 1
Platte 2
Platte n
DI Thomas Hödlmoser
35
Datenbankstruktur
Shared Disk Architektur
Prozessor 1
Prozessor 2
Prozessor n
Speicher 1
Speicher 2
Speicher n
Hochgeschwindigkeitsnetz
Platte 1
Platte 2
DI Thomas Hödlmoser
Platte n
36
Datenbankaufbau und
Organisation
DI Thomas Hödlmoser
37
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
38
Datenbankaufbau
• 3-Ebenen Modell nach ANSI-SPARC 1978
externe Ebene
benutzerdefinierte Sichten (Ausschnitte)
Sicht 1
Sicht n
Sicht 2
Transformationsregeln
konzeptionelle Ebene
logische Gesamtsicht
konzeptionelles Schema
Transformationsregeln
interne Ebene
physikalische Beschreibung
(Datenorganisation im Speicher)
internes Schema
Datenbank
DI Thomas Hödlmoser
39
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
40
Datenbankaufbau
• konzeptionelle Ebene
– Daten nach Anwendungsbereich (z.B. alle Abteilungsdaten)
– Logische Zusammenhänge zwischen Daten werden definiert
DI Thomas Hödlmoser
41
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
42
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
43
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
44
Datenbankaufbau
• Datenbankmanagementsystem DBMS - Komponenten
– Data Dictonary / Repositories
– Logbuch
– Utilities zur Fehleranalyse
– CASE – Anwendungen (für Entwurf von Softwareanwendungen)
DI Thomas Hödlmoser
45
Datenbankentwurf
DI Thomas Hödlmoser
46
Datenbankentwurf
• Datenbanklebenszyklus
– Analyse
– Planung
– Entwicklung
– Testen
– Eigentlicher Betrieb
DI Thomas Hödlmoser
47
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
48
Datenbankentwurf
• Datenbankentwurfsphasen (Wasserfallmodell)
Anforderungsanalyse
Anforderungen
konzeptioneller Entwurf
Auswahl des DBS
konzeptionelles
Schema
logischer Entwurf
logisches Schema
Entwurfsverfeinerung
verfeinertes
logisches Schema
Implementierung
physisches Schema
Dokumentation
DI Thomas Hödlmoser
49
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
50
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
51
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
52
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
53
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
54
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
55
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
56
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
57
Entity – Relationship Modell
• Primärschlüssel
Entitätsmenge PROJEKT besitzt den Primärschlüssel PROJEKTNUMMER
Projekt
Projektnummer
Projektname
Projektbeginn
Entitätsmenge PERSON besitzt einen Primärschlüssel, der aus den Attributen
NAME und GEBURTSDATUM besteht
Person
Strasse
Name
Geburtsdatum
PLZ
DI Thomas Hödlmoser
Wohnort
58
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
59
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
60
Entity – Relationship Modell
• Beziehungsmenge
– Sammlung von Beziehungen gleicher Art
– Darstellung im ER-Modell als Raute
Mitarbeiter
Mitarbeiter
Tätigkeit
arbeitet an
Projekt
arbeitet an
Projekt
Prozent
DI Thomas Hödlmoser
61
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
1:n
n:m
Beziehung (1 Person ist verheiratet mit 1 Person)
Beziehung (Abteilung – Mitarbeiter)
Beziehung (Mitarbeiter – Projekt)
DI Thomas Hödlmoser
62
Entity – Relationship Modell
• Konstrukte des ER Modells
– Entitätsmenge
– Attribut (Eigenschaft)
– Primärschlüssel
– Relation (Beziehung)
1
DI Thomas Hödlmoser
n
63
Das relationale Datenmodell
DI Thomas Hödlmoser
64
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
65
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
66
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
67
Das relationale Datenmodell
• Aufbau einer Relation
Nummer Name
PLZ
Ort
Strasse
1
Huber
5020
Salzburg
Plainstrasse 17
2
Maier
5071
Wals
Unterfeldstr. 17
Tupel, Datensatz
Attribut, Spalte, Feld
DI Thomas Hödlmoser
68
Das relationale Datenmodell
• Schlüssel
– Primärschlüssel
– Index (Sekundärindizes)
– Fremdschlüssel
DI Thomas Hödlmoser
69
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
70
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
71
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
72
Das relationale Datenmodell
• Normalisierung des Datenbankschemas
– Redundanzen zu vermeiden
– Übersichtlicher und einfacher Aufbau der Datenbank
– Ermöglichen einer einfachen Datenpflege
DI Thomas Hödlmoser
73
Das relationale Datenmodell
• Nicht normalisierte Datenstruktur
– Eine Eigenschaft eines Datensatzes enthält eine Liste
PersonalNr Name
AbtNr AbtBezeichnung ProjNr ProjBeschreibung
0003
3
Huber
Verkauf
DI Thomas Hödlmoser
1,
2,
3
Kundenumfrage,
Verkaufsmesse,
Teileanalyse
74
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
75
Das relationale Datenmodell
• 2. Normalform einer Relation
– Jedes Nicht-Schlüsselfeld ist vom Primärschlüssel abhängig
DI Thomas Hödlmoser
76
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
77
Das relationale Datenmodell
• Transformation ER-Modell in relationales Modell
(physikalische Struktur)
PersonalNr
Abteilung
1
besteht aus
n
Nachname
Mitarbeiter
Position
Abteilungsnr
Bezeichnung
arbeitet an
n
Tätigkeit
Vorname
Prozent
m
Projekt
ProjektNr
Beschreibung
Anschrift
DI Thomas Hödlmoser
78
Beispiel S-Designor
• Beispiel ER-Diagramm eingeben in S-Designor
• Automatische Erstellung physikalische DB-Struktur
Vorname
Abteilungsleiter
Abteilung
1
Anschrift
PersonalNr
besteht aus
n
Nachname
Mitarbeiter
1
n
arbeitet an
m
Projekt
n
ProjektNr
Abteilungsnr
Beschreibung
Bezeichnung
ist vorgesetzt
DI Thomas Hödlmoser
79
Planung einer Datenbank
DI Thomas Hödlmoser
80
Datenbankplanung
• Vorgehensweise:
– Anforderungsanalyse
– Konzeptionelles Schema
– Logischen Datenbankentwurf
– Physikalischer Datenbankentwurf (Relationales Datenmodell)
DI Thomas Hödlmoser
81
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
82
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
83
SQL
Structured Query Language
DI Thomas Hödlmoser
84
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
85
SQL-allgemeines
• Sprachumfang wird untergliedert in 3 Conformance Level
– Entry Level
– Intermediate Level
– Full Level
DI Thomas Hödlmoser
86
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
87
SQL-allgemeines
• Intermediate Level
– Zusätzliche Funktionalitäten
– Zusätzlicher Zeit-Datentyp
– Mengenoperationen
– Dynamisches SQL
DI Thomas Hödlmoser
88
SQL-allgemeines
• Full Level
– Enthält weitere Verwaltungsfunktionen
– Bis jetzt nur unvollständig in den DBMS integriert
DI Thomas Hödlmoser
89
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
90
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
91
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
92
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
93
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
94
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
BEZEICHNUNG
VARCHAR(50)
ABTEILUNGSLEITER INTEGER
primary key (ABTEILUNGSNUMMER)
);
not null ,
not null ,
not null ,
DI Thomas Hödlmoser
95
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
96
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
97
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
98
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
99
SQL
• Beispiele für Definitionen von Datenfeldern
NACHNAME VARCHAR(50)
Personalnummer integer not null
anzahl default 1
Beschreibung default ‚Projektbeschreibung‘
DI Thomas Hödlmoser
100
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
101
SQL
• Einfügen von Daten
Insert into projekt (projektnummer, beschreibung) values (1, ‚projektbeschreibung‘);
• Abfragen der Daten
Select * from projekt;
DI Thomas Hödlmoser
102
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
103
SQL
• Löschen von Daten
Delete from Mitarbeiter where Personalnummer=15;
DI Thomas Hödlmoser
104
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
105
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;
DI Thomas Hödlmoser
106