Datenbanksysteme
Werbung
Datenbanksysteme Prof. Dr. Stephan Kleuker Kernziele: • Entwicklung einer relationalen Datenbank (von Anforderungsanalyse über Realisierung zur Nutzung) • Steuermechanismen von Datenbanken Datenbanksysteme Prof. Dr. Stephan Kleuker 1 Überblick 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Grundbegriffe Datenbanken Grundlagen der Enitity-Relationship-Modellierung Spezielle ER-Modelle und Tabellenableitung Normalformen SQL: Erstellen von Tabellen SQL: Einfache Anfragen SQL: Komplexere Anfragen SQL: Gruppierung und Analyse von NULL-Werten Einführung in PL/SQL Cursor und Trigger in PL/SQL JDBC Views und Datenbankverwaltung Integrität innerhalb der DB Wiederholung: Anfragen in SQL arbeitsaufwändig intuitiv Datenbanksysteme 1 2 3 4 5 6 7 Prof. Dr. Stephan Kleuker 8 9 10 11 12 13 14 2 Ich • Prof. Dr. Stephan Kleuker, geboren 1967, verheiratet, 2 Kinder • seit 1.9.09 an der HS, Professur für SoftwareEntwicklung • vorher 4 Jahre FH Wiesbaden • davor 3 Jahre an der privaten FH Nordakademie in Elmshorn • davor 4 ½ Jahre tätig als Systemanalytiker und Systemberater in Wilhelmshaven • [email protected], Raum SI 0109 Datenbanksysteme Prof. Dr. Stephan Kleuker 3 Ablauf • 2h Vorlesung + 2h Praktikum = 5 CP d. h. etwa 150 Arbeitsstunden • Praktikum : – Anwesenheit = (Übungsblatt vorliegen + Lösungsversuche zum vorherigen Aufgabenblatt) – Übungsblätter mit Punkten (Σ Σ ≥ 100), zwei Studis als Team (gemeinsam planen, getrennt lösen) – Praktikumsteil mit 80 oder mehr Punkten bestanden • Prüfung: Klausur recht kurz nach der Vorlesungszeit • Folienveranstaltungen sind schnell, bremsen Sie mit Fragen • von Studierenden wird hoher Anteil an Eigenarbeit erwartet Datenbanksysteme Prof. Dr. Stephan Kleuker 4 Verhaltenscodex • • • • Rechner sind zu Beginn der Veranstaltung aus Handys sind aus Wir sind pünktlich Es redet nur eine Person zur Zeit • Sie haben die Folien zur Kommentierung in der Vorlesung vorliegen, zwei Tage vor VL abends mit Aufgaben im Netz, Aufgabenzettel liegen in der Übung vor (Ihre Aufgabe), auch http://www.edvsz.hs http://www.edvsz.hs://www.edvsz.hs-osnabrueck.de/skleuker/index.html • Probleme sofort melden • Wer aussteigt, teilt mit, warum Datenbanksysteme Prof. Dr. Stephan Kleuker 5 Literatur 1/2 (es könnte aktuelle Auflagen geben) • Zur Vorlesung extrem gut passend ☺ [KL] S. Kleuker, Grundkurs Datenbankentwicklung, Vieweg+Teubner, 2. Auflage, 2011 (als PDFs über Bibliotheks-Link verfügbar) • Sehr gelungene Bücher mit tieferen Einblicken A. Kemper, A. Eickler, Datenbanksysteme, 8. Auflage, Oldenbourg, 2011 R. Elmasri und S. B. Navathe, Grundlagen von Datenbanksystemen, 3. Auflage, Pearson/Addison Wesley, 2009 M. Schubert, Datenbanken: Theorie, Entwurf und Programmierung relationaler Datenbanken, 2. Auflage, Vieweg+Teubner, 2007 Matthiessen, Unterstein, Relationale Datenbanken und SQL, 4. Auflage, Addison-Wesley, 2007 Datenbanksysteme Prof. Dr. Stephan Kleuker 6 Literatur 2/2 (es könnte aktuelle Auflagen geben) • Eigentlich für Nicht-Informatiker, deshalb aber auch für DB-Einsteiger geeignet R. Steiner, Grundkurs Relationale Datenbanken, 7. Auflage, Vieweg+Teubner, 2009 • Nicht als Einstieg, aber als preiswertes Nachschlagewerk G. Kuhlmann, F. Müllmerstadt, SQL, Rowohlt Tb., 3. Auflage, 2004 • Kurzreferenz zu PL/SQL (lesenswert) S. Feuerstein, B. Pribyl, C. Dawes, Oracle PL/SQL Language Pocket Reference, O'Reilly, 2007 • Für den tiefen Einstieg in PL/SQL S. Feuerstein, B. Pribyl, Oracle PL/ SQL Programmierung, O'Reilly, 2003 Datenbanksysteme Prof. Dr. Stephan Kleuker 7 Warum Datenbanken? Warum haben wir überhaupt ''Datenbanken''? • Dateien und Dateisysteme sind doch gut genug? • Oder? Beispiel Arbeitsprozesse: In einem kleinen Unternehmen findet die Datenverwaltung ohne Software statt. Das Unternehmen wickelt Bestellungen ab, die mehrere Artikel umfassen können und in schriftlicher Form vorliegen. Um schnell reagieren zu können, werden auch nicht vollständige Bestellungen versandt und dem Kunden mitgeteilt, dass die weiteren Artikel nicht lieferbar sind. Der Kunde müsste bei Bedarf diese Artikel wieder neu bestellen. Zur Analyse der Abläufe möchte man eine Übersicht haben, wie viele Bestellungen ein Kunde gemacht hat und wie hoch seine bisherige Bestellsumme war. Weiterhin soll bekannt sein, wie häufig ein Artikel bestellt wurde und wie häufig dieser Artikel nicht vorrätig war, obwohl eine Bestellung vorlag. Beschreiben sie den Arbeitsablauf ohne SW mit seinen möglichen Alternativen, so dass alle Informationen erfasst werden können. Datenbanksysteme Prof. Dr. Stephan Kleuker 8 Was ist eine Datenbank (informell) Unter einer Datenbank wird eine Sammlung von Daten verstanden. Eine Datenbank entspricht einem elektronischen Aktenschrank, auf dem der Benutzer eine Reihe von Operationen ausführen kann. Der Benutzer hat die Möglichkeit, neue „Dateien“ (Datenschemata) anzulegen, Datensätze hinzuzufügen, zu ändern oder zu löschen und Datensätze herauszusuchen. Forderung 1: Garantie von Persistenz Forderung 2: Anlegen von Datenschema (Tabellen) Forderung 3: Einfügen, Löschen, Ändern von Daten Forderung 4: Strukturiertes Lesen von Daten Datenbanksysteme Prof. Dr. Stephan Kleuker 9 Was ist ein Datenbank-Management-System • Ein Datenbank-Management-System (DBMS) umfasst die Gesamtheit an Programmen, die zum Aufbau, zur Nutzung und zur Verwaltung von Datenbanken notwendig ist. • Das DBMS ermöglicht verschiedenen Benutzergruppen einen einfachen Zugang zu den gespeicherten Datenbeständen. Kürzel Begriff Erläuterung DB Datenbank Strukturierter, von DBMS verwalteter Datenbestand DBMS DatenbankManagement-System SW zur Verwaltung von Datenbanken DBS Datenbanksystem DBMS plus Datenbank(en) Datenbanksysteme Prof. Dr. Stephan Kleuker 10 DBS = DBMS kapselt DB [KL] Datenbank-Managementsystem erweiterte Funktionalität Schema anlegen Daten bearbeiten Daten auslesen Datenbanksysteme Prof. Dr. Stephan Kleuker Datenbank 11 Aufgaben eines DBMS (1/3) • Operationen – Speichern, Suchen, Ändern, Löschen • Integration – einheitliche Verwaltung aller Daten, z. B. enthalten alle Bestellungen die gleichen Daten – Möglichkeit zur redundanzfreien Datenhaltung, z. B. jede Bestellung wird durch eine eindeutige Nummer identifiziert • Konsistenzüberwachung (Integritätssicherung) – Garantie der Korrektheit bei Datenbankänderungen – z.B. abhängige Daten werden mit verändert Datenbanksysteme Prof. Dr. Stephan Kleuker 12 Aufgaben eines DBMS (2/3) • Benutzersichten – Unterschiedliche Anwendungen benötigen unterschiedliche Sichten – z.B. nur bestimmte Teildaten – z.B. bestimmte Übersichten • Zugriffskontrolle – welcher Nutzer darf auf welche Daten in welcher Form zugreifen • Katalog – Verwaltung der Information welche Informationen in der DB vorhanden sind – z.B. Aufbau von Tabellen – z.B. Randbedingungen, die durch Daten eingehalten werden müssen Datenbanksysteme Prof. Dr. Stephan Kleuker 13 Aufgaben eines DBMS (3/3) • Transaktionen – Zusammenfassung von Datenbankänderungen zu einer Aktion, deren Effekt bei Erfolg permanent in der DB gespeichert werden soll • Synchronisation – konkurrierende Transaktionen mehrerer Benutzer müssen synchronisiert werden, um gegenseitige Beeinflussungen zu vermeiden • Datensicherung – Ermöglichung der Systemwiederherstellung z.B. nach einem Systemabsturz Datenbanksysteme Prof. Dr. Stephan Kleuker 14 Entwicklung von Datenbanken (1/2) 1. Klassisch ohne spezielle Verwaltung 2. Nutzung von Dateiverwaltungssoftware für Dateien Anwendung 1 Datei 1 Anwendung 1 Anwendung 2 ... Datei 2 Prof. Dr. Stephan Kleuker ... ... Datei 2 Dateiverwaltungssystem 1 Datei 1 Datenbanksysteme Anwendung 2 ... Anwendung n Datei m Anwendung n Dateiverwaltungssystem j ... Datei m 15 Entwicklung von Datenbanken (2/2) 3. Einführung eines Datenbank-Management-Systems (DBMS) Anwendung 1 Anwendung 2 ... Anwendung n DBMS Datenbank Datenbanksysteme Prof. Dr. Stephan Kleuker 16 Einsatz von DBMS Wie werden Datenbankmanagementsysteme verwendet? • Betriebliche Anwendungen • Web-Anwendungen • Spezialprogramme • Handy-Programme • ... Als Teil eines Informationssystems ist die Gesamt-Architektur entscheidend: • heute typischerweise Client/Server-Architekturen Datenbanksysteme Prof. Dr. Stephan Kleuker 17 Beispiele für DBMS • • IBM Oracle • Microsoft • Sybase • Informix / IBM • MySQL /MariaDB • SAP • PostgreSQL • Apache • SQLite • Firebird • Lotus • Datenbanksysteme … DB2 UDB (relational, OO, XML) Oracle 11g (relational, OO, XML) Berkeley DB (auch XML-Variante) SQL-Server 20xx (MSSQLServer 2012) Access / Visual FoxPro Sybase Informix Oracle / freier Fork MaxDB (SAP-DB, Adabas) PostgreSQL Apache Derby SQLite Firebird, freier Ableger von InterBase Lotus Domino Server / Lotus Notes Prof. Dr. Stephan Kleuker 18 Datenbankarten • letzte Folie „relationale Datenbanken“ (vereinfacht: beliebige Verknüpfung einfacher Tabellen) • ist der deutlich am weitetesten verbreitete Anteil • gibt andere Arten von Datenbanken für spezielle Aufgaben – hierarchisch, netzwerkartig (historisch interessant) – objektorientiert (einfache Verknüpfung mit OO) – dokumentenorientiert (Fokus auf zusammenhängende Daten, typisch No[t only]SQLDatenbanken) – XM-basiert, verteilt, … • Hinweis: Vertiefung Prof. Dr. Heiko Tapken Datenbanksysteme Prof. Dr. Stephan Kleuker 19 Überblick DB-Entwurf Grob sind die Einzelschritte: • die logische Datenmodellierung • die physische Datenmodellierung • der Aufbau einer Datenbank, sowie • der Betrieb (Administration, Konfiguration) derselben Datenbanksysteme Prof. Dr. Stephan Kleuker 20 Nächste Schritte • Auswahl, Kauf, Installation, Konfiguration eines DBMS • Anlegen der Datenbank, Einspielen der Daten, ... • Administration • Leistungsoptimierung • Sicherheitsaspekte • Anwendungsentwicklung • Backup, Replikation, Clustering, Recovery, ... • Aufgabe: Überlegen Sie Kriterien, die bei der Auswahl eines DBMS eine Rolle spielen Datenbanksysteme Prof. Dr. Stephan Kleuker 21 ANSI/SPARC-Modell Anwendung 1 Anwendung 2 Externe Ebene Externe Ebene Transformationsregeln logische Ebene Transformationsregeln physische Ebene Datenbanksysteme Prof. Dr. Stephan Kleuker 22 Überblick über Ebenen [KL] Sichten (Ein- und Ausgabemasken) externe Ebene Tabellen und Abhängigkeiten logische Ebene Konfiguration / DB-Einrichtung physische Ebene Datenbanksysteme <table name="Artikel"> <size> 5G <\size> <\table> Prof. Dr. Stephan Kleuker 23 Externe Ebene Dies ist die Benutzersicht auf die Daten: Anwender sieht nur die Daten und Beziehungen, die in seinem externen Modell vom Anwendungsadministrator definiert sind. • Der logische Inhalt des externen Modells ist vollständig aus dem konzeptionellen Modell ableitbar. • Im externen Modell können Felder vorhanden sein, die im logischen Modell fehlen (berechnete Felder). • Typischer Teil der Benutzersicht: Masken zur Einund Ausgabe von Daten • Datenbanksysteme Prof. Dr. Stephan Kleuker 24 Logische (konzeptionelle) Ebene Zentraler Inhalt ist das logische Datenmodell: • • • • • Beschreibt die Daten der Miniwelt auf logischer Ebene (Datenobjekte, Integritätsregeln, ...). Bezugspunkt für alle Anwendungen Logische Datenunabhängigkeit Anwendungsübergreifendes Datenmodell Im relationalen Modell kann man sich Tabellen vorstellen, die die Basisinformationen beinhalten Datenbanksysteme Prof. Dr. Stephan Kleuker 25 Physische Ebene (auch interne Ebene) Definiert die Speicherstruktur der Daten: • Hier wird die physische Datenorganisation festgelegt • Festlegung von internen Datensatztypen, Verkettungsmechanismen, physische Indizierung etc. • Ist direkt oberhalb der Ressourcenverwaltung durch das Betriebssystem angesiedelt • Die Güte des internen Schemas hat wesentlichen Einfluss auf die Leistung des Gesamtsystems • hier hat DB-Administrator Möglichkeiten zur Optimierung und Pflege der Datenbank Datenbanksysteme Prof. Dr. Stephan Kleuker 26 Wozu ANSI/SPARC-Dreischichtenmodell? Dieses ANSI/SPARC-Modell stammt von 1975 (ANSI/X3/SPARC Study Group on Data Base Management Systems, FDT ACM SIGMOD 7,2 (1975)) Wozu ist das gut? • Änderungen an der internen Darstellung können vorgenommen werden, ohne die konzeptionelle Ebene zu berühren • Ebenso ist es möglich, Teile der konzeptionellen Schicht zu ändern, ohne die Benutzersichten zu berühren höhere Robustheit gegenüber Änderungen Datenbanksysteme Prof. Dr. Stephan Kleuker 27 Nutzer und Entwickler der Ebenen [KL] Nutzer Entwickler externe Ebene Oberflächen-Designer Endnutzer logische Ebene Datenbank-Entwickler physische Ebene DatenbanksoftwareEntwickler DatenbankAdministrator Datenbanksysteme Prof. Dr. Stephan Kleuker 28 Beispiel: Datenbank Hochschule • Logische Ebene (z.B. Tabellen) – Studi (studid: int, name: string, login: string, alter: int) – Kurs (kursid: int, kname: string, stunden: int) – Fachbereich (fbid: int, fbname: string, budget: real) – Lehrt (fbid: int, kursid: int) – Eingeschrieben (studid: int, kursid: int) • Physische (interne) Ebene – Speicherung der Relationen als Files: unsortierte Menge von physischen Records – Index auf der ersten Spalte von Studis und Kurse zur Beschleunigung des Datenzugriffs • Externe Ebene (View) – Anfragemaske: Wie viele Studenten haben sich in jedem Kurs eingeschrieben? – Kurs_Info (kursid: int, einschreibanzahl: int) Datenbanksysteme Prof. Dr. Stephan Kleuker 29 2. Grundlagen der Entity-Relationship-Modellierung • Was ist ein Modell • Was sind Entitäten • Was sind Relationen • Was sind Attribute Datenbanksysteme Prof. Dr. Stephan Kleuker 30 Konzeptioneller Entwurf (logische Ebene) Der konzeptionelle Datenbankentwurf ist dem Modellieren in den Naturwissenschaften und der Technik ähnlich: Ein Modell wird konstruiert um das Verständnis zu verbessern und um Details zu abstrahieren. Verständnis: Die Bedeutung der Daten und ihre Beziehungen untereinander als Informationsstrukturen darstellen Abstraktion: Vernachlässigung der Details individueller Datenwerte Datenbanksysteme Prof. Dr. Stephan Kleuker 31 Datenmodellierung • Objekte der realen Welt, die für die Aufgabenstellung relevant sind, werden mit ihren Beziehungen untereinander in abstrakter Weise beschrieben, d.h. modelliert • Zentrale Fragen: Welche Objekte / Entitäten spielen eine Rolle? Welche Eigenschaften / Attribute haben diese Entitäten? Wie stehen die Entitäten miteinander in Beziehung (Relation)? Welche Eigenschaften haben diese Beziehungen? • Es stellen sich die Probleme der Anforderungsanalyse beim Versuch, Kundeninteressen in Datenbankanforderungen umzuformen, wie sie z. B. in der Veranstaltung Softwaretechnik diskutiert werden Datenbanksysteme Prof. Dr. Stephan Kleuker 32 Grundbegriffe der Entity-Relationship-Modelle Entität entity (oft auch „Objekt“) individuelles, identifizierbares Exemplar beschrieben durch Eigenschaften Entitätsmenge entity set (oft auch „Objekttyp“, „Entitätstyp“, vereinfacht ungenau auch „Entität“) Zusammenfassung von Entitäten mit gleichartigen Eigenschaften Name (Substantiv) als Oberbegriff für alle Entitäten der Menge Datenbanksysteme Prof. Dr. Stephan Kleuker 33 Grundbegriffe der Entity-Relationship-Modelle Attribut attribut, property Eigenschaft von allen Entitäten einer Entitätsmenge Name entsprechend fachlicher Bedeutung vorgegebener Wertebereich (auch „Domäne“ domain) beschreibende / identifizierende Attribute Schlüssel key (vorläufige Definition) identifizierende Attributkombination Datenbanksysteme Prof. Dr. Stephan Kleuker 34 Grundbegriffe der Entity-Relationship-Modelle Assoziation relationship Zusammenfassung von gleichartigen Beziehungen zwischen Entitäten Name (Verbform) als Oberbegriff für die gleichartigen Relationen zwischen den Entitäten zweier Entitätsmengen kann ebenfalls Attribute haben Datenbanksysteme Prof. Dr. Stephan Kleuker 35 Graphische Darstellung Kunde bucht Kundennr. Anrede Titel ... Seminarveranstaltung Veranst.-Nr. angemeldet am bestätigt am ... vom bis ... identifizierendes Attribut einer Entität ist unterstrichen (Hinweis: Es ist möglich, dass mehrere Attribute zur Identifizierung benötigt werden) Datenbanksysteme Prof. Dr. Stephan Kleuker 36 Kardinalitäten von Assoziationen (1/10) 1:1-Assoziation Ehefrau 1 ist verheiratet mit 1 Ehemann jede Ehefrau hat genau einen Ehemann jeder Ehemann hat genau eine Ehefrau Hinweis: Die Richtigkeit eines Entity-RelationShip-Diagramms hängt auch von der individuellen Aufgabenstellung ab Datenbanksysteme Prof. Dr. Stephan Kleuker 37 Kardinalitäten von Assoziationen (2/10) 1:N-Assoziation Mutter 1 hat N Kind jede Mutter kann mehrere Kinder haben jede Mutter hat mindestens ein Kind jedes Kind hat genau eine Mutter Datenbanksysteme Prof. Dr. Stephan Kleuker 38 Kardinalitäten von Assoziationen (3/10) M:N-Assoziation Student M hört N Vorlesung jeder Student kann mehrere Vorlesungen hören jeder Student hört mindestens eine Vorlesung jede Vorlesung kann von mehreren Studenten gehört werden jede Vorlesung hat mindestens einen Studenten als Hörer Datenbanksysteme Prof. Dr. Stephan Kleuker 39 Kardinalitäten von Assoziationen (4/10) 1:C-Assoziation Frau 1 ist verheiratet mit C Ehemann jede Frau hat entweder genau einen Ehemann oder keinen Ehemann (konditionelle Beziehung conditional relation) jeder Ehemann hat genau eine Ehefrau Datenbanksysteme Prof. Dr. Stephan Kleuker 40 Kardinalitäten von Assoziationen (5/10) 1:NC-Assoziation Frau 1 hat NC Kind jede Frau kann kein Kind, ein Kind oder mehrere Kinder haben jedes Kind hat genau eine Mutter (genauer Frau) Datenbanksysteme Prof. Dr. Stephan Kleuker 41 Kardinalitäten von Assoziationen (6/10) M:NC-Assoziation Dozent M führt durch NC Seminarveranstaltung jeder Dozent kann keine Seminarveranstaltung, eine Seminarveranstaltung oder mehrere Seminarveranstaltungen durchführen jede Seminarveranstaltung hat einen Dozenten oder mehrere Dozenten Datenbanksysteme Prof. Dr. Stephan Kleuker 42 Kardinalitäten von Assoziationen (7/10) MC:NC-Assoziation Artikel MC lagert in NC Lager jeder Artikel kann in keinem Lager lagern (ausverkauft) in einem Lager lagern in mehreren Lagern lagern jedes Lager kann keine Artikel lagern (wird saniert) einen Artikel lagern mehrere Artikel lagern Datenbanksysteme Prof. Dr. Stephan Kleuker 43 Kardinalitäten von Assoziationen (8/10) C:N-Assoziation Mentor C unterstützt N Künstler jeder Mentor unterstützt mindestens einen Künstler (sonst kein Mentor) eventuell mehrere Künstler jedes Künstler hat entweder keinen Mentor oder einen Mentor (sonst gibt es Krach) Datenbanksysteme Prof. Dr. Stephan Kleuker 44 Kardinalitäten von Assoziationen (9/10) C:NC-Assoziation Fluss NC mündet in C See jeder Fluss mündet entweder genau in einem oder in keinem See In jeden See mündet kein ein oder mehrere Flüsse Datenbanksysteme Prof. Dr. Stephan Kleuker 45 Kardinalitäten von Assoziationen (10/10) C:C-Assoziation Frau C verheiratet mit C Mann jede Frau ist verheiratet mit entweder genau einem oder keinem Mann jeder Mann ist verheiratet mit entweder genau einer oder keiner Frau Datenbanksysteme Prof. Dr. Stephan Kleuker 46 Muss- und Kann-Assoziationen Übersicht B A muss kann Datenbanksysteme 1 M C MC muss 1 N 1:1 1:N M:1 M:N C:1 C:N MC:1 MC:N Prof. Dr. Stephan Kleuker kann C NC 1:C 1:NC M:C M:NC C:C C:NC MC:C MC:NC 47 Assoziationen mit Attributen • Attribute, die keiner Entität zugeordnet werden können, sind bei Assoziationen gut aufgehoben BonID ProdID Datum Kasse Bon MC enthält Name Preis N Produkt Menge • Die Menge kann nicht beim Bon stehen, da sie für jedes Produkt verschieden sein kann • Die Menge kann nicht beim Produkt stehen, da jeder Bon eine andere Menge enthalten kann Datenbanksysteme Prof. Dr. Stephan Kleuker 48 Lesebeispiel Verkauf Straße Firma PLZ Ort Bezeichnung Adresse Status Preis PNR KNR Kunde Produkt M 1 MC erteilt NC bestellt lagern GPreis NC NC Menge ANR Auftrag Lager ADatum LDatum Datenbanksysteme Menge Ort Prof. Dr. Stephan Kleuker Straße 49 Textanalyse zur Modellfindung • Nomen können Entitäten oder Attribute sein • Adjektive deuten auf Attribute hin • Verben stellen häufig Entitäten (aber auch Attribute und Relationen) in Beziehung • Hinweis: Qualität des Ausgangstextes zur Analyse ist ein eigenes Thema • typische Problemfälle: – Synonyme: verschiedene Worte für den selben Begriff (Buchtitel, Exemplar) – Homonyme: gleiches Wort mit verschiedenen Bedeutungen (Bank, unsaubere Definitionen z. B. Entität) Datenbanksysteme Prof. Dr. Stephan Kleuker 50 Zyklen in ER-Diagrammen Kunde 1 erteilt N Auftrag NC MC enthält bestellt M NC Artikel Kunde Zyklen zur Darstellung unterschiedlicher Zusammenhänge sind dagegen sinnvoll Zyklen in ER-Diagrammen sind zu untersuchen, es darf generell keine redundante (auf anderem Weg berechenbare Information) modelliert werden. 1 erteilt N MC NC enthält bevorzugt M NC Datenbanksysteme Auftrag Prof. Dr. Stephan Kleuker Artikel 51 Verschiedene Notationen aus: H. Balzert, Lehrbuch Grundlagen der Informatik, Spektrum Akademischer Verlag, 1999 Datenbanksysteme Prof. Dr. Stephan Kleuker 52 Alternative Kardinalitätendarstellung A 1 NC (0,n) A (1,1) M N (1,n) A Datenbanksysteme B B (1,m) M C (0,1) (1,m) Prof. Dr. Stephan Kleuker B 53 UML-Notation Aus B. Oestereich, Objektorientierte Softwareentwicklung Hinweis: Oft werden nur Teile der Annotationen gezeigt Datenbanksysteme Prof. Dr. Stephan Kleuker 54 Lesebeispiel (CD-Sammler) Max-Notation: • 1,C wird 1 • N,NC wird N Datenbanksysteme Prof. Dr. Stephan Kleuker 55
