Digital långtidslagring < LÅNGTIDSLAGRING AV ADB UPPTAGNINGAR Underlag för framtagning av kravspecifikation för leveranser av data ur ADB - system och rutiner kring långtidsbevarande Vid framtagning av underlaget användes dels gällande föreskrifter i Riksarkivets författningssamling, dels praktisk erfarenhet av bevarande av data levererad under åren 1999-2003 till Region- och Stadsarkivet Göteborg. REGION- OCH STADSARKIVET GÖTEBORG 2005 INNEHÅLLSFÖRTECKNING Sammanställning över grundkrav ...........................................................................................5 Databärare: CD-skivor av typ CD-R (SS-ISO 10149).......................................................................................5 Arkivfilformat...........................................................................................................................................................5 Dokumentation: systemdokumentation och förståelsedokumentation..........................................................6 Metadata för långtidsbevarande ............................................................................................................................6 ADB-system relaterade förutsättningar för bevarande ...........................................................7 Kategorier av ADB-upptagning ............................................................................................................................7 Avställning av inaktiva uppgifter och avställning vid avveckling.....................................................................7 Avställning och migrering till arkivdatabas..........................................................................................................7 Handlingar och datamängder vid avställning ......................................................................................................8 Datamängder och arkivvolymer, teknisk proveniens.........................................................................................8 Rutiner kring ADB-leveranser och långtidslagring................................................................9 Kontroll av data vid leverans (bilagor 1A – 1D) ................................................................................................9 Registrering av digitala leveranser i dataliggaren.................................................................................................9 Konvertering av data...............................................................................................................................................9 Arkivdatabas .............................................................................................................................................................9 Rutiner kring ADB-leveranser: SCHEMA ........................................................................................................10 Ett praktiskt fall: Elev och betygshistorik 1989-2001 f.d. ELIN ...........................................11 Bakgrund.................................................................................................................................................................11 Arkivering (långtidsbevarande)............................................................................................................................11 Arkivdatabas ELIN ...............................................................................................................................................11 Bilaga 1A: Leveransexempel (mediatyp: magnetisk media) ...........................................................................12 Bilaga 1 B: Kontroll av arkivfilformat : exportfilen för tabellen BETYG från ELIN ...............................13 Bilaga 1C: Kontroll av datarepresentation i en arkivfil: förekomst av styrtecken.......................................14 Bilaga 1D: Kontroll av dataorganisation i en arkivfil : exportfilen för tabellen SKOLA från ELIN ......15 Bilaga 2A: Registrering av dataleverans i leveransliggaren ..............................................................................16 Bilaga 2B: Registrering i dataliggaren .................................................................................................................17 Bilaga 3A: ELIN-databaser i Göteborgs kommun, översikt ..........................................................................18 Bilaga 3B: Tabeller i Elin, översikt......................................................................................................................23 Bilaga 4A: Databärare, CDR med ELIN-arkivfiler..........................................................................................24 Bilaga 4B: Databärare, biblioteksstruktur på ELIN-arkivcd...........................................................................25 Bilaga 4C: Arkivfilexempel (arkivfil från ELIN – CD) ...................................................................................26 Bilaga 5A: Postbeskrivning : förståelsedokumentation på arkiv-CD ............................................................27 Bilaga 5B: Transaktionsbeskrivning för arkivfiler ............................................................................................28 Bilaga 6A: Arkivdatabas –ELIN : rekonstruktion från arkivfiler...................................................................29 Bilaga 6B: Datastruktur och relationer i arkivdatabasen ELIN .....................................................................30 Bilaga 7A: Sökbilder i arkivdatabasen ELIN.....................................................................................................31 Bilaga 7B: Elev- och betygshistorik i arkivdatabasen ELIN...........................................................................32 Bilaga 7C: ELIN arkivprojekt, sammanfattning: avställning ..........................................................................33 Bilaga 7D: ELIN arkivprojekt, sammanfattning: arkivbildning och förteckning........................................34 Kravspecifikation för arkivdatafiler....................................................................................... 35 Något om arkivterminologin ...............................................................................................................................35 Definition................................................................................................................................................................35 Dataformat (filformat, teckenrepresentation, kodning av tecknens binära mönster) ................................35 Datastruktur och dataorganisation......................................................................................................................36 Metadata och dokumentation..............................................................................................................................36 Kommentarer .........................................................................................................................................................36 Bilaga 1: Arkivfilformat för elektroniska dokument ........................................................................................39 Leverantörsberoende format: 39 Leverantörsoberoende: format (ISO) 39 Dokumentbildformat 40 Standardisering: referenser 40 Bilaga 2: Rekommendation för arkiv-CDR .......................................................................................................43 Databärare för långtidsbevarande 44 Dataorganisation och namnutrymme i ADB arkivet............................................................ 45 1. 2. 3. 4. Hierarkisk och flat dataorganisation..............................................................................................................45 Konsekvenser vid datamigrering , mediagenerationsskifte: ......................................................................45 I online-arkiv skikt kan en systemberoende hierarki tillämpas med fördel.............................................45 Kravspecifikation och namnutrymme i ett ADB-arkiv..............................................................................46 Avställning av data ur Profdocsystemet, principer ............................................................... 47 Långtidsbevarande av data ...................................................................................................................................47 Funktion för snabb åtkomst av avställda Profdocjournaler ...........................................................................48 Motivering...............................................................................................................................................................48 Avställning av räkenskaper ................................................................................................... 49 Avställningsrutiner steg för steg..........................................................................................................................49 Kontroll av dataintegritet vid avställning av räkenskaper ...............................................................................50 Bilder: .................................................................................................................................... 51 Bild 1: ADB-upptagning och ADB-system, dokument- och process schema.............................................51 Bild 2: Datamängder och arkivvolymer vid avställning...................................................................................52 Bild 3: Baskategorier av ADB-upptagning och arkivfiler vid avställning .....................................................53 Bild 4: Systemkategorier och dokumenttyper vid avställning.........................................................................54 Bild 5: ORM Model för ett ADB-arkiv..............................................................................................................55 Bild 6: Långtidslagring av ADB-upptagningar, Orsak och Verkan Diagram...............................................56 Bild 7: Regionarkivets ADB-Arkiv .....................................................................................................................57 Bild 8: Regionarkivets arkivserver för räkenskaper.........................................................................................58 Bild 9: Uppbyggnad av långtidslagring, lägesbeskrivning, skiss .....................................................................59 Bild 10 Schema för arkivdokumenthantering i ADB-Arkivet........................................................................60 Bild 11 Handling- och dokumentstruktur vid bevarande i ADB-arkivet .....................................................61 Ansvar vid Regionarkivet: Jerzy Misiewicz tel: 031-701 19 67(direkt) e-post: [email protected] Region- och Stadsarkivet Göteborg Box 2154, 403-13 Göteborg Web: http://www.arkivnamnden.se Dokument skapat 2005-05-12 Sammanställning över grundkrav Komplement till Regionarkivets kravspecifikation från 1999-06-09 (se sid. 35: Kravspecifikation för arkivdatafiler, se även exempel på aktuell tillämpning på sid. 36: Avställning av data ur Profdocsystemet, principer,) Databärare: CD-skivor av typ CD-R (SS-ISO 10149) - data kan bara skrivas en gång på CD-ROM / CD-R media och går ej att radera, det är viktigt att skilja mellan CD-ROM (kräver mastering och en viss upplaga) och CD-R (bränns i valfritt antal) - dataorganisation på CD-ROM och CD-R media regleras av ISO 9660 standard [SS-ISO 9660: 1988 Datadisposition - CD-ROM - Volym- och filstruktur] (bl.a. filnamn får inte vara längre än 8 tecken + 3 för filtypbeteckning och får innehålla endast tecken {A..Z, 0..9, _}, ISO Level 1) - arkivfiler bör förses med unika filnamn vid avställning och ordnas i en flat biblioteksstruktur på databäraren (motivering: se sid. 45, Dataorganisation och namnutrymme i ADB-arkivet) - CD-R som innehåller avställd data bör framställas i flera exemplar (minst två) av godkänd för långtidslagring media (aktuell rekommendation: se sid. 43) Arkivfilformat - teckenpresentation i en arkivfil är systemoberoende och regleras av ISO-8859-1 (Latin 1) standard för 8 bitars teckenuppsättning (får ej förväxlas med DOS Latin1, IBM format, utökad ASCII) - dataorganisation: sekventiell textfil där varje datarad utgör en dataenhet (post) av en viss fast bredd, som består av ett antal dataelement (fält) med fast bredd (kolumner i arkivfilen.) med undantag för dokumentdatabaser där avställning sker på dokumentnivå - styrtecken (tecken i ascii område 0-31 decimalt, 0-1F hexadecimalt) får ej förekomma i arkivfiler då dessa är systemberoende med undantag för nedstegningstecken (eller radbyte, <LF> Line Feed, ascii värde: 0A hexadecimalt, 10 decimalt) och radreturtecken (<CR>, Carriage Return, ascii värde: 0D hexadecimalt, 13 decimalt). OBS: i vissa andra arkivfiler, som t.ex. konverterade bilagor, även tecken för sidbyte <FF>, (Form Feed, ascii värde 0C hexadecimalt, 12 decimalt) - diverse länkade och inbäddade elektroniska dokument / dokumentbilagor i leverantörsberoende format, som saknar fördefinierad logisk struktur (typ DTD), såsom dokument skapade med ordbehandlare, dokumentmallar, blanketter, tabulerade dokument, kalkylblad och liknande bör i första hand konverteras till ISO 8859-1 textfiler . - för att bevara ovan nämnda dokumentens specifika egenskaper, stil, layout, överstrykningar, understrykningar, grafiska logotyper, signaturer m.m. bör dessa även konverteras till dokumentbilder vid sidan om arkivfiler i textformat vilket garanterar att dokument kan läsas i framtiden och skrivas ut i originalskick (autenticitet), och kringgår sådana problem som beskrivning av dokumentets utseende (som style sheet i XML: XLS), arkivbevarande av proprietära, licensierade typsnitt tillsammans med dokument m.m. Ett lämpligt ISO- standardformat för detta är TIFF, undergrupp TIFF group 4 (TIFF CCITT group 4, se sid. 40, Leverantörsoberoende format), ett format som används för lagring av stora volymer av inskannade dokument av standard A4 format som journaler, fakturor och liknande. 5 Dokumentation: systemdokumentation och förståelsedokumentation Ur Riksarkivets leveransbok: : (Kapitel 4.3) Annan dokumentation För ADB-upptagningar gäller att • ett representativt urval av den dokumentation som har upprättats under driften av systemet eller sammanställts, och • en dokumentation över framställningen av ADB-upptagningarna skall bifogas. I praktiken krävs: - systemdokumentation: från det ursprungliga ADB-systemet: pärmar, manualer, användarhandböcker med beskrivning av in- och utdata, beskrivning av rutiner för registrering- och uttag (formulär, rapporter, skärmbilder mm), sökrutiner mm - förståelsedokumentation på arkiv-CD: tabellöversikt, postbeskrivning med förklaring för varje kolumn/fält i klartext, transaktionsbeskrivning Metadata för långtidsbevarande När det gäller metadata så saknas det i leveransböcker rekommendationer på detaljnivå likvärdig den som gäller arkivhandlingar på papper och mikrofilm. Om man bortser från SGML, som är gällande standardformat för bevarande av strukturerad information, då majoriteten av befintliga ADB-system saknar implementering av datauttag i SGML-format, finns det ingen annan standard för metadata för långtidsbevarande. (XML, som är mera lätthanterlig och således kostnadsmässigt mera realistisk substandard av SGML, är inte riktigt etablerad än). Däremot finns ett antal de facto industristandarder som huvudsakligen utvecklades i praktisk databashantering och för migrering av information i samband med systemgenerationsskifte. Av dessa är SQL-standarden den mest kraftfulla men samtidigt i högt grad leverantörsberoende. (numera ISO-standard, se sid.40: Standardisering: referenser) Vad som återstår är ett antal leverantörsoberoende tekniker som utvecklades vid export och import av data mellan olika databasmiljöer (export och import i ASCII textformat). För att kunna bevara struktur, sammanhang och mening i datamängder avställda från ADBsystem till arkivfiler krävs det att kvarlevor av dessa system (arkivdata) kompletteras med någon form av metadata och förståelsedokumentation som skulle lagras digitalt tillsammans med arkivfiler på CD-R. I det första fallet handlar det om information som möjliggör maskininläsning av arkivfiler (transaktionsbeskrivning) och återskapande av information på ett strukturerad och sammanhängande sätt (datastruktur- / postbeskrivning, relationer, indexering) vilket gör i sin tur återinförande av strukturerad sökbarhet möjligt. I det andra fallet gäller det dels att ha tabell- och kolumnöversikter för alla avställda tabeller som metadata på arkiv-cd, men även att all slags yrkes- och verksamhetsorienterad kodning av information (förmodligen helt obegriplig i framtiden) kan läsas i klartext och tolkas rätt. (värdelistor /tabeller för dessa koder bör finnas i avställd datamängd som separata arkivfiler och följaktligen även tabell- och kolumnöversikter för koddelar med förklaringar i klartext). 6 ADB-system relaterade förutsättningar för bevarande Kategorier av ADB-upptagning Beroende på det ursprungliga systemets specifika egenskaper kan olika kategorier av ADB-upptagning urskiljas: - Enkelt dataregister, en helt flat struktur och ingen normalisering. Kräver ingen strukturering av information som skall arkiveras, d.v.s. bevaras i sin helhet. Avställd data ligger i en datafil med en posttyp. Exempel: Rosinante (register över utbetalad socialhjälp m.m., tidigt 1980-tal) - Hierarkiskt dataregister: hierarkisk datastruktur av typ Parent-Child (Huvudpost-Delpost). I det ursprungliga systemet binds data med fysiska pekare. Enda sättet att ställa av data är att dumpa hela strukturen i en arkivfil där huvudposter ligger sekventiellt ordnade med alla tillhörande delposter, m.a.o. arkivfilen innehåller två olika posttyper. Posttypen kan tex. urskiljas tack vare etikettmärkning (label-märkning) av huvudposter och delposter. (Exempel: Socialförvaltningens diarium Albert eller PÄR- diarium för Skaraborgs läns landsting, Mariestad) - Enkel relationsdatabas. Ett fåtal tabeller med få relationer mellan tabellerna. En sådan databas är skräddarsydd för sitt ändamål och innehåller endast relevant information, skall därför bevaras på samma sätt som enkelt dataregister, i sin helhet. (exempel: Ärendehanteringssystem ÄHSV i Vänersborg (diarium för Älvsborgs läns landsting) eller Göteborgs stads grundskoleelevregister ELIN. - Stora, komplexa (anpassningsbara) relationsdatabaser med en stor mängd (hundratals) tabeller och relationer. Dessa kräver analys och förstudier, strukturering av arkivinformation, provleveranser, och gallring av uppgifter som ej skall bevaras. Kräver kvalificerad expertis och konsulthjälp då risken för informationsförlust uppstår när urval för arkivering genomförs. (Exempel: Göteborgs stads system för studiedokumentation inom vuxenutbildning GERDA) Avställning av inaktiva uppgifter och avställning vid avveckling Vidare behöver man skilja på bevarande av information från ADB-system som tas helt ur drift (tex. nedlagda föråldrade ADB-system) och ställs av i sin helhet och datasystem som ställs av delvis genom periodiskt datauttag och under fortsatt drift. I det andra fallet måste den delen av data som tas med i avställningen vara strukturerad på ett sådant sätt att kontinuiteten av information kan bevaras mellan avställningarna och så att inga informationsförluster uppkommer. Hantering av urvalsfrågor som tas till hjälp vid en sådan avställning ligger på expertnivå och kräver konsulthjälp. En bred kunskap om relationsdatabaser krävs även hos arkivarier för att strukturera information som skall arkiveras på ett rätt sätt (kunskap om normalisering, indexering, relationer m.m.) Generellt arkivering utav äldre datasystem kan vara arbetsmässigt omfattande och tidskrävande. Datasystem som installerades på 90-talet har däremot, tack vare tex. inbyggd stöd för ODBC (Open database connectivity) bättre förutsättningar för långtidsbevarande rent tekniskt, då data kan tas ut / ställas av från en annan plattform, även via fjärruppkoppling. Således uppstår möjlighet för direkt migrering av data till en arkivdatabas. Avställning och migrering till arkivdatabas Migrering till en arkivdatabas borde ses som ett komplement till avställning och inte som ett alternativ till långtidsbevarande på ett arkivmässigt korrekt sätt, d.v.s. anpassning och långtidslagring av data i ett leverantörsoberoende arkivfilformat (ISO) och med hjälp av standardiserad och arkivbeständig media. Däremot bör åtkomsten till arkiverade datamängder alltid upprättas genom en arkivdatabas som fullständigt baserar på den ordningen som skapades vid avställning. 7 Handlingar och datamängder vid avställning När handlingar som diarieförda ärenden, betyg, journaler, räkenskaper blir bundna till ADB-teknik förvandlas dessa via systemteknisk bearbetning såsom objekt- och datamodellering, normalisering och programmering till datamängder därvid handlingen blir uppdelad i diverse dataobjekt . Ett betyg t.ex. ligger uppdelat i flertal relaterade tabeller, eftersom ämne, kurs, elev, tentamen, kursmall är olika objekt i systemet och representerar information som kan samlas och sammanställas endast av själva programmet i ett dokument som betyg eller betygskatalog . Det är en utpräglad ADB-teknisk ordning som gäller i datasamlingen i ett IT-system. I arkivhanteringen däremot ordnar man kompletta handlingar i enlighet med proveniens efter arkivbildare, serier och volymer då dessa skall sparas för alltid såsom ordnade dokument. Eftersom det är i programskiktet som handlingar återskapas från underliggande datamängder i ett ADB-system, och programskiktet går ej att långtidsbevara, måste datamängder anpassas för långtidslagring, struktureras på ett särskilt sätt, konverteras, dokumenteras o.s.v. Datamängder blir föremål för avställning, överföring till en ordning och format särskild anpassade för långtidslagring. Datamängder som ställs av skall dels bevaras i sin strukturerad form som arkiverat registerdata för att bevara ADB-tekniska informationsegenskaper, framför allt strukturerad sökbarhet och även i form av dokumentuttag (såsom vid utskrift) om det vid avställning går att genomföra ett dokumentuttag till datafiler. (Se sid.47 Avställning av data ur Profdocsystemet, principer). Således säkras både handlingarnas sökbarhet och autenticitet vid avställningen. Datamängder och arkivvolymer, teknisk proveniens Datamängder i ett ADB-system genererar arkivvolymer på liknande sätt som handlingar på papper även om de digitala volymer kan rymma flera hundra hyllmeter av papper och även om digitala volymer p.g.a. framtida förflytningar mellan databärare ej kan fixeras på samma sätt jämförelsevis. Förteckningsmässigt innehåller volymen av data avställd t.ex. från sociala tjänstens informationssystem, en årlig tömning av inaktiva uppgifter från alla ärende, som var avslutade vid tidpunkten fem år före avställningen alternativt, att inga nya handlingar har tillförts ärende under de fem år som föregått avställningen (se Bild 2. Datamängder och arkivvolymer, sid. 52) Normalt åtföljs avställningen av data från socialtjänstens informationssystem med utplockning och motsvarande avställning och leverans till arkivmyndigheten av den pappersbundna delen av socialakten som finns hos den berörda sociala myndigheten. Digitala media, t.ex. CD-R skivor, har till skillnad från papper och papperskartonger en begränsad beständighet och variabelt kapacitet (utrymme). Ett digitalt medium typ CD-R, som används idag har plats för data som för 15 år sedan krävde flera hundra 3.5 tums disketter. För att kunna hålla sig till begreppet volymer på ett arkivmässigt korrekt sätt vid förteckning av handlingar i det digitala beståndet bör man betrakta volymer i beståndsregistret såsom luftvolymer, då endast en hänvisning görs i arkivförteckningen till ett annan liggare som definierar och avgränsar de egentliga fysiska digitala volymer, förtecknar dessa, följer upp mediamigrering och annan behandling samt anger plats där media bevaras (dataliggare) (se även Bilaga 7D- ELIN-arkivprojekt, sammanfattning: arkivbildning och förteckning, sid.34). En annan viktig faktor vid den digitala arkivbildningen är teknisk proveniens. Det är ganska vanligt idag att ett IT-system omfattar data från flera olika arkivbildare och att själva systemet förvaltas och administreras av en annan myndighet, organisation eller företag (som sköter systemets drift men även kontrollerar och säkerställer den egentliga arkivbildningen). Detta återspeglas i arkivförteckningen med en hänvisning till den arkivbildande myndighetens /organisationens arkiv (arkivnummer) från samtliga berörda arkivbildare. (se bilaga 7D- ELINarkivprojekt, sid.34) Vid avställning av data från ett sådant IT-system som omfattar flera arkivbildare bör handlingar tillhörande respektive myndighet skiljas åt och datamängder som tas ut anpassas efter detta. 8 Rutiner kring ADB-leveranser och långtidslagring Kontroll av data vid leverans (bilagor 1A – 1D) - kontroll av media (mediaformat och läsbarhet) säkerhetskopiering av media (ofta levereras i ett exemplar) kontroll av arkivfilformat, datarepresentation och dataorganisation kontroll av förekomst av styrtecken i arkivfiler kontroll av metadata / dokumentation Registrering av digitala leveranser i dataliggaren - för innehåll se bilaga 2A och 2B observera att journal för bevakning av avställda ADB-upptagningar är inbyggd i dataliggaren (behandlingsjournal och omlagringshistorik) där all behandling och utlåning registreras. Konvertering av data - teckenrepresenation i 7-bitars ASCII och 8-bitars utökad ASCII format kräver konvertering av levererade filer till ISO-8859-1 och framställning av nya arkivfiler/ nya CD-R skivor i efterhand med korrekt teckenrepresentation för långtidsbevarande. Om det ursprungliga systemet saknar stöd för export i fast bredd filformat kan data först ställas av tex. som koma avgränsade poster med citationstecken för fältdata (utan transaktionsbeskrivning) och sedan läsas in på nytt (tex. i Access ) och exporteras på nytt i fast bredd format (korrekt arkivfilformat) därvid transaktionsbeskrivning skapas och sparas med på arkiv-CD-R. (se bilagor 5B, 6A) - data levererad i leverantörsberoende format (program och datafiler) p.g.a. att det ursprungliga systemet saknar helt exportfunktioner kan i vissa fall tas ut med hjälp av utskriftsrutiner (t.ex., totalutskrift) och en omdirigering av utskriftsdata till en textfil i pc-dos format, som sedan kan konverteras till en arkivfil i ISO 8859-1 format - metadata levererat såsom Microsoft Word- eller Excel-filer bör konverteras till utökad ASCII textformat ISO 8859-1 Arkivering på CD-R (cd-bränning) - media som väljs skall vara CD-R-media av känd, och väl uttestad typ (tex. Kodak gold) filstrukturen och filnamn på arkiv-cd måste följa ISO-9660 standard för data CD-ROM alla arkivfiler skall brännas under samma pass / CDR-session som följaktligen måste vara stängd för tillägg minst två exemplar av arkiv-CD skall brännas (original och kopia) med helst två olika mediafabrikat, för att garantera att minst ett exemplar går att läsa i framtiden en rutin för omlagring / duplicering av arkiv-CD skall utarbetas Arkivdatabas När det tekniska arbetet med långtidsbevarande är avslutad bör en arkivdatabas skapas för att möjliggöra snabb framtagning av data/information i samband med förfrågningar från allmänheten eller i samband med forskning. Huvudfördelen med en arkivdatabas / arkivserver är att data från många tekniskt olika plattformer rekonstrueras i en och samma systemmiljö på en arkivplattform (arkivserver) med ett likformigt gränssnitt mot användare (forskare och arkivarier) där internationellt standardiserat frågespråk (SQL.) används för sökning i olika arkivdatabaser (se skärmbilder, bilaga 7A och 7B). Då data inte längre ligger i så många tekniskt olika miljöer kan även WEB- gränssnitt implementeras. Arkivdatabaser med sekretess belagda uppgifter kan tillgängliggöras i arkivverksamheten via en terminal server. Behandlingsjournal, motsvarande den som finns i dataliggaren kopplas till samtliga arkivdatabaser såsom arkivserverlogg. 9 Rutiner kring ADB-leveranser: SCHEMA Nedan presenterad schema ger en förenklad bild av rutiner kring ADB-leveranser och dess hantering. T.ex. begreppet arkivering på CD-R omfattar alla specifika moment vid cd-arkivering, såsom duplicering av media, märkning och registrering av fysiska cd-volymer m.m. 10 Ett praktiskt fall: Elev och betygshistorik 1989-2001 f.d. ELIN (ELevINformation) Bakgrund Fram till december 1997 fanns ingen databas med uppgifter för centrallagring inom Göteborgs kommun. Alla grundskolor hade sina egna lokala Elin-databaser med säkerhetskopior (backup) på disketter som skulle bevaras i tio år (inget bevarande/gallringsbeslut fanns, det var en internt påhittad regel). 2001-10-16 levererades till regionarkivet 84 st. 3.5 tums disketter med Elin databasfiler från respektive rektorsområde med tillhörande grundskolor (sammanlagt 214 skolor från 71 rektorsområde) för åren 1989-2001 plus en IBM/PS2 PC med Elin-programmet samt 2 st. dokumentationspärmar. Arkivering (långtidsbevarande) För att kunna bevara uppgifter från Elin för framtiden återinstallerades Elin-databaser skola för skola i sin ursprungliga miljö på en IBM/PS2 med OS-2 operativsystem och samtliga 27 tabeller ställdes av i koma avgränsat textformat (med citationstecken för fältdata) till arkivfiler, 27 filer för varje rektorsområde. Bevarande av data i koma avgränsat textformat rekommenderas inte bl.a. därför att det förekommer citationstecken och komma i själva fältdata vilket orsakar att datarader kan ej tolkas entydigt (fältordningen inom dataposter bryts). Därför lästes arkivfiler för respektive rektorsområde in i en tom Access-databas, tabell för tabell enligt postbeskrivning i Elin-dokumentationen och exporterades på nytt till arkivfiler såsom flata textfiler med fastbredd både för post och datafält inom en post därvid en transaktionsbeskrivning för varje tabell avställd till arkivfil sparades i textformat såsom metadata gemensam för alla rektorsområde. Arkivdatabas ELIN En arkivdatabas i Access-format (mdb) konstruerades där uppgifter från nyckeltabeller (Elev, Klass, Lärare, Betyg, Nybetyg, Skolgång) sammanfogades och elev- och betygshistorik för hela Göteborg för åren 1989-2001 har åstadkommits med möjlighet at få fram betyg och skolgång för ca. 100 000 registrerade elever med personnummer som nyckel och klasslistor med läsår, årskurs och skolnamn som nyckel. Vidare migrerades Access-databasen med elev- och betygshistorik till en arkivserver (SQL-server) såsom skrivskyddad arkivdatabas. 11 Bilaga 1A: Leveransexempel (mediatyp: magnetisk media) OBS: media ej lämplig för långtidsbevarande Grundskoleelevregister ELIN : 3.5 tums FD-disketter (floppy disk) Dataliggare: media Socialtjänstens register över utbetalt stöd ROSINANTE: 8mm magnetband Dataliggare: media 12 Bilaga 1 B: Kontroll av arkivfilformat : exportfilen för tabellen BETYG från ELIN De ursprungliga ELIN-filer levererades såsom databasens backupfiler på disketter. Databasen för respektive rektorsområde återinstallerades på en OS/2 maskin och därefter exporterades alla tabeller såsom koma avgränsade dataposter till ascii-filer då databasen saknade stöd för export i fast bredd format , och följaktligen blev datarader i arkivfiler av olika längd. Observera att data representeras i exempelfilen med IBM dos-latin 1 och inte ISO 8859-1 13 Bilaga 1C: Kontroll av datarepresentation i en arkivfil: förekomst av styrtecken Förhandsgranskning av innehåll i exportfilen ELEV.TXT från ELIN-databasen för rektorsområde SDF-ÄLVSBORG (OS2-operativsystem, DB2 databas) Kontroll av teckenrepresentation (ASCII-text) , förekomst av styrtecken: Styrtecken markerad på bilden nedan (en högerpil , hexadecimal kod 1A, decimal 26 ) betecknas som SUB (substitute) och upfattas av till exempel Windows OS som filslutmarkering. Detta orsakar ”trunkering ” (avkortning) av arkivfilen vid konvertering till ISO-format och dataförlust (arkivfilen innehåller efter konvertering endast tecken fram till styrtecknet där filen blir avkortad). Ett annat styrtecken av det här slaget är nedåtpil (hexkoden 19, decimal 25) vilket betecknas som EM (End of Medium) OBS: Programmet som används för granskning är en binär editor (redigeringsprogram för stora binära filer) 14 Bilaga 1D: Kontroll av dataorganisation i en arkivfil : exportfilen för tabellen SKOLA från ELIN 15 Bilaga 2A: Registrering av dataleverans i leveransliggaren (se Acc.nr 120/2001 och 121/2001) Leveranskvitto: 16 Bilaga 2B: Registrering i dataliggaren OBS: ett underformulär för bevakning av det digitala arkivet (registrerade arkiv-CD) är inbyggd i dataliggaren (se under fältrubrik Bevarande historik”). Detta förutsätter att det finns en teknisk rutin för omlagring av arkivskivor. 17 Bilaga 3A: ELIN-databaser i Göteborgs kommun, översikt Översikt över ELIN (ELevINformation) databaser i Göteborg Databasen kommer ifrån Skolor i databasen Elin Skolkod SCB kod Kommentar Gårdstensskolan Gårdstensskolan Långmosseskolan GÅGÅ GÅLÅ 11305 25601 Nya Lövgärdesskolan Nya Lövgärdesskolan Räveberget skola Tretjärnsskolan LÖLÖ LÖRÄ LÖTR 12901 25701 25801 Rannebergen Centrumskola Rannebergen Centrumskola RCRC 13502 Rannebergen Södra RCRS 22001 Vättleskolan Gunnaredsskolan Vättleskolan Trädgårdsgärdet VÄGU VÄV VÄTG 22101 22201 32001 Bläseboskolan Bläseboskolan BBB 13001 Bergsgårdsskolan Bergsgårdsskolan BDB 27201 Bergums skola Bergums skola Gunnilseskolan Björsaredsskolan BGBS BGG BGBJ 19001 19002 19003 Eriksboskolan Eriksboskolan ERE 13002 Hammarkullsskolan Hammarkullsskolan Hjällbo Gård Skoldaghemmet Bredfjällsskolan Hammarkullsskolan L-M Röseredsskolan Terapiskolan HAH HAHG HASK HABG HAHK HARÖ HATE 10501 10502 26702 26701 26801 26802 26703 Hjällboskolan Hjällboskolan HJH 10601 Nytorpsskolan Nytorpsskolan NYNY 26601 Gamlestadsskolan Gamlestadsskolan H Gamlestadsskolan LM Heldagsskolan LK Strändängsledet GAGH GAGA GALK GAST 01801 16701 30901 33901 Ramsdalsskolan Ramsdalsskolan KSRA 16602 Utmarksskolan Utmarksskolan K4UT 24901 Talldungeskolan Talldungeskolan Lövåsskolan TATA TALÅ 03501 30801 Fjällboskolan Fjällboskolan Utbynässkolan UTFJ UTUT 16801 27604 18 Bergsjöskolan Bergsjöskolan H Kometskolan Bergsjöskolan LM Backegårdsskolan BEB BEK BEBS BEBM 01901 01903 20601 20801 Gärdsmosseskolan Gärdsmosseskolan GÄ1 20701 Sandeklevsskolan Sandeklevsskolan SN1 10801 Solbackeskolan Solbackeskolan SO1 11501 Kålltorpsskolan Kålltorpsskolan, L M Parkskolan Rosendalsskolan Fräntorpsskolan Vidkärrsskolan Ättehögsskolan Klinikskolan BUP "DUVAN" Kålltorpsskolan H KÅK1 KÅRE KÅR KÅÄ3 KÅÄ4 KÅÄ KÅD KÅK2 01501 01509 31701 31801 31802 31803 31805 31901 Nya Lundenskolan Nya Lundenskolan Gamla Lundenskolan Bagaregårdsskolan Kärralundsskolan Skårsskolan Ånässkolan ÖRLN ÖRGL ÖRBA ÖRK ÖRS ÖRÅ 01601 01602 01604 01605 01606 01607 Buråsskolan Buråsskolan BSBS 00501 Guldhedsskolan Guldhedsskolan Mossebergsskolan Landalaskolan Gustaviskolan GU5 GU6 GU7 GU8 01002 01003 18001 18201 Johannebergsskolan Johannebergsskolan JOJO 17901 Nordhemsskolan Nordhemsskolan NON Annedalsskolan Östra Hagaskolan Västra Hagaskolan NOA NOÖH NOVH 01701 Gamla betygstabellen är skadad går ej att läsas in 18601 18701 18702 Oscar Fredriksskolan Oscar Fredriksskolan Stigbergsskolan Gathenhielmsskolan Mossbergska friluftsskolan Flexgruppen Fjällskolan OFOF OFST OFGA OFMF OFFL OFFJ 02001 02002 02003 02005 02011 35201 Karl Johansskolan Karl Johansskolan H Karl Johansskolan M Djurgårdsskolan M Djurgårdsskolan L Karl Johansskolan L Småbarnsskolan Lilla Karl Johansskolan L Fyrhuset Karl Johansskolan L Karl Johansskolan L KJKJ KJKM KJDJ KJDL KJKL KJKS KJLK KJFY KJK2 KJKK 01301 26101 26102 26103 26201 26201 34201 26104 26210 26204 19 Kungsladugårdsskolan Kungsladugårdsskolan KUK Kungsladugårdsskolan år 0-3 KUK2 21501 34101 Sannaskolan Chapmansskolan Kennedyskolan Sannaskolan år 4-9 Sannaskolan år 0-3 SACH SAK SAS SAS2 02403 02401 02401 34001 Flatåsskolan Flatåsskolan Högsboskolan Kavåsskolan Skytteskolan Västerhedsskolan FLF FLH FLKÅ FLS FLV 00801 28401 23801 24001 23901 Särskolan Eriksboskolan Klaraskolan Glöstorpsskolan, grundsär Gamlestadsskolan/H Glöstorpsskolan; träning Gamlestadsskolan/LoM Grevegårdsskolan Gustafskolan Högsboskolan Högsbogårdsskolan Individintegrerade elever Kannebäcksskolan Kvibergsnäs Kärralundsskolan Lundbyskolan G.a Långedragsskolan Rannebergen Centrumskola Rebeckaskolan, Högsbo Rebeckaskolan/Skytte Renströmska Sjukhuset Rebeckaskolan, Torslanda Skytteskolan Spinettskolan Svartedalsskolan Toleredsskolan Trädgårdsgärdesskolan Utmarksskolan GSER GSGA GSGG GSGH GSGL GSGM GSGR GSGU GSHS GSHÖ GSII GSKA GSKV GSKÄ GSLU GSLÅ GSRC GSRH GSRM GSRS GSRT GSSK GSSS GSSV GSTO GSTR GSUT 21202 34701 14804 21201 29202 21204 21101 21208 28403 29301 00000 24603 29415 29201 14807 21102 21203 29401 29414 29203 29402 24002 14801 14802 14803 21205 21207 Specialpedagogik Högsboskolan, G-klass Kannebäcksskolan Kronängsskolan Nordhemsskolan SPH1 SPKN SPKÄ SPNO 31101 29101 28402 29102 Älvsborgs skolkontor Dalaskolan Fiskebäcksskolan G Påvelundsskolan Hagenskolan Långedragsskolorna Nya Påvelundsskolan Nya Varvets skola ÄLDA ÄLFI ÄLGP ÄLHA ÄLLÅ ÄLNP ÄLNV 02201 28101 28001 27701 27801 27901 28201 Järnbrottsskolan Björkåsskolan Järnbrottsskolan M H Järnbrottsskolan L Slottsbergsskolan JÄB JÄJ JÄJL JÄSL 26402 01201 26401 26301 20 Askimsskolan Askimsskolan Sisjöskolan AMA AMS 19101 19201 Trollängsskolan Hultskolan Lilla Trollängsskolan 1-4 Trollängsskolan ASH ASLT AST 13207 13204 13201 Nygårdsskolan Nygårdsskolan Sandåsskolan Skinteboskolan ND1 ND2 ND3 13401 19401 19501 Lindåsskolan Lindåsskolan NGLS 13802 Hovåsskolan Hovåsskolan 261 13301 Åkeredsskolan Näsetskolan Åkeredsskolan ÅNN ÅNÅ 17001 24701 Ängåsskolan Ängåsskolan ÄNÄ 16901 Önneredsskolan L M Högenskolan Önneredsskolan L M Ö1HÖ Ö1Ö1 11603 11602 Önneredsskolan H Önneredsskolan H Ö2Ö2 17301 Grevegårdsskolan Grevegårdsskolan 1-3 Grevegårdsskolan 4-9 GRG4 GRG5 11201 33401 Österöd Österöd ÖSÖS 29002 Tynneredsskolan Tynneredsskolan TYT1 03101 Vättnedalsskolan Kannebäcksskolan Vättnedalsskolan VDK VDVÄ 24602 17401 Styrsöskolan Brännö skola Asperö skola Styrsöskolan Donsö skola Vrångö skola Kalvhagsskolan ST1 ST2 ST4 ST5 ST6 ST7 13106 13104 13105 13102 13103 13101 Björlandagården Björlandagården BLBL 28901 Lillebyn Lillebyn LBLN 28801 Noleredsskolan Noleredsskolan NRNR 29001 Skutehagen Skutehagen Hällsviks Bycenter Hjuviksgården SH1 SH2 SH3 28303 28302 28301 Torslandaskolan Torslandaskolan TL1 02901 Sjumilaskolan Sjumilaskolan L Sjumilaskolan M BISL BISM 20103 20101 Landamäreskolan Landamäreskolan Landamäreskolan L Landamäreskolan M LALA LALL LALM 20201 20201 20202 21 Ryaskolan Ryaskolan, Profil Bild/Slöjd Ryaskolan, Idrott Ryaskolan Treröseskolan 1-6 RYRB RYRH RYRY RYTR 02301 02301 02301 19803 Svartedalsskolan Jättestensskolan L Jättestensskolan M Jättestensskolan SUG Svartedalsskolan H Svartedalsskolan L Svartedalsskolan M Svartedalsskolan SUG SVJL SVJM SVJU SVSH SVSL SVSM SVSU 16401 16402 16403 02601 02603 02602 02604 Klarebergsskolan Klarebergsskolan Klockareskolan Kärraskolan Lillekärrskolan KLKL KLKS KLKÄ KLLK 12801 25001 16501 22601 Bjurslättsskolan Bjurslättsskolan BJBJ 00201 Bräckeskolan Bräckeskolan BRBR 18501 Lerlyckeskolan Kärrdalsskolan Lerlyckeskolan LEK LEL 19701 19601 Rambergsskolan Rambergsskolan RARA 20501 Toleredsskolan Toleredsskolan TOT 02701 Glöstorpsskolan Bärbyskolan/Humlelyckan Glöstorpsskolan Glöstorpsskolan Gunnestorpsskolan Tångenskolan Backaskolan TUBÄ TUGH TUGL TUGU TUTÅ BAB 26001 25901 03004 03001 26003 01401 Brunnsboskolan Brunnsboskolan Brunnsbo Musikklasser Skogomeskolan BOB BOBM BOS 00301 00301 23501 Erikslundsskolan Erikslundsskolan ELE 17501 Skälltorpsskolan Skälltorpssk/Brudbergssk Brudbergets rektorsområde Bäckebols rektorsområde Skälltorpsskolan Skälltorp/Svenska Balettskolan SKBH SKBR SKBÄ SKS SKSD 17602 17601 17701 10701 10702 Framnässkolan Framnässkolan FRFR 18301 BÖS1 18401 Elin maskinen på Bräcke Östegård gick sönder under vecka 4 2001. Ingen backup fanns av databasen. 18402 Backaskolan Ingen databas kom från Bräcke Östergårdsskolan Bräcke Östergårdsskolan Önneredsskolan BÖÖN 22 Bilaga 3B: Tabeller i Elin, översikt ELIN - Tabellöversikt Tabellnamn -----------AMNE AVIS BETYG CTLELEV ELEV ELEVTPL FASTTPL GRPTILLH GRUPP HEMSPR HSPR_ELV KLASS KOMMUN LARARE NATION NYBETYG PRIMOMR REGKOD REKTOMR SDN SKOLA SKOLGNG SKOLTPL STDPARAM TPLAMNE UOMR VAL Kommentar Kolumnantal ----------------------------------------------------- ----------Ämnestabell 6 Aviseringstabell 33 Gamla Betygtabell 16 Tabell för Central lagring 77 Elevtabell 76 Elevens timplan 24 Timplan fastställd av 5 Grupptillhörighetstabell 8 Grupptabell 13 Hemspråkstabell 4 Hemspråk/Elev 20 Klasstabell 12 Kommuntabell 3 Lärartabell 4 Nationstabell 3 Ny Betygtabell 38 Primärområdestabell 3 Registreringskodstabell 21 Rektorsområdestabell 11 SDN-tabell 8 Skolenhetstabell 12 Skolgångstabell 12 Skolans timplan 14 Standardparametrar 19 Timplansämne LPO94 4 Upptäckningsområdestabell 20 Valtabell 12 23 Bilaga 4A: Databärare, CDR med ELIN-arkivfiler (OBS: för cd-volymmärkning användes särskild märkpenna med permanent bläck. PENOL) Under senare projekt (efter ELIN) märktes alla CDR-skivor med arkivbildarnamn och arkivnummer (leveransnummer) inhämtat från dataliggaren t.ex.: Göteborgs Stad, ADB-Kontoret 27: 01 Arkiv-cd för ELIN brändes i 3 exemplar (två olika CDR fabrikat, Kodak och Fujitsu) Original ex: Kopia 24 Bilaga 4B: Databärare, biblioteksstruktur på ELIN-arkivcd (arkivfiler ligger ordnade per rektorsområde enligt nedan) Arkivfiler består av textfiler motsvarande 27 tabeller i databasen för respektive rektorsområde 25 Bilaga 4C: Arkivfilexempel (arkivfil från ELIN – CD) Förhandsgranskning av innehåll i arkivfilen BETYG.TXT (tabellen BETYG i databasen ELIN) Älvsborgs rektorsområde OBS: filen är konverterad till ISO-8859-1 textformat 780310036691993/94VTBI 83 780310036691993/94VTBL 83Bild 780310036691993/94VTENA 82Engelska allmän 780310036691993/94VTFY 82 780310036691993/94VTGE 83 780310036691993/94VTHA T83Hantverk 780310036691993/94VTHI 83 780310036691993/94VTHK 82 780310036691993/94VTID 82 780310036691993/94VTMAA 82Matematik allmän kurs 780310036691993/94VTRE 82 780310036691993/94VTSH 82 780310036691993/94VTSL 83 780310036691993/94VTSV 82 780310036691993/94VTTK 82 780310036691994/95HTBI 92 780310036691994/95HTBK 9UBarnkunskap 780310036691994/95HTBL 9UBild 780310036691994/95HTENA 92Engelska allmän 780310036691994/95HTFY 91 780310036691994/95HTGE 92 780310036691994/95HTHA T93Hantverk 780310036691994/95HTHI 92 780310036691994/95HTHK 92 780310036691994/95HTID 92 780310036691994/95HTKE 91 780310036691994/95HTMAA 92Matematik allmän kurs 780310036691994/95HTMU 93 780310036691994/95HTRE 92 780310036691994/95HTSH 92 780310036691994/95HTSL 9U 780310036691994/95HTSV 92 780310036691994/95HTTK 92 780310036691994/95VTBI 92 780310036691994/95VTBK 93Barnkunskap 780310036691994/95VTBL 93Bild 780310036691994/95VTENA 92Engelska allmän 780310036691994/95VTFY 91 780310036691994/95VTGE 91 780310036691994/95VTHA T93Hantverk 780310036691994/95VTHI 91 780310036691994/95VTHK 92 780310036691994/95VTID 92 780310036691994/95VTKE 92 780310036691994/95VTMAA 92Matematik allmän kurs 780310036691994/95VTMU 93 780310036691994/95VTRE 92 780310036691994/95VTSH 92 780310036691994/95VTSL 93 780310036691994/95VTSV 92 780310036691994/95VTTK 92 780510497891993/94VTBI 83 19940530 19940530 19940530 19940530 19940530 119940530 19940530 19940530 19940530 19940530 19940530 19940530 19940530 19940530 19940530 19941216 19941216 19941216 19941216 19941216 19941216 119941216 19941216 19941216 19941216 19941216 19941216 19941216 19941216 19941216 19941216 19941216 19941216 19950531 19950531 19950531 19950531 19950531 19950531 119950531 19950531 19950531 19950531 19950531 19950531 19950531 19950531 19950531 19950531 19950531 19950531 19940530 26 1994-05-30-2.16.41.590000 1994-05-30-12.16.40.250000 1994-05-30-12.16.40.650000 1994-05-30-12.16.41.780000 1994-05-30-12.16.42.150000 1994-05-30-12.16.43.460000 1994-05-30-12.16.42.340000 1994-05-30-12.16.40.840000 1994-05-30-12.16.41.210000 1994-05-30-12.16.41.400000 1994-05-30-12.16.42.530000 1994-05-30-12.16.42.710000 1994-05-30-12.16.42.870000 1994-05-30-12.16.43.060000 1994-05-30-12.16.41.930000 1994-12-16-11.51.47.310000 1994-12-16-11.51.45.590007 1994-12-16-11.51.45.810000 1994-12-16-11.51.46.030000 1994-12-16-11.51.47.500000 1994-12-16-11.51.48.150000 1994-12-16-11.51.49.650007 1994-12-16-11.51.48.340000 1994-12-16-11.51.46.250000 1994-12-16-11.51.46.690007 1994-12-16-11.51.47.720000 1994-12-16-11.51.46.900000 1994-12-16-11.51.47.120000 1994-12-16-11.51.48.560000 1994-12-16-11.51.48.750000 1994-12-16-11.51.48.940000 1994-12-16-11.51.49.150000 1994-12-16-11.51.47.940000 1995-05-31-09.42.08.440000 1995-05-31-09.42.08.100007 1995-05-31-09.42.08.160000 1995-05-31-09.42.08.190000 1995-05-31-09.42.08.500000 1995-05-31-09.42.08.600000 1995-05-31-09.42.09.130007 1995-05-31-09.42.08.630000 1995-05-31-09.42.08.220000 1995-05-31-09.42.08.310007 1995-05-31-09.42.08.530000 1995-05-31-09.42.08.380000 1995-05-31-09.42.08.410000 1995-05-31-09.42.08.910000 1995-05-31-09.42.08.940000 1995-05-31-09.42.08.970000 1995-05-31-09.42.09.030000 1995-05-31-09.42.08.560000 1994-05-30-15.09.08.810000 Bilaga 5A: Postbeskrivning : förståelsedokumentation på arkiv-CD (tabellen BETYG i ELIN) (OBS: sparas på cd-n i leverantörsoberoende format d.v.s. en ISO-formaterad textfil) Postbeskrivningen utgör en del av metadata (se även transaktionsbeskrivning, bilaga 5B) 27 Bilaga 5B: Transaktionsbeskrivning för arkivfiler (arkivfiler BETYG.TXT och NYBETYG.TXT, export av Elin-databastabeller BETYG och NYBETYG i fastbreddformat) Tabellnamn ---------BETYG Fältnamn -------PNR SEKEL LASAR TERMIN AMNESKOD TYP ARSKURS BETYG BETYGTXT SORTFLT REGDAT REGSIGN FTERMIN FARSKURS FBETYG TIDSTMP Börja ----1 11 12 19 21 25 26 27 28 58 59 69 72 74 75 76 Bredd ----10 1 7 2 4 1 1 1 30 1 10 3 2 1 1 26 Tabellnamn ---------NYBETYG Fältnamn -------PNR SEKEL LASAR TERMIN BLD HEM IDR MUS SLD SVE ENG MAT SO GEO HIS REL SAM NO BIO FYS KEM TEK SV2 SPR SPRAMNESKOD SPRAMNESTXT CSP CSPAMNESKOD CSPAMNESTXT HSP HSPRKOD HSPRTXT LRENAMN1 LRENAMN2 TIDSTMP Börja ----1 11 12 19 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 45 75 76 80 110 111 114 134 170 206 Bredd ----10 1 7 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4 30 1 4 30 1 3 20 36 36 26 28 Bilaga 6A: Arkivdatabas –ELIN : rekonstruktion från arkivfiler Transaktionsbeskrivning för arkivfilen utgör ett underlag vid rekonstruktion: alla arkivfiler läses in i en arkivdatabas Kontroll och import av arkivfil BETYG.TXT (tabellen BETYG i databasen ELIN) Älvsborgs rektorsområde till en arkivdatabas Transaktionsbeskrivning / import – specifikation: Tabellnamn ---------BETYG 1 11 12 Fältnamn -------PNR SEKEL LASAR TERMIN AMNESKOD TYP ARSKURS BETYG BETYGTXT SORTFLT REGDAT REGSIGN FTERMIN FARSKURS FBETYG TIDSTMP 19 21 25 26 27 28 Börja ----1 11 12 19 21 25 26 27 28 58 59 69 72 74 75 76 58 59 Bredd ----10 1 7 2 4 1 1 1 30 1 10 3 2 1 1 26 69 72 74 75 76 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 780310036691993/94VTBI 83 19940530 1994-05-30-2.16.41.590000 780310036691993/94VTBL 83Bild 19940530 1994-05-30-12.16.40.250000 780310036691993/94VTENA 82Engelska allmän 19940530 1994-05-30-12.16.40.650000 780310036691993/94VTFY 82 19940530 1994-05-30-12.16.41.780000 780310036691993/94VTGE 83 19940530 1994-05-30-12.16.42.150000 780310036691993/94VTHA T83Hantverk 119940530 1994-05-30-12.16.43.460000 780310036691993/94VTHI 83 19940530 1994-05-30-12.16.42.340000 780310036691993/94VTHK 82 19940530 1994-05-30-12.16.40.840000 780310036691993/94VTID 82 19940530 1994-05-30-12.16.41.210000 780310036691993/94VTMAA 82Matematik allmän kurs 19940530 1994-05-30-12.16.41.400000 780310036691993/94VTRE 82 19940530 1994-05-30-12.16.42.530000 780310036691993/94VTSH 82 19940530 1994-05-30-12.16.42.710000 780310036691993/94VTSL 83 19940530 1994-05-30-12.16.42.870000 780310036691993/94VTSV 82 19940530 1994-05-30-12.16.43.060000 780310036691993/94VTTK 82 19940530 1994-05-30-12.16.41.930000 780310036691994/95HTBI 92 19941216 1994-12-16-11.51.47.310000 780310036691994/95HTBK 9UBarnkunskap 19941216 1994-12-16-11.51.45.590007 780310036691994/95HTBL 9UBild 19941216 1994-12-16-11.51.45.810000 780310036691994/95HTENA 92Engelska allmän 19941216 1994-12-16-11.51.46.030000 780310036691994/95HTFY 91 19941216 1994-12-16-11.51.47.500000 780310036691994/95HTGE 92 19941216 1994-12-16-11.51.48.150000 780310036691994/95HTHA T93Hantverk 119941216 1994-12-16-11.51.49.650007 780310036691994/95HTHI 92 19941216 1994-12-16-11.51.48.340000 780310036691994/95HTHK 92 19941216 1994-12-16-11.51.46.250000 780310036691994/95HTID 92 19941216 1994-12-16-11.51.46.690007 780310036691994/95HTKE 91 19941216 1994-12-16-11.51.47.720000 780310036691994/95HTMAA 92Matematik allmän kurs 19941216 1994-12-16-11.51.46.900000 780310036691994/95HTMU 93 19941216 1994-12-16-11.51.47.120000 780310036691994/95HTRE 92 19941216 1994-12-16-11.51.48.560000 780310036691994/95HTSH 92 19941216 1994-12-16-11.51.48.750000 780310036691994/95HTSL 9U 19941216 1994-12-16-11.51.48.940000 780310036691994/95HTSV 92 19941216 1994-12-16-11.51.49.150000 780310036691994/95HTTK 92 19941216 1994-12-16-11.51.47.940000 780310036691994/95VTBI 92 19950531 1995-05-31-09.42.08.440000 780310036691994/95VTBK 93Barnkunskap 19950531 1995-05-31-09.42.08.100007 780310036691994/95VTBL 93Bild 19950531 1995-05-31-09.42.08.160000 780310036691994/95VTENA 92Engelska allmän 19950531 1995-05-31-09.42.08.190000 780310036691994/95VTFY 91 19950531 1995-05-31-09.42.08.500000 780310036691994/95VTGE 91 19950531 1995-05-31-09.42.08.600000 780310036691994/95VTHA T93Hantverk 119950531 1995-05-31-09.42.09.130007 780310036691994/95VTHI 91 19950531 1995-05-31-09.42.08.630000 29 Bilaga 6B: Datastruktur och relationer i arkivdatabasen ELIN Elev- och betygshistorik 1989 – 2001 för grundskolor inom Göteborgs kommun - - Arkivdatabasen består av nyckeltabeller från Elin och vyer (hjälptabeller som skapades i arkivdatabasen med uppgifter sammansatta från flera olika Elins arkivtabeller), KLASS_vy tex innehåller uppgifter om varje klass med namn på klassföreståndare och skapades genom sammansättning av tabeller KLASS och LÄRARE från ELIN. Relationer utgör ett skelett för ELIN- arkivdatabas, med hjälp av relationer går det att visa hela skolgången (från låg- och mellan- till högstadieskola) för en vald elev och samtliga grundskolebetyg på en och samma arkivregisterbild, bläddra och söka snabbt i arkivdatabasen. Arkivdatabasens funktionalitet kan m.a.o. endast åstadkommas genom skicklig rekonstruktion och hantering av relationer mellan arkivtabeller då det ursprungliga systemets funktioner går ej att bevara med arkivfiler (de försvann i samma ögonblick som data ställdes av). Det som man lyckas återskapa med hjälp av relationer i arkivdatabasen är sammanhang och sökbarhet i arkiverad datamängd, viket är huvuduppgift i den digitala arkiveringen förutom bevarande av själva data. I alla väl normaliserade datasystem är relationsstrukturen klar och lätt att genomskåda vilket gör arbete med långtidsbevarande betydligt lättare än i sådana fall där själva programmet stod för informationens integritet och sammanhang. 30 Bilaga 7A: Sökbilder i arkivdatabasen ELIN Sökning av klasslista med Läsår, Årskurs / Klass och Skolnamn som nyckel: 31 Bilaga 7B: Elev- och betygshistorik i arkivdatabasen ELIN (skapad från samtliga ELIN-arkivfiler, databasen omfattar åren 1989-2001.) För varje registrerad elev visas både skolgång och betyg från gamla respektive nya betygssystemet; nya betyg registrerades sedan 1997, höstterminen. Arkivserver: skrivskyddad arkivdatabas ELIN (Read Only format) 32 Bilaga 7C: ELIN arkivprojekt, sammanfattning: avställning 33 Bilaga 7D: ELIN arkivprojekt, sammanfattning: arkivbildning och förteckning 34 REGIONARKIVET Jerzy Misiewicz tfn 031-701 19 67 Kravspecifikation för arkivdatafiler Något om arkivterminologin Gallring innebär att handlingar eller uppgifter (datamängder) förstörs definitivt på ett sådant sätt att de aldrig kan återskapas. Avställning innebär att handlingar eller uppgifter (datamängder) uttages (exporteras) från t ex ett närarkiv eller från en databas för att långtidsarkiveras i t ex ett centralarkiv eller i en arkivdatabas. Om man gallrar i en databas förstör man uppgifter. Om man avställer uppgifter förstörs inte dessa utan överförs först till arkivformat och sedan till arkivmedia för långtidsbevarande. Åtkomsten till data bevaras i form av en särskild arkivdatabas som baserar på informationsurvalet genomförd vid avställning. Definition Gallring, rensning, avställning m.m. 17 § arkivförordningen Med avställning menas att handlingarna överförs till en ordning (ett format) som är särskilt avpassad för slutlig långtidslagring. Först och främst är det databaser som oftast behöver avställas innan leverans. Data i en avställning består således av registerdata, metadata och / eller elektroniska dokument konverterade till ett leverantörsoberoende format (ISO -, ISO/IEC -, SS-ISO standard) Dataformat (filformat, teckenrepresentation, kodning av tecknens binära mönster) Data bör (enligt Riksarkivets rekommendationer) avställas såsom flata textfiler i 8-bitars textformat enligt ISO 8859-1 standard. I det tidigare vanliga ascii (IBM/PC-Dos) formatet för textfil kodas landspecifika (diakritiska) tecken på ett annat sätt och det är operativsystemets inställningar som avgör hur tecknen tolkas, d.v.s. först när man har deklarerat vilken utökad ASCII tabell (Code Page) som används blir tolkning av tecken entydig. ISO 8859 formatet däremot åstadkommer leverantörsoberoende och entydig teckenkodning genom att dela upp teckenuppsättningar i så kallade Latin-grupper (Latin1=8859-1, Latin2=8859-2 o.s.v.). Dos-Latin1 (Code Page 850) och ISO Latin-1 avser samma språkgrupp men behandlar olika tecken som ligger utanför 7-bitars ascii (0-127) teckenuppsättning där de landspecifika tecknen lagras. Elektroniska dokument och dokumentbilagor som lagras i ett leverantörsberoende format i sin helhet i ett IT-system (tex. Word dokument eller Excel kalkylblad) bör konverteras till ISO 8859-1 textformat (en arkivfil per dokument). Dessa dokument och bilagor bör även konverteras till dokumentbilder i TIFF format (lämpligen TIFF CCITT Group 4 undergrupp för standard A4 svart-vit dokument). 35 Datastruktur och dataorganisation Poster som avställs (registerdata) skall ligga i flata textfiler med en posttyp per arkivfil och fast postlängd, d.v.s. om databasen innehåller flera olika tabeller (relationsdatabas) bör avställning ske på tabellnivå och tabellerna lagras separat, var i sin textfil. Fältlängden inom en post i arkivfilen kan variera men de skall ha fast bredd och följaktligen blir postlängden samma för alla poster av en viss posttyp i en arkivfil. Det är transaktionsbeskrivning som bestämmer postlängden i en arkivfil. Arkivfiler skapade enligt ovan bör vid avställning överföras till en arkivbeständig digital media (i två exemplar) ordnade i en flat biblioteksstruktur med unika filnamn. Digital långtidslagring förutsätter omkopiering av media och migrering av arkivdata vilket är tekniskt lättare att genomföra med flat dataorganisation och unika filnamn (högre säkerhet vid automatisk databehandling). Transaktionsbeskrivning är en postbeskrivning av en post såsom den har lagrats i arkivfilen d.v.s. namn på alla fält inom en post, offset (relativ position i dataraden) och antal tecken (fältlängd). Transaktionsbeskrivning skiljs således från postbeskrivningen i den ursprungliga databastabellen endast i det avseende att packade (typade) fält får en annan datalängd efter konvertering till text. Metadata och dokumentation Dokumentationen bör följaktligen innehålla både fullständig postbeskrivning för alla posttyper i det ursprungliga dataregistret och en fullständig transaktionsbeskrivning för avställda poster (datarader i en arkivfil). Tabell- och kolumnöversikt med förklaring i klartext för varje kolumn (datafält) bör skapas för alla tabeller som ingår i arkivurvalet (förståelsedokumentation). Förklaringar bör ges för alla beräknade fält, koder och förkortningar. Om koder finns lagrade i det avställda systemet såsom separata tabeller eller värdelistor bör dessa obligatoriskt ingå i arkivurvalet för avställd registerdata (exempelvis i ett ekonomisystem: kontoplan med kontonummer och kontonamn eller motpartskoder med motpartsnamn, vidare på samma sätt ansvarskoder, leverantörs- och kundlistor med nummer /kontonummer och namn med värden specifika för angivet räkenskapsår). Fullständig relationsbeskrivning (relationer / länkar mellan tabeller) skall finnas i dokumentationen. Detaljnivån skall vara tillräcklig för att man skall kunna återskapa bindningar mellan tabeller lagrade i arkivfiler när de läses in i arkiv-/forskardatabas. Kommentarer I ett hierarkiskt dataregister, vanligt i äldre system, är poster länkade med pekare i en parentchildpost struktur och användning av ovan beskrivna modell för avställning innebär vissa svårigheter. Ett enkelt exempel för detta är ett diariesystem av följande typ: Parent (postlayout): ärendeID, fält2, fält3……..fält-n child1 (postlayout): händelse(datum),fält2,fält3….fält-n child2 (postlayout): händelse(datum),fält2,fält3….fält-n child3 (postlayout): händelse(datum),fält2,fält3….fält-n …. …. child-n (postlayout):händelse(datum),fält2,fält3….fält-n I en relationsdatabas skulle det innebära att det finns två tabeller med en explicit en till många relation och att ärendeID identifierar unikt en ärendepost, samtidigt som ärendeID används i den andra tabellen för att binda samman alla händelser som hör till ett visst ärende. 36 I en hierarkisk struktur däremot uttrycker sig relationen en till många implicit via pekarlänkning och utan dessa pekare blir datamängden osammanhängande. Visserligen kan hela registret lagras i en enda textfil där registerstrukturen bibehålls och för varje ärendepost som lagras sekventiellt i arkivfilen medföljer tillhörande händelseposter men för att läsa in en sådan arkivfil i en forskardatabas krävs det ett nytt program som vänder på det som avställningsprogrammet har gjort. När man nu inte längre har pekarlänkar till hjälp måste man på ett annat sätt identifiera datarader i arkivfilen (dvs. om en viss datarad är av ärende eller händelse typ). Problemet kan till exempel lösas genom att avställningsprogrammet lagrar växelvis poster i två textfiler (en för ärende och en för händelse) och för varje enligt postbeskrivning skapad datarad i ärende-filen skapas det ett antal rader i händelse-filen som får i transaktionsbeskrivningen ett extra fält för ärendeID (kan vara sista fält i transaktionsposten) där huvudpostens ärendeID upprepas. Detta innebär ingen ändring av arkivdata utan att man inför en viss redundans (dataupprepning) för att bevara hierarkiska datastrukturer utanför deras ursprungligt system. Följaktligen kommer respektive arkivfil innehålla: Fil1.txt: (rad1): ärendeID, fält2, fält3……..fält-n (rad2): ärendeID, fält2, fält3……..fält-n .. (rad-n): ärendeID, fält2, fält3……..fält-n Fil2.txt: (rad1):händelse(datum),fält2,fält3….fält-n, ärendeID (rad2):händelse(datum),fält2,fält3….fält-n, ärendeID .. (rad-n):händelse(datum),fält2,fält3….fält-n ärendeID Jerzy Misiewicz E-post [email protected] 37 38 Bilaga 1: Arkivfilformat för elektroniska dokument Med elektroniska dokument avses här dokument och dokumentbilagor som har skapats elektroniskt, både textdokument och dokument med grafiskt innehåll, inskannade dokument (dokumentbilder), digitala bilder, både stillbilder och rörliga bilder, och digitala bilder med strukturerad metadata Leverantörsberoende format: • PDF (Portable Document Format), huvudsakligen för dokumentutbyte (med möjlighet för vidare redigering) och inte arkivering, leverantörsberoende (Adobe Corp.) För att bevara ett specifikt typsnitt måste typsnittet följa själva arkivfilen antingen inbäddad i pdf-dokumentet eller som separat arkivfil (pdf-filen innehåller då endast hänvisning till respektive typsnitt, såsom html), plattformoberoende. • PostScript, huvudsakligen ett format för utskrift av dokument, trycksaker, leverantörsberoende (Adobe och diverse leverantörer av dataskrivare: Apple Laser Writer, Linotronics), samma begränsningar som PDF, plattformoberoende. • RTF (Rich Text Format) för program- och versionsoberoende dokumentutbyte (Microsoft) Leverantörsoberoende: format (ISO) • Latin 1 (ISO/IEC 8859-1:1998) , 8-bitars grafiska teckenkoder, avser endast dokumentets text (konverterade dokument och bilagor), typsnitt, grafisk stil och layout, överstrykningar, understrykningar m.m. bortses ifrån, arkivstandard för långtidsbevarande. (I teckenområdet 1- 127 fullständigt kompatibel med ASCII, 7 bitars (ISO 646 : 1991) • SGML (ISO 8879:1986) , metaspråk för strukturerade dokument, kan användas med väl definierade ”preprocessade” (förbehandlade) dokument, kräver DTD (Dokument Typ Definition), använder ”taggade” märkord, beskriver endast dokumentets logisk struktur, bortser från grafisk layout (utseende). Saknar utbredd implementering. Substandarden XML tillåter dessutom beskrivning av dokumentet utseende i en separat specifikation (style sheet, XLS) på liknande sätt som HTML. SGML och XML möjliggör unifierad och strukturerad indexering av mängder av dokument av samma typ för sökning. Exempel på detta är Dublin Core (Termkatalog och metadataschema) för vetenskapliga publikationer. • SQL, Structured Query Language, (ISO/IEC 9075:2003), för selektion (och uttag via ODBC) av normaliserat registerdata i en relationsdatabas där antigen ett helt register eller enstaka poster utgör elektroniska dokument, alternativt ett informationsurval genomfört med hjälp av SQL., (OBS: för integration av XML med SQL: del 14 av SQL standarden, ISO/IEC 9075-14:2003 (SQL/XML) • ODA (ISO 8613:1994): Open Document Architecture (tidigare ISO 8613:1989 Office Document Architecture) behandlar både dokumentets struktur och grafisk layout (utseende) och är egentligen det enda icke proprietära formatet för fullständigt dokumentutbyte mellan olika IT-system. (ISO 8613-7) – delen av ODA är en profil för grafiskt innehåll i dokumentet som baserar på TIFF-CCITT group 4 (för rastrerad grafik) eller CGM (se bildformat nedan) Saknar utbredd implementering. • DICOM (DICOM 3.0), för elektronisk bild med strukturerad textinformation de facto standard inom medicinsk informatik (radiologisk undersökning), dokumentets informationsstruktur är uppdelad i väl definierade numeriska grupper DICOM är än så länge en icke ISO-standard. 39 Dokumentbildformat • TIFF (Tag Image File Format), ISO 12639 : 1998, ISO 12639 : 2004, för långtidslagring (offline) av fotografiska bilder och dokument i gråskala och färg (kontinuerlig färgtonskala) [1 bits (bitonal=tvåfärgs) rasterformat finns under TIFF som grupp 4 tillval för komprimering av svart-vita bilder] • TIFF group 41, CCITT group 4 rasterformat ITU (tidigare CCITT) Recommendation T.6, för arkivlagring av stora volymer av standard A4-dokument (1 bits, bitonal, huvudsakligen sv.-vit rastergrafik, är inkluderad i TIFF-specifikationen (se ovan) Ursprungligt: Huffmans kodning (1952), använd som algoritm för kodning av handskrift och maskinskrift i telefax (ITU = International Telecommunications Union, CCITT =Comite Consultatif International de Telegraphique et Telephonique ) • JBIG (Joint Bi-Level Experts Group), (ISO/IEC 11544, CCITT Recommendation T.82), en mer avancerad standard för 1 bits (bitonal) tvåfärgs grafik som kan även användas med dokument i gråskala samt flerfärgsdokument (jfr med JPEG) genom uppdelning i flera en bits plan • JPEG /JFIF (Joint Phototgraphic Experts Group), (ISO 10918-1, 2, 3) för lagring online av fotografiska bilder (flerbits, flerfärgs representation) [JFIF = JPEG File Interchange Format] • JPEG 2000 (ISO/IEC WD15444-6: 2001) för blandade kompositbilder med både skannat och syntetiskt innehåll, för multipla bilder och bildserier (inkluderar både CCITT group 4 och JBIG som referensprofil för bitonal representation /rasterformat), (bl.a. används som standard för komprimering av bilddata med kontinuerlig tonskala i DICOM-dokument) • CGM (Computer Graphics Metafile), (ISO 8632 : 1999), för dokument med grafiskt innehåll (geometric graphics) och text (samma problem som med PDF när det gäller bevarande av typsnitt) 1 bör ej förväxlas med TIFF-F eller TIFF Class F proprietärt format (används inom faxindustri, för fascimile group 3 kodning i faxtelekommunikationen, stöds i både TIFF 5.0 och 6.0 spec. från Adobe / Microsoft) Standardisering: referenser ISO standard för SQL (selektivt urval, datatyper m.m) : ISO/IEC 9075-1..14 (Part 1 – 14) : 2003 Information technology -- Database languages – SQL Part 2: Foundation (SQL/Foundation), ISO/IEC 9075 – 2: 2003 ISO standard för metadata : ISO/IEC 11179 [delar 1 – 6] ISO/IEC 11179-2: 2000 Part 2: Specification and standardization of data elements Classification for data elements ISO standard för arkivfilformat : SS-ISO 646 : 1991 Datarepresentation - Internationell 7-bits teckenkod för datautbyte SS-ISO/IEC 8859-1:2004 8-bits kodade grafiska teckenmängder - Del 1: Latinska alfabetet nr 1 (ISO/IEC 8859-1:1998, IDT) 40 ISO 8879:1986 Information processing -- Text and office systems -- Standard Generalized Markup Language (SGML) ISO 12639:2004 Graphic technology -- Prepress digital data exchange -- Tag image file format for image technology (TIFF/IT) ISO/IEC 8632-1 Information technology -- Computer graphics -- Metafile for the storage and transfer of picture description information [CGM format] ISO standard för ej förstörande komprimering av arkivbilder: ITU-T Recommendation T.6 :1993 Fascimile coding schemes and coding control functions for group 4 facsimile apparatus [CCITT group 4, se ISO 12639:2004 för TIFF ovan] ISO/IEC 8613-7-Amd 1 Information technology -- Open Document Architecture (ODA) and Interchange Format: Raster graphics content architectures [CCITT group 4] SS-ISO 10918-1 Bildrepresentation - Digital komprimering och kodning av stillbilder kontinuerlig tonskala - Krav och riktlinjer [JPEG standard] ISO/IEC 15444 Information technology -- JPEG 2000 image coding system -- Part 1, 2, 3…12 SS-ISO 15444-3 Information technology -- JPEG 2000 image coding system -- Part 3: Motion JPEG 2000 [för bilddokument med rörlig bild] [arkivreferens, bildkomprimering]: http://www.nationalarchives.gov.uk/preservation/advice/pdf/image_compression.rtf. Digital Preservation Department of The National Archives, UK Digital Preservation Guidance Note: 5, Image Compression DICOM 3.0, de facto standard (ej ISO) för bildobjekt med metadata inom radiologi: NEMA PS 3.1:2003 Digital imaging and communications in medicine (DICOM) IEC/TR3 61852 (1998) Medical electrical equipment - Digital imaging and communications in medicine (DICOM) - Radiotherapy objects ** IEC/TR3 62266 (2002) Medical electrical equipment - Guidelines for implementation of DICOM in radiotherapy *** [Formatet används med JPEG 2000 i LTA-system för långtidsarkivering, se SS-ISO 15444 ovan] NEMA = National Electrical Manufacturers Association (USA) IEC = International Electrotechnical Commission (Schweiz) ** tillägg till Del 3, 4 och 6 av DICOM *** bl. a. Implementeringens överenskommelse med DICOM standarden (DICOM conformance) 41 42 Bilaga 2: Rekommendation för arkiv-CDR Göteborg, 2005-05-12 Rekommendationer för arkiv-CDR: (Regionarkivet Göteborg) - 3 ex. per arkiv-CD (2 olika CD-R fabrikat), original ex: CDR-74 Kodak Gold Ultima (Info Guard), eller likvärdig kopior: TDK, Maxell, Fujii eller annat, CDR-74) (aktuellt tillverkas CD-R motsvarande ovan i CDR-80 format, ftalocyanin som bas, guldskivor, tex. MAM-E Gold Ultra, MAM-E Studio) - 2 ggr (2 X) CD- brännarhastighet max. för arkivfiler - ISO-9660 Level 1 filnamn endast A...Z, 0..9 och understrykning är tillåtna i filnamn som får högst vara 8 tecken för filnamn+ 3 för filändelse (.txt) - en stängd brännarsession (session closed) och hela CD-skivan stängd för vidare skrivning (ej CD-ROM XA, multisession), alltså ISO9660 CD-ROM format - det inbrända volymnamnet skall bestå av datum för bränning och nr (det är standard i cd-brännarprogram) - metadata i form av tabellöversikt skall ligga i en textfil på Cd-n (behövs ej om data ligger i en enda arkivfil) - metadata i form av postbeskrivning skall ligga i en textfil på Cd-n enligt nedan: [tabellnamn], [fältnr], fältnamn, datatyp, längd (byte), (+ förklaring i klartext), tex: Tabelnamn Fältnnr Fältnamn Typ Längd Beskrivning PERSON 1 2 3 4 pnr enamn fnamn ålder CHAR CHAR CHAR INTEGER 10 60 50 2 Personnr Efternamn Förnamn Ålder osv. detta kallas för kolumnöversikt - metadata för maskininläsning (transaktionsbeskrivning) skall ligga i en textfil på Cd-n enligt exempel nedan: fältnamn personnr enamn fnamn ålder osv. position 1 12 72 122 längd (bredd) 11 60 50 3 justering v v v h Dokumentbilder skall lagras på CD-R i CCITT grupp 4, Tiff grupp 4 format 43 Databärare för långtidsbevarande Optiska skivor Bilaga 1 till RA-FS 1994:7 ändrad senast genom RA-FS 1997:7 CD-skivor av typerna CD-ROM eller CD-R (SS-ISO 10149) Det är viktigt att vara medveten om skillnaden mellan CD-ROM och CD-R. CD-ROM framställs med master och i en viss upplaga. Det blir väldigt dyrt vid framställning av enstaka exemplar. CD-R skrivs däremot en och en. Normalt är det CD-R som är aktuellt för framställning av arkivexemplar. Vad gäller standarder kan noteras att det under dataorganisation förekommer två stycken. CD-ROM- / CD-R- skivorna rymmer normalt 650 MB. För närvarande accepterar Riksarkivet inte den nya skrivtekniken i fysiskt CD-format, DVD (digital video disc) Ur SP RAPPORT 1999:26 (Statens Provnings och Forskningsinstitut, Kemi och Materialteknik): Industristandarder för fysiskt format: (de färgade böckerna) Yellow Book fysiskt format för data-CD //master baserade CD-skivor Orange Book fysiskt format för CD-Recordable (CD-R) ............................................................................................................................................. // OBS: Orange Book behandlar enbart skivorna, inte inspelnings- eller läsutrustning Internationella standarder för logiskt format: ISO 9660 för CD-ROM, logiskt format // (bla filnamn får inte vara längre än 8 tecken + 3 för filtypbeteckning och innehålla bara tecken {A..Z, 0..9, _}) ISO 13490 för CD-R (mer flexibel än ISO 9660, tillåter bl. a långa filnamn) // OBS: så kallade Joliet filnamn (128 tecken) används av praktiska skäl för bl.a. arkivering av bilder vid Regionarkivet Göteborg på ISO 9660 formaterade arkiv-CD skivor med innehållsförteckning (namn på alla filer som arkiverades på CD) lagrad i en indexfil i textformat. Färgämne: (CD-R) // den egentliga informationsbäraren Ftalocyanin, ”guldskivor” tex. Kodak Gold Infoguard (aktuellt MAM-E Studio) // längst beständighet i tester för åldrande Cyanin, ”gröna skivor” tex. TDK-74 // mycket bra läsbarhet och kompatibilitet med cd-läsare av olika märke, kortare beständighet Strategi för långtidsbevarande: periodvis omlagring och migration // kopiering till ny media av samma sort / konvertering till annan optisk media // OBS: Magnetband är fortfarande lagringsmedium i många sammanhang, men av olika tekniska skäl anses vara olämpliga som media för långtidsbevarande. (Bl. a. Finns det ingen ISO standard för dataorganisation på band likvärdig ISO 9660 för CD-R. En plattformoberoende standard för lagring på band, indexering och labelmärkning, SIDF - System Independent Data Format ISO/IEC 14863 (ECMA-208) har inte slagit igenom och stöds endast av vissa backup program leverantörer t.ex Novell (SBackup). Andra stora leverantörer av bandlagringssytem (tex. Legato stödjer endast läsning av SIDF format) I övrigt är arkivlagring på band UNIX plattformberoende och använder Posix de facto industristandard med TAR-format (Tape Archive) och IBM labelmärkning. 44 Dataorganisation och namnutrymme i ADB arkivet Regionarkivet, 2004-06-11 1. Hierarkisk och flat dataorganisation Definition: (ur Riksarkivets leveransbok kapitel 4.7: Dataorganisation Med dataorganisation avses här standarder för hur filerna är organiserade på databärare för ADB. För band levererade till Riksarkivet i TAR-format gäller följande: Vid leverans gäller att endast flata biblioteksstrukturer får användas. Kommentar: problemet med hierarkiska biblioteksstrukturer är bland annat att förutom att man behöver veta vad en datafil heter måste man också ta reda på vad den finns lagrad enligt de regler som gäller för den hierarkin som man har använt sig av. I en hierarkisk struktur kan en arkivfil heta samma sak och innehålla olika dokument. I en flat biblioteksstruktur måste alla filnamn för dokument som lagras / arkiveras vara unika, m.a.o. alla arkivfiler är unikt identifierbara helt oberoende av systemskiktet. (Dvs. endast regler för namngivning, t.ex. filnamnlängd måste beaktas) 2. Konsekvenser vid datamigrering , mediagenerationsskifte: Vid övergång till en ny slags media för digitalt bevarande kan flata biblioteksstrukturer med unika arkivfiler överföras direkt utan hänsyn till filsystemhierarkin specifik för given mediastandard. (Flat överföring, direkt arkivfilkopiering mellan media av olika slag inklusive ev. indexfiler) [överföring i exempel nedan görs helt automatiskt] Exempel: lagring av en serie J0000000 – J00025000 av patientjournaler, 25 000 journaler media av typ CD-R: à media av ny typ ”XD-R”: index: D26_CD1.txt arkivfil1: J0000001.txt arkivfil2: J0000002.tx --------------arkivfilN:J0012500.txt index: D26_CD1.txt index: D26_CD2.txt arkivfil1: J000001.txt arkivfil2: J000002.txt arkivfil1: J000003.txt --------------arkivfilN: J025000.txt index: D26_CD2.txt arkivfil1: J0012501.txt arkivfil2: J000004.txt --------------arkivfilN:J025000.txt 3. I online-arkiv skikt kan en systemberoende hierarki tillämpas med fördel (av bland annat prestanda skäll) Observera dock att dessa hierarkier skiljs mellan olika datasystem (tex. mellan UNIX och Windows NT, eller OS/2) För att kunna återställa katalogisering av arkivfiler / ursprunglig uppdelning med filvägar kan man spara dessa i en indexfil (biblioteksfil) som skapas endast för första generation av media och bevaras genom alla generationsskiften. 45 4. Kravspecifikation och namnutrymme i ett ADB-arkiv Enligt kravspecifikationen för arkivdatafiler skall arkivfiler döpas efter regler för dataorganisation för specifik arkivmedia, tex. för CD-R skivor ISO 9600 respektive ISO 10 149. På en arkiv-CD som följer dessa regler kan filnamn vara högst åtta tecken långa (8 tecken för filnamn punkt som avskiljare och 3 tecken för filändelse t.ex.: J0012500.txt. (ISO 9600 level 1 regler för filnamn) När arkiverade datamängder består av stora mängder av enstaka arkivfiler som måste skiljas åt och identifieras lätt i ADB-arkivet måste regler för hantering av namnutrymme införas och beaktas för att klara av, i första hand, att märka stora serier av arkivhandlingar inom en arkivbildare och i sådana avställningar där handlingar av samma slag från olika arkivbildare skall arkiveras i ett enda stort projekt. I sådana fall kan ett namnindex upprättas där serier av arkivfiler registreras och nya serier kan lätt skapas som följer regler för hantering av namnutrymme. (se nedan exempel på implementering av en sådan namnindex). I en ännu mer produktiv miljö skulle man kunna koppla in tidsdimension i namngivningsregler enligt ISO level 1, och upprätta en särskild kronologisk ordning i det digitala arkivet där regelbundna leveranser från en och samma arkivbildare läggs i en enda stor serie av unika arkivfiler med kronologisk utveckling, t. ex: serie R0000101.004 – R9999901.004. av bilder, 100 000 bilder vecka 1, 2004 ………………………………………………………………………………… ……………………………………………………………………………… serie R0000152.004 – R9999952.004. av bilder, 100 000 bilder vecka 52, 2004 totalt för år 2004: 5.2 miljoner arkivfiler, enligt följande serieformel: R0000152.004 = R00001 + 52 + . veckonr (2 tecken) serienr (6 tecken) + 0 + 04 årtal (2 tecken) sekelsiffra (1 tecken) Att göra i ordning handlingar i det digitala arkivet innebär sammanfattningsvis att regler för dataorganisation och namngivning inom respektive ISO-standard för databärare (arkivmedia) och rekommendationer om flat filbiblioteksstruktur och flat dataformat i Riksarkivets leveransbok beaktas och följs upp i den praktiska hanteringen av ADB-arkivet och att även ovan beskrivna problem med hantering av namnutrymme uppmärksammas när rutiner kring långtidsbevarande av digitala arkivalier läggs upp. 46 2003-04-07 Avställning av data ur Profdocsystemet, principer Det är nödvändigt att, bl. a. av prestandaskäl, kunna avställa data ur Profdocs patientjournalsystem samt långsiktigt bevara denna data. Med avställning avses att all data som bildar ett visst intervall patientjournaler, exporteras ur det aktiva systemet. Det kan röra sig om journaler för patienter som avlidit eller som flyttat från orten. Det kan också röra sig om journaler för patienter som inte varit aktuella på senare år. Avställning innebär således att datamängderna bevaras men utanför det ursprungliga systemet. För att långsiktigt kunna bevara datorjournaler måste man bevara själva datat i maskinläsbar form. Det handlar inte om att ha ett parallellt Profdocsystem, t ex en ”lightversion” med inaktuella journaler. Den ständigt pågående programutvecklingen (och teknikutvecklingen) innebär att nya releaser av Profdoc utvecklas och implementeras hos användarna. Vid installation av en ny release konverteras befintlig data till den nya versionen. Avställd data däremot skall inte konverteras utan får kvarbli i det format som valdes vid avställningen. Härigenom uppkommer en nackdel, nämligen den att en avställd patientjournal i princip aldrig kan återinläsas. Detta är emellertid något man måste acceptera. Av praktiska- och kostnadsskäl skall man inte sträva efter ett avställningssystem med inbyggd versionshantering. Man bör i stället anlägga ett pappersperspektiv, d.v.s. jämföra med hur traditionell arkivering av pappersjournaler går till. En arkiverad pappersjournal ser ut exakt så som den gjorde då den överfördes till långtidsarkivering. Den speglar sin tid och kan förefalla ålderdomlig för den nutida läsaren. Icke desto mindre innehåller den arkiverade pappersjournalen just den information som var aktuell då journalen fördes. Långtidsbevarande av data För att långsiktigt kunna bevara patientjournaldata och datastrukturen samt bibehålla möjligheten att i framtiden göra avancerade sökningar och sammanställningar, måste avställd data bevaras i form av ASCII-filer tillsammans med en kolumnöversikt i klartext för varje tabell som ställs av. Man behöver inte behöver ställa av samtliga tabeller. Endast tabeller med medicinskt relevant information måste avställas. Observera att man måste fatta ett gallringsbeslut för de tabeller som inte ställs av. Enklast sker avställningen genom att man läser över datat till Microsoft Access och därefter skapar en exportspecifikation (denna sparas som transaktionsbeskrivning). Från Access ställs datat av i form av flata textfiler (ISO 8859-1). 47 Funktion för snabb åtkomst av avställda Profdocjournaler Leverantören måste utveckla ett tilläggsprogram som skriver ut samtliga journaler till fil (eller samtliga journaler i valt intervall). Härmed avses en generisk utskriftsfunktion, ej en printerfil utan en funktion som skriver ut till en skrivare, vilken som helst. Man kan sammanfatta med att det behövs ett makro som hämtar journal för journal och skriver ut dessa (till fil). Tilläggsprogrammet skall vara så utformat att man kan ange olika tidsintervall för utskrift (till fil) av samtliga journaler inom intervallet. Ovan beskrivna funktionalitet innebär att journaler avställs i olika tidsintervall. På längre sikt betyder det att man får ett antal intervall med avställda journaler. Därför måste man bygga ett index över samtliga avställda skikt. Härmed avses ett enkelt söksystem som ställer SQL-frågor till de avställda journalintervallen för att man skall kunna hitta en journal, oavsett i vilket intervall den finns. Motivering Data måste, som ovan nämnts, avställas på tabellnivå och bevaras som maskinläsbara ASCII-filer. Man får dock inte bortse från svårigheten att, med utgångspunkt från datat i tabellerna, åstadkomma en arkivdatabas enligt etablerad kravspecifikation för arkivdatabaser (jfr Regionarkivets kravspecifikation). För att säkerställa snabb och säker tillgång till avställda patientjournaler samt möjliggöra strukturerad sökbarhet måste därför avställningen ske enligt de två principer som beskrivits ovan, nämligen dels i strukturerad form, där varje tabell överförs till en ASCII-fil, dels såsom färdiga dokument, journaler i sin helhet utskrivna till fil. Bo Thalén och Jerzy Misiewicz 48 Avställning av räkenskaper AVSTÄLLNING AV RÄKENSKAPER TILL ARKIVDATABAS PER FÖRVALTNING OCH RÄKENSKAPSÅR Avställningsrutiner steg för steg 1. DATA TAS UT FRÅN RESPEKTIVE FÖRVALTNINGENS DATABAS FÖR VARJE FUNKTION I REDOVISNINGSSYSTEMET VIA RAPPORT / FRÅGA OMFATTANDE ALL BOKFÖRINGSMÄSSIGT RELEVANT DATA FÖR AVSTÄLLT RÄKENSKAPSÅR: (DATA TAS UT TILL ASCII FILER): – transaktioner i grundboken (hela kodsträngen) – huvudboken (företagskod, kontonummer, konto i klartext, IB, kontosaldon, UB, bokf.år) – kundreskontra (journaluppgifter) – leverantörsreskontra (journaluppgifter) – kontoplan aktuell för avställningsåret (kontokod, konto i klartext, bokf. År) – obligatoriska koddelar: ansvar, motpart, huvudansvar (ev. egna koder såsom projekt, aktivitet m.m.) var för sig i separat ascii-fil (kod, klartext) – förvaltningslista aktuell för avställningsåret (förvaltningskod, namn i klartext) 2. ASCII-FILER AVPASSAS FÖR LÅNGTIDSBEVARANDE: – datastruktur i arkivfiler eventuellt vidareanpassas (en posttyp per fil, fast post bredd, fast fältlängd osv. därvid en arkivpostbeskrivning och kolumnöversikt upprättas för varje arkivfil och sparas i separat fil som metadata) – teckenrepresentation i varje arkivfil anpassas till ISO-8859-1 format (obs: vid konvertering måste eventuella styrkoder, ascii-koder 0h – 19h.flitreras bort med undantag för tecken för vagnretur (0Ch) och radframmatning (0Ah) 3. DATA FRÅN ARKIVFILER ÅTERINLÄSES IN I EN ARKIVDATABAS STRUKTURERAD ENLIGT TRANSAKTIONSBESKRIVNING FÖR ARKIVFILER (ARKIVPOSTBESKRIVNING): – dataintegritet i arkivfiler kontrolleras vid inläsning till arkivtabeller via en relationsstruktur som bevarar sammanhang mellan kontoplan, koddelar och grundbokföringens transaktioner, likaså identifiering av en leverantör eller kund i kund- och leverantörsreskontra), antalet poster i importtabeller stäms av mot antalet datarader i respektive arkivfil) – arkivdatabasen skrivskyddas efter avslutad dataimport 4. CDR-SKIVOR BRÄNNS MED ARKIVFILER PER FÖRVALTNING OCH ÅR: – arkiv-cd bränns i tre exemplar (ett original och två kopior) på cd-r media godkänd för långtidsbevarande (ftalocyanin- guldskivor tex.Mitsui Gold, MAM-e studio) med datum för framställning inbränt i cdr-media. – avställning av räkenskaper dokumenteras (rapport över avställning (kvalitetssäkring, dataautenticitetssäkring m.m.) – arkiv-cd och dokumentation över avställning överlämnas till arkivet för långtidsbevarande 49 Kontroll av dataintegritet vid avställning av räkenskaper 50 Bilder: Bild 1: ADB-upptagning och ADB-system, dokument- och process schema 51 Bild 2: Datamängder och arkivvolymer vid avställning 52 Bild 3: Baskategorier av ADB-upptagning och arkivfiler vid avställning 53 Bild 4: Systemkategorier och dokumenttyper vid avställning 54 Bild 5: ORM Model för ett ADB-arkiv 55 Bild 6: Långtidslagring av ADB-upptagningar, Orsak och Verkan Diagram 56 Bild 7: Regionarkivets ADB-Arkiv 57 Bild 8: Regionarkivets arkivserver för räkenskaper 58 Bild 9: Uppbyggnad av långtidslagring, lägesbeskrivning, skiss 59 Bild 10 Schema för arkivdokumenthantering i ADB-Arkivet 60 Bild 11 Handling- och dokumentstruktur vid bevarande i ADB-arkivet 61