DataMuseum.dk

top - metrics - download

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

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

TextFileVerbose

>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
«eof»