Newsgroup: it.lavoro.informatica
Titolo: come si traduce questo brano  in inglese?

A relationship in a sql server database is a logical link between 2 
tables.It's impossible to have a physical link.
To have a physical link would mean the actual data linking the 2 tables 
would be stored only once in a central location,and that information within 
the keys linking the tables would be stored more than once,which is just not 
the case.
 
 
Grazie e ciao
 
 
 


Una relazione in un database sql server e' un legame logico tra due
tabelle. E' impossibile avere un link fisico.
Avere un link fisico vorrebbe dire che i dati che legano le due
tabelle sono depositati un' unica volta in un punto centrale e che l'
informazione nelle chiavi che legano le due tabelle e' registrata piu'
di una volta, e non e' certo questa la situazione...
(si riferisce al fatto che la freccina che lega le tabelle nel
diagramma del DB ha valore logico/simbolico..)
Beginning Sql Server 2012? :) Fai bene a leggere libri in inglese ma
se hai gia' probs su questo la vedo dura... ma non ti dare per vinto,
leggere libri di info in inglese "it's the only way"! :)


 
Si capisce una sega in inglese, ancora meno in italiano...
 

<Una relazione in un database sql server e' un legame logico tra due
<tabelle. E' impossibile avere un link fisico.
 
<Avere un link fisico vorrebbe dire che i dati che legano le due
<tabelle sono depositati un' unica volta in un punto centrale e che l'
<informazione nelle chiavi che legano le due tabelle e' registrata piu'
<di una volta, e non e' certo questa la situazione...
 
sě letteralmente capisco la traduzione,ma dal punto di vista pratico non 
capisco l'osservazione dell'autore...quella di registrare piů volte i 
dati...
 
<<<Beginning Sql Server 2012? :)
 
sě...anche se ho trovato la versione  sql server 2008
 
ciao 
 
 

dati...
 
Probabilmente vuol dire che se hai una relazione tra la tabella
"impiegato" e la tabella "mansione", il risultato di una query che ti
tira fuori quali sono le mansioni di tutti quelli che si chiamano
"Mario" e' immateriale.
 
Se invece il legame fosse fisico, avresti una tabella in piu' da
conservare da cui estrarre i dati con ridondanza di informazione.
 
Quando dice che "e' impossibile", andrebbe letto come "non e'
consigliabile" se vuoi rispettare le forme normali.
-- 
Living in Barbaropoli
http://www.barbaropoli.com
 

 Si capisce una sega in inglese, ancora meno in italiano...
 
Si capisce una sega?!?
 
Strano, a meno che tu non abbia mai avuto a che fare con database relazionali.
 
-- 
Ciao!
Luca

 dati...
 
E' uno dei principi base della teoria relazionale: i dati non vanno mai duplicati (aggiungerei: inutilmente).
 
In buona sostanza: se io metto in relazione due tipi di dato, i dati risultato di questa relazione di fatto non esistono se non in modo logico, e vengono computati solo nel momento in cui vengono richiesti; fare altrimenti comporta la creazione di una tabella apposita per ogni relazione, con il risultato di duplicare inutilmente i dati.
For the record: a volte capita che il principio generale venga derogato, usando tecniche adeguate, e che effettivamente vengano create tabelle derivate che contengono effettivamente dati duplicati; se viene fatto, pratica comunque deprecata perché ne va della manutenibilità, lo si fa per questioni di prestazioni.
 
Capirai meglio la cosa quando arriverai alle viste logiche (che non si chiamano logiche a caso).
 
-- 
Ciao!
Luca

 consigliabile" se vuoi rispettare le forme normali.
 
Beh, a pensarci, col DBMS così come è strutturato (mi limito a SQL Server e Postgres, che conosco) è di fatto impossibile in modo diretto; per farlo, devi smadonnare non poco di trigger...
 
-- 
Ciao!
Luca


 
Guarda che questo:
"
To have a physical link would mean the actual data linking the 2 tables
would be stored only once in a central location,and that information within
the keys linking the tables would be stored more than once,which is just not
the case.
"
 
E' giusto l'opposto di quello che state pensando che invece ci sia 
scritto... :-)
Per me quei due paragrafi continuano ad essere incapibili e scritti male.
Se l'autore voleva parlare dei vincoli di chiave esterna, poteva benissimo 
usare il termine foreign key constraint che č appunto quello giusto invece 
di tirar fuori relationship e poi disquisire sul senso logico e "fisico" 
(che proprio non ho idea di che intendesse) della questione senza dire nulla 
di chiaro.
In ogni caso, per me, non ha mai parlato di duplicazione dei dati nel senso 
che gli state dando voi circa la violazione delle forme normali.
 


se tu sei davanti ad una botte piena di barolo e desideri berlo, ti 
prendi un bel tubo, immergi una estremità nella botte e l'altra te la 
metti in bocca, e cominci a succhiare.
 
Questo è un link 'logico'.
 
Se invece ti immergi nella botte e cominci a berti il barolo 'dal di 
dentro', quello è un 'link fisico' ma non è molto pratico e non si fa 
comunemente.
 
 
 
 
 
 
 

 dati...
 
Mah, cosi' a occhio e croce dovrebbe voler dire che le informazioni che ti
danno le chiavi, non sono memorizzate in modo permanente sul supporto
fisico e non avrebbe nemmeno senso memorizzarle, perche' le chiavi sono
li' apposta perche' possa essere tu, che conosci la definizione di
"chiave", a ricavare le informazioni che ti servono, anche se queste non
sono esplicitamente memorizzate sul supporto fisico (ad esempio le
informazioni potrai ricavarle a volte facendo opportunamente dei join fra
tabelle, altre volte facendo altre cose, stando attento a non dare luogo a
fenomeni di duplicazione o perdita di informazione. E per non avere
perdita di informazione devi comunque giocare sui cmpi chiave). 
 
Ciao,
Marco
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 


a me sembra una spiegazione del tipo: "gli asini si dividono in due 
categorie, quelli che volano e quelli che non volano. gli asini che 
volano hanno bisogno di grandi e possenti ali, ma siccome che non ce 
l'hanno allora non è il nostro caso".

che gli state dando voi circa la violazione delle forme normali.
 
Io quando leggo che la relazione tra due tabelle si materializza
fisicamente penso immediatamente che quello ce ha preparato il DB non
ha usato chiavi e che ha infilato nel DB una tabella in piu' che
contiene dati gia' presenti nelle tabelle esistenti, in una parola:
ridondanza.
 
Sono comunque daccordo che l'autore si sarebbe poturo esprimere in
maniera meno fumosa.


 
l'autore vuol dire questo(divido il brano ):
 
<"To have a physical link would mean the actual data linking the 2 tables
<would be stored only once in a central location,....."
 
memorizzi una volta sola centralmente  le tabelle con i dati :esempio hai 
tabella clienti e tabella ordini.
La tabella clienti contiene PIPPO ,la tabella ordini  contiene i suoi ordini 
PIPPO_O1 e PIPPI_O2 (fra gli altri ordini)
 
"...and that information within
the keys linking the tables would be stored more than once,which is just not
the case."
 
 
ma le informazioni collegate dovresti memorizzarle piů di una volta ,creando 
una struttura (tabella), esempio cosě:
 
PIPPO ----> PIPPO_O1
PIPPO ---->PIPPO_O2
 
ETC...
 
Quindi spreco di spazio,e duplicazione delle info a iosa..
 
 
 
 
 
 
 
 
 
 
 
 

 dati...
 
beh allora dovevi dire "chi me lo spiega" , non chi me lo "traduce" ,
scusa la pignoleria :)
Comunque e' una cazzata.. dice solo che il legame di relazione tra due
tabelle non e' un legame "fisico" come quello tra due classi in cui
una classe ha un puntatore (o reference che dir si voglia..) ad un'
altra.. tutto li'.. Non mi sembra il caso di arenarsi spaccando il
capello in quattro su questo dettaglio quando hai tutto il resto del
libro che ti aspetta ..:)
PS> se vuoi qualche buon libro su SQL Server ti consiglio qualsiasi
libro scritto da Itzik Ben-Gan...


 
In pratica dice questo:
In SQL Server una relazione tra due tabelle è sempre un link logico. E' 
IMPOSSIBILE (in SQL) avere un link fisico.
 
Due tabelle legate con link logico:
 
Tabella Cliente:
Codice Cliente
Nome
Cognome
...ecc
 
Tabella Sedi cliente:
Codice Sede
Codice Cliente
Indirizzo Sede
 
Poniamo un link semplice: hai un cliente con una sede. Ne consegue che 
il campo codice sarà scritto due volte: una volta nella tabella cliente, 
una volta nella tabella sedi.
Il codice cliente è salvato due volte e "linkato" in modo logico.
 
Se, per assurdo, volessi realizzare un link fisico (che, già detto, è 
impossibile, quindi siamo nell'assurdo, e la spiegazione ti serve per 
capire perchè è stata fatta la scelta di usare link logici e non link 
fisici) dovresti avere il codice cliente memorizzato una sola volta.
Questo ti farebbe risparmiare spazio per lo storage del codice cliente.
Ma dovresti avere altre due chiavi: chiave che lega la tabella cliente 
ai codici cliente, e chiave che lega la tabella sedi ai codici cliente.
 
E il libro conclude che "non è il caso" ;-)
 
 
 
 

simone pretended :

e' gia' in inglese, non c'e' bisogno di tradurlo
 
-- 
We are the music makers,
And we are the dreamers of dreams