Skalierbare Datenqualität in anwendungsspezifischen Szenarien

Abstract

Konzepte der Datenqualitat haben sich neben vielen Disziplinen auch im Umfeld der Informationstechnologie etabliert und somit einen festen Platz in Aspekten der Entwicklung neuer Informationssysteme eingenommen. Das Vorhandensein vieler unterschiedlicher objektiver und subjektiver Anforderungen an die Qualitat von Daten zwingt den Entwickler mittlerweile dazu, einen immer gro eren Teil seiner Entwicklungszeit fur die Modellierung von Konzepten zur Qualitatserfullung zu verwenden. In diesem Beitrag wird eine erste Idee vorgestellt, um diesen Aufwand fruhzeitig zu verringern. Dazu wird zunachst eine Betrachtung der sicherheitsrelevanten Qualitatsfaktoren vorgenommen. Daraufhin erfolgt eine anwendungsspezi sche Einordnung der Qualitatskriterien in Gruppen ahnlicher Charakteristika mit anschlie ender Skalierung. Somit besteht die Moglichkeit einzelne Gruppen mit besonders hohen Qualitatsbedurfnissen zu identi zieren und zu behandeln. Ressourcen konnen dadurch von Anfang an schonender und auf bestimmte Qualitatskriterien hin gezielter eingesetzt werden.

Keywords

• eol>Datenqualitat
• Qualitatsbewertung
• Qualitatsmodell

Categories and Subject Descriptors

H.1.1 [Systems and Information Theory]: Value of information

Datenqualitat ist somit ein unverzichtbarer Begleiter jeglicher Informationssysteme. Ursprunglich und auch heute noch hat das Konzept der Datenqualitat in der Integration heterogener Datenbestande einen besonders hohen Stellenwert. Aber naturlich sind auch fur jedes andere Softwaresystem die Techniken zur Erhohung der Datenqualitat einsetzbar und empfehlenswert [ 9 ]. Deshalb ist schon bei der Planung von Softwaresystemen, unabhangig vom Anwendungsszenario, darauf zu achten, dass von vornherein ein verstarkter Blick auf die Datenqualitat gerichtet wird. Qualitat bedeutet eine bestimmte Eignung fur einen Zweck. Das hei t, dass fur jeden Zweck der Qualitatsbegri bzw. dessen Auspragung neu bestimmt werden muss [ 4 ]. Damit wird ausgesagt, dass jedes Anwendungsszenario einen anderen Blickwinkel auf bestimmte Qualitatsaspekte von Daten besitzt. Das bedeutet, dass jedes Szenario und dessen Zielsetzung im Hinblick auf den Einsatz bestimmter Methoden und Konzepte der Datenqualitat immer wieder neu diskutiert werden muss. Diese Ma nahmen resultieren aus den verschiedenen Anforderungen an die Datenqualitat, die in einem besonderen Ma e betrachtet werden mussen. In der Literatur werden zwar Vollstandigkeit, Fehlerfreiheit, Konsistenz und Aktualitat als besonders wichtige Anforderungen beschrieben; diese konnen aber in unterschiedlichen Anwendungsszenarien, neben weiteren Anforderungen, verschieden wichtige Stellungen einnehmen. Bei geogra schen Anwendungen ist es z.B. die spezielle Anforderung an die Positionsgenauigkeit, die einen sehr hohen Stellenwert besitzt, aber in kaum einem anderen Anwendungsszenario wichtig ist [ 6 ], oder auch Forderungen nach referenzieller Integritat als Qualitatsanforderung an relationale Datenbanken [ 2 ]. ten eher applikations- oder kundenbezogene Anspruchsniveaus (Soll-Wert) auf Anforderungen de niert werden, an denen die Qualitat der Daten im laufenden Prozess beurteilt werden kann [ 2 ]. Somit kann es kein allgemeines Qualitatsmodell fur Daten bei der Entwicklung von Softwaresystemen geben. Deshalb stellen wir hier einen Losungsansatz vor, der ein objektives Vorgehen de niert ohne die benotigten dynamischen Aspekte einzelner Anwendungsszenarien zu vernachlassigen.

2. STAND DER TECHNIK

Eingangs wurde bereits die Moglichkeit einer Gruppierung von Qualitatsdimensionen erwahnt. Diese Idee, als Qualitatsmodell benannt, ist an sich nichts Neues. Um einen U berblick uber vorhandene Modelle und deren Charakteristika zu geben, fuhren wir anschlie end vier von ihnen an. Mitte der 1990er Jahre wurde durch Wang und Strong eine Befragung bei IT-Managern durchgefuhrt [ 10 ]. Diese sehr oft zitierte Umfrage ergab als Ergebnis einen Umfang von 179 Anforderungen an die Qualitat von Daten. Von den Autoren wurden anschlie end 15 Anforderungen ausgewahlt, die von der Mehrzahl der Befragten genannt wurden.

Ein Gro teil der heutigen Autoren geht von annahernd diesen 15 grundlegenden, allgemeinen Anforderungen, den sogenannten Qualitatsdimensionen, aus. Auch wenn diese in diversen Publikationen oft syntaktisch unterschiedlich erscheinen, ero net die Kurzerklarung meist einen semantischen Zusammenhang. Die in Deutschland gebrauchlichen Dimensionen1 wurden durch die Deutsche Gesellschaft fur Informations- und Datenqualitat auf Grundlage von Robert Wang [ 10 ] erstellt. Dabei wurden sie ins Deutsche ubersetzt und mit festen De nitionen versehen. Ein Ziel dieser Festlegung war, dass Dimensionen so ausgelegt werden, dass sie zum einen uberschneidungsfrei sind und zum anderen entweder einzeln oder in eindeutiger Kombination miteinander verwendet werden konnen [ 9 ].

Die Autoren au erten sich zusatzlich zu einer Kategorisierung der Dimensionen nach bestimmten Merkmalen. Das Ergebnis von Wang und Strong war eine erste Zerlegungssemantik, die die Dimensionen in 4 Kategorien nach folgendem Muster einordnete:

Informationszugang (Systemzugang, Zugangssicherheit) Informationszusammenhang (Relevanz, Zusatznutzen, Aktualitat, Vollstandigkeit, Informationsumfang) 115 Qualitatsdimensionen: Zuganglichkeit, Angemessener Umfang, Glaubwurdigkeit, Vollstandigkeit, U bersichtlichkeit, Einheitliche Darstellung, Bearbeitbarkeit, Fehlerfreiheit, Eindeutige Auslegbarkeit, Objektivitat, Relevanz, Hohes Ansehen, Aktualitat, Verstandlichkeit, Wertschopfung 80% der befragten IT-Manager durch Wang hatten ebenfalls diese Kategoriserung gewahlt [ 9, 10 ]. Diese erste Systematisierung machte es moglich Datenqualitat auf einer strukturierten Ebene zu behandeln, zu steuern, zu messen und im Anschlu daran auch zu bewerten. Auf Grundlage dieses Modelles sind viele weitere Modelle entstanden, die sich in ihrer Zerlegungssemantik unterscheiden und somit auch Unstimmigkeiten untereinander erzeugen. Es seien an dieser Stelle noch 3 weitere Modelle genannt, die in der Literatur erhohtes Interesse aufweisen.

Ein Modell, dass direkt von Wang abgeleitet ist, ist das von Felix Naumann (2002). Er veranderte die Kategorien (leicht, nach eigenen Aussagen) und die Einordnung der Dimensionen (teilweise anders benannt) und bemerkte zudem, dass viele Kriterien immer noch sehr subjektiv gepragt seien und eine feste De nition deshalb auch nicht sinnvoll erscheint [ 4 ].

Inhaltsbezogene Kriterien (Interpretierbarkeit, Dokumentation, ...)

Technische K. (Verfugbarkeit, Preis, ...)

Intellektuelle K. (Glaubwurdigkeit, Reputation, ...)

Instanzbezogene K. (Datenmenge, Verstandlichkeit, ...) Allerdings, so Naumann, ist eine solche Liste nutzlich, um fur bestimmte Anwendungen die relevante Teilmenge aus den Kategorien festlegen zu konnen [ 4 ]. Es wird allerdings nicht auf die Art und Weise bzw. auf die Vorgehensgrundlage sowie auf die weiterfuhrende Zerlegungssemantik eingegangen.

Um noch einmal, wie in der Motivation schon einleitend erwahnt, zu verdeutlichen, dass bestimmte Szenarien neben den grundsatzlich wichtigen Dimensionen, wie z.B. Vollstandigkeit und Fehlerfreiheit, auch anwendungsspezi sche Dimensionen nutzen, um die Relevanz anwendungsspezi scher Gegebenheiten auszudrucken, zeigt das Qualitatsmodell nach Hinrichs (Figure 1).

Hier nden sich in der rechten Kategorie die Dimensionen Schlusseleindeutigkeit und Referenzielle Integritat, die speziell auf relationale Datenbanken ausgerichtet sind. Bei der Verbreitung relationaler Datenbanken ware der Einsatz dieses Modells allerdings nach [ 2 ] als legitim anzusehen. Das letzte hier genannte Qualitatsmodell stellt das Referenzmodell im deutschsprachigen Raum dar (Figure 2). Im Jahr 2007 uberarbeite die Deutsche Gesellschaft fur Informationsund Datenqualitat (DGIQ) die von Robert Wang ursprunglich 15 ermittelten Qualitatsdimensionen und ubersetzte sie t"ign, anl\acinhs eDigeeuntesrchAeuusnsdagpea)ss[8te]. dDieieD4e Kniattioegnoernieann, (deiiendheiuergenutzt wurden, sind von der Zerlegungssemantik her dem ljtueewnmgeusinlbietgezeornsgteUuntnztzteurzsuDucaShryusstnteeglmlsug\ne,gg\e"ninusthnaadnred"nzztwuezgcuekoaIrnbdhhnaaenltt.\gi,Ag "lszdouar"Nsstyuestl--zung\ [ 9 ].

Die Anforderungen an die Qualitat von Daten stellen eine Grundlage fur die Messbarkeit und Bewertung der Qualitat, also der Eignung von Daten fur einen bestimmten Zweck, dar. Die Messung und Bewertung von Qualitat ist immer noch sehr stark subjektiv gepragt. Das wird belegt durch generelle Aussagen wie: "Die Qualitat von Daten ist dann gut, wenn Sie den Anforderungen an den Gebrauch der Daten erfullen.\ [ 1 ] oder: "Die Qualitat der erhobenen Daten ist abhangig von der Qualitat der Erhebung.\ [ 7 ]. Die Qualitat der Daten wird also immer an anderen Ma staben gemessen. Durch diese, wie schon erwahnt, meist subjektiven Bewertungen ist es erforderlich, zumindest eine objektive Vorgehensweise zu de nieren, die die gesetzten Qualitatsdimensionen nutzt und diese dynamisch auf verschiedene Anwendungsszenarien anwendet. Die hier gezeigten Qualitatsmodelle versuchen bzw. haben die einzelnen Qualitatsdimensionen in Kategorien zusammengefasst, um den Umgang mit ihnen zu erleichtern. Allerdings fallen 2 Aspekte auf: 1. Spezi sche Dimensionen Die Nutzung von anwendungsspezi schen Dimensionen passt das Qualitatsmodell fur diese bestimmte Anwendung an, macht es aber gegenuber etablierten Modellen nicht vergleichbar. Erfahrungswerte von vorhergehenden Modellen konnen so nicht ubernommen werden. 2. Statische Modelle Die hier vorgestellten Modelle sind alle sehr statisch aufgebaut. Anwendungsspezi sche Szenarien konnen damit nicht exibel genug beschrieben werden.

Unser Ziel ist die exible Gruppierung durch vorhandene und anerkannte Qualitatsdimensionen fur anwendungsspezische Szenarien. Und dies so, dass gesammelte Erfahrungswerte auf spater folgende Modelle mit ubernommen werden konnen.

3. LÖSUNGSANSATZ

3.1 Rechtliche Anforderungen als Qualitätsdimension

Einige Autoren ([ 1, 10 ] etc.) fuhrten innerhalb ihrer Qualitatsdimensionen auch die der Sicherheit an. Grundlegend kann man sagen, dass die Dimension der "Sicherheit\ inhaltlich zu einem gro en Teil aus Anforderungen an den Datenschutz bestehen und somit auch rechtliche Vorgaben widerspiegeln. Diese rechtlichen Vorgaben mussen erfullt werden und konnen, wie spater in diesem Beitrag zu sehen, zunachst nicht in ihrer Wichtigkeit skaliert werden. Deshalb gehort unserer Meinung nach der rechtliche Teil der Dimension Sicherheit auch nicht zur Datenqualitat. Allerdings kann die Sicherheit auf Kundenwunsch hin uber den Anforderungen von rechtlichen Vorgaben oder leitlinienerstellenden Einrichtungen liegen. Wir sprechen hier von einer U bererfullung von sicherheitsrelevanten Anforderungen, die wiederum einen qualitativen Charakter besitzen. Dieser Mehrwert kann in Zahlen, und somit skaliert, ausgedruckt werden und durch den erhohten Schutz der Daten auch indirekt die Qualitat anderer Dimensionen erhohen. Insofern werden wir in weiterer Betrachtung Aspekte der Sicherheit unabhangig der rechtlichen Anforderungen mit betrachten. Ungeachtet dessen haben die DGIQ und Autoren aktueller Publikationen die Sicherheit aus den Qualitatsdimensionen und deren Umfeld komplett entfernt. Wie wir aber im Stand der Technik festgestellt haben, sind diese Modelle recht starr und un exibel gegenuber anwendungsspezi schen Szenarien. Deswegen sind wir der Meinung, dass man in gewissen Szenarien die Sicherheit als zusatzliche Dimension mitbetrachten kann. Auch wenn die DGIQ die Sicherheit als Dimension mit der Begrundung entfernt hat, dass sie zwar zu einer Qualitatssteigerung der restlichen Dimensionen fuhrt, aber als erschopfend bewertet angesehen werden sollte [ 9 ], musste man sie immer noch nebenher zu den bestehenden Dimensionen mit betrachten und nicht ganzlich aus dem Blickfeld dieser entfernen. Denn auch die Umsetzung rechtlich relevanter Sicherheitsma nahmen muss auf seine Qualitat hin uberpruft und bewertet werden.

3.2 Anwendungsspezifische Gruppen

In mehreren Arbeiten, wie auch in [ 4 ], wird davon gesprochen, dass fur jede Anwendung die Qualitat neu bewertet werden muss. Denn jedes Unternehmen und somit auch jedes Anwendungsszenario ist anders, so dass die Datenqualitat nach [ 9 ] sinnvoll umgesetzt werden muss. Allerdings bleibt es meist bei diesen Aussagen. Ein konkreter weiterfuhrender Vorschlag ist unseres Erachtens nicht eindeutig zu nden. Fur unseren Ansatz gehen wir nicht von einer strikten anwendungsunabhangigen Einordnung der Dimensionen in Kategorien aus, wie in den Qualitatsmodellen im Stand der Technik gezeigt. Eher schlagen wir vor, je nach Anwendungsszenario eigene Kategorien zu erzeugen und die Dimensionen angepasst an das Projektvorhaben einzusortieren. Die Zerlegungssemantik ist also hier sehr exibel angesetzt. Wir nutzen dazu nur die 15 von der DGIQ vorgeschlagenen Dimensionen, um eine gewisse Moglichkeit fur Vergleiche beizubehalten. Eigens de nierte Dimensionen, wie in Hinrichs Modell [ 3 ], wollen wir vermeiden, damit begri ich auf einer Ebene gearbeitet werden kann. So kann man aber z.B. eine eigene Kategorie "Referenzielle Integritat\ erzeugen, die mit bestimmten Qualitatsdimensionen durch Nutzer oder Entwicklerwunschen befullt wird. Bei dieser sehr exiblen Erstellung einer eigenen Zerlegungssemantik ist naturlich eine sehr bewusste Auswahl der Qualitatsmerkmale und dessen Einordnung in die Kategorien zu tre en. Durchaus kann es dabei vorkommen, dass einige Dimensionen gar nicht betrachtet werden, da sie fur das Vorhaben nicht relevant sind oder durch andere Dimensionen mit abgedeckt werden. Auch ist es durchaus denkbar, eine Qualitatsdimension mehreren Gruppen zuzuordnen, je nachdem, ob mehrere Kategorien ahnliche Qualitatsanforderungen besitzen.

Kategorie

DQ Dimensionen

A B C D E F G

In der Tabelle 1 haben wir exemplarisch die Dimensionen in 7 Gruppen nach einer einfachen A hnlichkeit der Begriffe der Dimensionen erstellt. Hier sind die Kategorien noch mit Buchstaben benannt, eine sinnvolle Namensgebung auf Grundlage bestimmter anwendungsszenarischer Anforderungen oder Gebiete ist naturlich moglich und erwunscht.

3.3 Skalierung

Nachdem die Dimensionen in die selbst erstellten Kategorien eingeordnet wurden, macht es Sinn, diese nach ihrer Wichtigkeit zu skalieren. Dazu kann man ihnen mehr oder weniger Punkte auf einer Skala zuordnen, um damit ihre Bedeutung in Umfang, Wichtigkeit oder praferierter Behandlung zu kennzeichnen. Eine exemplarische Skalierung haben wir in Abbildung 3) gegeben. Hier haben wir verschiedene globale Anwendungsbereiche de niert, die nach der Aufteilung aus Tabelle 1 skaliert wurden. Alle genannten Anwendungen haben die gleiche Aufteilung der Dimensionen in die Kategorien erhalten. Denkbar ist naturlich auch die individuelle Gruppenbildung bei den einzelnen Anwendungen. Fur einen ubersichtlichen Vergleich und die allgemeine Erlauterung unserer Idee ziehen wir diese Variante zunachst vor.

Die verschiedenen "System Layouts\ resultieren aus den verschiedenen Anforderungen in dessen Anwendungsgebiete. Gesetzgeber und Behorden (i) legen mehr Wert auf Vollstandigkeit, Objektivitat und erhohte Sicherheit (Gruppen E, F & G). Die strengen Anforderungen fur die Zuganglichkeit und Aktualitat sowie die Fehlerfreiheit (Gruppen A & E) im Bereich der Forschung (ii) oder der Einsatz in der alltaglichen (Berufs-)Praxis (iii), bei der das Wichtigste eine einfache Zuganglichkeit, Vollstandigkeit und Objektivitat (Gruppen A, E & F) sind, konnen ebenso abgebildet werden, wie die klare Forderungen nach einer moglichst hohen Wertschopfung (Gruppe C) aus Sicht des Management (iv) unter verringerter Berucksichtigung aller anderen Gruppen.

Die Gro e der umschlossenen Flache, die sich durch das Verbinden der Punkte auf den Kategorieachsen gebildet hat, kann ein erstes Indiz fur den mutma lichen Implementationsaufwand darstellen, den die Umsetzung des Systems verursachen wird, um allen Anforderungen an die Datenqualitat aus der Betrachtung gerecht zu werden. Zudem wird aus der gra schen Betrachtung ersichtlich, auf welche Bereiche sich der Entwickler zuerst konzentrieren sollte, da dies ja einen erhohten Arbeitsaufwand vermuten lasst.

3.4 Entwickler- und Nutzersichten

Nach [ 9 ] und [ 10 ] ist es zur Beschreibung und Bewertung von Informations- bzw. Datenqualitat wichtig, die Qualitat der Daten aus der Sicht der Nutzer zu ermitteln ( t for use Konzept). Eine weitere Quelle [ 4 ] legt der Qualitatsbewertung ein Qualitatsmodell zugrunde, dessen Subjekte (Nutzer), Pradikate (Anfrageverarbeitung) und Objekte (Datenquelle) nur ganz bestimmte Qualitatskriterien bewerten, und zwar diejenigen, die laut Autor in der Anwendung, Anfrageverarbeitung oder Datenquelle vorliegen. Es wird also uberwiegend vom Nutzer ausgegangen, der die Qualitatsanspruche an die Daten vorgibt. Allerdings musste unseres Erachtens nach auch der Entwickler, der das System erstellt und eventuell auch unterhalt, bei der Qualitatsbewertung nach unserem oben beschriebenen Vorgehen ma geblich unterstutzend mitwirken. Das wurde in der Praxis folgenderma en aussehen. Anwender und Nutzer fuhren die ersten zwei Schritte gemeinsam aus, dabei sollte der Entwickler durch seine Fachkompetenz die Richtung vorgeben. 1. Kategorien bilden Fur das anwendungsspezi sche Szenario werden Kategorien gebildet, in denen die Qualitatskriterien spater eingeordnet werden. Diese Kategorien konnen bestimmte Qualitatsaspekte der Anwendung namentlich darstellen. 2. Qualitatsdimensionen einfugen Die 15 festde nierten Dimensionen werden nach den Spezi ka der Anwendung in die Kategorien eingeordnet. 3. Skalierung der Kategorien Nutzer und Anwender bewerten die Wichtigkeit der Kategorien nach ihrem personlichen Verstandnis und ihrer Au assung gegenuber der Wichtigkeit und Praferenz der Dimensionen in den Kategorien. 4. nPernobnluenmgeeigdeenneitnianzdieerregnehBaelitdeen"Swyesrtdeemn.LGayrooutes\Dkiof-nferenzen zwischen Nutzer- und Entwicklerbewertung einzelner Kategorien identi zieren nochmalige Klarung zum Bedarf und Einsatz bestimmter Konzepte zur Qualitatsbehandlung der Daten.

Durch ein derartiges Vorgehen kann bei der Planung bzw. Anforderungsanalyse einer Anwendung in Hinblick auf den Einsatz des Qualitatsmanagements mit seinen Qualitatsdimensionen von vornherein eine anwendungsspezi sche Abstimmung zwischen Nutzer und Entwickler erfolgen. Allen Beteiligten kann dabei ein aussagekraftes Qualitatskonzept in die Hand gegeben werden.

4. ZUSAMMENFASSUNG UND SCHLUSS

FOLGERUNG

In diesem Beitrag haben wir das Feld der Datenqualitat aufgegri en und ein erstes theoretisches Konzept fur den Umgang mit Qualitatsdimensionen vorgestellt. Das generelle Ziel war es, Voraussetzungen fur eine hohe Datenqualitat zu scha en, die fur ein anwendungsspezi sches Szenario geeignet ist. Denn erst wenn die Funktionalitaten eines Softwaresystems eine, vom Nutzer und Entwickler durch Dimensionen spezi zierte, ausreichende Qualitat besitzen, ist die Funktionsfahigkeit eines IT-Systems gewahrleistet [ 9 ]. Hauptverursacher unzureichender Datenqualitat ist und bleibt der Mensch. Deshalb war es wichtig, die von uns aus ersichtlichen Unzulanglichkeiten anderer Qualitatsmodelle aufzugreifen und sie zu behandeln. Dazu haben wir die Dimension der Sicherheit als Konzept einer U bererfullung von Sicherheitsbedurfnissen uber den rechtlichen Vorgaben hinaus in unsere Betrachtungen mit einbezogen. Die Einordnung von 15 fest de nierten Dimensionen in selbst erstellte Kategorien, aus einem bestimmten Anwendungsszenario heraus, erlaubt eine Wichtung dieser durch den Nutzer und den Entwickler, um auf ein gemeinsames Qualitatslevel zu gelangen. Damit konnen Methoden und Werkzeuge in der Anforderungsanalyse bestimmt werden, die die Umsetzung der ermittelten Qualitaten gewahrleisten konnen. Fur einen spateren Soll-Ist-Vergleich konnen die Wichtungen ebenfalls als Bewertungsgrundlage herangezogen werden.

Die nachsten Schritte fur die Weiterentwicklung dieser Idee sind zunachst z.B. die U berprufung, ob eine Mehrfacheinordnung von Qualitatsdimensionen in spezielle Kategorien sinnvoll ist. Auch fur die Benennung der Kategorien nach den in jedem Anwendungsszenario unterschiedlichen Anforderungen musste der Einsatz bestimmter Reglements uberpruft werden. Um einfache anwendungsspezi sche Kategorien zu nutzen, kann der Einsatz von globalen "System Layouts\ (Szenario-Mustern) Abhilfe scha en. Auch fur die Bewertung der Qualitat im Nachhinein, also im laufenden Prozess, muss es sich zeigen ob der hier vorgestellte Ansatz dafur ausreichend Informationen bietet. Und zum Schluss steht ein genereller praktischer Einsatz noch aus.

References

[1] M. Abate , K. Diegert , and H. Allen . A hierarchical approach to improving data quality . Data Quality , 4 ( 1 ): 365 { 369 , 1998 .

[2] D. Apel , W. Behme , R. Eberlein , and C. Merighi . Datenqualita t erfolgreich steuern - Praxislosungen fur Business-Intelligence-Projekte . Carl Hanser Verlag Munchen , 2009 .

[3] H. Hinrichs . Datenqualitatsmanagement in Data Warehouse-Systemen . PhD thesis , Carl von Ossietzky-Universita t Oldenburg , 2002 .

[4] U. Leser and F. Naumann . Informationsintegration. dpunkt Verlag Heidelberg, 2007 .

[5] F. Naumann and C. Rolker . Assessment methods for information quality criteria . In Proceedings of the 2000 International Conference on Information Quality (ICIQ) , pages 148 { 162 , Cambridge, MA, 2000 .

[6] A. Ostman . The speci cation and evaluation of spatial data quality . ICA/ACI International Conference, 18 , 1997 .

[7] E. Poy . Objectives of QC systems and QA function in clinical research . Quality Assurance (San Diego, Calif.), 2 ( 4 ): 326 { 331 , Dec . 1993 .

[8] J. Rohweder , G. Kasten , D. Malzahn , A. Piro , and J. Schmid . Information quality - de nitions, dimensions and terms. http://dgiq.de/ data/pdf/IQDe nition/IQ-De nitionen.pdf, 2007 .

[9] J. Rohweder , G. Kasten , D. Malzahn , A. Piro , and J. Schmid . Daten- und Informationsqualitat. Vieweg Teubner , 2008 .

[10] R. Wang and D. Strong . Beyond accuracy: What data quality means to data consumers . Journal of Management Information Systems , 12 :5{ 33 , 1996 .