Das Entity-Relationship-Modell 1

Ein Phasenmodell der Softwareentwicklung Implementierung Analyse Design oder Entwurf Abnahme und Einführung Wartung und Pflege

Datenbankentwurf im Softwareentwicklungsprozess

Phasen des DB-Entwurfs Requirements-Analyse Welche Daten? Welche (häufigen) Operationen? Welche Anwendungen? Nicht-funktionale Anforderungen, z.B. Performance Konzeptueller DB-Entwurf Spezifikation der gesammelten Anforderungen in einer high-level-Darstellung (z.B. ER-Modell) Logischer DB-Entwurf Übersetzung des konzeptuellen DB-Entwurfs in ein Schema im Datenmodell des Ziel-DBMS (zumeist relationales DBMS) Schema-Verfeinerung Normalisierung des relationalen Schemas soweit erforderlich (Nutzung Normalformen-Theorie) Physischer DB-Entwurf Phys. Entwurfsentscheidungen (Index, Clusters) entsprechend Last-Profilen und Performance-Anforderungen Security-Entwurf Definition von Benutzergruppen, Rollen, Zugriffsrechten

Konzeptueller DB-Entwurf Konzeptueller Entwurf Entity-Relationship-Modell ist traditioneller Ansatz Was sind die Entitäten und die Beziehungen im gewählten Weltausschnitt? Welche Information über diese Entitäten und Beziehungen sollen in der DB gespeichert werden (Informationsbedarfsanalyse)? Was sind die Integritätsbedingungen (oder Business Rules), die gelten müssen? Ein DB-Schema kann graphisch im ER-Modell repräsentiert werden (ER-Diagramm) Ein ER-Diagramm läßt sich in ein relationales Schema übersetzen (logischer DB-Entwurf)

Das ER-Modell - Analyse

Das ER-Modell - Entität und Entity-Menge Eine Entität (Entity) ist ein Objekt der realen Welt, ein individuelles und eindeutig identifizierbares Exemplar von Dingen, Begriffen oder Personen Entity: “A thing that has a real or individual existence in reality or in mind“ (Webster) Gleichartige Entitäten werden zu Entity-Mengen (Entity set) zusammengefasst.

Das ER-Modell - Attribute von Entity-Mengen Ein Attribut ist eine Eigenschaft, die allen Entitäten einer Entity-Menge gemeinsam ist. Eine Entität wird durch ihre Attributwerte beschrieben. optional obligatorisch Darstellung als Oval name stadt adr strasse name

Das ER-Modell - Schlüssel Ein Schlüssel ist eine minimale Menge von Attributen, die die zugeordnete Entität eindeutig identifizieren. Sie kann aus einem oder mehren Attributen zusammengesetzt sein. Schlüsselattribute sind immer obligatorisch. Mehrere Kandidaten möglich, z.B. Ausweis-Nr. oder Sozialversicherungs-Nr. bei Personen Darstellung: Attributname unterstrichen pnr

ER-Modell - Beziehungen Zwischen Entitäten gibt es Beziehungen (Relationships), die auch Attribute haben können. Beziehungen beschreiben einen Zusammenhang zwischen Entitäten, der im Allgemeinen durch ein Verb ausdrückt wird. Gleichartige Beziehungen zwischen Entitäten der gleichen Entity-Menge werden zu Beziehungsmengen zusammengefasst. Angestellter Arbeitet Abteilung

Beziehungen im ER-Modell Aktivitäten zwischen Entitäten werden durch Beziehungen beschrieben Mathematische Beschreibung einer Beziehung: Ein Beziehung R (Relationship) ist eine Relation im mathematischen Sinne, also eine Teilmenge des kartesischen Produkts der Entity-Mengen E1, E2,.... En: R  E1 x E2 x.... x En R ist binär oder vom Grad 2, falls n = 2 ist. n heißt der Grad der Beziehung.

Beispiele (1) seit name aname pnr gehalt anr budget Manager leitet Abteilung 1 1 seit name aname pnr gehalt anr budget arbeitet Angestellter Abteilung n 1 seit name pname pnr gehalt pnr dauer Angestellter arbeitet Projekt m n

Beispiele (2) Ehefrau verheiratet Person 1 1 Ehemann vorgesetzt Angestellter 1 n rapportiert untergeordnet oberes Teil zusammen- gesetzt Teil m n unteres Teil Zwischen den gleichen Entity-Mengen können jeweils unterschiedliche Relationship-Mengen definiert werden. arbeitet m n Angestellter Projekt 1 leitet n

Kardinalität von Beziehungen leitet / wird_geleitet Manager Abteilung 1:1 arbeitet mit / für Manager Mitarbeiter 1:n arbeitet an / bearbeitet von Projekt Mitarbeiter m:n

Integritätsbedingungen in Relationships Verfeinerung der Semantik einer Beziehung Sei R  E1 D E2 ... D En card(R, Ei) = (min,max) bedeutet, daß jedes Element aus Ei in wenigstens min und höchstens max Ausprägungen von R enthalten sein muß (mit 0  min  max, max  1) Graphische Darstellung (min1,max1) (min2,max2) E1 R E2 Verfeinerung der Semantik einer Beziehung e1 nimmt an (min1,max1) Beziehungen von Typ R teil e2 nimmt an (min2,max2) Beziehungen von Typ R teil Beispiel (0,1) (1,1) Angestellter leitet Abteilung (1,1) (1,*) arbeitet_in

Komplexität binärer Relationships Bemerkung Beispiel (1,1)(1,1) Strenge 1:1-Beziehung, umkehrbar eindeutige Funktion Ehe zwischen Ehemännern und Ehefrauen (1,1)(0,1) (0,1)(1,1) Partielle 1:1 Ehe zwischen Ehemännern und Frauen (0,1)(0,1) Allgemeine 1:1 Ehe zwischen Männern und Frauen (1,1)(1,*) (1,*)(1,1) Strenge hierarchische Beziehung Angestellte in einer Abteilung (1,1)(0,*) (0,*)(1,1) Funktionale Abhängigkeit ohne Existenzbedingung Beziehung zwischen Männern (potentiellen Vätern) und Kindern (0,1)(1,*) (0,1)(0,*) (1,*)(0,1) (0,*)(0,1) Allgemeine hierarch. Beziehung (1:n) (k,l)(r,s) Âllgemeine m:n-Beziehung (l,s 1) Angestellte arbeiten für Projekte

Schwache Entities Schwaches Entity (weak entity) kann eindeutig identifiziert werden nur über den Primärschlüssel einer anderen (Owner) Entity. Owner Entity und Weak Entity müssen in einer 1:n-Beziehung stehen (ein Owner, mehrere Weak Entities) name pnr name alter gehalt Angestellter hat Kinder (0,*) (1,1) Jedes Entity aus Kinder muß an der Beziehung teilnehmen (total Participation Constraint)

ISA-Beziehung Vererbung von Attributen (vgl. OO Sprachen) A “is a“ B heißt: Jedes A Entity ist zugleich auch ein B Entity Overlap Constraints: Kann Joe zugleich ein Fest-Angestellter und ein Contractor sein (erlaubt / nicht erlaubt)? Covering Constraints: Kann jeder Angestellte in Intern oder Extern klassifiziert werden (ja/nein) Nutzen von ISA: Hinzufügen von Attributen spezifisch für einen Subtyp Identifizieren von Entities, die an Beziehungen teilnehmen (Generalisierung) name pnr gehalt Angestellter stundensatz stundenzahl ISA vertrags_nr Extern Interner

Aggregation* Zur Modellierung von Relationships zwischen Entity-Mengen und Relationship-Mengen Erlaubt es, eine Relationship-Menge (z.B. “Sponsors“) als eine Entity-Menge zu betrachten, um an einer anderen Relationship teilzunehmen name pnr gehalt Angestellter kontrolliert bis startdatum seit name budget pid pbudget id Projects Sponsors Abteilung

Konzeptueller Entwurf im ER-Modell Entwurfsentscheidungen Sollte ein Konzept als Entity oder Attribut modelliert werden? Sollte ein Konzept als Entity oder Relationship modelliert werden? Bestimme die Beziehungen: Binär oder ternär? Aggregation? Constraints im ER-Modell Möglichst viel Datensemantik sollte erfaßt werden Einige Constraints können mit den Mitteln des ER nicht ausgedrückt werden (z.B. Wertabhängigkeiten zwischen Attributen)

Checkliste zum Finden von Entitäten Lassen sich konkrete Objekte identifizieren? Reale Objekte Formulare als Vorlage für Entitäten. Zu welchen Kategorien gehören die Entitäten? Konkrete Objekte Personen und deren Rollen Informationen über Aktionen Orte Organisationen Schnittstellen des System Liegt ein aussagefähiger Entity-Mengen-Name vor? Wann liegt keine Entität vor

Checkliste zum Finden von Attributen Ist ein Attribut problemrelevant? Gehört ein Attribut zu einer Entität oder zu einer Beziehung? Welche Attribute können als Schlüsselattribute dienen? Ist der Attributname geeignet? sprechende Namen Eindeutigkeit Welche Datentypen liegen vor? Standarddatentypen : NUMBER, Date, VARCHAR Liegen für Attribute bestimmte Domänen, das heißt festgelegte Wertebereiche vor? männlich, weiblich Wochentage

Checkliste zum Finden von Beziehungen Liegen zwischen Entitäten permanente Beziehungen vor ? Ist eine Benennung der Beziehung sinnvoll ? Existieren zwischen Entitäten mehrere Beziehungen ? Prüfen Sie, ob die Beziehungen eine unterschiedliche Bedeutung besitzen unterschiedliche Kardinalitäten haben unterschiedliche Optionalität besitzen ob es sich um eine Kann- oder eine Muß–Beziehung handelt. Gehören Attribute zu einer Beziehung? Eventuell´Beziehung in eine Entität umformen Läßt sich die Beziehung in eine Kategorie einordnen ? Das Ganze und seine Teile Der Behälter und sein Inhalt ( z.B. Flugzeug und Pilot) Kollektion und ihre Mitglieder ( z.B. Firma, Angestellte) Konfiguration von Teilen zu einem Ganzen ( z.B. Szenen zu einem Film) Teile können nicht vom Ganzen getrennt werden ( München ist Teil von Bayern) Tupel/Element (Fahrzeug besteht aus Auto und Eigentümer)

Künstliche Schlüsselattribute künstliches Schlüsselattribut (surrogate key) zusätzliches Attribut ohne Anwendung in der realen Welt i.d.R. Datentyp: NUMBER dient zur eindeutigen Identifizierung der Entities der zugehörigen Entity-Menge ersetzen einen aus mehreren Attributen zusammengesetzten Primärschlüssel; diese Attribute werden Zweitschlüssel weniger Attribute bei Verwendung des Primärschlüssels als Fremdschlüssel einfacherer Index-Aufbau schnellere Suche

Entity vs. Attribut Sollte Adresse ein Attribut von Angestellter sein oder ein Entity (in Beziehung zu Angestellter) Abhängig von der Benutzung der Adress-Information und der Semantik der Daten Wenn mehrere Adressen pro Angestellter vorhanden, dann sollte Adresse ein eigenständiges Entity sein (wenn mengenwertige Attribute ausgeschlossen sind) Wenn die Struktur der Adresse wichtig ist, d.h. Zugriff auf Bestandteile der Adresse (wie Stadt), dann muß Adresse als separates Entity modelliert werden (mit atomaren Attributwerten) plz stadt strasse Adresse (0,*) (1,*) Angestellter

Entity vs. Attribut (Forts.) von bis name name pnr gehalt id budget Angestellter Arbeitet_in Abteilung So ist es nicht möglich, die Mitarbeit eines Angestellten über mehrere Zeiträume zu modellieren (ähnlich wie mehrere Adressen eines Mitarbeiters)  Ersetzen der zeitbezogenen Attribute (von,bis) durch das neue Entity Dauer Es entsteht eine ternäre Beziehung von bis Dauer name name pnr gehalt id budget Angestellter Arbeitet_in Abteilung

Ternäre Beziehungen Ternäre Beziehungen können nicht automatisch in binäre Beziehungen aufgebrochen werden name Professor titel isbn empfiehlt Vorlesung Buch name Professor titel P-V P-B isbn Vorlesung V-B Buch

Ternäre Beziehungen (Forts.) Hier verlieren wir die Information, daß Heuer das Buch 9-876 nur für die Vorlesung DB2 aber nicht für DB1 empfiehlt. Könnten auch zusätzliche (fragwürdige) Information abspeichern, die sonst nicht darstellbar wäre, z.B. das Buch 7-000 für DB3, ohne daß ein Professor diese Vorlesung hält oder das Buch empfiehlt

Konzeptueller Entwurf (Zusammenfassung) Konzeptueller Entwurf folgt der Anforderungsanalyse Ergebnis: eine “high-level“ Beschreibung der zu speichernden Daten ER-Modell populär für konzeptuellen Entwurf Basis-Konstrukte: Entities, Relationships, Attribute (von Entities und Relationships) Zusätzliche Konstrukte: Weak Entities, ISA-Beziehungen, Aggregation Constraints (Integritätsbedingungen) im ER: Kardinalitätsrestriktionen (1:1, 1:n, m:n) Komplexität von Beziehungen in min,max-Notation (Participation Constraints) Overlap/Covering-Constraints in ISA-Hierarchien Bestimmen von Constraints wichtig für guten DB-Entwurf Einige Constraints (z.B. funktionale Abhängigkeiten) lassen sich im ER-Modell nicht ausdrücken Entwurf ist subjektiv Entity vs. Attribut, Entity vs. Relationship, Binär oder Ternär, mit oder ohne ISA, mit oder ohne Aggregation