Database Normalisatie vraag

[yevgenyquinne]

Ik ben al aardig wat topics op GoT nagegaan, sommige gaan zelfs terug tot 2001, en heb er een enkele tutorial op nageslagen [1,2,3] maar heb nog steeds het gevoel dat ik nog steeds iets fout doe. Mijn huidige versie ziet er zo uit:


De opdracht die wij moeten maken (klik) bestaat uit de volgende te normaliseren "keywords"

• User
• Week
• Name
• Total workhours (procesgegeven dus verwijderd)
• Project Number (staat als number in het word document, maar Project_number is beter te identificeren binnen een database)
• Project
• Activity
• Planned Hours
• Workhours
• Rest Hours
• Endate

Nu heb ik deze in de 0de vorm gezet, en gelijk aangegeven wat de Primary Key(PK) is (User) deze staan allemaal onderstreept. De herhalende vorm heb ik ook al aangegeven (zoals moet van onze leraar, ondanks andere tutorials en wikipedia dit tegenspreken) de PK hiervan is Project_Number.

In de 1ste vorm geef je de herhalende "keywords" hun eigen groep. In dit geval dus Project_Number tot en met Einddate. User is een Foreign Key om het project te kunnen koppelen aan een user.

In de 2de vorm verwijder je de sleutels die geen relatie hebben tot allebei de sleutels. In dit geval de uren dus. De "Hours" krijgen nu ook hun eigen groep. Over resthours twijfel ik nog, ik geloof dat dit een procesgegeven is van "planned hours - workhours = resthours". Deze zou dan wegmoeten.

De 3de vorm schoont de rest op, in dit geval is het niet erg van belang omdat het enkel om week en name gaat.

Nu ik er over denk vraag ik me af of week ook niet bij hours moet komen om een relatie te maken tussen de gewerkte uren in een week van een user op een bepaald project. Maar omdat deze er niet is uitgegaan bij de 1ste en 2de vorm vraag ik me af of ik hem bij hours mag gooien.

Dus klopt het een beetje, of maak ik naast de genoemde week en resthours ook nog andere fouten

[Janoz]

Ik ben eigenlijk alweer kwijt hoe 0, 1 en 2 waren, maar 3 weet ik wel. Wat ik iig alvast kan zeggen is dat je PK's niet allemaal kloppen. Waarom heeft een user een projectnumber? Waarom is projectnumber bij hours de pk (nu kan er maar 1 uur per project geschreven worden)? Waarom heeft project een pk bestaande uit 2 velden?

[yevgenyquinne]

Janoz schreef op vrijdag 13 april 2007 @ 12:34:
Ik ben eigenlijk alweer kwijt hoe 0, 1 en 2 waren, maar 3 weet ik wel. Wat ik iig alvast kan zeggen is dat je PK's niet allemaal kloppen. Waarom heeft een user een projectnumber? Waarom is projectnumber bij hours de pk (nu kan er maar 1 uur per project geschreven worden)? Waarom heeft project een pk bestaande uit 2 velden?

Ik dacht al dat ze niet klopte vandaar mijn vraag
Ik wou een user koppelen aan een project, maar ik zie nu ook dat het beter is om een project aan aan een user te koppelen. Vanuit het project verwijzen naar een user is beter, dan vanuit een user te verwijzen naar een project.

Ik had bij hours de projectnumber de PK gemaakt om een project te koppelen aan het aantal uren. Maar daardoor komt inderdaad een fout aan de orde waardoor je maar 1 uur per keer kan schrijven. Als ik hem dan omdraai en vanuit project verwijs naar planned hours die de PK van de tabel Hours is zou het goed moeten zijn.

Ik nam aan dat project bestaat uit een verzameling van PKs die ervoor zorgen dat er een verbinding is. Het onderstaande zou dan nu moeten kloppen volgens mij. Maar ik vraag me nog steeds af of week niet bij hours moet worden geplaatst.

[Janoz]

Tja, nu kan een project maar door 1 gebruiker gedaan worden. Verder klopt je uren tabel niet. Workhours is eerder een losse tabel (Wanneer iemand waaraan gewerkt heeft) en planned hours is eerder een eigenschap van het project. Resthours is een waarde die uit deze twee gegevens afgeleid wordt dus hoeft niet in de database (als ik de betekenis een beetje goed heb geinterpreteerd)

Waarom hoort week bij een gebruiker? Week lijkt me eerder bij de uren te horen (in welke week de uren verspijkert zijn)

Zoals ik eerder al aangaf is het hele proces van 0e naar 3e normaalvorm bij mij erg roestig. Ik werk tegenwoordig gelijk naar de 3e toe.

[ Voor 10% gewijzigd door Janoz op 13-04-2007 12:56 ]

[IntToStr]

Kun je niet beter eerst goed overleggen/vastleggen hoe alle objecten aan elkaar gerelateerd zijn?
Zaken zoals Janoz al aangeeft: een project kan door meerdere gebruikers worden gedaan (maar ook elke gebruiker kan meerdere projecten doen neem ik aan), betekent dus dat je waarschijnlijk een extra tabel wilt om een koppeling tussen gebruikers en projecten te maken.

Op deze manier kun je gewoon in 1x een goede databasestructuur opzetten zonder je zorgen te maken over die regels.

Edit: overigens zou je met die normalisatieregels op hetzelfde uit moeten komen lijkt me. Wat altijd essentieel is dat je wel met de juiste indeling begint en dan kom je weer uit op dat je eerst goed moet bespreken hoe alles gerelateerd is.

[ Voor 20% gewijzigd door IntToStr op 13-04-2007 13:03 ]

[yevgenyquinne]

IntToStr schreef op vrijdag 13 april 2007 @ 13:01:
Kun je niet beter eerst goed overleggen/vastleggen hoe alle objecten aan elkaar gerelateerd zijn?
Zaken zoals Janoz al aangeeft: een project kan door meerdere gebruikers worden gedaan (maar ook elke gebruiker kan meerdere projecten doen neem ik aan), betekent dus dat je waarschijnlijk een extra tabel wilt om een koppeling tussen gebruikers en projecten te maken.

Op deze manier kun je gewoon in 1x een goede databasestructuur opzetten zonder je zorgen te maken over die regels.

Edit: overigens zou je met die normalisatieregels op hetzelfde uit moeten komen lijkt me. Wat altijd essentieel is dat je wel met de juiste indeling begint en dan kom je weer uit op dat je eerst goed moet bespreken hoe alles gerelateerd is.

• User en name zijn aan elkaar gekoppeld. Dit wordt dus een groep genaamd Employee
• Project_numer, Project, Activity en Planned_Hours en Enddate zijn ook aan elkaar gekoppeld, deze groep noem ik project.
• Workhours week en users zijn aan elkaar gekoppeld, deze noem ik Hours
• Procesgegevens zijn Total_workhours en rest_hours, deze kunnen worden berekend en worden niet opgenomen.

Je hebt dus nu:

---

• Employee (User, name)
• Project (Project_number, project, activity, planned_hours, enddate)
• Workhours (week, workhours)

---

Om een user aan de workhours te koppelen zet je user in de groep Workhours. Bij Project doe je hetzelfde. Blokkeer je het dan om andere gebruikers toe te voegen?

[_js_]

Hoe wil jij die users in Project zetten? Of in Workhours? Jij hebt helemaal geen velden daarvoor.

Je zult een aantal koppeltabellen moeten maken, 1 om users aan projecten te koppelen en 1 om users aan workhours te koppelen.

Een koppeltabel ziet er uit als:
UserProjects (user, project)

[yevgenyquinne]

---

• Employee (User, name)
• Project (Project_number, project, activity, planned_hours, enddate)
• ProjectUser (Project)number, User)
• Workhours (week, workhours)
• WorkhoursUsers (Workhours, User )

---

Zou deze Database constructie dan goed zijn? Een User wordt gekoppeld aan een Project_number door middel van ProjectUser. Bij Workhours en user gebeurd dan precies hetzelfde.

[Janoz]

Dat lijkt er inderdaad meer op. Het enige wat je nog zou moeten doen is ID's toevoegen en deze als PK's gebruiken. ID's zijn de velden waarop uniek geidentificeerd wordt, maar hebben in de echte wereld geen betekenis.

[IntToStr]

Die werkuren zit nog niet goed lijkt me. Ik weet niet wat je precies wilt, maar als je per user wilt opslaan hoeveel uur deze heeft gewerkt per week kom je er zo niet.

Als je deze zin leest kom je al meteen tot de oplossing: sla user + hours + week op in een tabel.
Dat is alles. Verdere statistieken kun je hieruit opbouwen en zo.

[yevgenyquinne]

Janoz schreef op vrijdag 13 april 2007 @ 14:33:
Dat lijkt er inderdaad meer op. Het enige wat je nog zou moeten doen is ID's toevoegen en deze als PK's gebruiken. ID's zijn de velden waarop uniek geïdentificeerd wordt, maar hebben in de echte wereld geen betekenis.

Hoe zou ik z'n ID dan kunnen invoegen? Een extra veld maken waarin ik een unieke code inzit waarmee ik het hele veld kan oproepen?

IntToStr schreef op vrijdag 13 april 2007 @ 14:34:
Die werkuren zit nog niet goed lijkt me. Ik weet niet wat je precies wilt, maar als je per user wilt opslaan hoeveel uur deze heeft gewerkt per week kom je er zo niet.

Als je deze zin leest kom je al meteen tot de oplossing: sla user + hours + week op in een tabel.
Dat is alles. Verdere statistieken kun je hieruit opbouwen en zo.

---

• Employee (User, name, workhours, week)
• Project (Project_number, project, activity, planned_hours, enddate)
• ProjectUser (Project)number, User)

---

Deze zou goed moeten zijn. Per Employee kan een User, name, week en het aantal workhours in een week worden aangegeven. Een project kan worden gekoppeld aan een User door middel van ProjectUser. Project bestaat uit alles wat bij het project hoort.

[IntToStr]

Die id's zijn gewoon een extra veld (integer) die de primary key worden. Met iets als auto increment worden die velden automatisch gevuld met unieke waardes bij het toevoegen.

Nu kun je per werknemer maar 1 week en 1x het aantal uren opgeven. Ik neem aan dat je dit per week wilt doen? Lees: per week, dus: aparte tabel!

Maar misschien is het geen slecht idee om je iets meer in te lezen op dit gebied als je hier straks bedrijfsmatig mee aan de slag moet?

[yevgenyquinne]

IntToStr schreef op vrijdag 13 april 2007 @ 15:23:
Die id's zijn gewoon een extra veld (integer) die de primary key worden. Met iets als auto increment worden die velden automatisch gevuld met unieke waardes bij het toevoegen.

Nu kun je per werknemer maar 1 week en 1x het aantal uren opgeven. Ik neem aan dat je dit per week wilt doen? Lees: per week, dus: aparte tabel!

Maar misschien is het geen slecht idee om je iets meer in te lezen op dit gebied als je hier straks bedrijfsmatig mee aan de slag moet?

Op het moment heb ik nog mijn opleiding en zijn we net begonnen met databases. Vandaar dat ik met normalisatie aan het spelen ben. Het is helaas een feit dat de uitleg die wij van school hebben gekregen erg onoverzichtelijk en onbegrijpbaar is. Erger is dat de uren dat wij normalisatie hebben uitvallen of dat er vrij weinig behandeld wordt door de leraar. Ik sta nu zelf nog onderaan de berg van de database wereld

Als we teruggaan naar mijn vraag zou week een aparte tabel moeten hebben met het aantal uren erin, zoals dit:

---

• Employee (User, name)
• Project (Project_number, project, activity, planned_hours, enddate)
• ProjectUser (Project)number, User)
• Hours (user, week, workhours)

---

Hiermee zouden Employee, Project, ProjectUser en Hours dus de IDs kunnen worden en daarmee ook gelijk de PK.

[IntToStr]

Zoals je het nu aangeeft lijkt mij correct.

Wel een paar kanttekeningen:
Employee, Project, ProjectUser en Hours zijn de tabelnamen.
Je hebt nu andere velden onderstreept. Dit houdt in dat je die als key ziet. In principe klopt het, het zijn velden die zo een unieke key opleveren, maar zoals al eerder aangegeven, id's zijn makkelijker. User kun je al als id zien (als het geen username is hier, anders extra id toevoegen) waar je auto_increment op kan zetten, Project_number is al wel een integer waarschijnlijk, maar voeg toch een extra id veld toe met auto_increment. De andere 2 zijn goed zo.

[yevgenyquinne]

IntToStr schreef op vrijdag 13 april 2007 @ 16:04:
Zoals je het nu aangeeft lijkt mij correct.

Wel een paar kanttekeningen:
Employee, Project, ProjectUser en Hours zijn de tabelnamen.
Je hebt nu andere velden onderstreept. Dit houdt in dat je die als key ziet. In principe klopt het, het zijn velden die zo een unieke key opleveren, maar zoals al eerder aangegeven, id's zijn makkelijker. User kun je al als id zien (als het geen username is hier, anders extra id toevoegen) waar je auto_increment op kan zetten, Project_number is al wel een integer waarschijnlijk, maar voeg toch een extra id veld toe met auto_increment. De andere 2 zijn goed zo.

We zijn nog niet zover dat we met databases mogen spelen. Tot nu toe willen ze alles op papier houden. (Dat weerhoud mij er dan weer niet van om eens een weekend lang met databases te gaan klieren) dus auto_increment zal ik later tegenkomen. IDs zal ik onthouden.

Denk dat ik er goed aan doe om nog even alles door te nemen op de site van o.a MySQL en wikipedia. Als iemand nog een goede tutorial of algemene documentatie voor mij heeft. Graag!

Bedankt

[YakuzA]

Ik zou zelf een schema maken wat er zo uitziet:

---

• Employees (UserID (PK), user, name)
• Projects (ProjectID (PK), project, activity, planned_hours, enddate)
• Hours (HID (PK), UserID (FK), ProjectID (FK), week, workhours)

---

Eventueel kan de HID eruit gelaten worden

[yevgenyquinne]

YakuzA schreef op vrijdag 13 april 2007 @ 20:37:
Ik zou zelf een schema maken wat er zo uitziet:

---

• Employees (UserID (PK), user, name)
• Projects (ProjectID (PK), project, activity, planned_hours, enddate)
• Hours (HID (PK), UserID (FK), ProjectID (FK), week, workhours)

---

Eventueel kan de HID eruit gelaten worden

Project_number moet er nog bij Dan klopt hij inderdaad met mijn opdracht denk ik ^^

De UserID in Hours zorgt ervoor dat de workhours aan de User kunnen worden gekoppeld.
De ProjectID in Hours zorgt ervoor dat er een ProjectID aan de workhours kunnen worden gekoppeld. En uiteindelijk kan via Hours de User worden gekoppeld aan een ProjectID.

Dat is tenminste wat ik er nu van begrijp

[YakuzA]

Klopt inderdaad,

Eventueel zou je dingen kunnen inbouwen als 1 userID binnen projects op te nemen wat de manager van dat project voorsteld oid.
Maar verder lijkt me dit het wenselijke model, zonder koppeltabellen die eigenlijk alleen nodig zijn bij n-tot-n relaties en niet voor deze 1-tot-n relaties

(PK)'s in dit model zijn gewoon autoincrement velden in je database, of een uniek getal zoals een personeelsnummer.

[ Voor 16% gewijzigd door YakuzA op 13-04-2007 23:01 ]

[dB90]

In database theorie zou je geen ID veld nodig moeten hebben om een rij uniek te identificeren. Dat dit in de praktijk vaak het makkelijkst is ben ik met je/jullie eens, maar als je leraar een beetje precies is qua theorie rekent hij ID-velden als fout, tenminste dat deed die van mij wel! Als je goed normaliseert dan zou je één attribuut over moeten houden dat een tuple (rij) als uniek kan identificeren.

[yevgenyquinne]

dB90 schreef op vrijdag 13 april 2007 @ 23:17:
In database theorie zou je geen ID veld nodig moeten hebben om een rij uniek te identificeren. Dat dit in de praktijk vaak het makkelijkst is ben ik met je/jullie eens, maar als je leraar een beetje precies is qua theorie rekent hij ID-velden als fout, tenminste dat deed die van mij wel! Als je goed normaliseert dan zou je één attribuut over moeten houden dat een tuple (rij) als uniek kan identificeren.

I See, vanavond even verder met normaliseren dan

[Lustucru]

Voor zover ik heb kunnen nagaan is dat repeterende groepen gedoe een hollands didactisch uitvindinkje uit de jaren tachtig, om het normaliseren dichter te trekken bij wat toen bekend was: de kaartenbak. Wat jij opschrijft komt overeen met een projectregistratie waarbij er bij project één kaart is waarop van alle medewerkers alle uren worden bijgehouden. Dan is de hollandse methode uitermate verwarrend. Wat mij betreft mag die zo snel mogelijk afgeschoten worden. Ik zou iig de discussie met je docent met liefde en plezier aangaan.

Ga ervoor het gemak even vanuit dat iedere medewerker voor ieder project kaart heeft waarop hij zijn uren bijhoudt. Dan wordt het al direct een stuk makkelijker:

1NV: tabel moet atomair zijn met een unieke key die een rij uniek identificeert. Dat kun je op twee manieren bereiken: of te wel per sleutel repeterende velden afsplitsen of de sleutel uitbreiden. In het geval van een kaart per medewerker per project wordt het simpel:

{userid,projectid}, usergegevens, projectgegevens
[userid,projectid], tijdgegevens

2 NV:
Alleen afhankelijkeheden van de hele sleutel:
{userid,projectid}
{userid} usergegevens
{projectid} projectgegevens
[userid,projectid] tijdgegevens

tricky is hierbij de week. Worden medewerkers per week ingepland, worden uren per week geregistreerd? In zo'n geval kun je theoretisch overwegen om ook weeknummer aan de sleutel toe te voegen.

3 NV:
Alleen afhankelijkheden van de sleutel en geen onderlinge afhankelijkheden. Als er sprake is van weekplanningen en weekregistratie dan moet je die hier nog apart nemen, anders zou in dit geval de 3 Nv gelijk zijn aan de 2e.

[yevgenyquinne]

Volgens mijn leraar zou het het volgende moeten zijn:

0NV
Account{User, name, project_number, project, activity, planned_hours, work_hours, endate}
# Er wel van uitgaande dat week een proces gegeven was

1NV
Projectregel {Project_number, project, activity, planned_hours, workhours, enddate}
account {user, naam,projectnumber,activity}
# er van uitgaande dat via account een koppeling aan een project kan worden gemaakt

2NV
Project {Project_number, projectnaam}
Projectregel{Project_number, activity, planned_hours, workhours, enddate}
User {User, naam}
Account {user, projectnumber, activity}

3NV
Gelijk aan 2NV

---

Hij gaf wel toe dat de database nooit geheel zou kloppen, en databases zoals we ze nu op papier maken er altijd van uitgaande dat de 4de tot en met 7de vorm niet bestaat iemand zijn kop zou kosten binnen een bedrijf. Andere opdrachten zijn nog vreemder opgebouwd zonder enige extra informatie, deze onthoudt ik iedereen maar ^^.

De 4de tot de 7de normaalvorm mogen ze niet geven volgens de examencommissie en dat soort andere regeltjes.

[ Voor 4% gewijzigd door yevgenyquinne op 16-04-2007 17:12 . Reden: Extra zin ]