Newsgroup: it.comp.www.php
Titolo: Quale criterio per le tabelle relazionali?

E' una domanda che mi sono posto perchè forse dovrò realizzare un sito 
che "potrebbe" essere basato su un Db composto da più tabelle 
relazionate fra loro.
Quindi chiedevo a questo Ng (che reputo uno dei più competenti in 
assoluto fra quelli che frequento) se esiste un criterio che serva per 
stabilire la cosa.
E' una questione di quantità di record immessi?
Dipende dal numero di campi?
Sto sbagliando ragionamento?
Max
-- 
Se mi volete scrivere
massimo . ori @ aliceposta . it

 
ciao
Alesi_27

 ha scritto nel messaggio
news:20031022144...@news.tin.it...

C'era un autodidattico in IBM che in termini pratici diceva di prendere
tutti i dati e metteli in una sola tabella e poi di avviare quello che si
chiama processo di normalizzazione ovvero individuare tutte le ridondanze ed
eliminarle creando altre tabelle ognuna delle quali, come già suggerito
nell'altro post, dovrebbe raggruppare i dati relativi ad una singola entità,
queste tabelle vengono messe poi in relazione fra loro tramite ID univoci,
il processo di normalizzazione troppo spinto a volte può nuocere però alle
prestazioni e alla semplicità dell'applicazione quindi poi a seconda dei
casi si potrebbe aver bisogno di un processo di denormalizzazione ovvero la
cosa inversa. In pratica certi passaggi con l'esperienza li vai a saltare e
tenendo presente i dati che hai a disposizione riesci a costruire un
database abbastanza normalizzato fin dall'inizio
Ciao

 Ciao
ciao
Alesi_27

 Alesi_27
In effetti me ne sono accorto.
Mano a mano che progetto e realizzo siti basati su Db mi sono accorto di 
un continuo miglioramento sia della parte di programmazione pura che di 
progettazione del Db stesso (comunque parliamo sempre di livelli bassini, 
non vorrei essere frainteso).
(S)Fortunatamente non ho ancora avuto la necessità di usare tabelle 
relazionate, vuoi per la piccola dimensione dei siti realizzati vuoi per 
la tipologia, ma so che prima o poi capiterà e quindi ne ho approfittato 
per chiedere un parere qui.
Grazie


 Max
Allora in questo caso ti faccio un piccolissimo esempio che può 
chiarificare le idee e far capire i vantaggi di spezzare i dati in più 
tabelle:
supponiamo che vogliamo memorizzare i nomi di un gruppo di persone, la 
loro nazionalità, e quanti abitanti ha la nazione di cui fanno parte.
qualcuno potrebbe pensare di fare una cosa tipo
persone (nome,nazione,abitanti)
come vedi però in questo caso abbiamo messo informazioni eterogenee 
nella stessa tabella, infatti il nome di una persona ha poca attinenza 
con quante persone vivono nella sua stessa nazione.
Inoltre se abbiamo
Pippo - Libia - 30'000'000
Pluto - Libia - 30'000'000
Minnie- Italia - 50'000'000
e vogliamo aggiornare il # di abitanti della Libia, dobbiamo modificare 
tutte i record che contengono Libia come nazione, aggiornando la 
popolazione al valore desiderato. Inoltre potremmo avere incongruenza 
dei dati, perchè se aggiorniamo ad esempio solo "PIPPO-LIBIA-50'000'000" 
non sapremmo più se in Libia ci sono 30'000'000 oppure 50'000'000 persone.
Allora potremmo affrontare il discorso in modo differente:
Persone (nome, id_nazione)
Nazione (id, nome, abitanti)
a questo punto abbiamo "diviso" le informazioni riguardanti le persone 
con quelle riguardanti la nazione. La relazione che c'è tra queste 2 
tabelle è che una persona appartiene ad una nazione.
PERSONE:
Pippo - 01
Pluto - 01
Minnie- 02
NAZIONE:
01-Libia-30'000'000
02-Italia-50'000'000
se vogliamo sapere in che paese vive pippo facciamo
Select N.nome from Persone as P, Nazione as N where P.id_nazione=N.id 
and P.nome='Pippo'
il database eseguirà una specie di prodotto cartesiano tra le 2 tabelle 
(restituirà una tabella con schema dato dall'unione dei 2 schemi) 
eliminando tutti i record che non coincidono sull'attributo comune 
(P.id_nazione=N.id).
Ovviamente le possibilità sono limitate solo dalla fantasia, e solo 
attraverso uno studio un pò più approfondito si scoprono piano piano tutte.
ciao
Alesi_27

 alesi_27  wrote:
Se stato chiarissimo, molte grazie.
Ora tocca e me...  ;-)
