DataMuseum.dk

top - metrics - download

    Length: 4608 (0x1200)
    Types: TextFileVerbose
    Names: »hjafs6«

└─⟦a41ae585a⟧ Bits:30001842 SW-save af projekt 1000, Alarm-system
    └─⟦72244f0ef⟧ 
        └─⟦this⟧ »hjafs6« 

TextFileVerbose

>a1 EXTERNE MODELLER.

@En extern model er en databasebeskrivelse der er 
rettet mod en mestemt brug af databasen
Modellen beskriver s}ledes kun relevante
dele af databasen. Herved opn}s flere ting:
en enklere beskrivelse af databasen, visse felter
kan skjules, {ndringer i databasen ber|rer
ikke alle brugere.
N}r de externe modeller implementeres, er de
beskrevet i et database sprog f.ex. calculus.
her vil vi for l{selighedens skyld n|jes
med at vise de attributter der er med i
releationerne.

>a2 Ekspedition.
@Ekspeditionen tager sig af nogle administrative
rutiner: til- og afmeldning, flytning, m.v.

Abonnent relation

   ATNR   ADR   BETNR   BEM[RK   STATUS



Betaler relation

   BETNR   ADR



Service relation

   STID   ATNR   MODE   STYR   INTERVAL



>a2 BOGHOLDERI

@Bogholderiet tager sig af regningsudskrivning
og kontrol.
@Dets relationer ser s}ledes ud:

Abonnent relation

   ATNR   BETNR   ANTAL YDELSER


Betaler relation

   BETNR   B-ADR   AKKBEL\B   REGNING   G[LD   RYKNR


H{ndelses relation

   ATID   ATNR   TYPE


Regnings relation

   REGNR   BETNR   BEL\B   RDATO


>a2 Vagtoperat|rens model
H{ndelses relationen indeholder en tuppel
for hver h{ndelse. H{ndelser er alarmer
fra abonenter, kvitteringer for styringer,

   ATNR   ALARMTID   ALARMTYPE   V[RDI   AKTION


Abonnentrelation
indeholder en tuppel for hver abonent. BEM[RK er
en tekst p} helt frit format med ekstraoplysninger.

    ATNR   ADR   BEM[RK   STATUS


Service relation indeholder oplysninger om styringer,
der skal foretages p} bestemte tidspunkter (@lige
som telefonv{kning@).

    STID   ATNR   STYREINFO



>a1 DEN INTERNE MODEL
@Den interne model beskriver hvorledes databasen er lagret
p} anl{ggets eksterne lagermedie (disk).
Hertil kan benyttes flere forskellige filstrukturer:
randomiseret direkte acces ( med hashing), index sekventielle
filer, inverterede filer, m.v.
@Da vi her har b}de realtime- og batchproduktion,
har vi valgt at lade hver relation v{re lagret som
en index sekventiel fil. De f|rste poster p} filen
er oplysninger til adm. af filen bl.a. tuppel beskrivelse,
dom{ner, accesrettigheder; resten af filen er en s{dvanlig
index-sekventiel fil.
>br
Vi kan s}ledes bygge p} det katalog og filsystem som er 
leveret med maskinen.


>a1 FORSLAG TIL OPTIMALISERINGER

@Systemet best}r af en tidskritisk applikation 
(@vagtoperat|ren@) og mange batchlignende opgaver.
 For at hj{lpe vagten, der hyppigt vil se p}
de sidst ankomne alarmer indtil de bliver
kvitteret (@vagten skriver i AKTION i h{ndelsen,
hvilken aktion han her taget@), kunne man
have de ukvitterede alarmer st}ende i en relation
for sig. Den vil normalt ikke indeholde ret mange
tupler, oftest kun en sk{rmfuld.
Abonnentrelationen er en temmelig stabil relation
med hensyn til inds{ttelse og sletning, det er
derfor fornuftigt at g|re sig ekstra umage med
dimensioneringen s}ledes at overflow-blokke
undg}s. Vi vil s}ledes altid kunne n} den rette
blok p} nogle enkelte diskaccesser.
>br

@I de ikke-tidskritiske relationer b|r der g|res
en del for at spare plads, da systemet skal udf|res
p} ret sm} maskiner. Et eksempel p} hvordan der kan
spares plads er f|lgende:
@Det kan let ses at mange gadenavne vil g} igen
rundt omkring i databasen. Derfor oprettes en 
gaderelation med  GADEKODE og GADENAVN, og i alle
adressefelter skiftes gadenavn ud med den mindre
gadekode (@ca 600 koder@).
Der bruges i |vrigt mange koder i den interne
repr{sentation. Disse koder oms{ttes selvf|lgelig
til klartekst for operat|ren.

>a1 KONKLUSION
@Selv om vi i opgaven har udeladt nogle af de
aspekter, der b|r med i en analyse af anvendelse af
databaser f.ex. sikkerhed og performance, kan vi 
alligevel godt frage nogle konklusioner.
>br
@Til de funktioner der er velspecificerede
og ret uforanderlige ville et 'skr{ddersyet'
system med direkte adgang til konventionelle filer
v{re lige s} godt, m}ske endda have en bedre
performance end et database-system.
>br
@Men til de funktioner der ikke ligger s} fast, eller 
som opst}r hen ad vejen, har databasesystemet nogle
klare fortrin. Brugeren har nemlig et meget fleksibelt
v{rkt|j, der kan anvendes til nye opgaver, uden det s{dvanlige
besv{r med at f} lavet nye programmer.
For leverand|ren er der den fordel at samme system kan s{lges
til mange forskellige brugere, 
da systemet er langt mere generelt end et 'skr{ddersyet'
system.

«eof»