Modello logico, dubbi di un principiante

di il
4 risposte

Modello logico, dubbi di un principiante

Salve,

sto imparando la teoria di basi di dati.
Però ho dei dubbi.

Per la mia convenzione, etichetterò la chiave primaria di ogni tabella con la simbologia "% %", e la
chiave esterna con " *".

1)
Ipotizziamo di avere creato lo schema logico che segue:

squadra(%nome%, anno_fondazione)

collaboratore_allenatore(%cod_fis%, nome, cognome, ruolo, cod_fis*)

allenatore(%cod_fis%, nome, cognome, età, nome*)

presidente(%cod_fis%, nome, cognome, età, nome*)

1a) La tabella "collaboratore_allenatore" contiene il campo "cod_fis*" che costituisce la chiave esterna di qualche altra tabella.
Come si fa a capire se questo campo "cod_fis*" si riferisce alla tabella "allenatore" o alla
tabella "presidente"?

1b) Dove va scritto il vincolo della chiave esterna?

1c) E' obbligatorio ridenominare "cod_fis" presente nella tabella "allenatore" per distinguerlo da
quello omonimo, presente nella tabella "presidente"?

Oppure ciò è lecito, a patto però di inserire in ogni query che coinvolge queste due tabelle,
il collegamento corretto fra la chiave primaria ed esterna?

1d) Ma non è conveniente assegnare le denominazioni diverse ai due campi "cod_fis" omonimi, così da evitare di ripetere ogni volta la ciorrispondenza fra la chiave esterna e la chiave primaria
all'interno di ogni query?

1e) Fra le due entità "squadra" e "presidente" esiste la corrispondenza 1:1.
Alla luce di ciò, è obbligatorio fondere le due tabelle, inserendo ogni campo della tabella "
presidente" dentro alla tabella "squadra"?

Quale delle tre forme normali impone questa fusione?

///////////////////

2)
Ipotizziamo di avere creato lo schema logico che segue:

giocatore(%id_G%, nome, cognome, ruolo, nome*)

squadra(%nome%, anno_fondazione)

allenatore(%nome%, %cognome%, età, nome*)

La tabella "giocatore" contiene la chiave esterna "nome*".

2a) C'è ambiguità nel capire se essa si riferisca al campo "nome" presente nella tabella
"allenatore" o nella tabella "squadra"?

Secondo me no: è evidente che esso si riferisce alla tabella "squadra".
Infatti, se ci si volesse riferire alla tabella "allenatore", allora si dovrebbe cambiare la
tabella "giocatore" in questa neo-forma:

giocatore(%id_G%, nome, cognome, ruolo, nome*, cognome*)

E' corretto ciò?

2b) Cioè è corretto affermare che, se la chiave interna di una tabella è composita, allora anche la
chiave esterna di essa (inserita in un'altra tabella) deve essere composita?

2c)
Ora si consideri invece il campo "nome*" presente nella tabella "allenatore".
C'è ambiguità nel capire se essa si riferisca al campo "nome" presente nella tabella
"giocatore" o nella tabella "squadra"?

Secondo me no: è evidente che esso si riferisce alla tabella "squadra".
Infatti il campo "nome" presente nella tabella "giocatore" non costituisce la chiave primaria, e
pertanto è impossibile che, in un'altra tabella, ci si riferisca a questo campo.

////////////////////////

grazie,

4 Risposte

  • Re: Modello logico, dubbi di un principiante

    Benvenuto nel forum.
    Se leggi attentamente il regolamento, troverai scritto che è preferibile scrivere un Titolo coerente con il successivo testo che poi si andrà a stendere. Il titolo che hai proposto mi sembra troppo generico.
    Le tabelle Collaboratori, Allenatori, Presidenti (usa sempre il plurale quando nomini le tabelle) parlano lo stesso linguaggio, ossia hanno gli stessi campi. Non devi avere 3 tabelle separate, ma una sola Persone.
    La chiave esterna si mette solitamente come ultimo campo. Può avere lo stesso nome della chiave primaria. Alcuni puristi, per non confoderle, preferiscono chiamare PkNomeCampo (chiave primaria) e FkNomeCampo (chiave esterna).
    A primo acchito si potrebbe pensare di relazionare Squadre uno-a-molti con Persone...e nella tabella Persone devi prevedere un campo Ruolo. Ma si dà il caso che, nel corso degli anni le Persone in una Squadra non sono sempre le stesse e spesso si interscambiano di Squadra e anche di Ruolo. In base a questo secondo ragionamento direi di considerare Squadre molti-a-molti con Persone attraverso una tabella di congiunzione che chiamerei Formazioni, con i seguenti campi:
    IDFormazione (contatore, chiave primaria)
    Stagione (o Annata)
    Squadra
    CodFisc
    Ruolo

    Relazioni:
    Squadre.NomeSquadra uno-a-molti con Formazioni.Squadra
    Persone.CodFisc uno-a-molti con Formazioni.CodFisc
  • Re: Modello logico, dubbi di un principiante

    Ok.

    a) Presumo che. nella tua modellizzazione, i campi "Codfisc" e "squadra" della tabella "formazioni" siano chiavi esterne delle tabelle "persona" e "squadra" rispettivamente, e dunque la tabella "formazioni" è indicabile, nel modello logico, così:

    Formazioni(IDFormazione, Stagione, Squadra*, CodFisc*, Ruolo)

    E' corretto ciò?

    b) E' lecito, nel modello logico relazionale, ridenominare le chiavi esterne di "Formazioni" così:

    Formazioni(IDFormazione, Stagione, Squadra.Squadra*, Persone.CodFisc*, Ruolo)

    c)
    non ho ancora capito come si fa per specificare il collegamento fra la chiave esterna di una tabella, e la chiave primaria di un'altra tabella (aspetto rilevante quando esistono tabelle diverse ove la chiave primaria ha la stessa denominazione).

    Per caso, la sola maniera consiste nel passare dal "modello logico relelazionale" al linguaggio SQL, ove si scrive:

    CREATE TABLE Persone
    (CodFis char(16) primary key,
    nome char(20),
    cognome char(20),
    età int);

    CREATE TABLE Squadre
    (nome_squadra char(20) primary key,
    budget int,
    anno_fondazione int);

    CREATE TABLE Formazioni
    (IDFormazione INT primary key,
    stagione int,
    Ruolo char,
    squadra char(20) CONSTRAINT s REFERENCES Squadre(nome_squadra),
    CodFis char(20) CONSTRAINT s REFERENCES Persone(CodFis)
    );

    Oppure esiste la maniera di specificare a quale chiave primaria si riferisca una chiave esterna
    rimanendo nel modello logico relazionale, cioè senza passare per il linguaggio SQL?

    d)
    La corrispondenza fra le chiavi esterne e primarie esposta nella tabella "Formazioni", impiegando il linguaggio SQL, è descrivibile anche in questa altra maniera, alternativa alla precedente:

    CREATE TABLE Formazioni
    (IDFormazione INT primary key,
    stagione int,
    Ruolo char,
    CodFis char(20),
    squadra char(20),
    FOREIGN KEY(squadra) REFERENCES Squadra(nome_squadra),
    FOREIGN KEY(CodFis) REFERENCES Persone(CodFis),
    );

    e) se invece il database non vuole fungere da archivio, ma solo da "foto "istantanea, allora andava bene il "modello logico relazionale" da me proposto nel mio post iniziale?

    grazie,

    adriano
  • Re: Modello logico, dubbi di un principiante

    Risposte:

    A) OK. Non ti consiglio di aggiungere l'asterisco al nome di campo, potresti avere problemi di interpretazione in future espressioni.

    B) Teoricamente sì, ma è sconsigliato nominare un campo col punto in mezzo, a maggior ragione che la parte a sinistra del punto ricorda un nome-tabella. Anche qui potresti avere problemi di interpretazione in future espressioni.

    A e B) Tu puoi chiamare anche Pippo la chiave primaria e Andrea la chiave esterna. L'importante è che ci sia coerenza nel tipo di dati dalla tabella madre verso la tabella figlia. La prassi più usata prevede per la chiave primaria un campo di tipo Contatore, la chiave esterna un campo di tipo Numerico impostato a Intero Lungo. Queste impostazioni di solito le trovi di default.
    Anche 2 campi Testo--->Testo possono essere legati da relazioni. Entrambi i campi devono avere la stessa lunghezza caratteri. Direi che questi due casi sono i più frequenti.
    Il vantaggio di nominare UGUALI chiave primaria e chiave esterna (io uso questa prassi), può consistere nella facilità logica in alcune procedure guidate (ad esempio creazione maschera/sottomaschera)...almeno in Access ciò accade.

    C) Io uso Access, dove esiste una comoda finestra Relazioni (come una "interfaccia utente"...non so se si può definire così), dove è possibile importare/visualizzare le tabelle e unire (disegnando manualmente) con una linea di join i campi da relazionare.
    Credo che la chiave primaria vada dichiarata esplicitamente. La chiave esterna lo è come dato di fatto. Forse per questo alcuni preferiscono nominare PkNomeCampo e FkNomeCampo.
    Quando si parla di relazioni fra tabelle ti consiglio di ragionare sempre partendo dalla tabella madre (quella con la chiave primaria) verso la tabella figlia (quella con la chiave esterna).

    D) Non so usare SQL.

    E) No. Puoi sempre sfruttare opportune query che ti permettono di rimettere ordine e visualizzare come piace a te.
  • Re: Modello logico, dubbi di un principiante

    Sei stato molto disponibile.

    grazie,

    Adriano
Devi accedere o registrarti per scrivere nel forum
4 risposte