2.4 Erweiterungen des E/R-Modells. Erweiterung von Entitätstypen - Weak Entity Type
|
|
|
- Martha Gärtner
- vor 6 Jahren
- Abrufe
Transkript
1 2.4 Erweiterungen des E/R-Modells Erweiterung von Entitätstypen - Weak Entity Type Erweiterung von Attributen - Optionale Attribute - Strukturierte Attribute - Mengenwertige Attribute - Virtuelle Attribute Erweiterung von Beziehungstypen - Spezialisierung / Generalisierung - IS-A-Beziehung - Subtypen / Supertypen Seite 71
2 2.4.1 Erweiterung von Entitätstypen Situation: bestimmte Entities können nur existieren in Abhängigkeit von anderen Entities (zu denen sie in Beziehung stehen) - Begriff des schwachen Entitytyps (engl.: WET = weak entity type) - Zur eindeutigen Identifizierung einer Instanz eines schwachen Entitytyps muss neben bestimmten Attributwerten zusätzlich die Beziehung mit herangezogen werden - WET eignen sich zur Darstellung von Existenzabhängigkeiten Beispiel: Entitytypen Kinder (KIND), Angestellte (ANGEST) - Kinder sollen im Datenmodell erfasst werden - Nicht global alle, sondern nur die Kinder von Angestellten - Kinder haben im Datenmodell aber nur "Existenzberechtigung" zusammen mit zugehörigem Elternteil (Angestellen) - Modellierungsvorgabe: kein eigener global identifizierende Schlüssel à la "KPNR" für Kinder KIND ist ein schwacher Entitytyp Seite 72
3 2.4.1 Erweiterung von Entitätstypen Darstellung im E/R-Diagramm: - Schwache Entitytypen werden durch doppelte Linien beim Entitytyp und Beziehungstyp gekennzeichnet - Kennzeichnung des (nicht globalen, unvollständigen) Schlüssel am schwachen Entitytyp wie üblich Bezeichnet als partieller Schlüssel Bsp: Attribut "Vorname" bei KIND - Partieller Schlüssel ist erst vollständig identifizierend zusammen mit der Beziehung zum zugehörigen Elternteil (ANGEST) ANGEST 1 HAT n KIND PNR Name Vorname Geb-Dat Global eindeutig Partieller Schlüssel, nicht global eindeutig Seite 73
4 2.4.2 Erweiterung von Attributen Optionale Attribute Definition: - Attribut existiert für Entitytyp bzw. Beziehungstyp, muss aber nicht für jedes Entity / jede Beziehung existieren, d.h. einen definierten Wert annehmen - (Primär-)Schlüssel dürfen nicht optional sein! - Vergleich mit optionaler Beziehung (Folie 65): Entity e 1 єe darf in Beziehung r stehen zu Entity e 2 єe', muss aber nicht Beispiel: - Entitytyp ANGEST, Attribut "Wehrdienst von/bis" - Für weibliche Angestellte existiert die Wehrdienstangabe nicht zwingend - Darstellung im E/R-Diagramm: ANGEST PNR Wehrdienst_von_bis Seite 74
5 2.4.2 Erweiterung von Attributen Optionale Attribute Hinweis: die Semantik bei Optionalität sollte jeweils genau definiert/überlegt werden, meist werden mehrere Bedeutungen einfach vermischt: - Für weibliche Angestellte existierte die Wehrdienstangabe (in Deutschland) nicht - Für männliche Angestellte existiert sie nicht, wenn sie keinen Wehrdienst geleistet haben oder wenn sie ihn zwar geleistet haben, der von-bis-zeitraum der Datenbank aber aktuell unbekannt ist ("wurde bislang nicht eingegeben") Tatsache, dass ein Attributwert aktuell undefiniert ist, kann verschiedene Ursachen haben (not known, does not exist,...) Optionale Attribute sind primär für den Fall gedacht, wo nicht nur zeitweise undefinierte Attributwerte zugelassen werden sollen, sondern wo zulässige strukturelle Unterschiede zwischen den Entities eines Typs erlaubt sind Seite 75
6 2.4.2 Erweiterung von Attributen Strukturierte Attribute Definition: - Strukturiertes (nicht atomares) Attribut setzt sich aus anderen einfachen (atomaren) Attributen Engl.: composite attribute Schachtelungstiefe ist beliebig Entspricht record-/struct-konstrukt in Programmiersprachen - Komponenten eines strukturierten Attributs sind benannt und i.d.r. bezüglich ihrer Domänen (Wertebereiche) inhomogen Beispiel: Adress-Attribut des Entitytyp ANGEST ANGEST atomares Attribut PNR Adresse strukturiertes Attribut PLZ Ort Straße Nummer (Teil-)Attribut Seite 76
7 2.4.2 Erweiterung von Attributen Mengenwertige Attribute Definition: - Wertebereich eines mengenwertigen Attributes ist eine Wertemenge Engl.: multivalued attribute Weitere Schachtelungen möglich, auch in Verbindung mit strukturierten Attributen (Bsp: Menge von Adressen) Entspricht set-konstrukt in Programmiersprachen - Elemente der Wertemenge eines mengenwertigen Attributs sind unbenannt und bezüglich ihrer Domäne (Wertebereichs) homogen Beispiel: Telefonnummer-Attribut des Entitytyp ANGEST ANGEST atomares Attribut PNR Telefon# mengenwertiges Attribut Seite 77
8 2.4.2 Erweiterung von Attributen Mengenwertige Attribute Hinweise zur Verwendung von mengenwertigen/strukturierten Attributen im E/R-Modell: - "Später" nicht 1:1 abbildbar auf relationales Modell (DB-Schema), da dieses in Reinkultur nur atomare Attribute kennt (Kapitel 3/5) - Entscheidung, ob etwas als (schwacher) Entitytyp modelliert wird oder als nichtatomares Attribut, nicht immer einfach Bsp: Kinder von Angestellten als schwacher Entitytyp oder mengenwertiges Attribut? Information nicht in Attributen "verstecken", sondern explizit darstellen via Entitytyp/Beziehungstyp (oftmals betrachtet man bei E/R-Diagramm oberflächlich nur Entitytypen/Beziehungstypen) In nichtatomaren Attributen "versteckte" Information bleibt Betrachter verborgen bei grober Sicht auf E/R-Modell - (Nichtatomare) Attributwerte existieren nur, solange Entity existiert, d.h. können nicht eigenständig weiterleben analog schwacher Entitytyp! Seite 78
9 2.4.2 Erweiterung von Attributen Virtuelle Attribute Definition: - Virtuelle/berechnete/abgeleitete Attribute sind nicht real gespeicherte Werte, sondern entstehen aus Berechnungsvorschrift Engl.: derived attribute "Nicht-materialisierte" Attribute - Berechnungsvorschrift Muss mit angegeben werden, grundsätzlich beliebig komplex Kann auch Attributwerte anderer Entities verwenden Beispiel: Attribute Jahresgehalt und Alter am Entitytyp ANGEST - Jahresgehalt := Gehalt Gehaltsmonate - Alter := Aktuelles Datum Geb-Dat ANGEST virtuell "nötig" PNR Gehalt Geb-Dat Jahresgehalt Alter Gehaltsmonate virtuell sinnvoll Seite 79
10 2.4.2 Erweiterung von Attributen Virtuelle Attribute Beispiele: - Entitytyp ABTEILUNG mit virtuellem Attribut "DurchschnittsGehaltAbt", Wert errechnet sich mittels Durchschnittsbildung über die in Beziehung stehenden ANGEST-Entities - Entitytyp ANGEST mit virtuellem Attribut "MaxGehalt" Wert errechnet sich als Maximum der Gehälter aller Angestellten Einfache Möglichkeit zu bestimmen, wie weit das Gehalt eines Angestellten vom Maximalgehalt entfernt ist Tabellarische Darstellung virtuelles Attribut ANGEST PNR Gehalt Geb-Dat... MaxGehalt Seite 80
11 2.4.2 Erweiterung von Attributen Virtuelle Attribute Bemerkungen: - Wir betrachteten ausschließlich Modellierungsebene, noch nicht Umsetzung auf konkretes Datenbankmodell oder gar konkretes DBMS - Kurzer Ausblick auf Realisierung in relationalem Datenbankmodell später über Views (virtuelle Tabellen) - Über reale Tabellen (Basistabellen) werden virtuelle Tabellen (Views) "gestülpt", d.h. man kann dort Dinge wie Attribute/Tabellenspalten "simulieren" (berechnen), die es so real darunter (in der DB) nicht gibt Problem: Berechnungsaufwand bei jedem Zugriff auf "Virtuelles"? - Normale View erfordert beim Zugriff stets neue Berechnung, wie bei normalen DB-Abfragen - Materialized View als "materialisierte virtuelle Tabelle", d.h. es wird der Eindruck einer virtuellen Tabelle vermittelt, in Wahrheit ist sie aber vom DBMS materialisiert Vorteil: Performance-Gewinn beim Lesen Nachteil: Performance-Verlust beim Ändern (der Basistabellen), da komplette oder inkrementelle Anpassung der mat. View nötig Seite 81
12 2.4.3 Erweiterung von Beziehungstypen - Definition Definition: - Generalisierung ist die Bildung eines allgemeineren ("generischen") Entitytyps aus einer Anzahl "ähnlicher" Entitytypen - Spezialisierung ist der zur Generalisierung umgekehrte Vorgang - Begriffe: Beziehungsform " " wird IS-A-Beziehung genannt Bildung von Subtyp und Supertyp - Bestandteil sogenannter Semantischer Datenmodelle Beispiel: - Entitytyp MITARBEITER (Supertyp) - Entitytypen ANGEST, ARBEITER (Subtypen) - Jeder Angestellte/Arbeiter ist ein (is a) Mitarbeiter Spezialisierung MITARBEITER ANGEST ARBEITER Generalisierung Seite 82
13 2.4.3 Erweiterung von Beziehungstypen - Definition Bildung von Sub-/Supertypen notwendig, weil - Realwelt-Entities einerseits oftmals zwar "ähnlich" - Andererseits doch mit vielen Unterschieden, die Abbildung in einen einzigen Entitytyp verhindern ( "Missbrauch" optionaler Attribute!) Beispiel: - Firmen-Mitarbeiter: Verkäufer, Schreibkräfte und Mechaniker - Eigenschaften aller Mitarbeiter: PNR, Name, Adresse, Abteilung, Gehalt - Zusätzliche Eigenschaften: Verkäufer: Umsatz-Soll, Umsatz-Ist Schreibkräfte: Anschläge pro Minute, Fremdsprachen Mechaniker: Zuständigkeit - Betrachtungen zur Abbildung der Firmen-Mitarbeiter: Attributmengen sind nicht identisch, aber teilüberlappend Zusammenfassung zu einem Entitytyp problematisch wegen vielen optionalen Attributen, Semantik/Zusammenhänge dann unklar Trennung in einzelne Entitytypen problematisch (alles Mitarbeiter) Seite 83
14 2.4.3 Erweiterung von Beziehungstypen - Darstellung Darstellung von IS-A im E/R-Diagramm - Verwendung der bestehenden Notation für Beziehungstypen geht allgemein so nicht - Erweiterung der Notation: ABT-LTR (1,1) IS-A (0,1) ANGEST ABT-LTR IS-A ANGEST Bemerkungen: - Subtyp hat normalerweise zusätzliche Attribute gegenüber Supertyp, Beispiel Abteilungsleiter Ernennungsdatum, AnzahlUntergebene,... Abteilungsleiter ist ein spezieller Angestellter - Generalisierung/Spezialisierung kann über beliebig viele Stufen erfolgen, Beispiel: Abteilungsleiter sind spezielle Angestellte Angestellte sind spezielle Mitarbeiter (es existieren noch Arbeiter) Seite 84
15 2.4.3 Erweiterung von Beziehungstypen - Darstellung - Subtyp und Supertyp haben meist denselben Primärschlüssel, dies muss aber nicht stets so sein Beispiel 1: Primärschlüssel PNR (Personalnummer) gilt für Entitytyp MITARBEITER und Subtypen ABT-LTR und ANGEST ABT-LTR IS-A ANGEST IS-A MITARBEITER PNR Beispiel 2: Entitytypen MITARBEITER und INSTITUT haben jeweils eigenen, unterschiedlichen Primärschlüssel MITARBEITER PNR INSTITUT NAME IS-A IS-A AUSLEIHER BERECHTIGT_BIS Seite 85
16 2.4.3 Erweiterung von Beziehungstypen - Vererbung Definition: - Subtyp erbt die Attribute des Supertyps - Supertyp vererbt seine Attribute an seine Subtypen Konsequenz: Attribute des Supertyps brauchen beim Subtyp nicht nochmals aufgeführt werden, sie sind dort vielmehr implizit vorhanden Beispiel: - Supertyp Mitarbeiter, Subtypen Verkäufer, Schreibkräfte, Mechaniker - Attribute von Mitarbeiter (PNR, Name, Adresse, Abteilung, Gehalt) werden an die Subtypen Verkäufer, Schreibkraft und Mechaniker vererbt Erweiterungen (hier nicht weiter betrachtet): - Festlegung, welche Attribute vererbt/geerbt werden sollen - Möglichkeit, Attribute auf Subtypebene zu überschreiben Seite 86
17 2.4.3 Erweiterung von Beziehungstypen - Klassifizierung Ausprägung der Spezialisierung/Generalisierung - Konzepte bei Subtypbildung: Disjunkt vs. überlappend (nicht disjunkt) Vollständig vs. partiell (unvollständig) - Beispiel: jeder Mitarbeiter gehört (höchstens) einem der Subtypen an MITARBEITER VERKÄUFER SCHREIBKRAFT MECHANIKER Konzepte disjunkt/überlappend sowie vollständig/partiell sind orthogonal, d.h. beliebig kombinierbar (siehe nächste Folie) X Supertyp Y Z IS-A-Beziehung Subtyp Seite 87
18 2.4.3 Erweiterung von Beziehungstypen - Klassifizierung Spezialisierungstyp pd (partiell & disjunkt) - X = Universitätsangehörige - Y = Professoren - Z = Studenten Spezialisierungstyp pü (partiell & überlappend) - X = Universitätsangehörige - Y = Hiwis - Z = Studenten Spezialisierungstyp vd (vollständig & disjunkt) - X = Personen - Y = Männer - Z = Frauen Spezialisierungstyp vü (vollständig & überlappend) - X = Bauteile - Y = Eigenteile - Z = Fremdteile X X X X Y Y Y Y Z Z Z Z Seite 88
19 2.5 Darstellung von Attributen/Beziehungen als Entitytypen Verwendung von Entitytypen für - Attribute - Beziehungstypen Gründe / Entscheidungshilfen - Vereinfachung mehrstelliger Beziehungen (Semantikverlust!) - Erweiterbarkeit von Entitytypen ist einfacher (Beziehungstypen können selbst keine Beziehungen eingehen) - Vermeidung von Redundanz - Beachtung der Möglichkeiten bei späterer Umsetzung, teilweise fehlt die Unterstützung in konkreten DB-Modell Alternativen in der Modellierung, Klärung im konkreten Sachverhalt Seite 89
20 2.5.1 Darstellung von Attributen als Entitytypen Beispiel 1 Ausgangslage: - Entitytyp ARTIKEL : {ART-NR,..., FARBE,...} - Attribute FARBE mit dom(farbe) = {weiß, rot, gelb, grün, blau} - Frage: wie lässt sich ein mehrfarbiger Artikel modellieren? Lösung 1: Überführung von FARBE in ein mengenwertiges Attribut (a) mit folgenden Problemen: - Mengenwertiges Attribut nicht 1:1 abbildbar auf relationales Modell - Annahme: jede Farbe hat noch einen (farbspezifischen) Preis Diesen Preis jeweils zusätzlich im Attribut mitführen? Strukturiertes Attribut FARBANGABE (b) Preis ist dann, obwohl farb- und nicht artikelspezifisch gemeint, in jedem ARTIKEL-Entity vorhanden Redundanz ARTIKEL (a) ARTIKEL (b) ARTIKEL ART-NR FARBE ART-NR FARBE ART-NR FARBANGABE FARBE PREIS Seite 90
21 2.5.1 Darstellung von Attributen als Entitytypen Beispiel 1 Lösung 2: Einführung eines Entitytyps FARBE (sowie eines Beziehungstyps HAT) - Redundanzfreie Darstellung des gewünschten Sachverhalts - Eigenständiger Entitytyp hat zudem Vorteil der symmetrischen Darstellung der Informationen: ARTIKEL und FARBE stehen gleichberechtigt nebeneinander, während in Alternative 1 FARBE dem ARTIKEL untergeordnet ist FARBE könnte nun auch anderen Entitytypen zugeordnet werden - Beziehungstyp zwischen ARTIKEL und FARBE erlaubt mehr Semantik, z.b. Anzahl der möglichen Farben eines Artikels (Kardinalität) ARTIKEL (1,*) HAT (0,*) FARBE ART-NR Farbe Preis Seite 91
22 2.5.1 Darstellung von Attributen als Entitytypen Beispiel 2 Ausgangslage: - Entitytyp ANGEST : {PNR, NAME, GEHALT, LETZTE-LB} - Erweiterung des Modells (Schemaevolution): Neues Attribut JAHRESBERICHT Festlegung, dass mehrere Mitarbeiter innerhalb eines Teams ihren Jahresbericht gemeinsam schreiben dürfen Lösung 1: Entitytyp ANGEST erweitert um JAHRESBERICHT, Problem der Redundanz bei gemeinsamen Jahresberichten ANGEST ANGEST PNR GEHALT PNR GEHALT JAHRESBERICHT NAME LETZTE-LB NAME LETZTE-LB Lösung 2: Attribut JAHRESBERICHT als Entitytyp ANGEST (0,1) SCHREIBT (1,*) JAHRESBERICHT PNR NAME GEHALT LETZTE-LB Seite 92
23 2.5.1 Darstellung von Attributen als Entitytypen Beispiel 2 Lösung 3: - Anname, ein Entitytyp TEAM existiert bereits - Erweiterung von TEAM um Attribut JAHRESBERICHT ANGEST (1,1) (1,*) ARBEITET_IN TEAM JAHRESBERICHT - Was passiert aber, wenn (1,1)-Kardinalität durch (0,1) ersetzt wird? Angestellte ohne Team können keinen Jahresbericht schreiben Eigenständiger Entitytyp wie in Lösung 2 wäre doch die bessere und langfristig tragfähigere Lösung gewesen Bemerkungen: - E/R-Modell nachträglich zu ändern ist trivial - Daraus abgeleitetes DB-Modell zu ändern ist meist schwierig - Ziel: von Beginn an nach langfristig stabilem/flexbilem E/R-Modell streben, mögliche Änderungen mit berücksichtigen/vorsehen Seite 93
24 2.5.2 Darstellung von Beziehungstypen als Entitytypen Prinzipielles Vorgehen: - Beziehungstyp R K (k-stellig) - Identifikation der Primärschlüssel K n aller an R K beteiligten Entitytypen - Definition eines neuen Entitytyps mit {K n } als Attributmenge plus etwaige Attribute des Beziehungstyp R K Gründe für diese Überführung: - Kompakte (E/R-)Darstellung zusammenhängender Informationen in einem Entitytyp, Bsp: Darstellung der Beziehung "liefert" als Entitytyp (nächste Folie) Informationen über Lieferungen stehen "im Mittelpunkt" - Größere Nähe der (E/R-)Modelldarstellung zur späteren relationalen Darstellung Im relationalen Modell (siehe Kapitel 3) werden alle Informationen in Tabellenform ("Relationen") dargestellt Viele Beziehungstypen werden dort zu eigenständigen Tabellen Seite 94
25 2.5.2 Darstellung von Beziehungstypen als Entitytypen Beispiel: - Aus Beziehungstyp "liefert" wird schwacher Entitytyp LIEFERUNG - LIEFERUNG : {LNR, ANR, Name, Menge} - Was ist der Primärschlüssel von LIEFERUNG? Menge LIEFERANT liefert PROJ Name LNR Name ANR ARTIKEL ARTIKEL Bezeichnung ANR Bezeichnung L1 LIEFERANT L2 LIEFERUNG L3 PROJ Name LNR LNR Name Name ANR Menge Seite 95
26 2.6 Abschließende Bemerkungen zur E/R-Modellierung Attribute bei Beziehungstypen vergessen / falsch verwendet Umgang mit k-stelligen (k 3) Beziehungstypen - Anwendungsmöglichkeit übersehen - Falsche Verwendung Kardinalitäten bei Beziehungstypen - Falsch den Kanten zugeordnet ("vertauscht") - Passende Verwendung der Notationen (1:n, min/max,...) Vermischung logischer und physischer Aspekte Unzureichende Nutzung der semantische Möglichkeiten der E/R-Methodik - "Porsche im 1. Gang" - Modellierung ohne optionale/virtuelle Attribute, Generalisierung,... Zusammenfassung: - Es gibt in der Regel nicht das eine, einzig richtige E/R-Diagramm für eine gegebene Problemstellung - ABER: es gibt sehr wohl falsche, unvollständige E/R-Diagramm und es gibt gute oder schlechte Seite 96
2.2.4 E/R-Diagramm. Im E/R-Diagramm müssen Entitytyp- und Beziehungstypnamen eindeutig sein. Beispiel: ANGEST arbeitet_in ABTEILUNG A A.
2.2.4 E/R-Diagramm Notation: - Entitytyp mit Substantiven als Namen E - Beziehungstyp R Verben als Namen (von links nach rechts bzw. oben nach unten) "Aliasnamen" für umgekehrte Leserichtung für Klarheit/Verständnis
Sog. schwache Entitytypen (auch abhängige Entitytypen genannt)
Sog. schwache Entitytypen (auch abhängige Entitytypen genannt) Engl.: weak entity (bzw. weak entity type) Situation: Instanzen eines bestimmten Entitytyps, also die zugehörigen Entities, können nur existieren
Thema Künstliche Schlüssel / Künstlicher Primärschlüssel
Thema Künstliche Schlüssel / Künstlicher Primärschlüssel In vielen Fällen wird (zumindest) der Primärschlüssel künstlich eingeführt, d.h. fällt bei der Sammlung von Attributen für einen Entitytyp nicht
2. Datenmodellierung mit dem Entity-Relationship-Modell (E/R-Modell, ERM)
2. Datenmodellierung mit dem Entity-Relationship-Modell (E/R-Modell, ERM) Zielsetzung des Kapitels: (Nicht nur intuitive ) Einführung von Begriffen wie Entity, Entitytyp, Wertebereich, Attribut, Schlüssel(-kandidat),
2. Datenmodellierung mit ERM. Motivation für Datenmodellierung. Begriffsklärung. Kardinalität/Komplexität von Beziehungstypen
2. Datenmodellierung mit ERM Motivation für Datenmodellierung Begriffsklärung Kardinalität/Komplexität von Beziehungstypen Erweiterungen des E/R-Modells Darstellung von Attributen/Beziehungen als Entitytypen
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
E-R-Modell zu Relationenschema
Raum: LF 230 Nächste Sitzung: 27./30. Oktober 2003 Aktuelle Informationen unter: http://www.is.informatik.uni-duisburg.de/teaching/lectures/dbp_ws03/index.html E-R-Modell zu Relationenschema Als zweiter
Das konzeptionelle Datenmodell
Das konzeptionelle Datenmodell Signifikanz der Datenmodellierung Anforderungsanalyse Effizienz der Anwendung. Redundanzfreiheit. Datenintegrität. Reibungsarme Umsetzung des Datenmodells in das physikalische
Das Entity-Relationship-Modell. Prof. Dr. T. Kudraß 1
Das Entity-Relationship-Modell Prof. Dr. T. Kudraß 1 Datenmodell Datenmodelle System von Konzepten zur abstrakten Darstellung eines Ausschnitts der realen Welt mittels Daten Verschiedene Abstraktionsebenen
3. Relationales Modell
3. Relationales Modell entwickelt von Codd (1970) beruht auf dem mathematischen Begriff der Relation, den man anschaulich mit dem der Begriff Tabelle vergleichen kann alle Informationen sind in Relationen
Theorie zur Übung 8 Datenbanken
Theorie zur Übung 8 Datenbanken Relationale Datenbanksysteme Ein relationales Datenbanksystem (RDBS) liegt vor, wenn dem DBS ein relationales Datenmodell zugrunde liegt. RDBS speichern Daten in Tabellenform:
Kapitel 3: Datenbanksysteme
LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS Skript zur Vorlesung: Einführung in die Informatik: Systeme und Anwendungen Sommersemester 2008 Kapitel 3: Datenbanksysteme Vorlesung:
Introduction to Data and Knowledge Engineering Übung 1: Entity Relationship Model
Introduction to Data and Knowledge Engineering Übung 1: Entity Relationship Model FB Informatik Datenbanken und Verteilte Systeme Arthur Herzog 1 Entity Relationship Model FB Informatik Datenbanken und
Rückblick: Datenbankentwurf
Rückblick: Datenbankentwurf Entity-Relationship-Modell für konzeptuellen Entwurf Entitytypen (entity types) (z.b. Studenten) Beziehungstypen (relationships) (z.b. hören) Attribute beschreiben Gegenstände
Kapitel DB:IV (Fortsetzung)
Kapitel DB:IV (Fortsetzung) IV. Logischer Datenbankentwurf mit dem relationalen Modell Das relationale Modell Integritätsbedingungen Umsetzung ER-Schema in relationales Schema DB:IV-45 Relational Design
Daten Bank. 2. Vorlesung. Dr. Karsten Tolle PRG2 SS 2014
Daten Bank 2. Vorlesung Dr. Karsten Tolle PRG2 SS 2014 Letzte Vorlesung Grundbegriffe SQL create table insert select Dr. Karsten Tolle PRG2 SS 2014 2 Heute Übersicht Modellierung (ER-Diagramme) Entitäten
Datenmodelle. Einführung in das Entity-Relationship-Modell. Datenbankmodelle. Beispiel für ein ER-Schema. Kunde( Meier, , ) 41, Meier
Einführung in das Entity-Relationship-Modell Datenmodelle Datenmodelle dienen der Darstellung der Informationsstruktur, nicht der Darstellung der Informationen selbst. Motivation Grundbestandteile von
Universität Augsburg, Institut für Informatik WS 2009/2010 Prof. Dr. W. Kießling 06. Nov Dr. A. Huhn, F. Wenzel, M. Endres Lösungsblatt 2
Universität Augsburg, Institut für Informatik WS 2009/2010 Prof. Dr. W. Kießling 06. Nov. 2009 Dr. A. Huhn, F. Wenzel, M. Endres Lösungsblatt 2 Aufgabe 1: ER-Modellierung 1. Siehe Unterstreichungen in
Rückblick: Entity-Relationship-Modell
Rückblick: Entity-Relationship-Modell Entity-Relationship-Modell für konzeptuellen Entwurf Entitytypen (entity types) (z.b. Studenten) Beziehungstypen (relationships) (z.b. hören) Attribute beschreiben
Kapitel 1: Einführung 1.1 Datenbanken?
Kapitel 1: Einführung 1.1 Datenbanken? 1. Einführung 1.1. Datenbanken Grundlagen der Datenbanksysteme, WS 2012/13 29. Oktober 2012 Seite 1 1. Einführung 1.1. Datenbanken Willkommen! Studierenden-Datenbank
Kapitel 3: Entity-Relationship-Modell
Kapitel 3: Entity-Relationship-Modell Objekte und Beziehungen Objekte bilden die elementare Grundlage unserer Betrachtung. Objekte werden durch Tupel in Relationen repräsentiert und können durch Schlüsselwerte
-02- Arbeitsunterlagen
-02- Arbeitsunterlagen DVT LK13.1 2014/2015 Erweiterung ER-Modell Übungsaufgaben ER-Modell Lehrkraft: Kurs: 0 Erweiterung zum Ersten Generalisierung Übergang zu einem allgemeineren (Super-)Typ Bsp.: Mitarbeiter
Handelsinformationssysteme
Kurzskript zur Vorlesung Handelsinformationssysteme Prof. Dr. Jörg Becker Inhaltsverzeichnis Inhaltsverzeichnis... 2. Architektur integrierter Informationssysteme (ARIS)... 3 2. Logisches Datenmodell...
Aufgabe 1) Übung 4: 1.2
Übung 4: Aufgabe 1) 1.2 Relation: Eine Relation besteht aus Attributen und Tupeln. Sie wird üblicherweise mit Hilfe einer Tabelle beschrieben, welche in zweidimensionaler Anordnung die Datenelemente erfasst.
Übungen Teil 1: ER-Modelle. Dozent: Stefan Maihack Dipl. Ing. (FH)
Übungen Teil 1: ER-Modelle Dozent: Stefan Maihack Dipl. Ing. (FH) Die (min, max) - Notation Bei der Verwendung der Funktionalität ist für einen Entity-Typen nur die maximale Anzahl der Beziehungen mit
ERM Modellierung Teil 2
ERM Modellierung Teil 2 Oliver Berthold Frank Huber Heiko Müller Lehr- und Forschungseinheit Datenbanken und Informationssysteme 1 Ziele Generalisierung / Spezialisierung Mehrstellige Beziehungen Lehr-
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.
D1: Relationale Datenstrukturen (14)
D1: Relationale Datenstrukturen (14) Die Schüler entwickeln ein Verständnis dafür, dass zum Verwalten größerer Datenmengen die bisherigen Werkzeuge nicht ausreichen. Dabei erlernen sie die Grundbegriffe
Dieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird.
Thomas Studer Relationale Datenbanken: Von den theoretischen Grundlagen zu Anwendungen mit PostgreSQL Springer, 2016 ISBN 978-3-662-46570-7 Dieser Foliensatz darf frei verwendet werden unter der Bedingung,
Stufen der Entwicklung einer Datenbank. ER-Modell. Datenbank-Entwurf (1) Datenbank-Entwurf (2) 1. Datenbank - Entwurf ( ER - Diagramm)
9. Einführung in das Entity-Relationship-Modell 9-1 9. Einführung in das Entity-Relationship-Modell 9-2 ER-Modell Stufen der Entwicklung einer Datenbank 1. Überblick über den Datenbank-Entwurf 2. Grundlegende
Datenbankentwurf. VO Datenmodellierung. Katrin Seyr. Institut für Informationssysteme Technische Universität Wien.
Datenbankentwurf Datenbankentwurf VO Datenmodellierung Katrin Seyr Institut für Informationssysteme Technische Universität Wien Katrin Seyr Seite 1 Datenbankentwurf 1. Überblick Überblick Wiederholung:
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
Datenbankmodelle 1. Das Entity-Relationship-Modell
Datenbankmodelle 1 Das Entity-Relationship-Modell Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle ER Modell - 2 Was kann modelliert werden?
Aufgabe 1: Strukturmodellierung mittels Klassendiagramm Wiederholen Sie das Kapitel aus der Vorlesung, das sich mit dem Klassendiagramm beschäftigt.
Aufgabe 1: Strukturmodellierung mittels Klassendiagramm Wiederholen Sie das Kapitel aus der Vorlesung, das sich mit dem Klassendiagramm beschäftigt. Was ist eine Klasse? Was ist ein Objekt? Geben Sie ein
3. Grundlagen relationaler Datenbanksysteme
3. Grundlagen relationaler Datenbanksysteme Hier nur kurze Rekapitulation, bei Bedarf nachlesen 3.1 Basiskonzepte des Relationenmodells 1 Darstellung der Miniwelt in Tabellenform (DB = Menge von Relationen
ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen
ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen C4: Structured ERM Lernziele: Nach der Bearbeitung dieser Lektion haben Sie folgende Kenntnisse erworben: Sie können die Motivation zur Erweiterung
Vorlesung Datenbank-Entwurf Klausur
Dr. Stefan Brass 3. Juli 2002 Institut für Informatik Universität Giessen Vorlesung Datenbank-Entwurf Klausur Name: Geburtsdatum: Geburtsort: (Diese Daten werden zur Ausstellung des Leistungsnachweises
Kap. 5.3: SAP-Datenmodell, Metadatenverwaltung
Kap. 5.3: SAP-Datenmodell, Metadatenverwaltung & Abbildung auf RDBMS SAP R/3 Repository Analyse: Datenmodell von SAP R/3 SAP-SERM Metadatenverwaltung Data Dictionary Abbildung von SAP-Tabellen auf RDBMS
Das Entity-Relationship-Modell (ERM)
Das Entity-Relationship-Modell (ERM) Konzeptionelle Informationsmodellierung Das Entity-Relationship-Modell (ER-Modell) Konzepte ER-Diagramme Beispiele Das Erweiterte ER-Modell (EER-Modell) Subklassen,
Konzeptueller Entwurf
Konzeptueller Entwurf UML Klassendiagrame UML Assoziationen Entspricht Beziehungen Optional: Assoziationsnamen Leserichtung ( oder ), sonst bidirektional Rollennamen Kardinalitätsrestriktionen UML Kardinalitätsrestriktionen
Wirtschaftsinformatik 2 Modellierung betrieblicher Informationssysteme - MobIS (theoretische Aspekte der Informationsmodellierung)
Wirtschaftsinformatik 2 Modellierung betrieblicher Informationssysteme - MobIS (theoretische Aspekte der Informationsmodellierung) 4. Vorlesung 25.04.2007 Kardinalität Typisch für Kardinalitätsangaben
Objektorientierte Analyse (OOA) OOA-Pattern
OOA-Muster (Architektur Pattern) Ein Pattern (Entwurfsmuster) ist ein Problem mit seiner Lösung in einem Kontext. Der Kontext enthält in der Regel Zielkonflikte, die der Designer lösen muss, z.b. Performance
Logischer Entwurf von Datenbanken
Logischer Entwurf von Datenbanken Relationales Datenbankschema Wintersemester 16/17 DBIS 1 Typischer Datenbankentwurf Anforderungsanalyse und -spezifikation Miniwelt Konzeptioneller Entwurf E/R-Diagramm
Grundlagen des relationalen l Modells
Grundlagen des relationalen l Modells Seien D 1, D 2,..., D n Domänen (~Wertebereiche) Relation: R D 1 x... x D n Bsp.: Telefonbuch string x string x integer Tupel: t R Bsp.: t = ( Mickey Mouse, Main Street,
Datenbanken 1 für Medieninformatiker. 2. Semantische Datenmodellierung 2.3. ERM-Modellierung 2.4. ERM-Erweiterungen
Datenbanken 1 für Medieninformatiker 2. Semantische Datenmodellierung 2.3. ERM-Modellierung 2.4. ERM-Erweiterungen ERM: Entität und Entitätstyp Patient Klaus Meier 22.5.22.. Station 53, Zi 227 Typ Patient:
Datenbanken Unit 3: Das relationale Modell
Datenbanken Unit 3: Das relationale Modell 8. III. 2016 Outline 1 Das ER Modell Zusammenfassung 2 Das Relationale Modell 3 SQL Organisatorisches Wissensüberprüfung: heute zwei Aufgaben statt nur einer
Vorlesung Informationssysteme
Saarbrücken, 21.04.2015 Information Systems Group Vorlesung Informationssysteme Vertiefung zu Kapitel 2: ER-Modell Erik Buchmann (buchmann@cs.uni-saarland.de) Wer hat noch keine Gruppe? Bitte im Q&A-Forum
3. Das Relationale Datenmodell
3. Das Relationale Datenmodell Das Relationale Datenmodell geht zurück auf Codd (1970): E. F. Codd: A Relational Model of Data for Large Shared Data Banks. Comm. of the ACM 13(6): 377-387(1970) DBMS wie
Datenbanken. Relationales Modell:
Relationales Modell: beruht auf dem mathematischen Konzept der Relation wurde von Edgar F. Codd 1970 bereits entwickelt Alle relevanten Informationen der Datenbank sind in diesem Datenbank-Modell in Relationen
Kapitel 2: Das Relationale Modell
Ludwig Maximilians Universität München Institut für Informatik Lehr- und Forschungseinheit für Datenbanksysteme Skript zur Vorlesung Wintersemester 2006/2007 Kapitel 2: Das Relationale Modell Vorlesung:
ISDA Informationssysteme und Datenanalyse SS 2015
Hausaufgabenblatt 1 (10 Portfoliopunkte) Ausgabe: Montag, 27.04.2015 Abgabe: Allerspätestens am Sonntag, 24.05.2015, 23:59 Uhr auf ISIS. Abzugeben ist eine PDF- Datei. Aufgabe 1: EER- Modellierung (2 P)
Erweiterte Entity-Relationship- und UML-Modellierung. Copyright 2004 Shamkant Ramez Elmasri B. Navathe and Shamkant Navathe.
Erweiterte Entity-Relationship- und UML-Modellierung Copyright 2004 Shamkant Ramez Elmasri B. Navathe and Shamkant Navathe. CC 1 Erweitertes-ER (EER) Modellkonzept Beinhaltet alle Aspekte des Basis-ER-Modellkonzeptes
Kapitel 3. Relationales Modell (Relationenmodell) Transformation ER-Modell Relationenmodell. Prof. Dr. Wolfgang Weber, Vorlesung Datenbanken 1
Kapitel 3 Relationales Modell (Relationenmodell) Transformation ER-Modell Relationenmodell Prof. Dr. Wolfgang Weber, Vorlesung Datenbanken 1 Definition Relationenmodell entwickelt von Codd u. a. beruht
Kapitel DB:III (Fortsetzung)
Kapitel DB:III (Fortsetzung) III. Konzeptueller Datenbankentwurf Einführung in das Entity-Relationship-Modell ER-Konzepte und ihre Semantik Charakterisierung von Beziehungstypen Existenzabhängige Entity-Typen
Software-Engineering und Datenbanken
Software-Engineering und Datenbanken Datenbankentwurf Prof. Dr. Bernhard Schiefer 5-1 Datenbankentwurf: Phasenmodell Anforderungsanalyse Konzeptioneller Entwurf Verteilungsentwurf Logischer Entwurf Datendefinition
Datenbankentwurf. 4.2 Logischer Entwurf. Kapitel 4. ER-Modell. Umsetzung. Entwurfsdokumentation. relationales Modell. Verbesserung
4.2 Logischer Entwurf Datenbankentwurf 4.2 Logischer Entwurf 2002 Prof. Dr. Rainer Manthey Informationssysteme Logischer Entwurf: Einordnung Entwurfsdokumentation logische Strukturen "auf dem Papier" konzeptueller
Entwurf und Verarbeitung relationaler Datenbanken
Entwurf und Verarbeitung relationaler Datenbanken Eine durchgängige und praxisorientierte Vorgehens weise von Prof. Dr. Nikolai Preiß Berufsakademie Stuttgart R. Oldenbourg Verlag München Wien Inhalt Abbildungsverzeichnis
2. Übung zur Vorlesung Datenbanken im Sommersemester 2007 mit Musterlösungen Prof. Dr. Gerd Stumme, Dipl.-Inform. Christoph Schmitz http://www.kde.cs.uni-kassel.de 30. April 2007 Aufgabe 1 Betrachten Sie
Datenbanksysteme I, SS 2004
Universität Mannheim Lehrstuhl für Praktische Informatik III orman May D7 27, Raum 40 683 Mannheim Telefon: (062) 8-2586 Email: norman@pi3.formatik.uni-mannheim.de Datenbanksysteme I, SS 2004 Lösungen
Grundlagen von Datenbanken SS 2010
Grundlagen von Datenbanken SS 2010 2. Formalisierung des relationalen Datenmodells Agenda: Prof. Dr. Stefan Böttcher Universität Paderborn mit Material von Prof. Dr. Gregor Engels Das Relationenmodell
Übung zur Vorlesung Einführung in die Informatik für Hörer anderer Fachrichtungen (WZW) IN8003, SS 2011 Prof. Dr. J. Schlichter
Übung zur Vorlesung Einführung in die Informatik für Hörer anderer Fachrichtungen (WZW) IN8003, SS 2011 Prof. Dr. J. Schlichter Dr. Georg Groh, Dipl.Inform. Dipl.Geogr. Jan Herrmann, Florian Schulze BSc.,
ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen
ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen C2: Relationenbildung und Normalisierung Lernziele: Nach der Bearbeitung dieser Lektion haben Sie folgende Kenntnisse erworben: Sie können den
1. Einführung Seite 1. Kapitel 1: Einführung
1. Einführung Seite 1 Kapitel 1: Einführung 1. Einführung Seite 2 Willkommen! Studierenden-Datenbank Hans Eifrig hat die Matrikelnummer 1223. Seine Adresse ist Seeweg 20. Er ist im zweiten Semester. Lisa
10. Datenbank Design 1
1 Die Hauptaufgabe einer Datenbank besteht darin, Daten so lange zu speichern bis diese explizit überschrieben oder gelöscht werden. Also auch über das Ende (ev. sogar der Lebenszeit) einer Applikation
Einführung in die Informatik II
Einführung in die Informatik II Relationale Datenbanken und SQL Theorie und Anwendung Prof. Dr. Nikolaus Wulff Gründe für eine Datenbank Meist werden Daten nicht in XML-Dokumenten, sondern innerhalb einer
Inhalt. 2.1 Datenbankentwurf. 2.2 Relationales Modell. 2.3 Relationale Entwurfstheorie. 2.4 Relationale Algebra. 2.5 Structured Query Language (SQL)
2. Datenbanken Inhalt 2.1 Datenbankentwurf 2.2 Relationales Modell 2.3 Relationale Entwurfstheorie 2.4 Relationale Algebra 2.5 Structured Query Language (SQL) 2 2.1 Datenbankentwurf Datenbankanwendungen
Objektorientierte Modellierung (1)
Objektorientierte Modellierung (1) Die objektorientierte Modellierung verwendet: Klassen und deren Objekte Beziehungen zwischen Objekten bzw. Klassen Klassen und Objekte Definition Klasse Eine Klasse ist
Datenbanken: Relationales Datenbankmodell RDM
Das RDM wurde in den 70'er Jahren von Codd entwickelt und ist seit Mitte der 80'er Jahre definierter Standard für Datenbanksysteme! Der Name kommt vom mathematischen Konzept einer Relation: (Sind A, B
4 Grundlagen der Datenbankentwicklung
4 Grundlagen der Datenbankentwicklung In diesem Kapitel werden wir die Grundlagen der Konzeption von relationalen Datenbanken beschreiben. Dazu werden Sie die einzelnen Entwicklungsschritte von der Problemanalyse
fbi h_da Datenbanken Kapitel 2: Semantische Datenmodellierung Kapitel 2-1 Datenbanken 1 (Bachelor)
Datenbanken Kapitel 2: Semantische Datenmodellierung Kapitel 2-1 Semantische Datenmodellierung Inhalte des Kapitels Die Rolle der Datenmodellierung im Lifecycle von Informationssystemen Das erweiterte
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-
Relationales Datenbanksystem Oracle
Relationales Datenbanksystem Oracle 1 Relationales Modell Im relationalen Modell wird ein relationales Datenbankschema wie folgt beschrieben: RS = R 1 X 1 SC 1... R n X n SC n SC a a : i=1...n X i B Information
Inhaltsverzeichnis Vorwort zur vierten Auflage Vorwort zur dritten Auflage Vorwort zur zweiten Auflage Vorwort zur ersten Auflage Hinweise zur CD
Vorwort zur vierten Auflage 11 Vorwort zur dritten Auflage 13 Vorwort zur zweiten Auflage 15 Vorwort zur ersten Auflage 17 Hinweise zur CD 19 1 Datenbanken und Datenbanksysteme 21 1.1 Zentralisierung der
fbi h_da Datenbanken Kapitel 2: Semantische Datenmodellierung Schestag Datenbanken (Bachelor) Kapitel 2-1
Datenbanken Kapitel 2: Semantische Datenmodellierung Schestag Datenbanken (Bachelor) Kapitel 2-1 Semantische Datenmodellierung Inhalte des Kapitels Die Rolle der Datenmodellierung im Lifecycle von Informationssystemen
LB 5: Astronomische Beobachtungen
LB 5: Astronomische Beobachtungen Konkrete Stoffverteilung Stoffverteilung für dieses Schulhr Datenbanken im Profilunterricht Lehrplanbezug im naturwissenschaftlichen Profil Übertragen des Modellbegriffs
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
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
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
Der Tabellenname wird in Grossbuchstaben geschrieben.
Datenbanken: Abbildungsregeln 1 Tabellen Einleitung Da ein relationales Datenbankschema als Objekte nur Tabellen zulässt, müssen sowohl die Entitäts- als auch die Beziehungsmengen in Tabellenform ausgedrückt
Zur Beschreibung datenbasierter Parametrisierung von Softwarekomponenten
Zur Beschreibung datenbasierter Parametrisierung von Softwarekomponenten Jörg Ackermann Uni Augsburg Jörg Ackermann: Zur Beschreibung datenbasierter Parametrisierung von Softwarekomponenten. AKA 2004 /
Objektorientierte Programmierung OOP
Objektorientierte Programmierung OOP Objektorientierte Programmierung OOP Ronja Düffel Alina Stürck WS2016/17 11. Oktober 2016 Objektorientierte Programmierung OOP 1 Was ist das? 2 Wie geht das? 3 Warum
Das Entity-Relationship-Modell
Das Entity-Relationship-Modell 1976 vorgeschlagen von Peter Chen Entities wohlunterschiedbare Dinge der realen Welt Beispiele: Personen, Autos weithin akzeptiertes Modellierungswerkzeug, denn ist unabhšngig
10 Datenbanksysteme Datenbanken und Datenbanksysteme
10 Datenbanksysteme In vielen Anwendungen müssen große Datenbestände dauerhaft auf Externspeichern verwaltet werden. Stellen diese Daten eine logische Einheit dar, so spricht man von einer Datenbank. Im
Beziehungen. one-to-one. one-to-many. many-to-many. Beziehung. Beziehung. Beziehung. Beziehung. Relationales Datenmodell
Beziehungen one-to-one Entität_1 (0:1) (0:1) Beziehung Entität_2 Entität_1 (1:1) (1:1) Beziehung Entität_2 one-to-many Entität_1 (0:1) (0:n) Beziehung Entität_2 many-to-many Entität_1 (0:n) Beziehung (0:n)
Einführung in Datenbanken
Einführung in Datenbanken Dipl.-Inf. Michael Wilhelm Hochschule Harz FB Automatisierung und Informatik mwilhelm@hs-harz.de aum 2.202 Tel. 03943 / 659 338 1 Inhalt 1. Grundlegende Begriffe der Datenbanktechnologie
Übungsblatt 4. Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin)
Übungsblatt 4 Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin) Die Saartal Linien beauftragen Sie mit dem Entwurf der Datenstrukturen für ein Informationssystem. Dieses soll zur Verwaltung
Datenbanken. Semantische Datenmodellierung:
Semantische Datenmodellierung: Bei der semantischen Datenmodellierung wird ein Modell entworfen, das syntaktischen Regeln gehorcht und die Semantik also die Bedeutung - einschließt. Modelliert wird bei
Software-Engineering
SWE42 Slide Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 4: Systemanalyse Teil 2: Datenorientierte Sicht SWE42 Slide 2 Systemanalyse: Datenorientierte Sicht Entity-Relationship-Modellierung
Kapitel 3: Datenbanksysteme
LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS Skript zur Vorlesung: Einführung in die Informatik: Systeme und Anwendungen Sommersemester 2014 Kapitel 3: Datenbanksysteme Vorlesung:
Wegweisende Arbeiten in der Softwaretechnik Peter P. Chen Entity Relationship Modellierung
Wegweisende Arbeiten in der Softwaretechnik Peter P. Chen Entity Relationship Modellierung Problemseminarvortrag im SS 2004 von Madlen Hartmann 1 Übersicht 1. Einführung 2. Hintergründe 3. Wichtige Erkenntnisse
Kapitel 2: Das Relationale Modell
Ludwig Maximilians Universität München Institut für Informatik Lehr- und Forschungseinheit für Datenbanksysteme Skript zur Vorlesung Datenbanksysteme I Wintersemester 2012/2013 Kapitel 2: Das Relationale
Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert
Maika Büschenfeldt Datenbanken: Skript 1 1. Was ist eine relationale Datenbank? In Datenbanken können umfangreiche Datenbestände strukturiert abgelegt werden. Das Konzept relationaler Datenbanken soll
Vorlesung Datenbankmanagementsysteme
Vorlesung Datenbankmanagementsysteme ER-Modellierung M. Lange, S. Weise Folie #3-1 ER-Modellierung Wiederholung - Drei-Ebenen-Schema-Architektur - ANSI-SPARC-Architektur - Fünf-Schichten-Architektur ER-Modellierung
Informations-, Daten- und Wissensmanagement
Informations-, Daten- und Wissensmanagement Lesen Sie den Artikel Schürfen in der Datenhalde und beantworten Sie folgende Fragen: Was ist Wissensmanagement? Forschungsgebiet / Managementthema, das sich
Relationales Datenmodell
Relationales Datenmodell Ein Datenmodell hat zwei Bestandteile: Eine mathematische Notation zur Darstellung von Daten und Beziehungen. Operationen auf den Daten, um Abfragen und andere Manipulationen zu
9. Einführung in Datenbanken
9. Einführung in Datenbanken 9.1 Motivation und einführendes Beispiel 9.2 Modellierungskonzepte der realen Welt 9.3 Anfragesprachen (Query Languages) 9.1 Motivation und einführendes Beispiel Datenbanken
Entwurf von Datenbanken
Bisher: was sind Datenbanken? Wie funktionieren sie? Im Folgenden: wie entwickle ich eine Datenbank? Was ist eine gute Datenbank? Der Datenbankentwurfsprozess Das Entity Relationship (ER) Modell Abbildung
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,
WS 2010/11 Datenbanksysteme Fr 15:15 16:45 R 1.008. Vorlesung #5. SQL (Teil 3)
Vorlesung #5 SQL (Teil 3) Fahrplan Besprechung der Übungsaufgaben Rekursion Rekursion in SQL-92 Rekursion in DBMS- Dialekten (Oracle und DB2) Views (Sichten) - gespeicherte Abfragen Gewährleistung der
Inhaltsverzeichnis. 1. Fragestellung
Inhaltsverzeichnis 1. Fragestellung... 1 2. Herleitung zum Thema... 1 3. Das Entity Relationship Modell (ERM)... 2 4. Praktisches Beispiel zum ERM... 7 5. Anhang...Fehler! Textmarke nicht definiert. 1.