Datenbanken. Relationales Modell:
|
|
- Emilia Kruse
- vor 7 Jahren
- Abrufe
Transkript
1 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 abgelegt. 1
2 Rückblick: Datenbank-Entwurfsprozess Semantische Datenmodellierung (vgl. Kapitel 2) Überführung des semantischen Datenmodells in das relationale Modell 2
3 Mathematische Grundlagen des relationalen Modells (1): Seien W 1, W 2,, W n die Wertebereiche der Attribute A 1, A 2,, A n. Das kartesische Produkt der Mengen W 1, W 2,, W n ist die Menge aller n-tupel (w 1, w 2,, w n ), w i W i und wird geschrieben als W 1 X W 2 X X W n. Jede Untermenge des kartesischen Produkts W 1 X W 2 X X W n ist eine (n-stellige) Relation. Der Grad der Relation ist n. Für jede Relation in einer relationalen Datenbank wird ein Relationenschema festgelegt, durch Angabe des Namens des Schemas und der dazugehörigen Attribute. Eine identifizierende Attributkombination einer Relation ist eine Menge von Attributen, durch die jedes Tupel der Relation identifiziert werden kann. Eine identifizierende Kombination von Attributen K = (A 1, A 2,, A j ) heißt Schlüssel der Relation, wenn keine echte Untermenge von K eine identifizierende Attributkombination der Relation ist. 3
4 Mathematische Grundlagen des relationalen Modells (2): Jede Relation besitzt mindestens einen Schlüssel. Falls eine Relation mehrere Schlüssel besitzt, wird ein Schlüssel als Primärschlüssel (primary key, PK) ausgezeichnet. Der Wert des Primärschlüssels ist eindeutig, nicht änderbar und darf nicht leer sein. Der Primärschlüssel wird im Relationenschema unterstrichen. Aus der mathematischen Definition der Relation folgt, dass zwei Tupel einer Relation paarweise verschieden (Definition als Menge!) sind, d.h. sie unterscheiden sich mindestens in einem Attribut. Tupel sind nicht geordnet, d.h. die Reihenfolge ist bedeutungslos. 4
5 Beispielrelation: Name des Relationenschemas Attribut (Spalte) Markt: Bezeichnung Standort Kategorie Relationenschema Internationaler Töpfermarkt Krefeld Töpfermarkt Relation (Tabelleninhalt) Töpfermarkt Sommerhausen Internationaler Töpfermarkt Sommerhausen Hanau Töpfermarkt Töpfermarkt Tupel (Zeile) 5
6 Kritik am relationalen Modell: Einfacher Aufbau des Modells wird kritisiert, da die komplexe Welt auf flache Relationen herunter gebrochen werden muss. Es ist tatsächlich so, dass Dinge der realen Welt, die man z.b. in einer Excel-Tabelle darstellen kann in einem relationalen Datenbank-System aufgrund der Normalisierungs-Regeln in verschiedene Relationen abgelegt werden müssen. Dieser Sachverhalt bedeutet neben der unnatürlichen Verteilung auch Performance-Verlust. Aufgrund der Kritik wurden alternative Ideen entwickelt: Objektorientierte Datenbanken (ausgehend von den objektorientierten Programmiersprachen Objekt-relationale Datenbanken (ausgehend von den relationalen Datenbanken) 6
7 Integritätsbedingungen: 7 Die Definition von Integritätsbedingungen dient dazu, dass das Datenbanksystem diese automatisiert prüfen und einhalten kann. Auch falls die Gefahr der Verletzung einer Integritätsbedingung besteht, kann das System angemessen reagieren. Bereits die Einhaltung des Datentyps eines Attributs kann als Integritätsbedingung aufgefasst werden. Das System erlaubt dies nicht und meldet ggfs. einen Fehler bei der Eingabe. Bei Datenbanken unterscheidet man insbesondere zwei Sorten von Integritätsbedingungen: intralrelationale und interrelationale. Intrarelationale Integritätsbedingungen sind Abhängigkeiten zwischen Attributen einer Relation. Bekanntestes Beispiel ist die Schlüsselabhängigkeit. Ist ein Attribut (oder eine Kombination von Attributen) als Schlüssel definiert, kann das System für die Einhaltung der Schlüsselbedingung sorgen. Interrelationale Integritätsbedingungen existieren zwischen Relationen. Bekanntes Beispiel hierfür ist die Fremdschlüsselabhängigkeit. Ein Attribut, das in einer Relation als Schlüssel definiert wurde, kann in einer assoziierten Relation als Fremdschlüssel definiert werden. Die Assoziation legt fest, dass Tupel in den beiden Relationen, die den gleichen Wert in diesem Attribut haben, ein identisches (übergeordnetes) Objekt meinen. Des Weiteren gilt, dass Tupel in der in der assoziierten Relation nur solche Werte in dem Fremdschlüsselattribut haben dürfen, die in der referenzierten Relation auch vorhanden sind.
8 Integritätsbedingungen: Beispiel: Markt: Bezeichnung Standort Name Kategorie Veranstalter: Name Adresse Bezeichnung Typ Das Attribut Name in der Relation Veranstalter ist Primärschlüssel, d.h. in jedem Tupel muss sich dieses von den anderen im Namen unterscheiden. Die Attribute Bezeichnung und Standort sind Primärschlüssel der Relation Markt, d.h. die Kombination der beiden Attributwerte muss sich in jedem Tupel unterscheiden. Das Attribut Name in Markt ist Fremdschlüssel, d.h. es korrespondiert zu dem Attribut Name in Veranstalter (hier ist es Schlüssel). Dies bedeutet, dass jeder Name in Markt auch in Veranstalter vorkommen muss. Alle Attribute des Veranstalters sind relevant für den korrespondierenden Markt. Notation: Unterstrich: Schlüssel(-attribut), Oberstrich: Fremdschlüssel(-attribut) 8
9 Das EERM dient der Modellierung der Realwelt aus Sicht der Anwendung. Das relationale Modell dient als Grundlage für die Realisierung in relationalen Datenbanken. Die Transformation EERM Relationales Modell führt uns dazu, die Wünsche des Anwenders der Datenbank näher an die physische Realisierung zu bringen. Die im Folgenden aufgestellten Regeln erlauben eine (halb-)automatisierte Implementation. Diese Implementation ist mit entsprechenden Software-Tools möglich. Trotz der aufgestellten Regeln muss der Datenbank-Spezialist am Ende des Prozesses überprüfen, ob die Umsetzung sinnvoll ist. 9
10 Rückblick: Datenbank-Entwurfsprozess Überführung des semantischen Datenmodells in das relationale Modell 10
11 Folgende Regeln werden verwendet: 1. Jeder Entity-Typ wird zu einem Relationenschema 2. Strukturierte Typen von Attributen müssen in einfache Relationenschemata überführt werden. 3. m:n-beziehungen werden zu drei Relationenschemata (2 für die Entity-Typen, 1 für den Relationship-Typ) 4. m:1-beziehungen werden zu zwei Relationenschemata (für die Entity-Typen). 5. 1:1-Beziehungen werden zu zwei Relationenschemata. 6. Rekursive Beziehungen werden konsequent wie normale Beziehungen behandelt. 7. Mehrstellige Beziehungen werden wie zweistellige Beziehungen umgesetzt unter Berücksichtigung des mehrstelligen Relationship-Typ. 8. Generalisierungen/Spezialisierungen können auf zweierlei Weise umgesetzt werden, je nachdem ob die Oberklasse abstrakt oder konkret ist. 11
12 1. Entity-Typ Jeder Entity-Typ wird zu einem Relationenschema. Der Name des Entity-Typs wird zum Namen des Relationenschemas Die Attribute des Entity-Typs werden zu den Attributen des Relationenschemas Falls Entities komplexe Attribute haben, müssen diese aufgelöst werden: Listenartige/Arrayartige Attribute werden in ein neues Relationenschema ausgelagert, welches über eine Schlüssel-/Fremdschlüssel-Beziehung verbunden wird. Recordartige Attribute werden entweder ebenfalls ausgelagert oder als jeweils einzelne Attribute behandelt. Ein Schlüssel (falls noch nicht im EERM geschehen) wird ausgezeichnet und unterstrichen. Die Datentypen der Attribute müssen spätestens jetzt festgelegt werden und dürfen nicht komplex (z.b. Liste, Array, Record) sein. 12
13 Entity-Typ (Beispiel): Markt Bezeichnung Standort Kategorie Markt: Bezeichnung Standort Kategorie Datentypen: Bezeichnung varchar(), Standort varchar(), Kategorie Aufzählungstyp 13
14 Entity-Typ (Beispiel): Kunde Vornamen Nachname Strasse Kd-Nummer Adresse Stadt PLZ Kunde: Adresse Vornamen Kd-Nummer Nachname Strasse PLZ Stadt Vorname_1 Vorname_2... Vorname_n Dieses Relationenschema ist nicht gültig, da noch komplexe Attribute (Adresse ist recordartig, Vornamen ist listenartig/arryartig) enthalten sind. 14
15 Vornamen Entity-Typ (Beispiel, Fortsetzung): Auflösung Adresse: Kunde Nachname 2. Es werden nur die Subattribute genutzt. Auflösung Vornamen: Ein zweites Relationenschema wird gebildet Adresse Strasse Stadt Kd-Nummer und über Schlüssel-/Fremdschlüssel verbunden. PLZ Kunde: Kd-Nummer Nachname Strasse PLZ Stadt Vorname: Kd-Nummer Vorname 15 Datentypen: Kd-Nummer integer, Nachname, Vorname, Strasse, Stadt varchar(), PLZ integer oder varchar()
16 3. Relationship-Typ: m:n-beziehung Die beteiligten Entity-Typen werden wie zuvor behandelt. Der Relationship-Typ wird zu einem eigenen Relationenschema. Die Attribute des Relationship-Typs werden zu Attributen des neuen Relationenschemas. Zusätzlich werden die Primärschlüssel-Attribute der beteiligten Entity-Typen als Attribute des neuen Relationenschemas hinzugefügt, wobei gilt: Diese Primärschlüssel-Attribute bilden gemeinsam den Primärschlüssel des neuen Relationenschemas. Diese sind gleichzeitig Fremdschlüssel bezogen auf das Relationenschema, aus dem sie hervorgegangen sind. Zusammengefasst: Es entstehen drei Relationenschemata, eines für den Relationship-Typ und zwei für die beiden Entity-Typen. Diese sind über Schlüssel-/Fremdschlüssel-Beziehungen miteinander verbunden. Hierzu werden die Schlüssel-Attribute der beteiligten Entity-Typen in das dritte Relationenschema übertragen und dort zum Primärschlüssel. 16
17 m:n-beziehung (Beispiel): Produkt (0,*) (0,*) 6 Markt Produkt (Nummer, Bezeichnung, Funktion) Markt (Bezeichnung, Standort, Kategorie) 6: wird angeboten auf (Anzahl) Produkt: Nummer Bezeichnung Funktion Markt: Bezeichnung Standort Kategorie WirdAngebotenAuf: Nummer Bezeichnung Standort Anzahl 17
18 Exkurs Anwendung mit einem Case-Tool (Power Designer): 1. Modellierung einer m:n-beziehung (Entity-Typ + Attribute): Die Notation ist unterschiedlich zu der bisher gelernten, jedoch semantisch gleich mächtig. 2. Einfügen von Attributen bei dem Relationship-Typ (change to entity) 3. Check Modell ( Überprüfen auf syntaktische Fehler) 4. (Übersetzen des Modells in das relationale Modell) 18
19 Exkurs Anwendung mit einem Case-Tool (Power Designer): 1. Modellierung einer m:n-beziehung (Entity-Typ + Attribute): Die Notation ist unterschiedlich zu der bisher gelernten, jedoch semantisch gleich mächtig. a) Demonstration am Rechner b) Ergebnis ( Krähenfußdiagramm ): 0 * <pi> 19
20 Exkurs Anwendung mit einem Case-Tool (Power Designer): 2. Einfügen von Attributen bei dem Relationship-Typ (change to entity) a) Demonstration am Rechner b) Ergebnis: * 1 20
21 Exkurs Anwendung mit einem Case-Tool (Power Designer): 3. Check Modell ( Überprüfen auf syntaktische Fehler) 4. (Übersetzen des Modells in das relationale Modell) a) Demonstration am Rechner b) Ergebnis: enthält die gleichen Informationen wie die Tabellendarstellung 21
22 Aufgabe (m:n-beziehung): Setzen Sie das folgende EERM in ein äquivalentes relationales Modell um. a) Schreiben Sie direkt die Relationenschemata auf, die entstehen. b) Gehen Sie auf Papier so vor, wie es mit dem Power Designer funktioniert. Produkt (0,*) (0,*) 7 Kunde Produkt (Produktnummer, Bezeichnung, Preis) Kunde (Nummer, Name) 7: erhält geliefert (Anzahl, Lieferdatum) 22
23 4. Relationship-Typ: m:1-beziehung Die beteiligten Entity-Typen werden zunächst wie zuvor behandelt. Der Relationship-Typ erhält kein eigenes Relationenschema. Das Relationenschema, dessen Tupel nur maximal ein Mal in der Beziehung vorkommen dürfen, wird um eine Spalte ergänzt. Diese Spalte erhält den Namen des Primärschlüssel der anderen Relation und wird zum Fremdschlüssel. Zusätzlich werden bei diesem Relationship-Typ evtl. vorhandene Attribute des Relationship-Typs angebracht. Zusammengefasst: Es entstehen zwei Relationenschemata. Diese sind über die Schlüssel- /Fremdschlüssel-Beziehung miteinander verbunden, die durch Ergänzung der 1 -Relation um den Schlüssel der m -Relation entsteht. 23
24 m:1-beziehung (Beispiel): Markt (1,1) (0,*) 8 Veranstalter Markt (Bezeichnung, Standort, Kategorie) Veranstalter (Name, Adresse, Bezeichnung, Typ) 8: Ansprechpartner Markt: Bezeichnung Standort Name Kategorie Veranstalter: Name Adresse Bezeichnung Typ (Veranstalter-) Name wird in der Markt-Relation ergänzt und zum Fremdschlüssel. 24
25 Exkurs Anwendung mit einem Case-Tool (Power Designer): 1. Modellierung einer m:1-beziehung (Entity-Typ + Attribute): a) Demonstration am Rechner b) Ergebnis ( Krähenfußdiagramm ): * 0 1 <pi> 25
26 Exkurs Anwendung mit einem Case-Tool (Power Designer): 2. Einfügen von Attributen bei dem Relationship-Typ (change to entity) entfällt! 3. Check Modell ( Überprüfen auf syntaktische Fehler) 4. (Übersetzen des Modells in das relationale Modell) a) Demonstration am Rechner b) Ergebnis: enthält die gleichen Informationen wie die Tabellendarstellung <pk> 26
27 Aufgabe (m:1-beziehung): Setzen Sie das folgende EERM in ein äquivalentes relationales Modell um. a) Schreiben Sie direkt die Relationenschemata auf, die entstehen. b) Gehen Sie auf Papier so vor, wie es mit dem Power Designer funktioniert. Produkt (0,1) (0,*) 5 Dekor Produkt (Produktnummer, Bezeichnung, Größe, Preis) Dekor (Bezeichnung, Foto) 5: ist versehen mit 27
28 5. Relationship-Typ: 1:1-Beziehung Vorbemerkung: Es können theoretisch alle Attribute in ein Relationenschema gebracht werden, d.h. aus 2 Entity-Typen wird 1 Relationenschema. Diese Variante ist jedoch praktisch nicht sinnvoll, da es aus Anwendungssicht gute Gründe gegeben hat, zwei Entity-Typen zu erstellen. Ansonsten geht man wiefolgt vor: Die beteiligten Entity-Typen werden zunächst wie zuvor behandelt. Der Relationship-Typ erhält kein eigenes Relationenschema. Eines der beiden Relationenschemata wird um eine Spalte ergänzt. Diese Spalte erhält den Namen des Primärschlüssel der anderen Relation und wird zum Fremdschlüssel. Bei der 1:1-Beziehung ist es egal welche der beiden Relationen welche Rolle übernimmt. Zusammengefasst: Es entstehen zwei Relationenschemata. Diese sind über die Schlüssel- /Fremdschlüssel-Beziehung miteinander verbunden, die durch Ergänzung um ein Attribut in einer der Relationen entsteht. 28
29 6. Relationship-Typ: Rekursive Beziehungen Die beteiligten Entity-Typen werden wie zuvor behandelt. Bei m:n-beziehungen wird der Relationship-Typ zu einem eigenen Relationenschema, bei m:1-beziehungen ist dies nicht notwendig. Die Attribute des Relationship-Typs werden wie bei nicht-rekursiven Beziehungen gehandhabt.. Da die beteiligten Entity-Typen identisch sind, wird auch nur ein Relationenschema daraus erstellt. Zusammengefasst: Es entstehen zwei Relationenschemata bei einer m:n-beziehung und nur eines bei einer m:1-beziehung. Die Attribute und Schlüssel-/Fremd-Schlüssel werden so behandelt wie bei Beziehungen ohne Rekursion. 29
30 Relationship-Typ: Rekursive Beziehungen m:n Teilprodukt (0,*) 4 Produkt Rollen (0,*) Produktgruppe 4: besteht aus NummerO und NummerU werden zur Unterscheidung der beiden Nummern eingeführt. Sie sind jeweils Fremdschlüssel zu Nummer in Produkt. Produkt: Nummer Bezeichnung Funktion Besteht_aus: NummerO NummerU Anzahl 30
31 Relationship-Typ: Rekursive Beziehungen m:1 Teilprodukt (0,1) Produkt Rollen (0,*) Produktgruppe 4 31 NummerU wird zur Unterscheidung von Nummer eingeführt. Sie ist praktisch Fremdschlüssel zu Nummer in Produkt. Durch diese Konstruktion kann eine Hierarchie der Produkte (nichts anderes ist die rekursive 1:n-Beziehung) dargestellt werden. 4: besteht aus Produkt: Nummer Bezeichnung Funktion NummerU
32 Exkurs Anwendung mit einem Case-Tool (Power Designer): 1. Modellierung einer rekursiven m:n-beziehung (Entity-Typ + Attribute): a) Demonstration am Rechner b) Ergebnis ( Krähenfußdiagramm ): 0 * 1 32
33 Exkurs Anwendung mit einem Case-Tool (Power Designer): 2. Einfügen von Attributen bei dem Relationship-Typ (change to entity) entfällt! 3. Check Modell ( Überprüfen auf syntaktische Fehler) 4. (Übersetzen des Modells in das relationale Modell) a) Demonstration am Rechner b) Ergebnis: enthält die gleichen Informationen wie die Tabellendarstellung 33
34 Aufgabe (rekursive Beziehung): Setzen Sie das folgende EERM in ein äquivalentes relationales Modell um. a) Schreiben Sie direkt die Relationenschemata auf, die entstehen. b) Gehen Sie auf Papier so vor, wie es mit dem Power Designer funktioniert. c) Füllen Sie die Relation mit den folgenden Inhalten Fach (0,1) (0,*) 4 Fach (FNr, FName, SWS, CP) 4: ist Voraussetzung für Fach: FNr FName SWS CP 1 Pr Pr DB 4 5 und den Bedingungen Tupel mit FNr 1 ist Voraussetzung für Tupel mit FNr 2, Tupel mit FNr 2 ist Voraussetzung für Tupel mit FNr 3: 34
35 7. Relationship-Typ: mehrstellige Beziehung (n-stellig) Die beteiligten Entity-Typen werden wie zuvor behandelt. Der Relationship-Typ wird zu einem eigenen Relationenschema, bei Mehrstelligkeit i.d.r. unabhängig von den Kardinalitäten. Die Attribute des Relationship-Typs werden zu Attributen des neuen Relationenschemas. Zusätzlich werden die Primärschlüssel-Attribute aller (also mehr als 2) beteiligten Entity- Typen als Attribute des neuen Relationenschemas hinzugefügt, wobei gilt: Diese Primärschlüssel-Attribute bilden gemeinsam den Primärschlüssel des neuen Relationenschemas. Diese sind gleichzeitig Fremdschlüssel bezogen auf das Relationenschema, aus dem sie hervorgegangen sind. 35 Zusammengefasst: Es entstehen n+1 Relationenschemata (n = Anzahl der beteiligten Entity- Typen, eines für den Relationship-Typ und n für die Entity-Typen. Diese sind über Schlüssel- /Fremdschlüssel-Beziehungen miteinander verbunden. Hierzu werden die Schlüssel- Attribute der beteiligten Entity-Typen in das n+1. Relationenschema übertragen und dort zum Primärschlüssel.
36 Aufgabe (mehrstellige Beziehung): Setzen Sie das folgende EERM in ein äquivalentes relationales Modell um. Schreiben Sie direkt die Relationenschemata auf, die entstehen. Aufgabe: Setzen Sie das folgende ERM in Relationen um. Händler Spediteur (1,*) (1,*) 1 (1,*) Rohstoff 1: liefert (Bestelldatum, Menge) 36
37 Lösung zur Aufgabe (mehrstellige Beziehung): Händler Name Adresse Firmenbezeichnung Spediteur Name Adresse Firmenbezeichnung Rohstoff: Bezeichnung Art Liefert: HName SName Bezeichnung Bestelldatum Menge 37
38 8. Relationship-Typ: Generalisierung/Spezialisierung Zwei Varianten der Realisierung bei der Generalisierung/ Spezialisierung sind möglich: 1. Sowohl für den Generalisten als auch für die Spezialisten wird jeweils ein Relationenschema erstellt. Diese Variante ist sinnvoll bei partieller Spezialiserung und wenn eine Überlappung der Spezialisten möglich ist. Vorteil dieser Variante: keine Redundanzen. Jedes Relationen-Schema erhält alle Attribute, die der korrespondierende Entity-Typ bereits hatte. Jeder Spezialist erhält den Primärschlüssel des Generalisten als zusätzliches Attribut. Dieser ist Fremdschlüssel zu der Generalisten-Relation. Er kann auch gleichzeitig als Primärschlüssel beim Spezialisten genutzt werden (muss nicht). 2. Nur für die Spezialisten wird jeweils ein Relationenschema erstellt. Diese Variante ist nur möglich, wenn der Generalist eine abstrakte Klasse darstellt bzw. für den Generalisten keine Tupel existieren, was bedeutet, dass eine totale Spezialisierung vorliegen muss. Bei Überlappung liegt Redundanz vor. Vorteil bei der Abfrage: Nur eine Relation wird benötigt. Jedes Relationen-Schema (nur die Spzialisten) erhält alle Attribute, die der korrespondierende Entity-Typ bereits hatte. Jeder Spezialist erhält zusätzlich alle Attribute des Generalisten-Entity-Typs. 38
39 Relationship-Typ: Generalisierung/Spezialisierung (Beispiel) Geschäftspartner O Variante 1: Für alle Spezialisten und den Generalisten werden jeweils Relationenschemata erstellt. Die Spezialisten erben den Primärschlüssel des Generalisten. Bei Abfragen zu allen Attributen müssen 2 Relationen angesprochen werden. Veranstalter Kunde Generalist: Geschäftspartner (Geschäftspartner-Nr, Adresse, Telefonnummer) Spezialisten: Veranstalter (Bezeichnung, Typ) Kunde (Name) Geschäftspartner: Geschaeftspartner-Nr Adresse Telefonnummer Veranstalter: Geschaeftspartner-Nr Bezeichnung Typ Kunde: Geschaeftspartner-Nr Name 39
40 Relationship-Typ: Generalisierung/Spezialisierung (Beispiel) Geschäftspartner O Variante 2: Nur für die Spezialisten werden Relationen- Schemata erstellt. Diese übernehmen alle Attribute des Generalisten. Bei overlapping entstehen Redundanzen (Adresse, Telefonnummer). Veranstalter Kunde Generalist: Geschäftspartner (Geschäftspartner-Nr, Adresse, Telefonnummer) Spezialisten: Veranstalter (Bezeichnung, Typ) Kunde (Name) Veranstalter: Geschaeftspartner-Nr Adresse Telefonnummer Bezeichnung Typ Kunde: Geschäftspartner-Nr Adresse Telefonnummer Name 40
41 Aufgabe (Generalisierung/Spezialisierung): Setzen Sie folgende Generalisierung/Spezialisierung in ein äquivalentes relationales Modell um. a) Wählen Sie Variante 1. b) Wählen Sie Variante 2. Generalist: Dokument (DokumentenID, Titel, Standort) Spezialisten: Buch (ISBN, Autor) Zeitschrift (Jahrgang, ISSN) 41
42 Aufgabe : Quelle: Stefan Rühl 42
43 Lösung: Building (ID, Name) Janitor (ID, Name, Phone) Room (Number, Size, Building_ID, Janitor_ID) Is-Responsible-For (Janitor_ID, Building_ID, Position) Quelle: Stefan Rühl 43
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
MehrKapitel 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
MehrDatenbanken. 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
MehrRü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
Mehr3. Relationales Modell & Algebra
3. Relationales Modell & Algebra Inhalt 3.1 Relationales Modell Wie können wir Daten mathematisch formal darstellen? 3.2 Übersetzung eines konzeptuellen Modells Wie können wir ein konzeptuelles Modell
MehrDas relationale Datenmodell
Das relationale Datenmodell Konzepte Attribute, Relationenschemata, Datenbank-Schemata Konsistenzbedingungen Beispiel-Datenbank Seite 1 Einführung Zweck datenmäßige Darstellung von Objekten und Beziehungen
MehrKapitel 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
Mehr3. Relationales Modell & Algebra
3. Relationales Modell & Algebra Inhalt 3.1 Relationales Modell Wie können wir Daten mathematisch formal darstellen? 3.2 Übersetzung eines konzeptuellen Modells Wie können wir ein konzeptuelles Modell
MehrKapitel 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-46 Relational Design
MehrDieser 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,
MehrMedizininformatik Software Engineering
Vorlesung Software Engineering Inhaltsverzeichnis 1. Einleitung 2. Software und Medizinprodukt 3. Vorgehensmodelle 4. Strukturierter Entwurf von Echtzeitsystemen 4.1 Echzeit, was ist das? 4.2 Einführung
Mehr2. Relationale Datenbanken
2. Relationale Datenbanken Inhalt 2.1 Entity-Relationship-Modell 2.2 Relationales Modell 2.3 Relationale Entwurfstheorie 2.4 Relationale Algebra 2.5 Structured Query Language (SQL) 2 2.1 Entity-Relationship-Modell
MehrARIS 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
MehrDa ist zunächst der Begriff der Menge.
1 In diesem Abschnitt werden wir uns mit den theoretischen Grundlagen der relationalen Datenbanken beschäftigen. Hierzu werden wir uns die wichtigsten Konzepte, Ideen und Begriffe näher ansehen, damit
Mehr3. Das Relationale Datenmodell
! " # $ # $ % # $ 3. Das Relationale Datenmodell 1. Datenstruktur und Integritätsbedingungen 2. Abbildung zwischen ERM und RDM 3. Implementierung in SQL 4. Anomalien und Normalformen des RDM 5. Relationenalgebra
MehrUniversitä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
MehrArbeiten mit einer Datenbank 1
Arbeiten mit einer Datenbank 1 1. Datenmodelle 1.1 Das Entity-Relationship-Model (Objekt-Beziehungs-Modell) Bevor man in einem Datenbanksystem eine Datenbank aufbaut, muss man sich die Struktur der Datenbank
Mehr10. 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
MehrGrundlagen 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
MehrE-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
MehrEntitätstypen, Attribute, Relationen und Entitäten
Einführung Datenmodellierung Entitätstypen, Attribute, Relationen und Entitäten Wozu Datenbanken? Datenbanken dienen zur Speicherung und Verwaltung großer Datenbestände Beispiele: Adressdaten aller Kunden
MehrKapitel 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:
MehrKapitel 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
MehrKapitel 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:
Mehr2. Semantische Datenmodellierung
2. Semantische Datenmodellierung Datenmodell: System von Konzepten zur Beschreibung relevanter Daten Datenbankmodell: System von Konzepten zur Beschreibung von Datenbanksystemen (hierarchisches, Netzwerk-,
MehrKapitel 3: Datenbanksysteme
LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS Skript zur Vorlesung: Einführung in die Informatik: Systeme und Anwendungen Sommersemester 2013 Kapitel 3: Datenbanksysteme Vorlesung:
MehrDatenbanken: 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
Mehr5. Relationale Entwurfstheorie
5 Relationale Entwurfstheorie Motivation Konzeptuelles Modell (ERM) kann in ein relationales Schema mit möglichst wenigen Relationen übersetzt werden (vgl Kapitel 4) Welche Eigenschaften hat ein gutes
MehrAufgabe 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.
MehrAnwendungsentwicklung Datenbanken Datenbankentwurf. Stefan Goebel
Anwendungsentwicklung Datenbanken Datenbankentwurf Stefan Goebel Warum eine Datenbank? Nutzung von gleichen Daten durch viele Anwender auch an unterschiedliche Orten Daten können mit unterschiedlicher
MehrD1: 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
MehrVeranstaltung Pr.-Nr.: Datenmodellierung. Veronika Waue WS 07/08. Phasenschema der Datenbankentwicklung (grob) Informationsanalyse
Veranstaltung Pr.-Nr.: 101023 Datenmodellierung Veronika Waue WS 07/08 Phasenschema der Datenbankentwicklung (grob) Informationsanalyse Konzeptualisierung und Visualisierung (z.b. mittels ERD) (Normalisiertes)
MehrDatenbankanwendungen werden oft über einen sehr langen Zeitraum (z.b. Jahrzehnte) eingesetzt
2. Datenbankentwurf Motivation Datenbankanwendungen werden oft über einen sehr langen Zeitraum (z.b. Jahrzehnte) eingesetzt Fehler sind umso teurer zu beheben, je weiter die Entwicklung bzw. der Einsatz
Mehr4. Normalisierung von Relationenschemata
4. Normalisierung von Relationenschemata Ziel: Vermeidung von Anomalien in Relationenschemata wird erreicht durch systematische Vorgehensweise beim Datenentwurf vom eerm zum Relationalen Modell (s. voriges
MehrDatenbanksysteme: Entwurf
Wichtigste Themen hier: Datenbanksysteme: Entwurf DB Entwurf ist in der Regel eingebettet in ein größeres Projekt: siehe Informationssysteme Die Daten dienen einem Zweck und sind dennoch universell nutzbar:
MehrDas konzeptionelle Datenmodell
Das konzeptionelle Datenmodell Signifikanz der Datenmodellierung Anforderungsanalyse Effizienz der Anwendung. Redundanzfreiheit. Datenintegrität. Reibungsarme Umsetzung des Datenmodells in das physikalische
MehrKommunikation und Datenhaltung
Kommunikation und Datenhaltung von ER-Modellen auf das Relationenmodell Überblick über den Datenhaltungsteil Einleitung Motivation und Grundlagen Architektur von Datenbanksystemen Datenbankanfragen Relationenmodell
MehrEinführung SQL Data Definition Language (DDL)
Innsbruck Information System University of Innsbruck School of Management Universitätsstraße 15 6020 Innsbruck Einführung SQL Data Definition Language (DDL) Universität Innsbruck Institut für Wirtschaftsinformatik,
MehrTeil IV Datenbankentwurf
Teil IV Datenbankentwurf Datenbankentwurf 1 Phasen des Datenbankentwurfs 2 Weiteres Vorgehen beim Entwurf 3 Kapazitätserhaltende Abbildungen 4 ER-auf-RM-Abbildung Sattler / Saake Datenbanksysteme Letzte
MehrDatenmodelle und Datenbanken 2
Datenmodelle und Datenbanken 2 Prof. N. Fuhr Institut für Informatik und Interaktive Systeme Arbeitsgruppe Informationssysteme 24. Februar 2005 Hinweise zur Bearbeitung Die Zeit läuft erst, wenn Sie alle
MehrTheorie 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:
MehrEinführung in Datenbanken
Einführung in Datenbanken Dipl.-Inf. Michael Wilhelm Hochschule Harz FB Automatisierung und Informatik mwilhelm@hs-harz.de Raum 2.202 Tel. 03943 / 659 338 1 Inhalt 1. Grundlegende Begriffe der Datenbanktechnologie
MehrVorlesung DBIS I (WS 2005/2006) Teil 4
otivation Das Relationenmodell Vorlesung Prof. Johann Christoph Freytag, Ph.D. Institut für Informatik Humboldt-Universität zu Berlin WS 2005/2006 Ziel des Relationenmodells Hoher Grad an Datenunabhängigkeit
MehrVorlesung Datenbankmanagementsysteme
Vorlesung Datenbankmanagementsysteme Relationaler Datenbankentwurf II Vorlesung Datenbankmanagementsysteme Relationaler Datenbankentwurf II M. Lange, S. Weise Folie #6-1 Wiederholung Relationaler Datenbankentwurf
MehrKlausur Konzeptionelle Modellierung
Klausur Konzeptionelle Modellierung Braindump Wintersemester 2012/2013 Inhaltsverzeichnis 1 Allgemeines 2 1.1 Begriffe............................... 2 1.2 Konzeptionelles Schema..................... 2
MehrKapitel 6: Das E/R-Modell
Ludwig Maximilians Universität München Institut für Informatik Lehr- und Forschungseinheit für Datenbanksysteme Skript zur Vorlesung Wintersemester 2013/2014 Vorlesung: Prof. Dr. Christian Böhm Übungen:
MehrModellierungskonzepte semantischer Datenmodelle. Semantische Datenmodelle. Das Entity-Relationship Modell
DEVO. Semantische Datenmodelle DEVO.4 Modellierungskonzepte semantischer Datenmodelle Äquivalente Begriffe: Objekttypenebene = Objektklassenebene = Schema (Schema-level), Objektebene = Exemplarebene (Instance-level)
Mehr5.2 Entity-Relationship-Modell
5.2 Entity-Relationship-Modell Mod-5.8 Entity-Relationship-Modell, ER-Modell (P. Chen 1976): Kalkül zur Modellierung von Aufgabenbereichen mit ihren Objekten, Eigenschaften und Beziehungen. Weitergehende
MehrDatenbanken. Rückblick: Datenbank-Entwurfsprozess. Semantische Datenmodellierung (vgl. Kapitel 2)
Rückblick: Datenbank-Entwurfsprozess Semantische Datenmodellierung (vgl. Kapitel 2) Überführung des semantischen Datenmodells in das relationale Modell (vgl. Kapitel 3) Das relationale Modell wird in eine
MehrRelationale Datenbanken
Ramon A. Mata-Toledo, Pauline K. Cushman Relationale Datenbanken Schaum's Repetitorien Übersetzung aus dem Amerikanischen von G&U Technische Dokumentation GmbH Z Die Autoren 9 Vorwort 9 1 Ein Überblick
MehrSoftware-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
MehrVom 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
MehrKapitel 3: Datenbanksysteme
LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS Skript zur Vorlesung: Einführung in die Informatik: Systeme und Anwendungen Sommersemester 2018 Kapitel 3: Datenbanksysteme Vorlesung:
Mehrzu E 1 der Form (0, 1) erfüllen.
1 Aufgabe 4.1: Sei B ein Beziehungstyp über den drei Entitätstypen E 1, E 2 und E 3. Sei ohne Beschränkung der Allgemeinheit die Beziehungskomplexität zu E 1 der Form (0, 1). Wir zeigen, dass B durch die
MehrDatenmodelle. 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
MehrDatenmodelle dienen der Darstellung der Informationsstruktur, nicht der Darstellung der Informationen selbst. Motivation
Einführung in das Entity-Relationship-Modell Datenmodelle Datenmodelle dienen der Darstellung der Informationsstruktur, nicht der Darstellung der Informationen selbst. Motivation Grundbestandteile von
MehrLogischer Entwurf. Stufen der Entwicklung einer Datenbank. Inhalt. Übersicht. 1. Datenbank - Entwurf ( ER - Diagramm)
10. Logischer Entwurf 10-1 10. Logischer Entwurf 10-2 Stufen der Entwicklung einer Datenbank 1. Datenbank - Entwurf ( ER - Diagramm) Logischer Entwurf 2. Umsetzen des ER - Diagramms ins relationale Modell
MehrEinführung in die Datenorganisation. Informationssysteme
Einführung in die Datenorganisation Informationssysteme Informationen Sind Kenntnisse über Sachverhalte Daten sind abgelegte Informationen Nachrichten sind Informationen zur Weitergabe Drei Betrachtungsebenen
MehrDieser 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,
Mehr3. 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
MehrDatenbanken 1. Kapitel 2: Datenbankentwurf. Ansprechpartner hat Name Adresse. Geschaeftspartner <pi> Characters (30) Characters (50) ist.
Datenbanken 1 Kapitel 2: Datenbankentwurf Ansprechpartner hat Name Adresse Geschaeftspartner Characters (30) Characters (50) ist Haendler Rabatt Integer Spediteur Verfuegbar Characters (20) Kunde
MehrDieser 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,
MehrTeil 2-5. Vorlesung. Modul: Programmierung B-PRG Grundlagen der Programmierung II
Teil 2-5. Vorlesung Modul: Programmierung B-PRG Professur für Datenbanken und Informationssysteme Dr. Karsten Tolle tolle@dbis.cs.uni-frankfurt.de 1 2 Fahrplan Heute: ER relationales Modell Nächste Woche:
MehrTeil III Entity-Relationship-Modell
Teil III Entity-Relationship-Modell Entity-Relationship-Modell 1 Datenbankmodell 2 ER-Modell 3 Weitere Konzepte im ER-Modell Sattler / Saake Datenbanksysteme Letzte Änderung: Okt. 2016 3 1 Lernziele für
MehrFolien zum Textbuch. Kapitel 2: Planung, Entwicklung und Betrieb von IS. Teil 3: Modellierung von betrieblichen Informationssystemen
Folien zum Textbuch Kapitel 2: Planung, Entwicklung und Betrieb von IS Teil 3: Modellierung von betrieblichen Informationssystemen Textbuch-Seiten 185-208 WI Planung, Entwicklung und Betrieb von IS IS-Modellierung
MehrGrundlagen der Programmentwurfstechnik Fundamentals of Software Engineering 1
Fundamentals of Software Engineering 1 Inhaltsverzeichnis 1. Einführung 2. Allgemeine Modellbildung - Klassische Konzepte des Software Engineering- 2.1 Das Kontextmodell 2.2 Entscheidungstabellen 2.3 Zustandsmodelle
MehrKapitel 1: Wiederholungsfragen Grundlagen DBS
Grundlagen DBS 1. Welche zentralen Anforderungen an ein DBS definierte Edgar Codd? 2. Was ist eine Transaktion? 3. Welche Eigenschaften muss das DBMS bei der Transaktionsverarbeitung sicherstellen? 4.
MehrDatenbanken 1. Kapitel 3: Relationenmodell WURDE_VERKAUFT INTEGER PRODNR. <pk,fk1> <pk,fk2> PRODNR = PRODNR SHOPID = SHOPID SHOPID INTEGER INTEGER
Datenbanken 1 Kapitel 3: Relationenmodell WURDE_VERKAUFT PRODNR = PRODNR PRODNR SHOPID ANZAHL INTEGER INTEGER INTEGER SHOPID = SHOPID PRODUKT SHOP PRODNR BEZEICHNUNG PREIS INTEGER VARCHAR2(20)
MehrTeil V Relationaler Entwurf
Teil V Relationaler Entwurf Relationaler Entwurf 1 Zielmodell des logischen Entwurfs 2 Relationaler DB-Entwurf 3 Normalformen 4 Transformationseigenschaften 5 Weitere Abhängigkeiten Sattler / Saake Datenbanksysteme
MehrDatenintegrität. Kapitel 5 1
Datenintegrität Integitätsbedingungen Schlüssel Beziehungskardinalitäten Attributdomänen Inklusion bei Generalisierung statische Integritätsbedingungen Bedingungen an den Zustand der Datenbasis dynamische
MehrÜbungsblatt DB:IV. Abzugeben sind, bis , Lösungen zu den Aufgaben 1d, 1e, 3, 7, 9, 12. Aufgabe 1 : Datenintegrität
Datenbanken WS 2012/13 8. November 2012 Übungsblatt DB:IV Abzugeben sind, bis 19.11.2012, Lösungen zu den Aufgaben 1d, 1e, 3, 7, 9, 12. Aufgabe 1 : Datenintegrität (a) Welche Arten von Integritätsbedingungen
MehrDer 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
MehrEinfü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
MehrDatenbanksysteme Teil 3 Indizes und Normalisierung. Stefan Maihack Dipl. Ing. (FH) Datum:
Datenbanksysteme Teil 3 Indizes und Normalisierung Stefan Maihack Dipl. Ing. (FH) Datum: 01.11.2005 1 MySQL - Normalisierung Durch die Normalisierung von Tabellen soll folgendes erreicht werden Redundanzfreie,
MehrGliederung Datenbanksysteme
Gliederung Datenbanksysteme 1. Einführung Datenbanksysteme: Informationssysteme für das Controlling 2. Informationsstrukturierung: Semantische Datenmodellierung 1. Informationsstrukturmodell und Entity-Relationship-Modell
MehrPD Dr.-Ing. F. Lobeck. Seite 6
Seite 6 Datenbanken Datenbank: Eine geordnete Menge von Daten. Speicherung erfolgt unabhängig von speziellen Anwenderprogrammen. Ebenso sollte die Hardwareunabhängigkeit gesichert werden. Zu einem Datenbankmanagementsystem
MehrHandout zur Unit Datenmodellierung Web-Technologien Datenmodellierung Prof. Dr. rer. nat. Nane Kratzke
Handout zur Unit Web-Technologien 1 Prof. Dr. rer. nat. Nane Kratzke Praktische Informatik und betriebliche Informationssysteme Raum: 17-0.10 Tel.: 0451 300 5549 Email: nane.kratzke@fh-luebeck.de (Praktische
MehrKapitel 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
MehrRü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
Mehr7. Datenbankdefinitionssprachen
7. Datenbankdefinitionssprachen SQL-DDL Teil der Standardsprache für relationale Datenbanksysteme: SQL ODL (Object Definition Language) für objektorientierte Datenbanksysteme nach dem ODMG-Standard VL
MehrVorlesung 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
Mehrkonzeptionelles DB-Design
konzeptionelles DB-Design was ist das? Systemunabhängige Darstellung des Datenmodells Was ist bei allen möglichen Datenbanksystemen gleich --> Systemtheorie Informationen über Objekte (Dinge) mit Attributen
MehrDatenintegrität. Kapitel 5 1
Datenintegrität Integitätsbedingungen Schlüssel Beziehungskardinalitäten Attributdomänen Inklusion bei Generalisierung statische Integritätsbedingungen Bedingungen an den Zustand der Datenbasis dynamische
MehrProgrammierung und Datenbanken II
Programmierung und Datenbanken II Wiederholung Was haben wir bisher getan? Anwendungsbereich analysiert Datenobjekte + Beziehungen identifiziert Modelle erstellt Modellhafte Aufbereitung der Analyse (ERM/SERM)
MehrEntwurf eines Datenbanksystems für eine Schule. Datenbanksysteme. Wintersemester 2004/05. Patrice Calvin Taffou Happi
Entwurf eines Datenbanksystems für eine Schule Datenbanksysteme Wintersemester 2004/05 Patrice Calvin Taffou Happi (taffou@tzi.de) Ruben Rothaupt (rubenr@tzi.de) Inhalt 1. Einleitung 2. Anwendungsbeschreibung
MehrGrundlagen 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,
MehrKapitel DB:IV. IV. Logischer Datenbankentwurf mit dem relationalen Modell
Kapitel DB:IV IV. Logischer Datenbankentwurf mit dem relationalen Modell Das relationale Modell Umsetzung ER-Schema in relationales Schema DB:IV-2 Relational Design STEIN 2004-2018 Das relationale Modell
MehrDatenbankentwurf. Kapitel 3. Datenbankentwurf 76 / 508
Kapitel 3 Datenbankentwurf 76 / 508 Phasen des Datenbankentwurfs Phasen des Datenbankentwurfs Anforderungsanalyse Spezifikation Konzeptueller Entwurf Konzeptuelles Schema Logischer Entwurf Logisches Schema
MehrDatenbanken. Teil 2: Informationen. Kapitel 2: Einführung. Zusammenfassung der Grundbegriffe. Übersicht über wichtige Grundbegriffe:
Datenbanken Einführung Seite 1 von 17 Datenbanken Teil 2: Informationen Kapitel 2: Einführung Zusammenfassung der Übersicht über wichtige : 1. Merkmal,, 2., 3., 4., nname 5. Beziehungstabelle, zusammengesetzter
MehrInhalte der Veranstaltung
Inhalte der Veranstaltung 5. Anwendungssysteme 5-4 6. Entwurf von Anwendungssystemen 6.1 Datenmodellierung 6-1 6.2 Geschäftsprozessmodellierung 6-32 6.3 Entwurf von Datenbanken 6-79 6.4 Nutzung von Datenbanken
Mehr