Informations- und Wissensmanagement

Transkript

1 Übung zur Vorlesung Informations- und Wissensmanagement (Übung 1) Frank Eichinger IPD, Lehrstuhl für Systeme der Informationsverwaltung

2 Zur Person Beruflicher Hintergrund Studium an der TU Braunschweig Seit Juni Mitarbeiter am IPD Interessensfelder Data Mining Datenbanken Aktuelle Arbeitsschwerpunkte Graph Mining Anwendungen in der Softwaretechnik Frank Eichinger IWM Übung 1 2

3 Organisatorisches Kontakt Per eichinger at ipd.uka.de Sprechzeiten Nach Absprache Gebäude 50.34, Raum 340 Aufgabenblätter: werden vor der Übung ins Netz gestellt Lösungen: nach der Übung Weitere Übungen: , und Raum: in Zukunft Raum -101 Frank Eichinger IWM Übung 1 3

4 Wiederholung wichtiger Begriffe (1) Datenunabhängigkeit Welche Unterscheidungen werden gemacht? Was versteht man darunter? Wie wird sie realisiert? Frank Eichinger IWM Übung 1 4

5 Datenunabhängigkeit Physische Datenunabhängigkeit Anfragen sind deklarativ. DBMS entscheidet über zu benutzende Zugriffspfade, Indexe, Selektionsreihenfolge etc. und gewährleistet effiziente Bearbeitung. Vereinfacht Anwendungsentwicklung! Ausnahme: Manuelles Performance-Tuning Logische Datenunabhängigkeit Realisiert durch externe Schema (Views). Unterschiedliche Benutzer erhalten unterschiedliche Sicht auf den gleichen Datenbestand. Frank Eichinger IWM Übung 1 5

6 3-Ebenen Architektur Externes Schema 1... Externes Schema n Anfragebearbeitung Konzeptuelles Schema Internes Schema Datenvisualisierung Frank Eichinger IWM Übung 1 6

7 Wiederholung wichtiger Begriffe (2) Integrität Was ist Integrität? Was sind Beispiele für inkonsistente Zustände? Wer ist Verantwortlich für die Integritätssicherung? Wie wird Integritätssicherung durch DBMS unterstützt? Frank Eichinger IWM Übung 1 7

8 Integrität Integrität befasst sich mit der Korrektheit der Daten. Integrität erfüllt, wenn alle gespeicherten Daten fehlerfrei erfasst wurden und den gewünschten Informationsgehalt korrekt wiedergeben. Sinnvoll: Einschränkungen aus der modellierten Miniwelt an das Datenbanksystem delegieren! Hilfsmittel: Integritätsbedingungen Das DBMS weist Änderungen zurück, die die Integrität verletzen würden. Frank Eichinger IWM Übung 1 8

9 Wertebereichsbedingung Attributwerte dürfen nur Elemente aus einem festgelegten Wertebereich (Domäne) sein. Typischerweise Standarddatentypen (integer, float, varchar,...) Auch benutzerdefinierte Domänen möglich, z.b.: CREATE DOMAIN Matr_Nr AS integer CHECK (value > 0), CHECK (value <= ); Besonderer Attributwert: NULL Frank Eichinger IWM Übung 1 9

10 Eindeutigkeitsbedingung Heutige DBMS können alle mit Multimengen umgehen Tupel in der Relation können also mehrfach vorkommen. In den meisten Fällen ist es aber gewünscht, dass jedes Tupel in einer Relation nur 1x vorkommen darf. Redundanzfreiheit Wird realisiert mit PRIMARY KEY (Primärschlüssel) UNIQUE (weitere Schlüsselkandidaten) Frank Eichinger IWM Übung 1 10

11 Referentielle Integrität (1) Fremdschlüsselbeziehung Zwei Bedingungen: Zusammengesetzter Fremdschlüssel darf nur aus NULL-Werten oder nur aus Nicht-NULL-Werten bestehen Falls Fremdschlüssel ungleich NULL, muss in der referenzierten Relation ein Schlüssel mit gleichem Wert existieren Problem: Reaktion auf das Löschen eines referenzierten Schlüssels Frank Eichinger IWM Übung 1 11

12 Referentielle Integrität (2) Löschen verbieten (default) Fremdschlüssel auf NULL setzen ON DELETE SET NULL Tupel in referenzierter Relation löschen ON DELETE CASCADE Auswahl ist anwendungsspezifisch Frank Eichinger IWM Übung 1 12

13 Weitere Bemerkungen Weitere Integritätsbedingungen lassen sich durch check (u.a. Techniken) realisieren. Z.B.: check( (select COUNT(*) from AUFTRAG) (select COUNT(*) from KUNDE) ) Integritätsbedingungen überlegt einsetzen! Jede IB muss bei Veränderungen am Datenbestand überprüft werden und kostet somit Rechenzeit. Redundante Integritätsbedingungen vermeiden! Statt mehrfaches 'check age > 0' lieber Domain verwenden. Frank Eichinger IWM Übung 1 13

14 Wiederholung wichtiger Begriffe (3) Die neun Codd'schen Regeln Anforderungen an DBMS nach Codd (1982) Welche Regeln/Anforderungen sind bekannt? Frank Eichinger IWM Übung 1 14

15 Die neun Codd'schen Regeln (1-3) 1.) Integration Alle Daten sollen einheitlich und nicht redundant verwaltet werden. 2.) Operationen...zum Speichern, Suchen und Ändern müssen vorhanden sein. 3.) Katalog Der Katalog oder Data Dictionary stellt Datenbeschreibungen (Metadaten) des gesamten Datenbestands zur Verfügung. Frank Eichinger IWM Übung 1 15

16 Die neun Codd'schen Regeln (4+5) 4.) Benutzersichten...stellen logische Datenunabhängigkeit sicher.... sind benutzerabhängige und vom System kontrollierte Sichten auf den Datenbestand. Siehe 3-Ebenen Architektur. 5.) Integritätssicherung oder auch Konsistenzüberwachung Das System garantiert die Korrektheit des Datenbestandes zu jedem Zeitpunkt nach Maßgabe definierter Regeln. Siehe Integrität. Frank Eichinger IWM Übung 1 16

17 Die neun Codd'schen Regeln (6+7) 6.) Datenschutz bzw. Zugriffskontrolle Ausschluss unautorisierter Zugriffe durch das System. 7.) Transaktionen Sind eine Zusammenfassung von Datenbankänderungen, die gemeinsam ausgeführt werden. Das System gewährleistet Atomarität ( Alles oder nichts ) und Dauerhaftigkeit (Persistenz). Beispiel: Zwei Relationen MITARBEITER und RAUM Jede hat ein NOT NULL-Fremdschlüssel zur Anderen Problem: Einfügen von Tupeln Frank Eichinger IWM Übung 1 17

18 Die neun Codd'schen Regeln (8+9) 8.) Synchronisation Das System ermöglicht nebenläufige Transaktionen mehrerer Benutzer. Gegenseitige Beeinflussungen werden vermieden (Gewährleistung der Isolation). 9.) Datensicherung Wiederherstellung von Daten nach Systemfehlern Frank Eichinger IWM Übung 1 18

19 ACID-Eigenschaften von Transaktionen Üblicherweise werden vier Forderungen an Transaktionen gestellt: Atomicity (7. - Transaktionen) Consistency (5. - Integritätssicherung) Die Transaktion überführt das System von einem konsistenten Zustand in einen anderen. Abbruch falls nicht möglich (atomicity). Isolation (8. - Synchronisation) Durability (7./9. - Transaktionen) Wenn eine Transaktion nicht abgebrochen wird, bleiben die Änderungen selbst bei einem Systemabsturz erhalten. ACID wird nicht nur bei Datenbanken gefordert sondern auch bei verteilten Systemen. Frank Eichinger IWM Übung 1 19

20 Übungsblatt 1 Aufgabe 1: Schemadefinition Aufgabe 2: Datenbankdefinition Frank Eichinger IWM Übung 1 20

21 Aufgabe 1a) Schlüssel Stadt (stadt, land, einwohnerzahl) Entfernung (stadt1, land1, stadt2, land2, entfernung) Hotel (hotel, stadt, land, klasse, adresse, anzahlezimmer, anzahldzimmer, preisezimmer, preisdzimmer) Buchung (buchungnr, hotel, stadt, land, anreisedatum, abreisedatum, kundennr, gebuchteezimmer, gebuchtedzimmer) Kunde (kundennr, name, vorname, adresse) Frank Eichinger IWM Übung 1 21

22 Aufgabe 1a) Fremdschlüssel Entfernung: (stadt1, land1) auf Stadt, (stadt2, land2) auf Stadt Hotel: (stadt, land) auf Stadt Buchung: (stadt, land, adresse) auf Hotel, (kundennr) auf Kunde Frank Eichinger IWM Übung 1 22

23 Aufgabe 1b) Stadt CREATE TABLE Stadt ( stadt varchar(30) NOT NULL, land varchar(30) NOT NULL, einwohnerzahl integer, PRIMARY KEY (stadt, land), CHECK (einwohnerzahl > 0) ); Frank Eichinger IWM Übung 1 23

24 Aufgabe 1b) Entfernung CREATE TABLE Entfernung ( stadt1 varchar(30) NOT NULL, land1 varchar(30) NOT NULL, stadt2 varchar(30) NOT NULL, land2 varchar(30) NOT NULL, entfernung integer NOT NULL, PRIMARY KEY (stadt1, land1, stadt2, land2), FOREIGN KEY (stadt1, land1) REFERENCES Stadt, FOREIGN KEY (stadt2, land2) REFERENCES Stadt, CHECK (entfernung > 0) ); Frank Eichinger IWM Übung 1 24

25 Aufgabe 1b) Buchung CREATE TABLE Buchung ( buchungnr integer NOT NULL, hotel varchar(30), stadt varchar(30), land varchar(30), anreisedatum date, abreisedatum date, kundennr integer, gebuchteezimmer integer, gebuchtedzimmer integer, PRIMARY KEY (buchungnr), FOREIGN KEY (kundennr) REFERENCES Kunde, FOREIGN KEY (stadt, land, adresse) REFERENCES Hotel, CHECK (gebuchteezimmer >= 0), CHECK (gebuchtedzimmer >= 0), CHECK (gebuchteezimmer+gebuchtedzimmer > 0), CHECK (anreisedatum < abreisedatum) ); Frank Eichinger IWM Übung 1 25

26 Aufgabe 1c) Hinzufügen eines neuen Attributes ALTER TABLE Entfernung ADD masseinheit varchar(10); Bereits existierende Tupel erhalten als Wert für das neue Attribut den Wert null Problem: Neues Attribut soll als not null definiert werden. Default-Wert für existierende Tupel ALTER TABLE Entfernung ADD masseinheit varchar(10) NOT NULL default 'Kilometer'; Frank Eichinger IWM Übung 1 26

27 Aufgabe 1d) i)entfernung und Hotel haben Fremdschlüssel auf Stadt. Solange Entfernung oder Hotel Einträge mit Fremdschlüsseln enthalten, die NOT NULL sind, ist ein DROP TABLE von Stadt nicht möglich. ii) Viele Möglichkeiten: Einfügen einer Buchung mit gebuchteezimmer < 0 Einfügen eines Tupels mit bereits existierendem Primärschlüssel Einfügen eines Tupels mit nicht existierendem Fremdschlüssel Frank Eichinger IWM Übung 1 27

28 Aufgabe 2a) Studenten CREATE TABLE Student ( matnr integer NOT NULL, name varchar(30), adresse varchar(50), studienfach varchar(30), PRIMARY KEY (matnr), CHECK (matnr > 0), CHECK (studienfach IN ('Informatik', 'Maschinenbau',...)) ); Frank Eichinger IWM Übung 1 28

29 Aufgabe 2a) Professoren CREATE TABLE Professor ( name varchar(30) NOT NULL, fakultät varchar(30) NOT NULL, fachgebiet varchar(50), PRIMARY KEY (name), CHECK (fachgebiet IN ('Informatik', 'Maschinenbau',...)) ); Frank Eichinger IWM Übung 1 29

30 Aufgabe 2a) Mitarbeiter CREATE TABLE Mitarbeiter ( name varchar(30) NOT NULL, chef varchar(30), zimmernr integer, PRIMARY KEY (name), FOREIGN KEY (chef) REFERENCES Professor ON DELETE SET NULL ); Frank Eichinger IWM Übung 1 30

31 Aufgabe 2a) Veranstaltung CREATE TABLE Veranstaltung ( nummer integer NOT NULL, typ varchar(20), name varchar(30), dozent varchar(30), hoersaal varchar(20), PRIMARY KEY (nummer), FOREIGN KEY (dozent) REFERENCES Professor ON DELETE SET NULL, CHECK (typ IN ('Vorlesung', 'Uebung',...)), CHECK (nummer > 0) ); Frank Eichinger IWM Übung 1 31

32 Aufgabe 2b) Einfügen von Tupeln INSERT INTO Student VALUES ( , 'Hans Schmidt', 'Baumweg 3, Karlsruhe', 'Informatik'); INSERT INTO Student VALUES ( , 'Tim Mueller', null, 'Maschinenbau'); INSERT INTO Student (name, matnr, studienfach) VALUES ('Fred Sachs', , 'Informatik'); Frank Eichinger IWM Übung 1 32

33 Aufgabe 2b) Löschen von Tupeln DELETE FROM Student WHERE adresse IS NULL; DELETE FROM Student WHERE matnr IN (SELECT matnr FROM Student WHERE adresse IS NULL) DELETE FROM Student; Ändern von Tupeln UPDATE Student SET name = 'Willi Winzig' WHERE matnr = ; Frank Eichinger IWM Übung 1 33

34 Aufgabe 2c) Annahme: Es wird häufig nach der Belegung von Hörsälen gefragt CREATE INDEX hs_index ON Veranstaltung(hoersaal); Annahme: Es werden häufig alle Mitarbeiter eines Professors gesucht CREATE INDEX ma_index ON Mitarbeiter(chef); Frank Eichinger IWM Übung 1 34

35 Aufgabe 2d) "unique"-index auf matnr CREATE UNIQUE INDEX matnr_index ON Student(matNr); Forderung: Kein Wert für das indexierte Attribut darf mehrmals in der Tabelle auftreten Sonst: Abbruch Bemerkung: "unique"-indexe vor allem für Schlüssel sinnvoll Frank Eichinger IWM Übung 1 35

36 Aufgabe 2e) Die folgende CHECK-Klausel tritt mehrfach auf: CHECK (studienfach IN (...)) in den Relationen Student und Professor Das ist eine Form von Redundanz die durch die Verwendung eines gemeinsamen Datentyps verhindert werden kann! CREATE DOMAIN Fachrichtung AS varchar CHECK (studienfach IN ('Informatik', 'Maschinenbau',...)); Frank Eichinger IWM Übung 1 36