Script Datenmanagement - Teil 1: Modellieren mit dem ERM

Transkript

1 Wintersemester 2009/2010 Script Datenmanagement - Teil 1: Modellieren mit dem ERM Jörg Becker Phillip Bergener Patrick Delfmann Milan Karow Lukasz Lis Ralf Plattfaut

2 Inhaltsverzeichnis Das Script für die Lehrveranstaltung Datenmanagement wurde im Wintersemester 2007/2008 komplett überarbeitet und neu strukturiert. Wir bitten darum, eventuelle Fehler im Script an Ralf Plattfaut zu melden. Inhaltsverzeichnis 1 Konzeptionelle Datenmodelle mit der Entity-Relationship-Methode Zweck Konzeptioneller Datenmodelle Grundlegende Modellelemente im ERM Verwendung der Kardinalitäten in der Min-Max-Notation Syntax Kombinationsmöglichkeiten und deren Interpretation Hierarchien und Strukturen im ERM Hierarchien und Bäume Strukturen und Netze Attribute im ERM Syntax Attribute als Schlüssel Mehrwertige Relationshiptypen Uminterpretation von Relationshiptypen Syntax Zulässigkeit der Uminterpretation von Relationshiptypen Generalisierung und Spezialisierung im ERM Spezielle Konventionen der ER-Modellierung Benennung von Relationshiptypen Das Konzept Zeit im Entity-Relationship-Modell Konventionen zu Kardinalitäten Konventionen zur Generalisierung/Spezialisierung Kommentare und zusätzliche Annahmen

3 1 Konzeptionelle Datenmodelle mit der Entity-Relationship-Methode 1.1 Zweck Konzeptioneller Datenmodelle In einem konzeptionellen Datenmodell sollen die im Betrachtungsgebiet relevanten Daten unabhängig von einem konkreten Datenbankmodell und unabhängig von Funktionen, in denen die Daten verarbeitet werden, dargestellt werden. Ein logisches Datenmodell kann prinzipiell in ein beliebiges Datenbankmodell überführt werden. Das Entity-Relationship-Modell (ERM) ist ein Hilfsmittel zur Darstellung eines konzeptionellen Datenmodells und unabhängig von einem bestimmten Datenbankmodell. Das Datenmodell hält auf konzeptioneller Ebene die im Betrachtungsbereich relevanten Objekte (Entitäten) und Beziehungen (Relationships) zwischen diesen formal fest. Objekte und Beziehungen können durch Eigenschaften (Attribute) näher beschrieben werden. 1.2 Grundlegende Modellelemente im ERM Entity Entitytyp Relation Relationshiptyp Kante Attribut Kardinalität die informationelle Repräsentation eines realen oder künstlichen/abstrakten Objekts (auch: Instanz eines Entitytyps), hat im ERM keine direkte Entsprechung Zusammenfassung bzw. Typisierung gleichartiger Entities zu einer Menge (bzw. einer Klasse), im ERM dargestellt durch ein Rechteck Beziehung zwischen zwei Entities Typisiert die Beziehung zwischen zwei Entitytypen, wobei auch ein Entitytyp mit sich selbst in Beziehung gesetzt werden kann (z.b. Hierarchie), im ERM dargestellt durch eine Raute Verbinden Entity- und Relationshiptypen miteinander, Kanten dürfen nicht zwischen gleichartigen Knoten gezogen werden, im ERM dargestellt durch horizontale und vertikale Linien Weist einem Entity- oder Relationshiptypen typisierte Eigenschaften zu, Attribute können als ellipsenförmige Knoten an Entity- und Relationshiptypen annotiert werden Gibt an, wie oft ein Entity eines Entitytypen A eine Beziehung mit einem Entity eines Entitytypen B eingehen kann, wenn A und B über einen Relationshiptypen in Verbindung gesetzt werden 1.3 Verwendung der Kardinalitäten in der Min-Max-Notation Bei der Min-Max-Notation wird angegeben, wie oft eine Entität mindestens eine Beziehung eingehen muss und wie oft sie maximal eine Beziehung eingehen darf. Um eine Beziehung zwischen zwei Entitytypen zu charakterisieren, sind also zwei (min, max)-paare notwendig (eins für jeden Entitytyp). Hat die Minimalkardinalität den Wert Eins (oder größer), dann spricht man auch von einer existenziellen Abhängigkeit. 3

4 1.3.1 Syntax A (min,max) R (min,max) B Mit min wird angegeben, wie oft ein Entity aus A mindestens eine Beziehung mit einem Entity aus B eingeht bzw. eingehen muss. Übliche Werte für die Minimalkardinalität (also die untere Schranke) sind 0 und 1. Theoretisch - wenn auch selten eingesetzt - sind auch andere nichtnegative Ganzzahlen zulässig. Bei einer Minimalkardinalität von größer als null, ist der Entitytyp existenzabhängig vom verbundenen Entitytyp. Mit max wird angegeben, wie oft ein Entity aus A höchstens eine Beziehung mit B eingehen darf. Die Maximalkardinalität (also die obere Schranke) muss immer größer als 0 sein. Übliche Werte sind 1 oder n (bzw. m), wobei hier die Variable n lediglich angibt, dass die obere Grenze offen ist, d.h. ein A kann Beziehungen mit beliebig vielen Instanzen von B eingehen. Auch für die Maximalkardinalität können bei Bedarf andere natürliche Zahlen als 1 eingesetzt werden Kombinationsmöglichkeiten und deren Interpretation Kombinationen ohne Existenzabhängigkeiten: Kombinationen von Kardinalitäten implizieren keine Existenzabhängigkeit, wenn die Minimalkardinalität für alle Entitytypen, die an einer Beziehung teilnehmen, Null ist. Kombination 1.1: (0,m) (0,m) Vorlesung Teilnahme Student An einer Vorlesung nehmen null bis beliebig viele Studenten teil, Studenten können an null bis beliebig vielen Vorlesungen Teilnehmen. Kombination 1.2: (0,1) Lehrveranstaltung (0,1) Veranstltgs.- ort Hörsaal Einer Lehrveranstaltung kann maximal ein Hörsaal zugeordnet werden (muss aber nicht: beispielsweise bei reinen Online-Veranstaltungen). In einem Hörsaal können null bis beliebig viele Vorlesungen stattfinden. Kombination 1.3: (0,1) (0,1) Mitarbeiter (0,1) (0,1) Dienstwagen Personenkraftwagen 4

5 Mitarbeitern kann jeweils (maximal) ein PKW als Dienstfahrzeug zugeordnet werden. Ein PKW kann der Dienstwagen von (maximal) einem Mitarbeiter sein. Kombinationen mit einseitiger Existenzabhängigkeit: Kombinationen von Kardinalitäten implizieren eine einseitige Existenzabhängigkeit, wenn die Minimalkardinalität für genau einen an der Beziehung teilnehmenden Entitytypen Eins ist. Entities diesen Typs sind abhängig von den Entities, mit denen sie in Beziehung stehen. Kombination 2.1: (1,1) (1,1) Warengruppe Atikel-WG Artikel Ein Artikel ist genau einer Warengruppe zugeordnet (d.h. es gibt auch keinen Artikel ohne Warengruppe). Warengruppen können null bis beliebig viele Artikel umfassen. Ein Artikel ist damit existenzabhängig von seiner Warengruppe, die Warengruppe ist jedoch unabhängig von ihren Artikeln. Kombination 2.2: (1,n) (1,n) Professor Dozent Vorlesung Ein Professor kann für null bis beliebig viele Vorlesungen als Dozent auftreten. Eine Vorlesung wird von mindestens einem (bis beliebig vielen) Professoren betreut. Vorlesungen sind damit existenzabhängig von Professoren. Kombination 2.3: (0,1) (1,1) Lehrveranstaltung (0,1) (1,1) LV-Forum Onlineforum Einer Lehrveranstaltung kann ein Online-Forum zugeordnet sein (muss aber nicht), ein Onlineforum ist immer genau einer Veranstaltung zugeordnet. Damit ist das Forum existenzabhängig von der Veranstaltung. Kombination 2.4: (0,1) (1,n) Die Kombination (0,1) (1,n) ist theoretisch denkbar, allerdings ist diese ein Spezialfall mit geringer praktischer Relevanz. 5

6 Kombinationen mit wechselseitiger Abhängigkeit Wechselseitige Anhängigkeiten entstehen, wenn die Minimalkardinalität einer Beziehung auf beiden Seiten größer als Null ist. Kombination 3.1: (1,n) (1,1) Rechnung (1,n) Positionszuordnung (1,1) Rechnungsposition Zu einer Rechnung existiert immer mindestens eine Rechnungsposition, eine Rechnungsposition ist genau einer Rechnung zugeordnet. Rechnung und Rechnungsposition sind wechselseitig abhängig voneinander. Kombination 3.2: (1,n) (1,n) Die Kombination (1,n) (1,n) ist theoretisch möglich, hat jedoch als Spezialfall geringe praktische Relevanz. Kombination 3.3: (1,1) (1,1) Die Kombination (1,1) (1,1) zeigt an, dass eine Beziehung immer zwischen exakt zwei Entities der verbundenen Typen besteht. Eine solche Kombination impliziert in der Regel, dass die beiden beteiligten Entitytypen zu einem Entitytyp zusammengefasst werden sollten. In Ausnahmefällen kann es jedoch fachliche Gründe geben, sie dennoch getrennt zu modellieren. 1.4 Hierarchien und Strukturen im ERM Relationshiptypen müssen nicht zwangsläufig unterschiedliche Entitytypen verbinden, eine Beziehung kann auch zwischen Entities desselben Typs bestehen. Die Minimalkardinalität muss bei solchen Beziehungen in jeder Leserichtung 0 sein, da sonst eine Unendlichschleife typisiert würde. Je nach Maximalkardinalität unterscheidet man zwei Anwendungsfälle: Hierarchien (bzw. Bäume) und Strukturen (bzw. Netze) Hierarchien und Bäume Hierarchien setzen Entities in eine Über-/Unterordnungsbeziehung. Dabei entsteht eine Baumstruktur, d.h. einem darf maximal ein anderes (gleichen Typs) übergeordnet werden, einem können aber beliebig viele e (gleichen Typs) untergeordnet werden. Die Kardinalität ist also (0,1) : Hierarchie (0,1) typ Auf Entityebene lässt sich diese Beziehung wie folgt visualisieren: 6

7 Aus der Darstellung wird ersichtlich, dass die Hierarchiestruktur mehr als einen Wurzelknoten erlaubt. Es sind darüber hinaus auch e erlaubt, die weder ein über- noch ein untergeordnetes haben. Ein zwingend zusammenhängender Baum lässt sich mit Mitteln des ERM nicht darstellen. Beispiele für Hierarchien Hierarchie Antwort- Hierarchie (0,1) (0,1) Mitarbeiter Forumsbeitrag Beispiel 1: Vorgesetzte und untergeordnete Mitarbeiter Beispiel 2: Beiträge in einem Internetforum und deren Antworten Insbesondere in Beispiel 2 wird ersichtlich, dass es mehrere Wurzelknoten geben kann: in einem Forum kann entweder eine Antwort auf einen Beitrag, oder aber ein neuer Beitrag verfasst werden. Der neue Beitrag stellt dann einen neuen Wurzelknoten in der Hierarchie dar Strukturen und Netze Strukturen bzw. Netze im ERM setzen Entities mit beliebig vielen Entities des gleichen Typs in Verbindung. Potentiell darf jede Instanz eines Entitytyps mit jeder anderen Instanz verbunden sein. Anders als in Hierarchien muss es keine klare Richtung der Beziehung geben, bestimmte Anwendungsfälle können jedoch eine Leserichtung erfordern (siehe Beispiele). Ob eine Strukturbeziehung gerichtet oder ungerichtet ist, lässt sich aus dem ERM nicht direkt ablesen und ist nur aus dem fachlichen Kontext ersichtlich. Die Kardinalität einer Strukturbeziehung ist immer - (0,m): 7

8 Struktur typ (0,m) Auf Entityebene lässt sich eine Struktur bzw. ein Netz wie folgt visualisieren: Ähnlich den Hierarchien im ERM wird auch bei Strukturen ersichtlich, dass es auf Ebene der Entities unverbundene Teilnetze, sowie damit auch unverbundene Einzelelemente geben darf. Ein zwingend zusammenhängendes Netz lässt sich mit Mitteln des ERMs nicht darstellen. Beispiele für Strukturen Teilstruktur Bauteil (0,m) Beispiel 1: Bauteile und ihre Zusammensetzung 8

9 In Beispiel 1 werden Bauteile anderen Bauteilen als Bestandteile zugeordnet. Diese Beziehung ist gerichtet, da ein Bauteil entweder Bestandteil eines verbundenen Bauteils ist, oder aus den verbundenen Bauteilen zusammengesetzt ist. So ist beispielsweise ein Aluminiumrohr Bestandteil eines Fahrradrahmens, jedoch ist der Fahrradrahmen nicht Bestandteil des Rohrs, sondern diesem übergeordnet. Diese Überordnung ist keine (strenge) Hierarchie, da das Rohr potentiell auch in anderen Bauteilen verbaut werden kann (z.b. in der Lenkerkomponente, oder in der Sattelstütze) also nicht genau ein übergeordnetes besitzt. Freund Mitglied (0,m) Beispiel 2: Freundstrukur von Mitgliedern in einem sozialen Netzwerk Beispiel 2 zeigt ein soziales Netzwerk bei welchem Mitglieder mit anderen Mitgliedern über eine Freundschaftsbeziehung verbunden werden können. Die Beziehung ist im Gegensatz zu Beispiel 1 ungerichtet (bzw. bidirektional oder kommutativ), d.h. wenn Teilnehmer A mit B befreundet ist, so ist auch B mit A befreundet. Reale Beispiele für Implementationen solcher Netzwerke sind Internetplattformen wie bspw. StudiVZ, Facebook, XING, MySpace etc. 1.5 Attribute im ERM Attribute beschreiben Entitytypen näher, in dem deren jeweilige Eigenschaften festgelegt werden. Auch Relationshiptypen können durch die Annotierung von Attributen näher definiert werden Syntax Attribute werden im ERM durch eine Ellipse dargestellt, welche über eine Kante mit dem näher zu beschreibenden Knoten verbunden wird. Für eine kompaktere Darstellung der Attribute im ERM ist es auch erlaubt, die Attribute eines Typs in einer Ellipse zusammenzufassen. Die einzelnen Attribute werden dann durch Kommata getrennt: Entitytyp Entitytyp Attribut1 Attribut2 Attribut1, Attribut2, Attribut3 9

10 Durch die Attribute eines Knotens wird bestimmt, welche Informationen über eine Entität oder eine Beziehung im zu entwickelnden Datenbanksystem abgelegt werden sollen. Grundsätzlich ist die Wahl der Attribute für einen Entity- oder Relationshiptypen vom jeweiligen Anwendungskontext abhängig: Personenkraftwagen Personenkraftwagen Modell, Erstzulassung, Kilometerstand, Unfallstatus, Farbe, TÜV-Status, Verkaufspreis Beispiel 1: Attributierung eines PKW für eine Anwendung im Gebrauchtwagenhandel (Auszug) Modell, Risikoklasse, Stellplatz Schadenfreiheitsrabatt Beispiel 2: Attributierung eines PKW für eine Anwendung eines KFZ- Versicherungsanbieters (Auszug) Neben Entitytypen können auch Relationshiptypen mit Attributen versehen werden, wenn den Beziehungen spezifische Eigenschaften zugeordnet werden sollen. Sinnvoll ist eine solche Attributierung in der Regel nur dann, wenn eine N-zu-M-Beziehung besteht, da sich in diesem Fall die Beziehungsattribute nicht einem an der Beziehung beteiligten Entitytyp zuordnen lassen: Prüfung (0,m) Prüfungsteilnahme Student Note Beispiel: Attributierung einer Beziehung Attribute als Schlüssel Attribute werden nicht nur dazu eingesetzt, Entities oder Beziehungen näher zu beschreiben, sondern können darüber hinaus dazu dienen, solche e eindeutig zu identifizieren. Folgende Begrifflichkeiten werden unterschieden: Schlüsselkandidat: Ein Schlüsselkandidat ist eine Menge an Attributen, die die Tupel einer Relation eindeutig identifiziert. Diese Menge muss minimal sein, dass heißt alle Attribute in der Menge müssen für die Eindeutigkeit notwendig sein. Eine Relation kann mehrere Schlüsselkandidaten besitzen. 10

11 Primärschlüssel: Ein Primärschlüssel ist der Schlüsselkandidat, der zur eindeutigen Identifikation der Tupel einer Relation ausgewählt wurde. Im ERM werden Primärschlüsselattribute durch Unterstreichung gekennzeichnet: Entitytyp Entitytyp Schlüsselattribut1, Schlüsselattribut2, Attribut3, Attribut4 Schlüssel Attribut2 Fremdschlüssel: Der Fremdschlüssel ist eine Menge von Attributen einer Relation, welche auf einen Primärschlüssel einer anderen oder der gleichen Relation verweist. Ein Fremdschlüssel kann theoretisch auch auf einen anderen Schlüsselkandidaten als den Primärschlüssel verweisen. Fremdschlüssel entstehen bei der Überführung des ERM in ein Tabellenschema in Abhängigkeit der Beziehungen und ihrer Kardinalitäten (siehe Abschnitt 1.2: Überführung des ERM in ein Datenbankschema). Im ERM selbst werden Fremdschlüssel daher nicht dargestellt. 1.6 Mehrwertige Relationshiptypen In den bisherigen Beispielen wurden Relationshiptypen dazu eingesetzt entweder zwei Entitytypen, oder einen Entitytypen mit sich selbst in Beziehung zu setzen. Grundsätzlich ist es jedoch möglich, drei oder mehr Entitytypen über einen Relationshiptypen zu verbinden. Ein Beispiel: In einem Serviceunternehmen ist eine Kundenfahrt dadurch definiert, dass ein Mitarbeiter mit einem Fahrzeug des Fuhrparks für einen spezifischen Kundenauftrag fährt. Ein Kundenauftrag kann jedoch mehrere Fahrten erfordern. Jedes Fahrzeug des Fuhrparks kann von jedem Mitarbeiter verwendet werden - ein Mitarbeiter, der eine Fahrt zu erledigen hat, reserviert sich aus dem Fuhrpark ein beliebiges freies Fahrzeug. Für Versicherungs- und Abrechnungszwecke soll festgehalten werden, welcher Mitarbeiter welches Fahrzeug im Rahmen welches Kundenauftrags verwendet hat. Diese Anforderungen lassen sich mit einem trinären Relationshiptypen elegant abbilden: 11

12 Kraftfahrzeug Fahrzeugnr Kundenauftrag Fahrt Auftragsnr Mitarbeiter Personalnr Es sind darüber hinaus natürlich auch Relationshiptypen möglich, die mehr als drei Entitytypen verbinden. 1.7 Uminterpretation von Relationshiptypen Relationshiptypen beschreiben Beziehungen zwischen Instanzen zweier oder mehrerer Entities. Bestimmte fachliche Fälle können es erfordern, dass ein Relationshiptyp wiederum mit einem Entitytypen eine Beziehung eingehen muss. Da Relationshiptypen nicht direkt mit Relationshiptypen verbunden werden dürfen, muss der betreffende Relationshiptyp uminterpretiert werden Syntax Im ERM wird zur Uminterpretation eines Relationshiptypen ein Rechteck um das Rautensymbol gezogen, um die Entity-Rolle des Knotens zu kennzeichnen. Wichtig dabei ist, dass die jeweiligen Kanten je nach eingenommener Rolle entweder an die Seiten des Rechtecks, oder an die Eckpunkte der Raute gezogen werden: 12

13 E-Typ 1 E-Typen docken an R-Typ-Eckpunkt an Uminterpretierter R-Typ R-Typ (1,1) E-Typ 3 (0,m) E-Typ 2 R-Typ dockt an E-Typ-Seite an Beispiel Ein Handelsunternehmen bezieht Artikel von unterschiedlichen Lieferanten und nimmt Bestellungen von Kunden entgegen. Dabei kann ein Artikel im Sortiment von mehreren Lieferanten bezogen werden, Lieferanten liefern in der Regel mehrere verschiedene Artikel. Für Nachweiszwecke ist es erforderlich, dass für jeden vom Kunden bestellten Artikel nachvollzogen werden kann, von welchem Lieferanten der Artikel jeweils stammt. Folgende Lösungsvarianten stehen zur Disposition: Variante 1: Die Beziehung wird mit einem ternären R-Typ dargestellt. Problem: Es kann kein Artikel seinem Lieferanten zugeordnet werden (Liefernachweis), wenn dieser Artikel noch nicht von einem Kunden bestellt wurde. Lieferant Artikel Kunde Bestellung 13

14 Variante 2: Ein zusätzlicher R-Typ bildet den Liefernachweis ab. Problem: Diese Variante ermöglicht Inkonsistenzen zwischen den Beziehungstypen Bestellung und Liefernachweis: so könnte ein Bestellartikel einem Lieferanten zugeordnet werden, der diesen laut Liefernachweis gar nicht liefert. Lieferant Artikel Kunde Liefernachweis Bestellung Variante 3: Der R-Typ Liefernachweis wird uminterpretiert. Dadurch können nur Bestellungen erzeugt werden, die sich auf einen konkret von einem Lieferanten gelieferten Artikel beziehen. Die Lieferung ist aber von der Kundenbestellung unabhängig. Variante 3 löst das fachliche Problem. Lieferant Artikel Kunde Liefernachweis Bestellung Zulässigkeit der Uminterpretation von Relationshiptypen Die Uminterpretation von Relationshiptypen ist in solchen Fällen sinnvoll, in denen der Beziehungstyp bei weitergehender fachlicher Betrachtung selbst Entity-Merkmale aufweist. Formal ausgedrückt ergibt sich folgende Definition: Definition: Für die Uminterpretation eines Relationshiptypen müssen zwei Bedingungen erfüllt sein: der Relationshiptyp beschreibt Beziehungen, die aus Sicht von mindestens zwei beteiligten Entitytypen nicht-eindeutig sind, und die Instanzen des Relationshiptypen gehen nicht-eindeutige Beziehungen mit Instanzen von Entitytypen ein, die nicht an der ursprünglichen Beziehung beteiligt waren. Als nicht-eindeutige Beziehungen werden solche Beziehungen bezeichnet, deren Minimalkardinalität und/oder Maximalkardinalität von 1 abweicht. D.h. eine Beziehung ist aus Sicht eines Entitytypen dann eindeutig, wenn die Kardinalität für diesen Typen (1,1) beträgt. 14

15 Beispiel 1 Folgende fachliche Beschreibung ist gegeben: In einem Computerpool wird den Nutzern eine Anzahl von Rechnern zur Verfügung gestellt. Auf Grund von technischen und lizenzrechtlichen Einschränkungen, werden auf den Rechnern verschiedene Pakete an Softwareprodukten installiert. Aus diesen Anforderungen lässt sich zunächst eine typische M-N-Beziehung interpretieren 1 : Es gibt einen Entitytyp Softwareprodukt dessen Instanzen beliebig (genauer: unbestimmt) viele Beziehungen mit Instanzen des Typen Rechner eingehen können. Wiederum können auf den Rechnern beliebig viele Produkte installiert sein. Den ursprünglichen Anforderung wird nun folgende Information hinzugefügt: Eine datenbankgestützte Anwendung soll nun protokollieren, welche Nutzer die verschiedenen Produkte auf welchen Rechnern nutzen. Jede Nutzung soll protokolliert werden Der Text verleiht dem ursprünglich als Beziehung modellierten Konzept Installierte Software nun eine entity-artige Qualität. Die Nutzung bezieht sich nicht auf eine beliebige Konstellation von Rechner und Softwareprodukt, sondern auf die konkrete Kombination die durch den Relationshiptyp Installierte Software repräsentiert wird. Da Nutzer dasselbe Softwareprodukt auf demselben Rechner beliebig oft nutzen können, ist die Beziehung des Konzepts Installierte Sofware zum Nutzer nicht-eindeutig (0,n-Kardinalität). Der Relationshiptyp Installierte Software muss daher uminterpretiert werden. Softwareprodukt Installierte Software Nutzung Nutzer Rechner Wird eine der beiden oben genannten formalen Bedingungen verletzt, ist eine Uminterpretation nicht zulässig. 1 Da keine näheren Angaben vorliegen, wird von der genauen Gestalt der technischen und lizenzrechtlichen Einschränkungen abstrahiert. 15

16 Beispiel 2 Folgendes Szenario ist gegeben: Ein Versicherungsunternehmen stellt für die Beratung von (potentiellen) Kunden Mitarbeiter als Kundenbetreuer ab. Um die Kundenbindung zu verbessern, wird jedem Kunden für alle seine Versicherungsbelange genau ein Berater zugeordnet. Ein Berater betreut in der Regel jedoch mehrere Kunden. Entscheidet sich ein Kunde für ein Versicherungsprodukt, wird ein entsprechender Vertrag abgeschlossen. Fachlich kann man argumentieren, dass der Abschluss eines Vertrages aus der Beratung des Kundenberaters resultiert. Setzt man diese Interpretation 1:1 um, erhält man das folgende (fehlerhafte) Modell: Es wird ersichtlich, dass die erste Bedingung der o.g. Definition nicht erfüllt ist: die Beziehung ist nur aus Sicht eines Entitytypen (Kundenberater) nicht-eindeutig, aus Sicht des Kunden wird eindeutig auf einen Berater verwiesen. Wird der Vertrag direkt an den E-Typ Kunde modelliert, lässt sich die Komplexität des Modells reduzieren, ohne das Information verloren geht: Der Vertrag ist durch die (1,1)-Beziehung immer noch eindeutig auf einen Kundenberater zurückzuführen. Das Modell vereinfacht die Transformation, da der gültige, zweistellige Primärschlüssel des E-Typs Vertrag nun direkt aus dem Modell ableitbar ist. 2 Beispiel Generalisierung und Spezialisierung im ERM Die Generalisierung und Spezialisierung von Entitytypen dient dazu, gemeinsame Eigenschaften ähnlicher Entitytypen zusammenzufassen. Die gemeinsamen Attribute und Beziehungen aller ähnlichen Typen gehen dabei auf den generalisierten Typ über, spezifische Attribute und Beziehungen verbleiben in den spezialisierten Typen: 2 In der ersten Modellvariante wird ein dreistelliger Schlüssel aus Kundenberater, Kunde und Produkt suggeriert. Durch die funktionale Abhängigkeit des Kundenberaters vom Kunden würde ein solcher Schlüssel jedoch die Eigenschaft der Minimalität verletzen. 16

17 (1,1) Kundenbetreuer Betreuung (1,1) Kunde PersonalNr, Telefonnr, Büro Gehaltsklasse (1,1) Abteilungsleiter PersonalNr, Telefonnr, Büro, Dienstwagen Kundenbetreuer Betreuung (1,1) Kunde Gehaltsklasse (1,1) Mitarbeiter D,P PersonalNr, Telefonnr, Büro Abteilungsleiter Dienstwagen Unterschieden werden Generalisierung und Spezialisierung hinsichtlich ihrer Dimensionen Zerlegung und Vollständigkeit: 17

18 D - disjunkt Ein Entity darf nur maximal einem Spezialfall angehören N - nicht disjunkt Ein Entity darf beliebig vielen Spezialfällen angehören T - total Jedes Entity muss mindestens einem Spezialfall angehören D,T N,T P - partiell Ein Entity darf einem Spezialfall angehören, muss aber nicht Disjunkt-Total: Jedes Entity gehört immer genau einem Spezialfall an D,P Nichtdisjunkt-Total: Jedes Entity gehört immer mindestens einem Spezialfall an. N,P Disjunkt-Partiell: Jedes Entity kann maximal einem Spezialfall angehören. Nichtdisjunkt-Partiell: Jedes Entity kann einem oder mehreren Spezialfällen angehören Beispiele Disjunkt-total: Ein Student ist entweder als Fern- oder als Direktstudent eingeschrieben. Direktstudent Student D,T Fernstudent 18

19 Disjunkt-partiell: Ein Mitarbeiter kann Programmierer oder Kundenbetreuer sein (aber nicht beides). Es gibt jedoch Mitarbeiter, die weder das eine noch das andere sind. Mitarbeiter D,P Programmierer Kundenbetreuer Nichtdisjunkt-total: Ein Geschäftspartner eines Handelsunternehmens kann ein Lieferant oder ein Kunde sein. Es kann aber auch beides zutreffen, wenn ein Lieferant bei dem Handelsunternehmen Artikel bestellt - beispielsweise könnte ein Produzent und Lieferant von Kugelschreibern bei einem Händler für Büroartikel seine Druckertoner bestellen. Geschäftspartner, die weder Lieferant noch Kunde sind, gibt es nicht. Geschäftspartner N,T Lieferant Kunde Nichtdisjunkt-partiell: An einer Tagung können verschiedene Personen teilnehmen. Einige Teilnehmer sind Redner, d.h. sie halten auf der Tagung einen Vortrag. Veranstalter sind Teilnehmer, die an der Gestaltung der Tagung mitwirken. Veranstalter können auch selbst Vorträge halten, also Redner sein. Es gibt Teilnehmer, die weder Redner noch Veranstalter sind. Tagungsteilnehmer N,P Redner Veranstalter 1.9 Spezielle Konventionen der ER-Modellierung Bei der Erstellung konzeptioneller Modelle nach dem konstruktivistischen Modellbild der Wirtschaftsinformatik bestehen grundsätzliche Freiheitsgrade, wie bestimmte Sachverhalte im Modell darzustellen sind. Im Rahmen der Modellierung realweltlicher Zusammenhänge zur Konstruktion von Datenstrukturen äußern sich solche Freiheiten beispielsweise in der Frage, ob ein Konzept im ERM als Entity- oder als Relationshiptyp, oder welche Kardinalitäten für eine spezifische Beziehung modelliert werden sollen. Nicht selten lassen Modellierungssprachen wie das ERM mehrere Modellierungsvarianten für semantisch gleichartige Strukturen zu. Ein weiteres Problem stellen unterschiedliche Versionen gleicher Sprachen dar, so werden Modellierungssprachen wie das ERM von unterschiedlichen Autoren erweitert und modifiziert, implementierungsnahe Standards wie SQL werden von Herstellerfirmen für entsprechende Systeme unterschiedlich interpretiert oder ergänzt. 19

20 1.9.1 Benennung von Relationshiptypen Eine häufig gestellte Frage betrifft die Benennung von Relationshiptypen. In der Literatur existieren dafür verschiedene Ansätze, wie Verbenbeschreibungen (z. B. Student - nimmt teil - Vorlesung) oder Wortketten (Artikel - Artikel-Lieferant-Zuordnung - Lieferant). Beide Varianten haben Nachteile: Verbenbezeichnungen lassen häufig nur eine Leserichtung zu: Student - nimmt Teil (an) - Vorlesung ist sinnvoll, aber: Vorlesung - nimmt Teil (an) - Student ergibt keinen Sinn Verbenbezeichnungen führen dazu, dass resultierende Tabellen keinen fachlich sinnvollen Namen haben (z. B. Tabelle hat oder ist zugeordnet) die Verkettung mit dem Wort Zuordnung ergibt bei einer Uminterpretation unschöne Ausdrücke (z.b. Lieferanten-Artikel-Zuordnung-Kunden-Zuordnung) Aus diesem Grund gilt folgende Konvention: Konvention: Relationshiptypen sind (wenn möglich) mit sinnvollen Substantivbezeichnungen zu versehen! Beispiele: statt Mitarbeiter-Projekt-Zuordnung eher Projektmitglied statt Kunde-Bearbeiter-Zuordnung eher Betreuer statt (Professor) hält (Vorlesung), eher Dozent Die Einschränkung wenn möglich bezieht sich insbesondere auf Beziehungstypen, die in einer (1,1)-Kardinalität stehen. Bei solchen Beziehungen ist eine sinnvolle Bezeichnung teilweise kaum zu finden. Auch resultieren diese Relationshiptypen bei der Überführung in das Datenbankschema nicht in eigenen Tabellen. Deshalb gilt: Konvention: Relationshiptypen, die in einer (1,1)-Beziehung stehen, müssen nicht benannt werden, wenn sich keine sinnvolle Bezeichnung finden lässt Das Konzept Zeit im Entity-Relationship-Modell In Datenmodellen können häufig Beziehungen auftreten, die einen Zeitbezug haben und sich über diesen Zeitbezug definieren. Modelliert man an solche Relationshiptypen einen Entitytyp Zeit, so drückt man aus, dass die Beziehung zeitabpunkthängig und die Zeit Primärschlüsselbestandteil ist. Der Entitytyp Zeit nimmt jedoch bei der Überführung in das Datenbankschema eine Sonderrolle ein, da aus ihm keine Tabelle resultiert. Beispiel Kunden können Artikel bestellen. Um sicherstellen zu können, dass derselbe Kunde denselben Artikel zu einem späteren Zeitpunkt wieder bestellen kann, wird der Zeitpunktbezug in das Modell aufgenommen. Die Abbildung zeigt, wie das Zeitkonstrukt im ERM dargestellt wird und welche Tabellen resultieren. Es wird sichtbar, dass der Entitytyp Zeit nur noch als Attribut 20

21 und Primärschlüsselbestandteil in der Relation Bestellung auftaucht, jedoch in keiner eigenen Relation: Artikel Relation Kunde Kundennr Name Relation Artikel Artikelnr Name Artikelnr Bestellung Zeit Relation Bestellung #Kundennr #Artikelnr Zeitpunkt Menge Kunde Menge Zeitpunkt Kundennr Beziehungen können sich neben Zeitpunkten auch auf Zeitspannen beziehen. Konzeptionell ist eine Zeitspanne nichts anderes als eine Paarung von zwei Zeitpunkten. Dies lässt sich im ERM einfach durch eine Struktur über dem Entitytyp Zeit darstellen. Soll sich nun ein Relationshiptyp auf eine Zeitspanne beziehen, wird die Struktur uminterpretiert. Beispiel: Ein Vermieter vermietet Wohnungen an Mieter. Das Mietverhältnis ist gekennzeichnet durch eine Zeitspanne (also einen Start- und Endzeitpunkt). Die Abbildung zeigt die Zeitspanne als Struktur über Zeitpunkten und die resultierenden Relationen: Wohnung Relation Mieter Relation Wohnung Wohnungsnr Mietverhältnis Zeitspanne Mieternr Name Wohnungsnr Name Mieter Relation Mietverhältnis Zeit #Mieternr... #Wohnungsnr... Anfangszp... Endzp... Mieternr Zeitpunkt Als Konvention gilt: Konvention: Zeitpunkte und Zeitspannen sind im ERM mit eigenen Entitytypen bzw. Strukturen zu modellieren, wenn sich Beziehungen zur eindeutigen Identifikation auf Zeitpunkte oder Zeitspannen beziehen. Anders ausgedrückt: ist die Zeit in irgendeiner Form Bestandteil des Primärschlüssels eines Relationshiptypen, dann ist sie explizit zu modellieren. 21

22 1.9.3 Konventionen zu Kardinalitäten Kardinalitäten beschreiben einen Beziehungstypen näher bzw. drücken aus, wie oft ein Entity eines Typs eine bestimmte Beziehung eingehen kann. Da die Kardinalitäten ein wesentlicher Bestandteil eines Beziehungstyps sind, kann auf deren Angabe nicht verzichtet werden. Daher gilt: Konvention: Kardinalitäten sind immer zu explizieren, zwischen Entitytypen, Relationshiptypen und uminterpretierten Relationshiptypen gibt es keine Kanten ohne Kardinalitätsangaben! Teilweise lassen sich Aufgabentexte oder fachliche Beschreibungen hinsichtlich der Kardinalitäten unterschiedlich interpretieren. Für die untere Grenze (Minimalkardinalität) gilt daher folgende Konvention: Konvention: Bei unterschiedlichen Interpretationen hinsichtlich der Kardinalitäten sollte immer so wenig restriktiv wie möglich modelliert werden. Das heißt konkret: wenn die textliche Beschreibung nichts anderes vorgibt, ist als untere Grenze 0 und als obere Grenze n zu modellieren. Impliziert der Aufgabentext klar eine 1 als Minimum (z.b.: ein X hat genau/mindestens ein Y ) oder Maximum (z.b.: ein X hat genau/höchstens ein Y ), ist das im Modell natürlich zu berücksichtigen. Für die Schreibweise der Kardinalitäten gilt: Konvention: Die vorgeschriebene Schreibweise für Kardinalitäten ist: (0,1), (1,1),, (1,n). Andere Schreibweisen von bestimmten Autoren verzichten auf die Klammern, geben statt einem Buchstaben einen Stern (*) als Symbol für beliebig an, oder trennen Min und Max nicht durch Komma, sondern mit zwei Punkten. Aus Gründen der einheitlichen Darstellung ist im Rahmen der Lehrveranstaltung nur die obere Schreibweise zugelassen. Häufig wird bei Beziehungen, deren Maximum auf beiden Seiten n ist, die Schreibweise mit wechselnden Buchstaben n und m [z.b.: - (0,m)] verwendet. Damit soll angezeigt werden, dass die tatsächliche Kardinalität auf Entity-Ebene auf der einen Seite von der auf der anderen Seite unabhängig ist. Da eine solche Abhängigkeit praktisch nie besteht, kann auf wechselnde Buchstaben als Anzeige beliebiger Maxima verzichtet werden (im anderen Fall dürfte sonst im ganzen Modell kein Buchstabe doppelt vorkommen) Konventionen zur Generalisierung/Spezialisierung Für Generalisierungen/Spezialisierungen gilt: Konvention: Entitytypen sollten nach Möglichkeit sinnvoll generalisiert bzw. spezialisiert werden. 22

23 Ob eine Generalisierung sinnvoll ist, kann im konkreten Fall Ermessenssache sein. Generalisierungen empfehlen vor allem dann, wenn dadurch Attribute und Beziehungskanten nicht redundant modelliert werden müssen. Spezialisierungen empfehlen sich, wenn bestimmte Attribute oder Beziehungen eines Entitytyps nur für eine abgrenzbare Gruppe von Instanzen eine Bedeutung haben. Darüber hinaus gilt: Konvention: Generalisierungen sind immer hinsichtlich ihrer Zerlegung (disjunkt/nichtdisjunkt) und ihrer Vollständigkeit (total/partiell) zu kennzeichnen Kommentare und zusätzliche Annahmen Textliche Beschreibungen fachlicher Sachverhalte sind in der Regel in natürlicher Sprache verfasst - das Gleiche gilt für Klausur- und Übungsaufgaben. Alle natürlichen Sprachen (z.b. Deutsch, Englisch, aber auch Fachsprachen) teilen die Eigenschaft potentiell mehrdeutig und damit unterschiedlich interpretierbar zu sein. Sprachen wie das ERM verwenden natürlich- / bzw. fachsprachliche Ausdrücke und erben als semiformale Sprachen diesen Defekt. Aus diesem Grund kann es sinnvoll sein, Modellelemente mit Kommentaren zu annotieren, um so das Modellverständnis zu verbessern. Auch Annahmen, welche der Modellerstellung zu Grunde gelegt werden, weil bestimmte fachliche Informationen fehlen oder unklar sind, sollten expliziert werden. Ein weiterer Anwendungsfall für Kommentare sind Informationen oder Einschränkungen, die sich in der gewählten Modellierungssprache nicht ausdrücken lassen. Für die Lehrveranstaltung Datenmanagement gelten folgende Konventionen: Konvention: Zusätzliche Annahmen können getroffen werden, sollten jedoch deutlich und explizit am Modell annotiert werden. Die Annahmen dürfen Aufgaben jedoch nicht im Kern verändern (so können zwar ergänzende Annahmen getroffen werden, eine Vereinfachung durch Weglassen von Aufgabenteilen durch Annahmen ist unzulässig). 23