Hej Alla!

Jag har ett problem med normalisering av en databas. Jag håller på med ett artikelregister som jag tex har en maskin som har ett artnr. maskinen har i sin tur delar som har egna artnr. Samma "delar" till en typ av maskin kan finnas till en annan typ maskin.

Det hela känns en smula abstrakt för mig:) så jag skulle vara tacksam om någon skulle kunna svara på min fråga.

om någon kanske vet om någon länk eller så vore jag tacksam

Mvh Venni

Glömde säga att en maskin kan ha flera leverantörer och naturligt vis kan en produkt(tex en maskin) ha flera order eller kunder. Varje del av en maskin kan produseras på olika avdelningar och olika sätt så som laser, svets mm.

som sagt...tycker inte om normalisering:)

Hjälp!!!

Mvh Venni

Hej Venni,

Normalisering av databaser är inte helt lätt.
Man bör ha lite erfarenhet av att designa databaser för att komma fram till ett bra resultat och det är inte säkert att man gör rätt första gången heller.
Man kanske kommer på att man måste designa om databasen lite efter att man har kört ett slag. Men man brukar kunna flytta om befintligt data utan att behöva lägga in datat igen.
Men, övning ger färdighet.... :-)

Om jag förstår dig rätt så kan dina tabeller se ut ungefär som nedan ?

Det som står inom parentes efter vissa "Fältnamn" är (PN) = Primärnyckel och (SN) = Sekundärnyckel.
Primärnyckel används på fält för att unikt skilja på värden.
Sekundärnyckel sätts inte men visar att det är ett fält för att länka ihop t.ex. flera Delar med EN unik maskin.

Maskin
======
ArtnrMaskin (PN)
BenämningMaskin
Ordernr (SN)
Kundnr (SN)
Leverantörsnr (SN)

Del
===
ArtnrDel (PN)
BenämningDel
ArtnrMaskin (SN)

Leverantörer
==========
Leverantörsnr (PN)
Levernatör
ArtnrMaskin (SN)

Kunder
======
Kundnr (PN)
ArtnrMaskin (SN)

Order
=====
Ordernr (PN)
ArtnrMaskin (SN)

Produktion
==========
Produktionsnr (PN)
ArtnrDel (SN)

Relationerna mellan de olika tabellerna skulle kunna se ut ungefär så här:

En Maskin många Del(ar)
ArtnrMaskin <1 till många> ArtnrDel

En Maskin många Leverantörer
ArtnrMaskin <1 till många> Leverantörsnr

En Maskin många Order
ArtnrMaskin <1 till många> Ordernr

En Maskin många Kunder
ArtnrMaskin <1 till många> Kundnr

En Del från olika Avdelningar
ArtnrDel <1 till många> Produktionsnr

Nu vet jag inte vilken typ av database du anväder, men principen är lika
för alla typer av databaser, så jag hoppas nedanstående kommer till nytta också.

För mer infromation kan du läsa ...
288947 - ACC2000: Where to Find Information About Designing a Database in Access
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q288947

Hittade också en kort artikel på svenska ...
http://lom.oru.se/asp/Informatik/itam/appl/documents/Access.pdf

Hoppas detta hjälper
Mikael - Microsoft

Om jag förstår dig rätt behöver du följande entiteter:

Produkt (P)
Produktdel (D)
Avdelning (A)
Order (O)

Förhållandena dessa emellan blir då:

P----O
|
|
D----A

P-O har ett många-till-många-förhållande (en produkt kan finnas i flera order, en order kan innehålla flera produkter).
P-D har också ett många-till-många-förhållande (en produkt kan innehålla flera delar, och en del kan finnas i flera produkter).
D-A har ett ett-till-många-förhållande (en del tillverkas av en viss avdelning, en avdelning kan tillverka flera delar).

Alltså blir tabellstruktrukturen typ så här:

PRODUCTS (pid PRIMARY KEY <plus andra kolumner med info>)
ORDERS (oid PRIMARY KEY <plus andra kolumner med info>)
ORDERPRODUCTS (oid FOREIGN KEY till ORDERS, pid FOREIGN KEY till PRODUCTS med oid+pid som PRIMARY KEY)
DEPARTMENTS (did PRIMARY KEY <plus andra kolumner med info>)
PARTS (ptid PRIMARY KEY, did FOREIGN KEY till DEPARTMENTS <plus andra kolumner med info>)
PRODUCTPARTS (pid FOREIGN KEY till PRODUCTS, ptid FOREIGN KEY till PARTS med pid+ptid som PRIMARY KEY)

Var det svar?


-- Edit: Entiteter ska ju skrivas i singular

www.databases.about.com har en kurs i normalisering.

Annars kan jag ta ett snabbt exempel:

Du har en klass med elever, ett antal kurser och eleverna ska få betyg. En databas
som behandlar detta bör se ut som följer:

Tabell Klass
klassID
klassnamn
...

Tabell Elev
elevID
elevnamn
...

Tabell Betyg
klassID
elevID
betyg
datum
...

Det kan många gånger kännas onödigt att lägga upp tre så små tabeller, men om
man tänker på hur enkelt det blir att bygga ut, och risken att det blir fel är mindre,
som en extra bonus går frågorna snabbare att ställa (kan verka konstigt eftersom
du har fler tabeller, men du får faktiskt färre rader - som är mer strukturerade)

Har du några frågor är det bara att fråga... =)

/Emma

Hej Alla...igen!

Jag har tittat lite på de inlägg jag fick svar på och klurat o klurat. Jag anser att min databas börjar ta sig men det är fortfarande en sak som jag anser vara fel och det är att jag inte ser någon anledning att skilja kunder och leverantörer åt. Det som skiljer en kund från en leverantör är inkomster och utgifter och det går ju att kontrolera genom en kontroll siffra i tabellen. tex

Tabell LevKund

FöretagsNr(PK)
Namn
Adress
PersNr(FK) där persNr inte står för personnr utan bara en vanlig främmande nyckel
...
LevKund (bit)
Spärrad (bit)
...


Tabell LevKundPers

PersNr(PK)
Namn
Telnr
MobNr
...

Har jag rätt eller fel? Följer jag inte hela tanke gången?

Mvh Venni

Nja, rent normaltekniskt så är det inte korrekt, eftersom de övriga attributen då blir beroende av ett icke-nyckel-attribut. På svenska innebär det att du har två olika entiteter i samma tabell, fast de egentligen är olika saker. Dock skulle du kunna ha Personer i en egen tabell, och både Leverantörer och Kunder kan ha en relation till den. Prestandamässigt är det inte heller bra (ganska naturligt eftersom man får bäst prestanda genom att designa korrekt), eftersom alla index för en tabell LevKund måste innehålla det attribut som visar om det är en leverantör eller kund, för att man ska kunna skriva WHERE-villkor som presterar bra. Det är helt enkelt onödigt att ha dem i samma tabell, du tjänar inget på det.

Hej Christoffer!

tack för inlägget!

ok, jag kan förstå och acceptera det du skrev men det motsäger faktiskt den tidigare förklaringen i ditt första inlägg. genom att: En produkt kan innehålla delar och delarna kan i sin tur innehålla andra mindre delar. allt detta måste beräknas i pris och arbetstid för varje enskild del(artikel) för att sedan summeras. varje artikel ändrar pris(ca 1 gång i månaden) för att kunna åstakomma detta så måste jag normalisera där med, inte sant? Det får inte vara en "stel" beräkning genom att jag tex bara räknar på hur många skruvar det finns i en produkt och summerar det utan jag måste kunna räkna på det hela utifrån varje nivå på varje artikel.


Mvh Venni

> jag kan förstå och acceptera det du skrev men det motsäger faktiskt den tidigare förklaringen i ditt första inlägg

Jag förstår inte riktigt vad du menar, det du skriver här har inget med LevKund att göra?

> En produkt kan innehålla delar och delarna kan i sin tur innehålla andra mindre delar

OK, detta hade jag inte uppfattat att du behövde. Då får vi ändra designen lite, eller iaf lägga till en liten del. Är en produkt egentligen också bara en del? Dvs, kan man beställa alla delar enskilt, vare sig de består av andra delar eller ej? Om jag börjar utgå från att så är fallet så kan vi skippa begreppet produktdel och helt enkelt kalla allt för produkter (vare sig det rör sig om en bil eller en skruv), och sedan lägger vi till en relation till sig själv. Jag har även lagt till leverantör och kund som jag uppfattat att de ska vara med.

Produkt (P)
Avdelning (A)
Order (O)
Leverantör (L)
Kund (K)

Förhållandena dessa emellan blir då:

L
|
|
P----O----K
|
|
A

L-P är ett många-till-många-förhållande
P-O är ett många-till-många-förhållande
O-K är ett många-till-ett-förhållande (en order har en kund, men en kund kan ha flera order)
P-A är ett många-till-många-förhållande

Dessutom har P ett många-till-många-förhållande till sig själv (en produkt kan bestå av många andra produkter, och varje produkt kan ingå i flera andra produkter). Och detta är det jobbiga, nu är du ute på ganska stora utmaningar. Detta är en s k flerförälder-hierarki (multi-parent hierarchy). De är hyfsat enkla att representera med hjälp av en extra tabell typ så här:

PRODUCTRELATIONS (parentid FOREIGN KEY till PRODUCTS, childid FOREIGN KEY till PRODUCTS med en PRIMARY KEY på dessa kolumner gemensamt)

Att sedan arbeta med en sådan hierarki är däremot ganska avancerat, åtminstone om man vill göra det hyfsat bra prestandamässigt sett. Med en enkel rekursiv metod kan man arbeta med dem, men det är värdelöst i prestandahänsyn. Dock kan jag inte i ett forum gå genom de övriga tekniker som finns för att hantera sådana här problem på ett korrekt mängdbaserat vis (jag kan dock hålla ett endagsseminarie om det om någon är intresserad), utan då kan jag bara rekommendera lite läsning. Det bästa du kan läsa om du verkligen vill lära dig sånt är Joe Celkos SQL for Smarties. Eller bara sök lite på Google om multi-parent hierarchies eller nested sets.

Ok, nu så:)
du uppfattade det hela helt rätt. Det var skilda tabeller men det jag menade var att var varför normalisera kundlev när det kändes som om produkter förenklades i sin struktur.

Är jag fel ute om jag försöker utveckla det hela genom lägga till en tabell som heter Produktnivå? Tänkte om jag på så vis slipper rekursivitet. som du sa är det en långsam metod som kräver en hel del tanke bakom.

Produkt (P)
Avdelning (A)
Order (O)
Leverantör (L)
Kund (K)
Innehållsförteckning(I)

Förhållandena dessa emellan blir då:

L
|
|
P----O----K
|
|
I
|
|
A

L-P är ett många-till-många-förhållande
P-O är ett många-till-många-förhållande
O-K är ett många-till-ett-förhållande (en order har en kund, men en kund kan ha flera order)
P-I är ett ett-till-många-förhållande(där jag utnyttjar en stående räknare i produkter)
I-A är ett ett-till-ett-förhållande

Jag vet att det gör det hela kanske normaliseringstekniskt fel men det borde kunna lösa det hela eftersom varje produkt måste byggas upp manuellt. En skruv kan ju inte vet om den tillhör en bil eller ett hus. Eller är jag på fel spår igen?

Mvh Venni

Vad är innehållsförteckning för något då?

> P-I är ett ett-till-många-förhållande(där jag utnyttjar en stående räknare i produkter)

Kan inte en produkt ingå i flera innehållsförteckningar, och en innehållsförteckning innehålla flera produkter? Dvs ett många-till-många-förhållande.

Produktnivå hänger jag inte riktigt med på, hur skulle du använda den?

innehållsförteckning är ett sätt för att slippa den rekursiva förhållandet.
en så kallad innehållsförteckning av av vad en produkt innehåller men även vilken nivå som en artikel befinner sig i. jag vet att det blir dubbel lagring om det nu skulle vara så att man skulle sälja en artikel direkt från lagerhyllan eftersom man då måste lägga upp en artikel som en produkt där nivån i innehållsförteckningen blir bara just den artikeln som finns i artikelregistret.
men låt oss säga att du har en en produkt tex en bil. du köper in 4 däck(finns i artikel registret) men du bygger karossen själv genom de råvaror du har(också artiklar du har i artikelregistret). karossen består av en massa delmoment för att få komplett. det kan tex vara så att du levererar en del av karossen till en annat bilmärk än ditt eget bilmärke. nåja, när du nu monterat din kaross vill du dokumentera vad varje arbetsmoment kostat i arbetstid, matrial och pengar. den totala summan av det hela tänkte jag lagra i produkt. när jag sedan gör en order lägger jag order tabellen där jag alltså har min historik. delar av historiken lagrar jag även i en annan tabell beroende på om det är delleveranser, del faktureringar osv...har inte riktigt kommit längre efter som jag fokuserar på att få i ordning kund, leverantör, produkt, innehållsförteckning och artikelregistret. så att jag kan börja programmera lite och få en ökad förståelse hur det hela kommer att fungera i "min" verklighet:)

tack för att du tar dig tid:)

Mvh Venni

Jo, det är väl en lösning, men den är som du säger ganska dubbellagrande och det är ju inte korrekt normaliserat. Dock tror jag inte det är nån mening att vi sitter och drar normalisering mer här, det är bättre att du kör på det du har och kommer igång och kodar som du säger. På så vis kommer du också få en bättre förståelse för hur normaliseringen påverkar din kod.

Kul tråd :)

Tycker många fastnar i fällan att sträva efter att ha en så "maximalt normaliserad" databas som möjligt. Man får inte glömma att det finns fler faktorer som spelar in när man bygger en applikation än att skapa den minst redundanta databasen som möjligt (vilket normalisering i princip går ut på).. ibland är redundans bra.. du kan i en del avseenden tjäna mer på att ha lite redundans i din databas.

Ville bara klargöra detta.. :)

Det viktiga är alltså att utgå från de krav man har på systemet och sedan skräddarsy databasen efter dessa.

/MJ

> ibland är redundans bra.. du kan i en del avseenden tjäna mer på att ha lite redundans i din databas.

Generellt sett, nej, det håller jag ej med om. Vad är det du tjänar? Prestanda vid läsning, visst, i vissa situationer kan man tjäna lite där, men ofta gör man det inte genom att ha redundans. Ex får du läsa in fler datasidor för att leverera ett resultat på en fråga mot en tabell med mycket redundans än du behöver om tabellen är korrekt normaliserad, och eftersom I/O står för den största 'prestandakorken' i databashantering så är det lätt hänt att redundans slår fel.

> Man får inte glömma att det finns fler faktorer som spelar in när man bygger en applikation än att skapa den minst redundanta databasen som möjligt (vilket normalisering i princip går ut på).

Normalisering (och relationsdatabasdesign) handlar inte om att 'skapa den minst redundanta databasen', det handlar om att definiera constraints som upprätthåller integriteten i databasen. Vad man absolut inte får glömma är att det finns andra faktorer än prestanda som spelar in när man designar en databas, den viktigaste faktorn är fortfarande upprätthållandet av data integritet. Annars kan man ju lika bra använda något annat än en relationsdatabas för att lagra sin data (om man ändå inte tänker utnyttja relationsmodellens styrka), t ex en vanlig textfil eller något mellanting som MySQL.

Hej igen.. kul att diskussionen fortsätter :)

>Generellt sett, nej, det håller jag ej med om. Vad är det du tjänar?

Det känns som om du missförstod mig. Om man ser på databasen på väldigt låg nivå.. så är det som du säger.. men det jag ville lyfta fram, och det som jag känndes saknades i diskussionen är att man måste höja sitt synsätt lite, och även se på sin applikation på en högre nivå. Du kan indirekt tjäna på att ha en mindre normaliserad databas i många fall.. det hela handlar om att tillgodose själva kraven för applikationen. (Du är inne på det själv, så jag tror vi är överrens egentligen..)

Citat från kurskompendie från högskolan i Skövde:
"En stor del av kursen databassystem består i att lära sig olika regler för hur normalisering av relationer går till. Normalisering är till fördel för databasen eftersom redundans undviks. Priset som betalas för den undvikna redundansen är att antalet relationer i databasen ökar vilket i sin tur ökar behovet för långsamma joinoperationer. Eftersom de flesta databassystem har problem med för låg prestanda så kan det vara av fördel att öka redundansen och därmed göra det möjligt att öka prestandan. Olika tekniker för att öka redundansen och därmed vinna prestanda kallas med ett samlingsnamn denormalisering."

>Normalisering (och relationsdatabasdesign) handlar inte om att 'skapa den minst redundanta databasen', det handlar om att definiera constraints som upprätthåller integriteten i databasen.

Normalisering var det jag pratade om.. och jag står fast vid att det i princip handlar om att skapa den minst redundanta databasen.

Definition från Computer Sweden (http://computersweden.idg.se/tjanster/sprakwebb/ord.asp?ord=normalisera)
"normalisera - (om relationsdatabaser) - se till att samma data bara finns på ett och endast ett ställe i databasen. Detta för att man bara ska behöva ändra på ett ställe när man ändrar. Det innebär att man också måste se till att det inte finns några data som är beroende av andra data i databasen. (Se atomära värden.) Exempel: en databas med försäljningssiffror från alla län i Sverige får inte samtidigt innehålla ett tal för hela Sverige. Det talet ska i stället räknas fram av ett program som lägger ihop siffrorna från länen. Då slår ändringar igenom automatiskt."

Men märk att jag skriver "i princip".. jag är medveten om att det handlar om att bevara integriteten i databasen, men det får man som resultat genom minimal redundans.. eller hur!?

> Hej igen.. kul att diskussionen fortsätter :)

Absolut! :)

> Det känns som om du missförstod mig.

Det tror jag inte tyvärr.

> Om man ser på databasen på väldigt låg nivå.. så är det som du säger.. men det jag ville lyfta fram, och det som jag känndes saknades i diskussionen är att man måste höja sitt synsätt lite, och även se på sin applikation på en högre nivå.

Höh? Om något, så skulle jag säga tvärtom. Om du med låg resp. hög nivå menar fysisk resp. logisk implementation så är denormalisering alltid fel på hög nivå (logisk modell). I en fysisk modell _kan_ denormalisering ge _vissa_ prestandafördelar, men dessa fördelar är isf riktade mot _en_ applikation (eller möjligen flera, men inte _alla_), och förmodligen t o m mot en viss funktion i denna applikation. I slutändan kan det snarare bli en nettoförlust i prestanda, eftersom den vinst man får i en viss funktion förmodligen uppvägs av den förlust man får i flera andra funktioner.

> Du kan indirekt tjäna på att ha en mindre normaliserad databas i många fall.. det hela handlar om att tillgodose själva kraven för applikationen. (Du är inne på det själv, så jag tror vi är överrens egentligen..)

Vi är absolut inte överens. :)
Vad kan man indirekt tjäna på att ha en mindre normaliserad databas? Prestanda? Som sagt, ja, för vissa specifika funktioner kan man få bättre prestanda (men som jag nämnde i mitt förra inlägg är det inte ens säkert att man får det pga t ex I/O-kostnader), men återigen är den viktigaste uppgiften för en relationsdatabas att upprätthålla integriteten i datan. För att göra det i en denormaliserad design måste DBMSen utföra kostsamma operationer vid datamodifieringar. Dessa operationer består av precis de select-satser man ville undvika genom att denormalisera, plus att man måste göra jämförelser.

> Citat från kurskompendie från högskolan i Skövde:
"En stor del av kursen databassystem består i att lära sig olika regler för hur normalisering av relationer går till. Normalisering är till fördel för databasen eftersom redundans undviks. Priset som betalas för den undvikna redundansen är att antalet relationer i databasen ökar vilket i sin tur ökar behovet för långsamma joinoperationer. Eftersom de flesta databassystem har problem med för låg prestanda så kan det vara av fördel att öka redundansen och därmed göra det möjligt att öka prestandan. Olika tekniker för att öka redundansen och därmed vinna prestanda kallas med ett samlingsnamn denormalisering."

Tråkigt att man även i den akademiska världen har problem med att förstå och följa teorin. Normalisering är ett krav för att upprätthålla integriteten i en relationsdatabas. Man måste skilja på den logiska och fysiska modellen. Joinoperationer är inte långsamma, det är den fysiska implementationen av dem som är långsam. Att en högskola inte lär ut databasteori utan istället inriktar sig på fysisk databashantering är som sagt tråkigt. Att de inte förstår kostnaden av att 'släppa' integriteten för (möjlig) prestandavinst (i vissa specifika fall) är oförklarligt.

>> Normalisering (och relationsdatabasdesign) handlar inte om att 'skapa den minst redundanta databasen', det handlar om att definiera constraints som upprätthåller integriteten i databasen.

> Normalisering var det jag pratade om.. och jag står fast vid att det i princip handlar om att skapa den minst redundanta databasen.

OK, vi ska inte diskutera enskilda ord och jag kan acceptera att det 'i princip' handlar om att ta bort redundans i en databas. Märk väl att det är skillnad på redundans och duplicerad data. Redundans är _onödigt_ duplicerad data.

> Definition från Computer Sweden (http://computersweden.idg.se/tjanster/sprakwebb/ord.asp?ord=normalisera)
"normalisera - (om relationsdatabaser) - se till att samma data bara finns på ett och endast ett ställe i databasen. Detta för att man bara ska behöva ändra på ett ställe när man ändrar. Det innebär att man också måste se till att det inte finns några data som är beroende av andra data i databasen. (Se atomära värden.) Exempel: en databas med försäljningssiffror från alla län i Sverige får inte samtidigt innehålla ett tal för hela Sverige. Det talet ska i stället räknas fram av ett program som lägger ihop siffrorna från länen. Då slår ändringar igenom automatiskt."

Jo, det var ju en definition. Som sagt, redundans och duplicerad data är inte riktigt samma sak. Men visst, de menar nog rätt där. Men det handlar inte om att man bara ska behöva ändra på ett ställe (det låter som att normalisering bara är till för att förenkla för användaren), utan snarare om att se till att man inte kan skapa korrupt och inkonsistent data. Att det sedan blir enklare för användaren är bara en fin extra effekt. Vad de menar med "Det innebär att man också måste se till att det inte finns några data som är beroende av andra data i databasen" låter jag vara osagt. I den tolkning som används i exemplet nedan är det att man inte får ha beroenden mellan olika rader i en tabell (vilket förstås är korrekt). Jag antar att vad de skulle ha sagt är att "man måste se till att det inte finns någon data som är beroende av annan, icke-nyckel information", eller något liknande.

> Men märk att jag skriver "i princip".. jag är medveten om att det handlar om att bevara integriteten i databasen, men det får man som resultat genom minimal redundans.. eller hur!?

Jo, men varför då öka redundansen när man är medveten om att det inte bevarar integriteten?? Jag frågar igen, varför använda en relationsdatabas om man inte ska utnyttja den?

Hej Alla igen!

Kul att mitt inlägget har fått sådan reaktion:)
Trodde aldrig att att detta inlägget kunde ge mig så mycket.

Jag har en lite enklare fråga när det gäller MSSQL. Var går gränsen för hur många kolumner man "bör" ha i en tabell. Det är så att jag upptäckt att jag kan slå ihop 4 tabeller i 1, men jag är inte säker på att resultatet blir bra. Det blir ca 50 kolumner i en enda tabell. Jag kan inte se att det vore lämpligt att ha den mängden av kolumner i en enda tabell, men vem vet jag kanske har fel igen:)

Att i programmet uppdatera 50 st kolumner gör att det hela kan lätt bli fel. bör jag uppdatera tabellen stegvis tex mina 4 steg som jag hade tidigare men slå ihop tabellerna till en. Samma gäller att lägga in ny data.

en annan fråga som jag undrar över är om det i så fall är lämpligt att ha många null värden i denna tabell? Är null värden något positivt eller något negativt.

Mvh Venni

Varje kolumn (eller rättare sagt värdet i varje kolumn) ska vara funktionellt beroende av nyckeln, hela nyckeln och inget annat än nyckeln. Alltså, de attribut som tillhör en entitet ska lagras med den. Det finns ingen speciell gräns för hur många dessa får vara. Utan att veta vad det är för tabell och vilka kolumner det handlar om så antar jag dock, speciellt utifrån att du har en massa nulls, att det inte är korrekt normaliserat.