07. marts 2004 - 17:00Der er
8 kommentarer og 1 løsning
hjælp til normalisering af database ?
hjælppppppp.
jeg har lavet en database, til et booking system skole opgave for et rejsebeuro. Men er ikke helt i det der normalisering. Er der ikke nogen af jer der gider at være sød og lige se på det nedstående link, for at se om hvor normaliseret den er og hvad der skal ændres for at den kommer op på en 3 normalform.
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
Og så er det iøvrigt svært at gennemskue om der er utilsigtede sammenhænge mellem de felter, du har i dine tabeller, når man kun har feltnavnene at gøre godt med. Det er fx ret umligt at overskue om fx booking_total_pris er et felt, der lige så godt kunne beregnes. Eller om samme felt fx styres booking_antal_voksen el.l. I begge ovenstående tilfælde er tabellen ikke på 3NF. Og med så mange felter, er det fuldstændigt umuligt at gennemskue uden at se nogen data.
Måske er der noget jeg ikke ved (og det gør det endnu sværere), men for mig at se, kan en postadresse i dit eksempel tilhøre flere kunder. Det er i hvert ikke normalt, men derfor kan det jo godt være rigtigt :-)
Hvis ikke, er der en en-tilen realtion mellem kunde og postadresse, og så brudre de have været i samme tabel.
De øvrige tabeller, bortset fra booking, opfylder 3NF, med mindre der er forhold, jeg ikke kender til.
Booking er som sagt uoverskuelig, og dermed umulig at vurdere.
det er sådan at det her database skal bruges til et asp, aplikation. og i den applikation er det sådan at der også findes en hel masse statistiker som bliver udtræket ved disse data fra databasen.
når man oprette en booking, indtaster man -navn -adresse -post nr -by -email på kunden
derefter kommer bookings siden hvor man indtaster: afrejse fra by afrejse til by hjemrejse fra by hjemmerejse til by afrejse afgangs tid afrejse ankomst tid hjemmerejse afgangs tid hjemmerejse ankomst tid antal voksne antal børn antal infant
og der går asp ind og regner hvor mange voksne i alt og hvor i alt prisen for voksne det er og smide disse informationer ind i databasen.
Alt hvad der beregnes bør ud. Har du de faktuelle oplysninger kan du jo beregne dem igen når som helst, du får brug for dem, og derfor bør de ikke lagres i databasen.
Herudover tror jeg faktisk at det ser meget "normalt" ud. Især hvis du lige forklarer mig, hvorfor flere personer kan have samme adresse? Flere medarbejdere deler også adresser? Og så forstår jeg heller ikke sammenhængen mellem Bruger og Medarbejder.
Og det er præcis denne mangel på forståelse (baseret på mangel på insiderviden om applikationen), der gør den næsten umulig at normalisere korrekt. Der bliver alt for mange spørgsmål, som skal sendes frem og tilbage.
I virkeligheden er det meget nemmere, at du selv står for din normalisering, da du har de interne oplysninger, håber jeg. Ellers er opgaven stillet forkert, eller du mangler at gøre dig nogen fvorudsætninger omkring løsningen.
Du kan altid starte ud med denne sætning:
Alle felter i en tabel, skal være afhængige af
The Key, The Whole Key, and nothing but the Key. So help me,Codd. 1NF 2NF 3NF
din afrejse/hjemrejsetabeller er ikke ok - eftersom begge tabeller er ens - bortset fra retningen, så burde det være en tabel - med en kolonne som angiver om det er afrejse eller hjemrejse.
Jeg vil vurdere, at din byer heller ikke er ok - da jeg heller ikke har insider-viden, så kan jeg ikke sige det med sikkerhed, men formentlig burde du have en destinationstabel - eller rejsemålstabel - og en reference fra booking til rejsemål - og evt. (hvis det er muligt at rejse til flere rejsemål på den samme rejse) - en jointabel.
Den er gal med (som tidligere skrevet) bruger og medarbejder - formentlig skulle medarbejder tabellen blot udvides med brugeroplysningerne (er dog smag og behag).
Derudover tilslutter jeg mig de tidligere kommentarer omkring postadresser mv.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.