Online-Kurs 'Datenbanken und Datenmodellierung'

Größe: px
Ab Seite anzeigen:

Download "Online-Kurs 'Datenbanken und Datenmodellierung'"

Transkript

1 Online-Kurs 'Datenbanken und Datenmodellierung' Das Entity-Relationship-Modell Print-Version (c) StR S. Winter - Universität Passau Inhaltsverzeichnis 1 Allgemeine Hinweise zum Abschnitt ER-Modell 1.1 Lernziele 1.2 Begriffe 1.3 Vorgehensweise bei der Bearbeitung 1.4 Material 2 Grundlagen des ER-Modells 2.1 Das Entity-Relationship-Modell 2.2 Die Idee des ER-Modells 2.3 Die graphische Darstellung 2.4 Rollennamen 2.5 Der Begriff der Domäne 2.6 Übungen 3 Schlüssel 3.1 Identifizierung von Entities 3.2 Superschlüssel, Schlüsselkandidat, Primärschlüssel 3.3 Übungen 4 Mengenschreibweise von Entity- und Relationship-Typen 4.1 Mengenschreibweise für Entity-Typen 4.2 Mengenschreibweise für Relationship - Typen 5 Relationship-Typen als Teilmengen kartesischer Produkte 5.1 Konkatenation von Entities 5.2 Das kartesische Produkt von Entity-Typen 5.3 Relationship-Typ als Teilmenge eines kartesischen Produkts 5.4 Übungen 6 Funktionalität bei zweistelligen Relationship-Typen 6.1 Funktionalität (Kardinalität) bei 2-stelligen Relationship-Typen 6.2 1:1 - Relationship-Typen 6.3 n:1 - Relationship-Typen 6.4 1:n - Relationship-Typen 6.5 n:m - Relationship-Typen 6.6 Die (min, max) - Notation 6.7 Übungen 7 Mehrstellige Relationship-Typen 7.1 Mehrstellige Relationship-Typen 7.2 Funktionalitäten für mehrstellige Relationship-Typen 7.3 Übungen 8 Generalisierung und Spezialisierung 8.1 Generalisierung 8.2 Spezialisierung 8.3 Die isa-beziehung 8.4 Übungen 9 Schwache Entity-Typen 9.1 Existenzabhängigkeit 9.2 Schwache Entity-Typen

2 9.3 Diskriminator und Schlüssel schwacher Entity-Typen 9.4 Darstellung im ER-Modell 9.5 Mehrfache Abhängigkeiten 9.6 Übungen 10 Der Entwurf eines ER-Modells 10.1 Vorschlag für die Vorgehensweise 10.2 Übungen 1 Allgemeine Hinweise zum Abschnitt ER-Modell Dieser Abschnitt behandelt die Grundlagen des Entity-Relationship-Modell (ER-Modell) sowie den Entwurf eines ER-Modells. 1.1 Lernziele Nach dem Studium dieses Abschnittes sollten Sie Folgendes 1. kennen Grundlagen des ER-Modells Einordnung des ER-Modells innerhalb des Datenbankentwurfes Schlüssel Funktionalität, Kardinalität Prinzip der Generalisierung und Spezialisierung Schwache bzw. existenzabhängige Entity-Typen 2. durchführen können Erstellung eines ER-Modells zu einer vorgegebenen 'Miniwelt' Festlegung eines Primärschlüssels bei den Entity-Typen 1.2 Begriffe Zudem sollten Sie die Bedeutung folgender Begriffe kennen: Entity-Typ, Entity, Relationship-Typ, Relationship, Attribut, Attributwert Superschlüssel, Schlüsselkandidat, Primärschlüssel Funktionalität Generalisierung, Spezialisierung Existenzabhängigkeit, schwacher Entity-Typ, Diskriminator 1.3 Vorgehensweise bei der Bearbeitung Das Material sollte in der vorgegebenen Reihenfolge abgearbeitet werden. 1.4 Material Printversion des Abschnittes " ER-Modell "

3 2 Grundlagen des ER-Modells 2.1 Das Entity-Relationship-Modell Das Entity-Relationship-Modell ist ein Datenmodell, das sich gut zur Darstellung des konzeptuellen Datenbankschemas für relationale Datenbanksysteme eignet. Dazu steht eine standardisierte graphische Notation in Form des Entity-Relationship-Diagramms (ER-Diagramm) zur Verfügung. Sowohl der Vorgang als auch das Resultat der Modellierung wird Entity-Relationship-Entwurf (ER-Entwurf) genannt. Das Resultat der Modellierung wird auch oft - ebenso wie das zugrundeliegende Datenmodell - als Entity-Relationship-Modell (ER-Modell) des Anwendungsbereichs bezeichnet. Vorteil des ER-Entwurfs ist es, dass er systematisch in eine Menge von Relationenschemata überführt werden kann, die die Grundlage für die Tabellen einer relationalen Datenbank bilden. Datenmodelle zur konzeptuellen Modellierung beschreiben nur die Struktur der Daten und verfügen im Allgemeinen nicht über Operatoren zur Datenmanipulation. 2.2 Die Idee des ER-Modells Entity, Relationship, Attribut und Attributwert Das ER-Modell geht davon aus, dass sich die betrachtete Miniwelt durch Objekte (Entities) und Beziehungen zwischen diesen Objekten (Relationships) beschreiben lässt. Entities und Relationships können durch Attribute näher charakterisiert werden. Dabei handelt es sich um Eigenschaften, die für jedes Entity bzw. jede Relationship durch entsprechende Werte, die Attributwerte, konkretisiert werden. Beispiel: In der Miniwelt Schule gibt es beispielsweise die Lehrerin Thatcher, Geburtsjahr 1970, wohnhaft in Berlin. Diese ist Klassenleiterin der Klasse 11, dessen Klassenzimmer die Raumnummer 202 hat. Lehrerin Thatcher und die Klasse 11 sind Objekte. Eine Beziehung zwischen diesen beiden Objekten besteht darin, dass Frau Thatcher die Klassenleitung dieser Klasse hat Entity-Typ, Relationship-Typ, Attribut Ein Entity-Typ fasst eine Menge von gleichartigen Entities, d.h. Entities, die durch gleiche Attribute charakterisiert sind, zusammen. Analog entspricht ein Relationship-Typ einer Menge gleichartiger Relationships. Beispiel: In der Miniwelt Schule könnte sich das folgendermaßen darstellen:

4 1. 2. Entity-Typen müssen nicht disjunkt sein, d.h. im Allgemeinen kann ein Entity Element mehrerer Entity-Typen sein. Relationship-Typen stellen - wie angesprochen - Beziehungen zwischen Entity-Typen her. Die Stelligkeit eines Relationship-Typen gibt an, zwischen wie vielen Entity-Typen eine Beziehung hergestellt wird. Am häufigsten sind 2-stellige Relationship-Typen. 3. Ein Entity-Typ kann natürlich an mehreren Relationship-Typen beteiligt sein. 4. Entity-Typ, Relationship-Typ und Attribut entsprechen der Schemaebene, während Entity, Relationship und Attributwert Instanzen darstellen. 5. Konkrete Entities, Relationships und Attributwerte spielen in der Regel beim ER-Entwurf keine Rolle, weil die Modellierung auf Schemaebene stattfindet. Beispiel: Beispiel zu Bemerkung 1: Die Entity-Typen Lehrkraft und Erziehungsberechtigter sind nicht disjunkt. Eine Lehrkraft kann gleichzeitig Erziehungsberechtige(r) sein. Beispiel zu Bemerkung 3: Eine Lehrkraft kann einerseits eine Klassenführung, andererseits eine Fachbetreuung ausüben. Die Situation kann durch die Entity-Typen Lehrkraft, Klasse und Fach und die Relationship-Typen hat_klassenleitung_in (Beziehung zwischen Lehrkraft und Klasse) und hat_fachbetreuung_in (Beziehung zwischen Lehrkraft und Fach) modelliert werden. Der Entity-Typ Lehrkraft ist an beiden Beziehungen beteiligt. 2.3 Die graphische Darstellung Entity-Typen werden durch Rechtecke, Relationship-Typen durch Rauten und Attribute durch Ovale dargestellt. Der zugehörige Name wird jeweils innerhalb der Figur angegeben. Die Rauten der Relationship-Typen werden mit den beteiligten Entity-Typen durch Kanten verbunden. Die Attribute werden den Entity-Typen ebenfalls durch Kanten zugeordnet. Beispiel: Die graphische Umsetzung des obigen Beispiels hat damit folgende Form:

5 Ist ein Entity-Typ an mehreren Relationship-Typen beteiligt, ist dieser Entity-Typ dementsprechend mit mehreren Relationship-Typen durch Kanten verbunden. Beispiel: Lehrkräfte können sowohl eine Klassenleitung sowie eine Fachbetreuung ausüben. Ein mögliches ER-Modell zeigt folgendes Bild Attribute von Relationship-Typen werden wie Attribute von Entity-Typen grafisch dargestellt. Beispiel: Die Wertigkeit einer Fachbetreuung ist ein Attribut des Relationship-Typen hat_fachbetreuung_in.

6 2.4 Rollennamen Um die durch einen Relationship-Typ verbundenen Entity-Typen genauer charakterisieren zu können, können ihnen Rollennamen zugeordnet werden. Beispiel: Gegeben sei der Entity-Typ Person. Die Beziehung Elternteil - Kind kann durch folgenden Relationship-Typen beschrieben werden: Wie das obige Beispiel zeigt, kann ein Entity-Typ mit sich selbst in Beziehung gesetzt werden. 2.5 Der Begriff der Domäne Entity- bzw. Relationship-Typen werden durch eine geeignete Auswahl von Attributen beschrieben. Die zulässigen Attributwerte werden je Attribut durch eine vorgegebene Wertemenge, die Domäne, festgelegt. Beispiel: Den Attributen des Entity-Typs Lehrkraft können beispielsweise folgende Domänen zugrundeliegen: Attribut Domäne Name STRING PersNr INTEGER > 0 Wohnort STRING Geschlecht {'w', 'm'} Geburtsjahr INTEGER > 1900 Domänen können extensional, d.h. durch Aufzählung aller zulässigen Werte, oder intensional, d.h. durch Angabe allgemein bekannter Mengen, wie INTEGER für ganze Zahlen, STRING für Zeichenreihen usw., die durch Bedingungen, wie INTEGER > 0, modifiziert werden können, definiert sein.

7 Beispiel: Im obigen Beispiel ist die Domäne des Attributs Geschlecht extensional definiert, alle anderen Domänen sind intensional definiert. Die Festlegung der Domänen kann bei der Erstellung des ER-Modells erfolgen. Dies ist vor allem dann notwendig, wenn sich bereits bei der Analyse der Miniwelt spezielle Anforderungen an bestimmte Domänen ergeben. Sehr oft werden die Domänen aber erst bei der Entwicklung des Relationenmodells festgelegt. 2.6 Übungen Welche Entity- und Relationship-Typen sind in der Miniwelt Schule vorstellbar? Entity-Typen: Lehrkraft, Schueler, Klasse, Fach, Raum, Personal,... Relationship-Typen: hat_fachbetreuung_in, hat_lehrbefaehigung_in, hat_stundenplan, ist_fachlehrkraft_von, gehoert_zu_klasse,... Erstellen Sie ein ER-Modell für folgende Situation: Einige Lehrkräfte sind Vorgesetzte der anderen Lehrkräfte. Es ist also möglich, dass an einem Relationship-Typ nur ein einziger Entity-Typ beteiligt ist. Gegeben ist folgende Ausgangssituation: In einer Firma gibt es Arbeitnehmer, die Maschinen bedienen. Außerdem gibt es Arbeitnehmer, die Vorgesetzte sind. (Attribute sollen hier vernachlässigt werden.) Welche Entity- bzw. Relationship-Typen gibt es? Entity-Typen: Arbeitnehmer, Maschinen Relationship-Typen: ist_vorgesetzter_von, bedient Zeichnen Sie das ER-Modell für die Situation.

8 3 Schlüssel 3.1 Identifizierung von Entities Die Wahl der Attribute eines Entity-Typs muss derart erfolgen, dass jedes Entity dieses Entity-Typen eindeutig durch seine Attributwerte identifizierbar ist. Gegebenenfalls müssen weitere Attribute hinzugenommen oder vorhandene Attribute stärker differenziert werden. Sehr oft werden zu diesem Zweck "künstliche" Unterscheidungsmerkmale eingeführt. Beispiel: Für den Entity-Typ Lehrkraft seien folgende zwei Möglichkeiten vorgegeben: Im linken Fall kann es bei der Identifizierung der Entities schnell zu Problemen kommen, da an einer Schule durchaus zwei Lehrkräfte mit identischen Daten bzgl. Name, Wohnort, Geschlecht und Geburtsjahr unterrichten können. Durch Hinzunahme des Attributs PersNr ist aber eine eindeutige Identifizierung möglich. Dabei kann die Identifzierung des Entities grundsätzlich über die Kombination aller ihrer Attributwerte erfolgen. Der Wert des Attributs PersNr alleine ist aber offensichtlich auch ausreichend. 3.2 Superschlüssel, Schlüsselkandidat, Primärschlüssel Obige Überlegung führt zur Unterscheidung von Superschlüssel, Schlüsselkandidat und Primärschlüssel von Entity - Typen. 1. Jede Teilmenge der Attributmenge eines Entitytyps, anhand deren Wertkombination die Entities dieses Typs identifizierbar sind, heißt Superschlüssel dieses Entity-Typs. 2. Ein minimaler Superschlüssel, d.h. ein Superschlüssel mit einer minimalen Menge von Schlüsselattributen, heißt Schlüsselkandidat. Minimale Menge bedeutet dabei, dass aus dieser Menge kein Attribut weggelassen werden kann, ohne die Superschlüsseleigenschaft der Menge zu zerstören. 3. Einer der Schlüsselkandidaten eines Entity-Typs wird beim ER-Entwurf als Primärschlüssel ausgewählt und dient dann zur Identifizierung von Entities. Beispiel: In der Schulverwaltung wird eine Klasse durch die Attribute Name und Klassenzimmer festgelegt. Jede Klasse hat dabei ihr eigenes Klassenzimmer-

9 Superschlüssel: Schlüsselkandidaten: {Name, Klassenzimmer} {Name} {Klassenzimmer} {Name} {Klassenzimmer} Primärschlüssel: je nach Festlegung {Name} oder {Klassenzimmer} Zu einem Entity-Typen kann es mehrere Schlüsselkandidaten geben. Dabei ist es durchaus möglich, dass diese Attributmengen verschieden groß sind. Beispiel: Schüler sind in unserer Schulverwaltung eindeutig durch Angabe des Eintrittsjahres und der laufenen Nummer charakterisiert. Die zweielementige Attributmenge {Eintrittsjahr, Nr} eignet sich daher als Schlüsselkandidat des Entity-Typen Schueler. Führt man zusätzlich für die Schüler Personalnummern ein, so ist die einelementige Menge {PersNr} ebenfalls ein Schlüsselkandidat. Die Wahl der Schlüssel, insbesondere der Primärschlüssel, hängt natürlich auch vom betrachteten Zeitraum oder dem Anwendungsbereich ab. Bei beschränktem Zeitraum bzw. Anwendungsbereich reicht in der Regel oft ein "kleiner" Primärschlüssel, d.h.ein Primärschlüssel, der in einem erweiterten Zeitraum oder Anwendungsbereich die Kriterien eines Superschlüssels nicht erfüllen würde. Beispiel: In dem oben skizzierten Beispiel ist die Wahl des Attributs Name bzw. Klassenzimmer als Primärschlüssel ausreichend, da davon ausgegangen werden kann, dass innerhalb einer Schule der Klassenname bzw. das entsprechende Klassenzimmer nur einmal existiert. Würde die Schulverwaltung aber in eine übergeordnete Schulverwaltung integriert, müsste der Primärschlüssel eventuell neu definiert werden, da dann durchaus zwei Klassen mit gleichem Namen vorkommen können. Statt "Superschlüssel" wird manchmal der Begriff "Schlüssel" verwendet. Oft wird auch der Primärschlüssel einfach als Schlüssel (Key) bezeichnet. Die Entscheidung für einen bestimmten Schlüsselkandidaten als Primärschlüssel geschieht während der Modellierung des Anwendungsbereiches. Im Abschnitt über das Relationenmodell wird ebenfalls auf Schlüssel eingegangen. Primärschlüssel werden im ER-Modell durch Unterstreichung gekennzeichnet. 3.3 Übungen Welche künstlichen Unterscheidungsmerkmale kennen Sie aus dem täglichen Leben?

10 Ausweisnummern Bestellnummern Bankleitzahlen Kontonummern usw. Firmenmitarbeiter werden durch den Entity-Typ Angestellte mit den Attributen PersNr, Name und Einkommen dargestellt. Welche Superschlüssel und Schlüsselkandidaten gibt es? Superschlüssel: {PersNr, Name, Einkommen}, {PersNr, Name}, {PersNr, Einkommen}, {PersNr} Schlüsselkandidaten: {PersNr} Betrachten Sie zu dem Entitytyp Professordie folgenden möglichen Attribute:Vorname, Name, Fachgebiet, Status, Zimmer, Telefon und PersNr. Welche Schlüssel sind im Folgenden angegeben? {Name, Telefon} Superschlüssel, da die Zuordnung Telefon - Professor eindeutig ist. {Zimmer} Superschlüssel, Schlüsselkandidat, eventuell Primärschlüssel. (Jede Professorin bzw. jeder Professor hat ein eigenes Büro) {Name, Vorname} kein Schlüssel, da Professoren mit gleichem Vornamen und Namen existieren können. Wie stellt sich für die drei vorgegebenen Attributmengen die Situation bzgl. der Schlüssel dar, wenn nicht nur die

11 Professorenschaft einer Hochschule, sondern die Professorenschaft eines Landes betrachtet wird? {Name, Telefon} bleibt ein Superschlüssel, da eine Telefonnummer landesweit nur einmal vergeben wird. Das Attribut Zimmer ist weder Schlüsselkandidat noch Superschlüssel, da nicht auszuschließen ist, dass es an verschiedene Hochschulen gleiche Zimmernummern gibt. {Name, Vorname} ist kein Schlüssel, da es aufgrund der erweiterten Anzahl der Professoren sehr wahrscheinlich ist, dass Hochschullehrer mit identischem Namen und Vornamen existieren. 4 Mengenschreibweise von Entity- und Relationship-Typen Die ER-Entwurf ist auf der Schema-Ebene angesiedelt. Zur Angabe der Instanz eines Entity- bzw. Relationship-Typen nutzt man die Mengenschreibweise. 4.1 Mengenschreibweise für Entity-Typen Ein Entity-Typ E ist eine Menge von Entities e 1 bis e n, es gilt also E = { e 1,..., e n }. Ein konkretes Entity wird durch die Liste der zugehörigen Attribut - Wert - Paare repräsentiert. Beispiel: Für der Entitytyp Lehrkraft gilt: Lehrkraft = { l 1,..., l 7 } mit l 1 = ((PersNr: 566), (Name: Schumann), (Geschlecht: w), (Wohnort: Passau), (Geburtsjahr: 1959)) l 2 = ((PersNr: 15), (Name: Neumann), (Geschlecht: m), (Wohnort: Passau), (Geburtsjahr: 1950)) l 3 = ((PersNr: 35), (Name: Rinser), (Geschlecht: w), (Wohnort: Passau), (Geburtsjahr: 1946)) l 4 = ((PersNr: 73), (Name: Zuse), (Geschlecht: m), (Wohnort: München), (Geburtsjahr: 1936)) l 5 = ((PersNr: 245), (Name: Gauß), (Geschlecht: m), (Wohnort: Passau), (Geburtsjahr: 1925)) l 6 = ((PersNr: 356), (Name: Thatcher), (Geschlecht: w), (Wohnort: Berlin), (Geburtsjahr: 1970)) l 7 = ((PersNr: 1344), (Name: Graf), (Geschlecht: w), (Wohnort: Berlin), (Geburtsjahr: 1957)) Für den Entity-Typ Klasse gilt: Klasse = { k 1, k 2 } mit k 1 = ((Name: 11), (Klassenzimmer: 202)) k 2 = ((Name: 5), (Klassenzimmer: 101)) 4.2 Mengenschreibweise für Relationship - Typen Ebenso können Relationship-Typen durch Mengen dargestellt werden. Die Relationships werden dabei durch Auflistung der Attribute und Attributwerte aller beteiligten Entities beschrieben. Beispiel: Die Relationship hat_klassenleitung_in stellt eine Beziehung zwischen den Entity-Typen Lehrkraft und Klasse her.

12 Die Mengenschreibweise von Relationship-Typ ist zum Verständnis der (min, max) - Notation notwendig. 5 Relationship-Typen als Teilmengen kartesischer Produkte Relationship-Typen sind Mengen von Relationships. Relationships wiederum können als eine kombinierte Liste aller Attribut-Werte-Paare der beteiligten Entities dargestellt werden. Mathematisch kann damit ein Relationship-Typ als Teilmenge des kartesischen Produktes der beteiligten Entity-Typen gesehen werden. 5.1 Konkatenation von Entities Eine Kombination von Entities wird über den Begriff der Konkatenation definiert. Definition: Konkatenation von Entities Die Konkatenation e 1 * e 2 zweier Entities e 1 und e 2 ist die Liste der Attribut-Wert-Paare, die durch Hintereinanderschreiben der entsprechenden Listen für e 1 und e 2 entsteht. Beispiel: Für l 2 = ((PersNr: 15), (Name: Neumann), (Geschlecht: m), (Wohnort: Passau), (Geburtsjahr: 1950)) und k 2 = ((Name: 5), (Klassenzimmer: 101)) ergibt die Konkatenation l 2 * k 2 = ((PersNr: 15), (Name: Neumann), (Geschlecht: m), (Wohnort: Passau), (Geburtsjahr: 1950), (Name: 5), (Klassenzimmer: 101)) Die Konkatenation entspricht der Beziehung Lehrkraft Neumann hat die Klassenleitung der Klasse 5, ist damit also als Relationship des Relationship-Typen hat_klassenleitung_in interpretierbar. Analog wird die Konkatenation e 1 *... * e n mehrerer Entities definiert. 5.2 Das kartesische Produkt von Entity-Typen Die Menge aller Konkatenationen der Entities zweier Entity-Typen E 1 und E 2 wird über das kartesische Produkt E 1 x E 2 beschrieben. Definition: Kartesisches Produkt von Entities Das kartesische Produkt E 1 x E 2 zweier Entity-Typen E 1 und E 2 ist definiert als die Menge aller möglichen Konkatenationen ihrer Elemente: E 1 x E 2 = { e 1 * e 2 e 1 E 1 und e 2 E 2 } Analog wird das kartesische Produkt E 1 x... x E n mehrerer Entity-Typen definiert. Beispiel:

13 Die Menge enthält alle möglichen Kombinationen der Entity-Typen Lehrkraft und Klasse. Anders ausgedrückt sind dies alle (theoretisch) möglichen Relationships des Relationship-Typen hat_klassenleitung_in. Das kartesische Produkt der beteiligten Entity-Typen bildet also den Elementevorrat für den jeweiligen Relationship-Typen. 5.3 Relationship-Typ als Teilmenge eines kartesischen Produkts Jeder Relationship-Typ R zwischen gegebenen Entity-Typen E 1,..., E k kann als eine Teilmenge des kartesischen Produkts E 1 x... x E k aufgefasst werden, d.h. Bei k beteiligten Entity-Typen heißt R k-stellig. Beispiel: R E 1 x... x E k. Der Relationship-Typ hat_klassenleitung_in ist 2-stellig. 5.4 Übungen In einer Firma gibt es Angestellte, die Projekte bearbeiten. Angestellte sind Müller mit der PersNr. 3 und Meier mit der PersNr. 7. Müller ist am Projekt 'Datenbanksysteme' beteiligt, Meier ist Mitarbeiter in den Projekten 'Datenbanksysteme' und 'Softwareentwicklung'. Geben Sie ein geeignetes ER-Diagramm an. Die Einführung der Projektnummer ermöglicht die eindeutige Indentifizierung der Projekte. Ist die Namensgebung der Projekte eindeutig, kann auch der Projektname als Primärschlüssel verwendet werden.

14 Geben Sie das kartesische Produkt Angestellter x Projekt an. Angestellter x Projekt = { ((PersNr: 3), (Name: Müller), (ProNr: 1), (Name: Datenbanksysteme)), ((PersNr: 3), (Name: Müller), (ProNr: 2), (Name: Softwareentwicklung)),((PersNr: 7), (Name: Meier), (ProNr: 1), (Name: Datenbanksysteme)), ((PersNr: 7), (Name: Meier), (ProNr: 2), (Name: Softwareentwicklung)) } Geben Sie eine geeignete Teilmenge dieses kartesischen Produkts an, die die in der Aufgabenstellung gegebene Situation beschreibt. Die Relationship bearbeitet kann als Teilmenge des kart. Produktes interpretiert werden: bearbeitet = { ((PersNr: 3), (Name: Müller), (ProNr: 1), (Name: Datenbanksysteme)), ((PersNr: 7), (Name: Meier), (ProNr: 1), (Name: Datenbanksysteme)), ((PersNr: 7), (Name: Meier), (ProNr: 2), (Name: Softwareentwicklung)) } 6 Funktionalität bei zweistelligen Relationship-Typen 6.1 Funktionalität (Kardinalität) bei 2-stelligen Relationship-Typen Ein wichtiges Charakteristikum von 2-stelligen Relationship-Typen ist ihre Funktionalität oder Kardinalität. Dadurch wird zum Ausdruck gebracht, mit wie vielen Entities ein gegebenes Entity in Beziehung stehen kann. Die Funktionalität muss beim Datenbankentwurf durch die Analyse der Rahmenbedingungen erkannt werden. Man unterscheidet die Funktionalitäten 1:1, n:1, 1:n und n:m und spricht dementsprechend von 1:1 - Relationship-Typen oder 1:1 - Beziehungen n:1 - Relationship-Typen oder n:1 - Beziehungen 1:n - Relationship-Typen oder 1:n - Beziehungen n:m - Relationship-Typen oder n:m - Beziehungen Beim ER-Modell wird die Funktionalität durch entsprechende Angabe von 1, n oder m an den grau unterlegten Stellen angegeben. Das ER-Diagramm ist folgendermaßen zu lesen: Einem Entity aus E 1 können höchstens y Entities aus E 2 zugeordnet werden bzw. Einem Entity aus E 2 können höchstens x Entities aus E 1 zugeordnet werden. x bzw. y wird mit '1' oder mit einem Buchstaben, meistens 'n' oder 'm', belegt. Dabei symbolisiert '1' höchstens eine Beziehung und 'n' bzw 'm' beliebig viele, d.h. keine, eine oder mehrere Beziehungen.

15 Ausgehend von der Mengenschreibweise für Relationship-Typen kann man die obige Beziehung auch folgendermaßen interpretieren: Der Relationship-Typ R enthält maximal y Tupel mit einem Entity des Entity-Typen E 1 bzw. maximal x Tupel mit einem Entity des Entity-Typen E 2. Die Lesart dieser Funktionalitätsdarstellung wird in der Literatur unterschiedlich gehandhabt. Man findet oft auch die umgekehrte Interpretation: Einem Entity aus E 1 werden höchstens x Entities aus E 2 zugeordnet bzw. einem Entity aus E 2 werden höchstens y Entities aus E 1 zugeordnet. Hier ist auf jeweilige Notation der jeweiligen Autors zu achten. In der Literatur findet sich auch eine graphische Darstellungsmöglichkeit für Funktionalitäten mit Hilfe von Pfeilen :1 - Relationship-Typen Ein 2-stelliger Relationship R zwischen den Entity-Typen E 1 und E 2 hat die Funktionalität 1:1, falls ein Entity aus E 1 mit höchstens einem Entity aus E 2 über R in Beziehung stehen kann und umgekehrt. R heißt dann 1:1 - Relationship-Typ. Definition: 1:1-Funktionalität Seien E 1, E 2 Entity-Typen und R E 1 x E 2 ein Relationship-Typ. Weiterhin seien x und x' Entities von E 1 und y und y' Entities von E 2. R ist ein 1:1 - Relationship-Typ, falls gilt: und ( x, y ) R und ( x, y' ) R y = y' ( x, y ) R und ( x', y ) R x = x'. Beispiel: Der Relationship-Typ hat_klassenleitung_in ist ein 1:1-Relationship-Typ, denn jede Klasse hat genau eine Lehrkraft als Klassenleitung und jede Lehrkraft hat höchstens eine Klassenleitung. Als alternative graphische Darstellung der 1:1 Funktionalität findet man auch folgende Pfeildarstellung: 6.3 n:1 - Relationship-Typen Ein 2-stelliger Relationship R zwischen den Entity-Typen E 1 und E 2 hat die Funktionalität 1:n, falls ein Entity aus E 1 mit höchstens einem Entity aus E 2, aber ein Entity aus E 2 mit beliebig vielen Entities aus E 1 über R in Beziehung

16 stehen kann. R heißt dann n:1 - Relationship-Typ. Definition: n:1-funktionalität Seien E 1, E 2 Entity-Typen und R E 1 x E 2 ein Relationship-Typ. Weiterhin seien x ein Entity von E 1 und y und y' Entities von E 2.R ist ein n:1 - Relationship-Typ, falls gilt: ( x, y ) R und ( x, y' ) R y = y' Beispiel: Der Relationship-Typ gehoert_zu ist ein n:1-relationship-typ, d.h. gehoert_zu hat die Funktionalität n:1. Ein Schüler gehört zu genau einer Klasse, zu einer Klasse gehören aber mehrere Schüler. Als alternative graphische Darstellung der n:1 Funktionalität findet man auch folgende Pfeildarstellung: 6.4 1:n - Relationship-Typen Ein n:1 - Relationship-Typ R zwischen E 1 und E 2 ist ein 1:n - Relationship-Typ zwischen E 2 und E 1. Damit gilt Analoges zum vorherigen Abschnitt. 6.5 n:m - Relationship-Typen Ein 2-stelliger Relationship R zwischen den Entity-Typen E 1 und E 2 hat die Funktionalität n:m, falls ein Entity aus E 1 mit beliebig vielen Entities aus E 2 über R in Beziehung stehen kann und umgekehrt. Es gelten also keine Einschränkungen. R heißt dann n:m - Relationship-Typ. Beispiel: Der Relationship-Typ hat_lehrbefaehigung_in ist ein n : m-relationship-typ, d.h. hat_lehrbefaehigung_in hat die Funktionalität n:m.

17 Graphisch wird die n:m - Funktionalität wie folgt dargestellt: 6.6 Die (min, max) - Notation Bei der Verwendung der Funktionalität ist für einen Entity-Typen nur die maximale Anzahl der Beziehungen mit einem Relationship-Typen relevant. Falls diese Anzahl größer als eins ist, wird sie, ohne genauere Aussagen zu machen, als n oder m (d.h. beliebig viele) gesetzt. Die (min, max) - Notation erlaubt die Festlegung präziser Unter- und Obergrenzen. Damit kann also - im Gegensatz zur 1:1, 1:n oder n:m - Notation - auch die minimale Anzahl der Beziehungen festgelegt werden. Dazu wird für jeden an der Relationship-Typ R beteiligten Entity-Typ E i ein Zahlenpaar (min, max) angegeben. Damit wird ausgedrückt, dass jedes Entity von E i mindestens min-mal und höchstens max-mal in der Beziehung R steht. Im ER-Modell wird die (min, max) - Notation folgendermaßen verwendet: Beachten Sie beim ER-Modell die unterschiedliche Platzierung der Funktionalitätsangaben in der x:y-notation und der (min, max) - Notation. Oft kann die Obergrenze nicht festgelegt werden. In diesem Fall ersetzt man max durch einen Stern. Ein Relationship-Typ R kann als Menge von Tupeln aufgefasst werden, die aus den Entities der beteiligten Tupel aufgebaut werden. Die Markierung (min, max) bei einem Entity-Typen E gibt an, dass es mindestens min und höchstens max Tupel mit einem Entity von E gibt. Beispiel: Ein Fach (Wahl- oder Pflichtfach) hat 0 bis 2 Fachbetreuer. Theoretisch darf eine Lehrkraft beliebig viele Fachbetreuungen übernehmen. (Natürlich muss der Fachbetreuer immer die entsprechende Lehrbefähigung besitzen.) Diese Situation kann im ER-Modell mit Hilfe der (min, max)-notation folgendermaßen dargestellt werden:

18 (Aus Übersichtlichkeitsgründen wird bei den Entity-Typen jeweils nur ein Attribut verwendet.) Betrachtet man die Situation aus der Sicht der Mengenschreibweise für Relationship-Typen, so lässt sich die angegebene (min, max) - Funktionalität folgendermaßen interpretieren: Der Relationship-Typ hat_fachbetreuung_in enthält Tupel, deren erste Komponente die Personalnummer der Lehrkraft und deren zweite Komponente den Fachnamen enthält. Wegen (0,2) darf es maximal zwei Tupel mit gleichem Fachnamen geben, wegen (0,*) aber beliebig viele Tupel mit gleichem Personalnummerwert. Ohne Verwendung der (min,max)-notation wäre die Funktionalität weniger aussagekräftig: 6.7 Übungen Geben Sie die Funktionalität folgender Relationship-Typen an: 1. Mitarbeiter gehoert_zu Abteilung 2. Mitarbeiter arbeitet_in Projekt 3. Mitarbeiter ist_abteilungsleiter_von Abteilung n:1, denn ein Mitarbeiter gehört zu höchstens einer Abteilung, zu einer Abteilung gehören aber mehrere Mitarbeiter. n:m, denn Mitarbeiter können in mehreren Projekten gleichzeitig arbeiten, ein Projekt wird in der Regel von mehr als einem Mitarbeiter durchgeführt. 1:1, denn eine Abteilung hat genau eine Abteilungsleiterin bzw. einen Abteilungsleiter Eine Schülerin hat viele CDs, die sie auch an Freunde ausleiht. Damit sie immer weiß, wem sie welchen Tonträger gegeben hat, möchte sie ein Datenbanksystem einsetzen. Geben Sie möglich Entity- und Relationship-Typen an. Entity-Typ: CD, Freund Relationship-Typ: ausgeliehen_an

19 Geben Sie die Funktionalität (x:y-notation) für die in der vorherigen Aufgabe gewählten Relationship-Typen an? ausgeliehen_an: n:1, denn ein Tonträger kann nur einmal ausgeliehen werden, ein Freund kann aber mehrere CDs gleichzeitig ausleihen. Zeichnen Sie ein entsprechendes ER-Diagramm! (Attribute können vernachlässigt werden.) Flüsse können in einem Meer münden. Erstellen Sie ein ER-Modell und geben Sie die Funktionalität in (x:y) und (min, max)-notation an. Es gilt: Ein Fluss mündet maximal in ein Meer. In ein Meer mündet mindestens ein Fluss, in der Regel aber mehrere Flüsse. Angabe der Funktionalität Angabe der (min, max) - Notation 7 Mehrstellige Relationship-Typen 7.1 Mehrstellige Relationship-Typen Ein Relationship-Typ R ist eine Teilmenge des kartesisches Produkts der beteiligten Entity-Typen. Sind am Relationship-Typ mehr als zwei Entity-Typen beteiligt, spricht man von mehrstelligen Relationship-Typen. Für einen n-stelligen Relationship-Typ gilt: R E 1 x... x E n Dreistellige Relationship-Typen kommen bei ER-Modellierungen noch häufig vor, höherstellige Beziehungen findet man dagegen selten.

20 Beispiel: Im Schulverwaltungsbeispiel gibt es den dreistelligen Relationship-Typ ist_fachlehrkraft_von. Dadurch wird eine Beziehung zwischen den Entity-Typen Lehrkraft, Fach und Klasse modelliert. Das ER-Modell hat folgende Gestalt: Es gilt: ist_fachlehrkraft_von Lehrkraft x Klasse x Fach. Unter Beteiligung der Entities ((PersNr: 35), (Name: Rinser), (Geschlecht: w), (Wohnort: Passau), (Geburtsjahr: 1946)) Lehrkraft, ((Name: 5), (Klassenzimmer: 101)) Klasse und ((Name: Deutsch), (Pflichtfach: ja)) Fach gibt es die Relationship ((PersNr: 35), (Name: Rinser), (Geschlecht: w), (Wohnort: Passau), (Geburtsjahr: 1946), (Name: 5), (Klassenzimmer: 101),(Name: Deutsch), (Pflichtfach: ja)) ist_fachlehrkraft_von. Dadurch wird ausgedrückt, dass Frau Rinser die Klasse 5 im Fach Deutsch unterrichtet. 7.2 Funktionalitäten für mehrstellige Relationship-Typen Die Begriff der Funktionalität kann auch auf mehrstellige Beziehungen R E 1 x... x E n übertragen und erweitert werden. Bei mehrstelligen Relationship-Typen wird damit zum Ausdruck gebracht, mit wie vielen Entities e i des Entity-Typen E i das Entity-Tupel (e 1,..., e i - 1, e i + 1,..., e n ) mit e 1 E 1,...,e n E n in Beziehung steht. Der Relationship-Typ wird im ER-Modell wieder entsprechend annotiert. Der Wert "1" symbolisiert wieder höchstens eine Zuordnung und ein Buchstabe beliebig viele Zuordnungen. Für den dreistelligen Relationship-Typen R E 1 x E 2 x E 3 bedeutet dies konkret: Einem Tupel (e 1, e 2 ) mit e 1 aus E 1 und e 2 aus E 2 werden höchstens z Entities e 3 aus E 3 zugeordnet. Einem Tupel (e 1, e 3 ) mit e 1 aus E 1 und e 3 aus E 3 werden höchstens y Entities e 2 aus E 2 zugeordnet. Einem Tupel (e 2, e 3 ) mit e 2 aus E 3 und e 3 aus E 3 werden höchstens x Entities e 1 aus E 1 zugeordnet. R hat damit die Funktionalität x:y:z Beispiel: Die Relationship hat_lehrbefaehigung_in hat die Funktionalität 1:n:m.

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

02: Entity-Relationship-Modelle

02: Entity-Relationship-Modelle Lehrstuhl für Angewandte Informatik IV Prof. Dr.-Ing. Stefan Jablonski Datenbanken und Informationssysteme I 02: Entity-Relationship-Modelle Prof. Dr.-Ing. Stefan Jablonski Telefon: +49 921-55 7620 Fax:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ü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

Datenbanksysteme I ER Modellierung. 23.4.2009 Felix Naumann

Datenbanksysteme I ER Modellierung. 23.4.2009 Felix Naumann Datenbanksysteme I ER Modellierung 23.4.2009 Felix Naumann Überblick 2 Motivation und Einbettung Begriffe und Definitionen ER-Diagramme Modellierung von Nebenbedingungen Schwache Entitytypen Erweitertes

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

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

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

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

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

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

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

Ü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

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

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

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

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

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

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

Ü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

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

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

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

Kapitel 12: Datenmodellierung mit ERM und UML

Kapitel 12: Datenmodellierung mit ERM und UML Kapitel 12: Datenmodellierung mit ERM und UML Ziel der Datenmodellierung (des konzeptionellen Datenbankentwurfs): Modellierung von Sachverhalten der realen Welt mittels weniger Grundkonzepte mit dem Zweck,

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

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

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

7. Analyse-Phase: Datenmodellierung Software Engineering

7. Analyse-Phase: Datenmodellierung Software Engineering 7. Analyse-Phase: Datenmodellierung Software Engineering Hochschule Darmstadt Haardtring 100 D-64295 Darmstadt Prof. Dr. Bernhard Humm Hochschule Darmstadt, 20. November 2006 Einordnung in den Kontext

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

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

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

https://webct.net.ethz.ch/script/dbsyst/scripts/student/serve_quiz_marked.pl?do_g...

https://webct.net.ethz.ch/script/dbsyst/scripts/student/serve_quiz_marked.pl?do_g... Seite 1 von 5 View Results Übung 3 User ID: unizh.ch_scherrer_larissa_733033363031363501 Attempt: 1 / 1 Out of: 16 Started: May 31, 2006 20:43 Finished: June 6, 2006 15:04 Time spent: 138 hr, 20 min.,

Mehr

Hochschule Darmstadt Darmstadt, den 04.02.08. KLAUSUR zur Lehrveranstaltung "Datenbanken für FB MN"

Hochschule Darmstadt Darmstadt, den 04.02.08. KLAUSUR zur Lehrveranstaltung Datenbanken für FB MN Hochschule Darmstadt Darmstadt, den 04.02.08 Fachbereich Informatik Klausur-DB-MN-WS07/08 - Prof. Dr. Wolfgang Weber - Teilnehmer(in) Name: Vorname: Matrikel-Nr: KLAUSUR zur Lehrveranstaltung "Datenbanken

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

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

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

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

Modellierung in Geoinformationssystemen für Relationale DB-Systeme

Modellierung in Geoinformationssystemen für Relationale DB-Systeme Geodätische Woche 1. - 17. Oktober 1998 an der Universität Kaiserslautern Modellierung in Geoinformationssystemen für Relationale DB-Systeme Hosse, Karin, Dipl.-Ing. und Roschlaub, Robert, Dipl.-Ing. Technische

Mehr

6.2 Petri-Netze. kommunizierenden Prozessen in der Realität oder in Rechnern Verhalten von Hardware-Komponenten Geschäftsabläufe Spielpläne

6.2 Petri-Netze. kommunizierenden Prozessen in der Realität oder in Rechnern Verhalten von Hardware-Komponenten Geschäftsabläufe Spielpläne 6.2 Petri-Netze WS 06/07 mod 621 Petri-Netz (auch Stellen-/Transitions-Netz): Formaler Kalkül zur Modellierung von Abläufen mit nebenläufigen Prozessen und kausalen Beziehungen Basiert auf bipartiten gerichteten

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

Kapitel 7: Formaler Datenbankentwurf

Kapitel 7: Formaler Datenbankentwurf 7. Formaler Datenbankentwurf Seite 1 Kapitel 7: Formaler Datenbankentwurf Die Schwierigkeiten der konzeptuellen Modellierung sind zu einem großen Teil dadurch begründet, dass sich die relevanten Strukturen

Mehr

A.1 Schaltfunktionen und Schaltnetze

A.1 Schaltfunktionen und Schaltnetze Schaltfunktionen und Schaltnetze A. Schaltfunktionen und Schaltnetze 22 Prof. Dr. Rainer Manthey Informatik II Bedeutung des Binärsystems für den Rechneraufbau Seit Beginn der Entwicklung von Computerhardware

Mehr

10.1 Abbildung von Anwendungsobjekten auf Datenbankobjekte in ERP-Systemen 10.2 Workshop: Datenmodell, Metadaten, & Abbildung auf RDBMS in SAP R/3

10.1 Abbildung von Anwendungsobjekten auf Datenbankobjekte in ERP-Systemen 10.2 Workshop: Datenmodell, Metadaten, & Abbildung auf RDBMS in SAP R/3 Kap.10 ERP: Datenmodellierung und verwaltung 10.1 Abbildung von Anwendungsobjekten auf Datenbankobjekte in ERP-Systemen 10.2 Workshop: Datenmodell, Metadaten, & Abbildung auf RDBMS in SAP R/3 Objektverwaltung

Mehr

SWT MN Vorlesung 19.04.2006 2. Übungsblatt Hausaufgaben und Hörsaalübungen zum Themenbereich UML-Modellierung mit Rollen und OOA-Muster

SWT MN Vorlesung 19.04.2006 2. Übungsblatt Hausaufgaben und Hörsaalübungen zum Themenbereich UML-Modellierung mit Rollen und OOA-Muster SWT MN Vorlesung 19.04.2006 2. Übungsblatt Hausaufgaben und Hörsaalübungen zum Themenbereich UML-Modellierung mit Rollen und OOA-Muster Aufgabe 1 analytische Aufgabe Die Eigenschaften und Einsatzbereiche

Mehr

Grundlagen Programmierung

Grundlagen Programmierung 1. Aufgabe (Spielen mit Objekten) Gegeben sei der auch von der Veranstaltungsseite erhältliche Programmcode auf der rechten Seite, der im Detail zuerst nicht verstanden werden muss. a) Erzeugen Sie sich

Mehr

Relationale Datenbanksysteme

Relationale Datenbanksysteme MultiAugustinum E2A/E3A SQL Relationale Datenbanksysteme Mag. Christian Gürtler 2011 Inhaltsverzeichnis I. Allgemeines 5 1. Vergleich Datenbankysteme Dateisystem 7 2. Architektur eines DBMS 11 2.1. Konkrete

Mehr

Datenbanken / Datenbankmanagementsystem

Datenbanken / Datenbankmanagementsystem Datenbanken / Datenbankmanagementsystem 1.Einführung Daten, Informationen; Datenbank, Datenbanksystem; Relationale Datenbanksysteme; Beispiel Access 2.Aufbau von Datenbanken Datenanalyse; Entitäten-Beziehungsmodell;

Mehr

Formaler Entwurf mit Event-B Die Eventbank

Formaler Entwurf mit Event-B Die Eventbank Institut für Theoretische Informatik Anwendungsorientierte Formale Verifikation Vorlesung Anwendung Formaler Verifikation SS 2015, 9.6.15 Dr. V. Klebanov, Dr. M. Ulbrich Formaler Entwurf mit Event-B Die

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

Objektorientierte Programmierung mit Python Polymorphismus und Vererbung. Eltern

Objektorientierte Programmierung mit Python Polymorphismus und Vererbung. Eltern Objektorientierte Programmierung mit Python Polymorphismus und Vererbung Eltern Kind Kind Kind Kind Prinzipien der objektorientierten Programmierung Vererbung Strukturierung von Klassen. Oberbegriffe beschreiben

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

Objektorientierter Softwareentwurf mit UML. Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010. Grundlagen. Neubearbeitung 2010

Objektorientierter Softwareentwurf mit UML. Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010. Grundlagen. Neubearbeitung 2010 Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010 Objektorientierter Softwareentwurf mit UML Grundlagen Neubearbeitung 2010 PGOS2010 I Objektorientierter Softwareentwurf mit UML - Grundlagen

Mehr

Vorlesung. Funktionen/Abbildungen 1

Vorlesung. Funktionen/Abbildungen 1 Vorlesung Funktionen/Abbildungen 1 1 Grundlagen Hinweis: In dieser Vorlesung werden Funktionen und Abbildungen synonym verwendet. In der Schule wird eine Funktion häufig als eindeutige Zuordnung definiert.

Mehr

2 Datenbanksysteme. 2.1 Grundlegende Begriffe. Datenbank Management System. Schemata und Instanzen

2 Datenbanksysteme. 2.1 Grundlegende Begriffe. Datenbank Management System. Schemata und Instanzen 2 Datenbanksysteme Im Folgenden werden wir einige grundlegende Eigenschaften von Datenbanksystemen kennen lernen Datenbanken sind Bestandteil vieler Anwendungssysteme; sie stellen die dort benötigten Daten

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

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER INHALTSVERZEICHNIS 1. Datenbanken 2. SQL 1.1 Sinn und Zweck 1.2 Definition 1.3 Modelle 1.4 Relationales Datenbankmodell 2.1 Definition 2.2 Befehle 3.

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

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

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

OO Softwareentwicklung

OO Softwareentwicklung OO Softwareentwicklung Objektorientierung Prof. Dr. Bernhard Schiefer 1 OO als Ansatz zur Verbesserung der Software-Qualität Modellierung der Welt als selbständig agierende Objekte. Gemeinsame Beschreibung

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

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

Klausur Software-Engineering WS 2006 / 2007 Iwanowski 16.02.2007

Klausur Software-Engineering WS 2006 / 2007 Iwanowski 16.02.2007 Klausur Software-Engineering WS 2006 / 2007 Iwanowski 16.02.2007 Hinweise: Bearbeitungszeit: 90 Minuten Erlaubte Hilfsmittel: keine Bitte notieren Sie Ihre Antworten ausschließlich auf dem Aufgabenblatt!

Mehr

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten Einführung in SQL Die Sprache SQL (Structured Query Language) ist eine Programmiersprache für relationale Datenbanksysteme, die auf dem ANSI-SQL-Standard beruht. SQL wird heute von fast jedem Datenbanksystem

Mehr

w a is die Anzahl der Vorkommen von a in w Beispiel: abba a = 2

w a is die Anzahl der Vorkommen von a in w Beispiel: abba a = 2 1 2 Notation für Wörter Grundlagen der Theoretischen Informatik Till Mossakowski Fakultät für Informatik Otto-von-Guericke Universität Magdeburg w a is die Anzahl der Vorkommen von a in w Beispiel: abba

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

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

DTD: Syntax-Zusammenfassung

DTD: Syntax-Zusammenfassung DTD: Syntax-Zusammenfassung Dokumenttyp-Deklarationen Interne Teilmenge ]> Externe

Mehr

Einführung Datenbank

Einführung Datenbank Einführung Datenbank Einführung Datenbank Seite 2 Einführung in die Arbeit mit einer Datenbank Grundbegriffe: Datenbank - Datenbankmanagementsystem Eine Datenbank ist eine systematische strukturierte Sammlung

Mehr

Grundlagen der Datenbanken

Grundlagen der Datenbanken Grundlagen der Datenbanken Sommersemester 1995/96 Christoph Kreitz FG Intellektik, TH Darmstadt, Telephon (06151) 16-2863 kreitz@intellektik.informatik.th-darmstadt.de 1. Einführung: Datenbanksysteme:

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

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 9 17. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Beispiellektionen. Geometrische Grundformen. Gestaltung und Musik. Fach. Klasse. Ziele Soziale Ziele

Beispiellektionen. Geometrische Grundformen. Gestaltung und Musik. Fach. Klasse. Ziele Soziale Ziele Geometrische Grundformen Fach Gestaltung und Musik Klasse 1 2 3 4 5 6 7 8 9 Ziele Soziale Ziele Gemeinsam ein Bild aus einfachen geometrischen Formen entstehen lassen. Inhaltliche Ziele Geometrische Formen

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

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

Klausur zur Vorlesung Datenbanken I im Wintersemester 2011/12

Klausur zur Vorlesung Datenbanken I im Wintersemester 2011/12 Prof. Dr. Lutz Wegner, Dipl.-Math. Kai Schweinsberg 21.03.2012 Klausur zur Vorlesung Datenbanken I im Wintersemester 2011/12 Name:... Vorname:... Matr.Nr.:... Studiengang:... Hinweis: Bearbeiten Sie alle

Mehr

OPERATIONS-RESEARCH (OR)

OPERATIONS-RESEARCH (OR) OPERATIONS-RESEARCH (OR) Man versteht darunter die Anwendung mathematischer Methoden und Modelle zur Vorbereitung optimaler Entscheidungen bei einem Unternehmen. Andere deutsche und englische Bezeichnungen:

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

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22 Kapitel 19 Vererbung, UML Seite 1 von 22 Vererbung - Neben der Datenabstraktion und der Datenkapselung ist die Vererbung ein weiteres Merkmal der OOP. - Durch Vererbung werden die Methoden und die Eigenschaften

Mehr

Datenbanksysteme. Vorlesung im SS 2001. [Version vom 23. August 2001] achte, überarbeitete Auflage

Datenbanksysteme. Vorlesung im SS 2001. [Version vom 23. August 2001] achte, überarbeitete Auflage Datenbanksysteme Vorlesung im SS 2001 [Version vom 23. August 2001] achte, überarbeitete Auflage Oliver Vornberger Olaf Müller Fachbereich Mathematik/Informatik Universität Osnabrück 2 Literatur Date,

Mehr

x 2 2x + = 3 + Es gibt genau ein x R mit ax + b = 0, denn es gilt

x 2 2x + = 3 + Es gibt genau ein x R mit ax + b = 0, denn es gilt - 17 - Die Frage ist hier also: Für welche x R gilt x = x + 1? Das ist eine quadratische Gleichung für x. Es gilt x = x + 1 x x 3 = 0, und man kann quadratische Ergänzung machen:... ( ) ( ) x x + = 3 +

Mehr

1 Grundbegriffe...1. 2 Datenbanksysteme...7. 3 Entwicklung von Datenbanksystemen...15. Inhaltsverzeichnis. 1.1 Information und Daten...

1 Grundbegriffe...1. 2 Datenbanksysteme...7. 3 Entwicklung von Datenbanksystemen...15. Inhaltsverzeichnis. 1.1 Information und Daten... Inhaltsverzeichnis 1 Grundbegriffe...1 1.1 Information und Daten...2 1.2 Datenorganisation...3 1.3 Dateikonzept...5 1.4 Kontroll- und Vertiefungsfragen...6 2 Datenbanksysteme...7 2.1 Datenintegration...7

Mehr

1 Aussagenlogik und Mengenlehre

1 Aussagenlogik und Mengenlehre 1 Aussagenlogik und engenlehre 1.1 engenlehre Definition (Georg Cantor): nter einer enge verstehen wir jede Zusammenfassung von bestimmten wohl unterschiedenen Objekten (m) unserer Anschauung oder unseres

Mehr