normaliseren

dames en heren, ik heb hier heel vaak hulp gehad op het forum maar heel vaak bleek dat mijn db niet goed genormaliseerd was, en met een paar omweggetjes lukte het dan toch wat ik wilde maar nu moet ik een nieuw project doen en daar weer een website voor bouwen en nu wil ik graag de database goed op orde hebben,

mijn vraag is kan iemand mij helpen met het normaliseren van de database?
misschien een goede uitleg geven waar ik op letten moet?

ik heb hier ergens volgens mij daar een tut van gezien maar daar werd ik niet wijzer van.

bedankt alvast!

Dit is de beste uitleg: http://www.phphulp.nl/php/tutorial/overig/normaliseren/150/
Veel beter kunnen we het niet geven. Probeer heel rustig eens na te denken.

Probeer anders eerst eens de nulde normaalvorm uit. Dat is de simpelste die er is en daar schrijf je alles op wat je in de db wilt opslaan. Daarna wil ik je wel verder helpen om met dat voorbeeld de andere 3 normaalvormen uit te voeren.

Waar zijn de 2e en 3e vorm? Daarnaast zou ik email niet als sleutel hanteren, een email kan gewijzigd worden waardoor relaties die eerder gelegd zijn niet meer gelinkt zijn ( is corruptie en overhead) dus daar moet je nog op verder. TicketNummer/sleutel is al beter.

IC, even kijken hoor, een zelfgemaakte sleutel hoeft niet perse, als iets uniek is dan kan dat fungeren als de sleutel. Het is alleen wel handiger om een ID als primary key te gaan gebruiken. Email zou ik niet doen. Maar op dit moment is het sowieso nog niet goed denk ik want nu heb je nog n-n relaties. Immers, meerdere gebruikers kunnen meerdere tickets aanvragen. Snap je dit? Relaties in databases is eigenlijk best interessant namelijk.

Je hebt meerdere soorten relaties maar even kort door de bocht:
1-1
1-N
N-1
N-N

1-1 is overbodig, dan kan er gecombineerd worden,
1-N / N-1 is hetzelfde, maar dit is wat je wil. 1 op N relaties
N-N is wat je niet wil, dan heb je geen relationele database ( soms kan het helaas niet anders )

Wat je nu wil is GEGEVENS een uniek ID geven welke niet gelijk is aan email ( die kan veranderen => corrupte database, overhead )

Wat je nu wil is een ticket nummer een uniek ID geven welke gekoppeld (!) kan worden aan een gebruiker ID. Maar omdat we dan N-N relaties krijgen moeten we dit nog een keer afsplitsen ( 3e vorm ).

Dan krijg je dus:

GEBRUIKER
gebruiker_ID
email
naam
wachtwoord

TICKETS
ticket_ID
ticketSleutel
Ticketnummer

GEBRUIKER_TICKETS
gebruiker_ID
ticket_ID

Oke, als het dubbel op is kun je die weghalen inderdaad. Waar ik zelf voorstander van ben is om alle primary keys een soortgelijke naam te geven. Vaak is dat altijd ID maar om duidelijk te maken wat wat is heb ik het hier gberuiker_ID en ticket_ID genoemd.

Maar het gaat er om dat je N-N relaties wil voorkomen. Die tutorial die Wouter heeft gepost staat ook veel interessante data in, om bijvoorbeeld een webwinkel achtig idee op te zetten. Daar heb je vrij veel N-N relaties op een gegeven moment en dan wordt het koppelen interessant. Als je een keer tijd hebt zou ik die tut eens door nemen. Daar staat ook in wat ik hier boven even heb geschetst.

Het komt er simpelweg op neer dat je entiteiten gaat omschrijven. Een gebruiker, wat is uniek voor een gebruiker? naam, wachtwoord etc , dan is dat 1 entiteit. Dan heb je de tickets, dat is ook een entiteit, heeft een nummer, content, een response, een update. Oftewel, samengevoeg ook een entiteit.

Entiteiten wil je gaan koppelen ( anders zou je geen RMDB gebruiken ) dus moet je er voor zorgen dat entiteiten gekoppeld kunnen worden. Daar zijn de ID`s voor en die moeten vervolgens geen N-N relaties krijgen. Als je dat hebt, moet je ze gaan koppelen door een koppeltabel zodat je 1-N en N-1 relaties krijgt.

Succes ermee

Je moet eerst inventariseren dan normaliseren, het lijkt me sterk dat je een db hebt met 2 tabellen met ieder 3 velden.

Deze tabel heb je volgens mij niet nodig. Tenminste, als elk ticket altijd aan maar een gebruiker hangt. In dat geval kan je namelijk de gebruiker_ID opnemen in het ticket zelf.
Kunnen meerdere gebruikers aan hetzelfde ticket hangen dan heb je al een N-N relatie.

Dat laatste is waarom je apart een gebruikers tabel nodig hebt en een ticket tabel. Maar een link tabel tussen die twee is alleen nodig als er meerdere gebruikers aan meerdere tickets kunnen hangen. In dat geval heb je namelijk een N-N relatie.

Inmiddels zag ik wel dat Merijn dat ook opmerkte in zijn post, alleen zie ik dus niet dat het ook een N-N relatie is (wat jij nu bevestigt).