ricerca database
Alessandro M.
scusatemi se vi faccio una domanda forse banale ma non sono molto
pratico di teoria dei database. Devo costruire un database relazionale
del tipo padri e figli; mi spiego meglio: ho una tabella con degli
elementi identficati da un codice. Ognuno di questi elementi ￜ legato
agli altri elementi della tabella da una relazione padre-figlio, nel
senso che, fissato un elemento esso avrￜ un certo numero di elementi
della stessa tabella come padri (livello superiore) ed un numero di
elementi della stessa tabella come figli (livello inferiore). Ovviamente
io devo essere in grado di spostarmi all'interno di questo database, nel
senso che posso salire e scendere all'interno di esso a mio piacere.
Sapreste dirmi se con Access ￜ possibile realizzare questo tipo di
database o altrimenti con quale tipo di software sia possibile senza
prima laurearsi in informatica?
Grazie mille a tutti in anticipo per l'aiuto e la pazienza.
Alessandro
Leonardo
news:4b0af1d3$0$34599$4faf...@reader1.news.tin.it...
> Salve a tutti
> scusatemi se vi faccio una domanda forse banale ma non sono molto pratico
> di teoria dei database. Devo costruire un database relazionale del tipo
> padri e figli; mi spiego meglio: ho una tabella con degli elementi
> stessa tabella come figli (livello inferiore). Ovviamente io devo essere
> in grado di spostarmi all'interno di questo database, nel senso che posso
> salire e scendere all'interno di esso a mio piacere. Sapreste dirmi se con
> Grazie mille a tutti in anticipo per l'aiuto e la pazienza.
> Alessandro
Secondo me si.
Devi fare 3 tabelle
A) Padri
B) Figli
in relazione molti a molti tramite la tabella
C) RelazioneMM
Le chiavi delle 3 tabelle potrebbero essere:
Padri = IDPadri + gli altri campi della tabella
Fogli = IDFigli + gli altri campi della tabella
RelazioneMM = IDRelazioneMM, IDPadri, IDFigli (3 campi)
Tramite la tabella RelazioneMM potrai "spostarti" all'interno del database.
Ciao
Leonardo
Andrea D'Amore
"Leonardo" <leo...@libero.it> wrote:
> Devi fare 3 tabelle
Perché tre e non due, cioè una tabella con codice e nome elemento ed
un'altra con la relazione PadreFiglio?
Leonardo
"Andrea D'Amore" <and.da...@LOSPAM.gmail.com.invalid> ha scritto nel
messaggio news:and.damoreVIA-EED...@nntp.aioe.org...
> In article <73EOm.98712$9f6.1...@twister1.libero.it>,
> "Leonardo" <leo...@libero.it> wrote:
>
>> Devi fare 3 tabelle
>
> un'altra con la relazione PadreFiglio?
>
modo per mettere padri e figli in relazione.
Prendi un esempio analogo, Scrittori e Libri.
Abbiamo 2 tabelle Scrittori e Libri.
Uno scrittore pu� scrivere molti libri e sarebbe una relazione 1 a Molti fra
scrittore e libri.
Ma un libro pu� essere scritto da pi� scrittori ed avremo una relazione 1 a
Molti fra libri e scrittori.
Va da se che le stesso scrittore pu� avere dei libri scritti da solo ed
altri scritti insieme ad altri scrittori appartenenti alla tabella
Scrittori.
Quindi il rapporto � Molti a Molti.
Il modo per metterli in relazione fra loro � la tabella
RelazioneMM = IDRelazioneMM, IDPadri, IDFigli (3 campi) [IDAutori ,
IDLIbri]
IDPadri � legato allo IDPadri (principale) della tabella padri
IDFigli � legato allo IDFigli (principale) della tabella figli.
Ciao
Leonardo
Paolo opg
news:GLQOm.97944$1s6....@twister2.libero.it:
>
> "Andrea D'Amore" <and.da...@LOSPAM.gmail.com.invalid> ha scritto
> nel messaggio
> news:and.damoreVIA-EED...@nntp.aioe.org...
>> In article <73EOm.98712$9f6.1...@twister1.libero.it>,
>> "Leonardo" <leo...@libero.it> wrote:
>>
>>> Devi fare 3 tabelle
>>
>> Perch� tre e non due, cio� una tabella con codice e nome elemento ed
>> un'altra con la relazione PadreFiglio?
>>
> Perch� se un figlio ha molti padri ed un padre ha moli figli questo �
> il modo per mettere padri e figli in relazione.
[cut]
occhio che l'op parla di relazioni molti a molti tra elementi simili, tutti
inseriti nella stessa tabella.
con una sola tabella di 'esseri umani', la relazione padri - figli puo'
essere gestita con due sole tabelle
--
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--
Andrea D'Amore
Paolo opg <spamc...@tiscali.it> wrote:
> occhio che l'op parla di relazioni molti a molti tra elementi simili, tutti
> inseriti nella stessa tabella.
Esatto, non sono due entità distinte, c'è una sola entità che ha una
relazione M-M su sé stessa.
Leonardo
"Andrea D'Amore" <and.da...@LOSPAM.gmail.com.invalid> ha scritto nel
> In article <Xns9CCDA7D543D35sp...@193.43.96.1>,
> Paolo opg <spamc...@tiscali.it> wrote:
>
>> occhio che l'op parla di relazioni molti a molti tra elementi simili,
>> tutti
>> inseriti nella stessa tabella.
>
> relazione M-M su s� stessa.
>
Interessante, puoi farmi uno schema minimale?
Grazie
Leonardo
Andrea D'Amore
"Leonardo" <leo...@libero.it> wrote:
> Interessante, puoi farmi uno schema minimale?
PERSONA(id, nome)
PADRE_FIGLIO(id, id_padre, id_figlio)
dove id è chiave primaria nelle due tabelle e id_padre e id_figlio sono
foreign key su PERSONA(id).
Redwiz
> In article <3TTOm.98036$1s6....@twister2.libero.it>,
> "Leonardo" <leo...@libero.it> wrote:
>
>> Interessante, puoi farmi uno schema minimale?
>
> PERSONA(id, nome)
> PADRE_FIGLIO(id, id_padre, id_figlio)
>
> dove id � chiave primaria nelle due tabelle e id_padre e id_figlio sono
> foreign key su PERSONA(id).
mi � capitato di vedere la stessa struttura ra�ppresentata cos�:
persona(id,nome,id_padre)
funzionare funziona, non mi pronuncio sulla complessit�
cumputazionale,complessit� delle query, etc.
Andrea D'Amore
Redwiz <red...@inwind.it> wrote:
> mi è capitato di vedere la stessa struttura raèppresentata così:
>
> persona(id,nome,id_padre)
Ma c'è il vincolo che tutti partecipano alla relazione in qualità di
figlio?
The man with two watches
>
> "Andrea D'Amore"
>> "Leonardo"
>>
>>> Devi fare 3 tabelle
>>
>> Perch� tre e non due, cio� una tabella con codice e nome elemento ed
>> un'altra con la relazione PadreFiglio?
>>
> Perch� se un figlio ha molti padri ed un padre ha moli figli questo � il
> modo per mettere padri e figli in relazione.
Non ne vedo la necessita`, in quanto essendo una relazione tra due
attributi, sarebbe completamente esprimibile con una tabella tipo:
PadreFiglio {PadreID, FiglioID}
1, 10
1, 11
2, 12
3, 13
3, 10
L'esempio mostra come i padri hanno un numero variabile di figli,
ed il figlio "10" ha due padri. Questa tabella, da sola, e` gia`
"molti a molti", nel senso che dicevi tu, senza bisogno di
alcun'altra tabella.
> Prendi un esempio analogo, Scrittori e Libri.
> Abbiamo 2 tabelle Scrittori e Libri.
> Uno scrittore pu� scrivere molti libri e sarebbe una relazione
> 1 a Molti fra scrittore e libri.
> Ma un libro pu� essere scritto da pi� scrittori ed avremo una relazione 1
> a Molti fra libri e scrittori.
> Va da se che le stesso scrittore pu� avere dei libri scritti da solo ed
> altri scritti insieme ad altri scrittori appartenenti alla tabella
> Scrittori.
> Quindi il rapporto � Molti a Molti.
Attenzione che quando si parla relazioni "uno a", "molti a" etc...
nel campo dei database di solito si intende la cardinalita`
dell'integrita` referenziale tra righe di tabelle, non vorrei che
si facesse confusione con altri usi del termine (che pure esistono).
Questi due concetti sono spesso collegati, ma NON sono la stessa cosa.
Ad esempio quando si dice che "le relazioni M:M nel modello
relazionale sono implementabili con una terza tabella intermedia
di giunzione", in realta` s'intende parlare dell'integrita`
referenziale, non delle relazioni di per se' (che sono un'altra cosa).
Purtroppo i termini inglesi usati, "relation" e "relationship"
vengono tradotti entrambi con "relazione".
Nella parlata comune (ma anche in tanta letteratura), spesso i
due usi dei termini vengono scambiati; per averne una piccola
prova, vi propongo questo esperimento, per il quale e`
indispensabile la vs. collaborazione a mente aperta, oltre che una
lettura un passo alla volta del messaggio (non sbirciate avanti e
scrollate una riga alla volta).
L'esperimento, se avra` successo, gettera` nel panico chi
non ha chiaro il significato di relazione.
Attenzione, quando lo dico io [cit.] Dunque cominciamo:
Tutti sappiamo che la Partita IVA costituisce un'ottima chiave
primaria da usare nei database in quanto identifica in maniera
sicura UNA e SOLO una ditta.
Pensateci un momentino, non c'e` alcun trucco, l'esperimento
non si basa su sotterfugi ma e` un esercizio di design.
Ora immaginate di usare la P.IVA per una classica tabella di
anagrafiche, usando per l'appunto la P.IVA come chiave primaria,
in modo da avere UNA sola riga per ciascuna ditta.
Siete sicuri che una P.IVA apparira` al massimo UNA volta in
tabella? Convincetevene, vi voglio coinvolti.
Poi, mentre e` ovviamente possibile che una ditta abbia piu` sedi
lavorative, avra` UNA e SOLO UNA sede legale. Pertanto UNA P.IVA
avra` esattamente UNA sede legale, non e` possibile che ci siano
piu` sedi legali per una ditta, questo e` un requisito imposto
dalla legge.
Siete d'accordo che 1 ditta ha solo 1 sede legale?
Giurate, vi voglio compromessi. Non procedete oltre se non siete
convinti, altrimenti l'esperimento fallira`.
Attenzione momento cruciale: ora immaginate una semplice tabella
anagrafica, come tante ne avrete fatte, che descriva quanto
sopra detto:
AnagraficaDitte { P.IVA(pk), NomeDitta, SedeLegale }
Siete d'accordo che la tabella riportera` per ciascuna ditta
al minimo UNA, al massimo UNA, e quindi ESATTAMENTE UNA sede
legale? Siete sicuri?
Cosa succede se tento di inserire un'altra sede legale per una
P.IVA gia` presente? Secondo la vs.esperienza il dbms lo
impedira` con un messaggio di violazione di univocita`?
Siete convinti che un tale schema forza 1 P.IVA per esattamente
1 sede legale, e quindi 1:1? Giurate!
.
.
.
.
.
.
Bene, adesso guardate questi dati di esempio sempre per la stessa tabella:
Ditte { P.IVA(pk), NomeDitta, SedeLegale }
123, Rossi Sas, Corso Buenos Aires 100(MI)
456, Verdi Spa, Corso Buenos Aires 100(MI)
789, Bianchi Srl, Corso Buenos Aires 100(MI)
Ops, a UNO stesso indirizzo c'e` un palazzo con MOLTE ditte.
Siete ancora sicuri che il rapporto sia 1:1?
Quanti avrebbero messo un'altra PK anche su sede legale per
forzare il vincolo x:1? E quanti avrebbero usato due tabelle
una con P.IVA e l'altra SedeLegale ciascuna come PK credendo
che siano 1:1 nel senso sopra (sbagliando)?
Io l'ho visto fare varie volte, e tutte hanno come causa comune
il confondere relazione con integrita` referenziale.
Le relazioni sono strutture che valgono per tutti i suoi
termini *contemporaneamente*, senza cambiamenti se li scambio
di posto; non hanno "direzione".
I vincoli di integrita` referenziale invece sono piu' simili
a *funzioni*, ossia hanno direzionalita` e non possono essere
invertiti i termini; ossia da f(x)=y ma se inverto f(y)= non
riottengo la stessa x.
Pertanto quando dico che una ditta ha una sede legale ma una
sede legale ha molte ditte non sto parlando di relazioni in
questo dato senso, altrimenti scambiandoli di posto non dovrei
ottenere variazioni.
> Il modo per metterli in relazione fra loro � la tabella
> RelazioneMM = IDRelazioneMM, IDPadri, IDFigli (3 campi)
> IDPadri � legato allo IDPadri (principale) della tabella padri
> IDFigli � legato allo IDFigli (principale) della tabella figli.
IDRelazioneMM e` attributo estraneo alla chiave, in quanto
{IDPadri, IDFigli} e` sufficiente ad identificare la relazione
PadreFiglio. Inoltre e` dannoso nel senso che come altri usi
degli ID artificiali puo' permettere dati errati sottoforma di
duplicati, ad es:
RelazioneMM {IDRelazioneMM, IDPadri, IDFigli}
1, Abramo, Isacco
2, Abramo, Isacco
3, Abramo, Isacco
etc...
The man with two watches
> Sapreste dirmi se con Access � possibile realizzare questo tipo di
> database
Ciao Alessandro, si puo' fare con tutti i dbms, ma i problemi
principali di solito sono:
- manca il supporto da parte dell'engine ad ottimizzazioni ad hoc
- mancano nel linguaggio costrutti per alcune utili query comuni
(es. trovare tutti i progenitori di x, trovare il "percorso minimo"
tra x e y etc...)
La prima mancanza comportera` prestazioni scadenti, la seconda
ti obblighera` a scriverti a mano procedure ad hoc.
> o altrimenti con quale tipo di software sia possibile
Per MySQL c'e` un engine dedicato: http://www.openquery.com/graph/
The man with two watches
> Redwiz
>
>> mi � capitato di vedere la stessa struttura ra�ppresentata cos�:
>>
>> persona(id,nome,id_padre)
>
> Ma c'� il vincolo che tutti partecipano alla relazione in qualit� di
> figlio?
Non proprio... il requisito originale e` piu` complesso di
quello che e` stato detto sinora, e mi sembra che nessun altro
l'abbia notato ;-)
"Ognuno di questi elementi � legato agli altri elementi della
tabella da una relazione padre-figlio, nel senso che, fissato
un elemento esso avr� un certo numero di elementi della stessa
tabella come padri (livello superiore) ed un numero di
elementi della stessa tabella come figli (livello inferiore)"
Questo significa che dato un nodo X, ci saranno un certo numero
di padri nel livello X-1 ed un certo numero di figli nel livello
X+1; quindi non sara` piu` sufficiente una relazione padre-figlio
a due posti, ma a TRE posti, come segue:
PadreIoFiglio { MioPadre, Io, MioFiglio }
(Da notare che non e` una relazione "Nonno", per la quale
basterebbero due posti).
Per tornare alla tua domanda, il requisito e` che un elemento
"partecipi" alla relazione, ma non e` detto in che ruolo; diverso
sarebbe stato se avesse detto "dato un elemento QUALSIASI", il
che per� porterebbe ad una tabella infinita! (perche' ogni
elemento avrebbe un figlio nel livello X+1 che a sua volta
avrebbe un figlio nel livello X+2 etc...)
(da notare che senza il requisito dei livelli si potrebbe ancora
avere un numero finito di nodi).
Non so se l'op se ne era avveduto, ma questo va significativamente
a complicare la struttura... all'inizio gia` un albero non
poteva essere in quanto un figlio poteva avere piu` padri, ma
neppure un grafo, in quanto un arco non puo' essere destinato a
due nodi contemporaneamente, per cui dovrebbe trattarsi di un
ipergrafo(!) nel quale dal nodo "Io" parte un arco destinato
ad un numero variabile di Padri e Figli.
Notare inoltre come la relazione sia una struttura sufficiente
a descriverle tutte quante, e scusate se e` poco...
Andrea D'Amore
"The man with two watches" <do...@spam.me> wrote:
> fissato un elemento esso avrà un certo numero di elementi della
> stessa tabella come padri (livello superiore) ed un numero di
> elementi della stessa tabella come figli (livello inferiore)"
[…]
> X+1; quindi non sara` piu` sufficiente una relazione padre-figlio
> a due posti, ma a TRE posti, come segue:
> PadreIoFiglio { MioPadre, Io, MioFiglio }
Non mi sembra che la tabella a tre posti sia utile, anzi mi sembra sia
uno svantaggio.
Nella tabella a due colonne per indicare che un elemento X ha molti
figli ci sono semplicemente più righe in cui X compare nella prima
colonna e per indicare che ha molti padri semplicemente compare più
volta in seconda colonna.
Non mi sembra ci siano problemi così, mi sfugge qualcosa di quello che
hai scritto?
> che però porterebbe ad una tabella infinita! (perche' ogni
> elemento avrebbe un figlio nel livello X+1 che a sua volta
> avrebbe un figlio nel livello X+2 etc...)
Non mi sembra affatto che debba essere infinita, basta chiudere la
relazione sugli elementi già presenti.
> ma neppure un grafo, in quanto un arco non puo' essere destinato a
> due nodi contemporaneamente,
Però puoi disegnare più archi, uno per ogni destinazione.
The man with two watches
> "The man with two watches"
>
>> stessa tabella come padri (livello superiore) ed un numero di
>> elementi della stessa tabella come figli (livello inferiore)"
>> X+1; quindi non sara` piu` sufficiente una relazione padre-figlio
>> a due posti, ma a TRE posti, come segue:
>> PadreIoFiglio { MioPadre, Io, MioFiglio }
>
> Non mi sembra che la tabella a tre posti sia utile, anzi mi
> sembra sia uno svantaggio.
> Nella tabella a due colonne per indicare che un elemento X ha molti
> colonna e per indicare che ha molti padri semplicemente compare pi�
> volta in seconda colonna.
Non e` tanto da pensare se sia utile o svantaggiosa (ovviamente
una a 3 posti e` piu` complessa), piuttosto che SOLO con tre
posti si esprime la relazione che l'OP aveva scritto... a due
posti e` insufficiente, come spieghero` nel seguito.
> Non mi sembra ci siano problemi cos�, mi sfugge qualcosa di
> quello che hai scritto?
Credo di si: detta in breve, oltre a non essere la stessa
cosa, una relazione ternaria non e` scomponibile in due
relazioni a due posti senza PERDITA di informazioni.
>> che per� porterebbe ad una tabella infinita! (perche' ogni
>> elemento avrebbe un figlio nel livello X+1 che a sua volta
>> avrebbe un figlio nel livello X+2 etc...)
>
> Non mi sembra affatto che debba essere infinita, basta chiudere
> la relazione sugli elementi gi� presenti.
Non si puo': devo trovare sempre un figlio del livello X+1, non
posso chiudere su nessuno dei "progenitori" (livello X-Y); questo
e` un requisito imposto dall'OP.
>> ma neppure un grafo, in quanto un arco non puo' essere
>> destinato a due nodi contemporaneamente,
>
> Per� puoi disegnare pi� archi, uno per ogni destinazione.
Affermazione un po' ingenua... se fossero equivalenti, per
quale motivo i matematici avrebbero creato teorie differenti?
Credo che sia dunque necessario chiarire quanto segue:
una relazione ad N posti vale contemporanemente per tutti gli
attributi coinvolti; se la "rompo" in relazioni piu` piccole
vado a perdere certe informazioni.
Faccio l'esempio classico che spero risolva il problema della
decomposizione ed il problema degli archi multipli; pensatelo
come un simpatico quiz se volete.
Una certa materia viene insegnata da un certo docente e viene
seguita da un certo studente; non c'e` vincolo alle materie
e ai docenti frequentabili da uno studente.
Lezioni {Materia, Docente, Studente}
--------------------------------
Pittura, Michelangelo, Mario
Pittura, Davinci, Mario
Scultura, Michelangelo, Mario
Scultura, Davinci, Mario
La decomposizione su relazioni binarie sarebbe:
Competenze {Docente, Materia }
-----------------------------
Michelangelo, Pittura
Michelangelo, Scultura
Davinci, Pittura
Davinci, Scultura
Interessi {Materia, Studente}
-----------------------------
Pittura, Mario
Scultura, Mario
Docenze {Docente, Studente}
---------------------------
Michelangelo, Mario
Davinci, Mario
A prima vista sembrano riportare dei dati che, una volta
ricombinati, danno di nuovo le stesse informazioni, vero? Sbagliato...
Aggiungiamo le seguenti righe nelle rispettive tabelle, questa
volta per lo studente Luigi:
Interessi {Materia, Studente}
-----------------------------
Pittura, Luigi
Scultura, Luigi
Docenze {Docente, Studente}
---------------------------
Michelangelo, Luigi
Davinci, Luigi
Noterete che sono le stesse medesime righe di Mario.
Quindi... stessi dati, stesse informazioni?
Prima della soluzione, rifletteteci bene perche' il punto sta
tutto qui...
.
.
.
.
.
Questo e` lo schema per Luigi:
Lezioni {Materia, Docente, Studente}
--------------------------------
Pittura, Michelangelo, Luigi
Pittura, Davinci, Luigi
Scultura, Davinci, Luigi
Luigi NON segue il corso di scultura di Michelangelo, e questa
informazione non e` catturabile dalla corrispondente suddivisione
in uno schema binario.
Per gli archi di un grafo/ipergrafo, il concetto e` simile.
Immaginiamo la rete di strade che collegano Roma, Milano, Napoli
piu` le altre citta`; esse sono un reticolo in cui diciamo che
ogni citta` ha una strada che la collega a quelle vicine; a
queste condizioni uno schema con 2 nodi ed 1 arco e` sufficiente
a descrivere ogni strada.
Ora immaginate un arco che colleghi CONTEMPORANEAMENTE Roma,
Milano e Napoli; possiamo paragonarla all'autostrada.
Se entro in autostrada, posso andare DIRETTAMENTE in queste
tre citta` senza essere obbligato a compiere le tappe intermedie,
semplicemente restando in autostrada; questa strada e` distinta
dalla strada normale, e la caratteristica che ci interessa e` che
posso andare dal nodo Milano al nodo Napoli con un singolo arco.
Ricapitolando, la relazione ad N posti ha come caratteristica la
valenza _simultanea_ tra tutti i suoi termini; nel database
modeling e` interessante perche` una relazione ad N termini puo`
avere attributi propri che esistono solo al manifestarsi
simultaneo di questi N termini.
bye
Andrea D'Amore
"The man with two watches" <do...@spam.me> wrote:
> Credo di si: detta in breve, oltre a non essere la stessa
> cosa, una relazione ternaria non e` scomponibile in due
> relazioni a due posti senza PERDITA di informazioni.
Mi è chiaro, quello che non mi sembra è che la richiesta dell'OP
prevedesse una relazione ternaria, nel tuo messaggio precedente hai
cercato di spiegare proprio questo ma non sono convinto fosse quello che
lui intendeva.
The man with two watches
> "The man with two watches"
>
>> cosa, una relazione ternaria non e` scomponibile in due
>> relazioni a due posti senza PERDITA di informazioni.
>
> prevedesse una relazione ternaria, nel tuo messaggio precedente
> hai cercato di spiegare proprio questo ma non sono convinto fosse
> quello che lui intendeva.
Beh ma se e` per questo, neanche io so cosa lui intendeva, io
tengo valido innanzitutto quello che uno scrive...
Comunque permane anche da parte mia una certa parte di dubbio su
cosa gli serva, per cui se fossimo in una situazione lavorativa
"reale" un incontro vis a vis sarebbe chiaramente indispensabile.