Newsgroup: it.comp.software.database
Titolo: potreste per favore consigliarmi qualche link di progettazione database?

buongiorno a tutti, sto iniziando a studiare per imparare a progettare
qualche piccolo database, vorrei cominciare con qualche cosa di facile
e in italiano, avreste gentilmente qualche link da consigliarmi?
io ho trovato questo, introduttivo... è buono secondo voi?
http://www.phpnews.it/corsi/la-progettazione-dei-database/
Vi ringrazio anticipatamente, so che è una domanda molto generica ma
sono un po' perso di fronte all'immensità di google :)
Picchio

 io ho trovato questo, introduttivo... è buono secondo voi?
http://www.phpnews.it/corsi/la-progettazione-dei-database/
L'autore ha chiaramente una preparazione accademica (assai raffinato,
forse troppo data la circostanza, il distinguo tra relazione e
tabella); tuttavia, il capitolo sui domini dell'attributo e' da
riscrivere (il modello relazionale non si rifa' ai tipi fisici di dato);
si parla inoltre di null e chiavi auto incrementanti (killer del
buon design), cose che non insegnerei ai novizi.
Inoltre, se per adesso non lo usi, non e' necessario che tu impari
l'E/R.
bye

 ha scritto

ti ringrazio per la gentile risposta, il portafoglio lo preparo
senz'altro, l'idea dell'inglese però...
mi spaventa, soprattutto in un campo di cui sono totalmente digiuno.
In italiano ho visto molti titoli ma dato che dovrò ordinarli non hai
un consiglio anche su questo?
Spero non te/ve lo abbiano già chiesto mille volte... in tal caso mi
scuso!
ciao,
Picchio
P.S. ho letto nei thread precedenti che sei contrario alle chiavi
autoincrementanti e credo di averne
capito il perché, non ho capito invece perché sei contario ai campi
null, immagino che qualche volta
almeno si debbano usare... o no?
Ciao e grazie ancora!

 immagino che qualche volta almeno si debbano usare... o no?
Il discorso e' complesso, e non si esaurira' in breve.
Per quanto riguarda il modello relazionale, credo che i null siano
stati un errore.
Infatti, forse non tutti sanno che il modello relazionale e' andato
avanti per ben nove anni SENZA i null! Solo successivamente Codd
introdusse gli I-Mark e A-Mark, due tipi di null con diverso
significato; ormai il vaso di Pandora era scoperchiato, e ci si
accorse che alcuni null avevano un significato diverso dagli altri,
e si arrivo' ad una decina di diversi null!
Ad aggiungersi a questo problema, arrivo' l'Sql, che miscelava
il significato di "valore non presente" con "sconosciuto", portanto
inoltre il tutto al livello logico, ed aggiungendoci varie
incongruenze; ossia, dove prima ti aspettavi una logica a due
valori, improvvisamente ne appare una a tre, E VICEVERSA, talvolta.
Ma il problema finale, come puntualizzato da C.Date, e' che la 3vl
e' inadatta a rappresentare la realta'. Col tempo ci si rese conto
di vari problemi, ed oggi si ritiene che i null siano stati uno dei
piu' grandi errori.
Per quanto riguarda l'insegnamento, i null portano lo studente a
non normalizzare correttamente lo schema, in quanto usato spesso
come comodo escamotage per fondere piu' tabelle.
Ma... c'e' un ma... i null sono dannatamente comodi :-(
Il discorso dei null non va cestinato completamente, ma andrebbe
profondamente rivisto, togliendolo dallo strato logico, e
lasciandolo solo come segnaposto temporaneo; ad ogni tentativo di
computarne il valore, bisogna restituire un errore, perche' il
null NON E' UN VALORE.
bye

 null NON E' UN VALORE.
Visto che te ne intendi di basi di dati, come consigli di bypassare il
problema dei null? Possibili soluzioni che mi vengono in mente:
- prevedere sempre un valore di default, da usare quando non viene
specificato esplicitamente un valore;
- gestire i dati che teoricamente possono essere null, con tabelle
specifiche (ad esempio, se il campo "telefono" del cliente può essere
null, gestisco un'apposita tabella "clienti_telefoni" nella quale
inserisco una tupla solo quando conosco il numero di telefono);
-- 
David Martin

 inserisco una tupla solo quando conosco il numero di telefono);
Ma a quel punto potresti avere infiniti numeri di telefono per
cliente (a meno di non forzare la cardinalita' della tabella), il
che rappresenta un vincolo differente rispetto al richiedere una
singola istanza di ogni attributo per tupla.
Questo va contro ad un motivo fondamentale per cui usiamo set di
istanze di uno stesso predicato: avere la garanzia di risposte.
Nel ns. esempio, ciascun cliente DEVE avere 1 telefono (il che
puo' essere considerato un constraint come un altro, se vogliamo).
C'e' un'intera classe di dbms che rappresentano i null come insieme
vuoto; sono i multivalued db; ogni attributo puo' essere opzionale,
oppure avere un numero infinito di valori.
Il discorso dei null comincera' ad andare solo dopo che si decidera'
quanto segue:
1) No 3vl
2) Null fuori dalla logica di calcolo
Se io faccio a + b + c, ed uno di questi e' null, il programma
DEVE INTERROMPERE l'esecuzione e sollevare un'eccezione con obbligo
di trattamento, altrimenti il programma deve chiudersi in errore.
Ma purtroppo c'e' tutta una corrente di pensiero per cui "The Show
must go on" costi quel che costi...
bye

 ha scritto:


>puo' essere considerato un constraint come un altro, se vogliamo).
bye