Datenbankentwurf 4.1 Konzeptueller Entwurf
Werbung
4.1 Konzeptueller Entwurf Kapitel 4 Datenbankentwurf – Kapitel 4 – 4.1 Konzeptueller Entwurf © 2002 Prof. Dr. Rainer Manthey Informationssysteme Konzeptueller Entwurf: Übersicht 1 Kapitel 4 • erste Phase des "eigentlichen" Entwurfsprozesses: Umsetzen der Strukturanforderungen und der Gesetzmäßigkeiten des Anwendungsbereichs in eine formale Darstellung konzeptuelles Schema • Statt "konzeptuell" wird oft auch das Adjektiv "konzeptionell" verwendet. Einmal stehen die 'Konzepte' der Anwendung, einmal die 'Konzeption' der Datenbank im Vordergrund - gemeint ist letztlich dasselbe. Im englischen Sprachraum: "conceptual modeling" (daher in dieser Vorlesung "konzeptuell"). • Charakteristisch für die konzeptuelle Modellierung (KM) ist der enge Bezug der Modellierungskonzepte zur realen Welt statt zum Rechner. • Bei der KM spielen die später zu entwerfenden Datenstrukturen noch keine Rolle! Im Vordergrund steht stets noch der Dialog mit dem Fachanwender. • In der kommerziellen Welt werden derzeit zwei Datenmodelle überwiegend für den DB-Entwurf verwendet, die auch in dieser Vorlesung genutzt werden: • konzeptueller Entwurf: Entity-Relationship(ER)-Modell • logischer Entwurf: Relationenmodell © 2002 Prof. Dr. Rainer Manthey Informationssysteme 2 Das Entity-Relationship-Modell Kapitel 4 • "Entity-Relationship"-Datenmodell (ER-Modell): • vorgeschlagen in einer Arbeit aus dem Jahre 1976 von Peter Chen • graphische Notation für Anwendungsmodellierung • eigenständiges semantisches Datenmodell (an der Bedeutung der Konzepte in der realen Welt orientiert) • Vorläufer der heutigen objektorientierten Datenmodelle • äusserst erfolgreich als Mittel zum "Vorentwurf" relationaler DB • seit vielen Jahren: sogar eigene Konferenzreihe (ER Conferences) • wenige sehr einfache und grundlegende Konzepte zur Modellierung: • "entities" (Gegenstände) charakterisiert durch Attribute (Eigenschaften) • 2- oder mehrstellige "relationships" (Beziehungen) zwischen Entities, ggf. auch charakterisiert durch Attribute • oft nicht explizit erwähnt, aber wichtig und elementar: "values" (Werte); druckbare Zeichen als Werte von Attributen von untergeordnetem Rang (charakterisieren Gegenstände) • "roles" (Rollen): Bezeichner für die spezielle Bedeutung, die einem Gegenstand im Rahmen einer Beziehung zukommt © 2002 Prof. Dr. Rainer Manthey Informationssysteme Entity ??? 3 Kapitel 4 Was ist das: ein Entity ? • engl. "entity" (Plural: "entities"): being, person, creature, individual, organism, object, article, thing, substance, quantity (Synonyme nach Oxford Thesaurus) • dt. "Entität": "[lat.] die bestimmte Seinsverfassung eines Seienden, auch dieses selbst ( → Ens)" (dtv-Lexikon, Bd. 5) • dt. "Ens": "[lat.] scholastische Philosophie: das Seiende oder etwas, das dem Sein zukommt, urspr. das wirklich Seiende, i.w.S. alles, das ist oder sein kann, insgesamt das real Seiende (ens reale), i. Ggs. zum Gedankending (ens rationis). . ." (dtv-Lexikon Bd. 5) im Buch von Kemper: "Gegenstände (bzw. Entities) sind wohlunterscheidbare physisch oder gedanklich existierende Konzepte der zu modellierenden Welt." © 2002 Prof. Dr. Rainer Manthey Informationssysteme 4 ein Entity Kapitel 4 Jedes Entity ist durch die Angabe der Werte aller seiner Attribute vollständig charakterisiert. ein Entity PersNr seine Attribute Vorname Name Alter Fach "Rainer" 765 "Manthey" BesGrp "Informatik" "C3" 49 deren Werte © 2002 Prof. Dr. Rainer Manthey Informationssysteme 5 zwei gleichartige Entities Kapitel 4 PersNr 765 "Rainer" Vorname Name Alter Fach "Manthey" 49 BesGrp "Informatik" "C3" ein anderes Entity gleiche Attribute PersNr ? Vorname Name Alter Fach "Joachim M." "Buhmann" 43 BesGrp "Informatik" "C3" z.T. anderes Werte © 2002 Prof. Dr. Rainer Manthey Informationssysteme 6 Entity-Typen Kapitel 4 • Gleichartige Entities können zu Entity-Typen zusammengefasst werden. • "Gleichartigkeit" setzt zumindest identische Attributstruktur voraus. (Attributnamen und zugehörige Wertebereiche sind gleich) • Entity-Typen werden in der graphischen Notation des ER-Modells durch Rechtecke dargestellt. Attribute markieren die Verbindung zwischen den Entity-Typen und Wertebereichen (meist als Oval dargestellt): professor PersNr Int Name des Typs Vorname Name Alter Fach String Int String © 2002 Prof. Dr. Rainer Manthey BesGrp String String Informationssysteme 7 Entity-Typen: alternative Darstellungsweisen Kapitel 4 • Wertebereichsnamen werden oft weggelassen (sofern sie offensichtlich oder irrelevant sind) und stattdessen nur die Attribute in die Ovale geschrieben: professor PersNr Vorname Name Alter Fach BesGrp • In grösseren Diagrammen fällt die Attributstruktur meistens ganz weg, um Platz zu sparen (oder wird nur abkürzend bzw. separat notiert): professor PersNr, Vorname, Name, . . . © 2002 Prof. Dr. Rainer Manthey Informationssysteme 8 Instanzen und Population eines Entity-Typs Kapitel 4 • Jedes Entity "gehört zu" mindestens einem Entity-Typ: Es wird dann Instanz dieses Typs genannt. professor eine Instanz von • Die Menge aller aktuellen Instanzen eines Entity-Typs heisst dessen Population. professor eine Population von © 2002 Prof. Dr. Rainer Manthey Informationssysteme Mehrfachklassifizierung 9 Kapitel 4 • Ein und dasselbe Entity kann Instanz verschiedener Entity-Typen sein. professor Instanz von Instanz von werder bremenfan • Dabei kann die Attributstruktur der beiden Typen durchaus verschieden sein. © 2002 Prof. Dr. Rainer Manthey Informationssysteme 10 Klassifizierung bei gleicher Attributstruktur Kapitel 4 • Entities mit gleicher Attributstruktur müssen keineswegs Instanzen desselben Typs sein ! Instanz von esel name, vorname, alter werder bremenfan Instanz von name, vorname, alter • Fast immer muss es noch zusätzliche Klassifizierungsmerkmale geben, die man an der Attributstruktur nicht ablesen kann. © 2002 Prof. Dr. Rainer Manthey Informationssysteme 11 Schlüsselattribute • Kapitel 4 Wie bereits im relationalen Modell (Access, SQL) gibt es in der Regel stets ein oder mehrere Attribute pro Entity-Typ, deren Werte ausreichen, um die einzelnen Instanzen eindeutig zu identifizieren: Schlüsselattribute professor PersNr Vorname Name Alter Fach BesGrp • (Primär-)Schlüsselattribute werden meist durch unterstreichen im ER-Diagramm gekennzeichnet. • Schlüssel sollten stets "minimal" sein (kein Attribut kann weggelassen werden). • Eine Unterscheidung von Primärschlüsseln und anderen Schlüsselkandidaten ist im ER-Modell nicht vorgesehen, ist aber sinnvoll. © 2002 Prof. Dr. Rainer Manthey Informationssysteme 12 SLF-Datenbank: Entity-Typen und Attribute Kapitel 4 Land Stadt Attribut Name Kfz Einwohner Fläche Entity-Typ Name Kurzform Einwohner Fläche Fluss Schlüsselattribut Name LängeInD Gesamtlänge Bezirk Nachbarstaat Name Einwohner Fläche Staat Kennzeichen Vorwahl GrenzlängeMitD © 2002 Prof. Dr. Rainer Manthey Informationssysteme 13 Relationships Kapitel 4 • zweites Grundkonzept des ER-Modells: elementare Beziehungen zwischen zwei oder mehr Entities (ggf. mit eigenen Attributwerten) Relationship PersNr 765 Berufungsjahr Bezeichnung 1992 Universität Bonn • Jede Relationship ist durch die Schlüsselwerte der beteiligten Entities und die Werte aller Relationship-Attribute eindeutig charakterisiert. • Es gibt allerdings keine Schlüsselattribute für Relationships geben, da stets die Schlüssel der beteiligten Entity-Typen zum eindeutigen Identifizieren dienen. © 2002 Prof. Dr. Rainer Manthey Informationssysteme 14 Mehrfache Beziehungen Kapitel 4 Entitites können an mehreren Relationships (auch gleichartigen) beteiligt sein. Berufungsjahr 1992 Berufungsjahr 1999 © 2002 Prof. Dr. Rainer Manthey Informationssysteme 15 Relationship-Typen Kapitel 4 • Gleichartige Relationships können zu Relationship-Typen zusammengefasst werden. • "Gleichartigkeit" setzt zumindest identische Attributstruktur und identische Typen (und Anzahl) der beteiligten Entities voraus. • Relationship-Typen werden in der graphischen Notation des ER-Modells durch Rauten dargestellt. Attribute werden wie bei Entity-Typen notiert. berufen_an universität professor Bezeichnung, . . . PersNr, . . . Berufungsjahr Int © 2002 Prof. Dr. Rainer Manthey Informationssysteme 16 Instanzbeziehungen bei Relationship-Typen Kapitel 4 berufen_an universität professor Bezeichnung, . . . PersNr, . . . Berufungsjahr Int Auch bei Relationship-Typen gibt es den Begriff der 'Instanz': einzelne Relationships zwischen einzelnen Entities lassen sich analog als Instanzen der R-Typen auffassen. berufen_an Berufungsjahr PersNr 765 Bezeichnung ... 1992 © 2002 Prof. Dr. Rainer Manthey ... Universität Bonn Informationssysteme 17 Mehrfache Beteiligung an Relationship-Typen und Rollen Kapitel 4 • Ein und derselbe Entity-Typ kann an einem Relationship-Typ auch mehrfach beteiligt sein, z.B.: mutter abkömmling_von person tochter • Zur (syntaktischen) Unterscheidung zwischen den verschiedenen "Formen der Beteiligung" sollte man in solchen Situationen gesonderte Bezeichner, genannt Rollen, verwenden, die als Markierungen an den jeweiligen Kanten zwischen Entity- und Relationship-Symbol notiert werden. © 2002 Prof. Dr. Rainer Manthey Informationssysteme 18 Rollen bei Relationships ohne Mehrfachbezug Kapitel 4 • Rollen dürfen auch dann eingesetzt werden, wenn keine Mehrdeutigkeit auf Grund von mehrfacher Beteiligung desselben Entity-Typs vorliegt. Sie dienen dann als semantisch begründete zusätzliche Informationen im Schema. geprüft_von student professor prüfer prüfling MatrNr, . . . PersNr, . . . • Werden bei einem Relationship-Typ nur einzelne beteiligte Entity-Typen mit expliziten Rollen versehen, dann kann man für die übrigen E-Typen deren Namen stets als implizite Rolle annehmen. • Würde also im obigen Beispiel nur die Rolle 'prüfer' explizit genannt, dann könnte man 'student' als implizite Rolle an der anderen Kante annehmen. © 2002 Prof. Dr. Rainer Manthey Informationssysteme Namenskonventionen 19 Kapitel 4 • Die Wahl der Bezeichner für Typen und Attribute muss stets so gewählt sein, dass innerhalb desselben Schemas immer klar ist, von welchem Konzept man gerade spricht. • Das bedeutet: • Jeder Name eines Entity-Typs darf im Schema nur einmal vorkommen. • Jeder Name eines Relationship-Typs darf im Schema nur einmal vorkommen. • Jedes Attribut und jede Rolle muss innerhalb des Schemas des jeweiligen Entity- oder Relationship-Typs eindeutig gewählt sein. • Attribute und Rollen dürfen aber in anderen Typen wieder verwendet werden. • Globale Bezeichungskonflikte bei Attributen oder Rollen lassen sich (wie in SQL oder in der RA) durch Verwendung des jeweiligen Typs als Präfix lösen, z.B. professor.Name versus universität.Name. © 2002 Prof. Dr. Rainer Manthey Informationssysteme 20 SLF-Datenbank: Relationship-Typen (1) Kapitel 4 nachbarland_von Hauptstadt hauptstadt_von_land Land 1 Land Stadt Land 2 stadt_in_land stadt_an_fluss bezirk_ in_land fluss_ durch_ land Fluss Bezirk Relationship-Typ Quellfluss quellfluss_von © 2002 Prof. Dr. Rainer Manthey Rolle Informationssysteme 21 SLF-Datenbank: Relationship-Typen (2) Kapitel 4 fluss_entspringt_ in_land Ursprungsland Land 1 Land Land 2 grenzfluss_national Fluss grenzfluss_international Nebenfluss nebenfluss_von Seite Nachbarstaat Attribut © 2002 Prof. Dr. Rainer Manthey Informationssysteme 22 Germ-lish in der Informatik ? • Kapitel 4 Wir haben auf den letzten Folien stets die englischen Begriffe 'Entity' und 'Relationship' in deutschen Sätzen quasi als "eingedeutschte" Substantive verwendet. Ist das nicht stilistisch fragwürdig ?? (Stichwort: "Germ-lish") • (meine) Antwort: Im Prinzip ja, aber . . . • . . . es gibt - gerade in der Informatik - manchmal Situationen, in denen ein "terminus technicus" (Latinismus!) aus dem Englischen sich nur mit deutlichen Schwierigkeiten eindeutschen lässt. In solchen Fällen (aber stets nach bewusster Entscheidung!) verwende ich den fremdsprachigen Begriff in einem deutschen Satz. © 2002 Prof. Dr. Rainer Manthey Informationssysteme Sprache und Typwahl 23 Kapitel 4 • Wo wir gerade beim Thema "Sprache" sind: . . . • . . . es gibt eine einfache Heuristik für die Wahl von Bezeichnern bei der ER-Modellierung ! • Man sollte stets versuchen, Typnamen so zu wählen, dass • Entity-Typen durch Substantive benannt werden. (professor, universität, stadt, land, fluss, . . .) • Relationship-Typen entweder • durch Verben benannt werden. (berufen_an, liegt_in, . . .) • oder durch Substantive mit Präpositionen benannt werden. (hauptstadt_von, nebenfluss_von, . . .) • Attribute und Rollen sollten wiederum in der Regel Substantive sein. (Name, Personalnummer, Prüfer, . . . ) • Dies sind aber keine zwingenden Regeln, sondern nur "Ratschläge", von denen man gelegentlich abweichen wird (aber wiederum nur "mit gutem Grund"!). © 2002 Prof. Dr. Rainer Manthey Informationssysteme 24 ER-Modellierung im Bundesliga-Beispiel Kapitel 4 • Die "richtige" Designentscheidung beim konzeptuellen Modellieren ist oft bei Weitem nicht so offensichtlich wie im Stadt-Land-Fluss-Beispiel (und wer weiss, ob diese Entscheidung "richtig" war! Was ist überhaupt "richtiges" oder gar "gutes" Design?) • Im Bundesliga-Beispiel scheint die Modellierung nur auf den ersten Blick ganz offensichtlich zu sein: Heimmannschaft Spiel Verein Name Ort Trainer Auswärtsmannschaft beteiligt_an Datum Spieltag ToreH ToreA Sollten das Attribute des Spiels oder der Relationship sein? © 2002 Prof. Dr. Rainer Manthey Informationssysteme 25 ER-Modellierung im Bundesliga-Beispiel (2) Kapitel 4 Wozu braucht man den dann überhaupt den Entity-Typ 'Spiel' ? Kann man stattdessen denn nicht mit der Relationship auskommen ? beteiligt_an Heimmannschaft Verein Name Ort Trainer Auswärtsmannschaft spielt_gegen Spiel Datum Spieltag ToreH ToreA Was "ist" denn nun ein Spiel ? Ein Entity oder eine Relationship ? © 2002 Prof. Dr. Rainer Manthey Informationssysteme 26 ER-Modellierung im Bundesliga-Beispiel (3) Kapitel 4 Die "richtige" Designentscheidung kann hier - ganz pragmatisch - z.B. dadurch begründet sein, dass man das Schema noch erweitern will: Um die Beteiligung von Spielern an Spielen zu modellieren, muss man 'Spiel' schon den Status eines E-Typs geben, weil es Beziehungen zwischen E- und R-Typen nicht gibt! Heimmannschaft Spiel Verein beteiligt_an Auswärtsmannschaft eingesetzt_in AnzahlTore Spieler © 2002 Prof. Dr. Rainer Manthey Informationssysteme 27 ER-Modellierung im Bundesliga-Beispiel (4) Kapitel 4 Heimmannschaft Spiel Verein Name Ort Trainer Auswärtsmannschaft beteiligt_an Datum Spieltag ToreH ToreA • weitere "schwierige" Designentscheidung: Was wird Attribut, was wird Beziehung (bzw. Entity-Typ) ? • im Beispiel: Soll man Attribute wie 'Trainer', 'Ort' oder 'Spieltag' "zu EntityTypen erheben" ? • Heuristik hier: Will man diese Konzepte durch "eigene" Attribute näher charakterisieren oder sie in "eigenen" Relationships verwenden, dann sollten sie zu E-Typen werden. • Attribute sind untergeordnete Konzepte, die nur zur Charakterisierung der wesentlichen Konzepte der Anwendung (Entities) dienen ! © 2002 Prof. Dr. Rainer Manthey Informationssysteme 28
