Forum Mjukvara Programmering och digitalt skapande Tråd

Databasmodellering

1
Skriv svar
Permalänk
Medlem
●

Databasmodellering

Tjena!

Ska börja med ett nytt projekt nu, men jag är lite osäker på hur jag skall utforma min databas.
Mitt diagram ser ut såhär:

Jag har tänkt följande:
En dag skall kunna ha en lagerstatus, alltså vad man har kvar i lager.
En dag skall kunna ha en beställning per dag.
En försäljningsrad skall kunna ha en artikel per rad.
En dag skall kunna ha flera försäljningsrader.
En beställningsrad skall kunna ha en artikel per rad.
En beställning skall kunna ha flera beställningsrader.

Har jag tänkt rätt eller hade ni modellerat på något annat sätt?
Sen, kommer ni på något bättre namn än Lager?

Redigera
Citera flera Citera
Permalänk
Medlem
●

Vad är egentligen skillnaden på försäljningsrad och beställningsrad? Och varför kan dag inte ligga direkt som en kolumn i beställning? Det är ju bara att köra en select på datumet du vill ha ut? Likadant med lager, varför ligger inte "antal artiklar på lager" direkt på artiklar? Tycker det känns lite ologiskt, eller så är det bara för att jag inte förstår konceptet bakom projektet.

Visa signatur

Silverstone TJ08-E | Seasonic X-750 | Asus ROG STRIX M450-I | AMD Ryzen 3700X | Noctua NH-U12P SE2 | Hyper X 32GB | ASUS Strix GeForce GTX 960 | Samsung 840 EVO 120GB

Redigera
Citera flera Citera
Permalänk
Medlem
●

Tanken med dag är att det är ett försäljningstillfälle, alltså tänk dig att dagen är en Faktura och där försäljningsraden är raderna på fakturan, förstår du vad jag menar?
Angående lager så är det såhär att man beställer in säg 1000 datorer till dag1, sen under dag1 så säljer jag 400 datorer. Då har jag 600 kvar som skall ligga i Lager med Dag1 som ID... Har jag tänkt dumt?

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Känns som en väldigt annorlunda modell iaf. Skulle inte använda dag som huvudtabell. Skulle nog inte haft det som en tabell över huvud taget. Dag borde vara en kolumn "inköpsdatum" i en tabell "inköpsorder". Huvudtabell borde instinktivt vara Lager.

Sedan skulle jag använda engelska namn så lager skulle heta Stock eller Warehouse.

Har inget modelleringsprogram här just nu tyvärr. En bild säger mer än tusen ord säger man ju... men men.

Visa signatur

He who hasn't hacked assembly language as a youth has no heart. He who does so as an adult has no brain.
~John Moore

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Anaii:

Känns som en väldigt annorlunda modell iaf. Skulle inte använda dag som huvudtabell. Skulle nog inte haft det som en tabell över huvud taget. Dag borde vara en kolumn "inköpsdatum" i en tabell "inköpsorder". Huvudtabell borde instinktivt vara Lager.

Sedan skulle jag använda engelska namn så lager skulle heta Stock eller Warehouse.

Har inget modelleringsprogram här just nu tyvärr. En bild säger mer än tusen ord säger man ju... men men.

Gå till inlägget

Jag har full förståelse för om du tycker den är märklig. Har designat om det lite så nu ser den ut såhär.
Lagerstatus flyttades in direkt under Article, vet inte vad jag tänkte innan...

Tanken med att ha Day som huvudtabell är för att det är ett försäljningstillfälle.
Tror att det blir lite klarare med vad jag menar när du får se alla kolumner etc i diagrammet ovan.
Några tankar på detta?

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Det är definitivt en unik lösning Jag jobbar just med ordersystem och jag har aldrig sett din lösning förut. Säger inte att den är fel eller inte kommer funka men den är annorlunda.

En mer normal design brukar vara (ska försöka utan ritprogram):

Tabeller:
OrderHead (försäjning till kund, innehåller referens till kund, ordernr, datum info etc)

OrderRow (flera kan tillhöra samma head. pekar på produkter samt sparar prisinformation etc. Dvs information som kan förändras på produkten. Kunden vill ju få priset som var när orden lades. )

Customer (kund info)

Article (produktinfo. Kan innehålla priser men oftast ligger priser i en separat tabell pga att man ofta har flera prissättningar till samma produkt beroende på kundgrupp eller erbjudanden etc. Kan innehålla lagersaldo men det kan också vara en egen tabell)

Supplier (leverantör av produkterna. Var man beställer ifrån etc.)

PurchaseOrderHead (inköp från leverantör)

PurchaseOrderRow (tillhör en Head. artiklar, priser, datum etc)

Så skulle jag nog göra det du ritat upp.

Visa signatur

He who hasn't hacked assembly language as a youth has no heart. He who does so as an adult has no brain.
~John Moore

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Anaii:

Det är definitivt en unik lösning Jag jobbar just med ordersystem och jag har aldrig sett din lösning förut. Säger inte att den är fel eller inte kommer funka men den är annorlunda.

En mer normal design brukar vara (ska försöka utan ritprogram):

Tabeller:
OrderHead (försäjning till kund, innehåller referens till kund, ordernr, datum info etc)

OrderRow (flera kan tillhöra samma head. pekar på produkter samt sparar prisinformation etc. Dvs information som kan förändras på produkten. Kunden vill ju få priset som var när orden lades. )

Customer (kund info)

Article (produktinfo. Kan innehålla priser men oftast ligger priser i en separat tabell pga att man ofta har flera prissättningar till samma produkt beroende på kundgrupp eller erbjudanden etc. Kan innehålla lagersaldo men det kan också vara en egen tabell)

Supplier (leverantör av produkterna. Var man beställer ifrån etc.)

PurchaseOrderHead (inköp från leverantör)

PurchaseOrderRow (tillhör en Head. artiklar, priser, datum etc)

Så skulle jag nog göra det du ritat upp.

Gå till inlägget

Anledningen till att det ser ut som det gör, är att det kommer bara finnas en Kund, och det är jag själv, så en kundtabell är onödig för mig att ha.
Beställningar kommer bara att ske ifrån ett ställe, så det känns onödigt att ha en tabell med Suppliers?
Så om man kopplar bort Supplier och Customer från det du skrev, så är det väl ändå ganska likt ;)?

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Det känns definitivt som om Day åtminstone har fel namn med fält som Town och Money. Det känns som SaleRow borde ha type Double på Price. Sum känns också småskumt: Om fältet representerar [Number(Amount?) * Price] borde det räknas ut istället för att ligga statiskt.

Visa signatur

Kom-pa-TI-bilitet

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Teknocide:

Det känns definitivt som om Day åtminstone har fel namn med fält som Town och Money. Det känns som SaleRow borde ha type Double på Price. Sum känns också småskumt: Om fältet representerar [Number(Amount?) * Price] borde det räknas ut istället för att ligga statiskt.

Gå till inlägget

En Day kan vara på 3 olika ställen, alltså 3 olika städer. Money ska vara den totala försäljningen på en dag.
Number byter genast namn till Amount. Sum räknas ut automatiskt Number*Price, Alltså Amount*Price...

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Fält som Money och Sum sparas normal inte. Inget av det du sparar i day sparas normal. Det är nämligen dubbellagrad information. Det räknas ut vid behov genom att summera order rader lagda ett visst datum. Sum samma sak. Det räknas ut vid tillfället informationen ska användas precis som Teknocide föreslog.

Visa signatur

He who hasn't hacked assembly language as a youth has no heart. He who does so as an adult has no brain.
~John Moore

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Anaii:

Fält som Money och Sum sparas normal inte. Inget av det du sparar i day sparas normal. Det är nämligen dubbellagrad information. Det räknas ut vid behov genom att summera order rader lagda ett visst datum. Sum samma sak. Det räknas ut vid tillfället informationen ska användas precis som Teknocide föreslog.

Gå till inlägget

Okey. Då åtgärdar jag det, då har jag lärt mig något, tack så mycket för hjälpen :). Jag skall använda mig utav ASP.NET så när jag till exempel skall visa total försäljning för en dag så summerar jag alla raderna direkt i ASP med andra ord?
Angående Day, jag kommer ha kvar Date,Town och WeekDay då jag vill kunna visa typ all försäljning på tex Måndagar, eller all försäljning i till exempel Stockholm, eller ett visst datum. Kan man lösa det på något annat sätt som är bättre?

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Antagligen skulle jag spara den informationen på varje försäljningsrad. När du vill veta hur mycket som sålt på måndagar is Stockholm: summera amount * price av alla försäljningsrader som har weekday = monday och city = Stockholm

Men om du definitivt vill ha kvar detta i en egen tabell så borde du döpa om den till något mer intuitivt. SaleDate möjligvis.

Visa signatur

He who hasn't hacked assembly language as a youth has no heart. He who does so as an adult has no brain.
~John Moore

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Anaii:

Antagligen skulle jag spara den informationen på varje försäljningsrad. När du vill veta hur mycket som sålt på måndagar is Stockholm: summera amount * price av alla försäljningsrader som har weekday = monday och city = Stockholm

Men om du definitivt vill ha kvar detta i en egen tabell så borde du döpa om den till något mer intuitivt. SaleDate möjligvis.

Gå till inlägget

Du låter extremt vettig, jag gör som du säger rakt av Nu när du har förklarat lite för mig så har det klarnat en hel del. Stort tack för hjälpen

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av joss:

Jag har full förståelse för om du tycker den är märklig. Har designat om det lite så nu ser den ut såhär.
Lagerstatus flyttades in direkt under Article, vet inte vad jag tänkte innan...
https://img.skitch.com/20120412-t2c72au7ijq82pj7f1qei46yb1.jp...

Tanken med att ha Day som huvudtabell är för att det är ett försäljningstillfälle.
Tror att det blir lite klarare med vad jag menar när du får se alla kolumner etc i diagrammet ovan.
Några tankar på detta?

Gå till inlägget

Vad är det för program du har använd för att skapa diagrammet?

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Murloc:

Vad är det för program du har använd för att skapa diagrammet?

Gå till inlägget

Diagrammet är skapat i Microsoft SQL Server Management.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Murloc:

Vad är det för program du har använd för att skapa diagrammet?

Gå till inlägget

Jag undrade samma sak.
Kollade runt lite och hittade ett liknande verktyg vid namn Power*Architect som finns i community edition.

Java-baserat, verkar helt ok! Ladda ner härifrån: http://www.sqlpower.ca/page/architect_download_os

Visa signatur

Kom-pa-TI-bilitet

Redigera
Citera flera Citera
Permalänk
Medlem
●

Ser konstigt ut med salesrow och orderrow. Kommer alla salesrow ha en egen orderrow eller är detta något som är helt skiljt från varandra?

Visa signatur

Projekt:Dual Comp

Ubuntu One?

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av chila:

Ser konstigt ut med salesrow och orderrow. Kommer alla salesrow ha en egen orderrow eller är detta något som är helt skiljt från varandra?

Gå till inlägget

Jag förstod det som att det ena är inköpsorder, den andra säljorder.

Visa signatur

He who hasn't hacked assembly language as a youth has no heart. He who does so as an adult has no brain.
~John Moore

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Teknocide:

Det känns definitivt som om Day åtminstone har fel namn med fält som Town och Money. Det känns som SaleRow borde ha type Double på Price. Sum känns också småskumt: Om fältet representerar [Number(Amount?) * Price] borde det räknas ut istället för att ligga statiskt.

Gå till inlägget

Jag har sett många system som har det sparat som en sorts "cache".

Visa signatur

Asus Striker II Extreme / XFX Geforce GTX 280 / Q9450 @ 3.6GHz/ TRUE Noctua 120/ 4x1GB Corsair TWIN3X2048-1333C9DHX / X25-M G2 80gb Velociraptor / Win 7 Ultimate x64/ Antec P190

MovieDatabase

Redigera
Citera flera Citera
1
Skriv svar
Senaste nyheterna
Hårdvara
Mjukvara
Övrigt
Nytt i forumet
Datorkomponenter
System
Ljud, bild och kommunikation
Spel och mjukvara