database ontwerp!
 

help!
Voor maandag moet ik voor mijn Eindwerk een database ontwerp maken van mijn stagebedrijf (boekhoud en fiscaliteiten kantoor).
Hoewel ik oplet in de les versta ik er geen bal van :(.
Informatica staat op superveel punten!!!
Hoe ik eraan moet beginnen ik weet het niet!
Is hier toevallig niemand goed daarin?
Kan die eventueel een powerpoint met de stappen doormailen ofzo?
:( I need help!
Want mijn punten zijn niet zo best en ik zou graag dit jaar afstuderen!!!

moet geen powerpoint zijn!
iets wat mij kan helpen! :-)

Als je een database moet opzetten is Access een logische optie.

ja maar ik moet nu eerst een schema maken... :(

Gebruik anders FCO-IM als je er écht niets van snapt.
Infagon 5.0 werkt prima om een 5NF database op te zetten, mits je je informatie goed kunt verwoorden. :p

Bij FCO-IM schrijf je eerst de informatie op (Zoals "Er is een factuur met nummer XXX" en "Factuur met nummer XXX hoort bij klant met nummer YYY", etc) aan de hand van voorbeeld data. Je zet er ook restraints in, etc.. Als je klaar bent, maakt de case-tool een GLR-schema van je informatie die dan weer direct te vertalen is naar een relationele database.

Het meeste werk doet het programma trouwens voor je. :p

Ik wil je best helpen, maar je komt nogal laat met je vraag, eigenlijk; omdat je bij database-ontwerp nogal wat moet nadenken over hoe je alles in elkaar gaat steken.

Mijn persoonlijke werkwijze hierbij is dat ik gewoon nagaan wat er allemaal opgeslagen moet worden en dan zie je de relaties ook wel (hiervoor is wel enig inzicht nodig in informatieverwerking). Voor de meeste mensen is dat dus géén optie (of in het begin toch niet).

Het meer theoretische xN-systeem (normalisatiegraden) is beter geschikt als je niet echt veel inzicht of ervaring hebt. Dat komt er gewoon op neer dat je bedenkt welke output je database moet kunnen leveren. Die output stel je eerst manueel op (bv. een factuur, bovenaan naam van het bedrijf, naam van de klant etc., dan in kolommen de gekochte artikels, etc.). Daarin zullen een aantal constanten zitten (de naam van je eigen bedrijf bijvoorbeeld), die moeten niet in de DB komen, maar voor de rest ga je verschillende types velden tegenkomen (naam_klant, adres_klant, prijs_product, aantal_product, ...), die schrijf je allemaal op. Dit geeft de zogenaamde 0N-vorm. Met de verdere normaalvormen ben ik niet zo bekend (omdat ik ze zelf niet echt gebruik).

Ik raad je aan dus gewoon met Google "normaalvormen OR normalisatie database" op te zoeken. Er zijn heel wat sites die stap per stap uitleggen hoe je normaliseert, zodat je een goede database kan opzetten.

dank u wel

FCO-IM is met name geschikt als je *wel* goed snapt hoe de zaak in elkaar zit.
Of preciezer: Als je op dat moment spreekt met iemand van het bedrijf die precies weet hoe de zaak in elkaar zit (maar dat wellicht nog niet meteen goed onder woorden kan brengen).

FCO-IM stelt je dan in staat, je gesprekpartners precies te laten zien wat het logisch gevolg is van wat ze jou zoal hebben uitgelegd.
Ze kunnen dan bijtijds bijstellen waar ze eerder onduidelijke (of foutieve) informatie hebben gegeven.



Maar daarvoor blijft hoe dan ook noodzakelijk, dat je aan de mensen van het bedrijf vraagt waar het allemaal om gaat en hoe de verbanden precies liggen.

----------------

Het grote probleem is meestal de communicatie tussen enerzijds de mensen die het database-ontwerp moeten maken (in dit geval ben jij dat), en de mensen die de uiteindelijke applicatie zouden moeten gebruiken (dat zijn dus mensen van je stage-bedrijf).

Dus het zal er op neer komen, dat je --tussen nu en het moment dat je de opdracht moet inleveren-- een stuk of drie sessies plant met de juiste mensen, en daarbij de juiste informatie boven water haalt.
De tweede sessie is nodig voor opheldering over zaken die na de eerste sessie achteraf niet duidelijk genoeg bleken te zijn.
De derde sessie is nodig voor opheldering over zaken die na de tweede sessie achteraf niet duidelijk genoeg bleken te zijn.
Houd er daarbij rekening mee, dat je er waarschijnlijk pas *tijdens* de eerste of tweede sessie achterkomt, welke persoon je eigenlijk had moeten spreken ...

Die noodzaak is er sowieso wel, van wat ik heb gemerkt. Hij's alleen wat stricter bij FCO-IM. Maar ik vind het wel een fijne tool.

Op zich heb je altijd wel enig inzicht nodig in gegevensstructuren, mar er zijn genoeg websites en boeken die je stapje voor stapje uitleggen hoe je een database kan ontwerpen. Die normalisatiestappen kunnen in het begin best een handige leidraad zijn, lijkt me (ook al vind ik ze persoonlijk nogal theoretisch en lukt het met enige ervaring meestal sneller gewoon op het gevoel).

Met die websites en boeken krijg je wel een mooi database-ontwerp, maar vast geen ontwerp dat goed past bij je stage-bedrijf.

Lezen is niet alles overtypen wat in het boek staat. Ik bedoelde in geen geval dat je gewoonweg alles moest kopiëren van een bestaand ontwerp (je kan wel stukjes opnieuw gebruiken, in feite kan je bijna niet om het gegeven heen dat verschillende ontwerpen toch overeenkomsten kunnen hebben, vermits de relaties toch dezelfde blijven, dat zal ook in het ontwerp zo blijven).

Ik bedoel enkel dat er genoeg lectuur is, ook op internet (die meestal kwalitatief iets minder goed is, maar misschien op veel kortere periode een resultaat geeft, terwijl boeken eerder de basis uitleggen en je dan pas aan hetontwerpen zetten, wat op langere termijn natuurlijk veel productiever is).

Sowieso kan je amper een specifiek ontwerpp kopiëren, maar stel dat je een database met films maakt; dan heeft de titel van de film een 1:1-relatie met de film, terwijl een acteur een veel:veel-relatie heeft met de film (een acteur kan in meerdere films spelen, en in één film kunnen meerdere acteurs spelen) en de filmquotering heeft een veel:1-relatie met de film (1 film kan door verschillende personen een andere score krijgen, maar 1 persoon kan maar 1 punt toekennen aan de film). In de meeste gevallen blijven deze structuren behouden, tenzij het bedrijf echt een specifiek doel heeft, waarbij de meest eenvoudige relaties niet voldoen (bv.voor een gewoon bedrijf is het meestal genoeg om te weten welk adres een bepaalde klant heeft, terwijl het voor de Post ook handig kan zijn om te weten wie er daarvoor op het adres woonde, om maar een min of meer fictief voorbeeld te geven).

Sowieso moet je een ontwerp zelf maken, dat kan geen boek of website voor je doen; je hebt namelijk zelf de specificaties nodig voor de wensen van de klant.