dbms e chiavi primarie

[Ivan Zanolla]

2008/4/5, Massimo <max@studiomasson.it>:
> Sto riflettendo su un tema correlato ai rdbms.
>  In particolare, sto cercando di capire se esistano dei casi in cui una
>  chiave primaria composta di un solo campo NON possa sostituire una
>  chiave primaria multi colonna. Allo stato attuale non mi sta venendo in
>  mente nulla, ma se qualcuno ha osservazioni in merito gli sarei grato se
>  volesse discuterne.
>
Rispondo a livello teorico avendo avuto un pignolone di docente al
corso di Basi di dati. In pratica non saprei, faccio sapere meglio per
il progetto del tirocinio che purtroppo ora non ho sottomano

>  Mi spiego meglio con un esempio:
>  ipotizziamo di avere 2 tabelle (A e B) in relazione tra loro (1:1 o 1:n,
>  non mi interessa attualmente...).
>  Ipotizziamo anche che la chiave primaria della tabella A sia composta da
>  k campi, e che quindi la tabella B per relazionarsi abbia bisogno di
>  altrettanti k campi da usare come foreign key.
>  La relazione è quindi tra k campi di B e k campi di A.
Esattamente, la definizione di chiave esterna necessita proprio della
stessa cardinalità della chiave primaria. E' proprio per definizione
"matematica".

>
>  La riflessione che facevo tra me e me è la seguente: in ogni caso, per
>  quanti siano quei "k" campi, viene sempre individuata una sola riga in
>  A. Lo stesso risultato (la relazione) lo si può quindi ottenere
>  utilizzando UN SOLO campo (il classico "id") nella tabella A ed un solo
>  campo foreign key nella tabella B, semplificando di molto la logica di
>  gestione.
Questo in generale, quando non si riesce a identificare una attributo
o più attributi che riescano a  formare una chiave primaria per quella
relazione si usa il famoso ID, che ovviamente, come chiave ha
cardinalità =1.

>
>  Mi chiedevo, e volevo con voi condividere:
>  1) è corretto il ragionamento?
Per me sì, leggi su.

>  2) è forse questo il motivo per cui molti ORM si disinteressano alla
>  gestione delle chiavi primarie multi campo e utilizzano spesso le chiavi
>  primarie su un singolo campo?
Ignoranza mia, ORM=?
Comunque spesso si fa *solo* per evitare di complicarsi la vita a
livello pratico ma a livello concettuale è sbagliato. Un modello ER
deve rappresentare la realtà, se non ho tipo il codice fiscale che
posso usare come chiave ma ho benissimo attributo a e b che possono
formare la chiave primaria si dovrebbero usare questi due.
Inutile dire al DBMS relazionale "dammi te la chiave primaria". Anche
perché devo poi aggiornare il mio dataset a livello di programmazione
istantaneamente su un valore numerico datomi dal database, quando
invece posso solo aggiornare il dataset con gli stessi valori che do
al DBMS senza che lui (codici errore a parte) mi dica niente.

>  3) mi sfugge qualche casistica, anche residuale, per cui le pk
>  multicampo potrebbero fare qualcosa che la pk su campo singolo non può
>  gestire?
Vale il punto precedente.

>
>  Grazie in anticipo a chi vorrà discutere su queste mie elucubrazioni...
E' un piacere, anzi adesso non so chi abbia studiato queste cose e chi
no (non credo che ci siano solo ingegneri qui) ma ho scritto degli
appunti per le Basi di dati (ovviamente sulla teoria generale). Se
qualcuno volesse leggere questo documento "Appunti per basi di dati"
che si trova a questo indirizzo
http://unipd.net/download.php?mode=unipedia&id=99 e mi desse pareri
consigli ecc ecc ne sarei lieto.
Qui c'è anche la definizione di chiave esterna, di chiave primaria ecc
ecc. Per chi volesse buttarsi in queste elucubrazioni.
>
>  Ciao,
>  max.
>
>  _______________________________________________
>  blug mailing list
>  blug@lists.linux.it
>  http://lists.linux.it/listinfo/blug
>