DATABASE SQL come si implementa una relazione N a N

Ciao.
Io ho questo database con tre entità:
Film(IDfilm, titolo, regista)
Interpretazioni(IDartista,IDfilm)
Artisti(IDartista,Nome,Cognome)

NOTA Le chiavi primarie sono sottolineate, quelle esterne sono scritte in corsivo
quelle sia sottolineate chè in corsivo sono esterne e primarie nello stesso tempo

In pratica l'entità interpretazioni sarebbe il risultato di una relazione N a N tra Film e Artista..
Io, non sapendo come "dichiarare" contemporaneamente le chiavi esterne e primarie
in SQL DDL creo la tabella in questo modo:

Codice:

create table interpretazioni (ID interpretazione counter primary key, IDartista int references Artista(idartista), IDfilm int references Film(idfilm));

In pratica creo un altro campo IDinterpretazioni come primary key
e metto gli altri due come fk (chiave esterna)
non sapendo come si fà a dichiarare entrambi i campi FK e PK
Come dovrei procedere?
Poichè la mia non mi pare una soluzione mooooooolto eccellente..
:mrgreen:
Grazie per l'attenzione
Ciau :wink:

La query che ti serve è questa:

Codice:

CREATE TABLE Interpretazioni ( IDartista INT, IDfilm INT, PRIMARY KEY (IDartista, IDfilm), FOREIGN KEY IDartista REFERENCES Artista, FOREIGN KEY IDfilm REFERENCES Film );

Nota: l'engine del DB di AlterVista non è in grado di realizzare correttamente le chiavi esterne... vengono "parsate" ma non realmente implementate.

Stammi bene...

Citazione:

Originalmente inviato da dementialsite

La query che ti serve è questa:

Codice:

CREATE TABLE Interpretazioni ( IDartista INT, IDfilm INT, PRIMARY KEY (IDartista, IDfilm), FOREIGN KEY IDartista REFERENCES Artista, FOREIGN KEY IDfilm REFERENCES Film );

Nota: l'engine del DB di AlterVista non è in grado di realizzare correttamente le chiavi esterne... vengono "parsate" ma non realmente implementate.

Stammi bene...

Grazie infinite per la risposta era proprio quello che cercavo :razz:
No.. non devo fare nulla su altervista, era solo per motivi di studio..
comunque per un domani.. non mi è chiara la seguente dicitura:

Nota: l'engine del DB di AlterVista non è in grado di realizzare correttamente le chiavi esterne... vengono "parsate" ma non realmente implementate.

cosa intendi per parsate?

Rinnovo i miei ringraziamenti..
ciau :wink:

In pratica, se scrivi quella query sul phpMyAdmin di AV, risulterà corretta. Ma quello che viene realizzato è questo:
- crea una tabella di due campi di tipo intero
- questi due campi costituiscono la chiave primaria, e pertanto non potranno esserci record duplicati
- non ci saranno le chiavi esterne: in altre parole, se inserisci in IDartista un valore che non è presente tra gli ID della tabella Artista, non ti sarà segnalato alcun errore (come invece dovrebbe essere se le chiavi esterne fossero realmente implementate). Analogamente dicasi per il campo IDfilm.

Stammi bene...

Ad esempio

Codice:

FILM Attori 001 titanic 001 Dicaprio 002 Altrofilmcondicaprio 003 filmsenzaattori interpretazioni idfilm idattori 001 001 002 001 003 * 001 001 **

* !Questo non dovrebbe accadere (andrebbe applicata l'integrità referenziale invece questo non accade
** Questo è impossibile!
E questo che vuoi dire no? :wink:
A questo punto anche se viene sprecata memoria sarebbe migliore l'aneddoto di creare un altro ipotetico
IDinterpretazioni come chiave primaria e idfilm e idattori come chiavi esterne?
Ciao :)

EDIT:
Piccola nota:
nella tabella interpretazioni idartistaidattori sarebbe un unico campo della tabella.. o sbaglio?

A parte che si dice "integrità referenziale"... comunque:
- la prima situazione che descrivi non dovrebbe accadere, ma è perché il campo IDattori manca: fino a qui dovrebbe arrivarci anche MySQL-ISAM (ti ricordo che una chiave primaria non può assumere valori nulli per definizione)
- la seconda situazione causa errore (perché stai duplicando una chiave primaria)

La (vera prima) situazione a cui mi riferivo si ha se inserisci nella tabella interpretazioni il record (003, 002): in questo caso, seguendo la logica di SQL dovrebbe verificarsi un errore di "violazione di chiave esterna" (o integrità referenziale che dir si voglia). Questo perché il valore 002 non è presente nella tabella Attori. In MySQL-ISAM (il motore che usa AV), invece, il record è inserito senza errori... perché la chiave esterna non è stata realmente implementata.

Gli "ID artificiali" che descrivi andrebbero inseriti con molta cautela: spesso sono più le complicanze dei vantaggi. L'esempio classico è quello dei "finti duplicati": record uguali in tutto e per tutto, tranne che in questo ID. Quindi, se in una tabella esistono degli attributi (anche più di uno, anche tutti) che possono fungere da identificatore, è sempre meglio utilizzare quelli come chiave primaria, soprattutto se sono numerici.

Infine, ogni chiave esterna deve avere lo stesso numero di attributi e lo stesso tipo della chiave primaria di riferimento. Ti ricordo che anche se su AV non sei in grado di stabilire il vincolo di integrità referenziale via DDL (Data Definition Language, le CREATE per capirci), puoi sempre trattare gli attributi in questione come li hai dichiarati via DML (Data Manipulation Language, le INSERT o SELECT).

Stammi bene...