DataMuseum.dk

top - metrics - download

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

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

TextFile

>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◀