Newsgroup: it.comp.software.database
Titolo: problema di design

Ciao,
all'interno di un gestionale devo tenere traccia della movimentazione
di apparecchiature. Questi macchinari possono trovarsi, in tempi
diversi, presso un magazzino, un tecnico, un fornitore o un cliente.
Ovviamente in un dato momento non possono trovarsi assegnati a più
entità. Come gestireste queste informazioni? Il modo che ho adottato,
ma che non mi piace molto, è di avere una tabella Movimentazione di
questo tipo:
MovimentoMacchinario
- data
- id_macchinario -> Macchinario.id
- id_magazzino -> Magazzino.id
- id_tecnico -> Tecnico.id
- id_fornitore -> Fornitore.id
- id_cliente -> Cliente.id
Secondo voi quale sarebbe il metodo migliore?

 Secondo voi quale sarebbe il metodo migliore?
Dato il requisito di tenere traccia dei macchinari e del trovarsi
in tempi non contemporanei in vari posti, credo che non si
riuscira` a scappare dall'avere tabelle temporali.
Ossia aggiungere i campi "Dal", "Al", e soprattutto i relativi
vincoli, ad ogni tabella rilevante (parecchio oneroso).
Altre soluzioni intermedie non credo che abbiano i requisiti che
chiedi.
Questo e` un caso in cui la limitatezza degli attuali dbms,
unita all'attrattiva di una soluzione di compromesso, rendono
il classico "strappo alla regola" conveniente e quantomai
tentatore... 


Gia' solo col  "DAL" dovrebbe bastare
Per vedere dov'e' in questo momento bastera' selezionare il record con l'id 
macchinario desiderato ed il DAL piu' recente
Ciao
RobertoA

 record con l'id macchinario desiderato ed il DAL piu' recente
Pero' cosi' il dbms non potrebbe piu` rilevare gli errori
dovuti agli intervalli sovrapposti, ossia quando il pezzo
risulterebbe in due posti contemporaneamente. 

 risulterebbe in due posti contemporaneamente.
Il controllo degli intervalli sovrapposti credo sia da risolvere a
monte, non capisco come lo si potrebbe far fare al dbms. Però ci
sarebbe il grosso problema che trovare un errore di inserimento
sarebbe difficile. Se mi trovassi tre record:
Dal 1/1/09 Al 1/2/09 magazzino1
Dal 2/2/09 Al 1/3/09 magazzino2
Dal 15/2/09 Al=null cliente1 (valore Dal sbagliato, dovrebbe essere
2/3/09)
potrei capire immediatamente che c'è qualcosa che non va.
Diversamente, se mi affidassi al solo campo Dal avrei tre record
Dal 1/1/09 magazzino1
Dal 2/2/09 magazzino2
Dal 15/2/09 cliente1
senza che possa accorgermi della presenza di un errore.
Altro problema di avere il solo campo "Dal" credo sia diventare
dipendenti dall'ordine dei record (che dovrebbe essere vietato da una
delle regole di normalizzazione). Per sapere se il record che sto
controllando è quello attuale dovrei verificare se è l'ultimo, mentre
con i campi Dal-Al basterebbe controllare se il campo Al è null.
Inoltre calcolare qualunque cosa che abbia a che fare con l'intervallo
di tempo richiederebbe query complesse e tempi di elaborazione lunghi.
Grazie per la risposta, mi metterò il cuore in pace e chiuderò gli
occhi di fronte ad una soluzione che non mi piace ma che non ha
alternative migliori.
L'unico modo per impedire l'inserimento di dati errati (date
sovrapposte o riferimenti a più di un'entità di destinazione) temo sia
usare un trigger. Ad esempio per impedire l'inserimento di un record
di questo tipo:
MovimentoMacchinario
- dataDal=1/1/09
- dataAl=null
- id_macchinario=8992
- id_magazzino=9823
- id_tecnico=null
- id_fornitore=null
- id_cliente=1823
Se fosse possibile non saprei più se il macchinario è presso un
magazzino o un cliente.
Ciao
Mattia

 a monte, non capisco come lo si potrebbe far fare al dbms.
Tramite (purtroppo complessi) trigger.
Il libro sui time db aveva anche degli esempi se non ricordo male. 

 Il libro sui time db aveva anche degli esempi se non ricordo male.
Uhm... immaginavo, ma non mi piace molto usare i trigger, soprattutto
per calcoli complessi.
Tra l'altro la cosa si complica ulteriormente, perché oltre a dover
tracciare gli spostamenti dei macchinari devo anche tenere conto dello
stato degli stessi (disponibile, in uso, guasto, in riparazione,
cessato). Solitamente lo spostamento del macchinario comporta anche il
cambio di stato, però non è una regola.
Io farei in questo modo:
PosizioneMacchinario
- id
- dataMovimento
- dataFineValidita
- id_macchinario -> Macchinario.id
- id_magazzino -> Magazzino.id
- id_tecnico -> Tecnico.id
- id_fornitore -> Fornitore.id
- id_cliente -> Cliente.id
StatoMacchinario
- id
- dataInizio
- dataFine
- stato
- movimento_id -> PosizioneMacchinario
StatoMacchinario potrebbe essere slegato da  PosizioneMacchinario,
però in questo modo potrei effettuare datamining abbastanza
facilmente. Ad esempio potrei contare quanti cambi di stato vengono
effettuati in una stessa posizione o calcolare il tempo che è rimasto
in uno stesso stato nello stesso posto (ad esempio per sapere in media
quanto un macchinario rimane guasto presso il cliente). Senza un
legame con PosizioneMacchinario dovrei fare calcoli complessi per
determinare la posizione corrispondente in quella data, probabilmente
senza poter sfruttare a dovere gli indici e con performance indecenti.
Secondo te va bene così, o hai qualche suggerimento? Per me è un
argomento abbastanza nuovo... Mi sono appena scaricato un libro in pdf
da Wikipedia inglese che parla di time db... 500 pagine.. mi ci vorrà
un po' prima di finirlo.
Grazie.
Mattia

 - movimento_id -> PosizioneMacchinario
Mi correggo da solo... ci vuole una tabella in mezzo.
PosizioneMacchinario -> PosizioneStatoMacchinario <- StatoMacchinario
Ciao
Mattia

> [...]
Questo problema da modellare e` un po' particolare perche'
e` l'incontro di due cose che i dbms non supportano, ossia una
distributed foreign key, e le tabelle temporali.
Farsi a mano queste due cose sara` notevolmente problematico.
La soluzione di compromesso che descrivi non andrebbe bene
perche` usa i null.
Pero` purtroppo questa e le altre soluzioni fatte a mano
sarebbero comunque sub-optimali ed insoddisfacenti.
E` un po' come George Clooney nei panni del capitano ne
"La tempesta perfetta", quando in cabina ormai con l'acqua
alla gola il marinaio gli chiede "...e adesso?".
"Rimane solo una cosa, ma quella non te la insegnano". 

 sarebbero comunque sub-optimali ed insoddisfacenti.
uhm... puoi farmi qualche esempio o darmi qualche link o anche solo
qualche chiave di ricerca interessante? Conta che non solo ho poca
esperienza ma anche non conosco i termini tecnici. Menzionato "time-
oriented db" e "distributed foreign key" mi hai permesso di fare
ricerche mirate su questi problemi. Prima non sapevo nemmeno cosa
cercare.
Ciao
Mattia

 qualche chiave di ricerca interessante?
Nel ns. newsgroup qualche settimana fa:
http://groups.google.it/group/it.comp.software.database/browse_thread/thread/ed5620a22a44fd2b
Gli argomenti in ballo sono:
- distributed (foreign) key
- specializzazione obbligatoria
- set mutualmente esclusivi
- temporal table
Queste sono le cose di cui avremmo bisogno nei dbms, non le altre
menate che ci propongono continuamente... adesso sono tornati
a dire che i db relazionali sono morenti, di nuovo...
http://www.programmazione.it/index.php?entity=eitem&idItem=41482
A farli fuori sara` il "cloud computing", buzzword inventata dai
markettari per rivenderti roba di 40 anni fa. 

 - temporal table
Wow... un bel po' di roba... Che già prese da sole sono un bel
grattacapo. Ho capito che non sarà tanto facile... Credo che seguirò
il tuo consiglio di fare la cosa che mi darà meno lavoro...
Grazie mille.
Mattia