Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Datenbankanbindungen

Ähnliche Präsentationen


Präsentation zum Thema: "Datenbankanbindungen"—  Präsentation transkript:

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

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: Donnerstag: 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 Inkonsistenzen
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 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)
Für jeden Knoten (Kunde, Bestellung, Posten) 1 Datensatz Redundante Datendarstellung DI Thomas Hödlmoser

22 Datenbanktypen Netzwerkdatenbanken 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,…) DI Thomas Hödlmoser

24 Datenbanktypen objektorientierte Datenbanken OODB
Objekt-Klassen enthalten Attribute, Beziehungen und Methoden Dzt. Unterstützen nur wenige Datenbanksysteme OODB 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 ü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) 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) 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) DI Thomas Hödlmoser

35 Datenbankstruktur Shared Nothing Architektur DI Thomas Hödlmoser

36 Datenbankstruktur Shared Disk Architektur 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
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 DI Thomas Hödlmoser

49 Datenbankentwurf Datenbankentwurfsphasen (Wasserfallmodell)
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 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 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 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 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) 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
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 Tupel, Datensatz Attribut, Spalte, Feld 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, 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) DI Thomas Hödlmoser

79 Beispiel S-Designor Beispiel ER-Diagramm eingeben in S-Designor
Automatische Erstellung physikalische DB-Struktur 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 SQL Structured 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 Verwenden einer 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 Datenbanken anzeigen
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 Abfragen der 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 Ändern von 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; DI Thomas Hödlmoser


Herunterladen ppt "Datenbankanbindungen"

Ähnliche Präsentationen


Google-Anzeigen