rijkswaterstaat BEDRIJFSNORM NR.9 ontwikkelen en beheren van mimer-databases en-applicaties

ministerie van verkeer en waterstaat

rijkswaterstaat dienst informatieverwerking

BEDRIJFSNORM NR.9 ontwikkelen en beheren van mimer-databases en-applicaties

C 5999

voorlopige versie Deze norm kan e.v.t. nog worden bijgeateld naar aanleiding van de resultaten van de invoering van SDM JL.

rijkswaterstaat

di«ntt in(ormati«v«rw*rking

BEDRIJFSNORM NR. 9

linM

Ontwikkelen en beheren van MIMER-databases en -applicaties

ilaii«n ni«uw

Haiumouoi

880201

INHOUDSOPGAVE

PAGINA

1.

DEFINITIE

3

1.1. Vaststellen van de bedrij fsnorm

3

1.2. Vervallen en vervangen

4

1.3. Algemeen

4

1.4. Geldigheidsgebied

4

1.5. Wijze van hanteren

5

1.6. Afwijkingen van de bedrij fsnorm

5

1.7. Toezichthoudende instantie

5

2. INDELING VAN DE NORM

6

2.1. SDM II fasering

9

2.2. Aspecten

10

3. INFORMATIE PLANNING (SDM II fase 0)

11

4. DEFINITIE STUDIE (SDM II fase 1)

12

5. BASIS ONTWERP (SDM II fase 2)

14

6. DETAIL ONTWERP (SDM II fase 3)

18

7. REALISATIE (SDM II fase 4)

20

8. INVOERING (SDM II fase 5)

26

9. GEBRUIK EN BEHEER (SDM II fase 6)

27

APPENDIX A. GEBRUIKTE TERMEN EN BEGRIPPEN.

29

APPENDIX B. LITERATUUR OVERZICHT.

33

REF.NR.

b3^q SIGN.

j'iaat a V. ,\ -'/,^,..-... , .^ / \}

/"\r^

^-X^ïwVVÎH.

f

rijkswaterstaat

di«nst informatMycrwarking

BEDRiJFSNORM NR. 9

°Mk7


nooidttuk

datum ntauw

tdaium cxjo)

880201

1. DEFINITIE 1.1. Vaststellen van de bedrijfsnorm De bedrij fsnorm voor het ontwikkelen en beheren van MIMERdatabases en -applicaties is.goedgekeurd en vastgesteld door het Directieteam van de Dienst Informatieverwerking van de Rij kswaterstaat. De bedrij fsnorm bestaat uit 28 bladen + 5 bladen Appendices en is alleen geldig indien ondertekend door de Hoofdingenieur-Directeur van de Dienst Informatieverwerking. Datum van vaststellen: 1 februari 1988. De Hoofdingenieur-Direct

Datum van ingang: zie datum van vaststellen.

rijkswaterstaat

dienst infofmatwv«rw*rking

BEDRIJFSNORM NR. 9

ïâ^

blad


MlkfTi niauw

tdatum ouoi

880201

1.2. Vervallen en vervsmgen Gelijktijdig met de vaststelling van de Bedrij fsnorm voor het ontwikkelen en beheren MIMER-databases en -applicaties worden de onderstaande documenten vervallen verklaard en door deze bedrij fsnorm vervangen. Vervallen documenten; Memo's "Bedrijfsnorm MIMER" van POM (1986-2098 en 1987-237). 1.3. Algemeen In deze bedrijfsnorm zijn afspraken over de wijze, waarop databases en database-âpplicaties met behulp van MIMER ontwikkeld en beheerd moeten worden, vastgelegd in de vorm van standaards. Hierbij komen onderwerpen zoals database-ontwerp, autorisatie, backup en herstel en organisatie aan de orde. Voor een schema en beschrijving van alle MIMER-onderdelen wordt verwezen naar "Technical Facts About the MIMER System" en "A Primer for the MIMER System" (zie Appendix B ) . 1.4. Geldigheidsgebied Deze bedrijfsnorm is van kracht: - In geval van het ontwikkelen van MIMER-databases en -applicaties door of onder verantwoordelijkheid van de DIV. - In geval van toetsing bij overdracht aan de exploitant van elders ontwikkelde MIMER-databases en -applicaties. - In geval van het beheren van MIMER-databases en -applicaties. Deze norm is geldig voor de volgende MIMER-versies: Release Onderdelen

StDerry 1100 4.2 en hoger. Alle.

Vax 4.2 en hoger. Alle.

PC 3.2 en hoger. Alle, behalve MIMER/PG en /SH-editor.

N.B. Voor Sperry 1100 en Vax sluit dit niet uit, dat veel zaken ook op release 3.2 van toepassing zijn.

rijkswaterstaat

di«nst informati*<Mrwttrking

BEDRIJFSNORM NR. 9

dlöi^


daiixn ni«uw

Ktatum ouol

880201

1.5. Wijze van hanteren Deze bedrij fsnorm dient als standaard gehanteerd te worden. Dit betekent dat de bedrij fsnorm zonder meer .als bindend dient te worden beschouwd. 1.6. Afwijkingen van de bedrijfsnorm De richtlijnen en standaards zijn met name van toepassing op die systemen, waarbij hoge eisen gesteld worden aan beschikbaarheid en continuïteit van het database-systeem (=database + MIMER-pakket) en aan de betrouwbaarheid van de gegevens. Het is goed denkbaar dat er systemen ontwikkeld worden, waarvoor deze eisen veel lager gesteld zijn. Per geval zal dan bekeken moeten worden, welke standaards in verband met de daaraan verbonden kosten niet van toepassing zijn. Afwijkingen óp de standaards dienen van te voren met de verantwoordelijke instantie (DBA) besproken te worden en door de Directie te worden goedgekeurd. Deze afwijkingen zullen duidelijk aangegeven dienen te worden in de documentatie. 1.7. Toezichthoudende instantie De DBA houdt toezicht op het (juist) toepassen van drij f snorm.

deze be-

Tevens zal zij: - als vraagbaak fungeren, - voorlichting geven over de bedrij fsnorm, - afwijkingen op de norm registreren. Daar waar in deze bedrij fsnorm keuzemogelijkheden genoemd worden, dient de DBA akkoord te gaan met de uiteindelijke keuze. Sommige zaken (zoals b.v. de tool-strategie) kunnen niet dwingend worden voorgeschreven, doch moeten per situatie bekeken worden.

rijkswaterstaat

d(«nst inform«ti«v«rw»rking

BEDRIJFSNORM NR. 9

\mM


880201

2. INDELING VAN DE NORM Bij het ontwilckelen van informatiesystemen, welke gebruik maken van relationele database management systemen en vierde generatie ontwikkelingstools, komen verschillende aspecten zoals performance, backup en herstel, database-ontwerp etc. aan de orde. Het is van belang aan deze aspecten reeds in een vroeg stadium van het ontwikkelingstraject aandacht te besteden. Ook kunnen deze aspecten invloed uitoefenen in meerdere fasen van het traject. Men kan dit zien als een matrix, waarbij langs de ene as de SDM II fasering is uitgezet en langs de andere as de ontwerp aspecten. Deze matrix wordt op de volgende twee bladzijden gepresenteerd:

rijkswaterstaat

dl«nsi inform«tt«v«rw«
hooioiluk

BEDRIJFSNORM NR. 9

blad

djuD^


daium niauw

tdaiumouol

880201

A S P E C T E N

Database-ontwerp

Autorisatie

Applicatie-ontwerp

-Globale autorisatiestructuur

-Geschikheid MIMER -Externe samenhang -Globaal gegevensmodel

-Tool-strategié -Autorisatie-Conceptueel gegevensmodel -Transactie-afhande- hiërarchie -Afstemming andere lingsstrategie (MIMER-)databases

•Fysiek database- -Database foutafhandelingsstrategie ontwerp -Transactie-opties -Transacties + afhandeling -Gelijktijdig gebruik

•Invulling autorisatie

-Databank indeling -Gebruik van MIMER/ DB,/QL,/PG,/SH,/FM -Creatie met MI-Initieel laden MER/ CL -Onderhoudsblokkade

-Creatie met MIMER/CL

-Performance-meting en tuning db -Wij zigingsprocedure

-Onderhoud autorisatie

Matrix SDM II / Aspecten

deel 1

rijkswaterstaat

dl«n(t informati*v«rw«rking

BEDRIJFSNORM NR. 9

ïmM

Blad


8

datum n>*uw

tdtiumouol

880201

A S P E C T E N Backup en herstel Operating Systeem omaevina en testen

Organisatie

0 -Instelling DBA 1 -Urgentie bepaling -Globale performance -Voorlichting eisen MIMER

s D M

2 -Backup/herstelstrategie

I I

-Performance-eisen -Systeem recources

f a s e r 3 -Backup/hersteli n eiseii g

-Cursussen ontwikkelaars -Taakverdeling inhoudelijk + technisch beheerder en DBA

4 -Backup/herstelprocedures

-Beveiliging db op os-niveau -Spreiding databanks over disks -Real-life performancetest -Test/produktieversie

5 -Cursussen gebruikers 6

Matrix SDM II / Aspecten

deel 2

rijkswaterstaat

di«nst inform«tt*v*rw«rking

BEDRIJFSNORM NR. 9

dlW

eiad


880201

2.1. 8DM II fasering De hoofdas van de matrix bestaat uit de fasering zoals deze binnen SDM II gebruikt wordt. Voor een beschrijving van de fasen van SDM II wordt verwezen naar de SDM handboeken. De volgende fasen worden onderscheiden: Fase O Informatie Planning. Fase 1 Definitie Studie. Fase 2 Basis Ontwerp. Fase 3 Detail Ontwerp. Fase 4 Realisatie. Fase 5 Invoering. Fase 6 Gebruik en Beheer. De hoofdstukindeling binnen deze norm is confonn bovenstaande SDM II fasering. Het is echter niet de bedoeling om in deze bedrij fsnorm een volledige SDM Il-checklist op te nemen. De wijze waarop binnen de DIV SDM II gehanteerd zal gaan worden, wordt in een aparte bedrij fsnorm beschreven. In deze MIMERbedrijfsnorm zal per SDM Il-fase aangegeven worden aan welke MIMER-specifieké ontwerp aspecten aandacht besteed dient te worden, om uiteindelijk tot een goed werkend en beheersbaar informatiesysteem te komen. Hierbij zal een geringe overlap met de bedrij fsnorm voor SDM II onvermijdelijk zijn. Deze overlap zal vooral betrekking hebben op algemene database aspecten in de fasen Informatie Planning, Definitie Studie en Basis Ontwerp.

rijkswaterstaat

di«n«t informatMvwrwerking

BEDRIJFSNORM NR. 9

hootasiuk

blad

su[k7

Ontwikkelen en beheren van MIMER-^databases en -applicaties

10 datum ni«u«>

Malum ouoi

880201

2.2. Aspecten Er spelen binnen het ontwikkelen en beheren van MIMER-applicaties een aantal aspecten een belangrijke rol. Deze aspecten kunnen we onderverdelen in de volgende groepen: Database-ontwerp. Hieronder vallen alle zaken, welke uiteindelijk moeten resulteren in een goed werkende MIMER-database. Het betreft hier zowel het opstellen van het gegevensmodel als het implementeren van de fysieke databasestructuur . Applicatie-ontwerp. Hieronder vallen alle MIMER aspecten, welke onderdeel uitmaken van het applicatie-ontwerp. Hierbij gaat het om zaken als transactie-afhandeling, database-foutafhandeling en het gebruik van de diverse MIMER-onderdelen. Autorisatie. De mogelijkheden, welke MIMER biedt met betrekking tot het beveiligen van gegevens tegen ongeoorloofd gebruik. Backup en herstel. Richtlijnen voor het herstellen van databases na calamiteiten. Operating systeem omgeving en testen. Hieronder verstaan we zowel de invloed van het operating systeem op MIMER en hiermee op het functioneren van de applicatie, als de richtlijnen voor het testen van het database-systeem. Organisatie. Een beschrijving van de functies en opleidingen voor diegenen die betrokken zijn bij het goed functioneren van het database-systeem. Per SDM Il-fase zullen in het vervolg steeds de voor die fase relevante aspecten behandeld worden. Er moet hierbij echter worden opgemerkt, dat in deze bedrij fsnorm alleen de MIMERspécifieke aangelegenheden worden beschreven. Daarnaast blijven de algemene ontwerp-, programmeer- en testnormen uiteraard van toepassing.

rijkswaterstaat

dienst informatwtwrwvrking

BEDRIJFSNORM NR. 9

°juïk7


hoofdtluk

11 OaCunt ni«uw

I d i i u m ouoi

880201

3. INFORMATIE PLANNING (8DM II fase 0) Organisatorische aspecten. Instelling DBA. Alvorens er binnen een organisatie applicatiesystemen met behulp van MIMER gebouwd gaan worden, moet er een DBA (DataBase Administrator) worden aangewezen. De DBA is een persoon (of een groep personen) wiens taken van bedrijf tot bedrijf verschillen, maar die zich in het algemeen bezighoudt met het beheer van bestaande database-systemen en het verlenen van ondersteuning bij de ontwikkeling van nieuwe database-systemen. Belangrijke taken hierbij zijn: - Installeren en testen van nieuwe releases van MIMER. - Uitvoeren van het technisch database-beheer zoals backup en herstel en performance metingen. - Uitvoeren van het database-ontwerp. - Ondersteuning verlenen bij het applicatie-ontwerp. - Tuning van het database-systeem. - Zorg voor het naleven van standaards en richtlijnen. - Onderhouden van de data-dictionary. - Copy management (= toezicht houden op distributie van extracten uit databases). Bij de DIV bestaat de DBA uit een samenwerkingsverband van vertegenwoordigers uit de verschillende hoofdafdelingen, onder voorzitterschap van de Coördinator Databases uit POA/db. Bij de AIV's van de directies die MIMER op hun Vax of PC's hebben, dient een persoon te worden aangewezen, die als (decentrale) DBA zal fungeren. Deze persoon is dan tevens contactpersoon voor de centrale (DIV-) DBA.

rijkswaterstaat

dl«nst inforfn«ti*v«rw*rking

BEDRIJFSNORM NR. 9

°Mk7^

hootdsiuk

12


dati«n ni«uw

Maiumouoi

880201

4. DEFINITIE STUDIE (SDM II fase 1) Database-ontverp aspecten. Bepaal geschiktheid MIMER. Bepaal of MIMER de juiste omgeving biedt voor het bouwen in produktie houden van het nieuwe informatiesysteem.

en

Definieer de externe samenhang. Dit heeft tot doel in een vroeg stadium inzicht te krijgen in de relaties tussen het te bouwen systeem en eventuele andere (al bestaande of nog te bouwen) informatiesystemen. Voor wat betreft het op te stellen gegevensmodel dienen de volgende aspecten aan de orde te komen: - het kader waarbinnen het gegevensmodel valt moet vastgesteld worden. - de systeemgrenzen dienen bepaald te wórden. - de relaties met andere systemen moeten beschreven worden. Definieer een globaal gegevensmodel. Reeds tijdens • de fase Definitie Studie is het van belang aandacht te besteden aan de gegevens, die binnen het gestelde kader een rol spelen, alsmede aan de samenhang tussen deze gegevens. We noemen deze activiteit: het opstellen van een globaal gegevensmodel, Een globaal gegevensmodel dient minimaal de volgende onderdelen te bevatten: - een omschrijving van de belangrijkste entiteiten of entiteitsgroepen. - een globale beschrijving van alle relaties tussen deze entiteiten. - een schatting van de aantallen occurrences per entiteit. - een Bachman-diagram.

rijkswaterstaat

dl«n«t informatt«v«rw*rkino

BEDRIJFSNORM NR. 9

^M^


13 dalunt nt«uw

Mllumouoi

880201

Autorisatie aspecten. Definieer de globale autorisatie-structuur. De globale autorisatie-structuur geeft aan, welke groepen gebruikers en beheerders van het systeem gebruik maken en wie verantwoordelijk is voor welke gegevens in het globale gegevensmodel. Deze globale autorisatie-structuur dient de volgende gegevens te bevatten: - een beschrijving van alle groepen gebruikers. - een beschrijving van alle (groepen) beheerders. - een overzicht van de verantwoordelijke (groepen) beheerders/gebruikers per entiteit op basis van het globale gegevensmodel. Backup en herstel aspecten. Bepaal de urgentie. Bepaal of het noodzakelijk is regelinatig backups te maken en herstelmogelijkheden te bieden in het geval van systeemstoring. Qperatinq systeem en test aspecten. Definieer globale performance-eisen. Geef per functie een indicatie van de gewenste en de maximale response- en doorlooptijden. Organisatorische aspecten. Voorlichting MIMER. Indien het produkt MIMER nog niet of onvoldoende bekend is bij de ontwikkelaars en/of de gebruikers, zorg dan voor een gepaste vorm van voorlichting over de wérking en de mogelijkheden van het MIMER-pakket.

dUnst informatwvvrwarking

fijkSWaterStaat

BEDRIJFSNORM NR. 9

°M^

5 14


dalurr ni«u»i

M d u m ouol

880201

5. BASIS ONTWERP (SDM II fase 2) DataJaase-ontverp aspecten. Maak een conceptueel aeaevensmodel. Het globale gegevensmodel wordt verder uitgewerkt tot een zogenaamd conceptueel gegevensmodel. Het conceptuele gegevensmodel is een gedetailleerde beschrijving van de structuur van alle gegevens, die in het informatiesysteem moeten worden opgeslagen. Dit gegevensmodel moet zich in derde normaalvorm bevinden en dient de volgende informatie te bevatten: - een volledige definitie van alle entiteiten. - een volledige definitie van alle attributen (zowel de kenmerkende als de beschrijvende attributen). - de waardebereiken van de attributen. - een volledige definitie van alle relaties tussen de entiteiten (de permanente en optionele relaties) zowel l:n als 1:1 relaties. - de aantallen occurrences per entiteit. - de aantallen occurrences per relatie. - een Bachman-diagram. - de definitie van de constraints. Dit wil zeggen: alle eenheden van integriteit voor database-wijzigingen (zowel entiteitsintegriteit, referentiële integriteit als database-afhankelijke integriteit). - maak een globale Toegangs Pad Analyse (TPA) in de vorm van een matrix met langs de ene as de functies, langs de andere as de entiteiten en op de snijpunten de operaties (update, retrieval, insert of delete). Afstemming met andere (MIMER-) databases. Zorg voor afstemming met andere databases om een zo groot mogelijke eenvormigheid te bewerkstelligen, waardoor de mogelijkheden van integratie in de toekomst zo optimaal mogelijk zijn. Afstemming dient te geschieden op de volgende punten: -

structuur. naamgeving. definitie. waardebereiken.

rijkswaterstaat

dt«n«t informatwvwrwcrking

BEDRIJFSNORM NR. 9 6iad

OJUÏ!:^


15

datum n*«uw

(da t um oua i

880201

Applicatie-ontwerp aspecten. Definieer de tool-strateaie. Bepaal, in samenspraak met de DBA, voor welke delen van het applicatie-systeem welke MIMER-onderdelen gebruikt zullen gaan worden. Voor programmering kan men kiezen tussen PG, level-2/level-4 programma's of QL-procedures. Deze laatste zijn bij uitstek geschikt voor prototyping. Complexere applicaties worden in principe in PG geprogrammeerd. Indien PG niet toereikend is, wordt gebruik gemaakt van level-4 programma's. Van level-2 programma's wordt alleen gebruik gemaakt, indien PG noch level-4 programma's toereikend zijn om de betreffende functie te kunnen programmeren. Voor schermafhandeling dient, vanaf het moment dat FM als volwaardig schermpakket geaccepteerd is, van FM gebruik te worden gemaakt. Dit omdat SH met ingang van release 4.2 bij Sperry 1100 niet meer, en bij Vax en PC slechts op verzoek geleverd wordt. Bovendien is FM sneller en levert een kleiner executable. Totdat FM als volwaardig schermpakket geaccepteerd is, dient SH slechts te worden gebruikt met beperkte functionaliteit (zoals beschreven bij "Gebruik van MIMER/SH" uit de fase Realisatie). De DBA zal ten allen tijde akkoord moeten gaan met de gekozen tool-strategie. Definieer de transactie-afhandelingsstrategie. Definieer de algemene strategie voor het afhandelen van nietsuccesvolle transacties t.g.v van transactie-conflicten. Hierbij moet gedacht worden aan twee mogelijkheden, te weten: 1 - Het ten allen tijde automatisch opnieuw proberen van de database-operaties ingeval van een niet-succesvolle commit. 2 - Het meedelen aan de gebruiker van een niet-succesvolle commit en de gebruiker zelf de operatie opnieuw laten uitvoeren. De eerste methode kenmerkt zich door een grotere gebruikersvriendelijkheid, maar vergt wel een extra hoeveelheid programmeerwerk (vasthouden van waarden, extra controles e t c ) . Voor de tweede methode is dit juist andersom. Ook de te verwachten freguentie van niet-succesvolle commits kan meespelen in de keuze van de strategie.

rijkswaterstaat

dl*ntt in(ormatt«v*rw*rking

BEDRIJFSNORM NR. 9

\mM

Diaa


16

Oalum nieuw

idttumouai

880201

Autorisatie aspecten. Definieer de autorisatie-hiërarchie.

-^

De autorisatie-hiërarchie is een verdere uitwerking van de autorisatie-structuur, vastgesteld in de Definitie Studie. De volgende zaken dienen gedefinieerd te worden: - bepaal de gebruikers en beheerders (groepen) en geef de onderlinge hiërarchie weer. - bepaal per groep de noodzakelijke toegangen en privileges . - maak een matrix, waarin de gebruikers en beheerders (groepen) worden uitgezet tegen de entiteiten uit het conceptuele gegevensmodel en geef per combinatie aan, of de betreffende groep de gegevens mag invoeren, wijzigen, verwijderen, lezen of helemaal niet mag zien. N.B. Beveiliging (met name van gevoelige gegevens) is niet alleen via autorisatie binnen MIMER te regelen, maar stelt ook eisen aan de toegang tot het betreffende computersysteem en de organisatie. Backup en herstel aspecten. Definieer de baekup- en herstelstrateqie. Afhankelijk van de urgentie van baekup en herstel, vastgesteld in de Definitie Studie, wordt hier de baekup- en herstelstrategie beschreven. Hiervoor is het noodzakelijk de volgende zaken te bepalen: - geef een indicatie ten aanzien van de frequentie van baekup. - bepaal de gewenste en de maximale doorlooptijd voor hét maken van de baekup. ^ - bepaal de gewenste en de maximale doorlooptijd voor herstel. Qperatinq systeem en test aspecten. Definieer de performance-eisen. Definieer per functie de vereiste en de maximale response- en doorlooptijden, alsmede de periodiciteit van de functie. Dit is een aanduiding hoe vaak de functie wordt aangeroepen.

rijkswaterstaat

d(«n*t informati*v«rw«rking

BEDRIJFSNORM NR. 9

\mM


17 dalum ni«uw

fdaium ouoi

880201

Bepaal systeem resources. Om continuïteit in de ontwikkeling en produktie te kunnen waarborgen is het nodig in een vroeg stadium de gewenste systeem recources te kennen. Daartoe dienen de benodigde recources voor de volgende aspecten bepaald te worden: - opslagcapaciteit en CPU-belasting voor het ontwikkelingstraject. - opslagcapaciteit en CPU-belasting gedurende de produktie van het systeem. - opslagcapaciteit en CPU-belasting ten aanzien van de te verwachten groei van het systeem. Organisatorische aspecten. Definieer taakverdeling Inhoudelijk Beheerder. Technisch Beheerder en DBA. Vastgelegd dient te worden wat de verschillende taken, verantwoordelijkheden en bevoegdheden zijn van de inhoudelijk beheerder, technisch beheerder en database administrator (DBA). De DBA en technisch beheerder kunnen verenigd zijn in één persoon of groep. Ook dienen de taken van de aanleverende instanties te worden vastgelegd. Verzorg cursussen voor ontwikkelaars. Indien de ontwikkelaars niet over de noodzakelijke MIMERkennis en -ervaring beschikken, zorg dan voor een -gepaste opleiding.

rijkswaterstaat

cH«nst informati*y«rw*rking

BEDRIJFSNORM NR. 9

°Mk7

hoolOttuk

18


datum niauw

tdaiumouo)

880201

6. DETAIL ONTWERP (8DM II fase 3) Dataüaase-ontwerp aspecten» Maak het fysieke database-ontwerp. Het conceptuele gegevensmodel wordt nu met behulp van een Toegangs Pad Analyse (TPA) vertaald naar het fysieke database-ontwerp. - Beschrijf de toegangspaden en rangschik deze naar zwaarte volgens de performance-eisen, zoals geformuleerd in het Basisontwerp. - Definieer mede aan de hand van bovenstaande gegevens de tabellen, kolommen, primaire sleutels, secundaire sleutels, views en domains. - Geef een verantwoording voor elke afwijking van de derde normaalvorm, die hierbij zou kunnen optreden. Definieer de transactie-opties. Per tabel dient vervolgens bepaald te worden welke transactie opties (NOTRANS, WTRANS, RWTRANS, TRANS) noodzakelijk zijn. Applicatie-ontverp aspecten. Bepaal foutafhandelingsstrategie voor database-manipulatie. Het benaderen van een MIMER-database zal niet in alle gevallen resulteren in het juist uitvoeren van de gewenste operatie. In sommige gevallen kan namelijk een foutcode geretourneerd worden bij bijvoorbeeld update van een niet-bestaande irij. Er dient een algemene strategie gedefinieerd te worden voor foutsituaties. Transacties en transactie-afhandeling. De constraints uit het conceptuele gegevensmodel vormen de basis voor het definiëren van MIMER-transacties, welke in de programmatuur gebruikt moeten' worden om een integere database te garanderen. De volgende zaken dienen gedefinieerd te worden: - transacties. - per transactie te plegen acties bij succesvolle commit. - per transactie te plegen acties bij niet-succesvolle commit t.g.v. transactie-conflicten.

rijkswaterstaat

dl«ntt informatwvvrwarking

BEDRIJFSNORM NR. 9

\mM

hoOlOlluk

61* d


19 dattxn ni«uw

lOilum oual

880201

Bepaal aeliiktiidiq gebruik. Het is mogelijk, dat sommige functies in een applicatie niet gelijktijdig met andere functies uitgevoerd nrogen worden. Denk hierbij bijvoorbeeld aan het wijzigen van de database en het maken van een extract ten behoeve van een PC-applicatie. Ook is het maken van een backup een functie welke over het algemeen slechts in een systeem uitgevoerd zal'mogen worden, waarin door andere gebruikers op dat moment hoogstens gelezen wordt. Er zal bepaald moeten worden welke delen van het applicatiesysteem wel of niet samen met welke andere delen uitgevoerd kunnen worden. Tevens zal er gedefinieerd moeten worden hoe dit gerealiseerd wordt. Autorisatie aspecten. Invulling autorisatie. Aan de hand van de autorisatie-hiërarchie uit het Basis Ontwerp vindt er nu een verdere invulling plaats. Definieer hiertoe de volgende MIMER-zaken: -

user idents. group idents. program idents. access (op tabel en/of view) per group ident. access (op tabel en/of view) per user ident. privileges.

Backup en herstel aspecten» Definieer de backup- en hersteleisen. De backup- en herstelstrategie uit het Basis Ontwerp wordt nu verder uitgewerkt: - Definieer per tabel de frequentie van backup. - Definieer welke tabellen gezamenlijk als eenheid in de herstelprocedure beschouwd dienen te worden in verband met de referentiële integriteit. - Maak een keuze ten aanzien van de te gebruiken backup utility (MIMER-backup, operating systeem backup of een mix van beide).

rijkswaterstaat

di*nst i n f o r m a t i « v * r w e r k i n g

BEDRIJFSNORM NR. 9

diui^

hooiosiuk

20


Oaluni ni«uw

Maiumouai

880201

7. REALISATIE (8DM II fase 4) Database-ontverp aspecten. Bepaal databank indeling. De tabellen dienen over de gewenste databanks (= fysieke files) verdeeld te worden. De basis voor deze indeling wordt gevonden in de volgende aspecten: - transactie-opties per tabel (uit de fase Detail Ontwerp) . - backup- en hersteleisen per tabel (uit de fase Detail Ontwerp). - aantallen (uit de fase Basis Ontwerp). - beveiligingsmogelijkheden op operating systeem niveau (uit de fase Realisatie). Creëer de database. Het fysieke database-ontwerp wordt nu geïmplementeerd: - Creëer de database niet onder een user ident maar onder een program ident in verband met het eventueel later verwijderen van de betreffende user. - Hanteer, indien aanwezig, de door de exploitant gedefinieerde standaards met betrekking tot filenamen, directory-structuur etc. - Gebruik MIMER/CL met input files voor het creëren van databanks, tabellen, views en domains. Dit dient om de database-creatie te kunnen reproduceren en kan tevens als documentatie dienen. Applicatie-ontwerp aspecten. Gebruik van MIMER/DB routines. Maak alleen gebruik van level-2 routines, indien level-4 routines niet toereikend zijn en gebruik level-4 routines alleen, indien PG niet toereikend is (zie Tool-strategie uit de fase Basis Ontwerp). Voor het juist benaderen van de MIMER-database d.m.v. level-2 en level-4 routines gelden de volgende standaards: - Maak bij het ontwikkelen van applicaties met behulp van DB/scherm routines gebruik van de door de DIV ontwikkelde interfaces DBINT en SHINT. Dit met het oog op onderhoud en toekomstige conversies. Op de Sperry 1100 staan deze interfaces op de file DIEX*MIMLIB. Op Vax en PC zullen deze interfaces door de DBA worden geïmplementeerd zodra ze hier nodig zijn.

dl«flst inform«ti«v«rw«rking

rIjkSWaterStaat

BEDRIJFSNORM NR. s

dMi^

nooiasiuk

7 DUO


21 dalum nwuw

Matumouoi

880201

- Als transacties gebruikt worden, dient de tijd tussen het begin (CALL BEGTR2) en het eind (CALL ENDTR2) van de transactie zo klein mogelijk te zijn. - De BASE variabele in level-2 calls dient- gedefinieerd te zijn in COMMON-storage. - Sluit de database af op de juiste manier (CALL CL0ST2, CALL CL0SD2 en CALL END2) voordat het programma beëindigd wordt. - Controleer bij alle database-benaderingen of de operatie succesvol is verlopen, door het testen van de returncode. - Gebruik geen "*" om alle kolommen aan te geven om onderhoud in de toekomst te beperken. - Maak een PROJECT voor alle kolommmen, welke benaderd worden. - Gebruik de NO-OPTIMIZE optie bij Fortran-compilaties (voorschrift van de leverancier). - Definieer nieuwe tabel-cursors in plaats van PUSH2, P0P2 en DEQUE2. - Zorg voor de optimale benadering van de database, door de juiste volgorde in de SELECi2 calls (zie ook MIMER/DB manual). - Maak standaard subroutines voor de PR0JE2 calls vooralle tabellen. - Het afwisselend gebruik van level-2 en level-4 routines in één programma kan problemen veroorzaken en is dus verboden. Gebruik of alleen level-4 routines, of alleen level-2 routines. - Definieer werktabellen in WORKDB. Gebruik van MIMER/PG. Voor een juist gebruik van PG bij het ontwikkelen gramma's gelden de volgende standaards:

_

van

pro-

- Gebruik de UNSORTED optie bij de GET, tenzij een specifieke sorteervolgorde gewenst wordt. Als er een selectie op sleutels plaatsvindt, zullen de records in deze volgorde beschikbaar komen. In de meeste gevallen is de volgorde dan^_al juist of niet relevant. Het gebruik van de UNSORTED optie reciteert— dan in meer efficiënte programma's. - Gebruik procedures in plaats van REPORT GET 1. Hierdoor wordt meer efficiënte en meer flexibele code gegenereerd . - Indien een report op meerdere plaatsen in een programma of procedure aangeroepen wordt, doe dit . dan in een LOCAL PROCEDURE. Dit resulteert in een kleiner programma. - Definieer tijdelijke tabellen (DEFINE TEMPORARY) aan het begin van het hoofdprogramma. - Declareer alle variabelen in procedures aan het begin van de procedure tussen de statements PROCEDURE ( ) ; en BEGIN.

rijkswaterstaat

dt*n«t informati«v«rw*rking

BEDRIJFSNORM NR. 9

dlW


22 aaium ni«uw

Walumouoi

880201

- Initialiseer alle gedeclareerde variabelen aan het begin van de procedure, dus na BEGIN. - Bij het gebruik van het OPEN (file-id,...) statement, dient de OPEN uitgevoerd te zijn vóór de eerste WRITE. Is dit niet het geval, dan schrijft het gegenereerde Fortran-programma de output niet naar de file, maar naar de terminal. - Bij het doorgeven van file-id's naar procedures, dient de file-id als type INTEGER doorgegeven te worden inplaats van type FILE. - Gebruik, indien aanwezig, de standaard-naamgeving voor programma's, procedures, reports, schermen en variabelen volgens de normen van de exploitant. - Met uitzondering van algemene procedures en reports dienen programma's, procedures en reports, welke bij elkaar horen, in dezelfde PG procedure library opgeslagen te worden. - Voor Vax en Sperry 1100: genereer Fortran. Cobol-generatie geeft namelijk een groter executable. - Voor PC: genereer C. Fortran geeft een groter en moeilijker te linken object module. - Maak generatie/compile/link procedures. Dit om het onderhoud te vereenvoudigen. Voorbeelden van deze procedures zijn te verkrijgen via de DBA. Gebruik van MIMER/OL. Voor een goed gebruik van QL gelden de volgende standaards: - Controleer bij alle database-benaderingen of de operatie succesvol is verlopen, door het testen van de returncode. - QL mag niet gebruikt worden, indien meervoudige updates binnen één transactie moeten vallen. Gebruik van MIMER/SH. SH dient alleen gebruikt te worden, zolang FM nog niet als volwaardig schermpakket geaccepteerd is. Vanaf release 4.2 is SH niet meer aanwezig op de Sperry 1100. Bij het gebruik van SH gelden de volgende standaards: - Maak bij het ontwikkelen van applicaties met behulp van DB/scherm routines gebruik van de door de DIV ontwikkelde interfaces DBINT en SHINT. Dit met het oog op onderhoud en toekomstige conversies. Op de Sperry 1100 staan deze interfaces op de file DIEX*MIMLIB. Op Vax en PC zullen deze interfaces door de DBA worden geïmplementeerd zodra ze hier nodig zijn. - Gebruik de NO-OPTIMIZE optie bij Fortran-compilaties (voorschrift van de leverancier). - Gebruik de volgende SH-commando's niet, om conversie naar FM in de toekomst op een relatief eenvoudige manier te kunnen realiseren:

rijkswaterstaat

dt«nst in(orm«ti«v*rw*rking

BEDRIJFSNORM NR. 9

dluM'

Oiad

Ontwikkelen en beheren van MIMER-databases en - r a p p l i c a t i e s

23

daturri n»«uw

idaiumoua)

880201

- het wissen van vaste teksten in een picture (routine CLPSH2, type="T") - het wissen van een deel van het scherm (routine CLSSH2, code="R" of "RC") - het leggen van een verbinding tussen velden of tussen velden en een variabele (routine C0NSH2) - het springen naar een ander veld (routine IMPSH2) - het prompten om een antwoord vanaf de terminal (routine PMTSH2) - het projecteren van een scherm(veld) op een tabel (routine PR0SH2) - het direct maken van een selectie in een tabel aan de hand van een schermveld (routine SELSH2) - het afdrukken van een boodschap in een andere dan de default message area (routine MSGSH2) - het instellen van SH-parameters (routine SETSH2) - het definiëren van message areas en prompters (routine DEFSH2) - het opvragen van status informatie (routine GINSH2) - het gebruik van check/unit en check/exit routines - het gebruik van controle code "RB" - het "field given" concept - het gebruik van display edit routines en patterns - het gebruik van de pijltoetsen om het scherm te verlaten. Gebruik van MIMER/FM. Voor een goed gebruik van FM gelden de volgende standaards: - Maak bij het ontwikkelen van applicaties met behulp van DB/scherm routines gebruik van de door de DIV ontwikkelde interfaces DBINT en SHINT (deze laatste zal t.z.t. worden geconverteerd van SH naar FM). Dit met het oog op onderhoud en toekomstige conversies. Op de Sperry 1100 staan deze interfaces op de file DIEX*MIMLIB. Op Vax en PC zullen deze interfaces door de DBA worden geïmplementeerd zodra ze hier nodig zijn. - Gebruik bij voorkeur een FM-form voor het opslaan van standaard boodschappen welke met het MESSAGE statement verstuurd worden. Dit is sneller dan een eigen boodschappen tabel. - Gebruik de bovenste regel van het scherm bij voorkeur niet, behalve eventueel voor het geven van foutboodschappen. FM gebruikt deze regel voor foutmeldingen zoals "INPUT MISSING" en "NUMERIC REQUIRED".

- Gebruik de onderste beschikbare regel van het scherm niet, behalve eventueel voor het geven van boodschappen. In verband met compatibiliteit (IBM omgeving) gebruikt FM deze regel alleen voor het geven van boodschappen .

rijkswaterstaat

dl«nst informati«v«rw*rking

BEDRIJFSNORM NR. 9

\mM

hootosiuk

24


datum ni«uii>

Milumouoi

880201

Initieel laden. Om het mogeljk te maken de database opnieuw op te bouwen (bijvoorbeeld voor een nieuwe versie van het systeem) is het noodzakelijk de volgende zaken beschikbaar te hebben: -

te gebruiken load-opties. te gebruiken transactie-opties. te gebruiken programma's. te gebruiken files. te gebruiken procedures. instructie voor het gebruik van bovenstaande zaken.

Onderhoudsblokkade. In verband met onderhoudswerkzaamheden kan het noodzakelijk zijn, dat MIMER enige tijd niet gebruikt mag worden. Het al of niet beschikbaar zijn van MIMER wordt geregeld door de aan- of afwezigheid van een file. In COBOL-programma's wordt op het al dan niet aanwezig zijn van deze file getest door middel van een aanroep van "MITDWN" (voor de MlMER-testversie) of "MIPDWN" (voor de MIMER-produktieversie). In Fortranprogramma's wordt de test uitgevoerd door de functie "MITDWN" respectievelijk "MIPDWN". In beide gevallen zal, wanneer MIMER niet beschikbaar is, de programmeur zelf voor het sturen van een boodschap en het beëindigen van het programma moeten zorgen. Op de Sperry 1100 staan beide modules op de file MIMER*DBARUN. Op Vax en PC zullen deze modules door de DBA worden geïmplementeerd zodra ze hier nodig zijn. Autorisatie aspecten. Creëer autorisatie. De gewenste autorisaties dienen met behulp van MIMER/CL en input files gecreëerd te worden, om reproduceerbaar te kunnen zijn. De volgende zaken dienen gedefinieerd te worden: -

program idents. group idents. user idents. accessen. privileges.

di«nsl inf(xmati*v«rw*rking

rijkSWaterStaat

BEDRIJFSNORM NR. 9

mM

hooidtiük

7 blad


25

880201

Backup en herstel aspecten. Maak backup- en herstelprocedures. De backup- en hersteleisen worden verwerkt in procedures: - maak backup-procedures (via MIMER/DBR, CITO-procedure of andere). - gebruik hierin MIMER/DBCHK voordat de backup gemaakt wordt, om te garanderen dat niet van een corrupte databank een backup gemaakt wordt. - maak herstelprocedures. Voorbeelden van deze procedures zijn DBA.

tè verkrijgen

via

de

Operatinq systeem en test aspecten. Beveiliging files. Definieer de vereiste beveiligingsopties per database-file (=databank). De eerste gebruiker van een databank zorgt ervoor, dat MIMER de file exclusief opent en de file blijft exclusief aan MIMER toegewezen tot MIMER gedeactivèerd wordt. Als een file niet door MIMER gebruikt wordt, dient het operating systeem voor een adequate beveiliging te zorgen. Spreiding databanks. Bepaal de noodzaak van spreiding van de databanken over meerdere disk-units (indien beschikbaar) in verband met performance-overweging en crash-gevoeligheid. Real-life performancetest. Voer overleg met de exploitant van het systeem over de noodzaak van het uitvoeren van een real-life performancetest. Deze test heeft als doel inzicht te krijgen in het gedrag van het database-systeem in een multi-user omgeving. Test- en produktieversie. Het is alleen toegestaan om overgedragen systemen in de MIMER produktie-omgeving te draaien. Voor het ontwikkelen van systemen dient met de DBA overleg gepleegd te worden omtrent de te gebruiken ontwikkelingsomgeving. Naast het produktiesysteem dient ook het testsysteem (dat wil zeggen: programma's + testdatabase) aan de exploitant te worden overgedragen.

rijkswaterstaat

di«nst informati«v«rw«rkJng

BEDRIJFSNORM NR. 9

\^M

hooldstuk

8

26


datum ntcuw

tOatumouOi

880201

8. INVOERING (SDM II fase 5) Algemene aspecten. Algemeen. Er dient een toetsing plaats te vinden door de exploitant van het in te voeren systeem. Hierbij wordt voor wat betreft het gebruik van MIMER getoetst op alle in deze norm beschreven standaards en richtlijnen. Organisatorische aspecten. Verzorg cursussen voor gebruikers. De voor de gebruiker noodzakelijke opleiding seerd te worden. Denk hierbij aan: - cursus Inleiding Databases. - MIMER/QL cursus (te zijner tijd SQL).

dient

gereali-

dienst in(ofm«tt«v»rw«fking

rijkswaterstaat

BEDRIJFSNORM NR. 9

mM"

hootoiiuk

9 oiad


27 datum ni«uw

MilumouOI

880201

9. GEBRUIK EN BEHEER (8DM II fase 6) Algemene aspecten. Algemeen. Er dient evaluatie/bewaking plaats te vinden door de exploitant van het in produktie genomen systeem. Hierbij worden, voor wat betreft het gebruik van MIMER, alle in deze norm beschreven aspecten in ogenschouw genomen. Enkele voorbeelden: - Belangrijke zaken, zoals herstelprocedures, dienen periodiek te worden uitgeprobeerd. Dit om er zeker van te zijn dat ze in geval van calamiteiten goed zullen functioneren. - Backup-, herstel- en overige procedures" dienen gestroomlijnd te worden. Database-ontwerp aspecten. Performance-meting en tuning van het database-systeem. Er dient periodiek gekeken te worden of het database-systeem nog wel voldoet aan de gestelde performance-eisen. Deze performance-metingen worden vervolgens geëvalueerd, er wordt gekeken of er een bepaalde trend te onderkennen is en zonodig worden maatregelen genomen ter verbetering van de performance. Eventueel kan door middel van het definiëren van secundaire indices of het aanpassen van het database-ontwerp een performance-verbetering gerealiseerd worden. Er dient echter ten allen tijde in zo'n geval overleg plaats te vinden met de DBA. Een andere mogelijkheid tot performance-verbetering is het aanpassen van parameters, welke invloed hebben óp de werking van MIMER en het operating systeem. Dit is doorgaans een DBA-zaak. Definieer wii zigingsprocedure. Er dient een beschrijving te komen met betrekking tot het wijzigen van de database(-applicatie). Hierin dient de te volgen procedure en de verantwoordelijkheden te worden vastgelegd.

rijkswaterstaat

divnst informati«v*rw*rking

BEDRIJFSNORM NR. s

[SM^


28 diium mauw

Idaiumouoi

880201

Autorisatie aspecten. Definieer autorisatie onderhoud. Er dient gedefinieerd te worden hoe en door wie toevoegingen van, wijzigingen aan en verwijderingen van idents, access en privileges dient te gebeuren. Meestal zal dit door de DBA worden gedaan. De DBA zorgt ook voor bewaking van de doeltreffendheid van de autorisatie.

dtcnst in(ofm«ti«w«rw«fkinQ

rljkswaterstaat

BEDRIJFSNORM NR. 9

NMtdSluk

A Diad

°Mk^


29 datum niauw

Maiumoual

880201

APPENDIX A. GEBRUIKTE TERMEN EN BEGRIPPEN. Attribuut. Basis-eenheid van informatie die een entiteit, beschrijft. Deze kan niet verder zinvol worden onderverdeeld. Een attribuut komt meestal overeen met een kolom van een tabel. Autorisatie. Het beveiligen van gegevens tegen ongeoorloofd gebruik. Conceptueel gegevensmodel. Een gedetailleerde beschrijving van alle gegevens en hun onderlinge samenhang, zoals deze in de gebruikerswereld voorkomen. Constraints. Voorwaarden voor integriteit (zie ook integriteit). Database-systeem. DBMS + database. Data-dictionary. Een catalogus die gegevens bevat over de database, zoals tabelnamen, kolomnamen, views, privileges, domeinen enz. Bij iedere actie door het DBMS wordt aan de dictionary gerefereerd. DBA. Data Base Administrator. DBMS. Data Base Management Systeem. Domein. Verzameling waarden die database mag aannemen.

een

individueel

veld

uit

een

Entiteit. 'lets^ van fundamenteel, wezenlijk belang voor een organisatie. In relationele databases wordt een (conceptuele) entiteit meestal 1 op 1 vertaald in een tabel. Exploitant. Persoon of afdeling, die verantwoordelijk is voor het beheer en onderhoud van in produktie genomen informatiesystemen .

dt«nst infOfm«tt«w»rw«rkino

rijkSWatefStaat

BEDRIJFSNORM NR. 9 biid

Muïk^

30 Ontwikkelen en beheren van MIMER-databases en -applicaties

Oalum niAuw

WKumoual

880201

Integriteit. Integriteit is het correct, volledig en samenhangend zijn van de gegevens in een database. Er zijn verschillende soorten integriteit. De drie belangrijkste zijn: 1 - Sleutelintegriteit. Alle velden in een tabel die deel uitmaken van de primaire sleutel, moeten een waarde hebben en mogen dus niet leeg zijn. Een primaire sleutelwaarde mag slechts eenmaal voorkomen in een tabel. MIMER zorgt automatisch voor het in stand houden van de sleutelintegriteit. 2 - Referentiële integriteit. Als b.v. in een database een tabel met landen is opgeslagen en een tabel met provincies, dan mag men niet een bepaald land verwijderen uit de landen-tabel terwijl er van dat land nog provincies bestaan in de provincie-tabel. Deze vorm van integriteit dient door de MIMER-applicatie zelf in stand te worden gehouden. 3 - Database-afhankelijke integriteit. Hiermee wordt de compleetheid van de database bedoeld, zoals gedefinieerd in het ontwerp; bijvoorbeeld saldo's, welke niet kleiner mogen zijn dan 0. Logging. Alle transacties die op de database worden uitgevoerd worden vastgelegd in een daarvoor.bestemd bestand. Mocht op welke wijze dan ook de database defect raken, dan kan met behulp van dit loggingsbestand en een backup de database weer hersteld worden. MIMER/DB. De Database Handler, waarmee vanuit een derde-generatie programmeertaal met een MIMER-database gemanipuleerd kan worden. MIMER/CL. De Command Language, waarmee d'in.v. commando-files met de data-dictionary gemanipuleerd kan worden.. MIMER/FM. De Forms Manager; het "nieuwe", portable schermpakket van MIMER. MIMER/PG. De Program Generator, waarmee vanuit een soort vierdegeneratietaai, complete applicaties gegenereerd kunnen worden.

rijkswaterstaat

dl«nst inforinati«v*rw*rkiog

BEDRIJFSNORM NR. 9 blad

[dMy?


31 datum ni«u«>

Maiumouoi

880201

MIMER/QL. De Query Language, waarmee interactief met de database gemanipuleerd kan worden. MIMER/SH. De Screen MIMER.

Handler; het

"asynchrone"

schermpakket

van

Occurrence. Een exemplaar, voorkomen. Bijvoorbeeld Zuid-Holland is een occurrence van de entiteit provincie. Primaire sleutel. De kleinste groep attributen van een entiteit waarmee deze geïdentificeerd kan worden, tedere tabel moet een primaire sleutel hebben. SQL. Structured Query Language. Een op de verzamelingenleer gebaseerde vraagtaal voor gegevénsmanipulatie en -definitie, die geldt als de standaard. Tabel. Een tabel (velden).

bestaat

uit

rijen

(records)

en

kolommen

Transactie. Zie transactiemechanisme. Transactiemechanisme. Door gebruik te maken van het transactiemechanisme worden alle updates op de database gegroepeerd tot transacties. Een transactie kan hierbij gezien worden als een zo klein mogelijke hoeveelheid wijzigingen op de database, waarbij na afloop de database weer integer is (integriteitseenheid). Een transactie wordt altijd ofwel in zijn geheel uitgevoerd, ofwel in zijn geheel niet uitgevoerd. Dit heeft tot gevolg dat bij een systeemcrash tijdens het uitvoeren van een transactie, de database automatisch wordt hersteld tot op het moment voordat de transactie begon. Het is ook mogelijk om zelf in het applicatieprogramma een reeds begonnen transactie af te breken en daardoor teniet te doen. Dit kan nodig zijn, indien er b.v. een bepaalde foutsituatie zich voordoet. De commando's om binnen MIMER van het transactiemechanisme gebruik te maken zijn:

^

PG TRANSACTION COMMIT

Level2 BEGTR2 ENDTR2

Leve14 START4 C0MIT4

ABORT

ENDTR2

AB0RT4

—

Betekenis Start de transactie. Beëindig de transactie en maak de updates definitief. Breek de transactie af en maak de updates ongedaan. /

rijkswaterstaat

di*n«t informatt*v«rw*rking

BEDRiJFSNORM NR. 9

nruïk^


32 daiKT> ni«uw

idaiumouoi

880201

Hieronder volgt een voorbeeld van het gebruik van transacties om de integriteit van de database te waarborgen. Het gaat hier om het overboeken van een bedrag van de ene girorekening naar de andere: Tabel : GIRO Kolommen: NUMMER * NUM(7) TEGOED NUM(7) PROCEDURE OVERBOEKING (VAN, NAAR, BEDRAG) +—integriteitspunt 1 TRANSACTION; UPDATE GIRO (TEGOED = TEGOED-BEDRAG) WHERE GIRO.NUMMER EQ VAN; integriteitsniet-integere toestand eenheid UPDATE GIRO (TEGOED = TEGOED+BEDRAG) WHERE GIRO.NUMMER EQ NAAR; COMMIT; +—integriteitspunt 2 Vanaf het moment dat de VAN-girorekening met het bedrag verminderd is, totdat dit bedrag bijgeschreven is op de NAAR-rekening, is de database niet integer. Als in die situatie de computer down zou gaan, dan zou na het weer actief worden kunnen blijken dat het totaal van de tegoeden een bedrag BEDRAG tekort komt. Het transactiemechanisme zorgt er echter voor dat teruggegaan wordt naar het vorige integriteitspunt (in dit geval integriteitspunt 1) zodat de hier genoemde situatie voorkomen wordt. View. Een view is de wijze waarop een individuele gebruiker naar de gegevens kijkt. Sommige gebruikers hebben vanuit hun functie slechts met enkele kolommen of rijen van een tabel te, maken. Anderen zien wat in de database in twee tabellen is ondergebracht als één tabel (join). In de data-dictionary kunnen deze views worden opgeslagen. Voor de gebruiker ziet zo'n view er gewoon uit als een tabel. Een view over meer dan één tabel is in release 4.2 van MIMER nog niet mogelijk.

rijkswaterstaat

di«nst inform«ti«v*rw*rking

~

r—

nootastuti

BEDRIJFSNORM NR. 9

biaa

^MM


33 daiKK n>«u»>

Ualufnouoi

880201

APPENDIX B. LITERATUUR OVERZICHT. De volgende literatuur is geraadpleegd: Database, een inleiding door C.J.Date. Een algemene introductie in de wereld van de database. Dit boek wordt ook gebruikt in de cursus "Inleiding Databases". Technical Facts About the MIMER System. De verkoopfolder van MIMER. A Primer for the MIMER Svstero. Een beschrijving van het MIMER-systeem en alle MIMER-modules. MIMER Svstem Management Handboek /release 4.1). Naslagwerk voor systeembeheer met een beschrijving van de beschikbare algemene Utilities en hoe deze te gebruiken. MIMER/DB Database Manager and Program Interface Version 4.2. Algemeen naslagwerk voor MIMER database handler met een beschrijving van de database, data-dictionary, beschikbare database-utilities, level-2 programmering en level-4 programmering. MIMER/PG Program Generator Version 4.2. Naslagwerk voor het gebruik van de MIMER Program Generator. MIMER/FM Forms Manager Version 4.2. Naslagwerk voor het gebruik van de MIMER Forms Manager. MIMER/SH Screen Handler Version 4.2. Naslagwerk voor het gebruik van de MIMER Screen Handler. MIMER/OL Oüery and Command Language Version 4.2. Naslagwerk voor het gebruik van de MIMER Query Language. MIMER Installation Guide for VAX latest version. Handleiding voor het installeren van MIMER op de Vax. MIMER Users Guide for VAX latest version. Handleiding voor het gebruik van MIMER op de Vax. MIMER Installation Guide for SPERRY^llOO latest version. Handleiding voor het installeren van MIMER op de Sperry 1100. MIMER Users Guide for SPERRY-1100 latest version. Handleiding voor het gebruik van MIMER op de Sperry 1100. Transaction Handling in een MIMER-omgeving door SEE. Een beschrijving van het MIMER-transactieconcept, de database-opties en hoe hiervan gebruik te maken. Svstem Development Methodology door W.S. Turner e.a. Het SDM II handboek van Pandata.

rijkswaterstaat BEDRIJFSNORM NR.9 ontwikkelen en beheren van mimer-databases en-applicaties

Recommend Documents