07.12.2012 Views

Flensburg P: Personlig databehandling - Per Flensburgs hemsida

Flensburg P: Personlig databehandling - Per Flensburgs hemsida

Flensburg P: Personlig databehandling - Per Flensburgs hemsida

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>Per</strong> <strong>Flensburg</strong>: <strong><strong>Per</strong>sonlig</strong> <strong>databehandling</strong><br />

• Kontoplan (Kontoklass, kontoklassbenämning, datum, belopp)<br />

• Kontoklass (Kontonummer, kontobenämning, datum, belopp)<br />

• Kontotranskation (Transaktionstyp, försystem, datum, belopp)<br />

• Transaktionstyp (Transaktionsnr, försystem, datum, belopp)<br />

Detta ser ut att fungera fint, åtminstone på pappret. Men vad som inte representeras i<br />

denna modell är olika summeringar som äger rum mellan nivåerna. "Belopp" har olika<br />

innebörder i alla fyra tabellerna ty de är summeringar på olika nivåer av enskilda<br />

transaktioner. Inte heller representeras reglerna för konteringar och förflyttning<br />

mellan olika konton. Det finns stora skillnader mellan olika konton. Det finns även<br />

skillnader i organisationen av kontona. I kontoklass 7 t ex finns det vissa gruppkonton,<br />

som ligger på en nivå mellan kontoklass och enskilt konto. Förflyttningsreglerna<br />

och de olika summeringarna kan inte, åtminstone inte på ett enkelt sätt representeras<br />

i en relationsdatabas. Detta sätt att göra kravspecifikation kan kallas det dataorienterade<br />

sättet.<br />

Det verksamhetsorienterade sättet och det dataorienterade sättet kan i viss mån sägas<br />

komplettera varandra. Det verksamhetsorienterade koncentrerar sig på vad som<br />

görs med informationen, medan det dataorienterade koncentrerar sig på vilken information<br />

som behövs. Det verksamhetsorienterade sättet är användarnas sätt, medan<br />

det dataorienterade är dataexpertens. Enbart kunskapen om de olika sättens<br />

kravspecifikation är bra, men det behövs någon metod för att kunna övergå från den<br />

ena till den andra. En tänkbar sådan har jag skissat på i ett tidigare forskningsprojekt<br />

(<strong>Flensburg</strong> 1981c), men denna gick inte att använda i föreliggande fall. Orsaken var<br />

att problemet bestod i att ta fram information, som inte fanns. Vilken var alldeles<br />

unikt för varje gång problemet uppkom och därför kunde man inte heller säga vad<br />

som ska göras annat än i mycket allmänna termer. Att närmare klargöra förhållandena<br />

mellan dessa olika sätt att specificera sina krav är en viktig uppgift för fortsatt<br />

forskning.<br />

Den tredje innebörden av kravspecifikation, maskinbehovet, talade vi ganska mycket<br />

om, men ingen kallade det för kravspecifikation. Från början trodde jag nog att val av<br />

dator och av redskap skulle visa sig viktigare än det verkar bli. Det är faktiskt ett väldigt<br />

stort språng man tar, från satsvis arbetande system med separata filer till applikationsgenerator<br />

med databas.<br />

Martin (1982) talar om fyra olika typer av "data environments":<br />

• Files som innebär enskilda, flata filer för varje tillämpning. Ingen databashanterare.<br />

• Application data bases som innebär att man har separata databassystem för<br />

varje tillämpning.<br />

• Subject data bases som innebär att man har databaser oberoende av tillämpning<br />

och avsedda för tunga, satsvisa bearbetningar.<br />

• Information systems som är databaser organiserade för snabb on-line åtkomst<br />

och med goda frågemöjligheter.<br />

154

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!