1. No category

Mobilfunk-Netze bei Überlast
Schloßgrabenfest 2015
Alexander Frömmgen und Jens Heuschkel
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)
DFG Sonderforschungsbereich 1053 — MAKI
Multi-Mechanismen-Adaption für das künftige Internet
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#
Klausur
(0,N)
schreibt
(1,1)eingeschr. (0,N)
Student
an
Name
Fachbereich
(1,N)
gliedern
sich in
(1,1)
Zeit
hat
Zeit
(1,1)
findet
statt
(0,N)
FB#
(1,1)
(1,N)
findet
statt
(0,N)
Name
Vorlesung
findet
statt
Zeit
(1,1)
(0,N)
Titel
Professor
Name
Pers#
(1,1)
Übung
Veranst#
Titel
Name
(0,N)
(0,1)
(1,N)
hält
(0,N)
Raum#
(0,N)
gehört
zu
Raum
FG#
Fachgebiet
Veranst#
(3,3)
(1,1)
(0,N)
beschäftigt
(1,1)
stellt
ein
stellt
ein
(0,1)
(1,1)
hält
(0,N)
Mitarbeiter
Pers#
Name
22.06.2015 | Fachbereich Informatik | Datenbanken und Verteilte Systeme | Robert Rehner | 7
(0,1)
Hiwi
Pers#
Name
Aufgabe 3.1:
Relationen Schemata
Fachbereich
FB#
PK
Name
x
FK
Fachgebiet
FG#
PK
Name
x
FB#
Professor
x
FK
Fachbereich.FB#
Professor.Pers#
Professor
Pers#
PK
Name
x
FK
22.06.2015 | Fachbereich Informatik | Datenbanken und Verteilte Systeme | Robert Rehner | 8
FG# und FB# als
PK notwending da
nur weak entity!
Aufgabe 3.1:
Relationen Schemata
Mitarbeiter
Pers#
PK
Name
FG
FB
Fachgebiet.FG#
Fachgebiet.FB#
FG
FB
Fachgebiet.FG#
Fachgebiet.FB#
x
FK
Hiwi
Pers#
PK
Name
x
FK
Student
Matr#
PK
FK
Name
FB
x
Fachbereich.FB#
22.06.2015 | Fachbereich Informatik | Datenbanken und Verteilte Systeme | Robert Rehner | 9
Aufgabe 3.1:
Relationen Schemata
Vorlesung
Veranst#
PK
Titel
Raum
Zeit
x
FK
Raum.Raum#
Übung
Veranst#
PK
Titel
Raum
Zeit
Vorlesung
Mitarbeiter
Vorlesung.Veranst#
Mitarbeiter.Pers#
x
FK
Raum.Raum#
Vorlesung-Professor
Vorlesung
Professor
PK
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
Klausur-Raum
Raum#
PK
x
FK
Raum#
Klausurart
Vorlesung
PK
x
x
x
FK
Raum.Raum#
Klausur.Art
Klausur.Vorlesung
Klausur
PK
Art
Vorlesung
x
x
FK
Zeit
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
PK
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
Inv#
Noten
N
Konto
1
Seiten
leiht
aus
1
Schüler
N
Id
Eltern
Name
ist
Kind
Id
Lehrer
N
Name
N
unterrichtet
Id
N
Dauer
N
N
Raum
Name
1
Zeit
N
Beginn
Ende
Name
Instrument
Kosten
Größe
lagert
Nummer
22.06.2015 | Fachbereich Informatik | Datenbanken und Verteilte Systeme | Robert Rehner | 12
Aufgabe 3.1:
Relationen Schemata
Noten
Inv#
PK
Seiten
Ausleiher
X
FK
Schüler.Id
Eltern
Id
PK
Name
Konto
Name
Eltern
X
FK
Schüler
Id
PK
FK
X
Eltern.Id
22.06.2015 | Fachbereich Informatik | Datenbanken und Verteilte Systeme | Robert Rehner | 13
Aufgabe 3.1:
Relationen Schemata
Lehrer
Id
Name
PK
X
FK
Raum
Nummer
PK
Größe
X
FK
Instrument
Name
PK
FK
Kosten
lagert_in
X
Raum.Nummer
22.06.2015 | Fachbereich Informatik | Datenbanken und Verteilte Systeme | Robert Rehner | 14
Aufgabe 3.1:
Relationen Schemata
Unterricht
Schüler
Lehrer
Raum
Instrument
Zeit
PK
X
X
X
X
FK
Schüler.Id
Lehrer.Id
Raum.Nummer
Instrument.Name
Beginn
Ende
X
X
Ist das Ergebnis streng nach Umsetzungsvorschrift. Problem: Unterricht, der noch
andauert, hätte Ende = null, was nicht erlaubt ist, da Ende Teil vom PK ist.
Unterricht
Schüler
Lehrer
Raum
Instrument
Zeit
Dauer
PK
X
X
X
X
X
FK
Schüler.Id
Lehrer.Id
Raum.Nummer
Instrument.Name
Dauer.Id
Dauer
Id Beginn
Ende
X
Diese Variante umgeht das Problem, indem eine eigene Relation mit extra Primärschlüssel
für Dauer angelegt wird.
Unterricht
Schüler
PK
X
Lehrer
X
Raum
Instrument
X
Zeit
X
Beginn
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
Ende
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.
𝐹 = {𝐵 → 𝐶, 𝐴 → 𝐷𝐸, 𝐵𝐶 → 𝐹, 𝐹 → 𝐺𝐻, 𝐴 → 𝐼, 𝐷 → 𝐼}
𝐵 → 𝐶, 𝐵𝐶 → 𝐹, 𝐹 → 𝐺𝐻 ⊨ 𝐵 → 𝐵𝐶𝐹𝐺𝐻
𝐴 → 𝐷𝐸, 𝐴 → 𝐼
⊨ 𝐴 → 𝐴𝐷𝐸𝐼
𝐵𝐶 → 𝐹, 𝐹 → 𝐺𝐻
⊨ 𝐵𝐶 → 𝐵𝐶𝐹𝐺𝐻
𝐹 → 𝐺𝐻
⊨ 𝐹 → 𝐹𝐺𝐻
𝐷→𝐼
⊨ 𝐷 → 𝐷𝐼
 keine linke Seite bildet alleine einen Schlüsselkandidaten.
 z.B. 𝐴, 𝐵, 𝐶 bildet einen Superschlüssel, der aber nicht minimal ist.
 {𝐴, 𝐵} 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: {𝐴𝐵 → 𝐶, 𝐵 → 𝐴}
{𝐴𝐵 → 𝐶, 𝐵 → 𝐴}
≡
?!
{𝐵 → 𝐶, 𝐵 → 𝐴}

𝐴𝐵 → 𝐶, 𝐵 → 𝐴
(Erweiterung) 𝐴𝐵 → 𝐶, 𝐵 → 𝐴, 𝐵 → 𝐴𝐵
(Transitivität) 𝐴𝐵 → 𝐶, 𝐵 → 𝐴, 𝐵 → 𝐴𝐵, 𝐵 → 𝐶

𝐵 → 𝐶, 𝐵 → 𝐴
𝐵 → 𝐶, 𝐵 → 𝐴, 𝐴𝐵 → 𝐴𝐶
(Erweiterung)
𝐵 → 𝐶, 𝐵 → 𝐴, 𝐴𝐵 → 𝐴𝐶, 𝐴𝐵 → 𝐶 (Projektivität)
(𝐴𝐵
Beispiel: A: Titel, B: ISBN, C: Autor
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
𝐹 = {𝐵 → 𝐶, 𝐴 → 𝐷𝐸, 𝐵𝐶 → 𝐹, 𝐹 → 𝐺𝐻, 𝐴 → 𝐼, 𝐷 → 𝐼}
Entferne Attribut 𝐶 in 𝐵𝐶 → 𝐹, da 𝐵 → 𝐶
 𝐹′ = {𝐵 → 𝐶, 𝐴 → 𝐷𝐸, 𝐵 → 𝐹, 𝐹 → 𝐺𝐻, 𝐴 → 𝐼, 𝐷 → 𝐼}
Es ist nicht möglich alternativ 𝐵 aus 𝐵𝐶 → 𝐹 zu entfernen. Man kann
zwar 𝐵𝐶 → 𝐹 aus 𝐶 → 𝐹 herleiten, allerdings nicht 𝐶 → 𝐹 aus 𝐵𝐶 → 𝐹.
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 𝐹 = 𝐵 → 𝐶, 𝐴 → 𝐷𝐸, 𝐵𝐶 → 𝐹, 𝐹 → 𝐺𝐻, 𝐴 → 𝐼, 𝐷 → 𝐼 können wir 𝐵 → 𝐵𝐶𝐹𝐺𝐻 und
𝐴 → 𝐴𝐷𝐸𝐼 ableiten. Womit sich {𝐴, 𝐵} als Schlüsselkandidat ergibt. (Aufgabe 3.2)
Kann man also 𝐹 auf 𝐹′ = 𝐵 → 𝐵𝐶𝐹𝐺𝐻, 𝐴 → 𝐴𝐷𝐸𝐼 reduzieren?  nein!
Beweis:
Wenn 𝐹 und 𝐹′ äquivalent wären, dann müssten die Transitiven Hüllen 𝐹 + und 𝐹′+
gleich sein. Aber 𝐹 + enthält z.B. 𝐷 → 𝐼 was sich aus 𝐹′ 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
𝐹 = {𝐴 → 𝑋, 𝐴𝐵 → 𝑌}
Streicht man 𝐴 aus 𝐴𝐵 → 𝑌 heraus, entsteht
𝐹´ = {𝐴 → 𝑋, 𝐵 → 𝑌}
Die ursprüngliche FD 𝐴𝐵 → 𝑌 lässt sich aber aus der FD 𝐵 → 𝑌
durch Erweiterung wieder herstellen.
Darf man also 𝐴 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 𝐹, bemerkt man schnell, dass sich die
FD 𝐵 → 𝑌 , die in 𝐹′ enthalten ist, nicht herleiten lässt und die
beiden FD-Mengen somit nicht äquivalent sind.
Informell kann man sich klar machen, dass in 𝐹 sowohl 𝐴 als
auch 𝐵 notwendig sind, um 𝑌 zu bestimmen. Lässt man 𝐴 weg,
müsste 𝐵 alleine ausreichen, um 𝑌 zu bestimmen, was in 𝐹 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