Kapitel 12. Warum DB-Systeme, nichtrelationale Datenmodelle. Prof. Dr. Wolfgang Weber, Vorlesung Datenbanken 1

Transkript

1 Kapitel 12 Warum DBSysteme, nichtrelationale Datenmodelle 1

2 Eigenschaften von DBSystemen im Vergleich zu Dateisystemen DBSystem Dateisystem Abstraktionsebene: logisch (DBSystem auf physischer Ebene kümmert sich um (Nutzer muss sich um physische Speicherung, z. B. alle Daten Speicherung kümmern) zur Firma in einer DB) Abspeicherung: in einer oder mehreren in mehreren Dateien Datenbanken des Unter (jeder hat seine privaten nehmens Dateien) Beschreibung der Daten: im Data Dictionary, d. h. im Anwendungsprogramm zentral für alle Anwendungsprogramme Zugriff / Mehrbenutzersynchronis. über DBS (Kontrolle hat DBS) über BS / eigene Programmierung Dienstprogramme über DBS i. d. R. eigene Programmierung (Backup, Recovery) Verknüpfungen zwischen Daten über DBS i. d. R. eigene Programmierung Entwicklungstools (GUI etc.) teilweise integriert in DBS isolierte Entwickungstools 2

3 Wie arbeiten Anwendungsprogramme mit Dateien / mit DB? Anwendungs Progr 1? Anwendungs Progr 2. Anwendungs Progr 3... Anwendungs Progr n 3

4 Arbeiten mit Dateien Datei A Datei B... Datei Z Anwendungs Progr. 1 Anwendungs Progr. 2 Anwendungs Progr Anwendungs Progr. n Datenstruktur (DS) ist im Programm definiert. Änderung DS Änderung in allen Anwendungsprogrammen, die mit Datei arbeiten (keine Datenunabhängigkeit)! Jeder Nutzer der Daten muss physische Struktur kennen. Arbeiten mit einem DBS Anwendungs Progr. 1 Daten (DB) DBMS Anwendungs Progr. 2 Anwendungs Progr. 3 DBMS kennt logische und physische Datenstruktur DBMS ist auch Zugriffsfilter (Sichten)... Anwendungs Progr. n 4

5 Vergleichendes Beispiel zu DBSystem / Dateisystem DBSystem: SELECT name, plz, ort FROM WHERE kunde ort = Darmstadt, Dateisystem (in C++): #include <fstream.h>.. typedef struct { char name [30]; int plz; char ort [30]; char telnr [20]; //obwohl: nicht benötigt } kunde_record; kunde_record buffer; fstream kunden_file; file.open ( kunden.dat, ios::in ios::binary); while (!file.eof()) { file.read( (char*) &buffer, sizeof(kunde_record) ); if buffer.ort = Darmstadt { cout << buffer.name << buffer.plz << } } 5

6 Auswirkungen von Änderungen in normalen Dateien Frage: Welche Auswirkungen haben Änderungen in der Datenstruktur von Dateien auf die die Dateien verwendenden Anwendungsprogramme? z. B. Einfügung Vorname 6

7 Auswirkungen von Änderungen in normalen Dateien Frage: Welche Auswirkungen haben Änderungen in der Datenstruktur von Dateien auf die die Dateien verwendenden Anwendungsprogramme? Änderungen in den Anwendungsprogrammen notwendig, da Dateibeschreibung in allen Programmen, die die Datei verwenden, redundant abgelegt sind. d. h. 5 Programme arbeiten mit einer Datei, 1 Programm benötigt zusätzliches Feld => alle 5 Programme müssen geändert werden. 7

8 Was sind Metadaten? Es gibt die eigentlichen Daten: Krefelder Töpfermarkt, Krefeld, , Wenn man die Daten so hinschreibt, weiß man noch nicht, was die Daten bedeuten, in welchen Formaten sie gespeichert werden etc. Abhilfe: Man gibt die Bedeutung, Formate etc. immer mit den Daten an: Relation Markt besteht aus: Bezeichnung: Krefelder Töpfermarkt, char(30); Standort: Krefeld, int; Geht Richtung XML: <Markt> <Bezeichnung>Krefelder Töpfermarkt</Bezeichnung> <Standort>Krefeld</Standort> <Termin> </Termin> <Oeffnungszeiten>820 Uhr</Oeffnungszeiten> <URL> </Markt> 8

9 Was sind Metadaten? Lösung in DBSystemen: Die Daten haben immer wieder gleichen Aufbau Man trennt Beschreibung des Aufbaus der Daten von den eigentlichen Daten Man unterscheidet zwischen: eigentlichen Daten in der Datenbank und Metadaten Metadaten werden in der Schemabeschreibung abgelegt: Beispiel: Relation Markt mit Attributen Bezeichnung char(30); Standort int; Diese Beschreibungen stehen im DataDictionary des DBS. Krefelder Töpfermarkt, Krefeld, , Darmstädter Töpfermarkt, Darmstadt, ,... sind die eigentlichen Daten 9

10 Warum DBS? (1) Redundanzvermeidung: Ein Fakt in der realen Welt ist nur ein Mal in der DB abgelegt. Warum? > siehe Kapitel ERD, Normalisierung Verringerung von Inkonsistenzen (keine widersprüchlichen Informationen zum gleichen Objekt): Wenn z. B. eine Person mit Adresse doppelt vorkommen würden, könnte nach einem Umzug der Person die eine Adresse geändert sein, die andere wäre noch auf dem alten Stand. Beispiel: bestell.dat: , Meyer, 64288, Bensheim, < geändert, da umgezogen kunden.dat: Meyer,64295, Darmstadt, < aus Versehen nicht geändert Frage: Wie modellieren wir, um dies zu vermeiden? Einheitliche Sicht auf die Daten Standards durchsetzbar 10

11 Warum DBS? (2) Datenunabhängigkeit: Anwendungen müssen sich nicht um Details der Speicherstruktur und Zugriffstechniken kümmern. (physische Datenunabhängigkeit) Änderungen z. B. von Speicherstrukturen (physische Datenunabhängigkeit), Attributanzahl etc. (logische Datenunabhängigkeit) sind (oft) ohne Auswirkungen auf Anwendungsprogramme. Beispiel: Länge des Nachnamens wird von 30 auf 40 Zeichen gesetzt oder zusätzliches Attribut Qualifikation wird eingeführt. Streichen eines Attributs ist auch in DBSystemen oft ohne Auswirkungen auf Anwendungsprogramme nicht möglich! Spontane Abfragen mit Hilfe des Dialogabfragesystems Beispiel: Selektiere alle Mitarbeiter, die mehr als verdienen. Zugriffskontrolle bei parallelen Zugriff: Benutzung von Daten durch mehrere Programme gleichzeitig mit Kontrolle der Zugriffe, so dass z. B. keine Lost Updates entstehen (Lesen Müller durch Ben. A, Lesen Müller durch Ben. B, Ändern Geh. und Zurückschreiben durch Ben. A, Ändern Geh. und Zurückschreiben durch Ben. B => Änderung von Ben. A wäre verloren!) Beispiel: Änderung des Gehalts von Müller durch A: + 10%, durch B: Frage: Welcher Update geht verloren? 11

12 Warum DBS? (3) Datensicherheit: Schutz vor systembedingten Fehlern wie Stromausfällen, Systemabstürzen, Softwarefehlern Datenschutz: Schutz der Daten vor unerlaubter Nutzung oder böswilliger Manipulation oder Löschung durch Zugriffskontrolle, d. h. Setzen von Sperren, durch DBS auch auf Feld und Satzebene (nicht nur Read, WriteSperren ganzer Dateien) Beispiel: Nur Personalabteilung dürfen Gehälter der Mitarbeiter sehen. Integritätskontrolle: Schutz der Konsistenz der Daten vor unbeabsichtigten Eingabefehlern. Kontrolle von Integritätsbedingungen durch DBS (z. B. Wertebereiche, Existenzabhängigkeiten zwischen Datensätzen, allg. Bez. zwischen Werten) Beispiel: Alter von Mitarbeitern muss immer > 14 sein. Nachname ist max. 30 Zeichen lang. Zu Fremdschlüsselwert muss in anderer Relation Schlüsselwert existieren. 12

13 Warum DBS? (4) Beziehungen zwischen Daten: können definiert und vom System kontrolliert werden. (referenzielle Integrität) Beispiel: Bestellung hat Beziehung zu Kunde. Zu Bestellung gibt es immer einen Kunden Verteilung von Daten: kann vom DBS verwaltet werden. Multiple Datensichten: Jede Anwendung kann eine eigene (externe) Sicht auf die Daten haben. 13

14 Unterschied DB, DBS? Datenbank (DB) = Datenbestand Datenmanagementsystem (DBMS) = Software zum Arbeiten mit Datenbanken Datenbanksystem (DBS) = DB + DBMS aber: oft synonym zu DBMS verwendet. 14

15 Gruppen von Personen, die mit dem DBS arbeiten DatenAdministrator (DA) / DatenbankDesigner Hat zentrale strategische Verantwortung für die Daten. Entscheidet welche Daten für wen gespeichert werden. DatenbankAdministrator (DBA) Hat technische Verantwortung. Entscheidet, wie Daten gespeichert werden. Anwendungsentwickler Entwickelt Anwendung z. B. in Programmiersprache. Arbeitet hinsichtlich der Definition von Daten mit DBA, DA zusammen. Endanwender Hat Zugriff auf Daten über GUIs / Abfragesprache. Zusammenarbeit mit Anwendungsentwickler in Entwicklungsphase. 15

16 Historische Entwicklung von Datenbanksystemen 1965: Firma IBM entwickelt das DBS: IMS, das auf dem Hierarchischen Datenmodell beruht 1969 Standardisierungsgremium CODASYL schlägt Netzwerkmodell vor 1976: Firma SIEMENS (UDS) u.v.a. entwickeln DBS nach dem NetzwerkDatenmodell seit 1970: Codd definiert das Relationale Datenmodell : IBM entwickelt Prototyp für Relationales Datenbanksystem, Name: System /R mit Datenbanksprache: Sequel (~SQL) seit 1980: ORACLE, Relationales DBS mit SQL als Datenbanksprache auf dem Markt seit 1982: SQL/DS der Firma IBM mit SQL auf dem Markt seit 1984: Relationale DBS für PCs auf dem Markt: DBASE, ACCESS auch ORACLE seit Ende der 80er: Entwicklung Objektorientierter DBS: GEMSTONE, ObjectStore, O2, POET (jetzt: FastObjects) u.v.a. 1992: SQL2Standard wird verkündet; gleichzeitig Arbeit an einer OOErweiterung von SQL (Objektrelationale DBMS). Arbeitsname: SQL3 1999: XMLDatenbanken aktuelle Situation: ClientServer Prinzip beim Einsatz von Datenbanksystemen, Einsatz von Datenbanksystemen in integrierten Softwaresystemen (hauptsächlich noch immer: Relationale DBSysteme), Objektorientiertes Mapping (OO <> relational) 16

17 Hierarchisches Datenmodell 1:nBeziehungen Schema des hierarchischen Datenmodells Dekor (0,*) 7 ist versehen mit (1,1) Produkt Beziehungen zwischen den konkreten Datenobjekten: Pflanzendekor Tierdekor Tasse S22 Teller S22 Untertasse S22 Vase S17 Vase S23 17

18 Hierarchisches Datenmodell Navigation Pflanzendekor Tierdekor Tasse S22 Teller S22 Untertasse S22 Vase S17 Vase S23 get unique <Schlüsselwert> get next get next within parent get hold... insert delete replace get unique Dekor ( DekorNr = S22 ); get next within parent; get next; get next within parent; get next; Ergebnis? 18

19 Hierarchisches Datenmodell n:mbeziehungen Problem: Realisierung von n:mbeziehungen E/RModell Kunde (0,*) (0,*) 7 Produkt 7: erhält geliefert Hierarchisches Modell: Kunde Produkt Nicht hierachische Beziehungen nur kompliziert und mit Einschränkungen realisierbar Bedeutung Pfeil: 1:nBeziehung Lieferung 19

20 NetzwerkDatenmodell n:m Beziehungen Wie bei Relationenmodell: Auflösung von n:mbeziehungen in zwei 1:nBeziehungen (0,*) (0,*) E/RModell Kunde 7 Produkt 7: erhält geliefert Netzwerkmodell Kunde Produkt OwnerRecordTyp erhält geliefert wird geliefert SetTyp Lieferung MemberRecordTyp 20

21 NetzwerkDatenmodell Navigation Kopplung der Recordtypen nicht wie beim Relationenmodell durch SchlüsselFremdschlüssel, sondern: durch Zeiger (SetTypen) Lieferung 07 Tasse S22 Kunde 1 Lieferung 11 Lieferung 12 wird_geliefert Teller S22 erhält_geliefert Lieferung 08 Kunde 2 Lieferung 10 Anfrage: Finde alle Produkte, die an den Kunden Meier geliefert werden. Vase S17 Bedeutung Pfeil: Zeiger 21

22 NetzwerkDatenmodell Navigation Kunde 1 Kunde 2 erhält_geliefert Lieferung 07 Lieferung 11 Lieferung 12 Lieferung 08 Lieferung 10 wird_geliefert Tasse S22 Teller S23 Vase S17 find x record by calckey find owner of current x set find next y record within current x set Anfrage: Finde alle Produkte, die an den Kunden mit Kundennummer =1 geliefert werden: KNR sei der calckey im Record Kunde Kunde.KNR := 1; find Kunde record by calckey; while not fail do begin find next Lieferung record within current erhält_geliefert; find owner of current wird_geliefert set; get Produkt;... end; 22

23 Objektorientierte DBS 1:n Beziehungen FastObjects/C++ Notation UML Klassendiagramm: Markt 0.. * Ansprechpartner Veranstalter Markt (Bezeichnung, Standort, Kategorie) Veranstalter (Name, Typ) persistent class Markt { PtString Bezeichnung, Standort; int Kategorie; Veranstalter* derveranstalter; public : Markt (char*, char*, int, Veranstalter*);... }; persistent class Veranstalter { PtString Name; int Typ; cset <Markt*> diemaerkte; public : Veranstalter (char*, int);... void Append (Markt*); Methoden der Klasse }; in OOP,OOD: Welche Mögl. der Realisierung d. Bez.? Bemerkung: Wir können allerdings auch Klassen mit noch komplexeren Strukturen innerhalb der Klasse definieren! 23

24 Objektorientierte DBS Navigation Gesucht: Alle MarktStandorte, die vom Veranstalter Meyer organisiert werden. select m.standort from m in AlleMaerkte, v in m.derveranstalter where v.name = Meyer AlleMaerkte Ergebnis: { Sommerhausen, Krefeld } AlleVeranstalter B: Int. Töpfermarkt S: Krefeld K: Töpfermarkt derveranstalter: B: Töpfermarkt S: Sommerhausen K: Töpfermarkt derveranstalter: B: Int. Töpfermarkt S: Hanau K: Töpfermarkt derveranstalter: Zeiger Name: Meyer Typ: 2 diemaerkte: Name: Schulze Typ: 3 diemaerkte: 24

25 XMLDatenbanken Beispiel eines XMLDokuments XMLDokument ist einfache Textdatei: Kopfzeile mit XMLVersion, verwendeten Zeichensatz (UTF8 ist Defaultwert kann weggelassen werden) und Angabe, dass DTD existiert <?xml version= 1.0 encoding= UTF8 standalone = no > <!doctype Markt SYSTEM markt.dtd > <Markt> <Bezeichnung>Krefelder Töpfermarkt</Bezeichnung> <Standort>Krefeld</Standort> <Termin> </Termin> <Oeffnungszeiten>820 Uhr</Oeffnungszeiten> <URL> </Markt> Verweis auf Strukturdaten Daten 25

26 XMLDTD Das zu dem obigen XMLDokument Markt passende Document Type Definition (DTD) mit Angabe des Formats: <?xml version="1.0" encoding="utf8"> <!ELEMENT Bezeichnung (#PCDATA)> <!ELEMENT Standort (#PCDATA)> <!ELEMENT Termin (#PCDATA)> <!ELEMENT Oeffnungszeiten (#PCDATA)> <!ELEMENT URL (#PCDATA)> <!ELEMENT Markt (Bezeichnung, Standort?, Termin?, Oeffnungszeiten+, URL?)> mehrere Märkte: <!ELEMENT Maerkte (Markt+)> 26

27 XMLSchema <xs:element name="markt"> <xs:complextype> <xs:sequence> <xs:element name="bezeichnung" type="xs:string"/> <xs:element name="standort" type="xs:string"/> <xs:element name="oeffnungszeiten" type="xs:string"/> <xs:element name="termin" type="xs:string"/> <xs:element name="url" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> mehrere Märkte: <xs:element name="maerkte"> <xs:complextype> <xs:sequence> <xs:element ref="markt" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> </xs:element> XMLNamespace = xs 27

28 XML n:mbeziehung Extensible Linking Language (XLink) Produkt Nummer Bezeichnung Grösse Fassungsvermögen Preis Funktion Foto + getanzverkauft () : int : int : String : double : double : double : int : BLOB 1..* 0..* Markt Bezeichnung Standort Termin von Termin bis URL Kategorie Ranking Standgebühr pro qm + getdauer () : int : String : String : Date : Date : String : int : int : double Angebot Anzahl : int 28

29 XML n:mbeziehung Extensible Linking Language (XLink) <!ELEMENT Markt (Bezeichnung, Standort, Termin, Oeffnungszeiten, URL)> <!ATTLIST Markt Nr ID #REQUIRED>... <!ELEMENT Produkt (...)> <!ATTLIST Produkt Nr ID #REQUIRED>.... <!ELEMENT WirdAngebotenAuf (Anzahl)> <!ATTLIST WirdAngebotenAuf Produkt Nr IDREF #REQUIRED Markt Nr IDREF #REQUIRED> eindeutigen Identifikation Bezug auf eindeutigen Identifikation 29