Newsgroup: it.comp.appl.access
Titolo: Re: relazione con una chiave primaria composta


CUT
Ti ricordo di rispondere dopo la precedente risposta e non prima.
Apri in struttura la tabella con i tre campi uniti in chiave primaria. Dal 
menù Visualizza seleziona Indici e potrai renderti conto da solo che pur 
essendo tre i campi legati nella chiave primaria un solo indice ha il nome 
di "PrimaryKey" con le caratteristiche di primario e univoco. I tre campi 
formano un solo indice univoco. Ora ti è piu' chiaro?
La seconda soluzione prospettata da Cinzia mi sembra la più corretta: Un 
artista molte opere attraverso IDArtista e IDOpera.
Ciao, Carlo 

Salve NG,
come faccio in Access a fare una relazione con una tabella che ha una chiave 
primaria composta?
Grazie 

@-- HeartEarth --! ha scritto:

Eh?
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Evidenzia i due campi e clicka sul simboletto della chiave primaria in
struttura tabella
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it


Vedi? c'č chi si trastulla e chi come me LAVORA con l'antiMAZZA !!! :-D


 Ciao MA come va? tutto bene ?
Sě tutto bene, un pň preso dalla realizzazione di un software di gestione
Ordini e vendite in inglese
perň tutto decisamente bene


riformulo la domanda...
ho le seguenti tabelle:
- OPERA(titolo,...,museo,artista)
titolo chiave primaria
museo chiave esterna per tabella MUSEO
artista chiave esterna per tabella ARTISTA
- ARTISTA(data_nascita,nome,cognome)
sono tutte chiavi PRIMARIE...chiave primaria composta
come faccio a fare una relazione 1 a N tra le tabelle consentendo anche 
l'integrità referenziale?
NB: N opere di 1 artista 

 :-D
Tu lo sai che in questo lavoro sto sentendo tanto odore di mandorle da farne
un torrone!!!


 ha scritto nel messaggio
news:F6aBe.14562$tX6.3...@twister1.libero.it...

Guarda come sono fatte le relazioni nel database di esempio della Northwind.
Non mi pare tu abbia bisogno di chiavi composte.
Ciao

[CUT]
Ciao,
che significa -> hai x caso indicizzato + campi di una tabella? 

 ha scritto nel messaggio 
news:409Be.14467$QV1.1...@twister2.libero.it...

..nella struttura della tabella devi selezionare i due campi che formeranno 
la c. primaria, poi fai click col destro del mouse sulla selezione e cliccki 
su chiave primaria, a questo punto dovrebbero apparire 2 chiavine a sx di 
entrambi i campi..
Ciao
Davide 



 ha scritto nel messaggio
news:F6aBe.14562$tX6.3...@twister1.libero.it...

Ciao  "<!-- HeartEarth --!>" ,
hai due possibilità:
1) aggiungi i campi Nome Cognome e Data di Nascita alla tabella opera e
diventerebbero chiavi esterne ma mi sento di sconsigliartela, anche perchè
non hai nessuna garanzia che non ci siano 2 artisti con lo stesso nome nati
nello stesso giorno per una qualche fortunata coincidenza astrale....
2) aggiungi una chiave primaria fittizia idArtista alla tabella Artista di
tipo contatore  e nella tabella Opera metti un campo IdArtista al posto del
campo Artista  che sarà la tua chiave esterna
Se vuoi  mantenere comunque l'univocità della tripletta (Cognome, Nome ,
Data di Nascita ) crei un indice univoco su questi 3 campi.
Saluti
Cinzia

 ha scritto nel messaggio 
news:42d53091$0$341$5fc...@news.tiscali.it...


[CUT]
;-) 

 ha scritto nel messaggio
news:F6aBe.14562$tX6.3...@twister1.libero.it...

Scusa, non te la prendere se sarò un po brusco ma la domanda lascia
intravedere non una lacuna ma un canyon:
sai che cosa si intende per vincolo di integrità referenziale?
Se artista è univocamente determinato dalla chiave primaria composta
(data_nascita,nome,cognome) e la tabella OPERA referenzia la tabella
ARTISTA, allora anche la tabella OPERA deve avere una chiave esterna
composta del tipo (data_nascita,nome,cognome).
In ANSI-SQL faresti
ALTER TABLE OPERA ADD CONSTRAINT
FK_OPERA_ARTISTA FOREIGN KEY (data_nascita,nome,cognome) REFERENCES
ARTISTA(data_nascita,nome,cognome)
Non so se Access supporta questa sintassi, altrimenti segui i seguenti
passi:
1) Apri la tabella OPERA in modalità struttura ed aggiungi tre campi di tipo
compatibile con quelli che sono chiave in ARTISTA (consglio: falli
propriouguali nel nome e nel tipo);
2) Seleziona i predetti tre campi e definisci un indice univoco (se hai già
definito una chiave primaria rimuovi la chiave);
3) Definisci la chiave primaria della tabella OPERA (che, secondo quanto hai
detto, dovrebbe comprendere i tre predetti campi);
4) Salva;
5) Definisci la chiave primaria nella tabella ARTISTA come ti è stato
suggerito nei precenti post;
6) Apri la maschera "relazioni" ed aggiungi le due tabelle.
7) Seleziona dalla tabella OPERA i tre campi che sono chiave della tabella
ARTISTA e trascinali sopra a quest'ultima.
8) Nella mascherina delle relazioni, componi le esatte corrispondenze tra i
tre campi di ciascuna tabella e seleziona il flag che applica l'integrità
referenziale.
9) Fatto!
Comunque, IMHO, Access da questo punto di vista fa proprio cagare.
Yogurts Sincerely
--
Simplex2
www.mdenittis.it
________________
LEGGE DEGLI EQUILIBRI DI SIMPLEX2
Da un grande potere, derivano grandi responsabilità,
da grandi responsabilità, derivano grandi rompimenti di palle,
i rompimenti di palle sono una gran perdita di tempo ma il tempo è denaro,
quindi una gran perdita di denaro comporta una grande perdita di potere.

 ha scritto nel messaggio 
news:409Be.14467$QV1.1...@twister2.libero.it...

Cosa devi relazionare e perchè. Fai un esempio.
Se vuoi applicare l'integrità referenziale devi avere indici univoci ossia 
la parte uno deve avere un indice univoco e la parte due può anche non avere 
indici univoci e avere una chiave primaria composta da due o più campi.
Ciao,Carlo 


umm forse questa non si capisce bene, riprovo
no, è proprio una necessità per gestire l'integrità referenziale, senza
l'indice univoco nella tabella lato 1 potresti avere più righe (del lato 1)
che puntano
agli stessi record della tabella lato molti
Ciao Giorgio

 Alla faccia dell'ottimizzazione!
no, è proprio una necessità per gestire l'integrità referenziale, senza
l'indice univoco nella tabella lato 1 potresti avere più righe che puntano
alla tabella lato molti, insomma, un pasticcio di prughe.
:-)
Ciao Giorgio

 limiti di Access.
perche' pensi che da altre parti la solfa sia diversa? E' poi se hai una 
integrita' a cascata non sempre i figli hanno indici univoci
Non mi chiamo Carlo *mappoiche'*, ultimamente, un paio di volte, cosi' 
mi hanno appellato mi sono sentito coinvolto ;<)
--
a.cara


Ciao  "<!-- HeartEarth --!>" ,
Visualizza struttura della tabella Artista,
selezioni il campo IDArtista e fai  click sulla chiavetta  (Primary Key)
Adesso click sull'icona stile Fulmine (indici)
Vedrai che avrai sicuramente un indice in corrispondenza di IDArtista, per
costruirti un indice univoco sui campi Nome Cognome e DataNascita
Scrivi il  nome da dare all' indice diciamo Indice2 selezioni il campo
Cognome, nella riga sotto lasci bianco lo spazio del nome dell'indice e
selezioni il campo Nome,
nella riga sotto lasci sempre bianco il nome dell'indice e selezioni il
campo data Nascita , sotto metti la spunta su Univoco.  Chiudi ed ecco
fatto!
Saluti
Cinzia
PS.  In bocca al lupo per l'esame..

 a.cara
;-)
Ciao.



Giorgio, stamani non mi sono svegliato col senso del comprendonio al
massimo.
Faccio un esempio:
Tabella 1: Regione
CREATE TABLE Regione (
ID integer PRIMARY KEY,
Nome VARCHAR(20),
....,
....
)
Tabella 2: Anagrafica
CREATE TABLE Anagrafica (
Matricola VARCHAR(20) PRIMARY KEY,
Nome VARCHAR(20),
Cognome VARCHAR(20),
Regione integer REFERENCES Regione(ID),
....,
....
)
Nello schema ho definito un vincolo di integrità referenziale
(accademicamente parlando).
Allora, un'istanza del precedente schema può essere la seguente:
Anagrafica:
12345     Michele Rossi    1
30930    Giorgio   Verdi    2
59090      Claudio Bianchi 5
67678     Stefano Neri        1
78794    Mimmo Viola      5
Regione:
1   Lazio
2   Toscana
3  Liguria
4  Lombardia
5  Veneto
L'indice (univoco) su Regione.ID viene automaticamente generato insieme al
vincolo di chiave primaria (i più diffusi RDBMS sulla piazza lo fanno,
almeno quelli che ho usato io). Ok?
Non rimane che analizzare la tabella Anagrafica.
Se ho capito bene (spero proprio di no), tu vorresti definire un indice
univoco su Anagrafica.Regione?
Se è così vado a fare di nuovo colazione, passo da uno spacciatore, sniffo
un po di robaccia, poi torno e ne discutiamo.
:-)
Attendo risposta.


agli stessi record della tabella lato molti
----
quindi ho scritto *senza l'indice univoco nella tabella lato 1* ovvero nel
tuo esempio la tabella Regione.
Senza l'indice univoco potresti avere due o più righe della tabella Regione
con valore id=100 che puntano a n righe della tabella anagrafica che hanno
il campo Regione=100..
Per indice univoco io intendevo questo:
esempio di relazione con constraint unique
--------
--Tabella 1: Regione
CREATE TABLE Regione (
ID integer UNIQUE,
Nome VARCHAR(20)
)
--Tabella 2: Anagrafica
CREATE TABLE Anagrafica (
Matricola VARCHAR(20) PRIMARY KEY,
Nome VARCHAR(20),
Cognome VARCHAR(20),
Regione integer REFERENCES Regione(ID)
)
-------
esempio con indice univoco
-------
CREATE TABLE Regione (
ID integer ,
Nome VARCHAR(20)
)
CREATE UNIQUE INDEX Ix_Regione
ON Regione(ID)
--Tabella 2: Anagrafica
CREATE TABLE Anagrafica (
Matricola VARCHAR(20) PRIMARY KEY,
Nome VARCHAR(20),
Cognome VARCHAR(20),
Regione integer REFERENCES Regione(ID)
)
--------
Ciao Giorgio

agli stessi record della tabella lato molti
Ecco, non avevo capito che ti riferivi alla tabella Regione.
Leggendo, pensavo ti riferissi alla tabella Anagrafica, da cui il mio
sbigottimento.
Quindi, per chiarire, ho inserito gli script di definizione delle tabelle e
dei vincoli I. R..
Ok?


 generano anche un indice univoco.
si, ma non era questo il punto, il punto era che c'è bisogno di un indice
univoco nella tabella lato 1, poi, che sia primaria o no non ha importanza,
dipende da come vuoi gestire la tabella.
Ciao Giorgio

 univoco nella tabella lato 1,
poi che sia una chiave primaria o no non ha importanza, dipende da come vuoi
gestire la tabella.
Giorgio

 il tuo commento (se tu l'avessi letto prima di scrivere ... :-) ).
per prassi leggo sempre tutto una prima volta, conto fino a 5,
poi rileggo, medito, per quello che la mia confusione mi consente,
e poi, forse, rispondo. Leggo,rileggo la mia risposta e qualche
volta la cancello. Naturalmente capita che  mi incazzi, ma non e'
questo il caso, e derogo. ;<)
Cos'e' per te un indice "cluster"?
--
a.cara

 > univoco nella tabella lato 1,
No Giorgio, il problema è che insisti su una questione di rilevanza
marginale (e non so perchè), per di più anche scorretta.
Il mio errore deriva dal fatto che non capivo la tua frase:
<<nella tabella lato 1 potresti avere più righe che puntano alla tabella
lato molti>>.
Per me quella frase indicava la tabella Anagrafica, ma poi mi sono accorto
che sbagliavo.
Cercherò di spiegarti perchè la questione che poni è scorretta, lasciando da
parte la retorica e andando direttamente alla teoria relazionale:
L' integrità referenziale è un vincolo di tipo LOGICO (vedi progettazione L
O G I C A, schema LOGICO), mentre gli indici attengono all'implementazione
di un database (vedi progettazione F I S I C A). E già dovresti intuire dove
vado a parare.
Affinchè sussista un vicolo di I.R. sono necessarie due condizioni logiche:
1) Unicità del campo referenziato (R E F E R E N Z I A T O è la terminologia
corretta, non tabella lato 1);
2) Assenza di valori NULL nel campo referenziato.
Le due condizioni traducono il concetto che il campo referenziato (o l'
insieme di campi referenziato) identifica univocamente i record della
tabella referenziata e può essere chelto quale chiave di tale tabella. La
chiave primaria è una chiave minimale.
Nulla vien detto sui campi vincolati (V I N C O L A T I è la terminologia
corretta) della tabella referente (R E F E R E N T E, non tabella lato
molti);
Se convieni con quanto ho scritto sopra, non ti sarà difficile convenire con
me che l'indicizzazione (del campo vincolante) della tabella REFERENZIATA
non centra un'emeritra S E G A perchè  attiene questioni implementative e
non logiche.
Dunque per l'integrità referenziale (LOGICA) è necessario definire chiavi
non indici.
Dunque del termine "indice univoco", accetto l'aggettivo univoco ma scarto
il sostantivo indice.
Veniamo allo script SQL:
CREATE TABLE Regione (
ID integer PRIMARY KEY,
Nome VARCHAR(20),
)
In questo modo io creo lo schema di una tabella imponendo il vincolo logico
di CHIAVE PRIMARIA che comporta UNICITA' e CONSISTENZA (assenza di valori
null). Dunque questa tabella, con questa definizione, è già pronta per
essere referenziata.
E' frequente che il vincolo di integrità referenziale viene OPERATIVAMENTE
sfruttato per operazioni di correlazione, come il JOIN.
Un'operazione di join tra due tabelle si esegue con un algoritmo di ordine
O(N^2), cioè, nel caso peggiore, se due tabelle hanno N record cadauna il
join impiega
N*N passaggi.
Se le tabelle sono 3, l'ordine di complessità dell'algoritmo di join è
O(N^3).
Gli algoritmi di join "nudi e crudi" hanno, quindi, complessità POLINOMIALE.
Per abbassare la complessità degli algoritmi, possiamo imporre un
ordinamento sui campi di matching (cioè sui campi che compaiono nella
condizione di join) e ciò lo si fa definendo un INDICE. L'algoritmo più
diffuso, in queste condizioni, è il citato INDEX NESTED LOOP JOIN.
Ma siamo già in fase implementativa o FISICA!
I più diffusi RDBMS creano di default un indice in corrispondenza della
definizione di una chiave primaria. Non penso proprio che accada il
vicevesa, percui:
CREATE TABLE Regione (
ID integer PRIMARY KEY,
Nome VARCHAR(20),
)
implica
CREATE TABLE Regione (
ID integer ,
Nome VARCHAR(20)
)
CREATE UNIQUE INDEX Ix_Regione
ON Regione(ID)
MA NON IL VICEVERSA!
Ti dirò di più.
Lo script che hai riportato, anche se sintatticamente è corretto,
semanticamente è errato!
Spero di essere statio chiaro, esaudiente ed esaustivo.
Tempo addietro avevo scritto delle dispense sull'argomento, se vuoi le cerco
e le pubblico sul mio sito.
--
Simplex2
www.mdenittis.it
________________
LEGGE DEGLI EQUILIBRI DI SIMPLEX2
Da un grande potere, derivano grandi responsabilità,
da grandi responsabilità, derivano grandi rompimenti di palle,
i rompimenti di palle sono una gran perdita di tempo ma il tempo è denaro,
quindi una gran perdita di denaro comporta una grande perdita di potere.


 Cos'e' per te un indice "cluster"?
Per me?
Un indice CUSTER è un indice CLUSTER!
Vai a pagina 5 di questa mia dispensina:
http://www.mdenittis.it/Documentazione/Database/TECNOLOGIA%20DI%20UN%20BDMS_
IV_1.pdf
Soddisfatto?
Ho scritto cazzate?
"Ti che te sapi?" (trad. che mi sai dire?)


 il sostantivo indice.
Non so in che database sia sbagliato usare un indice univoco, io uso solo i
db di  Access e Sql Server
Per l'integrità referenziale non ha importanza se si usa una primary key un
constraint univoco o un indice univoco.
----
Foreign Key Constraints
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vdtsql/dvovrforeignkeyconstraints.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb/cm_8_des_04_8ypg.asp
----
Ciao Giorgio

 Ho scritto cazzate?
Ad una prima scorsa direi proprio di no.
buono, me lo leggero' con tutta calma. Mi segno l'indirizzo.  Trovo 
splendido l'inclusione delle immagini, come posso definirle?, 
"analogiche"?. Anche l'occhio vuole la sua parte.
--
a.cara

 a.cara
Hahahahaha :D
Accordato per "analogiche".


 db di  Access e Sql Server
Giorgio non è sbagliato usare un indice univoco. Il fatto è che gli indici
intervengono ad un livello, il fisico o implementativo, mentre l'integrità
referenziale non è un problema di tipo fisico o implementativo ma logico.
L'Intergità referenziale è una delle colonne portanti del modello
relazionale, l'indicizzazione no, come non lo è la paginazione, la
concorrenza, la persistenza e le altre fondamentali funzionalità di un DBMS,
perchè solo la prima attiene il modello logico relazionale.
Occhio a non confondere i due aspetti, anche se comunemente e praticamente
li affronti contestualmente.
Ciao.


 Accordato per "analogiche".
Mi ero dimenticato di scriverlo nel post precedente.
Perche BDMS?
--
a.cara

 --
Perchè mi sono sbagliato.
DBMS
