Newsgroup: it.comp.software.database
Titolo: Problema di progettazione

Salve!
Volevo condividere con qualcuno di voi questo problema di progettazione 
database.
Ho una tabella (facciamo ad esempio una tabella "Articoli").
In questa tabella "Articoli" c'è un campo (non chiave) "Tipologia" (ad 
esempio "ArticoliDiAcquisto" e "ArticoliDiVendita").
Poi nel database ci sono altre tabelle che hanno foreign-key della tabella 
"Articoli" (ad esempio "OrdiniAcquisto" e OrdiniVendita").
Io vorrei progettare il database facendo in modo il campo "Articolo" della 
tabella "OrdiniDiAcquisto" si possa riempire solo con articoli di tipologia 
"ArticoliDiAcquisto" e il campo "Articolo" della tabella "OrdiniDiVendita" 
si possa riepire solo con articoli di tipologia "ArticoliDiVendita".
Per questo tipo di problematica vorrei trovare una soluzione che rispetti le 
definizioni di prima, seconda e terza forma normale di una database.
Sapreste aiutarmi a trovare una soluzione corretta?
Grazie
Ciao
Cricca


Prima dovresti chiarire le dopmande precedenti.



Abbi pazienza. Forse ho dato troppe informazioni per scontate.
Comunque riassumo. Le tabelle che ho sono tre "Articoli", "OrdiniAcquisto", 
"OrdiniVendita"
La chiave primaria di "Articoli" è CodiceArticolo.
Sia in "OrdiniAcquisto" che "OrdiniVendita" c'è un campo CodiceArticolo che 
è ForeignKey della tabella Articoli.
Io voglio fare in modo che in "OrdiniAcquisto" nel campo CodiceArticolo ci 
si possano scrivere articoli con Tipologia "Acquisto" e in "OrdiniVendita" 
ci si possano scrivere solo articoli con Tipologia "Vendita".
La struttura che ho qui sopra indicato non mi sembra che si possa 
considerare messa in terza forma normale.
Secondo te come si dovrebbe modificare la struttura del db per portarlo in 
terza forma normale?
Ciao
Cricca 

 
due tabelle 'cuscinetto' articoliVendita e articoliAcquisto che contengono 
solo l'idarticolo preso dalla tabella 'articoli'.
ognuna delle tabelle ordini e' collegata al rispettivo 'cuscinetto'.
non e' una grande idea e secondo me quello che vuoi ottenere va fatto in 
interfaccia, ma dovresti ottenere il risultato voluto.
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--


Ci avevo pensato, ma la soluzione non mi piace perchè in questo modo posso 
avere lo stesso codice sia nella tabella cuscinetto "ArticoliVendita", sia 
nella tabella cuscinetto "ArticoliAcquisto" che invece è un caso che voglio 
evitare.
Ciao
Cricca 

 wrote in news:hutjhh$939$
1...@tdi.cu.mi.it
:

non so di che articoli stiamo parlando, ma mi sembra esoterica la 
situazione in cui un articolo acquistato non verra' mai venduto e un 
articolo che vendi non puo' essere acquistato...
perfino chi acquista materia prima e la trasforma occasionalmente la 
rivende (all'amico, al parente, a quel cliente da tenere buono) e 
occasionalmente acquista il prodotto finito per rivenderlo; se impedisci 
che venga gestita questa situazione questi casi particolari dovrebbero 
essere gestiti al di fuori del db (male) oppure inserendo il doppio 
articolo (peggio).
sicuro che sia un requisito essenziale?
io un vincolo del genere lo metterei in interfaccia, dando comunque 
all'utente la possibilita' di inserire eccezioni.


 all'utente la possibilita' di inserire eccezioni.
Voleva solo essere un esempio!
Di situazioni che si possono ricondurre a questa casistica ne potrei 
inventare di altri.
Ho semplicemente voluto proporre una situazione più o meno verosimile.
Non vorrei stare qui a valutare la veridicità del caso specifico, ma trovare 
una soluzione per questa casistica.
Ciao
Cricca 

 [...]
Ciao  Manlio

 Ciao  Manlio
Sono quasi d'accordo.
Pensandoci, ho trovato una soluzione che credo sia la migliore in assoluto, 
che consiste nella seguente struttura:
Articoli (Codice, Descrizione)
- PK(Codice)
ArticoliTipologia (Codice, Tipologia)
- PK(Codice, Tipologia)
- Tipologia può assumere i valori A=Acquisto; V=Vendita.
OrdiniAcquisto (NumeroOrdine, Codice, Tipologia)
- PK(NumeroOrdine)
- Tipologia può assumere solo il valore A=Acquisto
OrdiniVendita (NumeroOrdine, Codice, Tipologia)
- PK(NumeroOrdine)
- Tipologia può assumere solo il valore V=Vendita
Le relazioni sono
Articoli(Codice)-ArticoliTipologia(Codice) di tipo uno-a-uno
ArticoliTipologia(Codice, Tipologia)-OrdiniAcquisto(Codice, Tipologia) di 
tipo uno-a-molti
ArticoliTipologia(Codice, Tipologia)-OrdiniVendita(Codice, Tipologia) di 
tipo uno-a-molti
Grazie
Ciao
Cricca

 Articoli(Codice)-ArticoliTipologia(Codice) di tipo uno-a-uno
Volevi dire uno a molti...

> Volevi dire uno a molti...
No!
Intendo proprio uno-a-uno, perchč solo cosě riesco a garantirmi il fatto che 
nella tabella ArticoliTipologia un singolo codice articolo compaia una volta 
sola. 

 
ok portarsi avanti e prevenir le rogne, ma meglio cercare di risolvere 
casi probabili, piuttosto che puntare a quelli esoterici ^^


 
i campi 'tipologia' delle tabelle intermedie sono inutili, perche' il
valore contenuto nel campo dipende dalla tabella in cui la riga si
trova... 
ed eliminando il campo tipologia hai esattamente la soluzione che ho
proposto nell'altro post. 


 
come non detto...
ho letto male il tuo post e ho scritto una caxxata ^^


 
-- 


 e 'OrdiniAcquisto' contenga solo righe con 'acquisto'?
Come già spiegato nel post precedente, nella definizione del campo
Tipologia, a seconda della tabella in cui mi trovo, nel definire il range di
valori ammessi per il campo, indicherò:
in ArticoliTipologia
- Tipologia può assumere i valori A=Acquisto; V=Vendita.
in OrdiniAcquisto
- Tipologia può assumere solo il valore A=Acquisto
in OrdiniVendita
- Tipologia può assumere solo il valore V=Vendita
In questo modo in ArticoliTipologia il codice "Pippo" può esserci una volta
sola (per via della relazione uno-a-uno con la tabella Articoli) e può
essere o di tipo V (Vendita) o di tipo A (Acquisto).
Se "Pippo" è di tipo V può essere caricato solo nella tabella OrdiniVendita,
mentre se è di tipo A può essere caricato solo nella tabella OrdiniAcquisto.
Per rispondere a tuo dubbio nell'altro sottothread, ti riporto alcuni esempi
analoghi a quello qui indicato:
1) Il caso reale che mi è capitato a lavorare è il seguente: produciamo
piastrelle di ceramica di diversi formati. Abbiamo quindi un'anagrafica
formati e un'anagrafica articoli. Nell'anagrafica articoli ho un campo
"FormatoCommerciale" e un campo "FormatoStatistico" mentre nell'anagrafica
Formati ho un flag che mi dice se il formato è Statistico o Commerciale.
Ovviamente nel campo "FormatoCommerciale" vengono caricati solo formati con
il flag impostato su Commerciale e nel campo "FormatoStatistico" vengono
caricati solo formati con il flag impostato su Statistico. Questa soluzione
però non è un esempio di buona normalizzazione, perchè è sufficente
modificare il flag della tabella Formati e subito mi ritrovo in una
situazione incosistente.
2) Altri casi sono quelli in cui da un'anagrafica (ad esempio Persone) vuoi
derivare tabelle di maggiore dettaglio che a seconda di attributo di
tipologia (ad esempio Sesso) possono avere caratteristiche differenti. In
questo esempio potrei quindi fare le tabelle Maschi e Femmine che avranno i
loro campi specifici.
Potrei andare avanti, ma mi sembrano due casi già più che sufficienti. Io
non ho voluto riportare il caso che stavo affrontando nella realtà perchè
non mi sembrava che ce ne fosse la necessità. Ho posto un problema
"accademico" che facesse da Pattern e chiedevo la risposta al Pattern. Poi
starà in me prendere la soluzione del Pattern e adattarla al mio caso
specifico.
Comunque grazie per il costruttivo confronto.
Ciao
Cricca

 
spero che le mie domande non ti infastidiscano, perche' m'interessa 
capire lo scenario.
non avendo mai avuto a che fare con situazioni simili e non riuscendo a 
vedere i vantaggi della soluzione che proponi, m'interessano le 
spiegazioni ^^


 a-molti...
Riconosco di avere problemi nello spiegare il dettaglio del problema che ho 
posto.
Se hai un contatto Skype o Messenger e me lo mandi per e-mail, ci possiamo 
sentire in modo da risolvere i dubbi al riguardo.
Ciao
Cricca 

 Cricca
Ad ogni modo poi facci sapere se e come funge, dato che questa
e` una domanda che esce periodicamente.