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:
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!
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.
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?
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.
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
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!
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/
...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]
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. :)
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. :)
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
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...
