Normalizzazione database.

turtle87crociato
Ciao.

Ragazzi, sapreste aiutarmi con questo concetto importante per la progettazione di un database?

Ho letto di dipendenze funzionali, ho letto delle tre forme normali e della forma di Boyce-Codd.

Il fatto è che quando devo mettermi all'opera, non so come ricostruire l'algoritmo da seguire (i vari passaggi, che, come si legge, sono anche concatenati). Diciamo che posso avere una vaga infarinatura dei concetti teorici, infarinatura di scarso rilievo visto che, quando mi trovo a doverli applicare, non riesco ancora a farlo.

P.s.- E' un semplice hobby, di conseguenza il mio livello poco superiore allo zero, essendomi barcamenato tra mille fonti senza riuscire ad arrivare mai al punto.
P.p.s.- Se volete, potrei postare qualche esempio pratico per vederlo insieme.

Risposte
Umby2
"turtle87":

P.p.s.- Se volete, potrei postare qualche esempio pratico per vederlo insieme.


Penso che sia la cosa migliore... ;-)

turtle87crociato
Ciao, grazie per avermi risposto.

Dunque, ho questo schema, tratto peraltro da un libro consultabile parzialmente via internet.

Lo schema vuole modellizzare una situazione in cui vi sono dei clienti che effettuano varie ordinazioni, nelle quali ordinano vari prodotti. La struttura iniziale, non normalizzata, è la seguente:

ordine (idcliente, nomecliente, indirizzocliente, idordine, dataordine, idprodotto, nomeprodotto, quantitàprodotto).

Tale schema andrebbe riportato nella terza forma normale.

Pietro_Bonf
Ciao,
per cominciare partiamo con l'identificare le chiavi estrne , nel nostro caso idcliente, idprodotto.
Poi leghiamo i campi con le chiavi
nomecliente, indirizzocliente ---> idcliente
nomeprodotto -------> idprodotto
queste diventeranno le tabelle atomiche del tuo schema
la relazione inziale è diventata
ordine(idordine, idcliente, idprodotto, quantitàprodotto, dataordine)

Umby2
Concordo con Sergio:

L'ordine andrebbe diviso in:

Testa_Ordine ( Id_Ordine, Data_Ordine, Id_Cliente .... e tutte le altre info legate all'odine nel suo complesso)

e

Rigo_Ordine ( Id_Ordine, Id_Prodotto, Quantità, Prezzo, Sconto .... e le altre info legate al singolo rigo )

Pietro_Bonf
Mi pare che lo schema di Umby sia ottimale,
aggiungerei solamente nella riga_ordine, Id_riga_ordine come chiave altrimenti dovremmo mettere ID_prodotto in chiave e
non mi sembra sia la soluzione.(Magari nell'ordine ci potrebbe essere lo stesso prodotto con quantità diverse riferite a sconti diversi)

turtle87crociato
Quindi, fatemi capire, volendo generalizzare, quali sarebbero i passi da seguire?

Non devo prima riscrivere l'unica tabella iniziale nella prima forma normale, poi nella seconda, e infine nella terza?
Le chiavi esterne non dovrebbero automaticamente venire fuori da questa suddivisione progressiva?

Io, a priori, posso solo individuare la superchiave, che sarebbe (salvo, ovviamente, errori) la terna di attributi (idcliente, idordine, idprodotto). Idprodotto è presente perchè, come faceva notare Sergio, si vuole che in un ordine possano esserci più prodotti ordinati.

Umby2
"Pietro_Bonf":
Mi pare che lo schema di Umby sia ottimale,
aggiungerei solamente nella riga_ordine, Id_riga_ordine come chiave altrimenti dovremmo mettere ID_prodotto in chiave e
non mi sembra sia la soluzione.(Magari nell'ordine ci potrebbe essere lo stesso prodotto con quantità diverse riferite a sconti diversi)


alcuni database come l'access non hanno la necessità di avere obbligatoriamente una chiave primaria univoca (in realta' ci sta sempre, ed è il contatore dei record presente nella tabella stessa).

Umby2
"turtle87":
Quindi, fatemi capire, volendo generalizzare, quali sarebbero i passi da seguire?

Non devo prima riscrivere l'unica tabella iniziale nella prima forma normale, poi nella seconda, e infine nella terza?


Non è molto efficiente creare una database, con tutte le chiave interne alla stessa tabella. Nel caso ci siano altri campi dell'ordine (immagina la data di evasione, o il luogo di consegna, o il vettore... etc etc ), andresti a duplicare tantissime informazioni. Il database in questo caso non è efficiente.
Di solito per documenti tipo "ordine" "ddt" "fattura" si preferisce sempre spezzare la parte della testata (notizie generali dell'intero ordine) con il corpo del documento (righe articoli)

turtle87crociato
Non è molto efficiente creare una database, con tutte le chiave interne alla stessa tabella. Nel caso ci siano altri campi dell'ordine (immagina la data di evasione, o il luogo di consegna, o il vettore... etc etc ), andresti a duplicare tantissime informazioni. Il database in questo caso non è efficiente.


Ma non è questo il motivo per cui, partendo dalla prima forma normale (che serve solo ad atomicizzare i domini, ma che mantiene comunque la ridondanza), si passa alle successive?

Non c'è un algoritmo che va bene per tutti i casi? Un algoritmo che permetta di realizzare le normalizzazioni in tutti i casi affrontabili?

Pietro_Bonf
Scusate non sapevo che Access fosse un Data Base serio. :mrgreen:
La chiave del dettaglio deve essere Nro_ordine, Nro_riga_ordine ovvio

Rispondi
Per rispondere a questa discussione devi prima effettuare il login.