Bijlagen A bij hoofdstuk IV over Basisontwerp

B3: Systematisch bouwen van informatiesystemen

Bijlagen A bij SDM-fase 2: Basisontwerp

Bijlagen A bij hoofdstuk IV over Basisontwerp Bijlage BO - a)

Basisgegevensstructuur bepalen: uniciteitspijlen

We zullen onze activiteiten verduidelijken aan de hand van het voorbeeld secretariaat sportvereniging. Wij bouwen hierbij voort op de resultaten die in het Rapport Definitiestudie Sportvereniging staan. Dit rapport is als bijlage in Fase 1 Definitiestudie opgenomen.

Informatieanalyse - tweede onderdeel : uniciteitsregels Inleiding In de informatie-structuurdiagrammen uit de definitiestudie kun je zien wat voor relaties er zijn tussen de objecten (dingen, begrippen en personen) die een rol spelen in de werkelijkheid van de sportvereniging. In dit tweede onderdeel van de informatieanalyse worden deze relaties nader geanalyseerd. In deze analyse zullen we nagegaan of er beperkingen zijn voor wat betreft het aantal keren dat objecten in een relatie een rol mogen spelen. Bijvoorbeeld: - van een team weten wij dat er per team maar één aanvoerder is, - van een team weten wij ook dat een team uit meerdere spelers bestaat. In de terminologie van ons informatiestructuurdiagram kunnen we dan zeggen, dat in de relatie 'speleraanvoerder van team' de objecten team en zijn speleraanvoerder slechts één keer een rol kunnen/mogen spelen. In de relatie 'speler van team' kan het object team met meerdere objecten speler voorkomen; het object speler kan meerdere malen een rol in de relatie spelen.

Aantallenregels In de analyse hanteren wij zogenaamde aantallenregels. Zo'n aantallenregel geeft aan hoe vaak een object een bepaalde rol in een relatie met een (ander) object mag spelen. Voorbeeld: in de relatie tussen team en speler geldt de aantallenregel : een speler mag maar in één team spelen. In dit voorbeeld mag een object (een speler) een bepaalde rol (van) in een relatie met een (ander) object (de relatie tussen spelers en teams) een aantal malen (één maal) spelen. Wanneer een rol maar éénmaal gespeeld mag worden, dan noemen we zo'n rol een 'unieke rol'. Een rol die meer dan één keer gespeeld mag worden, noemen we een 'niet-unieke rol'. Minder dan één keer kan een rol niet gespeeld worden, immers: wanneer er geldt dat een rol nul keer (= nooit) gespeeld mag worden dan is er eigenlijk helemaal geen relatie tussen de betreffende objecten en zou die relatie helemaal niet in het informatie-structuurdiagram mogen staan. Het vinden van unieke rollen is vooral van belang voor later, wanneer in de fase detailontwerp de gegevens die bij de objecten uit de werkelijkheid horen, moeten worden ingedeeld in gegevenstabellen die tezamen de gegevensbank vormen.

Unieke en niet-unieke rollen in binaire relaties Allereerst bespreken we de notatie van het uniek of niet-uniek zijn van rollen in het informatie-structuurdiagram: Een unieke rol wordt in een informatie-structuurdiagram weergegeven door een klein dubbel pijltje te zetten onder of boven het vakje van de betreffende rol: met

van

TEAM

SPELER

BO-bijlagen A blz. 1



Een niet-unieke rol wordt in een informatiestructuurdiagram weergegeven door NIETS te zetten onder of boven het vakje van de betreffende rol. In de voorgaande figuur geldt bijvoorbeeld dat: - 'van' een unieke rol is, immers: een speler zit maar in één team, - 'met' een niet-unieke rol is, immers: een team bestaat uit meerdere spelers.

In relaties waarin twee rollen voorkomen (binaire relaties met als rollen rol1 en rol2 ) zijn er vier mogelijkheden: 1.

rol1 is een unieke rol en rol2 is een niet-unieke rol (zet in dit geval onder rol1 een klein dubbel pijltje)

2.

rol2 is een unieke rol en rol1 is een niet-unieke rol (zet in dit geval onder rol2 een klein dubbel pijltje)

3.

zowel rol1 als rol2 is een unieke rol (zet in dit geval zowel onder rol1 als onder rol2 een klein dubbel pijltje)

4.

zowel rol1 als rol2 is een niet-unieke rol (zet in dit geval een lange dubbele pijl, die begint onder rol1 en eindigt onder rol2.

Eigenlijk zou je verwachten dat je zowel onder rol1 als onder rol2 GEEN pijltje zou zetten. De grote dubbele pijl onder beide rolvakjes geeft echter aan dat de combinatie van beide rollen uniek is, dat wil zeggen: als object a voorkomt in deze relatie samen met object b, dan komt de combinatie (object a , object b) slechts één keer voor in de relatie; het voorkomen van de combinatie (object a, object b) is uniek.

Hieronder staat het informatie-structuurdiagram van elk van deze vier gevallen: rol 1

rol 2

Geval 1

rol 1

rol 2

Geval 2

rol 1

rol 2

Geval 3

rol 1

rol 2

Geval 4




'Strepen en tellen' -methode: voor het bepalen van unieke en niet-unieke rollen in binaire relaties Het wel of niet uniek zijn van rollen is op een eenvoudige en systematische manier na te gaan. Daarvoor wordt de 'strepen en tellen'-methode gebruikt, die hieronder beschreven staat.

Opstellen relatietabel: Voor relaties met 2 rollen (binaire relaties) wordt het volgende tabelletje opgeschreven: object 1 object 2 rol 1 rol 2 ____________________

VOORBEELDTABEL 1

A1 B1 A1 B2 A2 B1 ____________________

In dit tabelletje staan alle mogelijke combinaties van objecten die zich theoretisch gezien zouden kunnen voordoen. In de tabel staan voorbeeld-objecten: A1 is één van de mogelijke "object 1"- objecten, A2 is een ander "object 1"object. Analoog is B1 een mogelijk "object 2"- object en B2 een ander mogelijk "object 2"- object . De mogelijke combinaties zijn: - een object A1 komt voor in combinatie met object B1, - hetzelfde object A1 kan ook voorkomen in combinatie met een ander object uit de B-categorie: B2 en omgekeerd: - een object B1 komt voor in combinatie met object A1, - hetzelfde object B1 kan ook voorkomen in combinatie met een ander object uit de A-categorie: A2 Omdat er een "dubbeltelling" voorkomt zijn de verschillende mogelijke combinaties: - A1 in combinatie met B1 (deze combinatie kwam dubbel voor) - A1 in combinatie met B2 - B1 in combinatie met A2, wat hetzelfde is als: A2 in combinatie met B1.

Werkwijze/toelichting Kies als 'begininvulling' van de relatie de combinatie van objecten A1 en B1. A1 en B1 zijn zogenaamde 'surrogaatobjecten', dat wil zeggen dat je je op dit moment niet druk maakt over de vraag wat die objecten nu precies zijn; het ene is een object uit de A-categorie en het andere een object uit de B-categorie. Ga na of deze invulling van objecten in de relatie geoorloofd is. In dit geval van de begininvulling is het antwoord altijd: "ja, deze combinatie van objecten is geoorloofd". Kies als vervolginvulling van de relatie de combinatie van objecten A1 en B2. Ga na of deze invulling van objecten in de relatie geoorloofd is, rekening houdend met wat er in de eerdere regel van de tabel, die reeds is geprobeerd, als resultaat staat. Als deze combinatie niet geoorloofd is, streep dan deze regel in de tabel door. Probeer achtereenvolgens van alle regels uit de VOORBEELDTABEL 1 of de betreffende combinatie van objecten in de relatie geoorloofd is, rekening houdend met wat er in eerdere regels van de tabel, die reeds zijn geprobeerd, als resultaat staat. Het criterium voor wel of niet geoorloofd zijn van een volgende combinatie op een regel in de tabel is dus of het mogelijk is om - gegeven de rollen (rol1 en rol2) die de objecten spelen - een dergelijk samenstel van combinaties in de tabel te hebben. Dus bijvoorbeeld: kan object A1 zowel in relatie met een object B1 als met een ander object B2 voorkomen? Zo ja, dan kan de tweede regel gewoon blijven staan, zo nee dan wordt deze doorgestreept. In geval van een binaire relatie is het resultaat van de "strepen en tellen"-methode een tabelletje met drie (al dan niet doorgestreepte) regels.




Aflezen conclusie Rol 1 is uniek wanneer in de kolom van rol1 de niet doorgestreepte objecten allemaal verschillend zijn. Rol 2 is uniek wanneer in de kolom van rol2 de niet doorgestreepte objecten allemaal verschillend zijn.

Voorbeeld: In de relatie tussen team en speler geldt - zoals wij hiervoor al zagen - de aantallenregel: een speler mag maar in één team spelen. In het informatie-structuurdiagram wordt dit als volgt aangegeven: met

van

TEAM

SPELER

Laten wij eens kijken hoe dit resultaat met de strepen-en-tellen-methode gevonden zou worden. Relatietabel: team speler met van _______________________

VOORBEELDTABEL 2

team1 speler1 team1 speler2 team2 speler1 _______________________

Werkwijze/toelichting: De combinatie van team team1 en speler speler1 op de eerste regel in de tabel is altijd geoorloofd. Nu moet de combinatie op de tweede regel gecontroleerd worden terwijl regel 1 in de relatie geoorloofd is: De rol 'met': De rol 'van': =>

team team1 mag zowel een speler speler1 (de combinatie op de eerste regel) als een speler speler2 (de combinatie op de tweede regel) hebben. twee verschillende spelers (speler1 en speler2) mogen in één team (team1) zitten.

De tweede regel mag dus blijven staan.

Nu de combinatie op de derde regel waarvan moet worden nagegaan of deze in samenstel met beide reeds gecontroleerde regels mag voorkomen: De rol 'met': De rol 'van':

team team2 mag een speler speler1 hebben. speler speler1 mag niet zowel in team team1 (eerste regel) als in team team2 (laatste regel) zitten. De derde regel is dus niet geoorloofd.

Schematisch (via een relatietabel): team met

speler van _

team1 speler1 team1 speler2 ====== team2 ======= speler1 ====== níet-toegestane regel wordt doorgestreept! _______________________




Aflezen conclusie: Rol 1 is uniek wanneer in de kolom van rol1 de niet doorgestreepte objecten allemaal verschillend zijn; rol1 ('met') is dus niet -uniek. Rol 2 is uniek wanneer in de kolom van rol2 de niet doorgestreepte objecten allemaal verschillend zijn; rol2 ('van') is dus uniek . In het informatie-structuurdiagram hiervoor staat dit aangegeven.

Secretariaat sportvereniging

Voorbeeld:

De informatieanalyse in het basisontwerp geeft een verder uitwerking van de informatie-structuurdiagrammen die in de fase definitiestudie gevonden zijn. Voor het voorbeeld van de sportvereniging staan deze diagrammen in het rapport definitiestudie sportvereniging dat als bijlage aan de fase definitiestudie is toegevoegd. Het tweede onderdeel van de informatieanalyse, gaat als eindresultaat een informatie-structuurdiagram opleveren, waarin aangegeven staat welke rollen wel of niet uniek zijn. De analyse vindt plaats door van elke rol na te gaan of deze wel of niet uniek is. Daarbij kan de 'strepen en tellen'-methode gebruikt worden.

Verenigingsadministratie Elk van de relaties in het informatiestructuurdiagram moet onderzocht worden op uniciteit. Voor de relatie tussen team en speler (de relatie: 'is team met speler' en 'is speler van team') hebben wij dat onderzoek reeds gedaan. Daarbij is gebruik gemaakt van de omstandigheid dat het in deze specifieke sportvereniging onmogelijk is dat een speler in twee teams zit. Bij het verdere onderzoek van de relaties moet je weten dat in deze specifieke sportvereniging geldt dat: - een team meerdere trainers kan hebben - een speler trainer kan zijn van meerdere teams - een speler maar in één team kan spelen (deze beperking hadden wij al gebruikt). - bij één adres hoort steeds precies één straat en één plaats. Na onderzoek van de overige relaties wordt het volgende eindresultaat gevonden (ga dat zèlf na):

Voornaam met / aanvoerder van Team (teamnaam)

heeft / van Speler

heeft / van

Achternaam heeft / van Straat_nr

speelt in

met / trainer van

/ van

Adres met

woont op

Plaatsnaam

/ van

met / van

met

Datum

/ van Klasse

met / van

Bondsnummer

is geboren op

Alle vier mogelijkheden van unieke en niet-unieke rollen in binaire relaties komen in dit diagram voor.



Oefening:


Wedstrijdadministratie

In het rapport definitiestudie staat het hiernavolgende informatie-structuurdiagram voor de wedstrijdadministratie. => Ga de uniciteit van de relaties na en geef de resultaten in het informatie-structuur-diagram weer.

van /...met...als speler1 Speler

Wedstrijd van /...met...als speler2

met

van / met met

/ van

/ van

van / op Datum Uitslag op / van Stand

bij

bij

/ met

/ met

...met...als score1

...met...als score2

/ van

/ van

Score (punten) Aantal_Wedstrijden

Totaalscore (punten)

N.B. waarschijnlijk is het je hierboven niet ontgaan, dat bij de relatie “Speler met/van Stand” de vraag op komt of wel dan niet ‘historische’ moeten worden bewaard. Vraag in zo’n geval steeds een domeindeskundige om raad!




Uniciteitsregels bij ‘ternaire’ (en i.h.a. ‘n-aire’) relaties In bijlage A bij het hoofdstuk over Definitiestudie hebben we ook kort gesproken over ‘ternaire relaties’ (en eventueel nog ‘hogere’ n-aire relaties). N.B. Ter herinnering: we hebben daarbij ook gesteld dat andere-dan-binaire relaties meestal om te zetten zijn in een combinatie van [meerdere] binaire relaties [door het introduceren van ‘tussen-objecttypen’] en dat dat in ieder geval toegestaan is als het taalgebruik binnen de onderhavige organisatie in die richting gaande verwoordingen toestaat.

Het bepalen van bestaande uniciteitsregels bij zulke n-aire relaties kan op dezelfde wijze gebeuren als bij de door ons tot nog toe beschouwde binaire relaties. Kledingzaak “Modieus”

We beschouwen opnieuw het daar besproken voorbeeld van de kledingzaak, waarvan we hier de eerder gebruikte verkoopbon tonen, de verwoording van (alleen) de ternaire relatie geven en vervolgens ook het deel-informatie-structuurdiagram tonen voor zover dat op die ternaire relatie betrekking heeft.

Verkoopnr: N307421

Verkoper: 3 Datum: 20-03-2003 Aantal Artikelnr 2 1 2

A3024 A3072 B1035

Artikelnaam broek broek trui

Stukprijs

Bedrag

34,95 43,50 27,50

69,90 43,50 55,00

Totaalbedrag:

Algemene verwoording:

168,40

Verkoop (verkoopnr) van Artikel (artikelnr) betrof Aantal stuks. en het overeenkomstige gedeelte van het ORM-conceptueel schema: Artikel (artikelnr)

Verkoop (verkoopnr)

Aantal ...van ... betrof ... stuks

Ook hier kunnen we de strepen-en-tellen-methode toepassen. Relatietabel:

stel: mag dan:

Verkoop

Artikel

N307421 N307421

A3024 A3024

Aantal 2 5

?

en als de chef dan zegt: “Nee; elk artikel mag bij onze zaak maar één keer op eenzelfde verkoopbon staan”, dan mag die 2e regel niet en is blijkbaar de combinatie van de linkse en de middelste rol uniek en kan er een uniciteitspijl over die 2 rollen. Als hij echter zegt: “Ja, dat is geen enkel probleem”, dan moeten we verder gaan met b.v.: mag dan ook: N307421 B1035 2 ? en de chef zal zeggen: “Ja; kijk zelfs maar op die bon; daar staat dat al!” en mag dan ook: N123456 A3024 2 ? en de chef zegt: “Graag zelfs, want dan zouden we dat artikel ook aan andere klanten verkopen!”. Kortom: de uniciteitsregel-situatie kunnen we hier blijkbaar schematisch als volgt weergeven: Artikel (artikelnr)

Verkoop (verkoopnr)

Bedrag ... van ... voor ...




In het algemeen is voor het bepalen van uniciteitsregels voor een n-aire relatie (met in totaal ‘n’ rollen) de aanpak als volgt: • probeer eerst of er een uniciteitsregel geldt voor combinaties van n-1 rollen (dat kunnen er méérdere zijn!) • voor elke gevonden uniciteitsregel over n-1 rollen proberen we of ook niet een gedeelte van die combinatie van n-1 rollen al een sterkere uniciteitsregel (lees: een kortere uniciteitspijl) oplevert. Bij het vinden van een kortere uniciteitspijl, vervallen alle eerder gevonden langere uniciteitspijlen. • als we bij een n-aire relatie een uniciteitsregel vinden over minder dan n-1 rollen, dan betekent dat, dat we géén elementaire feitexpressies voor onze verwoording hebben gebruikt en dat de n-aire relatie zal moeten worden opgesplitst in meerdere kortere (dit is de zogenaamde ‘n-1’-regel waaraan voldaan moet zijn om überhaupt een correct conceptueel schema te kunnen hebben). We geven nu van dat laatste (controle via de ‘n-1’-regel) een voorbeeld, waarbij we een begane analyse-fout opsporen en corrigeren. Stel je daarbij voor, dat we voor het op een bepaald adres wonen van een persoon een verwoording hadden gebruikt als: Persoon “Jan Jansen” woont op Straat “Annastraat 123” te Plaats “Nijmegen” dan kan voor het opstellen van een relatietabel de vraag zijn: “Is dan ook toegestaan:” Persoon “Jan Jansen” woont op Straat “Graafseweg 123” te Plaats “Nijmegen” en dan zal het antwoord zijn: “Neen, want hij woont al op de Annastraat...” En op de vervolgvraag of ook toegestaan is: Persoon “Jan Jansen” woont op Straat “Annastraat 123” te Plaats “Maastricht” zal het antwoord zijn: “Neen, want hij woont al in Nijmegen en kan maar in één plaats tegelijk wonen!” [dat wil zeggen: het informatiesysteem staat maar één adres van die persoon toe]. Het bovenstaande betekent, dat er een klein uniciteitspijltje over alleen de rol bij Persoon zou komen te staan: Straat

Persoon

Plaats ...woont op...te...

foutief (volgens n-1-regel!) en volgens de n-1-regel is dit niet toegestaan en verwijst dit naar het gebruik van een niet-elementaire feit-expressie. Een verbeterde (correcte) verwoording is daarom de volgende combinatie van twéé expressies: Persoon “Jan Jansen” woont op Straat “Annastraat 123” Persoon “Jan Jansen” woont te Plaats “Nijmegen” hetgeen leidt tot het volgende, wèl correcte schema: Straat Persoon

woont op Plaats woont in

wèl correct

Kortom: indien je voor je conceptuele schema ‘ternaire’ (en/of hogere ‘n’-aire) relaties hebt gevonden, controleer dan steeds zeer goed via uniciteitsregel-bepaling en controle van het gevonden resultaat met de n-1-regel of het gevonden resultaat wel kan kloppen. Als je merkt dat ingegaan wordt tegen die n-1-regel, dan is er bijna zeker òf iets fout gegaan bij de verwoording òf bij het bepalen van de uniciteitsregel.




Identificatie van álle entiteit-objecttypen en bepaling [voorlopige] database-structuur Voordat we aan SDM-activiteit 2.4 kunnen beginnen (of beter: voordat we die activiteit geheel kunnen afmaken) dienen we eerst een [ruwe] voorlopige database/tabelstructuur voor ons te bouwen informatiesysteem te bepalen. Daardoor zullen we in activiteit 2.4 kunnen aangeven van welke gegevenstabellen de diverse basisfuncties gebruik zullen gaan maken. Om zo’n [voorlopig ruw bepaalde] database/tabelstructuur te kunnen bepalen, moeten we nog: a) voor zover dat nog niet gebeurd is: alle ‘entiteit’-objecttypen (de niet-value-typen) dienen eenduidig geïdentificeerd te kunnen worden door ‘values’ (je kunt immers geen ‘begrippen’ zoals ‘Persoon’, ‘Plaats’, ‘Adres’ e.d. in een informatiesysteem stoppen, maar alleen ermee geassocieerde values -zoals getalswaarden, strings, booleans. Zo’n identificatie van entiteiten kan gebeuren via: i) een één-op-éénrelatie; ii) een reference code; en iii) een unieke combinatie van waarden. b) mapping van een conceptueel (ORM-) schema naar een relationele database/tabelstructuur gebeurt zodanig, dat er géén redundantie [= een meermalen voorkomende opslag van eenzelfde feit] optreedt en [liefst] in zo weinig mogelijk relationele tabellen. ad a) Identificatie van alle entiteit-objecttypen Stel je de volgende situatie voor: Naam

Voornaam heeft

heeft

Hond heeft

Achternaam

Hondenras van

heeft

SoFinummer

Straatnaam Persoon

met

Adres

met Huisnr

woont op met

Jaar (jaartal)

is beboet in

aanslag hondenbelasting

Bedrag (euro)

Plaatsnaam met

Dit conceptuele schema is bedoeld voor de opzet van een gemeentelijk hondenbelastings-informatiesysteem. Een persoon kan meerdere honden hebben, maar een hond maar één baas (gezien het Universe of Discourse kunnen we hier beter zeggen: één eigenaar die de hondenbelasting moet betalen). Zo’n hondeneigenaar kan in meerdere jaren beboet zijn wegens poging tot ontduiking van de hondenbelasting (let op de brede uniciteitspijl tussen ‘Persoon’ en ‘Jaar’). We zien in dit conceptuele schema, dat er 3 nog niet uniek geïdentificeerde entiteiten in voorkomen (let wel: de entiteit ‘Bedrag’ heeft als reference code [aantal] ‘euro’ en is daarmee al geïdentificeerd). Er resteren dus ter identificatie: ‘Persoon’, ‘Hond’ en ‘Adres’. a) identificatie van ‘Persoon’: Het ligt voor de hand om de één-op-één-relatie tussen Persoon en Sofinummer te gebruiken om het begrip ‘Persoon’ mee te identificeren; ieder persoon heeft immers een uniek sofinummer en elk bestaand sofinummer verwijst uniek naar één persoon. b) identificatie van ‘Hond’: Voor ‘Hond’ bestaat in ons schema geen 1:1-relatie [en er lijkt ook geen unieke combinatie van feiten te bestaan]. Hoe nu? Gelukkig kan een domeindeskundige van dit UoD ons uit de brand helpen; zij geeft aan, dat een hond een unieke code op zijn honden[belasting]penning heeft staan. Kortom: probleem opgelost: we gebruiken de hondenpenningcode als reference code voor elke hond. c) identificatie van ‘Adres’: We weten dat een adres uniek vastgelegd wordt de combinatie van straatnaam+huisnr+plaatsnaam. We zullen deze combinatie ter identificatie van ‘Adres’ gebruiken. In ons conceptuele schema geven we dat aan met een omcirkelde ‘u’, die met stippellijntjes met de verschillende rollen wordt verbonden (in dit geval gebruiken we zelfs een omcirkelde ‘P’, hetgeen staat voor primary identification).




Het resultaat is hierna aangegeven: Naam

Voornaam Hond (penningcode)

heeft heeft

Achternaam

heeft Hondenras van

heeft

SoFinummer

Straatnaam Persoon

met

Adres

met

P Huisnr

woont op met

Jaar (jaartal)

is beboet in


Bedrag (euro)

Plaatsnaam met

Voor het vergemakkelijken van het overzicht over hoe we uit dit ORM-schema een (ruwe) structuur van een geschikte relationele database kunnen bepalen, gaan we de hiervoor gevonden/gekozen identificaties van die entiteiten binnen de ‘bol’ van het object trekken: Naam

Voornaam Hond (penningcode)

heeft heeft

Achternaam

Hondenras van

heeft

Adres (straatnaam+ huisnr+plaatsnaam)

Persoon (SoFinummer) woont op Jaar (jaartal)

heeft

is beboet in


Bedrag (euro)

We zijn nu klaar voor het bepalen van een [voorlopige, ruwe] tabel- en database-structuur.

ad b) ‘Relational mapping’ van het (ORM-) conceptuele schema naar een tabel/dabasestructuur We moeten ons voor deze ‘mapping’-procedure [in deze voorlopige, ruwe benadering] geheel en al baseren op de in het conceptuele schema aangegeven uniciteitspijlen. 1) Daarbij moet eerst gekeken/gezocht worden naar de ‘brede’ uniciteitspijlen (over méér dan slechts één rol), zoals in voorgaand hondenbelastingsvoorbeeld er een staat boven de relatie ‘Persoon is beboet in Jaar’. Elke ‘brede’ uniciteitspijl levert een aparte relationele gegevenstabel op, met als kolommen de gegevens die onder de (combinatie van) rollen in de relatie staan en als sleutel de combinatie van rollen/kolommen zoals die onder die ‘brede’ uniciteitspijl staan. N.B. omdat ternaire en hogere relaties ook een ‘brede’ uniciteitspijl [over méér dan één rol] hebben, zullen ternaire en hogere relaties altijd resulteren in een aparte tabel in de database.

2) Vervolgens beschouwen we de ‘smalle’ uniciteitspijlen en combineren alle 1:n-relaties (gezien vanuit een centraal object; dus daarbij alleen kijkend naar de kleine uniciteitspijlen die van de kant van dat centrale object staan). Omdat het hierbij gaat om 1:n-relaties, waarbij dat centrale object dus steeds met één waarde van het object aan de andere kant van de betreffende relatie is verbonden, kunnen we al deze waarden samen met de identificerende waarde van dat centrale object in een afzonderlijke relationele tabel opslaan. De kolom met de identificerende waarde van dat centrale object zal daarbij de ‘sleutel’ van die tabel worden.




We schetsen deze aanpak in het besproken hondenbelastings-conceptuele schema:

Ga nu zelf na, dat het resultaat van dit [voorlopige, ruwe!!!] mappingsproces een combinatie is van de volgende 3 relationele tabellen ‘Persoon’, ‘Hond’ en ‘Persoon beboet in Jaar’:

Persoon beboet in Jaar PK SoFinummer PK Jaartal

Persoon PK SoFinummer Achternaam Voornaam Straatnaam Huisnr Plaatsnaam Aanslagbedrag

Hond PK Hondenpenningcode SoFinummer eigenaar Naam hond Hondenras

In dit overzicht is per tabel ‘boven de streep’ (voorafgegaan door ‘PK’ van primary key) de primaire sleutel van die tabel aangegeven; de primary key-waarde van een record is de unieke waarde waarmee dat record van die tabel (en daarmee het ‘er achter zittende object’) geïdentificeerd kan worden. Let op: in de volgende SDM-fase (fase 4: Detailontwerp) gaan we ons [ORM-] conceptuele schema verder uitwerken en voorzien van alle binnen het betreffende Universe of Discourse geldende beperkingsregels. Daar ook zullen we zien dat relationele mapping van een compleet, gedetailleerd ORM-datamodel een gedetailleerdere database-structuur oplevert, waarbij ook de samenhang tussen de verschillende tabellen en de daartussen geldende constraints duidelijk wordt.




Bijlage BO - b) Basisfunctiestructuur bepalen:1) specificatie functionele eisen We gaan de 'geconcretiseerde informatiewensen' uit de Definitiestudie (b.v. toon factuur van klant ) verder uitwerken. Daarbij wordt voor toekomstige gebruikers duidelijk vastgelegd, wat voor acties later van henzelf verwacht worden (b.v. wat moeten ze precies doen om die factuur van een klant te zien te krijgen? moeten ze een adres of een klantnaam of een klantnummer invoeren?) en welke acties het systeem moet uitvoeren. N.B.

Dit verduidelijkt ook de bij activiteit 2.2 bekeken interactie tussen de te automatiseren delen en de handmatige delen van het toekomstige informatiesysteem. De toekomstige werkomgeving wordt immers deels ook vastgelegd door aan te geven welke basisfuncties de gebruiker of gebruikster in het informatiesysteem beschikbaar zal hebben om zijn of haar taken uit te voeren. De basisfuncties zijn het gereedschap waarmee de gebruiker of gebruikster zijn of haar werk doet; deze functies vormen een onderdeel van de werkomgeving.

per basisfunctie Bovendien moet nu niet alleen duidelijk worden welke gegevens worden ingevoerd, maar ook welke gegevens uit de databank 'gebruikt' (geraadpleegd) gaan worden. Inzicht in dat raadplegen van gegevens is beslist ook nodig om te kunnen beoordelen of we het systeem in onderdelen kunnen splitsten (en zo ja: welke).

Basisfuncties In de definitiestudie is de informatiebehoefte beschreven van de toekomstige gebruikers waarvoor wij een informatiesysteem bouwen (activiteit 1.2). Deze beschrijving heeft een vorm die nauw aansluit bij het beeld dat de gebruiker van de werkelijkheid heeft, omdat met behulp van de informatie-structuurdiagrammen van de gebruikerswerkelijkheid 'zinnetjes' zijn gemaakt die de informatiebehoefte beschrijven.

Voorbeeld:

factureringsafdeling

In het factureringsvoorbeeld was de werkelijkheid van de gebruiker via (een lichte variant op) het volgende informatie-structuurdiagram vastgelegd:

artikel

bedrag

datum

van

van

van

voor

met

op

van

met

klant

factuur

met van

adres

straat

met

met

met

met

in

in

in

in

huis


postcode

woonplaats



Zoals besproken was een voorbeeld van een informatiebehoefte in die werkelijkheid: 'Waar woont (wat is het adres van) de klant die factuur .... heeft gekregen?' Deze informatievraag is in de Definitiestudie-fase vertaald in termen van de objecten en de relaties uit het informatie-structuurdiagram tot: 'Toon adres van klant met factuur ....' Ook waren er mogelijkheden om de gegevens in het informatiesysteem in te brengen en up to date te houden. Dat betekent opdrachten tot toevoegen, verwijderen en muteren (corrigeren of wijzigen) van de bijbehorende gegevens. Bij de omschrijving van de gewenste informatievoorziening in activiteit 1.2 (definitiestudie) zijn ook deze noodzakelijke voorzieningen meegenomen, bijvoorbeeld: Toevoegbehoefte: Mutatiebehoefte: Verwijderbehoefte:

'Voeg toe klant' 'Muteer adres van klant' 'Verwijder factuur'

De hiervoor noodzakelijke functies om aan deze toevoeg-, verwijderen mutatiebehoeften van de gebruikers te voldoen, moeten nu in activiteit 2.3 verder gespecificeerd worden. Daartoe worden alle geconcretiseerde informatiewensen zoals geformuleerd tijdens de Definitiestudie (inclusief het up to date houden van de gegevens) opgeschreven in de vorm van verder geëxpliciteerde basisfuncties.

Omdat we (zie ook de belangrijkste doelstelling van deze SDM-fase 2: komen tot een [mogelijke] opsplitsing van het informatiesysteem in [samenwerkende] onderdelen) willen we van alle basisfuncties aangeven met gegevens van welke (relationele) database-tabellen ze zullen werken. Daarom moeten we eerst via een identificatie van alle (nog niet-geïdentificeerde) entiteit-objecttypen overgaan tot een voorlopige mapping van ons ruwe conceptuele datamodel naar een relationele database-tabelstructuur. Voor ons voorbeeld van de factureringsafdeling geven we hier eerst de identificatie en vervolgens de ruwe, voorlopige database-tabelstructuur. Artikel (artikelnr)

Bedrag

Datum

van

met

op

/ voor

/ van

/ van

Klant

Factuur (factuurnummer)

(klantnummer) is voor / krijgt

Klantnaam met / van

heeft / van

Adres (straatnaam, huisnr, postcode, plaatsnaam)

N.B. We hebben hier niet erg correct ‘Adres’ geïdentificeerd door de gehele combinatie van straatnaam+huisnr+ postcode+plaatsnaam. We komen hier later op terug (en doe het zelf beter bij de ‘oefenopdracht’).




Bepaling van een (ruwe!) adekwate relationele database-tabelstructuur leidt tot (ga dit zelf na): Factuur PK Factuurnummer FK Klantnummer Artikelnr Bedrag Datum

Klant PK Klantnummer Klantnaam Straatnaam Huisnr Postcode Plaatsnaam

We hervatten nu onze taak om alle geconcretiseerde informatiewensen zoals geformuleerd tijdens de Definitiestudie op te schrijven in de vorm van verder geëxpliciteerde basisfuncties. Van alle basisfuncties wordt daartoe aangegeven: - van welke soort ze zijn (informatie verstrekken, toevoegen, verwijderen of muteren), - op welke tabellen (/objecten) ze betrekking hebben, - of er uit de betrokken tabellen/objecten een selectie gemaakt moet worden en - zo ja met welk selectiecriterium. Een selectiecriterium bij een basisfunctie duidt op een object waarmee het bij de basisfunctie betrokken object een relatie heeft (resp. de betrokken objecten een relatie hebben).

- een duidelijke functionele specificatie; daarin moet van zo'n functie het doel omschreven staan en de benodigde invoer en de op te leveren uitvoer. De beschrijving van de basisfuncties gaat dus heel wat verder dan het opschrijven van 'zinnetjes' zoals in activiteit 1.2 van de definitiestudie; de beschrijving van de basisfuncties is gedetailleerder en beslaat (impliciet) alle objecten, niet alleen de objecten op het bovenste niveau van de hiërarchie. Als voorbeeld nemen we hier een deel van de informatiewensen van de factureringsafdeling (voor een uitwerking van de rest verwijzen we naar het rapport Basisontwerp factureringsafdeling, wat in een andere bijlage van dit hoofdstuk is terug te vinden). Op grond van het informatie-structuurdiagram is (dat deel van) de gewenste informatievoorziening in het voorbeeld van de factureringsafdeling in de Definitiestudie-fase concreet vertaald in: - aan kunnen brengen van binnengekomen factuurgegevens op een factuur met een uniek volgnummer, een kopiefactuur kunnen archiveren: . Voeg toe factuur van klant . Toon facturen van klant . Verwijder factuur van klant . Muteer factuur van klant

Onze bij deze activiteit nieuw te maken lijst van basisfuncties ziet er dan als volgt uit: Specificatie basisfuncties naam soort betrokken selectiecriterium basisfunctie tabel(len) ______________________________________________________________________ factuur toevoegen

toev

factuur

Omschrijving: Bij het toevoegen van een factuur worden de factuurgegevens van die factuur ingevoerd in het factureringssysteem. Het systeem genereert zelf het factuurnummer en drukt een kopiefactuur en een verzendopdracht af. N.B. De gebruikster van het systeem hoeft dus níet via een klantnummer of zoiets een selectie(zoek)criterium op te geven!

Bij de realisering van deze basisfunctie (zie factureringsformulier) zal bij deze functie van klant alleen het klantnummer in de ‘factuur’-tabel ingevoerd gaan worden; in de ‘klant’-tabel hoeven we te niets veranderen.




Specificatie basisfuncties (vervolg) naam soort betrokken selectiecriterium basisfunctie tabel(len) ______________________________________________________________________ facturen tonen van klant

info

factuur

klant = gekozen klant(nummer)

Omschrijving: Bij het tonen van facturen van een klant worden alle factuurgegevens getoond van de facturen van de door de gebruiker aan te geven klant (het selectiecriterium is dus: klant = gekozen klantnummer).

N.B. de volgende basisfunctie werd niet gevraagd, maar stel dat ...: facturen tonen op datum info factuur

datum = gekozen datum

Omschrijving: Bij het tonen van facturen op datum worden alle factuurgegevens getoond van de facturen die zijn gefactureerd op de gekozen (en door de gebruiker in te tikken) datum. In de oorspronkelijk opgegeven informatiebehoefte werd alleen de behoefte gesignaleerd om facturen te tonen; nu nader gedetailleerd wordt naar selectiecriterium, blijken (bij doorvragen) twéé selectiecriteria gewenst te worden:

factuur verwijderen

verw

factuur

factuur = gekozen factuur klant = gekozen klant(nummer)

Omschrijving: Bij het verwijderen van een factuur worden de factuurgegevens van de gekozen factuur verwijderd uit het factureringssysteem. De te verwijderen factuur kan direct of indirect gekozen worden (door eerst de facturen van een bepaalde klant te kiezen en vervolgens weer uit een overzichtslijst de te verwijderen factuur te kiezen). N.B. In feite blijkt de informatiewens 'factuur verwijderen' dus twéé basisfuncties te vereisen!

factuur muteren

mut

factuur1

factuur = gekozen factuur klant = gekozen klant

Omschrijving: Bij het muteren van een factuur kunnen een aantal (d.w.z. alle, behalve het unieke factuurnummer) factuurgegevens van de gekozen factuur worden gecorrigeerd. Het systeem drukt vervolgens weer een kopiefactuur en een verzendopdracht af. De te muteren factuur kan weer direct of indirect worden gekozen. Ook hier blijkt deze informatiewens in feite dus twéé basisfuncties te vereisen! Met factuur1 bedoelen we hier, dat niet het (waarschijnlijk gegenereerde, identificerende) factuurnummer gemuteerd mag worden, maar wèl alle andere ‘onder’ factuur vallende gegevens (zoals artikelnummer, bedrag en/of datum).

factuur afdrukken

info

factuur klant

factuur = gekozen factuur klant = gekozen klant

Omschrijving: Voor het afdrukken van een factuur kan weer direct of indirect worden gekozen. De gebruiker kan een bepaald factuurnummer intikken, of via het intikken van een klantnummer eerst een overzicht krijgen van welke facturen er voor die klant bekend zijn en dan aan de hand van dat overzicht een keuze voor een bepaalde factuur opgeven. N.B. Ook hier blijkt deze informatiewens in feite dus twéé basisfuncties te vereisen!

Voor een volledige uitwerking verwijzen we naar de bijlagen met voorbeelden van Basisontwerp-rapporten. Daarna kan ook een conclusie getrokken worden over de doelstelling van deze fase: het al dan niet kunnen opsplitsen van het gehele systeem in deelsystemen.




Bijlage BO - c) Basisfunctiestructuur bepalen: 2) groeperen en menu's Om een duidelijk overzicht te kunnen krijgen van een complex informatiesysteem, zullen we bij elkaar behorende onderdelen op een 'logische' manier moeten groeperen. Die 'logische' manier zal in overleg met de gebruiker moeten worden bepaald. Meestal zal daarbij uitgegaan worden van de hoofdfuncties en wordt vandaar uit een verdeling gemaakt met erbinnen liggende functies en tot slot een verdere uitsplitsing van de functies in basisfuncties. Er ontstaat op zo'n manier een hiërarchie van hoofdfuncties, functies en uiteindelijk basisfuncties, met: Op het hoogste niveau (de hoofdfuncties): het hoofdmenu (het menu 'informatiesysteem') met een keuze uit een aantal mogelijkheden (de hoofdfuncties). De onder de hoofdfuncties liggende niveaus van (deel-)functies: dit zijn ook weer menu's met een keuze uit een aantal mogelijkheden (de functies). De basisfuncties liggen aan het einde van de vertakkingen in de structuur. Hieruit is later eenvoudig de 'echte' menustructuur voor het te bouwen informatiesysteem af te leiden. De op deze wijze gevonden (menu)structuur is vaak voor de gebruiker niet optimaal. In het dagelijks gebruik van het informatiesysteem worden ook andere criteria aangelegd dan structuurcriteria. Zo wil de gebruiker bijvoorbeeld dat het systeem er rekening mee houdt dat: - sommige functies veel vaker gebruikt worden dan andere, - bepaalde functies vaak in een vaste volgorde gebruikt worden, etc. Om dat soort redenen worden vaak in overleg met de gebruiker veranderingen in een voorlopig opgestelde structuur aangebracht die moeten leiden tot een beter gebruik van het informatiesysteem.

Voorbeeld:

functies in het factureringsinformatiesysteem

Als we bijvoorbeeld in eerste instantie voor de hoofdfunctie 'verzenden' de volgende (sub)functie-hiërarchie hadden opgesteld: 2

verzenden 2.1 2.1.1 2.1.2 2.1.3

klant veranderen (N.B. ook: adresgegevens van klant) klant toevoegen klant verwijderen klant muteren

2.2 2.2.1

informatie over klant klant tonen

2.3

informatie over factuur van klant factuur afdrukken

2.4 2.4.1

informatie over klant met factuur klant (inclusief adres) tonen met factuur

Dan zal het zeer waarschijnlijk door de gebruiker van de hoofdfunctie erg onhandig worden gevonden, dat er maar liefst vier functies zijn die alleen maar als tussenstap dienen bij het bereiken van de basisfuncties die informatie moeten leveren. Het is zeer waarschijnlijk dat de gebruiker in dit geval de voorkeur geeft aan de volgende (totale) structuur:




Functies in het factureringsinformatiesysteem (in overleg met gebruikers herzien) 1

2

factureren 1.1

factuur veranderen 1.1.1 factuur toevoegen 1.1.2 factuur verwijderen 1.1.3 factuur muteren

1.2

informatie over factuur 1.2.1 facturen tonen van klant 1.2.2 facturen tonen op datum

(stel dat ...)

verzenden 2.1

2.2

klant veranderen 2.1.1 2.1.2 2.1.3

klant toevoegen klant verwijderen klant muteren

verzendinformatie 2.2.1 factuur afdrukken 2.2.2 klant tonen 2.2.3 klant (inclusief adres) tonen met factuur

Samenvoegen van basisfuncties Naast het hergroeperen van (basis)functies kan het in overleg met de gebruiker ook nodig of efficiënter blijken basisfuncties samen te voegen om een beter gebruik van het informatiesysteem mogelijk te maken. Aanleidingen tot samenvoegen van basisfuncties kunnen zijn: bepaalde basisfuncties zullen naar verwachting (min of meer) dezelfde gegevens verwerken en de layout op een scherm zal overeenkomen. In dit geval kunnen (vooral bij een grafische user interface) deze functies binnen één window via aparte push buttons geactiveerd worden. Ook bij de uiteindelijke implementatie zal zo'n samenvoegen aanmerkelijke tijdwinst kunnen opleveren (het totaal van de in één scherm samengevoegde functies krijgt dan ook minder FPA-functiepunten dan de som van de afzonderlijke functies). Zo zouden de 3 klant-verander-functies (2.1.1, 2.1.2 en 2.1.3) misschien goed met 'klant tonen' (2.2.2) samen in één scherm kunnen worden opgenomen, of anders de toon-, muteer- en verwijder-mogelijkheden van klant. een bepaalde basisfunctie heeft géén selectiecriterium, terwijl een of meer andere basisfuncties met eenzelfde werking wel een selectiecriterium hebben. Dit geval kan zich bijvoorbeeld voordoen bij info rmatiefuncties; de ene basisfunctie geeft bijvoorbeeld een lijst van alle facturen, andere basisfuncties selecteren uit alle facturen er één op grond van een selectiecriterium. Samenvoegen heeft mogelijk het voordeel dat een extra menukeuze wordt vermeden. bepaalde basisfuncties hebben het zelfde selectiecriterium. In dit geval kan samenvoegen voordelen hebben, omdat het betreffende selectiecriterium maar éénmaal door de gebruiker hoeft te worden ingetikt. Ook bij samenvoegen geldt: de systeemontwerper inventariseert mogelijkheden tot samenvoeging, maar tot samenvoegen wordt besloten in samenspraak met de gebruiker(s) van het toekomstige systeem.

Mogelijke opsplitsing in deelsystemen: Op basis van de resultaten van de detaillering van de basisfuncties (bijlage BO-b) en het overzicht van gegroepeerde basisfuncties (uit deze bijlage BO-c), kan besloten worden of het totale systeem (indien gewenst) in kleinere deelsystemen kan worden opgesplitst.




Zo blijken de 3 klant-verander-functies (2.1.1, 2.1.2 en 2.1.3) en de 'klant tonen' (2.2.2) alle slechts als betrokken object 'klant' te hebben (en ze zoals boven gesuggereerd allen in één scherm kunnen worden ondergebracht). Het is dus goed mogelijk om dit onderdeel van het totale systeem af te splitsen en als een eerste deelsysteem verder te bouwen. Later kan dan als tweede deelsysteem de rest worden gebouwd. Menu-structuur De menuboom wordt, met behulp van de eerder bepaalde functiestructuur, in een aantal stappen opgebouwd. Eerst geven wij de samenhang tussen hoofdfuncties, functies en basisfuncties aan:

factureringsinformatiesysteem factureren

verzenden

factuur veranderen

klant veranderen

factuur toevoegen

klant toevoegen

factuur verwijderen

klant verwijderen

factuur muteren

klant muteren

verzendinformatie

informatie over factuur facturen tonen van klant

factuur afdrukken

facturen tonen op datum

klant tonen klant tonen met factuur

Afhankelijk van de wijze waarop het systeem later geïmplementeerd zal worden, kunnen we uit voorgaand overzicht een reeks van benodigde menu-schermen (of i.g.v. een pull-down-menusysteem: 'n menu-scherm) ontwerpen . De concrete invulling van deze schermen moet dus nog gemaakt worden (hangt o.a. af van de mogelijkheden van het concrete DBMS, dat we voor de implementatie gaan gebruiken). Zeker als er met proto-typing gewerkt wordt, is het uiterst gemakkelijk om hier al gelijk zo'n concrete uitwerking te geven van de wijze waarop menu-schermen zullen verschijnen.

Een implementatiewijze, die gemakkelijk in een GUI-omgeving (Graphical User Interface) kan worden toegepast, en die via pull-down-menu's werkt, kan de implementatie (en dus nu het ontwerp) als volgt zijn:

Factureren

Factureringsinformatiesysteem Verzenden Einde Klant veranderen Verzendinformatie

Factuur afdrukken Klant tonen Klant tonen met factuur

Als het werken met deze Window-menubalken e.d. níet mogelijk is en je met schermen in de tekstmode moet werken, dan zul je veel moeizamer de afzonderlijke menuschermen moeten gaan bepalen en bovendien de foutmeldingen die gegenereerd moeten worden indien een foutieve menukeuze wordt gemaakt.




In het geval van een 'reeks van menu-schermen' (voor bijvoorbeeld een character-based besturingssysteem/ programma) zullen die de hierna volgende menuboom als structuur hebben. Zo'n uitgewerkte menuboom, vergezeld van de uitgewerkte schermen, is vreselijk handig: niet alleen helpt de boom je bij het houden van overzicht in de nog volgende fasen van ontwerp en bouw, maar de boom vormt ook de ruggengraat voor de gebruikershandleiding die straks bij het kant en klare informatiesysteem moet worden opgeleverd.

factureringsinformatiesysteem

factureren

menu 0

verzenden

menu 1.1

factuur veranderen

klant veranderen

factuur toevoegen

klant toevoegen

factuur verwijderen

klant verwijderen

factuur muteren

klant muteren

menu 1.2

informatie over factuur

verzendinformatie

facturen tonen van klant facturen tonen op datum

menu 2.1

menu 2.2

factuur afdrukken klant tonen klant tonen met factuur

Aanvullend aan zo'n benodigde 'reeks van menu-schermen' moet o.a. nog worden bepaald op welke manier een gebruiker desgewenst een stapje terug in de menuboom-hiërarchie kan doen, hoe het systeem (met welke informatieschermen) moet reageren als een 'niet-bestaand' commando wordt gegeven en hoe de precieze schermlayout er uit zal zien. Bij het gaan werken met tekst-menuschermen moeten we de basisdialoog concreet en volledig invullen. Die basisdialoog beschrijft alle besturingsinteracties met de gebruiker in de vorm van een menuboom met bijbehorende uitgewerkte schermen. Op het ontwerpen van menu-schermen in een omgeving waarin met ‘tekstschermen’ wordt gewerkt, gaan we in deze cursus niet verder in.




Bijlage BO - d) Rapport Basisontwerp Factureringsafdeling UITTREKSEL Uitgangspunten Plan van aanpak Toekomstige werkomgeving Voor wat betreft de organisatorische implicaties van de toekomstige interactie tussen het geautomatiseerde en het handmatige deel van het informatiesysteem vermelden we allereerst, dat een van de uitgangspunten was, dat de huidige werkwijze zoveel mogelijk gehandhaafd moest blijven. Daarnaast geldt: - De factuurformulieren die op dit moment nog worden gebruikt zijn standaard al voorzien van een factuurnummer. Net als voorheen wil het personeel van de factuurafdeling de factuurnummers in de toekomst niet intikken, maar men wil er wel mee kunnen werken. Het systeem komt daarin tegemoet door zelf factuurnummers te genereren. Als echter de huidige factuurformulieren ook in de toekomst worden gehanteerd komen de factuurnummers die worden gegenereerd door het systeem hoogst waarschijnlijk niet overeen met de factuurnummers die standaard al op het factuurformulier staan. Daarom zullen er in de toekomst factuurformulieren gebruikt moeten worden die niet al standaard zijn voorzien van een factuurnummer, zodat het systeem daar het gegenereerde factuurnummer neer kan zetten. - Iedere middag om 17.00u maakt de systeembeheerder een print van alle op die dag toegevoegde facturen. - Iedere vrijdagmiddag zal de systeembeheerder een back-up maken van alle gegevensbestanden. - De medewerkers van de factureringsafdeling moeten een MS Windows-gebruikerscursus volgen.

Basisgegevensstructuur Het bij het rapport Definitiestudie gegeven informatiestructuurdiagram is voorzien van uniciteitspijlen: Artikel (artikelnr)

Bedrag

Datum

van

met

op

/ voor

/ van

/ van

Factuur (factuurnummer)

is voor /krijgt

Klant (klantnummer)

Klantnaam met / van

heeft / van met / van

Straat (straatnaam)

Huisnr

Adres met / van

Postcode met / van Woonplaats (plaatsnaam) met / van




Identificatie en bepaling van een (ruwe!) relationele database-tabelstructuur leidt tot de volgende twee benodigde tabellen: Factuur PK Factuurnummer FK Klantnummer Artikelnr Bedrag Datum

Klant PK Klantnummer Klantnaam Straatnaam Huisnr Postcode Plaatsnaam

Kwantitatief: Het aantal klanten/adressen bedraagt momenteel ca. 600, maar het systeem moet een groei tot 1000 zonder problemen aankunnen. Gehoopt wordt op een toename van 100 klant/adressen per jaar. Het aantal klant/adreswijzigingen zal ook in deze orde van grootte liggen. Het aantal facturen bedraagt momenteel ca. 4000 per jaar; een groei tot 7000 per jaar moet zonder problemen haalbaar zijn. Deze zelfde aantallen gelden uiteraard voor het toevoegen èn verzenden van facturen! Factuurgegevens moeten gedurende 5 jaar direct toegankelijk blijven. In het facturenbestand moeten dus van enkele tienduizenden facturen de gegevens aanwezig kunnen zijn

Basisfunctiestructuur De volgende lijst van basisfuncties is een vertaling van de in het vorige rapport definitiestudie vastgelegde gewenste informatievoorziening en levert een specificatie van deze voorziening in de toekomstige werkomgeving. Voor bij elkaar behorende basisfuncties worden eerst de relevante objecten en gegevens met hun onderlinge hiërarchie weergegeven. Daarna volgt een specificatie van de basisfunctie naar: - naam - soort (toev oegen, verw ijderen, mut eren en info rmatie) - betrokken objecten van het hoogste niveau in de hiërarchie - selectiecriterium (bepaalde gegevenswaarde van een object waarop geselecteerd moet worden). - doel en werking

Specificatie basisfuncties: naam soort betrokken selectiecriterium basisfunctie tabel(len) ______________________________________________________________________ factuur toevoegen

toev

factuur

Omschrijving: Bij het toevoegen van een factuur worden de factuurgegevens van die factuur ingevoerd in het factureringssysteem. Het systeem genereert zelf het factuurnummer en drukt een kopiefactuur en een verzendopdracht af. facturen tonen van klant

info

factuur


Omschrijving: Bij het tonen van facturen van een klant worden alle factuurgegevens getoond van de facturen van de door de gebruiker aan te geven klant (het selectiecriterium is dus: klant = gekozen klantnummer).


info

factuur

datum = gekozen datum

Omschrijving: Bij het tonen van facturen op datum worden alle factuurgegevens getoond van de facturen die zijn gefactureerd op de gekozen (en door de gebruiker in te tikken) datum. factuur verwijderen

verw

factuur


factuur = gekozen factuurnr klant = gekozen klant(nummer)



Omschrijving: Bij het verwijderen van een factuur worden de factuurgegevens van de gekozen factuur verwijderd uit het factureringssysteem. De te verwijderen factuur kan direct of indirect gekozen worden (door eerst de facturen van een bepaalde klant te kiezen en vervolgens weer uit een overzichtslijst de te verwijderen factuur te kiezen). N.B. In feite blijkt de informatiewens 'factuur verwijderen' dus twéé basisfuncties te vereisen!

factuur muteren

mut

factuur1


Omschrijving: Bij het muteren van een factuur kunnen een aantal (d.w.z. alle, behalve het unieke factuurnummer) factuurgegevens van de gekozen factuur worden gecorrigeerd. Het systeem drukt vervolgens weer een kopiefactuur en een verzendopdracht af. De te muteren factuur kan weer direct of indirect worden gekozen. Ook hier blijkt deze informatiewens in feite dus twéé basisfuncties te vereisen! Met factuur1 bedoelen we hier, dat niet het (identificerende) factuurnummer gemuteerd mag worden, maar wèl alle andere ‘onder’ factuur vallende gegevens (zoals artikelnummer, bedrag en/of datum).

factuur afdrukken

info

factuur klant


Omschrijving: Voor het afdrukken van een factuur kan weer direct of indirect worden gekozen. De gebruiker kan een bepaald factuurnummer intikken, of via het intikken van een klantnummer eerst een op het scherm geproduceerde lijst krijgen van welke facturen er voor die klant bekend zijn en dan aan de hand van dat overzicht een keuze voor een bepaalde factuur opgeven. N.B. Ook hier blijkt deze informatiewens in feite dus twéé basisfuncties te vereisen!

klant toevoegen

toev

klant

Omschrijving: Bij het toevoegen van een klant worden de klantgegevens (NAW: naam, adres, woonplaats) van die klant ingevoerd in het factureringssysteem.

klant tonen

info

klant


Omschrijving: Alle klantgegevens (NAW) worden getoond.

klant verwijderen

verw

klant factuur


Omschrijving: Bij het verwijderen van een klant worden de klantgegevens van de gekozen klant verwijderd mits er voor deze klant geen factures meer in het systeem zijn opgeslagen.

klant muteren

mut

klant2


Omschrijving: Bij het muteren van klantgegevens kunnen de NAW-gegevens van de gekozen klant worden gecorrigeerd (dus níet het unieke klantnummer!). N.B. Met klant2 bedoelen we vanaf nu álle klantgegevens (inclusief de ‘lagerliggende’adresgegevens), met uitzondering van het identificerende klantnummer.




Na een vergelijking van de direct geuite informatiewensen met de (volgens het datamodel ) theoretisch mogelijke functies (zie bijlage DS-f van het B3-collegedictaat) waren daar, na overleg met de opdrachtgever en de toekomstige gebruikers, aan het repertoire van basisfuncties toegevoegd: klant tonen met factuur

info

factuur

factuur = gekozen factuur

Omschrijving: Alle gegevens van de geselecteerde factuur worden getoond en dus tevens het klantnummer van de klant van wie de factuur is.

klant tonen met factuur

info

klant factuur

klant = gekozen klant factuur = gekozen factuur

Omschrijving: Alle (NAW) klantgegevens van de klant van wie de geselecteerde factuur is, worden getoond. De factuur kan direct of indirect (door eerst de facturen van een klant met een bepaalde naam te kiezen en daaruit weer de bedoelde factuur te kiezen) gekozen worden .

Mogelijke opsplitsing in deelsystemen Op basis van de voorgaande detaillering van de basisfuncties en dan specifiek van de opgegeven 'betrokken tabel(len)' (b)lijkt het mogelijk om het totale factureringssysteem op te splitsen in twee afzonderlijk te bouwen deelsystemen. Het eerste, onafhankelijk te ontwikkelen deelsystemen kan dan bestaan uit die onderdelen die alleen met de tabel (het object) 'klant' te maken hebben. Dat zijn de basisfuncties: 'klant toevoegen', 'klant tonen' en 'klant muteren'. Indien gewenst kan in een tweede deelproject dan de overige functionaliteit ontworpen en gerealiseerd worden.

Veranderingen Aangezien het geautomatiseerde factureringssysteem voor iedere factuur zelf een uniek factuurnummer genereert zal er in de toekomst gebruik gemaakt gaan worden van factuurformulieren die niet al standaard zijn voorzien van een factuurnummer. Bij het (automatisch) afdrukken van een factuur zal op de positie waar eerst het voorgedrukte factuurnummer stond nu het door het factureringssysteem gegenereerde factuurnummer worden neergezet.

Structuur van de (hoofd- en basis)functies De basisfuncties zijn op de volgende wijze (via functies) ondergebracht bij de hoofdfuncties: functies in het factureringsinformatiesysteem (opzet na overleg met gebruikers): 1

factureren 1.1 factuur veranderen 1.1.1 factuur toevoegen 1.1.2 factuur verwijderen 1.1.3 factuur muteren 1.2

2

informatie over factuur 1.2.1 facturen tonen van klant 1.2.2 facturen tonen op datum

verzenden 2.1 klant veranderen 2.1.1 2.1.2 2.1.3 2.2

klant toevoegen klant verwijderen klant muteren

verzendinformatie 2.2.1 factuur afdrukken 2.2.2 klant tonen 2.2.3 klant (inclusief adres) tonen met factuur




Menuboom Op basis van de structuur van de functies zoals hiervoor aangegeven is een menuboom met bijbehorende menuschermen ontworpen: factureringsinformatiesysteem

factureren

menu 0

verzenden

factuur veranderen

menu 1.1

klant veranderen

factuur toevoegen

klant toevoegen

factuur verwijderen

klant verwijderen

factuur muteren

klant muteren

menu 1.2

verzendinformatie

informatie over factuur

menu 2.1

menu 2.2

factuur afdrukken

facturen tonen van klant

klant tonen


klant tonen met factuur

Een implementatiewijze, die gemakkelijk in een GUI-omgeving (Graphical User Interface) kan worden toegepast, en die via pull-down-menu's werkt, kan de implementatie (en dus nu het ontwerp) als volgt zijn:

Factureren

Factureringsinformatiesysteem Verzenden Einde Klant veranderen Verzendinformatie

Factuur afdrukken Klant tonen Klant tonen met factuur

Als het werken met deze Window-menubalken e.d. níet mogelijk is en je met schermen in de tekstmode moet werken, dan zul je veel moeizamer de afzonderlijke menuschermen moeten gaan bepalen en bovendien de foutmeldingen die gegenereerd moeten worden indien een foutieve menukeuze wordt gemaakt. Gezien het voornemen het informatiesysteem te ontwikkelen voor een grafische omgeving werken we deze mogelijkheid hier verder niet uit. Technische vormgeving + Gedetailleerd projectenplan Ondanks het bestaan van de eerder aangegeven mogelijk om het totale informatiesysteem in twee deelsystemen op te splitsen, is in overleg met de opdrachtgever bepaald, dat het verdere ontwikkelingsproject toch het gehele systeem zal behelzen. Het apart ontwikkelen van deze deelsystemen is immers weinig zinvol. Dat eerste deelsysteem kan los alleen gebruikt worden om bijvoorbeeld reclamefolders op te sturen (b.v. met een mailing ), maar als dan een week later de bestellingen binnenkomen, dan zou toch zeker deel 2 klaar moeten zijn. Bovendien is het totale systeem weinig complex, zodat een opsplitsing niet per se noodzakelijk is. Voorgesteld wordt daarom om het systeem toch als een geheel te ontwikkelen. De planning is qua tijd: - detailontwerp-fase van .... tot ... ; bespreking rapport Detailontwerp op .... - realisatie-fase van .... tot ... - systeemtest op ... - aanschaf van de volgende hardware: .... in de eerste week van de maand ... - aanschaf van de volgende software: .... (vanaf nu direct)

Einde UITTREKSEL Rapport Basisontwerp factureringsafdeling N.B. In jullie rapport dient ook een evaluatie + overzicht tijdsbesteding (ook van het totaal tot nu toe) komen.


Bijlagen A bij hoofdstuk IV over Basisontwerp

Recommend Documents