Newsgroup: it.comp.lang.visual-basic
Titolo: database relazionati

Buongiorno a tutti
E' da poco tempo che ho iniziato a programmare in vb5
e nell' affrontare l' argomento database non mi e' chiaro il concetto di
database relazionato, quello che mi chiedo e' una tecnica di
programmazione particolare oppure e' altro ?
Inoltre vorrei chiedere : gli
indici nei database bisogna usarli per forza oppure se ne puo' fare a meno
? Se non si usano cosa comporta ?
Vi ringrazio anticipatamente
--------------------------------
Inviato via 
http://usenet.iol.it

 ha scritto nel messaggio
news:192Z106Z52Z2Y1...@usenet.iol.it...


 ? Se non si usano cosa comporta ?
Il discorso č molto lungo (ma per nulla complesso).
I DB relazionali sono un particolare tipo di DB (e oramai lo sono quasi
tutti), che operando con piů tabelle, sono in grado di combinare i risultati
di n tabelle applicando delle regole (appunto di referenza) scelte
dall'utente e variabili in base alle esigenze.
Definizione un po' scarsa e magari contorta .. ma spero tu abbia capito
ugualmente.
Gli indici sono tabelle particolari (non accessibili direttamente) che
contengono informazioni in merito ad un set di informazioni.
Esistono indici per le tabelle di un DB, per i record di una tabella ecc..
In base al loro impiego, rendi estremamente veloci le funzioni di ricerca a
scapito di quelle di aggiornamento.
Non sei costretto ad utilizzarli perň č buona norma sfruttarli il piů
possibile.
Saluti

Prima di tutto si dice Database relazionale e non relazionato.
Ti conviene comprarti un libro su come funzionano i database, entity relation,
ecc...
-- 
Posted from  [217.57.33.234] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

identificativi di record.
A dire il vero si chiamano relazionali non
perchè usano indici, ma perchè esistono relazioni che legano le tabelle tra
di loro.
Un database ben fatto dovrebbe seguire le regole di
normalizzazione (non solo a dire il vero).
Normalizzare un database vuol
dire che gli stessi campi non lo riporti in ogni tabella in cui li usi, in
questo modo avresti una ploriferazione di informazioni, sempre le stesse,
che ai fini pratici non ha nessun effetto positivo :)
Creando una
relazione riesci ad ovviare a questo problema. Le relazioni tra due o più
tabelle però non hanno niente a che fare con gli indici. Infatti, le prime
si fanno per mezzo di chiavi (primary keys a cui puntano foreigns key), le
seconde invece, servono a tutt' altro.
Saluti...


Leggi la risposta di Fox, che lui i db credo li conosca bene :)
Io ti
consiglio un libro (un mattone allucinante) dal titolo 'Visual Basic 6,
guida allo sviluppatore di database'. Tralasciando che tu programmi in vb5,
li dentro comunque ci sono molti concetti generali che ti possono essere
sicuramente utili.
Saluti...


 writes:
s> questo modo avresti una ploriferazione di informazioni, sempre le stesse,
s> che ai fini pratici non ha nessun effetto positivo :)
Puoi averli gli  effetti positivi in fatto di  prestazioni. Una cosa è
il mondo della lavagna, una cosa  è il mondo reale dove i dischi hanno
i loro bei tempi di seek.
Un'altro vantaggio della non normalizzazione  è che se hai una tabella
anagrafica  su cui  non hai  il  controllo (vista  su un  altro DB  di
un'altra  applicazione   che  ti  tocca  usare)   puoi  mantenerti  un
informazione  di  storico  completa  nelle tabelle  che  hanno  valori
perscati dalla tabella anagrafica.
-- 
Gian  | main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Uberto|                        David Korn, 1987 ioccc best one liner 
Lauri |-------------------------------------------------------------------
(aka saint) >>Vedere X-Nospam nell'header - See X-Nospam field in Header<<


Un ulteriore uso di campi ridondanti è quello di permettere di definirne la
specificità di contesto:
per es. altro è scrivere solo il codice cliente nella testata bolle e altro
è trasferire nella testata bolle tutti quei dati che, pur essendo
generalmente ridondanti possono nichiedere nel contesto specifico di essere
modificabili.
ciao
ugo


Il discorso sulla normalizzazione io lo definisco alquanto astratto.
Se normalizzare vuol dire rendere le relazioni omogenee ed evitare le
ridondanze, concordo con le tue parole.
Ma nella realtà dei fatti, succede a volte che duplicare i dati, magari sia
l'unico metodo per ottenere accessi più veloci in lettura (applicazioni
Time-Critical)
Se poi ci vogliono alcuni secondi per eseguire un aggiornamento perchè si
riflette su più tabelle, non è necessariamente un problema.
Dipende sempre dallo scopo dell'applicazione.
Saluti

perscati dalla tabella
anagrafica.
Non sempre la strada più corta è la migliore :)
A me hanno
insegnato ad usare un metodo valido, se il metodo è chiaro e fatto bene,
allora anche le prestazioni non lo so quanto sono così deludenti.
Per quel
che ho letto io, non ho mai sentito di un libro che elogi i metodi della
non normalizazione di un db. E' logico che io parlo per la mia esperienza
che, non è di certo decennale :)


essere modificabili.
E bhè, in un caso del genere te che
faresti? Ammettiamo che hai una tabella chiamata angrafica clienti composta
da:
CD_CLIETE
DS_NOME
DS_COGNOME
...
e un altra tabella dove
risporti questi stessi campi per comodità, perchè in effetti ne fai uso, e
vuoi averli li a aportata di mano, ok. Fai una query, io sono un utente e
tramite un campo di ricerca tiro su un record. Visualizzo il cliente Mario
Rossi, e mi accorgo che il suo cognome l' ho scritto male. Che fai? Me lo
fai cambiare solo qua, lasciandolo sbagliata di sicuro la tabella
anagrafica? Questo sarebbe un errore...oppure per essere sicuro che in
tutto il db, il tuo mario rossi venga modificato correttamente, devi
lanciare una serie di update, o select per prendere quello che ti serve e
fare dei lavori.
Bhè, io preferscio fare una join su un campo codice, che
si solito è una sequence, e quindi pure veloce da ricercare, piuttosto che
lanciare 50 sql per aggiornare tutti i mario rossi.
I db relazionali sono
stati inventati proprio per ovviare a questi tipi di problemi.


Dipende sempre dallo scopo
dell'applicazione.
Si, ma come non attacchi le connessioni a un
datacontrol (che non hi mai usato...magari manco si chiamano così)
impostandogli la sua proprietà in fase di design, un db lo pensi anche un
minimo strutturato...ma non perchè lo dico io, ma perchè è più comodo :)


 Dipende sempre dallo scopo dell'applicazione.
Perfetto! :-)

di loro.
Falso.
I database relazionali non si dicono relazionali perche'
esistono relazioni tra tabelle, al contario di quanto si
potrebbe pensare.  Si dicono relazionali proprio perche' si
basano sulle tabelle, che secondo la teoria originale
formulata da E.F.Codd non sono altro che "relazioni".
Il concetto di "relazione", come legame *tra* le tabelle non
c'entra nulla col termine "relazionale".
-- 
The Follet

 c'entra nulla col termine "relazionale".
Esatto!
In realtà ciò che noi chiamiamo "relazione" nel modello teorico si chiama
"associazione"... dunque le "associazioni fra relazioni" si denotano
comunemente con l'espressione "relazioni fra tabelle"... che casino!
E in inglese? Le relazioni, cioè le tabelle, si chiamano "relations" (ma, al
solito, nella pratica comune sono le "tables") e le associazioni si chiamano
"relationships".
Uff!...
Ciao,
Carlo.

non normalizazione di un db.
La teoria non puo' coprire tutti i casi pratici e cio' che
viene insegnato e' cio' che va bene la maggior parte delle
volte.   Non sempre e' cosi' e i casi in cui non e' cosi'
possono essere moltissimi.  Tra l'altro, considera che la
teoria arriva a definire 4 livelli di normalizzazione, ma il
quarto livello, nella pratica, non e' quasi mai facilmente
gestibile e quindi quasi mai viene raggiunto.
-- 
The Follet