Newsgroup: it.comp.software.database
Titolo: Relazione in base a caratteristiche comuni

Buongiorno a tutti, ho un piccolo problema ma grande per me poco
esperto. Forse è un mio errore di impostazione del DB, o non vedo la
relazione nell'ottica giusta o magari semplicemente mi sono perso in un
bicchier d'acqua ma....
ho un file fornitori, con una tabella "fornitori" che contiene i campi
anagrafici del fornitore come:
-ID fornitore (Chiave primaria)
-Nome
-pIva
-Indirizzo
Ogni fornitore ha una tipologia diversa: uno è albergo, l'altro
ristorante, ecc.
quindi ho creato delle tabelle "albergo", "ristorante", Ecc. che
contengono nei campi, oltre a una chiave primaria, le info essenziali e
specifiche per ciascuna tipologia. (tipo nella tabella albergo "N°
stanze" e "distanza dall'arepoprto")
Come le metto in relazione? le relaziono direttamente? Creo una tabella
di collegamento "tipologie" ?
Grazie davvero per qualsiesi aiuto!!! e a buon rendere...

 tabella di collegamento "tipologie" ?
Specifica se ti riferisci al vincolo di integrità referenziale, o al
(runtime) join.

 
No, devi creare una tabella TIPO dove ci metti
ID_Fornitore
ID_Categoria_Fornitore --> dalla tabella Categorie
poi aggiungi tutte le caratterische del *singolo* fornitore
es: stanze, distanza, numero tavoli, ecc. ecc.
Sicuramente avrai dei campi che andrai a riempire a seconda della 
categoria ed altri no, sta a te visualizzarli o meno.
Spero di essere stato abbastanza chiaro, altrimenti chiedi pure.
Alla prossima.
           MAX
p.s. la tabella TIPO, la chiami come vuoi tu io ho solo steso il concetto.

 (runtime) join.
Scusate davvero l'ignoranza ma qual'è la differenza?

 del tipo?
Io inserirei nella tabella "Fornitori" un campo "TipoFornitore", in
relazione uno-a-uno con una specifica tabella "FornitoreTipi".
La tabella "Fornitori" sarebbe poi relazionata, sempre con relazione
uno-a-uno, con le specifiche tabelle "Ristoranti", "Alberghi", ecc.
In questo modo ogni tabella ha i suoi attributi specifici e non devi
inserire  decine di valori null in un'unica tabellona dei fornitori, la
quale diventa solo un'aggregazione di tutti i tuoi soggetti...
HTH
-- 
David Martin

uno-a-uno, con le specifiche tabelle "Ristoranti", "Alberghi", ecc.
si questo era in realtà anche una delle possibilità che avevo
pensato. Perchè, ragionando in linea teorica in realtà dividere le
tipologie in sottotabelle non ha un esigenza per creare campi multipli
relazionati ma solo per avere i dati che in realtà starebbero su una
sola tabella divisi in più tipologie per creare un pò di "ordine".
Il mio problema allora è un pò più tecnico: come faccio a stabilire
una relazione uno a uno in automatico ( premetto che sono un pò fuori
dai linguaggi sql... io uso il programma Filemaker Pro 8.5 su winXp,
sorta di Access e che funziona come questo, un pò più avanzato...).
Una volta impostata la chiave primaria fornitori contatore come faccio
a dire alle altre chiavi di riprenderne il valore in base alla
tipologia?
Grazie a tutti
Filippo

 tipologia?
Non capisco cosa intendi per "stabilire una relazione uno a uno in
automatico". Il problema è nel momento in cui inserisci un nuovo
fornitore nella tabella fornitori e vuoi inserire i valori anche nelle
tabelle ad essa collegate? Oppure non sai come mettere in join le
tabelle quando devi fare delle query?
-- 
David Martin

 
In questo caso devi ulteriormente normalizzare il DB.
Alla luce dei dati che hai fornito, pero', mi sembra dura.
Cosi' come sono adesso, la soluzione sarebbe, ripeto sarebbe, una 
tabella Fornitori, relazionata alla tab_tipo_fornitore (ristorante, 
albergo ecc. ecc) con in piu' una tabella per ogni tipo_fornitore.
Es. Tab_ristoranti
ID_fornitore
num_tavoli
ecc. ecc.
Tab_Pizzerie
ID_fornitore
num_tavoli
ecc. ecc.
Tab_Alberghi
ID_fornitore
num_camere
ecc. ecc.
E' incasinato, perche' per ogni ricerca devi fare la scansione di tutte 
le tabelle, non sapendo se uno e'ristoratore e pizzeria o solo albergatore.
IMHO, ci vorrebbe uno studio del problema piu' approfondito.
Alla prossima.
	MAX

 Scusate davvero l'ignoranza ma qual'è la differenza?
Un join è un'operazione relazionale, fatta di volta in volta dal
tuo codice su due tabelle, per costruirne una terza; un vincolo
di integrità referenziale è un requisito permanente che inserisci
nel db, ed HA UN SIGNIFICATO semantico (non serve "per i join").
Nel tuo caso, significa che un albergo deve essere vostro
fornitore prima di essere censito nel db (esiste questa regola nel
tuo schema concettuale?).
I "flag", come anche i descrittori di "tipo" di riga, sono il tentativo
di iniettare metadata nello schema di un db; non servono in uno schema
ben strutturato.
Tornando al tuo esempio, la tabella Fornitori:
-ID fornitore (Chiave primaria)
-Nome
-pIva
-Indirizzo
vedo subito una candidate key, la partita iva; supponiamo di usarla,
visto che c'è già.
Devi solo riempire le altre tabelle usando la stessa chiave; il
tipo di fornitore sarà dichiarato semplicemente con la presenza o
meno della rispettiva riga nella tabella corrispondente, lasciando
possibile anche il fatto che, ad esempio, può essere sia albergo che
ristorante (cosa non possibile con una singola colonna "Tipo").
bye

 
Credo che il flag "tipo di fornitore" può essere ancora utile se, ad
esempio, voglio fare una query che mi conti quanti tipi di fornitori ci
sono per ogni tipo.
Altrimenti dovrei fare N query separate.
Saluti  Manlio Perillo

 Altrimenti dovrei fare N query separate.
Ma quelle query sarebbero sempre giuste; lo scopo di proibire dati
derivati è appunto la garantita correttezza degli stessi, liberi da
anomalie di aggiornamento (che succede se inserisco una riga in
Ristoranti e dimentico di aggiornare il flag? Che succede se aggiungo
una tabella Ostelli e non la includo nei controlli?); è la vecchia
e deprecata application-managed data integrity.
In ogni caso le N query le dovresti fare comunque, per il problema di
cui sopra, perché dovresti scrivere un trigger che mantenga
sincronizzato il flag (pena dati errati).


Si, hai ragione.
Tuttavia mi sembra di capire che è una cosa richiesta tanto che lo
standard SQL ha aggiunto il supporto per l'ereditarietà ;-).
Peccato che su PostgreSQL non funzioni a dovere (su Oracle come è
implementata?)
Saluti  Manlio Perillo

 standard SQL ha aggiunto il supporto per l'ereditarietà ;-).
L'ereditarietà è discorso complesso; in programmazione è soprattutto
(premesso che esista "un" modello ad oggetti) ereditarietà di
strutture, soprattuto derivazione per estensione.
Per i db si andrebbe a parlare di ereditarietà di tipi di dato
(anche complessi, non dobbiamo pensare a singoli valori), ed è
specializzazione per valori (intrisecamente a runtime, quindi).
SQL3 e compagnia varia mappano una riga su un oggetto e viceversa,
una colonna su un singolo valore dell'oggetto, il che non
è precisamente la stessa cosa, ma un'approssimazione dovuta
all'incompleto supporto dei tipi (che è un bel grattacapo, in
effetti).
bye

 ristorante (cosa non possibile con una singola colonna "Tipo").
...questo tipo di approccio è sicuramente più semplice e lineare, oltre
che più facile da gestire, rispetto all'utilizzo di un attributo che
identifichi il "tipo di fornitore".
...ed è probabilmente anche più sensato gestirlo così... la mia proposta
nasceva da alcuni presupposti:
- che un fornitore sia sempre e solo di un tipo;
- che ci sia un elenco di "tipi di fornitore" (magari con alcune
caratteristiche specifiche per ciascun "tipo", ad es. la descrizione);
- che si voglia mantenere integrità referenziale fra la tabella dei
"fornitori" e la tabella "tipi di fornitore";
..ciò non significa, comunque, che anche con questi presupposti non ci
fosse una soluzione migliore per gestire il tutto.
-- 
David Martin

 ristorante (cosa non possibile con una singola colonna "Tipo").
Il moi problema è allora: come faccio a dire al programma quale
fornitore è quale "tipo"? Devo ogni volta reinserire la partita iva (o
altra chiave primaria) nelle tabelle tipo? C'è un modo di farlo in
automatico?
Inoltre forse a questo punto non mi conviene piuttosto fare l'inverso,
cioè riempire tutte le tabelle di tipologia con anche i dati
anagrafici e poi farne confluire le chiavi primarie in un unica tabella
fornitori?
Grazie
Filippo

 fornitori?
A quale scopo??
Se inserisci i dati nella tabelle di tipologia, non ti interessa avere
anche una tabella fornitori (l'elenco completo di tutti i tuoi fornitori
lo puoi estrarre con una vista).
-- 
David Martin

David il mio problema è che uso Filemaker pro 8.5, programma tipo
Access, e purtroppo (anche se si possono programmare una serie di
script) questa operazione di "doppio inserimento" non credo la faccia...

 script) questa operazione di "doppio inserimento" non credo la faccia...
Sinceramente non ho mai usato FileMaker e ora non ho tempo per vedere di
cosa si tratta, ma se č come dici tu, allora siamo semplicemente
diventati OT... non si tratta piů di discutere sulla logica di come
strutturare la base dati, ma ovviare alle mancanze del software che usi...
A questo punto posso consigliarti di cambiare rdbms ;-)
-- 
David Martin