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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

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

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

Ü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

DBSP. Vorlesung. Prof. Dr. rer. nat. Nane Kratzke. Unit. Praktische Informatik und betriebliche Informationssysteme

DBSP. Vorlesung. Prof. Dr. rer. nat. Nane Kratzke. Unit. Praktische Informatik und betriebliche Informationssysteme Handout zur Vorlesung Vorlesung DBSP Unit Datenmodellierung 1 Prof. Dr. rer. nat. Nane Kratzke Praktische Informatik und betriebliche Informationssysteme Raum: 17-0.10 Tel.: 0451 300 5549 Email: kratzke@fh-luebeck.de

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

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

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

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

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

Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme. 11. November 2014

Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme. 11. November 2014 Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme 11. November 2014 Überblick Was ist die Unified Modeling Language (UML)? die Standardmodellierungssprache für Softwaresysteme

Mehr

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

LISE MEITNER GYMNASIUM NEUENHAUS UELSEN

LISE MEITNER GYMNASIUM NEUENHAUS UELSEN Entwurf eines schulinternen Curriculums im Fach Informatik für die Qualifikationsphase (Jahrgang 11 und 12) Für die Gestaltung des Informatikunterrichts in der Qualifikationsphase sind für das schulinterne

Mehr

KONZEPTUELLES DATENBANKEN-DESIGN

KONZEPTUELLES DATENBANKEN-DESIGN KONZEPTUELLES DATENBANKEN-DESIGN Batini, Ceri, Navathe, Conceptual Database Design, The Benjamin/Cummings Pub., 1992 ISBN 0-8053-0244-1 Part I: Kapitel 1 und Kapitel 2 II-1 Methode des Datenbanken-Designs

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

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software SQL Tutorial SQL - Tutorial SS 06 Hubert Baumgartner INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische Universität Wien Inhalt des Tutorials 1 2 3 4

Mehr

Gibt es verschiedene Arten unendlich? Dieter Wolke

Gibt es verschiedene Arten unendlich? Dieter Wolke Gibt es verschiedene Arten unendlich? Dieter Wolke 1 Zuerst zum Gebrauch des Wortes unendlich Es wird in der Mathematik in zwei unterschiedlichen Bedeutungen benutzt Erstens im Zusammenhang mit Funktionen

Mehr

TECHNISCHE UNIVERSITÄT DRESDEN Fakultät Wirtschaftswissenschaften Prof. Dr. W. Esswein Lehrstuhl Wirtschaftsinformatik, insbesondere Systementwicklung

TECHNISCHE UNIVERSITÄT DRESDEN Fakultät Wirtschaftswissenschaften Prof. Dr. W. Esswein Lehrstuhl Wirtschaftsinformatik, insbesondere Systementwicklung TECHNISCHE UNIVERSITÄT DRESDEN Fakultät Wirtschaftswissenschaften Prof. Dr. W. Esswein Lehrstuhl Wirtschaftsinformatik, insbesondere Systementwicklung Diplomprüfung Wintersemester 2010-2011 im Fach Wirtschaftsinformatik,

Mehr

Angewandte Mathematik und Programmierung

Angewandte Mathematik und Programmierung Angewandte Mathematik und Programmierung Einführung in das Konzept der objektorientierten Anwendungen zu mathematischen Rechnens WS 2013/14 Die Vererbung ermöglicht es, neue Klassen auf der Basis von schon

Mehr

Teil 3: Einführung in das Entity-Relationship-Modell

Teil 3: Einführung in das Entity-Relationship-Modell 3. Einführung in das Entity-Relationship-Modell 3-1 Teil 3: Einführung in das Entity-Relationship-Modell Literatur: Elmasri/Navathe:Fundamentals of Database Systems, 3. Auflage, 1999. Chapter 3, Data Modeling

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

Sprechen wir über Zahlen (Karl-Heinz Wolff)

Sprechen wir über Zahlen (Karl-Heinz Wolff) Sprechen wir über Zahlen (Karl-Heinz Wolff) Die Überschrift ist insoweit irreführend, als der Autor ja schreibt und nicht mit dem Leser spricht. Was Mathematik im allgemeinen und Zahlen im besonderen betrifft,

Mehr

Analyse und Entwurf objektorientierter Systeme

Analyse und Entwurf objektorientierter Systeme Analyse und Entwurf objektorientierter Systeme Teil 3 Modellbildung in der Analysephase 3.1 Statische und dynamische Notationselemente Modul WI111: Objektorientierte Programmierung Fachrichtung Wirtschaftsinformatik

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

Musterlösung zur Klausur Prozess- und Daten-Modellierung. Termin: 2006-10-19, 8:00 09:30 Uhr

Musterlösung zur Klausur Prozess- und Daten-Modellierung. Termin: 2006-10-19, 8:00 09:30 Uhr Musterlösung zur Klausur Prozess- und Daten-Modellierung Termin: 006-10-19, 8:00 09:30 Uhr Name:... Vorname:... Strasse:... PLZ, Ort:... Matrikel-Nr.:... Wirtschafts- und Sozialwissenschaftliche Fakultät

Mehr

1 Einleitung. Software Engineering. Vorgehensweisen

1 Einleitung. Software Engineering. Vorgehensweisen 1 Noch ein Buch über Software Engineering? Warum nicht! Wir folgen einem Prinzip, das zur Lösungsfindung in den verschiedensten Domänen Einzug gehalten hat: die Betrachtung aus verschiedenen Blickwinkeln.

Mehr

Klausur Datenbanksysteme

Klausur Datenbanksysteme Prüfung Datenbanksysteme, 31.Jan. 2003 S. 1 Klausur Datenbanksysteme Name: Matrikel-Nr.: Studiengang: Aufgabenblatt nicht vor Beginn der Prüfung umdrehen! Prüfer: Prof. Dr. Martin Hulin Dauer: 90 Minuten

Mehr

7 Projektarbeit Fahrradverleih

7 Projektarbeit Fahrradverleih Kapitel 7 Projekt Fahrradverleih Seite 1 7 Projektarbeit Fahrradverleih 7.1 Aufgabenstellung In einem Geschäft, das Fahrräder vermietet, sollen die Aktionen, die beim Verleih dieser Fahrräder ablaufen,

Mehr

syntax.tex Eine Übersicht

syntax.tex Eine Übersicht syntax.tex Eine Übersicht Bernd Worsch 7. Juli 1997 Inhaltsverzeichnis 1 Einleitung 1 2 Bevor es funktioniert... 1 3 Grundelemente von syntax.tex 1 4 Strukturelemente von syntax.tex 3 5 Setzen von Syntaxdiagrammen

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Musterlösung Name: Matrikelnummer: Note: Prüfungstag:

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

Hochschule Karlsruhe Technik und Wirtschaft- 10.7.2013. Anhänge: Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Prof. Schmidt.

Hochschule Karlsruhe Technik und Wirtschaft- 10.7.2013. Anhänge: Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Prof. Schmidt. Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Datenbanken und Informationssysteme II Szenario: Projektverwaltung. Es gibt Projekte, Projektleiter, Mitarbeiter und ihre Zuordnung zu Projekten.

Mehr

Einführung in die Programmierung mit Java. Hörsaalübung

Einführung in die Programmierung mit Java. Hörsaalübung Einführung in die Programmierung mit Java Hörsaalübung Folie 1 Grundlagen der Objektorientierung Seit Anfang der Neunzigerjahre Standardmethode der Softwareentwicklung. Die OOP Objektorientierte Programmierung

Mehr

Präsentation zum Thema XML Datenaustausch und Integration

Präsentation zum Thema XML Datenaustausch und Integration Sebastian Land Präsentation zum Thema XML Datenaustausch und Integration oder Warum eigentlich XML? Gliederung der Präsentation 1. Erläuterung des Themas 2. Anwendungsbeispiel 3. Situation 1: Homogene

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Orientierte Modellierung mit der Unified Modeling Language

Orientierte Modellierung mit der Unified Modeling Language UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language Michael Hahsler Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Name: Matrikelnummer: Note: Prüfungstag: 21.09.2012 Prüfungsdauer:

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

Strukturierte Entity-Relationship-Modellierung. Übungsaufgaben

Strukturierte Entity-Relationship-Modellierung. Übungsaufgaben Strukturierte Entity-Relationship-Modellierung Übungsaufgaben 1 Aufgabenstellungen...2 2 Lösungen zu den Aufgabenstellungen...15 Seite 1 1 Aufgabenstellungen Seite 2 Aufgabe 1: Ergänzen Sie das Entity-Relationship-Modell

Mehr

Sichten II. Definition einer Sicht. Sichten. Drei-Ebenen-Schema-Architektur. Vorteile Vereinfachung von Anfragen Strukturierung der Datenbank

Sichten II. Definition einer Sicht. Sichten. Drei-Ebenen-Schema-Architektur. Vorteile Vereinfachung von Anfragen Strukturierung der Datenbank Vorteile Vereinfachung von Anfragen Strukturierung der Datenbank Sichten II logische Datenunabhängigkeit (Sichten stabil bei Änderungen der Datenbankstruktur) Beschränkung von Zugriffen (Datenschutz) Definition

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

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

Die Funktion ist Träger von Zeiten und Kosten.

Die Funktion ist Träger von Zeiten und Kosten. Funktion Eine Funktion ist eine fachliche Aufgabe, ein Vorgang bzw. eine Tätigkeit an einem (Informations-)Objekt zur Unterstützung eines oder mehrerer Unternehmensziele. Die Funktion ist Träger von Zeiten

Mehr

Assoziation und Aggregation

Assoziation und Aggregation Assoziation und Aggregation Martin Wirsing in Zusammenarbeit mit Matthias Hölzl, Nora Koch 05/03 2 Ziele Verstehen der Begriffe Assoziation und Aggregation Implementierung von Assoziationen in Java schreiben

Mehr

Fachbereich Informatik Praktikum 1

Fachbereich Informatik Praktikum 1 Hochschule Darmstadt DATA WAREHOUSE SS2015 Fachbereich Informatik Praktikum 1 Prof. Dr. S. Karczewski Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 14.April.2015 1. Kurzbeschreibung In diesem Praktikum geht

Mehr

LINQ to SQL. Proseminar Objektorientiertes Programmieren mit.net und C# Christoph Knüttel. Institut für Informatik Software & Systems Engineering

LINQ to SQL. Proseminar Objektorientiertes Programmieren mit.net und C# Christoph Knüttel. Institut für Informatik Software & Systems Engineering LINQ to SQL Proseminar Objektorientiertes Programmieren mit.net und C# Christoph Knüttel Institut für Informatik Software & Systems Engineering Agenda 1. LINQ allgemein Vorteile Bausteine und Varianten

Mehr

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

Mehr

Probabilistische Datenbanken

Probabilistische Datenbanken Probabilistische Datenbanken Seminar Intelligente Datenbanken AG Intelligente Datenbanken Prof. Dr. Rainer Manthey 26.04.05 Maarten van Hoek - 1 - Inhaltsverzeichnis 1.0 Einleitung...3 2.0 Modell probabilistischer

Mehr

Graphen: Einführung. Vorlesung Mathematische Strukturen. Sommersemester 2011

Graphen: Einführung. Vorlesung Mathematische Strukturen. Sommersemester 2011 Graphen: Einführung Vorlesung Mathematische Strukturen Zum Ende der Vorlesung beschäftigen wir uns mit Graphen. Graphen sind netzartige Strukturen, bestehend aus Knoten und Kanten. Sommersemester 20 Prof.

Mehr

DATENSTRUKTUREN UND ZAHLENSYSTEME

DATENSTRUKTUREN UND ZAHLENSYSTEME DATENSTRUKTUREN UND ZAHLENSYSTEME RALF HINZE Institute of Information and Computing Sciences Utrecht University Email: ralf@cs.uu.nl Homepage: http://www.cs.uu.nl/~ralf/ March, 2001 (Die Folien finden

Mehr

adcubum ACADEMY. Die Vertiefung von Hochstehendem. SQL-Datenbankkurse

adcubum ACADEMY. Die Vertiefung von Hochstehendem. SQL-Datenbankkurse adcubum ACADEMY. Die Vertiefung von Hochstehendem. SQL-Datenbankkurse Rubrik: Datenbanken Einleitung adcubum SYRIUS legt alle Bewegungsdaten in der Datenbank ab. Als Consultant, Parametrierer, Kundendienstmitarbeitender,

Mehr

Übungen zum Entity-Relationship-Diagramm-Entwurf

Übungen zum Entity-Relationship-Diagramm-Entwurf Übungen zum Entity-Relationship-Diagramm-Entwurf Holger Jakobs bibjah@bg.bib.de, holger@jakobs.com 2011-07-01 Inhaltsverzeichnis 1 Projektarbeiten 1 2 Planstellenverwaltung 2 3 Tennisclub 3 4 Bücherei

Mehr

Beschreibungsmodelle

Beschreibungsmodelle Beschreibungsmodelle Inhaltsverzeichnis 1 Übersicht 2 1.1 eite 1................................. 2 2 Architekturmodelle 3 2.1 eite 1................................. 3 3 Datenmodelle 4 3.1 eite 1.................................

Mehr

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1.

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1. Inhalt der Vorlesung Literatur 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen

Mehr

Datenmodellierung und Datenbanksysteme. Vorlesung. Informationswissenschaft und Informationssysteme. Hans Uszkoreit & Brigi1e Jörg

Datenmodellierung und Datenbanksysteme. Vorlesung. Informationswissenschaft und Informationssysteme. Hans Uszkoreit & Brigi1e Jörg Vorlesung Informationswissenschaft und Informationssysteme Hans Uszkoreit & Brigi1e Jörg Definitionen Data modeling in software engineering is the process of creating a data model by applying formal data

Mehr

KONSTRUKTION VON ROT-SCHWARZ-BÄUMEN

KONSTRUKTION VON ROT-SCHWARZ-BÄUMEN KONSTRUKTION VON ROT-SCHWARZ-BÄUMEN RALF HINZE Institut für Informatik III Universität Bonn Email: ralf@informatik.uni-bonn.de Homepage: http://www.informatik.uni-bonn.de/~ralf Februar, 2001 Binäre Suchbäume

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Klausur Datenbanken Wintersemester 2013/2014 Prof. Dr. Wolfgang May 29. Januar 2014, 14-16 Uhr Bearbeitungszeit: 90 Minuten

Klausur Datenbanken Wintersemester 2013/2014 Prof. Dr. Wolfgang May 29. Januar 2014, 14-16 Uhr Bearbeitungszeit: 90 Minuten Klausur Datenbanken Wintersemester 2013/2014 Prof. Dr. Wolfgang May 29. Januar 2014, 14-16 Uhr Bearbeitungszeit: 90 Minuten Vorname: Nachname: Matrikelnummer: Studiengang: Bei der Klausur sind keine Hilfsmittel

Mehr

Peter Meier. Die Umsetzung von Risikomanagement nach ISO 31000. - Leseprobe -

Peter Meier. Die Umsetzung von Risikomanagement nach ISO 31000. - Leseprobe - Peter Meier Die Umsetzung von Risikomanagement nach ISO 31000 Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen

Mehr

Objektorientierte Programmierung

Objektorientierte Programmierung Objektorientierte Programmierung Ein Computerprogramm besteht aus Funktionen (Programmabschnitten, die etwas tun) und Variablen (Speicherplätzen für Informationen). Werden Funktionen aktiviert, verändern

Mehr

Inhalt: Version 1.7.5

Inhalt: Version 1.7.5 Inhalt: Objekte ohne Methoden Objekte mit einfachen Methoden Objekte und Methoden mit Parametern Objekte und Methoden mit Rückgabewert Objekte mit einem Array als Attribut Beziehungen zwischen Objekten

Mehr

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen Lennart Leist Inhaltsverzeichnis 1 Einführung 2 1.1 Aufgaben einer Datenbank...................... 2 1.2 Geschichtliche Entwicklung

Mehr

Normalformen. Datenmodellierung, Datenbanksysteme. Ingo Claÿen, Martin Kempa, Peter Morcinek. Hochschule für Technik und Wirtschaft Berlin

Normalformen. Datenmodellierung, Datenbanksysteme. Ingo Claÿen, Martin Kempa, Peter Morcinek. Hochschule für Technik und Wirtschaft Berlin Normalformen Datenmodellierung, Datenbanksysteme Ingo Claÿen, Martin Kempa, Peter Morcinek Hochschule für Technik und Wirtschaft Berlin Nichtnormalisierte Tabelle Update-Anomalie MNR Name ANR AbtBez 11

Mehr

Teil 5: Datenbankdesign, ER-Modell, Normalformen. Das Entity-Relationship (ER) Modell

Teil 5: Datenbankdesign, ER-Modell, Normalformen. Das Entity-Relationship (ER) Modell Teil 5: Datenbankdesign, ER-Modell, Normalformen Generell ist beim Datenbankdesign zwischen logischem und physischem Design zu unterscheiden. Das logische Design führt zu den Tabellen und Attributen, die

Mehr

Hinweise zum Erstellen eines Verfahrensverzeichnisses

Hinweise zum Erstellen eines Verfahrensverzeichnisses Hinweise zum Erstellen eines Verfahrensverzeichnisses Eine Information des Datenschutzbeauftragten der PH Freiburg Stand: 11.03.2010 Inhalt Hinweise zum Erstellen eines Verfahrensverzeichnisses... 1 Vorbemerkung...

Mehr

DB-Entwurf im ER-Modell

DB-Entwurf im ER-Modell DB-Entwurf im 1 Datenbankentwurf 2 Datenbankmodell 3 4 Erweiterungen des s 5 Weiteres Vorgehen beim Entwurf Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 1 Datenbankentwurf Entwurfsaufgabe Datenhaltung

Mehr

Softwareentwurf für Technische Systeme Kapitel 6: Erfassen und Pflege von Anforderungen

Softwareentwurf für Technische Systeme Kapitel 6: Erfassen und Pflege von Anforderungen : Softwareentwurf für Technische Systeme Kapitel 6: Erfassen und Pflege von Anforderungen Alexey Cheptsov : Kapitel 6: Anforderungsanalyse 6.1 Das Beispiel 6.2 Problembeschreibung & Risikoanalyse 6.3 Namensanalyse

Mehr

Objektorientierte Programmierung. Objektorientierte Programmierung. Klasse. Objekt. Beispiel: Sportfest1. Methode. Eine Einführung mit BlueJ

Objektorientierte Programmierung. Objektorientierte Programmierung. Klasse. Objekt. Beispiel: Sportfest1. Methode. Eine Einführung mit BlueJ Objektorientierte Programmierung Objektorientierte Programmierung Eine Einführung mit BlueJ stellt die Daten, ihre Struktur und ihre Beziehungen zueinander in den Vordergrund. Weniger im Blickpunkt: die

Mehr

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2008/2009

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2008/2009 PIWIN I Kap. 8 Objektorientierte Programmierung - Vererbung 1 PIWIN I Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I Vorlesung 3 SWS WS 2008/2009 FB Informatik

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE

BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE CO-MAT-TECH 2004 14-15 October 2004 BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE Roman NAGY External doctorand

Mehr

Repräsentation von Daten Binärcodierung von rationalen Zahlen und Zeichen

Repräsentation von Daten Binärcodierung von rationalen Zahlen und Zeichen Kapitel 4: Repräsentation von Daten Binärcodierung von rationalen Zahlen und Zeichen Einführung in die Informatik Wintersemester 2007/08 Prof. Bernhard Jung Übersicht Codierung von rationalen Zahlen Konvertierung

Mehr

3. Spezielle ER-Modelle und Tabellenableitung

3. Spezielle ER-Modelle und Tabellenableitung 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

Binäre Suchbäume (binary search trees, kurz: bst)

Binäre Suchbäume (binary search trees, kurz: bst) Binäre Suchbäume (binary search trees, kurz: bst) Datenstruktur zum Speichern einer endlichen Menge M von Zahlen. Genauer: Binärbaum T mit n := M Knoten Jeder Knoten v von T ist mit einer Zahl m v M markiert.

Mehr

1 Die Active Directory

1 Die Active Directory 1 Die Active Directory Infrastruktur Prüfungsanforderungen von Microsoft: Configuring the Active Directory Infrastructure o Configure a forest or a domain o Configure trusts o Configure sites o Configure

Mehr

3. Zusammenhang. 22 Andreas Gathmann

3. Zusammenhang. 22 Andreas Gathmann 22 Andreas Gathmann 3. Zusammenhang Eine der anschaulichsten Eigenschaften eines topologischen Raumes ist wahrscheinlich, ob er zusammenhängend ist oder aus mehreren Teilen besteht. Wir wollen dieses Konzept

Mehr

Kurzreferenz UML. Autor: Michael Puff. Stand: 2010-05-21. http://www.michael-puff.de mail@michael-puff.de

Kurzreferenz UML. Autor: Michael Puff. Stand: 2010-05-21. http://www.michael-puff.de mail@michael-puff.de Kurzreferenz UML Autor: Michael Puff Stand: 2010-05-21 http://www.michael-puff.de mail@michael-puff.de Inhaltsverzeichnis Inhaltsverzeichnis 1 Die Modellierungssprache UML 5 1.1 Definition Klasse - Objekt......................

Mehr

Einführung in SQL Datenbanken bearbeiten

Einführung in SQL Datenbanken bearbeiten Einführung in SQL Datenbanken bearbeiten Jürgen Thomas Entstanden als Wiki-Buch Bibliografische Information Diese Publikation ist bei der Deutschen Nationalbibliothek registriert. Detaillierte Angaben

Mehr

4. Relationen. Beschreibung einer binären Relation

4. Relationen. Beschreibung einer binären Relation 4. Relationen Relationen spielen bei Datenbanken eine wichtige Rolle. Die meisten Datenbanksysteme sind relational. 4.1 Binäre Relationen Eine binäre Relation (Beziehung) R zwischen zwei Mengen A und B

Mehr

Objektorientierte Datenmodelle und - verwaltung

Objektorientierte Datenmodelle und - verwaltung Schlagworte der 90er: Objektorientiertes GIS OpenGIS Case-Tool Geoökologe Legt Problemstellung fest (Art, Anzahl, Dimension, Skalierung) Wählt Koordinatensystem Wählt Fachattribute OOUI (object-oriented

Mehr