[BC3] Hoe kan ik deze tabellen het beste normaliseren??

Voor school zijn we bezig met een project. De bedoeling is om een hotelregistratie te maken waarbij klanten kamers kunnen boeken en informatie kunnen opvragen, we zijn nu halverwege het schrijven van het programma, maar moeten nu de database "normaliseren", zodat het opvragen sneller gaat. We moeten hierbij de 0de, 1ste en 2de normaalvorm maken. Hieronder vind je de gegevens uit de database.
Kan iemand ons alvast op weg helpen..
Alvast bedankt

Klantnummer
Klantnaam
Klantadres
Klantpostcode
Klantwoonplaats
Klanttelefoonnummer
Klantgeboortedatum
Klantrekeningnummer
*Kamernummer
*Kamertype
*Kamermankementen
**Reserveringsnummer
**Datum aankomst
**Datum vertrek
**Betaalstatus

Lees dit, en maak daarna braaf je eigen huiswerk

Ik ben ermee bezig geweest, kom er alleen niet helemaal uit.

Wat is precies het probleem dan?

quote:

Op dinsdag 08 mei 2001 14:16 schreef Paul18 het volgende:

Klantnummer
Klantnaam
Klantadres
Klantpostcode
Klantwoonplaats
Klanttelefoonnummer
Klantgeboortedatum
Klantrekeningnummer
*Kamernummer
*Kamertype
*Kamermankementen
**Reserveringsnummer
**Datum aankomst
**Datum vertrek
**Betaalstatus

Tabel 1, stap 1:
Klant:
Klantnummer
Klantnaam
Klantadres
Klantpostcode
Klantwoonplaats
Klanttelefoonnummer
Klantgeboortedatum
Klantrekeningnummer


En verzin de rest zelf maar!

Dit komt er uit als ik tot de 2de normaalvorm ga, maar er klopt volgens mij nie echt veel van.

Klant
Klantnummer
Klantnaam
Klantadres
Klantpostcode
Klantwoonplaats
Klanttelefoonnummer
Klantgeboortedatum
Klantrekeningnummer

Kamer
Kamernummer
Kamertype
Kamermankementen

Reserveringen
Reserveringsnummer
Klantnummer
Kamernummer
Datumaankomst
Datumvertrek
Betaald

Wat onderstreept is is de primary key

Thnx zal ff verder kijken

Haal kamertype eens snel uit die tabel

(en kamermankementen misschien ook, ik weet niet precies wat het voorstelt)

[edit]
Maak er ook ''Reservering'' van ipv ''Reserveringen'' (of wees iig consequent in benamingsmethode).

klanten(Klantnu,Klantnaam,Klantadr,Klantpc,Klanwpls,Klanttel,Klantgebdatum,Klantrekening,Kamernum)
Kamer(Kamernum,Kamertype,Kamermanko)
reservering(klantnu,Reserveringsnum,aankomst,vertrek,Betaalstatus)

primary
fordinges

dat was toch zo iets.

Dat ligt er maar net aan welke DBMS je hebt en hoe je ''m aanspreekt.

Jou leraaren proberen je wijs te maken dat je een database eerst volgens het boekje moet normaliseren. DAT WERKT NOOIT.

Leraaren op een ICT school zijn meest loosers die het in ''t bedrijfsleven niet aan konden omdat ze er achter kwamen dat niet alles via het boekje kan. (er zijn uitzonderingen op deze regel, maar niet veel)

Bedenk eerst eens hoe je de database en je tabellen gaat aanspreken. Kijk dan hoet je de verschillende tabellen het besten in kunt delen. En ga dan eens kijken of dat nog eens genormaliseert moet worden.

Het belangrijkste van normaliseren is dat je dubbele data invoer voorkomt. m.a.w. je database fool proof maakt.

Het is b.v. niet altijd schadelijk om productie gegevens in een database op te slaan. Het kan soms (i.v.m. performance b.v.) best wenselijk zijn.

greets martijn

quote:

Op dinsdag 08 mei 2001 14:46 schreef tomato het volgende:
Haal kamertype eens snel uit die tabel

(en kamermankementen misschien ook, ik weet niet precies wat het voorstelt)

[edit]
Maak er ook ''Reservering'' van ipv ''Reserveringen'' (of wees iig consequent in benamingsmethode).

altijd enkelvoud. Immers is een regel altijd maar EEN reservering.

quote:

Op dinsdag 08 mei 2001 14:47 schreef thereap.demon het volgende:
Dat ligt er maar net aan welke DBMS je hebt en hoe je ''m aanspreekt.

Jou leraaren proberen je wijs te maken dat je een database eerst volgens het boekje moet normaliseren. DAT WERKT NOOIT.
[..meer onzin..]

Gefeliciteerd, U bent DE prutser van de dag.

quote:

Op dinsdag 08 mei 2001 14:51 schreef dusty het volgende:

[..]

Gefeliciteerd, U bent DE prutser van de dag.

You''ve pulled the words out of my mouth

quote:

Op dinsdag 08 mei 2001 14:47 schreef thereap.demon het volgende:
Dat ligt er maar net aan welke DBMS je hebt en hoe je ''m aanspreekt.

Jou leraaren proberen je wijs te maken dat je een database eerst volgens het boekje moet normaliseren. DAT WERKT NOOIT.

Leraaren op een ICT school zijn meest loosers die het in ''t bedrijfsleven niet aan konden omdat ze er achter kwamen dat niet alles via het boekje kan. (er zijn uitzonderingen op deze regel, maar niet veel)

Bedenk eerst eens hoe je de database en je tabellen gaat aanspreken. Kijk dan hoet je de verschillende tabellen het besten in kunt delen. En ga dan eens kijken of dat nog eens genormaliseert moet worden.

Het belangrijkste van normaliseren is dat je dubbele data invoer voorkomt. m.a.w. je database fool proof maakt.

Het is b.v. niet altijd schadelijk om productie gegevens in een database op te slaan. Het kan soms (i.v.m. performance b.v.) best wenselijk zijn.

greets martijn

Onzin. Iig als reply op deze vraag. Normaliseren is een standaardmethode die je kunt toepassen voordat je weet welke dbm je gaat gebruiken.
Bij normaliseren houd je ook geen rekening met hoe je de data er weer uit wilt krijgen, dat komt in een later stadium. Het is altijd goed om eerst volledig te normaliseren en dan pas verder te kijken.

quote:

Op dinsdag 08 mei 2001 14:47 schreef thereap.demon het volgende:
Dat ligt er maar net aan welke DBMS je hebt en hoe je ''m aanspreekt.

Jou leraaren proberen je wijs te maken dat je een database eerst volgens het boekje moet normaliseren. DAT WERKT NOOIT.

Leraaren op een ICT school zijn meest loosers die het in ''t bedrijfsleven niet aan konden omdat ze er achter kwamen dat niet alles via het boekje kan. (er zijn uitzonderingen op deze regel, maar niet veel)

Bedenk eerst eens hoe je de database en je tabellen gaat aanspreken. Kijk dan hoet je de verschillende tabellen het besten in kunt delen. En ga dan eens kijken of dat nog eens genormaliseert moet worden.

Het belangrijkste van normaliseren is dat je dubbele data invoer voorkomt. m.a.w. je database fool proof maakt.

Het is b.v. niet altijd schadelijk om productie gegevens in een database op te slaan. Het kan soms (i.v.m. performance b.v.) best wenselijk zijn.

greets martijn

Ze leren je een methode zodat je die later op je eigen manier kan gebruiken. Duh.

quote:

Op dinsdag 08 mei 2001 14:51 schreef dusty het volgende:

[..]

Gefeliciteerd, U bent DE prutser van de dag.

Jah, dat bedoelde ik dus ook een beetje

En idd altijd enkelvoud, wordt zo vaak fout gedaan!

Als ik kamertype (bv standaard, luxe ofzo), en kamermankementen (iets wat er kapot is in de kamer) niet in de database mag zetten, hoe kan ik deze dan in het programma verwerken.

De receptioniste (of iemand anders) die het programma raadpleegt moet namelijk wel kunnen zien wat er mankeert aan de kamer, en welk type kamer het is

quote:

Op dinsdag 08 mei 2001 14:47 schreef thereap.demon het volgende:
...
Het is b.v. niet altijd schadelijk om productie gegevens in een database op te slaan. Het kan soms (i.v.m. performance b.v.) best wenselijk zijn.

greets martijn

En ook dat heet normaliseren! Ooit wel eens verder gekeken dan de 3e normaalvorm?

quote:

Op dinsdag 08 mei 2001 14:58 schreef Paul18 het volgende:
Als ik kamertype (bv standaard, luxe ofzo), en kamermankementen (iets wat er kapot is in de kamer) niet in de database mag zetten, hoe kan ik deze dan in het programma verwerken.

De receptioniste (of iemand anders) die het programma raadpleegt moet namelijk wel kunnen zien wat er mankeert aan de kamer, en welk type kamer het is

Mag wel in de database. Maar niet op de manier waarop jij het hebt gedaan.

quote:

Op dinsdag 08 mei 2001 15:04 schreef Bazzel het volgende:
En ook dat heet normaliseren! Ooit wel eens verder gekeken dan de 3e normaalvorm?

Kan maar tot 2 tellen.

quote:

Op dinsdag 08 mei 2001 15:10 schreef dusty het volgende:

[..]

Kan maar tot 2 tellen.

AHA, dat verklaart een hoop!