[MySQL/normaliseren]Kom niet helemaal uit normalisatie

[RvL]

Hallo allemaal,

zoals de titel al zegt kom ik er niet helemaal uit.

Wat is het geval? Ik ben bezig met een ledengedeelte voor een muziekvereniging. Op dit gedeelte kunnen de leden de agenda bekijken, nieuwsberichten lezen, adreslijsten opvragen en doorzoeken en afmelden voor gebeurtenissen. Ook is het mogelijk om persoonlijke gegevens in te vullen, welke op de adreslijst weergegeven zullen worden.

De pagina voor de agenda bestaat uit een tabel in HTML, met daarin alle punten. Voor elke maand is er een aparte pagina. Dit is hetzelfde bij het nieuws.

Verder hebben administrators (bestuur, ik ) de mogelijkheid om agendapunten en nieuwsitems toe te voegen.

Let wel, alle velden voor 'afmelden' hebben met het afmelden voor repetities en optredens te maken . Dit was mijn fout in de uitleg!

Nu kwam ik bij het verzamelen (0e normaalvorm) op de volgende velden (beetje lang, excuses daarvoor). Onderlijnen staat voor primaire sleutel,* is repeating group:
gebruikersID
gebruikersnaam (unique)
gebruikers_status
wachtwoord
ingelogd --> nieuw!
voornaam
tussenvoegsel
achternaam
adres
huisnummer
toevoeging
postcode
woonplaats
telefoonnummer
gsm_nummer
e_mailadres
*datum_agendapunt
*titel_agendapunt
*beschrijving_agendapunt
*locatie_agendapunt
*tijd_agendapunt
**datum_nieuwsitem
**titel_nieuwsitem
**tekst_nieuwsitem
***afmelding_gebeurtenis
***afmelding_datum
***afmelding_reden

Volgens hetgeen ik geleerd heb kom ik op de volgende 1e normaalvorm (tabellen maken van repeating groups). Wat mij geleerd is, is dat deze altijd herkenbaar gemaakt moeten zijn naar het hoofdbestand (letterlijk uit het boek, nogal raar omschreven vind ik). Dikgedrukt is tabelnaam, schuingedrukt verwijzende sleutel
Gebruikers
gebruikersID
gebruikersnaam (unique)
wachtwoord
ingelogd --> nieuw!
voornaam
tussenvoegsel
achternaam
straatnaam

edit:
straatnaam was adres

huisnummer
toevoeging
postcode
woonplaats
telefoonnummer
gsm_nummer
e_mailadres

Agenda
gebruikersID
agendapuntID
titel_agendapunt
datum_agendapunt
tijd_agendapunt
locatie_agendapunt
beschrijving_agendapunt

Nieuws
gebruikersID
nieuwsitemID
datum_nieuwsitem
titel_nieuwsitem
tekst_nieuwsitem

Afmeldingen
gebruikersID
afmelding_datum
afmelding_gebeurtenis
afmelding_reden

Nou, dat is een hele lap tekst, sorry daarvoor.

Wat nu het probleem is, is dat in de tabellen Agenda en Nieuws de gebruikersnaam niets te maken heeft met de rest van de velden in de tabel. Maar volgens wat ze mij geleerd hebben zou het zo toch moeten.

Normaal gesproken zou ik naar mij leraar gaan met deze vraag, maar die zit al 4 weken overspannen thuis. Nee, niet van mijn vragen

Natuurlijk zijn alle op of aanmerkingen van harte welkom!

edit:
Nog meer aanpassing gedaan aan de hand van de posting van Johnny en Dusty. Wijzigingen zijn aangegeven

[ Voor 20% gewijzigd door RvL op 12-11-2003 14:22 ]

[Johnny]

Normalisatie betekent niet dat alle tabellen een kolom "Gebruikersnaam" moeten hebben. Het is vaak handiger om met gebruiker id's te werken, omdat het doorzoeken en vergelijken van integers veel sneller gaat dan strings.

Het lijkt me verstandig om ook voornaam, en gebruikersnaam te scheiden aangezien mensen nogal eens de neiging hebben om dezelfde voornaam te hebben.

Het veld adres zou ik "straatnaam" noemen, het adres is namelijk straat + nummer en vaak nog postcode en woonplaats.

Is de losse datum en tijd nodig voor de agenda, of is het genoeg om een enkel DATETIME() veld of een UNIX TIMESTAMP (INT) gebruiken?

[ Voor 3% gewijzigd door Johnny op 12-11-2003 00:51 ]

[RvL]

Ik neem aan dat je met het scheiden van de voornaam van de gebruikersnaam de 1e NV bedoeld? Daar staat voornaam inderdaad niet in, das een typefoutje van mij. Er is dus een veld voor de voornaam en een veld voor de gebruikersnaam in de tabel gebruikers.

Dat van straatnaam is inderdaad een goede, daar had ik nog niet aangedacht.

Dat van DATETIME en UNIX TIMESTAMP zou ik eens uit moeten zoeken. Ik heb ze wel zien staan maar nog niet echt in verdiept. Gaat gebeuren!

Ik zal mijn eerste posting aanpassen aan wat je me verteld hebt. Wellicht (waarschijnlijk ) heb je daarna nog wel het een en ander aan te merken?

[ Voor 13% gewijzigd door RvL op 12-11-2003 01:00 ]

[dusty]

Zoals Johnny al zei, het is vrij normaal om met een gebruikersID te werken ( getalletje ) en daaraan hangt dan een gebruikersnaam. Betekent dat gebruikersID de primairy key moet zijn en op de gebruikersnaam een unique restrictie moet zitten.

Waarschijnlijk wil je ook een agenda punt een ID geven zodat je makkelijk met die punten kan werken ( toevoegen, veranderen, verwijderen). Ook zou ik juist daar de gebruikersID laten staan, kan je namelijk zien WIE de agenda punt heeft toegevoegd.

Hetzelfde geldt voor nieuws, geef het een nieuwsID zodat het makkelijker is om toetevoegen/te veranderen/te verwijderen.

Netzoals bij Nieuws, wil je over het algemeen weten wie het heeft geplaatst, als er misbruik van het systeem wordt gemaakt kan je in iedergeval als admin opzoeken wie de nieuws heeft geplaatst en actie ondernemen.

Lees nu nog eens de post van Johnny door, dan zou je moeten merken dat je zijn aanbeveling maar half hebt opgevolgd. ( gebruikersnaam weghalen en gebruikersid in de plaats zetten)

Bij afmeldingen geldt trouwens hetzelfde, je wilt alleen in de gebruikerstabel de username hebben, en verder werk je met een gebruikersID voor binnen de database. Aangezien de gebruikersID voor een persoon nooit zou hoeven te veranderen, terwijl een gebruikersnaam wel eens zou kunnen veranderen.

Waarschijnlijk wil je ook nog een veld "Gebruiker_Status" invoeren in de gebruikers tabel. Dit zodat je kan bijhouden of het betreffende account geldig is of niet. Anders moet je bij elke persoon die inlogt in de afmeldingen tabel kijken of die toevallig voorkomt.

[RvL]

Nu ik wakker ben dringt het ineens wel door. Nu je het zo zegt en ik de posting van Johnny inderdaad nog eens goed doorlees snap ik het wel.

Ik zal hier boven de posting nog eens aanpassen!

[dusty]

"afmeldingen" - gebruikersnaam -> gebruikersid

[RvL]

Uiteraard, vergeten aan te passen (vergeet wel veel )

[drm]

Dan heb ik ook nog wel een tipje: wees consequent in je naamgeving. Zie het verschil in naamgeving van de velden in agenda en nieuws t.o.v. afmeldingen

[Jaspertje]

ff een vraagje: Kan een gebruiker zich meerdere malen afmelden?

edit:

Je kan het ook een hint noemen

[ Voor 27% gewijzigd door Jaspertje op 12-11-2003 11:21 ]

[drm]

Jaspertje:
ff een vraagje: Kan een gebruiker zich meerdere malen afmelden?

edit:

Je kan het ook een hint noemen

Lijkt me stug, maar dat mag de TS beantwoorden. Verder kan dat in dit model al prima als je in de afmeldingen-tabel de timestamp (datum) in de primary key opneemt.

[Jaspertje]

drm schreef op 12 november 2003 @ 11:48:
[...]
Lijkt me stug, maar dat mag de TS beantwoorden. Verder kan dat in dit model al prima als je in de afmeldingen-tabel de timestamp (datum) in de primary key opneemt.

Lijkt mij ook, maar in dit model mag het wel..

Afmeldingen
gebruikersID
afmelding_datum
afmelding_gebeurtenis
afmelding_reden

[drm]

Jaspertje:
Lijkt mij ook, maar in dit model mag het wel..

Afmeldingen
gebruikersID
afmelding_datum
afmelding_gebeurtenis
afmelding_reden

Hm, ik begreep je hint precies andersom

[Jaspertje]

drm schreef op 12 november 2003 @ 12:14:
[...]
Hm, ik begreep je hint precies andersom

Het was ook andersom bedoeld hoor Het was niet andersom , volgens mij mag het allemaal in dezelfde tabel als gebruiker.. alleen nu kan je nog meerdere keren afmelden.. en dat is (volgens mij) een beetje raar..

[ Voor 5% gewijzigd door Jaspertje op 12-11-2003 12:16 ]

[Mickman]

Tijdens het normaliseren ga je nog geen foreign keys toepassen.

[RvL]

Jullie begrijpen het afmelden een beetje verkeerd. Wat ik met afmelden bedoel is het afmelden voor een repetitie of optreden.Inloggen zou je dus gewoon zo vaak als je wil kunnen doen, zolang de gebruikersnaam en wachtwoord maar overeenkomt. Met het veld 'ingelogd' zal het dus maar mogelijk zijn om 1 keer in te loggen (veld wordt op 1 gezet) en 1 keer uit te loggen (veld wordt op 2 gezet)

Ik zit er aan te denken/ om er nog een veld 'ingelogd' bij te doen/ga er nog een veld ingelogd bij doen waar ik 1 of 0 inzet, zodat ik kan zien wie ingelogd is.

edit:

Nu ik er nog eens over nadenk gaat dat veld er inderdaad komen, omdat je anders inderdaad meerdere in kan loggen en uit kan loggen.

@drm
Wat betreft de naamgeving moet ik je helemaal gelijk geven. Waarom ik het zo heb gedaan zou ik eigenlijk niet weten.

Zo zie je maar weer, waar meerdere mensen meedenken komt vanzelf iets goeds tevoorschijn!

[ Voor 44% gewijzigd door RvL op 12-11-2003 14:20 ]