Archivar_1_10

Embed Size (px)

DESCRIPTION

Zeitschrift für Archivwesen

Citation preview

  • 4ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    EDITORIAL 5

    AUFSTZE 6

    R. Dssler / K. Schwarz Archivierung und dauerhafte Nutzung vonDatenbankinhalten aus Fachverfahren 6

    Chr. Keitel Digitale Archivierung beim Landesarchiv Baden-Wrttemberg 19

    St. Schwalm Elektronisch signierte Dokumente im Zwischen- und Endarchiv 27

    Ch. Vancoppenolle Der Fonds der unter Zwangsverwaltung gestelltenBestnde 35

    ARCHIVTHEORIE UND PRAXIS 44Das Archivwesen der Russischen Fderation. Ergebnisse und Probleme Das ArchivwesenWeirusslands. Voraussetzungen Was hat der Mensch dem Menschen greres zu geben,als Wahrheit? Zur Grndung des Reichsarchivs vor 90 Jahren in Potsdam Erschlieungs-informationen im Internet. Empfehlungen zur Weiterentwicklung der Prsentation im Netz Die Ver-Messung der Welt zur Lagerung und Restaurierung von Karten in Archiven Mikro-historie aus lokalen und regionalen Archiven. 69. Fachtagung rheinland-pflzischer und saar-lndischer Archivarinnen und Archivare am 11. Mai 2009 6. Bayerischer Archivtag 2009 inKaufbeuren: Kompetenzzentrum Archiv. Die Archive in der vernetzten Welt 4. WorkshopArchive von unten Documentary Heritage Management in the Digital Age: Beauty and theBeast. The 20th Bi-Annual East and Southern Africa Region Branch of the International Coun-cil on Archives (ESARBICA) General Conference in Windhoek 5. Nationaler Aktionstag derAllianz fr die Erhaltung des schriftlichen Kulturguts Auch fr Archivare von Interesse... Bericht ber den 61. Deutschen Genealogentag 19. Internationaler Archivtag des IIAS inTriest

    LITERATURBERICHTE 78

    MITTEILUNGEN UND BEITRGE DES LANDESARCHIVS NRW 96

    Das Archivierungsmodell Justiz des Landesarchivs Nordrhein-Westfalen.Work in progress: Konzept und Stand der Archivierungsmodelle im Landes-archiv NRW 96

    Ein Jahr Personenstandsgesetz (PStG) Erfahrungen aus NRW 102

    Neuauflage der Bestndebersicht in der Abteilung Westfalen des Landes-archivs NRW 105

    Archives and Libraries: From Memory of the Past to the Web.Internationale Tagung in Cagliari 25./26.11.2009 107

    MITTEILUNGEN UND BEITRGE DES VdA 109

    Archive im Digitalen Zeitalter 79. Deutscher Archivtag 2009 109

    Gemeinsame Arbeitssitzung 113

    Berichte zu den Sitzung der Fachgruppen 115

    Berichte der Arbeitskreise in der Mitgliederversammlung 121

    Dem Verborgenen auf der Spur 125

    PERSONALNACHRICHTEN 126

    NACHRUFE 130

    KURZINFORMATIONEN UND VERSCHIEDENES 131

    VORSCHAU/IMPRESSUM 132

    INHALT

  • 5ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    EDITORIALLLiieebbee LLeesseerriinnnneenn uunndd LLeesseerr,, lliieebbee KKoolllleeggiinnnneenn uunndd KKoolllleeggeenn,,

    Die Entscheidung fr ein Themenheft zur digitalen Archivierung bedarf eigentlich keiner besonderen Rechtfer-tigung. Die dauerhafte Sicherung und Zugnglichmachung elektronischer Unterlagen ist eine der dringendstenAufgaben der Archive. ber die Entwicklung von Konzepten fr die digitale Langzeitarchivierung wird seit spte-stens Mitte der 1990er Jahre in der Fachgemeinschaft intensiv diskutiert. Neben zahlreichen Handreichungen undDarstellungen liegt mittlerweile mit dem OAIS-Referenzmodell ein Standard vor, der (erstaunlich schnell) weltweitals verbindliche Grundlage fr die digitale Archivierung Akzeptanz gefunden hat. Die Archive stehen nunmehr vorder groen Aufgabe, diesen Standard in funktionierende Verfahren und technische Systeme umzusetzen. DieBeitrge des vorliegenden Heftes illustrieren exemplarisch den aktuellen Stand dieser Entwicklung. Sie zeugen vonden Fortschritten, die in den letzten fnf bis zehn Jahren auf dem Weg von der Theorie zur Praxis digitaler Archi-vierung gemacht wurden. Die Zahl der Archive, die tatschlich in der Lage sind, digitale Unterlagen zu berneh-men, nimmt zu; ebenso wchst die Bandbreite digitaler Archivlsungen, die inzwischen auch disparate undkomplexe Daten aus Verwaltungssystemen und -anwendungen bernehmen knnen. Allerdings sind die Problemenach wie vor gro. Die Beispiele aus dem Landesarchiv Baden-Wrttemberg und das von der FH Potsdam initiier-te Projekt zur Datenbankarchivierung zeigen, dass groe technische, aber auch finanzielle und personelle Ressour-cen fr den Aufbau und den Betrieb der vorerst meist prototypischen Archivierungssysteme ntig sind. Schon jetztist absehbar, dass die Aufwnde der Archive in erheblichem Mae noch ansteigen werden, sobald sich die Da-tenmengen im Echtbetrieb der Systeme vervielfachen. Und dabei hlt gleichzeitig in den Verwaltungen der Trendzur Intensivierung und Ausdifferenzierung elektronischer Informations- und Kommunikationsmglichkeiten(nicht zuletzt im Zeichen von Web 2.0) weiter an. Technische Grenzen, die zu einer Verlangsamung der Entwick-lung fhren knnten, sind bis auf Weiteres nicht absehbar. Angesichts dieser Entwicklung muss insbesondere derPolitik klar sein, dass die Archive mit ihrer gegenwrtigen Ausstattung kaum eine Chance haben, die Archivierungdigitaler Unterlagen in groem Stil und auf dem zu Recht angestrebten hohen fachlichen Niveau zu leisten. Siebrauchen mehr und auch informationstechnisch geschultes Personal; und sie mssen darber hinaus ihre Kompe-tenzen und Kapazitten in den Kernaufgaben der Bewertung und Erschlieung an die Bedingungen einer sichverstetigenden elektronischen Informationsexplosion anpassen. Dabei werden fr die Archive einige Aufgaben, dieaus der analogen Schriftgutproduktion resultieren wie die Bewertung , noch viele Jahrzehnte zu erledigen sein,andere wie die Bestandserhaltung von Papier und Pergament berhaupt nicht wegfallen.

    Wir hoffen, dass das vorliegende Themenheft aktuelle und anregende Einblicke in die Anstze der elektronischenLangzeitarchivierung bietet; das Thema wird sicher auch weiterhin im Archivar einen besonderen Stellenwertbesitzen.

    Jenseits des Themenschwerpunkts haben wir wieder versucht, ber ein mglichst breites Spektrum neuer Ent-wicklungen, Projekte und Tagungen im Archivwesen zu informieren. In loser Anknpfung an die Tradition derAuslandsberichte enthlt das Heft mit den Beitrgen von Hermann Schreyer und Ragna Boden einen kleinenosteuropischen Nebenschwerpunkt; er skizziert die gegenwrtige Situation des russischen und weirussischenArchivwesens in einer Spannung zwischen ffnung und kritischer Selbstreflexion einerseits und Tendenzen zueiner nationalen Abschottung andererseits. Der Blick ber den deutschen Tellerrand ist sowohl fr den internatio-nalen Austausch der archivischen Fachgemeinschaft als auch fr die Nutzer von Archiven wichtig und hilfreich.Die Zeitschrift Archivar wird weiterhin bemht sein, eine internationale Perspektive zu pflegen, nicht zuletztauch durch Berichte ber auslndische Tagungen und Archivliteratur.

    Schlielich noch ein praktischer Hinweis in eigener Sache: Wiederholt erreichen die Redaktion Anfragen nachdem Jahresinhaltsverzeichnis des Archivar. Dieses Jahresinhaltsverzeichnis erscheint seit 2008 nicht mehr ingedruckter Form. Es wird aber weiterhin erstellt und kann ber die Internetseite der Zeitschrift(www.archive.nrw.de/archivar/) als PDF-Datei heruntergeladen und ausgedruckt werden.

    Herzlichst, Andreas Pilger in Verbindung mit Michael Diefenbacher,

    Clemens Rehm, Wilfried Reininghaus, Ulrich Sonius und Martina Wiech

  • 6 AUFSTZE

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    6

    ARCHIVIERUNG UNDDAUERHAFTE NUTZUNGVON DATENBANKINHALTENAUS FACHVERFAHREN EINE NEUEHERAUSFORDERUNG FRDIE DIGITALEARCHIVIERUNG

    von Rolf Dssler und KarinSchwarz

    Der Einsatz von Informationstechnologien in der ffentlichenVerwaltung und den Wirtschaftsunternehmen erfolgt bekanntlichin grerem Umfang seit den 1960er Jahren. E-Government-Initiativen auf allen Verwaltungsebenen fhrten in den vergan-genen Jahren dazu, dass die elektronische Datenverarbeitung inihren verschiedensten Formen mittlerweile zum Broalltaggehrt. Auch wenn die elektronische Akte bisher in vielenBehrden und Unternehmen noch nicht real ist und die Nachvoll-ziehbarkeit des Verwaltungshandelns ber die Papierakte gesi-chert zu sein scheint, existiert eine groe Zahl fachspezifischerIT-Anwendungen, die das Verwaltungshandeln durch eine teilau-tomatisierte Sachbearbeitung erleichtern sollen. Registratur- undInformationssysteme, elektronische Register, Buchungs-und andere Systeme untersttzen den Bearbeitungsprozess einerspezifischen fachlichen Aufgabe und werden unter dem Begriffder Fachverfahren1 subsumiert. Die informationstechnischeGrundlage dieser Fachverfahren bilden Datenbanksysteme, die imVergleich zu den herkmmlichen Quellentypen der Urkunden,Amtsbcher und Akten einen neuen Dokumenttyp darstellen.Ursprnglich fr die Verwaltung von kaufmnnischen Datenentwickelt, bilden Datenbanksysteme heute die Dateninfra-struktur der modernen Informationsgesellschaft. Datenbanksys-teme sind nicht nur die Grundlage fr die meisten Geschftspro-zesse, sondern auch fr vielfltige Webanwendungen (z. B. DMS,

    CMS). Relationale Datenbanken bilden, oft unsichtbar fr denNutzer, die Datenbasis fr die meisten heute verfgbaren Infor-mationssysteme. Sie unterscheiden sich von anderen statischenDokumenttypen durch ihren ausschlielich digitalen und dyna-mischen Charakter und beeinflussen bisherige Geschftsgngeund interne Verwaltungsablufe ebenso wie auch die Methodender Archivierung von der bernahme bis hin zur Nutzung.Angesichts des Alters und der Flle von Fachverfahren ist es ander Zeit, sich aus archivfachlicher und informationstechnologi-scher Sicht den Datenbanken als eine archivwrdige Quelleumfassend zu nhern, bestehende Erfahrungen und Lsungsan-stze zu nutzen und nachhaltige Verfahren zur Datenbankarchi-vierung zu entwickeln. Fr innovative und praxisrelevanteLsungen muss dabei die archivfachliche Betrachtung des Doku-menttyps Datenbank an erster Stelle stehen. hnlich wie eineUrkunden- und Amtsbuchlehre oder Aktenkunde wird knftigeine Datenbankkunde ntig sein, um die Auswirkungen diesesDokumenttyps auf das Verwaltungshandeln und die Archivie-rungsstrategien zu beschreiben und vorteilhaft fr Archivare undBenutzer in Handlungsstrategien umsetzen zu knnen.Der Artikel befasst sich mit grundstzlichen Anforderungen anden archivischen Umgang mit Datenbanken, insbesondere mitden Methoden der Bewertung und dauerhaften Erhaltung der inden Datenbanken gespeicherten Informationen.

  • 7ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    ARCHIVWRDIGKEIT VON FACH-VERFAHREN UND FACHINFORMATIONS-SYSTEMEN

    Das deutsche Archivwesen beschftigt sich seit Mitte der 1990erJahre eingehender mit der Archivierung von Fachverfahren. Die1997 vom EDV-Ausschuss der Archivreferentenkonferenz erarbei-teten Hilfsmittel brachten im Ergebnis u. a. eine Klassifizierungder IT-Verfahren mit, die sich am Verwendungszweck fr dieVerwaltung orientiert und Bewertungsvorschlge ableitet.2

    Danach werden die IT-Verfahren in Registratursysteme, Systemezur IT-untersttzten und IT-gesttzten Sachbearbeitung sowie inInformationssysteme eingeteilt, wobei den Informationssystemendie hchste Archivwrdigkeit zugesprochen wurde. Einge-schrnkt wird diese Klassifikation durch die Tatsache, dass letzt-lich keine klare Zuordnung der Systeme erfolgen kann, da Misch-formen inzwischen blich sind. Bei der Feststellung der Archiv-wrdigkeit von Fachverfahren ist allein die Klassifizierung nachdiesem Schema nicht ausreichend und es mssen daher mehrereAspekte zum Tragen kommen.

    1. Verbindung zwischen Fachverfahren und AkteDer Transfer von Daten aus Fachverfahren in die Akte bildet einwesentliches Kriterium fr die Archivwrdigkeit wegen derRechtsverbindlichkeit der Akte und dem Bewertungsgrundsatz,Redundanzen zu vermeiden. Weiterhin wird der Akte der blei-bende Wert beigemessen gleich, ob in papierner oder elektroni-scher Form. Die Koordinierungs- und Beratungsstelle der Bundes-regierung fr Informationstechnik in der Bundesverwaltung(KBSt) stellte jedoch 2004 fest, dass in der Praxis nicht alleInhalte des Fachverfahrens in die Akte gelangen und eine vollstn-dige Information ber den Bearbeitungsprozess nur in Verbin-dung von Fachverfahren und Akte mglich ist.3 Ziel des Erweite-rungsmoduls Fachverfahrensintegration des DOMEA-Konzeptswar es daher, Lsungen fr die Kommunikation zwischen Fach-verfahren und Akte zu schaffen, um Hybridakten zu vermeiden.Die Schnittstelle zwischen den IT-Systemen Fachverfahren undVorgangsbearbeitungssystem bildet ein Hilfsmittel fr die Bewer-tungsentscheidung. Bei der Datenbertragung wird zumeistXDOMEA als Datenaustauschstandard zur bertragung vonMeta- und Primrdaten genutzt, welcher in seiner zweiten Versiondie Verbindung zwischen Fachverfahren und elektronischer Aktebercksichtigt.4 Sind die Systeme von den Herstellern so entwi-ckelt, dass sie den Empfehlungen des Erweiterungsmoduls Fach-verfahrensintegration und der Schnittstelle XDOMEA folgen, sosind auch die Voraussetzungen fr die Vollstndigkeit der elektro-nischen Akte gegeben. In der Regel werden die Inhalte der Fach-verfahren in solchen Fllen als kassabel eingestuft.Bei lteren Systemen knnten die genannten Voraussetzungenmitunter nicht gegeben sein. bernahmen von Altakten in neueSysteme werden wegen fehlender Exportschnittstellen, verbundenmit hohem Programmieraufwand, evtl. nicht durchgefhrt. DieAlt-Daten gehen verloren oder werden mit ihren Speichermedienbei den IT-Verwaltungen aufbewahrt.5 Systemwechsel stellendaher den sptesten Zeitpunkt dar, an dem die Archive eineBewertung vornehmen mssen.6 Liegen Hybridakten vor, sind dieelektronischen Teile der archivwrdigen Akte zu bernehmen.7

    Dies zeigt, wie wichtig die archivische Vorfeldarbeit bei derEinfhrung von IT-Systemen ist, die zudem auf die Einhaltungder DOMEA-Grundstze bestehen sollte.8

    2. Verwaltungswissen und Ergebnisse desVerwaltungshandelns

    Die Abfragemglichkeiten von Datenbanken fhren letztlichdazu, dass Verwaltungswissen und die Ergebnisse aus demVerwaltungshandeln von den Fachverfahren organisiert undstrukturiert werden. Den Fachverfahren kommt dann die Funk-tion eines umfassenden, wenn nicht sogar primren, Arbeitsmit-tels zu, whrend die Akten nur noch der rechtlichen Nachweis-funktion dienen. Dies ist insbesondere bei elektronischen Regis-tern, personen- und objektbezogenen bersichten in Listenformund generell bei der Verwaltung von Stammdaten9 der Fall. Dadie Fachverfahren das Datenmaterial enthalten, auf deren Basisdas Verwaltungshandeln beruht, liegt es nahe, das zugrundeliegende Datenmaterial aus der Datenbank zu archivieren. Geradebei Statistiken hat sich seit lngerem der Grundsatz bewhrt, dieDaten in den Datenbanken fr archivwrdig zu erklren undnicht allein den statistischen Auswertungsergebnissen in denAkten einen bleibenden Wert zuzuschreiben.10

    1 Frhere Bezeichnungen sprechen auch von Broautomatisierungssystemen.2 Vgl. Bohl, Peter/Mller-Boysen, Carsten: Klassifikation der EDV-Anwendun-gen in der Verwaltung, in: Der Archivar 50(1997), Sp. 333-340; Hebig [Stahl-berg], Ilka: Bewertung undArchivierung von IT-Anwendungen in der Verwal-tung, in: Brandenburgische Archive. Mitteilungen aus dem Archivwesen desLandes Brandenburg 11(1998), S. 15-18, hier: S. 15. Diese Klassifikation findetsich auch in hnlicher Form bei der KBSt wieder, vgl. Anm. 3.

    3 Koordinierungs- und Beratungsstelle der Bundesregierung fr Informations-technik in der Bundesverwaltung (KBSt): DOMEA-Konzept. Erweiterungs-modul zum DOMEA-Organisationskonzept 2.0. Fachverfahrensintegrationo. O. Oktober 2004, S. 11-12.

    4 Arbeitsgruppe xdomea des Kooperationsausschuss Automatisierte Datenver-arbeitung Bund/Lnder/Kommunaler Bereich (KoopA ADV): xdomea 2.1.0Spezifikation, o. O. 2009 [gltig seit 18. 9. 2009]. Die Vorgnger-Version xdo-mea 1.0 ist seit 31. 5. 2005 gltig.

    5 Die Lesbarkeit kann jedoch ohne Erhalt der IT-Anwendung und weitererHard- und Softwareumgebungen nicht gewhrleistet werden. Solche Objektesind bei der Anbietung an die Archive als zwangslufig nicht archivfhig ein-zustufen bzw. deren Archivierungsaufwand nur bei sehr bedeutendem blei-benden Wert gerechtfertigt.

    6 Vgl. hierzu auch Lang, Rolf/Naumann, Kai: Bei Umzug bernahme Bewer-tung und Ablieferung elektronischer Unterlagen im Rahmen von Systemmi-grationen. Vortrag imRahmen der 12. Tagung des AKArchivierung vonUnter-lagen aus digitalen Systemen vom 22. 4. 2008, online: Homepage Landesar-chiv Baden-Wrttemberg: www.landesarchiv-bw.de/sixcms/media. php/120/50218/Bei_Umzug_Ueberna hme01.pdf [Zugriff: 6. 12. 2009]. Prsentations-folien hierzu unter: Homepage Bundesarchiv: www.bundesarchiv.de/imperia/md/content/abteilungen/abtb/bbea/lang_naumann.pdf [Zugriff: 6. 12. 2009].

    7 Vgl. hierzu etwa:Worm, Peter: Handreichung fr die Archivierung von digita-len Daten aus Kommunalverwaltungen, Version 0.3, Stand 12. 7. 2007, S. 2.online unter: Homepage des LWL-Archivamt fr Westfalen, www.lwl.org/waa-download/pdf/Handbuch_Archivierung_von_Fachverfahren_Vers_0_3.pdf [Zugriff: 4. 12. 2009].

    8 Die Gesetzesvorlage fr die Novellierung des Archivgesetzes in Nordrhein-Westfalen bestimmt dieMitwirkung des Landesarchivs bei der Festlegung vonAustauschformaten und bezieht dies auf den Zeitpunkt der Planung von IT-Systemen. 3, Abs. 4 und 5 Gesetzentwurf ArchivG NRW. Drucksache14/10028 v. 27. 10. 2009, online abrufbar ber die Homepage des LandtagNRW, www.landtag.nrw.de/portal/WWW/dokumentenarchiv/Dokument/MMD14-10028. pdf [Zugriff: 14. 12. 2009]

    9 Unter Stammdaten versteht man Grunddaten, deren nderung nicht inAbhngigkeit vom Vorgang durchgefhrt wird und die von daher ber einenlngeren Zeitraum unverndert bleiben, wohingegen Bewegungsdaten dyna-misch und daher vorgangsbezogen sind.

    10 Zur Diskussion um die statistischen Daten vgl. bspw. Keitel, Christian: Diearchivische Bewertung elektronischer Statistiken. Vortrag auf der 5. Tagungdes AK Archivierung von Unterlagen aus digitalen Systemen vom 5. 3. 2001,online unter: Homepage Landesarchiv Baden-Wrttemberg: www.landesarchiv-bw.de/sixcms/media.php/120/47171/keitel_elektronische_statistiken.pdf[Zugriff: 4. 12. 2009].

  • 8 AUFSTZE

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    8

    3. RetrievalfunktionenDie Fachverfahren sichern die Auffindbarkeit von Informationenund Dokumenten. Ebenso wie Erschlieungsdatenbanken sindFachverfahren technisch fr benutzerspezifische Abfragen vonInformationen ausgelegt und knnen die Suchergebnisse fr denAnwender bedarfsgerecht zusammenstellen eine Funktion, dieein papiernes Findmittel nicht erfllen kann. Die elektronischenErschlieungsdaten in den Archiven z. B. werden daher durchwegals archivwrdig erachtet und nicht allein die ausgedrucktenFindbcher.11

    4. Individuelle Auswertungsmglichkeiten fr denBenutzer

    Der Datenbestand in den Datenbanken bildet fr den knftigenBenutzer einen Datenpool, auf welchen er mit eigenen Auswer-tungsmethoden zugreifen und auf dessen Grundlage er miteigenen Abfragen zu neuen Erkenntnissen gelangen kann. Auchwenn die betreffenden Daten in den Akten vorhanden sind, wirdman es knftig zu schtzen wissen, diese Daten in einer auswert-baren Form als Datensammlung nutzen zu knnen. Die berliefe-rung in statischen, d. h. starren Dokumenten der papiernen wieelektronischen Akte haben diesen Vorzug nicht.12 Das britischeNationalarchiv verfolgt mit seinem National Digital Archive ofDataset (NDAD) diesen Ansatz und stellt bereits zahlreiche archi-vierte Datenbanken ber das Internet zur Verfgung.13

    Das Bewertungskriterium der Auswertungsoffenheit rechtfertigtauch redundante Datenhaltungen oder grozgigere Kassationenvon Papierakten.14 Dies ist v. a. dann gegeben, wenn die Vollzh-ligkeit der Grundinformationen berlieferungswrdig ist und einstatistisches, die Grundgesamtheit verzerrendes Auswahlverfahrendamit abgewendet werden kann.15

    5. Fachverfahren als Ordnungsmittel vonDokumenten

    Fachverfahren, die gegenber den Akten vorzugsweise von denSachbearbeitern genutzt werden, knnen die Funktion einesOrdnungsmittels bernehmen. Da das Fachverfahren dieOrdnung der Dokumente virtuell und fr den Bearbeiter sichtbarherstellt, kann die physische Ablage der einzelnen Dokumentevernachlssigt sein. Im Bereich von Beschlussorganen der Lnderund Kommunen werden Informationssysteme eingesetzt (Ratsin-formationssysteme, Parlamentsdokumentationen), die Doku-mente zu einer bestimmten Sitzung oder einem Vorgang virtuellzusammen stellen. Sie greifen dabei mitunter elektronisch aufverschiedene Dateiordner zu, in denen die Dokumente nachDokumenttypen wie Beschlussvorlage, Protokoll und Einladung,also nicht vorgangsbezogen, sortiert sind. Bei der Anbietung andas Archiv bleibt diese physische Ordnung bestehen gleich obals elektronischer oder papierner Ordner. Ohne die gleichzeitigebernahme des Informationssystems geht die vorgangsbezogeneOrdnung verloren und msste ber aufwndige archivischeErschlieungsarbeit wiederhergestellt werden.16 Eine nicht nach-vollziehbare physische Ablage kann auf dieser Tatsache beruhenund strkt die Grnde fr eine bernahme der Ordnungsfunk-tion des Fachverfahrens.

    6. Nachnutzbarkeit in den archivischenArbeitsprozessen

    Daten aus Fachverfahren knnen als Metadaten fr die digitaleArchivierung oder die Erschlieung verwendet werden, indem sie

    aus dem System abgefragt und exportiert werden. Insbesonderedie berfhrung von Daten aus Registratursystemen in dieErschlieungsdatenbank ist denkbar.17 Inwiefern die gngigenArchivprogramme den Datenimport aus fremden Systemen intechnischer und informationsstruktureller Hinsicht bewerkstel-ligen knnen, ist von Fall zu Fall zu bercksichtigen. Mageblichfr dieses Vorgehen bleibt, dass es sich hierbei um keine Archivie-rung von Daten handelt, da die berfhrung von Archivgut inErschlieungsdatenbanken archivischen Grundstzen zuwiderluft und in etwa vergleichbar wre mit dem Einlegen voneinzelnen Aktenschriftstcken in Findbcher. Datenbankenknnen daher statistische Auswahlmethoden der Bewertungebenso untersttzen wie die Abfrage von Akten nach inhaltlichenBewertungskriterien.

    DATENBANKARCHIVIERUNG IMVERGLEICH ZU ANDEREN ARCHIVIE-RUNGSPROZESSENDie Datenbankarchivierung hat zum Ziel, die Datenbankinhaltein einer systemunabhngigen und lesbaren Form unter Wahrungder Authentizitt und Integritt dauerhaft zu erhalten. Hierbeiunterscheidet sich die Datenbankarchivierung strikt von derSicherung von Datenbankinhalten, die weder die Dauerhaftigkeitder Aufbewahrung noch die Systemunabhngigkeit und nachhal-tige Lesbarkeit erfllen kann. Fr die dauerhafte Erhaltung vonDatenbankinhalten gibt es zwei Anstze: den Erhalt derursprnglichen Systemumgebung der Datenverwaltung durchEmulation oder der migrative Ansatz, d. h. die bernahme derDaten aus den Datenbanksystemen in ein digitales Archiv mitanschlieender digitaler Bestandserhaltung. Auf Grund fehlenderLsungsanstze wird der emulative Archivierungsansatz indiesem Artikel nicht weiter verfolgt und nur die Migration vonDaten aus Datenbanken in ein digitales Archiv betrachtet.Obwohl Datenbanksysteme im Vergleich zu anderen Softwareum-gebungen sehr langfristig betrieben werden, fhren System-wechsel und die berlastung der Datenbanksysteme durch wach-sende Datenmengen zur Anforderung, Datenbestnde aus denDatenbanksystemen herauszunehmen. Dies geschieht v. a. beiSystemwechseln oder durch automatisierte Datenlschungen inden laufenden Systemen. Gleichwohl besteht fr die Datenbank-inhalte ebenso eine Anbietungspflicht gegenber den ffentlich-rechtlichen Archiven wie bei den Akten. Die Lschungsvor-schriften in Gesetzen zur Registerfhrung bercksichtigen diesoftmals nicht. Das Bundesdatenschutzgesetz verweist hingegenauf die Anbietungspflicht auch bei personenbezogenen Daten.18

    Die Archive werden bei der Datenbankarchivierung die ber-nahme aus laufenden Systemen propagieren mssen, um Daten-vernichtungen vorzubeugen. Hierbei muss bei Lschungsvor-schriften insbesondere der Register auf Lschungsfristen bzw. aufLschungsgewohnheiten oder -automatisierung geachtet undmssen Aussonderungsintervalle festgelegt werden.19

    Die Bewertung von Datenbankinhalten kann dabei wesentlichnher an ihrem Entstehungszeitpunkt liegen als dies bei Akten derFall ist und somit die Bewertung unter der Magabe der Archiv-reife vor neue Herausforderungen stellen.

  • 9ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    DIE SPEZIFIK VON DATENBANKENDatenbanksysteme verwalten Daten in einer internen logischenStruktur (Datenmodell), die den Grundstzen der Datenmodellie-rung aus der Informatik folgt. Die Daten sind zwar lesbar bildenselbst aber noch keine Informationen ab. Diese werden erst dyna-misch durch sogenannte nutzerspezifische Sichten auf einenDatenbestand erzeugt. Dies geschieht mit Hilfe von interaktivenDatenbankabfragen, die berwiegend als Programmschnittstellenentwickelt werden (Abbildung 1). Das erzeugte Informationsob-jekt ist eine spezifische Nutzersicht auf den Datenbestand inForm von Ergebnislisten, Tabellen, Dokumenten oder Grafiken.Die Verwaltung und Organisation von Datenbestnden in einemDatenbanksystem sind dabei vergleichbar mit dem Abstellen einesFahrzeuges in einer Garage, das, bevor es abgestellt wird, in seinekleinstmglichen Einzelteile zerlegt und dann in speziell gekenn-zeichnete Schubladen gelegt wird (Abbildung 2). Die Ablage inden Schubladen wird so vorgenommen, dass Objekte mit glei-chen Objekteigenschaften in dieselbe Schublade einsortiertwerden. Die Anordnung der Objekte in den Schubladen und dieAnordnung der Schubladen sind dabei nicht von Belang. JedesMal bevor das Fahrzeug benutzt wird, muss es zunchst aus allen

    Abbildung 1: Bereitstellung von Informationen aus einer Datenbank

    Abbildung 2: Veranschaulichung der Verwaltung von Daten in einem Daten-banksystem

    seinen Einzelteilen wieder zusammengebaut werden. Dazu ben-tigt man eine Bauanleitung, die aber in der Regel nicht mit in denSchubladen abgelegt ist oder sogar gnzlich fehlt. Die Bauanlei-tung enthlt Angaben darber, welche Einzelteile bentigt werdenund wie sie grundlegend miteinander verbunden werden mssen,damit das Fahrzeug funktionstchtig ist. Dabei sind Modellmodi-fikationen durchaus mglich. Oft sind auch die Schubladen nichtausreichend beschriftet. Um bestimmte Bauteile wieder zu finden,bentigt man daher auch eine genaue Beschreibung der Schub-laden und ihrer Inhalte. Zudem ist auch mglich, je nach Bedarfverschiedene Variationen des Fahrzeugs zusammen zu bauen.bertragen auf ein relationales Datenbanksystem reprsentierendie Schubladen Relationen (Tabellen) und deren Attribute (Tabel-lenspalten bzw. Datenfelder) und das zusammengebaute Fahrzeugeine nutzerspezifische Sicht auf einen Datenbestand, die durchdie Montage (Datenbankabfrage) auf der Grundlage einer Bauan-leitung realisiert wird. Der Bauplan symbolisiert dagegen daszugrunde liegende relationale Datenmodell. Aus unserem Beispielergeben sich folgende Konsequenzen fr die Arbeit mit Daten-banken: Zum einen entstehen nutzbare Informationen (funkti-onstchtiges Fahrzeug) erst zum Zeitpunkt einer Anforderungdurch den Nutzer. Das Ergebnis einer Datenbankabfrage istdadurch nicht von vornherein festgelegt, sondern ergibt sichdynamisch aus der Nutzerinteraktion. In unserem Modell ist esbeispielsweise auch mglich, aus den verfgbaren Einzelteilen beiBedarf ein Einrad zusammenzubauen. Zum anderen ist eineRekonstruktion sinnvoller Informationen aus der Datenbank nurmit Hilfe der Datenbankabfrage (Bauanleitung) mglich, diewiederum die Kenntnis des zugrundeliegenden relationalenEntwicklungsmodells (Bauplan) voraussetzt. Ist dagegen dieBauanleitung verloren gegangen, kann die Information (Fahrzeug)

    11 Vgl. bspw. die Bewertungsliste zu den Fachverfahren aus dem Stadtarchiv Bie-lefeld und dem Kreisarchiv Gtersloh, Zugriff ber die Homepage des LWL-Archivamtes fr Westfalen unter: http://www.lwl.org/LWL/Kultur/Archi-vamt/Archiv_IT/Elektronische_Fachverfahren/ [Zugriff: 7. 12. 2009]. DieBewertungslisten stammen aus dem Jahr 2006.

    12 Vgl. dazu auch die Ausfhrungen zu den statistischen Daten. Es kann ange-nommen werden, dass die knftigen Benutzer der digital born generationvon archivierten Datenbanken erwarten, dass eine programmierte Abfragedurchfhrbar ist.

    13 http://www.ndad.nationalarchives.gov.uk/access/ [Zugriff: 12. 12. 2009].14 Vgl. hierzu Ernst, Katharina: Einleitende Bemerkungen zur Bewertung vonUnterlagen aus digitalen Systemen, in: dies. (Hg.): Erfahrungen mit der ber-nahme digitaler Daten. Bewertung, bernahme, Aufbereitung, Speicherung,Datenmanagement. Elfte Tagung des Arbeitskreises Archivierung aus digita-len Systemen v. 20./21. Mrz 2007, Stuttgart 2007, S. 3-5, hier: S. 4.

    15 Vgl. Keitel, Christian/Lang, Rolf/Naumann, Kai: Handlungsfhige Archive:Erfahrungen mit der Bewertung und bernahme digitaler Unterlagen, in:ebd., S. 10-13, hier: S. 13.

    16 Diese Erfahrung hat das Stadtarchiv Potsdam seit Einfhrung des Ratsinfor-mationssystems gemacht und auch verschiedene andere Ratsinformationssys-teme zeigten, dass die Dateistruktur den Dokumenttypen folgt.

    17 Mit der Qualitt von Registraturdaten fr die Erschlieung beschftigte sich2006 eine Transferarbeit an der Archivschule Marburg und dem SchsischenHauptstaatsarchiv Dresden: Metadaten aus elektronischen Brosystemen Eine Grundlage fr die archivische Erschlieung. Angabe auf der Homepageder Archivschule Marburg unter: http://www.archivschule.de/ausbildung/liste-der-transferprojekte/ [Zugriff: 14. 12. 2009].

    18 Bundesdatenschutzgesetz 20 (Berechtigung, Lschung, Sperrung vonDaten;Widerspruchsrecht), Abs. 9.

    19 Hierzu nimmt bspw. die Verwaltungsvorschrift zum NiederschsischenArchivgesetz. Runderlass der Staatskanzlei v. 24. 10. 2006 Stellung. Zu 3(2),Satz 1 NArchG wird bestimmt, dass das Archiv einen Stichtag festlegen kann,an welchem kopierte Daten bergeben werden. Text abrufbar unter: Hayek,Hans-Jrgen (Hg.): Homepage Schule und Recht in Niedersachsen. Gesetze,Verordnungen, Erlasse und Kommentare. unter: http://www.schure.de/22560/vv-narchg.htm [Zugriff: 12. 12. 2009].

  • 10 AUFSTZE

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    10

    nicht mehr rekonstruiert werden. Die strukturierte Ablage derDaten in einer internen Datenstruktur (Schubladen) ist dabeiausschlielich fr die Verwaltung der Daten von Bedeutung, nichtaber fr die Wiederherstellung der Datenbankinformation.Datenbanksysteme sind daher Instrumente zur Verwaltung voneinzelnen Daten (Einzelteilen), die erst durch eine sinnvolleVerknpfung den Rang eines Informationsobjektes erlangen.

    STRUKTUR VON INFORMATIONS-ANWENDUNGENDatenbanksysteme werden auf der Grundlage ihres internenDatenmodells klassifiziert, wobei das relationale Datenmodellderzeit die berragende Praxisrelevanz hat. Demgegenber sindandere Datenmodelle vernachlssigbar. Betrachtet man heute diegrundlegende Struktur von Informationsanwendungen, so kannman drei Ebenen unterscheiden: das Dateiverwaltungssystem, dasDatenbanksystem und das Informationssystem (Abbildung 3).Das Datenbanksystem verwaltet dabei selbststndig die Ablageder Daten in Dateien durch Zugriff auf ein Dateiverwaltungs-system, in der Regel das Betriebssystem eines Rechners. DasDatenbanksystem legt die Daten in strukturierter Form ab,hierauf greift das Informationssystem zu. Das Informationssystembereitet die Daten zur Nutzung auf und realisiert die Mensch-Maschine-Kommunikation.

    Abbildung 3: Grundstzliche Architektur von Datenbank-basierten Informati-onsanwendungen

    Diese Struktur hat enorme Vorteile: Neben der Datenverwaltungermglichen Datenbanksysteme die Verwaltung von Benutzungs-rechten sowie die Gewhrleistung der Konsistenz und Integrittder gespeicherten Daten. Darber hinaus verfgen Datenbanksys-teme ber spezifische Werkzeuge zur Informationssuche, Infor-mationsverwaltung sowie Pflege, Strukturierung und Sicherungeines Datenbestandes. Das Informationssystem kommuniziert inder Regel ber eine Anwendungsprogrammschnittstelle mit demDatenbanksystem. Es handelt sich dabei um Rechnerprogramme,die Daten aus dem Datenbanksystem anfordern und fr dieweitere Nutzung in den Informationssystemen bereitstellen.Obwohl die Datenbankabfrage in der standardisierten Abfrage-sprache fr objekt-relationale Datenbanken SQL20 formuliertwird, ist sie Bestandteil eines Maschinenprogrammes und daher

    nicht systemunabhngig lesbar und archivierbar. Wird dieseProgrammschnittstelle im Fall einer Archivierung jedoch nicht inirgendeiner Form gesichert, fehlt letztlich die Bauanleitung fr dieInformationen.

    VERSCHIEDENE SICHTEN AUF DENDATENBESTANDDatenbanksysteme unterscheiden drei verschiedene Sichten aufeinen Datenbestand: eine interne, eine konzeptionelle und eineexterne Sicht (Abbildung 4).

    1. interne SichtDie interne Sicht betrifft die physische Organisation der Datenauf den Datentrgern, die vom Datenbanksystem selbststndigund unsichtbar fr den Anwender durchgefhrt wird.

    2. konzeptionelle SichtAuf der konzeptionellen Ebene definiert der Datenbankentwicklerdas Datenmodell die logische Struktur der Datenverwaltung.Bei Verwendung des relationalen Datenmodells reicht es aus,einzelne Tabellen zu definieren. Abbildung 5 zeigt das relationaleDatenmodell eines fiktiven Melderegisters, das Personendaten,Adressdaten und Ausweisdaten enthlt. Das Datenmodell defi-niert dabei Tabellen, Tabellenspalten und Beziehungen zwischenden Tabellen. Optional knnen auf dieser Ebene auch die Tabel-lenverknpfungen definiert werden. Diese Festlegungen habenjedoch nur Einfluss auf die berprfung der referenziellen Inte-gritt des Datenbestandes. Die Verknpfung von Tabellen in einerDatenbankabfrage kann auch unabhngig von diesen Festle-gungen erfolgen, was u. U. dazu fhren kann, dass Daten ausunterschiedlichen Tabellen falsch verknpft werden.Bei komplexeren Tabellenbeziehungen bentigt man zustzlicheTabellen, in unserem Beispiel fr die Beziehungen zwischenPersonen (Eltern, Kind, Partner etc.) oder zwischen Personen undderen gegenwrtigen bzw. frheren Adressen.Nur Datenbankabfragen, die auf der Grundlage des konzeptio-nellen Modells entwickelt werden, liefern richtige Informationen

    Abbildung 4: Sichten auf den Datenbestand eines Datenbanksystems

  • 11

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    Abbildung 5: Relationales Datenmodell (konzeptionelle Sicht) fr ein fiktives Melderegister

    aus einem Datenbestand. In der Praxis kommt es hufig vor, dassdas konzeptionelle Datenmodell nicht in der Datenbank inForm von Schlsselattributen gespeichert wird. Werden keineSchlsselattribute definiert, ist spter keine Rekonstruktion deslogischen Datenmodells aus dem Datenbanksystem heraus mehrmglich.

    20 SQL = Structured Query Language, standardisierte Skriptsprache vor allemzur maschinellen Kommunikation mit einem Datenbanksystem. Alle Daten-bankoperationen knnen mit Hilfe einer SQL-Programmschnittstelle ausge-fhrt werden.

    Abbildung 6: Beispiel fr eine externe, nutzerspezifische Sicht Ausweisdaten

  • 12 AUFSTZE

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    12

    3. externe SichtDie externe Sicht ist die nutzerspezifische Sicht auf den Datenbe-stand, die durch eine Datenbankabfrage erzeugt wird (Abbildung4). In der Regel bernehmen Anwendungsprogramme die unmit-telbare Datenkommunikation mit der Datenbank. Eine Sicht wirdin der Hauptsache durch die Auswahl von bestimmten Datenfel-dern (Projektion) und Datenstzen (Selektion) sowie durch dieVerknpfung von Daten aus unterschiedlichen Tabellen erzeugt.Im Ergebnis liefert das Datenbanksystem eine virtuelle Ergebnis-tabelle, die in dieser Form nicht in der Datenbank gespeichertwird. Prinzipiell ist es auch mglich, die Datenbankabfragen alsSichten in der Datenbank zu speichern (Views). Abbildung 6 zeigteine SQL-Datenbankabfrage, die als Ergebnis eine virtuelleTabelle mit Daten erzeugt, die beispielsweise in einem Ausweisdo-kument enthalten sind. Die Daten stammen dabei aus den dreiTabellen Person, Anschrift und Ausweis, die dazu miteinanderverknpft worden sind.Wie wichtig die Kenntnis des konzeptionellen Datenmodells istzeigt Abbildung 7. Durch eine falsche Zuordnung von Schlssel-attributen wurden Daten aus unterschiedlichen Tabellen falschverknpft. Da die Datenbankabfrage syntaktisch richtig ist,wrde der Anwender die fehlerhafte Verknpfung der Daten u. U.gar nicht bemerken.Eine wesentliche Funktionalitt von Datenbanksystemen bestehtin der Sicherung und Wiederherstellung von gespeicherten Daten.Die Datensicherung umfasst dabei die relationale Datenstruktur,die in den Tabellen gespeicherten Daten und die in der Daten-bank gespeicherten Sichten auf den Datenbestand. Als Ausgabe-formate werden heute SQL-Befehlsskripte oder systemspezifischeXML-Formate (nur fr Daten und Strukturdaten) benutzt.

    Abbildung 7: Beispiel fr falsche Informationen durch falsche Tabellenverknpfung

    Obwohl SQL eine standardisierte Abfragesprache ist, unter-scheiden sich die SQL-Dialekte verschiedener Anbieter zum Teilbetrchtlich. Auch die XML-Exportformate sind nicht standardi-siert und unterscheiden sich von Datenbankanbieter zu Daten-bankanbieter.

    GEGENSTAND DER ARCHIVIERUNG VONDATENBANKINHALTENDie archivische berlieferungsbildung bezog sich bei denherkmmlichen Unterlagen stets auf einzelne Informationsob-jekte als kleinste Einheit und nicht auf einzelne Daten, die zueinem solchen noch zusammengefgt werden mssen. Zu denGrundstzen der Archivierung gehrt es, diese Informationsob-jekte als Einheit zu erhalten und auch deren inhaltlichen Kontextdurch den Erhalt der Struktur der Akte bzw. des Vorgangs undderen Entstehungszusammenhang zu bewahren. 21 Die Eigen-schaft der Datenbank bringt es mit sich, dass wir zwischen Datenin einer konzeptionellen Struktur und Informationsobjekten aufder Grundlage dieser Daten unterscheiden mssen. Letztereentstehen erst durch die nutzerspezifische Sicht auf die Daten-bank, jener Sicht, die fr das Verwaltungshandeln relevant war.Gegenstand der Archivierung kann daher nur die nutzerspezifi-sche Sicht auf den in einer Datenbank verwalteten Datenbestandsein. Weder die interne noch die konzeptionelle Sicht sind fr einesptere Wiederverwendung des Datenbestandes geeignet. Wederdie Gesamtheit der Daten aus der Datenbank noch die Gesamt-heit der Tabellen in einem Datenmodell bilden daher ein Informa-tionsobjekt. Dies unterscheidet die Datenbankarchivierung

  • 13

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    wesentlich von der Datenbanksicherung, welche auf der Ebeneder konzeptionellen Sicht die Datenbestnde erhlt.Die Datenbanken erzeugen jedoch nicht nur eine einzige Sicht,sondern beliebig viele Sichten. Davon werden die einen als stati-sche Dokumente, bspw. in Form von Grafiken oder Tabellen,andere jedoch nur als quasi-flchtiges Abfrageergebnis in Formvon Ergebnistabellen erstellt, die nach Verlassen der Sicht nichtvom Datenbanksystem gespeichert werden.Im Zusammenhang mit einer Archivierung von Datenbankin-halten knnen weitere Probleme auftauchen, fr die es bisher nochkeine Lsungsanstze gibt. So kann ein Datenbanksystem proble-matische Datentypen enthalten, beispielsweise unstrukturierteBinrdaten (Bitstrme), die sich nicht direkt in ein Archivformatbernehmen lassen. Der Datenbestand in einer Datenbank kannauch durch interne Programmroutinen, sogenannte gespeicherteProzeduren und Funktionen sowie Trigger verndert werden. DieseRoutinen knnten nur zusammen mit der Datenbank-Systemum-gebung, d. h. durch eine Emulationsstrategie archiviert werden.Problematisch ist auerdem, dass Datenbankfragen (Sichten) undDatenstrukturinformationen (Schlsseldefinitionen) in der Daten-bank gespeichert werden knnen, aber nicht mssen.Sofern die Datenbanken eine etablierte, nicht-proprietre Abfra-gesprache verwenden, kann auch eine archivspezifische Sicht aufden Datenbestand erzeugt werden. Auf diese Weise bewertet derArchivar einzelne Datenfelder, stellt deren Archivwrdigkeit festund setzt sie zu neuen Sichten zusammen, die aus der Datenbankexportiert und in ein archivfhiges Format gebracht werden. ImErgebnis entsteht ein Gefge von Daten, welches in dieser Artnicht dem Verwaltungshandeln zugrunde gelegen hat, sondernvom Archivar neu kreiert worden ist.22 Er enthlt berlieferteDaten, aber keine berlieferten Verwaltungsdokumente. DieDokumentenkomposition ist dabei eine neue Archivierungsme-thode, bei der es grundstzlich zu berdenken gilt, inwiefern sieberlieferung bildet oder Historie erschafft. Zwischen derKomplettberlieferung eines Datenbestandes und der Teilarchivie-

    rung einzelner Daten steht immer noch das in der Verwaltungerstellte Informationsobjekt als berlieferungseinheit fr dieArchivierung. Es besteht vielmehr die Anforderung die Informati-onsobjekte, bspw. durch die Identifizierung verschiedener Formenvon Sichten, zu definieren und diese zu bewerten.Tabelle 1 zeigt die Anhngigkeit zwischen Erhaltungskriterienund Gegenstand der Archivierung.Fr die Archivierung von Datenbankinhalten wird im Folgendenv. a. die Archivierung von Informationsobjekten und dieKomplettarchivierung der Datenbank im Fokus stehen. DieAbfrage von Daten fr ein Erschlieungsprogramm fllt dabeinicht unter die Datenbankarchivierung. Die Archivierung vonstatischen Verwaltungsunterlagen, die auf der Grundlage derDatenbank erzeugten werden, kann sich an der Archivierung vonUnterlagen aus Dokumentenmanagementsystemen orientieren.

    REFERENZMODELL ZUR AUTOMATI-SIERTEN BERNAHME VON DATEN-BANKINHALTENBasierend auf den bisherigen internationalen Projekten zurDatenbankarchivierung wurde an der FH Potsdam ein OAIS-konformes Referenzmodell zur Archivierung von Datenbankin-

    21 Wie Michael Wettengel bereits fr die Archivierung arbeitsmarktstatistischerUnterlagen konstatierte, wird der Archivar ohne klar definierte Bewertungs-grundstze Gefahr laufen, in den Bits und Bytes unterzugehen. Vgl.Wetten-gel, Michael: Bewertung arbeitsmarktstatistischer Unterlagen. Vortrag auf der4. Sitzung des AK Bewertung imVdA Verband deutscher Archivarinnen undArchivare am 11. 3. 2003. [ohne Seitenangabe, Kap. 3 Bewertungsgrundstze]Zugriff seit 15. 12. 2009 nur noch im Mitgliederbereich des VdA zugnglich.

    22 Hierzu bspw. Keitel/Lang/Naumann: Handlungsfhige Archive (Anm. 15), S.13 und Anm. 17.

    Tabelle 1:Bestimmung des Gegenstands nachErhaltungskriterien

  • 14 AUFSTZE

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    14

    halten entwickelt. Auf der Grundlage dieses Modells kann eineprototypische Archivlsung fr ein digitales Archiv erstelltwerden. Dieses Referenzmodell kann Inhalte und Sichten ausDatenbanksystemen, die im Rahmen dieses Artikels als archiv-fhig eingestuft wurden, vollstndig und automatisiert in eindigitales Archiv bernehmen.Den Ausgangspunkt des Archivierungskonzeptes bilden ein relatio-nales Datenbanksystem (RDBS) und das Backup der darin enthal-tenen Datenbanken. Eine Datenbank stellt dabei das Informations-objekt der Archivierung dar. bernommen werden sowohl dieDatenbankstruktur, die Daten und die an das System gestelltenAbfragen. Darber hinaus werden verschiedene Metadaten berck-sichtigt. Zustzlich werden die Feldbeschreibungen archiviert.Unter Verwendung des OAIS-Standards werden Informationspa-kete verwendet: Einlieferungspakete (SIP), Archivpakete (AIP) undAuslieferungspakete (DIP). Prinzipiell bestehen die Informations-pakete aus Inhaltsinformationen und den dazugehrigen Meta-daten. Die Inhaltsdaten werden in allen drei Paketen durch dieDatenbankstrukturdaten, die Datenbankdaten und die Abfragengebildet. Die Metadaten liegen in Form der Feldbeschreibung undweiteren archivrelevanten Zusatzinformationen vor. Das Einliefe-rungspaket SIP entsteht als Ergebnis der Vorbernahme und wirdan den bernahmeprozess bergeben (Abbildung 8).

    Abbildung 8: Datenbankarchivierung: bernahmeprozess und SIP23

    Die Datenbankstruktur und die Datenbankdaten liegen, abhngigvom mglichen Datenbankexport, in einem systemspezifischenXML- oder SQL- Format vor. Die Angaben zur Datenbank-struktur bilden die strukturellen Reprsentationsinformationendes Informationspaketes und beinhalten Beschreibungen dervorhandenen Tabellen, Tabellenspalten sowie der Primr- undFremdschlssel. Die Datenbankabfragen sind in einem Protokolldes Datenbanksystems enthalten, das im Einlieferungspaket alsTextdatei vorliegt. Sowohl die Feldbeschreibungen als auch dieergnzenden Metadaten knnen in unterschiedlichen digitalenFormaten oder in nicht-elektronischer Form geliefert werden. Beiden ergnzenden Metadaten handelt es sich vorwiegend umbeschreibende Kontextinformationen, die Angaben zur institutio-nellen und organisatorischen Einordnung, zum Inhalt, Zweckund zur Bedeutung der Datenbank umfassen. Sie werden durchtechnische und rechtliche Informationen ergnzt.Entscheidend fr die Archivierung ist der Aufbau und Inhalt desArchivpaketes AIP, das im Archivspeicher dauerhaft und unvern-derbar abgelegt wird (Abbildung 9).Aus Grnden der Lesbarkeit und Interpretierbarkeit der Datenwird das XML-Format fr alle im AIP abgelegten Daten und

    Abbildung 9: Datenbankarchivierung: Archivierungsprozess und AIP

    Metadaten verwendet. Zustzlich werden alle Daten in einemstandardisierten Containerformat, z.B. METS abgelegt. Diebeschreibenden Metadaten werden in die Datenverwaltungkopiert und das Archivpaket im Archivspeicher abgelegt. Fr dieSicherung der Abfragen wird ein XML-basiertes sprachunabhn-giges Archivformat verwendet, das durch ein im Rahmen einerDiplomarbeit an der FH Potsdam entwickeltes XML-Schemabeschrieben wird.24

    Das Auslieferungspaket DIP wird auf der Grundlage von Nutze-ranforderungen generiert und fr die weitere Nutzung bereitge-stellt. Das Paket ist in seinem Aufbau an den Nutzerbedrfnissenorientiert und kann aufgrund der gewhlten Archivierungsfor-mate flexibel gestaltet werden. Datenbankstruktur, Datenbank-daten und Abfragen sind nicht an ein bestimmtes Ausgabeformatoder eine bestimmte Abfragesprache gebunden. In dem konkretenBeispiel werden Datenbankstruktur, Datenbankdaten, Abfragenund Feldbeschreibungen im SQL-Format bereitgestellt (Abbil-dung 10).

    Abbildung 10: Datenbankarchivierung: Bereitstellungsprozess (SQL-Sicht) undDIP

    Die Feldbeschreibungen werden mit Hilfe von SQL-Spaltenbe-zeichnungen, Aliasnamen oder Kommentarspalten umgesetzt.Abfragen werden in Datenbanksichten transformiert. Es wirdausschlielich standardkonformes SQL verwendet. In unseremBereitstellungsbeispiel ist es mglich, die archivierte Datenbankvollstndig in ein zuknftiges SQL-konformes relationales Daten-banksystem einzuspielen und somit die ursprngliche Benutzungzu rekonstruieren.

  • 15

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    modell fr die Datenbankarchivierung. Im Rahmen diesesProjektes wurde ein spezielles XML-Schema zur Archivierung derDatenbankstruktur und der Datenbankinhalte entwickelt, das alsDBML33 (Data Base Modelling Language) bezeichnet wird.In SIARD werden dagegen verschiedene Archivformate: CSV(Comma-Separated Values) fr Datenfeldinhalte, Standard- SQL(Structured Query Language) fr die Datenstruktur bzw. Sichtenund XML fr beschreibende Metadaten verwendet. SIARD legteinen besonderen Schwerpunkt auf die Standardisierung derSQL-Dialekte, die verschiedene Datenbanksysteme erzeugen,bevor ein standardisiertes SQL-Skript im Archivinformations-paket abgelegt wird. Dieser Aufwand ist vor allem deshalb erfor-derlich, da SIARD als Archivformat fr die Datenbankstrukturenund Sichten SQL benutzt. Legt man die Daten und Strukturdatendagegen, wie im RODA-Projekt, im XML-Format ab, ist esmglich, Programme zur bernahme von Datenbanken ausunterschiedlichsten Datenbanksystemen in ein XML-Schema(beispielsweise Altova Database Spy) zu benutzen. Zudem stellendie in SIARD betrachten Datenbanksysteme bereits eine XML-Export-Schnittstelle zur Verfgung.

    ARCHIVIERUNGSSTRATEGIENCharakteristisch fr relationale Datenbanken sind zum einen dasSichtenmodell und zum anderen die Automatisierung und interneStrukturierung des Datenbestandes zur Datenverwaltung.Entscheidend fr die Archivierung ist die externe, nutzungsab-hngige Sicht auf einen Datenbestand. Nur sie erzeugt das archi-vierbare Informationsobjekt. Die Sicherung der internen, konzep-tionellen Sicht (Datenbank-Backup) kann dagegen zu einemVerlust der Authentizitt des Informationsobjekts fhren.Prinzipiell kann man zwei Strategien zur Archivierung von Infor-mationen aus Datenbanken unterscheiden: die Archivierungausgewhlter nutzerspezifischer Sichten in Form von statischenelektronischen Dokumenten (z. B. Tabellen, Grafiken, Textdoku-mente) oder die Archivierung des Datenbestandes einer Daten-bank und der Datenbankfunktionalitt. Erst im zweiten Fall kann

    23 In den Abbildungenwerden die Inhaltsdaten als Rechtecke und dieMetadatendurch Rechtecke mit abgerundeten Ecken symbolisiert.

    24 Glde, Julia: Archivierung relationaler Datenbanken auf der Grundlage vonXML-Konzeption eines OAIS-konformen Archivierungsmodells und Ent-wicklung eines neuen Ansatzes zur Archivierung von Datenbankabfragen,Diplomarbeit FH Potsdam, 2009.

    25 Die Unternehmen sind nach den Grundstzen zum Datenzugriff und zurPrfbarkeit digitaler Unterlagen (GDPdU) und den Grundstzen ordnungs-miger DV-gesttzter Buchfhrungssysteme (GoBS) zur Aufbewahrung vonsteuerrelevanten digital born documents in weiterhin digitaler Form ver-pflichtet und mssen den Finanzmtern die Daten ggf. in lesbarer, aber auchauswertbarer Form zur Verfgung stellen. Da auch innerhalb der Aufbewah-rungsfrist von 10 Jahren Systemwechsel anstehen, sind hier Methoden derDatenbankarchivierung gefragt.

    26 Keitel, Christian: Erste Erfahrungen mit der Langzeitarchivierung von Daten-banken. Ein Werkstattbericht, in: Hering, Rainer/Schfer, Udo (Hg.): Digita-les Verwalten Digitales Archivieren, Hamburg 2004, S. 71-81.

    27 http://roda.di.uminho.pt/?locale=en#home.28 http://www.fedora-commons.org/.29 http://www.bar.admin.ch/dienstleistungen/00823/00825/index.html?lang=

    de.30 http://www.csp-sw.de/de/inhalt.php?kategorie=c114_L_sungen_CHRONOS.31 http://h71028.www7.hp.com/enterprise/w1/en/software/information-mana-gement-g overnance-ediscovery-database-archiving.html.

    32 http://conferences.idealliance.org/extreme/html/2007/Ramalho01/EML2007Ramalho01.html.

    33 http://inforum.org.pt/INForum2009/docs/full/paper_79.pdf.

    STAND UND BEWERTUNG DER PROJEKTEUND ANWENDUNGSPROGRAMME ZURDATENBANKARCHIVIERUNG

    Die langfristige Aufbewahrung von Inhalten, die in Datenbankengespeichert sind, gewinnt im Unternehmensumfeld und imBereich der ffentlichen Verwaltung zunehmend an Bedeutung.Die Ursachen fr das gewachsene Interesse an Methoden derDatenbankarchivierung in der Wirtschaft liegen zum einen in derberlastung der operationalen Datenverwaltungssysteme undzum anderen in Compliance- Anforderungen zur revisionssi-cheren Aufbewahrung elektronischer Unterlagen und der Einhal-tung von Aufbewahrungsfristen.25 Im Bereich der ffentlichenVerwaltung sind aus Sicht der IT vor allem Systemwechselausschlagegebend fr eine systemunabhngige langfristige Aufbe-wahrung von Datenbankanwendungen und Daten aus Informati-onssystemen. Auch im Zusammenhang mit dem Aufbau von digi-talen Archiven auf Landes- bzw. Bundesebene wird zunehmendber die bernahme von Datenbankinhalten nachgedacht. Ineinigen Lndern, wie beispielsweise in Baden-Wrttemberg,werden bereits ausgewhlte Sichten auf Datenbestnde in Daten-bankensystemen archiviert.26 Im Rahmen grerer nationalerLangzeitarchivierungsprojekte, wie RODA27 (Repository ofAuthentic Digital Objects), das auf der Open-Source-SoftwareFEDORA28 (Flexible Extensible Digital Object Repository Archi-tecture) basierende digitale Archiv der portugiesischen Regierungbzw. ARELDA (Archivierung elektronischer, digitaler Daten undAkten) des schweizerischen Bundesarchivs, aus dem die Daten-bankarchivierungs-Softwarelsung SIARD29 (Software Indepen-dent Archiving of Relational Databases) hervorgegangen ist,wurden bereits OAIS-konforme Archivlsungen fr die ber-nahme von relationalen Datenbanken entwickelt.Softwareanbieter, wie HP, IBM oder CSP bieten kommerzielleLsungen fr die Archivierung relationaler Datenbanksysteme an,die im Wesentlichen ber einen lngeren Zeitraum versionierteDatenbank-Backups in einem spezifischen Archivformat revisi-onssicher speichern. Die Vorteile solcher Archivlsungen wie zumBespiel das System CHRONOS30 der Firma CSP oder der HPArchiving Software31 liegen auf der Hand: die Verschlankung derProduktivdatenbanken, die Verkrzung der Datensicherung- undWiederherstellungszeiten und die langfristige Verfgbarkeit derDaten ohne das Vorhandensein der ursprnglichen Datenbank-systeme. Die Daten werden aus den Datenbanksystemen hnlichwie bei einem Datenbank-Backup automatisch kopiert. DerNachteil ist, dass die Datenbanken nicht auf ihre Archivfhigkeithin berprft werden, sondern nur die tatschlich in der Daten-bank vorhandenen Daten in das Archiv bernommen werden. Dakeine Information ber die Datenbankstruktur aus den Anwen-dungsprogrammschnittstellen bernommen werden kann, ist dieRekonstruktion der Datenbankfunktionalitt nur dann mglich,wenn die Daten in ihrer ursprnglichen Systemumgebung wieder-hergestellt werden. Die kommerziellen, sogenannten Datenbank-archivlsungen haben zwar Merkmale einer OAIS-konformenArchivierung, wie lesbare und teilweise auch systemunabhngigeArchivierungsformate, sind aber vom Charakter her eher Daten-banksicherungssysteme, die mehr mit einer Datawarehouse-Lsung als mit einer Archivlsung vergleichbar sind.Das im Zusammenhang mit dem RODA-Projekt entwickelteOAIS-konforme Modell32 fr die digitale Archivierung von relatio-nalen Datenbanken eignet sich dagegen schon besser als Referenz-

  • 16 AUFSTZE

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    16

    Tabelle 2: Vor- und Nachteile der beiden Methodenzur Archivierung von Datenbankinhalten

    man im eigentlichen Sinne von einer Datenbankarchivierungsprechen. Die Vor- und Nachteile beider Methoden sind in Tabelle2 zusammengefasst.Fr die Datenbankarchivierung mssen darber hinaus Kriterienfr die Archivfhigkeit von Datenbankanwendungen definiertwerden. Zu den Minimalanforderungen gehren:1. das Vorhandensein einer relationalen Datenbank2. das Vorliegen von Feldbeschreibungen3. das Vorliegen einer Beschreibung der Art und Weise der

    Datenverknpfungen, entweder durch Schlsseldefinitionen,Datenbanksichten (Views) oder die Analyse der Suchfunktio-nalitt

    4. Mglichkeit der Analyse der Datenbankfunktionalitt durchAbfragen, Suchoberflchen oder Dokumentationen

    ERFASSUNG UND BEWERTUNG VONFACHVERFAHRENDie vorangegangenen Erkenntnisse haben Einfluss auf dieArchivwrdigkeit und -fhigkeit von Fachverfahren. Der Erfas-sung von Fachverfahren obliegt die Aufgabe, mglichst frhzeitigdiejenigen Informationen einzuholen, aus denen auf den blei-benden Wert des Verfahrens geschlossen werden kann. Angesichtsder enormen Flle verschiedener Verfahren34 ist nicht nur eineeffiziente Erfassung, sondern eine ebenso effiziente Bewertung,z.B. auf der Basis einer Listenbewertung sinnvoll. Erfahrungenmit der Erfassung von Fachverfahren zeigen, dass diese umfang-reich sein knnen35 und die Ansprechpartner hierfr sorgfltigausgesucht sein mssen36 . Ntzliche Informationen liefern dabei

    nicht nur die anwendenden Behrden, sondern in jedem Fall auchdie IT-Stellen.So wie sich Anbietungslisten fr Akten im archivischen Arbeits-umfeld bereits etabliert haben und Teil von Registraturverord-nungen geworden sind, so wenig bestehen solche fr Fachver-fahren. Archive, die bereits Fachverfahren bewertet haben, greifenhier zumeist auf Listen aus der Verwaltung zurck, die frverwaltungsinterne Zwecke gefhrt werden. Die Archive knnenzunchst Listen aus den IT-Stellen verwenden, die in der Regelden besten berblick ber alle angewandten IT-Verfahren habenund auch Auskunft darber geben knnen, wie lange eineAnwendung bereits im Einsatz ist bzw. ob Systemwechsel schondurchgefhrt wurden oder zu erwarten sind. Zustzlich haltendie Datenschutzbeauftragten Verfahrenslisten vor, die auf Antragvon Jedermann einsehbar sind, sich jedoch ausschlielich aufDatenbanken mit personenbezogenen Daten beschrnken.37 ZurFhrung des Verzeichnisses sind nicht nur die Behrden, sondern

    34 Das Stadtarchiv Bielefeld listet insgesamt 226 verschiedene Verfahren (Stand2006), das Kreisarchiv Gtersloh 273 (Stand 2006) auf. Der Landkreis Pots-dam-Mittelmark verzeichnet 85 IT-Anwendungen (Stand: 2008). Auf derEbene der Lnder mgen dies noch wesentlich mehr sein.

    35 Vgl. Hinweise von Katharina Ernst in: dies.: Einleitende Bemerkungen (Anm.14), S. 3.

    36 So erste Erfahrungen im Landesarchiv Baden-Wrttemberg. Vgl. Keitel/Lang/Naumann: Handlungsfhige Archive (Anm. 15), S. 10 und 11.

    37 Formulare fr die Verfahrensverzeichnisse findet man bspw. ber die Gesell-schaft fr Datenschutz und Datensicherung e. V. (GDD e. V.): AK BDSG2001 der GDD e.V.: Das Verfahrensverzeichnis fr Jedermann, online unterHomepage der GDD e.V., https://www.gdd.de/nachrichten/arbeitshilfen/verfahrensverzeichnis.pdf [2004], [Zugriff: 12. 12. 2009].

  • 17

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    Tabelle 3: Vorschlag fr eine im Archiv gefhrte Fachverfahrensliste

  • 18 AUFSTZE

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    18

    auch die Unternehmen verpflichtet, sie sollen die personenbezo-gene Datenspeicherung nach innen und auen transparentermachen. Fr die Bewertung interessante Angaben sind: solche zurZweckbestimmung der Datenerhebung, zu den betroffenen Perso-nengruppen, zum Datentransfer an andere Stellen sowieLschungsregeln und fristen. Zustzliche Angaben zu den Fach-verfahren kann der Archivar auch ber die Internetseiten derHersteller erfahren.Fr eine einheitliche, archivbezogene Erfassung von Fachver-fahren, die kontinuierlich aktualisiert werden kann, ist jedoch eineigens erstelltes Verzeichnis der Fachverfahren sinnvoll. Vereinzeltkonnten sich schon archivische Formen fr Erfassungslisten vonFachverfahren bereits herausbilden.38 Die Angaben der inTabelle 3 enthalten Vorschlge fr ein Fachverfahrensverzeichnisstammen aus einem Projekt an der FH Potsdam.Die Liste zeigt, dass die IT-Referate einen groen Anteil bei derErfassung von Fachverfahren haben und die Zusammenarbeit mitihnen von groer Wichtigkeit fr die Archivierung von Daten-bankinhalten ist. Die Liste dient der Abfrage und kann ebenso alsInterviewleitfaden genutzt werden. Aus ihren Angaben lassen sichneben der Archivwrdigkeit auch die Archivierungsobjekte undbestimmte Archivierungsstrategien ableiten.Die vorgeschlagene Fachverfahrensliste lsst abschlieendeBewertungsentscheidungen zu und vermeidet eine Datenbankau-topsie bzw. zeitaufwndige Behrdenbesuche. Fr archivwrdigbefundene Datenbankinhalte werden dann in Zusammenarbeitmit den Behrden und IT-Referaten in Abhngigkeit von Archiv-wrdigkeit und -fhigkeit nher spezifiziert. Hierbei ist die Festle-gung der Bewertungstiefe von Bedeutung, die mglichst auf derEbene der nutzerspezifischen Sichten erfolgen sollte. Kassationenund die alleinige bernahmen auf Ebene der Datenfelder oderTabellen hingegen knnen die Datenbankstruktur bzw. die ber-lieferungseinheit zerstren.

    DATABASE ARCHIVING - A CONCEPTUAL ANDPROTOTYPICAL SOLUTION, DEVELOPED BY THEFH POTSDAM

    Today a growing amount of relevant information for archiving isstored in the public administrations in databases. Databases repre-sent a new type of digital objects, which are characterized by theirdynamic and interactive behavior. According to the OAIS model theinformation object is generated by a particular view of the datastored in the database, while the representation information is a

    Prof. Dr. Rolf DsslerFH PotsdamFachbereich InformationswissenschaftenFriedrich-Ebert-Str. 414467 PotsdamTel. +49 (0)331 580 1512E-Mail: [email protected]

    Dr. Karin SchwarzFH PotsdamFachbereich InformationswissenschaftenFriedrich-Ebert-Str. 414467 PotsdamTel. +49 (0)331 580 1528E-Mail: [email protected]

    specific database query. The long-term preservation of the integrityand authenticity of these information objects in a system-indepen-dent and readable format and is an important new challenge for thepreservation of digital information. The goal of database archiving istherefore the preservation of information objects, instead of a simpledatabase backup.This article describes migration strategies for the archiving of data-base applications and the advantages and disadvantages of variouspreservation approaches. We discuss the characteristics of relationaldatabases and present a reference model for the automatic transferand storage of both digital data and the representation information.Our model is compliant with the OAIS framework for digital preser-vation. In addition, we present criteria for the appraisal of databaseapplications and a metadata catalog for the acquisition of informa-tion objects from database applications.

    38 Vgl. bspw. die Empfehlungen der regionalenArbeitskreiseOstwestfalen-LippeundMnsterland auf der Homepage des LWLArchivamt frWestfalen unter:www.lwl.org/LWL/Kultur/Archivamt/Archiv_IT/Elektronische_Fachverfahren/ [Zugriff: 12. 12. 2009].

  • 19

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    DIGITALE ARCHIVIERUNGBEIM LANDESARCHIVBADEN-WRTTEMBERGvon Christian Keitel

    Das Landesarchiv Baden-Wrttemberg hat sich in den letztenJahren mit wachsender Intensitt der Archivierung digitalerUnterlagen zugewandt. An dieser Stelle sollen die bisherigenErgebnisse mitgeteilt werden. Dabei werden die einzelnenEntwicklungsstrnge durch ein 20062008 entwickeltes Metada-tenkonzept zusammengehalten. Das Konzept erlaubt es, die unter-schiedlichen konzeptionellen und praktischen berlegungen inein gemeinsames Bild zu integrieren. Durch den Begriff derReprsentationen wird es auerdem mglich, konventionelle unddigitale Unterlagen in einem einheitlichen System nachzuweisenund zu verwalten.

    ERSTE SCHRITTEber elektronischen Unterlagen diskutierte die baden-wrttem-bergische Archivverwaltung erstmals 1974.1 Viele der damalsentwickelten Vorstellungen haben ihre Gltigkeit bis heute nichtverloren. Unter anderem sei die rechtliche Zustndigkeit derArchivverwaltung fr diese neuen Unterlagen zu begrnden. 1987konnte ein erster Erfolg verzeichnet werden: Das Landesarchivge-setz erklrte, dass maschinenlesbaren Unterlagen ebenso wiekonventionelle Unterlagen anzubieten seien. Eine zweite Etappewar 1998 mit dem Entscheid des Landesbeauftragten fr Daten-schutz erreicht, dass die vom Statistischen Landesamt erhobenenBundesstatistiken (d. h. Statistiken, die auf einem Bundesgesetzberuhen) ebenfalls ohne Ausnahme anbietungspflichtig seien.Parallel dazu wirkte die Landesarchivdirektion dabei mit, dass diein der Landesverwaltung geltenden Aussonderungsbestim-mungen nun auch die digitalen Unterlagen einschlossen. Die1998 erlassene Verwaltungsvorschrift Schriftgut sah auch einePflicht zur Beteiligung der Landesarchivverwaltung bei derEinfhrung neuer Systeme vor.2

    In diesen Neuerungen schlgt sich nicht zuletzt das seit den1990er Jahren gestiegene Interesse der Landesarchivdirektionnieder. Im Jahr 2000 wurde zudem ein Archivassessor damitbeauftragt, in zwei Jahren mit 50 % seiner Arbeitszeit eineKonzeption zur Archivierung elektronischer Unterlagen zuerstellen.3 Eine der Aufgaben war es, Vorschlge fr die knftigeOrganisation der digitalen Archivierung zu machen. Konntendenn in allen Archiven Kapazitten fr die Archivierung digitalerUnterlagen aufgebaut werden? Angesichts der sehr spezifischen

    Anforderungen, die die Archivierung digitaler Daten einfordert,war diese Option nicht umsetzbar. Es erschien aussichtslos, dienotwendigen Ressourcen zeitgleich sechsmal in der Archivverwal-tung aufzubauen. Auf der anderen Seite war vllig klar, dass diesechs Staatsarchive auch weiterhin alle Unterlagen der ihnengegenber anbietungspflichtigen Stellen bewerten sollten.Schlielich sollten die von einer Stelle bernommenen Unterlagenunabhngig von ihrer analogen oder digitalen Verfasstheitgemeinsam im Lesesaal des zustndigen Staatsarchivs vorgelegtwerden knnen. Das Dilemma aus zentraler Aufbereitung undSpeicherung einerseits und dezentraler Bewertung und Benut-zung andererseits wurde konzeptionell durch ein fr alle Staatsar-chive zugngliches Intranet aufgelst.4 Damit war es mglich, dieweitere Ausgestaltung der digitalen Archivierung arbeitsteiliganzugehen. Im Jahr 2003 wurde im Staatsarchiv Ludwigsburgeine halbe Stelle geschaffen, die sich fortan der bernahme undArchivierung digitaler Unterlagen widmete.Diese Entwicklungen wurden seit den 1980er Jahren vonStimmen begleitet, die die Erfolgsaussichten der digitalen Archi-vierung zunehmend skeptisch beurteilten. Beispielsweisebestimmt das Landesarchivgesetz, dass die neuartigen Unterlagenvon den Archivaren nur nach Vereinbarung mit der abgebendenBehrde bernommen werden sollten. In der Begrndung zumGesetzestext wird das Ziel formuliert, dass sowohl aus Grndendes Datenschutzes als auch aus Wirtschaftlichkeitserwgungen in

    1 Protokoll der Tagung Automation in der ffentlichen Verwaltung und diestaatlichen Archive. Veranstaltet von der Staatlichen ArchivverwaltungBaden-Wrttemberg am 15. und 16. Oktober 1974 in Stuttgart, masch.schftl.

    2 Gemeinsame Verwaltungsvorschrift der Ministerien ber die Verwaltung desSchriftguts der Behrden, Dienststellen und sonstigen Einrichtungen desLandes (VwVSchriftgut), GABl. vom 29. Juli 1998, Nr. 10, S. 354356.

    3 Christian Keitel, Die Archivierung elektronischer Unterlagen in der baden-wrttembergischen Archivverwaltung. Eine Konzeption, 2002,http://www.landesarchiv-bw.de/sixcms/media.php/25/keitel_elektroni-sche_konz.pdf, Abruf 1. 12. 2009. Die Konzeption wurde vor ihrer Verffentli-chung in der Landesarchivdirektion diskutiert und denMitarbeiterinnen undMitarbeitern der Archivverwaltung vorgestellt. Die Kommentare wurden indie Verffentlichung eingearbeitet.

    4 Christian Keitel, Zugnglichkeit contra Sicherheit? Digitale Archivalien zwi-schen Offline-Speicherung undOnline-Benutzung, 2002, http://www.landes-archiv-bw.de/sixcms/media.php/25/zugaenglichkeit%20con-tra%20sicherheit.pdf , Abruf 1. 12. 2009. Auch ders., Die Archivierung elektro-nischer Unterlagen... (wie Anm. 3).

  • 20 AUFSTZE

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    20

    der Regel nicht alle angebotenen gleichfrmigen Unterlagen ber-nommen werden.5 Vergleichbare Befrchtungen schienen beiden Papierunterlagen nicht angebracht. Hatte 1974 noch die gutmgliche Finanzier- und Umsetzbarkeit des Vorhabens im Vorder-grund gestanden, so rckten nun die Bedenken ins Blickfeld. Inden 1990er Jahren schienen sich die Befrchtungen immer mehrzu besttigen. Auch nach der Wende zum neuen Jahrzehnt bedeu-tete die Beschftigung mit dem Thema vor allem eines: Zunchstmusste den zahlreichen Bedenken begegnet werden, die Aufgabesei zu gro, nicht finanzierbar oder schlicht auerhalb jederUmsetzungsmglichkeit durch die Archive.

    Ende 2005 stellte der baden-wrttembergische Landtag dannGelder fr ein auf drei Jahre angelegtes Projekt bereit, mit demdie Grundlagen fr die digitale Archivierung im LandesarchivBaden-Wrttemberg gelegt werden sollten.6 Trotz aller Vorar-beiten musste bei der Planung des Projekts festgestellt werden,dass das Landesarchiv bei der digitalen Archivierung weitgehendhandlungsunfhig war. Zwar konnten seit 2002 einige Statistikenvom statistischen Landesamt bernommen werden.7 StabileVerfahren, die eine bernahme, Aufbereitung und Archivierungvon digitalen Unterlagen in grerem Umfang erlaubt htten,waren jedoch noch nicht entwickelt. bernahme und Archivie-rung waren daher die Bereiche, in denen die Handlungsfhigkeitdes Landesarchiv vorrangig hergestellt werden musste. Siestanden im Mittelpunkt des Projekts Konzeption fr ein digitalesLandesarchiv.

    ARCHIVIERUNGAnfang 2006 wurden ein Informatiker und ein Archivar einge-stellt und die Projektarbeit begonnen.8 Im Staatsarchiv Ludwigs-burg wurde ein Produktivsystem auf Festplattenbasis mit einerSpeicherkapazitt von knapp 5 Terrabyte eingerichtet. Kopien derDaten werden seitdem auf zwei baugleiche Systeme in Stuttgartund zeitweise auch in Karlsruhe berspielt. Wie oben skizziert,sollten die Staatsarchive auf das Archivierungssystem zugreifenknnen. Das System sollte daher im Browser aufrufbar sein.

    Der Aufbau eines digitalen Archivs kann auf zwei unterschiedli-chen Wegen erfolgen, die sich vor allem in der Reihenfolge der zuunternehmenden Schritte unterscheiden. Eine Mglichkeit ist es,zunchst Metadatenkonzept und Archivierungssystem nur freine Objektart aufzubauen. Der Vorteil dieses Verfahrens liegt inder Mglichkeit, System und Konzept exakt an die Anforderungendieser Objektart (z. B. elektronische Akten) anzupassen. Frandere Objektarten muss dieses System erweitert oder verndertwerden. 2006 standen in Baden-Wrttemberg jedoch schonverschiedene Objektarten zur bernahme an. Archivierungs-system und Metadatenkonzept sollten daher von Anfang an fralle denkbaren digitalen Objektarten ausgelegt sein. Die so zuerzielende Handlungsfhigkeit wurde hher gewichtet als die mitdieser Option verbundenen Nachteile (umfangreichere konzeptio-nelle Vorarbeiten und zunchst geringere Anpassung an dieAnforderungen einer speziellen Objektart).

    Aus der Papierarchivierung sind in manchen Archiven ber-nahmen bekannt, die auch nach vielen Jahren noch unerschlossenin einer Ecke des Magazins liegen. Bei der digitalen Archivierungist hnliches kaum denkbar, da Informationen, die bei der ber-nahme noch leicht verfgbar sind, bereits nach kurzer Zeit nichtmehr rekonstruiert werden knnen. Ohne diese Metadaten isteine Erhaltung und Benutzung digitaler Archivalien nicht

    mglich. Vermieden werden sollte daher die bernahme von digi-talen Unterlagen (Primrdaten) mit der Absicht, diese spter erstdurch Metadaten zu beschreiben. Das Archivierungssystem solltealso die Aufnahme neu bernommener Objekte sehr leicht undohne groen Aufwand mglich machen. Es sollte nur wenigAnlass bieten, diese Aufgabe auf spter zu verschieben. EinigeMetadaten waren daher bereits bei der erstmaligen Speicherungder bernommenen Unterlagen anzugeben, die Zahl der Pflicht-felder war aber mglichst niedrig zu halten.9

    Eine frhzeitige Aufnahme ins System unmittelbar nach der ber-nahme bedeutete jedoch, dass es mglich sein sollte, im Zuge derAufbereitung, d. h. bei der Erstellung der Archivierungspakete,weitere Metadaten ins System einzugeben. Das System solltedaher auch diesen Aufbereitungsbereich umfassen. Ein eigenerabgetrennter Aufbereitungsbereich, wie dies in manchen Vorstel-lungen anderer digitaler Archive vorgesehen ist, wurde fr dasArchivierungssystem nicht konzipiert. Stattdessen arbeitet dasSystem mit den Elementen Status und Version. Whrend derErstellung des Archivierungspaketes steht der Status auf In Bear-beitung. Nach Abschluss dieser Arbeiten wird er auf abge-schlossen gestellt und das Archivierungspaket eingefroren.Wenn nun dennoch Metadaten ergnzt werden sollen, wird diealte Datei nicht mehr berschrieben. Stattdessen wird eine neueVersion der Datei erstellt. Diese Differenzierung macht einerseitseine Aufbereitung der Archivierungspakete mglich, andererseitsverhindert sie, dass ein Archivmitarbeiter spurlos und irreversibeldigitale Archivalien verndern kann.10

    Die im Archivierungssystem vorgesehene Metadatenerhebungsorgte dafr, dass parallel zum technischen System ein logischesMetadatenkonzept entwickelt werden musste. Dieses Konzeptkann die teilweise sehr unterschiedlichen Vorgaben, berle-gungen und Systeme aus den verschiedenen Bereichen der digi-talen Archivierung integrieren, da diese stets auf Metadatenzurckgreifen mssen. Es erscheint daher nicht bertrieben, inden Metadaten den konzeptionellen Kern der digitalen Archivie-rung beim Landesarchiv Baden-Wrttemberg zu sehen, an denalle bisher nur lose verbundenen Einzelteile andocken konnten.Ausgangspunkt des Metadatenkonzepts war die berlegung,konventionelle und digitale Archivalien zusammen nachzuweisen.Benutzer und Archivare sollten auf der Suche nach Unterlagennur in einem System recherchieren mssen. Konzeptionell bedeu-tete dies, konventionelle und digitale Archivalien in denselbenFindbchern nachzuweisen. Technisch war die Folge, dass dasgeplante Archivierungssystem mittel- und langfristig in das imLandesarchiv Baden-Wrttemberg eingesetzte Nachweissystem(MIDOSA21) integriert bzw. mit dessen Bestandteilen scopeAr-chiv und OLF 21 verbunden werden sollte. Sollte nicht sogar nachdem Prinzip eines fr alle ein System angestrebt werden, dassowohl den Nachweis aller Archivalien als auch die Archivierungdigitaler Unterlagen ermglichte? Hierfr unterschieden sich dieAnforderungen an die beiden Aufgaben dann doch zu stark.Geplant wurde daher mit zwei unterschiedlichen Systemen. Frdie Dauer des Projekts schien es auch nicht mglich, einerseitsdas Archivierungssystem aufzubauen und dieses zugleich in diebestehenden Komponenten von MIDOSA21 zu integrieren. Ange-strebt wurde daher ein Stand-Alone-System mit der Aussicht aufeine sptere Integration in MIDOSA21.Whrend der Konzeption des Archivierungssystems wiederholtesich die bei der Systemarchitektur des Landesarchivs gefhrteDiskussion ein weiteres Mal. Das System sollte einerseits demArchivar eine komfortable Verwaltung der Archivalien ermgli-

  • 21

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    chen. Hier lag eine Datenbanklsung nahe. Auf der anderen Seitesollte ebenso wie in allen anderen Bereichen der digitalen Archi-vierung die Zahl der Abhngigkeiten mglichst gering gehaltenwerden. Fr die Aufgabe der Archivierung schien daher ein Datei-system besser geeignet zu sein als eine Datenbank. Sollte dasArchivierungssystem nicht mehr verwendbar sein, wrendennoch alle Archivierungspakete vorhanden und aufrufbar. Frdie Speicherung in einer Datenbank gilt dies nicht. Verwaltungs-aufgaben und Sicherungsaufgaben erforderten also unterschied-liche Softwarelsungen. Als Anforderung wurde daher definiert,dass zentrale, das System steuernde Metadaten in einer Daten-bank, diese und alle anderen Metadaten sowie die Primrdaten ineinem Dateisystem abgelegt werden sollten.

    Mit den genannten Anforderungen ging die Projektgruppe daran,die verfgbaren Archivierungssysteme zu testen. 2006 war keinspeziell fr Archive entwickeltes System erhltlich. Die fr Biblio-theken entwickelten Systeme wie FEDORA, DAITTS oder DSpaceerfllten die genannten Anforderungen nicht oder htten aufwn-dige Nachprogrammierungen erfordert. Nach den Tests wurdedaher beschlossen, eine Eigenentwicklung anzustreben. Im Rck-blick erscheint dieses Vorgehen auch aus einem anderen Grundgerechtfertigt. Die Eigenentwicklung des Systems machte esmglich, in einem iterativen Prozess konzeptionelle Anforde-rungen und technische Umsetzung so zu entwickeln, dass sie sichwechselseitig voranbrachten. Im Juni 2006 nahm das DigitaleMagazin DIMAG seinen Betrieb auf. Die genannten Anforde-rungen werden erfllt. Ende 2009 speichert DIMAG etwa 17.000digitale Archivalien und ber 57 Millionen Datenstze. Archiviertwerden unter anderem Textdokumente, digitale Bestandteile vonHybridakten, polizeiliche Ermittlungsunterlagen, Daten auseinem frhen Registraturverwaltungssystem, von den Behrdengescannte Unterlagen, Daten aus Fachverfahren und Geoinforma-tionssystemen, digitale Fotos und statistische Mikrodaten.

    METADATENDIMAG verwaltet drei verschiedene Gruppen von Metadaten:MD5-Werte, Protokolldaten und brige Metadaten.11 Fr die ersteGruppe ermittelt das System von jeder Datei einen elektronischenFingerabdruck in Form eines MD5-Hashwertes und speichertdiesen mit demselben Dateinamen (und anderer Dateierweite-rung) im Dateisystem ab. Nach jeder Vernderung der Datei (z. B.Erweiterung der Metadaten) wird der vernderte Fingerabdruckin die MD5-Datei gespeichert. Der Fingerabdruck wird bei jedemAufruf einer Datei neu ermittelt und mit dem gespeichertenFingerabdruck verglichen. Dasselbe Verfahren ist allen Prozessenzur Datensicherung auf den beiden externen Servern vorge-schaltet. Es verhindert, dass unmittelbar im Dateisystem vern-derte Dateien ebenso wenig wie aufgrund eines Festplattendefektsbeschdigte Dateien auf die Sicherungsserver gespielt und dortvorhandene unversehrte Dateien berschrieben werden.

    Die bisherigen Erfahrungen legen es nahe, dass auch in Zukunftmit jeder neuen Computergeneration die Verarbeitbarkeit ltererDateiformate und Softwareprogramme schwinden wird. DenArchiven bleibt daher nur die Mglichkeit, entweder berspezielle Programme (Emulatoren) knftigen Rechnern einVerstndnis der heutigen Software zu ermglichen oder die altenErscheinungsformen regelmig in aktuellere Formen zu ber-tragen. Das Landesarchiv folgt wie die meisten digitalen Archivedem zuletzt genannten Ansatz (Migrationsstrategie). Heutige

    Software wird dabei nicht archiviert. Fr die Beschreibung derdigitalen Archivalien bedeutet dies, dass manche Bestandteilemglichst alle Zeitlufe berdauern sollten (Informationen, daseigentliche Ziel der Archivierung) und andere Bestandteile regel-mig hinzukommen. Diese Erscheinungsformen der Informa-tionen werden in Anlehnung an den PREMIS-Standard12 Repr-sentationen genannt. Die Reprsentation fungiert bei digitalenArchivalien wie ein gedachter Container, der eine beliebige Zahlan Dateien umfasst. Sobald eine in der Reprsentation gespei-cherte Datei aufgrund ihres Dateiformats in der Gefahr steht, inwenigen Jahren nicht mehr von dann gngigen Computernverstanden zu werden, muss eine neue Reprsentation mitDateien in neuen Dateiformaten erstellt werden. Auch in dieserneuen Reprsentation soll sich die zu erhaltende Information inihren wesentlichen Teilen unverndert ausprgen.13

    Eintrge zu Tektonik und Klassifikation, zum Archivale, zurReprsentation und zu den einzelnen Dateien knnen als struktu-rierte Metadaten verstanden werden. Stets wird eine inhaltlichabgegrenzte Informationseinheit in einem nur dafr reserviertenFeld erfasst. Darber hinaus bernimmt ein Digitales Archiv oftnoch eine Vielzahl weiterer Angaben, die in einer unstruktu-rierten Form vorliegen. Handbcher mit ihren vielfltigen Infor-mationen sind nur ein Beispiel fr diese Art von Metadaten. DieseForm von Metadaten wird in DIMAG nicht weiter strukturiert.Im Metadatenkonzept wird sie mit dem Begriff der Dokumenta-tion umschrieben. Eine grundstzliche Unterscheidung kannjedoch gemacht werden. Manche Dokumentation bezieht sich aufsehr viele digitale Archivalien. Diese Dokumentation wird zentralin einem besonderen Bereich des digitalen Magazins abgelegt.Sie kann daher auch relativ einfach erweitert werden, was beieiner physischen Speicherung in den Archivierungspaketen nichtder Fall wre. Die Beschreibungen von Dateiformaten, die imArchiv verwendeten Metadatenkonzepte oder einschlgige Anwei-sungen, wie in bestimmten Fllen (z. B. bei Migrationen) zuverfahren ist, sind Beispiele fr diesen Dokumentationstyp. Dieauf ein einzelnes digitales Archivale bezogene Dokumentationwird dagegen in eigenen Dateien als Bestandteil der Reprsenta-tionen gespeichert. 2006 war auerdem noch erlaubt, auf jeder

    5 LArchG 3 Abs. 2. Gesetzentwurf der Landesregierung (10. 7. 1986), in: Her-mann Banasch (Bearb.), Archivrecht in Baden-Wrttemberg, Stuttgart 1990, S.101125, hier S. 108.

    6 Nach einer einjhrigen Verlngerung endete das Projekt im Dezember 2009.7 Christian Keitel, Baden-wrttembergische Archivverwaltung beginnt mit derelektronischen Archivierung. Volkszhlung 1970 als erstes digitales Archivaleim Staatsarchiv Ludwigsburg archiviert, Der Archivar 57 (2004), S. 315.

    8 Das Projektteam bestand aus Rolf Lang (Informatiker), Dr. Kai Naumann(Archivar) und dem Verfasser (Projektleiter).

    9 Christian Keitel, Ways to Deal with Complexity, Beitrag zur iPRES-Konferenzan der British Library, 2008, http://www.bl.uk/ipres2008/presentati-ons_day2/45_Keitel.pdf, Abruf 1. 12. 2009.

    10 Zahlreiche Sicherheitsprobleme in IT-Unternehmen gehen auf ein gewolltesoder unbeabsichtigtes Fehlverhalten der Mitarbeiter zurck.

    11 Metadaten fr die Archivierung digitaler Unterlagen, 2008, http://www.lan-desarchiv-bw.de/sixcms/media.php/25/konzeption_metadaten10.pdf, Abruf1. 12. 2009, Kai Naumann, Christian Keitel und Rolf Lang, One for Many: AMetadata Concept for Mixed Digital Content at a State Archive, The Interna-tional Journal of Digital Curation 2 Vol. 4 (2009), S. 80-92,http://www.ijdc.net/index.php/ijdc/article/viewFile/120/123, Abruf 1. 12.2009.

    12 Vgl. Preservation Metadata: Implementation Strategies (PREMIS),http://www.loc.gov/standards/premis/, Abruf 1. 12. 2009.

    13 Mit dem Reprsentationmodell sollen im Landesarchiv Baden-Wrttembergauch die Erscheinungsformen konventioneller Archivalien (Original, Mikro-film, Scans) beschrieben werden. Bei konventionellen Reprsentationen wirdkein Container, sondern unmittelbar der Datentrger nachgewiesen.

  • 22 AUFSTZE

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    22

    Beschreibungsebene von Tektonik und Klassifikation eine sepa-rate Dokumentationsdatei zu erstellen. Der Vorteil groer Flexibi-litt brachte jedoch das Problem mit sich, auerhalb der Repr-sentationen Dateien verwalten zu mssen, die nicht eine berge-ordnete Tektonikebene reprsentierten. Im Jahr 2007 beschlossdas Projektteam daher, knftig auf separate, auerhalb der Repr-sentationen gefhrte Dokumentationsdateien zu verzichten.

    Mit der Definition der einzelnen Beschreibungsebenen war esmglich, die Bestandteile eines digitalen Archivales zielgenauanzusprechen. Sowohl fr die konzeptionelle Weiterentwicklungals auch fr den Anschluss von DIMAG an MIDOSA21 war damiteine wesentliche Vorarbeit geleistet. Die einzelnen Bestandteilesollten aber nicht nur fr Menschen verstehbar klassifiziert sein,sie sollten auch von Maschinen eindeutig identifiziert werdenknnen. Diese Identifikation muss ber sehr lange Zeitrumezuverlssig funktionieren. Das Landesarchiv entwickelte daher einSystem persistenter archivischer Identifikatoren.14 Diese AIDswerden von dem System, in dem ein Datensatz neu erstellt wird,vergeben und in die Metadaten eingetragen. Sie bleiben durch denganzen Lebenslauf der Archivalien unverndert. Da sie in dieMetadaten geschrieben werden, haben auch eine Abgabe an einanderes Archiv oder die berfhrung des Datensatzes in einNachfolgesystem keine Auswirkungen auf die AIDs. Die AIDbesteht aus zwei Teilen. Ein erster Teil enthlt eine eindeutigeKennnummer fr das erstellende System. Der zweite Teil enthlteine Kennnummer, die innerhalb des Erstellungssystemseindeutig ist.

    Digitale Bestandserhaltung bedeutet, dass die Daten relativ hufigzum Erhalt der Information aktiv bearbeitet oder verndertwerden. Diese Prozesse mssen fr jedes einzelne Archivale nach-vollziehbar in Protokollen beschrieben werden. Als Dateiformatbot sich ebenso wie bei den strukturierten Metadaten XML an.Zu jedem digitalen Objekt wird ein Protokoll erstellt. In diesesProtokoll werden auch alle wesentlichen Prozesse eingetragen, diesich auf die zugehrenden Reprsentationen oder Dateienbeziehen. Fr alle zu protokollierenden Prozesse oberhalb derArchivalienebene wurde ein Protokoll auf der obersten Ebene desDateisystems eingerichtet. Beide Protokolltypen enthalten nurfnf Felder: Prozessende und ausfhrender, Bezug (Strukturein-trag, digitales Objekt, Reprsentation oder Datei), Prozess undNhere Angaben. Die Protokolle sollen die digitalen Archivaliendurch ihre gesamte Lebenszeit hindurch begleiten und folglichnicht mit berflssigen Informationen aufgeblht werden.Backup-Prozesse und Benutzungen werden daher nicht protokol-liert. Festgehalten werden die Prozesse der Einstellung in dasDIMAG, einer Status-nderung, einer nderung der Metadaten(sofern der Status auf abgeschlossen steht) und einer Migration.In diesen Fllen erstellt DIMAG das Protokoll automatisch. DerArchivar kann diese und auch alle schon vorgenommenenEintrge nicht verndern. Er ist aber bei einem Neueintrag in derLage, eine Notiz hinzuzufgen, um das eigene Handeln nachvoll-ziehbar zu machen. Eine Notiz kann auch einen selbstndigenEintrag im Protokoll darstellen.

    BEWERTUNG UND BERNAHMENach mehreren exemplarischen Bewertungsprojekten in denJahren 2003 bis 2005 war klar, dass sich in den Behrden einegroe Menge archivreifer und teilweise auch archivwrdiger digi-taler Unterlagen finden lsst.15 Klar war auch, dass es nicht ausrei-

    chen wrde, sich nur auf die Beteiligung des Landesarchivs beider Einfhrung neuer Systeme zu verlassen. Zu selten konntedieser Schritt erfolgreich begangen werden. Stattdessen musste einSet unterschiedlicher Verfahren entwickelt werden, die eine ber-nahme auch in den Fllen erlauben, in denen das Landesarchivnicht bei der Systemeinfhrung beteiligt worden war.Die Methoden zu Bewertung und bernahme sollten in demProjekt Konzeption fr ein digitales Landesarchiv anhanddieser Daten und nicht mit Hilfe von Spieldaten gewonnenwerden. Zunchst konnte die bernahme, Aufbereitung undArchivierung der Daten nicht ohne Verluste hinausgeschobenwerden. Als das Projektteam Ende 2006 beispielsweise die Stra-enbauverwaltung besuchte, erklrte diese, man habe die Rechnermit der alten (bereits auf der Tagung 1974 vorgestellten) Straen-datenbank nur wegen des angekndigten Besuchs noch nichtabgeschaltet und verschrottet. Fr die Echtdaten sprachauerdem, dass sich die Projektgruppe 2006 erst eine bersichtber die mglichen Probleme erarbeiten musste. Spieldatenbringen es mit sich, dass sie manchmal die praxisrelevantenProbleme nicht enthalten und in anderen Fllen Fragen nahelegen, die in der Praxis gar nicht auftreten wrden.Sowohl die Bewertung als auch die bernahme digitaler Objektekonnten gut in Form einzelner Teilprojekte organisiert werden.Bei der Bewertung war es wichtig, die Kompetenz der fr dieabgebende Stelle zustndigen Kolleginnen und Kollegen einerseitsund das Wissen um technische Systeme und die Archivierbarkeitdigital gespeicherter Information andererseits gegenseitig abzu-stimmen. Besonders hoch ist der Abstimmungsbedarf bei denFachverfahren, da die Daten aus ihrer Umgebung extrahiertwerden mssen. Bei der Bewertung dieser Verfahren hat sich dieArbeit in Teams mit jeweils einem Vertreter des zustndigenArchivs und der Projektgruppe sehr bewhrt.Wer hatte nun den Export der Daten aus den Fachverfahren zuleisten? Viele Archive sehen darin zurecht eine Aufgabe der abge-benden Stellen. Andererseits waren die Techniker dieser Stellenaufgrund fehlender eigener Kenntnisse teilweise nicht in der Lage,fr die Archivierung geeignete Datenexporte herzustellen. Im Laufedes Projekts traten als Fehler unter anderem auf: Export derfalschen Datenbank (viele Daten liegen in mehreren fast identischenVersionen eines Fachverfahrens vor), unvollstndiger Export derDatenstze, Weglassen oder Beschneiden einzelner Felder,Weglassen einzelner Zeichen (hufig Umlaute) oder Einfgen vonZeichen, die nicht zum vereinbarten Zeichenformat gehrten (in derRegel UTF-8 oder ASCII). Auch bei der bernahme bewhrte essich daher, mit der abgebenden Stelle ein gemeinsames bernahme-projekt zu vereinbaren, in dem IT-Vertreter der abgebenden Stellemit einem IT-Fachmann des Landesarchivs zusammen in ein biszwei Wochen den Export der Daten besorgten. Verglichen mit denFllen, in denen die abgebende Stelle den Export alleine zu leistenhatte, war die Zahl der bei der Projektvariante zu berwindendenWiderstnde weitaus geringer.Nach den bisher gemachten Erfahrungen liegt das zentraleProblem bei der bernahme von Daten aus Fachverfahren in derbersetzung der archivarischen Bewertung in die zugrundelie-genden Datenstrukturen. In der Regel hat nmlich der Archivarseine Bewertung anhand der Datensichten vorgenommen, die sichauch dem Benutzer in der Behrde bieten. Gespeichert werden dieDaten in einer davon unabhngigen und daher oft anders struk-turierten Datenbank. Aus ihr mssen die zu archivierenden Datenextrahiert werden. Wie lassen sich also die Benutzersichten aufdie Datenbankschicht bertragen? Das hierfr erforderlicheWissen

  • 23

    ARCHIVAR 63. Jahrgang Heft 01 Februar 2010

    liegt zum Teil bei den Herstellern des Programms und zum Teil beiden Behrden, manche Informationen lassen sich auch indirekterschlieen. Auch die Verteilung des fr eine bernahme notwen-digenWissens legt daher ein kooperatives Vorgehen nahe.

    DIGITALE ARCHIVALIENWann ist ein Archivale ein digitales Archivale? Als Arbeitshypotheseging das Projektteam davon aus, dass immer dann von digitalenArchivalien die Rede sein sollte, wenn diese in digitaler Form vomLandesarchiv bernommen wurden. In anderenWorten liegt demLandesarchiv bei einem Verlust der Daten nichts mehr vor, was eineWiedergewinnung der Information ermglichen wrde. Glaubwr-digkeitsuntersuchungen knnen sich aus demselben Grund nichtauf ein analoges Original beziehen. Digital bernommene Archiva-lien erfordern daher eine hhere Datensicherheit und andereProzesse zum Erhalt der Authentizitt als vom Archiv vorgenom-mene Scans von ihren analogen Geschwistern.16 Unwesentlich ist beidieser Definition jedoch, ob die digitalen Archivalien in der abge-benden Stelle in digitaler Form entstanden sind oder zunchst aufPapier vorlagen, dann aber noch vor der Anbietung digitalisiertwurden.bernommene digitale Archivalien werden grundstzlich als Repr-sentation 1 abgelegt. Dies geschieht auch dann, wenn die darinverwendeten Dateiformate aller Wahrscheinlichkeit nach nur einegeringe Eignung zur Archivierung besitzen. In diesen Fllen wirdunmittelbar nach der bernahme eine zweite Reprsentation mitbesser geeigneten Dateiformaten erstellt. Drei Grnde sprechen frden Erhalt der bernommenen Dateien als Reprsentation 1:Zunchst knnten die archivischen Bearbeiter bei einer MigrationFehler machen. Wenn diese erst nach einiger Zeit auffallen, bestehtzumindest die theoretische Mglichkeit, die Migration noch einmalneu aufzu