Tjaa. Normalisering er ikke absolut videnskab. Du vælger selv hvor du stopper normaliseringen, men her er jeg i tvivl. For mig at se, er dine data fint normaliserede, udfra den grundtanke, at der ikke må være redundans (er det ikke 3'die normalform?).
van-veen, ad mig proeve at forstaa hvad det er du laver. Jeg tror at du saelger varer i form af forskellige typer aktiviteter der finder sted i lokale og som kreaever instruktoerer. Lad os sige at en Vare_Type er "boksning for viderekommende," en anden er "Vind i Ludo," og en tredje "Lederskabets psykologi." Hver varetype har en pris. En varetype kan kraeve adskillige lektioner, for eksempel ludo kraever fem timers instruktion som du normalt fordeler paa fem dage med en time hver.
Vare_Typerne finder sted adskillige gange, for eksempel starter du Ludo kurser i september, november, og februar. Vare_Type tabellen skal have V_Type som pk, skal have felter for pris, beskrivelse (med mindre du er eneste bruger og kan dem udenad), og varighed. Start og slut tid har ikke noget at goere med en Vare_Type som saadan.
Lokaler og instruktoerer er ikke afhaengige af vare numre og behoever ingen fk. Rum tabellen kan noejes med et enkelt felt, R_Nr som pk. Instruktoer tabellen skal have I_Nr som pk og et felt for navn.
Og saa laver du en aktivitetsplan saaledes at du for eksempel starter Ludo i uge 35, 50, og 6 og psykologi i uge 40 og 8 o.s.v. Hver aktivitet har et A_Nr som pk og et felt med Vare_Nr som fk. Du er saa noedt til at have en tabel med lektioner hvor hver lektion finder sted en bestemt dag i et bestemt lokale med en bestemt instruktoer, starter paa et bestemt tidspunkt, og hoerer til en bestemt A_Nr. Saa Lektion tabellen har L_Nr som primary key og felter med A_Nr, R_Nr, I_Nr som fk og felter med dato, start_tid, og varighed.
Naar saa du har din aktivitetsplan saa kan du begynde at modtage bookings. Din Booking tabel skal have, som du goer, Booking_Nr som pk og skal have felter som fk til Kunde_nr og Aktivitet_nr (ikke vare_type). Felter med datoer og tider er redundant i booking tabellen. Men du vil vel goere noget med den booking, acceptere den eller afvise den hvis der ikke er mere plads, og du vil vel ogsaa godt se nogle penge. Saa du skal nok have et felt for status med fk til en tabel for status typer, for eksempel disse: Afvist, Akcepteret, Betaling Modtaget.
Jeg kan ikke se hvad du skal med Historik_booking. Du lader bare dine bookings staa i bookingtabellen for tid og evighed. Ligeledes His_Vare_Type, hvis du for eksempel holder op med Ludo saa bliver den staaende som vare-type men indgaar bare ikke mere i din aktivitetsplan.
Saa jeg kommer frem til den foelgende tabelstruktur:
Booking: Booking_Nr pk, A_Nr fk, Kunde fk, Status fk.
Der kan naturligvis goeres meget mere ud af det. Jeg ser at du har Antal_Boern som felt i Kunde. Er det fordi boern ogsaa kan deltage (og hvad saa med aegtefaelle?) Kan der vaere lektioner der kraever mere end en instruktoer? Skal man sikre sig at lokalerne har bestemt udstyr? Skal der vaere en lokaleplanlaegning? O.s.v. Men det gaar alt sammen ud over rammerne for dit spoergsmaal.
Til hrc: Jeg er ikke helt enig i at normalisering ikke er absolut videnskab. Der bestaar en noeje teori, og redundans er kun et af problemerne. Den struktur jeg foreslaar er i 3' normalform. Der bestaar ogsaa en 4' og en 5' normalform for specielle tilfaelde.
van-veen, hvis jeg ikke har forstaaet dig rigtig og mit forslag derfor indeholder misforstaaelser saa forklar naermere. Ellers haaber jeg at nogle af mine tanker vil vaere nyttige.
Jeg kikkede paa det igen - jeg indser at et billede af de foreslaaede tabeller vil vaere lettere at kapere. Jeg har udbygget dit regneark med de tabeller jeg foreslaar. Jeg har proevet at goere det saaledes at en tabel som har en FK til en anden tabel er placeret lavere paa siden. Jeg haaber du kan downloade dette regneark. Hvis ikke saa send mig en mail som jeg kan returnere med regnearket som bilag.
Hej Christian. Må sige, at når du svarer, så svarer du! Synes egentlig van-veen skulle have haft lov til at formulere spørgsmålet så man ikke skulle bruge tid (som du må have gjort) på at finde ud af hvad der spørges om.
(Har i øvrigt lige brugt 45 minutter på at finde ditto belgiske IQGlass.com - det var ikke let. Nu venter vi spændt på kvadratmeterprisen).
Tak for de fine svar og Christian tak for din enorme indsats, men det er desværre ikke sådan billedet ser ud.
Strukturen er over et feriecenter der har hovedesæde i træning. De skal kunne booke: 2 typer lejligheder Baner af forskellige arter "badminton, tennis ect" Instruktør til 4 af de forskellige sportsarter. Udstyr til de forskellige aktiviteter.
Aktiviteterne har åbne fra 08:00 til 20:00 og derfor tids atributterne.
Det jeg har lavet, skulle gerne være på 1NF, 2NF, 3NF og boys Codd.
Jeg syntes bare at det er svært at normalisere selv om jeg godt kan se om der er renundans eller ej. Man skal jo også kunne forsvare det :)
Jamen i saa tilfaelde kan det vel goeres temmelig enkelt. Der er, som dit diagram viser, en mange-til-mange relation mellem kunder og varer, og forbindelsen mellem de to er Booking der derfor har to FKs, en til Kunde_nr og en til Vare_nr. Saa der er jeg enig. Yderligere har jeg ingen kommentarer til tabellerne Kunde(r) og Firma med FK relationen fra Kunde til Firma.
Vare-siden er mere kompleks, og det er vel ogsaa der du har haft betaenkeligheder. Her er et par kommentarer:
(a) I stedet for i databasen at gemme datoer saerskilt fra tidspunkter foreslaar jeg at du gemmer date-times. Kunden's bookingsoplysninger og de rapporter du traekker ud skal jo nok vise datoer og tidspunkter saerskilt, men det er et spoergsmaal om at omforme data, ikke et spoergsmaal om relationalle strukturer og normalisering.
(b) Saa viser du tidspunkter baade i booking og i varetype. Der vil jeg nok sige at du skal vaelge mellem de foelgende to muligheder: Enten (1) definerer du, for eksempel, tennisbane-1 23 juli fra 14-16 som en vare med et varenummer og den samme tennisbane 23 juli fra 16-18 som en anden vare med et andet varenummer. I saa fald lader du kunden booke en vare og det er redundant at gentage tidspunkter i bookingen. Eller (2) nok mere simpelt, du definerer tennisbane-1 som en vare, tennisbane-2 som en anden vare, instruktoer Thomsen som en tredje vare, o.s.v., hver med deres saerskilte varenummer. Saa skal bookingstabellen indeholde varenummer og start- og sluttider og det er redundant at have tidspunkter i varetabellen. Det at undgaa at dobbel-booking af en vare bliver saa et spoergsmaal om "business-rules," ikke normalisering. (I pseudo-kode, IF start- og sluttidspunktet BETWEEN 0800 AND 2000 AND start-datetime >= slut-datetime for alle andre bookings for samme varenummer AND slut-datetime < start-datetime for alle andre bookings for samme varenummer THEN tillad booking ELSE afvis booking.)
(c) Hvis omfanget er begraenset, som du fortaeller, saa er det maaske ikke noedvendigt at definere vare-typer og lignende. Hvis din vare tabel har felter for ID, beskrivelse, pris, og prisenhed (det vender jeg tilbage til) saa laver du raekker med varenumre for lejlighed-1, lejlighed-2, trambolin-1, Thomsen, Jensen, Tennisbane-1, o.s.v. og saa er den hjemme. Det med pris-enhed er fordi priser paa tennisbaner og instruktoerer nok er per time men paa lejligheder per dag.
(d) Saa er jeg kommet i tanker om at du i Booking, udover status (modtaget, accepteret, afvist, betalt, afsluttet..) nok ogsaa skal have pris. Det er godt nok en beregnet vaerdi, timer gange timepris, men kun paa bookings-tidspunktet. Timepriserne kan aendre sig senere. Hvis en kunde i marts bookede fem timers instruktion til 100 kr i timen saa koster hans booking 500 kr uanset om du i juli haever saetter timeprisen op til 120 kr. Med mindre man bevarer bookings-prisen vil den saa ikke senere kunne beregnes.
(e) Og jeg mener stadig at de historiske tabeller er unoedvendige. En kunde's bookings med status "afsluttet" er lig med kundens historiske bookings.
Saa til den situation du beskriver vil jeg mene at du skal bruge fire tabeller:
I bunden BOOKING med BookingNr som PK, KundeNr og VareNr som FK-er, og felterne start-datotid, slut-datotid, pris, status, og maaske bemaerkning (hvor du kan skrive ting som "Kunden ankommer sent, laeg noegle."
Til den ene side er der saa KUNDE med FK til FIRMA.
Til den anden side er der saa VARE med VareNr som PK og felterne Beskrivelse, pris, pris-enhed, og saa maaske igen bemaerkninger ("Trampolin-1 i stykker, forventes klar 15 juli ...").
Det blev igen en laengere historie. Jeg haaber du kan bruge noget af det.
van-ven. Kunne du ikke bare have spurgt om det fra starten? Du har spildt en masse af Christians tid. Dit spørgsmål kunne have været:
Har jeg normaliseret dette optimalt?
Dette og forklaringen i din sidste kommentar.
Ikke noget om det er 3NF eller eller Boys Codd. I praksis er det jo ikke begreber man bruger. Man kigger på hvordan man gør det bedst og er ligeglad med hvad man kan kalde det.
Ydermere er der en masse ting man kan koble på et normaliseret datasæt - afhængig af databaseplatformen man vælger. Der er constraints (kaskade), functions, procedure, triggere. Alt sammen noget som har praktisk værdi.
Derfor ville jeg rigtig gerne have set de færdige SQL-scripts til oprettelse af de få tabeller du har lavet. Det forarbejde havde givet dig meget bedre svar (dvs. ikke bedre, men mere relevante)
hrc, jeg noterer mig din sympati -- men jeg tror det er bedre at jeg selv formulerer hvad jeg har at sige. Du behoever saa kun at udtaler dig paa dine egne vegne.
Christian, tro ikke jeg taler din sag; det gør jeg ikke. Synes det er flot du leverer så store og velunderbyggede indslag - hvilket får mig til at tro du er ny på fora. Det gider man ikke efter et stykke tid. Efter et stykke tid forventer man et ordentligt velunderbygget (!) spørgsmål.
Uden ellers at agere selvbestaltet sysop, så taler jeg om almen god skik og praksis på Eksperten - og om respekt overfor de der gider hjælpe. Jeg synes det er ligegyldighed når spørgeren end ikke gør sig den ulejlighed at formulere spørgsmålet ordentligt - og det er hvad der er tale om her - og det var hvad jeg brokkede mig over.
hrc, du besvaerede dig i #9 over tid som du siger jeg har spildt. Jeg proevede i #10 paa en paen maade at sige at det behoever du ikke at bekymre dig om. Men jeg pakkede det nok saa meget ind at du ikke fattede det. Min skyld. Derfor siger jeg nu at jeg paa det bestemtest frabeder mig at du i dine kommentarer refererer til mig og til problemer du mener jeg har haft. Jeg gaar ud fra at du forstaar hvad jeg siger. Om du retter dig efter det kan jeg ikke kontrollerer. Jeg slutter denne debat her, det er ikke formaalet med denne traad. Men hav under alle omstaendigheder et godt nyt aar.
Naar saa det er sagt, van-veen fik du mit indlaeg #8? Var det til nytte/har du kommentarer?
Sikke en hostil tone du pludselig lægger. I #11 prøvede jeg på en (ditto) pæn måde at fortælle, at det ikke havde med dig at gøre. Spørgsmålet var dårligt stillet og det er mangel på respekt overfor de der forsøger at hjælpe.
Det er trættene at famle rundt i blinde, indtil spørgeren kommer med de oplysninger der sagtens kunne være leveret fra starten. Det er hvad der står i #9 - og jeg forstår ikke at du overser det. Ej heller forstår jeg dine problemer med at abstrahere fra jeg nævnte dit navn hvor der måske skulle have stået noget en generel reference til os med login på Eksperten.
Jeg afslutter hermed også mine indlæg på denne tråd. Gider ikke kværulere mere med dig.
van-veen, jeg proever lige en gang mere: Du oprettede spoergsmaalet og jeg gav adskillige indlaeg. Nu haaber jeg at du vil lukke spoergsmaalet, med eller uden points til mig, men saa du afslutter hvad du begyndte saa spoergsmaalet ikke laengere staar som aabent i min liste af indlaeg.
Jeg beklager, Af en eller anden årsag, har jeg først idag fået en e-mail omkring dette indlæg. Jeg takker for de flotte svar og håber det må hjælpe andre der kommer til at stå i samme situation som jeg var i.
Synes godt om
Ny brugerNybegynder
Din løsning...
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.
Ny bruger
Nybegynder
Opret
Preview
