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