Implementierung von Algorithmen zur Datenanonymisierung

Humboldt-Universität zu Berlin
Mathematisch-Naturwissenschaftliche Fakultät
Institut für Informatik
Implementierung von Algorithmen zur
Datenanonymisierung in DB2
Bachelorarbeit
zur Erlangung des akademischen Grades
Bachelor of Science (B. Sc.)
eingereicht von:
geboren am:
geboren in:
Dimitar Dimitrov
9.8.1990
Stara Zagora
Gutachter/innen: Prof. Johann-Christoph Freytag, Ph.D.
Prof. Dr. Björn Scheuermann
eingereicht am:
ii
Zusammenfassung
Zahlreiche Organisationen und Firmen erfassen personenbezogene Informationen
über Individuen, wie z.B. Einkommen, verschriebene Medikamente oder Krankheiten. In vielen Fällen ist es wünschenswert, dass diese Daten anonymisiert an
Dritte weitergegeben werden, z.B. für medizinische Studien.
Die Weitergabe erfolgt in der Form von Mikrodaten. Mikrodaten bezeichnen
nicht aggregierte Information. Aus Datenschutzgründen werden dabei in vielen
Fällen personenbezogene Daten, wie z.B. der Name, die Kontonummer oder Matrikelnummer, entfernt. Dieser Vorgang wird De-Identifikation genannt. Da die
De-Identifikation von Mikrodaten nicht ausreichend für eine Anonymisierung ist,
wurden erweiterte Konzepte zum Anonymisieren von Mikrodaten entwickelt.
Samarati und Sweeney haben das Konzept der k-Anonymity vorgestellt [SS98].
Durch Veränderung der Werte in den Mikrodaten, wird sichergestellt, dass die
Identifikation von Individuen nicht eindeutig möglich ist. Machanavajjhala et al.
haben gezeigt, dass Angriffe auf k-anonymisierte Tabellen existieren. Um dem
entgegenzuwirken, entwickelten sie das Konzept `-Diversity [MGKV06]. Dabei
werden weitere Anforderungen an den anonymisierten Mikrodaten gestellt. Anhand
diesen Konzepten sind mehrere Anonymisierungslagorithmen entstanden.
Zur Implementierung von Algorithmen zur Datenanonymisierung bieten sich
Datenbanksysteme an. Viele Datenbankmanagementsysteme (DBMS) erlauben
es, ihre Funktionalität auf verschiedenen Wegen zu erweitern. Routinen in DBMS
ermöglichen die Ausführung von komplexer Logik auf Daten. Nach bestem Wissen existieren bislang keine Veröffentlichungen, welche die Implementierung der
Anonymisierungsalgorithmen als DBMS-Routinen thematisieren.
Die Implementierung von Konzepten zur Datenanonymisierung in einem Datenbanksystem bietet ein lohnendes Forschungsfeld, da für die Anonymisierung von
Mikrodaten nur wenige Werkzeuge frei verfügbar sind. Routinen werden auf dem
Datenbankserver durch das DBMS ausgeführt. Wird die entsprechende Routine
aufgerufen, bekommt der Benutzer als Ergebnis eine anonymisierte Tabelle in der
Datenbank. Routinen sind eng mit der Datenbank verknüpft, was eine schnelle
Ausführung erlaubt.
iii
iv
Inhaltsverzeichnis
1. Einleitung
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Grundlagen
2.1. Daten . . . . . . . . . . . . . . . . .
2.2. Generalisierung und Unterdrückung
2.3. Anonymisierungskonzepte . . . . . .
2.4. Datenbankprogrammierung . . . . .
1
1
2
3
.
.
.
.
5
5
7
9
13
3. Anonymisierungsalgorithmen
3.1. Datafly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Incognito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3. Incognito mit `-Diversity . . . . . . . . . . . . . . . . . . . . . . . . . .
17
17
19
24
4. Implementierung
4.1. UTD Anonymization ToolBox . . . . . . . . . . . . . . . . . . . . . . .
4.2. Implementierung der Algorithmen als Routinen . . . . . . . . . . . . .
25
25
26
5. Experimente
5.1. Datafly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2. Incognito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
30
32
6. Zusammenfassung und Ausblick
6.1. Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
37
37
A. Optimizer Plan des Kantengenerierungsschritts in Incognito
A.1. Originale SQL-Anweisung des Kantengenerierungsschritts in Incognito
A.2. Optimisierte SQL-Anweisung für den Kantengenerierungsschritt in Incognito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
39
B. Konfiguration der UTD Anonymization ToolBox
45
Literatur
51
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
v
Abbildungsverzeichnis
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Beispiele für Domain- und Value-Generalization-Hierarchy . . . . . . .
Gitter der Generalisierungen für die Attribute Alter und Geschlecht
und deren Distanzvektoren . . . . . . . . . . . . . . . . . . . . . . . .
Art der Implementierung von Routinen in DB2 . . . . . . . . . . . . .
Beispiel einer Prozedur, die die Anzahl von unterschiedlichen Attributwerten in der Domäne eines Attributs bestimmt . . . . . . . . . . . . .
Durchsuchen der Gitter für die Attribute Alter und Geschlecht . . .
Architektur der UTD Anonymization ToolBox . . . . . . . . . . . . .
Architektur der Implementierung aus dieser Bachelorarbeit . . . . . .
Performanz von DB2MAF für verschiedene Größen von QIT bei festem
k-, bzw. `-Wert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performanz von Datafly für verschiedene Größen von QIT bei festem
k-Wert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performanz von Datafly bei fester Größe von QIT für verschiedene k-Werte
Performanz von Incognito für verschiedene Größen von QIT bei festem
k-Wert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performanz von Incognito bei fester Größe von QIT für verschiedenene
k-Werte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auswirkung des Reduktionsschritts bei der Generierung des Generalisierungsgraphen in Incognito bei fester Größe von QIT für verschiedene
k-Werte mit und ohne Pruning . . . . . . . . . . . . . . . . . . . . . .
Auswirkung der Implementierung des Kantengenerierungsschritts auf
die Laufzeit von Incognito für verschiedene Größen von QIT und k = 8
Performanz von Incognito für verschiedene Größen von QIT bei festem
`-Wert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performanz von Incognito bei fester Größe von QIT für verschiedenene
`-Werte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
10
14
15
20
25
27
30
31
31
32
33
33
34
35
35
Tabellenverzeichnis
1.
2.
3.
4.
5.
6.
7.
8.
vi
Daten eines Kreditunternehmens . . . . . . . . . . . . . . . . . . .
Anonymisierung von Tabelle 1, die 4-Anonymity genügt . . . . . .
Anonymisierung von Tabelle 1, die 3-Diversity genügt . . . . . . .
Ablauf der Generalisierungen in Datafly . . . . . . . . . . . . . . .
Anonymisierung von Tabelle 1 mit Datafly . . . . . . . . . . . . . .
Darstellung des Gitters für die Attribute Alter und Geschlecht
Abbilding 2a als Tabellen . . . . . . . . . . . . . . . . . . . . . . .
Laufzeit von Datafly als SQL und Java Routine für |QIT | = 7 . . .
Beschreibung des Adult Data Sets . . . . . . . . . . . . . . . . . .
. .
. .
. .
. .
. .
im
. .
. .
. .
6
10
12
18
19
22
26
29
Algorithmenverzeichnis
1.
2.
3.
4.
5.
6.
Datafly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incognito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reduktionsschritt von GraphGeneration in Incognito . . . . . . . . . .
Kantengenerierungsschritt von GraphGeneration in Incognito . . . . .
Optimierter Kantengenerierungsschritt von GraphGeneration in Incognito
`-Diversity in Incognito . . . . . . . . . . . . . . . . . . . . . . . . . .
17
21
22
23
23
24
Abkürzungsverzeichnis
DB2MAF DB2 Microdata Anonymization Framework
DBMS Datenbankmanagementsystem
DBS Datenbanksystem
DGH Domain-Generalization-Hierarchy
SQL Structured Query Language
SQL PL SQL Procedural Language
VGH Value-Generalization-Hierarchy
XML Extensible Markup Language
vii
viii
1. Einleitung
1.1. Motivation
Zahlreiche Organisationen und Firmen erfassen personenbezogene Informationen über
Individuen, wie z.B. Einkommen, verschriebene Medikamente oder Krankheiten. In
vielen Fällen ist es wünschenswert, dass diese Daten anonymisiert an Dritte weitergegeben werden, z.B. für medizinische Studien. Die Weitergabe erfolgt in der Form von
Mikrodaten. Mikrodaten bezeichnen nicht aggregierte Information [Gra77, S. 432].
Aus Datenschutzgründen werden dabei in der Regel identifizierende personenbezogene
Daten, wie z.B. der Name, die Kontonummer oder Matrikelnummer, entfernt. Dieser
Vorgang wird De-Identifikation genannt. Nach dem Bundesdatenschutzgesetz ist eine
Information genau dann anonymisiert, wenn die Identifikation einer einzelnen Person
schwer oder sogar unmöglich ist [BDS90]. Nach §3 Abs. 6 BDSG. wird verlangt, dass:
„Einzelangaben über persönliche oder sachliche Verhältnisse nicht mehr
oder nur mit einem unverhältnismäßig großen Aufwand an Zeit, Kosten
und Arbeitskraft einer bestimmten oder bestimmbaren natürlichen Person
zugeordnet werden können.“
Latanya Sweeny konnte zeigen, dass die durch De-Identifikation veränderten Mikrodaten nicht anonym sind [Swe00]. Durch Linking der Mikrodaten mit Daten aus
anderen Quellen ist es möglich, Tupel eindeutig zu identifizieren [Swe02b, S. 2]. Linking bezeichnet die Verknüpfung von zwei Tabellen anhand gemeinsamer Attributen
[Swe02b, S. 7]. Da die De-Identifikation von Mikrodaten nicht ausreichend für eine
Anonymisierung ist, wurden erweiterte Konzepte zur anonymisierten Weitergabe von
Mikrodaten entwickelt.
Samarati und Sweeney haben das Konzept der k-Anonymity in [SS98] vorgestellt.
Durch Veränderung von den Werten des Quasi-Identifikators wird sichergestellt, dass
die Identifikation von Mikrodaten anhand des Quasi-Identifikators nicht eindeutig
möglich ist. Ein Quasi-Identifikator ist eine Kombination von Attributen, die Tupel in
den Mikrodaten eindeutig identifizieren können [Dal86, S. 330]. Eine Veröffentlichung
genügt der k-Anonymity, wenn jedes Tupel bezogen auf den Quasi-Identifikator von
mindestens k − 1 anderen Tupeln nicht unterscheidbar ist [SS98, S. 3].
Machanavajjhala et al. [MGKV06] haben gezeigt, dass Angriffe auf k-anonymisierte
Tabellen existieren. Der erste Angriff basiert darauf, dass alle Tupel in einer Äquivalenzklasse der k-anonymisierten Tabelle dieselben Werte in ihren sensiblen Attributen
haben können. Eine Äquivalenzklasse ist eine Menge von Tupeln mit den gleichen
Werten für den Quasi-Identifikator. Der zweite Angriff stützt sich darauf, dass auch
das Hintergrundwissen eines Angreifers die Identifikation von Tupeln ermöglichen kann
[MGKV06, S. 2]. Diese zwei Angriffe werden entsprechend Homogeneity Attack und
Background Knowledge Attack genannt. Um ihnen entgegenzuwirken, entwickelten Machanavajjhala et al. in [MGKV06] das Konzept der `-Diversity. Eine Tabelle genügt der
`-Diversity genau dann, wenn alle Äquivalenzklassen mindestens ` „wohlunterschiedene
Werte“ für das sensible Attribut haben [MGKV06, S. 7].
1
1. Einleitung
Das Problem, optimale k-Anonymity für eine gegebene Tabelle zu schaffen ist NPhart [MW04], [AFK+ 05, S. 5]. Es wurden aber eine große Vielzahl an Approximationsalgorithmen mit besserer Laufzeit entwickelt. Datafly [Swe02a] ist einer der ersten
Algorithmen, der die k-Anonymity von Mikrodaten umsetzt. Bei Datafly handelt es sich
um einen Greedy-Algorithmus, welcher Generalisierung und Unterdrückung benutzt,
um die Tupel zu anonymisieren. Generalisierung bedeutet, dass der Wert des QuasiIdentifiers eines Tupels durch einen weniger spezifischen Wert ersetzt wird, der dennoch
semantisch geeignet ist. Unter Unterdrückung wird das Ersetzen des Attributwertes
durch ein Zeichen, das kein spezifisches Wissen über den Wert verrät, verstanden.
Ein weiterer Algorithmus ist Incognito [LDR05], welcher Generalisierung und Unterdrückung von Attributwerten benutzt, um die Tupel einer Tabelle zu anonymisieren. Incognito produziert verschiedene Generalisierungen und wählt eine minimale k-anonyme
Generalisierung aus. Eine Generalisierung ist minimal, wenn keine weitere Generalisierungen existieren, die k-Anonymity genügen und die Attribute des Quasi-Identifikators
weniger generalisieren [LDR05, S. 51]. Die Laufzeit von Incognito ist exponentiell in
Bezug auf die Anzahl an Attributen des Quasi-Identifikators [LDR05, S. 56]. Um den
Algorithmus zu beschleunigen wurden Techniken aus den Bereichen des Data-Mining
und der dynamischen Programmierung benutzt [LDR05, S. 52].
Zur Implementierung von Algorithmen zur Datenanonymisierung bieten sich Datenbanksysteme an. Die Sicherstellung von Datenintegrität, Robustheit, effizientem
Datenzugriff und Datenmanipulation sind Kernanforderungen an Datenbanksysteme [AHV95, S. 5–6]. Viele Datenbankmanagementsysteme (DBMS) erlauben es, ihre
Funktionalität auf verschiedenen Wegen zu erweitern. Eine dieser Möglichkeiten sind
Datenbankanwendungen. Datenbankanwendungen sind Programme, die ein Datenbanksystem als Speicher benutzen. Ein Beispiel ist die UTD Anonymization ToolBox.
Sie implementiert die Anonymisierungsalgorithmen im Programm und lagert die zu
anonymisierenden Daten in einer Datenbank ein.
Eine weitere Möglichkeit sind Routinen. Routinen in DBMS ermöglichen die Ausführung von komplexer Logik auf Daten. Routinen sind eng mit der Datenbank verknüpft,
was eine schnelle Ausführung erlaubt [IBM06, S. 53]. Schnell bedeutet in diesem Fall
eine möglichst kurze Laufzeit. Routinen verbessern das Leistungsverhalten von Programmen, indem sie die Daten lokal verarbeiten und die Kommunikation zwischen
Programm und DBMS reduzieren. Leistungsverhalten bedeutet, dass ein Programm
möglichst schnell eine korrekte Ausgabe liefert. Routinen können die Entwicklung von
Programmen erleichtern, indem sie eine einheitliche Schnittstelle zu den Daten im
Datenbanksystem bereitstellen [IBM06, S. 6].
Nach bestem Wissen existieren bislang keine Veröffentlichungen, welche die Implementierung von Algorithmen zur Datenanonymisierung als Routinen thematisieren.
1.2. Ziele
Die vorliegende Bachelorarbeit stellt sich als Ziel drei Algorithmen – Datafly, Incognito
und Incognito mit `-Diversity, die in der UTD Anonymization ToolBox implementiert
sind, als Routinen in einem DBMS zu implementieren. Dabei soll ein Überblick über
2
1.3. Aufbau der Arbeit
die verwendeten Anonymisierungskonzepte und -algorithmen geschaffen werden.
Diese Bachelorarbeit soll weiterhin eine Aussage darüber treffen, was für eine Auswirkung die Implementierung der Algorithmen als Routinen auf deren Leistungsverhalten
hat. Darüber hinaus soll die Implementierung der Algorithmen gegenüber denen der
UTD Anonymization ToolBox evaluiert werden.
1.3. Aufbau der Arbeit
Die Bachelorarbeit ist in sechs Kapitel gegliedert. Kapitel 2 befasst sich mit den
grundlegenden Konzepten, die für das Verständnis der vorliegenden Arbeit notwendig
sind. Neben einer Einführung in die Methoden der Datenanonymisierung werden
wichtige Anonymisierungskonzepte anhand von Beispielen genauer untersucht. In diesem
Kapitel werden zusätzlich prozedurale Programmierkonzepte in einem relationalen
Datenbankmanagementsystem vorgestellt.
Die Anonymisierungsalgorithmen, die im Zuge der Bachelorarbeit implementiert
worden sind, werden im Kapitel 3 anhand von Pseudocode detailiert vorgestellt und
erläutert.
In Kapitel 4 wird die entstandene Implementierung eingeführt und die getroffenen
Designentscheidungen begründet. Dabei wird auf die Herausforderungen während der
Entwicklung eingegangen.
Kapitel 5 befasst sich mit der Evaluierung der Implementierung. Anhand verschiedener
Experimenten wird die Laufzeit der entstandenen Implementierung gegenüber denen
der UTD Anonymization ToolBox evaluiert.
Kapitel 6 bietet einen Überblick über die gewonnenen Erkenntnisse, zieht die entsprechenden Schlüssfolgerungen und gibt einen Ausblick über mögliche zukünftige
Entwicklungen.
3
4
2. Grundlagen
Da die Implementierung von Algorithmen zur Anonymisierung von Daten die zentrale
Aufgabe dieser Bachelorarbeit ist, wird in diesem Kapitel eine einheitliche Terminologie
für die Konzepte und Methoden aus dem Bereich der Datenanonymisierung eingeführt.
Anschließend werden bestimmte Aspekte aus der Datenbankprogrammierung vorgestellt.
2.1. Daten
Mikrodaten, Tupel, Tabelle
Daten werden im Kontext dieser Arbeit als Mikrodaten verstanden. Der Begriff Mikrodaten bezeichnet in dem Bereich der Statistik die Menge aller Informationen aus
einer Datenerhebung [WW01, S. 1]. Eine Datenerhebung kann als eine Stichprobe χ
aus einer Population Ω verstanden werden. Eine Population bezeichnet die Gesamtheit
von Individuen, die bei der Datenerhebung untersucht wurden.
Mikrodaten sind deshalb in der Regel personenbezogen, sie beschreiben mehrere
Individuen ω aus einer Population Ω [WW01, S. 40]. Informationen, die als Mikrodaten
aufgefasst werden, sind nicht aggregiert [Gra77, S. 432].
Der Begriff der Mikrodaten wird nach Willenborg und de Waal [WW01, S. 13]
definiert:
Definition 1 (Mikrodaten) Mikrodaten bestehen aus Reihen von Datensätzen, wobei
sich jeder Datensatz auf eine Person bezieht. Die Daten werden in einer unveränderten,
nicht-aggregierten Form aufgefasst. Weiterhin existieren keine Abhängigkeiten zwischen
den einzelnen Attributen der Datensätzen.
Es wird weiterhin angenommen, dass jedes Individuum ω nur einmal in den Mikrodaten vorkommt. Diese Annahme vereinfacht die Diskussion über die Konzepte und
Methoden ohne ihre Anwendbarkeit zu verletzen [Swe02b, S. 6].
Mikrodaten werden üblicherweise in der Form einer Tabelle dargestellt. Die Beispiele
in dieser Arbeit werden sich an dieser Darstellungsform orientieren.
Eine Tabelle repräsentiert die Mikrodaten durch Zeilen und Spalten. Die Zeilen einer
Tabelle enthalten Informationen über Individuen und werden durch Tupel beschrieben.
Ein Tupel umfasst eine Menge von Attributen {A1 , . . . , An }, n ∈ N. Der Name Ai ∈
{A1 , . . . , An } einer Spalte, wird als Attribut bezeichnet. Die in der Spalte enthaltenen
Werten bilden die Domäne des entsprechenden Attributs. Der Begriff der Relation aus
dem Relationenmodell bei den relationalen Datenbankmanagementsystemen entspricht
dem Begriff der Tabelle [Swe02b, S. 6].
Definition 2 (Relation) Sei dom (Ai ) die Domäne eines Attributs Ai mit Ai ∈
{A1 , . . . , An } und sei {dom (A1 ) × . . . × dom (An )} das kartesische Produkt der Domänen dieser Attributen. Sei weiterhin eine Relation R eine Teilmenge dieses kartesischen
Produktes.
5
2. Grundlagen
Um die Notation einheitlich zu halten werden die Begriffe des Tupels und der Tabelle
nach Ullman [Ull94, S. 43] und Sweeney [Swe02b] formal definiert:
Definition 3 (Tupel) Ein Element t aus einer Relation R wird n-Tupel oder einfach
Tupel genannt. Der Wert des Attributs Ai in dem Tupel t wird mittels t [Ai ] bezeichnet.
Eine Tabelle T kann als eine Menge von Tupeln verstanden werden. Die Anzahl von
Tupeln in T wird mit |T | bezeichnet.
Definition 4 (Tabelle) Eine Tabelle T (A1 , . . . , An ) wird über eine Relation R mit
Attributen A1 , . . . , An , zusammen mit der Menge von Tupeln, die der Relation gehören,
definiert.
ID
Name
1
2
3
4
5
6
7
8
9
10
11
12
Julia
Stefanie
Nicole
Sandra
Michael
Peter
Thomas
Hans
Laura
Sarah
Lisa
Anna
PLZ
Alter
Geschlecht
Bonität
12741
12734
12734
12741
12486
12486
12482
12482
12741
12741
12734
12734
31
36
35
37
60
65
57
59
21
23
21
29
weiblich
weiblich
weiblich
weiblich
männlich
männlich
männlich
männlich
weiblich
weiblich
weiblich
weiblich
gut
mittel
gut
mittel
schlecht
gut
mittel
mittel
schlecht
schlecht
schlecht
schlecht
Tabelle 1: Daten eines Kreditunternehmens
Tabelle 1 stellt ein Beispiel für Mikrodaten dar. Die Tabelle enthält 12 Tupel, die
durch 6 Attribute – ID, Name, PLZ, Alter, Geschlecht und Bonität, beschrieben werden.
Weiter in der Arbeit werden die Attribute in Schreibmaschinenschrift gesetzt.
Schlüssel, Quasi-Identifikator, Sensibles Attribut
Ein Schlüssel besteht aus einem oder mehreren Attributen und ermöglicht die eindeutige
Zuordnung von Tupeln aus den Mikrodaten zu Individuen [Swe02b, S. 7]. Schlüssel
können eindeutige Nummern sowie Namen sein.
Definition 5 (Schlüssel) Sei T (A1 , . . . , An ) eine Tabelle und seien {A1 , . . . , An }
eine Menge von Attributen. Ein Schlüssel besteht aus den Attributen Ai , . . . , Aj und
identifiziert jedes Tupel t ∈ T eindeutig. Mit IDT ⊆ {A1 , . . . , An } wird die Menge der
Attribute bezeichnet, die den Schlüssel von T aufbauen.
6
2.2. Generalisierung und Unterdrückung
Die Attribute ID und Name bilen den Schlüssel in Tabelle 1. Da diese Attribute nie
Teil einer veröffentlichen Tabelle sein werden, werden sie in den nächsten Beispielen in
Grau dargestellt.
Der Begriff Quasi-Identifikator 1 wird nach Sweeney [Swe02b, S. 7] wie folgt definiert:
Definition 6 (Quasi-Identifikator) Sei χ eine Stichprobe und sei T (A1 , . . . , An )
eine Tabelle. Ferner seien fc : χ → T und fg : T → Ω zwei Funktionen mit χ ⊆ Ω.
Ein Quasi-Identifikator von T , bezeichnet als QIT , ist eine Menge von Attributen
{Ai , . . . , Aj } ⊆ {A1 , . . . , An } für die gilt
∃ωi ∈ χ : fg (ΠQIT (fc (ωi ))) = ωi .
Die Funktion fc bildet in diesem Fall die Mikrodaten in der Form einer Tabelle ab.
Die Funktion fg sorgt dafür, dass Tupel der Tabelle t ∈ T auf Individuen der Population
ω ∈ Ω abgebildet werden können. Die Projektion ΠQIT (T ) liefert als eine Menge die
Werte t [Ai , . . . , Aj ] der Attributen Ai bis Aj von QIT .
Ein Quasi-Identifikator ist eine Kombination von Attributen, die ein Individuum aus
einer Population eindeutig identifizieren kann [Dal86, S. 330]. In Tabelle 1 wird der
Quasi-Identifikator durch die Attribute PLZ, Alter und Geschlecht gebildet.
Definition 7 (Sensibles Attribut) Sei T (A1 , . . . , An ) eine Tabelle mit einer Menge
von Attributen {A1 , . . . , An }. Ein Attribut wird als sensibel gekennzeichnet, wenn seine
Attributwerte nicht mit den Schlüsselwerten verbunden werden dürfen. SAT ist dann
die Menge der sensiblen Attributen aus T mit SAT ⊆ {A1 , . . . , An }.
Als sensibel werden solche Attribute bezeichnet, die Informationen enthalten, die
aus der Sicht des Datenschutzes nicht mit Individuen verbunden sein dürfen [WW01,
S. 9]. In Tabelle 1 wurde Bonität als sensibles Attribut festgelegt.
Neben der drei eingeführten Attribut-Typen existieren auch neutrale Attribute. Alle
Attribute Ai ∈ {A1 , . . . , An }, die weder zum Schlüssel noch zum Quasi-Identifikator
gehören und keine sensible Attribute sind, werden als neutral bezeichnet [BS08, S. 2].
2.2. Generalisierung und Unterdrückung
Um vor De-Anonymisierung durch Linking zu schützen wurde das Prinzip der Generalisierung und Unterdrückung entwickelt [Swe02a, S. 2].
Unter Generalisierung eines Attributs wird die Ersetzung des Attributwertes durch
einen weniger spezifischen, aber jedoch semantisch korrekten Wert verstanden [Swe02a,
S. 5]. Die Unterdrückung eines Attributwertes beschreibt die Entfernung des Attributwertes oder die Ersetzung des Attributwertes durch ein Zeichen oder einen Wert ohne
Bedeutung für die Domäne dieses Attributs [Swe02a, S. 5].
1
Der Name „Quasi-Identifikator“ wurde von Tore Dalenius eingeführt [Dal86, S. 329].
7
2. Grundlagen
Domain- und Value-Generalization-Hierarchy
Der Begriff Domäne bezeichnet in relationale Datenbankmanagementsystemen die
Menge von Werten, die ein Attribut haben kann [Swe02a, S. 5]. Ein Beispiel dafür sind
die Postleitzahlen {12482, 12486} aus der Domäne des Attributs PLZ in Tabelle 1. Jede
Postleitzahl ist eine Kombination von 5 Ziffern zwischen 0 und 9. Die Werte „12482“
und „12486“ können dann nach dem Prinzip der Generalisierung zu „1248∗“ verändert
werden. Die Postleitzahl „1248∗“ repräsentiert alle Postleitzahlen zwischen „12480“
und „12489“.
Die Domänen-Hierarchie ist eine Erweiterung von der Domäne eines Attributs
[Swe02a, S. 5]. Eine Domänen-Hierarchie bezeichnet eine Menge von Domänen für die
Werte des Attributs. Eine Domäne wird in der Nächsten überführt, indem alle ihre
Werte generalisiert werden. Dieses Vorgehen wird Full-Domain Genelisierung genannt
[LDR05, S. 51]. Dabei wird sichergestellt, dass alle Attributwerte eines Attributs zu
der gleichen Domäne gehören.
Die Domain-Generalization-Hierarchy (DGH) wird nach [Swe02a, S. 5] als die Vereinigung von den Domänen in der Domänen-Hierarchie eines Attributs definiert und
wird als ein Baum dargestellt. Der Baum ist in Richtung Blätter zu Wurzel gerichtet.
Die Generalisierung wird durch eine Kante repräsentiert, ersetzt werden dabei die
Attributwerte des unteren Knotens durch die Attributwerte des oberen Knotens. Die
Ebene mit den originalen Attributwerten wird als H0 bezeichnet, die Wurzel als Hmax .
Die Höhe eines Knotens Hi wird durch sein Index i ∈ N bestimmt und wird durch die
Kantenzahl im Weg H0 , . . . , Hi definiert.
Um ein Attributwert aus der Ebene Hi in einen Wert der Ebene Hi+1 zu überführen
wird eine Value-Generalization-Hierarchy (VGH) definiert [Swe02a, S. 5]. In diesem
Baum bekommt jeder Wert aus einer Ebene Hi einen eigenen Knoten. Jeder Knoten
aus der Ebene Hi ist dann durch eine Kante mit einem Knoten aus Ebene Hi+1 , mit
seinem generalisierten Wert, verbunden.
Abbildung 1 veranschaulicht die VHGs für die Attribute PLZ, Alter und Geschlecht
aus Tabelle 1. Abbildung 1b enthält H0 die originale Attributwerte von PLZ. Hmax enthält dagegen die maximale Generalisierung, nämlich „12 ∗ ∗∗“. Bei einer Unterdrückung
wird der einzige Wert „12 ∗ ∗∗“ aus Hmax benutzt [Swe02a, S. 5].
Die DGHs von zwei oder mehreren Attributen können als ein Gitter kombiniert
werden [LDR05, S. 51]. Sei QIT = {Alter, Geschlecht}. Abbildung 2a ist ein Beispiel
für das Gitter der Attribute Alter und Geschlecht. A0 und G0 bezeichnen die Domänen der Attribute Alter und Geschlecht, die die originale Attributwerte enthalten.
hA0 , G0 i bezeichnet die Multi-Attribut-Generalisierung, bei der die Attribute Alter und
Geschlecht in ihren originalen Attributwerten berücksichtigt werden. Jeder Knoten im
Gitter repräsentiert eine Multi-Attribut-Generalisierung, die aus zwei Attributen besteht.
In Abbildung 2b werden die Distanzvektoren für jede Multi-Attribut-Generalisierung
in 2a angegeben. Die Höhe von einer Multi-Attribut-Generalisierung ist die Summe
der Werte in dem entsprechenden Distanzvektor.
Für die Erstellung der Value-Generalization-Hierarchy werden anhand der Domäne
verschiedene Ansätze benutzt. Zwei davon sind die Benutzung von Hierarchien und
8
2.3. Anonymisierungskonzepte
Hmax = {12 ∗ ∗∗}
12 ∗ ∗∗
H2 = {124 ∗ ∗, 127 ∗ ∗}
124 ∗ ∗
H1 = {1248∗, 1273∗, 1274∗}
1248∗
1273∗
1274∗
H0 = {12482, 12486, 12734, 12741}
12482 12486
12734
12741
(a) DGH für PLZ
127 ∗ ∗
(b) VGH für PLZ
∗
2∗
≥ 40
3∗
∗
21
29
23
31
37
35
57
36
(c) VGH für Alter
65
59
60
weiblich
männlich
(d) VGH für Geschlecht
Abbildung 1: Beispiele für Domain- und Value-Generalization-Hierarchy
die Partitionierung der Domäne [LDR05, S. 57]. Bei einer Partitionierung werden die
Attributwerte in nicht überlappende Intervalle aufgeteilt. Die VGH vom Attribut Alter
in Abbildung 1c ist ein Beispiel für eine Partitionierung. Eine Hierarchie wird benutzt,
wenn die Domäne kategoriale Attributwerte enthält. Ein Beispiel dafür ist die VGH
vom Attribut PLZ in Abbildung 1b.
2.3. Anonymisierungskonzepte
Die Benutzung von Generalisierung und Unterdrückung – Umschreibung und das Löschen von Werten oder das Abrunden von Zahlen – zum Schutz von sensiblen Attributen
wurde bereits im Bereich der Statistik in Betracht gezogen [Dal86, S. 336]. k-Anonymity
ist das erste Konzept, das das Prinzip der Generalisierung und Unterdrückung zur
Anonymisierung von Mikrodaten formal definiert [Sam01, S. 1025].
k-Anonymity
Das Konzept der k-Anonymity2 wird nach Samarati und Sweeney definiert [SS98, S. 3].
2
Der Name „k-Anonymity“ wurde von Pierangela Samarati eingeführt [Swe02b, S. 13].
9
2. Grundlagen
hA2 , G1 i
[2, 1]
hA2 , G0 i
hA1 , G1 i
[2, 0]
[1, 1]
hA1 , G0 i
hA0 , G1 i
[1, 0]
[0, 1]
hA0 , G0 i
[0, 0]
(a)
(b)
Abbildung 2: Gitter der Generalisierungen für die Attribute Alter und Geschlecht
und deren Distanzvektoren
Definition 8 (k-Anonymity) Sei T (A1 , . . . , An ) eine Tabelle und QIT ein QuasiIdentifikator, der mit der Tabelle assoziiert ist. T genügt der k-Anonymity, wenn für
jedes Tupel ti ∈ T gilt, dass ti [QIT ] von mindestens k − 1 weiteren Tupeln tj [QIT ] ∈ T
mit 1 ≤ i, j ≤ |T | nicht unterscheidbar ist.
Wenn T eine k-anonyme Tabelle ist und QIT = {Ai , . . . , Aj } der Quasi-Identifikator
von T ist, dann existieren mindestens k Tupel t mit den gleichen Attributwerten
t [Ai , . . . , Aj ]. Das impliziert die Bildung von Äquivalenzklassen. Alle Tupel in einer
Äquivalenzklasse sind bezüglich des Quasi-Identifikators voneinander nicht unterscheidbar [LLV07, S. 106].
ID
Name
PLZ
Alter
Geschlecht
1
4
2
3
Bonität
Julia
Sandra
Stefanie
Nicole
127**
127**
127**
127**
3*
3*
3*
3*
weiblich
weiblich
weiblich
weiblich
gut
mittel
mittel
gut
5
6
7
8
Michael
Peter
Thomas
Hans
124**
124**
124**
124**
≥ 40
≥ 40
≥ 40
≥ 40
männlich
männlich
männlich
männlich
schlecht
gut
mittel
mittel
9
10
11
12
Laura
Sarah
Lisa
Anna
127**
127**
127**
127**
2*
2*
2*
2*
weiblich
weiblich
weiblich
weiblich
schlecht
schlecht
schlecht
schlecht
Tabelle 2: Anonymisierung von Tabelle 1, die 4-Anonymity genügt
10
2.3. Anonymisierungskonzepte
Tabelle 2 stellt eine mögliche Anonymisierung von Tabelle 1 dar, die 4-Anonymity
genügt. Die Attribute ID und Name bilden den Schlüssel. Der Quasi-Identifikator ist
QIT = {PLZ, Alter, Geschlecht}. Als sensibles Attribut wird Bonität festgelegt.
Die Tupel in der Tabelle sind in drei Äquivalenzklasen mit jeweils vier Tupeln
aufgeteilt. Die erste Äquivalenzklasse enthält die Tupel mit t [ID] = {1, 2, 3, 4}. Für diese
Tupel gilt t [QIT ] = {127 ∗ ∗, 3∗, weiblich}. Weitere Äquivalenzklassen sind t [ID] =
{5, 6, 7, 8} und t [ID] = {9, 10, 11, 12}.
k-Anonymity sichert, dass bei einem Linking von dem Quasi-Identifikator mit Attributen aus anderen veröffentlichten Mikrodaten mindestens k Tupel übereinstimmen
[Swe02b, S. 9]. Diese Eingenschaft garantiert, dass ein Tupel nicht eindeutig zu einem Induviduum zugeordnet werden kann [Swe02b, S. 10]. Die Verletzung der obigen
Eigenschaft wird Identity Disclosure genannt [Lam93, S. 315].
Machanavajjhala et al. haben gezeigt, dass Angriffe auf k-anonyme Tabellen existieren [MGKV06, S. 2]. Dabei werden die Werte von den sensiblen Attributen mit
Individuen assoziiert ohne die dazugehörigen Tupel in der k-anonymen Tabelle eindeutig
identifizieren zu müssen [MGKV06, S. 2]. Diese Art von Informationspreisgabe wird
Attribute Disclosure genannt [Lam93, S. 315].
`-Diversity
Nach Machanavajjhala, et al. [MGKV06, S. 7] wird `-Diversity wie folgt definiert:
Definition 9 (`-Diversity) Sei T (A1 , . . . , An ) eine Tabelle und sei s ∈ SAT ein
sensibles Attribut von T . Eine Äquivalenzklasse E ∈ T genügt der `-Diversity genau
dann, wenn sie mindestens ` „wohlunterschiedliche“ Werte für s enthält. T genügt
genau dann der `-Diversity, wenn jede Äquivalenzklasse `-divers ist.
Mit `-Diversity wird versucht, Attibute Disclosure zu beschränken [LLV07, S. 108].
Es existieren mehrere Definitionen für den Begriff „wohlunterschiedliche“ Werte. Diese
Definitionen werden Instanziierungen genannt.
Eine naive Instanziierung von `-Diversity ist die Distinct `-Diversity. Eine Äquivalenzklasse E genügt der Distinct `-Diversity, wenn das sensible Attribut s mindestens
` ≥ 2 unterschiedliche Werte enthält [LLV07, S. 108] Eine strengere Instanziierung der
`-Diversity ist die Entropy `-Diversity [MGKV06, S. 7]:
Definition 10 (Entropy `-Diversity) Sei T (A1 , . . . , An ) eine Tabelle mit Attributen A1 , . . . , An . Sei weiterhin s ∈ SAT ein sensibles Attribut von T mit Attributwerten
s1 , . . . , sk . T genügt der Entropy `-Divesity genau dann, wenn für jede Äquivalenzklasse
E ∈ T gilt
−
X
p(E, s) log2 p(E, s) ≥ log2 (`)
s∈S
Dabei ist p(E, s) = P
n(E,s)
n(E,s0 )
der Anteil von Tupeln in E mit Attributwerten, die
s0 ∈S
gleich s sind.
11
2. Grundlagen
ID
Name
PLZ
Alter
Geschlecht
Bonität
1
4
9
10
Julia
Sandra
Laura
Sarah
1274*
1274*
1274*
1274*
*
*
*
*
weiblich
weiblich
weiblich
weiblich
gut
mittel
schlecht
schlecht
5
6
7
8
Michael
Peter
Thomas
Hans
1248*
1248*
1248*
1248*
*
*
*
*
männlich
männlich
männlich
männlich
schlecht
gut
mittel
mittel
2
3
11
12
Stefanie
Nicole
Lisa
Anna
1273*
1273*
1273*
1273*
*
*
*
*
weiblich
weiblich
weiblich
weiblich
mittel
gut
schlecht
schlecht
Tabelle 3: Anonymisierung von Tabelle 1, die 3-Diversity genügt
Tabelle 3 stellt eine Anonymisierung von Tabelle 1 dar, die Distinct 3-Diversity
genügt. Jede Äquivalenzklasse in der Tabelle enthält drei unterschiedliche Werte für
das sensible Attribut Bonität.
Seien E1 , E2 und E3 die drei Äquivalenzklassen in Tabelle 3. Es gilt dann unter
Berücksichtigung des Attributs ID E1 = {1, 4, 9, 10}, E2 = {5, 6, 7, 8} und E3 =
{2, 3, 11, 12}. Die Entropie von E1 wird wie folgt berechnet:
−
X
p (E1 , s) log2 p(E1 , s) = − 1 · (p (E1 , gut) log2 p (E1 , gut)
s∈S
+ p (E1 , schlecht) log2 p (E1 , schlecht)
+ p (E1 , mittel) log2 p (E1 , mittel))
1
1
1
1
1
1
=−1·
· log2
+ · log2
+ · log2
4
4
2
2
4
4
= 1, 5
Es gilt weiterhin, dass
−
X
p(E2 , s) log2 p(E2 , s) = 1.5
s∈S
−
X
p(E3 , s) log2 p(E3 , s) = 1.5
s∈S
Für die Äquivalenzklasse E1 gilt dann log2 (`) ≤ 1, 5 ⇔ ` ≤ 21,5 = 2, 828. Tabelle 3
ist Entropy 2, 828-divers, da die Entropie von E1 ist gleich die von E2 und E3 .
12
2.4. Datenbankprogrammierung
2.4. Datenbankprogrammierung
Structured Query Language (SQL) ist eine Sprache zur Definition und Verarbeitung von
Daten in relationalen Datenbanken [IBM14a, S. 1]. SQL wurde Anfang der 70er-Jahren
als SEQUEL von Donald D. Chamberlin und Raymond F. Boyce bei IBM entwickelt
[CB74]. SQL ist die meist implementierte Datenbanksprache [Ull94, S. 210]. Die SQL
Implementierung in DB2 wird in [IBM14a] und [IBM14b] beschrieben.
SQL Procedural Language (SQL PL) wurde in DB2 implementiert und ist eine
Teilmenge von dem SQL Persistent Stored Modules (SQL/PSM) Standard3 [YBC+ 03].
SQL PL erweitert SQL mit Anweisungen und Sprachelementen, die es erlauben, SQL
mit Konzepten aus der prozeduralen Programmierung zu erweitern [IBM14a, S. 16].
SQL PL enthält Klauseln zur Definition und Initialisierung von Variablen – DECLARE
und SET, sowie Kontrollstrukturen – IF, CASE, GOTO, ITERATE, LEAVE, RETURN und
Schleifen – WHILE, FOR und LOOP [IBM13, S. 20]. Eine Einführung in SQL PL bietet
[YBC+ 03].
Routinen sind Datenbankobjekte, die die Ausführung von komplexer Logik auf
Daten im Kontext einer Datenbank ermöglichen [IBM13, S. 3]. Routinen können das
Leistungsverhalten von Programmen verbessern, indem sie die Daten lokal verarbeiten
und die Kommunikation zwischen Programm und DBMS reduzieren [IBM13, S. 3].
Routinen sind eng mit der Datenbank verknüpft, was eine schnelle Ausführung erlaubt
[IBM06, S. 53]. Die Benutzung von Routinen kann die Entwicklung von Programmen
erleichtern, indem eine einheitliche Schnittstelle zu den Daten im Datenbanksystem
bereitgestellt wird [IBM06, S. 6].
Routinen in DB2 haben die Form von Prozeduren, Funktionen oder Methoden. In
[IBM13, S. 16–18] wird ein ausführlicher Vergleich der drei Typen von Routinen angeboten. SQL wird mit Funktionen erweitert. Sie können innerhalb von SQL-Anweisungen
aufgerufen werden [IBM14a, S. 213].
Methoden ermöglichen den Zugriff auf Attributwerte von strukturierten Typen. Ein
strukturierter Typ ist ein benutzerdefinierter Datentyp, der Attribute mit einem Namen
und einem Datentyp enthält [IBM14a, S. 228]. Eine geometrische Figur als strukturierter
Typ kann z.B. Attibute für ihre kartesische Koordinaten haben. Eine Methode für
diese geometrische Figur kann die Berechnung von ihrer Fläche sein [IBM06, S. 20].
Prozeduren sind Datenbankobjekte, die Logik und SQL einkapseln [YBC+ 03]. Sie
haben Ein- und Ausgabeparameter und können sowohl verschachtelt als auch rekursiv
aufgerufen werden. Prozeduren können mehrere Ausgaben zurückgeben [IBM06, S. 15].
Bei der Implementierung von Prozeduren wird zwischen SQL Prozeduren und externe
Prozeduren unterschieden [IBM13, S. 7]. Abbilding 3 stellt ein Teil der Klassifikation der
Routinen in DB2 dar [IBM13, S. 5]. SQL Prozeduren können in SQL oder SQL PL implementiert werden. Externe Prozeduren können in verschiedenen Programmiersprachen,
wie z.B. Java, C oder C++, geschrieben werden [IBM13, S. 21].
Abbilding 4 ist ein Beispiel für eine SQL Prozedur, die die Anzahl von unterschiedlichen Attributwerten in der Domäne eines Attributs bestimmt. Prozeduren in DB2
3
DB2 implementiert den Standard ANSI/ISO/IEC 9075-4:2003 Information technology – Database
languages – SQL – Part 4: Persistent Stored Modules (SQL/PSM) [IBM14a, S. xx]
13
2. Grundlagen
SQL Prozeduren
Prozeduren
Externe
Prozeduren
Routinen
Funktionen
Methoden
Abbildung 3: Art der Implementierung von Routinen in DB2
haben Ein- und Ausgabeparameter. Ausgabeparameter werden mit OUT gekennzeichnet.
Mit der SPECIFIC-Anweisung wird der Prozedur einen eindeutigen Namen zugeordnet.
Prozeduren können nur mit der CALL-Klausel aufgerufen werden. Die Anweisung
CALL get_domain_size(’PLZ’, ds) wird benutzt, um die Prozedur aufzurufen. Das
erste Parameter ist der Name des Attributs. Das zweite Parameter – ds, wird nach
dem Prozeduraufruf den gesuchten Wert enthalten.
Module in DB2 sind Erweiterungen des Namensraumes für bestimmte Datenbankobjekte [RS12]. Module können Funktionen, Prozeduren, benutzerdefinierte Typen sowie
globale Variablen enthalten [IBM13, S. 20]. In DB2 werden Module benutzt, um Programmbibliotheken zu modellieren. Datenbankobjekte können in Modulen hinzugefügt
und publiziert werden. Hinzugefügte Objekte sind nur im Modul sichtbar. Publizierte
Objekte können durch andere Module oder Anfragen referenziert werden. Die Teilung
von Deklaration und Implementation vereinfacht das Erstellen von rekursiven Routinen
[RS12].
14
2.4. Datenbankprogrammierung
1
--#SET TERMINATOR @
2
3
4
5
6
7
8
9
10
11
12
CREATE OR REPLACE PROCEDURE get_domain_size (
attr VARCHAR(32),
OUT domain_size INTEGER
)
SPECIFIC get_domain_size
LANGUAGE SQL
BEGIN
DECLARE dyn_sql VARCHAR(1024);
DECLARE domain_size_stmt STATEMENT;
DECLARE domain_size_cursor CURSOR FOR domain_size_stmt;
13
14
SET dyn_sql = ’SELECT COUNT(DISTINCT ’ || attr || ’) FROM freq’;
15
16
PREPARE domain_size_stmt FROM dyn_sql;
17
18
19
20
21
OPEN domain_size_cursor;
FETCH domain_size_cursor INTO domain_size;
CLOSE domain_size_cursor;
END @
Abbildung 4: Beispiel einer Prozedur, die die Anzahl von unterschiedlichen Attributwerten in der Domäne eines Attributs bestimmt
15
16
3. Anonymisierungsalgorithmen
Im vorherigen Kapitel wurden die Konzepte und Methoden eingeführt, die eine zentrale
Rolle bei der Anonymisierung von Daten spielen. In diesem Kapitel werden drei
Algorithmen, die im Zuge der Arbeit implementiert wurden, anhand von Pseudocode
erläutert.
3.1. Datafly
Datafly ist einer der ersten heuristischen Algorithmen, der sowohl Generalisierung als
auch Unterdrückung zur Erstellung von k-anonymen Mikrodaten benutzt [BA05, S. 218].
Algorithmus 1 stellt eine Übersicht des Algorithmus in Pseudocode dar [Swe02a, S. 13].
Die Laufzeit von Datafly ist O |QIT | · |T |2 unter der Annahme, dass in den meisten
P|QI |
Datenbanken |QIT | |T | und i=1T |DGHAi |T | gilt [Swe01, S. 122].
Als Eingaben bekommt Datafly Mikrodaten in der Form einer Tabelle T . Dazu wird
ein Wert k angegeben. Nach Beenden des Algorithmus muss die anonymisierte Tabelle
Tk , für den gegebenen Wert k, k-Anonymity bezüglich der Attribute Ai ∈ QIT genügen.
Um k-Anonymity zu erreichen wird eine Liste QIT mit Attributen angegeben, die den
Quasi-Identifikator aufbauen. Für jedes Attribut Ai ∈ QIT erhält Datafly auch seine
Value-Generalization-Hierarchy V GHAi .
Algorithmus 1 Datafly
Eingabe: T, QIT , k, V GHAi für jedes Ai ∈ QIT
Ausgabe: k-anonyme Tabelle Tk
1 freq ← Liste jeder Sequenz von quasi-identifizierenden Attributwerten und deren
absoluten Häufigkeiten in T
2 while es existieren Sequenzen in freq, die weniger als k Mal auftreten und mehr
als k Tupel ausmachen do
3
Aj ← wähle Attribut aus freq mit den meisten verschiedenen Werten
4
freq ← generalisiere die Werte von Aj in freq
5 end while
6 freq ← unterdrücke Sequenzen in freq, die weniger als k Mal auftreten
7 freq ← stelle k für die unterdrückten Sequenzen in freq sicher
8 return erstelle Tabelle Tk aus freq
Datafly benutzt eine Tabelle mit dem Namen freq, die jede Sequenz von quasiidentifizierenden Attributwerten und deren absoluten Häufigkeiten in T enthält. Jede
Sequenz in freq repräsentiert einen oder mehrere Tupel in T mit den gleichen Attributwerten und bildet eine Äquivalenzklasse. Die Konstruktion von freq erfolgt in Zeile 1.
Datafly arbeitet solange Sequenzen in freq existieren, die weniger als k Mal auftreten.
Weiterhin wird geprüft, ob die Anzahl von Tupeln, die nicht k-anonymen Äquivalenzklassen angehören, größer als k ist. Zeile 3 stellt die benutzte Heuristik dar. Es wird das
Attribut mit der größten Anzahl von unterschiedlichen Attributwerten ausgewählt. Die
Generalisierung des Attributs erfolgt entsprechend der Full-Domain Generalisierung.
17
3. Anonymisierungsalgorithmen
Wird die Abbruchbedingung aus Zeile 2 erfüllt, dann werden die Sequenzen, die weniger
als k Mal auftreten, unterdrückt. Das Ergebnis der Anonymisierung ist eine Tabelle Tk ,
die bezüglich der Attribute in QIT k-Anonymity genügt.
PLZ
Alter
Geschlecht
#
ID
12741
12734
12734
12741
12486
12486
12482
12482
12741
12741
12734
12734
31
36
35
37
60
65
57
59
21
23
21
29
weiblich
weiblich
weiblich
weiblich
männlich
männlich
männlich
männlich
weiblich
weiblich
weiblich
weiblich
1
1
1
1
1
1
1
1
1
1
1
1
1
2
3
4
5
6
7
8
9
10
11
12
4
11
2
(a) Erstellung von freq
PLZ
Alter
Geschlecht
#
ID
12741
12734
12486
12482
12741
12734
3*
3*
≥ 40
≥ 40
2*
2*
weiblich
weiblich
männlich
männlich
weiblich
weiblich
2
2
2
2
2
2
1, 4
2, 3
5, 6
7, 8
9, 10
11, 12
4
3
2
(b) freq nach Generalisierung von Alter
PLZ
Alter
Geschlecht
#
ID
1274*
1273*
1248*
1274*
1273*
3*
3*
≥ 40
2*
2*
weiblich
weiblich
männlich
weiblich
weiblich
2
2
4
2
2
1, 4
2, 3
5, 6, 7, 8
9, 10
11, 12
3
3
2
(c) freq nach Generalisierung von PLZ
PLZ
Alter
Geschlecht
#
ID
1274*
1273*
1248*
*
*
*
weiblich
weiblich
männlich
4
4
4
1, 4, 9, 10
2, 3, 11, 12
5, 6, 7, 8
3
1
2
(d) freq nach Generalisierung von Alter
Tabelle 4: Ablauf der Generalisierungen in Datafly
Seien T = Tabelle 1, k = 4 sowie QIT = {PLZ, Alter, Geschlecht} und deren
zugehörigen VGHs aus Abbildungen 1b, 1c und 1d gegeben.
In Tabelle 4 wird der Ablauf der Generalisierungen in Datafly dargestellt. Jedes
Tupel in T bildet seine eigene Äquivalenzklasse. Im ersten Generalisierungsschritt
(Tabelle 4a) wird das Attribut Alter ausgewählt. Das Ergebnis dieser und der weiteren
Generalisierungen ist in Tabellen 4b–4d dargestellt. Tabelle 5 stellt das Ergebnis von
Datafly dar, eine Anonymisierung von Tabelle 1, die 4-Anonymity genügt.
Nach Zeile 3 in Algorithmus 1 ist es möglich eines von den beiden Attributen Alter
oder PLZ in Tabelle 4c auszuwählen. In Datafly wird diese Auswahl nicht spezifiziert,
weshalb es möglich ist eine zweite 4-anonyme Tabelle zu bekommen. Diese wird in
Tabelle 2 dargestellt.
Tabelle 5 ist das Ergebnis der Anonymisierung von Datafly. Die Tabelle ist 4-anonym
bezüglich der Attribute PLZ, Alter und Geschlecht und enthält 3 Äquivalenzklassen.
18
3.2. Incognito
ID
Name
PLZ
Alter
Geschlecht
Bonität
1
4
9
10
Julia
Sandra
Laura
Sarah
1274*
1274*
1274*
1274*
*
*
*
*
weiblich
weiblich
weiblich
weiblich
gut
mittel
schlecht
schlecht
5
6
7
8
Michael
Peter
Thomas
Hans
1248*
1248*
1248*
1248*
*
*
*
*
männlich
männlich
männlich
männlich
schlecht
gut
mittel
mittel
2
3
11
12
Stefanie
Nicole
Lisa
Anna
1273*
1273*
1273*
1273*
*
*
*
*
weiblich
weiblich
weiblich
weiblich
mittel
gut
schlecht
schlecht
Tabelle 5: Anonymisierung von Tabelle 1 mit Datafly
3.2. Incognito
Zwei Eigenschaften spielen eine zentralle Rolle in Incognito – die Monotonie- und die
Subset-Eigenschaft [LDR05, S. 52].
Definition 11 (Monotonie-Eigenschaft) Sei T (A1 , . . . , An ) eine Tabelle und seien
weiterhin P und Q zwei Mengen von Attributen aus {A1 , . . . , An }, so dass die Domänen
der Attribute von Q Generalisierungen der Domänen der Attribute von P sind. Nach
der Monotonie-Eigenschaft ist T genau dann k-anonym bezüglich der Attribute aus P ,
wenn T k-anonym bezüglich der Attribute aus Q ist [LDR05, S 52].
Wenn Tabelle 1 2-anonym in Bezug auf hP0 i ist, dann ist T auch 2-anonym bezüglich
hP1 i, wobei P1 eine Generalisierung von P0 ist.
Definition 12 (Subset-Eigenschaft) Sei die Tabelle T k-anonym bezüglich einer
Menge von Attributen Q. Nach der Subset-Eigenschaft ist T auch bezüglich jeder
Teilmenge von Q k-anonym.
Wenn Tabelle 1 2-anonym bezüglich hP0 , A1 i ist, dann muss die Tabelle auch bezüglich hP0 i und hA1 i 2-anonym sein. Eine weitere Eigenschaft, die Rollup-Eigenschaft
beschreibt weiterhin, wie das frequencySet von T bezüglich Q mit Hilfe von P generiert
werden kann [LDR05, S. 53].
Incognito erzeugt die Menge von allen möglichen Full-Domain Generalisierungen
einer Tabelle T [LDR05, S. 53]. Der Algorithmus beginnt mit allen einelementigen
Teilmengen des Quasi-Identifikators QIT = {Ai , . . . , Aj } und überprüft, ob T in Bezug
auf die jeweilige Teilmenge k-Anonymity genügt. In den nachfolgenden Iterationen
werden die Teilmengen jeweils um ein Attribut vergrößert. Jede Iteration von Incognito
besteht aus zwei Teilen:
19
3. Anonymisierungsalgorithmen
1. In jeder Iteration i wird ein Graph von Multi-Attribut-Generalisierungen erzeugt.
Jede Multi-Attribut-Generalisierung ist Element der Teilmenge mit Größe i von
QIT . Die Menge von Knoten wird mit Ci bezeichnet, die Menge von Kanten
mit Ei . Eine modifizierte Breitensuche erzeugt die Menge Si von Multi-AttributGeneralisierungen, für die T k-anonym ist.
2. Der Algorithmus benutzt die Subset-Eigenschaft um die Menge von Knoten Ci+1
der Größe i + 1, aus Si zu erzeugen. Dabei wird die Menge von Kanten Ei+1
erstellt.
Die Komplexität
des
Algorithmus ist exponentiell in Bezug auf die Größe von QIT
|QI
|
T
und liegt in O 2
[LDR05, S. 56]. Incognito wird im Pseudocode nach [LDR05,
S. 55] dargestellt.
Breitensuche
Die i-te Iteration von Incognito durchsucht Ci um zu prüfen, ob T in Bezug auf die
Multi-Attribut-Generalisierungen in Ci k-anonym ist. Das erfolgt durch eine modifizierte
Bottom-Up-Breitensuche [LDR05, S. 53]. Die Suche beginnt mit den Knoten, die keine
eingehende Kanten haben.
hA2 , G1 i
hA2 , G1 i
hA2 , G1 i
hA2 , G0 i
hA1 , G1 i
hA2 , G0 i
hA1 , G1 i
hA2 , G0 i
hA1 , G1 i
hA1 , G0 i
hA0 , G1 i
hA1 , G0 i
hA0 , G1 i
hA1 , G0 i
hA0 , G1 i
hA0 , G0 i
hA0 , G0 i
hA0 , G0 i
Abbildung 5: Durchsuchen der Gitter für die Attribute Alter und Geschlecht
Sei T die Tabelle 1 und sei QIT = {PLZ, Alter, Geschlecht}. Die erste Iteration
des Incognito-Algorithmus stellt fest, dass T k-anonym in Bezug auf hP0 i, hA0 i und
hG0 i ist. P0 , A0 und G0 bezeichnen die Domänen der Attribute PLZ, Alter und
Geschlecht, die die originalen Attributwerte enthalten. Die zweite Iteration führt
dann drei Breitensuchen aus, um zu prüfen, ob T k-anonym in Bezug auf {PLZ, Alter},
{Alter, Geschlecht} und {PLZ, Geschlecht} ist.
Abbildung 5 zeigt den Ablauf der Breitensuche für {Alter, Geschlecht}. Incognito
generiert frequencySet von T in Bezug auf hA0 , G0 i und stellt fest, dass T nicht 4anonym ist. Der Algorithmus benutzt die Rollup-Eigenschaft und generiert frequencySet
von T in Bezug auf hA0 , G1 i und hA1 , G0 i, indem das frequencySet von hA0 , G0 i benutzt
wird [LDR05, S. 53]. T ist 4-anonym in Bezug auf hA1 , G0 i und deshalb auch 4-anonym
in Bezug auf hA2 , G0 i und hA2 , G1 i. T ist nicht 4-anonym in Bezug auf hA0 , G1 i,
20
3.2. Incognito
Algorithmus 2 Incognito
Eingabe: T, QIT , k und Dimensionstabellen für jedes Ai ∈ QIT
Ausgabe: k-anonyme Tabelle Tk
1 C1 ← {Knoten in den DGHAi für jedes Ai ∈ QIT }
2 E1 ← {Kanten in den DGHAi für jedes Ai ∈ QIT }
3 queue ← leere Warteschlange
4 for i ← 1 to n do
5
// Ci und Ei definieren den Graph der Generalisierungen
6
Si ← Kopie von Ci
7
{roots} ← {alle Knoten c ∈ Ci ohne eingehende Kanten e ∈ Ei }
8
queue ← {roots}, nach Höhe im Graph der Generalisierungen sortiert
9
while queue ist nicht leer do
10
node ← erstes Element aus queue
11
if node ist nicht markiert then
12
if node ist ein Root-Knoten then
13
frequencySet ← Liste von Sequenzen und deren absoluten Häufigkeiten in
T in Bezug auf die Attribute von node
14
else
15
frequencySet ← Liste von Sequenzen und deren absoluten Häufigkeiten in
T in Bezug auf die Attribute von node unter Benutzung des frequencySets
von einem Eltern von node
16
end if
17
Benutze frequencySet um zu prüfen, ob T in Bezug auf die Attribute von
node k-Anonymity genügt
18
if T ist k-anonym then
19
markiere alle direkten Generalisierungen von node
20
else
21
node aus Si löschen
22
queue ← direkte Generalisierungen von node, nach Höhe im Graph der
Generalisierungen sortiert
23
end if
24
end if
25
end while
26
Ci+1 , Ei+1 ← GraphGeneration(Si , Ei )
27 end for
28 return Projektion der Attribute von Sn auf T und den Dimensionstabellen
21
3. Anonymisierungsalgorithmen
deshalb muss geprüft werden, ob T 4-anonym in Bezug auf hA1 , G1 i ist. Da T für diese
Multi-Attribut-Generalisierung 4-anonym ist, wird die Breitensuche beendet.
Graph der Generalisierungen
ID
dim1
index1
dim2
index2
1
2
3
4
5
6
Alter
Alter
Alter
Alter
Alter
Alter
0
0
1
1
2
2
Geschlecht
Geschlecht
Geschlecht
Geschlecht
Geschlecht
Geschlecht
0
1
0
1
0
1
(a) Knoten
Anfang
Ende
1
1
2
3
3
4
5
2
3
4
4
5
6
6
(b) Kanten
Tabelle 6: Darstellung des Gitters für die Attribute Alter und Geschlecht im Abbilding 2a als Tabellen
.
Jeder Graph der Generalisierungen wird als zwei Tabellen Ci und Ei implementiert.
Jeder Knoten in Ci hat einen eindeutigen Schlüssel ID. In Abbildung 6 wird die
tabellarische Repräsentation vom Gitter in Abbildung 2a dargestellt.
Die Generierung des Graphen (Zeile 26 in Algorithmus 2) erfolgt in drei Schritten:
Join-, Reduktions- und Kantengenerierungsschritt [LDR05, S. 54]. Die Join- und Reduktionsschritte werden benutzt, um die Menge Ci zu erstellen. Danach wird Ei im
Kantengenerierungsschritt erzeugt.
Der Join-Schritt erstellt eine Obermenge von Ci auf die Basis von Si [LDR05, S. 54].
Die Menge Ci kann auch Knoten enthalten, deren Untermengen nicht in Si−1 enthalten
sind [LDR05, S. 54]. Diese Knoten werden bei dem Reduktionsschritt entfernt. Algorithmus 3 stellt den Reduktionsschritt bei der Generierung des Graphen in Pseudocode
nach Agrawal et al. [AS94, S. 491] dar.
Algorithmus 3 Reduktionsschritt von GraphGeneration in Incognito
Eingabe: Mengen von Knoten Ci und Si−1
Ausgabe: minimale Menge Ci
1 for all c ∈ Ci do
2
for all (i − 1)-Teilmengen s von c do
3
if s 6∈ Si−1 then
4
c aus Ci löschen
Der Kantengenerierungsschritt aus [LDR05, S. 54] wird im Algorithmus 4 dargestellt.
Ei wird dabei auf die Basis von Ci und Ei−1 erzeugt.
22
3.2. Incognito
Algorithmus 4 Kantengenerierungsschritt von GraphGeneration in Incognito
Eingabe: Mengen von Knoten Ci und Kanten Ei−1
Ausgabe: Menge von Knoten Ei
1 INSERT INTO Ei (start, end)
2 WITH CandidateEdges (start, end) AS (
3
SELECT p.ID, q.ID
4
FROM Ci p, Ci q, Ei−1 e, Ei−1 f
5
WHERE (e.start = p.parent1 ∧ e.end = q.parent1
6
∧ f.start = p.parent2 ∧ f.end = q.parent2
7
∨ (e.start = p.parent1 ∧ e.end = q.parent1
8
∧ p.parent2 = q.parent2 )
9
∨ (e.start = p.parent2 ∧ e.end = q.parent2
10
∧ p.parent1 = q.parent1 )
11 )
12 SELECT D.start, D.end
13 FROM CandidateEdges D
14 EXCEPT
15 SELECT D1 .start, D2 .end
16 FROM CandidateEdges D1 , CandidateEdges D2
17 WHERE D1 .end = D2 .start
Algorithmus 5 Optimierter Kantengenerierungsschritt von GraphGeneration in Incognito
1 INSERT INTO Ei (start, end)
2 WITH CandidateEdges (start, end) AS (
3
SELECT p.ID, q.ID
4
FROM Ci p, Ci q, Ei−1 e, Ei−1 f
5
WHERE e.start = p.parent1 ∧ e.end = q.parent1
6
∧ f.start = p.parent2 ∧ f.end = q.parent2
7
UNION ALL
8
SELECT p.ID, q.ID
9
FROM Ci p, Ci q, Ei−1 e, Ei−1 f
10
WHERE e.start = p.parent1 ∧ e.end = q.parent1
11
∧ p.parent2 = q.parent2
12
UNION ALL
13
SELECT p.ID, q.ID
14
FROM Ci p, Ci q, Ei−1 e, Ei−1 f
15
WHERE e.start = p.parent2 ∧ e.end = q.parent2
16
∧ p.parent1 = q.parent1
17 )
18 SELECT D.start, D.end
19 FROM CandidateEdges D
20 ...
23
3. Anonymisierungsalgorithmen
Bei der Implementierung wurde auf die komplexe WHERE-Klausel (Zeilen 5 bis 10)
aus Algorithmus 4 verzichtet. In Algorithmus 5 wird der implementierte Schritt de Kantengenerierung dargestellt. Diese Anweisung ist semantisch identisch zu Algorithmus 4,
jedoch von DB2 schneller zu verarbeiten.
Die Äquivalenz der SQL-Anweisungen, die die temporäre Tabelle CandidateEdges in
den Algorithmen 4 und 5 erstellen, wird anhand einer vereinfachten SQL-Anweisung
angezeigt. Seien R und S zwei Relationen und seien b1 , b2 und b3 drei Join-Bedingungen.
Die folgenden Ausdrücken sind in der relationalen Algebra [KE13, S. 88] äquivalent:
R ./b1 ∨b2 ∨b3 S ≡ σb1 ∨b2 ∨b3 (R × S)
≡ σb1 (R ./ S) ∪ σb2 (R ./ S) ∪ σb3 (R ./ S)
Die Laufzeit von diesem Schritt wurde um das Fünfzigfache verkürzt. In Kapitel 5
wird die Laufzeit der Implementierung der Algorithmen 4 und 5 verglichen.
In Anhang A werden die in Algorithmen 4 und 5 implementierten SQL-Anweisungen
für den Kantengenerierungsschritt dargestellt. Dazu werden die von DB2 optimierten
SQL-Anweisungen, sowie deren Optimizer Plan eingeführt.
3.3. Incognito mit `-Diversity
Incognito wird als ein Framework zum Erstellen von k-anonyme Full-Domain Generalisierungen verstanden [LDR05, S. 50]. Machanavajjhala, et al. haben `-Diversity als
eine Erweiterung von Incognito (Algorithmus 2) implementiert [MGKV06, S. 9].
Algorithmus 6 `-Diversity in Incognito
16 ...
17 Benutze frequencySet um zu prüfen, ob T in Bezug auf die Attribute von node
`-Diversity genügt
18 if T ist `-divers then
19
markiere alle direkten Generalisierungen von node
20 else
21
node aus Si löschen
22
queue ← direkte Generalisierungen von node, nach Höhe im Graph der Generalisierungen sortiert
23 end if
24 ...
Algorithmus 6 zeigt die Änderungnen, die vorgenommen werden müssen, damit
Incognito `-diverse Tabellen erstellen kann. In Zeile 17 wird geprüft, ob die Tabelle T
unter Benutzung von frequencySet `-Diversity genügt.
24
4. Implementierung
In dem vorherigen Kapitel wurde die Arbeitsweise von drei Anonymisierungsalgorithmen
beschrieben. In diesem Kapitel wird die Implementierung der Algorithmen vorgestellt
und diskutiert, die im Zuge der Bachelorarbeit entstanden ist.
Viele Datenbankmanagementsysteme erlauben es, ihre Funktionalität auf verschiedenen Wegen zu erweitern. Eine dieser Möglichkeiten sind Datenbankanwendungen.
Datenbankanwendungen sind Programme, die ein Datenbanksystem als Speicher benutzen.
4.1. UTD Anonymization ToolBox
Die UTD Anonymization ToolBox 4 wurde im Jahr 2010 von dem UT Dallas Data
Security and Privacy Lab entwickelt. Ziel war es existierende Implementierungen von
Anonymisierungsalgorithmen in einem Programm zusammenzustellen [KIK10, S. 1].
Die ToolBox ist implementiert in Java als Kommandozeile-Anwendung, arbeitet auf
Linux und Windows und unterstützt sechs Algorithmen, nämlich Datafly, Mondrian
Multidimensional k-Anonymity, Incognito, Incognito mit `-Diversity und t-Closeness
und Anatomy [KIK10, S. 8].
Datenbank
Mikrodaten
Konfiguration
UTD
Anonymization
ToolBox
anonymisierte
Mikrodaten
Hierarchien
Abbildung 6: Architektur der UTD Anonymization ToolBox
Abbildung 6 stellt die Architektur der ToolBox konzeptuell dar. Für die Ein- und
Ausgabe werden Textdateien benutzt. Die Einstellungen und VGH für die Attribute
des Quasi-Identifikators werden in einer XML-Datei gespeichert [KIK10, S. 2].
Die anonymisierten Mikrodaten werden während der Bearbeitung in einer Datenbank
gespeichert. Das erlaubt die Arbeit mit möglichst großen Datenmengen [KIK10, S. 1].
Ein Nachteil ist die Tatsache, dass Programm und Datenbank als verschiedene Prozesse
4
http://cs.utdallas.edu/dspl/toolbox/
25
4. Implementierung
laufen und mittels eines Treibers kommunizieren müssen. Dabei wird die Datenbank
als Speicher benutzt.
Die ToolBox wird als ein Java Archive (jar) ausgeliefert und benutzt SQLite als
Datenbank. Zur Ausführung der ToolBox wird Java benötigt.
4.2. Implementierung der Algorithmen als Routinen
Auswahl des Datenbanksystems
Als Datenbanksystem wurde DB2 Express-C von IBM ausgewählt. DB2 ExpressC ist ein kostenloses relationales DBS, dass die Kernfunktionen des kommerzielen
Datenbanksystems DB2 for Linux, UNIX and Windows bereitstellt [CCN+ 06, S. 11].
Routinen, die unter DB2 Express-C implementiert sind, können auch under DB2 for
Linux, UNIX and Windows ausgeführt werden [CCN+ 06, S. 11].
Vergleich zwischen Java Routinen und SQL Routinen
Algorithmus
Datafly, k = 8
Datafly, k = 16
Datafly, k = 32
SQL Routine
Externe Routine (Java)
Unterschied
13.1399s
16.2529s
14.1815s
12.6772s
16.0623s
14.2080s
+3.5844%
+1.1796%
−0.1867%
Tabelle 7: Laufzeit von Datafly als SQL und Java Routine für |QIT | = 7
Datafly wurde als externe Routine in Java und als SQL Routine implementiert.
Beide Implementierungen führen die gleichen SQL-Anweisungen aus. Als Mikrodaten
wurde das Adult Data Set des UC Irvine Machine Learning Repository benutzt. Die
Mikrodaten sind in Tabelle 8 auf Seite 29 beschrieben. Der Quasi-Identifikator wurde
von sieben Attributen aufgebaut. In Tabelle 7 werden die durchschnittlichen Laufzeiten
der zwei Implementierungen für einen gegebenen Wert von k angegeben.
Bei der Java-Implementierung wurde versucht, Threads zu benutzen, um die Laufzeit
der Algorithmen zu verbessern. Dieser Ansatz wurde als nicht realisierbar eingestuft,
da externe Routinen keine neuen Threads starten können [IBM13, S. 91].
Systementwurf
Die Anonymisierungsalgorithmen wurden als Teile von einem Framework mit dem
Namen DB2 Microdata Anonymization Framework (DB2MAF) implementiert. Die
Algorithmen sind als SQL Routinen implementiert und jedem Algorithmus wird ein Modul zugeordnet. Um die Anonymisierung zu starten, wird CALL DB2MAF.anonymize()
aufgerufen. Das DB2MAF-Modul ruft die anonymize-Prozedur des entsprechenden Moduls auf. Das Framework kann erweitert werden, indem neue Module die anonymize()
Prozedur implementieren.
26
4.2. Implementierung der Algorithmen als Routinen
Datenbank
anonymisierte
Mikrodaten
Mikrodaten
Hierarchien
Konfiguration
DB2MAF
Datafly
Incognito mit
k-Anonymity
Incognito mit
`-Diversity
anonymize()
anonymize()
anonymize()
anonymize()
Abbildung 7: Architektur der Implementierung aus dieser Bachelorarbeit
Abbildung 7 stellt die Architektur der Implementierung aus dieser Arbeit dar. Für die
Konfiguration, Anonymisierung, Ein- und Ausgabe werden mehrere Tabellen benutzt.
Die Tabelle microdaten enthält die originalen Mikrodaten, anon_microdata enthält
die anonymisierten Mikrodaten. In Tabelle star_schema werden die Attribute des
Quasi-Identifikators aufgelistet. Dazu werden die aktuelle und die höchste Ebene in der
Value-Generalization-Hierarchy des Attributs angegeben. Für jedes Attribut Ai ∈ QIT
existiert eine Tabelle Ai _gen mit der dazugehörigen Value-Generalization-Hierarchy.
In der Tabelle configuration werden die Methode, k- oder `-Wert, die Attribute des
Quasi-Identifikators und das sensible Attribut angegeben.
Korrektheit
Es wird angenommen, dass Datafly, Incognito und Incognito mit `-Diversity in der
UTD Anonymization ToolBox korrekt implementiert sind. Unter dieser Annahme ist
die Implementierung der Algorithmen in DB2MAF korrekt. Bei den Experimenten aus
Kapitel 5 haben DB2MAF und die UTD Anonymization ToolBox die Attributen des
Quasi-Identifikators zu den gleichen Höhen generalisiert.
Details der Implementierung
Die Liste von Sequenzen von quasi-identifizierenden Attributwerten und deren absoluten
Häufigkeiten in einer Tabelle T wird im Modul „Datafly“ durch eine SQL-Anweisung
erstellt. Sei QIT = {A1 , A2 , A3 } der Quasi-Identifikator für T . Die Attribute A1 , A2 , A3
werden mit GROUP BY in Äquivalenzklassen zusammengefasst. Mit COUNT(*) in der
27
4. Implementierung
SELECT-Klausel wird deren absolute Häufigkeit in T ermittelt.
Im Modul „Incognito mit k-Anonymity“ wird durch eine SQL-Anweisung geprüft,
ob eine gegebene Anonymisierung Tnode , für einen Knoten node aus dem Graph der
Generalisierungen, k-Anonymity genügt. Es wird die kleinste Äquivalenzklasse in
frequencySet gesucht. Sie muss mindestens k − 1 Tupel enthalten, damit die Tabelle
k-Anonymity genügt.
Im Modul „Incognito mit `-Diversity“ wird geprüft, ob eine gegebene Anonymisierung
Tnode , für einen Knoten node aus dem Graph der Generalisierungen, `-Diversity genügt.
Diese Prüfung wurde als eine SQL-Anweisung implementiert. Es werden drei temporäre
Tabellen erstellt, die aufeinander aufbauen um die Entropie jeder Äquivalenzklasse in
Tnode zu berechnen.
Die Möglichkeit, Module in DB2 zu erstellen, wurde erst in DB2 9.7 eingeführt
[RS12]. DB2MAF wurde als ein Framework implementiert, das aus mehreren Modulen
aufgebaut ist. Die Algorithmen können auch als Prozeduren außerhalb von Modulen
implementiert werden. Dabei muss die Eindeutigkeit der Namen von den Prozeduren
und den Variablen sichergestellt werden.
28
5. Experimente
Um das Leistungsverhalten der Implementierung aus Kapitel 4 zu testen und es mit dem
Leistungsverhalten der UTD Anonymization ToolBox zu vergleichen, wurden mehrere
Experimente mit reellen Daten durchgeführt. Evaluiert wurden Datafly, Incognito mit
k-Anonymity und Incognito mit `-Diversity.
Die Experimente zeigen, dass DB2MAF eine deutlich bessere Laufzeit im Vergleich zu
der UTD Anonymization ToolBox hat. Bei Datafly ist DB2MAF für die untersuchten
Werte zwischen 75 und 150 Mal schneller, bei Incognito und Incognito mit `-Diversity zwischen 250 und 500 Mal schneller.
Alle Experimente wurden auf einer Maschine, die mit openSUSE 13.1, acht 2.7GHz
Quad-Core AMD OpteronTM Prozessoren und 64GB Arbeitsspeicher ausgestattet ist,
durchgeführt. Als Datenbanksystem wurde DB2 Express-C, Version 10.5.5 benutzt.
Diese Version von DB2 ist auf 2 Prozessoren und 16GB Arbeitsspeicher beschränkt5 . Zur
Ausführung der UTD Anonymization ToolBox wird Java benötigt. Auf der Maschine
wurde OpenJDK 7 installiert.
Als Mikrodaten wurde das Adult Data Set6 des UC Irvine Machine Learning Repository benutzt. Die Daten stammen aus einer Völkerzählung in den Vereinigten Staaten.
Einträge mit unbekannten Werten – gekennzeichnet mit „?“, wurden entfernt. Dabei
sind 45222 Einträge entstanden. Die Größe der Daten beträgt 5.5MB.
Die verwendeten Value-Generalization-Hierarchies wurden aus [FWY05] entnommen
und nach [LDR05, S. 56] strukturiert. Sieben von den Attributen wurden für den
Quasi-Identifikator benutzt. Ein weiteres Attribut wurde als sensibel gekennzeichnet.
1
2
3
4
5
6
7
8
Attribut
Größe der Domäne
Generalisierung
Höhe
Age
Sex
Race
Marital Status
Education
Native Country
Work Class
Occupation
74
2
5
7
16
41
7
14
Bereiche von 5, 10, 20 Jahren
Unterdrückung
Unterdrückung
Taxonomie
Taxonomie
Taxonomie
Taxonomie
sensibles Attribut
4
1
1
2
3
2
2
Tabelle 8: Beschreibung des Adult Data Sets
Tabelle 8 beschreibt das Adult Data Set. Neben den Attributnamen werden die
Anzahl der eindeutigen Attributwerten angegeben. Für jedes Attribut wird die Art
der Generalisierung und die Höhe der Hierarchie aufgelistet. Im Anhang B wird die
Konfigurationsdatei config.xml der UTD Anonymization ToolBox angegeben. Sie
enthält die genauen VGHs für jedes Attribut.
5
6
http://www-03.ibm.com/software/products/en/db2expressc
http://archive.ics.uci.edu/ml/datasets/Adult
29
5. Experimente
Bei den Experimenten wurde der Schwerpunkt auf Laufzeit zum Anonymisieren
der Daten gesetzt. Die UTD Anonymization ToolBox listet die Zeit zum Einlesen,
Anonymisieren und Schreiben der Daten auf der Kommandozeile auf. Davon wurde
nur die Zeit zum Anonymisieren berücksichtigt. Die Laufzeit von DB2MAF wurde mit
der in der Kommandozeile eingebauten time-Funktion gemessen.
Adult Data Set
Adult Data Set
0.3
Datafly k = 8
Incognito k = 8
Incognito ` = 4
8
Datafly k = 8
Laufzeit in Minuten
Laufzeit in Minuten
10
6
4
2
0.2
0.1
0
3
4
5
|QIT |
(a)
6
7
3
4
5
|QIT |
6
7
(b)
Abbildung 8: Performanz von DB2MAF für verschiedene Größen von QIT bei festem
k-, bzw. `-Wert
In Abbildung 8 wird die Performanz der in DB2MAF implementierten Algorithmen
für |QIT | = {3, 4, 5, 6, 7} und k = 8, bzw. ` = 4 verglichen. In Abbildung 8a scheint
die Laufzeit von Datafly in DB2MAF linear zu sein. Dass dem nicht so ist, zeigt die
genauere Darstellung der Kurve in Abbildung 8b ohne den Vergleich zu Incognito.
5.1. Datafly
Abbildung 9 vergleicht die Laufzeit der beiden Implementierungen von Datafly für
|QIT | = {3, 4, 5, 6, 7} und k = {2, 8}. Für |QIT | = 3 wurden die ersten drei Attribute
aus Tabelle 8 benutzt, danach wurde QIT um ein Attribut vergrößert.
Die Laufzeit von DB2MAF zeigt eine deutliche Verbesserung gegenüber der UTD
Anonymization ToolBox. Die Anonymisierung des Adult Data Sets für |QIT | = 7 und
k = 8 hat bei DB2MAF 17 Sekunden gedauert. Im Vergleich dazu hat sie bei der
UTD Anonymization ToolBox 22 Minuten gedauert. Insgesamt ist DB2MAF für die
untersuchten Werte zwischen 75 und 150 Mal schneller als die UTD Anonymization
ToolBox.
In Abbildung 10 wird die Laufzeit der beiden Implementierungen von Datafly für
|QIT | = 5 und k = {2, 5, 10, 25, 50} verglichen. Sowohl DB2MAF als auch die UTD
Anonymization ToolBox haben keine großen Abweichungen bei einem aufsteigenden
k-Wert gezeigt.
30
5.1. Datafly
Datafly, Adult Data Set, k = 8
UTD
DB2MAF
20
UTD
DB2MAF
20
Laufzeit in Minuten
Laufzeit in Minuten
Datafly, Adult Data Set, k = 2
15
10
5
0
15
10
5
0
3
4
5
|QIT |
6
7
3
4
5
|QIT |
6
7
Abbildung 9: Performanz von Datafly für verschiedene Größen von QIT bei festem
k-Wert
Datafly, Adult Data Set, |QIT | = 5
Laufzeit in Minuten
UTD
DB2MAF
6
4
2
0
2 5 10
25
k
50
Abbildung 10: Performanz von Datafly bei fester Größe von QIT für verschiedene
k-Werte
31
5. Experimente
5.2. Incognito
Die Laufzeit von Incognito in DB2MAF ist im Gegensatz zu den nachfolgenden Abbildungen nicht linear. Abbildung 8a stellt einen deutlichen Aufstieg der Laufzeit
dar.
k-Anonymity
Incognito, Adult Data Set, k = 8
Incognito, Adult Data Set, k = 2
UTD
DB2MAF
Laufzeit in Minuten
Laufzeit in Minuten
UTD
DB2MAF
1,000
500
1,000
500
0
0
3
4
5
|QIT |
6
7
3
4
5
|QIT |
6
7
Abbildung 11: Performanz von Incognito für verschiedene Größen von QIT bei festem
k-Wert
Abbildung 11 vergleicht die Laufzeit der beiden Implementierungen von Incognito für
|QIT | = {3, 4, 5, 6, 7} und k = {2, 8}. Für |QIT | = 3 wurden die ersten drei Attribute
aus Tabelle 8 benutzt, danach wurde QIT um ein Attribut vergrößert.
Die Laufzeit von DB2MAF zeigt eine deutliche Verbesserung gegenüber der UTD
Anonymization ToolBox. Die Anonymisierung des Adult Data Sets für |QIT | = 6 und
k = 8 hat bei DB2MAF fast 3 Minuten gedauert. Im Vergleich dazu hat sie bei der
UTD Anonymization ToolBox 1312 Minuten, fast 22 Stunden, gedauert. Insgesamt ist
DB2MAF für die untersuchten Werte zwischen 250 und 500 Mal schneller als die UTD
Anonymization ToolBox.
Die Laufzeit von der UTD Anonymization ToolBox für |QIT | = 7 wird nicht angegeben, da die ToolBox nach mehr als 24 Stunden keine Anonymisierung erreicht hatte.
Die Laufzeit von DB2MAF für |QIT | = 7 ist 9 Minuten.
In Abbildung 12 wird die Laufzeit der beiden Implementierungen von Incognito für
|QIT | = 5 und k = {2, 5, 10, 25, 50} verglichen.
Bei einem aufsteigenden k-Wert werden bei dem Reduktionsschritt von Incognito
mehr Generalisierungen c ∈ Ci entfernt. Deshalb sinkt die Laufzeit von DB2MAF. Die
Laufzeit bei |QIT | = 5 und k = 10 ist 58 Sekunden, bei k = 25 – 58 Sekunden, bei
k = 25 – 56 Sekunden und bei k = 50 – 40 Sekunden. Diese Tendenz wurde bei der
UTD Anonymization ToolBox nicht beobachtet.
32
5.2. Incognito
Incognito, Adult Data Set, |QIT | = 5
Laufzeit in Minuten
300
UTD
DB2MAF
200
100
0
2 5 10
25
k
50
Abbildung 12: Performanz von Incognito bei fester Größe von QIT für verschiedenene
k-Werte
Incognito, Adult Data Set, k = 8
Laufzeit in Minuten
DB2MAF ohne Pruning
DB2MAF mit Pruning
10
5
0
3
4
5
|QIT |
6
7
Abbildung 13: Auswirkung des Reduktionsschritts bei der Generierung des Generalisierungsgraphen in Incognito bei fester Größe von QIT für verschiedene
k-Werte mit und ohne Pruning
33
5. Experimente
In Abbildung 13 wird die Auswirkung der „a priori“-Optimierung [LDR05, S. 52]
auf die Laufzeit von Incognito für |QIT | = {3, 4, 5, 6, 7} und k = 8 dargestellt. Bei dem
Reduktionsschritt werden Generalisierungen aus Ci entfernt, die nicht k-anonym sind
[LDR05, S. 54]. Das trägt zu einer schnelleren Anonymisierung bei.
Incognito, Adult Data Set, k = 8
originale SQL-Anweisung
optimierte SQL-Anweisung
Laufzeit in Minuten
600
400
200
0
3
4
5
|QIT |
6
7
Abbildung 14: Auswirkung der Implementierung des Kantengenerierungsschritts auf
die Laufzeit von Incognito für verschiedene Größen von QIT und k = 8
In Abbildung 14 wird die Auswirkung der Implementierung des Kantengenerierungsschritts auf die Laufzeit von Incognito für |QIT | = {3, 4, 5, 6, 7} und k = 8 dargestellt.
Mit „originale SQL-Anweisung“ wird die Implementierung von Algorithmus 4 bezeichnet, „optimierte SQL-Anweisung“ bezeichnet die Implementierung von Algorithmus 5.
Die Anonymisierung mit der optimierten SQL-Anweisung bei |QIT | = 7 hat 9 Minuten gedauert und ist somit mehr als 50 Mal schneller als die 622 Minuten für die
Anonymisierung mit der originalen SQL-Anweisung.
`-Diversity
Abbildung 15 vergleicht die Laufzeit der beiden Implementierungen von Incognito für
verschiedene Größen von QIT und ` = {2, 4}. Für |QIT | = 3 wurden die ersten drei
Attribute aus Tabelle 8 benutzt, danach wurde QIT um ein Attribut vergrößert.
Die Laufzeit von DB2MAF zeigt eine deutliche Verbesserung gegenüber der UTD
Anonymization ToolBox. Die Anonymisierung des Adult Data Sets für |QIT | = 6 und
k = 8 hat bei DB2MAF fast 4 Minuten gedauert. Im Vergleich dazu hat sie bei der
UTD Anonymization ToolBox 1295 Minuten, mehr als 21 Stunden, gedauert. Insgesamt
ist DB2MAF für die untersuchten Werte zwischen 250 und 500 Mal schneller als die
UTD Anonymization ToolBox.
Die Laufzeit von der UTD Anonymization ToolBox für |QIT | = 7 wird nicht angegeben, da die ToolBox nach mehr als 24 Stunden keine Anonymisierung erreicht hatte.
Die Laufzeit von DB2MAF für |QIT | = 7 ist 10 Minuten.
34
5.2. Incognito
Incognito, Adult Data Set, ` = 2
Incognito, Adult Data Set, ` = 4
1,500
UTD
DB2MAF
Laufzeit in Minuten
Laufzeit in Minuten
UTD
DB2MAF
1,000
500
0
1,000
500
0
3
4
5
|QIT |
6
7
3
4
5
|QIT |
6
7
Abbildung 15: Performanz von Incognito für verschiedene Größen von QIT bei festem
`-Wert
Incognito, Adult Data Set, |QIT | = 5
UTD
DB2MAF
Laufzeit in Minuten
300
200
100
0
2
3
`
4
Abbildung 16: Performanz von Incognito bei fester Größe von QIT für verschiedenene
`-Werte
35
5. Experimente
In Abbildung 16 wird die Laufzeit der beiden Implementierungen von Incognito für
|QIT | = 5 und ` = {2, 3, 4} verglichen. Bei einem aufsteigenden `-Wert werden bei dem
Reduktionsschritt von Incognito mehr Generalisierungen c ∈ Ci entfernt. Deshalb sinkt
die Laufzeit sowohl von DB2MAF als auch von der UTD Anonymization ToolBox.
Bei einem aufsteigenden k-Wert werden bei dem Reduktionsschritt von Incognito
mehr Generalisierungen c ∈ Ci entfernt. Deshalb sinkt die Laufzeit von DB2MAF und
von der UTD Anonymization ToolBox. Die Laufzeit von DB2MAF ist 100 Sekunden
für ` = 2, 80 Sekunden für ` = 3 und 65 Sekunden für ` = 4. Die Laufzeit von der UTD
Anonymization ToolBox ist 321, 315 und 306 Minuten für die entsprechende `-Werte.
36
6. Zusammenfassung und Ausblick
Die vorliegende Bachelorarbeit hat sich als Ziel gesetzt, eine Aussage darüber zu treffen,
was für eine Auswirkung die Implementierung von Algorithmen zur Anonymisierung
von Daten in einem DBMS auf deren Leistungsverhalten hat. Um dieses Ziel zu
erreichen sollten drei Algorithmen – Datafly, Incognito und Incognito mit `-Diversity –
als Routinen in einem DBMS implementiert und evaluiert werden.
Neben einer Einführung in die Methoden der Datenanonymisierung wurden in Kapitel 2 und 3 wichtige Anonymisierungsalgorithmen eingeführt. Dabei wurden prozedurale
Programmierkonzepte in einem relationalen DBMS vorgestellt. Die Implementierung
der Algorithmen wurde in Kapitel 4 eingeführt. In Kapitel 5 wurde die entstandene
Implementierung im Vergleich zur UTD Anonymization ToolBox evaluiert.
6.1. Ergebnisse
Als Ergebnis dieser Bachelorarbeit sind Implementierungen von Datafly, Incognito und
Incognito mit `-Diversity als SQL Routinen in DB2 entstanden. Jeder Algorithmus wurde als ein eigenes Modul implementiert. Die drei Module erkennen dieselben Eingabe-,
Ausgabe- und Konfigurationstabellen und wurden deshalb als ein Framework strukturiert. Das Framework trägt den Namen DB2 Microdata Anonymization Framework
(DB2MAF).
Die Implementierung der Algorithmen in DB2MAF wurde gegenüber denen der
UTD Anonymization ToolBox evaluiert. Die Laufzeit von DB2MAF zeigt eine deutliche
Verbesserung gegenüber der UTD Anonymization ToolBox. Bei Datafly ist DB2MAF für
die untersuchten Werte zwischen 75 und 150 Mal schneller und bei Incognito zwischen
250 und 500 Mal schneller.
Der Kantengenerierungsschritt von GraphGeneration in Incognito (Algorithmus 4)
wurde optimiert. Die Optimierung wird in Algorithmus 5 dargestellt. Die Laufzeit des
Kantengenerierungsschrittes in DB2 wurde um das Fünfzigfache verkürzt.
6.2. Ausblick
Nach bestem Wissen existieren bislang keine Veröffentlichungen, welche die Implementierung der Anonymisierungsalgorithmen aus Kapitel 3 als Routinen in einem DBMS
thematisieren.
Incognito wird als ein Framework verstanden [LDR05, S. 50]. Anonymisierungskonzepte, die auf Incognito basieren, können die Implementierung des Algorithmus in
DB2MAF erweitern. Ein solches Konzept ist die t-Closeness [LLV07, S. 112].
Weitere Varianten von Incognito, wie Super-roots Incognito oder Cube Incogntio
[LDR05, S. 55] können implementiert werden, damit die Laufzeit des Algorithmus
weiter verbessert wird.
In der UTD Anonymization ToolBox [KIK10, S. 7] und in DB2MAF werden die
Mikrodaten bei Incognito mit `-Diversity bezüglich nur eines sensiblen Attributs
37
6. Zusammenfassung und Ausblick
anonymisiert. Die Multi-Attribute `-Diversity Instanziierung von `-Diversity kann als
Erweiterung von Incognito in DB2MAF implementiert werden.
Sowohl Datafly als auch Incognito anonymisieren die Mikrodaten nach dem Prinzip der Full-Domain Generalisierung. Anonymisierungskonzepte, die das Prinzip der
Local Recoding benutzen, können potenter sein [LDR05, S. 59]. Bei einer Local Recoding werden nur einzelne Attributwerte von ausgewählten Tupeln modifiziert [WW01,
S. 26]. DB2MAF kann mit Algoritmen erweitert werden, die nach diesem Prinzip
Anonymisierungen erstellen.
Die Anonymisierungskonzepte, die in dieser Arbeit vorgestellt wurden, berücksichtigen
nur statische Mikrodaten. In vielen Fällen werden bestehende Mikrodaten durch
Löschen, Hinzufügen oder Modifizierung von Tupeln von einem Zeitpunkt zu einem
späteren Zeitpunkt verändert [XT07, S. 689]. Weder k-Anonymity noch `-Diversity
garantieren, dass eine frühere Anonymisierung der Mikrodaten, im Zusammenhang
mit einer späteren Anonymisierung, die Identifikation von Induviduen nicht ermöglicht
[XT07, S. 694]. Ein Konzept, dass das sicherstellt, ist die m-Invariance [XT07]. Die
Implementierung des Konzepts der m-Invariance [XT07] in DB2MAF kann das Erstellen
von anonymierten Mikrodaten bei der Änderung der Tupel automatisieren.
38
A. Optimizer Plan des Kantengenerierungsschritts in
Incognito
Anhänge A.1 und A.2 stellen die SQL-Anweisungen für den Kantengenerierungsschritt
in Incognito dar. Diese Anweisungen implementieren die Algorithmen 4 und 5.
Die Mengen C5 und E4 wurden von Incognito erstellt, wobei Incognito analog zu den
Experimenten in Kapitel 5 ausgeführt wurde, mit k = 8 und |QIT | = 7. Anhänge A.1
und A.2 erstellen E5 , wobei |C5 | = 540 und |E4 | = 915.
A.1. Originale SQL-Anweisung des Kantengenerierungsschritts in
Incognito
Im Folgenden wird ein Teil der Ausgabe von db2exfmt dargestellt. Neben der ausgeführten SQL-Anweisung wird die Optimisierung aufgelistet, die DB2 vorgenommen
hat.
Original Statement:
-----------------WITH candidateEdges(start_node, end_node) AS
(SELECT p.id, q.id
FROM c_5 AS p, c_5 AS q, e_4 AS e, e_4 AS f
WHERE
(e.start_node = p.parent_1 AND
e.end_node = q.parent_1 AND
f.start_node = p.parent_2 AND
f.end_node = q.parent_2) OR
(e.start_node = p.parent_1 AND
e.end_node = q.parent_1 AND
p.parent_2 = q.parent_2) OR
(e.start_node = p.parent_2 AND
e.end_node = q.parent_2 AND
p.parent_1 = q.parent_1)
)
SELECT d.start_node, d.end_node
FROM candidateEdges AS d
EXCEPT
(SELECT d1.start_node, d2.end_node
FROM candidateEdges d1, candidateEdges d2
WHERE d1.end_node = d2.start_node
)
Optimized Statement:
------------------SELECT
Q16.$C0 AS "START_NODE", Q16.$C1 AS "END_NODE"
FROM
(SELECT
Q15.$C0, Q15.$C1, SUM(Q15.$C2), COUNT(*)
FROM
(SELECT
Q4.ID, Q7.ID, -1
FROM
DIMITROV.E_4 AS Q1, DIMITROV.E_4 AS Q2, DIMITROV.C_5 AS Q3, DIMITROV.C_5 AS Q4,
DIMITROV.E_4 AS Q5, DIMITROV.E_4 AS Q6, DIMITROV.C_5 AS Q7, DIMITROV.C_5 AS Q8
WHERE
(Q3.ID = Q8.ID) AND
39
A. Optimizer Plan des Kantengenerierungsschritts in Incognito
((((((Q2.START_NODE = Q4.PARENT_1) AND
(Q2.END_NODE = Q3.PARENT_1)) AND
(Q1.START_NODE = Q4.PARENT_2)) AND
(Q1.END_NODE = Q3.PARENT_2)) OR
(((Q2.START_NODE = Q4.PARENT_1) AND
(Q2.END_NODE = Q3.PARENT_1)) AND
(Q4.PARENT_2 = Q3.PARENT_2))) OR
(((Q2.START_NODE = Q4.PARENT_2) AND
(Q2.END_NODE = Q3.PARENT_2)) AND
(Q4.PARENT_1 = Q3.PARENT_1))) AND
((((((Q6.START_NODE = Q8.PARENT_1) AND
(Q6.END_NODE = Q7.PARENT_1)) AND
(Q5.START_NODE = Q8.PARENT_2)) AND
(Q5.END_NODE = Q7.PARENT_2)) OR
(((Q6.START_NODE = Q8.PARENT_1) AND
(Q6.END_NODE = Q7.PARENT_1)) AND
(Q8.PARENT_2 = Q7.PARENT_2))) OR
(((Q6.START_NODE = Q8.PARENT_2) AND
(Q6.END_NODE = Q7.PARENT_2)) AND
(Q8.PARENT_1 = Q7.PARENT_1)))
UNION ALL
SELECT
Q10.ID, Q11.ID, 1
FROM
DIMITROV.C_5 AS Q10, DIMITROV.C_5 AS Q11, DIMITROV.E_4 AS Q12, DIMITROV.E_4 AS Q13
WHERE
((((((Q12.START_NODE = Q10.PARENT_1) AND
(Q12.END_NODE = Q11.PARENT_1)) AND
(Q13.START_NODE = Q10.PARENT_2)) AND
(Q13.END_NODE = Q11.PARENT_2)) OR
(((Q12.START_NODE = Q10.PARENT_1) AND
(Q12.END_NODE = Q11.PARENT_1)) AND
(Q10.PARENT_2 = Q11.PARENT_2))) OR
(((Q12.START_NODE = Q10.PARENT_2) AND
(Q12.END_NODE = Q11.PARENT_2)) AND
(Q10.PARENT_1 = Q11.PARENT_1)))
) AS Q15
GROUP BY
Q15.$C0, Q15.$C1
) AS Q16
WHERE
(Q16.$C3 = Q16.$C2)
Der Optimizer Plan für die Anweisung wurde mit db2expln erstellt.
Optimizer Plan:
Rows
Operator
(ID)
Cost
4045.73
RETURN
( 1)
9.49346e+08
|
4045.73
FILTER
( 2)
9.49346e+08
|
40
A.1. Originale SQL-Anweisung des Kantengenerierungsschritts in Incognito
101143
GRPBY
( 3)
9.49346e+08
|
101143
TBSCAN
( 4)
9.49346e+08
|
101143
SORT
( 5)
9.49346e+08
|
101143
UNION
( 6)
9.49346e+08
/--------------/
\--------------\
94018
HSJOIN
( 7)
6.32897e+08
/-----/
\-----\
7125.29
NLJOIN
(26)
3.16449e+08
/
\---\
7125.29
7125.29
2.66814e+08
*
NLJOIN
NLJOIN
NLJOIN
|
( 8)
(17)
(27)
915
3.16449e+08
3.16449e+08
96311
Table:
/
\---\
/
\---\
/
\-\
DIMITROV
2.66814e+08
*
2.66814e+08
*
291600
*
E_4
NLJOIN
|
NLJOIN
|
NLJOIN
|
( 9)
915
(18)
915
(28)
915
96311.1
Table:
96311.1
Table:
321.726
Table:
/
\-\
DIMITROV
/
\-\
DIMITROV
/
\
DIMITROV
291600
*
E_4
291600
*
E_4
540
*
E_4
NLJOIN
|
NLJOIN
|
TBSCAN
|
(10)
915
(19)
915
(29)
540
321.844
Table:
321.844
Table:
108.486 Table:
/
\
DIMITROV
/
\
DIMITROV
|
DIMITROV
540
*
E_4
540
*
E_4
540
C_5
TBSCAN
|
TBSCAN
|
Table:
(11)
540
(20)
540
DIMITROV
108.604 Table:
108.604 Table:
C_5
|
DIMITROV
|
DIMITROV
540
C_5
540
C_5
SORT
SORT
(12)
(21)
108.604
108.604
|
|
540
540
TBSCAN
TBSCAN
(13)
(22)
108.486
108.486
|
|
540
540
Table:
Table:
DIMITROV
DIMITROV
C_5
C_5
41
A. Optimizer Plan des Kantengenerierungsschritts in Incognito
A.2. Optimisierte SQL-Anweisung für den Kantengenerierungsschritt in
Incognito
Im Folgenden wird ein Teil der Ausgabe von db2exfmt dargestellt. Neben der ausgeführten SQL-Anweisung wird die Optimisierung ufgelistet, die DB2 vorgenommen
hat.
Original Statement:
-----------------WITH candidateEdges(start_node, end_node) AS
(SELECT p.id, q.id
FROM c_5 AS p, c_5 AS q, e_4 AS e, e_4 AS f
WHERE
e.start_node = p.parent_1 AND
e.end_node = q.parent_1 AND
f.start_node = p.parent_2 AND
f.end_node = q.parent_2
UNION ALL
SELECT p.id, q.id
FROM c_5 AS p, c_5 AS q, e_4 AS e, e_4 AS f
WHERE
e.start_node = p.parent_1 AND
e.end_node = q.parent_1 AND
p.parent_2 = q.parent_2
UNION ALL
SELECT p.id, q.id
FROM c_5 AS p, c_5 AS q, e_4 AS e, e_4 AS f
WHERE
e.start_node = p.parent_2 AND
e.end_node = q.parent_2 AND
p.parent_1 = q.parent_1
)
SELECT d.start_node, d.end_node
FROM candidateEdges AS d
EXCEPT
(SELECT d1.start_node, d2.end_node
FROM candidateEdges d1, candidateEdges d2
WHERE d1.end_node = d2.start_node
)
Optimized Statement:
------------------SELECT
Q16.$C0 AS "START_NODE", Q16.$C1 AS "END_NODE"
FROM
(SELECT
Q15.$C0, Q15.$C1, SUM(Q15.$C2), COUNT(*)
FROM
(SELECT
Q4.ID, Q7.ID, -1
FROM
DIMITROV.E_4 AS Q1, DIMITROV.E_4 AS Q2, DIMITROV.C_5 AS Q3, DIMITROV.C_5 AS Q4,
DIMITROV.E_4 AS Q5, DIMITROV.E_4 AS Q6, DIMITROV.C_5 AS Q7, DIMITROV.C_5 AS Q8
WHERE
(Q3.ID = Q8.ID) AND
((((((Q2.START_NODE = Q4.PARENT_1) AND
(Q2.END_NODE = Q3.PARENT_1)) AND
(Q1.START_NODE = Q4.PARENT_2)) AND
(Q1.END_NODE = Q3.PARENT_2)) OR
(((Q2.START_NODE = Q4.PARENT_1) AND
(Q2.END_NODE = Q3.PARENT_1)) AND
42
A.2. Optimisierte SQL-Anweisung für den Kantengenerierungsschritt in Incognito
(Q4.PARENT_2 = Q3.PARENT_2))) OR
(((Q2.START_NODE = Q4.PARENT_2) AND
(Q2.END_NODE = Q3.PARENT_2)) AND
(Q4.PARENT_1 = Q3.PARENT_1))) AND
((((((Q6.START_NODE = Q8.PARENT_1) AND
(Q6.END_NODE = Q7.PARENT_1)) AND
(Q5.START_NODE = Q8.PARENT_2)) AND
(Q5.END_NODE = Q7.PARENT_2)) OR
(((Q6.START_NODE = Q8.PARENT_1) AND
(Q6.END_NODE = Q7.PARENT_1)) AND
(Q8.PARENT_2 = Q7.PARENT_2))) OR
(((Q6.START_NODE = Q8.PARENT_2) AND
(Q6.END_NODE = Q7.PARENT_2)) AND
(Q8.PARENT_1 = Q7.PARENT_1)))
UNION ALL
SELECT
Q10.ID, Q11.ID, 1
FROM
DIMITROV.C_5 AS Q10, DIMITROV.C_5 AS Q11, DIMITROV.E_4 AS Q12, DIMITROV.E_4 AS Q13
WHERE
((((((Q12.START_NODE = Q10.PARENT_1) AND
(Q12.END_NODE = Q11.PARENT_1)) AND
(Q13.START_NODE = Q10.PARENT_2)) AND
(Q13.END_NODE = Q11.PARENT_2)) OR
(((Q12.START_NODE = Q10.PARENT_1) AND
(Q12.END_NODE = Q11.PARENT_1)) AND
(Q10.PARENT_2 = Q11.PARENT_2))) OR
(((Q12.START_NODE = Q10.PARENT_2) AND
(Q12.END_NODE = Q11.PARENT_2)) AND
(Q10.PARENT_1 = Q11.PARENT_1)))
) AS Q15
GROUP BY
Q15.$C0, Q15.$C1
) AS Q16
WHERE
(Q16.$C3 = Q16.$C2)
Der Optimizer Plan für die Anweisung wurde mit db2expln erstellt.
Optimizer Plan:
Rows
Operator
(ID)
Cost
1.82952
RETURN
( 1)
2520.59
|
1.82952
FILTER
( 2)
2520.59
|
45.738
GRPBY
( 3)
2520.58
|
45.738
43
A. Optimizer Plan des Kantengenerierungsschritts in Incognito
TBSCAN
( 4)
2520.57
|
45.738
SORT
( 5)
2520.57
|
45.738
UNION
( 6)
2520.55
/
33.779
HSJOIN
( 7)
1680.37
\
11.959
TBSCAN
(33)
840.184
|
11.959
Temp:
Src=9
/
\
11.959
11.959
TBSCAN
TBSCAN
( 8)
(32)
840.184 840.184
|
|
11.959
11.959
TEMP
Temp:
( 9)
Src=9
840.171
|
11.959
UNION
(10)
840.164
+---------------------------------++----------------------------------+
4.23393
4.20884
3.51624
HSJOIN
NLJOIN
NLJOIN
(11)
(18)
(25)
285.59
279.61
274.964
/
\
/
\---\
/
\---\
1111.13
915
4.20884
*
3.51624
*
HSJOIN
TBSCAN
HSJOIN
|
HSJOIN
|
(12)
(17)
(19)
915
(26)
915
251.295
34.1755
251.311
Table:
251.311
Table:
/
\
|
/
\
DIMITROV
/
\
DIMITROV
921.828
540
915
921.828
540
E_4
921.828
540
E_4
HSJOIN
TBSCAN
Table:
HSJOIN
TBSCAN
HSJOIN
TBSCAN
(13)
(16)
DIMITROV
(20)
(23)
(27)
(30)
142.734
108.486 E_4
142.734
108.486
142.734
108.486
/
\
|
/
\
|
/
\
|
915
540
540
915
540
540
915
540
540
TBSCAN
TBSCAN
Table:
TBSCAN
TBSCAN
Table:
TBSCAN
TBSCAN
Table:
(14)
(15)
DIMITROV
(21)
(22)
DIMITROV
(28)
(29)
DIMITROV
34.1755 108.486 C_5
34.1755 108.486 C_5
34.1755 108.486 C_5
|
|
|
|
|
|
915
540
915
540
915
540
Table:
Table:
Table:
Table:
Table:
Table:
DIMITROV DIMITROV
DIMITROV DIMITROV
DIMITROV DIMITROV
E_4
C_5
E_4
C_5
E_4
C_5
44
B. Konfiguration der UTD Anonymization ToolBox
Die UTD Anonymization ToolBox benutzt eine Datei mit dem Namen config.xml für
die Konfiguration und VGHs der Attribute des Quasi-Identifikators.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
<?xml version="1.0"?>
<config method=’Datafly’ k=’8’>
<input filename=’dataset/adult_no_null.data’ separator=’,’/>
<output filename=’adult_no_null_Anon.data’ format=’genVals’/>
<id></id>
<qid>
<!-- age -->
<att index=’0’ name=’age’>
<vgh value=’[0:100]’>
<node value=’[0:20]’>
<node value=’[11:20]’>
<node value=’[16:20]’/>
</node>
</node>
<node value=’[21:40]’>
<node value=’[21:30]’>
<node value=’[21:25]’/>
<node value=’[26:30]’/>
</node>
<node value=’[31:40]’>
<node value=’[31:35]’/>
<node value=’[36:40]’/>
</node>
</node>
<node value=’[41:60]’>
<node value=’[41:50]’>
<node value=’[41:45]’/>
<node value=’[46:50]’/>
</node>
<node value=’[51:60]’>
<node value=’[51:55]’/>
<node value=’[56:60]’/>
</node>
</node>
<node value=’[61:80]’>
<node value=’[61:70]’>
<node value=’[61:65]’/>
<node value=’[66:70]’/>
</node>
<node value=’[71:80]’>
<node value=’[71:75]’/>
<node value=’[76:80]’/>
</node>
</node>
<node value=’[81:100]’>
<node value=’[81:90]’>
<node value=’[81:85]’/>
<node value=’[86:90]’/>
</node>
<node value=’[91:100]’>
<node value=’[91:95]’/>
<node value=’[96:100]’/>
</node>
</node>
</vgh>
</att>
45
B. Konfiguration der UTD Anonymization ToolBox
57
<!-- sex -->
<att index=’9’ name=’sex’>
<map>
<entry cat=’Female’ int=’0’ />
<entry cat=’Male’ int=’1’ />
</map>
<!-- Any -->
<vgh value=’[0:1]’>
</vgh>
</att>
58
59
60
61
62
63
64
65
66
67
68
<!-- race -->
<att index=’8’ name=’race’>
<map>
<entry cat=’White’ int=’0’ />
<entry cat=’Asian-Pac-Islander’ int=’1’ />
<entry cat=’Amer-Indian-Eskimo’ int=’2’ />
<entry cat=’Other’ int=’3’ />
<entry cat=’Black’ int=’4’ />
</map>
<!-- Any -->
<vgh value=’[0:4]’>
</vgh>
</att>
69
70
71
72
73
74
75
76
77
78
79
80
81
82
<!-- marital_status -->
<att index=’5’ name=’marital_status’>
<map>
<entry cat=’Married-civ-spouse’ int=’0’ />
<entry cat=’Married-AF-spouse’ int=’1’ />
<entry cat=’Divorced’ int=’2’ />
<entry cat=’Separated’ int=’3’ />
<entry cat=’Widowed’ int=’4’ />
<entry cat=’Married-spouse-absent’ int=’5’ />
<entry cat=’Never-married’ int=’6’ />
</map>
<!-- Any -->
<vgh value=’[0:6]’>
<!-- Married -->
<node value=’[0:5]’ />
<!-- Never-Married -->
<node value=’[6:6]’ />
</vgh>
</att>
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
<!-- education -->
<att index=’3’ name=’education’>
<map>
<entry cat=’Preschool’ int=’0’ />
<entry cat=’1st-4th’ int=’1’ />
<entry cat=’5th-6th’ int=’2’ />
<entry cat=’7th-8th’ int=’3’ />
<entry cat=’9th’ int=’4’ />
<entry cat=’10th’ int=’5’ />
<entry cat=’11th’ int=’6’ />
<entry cat=’12th’ int=’7’ />
<entry cat=’HS-grad’ int=’8’ />
<entry cat=’Some-college’ int=’9’ />
<entry cat=’Assoc-acdm’ int=’10’ />
<entry cat=’Assoc-voc’ int=’11’ />
<entry cat=’Bachelors’ int=’12’ />
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
46
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
<entry cat=’Prof-school’ int=’13’ />
<entry cat=’Masters’ int=’14’ />
<entry cat=’Doctorate’ int=’15’ />
</map>
<!-- Any -->
<vgh value=’[0:15]’>
<!-- Without-post-secondary -->
<node value=’[0:8]’>
<!-- Preschool -->
<node value=’[0:0]’ />
<!-- Elementary -->
<node value=’[1:3]’ />
<!-- Secondary -->
<node value=’[4:8]’ />
</node>
<!-- Post-secondary -->
<node value=’[9:15]’>
<!-- Some-college -->
<node value=’[9:9]’ />
<!-- Assoc -->
<node value=’[10:11]’ />
<!-- University -->
<node value=’[12:13]’ />
<!-- Post-grad -->
<node value=’[14:15]’ />
</node>
</vgh>
</att>
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
<!-- native_country -->
<att index=’13’ name=’native_country’>
<map>
<entry cat=’United-States’ int=’0’ />
<entry cat=’Outlying-US(Guam-USVI-etc)’ int=’1’ />
<entry cat=’Canada’ int=’2’ />
<entry cat=’Mexico’ int=’3’ />
<entry cat=’Honduras’ int=’4’ />
<entry cat=’Guatemala’ int=’5’ />
<entry cat=’Nicaragua’ int=’6’ />
<entry cat=’El-Salvador’ int=’7’ />
<entry cat=’Ecuador’ int=’8’ />
<entry cat=’Peru’ int=’9’ />
<entry cat=’Columbia’ int=’10’ />
<entry cat=’Puerto-Rico’ int=’11’ />
<entry cat=’Dominican-Republic’ int=’12’ />
<entry cat=’Jamaica’ int=’13’ />
<entry cat=’Cuba’ int=’14’ />
<entry cat=’Haiti’ int=’15’ />
<entry cat=’Trinadad\&Tobago’ int=’16’ />
<entry cat=’France’ int=’17’ />
<entry cat=’England’ int=’18’ />
<entry cat=’Ireland’ int=’19’ />
<entry cat=’Scotland’ int=’20’ />
<entry cat=’Holand-Netherlands’ int=’21’ />
<entry cat=’Italy’ int=’22’ />
<entry cat=’Greece’ int=’23’ />
<entry cat=’Portugal’ int=’24’ />
<entry cat=’Yugoslavia’ int=’25’ />
<entry cat=’Hungary’ int=’26’ />
<entry cat=’Germany’ int=’27’ />
<entry cat=’Poland’ int=’28’ />
<entry cat=’Philippines’ int=’29’ />
47
B. Konfiguration der UTD Anonymization ToolBox
<entry cat=’Thailand’ int=’30’ />
<entry cat=’Cambodia’ int=’31’ />
<entry cat=’Vietnam’ int=’32’ />
<entry cat=’Laos’ int=’33’ />
<entry cat=’India’ int=’34’ />
<entry cat=’Japan’ int=’35’ />
<entry cat=’China’ int=’36’ />
<entry cat=’Hong’ int=’37’ />
<entry cat=’Taiwan’ int=’38’ />
<entry cat=’South’ int=’39’ />
<entry cat=’Iran’ int=’40’ />
</map>
<!-- Any -->
<vgh value=’[0:40]’>
<!-- North-America -->
<node value=’[0:2]’ />
<!-- Middle-America -->
<node value=’[3:7]’ />
<!-- South-America -->
<node value=’[8:16]’ />
<!-- Europe -->
<node value=’[17:28]’ />
<!-- Asia -->
<node value=’[29:40]’ />
</vgh>
</att>
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
<!-- workclass -->
<att index=’1’ name=’workclass’>
<map>
<entry cat=’Private’ int=’0’ />
<entry cat=’Self-emp-not-inc’ int=’1’ />
<entry cat=’Self-emp-inc’ int=’2’ />
<entry cat=’Federal-gov’ int=’3’ />
<entry cat=’Local-gov’ int=’4’ />
<entry cat=’State-gov’ int=’5’ />
<entry cat=’Without-pay’ int=’6’ />
</map>
<!-- Any -->
<vgh value=’[0:6]’>
<!-- Private -->
<node value=’[0:0]’ />
<!-- Self-emp -->
<node value=’[1:2]’ />
<!-- Gov -->
<node value=’[3:5]’ />
<!-- Without-pay -->
<node value=’[6:6]’ />
</vgh>
</att>
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
<!-- occupation -->
<att index=’6’ name=’occupation’>
<map>
<entry cat=’Adm-clerical’ int=’0’ />
<entry cat=’Exec-managerial’ int=’1’ />
<entry cat=’Prof-specialty’ int=’2’ />
<entry cat=’Sales’ int=’3’ />
<entry cat=’Craft-repair’ int=’4’ />
<entry cat=’Handlers-cleaners’ int=’5’ />
<entry cat=’Machine-op-inspct’ int=’6’ />
<entry cat=’Priv-house-serv’ int=’7’ />
232
233
234
235
236
237
238
239
240
241
242
48
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
<entry cat=’Tech-support’ int=’8’ />
<entry cat=’Transport-moving’ int=’9’ />
<entry cat=’Armed-Forces’ int=’10’ />
<entry cat=’Farming-fishing’ int=’11’ />
<entry cat=’Other-service’ int=’12’ />
<entry cat=’Protective-serv’ int=’13’ />
</map>
<!-- Any -->
<vgh value=’[0:13]’>
<!-- White-collar -->
<node value=’[0:3]’ />
<!-- Blue-collar -->
<node value=’[4:9]’ />
<!-- Other -->
<node value=’[10:13]’ />
</vgh>
</att>
</qid>
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
<sens>
<att index=’6’ name=’occupation’>
<map>
<entry cat=’Adm-clerical’ int=’1’ />
<entry cat=’Exec-managerial’ int=’2’ />
<entry cat=’Prof-specialty’ int=’3’ />
<entry cat=’Sales’ int=’4’ />
<entry cat=’Craft-repair’ int=’5’ />
<entry cat=’Handlers-cleaners’ int=’6’ />
<entry cat=’Machine-op-inspct’ int=’7’ />
<entry cat=’Priv-house-serv’ int=’8’ />
<entry cat=’Tech-support’ int=’9’ />
<entry cat=’Transport-moving’ int=’10’ />
<entry cat=’Armed-Forces’ int=’11’ />
<entry cat=’Farming-fishing’ int=’12’ />
<entry cat=’Other-service’ int=’13’ />
<entry cat=’Protective-serv’ int=’14’ />
</map>
</sens>
</config>
49
50
Literatur
[AFK+ 05] Ag g a rwa l, Gagan ; F e d e r, Tomas ; K e n t h a pa d i, Krishnaram
; M o t wa n i, Rajeev ; Pa n i g r a h y, Rina ; T h o m a s, Dilys ; Z h u,
An: Approximation Algorithms for k-Anonymity. In: Journal of Privacy
Technology (JOPT), 2005, S. 18
[AHV95]
A b i t e b o u l, Serge ; H u l l, Richard ; V i a n u, Victor: Foundations of
Databases. Addison-Wesley Publishing Company, 1995
[AS94]
Ag r awa l, Rakesh ; S r i k a n t, Ramakrishnan: Fast Algorithms for
Mining Association Rules in Large Databases. In: Proceedings of 20th
International Conference on Very Large Data Bases, September 12-15,
1994, Santiago de Chile, Chile, 1994, S. 487–499
[BA05]
B aya r d o, Roberto J. ; Ag r awa l, Rakesh: Data privacy through
optimal k-anonymization. In: Proceedings of the 21st IEEE International
Conference on Data Engineering (ICDE 2005), April 5-8, 2005, Tokyo,
Japan, 2005, S. 217–228
[BDS90]
Bundesdatenschutzgesetz in der Fassung der Bekanntmachung vom 14.
Januar 2003 (BGBl. I S. 66), das zuletzt durch Artikel 1 des Gesetzes vom
14. August 2009 (BGBl. I S. 2814) geändert worden ist. 1990
[BS08]
B r i c k e l l, Justin ; S h m at i kov, Vitaly: The cost of privacy: destruction of data-mining utility in anonymized data publishing. In: Proceedings of
the 14th ACM SIGKDD international conference on Knowledge discovery
and data mining, 2008, S. 70–78
[CB74]
C h a m b e r l i n, Donald D. ; B oy c e, Raymond F.: SEQUEL: A structured English query language. In: Proceedings of the 1974 ACM SIGFIDET
(now SIGMOD) workshop on Data description, access and control, 1974, S.
249–264
[CCN+ 06] C h e n, Whei-Jen ; C h u n, John ; N g a n, Naomi ; R a n j a n, Rakesh ;
S a r da n a, Manoj K.: DB2 Express-C: The Developer Handbook for XML,
PHP, C/C++, Java, and .NET. IBM, International Technical Support
Organization, 2006
[Dal86]
Da l e n i u s, Tore: Finding a needle in a haystack - or identifying anonymous census record. In: Journal of Official Statistics 2 (1986), Nr. 3, S.
329–336
[FWY05]
F u n g, Benjamin C. ; Wa n g, Ke ; Y u, Philip S.: Top-down specialization
for information and privacy preservation. In: Proceedings of the 21st IEEE
International Conference on Data Engineering (ICDE 2005), April 5-8,
2005, Tokyo, Japan, 2005, S. 205–216
51
Literatur
[Gra77]
G r a n d s t r a n d, O.: Towards a Methodology for Statistical Disclosure
Control. In: Statistik Tidskrift 15 (1977), S. 420–444
[IBM06]
I B M C o r p o r at i o n (Hrsg.): DB2 Version 9 for Linux, UNIX, and
Windows: Developing SQL and External Routines. SC10-4373-00. USA:
IBM Corporation, 2006
[IBM13]
I B M C o r p o r at i o n (Hrsg.): IBM DB2 10.5 for Linux, UNIX, and
Windows: Developing User-defined Routines (SQL and External). SC275501-00. USA: IBM Corporation, 2013
[IBM14a]
I B M C o r p o r at i o n (Hrsg.): IBM DB2 10.5 for Linux, UNIX, and
Windows: SQL Reference Volume 1. SC27-5509-01. USA: IBM Corporation,
2014
[IBM14b]
I B M C o r p o r at i o n (Hrsg.): IBM DB2 10.5 for Linux, UNIX, and
Windows: SQL Reference Volume 2. SC27-5510-01. USA: IBM Corporation,
2014
[KE13]
K e m p e r, Alfons ; E i c k l e r, André: Datenbanksysteme : eine Einführung. 9., erw. und aktualisierte Aufl. München : München : Oldenbourg,
2013
[KIK10]
K a n ta rc i o g l u, Murat ; I n a n, Ali ; K u z u, Mehmet: UT Dallas Anonymization ToolBox. http://cs.utdallas.edu/dspl/toolbox/
anonManual.pdf, 2010. – [letzter Zugriff: 27. Mai 2015]
[Lam93]
L a m b e rt, Diane: Measures of disclosure risk and harm. In: Journal of
Official Statistics 9 (1993), Nr. 2, S. 313–331
[LDR05]
L e F e v r e, Kristen ; D e W i t t, David J. ; R a m a k r i s h n a n, Raghu:
Incognito: Efficient Full-Domain K-Anonymity. In: Proceedings of the ACM
SIGMOD International Conference on Management of Data, June 14-16,
2005, Baltimore, Maryland, USA, 2005, S. 49–60
[LLV07]
L i, Ninghui ; L i, Tiancheng ; V e n k ata s u b r a m a n i a n, Suresh: tCloseness: Privacy Beyond k-Anonymity and `-Diversity. In: Proceedings
of the 23rd International Conference on Data Engineering, ICDE 2007,
April 15-20, 2007, Istanbul, Turkey, 2007, S. 106–115
[MGKV06] M ac h a n ava j j h a l a, Ashwin ; G e h r k e, Johannes ; K i f e r, Daniel
; V e n k i ta s u b r a m a n i a m, Muthuramakrishnan: `-Diversity: Privacy
Beyond k-Anonymity. In: Proceedings of the 22nd International Conference
on Data Engineering, ICDE 2006, April 3-8, 2006, Atlanta, GA, USA, 2006,
S. 24
52
Literatur
[MW04]
M e y e r s o n, Adam ; W i l l i a m s, Ryan: On the Complexity of Optimal K-Anonymity. In: Proceedings of the Twenty-third ACM SIGACTSIGMOD-SIGART Symposium on Principles of Database Systems, June
14-16, 2004, Paris, France, 2004, S. 223–228
[RS12]
R i e l au, Serge ; S wag e r m a n, Rick: MODULEs, a primer (SQL Tips
for DB2 LUW). https://www.ibm.com/developerworks/community/
blogs/SQLTips4DB2LUW/entry/module, 2012. – [letzter Zugriff: 28. Mai.
2015]
[Sam01]
S a m a r at i, Pierangela: Protecting respondents identities in microdata
release. In: IEEE Transactions on Knowledge and Data Engineering 13
(2001), Nr. 6, S. 1010–1027
[SS98]
S a m a r at i, Pierangela ; S w e e n e y, Latanya: Generalizing Data to
Provide Anonymity When Disclosing Information (Extended Abstract),
1998
[Swe00]
S w e e n e y, Latanya: Simple Demographics Often Identify People Uniquely
/ Carnegie Mellon University. 2000. – Forschungsbericht. – Data Privacy
Working Paper 3
[Swe01]
S w e e n e y, Latanya: Computational Disclosure Control: a Primer on
Data Privacy Protection, Dissertation, 2001
[Swe02a]
S w e e n e y, Latanya: Achieving k-Anonymity Privacy Protection Using
Generalization and Suppression. In: International Journal on Uncertainty,
Fuzziness and Knowledge-based Systems 10 (2002), Nr. 5, S. 571–588
[Swe02b]
S w e e n e y, Latanya: k-Anonymity: A Model for Protecting Privacy.
In: International Journal of Uncertainty, Fuzziness and Knowledge-Based
Systems 10 (2002), Nr. 5, S. 557–570
[Ull94]
U l l m a n, Jeffrey D.: Principles of database and knowledge-base systems.
Bd. 1. Rockville, MD, USA : Computer Science Press, 1994
[WW01]
W i l l e n b o rg, Leon ; Wa a l, Ton de: Elements of Statistical Disclosure
Control. New York, NY, USA : Springer, 2001 (Lecture Notes in Statistics
155)
[XT07]
X i ao, Xiaokui ; Tao, Yufei: m-invariance: Towards Privacy Preserving
Re-publication of Dynamic Datasets. In: Proceedings of the 2007 ACM
SIGMOD international conference on Management of data, 2007, S. 689–700
[YBC+ 03] Y i p, Paul ; B r a d s t o c k, Drew ; C u rt i, Hana ; G ao, Michael X. ;
J a n m o h a m e d, Zamil ; L i u, Clara ; M c A rt h u r, Fraser: DB2 SQL
Procedural Language for Linux, UNIX, and Windows. Prentice Hall, 2003
53
54
Selbständigkeitserklärung
Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst und noch nicht
für andere Prüfungen eingereicht habe. Sämtliche Quellen einschließlich Internetquellen,
die unverändert oder abgewandelt wiedergegeben werden, insbesondere Quellen für
Texte, Grafiken, Tabellen und Bilder, sind als solche kenntlich gemacht. Mir ist bekannt,
dass bei Verstößen gegen diese Grundsätze ein Verfahren wegen Täuschungsversuchs
bzw. Täuschung eingeleitet wird.
Berlin, den 10. Juni 2015
55