Databasdesign

:birp
Hej!

Håller att gå över från skräpdatabas till en riktig databas. MS SQL-server.

Eftersom jag tänkte göra det hela rätt från början denna gången så undrar jag om någon på detta eminenta forum kunde ge lite tips och råd om hur man designar en databas på ett bra sätt!

Databasen skall vara en artikleldatabas med följande tabeller:

tblArticle
*articleNumber (PK)
*articleName
*articleUnit

tblPrice
*articleNumber
*articlePrice
*articleCategory
*articleSupplierId

tblSupplier
*supplierId (PK)
*supplierName

tblCategory
*category
*categoryName

tblDiscount
*category
*discount

Kan detta vara något eller har jag tänkt helt fel. Finns det skaer som kan förbättras mm. Mycket tacksam för synpunkter!

Och vilka datatyper skall man använda? samt när ska man tillåta NULL respektive Inte tillåta NULL?

Mvh
Henrik

Ser väl bra ut till en början Dock bör det finnas en tid för pris dvs giltigt från till datum.
Det måste finnas artnr och namn och en leverantör. Lägg upp standardvärden i stödtabeller så kan du låsa till även dessa.
Viktigt att datayperna är likartade förstås!
Antal i lager, beställda, säsongsvariantion, först in först ut dvs lot hantering, beställningspunkt!

Lasp skrev:

...Lägg upp standardvärden i stödtabeller så kan du låsa till även dessa....

Hej!

Tack för synpunkterna!

Men vad menar du med ovanstående citat?

//Henrik

Typ i Supplier 999,Inte bestämt Discount 0, nollrabbatt eller tomt men att värdet 0 skall finnas. DVS tvinga fram defaultinmatningar för att skapa kontroll.

:e
Hoj!

Skickar med en skärmdump från MS SQL Server management studio express...

Är jag rätt på det eller har jag gjort några felaktigheter i mina tabeller?

Mvh
Henrik

Känns väl inte helt rätt. Jag skulle nog ha lagt både category och supplier närmare artikel i sig. Men du kanske har en tanke som jag inte kan läsa av ännu? Och tiden för ett giltigt pris! Var tog det vägen?

Jag håller med lasp. Sedan skulle jag ändra din price tabell från

tblPrice
*articleNumber
*articlePrice
*articleCategory
*articleSupplierId

till

tblPrice
*articleNumber
*articlePrice
*articleSupplierId

Anser att articleCategory är knuten till artikel tabellen. Det enda du behöver för att identifiera ett pris "unikt" är articleNumber och articleSupplierId. Dessa två skulle jag sedan ha som primärnyckel.

Detta skulle leda till att jag även skulle ändra

tblArticle
*articleNumber (PK)
*articleName
*articleUnit

till

tblArticle
*articleNumber (PK)
*articleName
*articleUnit
*articleCategory

Sedan tycker jag att du saknar en hel del i din design! Jag skulle börja med att modellera med penna och papper för att få fram relationer och således även främmande nycklar som jag tycker dina tabeller helt och hållet saknar.

Om du är intresserad av att se lite hur jag tänker när jag modellerar så skrev jag två ganska långa inlägg på ett annat forum, där jag "hjälpte" en med lite modellering: läs här

Hej!

I tblPrice kan ju samma artikelnummer finnas med flera gånger fast med olika leverantörer. Kan articleNumber vara Primary Key då?

Mvh
Henrik

Compusa skrev:

...Det enda du behöver för att identifiera ett pris "unikt" är articleNumber och articleSupplierId. Dessa två skulle jag sedan ha som primärnyckel...

Sedan tycker jag att du saknar en hel del i din design! Jag skulle börja med att modellera med penna och papper för att få fram relationer och således även främmande nycklar som jag tycker dina tabeller helt och hållet saknar.

Om du är intresserad av att se lite hur jag tänker när jag modellerar så skrev jag två ganska långa inlägg på ett annat forum, där jag "hjälpte" en med lite modellering: läs här

Självklart är jag intresserad av det! Jag ska läsa på!

Att jag ställer frågan här beror på att jag vill lära mig att göra detta riktigt från början. Har lekt en del i access innan men kände att det var dags att lära sig ordentligt denna gången!

Mvh
Henrik

Kan articleNumber vara Primary Key då?

Ja, tillsammans med leverantörs-ID.

Nej, det var därför jag skrev att articleNumber och articleSupplier blir din primärnyckel, composite key, tror jag det kallas.

primarykey(articleSupplierID, articleNumber).

Om du vill ha en bra databas så är mitt tips att du läser lite på lite om modellering av databaser (no offence). Jag skulle aldrig sitta direkt med tabeller och pula, såvida man inte har grymma kunskaper och erfarenheter. Om du orkar läsa och vill lära dig så kan jag rekommendera dig denna länk som är mycket bra.
http://www.databasteknik.se/webbkursen/

/edit, Anders var snabbar :)

Compusa!

Vad tycker du jag saknar i min design då?... (säkert massor... ;) )

Jag är mycket tacksam för hjälp och tips!

Mvh
Henrik

@nders skrev:

Kan articleNumber vara Primary Key då?

Ja, tillsammans med leverantörs-ID.

Det där fattar jag inte... :(

Det är väl bara en kolumn som kan vara PK? eller :q

Mvh
Henrik

Compusa skrev:

...om man inte har grymma kunskaper och erfarenheter. Om du orkar läsa och vill lära dig så kan jag rekommendera dig denna länk som är mycket bra.
http://www.databasteknik.se/webbkursen/
QUOTE]

Hehe!

Varken grymma kunskaper eller erfarenheter... :)

Mvh
Henrik

Jag tycker du saknar lite av varje plus att jag ogillar ditt tillvägagångssätt ;)
Läs lite på länken som jag redan postat:
http://www.databasteknik.se/webbkursen/

1. ER-diagram kan vara en bra början
2. Sedan skapar du relationer av ditt diagram
3. Normalisera databasen
4. Lägg in tabellerna i det programet du arbetar med nu

Som du ser så tycker jag att du har gått på det sista steget direkt.

devotion skrev:

Det där fattar jag inte... :(
Det är väl bara en kolumn som kan vara PK? eller :q

Nej, flera attribut kan bilda en primärnyckel tillsammans, dvs den unika kombinationen av dessa attribut. Det kallas composite key.

Hehe!
Varken grymma kunskaper eller erfarenheter... :)

Då tycker jag du ska läsa den webb-kursen. Du kommer ha använding och glädje av kunskaperna du införskaffar. :)

Compusa skrev:

...att jag ogillar ditt tillvägagångssätt ;)

Hehe... Jag har märkt det!.. :D

1. ER-diagram kan vara en bra början
2. Sedan skapar du relationer av ditt diagram
3. Normalisera databasen
4. Lägg inte tabellerna i det programet du arbetar med nu

Att jag började så här beror på att jag inte viste bättre... Men nu läser jag på!

Nej, flera attribut kan bilda en primärnyckel tillsammans, dvs den unika kombinationen av dessa attribut. Det kallas composite key.

Jag har lärt mig det nu... tack! :)

Då tycker jag du ska läsa den webb-kursen. Du kommer ha använding och glädje av kunskaperna du införskaffar. :)

Jag läser....

Mvh
Henrik

devotion skrev:

Att jag började så här beror på att jag inte viste bättre... Men nu läser jag på!

Jag gjorde på precis samma sätt som dig, innan jag visste bättre ;)

Jag såg att jag skrev väldigt fel i mitt förra inlägg:

4. Lägg inte tabellerna i det programet du arbetar med nu

Det ska natruligtvis vara:
4. Lägg in tabellerna i det programet du arbetar med nu

Iiiihhhh!

Läser om ER-modellering.......och det var ju inte det lättaste... :q

Någon som kan ge en spark i rätt riktning...

Ett vanligt fel
Nybörjare på ER-diagram gör ibland följande fel. Om de får uppgiften att rita ett ER-diagram för sin skola, så börjar de med att rita en ruta:

Det här är förstås galet, eftersom det här ER-diagrammet säger att det finns en entitetstyp som heter "skola", och alltså kommer databasen att innehålla ett antal skolor (entitetsinstanser av entitetstypen "skola"). "Skola" hade passat som rubrik till hela ER-diagrammet, men inte som en entitetstyp.

Så var man borta med man och allt.... ;)

Ska jag ha med "rutan" artikel, eller ska hela mitt ER-diagram heta artikel.. :q

Mvh
Henrik

**fortsätter och läsa på...** ;)

Vad är det din databas ska hålla data för?

Låt oss säga att du gör ett artikelregister för Pelle Bloms Järnhandel, då skulle det vara fel att rita en ruta (entitet) med texten "artikel register" eftersom det är detta som hela E/R-modellen ska skildra.

Exempel på entiteter:
Artikel
Leverantör

Bara att fråga på om du undrar något. Du kommer se fördelerna och vilken hjälp detta ger dig så småningom.

Min databas ska innehålla data om elartiklar från flera leverantörer (grossister) Tanken är att när den är klar ska man kunna jämföra priser på samma artikel (sama artiklenummer) från olika leverantörer. Och kanske på motsvarande artiklar som har olika artiklenummer. Men det kanske är ogörligt svårt...

entiteter:
*Artikel
*leverantör
*kategori
*Enhet
*pris

Är jag på rätt spår?

Mvh
Henrik