Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Datenbankanbindungen Grundlagen von Datenbanken Datenbankabfragen Thomas Hödlmoser, ICP systems.

Ähnliche Präsentationen


Präsentation zum Thema: "Datenbankanbindungen Grundlagen von Datenbanken Datenbankabfragen Thomas Hödlmoser, ICP systems."—  Präsentation transkript:

1 Datenbankanbindungen Grundlagen von Datenbanken Datenbankabfragen Thomas Hödlmoser, ICP systems

2 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

3 DI Thomas Hödlmoser 3 Praktische Inhalte Planung und Aufbau einer Datenbankstruktur Erstellen von Datenbankabfragen Problemlösungen und Fragen????

4 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

5 DI Thomas Hödlmoser 5 Agenda Freitag: –Einfache SQL-Abfragen –Änderungen an Tabelleninhalten mittels SQL –Praktische Beispiele SQL

6 DI Thomas Hödlmoser 6 Datenbanken - allgemein

7 DI Thomas Hödlmoser 7 Warum Datenbanken? Herkömmliche Speicherung in Dateisystemen

8 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)

9 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

10 DI Thomas Hödlmoser 10 Warum Datenbanken? Logische Datenunabhängigkeit –Es existiert eine logische Struktur der Datenbank –Jeder Benutzer sieht nur seine relevanten Daten

11 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

12 DI Thomas Hödlmoser 12 Warum Datenbanken? Prozedurale und nichtprozedurale Schnittstellen –Unterscheidung Entwickler - Anwender –Entwickler: Prozedurale Schnittstellen (C++, Java, Basic,…) –Anwender: nichtprozedurale Schnittstellen (Anwendungssoftware)

13 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)

14 DI Thomas Hödlmoser 14 Warum Datenbanken? Minimale Datenredundanz –Reduktion des Speicherbedarfs –Verwaltungsaufwand bei Datenänderung wird geringer –Abhängig vom Datenbankdesign des Entwicklers

15 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)

16 DI Thomas Hödlmoser 16 Warum Datenbanken? Konkurrierender Datenzugriff –Viele gleichzeitige Zugriffe auf die gleichen Daten –Datenbank muss Zugriffe richtig abarbeiten Konto Nr. 1234Kontostand EUR ,--Konto Nr. 1234Kontostand EUR ,-- Person 1 Abhebung EUR 5.000,-- Person 1 Abhebung EUR 5.000,-- Person 2 Abhebung EUR 5.000,-- Person 2 Abhebung EUR 5.000,-- Kontostand ?

17 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)

18 DI Thomas Hödlmoser 18 Warum Datenbanken? Datenschutz –Schutz gegen unerlaubten Zugriff (z.B. Mitarbeitergehälter) –Zugriff kann auf spezielle Daten eingeschränkt werden

19 DI Thomas Hödlmoser 19 Datenbanktypen

20 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

21 DI Thomas Hödlmoser 21 Datenbanktypen Hierarchisches Datenbankmodell (Vater-Sohn Darstellung) –Für jeden Knoten (Kunde, Bestellung, Posten) 1 Datensatz –Redundante Datendarstellung

22 DI Thomas Hödlmoser 22 Datenbanktypen Netzwerkdatenbanken

23 DI Thomas Hödlmoser 23 Datenbanktypen Relationale Datenbanken –Beziehungen werden benannt und im ER –Diagramm dargestellt –Beziehungen wird Kardinalität zugeordnet (1:n; n:m,…)

24 DI Thomas Hödlmoser 24 Datenbanktypen objektorientierte Datenbanken OODB –Objekt-Klassen enthalten Attribute, Beziehungen und Methoden –Dzt. Unterstützen nur wenige Datenbanksysteme OODB

25 DI Thomas Hödlmoser 25 Datenbankstruktur

26 DI Thomas Hödlmoser 26 Datenbankstruktur Zentralisierte Datenbanksysteme Verteilte Datenbanksysteme Client-Server Datenbanken Parallele Datenbanken

27 DI Thomas Hödlmoser 27 Datenbankstruktur Zentralisierte Datenbanksysteme - Zentralrechner übernimmt alle Aufgaben - dumme Terminals - Einfache Administration

28 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)

29 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)

30 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

31 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)

32 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

33 DI Thomas Hödlmoser 33 Datenbankstruktur Parallele Datenbanksysteme –Shared Memory Architektur (Shared Everything Architektur) –Shared Nothing Architektur –Shared Disk Architektur

34 DI Thomas Hödlmoser 34 Datenbankstruktur Shared Memory Architektur (Shared Everything Architektur)

35 DI Thomas Hödlmoser 35 Datenbankstruktur Shared Nothing Architektur

36 DI Thomas Hödlmoser 36 Datenbankstruktur Shared Disk Architektur

37 DI Thomas Hödlmoser 37 Datenbankaufbau und Organisation

38 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)

39 DI Thomas Hödlmoser 39 Datenbankaufbau 3-Ebenen Modell nach ANSI-SPARC 1978

40 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

41 DI Thomas Hödlmoser 41 Datenbankaufbau konzeptionelle Ebene –Daten nach Anwendungsbereich (z.B. alle Abteilungsdaten) –Logische Zusammenhänge zwischen Daten werden definiert

42 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

43 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

44 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

45 DI Thomas Hödlmoser 45 Datenbankaufbau Datenbankmanagementsystem DBMS - Komponenten –Data Dictonary / Repositories –Logbuch –Utilities zur Fehleranalyse –CASE – Anwendungen (für Entwurf von Softwareanwendungen)

46 DI Thomas Hödlmoser 46 Datenbankentwurf

47 DI Thomas Hödlmoser 47 Datenbankentwurf Datenbanklebenszyklus –Analyse –Planung –Entwicklung –Testen –Eigentlicher Betrieb

48 DI Thomas Hödlmoser 48 Datenbankentwurf Entwurfsphasen

49 DI Thomas Hödlmoser 49 Datenbankentwurf Datenbankentwurfsphasen (Wasserfallmodell)

50 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

51 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)

52 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

53 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

54 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

55 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 Projektbeginn tt.mm.jjjj

56 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

57 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

58 DI Thomas Hödlmoser 58 Entity – Relationship Modell Primärschlüssel

59 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 Projektbeginn tt.mm.jjjj

60 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

61 DI Thomas Hödlmoser 61 Entity – Relationship Modell Beziehungsmenge –Sammlung von Beziehungen gleicher Art –Darstellung im ER-Modell als Raute

62 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 : nBeziehung (Abteilung – Mitarbeiter) n : mBeziehung (Mitarbeiter – Projekt)

63 DI Thomas Hödlmoser 63 Entity – Relationship Modell Konstrukte des ER Modells –Entitätsmenge –Attribut (Eigenschaft) –Primärschlüssel –Relation (Beziehung)

64 DI Thomas Hödlmoser 64 Das relationale Datenmodell

65 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

66 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

67 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)

68 DI Thomas Hödlmoser 68 Das relationale Datenmodell Aufbau einer Relation NummerNamePLZOrtStrasse 1Huber5020SalzburgPlainstrasse 17 2Maier5071WalsUnterfeldstr. 17 Attribut, Spalte, Feld Tupel, Datensatz

69 DI Thomas Hödlmoser 69 Das relationale Datenmodell Schlüssel –Primärschlüssel –Index (Sekundärindizes) –Fremdschlüssel

70 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

71 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)

72 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

73 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

74 DI Thomas Hödlmoser 74 Das relationale Datenmodell Nicht normalisierte Datenstruktur –Eine Eigenschaft eines Datensatzes enthält eine Liste PersonalNrNameAbtNrAbtBezeichnungProjNrProjBeschreibung 0003Huber3Verkauf1, 2, 3 Kundenumfrage, Verkaufsmesse, Teileanalyse

75 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

76 DI Thomas Hödlmoser 76 Das relationale Datenmodell 2. Normalform einer Relation –Jedes Nicht-Schlüsselfeld ist vom Primärschlüssel abhängig

77 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

78 DI Thomas Hödlmoser 78 Das relationale Datenmodell Transformation ER-Modell in relationales Modell (physikalische Struktur)

79 DI Thomas Hödlmoser 79 Beispiel S-Designor Beispiel ER-Diagramm eingeben in S-Designor Automatische Erstellung physikalische DB-Struktur

80 DI Thomas Hödlmoser 80 Planung einer Datenbank

81 DI Thomas Hödlmoser 81 Datenbankplanung Vorgehensweise: –Anforderungsanalyse –Konzeptionelles Schema –Logischen Datenbankentwurf –Physikalischer Datenbankentwurf (Relationales Datenmodell)

82 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.

83 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?

84 DI Thomas Hödlmoser 84 SQL Structured Query Language

85 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)

86 DI Thomas Hödlmoser 86 SQL-allgemeines Sprachumfang wird untergliedert in 3 Conformance Level –Entry Level –Intermediate Level –Full Level

87 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

88 DI Thomas Hödlmoser 88 SQL-allgemeines Intermediate Level –Zusätzliche Funktionalitäten –Zusätzlicher Zeit-Datentyp –Mengenoperationen –Dynamisches SQL

89 DI Thomas Hödlmoser 89 SQL-allgemeines Full Level –Enthält weitere Verwaltungsfunktionen –Bis jetzt nur unvollständig in den DBMS integriert

90 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)

91 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)

92 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)

93 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

94 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(), …)

95 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) );

96 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

97 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;

98 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;

99 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) );

100 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

101 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

102 DI Thomas Hödlmoser 102 SQL Einfügen von Daten Insert into projekt (projektnummer, beschreibung) values (1, projektbeschreibung); Abfragen der Daten Select * from projekt;

103 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;

104 DI Thomas Hödlmoser 104 SQL Löschen von Daten Delete from Mitarbeiter where Personalnummer=15;

105 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;

106 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;


Herunterladen ppt "Datenbankanbindungen Grundlagen von Datenbanken Datenbankabfragen Thomas Hödlmoser, ICP systems."

Ähnliche Präsentationen


Google-Anzeigen