Flensburg P: Personlig databehandling - Per Flensburgs hemsida
Flensburg P: Personlig databehandling - Per Flensburgs hemsida
Flensburg P: Personlig databehandling - Per Flensburgs hemsida
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