Newsgroup: it.comp.software.database
Titolo: creare il 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,
 
adriano
 

 
 
non ho ben chiaro che differenza tu faccia tra schema logico cosi' come 
l'hai definito perche' parli di tabelle e mi sembra quindi uno schema 
fisico piu' che logico
 
comunque io la vedo diversamente:
squadra (%id_squadra%, [attributi a piacere])
 
persona (%id_persona%(diverso dal cf che non *vuoi* usare come 
identificativo univoco), [elenco attributi a piacere])
 
ruolo_persona (id_persona*, %ruolo*%, %id_squadra*%)
 
ruolo (%id_ruolo%, descrizione)
 
N.B.: la tabella ruolo_persona strutturata come l'ho definita impone al 
massimo una sola persona per ogni ruolo per ogni squadra. da verificare 
se questa soluzione e' adeguata alla tua situazione oppure no.
 
con questa struttura eviti o risolvi alla radice quasi tutti i tuoi 
commenti e dubbi
 
[huge cut]
 
 
 
-- 
Paolo opg
 
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--


 
Un consiglio, non fare le relazioni in questo modo, per flessibilità
usa gli id come chiavi  per le relazioni
 
 
Es:
 
Squadra(%id%,.....)
 
 
Giocatore(%id%,.....)
 
 
 
Poi i giocatori cambiano con il tempo squadra
Per qui la relazione cambia con il tempo
 
Si introduce una tabella di relazione tra giocatori e squadra
 
Un esempio:
SquadraGiocatore(%idsquadra%,%idgiocatore%,%inizioperiodo%,fineperiodo)
 
 
(idssquadra,idgiocatore,inizioperiodo) è una primary key
idsquadra punta a squadra(id)
idgiocatore punta a giocatore(id)
 
 
 
Per il presidente una cosa simile
 
 
 

 commenti e dubbi
 
grazie.
 
Noto che hai impiegato, per ogni chiave esterna, la stessa denominazione della chiave primaria 
associata (in un'altra tabella).
Non ho capito però come si fa ad essere sicuri, nel tuo modello logico relazionale, che la chiave esterna
"id_persona*" inserita nella tabella "ruolo_persona", sia riferita proprio alla chiave primaria 
"persona.id_persona".
 
Non potrebbe rimanere il dubbio, perlomeno al computer, che "id_persona*" si riferisca a 
"squadra.id_squadra" o a "ruolo.id_ruolo"?
 
Oppure il computer (DBMS) capisce da solo, senza doverlo specificare in qualche clausola, che la chiave esterna 
"id_persona*" si riferisce alla tabella "persona" perchè solo essa, fra le varie tabelle impiegate nel 
database, ha la chiave primaria con la stessa denominazione della chiave esterna impiegata nella tabella
"ruolo_persona"?
 
Oppure serve partire dal presupposto che il "modello logico relazionale" non riporta tutte le informazioni
che servono al computer-DBMS (che andranno poi specificate in SQL),  ma solo alcune di esse (e, fra le 
informazioni che il "modello logico relazionale" omette, ci sono proprio le corrispondenze fra ogni chiave 
esterna impiegata, e l'opportuna chiave primaria associata in un'altra tabella)?
 
Cioè è cirreto affrmare che la corrispondenza fra la chiave esterna "ruolo_persona.id_persona" e la chiave primaria 
"persona.id_persona" è indicabile solo impiegando il lingaggio SQL, in questa maniera:
 
CREATE TABLE Persona
id_persona INT primary key,
nome char(20),
cognome char(20);
 
CREATE TABLE Squadra
id_squadra INT primary key,
nome char(20),
budget int,
anno_fondazione int;
 
CREATE TABLE Ruolo
id_ruolo INT primary key,
descrizione char(20),
 
CREATE TABLE Ruolo_Persona
(IDFormazione INT primary key,
stagione int,
Ruolo char,
id_squadra char(20),
id_persona char(20), 
FOREIGN KEY(id_squadra) REFERENCES Squadra(id_squadra),
FOREIGN KEY(ruolo) REFERENCES ruolo(id_ruolo),
FOREIGN KEY(id_persona) REFERENCES Persona(id_persona)
);
 
grazie,
 
adriano

 idgiocatore punta a giocatore(id)
 
Come si scrive questo legame "punta" nello "schema logico relazionale"?
 
Impiegando SQL è corretto scriverlo così:
 
CREATE TABLE SquadraGiocatore
fineperiodo DATE,
PRIMARY KEY(idsquadra,idgiocatore,inizioperiodo),
FOREIGN KEY(idsquadra) REFERENCES Squadra(Id_squadra),
FOREIGN KEY(idgiocatore) REFERENCES Giocatori(id),
 
grazie,
 
adriano
 


 
Non si scrive cosi ma cosi
 
CREATE TABLE SquadraGiocatore (
	idsquadra   t_seq
	,idgiocatore t_seq
	,inizioperiodo date
	,fineperiodo date
);
 
alter table squadragiocatore add constraint squadraGiocatore_pk primary 
key(idsquadra,idgiocatore,inizioperiodo);
 
alter table squadragiocatore add constraint squadraGiocatore_fk0 foreign 
key (idsquadra) references squadra(id);
 
ecc...
 
Dando dei nomi ai constraint è ancora meglio perchè in caso di errore di 
violazione di constraint nel messaggio di errore si ha un nome 
facilmente capibile
 
Es:
     violated constraint squadraGiocatore_fk0
 
	molto piu chiaro di :
 
     violated constraint sys0010
 
 
 
t_seq è il tipo di un id generico
Puo essere sostituito da int, long, number(10),bigint,ecc..
oppure da un create domain t_seq as bigint  ad esempio, sempre se il 
database utilizzato supporta i domini creati dagli utenti
 
 
 

 database utilizzato supporta i domini creati dagli utenti
 
 
 
 
 
grazie enoquick,
 
mi rimane un dubbio fondamnetale sulla questione.
 
E' corretto affermare che il "modello logico relazionale" non riporta tutte le informazioni che servono al computer-DBMS (che andranno poi specificate in SQL),  ma solo alcune di esse (e, fra le informazioni che il "modello logico relazionale" omette, ci sono proprio le corrispondenze fra ogni chiave esterna impiegata, e l'opportuna chiave primaria associata in un'altra tabella)?
 
Cioè è corretto affermare che la corrispondenza fra la chiave esterna (per esempio "ruolo_persona.id_persona") e la (chiave primaria "persona.id_persona") è indicabile solo passando al lingaggio SQL, ma non rimanendo alla descrizione del database data dal "modello logico relazionale"?
 
grazie,
 
adriano
 

 Poi volendo si possono specificare anch' esse quando si disegna il progetto
 
Per esempio tu come indicheresti le relazioni fra chiave primaria e chiave esterna nel modello logico relazionale di esempio che segue:
 
giocatore(%id_G%, nome, cognome, ruolo, nome*)
 
squadra(%nome%, anno_fondazione)
 
Lo indicheresti a parole, e cioè scriveresti, sotto alle precedenti righe:
 
"giocatore.nome" corrisponde a "squadra.nome"
 
?
 
grazie,
 
adriano


senza stare a scrivere una bella frase basta una convenzione tipo
 
campo => campo
 
oppure si usano i disegni
 
 

sei stato molto disponibile.
 
grazie,
 
Adriano