Semantische Datenmodellierung Teil 2: Extended Entity Relationship Modell. Hans-Georg Hopf

Größe: px
Ab Seite anzeigen:

Download "Semantische Datenmodellierung Teil 2: Extended Entity Relationship Modell. Hans-Georg Hopf"

Transkript

1 Semantische Datenmodellierung Teil 2: Extended Entity Relationship Modell Hans-Georg Hopf 26. März 2004

2 Inhaltsverzeichnis 1 EER-Modell Objektklassen Beziehungen Beziehungsobjektklassen Grad einer Beziehung Rolle Kardinalität Objektbeteiligung Kardinalitätskonzept Namensgebung Schwache Objektklasse Gerund Objekthierarchien Darstellungshilfen Attribute Restriktionen Kategorisierung Gruppierung Übersicht Übungen Was Sie nach der Bearbeitung dieses Teils kennen und können sollten: Sie erfahren, welche Modellierungskonstrukte die Extended Entity Relationship Modellierungssprache zur Verfügung stellt. 1

3 Kapitel 1 Entity-Relationship-Modell Mit Hilfe von Relationen formulierte Datenmodelle haben einige gravierende Nachteile: Es stellt sich die Frage: Wann ist ein relationales Datenmodell (Relationenmodell) ein gutes Datenmodell? bzw. Was zeichnet ein gutes Datenmodell aus? Die einzelnen Relationen sind häufig in ihrer Struktur mit Mängeln behaftet. Diese Mängel machen sich, wie wir im Kapitel?? gesehen haben, allerdings oft erst im operationellen Umgang mit den Tabellen bemerkbar und drücken sich durch sogenannte Update-, Insert- und Delete-Anomalien aus. Ein vergleichsweise aufwendiges mathematisches Verfahren, die sog. Normalisierung, muss eingesetzt werden, um die in der Datenstruktur vorhandenen strukturellen Mängel aufzudecken und zu beseitigen. Die in einem Modell formulierten Relationen bzw. Tabellen sind üblicherweise nicht voneinander unabhängig. Über Fremdschlüssel sind Relationen untereinander verbunden. Fremdschlüssel vermittel jedoch Beziehungen verschiedenster Art und Ausprägung. Die Darstellung dieser relationsübergreifenden Beziehungen wird durch im Relationenmodell nur unzureichend unterstützt. Die Bedeutung der Beziehungen bleibt unberücksichtigt. Ein wesentlicher Teil der Aussagekraft eines Datenmodells wird gerade durch Beziehungen zwischen den Objektklassen bestimmt. Die unzureichende Darstellung dieser Objektbeziehungen ist damit ein echter Mangel des Relationenmodells. Ein semantisches Datenmodell soll die oben beschriebenen Nachteile beheben. Ein sehr erfolgreich eingesetztes semantisches Datenmodell ist das Entity- Relationship (ER) - Modell. Es gibt verschiedene Varianten dieses ursprünglich von Chen [CHE 76 ] eingeführten graphischen Modellierungsverfahrens. Sie unterscheiden sich nicht nur in der Ausgestaltung der verwendeten graphischen Symbole, sondern auch im ausdrückbaren Informationsgehalt. 2

4 1.1. OBJEKTKLASSEN KAPITEL 1. EER-MODELL Ein bezüglich der Repräsentation von Semantik besonders aussagekräftiges und in seiner graphischen Darstellung sehr übersichtliches Modell ist das Extended-Entity-Relationship (EER) - Modell von Teory, Yang und Fry (siehe [TEO 86, TEO 90 ]). Dieses Modell, erweitert um einige in der praktischen Modellierung sehr nützliche Konstrukte, soll hier vorgestellt werden. Grundelemente des EER-Modells, die im folgenden detailliert erläutert werden, sind: (eigenständige) Objektklassen (entity-sets) Beziehungsobjektklassen (relationship-sets) schwache Objektklassen (weak entity-sets) Gerund (view aggregation) Generalisation (generalization) Objektkategorien (category) 1.1 Objektklassen (entity-sets) Als erstes wenden wir uns der Beschreibung von sogenannten eigenständigen Objektklassen zu. Ein Datenmodellobjekt (entity) beschreibt eine eigenständige reale oder erdachte Einheit, der realen Welt oder abstrakten Gedankenwelt, über die Informationen zusammengetragen werden sollen. Eigenständige Objekte können ohne Rückgriff auf andere Objekte eindeutig identifiziert und näher beschrieben werden. Diese Identifikation und Beschreibung von Objekten geschieht durch Attribute und die ihnen zugeordneten Attributwerte. Objekte mit gleichen Attributen (aber üblicherweise verschiedenen Attributwerten) können zu Objektklassen (entity sets) zusammengefaßt werden. Relationen (Tabellen) sind z.b. Repräsentanten solcher Objektklassen. Jedes Tupel (Zeile) einer Relation (Tabelle) entspricht einem Objekt (entity). Für viele Überlegungen reicht es jedoch, die Struktur einer Objektklasse zu erfassen, ohne auf einzelne Objekte im Detail einzugehen. Das bedeutet, dass für eine Objektklasse die Attributstruktur erfaßt wird, die einzelnen Objekte mit ihren Attributwerten jedoch keine Rolle spielen. Dem trägt das EER- Modell Rechnung durch ein Konstrukt, das als Objektklasse oder Entity-Set bezeichnet wird (siehe Abbildung 1.1). In der Abbildung 1.1 ist eine mathematische Darstellung angegeben, wie wir sie zur Definition von Relationen benutzt haben. Daneben findet sich die EER- Darstellung einer Objektklasse. Beide Darstellungen beschränken sich auf die Angabe der Attributstruktur. Im Gegensatz dazu gibt die tabellarische Darstellung der Objektklasse die einzelnen Objekte (Entities) mit den zugehörigen Attributwerten an. Zusammenfassend läßt sich bezüglich der EER-Darstellung einer Objektklasse feststellen: Version 1.0 / 26. März c H.-G. Hopf

5 Alle Objekte (Entities) eines Typs sind als Menge zusammengefaßt in dieser Objektklasse (dem Entity-Set), zu finden. Das Datenmodell-Konstrukt beschreibt nur den Typ der Objekte einer Objektklasse, durch die Angabe der Attribute, nicht jedoch die Ausprägung einzelner, individueller Objekte mit ihren Attributwerten (Entities). In graphischer Notation benutzt man folgende Darstellungsformen: Die Objektklasse wird durch Angabe des Objektklassennamens und aller relevanten Attribute näher beschrieben. Der Objektklassennamen wird in ein Rechteck eingetragen. Die Attribute werden durch Verbindungslinien dem Rechteck zugeordnet. Attribute, die den Primärschlüssel bilden, werden im Unterschied zu den restlichen Attributen durch Unterstreichen besonders gekennzeichnet. Vergröbert man die Granularität in der Darstellung, kann auch noch auf die detaillierte Angabe der Objektstruktur verzichtet werden. Es genügt für viele Zwecke anzudeuten, dass die betrachteten Objekte gleichartig sind, ohne auf die Attributstruktur näher einzugehen. In diesem Fall reduziert sich die graphische Darstellung zu einem einfachen Rechteck, das den Objektklassennamen enthält. Es hat sich eingebürgert den Objektklassennamen als Substantiv anzugeben und jeweils im Singular zu verwenden. Werden, wie im Beispiel (siehe Abbildung 1.1), Angestellte durch die Objektklasse repräsentiert, ist der Objektklassenname Angestellter. 1.2 Beziehungen Wie eingangs erläutert ist der Verlust von Information über Beziehungen zwischen einzelnen Objektklassen ein großer Nachteil des traditionellen relationalen Modells. Dieser Abschnitt soll deutlich machen, wie im EER-Modell die Darstellung verschiedener Beziehungen zwischen Objektklassen gelöst ist Beziehungs - Objektklassen (relationship sets) Die erste Art einer Beziehung zwischen Objektklassen soll am Beispiel erläutert werden. Angestellte einer Firma arbeiten an verschiedenen Projekten. Der Prozentsatz der Mitarbeit eines Angestellten an einem Projekt ist jeweils festgelegt. Version 1.0 / 26. März c H.-G. Hopf

6 Abbildung 1.1: Verschiedene Darstellungen der Objektklasse Angestellter : mathematische Darstellung, Tabellendarstellung, EER-Darstellung Version 1.0 / 26. März c H.-G. Hopf

7 Diese einfache Situation soll in einem Datenmodell beschrieben werden. Als eigenständige Objektklassen erkennt man sofort die Objektklasse Angestellter und die Objektklasse Projekt. Die Attribute der Objektklasse Angestellter sind vom obigen Beispiel übernommen (siehe Abbildung 1.1). Für die Objektklasse Projekt wird neben der Projektnummer zur Identifikation des Projekts noch Projektname und Kostenstelle als Attribut angegeben. Eine beispielhafte Tabellendarstellung ist für die Objektklasse Angestellter in Tabelle 1.1 und für die Objektklasse Projekt in Tabelle 1.2 angegeben. Personal- Vorname Nachname Abteilung nummer 101 Fritz Meier Hans Müller Uli Adam Susi Otto Gaby Müller 2 Tabelle 1.1: Tabellendarstellung der Objektklasse Angestellter Projekt- Projektname Kostenstelle nummer 1 SST ASAB MTA 6900 Tabelle 1.2: Tabellendarstellung der Objektklasse Projekt In keiner der beiden Objektklassen jedoch gelingt es durch Ergänzung der vorhandenen Attribute die Projektmitarbeit ohne Schwierigkeiten unterzubringen. Besonders deutlich treten diese Schwierigkeiten zu Tage, wenn man sich die Situation mittels der Tabellendarstellung einer derart modifizierten Objektklassen (siehe Tabelle 1.3) veranschaulicht. Personal- Vorname Nachname Abteilung Projekt- Projektnummer nummer mitarbeit 101 Fritz Meier Hans Müller 1 1, 2 50, Uli Adam Susi Otto 2 2, 3 10, Gaby Müller Tabelle 1.3: Tabelle für die modifizierte Objektklasse Angestellter Das Hinzunehmen der Projektinformation (Projektnummer, Prozentsatz der Projektmitarbeit) in der Objektklasse Angestellter bringt offenkundig Probleme mit sich: Wir betrachten auch in der modifizierten Objektklasse Objekte vom Typ Angestellter. Damit darf sich auch an der Identifikation von Objekten der Objektklasse durch die neu hinzugenommenen Attribute nichts Version 1.0 / 26. März c H.-G. Hopf

8 ändern. Behält man also den Schlüssel Personalnummer bei, treten nicht atomare Attributwerte auf: Für den Angestellten Hans Müller müssen unter dem Attribut Projektnummer zwei Projektnummern (1, 2) und für das Attribut Projektmitarbeit zwei Prozentsätze (50 %, 40 %) aufgeführt werden. Der Zusammenhang zwischen Projekt und Projektmitarbeit geht verloren. Für den Angestellten Hans Müller ist nicht mehr zu entscheiden, in welchem der beiden Projekte 1 oder 2 er mit 40 % bzw. 50 % seiner Arbeitszeit mitarbeitet. Eine andere Lösung ist, die Objektklassen Angestellter und Projekt in ihrer ursprünglichen Form zu belassen und Informationen über die Projektmitarbeit in einer eigenen Tabelle abzulegen (siehe Tabelle 1.4). Personal- Projekt- Prozentnummer nummer satz Tabelle 1.4: Tabelle Projektmitarbeit Diese Aufteilung in verschiedene Tabellen kann man auch schon auf konzeptioneller Ebene ausdrücken: Der Aspekt Projektmitarbeit stellt eine Beziehung zwischen den Objektklassen Angestellter und Projekt her. Diese Beziehung drückt sich in einer eigenen Tabelle Projektmitarbeit aus. Nun könnte man Tabellen, die Beziehungen repräsentieren, auf konzeptioneller Ebene als Objektklasse ansehen. Im Unterschied zu den im Abschnitt 1.1 definierten Objekten sind Objekte dieser Objektklasse aber nicht eigenständig, sondern hängen von den Objekten der die Beziehung begründenden Objektklassen ab. Es ist dementsprechend nur folgerichtig, zur Darstellung auf konzeptioneller Ebene die Beziehungsinformation durch ein eigenes Symbol zwischen den in Beziehung gesetzten Objektklassen auszudrücken. Im Beispiel (siehe Abbildung 1.2) hängt die Beziehungsobjektklasse, der man den Namen arbeitet an geben kann, in ihrer Existenz von Objekten aus den Objektklassen Angestellter und Projekt ab. In der Tabellendarstellung zeigt sich diese Abhängigkeit durch den zusammengesetzten Tabellenschlüssel (Personalnummer, Projektnummer), der aus den Schlüsselattributen der Tabellen Angestellter und Projekt besteht. In der Abbildung 1.2 ist diese Beziehungsobjektklasse arbeitet an zwischen den Objektklassen Angestellter und Projekt als Raute ausgeführt. In der Abbildung 1.2 ist neben der EER- Darstellung und der tabellarischen Darstellung wieder eine mathematische Version 1.0 / 26. März c H.-G. Hopf

9 Darstellung aufgeführt, wie wir sie zur Definition von Relationen benutzt haben. An das Beziehungssymbol kann weitere Information (im Beispiel Prozentsatz ) in Form von beschreibenden Attributen angeheftet werden. Das explizite Ausweisen von identifizierenden Attributen (im Beispiel Personalnummer, Projektnummer ) erübrigt sich jedoch: Durch die Angabe der in Beziehung tretenden Objektklassen ergibt sich ein zusammengesetzter Identifikator aus den identifizierenden Attributen der Ausgangsobjektklassen (im Beispiel Angestellter, Projekt ). Version 1.0 / 26. März c H.-G. Hopf

10 Abbildung 1.2: Darstellungen für Beziehungsobjektklassen: mathematische Darstellung, Tabellendarstellung, EER-Darstellung (relationship) Version 1.0 / 26. März c H.-G. Hopf

11 Eine Beziehung zwischen Objektklassen kann noch sehr viel differenzierter ausformuliert werden. Beziehungen zwischen Objektklassen können näher beschrieben werden durch Angaben über: den Grad einer Beziehung (degree) die Rolle der beziehungsbeteiligten Objektklassen (role) den Typ der Beziehung (connectivity) die Art der Beteiligung von Objekten an der Beziehung (membership class) Grad einer Beziehung (degree) Der Grad einer Beziehung (siehe Abbildung 1.3) legt fest, wie viele bzw. wie oft Objektklassen an einer Beziehungsobjektklasse (Entity-Relationship-Set) beteiligt sind. Man unterscheidet: zweifache Beziehungen (binary relationships): Die Beziehung wird zwischen Objekten von zwei Objektklassen definiert. dreifache Beziehungen (ternary relationships): Die Beziehung wird zwischen Objekten von drei Objektklassen definiert. n - fache Beziehungen (n - ary relationships): Die Beziehung wird zwischen Objekten von n Objektklassen definiert. Die Objektklassen, die eine Beziehung definieren, müssen nicht notwendigerweise verschieden sein 1. Eine binäre Beziehung mit gleichen Ausgangsentities wird in der Literatur auch als rekursive Beziehung (recursive relationship) bezeichnet Rolle (role) Die Rolle gibt die Funktion an, die eine Objektklasse in einer Beziehungsobjektklasse spielt. Diese Funktion ist oft schon den Objektklassennamen oder dem Beziehungsklassennamen zu entnehmen. Beispielsweise verbindet die Beziehung gehört zu die Objektklassen Angestellter und Abteilung (siehe Abbildung 1.4). Die Rolle, die die Objektklasse Angestellter in der Beziehung gehört zu spielt ist offenkundig, die Rollenbezeichnung ist aus den Objektklassennamen ableitbar und muss dementsprechend nicht gesondert vermerkt werden. 1 In der Literatur (z.b. [TEO 86, TEO 90 ]) findet man häufig den Begriff einfache Beziehung (unary relationship). Unter einer einfachen Beziehung wird verstanden, dass die Beziehung zwischen Objekten der gleichen Objektklasse definiert wird. Dies ist jedoch ein Spezialfall einer binären Beziehung mit nicht verschiedenen Ausgangsobjektklassen. Insofern ist der Begriff einfache Beziehung entbehrlich. Version 1.0 / 26. März c H.-G. Hopf

12 Abbildung 1.3: Grad einer Beziehung Abbildung 1.4: Beispiele für eine implizite bzw. explizite Rollenkennzeichnung Version 1.0 / 26. März c H.-G. Hopf

13 In anderen Fällen muss die Rolle jedoch explizit angegeben werden, um die Beziehung in ihrer Bedeutung zu charakterisieren. Insbesondere für mehrfach an einer Beziehung beteiligte Objektklassen muss die Bedeutung der einzelnen Beteiligungen durch die Rollenbezeichnung unterschieden werden. In der 2-fach-Beziehung ist verheiratet mit, die die Objektklasse Person mit sich selbst verbindet, ist die Rollenkennzeichnung Ehemann bzw. Ehefrau zum Verständnis wichtig. In der Beziehung ist Vorgesetzter von, die die Objektklasse Angestellter mit sich selbst verbindet, muss die Rolle Vorgesetzter deutlich gemacht werden, ein Rollenname Mitarbeiter ist in diesem Fall entbehrlich. In der 3-fach-Beziehung spielt zwischen den Objektklassen Mannschaft und Saison muss die Charakterisierung Heimmannschaft bzw. Gastmannschaft die Rolle der einzelnen Beteiligung von Mannschaft an der Beziehung spielt verdeutlichen. Die Rolle dient dazu größtmögliche Transparenz in der Beschreibung der Beziehungsobjektklasse zu erreichen. Insofern sollte sie stets explizit angegeben werden. Die Rolle wird auf der Verbindungslinie zwischen Objektklassensymbol und Beziehungsklassensymbol vermerkt. Version 1.0 / 26. März c H.-G. Hopf

14 Kardinalität (cardinality) und Beziehungstyp (connectivity) Die Art, in der Objekte einer Objektklasse sich an einer Beziehung beteiligen, kann unterschiedlich sein. Durch eine Klassifikation dieser Beteiligung sollen Beziehungstypen herausgearbeitet werden. Die Kardinalität (cardinality) gibt für jede Rolle an, wie viele Objekte der aktuell betrachteten Objektklasse oder Rolle in einer Beziehung mit jeweils einem Objekt aller anderen Objektklassen stehen können. Üblicherweise wird für die Kardinalität ein Intervall festgelegt. [minimale Kardinalität, maximale Kardinalität] Eine Beziehung mit Objekten anderer Objektklassen einzugehen erfolgt üblicherweise mit wenigstens einem Objekt; die minimale Kardinalität hat in diesem Fall den Wert 1. Für die obere Grenze der Kardinalität unterscheidet man die Fälle maximale Kardinalität = 1 oder maximale Kardinalität > 1. Ein Wert für die maximale Kardinalität kann im letzteren Fall explizit angegeben werden (z.b. 5) oder über einen Parameter (z.b. n) ganz allgemein formuliert werden. Oft erfolgt die Bezeichnung für die maximale Kardinalität durch die englischen Begriffe one für den Wert 1 oder many für Werte n > 1. Werte kleiner 1 machen für den Maximalwert der Kardinalität keinen Sinn. Die Kardinalität wird im Beziehungsklassensymbol für alle beteiligten Rollen durch ein eigenes Indikatorsymbol graphisch dargestellt. Die Tabelle 1.5 zeigt die verschiedenen, typischen Formulierungen der Kardinalität. Ausgehend von einer minimalen Kardinalität 1 orientiert sich die Darstellung des Indikatorsymbols an der maximalen Kardinalität: die maximale Kardinalität 1 wird durch ein weißes Dreieck dargestellt; die maximale Kardinalität n > 1 wird durch ein schwarzes Dreieck dargestellt. Zur Darstellung des Typs einer Beziehung (connectivity) werden die zuvor für jede Rolle ermittelten Kardinalitäten kombiniert: Im Beziehungsklassensymbol sind die Indikatorsymbole für die Kardinalitätsintervalle für alle Rollen gemäß dem Grad der Beziehung angegeben. Für Zweifach-Beziehungen entsteht durch Kombination der Indikatorsymbole eine Raute. Version 1.0 / 26. März c H.-G. Hopf

15 Abbildung 1.5: Indikatorsymbole für verschiedene Kardinalitätsintervalle Für n-fach-beziehungen wird die Beziehung durch ein Polygon mit n Ecken dargestellt. Jeder Ecke ist eine Objektklasse/Rolle zugeordnet. In jeder Ecke wird ein Dreieck als Indikatorsymbol genutzt. Wir wollen in den folgenden Abschnitten zunächst binäre und dann n-fache Beziehungen näher untersuchen und insbesondere auf die verschiedenen Beziehungstypen eingehen. Binäre Objektbeziehungen Für eine binäre Objektbeziehung kann man folgende Beziehungstypen unterscheiden: 1:1 Beziehung: ein Objekt der einen Objektklasse ist genau einem Objekt der anderen Objektklasse durch die Beziehungsobjektklasse zugeordnet. Ein Beispiel für eine 1:1-Beziehung ist die Beziehung leitet zwischen den Objektklassen Angestellter und Abteilung (siehe Abbildung 1.6). Die beiden (maximalen) Kardinalitäten können wie folgt festgelegt werden: ein Angestellter leitet genau eine Abteilung; die Kardinalität der Objektklasse Abteilung in der Beziehung leitet ist 1 (one); das zugeordnete Dreieckssymbol ist weiß eingefärbt; eine Abteilung hat genau einen Abteilungsleiter; die Kardinalität der Objektklasse Angestellter in der Beziehung leitet ist 1 (one); das zugeordnete Dreieckssymbol ist ebenfalls weiß eingefärbt. 1:n Beziehung: ein Objekt der einen Objektklasse kann mit mehr als einem Objekt der anderen Objektklasse durch die Beziehungsobjektklasse verbunden sein. Als Beispiel für eine 1:n-Beziehung soll die Beziehung gehört zu zwischen den Objektklassen Angestellter und Abteilung dienen (siehe Abbildung 1.7). Version 1.0 / 26. März c H.-G. Hopf

16 Abbildung 1.6: Ermittlung des Beziehungstyps für die Beziehungsobjektklasse leitet zwischen den Objektklassen Angestellter und Abteilung Die beiden (maximalen) Kardinalitäten können wie folgt festgelegt werden: ein Angestellter gehört genau einer Abteilung an; die Kardinalität der Objektklasse Abteilung in der Beziehung gehört zu ist 1 (one); das der Objektklasse Abteilung zugeordnete Dreieckssymbol ist weiß eingefärbt; ein Abteilung besteht in der Regel aus mehr als einem Angestellten; die Kardinalität der Objektklasse Angestellter in der Beziehung gehört zu ist n (many); das der Objektklasse Angestellter zugeordnete Dreieckssymbol ist schwarz eingefärbt. n:m Beziehung: mehrere Objekte beider Objektklassen können sich gegenseitig durch die Beziehungsobjektklasse zugeordnet sein. Als Beispiel für eine n:m-beziehung soll die Beziehung arbeitet an zwischen den Objektklassen Angestellter und Projekt dienen. Die beiden (maximalen) Kardinalitäten können wie folgt festgelegt werden: ein Angestellter arbeitet an mehreren Projekten; die Kardinalität der Objektklasse Projekt in der Beziehung arbeitet an ist n (many); das der Objektklasse Projekt zugeordnete Dreieckssymbol ist schwarz eingefärbt; Version 1.0 / 26. März c H.-G. Hopf

17 Abbildung 1.7: Ermittlung des Beziehungstyps für die Beziehungsobjektklasse gehört zu zwischen den Objektklassen Angestellter und Abteilung ein Projekt wird von mehreren Angestellten abgewickelt; die Kardinalität der Objektklasse Angestellter in der Beziehung arbeitet an ist n (many); das der Objektklasse Angestellter zugeordnete Dreieckssymbol ist schwarz eingefärbt. Allgemeine n-fache Objektbeziehungen Für den allgemeinen Fall n-facher Beziehungsobjektklassen wird der Beziehungstyp wie folgt ermittelt: Man beantwortet für jede an der Beziehung beteiligte Objektklasse bzw. Rolle die Frage, mit wie vielen Objekten ein Beziehungstupel typischerweise angegeben werden kann, wenn von allen anderen Objektklassen/Rollen jeweils ein Objekt im Beziehungstupel festgelegt ist. Kann nur ein einziges Objekt mit den festgelegten (n-1) anderen Objekten ein gültiges Beziehungsobjekttupel bilden, so ist die maximale Kardinalität für diese Rolle 1. In der graphischen Darstellung wird im Relationssymbol das der betrachteten Objektklasse bzw. Rolle zugewandte Dreieck weiß dargestellt. Können mehrere Objekte mit den festgelegten anderen (n-1) Objekten zu gültigen Beziehungsobjekttupel kombiniert werden, ist der Maximalwert der Kardinalität für diese Rolle n (n > 1). In der graphischen Darstellung wird im Relationssymbol das der betrachteten Objektklasse/Rolle zugewandte Dreieck schwarz dargestellt. Version 1.0 / 26. März c H.-G. Hopf

18 Abbildung 1.8: Ermittlung des Beziehungstyps für die Beziehungsobjektklasse arbeitet an zwischen den Objektklassen Angestellter und Projekt Diese Überlegung wird für jede an der Objektklassenbeziehung beteiligte Objektklasse bzw. Rolle durchgeführt. Damit werden alle Dreiecke des Beziehungssymbols in ihrer Ausprägung (schwarz oder weiß) festgelegt, d.h. die maximalen Kardinalitäten aller Objektklassen/Rollen definiert. Die Abbildung 1.9 veranschaulicht das beschriebene Verfahren. Ein Beispiel soll zur Verdeutlichung dienen: Mannschaften spielen in der Bundesliga. Die Paarungen sollen für jede Saison abgespeichert werden. Betrachtet wird die 3-fach-Beziehung spielt zwischen den Objektklassen Mannschaft und Saison (siehe Abbildung 1.10). Die beiden Spiel-Mannschaften werden in der Beziehungsobjektklasse spielt durch die Rollen Heimmannschaft und Gastmannschaft unterschieden. Die maximalen Kardinalitäten der 3-fach-Beziehung können wie folgt festgelegt werden: Eine Paarung von Heimmannschaft und Gastmannschaft kann in mehr als einer Saison zustande kommen; die maximale Kardinalität der Objektklasse Saison in der Beziehung spielt ist n (many); das der Objektklasse Saison zugeordnete Dreieckssymbol ist schwarz eingefärbt. Eine Heimmannschaft spielt in einer Saison gegen mehrere Gastmannschaften; die maximale Kardinalität der Rolle Gastmannschaft der Objektklasse Mannschaft in der Beziehung spielt ist n (many); das der Objektklasse Mannschaft in der Rolle Gastmannschaft zugeordnete Dreieckssymbol ist schwarz eingefärbt. Version 1.0 / 26. März c H.-G. Hopf

19 Abbildung 1.9: Bestimmung der Kardinalität einer Objektklasse bzw. Rolle in einer n- fach Beziehung Version 1.0 / 26. März c H.-G. Hopf

20 Abbildung 1.10: Ermittlung des Beziehungstyps für die 3-fach- Beziehungsobjektklasse spielt zwischen den Objektklassen Mannschaft und Saison Völlig analog gilt: eine Gastmannschaft spielt in einer Saison gegen mehrere Heimmannschaften; die maximale Kardinalität der Rolle Heimmannschaft der Objektklasse Mannschaft in der Beziehung spielt ist n (many); das der Objektklasse Mannschaft in der Rolle Heimmannschaft zugeordnete Dreieckssymbol ist schwarz eingefärbt. Version 1.0 / 26. März c H.-G. Hopf

21 Art der Objektbeteiligung (membership class) Die Art der Objektbeteiligung an einer Beziehung macht rollenspezifisch eine Aussage über die Existenz von Objekten der Ausgangsobjektklassen/-Rollen im Kontext der Beziehung. Eine Beziehung ist für eine Rolle: verbindlich (mandatory): wenn für jede Objektkombination aller anderen Rollen ein zuzuordnendes Objekt der aktuellen Rolle existiert. wahlfrei (optional): wenn nicht sichergestellt ist, dass bei Vorgabe von jeweils einem Objekt aller anderen Rollen ein Objekt der betrachteten Rolle zugeordnet werden kann. Damit wird eine Aussage über die Formulierbarkeit bzw. Existenz von Objekten der Beziehungsobjektklasse gemacht. Eine optionale Objektbeteiligung wird durch ein Kreissymbol auf der, der Objektklasse/Rolle zugewandten Seite des Relationssymbols vermerkt. Die Optionalität soll an einigen einfachen Beispielen erläutert werden. Zuerst werden Beispiele binärer Beziehungen betrachtet: Betrachtet wird die Beziehung hat zwischen den Objektklassen Person und Paß (siehe Abbildung 1.11). Die beiden maximalen Kardinalitäten der binären Beziehung können wie folgt festgelegt werden: eine Person kann mehrere Pässe besitzen; die Kardinalität der Objektklasse Paß in der Beziehung hat ist n (many); das der Objektklasse Paß zugeordnete Dreieckssymbol ist schwarz eingefärbt; ein Paß kann nur einer Person zugeordnet sein; die Kardinalität der Objektklasse Person in der Beziehung hat ist 1 (one); das der Objektklasse Person zugeordnete Dreieckssymbol ist weiß eingefärbt. Nun soll die Art der Objektbeteiligung festgelegt werden: eine Person muss keinen Paß besitzen; d.h. nicht zu jeder Person muss ein Objekt der Objektklasse Paß existieren; die Beziehung hat ist bezüglich der Objektklasse Paß optional; das der Objektklasse Paß zugeordnete Dreieckssymbol ist durch das Optionalitätensymbol gekennzeichnet; ein Paß kann nur einer existierenden Person zugeordnet sein; jedem Paß ist damit eine Person zugeordnet, d.h. zu jedem Paß muss ein Objekt der Objektklasse Person existieren; die Beziehung hat ist bezüglich der Objektklasse Person verbindlich; das der Objektklasse Person zugeordnete Dreieckssymbol wird nicht weiter gekennzeichnet. Version 1.0 / 26. März c H.-G. Hopf

22 Auch für n-fach Beziehungen kann die Optionalität auf prinzipiell gleiche Weise festgelegt werden. Mannschaften spielen in einem Fußball-Turnier nach dem Prinzip jeder gegen jeden in verschiedenen Stadien. Betrachtet wird die 3-fach-Beziehung spielt zwischen den Objektklassen Mannschaft und Stadion (siehe Abbildung 1.12). Die beiden Spiel- Mannschaften werden in der Beziehungsobjektklasse spielt durch die Rollen Mannschaft A und Mannschaft B unterschieden. Die maximalen Kardinalitäten der 3-fach-Beziehung können wie folgt festgelegt werden: eine A-Mannschaft und eine B-Mannschaft tragen ihr Spiel in genau einem Stadion aus. die maximale Kardinalität der Objektklasse Stadion in der Beziehung spielt ist 1 (one); das der Objektklasse Stadion zugeordnete Dreieckssymbol ist weiß eingefärbt; eine A-Mannschaft spielt in einem Stadion im Rahmen des Turniers gegen alle anderen Mannschaften (B-Mannschaften); die maximale Kardinalität der Rolle B-Mannschaft der Objektklasse Mannschaft in der Beziehung spielt ist n (many); das der Objektklasse Mannschaft in der Rolle B-Mannschaft zugeordnete Dreieckssymbol ist schwarz eingefärbt. völlig analog gilt: eine B-Mannschaft spielt in einem Stadion im Rahmen des Turniers gegen alle anderen Mannschaften (A-Mannschaften); die maximale Kardinalität der Rolle A-Mannschaft der Objektklasse Mannschaft in der Beziehung spielt ist n (many); das der Objektklasse Mannschaft in der Rolle A-Mannschaft zugeordnete Dreieckssymbol ist schwarz eingefärbt. Nun soll die Art der Objektbeteiligung festgelegt werden: eine A-Mannschaft und eine B-Mannschaft tragen ihr Spiel in genau einem Stadion aus. Die Zuordnung eines Spielstadions für die Spielpaarung steht außer Frage. Die Objektbeteiligung der Objektklasse Stadion ist verpflichtend. Das der Objektklasse Stadion zugeordnete Dreieckssymbol ist weiter nicht gekennzeichnet. eine A-Mannschaft spielt in einem Stadion im Rahmen des Turniers gegen mehrere B-Mannschaften; eine A-Mannschaft muss jedoch nicht in jedem Stadium gegen eine B-Mannschaft antreten. Die Existenz einer B-Mannschaft für ein Spiel gegen eine A- Mannschaft in einem beliebig gewählten Stadion ist nicht gewährleistet. So spielt beispielsweise Dynamo im Rahmen des Turniers im Waldstadion nie gegen eine andere Mannschaft. Die Objektbeteiligung der Objektklasse Mannschaft in der Rolle B-Mannschaft ist optional. Das der Rolle B-Mannschaft zugeordnete Dreieckssymbol ist mit einem Optionalitätsindikator gekennzeichnet. Version 1.0 / 26. März c H.-G. Hopf

23 völlig analog begründet kann festgestellt werden, dass die Objektbeteiligung der Objektklasse Mannschaft in der Rolle A-Mannschaft optional ist. Das der Rolle A-Mannschaft zugeordnete Dreieckssymbol ist mit einem Optionalitätsindikator gekennzeichnet. Version 1.0 / 26. März c H.-G. Hopf

Kapitel DB:III. III. Konzeptueller Datenbankentwurf

Kapitel DB:III. III. Konzeptueller Datenbankentwurf Kapitel DB:III III. Konzeptueller Datenbankentwurf Einführung in das Entity-Relationship-Modell ER-Konzepte und ihre Semantik Charakterisierung von Beziehungstypen Existenzabhängige Entity-Typen Abstraktionskonzepte

Mehr

ER-Modell. Entity-Relationship-Model

ER-Modell. Entity-Relationship-Model + ER-Modell Entity-Relationship-Model + Was ist ein Modell? Worte/Zitat aus einem Physikbuch: "Modelle sind also Vorstellungshilfen und Wirklichkeitshilfen, nicht die Wirklichkeit selbst." (Metzler Physik).

Mehr

3. Spezielle ER-Modelle und Tabellenableitung. Transformation von ER-Diagrammen in Relationen

3. Spezielle ER-Modelle und Tabellenableitung. Transformation von ER-Diagrammen in Relationen 3. Spezielle ER-Modelle und Tabellenableitung Spezialfälle von ER-Modellen Grundlage, was sind Relationen Transformation von ER-Diagrammen in Relationen 56 Lesebeispiel Access (Realisierungmodell!) 57

Mehr

Fundamentals of Software Engineering 1

Fundamentals of Software Engineering 1 Folie a: Name Fundamentals of Software Engineering 1 Grundlagen der Programmentwurfstechnik 1 Sommersemester 2012 Dr.-Ing. Stefan Werner Fakultät für Ingenieurwissenschaften Folie 1 Inhaltsverzeichnis

Mehr

2. Datenmodellierung mit ERM. Motivation für Datenmodellierung. Begriffsklärung. Kardinalität/Komplexität von Beziehungstypen

2. Datenmodellierung mit ERM. Motivation für Datenmodellierung. Begriffsklärung. Kardinalität/Komplexität von Beziehungstypen 2. Datenmodellierung mit ERM Motivation für Datenmodellierung Begriffsklärung Kardinalität/Komplexität von Beziehungstypen Erweiterungen des E/R-Modells Darstellung von Attributen/Beziehungen als Entitytypen

Mehr

Datenbanken: ER-Modell

Datenbanken: ER-Modell Beispiel: Lastenheft: Für eine Hochschule soll eine Verwaltungssoftware geschrieben werden, die alle relevanten Daten in einem relationalen Datenbanksystem speichert. Zu diesen Daten zählen die Stamm-

Mehr

Inhaltsverzeichnis. 1. Fragestellung

Inhaltsverzeichnis. 1. Fragestellung Inhaltsverzeichnis 1. Fragestellung... 1 2. Herleitung zum Thema... 1 3. Das Entity Relationship Modell (ERM)... 2 4. Praktisches Beispiel zum ERM... 7 5. Anhang...Fehler! Textmarke nicht definiert. 1.

Mehr

Inhalt. 2.1 Datenbankentwurf. 2.2 Relationales Modell. 2.3 Relationale Entwurfstheorie. 2.4 Relationale Algebra. 2.5 Structured Query Language (SQL)

Inhalt. 2.1 Datenbankentwurf. 2.2 Relationales Modell. 2.3 Relationale Entwurfstheorie. 2.4 Relationale Algebra. 2.5 Structured Query Language (SQL) 2. Datenbanken Inhalt 2.1 Datenbankentwurf 2.2 Relationales Modell 2.3 Relationale Entwurfstheorie 2.4 Relationale Algebra 2.5 Structured Query Language (SQL) 2 2.1 Datenbankentwurf Datenbankanwendungen

Mehr

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle 1 Das Entity-Relationship-Modell Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle Prof. Dr.

Mehr

Einführung in das Entity-Relationship-Modell

Einführung in das Entity-Relationship-Modell Einführung in das Entity-Relationship-Modell Historie Entity-Relationship-Modell kurz: ER-Modell bzw. ERM 1976 von Peter Chen vorgeschlagen Standardmodell für frühe Entwurfsphasen in der Datenbankentwicklung

Mehr

4 Grundlagen der Datenbankentwicklung

4 Grundlagen der Datenbankentwicklung 4 Grundlagen der Datenbankentwicklung In diesem Kapitel werden wir die Grundlagen der Konzeption von relationalen Datenbanken beschreiben. Dazu werden Sie die einzelnen Entwicklungsschritte von der Problemanalyse

Mehr

Entwurf von Datenbanken

Entwurf von Datenbanken Bisher: was sind Datenbanken? Wie funktionieren sie? Im Folgenden: wie entwickle ich eine Datenbank? Was ist eine gute Datenbank? Der Datenbankentwurfsprozess Das Entity Relationship (ER) Modell Abbildung

Mehr

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert Maika Büschenfeldt Datenbanken: Skript 1 1. Was ist eine relationale Datenbank? In Datenbanken können umfangreiche Datenbestände strukturiert abgelegt werden. Das Konzept relationaler Datenbanken soll

Mehr

3. Das Relationale Datenmodell

3. Das Relationale Datenmodell 3. Das Relationale Datenmodell Das Relationale Datenmodell geht zurück auf Codd (1970): E. F. Codd: A Relational Model of Data for Large Shared Data Banks. Comm. of the ACM 13(6): 377-387(1970) DBMS wie

Mehr

Einführung in Datenbanken

Einführung in Datenbanken Einführung in Datenbanken Dipl.-Inf. Michael Wilhelm Hochschule Harz FB Automatisierung und Informatik mwilhelm@hs-harz.de aum 2.202 Tel. 03943 / 659 338 1 Inhalt 1. Grundlegende Begriffe der Datenbanktechnologie

Mehr

IT-Kompaktkurs. Datenbanken Skript zur Folge 5. Prof. Dr. Georg Herde Fachhochschule Deggendorf

IT-Kompaktkurs. Datenbanken Skript zur Folge 5. Prof. Dr. Georg Herde Fachhochschule Deggendorf IT-Kompaktkurs Skript zur Folge 5 Prof. Dr. Georg Herde Fachhochschule Deggendorf Semantisches Datenmodell, Entity-Relationship, Normalformen Bei der Entwicklung einer Datenbank wird das Ziel angestrebt,

Mehr

Entity-Relationship-Modell. Ein Studierender kann (oder muss) mehrere Vorlesungen hören. Eine Vorlesung wird i.a. von mehrerer Studierenden gehört.

Entity-Relationship-Modell. Ein Studierender kann (oder muss) mehrere Vorlesungen hören. Eine Vorlesung wird i.a. von mehrerer Studierenden gehört. Beziehungen Ein Studierender kann (oder muss) mehrere Vorlesungen hören. Eine Vorlesung wird i.a. von mehrerer Studierenden gehört. Eine Vorlesung wird von genau einem Dozenten gelesen. Ein Dozent kann

Mehr

Vom Entity-Relationship-Modell (ERM) zum relationalen Datenmodell (RDM)

Vom Entity-Relationship-Modell (ERM) zum relationalen Datenmodell (RDM) Regeln Vom Entity-Relationship-Modell (ERM) zum relationalen Datenmodell (RDM) Seite 1 Regel 1 Starke Entity-Typen Starke Entity-Typen Bilde ein Relationenschema R für jeden regulären Entity-Typ mit den

Mehr

Semantische Datenmodellierung Teil 1: Grundlagen. Hans-Georg Hopf

Semantische Datenmodellierung Teil 1: Grundlagen. Hans-Georg Hopf Semantische Datenmodellierung Teil 1: Grundlagen Hans-Georg Hopf 25. März 2004 Inhaltsverzeichnis 1 Dem Informationsnotstand begegnen 2 2 Datenmodelle 9 2.1 Datenablage............................ 10 2.2

Mehr

Das Entity-Relationship-Modell

Das Entity-Relationship-Modell Das Entity-Relationship-Modell 1976 vorgeschlagen von Peter Chen Entities wohlunterschiedbare Dinge der realen Welt Beispiele: Personen, Autos weithin akzeptiertes Modellierungswerkzeug, denn ist unabhšngig

Mehr

Wirtschaftsinformatik 2. Tutorium im WS 11/12

Wirtschaftsinformatik 2. Tutorium im WS 11/12 Wirtschaftsinformatik 2. Tutorium im WS 11/12 Entity/Relationship-Modell SQL Statements Tutorium Wirtschaftsinformatik WS 11/12 2.1 Datenmodellierung mit ERM (1) Datenmodellierung zur Erarbeitung des konzeptionellen

Mehr

Schulung FRBR Functional Requirements for Bibliographic Records

Schulung FRBR Functional Requirements for Bibliographic Records Arbeitsstelle für Standardisierung (AfS) 1. Oktober 2010 Schulung FRBR Functional Requirements for Bibliographic Records Modul B: Grundprinzipien FRBR ER-Modelle Lernziele Nach Bearbeitung des Moduls B

Mehr

Christian-Weise-Gymnasium Zittau Fachbereich Informatik M. Hans. Datenmodellierung 1. Inhaltsverzeichnis

Christian-Weise-Gymnasium Zittau Fachbereich Informatik M. Hans. Datenmodellierung 1. Inhaltsverzeichnis Datenmodellierung 1 Inhaltsverzeichnis 1. Informationsstruktur ermitteln...2 2. Datenstruktur modellieren...3 2.1 Elemente des ER-Modells...3 2.1.1 Entities...3 2.1.2 Beziehungen zwischen Entities...4

Mehr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr Raum: LF 230 Bearbeitung: 25.-29. April 2005 Datum Gruppe Vorbereitung Präsenz Aktuelle Informationen unter: http://www.is.informatik.uni-duisburg.de/courses/dbp_ss03/index.html Datenbankentwurf Der Entwurf

Mehr

Datenbankmodelle 1. Das Entity-Relationship-Modell

Datenbankmodelle 1. Das Entity-Relationship-Modell Datenbankmodelle 1 Das Entity-Relationship-Modell Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle ER Modell - 2 Was kann modelliert werden?

Mehr

Datenbankentwurf. Entwicklungsprozess Anforderungsanalyse & Miniwelt

Datenbankentwurf. Entwicklungsprozess Anforderungsanalyse & Miniwelt Datenbankentwurf Entwicklungsprozess Wollen DB entwickeln. Etwa für Comic-Sammlung, aus der Freunde ausleihen dürfen. Was ist dazu zu tun? Wie kommt man zu einer laufenden Anwendung? Datenbankentwurf Entwicklungsprozess

Mehr

ER-Modellierung am Beispiel der Universitätsdatenbank aus der DBIS-Vorlesung

ER-Modellierung am Beispiel der Universitätsdatenbank aus der DBIS-Vorlesung ER-Modellierung am Beispiel der Universitätsdatenbank aus der DBIS-Vorlesung Datenbank-Praktikum SS 2010 Prof. Dr. Georg Lausen Florian Schmedding ER-Modell: Wiederholung Entitäten E Beziehungen B Attribute

Mehr

Kapitel DB:IV (Fortsetzung)

Kapitel DB:IV (Fortsetzung) Kapitel DB:IV (Fortsetzung) IV. Logischer Datenbankentwurf mit dem relationalen Modell Das relationale Modell Integritätsbedingungen Umsetzung ER-Schema in relationales Schema DB:IV-45 Relational Design

Mehr

Der Tabellenname wird in Grossbuchstaben geschrieben.

Der Tabellenname wird in Grossbuchstaben geschrieben. Datenbanken: Abbildungsregeln 1 Tabellen Einleitung Da ein relationales Datenbankschema als Objekte nur Tabellen zulässt, müssen sowohl die Entitäts- als auch die Beziehungsmengen in Tabellenform ausgedrückt

Mehr

Profilbezogene informatische Bildung in den Klassenstufen 9 und 10. Schwerpunktthema Daten und Datenbanken

Profilbezogene informatische Bildung in den Klassenstufen 9 und 10. Schwerpunktthema Daten und Datenbanken Profilbezogene informatische Bildung in den Klassenstufen 9 und 10 Schwerpunktthema Robby Buttke Fachberater für Informatik RSA Chemnitz Fachliche Einordnung Phasen relationaler Modellierung Fachlichkeit

Mehr

Systemanalyse. - Folien zur Vorlesung für AI3 im Sommersemester 2010 - -Teil 4 -

Systemanalyse. - Folien zur Vorlesung für AI3 im Sommersemester 2010 - -Teil 4 - Systemanalyse - Folien zur Vorlesung für AI3 im Sommersemester 2010 - -Teil 4 - Hans-Jürgen Steffens (by courtesy of Prof. Dr. Thomas Allweyer) Fachbereich Informatik und Mikrosystemtechnik Fachhochschule

Mehr

Rückblick: Datenbankentwurf

Rückblick: Datenbankentwurf Rückblick: Datenbankentwurf Entity-Relationship-Modell für konzeptuellen Entwurf Entitytypen (entity types) (z.b. Studenten) Beziehungstypen (relationships) (z.b. hören) Attribute beschreiben Gegenstände

Mehr

Entwicklung einer DB-Anwendung vergleichbar mit gewöhnlicher Anwendungsprogrammierung:

Entwicklung einer DB-Anwendung vergleichbar mit gewöhnlicher Anwendungsprogrammierung: Entwicklung einer DB-Anwendung vergleichbar mit gewöhnlicher Anwendungsprogrammierung: 1. Problemanalyse (Datenmodellierung, konzeptionelles Schema) 2. Lösungsentwurf (logisches Schema) 3. Implementierung

Mehr

Teil 7: Einführung in den logischen Entwurf

Teil 7: Einführung in den logischen Entwurf 7. Einführung in den logischen Entwurf 7-1 Teil 7: Einführung in den logischen Entwurf Literatur: Elmasri/Navathe:Fundamentals of Database Systems, 3. Auflage, 1999. Chapter 3, Data Modeling Using the

Mehr

Einführung Datenbanken: Normalisierung

Einführung Datenbanken: Normalisierung Einführung Datenbanken: Normalisierung Für die Kursverwaltung einer VHS hat der Datenbank-Programmierer ein ER-Modell entworfen: Entitätstyp Entitäten Attribute Attributsausprägungen Kurse Teilnehmer Dozenten

Mehr

Darstellung von Assoziationen

Darstellung von Assoziationen Darstellung von Assoziationen Wie bereit aus Kapitel 1 bekannt, beschreiben Assoziationen Beziehungen zwischen Objekten, die zwischen Klassen modelliert werden. Zunächst soll die Modellierung binärer Assoziationen

Mehr

9. Einführung in Datenbanken

9. Einführung in Datenbanken 9. Einführung in Datenbanken 9.1 Motivation und einführendes Beispiel 9.2 Modellierungskonzepte der realen Welt 9.3 Anfragesprachen (Query Languages) 9.1 Motivation und einführendes Beispiel Datenbanken

Mehr

Software Engineering Analyse und Analysemuster

Software Engineering Analyse und Analysemuster Software Engineering Analyse und Analysemuster Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassendiagramme in der Analyse Im Rahmen der Anforderungsanalyse

Mehr

Kapitel 04 Strukturiertes Entity-Relationship-Modell. 4 Strukturiertes Entity-Relationship- Modell

Kapitel 04 Strukturiertes Entity-Relationship-Modell. 4 Strukturiertes Entity-Relationship- Modell Kapitel 04 Strukturiertes Entity-Relationship-Modell 4 Strukturiertes Entity-Relationship- Modell 4 Strukturiertes Entity-Relationship-Modell...1 4.1 Erste Verbesserung...4 4.2 Objekttypen in SERM...6

Mehr

Proseminar Pioniere der Informatik. Peter P. S. Chen

Proseminar Pioniere der Informatik. Peter P. S. Chen Proseminar Pioniere der Informatik Peter P. S. Chen Jawid Rassa Technische Universität München rassa@in.tum.de Abstract: Obwohl die Informatik derzeit eine noch sehr junge Wissenschaft ist, hat sie schon

Mehr

Software Engineering Klassendiagramme weiterführende Konzepte

Software Engineering Klassendiagramme weiterführende Konzepte Software Engineering Klassendiagramme weiterführende Konzepte Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassenattribut: static Implementierung in Java public

Mehr

Datenbankentwurf. 4.2 Logischer Entwurf. Kapitel 4. ER-Modell. Umsetzung. Entwurfsdokumentation. relationales Modell. Verbesserung

Datenbankentwurf. 4.2 Logischer Entwurf. Kapitel 4. ER-Modell. Umsetzung. Entwurfsdokumentation. relationales Modell. Verbesserung 4.2 Logischer Entwurf Datenbankentwurf 4.2 Logischer Entwurf 2002 Prof. Dr. Rainer Manthey Informationssysteme Logischer Entwurf: Einordnung Entwurfsdokumentation logische Strukturen "auf dem Papier" konzeptueller

Mehr

Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung

Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung 6. Datenintegrität Motivation Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung nur sinnvolle Attributwerte (z.b. keine negativen Semester) Abhängigkeiten

Mehr

Modellbasierte Softwareentwicklung mit EMF

Modellbasierte Softwareentwicklung mit EMF Softwaretechnik I, WS 2009/10 Modellbasierte Softwareentwicklung mit EMF Übungsblatt 5 13. November 2009 Organisatorisches Zur Bearbeitung der Übungsaufgabe stehen Ihnen die folgenden 3 Wochen (Kalenderwochen

Mehr

2 Das Entity-Relationship-Modell

2 Das Entity-Relationship-Modell 2 Das Entity-Relationship-Modell Das ER-Modell geht auf Peter Pi-Shan Chen zurück: P. P. Chen: The Entity-Relationship-Model Toward a Unified View of Data, ACM Transactions on Database Systems, Vol.1,

Mehr

Willkommen zum DBS I Praktikum!

Willkommen zum DBS I Praktikum! Willkommen zum DBS I Praktikum! Oliver Berthold Frank Huber Heiko Müller Lehr- und Forschungseinheit Datenbanken und Informationssysteme Übungsaufgaben Ausgabe Montags (i.d.r. aller 2 Wochen) erste Aufgabe

Mehr

WS 2002/03. Prof. Dr. Rainer Manthey. Institut für Informatik III Universität Bonn. Informationssysteme. Kapitel 1. Informationssysteme

WS 2002/03. Prof. Dr. Rainer Manthey. Institut für Informatik III Universität Bonn. Informationssysteme. Kapitel 1. Informationssysteme Informationssysteme Informationssysteme WS 2002/03 Prof. Dr. Rainer Manthey Institut für Informatik III Universität Bonn 2002 Prof. Dr. Rainer Manthey Informationssysteme 1 DB und/oder IS: terminologischer

Mehr

SWE5 Slide 1. Software-Engineering. Vorlesung 5 vom 15.11.2004 Sebastian Iwanowski FH Wedel

SWE5 Slide 1. Software-Engineering. Vorlesung 5 vom 15.11.2004 Sebastian Iwanowski FH Wedel SWE5 Slide 1 Software-Engineering Vorlesung 5 vom 15.11.2004 Sebastian Iwanowski FH Wedel SWE5 Slide 2 Software-Engineering Vorlesungsthemen: 1. Überblick über das Thema und die Vorlesung 2. Grundlegende

Mehr

Datenbanken. Einführung

Datenbanken. Einführung Datenbanken Einführung Einsatzbereiche von Datenbanken Unterstützung von Routinearbeiten Mehrfachnutzung von Daten Bewältigung der Informationsflut Fehlervermeidung Änderungen vornehmen Verbesserung der

Mehr

Datenbanken: Relationales Datenbankmodell RDM

Datenbanken: Relationales Datenbankmodell RDM Das RDM wurde in den 70'er Jahren von Codd entwickelt und ist seit Mitte der 80'er Jahre definierter Standard für Datenbanksysteme! Der Name kommt vom mathematischen Konzept einer Relation: (Sind A, B

Mehr

EDV-GESTÜTZTES ENTWERFEN, BERECHNEN UND KONSTRUIEREN IM BAUINGENIEURWESEN Prof. Dr.-Ing. Klaus Wassermann MODULPRÜFUNG

EDV-GESTÜTZTES ENTWERFEN, BERECHNEN UND KONSTRUIEREN IM BAUINGENIEURWESEN Prof. Dr.-Ing. Klaus Wassermann MODULPRÜFUNG EDV-GESTÜTZTES ENTWERFEN, BERECHNEN UND KONSTRUIEREN IM BAUINGENIEURWESEN Prof. Dr.-Ing. Klaus Wassermann MODULPRÜFUNG Bachelorstudiengang Facility Management Informatik am 26. September 2007 Name, Vorname

Mehr

Objektorientierte Modellierung (1)

Objektorientierte Modellierung (1) Objektorientierte Modellierung (1) Die objektorientierte Modellierung verwendet: Klassen und deren Objekte Beziehungen zwischen Objekten bzw. Klassen Klassen und Objekte Definition Klasse Eine Klasse ist

Mehr

Vorlesung Datenbanken II A Klausur

Vorlesung Datenbanken II A Klausur Prof. Dr. Stefan Brass 11. Juli 2006 Institut für Informatik MLU Halle-Wittenberg Vorlesung Datenbanken II A Klausur Name: Matrikelnummer: Studiengang: Aufgabe Punkte Max. Punkte Zeit 1 (Entwurf im ER-Modell)

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Schritt 3 (Grundlegende Folien für die Wiederholung sind mit gekennzeichnet!)

Schritt 3 (Grundlegende Folien für die Wiederholung sind mit gekennzeichnet!) HTW Berlin Prof. Dr. Zschockelt Datenmodellierung/Datenbanken (06)Semantische Datenmodellierung.ppt Folie 1 Lehrveranstaltung DM/DB Datenmodellierung und Datenbanksysteme Methodische Grundkenntnisse über

Mehr

2 Das Entity-Relationship-Modell

2 Das Entity-Relationship-Modell 2 Das Entity-Relationship-Modell (P.P.Chen, 1976; Verschiedene Versionen und Erweiterungen gebräuchlich) 2.1 Das Grundmodell... 2 2.2 Erweiterungen des ER-Modells... 58 2.3 Hinweise für den Aufbau von

Mehr

Objektorientierte Softwareentwicklung

Objektorientierte Softwareentwicklung Objektorientierte Softwareentwicklung Objektorientierte Softwareentwicklung Smalltalk CLOS Ada 9 C++ Objektorientierte Softwareentwicklung Object Pascal Java Oberon-2 Frage: Die Bibliothek der Fachhochschule

Mehr

Kurzreferenz Sybase PowerDesigner

Kurzreferenz Sybase PowerDesigner FB 4 Wirtschaftsinformatik Prof. Dr. Peter Zschockelt 1. Einführung Kurzreferenz Sybase PowerDesigner Der Sybase PowerDesigner ist ein universelles Modellierungstool. Für das Fach "Datenmodellierung und

Mehr

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2 EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0 EDV Kurs 13/2 Inhaltsverzeichnis 1 Objekte... 1 2 Klassen... 3 2.1 Beziehungen zwischen Klassen... 4 2.1.1 Vererbung... 4 2.1.2

Mehr

Datenbanken. Erstellen des Semantischen Modells. Manuel Friedrich. Schiller-Gymnasium Hof

Datenbanken. Erstellen des Semantischen Modells. Manuel Friedrich. Schiller-Gymnasium Hof Datenbanken Erstellen des Semantischen Modells Die Objektorientierte Sichtweise! Die Objektorientierte Sichtweise! Alles ist ein Objekt! Mensch Lehrgang Produkt Kunde Lieferant Beispiel Kreis Linienfarbe

Mehr

Wirtschaftsinformatik 2 Modellierung betrieblicher Informationssysteme - MobIS

Wirtschaftsinformatik 2 Modellierung betrieblicher Informationssysteme - MobIS Wirtschaftsinformatik 2 Modellierung betrieblicher Informationssysteme - MobIS (theoretische Aspekte der Informationsmodellierung) 3. Vorlesung 23.04.2007 Informationsmodelle Phasen der Softwareentwicklung:

Mehr

Daten Bank. 2. Vorlesung. Dr. Karsten Tolle PRG2 SS 2015

Daten Bank. 2. Vorlesung. Dr. Karsten Tolle PRG2 SS 2015 Daten Bank 2. Vorlesung Dr. Karsten Tolle PRG2 SS 2015 Letzte Vorlesung Grundbegriffe SQL create table insert select Dr. Karsten Tolle PRG2 SS 2015 2 Heute Übersicht Modellierung (ER-Diagramme) Entitäten

Mehr

Software-Engineering Einführung

Software-Engineering Einführung Software-Engineering Einführung 7. Übung (04.12.2014) Dr. Gergely Varró, gergely.varro@es.tu-darmstadt.de Erhan Leblebici, erhan.leblebici@es.tu-darmstadt.de Tel.+49 6151 16 4388 ES Real-Time Systems Lab

Mehr

Übung 1. Ziel: Statisches Modell (Klassendiagramm) aus allgemeiner Beschreibung erstellen.

Übung 1. Ziel: Statisches Modell (Klassendiagramm) aus allgemeiner Beschreibung erstellen. Übung 1 Ziel: Statisches Modell (Klassendiagramm) aus allgemeiner Beschreibung erstellen. Für Paletten ist eine verwaltung zu organisieren, eine Palette kann in einem offenen (z.b. eine große halle) stehen.

Mehr

DAS ENTITY-RELATIONSHIP MODELL (E-R MODEL)

DAS ENTITY-RELATIONSHIP MODELL (E-R MODEL) DAS ENTITY-RELATIONSHIP MODELL (E-R MODEL) P. Chen (76, ACM-TODS) Einfache graphische Darstellung Hauptelemente: Entitäten (entities) Beziehungen (relationships) Attribute (attributes) Weitere Elemente:

Mehr

Übungen zu Modellierung verteilter Systeme

Übungen zu Modellierung verteilter Systeme Technische Universität München SoSe 2014 Institut für Informatik Lösungsblatt 1 PD Dr.habil. B. Schätz Ausgabe: 17. April 2014 M. Gleirscher, D. Marmsoler Besprechung: 24. April 2014 Übungen zu Modellierung

Mehr

1. Ziel des Datenbankentwurfs

1. Ziel des Datenbankentwurfs 1. Ziel des Datenbankentwurfs Ziel ist der Aufbau eines Modells eines Teilbereiches der wahrnehmbaren Realität und Abbildung dieses Bereichs in Form von Daten, so dass diese nach verschiedensten Kriterien

Mehr

Übung Datenbanksysteme

Übung Datenbanksysteme Übung Datenbanksysteme Martin Reifberger Übungsaufgabe 1 Sachverhalt: Ein mittelständiges Industrieunternehmen möchte sein Auftragswesen datenbankbasiert organisieren, da die tägliche Flut auflaufender

Mehr

Integritätsbedingungen / Normalformen- Beispiel: Kontoführung

Integritätsbedingungen / Normalformen- Beispiel: Kontoführung Technische Universität München WS 2003/04, Fakultät für Informatik Datenbanksysteme I Prof. R. Bayer, Ph.D. Lösungsblatt 8 Dipl.-Inform. Michael Bauer Dr. Gabi Höfling 12.01. 2004 Integritätsbedingungen

Mehr

Wirtschaftsinformatik 2

Wirtschaftsinformatik 2 Wirtschaftsinformatik 2 Prof. Dr. Dr. L. Schmidt-Thieme MSc. André Busche Übung 2 1. Übungsblatt 2 2. Saalübung 02.05.12 2/ Aufgabe 2a (2 Punkte) Welche Vorteile bietet die Verwaltung von Daten in Datenbanken?

Mehr

Das Entity-Relationship-Modell (ERM)

Das Entity-Relationship-Modell (ERM) Das Entity-Relationship-Modell (ERM) Konzeptionelle Informationsmodellierung Das Entity-Relationship-Modell (ER-Modell) Konzepte ER-Diagramme Beispiele Das Erweiterte ER-Modell (EER-Modell) Subklassen,

Mehr

On the Consistency of Spatial Semantic Integrity Constraints. Konsistenzprüfung von räumlichen semantischen Integritätsregeln.

On the Consistency of Spatial Semantic Integrity Constraints. Konsistenzprüfung von räumlichen semantischen Integritätsregeln. On the Consistency of Spatial Semantic Integrity Constraints Konsistenzprüfung von räumlichen semantischen Problemstellung Geographische Daten werden immer häufiger dezentral gehalten und mithilfe vernetzter

Mehr

Vorlesung "Software-Engineering"

Vorlesung Software-Engineering Vorlesung "Software-Engineering" Rainer Marrone, TUHH, Arbeitsbereich STS Vorige Vorlesung Pflichtenheft (requirements specification document) Charakterisierung von Software-Qualität Detaillierte Anforderungsanalyse

Mehr

Objektorientierte Programmierung. Kapitel 3: Syntaxdiagramme und Grammatikregeln

Objektorientierte Programmierung. Kapitel 3: Syntaxdiagramme und Grammatikregeln Stefan Brass: OOP (Java), 3. Syntaxdiagramme und Grammatikregeln 1/32 Objektorientierte Programmierung Kapitel 3: Syntaxdiagramme und Grammatikregeln Stefan Brass Martin-Luther-Universität Halle-Wittenberg

Mehr

Grundbegriffe der Objektorientierung

Grundbegriffe der Objektorientierung Grundbegriffe der Objektorientierung Objekt Merkmale Zustand Verhalten Lebenszyklus Beziehungen zwischen Objekten Kategorisierung von Objekten Grundbegriffe der Objektorientierung Objekt Merkmale Zustand

Mehr

Codierungstheorie Rudolf Scharlau, SoSe 2006 9

Codierungstheorie Rudolf Scharlau, SoSe 2006 9 Codierungstheorie Rudolf Scharlau, SoSe 2006 9 2 Optimale Codes Optimalität bezieht sich auf eine gegebene Quelle, d.h. eine Wahrscheinlichkeitsverteilung auf den Symbolen s 1,..., s q des Quellalphabets

Mehr

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. Einleitung / Entity-Relationship

Mehr

10. Datenbank Design 1

10. Datenbank Design 1 1 Die Hauptaufgabe einer Datenbank besteht darin, Daten so lange zu speichern bis diese explizit überschrieben oder gelöscht werden. Also auch über das Ende (ev. sogar der Lebenszeit) einer Applikation

Mehr

Relationenmodell (RM)

Relationenmodell (RM) Relationenmodell (RM) Lehr- und Forschungseinheit Datenbanken und Informationssysteme Ziele Relationenmodell Transformation E-R-Modell in Relationenmodell Lehr- und Forschungseinheit Datenbanken und Informationssysteme

Mehr

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen:

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen: 1 Einführung in Datenbanksysteme Fast jeder kennt Excel und hat damit in seinem Leben schon einmal gearbeitet. In Excel gibt es Arbeitsblätter, die aus vielen Zellen bestehen, in die man verschiedene Werte

Mehr

Online-Kurs 'Datenbanken und Datenmodellierung'

Online-Kurs 'Datenbanken und Datenmodellierung' Online-Kurs 'Datenbanken und Datenmodellierung' Das Entity-Relationship-Modell Print-Version - 15.04.2002 (c) StR S. Winter - Universität Passau Inhaltsverzeichnis 1 Allgemeine Hinweise zum Abschnitt ER-Modell

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Objektorientierte Programmiersprachen

Objektorientierte Programmiersprachen Objektorientierte Programmiersprachen 1960 Algol 1970 Simula Pascal 1980 Smalltalk C Ada 1990 C++ Eiffel Eine ovale Box symbolisiert eine objektorientierte Programmiersprache. Eine rechteckige Box steht

Mehr

Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell

Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell Aufgabe 3. Assoziation

Mehr

Objektorientierte Programmierung OOP

Objektorientierte Programmierung OOP Objektorientierte Programmierung OOP Objektorientierte Programmierung OOP Ronja Düffel WS2012/13 08. Oktober 2013 Objektorientierte Programmierung OOP Objektorientierte Programmierung Objektorientierte

Mehr

Datenbanktechnologie mit praktischen Übungen in MySQL und PHP

Datenbanktechnologie mit praktischen Übungen in MySQL und PHP Datenbanktechnologie mit praktischen Übungen in MySQL und PHP Übung, Sommersemester 2013 29. April 2013 - MySQL 2 Sebastian Cuy sebastian.cuy@uni-koeln.de Aufgaben Anmerkungen Best practice: SQL Befehle

Mehr

Einführung in Datenbanksysteme. H. Wünsch 01.2001

Einführung in Datenbanksysteme. H. Wünsch 01.2001 Einführung in Datenbanksysteme H. Wünsch 01.2001 H. Wünsch 01/2001 Einführung Datenbanken 2 Was sind Datenbanken? Datenbanken sind Systeme zur Beschreibung, Speicherung und Wiedergewinnung von Datenmengen.

Mehr

Objektorientierte Konzepte und Notation in UML. Objekt Klasse Attribut Operation

Objektorientierte Konzepte und Notation in UML. Objekt Klasse Attribut Operation Objektorientierte Konzepte und Notation in UML Objekt Klasse Attribut Operation Objekt Wodurch zeichnet sich ein Objekt aus? - Zustand - Verhalten - Identität Objektdiagramm - Notationsregeln :Kuh Elsa:Kuh

Mehr

Hinweise zur Anfertigung von wissenschaftlichen Arbeiten

Hinweise zur Anfertigung von wissenschaftlichen Arbeiten UNIVERSITÄT HOHENHEIM INSTITUT FÜR BETRIEBSWIRTSCHAFTSLEHRE Fachgebiet Risikomanagement und Derivate Prof. Dr. Christian Koziol Hinweise zur Anfertigung von wissenschaftlichen Arbeiten Formale Richtlinien

Mehr

Grundlagen von Datenbanksystemen

Grundlagen von Datenbanksystemen Ramez Elmasri Shamkant B. Navathe Grundlagen von Datenbanksystemen 3., überarbeitete Auflage ein Imprint der Pearson Education Deutschland GmbH Inhaltsverzeichnis Vorwort 9 Über die Autoren 13 Teil 1 Grundkonzepte

Mehr

Software Engineering Klassendiagramme Einführung

Software Engineering Klassendiagramme Einführung Software Engineering Klassendiagramme Einführung Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Aufgabe Erstellen Sie eine Klasse Person in Java. Jede Person verfügt

Mehr

2.5.2 Primärschlüssel

2.5.2 Primärschlüssel Relationale Datenbanken 0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110

Mehr

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. DB Einleitung / Entity-Relationship

Mehr

3. Übung. Einführung MS Access. TU Dresden - Institut für Bauinformatik Folie-Nr.: 1

3. Übung. Einführung MS Access. TU Dresden - Institut für Bauinformatik Folie-Nr.: 1 WP3-13 Bauinformatik-Vertiefte Grundlagen 3. Übung Einführung MS Access Folie-Nr.: 1 Allgemeines Microsoft Access ist ein Datenbank-Management-System (DBMS) zur Verwaltung von Daten in Datenbanken und

Mehr

Datenbanken ERM, Tabellen aus dem ERM, SQL

Datenbanken ERM, Tabellen aus dem ERM, SQL Datenbanken ERM, Tabellen aus dem ERM, SQL Bernd Blümel Version: 16. März 2005 Inhaltsverzeichnis 1 Wie man es nicht machen sollte 1 2 Tabellen, Felder, Datensätze und Schlüssel 3 3 Entity-Relationship

Mehr

Institut für Informatik

Institut für Informatik Aufgaben für die 14. und 15. zur LV "Grundlagen der Informatik" Thema: Datenbanken ( ERM: Entity-Relationship-Modell und SQL: Structured Query Language ) sowie HTML (Hypertext Markup Language) -------------------------------------------------------------------------------------------------------------------------

Mehr

Siehe auch Heide Balzert: Lehrbuch der Objektmodellierung.

Siehe auch Heide Balzert: Lehrbuch der Objektmodellierung. Siehe auch Heide Balzert: Lehrbuch der Objektmodellierung. 9. Analyse Muster 1 Der Unterschied von Analyse und Design Pattern besteht auch in der zeitlichen Abfolge. Analyse Muster werden in der Analyse

Mehr

Klassifikation von Integrationskonflikten

Klassifikation von Integrationskonflikten Klassifikation von Integrationskonflikten Christiane Telöken 1 Inhaltsverzeichnis 1. Was bedeutet Integration? 2. Strukturelle Heterogenitätskonflikte 2.1 Konflikte bei bilateralen Korrespondenzen 2.2

Mehr

Übungsblatt 4. Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin)

Übungsblatt 4. Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin) Übungsblatt 4 Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin) Die Saartal Linien beauftragen Sie mit dem Entwurf der Datenstrukturen für ein Informationssystem. Dieses soll zur Verwaltung

Mehr