[Datamodel] Good practice? Klantenbestand

[ReallyStupidGuy]

Ik ben bezig om voor een hotel een reservering/kassa systeem te maken. Ik heb het datamodel nu wel zo een beetje af maar zit nog te twijfelen tussen twee oplossingen voor de klantregistratie.

Het probleem waar ik tegenaan loop is dat een persoon 3 verschillende rollen kan hebben, namelijk die van klant, gast en contactpersoon (voor bedrijven). (een gast is iemand die in het hotel verblijft (of verbleef) maar niet degene is die de boeking heeft gedaan.

De eerste oplossing heeft als voordeel dat de tabelstructuur eenvoudiger is maar houd met een aantal dingen geen rekening. (bijvoorbeeld dat een bedrijf op zich ook een adres kan hebben zonder een contactpersoon (en telefoonnr ed.)



De tweede is volgens mij behoorlijk genormaliseerd maar ik houd het gevoel dat ik het dan onnodig ingewikkeld zit te maken...




Ik wil dus wel graag weten wat jullie de beste oplossing vinden (en waarom), ik zit hier op dit moment namelijk alleen aan te werken en ben al een tijdje aan het twijfelen maar moet maandag echt een besluit nemen.....

[ Voor 14% gewijzigd door ReallyStupidGuy op 16-07-2004 19:49 . Reden: Linkje gefixt ]

[Harmen1975]

Leg eerst maar eens uit WAT je precies wil vastleggen...beide oplossingen zien er zonder meer informatie onnodig ingewikkeld uit. Wat zijn de vereisten ?

Vast een paar opmerking / vragen:

Leg de relatie eens uit tussen de entiteiten 'Klanten', 'Particuliereklanten' en 'Bedrijven'. Beschrijf de relatie maar eens en je zal zien dat je nog lang niet uitgenormaliseerd bent. Waarschijnlijk kom je op een entiteit 'Klanten'.

Een klant kan dan een contactpersoon hebben die een relatie heeft met een boeking. Nu weet je ook welk contactpersoon welke boeking heeft gedaan. Iets dat op dit moment niet mogelijk is

Waarom hou je zoveel informatie vast op persoonsniveau ?

Met de bovengenoemde opmerkingen kan ik dit plaatje maken met vijf entiteiten...maar ik weet ook niet wat je systeem allemaal moet kunnen.

[Gert]

Wat een vreemd datamodel.
Wat doet klant_id in de bedrijf tabel? Op fysiek niveau zou dat inderdaad een veld zijn maar in een dit datamodel niet, dat zou de relatie duidelijke moeten maken. Sowieso al die koppel entiteiten horen er niet. Dat zijn waarschijnlijk veel op veel relaties en dat worden dan koppel tabellen of fysiek niveau.

Wat is er mis met het adres bij de/het persoon/bedrijf opslaan, heeft met redundantie niets te maken aangezien je mag aanemen dat elke bedrijf een eigen adres heeft, net als elke persoon.

Verder ontbreekt een beetje of een gerelateerde entiteit al dan niet verplicht is.

[ Voor 14% gewijzigd door Gert op 17-07-2004 17:16 ]

[ReallyStupidGuy]

Harmen1975 schreef op 16 juli 2004 @ 21:08:
Leg eerst maar eens uit WAT je precies wil vastleggen...beide oplossingen zien er zonder meer informatie onnodig ingewikkeld uit. Wat zijn de vereisten ?

Vast een paar opmerking / vragen:

Leg de relatie eens uit tussen de entiteiten 'Klanten', 'Particuliereklanten' en 'Bedrijven'. Beschrijf de relatie maar eens en je zal zien dat je nog lang niet uitgenormaliseerd bent. Waarschijnlijk kom je op een entiteit 'Klanten'.

Een klant kan dan een contactpersoon hebben die een relatie heeft met een boeking. Nu weet je ook welk contactpersoon welke boeking heeft gedaan. Iets dat op dit moment niet mogelijk is

Waarom hou je zoveel informatie vast op persoonsniveau ?

Bedankt! Personen doen altijd boekingen!

Over de klanten, bedrijven en particulieren: Bij bedrijven moeten andere gegevens worden vastgelegd dan bij particuliere klanten. Het lijkt mij netter om zo min moglijk null velden te hebben dus daarom heb ik ze gesplitst.


Eerst even over de FK's die in het model staan: Ik weet dat het niet hoort maar ik vindt het wel prettiger werken... (En ik ben nogal eigenwijs...)

Het door een persoon laten doen van een boeking vindt ik een heel goed idee! Ik zal even een nieuw modelletje maken.

Gert schreef op 17 juli 2004 @ 17:15:
Wat is er mis met het adres bij de/het persoon/bedrijf opslaan, heeft met redundantie niets te maken aangezien je mag aanemen dat elke bedrijf een eigen adres heeft, net als elke persoon.

Verder ontbreekt een beetje of een gerelateerde entiteit al dan niet verplicht is.

Als ik het adres bij personen, klanten of bedrijven in stop dan kan een klant altijd maar 1 adres hebben. Het is een eis dat een klant meerdere adressen kan hebben dus dat kan al niet Ik heb iets tegen lege FK velden (gerelateerde entiteit) dus in principe is alles verplicht in dit model.

Over de eisen en wensen van het model:
-Klanten moeten zowel bedrijven als partikulieren kunnen zijn
-Bedrijven moeten meerdere contactpersonen kunnen hebben
-Particulieren zijn een persoon en kunnen geen contactpersonen hebben.
-Eventueel zou een particulier ook een contactpersoon kunnen zijn.
-Een bedrijf moet meerdere adressen kunnen hebben (factuur, correspondentie bv.)
-Een particulier mag eventueel ook meerdere adressen hebben maar dat is niet noodzakelijk
-Particulieren en bedrijven moeten meerdere telefoonnummers kunnen hebben(mobiel, thuis, werk ect.)

Hier is het alternatief zoals ik denk dat Harmen bedoelde.


Wat ik nu wel jammer vindt is dat niet is na te gaan of de boeking wordt gedaan als privepersoon door iemand die ook ooit contact is (geweest) voor een bedrijf.

[ Voor 38% gewijzigd door ReallyStupidGuy op 18-07-2004 19:12 ]