[SQL DB]hulp voor goede normalisering

[Mastruberik]

Hallo,

ik weet niet of deze topic op de goede plaats staat, maar zag hier nog 1 topic staan met dezelfde onderwerp.

Zal iemand mij kunnen helpen door even tekijken naar de normalisering die hier onder staat of die goed en logisch is?

Het is niet de complete database. Het word constant uitgebreid. Tot zo ver is het geschikt gemaakt om de voorraad bij te houden en om in te kunnen kopen. Er komen artikelen vanuit de voorraad naar de projecten.

Om de artikelen in de voorraad te krijgen moet het ingekocht worden. De tabel Inkoop_prijs dient als ware als een subtabel voor artikelen tabel, zodat de prijsverschillen bij gehouden kan worden.

Artikelen
id
Code
Naam
Omschrijving
Groep

Project
id
Naam
Omschrijving
Klant
Status

Projectartikelen
Id
Projectid
Artikelid
Artikelaantal
I_prijs

Inkoop
Id
Artikelid
Aantal_artikel
I_prijs
Verkoperid
Status

Verkoper
id
Naamwinkel
Woonplaats

Inkoop_prijs
Id
Artikelid
Aantal
I_prijs

bijvoorbaatdank

[Cyphax]

Het eerste dat me opvalt is dat je niet al te consistent bent met je tabel- en veldnamen. Inkoop heeft veld Id en Verkoper heeft veld id, en je hebt ook weer artikelid. Je hebt ook tabel Verkoper en Project, maar dan ook weer Artikelen. Dat staat los van of je model goed genormaliseerd is of niet.
Je laat ons een beetje gokken naar vreemde sleutels enzo (ik kan ze wel uit de veldnamen halen maar of het ook echt vreemde sleutels zijn en niet veldnamen die je zo toevallig hebt genoemd kan ik niet ruiken).
Je kunt beter een plaatje posten dan met een overzicht, dat zegt veel meer dan dit.

Mijn tip: lees een artikel over normaliseren, dan heb je geen controle van ons nodig hoor.
http://dev.mysql.com/tech...tro-to-normalization.html
http://databases.about.co...ducts/a/normalization.htm
http://www.databasejournal.com/sqletc/article.php/1428511

[ Voor 35% gewijzigd door Cyphax op 06-06-2006 10:18 ]

[Mastruberik]

oke, zal plaatje proberen te maken, uhm is er een functie mysql dat er een mooie overzicht komt?

Maar ik had voor heen de veldnamen als "tabel_veldnaam". Dat was voglens paar lui van een andere forum overbodig en meer werk. Dus artikel id, is eigenlijk een aanduiding dat het de id van de artikelen (-en) tabel is. Maar los van de benamingen, aangezien er inderdaad niet veel van klopt volgens de regels van de normalisatie, klopt dit dan?

zodra er een tabel naam met een veldnaam komt, betekent dat het via sql gekoppeld word. Heb wel sleutels aangemaakt, maar dat is meer een gewoonte vanwege acces gedoe. Werk eigenlijk alleen met sql en php, zonder relaties te leggen in apache.(via where ="bla bla").(begin beetje te twijfelen en is relaties leggen in apache ook wel sneller werken)

[Cyphax]

Mastruberik schreef op dinsdag 06 juni 2006 @ 10:23:
oke, zal plaatje proberen te maken, uhm is er een functie mysql dat er een mooie overzicht komt?

Maar ik had voor heen de veldnamen als "tabel_veldnaam". Dat was voglens paar lui van een andere forum overbodig en meer werk. Dus artikel id, is eigenlijk een aanduiding dat het de id van de artikelen (-en) tabel is. Maar los van de benamingen, aangezien er inderdaad niet veel van klopt volgens de regels van de normalisatie, klopt dit dan?

tabel_veldnaam is inderdaad niet echt nodig, je kunt die veldnamen bereiken met tabelnaam.veldnaam. Toch zegt "id" eigenlijk helemaal niets, vooral niet als je straks een keer een join hebt en je hebt 2 id's, dan moet je wel met aliasses gaan werken.

zodra er een tabel naam met een veldnaam komt, betekent dat het via sql gekoppeld word.

Huh? You lost me here.

Heb wel sleutels aangemaakt, maar dat is meer een gewoonte vanwege acces gedoe. Werk eigenlijk alleen met sql en php, zonder relaties te leggen in apache.(via where ="bla bla").(begin beetje te twijfelen en is relaties leggen in apache ook wel sneller werken)

Relaties leggen in apache? Wat voor sleutels heb je aangemaakt? (maak iig onderscheid tussen vreemde sleutels (foreign keys) en primaire sleutels (primary keys).
Wat voor DBMS gebruik je trouwens?

[Mastruberik]

Hoop dat het zo wat duidelijker is. Er missen wel wat lijnen, maar alle velden zijn 1 regel. Sorry voor de slordigheid:)



Alle ID velden zijn keys.

[ Voor 45% gewijzigd door Mastruberik op 06-06-2006 10:46 ]

[Mastruberik]

Cyphax schreef op dinsdag 06 juni 2006 @ 10:13:
Het eerste dat me opvalt is dat je niet al te consistent bent met je tabel- en veldnamen. Inkoop heeft veld Id en Verkoper heeft veld id, en je hebt ook weer artikelid. Je hebt ook tabel Verkoper en Project, maar dan ook weer Artikelen. Dat staat los van of je model goed genormaliseerd is of niet.
Je laat ons een beetje gokken naar vreemde sleutels enzo (ik kan ze wel uit de veldnamen halen maar of het ook echt vreemde sleutels zijn en niet veldnamen die je zo toevallig hebt genoemd kan ik niet ruiken).
Je kunt beter een plaatje posten dan met een overzicht, dat zegt veel meer dan dit.

Mijn tip: lees een artikel over normaliseren, dan heb je geen controle van ons nodig hoor.
http://dev.mysql.com/tech...tro-to-normalization.html
http://databases.about.co...ducts/a/normalization.htm
http://www.databasejournal.com/sqletc/article.php/1428511

Ik heb thuis ook boeken over normalisatie en weet wel het 1 en ander erover, maar het gaat meer om het systeem. Of de manier wel oke is. Misshcien dat dit te omslachtig is of juist niet logisch. of dat het niet gaat werken. Voor ik alles ga uitwerken, wou ik wat meer zekerheid hebben. Zat ook beetje met de inkoopprijzen, als het veranderd moet de oude prijzen wel blijven bestaan en achter halen te wezen. (dan kan als het goed is op deze manier, alles blijft in de db)

[Cyphax]

Inkoop.Id doe je niets mee, dat is jammer. Kun je zo'n rij niet anders uniek identificeren?
(van die id's zijn nogal betekenisloos, dus als het niet hoeft: niet gebruiken)
Hetzelfde geldt voor Inkoop_prijs en Projectartikelen.

[ Voor 18% gewijzigd door Cyphax op 06-06-2006 10:52 ]

[Mastruberik]

Cyphax schreef op dinsdag 06 juni 2006 @ 10:51:
Inkoop.Id doe je niets mee, dat is jammer. Kun je zo'n rij niet anders uniek identificeren?
(van die id's zijn nogal betekenisloos, dus als het niet hoeft: niet gebruiken)
Hetzelfde geldt voor Inkoop_prijs en Projectartikelen.

Oke, dus de id zonder waarde weg halen.Had ze allemaal wel neergezet, omdat het eigenlijk beetje standaad is(vind ik) en zodat elke regel een eigen nummer krijgt.

waarom is het jammer dat er niks met inkoop.id gedaan word?

----- niet gemeld, maar elke id veld is een key met tijdelijk autonummering van apace. Later via een functie.

[ Voor 12% gewijzigd door Mastruberik op 06-06-2006 11:01 ]

[Cyphax]

Mastruberik schreef op dinsdag 06 juni 2006 @ 10:59:
waarom is het jammer dat er niks met inkoop.id gedaan word?

Het is een betekenisloos veld dat er zo een beetje voor de kat z'n viool in staat, of niet? Dat maakt het er niet duidelijker op.

----- niet gemeld, maar elke id veld is een key met tijdelijk autonummering van apace. Later via een functie.

Waarom noem je weer Apache (neem ik aan)?

[Mastruberik]

Nou omdat ik voor heen veel met acces werkte, daar was het volgens mij een must om met relaties te werken en met keys.

Met sql en php gaat het op een andere manier naar mijn mening of ik doe iets constant fout. Maar met php en sql doe ik het eigenlijk handmatig. Noem apache, uhm eigenlijk nutteloos. Komt omdat ik het via phpmyadmin invoer.

Probeer het zo duidelijk mogelijk te vertellen . Is niet 1 van mijn sterkste kanten:(.

Maar de id velden staan er inderdaad voor de kat met de viool in de database en kunnen weg.(maar het maakt het niet overzichtelijker op, maar is het niet handig om elke regel een eigen id nummer te geven op die manier?)

alvast bedankt voor de reacties en de tijd.

[Cyphax]

Mastruberik schreef op dinsdag 06 juni 2006 @ 11:19:
Nou omdat ik voor heen veel met acces werkte, daar was het volgens mij een must om met relaties te werken en met keys.

Dat komt omdat dat eigenlijk zo hoort bij databases.

Met sql en php gaat het op een andere manier naar mijn mening of ik doe iets constant fout. Maar met php en sql doe ik het eigenlijk handmatig. Noem apache, uhm eigenlijk nutteloos. Komt omdat ik het via phpmyadmin invoer.

Aahh dus je gebruikt MySQL. Waarschijnlijk gebruik je standaard MyISAM tabellen, die hebben geen ondersteuning voor foreign keys. Dat verhaal laat maar even vallen dan.

Maar de id velden staan er inderdaad voor de kat met de viool in de database en kunnen weg.(maar het maakt het niet overzichtelijker op, maar is het niet handig om elke regel een eigen id nummer te geven op die manier?)

Het hangt er een beetje vanaf. Elke rij moet uit een unieke sleutel hebben, dat vang je af door een auto_increment-veld toe te voegen. Maar misschien moet een combinatie van twee andere velden ook uniek zijn, dan kun je daar beter de primary key op zetten. Dan heb je daar een index op en je voorkomt duplicate waarden. Je moet daarvoor even nagaan hoe zo'n rij zichzelf uniek moet identificeren.

[Mastruberik]

Cyphax schreef op dinsdag 06 juni 2006 @ 11:24:
[...]

Dat komt omdat dat eigenlijk zo hoort bij databases.

[...]

Aahh dus je gebruikt MySQL. Waarschijnlijk gebruik je standaard MyISAM tabellen, die hebben geen ondersteuning voor foreign keys. Dat verhaal laat maar even vallen dan.

[...]

Het hangt er een beetje vanaf. Elke rij moet uit een unieke sleutel hebben, dat vang je af door een auto_increment-veld toe te voegen. Maar misschien moet een combinatie van twee andere velden ook uniek zijn, dan kun je daar beter de primary key op zetten. Dan heb je daar een index op en je voorkomt duplicate waarden. Je moet daarvoor even nagaan hoe zo'n rij zichzelf uniek moet identificeren.

Gebruik inderdaad mysql, maar geen myisam. Daar werd ik al voor gewaarschuwd. Maak gebruik van InnoDB. En alle id velden zijn voorzien van primary key met autoincrement om het uniek te maken. Maar ik heb zelf nog nooit met foreign key gewerkt.

[Cyphax]

Mastruberik schreef op dinsdag 06 juni 2006 @ 11:36:
[...]


Gebruik inderdaad mysql, maar geen myisam. Daar werd ik al voor gewaarschuwd. Maak gebruik van InnoDB. En alle id velden zijn voorzien van primary key met autoincrement om het uniek te maken. Maar ik heb zelf nog nooit met foreign key gewerkt.

Foreign keys
Als je dan toch gebruik maakt van InnoDB, maak dan foreign keys aan, dat komt de integriteit van je database alleen maar ten goede.

[GigaDave56]

Zowel in de tabel "Inkoop_prijs" als "Inkoop" zie ik een veld met de waarde "I_prijs". Is dat gedaan om een evt korting te verrekenen?

[ Voor 12% gewijzigd door GigaDave56 op 06-06-2006 11:52 . Reden: leestekens tekort... ]

[kenneth]

Lijkt me om de inkoopprijs op het moment van de inkoop te bepalen, zodat een wijziging van de inkoopsprijs geen terugwerkend effect heeft.

[Mastruberik]

GigaDave56 schreef op dinsdag 06 juni 2006 @ 11:52:
Zowel in de tabel "Inkoop_prijs" als "Inkoop" zie ik een veld met de waarde "I_prijs". Is dat gedaan om een evt korting te verrekenen?

nee, er word niet gewerkt met kortingen. de Inkoop_prijs table is voor het geval er een artikel een prijs verhoging heeft gekregen. Als er nog 10 dezelfde artikelen van de oude prijs in voorraad ligt en de prijs gaat omhoog, dan komt er een extra regel met het aantal artikelen van de nieuwe prijs. Zodat de 10 oude artikelen voor de oude prijs staat geregistreed. Dus het is min of meer een sub tabel voor artikelen.

bedankt voor linkje, ben ff aan kijken hoe het foreign key werkt:) lijkt weer op acces gedoe. met veel voordelen

[whoami]

Cyphax schreef op dinsdag 06 juni 2006 @ 10:51:
Inkoop.Id doe je niets mee, dat is jammer. Kun je zo'n rij niet anders uniek identificeren?
(van die id's zijn nogal betekenisloos, dus als het niet hoeft: niet gebruiken)
Hetzelfde geldt voor Inkoop_prijs en Projectartikelen.

Natural keys zijn mooi in theorie, maar in de praktijk zorgen ze -of kunnen ze- voor problemen zorgen. Stel bv dat je je veld, dat toevallig een natural PK is, gaat gaan updaten, dan mag je alle FK's die die waarde hebben ook gaan updaten. Dat kan nogal wat overhead kosten (ook qua her-indexeren).

Dus: gebruik liever surrogate primary keys (velden zoals blaId dus, die eigenlijk helemaal geen betekenis hebben), die nooit van waarde hoeven te wijzigen.
(Maar deze discussie is hier al een paar keer gevoerd, dus ik ga er niet veel dieper op ingaan. Als je wat meer informatie hieromtrent wil, kan je mbhv de GoT search wel eea vinden).

[EfBe]

whoami schreef op dinsdag 06 juni 2006 @ 12:22:
[...]

Natural keys zijn mooi in theorie, maar in de praktijk zorgen ze -of kunnen ze- voor problemen zorgen. Stel bv dat je je veld, dat toevallig een natural PK is, gaat gaan updaten, dan mag je alle FK's die die waarde hebben ook gaan updaten. Dat kan nogal wat overhead kosten (ook qua her-indexeren).

Updaten van natural keys zou natuurlijk in theory niet hoeven, immers het is een uniek identificerend attribute. Echter omdat ze deel uitmaken van de data van de entity, loop je kans dat data foutief wordt ingegeven (typo op formpje oid) en later dus gewijzigd moet worden en dan loop je dus wel het risico dat je moet updaten, met alle gevolgen van dien.

[Cyphax]

whoami schreef op dinsdag 06 juni 2006 @ 12:22:
[...]

Natural keys zijn mooi in theorie, maar in de praktijk zorgen ze -of kunnen ze- voor problemen zorgen. Stel bv dat je je veld, dat toevallig een natural PK is, gaat gaan updaten, dan mag je alle FK's die die waarde hebben ook gaan updaten. Dat kan nogal wat overhead kosten (ook qua her-indexeren).

In de praktijk zijn ze meestal ook handig, het enige jammere is dat mensen zonder nadenken klakkeloos overal ID's gaan toevoegen in tabellen waar dat helemaal geen goed idee is, zoals bij van die koppeltabelletjes als Projectartikelen.
Het enige wat ik daarom eigenlijk wil zeggen is: denk er eerst over na. Ik zal de laatste zijn die die surrogaatsleutels in de ban doet.

[Mastruberik]

meeste wat ik met php en sql doe is eigenlijk met die koppeltabellen als het nodig was. Maar dan moet je veel zelf doen. Heb me nooit echt goed verdiept in de foreign key met mysql, omdat de handmatige manier met veel onnodige id velden ook goed werkte. Dat waren vaak minder complexe databases uit eindelijk.

Deze database word uiteindelijk wel complex en er komt nog veel meer bij in de toekomst. Dus ben al heeeel blij met deze informatie en stuk wijzer geworden.

nogmaals bedankt......

[ Voor 11% gewijzigd door Mastruberik op 06-06-2006 13:38 ]

[GigaDave56]

Mastruberik schreef op dinsdag 06 juni 2006 @ 12:10:
[...]
nee, er word niet gewerkt met kortingen. de Inkoop_prijs table is voor het geval er een artikel een prijs verhoging heeft gekregen. Als er nog 10 dezelfde artikelen van de oude prijs in voorraad ligt en de prijs gaat omhoog, dan komt er een extra regel met het aantal artikelen van de nieuwe prijs. Zodat de 10 oude artikelen voor de oude prijs staat geregistreed. Dus het is min of meer een sub tabel voor artikelen.

Onze inkoper ziet me al aankomen met dit verhaal. "Leuk bedacht, maar helaas", zegt ie dan, "is het artikel duurder geworden terwijl we voorraad hebben dan is onze voorraad nu meer waard."

Natuurlijk kan een prijsverhoging wel interessant zijn, als jij een van de weinige bent die het artikel nog voor de oude prijs kan leveren, maar dan moet die verhoging wel substancieel zijn (boven inflatie correctie bv). En dat komt minder vaak voor dan kortingen...

Maar goed, dit heeft verder weinig met normalisatie te maken.

[Mastruberik]

GigaDave56 schreef op dinsdag 06 juni 2006 @ 13:37:
[...]
Onze inkoper ziet me al aankomen met dit verhaal. "Leuk bedacht, maar helaas", zegt ie dan, "is het artikel duurder geworden terwijl we voorraad hebben dan is onze voorraad nu meer waard."

Natuurlijk kan een prijsverhoging wel interessant zijn, als jij een van de weinige bent die het artikel nog voor de oude prijs kan leveren, maar dan moet die verhoging wel substancieel zijn (boven inflatie correctie bv). En dat komt minder vaak voor dan kortingen...

Maar goed, dit heeft verder weinig met normalisatie te maken.

dit is geen inkoop voor winkel.......... gaat om administratie. Artikelen worden gebruik in projecten. er moet een eerlijke uitdraai kunnen komen voor andere instanties.

Even terug komen op project artikelen, ik zal daar dus id weg kunnen laten en projectid als foreignkey moeten maken en artikelid als primary key? aangezien die uniek blijft.

id in inkoopprijs moet blijven anders is er volgens mij geen uniek key. Aangezien de artikel id hetzelfde blijft als er 2 artikelen in staan met een prijs verschil. En Artikelid zal dan de foreign key moeten worden?

Er Zijn meer velden die als foreign key moeten, maar zat even over deze 2 te prakiseren.

[ Voor 27% gewijzigd door Mastruberik op 06-06-2006 14:21 ]

[Mastruberik]

Heb nu uit eindelijk dit als normalisatie met FK`s:



Heb nog es alle ID velden na gekeken, maar alleen die van artikelen kon weg. Bij de andere tabellen kon het niet, anders is er geen unieke veld. Misschien met een combinatie wel, maar volgens mij is dat niet zo belangrijk toch? Werkt sneller volgens mij. Of is het een must?

Bij artikelen kon die veld wel weg, omdat elke artikel een eigen code krijgt voor zo`n barcode apparaat.

Bedankt voor de reacties en hulp. Als er niet meer gereageert word, mag er wel een slotje op.

[EfBe]

Ik denk trouwens dat het voor jou wel verstandig is om eens wat te gaan lezen over Object Role Modelling (ORM) http://www.orm.net. Daarmee leer je bv op een abstract niveau met je entities en attributes om te gaan en niet ad-hoc met je tables te werken. Het leuke is dat je via ORM meteen in de 3e normaalvorm zit (minimaal).