Problematiche relative alla gestione di Database
 

creare il modello logico, dubbi di un principiante

adrianomeis03@gmail.com 5 Dic 2014 14:20
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
cos*****uisce 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 en*****à "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 cos*****uisce la
chiave primaria, e pertanto è impossibile che, in un'altra tabella, ci si
riferisca a questo campo.

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

grazie,

adriano
enoquick 5 Dic 2014 15:07
Il 05/12/2014 07:20, adrianomeis03@gmail.com ha scritto:
>
> 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
cos*****uisce 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"?
>


Dalla relazione che va scritta come foreign key da qualche altra parte

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

In un comando foreign key


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

No, non c'è conflitto di nomi


> 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?


Nelle query si usa un join per collegare tra loro le tabelle

>
> 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?
>

Questione di gusti, ma personalmente preferisco usare nomi uguale per
identificare una stessa en*****à

> 1e) Fra le due en*****à "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"?
>

Per flessibilità meglio di no, il presidente cambia con il tempo
E se si volesse tenere uno storico dei presidenti la relazione 1:1 non
sarebbe piu valida

> Quale delle tre forme normali impone questa fusione?
>

quali tre forme ?
Non capisco

> ///////////////////
>
> 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"?
>

No se si specifica tabella.campo


> 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?
>


Il numero di campi della relazione deve essere uguale
Obbligatoriamente

> 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 cos*****uisce
la chiave primaria, e pertanto è impossibile che, in un'altra tabella, ci si
riferisca a questo campo.
>

No, come spiegato sopra

> ////////////////////////
>
> grazie,
>
> adriano
>

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
adrianomeis03@gmail.com 7 Dic 2014 09:11
Il giorno venerdì 5 dicembre 2014 15:03:09 UTC+1, Paolo opg ha scritto:
> adrianomeis03@gmail.com wrote in
> news:31cbe35e-25ae-4d57-838e-9502ab48eac7@googlegroups.com:
>
>>
>> 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*)
>>
>
> 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


Non concordo.
Forse le definizioni non sono standardizzate.
Il mio libro di riferimento impiega la denominazione "schema logico relazionale"

per indicare le tabelle.
Infatti esso scrive:

"
partendo da uno schema concettuale, si passa alla creazione di uno
schema logico relazionale applicando le seguenti regole:
le en*****à dello schema concettuale diventano tabelle
[...]

Successivamente alla definizione dello schema logico si procede con la specifica
dei parametri, che serviranno per la memorizzazione dei dati da parte del DBMS.
Questa fase prende anche il nome di progettazione fisica.
"

> 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

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
adrianomeis03@gmail.com 7 Dic 2014 09:19
Il giorno venerdì 5 dicembre 2014 15:07:19 UTC+1, enoquick ha scritto:
> Il 05/12/2014 07:20, adrianomeis03@gmail.com ha scritto:
>>
>> 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
cos*****uisce 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"?
>>
>
>
> Dalla relazione che va scritta come foreign key da qualche altra parte
>
>> 1b) Dove va scritto il vincolo della chiave esterna?
>
> In un comando foreign key

Potresti essere più preciso?
Dove va specificata la corrispondenza fra ogni "foreign key" e la "primary key"
associata?
Va specificata solo al momento in cui si passa al linguaggio SQL, per esempio
così:

CREATE TABLE allenatore
(COdFis char(16) primary key,
nome char(20),
cognome char(20),
CodFis char(16),
)

CREATE TABLE collaboratore_allenatore
(CodFis char(16) primary key,
nome char(20),
cognome char(20),
CodFis char(16),
FOREIGN KEY(cod_fis) REFERENCES Allenatore(cod_fis)
);

In questo mio esempio però la tabella "collaboratore_allenatore" avrebbe due
campi (colonne) con la stessa denominazione "CodFis", il che non è lecito.

Dunque devo per forza ridenominare uno dei due campi.
E' corretto ciò?

>> 1c) E' obbligatorio ridenominare "cod_fis" presente nella tabella
"allenatore" per distinguerlo da quello omonimo, presente nella tabella
"presidente"?
>>
>
> No, non c'è conflitto di nomi
>
>
>> 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?
>
>
> Nelle query si usa un join per collegare tra loro le tabelle
>
>>
>> 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?
>>
>
> Questione di gusti, ma personalmente preferisco usare nomi uguale per
> identificare una stessa en*****à

Se io inserisco il comando "foreign key" come da te suggerito in precedenza,
allora poi posso evitare di inserire le corrispondenze fra le chiavi esterne e
primarie, all'interno della clausola "wHERE", nelle query che creerò?

>> 1e) Fra le due en*****à "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"?
>>
>
> Per flessibilità meglio di no, il presidente cambia con il tempo
> E se si volesse tenere uno storico dei presidenti la relazione 1:1 non
> sarebbe piu valida


E se invece a me interessasse memorizzare nel database solo la "foto istantanea"
delle varie squadre (senza creare l'archivio storico), allora sarebbe
conveniente fondere le due tabelle in una?
Infatti agendo in questa maniera occupo meno memoria, perchè, in totale,
impiego una colonna in meno.

>> Quale delle tre forme normali impone questa fusione?
>>
>
> quali tre forme ?
> Non capisco

Intendo: il porre il database in prima forma normale, o in seconda forma
normale, o in terza forma normale, implica il dovere fondere le tabelle fra cui
esiste la corrispondenza 1:1?

>> ///////////////////
>>
>> 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"?
>>
>
> No se si specifica tabella.campo

Intendi affermare che è lecito scrivere nel "modello logico relazionale":

squadra(%nome%, anno_fondazione)
giocatore(%id_G%, nome, cognome, ruolo, squadra.nome*)

E' strano che finora non abbia ancora visto da nessuna parte l'uso di questa
notazione "squadra.nome*" nello "schema logico relazionale".

[...]

> 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)

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
enoquick 7 Dic 2014 15:57
Il 07/12/2014 02:19, adrianomeis03@gmail.com ha scritto:
> Il giorno venerdì 5 dicembre 2014 15:07:19 UTC+1, enoquick ha scritto:
>> Il 05/12/2014 07:20, adrianomeis03@gmail.com ha scritto:
>>>
>>> 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
cos*****uisce 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"?
>>>
>>
>>
>> Dalla relazione che va scritta come foreign key da qualche altra parte
>>
>>> 1b) Dove va scritto il vincolo della chiave esterna?
>>
>> In un comando foreign key
>
> Potresti essere più preciso?
> Dove va specificata la corrispondenza fra ogni "foreign key" e la "primary
key" associata?
> Va specificata solo al momento in cui si passa al linguaggio SQL, per esempio
così:
>
> CREATE TABLE allenatore
> (COdFis char(16) primary key,
> nome char(20),
> cognome char(20),
> CodFis char(16),
> )
>
> CREATE TABLE collaboratore_allenatore
> (CodFis char(16) primary key,
> nome char(20),
> cognome char(20),
> CodFis char(16),
> FOREIGN KEY(cod_fis) REFERENCES Allenatore(cod_fis)
> );
>
> In questo mio esempio però la tabella "collaboratore_allenatore" avrebbe due
campi (colonne) con la stessa denominazione "CodFis", il che non è lecito.
>


Ovvio che non è lecito
Ma se il codfis esiste già perchè duplicarlo ?

Comunque mettere il codfis come chiave primaria è poco flessibile in
quanto diventerebbe obbligatorio
Meglio usare gli id


> Dunque devo per forza ridenominare uno dei due campi.
> E' corretto ciò?
>

Basta non mettere il secondo, in fondo perchè duplicare un campo ?

>>> 1c) E' obbligatorio ridenominare "cod_fis" presente nella tabella
"allenatore" per distinguerlo da quello omonimo, presente nella tabella
"presidente"?
>>>
>>
>> No, non c'è conflitto di nomi
>>
>>
>>> 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?
>>
>>
>> Nelle query si usa un join per collegare tra loro le tabelle
>>
>>>
>>> 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?
>>>
>>
>> Questione di gusti, ma personalmente preferisco usare nomi uguale per
>> identificare una stessa en*****à
>
> Se io inserisco il comando "foreign key" come da te suggerito in precedenza,
allora poi posso evitare di inserire le corrispondenze fra le chiavi esterne e
primarie, all'interno della clausola "wHERE", nelle query che creerò?
>


No, le foreign key sono solo dei vincoli,non un modo per automatizzare
delle relazioni tra tabelle nelle query
E le relazioni è meglio specificarle nella clausola join non where
La where usarla solo come filtro non per le relazioni


>>> 1e) Fra le due en*****à "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"?
>>>
>>
>> Per flessibilità meglio di no, il presidente cambia con il tempo
>> E se si volesse tenere uno storico dei presidenti la relazione 1:1 non
>> sarebbe piu valida
>
>
> E se invece a me interessasse memorizzare nel database solo la "foto
istantanea" delle varie squadre (senza creare l'archivio storico), allora
sarebbe conveniente fondere le due tabelle in una?
> Infatti agendo in questa maniera occupo meno memoria, perchè, in totale,
impiego una colonna in meno.
>

Certo, è limitante ma se ti piace cosi


>>> Quale delle tre forme normali impone questa fusione?
>>>
>>
>> quali tre forme ?
>> Non capisco
>
> Intendo: il porre il database in prima forma normale, o in seconda forma
normale, o in terza forma normale, implica il dovere fondere le tabelle fra cui
esiste la corrispondenza 1:1?
>

Non è obbligatorio fondere le tabelle con relazioni 1:1 tra loro
E' piu logico separare en*****à differenti in tabelle differenti anche se
tra loro esiste una relazione 1:1
Ma chiaramente non è un obbligo


>>> ///////////////////
>>>
>>> 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"?
>>>
>>
>> No se si specifica tabella.campo
>
> Intendi affermare che è lecito scrivere nel "modello logico relazionale":
>
> squadra(%nome%, anno_fondazione)
> giocatore(%id_G%, nome, cognome, ruolo, squadra.nome*)
>
> E' strano che finora non abbia ancora visto da nessuna parte l'uso di questa
notazione "squadra.nome*" nello "schema logico relazionale".
>


Non l' hai mai vista perchè è sbagliata e non ho mai detto questo
E' nella relazione della clausola select che si specifica tabella.nomecampo

> [...]
>
>> 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)
>
> 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 sos*****uito 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
adrianomeis03@gmail.com 8 Dic 2014 19:15
Il giorno domenica 7 dicembre 2014 15:58:00 UTC+1, enoquick ha scritto:

> t_seq è il tipo di un id generico
> Puo essere sos*****uito 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





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
enoquick 8 Dic 2014 19:34
Il 08/12/2014 12:15, adrianomeis03@gmail.com ha scritto:
> Il giorno domenica 7 dicembre 2014 15:58:00 UTC+1, enoquick ha scritto:
>
>> t_seq è il tipo di un id generico
>> Puo essere sos*****uito 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
>
>
>
>
>
> 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"?

Il modello relazione tratta delle relazioni tra oggetti ed è basato
sulla teoria degli insiemi quindi in se non tratta le restrizioni
(constraint)
Poi volendo si possono specificare anch' esse quando si disegna il progetto






>
> grazie,
>
> adriano
>
adrianomeis03@gmail.com 9 Dic 2014 19:31
Il giorno lunedì 8 dicembre 2014 19:35:04 UTC+1, enoquick ha scritto:

> Il modello relazione tratta delle relazioni tra oggetti ed è basato
> sulla teoria degli insiemi quindi in se non tratta le restrizioni
> (constraint)
> 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
enoquick 9 Dic 2014 21:43
Il 09/12/2014 12:31, adrianomeis03@gmail.com ha scritto:
> Il giorno lunedì 8 dicembre 2014 19:35:04 UTC+1, enoquick ha scritto:
>
>> Il modello relazione tratta delle relazioni tra oggetti ed è basato
>> sulla teoria degli insiemi quindi in se non tratta le restrizioni
>> (constraint)
>> 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
adrianomeis03@gmail.com 11 Dic 2014 22:32
sei stato molto disponibile.

grazie,

Adriano

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Problematiche relative alla gestione di Database | Tutti i gruppi | it.comp.software.database | Notizie e discussioni software database | Software database Mobile | Servizio di consultazione news.