⟦52d6562a0⟧

TextFileVerbose

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

>ne 22
>ne 12
 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
>ul
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
>ul
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

>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#, 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
>ul
>fg Funktionelle afh{ngigheder: bruger/attribut.
>a2
>ul
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
>ul
>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


pxq

>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»
DataMuseum.dk

RC3500

⟦52d6562a0⟧ TextFileVerbose

Derivation

TextFileVerbose
