PDA

Visualizza versione completa : Progettazione Database


gkcuvb
18-08-2004, 10.52.55
Devo progettare un database che verrà poi gestito da VB. Il mio problema è il seguente:
Ho tre insiemi : Reclami, NC, Azioni
e le seguenti relazioni
-Un reclamo può generare una o nessuna NC
-Ad una NC può essere associato nessuno, uno o più reclami
-Una NC può generare nessuna, una o più azioni
-Una Azione può essere associata ad una sola NC
-Un'azione può essere associata a uno o più reclami
-Ad un reclamo possono essere associate nessuna,una o più azioni

L'unica conclusione che riesco a raggiungere è che Reclami , NC e Azioni mi formerranno tre tabelle distinte, ma come posso fare per memorizzare le relazioni fra i tre insiemi?
:confused:

The_Prof
18-08-2004, 12.32.08
Se non hai mai partecipato a corsi in aula oppure interattivi sulla Progettazione basi dati relazionali, la vedo molto dura.

Dal momento che non posso indicarti la soluzione ottimale finale, posso suggerirti alcune cose.
Devi partire dai dati elementari in tuo possesso, e relazionarli tra di loro, osservando se le relazioni sono 1 a 1 , 1 a molti , in pratica se le corrispondenze sono iniettive o biiettive.
Per ogni tabella che decidi di creare devi decidere quale dato o combinazioni di dati sono candidati ad essere chiave principale ed eventualmente chiave esterna che fa riferimento ad una chiave primaria di un'altra tabella.
Devi evitare la ridondanza di dati omogenei su piu' tabelle.
Come detto sopra per le chiavi esterne, devi preoccuparti dell'integrita' referenziale.
Come ultima cosa dovresti preoccuparti di creare opportunamente gli indici secondari, per una maggior velocita' di accesso alla base dati.

P8257 WebMaster
18-08-2004, 19.03.40
Il Prof ha naturalmente ragione,
la progettazione è una fase molto difficile e complessa e bisogna avere almeno un minimo di conoscenza di base oltre che eseperienza se si ha a che fare con database o grandi strutture e quantità di dati da gestire..

E' importante progettare il tutto in modo chiaro, efficiente e coerente.. Efficienza, coerenza e chiarezza sono almeno 3 cose fondamentali di cui tener conto, sia per lo sviluppo dell'applicazione che per i successivi "step" o le successive generazioni di applicativi che faranno capo alla stessa base dati..

A questo scopo esistono molti software professionali dedicati, in particolare ErWin e Rational Rose (per java o per Visual Studio), essi forniscono supporto per il disegno di diagrammi con supporto di codice, inoltre Rational Rose offre un ventaglio più ampio di servizi...

Cominciare ad apprendere l'uso di un tool di questo tipo può rappresentare un punto di inizio .. anche se si rischia di entarre "dalla porta di servizio".

Bye :cool:

Eteria
19-08-2004, 03.50.05
Preparati il database con Access (con le relazioni che vuoi tu) e poi con VB ci disegni solo l'interfaccia grafica che aziona le query e applica le modifiche che ti interessano. Access si integra benissimo con VB ed ha un interfaccia veramente comoda per sti tipi di lavoro.

LoryOne
19-08-2004, 13.44.52
La prima cosa da fare è sicuramente quella di definire quante tabelle utilizzare e quali sono le relazioni che le legano tra loro.

La seconda cosa da fare è definire la struttura di ogni singola tabella e definire le chiavi primarie. Access consente di definire una sola chiave primaria, anche se è possibile crearne altre attraverso l'impostazione della proprietà "Accetta duplicati"

La terza cosa da fare è impostare le relazioni tra tabelle in modo da ottenere l'integrità dei dati.

E' importante ricordare che qualora all'interno di una tabella vi sia la necessità di riportare un valore presente in un' altra, tale valore è cosigliabile sia numerico.

gkcuvb
19-08-2004, 15.22.10
Capisco che il problema sia un po' troppo ampio per essere trattato su un forum.....provo a precisare quale è la mia idee e quale sia il mi dubbio.
Pensavo di creare tre tabelle : Reclami, NC, Azioni.
Poi seguendo le regole di normalizzazione penso che dovrei tirare fuori altre tre tabelle di relazione : una per la corrispondenza fra NC e Reclami, una per quella fra Nc e Azioni e una per quella fra Reclami e Azioni. La mia domanda è la seguente: dato che il flusso dei dati è Reclamo-> genera->NC->genera->Azione e che quindi un azione può essere associata ad un reclamo tramite la sua NC, non rischio di fare confusione usando tre tabelle? Se ne usassi una sola con tre campi (codiceReclamo,codiceNC,codiceAzione) oppure una tabella con due campi che contengono il codice dei due oggetti relazionati e un campo aggiuntivo che indica il tipo di relazione (per esempio relazione fra NC e Azione, relazione fra Reclamo e NC)?
Che ne dite?

The_Prof
19-08-2004, 16.04.04
Originariamente inviato da gkcuvb
Capisco che il problema sia un po' troppo ampio per essere trattato su un forum.....provo a precisare quale è la mia idee e quale sia il mi dubbio.
Pensavo di creare tre tabelle : Reclami, NC, Azioni.
Poi seguendo le regole di normalizzazione penso che dovrei tirare fuori altre tre tabelle di relazione : una per la corrispondenza fra NC e Reclami, una per quella fra Nc e Azioni e una per quella fra Reclami e Azioni. La mia domanda è la seguente: dato che il flusso dei dati è Reclamo-> genera->NC->genera->Azione e che quindi un azione può essere associata ad un reclamo tramite la sua NC, non rischio di fare confusione usando tre tabelle? Se ne usassi una sola con tre campi (codiceReclamo,codiceNC,codiceAzione) oppure una tabella con due campi che contengono il codice dei due oggetti relazionati e un campo aggiuntivo che indica il tipo di relazione (per esempio relazione fra NC e Azione, relazione fra Reclamo e NC)?
Che ne dite?

Se accenni alle regole di normalizzazione, forse conosci la tecnica ed i teoremi per passare alla prima, seconda, ecc. forma normalizzata.

Come ti ho gia' detto devi elencare tutti i dati elementari e con le tecniche di cui sopra scegliere i candidati per la chiave primaria.
Gli altri dati potremmo definirli attributi del campo chiave.
Devi porre attenzione che i dati attributo non siano presenti su piu' tabelle con lo stesso significato per evitare ridondanza di informazioni.

Gli unici dati che devono essere ripetuti (sotto forma di codice numerico come giustamente affermato da Loryone) sono i dati candidati ad essere Primary key e Foreign key.

Soltanto dopo si decide quante tabelle dati e quanti indici creare.
Ciao :)

gkcuvb
19-08-2004, 17.19.42
Caro prof, con tutto il rispetto parlando, la tua risposta è carica di teoria e buoni consigli ma povera di consigli pratici (ma fai veramente il professore nella vita?). Capisco, come ho precedentemente scritto, che il problema è un po' vasto, ma non sopporto che mi si tratti come chi scrive e non sa bene nemmeno quello che dice. Ho già individuato le mie chiavi primarie e da quanto scritto nel mio primo post è evidente che le mie sono relazioni molti a molti, quindi secondo le regole di normalizzazione (che ho accuratamente letto) dovrei creare tre tabelle che preciso:

tabella :XREF_AC_RC (relazioni fra Azioni e Reclami)
Campi : ID,IDReclamo, IDAzione

Tabella :XREF_AC_NC (relazioni fra Azioni e NC)
Campi : ID,IDNC, IDAzione

Tabella :XREF_RC_NC (relazioni fra Reclami e NC)
Campi : ID,IDReclamo, IDNC

La mia domanda è la seguente: sono valide le due seguenti possibilità?

1)Invece di tre tabelle fare una tabella
XREF_AC_NC_RC con i seguenti campi ID, ID1,ID2,TIPORELAZIONE
ossia in id1 e id2 (che sono i campi estranei , vedi che qiualcosina so di questa "materia") e in TIPORELAZIONE specificare quale è la relazione

2) Fare una tabella con tre campi estranei IDreclamo, IDNC,IDAzione

Ti pare che abbia capito che le informazioni non devono essere ridondanti? :rolleyes:

Spero di essere stata più chiara

The_Prof
20-08-2004, 10.15.33
Originariamente inviato da gkcuvb
Caro prof, con tutto il rispetto parlando, la tua risposta è carica di teoria e buoni consigli ma povera di consigli pratici (ma fai veramente il professore nella vita?). Capisco, come ho precedentemente scritto, che il problema è un po' vasto, ma non sopporto che mi si tratti come chi scrive e non sa bene nemmeno quello che dice. Ho già individuato le mie chiavi primarie e da quanto scritto nel mio primo post è evidente che le mie sono relazioni molti a molti, quindi secondo le regole di normalizzazione (che ho accuratamente letto) dovrei creare tre tabelle che preciso:

tabella :XREF_AC_RC (relazioni fra Azioni e Reclami)
Campi : ID,IDReclamo, IDAzione

Tabella :XREF_AC_NC (relazioni fra Azioni e NC)
Campi : ID,IDNC, IDAzione

Tabella :XREF_RC_NC (relazioni fra Reclami e NC)
Campi : ID,IDReclamo, IDNC

La mia domanda è la seguente: sono valide le due seguenti possibilità?

1)Invece di tre tabelle fare una tabella
XREF_AC_NC_RC con i seguenti campi ID, ID1,ID2,TIPORELAZIONE
ossia in id1 e id2 (che sono i campi estranei , vedi che qiualcosina so di questa "materia") e in TIPORELAZIONE specificare quale è la relazione

2) Fare una tabella con tre campi estranei IDreclamo, IDNC,IDAzione

Ti pare che abbia capito che le informazioni non devono essere ridondanti? :rolleyes:

Spero di essere stata più chiara

Mi scusi se per un attimo ho dubitato delle sue capacita' :D

La mia personalissima soluzione potrebbe essere questa :

Tabella_reclami
Cod_reclamo (Primary key)
id1, id2, ecc.

Tabella_NC
Cod_NC (Primary key)
Cod_reclamo (Foreign key su tabella_reclami)
id1 , id2, ecc.

Tabella_azioni
Cod_azione (Primary key)
Cod_NC (Foreign key su tabella_NC
Cod_reclamo (foreign key su Tabella_NC)
id1 , id2 , ecc.
Naturalmente i campi che ho indicato come id1 id2 sono i dati di pertineza dei codici Primary Key.

Cio' permette la referential integrity sulle tabelle.
Da valutare attentamente in fase di create table l'inserimento dell'opzione Delete on Cascade per evitare che il delete di una riga esegua il delete delle righe di riferimento della foreign key.

La craezione di opportuni indici secondari, dipende dal prodotto DB2 installato, nel senso di un accesso ottimale alle tabelle scelto dal DB2.

Certo di averLe fatto cosa gradita, Le porgo i piu' distinti saluti.

p.s. La creazione di una sola tabella come ovvio genera duplicazioni di dati, ma forse questa osservazione per Lei è ovvia.

Ciao ;)

gkcuvb
20-08-2004, 11.42.41
Mi scusi caro Prof, ma se due reclami distinti sono associati alla stessa NC (vedi 2 punto del mio primo messaggio), questo non comporta che nella tabella_NC ho due record completamente identici con solo il campo idReclamo diverso? Questa non si chiama ridondanza dei dati?

The_Prof
20-08-2004, 12.01.14
Originariamente inviato da gkcuvb
Mi scusi caro Prof, ma se due reclami distinti sono associati alla stessa NC (vedi 2 punto del mio primo messaggio), questo non comporta che nella tabella_NC ho due record completamente identici con solo il campo idReclamo diverso? Questa non si chiama ridondanza dei dati?

Dai ritorniamo seri (F) (F)
Dovresti spiegarmi cosa signica NC

gkcuvb
20-08-2004, 12.54.04
Una NC è una Non Conformità (in termini di Sistema di Qualità), ma indipendententemente da quello che è o non è...a noi interessano gli insiemi e le relazioni fra di essi,giusto? Bene, come già scritto nel mio primo messaggio, gli insiemi sono tre Reclami, Non Conformità e Azioni Correttive. Le relazioni sono le seguenti:

-Un reclamo può generare una o nessuna NC (1 a molti)
-Ad una NC può essere associato nessuno, uno o più reclami(1 a molti)
-Una NC può generare nessuna, una o più azioni (1 a molti)
-Una Azione può essere associata ad una sola NC (1 a 1)
-Un'azione può essere associata a uno o più reclami (1 a molti)
-Ad un reclamo possono essere associate nessuna,una o più azioni (1 a molti)

Un reclamo può essere associato ad un azione anche senza la NC; nel caso in cui un reclamo sia associato ad una NC l'associazione con le azioni è data dalla NC.

La mia domanda è : per quanto riguarda le relazioni, devo necessariamente fare tre tabelle? Non posso fare in modo di farne meno? e poi COn tre tabelle non rischio di perdere qualche legame fra gli insiemi?

The_Prof
20-08-2004, 13.21.33
Un reclamo può generare una o nessuna NC (1 a molti)
Questa non e' una relazione 1 a molti.

Il fatto che un reclamo possa non generare una NC , ti puo' permettere di inserire tutti i dati NC nella tabella azioni, oppure ricorrendo ad un artificio, definire un codice NC particolare che indica assenza di NC.
La faccenda dell'integrita' referenziale dipende dal prodotto DB2.

Ciao :)

P8257 WebMaster
20-08-2004, 16.33.42
Più tabelle si usano e più la coerenza viene mantenuta nell'integrità dei dati, quando si cominciano ad usare artifizi è sempre male (imho).

Bye :cool:

gkcuvb
20-08-2004, 17.32.23
Grazie prof, questa è un'osservazione davvero interessante quindi nella tabella Reclami aggiungo una chiave estranea IDNC e poi uso due tabelle XREF_AC_RC e XREF_AC_NC.
DIrei che così può andare,no?

The_Prof
20-08-2004, 18.04.27
Originariamente inviato da gkcuvb
Grazie prof, questa è un'osservazione davvero interessante quindi nella tabella Reclami aggiungo una chiave estranea IDNC e poi uso due tabelle XREF_AC_RC e XREF_AC_NC.
DIrei che così può andare,no?

Di solito nella fase di normalizzazione dei dati il fatto che manchi una relazione 1 - 1 o 1 - molti, puo' dar maledettamente fastidio.
Il fatto di creare un codice dummy NC, con il significato di assenza, permette di ottenere sempre la relazione 1 - 1 e solo quella.

Quelle due tabelle che mi indichi sono le tabelle dati che conterranno in futuro cio' che verra' inserito dagli utenti dell'applicazione, o sono delle tabelle di relazioni tra oggetti, cioe' tabelle gestionali ad uso esclusivo dell'applicazione, e che non sono gestite da tutti gli utenti, ma solo da coloro che manutengono l'applicazione ?

Per farti un esempio, supponiamo di avere una tabella conti_correnti e una tabella dei CAP.
La prima tabella viene acceduta da tutti gli utenti tramite gli applicativi, mentre la tabella CAP associazione tra CAp e citta', viene usata solo dagli applicativi per il controllo che il cap sia corretto e viene aggiornata da un ufficio centrale.

Ciao :)

gkcuvb
23-08-2004, 09.47.51
Le due tabelle XREF sono tabelle utilizzate per le relazioni fra i dati inserite dall'utente. Che ne dici può andare?

The_Prof
23-08-2004, 10.39.08
Direi di si, poi naturalmente saranno i test approfonditi a determinare la qualita' e la bonta' della struttura.

Ciao :)

gkcuvb
24-08-2004, 09.42.45
Bene, grazie mille prof, penso che abbiamo fatto proprio un buon lavoro! HO sviluppato le routine di insrimento modifica e ricerca e direi che il tutto è ben gestibile. Grazie ancora

The_Prof
24-08-2004, 09.49.08
Originariamente inviato da gkcuvb
Bene, grazie mille prof, penso che abbiamo fatto proprio un buon lavoro! HO sviluppato le routine di insrimento modifica e ricerca e direi che il tutto è ben gestibile. Grazie ancora

Di nulla (F)

pazzokramaz
31-08-2004, 16.57.18
gia ragazzi

pure io devo fare un database !!!!!!


deve funzionare su office !!!...

kuakuno mi dice che software devo usare ??? che programma di office ???

procurarmi office x me nn è un prob .. il prob è che non ho mai usato 1 versione di office !!!! :D:D uso wor :D:D

raga basta cmq che mi dite kuale prog di office poi ci penso io ;) nel giro di poki giorno lo sapro usare...

grazie ciao ;)

The_Prof
31-08-2004, 17.20.23
Microsoft Access.

pazzokramaz
31-08-2004, 21.56.57
ok ;) grazie ;)