Newsgroup: it.comp.software.database
Titolo: Quantità e unità di misura

Salve!
Mi sto ponendo il seguente problema:
Partendo dalle regole di normalizzazione dei database (le applicazioni di
prima, seconda e terza forma normale hanno, tra gli altri, lo scopo di 
eliminare le
dipendenze funzionali tra attributi non chiave), sto pensando alla struttura
migliore da dare al mio database dove devo registrare codici articoli, unit�
di misura e quantit�.
Una struttura, che penso sia comune alla maggior parte degli ERP, � quella 
di
creare una prima tabella di anagrafica dei codici articoli (CodArticolo,
DesArticolo, Unit�Misura, ecc...) e una tabella delle giacenze a magazzino
(CodArticolo, Quantit�).
In questo modo per� ho una dipendenza funzionale, che � quella tra l'unit� 
di
misura presente nell'anagrafica articoli e la quantit� presente nelle
giacenze di magazzino. Se cambia l'unit� di misura deve necessariamente
essere riconvertit� la quantit� delle giacenze.
Come si pu� strutturare correttamente il database in modo da non avere pi�
questa dipendenza funzionale?
Ciao
Cricca

 questa dipendenza funzionale?
Devi fare in modo che le grandezze salvate sul DB siano indipendenti
dall'unita'
di misura in cui sono state inserite: in pratica devi convertire prima
di
inserire nel DB ogni grandezza in modo che sul DB sia tutto nella
stessa
unita' di misura.
Ad esempio: se decidi che l'unita' di misura e' il metro, tu comunque
memorizzi
dati in metri, mentre nel prodotto memorizzi in che unita' di misura
l'utente
aveva inserito il dato (e quindi in che unita' va riconvertito quando
lo
vuoi visualizzare). In questo modo se cambi unita' di misura non devi
cambiare le grandezze gia' inserite,quello che cambia e' la
conversione
quando inserisci/visualizzi i dati.
Piu' in dettaglio: se l'utente ha inserito 35cm tu nel DB scrivi cm /
0.35
(convertendo da 35 cm a 0.35 m).
Se l'utente decide di visualizzare in mm, il tuo 0,35 resta uguale (in
metri
era e in metri rimane!) e basta cambiare l'unita' di misura sul
prodotto
Naturalmente devi decidere una unita' di base per ogni grandezza che
ti serve:
area, peso, lunghezza, quantita, eccetera. Per chiudere il giro ti
serve
una nuova entita' che distingue se le unita' di misura sono relative
a are, peso, eccetera.
GRANDEZZE (area, peso, lunghezza, quantita, ...)
codice
UNITA_DI_MISURA
simbolo
codice_grandezza --> GRANDEZZE.codice
PRODOTTI
codice
simbolo_um --> UNITA_DI_MISURA.simbolo
GIACENZE
codice_prodotto --> PRODOTTI.codice
grandezza: float/double/...
ciao
Giacomo

 unita' di misura.
Naturalmente tutte le grandezze omogenee (tutti i pesi, tutte le
lunghezze,
eccetera) devono essere inserite nel DB nella stessa unita' di misura
"di base".

qui aggiungi un fattore_conversione che ti consente di convertire
dalle
unita' inserite dall'utente alle unita' di base e viceversa.


 non avere pi� questa dipendenza funzionale?
Il problema si risolverebbe se il dbms supportasse un vero sistema
di tipizzazione degli attributi, e non i soliti INT, STRING etc
che invece sono tipi di immagazzinamento dell'hardware ma non dello
schema logico.
Il workaround consiste come al solito nel fare a mano le
conversioni che il motore del dbms dovrebbe fare in automatico... 

 questa dipendenza funzionale?
Humm sicuramente memorizzare le quantit� in unit� base risolve in parte
il problema, tieni presente che le cose non sono poi cos� banali in
generale e mi spiego: dire che ho a magazzino 100 metri di cavo e dire
che ho 100000 mm di cavo non � la stessa cosa.
Nel primo caso si intende che ne ho una quantit� compresa fra 99,5 m e
100,5 m mentre nel secondo significa che sono sicuro a meno di 0,5 mm
per cui andrebbe indicata anche la tolleranza in teoria.

 per cui andrebbe indicata anche la tolleranza in teoria.
Ma non ï¿œ solo questo:
Prendi il caso di un prodotto Arance.
Pur essendo un prodotto legato al peso,
nulla vieta di indicarlo a colli:
In questo caso non ï¿œ univoca la conversione Colli kg, ad esempio.
Come ci si muove in questi casi ?

 
Nei sistemi che conosco l'unitï¿œ di misura ï¿œ funzionalmente dipendente 
dalla referenza di magazzino. Se vendo le arance al chilo, allora tutti 
i movimenti di magazzino devono essere al chilo. Se le vendo in 
cassette, allora creo un altro codice di magazzino che spesso avrï¿œ 
anche differenti regole di business dal parente gestito in chili(ad 
esempio la logistica, gli sfridi e le politiche commerciali).
Nei supermercati, giusto per centrare l'esempio, ï¿œ sempre cosï¿œ.
Ovviamente si dovranno prevedere strumenti di trasformazione tra arance 
sfuse in chili e cassette, che potrebbero venire ricavati dalla gestione 
della produzione essendo figlie della logia della distinta base.

 della produzione essendo figlie della logia della distinta base.
Io di norma uso un sistema del genere.
Anche perch� si separa la gestione delle esistenze fra arance e scatole.
Quindi facendo statistiche posso avere che non ho pi� scatole pronte da
spedire ma ho totkg di arance a magazzino da "inscatolare".
Mentre un negozio gestir� solo le scatole, un'azienda prodruttrice gestir�
materia prima e prodotto finito.
Stessa cosa per le bobine di filo. A magazzino ho 5km di filo, ma ho 10
bobine da 100mt, 5 bobine da 500mt ecc.