Archief - normalisatie probleem

USER ID (hoofds)
Voornaam
Achternaam
Tussenvoegsel
Geslacht
Email adres
Wachtwoord
Land
Taal
Nieuws
Omschrijving
Branche
Zak doeleinden


Dit zijn dus men gegevens (afleidbare al verwijderd). De USER ID als hoofdsleutel heb ik zelf toegevoegd. Het probleem zit hem bij de subsleutel, mag ik er meerdere aanmaken? Dit was een tip die ik had gekregen =>

"Inderdaad in elke tabel een bep. id om iedere lijn uniek aan te duiden is een zeer goede oplossing voor jullie problemen hoor.
Gewoon naam en voornaam samenvoegen geeft geen 100% zekerheid dat er nooit iemand met identiek dezelfde naam kan voorkomen. Als dit wel het geval is, heb je een groot probleem, dus oplossing is een zelf gekozen sleutel toe te voegen, voor een tabel met persoonsgegevens kan je dan bv. denken aan "persoon_id".

http://users.telenet.be/jonasis1/Pics/ttmp.GIF

Dit bekom ik dan (dus voor de 2de normaalvorm) maar ik twijfel er zeer sterk aan... Ik heb dus overal zelf subsleutels aangemaakt omdat ik geen mogelijkheid zie om herhalende gegevens in een deelgroep te krijgen...

Ik zal proberen te helpen, maar ik ben er nooit echt een crack in geweest .

Als ik die foto bekijk. Zie ik toch wa rare dingen. bv: geslacht in afkomst tabel? Ik zou da laten in de user tabel.

Na het normaliseren zijn die USER ID's geen primaire sleutels meer, maar foreign keys. Die primaire sleutels voor die andere tabellen zijn volgens mij goed.

Voor zakelijke doeleinden zou ik geen aparte tabel maken.

Als ik de bal volledig mis sla, mag je het gerust zeggen .

Ooit allemaal gekunnen, nu weet ik nog maar amper hoe te beginnen.

Nu maken wij structuren ingewikkelder dan op school toen, en dat gebeurt allemaal puur op gevoel. Klopt er achteraf toch iets niet, dan past ge dat gewoon snel aan.

Voornaam t.e.m. taal zou ik in eenzelfde tabel steken.

En de laatste 4 in 1 of meerdere aparte tabelletjes, naargelang x-aantal keren ze kunnen voorkomen bij 1 persoon. En gewoon met een foreign key verwijzen.