Hoe een goede database te ontwerpen

[Anoniem: 197938]

Goedemiddag,

ik vraag me altijd af hoe ik een goede database kan ontwerpen dus database helemaal out of the blue. op school heb ik de techniek normaliseren geleerd alleen begrijp ik niet hoe deze techniek te gebruiken bij een database out of the blue, ik heb namelijk alleen geleerd op formuliertjes dus de repeating group, processgegevens, enz zoeken.

mijn vraag is dus:
Hoe kan ik goede database ontwerpen? (hier bij is het onderwerp niet relevant)
Zijn hier eventueel verschillende technieken in dan alleen normaliseren.

Ik hoop dat jullie hier een antwoord op kunnen geven

[Tukk]

Goedemiddag...

IMHO: Er zit altijd een verschil tussen praktijk en theorie. De manier om het te leren is het toepassen van de modellen en daarna goed te kijken of je modelleringen kloppen bij gebruik en mogelijke uitbreidingen van de database. Praktijkervaring is alles.

[Anoniem: 140111]

Ik zou beginnen met het formuleren van je probleem en het oplossingsdomein (uit de probleemstelling, door middel van vragen). Misschien heb je tijdens de lessen geleerd bepaalde woorden (werknemer, adres, prijs etc) te onderstrepen of iets dergelijks, doe dat. Het ontwerpen van een database vindt voornamelijk plaats op papier en het kost veel tijd en oefening om er handig in te worden.

Als je gewoon eens wilt oefenen, begin dan met een sportvereniging, een ledenadministratie. Je kunt zelf helemaal bepalen hoe gek (of beter: hoe simpel) je het wilt maken. Hoe ga je met 1:n relaties om, hoe met n:m relaties etc. Pas je ontwerp ook toe middels, bijvoorbeeld php/mysql (laag instap niveau, snel resultaat) of gewoon op de command prompt, en ga er mee 'spelen'. De beste leermeester is, imho, oefening

[-- 1 --]
In het plaatsje Verweggidrecht is een tennisvereniging actief.
Deze vereniging bestaat uit verschillende teams.
Elk team bevat verschillende leden.
Elk lid kan met 1 team meespelen.
[-- 2 --]
In het plaatsje Verweggidrecht is een tennisvereniging actief.
Deze vereniging bestaat uit verschillende teams.
Elk team bevat verschillende leden.
Omdat er een tekort aan spelers is kan een lid met meerdere teams meespelen.
[-- etc --]

[ Voor 30% gewijzigd door Anoniem: 140111 op 28-02-2008 14:27 ]

[Anoniem: 197938]

ok dat is duidelijkheid daar kan ik wat mee, dus kijken wat voor belangrijke objecten van de database dan kijken wat het verband tussen de objecten, en daarna gaan normaliseren?

[Anoniem: 140111]

Ja, daar komt het wel op neer. Inventariseer je objecten (eigenlijk heten dit entiteiten) en de eigenschappen van deze objecten (attributen), bepaal de relatie die deze hebben, schets ze en denk er over na.

code:

//pseudo gebrabbel
---[team]------------
teamnaam
PRIMARY KEY(teamnaam)
-------------------------

---[lid]----------------
lidnaam
teamnaam
woonplaats
PRIMARY KEY(lidnaam)
FOREIGN KEY (teamnaam) REFERENCES team.teamnaam
------------------------

Niet onbelangrijk (lees: essentieel), leer ook over FOREIGN/PRIMARY KEYS.
Hiermee dwing je namelijk relaties af tussen entiteiten/attributen, wat niet onbelangrijk is in een RelationalDBMS

Als je overigens meer theoretische diepgang zoekt, zul je er goed aan doen jezelf te verdiepen in de verzamelingenleer. Een (in beginsel) redelijk eenvoudig te begrijpen tak van de wiskunde. Relationele databases zijn in feite niets anders dan verzamelingen waar je bewerkingen op uitvoert.
Wikipedia: Verzameling (wiskunde)

[ Voor 40% gewijzigd door Anoniem: 140111 op 28-02-2008 14:59 ]

[Anoniem: 197938]

Hier kan ik echt heel veel mee

WortelTaart

[Voutloos]

Overigens kan ik me niet voorstellen dat de termen entiteit, attribuut, set en foreign key niet behandeld zijn voor/tijdens dat studievak.

[Koppensneller]

Kijk ook eens naar FCO-IM. Dit is een methode voor databaseontwerp waarmee je met een reeks vrij eenvoudige handelingen een kloppend datamodel kunt ontwerpen. Het is ontwikkeld door een aantal docenten op mijn hogeschool (HAN) en ik ben er op die manier mee in aanraking gekomen.

[Anoniem: 197938]

@Voutloos

deze termen zijn inderdaad behandeld maar erg basaal

[Anoniem: 140111]

KoppenSneller schreef op donderdag 28 februari 2008 @ 15:26:
Kijk ook eens naar FCO-IM. Dit is een methode voor databaseontwerp waarmee je met een reeks vrij eenvoudige handelingen een kloppend datamodel kunt ontwerpen. Het is ontwikkeld door een aantal docenten op mijn hogeschool (HAN) en ik ben er op die manier mee in aanraking gekomen.

Is het niet beter om eerst te weten wat je doet voor je met tooltjes gaat werken?

[Koppensneller]

Anoniem: 140111 schreef op donderdag 28 februari 2008 @ 15:32:
[...]

Is het niet beter om eerst te weten wat je doet voor je met tooltjes gaat werken?

Tuurlijk moet je de principes van databases een beetje onder de knie hebben, zeker als je wil begrijpen wat de uitwerking van elke tussenstap op het eindresultaat is. Maar een methode als FCO-IM kan wel degelijk een goede manier zijn voor een beginnende databaseontwerper.

[Standeman]

Wanneer je weet wat voor entiteiten je hebt kan je, om het te visualiseren, ook een ER-diagram tekenen. Dan krijg je imo een beter beeld van waarmee je bezig bent. Vooral de R in ER is erg belangrijk wat betreft keys en tussentabellen.

[ Voor 13% gewijzigd door Standeman op 28-02-2008 16:12 ]

[Anoniem: 140111]

Ah, ja dat vergat ik te vermelden, met schetsen bedoelde ik het tekenen van het ER model

[Anoniem: 33810]

Eigenlijk is normaliseren de laatste stap die je doet in het ontwerpen van een database...

Dat vind ik ook het vreemde van school (bij mij ging het ook zo)...eerst leer je hoe je uit een bestaande database dingen moet halen (SQL), daarna normaliseren, en nu krijgen we ERD modellen. Precies verkeerd om lijkt me.

Maar begin dus echt bij het begin, eerst in "mensen" taal beschrijven wat je hebt en wat je vast wilt leggen, dat omzetten naar een ERD, dat omzetten naar tabellen, en die uiteindelijk normaliseren.

[Orphix]

Er staan een aantal whitepapers op : http://www.orm.net/ .

[curry684]

Anoniem: 33810 schreef op donderdag 28 februari 2008 @ 16:43:
Eigenlijk is normaliseren de laatste stap die je doet in het ontwerpen van een database...

Ja klinkt logisch, laten we het eerst kut opzetten zodat we vervolgens de helft ervan weer weg kunnen gooien

Normaliseren moet je doen vanaf de eerste entiteit die je bedenkt/tekent/invoert. Ook zolang je nog niet denkt in de derde NV is dit geen proces wat je tot het allerlaatst moet uitstellen, maar doorlopend moet evalueren bij iedere entiteit die je toevoegt.

[Laurens-R]

En ook niet onbelangrijk: KISS (niet de rockband )

Keep It Simple Stupid!

Maak het jezelf niet moeilijk. Ook in grote enterprise applicaties zie nog wel eens dat de designers op hol waren geslagen ofzo, waardoor een overvloed aan tabellen was aangemaakt die niet te onderhouden waren, of simpelweg niet nodig waren binnen de context van de requirements.

[curry684]

EvilB2k schreef op zaterdag 01 maart 2008 @ 17:48:
Ook in grote enterprise applicaties zie nog wel eens dat de designers op hol waren geslagen ofzo, waardoor een overvloed aan tabellen was aangemaakt die niet te onderhouden waren, of simpelweg niet nodig waren binnen de context van de requirements.

En dat ziet er dan zo uit En maar afvragen waarom het niet performt \o/

[martennis]

een goed ontwerp hangt ook af van het doel van je database..
hoeveel gebruikers verwacht je en hoeveel transacties verwacht je (select, update, ..)? wil je analyses kunnen uitvoeren op je data? verwacht je een snelle groei van de omgeving, waardoor misschien in de toekomst distributed computing moet toepassen?

voor een simpele database voor een website ofzo is dit overdreven, maar voor een bedrijfskritische database zijn dit een aantal onderdelen waar je rekening mee moet houden..
meer info hierover kun je wel op wiki en wiki vinden..

[SKiLLa]

curry684 schreef op zaterdag 01 maart 2008 @ 18:11:
[...]

En dat ziet er dan zo uit En maar afvragen waarom het niet performt \o/

OMG, daar is iemand echt doorgeslagen ... Iets met theorie, praktijk, ervaring en gebrek aan ... ofzo

[EfBe]

Orphix schreef op donderdag 28 februari 2008 @ 17:17:
Er staan een aantal whitepapers op : http://www.orm.net/ .

De eerste site die je moet bezoeken idd. De theorie van meneer Halpin doornemen en het wordt je allemaal duidelijk.

Je kunt het ook op de lazy ass methode doen natuurlijk en gewoon een model van het net plukken:
http://www.databaseanswers.org/data_models/

[ Voor 20% gewijzigd door EfBe op 01-03-2008 20:53 ]

[Standeman]

curry684 schreef op zaterdag 01 maart 2008 @ 18:11:
[...]

En dat ziet er dan zo uit En maar afvragen waarom het niet performt \o/

Echt prachtig

[PeaceNlove]

curry684 schreef op zaterdag 01 maart 2008 @ 18:11:
[...]

En dat ziet er dan zo uit En maar afvragen waarom het niet performt \o/

In welk *NF is dat? Designer mag weer terug naar de bankjes

[Anoniem: 222167]

Bij het ontwerp van een database begin je met een ER of EER-schema te maken (EER=Extended Entity-Relationship). Daarbij ga je eigenlijk net zo te werk als bij het ontwerp van een klasse diagram bijvoorbeeld in UML. Je definieert entiteiten (== klassen in UML), die bepaalde attributen hebben en je definieert relaties tussen entiteiten (eventueel met generalisatie/specialisatie in het EER-model).
Als je eenmaal een (E)ER-schema hebt, is het makkelijk dit om te zetten naar een relationeel database schema. Er bestaan gewoon algoritmes daarvoor, dus je hoeft zelfs niet na te denken om de omzetting te doen.
Het is altijd veel makkelijker om te beginnen met een (E)ER-schema omdat het toelaat in een hoger abstractie-niveau te denken. Een ER-model zegt veel meer dan een relationeel schema omdat je je niet met details hoeft bezig te houden (type (INT, TEXT, VARCHAR,...), null of niet null toelaten, enz...).

Ik hoop dat je hiermee iets bent.

[Hydra]

Anoniem: 33810 schreef op donderdag 28 februari 2008 @ 16:43:
Dat vind ik ook het vreemde van school (bij mij ging het ook zo)...eerst leer je hoe je uit een bestaande database dingen moet halen (SQL), daarna normaliseren, en nu krijgen we ERD modellen. Precies verkeerd om lijkt me.

Ik heb HIO aan de HEN gedaan, en daar begin je toch eerst met normaliseren (NIAM HOOOO!!!), pas later ga je met databases aan de slag, en dan vooral query-optimalisaties. Wat voor'n opleiding heb je gedaan?

[Meekoh]

curry684 schreef op zaterdag 01 maart 2008 @ 18:11:
[...]

En dat ziet er dan zo uit En maar afvragen waarom het niet performt \o/

Was dat niet uit een topic hier een tijdje geleden? Plaatje komt me erg bekend voor

[Jeebeekje]

Ik doe BI op Windesheim, daar leren we ook om eerst te normaliseren voordat je een databaseontwerp maakt. De gegevens die je wilt opslaan bepalen hoe je database er uit komt te zien en niet andersom.
FCO-IM is best wel ingewikkeld, maar als je alle stappen hebt doorlopen die bij deze methode horen, kom je al aardig in de buurt van een databaseontwerp.
Het bouwen zelf reken ik dan uiteraard niet mee.

[Anoniem: 127425]

Koop een interessant boek over database modeling in het algemeen. Daaruit leer je de verschillende normalisatiestappen. Als je deze theorie beheerst kun je overstappen naar de praktijk en zul je (zoals eerder aangehaald) zien dat veel situaties/problemen/... terugkomen en in eenzelfde oplossing resulteren (patterns).