=Paper=
{{Paper
|id=None
|storemode=property
|title=Delegation von Datenmanagement in Szenarien verteilter Verantwortlichkeiten
|pdfUrl=https://ceur-ws.org/Vol-581/gvd2010_1_3.pdf
|volume=Vol-581
|dblpUrl=https://dblp.org/rec/conf/gvd/Stuber10
}}
==Delegation von Datenmanagement in Szenarien verteilter Verantwortlichkeiten==
https://ceur-ws.org/Vol-581/gvd2010_1_3.pdf
Delegation von Datenmanagement in Szenarien verteilter
Verantwortlichkeiten
Ralph Stuber
OFFIS Institut für Informatik
Escherweg 2
26121 Oldenburg
+49 441 9722 141
stuber@offis.de
ABSTRACT Teilbereiche der umfangreichen Datenbestände benötigen,
Um Daten aus verschiedenen Datenbeständen miteinander in gewinnt die Generierung verschiedener Sichten auf einzelne
Verbindung bringen und daraus zusätzliche Informationen Datenbereiche zunehmend an Bedeutung [1].
gewinnen zu können, werden diese oftmals aus verschiedenen Integrierte Datenbestände
Quellen heraus in einem gemeinsamen Datenbestand integriert. In
Fällen, in denen die Personen oder Institutionen, die die Weiter existieren Datenbestände über die Grenzen von
Quelldaten erzeugt haben und verantworten, nicht in den Prozess Unternehmen oder Institutionen hinaus, die sich über gemeinsame
der Erstellung und Nutzung integrierter Datenbestände Dimensionen oder Attribute miteinander verknüpfen lassen. Um
eingebunden werden, erhalten diese erst nach Veröffentlichung das Potential der in den verschiedenen Datenbeständen
des Datenbestandes Einsicht in die Daten und können somit vorliegenden Informationen nutzen zu können, werden derartige
Änderungs- und Korrekturwünsche an den Quelldaten nicht in Datenbestände oftmals aus verschiedenen Quellen unter Einsatz
den vorgelagerten Integrationsprozess einbringen. So resultiert von Data Warehouse-Technologien [2] integriert und so in einem
aus dem Erfordernis der Durchführung von Datenänderungen gemeinsamen Datenbestand zusammengeführt (Datenintegration).
aufgrund von Aktualisierungen oder Korrekturen von Institutionen und Unternehmen unterschiedlicher Branchen
Informationen der Bedarf des Delegierens von Datenpflege- nutzen die Möglichkeit, die auf diese Weise zusammengetragenen
Prozessen, welche es den Datenverantwortlichen ermöglicht, von Kennzahlen, Leistungsdaten und anderen Strukturinformationen
ihnen verantwortete Daten im Zielsystem integrationsnachgelagert zu verschiedenen Zwecken zu nutzen. So können integrierte
zu pflegen und ggf. zu aktualisieren. Datenbestände für Analysen zum Zwecke der Unterstützung in
Management-Entscheidungen genutzt werden, oder z.B. zur
Zur Lösung des Problems wird im Rahmen dieses Beitrages das Präsentation von Produkten, Dienstleistungen und
Vorgehensmodell VD2M (Vorgehensmodell zur Delegation von Unternehmensstatistiken in aufbereiteter Form beispielsweise über
Datenmanagement) vorgestellt, welches das angesprochene das World Wide Web.
Delegieren von Datenmanagement unter Berücksichtigung
verteilter Verantwortlichkeiten ermöglicht. Am Beispiel eines Verteilte Verantwortlichkeiten
Projektes aus dem Gesundheitswesen wird dargestellt, wie das Grundsätzlich können die Rollen Datenurheber und
Vorgehensmodell anschließend durch den Einsatz der Datenverwalter unterschieden werden. Nicht zwingend werden
prototypisch implementierten Softwarewerkzeug-Sammlung beide Rollen durch ein und dieselbe Person oder Institution
WD2M (Werkzeuge zur Delegation von Datenmanagement) wahrgenommen. Weisen verschiedene Datenquellen, die den
umgesetzt und evaluiert werden kann. integrierten Datenbeständen als Basis zugrunde liegen können,
eine Urheberschaft durch verschiedene Daten verantwortliche
Keywords Personen auf, so lassen sich Szenarien verteilter
Delegation, Datenmanagement, integrationsnachgelagerte Verantwortlichkeiten beobachten.
Datenänderungen, Verantwortlichkeiten, Schreibender Zugriff auf
In solchen Situationen, in denen Datenurheber und
Data Warehouses.
Datenverwalter verschiedene Personen oder Institutionen sind,
werden die Datenurheber, die die Quelldaten verantworten, selten
1. Einführung und Motivation in den Prozess der Erstellung oben beschriebener Datenbestände
Die meisten Unternehmen, Institutionen, Verbände und durch Dritte eingebunden. Sie erhalten daher erst nach
andere Organisationen verfügen über eine Vielzahl an Veröffentlichung des integrierten Datenbestandes die Möglichkeit
verschiedenen Datenbeständen. Diese wachsen zum einen stetig zur Einsicht, und haben somit meist keine Möglichkeit,
quantitativ bezüglich der jeweils enthaltenen Datenmengen, zum Änderungs- und Korrekturwünsche an den Quelldaten in den
anderen jedoch meist auch qualitativ in der Komplexität und der vorgelagerten Integrationsprozess einzubringen. Der Bedarf an
Anzahl verschiedener, durch die Daten abgebildeter Entitäten und integrationsnachgelagerten Datenänderungen entsteht. Weiter ist
Beziehungen. insbesondere zu beachten, dass die Personen, die die Daten aus
den Quellen der Integration verantworten, selten über detaillierte
Da unterschiedliche Nutzerkreise oder Interessenten
aufgrund stetig wachsender Datenmengen oftmals nur Zugriff auf
Kenntnis der Struktur des zugrunde liegenden Datenmodells und Manipulationen am Datenbestand zu einem späteren Zeitpunkt
Datenbankschemas verfügen. nachvollziehen zu können, da die Daten nicht zeitbezogen
getrennt abgelegt, sondern überschrieben werden, und somit die
Integrationsnachgelagerte Datenänderungen
ursprüngliche Belegung nach Durchführung einer Manipulation
Unterliegen Datenquellen stetigen Veränderungen, so verloren geht.
erscheint die Durchführung der Datenänderungen in der
Redundante Systeme zur Wartung mehrerer Datenbestände
Datenquelle - sofern möglich - meist sinnvoller als die Korrektur
des betroffenen Datums im integrierten Datenbestand. Darüber hinaus existieren auf Seiten eines Datenintegrators
Manipulierte Datensätze können dann unter erneuter oftmals mehrere heterogene, voneinander unabhängige und
Durchführung der Datenintegration in den integrierten inhaltlich disjunkte Datenbestände, die für verschiedene Projekte
Datenbestand übernommen werden. Wird die Korrektur auf dem und Auftraggeber gepflegt und gewartet werden müssen. Die
integrierten Datenbestand ausgeführt, so würde diese bei erneuter Entwicklung maßgeschneiderter, individueller Lösungen zur
Integration der betroffenen Daten aus der ursprünglichen Quelle Wartung und Anpassung der verschiedenen Datenbestände birgt
verloren gehen. Um Korrekturen auf den Datenquellen den Nachteil des Bedarfs an mehreren, in weiten Teilen
durchführen zu können, ist jedoch auch Kenntnis über die redundanten Lösungen. Im Vergleich zum Einsatz einer
Herkunft der im integrierten Datenbestand enthaltenen generischen Lösung kann dies im Hinblick auf den zu
Informationen erforderlich. investierenden Entwicklungsaufwand ineffizient erscheinen,
sofern durch die redundante Umsetzung identischer Aufgaben
In Fällen, in denen die Datenquellen jedoch keinen stetigen
vermeidbare Kosten entstehen.
Veränderungen unterliegen, erweist sich hingegen eine einmalige
Integrationsstrategie zur Erstellung eines integrierten Abgeleiteter Bedarf
Datenbestandes meist als sinnvoll. Die Durchführung der
So resultiert aus der Anforderung der Durchführung von
Integrationsprozesse ist bedingt durch die integrationsinhärenten
Datenänderungen am integrierten Datenbestand in Szenarien
Schritte der Beschaffung, Bereinigung, Aufbereitung und
verteilter Verantwortlichkeiten der Bedarf an einem
Vereinheitlichung der Daten zudem aufwändig gestaltet. Im
Vorgehensmodell, welches es den Datenverantwortlichen, also
Hinblick auf solche statischen Datenquellen, erscheint daher der
den ursprünglichen Urhebern und Verantwortungsträgern der
herkömmliche Weg des Data Warehousing, eine Durchführung
der Korrekturen in den Quelldatenbeständen und eine Daten aus den Quelldatenbeständen, ermöglicht, eine
Manipulation oder Aktualisierung der von ihnen verantworteten
anschließende erneute, aufwändige Integration der nur
Daten zu initiieren. Dabei ist insbesondere zu beachten, dass
geringfügig korrigierten Quelldaten durchzuführen, meist nicht
Datenverantwortliche selten über detaillierte Kenntnis der
verhältnismäßig in Bezug auf den zu investierenden Aufwand.
Struktur des zugrunde liegenden Datenmodells und
Vielmehr ist hier die Korrektur direkt am integrierten
Datenbankschemas des integrierten Datenbestandes verfügen, und
Datenbestand naheliegend und sinnvoll.
zudem nur in Ausnahmefällen in dessen Prozess der Erstellung
Zudem existieren integrierte Datenbestände, die Abzüge der eingebunden waren.
zugrunde liegenden Datenquellen zu bestimmten Zeitpunkten
beinhalten. Sollte ein Datenfehler nun der Integration
nachgelagert im integrierten Datenbestand identifiziert werden, so
ist nicht sichergestellt, dass die Änderung in der Datenquelle
durchführbar ist, da dort das integrierte Datum gegebenenfalls
nicht mehr vorgehalten wird [3]. Eine Änderung im integrierten
Datenbestand ist in solchen Fällen alternativlos.
Auch der Umstand, dass die integrierten Daten oftmals nicht
mit Metainformationen zur ursprünglichen Quelle annotiert sind,
erschwert eine nachträgliche Korrektur in den Quellsystemen.
Ohne Wissen über die Herkunft von Daten (Data Provenance [4]),
ist es nicht möglich, die Quelle zu identifizieren und eine
Manipulation auf dem Quelldatenbestand auszuführen. In diesen
Fällen können Korrekturen oder Manipulationen ebenfalls nur am
integrierten Datenbestand vorgenommen werden.
Temporale Aspekte
Ein weiteres Problem, welches sich im Kontext der zuvor Abbildung 1: Bedarf an integrationsnachgelagertem
motivierten Integration verschiedenartiger Quelldatenbestände Datenmanagement unter verteilten Verantwortlichkeiten
häufig beobachten lässt, besteht darin, dass die resultierenden Abbildung 1 zeigt ein beispielhaftes Szenario, in dem ein
integrierten Datenbestände oftmals als einfache relationale Dienstleister die Inhalte dreier Datenquellen integriert und die
Schemata (sog. Snapshot-Datenbanken [5]) aufgebaut werden, die Ergebnisse der Öffentlichkeit zur Verfügung stellt. Der Urheber
keinerlei Voraussetzungen hinsichtlich temporaler Aspekte [6,7], der Datenquelle A identifiziert einen Datenmanipulationswunsch,
also der Annotation der Realdaten mit einem der erst integrationsnachgelagert an den Betreiber des integrierten
Transaktionszeitbezug [6], aufweisen. So ist es ohne die Existenz Datenbestandes übermittelt werden kann.
temporaler Annotationen nicht möglich, durchgeführte
2. Problemstellung, Anforderungen und 3. Vorgehensmodell VD2M
Lösungsansatz Zur Lösung der in Abschnitt 2 beschriebenen
Motiviert aus den in Abschnitt 1 aufgezeigten Umständen lässt Problemstellung wird das Vorgehensmodell VD2M
sich folgende Problemstellung formulieren: vorgeschlagen, welches die Delegation von Datenmanagement-
Anforderungen in Szenarien verteilter Verantwortlichkeiten
Ist eine Delegation von Datenmanagement in Szenarien ermöglicht, und dabei die in Abschnitt 2 formulierten
verteilter Verantwortlichkeiten unter Berücksichtigung von Anforderungen (z.B. die Gewährleistung von Nachvollziehbarkeit
Nachvollziehbarkeit der Änderungen durch Einsatz eines und Reversibilität der Datenmanipulationen oder die
generischen Vorgehensmodells möglich? Anpassbarkeit an verschiedene Datenbestände oder an strukturelle
Zur Beantwortung dieser Fragestellung besteht die Änderungen des integrierten Datenbestandes unter Investition
Grundidee des vorgestellten Ansatzes in der Schaffung eines möglichst geringer Aufwände) erfüllt.
Vorgehensmodells, welches das Datenmanagement in Szenarien VD2M besteht aus zwei Gruppen von Phasen: initiale
verteilter Verantwortlichkeiten unter Berücksichtigung der Phasen und Phasen des Regelbetriebs. Die initialen Phasen
Historisierung der Dateninstanzen ermöglicht. Basierend auf den resultieren aus der Anforderung der einfachen Anpassbarkeit an
in Abschnitt 1 dargestellten Beobachtungen und Umständen verschiedene Einsatzszenarien und sind einmalig für jeden
werden verschiedene Anforderungen an das Vorgehensmodell integrierten Datenbestand auszuführen, auf dem später
abgeleitet, die im Folgenden aufgelistet seien: Datenmanagement-Schritte durchgeführt werden sollen (folgend
auch als „Anwendungsdatenbestand“ bezeichnet). Sie umfassen
• Das Datenmanagement muss durch Datenurheber
alle Aktivitäten und Aufgaben, die zur einmaligen, initialen
initiierbar sein, da dieser die Datenmanagement-Bedarfe
Konfiguration der Werkzeuge anfallen. Als Ergebnis entsteht nach
identifiziert und deren Umsetzung fordert.
Ausführung der initialen Phasen ein konfiguriertes System, auf
• Potentielle Datenmanipulationen müssen auch von „Nicht- Basis dessen in den wiederkehrenden Phasen dann die
IT-Experten“ und insbesondere ohne Detailkenntnis der Datenmanagement-Aktivitäten auf dem Anwendungsdatenbestand
Strukturen des zugrunde liegenden Datenbankschemas ausgeführt werden können.
möglich sein, da die Urheber der Datenquelle in der Regel
nicht über derartige Detailkenntnisse verfügen. 3.1 Initiale Phasen
• Alle Datenmanipulationen, die durchgeführt werden, Im Rahmen der initialen Phasen bedarf es zunächst der
müssen umfassend dokumentiert werden und zu späteren Erhebung einiger Metainformationen über den zu verwaltenden
Zeitpunkten nachvollziehbar sein, um ggf. auch Anwendungsdatenbestand, um:
zurückgenommen werden zu können (Reversibilität). • eine Historisierungsinfrastruktur zur automatisierten
• Das Vorgehensmodell soll weitestgehend generisch auf Historisierung der zu manipulierenden Daten zum Zwecke
beliebige, unterschiedliche relationale Datenbestände der Schaffung von Nachvollziehbarkeit und Reversibilität
anwendbar sein, um individuelle Entwicklungen für sowie
verschiedene Datenbestände und damit verbundene • einen Suchindex zum Auffinden von Relationen und
Redundanzen in der Umsetzung der Lösungen zu Attributen im Datenmodell anhand von
vermeiden. natürlichsprachlicher Beschreibungen von Realwelt-
• Die Phasen des Vorgehensmodells sollen durch eine Entitäten
Sammlung von Softwarewerkzeugen unterstützt umgesetzt für einen spezifischen Anwendungsdatenbestand erzeugen zu
werden, um im Kontext eines realen Projektes im können. Folgende initiale Phasen 1-3 lassen sich identifizieren:
Praxisbetrieb unter realistischen Bedingungen evaluiert
werden zu können. 1. Quellenanalyse: Erhebung von Metainformationen
aus Struktur und Inhalt des integrierten
• Aspekte struktureller Veränderungen der zugrunde Datenbestandes zur Vorbereitung der Generierung
liegenden Datenbankschemata sollen bei Entwurf und von Suchindex und Historisierungs-Infrastruktur.
Umsetzung von Vorgehensmodell und unterstützender
Werkzeugsammlung berücksichtigt werden; damit die 2. Infrastruktur-Generierung: Automatisierte
jeweilige Umsetzung des Ansatzes hinsichtlich potentieller Erzeugung der Infrastruktur zur Historisierung der
Änderungen oder Erweiterungen des Datenschemas ohne zu manipulierenden Daten auf Basis der in der
hohen Aufwand angepasst werden kann. vorigen Phase generierten Informationen.
3. Suchindex-Generierung: Semantische Indexierung
• Das Datenmanagement (insbesondere das Auffinden der
des integrierten Datenbestandes durch
modellierenden Struktur sowie die Spezifikation der zu
teilautomatisiertes Vorgehen: automatisierte Analyse
manipulierenden Dateninstanz) muss auf Grundlage von
der Struktur unter Extraktion der enthaltenen
natürlichsprachlichen Beschreibungen der modellierten
Informationen (Attribut- und Relationennamen,
Realwelt-Entitäten ermöglicht werden, da dem Urheber der
Kommentartexte, sonstige Informationen) und
Daten in Szenarien verteilter Verantwortlichkeiten nur
Erzeugung eines Suchindexes auf Basis der
diese, und nicht die Modellstruktur eines integrierten
extrahierten Strukturinformationen, und manuelle
Datenbestandes bekannt ist.
Anreicherung des Suchindexes durch Fachexperten
um Verschlagwortungen der im integrierten Durch das Durchlaufen der initialen Phasen erfolgt eine
Datenbestand abgebildeten Domäne, um eine Anpassung des zur Umsetzung des Vorgehensmodells
Stichwortsuche unter Nutzung von beschreibenden implementierten Systems an den integrierten Datenbestand. Die
Stichworten einer Realwelt-Entität zum Auffinden Infrastruktur zur automatisierten Historisierung sowie der
des Speicherortes im Datenmodell zu ermöglichen. Suchindex zur Abbildung der Realwelt-Entitäten auf die
modellierten Strukturen des integrierten Datenbestandes werden
im Rahmen der initialen Phasen auf Basis der individuellen
3.2 Phasen des Regelbetriebs
Eigenschaften des integrierten Datenbestandes erzeugt.
Neben den drei initialen Phasen, die nur einmalig zur
Anpassung an einen Anwendungsdatenbestand ausgeführt werden In der Phase des assistierten Datenmanagements erfolgt
müssen, sind wiederkehrende Phasen zu identifizieren. Sie anschließend im Rahmen des Regelbetriebs eine automatisierte
umfassen die zum eigentlichen Datenmanagement erforderlichen Historisierung von Original-Belegungen der Daten. Zudem bietet
Aktivitäten und Aufgaben und sollen den Prozess des die Phase Unterstützung bei der Lokalisierung der modellierten
Datenmanagements umsetzen und dokumentieren. Zudem sind im Strukturen im Anwendungsdatenbestand unter Nutzung des für
Falle von Änderungen am Anwendungsdatenbestand den Anwendungsdatenbestand spezifisch und individuell
Reorganisationsschritte erforderlich, um die Anpassungen, die am erzeugten Suchindexes. Unter Nutzung von Historisierung der
Anwendungsdatenbestand durchgeführt wurden, auch zugrunde Manipulationen und Dokumentation der durchgeführten Schritte
liegende System zu propagieren. Folgende wiederkehrende sind Nachvollziehbarkeit und Reversibilität der durchgeführten
Phasen 4-6 können im Regelbetrieb identifiziert werden: Datenmanipulationsschritte gewährleistet.
4. Assistiertes Datenmanagement: Durchführung von Für den Fall einer strukturellen Veränderung des integrierten
assistiertem Datenmanagement mitsamt Datenbestandes bietet die Phase der Reorganisation die
Historisierung von ursprünglichen Belegungen im Möglichkeit, unter Erhalt der bestehenden Informationen aus
Anwendungsdatenbestand. Historisierungsinfrastruktur und Suchindex die Generierung eines
an die Strukturveränderungen angepassten Suchindexes und einer
5. Dokumentation: Dokumentation der durchgeführten
angepassten Historisierungsinfrastruktur umzusetzen.
Schritte zum Datenmanagement
(Datenmanipulationen und Datenpflege) im
Anwendungsdatenbestand. 3.3 Evaluation
Um die Eignung des vorgeschlagenen Vorgehensmodells
6. Reorganisation: Erweiterung/Anpassung des
VD2M zu evaluieren, werden die Phasen des Vorgehensmodells
bestehenden Suchindexes an strukturelle
VD2M durch eine prototypisch implementierte
Änderungen im Anwendungsdatenbestand analog zu
Werkzeugsammlung WD2M (Werkzeuge zur Delegation von
den initialen Phasen, jedoch unter Erhalt manuell
Datenmanagement) umgesetzt.
hinzugefügter Informationen.
Aufgaben, die von WD2M zu unterstützen sind, bestehen
Abbildung 2 zeigt zusammengefasst eine grafische
zunächst in der Umsetzung der initialen Phasen zur Anpassung
Darstellung der initialen und wiederkehrenden Phasen des
des Systems, deren Kern in der strukturellen Analyse des zu
Vorgehensmodells in UML-Notation.
verwaltenden integrierten Datenbestandes besteht. Die dabei
akquirierten Informationen dienen zum einen dem Aufbau des
Suchindexes, in dem die Strukturen des Datenmodells um
semantische Realwelt-Information annotiert werden, damit der Ort
der Speicherung der gesuchten Information im Datenmodell (also
der modellierenden Relation sowie deren Attributen) anhand von
natürlichsprachlicher Stichwortsuche identifiziert werden kann.
Zum anderen dienen die Ergebnisse der strukturellen Analyse dem
Aufbau einer Historisierungsinfrastruktur, die die zeitbehaftete
Speicherung der zu manipulierenden Datentupel ermöglicht, um
Nahvollziehbarkeit und Reversibilität der Datenänderungen zu
gewährleisten.
Auch die Schritte der wiederkehrenden Phasen von VD2M
sind durch WD2M zu unterstützen und umzusetzen. Die primäre
Aufgabe besteht in der Umsetzung des assistierten
Datenmanagements, welches mehrere Aufgaben umfasst:
• Identifikation des Ortes der Speicherung der zu
manipulierenden Information unter Nutzung des
Suchindexes (also das Auffinden der zu referenzierenden
Relation bzw. des darin enthaltenen Attributs, welches die
zu manipulierende Information modelliert).
Abbildung 2: Das Vorgehensmodell VD2M
• Spezifikation der zu manipulierenden Dateninstanz (also Szenarien verteilter Verantwortlichkeiten erfolgen kann. Zunächst
des zu ändernden Tupels) anhand von wurde der Bedarf an integrationsnachgelagerten
instanzbeschreibenden Informationen. Datenmanagement-Schritten in Szenarien verteilter
Verantwortlichkeiten motiviert. Anschließend erfolgte die
• Editierbare Anzeige der aktuellen Tupelbelegung für zuvor Präzisierung der Problemstellung. Als Lösungsansatz wurde das
spezifizierte Relation und Dateninstanz. Vorgehensmodell VD2M vorgeschlagen, dessen Phasen und
• Automatisierte Historisierung der ursprünglichen Schritte vorgestellt wurden. Abschließend erfolgte die
Tupelbelegung und Annotation eines Zeitstempels zur Beschreibung eines Evaluationsszenarios, welches unter Einsatz
Schaffung von Nachvollziehbarkeit und Reversibilität der der prototypisch implementierten Werkzeugsammlung WD2M
Datenmanipulation. quantitative und qualitative Aussagen über die Eignung des
Ansatzes ermöglicht.
• Validierung und Speicherung des manipulierten
Datentupels. Durch den Einsatz des Vorgehensmodells VD2M ist die
Delegation von Datenmanagement in Szenarien verteilter
Weiter muss WD2M die Dokumentation aller benannten Verantwortlichkeiten unter Berücksichtigung der formulierten
Schritte, aller getätigten Eingaben sowie der Manipulationen des Anforderungen, dass das Datenmanagement durch den
Datenbestandes gewährleisten, um den eingangs benannten Datenurheber initiierbar ist und von Nicht-IT-Experten auf Basis
Anforderungen nachkommen zu können. Schließlich muss die von natürlichsprachlicher Beschreibung von Realwelt-Entitäten
Funktionalität zur Reorganisation von Suchindex und durchgeführt werden kann, möglich. Die durch VD2M/WD2M
Historisierungsinfrastruktur umgesetzt werden, damit auf durchgeführten Datenmanagement-Aktivitäten sind aufgrund der
strukturelle Änderungen des zugrunde liegenden integrierten automatisierten Historisierung der Originalbelegungen und der
Datenbestands reagiert werden kann, die im Laufe der Zeit vor Dokumentation des Gesamtprozesses vollständig nachvollziehbar
dem Hintergrund von Schemaevolution und Schemaversionierung und reversibel. Weiter sieht das Vorgehensmodell strukturelle
auftreten können. Entwicklungen in Datenbeständen vor und kann entsprechend
angepasst werden. VD2M kann durch Umsetzung der initialen
Die Evaluation der Werkzeuge wird im Kontext eines
Phasen weitestgehend generisch auf beliebige Datenbestände
Projektes im Umfeld des Gesundheitswesens erfolgen. Das
angewandt werden.
Projekt betreut einen integrierten Datenbestand, auf dem ein Web-
Portal aufbaut, welches die Inhalte den Benutzern strukturiert
aufbereitet zur Einsicht zur Verfügung stellt. Die Quellen, aus 5. Literatur
denen sich der integrierte Datenbestand speist, umfassen sowohl [1] Bauer, A. and Günzel, H. 2001. Data Warehouse Systeme.
strukturierte Informationen im XML-Format als auch Daten, die Architektur, Entwicklung, Anwendung. Dpunkt Verlag.
per Web-Formular direkt über das angebundene Portal erhoben ISBN 3932588762.
werden. Im Projekt liegen dahingehend verteilte [2] Inmon, William H. 1992. Building the Data Warehouse. John
Verantwortlichkeiten vor, als dass unterschiedliche Rollen, Wiley & Sons, Inc., New York, NY, USA. ISBN
Urheberschaften und Interessen in den Bereichen Quelleninhalte, 0471569607.
Betrieb des integrierten Datenbestandes sowie Darstellung der
Daten im Web-Portal identifiziert werden können. [3] Zeh, T. 2003. „Data Warehousing als Organisationskonzept
des Datenmanagements: Eine kritische Betrachtung der Data-
Der Einsatz von WD2M im Kontext des Projektes soll es Warehouse-Definition von Inmon“, Inform., Forsch.
dem Betreiber des integrierten Datenbestandes ermöglichen, Entwickl.,Volume 18 , Nummer 1, 32-38.
integrationsnachgelagerte Datenmanagement-Anfragen auf Basis
[4] Buneman, P., Khanna, S. and Tan, W. C. 2000. “Data
natürlichsprachlicher Beschreibung der modellierten Realwelt-
Provenance: Some Basic Issues”, FSTTCS, 87-93.
Entitäten durchführen zu können. Durch die Vorgabe einer Menge
exemplarischer, unterschiedlicher Manipulationsanfragen kann im [5] Stock, S. 2001. “Zeitbezogene Erweiterung des relationalen
Rahmen einer Studie erhoben werden, inwieweit die Datenmodells“, Wirtsschaftsstudium, Vol. 30, Nummer 6,
vorgeschlagenen Konzepte des Vorgehensmodells und deren 843-852.
Umsetzungen in Form der Werkzeuge WD2M zur Lösung der [6] Snodgrass, R. T. and Ahn, I. 1985. “A Taxonomy of Time in
Problemstellung beitragen, d.h. ganz konkret, welche Quote von Databases “, Proceedings of the 1985 ACM SIGMOD
Anfragen unter Nutzung von VD2M/WD2M erfolgreich International Conference on Management of Data, Austin,
bearbeitet werden kann. Texas, May 28-31, 1985, 236-246. ACM Press, New York.
[7] Harren, A. 2004. Temporale Datenintegration in Data-
4. Zusammenfassung und Fazit Warehouse-Systemen. dissertation.de - Verl. im Internet,
In diesem Beitrag wurde ein Lösungsansatz für die Frage ISBN 3-89825-868-8.
vorgestellt, wie eine Delegation von Datenmanagement in