[DB] Denkfout in ontwerp

[paulus4ever]

Sinds een paar dagen ben ik bezig om een database op te zetten voor een beginnend bedrijf dat kado's voor medewerkers van andere bedrijven regelt.
Iedere vrijdag wil hij kijken welke mensen van welke bedrijven de volgende week jarig zijn.

Edit* Hij gaat dan zelf de bedrijven af en geeft de kado's voor de jarige medewerkers af.


Ik heb op dit moment het volgende ontwerp al (gemaakt met Dezign v4):



Het probleem is dat het bedrijf wil weten welke contactpersoon de bestelling geplaatst heeft.
Nu heb ik tussen 'bedrijf' en 'bestelling' een relatie geplaatst, maar is het niet handiger om 'contactpersoon' eraan te koppelen ?
Of zou het beter zijn om een nieuwe relatie tussen 'bestelling' en contactpersoon te maken ?


Een opmerking:

het model is nog lang niet af, dus gelieve niet helemaal af te kraken
Tips voor attributen en tabellen zijn altijd welkom.

[ Voor 31% gewijzigd door paulus4ever op 18-06-2006 15:15 . Reden: Plaatje aangepast ]

[mithras]

Als bedrijven willen weten wie er heeft besteld, is het beter om het contactpersoon eraan te koppelen. Als je contactpersonen-id's met maar een bedrijf gekoppeld zijn (en dat is het geval) kan dit makkelijker zijn.

[ Voor 3% gewijzigd door mithras op 18-06-2006 14:05 ]

[webinn]

ik zie ff wat duplicatie zet beter je "jarigen" en "contactpersonen" in 1 tabel, desnoods met een bepaalde type ID ofzo, beter voor uitbreidingen naar de toekomst toe, een contactpersoon kan immers ook jarig zijn

[paulus4ever]

webinn schreef op zondag 18 juni 2006 @ 14:08:
ik zie ff wat duplicatie zet beter je "jarigen" en "contactpersonen" in 1 tabel, desnoods met een bepaalde type ID ofzo, beter voor uitbreidingen naar de toekomst toe, een contactpersoon kan immers ook jarig zijn

Ja, daar zat ik eigenlijk ook nog mee, maar dat was weer voor latere zorg en normalisatie...
Ga de tabel 'contactpersoon' hernoemen naar 'medewerker' met een atribuut conactpersoon en een geboortedatum erbij... Dan kan de tabel 'jarigen' idd vervallen.

[Kama]

Je kunt gewoon een 1:N relatie tussen contactpersoon en bestelling leggen. Dan komt op bestelling dus een FK naar contactpersoon. Ik zou die niet de bestaande relatie tussen bestelling en bedrijf laten vervangen. Een bedrijf is nl de "eigenaar" van de bestelling, krijgt de rekening etc. Een contactpersoon is iemand die ook weer kan verdwijnen, of kan veranderen...

Ik ben het ermee eens dat contactpersoon en jarige dubbele data op gaat leveren. Ik zou contactpersoon versimpelen tot een tabel met alleen een FK naar bedrijf een een FK naar jarige en logingegevens. (Jarige kun je dan beter "persoon" noemen).

Overigens. Op categorie zie ik de FK subcategorie_id staan. Ik denk dat je supercategorie bedoelt.

[ Voor 26% gewijzigd door Kama op 18-06-2006 14:22 ]

[paulus4ever]

Kama schreef op zondag 18 juni 2006 @ 14:18:
Je kunt gewoon een 1:N relatie tussen contactpersoon en bestelling leggen. Dan komt op bestelling dus een FK naar contactpersoon.

Is dit de beste optie of toch bestelling aan (contact-)persoon hangen ?

Overigens. Op categorie zie ik de FK subcategorie_id staan. Ik denk dat je supercategorie bedoelt.

De gedachte is dat het een sub-categorie wordt, maar hij hangt idd onder een super of hoofdcategorie.
Misschien toch logischer om te hernoemen ja.


Dit is nu het tussentijdse resultaat mbv jullie opmerkingen:

[ Voor 10% gewijzigd door paulus4ever op 18-06-2006 14:36 . Reden: Nieuwe versie gemaakt ]

[Kama]

paulus4ever schreef op zondag 18 juni 2006 @ 14:25:
[...]
Is dit de beste optie of toch bestelling aan (contact-)persoon hangen ?

Zie mijn edit Stel je zou cascading zou willen toepassen, dan zou je dat op de relatie bedrijf->bestelling willen doen en niet op de relatie contactpersoon->bestelling.
(Cascading via bedrijf->contactpersoon->bestelling is ook niet goed natuurlijk, je wilt gewoon niet dat een wijziging op contactpersoon je bestelling beinvloedt)

Je hebt nu wel de mogelijkheid om een contactpersoon aan een bestelling te hangen die niet bij het bedrijf hoort. Hier zou je een constraint op kunnen zetten.

Edit: Extra commentaar op je db2.png: Ik vind het verwijderen van de entiteit contactpersoon niet slim. Een contactpersoon is namelijk een relatie/rol die bepaalde personen met een bedrijf hebben, maar niet alle personen. (zie mijn originele post hierover, maar nu ik die teruglees was ik misschien wat onduidelijk. Ik zou contactpersoon en jarige beiden laten bestaan, maar contactpersoon in afgeslankte vorm). Verder hierboven mijn mening over de relatie bedrijf/bestelling die nu weg is.

[ Voor 31% gewijzigd door Kama op 18-06-2006 14:49 ]

[paulus4ever]

Dit is de laatste versie:




Nu mijn laatste vraag: Hoe kan ik een ralatie leggen tussen het bestelde item in de jarig ? En wat voor relatie moet dat zijn. Als ik een (non-)identifying relatie tussen 'jarige' en 'bestelling_item' leg, dan gooit Dezign hem via 'bestelling'.

Edit:

Vergeten info in startpost bijgeplaatst.

[ Voor 19% gewijzigd door paulus4ever op 18-06-2006 15:18 ]

[Kama]

paulus4ever schreef op zondag 18 juni 2006 @ 15:03:
Dit is de laatste versie:
[...]
Nu mijn laatste vraag: Hoe kan ik een ralatie leggen tussen het bestelde item in de jarig ? En wat voor relatie moet dat zijn. Als ik een (non-)identifying relatie tussen 'jarige' en 'bestelling_item' leg, dan gooit Dezign hem via 'bestelling'.

Je moet een FK op bestelde item naar jarige (of persoon) maken. Je gaat er dan vanuit dat er per bestelling items voor meerdere jarigen gekocht kunnen worden. Ook daar geldt dan weer dat je dan bestelling items kunt hebben met een FK van jarigen in een ander bedrijf, dus ook daar moet een constraint op.

Wat je nu met jarige en contactpersoon hebt kan wel.... Je hebt nu jarige zo afgelankt dat het een vrijwel andere entiteit is geworden dan contactpersoon. Een jarige contactpersoon komt nog wel voor in twee tabellen, mja... En: heb je aan alleen de naam genoeg?

Waarom niet een entiteit "persoon" maken en daar alle data op zetten + FK naar bedrijf en dan een extra n:m relatie toevoegen tussen bedrijf en persoon voor de contactpersonen? (zoals in m'n eerste post?) Alle mogelijke "jarigen" zijn dan de personen van dat bedrijf en sommigen ook contactpersoon.

[ Voor 10% gewijzigd door Kama op 18-06-2006 15:18 ]

[paulus4ever]

Versie 4 (van dit topic):



Als het goed is heb ik nu alle opmerkingen/commentaar van je verwerkt Kama...
In ieder geval alvast bedankt tot zover.

Ik twijfel alleen nog over, of contactpersoon klopt, en de te leggen leggen relatie met 'bestelling'.

[ Voor 84% gewijzigd door paulus4ever op 18-06-2006 16:31 . Reden: Toevoeging ]

[webinn]

je relatie bedrijf-bestelling ziet er prima uit volgens mij, enkel, waarom zit er een "persoonID" in bestellingitem in niet in bestelling?

[ Voor 207% gewijzigd door webinn op 18-06-2006 16:45 ]

[paulus4ever]

webinn schreef op zondag 18 juni 2006 @ 16:42:
je relatie bedrijf-bestelling ziet er prima uit volgens mij

Alleen hoe kan ik contactpersoon nu op een nette manier koppelen ?

[webinn]

paulus4ever schreef op zondag 18 juni 2006 @ 16:45:
[...]

Alleen hoe kan ik contactpersoon nu op een nette manier koppelen ?

zie edit: je kan persoonID beter in je "bestelling" steken, een persoon voert volgens mij een bestelling uit , die bestelling bevat dan meerdere items. Moet trouwens bestelling_id in "bestelling_items" geen PK ipv PF zijn?

[paulus4ever]

webinn schreef op zondag 18 juni 2006 @ 16:48:
[...]


zie edit: je kan persoonID beter in je "bestelling" steken, een persoon voert volgens mij een bestelling uit , die bestelling bevat dan meerdere items.

De bedoeling is dat de persoon (jarige in dit geval) gekoppeld is aan een item op de bestelling...
Zo kan er per persoon gekeken worden wat er in het verleden voor diegene al gekocht is.

De contactpersoon moet de bestelling plaatsen.

Moet trouwens bestelling_id in "bestelling_items" geen PK ipv PF zijn?

Het is een primary foreign key.

[ Voor 21% gewijzigd door paulus4ever op 18-06-2006 16:53 . Reden: Toevoeging ]

[webinn]

in dat geval plaats je best een persoon_id in bestelling_item en een contactpersoon_id in bestelling. je kan dan heel makkelijk aan het bedrijf van die contactpersoon en zijn andere gegevens

btw, zou je niet beter varchar(100) of 150 nemen voor website en emailadres? Sommige adressen kunnen echt wel lang zijn

[ Voor 60% gewijzigd door webinn op 18-06-2006 16:54 ]

[webinn]

paulus4ever schreef op zondag 18 juni 2006 @ 16:49:


Het is een primary foreign key.

Ok, my mistake :-)

[Kama]

v4 ziet er goed uit! Ik mis inderdaad alleen nog de relatie naar contactpersoon op bestelling. (Dus de FK op bestelling naar contactpersoon).

[paulus4ever]

Kama schreef op zondag 18 juni 2006 @ 18:36:
v4 ziet er goed uit! Ik mis inderdaad alleen nog de relatie naar contactpersoon op bestelling. (Dus de FK op bestelling naar contactpersoon).

Dan presenteer ik hier v5:



@Kama; wil je nog even kijken naar de entiteit contactpersoon of die zo klopt als bedoeld is door jou. Het is voor mij iets nieuws om dit zo te doen, maar ik moet er maar aan wennen als dit de goede (beste) manier is.

[ Voor 23% gewijzigd door paulus4ever op 18-06-2006 19:23 . Reden: Stukje voor Kama ]

[webinn]

paulus4ever schreef op zondag 18 juni 2006 @ 19:20:

@Kama; wil je nog even kijken naar de entiteit contactpersoon of die zo klopt als bedoeld is door jou. Het is voor mij iets nieuws om dit zo te doen, maar ik moet er maar aan wennen als dit de goede (beste) manier is.

ziet er perfect uit

[Kama]

webinn schreef op zondag 18 juni 2006 @ 21:42:
[...]
ziet er perfect uit

* Kama agrees volledig
Je zou evt nog wat velden van contactpersoon naar persoon kunnen verplaatsen (bijv. email), maar alleen als je ze ook echt nodig gaat hebben voor niet-contactpersonen (in jouw geval dus jarigen).

[ Voor 42% gewijzigd door Kama op 18-06-2006 23:16 ]

[Verwijderd]

Bij de tabel 'bestelling' is volgens mij 'verzonden' overbodig. Als 'verzenddatum' IS NULL dan is 'verzonden' automatisch false.
Idem voor 'annuleerdatum' en 'geannuleerd'.

Bij de tabel 'bedrijf' ga je een probleem krijgen met het veld huisnummer. Huisnummers kunnen ook niet-nummers zijn.

En zoals al eerder opgemerkt, sommige string-velden zijn te klein (plaats, land, e-mail, etc.).

De velden 'telefoon', 'gsm' en 'email' kun je volgens mij verplaatsen naar de tabel 'persoon'

Je mist een PK in de tabel 'contacpersoon'. (Oke, persoon_id en bedrijf_id vormen samen de PK, maar in de praktijk wordt dit een 'unique index/constraint ofzo). Maak een nieuw veld 'contactpersoon_id' en maak deze PK.

'persoon_id' moet wijzen naar PK 'contactpersoon_id' in de tabel 'contactpersoon' (of PK in de tabel 'persoon')

En mijn gevoel zegt dat 'bedrijf_id' in de tabel 'persoon' niet op zijn plaats is, misschien daar ook een koppeltabel van maken?