Klinisk Biokemi i Norden Nr 2, vol. 25, 2013 - page 32

32 | 
Klinisk Biokemi i Norden · 2 2013
datorn tilldelar programmen, och kanske öka tilldelat
minne som just detta program kan använda. Den pro-
gramvara som används är också ofta utvecklad långt före
hårdvaran (processorn och minnet) och kan innehålla
stora mängder gammal programkod som inte är anpas-
sad till dagens möjligheter. En ytterligare begränsning
är att data ofta måste transporteras mellan olika enheter
på datorer eller nätverk. En dator skall först hitta data,
packa data för sändning, data skall så genom kabel till
mottagardatorn som packar upp dem. Här kan man
tjäna tid. När jag använder tyngre beräkningsprogram
på jobbet lagrar jag beräkningar på lokal hårddisk (C:/)
i stället för på server, och när jag hämtar patientdata så
ger jag databasen instruktioner om att sända resultaten
tusen och tusen i stället för ett och ett. Ett gott råd är
också att beräkna t.ex. medelvärdet och standardav-
vikelsen direkt i databasen och så skicka dessa värden,
i stället för att sända fjortontusen patientresultat ut ur
databasen och sedan beräkna medelvärdet och stan-
dardavvikelsen.
När detta skrivs är den gamla magnetiska hårddisken
med skiva under attack från halvledardisken (”solid state
drive” eller ”SSD”) som datamaskinens permanenta
minne. Halvledardisken slår denmagnetiska hårddisken
i hastighet, speciellt när datamaskinen skall starta och
den magnetiska skivan skall snurras i gång. Halvledar-
disken tar också mindre plats, drar mindre ström och
klarar fysiska påfrestningar som temperaturvariationer
och magnetfält bättre. Halvledardiskar dominerar där-
för bland surfplattor och bärbara maskiner. Nackdelarna
är att halvledardisken är betydligt dyrare, och har en
tendens att bli långsammare över tid, och till sist så
kraschar halvledardiskar fortfarande lite för ofta.
Allmänna råd, sådana du kanske har hört förut
Man kan åstadkomma mycket genom enkla och van-
liga åtgärder. Först, städa i databasen. Se till att samma
data inte lagras på två ställen samtidigt. Detta kan
låta gnälligt, men många databaser har en kolumn för
fullständigt personnummer, en kolumn för de första
sex siffrorna i personnumret, en kolumn för dag, en
för månad och en för dag när pasienten är född. I en
kolumn lagrar man labnummer med 8 siffror, i en annan
kolumn samma labnummer med 10 siffror, osv. Orsaken
till att det blir så i ett laboratoriedatasystem är enkel,
systemet befinner sig mellan analysinstrumenten och
sjukhusets journalsystem, och laboratoriedatasystemets
roll är ofta att tolka och översätta. Några analysinstru-
ment vill ha sina ”order” med 8 siffror, andra med 10
siffror. Nästa råd är att tänka genom vad man använder
databasen till. En databas är en samling tabeller, och det
är förnuftigt att de organiseras efter hur man använder
dem. Om det är så att vi alltid söker patientresultat
genom att slå in patientens personnummer och aldrig
intresserar oss för resultat som är äldre än ett år, ja då
kan vi dela in data efter ålder i en ”aktuell” tabell och
en ”historisk” tabell. Eftersom vi söker på personnum-
mer kan vi sedan sortera tabellen efter personnummer.
För att ytterligare snabba på sökresultatet kan vi lägga
på ett index. Ett norskt personnummer innehåller elva
siffror, och om vi söker på personnummer så måste vi
gå igenom alla personnummer i tabellen och jämföra
dessa elva siffror med de elva siffror vi har skrivit in i
laboratoriedatasystemets sökruta. Ett enkelt index är
att vi lägger till en kolumn som består av första siffran
i personnumret. När vi nu söker efter personnumret
kan vi börja med att jämföra första siffran i vårt sökfält
mot vårt index. Vi går så bara vidare och jämför alla
elva siffrorna för de personer där första siffran stämmer.
Index kan alltså få en bestämd sökning att gå fortare,
men tyvärr sker ju detta på bekostning av att alla andra
sökningar går bittelite långsammare, och att databasen
kräver mer underhåll.
Kompression
Rent teoretiskt kanman säga att mer information kräver
mer lagringsplats. Vi har en tendens till att lagra data
på mer utrymme än vi behöver. Om vi vid det enorma
laboratoriet mäter hemoglobin på 3000 patienter under
en dag, kanske vi finner en högsta koncentration på 186
g/L och en lägsta koncentration på 58 g/L. Vi mäter i
hela gram per liter och vi har således ca. 130 nivåer, och
med andra ord förekommer varje nivå i genomsnitt hos
ca 25 patienter. Våra databaser innehåller alltså en stor
mängd repetitioner, det engelska begreppet för sådana
data är ”sparse”. Om vi önskar att beräkna medelvärdet
och standardavvikelsen för vår hemoglobinanalys från
1 mars till 30 juni, så har vi två möjligheter, vi kan gå
genom alla resultat (ca 360000) och beräkna genom-
snittet och standardavvikelsen. En annan möjlighet är
att vi för varje dag lagrar dag, nivå och antal patienter
som har denna nivån. Vi har max 130 nivåer per dag,
så vi behöver då bara gå igenom ca 15000 resultat för
våra beräkningar. Att lagra nivå/koncentration och
antal är det samma som man behöver när man skall
rita ett histogram, och denna variant kallas därför för
histogramrepresentation av data.
1...,22,23,24,25,26,27,28,29,30,31 33,34,35,36,37,38,39,40,41,42,...52
Powered by FlippingBook