advertisement

Kapitel4

33 %
67 %
advertisement
Information about Kapitel4
Entertainment

Published on October 24, 2007

Author: Nivedi

Source: authorstream.com

advertisement

Kapitel 4: Datenbankentwurf:  Kapitel 4: Datenbankentwurf Einführung UML Modellierung Schematransformation Normalisierung Kapitel 4: Datenbankentwurf:  Kapitel 4: Datenbankentwurf Einführung UML Modellierung Schematransformation Normalisierung Einordnung (1) :  Einordnung (1) Grundsätzliche Organisation des DBMS Organisation der DB für eine bestimmte Miniwelt Beschreibung eines bestimmten Zustands der Miniwelt DB-Entwurf DB-Betrieb Einordnung (2):  Einordnung (2) Primärdaten Externes Datenmodell Anfragebearbeitung Internes Datenmodell Satz- u. Satzmengenverwaltung Physische Datenstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Dateien Dateiverwaltung Geräteschnittstelle Daten- wörterbuch Metadaten Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung Anforderungen an rel. Datenbasisschema:  Anforderungen an rel. Datenbasisschema Passende Informationskapazität: Datenbasis muss genügend großen Zustandsraum besitzen, um alle relevanten Zustände der Miniwelt abzubilden, aber nicht mehr. Intuitivität: Gruppierung der Attribute zu Relationen sollte semantische Zusammenhänge der Miniwelt widerspiegeln. Anfragen sollten in möglichst natürlicher Weise formuliert werden können. Effizienz: Zusammenführung der Daten bei Lese-Operationen sollte möglichst wenig Verbindungs-Operationen (Joins) erfordern. Überwachung der Konsistenzbedingungen bei Schreib-Operationen sollte möglichst wenig Aufwand erfordern. Aufgabe:  Aufgabe Datenbankentwurf: Methodisches Vorgehen zur Modellierung der Miniwelt und Überführung in ein Datenbasisschema. Nachdruck auf Informationskapazität und Intuitivität Einflussfaktoren: Semantische Lücke zwischen Gegebenheiten der Miniwelt und Typsystem + Konsistenzregeln des Datenmodells Hohe Kosten nachträglicher Schema-Änderungen Lösung (1):  Lösung (1) Naheliegender Ansatz: Überwinde semantische Lücke nicht in einem Schritt, sondern sukzessive. Üblich sind zwei Abbildungsschritte: Zwischenschalten einer weiteren Modellierungsebene (sog. konzeptuelle Modellierungsebene) zwischen Miniwelt und Datenmodell. Vorteil: Modellierungs-Elemente der konzeptuellen Ebene müssen nicht implementiert werden, daher keine Einschränkung der Ausdrucksmächtigkeit zugunsten von Effizienz erforderlich. Abbildung von konzeptueller auf Datenmodell-Ebene hat definierte Spielräume, bietet daher Entwurfsfreiräume für Kompromisse zwischen den Anforderungen. Lösung (2):  Lösung (2) Anforderungen an Semantisches Datenmodell: Ausdrucksmächtigkeit Aspekt-Vielfalt Klare Semantik Standardisierung Werkzeugunterstützung Lösung (3):  Lösung (3) Relationales Datenmodell UML (intuitiv) Erweitert relational (formal) makroskopischeBetrachtung mikroskopischeBetrachtung Überarbeitung Schematransformation Kapitel 4: Datenbankentwurf:  Kapitel 4: Datenbankentwurf Einführung UML Modellierung Schematransformation Normalisierung Makroskopische Betrachtung:  Beschränkung auf die für den Datenbankentwurf bedeutsamen Konstrukte Makroskopische Betrachtung Systemanalytischer Ausgangspunkt: Klassischer Systembegriff als Ansammlung von Objekten und von Beziehungen, die zwischen den Objekten bestehen. Primäres Strukturierungsmittel: Klassifikation zu Mengen irgendwie als ähnlich angesehener Objekte. Vorgehen: Informell, pragmatisch, stark graphisch orientiert. Historie: Entity-Relationship Modeling (ERM) Object Modeling Technique (OMT) Unified Modeling Language (UML) Diagramme von UML:  Diagramme von UML (1) Anwendungsfalldiagramm (use case diagram) (2) Klassendiagramm (class diagram) (3) Sequenzdiagramm (sequence diagram) (4) Kollaborationsdiagramm (collaboration diagram) (5) Zustandsdiagramm (statechart diagram) (6) Aktivitätsdiagramm (activity diagram) (7) Komponentendiagramm (component diagram) (8) Verteilungsdiagramm (deployment diagram) Implementierungs- diagramme (implementation diagrams) Interaktions- diagramme (interaction diagrams) Verhaltens- diagramme (behavior diagrams) Struktur- diagramm UML-Klassendiagramm: Klassen:  UML-Klassendiagramm: Klassen Basiselemente des Klassendiagramms: Objekt: Modell eines wohlunterscheidbaren Gegenstandes in der Miniwelt. Klasse: Repräsentant einer Menge von Objekten. Definition einer Klasse setzt sich aus Attributen und Operatoren zusammen. Beispiele: Flüge, Flugzeugtypen, Flughäfen, Kunden, Tickets. Darstellung: UML-Klassendiagramm: Zusicherungen:  UML-Klassendiagramm: Zusicherungen Zusicherungen: Ergänzung von Klassenbeschreibungen durch einfache Konsistenzbedingungen. Beispiele: Einschränkung des Wertebereichs eines Attributs über den Datentyp hinaus, Aufrufbedingungen für Operatoren, Schlüsselbedingungen. UML-Klassendiagramm: Vererbung:  UML-Klassendiagramm: Vererbung Generalisierung: Zusammenführen mehrerer Klassen zu einer Klasse durch Beschränkung auf ihre gemeinsamen Eigenschaften. Spezialisierung: Gewinnen mehrerer neuer Klassen aus einer Klasse durch Hinzufügen unterschiedlicher spezieller Eigenschaften. Darstellung: Semantik: Vererbung von Eigenschaften der Oberklassen an die entsprechenden Unterklassen. Kunde Internetkunde Reisebürokunde UML-Klassendiagramm: Assoziationen (1):  UML-Klassendiagramm: Assoziationen (1) Objektverbindung: Beziehung zwischen individuellen Objekten. Assoziation: Klassifikation einer Menge von Objektverbindungen, definiert zwischen Klassen. Gewöhnlich zwischen verschiedenen Klassen, darf aber auch reflexiv sein. Stelligkeit einer Assoziation: Anzahl der Objekte, die an den individuellen Objektverbindungen teilhaben. Nicht beschränkt, binärer Fall jedoch am häufigsten. Notation binär: Flug Flugzeugtyp UML-Klassendiagramm: Assoziationen (2):  UML-Klassendiagramm: Assoziationen (2) Jede Assoziation wird mit einem Assoziationsnamen versehen, der beschreibt, worin die Beziehung besteht. Assoziationsnamen haben dann natürliche Leserichtung von einem Klassennamen zum anderen, die man durch einen Pfeil neben dem Namen kennzeichnet. Assoziationsnamen können für beide Leserichtungen notiert werden: Flug Flugzeugtyp UML-Klassendiagramm: Assoziationen (3):  UML-Klassendiagramm: Assoziationen (3) Bei drei- und mehrstelligen Assoziationen entfällt Leserichtung. Assoziationen können als eigene Assoziationsklasse ausgebildet und mit Attributen versehen werden: Kunde Ticket Flug UML-Klassendiagramm: Assoziationen (4):  UML-Klassendiagramm: Assoziationen (4) Assoziationen belassen viel Spielraum für die Modellierung. Gleiche Sachverhalte können unterschiedlich modelliert werden: Kunde Flug TicketNr: string platzCode: string datum: date UML-Klassendiagramm: Assoziationen (5):  UML-Klassendiagramm: Assoziationen (5) Multiplizität der Assoziation bezüglich einer Klasse: Anzahl der individuellen Objektverbindungen, die eine Instanz dieser Klasse eingehen kann. Im zweistelligen Fall: Mit wie vielen Objekten der gegenüberliegenden Klasse kann ein Objekt der Klasse verbunden sein? Vermerk in Leserichtung, also bei der gegenüberliegenden Klasse. 1.. 1 Flug Flugzeugtyp UML-Klassendiagramm: Assoziationen (6):  UML-Klassendiagramm: Assoziationen (6) Multiplizität bei mehrstelligen Assoziationen hat wenig intuitive UML-Definition: Betrachte bei Stelligkeit n Kombination von n-1 Objekten und bestimme, mit wie vielen Objekten der verbleibenden Klasse sie verbunden sein kann. 1 0..1 1..5 Kunde Ticket Flug Multiplizität gilt für Flug als Flugbewegung, nicht als Flugplanung! Flugbewegung, wenn Datum zur Differenzierung mit einbezogen werden könnte. In UML nicht vorgesehen! Mit Multiplizitäten lassen sich also Unstimmigkeiten bei der Modellierung aufdecken! UML-Klassendiagramm: Assoziationen (7):  UML-Klassendiagramm: Assoziationen (7) Anbindung von Zusicherungen an Assoziationen: {k1,k2Kunde: k1.Buchung.TicketNr = k2.Buchung.TicketNr  k1=k2} Alternativ: Das selbe Ticket gehört unabhängig vom Flug zu genau 1 Kunden! 1 0..1 1..5 Kunde Ticket Flug UML-Klassendiagramm: Assoziationen (8):  UML-Klassendiagramm: Assoziationen (8) Rolle: Sichtweise eines Objektes durch das gegenüberliegende Objekt. Besonders bei reflexiven Assoziationen interessant. Flug Ankommend 0.. 1 Abgehend UML-Klassendiagramm: Assoziationen (9):  UML-Klassendiagramm: Assoziationen (9) Gerichtete Assoziation: Assoziation, die nur in einer Richtung traversiert werden soll. (Als Optimierungshinweis für Implementierung aufzufassen.) Notation durch offene Pfeilspitze: Flug Ankommend 0.. 1 Abgehend UML-Klassendiagramm: Aggregationen:  UML-Klassendiagramm: Aggregationen Aggregation: Ganzes-Teile-Beziehung als Sonderfall einer Assoziation. Aggregationen dürfen Multiplizitäten aufweisen, jedoch gehört ein Teil nur zu höchstens einem Ganzen. Existenzgebunden , andernfalls . Flughafen Terminal Flugsteig 1..5 1..20 UML-Klassendiagramm: Beispiel:  von nach 1 1 1.. 1..5 1.. 1.. 1 WirdGeflogenMit Gibt SitzeinteilungVorFür 0..1 1 PlatzCode Datum Buchung Flugzeugtyp FtypId {eindeutig} Name First Business Economy Flug FlugNr {eindeutig} Wochentage Entfernung Ticket TicketNr {eindeutig} Kunde Name {eindeutig} Telefon Flughafen FlughCode {eindeutig} Stadt Land Name Zeitzone {k1,k2  Kunde: k1.Buchung.Ticket= k2.Buchung.Ticket  k1=k2} UML-Klassendiagramm: Beispiel UML-Klassendiagramm: Faustregeln:  UML-Klassendiagramm: Faustregeln Klasse oder Assoziation? Will man über einen Sachverhalt Aussagen machen, wozu man Methoden benötigt, so sollte er als Klasse erfasst werden. Dient ein Sachverhalt lediglich dazu, eigentlich interessierende Sachverhalte zu verknüpfen, so ist für ihn eine Assoziation zu wählen. Kapitel 4: Datenbankentwurf:  Kapitel 4: Datenbankentwurf Einführung UML Modellierung Schematransformation Normalisierung Abbildung UML-Schema  Rel. Schema (1):  Abbildung UML-Schema  Rel. Schema (1) Abbildungsregeln für Klassen: Klasse mit allen Attributen  Relation (sog. Objektrelation). Atomarer Datentyp des UML-Klassendiagramms  Übernahme des Attributs, Überführung Datentyp in Domäne des relationalen Schemas. Verbund-Datentyp des UML-Klassendiagramms  Pro Verbundelement: Übernahme von dessen Attribut, Überführung von dessen Datentyp in Domäne des relationalen Schemas. Mengenorientierte Datentypen des UML-Klassendiagramms  Übernahme des Attributs, Nachbearbeitung der zunächst ja nicht atomaren Domäne. Für Zwecke der Transformation auf relationale Schemata müssen Schlüssel unmittelbar im Klassendiagramm in Form von Zusicherungen vermerkt werden  Schlüssel der Relation. Abbildung UML-Schema  Rel. Schema (2):  Abbildung UML-Schema  Rel. Schema (2) Abbildungsregeln für binäre Assoziationen C1 — C2 mit Multiplizität an C2  1: Seien RC1, RC2 die Objektrelationen zu C1, C2. Füge zu RC1 Schlüsselattribute von RC2 hinzu, wobei bei Namenskonflikten der Assoziationsname als Präfix vorangestellt wird. Im späteren Betrieb nehmen diese Attribute in jedem RC1-Tupel den Schlüssel des assoziierten RC2-Tupels auf (Fremdschlüssel). Ist an C2 die Multiplizität 0..1, so können hier NULL-Werte auftreten. Falls die Assoziation attributiert ist, werden die Attribute ebenfalls C1 zugeschlagen. Behandlung von binären Assoziationen C1 — C2 mit Multiplizität an C1  1 entsprechend. Abbildung UML-Schema  Rel. Schema (3):  Abbildung UML-Schema  Rel. Schema (3) Abbildungsregeln für ternäre und höhere Assoziationen: Betrachte Assoziation A als eigene Klasse CA mit einer separaten binären Assoziation zu jeder an A beteiligten Klasse Ci, dort mit Multiplizität 1. Bilde CA auf separate Relation RA ab (Assoziationsrelation). Attribute von RA sind die Schlüsselattribute jeder Objektrelation RCi sowie alle Attribute der Assoziation selber. Bei Namenskonflikten wird den Fremdschlüsselattributen von der jeweilige Rollen- oder Klassenname als Präfix vorangestellt. Alle Attribute bilden gemeinsam den Schlüssel von RA. Nachbearbeitung zur Reduktion des Schlüssels. Im Betrieb wird für jede konkrete Objektverbindung ein Tupel in RA eingefügt. Die Attribute dieses Tupels enthalten die Schlüssel der beteiligten RCi-Tupel als Fremdschlüssel. Abbildung UML-Schema  Rel. Schema (4):  Abbildung UML-Schema  Rel. Schema (4) Abbildung von Vererbung erfordert Simulation der Zugehörigkeit von Objekten zu Oberklassen. Beispiel für Abbildungen: Jedes Objekt wird ausschließlich durch ein Tupel in derjenigen Objektrelation repräsentiert, die seinem spezifischsten Typ entspricht. Alle ererbten Attribute einer Klasse werden mit in die Objektrelation aufgenommen. Für jedes Objekt wird ein Tupel in allen Objektrelationen angelegt, die Oberklassen (inklusive der direkten Klasse) des Objekts entsprechen. Jede Objektrelation erhält nur die Schlüsselattribute der Klasse sowie die unmittelbar in der Klasse definierten, nicht ererbten Attribute. Da alle Tupel den gemeinsamen Schlüssel erhalten, ist die Zugehörigkeit zu Oberklassen implizit repräsentiert, muss dann aber von jeder Applikation nachvollzogen werden. Abbildung UML-Schema  Rel. Schema (5):  von nach 1 1 1.. 1..5 1.. 1.. 1 WirdGeflogenMIt Gibt SitzeinteilungVorFür 0..1 1 PlatzCode Datum Buchung Flugzeugtyp FtypId {eindeutig} Name First Business Economy Flug FlugNr {eindeutig} Wochentage Entfernung Ticket TicketNr {eindeutig} Kunde Name {eindeutig} Telefon Flughafen FlughCode {eindeutig} Stadt Land Name Zeitzone {k1,k2  Kunde: k1.Buchung.Ticket= k2.Buchung.Ticket  k1=k2} Anwendung der Regeln: KUNDE (Name, Telefon) TICKET (TicketNr) BUCHUNG (TicketNr, FlugNr, Name, PlatzCode, Datum) FLUGHAFEN (FlughCode, Name, Stadt, Land, Zeitzone) FLUG (FlugNr, Wochentage, Entfernung, FtypId, von, nach, Abflugszeit, Ankunftszeit) FLUGZEUGTYP (FtypId, Name, First, Business, Economy) Eindeutigkeits-Zusicherungen berücksichtigt, Multiplizitäten zum Teil verloren gegangen. Abbildung UML-Schema  Rel. Schema (5) Abbildung UML-Schema  Rel. Schema (6):  von nach 1 1 1.. 0..5 1.. 1.. 1 WirdGeflogenMIt Gibt SitzeinteilungVorFür 0..1 1 PlatzCode Datum Buchung Flugzeugtyp FtypId {eindeutig} Name First Business Economy Flug FlugNr {eindeutig} Wochentage Entfernung Ticket TicketNr {eindeutig} Kunde Name {eindeutig} Telefon Flughafen FlughCode {eindeutig} Stadt Land Name Zeitzone {k1,k2  Kunde: k1.Buchung.Ticket= k2.Buchung.Ticket  k1=k2} Anwendung der Regeln: KUNDE (Name, Telefon) TICKET (TicketNr, Name) BUCHUNG (TicketNr, FlugNr, PlatzCode, Datum) FLUGHAFEN (FlughCode, Name, Stadt, Land, Zeitzone) FLUG (FlugNr, Wochentage, Entfernung, FtypId, von, nach, Abflugszeit, Ankunftszeit) FLUGZEUGTYP (FtypId, Name, First, Business, Economy) Abbildung UML-Schema  Rel. Schema (6) Kapitel 4: Datenbankentwurf:  Kapitel 4: Datenbankentwurf Einführung UML Modellierung Schematransformation Normalisierung Motivation:  Motivation Nachbearbeitung eines bereits konstruierten relationalen Schemas mit dem Ziel einer Qualitätsverbesserung. Qualitätsverbesserung hier: Durchsetzen der Konsistenzbedingungen mit einem Minimum an Aufwand zur Laufzeit. Ausnutzen einer Erweiterung des relationalen Datenmodells für ein präzises, theoretisch untermauertes Vorgehen. Vorgehen:  Vorgehen Mikroskopische Betrachtung einzelner Relationen auf bestimmte Formen von Konsistenzbedingungen (sog. Abhängigkeiten), die aufgrund der Gegebenheiten der Miniwelt für diese Relation gelten müssen. Überarbeitung: Aufstellen der Abhängigkeiten. Zerlege eine Relation nach gewissen Regeln, die die Abhängigkeiten ausnutzen, so in Teilrelationen, dass die Durchsetzung der Konsistenzbedingungen ein Minimum an Aufwand zur Laufzeit erfordert. Schematransformation): Algorithmisch. Ergebnis des Verfahrens ist eine verfeinerte Menge von Relationen (genauer: Relationstypen) mit Schlüssel- und Fremdschlüsselbedingungen, die das gesuchte Datenbankschema darstellt. Beispielszenario (1):  Beispielszenario (1) Sei Ergebnis der UML-Schematransformation die Relation FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) Beispielszenario (2):  Beispielszenario (2) flugNr von nach ftyp wochent ab an entf ticketNr platz datum name ---------------------------------------------------------------------------------------- ... LH458 MUC SFO 744 MDMDFSS 1220 1445 9130 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 MDMDFSS 1220 1445 9130 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 MDMDFSS 1355 0990 9130 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 MDMDFSS 1355 0990 9130 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB6 MDMDFSS 1330 1410 654 7216080816 20A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB6 MDMDFSS 1330 1410 654 7216083968 05E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 -D-D-S- 2235 0530 9585 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 -D-D-S- 2235 0530 9585 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 -D-D-S- 2235 0530 9585 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 -D-D-S- 2235 0530 9585 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH501 GIG FRA 340 --M-F-S 1325 0550 9585 7216087337 02K 22-SEP-00 Nimis_Mr_J LH6390 SIN SYD 744 MDMDFSS 2015 0550 6298 7216083911 82A 06-AUG-00 Weinand_Mr_C LH6390 SIN SYD 744 MDMDFSS 2015 0550 6298 7216084065 24G 09-SEP-00 Pulkowski_Mr_S LH6391 SYD SIN 744 MDMDFSS 1550 2150 6298 7216084065 54J 20-OCT-00 Pulkowski_Mr_S LH6488 SFO HNL D10 MDMDFSS 1745 2204 3853 7216084066 03A 01-SEP-00 Schmitt_Mrs_B LH6489 HNL SFO D10 MDMDFSS 2125 0520 3853 7216084066 02A 22-SEP-00 Schmitt_Mrs_B LH676 FRA ALY 319 -D--FSS 1330 1825 2741 7216087336 12A 04-AUG-00 Nagi_Mr_K LH677 ALY FRA 319 M-M--SS 0745 1100 2741 7216087336 15F 23-AUG-00 Nagi_Mr_K LH710 FRA NRT 744 MDMDFSS 1350 0745 9360 7216082757 34D 10-SEP-00 Witte_Mr_R LH710 FRA NRT 744 MDMDFSS 1350 0745 9360 7216083495 01K 11-AUG-00 Gimbel_Mr_M LH711 NRT FRA 744 MDMDFSS 1010 1450 9360 7216083495 02B 26-AUG-00 Gimbel_Mr_M LH778 FRA SIN 744 MDMDFSS 2215 1605 10264 7216083911 83K 05-AUG-00 Weinand_Mr_C LH778 FRA SIN 744 MDMDFSS 2215 1605 10264 7216084065 33K 08-SEP-00 Pulkowski_Mr_S LH779 SIN FRA 744 MDMDFSS 2305 0545 10264 7216084065 56B 20-OCT-00 Pulkowski_Mr_S ... Abhängigkeiten:  Abhängigkeiten Überarbeitung beruht auf Abhängigkeiten zwischen Attributen als speziellen Konsistenzbedingungen. Varianten: Funktionale Abhängigkeiten als Verallgemeinerung von Schlüsselbedingungen, Mehrwertige Abhängigkeiten als weitere Verallgemeinerung funktionaler Abhängigkeiten, Inklusionsabhängigkeiten als Verallgemeinerung von Fremdschlüsselbedingungen (spielen untergeordnete Rolle). Wegen Schema-Ebene: Alle Formen sind echte Konsistenzbedingungen, d.h. Anforderungen an spätere Relationsinstanzen (Verpflichtung für das Datenbanksystem!). Funktionale Abhängigkeiten (1):  Funktionale Abhängigkeiten (1) Formale Definition: Sei R(A1,A2, ... ,An) Relationstyp mit Attributen A1, A2, ... ,An. Eine funktionale Abhängigkeitsbedingung (kurz: FD) für R ist ein Ausdruck X  Y mit X, Y  {A1, A2, ... ,An}. Sei Z = R\(XY). R erfüllt die Bedingung X ® Y wenn für R in jedem Zustand gilt: Sind t1 und t2 Tupel mit t1[X]=t2[X] und t1[Z]t2[Z], so t1[Y]=t2[Y]. Zu einem bestimmten Wert unter X findet man also in jedem Tupel, in dem dieser Wert vorkommt, den selben Wert unter Y. Funktionale Abhängigkeiten (2):  Funktionale Abhängigkeiten (2) Intuition: FD X  Y sagt aus, dass in der modellierten Miniwelt ein X-Merkmal das Y-Merkmal eindeutig bestimmt und daher in der späteren Relation Tupel, die in ihren X-Werten übereinstimmen, auch in ihren Y-Werten übereinstimmen müssen. Lokalität der Semantik: Zusammenhang zwischen Teilmengen der Attribute mit Gültigkeit unabhängig vom Rest der Relation. Funktionale Abhängigkeiten: Beispiele:  Funktionale Abhängigkeiten: Beispiele FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) soll folgende FDs erfüllen: flugNr  von von,nach  entfernung flugNr  nach ticketNr  name flugNr  abflugszeit flugNr,ticketNr  platzCode flugNr  ankunftszeit flugNr,ticketNr  datum flugNr  ftypId flugNr,platzCode,datum  ticketNr flugNr  wochentage Zusatzforderung: Auf jedem Flughafen darf zu jeder Zeit nur eine einzige Maschine in eine bestimmte Richtung starten: von,nach,abflugszeit  flugNr Armstrong-Axiome für FDs:  Sonderfälle: Z=W: XW  YW Z=: XW  Y Armstrong-Axiome für FDs Mit funktionalen Abhängigkeiten kann man rechnen! Für alle Attributmengen X, Y, Z gelten die folgenden drei Armstrong-Axiome (XY ist dabei Kurzform für X  Y): Reflexivität: Falls Y  X, dann X  Y. Expansivität: Falls X  Y, Z  W, dann XW  YZ. Transitivität: Falls X  Y und Y  Z, dann X  Z. Aus diesen Axiomen folgen weitere Regeln, z.B.: Vereinigung: Falls X  Y und X  Z, dann X  YZ. Dekomposition: Falls X  YZ, dann X  Y und X  Z. Armstrong-Axiome: Beispiele:  Armstrong-Axiome: Beispiele Reflexivität: Es gilt stets von,nachvon. Expansivität: Aus flugNrnach folgt flugNr,vonnach. Transitivität: Aus flugNr,platzCode,datumticketNr und ticketNrname folgt flugNr,platzCode,datumname. Vereinigung: Aus flugNrvon und flugNrnach folgt flugNrvon, nach. Hülle einer Menge von FDs:  Hülle einer Menge von FDs Fazit: Aus einer Menge von FDs lässt sich eine Reihe weiterer FDs herleiten. Definition: Ist  (endliche) Menge von FDs, dann bezeichne + die Menge aller FDs, die sich vermittels der Armstrong-Axiome aus  herleiten lassen. + wird Hülle von  genannt. Bemerkung: + ist wohldefiniert, weil sich nur endlich viele verschiedene FDs über den in  vorkommenden Attributen formulieren lassen. Kanonische Überdeckung:  Kanonische Überdeckung Kanonische Überdeckung c einer Menge  von FDs ist Gegenteil der Hülle: Minimale Menge an FDs, die noch zu  äquivalent ist. Berechnung wie folgt: Zerlege alle FDs in  gemäß Regel XYZ  XY  XZ in FDs, die nur ein Attribut auf der rechten Seite haben. Entferne aus der resultierenden Menge von FDs alle redundanten FDs (solche, die aus den verbleibenden hergeleitet werden können). Eliminiere für jede verbleibende FD X  Y alle redundanten Attribute auf der linken Seite (d.h., wenn es X’ X mit X’  Y  + gibt, ersetze X  Y durch X’  Y). Fasse unter den verbleibenden Abhängigkeiten alle solche mit gleicher linker Seite gemäß Regel XY  XZ  XYZ zusammen. Kanonische Überdeckung: Beispiel:  Kanonische Überdeckung: Beispiel flugNr  von flugNr  nach flugNr  abflugszeit flugNr  ankunftszeit flugNr  ftypId flugNr  wochentage von,nach  entfernung ticketNr  name flugNr,ticketNr  platzCode flugNr,ticketNr  datum flugNr,platzCode,datum  ticketNr von,nach,abflugszeit  flugNr Erste drei Schritte entfallen! Kanonische Überdeckung: Beispiel:  flugNr  von flugNr  nach flugNr  abflugszeit flugNr  ankunftszeit flugNr  ftypId flugNr  wochentage von,nach  entfernung ticketNr  name flugNr,ticketNr  platzCode flugNr,ticketNr  datum flugNr,platzCode,datum  ticketNr von,nach,abflugszeit  flugNr Kanonische Überdeckung: Beispiel flugNr  von, nach, abflugszeit, ankunftszeit, wochentage von,nach  entfernung ticketNr  name flugNr,ticketNr  platzCode flugNr,ticketNr  datum flugNr,platzCode,datum  ticketNr von,nach,abflugszeit  flugNr flugNr  von, nach, abflugszeit, ankunftszeit, wochentage von,nach  entfernung ticketNr  name flugNr,ticketNr  platzCode flugNr,ticketNr  datum flugNr,platzCode,datum  ticketNr von,nach,abflugszeit  flugNr flugNr  von, nach, abflugszeit, ankunftszeit, wochentage von,nach  entfernung ticketNr  name flugNr,ticketNr  platzCode, datum flugNr,platzCode,datum  ticketNr von,nach,abflugszeit  flugNr flugNr  von, nach, abflugszeit, ankunftszeit, wochentage von,nach  entfernung ticketNr  name flugNr,ticketNr  platzCode, datum flugNr,platzCode,datum  ticketNr von,nach,abflugszeit  flugNr Voll funktionale Abhängigkeiten:  Voll funktionale Abhängigkeiten Voll funktionale Abhängigkeit = Abhängigkeit, bei der auf der linken Seite nichts mehr weggelassen werden kann. Formal: Sei  Menge von FDs und X  Y weitere FD. X  Y heißt voll funktionale Abhängigkeit bezüglich , wenn es keine echte Teilmenge X’ von X mit X’  Y  + gibt. In diesem Fall wird X  Y statt X  Y geschrieben. Bemerkungen: „voll“ ist immer relativ zu einer gegebenen Grundmenge von FDs zu verstehen; es handelt sich nicht um eine absolute Eigenschaft von FDs. Kanonische Überdeckung liefert volle FDs. Voll funktionale Abhängigkeiten: Beispiel:  Voll funktionale Abhängigkeiten: Beispiel Alle für FLUGINFO ursprünglich postulierten FDs sind voll funktional bezüglich ihrer Gesamtmenge: flugNr  von von,nach  entfernung flugNr  nach ticketNr  name flugNr  abflugszeit flugNr,ticketNr  platzCode flugNr  ankunftszeit flugNr,ticketNr  datum flugNr  ftypId flugNr,platzCode,datum  ticketNr flugNr  wochentage Hülle einer Attributmenge:  Hülle einer Attributmenge Hülle A+ einer Attributmenge A bezüglich Menge  von FDs ist Gesamtmenge der Attribute, die vermöge  von A funktional abhängen. Berechnung durch wiederholte Anwendung von FDs aus : A+ := A; while A+ noch wachsend do for each (X  Y)   do if X  A+ then A+ := A+  Y; end for end while // A+ enthält nun das Ergebnis Hülle einer Attributmenge: Beispiel:  Hülle einer Attributmenge: Beispiel flugNr  von flugNr  nach flugNr  abflugszeit flugNr  ankunftszeit flugNr  ftypId flugNr  wochentage von,nach  entfernung ticketNr  name flugNr,ticketNr  platzCode flugNr,ticketNr  datum flugNr,platzCode,datum  ticketNr von,nach,abflugszeit  flugNr {flugNr, ticketNr}+ = {flugNr, ticketNr, flugNr  von flugNr  nach flugNr  abflugszeit flugNr  ankunftszeit flugNr  ftypId flugNr  wochentage von,nach  entfernung ticketNr  name flugNr,ticketNr  platzCode flugNr,ticketNr  datum flugNr,platzCode,datum  ticketNr von,nach,abflugszeit  flugNr {flugNr, ticketNr}+ = {flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, flugNr  von flugNr  nach flugNr  abflugszeit flugNr  ankunftszeit flugNr  ftypId flugNr  wochentage von,nach  entfernung ticketNr  name flugNr,ticketNr  platzCode flugNr,ticketNr  datum flugNr,platzCode,datum  ticketNr von,nach,abflugszeit  flugNr {flugNr, ticketNr}+ = {flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, flugNr  von flugNr  nach flugNr  abflugszeit flugNr  ankunftszeit flugNr  ftypId flugNr  wochentage von,nach  entfernung ticketNr  name flugNr,ticketNr  platzCode flugNr,ticketNr  datum flugNr,platzCode,datum  ticketNr von,nach,abflugszeit  flugNr {flugNr, ticketNr}+ = {flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, name, flugNr  von flugNr  nach flugNr  abflugszeit flugNr  ankunftszeit flugNr  ftypId flugNr  wochentage von,nach  entfernung ticketNr  name flugNr,ticketNr  platzCode flugNr,ticketNr  datum flugNr,platzCode,datum  ticketNr von,nach,abflugszeit  flugNr {flugNr, ticketNr}+ = {flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, name, platzCode, datum flugNr  von flugNr  nach flugNr  abflugszeit flugNr  ankunftszeit flugNr  ftypId flugNr  wochentage von,nach  entfernung ticketNr  name flugNr,ticketNr  platzCode flugNr,ticketNr  datum flugNr,platzCode,datum  ticketNr von,nach,abflugszeit  flugNr {flugNr, ticketNr}+ = {flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, name, platzCode, datum} Mehrwertige Abhängigkeiten (1):  Mehrwertige Abhängigkeiten (1) Verallgemeinerung einer funktionalen Abhängigkeit X  Y auf den Fall, dass nicht der einzelne Y-Wert, sondern die Gesamtmenge dieser Werte durch X bestimmt wird. Beispiel: Betrachte zusätzliches Merkmal „Filmtitel“, das die während eines Flugs gezeigten Filme beschreibt. Naheliegende FD flugNr,datum  filmtitel kann nicht gefordert werden, da auf Fernflügen evt. mehrere Filme gezeigt werden. Lösung: Mehrwertige Abhängigkeit flugNr,datum  filmtitel besagt, dass flugNr und datum die Menge der zugehörigen Filmtitel unabhängig von weiteren Attributen bestimmen. Mehrwertige Abhängigkeiten (2):  Beispielinstanz FLUGINFO mit Filmtiteln (div. Attribute weggelassen): FlugNr von nach Ftyp Filmtitel TicketNr Platz Datum Name ---------------------------------------------------------------------------------------- LH458 MUC SFO 744 Casablanca 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 Play it again, Sam 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 The Maltese Falcon 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH458 MUC SFO 744 The Big Sleep 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Psycho 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 The Birds 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Casablanca 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH459 SFO MUC 744 Play it again, Sam 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB6 - 7216080816 20A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB6 - 7216083968 05E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 Star Wars 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 The Empire Strikes Back 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Return of the Jedi 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Star Wars 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 The Empire Strikes Back 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Return of the Jedi 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Star Trek 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Wrath of Khan 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Search for Spock 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 Star Wars 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 The Empire Strikes Back 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 Return of the Jedi 7216087338 19D 12-AUG-00 Kuhn_Mrs_E Beispielinstanz FLUGINFO mit Filmtiteln (div. Attribute weggelassen): FlugNr von nach Ftyp Filmtitel TicketNr Platz Datum Name ---------------------------------------------------------------------------------------- LH458 MUC SFO 744 Casablanca 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 Play it again, Sam 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 The Maltese Falcon 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH458 MUC SFO 744 The Big Sleep 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Psycho 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 The Birds 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Casablanca 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH459 SFO MUC 744 Play it again, Sam 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB6 - 7216080816 20A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB6 - 7216083968 05E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 Star Wars 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 The Empire Strikes Back 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Return of the Jedi 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Star Wars 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 The Empire Strikes Back 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Return of the Jedi 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Star Trek 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Wrath of Khan 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Search for Spock 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 Star Wars 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 The Empire Strikes Back 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 Return of the Jedi 7216087338 19D 12-AUG-00 Kuhn_Mrs_E Beispielinstanz FLUGINFO mit Filmtiteln (div. Attribute weggelassen): FlugNr von nach Ftyp Filmtitel TicketNr Platz Datum Name ---------------------------------------------------------------------------------------- LH458 MUC SFO 744 Casablanca 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 Play it again, Sam 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 The Maltese Falcon 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH458 MUC SFO 744 The Big Sleep 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Psycho 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 The Birds 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Casablanca 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH459 SFO MUC 744 Play it again, Sam 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB6 - 7216080816 20A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB6 - 7216083968 05E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 Star Wars 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 The Empire Strikes Back 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Return of the Jedi 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Star Wars 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 The Empire Strikes Back 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Return of the Jedi 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Star Trek 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Wrath of Khan 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Search for Spock 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 Star Wars 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 The Empire Strikes Back 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 Return of the Jedi 7216087338 19D 12-AUG-00 Kuhn_Mrs_E Beispielinstanz FLUGINFO mit Filmtiteln (div. Attribute weggelassen): FlugNr von nach Ftyp Filmtitel TicketNr Platz Datum Name ---------------------------------------------------------------------------------------- LH458 MUC SFO 744 Casablanca 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 Play it again, Sam 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 The Maltese Falcon 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH458 MUC SFO 744 The Big Sleep 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Psycho 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 The Birds 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Casablanca 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH459 SFO MUC 744 Play it again, Sam 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB6 - 7216080816 20A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB6 - 7216083968 05E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 Star Wars 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 The Empire Strikes Back 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Return of the Jedi 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Star Wars 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 The Empire Strikes Back 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Return of the Jedi 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Star Trek 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Wrath of Khan 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Search for Spock 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 Star Wars 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 The Empire Strikes Back 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 Return of the Jedi 7216087338 19D 12-AUG-00 Kuhn_Mrs_E Mehrwertige Abhängigkeiten (2) Mehrwertige Abhängigkeiten:  Mehrwertige Abhängigkeiten Formale Definition: Sei R(A1,A2, ... ,An) Relationstyp mit Attributen A1, A2, ... ,An. Eine mehrwertige Abhängigkeitsbedingung (kurz: MVD) ist ein Ausdruck X  Y mit X, Y  {A1, A2, ... ,An}. Sei Z = R\(XY). Eine Instanz r von R erfüllt die Bedingung X  Y, wenn X  2Y Funktion: Sind t1, t2 Tupel in r mit t1[X] = t2[X], so existiert Tupel t3 mit t3[X]=t1[X], t3[Y]=t1[Y], t3[Z]=t2[Z] (und aus Symmetriegründen Tupel t4 mit t4[X]=t1[X], t4[Y]=t2[Y], t4[Z]=t1[Z]). Die Belegung der restlichen Attribute (der Kontext) darf also keine Rolle spielen! Lokalität der Semantik: Zusammenhang zwischen Teilmengen der Attribute mit Gültigkeit unabhängig vom Rest der Relation. Mehrwertige Abhängigkeiten: Beispiele (1):  Mehrwertige Abhängigkeiten: Beispiele (1) Betrachte wieder ursprüngliche Variante von FLUGINFO: FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name). Buchungen und Flugplanung haben nichts miteinander zu tun, außer dass ihnen die Flugnummer gemeinsam ist. Die jeweiligen Informationen können also ohne Kenntnis des Restes gewonnen werden. flugNr  ticketNr,platzCode,datum,name flugNr von,nach,ftypId,wochentage,abflugszeit,ankunftszeit,entfernung Mehrwertige Abhängigkeiten: Beispiele (2):  Mehrwertige Abhängigkeiten: Beispiele (2) Dagegen ist flugNr  ticketNr,platzCode („Die Flugnummer bestimmt die Tickets und die dafür belegten Sitzplätze“) keine MVD, da die Menge sich mit dem Datum ändert. Stattdessen: flugNr,datum  ticketNr,platzCode Zwei Axiome:  Zwei Axiome Folgerungen aus Erfüllungsbedingung: MVD ist Verallgemeinerung von FD: Aus X  Y folgt X  Y (jede FD ist auch MVD). Unabhängigkeit von der restlichen Belegung: Aus X  Y folgt X  Z mit Z = R\(XY). (Symmetrie). Folglich: Eine Instanz r von R erfüllt die Bedingung X  Y, wenn gilt: r = XY(r) ⋈ XZ(r). Axiome für mehrwertige Abhängigkeiten:  Axiome für mehrwertige Abhängigkeiten Für MVDs gelten erweiterte Armstrong-Axiome: Sei R Relationstyp mit Attributmenge U := {A1, A2, ... ,An} und X, Y, Z beliebige Teilmengen von {A1, A2, ... ,An}. Dann gilt: Reflexivität: Falls Y  X, dann X  Y. Expansivität: Falls X  Y, dann XZ  YZ für Z beliebig. Transitivität: Falls X  Y und Y  Z, dann X  (Z \ Y). Symmetrie: Falls X  Y, dann X  (U \ Y).  Umwandlung: Falls X  Y, dann X  Y.  Mischung: Falls X  Y und XY  Z, dann X  (Z \ Y). Mit diesen Axiomen lässt sich Hülle + einer Menge  von FDs und MVDs definieren. Schlüssel:  Schlüssel Einordnung des Schlüsselbegriffs in Abhängigkeitstheorie: Sei R(A1,A2, ... ,An) Relationstyp,  Menge von FDs für R und S Teilmenge von {A1,A2, ... ,An}. S heißt Superschlüssel von R bzgl. , wenn S  A1,...,An  +. S heißt Schlüssel (besser: Schlüsselkandidat) von R bzgl. , wenn S  A1,...,An  +. Jede FD S  X (X  {A1,A2, ... ,An}) heißt Schlüsselabhängigkeit. Bemerkung: Falls mehrere Schlüsselkandidaten für eine Relation existieren, muss einer davon als Primärschlüssel ausgezeichnet werden. Systematisches Finden eines Schlüssels:  Systematisches Finden eines Schlüssels Sei Relationstyp R mit Attributen A1, A2, ... ,An und Menge  von FDs für R gegeben. Algorithmus zur Bestimmung eines Superschlüssels S für R bzgl. : S :=  while S+  {A1,...,An} do choose Ai  {A1,...,An} \ S+ S := S  {Ai} end while // S ist jetzt Superschlüssel Bemerkung: Algorithmus liefert nicht notwendig Schlüssel. Dieser kann jedoch stets aus S durch Weglassen von Attributen gewonnen werden. Finden eines Schlüssels: Beispiel:  Finden eines Schlüssels: Beispiel FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr  von von,nach  entfernung flugNr  nach ticketNr  name flugNr  abflugszeit flugNr,ticketNr  platzCode flugNr  ankunftszeit flugNr,ticketNr  datum flugNr  ftypId flugNr,platzCode,datum  ticketNr flugNr  wochentage Iteration S S+ Ai 1 {} {} {flugNr} 2 {flugNr} {flugNr,von,nach,abflugszeit,ankunftszeit, {ticketNr} ftypdId,wochentage,entfernung} 3 {flugNr, ticketNr} -- alle Attribute -- Schlüssel von FLUGINFO:  Schlüssel von FLUGINFO Durch Ausprobieren erhält man Menge aller Schlüssel von FLUGINFO: {flugNr,ticketNr} {flugNr,platzCode,datum} Anomalien:  Anomalien MVD X  Y für Relationstyp R(A1, ... ,An) besagt, dass jede Instanz r natürliche Verbindung semantisch unabhängiger Teilrelationen rXY := XY(r) und rXZ := XZ(r) ist: r = XY(r) ⋈ XZ(r) mit Z = {A1, ... ,An} \ (XY), XZ  {A1, ... ,An}  XY. Gilt auch, falls X  Y aber X  Z. MVDs sind unerwünscht, da sie bei Schreibzugriffen sogenannte Anomalien verursachen. Problem: Wegen Kombination in einer Relation r muss für ein XY-Tupel der gesamte XZ-Kontext mitgeführt werden  Einfüge-, Änderungs- und Lösch-Anomalien. Einfüge-Anomalien:  Einfüge-Anomalien Es werde MVD XY und assoziierte Gleichung r = XY(r) ⋈ XZ(r) mit YX und Z = {A1, ... ,An} \ (XY)   unterstellt. Einfüge-Anomalie: XY-Wertekombination kann nicht in r eingefügt werden, solange keine Z-Werte vorliegen. Beispiel: Einfügen eines neuen Fluges in FLUGINFO erst möglich, wenn zumindest eine Buchung vorliegt (da Werte für Attribute ticketNr, platzCode, datum, name benötigt werden). Abhilfe durch Verwendung von NULL-Werten für fehlende Attributwerte möglich, allerdings unter Inkaufnahme komplexerer SQL-Semantik. Änderungs-Anomalien:  Änderungs-Anomalien Es werde MVD XY und assoziierte Gleichung r = XY(r) ⋈ XZ(r) mit YX und Z = {A1, ... ,An} \ (XY)   unterstellt. Änderungs-Anomalie: XY-Wertekombination wird redundant für jede Z-Wertekombination gespeichert, Änderungen müssen daher mehrfach durchgeführt werden. Beispiel: Änderung der Ankunftszeit eines Fluges in FLUGINFO muss redundant für jede vorliegende Buchung durchgeführt werden. Lösch-Anomalien:  Lösch-Anomalien Es werde MVD XY und assoziierte Gleichung r = XY(r) ⋈ XZ(r) mit YX und Z = {A1, ... ,An} \ (XY)   unterstellt. Lösch-Anomalie: Beim Löschen der letzten Z-Wertekombination für gegebene X-Wertekombination gehen auch alle zugehörigen Y-Wertekombinationen verloren. Beispiel: Beim Löschen der letzten Buchung für einen Flug in FLUGINFO geht auch jedwede Information über FlugNr, Start- und Zielflughafen, FtypId etc. verloren. Gegenstück zu Einfüge-Anomalie, Abhilfe ebenfalls durch NULL-Werte möglich. Ziel der Normalisierung:  Ziel der Normalisierung Normalisierung: Prozess der Schematransformation mit den Zielen: Beseitigen von MVDs. DBMS kann Schlüsselbedingungen effizient überwachen; Normalisierung versucht daher, FDs in Schlüsselbedingungen zu transformieren. Auch damit lassen sich MVDs eliminieren. Zu Grunde liegendes Ziel: Beseitigen der Anomalien bei Schreiboperationen. Schlüssel- und Nichtschlüsselattribute:  Schlüssel- und Nichtschlüsselattribute Definition (technisch, für Normalformenlehre): Sei R(A1,...,An) Relationstyp und  Menge von FDs für R. Ein Attribut Ai heißt Schlüsselattribut von R bzgl. , wenn es einen Schlüsselkandidat S von R bzgl.  mit Ai  S gibt, und Nichtschlüsselattribut sonst. Beispiel: Schlüssel von FLUGINFO sind: {flugNr,ticketNr} {flugNr,platzCode,datum} Schlüsselattribute von FLUGINFO sind also: flugNr, ticketNr, platzCode, datum. Normalisierung: Vorgehen und Ziele:  Normalisierung: Vorgehen und Ziele Umsetzung der Ziele durch Zerlegung von Relationen in Teilrelationen mit kleineren Attributmengen. Zu klären: 1) Welche Zerlegungen sind gut? 2) Welche Zerlegungen sind korrekt? 3) Wie findet man gute und korrekte Zerlegungen? Normalformen:  Normalformen FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) FDs: flugNr  von von,nach  entfernung flugNr  nach ticketNr  name flugNr  abflugszeit flugNr,ticketNr  platzCode flugNr  ankunftszeit flugNr,ticketNr  datum flugNr  ftypId flugNr,platzCode,datum  ticketNr flugNr  wochentage Schlüssel: {flugNr,ticketNr}, {flugNr,platzCode,datum} Frage 1 führt auf sog. Normalformen als Erfolgsmaßstab für Eliminieren von unerwünschten FDs und MVDs. Erste Normalform:  Erste Normalform Relationstyp R(A1,...,An) und Menge  von FDs und MVDs für R sei im Folgenden fest vorgegeben. R ist in erster Normalform (1NF), wenn die Domänen aller Attribute primitive Typen sind. FLUGINFO ist 1NF, da alle Attribute primitive Domänen haben. Gilt im relationalen Modell immer. Zweite Normalform:  Zweite Normalform R ist in zweiter Normalform (2NF), wenn jedes Nichtschlüsselattribut von jedem Schlüssel voll funktional abhängt. (Nichtschlüsselattribute dürfen also nicht von Teilen eines Schlüssels abhängen.) FLUGINFO nicht in 2NF, da es Nichtschlüsselattribute gibt, die bereits allein von ticketNr oder flugNr abhängen. Zerlegung: FLUGANGABE (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung) TICKET (ticketNr, name) BUCHUNG (flugNr, ticketNr, platzCode, datum) Zweite Normalform ist insbesondere (aber nicht nur!) in den folgenden Fällen gegeben: Alle Schlüssel sind einelementig. Es gibt keine Nichtschlüsselattribute. Dritte Normalform:  Dritte Normalform R ist in dritter Normalform (3NF), wenn für jede FD X  A mit A Nichtschlüsselattribut gilt: X ist Superschlüssel. Dritte Normalform gilt nicht in FLUGANGABE, da Abhängigkeit von,nach  Entfernung besteht und {von,nach} nicht Superschlüssel ist. Relation BUCHUNG ist in dritter Normalform, da alle Attribute Schlüsselattribute sind, TICKET weil ticketNr Superschlüssel ist. Zerlegung von FLUGANGABE: FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) FLUGSTRECKE (von, nach, entfernung) Dritte Normalform:  Dritte Normalform Dritte Normalform ist also nicht gegeben, wenn ein Nichtschlüsselattribut von (einer Kombination von) Attributen abhängt, die Nichtschlüsselattribute einschließen. Dritte Normalform liegt insbesondere (aber nicht nur!) vor, wenn es keine Nichtschlüsselattribute oder keine FDs gibt. Dritte Normalform: Zwischenergebnis:  Dritte Normalform: Zwischenergebnis FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) flugNr  (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) (von, nach, abflugszeit)  flugNr FLUGSTRECKE (von, nach, entfernung) (von, nach)  entfernung TICKET (ticketNr, name) ticketNr  name BUCHUNG (flugNr, ticketNr, platzCode, datum) (flugNr, ticketNr)  (platzCode, datum) (flugNr, platzCode, datum)  ticketNr Boyce-Codd-Normalform:  Boyce-Codd-Normalform R ist in Boyce-Codd-Normalform (BCNF), wenn für jede FD X  Y gilt: X ist Superschlüssel. In 3NF werden nur Abhängigkeiten betrachtet, bei denen auf der rechten Seite Nichtschlüsselattribute stehen. In 3NF sind auch FDs mit Schlüsselattributen auf der rechten Seite möglich. Boyce-Codd-Normalform gilt in allen vier Relationen. Ältere Definitionen bezogen sich nur auf den Primärschlüssel. Dann wäre BUCHUNG (flugNr, ticketNr, platzCode, datum) nicht in BCNF wegen (flugNr, platzCode, datum)  ticketNr. Vierte Normalform:  Vierte Normalform R ist in vierter Normalform (4NF), wenn für jede MVD X  Y gilt: X ist Superschlüssel (und damit X  Y). Vierte Normalform gilt in allen vier Relationen. Betrachte Relation mit Angaben, welche Passagiere wann welche Filme gesehen haben: ZUSCHAUER (Name, FlugNr, Datum, Filmtitel) und frühere MVD FlugNr,Datum  Filmtitel Boyce-Codd-Normalform, da keine FDs vorliegen. Vierte Normalform gilt nicht, da (FlugNr,Datum) nicht Superschlüssel ist. Vierte Normalform:  Vierte Normalform Präzise Formulierung: 4NF liegt genau dann vor, wenn für jede FD X  Y und jede MVD X  Y mindestens eine der folgenden Aussagen zutrifft: X  Y. X  Y = alle Attribute der betrachteten Relation. X ist Superschlüssel der betrachteten Relation. Normalformen in der Übersicht:  Normalformen in der Übersicht 1NF 2NF 3NF BCNF 4NF Alle Relationen Nichtschlüsselattribute hängen voll funktional von jedem Schlüssel ab Nichtschlüsselattribute hängen funktional nur von Superschlüsseln ab Keine FDs außer Schlüsselabhängigkeiten Keine MVDs außer Schlüsselabhängigkeiten Zerlegung und Konstruktion:  Zerlegung und Konstruktion Frage 2: Welche Zerlegungen sind korrekt? Zerlegung ersetzt Relationstyp R(A1,...,An) und Menge  von assoziierten Abhängigkeiten durch mehrere einzelne Relationstypen Ri(Ai1,...,Aij) mit Abhängigkeiten i. Attributmengen der einzelnen Ri können überlappen, Vereinigung muss {A1,...,An} ergeben. Statt Instanz r von R werden Projektionen ri : Attribute(Ri) (r) abgespeichert, r wird durch natürliche Verbindung r = r1 ⋈ r2 ⋈ ... ⋈ rk konstruiert. Korrektheit von Zerlegungen:  Korrektheit von Zerlegungen Durch Speicherung der Teilrelationen statt der unzerlegten Relation r darf Zustandsraum r nicht verändert werden. Korrektheitsforderung daher: Durch Zerlegung darf weder (1) die Speicherung konsistenter Zustände von r unmöglich (2) noch die Speicherung inkonsistenter Zustände in r möglich werden. r ist nur virtuell! Als konsistent gilt per Definition jeder Zustand von r! Zerlegungen, die (1) erfüllen, heißen verlustlos und Zerlegungen, die (2) erfüllen, konsistenzwahrend (oft auch abhängigkeitsbewahrend genannt). Verlustlosigkeit:  Verlustlosigkeit Formale Definition: Sei R(A1,...,An) Relationstyp,  Menge von FDs und MVDs für R, r Instanz von R. Zerlegung {(Ri(Ai1,...,Aij), i) | i = 1,...,k} von (R,) in Teilrelationen Ri mit assoziierten Abhängigkeiten i ist verlustlos, wenn für r gilt: Jede Projektion ri  Ai1,...,Aij (r) erfüllt die Abhängigkeiten in i (1ik). r  r1 ⋈ r2 ⋈ ... ⋈ rk. Abhängigkeitsbewahrung:  Abhängigkeitsbewahrung Formale Definition: Sei R(A1,...,An) Relationstyp,  Menge von FDs und MVDs für R, r Instanz von R. Zerlegung {(Ri(Ai1,...,Aij), i) | i = 1,...,k} von (R,) in Teilrelationen Ri mit assoziierten Abhängigkeiten i ist abhängigkeitsbewahrend, wenn gilt: Sind für 1  i  k Instanzen ri von Ri(Ai1,...,Aij) gegeben, die jeweils i erfüllen, dann muss r1 ⋈ r2 ⋈ ... ⋈ rk die Bedingungen in  erfüllen. r  r1 ⋈ r2 ⋈ ... ⋈ rk. Korrekte Zerlegung: Beispiel:  Korrekte Zerlegung: Beispiel FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr  (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) (von, nach)  entfernung ticketNr  name (flugNr, ticketNr)  (platzCode, datum) (flugNr, platzCode, datum)  ticketNr FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) flugNr  (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) FLUGSTRECKE (von, nach, entfernung) (von, nach)  entfernung TICKET (ticketNr, name) ticketNr  name BUCHUNG (flugNr, ticketNr, platzCode, datum) (flugNr, ticketNr)  (platzCode, datum) (flugNr, platzCode, datum)  ticketNr abhängigkeitsbewahrend! verlustlos? Inkorrekte Zerlegung: Beispiel:  Inkorrekte Zerlegung: Beispiel Weitere Zerlegung von FLUG in Teilrelationen FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) in FLUGTAGE (flugNr, von, nach, ftypId, wochentage) STRECKENZEITEN (von, nach, abflugszeit, ankunftszeit) nicht abhängigkeitsbewahrend (flugNr  (abflugszeit,ankunftszeit) geht verloren); Folge: Gibt es zwei Flüge auf derselben Strecke mit unterschiedlichen Zeiten, so entsteht kartesisches Produkt. Gewinnung von Zerlegungen:  Gewinnung von Zerlegungen Erreichter Kenntnisstand: Welche Zerlegungen sind gut? Höhere Normalformen. Welche Zerlegungen sind korrekt? Verlustlose und abhängigkeitsbewahrende Zerlegungen. Frage 3: Wie findet man gute und korrekte Zerlegungen? Zerlegungsalgorithmen, im Folgenden zu betrachten. Grundsätzliche Resultate:  Grundsätzliche Resultate Theorem: Für jeden Relationstyp R(A1,...,An) und jede Menge  von FDs über {A1,...,An} gibt es: eine verlustlose (aber nicht notwendig abhängigkeitsbewahrende) Zerlegung in eine Menge von Relationstypen in BCNF, eine verlustlose und abhängigkeitsbewahrende Zerlegung in eine Menge von Relationstypen in 3. Normalform, polynomiale Algorithmen, die diese Zerlegungen finden. Wenn  auch MVDs enthält, lässt sich eine verlustlose Zerlegung in Relationstypen in 4. Normalform finden. Algorithmus zur Zerlegung in 3NF (1):  Algorithmus zur Zerlegung in 3NF (1) In der Praxis zerlegt man normalerweise in 3. Normalform. Man kann zeigen, dass Bedingung r = Attribute(R1) (r) ⋈ ... ⋈ Attribute(Rk) (r) gilt für alle Instanzen r von R, die Abhängigkeiten in  erfüllen, genau dann erfüllt ist, wenn die für die Verbindung maßgeblichen (d.h. abzugleichenden) Attribute jeder Teilrelation Ri einen Schlüssel von Ri gemäß i darstellen. Algorithmus zur Zerlegung in 3NF (2):  Algorithmus zur Zerlegung in 3NF (2) // Eingabe: Relationstyp R und Menge von FDs  // c sei kanonische Überdeckung von , // in der FDs absteigend nach Anzahl der Attribute sortiert sind (wichtig) // Idee: bilde separaten Relationstyp Ri(X,Y) für jede FD X  Y in c, // sofern X  Y nicht bereits durch anderen Relationstyp Rj abgedeckt ist i := 0 for each (X  Y)  c do if j: 1  j  i  (X  Y)  Attribute(Rj) then begin j := j  {X  Y} end else begin i := i +1; Ri := (X  Y); i := {X  Y} end end if end for // Relationstyp für Schlüssel von R bilden, falls noch nicht abgedeckt if 1  j  i: Attribute(Rj) sind nicht Superschlüssel von R then begin i := i +1; Ri := irgendein Schlüssel von R; i :=  end end if Algorithmus zur Zerlegung in 3NF (3):  Algorithmus zur Zerlegung in 3NF (3) Gewonnene Zerlegung ist i.A. nicht eindeutig, da Wahlfreiheit bzgl. Bildung und Sortierung der kanonischen Überdeckung und Auswahl des Schlüssels im Abschlussschritt besteht. 3NF-Zerlegung von FLUGINFO:  3NF-Zerlegung von FLUGINFO FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr  (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) (flugNr, ticketNr)  (platzCode, datum) (flugNr, platzCode, datum)  ticketNr (von, nach)  entfernung ticketNr  name FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr  (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) (flugNr, ticketNr)  (platzCode, datum) (flugNr, platzCode, datum)  ticketNr (von, nach)  entfernung ticketNr  name FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr  (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) (flugNr, ticketNr)  (platzCode, datum) (flugNr, platzCode, datum)  ticketNr (von, nach)  entfernung ticketNr  name FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) BUCHUNG (flugNr, ticketNr, platzCode, datum) FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr  (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) (flugNr, ticketNr)  (platzCode, datum) (flugNr, platzCode, datum)  ticketNr (von, nach)  entfernung ticketNr  name FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) BUCHUNG (flugNr, ticketNr, platzCode, datum) FLUGSTRECKE (von, nach, entfernung) FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr  (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) (flugNr, ticketNr)  (platzCode, datum) (flugNr, platzCode, datum)  ticketNr (von, nach)  entfernung ticketNr  name FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) BUCHUNG (flugNr, ticketNr, platzCode, datum) FLUGSTRECKE (von, nach, entfernung) TICKET (ticketNr, name) 4NF-Zerlegung:  4NF-Zerlegung Vorgestellter Zerlegungsalgorithmus berücksichtigt nur FDs, da bei MVDs i.A. keine abhängigkeitsbewahrende Zerlegung in 4. Normalform möglich ist. Verlustlose Zerlegung eines Relationstyps R, der nicht in 4. Normalform ist, ist jedoch leicht möglich: Sei X  Y MVD, in der X nicht Superschlüssel ist. Setze Z := {A1,...,An} \ (XY). Dann gilt XZ  {A1,...,An}  XY. Zerlege R in Relationstypen R1(X,Y) und R2(X,Z). MVD X  Y besagt gerade, dass jede Instanz von R sich durch natürliche Verbindung ihrer Projektionen auf XY bzw. XZ rekonstruieren lässt, Zerlegung also verlustlos ist. Anschließend ggf. weitere Zerlegung der Teilrelationen. Inklusionsabhängigkeiten:  Inklusionsabhängigkeiten Zerlegung gibt i.A. Anlass zu Fremdschlüsselbedingungen, z.B. Fremdschlüssel {flugNr} und {ticketNr} in BUCHUNG. Allgemeine Form solcher Bedingungen sind sogenannte Inklusionsabhängigkeiten (kurz: IDs): Sind R1, R2 Relationstypen und X  Attribute(R1), Y  Attribute(R2) Listen von Attributen mit kompatiblen Domänen, so ist ID Ausdruck der Form R1.X  R2.Y. Instanzen r1, r2 von R1, R2 erfüllen R1.X  R2.Y, wenn X(r1)  Y(r2).

Add a comment

Related presentations

Related pages

Kapitel4 – ein Werbekrimi

Kapitel4 GmbH Agentur für Werbung und Kommunikation St.-Antonius-Straße 5 6890 Lustenau, Österreich partner@kapitel4.com T +43 (0)5577 / 20 543
Read more

IMPRESSUM

Kapitel4 | Agentur für Werbung und Kommunikation GmbH St. Antonius-Straße 5 A-6890 Lustenau, Österreich T +43 (0)5577 / 20 543 F +43 (0)5577 / 20 543 15
Read more

Kapitel 4: Prozesskostenrechnung - TU München - Lehrstuhl ...

Management Accounting Kapitel 4: Prozesskostenrechnung Beurteilung Generell hohe Akzeptanz in der unternehmerischen Praxis, wegen gleichzeitig
Read more

Kapitel4 RelationenundFunktionen - WWU - Mathematik und ...

Kapitel4 RelationenundFunktionen Bin¨are Relationen Partielle Ordnung Lineare Ordnung Aquivalenzrelation¨ Funktionen Allgemeine Relationen Kapitel4 ...
Read more

Kapitel 4 Dokumentation - Bundesministerium für Gesundheit

Kapitel 4 Dokumentation Inhaltsverzeichnis Grundsätze Erforderliche GMP Dokumentation Erzeugung und Kontrolle der Dokumentation Gute Dokumentationspraxis
Read more

Kapitel 4 - Antidiskriminierungsstelle - Startseite

Ansprüche und Rechtsschutzmöglichkeiten jenseits des AGG ... Ka­pi­tel 4 des Hand­buchs "Recht­li­cher Dis­kri­mi­nie­rungs­schutz" zum Her­un ...
Read more

Kapitel4, Main | Dermatologie, Umweltmedizin ...

... Gesundheitstheorie » Kapitel 4 Team. Mitarbeiter des Fachgebiets Osnabrück. Name: E-Mail-Adresse: Telefonnummer/n. Allmers, Henning, apl. Prof. Dr ...
Read more

HTML/Tutorials/HTML-Einstieg/Kapitel4 – SELFHTML-Wiki

Die Preistabelle. So, das nächste, was Herr Meier sich notiert hatte, war die Preisliste. Wir bitten hier um große Nachsicht, denn wir gehören nicht zu ...
Read more

Kapitel4

Start Vorbemerkung HTML - Basis Kapitel1 ... Felder simuliert echt assoziativ
Read more

Kapitel4 - Medizinische Fakultät

Übungen zur medizinischen Biometrie : 4 Wahrscheinlichkeitsrechnung. 4.1 Lernziele zu Kapitel 4 - Grundbegriffe der ...
Read more