Mobilfunk-Netze bei Überlast Schloßgrabenfest 2015 Alexander Frömmgen und Jens Heuschkel DFG Sonderforschungsbereich 1053 MAKI Multi-Mechanismen-Adaption für das künftige Internet Antragsteller: Prof. Alejandro Buchmann, Ph.D. Prof. Dr.-Ing. Wolfgang Effelsberg Prof. Dr. David Hausheer Prof. Dr.-Ing. Matthias Hollick Prof. Dr.-Ing. Anja Klein Prof. Dr. phil. Martina Löw Prof. Dr. rer. nat. Max Mühlhäuser Prof. Klara Nahrstedt, Ph.D. (UIUC) Prof. Dr. Silvia Santini Prof. Dr. rer. nat. Andreas Schürr Prof. Dr.-Ing. Ralf Steinmetz Prof. Dr.-Ing. Thorsten Strufe Prof. Dr. Karsten Weihe Prof. Dr.-Ing. Klaus Wehrle (RWTH Aachen)
Motivation Das Forschungsprojekt MAKI zielt auf Überlast-Situationen Realistische Daten werden benötigt Daten werden von Providern nicht bereitgestellt Idee: Sammeln der Daten mittels App beim Nutzer z.b. Schlossgrabenfest Darmstadt: Hessens größtes Musik-Festival Über 400.000 Besucher Garantierte Überlast DFG Sonderforschungsbereich 1053 MAKI Multi-Mechanismen-Adaption für das künftige Internet
Android APP zur Datensammlung Research4Refill Was wird gemessen? Die Messung läuft anonym und automatisch im Hintergrund Es werden keine Handynummern, Namen, Adressbücher, emails, Nachrichten, besuchte Webseiten etc. erfasst! Was habe ich davon? Ein Freigetränk auf dem Schloßgrabenfest! Du unterstützt die Forschung an einem Problem, von dem Du selbst betroffen bist! DFG Sonderforschungsbereich 1053 MAKI Multi-Mechanismen-Adaption für das künftige Internet
Download Research4Refill Unterstütze die Verbesserung mobiler Netzwerke und hol dir dein Schloßgrabenfest Freigetränk! Schloßgrabenfest: 21.05. - 24.05. (Teilnahme an allen Tagen möglich) App verfügbar im Google Playstore: Research4Refill DFG Sonderforschungsbereich 1053 MAKI Multi-Mechanismen-Adaption für das künftige Internet
Einführung in Data and Knowledge Engineering 3. Übung Relationales Modell 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 5
Aufgabe 3.1: Relationen Schemata Art Matr# Name FB# Name Klausur (1,N) (1,1) (0,N) schreibt (0,N) Student (1,1) eingeschr. an (0,N) Fachbereich (1,N) gliedern sich in findet statt (0,N) Raum Raum# Zeit Zeit findet statt (0,N) (0,N) (1,1) (3,3) Vorlesung (1,1) findet statt (1,1) hat gehört zu Veranst# Titel (1,1) Übung (1,N) hält (1,1) (0,N) Pers# hält beschäftigt (0,1) Professor (0,N) Name (1,1) (0,1) Mitarbeiter stellt ein (1,1) Fachgebiet (0,N) (0,N) stellt ein Hiwi FG# Name (0,1) Veranst# Titel Pers# Name Zeit 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 7 Pers# Name
Aufgabe 3.1: Relationen Schemata Fachbereich FK FB# x Name Fachgebiet FG# Name FB# Professor x x FK Fachbereich.FB# Professor.Pers# FG# und FB# als notwending da nur weak entity! Professor FK Pers# x Name 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 8
Aufgabe 3.1: Relationen Schemata Mitarbeiter Pers# Name FG FB x FK Fachgebiet.FG# Fachgebiet.FB# Hiwi Pers# Name FG FB x FK Fachgebiet.FG# Fachgebiet.FB# Student FK Matr# Name FB x Fachbereich.FB# 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 9
Aufgabe 3.1: Relationen Schemata Vorlesung FK Veranst# Titel Raum Zeit x Raum.Raum# Übung Veranst# Titel Raum Zeit Vorlesung Mitarbeiter x FK Raum.Raum# Vorlesung.Veranst# Mitarbeiter.Pers# Vorlesung-Professor Vorlesung Professor x x FK Vorlesung.Veranst# Professor.Pers# 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 10
Aufgabe 3.1: Relationen Schemata Raum FK Raum# x Klausur-Raum Raum# Klausurart Vorlesung x x x FK Raum.Raum# Klausur.Art Klausur.Vorlesung Klausur Art Vorlesung Zeit x x FK Vorlesung.Veranst# Klausur.Zeit könnte man auch in der Tabelle Klausur-Raum darstellen. Dies würde es erlauben je Raum eine unterschiedliche Klausurzeit festzulegen Student-Klausur Student Klausurart Vorlesung x x x FK Student.Matr# Klausur.Art Klausur.Vorlesung 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 11
Aufgabe 3.1: Relationen Schemata Noten leiht aus N 1 Seiten Name Inv# 1 Id Schüler N Konto N Eltern ist Kind unterrichtet Id Name Lehrer N N Dauer Name Id Beginn Ende N Raum 1 Zeit N N Instrument Name Kosten Größe Nummer lagert 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 12
Aufgabe 3.1: Relationen Schemata Noten FK Eltern FK Schüler FK Inv# Seiten Ausleiher X Schüler.Id Id Name Konto X Id Name Eltern X Eltern.Id 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 13
Aufgabe 3.1: Relationen Schemata Lehrer FK Id X Name Raum FK Nummer X Größe Instrument FK Name Kosten lagert_in X Raum.Nummer 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 14
Aufgabe 3.1: Relationen Schemata Unterricht Ist das Ergebnis streng nach Umsetzungsvorschrift. Problem: Unterricht, der noch andauert, hätte Ende = null, was nicht erlaubt ist, da Ende Teil vom ist. Unterricht Schüler Lehrer Raum Instrument Zeit Beginn Ende X X X X X X FK Schüler.Id Lehrer.Id Raum.Nummer Instrument.Name Dauer Schüler Lehrer Raum Instrument Zeit Dauer Id Beginn Ende X X X X X X FK Schüler.Id Lehrer.Id Raum.Nummer Instrument.Name Dauer.Id Diese Variante umgeht das Problem, indem eine eigene Relation mit extra Primärschlüssel für Dauer angelegt wird. Unterricht Schüler Lehrer Raum Instrument Zeit Beginn Ende X X X X X FK Schüler.Id Lehrer.Id Raum.Nummer Instrument.Name Diese Variante modelliert die Intention, ist aber die am wenigsten offensichtliche. 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 15
Aufgabe 3.2: Schlüsselkandidaten Sei R = ABCDEFGHI eine Relation und F = {B C, A DE, BC F, F GH, A I, D I} eine Menge FDs über R. Bestimmen Sie alle Schlüsselkandidaten. 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 16
Aufgabe 3.2: Schlüsselkandidaten Um die Schlüsselkandidaten zu finden, muss man alle linken Seiten der FDs betrachten und bestimmen, welche Attribute von ihnen funktional abhängig sind. F = {B C, A DE, BC F, F GH, A I, D I} B C, BC F, F GH B BCFGH A DE, A I BC F, F GH F GH D I A ADEI BC BCFGH F FGH D DI keine linke Seite bildet alleine einen Schlüsselkandidaten. z.b. A, B, C bildet einen Superschlüssel, der aber nicht minimal ist. {A, B} ist minimal und ist der einzige Schlüsselkandidat. 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 17
Überflüssige Attribute Achtung: wir betrachten ab jetzt FD-Mengen Ein Attribut ist überflüssig, g.d.w. man es aus der linken (bzw. rechten) Seite einer FD entfernen kann und die neue FD-Menge äquivalent zur alten ist. Zwei FD-Mengen sind äquivalent, g.d.w. sie die gleiche Hülle besitzen. (die eine darf weder größer noch kleiner sein als die andere). Die Hülle (transitive closure) F + ist die Menge aller FDs, die von der bekannten Menge von FDs impliziert werden 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 18
Armstrongs Axiome Reflexivität Wenn Y Teilmenge von X ist, dann gilt X Y Erweiterung Wenn X Y, dann gilt XZ YZ Transitivität Wenn X Y und Y Z, dann gilt X Z Additivität (union rule) Wenn X Y und X Z, dann gilt X YZ Projektivität (decomposition rule) Wenn X YZ, dann gilt X Z und X Y Pseudotransitivität (pseudotransitivity rule) Wenn X Y und WY Z, dann gilt XW Z 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 19
Überflüssige Attribute Beispiel: {AB C, B A} {AB C, B A} {B C, B A}?! AB C, B A (Erweiterung) AB C, B A, B AB (Transitivität) AB C, B A, B AB, B C Beispiel: A: Titel, B: ISBN, C: Autor B C, B A B C, B A, AB AC (Erweiterung) B C, B A, AB AC, AB C (Projektivität) (AB A) 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 20
Aufgabe 3.3: Überflüssige Attribute 1 Finden und entfernen Sie überflüssige Attribute in F = {B C, A DE, BC F, F GH, A I, D I} Entferne Attribut C in BC F, da B C F = {B C, A DE, B F, F GH, A I, D I} Es ist nicht möglich alternativ B aus BC F zu entfernen. Man kann zwar BC F aus C F herleiten, allerdings nicht C F aus BC F. Siehe dazu auch die nächste Aufgabe. 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 21
Unterschiede zu Aufgabe 3.2 In der Aufgabe 3.3 geht es um überflüssige Attribute. Wie man diese findet ist ähnlich zur Suche nach einem Schlüsselkandidaten aber nicht identisch! Aus F = B C, A DE, BC F, F GH, A I, D I können wir B BCFGH und A ADEI ableiten. Womit sich {A, B} als Schlüsselkandidat ergibt. (Aufgabe 3.2) Kann man also F auf F = B BCFGH, A ADEI reduzieren? nein! Beweis: Wenn F und F äquivalent wären, dann müssten die Transitiven Hüllen F + und F + gleich sein. Aber F + enthält z.b. D I was sich aus F nicht ableiten lässt! Hüllen sind nicht gleich, somit sind die Mengen nicht äquivalent. 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 22
Aufgabe 3.4: Überflüssige Attribute 2 Gegeben ist die FD-Menge F = {A X, AB Y} Streicht man A aus AB Y heraus, entsteht F = {A X, B Y} Die ursprüngliche FD AB Y lässt sich aber aus der FD B Y durch Erweiterung wieder herstellen. Darf man also A als überflüssiges Attribut herausstreichen? Wenn nein, warum nicht? 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 23
Aufgabe 3.4: Überflüssige Attribute 2 Wenn man formal prüfen will, ob ein Attribut (oder eine ganze FD) überflüssig ist, muss man überprüfen, ob beim Entfernen des Attributs bzw. der FD die FD Menge äquivalent bleibt. Die Hüllen der FD-Mengen müssen also gleich sein. Bildet man die Hülle von F, bemerkt man schnell, dass sich die FD B Y, die in F enthalten ist, nicht herleiten lässt und die beiden FD-Mengen somit nicht äquivalent sind. Informell kann man sich klar machen, dass in F sowohl A als auch B notwendig sind, um Y zu bestimmen. Lässt man A weg, müsste B alleine ausreichen, um Y zu bestimmen, was in F aber nicht der Fall ist. 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 24
Aufgabe 3.5: Überflüssige Attribute bei der Musikschule F = { Id Name, Vorname, Geburtstag, Alter, Anschrift; Id, Geburtstag Alter; Geburtstag Alter; Name, Vorname, Geburtstag Telefonnummer; Telefonnummer Anschrift} 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 25
Zusammenfassung Schlüssel Superschlüssel (auch Oberschlüssel genannt) (Jede) Menge von Attributen welche alle Tupel einer Relation eindeutig identifizieren kann. Trivial Beispiel: die Menge aller Attribute. Schlüsselkandidat (auch Kandidatenschlüssel genannt) Superschlüssel in dem KEINE Teilmenge existiert die selbst Superschlüssel sein kann. Beispiel: Studenten könnte man identifizieren mit: Matrikelnummer TU-ID Vorname+Nachname+Geburtsdatum+Geburtsort Vorname+Nachname+Adresse Diese sind ALLE minimal da man jeweils nichts weglassen ohne die Eindeutigkeitsbedingung zu verletzen Gegenbeispiele: Matrikelnummer+TU-ID Matrikelnummer+Vorname +Nachname TU-ID+Geburtsdatum Man könnte jeweils ein Attrbut weglassen und die Eindeutigkeit bliebe gewahrt. (Es wird angenommen, dass es keine Sonderfälle gibt wie Studenten mit gleichen Vornamen, Nachnamen und gleicher Adresse) 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 26
Zusammenfassung Schlüssel (2) Primärschlüssel (primary key) Genau einer der Schlüsselkandidaten. Welchen man wählt ist (in the Theorie) egal, da alle Schlüsselkandidaten schon minimal sind. In der Praxis gibt es durchaus Unterschiede, da z.b. Zahlen effektiver gespeichert und verglichen werden können als Zeichenketten. 22.06.2015 Fachbereich Informatik Datenbanken und Verteilte Systeme Robert Rehner 27