DataMuseum.dk

top - metrics - download

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

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

TextFile

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