4 Richtlinien für datenschutzkonforme Ergebnisse
Um die Ergebnisse aus Jobs im Presentation / Publication Modus freizugeben, erfolgt eine datenschutzrechtliche Prüfung am FDZ in einem zweistufigen Verfahren: Zunächst kommt ein eigens dafür entwickeltes Prüfskript zur automatischen Löschung von kritischen Werten zum Einsatz. Dieses Skript kann jedoch nur einfache Ausgabeformate in Stata (z.B. für die Befehle tabulate oneway, summarize) prüfen und kritische Werte löschen. Anschließend erfolgt immer eine manuelle Prüfung aller Ergebnisse durch die Beschäftigten des FDZ.
Das FDZ nimmt in der Regel keine manuellen Löschungen in den Ergebnisdateien vor, sondern prüft lediglich, ob die Anforderungen für die Mindestanzahl erfüllt sind oder zu geringe Fallzahlen durch das automatische Prüfskript des FDZ zensiert wurden. In Ausnahmefällen übernimmt das FDZ manuelle Löschungen, wenn begründet werden kann, dass eine Zusammenfassung von Kategorien einer Variablen, um die Ausgabe von zu kleinen Fallzahlen zu vermeiden, nicht möglich ist. Nachträgliche manuelle Löschung durch die Nutzenden sind nicht möglich.
Sie müssen dafür Sorge tragen, dass Ihre Programme keinen Output mit zu geringen Fallzahlen erzeugen. Beispiele zur Gestaltung der Do-Files sind in den FDZ templates enthalten. Im Folgenden sind die wichtigsten Richtlinien des FDZ zur datenschutzrechtlichen Prüfung der Analyseergebnisse dargestellt. Die folgenden Beispiele sollen Ihnen zum einen veranschaulichen, welche Ergebnisse als datenschutzrechtlich bedenklich eingestuft werden, und zum anderen helfen, die Ausgabe solcher Ergebnisse zu vermeiden.
4.1 Anzahl der Beobachtungen allgemein
- Weisen Sie immer die zugrundeliegenden Fallzahlen bei allen statistischen Kennzahlen oder multivariaten Analysen aus. Bei Fehlen der Fallzahlen werden die betreffenden Ergebnisse nicht freigegeben.
- Sämtliche Ergebnisse müssen aus datenschutzrechtlichen Gründen auf mindestens 20 Beobachtungen basieren. Dies gilt für alle statistischen Kennzahlen, Kreuztabellen und auch multivariate Analysen. Die Mindestanforderung von 20 Beobachtungen der betrachteten Einheit gilt sowohl für die Unternehmens-, Betriebs- als auch die Personendaten, die das FDZ anbietet.
- Im Rahmen der Datenschutzprüfung am FDZ werden Log-Files oder ggf. der gesamte Job nicht freigegeben, wenn Werte enthalten sind, die auf weniger als 20 Beobachtungen (Personen und/oder Betrieben und/oder Unternehmen) basieren.
- Weisen Sie bei Auswertungen kombinierter Unternehmens-, Betriebs- und Personendaten in deskriptiven Tabellen sowohl die Anzahl der Beobachtungen für Personen als auch für Betriebe bzw. Unternehmen aus.
4.2 Häufigkeitsauszählungen
Bei Häufigkeitsauszählungen werden Werte < 20 in der Regel nicht freigegeben. In Kreuztabellen muss die Fallzahl jeder einzelnen Zelle >= 20 sein, die Gesamtzahl der Tabelle ist hier nicht ausreichend. Wenn also Auswertungen auf einer zu kleinen Beobachtungszahl basieren, müssen die Programme zu deren Erzeugung von Ihnen so angepasst werden, dass keine zu geringen Fallzahlen mehr ausgegeben werden. Beispielsweise können bei deskriptiven Statistiken Ausprägungen zusammengefasst oder ausgeschlossen werden, damit keine manuellen Löschungen mehr erforderlich sind. Beispiel 1 zeigt wie mit der Zusammenfassung der Kategorien „100-499 SVB“ und „500-999 SVB“, die Ausgabe von zu kleinen Werten verhindert werden kann. Weitere Hinweise finden sich im FDZ-Template jd02_describe.do.
Beispiel 1: Ostdeutschland
| Anz. svpfl. Besch. | Ja | Nein | Total |
|---|---|---|---|
| 1 1-4 SVB | 43 | 1380 | 1423 |
| 2 5-9 SVB | 39 | 547 | 586 |
| 3 10-99 SVB | 594 | 1322 | 1916 |
| 4 100-499 SVB | 573 | 175 | 748 |
| 5 500-999 SVB | 142 | 16 | 158 |
| Total | 1391 | 3440 | 4831 |
| Anz. svpfl. Besch. | Ja | Nein | Total |
|---|---|---|---|
| 1 1-4 SVB | 43 | 1380 | 1423 |
| 2 5-9 SVB | 39 | 547 | 586 |
| 3 10-99 SVB | 594 | 1322 | 1916 |
| 4 100-999 SVB | 715 | 175 | 906 |
| Total | 1391 | 16 | 4831 |
Ist eine Zusammenfassung von Kategorien aus wichtigen Gründen nicht möglich, kann in Ausnahmefällen eine manuelle Zensierung der Ergebnisse durch das FDZ-Team erfolgen. Zunächst müssen alle Werte (Fallzahlen, Verteilungsparameter und Regressionskoeffizienten), die auf einer Beobachtungszahl < 20 basieren, gelöscht werden. Um die Möglichkeit des Rückrechnens von gelöschten Werten durch Zwischen- oder Randsummen zu verhindern, müssen ggf. weitere Werte gelöscht oder gerundet werden.
In Beispiel 2 wird das Vorgehen des FDZ bei der Datenschutzprüfung von deskriptiven Kreuztabellen kurz erläutert. Zunächst wurden hier Werte < 20 aufgrund der zu geringen Fallzahl durch “/” ersetzt (Primärsperrung). Damit keine Rückrechnung des gelöschten Wertes mit Hilfe der Randsumme möglich ist, wurden zudem weitere Werte durch ein (“*”) einer Sekundärsperrung unterzogen.
Zudem muss ausgeschlossen werden, dass eine Rückrechnung über mehrere Tabellen hinweg möglich ist. Dies wird in Beispiel 3 deutlich. In Westdeutschland ist die Fallzahl in den einzelnen Zellen zwar jeweils >=20, da jedoch neben Ost- und Westdeutschland auch die Tabelle für Gesamtdeutschland ausgewiesen ist, wäre eine Rückrechnung der gelöschten Werte von Ostdeutschland (aus Beispiel 2) möglich. Aus diesem Grund werden auch in der Tabelle für Westdeutschland die entsprechenden Zellen zensiert (Sekundärsperrung: “*”).
Beispiel 2: Ostdeutschland
| Anz. svpfl. Besch. | Ja | Nein | Total |
|---|---|---|---|
| 1 1-4 SVB | 43 | 1380 | 1423 |
| 2 5-9 SVB | 39 | 547 | 586 |
| 3 10-99 SVB | 594 | 1322 | 1916 |
| 4 100-499 SVB | 573 | 175 | 748 |
| 5 500-999 SVB | 142 | 16 | 158 |
| Total | 1391 | 3440 | 4831 |
| Anz. svpfl. Besch. | Ja | Nein | Total |
|---|---|---|---|
| 1 1-4 SVB | 43 | 1380 | 1423 |
| 2 5-9 SVB | 3* | 54* | 586 |
| 3 10-99 SVB | 594 | 1322 | 1916 |
| 4 100-499 SVB | 573 | 175 | 748 |
| 5 500-999 SVB | 14* | / | 158 |
| Total | 1391 | 3440 | 4831 |
Aufgrund des Deanonymisierungsrisikos ist es notwendig, Auszählungen nach allen Subgruppen auszuweisen, sobald die Möglichkeit des Rückrechnens besteht. In obenstehendem Beispiel ist es daher notwendig sowohl die Tabelle nach West- als auch nach Ostdeutschland auszuweisen, da durch die Werte für Gesamtdeutschland auf Ostdeutschland rückgerechnet werden kann. Wollen Sie hingegen beispielsweise anstatt eines Ost-West-Vergleichs branchenspezifisch nur das Baugewerbe analysieren, ist keine Ausgabe aller Wirtschaftszweige notwendig, da keine Rückrechnung mit Hilfe der Ergebnisse für die Gesamtwirtschaft möglich ist.
4.3 Statistische Kennzahlen
Statistische Kennzahlen lassen auf den ersten Blick keinen Rückschluss auf die zugrunde gelegten Fallzahlen zu. Das heißt aber nicht, dass die Ausgabe statistischer Kennzahlen, wie z.B. Mittelwerte, nicht problematisch sein kann. Auch hier gilt das Prinzip, dass die angesprochenen Kennzahlen nur dann als sicher eingestuft werden, wenn die Berechnungsgrundlage mindestens 20 Beobachtungen umfasst. Als Spezialfall ist die Ausgabe statistischer Kennzahlen bei Dummys zu sehen. Bei binär kodierten Merkmalen verteilen sich die Ausprägungen dieser auf lediglich zwei Kategorien. Auch wenn die Gesamtanzahl der Beobachtungen einer Dummy-Variablen größer als 20 ist, kann es sein, dass durch eine schiefe Verteilung nur drei Personen, Betriebe oder Unternehmen auf eine der Ausprägungen fallen. In diesem Fall wird die Auswertung als unsicher angesehen, auch wenn nicht direkt über die Gesamtanzahl der Beobachtungen auf eine geringe Besetzung einer Kategorie geschlossen werden kann. Denn dies kann mit Hilfe des Mittelwerts einfach herausgefunden werden. Um diese Fälle identifizieren und prüfen zu können, ist es erforderlich, dass bei der Ausgabe von Mittelwerten dokumentiert wird, ob es sich um eine Dummy-Variable handelt.
Beispiel 3: Westdeutschland
| Anz. svpfl. Besch. | Ja | Nein | Total |
|---|---|---|---|
| 1 1-4 SVB | 64 | 2461 | 2525 |
| 2 5-9 SVB | 54 | 847 | 901 |
| 3 10-99 SVB | 859 | 1985 | 2844 |
| 4 100-499 SVB | 793 | 255 | 1048 |
| 5 500-999 SVB | 198 | 22 | 220 |
| Total | 1968 | 5570 | 7538 |
| Anz. svpfl. Besch. | Ja | Nein | Total |
|---|---|---|---|
| 1 1-4 SVB | 64 | 2461 | 2525 |
| 2 5-9 SVB | 5* | 84* | 901 |
| 3 10-99 SVB | 859 | 1985 | 2844 |
| 4 100-499 SVB | 793 | 255 | 1048 |
| 5 500-999 SVB | 19* | 2* | 220 |
| Total | 1968 | 5570 | 7538 |
Gesamtdeutschland
| Anz. svpfl. Besch. | Ja | Nein | Total |
|---|---|---|---|
| 1 1-4 SVB | 107 | 3841 | 3948 |
| 2 5-9 SVB | 93 | 1394 | 1487 |
| 3 10-99 SVB | 1453 | 3307 | 4760 |
| 4 100-499 SVB | 1366 | 430 | 1796 |
| 5 500-999 SVB | 340 | 38 | 378 |
| Total | 3359 | 9010 | 12369 |
| Anz. svpfl. Besch. | Ja | Nein | Total |
|---|---|---|---|
| 1 1-4 SVB | 107 | 3841 | 3948 |
| 2 5-9 SVB | 93 | 1394 | 1487 |
| 3 10-99 SVB | 1453 | 3307 | 4760 |
| 4 100-499 SVB | 1366 | 430 | 1796 |
| 5 500-999 SVB | 340 | 38 | 378 |
| Total | 3359 | 9010 | 12369 |
Beispiel 4 veranschaulicht die Problematik bei der Ausgabe von Mittelwerten. Bei der Dummy-Variable r61 mussten alle Werte zensiert werden, da aufgrund der schiefen Verteilung nur 12 Betriebe (140*0.0857143) auf eine der beiden Ausprägung fallen.
Beispiel 4
| Variable | Obs | Mean | Std. Dev | Min | Max |
|---|---|---|---|---|---|
| r60 | 201 | 2.373134 | 0.9192794 | 1 | 3 |
| r61 | 140 | 0.0857143 | 0.2809469 | 0 | 1 |
| r62a | 73 | 2.219178 | 2.340742 | 1 | 15 |
| Variable | Obs | Mean | Std. Dev | Min | Max |
|---|---|---|---|---|---|
| r60 | 201 | 2.373134 | 0.9192794 | 1 | 3 |
| r61 | 140 | / | / | / | / |
| r62a | 73 | 2.219178 | 2.340742 | 1 | 15 |
Bei Verwendung des summarize-Befehls in Stata werden entsprechende Fälle durch das Prüfskript des FDZ automatisch überprüft und ggf. gelöscht. Werden entsprechende Ergebnisse anhand anderer Befehle (z.B. table, tabstat) erzeugt, kann keine automatische Löschung erfolgen. In diesen Fällen müssen Sie auf die Ausgabe von Ergebnissen mit zu geringen Fallzahlen verzichten, indem Sie den entsprechenden Code aus Ihren Auswertungsprogrammen löschen.
4.4 Percentiles / quantiles
Bei der Ausgabe von Perzentilen muss darauf geachtet werden, dass mindestens 20 Beobachtungen im jeweiligen Perzentil enthalten sind. Bei einer detaillierten Ausgabe (1% Perzentile) müssen folglich insgesamt mindestens 2000 Beobachtungen in die Ausgabe mit einfließen, um die Datenschutzvorgaben des FDZ zu gewährleisten. Grundsätzlich gilt, je detailliertere Informationen man erhalten will, umso mehr Beobachtungen müssen für die gesamte Verteilung vorhanden sein:
- Mind. 20 Beobachtungen für die Ausgabe von Mittelwerten (Ausnahme Dummys)
- Mind. 40 Beobachtungen für die Ausgabe von 50%-Perzentilen
- Mind. 80 Beobachtungen für die Ausgabe von 25%- oder 75%-Perzentilen
- Mind. 200 Beobachtungen für die Ausgabe von 10%- oder 90%-Perzentilen
- Mind. 400 Beobachtungen für die Ausgabe von 5%- oder 95%-Perzentilen
- Mind. 2000 Beobachtungen für die Ausgabe von 1%- oder 99%-Perzentilen
Werden Quantilswerte ausgegeben, so ist immer der geringste Abstand zwischen den gewählten Prozentsätzen (auch zur Null und zu 100) ausschlaggebend – werden z.B. die Perzentile 10 – 15 – 30 ausgegeben, muss die Stichprobe mindestens (15-10)/100 * x ≥ 20 → x ≥ 400 Beobachtungen betragen, um die notwendigen 20 Beobachtungen in jedem Quantil zu gewährleisten.
Bei Verwendung des summarize-Befehls in Stata werden entsprechende Fälle durch das Prüfskript des FDZ automatisch überprüft und ggf. gelöscht. Werden entsprechende Ergebnisse anhand anderer Befehle (z.B. table, tabstat) erzeugt, kann keine automatische Löschung erfolgen. In diesen Fällen müssen Sie auf die Ausgabe von Ergebnissen mit zu geringen Fallzahlen verzichten, indem Sie den entsprechenden Code aus ihren Auswertungsprogrammen löschen oder so anpassen, dass Perzentile mit größeren Abständen ausgegeben werden, für die ausreichend viele Fälle vorliegen.
4.5 Gewichtung
Bei Verwendung jeglicher Hochrechnungs- oder Gewichtungsfaktoren in deskriptiven Analysen sind auch immer analoge ungewichtete Ergebnisse auszuweisen. Die gewichteten und die dazugehörigen ungewichteten Ergebnistabellen müssen dabei must directly follow folgen, weil dies die Datenschutzprüfung erleichtert und somit - auch für Sie - beschleunigt. Dies muss auch in Schleifen entsprechend berücksichtigt und kommentiert werden. Fehlt die ungewichtete Ausgabe, kann das entsprechende Log-File bzw. ggf. der gesamte Job nicht freigegeben werden. Weitere Hinweise finden sich im FDZ-Template jd02 jd02_describe.do.
Bei gewichteten Regressionen ist die Angabe der ungewichteten Fallzahl notwendig, wenn iweights oder fweights verwendet werden.
4.6 Grafiken
Zu jeder Grafik ist nachzuweisen, auf wie vielen Beobachtungen die einzelnen dargestellten Werte basieren. Dabei ist es nicht ausreichend die Gesamtfallzahl auszuweisen, sondern es muss die Beobachtungszahl jedes einzelnen dargestellten Balkens bzw. Punktes aufgelistet werden. Dies kann über die Angabe der Fallzahlen entweder direkt in den Grafiken oder in Tabellen, die sich unmittelbar vor oder nach der Erstellung der Grafiken befinden, erfolgen. Bei der Darstellung von sehr vielen Datenpunkten in Grafiken ist es nicht erforderlich, für jeden einzelnen Datenpunkt die Fallzahl auszugeben. Hier reicht es, wenn Sie nachweisen, dass die kleinste zugrundeliegende Fallzahl mindestens 20 ist. Ein Beispiel dafür finden Sie im FDZ-Template jd05_graphs.do.
Auch für Grafiken gilt die Fallzahlgrenze von mindestens 20 Beobachtungen. Somit sind z.B. Scatterplots auf Individualebene nicht erlaubt, da hinter den einzelnen ausgegebenen Datenpunkten weniger als 20 Beobachtungen stehen. Während bei Histogrammen die Fallzahlen für jeden einzelnen Balken ausgegeben werden müssen, ist bei Kernel Density Plots die Gesamtfallzahl ausreichend. Koeffizienten- bzw. Marginsplots sind unbedenklich, wenn die Fallzahl in der zugehörigen Regressionstabelle ausreichend ist. Zudem ist die Verwendung der asis-Option beim Speichern der Grafik im gph-Format verpflichtend, um sicherzustellen, dass die Grafik in der derzeitigen Form gespeichert wird und keine nachträgliche Bearbeitung mehr möglich ist. Weitere Hinweise finden sich im FDZ-Template jd05_graphs.do.
4.7 LaTeX-Output
Stata-Ergebnisdateien müssen entweder die Endung „.log“ oder „.txt“ tragen. Ergebnisse, die in separate Dateien außerhalb der von Stata angelegten Log-Files geschrieben wurden, können nicht bereitgestellt werden. Sie müssen wieder in das Log-File mit type Pfadangabe eingebunden werden. Achten Sie darauf, dass der Output übersichtlich gestaltet und leicht lesbar ist (z.B. durch feste Spaltenbreiten). Sollte dies in Ausnahmefällen nicht umsetzbar sein, müssen die Ergebnisse unmittelbar vor dem eingebundenen Text nochmals in lesbarer Form dargestellt werden. Ein Beispiel finden Sie im FDZ-Template jd03_analyses.do.
4.8 Aggregierte Daten
4.8.1 Import aggregierter Daten in das Projekt
Externe Kenngrößen auf aggregiertem Niveau (z. B. Arbeitslosenquoten nach Kreisen) dürfen den Daten zugespielt werden, wenn sie den Datenschutzrichtlinien des FDZ entsprechen. Weitere Informationen zu den Voraussetzungen und zum Vorgehen finden Sie in unseren Anleitungen in Abschnitt 2.2.2.
4.8.2 Dokumentation von Aggregationsschritten innerhalb eines Projekts
Wenn Sie die ursprünglichen Mikrodaten für weitere Analysen aggregieren (z. B. auf die Ebene von Branchen, Regionen etc.), stellen Sie bitte sicher, dass dies im Log-File angemessen dokumentiert wird (Überschriften; erläuternde Anmerkungen). Alle Ergebnisdateien, die nach einem solchen Aggregationsschritt erstellt werden (und den aggregierten Datensatz als Hauptdatenquelle verwenden), müssen am Anfang in der Kommentierung folgende Informationen enthalten:
- auf welche Ebene aggregiert wurde
- in welchem Programmschritt (z.B. Do-File) aggregiert wurde (bitte auch in der Master-Datei kennzeichnen)
Fehlen diese Informationen oder sie sind schwer zu finden, können die Ergebnisse nicht geprüft und freigegeben werden.
Wenn Sie diese aggregierten Variablen später ausgeben wollen, beachten Sie bitte, dass hier immer noch die Regeln für die Mindestanzahl von Beobachtungen (siehe Abschnitt 4.1 bis 4.3) gelten. Daher müssen die folgenden Anforderungen erfüllt sein:
- Es muss je aggregierter Variable, die ausgegeben werden soll, eine zusätzliche Variable gebildet werden, welche die Anzahl der entsprechenden gültigen Beobachtungen pro Zelle enthält.
- Ist das gewünschte Aggregat z.B. ein Anteil oder eine Quote muss bei tabellarischen Darstellungen zusätzlich die Anzahl der gültigen Werte in den einzelnen Subgruppen, die zur Erstellung des Aggregats verendet wurden, ausgegeben werden (z. B. Anzahl Männer in Bundesland X und Anzahl Frauen in Bundesland X für die Frauenquote in Bundesland X).
Beispiele zur richtigen Programmierung von Aggregaten finden Sie im FDZ-Template jd02_describe.do. Die Anzahl der aggregierten Tabellen sollte im Sinne der Datensparsamkeit auf ein Minimum beschränkt sein 1.
4.8.3 Export/Transfer aggregierter Datensätze aus dem Projekt
Falls Sie einen umfangreicheren aggregierten Datensatz als .dta-Datei erhalten oder in ein anderes Projektverzeichnis transferieren möchten, weil er als Tabelle in einem Log-File nicht richtig dargestellt und geprüft werden kann (oder wenn Sie diesen Datensatz in ein anderes Projektverzeichnis übertragen möchten), sprechen Sie die Vorgehensweise bitte vorher, im Idealfall bereits bei der Antragsstellung, mit uns ab. Neben dem Zweck der Aggregation muss geklärt werden, auf welcher Ebene aggregiert wird und wie die enthaltenen Variablen generiert wurden (Summe, Mittelwert, etc.). Erläutern Sie, warum der Export/Transfer notwendig ist.
Die Generierung der aggregierten Daten kann mit den Testdaten vorbereitet werden und sollte während eines Gastaufenthalts erfolgen. Die Programme müssen anschließend nochmals mit JoSuA gestartet werden. Bitte verwenden Sie dafür den Modus Presentation/Publication und vermerken Sie im Kommentarfeld, dass Sie einen generierten Datensatz erhalten bzw. transferieren möchten und den entsprechenden Dateinamen. Speichern Sie diesen Datensatz immer im Unterverzeichnis data.
Da die Prüfung von aggregierten Datensätzen sehr aufwändig ist, müssen folgende Regeln bei der Erstellung berücksichtigt werden:
- Die vollständige Erstellung des aggregierten Datensatzes, von Original-Datensatz bis zum zu exportierenden Datensatz, muss in einem Do-File/Log-File erfolgen. Bitte vermeiden Sie unnötige Schritte im Do-File. Ein Beispiel finden Sie im FDZ-Template
jd06_export_aggregate.do. - Die Vorgaben zur Dokumentation und Darstellung der Fallzahlen, die im vorherigen Abschnitt beschrieben wurden, gelten ebenso.
- Verwenden Sie aussagekräftige Variablennamen, Variablenlabels und Wertelabels für die zu exportierenden Merkmale.
- Vermeiden Sie sich überlagernde Aggregationen (z.B. Bundesland + Arbeitsmarktregion + Kreis), zumindest wenn die kleinste Aggregationsebene Zellen enthält, die zensiert werden müssen.
- Fügen Sie keine Variablen für weitere Untergruppen im ‘wide’ Format an. Bleiben Sie im ‘long’ Format.
- Die Variablen, die die Aggregationsebene angeben, müssen “lvl_1_*, lvl_2_*, …” heißen, z.B. bei einer Aggregation nach Jahren und Bundesländern sollten die Variablen für die Kategorien mit lvl_1_year und lvl_2_fstate bezeichnet werden.
- Nach jeder aggregierten Ergebnis-Variablen (wenn sie nicht an sich schon eine Zählvariable ist) muss eine Variable, die die entsprechende Anzahl der zugrundeliegenden Beobachtungen enthält, folgen. Diese Variable muss genauso benannt werden, aber das Präfix N_ enthalten.
- Versuchen Sie, den aggregierten Datensatz so klein wie möglich zu halten. Insbesondere sollten Werte, die anhand anderer Informationen im aggregierten Datensatz berechnet werden können (z.B. Summen oder Quoten), erst nach dem Export oder Transfer generiert werden, um den Prüfaufwand zu reduzieren.
Zusätzlich müssen Sie für den Export/Transfer eines aggregierten Datensatzes sicherstellen, dass jeder Zelle mindestens 20 Beobachtungen zugrunde liegen. Sollte dies nicht der Fall sein, haben Sie folgende Optionen:
- Fassen Sie Kategorien zusammen (vom FDZ bevorzugtes Vorgehen). Möchten Sie z. B. Aggregate auf Kreisebene erhalten, fassen Sie Kreise, die zu geringe Fallzahlen aufweisen, zusammen.
- Zensieren Sie Zellen, die zu geringe Fallzahlen aufweisen selbst (vom FDZ nicht bevorzugtes Vorgehen). Gehen Sie dabei wie folgt vor:
- Ist die Fallzahl in einzelnen Zellen des Datensatzes < 20, setzen Sie die Zählvariable und alle anderen Ergebnisse für dies Zelle auf die Missing-Kategorie “.p”.
- Halten Sie die Anzahl der Zellen mit nicht ausreichend großen Fallzahlen so gering wie möglich. Bedenken Sie, dass wir ggf. eine Sekundärsperrung vornehmen müssen (siehe Abschnitt 4.2).
- Ergänzen Sie eine Begründung, warum weitere Aggregationen/Zusammenfassungen für Ihr Projekt nicht vertretbar sind.
- Bitte beachten Sie, dass wir uns das Recht vorbehalten, die Freigabe von Daten für den Export oder Transfer zu verweigern, wenn sie zu gering besetzte Zellen enthalten, die nicht angemessen begründet und dokumentiert sind, oder wenn wir zu dem Schluss kommen, dass der Zeitaufwand für eine angemessene Datenschutzprüfung zu groß wäre.
Für jedes Projekt kann nur einmal ein solcher Datensatz weitergegeben werden. Dies gilt auch, wenn der aggregierte Datensatz in einem anderen FDZ-Projektverzeichnis zur Zuspielung bereitgestellt werden soll. Der Export des Datensatzes erfolgt per E-Mail. Transfers in andere Projektverzeichnisse übernehmen die Beschäftigten des FDZ.
4.9 Regressionoutput
Die Gesamtzahl der zur Schätzung verwendeten Beobachtungen muss bei Regressionen mindestens 20 betragen. Ergebnisse multivariater Analysen, die auf weniger als 20 Beobachtungen beruhen, können generell nicht freigegeben werden und sollten daher aus den Programmen entfernt werden.
Mit Hilfe von Regressionen lassen sich unter Umständen allerdings auch indirekt kleine Fallzahlen ermitteln. Deshalb reicht es hier nicht aus, nur die Gesamtanzahl der Beobachtungen zu beachten. Problematisch sind:
- Regressionen, aus deren Koeffizienten sich der unbedingte Mittelwert ergibt, wie beispielsweise bei einer Regression mit lediglich einer Dummy-Variablen oder einer Gruppe von Dummys, z.B. für die Bundesländer
- Regressionen mit zwei oder mehr Variablen in voll interagierten Modellen (alle möglichen Kombinationen der Merkmalsausprägungen).
Hier muss sichergestellt werden, dass die einzelnen Ausprägungen der dichotomen oder kategorialen Variablen mindestens 20 Beobachtungen beinhalten. Dies soll durch eine Auszählung der einzelnen Variablen nach dem Regressionsoutput unter Verwendung von if e(sample) gezeigt werden. Jede weitere Variable im Modell lässt keine Rückschlüsse mehr zu. Weitere Hinweise finden Sie im FDZ-Template jd03_analyses.do.
4.10 Ereignisdatenanalyse
Bei Anwendung des sts list-Befehls im Rahmen der Ereignisdatenanalyse, um sich die Ergebnisse des Kaplan-Meier-Schätzer auszuweisen, ist der Wert zu Beginn der Tabelle (population at risk) für die Datenschutzprüfung relevant. Darüber hinaus muss bei der Ausweisung von Gruppen in Grafiken der sts list-Befehl ebenfalls für jede Gruppe erfolgen.
Bei Weitergabe von Ergebnissen aus Survival-Analysen muss lediglich der Anfangswert >= 20 sein, nicht jeder einzelne Schritt.
4.11 Sequenzmusteranalyse
Bei der Sequenzmusteranalyse ist sicherzustellen, dass graphische Darstellungen auf einer ausreichend großen Anzahl von Beobachtungen basieren. Hierfür gibt es zwei zulässige Möglichkeiten. Unbedenklich ist es, Sequenzmuster pro Zeiteinheit als Anteile der Zustände anzugeben (z. B. im Monat 1 sind 30 % der Personen in Arbeitslosigkeit und 70 % in Erwerbstätigkeit). Des Weiteren ist es möglich, aggregierte Sequenzmuster für Gruppen darzustellen, wenn jede Gruppe mindestens 3 Beobachtungen beinhaltet. Sequenzmuster für weniger als 3 Individuen, Betriebe oder Unternehmen graphisch darzustellen ist nicht zulässig.
Zu beachten ist hierbei, dass das automatisierte Prüfskript bei bestimmten Stata-Befehlen wie summarize oder tabulate auch aggregierte Ausgaben, beispielsweise auf Kreisebene, trotz einer ausreichenden Anzahl an Personen bzw. Betrieben/Unternehmen innerhalb der Kreise löscht bzw. zensiert. In solchen Fällen würden wir Sie bitten Rücksprache mit dem FDZ zu halten, um eine solche Löschung von Ergebnissen durch eine angepasste Programmierung zu vermeiden.↩︎