DataMuseum.dk

top - metrics - download

    Length: 10752 (0x2a00)
    Types: TextFile
    Names: »nlaext1«

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

TextFile

>a1 INDLEDNING

@Denne opgave er resultatet af projektarbejdet på 
datanom_ud_dannelsens databasemodul.
 Formålet med opgaven er at vise anvendelsen af
data_base modeller og principper når det drejer sig om
ret små systemer, der kører på meget små hard_ware
konfigurationer.




 NB. Da der til opgaven er brugt materiale fra vor
arbejdsplads, må opgaven kun anvendes i forbindelse med 
undervisning, altså ikke i erhvervsmæssig hensigt.
>np

>a1 Den begrebsmæssige model.

Den begrebsmæssige model beskrives 
og vedligeholdes af database 
administratoren
( DBA ) i database management systemets ( DBMS ) data directory ( DAD ).
DBA kendes, når DBMS startes, af 
DBMS og DAD som en priviligeret bruger, der har alle rettigheder
overfor databasens operationelle data og DAD.
Den del af
DAD's indhold, som DBA er ansvarlig for, defineres i SEQUEL2 data sprog .
>sp0
De øvrige brugere af DBMS beskriver ligeledes deres datamodeller ved hjælp af
SEQUEL2. Disse externe modeller defineres ud fra DBA's database beskrivelse,
som, ud over en beskrivelse af de operationelle data 
i relationer, attributter og domæner ( begrebsmæssig model ),
også beskriver den enkelte bruger og dennes rettigheder overfor
databasens enkelte attributter. DBA's beskrivelse
omfatter desuden en definition af den begrebsmæssige/interne mapping.

DBA's definition af databasen er altså 
den vigtigste del af DAD og kan deles i to afdelinger: 
>nf

    - bruger/attribut forhold
    - den egentlige datamodel

>fi
>a2 Bruger/attribut relationer.

Databasens brugere og deres rettigheder 
kan skitseres ved hjælp af følgende
relationer:

>ul
RELATION
ATTRIBUT( ATTR#, DOMÆNE, REL#, ATTR_NAVN, ACCESS-METODE )
>sp0
>ul
KEY
( ATTR# )

I denne relation beskriver DBA databasens attributter,
deres domæner,
hvilken relation de indgår i og 
under hvilket navn samt hvorledes den pågældende
dataenhed findes ( begrebsmæssig/intern mapping ).
Relationen opdateres
af DBMS når externe brugere definerer egne views.
>sp2

>ne 6
>ul
RELATION
RELATION( REL#, NAVN, EJER-ID, TABELHOVED, FORMAT# )
>sp0
>ul
KEY
( REL# )

Samtlige databasens relationer er beskrevet i denne relation.
>sp2
>ul
RELATION
RETTIGHEDER( BRUGER-ID, ATTR#, REL#, ACCESS-RET )
>ul
KEY
( BRUGER-ID, ATTR# )

Denne relation definerer arten af den individuelle brugers adgang 
( eller mangel på samme )
til en bestemt attribut.
>sp2
>ul
RELATION
BRUGER( BRUGER-ID, PRIO, DB-PRIO, NAVN, TLF# )
>sp0
>ul
KEY
( BRUGER-ID )
>sp0
>ul
UNIQUE
( TLF# )

Her beskrives den enkelte 
database bruger og hans rettigheder i forhold
til øvrige brugere hvad cpu ressourcer og database adgang angår.
Med database adgang menes i virkeligheden den strategi, DBMS skal følge i
et tilfælde hvor to brugere skaber en deadlock ved samtidig at være i
besiddelse af den ressource, den anden bruger gør krav på
og gøre krav på den ressource, den anden bruger
er i besiddelse af.
>sp0
DB-PRIO giver DBA adgang til at fratage en lavere prioriteret 
bruger sine ressourcer, således at den højt prioriterede bruger kan fortsætte
med en for systemet vigtigere funktion ( det kan eksempelvis være en vagtoperatør, hvis adgang
til databasen ikke må hindres eller forsinkes )
>sp2
>ul
RELATION
FUNKTION-AFH( ATTR#, AFH-ATTR#, FUNKTION )
>ul
KEY
( ATTR#, AFH-ATTR# )

I denne relation beskriver DBA
funktionelle afhængigheder mellem databasens attributter samt en funktion,
der muliggør en ændring af den attribut, der er funktionelt afhængig
af en anden. Der kan hermed sikres konsistens i databasen.
>sp0
Dette fritager den almindelige bruger for at bekymre sig om attributernes
indbyrdes afhængigheder.
>ne24
>sp24
>fg Funktionelle afhængigheder: bruger/attribut.

>a2 Beskrivelse af den egentlige database
>sp2
Her følger de relationer der er nødvendige for at administrere en alarmcentral
samt udføre vagtens funktioner.
>sp2
>ul
RELATION
AU( AU#, AT#, ADR-KODE, BLOK-L, SERV-DATO, FEJL-T, TXT )
>sp0
>ul
KEY
( AU# )
>sp2
>ul
RELATION
AT( AT#, AB#, STATUS, LINJE, FEJL_T, AKTIVITET,
TYPE, TXT )
>sp0
>ul
KEY
( AT# )
>sp2
>ul
RELATION
VC( VC#, VC-ARRANGEMENT )
>sp0
>ul
KEY
( VC# )
>sp2
>ul
RELATION
AUTOSERV( AT#, STID, OP-KODE, DATA, BLOK-L )
>sp0
>ul
KEY
( AT#, STID )
>sp2
>ul
RELATION
UDEST-MEDDELELSE( AT#, UTID, OP-KODE, DATA, BLOK_L )
>sp0
>ul
KEY
( AT#, UTID )
>sp2
>ul
RELATION
HÆNDELSE( AT#, HTID, VAGT-ID, AKTION, TEXT )
>sp0
>ul
KEY
( AT#, HTID )
>sp2
>ul
RELATION
ABONNENT( AB#, BRANCHE, NAVN, GADE, POST#, TLF#, TAKS, BET#, TEKST )
>sp0
>ul
KEY
( AB#, AT# )
>sp0
>ul
UNIQUE
( TLF# )
>sp2
>ul
RELATION
BY( POST#, BYNAVN )
>sp0
>ul
KEY
( POST# )
>sp2
>ul
RELATION
BETALER( BET#, BRANCHE, NAVN, GADE, POST#, TLF#, TIL_DATO )
>sp0
>ul
KEY
( BET# )
>sp0
>ul
UNIQUE
( TLF# )
>sp2
>ul
RELATION
RYKKER( BET#, RYK#, BELØB, PERIODE )
>sp0
>ul
KEY
( BET# )
>sp2
>ul
RELATION
LOG( AT#, LTID, TXT# )
>sp0
>ul
KEY
( AT#, LTID )
>ne20
>sp20
>fg Funktionelle afhængigheder

>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

>nf
>np
; Vagt pseudo kode

PROCESS vagt( VAR main, dbms, tty, timer, net: SEMAPHORE;
              rt_prio, db_prio: INTEGER );

 BEGIN

 initialize;
 create_channel;
 
 log_on( user_id );

 define_views;

 REPEAT

   WAIT( message, main );

   CASE message_origin OF

    timer:
    BEGIN
     SELECT at_no, op_code, data 
     FROM serv_view
     WHERE time >= timer_clock
     ;
     SIGNAL( service_message, net )
    END;

    tty:
    BEGIN
     decode( mml_command, sequel );
     SIGNAL( sequel, dbms )
    END;

    net:
    BEGIN
     decode( net_message, sequel );
     SIGNAL( sequel, dbms )
    END;

    dbms:
     display;

    OTHERWISE
   END

  UNTIL log_off

END. <* process vagt *>
>fi
>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◀