[ALG] RFC : Database ontwerp tutorial

[Skinny]

Naar aanleiding van een topic wat ik hier gisteren las (en de vele anderen die voorgingen) heb ik vandaag een eerste versie van een tutorial gemaakt over het normaliseren van databases en het waarom.

[url="http://www.breakie.com/dbtut.html"]Klik om te lezen[/url]

Graag jullie reakties..

Disclaimer : Het is in een middagje geschreven en nog niet af. Opbouwende kritiek wordt zeer gewaardeerd, maar stomme opmerkingen (iedereen weet waar ik het over heb) kunnen gerust in je hoofd blijven.

[Janoz]

ff snel gekeken, lees later wel verder:

Bij relaties is het gebruikelijker om 1:N te gebruiken. Bij een many-many relatie kun je beter N:M gebruiken om duidelijk aan te geven dat de hoeveelheden aan beide kanten van de : van elkaar kunnen verschillen.

[Zoijar]

Haha, cool mate

Ik zei gisteren dat het een goed idee zou zijn, ben blij dat iemand er de tijd en moeite voor heeft genomen

Top!

[Skinny]

Op woensdag 24 juli 2002 15:23 schreef Janoz het volgende:
Bij relaties is het gebruikelijker om 1:N te gebruiken.

Done.

[Zoijar]

"Om ons ontwerp in de 2e NF te krijgen, moeten attributen die afhankelijk zijn van een (deel van een) samengestelde primary key naar een aparte entity verplaatst worden. Eens kijken waar we dan op uit komen..."

die haken om "deel van een" moeten weg. Als het attribuut namelijk afhankelijk is van de volledige samengestelde PK is het wel 2NF. Het gaat om afhankelijkheid van een deel van de PK, dat mag niet.
Als je geen samengestelde PKs hebt, is je schema automatisch in 2NF als het ook in 1NF is

[Zoijar]

Misschien kan je nog wat meer voorbeelden geven van waar het fout gaat als je database niet genormaliseerd is.

Bv.:

- Als alle wiskunde studenten zich uitschrijven, dan verdwijnt ook de studie wiskunde. Dit wil je iha niet.

- We kunnen geen nieuwe studie toevoegen, zonder dat er een student is die dat studeert.

- lossless join eigenschap/spurious tuples, maar dat zou ik eruit laten. Misschien te ingewikkeld.


[Nb. dit is constructief commentaar. Ik vind het erg goed dat je dit geschreven hebt in duidelijke taal]

[Skinny]

Op woensdag 24 juli 2002 15:30 schreef Zoijar het volgende:
[..]

Ook done..

Op woensdag 24 juli 2002 15:38 schreef Zoijar het volgende:
- lossless join eigenschap/spurious tuples, maar dat zou ik eruit laten. Misschien te ingewikkeld.

Ja, dit lijkt me iets voor "part 2" .. De overige twee puntjes staan er inmiddels ook in.. bedankt!

[Mithrandir]

Ik had net een paar weken geleden aan D2k een linkje voor in de FAQ gegeven voor een stuk text over Database Normalisatie...

Ik vind het leuk dat iemand van GoT iets heeft geschreven

Een goed stukkie hoor!

[Skinny]

Inmiddels is er ook een stukje van Deel 2

[url="http://www.breakie.com/dbtut2.html"]Klik[/url]

[Verwijderd]

Dit interesseert mij.
Klasse werk!!

Zal ik eens wat waarde toevoegen.
Gaan we hier eens een mooie van maken.

Tot over 1-4 uurtjes.....

[Verwijderd]

Normalisatie wordt gedaan door de methodiek die je gebruikt voor de modellering van je data. Dus, als je kiest voor ORM en je zet het ORM schema om naar E/R model middels de ORM methodiek, dan is dat automatisch 5e normaalvorm. (volgens Halpin, een van de bedenkers van ORM).

Zelf knoeien aan tabledefinities is dus not done, en staat gelijk aan het verbeteren van assembler dat uit een C compiler rolt. Hoe goed de bedoelingen ook zijn

[Skinny]

Uhh.. ongetwijfeld, maar hoeveel mensen die een tutorial over database-design nodig hebben zullen een ORM/ERM of whatever maken ? Ik denk dat de doelgroep toch heel anders is.

NOFI

[Zoijar]

Op woensdag 24 juli 2002 17:00 schreef Otis het volgende:

Zelf knoeien aan tabledefinities is dus not done, en staat gelijk aan het verbeteren van assembler dat uit een C compiler rolt. Hoe goed de bedoelingen ook zijn

Wat in sommige gevallen nodig kan zijn. Soms wil je helemaal geen 5NF afdwingen. Bv met het oog op performance, of de grootte van de database. Soms heb je helemaal geen ER-diagrammen, maar alleen een bestaande bedrijfs database. Wat doe je dan als er iets toegevoegd moet worden?
Iedereen die met databases werkt moet tenminste zelf handmatig kunnen normaliseren tot bcnf. En vooral de theorie erachter begrijpen.

[edit: Je zou dan ook geen SQL hoeven leren, want je kan je queries zo mooi grafisch samenstellen in bv sql server enterprise manager...]

[Verwijderd]

Ik denk dat ik toch maar afzie van verdere uitwijdingen over dit onderwerp.

Wie wil leren normaliseren, doet maar eens een query in de google-database.

Heb het idee dat deze kous meer dan af is..........

[Verwijderd]

Op woensdag 24 juli 2002 17:09 schreef Zoijar het volgende:
[edit: Je zou dan ook geen SQL hoeven leren, want je kan je queries zo mooi grafisch samenstellen in bv sql server enterprise manager...]

Niet iedereen heeft GELD voor Microsoft produkten, Zoijar en niet iedereen wil vertrouwen op een monstrueus en gesloten platform als dat van Microsoft (qua stabiliteit en veiligheid). Ook kom je op jouw manier geen steek verder op een 486 of Pentium 133 o.i.d.

-

Wie wat wil kunnen met databases en zichzelf respecteert zou MINSTENS zelf moeten kunnen normaliseren (recursief / complex) en alles m.b.v. SQL kunnen implementeren en gebruiken (vooral query's).

Die dingen komen telkens weer terug. In welke vorm dan ook.

[Zoijar]

Hmmm ja... sarcasm truly is a bitch

[Feyd-Rautha]

Ik moet zeggen: heel sjieke tutorial. Ik zou er niets aan toe te voegen hebben. Op het eerste zicht toch

[dusty]

Op woensdag 24 juli 2002 17:09 schreef Zoijar het volgende:
[..]
Bv met het oog op performance

Als ik jou was zou ik nog eens de definitie van de 5e normaalvorm doornemen.

[Verwijderd]

Helaas dat er wat minder uitgebreide DBMS's als mysql zijn, die enkele handige features (zoals UNION) [nog] niet ondersteunen. Zo had ik afgelopen week een geval waarbij met een simpele union de query in minder dan een honderste seconde uitgevoerd kan worden, maar omdat dat in mysql niet kon moest ik de query op een andere manier opschrijven waarbij de optimizer weigerde een index te gebruiken (maar full table scan op een aardig grote set kleine records) en de query opeens een halve seconde duurt... (i know, should have used postgresql...)

Dit kon ik oplossen door een shortcut in te bouwen (er was ook nog wel een andere oplossing, maar dat doet niet ter zake). Nu draait het geheel dus wel snel, maar er is hierdoor wel redundancy ontstaan die je eigenlijk helemaal niet hebben wilt. Gelukkig gaat het in dit geval om data dat in principe niet verwijdert hoort te worden en referenties niet gewijzigd, dus zo erg is het eigenlijk niet.

Later moest ik echter een feature toevoegen en toen bleek het opeens een heel nuttige wijziging en is op dit moment de shortcut niet meer redundant (omdat het per definitie niet een echte shortcut meer is).

Verder nog een toevoeging: er zijn algoritmen om een database schema in een gegeven normaalvorm te brengen (dat kan handig zijn als je een gigantische berg tabellen hebt). Maar die gaan voor iemand die zojuist de beginnende stapjes met SQL doet, denk ik iets te ver.

[Zoijar]

Op woensdag 24 juli 2002 21:07 schreef dusty het volgende:

[..]

Als ik jou was zou ik nog eens de definitie van de 5e normaalvorm doornemen.

Heb je helemaal gelijk in. Ben nl. nooit verder dan BCNF gekomen. Het was maar een vak, en niet m'n afstudeer richting. Ik quote alleen maar wat ik geleerd heb, en ik heb geleerd dat er gevallen zijn dat je geen normaal vormen wilt afdwingen en performace werd als voorbeeld gegeven. Duidelijk tentamen vraagje. Maareh, wat is er dan zo speciaal aan 5NF?

[Feyd-Rautha]

Maareh, wat is er dan zo speciaal aan 5NF?

Ik dacht: Denormaliseren om performantie-redenen

[Tomatoman]

Nog een paar puntjes op de i zetten en dan is het helemaal goed.

- Misschien is het handig om ook de Nederlandse termen toe te voegen voor de schuingedrukte begrippen zoals 'primary key'. Dat maakt het zoeken in bijvoorbeeld de Help van Access een stukje gemakkelijker.
- Om alle Trekkies voor te zijn, de correcte quote is: 'To boldly go where no man has gone before'. Tja, het blijft een kromme zin.

Je hebt nu de 1e t/m de 3e NF beschreven. Aangezien de meeste 'goede' databaseontwerpen ook aan de 4e NF voldoen, is het misschien verstandig om deze ook nog te beschrijven. De 5e NF en hoger hebben vooral theoretische waarde, maar worden in de praktijk nauwelijks toegepast, omdat de performance daar onder zou lijden.

Anyway, goed werk!

[Skinny]

Op woensdag 24 juli 2002 22:17 schreef tomatoman het volgende:


Anyway, goed werk!

Thanks! en goede puntjes inderdaad. Voor vanavond is het genoeg geweest. Morgen weer een dag!

[Juup]

primary key: Een primary key is een (jaja) uniek attribuut dat verwijst naar één (niet meer) regel data in een tabel, m.a.w. naar een instance dus. In ons voorbeeld over studenten zou het 'studentnummer' een goed voorbeeld zijn van een primary key, omdat dit nummer voor elke student uniek is en dus naar één specifieke regel (student) in de tabel verwijst.

Ik zou zeggen kolom ofzo. regel is iig niet wat je bedoelt.

Keep up the good work!!!

[gorgi_19]

Op donderdag 25 juli 2002 00:59 schreef Jaaap het volgende:

[..]

Ik zou zeggen kolom ofzo. regel is iig niet wat je bedoelt.

Keep up the good work!!!

Bedoel je niet rij in dit geval?

[Juup]

one-to-one (1:1) :
Een 'one-to-one' (één op één) relatie bepaald dat van elke mogelijke versie (instance) van een entity exact 1 instance van een andere entity bestaat. Als voorbeeld nemen we weer onze studenten. Elke 'student' heeft slechts één 'diploma' en andersom : elk 'diploma' behoort slecht aan één 'student'.

bepaald => bepaalt

diploma => diplomanummer ofzo want ELKE student kan hetzelfde diploma hebben (VWO ofzo).

[Juup]

Op donderdag 25 juli 2002 01:02 schreef gorgi_19 het volgende:

[..]

Bedoel je niet rij in dit geval?

Oh wacht, spraakverwarring! Ik bedoelde dat de hele kolom verschillende primary keys bevat.

De auteur bedoelt dat die rij/regel EEN primary key heeft. Hmmm... verwarrend is dat.

[Psychops]

Mooie tutor, maar nog vrij lastig voor mensen die beginnen met het opzetten van een Database en leek zijn.

Zelf vind ik de NIAM methode voor een beginner een goeie. FCO-CASETOOL maakt hier gebruik van, en het programma is gratis te downloaden (v4 en v5) en er zit een erg duidelijke tutorial bij. Tevens kan het programma zelf het GLR algorithme toepassen op een ontwerp (stap voor stap, erg makkelijk om het beter te begrijpen).

Greetz

[drm]

Coole tut, dat staat voorop

Maar natuurlijk ga ik weer ff uberkritisch zijn:

Een primary key hoeft niet persé uit één attribuut te bestaan. Stel je bijvoorbeeld een schoolrooster voor. Een klaslokaal is geen uniek attribuut want in een lokaal kunnen meerdere lessen gegeven worden. Voegen we aan het klaslokaal een tijdstip (datum/tijd) toe dan wordt het ineens wél een uniek omdat er niet meer dan één les gegeven kan worden in een klaslokaal op een gegeven tijdstip.

Dit stukje ben ik niet helemaal met je eens. Ik vind het persoonlijk niet zo netjes om een tijdstip als onderdeel van een primary key te nemen. imo mag een primary key niet meer betekenis hebben dan de identificatie van het record. Verder geen enkele informatie.

Daarnaast is "tijdstip" geen attribuut van "lokaal" maar van "lesuur". (Denk aan: "Ik heb het 1^e tot het 4^e les")

Dus wat ik zou doen is een tabel lesuren maken, met daar een primary key, en die vervolgens samen met lokaal, leraar, klas en lesuur en vak (allemaal foreign keys dus) als 1 primary key in een koppelentiteit "lessen" opnemen.

Kortom, je voorbeeld is niet zo geweldig, imo Om nou meteen te beginnen met een koppelentiteit van 5 primary keys ...

foreign key: Een 'foreign key' staat aan de basis van een (1:M) relatie tussen twee 'entities'. De 'foreign key' komt voor in de 'M' entity en verwijst naar 1 instance van de andere entity. Als voorbeeld kan je denken aan het volgende. Er bestaat een entity 'leraar' die als primary key een leraar-nummer heeft. In de 'klassen' entity staat een 'foreign key' waarin een nummer (en dus een unieke verwijzing) staat naar de leraar.

Dit is ook niet helemaal terecht, want de relatie leraar - klas is n:m Een klas heeft les van meerdere leraren en een leraar geeft les aan meerdere klassen.

Maak daar bijvoorbeeld "mentor" van als foreign key in klas. Een klas heeft doorgaans maar 1 mentor, en een mentor is wel een leraar.

Stel dat nu leraar 145 ziek wordt en wordt vervangen door nummer 160. In deze tabel is dit nog simpel te doen, omdat er slecht twee rijen veranderd hoeven te worden. Als de tabel echter zo groot is als de GoT-users tabel, dan wordt dit al snel een foutgevoelig werkje. Er wordt een fout gemaakt tijdens het veranderen, of er wordt een rij overgeslagen, dan klopt er dus al niets meer van.

Geef hierbij ook aan dat een leraar op een bepaalde dag ziek is, en dat het bij deze manier van opslaan niet weer te geven is dat hij op Maandag geen les kan geven, maar op woensdag en vrijdag waarschijnlijk wel.


Verder vind ik 'm redelijk ok. Deel 2 heb ik niet doorgelezen, want die is toch nog niet af

't Is misschien nog iets om aan het eind van deel 1 ook eventjes een beeld van tabelletjes en hun relaties (pijltjes met 1:n, n:m enzo). Dan grijp je weer terug op wat eerder al verteld is, en herinnert de lezer het zich weer

Keep up the good work

[Verwijderd]

Op donderdag 25 juli 2002 09:46 schreef drm het volgende:
Dit stukje ben ik niet helemaal met je eens. Ik vind het persoonlijk niet zo netjes om een tijdstip als onderdeel van een primary key te nemen. imo mag een primary key niet meer betekenis hebben dan de identificatie van het record. Verder geen enkele informatie.

Maar, algemeen gezegd, KAN een datum/tijd onderdeel uitmaken van de PK.

Daarnaast is "tijdstip" geen attribuut van "lokaal" maar van "lesuur". (Denk aan: "Ik heb het 1^e tot het 4^e les")

Nee het is een attribuut van de objectified relatie lokaal - lesuur.

Daarom is het ook onzin te knoeien in tabellen. Tabellen zijn het RESULTAAT van je model, niet gelijk aan je model. Door dit soort gefreubel krijg je de grootst mogelijke ellende in je tabelstructuur en is na verloop van tijd de chaos compleet.

Je kunt 'normalisatie' wel illustreren aan de hand van tabellen, maar het is geen methodiek om 'tabellen' even op orde te brengen, maar een term voor de toestand waarin je tabellenstructuur zich bevindt. Een goede methodiek levert al de gewenste normaalvorm op en je hebt er dus normaliter geen omkijken naar.

Dus wat ik zou doen is een tabel lesuren maken, met daar een primary key, en die vervolgens samen met lokaal, leraar, klas en lesuur en vak (allemaal foreign keys dus) als 1 primary key in een koppelentiteit "lessen" opnemen.

Op wat voor basis? Uit de losse pols even een tabelletje toevoegen is gewoon NOT DONE. Wellicht wel voor je studentenflat-admin-systeempje wie wanneer gekookt heeft, maar voor productie systemen is dit fatalistisch bezigzijn. En aangezien we het hier hebben over een tutorial, dus iets dat iets zou moeten leren, mag je verwachten dat het het juiste onderwijst.

Beter is de relaties uit te schrijven. Een klas heeft les op een bepaald tijdstip in een bepaald lokaal. les + tijdstip + lokaal is relatie. Les heeft relaties met vak, leraar en klas. door die relaties zit klas in lokaal op tijdstip tijdstip. 'even' een tabel erbij vrotten lost dus niets op, in tegendeel, je ziet al dat dit meerdere tabellen oplevert (of iig een andersoortig tabellenstructuur).

Kortom, je voorbeeld is niet zo geweldig, imo Om nou meteen te beginnen met een koppelentiteit van 5 primary keys ...

Het voorbeeld an sig is niet verkeerd, want er zitten veel nogal diepe relaties in verborgen. JOUW voorbeeld is daarentegen idd niet zo geweldig

[..]
't Is misschien nog iets om aan het eind van deel 1 ook eventjes een beeld van tabelletjes en hun relaties (pijltjes met 1:n, n:m enzo). Dan grijp je weer terug op wat eerder al verteld is, en herinnert de lezer het zich weer

Relaties tussen tabellen op basis van 1:n ? Wat heb jij gedronken!

repeat after me: "Relaties tussen tabellen _BESTAAN NIET_". 'Relaties' tussen velden in tabellen bestaan _WEL_. (maar feitelijk zijn dit constraints). Je kunt dat wel gaan zien als 'relatie tussen tabel X en Y' maar in feite is dat freubelen. Je spreekt over relaties in een datamodel, niet in een tabellenstructuur. Dan spreek je over constraints. Normaliter is nl. je datamodel niet 1:1 afbeeldbaar op een tabellenstructuur!

[Zoijar]

Op donderdag 25 juli 2002 11:36 schreef Otis het volgende:

Op wat voor basis? Uit de losse pols even een tabelletje toevoegen is gewoon NOT DONE. Wellicht wel voor je studentenflat-admin-systeempje wie wanneer gekookt heeft, maar voor productie systemen is dit fatalistisch bezigzijn. En aangezien we het hier hebben over een tutorial, dus iets dat iets zou moeten leren, mag je verwachten dat het het juiste onderwijst.

Ik denk dat de meeste mensen hier juist precies zo'n "studentenflat-admin-systeempje" op willen zetten. Dat was het hele doel van de tutorial. Je moet nooit je doelgroep uit het oog verliezen. Wanneer mensen zich met productie systemen bezig gaan houden, neem ik aan dat ze ofwel een goed boek pakken, ofwel al een graad in informatica hebben.
Ik heb bij jouw posts over dit onderwerp steeds het idee dat je alleen maar post om wel is even te laten zien hoe goed jij het weet, en dat jij met productie systemen werkt. Niet echt constructief, maarja...misschien zit ik er helemaal naast, in dat geval mijn excuus.

[Verwijderd]

Op donderdag 25 juli 2002 11:55 schreef Zoijar het volgende:
[..]
Ik denk dat de meeste mensen hier juist precies zo'n "studentenflat-admin-systeempje" op willen zetten. Dat was het hele doel van de tutorial. Je moet nooit je doelgroep uit het oog verliezen. Wanneer mensen zich met productie systemen bezig gaan houden, neem ik aan dat ze ofwel een goed boek pakken, ofwel al een graad in informatica hebben.

Velen ook niet, maar houden zich wel bezig met het ontwikkelen van systemen en lezen WEL deze newsgroup. Bij het zien van 'tutorial' denken ze dan iets te leren, terwijl het juist niet echt iets is dat ze op het juiste pad zet.

Ik heb bij jouw posts over dit onderwerp steeds het idee dat je alleen maar post om wel is even te laten zien hoe goed jij het weet, en dat jij met productie systemen werkt. Niet echt constructief, maarja...misschien zit ik er helemaal naast, in dat geval mijn excuus.

FYI: Ik weet het ook erg goed en ik ben ook heel erg goed. Zoiets verwacht je op een gegeven moment ook wel met hio + 8 jaar prof. ervaring. Echter ik post niet om te laten zien dat ik goed ben, wat heb ik daar aan? Niks.

Waar de mensen in de IT met zn allen wat aan hebben, ik dus ook, is dat de mensen die GEEN opleiding hebben genoten (of hebben afgemaakt) in de richting informatica en zelf dingen hebben aangeleerd, via methodieken leren werken ipv via de 'knutsel-maar-raak-want-dat-werkt-ook-wel-(vaak)'-methodiek.

Dus, JA, dan kom ik wellicht met ongezouten kritiek op een 'tutorial', maar het is een RFC dus comments mag ik maken, of moet het alleen positief zijn oid? Als men niet tegen kritiek kan, dan moet je niet om comments vragen, en al helemaal niet 'kritiek' leveren die zelf ook geen hout snijdt. Er lezen hier meer mensen die 'professioneel' bezig zijn dan je denkt.

[Skinny]

Op donderdag 25 juli 2002 12:58 schreef Otis het volgende:

[..]

Dus, JA, dan kom ik wellicht met ongezouten kritiek op een 'tutorial', maar het is een RFC dus comments mag ik maken, of moet het alleen positief zijn oid? Als men niet tegen kritiek kan, dan moet je niet om comments vragen, en al helemaal niet 'kritiek' leveren die zelf ook geen hout snijdt. Er lezen hier meer mensen die 'professioneel' bezig zijn dan je denkt.

Wellicht dat het makkelijk is om te weten dat IK die tutorial geschreven heb, en dat in mijn ogen niemand anders dan ikzelf kan bepalen of ik tegen kritiek kan. Zoals ik in mijn start-post al schreef. Graag hoor ik kritiek/suggesties/meningen.

Vergeet niet dat ik die tutorial even in een middagje in elkaar heb gezet, dus kan het nooit perfect zijn. Negatief commentaar kan ik (natuurlijk) wel hebben, maar het moet wel onderbouwd zijn. En dat gebeurd in de meeste gevallen gelukkig wel in dit topic.

Inmiddels heb ik besloten om deel 1 toch maar even opnieuw te schrijven .. met een iets andere insteek. Niet speciaal gericht op het fenomeen normaliseren, maar meer op "Hoe bouw ik een goed db-ontwerp", want dan kom je (zoals reeds gezegd) bijna automatisch in de goede (normaal)vorm uit.

Denk dat het dit weekend online komt, en dan natuurlijk weer met een RFC

[edit]Misschien handig te vermelden dat ik zelf ook "professioneel" met dit soort dingen bezig ben, maar dat ik het nooit op school heb gehad. Zelf-studie rulez IMO, maar dan moeten tutorials/how-to's wel goede manieren voorschrijven.

[Verwijderd]

Op woensdag 24 juli 2002 17:09 schreef Zoijar het volgende:
[..]
Wat in sommige gevallen nodig kan zijn. Soms wil je helemaal geen 5NF afdwingen. Bv met het oog op performance, of de grootte van de database.

Consessies doen aan je datamodel met het oog op performance is niet zo slim. Immers, tabellen hebben geen performance, de code die er data uit betrekt of update heeft performance. Veelal is performance achteraf pas meetbaar en bottlenecks zijn veelal op te lossen door optimalisaties aan de code, het gebruiken van views ipv hardcore tablejoins, of andere faciliteiten die het RDBMS biedt. Er vanuit gaan dat een datamodel niet zal performen bij voorbaat is net zulke luchtfietserij als verklaren dat een zeker object model in C++ retetrage code op zal leveren.

Soms heb je helemaal geen ER-diagrammen, maar alleen een bestaande bedrijfs database. Wat doe je dan als er iets toegevoegd moet worden?

Weet je wel wat ER-diagrammen zijn? Die kun je 1:1 afbeelden op je tabellen + database-constaints. Je kunt dus een ER model opstellen aan de hand van de tabellen + constraints. Een ER-diagram heb je dus altijd.

Verder: een serie tabellen IS ergens uit ontstaan, en als iemand met een beetje verstand van zaken ermee bezig is geweest, had die persoon een model opgesteld, daar de tabellen uit gedistilleerd en die in de database gezet. Iets toevoegen doe je dan aan je model, en je bepaalt DAN opnieuw je tabellen. 1 relatie erbij kan bv resulteren in meerdere nieuwe tabellen, waarbij de tabel-knutselaar wellicht gedacht had aan 1 extra kolom ergens in een bestaande tabel.

Iedereen die met databases werkt moet tenminste zelf handmatig kunnen normaliseren tot bcnf. En vooral de theorie erachter begrijpen.

Normaliseren is een werkwoord dat niet bestaat of althans, onzinnig is qua semantiek. Een database is in een zekere normaalvorm, een toestand. Een database is OOK een gevolg van een transformatie van een zeker datamodel naar DDL. Ergo: tijdens de transformatie zorg je voor de TOESTAND van de database, verwoord in de DLL. In de DLL lopen kloten (dat doe je, wanneer je gaat normaliseren met tabellen), is dan niet slim. Metafoor: je ziet een bug in je C++ code, en gaat die fixen in de assembler van de vorige compile-run. Dat doe je ook niet, je fixt de C++ code en compileert opnieuw. Zo is het ook met databases.

Databases is een zeer nieuw vakgebied, waarbij we op dit moment in een overgangsfase zitten. Relationele databases waren lange tijd de enige keuze maar men komt steeds meer tot de conclusie dat relationele databases (de 2D varianten) niet de lading dekken, plus men meer faciliteiten wil, immers je moet nu constraints e.d. aanbrengen voor het in stand houden van wat het datamodel aan structuur voorschrijft (dus dat de transformatie van datamodel naar DLL uberhaupt mogelijk is zonder loss of data/precision). Ik denk dan ook dat over 20 jaar men niet meer werkt met relationele databases en al helemaal niet meer met normalisaties, maar werkt met databases die data beheren aan de hand van een model, zoals je het ook opstelt, het datamodel.

[edit: Je zou dan ook geen SQL hoeven leren, want je kan je queries zo mooi grafisch samenstellen in bv sql server enterprise manager...]

In principe zou dat ook moeten. SQL is zeer beperkt en vrij low level, terwijl de vragen die je aan de database stelt vrij algemeen en high level zijn. Hier zit dan ook een discrepantie. Heb ik het nog niet eens over 3D queries, de zg Cubes, waar datamining systemen mee werken en waar je middels SQL wel krachtig mee om kunt gaan, maar die queries matchen al helemaal niet met de eigenlijke vraag die je wilt stellen.

Ooit afgevraagd waarom je uberhaupt een 'join' moet opgeven INCLUSIEF joinfields, terwijl de database dit echt zelf kan achterhalen? Hoe meer je normaliseert hoe meer joins, hoe complexer je SQL statements, terwijl de vraag eigenlijk hetzelfde blijft. Iets zegt me dat er dan een gapend gat is tussen wat we verlangen van computers en wat de computer levert, dus de software is niet op het level van de eis van de user.

Een database in een zekere normaalvorm is gewenst om slechts 1 reden: het voorkomen van inconsistentie. Een database in de 1e normaalvorm met 100% bugvrije code maakt geen fouten. Echter de code moet wel veel meer werk verzetten en de database bevat veel lege plekken. Sommige developers kiezen voor NIAM dat naar de 3e NF converteert en nemen niet die extra laatste horde naar de 5e NF. Op zich niet erg, de 3e NF is een goede tradeoff tussen een zekere redundancy vs. overzichtelijkheid die tot de voorkoming van inconsistentie moet leiden.

Maar t.a.t. moet men ernaar streven een datamodelleringstechniek te gebruiken die naar iig de 3e normaalvorm transformeert. Niet alleen heb je dan een model van je data, dat is nooit weg, plus je zit meteen op de 3e normaalvorm en kunt zo aan de slag met de programmatuur.

Ook voor flat-kooklijstenprogrammaatjes, want oefening baart kunst en een model opstellen voor zo'n systeem + transformaties is voor een beetje geoefende data-modelleerder kinderspel, dus voor een student informatica hooguit 2 zweetdruppels en een grolschje.

[Zoijar]

Even voor de duidelijheid, je hoeft het mij niet uit te leggen. Normaal zou ik het hier nooit over hebben, maar omdat het punt toch al naar voren kwam, ik heb een masters graad in de informatica (distributed systems, geen databases), civi award in informatica, propedeuse in wiskunde en 2 jaar profesionele ervaring. Kortom, ja ik weet wat een ER diagram is, en ik weet ook de wiskundige theorie achter normalisatie die vnl rust op hogere logica. Maar ik heb er een hekel aan als mensen zichzelf erg goed vinden

Mijn punt was...en nu komt het Je moet schrijven voor je doelgroep. Alles waar het woord "tutorial" in voor komt is meestal niet van universitair niveau, en dat is maar goed ook. Als ik de vragen die hier gesteld worden over databases zie, dan is zo'n tekst over normalisatie een goed hulpmiddel voor velen.

Buiten dat zie ik het probleem niet in het uitleggen ervan. Het is beter om eerst de basis theorie erachter te kennen, en dan pas je tools te gebruiken. Een quote van m'n professor, "Database design is meer dan alleen naive (E)ER-mapping"

En verder, agree to disagree

[drm]

Otis:
Relaties tussen tabellen op basis van 1:n ? Wat heb jij gedronken!

Goed zo. Daarmee overwin je een hoop barrieres, om met je universitaire kennis mijn "kennis" of kritiek te overrompelen. Beetje flauw om me te gaan zitten pakken op termen.

Verder is de tutorial geschreven om een te ontwerpen voor databases op GoT-niveau, en dit soort verhalen helpen daar echt niet aan mee. In plaats van duidelijk uit te leggen wat er aan de hand is begin je te schermen met allerlei termen, waar ik in ieder geval geen zak aan heb. Leg dan wat uit, in plaats van een beetje ongenuanceerd te gaan zitten blaten.

Begrijp me goed, ik twijfel niet aan je kennis, maar de strekking van je post is nou niet direct eentje waarvan ik dankjewel zou zeggen

Misschien was mijn bijdrage dan niet de geweldigste maar ik heb er geen behoefte aan dat hier één of andere malle pietje even komt vertellen dat hij met 8 jaar profi ervaring weet dat mensen, die hier met een huis tuin en keuken MySQL databaseje een hobbysite in elkaar draaien, het allemaal helemaal verkeerd doen, omdat iets nou toevallig "constraint" heet ipv "relatie". Sorry, knoeien met tabellen heet dat, hè?

[Verwijderd]

Op donderdag 25 juli 2002 13:53 schreef Zoijar het volgende:
Normaal zou ik het hier nooit over hebben, maar omdat het punt toch al naar voren kwam, ik heb een masters graad in de informatica (distributed systems, geen databases), civi award in informatica, propedeuse in wiskunde en 2 jaar profesionele ervaring. Kortom, ja ik weet wat een ER diagram is, en ik weet ook de wiskundige theorie achter normalisatie die vnl rust op hogere logica. Maar ik heb er een hekel aan als mensen zichzelf erg goed vinden

Je verdenkt mij ervan alleen te posten om te laten zien hoe goed ik ben. Als ik dan vertel dat ik dat ook ben maar niet om die reden post moet jij kotsen om het feit dat ik mezelf goed vindt. Tja, jouw probleem. Ik denk dat je de kritiek niet aan kunt, het zei zo.

Mijn punt was...en nu komt het Je moet schrijven voor je doelgroep. Alles waar het woord "tutorial" in voor komt is meestal niet van universitair niveau, en dat is maar goed ook.

Dat zeg ik toch ook niet? De tutorial bevat grove fouten, begint ergens halverwege een traject waar men normaliter niet eens iets doet omdat dat volgt uit het traject dat ervoor zit, en daarmee is de tutorial void.

No offence, maar ik heb hier gezegd dat normaliseren onzin is en dat je een methodiek moet gebruiken. Dat is me niet in dank afgenomen. Ik heb geen zin in een pissing-contest. Als jij vindt dat je het beter weet, by all means, ga lekker door...

Als ik de vragen die hier gesteld worden over databases zie, dan is zo'n tekst over normalisatie een goed hulpmiddel voor velen.

NEE!!!! Een tutorial HOE een datamodel te maken en die om te zetten naar een database, DAT is gewenst. DIE kennis ontbreekt. Een tutorial brengen die louter gaat over normaliseren, iets wat je normaliter NOOIT hoeft te doen, behalve als je aan het kloten bent zonder model, is leuk voor de moeite, maar bezorgt die mensen waar je het voor schrijft alleen maar van de regen in de drup. Ze leren nl. NIETS, ze blijven het fout doen.

Buiten dat zie ik het probleem niet in het uitleggen ervan. Het is beter om eerst de basis theorie erachter te kennen, en dan pas je tools te gebruiken. Een quote van m'n professor, "Database design is meer dan alleen naive (E)ER-mapping"

E/R model is geen database design. Het is een model dat werd gebruikt bij gebrek aan beter, maar het levert niet die abstractie op waar je naar verlangt wanneer je entiteiten en hun relaties modelleert.

En verder, agree to disagree

Mja, wat moeten we hier dan mee? "Ik maak een tutorial, die is eigenlijk niet goed, maar de doelgroep rechtvaardigt dit, iemand heeft kritiek daarop, nou dat mag" ?

[edited ivm nick-verwisseling]

[Verwijderd]

Op donderdag 25 juli 2002 14:22 schreef drm het volgende:
[..]
Goed zo. Daarmee overwin je een hoop barrieres, om met je universitaire kennis mijn "kennis" of kritiek te overrompelen. Beetje flauw om me te gaan zitten pakken op termen.

Nee, dit was geen 'pakken op termen', want wat ik aanhaalde is een groot misverstand en een van de redenen, zoniet DE reden, dat mensen nog altijd op tabelniveau met hun datamodel bezig zijn! Zeuren over termen is imho overbodig, maar relaties tussen tabellen is zeker geen 'termenkwestie'.

Omdat sommigen denken dat er relaties tussen tabellen bestaan, denken ze dat die gelijk zijn aan de relaties tussen de entiteiten die door de PK van de tabellen in kwestie worden gerepresenteerd, maar dit is lang niet altijd het geval. Vandaar dat je op TABELniveau niet aan je model moet kloten.

Verder is de tutorial geschreven om een te ontwerpen voor databases op GoT-niveau, en dit soort verhalen helpen daar echt niet aan mee. In plaats van duidelijk uit te leggen wat er aan de hand is begin je te schermen met allerlei termen, waar ik in ieder geval geen zak aan heb. Leg dan wat uit, in plaats van een beetje ongenuanceerd te gaan zitten blaten.

Mja, weer dat gezeik over het GoTniveau. Dat moet dan wel erg laag zijn of niet? Ooit bedacht dat er in dit forum ook discussies op niveau worden gevoerd, vragen op niveau worden gesteld en antwoorden op niveau worden gegeven? Hoe moet ik nu weten wat 'Het GoTNiveau' is? Zitten we hier op 'ik snap geen ruk van PHP, man!'-niveau? Ik dacht het niet.

Nu moet ik de termen uitleggen waarmee ik iets duidelijk probeer te maken... en dan is dat MIJN probleem! Wil je meepraten over databases en de theorie daarachter? Ik krijg het gevoel van wel, anders geef je geen 'uberkritische kritiek' op een tutorial, zorg dan ook dat je bagage in orde is. Kritiek leveren op iets kan iedereen, maar kritiek die niet klopt is niet erg nuttig.

Misschien was mijn bijdrage dan niet de geweldigste maar ik heb er geen behoefte aan dat hier één of andere malle pietje even komt vertellen dat hij met 8 jaar profi ervaring weet dat mensen, die hier met een huis tuin en keuken MySQL databaseje een hobbysite in elkaar draaien, het allemaal helemaal verkeerd doen, omdat iets nou toevallig "constraint" heet ipv "relatie". Sorry, knoeien met tabellen heet dat, hè?

Mja, als je het hier ziet als kleuterklasje vol met knoeiers die voor de hobby af en toe iets doen met een computer, wat doe je dan in deze discussie? Mensen die voor de hobby iets doen moeten dat vooral blijven doen zoals zij denken dat het moet. het is immers hobby en dat doe je voor de lol. Veel mensen hier echter doen development werk voor geld bij bedrijven. Die bedrijven verwachten kwaliteit. Geen hobbytroep. Als je (algemeen, niet jij) kennis niet verder reikt dan de hobbykamer, moet je niet met prof. zaken bezighouden.

Echter NERGENS staat dat deze 'tutorial' voor hobbyknutselaars was bedoeld, NOCH dat de reacties louter in dat licht moesten worden bezien. Maar goed, who carez anyway...

[Skinny]

Op donderdag 25 juli 2002 14:35 schreef Otis het volgende:

[een hele hoop tekst]

Er is een kreet "lees de draad voordat je blaat", maar ik vind dat altijd een hoog "flame" gehalte hebben, dus daarom zet ik hem hier niet neer. Dat neemt niet weg dat ik na jouw reply wel degelijk zo'n gevoel heb.

Die tutorial is van MIJ afkomstig en hij is geschreven als reaktie op een topic wat hier een paar dagen geleden voorbij kwam. Daarin werd gesproken over "normaliseren". Misschien is dat geen werkwoord, of whatever, maar feit blijft dat heel veel P&W bezoekers baat hebben bij het "iets beter" nadenken over het database ontwerp. Dat voorkomt veel problemen. Mee eens ?

Ik ben zelf ook geen database goeroe, maar probeer hier wel de kennis die ik (al dan niet met behulp van GoT) te delen met mensen die er minder verstand van hebben. Misschien had ik gisteren de titel van dit topic niet moeten laten veranderen van "normalisatie tutorial" naar "ontwerp tutorial", maar goed.. dat is gebeurd.

Otis, begrijp me niet verkeerd, ik ben het op veel punten met je eens, maar ik denk niet dat het mijn (of een ander individu hier op GoT) zijn/haar taak is om een compleet handboek over het ontwerpen van databases te maken. Daar zijn genoeg alternatieven voor. Waar IMO wel veel behoefte aan is, is een "in normaal nederlands" geschreven handleiding die wat ontwerp-issues onder de aandacht brengt.

[edit]En als er fouten in staan nodig ik je van harte uit om dat hier te melden, maar verlies niet de doelgroep uit het oog (Waar heb ik dat eerder gehoord)

[Zoijar]

Op donderdag 25 juli 2002 14:35 schreef Otis het volgende:

[..]

De 'tutorial' lezende, betwijfel ik deze uitspraak ten zeerste. Iemand met kennis van zaken had de tutorial niet met zoveel fouten opgesteld.
[..]

Mja, sorry hoor dat ik je help met je gefreubel. Ik wil ook de moeite nog wel nemen je 'tutorial' tot de grond toe af te branden als je dat liever hebt.

Ik heb nog niet alles gelezen, maar over het begin wil ik meteen even nog wat meer duideljikheid scheppen. Ik heb de tutorial niet gescreven. ... ... OOPS! foutje otis? haha

[ErectionJackson]

Op donderdag 25 juli 2002 14:35 schreef Otis het volgende:

[..]

De 'tutorial' lezende, betwijfel ik deze uitspraak ten zeerste. Iemand met kennis van zaken had de tutorial niet met zoveel fouten opgesteld.
[..]

Mja, sorry hoor dat ik je help met je gefreubel. Ik wil ook de moeite nog wel nemen je 'tutorial' tot de grond toe af te branden als je dat liever hebt.

Euhm.. Skinny != Zoijar

edit: te laat

Btw, hou het wel een beetje leuk he jongens

[drm]

Otis:
Nee, dit was geen 'pakken op termen', want wat ik aanhaalde is een groot misverstand en een van de redenen, zoniet DE reden, dat mensen nog altijd op tabelniveau met hun datamodel bezig zijn! Zeuren over termen is imho overbodig, maar relaties tussen tabellen is zeker geen 'termenkwestie'.

Laat ik het dan anders zeggen, als je een database aan 't bouwen, ben, bouw je tabelletjes. Die tabelletjes zijn gebaseerd op een "model", wat je van te voren uitdenkt. Dat snap ik wel. En dat die relaties dan vervolgens tussen je tabellen bestaan, of dat nou correct is of niet, is volgens mij alleen, om het visueel een beetje duidelijk te maken alleen maar handig. Denk aan zo'n relatie-overzicht in Access, ofzo. Wat je daar ziet zijn de tabel-definities en de relaties tussen venstertje x en venstertje y. Dat je die venstertjes geen "tabel" moet noemen, ok, best dan, maar daar ging het niet om. ajbwib

Omdat sommigen denken dat er relaties tussen tabellen bestaan, denken ze dat die gelijk zijn aan de relaties tussen de entiteiten die door de PK van de tabellen in kwestie worden gerepresenteerd, maar dit is lang niet altijd het geval. Vandaar dat je op TABELniveau niet aan je model moet kloten.

Goed, dan snappen we elkaar volgens mij nu wel

Mja, weer dat gezeik over het GoTniveau. Dat moet dan wel erg laag zijn of niet? Ooit bedacht dat er in dit forum ook discussies op niveau worden gevoerd, vragen op niveau worden gesteld en antwoorden op niveau worden gegeven? Hoe moet ik nu weten wat 'Het GoTNiveau' is? Zitten we hier op 'ik snap geen ruk van PHP, man!'-niveau? Ik dacht het niet.

Nu moet ik de termen uitleggen waarmee ik iets duidelijk probeer te maken... en dan is dat MIJN probleem! Wil je meepraten over databases en de theorie daarachter? Ik krijg het gevoel van wel, anders geef je geen 'uberkritische kritiek' op een tutorial, zorg dan ook dat je bagage in orde is. Kritiek leveren op iets kan iedereen, maar kritiek die niet klopt is niet erg nuttig.

Dat ben ik dus alleszins met je oneens. Kijk, als ik kritiek lever die volgens jou (of ieder ander) niet terecht is, kun je daar ook kritiek op leveren. Daar is het tenslotte een discussie (forum) voor. Geen enkel punt. Maar je manier van kritiek leveren is, idd, voor het GoTniveau niet geschikt. Het landt niet. Ik kan er nog wel een beetje chocola van maken, maar 't overgrote deel niet.

Mja, als je het hier ziet als kleuterklasje vol met knoeiers die voor de hobby af en toe iets doen met een computer, wat doe je dan in deze discussie? Mensen die voor de hobby iets doen moeten dat vooral blijven doen zoals zij denken dat het moet. het is immers hobby en dat doe je voor de lol. Veel mensen hier echter doen development werk voor geld bij bedrijven. Die bedrijven verwachten kwaliteit. Geen hobbytroep. Als je (algemeen, niet jij) kennis niet verder reikt dan de hobbykamer, moet je niet met prof. zaken bezighouden.

Het gaat mij er niet om dat je geen profi zaken uit mag leggen... Graag zelfs . Ik neem graag wat aan van iemand die 't weet. Maar vertel dan iets ook met de bedoeling iemand (mij in dit geval) iets te leren, of in ieder geval duidelijk te maken (te overtuigen van het feit) dat (z|m)ijn post niet klopt. En niet om een post af te zeiken met een beetje suffe flames. En dan zal ik je ongetwijfeld helemaal verkeerd begrepen hebben, maar zie dat dan ook als een uitdaging.

Echter NERGENS staat dat deze 'tutorial' voor hobbyknutselaars was bedoeld, NOCH dat de reacties louter in dat licht moesten worden bezien. Maar goed, who carez anyway...

I do

[Verwijderd]

Op donderdag 25 juli 2002 14:59 schreef Zoijar het volgende:
[..]
Ik heb nog niet alles gelezen, maar over het begin wil ik meteen even nog wat meer duideljikheid scheppen. Ik heb de tutorial niet gescreven. ... ... OOPS! foutje otis? haha

Vaag, ik dacht dit toch echt, kwam door die message van de topicstarter waar ik niet goed naar de nick had gekeken en die met jou verwarde. Ik zal ff die tekst omtrent de tutorial-kwaliteit en jouw kwaliteiten weghalen, want die snijdt dan geen hout nee.

[Zoijar]

Maakt niet uit. No offense taken Maareh, ik weet echt wel waar ik over praat hoor, ben er ook in afgestudeert

[D2k]

Otis: ipv op deze manier te discussieren is het misschien een idee om (desnoods ism de topicstarter of alleen) jezelf eens aan een stukje mbt tot dit onderwerp te richten? Of desnoods een ander onderwerp dat je hier ondergewaardeerd vind

[Verwijderd]

Op zaterdag 27 juli 2002 01:14 schreef D2k het volgende:
Otis: ipv op deze manier te discussieren is het misschien een idee om (desnoods ism de topicstarter of alleen) jezelf eens aan een stukje mbt tot dit onderwerp te richten? Of desnoods een ander onderwerp dat je hier ondergewaardeerd vind

Herkauwen wat elders op het internet haarfijn is uitgelegd is IMHO je tijd verdoen. In het kader van dit topic, kijk eens op [url="http://www.orm.net/overview.html"]http://www.orm.net/overview.html[/url]. 1 methodiek waar je wat aan hebt, en IMHO wordt het door Halpin keurig uitgelegd hoe het werkt.

Er zijn veel onderwerpen ondergewaardeerd hier, te beginnen bij de discussie 'wat is belangrijk bij softwaredevelopment', die telkens weer onder de huid van talloze discussies hier zn beknokkelde kop opsteekt Het hierboven aangeroerde 'niveaupunt' is daar mede schuldig aan: het is nl. lang niet altijd duidelijk in wat voor niveau je terecht komt. Voor je het weet zit je in een heilige huisjes gevecht dat nergens over gaat behalve het laten zien welke taal/tool/database/techniek het beste is, zonder te benadrukken wat de criteria zijn voor 'beste'. (Voorbeeld, ik manouvreerde mezelf met open ogen in een C++ fetisjisten-feestje () (hier: [url="http://gathering.tweakers.net/forum/list_messages/557279/2?limit=25"]http://gathering.tweakers.net/forum/list_messages/557279/2?limit=25[/url]) en zat ineens klem in een discussie omtrent C++'s onderdelen (wel/geen std etc). Mja, voor C++ wellicht erg belangrijke stof, voor een developer die een tool gebruikt echt intens onbelangrijk (want voldoet een taal niet omdat deze te complex is, dan neem je een andere taal). Anyway, komt er op neer: op usenet heb je .advocacy groups, die zijn er speciaal voor om over details te neuzelen, en wil je dat dan doe je dat daar. Hier heb je die niet en beland je soms in zo'n discussie waar dat niet is gewenst terwijl ik dat bv wel deed (hier) of juist wel gewenst terwijl ik dat niet deed (het voorbeeld hierboven). Lastig parket, maar goed, inherent aan het fenomeen 'forum' denk ik.

[Zoijar]

Op zaterdag 27 juli 2002 12:02 schreef Otis het volgende:
(Voorbeeld, ik manouvreerde mezelf met open ogen in een C++ fetisjisten-feestje ()

Hahaha Humor