Databas design

Hallå...

Jag sitter och klurar på en bra databasdesign för ett litet problem som jag funderar över.

Följande är scenariot:
Detta gäller en artikelregister för olika typer av möbler och andra inredningsgrupper så som Lampor, Galleri, Mattor osv osv...

Till varje grupp ovan finns under grupper. Så hos möbler så finns undergrupper: Fåtölj, Soffa 2-Sits, Soffa 3-sits, Pall, Soffbord, Matbord osv osv. För Lampor så finns undergrupper: Bordlampa, Taklampa, Golvlampa, Vägglampa osv osv...

De olika artiklarna brukar man kunna dela in i Serie. Säg att man vill ha en serie Magnus som består av: Fåtölj, Soffa 2-sits, Matbord och en Pall.
Fåtöljen, soffan och Pallen kan man få i olika material typ: Läder eller Tyg, för varje material är det olika färgval. Till Läder så är det: Begie och Svart, medans tyget finns i Röd, Vit. Matbordet finns i Ek, Valnöt och Lackad skiva, där man kan välja färgerna Röd, Vit.

Som märkes så blir det en del valmöjligheter och jag skulle nu vilja få till en databasdesign som gör det enkelt för mig att plocka fram de olika valmöjligheter som finns om jag står på en given artikel.

Säg att jag vill skapa en skylt för min fåtölj. Jag vill du kunna plocka fram vilka andra typer av möbler som finns i denna serie 'Magnus'. Jag skall också kunna se vilka andra färger som finns i just detta material (säg att artiklen som jag står på är Läder-Beige). Det betyder att skylten skall kunna visa att detta är material Läder och Färgen Beige, men att den även finns i färgen Svart. Samt att den även finns i andra material så som Tyg.

Detta vill jag uppnå:
Det jag vill eftersträva är att om jag lägger till en ny artikel, säg att det kommer en ny fåtölj i läder där färgen är röd. Så vill jag kunna plocka fram de artiklar som måste få en ny skylt. Alltså alla fåtöljer i läder och skriva ut dessa igen, där färgen röd är ditt lagd. Om det kommer ett nytt material, säg manchestertyg, så skall man kunna plocka fram alla fåtölj ariklar för att genererar nya skyltar för dessa. Skyltarna skall givetviss skapas utifrån datan som finns i databasen så man inte skall behöva skriva in färger och sånt manuellt.

Jag har suttit och klurat lite och kommit fram till följande borde lösa mina problem, men tycker det blir onödigt krångligt och samtidigt lite väl böckigt att hämta ut datan från databasen på ett snabbt och snyggt sätt.

Här är hur jag tänkt:

Serie tabellen:
Innehåller namnet på serien 'Magnus' och att den tillhör gruppen Möbler (om man nu vill ha en 'Magnus' serie hos lampor.

BaseArticlen:
Innehåller basinformation för artiklen, så som att det är en fåtölj, att den tillhör en speciell serie och andra saker som är gemensamt för att olika fåtöljer i serien, så som leverantörsinformation, storlek osv osv..

OptionGroup:
Innehåller de olika valmöjlighetesgrupper som finns, så som Material, Färg och andra saker som man skall kunna specifisera för artiklar, typ Lampsort för lampor.

OptionDetail:
Innerhåller detaljer för en valmöjlighetsgrupp, så för Material så blir det Läder, Tyg, ManchesterTyg. För färg blir det: Röd, Vit, Svart osv osv..

Article:
Innehåller specifia detaljer för den specifia produkt, så som uniktId, EanCode, Inpris osv osv... Det är denna artikel som består av baseartikel och alla olika valmöjligheter.

ConnectionTable:
Här binder man ihop baseartiklen, men de olika valmöjlighetsdetaljerna tillsammans med artikelID.

Tacksam för input hur förändringar kan göras...

Det är väl en bra början, någon sorts "Ingår i" och "Består av" Men det måste ju finnas trigger möjligheter vid tillägg. Skall fundera, men bra presenterat.

Enkelheten får ofta offras på dynamikens altare, men min erfarenhet från just möbeldatabaser är att man skjuter sig själv i foten om man inte bygger på detta viset. Varje unik kombination av material, färg etc. måste finnas unikt definierad i databasen. I praktiken blir det ändå inte särskilt svårt att ställa frågor.

Triggers är användbara, men som en lösning på ett modellproblem är de mest en indikation på att man bör tänka om (inte utan undantag, förstås, men nästan).

Ett par anmärkningar:

1. Kategorin i "Serie" är en bekvämlighetskolumn och inte relevant i modellen.
2. FK till BaseArticle bör ligga i Article, inte i ConnectionTable.
3. Det kan vara en tanke att föra in en 1:n-relation mellan Category och OptionGroup, bl.a. för att kunna presentera vettiga sök- och detaljformulär.

Jag fyller på med lite mer information.

Att varje artikel måste vara unik för just sin kombination är självklart, speciellt om man skall koppla det till en webshop, där det blir lite svårt för packaren att vet vilken färg kunden valt, om alla fåtöljer läder ligger på samma arikelnummer. Tyvärr är det väldigt vanligt att man låter fler likadana artiklar som endast skiljer i färg lika på samma artikelnummer.

Man behöver dock inte komplicera till det så mycket som jag gjort för att få det unikt, det räcker med en artikeltabell som refererar till en materialtabell och färgtabell, men det jag tappar så fall är den koppling som finns mellan de olika valalternativen för en artikel och de artiklar som finns i en serie och det är den kopplingen som är viktig.

Här kommer min input till dig emisson

emisson skrev:

1. Kategorin i "Serie" är en bekvämlighetskolumn och inte relevant i modellen.

Nja.. Det kan nämligen vara så att jag har en serie 'Magnus' för kategorin Möbler och sedan en serie 'Magnus' för Lampor och dessa serie hör inte ihop på något sätt mer än de råkar ha samma namn, så jag måste kunna separera dem åt på något sätt, och bara namnet är inte tillräckligt, för hur skall man då vet vilken serie som min fåtölj skall ingå i....

emisson skrev:

2. FK till BaseArticle bör ligga i Article, inte i ConnectionTable.

mmmmm.... det skulle kanske fungerar, samt att min connectiontable bara blir en många till många tabell mellan artiklarna och valmöjligheterna... om det fungerar så blir det ju snyggare och mer korrekt.. skall klura vidare på det...

emisson skrev:

3. Det kan vara en tanke att föra in en 1:n-relation mellan Category och OptionGroup, bl.a. för att kunna presentera vettiga sök- och detaljformulär.

Hur menar du då? OptionGroupen har inget med kategorin att göra utan beskriver bara vilka möjligheter som finns för artiklen.

Jag vet att OptionGroup och OptionDetail är lite "overkill" i dessa exempel där man bara har Material och färg som valmöjligheter, så då skulle man ju enkelt kunna skapa 2 tabeller med dessa och sedan koppla sig direkt mot dem, men jag vet också av erfarenhet att det man inte ser i början och inte tar höjd för blir jobbigt att implementera senare, så därför försöker jag göra det så dynamiskt som möjligt från början utan att komplicera det allt för mycket. Det är möjligt att det blir 2 seperata tabeller och kommer jag på något senare så får jag lägga till den tabellen då....

Angående triggersen så löser jag själva triggningen av händelser som skall ske när något är ändrat i koden istället, och slipper lägga det i databasen, eftersom jag vilket fall som helst måste upp med ändringen till koden eftersom någon skall informeras att en ny skylt måste skrivas ut...

Fram med förslagen bara, jag vill ha det så bra som möjligt...

- M

Gladh skrev:

Man behöver dock inte komplicera till det så mycket som jag gjort för att få det unikt, det räcker med en artikeltabell som refererar till en materialtabell och färgtabell, men det jag tappar så fall är den koppling som finns mellan de olika valalternativen för en artikel och de artiklar som finns i en serie och det är den kopplingen som är viktig.

Förvisso kan du denormalisera och flytta in informationen i egna kolumner i Article - huvudsaken är att det finns en unik entitet i modellen som definierar en specifik "konfiguration" av en möbel - men särskilt mycket smidigare blir det inte, snarare tvärtom.

Gladh skrev:

Nja.. Det kan nämligen vara så att jag har en serie 'Magnus' för kategorin Möbler och sedan en serie 'Magnus' för Lampor och dessa serie hör inte ihop på något sätt mer än de råkar ha samma namn, så jag måste kunna separera dem åt på något sätt, och bara namnet är inte tillräckligt, för hur skall man då vet vilken serie som min fåtölj skall ingå i....

Sant. Kanske en relation till Category då (det kanske var menat så).

Gladh skrev:

Hur menar du då? OptionGroupen har inget med kategorin att göra utan beskriver bara vilka möjligheter som finns för artiklen.

Jajamen, men de olika möjligheter som finns för en artikel är ofta gemensamma inom en kategori. "Lampsort för lampor" nämnde du själv. Jag menar inte att detta ska vara en constraint, utan en schema-finess. Två scenarion:

1. Detaljformulär för administrering av en ny artikel. Så fort kategorin är vald kan droppmenyer skapas för de sannolika optionvalen.
2. Sökformulär. Om sökningen görs i ett kategorikontext kan formuläret skapas dynamiskt.