Entity - Relationship Diagramme Software Entwicklung Darstellungsart von ERD‘s Mögliche Beziehungen zwischen Entities Grenzen Beispiele

Software Entwicklung Projektmanagement EDV Phasen Realisierung Einführung Projektinitierung Vorstudie Fachkonzept DV-Design Gewährleistung Qualitätssicherung Dokumentation Software Entwicklung Entity Relationship Diagramme sind ein Werkzeug im Software Entwicklungs Prozess. Sie werden in der Phase des Fachkonzeptes erstellt, um die zukünftigen Datenstrukturen zwischen Auftraggeber und Auftragnehmer (Programmierer) zu definieren. In der Phase “DV-Design” sind sie die Vorlage für die Entwicklung der Datenbankstruktur. Das hier gezeigte “Wasserfall-Modell” sieht einen einmaligen Durchlauf der angegebenen Phasen vor. Die Ergebnisse einer Phase sind die Vorgaben für die folgende Phase. Weitere Vorgehensmodelle sind das Spiralmodell oder das prototypische Vorgehen, die beide die einzelnen Phasen mehrfach durchlaufen. Aufwände: Vorstudie 10% Fachkonzept 15 - 20% DV-Design 15% Realisierung 25 - 45% Einführung 5 - 15% Gewährleistung 5 - 15%

ERD Entity Relationship Diagramme wurden im Jahr 1976 von Chen vorgestellt. Top-Down Methode Visualisieren der Beziehungen zwischen den Daten Kommunikation mit dem Auftraggeber Im Gegensatz zu der bereits bekannten Methode des Normalisierens, die vom einzelnen Datenelement zu größeren Srtukturen, den Tabellen, geht, beschreiben Entity-Relationship Diagramme die Zusammenhänge zwischen großen Datenstrukturen. Diese Vorgehensweise nennt man Top-Down. Die entstehenden Diagramme zeigen die Zusammenhänge recht anschaulich und sind geeignet, die Strukturen auch dem „Nicht-EDV-Fachmann“ zu erklären und mit ihm die Idee des zukünftigen Programms zu diskutieren. Entity kann übersetzte werden als „Einheit,die sich von anderen Gebilden abgrenzen kann“. Zu dem deutschen Wort „Entität“ sagt der Duden: „Dasein im Unterschide im Wesen eines Dinges“. Relationship wird mit „Beziehung“ übersetzt.

Definition der ERD’s Entity Relationship Diagramme fassen Datenelemente zu logischen Einheiten zusammen und stellen grafisch die Beziehungen zwischen diesen Einheiten dar. Die logischen Einheiten werden Entity genannt, die Beziehungen werden Relationship genannt. Die Entitäten und ihre Beziehungen zueinander werden grafisch dargestellt. Die Daten der realen Welt, die für die Bearbeitung durch das EDV-System notwendig sind, werden aussortiert und zu sinnvolen Gruppen zusammengefasst. Dieser Ausschnitt der realen Welt wird häufig „Miniwelt“ genannt. Die zusammengefaßten Einheiten entsprechen nicht unbedingt den späteren Datenbanktabellen.

Darstellung der ERD’s Entity 1 Entity 2 Relationship (n,m) (k,l) Die Rechtecke beschreiben die logischen Einheiten von zusammenhängenden Daten und geben diesen Einheiten einen sinnvollen Namen. Die einzelnen Datenelemente können in einer verfeinerten Darstellung aufgeführt werden. Die Rauten beschreiben die Beziehungen zwischen zwei oder mehreren Entities. Diese Beziehungen können häufig durch einen einfachen Satz ausgedrückt werden. Die eingeklammerten Buchstaben (n,m) beschreiben die minimale und maximale Menge von Elementen aus Entitiy 1 zu einem Element aus Entity 2 gehören. Analog beschreiben die eingeklammerten Buchstaben (k,l) wieviel Elemente aus Entitiy 2 zu einem Element aus Entity 1 in Beziehung stehen. Diese Angaben werden Kardinalität oder Wertigkeit genannt.

Hierarchische Beziehung Student Matr Nr Name Adresse Wohnsitz Strasse Haus Nr PLZ Ort hat Adressen (1,n) (1,1) Jeder Student hat 1 bis n Adressen Jede Adresse gehört zu genau einem Studenten Eine Beziehung, die aus zwei Entities besteht kann gewöhnlich in zwei Richtungen gelesen werden: Jeder Student hat 1 bis n Adressen: Es darf also nicht möglich sein, Name und Matrikel Nummer eines Studenten un das System einzugeben, ohne gleichzeitig auch seine Adresse einzugeben. Technisch wird diese Forderung dadurch gelöst, dass alle zusammenhängenden Daten in ein Formular eingetragen werden und dieses dann an die Datenbank übergeben wird. Dort findet eine Überprüfung der geforderten Abhängigkeiten statt und fehlende oder fehlerhafte Daten werden nachgefordert. Erst wenn alle einzugebenden oder zu ändernden Daten fehlerfrei und den vorgegebenen Regeln entsprechen, werden die Daten in die Datenbank eingefügt. Jede Adresse gehört zu genau einem Studenten: Wenn mehrere Studenten zufällig die gleiche Adresse haben, wird für jeden Studenten der gleiche Eintrag gespeichert. Die Datenbank hat dafür zu sorgen, dass keine herrenlosen Adressen in der Datenbank vorhanden sind. Sie hat dafür zu sorgen, dass mit jedem gelöschten Studneteneintrag alle dazugehörenden Adressen gelöscht werden, oder dass ein Studenteneintrag solange nicht gelöscht werden darf, wie mindestens eine Adresse zu diesem Eintrag vorhanden ist. Nach dieser Definition kann eine Adresse nicht zu mehreren Studenten gehören. Wenn mehrere Studenten zusammenwohnen, wird für jeden Studenten seine Adresse getrennt gespeichert.

Konditionelle Beziehung Stile Stilrichtung Werk Werk Nr Autor Jahr Ort Schlagwort hat eine (0,n) (1,1) Zu einem Stil gibt es 0 bis n Werke Jedes Werk ist genau einem Stil zuzuordnen In Zusammenarbeit mit dem Fachbereich Design wird ein digitales Bildarchiv entwickelt. Dieses Archiv enthält Dias von Werken, die Architekten und Künstler an Bauhaus geschaffen haben. Jedes Werk enthält verschiedene Attribute. Es kann mit Hilfe dieser Attribute definiert werden und durch eine geeignete Abfrage können alle dazugehörenden Dias aus der Datenbank herausgezogen werden. In disem Beispiel wird ein Werk genau einer Stilrichtung zugeordnet. Es ist also nicht möglich, ein Werk ohne eine Stilrichtung in die Datenbank einzufügen. Zu einer Stilrichtung kann es kein oder mehrere Werke geben. Es ist also möglich, Stilrichtungen zu definieren, zu denen kein Werk vorhanden ist.

1-1 Beziehung Bildarchiv Bild Nr Daumennagel Mittelformat Großformat Bild Werk Nr Beschrei-bung Hat versch. Größen (1,1) Zu jedem Bild gibt es genau eine Abbildung in jeder Kategorie Die Attribute zu den einzelnen Bildern und die Bilder werden in getrennten Entities beschrieben. Zu jeder Bildbeschreibung gibt es genau einen Eintrag in einem Bildarchiv, das ein Bild in unterschiedlichen Auflösungen enthält. Physikalisch werden diese Informationen auch getrennt abgelegt: Die Beschreibung der Bilder wird in einer Datenbank gespeichert. Die Bilder werden in einem Filesystem gespeichert. Entscheidend für diese Trennung ist einerseits die Größe der Bilder (Pro Dia 3 Darstellungen mit zusammen ca. 5 MB Speicherbedarf) und andererseits das Verfahren der Datensicherung. Die Bilder brauchen nur einmal gesichert zu werden. Die Datenbank muss regelmäßig gesichert werden, da sie einem permanenten Wandel unterworfen ist.

n-m Beziehung Ein Werk kann in 0 bis m Literaturstellen zitiert werden Quellen Nr Autor Text Werk Werk Nr Jahr Stilrichtung Ort Schlagwort Wird zitiert (0,n) (0,m) Ein Werk kann in 0 bis m Literaturstellen zitiert werden Eine Literaturstelle kann 0 bis n Werke beschreiben Ein Werk kann in 0 bis m Literaturstellen zitiert werden. Eine Literaturstelle kann 0 bis n Werke beschreiben. Es ist also möglich, sowohl Literaturstellen als auch Werke ohne Beziehungen zueinander zu speichern. Eine Literaturstelle kann eine Bezeihung zu einem Autor mehrerer Werke oder zu einer Stilrichtung haben. Da das Entity “Literatur” zu keinem anderen Entity eine obligatorische Beziehung hat, ist es möglich, dass eine Literaturstelle gespeichert wird, die zu keinem anderen Objekt eine Beziehung hat.

Aufgelöste n-m Beziehung Literatur Quellen Nr Autor Text Werk Werk Nr Jahr Stilrichtung Ort Schlagwort Wird zitiert (1,n) (1,m) Werkzitat (1,1) Die Zusatztabelle enthält die Schlüssel beider in Beziehung stehender Tabellen und Attribute, die diese Beziehung beschreiben. Ein weiteres Beispiel einer n - m Beziehung ist die Buchausleihe in einer Bücherei. Bücher und Kunden sind unabhängige Entitäten die durch das Ausleihen eines Buches durch einen Kunden zeitweise zusammengeführt werden. Die Beziehungsrelation wird durch die Dauer der Ausleihe ergänzt. Diese Beziehung wird in der Praxis durch eine Zusatztabelle realisiert

rekursive Beziehungen Stückliste Bauteil besteht_aus Menge 0,N Ein Bauteil kann aus einzelnen Bauteilen bestehen Eine rekursive Abfrage nach allen Einzelteilen ist mit SQL nicht möglich Rekursive Beziehungen können durch ERD‘s zwar dargestellt werden, durch die Abfragesprache SQL aber nicht bearbeitet werden. Stücklisten sind häufig benutzte Konstruktionen, deren Abfrage abhängig von der Anwendung durch spezielle Verfahren ermöglicht werden. Je nach Fertigungstiefe können beliebig zusammengesetzte Bauteile wieder Grundstoff für weitere Bauteile sein.

Stückliste Die Abfrage, wieviel Zucker der „Kalte Hund“ enthält wird von der Datenbank mit einer einfachen SQL-Abfrage falsch beantwortet. Select sum(Menge) from stückliste where bauteil = ‚Kalter Hund‘ and besteht_aus = ‚Zucker‘ ergibt als Antwort 0;

ERD Beispiel Werkkatalog Stile Werk Bild Literatur wird zitiert hat eine Stilrichtung wird abgebildet (1,1) (0,n) (1,n) (1,m) (0,m) Eine Entität kann Bezeihungen zu mehreren Entitäten haben.

ERD Beispiel Kardinalität Heirats urkunde Personen register heiratet ist Trauzeuge (2,2) (0,1) (0,2) (0,n) Zwischen zwei Entitäten können mehrere Beziehungen bestehen. In einer Heiratsurkunde wird die Heirat von genau zwei Personen beurkundet. Die Heirat wird von null bis zwei Trauzeugen beurkundet. Eine Person kann (gleichzeitig) in höchstens einer Heiratsurkunde erwähnt werden. Eine Person kann beliebig oft Trauzeuge sein.

ERD Beispiel Kardinalität Heirats urkunde Personen über 18 Zeremonie benötigt (2,2) (1,1) Heirats- willige Eine Beziehung kann mehr als zwei Entitäten verbinden.

ERD Beispiel - Silverrun

ERD Zusammenfassung Phasen der SW-Wntwicklung Darstellung von ERD Beziehungen Hierarchisch Konditionell 1-1 n-m Grenzen Beispiele