[ALG] Ontwerp van een databaseprogramma

[TweakersOnly]

Voor m'n stage moet ik een ASP-applicatie maken, waarin het verlof, adv-dagen en ziektedagen ed kunnen worden beheerd. Dit programma is afhankelijk van de CAO waarin iemand is ingedeeld, daarom moet de database zo generiek mogelijk zijn. De ontwerp van de databasestructuur en een beschrijving van de functionaliteitseisen van het programma heb ik inmiddels op papier staan.

Vandaag is m'n schoolbegeleider gekomen en volgens hem moet er nog 't een en ander van ontwerp bij, zodat het ook echt duidelijk wordt, waarom de database zo generiek is. Welke modelleermethoden kan ik gebruiken, om het programma zo goed mogelijk te ontwerpen. UML is volgens mij onmogelijk, omdat deze methode alleen voor OO programma's bedoeld is.

Welke onderdelen worden in het bedrijfsleven eigenlijk gebruikt om een goed ontwerp van een applicatie, zoals die van mij, op te zetten?

[TweakersOnly]

Inmiddels heb ik 'n beetje op het net gesurfd en heb ik een volgende aanpak gevonden, deze werkt volgens de KISS methodiek:
- Textuele beschrijving huidige situatie

- Textuele beschrijving gewenste situatie
- Structuurzinnen
- Lijst van objecten,subjecten,acties,verantwoordelijkheden
- Informatiekwadrant
- Object Interactiemodel
- LGS / GSD
- Takentabel
- Datadictionary

Zijn hier nog op- of aanmerkingen over, of is dit inderdaad een goed ontwerp voor een ASP-applicatie?

[raptorix]

Leuk en aardig maar kost bakken met tijd, zorg dat je goed snapt wat er in je DB moet komen, zet gewoon je DB op papier op of in een geschikt programma (visio,dataarchitect,etc) vervolgens leg je het ontwerp voor aan de gene waarmee je te maken hebt, dan ga je brainstormen of eventuele situaties wel geschikt zijn voor je database model etc.

Wat jij nu allemaal wil gaan doen riekt naar bureaucratie en papierwerk.

[Verwijderd]

Op donderdag 07 februari 2002 12:16 schreef raptorix het volgende:
Leuk en aardig maar kost bakken met tijd, zorg dat je goed snapt wat er in je DB moet komen, zet gewoon je DB op papier op of in een geschikt programma (visio,dataarchitect,etc) vervolgens leg je het ontwerp voor aan de gene waarmee je te maken hebt, dan ga je brainstormen of eventuele situaties wel geschikt zijn voor je database model etc.

Wat jij nu allemaal wil gaan doen riekt naar bureaucratie en papierwerk.

De enige methode die ik ken is de SDM, misschien kun je daar wat documentatie over vinden. Het is een uitgebreide methode die volgens mij wel compleet is. Prototyping kan altijd nog

[TweakersOnly]

Op donderdag 07 februari 2002 12:16 schreef raptorix het volgende:
Leuk en aardig maar kost bakken met tijd, zorg dat je goed snapt wat er in je DB moet komen, zet gewoon je DB op papier op of in een geschikt programma (visio,dataarchitect,etc) vervolgens leg je het ontwerp voor aan de gene waarmee je te maken hebt, dan ga je brainstormen of eventuele situaties wel geschikt zijn voor je database model etc.

Wat jij nu allemaal wil gaan doen riekt naar bureaucratie en papierwerk.

Ja, zo denk ik er ook over. Ik snap de databasestructuur van het programma heel goed, ik heb de structuur ook al uitgewerkt in Visio en dit aan de leraar gegeven. Ook heb ik hem een Word-document (4 pagina's lang) gegeven, waarin een textuele beschrijving van het te realiseren programma staat, incl. de doelstellingen en de functionaliteitseisen.

Volgens de leraar was dit allemaal nog veel te summier, hij wilde weten waarom de databasestuctuur zo goed en generiek was. Kortom, hij wilde diagrammen zien. Tenminste, dat denk ik...

Dit is mijn afstudeerstage, dus ik moet toch de leraar een beetje te vriend houden, hij beoordeelt mij namelijk ook.

[TweakersOnly]

Informatie over SDM heb ik trouwens gevonden op http://www.zbc.nu/main.asp?ChapterID=420

[raptorix]

Op donderdag 07 februari 2002 13:05 schreef TweakersOnly het volgende:

[..]

Ja, zo denk ik er ook over. Ik snap de databasestructuur van het programma heel goed, ik heb de structuur ook al uitgewerkt in Visio en dit aan de leraar gegeven. Ook heb ik hem een Word-document (4 pagina's lang) gegeven, waarin een textuele beschrijving van het te realiseren programma staat, incl. de doelstellingen en de functionaliteitseisen.

Volgens de leraar was dit allemaal nog veel te summier, hij wilde weten waarom de databasestuctuur zo goed en generiek was. Kortom, hij wilde diagrammen zien. Tenminste, dat denk ik...

Dit is mijn afstudeerstage, dus ik moet toch de leraar een beetje te vriend houden, hij beoordeelt mij namelijk ook.

Vergeten dat leraren kicken op papier winkeltjes

[Verwijderd]

Op donderdag 07 februari 2002 13:33 schreef raptorix het volgende:
[..]
Vergeten dat leraren kicken op papier winkeltjes

haha ja ik ken dat
maar tis opzich wel goed om van te voren heel duidelijk te stellen wat en hoe je het wil gaan doen, ook al heb JIJ het nog zo goed in je hoofd, je loopt later echt tegen dingen aan die je niet had voorzien, dat is vaak op voorhand al op te lossen.
Ik ben zelf ook nie super voorstander van SDM enzo, maar bij me laatste project voor school is het me toch echt wel duidelijk geworden dat het zeker wel nut heeft
Succes!

[farlane]

Volgens mij kan UML voor een database ontwerp ook wel gebruikt worden. Een tabel verschilt immers niet veel van een klasse.

Een onderdeel van UML is het Data Model en kan hiervoor goed gebruikt worden.

[Verwijderd]

Waarom gebruik je geen ERD's (Entity relationship Diagrams)? Deze geven de relaties tussen de diverse tabellen goed weer. Indien je ook nog de processen moet beschrijven raad ik je Hatley&Phirbai aan omdat die uitgaan van data driven processen.

[Verwijderd]

Gewoon ERD's maken jah.
Die zijn voor databases echt onmisbaar

[Badger]

Wat ik mij afvraag bij lezen van het bericht van de topicstarter:

Zou je daar geen les in moeten hebben gehad!?

UML is zoals eerder genoemd erg geschikt. Je kan naast de tussentabellen, klassen en attributen ook de acties erop en ook (zeer belangrijk) de relaties tussen de tabellen in een diagram kwijt.
Voor UML is het boek "Teach yourself UML in 24 hours" van uitgeverij Sams wel aardig. Staan een aantal cases/beschrijvingen in. (Is ook in het Nederlands verkrijgbaar)

Voorbeeld van een tabel uit het diagram:

wasmachine <-- was machine
----------
model <-- attribuut
serienummer
build by
productiedatum
----------
Wassen <-- operatie

(Wat nu volgt is geen UML)
Hieruit destileer je een relationeel model met daarin de vreemde (italic) en primaire (onderstreept) sleutels. Met daaronder welke vreemde sleutel naar welke primaire sleutel verwijst.

wasmachine(serienummer,build_by,kleur,productiedatum)

build_by_ references personeels_lid in personeel not NULL

Zodra je het datamodel hebt moet er nog genormaliseerd worden. (3 vormen + Boyce Cott)

Daarna kan je daar uit je implementie model maken
(eigenlijke script voor je database)

[SjosPin]

Wat ik denk dat je leraar bedoelt is het maken van een duidelijk en uitgebreid FUNCTIONEEL ONTWERP (andere benameningen zijn basisontwerp / detailontwerp).

Een van de doelen van een functioneel ontwerp is dat als jij er niet meer bent (op je werk / stage dan) en een ander persoon wil het systeem verder ontwikkelen / aanpassen dat hij wel snel een goed inzicht kan krijgen in het door jou systeem.

Ik helaas nu ff niet de literatuur bij de hand (ligt op stage) maar ik zal ff wat voorbeelden geven van onderdelen die in een Functioneel Ontwerp thuishoren:
- Rollenmatrix
- ERD's
- DataDictionary
- Function Hiërarchy Model
- Hiërarchisch model van de interface-structuur
- Geef duidelijk weer hoe je elke gevraagde functionaliteit wilt gaan implementeren (schets een voorbeeld interface, welke input en output, procedures en bijvoorbeeld nog een toegangspadanalyse).

Uhm meer kan ik ff niet achterhalen, als je vragen hebt of meer dingen wilt weten kan ik het altijd voor je nakijken.

[Verwijderd]

Floppy heeft een goed punt. Als je een echte database maakt moet je zorgen dat ie minstens in de 2e of 3e normaalvorm staat. Dit is denk ik toch wel het belangrijkste punt van databasedesign. Als dit niet gedaan wordt zou je nog wel eens voor performance verassingen kunnen komen te staan.

Greetz, daRoBBie.

[baggah]

Lees het boek van Edward Yourdon: Gestructureerde analyse.

Daar staan dingen als:
-Modelleringstechnieken
-analyse proces
zeer duidelijk in beschreven lijkt een beetje op SDM (maar iets wat beter).
En op het moment dat jij alles beschreven heb heb je een goede DataDictionary en een erd waarin je bijna alles al kan afleiden. De beschreven stromen(DD) moet je dan nog normaliseren en je hebt een redelijk goed gedocumenteerd systeem.