Onderzoek naar de ontwerpmethodiek ten behoeve van CAAD programmapakketten. Deel 8: ADIS : trefwoordenregister (bijlage) : IOP - GOM - CAD - project GOM 1/2; fase 1984-1985

Onderzoek naar de ontwerpmethodiek ten behoeve van

CAAD programmapakketten. Deel 8: ADIS :

trefwoordenregister (bijlage) : IOP - GOM - CAD - project

GOM 1/2; fase 1984-1985

Citation for published version (APA):

Beheshti, M. R., Monroy, M. R., & Botma, E. F. (1986). Onderzoek naar de ontwerpmethodiek ten behoeve van CAAD programmapakketten. Deel 8: ADIS : trefwoordenregister (bijlage) : IOP - GOM - CAD - project GOM 1/2; fase 1984-1985. Technische Hogeschool Eindhoven.

Document status and date: Gepubliceerd: 01/01/1986

Document Version:

Uitgevers PDF, ook bekend als Version of Record

Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website.

• The final author version and the galley proof are versions of the publication after peer review.

• The final published version features the final layout of the paper including the volume, issue and page numbers.

Link to publication

General rights

Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

• You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement:

www.tue.nl/taverne Take down policy

If you believe that this document breaches copyright please contact us at: openaccess@tue.nl

.

?

G

Afdeling Bouwkunde

·

.

6

Vakgroep ~

D

Apyhitectuur en '/) ur6anistiek -M045232

Technische

Hogeschool

;:..__~-~~

...

-iDdhoven

~

~=-=---..:

Gom dee1nemers in 1985 :

DEEL 8

ADIS:

TREFWOORDENREGISTER

(BIJLAGE)

IOP - GOM - CAD - Project GOM 1/2: FASE 1984 -1_985 Auteurs: M.R. Beheshti M.R. Monroy E.F. Botrna Januari 1986

Prof.dr.ir. M.F.Th. Bax, Dr.ir. M.R. Beheshti, Dr.ir.J.Th. Boekholt, F.v.d. Bosch, Ir. E. Botma, p. Coppelmans, Ir. P.J.M. Dinjens,

Ing. J.P.M. van Geest, M.Janneman, M. Ir.

w.s.

Schaefer,Ir A.P. Thijssen, Dr. ir. H.M.G. Truro.

Gast :Ir. M. Monrooy.

van Kempen, arch. H.B.O.,

INHOUOSOPGAVE 1 1.1 1.2 1. 2 .1 1.2.1.1 1.2.1.2 1 • 2. 2 1.2.2.1 1.2.2.2 1 • 2•. 2 • 3 2 2.1 2.2 2. 2 .1 2. 2. 2 2.2.2.1 2.2.2.2

ALGEMENE KENMERKEN VAN ADIS

De begrijppen data-bank, data-base en programmabank

De inhoud van ADIS Data De projectdata-base De algemene data-base De prgrammatuur Data-baseprogrammatuur Gebruiker-gerichte programmatuur Programmatuur gezien vanuit de fase-stappen

DE LEVENSCYCLUS VAN EEN SYSTEEM De fasen van de 1evenscyc1us van een systeem

De data-base 1evenscyc1us Systeemana1yse

Het logische antwerp

In1eiding tot de data-base structuur

Drie benaderingen van een 1ogische data-base visua1isering

2.2.2.2.1 Boomstructuren 2.2.2.2.2 Netwerkbenadering

2.2.2.3 2.2.2.4 2. 2. 3 2.2.3.1 2 .2 .4 2.3 2. 3 .l 2. 3. 2 2. 3. 3 2.3.4 2. 3. 5 2.3.6 2.3.6.1 2.3.6.2

Het nut van een logische structuur De stappen van het logische ontwerp Het structurele ontwerp

De stappen van het structurele on twerp

Het fysieke ontwerp Verspreide data-bases

Mogelijke redenen voor het

verspreiden van data-bases

Verschillende typen van systemen De overeenkomsten van datastruc-turen

Waar zijn de data opgeslagen?

Het oversturen van gegevensbe-standen

Verspreide data-bases en het design coalition team

De verspreide model-data-base De data-bank en programma-bank

1. ALGEMENE KENMERKEN VAN ADIS

In dit hoofdstuk zullen we alle algemene ken-merken van de ontwikkeling van ADIS kort be-spreken. Deze zaken behelzen de introductie van de begrippen 'algemene data-base' (data-bank en programma-(data-bank) en 'projectgebo~den

data-base'. Tevens bespreken we het begrip 'besluitvormingsondersteunend systeem'. Dit hoofdstuk behandelt in hoofdzaak de technische aspecten van een dergelijke ontwikkeling.

1.1 DE BEGRIPPEN DATA-BANK, DATA-BASE EN PROGRAMMABANK

Het Architectural Design Information System (ADIS) wordt ingevoerd als een hulpmiddel bij de besluitvorming in de architectenpraktijk. Het systeem bevat drie onderdelen, welke op de gebruiker gericht zijn. De besluitvormings- en automatiseringsaspecten van die drie onder-delen worden hier in het kort besproken.

Gedurende het bouwkundige ontwerpproces wordt een grote hoeveelheid gegevens verzameld en verwerkt via methoden en technieken welke de architect voorafgaand aan of in de loop van het proces verwerft.

Wat in feite gebeurt is dat de architect onbe-werkte data verzamelt en deze data selecteert -het analyseproces (zie deel 2). Deze selectie verandert de data in in forma tie, waarbi j in-forma tie is gedefini~erd als: "verzamelingen van betekenisvolle en relevante gegevens welke gebeurtenissen of entiteiten beschrijven" (Ver_zello, 1982, p.56). Naar de verzameling onbewerkte data wordt gerefereerd als data-bank. In computertermen wordt deze data-bank de algemene data-base genoemd om fysieke asso-ciaties te vermijden.

Na het verzamelen van de gegevens voegt de architect er waarde aan toe door ze in een bepaalde context te plaatsen. Dit is een

es-senti~le handeling van het ontwerpen. In het algemeen doet hij dit op een grafische manier, omdat tekeningen vanuit het oogpunt van commu-nicatie de meest veelzeggende informatiedra-gers zijn. Omdat het echter niet mogelijk is alle aspecten van een ontwerp in tekeningen te vervatten gaan de tekeningen vergezeld van onder meer geschreven teksten, zeals rapporten en bestek. Deze teksten beschrijven de kenmer-ken van de geometrische elementen die op hun beurt de ruimtelijke configuratie van het gebouw beschrijven. De bewust geselecteerde en/of ontworpen geometrische elementen en hun kenrnerken worden opges lagen in de projectdata-base.

Vele methoden, strategi~en en technieken zijn ontwikkeld om de architect -in de vorm van een programma- te ondersteunen gedurende de stap-pen binnen elke fase, bijvoorbeeld de SAR-ontwerpmethode, de Finite Elements Calculation methode en dynamische energieberekeningsmetho-den. Indien de architect een van deze hulp-middelen wenst te gebruiken kan hij er ge-schreven informatie over betrekken of zich tot een expert wenden. De programma-bank, waarin deze hu lpmidde len zi j n opges 1 agen, zou de architect in staat moeten stellen de meest geschikte hulpmiddelen uit te zoeken. Deze hulpmiddelen, ook: gebruikersgerichte soft-ware, dienen tenminste de volgende drie

eigen-schappen te hebben:

(a) hun proces dient in het kort uiteen

gezet te worden

(b) de vereiste input en het formaat ervan (grafieken, tabellen e.d.) dienen ver-meld te worden

(c) de output en het formaat ervan dienen vermeld te worden.

1.2 DE INHOUD VAN ADIS

De inhoud van ADIS kan verdee1d worden in twee categorie~n:

(a) data

(b) programmatuur.

De data-verzameling wordt de (ge!ntegreerde) archi tectonische ontwerpdata-.base genoemd.. Op deze data kunnen bewerkingen worden

uitge-voerd. De programmatuur stelt de gebruiker(s) in staat om bepaalde bewerkingen op de data uit te voeren. Dit kan geschieden door direct ingrijpen van de gebruiker, bijvoorbeeld door

'queries' of indirect door het opstarten v~n

User (Design Coalition Teap1) ~-..._ Architects Engineers Surveyors Organisation Economic Building Management Etc. retrieval updating modelling manipulation management software -...:::::;;;. _ _ _.file structure ~-- key-words

•E~--• on/ off-line

HW

frame

products ·~ . . ~---4availability

cost

design coalition team

~~!:::£!~~~====:::::surface

data volume data

~~---Project Data Base standard ELDB el9ment library data base bldg component LDB

expert knowl~dge bldg material LDB application software specification DBs

~~----design research/methods standard detail D'Bs

~~---ehistory/theorY. of architecture environmental/social psychology legislations,norms, etc.

decision making the~ries/m~els/techni~ues statistics theories/models/data

publications/project reviews etc.

l . 2 . l Data

Twee soorten data dienen tot de beschikking van de gebruiker te staan:

(a) projectgegevens

(b) algemene gegevens.

Onder projectgegevens worden die data verstaan welke het te ontwerpen gebouw aan de architect beschrijven gedurende het bouw- en ontwerp-proces. Algemene gegevens zijn die gegevens welke de architect tijdens de ontwikkeling van het gebouw hoe dan ook nodig kan hebben. Deze hebben in principe geen samenhang met het

specifieke karakter van het project.

Vanwege hun verschillende kenmerken en de verschillende manieren waarop ze gebruikt kunnen worden dienen deze data respectievelijk in de projectbase en de algemene data-base opgeslagen te worden.

1.2.1.1 De projectdata-base

De moge1ijke inhoud van de projectdata-base is

weergegeven in figuur 2.

1. Planning and programming phase --Functional description

--Space requirements

--Site context description --Site evaluation criteria --Economic feasibility model --Special user requirements

--Codes/regulations/legal constraints --Performance requirements

--Management plan

--Marketing/selling data -Budget limits

--Management development approach •

.

-2. Design and engineering phase --Space allocation --Space organization --Constructed elements --Quantities/costs --Equipment --Population distribution

--Expected performance of the design configuration (such as cost and energy use)

--options (left to choice of builder) --operations and maintenance

--Training plan for operations and maintenance -Cost of design production

--Plans and specifications --Test specifications --Requirements compliance --Cost estimates

--Structural load calculations --Energy analysis usage projections 3. Specifications and procurement phase

--Structure and procedures of procurement process

--Scheduling ·

-Quantities --Estimated costs

--Sources of supply and payment --Furnished items

-Contract documents --Shipping

. . . /Figuur 2 (vervolg)

4. Construction and outfit phase -"As-built" information -Shop drawings

--Design refinements (graphic, specifications) --Materials bought

--Equipment bought -Actual costs --Change orders

--construction schedule (daily log of events, people, environment) -Productivity

-Test re.sults

--Status and forecasts --construction rates

S.

Building maintenance and.operation phase -Expenses and financing

--Renewal/replacement

--Servicing/preventive maintenance schedules --Repairs (service requests and demands)

--Redecoration and remodeling ·

--Training costs -"As-built" drawings

-E<tuipment/material listings and specifications --warranty/guarantee information

--Punch list resolution --operating manuals --Energy usage

I

6. ·user operation phase --Space assignments --Space utilization

--Communications assignments

-Furnishings and equipment inventory/assignment -Functions performed

-Productivity

--Remodeling and renovation costs --Income/expense model

--occupancy costs -Layout detail --Growth projections

--Space/function requirements --Drawings and specifications --Special requirements

Figuur 2: Voorbee lden van data ten behoeve van een projectgebonden data-base (rapport van het '1984 Workshop on Advanced Technology for Building Design and Engineering)

De inhoud van deze data-base neemt enorm toe naarmate de ontwikke1ingscyc1us van het gebouw voortschrijdt. Deze toename is weergegeven in figuur 3.

Figuur 3: De informatie-toename tijdens het bouwproces (Informatieverwerking tijdens het bouwproces, 1984)

Uit de aard van het architektenvak moge duide-lijk worden dat het centrale gedeelte van deze data-base wordt gevormd door de geometrische beschrijving van het gebouw inclusief de

at-tributen•

De gegevens in deze data-base dienen te worden georganiseerd te worden op een manier welke volgt uit het ARGOM-model. Uit deze data base kunnen gegevens worden opgeroepen door de leden van het design coalition team. ·oeze data zullen hen in staat stellen de handelingen, aan hun discipline eigen, uit te voeren. De projectdata-base dient centraal te worden beheerd en bestuurd teneinde de samenhang, juistheid en beveiliging van de data te garan-deren. Dit k~p gedaan worden door de persoon die het proces c~rdineert.

1.2.1.2 De algemene data-base

Onder algemene gegevens worden die data ver-staan welke de architect tijdens het bouw-praces nodig kan hebben, zij het direct ter verwerking in het proces of als acntergrondin-formatie. Vaak zijn deze data in de ene of

andere vorm reeds beschikbaar, bijvoorbeeld

de Nederlandse Bouw Documentatie, kadaster-kaarten, klimaatgegevens, historische gegevens of gegevens over soortgelijke projecten.

Deze gegevens kunnen nationaal, provinciaal of lokaal geldig en/of georganiseerd zijn. Zowel de geografische aspecten hiervan als de betrokken disciplines kunnen uitgangspunten vormen voor de logische en fysieke organisatie van de algemene data-base. In wezen dienen deze data onafhankelijk van de fasen te zijn, ook al zullen bepaalde data gedurende bepaalde fasen van het bouwproces meer gebruikt worden dan gedurende andere. Een verder uitgangspunt voor het logische antwerp van de data-base kan gebaseerd worden op de beschrijving van het ARGOM-model (zie deel 2).

1.2.2 De programmatuur

De handelingen die op gegevens worden uitge-voerd worden gespecifieerd in een programma, dat bestaat uit een reeks van instructies geschreven in een computertaa 1, bi j voorbee ld PASCAL, FORTRAN of COBOL. De verschillende typen programma's welke in een computersysteem gebruikt worden, worden met de collectieve term 'programmatuur' aangeduid (Mitchell, 19 7 7 1 pp • 6-7) •

Twee typen programmatuur kunnen in ADIS worden herkend:

(a) niet-gebruikergerichte programmatuur of

data-base programmatuur (de term programmatuur is synoniem aan de term software)

(b) gebruiker-gerichte programmatuur.

1.2.2.1 Data-baseprogrammatuur

Onder niet-gebruikergerichte programmatuur wordt die software verstaan welke de gebrui-ker-gerichte programmatuur koppelt aan de data-base zonder dat de gebruiker normaal gesproken van het bestaan ervan op de hoogte is, zeals data-base management software (DBMS). Daar het geen relatie heeft met de gebruiker en de data-base in dit rapport wordt beschreven vanuit het oogpunt van de gebrui-ker, valt een diepgaande uitleg buiten het bereik van dit rapport. Om echter een indruk te geven van het gebruik en doel van dit soort software kunnen we een DBMS zien als "een interface tussen programma's en data, met de

verantwoordelijkheid voor het .defini~eren,

weergeven, opslaan, organiseren en beschermen van data, evenals het doorkoppelen van ge-bruikers met de data-base" (Loomis, 1983, p.454), of a 1 s "de verzame 1 ing van programma-tuur vereist voor het gebruik van de data-base" (Martin, 1976, p. 329).

1.2.2.2 Gebruiker-gerichte programmatuur

Twee soorten gebruiker-gerichte programmatuur kunnen worden onderscheiden aan de hand van Loomis' definitie van een DBMS:

(a) app1icatieprogrammatuur

(b) interrogatie-computerta1en.

Applicatieprogrammatuur kan worden gedefi-nH!erd a1s: "programma's geschreven om bepaa1-de problemen inzake data-verwerking binnen een organisatie op te los sen" [ Verze 11o, 1982]. Voorbeelden van dit soort prob1emen gedurende het bouwproces kunnen energie- en

sterktebere-keningen zijn. Door middel van vooraf bepaald

proces wordt een prob1eem opge1ost en informa-tie verkregen. Dit zijn standaardapp1icainforma-ties. De programmatuur om de data, verkregen uit de data-base -in bovenstaande gevalien de projectdata-base-, te verwerken wordt ontwik-keld op deze1fde manier als het gehele sys-teem. Het dient a1le fasen van de software-ontwikke1ings-cyclus te doorlopen. Het verzoek om informatie wordt vertaa1d door de program-meur in een app1icatieprogramma, dat op zijn beurt de data bewerkt om de informatie te 1everen waar de eindgebruiker (de architect) om gevraagd had.

De ontwikkeling van de app1icatieprogrammatuur neemt nogal wat tijd in bes1ag en dit is onacceptabe1 voor sommige bes1uitvormingspro-cessen. Dit tijdsaspect van het data-basege-bruik is aanleiding voor de ontwikke1ing van

interrogatietalen, welke de gebruiker in staat ste1len de data-base te gebruiken zonder in-schakeling van applicatieprogrammeurs.

Zo'n taal kan gebruikt worden· voor het opste1-1en van rapporten, het doen van onderzoeken, het zoeken en manipuleren van data, etc. De data-base-interrogatieta1en stel1en de

gebrui-ker, in dit geval de architect, in staat

on-voorziene vragen te formuleren zonder enige

dui-delijk zijn dat deze onvoorziene ondervragin-gen van de data-base de organisatie en de structuur van de data-base onder zware druk zetten. Omdat zowel de applicatieprogrammatuur

als de ondervragingsprogrammatuur -in het

optimale geval althans- hetzelfde schema ge-bruiken, dient er veel aandacht te worden besteed aan het antwerp van dit schema.

1.2.2.3 Programmatuur gezien vanuit de

fa-se-stappen

De gebruiker-gerichte software van ADIS heeft tot doel de besluitvorming gedurende elke stap van elke fase van het bouwproces te ondersteu-nen. Een uitgebreide uitleg van de diverse stap-begrippen, zeals hierna opgesomd, en van hun logische volgorde kan in deel 2, sectie 1.3.4, worden gevonden. (a) probleemstelling (b) analyse (c) synthese (d) evaluatie (e) beslissing

2 • DE LEVENSCYCLUS VAN EEN SYSTEEM

Als er eenmaal tot een Electronisch Data Pro-cessing project (EDP) is besloten, begint de levenscyclus van een systeem. Elk project doorloopt een reeks van fasen bijna analoog aan de wijze waarop een bouwkundig project wordt gestart, ontworpen, gedetailleerd, ge-bouwd, en tenslotte opgeleverd.

BUILDING CONSTRUCTION

l)ra·~:!.all _{a.rc!li teet • a}

idsn1:iti- _slcatc!les C ;~. ti OD. !UI:i

--

-

and initial _sstimates 3\U'Vay SYSTEMS DEVELOPMENT :-eq:~re­ a:ant3 specific&-- tion and initial survey - f'eaei bili ty -study :istailed working

study or

-

final drawings construe-

~a-arclrl.tect's

-

&.'1d

-

_{tion out}

space

plane quantity nHdS _surv.,y

syst8!11e - logicu

analysis design - design ph,ysic&l - [ ; ] r o l f - -ramming

imple~~sn-

tation

-._

__

__,

A

A

A

A

l

111111-111111111111111111 .. 1

----I .. I ..

IIIIIIIIIIIIII . . . HIIIIIIIIIHeiiiiiiiiiiM ~ ~ US9"

Figuur 4: vergelijking van de fases van een bouwproject met de levenscyclus van een systeem (naar Brookes e.a.,

Gedurende elke fase zijn er een aantal taken die uitgevoerd dienen te worden voordat het mogelijk is met de volgende fase verder te gaan. Het begrip 'levenscyclus' houdt nauw verband met de systeemontwerp- en

-ontwikke-lingsmethodologi~en zoals de Gestructureerde

Analyse (DeMarco, 1979).

De meeste systeemontwerp-methodologen staan een top-down aanpak voor die kan worden uitge-voerd op een conservatieve of een radicale wijze. Met een top-down aanpak wordt het

opde-len van grate, ingewikkelde problemen in klei-nere, handzamer problemen bedoeld. Een conser-vatieve aanpak is een opeenvolgingsaanpak van het systeemontwerp, waarmee wordt bedoeld dat een bepaalde activite~t in z'n geheel dient te zijn afgerond voordat er met een volgende begonnen kan worden. Een gestructureerde EDP-projectlevenscyclus, zoals Yourdon die voor-staat, schept ruimte voor een radicale aanpak waarmee bedoeld wordt dat alle taken tegelij-kertijd kunnen worden uitgevoerd [Yourdon, 1982]. Om de systeemontwerper bij te staan zijn er een aantal gestructureerde technieken ontwikkeld [Yourdon, 1979 & 1976]. Hoe meer erVaring een systeemontwerper krijgt des te radikaler zal zijn aanpak zijn.

Naast de voordelen voor de ontwerpers vormt de levenscyclus de basis voor de besturing van het project, daar de EDP project-managers er naar neigen de resultaten van het ontwerpteam te bekijken bij de afronding van elke fase, omdat daar de natuurlijke controlepunten te vinden zijn.

"Er bestaan vele verschillende methoden om de ontwikkelingscyclus weer te geven, maar ze bevatten allen in wezen dezelfde componenten waarbij de grootste verschillen liggen in de begrenzingen van de fasen zoals de auteurs die zien" [Brookes, 1982, p.l3].

2.1 DE FASEN VAN DE LEVENSCYCLUS VAN EEN SYSTEEM

Twee opvattingen van de levenscyclus van een systeem zull en hier worden besproken. De ene wordt naar voren gebracht door Brookes e.a., de andere door Yourdon. Het belangrijkste ver-schil is dat Yourdon het gehele systeem van een organisatie tijdens de eerste fasen van de levenscyclus beschouwt en niet alleen het

ge~utomatiseerde gedeel te.

Vanwege de differentiatie tussen het logische en het fysieke antwerp zal Brookes' opvatting van de fasering onze leidraad zijn bij de bespreking van de uit te voeren taken en acti-viteiten.

Fase 1: referentiekader en eerste programma van eisen

"Het beste beginpunt voor elk project is een opsomming van wensen en verwachtingen van de zijde van de gebruikers van het systeem. Soms wordt deze opgesteld na overleg met het mana-gement van informatiessytemen over de toepas-baarheid van de computertechnologie op het betrokken probleemgebied, en over de orde van. grootte van de kosten. De opsomming dient te worden omgezet in een programma van eisen alvorens er een aanvang kan worden gemaakt met het meer gedetailleerde werk.

De hoeveelheid werk die in het opstellen van een programma van eisen dient te worden

gesto-ken varie~rt sterk. Het hangt sterk af van

factoren als de complexiteit van het doel-gebied, de kennis van de gebruiker van zijn werkomgeving, het risico en de kosten van een mislukking, de technische kennis van de

compu-terspecialist en de hoeveelheden te verwer-ken gegevens. Indien er enige onzekerheid bestaat kunnen speciale aanpakken nodig zijn om het werkgebied tot hanteerbare properties terug te brengen. Soms is een proefstudie of

een andere vorm van simulatie of proefneming nodig" [Brookes e.a., 1982].

Fase 2: haalbaarheidsstudie

"Een eerste analyse van het probleemgebied dient in voldoende detail te worden u{tgevoerd om de keuzemogelijkheden te bepalen die be-schikbaar zijn om aan de eisen te voldoen zeals die in de opdracht vermeld staan. Deze fase is kritiek omdat hij de totale architec-tuur van het nieuwe systeem bepaalt, en de !eiders van het project dienen derhalve het scala van keuzemogelijkheden en hun mogelijke gevolgen zorgvuldig te bezien. Als het ontwerp eenmaal echt onderweg is, wordt het veel

moei-lijker om nog van richting te veranderen" [Brookes e.a., 1982].

Yourdon combineert de activiteiten, die door Brookes worden beschreven onder Fase 1 en 2 in sen fase, te weten het onderzoek. "Ret

belang-rijkste doel van de onderzoeksactiviteit is het identificeren van bestaande tekortkomingen in de werkomgeving van de gebruiker7 om nieuwe doelen vast te leggen7 om te bepalen of het mogelijk is om de zaak te automatiseren en, zq

j a, om acceptabe 1 e draa iboeken voor te ste 1-len" [Yourdon, 1982].

Yourdon definie~rt de activiteiten op een hoger niveau dan Brookes. Er zijn geen gestructureerde technieken gegeven voor deze eerste fasen.

Fase 3: systeemanalyse

"Deze stap behelst een analyse van het bestaande systeem in detail, waarbij in het bijzonder aandacht dient te worden besteed aan de fysieke stroom van gegevens en informatie door het systeeem en waarbij de nadruk moet worden gelegd op knelpunten of andere beper-kingen ten aanzien van de verbetering in de

prestatie" [Brookes e.a., 1982].

Yourdon is een groat voorstander van een Ge-structureerde Analyse zeals die ontwikkeld is door DeMarco "om de huidige gebruikerswerkom-geving te omschrijven met gebruikmaking van datastroom-diagrammen en andere hulpmiddelen. Via de toepassing van het fysieke model wordt de nieuwe gebruikersomgeving gemodelleerd in

logische termen" [Yourdon, 1982].

Het resultaat wordt een Gestructureerde Speci-ficatie genoemd. Deze houdt een logische be-schrijving van de data-base in evenals de fysieke bep,erkingen van deze data-base.

Yourdon begint gedurende de analyse-stap met de logisch-ontwerp activiteiten zeals die in fase 4 door Brooks worden beschreven. Yourdon specificeert derhalve geen afzonderlijke fase voor het logisch antwerp.

Fase 4: logisch antwerp van het nieuwe systeern

"Deze fase bestaat uit het opstellen van een gebruikerspecificatie van de data- en inforrna-tiestroom zowel binnen het systeem alsop de grens tussen de gebruiker en de geautomati-seerde omgeving. Tijdens deze fase is het belangrijker te bepalen wat het

computer-systeern dient te doen dan hoe de oplossing op de computer dient te worden ge!rnplementeerd" [Brookes e.a., 1982].

Volgens Yourdon is de derde activiteit 'ant-werp'. Deze "gaat in op het vastleggen van de

juiste hi~rarchie van de modules en interfaces tussen die rnodulen om de gestructureerde spe-cificatie te irnplementeren" [Yourdon, 1982].

Fase 5: fysiek antwerp van het nieuwe systeern

"Tijdens deze fase tast de systeemontwerper de mogelijkheden voor het implementeren van het

logische antwerp op het computer systeem af door het ontwerpen van bestanden en de details van de programma-modulen" [Brookes e.a., 1982].

Het tweede gedeelte van Yourdon's derde acti-viteit "bevat een stap die bekend staat als packaging waarbij .het antwerp wordt bijgesteld of veranderd om tegemoet te komen aan de be-perkingen van de hardware waarop het systeem wordt gefmplementeerd" [Yourdon, 1982].

Terwijl het tijdens het eerste stadium van Yourdon's ontwerpaktiviteit gaat om het meer logische gedeelte van het antwerp gaat het tijdens het tweede stadium om het fysieke antwerp w.o. het fysieke antwerp van de data-base.

Fase 6: programmeren

"Het programmeren behelst het ontwerpen en coderen van de programma's die er voor zorgen dat de computer het pad volgt dat in het fysieke antwerp is uitgezet. Deze fase behelst ook het testen van de programma's om er zeker van te zijn dat ze binnen de specificaties werken" [Brookes e.a., 1982].

De vierde activiteit van Yourdon behelst "zo-wel het coderen als het integreren van modules

in een in toenemende mate completer skelet van het uiteindelijke systeem" [Yourdon, 1982].

Bij deze aktiviteit horen twee gestructureerde technieken. De eerste is gestructureerd pro-grammmeren en is gericht op op het terug-brengen van het aantal constructies in het programma. De tweede wordt besproken bij de volgende fase.

Fase 7: implementatie

"Tijdens deze fase wordt het gehele systeem

alsmede zijn implementatie in de

inwerk-periode gedurende welke zowel de oude proce-dures als het nieuwe systeem gebruikt worden om uit te vinden of de juiste resultaten wor-den verkregen uit de nieuwe procedures" [Brookes e.a., 1982].

De tweede gestructureerde techniek van Your-den's vierde activiteit is de top-down imple-mentatie, een aanpak die het mogelijk maakt om de modules op een hoger niveau van het systeem te implementeren voordat die van een lager niveau worden gefmplementeerd.

Brookes' fasen 6 en 7 samen vormen Yourdon's vierde activiteit (of fase) die Implementatie wordt genoemd. Volgens Brookes wordt de imple-mentatie gedurende deze fase getest, maar de daadwerkelijke implementatie wordt niet

be-sproken.

De testactiviteiten zoals die worden voorge-steld door Yourdon kunnen worden onderverdeeld in twee gedeelten: als eerste het genereren

van de accepta tietests ( acti vi te i t 5) en ten tweede de kwaliteitsverzekering ofwel de

slot-test (activiteit 6).

Yourdon's zevende fase, procedurebeschrijving, vereist "de ontwikkeling van. een formele be-schrijving van die parameters van het nieuwe systeem die door mens en worden ui tgevoerd en een beschrijving hoe de gebruikers

daadwerke-lijk met het ge~utomatiseerde gedeelte van het nieuwe systeem omgaan" [Yourdon, 1982]. Het resultaat van deze fase is een gebruikershand-leiding.

Yourdon's achtste activiteit houdt zich bezig met de conversie van de data-base. "In het algemeen vereist deze fase als input de be-staande data-base van de gebruiker en de ont-werpspecificatie die het resultaat is van activiteit 3" [Yourdon, 1982]. Zie ook Fase 5. Yourdon's negende en laatste activiteit. is de

Installatie. Het gaat hierbij om een (geleide-lijke) overgang naar het nieuwe systeem (zie Brookes hierboven) en gebruikersopleidingen.

Fase 8: post- impl ementatieve contro 1 e

"Een beoorde1ing van het funktioneren van het systeem nadat het zo'n zes maanden in bedrijf is geweest, is gewenst. Tijdens deze beschou-wing wordt bepaald of het systeem voldoet aan de eisen die gesteld werdenen en of de

gepro-jecteerde voordelen ook daadwerkelijk tot stand gekomen zijn" [Brookes e.a., 1982].

Yourdon geeft geen specifieke activiteiten voor deze fase aan.

Deze fase gaat zonder ophouden door tot er door de gebruiker een gehee1 nieuw systeem is aangeschaft.

2.2 De data-base levenscyclus

De e1ementaire fasen van de data-base ontwik-kelingscyclus zoa1s geformuleerd door Teory en Fry (1981) zijn:

(a) formu1eren van het programma van eisen en analyse

(b) logisch on twerp

(c) fysiek on twerp en evaluatie (d) implementatie

(e) ingebruikneming en toezicht (f) verandering en aanpassing.

Het daadwerkelijke ontwerpen van de data-base gebeurt in de fasen (b)-(c). Men kan ste1len dat er een extra fase tussen fasen (b) en (c) is, genaamd structureel ontwerp, waarin de toegangseisen wel in aanmerking worden genomen maar de diverse zaken die te maken hebben met de specifieke eisen van data-base managers nog niet.

Hieruit mogen de drie fasen voor het data-base ontwerpproces afgeleid worden:

(a) logisch ontwerp (b) structureel ontwerp (c) fysiek ontwerp.

Tijdens het logische antwerp worden de eisen ten aanzien van de data en de relaties tussen de data beschouwd (zie 2.2.2). Het structurele antwerp bepaalt de taegangseisen en de

hoevee-lheden data (zie 2.2.3). Bij het fysieke ant-werp worden de logische en structurele model-len op een specifiek data-base managementsys-teem toegespitst (zie 2.2.5).

Volgens Teary en Fry zijn de drie belangrijk-ste resultaten van het data-base antwerp-proces:

(a) de datastructuur (of logische data-basestructuur),

(b) de opslagstructuur en

(c) de specificaties vaor de applicatie-programma' s, gebaseerd op deze data-basestructuren en eisen omtrent de ver-werking.

Het eerste is het resultaat van het logische antwerp, het tweede van het fysieke antwerp en het derde is het resultaat van beide fasen. Deze resul taten tesamen kunnen gezien worden als de specificatie van de uiteindelijke data-base implementatie.

2.2.1 Systeemanalyse

"Bij het verwerken van data wordt een verzame-ling mensen, machines en methoden, georgani-seerd om een set specifieke functies te ver-vullen, een systeem genoemd" [Davis, 1983,

p .4].

De systeemanalyse is een activiteit die de planning en coardinatie van activiteiten be-helst als er een specifieke functie vervult dient te worden. De systeemanalyse is afge-stemd op de systeem-levenscyclus. De analyse is een lagisch praces. Het dael van de

sys-teemanalyse is niet het probleem daadwerkelijk op te lessen, maar exact te bepalen wat er

gedaan moet worden om bet probleem op te los-sen. Tijdens de systeemanalyse dient de sys-teemana 1 ist samen te werken met de gebruiker om tot een logisch model van het systeem te komen. De componenten voor de systeemana lyse zijn:

(a) het logische model van het systeem (b) het datastroom-diagram

(c) de data-dictionary (d) de algoritmen.

Volgens Davis dient de systeemanalyse te ein-digen met een keuze. Op dat punt moet duide-lijk worden wat de voordelen van elk alterna-tief zijn. Deze keuze zal de basis zijn van het model voor de ontwikkeling van het logi-sche en het fysieke ontwerp van het systeem. De kern van de systeemanalyse is de vraag: Hoe

dient bet probleem in het algemeen te worden

opgelost? Hieruit dienen de alternatieve

oplossingen voort te komen, evenals de stroom-diagrammen van het systeem en de kosten/baten-analyse.[ibid]

2.2.2 Het logische ontwerp

In de voorgaande sekties over data-base wikkeling Werden de begrippen 'logisch ont-werp' en 'logische structuur' geintroduceerd. In het volgende wordt het woord 'logisch' in dit verband toegelicht.

Log~sch in data-base terminologie betekent:

"een bi j voege 1 i jk naamwoord da t de vorm van data-organisatie, hardware, of systeem be-schrijft., zoals dat door een applicatie-pro-gramma of -programmeur wordt gezien; het kan verschillen van de werkelijke (fysieke) vorm." [Martin, 1977, p. 691]

2.2.2.1 Inleiding tot de data-base structuur Het meest elementaire stukje data is het

data-item (oak: veld, oak: data element). Een data-item kan niet verder onderverdeeld worden in kleinere data-typen zonder zijn betekenis voor de gebruikers te ver l iezen. Een losstaand data-item heeft geen waarde. Het krijgt alleen dan betekenis indien het in relatie wordt gebracht met andere d~ta-items.

Een data-base bestaat uit data-items and hun samenhang. Er bestaat een groot aantal ver-schillende data-item-types en daarom hebben we een kaart nodig die aangeeft hoe ze samenhan-gen. Deze kaart wordt soms een datamodel ge-noemd.

Er bestaat een aantal manieren om zo'n kaart te tekenen. De kaart die we gebruiken laat niet zien hoe de data fysiek opgeslagen wor-den. Het laat alleen de logische samenhang tussen de data-items zien. De totale logische data-basebeschrijving wordt schema genoemd. Soms wordt het een globaal model van de data, een conceptueel model, of een conceptueel schema genoemd. Terwijl de kijk op de data van de programmeur of de fysieke opslag en organi-satie veranderen, blijft het conceptuele model stabiel of groeit om meer data-types te kunnen bevatten.

De term subschema verwijst naar de kijk van een applicatie-programmeur op de data die hij gebruikt. Vele subschema's kunnen van een

schema afgeleid worden.

Om de data-base structuur te ontwerpen en te laten functioneren werd een nieuwe discipline ge!ntroduceerd: de data-base administrator. Dit is de persoon die het gehele data-base schema ontwerpt en kent, en er voor zorgt dat de de subschema's, welke door de applicatie-programmeur worden afgeleid, voldoen aan het algemene schema.

Howe stelt de voordelen van de introductie van het begrip 'data-model' aan de orde en

op een hoger niveau, die onafhankelijk is van enige DBt1S programmatuur." [Howe, 1983, p. 30] "Door het vastleggen van conceptuele en exter-ne data-modellen hoeft de data administrator zich niet te bekommeren om de eigenaardigheden van een bepaald DBMS en is hij of zij dus in staat zich uitsluitend te concentreren op de eigenschappen van de data. Het bestaan van data-model1en zal tevens de vergelijkingen vergemakkelijken tussen de merites van ver-schillende data-base managementsystemen, waar het erom gaa t om te ki jken of aan de eisen van

een organisatie tegemoet wordt gek~men.

Tij-dens een daarop volgende fase van het (EDP) ontwerpproces zullen de data-modellen toege-sneden worden op de schema's die gebruik maken van de talen welke door een bepaald DBMS wor-den geleverd." [Howe, ibid]

Drie benaderingen van een logische

data-base visualisering

Er kunnen drie benaderingen van logische re-presentaties van een data-base onderscheiden:

(a) de hi~rarchische benadering: boom-struc-turen

(b) de netwerkbenadering: plexstructuren

(c) de relationele benadering:

genormali-seerde structuren Information Structure Entltie1 Ralation1hlp1 Anribut•• Identifier~

applications data models _relational

D.DDD

Figuur 5: Logische representatie van een

2.2.2.2.1 Boornstructuren

De belangrijkste karakteristieken van een hi~rachische benadering van data-basemodellen of -structuren zijn:

(a) een segment kan slechts aan~~n ander

segment ondergeschikt zijn

(b) een of meer segrnenten kunnen onderge-schikt zijn aan een ander segment.

Sommige data-base programmatuur is ontworpen om alleen hi~rarchische datastructuren te ver-werken. Hi~rarchische structuren zijn relatief gemakkelijk weer te geven en te onderhouden. Hoewel dit mqge voldoen voor sommige toepas-singen, zijn vele data niet hi~rarchisch van aard.

De visies van de gebruikers op de data dienen samengevat te worden in een data-base schema. Het resultaat hiervan is meestal gecompliceer-der dan een boomstructuur. Daarom is software, ontworpen om alleen ontleedde boom-structuren te verwerken, beperkt in gebruik, en zal vaak de groei en de ontwikkeling van de data-base

in de tijd sterk beperken.

2.2.2.2.2 Netwerkbenadering

Indien een segment in een datarelatie onder-geschikt is aan meerdere segmenten kan de relatie niet beschreven worden als een boom-of hi~rarchische structuur. In plaats daarvan wordt hij beschreven als een netwerk- of

plex-structuur. De belangrijkste karakteristiek van een plexstructuur is dat elk segment met elk ander segment in verbinding kan staan.

Elke netwerkstructuur kan worden teruggebracht tot een simpeler vorm door redundantie te introduceren. In sommige gevallen is de redun-dantie, die het gevolg is van het weergeven van een netwerkstructuur als een boomstruc-tuur, klein en acceptabel. In andere gevallen

is de redundantie buitensporig.

De reden van bezorgdheid of de reLaties als boom- of netwerkstrukturen kunnen worden weer-gegeven vloeit voort uit het feit dat de mees-te types fysieke data-organisatie die goed werken met boomstructuren slecht werken met netwerk-structuren. Bijg~volg kan sommige data managementprogrammatuur netwerkstructuren ver-werken en sommige slechts boom-structuren.

2.2.2.2.3 De relationele benadering

Data-base systemen lopen het risico dat ze omslachtig, star en problematisch worden. De logische verbindingen neigen naar een verveel-voudiging bij het toevoegen van nieuwe appli-ca ties en bi j de verzoeken van gebruikers om nieuwe vormen van 'queries'. Een hoge mate van complexiteit zal zo binnen vele data-base systemen ontstaan.

Het is mogelijk om zulke klitten in boom- en netwerkstrukturen te vermijden door gebruikma-king van een techniek die normalisatie wordt genoernd. Normalisatietechnieken werden ont-worpen en gepropageerd door Codd. ne principes die volgens Codd moeten worden gebruikt bij het ontwerpen van een data-base houden verband met de gebruiker's visie op de data of de

logische beschrijving van de data.

Men moet streven naar een beschrijving van de data, zodanig dat hij:

(a) eenvoudig door de gebruikers zonder programmeerervaring kan worden begrepen; (b) het mogelijk maakt nieuwe data-items, records en associaties aan de data-base toe te voegen zonder de bestaande sub-schema's, en derhalve de applicatie-programma's te veranderen en

(c) de maximale vrijheid biedt bij het ver-werken van onvoorzien datagebruik of

spontane vragen van gebruikers aan de terminals.

Vaak is de meest natuurlijke manier data aan de niet-programmerende gebruikers weer te geven door middel van een twee-dimensionale tabel. Normalisatie is een proces waarbij stap voor stap de verbanden tussen gegevens zoals bij boom- en netwerkstructuren vervangen wor-den door verbanwor-den in een twee-dimensionale tabelvorm. Deze tabel wordt een relatie ge-noemd. Een data-base die opgebouwd is uit

relaties wordt een relationele data-base

genoemd.

De voordelen van het weergeven van data in een genormaliseerde vorm zijn een toename van eenvoud in het gebruik, flexibiliteit, nauw-keurigheid, veiligheid, eenvoud in de imple-mentatie, data-onafhankelijkheid, duidelijk-heid, en het gebruik van een simpele, krach-tige data-manipulatie taal.

2.2.2.3 Het nut van een logische structuur Nadat de eerste data-base systemen een tijd in gebruik war en geweest werd het d uide 1 i jk da t een extra niveau van data-onafhankelijkheid gewenst was. De totale logische structuur van de data-base wordt in veel gevallen ingewik-keld en als de data-base in omvang toeneemt

verandert de totale logische structuur onver-mijdelijk. Het wordt belangrijk dat de struc-tuur moet kunnen veranderen zonder dat de vele applikatie-programma's, die er mee werken, mee moeten veranderen. Bij sommige systemen is het veranderen van de logische structuur van de data-base er bij gaan horen~ hij ontwikkelt zich doorlopend. Daarom zijn twee niveau's van data-onafhankelijkheid vereist: logische en

fysieke data-onafhankelijkheid.

Logische data-onafhankelijkheid betekent dat de totale logische structuur van de data kan veranderen zonder de applicatie-programma's te

veranderen. De data-baseprogrammatuur zal fei-telijk de data van de applicatie-programmeur uit het totale logische structuurschema aflei-den en de totale logische structuur in een

fysieke representatie omzetten.

2.2.2.4 De stappen van het logische ontwerp Hoewel er geen gedetailleerde leidraad voor het logische ontwerp van een data-base in de literatuur te vinden is, kunnen toch enige globale stappen worden onderscheiden:

(a) via een analyse van het bouwproces dient een datamodel te worden afgeleid~

(b) dit datamodel moet leiden tot het ont-werp van het schema van ADIS ~

(c) van dit schema kunnen de vele verschil-lende subschema's afgeleid worden welke aan de eisen van de applicatie-program-meurs en gebruikers (architecten) tege-moet komen.

In het 'Report from the 1984 Workshop on Ad-vanced Technology for Building Design and Engineering' wordt een twee-traps aanpak voor het on twerp van een gelntegreerde data-base, dat wil zeggen een combinatie van een project en een algemene data-base, voorges~eld.

Wat betreft het puur logische ontwerp worden de volgende twee stappen genoemd:

(a) applicatie-architectuur1)7 de definities van de functies en de functionele rela-ties die het bouwproces beschrijven. De applicaties worden gedefini~rd door een

portfolio aan te leggen waarin de ele-menten van een proces in termen van

input, output en bewerkingshandelingen worden vastgelegd. (zie deel 5).

(b) data-arcbitectuur7 bet onderscbeiden van de entiteiten en de relaties die de applicatie-arcbitectuur bndersteunen. Tijdens dit stadium dient bet datamodel te worden ontwikkeld. Dit datamodel is onafhankelijk van de fysieke irnplementa-tie van de data-base en geeft alleen de

logiscbe structuur weer.

l)N.B.: de term 'arcbitectuur' wordt bier gebruikt in de betekenis van: "bouw" of "con-structie".

2.2.3 Het structurele ontwerp

Het structurele ontwerp vorrnt een belangrijke stap tussen bet puur logiscbe ontwerp van de conceptuele en relationele modellen en bet totaal opslag-georienteerde fysieke ontwerp. Bij bet structurele ontwerp worden de data-volumes en toeganseisen samen met de sleutel structuur van de relaties bescbouwd. Deze fase van analyse kan leiden tot enige veranderingen in de relaties, betgeen is toegestaan omdat er altijd praktiscbe problemen opgelost dienen te worden. Deze redenen voor veranderingen moeten ecbter worden vastgelegd en de originele set moet worden bewaard, opdat de beslissingen op een later tijdstip opnieuw bekeken kunnen worden.

2.2.3.1 De stappen van bet structurele ontwerp Drie stappen in bet ontwerp van een structu-reel model worden door Teory en Fry onder-scbeiden. De eerste beeft te doen met de typen

records, de tweede met de ontwerpobjectieven en de laatste met informatie omtrent de volu-mina. DBze drie stappen zijn:

(a) leg de recordtypen vast7 (b) toets de aannamen7

(c) analyseer het te verwerken volume en leg de laatste hand aan de informatiestruc-tuur [Teory en Fry, 1982].

Tijdens de eerste stap dient er een bewer-kingsmatrix te worden ontwikkeld die het ver-band legt tussen bepaalde applicaties en data-items, die in de analyse van de bewerkingsei-sen werden gespecificeerd. Het gecombineerde inzicht, verkregen uit de bewerkingsmatrix en de herziene informatiestructuur moet worden gebruikt om de eerste recordtypen, keydata-items en non-keydata keydata-items te formuleren.

Tijdens de tweede stap dienen alle aannamen omtrent de ontwerpobjectieven, informatie-eisen en data-inhoud te worden getoetst. Ver-volgens moet worden getoetst of aan de data-eisen van alle applicaties tegemoet kan worden gekomen met de bestaande informatiestructuur. Gedurende de ~aatste stap zou men de kingseisen van het datavolume en de bewer-kingsfrequentie moeten analyseren. Voor elke toepassing moeten de prestatiemaatstaven, zoa 1 s toegang tot de 1 og i sche recorns, trans-port-volumina (aantal overgezonden bytes of records) en de opslagruimte nodig voor de herziene informatiestructuur met de records worden gespecificeerd. Kritieke en

overheer-sende applicaties dienen te worden aangegeven. Vervolgens dient de informatiestructuur voor het minimaliseren van de toegang tot de

logi-sche records en/of transport-volumina voor

alle applicaties te worden vastgelegd. Indien

nodig moet het recordtype bevestigd of opge-deeld worden. Indien gewenst en haalbaar die-nen de applicaties bevestigd te worden.

Hoewel dit niveau van beschrijving niet erg gedetailleerd is -meer gedetailleerde

aanpak-ken kunnen worden gevonden [Yeh e.a.,

]-beschouwen wij dit vooralsnog als voldoende om de lezer enige indruk te geven van de taken welke vervuld moeten worden gedurende het structurele ontwerp.

Het structurele model verschaft een uitsteken-de ingang tot uitsteken-de fysieke-ontwerp fase die er op volgt. Het model dat zojuist is ontwikkeld bevat 'plaatjes' van de structuur -een raam-werk van relaties waaraan idee~n kunnen worden opgehangen-, details aangaande de toegang en volume-eisen.

2.2.4 Het fysieke ontwerp

Tijdens het fysieke ontwerp worden de set met relaties (of relationele bestanden) en het structurele model vertaald in opslagstructuren door gebruikmaking van indexen, bestandswij-zers en toegangsmethoden.

Hier worden slechts weinige woorden besteed aan het fysieke ontwerp, omdat het te veel afhankelijk is van de gebruikte hardware en het buiten het bereik van het onderzoek valt. Teory en Fry noemen een stadium voor de fase van het fysieke ontwerp: "Het formuleren van de logische data-basestructuur. Gedurende deze stap worden de specificaties van het DBMS beschouwd en de herziene informatiestructuur wordt omgezet in een logische data-basestruc-tuur (of datastrucdata-basestruc-tuur). Ingangen, wijzerop-ties en de rangorde van records moeten worden gese 1 ecteerd. Er meet gezoch t worden naar verdere verfijningen of alternatieven die DBMS-afhankelijk zijn: afzonderlijke

data-bases, sorteren, batchgewijze-verwerking,

enz." [Teory en Fry, 1982]

Volgens Teory en Fry omvat het fysieke ontwerp de selectie van de klasse van opslagstructuur en het nadere afstemmen van de implementatie ervan, zeals de specificatie van de

blok-grootte en de apparatuurtoewijzing. Ret re-sultaat van het fysieke data-base ontwerp-proces is een compleet en implementeerbaar ontwerp.

2.3 Verspreide data-bases

Indien een enkel systeem data-bases op meer-dere geografische plaatsen heeft worden deze verspreide data-bases (distributed data-bases) genoemd.

Bij het ontwerp- en bouwproces ziin vele indi-viduen en organisaties betrokken. Deze leden van het Design Coalition Team zullen -naar alle waarschijnlijkheid- niet allen op dezelf-de plaats werkzaam zijn. Dit vormt dezelf-de aanlei-ding tot een bespreking van verspreide data-bases in het verband van een Architectural Design Data Base (ADDB) als onderdeel van het Architectural Design Information System

(ADIS).

De redenen voor het verspreiden van data nemen toe. Een aantal argumenten, zowel voor als tegen verspreide data base, worden genoemd in

J. Martin's boek 'Principles of Data Base Management' [Martin, 1976].

Hiervan volgt een samenvatting in de sekties 2.3.1 - 2.3.3. In sektie 2.3.6 wordt de theo-rie in het kader van de Architectural Design Data Base kort besproken.

2. 3 . l Mogelijke redenen voor het ver-spreiden van data-bases

Voor verspreide data-bases kunnen de volgende voordelen -met enige kanttekeningen- worden gegeven:

(a) kostenvermindering

Indien een systeem zijn gegevens opslaat nabij de plaatsen waar ze zijn ontstaan

of worden gebruikt is er minder verzen-ding van data nodig hetgeen leidt tot een afname van de telecommunicatie-kosten. Aan de andere kant werkt de kostenafname als gevolg van schaalver-groting grate, gecentraliseerde gege-vensopslagmiddelen in de hand. Er dient

een kostenafweging te worden gemaakt

tussen beide factoren. De kosten van kleine, plaatselijke opslagfacili-teiten zakken sneller dan die van data-verzending.

(b) overwegingen inzake werkbelasting

Op een aantal systemen is de verkeers~ last grater dan de capaciteit van de huidige data-baseprogrammatuur. Aparte systemen, die bepaalde gebieden bedie-nen, kunnen worden gebruikt, maar die dienen dan wel gelijke datastructuren te hebben evenals de mogelijkheid transac-ties van het ene systeem naar het andere te versturen.

(c) plaatselijk management

Plaatselijk management en beheer van de data kan aanzienlijke voordelen hebben. De plaatselijke organisatie is volledig verantwoordelijk voor de nauwkeurigheid en het veiligstellen ervan. Bovendien kunnen sommige programma's het beste plaatselijk worden ontwikkeld, omdat alleen de plaatselijke analist met lo-cale problemen en eisen bekend zal zijn. De afzonderlijke, plaatselijke gebrui-kers van de data kunnen echter verplicht

zijn zich aan de centraal overeengeko-men datadefinities, -formaten en sche-ma's te conformeren.

(d) minicomputers

De plaatselijke ontwikkeling en opslag van locale bestanden heeft in populari-teit en economische haalbaarheid qewon-nen door de verspreiding van minicompu-ters met de mogelijkheid van datatrans-missie.

Bij deze systemen moet de logische en fysieke data-onafhankelijkheid -de be-langrijkste karakteristiek van DBMSen-gewaarborgd Z1Jn. Vele minicomputers maken echter eerder gebruik van file-opslag dan van data-basefile-opslag bij DBMS-programmatuur. Netwerken van dergelijke minicomputers zouden daarom eerder als verspreide filesystemen aangeduid dienen te worden dan als verspreide data-base-systemen.

(e) afzonderlijke informatiesystemen

Er kunnen goede redenen bestaan om de data-bases van operatie- en informatie-systemen apart te houden. Indien ze apart gehouden worden kunnen ze zich al dan niet op verschillende plaatsen be-vinden.

Binnen grote organisaties kan zich het patroon ontwikkelen met locale en regio-nale operatiesystemen die een apart, gecentraliseerd informatiesysteem, met anderszins gestructureerde data-bases voor snelle en spontane vragen, voeden. In dit geval verwerken de informatiesys-temen de complexe vragen van de mensen die het beleid bepalen en de beslissin-gen nemen, en het operatiesysteem dient om de gegevens te verzamelen.

De data bases van het operatie- en in-formatiesysteem kunnen desalniettemin bepaalde data delen en verbonden zijn door datatransmissie-verbindingen.

e-systeem een data-basee-systeem terwijl de operatiesystemen slechts bestandensyste-men zijn.

(f) verspreide inte 11 igentie

Een van de meest belangrijke trends bij interactieve computersystemen is de trend naar verspreide intelligentie (distributed intelligence). Onder DI wordt verstaan dat terminals en andere apparaten in een terminalnetwerk aan een miniatuu_r computer gekoppeld zijn om ervoor te zorgen dat de uitgestrekte tentakels van het netwerk zich 'intelli-genter; gedragen. Een mogelijk gebruik van DI is het voorzien in een dialoog tussen de gebruiker en de terminal, die aangepast is aan de eerstgenoemde.

Een andere mogelijkheid is het verbete-ren van de doelmatigheid en de reductie van de kosten van het overzenden van data door deze eerst in kleine, lokale opslageenheden op te slaan en vervolgens 'en bloc' naar de centrale data bases en computers te verzenden. De data kunnen worden onderverdeeld in die welke locaal kunnen worden opgeslagen (en niet van belang zijn op de centrale locatie) en die welke centraal benodigd zijn voor centraal beheer of omdat andere gebrui-kers ze nodig kunnen hebben.

In sommige gevallen wordt de opslag van de lokale dialoogcomputer geladen vanuit de centrale data-base op verzoek van de gebruiker van de terminal. Bij grafische toepassingen, bij voorbeeld, kunnen op verzoek de bestanden met manipuleerbare beelden vanuit de centrale data-base worden verzonden.

In sommige gevallen Z1Jn verspreide

locale bestanden nodig om in een snele responstijd te voorzien ten behoeve van een effectieve dialoog.

(g) beschikbaarheid

Systemen die terminalgebruikers bedienen dienen in een veel grotere mate dan batchgewijze verwerkingssystemen vrij te zijn van haperingen. Opslagsystemen ha-peren echter en om een hoge mate van beschikbaarheid van data te verkri jgen kan de systeemontwerper dupl icaten van belangrijke data in meer dan ~n machine opslaan. Om storingen in de telecom-municatie te omzeilen kan hij de dupli-caten in verschillende lokaties opslaan. (h) veiligheid

De bescherming van data is een argument geweest bij sommige systemen om data-bases op te splitsen.

(j) veelzijdigheid in terminalgebruik

De optie ve 1 e verschi llende data-bases te gebruiken kan de gebruiker voorzien van een scala van mogelijkheden.

(k) computernetwerken

Computernetwerken die een wijd scala van heterogene computersystemen onderling verbinden komen in zwang. Dergelijke netwerken staan het koppel en van ·vele, afzonderlijk ontwikkelde data-bases toe.

2.3.2 Verschillende typen van systemen

De in 2.3.1 genoemde redenen om verspreide data-bases te gebruiken zijn aanleiding tot het ontstaan van verschillende typen van sys-temen. Figuur 5.3 toont vier gangbare typen van systemen di e elk gebruik maken van ver-spreide data.

a..

1%1~--b.

c.

cl.

Figuur 6:

Smli· •oca' itoratt ""its c:oro"tctiCJ to 1 cefllt~l Dlt• bile to form 1 homblf"IOvS Syst.,.

ODrt!·OI"''' t-nt..,. tonl"tetld tor int~.,t·Oft I'Yitt-C:;I'IU•"•"'Q ,..llt'IG data chff..-.,r-v ~1,1.181d

lOci .. _ dlta-Golo I V f t

-ll"'fi"COI"'nect.C: by I t'O'"D~tl'f' :iU - k

verspreide data-base systemen (naar Martin, 1976)

In figuur 6(a) kunnen de datatypen en -struc-turen globaal hetzelfde zijn, maar de fysieke opslag is geografisch verspreid. Dezelfde

zelfde schema's kunnen worden gebruikt voor elk van de afzonderlijke data-bases.

In figuur 6 (b) worden k 1 eine, peri fere opslageenheden gebruikt om het functioneren van de centrale data-base te verbeteren. De subschema's die gebruikt worden in de perifere opslageenheden kunnen worden afgeleid van het Schema dat gebruikt wordt in het centrale systeem.

Figuur 6(c) laat afzonderlijke operatiesys-temen zien die een gedeelte van hun data leve-ren aan een centraal informatiesysteem. De operatiesystemen hier gebruiken hun eigen schema's en, anders dan in het tweede geval, zou elk een op zichzelf staand systeem moeten zijn. De datatypen en -formaten die in de systemen worden gebruikt zijn echter nauw verbonden en op een ge!ntegreerde wijze ont-wikkeld.

Figuur 6(d) toont een computernetwerk waar-in zowel de computers als de data-bases valle-dig heterogeen kunnen zijn.

2.3.3 De overeenkomsten van datastructuren Verspreide data-bases. verschillen in hun mate van homogeniteit. In het ene uiterste kunnen ze identieke structuren hebben, zoals dat het geval zou kunnen zijn in figuur 6(a), en in het andere uiterste kunnen ze totaal

verschil-lende structuren hebben, zoals misschien in figuur 6(d).

Het is wenselijk een goed evenwicht te vinden tussen gecentraliseerd en gedecentraliseerd beheer. Voldoende gedecentraliseerd beheer is noodzakelijk om het plaatselijk oplossen van lokale problemen toe te staan en voldoende gecentraliseerd beheer is vereist om het

moge-lijk te maken dat data en programma's van de ene lokatie naar de andere kunnen worden over-gestuurd.

2.3.4 Waar zijn de data opgeslagen?

Indien de gegevens van een systeem gescheiden zijn opgeslagen dient er een hulpmiddel te zijn om te bepalen waar een bepaald gedeelte van de data zich bevindt. Zoals bij andere aspecten van verspreide data-bases kan het localiseren van data varieren van een simpele tot een.hoogst gecompliceerde operatie.

Een eenvoudige methode is die waarbij de ge-bruiker de plaats specificeert waar de data zijn opgeslagen wanneer hij het verzoek in-dient om hen te gebruiken. Zijn transactie kan dan worden verzonden naar de computer op de locatie van de data of de data kunnen worden verzonden naar een locatie waar ze bewerkt kunnen worden.

Het wordt iets gecompliceerder als de gebrui-ker informatie omtrent de data mag specifice-ren waaruit hun locatie eenvoudigweg kan wor-den bepaald.

De plaatsbepaling van de data wordt nog ge-compliceerder in het soort systemen zoals dat in figuur 6(d) waarbij de gebruiker niet weet waar de data zich bevinden. Het systeem moet in dat geval een soort catalogus of lijst (directory) bevatten waarmee de data kunnen worden gelocaliseerd.

Directories zullen normaliter meer informatie

bevatten over het beheer van de data dan al-leen hun plaats: "Moderne DBMSen hanteren een directory (of schema) om de data-base die beheerd moet worden te defini~ren. Het doel van de directory is de gebruiker en de appli-catie-programmeur te bevrijden van de noodzaak dergelijke informatie te verschaffen en het vereenvoudigt vele soorten structurele veran-deringen van de data-base. In voorkomende gevallen bevat de directory vier soorten

in-formatie:

(a) de definitie van de logische structuur (namen van de records en hun relaties, domeinen, etc.)

(b) de definitie van de fysieke structuur (de formaten van de datavelden, etc.) (c) statistieken aangaande de bestanden

(om-vang, etc.)

(d) boekhoudkundige data (wie heeft er toe-gang gehad tot het bestand, wie is de eigenaar van een bestand, etc.)

Voor een verspre,ide data-base dient er nog meer informatie aan de directory te worden toegevoegd: de plaats van elk stuk van de data-base in het netwerk" [Davenport, 1979, p.l04].

Het verschil tussen een directory en een cata-logus moge het duidelijkst worden uit een vergelijking van de voorgaande definitie van een directory met de volgende van een catalo-gus.

"Data-elementen in een verspreide data-base kunnen ook gelocaliseerd worden via een

cata-logus die vermeldt waar bepaalde datasets zijn

opgeslagen. Catalogi bevatten meestal eerder informatie over de dataset, het bestand, of gebiedsniveau dan op het niveau van de data-elementen zeals schema's.

Een globale catalogus kan door een lijst data-sets opgeven die van een afstand zi jn toege-voegd en aangeven waar elke dataset zich be-vindt. Indien elke computer een kopie bevat van de globale catalogus is het altijd moge-lijk te bepalen waar de globaal-toegankemoge-lijke data-elementen zich bevinden" [Booth, 1979,

p.35].

Het verschil tussen een directory en een cata-logus ligt derhalve in het niveau waarop deze met de data omgaan.

2.3.5 Het oversturen van gegevensbestanden Wanneer een transactie een computer bereikt die niet de vereiste data bezit zijn er drie mogelijkheden:

(a) de transactie kan worden verstuurd naar de plaats waar de data zich bevinden en daar uitgevoerd worden

(b) de data kunnen worden verstuurd naar de plaats van de transactie om daar ge-bruikt te worden

(c) zowel de transactie als de data kunnen worden verstuurd naar een derde plaats

voor verwerking.

De keuze van de te gebruiken methode zal deels van het volume van de data en deels van de frequentie van het versturen afhangen.

2.3.6 Verspreide data-bases en het Design

Coalition team

In de introductie is reeds gesteld dat de

leden van het design coalition team over

verschillende plaatsen verspreid z~llen zijn. Omdat zij echter aan hetzelfde gebouw werken zal het nodig zijn dat ze de data die het gebouw beschrijven, de model data-base, en de algemene data, de algemene data-bank, kunnen delen. Beide data bases kunnen op een ver-schillende manier worden benaderd vanuit de .oogpunten van verspreidingspolitiek,

manage-ment en beheer.

2.3.6.1 De verspreide model-data-base

De model-data-base moet centraal worden heerd om de samenhang, nauwkeurigheid en

be-veiliging te kunnen garanderen door de persoon

die het projekt .c~rdineert, de architect dus.

Op deze wijze worden de andere leden van het design coalition team verplicht zich te con-formeren aan de centraal overeengekomen data-definities en -formaten en schema's.

Een afweging dient te worden gemaakt tussen de

kosten van de opslagfaciliteiten en de

tele-communicatie om te beslissen of de gehele model-data-base -of welk deel ervan- moet worden verstuurd naar de plaatselijke opslag van de gebruiker, of da t de transacties van de gebruiker met het model dienen te worden over-gestuurd.

Elk lid dient te zijn uitgerust met een opera-tiesysteem om handelingen op het model te kunnen uitvoeren, bv. het gebruiken van

appli-catieprogrammatuur. De computers die deze taken vervullen kunnen ook andere taken op zich nemen zoals het voorzien in een geschikte dialoog en transmissiefaciliteiten.

Nadat de transacties met (een gedeelte van) het model zijn afgerond moet de samenhang van de data-base op een centrale lokatie worden gecontr.oleerd.

De data-bank en programma-bank

De verspreiding van ADIS is een veel gecompli-ceerder zaak dan die van de model-data-base. Dit onderzoek houdt zich niet bezig met de ontwikkeling van de verspreide data-bases van ADIS. Het zal zich echter bezig houden met de

bepaling van de datatypen, datastromen en

processen. Tevens zal dit onderzoek trachten het gestelde doel te bereiken door het ontwik-kelen van de conceptuele structuur van het systeem en alles voor te bereiden voor bet logische en fysieke ontwerp van het systeem op basis van de criteria die genoemd zijn onder 2.2.1 en 2.3 (zie 1.1 voor een gedetailleerde beschrijving van de data-bank en programma-bank).