Kapitel 4: Konzeptueller Datenbankentwurf

Transkript

1 4. Konzeptueller Datenbankentwurf Seite 1 Kapitel 4: Konzeptueller Datenbankentwurf Der Entwurf des konzeptuellen Schemas ist Teil eines übergeordneten Softwareentwurfsprozesses. Im Pflichtenheft eines zu entwickelnden Anwendungssystems werden die Informationsbedürfnisse definiert. Entity-Relationship-Modell (ERM). Unified Modeling Language (UML).

2 4. Konzeptueller Datenbankentwurf 4.1. Datenbankentwurf Seite Datenbankentwurf konzeptueller Entwurf: finde eine umfassende Strukturierung der gesamten Informationsanforderungen der Miniwelt. konzeptuelle Schema. logischer Entwurf: bilde die Zusammenhänge des konzeptuellen Schemas in Relationsschemata ab. logisches Schema. Das logische Schema ist Teil des zum Einsatz kommenden (relationalen) Datenbanksystems. physischer Entwurf: definiere die Abspeicherung der Relationen auf den Speichermedien und lege Indexstrukturen zur Effizienzsteigerung der Anwendungen fest.

3 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite Entity-Relationship-Modell Entitäts- und Beziehungstypen LCode Land Lage Kontinent SName Prozent KName Entitäts- und Beziehungsmengen Land LCode LName Austria A 84 Egypt ET 1001 Germany D 357 Turkey TR 779 Kontinent KName Europe 3234 Asia Africa Land Lage Kontinent LCode KName Prozent A Europe 84 ET Africa 90 ET Asia 10 D Europe 100 TR Europe 32 TR Asia 68

4 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite Entitäts- und Beziehungstypen Entitätstypen ( Objekttypen); Rechtecke Beziehungstypen; Rauten Attribute; Ovale Attribute eines Entitätstyps, die einen Schlüssel ergeben, werden durch Unterstreichung gekennzeichnet. Der Schlüssel eines Beziehungstyps ist implizit durch die Schlüssel der an ihm beteiligten Entitätstypen gegeben. Auch Beziehungstypen können Attribute besitzen.

5 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite 5 Schema und Instanz Ein aus Entitäts- und Beziehungstypen gebildetes Schema nennen wir ER-Schema. Ein konkreter Zustand der betrachteten Miniwelt wird durch eine Menge von Entitäten und Beziehungen gemäß den Strukturen des Schemas repräsentiert. Zu jedem Typ existiert somit eine Entitäts- bzw. Beziehungsmenge, in denen die jeweiligen Entitäten und Beziehungen zusammengefasst sind; wir nennen dies eine Instanz des ER-Schemas. Die Entitäts- und Beziehungsmengen einer Instanz müssen die folgenden Bedingungen erfüllen: Je zwei Entitäten, die gleiche Schlüsselwerte besitzen, sind auch in den übrigen Attributen gleich. Die Werte der einzelnen Schlüsselattribute müssen verschieden von null sein (Schlüsselbedingung für Entitätsmengen). Je zwei Beziehungen, in denen die Werte der Schlüssel der an ihnen beteiligten Entitäten gleich sind, sind auch in den übrigen Attributen gleich (Schlüsselbedingung für Beziehungsmengen). Jede, in einer Beziehung über ihren Schlüssel referenzierte Entität, existiert auch in der zugehörigen Entitätsmenge (referentielle Integrität, Fremdschlüsselbedingung).

6 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite 6 Kardinalitäten: Beziehungskomplexitäten Sei E B eine Kante, die einen Entitätstyp E mit einem Beziehungstyp B verbindet und mit einer Beziehungskomplexität (min, max), min max, beschriftet ist. Seien e, b eine Entitäts- und Beziehungsmenge einer Instanz. Jede Entität µ e ist dann in mindestens min und maximal max Beziehungen ν b involviert. Wählen wir für max anstelle einer Zahl, so steht dies für beliebig viele. Beispiel Stadt (0,1) (1,1) HStadt Land (1,3) Lage Kontinent

7 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite 7 partielle und totale Beziehungen min = 0: es sind Instanzen zulässig, in denen Entitäten µ e auftreten können, die in keiner Beziehung ν b involviert sind (partielle Beziehung). min = 0, max = 1: in jeder Instanz darf jede Entität µ e nur in höchstens einer Beziehung ν b involviert sein (partielle Schlüsselbedingung). min = 1, max = 1: in jeder Instanz muss jede Entität µ e in genau einer Beziehung ν b involviert sein (totale Schlüsselbedingung).

8 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite 8 rekursive Beziehungstypen Ist derselbe Entitätstyp mehrmals in demselben Beziehungstyp involviert, so reden wir von einem rekursiven Beziehungstyp. Es wird eine Unterscheidung von unterschiedlichen Rollen des Entitätstyps erforderlich. Beispiel Mündung gerichteter Graph Haupt Neben (0,1) Chef Unter (0,1) Quelle Senke Fluß Hierarchie Angestellte Knoten

9 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite 9 mehrstellige Beziehungstypen Bisher waren Beziehungstypen binär. Ein Beziehungstyp kann im Allgemeinen über beliebig vielen Entitätstypen definiert sein. Beziehungstyp über drei Entitätstypen und eine Zerlegung des Beziehungstyps in zwei binäre Beziehungstypen. Organisation OName Land Unterstützung LCode Projekt PrName Organi- Land LO OP Projekt sation LCode OName PrName Ist die Zerlegung unabhängig von der Wahl der Beziehungskomplexitäten?

10 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite 10 Beziehungsmengen zum Beispiel Unterstützung Land Organisation Projekt LCode OName PrName EgoLand Invest Economy AltruLand Invest Economy AltruLand Invest Education LO OP Land Organisation Organisation Projekt LCode OName OName PrName EgoLand AltruLand Invest Invest Invest Invest Economy Education

11 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite 11 Mondial ER-Schema HStadt Prozent LName LCode Land Lage Kontinent KName PName LCode LaPro Provinz Art Mitglied Organisation Einwohner LGrad BGrad OName ProSta Stadt LCode SName PName

12 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite 12 Mondial ER-Schema alternativ HStadt Prozent LName LCode Land Lage Kontinent KName ProNr PName LaPro Provinz Art Mitglied Organisation Einwohner LGrad BGrad OName ProSta Stadt StaNr SName

13 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite Erweiterungen Die Erfahrungen beim Einsatz des Entity-Relationship-Modells haben gezeigt, dass die Modellierung mittels Entitäts- und Beziehungstypen in gewissen Situation zu unbefriedigenden Resultaten führen kann. mengenwertige und strukturierte Attribute, schwache Entitätstypen, Generalisierung, Aggregation.

14 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite 14 Mengenwertige und strukturierte Attribute LCode LName HStadt OName Land Organisation Beginn

15 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite 15 schwache Entitätstypen LCode LName PName SName Einwohner Land LaPro Provinz ProSta Stadt HStadt LGrad BGrad

16 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite 16 Generalisierung GName Belastung GName Belastung GeSe Gewässer (0,1) Gewäs- (0,1) ser GeFlu (1,1) (1,1) ISA See Fluss See Fluss SName FName Länge Länge

17 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite 17 Aggregation LCode LName Art OName Land HStadt LO Organisation LP PName LOP Betrag GName Belastung Provinz Projekt PG (0,1) Gewässer PS PrName Budget Dauer ISA SName Einwohner Stadt BGrad LGrad See Länge Fluss

18 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite Transformation in Relationsschemata Wir ordnen zunächst jedem Entitätstyp und jedem Beziehungstyp ein Relationsschema zu. In gewissen Situation fassen wir mehrere Relationsschemata wieder zu einem Schema zusammen, um die Anzahl Schemata nicht unnötig groß werden zu lassen. Ein so erhaltenes logisches Schema ist als Ausgangspunkt für eine weitere Verfeinerung zu verstehen, in die dann menschliches, nicht im ER-Schema dokumentiertes Wissen über die geplanten Anwendungen der Miniwelt eingehen kann.

19 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite 19 Beispiel Mondial Land(LCode, HStadt, LName, ), Provinz(PName, LCode, ), Stadt(SName, LCode, PName, Einwohner, LGrad, BGrad), Organisation(OName), Projekt(PrName, Budget), Gewässer(GName, Belastung), See(GName, ), Fluss(GName, Länge). LO(LCode, OName, Art), LOP(LCode, OName, PrName, Betrag), PG(GName, PrName, Dauer).

20 4. Konzeptueller Datenbankentwurf 4.2. Entity-Relationship-Modell Seite 20 Beispiel Mondial fertiggestellt Land(LCode,LName,HStadt,) LO(LCode,OName,Art) Organisation(OName) LOP(LCode,OName,PrName,Betrag) Projekt(PrName,Budget) Provinz(PName,LCode,) Gewässer(GName,Belastung,PrName,Dauer) Stadt(SName,PName,LCode,Einwohner, LGrad,BGrad) See(GName,) Fluss(GName,Länge)

21 4. Konzeptueller Datenbankentwurf 4.3. Unified Modeling Language Seite Unified Modeling Language Im Unterschied zum Entity-Relationship-Modell deckt die Unified Modeling Language (UML) den gesamten Softwareentwurf ab und geht damit über den konzeptuellen Datenbankentwurf hinaus. Insbesondere werden eine Reihe von Techniken angeboten, um das dynamische Verhalten eines Systems zu definieren, beispielsweise durch Festlegen der zulässigen Abfolgen der einzelnen Anwendungsprozesse. Wir beschränken uns auf die zur Strukturierung der Daten zur Verfügung stehenden Konzepte.

22 4. Konzeptueller Datenbankentwurf 4.3. Unified Modeling Language Seite 22 Klassendiagramm Eine Klasse repräsentiert eine Menge von gleichartigen Objekten und ist somit vergleichbar zu einem Entitätstyp oder Beziehungstyp eines ER-Schemas, oder auch zu einem Relationsschema. Die relevanten Eigenschaften der Objekte einer Klasse werden durch Attribute repräsentiert. Einer Klasse wird kein Schlüssel zugeordnet, da ganz im Sinne einer objektorientierten Modellierung jedem Objekt implizit eine systemweit eindeutige Objektidentität zugeordnet ist, die zur Identifizierung und insbesondere auch zum Ausdrücken von Beziehungen in Form von Referenzen verwendet werden kann.

23 4. Konzeptueller Datenbankentwurf 4.3. Unified Modeling Language Seite 23 Generalisierung, Assoziation, Komposition und Aggregation Klassen können mittels Generalisierungen in Hierarchien angeordnet werden. Beziehungen zwischen Klassen werden durch Assoziationen und Kompositionen ausgedrückt. Kompositionen sind eine spezielle Form einer Assoziation. Sie repräsentieren Teil-Ganzes-Beziehungen unter den Objekten, in denen das in der Rolle eines Teils stehende Objekt A zu einem Zeitpunkt mit genau einem in der Rolle des Ganzen stehenden Objekts B in Beziehung stehen kann, wobei A ohne das es enthaltende Objekt B keine Existenzberechtigung hat. Assoziationen können über zwei oder mehreren Klassen definiert sein. Ihnen kann des Weiteren eine Assoziationsklasse zugeordnet werden, so dass Assoziationen durch Attribute beschrieben werden können und selbst an anderen Assoziationen Teil haben können. Kompositionen und Assoziationen können durch Rollenangaben und Multiplizitäten weiter beschrieben werden. Häufig wird auch noch eine schwächere Form der Komposition, die Aggregation, unterschieden. Eine Aggregation ist eine Assoziation, die eine Teil-Ganzes-Beziehung ausdrückt, ohne die Existenzbeschränkung einer Komposition.

24 4. Konzeptueller Datenbankentwurf 4.3. Unified Modeling Language Seite 24 Mondial in UML Land * * Organisation LCode LName HStadt 1 LO Art * * OName Gewässer 1..* Provinz GName Belastung PName 1 LOP Betrag PG Dauer * Stadt SName Einwohner LGrad BGrad * Projekt PrName Budget 0..1 See Fluss Länge