Come progettare e normalizzare al meglio un DB SQL Server 2005 partend...

martedì 23 ottobre 2007 - 11.25

roddik1980 Profilo | Junior Member

Buongiorno a tutti, complimenti per il forum molto interessante e ricco di siggerimenti utili.

Non sono molto esperto nella progettazione e normalizzazione dei database, per questo ho aperto questo thread, al fine di poter ricevere importanti consigli in merito come già successo per altri thread da me aperti.

Veniamo al problema:
devo creare un "DB SQL Server 2005" partendo da un FileFlat .txt che contiene tutti i campi (circa 40) / informazioni che mi servono.

I record sono tutti univoci.

Vorrei normalizzarlo e progettarlo al meglio creando tante tabelle e relazioni perchè successivamente dovrò farvi sopra delle query e dovrò collegarvi una applicazione ASP.net 2.0 ecc.......
Ho "pensato" di fare così, ditemi per favore se secondo voi è la soluzione giusta / corretta oppure se avete consigli da darmi:

Steps:
A) Ogni volta che ho i dati aggiornati (ogni settimana) utilizzando una procedura molto semplice ed immediata creata con SSIS (SQL Server Integration Services) importo tutto il FileFlat.txt in una tabella del DB ("DatiTXT") e lavoro su questa tabella per creare e popolare le tabelle finali; questo perchè non mi piace (non mi sento sicuro) lavorare direttamente su un file.txt ! Non mi costa nulla (ho già provato) svotare la tabella ed importare ogni volta il fileflat.txt !

B) La tabella principale ("AnagraficaArticoli") contiene vari campi tra cui un "CodArticolo" univoco (alfanumerico, VARCHAR) = forse la imposterò come chiave primaria ??? e un "ID_CodArticolo" univoco (numerico, INT) anch' esso chiave primaria che creo io tramite un "contatore" in fase d' import del file flat; faccio questo perchè penso sia più affidabile e stabile una "chiave primaria di tipo INT" che di tipo "VARCHAR" ! Per favore dimmi se mi sbaglio....
La tabella "AnagraficaArticoli" conterrà i seguenti campi (sono tutti tipi VARCHAR (alfanumerici) tranne ID_CodArticolo che è INT; cercherò sicuramente in futuro di migliorare i nomi rendendoli il + parlante possibile e + corti se possibile):

ID_CodArticolo = CHIAVE PRIMARIA
CodArticolo = CHIAVE PRIMARIA ??? (forse la metterò in abbinamento all' ID_CodArticolo, cosa ne dite ?)
Descrizione
Costo
PesoNetto
Volume
QuantitaMinimaAcquistabile

Tutti i campi provengono da "DatiTXT".

C) Creo (solo la prima volta) e popolo tutte le altre tabelle tramite pacchetto SSIS raggruppando i valori, per esempio:
Tabella "TipoArticolo" conterrà i seguenti valori univoci ricavati dalle colonna TipoArticolo...... della tabella "DatiTXT" utilizzando il GROUP BY o il DISTINCT nella query di INSERT:

ID_TipoArticolo = CHIAVE PRIMARIA (è sempre il solito campo contatore che mi creo io in fase d' insert)
TipoArticolo
Descrizione

Tabella "GruppoArticolo" conterrà i seguenti valori univoci ricavati dalle colonna GruppoArticolo..... della tabella "DatiTXT" utilizzando il GROUP BY o il DISTINCT nella query di INSERT:
ID_GruppoArticolo = CHIAVE PRIMARIA (è sempre il solito campo contatore che mi creo io in fase d' insert)
GruppoArticolo
Descrizione

Tabella "Gerarchia" conterrà i seguenti valori univoci ricavati dalle colonna Gerarchia...... della tabella "DatiTXT" utilizzando il GROUP BY o il DISTINCT nella query di INSERT:
ID_Gerarchia = CHIAVE PRIMARIA (è sempre il solito campo contatore che mi creo io in fase d' insert)
Gerarchia
Descrizione

Tutte queste tabelle del punto "C" potrei anche non svuotarle / ricaricarle totalmente ogni volta; volendo potrei inserire ad ogni aggiornamento solo i nuovi valori. Ma questo per ora è un problema secondario !

E così via per tutte le altre tabelle........

D) Ora creo una tabella che chiamerò "RELAZIONI" all' interno della quale inserirò ogni "ID_CodArticolo" con in abbinamento tutti gli ID delle altre tabelle, per esempio:
ID_CodArticolo = 25 (tradotto in termini pratici per es. "0001AS-8599 = marmitta ford fiesta")
ID_TipoArticolo = 5 (tradotto in termini pratici per es. "001A-L = componente auto benzina")
ID_GruppoArticolo = 2 (tradotto in termini pratici per es. "0018894KK-LU = gruppo impianto generale")
................
................
................

D: Come popolo questa tabella "RELAZIONI" ?
R: Da "codice Vb.net tramite una routine" oppure all' interno di un pacchetto "SSIS" creo un ciclo, leggo uno alla volta ogni "ID_CodArticolo" dalla tabella "AnagraficaArticoli", lo prendo, vado a cercarlo all' interno della tabella "DatiTXT" prendo il valore del campo "TipoArticolo" lo vado a cercare dentro alla tabella "TipoArticolo" e mi faccio restituire l' "ID_TipoArticolo" che andrò ad inserire all' interno del campo " ID_TipoArticolo" della tabella " RELAZIONI"...

E così via per tutti gli altri campi !

Una volta popolata tutta la tabella "RELAZIONI" creando poi delle query potrò, partendo dagli ID, pescare nelle varie tabelle tutte le informazioni necessarie relative ad ogni mio ARTICOLO !

N.B. Non posso usare / fidarmi dei campi "TipoArticolo", "GruppoArticolo" ecc... come chiavi primarie perchè sono alfanumerici/VARCHAR e contengono simboli (-, /...). Preferisco usare un campo INT ! Magari mi sbaglio !

Secondo voi questa soluzione va bene ? Voi che soluzione adottereste ?

Grazie in anticipo a tutti e buona giornata.

Mark

lbenaglia Profilo | Guru

>A) Ogni volta che ho i dati aggiornati (ogni settimana) utilizzando
>una procedura molto semplice ed immediata creata con SSIS (SQL
>Server Integration Services) importo tutto il FileFlat.txt in
>una tabella del DB ("DatiTXT") e lavoro su questa tabella per
>creare e popolare le tabelle finali; questo perchè non mi piace
>(non mi sento sicuro) lavorare direttamente su un file.txt !
>Non mi costa nulla (ho già provato) svotare la tabella ed importare
>ogni volta il fileflat.txt !
Forse non lo sai, ma questo modo di procedere è assolutamente la prassi, quindi vai tranquillo

>B) La tabella principale ("AnagraficaArticoli") contiene vari
>campi tra cui un "CodArticolo" univoco (alfanumerico, VARCHAR)
>= forse la imposterò come chiave primaria ???
Va bene, basta che le dimensioni non siano eccessive (diciamo sotto i 15/20 caratteri).

> un "ID_CodArticolo"
>univoco (numerico, INT) anch' esso chiave primaria che creo io
>tramite un "contatore" in fase d' import del file flat; faccio
>questo perchè penso sia più affidabile e stabile una "chiave
>primaria di tipo INT" che di tipo "VARCHAR" ! Per favore dimmi
>se mi sbaglio....
Come dicevo se la colonna varchar sulla quale vuoi definire un constraint di Primary Key ha dimensioni contenute, procedi pure.

>D) Ora creo una tabella che chiamerò "RELAZIONI" all' interno
>della quale inserirò ogni "ID_CodArticolo" con in abbinamento
>tutti gli ID delle altre tabelle, per esempio:
>ID_CodArticolo = 25 (tradotto in termini pratici per es. "0001AS-8599
>= marmitta ford fiesta")
>ID_TipoArticolo = 5 (tradotto in termini pratici per es. "001A-L
>= componente auto benzina")
>ID_GruppoArticolo = 2 (tradotto in termini pratici per es. "0018894KK-LU
>= gruppo impianto generale")
Mmmmm... a che serve questa tabella?
Che schema vuoi generare? Uno star schema?
Stai definendo un datawarehouse o un database OLTP?

>Grazie in anticipo a tutti e buona giornata.
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

roddik1980 Profilo | Junior Member

>D) Ora creo una tabella che chiamerò "RELAZIONI" all' interno
>della quale inserirò ogni "ID_CodArticolo" con in abbinamento
>tutti gli ID delle altre tabelle, per esempio:
>ID_CodArticolo = 25 (tradotto in termini pratici per es. "0001AS-8599
>= marmitta ford fiesta")
>ID_TipoArticolo = 5 (tradotto in termini pratici per es. "001A-L
>= componente auto benzina")
>ID_GruppoArticolo = 2 (tradotto in termini pratici per es. "0018894KK-LU
>= gruppo impianto generale")
Mmmmm... a che serve questa tabella?
Che schema vuoi generare? Uno star schema?
Stai definendo un datawarehouse o un database OLTP?

Voglio definire un datawarehouse.
Ok, posso fare a meno della tabella "RELAZIONI" però dovrò comunque inserire gli ID nella tabella generale "AnagraficaArticoli" come avrei fatto nella tabella "RELAZIONI" altrimenti mi mancano le chiavi primarie esterne per fare le relazioni, giusto ?

>Grazie in anticipo a tutti e buona giornata.
Prego.

lbenaglia Profilo | Guru

>Voglio definire un datawarehouse.
OK, allora lo star-schema può essere la soluzione corretta.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

roddik1980 Profilo | Junior Member

Scusa, ma lo star-schema cos' è ?
Dove posso trovare delle info / tutorial ecc sullo star-schema ?

Grazie

lbenaglia Profilo | Guru

>Scusa, ma lo star-schema cos' è ?
http://en.wikipedia.org/wiki/Star_schema

>Dove posso trovare delle info / tutorial ecc sullo star-schema?
http://www.ciobriefings.com/whitepapers/StarSchema.asp

>Grazie
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

roddik1980 Profilo | Junior Member

Grazie Lorenzo per le info !

Buona giornata

Mark

roddik1980 Profilo | Junior Member

Se il "CodArticolo" fosse un campo alfanumerico di tipo VARCHAR lunghezza max 15 potrebbe essere utilizzato senza problemi come ID chiave primaria oppure ci possono esser problemi ?

Grazie

Mark

lbenaglia Profilo | Guru

>Se il "CodArticolo" fosse un campo alfanumerico di tipo VARCHAR
>lunghezza max 15 potrebbe essere utilizzato senza problemi come
>ID chiave primaria oppure ci possono esser problemi ?
Va bene, va bene
Tieni presente che più è grande il key value, meno valori staranno in una index page, più letture saranno effettuate su disco e meno efficiente sarà l'indice.
Quindi cerca di mantenerlo più piccolo possibile.

>Grazie
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5