Entity - Relationship Diagramme

Slides:



Advertisements
Ähnliche Präsentationen
Eine Frage der Sichtweise
Advertisements

ER-Modell: Objekte und Klassen
ER-Datenmodell und Abfragen in SQL
Zur Rolle der Sprache bei der Modellierung von Datenbanken
Kardinalität von binären Beziehungen (1)
Datenmodellierung Externe Phase Informationsstruktur
Datenbanksysteme für FÜ SS 2000 Seite Worzyk FH Anhalt SQL 1 Aussagen über Tabelleninhalte Aussagelogik Äquivalenzen Select Where.
Datenbanksysteme für FÜ WS2004/05 SQL1 - 1 Worzyk FH Anhalt SQL 1 Aussagen über Tabelleninhalte Aussagelogik Äquivalenzen Select Where.
Extensible Markup Language
Worzyk FH Anhalt Datenbanksysteme für FÜ WS 2004/2005 XML - 1 XML Extensible Markup Language.
HyperText Markup Language
Entity-Relationship-Ansatz
Ein Entity Relationship Diagramm zur ADB/NDB
Das Entity-Relationship-Modell
Themenschwerpunkte Übung 3:
Gliederung der Vorlesung Software Engineering WS 2001/2002
Datenbankentwurf mit Hilfe des ER-Modells entwickeln
Entity-Relationship (ER)-Modell
Relationaler Datenbankentwurf (I)
Übung Datenbanksysteme WS 2002/ Übung Datenbanksysteme ER-Modellierung
Normalformen Normalisieren Schlüssel
Datenbanksysteme für FÜ WS 2004/2005 Transaktionen 1 Worzyk FH Anhalt Transaktionen und Parallelverarbeitung Eigenschaften von Transaktionen Konsistenz.
SQL 2 Order by null Aggregatfunktionen group by Join subselect.
Datenintegrität Referentielle Integrität create table
Reviews Definition Ziele Teilnehmer Ablauf Ergebnisse.
6 Normalformen Normalisieren Schlüssel
Einführung Dateisystem <-> Datenbanksystem
Entity - Relationship Diagramme
Willkommen zum DBS I – Praktikum!
Datenmodellierung - Aufbau einer Datenbank -
Kapitel 2: Konzeptuelle Modellierung
Fachbereich Mathematik/Informatik Universität Osnabrück
Beziehungen und Beziehungstypen (1)
7.3 Hinweise für den Aufbau von ER-Schemata (1|7)
Datenmodellierung mit XCASE
Wo liegt die Grenze zwischen Zitat und Plagiat?
Visualisierung objektrelationaler Datenbanken
Einführung Access Einführung und Datenbankgrundbegriffe
Semantisches Datenmodell Entity-Relationship-Modell Normalformen
WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #3 Das relationale Modell (Teil 2)
7.3.1 Ein Modellierungsbeispiel (1|9)
DI (FH) DI Roland J. Graf MSc (GIS) U N I V E R S I T Ä T S L E H R G A N G Geographical Information Science & Systems UNIGIS.
Paradigmenwechsel in der Unternehmensmodellierung Prof. Dr. Wolfgang Voigt Dipl.-Ing. Päd. Alexander Huwaldt UML Extrakt UML Seminar, Chemnitz
7.1.9 Kardinalität von Beziehungen (1|15)
Datenbanksysteme für Hörer anderer Fachrichtungen
Ihr Trainer: Gerold Hämmerle
verstehen planen bearbeiten
Relationale Datenbanken
ADAT©2004 Dipl. - Ing. Walter SabinSeite: 19 Version 1.0a Programme - Zusatzsoftware Oracle: –Forms –Reports –Designer –Jdeveloper –APEX (Application Express)
Software Engineering Grundlagen
Datenbanken und Informationssysteme
Stundenplanung Programm zur Stunden- und Zimmerplanung auf der Basis von Datenbanken und unter Berücksichtigung von Mehrfachnutzung im (lokalen) Netz (Internet.
Software Engineering Strukturierte Analyse
7.1.9 Kardinalität von Beziehungen (12|15)
Einführung Dateisystem <-> Datenbanksystem
8.4.3 Übertragung von Beziehungstypen (1|12)
Erweiterung bzgl. der Kardinalität. (1|9)
Zitat-management-System Meilenstein 1
ER-Modell Beziehungen und Beziehungstypen (1|5) Beziehung (relationship) (b): Zwei oder mehr Objekte können miteinander in Beziehung.
Datenbanken Datenbank-Entwurf
1 1.Man beginne mit „leicht erkennbaren natürlichen Objekten“ (Personen und konkreten Gegenständen) und fasse diese zu Objekttypen zusammen. (etwa Substantive.
Entität Attribute Beziehung AUTOR CD M 1 N leihen erstellen N verfasst
Vom Konzept zur Datenbank
CD BÜCHER FREUNDE INTERPRETAUTOR Entität Attribute Beziehung Preis TitelCd# Musikricht- ung von bis Handy PLZ Ort Straße Gdatum Vorname Nachname.
Übungsblatt 3 Erläuterungen Wintersemester 15/16 DBIS.
Was ist ein Datenbankprogramm?
IS: Datenbanken, © Till Hänisch 2000 Entwicklung von Datenbankapplikationen Vorgehensmodell.
ER-Modell und Relationales Schema
Informatik 9 – 2.Datenbanken – 2.5 Datenbankentwurf
Titel Zeile 1 Zeile 2 Zeile 3
 Präsentation transkript:

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 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%

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

Es ist möglich, n-m Beziehungen anzugeben Es ist möglich, n-m Beziehungen anzugeben. Diese werden dann durch eine zusätzliche Tabelle aufgelöst.

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