Teknologi, AI og forretning er i centrum på Computerworlds Cloud og AI Festival i København d. 18. og 19. september. Se hele programmet for den store konference om strategisk brug af Cloud og AI på: www.cloud-festival.dk
Og hvis ialt_pris er hvad jeg tror det er, så er der noget galt i bestillinger idet det virker som om "ordre linier" og "total ordre" er blevet blandet sammen.
"Umiddelbart synes jeg ikke der er det store at normalisere !" Men det synes jeg!!
"VNavn må kunne fjernes fra bestillinger, da det kan findes via VId i vare." ok
"alle priserne må kunne fjernes fra bestilleinger da de enten kan slåes op i vare eller beregnes." ok
"Og hvis ialt_pris er hvad jeg tror det er" hvad tror du det er? ialt_pris fås på denne måde: apris * antal = samlet_pris alle samlet_pris lægges sammen, og vupti! = ialt_pris. :)
"Og jeg savner en BestId i bestillinger !" det er rigtigt. Den glemte jeg at skrive. :)
I tabellen vare er VId og VNavn kandidatnøgler. Disse nøgler er entydige dvs. at f.eks. er der ikke to ens VId’er. VId er valgt som primærnøgle, fordi denne er den eneste kandidatnøgle som vil forblive uændret. Derudover er VId afhængig af butik og VId er også afhængig af kategori. For at skabe sikkerhed og undgå redundans, er tabellen delt op i tre tabeller: vare, vare_kategori og vare_pris.
vare_pris tabellen indeholder pris, BId og VId, hvor VId er primærnøgle. VId er valgt som primærnøgle, da der ikke er andre nøgler i denne tabel.
I tabellen vare_kategori er KId kandidatnøgle. Denne nøgle er entydig dvs. at f.eks. er der ikke to ens id’er. KId er valgt som primærnøgle, da der ikke er andre nøgler i denne tabel. VId er fremmednøgle.
I tabellen menu er MenuId og MNavn kandidatnøgler. Disse nøgler er entydige dvs. at f.eks. er der ikke to ens MenuId’er. MenuId er valgt som primærnøgle, fordi denne er den eneste kandidatnøgle som vil forblive uændret. Derudover er UnderMId afhængig af MenuId og UnderMNavn, ULink er afhængig af UnderMId. For at skabe sikkerhed og undgå redundans, er tabellen delt op i tre tabeller: menu, menulink og links.
menu tabellen indeholder MenuId og MNavn, hvor MenuId er primærnøgle. MenuId er valgt som primærnøgle, fordi denne er den eneste kandidatnøgle som vil forblive uændret.
I tabellen menulink er OMenuID og UMenuID en sammensat kandidatnøgle. Denne nøgle er entydig dvs. at f.eks. er der ikke to ens id’er. OMenuID og UMenuID er valgt som primærnøgle, da der ikke er andre nøgler i denne tabel. OMenuID og UMenuID er begge fremmednøgle.
Jeg er lidt i tvivl om den sidste:
I tabellen menulink er MenuID kandidatnøgle. Denne nøgle er entydig dvs. at f.eks. er der ikke to ens id’er. MenuID er valgt som primærnøgle, da der ikke er andre nøgler i denne tabel. MenuID er fremmednøgle.
eller skal det være sådan:
Tabellen menulink indeholder MenuID og link. Der er ikke nogen nøgler i denne tabel. MenuID er fremmednøgle.
eller:
Tabellen menulink indeholder MenuID og link, hvor MenuID og link er valgt som sammensat primærnøgle, da der ikke er andre nøgler i denne tabel. MenuID er fremmednøgle.
Jeg har ikke læst hele tråden, men jeg vil kraftigt fraråde at fjerne prisen fra bestilingen. Dvs. hvis en vare ændrer pris efter en kunde har afgivet en bestilling slår det også igennem der. Ville du selv være tilfreds med det, med mindre prisen gik ned? ;-) (Desuden giver det også mulighed for at give kunden rabat manuelt.)
Bestillingerne vil, som regel, blive leveret dagen efter en bestilling. Så risikoen er nok ikke stor, desuden taler vi heller ikke om priser på tusindevis af kroner.
Dvs. sålænge man kun snyder folk lidt er det ok? Øhh, pointe ikke forstået :-)
I et "rigtigt" system vil man enten kopiere prisen over på bestillingen, eller have detaljeret historik i varepris ved at tilføje en gyldighedsperiode, typisk bare et stoptid. Og selfølgelig tilføje tid på bestillingen så man altid kan finde prisen på tidspunktet for bestillingen. (Med priser har jeg dog aldrig set eller lavet andet end det første. Det er faktisk tvivlsomt og det overhovedet er lovligt at gøre det via historik, men det er en anden diskussion)
Brugeren bestiller varerne. Dagen efter købes disse varer(og andres bestillinger) af virksomheden. Hjemme hos virksomheden bliver varerne pakket om. Til sidst køres varerne ud til kunden.
Det skal jo "kun" bruges til et skole projekt, men jeg kan da godt se dit synspunkt. :)
Netop til et normaliserings projekt vil det være godt at have noget der umiddelbart ligner redundant data. Det gælder bare om at have argumenterne klar :-)
I praksis betyder ovennævnte altså at butikken aldrig (eller sjældent) har varen på lager. Når virksomheder kontakter sin leverandør for at få varer sker der i realiteten ofte det at prisen er anderledes end sidst varen blev købt. Derfor må virksomheden vurdere om den skal lade den nye indkøbspris resultere i en ny salgspris. Derfor er der faktisk stor risiko for at prisen ændres fra kunden bestiller varen til den afsendes. Hvis virksomheden derimod kørte med stort lager var det måske ikke så ofte det ville ske. Så er vi henne og diskutere hvilket pris princip der kører etc. (Ligesom jura diskussionen er det vist et andet projekt)
Under alle omstændigheder skader det næppe at kunne fyre lidt af til sin underviser/karaktergiver ;-)
altså: fd 1: abonnementnummer holder alle andre attributter. fd 2: BestilId holder alle andre attributter, undtagen abonnementnummer. fd 3: VId og butik holder APris. fd 4: APris og antal holder samlet_pris. fd 5: samlet_pris holder ialt_pris.
Du tager definition på BCNF og bruger den på alle tabeller efter normalisering (og BCNF betyder også 3NF). Det betyder lidt skrive arbejde men er vel ret trivielt.
fd 1: VId holder alle andre attributter. ---- ikke rigtig (butik, kategori, pris) fd 2: VId og butik holder pris. ---- rigtig fd 3: kategori holder VId. ---- ikke rigtig
fd 1: abonnementnummer holder alle andre attributter. ----- no fd 2: BestilId holder alle andre attributter, undtagen abonnementnummer. ---- no fd 3: VId og butik holder APris. ---- yes fd 4: APris og antal holder samlet_pris. ---- yes fd 5: samlet_pris holder ialt_pris. ---- delvist
"fd 1: VId holder alle andre attributter. ---- ikke rigtig (butik, kategori, pris)"
Mener du de skal fjernes fra den fd?
"fd 3: kategori holder VId. ---- ikke rigtig" Hvordan så? Omvendt?
"fd 1: abonnementnummer holder alle andre attributter. ----- no" "fd 2: BestilId holder alle andre attributter, undtagen abonnementnummer. ---- no" Samme som den anden fd 1?
"fd 5: samlet_pris holder ialt_pris. ---- delvist" Hvordan delvist?
Ja. VId determinerer ikke hverken butik (en vare kan sælges i flere butikker), kategori (en vare kan være i flere kategorier), pris (forskellige butikke rkan have forskellig pris for samme vare).
kategori og vare er så vidt jeg har forstået en M:M relation d.v.s. ade ikke rigtigt determinerer hverken den enne eller den anden vej.
samlet_pris er en aggregering af ialt_pris o det er ikke rigtigt en determinering.
bestilling og bestillinglinie skulle nok hav eværet splittet op allerede inden normnalisering.
vare: fd 1: VId holder alle attributter undtagen butik, kategori og pris. fd 2: VId og butik holder pris.
bestillinger: fd 1: BestilId holder alle andre attributter, undtagen abonnementnummer. (I bestilling) fd 2: VId og butik holder APris. fd 3: APris og antal holder samlet_pris.
vare: fd 1: VId holder alle attributter undtagen butik, kategori og pris. ---- ok fd 2: VId og butik holder pris. ---- ok
bestillinger: fd 1: BestilId holder alle andre attributter, undtagen abonnementnummer. (I bestilling) ---- ? fd 2: VId og butik holder APris. ---- ok fd 3: APris og antal holder samlet_pris. ---- ok
Jeg vil sige at BestilID kun determinerer butik og abonnementsnummer.
I tabellen bestillinger er BestilId kandidatnøgle. Denne nøgle er entydig dvs. at f.eks. er der ikke to ens BestilId’er. BestilId er valgt som primærnøgle, da der ikke er andre nøgler i denne tabel. Derudover er APris afhængig af butik og VId. samlet_pris er afhængig af APris og antal. For at skabe sikkerhed og undgå redundans, er tabellen delt op i to tabeller: bestilling og bestillingslinie.
bestillingslinie tabellen indeholder BestLinId, BestID, VId og antal, hvor BestLinId er primærnøgle. BestLinId er valgt som primærnøgle, da der ikke er andre nøgler i denne tabel. BestID og VId er fremmednøgler.
I tabellen profiler er brugernavn og abonnementsnummer kandidatnøgler. Disse nøgler er entydige dvs. at f.eks. er der ikke to ens brugernavne. abonnementsnummer er valgt som primærnøgle, fordi denne er den eneste kandidatnøgle som vil forblive uændret. Derudover er postnummerby en sammensat attribut, som består af postnummer og by. For at skabe sikkerhed og undgå redundans, er tabellen delt op i to tabeller: profiler og postnummerby.
postnummerby tabellen indeholder postnummer og by, hvor postnummer er primærnøgle. postnummer er valgt som primærnøgle, da der ikke er andre nøgler i denne tabel.
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.
