[database] probleem bij normaliseren*

[Verwijderd]

ik probeer al ruimte tijd een soort reserveringssysteem te maken en het lijkt eindelijk een beetje te willen. Probleem is dat ik het gewend ben om altijd met spreadsheats te werken, dus uitwerken in access is een eitje maar het normalisatie en integratie process gaat me niet zo makkelijk af. Ik heb gegoogeled en kwam een paar leuke tuts tegen o.a. phphulp.nl, leuke om mee te beginnen hier ben ik ook op verder gegaan.Echter zodra ik met mijn output van de normalisatie meeneem naar access krijg ik het niet voor elkaar om een geheel van te maken zonder dat er atributen meerdere malen voorkomen en dat is niet de bedoeling, dus ik geloof dat het in mijn normalisatie zit. alle tips, suggesties, evt links naar tuts worden op prijsgesteld.

Ik probeer het geheel te bouwen aan de hand van 2 overzichten.

overzicht 1 met daarin:
parknaam (komt 2x voor in 't overzicht),type_huis, huisnummer,aantal slaapkamer,aantal bedden,huurprijs
- normalisatie:
0NV:
RG: (Parknaam, RG:(Type huis, RG:( Huisnummer, aantalslaapkamers, aantalbedden, huurprijs))).

1NV:
(Parknaam)
(Parknaam, Type huis)
( Type huis, Huisnummer, aantalslaapkamers, aantalbedden, huurprijs)


2NV:
(Parknaam)
(Parknaam, Type huis)
( Type, Huisnummer)
(Huinummer, aantalslaapkamers, aantalbedden, huurprijs).


3NV:
Park (Parknaam, Type huis)
Type (Type huis, Huisnummer)
Huis (Huisnummer, aantalslaapkamers, aantalbedden, huurprijs)

overzicht 2
gastnaam,parknaam (komt 2x voor in 't overzicht),huisnummer,boekingdatum,aankomstdatum,vertrekdatum,aantalpersonen,prijs,betaald
-normalisatie:
0NV:
RG: ( Parknaam, RG:(Huisnummer, naamgast, Tel nummer, boekingdatum, aankomstdatum, vertrekdatum, aantalpersonen, prijs, betaald)).

1NV:
(Parknaam)
(Parknaam, Huisnummer, naamgast, Tel nummer, boekingdatum, aankomstdatum, vertrekdatum, aantalpersonen, prijs, betaald).


2NV:
(Parknaam)
(Parknaam, Huisnummer)
(Huisnummer, naamgast, Tel nummer, boekingdatum, aankomstdatum, vertrekdatum, aantalpersonen, prijs, betaald).


3NV:
Park (Parknaam, Huisnummer)
Huis (Huisnummer, naamgast, Tel nummer)
Boeking (Naamgast, boekingdatum, aankomstdatum, vertrekdatum, aantalpersonen,
prijs, betaald).

[ Voor 4% gewijzigd door Verwijderd op 23-06-2006 02:54 ]

[Bergen]

Uit de losse pols:

parken
------------------------
id
parknaam

huistypen
------------------------
id
huistypenaam

huizen
------------------------
id
parkid
huistypeid
huisnummer
slaapkamers
bedden
huurprijs

gasten
------------------------
id
naam
straat
huisnummer
postcode
woonplaats
telefoonnummer
haarkleur
favorietehobby

boeking
------------------------
id
gastid
huisid
aankomstdatum
vertrekdatum
aantalpersonen
betaald

Zoals je ziet is het handiger om elk record een id te geven, een uniek nummer dus. Dat is overzichtelijker, scheelt ruimte en zo werk je automatisch gestructureerd. Zo hoef je bij je boekingen bijvoorbeeld geen parknamen of huistypen op te slaan, want die kun je herleiden uit de gegevens van het geboekte huis.

[Verwijderd]

Bergen schreef op vrijdag 23 juni 2006 @ 04:59:
Uit de losse pols:

parken
------------------------
id
parknaam

huistypen
------------------------
id
huistypenaam

huizen
------------------------
id
parkid
huistypeid
huisnummer
slaapkamers
bedden
huurprijs

gasten
------------------------
id
naam
straat
huisnummer
postcode
woonplaats
telefoonnummer
haarkleur
favorietehobby

boeking
------------------------
id
gastid
huisid
aankomstdatum
vertrekdatum
aantalpersonen
betaald

Zoals je ziet is het handiger om elk record een id te geven, een uniek nummer dus. Dat is overzichtelijker, scheelt ruimte en zo werk je automatisch gestructureerd. Zo hoef je bij je boekingen bijvoorbeeld geen parknamen of huistypen op te slaan, want die kun je herleiden uit de gegevens van het geboekte huis.

@bergen, dat is idd wel handig om overal met id's te werken, zo heb je bij elke tabel telkens maar 1 sleutel, dus de id-nr. Klopt er overigens wel een beetje van mijn normalisatie?

[ Voor 6% gewijzigd door Verwijderd op 23-06-2006 10:55 ]

[Verwijderd]

@modjes mag ik een topic change? naar-> [databases access] normalisatie/integratie vragen

[gorgi_19]

Verwijderd schreef op vrijdag 23 juni 2006 @ 19:09:
@modjes mag ik een topic change? naar-> [databases access] normalisatie/integratie vragen

Dat kan je door middel van doen

[JeroenTheStig]

Wat ik doe met het opbouwen van een databasemodel is ten eerste alle entiteiten en attributen zoeken en groeperen. Attributen beschrijven dus de eigenschappen van de entiteiten.
Wat je in je startpost hebt gedaan is de attribuut 'huisnummer', of 'type_huis' onder entiteit 'park' plaatsen, wat niet bij elkaar hoort. Type_huis plaats je in een aparte tabel 'huistypen', en 'huisnummer' hoort bij entiteit 'huis'.

Als je de entiteiten + attributen hebt gegroepeerd, kun je vervolgens de tabellen definieren:

Parken (naam)
Huis_typen( type)
Huizen (huisnummer, aantal_slaapkamers, aantal_bedden, huurprijs)
Gasten (naam, telefoonnummer)
Boekingen (boekingsdatum, aankomstdatum, vertrekdatum, aantalpersonen, prijs, betaald)

De volgende stap is de relaties leggen. Zoals Bergen ook al aangaf, is het verstandig om elke tabel een attribuut 'id' mee te geven die als primaire sleutel gebruikt wordt. Deze attribuut is dus puur een technische sleutel.

Vervolgens ga je kijken welke tabellen een relatie met elkaar hebben, en wat voor relatie. Bijvoorbeeld: een park heeft 1 of meerdere huizen, een huis_type geldt voor 0, 1 of meerdere huizen, een gast kan 1 of meerdere boekingen hebben gemaakt, enz. Om deze relaties te bewerkstelligen, heb je foreign keys nodig. Om de relatie park -> huis te leggen, plaats je in tabel 'huizen' een foreign key genaamd park_id. Dus de naam van de entiteit waarnaar de relatie wordt gelegd, gevolgd met nr.
Je krijgt dan de volgende tabellen:

Parken (id, naam)
Huis_typen(id, type)
Huizen (id, , park_id, huis_type_id, huisnummer, aantal_slaapkamers, aantal_bedden, huurprijs)
Gasten (id, naam, telefoonnummer)
Boekingen (id, gast_id, huis_id, boekingsdatum, aankomstdatum, vertrekdatum, aantalpersonen, prijs, betaald)

Het algeheel plaatje + relaties is dan als volgt:



_{Misschien lichtelijk overdreven met bovenstaande screenshot, maar ik wou de nieuwste JDeveloper toch nog even uitproberen met het bouwen van ERD's}

[ Voor 15% gewijzigd door JeroenTheStig op 24-06-2006 21:35 ]

[Creepy]

offtopic:
@gorgi_19: Dat had ie vanmiddag al gedaan

En ook meteen maar ff een move naar SEA aangezien we hier met met design i.p.v. implementatie bezig zijn

Overigens, zou je misschien ook de redenatie achter je verschillende normaal vormen ook eens kunnen posten en welke zaken je nu in Access herhalend krijgt? Met je 3de normaal vorm ben je namelijk al een heel eind Wat ID's nog toevoegen, misschien nog eens goed kijken naar namen van personen e.d. maar verder zie ik vrij weinig problemen.

[Verwijderd]

Wat ik fout deed was dat ik o.a. geen gebruik maakte van id's bij de tabellen, dat is beter en scheelt bovendien veel ruimte.

@ Bokter. Mooie schema, Jdeveloper zegt me alleen niet veel.
Ik heb me in de tussentijd verdiept in het maken de ER-diagrammen, blijkbaar zijn daar verschillende manieren voor. Ik heb gekozen voor de onderstaande omdat deze vrij simpel maar toch duidelijk is.



IIk zit alleen te twijvelen over de relatie Gasten-->Boekingen, nu weergegeven dat een gast meerdere boekingen kan hebben, en niet moet zijn gast kan 0, 1 of meerdere boekingen hebben ivm met klanten die eerder een boeking hebben gedaan en nog in het systeem staan want dat zou dan niets opleveren.

[ Voor 21% gewijzigd door Verwijderd op 24-06-2006 17:29 ]

[JeroenTheStig]

Ik zou zeggen: een gast kan 1 of meerdere boekingen hebben. Je zegt dat klanten die eerder een boeking hebben gedaan nog in het systeem staan. Bedoel je dat je records uit het boekingen-tabel gaat verwijderen op het moment dat de vertrektijd van die boeking gepasseerd is? Ik zou de records gewoon in je tabel laten staan als een stuk historie, en op basis van de data de recente boekingen laten zien in je systeem.

Overigens, je schema ziet er goed uit hoor De 1-op-meer relaties zijn goed weergegeven mbv het 'harkje'. Zorg er wel voor dat je consequent je tabelnamen in de meervoudsvorm hebt en de relaties tussen de tabellen kun je in plaats van 'gast-id' beter gasten_boekingen_fk noemen ofzo. Dan zie je dat het gaat om een foreignkey tussen gasten en boekingen.

[ Voor 31% gewijzigd door JeroenTheStig op 24-06-2006 21:27 ]

[maxtrash]

Het datamodel zoals het er nu ligt dat door Bergen is voorgesteld lijkt me prima, zou ik ook zo gedaan hebben. Ik kan me alleen niet helemaal voorstellen dat ieder huis altijd dezelfde huurprijs heeft. Je zou het prijs-attribuut naar de boeking-entiteit kunnen verplaatsen. Je moet bij iedere boeking de prijs ingeven, maar dat is wel heel flexibel. Een prijs kan afhangen van periode, lengte van de huurperiode, aantal personen, gezinskorting, vroegboek-korting, last-minute korting etc. Ik verzin maar wat, je begrijpt m'n punt. Nu kun je dat ook gaan modelleren natuurlijk maar dan komen er weer wat entiteiten bij.

De relatie tussen gast en boeking lijkt me zeker optioneel. Los van het schoningspunt (waar ik ook niet te snel mee zou beginnen trouwens), is het perfect mogelijk dat een gast bekend is zonder dat hij al geboekt heeft. Een prospect zeg maar.