Progettazione e Sviluppo Di Un Sistema Informativo Per La Gestione Della Distinta Base

Università degli Studi di Bologna
FACOLTÀ DI INGEGNERIA
Corso di Laurea in Ingegneria Gestionale
Sistemi Informativi
Progettazione e Sviluppo di un Sistema Informativo

per la Gestione della Distinta Base
Tesi di Laurea di: Relatore:
Michele Borghi Chiar.ma Prof. Wilma Penzo
Correlatori:
Ing. Marco Patella
Ing. Andrea Regazzi
Anno Accademico 2002-2003

Introduzione _______________________________________________10
1. LA DISTINTA BASE____________________________________15
1.1. La definizione di distinta base ______________________15

1.1.1. Una ricetta tecnica di prodotto _________________15
1.1.2. Un risultato della progettazione di prodotto _______16
1.2. Le conseguenze di errori nella distinta base ___________16
1.3. La struttura della distinta base _____________________17
1.4. La distinta base nei sistemi MRP ____________________18
1.5. Le problematiche relative alla distinta base ___________19
1.6. L’importanza della distinta base ____________________20
2. IL SISTEMA PREESISTENTE ___________________________21
2.1. Caratteristiche tecniche ___________________________21
2.2. La struttura del database __________________________22

2.2.1. Le due anime del vecchio database ______________26
2.2.2. Analisi statistica sulle tabelle __________________29
2.2.3. I risultati dell’analisi della struttura______________38
2.3. Analisi della qualità dei dati ________________________39

2.3.1. La codifica degli elementi _____________________40
La gerarchia degli elementi________________________41
I dati reali e il codice ____________________________44
2.3.2. La descrizione dei componenti _________________45
2
2.3.3. I documenti allegati__________________________46
2.3.4. Altri piccoli problemi ________________________46
2.3.5. I risultati dell’analisi della qualità dei dati ________47
2.4. Analisi delle procedure di gestione __________________48

2.4.1. La creazione di un elemento ___________________48
2.4.2. L’inserimento di una distinta___________________50
2.4.3. La revisione di un elemento ___________________53
Cos’è una revisione ______________________________53
La procedura di revisione _________________________54
2.5. Analisi dei sistemi di sicurezza ______________________55

2.5.1. La gestione dei permessi ______________________56
2.5.2. I backup e il ripristino dei dati__________________57
2.6. Analisi dell’interfaccia ____________________________57

2.6.1. L’home page _______________________________58
2.6.2. La visualizzazione delle tabelle_________________59
2.6.3. La scheda elemento __________________________60
2.6.4. La visualizzazione della distinta ________________61
2.6.5. La ricerca delle informazioni __________________61
2.6.6. L’esportazione dei dati _______________________62
2.6.7. Considerazioni conclusive sull’interfaccia utente ___63
3. IL SISTEMA DI CODIFICA______________________________64
3.1. Gli obiettivi da raggiungere ________________________64
3.2. La soluzione proposta _____________________________64

3.2.1. La funzione di analisi del codice ________________65
3.2.2. La razionalizzazione del sistema di codifica _______66
3
3.2.3. Il controllo sui dati inseriti ____________________67
3.3. La soluzione operativa: il modello di riferimento_______67

3.3.1. L’albero dei formati _________________________68
3.3.2. La rappresentazione testuale dell’albero __________69
4. LA GESTIONE DELLE DISTINTE ________________________73
4.1. I limiti del sistema preesistente _____________________73
4.2. La distinta base per Sadel__________________________74

4.2.1. Gli elementi e la distinta base __________________75
I prodotti Sadel _________________________________75
Le schede elettroniche ____________________________76
Le parti meccaniche _____________________________77
Il caso limite ___________________________________78
Gli assemblati senza distinta _______________________78
L’esplosione della distinta_________________________79
4.3. I requisiti della distinta base________________________80
4.4. La proposta operativa_____________________________81

4.4.1. La distinta base come auto-associazione __________82
4.4.2. Procedura di inserimento di una distinta __________83
5. LA GESTIONE DELLE REVISIONI _______________________87
5.1. Cosa si intende per revisione _______________________87
5.2. Gli obiettivi da raggiungere ________________________88
5.3. Gli elementi obsoleti ______________________________89
5.4. La politica aziendale delle revisioni __________________89
4
L’essenza del problema ___________________________91
5.5. L’effetto domino sulle revisioni _____________________92
5.6. Il confronto tra le due alternative ___________________94

La scelta aziendale ______________________________95
Alcuni dubbi conclusivi ___________________________96
6. LA PROCEDURA DI APPROVAZIONE ____________________97
6.1. La situazione preesistente__________________________97
6.2. Come affrontare il problema _______________________98
6.3. Il protocollo di approvazione _______________________99
6.4. I miglioramenti apportati _________________________104
7. LA GESTIONE DEI DOCUMENTI _______________________105
7.1. I documenti nel sistema preesistente ________________105
7.2. Una soluzione semplice e potente ___________________106
7.3. Obiettivi raggiunti_______________________________108
8. RICERCA E VISUALIZZAZIONE DELLE INFORMAZIONI _109
8.1. Il limite del sistema preesistente____________________110

8.1.1. La soluzione al problema dei componenti speciali _110
8.1.2. L’importazione del campo descrizione __________112
8.2. Le viste principali e la struttura delle informazioni ____114
8.3. La struttura di visualizzazione_____________________116
8.4. La ricerca ______________________________________117
5
8.4.1. La ricerca semplice _________________________117
8.4.2. La ricerca avanzata _________________________118
8.5. La progettazione operativa________________________119
8.6. Esportazione e stampa delle informazioni____________121
9. LA SICUREZZA ______________________________________123
9.1. Gestione dei permessi di accesso ___________________123

9.1.1. Gli strumenti offerti da MySQL _______________124
9.1.2. La progettazione della logica di gestione ________125
9.1.3. La gestione dei permessi _____________________127
9.2. Sistemi di prevenzione e recupero dei dati ___________127

9.2.1. Gli strumenti offerti da MySQL _______________128
9.2.2. Il file di log _______________________________128
9.2.3. La gestione dei backup ______________________130
10. IL PROGETTO DELLA BASE DI DATI ___________________131
10.1. La progettazione concettuale ______________________131

10.1.1. Lo schema E-R ____________________________131
Individuazione delle entità e delle associazioni _______132
Lo schema scheletro ____________________________133
Gli attributi e le chiavi __________________________135
Il modello completo _____________________________141
10.2. La progettazione logica___________________________142

10.2.1. Lo schema normalizzato _____________________142
10.2.2. Gli schemi di relazioni ______________________144
10.3. La progettazione fisica ___________________________145
6
10.3.1. Definizione degli attributi ____________________146
11. L’IMPLEMENTAZIONE DEL SISTEMA__________________154
11.1. Gli strumenti ___________________________________154

11.1.1. Il linguaggio PHP __________________________154
11.1.2. Il database MySQL _________________________155
Perché MySQL è meglio di Access _________________156
11.1.3. L’architettura del sistema ____________________159
11.2. La realizzazione del database______________________159

11.2.1. La creazione delle tabelle ____________________159
PhpMyAdmin__________________________________164
11.2.2. La creazione dei permessi iniziali ______________165
11.2.3. L’importazione dei dati ______________________166
Riempimento delle tabelle compatibili ______________167
L’importazione dei documenti allegati ______________168
La pulizia dei dati ______________________________170
Importazione dei componenti speciali _______________171
11.3. L’interfaccia utente ______________________________172

11.3.1. L’usabilità ________________________________172
11.3.2. La struttura di visualizzazione_________________175
Il menù di navigazione __________________________175
11.3.3. L’home page ______________________________176
11.3.4. Le viste principali __________________________177
Gli elementi ___________________________________178
I prodotti _____________________________________179
Il magazzino __________________________________180
11.3.5. La “scheda elemento” _______________________180
7
11.3.6. L’esplosione della distinta____________________181
11.3.7. La ricerca_________________________________182
La ricerca semplice _____________________________183
La ricerca avanzata_____________________________183
11.3.8. La gestione dei dati _________________________185
L’inserimento di un elemento e la codifica assistita ____186
Il controllo sui dati _____________________________188
La modifica e l’eliminazione dei dati _______________189
La gestione della distinta_________________________190
L’amministrazione dei permessi e la gestione dei backup192
11.3.9. L’esportazione e la stampa ___________________193
La stampa diretta e i CSS ________________________194
La stampa della distinta _________________________196
12. VARO DEL SISTEMA E SUA VALUTAZIONE _____________199
12.1. Come misurare i miglioramenti ottenuti _____________199

Velocità ______________________________________200
Usabilità dell’interfaccia_________________________201
Ricerca delle informazioni _______________________201
Qualità dei dati ________________________________201
Quantità dei dati contenibili ______________________202
Sicurezza _____________________________________202
Esportazione e stampa dei dati ____________________202
Stabilità del sistema_____________________________203
Costi ________________________________________203
12.2. Valutazione degli indicatori di processo _____________203

12.2.1. Numero di codici errati ______________________203
8
12.2.2. Numero di link interrotti _____________________205
12.2.3. Percentuale di errori evitati nell’inserimento _____205
12.2.4. Istanze eliminate nel passaggio al nuovo sistema __206
12.3. Il questionario __________________________________207
12.4. Valutazioni conclusive sul nuovo sistema ____________210

12.4.1. Miglioramenti ottenuti_______________________210
12.4.2. I lati negativi ______________________________211
Conclusioni_______________________________________________212
Sviluppi futuri_____________________________________________213
Bibliografia_______________________________________________214
Ringraziamenti ____________________________________________216
9
Introduzione
La progettazione e lo sviluppo di un sistema informativo per la

gestione della distinta base è il tema del presente elaborato. Il discorso
nasce dal contesto aziendale e si sviluppa su problematiche
economico/gestionali ed informatiche.
L’azienda SADEL s.r.l. di Castelmaggiore (BO), presso la quale è

stata svolta questa tesi, si occupa di progettazione, sviluppo e realizzazione
di schede elettroniche e di macchine che fanno uso di schede elettroniche.
Al fine di ottenere la Certificazione di Qualità secondo le norme ISO 9000,
l’azienda ha pensato alla realizzazione di un sistema organizzativo per la
gestione della distinta base estremamente snello e gestibile con applicazioni
informatiche.
La distinta base è la “ricetta tecnica” del prodotto ed è un documento

chiave per l’azienda di progettazione e di produzione; essa rappresenta
difatti il legame tra la fase di progettazione e la fase di realizzazione di un
prodotto, inoltre ha numerose implicazioni gestionali su diverse altre
problematiche aziendali: il magazzino, l’approvvigionamento, l’assistenza
ai clienti, la gestione delle revisioni, il sistema di codifica, la gestione dei
documenti di progetto, ecc. All’interno del contesto aziendale presso la
quale è stata svolta questa tesi, la distinta base svolge un ruolo
fondamentale: essa è il “cuore informativo” dell’azienda e da sola consente
la realizzazione di qualsiasi prodotto sviluppato in quanto comprende oltre
che i componenti per la realizzazione anche i documenti di progetto
necessari per la produzione e la realizzazione.
La situazione aziendale, e quindi le caratteristiche del sistema di

gestione della distinta base esistente, è il punto dal quale bisogna partire per
10
individuare i requisiti necessari minimi da rispettare, le problematiche
maggiori da risolvere e per studiare la struttura delle informazioni conformi
alle nuove esigenze.
L’individuazione dei requisiti minimi che il sistema dovrà soddisfare

precede un’analisi dei requisiti più approfondita relativa alle numerose
esigenze aziendali. In particolare si possono distinguere due diverse
tipologie di requisiti: requisiti gestionali e requisiti del sistema informativo.
Il primo punto debole riscontrato nel sistema preesistente riguarda la

mancanza di una verifica sui dati inseriti che ha generato numerosi errori
sui dati esistenti ed in particolare provoca gravi effetti relativi al sistema di
codifica semiparlante adottato dall’azienda: il rischio è quello di perdere la
corrispondenza tra l’elemento fisico codificato e il codice che lo
rappresenta all’interno del sistema informativo aziendale. Si rende pertanto
necessaria l’introduzione di un sistema di controllo sui dati inseriti ed in
particolare sui codici che si basi su una codifica definita in maniera
rigorosa affidata al sistema di gestione.
Un’altra delle problematiche fondamentali legate alla distinta base

riguarda la gestione delle revisioni, cioè le metodologie gestionali con cui i
prodotti cambiano di versione e di come tali cambiamenti si ripercuotono
sulla distinta base dei prodotti. In particolare, il sistema esistente ha una
gestione discutibile per quanto riguarda la reperibilità delle informazioni
riguardo le precedenti versioni dei prodotti. L’analisi dei requisiti in questo
campo impone la definizione di una metodologia di gestione delle revisioni
precisa e gestita in maniera semiautomatica dal sistema.
All’interno dell’azienda la gestione della distinta base è affidata ad

unico amministratore del sistema che ne ha la responsabilità per quanto
riguarda qualunque modifica che venga effettuata su di essa. Data
11
l’importanza della distinta base e degli elementi che la compongono, risulta
però rischioso affidare tutta la responsabilità ad un’unica persona. D’altro
canto risulta pericoloso anche concedere troppe autorizzazioni per
l’intervento sul database. La soluzione a questo problema è l’istituzione di
una procedura di approvazione che delega l’approvazione di un
componente, di una distinta o di una revisione a chi ne ha effettivamente
richiesto l’approvazione mediante uno scambio di e-mail che si instaura tra
il sistema, l’amministratore e l’utente “approvatore”.
Tra le problematiche più importanti relative alla distinta base spicca

anche la gestione dei documenti allegati. L’idea è quella di legare
indissolubilmente il documento fisico al link testuale contenuto nel
database, per assicurare una perfetta reperibilità dei documenti stessi
mediante semplici ricerche sul database ed evitare perdite estremamente
gravi.
Per quanto riguarda i requisiti a cui deve rispondere il sistema

informativo, essi si concretizzano in due grandi categorie: ricerca delle
informazioni e sicurezza. È chiaro come la visualizzazione e la ricerca delle
informazioni debbano rispettare le esigenze di interrogazione del database
da parte degli utenti. Per questo motivo oltre a due meccanismi di ricerca
(semplice ed avanzata) si rende necessario un sistema per una ricerca
dettagliata all’interno di quelle categorie di elementi più numerose e
ritenute più importanti dagli utenti, oltre a meccanismi per l’esportazione e
la stampa delle informazioni in altri formati. I requisiti relativi alla
sicurezza del sistema si possono invece dividere in due aspetti diversi:
gestione dei permessi d’accesso e sistemi di recupero dei dati. In entrambi i
casi le procedure rispecchiano le metodologie di sicurezza standard per il
database utilizzato.
12
Il naturale sbocco dell’analisi dei requisiti è la progettazione e
l’implementazione del sistema. La progettazione, come noto dalla teoria, si
suddivide in progettazione della base di dati e progettazione
dell’applicazione. La progettazione della base di dati, sviluppata secondo le
metodologie standard, ci consente di ottenere lo schema ER normalizzato e
quindi la definizione precisa delle tabelle del database. La progettazione
dell’applicazione consiste invece nella realizzazione di un programma
informatico per la gestione del database appena creato. Questo presuppone
la scelta degli strumenti di programmazione che nel nostro caso è ricaduta
su PHP (PHP: Hypertext Preprocessor) con database MySQL, entrambi
disponibili gratuitamente sul mercato e largamente utilizzate nelle
applicazioni web. Il vantaggio principale del PHP è la generazione di
pagine HTML interpretabili da un qualsiasi browser e quindi totalmente
indipendenti dalla piattaforma di utilizzo. Oltre alla programmazione
dell’applicazione bisogna prevedere metodologie di importazione, pulizia e
analisi dei dati del sistema preesistente, ed inoltre sviluppare un interfaccia
utente potente e facile da usare. L’implementazione del sistema riguarda
principalmente quest’ultimo aspetto, cioè su come far interagire l’utente col
database attraverso l’applicazione PHP, e, oltre ad implementare le
procedure definite, si scontra con numerosi ed ostici problemi relativi alla
compatibilità dei formati delle informazioni.
Il varo del sistema è l’ultimo passo nella realizzazione di un sistema

informativo ed è l’elemento che ci consente di dargli una valutazione.
Questo può essere effettuato mediante la raccolta di dati relativi ad alcuni
indicatori di processo e mediante la misurazione della soddisfazione
dell’utente finale, attraverso un questionario. I risultati ottenuti mostrano un
13
netto miglioramento delle prestazioni del sistema riguardo l’affidabilità dei
dati, l’usabilità dell’interfaccia, la ricerca delle informazioni e i costi.
Fra i possibili sviluppi futuri del sistema implementato vi è l’apertura

verso la rete Internet, naturale sbocco per un sistema web-based, ed il
miglioramento delle procedure di esportazione e stampa delle informazioni
su un formato più portabile.
14
1. LA DISTINTA BASE
La distinta base, la sua funzione, la sua importanza per l’azienda e le
problematiche relative ad essa, sono elementi conoscitivi fondamentali per
la comprensione del significato della tesi sviluppata nel presente elaborato.
In questo capitolo cercheremo di fornire al lettore una base teorica sulla
“distinta base” per una comprensione più chiara dei capitoli successivi.
1.1. La definizione di distinta base

La distinta base si può definire come “prospetto di dettaglio” quali-
quantitativo che riporta i componenti (materie prime, accessori, ecc.) e le
quantità-qualità degli stessi, necessari per la produzione di dati prodotti.
Essa disegna la configurazione di un prodotto la cui architettura viene
abbozzata dal mix delle parti e materiali che lo compongono e che sono
necessari per la sua realizzazione.
1.1.1. Una ricetta tecnica di prodotto

La distinta base è spesso paragonata alla lista di ingredienti di una
torta. Entrambi sono composti da una serie di componenti che insieme
costituiscono un prodotto finito, ma gli ingredienti della distinta base,
anziché uova, zucchero e farina, sono materie prime, sottoassemblati ed
elementi intangibili che contribuiscono al costo del prodotto finito.
Non per niente, in inglese, la distinta base è identificata dall’acronimo

B.O.M. (Bill Of Materials) e comunque il paragone funziona in quanto la
distinta base è sufficiente alla realizzazione del prodotto se associata a delle
specifiche di montaggio, così come la lista degli ingredienti è sufficiente
15
alla realizzazione della torta se associata alla ricetta che spiega come
utilizzare tali ingredienti.
Se associata a delle specifiche di montaggio, quindi sufficiente per la

realizzazione di un prodotto, la distinta base può essere considerata una
vera e propria “ricetta tecnica di prodotto”.
1.1.2. Un risultato della progettazione di prodotto

La distinta base è uno tra i risultati della progettazione del prodotto
[9]. I disegni esecutivi generati da questa importante fase dello studio di
fattibilità contengono oltre che i disegni di complessivo e di dettaglio, tutte
le indicazioni da fornire ai reparti interessati alla produzione ed in
particolare la distinta base, rivolta all’ufficio acquisti, che contiene la lista
dei materiali da approvvigionare con le relative quantità.
1.2. Le conseguenze di errori nella distinta base

Se un ingrediente sbagliato nella torta può avere pesanti effetti nel
contesto familiare (un forte mal di pancia o una figuraccia con gli ospiti),
nel contesto aziendale ciò assume proporzioni ben più gravi ed incide
negativamente sulle prestazioni dell’azienda.
Gli effetti indesiderati che può causare sono [6]:
errato costo di prodotto;
errati livelli di inventario;
errori nella contabilità;
ritorni di prodotti dal cliente;
realizzazione di prodotti “non conformi” alle specifiche;
reclami e lamentele dei clienti.
16
Una gestione accurata della distinta base è un prerequisito
fondamentale per lo sviluppo di altri sistemi di gestione operativi, come la
gestione degli ordini d’acquisto, la gestione delle revisioni di prodotto, la
gestione del magazzino.
1.3. La struttura della distinta base

La distinta base può essere riportata su una struttura ad albero oppure
più semplicemente in un documento in cui ogni sottolivello è rientrato
rispetto il livello superiore (vedi esempio).
La distinta base può essere strutturata per vari gradi di complessità a

seconda dei requisiti aziendali. Un documento relativo a una distinta base
dovrebbe rappresentare perlomeno le seguenti informazioni:
livello nella struttura;
un codice identificativo del componente;
il numero di revisione;
la quantità richiesta;
l’unità di misura (se le quantità non sono omogenee);
una descrizione;
un indicatore di “Make or Buy” (naturalmente solo gli elementi

realizzati dall’azienda, e pertanto “Make”, avranno a loro volta livelli
inferiori di dettaglio, mentre le “foglie dell’albero” saranno
necessariamente acquistati “Buy”).
17
La distinta può essere completata con informazioni relativi ai costi di
acquisto o di lavorazione dei singoli componenti ai diversi livelli, grazie ai
quali si può risalire un costo complessivo del prodotto. In ogni caso
bisogna porre molta attenzione nel convertire una distinta di produzione in
una distinta di costo in quanto i costi della distinta base di produzione sono
stime e non rappresentano costi reali.
1.4. La distinta base nei sistemi MRP

La distinta base di produzione contiene tutte le informazioni relative al
prodotto e tiene traccia di tutti i passaggi che il prodotto percorre fino alla
sua realizzazione.
La distinta base di produzione è utilizzata nei sistemi MRP. Esistono

due tipi di sistemi MRP:
MRP I (Materials Requirements Planning);
MRP II (Manufacturing Resources Planning).
Il sistema MRP I è lo strumento che permette di tenere sotto controllo

produzione, fornitori, terzisti, allo scopo di consentire una lineare gestione
18
dei materiali; inoltre sviluppa un piano di produzione allo scopo di
assicurare la disponibilità dei materiali, dei componenti e dei semilavorati
per rispettare assetto, processo e risultato del piano di produzione fino alle
consegne.
Negli anni ottanta si è sviluppato l’MRP II che non riguarda solo i

materiali ma tutte le risorse che si trovano lungo il processo produttivo. Per
questo l’MRP II è diventato uno strumento di “decision-making” per
qualsiasi azienda di produzione.
In tali sistemi la distinta base non è più una semplice ricetta tecnica
ma rappresenta un prodotto che si evolve e si trasforma, nello spazio e nel
tempo, dalla progettazione al cliente finale.
1.5. Le problematiche relative alla distinta base

La corretta gestione della distinta base racchiude in sé una serie di
problematiche dalla quale non si può prescindere. Riportiamo le principali
di seguito.
La rappresentazione dei livelli. Come rappresentare i livelli e i

legami di parentela tra i componenti e gli assemblati.
Il sistema di codifica. I componenti sono identificati nella distinta

base mediante un codice, è necessario pertanto istituire un sistema di
codifica adeguato per la rappresentazione delle distinte e dei
componenti.
La gestione delle revisioni. Come gestire le nuove versioni dei

componenti in distinta.
19
La gestione dei documenti. Come gestire i documenti allegati alla
distinta base e che insieme ad essa consentono la realizzazione
effettiva del prodotto.
La gestione del magazzino. Come gestire il magazzino e

l’approvvigionamento in relazione alla distinta base di produzione.
Il supporto informativo. Come conservare e reperire le informazioni

relative alla distinta base.
1.6. L’importanza della distinta base

La distinta base è il cuore dell’azienda di progettazione e/o produzione
e rappresenta il legame tra la fase di progettazione e la fase di produzione
di un prodotto, con forti implicazioni anche riguardo il problema
dell’approvvigionamento e della gestione del magazzino. Abbiamo inoltre
visto come la distinta base assuma un ruolo principale all’interno
dell’azienda e come essa rappresenti la base informativa su cui sviluppare
qualsiasi tipo di sistema informativo per la gestione aziendale.
20
2. IL SISTEMA PREESISTENTE
Nelle pagine che seguono riportiamo l’analisi svolta riguardo la

struttura del sistema preesistente.
L’analisi si può suddividere nelle seguenti fasi:
analisi generica delle caratteristiche tecniche;
analisi della struttura del database;
analisi qualitativa dei dati;
analisi delle procedure di gestione;
analisi dei sistemi di sicurezza;
analisi dell’interfaccia utente.
L’obiettivo è individuare le cose da mantenere, quelle da eliminare,

quelle da modificare e quelle da aggiungere.
2.1. Caratteristiche tecniche

Si tratta di un database realizzato con Microsoft Access 2000, delle
dimensioni di circa 10Mbyte (dopo la compressione). Dal punto di vista
tecnico, a giudicare dall’opinione degli utenti, non presenta particolari
problemi. Svolge senza problemi le operazioni principali per cui è stato
creato, mentre la gestione degli inserimenti e di eventuali problemi tecnici
è affidata ad un operatore che lo conosce molto bene e che è in grado di
risolvere qualsiasi problema si presenti. Il database funziona bene se è
usato bene: richiede una conoscenza tecnica elevata e poco trasmissibile.
21
2.2. La struttura del database
Aprendo il database Access è possibile visualizzare la struttura
tabellare su cui esso si basa dalla quale è necessario individuare:
le tabelle che rappresentano delle “entità” (qualcosa che esiste

“fisicamente”).
le tabelle che rappresentano “associazioni” tra più entità;
le tabelle che rappresentano “proprietà” (attributi) di entità.
La cosa risulta abbastanza semplice in quanto le entità rappresentano

qualcosa di tangibile ed hanno senso in sé e per sé (non necessitano di altre
tabelle per avere significato), le associazioni collegano due entità e quindi
contengono le “chiavi” di entrambe, le proprietà (oltre ad essere per forza
le rimanenti) si individuano in quanto perdono di significato se non
collegati all’entità di riferimento.
Riportiamo di seguito le tabelle così come sono state trovate nel

database Access (le chiavi dove presenti sono in neretto).
22
Facendo le considerazioni sopra descritte per tutte le tabelle si giunge
al seguente risultato:
la tabelle TBLELEMENTI, TBLFORNITORI, TBLORDINI

rappresentano entità;
23
la tabella TBLCOSTI rappresenta una associazione tra l’entità
TBLELEMENTI e l’entità TBLFORNITORI;
le tabelle TBLCODICICOSTRUTTORI,
TBLALTRICOSTRUTTORI, TBLLINK, TBLREVISIONI,
TABELLAMASA e TABELLAOPERAZIONIMAS rappresentano
proprietà relative all’entità TBLELEMENTI;
le tabelle TBLLOTTOPROD, TBLPROGETTI, TBLTIPOACQ

rappresentano proprietà relative all’entità ORDINI;
la tabella TBLDISTINTE rappresenta un’associazione, in particolare

un’auto-associazione tra l’entità TBLELEMENTI e sé stessa, serve
per evidenziare il legame di parentela tra due elementi (vedi figura).
(0,N) PADRE
TBLELEMENTI TBLDISTINTE
(0,N) FIGLIO
A questo punto è possibile ricavare lo “schema scheletro” della

struttura del database preesistente.
24
(1,1)
tbllink
(0,N)
(1,N) (0,N) (0,1)

tblaltricostruttori tblrevisioni
(0,1)
(1,1) (0,1) (0,N) PADRE

tblcodicicostruttori tblelementi tbldistinte
(0,N) FIGLIO
(1,1) (0,1) (0,N)
Tabellamasa
tblcosti
(0,N)
(0,N)
(1,1) tblfornitori
Tabellaoperazionimas
(0,N)
(0,N)
tblLottoProd
(0,1)
(1,1) (0,1)
tblordini
(0,1)
(0,N)
(0,N)
tblTipoAcq tblprogetti
25
2.2.1. Le due anime del vecchio database
Guardando lo schema rappresentante la struttura del database
preesistente si nota immediatamente una suddivisione logica e funzionale
tra due aree:
la gestione della produzione;
la gestione degli ordini.
L’area di “produzione” si occupa di immagazzinare le informazioni

relative agli elementi e alla distinta base, l’area di gestione degli ordini
raccoglie invece i dati relativi agli ordini emessi con le relative
caratteristiche.
GESTIONE (1,1)
DELLA
tbllink
(0,N)
PRODUZIONE
(1,N) (0,N) (0,1)
tblaltricostruttori tblrevisioni
(0,1)
(1,1) (0,1) (0,N) PADRE

tblcodicicostruttori tblelementi tbldistinte
(0,N) FIGLIO
(1,1) (0,1) (0,N)
Tabellamasa
tblcosti
(0,N)
(0,N)
(1,1) tblfornitori
Tabellaoperazionimas
(0,N)
(0,N)
tblLottoProd
(0,1)
(1,1) (0,1)
tblordini
(0,1)
(0,N)
(0,N)
tblTipoAcq tblprogetti
GESTIONE
DEGLI ORDINI
26
Queste due aree appaiono a prima vista scollegate tra loro e il loro
collegamento sembra quantomeno forzato. In particolare la divisione logica
che si evidenzia nell’analisi della struttura è causata dal fatto che tale
database non è il risultato di un unico processo di studio del sistema
informativo aziendale, bensì l’insieme di successivi miglioramenti fatti per
rispondere alle esigenze che si presentavano con l’aumentare delle
dimensioni dell’azienda.
Esaminando la struttura del database riportata in precedenza si

evidenziano le due aree di gestione della produzione e di gestione degli
ordini che si intersecano nell’entità TBLFORNITORI. Tale intersezione è
estremamente debole, basti considerare la numerosità dei fornitori (circa
170) rispetto quella degli elementi (quasi 9000). La causa di questo si può
individuare proprio nella forzata unione di due parti che sia
concettualmente che operativamente svolgono funzioni diverse all’interno
dell’azienda. Si evidenziano pertanto i seguenti problemi:
sono pochi gli elementi a cui è associato un costo e quindi un

fornitore;
dal singolo ordine non è possibile risalire direttamente al codice

elemento in quanto ogni elemento viene codificato nel momento in cui
viene utilizzato;
le due parti hanno diversi obiettivi e diverse funzioni.
Queste considerazioni portano alla conclusione che non vi è alcun

motivo che giustifichi l’unione di queste due aree così diverse tra loro, a
meno che non si operi una revisione globale di tutto il sistema degli ordini.
In particolar modo vi dovrebbe essere una correlazione diretta tra “ordine”
ed “elemento”. Ciò implica una lunga serie considerazioni:
27
prima dell’emissione di un ordine sarebbe necessario effettuare la
codifica degli elementi che si stanno ordinando;
fino ad ora su ogni ordine non è mai stato specificato il relativo codice
elemento, l’introduzione del nuovo sistema implicherebbe un lungo
lavoro di reperimento delle informazioni altrimenti la perdita di una
notevole mole si dati;
nell’entità TBLELEMENTI sono codificati nel medesimo modo sia

componenti acquistati (per i quali vi è un relativo ordine) sia prodotti
realizzati all’interno dell’azienda;
il legame tra TBLELEMENTI e TBLFORNITORI non sarebbe diretto

bensì realizzabile solo attraverso l’entità TBLORDINI, stesso discorso
vale per la relazione tra TBLELEMENTI e TBLCODICI
COSTRUTTORI;
la ricostruzione di tali relazioni a partire dalla struttura attuale è

pressoché impossibile, significherebbe procedere nell’analisi manuale
di ogni singolo ordine emesso, con una elevatissima probabilità di
errore.
Le soluzioni che possono essere prese sono infine le seguenti due:
Creazione di una nuova struttura informativa corretta concettualmente e

che comprenda tutte le aree dell’azienda. Questo significherebbe la
perdita pressoché totale di tutti le informazioni che attualmente
afferiscono all’entità elementi e che passerebbero all’entità
TBLORDINI (codice costruttore, costi), fatto non accettabile per
l’azienda. Riporto di seguito una rappresentazione semplificata sulla
possibile nuova struttura del database (sono omesse le parti meno
rilevanti).
28
DATA
COSTO TBLORDINE TBLELEMENTO TBLDISTINTE
CODICE
COSTRUTTORE
CODICE_ELEMENTO
TBLFORNITORE ID_FORNITORE
Suddivisione delle due parti in due sistemi di gestioni differenti. Questo

consente di mantenere tutti i dati storici relativi alla gestione della
produzione e alla gestione degli ordini. L’unico limite è l’impossibilità
di future interrogazioni incrociate sulle due aree, cosa che comunque
attualmente è impedita dalla scorretta impostazione.
Date le considerazioni fatte, si è optato per la seconda soluzione

decidendo di affidare la gestione degli ordini ad un sistema commerciale e
di procedere invece allo studio della gestione della produzione. Pertanto
d’ora in avanti ci occuperemo solo di tale parte.
2.2.2. Analisi statistica sulle tabelle

Per comprendere a fondo la struttura del database preesistente e
necessario cercare eventuali errori nella definizione delle tabelle. Per
questo, è necessaria un’analisi statistica sulle tabelle del database che ci
fornisca il significato reale dei campi da confrontare con il significato che i
medesimi campi “dovrebbero” avere.
29
Per eseguire tale analisi abbiamo realizzato un programma,
denominato “statistiche_tabelle.php”, in linguaggio PHP, che svolge le
seguenti funzioni:
determina il totale delle istanze per ciascuna tabella;
determina, per ogni campo di ogni singola tabella, la lunghezza

massima (in caratteri) della stringa;
determina, per ogni campo di ogni tabella, il totale delle istanze che
hanno un valore “non nullo” relativamente a quel campo.
Questo serve per individuare eventuali errori nella scelta delle chiavi,
quali campi dovrebbero essere dichiarati obbligatori (a parte le chiavi
nessun campo era stato impostato come obbligatorio in precedenza) e ci
aiuterà, in fase di riprogettazione del database, nel determinare le
lunghezze massime da assegnare ai vari campi.
Per funzionare, tale programma, necessita delle tabelle in formato

CSV (Comma Separated Values) ottenibile mediante i seguenti semplici
passi:
aprire il file Access contenente tutto il database;
selezionare la tabella che si vuole esportare;
nel menu a tendina selezionare FILE, poi EXPORT;
posizionarsi in una directory qualsiasi e salvare il file in un formato

Excel, per esempio “Microsoft Excel 97-2002”;
aprire il file appena salvato con Excel;
nel menu a tendina selezionare FILE, poi SALVA CON NOME;
posizionarsi nella directory del server in cui verrà eseguito lo script PHP
e salvare nel formato “CSV (OS/2 or MS-DOS)”;
30
ripetere tale procedura per tutte le tabelle da esportare.
Aprendo uno dei file CSV appena creati con un qualsiasi editor di
testo si può notare che tale formato è una semplice rappresentazione di una
tabella, in particolare ogni riga del file corrisponde a un’istanza della
tabella, ed ogni campo è separato dall’altro mediante un “punto e virgola” e
nel nostro caso la prima riga corrisponde al nome dei campi rappresentati.
Il programma procederà quindi alla parserizzazione dei file in

questione e gli esaminerà generando un output contenente le statistiche
relative.
Il risultato consiste in una serie di tabelle, che riportiamo di seguito

insieme a un breve elenco di problematiche riscontrate.
TBLELEMENTI
L’attributo “descrizione” deve essere un attributo obbligatorio, ma vi

sono un certo numero di istanze (12) con tale campo nullo: da
eliminare.
L’attributo “data_inserimento” è un attributo obbligatorio, ma vi sono

molte istanze con tale campo nullo: nel nuovo sistema verrà inserita la
“data nulla” 0000-00-00.
31
L’attributo “gestione” identifica quegli elementi il cui acquisto è
gestito dall’azienda stessa, questo in realtà varia a seconda della
distinta in cui il componente è utilizzato, quindi tale attributo è una
proprietà della entità TBLDISTINTE.
TBLDISTINTE
Non è definita la chiave della tabella! Essendo tale tabella

un’associazione, la chiave è individuata dall’insieme delle due chiavi
delle entità a cui essa afferisce: “codice_distinta” e
“codice_elemento”. Inoltre siccome all’interno della stessa distinta
può essere presente più volte lo stesso elemento ma in posizione
diversa, la chiave definitiva deve essere il trio “codice_distinta”,
“codice_elemento”, “pos”.
L’attributo “descrizione” è una banale ripetizione della descrizione

dell’elemento padre, è pertanto una ridondanza inutile da eliminare.
L’attributo “quantità” è un attributo obbligatorio ma può essere anche

zero, nelle istanze dove non è presente sarà inserito “0”.
32
TBLREVISIONI
Questa tabella ha un bassissimo numero totale di istanze, è per questo

che nonostante sia un attributo con cardinalità unaria (ad ogni
elemento può essere associata una sola revisione) non può essere
incorporato nell’entità TBLELEMENTI.
Ad ogni elemento può essere associata al più una revisione pertanto è

identificativo della revisione stessa il “codice_elemento”: è del tutto
inutile e superfluo l’identificatore “ID_rev”;
“descrizione_revisione” è un attributo obbligatorio;
“data_revisione” è un attributo obbligatorio;
Gli attributi “originato” e “approvato” sono facoltativi, ma necessari;
I campi “conseguenze” e “azioni_attuate”, nonostante la bassissima

numerosità di valori non nulli vanno mantenuti in quanto potrebbero
essere utilizzati maggiormente in futuro;
L’attributo “link”, anche se praticamente inutilizzato, può essere

molto utile quindi va mantenuto.
33
TBLLINK
La tabella TBLLINK rappresenta un attributo composto a cardinalità

multipla (0,N), cioè ad ogni “codice_elemento” possono essere
associati più link, per questo non è possibile incorporarlo con l’entità
ELEMENTI.
“codice_elemento” e “link” caratterizzano univocamente un’istanza, il

loro insieme è pertanto la chiave primaria della tabelle rendendo
superfluo l’identificatore progressivo “ID” e prive di significato le
istanze contenenti link nulli.
TBLCODICICOSTRUTTORI
Tale tabella rappresenta un attributo unario (0,1) e composto, non

viene integrato con ELEMENTI per evitare troppi campi con valori
nulli;
La chiave primaria è “codice_elemento”, ad essa deve riferire sempre

un “codicecostruttore” che pertanto è attributo obbligatorio;
34
“costruttore” e “note” sono attributi facoltativi;
TBLALTRICOSTRUTTORI
Tale tabella rappresenta un attributo multiplo (0,N) composto

dell’entità ELEMENTI.
Ad ogni “codice_elemento” (campo obbligatorio) deve essere

associato un “costruttore” e un “codice_costruttore” (campi
obbligatori).
La chiave primaria è l’insieme degli attributi “codice_elemento” e

“codice_costruttore” (ID è superfluo).
TBLFORNITORI
35
L’identificatore primario è “ID_fornitore”, un numero progressivo
auto-incrementante; non viene preso “fornitore” come identificatore
perché potrebbe esistere il caso limite in cui due fornitori diversi
hanno la stessa denominazione.
gli altri attributi sono tutti caratterizzanti del fornitore stesso, sono
tutti facoltativi tranne fornitore.
TBLCOSTI
Deve essere possibile associare un elemento a un costo anche in

assenza di un fornitore, quindi è corretto utilizzare come identificatore
“ID”. Da notare però che in tale modo l’associazione tra elementi e
costi è più debole.
“codice_elemento”, “costo” e “data” sono attributi obbligatori;
gli altri attributi sono facoltativi.
TABELLAMASA
36
Tale tabella rappresenta un attributo unario e composto dell’entità
ELEMENTI, non può essere incorporato in ELEMENTI a causa della
bassa numerosità.
è identificativo lo stesso “codice_sadel” (che in realtà corrisponde

esattamente al solito “codice_elemento”), “ID-codice” è superfluo;
“posizione” è un attributo facoltativo in quanto anche se non è

specificata la posizione del componente in magazzino va comunque
mantenuta l’informazione della sua presenza.
TABELLAOPERAZIONIMASA
Tale tabella rappresenta un attributo composto multiplo (0,N)

dell’entità ELEMENTI, non può pertanto essere incorporata e
“codice_sadel” (“codice_elemento”) non può svolgere il ruolo di
chiave primaria che è affidato a “ID-op”, numero progressivo auto-
incrementante;
“codice_sadel”, “npezzi_operazione” e “data” sono attributi

caratterizzanti e quindi obbligatori;
Riassumiamo quindi i risultati ottenuti relativamente ai valori nulli

nella tabella TBLELEMENTI allargata agli attributi composti unari che in
linea di principio potrebbero essere accorpati ad essa:
37
E’ evidente come l’incidenza dei valori nulli sarebbe troppo elevata
se le tabelle TBLREVISIONI, TBLCODICICOSTRUTTORI e
TABELLAMASA fossero incorporati nell’entità TBLELEMENTI.
2.2.3. I risultati dell’analisi della struttura

Completata l’analisi della struttura del database preesistente abbiamo
le idee un po’ più chiare su quali saranno le modifiche strutturali da
effettuare, quali tabelle dovremo mantenere, quali i campi che dovremo
definire come “chiavi” e quali come “obbligatori”, come dovremo
comportarci in alcuni casi nella fase di importazione (per esempio cosa fare
dei valori nulli nei campi obbligatori). Tutto questo però non è sufficiente
se non accompagnato da un’analisi qualitativa sui dati e sulle procedure.
38
2.3. Analisi della qualità dei dati
Un’analisi di questo tipo si presenta inizialmente quantomeno ardua,
in quanto la mole di dati da esaminare è notevole. In realtà l’obbiettivo di
questa analisi non è quello di confrontare i dati contenuti nel database con
altri dati noti contenuti su altri tipi di supporto, ma “semplicemente”
comprendere quali informazioni debbano essere associate ad elevati livelli
di precisione e per tali informazioni verificare la presenza o meno di
meccanismi di controllo ed eventualmente procedere alla verifica dei dati
storici preesistenti.
L’analisi in particolare si deve concentrare su:
la documentazione esistente riguardo il sistema di codifica;
eventuali sistemi di controllo nell’inserimento dei dati;
le informazioni considerate più importanti dall’azienda;
Per quanto riguarda gli ultimi due punti la risposta è semplice: non è
presente alcun sistema di controllo nell’inserimento dei dati, quindi non c’è
nulla che è sicuramente corretto. Ciò non significa, però, che non vi siano
dati importanti; anzi, i dati relativi alle tabelle TBLELEMENTI e
TBLDISTINTE, contenenti rispettivamente le informazioni su tutti gli
elementi gestiti dal database e su tutte le distinte, sono considerate vitali per
l’azienda. Inoltre sono ritenuti importantissimi tutti i documenti allegati nei
quali sono riportati, tra l’altro, i progetti relativi alle schede elettroniche e
ai prodotti realizzati.
L’attenzione a questo punto passa sulla documentazione esistente che

determina il formalismo a cui si deve attenere il “codice_elemento”
(identificatore dell’entità TBLELEMENTI).
39
2.3.1. La codifica degli elementi
Dall’analisi della struttura del database preesistente si è potuto notare
quanto sia centrale il ruolo dell’entità “Elementi”, rappresentata nella sua
forma tabellare da TBLELEMENTI, per l’intero sistema. Tale importanza
deriva dal fatto che essa definisce il soggetto che le altre tabelle descrivono.
Diventa cruciale a questo punto l’identificatore primario di tale entità che
di conseguenza diventa una “chiave esterna” per quasi tutte le altre tabelle.
La scelta di tale identificatore è caduta su un codice semi-parlante, in

parte ereditato dalla azienda precedente, in parte rivisto dall’azienda
attuale.
Esiste una serie di documenti che riporta la struttura che il codice

dovrebbe avere, che si può riassumere nei seguenti formati (le lettere
minuscole individuano numeri, quelle maiuscole lettere, le “xxxx” numeri
progressivi, le “yy” i numeri di revisione):
tAAxxxx: componenti per circuito stampato
AAxxxx-yy: assemblati
AAxxxx-BByy: documenti relativi all’assemblato
AAxxxx: componenti commerciali
AAxxxx-BByy: Software, Firmware
Naturalmente i valori letterali presenti, assumono diverso significato a

seconda del tipo di elemento che viene identificato dal formato ed inoltre vi
è un certo numero di eccezioni che complica notevolmente le cose:
Per i componenti per circuito stampato codificati da Sadel viene

introdotta una S tra la prima e la seconda cifra
40
Le schede elettroniche già codificate in passato da FEP viene
mantenuta la codifica originaria aggiungendo due parametri:
0CSADxxxx-DI-yy
Per effettuare una valutazione del sistema di codifica esistente è

necessario esaminare i seguenti punti:
confrontare il sistema di codifica con le tipologie di elementi;
verificare l’attinenza dei dati reali al formato di codifica.
La gerarchia degli elementi

Il codice semi-parlante, se esistente, deve poter dare informazioni
sull’elemento che rappresenta. Utilizzato in un database ciò significa poter
effettuare selezioni di istanze sulla base del tipo di codice. Questo ha senso
solo se tali selezioni raggruppano un insieme di dati simili, quindi una
tipologia di codice deve essere associata ad una ben precisata tipologia di
elementi.
Parlando più dipendenti dell’azienda è stato possibile determinare una

certa gerarchia di elementi (vedi figura).
41
Liv.0
Liv.1
Liv.2
42
In particolare, si possono individuare due livelli principali di
categorie:
Livello 1. Vi sono 4 grandi tipi di elemento: assemblati, componenti

commerciali, componenti per circuito stampato, documenti e software.
Il primo dubbio riguarda la denominazione della categoria
“componenti commerciali”, in quanto anche i componenti per circuito
stampato sono in larga parte commerciali: quindi sarebbe necessario
cambiare tale denominazione, ma comunque la divisione tra le due
categorie è corretta in quanto si tratta di elementi che svolgono ruoli
molto diversi nel processo di produzione. L’altro dubbio da chiarire è
il perché dell’unione di documenti e software. Il motivo è perché
nonostante l’evidente diversità tra le due tipologie essi svolgono ruoli
simili in quanto si tratta di elementi associati a distinte con quantità
nulla, necessari per la costruzione e l’utilizzo del prodotto ma
difficilmente quantificabili. In ogni caso l’unione tra documenti e
software rimane discutibile, ma è tollerabile in quanto nel successivo
livello di definizione i ruoli si possono distinguere facilmente.
Livello 2. A questo livello si differenziano le singole tipologie di

elementi (in figura sono riportate solo le principali), più in basso vi
sono solamente caratteristiche tecniche che possono differenziare un
elemento da un altro (per esempio due condensatori con capacità
diverse).
La gerarchia sopra descritta, se confrontata con la struttura del codice,

è rappresentata abbastanza bene, in particolare si nota come le categorie al
primo livello corrispondano a diversi formati di codice, mentre quelle al
secondo hanno per ogni ramo il medesimo formato e si distinguono tra loro
grazie alla parte “parlante” del codice. Per livelli di dettaglio superiore il
43
sistema di codifica prevede, saggiamente, una parte di codice seriale
evitando così codici troppo complicati e lunghi e, di conseguenza,
difficilmente interpretabili.
I dati reali e il codice

Considerato il fatto che non esiste alcun meccanismo di controllo
sull’inserimento dei dati è facile immaginare come un buon numero di
codici inseriti non corrispondano al sistema di codifica previsto.
Per effettuare quest’analisi ci siamo serviti di un piccolo programma

(“analisi_vecchi_codici.php”), realizzato in linguaggio PHP, che prende
tutti i codici contenuti nella tabella TBLELEMENTI e li confronta con i
diversi formati possibile, restituendo quanti codici rispettano tale codifica.
Tale programma si basa su un file di testo “strutturato” mediante un

certo formalismo che permette di esprimere l’intero sistema di codifica (un
file simile lo utilizzeremo anche per effettuare la verifica dei dati inseriti
nel sistema in progettazione; allora lo descriveremo nel dettaglio).
Otteniamo il seguente risultato.
44
Come si può notare il numero di codici errati si aggira attorno all’1%
e corrisponde a un valore assoluto di circa 100 codici, quindi solo un
numero limitato di elementi non rispetta la codifica. E’ necessaria pertanto
una revisione di tali codici per ricondurli eventualmente a una codifica
nota, ma non la creazione di nuove tipologie di codice. Per contenere in
futuro tale numero di codici errati è inoltre auspicabile l’introduzione di
meccanismi di controllo sull’inserimento dei dati.
2.3.2. La descrizione dei componenti

Un’altra caratteristica molto importante dell’elemento è naturalmente
la descrizione che, associata a al codice, esprime le caratteristiche
(prevalentemente tecniche) dell’elemento. Tale descrizione assume
un’importanza ancora maggiore per una serie di “componenti per circuito
stampato” presenti in elevata numerosità e con caratteristiche tecniche ben
definite. In particolare per i seguenti componenti, che in seguito
denomineremo “speciali” a causa dell’importanza del loro ruolo, dovrebbe
essere previsto un “campo descrizione” formalizzato in modo tale da poter
distinguere chiaramente componenti con diverse caratteristiche tecniche:
condensatori;
resistenze;
circuiti integrati;
connettori;
diodi;
transistor.
In effetti, la definizione di un formato per il campo descrizione dei

suddetti elementi è già in studio all’interno dell’azienda, in quanto la
45
mancanza di un formalismo preciso si rivela un fortissimo limite alle
potenzialità di ricerca e di interrogazione del database.
2.3.3. I documenti allegati

Altro punto importantissimo e che non può essere tralasciato
nell’analisi della qualità dei dati è quello dei documenti allegati. Nella
tabella TBLLINK del database preesistente sono contenuti i collegamenti ai
documenti reali presenti all’interno di un apposito server.
Questo rischia di essere un fortissimo limite per l’affidabilità e

l’integrità dei dati contenuti, in quanto non vi è un legame biunivoco tra il
collegamento scritto all’interno del database e i dati reali contenuti in una
directory del server. Un operatore distratto o un malintenzionato potrebbe,
per ipotesi, modificare o eliminare un documento senza che questo venga
rilevato nel database.
Non è possibile pertanto dare un giudizio, come nei casi precedenti,

sulla qualità e sull’integrità dei dati contenuti attualmente nel database
(anche se una decina di link che indirizzano a documenti inesistenti fanno
riflettere), ma si può senz’altro dire che tale sistema di gestione dei
documenti presenta gravi falle e, se possibile, deve essere cambiato.
2.3.4. Altri piccoli problemi

Vi è una serie di altri piccoli problemi legati alla qualità dei dati, ma
che in genere possono essere risolti con un’adeguata pulizia dei dati:
“codici costruttori” senza codice, ma con solo il nome del costruttore;
“costi” senza costo, ma con solo l’associazione del fornitore;
“elementi” senza descrizione;
46
“revisioni” senza descrizione della revisione;
“link” senza collegamento;
“altri costruttori” senza il nome del costruttore;
La maggior parte di questi casi, che per fortuna non sono molti, in fase
di importazione dei dati saranno eliminati, in quanto sono privi delle
informazioni necessarie affinché la loro esistenza abbia senso.
Per fortuna non sono stati rilevati problemi di questo tipo in relazione
alle “distinte”, evidentemente è stata posta maggiore attenzione su questa
associazione che in fondo è il cuore del sistema e che rappresenta i dati più
importanti per l’azienda.
2.3.5. I risultati dell’analisi della qualità dei dati

In base a tutte le considerazioni fatte riguardo l’attuale livello di
qualità dei dati si rilevano le seguenti problematiche:
manca un sistema di verifica dei dati in inserimento, in particolare per

quanto riguarda il codice di un elemento;
risulta mal definito il “campo descrizione” di alcuni componenti per il

quale si rendono necessarie frequenti interrogazioni complesse del
database;
manca un sistema che garantisca la corretta associazione dei link ai

documenti che essi rappresentano, creando un problema di sicurezza e
di integrità dei dati.
47
2.4. Analisi delle procedure di gestione
Per comprendere bene il funzionamento del sistema preesistente è
necessario focalizzare la propria attenzione sulle procedure più importanti
che risultano essere elementi chiave per il funzionamento del sistema.
Abbiamo individuato nei seguenti tre punti le procedure principali:
la creazione di un elemento;
l’inserimento di una distinta;
la revisione di un elemento.
Tutte le suddette funzioni sono affidate ad un operatore che ha la

responsabilità dell’intero sistema e delle operazioni che su di esso svolge.
Questo fatto favorisce possibili errori determinati dall’inserimento di dati
richiesti da altri e sui quali l’operatore non può valutare la correttezza (per
esempio schede tecniche o progetti).
Nei seguenti paragrafi si descrivono le tre procedure in uso.
2.4.1. La creazione di un elemento

Nel momento in cui si rende necessaria la creazione di un elemento si
procede secondo i seguenti passi:
Codifica di un elemento. Avviene determinando il formato e la parte

parlante del codice a seconda della tipologia dell’elemento e
successivamente cercando tra i codici già esistenti un numero seriale
non ancora utilizzato, in modo tale da avere la certezza che
l’identificatore non esista (fortunatamente Access impedisce
l’inserimento di istanze se la chiave è già esistente).
48
Inserimento dell’istanza nella tabella. Il codice elemento, insieme alla
descrizione, alla data e a gli altri attributi viene inserito molto
semplicemente aggiungendo una riga in fondo alla tabella degli elementi
(vedi figura).
Si individuano pertanto i seguenti problemi:
non vi è alcun controllo sull’inserimento;
una distrazione potrebbe modificare altri elementi già inseriti;
non vi è una chiara attribuzione delle responsabilità. Il campo

“approvato da” indica chi ha approvato l’inserimento dell’elemento,
quindi chi ha la responsabilità dei dati immessi nel database. Potrebbe
per assurdo capitare che risulti che una persona ha approvato un
elemento che però a causa di un banale errore di battitura
dell’operatore contiene dati sbagliati. In questo caso, la responsabilità
è dell’operatore, ma l’errore risulta attribuito a chi è nominato
all’interno del campo “approvato da”.
49
2.4.2. L’inserimento di una distinta
Per comprendere l’inserimento della distinta è necessario
comprendere come viene creata una distinta.
La distinta, che come abbiamo già detto, è la ricetta tecnica di un

prodotto, viene estratta dal progetto sotto forma di B.O.M. (Bill Of
Materials). In genere, si tratta di una tabella Excel, con determinati campi,
che prima di essere inserita nel database deve essere rivista, ordinata ed
eventualmente modificata.
Riportiamo di seguito un esempio di B.O.M.
Per capire a quali modifiche essa debba essere sottoposta affinché

possa collocarsi all’interno del database riportiamo la struttura della tabella
TBLDISTINTE utilizzata.
50
Confrontando le due strutture si evidenzia come tra tutti i campi gli
unici rilevanti siano “code” (corrispondente al codice_elemento della
tabella), “description” (descrizione), “item” (pos), “qty” (quantità) e
“reference”.
Inoltre oltre all’eliminazione dei campi inutili, prima dell’inserimento

nel database è necessario:
riordinare i campi;
aggiungere come primo campo il codice della distinta (è l’elemento

padre ed è lo stesso per tutti i componenti);
sommare le quantità e unire le stringhe di “reference” per i

componenti con lo stesso codice elemento (a meno che non vi sia la
dicitura “non saldare”);
se presente il campo “non saldare” inserire l’elemento con quantità

pari a zero;
modificare la quantità dei documenti che deve essere sempre pari a

zero;
aggiungere eventuali note.
Il risultato dell’elaborazione “manuale” del file dovrebbe essere il

seguente:
51
A questo punto, con una delicata operazione di “copia e incolla” si
trasferiscono i dati (tranne la prima riga contenente l’intestazione delle
colonne) nel database Access.
Considerazioni sulla procedura
Essendo la distinta un elemento critico dell’intero sistema, riteniamo

sia troppo poco affidabile la procedura di gestione della distinta. In
particolare, il susseguirsi di operazioni estremamente delicate realizzate
manualmente e senza alcun meccanismo di verifica dei dati inseriti, può
generare gravi errori ed è suscettibile di distrazioni e dimenticanze. Si
ritiene pertanto che il sistema di gestione della distinta base debba essere
modificato.
52
2.4.3. La revisione di un elemento
L’ultima procedura di gestione considerata critica per il sistema è la
“revisione di un elemento”. Per comprendere la procedura è necessario
conoscere cosa si intende all’interno dell’azienda per “revisione”.
Cos’è una revisione

Il significato di revisione cambia a seconda dell’elemento che viene
revisionato. Non tutti gli elementi presenti nel database possono essere
oggetto di revisione per esempio ne sono esclusi tutti i componenti
commerciali e quindi non prodotti all’interno dell’azienda.
Elenchiamo di seguito i diversi elementi che possono essere soggetti a

revisione e ne esplichiamo il significato per ognuno di essi.
Assemblati (prodotti, schede, parti meccaniche, cablaggi). Per tali tipi

di elementi la revisione è il cambiamento di un componente nella
distinta corrispondente che lascia invariate le caratteristiche funzionali
dell’elemento, modificando (innalzando) la caratteristiche
prestazionali dello stesso (per es. affidabilità). Da notare che è
possibile l’esistenza di una “versione” (relativa a una revisione) di un
elemento senza che nel database sia presente la distinta
corrispondente.
Documenti. Per revisione di un documento si intende

l’aggiornamento del documento (per esempio se si tratta di un
progetto CAD, qualche piccola modifica dello stesso, che non
influisce sulla distinta a cui il documento si riferisce). I documenti non
hanno mai una distinta (cioè non sono mai l’elemento padre di una
distinta).
53
Software. Cambiamenti nel programma che non cambia la
funzionalità dello stesso ma ne migliora le prestazioni. Come i
documenti non hanno distinta.
Componenti. E’ un caso limite: può capitare che un componente

commerciale debba essere sottoposto a lavorazioni (per esempio di
tipo chimico) per migliorarne le prestazioni, in tal caso si crea una
piccola distinta contenente il componente e la lavorazione a cui è stato
sottoposto. Tale componente modificato può successivamente essere
sottoposto a revisione come un qualsiasi altro assemblato.
La procedura di revisione
Nel momento in cui si decide di effettuare una revisione, vi è una
procedura di tipo operativo a cui fare riferimento:
individuare il numero di revisione (per esempio, se si tratta di una

scheda il cui codice è HS0001-01, quindi di versione 01, la sua
revisione sarà del tipo HS0001-02, con numero di revisione 02);
creare un nuovo elemento con il codice determinato in precedenza;
inserire nella tabella TBLREVISIONI i dati relativi alla revisione

(descrizione revisione, motivazione, ecc.);
se prevista, inserire la distinta relativa alla nuova revisione

dell’elemento;
si dichiarano obsoleti tutti gli elementi con versioni precedenti

(cambiando il campo “obsoleto” nella tabella TBLELEMENTI);
se qualche versione dell’elemento revisionato era già presente in

qualche distinta, si modifica l’elemento (aggiornandolo a l’ultima
revisione) in tutte le distinte non ancora marchiate come obsolete.
54
Da notare come tutte le operazioni sopra descritte avvengano
intervenendo manualmente sulle istanze presenti all’interno delle tabelle,
senza alcun meccanismo di controllo o verifica dei dati inseriti.
E’ da segnalare inoltre il fatto che le revisioni debbano essere

approvate da qualcuno che si prende la responsabilità delle modifiche
effettuate sull’elemento. Questo avviene mediante una procedura di
approvazione assai simile a quella per la creazione di un elemento, con tutti
i limiti sull’attribuzione delle responsabilità che ciò comporta.
Considerazioni sulla procedura
Dal punto di vista operativo la procedura presenta tutti i limiti che

abbiamo già visto nel caso della creazione di un elemento e di inserimento
di una distinta. In particolare l’assenza di controllo sui dati inseriti e la
difficile attribuzione delle responsabilità minano fortemente l’affidabilità e
l’integrità di dati relativi. Inoltre, sorgono alcuni dubbi, riguardo la
procedura logica utilizzata per le revisioni, soprattutto riguardo la
reperibilità delle informazioni (modificando elementi in distinte già in uso
non si rischia di perdere informazioni su prodotti già realizzati o venduti?).
2.5. Analisi dei sistemi di sicurezza

In questo paragrafo analizzeremo la sicurezza del sistema sotto due
aspetti fondamentali:
la gestione dei permessi;
i backup e il ripristino dei dati.
55
2.5.1. La gestione dei permessi
La gestione degli utenti e dei permessi a loro assegnati, nel sistema
preesistente, è di una semplicità disarmante. Una sola persona,
l’amministratore del sistema, ha accesso sia in lettura che in scrittura al
database, mentre tutti gli altri utenti possono accedervi solo in lettura.
Tale sistema nella sua semplicità funziona abbastanza bene. Si evitano

rischi di inquinamento dei dati da parte di malintenzionati o inesperti e si
da la responsabilità dell’intero sistema ad una persona affidabile all’interno
dell’azienda stessa.
In sostanza qualsiasi operazione effettuata sul database ed eventuali

errori di inserimento di “basso livello” (errori di battitura o di distrazione)
sono attribuibili solo ed esclusivamente all’amministratore del sistema, con
un chiara attribuzione delle responsabilità. Il problema sorge per gli errori
più gravi, che minano effettivamente la qualità globale dei dati: in questo
caso tale meccanismo non è sufficiente, come abbiamo visto nell’analisi
della qualità dei dati.
Vi è anche un problema di riservatezza delle informazioni. Ci sono un

certo tipo di dati che sono considerati riservati e che pertanto non devono
uscire dall’azienda. Tali dati sono in particolare quelli relativi ai costi degli
elementi e alla situazione del magazzino. Non è previsto alcun permesso
che conceda ad un utente di vedere tutti i dati tranne quelli riservati,
impedendo pertanto di aprire le porte del database verso l’esterno (in
particolare verso i terzisti e i fornitori che necessitano solo dei dati relativi
alla distinta base).
56
2.5.2. I backup e il ripristino dei dati
L’altro aspetto importante della sicurezza è quello relativo alle
operazioni di backup e all’eventuale ripristino dei dati.
L’intero database preesistente consiste in un unico file che può essere

letto con l’applicazione Microsoft Access. Esso è contenuto in un apposito
server sul quale sia l’amministratore che gli utenti accedono, l’hard disk nel
quale si trova è replicato per tutelarsi da eventuali crash del sistema.
Si adottano inoltre i seguenti accorgimenti:
tutte le operazioni di inserimento o modifica del database vengono

effettuate su una copia del file contenente il database;
a fine giornata, se tutto è andato bene (cioè se non ci sono stati crash
del sistema), si memorizza il file con un nome contenente la data del
giorno.
In sostanza si effettua un backup del sistema ogni giorno, questo

consente di perdere, nella peggiore delle ipotesi, al massimo una giornata
lavorativa di dati inseriti. Questo è tollerabile se il numero di modifiche e
inserimenti che giornalmente si effettuano è basso, mentre diventa un forte
limite se tale numero è destinato ad aumentare.
2.6. Analisi dell’interfaccia

In questo paragrafo descriveremo la struttura generale dell’interfaccia
utente, senza dilungarsi nei particolari tecnici, per limiti di tempo e di
pertinenza.
L’obiettivo e valutare l’usabilità dell’attuale sistema e individuare

quegli elementi che entrati ormai nell’uso comune all’interno dell’azienda
57
non devono, se possibile, essere modificati, per evitare rivoluzioni
d’utilizzo troppo grosse.
Si procede di seguito analizzando:
l’home page;
la visualizzazione delle tabelle;
la scheda degli elementi;
la visualizzazione della distinta;
la ricerca delle informazioni;
l’esportazione dei dati.
2.6.1. L’home page

Riportiamo di seguito l’home page del sistema preesistente.
Si denotano immediatamente i tasti che consentono la visualizzazione

delle varie viste più importanti.
Tutti gli elementi. La visualizzazione della tabella elementi.
Elementi. Tutti gli elementi non obsoleti.
58
Schede. Tutte le schede elettroniche Sadel non obsolete.
Prodotti Sadel. Tutti i prodotti non obsoleti.
Circuiti stampati. Tutti i circuiti stampati.
Fornitori, clienti, ordini. Si accede ad un altro menu contenente i

tasti relativi alla “gestione degli ordini”.
Produzione. Si accede a un menu da cui è possibile interrogare il

database secondo query standard.
Magazzino. Il magazzino dell’azienda (corrispondente al “join” tra le

tabelle TBLELEMENTI, TABELLAMASA,
TBLCODICICOSTRUTTORI).
Ricerca dati. Si accede ad una pagina dalla quale si può impostare

una ricerca.
2.6.2. La visualizzazione delle tabelle

Di seguito la visualizzazione che si ottiene premendo dall’home page
il tasto ELEMENTI.
59
Tale visualizzazione è abbastanza chiara anche se si riscontrano i
seguenti difetti:
manca la possibilità di effettuare selezioni se non mediante il tasto

“Ricerca dati” o mediante l’apposito tasto di Access dopo aver
selezionato la parte del campo che interessa;
non si possono eseguire interrogazioni complesse (per es. tutti gli

elementi con data maggiore di …., ecc.)
manca un modo semplice di ordinamento dei dati se non utilizzando le

caratteristiche di Access;
2.6.3. La scheda elemento

Ciccando su un codice elemento dalla tabella “Elementi” è possibile
visualizzare la “scheda dell’elemento”.
60
Tale scheda raccoglie tutte le informazioni relative a un elemento,
dall’eventuale distinta, ai dati della revisione, al magazzino, costi,
costruttore ed allegati. Inoltre è possibile calcolare il numero totale di pezzi
a magazzino e trovare in quali distinte l’elemento in questione è utilizzato.
2.6.4. La visualizzazione della distinta

Mediante il tasto “Visualizza” vicino alla distinta riportata in basso a
destra nella scheda elemento si accede alla visualizzazione completa della
distinta.
2.6.5. La ricerca delle informazioni

Dall’home page la ricerca delle informazioni può essere effettuata
mediante il tasto “Ricerca Dati” che invia alla seguente pagina.
61
Tale operazione individua nella particolare tabella in basso
(contenente solo Codice Sadel, Descrizione, Codice Costruttore,
Costruttore) l’elemento ricercato, dal quale è possibile successivamente
accedere alla scheda elemento. Per effettuare una selezione è comunque
necessario utilizzare il tasto Access “filtro in base a selezione”, impedendo
a chi non conosce l’applicazione di effettuare ricerche più complesse.
2.6.6. L’esportazione dei dati

L’esportazione dei dati in altri formati e la stampa degli stessi e
senz’altro la funzionalità migliore che si ritrova nel database preesistente.
In particolare la perfetta compatibilità di Access con gli altri prodotti
Microsoft consente di esportare i dati in tutti i formati più comunemente
utilizzati (tipica è l’esportazione di una tabella in Excel) con ottimi risultati.
Inoltre è ottimo anche il sistema di stampa che consente di riportare le
tabelle su più pagine mantenendo belle intestazioni e impaginazioni.
Riportiamo di seguito, per esempio, l’anteprima di stampa di una

distinta Sadel.
62
2.6.7. Considerazioni conclusive sull’interfaccia utente
Abbiamo rilevato che l’interfaccia utente su cui si basa il sistema
preesistente presenta i seguenti limiti:
è “Access dipendente”, l’utente che ne fa uso deve conoscere bene

l’applicazione Microsoft;
mancano funzioni che ne facilitino l’usabilità (per esempio un menu

fisso che consenta di navigare fra le varie aree del database);
è difficile effettuare interrogazioni complesse e selezioni successive.
63
3. IL SISTEMA DI CODIFICA
Il sistema di codifica come abbiamo dimostrato nel capitolo

precedente è uno dei punti critici del sistema preesistente, in quanto
identificatore unico degli elementi e di conseguenza punto di raccordo per
tutti gli attributi che afferiscono ad un qualche elemento del database.
3.1. Gli obiettivi da raggiungere

Dall’analisi della qualità dei dati del sistema preesistente abbiamo
individuato nella mancanza di una verifica sui dati inseriti il difetto
maggiore del sistema di codifica. Non è pertanto sbagliata la codifica semi-
parlante utilizzata bensì il fatto che non c’è alcun meccanismo che controlli
l’attinenza dei dati inseriti con il codice.
Sono tre gli obiettivi da raggiungere:
in fase di “importazione dei dati” bisogna ricondurre i codici “errati”

alla codifica scelta (razionalizzazione);
in fase “operativa” bisogna impedire l’inserimento di codici non

attinenti alla codifica (validità dei dati);
in ogni caso è necessario consentire l’inserimento di nuove tipologie

di codici e di poter modificare le esistenti (flessibilità).
3.2. La soluzione proposta

Per raggiungere tutti gli obiettivi proposti è necessario fornire al
sistema che è in fase di sviluppo la capacità di “riconoscere un codice” e di
64
valutarne la correttezza sulla base di un “modello di riferimento” che
rappresenti tutti i possibili formati.
Una volta “istruito il sistema” in tal senso sarà possibile individuare i

codici errati preesistenti, impedirne l’inserimento di nuovi e,
semplicemente modificando il “modello di riferimento”, garantire la
flessibilità necessaria.
3.2.1. La funzione di analisi del codice

La rappresentazione logica della “funzione” necessaria è la seguente.
CODICE
codice corretto codice errato
SIGNIFICATO ERRORE
Come si può notare dato in input il codice da esaminare essa

restituisce l’interpretazione del codice se corretto, mentre restituisce un
errore (e magari anche il motivo dell’errore) se sbagliato. Tutto questo il
programma lo realizza confrontando il codice con le specifiche contenute
nel “modello di riferimento”.
65
3.2.2. La razionalizzazione del sistema di codifica
Dopo aver illustrato il meccanismo con cui agisce la funzione di
analisi del codice, riportiamo lo schema logico di utilizzo di tale funzione
per la razionalizzazione dei dati contenuti nel database.
PRELIEVO DI UN CODICE
CODICE ERRATO
MODIFICA
DB
ELIMINAZIONE
CODICE CORRETTO
Il programma deve prendere ad uno ad uno tutti i codici presenti nel

database e controllarli. Se il codice risulta corretto viene lasciato nel
database, mentre se è errato viene richiesto all’amministratore di
modificare o eventualmente eliminare il codice. Naturalmente il codice
inserito dall’amministratore deve risultare corretto altrimenti viene
restituito nuovamente un errore.
66
3.2.3. Il controllo sui dati inseriti
L’altro processo chiave nel quale la “funzione di analisi del codice”
risulta fondamentale, è il controllo sui dati inseriti , in particolare sui nuovi
codici inseriti nel database.
Tale processo può essere realizzato mediante il seguente schema

logico.
NUOVO CODICE
CODICE CORRETTO
CODICE ERRATO DB
Molto semplicemente, il sistema non accetta il codice inserito

dall’utente finché non si rivela un codice attinente alle specifiche contenute
sul “modello di riferimento”.
3.3. La soluzione operativa: il modello di riferimento

Nei paragrafi precedenti abbiamo citato più volte il “modello di
riferimento” senza però mai addentrarci nella sua definizione.
Esso è in effetti il cuore del sistema di analisi dei codici e consiste in

quella serie di informazioni da cui il programma attinge per valutare la
correttezza dei codici.
Mentre sarebbe noioso e poco produttivo dilungarsi nella descrizione

del programma e di come esso confronti i codici, risulta invece assai
interessante studiare la struttura del “modello di riferimento” che abbiamo
elaborato.
Le due caratteristiche principali che deve rispettare sono:
67
realizzazione di un formalismo preciso che definisca in maniera rigida
e univoca il formato dei codici;
possibilità di modifica, sempre rispettando il formalismo predefinito,

per introdurre nuove tipologie di codice.
3.3.1. L’albero dei formati

L’idea su cui si basa la soluzione operativa che proponiamo è quella
che la codifica può essere espressa mediante uno schema ad albero in
accordo con la gerarchia degli elementi presenti nel database, che
riportiamo nuovamente.
Liv.0
Liv.1
Liv.2
68
Dopo aver ricordato che un codice ha un “formato” costituito da più
“parti” ognuna delle quali può avere diversi significati a seconda del “tipo”
di parte e da un numero di serie che cambia se tutte le parti coincidono,
possiamo costruire lo schema ad albero che dovrà essere rappresentato nel
nostro modello di riferimento.
CODICE ELEMENTO
FORMATO_1 FORMATO_2 FORMATO_3
PARTE_1 PARTE_2 PARTE_3 NUMERO
TIPO_1 TIPO_2 TIPO_3 TIPO_4 TIPO_5
3.3.2. La rappresentazione testuale dell’albero

Lo schema ad albero riportato nel paragrafo precedente può essere
rappresentato mediante un file di testo formattato secondo il seguente
schema.
[formato]
formato1:descrizione_formato1
69
[parte2_formato2]
tipo1_parte2_formato2:descrizione_tipo1_parte2_formato2
Grazie a tale rappresentazione è inoltre possibile associare ad ogni

formato e parte di codice il significato che esso rappresenta e quindi
riuscire ad estrarre informazioni sulla parte parlante del codice.
Mediante l’esempio sul caso reale riportato nella pagina seguente

risulterà tutto più chiaro. In particolare si nota come nella definizione dei
formati le lettere minuscole rappresentino “numeri” mentre quelle
maiuscole lettere, le “xxxx” rappresentano numeri di serie, le “rr” numeri
di revisione e le “R” lettere che individuano revisioni. La stringa “(OBS)”,
dopo la descrizione, indica che il formato è corretto ma non più in uso,
quindi i codici corrispondenti non verranno proposti nella “procedura di
codifica assistita” (di cui parleremo più avanti). Infine il carattere speciale
“#” prima di una riga indica che si tratta di un commento quindi per il
programma è come se tale riga non ci fosse.
Da notare inoltre, oltre ai primi cinque formati relativi alla codifica

preesistente, tre formati obsoleti relativi alla codifica utilizzata dall’azienda
precedente all’attuale (da cui Sadel ha ereditato parte dei codici) e quattro
nuove tipologie di formato che saranno introdotte nel nuovo sistema
secondo la politica attuale per cui qualsiasi elemento può essere revisionato
e di conseguenza avere una distinta ed eventuali documenti allegati in
distinta.
70
L’introduzione di queste nuove tipologie di codice è il risultato dello
sforzo di razionalizzazione che l’azienda ha dovuto compiere affinché il
sistema si attenga alle regole (più restrittive) del nuovo sistema di codifica.
71
Conclusioni
Dopo aver definito operativamente il modello di riferimento e

implementato il sistema di analisi dei codici, è realistico pensare di ottenere
l’azzeramento del numero di codici non corrispondenti al sistema di
codifica predefinito, con notevoli miglioramenti dal punto di vista della
“qualità dei dati”. Inoltre risulta estremamente agevole creare nuovi formati
di codice, basterà scaricare il file di testo dal server, modificarlo secondo il
semplice schema predefinito e ricaricarlo sul server mediante modalità che
riporteremo nel dettaglio nella descrizione dell’interfaccia utente.
72
4. LA GESTIONE DELLE DISTINTE
In questo capitolo cercheremo di individuare i requisiti necessari

relativi alla gestione delle distinte per l’implementazione del nuovo
sistema. Naturalmente non è facile scorporare la questione della “distinta
base” dal resto del sistema in quanto essa è strettamente collegata a tutte le
altre problematiche esistenti, comunque ci proveremo riservandoci
eventualmente di rimandare ad altri capitoli le questioni più rilevanti.
4.1. I limiti del sistema preesistente

Naturalmente, come i requisiti, anche i problemi relativi alla distinta
base sono trasversali all’intero sistema di gestione. Val la pena quindi
ricordare quali sono i limiti del sistema preesistente più evidenti relativi
alla distinta base:
dal punto della struttura del database non sono state definite le chiavi
della tabella;
come per tutti gli altri dati presenti non esiste un sistema di controllo
sulle informazioni inserite, inoltre l’inserimento di una distinta
avviene in modo estremamente insicuro;
la distinta può essere sottoposta a revisione e quindi risente di tutte le

problematiche relative a tale procedura;
manca la possibilità di “esplodere” la distinta, cioè di visualizzare

tutte le distinte da l’elemento radice fino all’ultimo “figlio”.
73
4.2. La distinta base per Sadel
Oltre alla soluzione dei problemi esistenti la progettazione di un
nuovo sistema di gestione deve individuare quei requisiti necessari che nel
precedente sistema erano assenti. Per fare questo è fondamentale capire
qual è il significato di “distinta base” per l’azienda.
La distinta base per Sadel consiste in una “ricetta tecnica” dei prodotti
che essa progetta o realizza. Vi sono in particolare tre tipologie di
assemblati che tipicamente possiedono una distinta base:
i prodotti finiti Sadel, codice del tipo PS0123-01;
le schede elettroniche, codice del tipo HS0123-01;
le parti meccaniche, codice del tipo PM0123-01;
A questi tre si aggiungono inoltre i cablaggi (CB0123-01) che

dovrebbero possedere una distinta base, ma che in realtà non viene mai
inserita (al posto della distinta viene inserito un documento contenente il
progetto dettagliato) e il caso limite dell’inserimento di distinte per
componenti commerciali che però hanno subito lavorazioni all’interno
dell’azienda.
La caratteristica più rilevante sul tipo di “distinta base” utilizzata da

Sadel è la scelta di poter introdurre in distinta come elementi anche i
documenti relativi alla distinta stessa (per esempio, specifiche di progetto,
specifiche di lavorazione o di montaggio, manuali d’uso, ecc.). Essi
vengono in genere inseriti in fondo alla distinta con quantità “zero”. Tale
soluzione consente a chi ha accesso ai dati relativi alla distinta di avere
tutte le informazioni necessarie alla realizzazione del prodotto.
74
4.2.1. Gli elementi e la distinta base
Il nostro obiettivo è quello di modellare la struttura e le funzionalità
della distinta base sugli elementi che più degli altri ne sono soggetti.
Esaminiamo di seguito, con esempi, le varie tipologie di elementi del
database Sadel che in genere hanno una distinta.
I prodotti Sadel
Riportiamo di seguito un esempio realistico (preso da un caso reale
ma semplificato) di distinta di un prodotto Sadel. Sono presenti solo gli
attributi minimi indispensabili affinché la distinta abbia senso più la
descrizione del componente per renderla più chiara al lettore.
DISTINTA PRODOTTO SADEL PS0035-03

Codice elemento Quantità Descrizione
HS0030-03 1 SCHEDA OBOE OUT VER6
AC0060 1 CAVO
MC0013 1 MODULO GSM/GPRS
PM0025-02 1 CUSTODIA IN ALLUMNINIO OBOE OUT
PM0513-01 1 GHIERA DI FISSAGGIO
UN1004 4 VITE
UN1221 14 RONDELLA
PS0035-SM03 0 SPECIFICHE DI MONTAGGIO OBOE OUT VER6
Si nota come il prodotto sia composto da una scheda, che a sua volta
avrà una distinta, da alcuni componenti commerciali (il cavo e il modulo
GSM/GPRS), da alcune parti meccaniche (ghiera e custodia) che
dovrebbero avere a loro volta una distinta, da alcuni componenti meccanici
unificati (vite e rondella) e da un documento contenente le specifiche di
montaggio del prodotto. Da notare il particolare formato del codice del
documento “PS0035-SM03” che nella prima parte riporta l’inizio del
codice di prodotto (PS0035), mentre nella seconda parte vi è specificato il
75
tipo di documento (SM) e il numero di revisione del documento (non del
prodotto!).
Le schede elettroniche
Proseguiamo riportando un esempio di distinta di scheda elettronica
progettata da Sadel. In questo caso tra gli attributi indispensabili per la
definizione della distinta ci sono anche il “reference” che permette di
individuare la posizione dell’elemento sul circuito stampato e la posizione,
che indica semplicemente la posizione dell’elemento in distinta (il motivo
della necessità di questo attributo verrà spiegato in seguito).
DISTINTA SCHEDA SADEL HS0030-03

Pos Codice Qtà Reference Descrizione
1 TS0036 1 CIRCUITO STAMPATO
2 1CC6214 2 CAP7 CAP11 CONDENSATORE CERAMICO
3 1SCI0273 1 U6 DIGITAL INVERTER (CIRCUITO INTEGRATO)
4 1SCO0001 1 CONN15 CONNETTORE
5 1SDI0004 2 D1 D4 DIODO
6 1SIN0001 1 L2 INDUTTORE
7 1LE0001 1 LED1 LED VERDE
8 1RE3004 4 R6-9 RESISTENZA
9 1RE2501 6 RES3 RES8 RES2 RES12-14 RESISTENZA
10 1RE2501 0 RES15 RESISTENZA
11 1STF0002 2 T1-2 TRASFORMATORE AUDIO
12 1TR0020 1 TR1 TRANSISTOR
13 2SCE0020 3 C4 C5 C8 CONDENSATORE ELETTROLITICO VERTICALE
14 2CE0052 2 C1-2 CONDENSATORE ELETTROLITICO RADIALE
15 2SCO1035-01 1 J1 CONNETTORE FISSO 19 POLI MASCHIO
16 2IN0200 1 F1 INDUTTORE
17 2SOP0522 1 OP1 OPTOISOLATORE
18 HS0030-SC02 0 SCHEMATICO
19 HS0030-PC03 0 PCB
20 HS0030-GE03 0 GERBER
21 HS0030-SM03 0 SPECIFICHE DI MONTAGGIO
La prima cosa che si nota guardando l’esempio è che vi è un ordine

ben preciso: il primo elemento è il circuito stampato (la base della scheda),
76
poi si susseguono componenti SMD (il cui codice inizia con “1”),
componenti THD (il cui codice inizia con “2”), infine vi sono i documenti.
I quattro tipi di documenti presenti sono i documenti standard che

vengono associati ad una distinta di scheda: lo schematico, il PCB, il
Gerber e le specifiche di montaggio.
L’unica distinta presente sembrerebbe essere quella relativa al

“connettore fisso” in quanto è l’unico tra gli elementi ad avere associato un
numero di revisione. Questo caso rientra in quei casi limite nei quali risulta
necessaria la revisione di componenti commerciali.
L’ultimo particolare da evidenziare è la presenza in distinta dello

stesso componente due volte: la resistenza “1RE2501”. Il motivo di questa
“stranezza” è che tale componente potrebbe servire (nella posizione
specificata dal “reference”) ma non viene installato sulla scheda (per questo
è presente in quantità nulla). Tale caso particolare crea la necessità di
introdurre l’attributo “posizione” per identificare univocamente i
componenti presenti in distinta.
Le parti meccaniche
Nel seguente esempio riportiamo la distinta della parte meccanica
relativa al prodotto descritto in precedenza.
DISTINTA PARTE MECCANICA PM0025-02

AC0036 1 CUSTODIA IN ALLUMINIO 140X180X70
PM0025-CM01 0 DISEGNO "CAD MECCANICO" CUSTODIA
L’esempio è estremamente chiaro: la parte meccanica è costituita da

un componente commerciale (la custodia) più il progetto che ne descrive
dettagliatamente le caratteristiche.
77
Il caso limite
Il caso limite si realizza nel momento in cui un componente
commerciale affinché possa essere utilizzato deve essere sottoposto a
lavorazioni particolari realizzate all’interno dell’azienda. In questo caso
l’elemento può avere una distinta.
Segue l’esempio relativo.
DISTINTA COMPONENTE 2SCO1035-01

2SCO0152 1 CONNETTORE FISSO 19 POLI MASCHIO
AC0040 19 CONTATTO
Gli assemblati senza distinta

Capita abbastanza frequentemente esaminando il database preesistente
di imbattersi in assemblati già utilizzati in distinta (quindi importanti) privi
di una propria distinta base. Questo, raro per quanto riguarda le schede
elettroniche, è assai frequente per “parti meccaniche” e la regola per i
“cablaggi”. Tale grave incoerenza dal punto di vista logico si spiega assai
bene da un punto di vista operativo. Vi sono due motivi che chiariscono
questo punto:
molti assemblati vengono già acquistati come tali e pertanto non si

dispongono dei dati relativi alla distinta base;
a volte anziché inserire la distinta base si preferisce inserire un

documento allegato contenente le specifiche di progetto.
Nell’esempio riportato nelle pagine precedenti per esempio la parte

meccanica “PM0513-01” non possiede la distinta, ma ad essa è associato
un documento contenente le seguenti specifiche di progetto.
78
L’esplosione della distinta
In ultimo rappresentiamo graficamente l’esplosione della distinta del
prodotto “PS0035-03” evidenziando le relazioni di “parentela” che legano i
vari elementi.
L’esplosione della distinta ha un significato molto importante in

quanto è la rappresentazione globale di un prodotto in tutte le sue parti e
fino a un elevato livello di dettaglio, con tutte le indicazioni di lavorazione
e i progetti necessari per realizzarlo.
Nell’esempio che segue non sono riportate le descrizioni degli

elementi per motivi di spazio.
79
DISTINTA PS0035-03
Codice elemento Quantità
HS0030-03 1
AC0060 1
MC0013 1
PM0025-02 1
PM0513-01 1
UN1004 4
UN1221 14
PS0035-SM03 0
DISTINTA HS0030-03 DISTINTA PM0025-02

Pos Codice Qtà Reference Codice elemento Quantità
1 TS0036 1 AC0036 1
2 1CC6214 2 CAP7 CAP11 PM0025-CM01 0
3 1SCI0273 1 U6
4 1SCO0001 1 CONN15
5 1SDI0004 2 D1 D4
6 1SIN0001 1 L2
7 1LE0001 1 LED1
8 1RE3004 4 R6-9
9 1RE2501 6 RES3 RES8 RES2 RES12-14
10 1RE2501 0 RES15
11 1STF0002 2 T1-2
12 1TR0020 1 TR1
13 2SCE0020 3 C4 C5 C8
14 2CE0052 2 C1-2
15 2SCO1035-01 1 J1
16 2IN0200 1 F1
17 2SOP0522 1 OP1
18 HS0030-SC02 0
19 HS0030-PC03 0
20 HS0030-GE03 0
21 HS0030-SM03 0
DISTINTA 2SCO1035-01
Codice elemento Quantità
2SCO0152 1
AC0040 19
4.3. I requisiti della distinta base

Dopo aver capito bene cosa è la distinta base per Sadel ed individuato
i punti deboli del sistema preesistente è possibile stilare una serie di
requisiti a cui l’implementazione e la gestione della distinta base si devono
attenere:
80
ogni elemento presente nel database può avere una distinta base;
ogni elemento può essere contenuto in una o più distinte;
se un elemento ha una distinta il suo codice deve avere un numero di

revisione;
se il codice di un elemento ha un numero di revisione, l’elemento

corrispondente non necessariamente deve avere una distinta;
per identificare un elemento di una distinta univocamente è necessario

un attributo che ne individui la posizione;
il “reference” è un attributo necessario per la definizione dei

componenti delle schede elettroniche, ma non ha significato per altri
tipi di elemento;
è necessario poter visualizzare l’esplosione di una distinta;
è necessario un controllo sull’inserimento della distinta base;
è auspicabile l’introduzione di una procedura automatica o

semiautomatica di inserimento di una distinta direttamente dal file
B.O.M. generato assieme al progetto.
4.4. La proposta operativa

La nostra proposta di implementazione del sistema di gestione relativa
alla distinta base riguarda due aspetti:
la struttura relazionale della distinta base;
la procedura semiautomatica di inserimento di un file B.O.M. in

distinta.
81
4.4.1. La distinta base come auto-associazione
Data la caratteristica per cui ogni elemento può avere una distinta base
e/o esservi contenuto, è naturale esprimere la distinta come auto-
associazione relativa all’entità ELEMENTI, come in effetti era nel database
preesistente: “un elemento può essere padre o figlio di un altro elemento”.
(0,n) padre
ELEMENTI DISTINTE
(0,n) figlio
Quello che però mancava nella struttura del database preesistente era
la definizione della chiave dell’associazione DISTINTE, inoltre è
necessaria la definizione di tutti gli attributi che la identificano.
Gli attributi che risultano indiscutibilmente legati alla distinta sono:
la quantità;
il reference (anche se necessario solo per i componenti in distinte di

schede).
Inoltre vi sono altri due attributi necessari, ma meno evidenti:
la gestione dell’elemento (questo attributo individua se l’acquisto

dell’elemento presente in distinta è gestito da Sadel o meno, prima era
erroneamente presente come attributo dell’elemento);
l’attributo note (per annotazioni sull’elemento relative alla distinta in

cui è contenuto).
La chiave dell’associazione DISTINTE è naturalmente formata

dall’insieme delle chiavi delle entità che collega, più l’attributo “posizione”
82
per identificare univocamente un elemento in una distinta (ricordiamo che
lo stesso elemento può essere presente più volte nella stessa distinta).
A questo punto possiamo riportare lo schema E/R completo che

rappresenta la relazione tra l’entità ELEMENTI e l’auto-associazione
DISTINTE.
codice_elemento pos
codice_elemento quantità
codice_distinta reference
descrizione
(0,n) padre
data ELEMENTI DISTINTE
approvato
(0,n) figlio gestione

obsoleto note
note
Quello appena riportato è il cuore del sistema informativo in

progettazione ed su questo che costruiremo l’intero e complesso sistema di
relazioni del futuro database.
4.4.2. Procedura di inserimento di una distinta

Per facilitare l’inserimento di una distinta nel database e ridurre il
numero di operazioni manuali da effettuare per preparare i dati
all’inserimento in distinta, evitando rischi di errori banali ma dalle gravi
conseguenze (rimando al paragrafo relativo all’inserimento di una distinta
nel database preesistente) abbiamo pensato di realizzare una procedura
semiautomatica che aiuti l’amministratore del sistema, incaricato
dell’inserimento di una distinta, nel suo compito.
83
L’idea è quella di inserire direttamente il file B.O.M. generato
dall’applicazione con cui si sviluppa il progetto nel programma che dopo
averla “sistemata” e controllata la inserisce direttamente nel database.
La fattibilità di questo dipende dal tipo di “operazioni di

sistemazione” che devono essere svolte:
riordinare i campi del file B.O.M.;
aggiungere come primo campo il codice della distinta (è l’elemento

padre ed è lo stesso per tutti i componenti);
sommare le quantità e unire le stringhe di “reference” per i

componenti con lo stesso codice elemento (a meno che non vi sia la
dicitura “non saldare”);
se presente il campo “non saldare” inserire l’elemento con quantità

pari a zero;
controllare che la quantità dei documenti sia pari a zero ed

eventualmente modificarla;
segnalare se l’acquisto dell’elemento per la distinta è gestito

dall’azienda;
aggiungere eventuali note.
Come si può notare molte di queste operazioni sono meccaniche e

dipendono esclusivamente dal file B.O.M, quindi possono essere eseguite
in maniera automatica da un programma.
Le uniche informazioni che spesso non sono presenti nel file di

B.O.M. (ma che a volte comunque sono presenti) sono quelle relative alle
note ed alla gestione dell’acquisto, per cui la procedura deve essere
comunque realizzata in interazione con l’amministratore.
84
Riportiamo di seguito la rappresentazione schematica della procedura
così come avveniva nel sistema preesistente.
B.O.M.
APPLICAZIONE SOFTWARE
DB
E’ evidente come l’amministratore, in precedenza, aveva l’intera

responsabilità della distinta inserita nel database, perché era egli che dalla
B.O.M. estraeva e modificava i dati da inserire.
La procedura semiautomatica che proponiamo, prevede invece

un’interazione dell’amministratore con il programma. In particolare il
programma compie le seguenti operazioni:
propone una sistemazione del file di B.O.M.;
evidenzia eventuali errori strutturali (per esempio se i codici non sono

presenti nella tabella ELEMENTI, o se manca la quantità di un
elemento);
obbliga l’amministratore a risolvere i problemi strutturali;
85
chiede all’amministratore di controllare la significatività dei dati
inseriti (operazione che un computer non potrebbe mai eseguire);
permette all’amministratore di inserire informazioni aggiuntive

(attributi “note” e “gestione”);
se i dati sono strutturalmente corretti e l’amministratore dà

l’autorizzazione, inserisce i dati nel database.
B.O.M.
APPLICAZIONE SOFTWARE
DB
La procedura sopra illustrata garantisce che i dati inseriti nel database siano
strutturalmente corretti e che siano stati valutati dall’amministratore (che
pertanto ne ha la responsabilità) per quanto riguarda la “correttezza di
significato”.
86
5. LA GESTIONE DELLE
REVISIONI
La gestione delle revisioni e le procedure ad essa connesse sono
senz’altro tra gli aspetti più rilevanti relativi alla distinta base. In
conclusione all’analisi della gestione delle revisioni nel sistema
preesistente avevamo espresso alcuni dubbi riguardo la procedura in uso in
azienda: per comprendere la fondatezza o meno dei nostri dubbi
ripercorriamo il percorso logico che ci deve portare alla procedura corretta,
che naturalmente dipende da che cosa significa “revisione di un elemento”
e dal livello di prestazioni che vogliamo raggiungere.
5.1. Cosa si intende per revisione

Per revisione si intende la modifica di un elemento tale per cui la
funzione dell’elemento stesso non cambia, ma cambiano le sue
caratteristiche prestazionali.
Questa definizione vale per tutti i tipi di elementi che possono essere
soggetti a revisione (quindi tutti). Il seguente schema è relativo alla
revisione di una scheda.
MTBF = 1 ANNO
INPUT SCHEDA-01 OUTPUT
MTBF = 2 ANNI
INPUT SCHEDA-02 OUTPUT
87
Anche le revisioni di documenti, software e componenti assumono il
medesimo significato: cambia la “qualità” del componente ma non la
funzione.
Per gli elementi aventi distinta è inoltre possibile dare una definizione
di revisione più specifica: la revisione di una distinta avviene quando un
elemento presente in distinta viene sostituito con un altro, naturalmente
senza alterane la funzione complessiva della distinta.
A A
SCHEDA-01 SCHEDA-02
B C
5.2. Gli obiettivi da raggiungere

Le caratteristiche fondamentali a cui una procedura di revisione degli
elementi si deve attenere sono le seguenti:
deve consentire l’aggiornamento di un elemento;
deve mantenere le informazioni storiche relative a tutte le revisioni

precedenti;
l’ultima versione di una distinta (per esempio, la versione più recente

di un prodotto o di una scheda) deve contenere tutte le versioni più
recenti dei componenti che la compongono;
deve mantenere le informazioni relative alla composizione di tutte le

distinte precedenti (per esempio di prodotti già prodotti o venduti con
all’interno versioni obsolete di componenti).
88
Si nota da subito come il problema cruciale relativo alla gestione delle
revisioni sia la reperibilità delle informazioni, in particolare le informazioni
riguardo la composizione delle distinte contenenti prodotti revisionati.
5.3. Gli elementi obsoleti

Il concetto di “obsolescenza” di un elemento è strettamente associato
al concetto di “revisione”. E’ naturale che nel momento in cui un elemento
viene revisionato e di conseguenza generata una nuova versione, con le
stesse funzioni ma migliori prestazioni, esso diventi a tutti gli effetti
obsoleto.
Tale informazione è fondamentale ai fini di una corretta gestione della

distinta base ed è per questo che deve essere presente come attributo
dell’elemento anche nella struttura relazionale del database.
“Tutte le versioni di un elemento precedenti all’ultima devono essere

dichiarate obsolete”
Una volta che un elemento è dichiarato “obsoleto” sono due le

principali conseguenze:
esso non dovrà più essere inserito in alcuna nuova distinta (al suo
posto ci deve essere la versione più recente del componente stesso);
se avente distinta, essa non dovrà più essere modificata: è assurdo che
un elemento non più utilizzato sia composto da componenti con
versioni più recenti della versione dell’elemento padre.
5.4. La politica aziendale delle revisioni

La politica delle revisioni già in uso in azienda è la seguente:
89
la revisione può avvenire per tutti gli elementi aventi nel codice un
“numero di versione”;
in particolare, la revisione di un elemento avente distinta avviene se

cambia un suo componente (ma non se cambia solo la versione!);
nel momento in cui esce una nuova versione di un elemento, il codice

sarà uguale a quello della versione precedente, ma con il numero di
revisione aumentato di uno;
tutti gli elementi relativi a versioni precedenti vengono dichiarati

obsoleti;
viene aggiornata la distinta di tutti gli elementi, non obsoleti, che

sono padre dell’elemento revisionato.
L’esempio riportato nello schema seguente chiarisce quali sono le

conseguenze operative a cui la politica di revisione già in uso in azienda
conduce.
90
HS0001-02
HS0001-01 REVISIONE
HS0001-01
(OBS)
HS0001-01
HS0001-01
(OBS)
PS0003-01 PS0003-01
(OBS) X REVISIONE (OBS) X
Y Y
HS0001-01 HS0001-02
PS0123-01
J REVISIONE PS0123-01
J
K K
Come si può facilmente notare la medesima revisione di un

componente ha due effetti diversi a seconda se la distinta in cui è contenuto
è dichiarata obsoleta o meno.
L’essenza del problema

Il punto più delicato della suddetta politica è evidentemente la
possibile modifica di una distinta già presente nel database, che fa perdere
la corrispondenza univoca tra la distinta e i componenti della distinta, tra
l’elemento padre e i propri figli.
Ciò è diretta conseguenza del fatto che il cambiamento di revisione di

un elemento contenuto in distinta non innesca a sua volta la revisione
91
dell’elemento padre a cui la distinta fa riferimento. Tale eventualità
genererebbe una sorta di “effetto domino”, ma eviterebbe di perdere la
corrispondenza univoca tra distinta e componenti. E’ la soluzione
alternativa che proponiamo nel paragrafo seguente.
5.5. L’effetto domino sulle revisioni

L’unica differenza procedurale rispetto la politica esposta in
precedenza è la seguente regola:
la revisione di un elemento avente distinta avviene se cambia un suo

componente o se viene revisionato un componente della sua distinta.
Continua a valere inoltra la regola implicita:
le distinte obsolete non vengono modificate, quindi i loro componenti

non cambiano di versione e di conseguenza sono escluse dall’effetto
domino.
Di conseguenza non è più necessario intervenire sulle distinte di tutti

gli elementi padre non obsoleti; infatti, per ogni distinta in cui è presente il
componente revisionato verrà generata, per “effetto domino”, una nuova
versione dell’elemento padre e quindi una nuova distinta contenente la
versione aggiornata del componente revisionato.
L’esempio dovrebbe chiarire tutto.
92
HS0001-02
HS0001-01 REVISIONE
HS0001-01
(OBS)
HS0001-01
HS0001-01
(OBS)
PS0003-01 PS0003-01
(OBS) X REVISIONE (OBS) X
Y Y
HS0001-01
(OBS)
PS0123-01
(OBS) J
HS0001-01
K
PS0123-01
J REVISIONE
HS0001-02
K
PS0123-02
J
Come si nota l’effetto domino si propaga verso l’alto, infatti la

revisione di una scheda ha innescato a sua volta la revisione del prodotto
contenente la scheda, in generale il susseguirsi di revisioni si propaga fino
alla radice dell’albero delle distinte.
93
In tal modo l’univocità della relazione distinta/componenti è garantita:
il prodotto “PS0123-01” dell’esempio sarà sempre associato
esclusivamente alla scheda “HS0001-01” senza possibilità di equivoci.
5.6. Il confronto tra le due alternative

Per comprendere quale sia l’alternativa migliore tra le due politiche di
revisione riportiamo in una tabella il confronto sui vari punti.
Senza effetto domino Effetto domino

Il cambiamento di un elemento alla base Il cambiamento di un elemento alla base
dell’albero della distinta implica una sola dell’albero della distinta implica la
revisione. propagazione di nuove revisione fino
all’elemento radice.
Il totale delle revisioni per scheda o Il totale delle revisioni per scheda o
componente è in media basso (esempio: se componente sarebbe in media
un prodotto contiene 5 schede e per ogni notevolmente più alto (esempio: se un
scheda escono 3 revisioni, viene prodotto contiene 5 schede e per ogni
aggiornata la distinta del prodotto 15 scheda escono 3 revisioni, per il prodotto
volte, ma il numero di revisione non verranno generate ben 15 revisioni e
cambia). relative distinte).
Si perdono informazioni storiche sulla Vi è la reperibilità totale delle
composizione esatta delle vecchie distinte informazioni relative a vecchie distinte
(esempio: se un cliente riscontra un successivamente sottoposte a revisioni (a
problema su un prodotto non si è in grado un determinato codice di scheda
di sapere con certezza quali versioni di corrisponde esattamente una e una sola
schede sono presenti su di esso). Possibili distinta perché non è mai stata
problemi in fase di ASSISTENZA. modificata).
In fase di PRODUZIONE non vi sono In fase di PRODUZIONE non vi sono
problemi perché vi è la certezza che ogni problemi: l' ultima revisione di un prodotto
distinta non obsoleta è composta con le ha, in distinta, tutte le ultime revisioni dei
ultime versioni esistenti dei suoi sui componenti.
componenti.
Se un componente è presente in più Un componente con più padri propaga
distinte (ha più padri), la sua eventuale l’aggiornamento di revisioni in più
revisione, non propagandosi, non influisce direzioni con l’effetto collaterale di
sul numero di revisione degli elementi ritrovarsi nuove revisioni di prodotti che
padre. potrebbero non essere più in catalogo
perché, per esempio, l’azienda non è più
interessata nella loro produzione.
94
La soluzione più affidabile e con meno punti deboli sembrerebbe
l’effetto domino. L’unico problema associato ad esso è difatti il maggior
numero di revisioni (e quindi di codice e relative distinte) da gestire.
Risulta meno grave di quello che appare, invece, il problema della

reperibilità per la politica “senza effetto domino” già in uso in azienda, in
quanto nel momento in cui si genera una nuova versione relativa ad un
elemento si tiene traccia delle caratteristiche della revisione. In particolare
si memorizza la “descrizione della revisione”, la “motivazione”, la “data di
revisione”, ed eventualmente si associa, mediante un link, un documento
che rappresenta nel dettaglio le modifiche effettuate. Data una qualsiasi
versione di un elemento è nota la “data” a cui essa si riferisce. Mediante il
meccanismo inverso è pertanto possibile risalire alla versione in uso in una
certa data passata. Quindi è possibile, conoscendo per esempio la data in
cui il prodotto fu venduto, risalire alla composizione esatta della distinta
con le versioni dei componenti allora in uso. La coppia distinta/data
individua pertanto univocamente i componenti della distinta a quella data.
La scelta aziendale
L’azienda posta di fronte alla scelta tra le due alternative di gestione
delle revisioni, dopo aver considerato i pro e i contro ha optato per
mantenere la politica in uso, ritenendola più coerente con le metodologie
fino ad ora adottate e sufficientemente solida. Sulla scelta ha pesato
decisamente la propagazione verso l’alto generata dall’effetto domino, che
spinge per la generazione di nuove revisioni anche per prodotti che, per
esempio, potrebbero essere ormai fuori listino, senza essere ancora
considerati obsoleti.
95
La nostra opinione è in disaccordo con tale scelta in quanto una
definizione migliore dell’obsolescenza consentirebbe di limitare la
propagazione verso l’alto dell’effetto domino solo agli elementi padre
effettivamente ancora in uso. Basterebbe che invece di considerare obsoleti
solo gli elementi soggetti a revisione, siano dichiarati obsoleti anche i
prodotti non più utilizzati per risolvere tale problema.
Alcuni dubbi conclusivi

Rimangono inoltre alcuni dubbi sulla correttezza concettuale di alcune
procedure in uso relative alla gestione delle revisioni.
L’uscita di una nuova revisione, come abbiamo detto, non cambia la

funzione dell’elemento ma può cambiare altre proprietà, come per
esempio l’affidabilità. Il cambiamento dell’affidabilità di un
componente, può di conseguenza cambiare l’affidabilità dell’elemento
che lo contiene. Il cambiamento dell’affidabilità di un elemento non è
sufficiente per affermare che tale elemento è diverso da quello
precedente e quindi che è necessaria l’uscita di una nuova revisione
dell’elemento stesso?
E’ corretto, da un punto di vista concettuale, prevedere una procedura

standard per la modifica di dati già archiviati in un database? A mio
avviso questo è lecito solo se i dati suscettibili di tale modifica non
hanno un valore storico. E’ questo il caso delle distinte?
96
6. LA PROCEDURA DI
APPROVAZIONE
Vi sono alcuni tipi di informazioni che prima dell’inserimento
all’interno del database necessitano di approvazione da parte dell’utente
che ne detiene la responsabilità.
Tale elemento è fondamentale per una chiara e precisa distribuzione

delle responsabilità tra i dipendenti dell’azienda e si scontra con la
decisione aziendale di centralizzare l’inserimento dei dati attribuendo ad un
solo utente “amministratore” tale compito.
Vi sono due tipi di operazioni sul database, in particolare, che

necessitano di “approvazione” da parte dell’utente in quanto informazioni
ritenute critiche per l’azienda.
codifica dell’elemento;
revisione di un elemento.
6.1. La situazione preesistente

Come abbiamo già avuto modo di vedere, nel sistema preesistente, la
codifica e la revisione di un elemento avviene secondo la procedura
implicita seguente:
il progettista richiede la codifica o la creazione di una revisione

all’amministratore e gli fornisce i dati da inserire;
l’amministratore attribuisce l’approvazione degli stessi a colui che l’ha

richiesta o a colui che ne detiene la responsabilità;
l’amministratore inserisce i dati nel database.
97
Tale procedura è priva di strumenti di verifica da parte di colui che
effettivamente detiene la responsabilità sui dati. Paradossalmente sarebbe
possibile che un errore di inserimento da parte dell’amministratore risulti
attribuito alla persona il cui nome è inserito nel campo “approvato” del
database, o, ancor peggio, che per errore l’amministratore attribuisca
l’approvazione alla persona sbagliata.
Questa mancanza di controllo esaspera ancora maggiormente la

responsabilità delle informazioni verso l’amministratore, privando di
conseguenza di valore i dati relativi all’approvazione inseriti nel database.
6.2. Come affrontare il problema

Il problema relativo all’approvazione nasce da una confusione di
fondo sull’attribuzione delle responsabilità. E’ necessario scegliere
chiaramente su chi si vuole far ricadere la responsabilità dei dati inseriti.
Se la responsabilità la si vuol far ricadere su una sola persona per

poter meglio identificare la possibile fonte di errori, l’esistenza di un
attributo “approvato” crea solo confusione e può spingere l’amministratore
a disinteressarsi della validità dei dati in quanto “sembra” che la
responsabilità non sia sua. A questo punto sarebbe meglio rimuovere tale
attributo e responsabilizzare maggiormente l’unico responsabile del sistema
in modo che si assicuri che i dati inseriti siano corretti. Il livello di
responsabilità da affidare ad egli, in questo caso, sarebbe veramente molto
alto e in alcuni casi potrebbe generare problemi: per esempio se gli si
richiedesse di inserire dati di un elevato livello tecnico, difficilmente
valutabili.
L’altra soluzione è quella di mantenere una distinzione delle

responsabilità, quanto meno per quanto riguarda i dati più importanti. Si
98
renderebbe necessaria, in tal caso, una procedura che garantisca la diretta
responsabilità di chi effettivamente deve dare l’approvazione di una
informazione. La procedura che presentiamo di seguito si fonda su tale
scelta.
6.3. Il protocollo di approvazione

La soluzione che proponiamo relativa alla procedura di approvazione
si basa su due presupposti fondamentali che devono essere implementati
nel sistema:
la possibilità da parte del programma di inviare e-mail agli utenti;
la possibilità da parte del sistema di riconoscere gli utenti.
Il protocollo si articola in cinque fasi:
richiesta di codifica o di revisione;
“login” dell’amministratore;
inserimento dei dati;
“login” dell’utente;
approvazione finale.
Nelle seguenti pagine riportiamo schematizzate graficamente le

cinque fasi relative al protocollo di approvazione.
99
FASE 1: RICHIESTA DI CODIFICA (O DI REVISIONE)
UTENTE AMMINISTRATORE
L' utente richiede all'
amministratore DEL SISTEMA
la nuova codifica di un elemento o
la generazione di una nuova revisione.
La richiesta viene effettuata mediante un'e-mail
contenente i dati necessari all'
inserimento.
FASE 2: LOGIN DELL'AMMINISTRATORE
DEL SISTEMA
1) L' amministratore
richiede 3) Se l'
amministartore ha i
l'identificazione dovuti permessi viene restituita
l'
autorizzazione all'
uso (sia "in
scrittura" che "in lettura")
del programma di gestione
PROGRAMMA
DI GESTIONE
2) Il programma confronta i dati di LOGIN

inseriti dall'
amministratore con quelli presenti
nel database
DATABASE
SADEL
DB
100
FASE 3: INSERIMENTO DEI DATI
1) L'amministratore AMMINISTRATORE
UTENTE inserisce i dati relativi alla DEL SISTEMA
codifica o alla revisione
di un elemento e
3) Il programma sceglie se farlo 2) Il programma controlla e
invia un'email all'
utente approvare e da reinvia iterativamente i dati
informandolo che gli è chi all'
amministartore finché
stata richiesta una non risultano formalmente
approvazione corretti
PROGRAMMA
DI GESTIONE
4) Vengono inseriti nel database tutti i dati tranne

la conferma di approvazione dell' utente
DATABASE
SADEL
DB
101
FASE 4: LOGIN DELL'UTENTE
DEL SISTEMA
1) L'utente richiede
l'
identificazione
3) Se l' utente ha i
dovuti permessi viene
restituita l'
autorizzazione
approvazione e all'
all' uso
"in lettura" del programma di
gestione PROGRAMMA
DI GESTIONE
2) Il programma confronta i dati di LOGIN

inseriti dall'
utente con quelli presenti
nel database
DATABASE
SADEL
DB
102
FASE 5: APPROVAZIONE FINALE
1) Dopo aver controllato i dati inseriti

l'
utente decide se approvarli o meno, AMMINISTRATORE
UTENTE
inviando la sua scelta DEL SISTEMA
al programma di gestione
2) Viene inviata una e-mail

all'
amministratore informandolo
della scelta fatta
PROGRAMMA
DI GESTIONE
3) Se l'
utente ha approvato i dati inseriti viene
aggiunta, a tali dati, la "firma"
dell'
utente stesso
N.B. Se l'approvazione non è DATABASE

concessa, i dati inseriti rimangono SADEL
nel database, ma senza la "firma" DB
dell'
utente.
E’ da chiarire, probabilmente, il perché è consentita la mancata

approvazione di un elemento o di una revisione. Questa scelta dipende
dalla mole di dati che altrimenti sarebbero soggetti ad approvazione (si
pensi solamente a gli oltre 9000 elementi codificati) e al fatto che si vuole
lasciare all’amministratore la decisione su quali siano le informazioni
importanti. Un elemento approvato è “garantito” dal nome della persona
che lo approva e sarà pertanto preferibile nell’uso rispetto ad un
equivalente non approvato.
103
6.4. I miglioramenti apportati
Nelle cinque fasi descritte in precedenza si può notare come tale
protocollo realizza un’interazione tra amministratore, utente e database
armonizzate dal programma di gestione.
Questa tipo di soluzione consente di distribuire correttamente le

responsabilità nonché di effettuare ripetuti controlli sui dati più importanti.
Difatti le informazioni suscettibili di approvazione sono esaminate
molteplici volte:
l’utente, che ne richiede l’inserimento nel database, controlla il

“significato”;
l’amministratore, che le inserisce nel database, controlla sia il

significato che la correttezza formale;
il programma di gestione verifica la correttezza strutturale;
l’utente, che le deve approvare, controlla la correttezza di

“significato” dopo che sono passate sotto le modifiche
dell’amministratore e del programma di gestione.
Si può affermare pertanto che il protocollo di approvazione, una volta

implementato, garantisca due aspetti fondamentali del sistema di gestione:
una corretta distribuzione di responsabilità;
la sicurezza della correttezza delle informazioni ritenute più importanti.
104
7. LA GESTIONE DEI DOCUMENTI
La gestione dei documenti è un altro degli aspetti fondamentali,
fortemente collegato alla distinta base. Tra i documenti infatti ritroviamo i
progetti e le specifiche dei prodotti e delle schede realizzati nell’azienda,
senza i quali la distinta base sarebbe un semplice elenco di componenti
senza che sia in alcun modo possibile collegarli fra loro. Sarebbe come
avere una lista di ingredienti senza la ricetta che spiega come impiegarli per
fare la torta. Inoltre i documenti rappresentano, per l’azienda, le
“informazioni riservate”, quelle per cui la protezione deve raggiungere i
livelli più elevati possibili. Per questo si ritiene fondamentale un sistema
che garantisca contemporaneamente la sicurezza e la corretta gestione dei
documenti.
7.1. I documenti nel sistema preesistente

La metodologia di gestione dei documenti nel sistema preesistente
separa l’inserimento fisico del documento nel server, dall’inserimento del
link relativo nel database.
LINK
DB
105
Come per innumerevoli altre funzioni implementate nel sistema
preesistente anche questa è affidata all’amministratore, che ne assume
l’intera responsabilità.
Il problema comunque va al di là della responsabilità su eventuali

errori, infatti risulta assai più pericolosa la relazione unilaterale che vi è tra
link e documento associato. Per la natura stessa del concetto di “link”
(collegamento), cioè di puntatore a una posizione ben precisa, esso non
risente di eventuali modifiche o cancellazioni del file a cui esso punta. Se
per esempio un file viene cancellato dal server, tale cambiamento non viene
rilevato dal database che continuerà ad avere un link che però, quando
servirà, si rivelerà interrotto. Nel database preesistente sono presenti circa
25 documenti con link interrotto.
La soluzione di questo grave problema è il requisito fondamentale su

cui costruire un valido sistema di gestione dei documenti.
7.2. Una soluzione semplice e potente

La soluzione al problema va ricercata nell’unione di quelle due
operazione di base che nel sistema preesistente erano separate:
l’inserimento del documento nel server;
l’inserimento del link nel database.
Sia il link, che il documento vero e proprio devono essere sotto la

protezione del “programma di gestione” che ne deve garantire una
“gestione coordinata”, in particolare deve implementare le seguenti
funzioni:
consentire l’inserimento del link solo dopo che il file è stato inserito
nella directory del server;
106
all’atto dell’inserimento accertarsi che il link punti al relativo file;
impedire la modifica del file;
consentire l’eliminazione o la sostituzione di un file eliminando o

cambiando anche il link presente nel database.
Lo schema seguente rappresenta l’inserimento di un documento,

secondo la metodologia proposta.
LINK
DB
In particolare si nota come l’amministratore “dia in affidamento” il

documento al programma di gestione, il quale oltre ad inserire il
107
documento in una predefinita directory del server, crea il link corretto e lo
inserisce all’interno del database.
Con la medesima logica di gestione si possono implementare anche le

operazioni di sostituzione e di eliminazione dei documenti conservati nel
server.
7.3. Obiettivi raggiunti

Mediante la gestione congiunta dei documenti e dei link, descritta nel
paragrafo precedente, è possibile raggiungere elevati livelli di qualità nella
gestione dei documenti. In particolare si ottengono i seguenti risultati:
azzeramento del numero di link interrotti;
rintracciabilità dei documenti mediante ricerca sul database;
possibilità di eliminazione e sostituzione dei documenti senza

rischiare di alterare la validità e l’integrità dei dati;
semplificazione della procedura di inserimento dei documenti per

l’amministratore.
108
8. RICERCA E VISUALIZZAZIONE
DELLE INFORMAZIONI
L’importanza della ricerca e visualizzazione dei contenuti è almeno
pari all’importanza dei contenuti stessi; informazioni prive di una adeguata
interfaccia per la consultazione risultano essere inutili e incapaci di
svolgere il ruolo per cui esistono: informare.
In questo capitolo cercheremo di individuare i requisiti necessari per

una corretta ricerca e presentazione dei contenuti all’utente finale e
svilupperemo la logica di gestione relativa.
Tale lavoro prende forma da alcune considerazioni di base:
è necessario evitare di stravolgere la struttura di visualizzazione

presente in precedenza, per attenuare le difficoltà del passaggio dal
sistema preesistente a quello in studio;
vi sono alcune “viste” (query standard) indispensabili;
è necessaria una tipologia di ricerca per livelli successivi: da una

ricerca molto generale ad una ricerca estremamente specifica;
serve un menù fisso per la navigazione che consenta all’utente di

muoversi nelle varie aree dell’interfaccia in modo semplice ed
intuitivo;
è necessario prevedere metodologie per l’esportazione in formato

Excel delle tabelle;
servono strumenti adeguati per la stampa delle tabelle, delle distinte e

delle schede degli elementi.
109
8.1. Il limite del sistema preesistente
L’unico problema grave del sistema preesistente riguarda
l’impossibilità di eseguire interrogazioni altamente specifiche per una
determinata categoria di elementi che, d’ora in avanti, chiameremo
“componenti speciali”. Si tratta di componenti per circuito stampato,
presenti in elevata numerosità, per i quali frequentemente è necessario
effettuare ricerche sulle specifiche caratteristiche funzionali.
I componenti di cui stiamo parlando sono:
condensatori;
resistenze;
circuiti integrati;
connettori;
diodi;
transistor.
Nel sistema preesistente le ricerche sulle caratteristiche funzionali di

questi componenti venivano effettuate mediante semplici ricerche testuali
all’interno del campo descrizione della tabella degli elementi. Questo
dovrebbe presupporre due condizioni:
che il campo descrizione sia definito mediante un formalismo preciso;
che sia necessario effettuare solo ricerche esatte.
In realtà nessuna delle condizioni sopra citate è rispettata.
8.1.1. La soluzione al problema dei componenti speciali

La necessità di un formalismo preciso per il campo descrizione dei
componenti speciali era già stata recepita dall’azienda che ha sviluppato
110
documenti che stabiliscono le regole per la definizione di tale campo.
Basterebbe pertanto ricondurre i dati esistenti al formato scelto e
controllare l’inserimento dei nuovi dati per garantire la possibilità di
ricerche esatte sui componenti speciali.
In realtà ciò non è sufficiente in quanto abbiamo rilevato la necessità

di effettuare anche ricerche “non esatte”, per esempio trovare tutti i
condensatori con tensione maggiore di un certo valore prefissato.
codice_elemento .....
ELEMENTI
(p,e)
CIRCUITI
CONDENSATORI RESISTENZE CONNETTORI DIODI TRANSISTOR
INTEGRATI
..... ..... ..... ..... ..... .....
Dalla gerarchia degli elementi si nota come le sottocategorie relative

ai componenti speciali non possano essere incorporate nell’entità padre
ELEMENTI, pena la perdita di tutti gli attributi importanti contenenti le
caratteristiche dei componenti.
Per consentire la realizzazione di ricerche “non esatte” è necessario

rappresentare tali caratteristiche funzionali, diverse per ogni tipologia di
componente, mediante entità collegate mediante una relazione di
appartenenza all’entità degli elementi. Di seguito riportiamo, per chiarezza,
lo schema E/R, dopo l’eliminazione delle gerarchie, relativo a due
categorie di componenti speciali: i condensatori e le resistenze.
111
codice_elemento
(0,n) ELEMENTI
(0,n)
(1,1) (1,1)
CONDENSATORI RESISTENZE
..... .....
Tale schema si concretizza in una serie di tabelle, ognuna relativa ad

un componente speciale, aventi come chiave il codice dell’elemento a cui si
riferiscono e come attributi tutte le varie caratteristiche funzionali
dell’elemento.
L’insieme degli attributi del componente speciale sostituiscono, per

tali componenti, il campo “descrizione” presente nell’entità degli elementi.
Per consentire comunque una veloce identificazione del componente, il
campo “descrizione” viene generato mediante un semplice funzione
direttamente dagli attributi del componente relativo in maniera univoca,
permettendo così anche una eventuale ricerca esatta col “vecchio sistema”.
8.1.2. L’importazione del campo descrizione

La creazione di sei nuove entità derivate dall’entità degli elementi
genera un problema di “trasporto” dei dati, contenuti nel campo descrizione
112
dei componenti speciali preesistenti, all’interno delle nuove tabelle. Per
realizzare tale trasposizione dei dati è necessario:
interpretare il campo descrizione;
inserire i dati negli appropriati campi delle nuove tabelle;
segnalare i componenti per i quali non è stato possibile interpretare il

campo descrizione correttamente.
L’interpretazione del campo descrizione viene realizzata grazie ad un

meccanismo simile a quello usato per l’interpretazione dei codici.
Mediante un file di testo, viene istruito il sistema sul formato che il

campo descrizione deve avere.
Il sistema confronta il campo descrizione del componente col formato

restituendo il significato delle varie parti del campo.
Se il sistema comprende tutte le parti del formato lo inserisce nei

rispettivi campi della tabella del componente.
Se lo riconosce solo in parte e il componente non è utilizzato in altre

tabelle, lo elimina.
Se lo riconosce solo in parte e il componente è utilizzato, inserisce nella

tabella del componente i dati che ha riconosciuto e segnala il
riconoscimento parziale inserendo in un apposito campo “altro”,
presente in tutte le tabelle dei componenti, l’intera descrizione che non
ha riconosciuto completamente.
Riportiamo di seguito parte del file di testo necessario per realizzare

tale procedura. Da notare come i valori numerici siano rappresentati da un
asterisco.
113
8.2. Le viste principali e la struttura delle informazioni
Per poter stabilire una adeguato sistema di visualizzazione e ricerca
delle informazioni è necessario comprendere quali siano le interrogazioni
che più di frequente vengono poste al database. Se tali interrogazioni
114
raggruppano una categoria di istanze ben definita e con caratteristiche ed
esigenze di visualizzazione simili, si denominano “viste”.
Le viste fondamentali sono le seguenti:
“elementi”: tutti gli elementi presenti nel database;
“prodotti”: tutti i prodotti non obsoleti con evidenziazione di quelli

aventi distinta;
“schede”: tutte le schede elettroniche non obsolete con evidenziazione

di quelle aventi distinta;
“circuiti stampati”: tutti i circuiti stampati;
“documenti interni”: tutti i documenti ad uso interno (moduli, ecc.)

con riportato il link associato;
“magazzino”: tutti gli elementi presenti in magazzino con evidenziato

anche il costruttore e il relativo codice e il numero di pezzi
attualmente presenti;
“codici costruttori”: tutti gli elementi aventi associato un codice

costruttore ed eventualmente gli alternativi.
“fornitori”: tutti i fornitori con i relativi dati.
Come si può notare, tutte le viste descritte tranne quella relativa ai

fornitori, rappresentano sottocategorie di elementi e sono pertanto
identificate univocamente dal “codice elemento”. Questo significa che è
sempre possibile ricondursi ad una “scheda elemento” che raggruppi in sé
tutte le informazioni relative all’elemento stesso. L’informazione relativa
alle caratteristiche dell’elemento è pertanto un sottoinsieme della
informazione più vasta relativa alla categoria a cui l’elemento appartiene.
Da notare, infine, che il medesimo elemento può essere presente in diverse
115
“viste” che pertanto non si escludono a vicenda (per esempio un prodotto
che è in magazzino).
Le viste corrispondono alle opzioni che devono essere presenti nel

menu di navigazione.
8.3. La struttura di visualizzazione

Le problematiche relative alla visualizzazione e alla ricerca delle
informazioni nonostante siano fortemente interconnesse, debbono essere
studiate separatamente in quanto corrispondono a due sistemi di
consultazione dei dati alternativi: è possibile trovare un’informazione sia
mediante una ricerca che mediante un susseguirsi di visualizzazioni più
specifiche o (come accade il più delle volte) mediante l’utilizzo di entrambi
gli strumenti.
Per quanto riguarda la visualizzazione si è scelto di mantenere una

struttura simile a quella preesistente, che consente di muoversi dalla prima
pagina verso l’informazione cercata mediante la scelta di viste successive.
Nell’esempio di seguito riportiamo una possibile rappresentazione

gerarchica per la visualizzazione delle informazioni, su quattro livelli:
livello zero: l’home page;
livello “viste”: tutte le viste più importanti del database;
livello “elementi”: tutti gli elementi relativi alla vista selezionata;
livello “caratteristiche”: tutte le caratteristiche relative all’elemento

scelto.
116
LIVELLO ZERO
HOME PAGE
LIVELLO "VISTE"
PRODOTTI MAGAZZINO COSTRUTTORI
LIVELLO "ELEMENTI"
PS0001 PS0002 PS0003
LIVELLO
DISTINTA REVISIONE COSTO
"CARATTERISTICHE"
8.4. La ricerca
La ricerca costituisce lo strumento più semplice ed immediato per
trovare facilmente ciò che si cerca o quantomeno per individuare la
categoria in cui cercare “visivamente” l’informazione desiderata.
Come per la visualizzazione anche la ricerca deve essere possibile su

più livelli di dettaglio e deve essere correttamente gestita dall’utente
affinché raggiunga le migliori prestazioni.
Le tipologie di ricerca che abbiamo deciso di implementare sono:
ricerca semplice;
ricerca avanzata.
8.4.1. La ricerca semplice

Questa tipologia di ricerca consente di effettuare una ricerca “esatta”
all’interno di una specificata “vista” ed eventualmente all’interno di un
determinato “campo” della “vista”.
Per ricerca esatta si intende la ricerca di una corrispondenza diretta tra

la parola che si inserisce e il risultato ottenuto e non di un determinato
117
intervallo di soluzioni che si avvicinano alla ricerca. Questo tipo di ricerca
consente in ogni caso di effettuare ricerche abbastanza complesse anche
grazie alla possibilità di uso dei caratteri “jolly” (o “wild card”).
In particolare se nella parola inserita per la ricerca non è presente

alcun “wild card” il sistema ricerca tutte le istanze i cui campi contengono
tale parola: per esempio la ricerca della parola “DSP” produrrà tra i risultati
anche la descrizione “SCHEDA DSP FS”. Se invece viene fatto uso dei
“wild card” il risultato ne terrà conto: per esempio la ricerca della parola
“HS*” produrrà come risultato tutti i codici che iniziano per HS.
8.4.2. La ricerca avanzata

La ricerca avanzata, come quella semplice, svolge il suo ruolo
all’interno di una specificata “vista”, ma con alcuni importanti vantaggi:
è possibile specificare i criteri della ricerca sulla base del tipo di

campo;
è possibile impostare più criteri contemporaneamente;
è possibile effettuare più ricerche successive;
è possibile stabilire un ordinamento del risultato.
La cosa più interessante è senz’altro la possibilità di specificare i

criteri di ricerca sulla base del tipo di campo. In particolare ciò si
concretizza nelle seguenti implicazioni logiche.
118
TIPO DI CAMPO FORM
parola ricercata
TESTUALE ordine di grandezza
intervallo su cui ricercare
NUMERICO
= valore K (E +03) ± valore
menu a tendina con l'
elenco delle opzioni possibili
OPZIONI opzione_1
> giorno mese anno

DATA
menu a tendina per la scelta dell'

intervallo temporale
Per i campi testuali vale l’uso dei “wild card” con le stesse
metodologie della ricerca semplice.
La ricerca avanzata consente, per esempio, di effettuare la ricerca di

un componente “condensatore” con capacità maggiore di 2pF, tensione pari
a 50V codificato dopo il primo gennaio 2003 con precisione compresa tra
lo 0,25 e l’1,75 % (1±0.75), ordinato per “codice elemento”.
8.5. La progettazione operativa

La progettazione della logica di gestione relativa alle funzionalità di
visualizzazione e di ricerca consiste nel realizzare strumenti operativi che
consentano all’utente di interagire col sistema. In questo paragrafo
presenteremo a grandi linee le funzioni che riguardano la visualizzazione
delle informazioni sia come risultato di una “vista” sia come risultato di
una ricerca.
L’idea di fondo è quella che in ogni caso le informazioni da riportare

sono frutto di una query SQL eseguita su una tabella del database o, come
accade più frequentemente, su una “vista” che non è altro che una tabella
temporanea frutto di selezioni e “join” sulle tabelle già esistenti.
119
E’ necessaria pertanto una funzione che dato in input una query SQL
restituisca la visualizzazione del risultato corrispondente, che nella realtà
sarà una tabella in HTML.
FUNZIONE DI
QUERY SQL VISUALIZZAZIONE HTML
La “funzione di visualizzazione” consente, da sola, di visualizzare

tutte le tabelle e “viste” del database. Dopo aver creato la “vista” basta
difatti inserire in input la query SQL “select * from nome_tabella” per
ottenere sotto forma tabellare tutte le istanze relative alla tabella o alla vista
desiderata.
Per quanto riguarda la ricerca le cose si complicano leggermente, in

quanto, non è pensabile di chiedere all’utente direttamente l’espressione
SQL della ricerca, pena l’impossibilità di effettuare ricerche da parte
dell’utente medio che non conosce il linguaggio SQL. E’ necessario
pertanto una funzione che data la struttura della vista proponga all’utente
un modulo con determinati campi (“form”) da compilare e che generi delle
specifiche precise dalle quali sarà possibile creare una query SQL che
rappresenti in modo “strutturato” le scelte dell’utente.
Nello schema di seguito riportiamo la sequenza logica delle funzioni

che consentono di visualizzare il risultato di una ricerca a partire dalla
compilazione della “form” da parte dell’utente.
120
VISTA FORM SPECIFICHE
FUNZIONE DI
QUERY SQL SELEZIONE
FUNZIONE DI
VISUALIZZAZIONE HTML
8.6. Esportazione e stampa delle informazioni

Oltre alla ricerca delle informazioni è estremamente importante
definire delle metodologie per la stampa e l’esportazione dei dati.
Per quanto riguarda l’esportazione essa è realizzabile mediante una

“funzione di visualizzazione” con le medesime caratteristiche di quella
illustrata in precedenza, ma che in output restituisce un file in formato
C.S.V. (Comma Separated Values), che può essere interpretato
agevolmente dall’applicazione Microsoft Excel.
La stampa si può realizzare direttamente mediante il comando “print”

del browser utilizzato dal programma di gestione, semplicemente
impostando in maniera adeguata i fogli di stile C.S.S. (Cascading Style
121
Sheet) che istruiscono il browser su come visualizzare i contenuti a seconda
del supporto (schermo o stampa). L’unica eccezione riguarda la stampa di
distinte che data l’importanza richiede l’implementazione di una pagina
“printer friendly” che viene interpretata meglio dalla stampante.
122
9. LA SICUREZZA
La sicurezza è uno degli aspetti fondamentali di un qualsiasi sistema
informativo in quanto proteggendo i dati da possibili inquinamenti ne
garantisce l’integrità e la validità degli stessi.
In questo capitolo affronteremo il tema “sicurezza” sotto due aspetti

differenti:
gestione dei permessi di accesso;
sistemi di prevenzione e recupero dei dati in caso di crash del sistema.
Tralasciamo di proposito il tema relativo alla “sicurezza del server”, in

quanto oltre ad essere estremamente complesso, non è pertinente con
questo elaborato.
9.1. Gestione dei permessi di accesso

Nel sistema preesistente, la gestione dei permessi era estremamente
semplice, tutti gli utenti avevano accesso al database solo in letture mentre
solo l’amministratore aveva accesso al database anche in scrittura.
Nel sistema che si sta implementando tale soluzione risulta

insufficiente in quanto si vuole impedire l’accesso al database (anche in
lettura) ad un utente non identificato.
La riservatezza delle informazioni deve essere garantita da un accesso

mediante password e da alcuni livelli di permesso, diversi a seconda delle
caratteristiche dell’utente. In particolare si vorrebbero realizzare tre livelli
di permesso:
amministratore (accesso in lettura e in scrittura su tutto il database);
123
utente interno Sadel (accesso in lettura su tutto il database);
utente esterno (accesso in lettura su tutto tranne che sulle informazioni

relative ai costi, al magazzino e ai fornitori).
9.1.1. Gli strumenti offerti da MySQL

Il database MySQL prevede alcuni strumenti per la gestione degli
utenti mediante i quali è possibile assegnare o revocare permessi per le
diverse operazioni sulle tabelle. Di seguito riportiamo la sintassi dei
suddetti strumenti tratto dal manuale ufficiale di MySQL.
Mediante questa sintassi il permesso per l’amministratore sarà

pertanto:
GRANT ALL ON *.* TO tizio@localhost IDENTIFIED BY 'sadel'
WITH GRANT OPTION;
Con tale istruzione si autorizza l’amministratore “tizio” dall’host
“localhost” con password “sadel” ad accedere sia in lettura che in scrittura
(GRANT ALL) su tutti i database e su tutte le tabelle (ON *.*) e a
concedere altri permessi (WITH GRANT OPTION).
124
Mentre per l’utente generico sarà:
GRANT CREATE,SELECT ON sadel.* TO caio@localhost IDENTIFIED
BY 'sadel';
Con tale istruzione si concedono i permessi di “creazione di tabelle”
(necessario per creare le viste che sono tabelle temporanee) e di “selezione”
(proiezione) su tutte le tabelle del database “sadel” all’utente “caio”
dall’host “localhost” con password “sadel”
9.1.2. La progettazione della logica di gestione

Affinché la gestione degli accessi in fase di sviluppo si riveli corretta è
necessario che i permessi concessi a livello “applicativo” coincidano con
quelli necessari all’applicazione per accedere al database. In tal modo
anche l’utente più “smaliziato” che eventualmente riuscisse, attraverso un
“baco” dell’applicazione, ad interfacciarsi direttamente al database non
potrà eseguire operazioni a cui non è autorizzato.
PERMESSO DATI
UTENTE
APPLICAZIONE
PERMESSO DATI
UTENTE
DB
125
L’unico problema sorge dal fatto che mediante la sintassi prevista da
MySQL non è possibile specificare il permesso per un utente “esterno”
(così come l’abbiamo definito in precedenza) a causa di una imprecisa
gestione dei permessi relativi alle tabelle temporanee (le viste). Tale
problema si può risolvere mediante un controllo a livello applicativo del
tipo di permesso. In questo caso l’utente smaliziato che riesce a trovare un
baco potrà al più riuscire ad accedere come utente Sadel, anziché come
utente esterno, ma in ogni caso non potrà modificare in alcun modo i dati
presenti nel database.
La gestione dei permessi a livello applicativo necessita di una tabella

che associ gli utenti ad una tipologia di permesso. Riportiamo l’entità
relativa ad essa.
nome_completo
permesso
e-mail
nome
UTENTI_DB
Naturalmente in questa tabella non vi è alcuna password, la

correttezza di “dati di login” inseriti dall’utente che prova ad accedere al
sistema viene verificata direttamente dal programma di gestione provando a
porre un’interrogazione relativa ad un’area riservata al database. A seconda
della risposta di MySQL si comprende se l’utente ha diritto all’accesso o
126
meno. L’attributo “permesso” serve invece soprattutto per distinguere le
aree riservate a l’utente interno da quelle accessibili anche da un utente
esterno.
9.1.3. La gestione dei permessi

Naturalmente deve essere prevista anche un’interfaccia riservata
all’amministratore per la gestione dei permessi, dalla quale si potranno:
creare nuovi permessi;
revocare i permessi esistenti;
promuovere o declassare gli utenti;
modificare i dati relativi agli utenti, compresi i “dati di login” (nome

utente e password).
L’ultima particolarità da segnalare è la possibilità di coesistenza di più

amministratori. In particolare un amministratore può essere nominato solo
da un amministratore già esistente e un amministratore non può attraverso
l’interfaccia modificare il proprio permesso o i propri dati di login.
E’ necessario pertanto in fase di implementazione del sistema la

creazione di un primo amministratore che possa generare a sua volta tutti i
permessi necessari.
9.2. Sistemi di prevenzione e recupero dei dati

L’aspetto della sicurezza relativo ai sistemi di prevenzione e recupero
dei dati deve essere implementato a livello del “server”, ma, come abbiamo
già avuto modo di rilevare, noi non ci addentreremo fino a tal punto.
In ogni caso abbiamo pensato di implementare un sistema di recupero

dei dati ad un livello più elevato, che tuteli il database da possibili errori a
127
livello applicativo (errori umani o malfunzionamenti del programma di
gestione).
9.2.1. Gli strumenti offerti da MySQL

Anche in questo caso MySQL ci viene in aiuto prevedendo un
semplice ma efficace meccanismo di “backup” e “restore” (ripristino) dei
dati.
In realtà, essendo le tabelle utilizzate da MySQL contenute sottoforma

di file in una determinata directory, tali comandi non fanno altro che
copiare da una directory all’altra i file relativi alle tabelle di cui si vuole
effettuare il backup o il ripristino.
È necessario che sia l’amministratore a dare questi comandi al

sistema, in quanto MySQL non prevede un backup automatico dei dati ad
intervalli regolari, per questo serve un’interfaccia che permetta
all’amministartore di gestire le operazioni di rispristino e di backup.
9.2.2. Il file di log

Per aumentare le capacità di ripristino dei dati è possibile affiancare al
meccanismo di backup un “file di log” che tiene traccia di tutte le istruzioni
eseguite sul database che hanno modificato i dati a partire dall’ultimo
backup.
128
Il file di log, consiste in un file di testo nel quale ogni riga ha la
medesima sequenza di campi:
data e ora;
utente;
query SQL;
righe affette (cioè il numero di istanze che sono state modificate);
errore (il numero dell’eventuale errore).
Riportiamo di seguito un esempio.
Il tipo di operazioni memorizzate sono tutte quelle che modificano in

qualche modo i dati presenti:
inserimento di istanze (insert);
eliminazione di istanze (delete);
modifica di istanze (update);
modifica dei permessi (grant);
revoca dei permessi (revoke).
In caso di necessità è possibile, grazie al “file di log”, tentare un

ripristino di tutti i dati presenti fino al momento di crash del sistema. Si può
129
implementare una procedura che, dopo aver riportato il sistema a un punto
di ripristino “consistente”, tenti di rieseguire tutte le istruzioni presenti nel
“file di log” fino ad un’eventuale errore o diversa risposta del sistema
(confrontando il numero di righe affette con il relativo numero nel “file di
log”).
9.2.3. La gestione dei backup

La gestione dei backup e delle operazioni di ripristino del sistema che
abbiamo deciso di implementare, viene affidata ad un’interfaccia dalla
quale l’amministratore:
visualizza tutti i punti di ripristino del sistema esistenti;
può riportare il sistema a punti di ripristino precedenti;
può eliminare vecchi punti di ripristino;
può effettuare backup del database;
può tentare il ripristino del sistema ad un qualsiasi istante successivo

all’ultimo backup (grazie al “file di log”).
Inoltre il programma di gestione svolge alcune funzioni automatiche:
ogni volta che viene eseguita un’operazione di backup o di ripristino

“svuota” il “file di log”;
prima di ogni operazione di backup verifica la consistenza delle

tabelle;
prima di ogni tentativo di recupero mediante il file di log effettua un

backup della situazione attuale;
segnala sempre in home page quante ore sono trascorse dall’ultima

operazione di backup;
130
10. IL PROGETTO DELLA BASE DI
DATI
Dopo aver effettuato una completa analisi dei requisiti si può
procedere con la progettazione del database che ci porterà ad individuare
l’organizzazione e la struttura della base di dati.
La progettazione del database si può distinguere in tre fasi [1]:
la progettazione concettuale;
la progettazione logica;
la progettazione fisica;
10.1. La progettazione concettuale

Lo scopo della progettazione concettuale è quello di tradurre il
risultato dell’analisi dei requisiti in una descrizione formale, indipendente
dal tipo di database che si andrà ad utilizzare (nel nostro caso MySQL).
Si deve giungere pertanto ad uno “schema concettuale” che, anche se

in forma semplificata, dovrà contenere tutti e soli gli aspetti interessanti per
la gestione del sistema.
Il modello utilizzato per esprimere il risultato della progettazione

concettuale, ormai da tempo affermato nelle metodologie di progetto delle
basi di dati, è il modello E-R (Entity – Relationship, P.P. Chen 1976).
10.1.1. Lo schema E-R

Il primo passo nella progettazione della base di dati è la definizione di
uno schema E-R, che rappresenti in maniera completa il database.
131
Parte delle considerazioni che andremo a fare sono ripetizioni di
osservazioni già esposte frammentariamente nei capitoli precedenti, ma per
chiarezza le riproponiamo in modo completo.
Individuazione delle entità e delle associazioni

Per prima cosa individuiamo le istanze di entità, cioè (dalla
definizione) quegli oggetti esistenti di per sé in azienda e della quale si
vogliono registrare fatti specifici.
Le entità rilevate sono le seguenti:
elemento;
fornitore;
utente;
Le specifiche che esprimono le associazioni sono invece:
un utente può approvare uno o più elementi, un elemento può essere

approvato da un solo utente;
un elemento può essere stato comprato o realizzato da uno o più

fornitori sotto il corrispettivo di un costo, un fornitore può aver
venduto o realizzato uno o più elementi;
un elemento (padre) può essere costituito da uno o più altri elementi

(figli), un elemento (figlio) può essere parte di uno o più altri elementi
(padri);
un utente può originare una o più revisioni di un elemento;
un utente può approvare una o più revisioni di un elemento.
Si nota come vi siano due associazioni che legano l’utente alla

revisione di un elemento che da un punto di vista concettuale non sarebbe
132
altro che una proprietà unaria dell’entità elemento (un elemento può avere
al più una revisione). Per esprimere schematicamente queste specifiche è
necessario introdurre tra le istanze di entità, l’entità “revisione”. Essa è in
realtà un’entità “debole” in quanto ha significato solo in funzione
dell’esistenza di una relativa entità “forte” elemento.
L’ultima considerazione relativa alla struttura di massima del sistema

riguarda le gerarchie presenti. Abbiamo già avuto modo di rilevare che
possono esistere diverse tipologie di elemento tra le quali alcune, che
abbiamo denominato “componenti speciali” di rilevante importanza. Esse
possono essere considerate, a ragion veduta, sottocategorie dell’entità
elemento. La gerarchia è di tipo parziale (esistono elementi che non
appartengono ad alcuna delle sottocategorie) ed esclusiva (se un elemento è
nella sottocategoria “condensatore” non è di sicuro presente nella
sottocategoria “resistenza”).
Lo schema scheletro
Grazie alle considerazioni fatte è possibile realizzare lo “schema
scheletro” del sistema
(p,e)
Nella pagina seguente riportiamo lo schema scheletro completo delle

cardinalità delle associazioni.
133
134
Gli attributi e le chiavi
L’ultimo passo della progettazione concettuale necessario per
giungere alla definizione dello schema E-R è l’assegnazione degli attributi
e delle chiavi delle entità e delle associazioni.
Gli attributi sono “fatti che descrivono le caratteristiche delle istanze

di entità e le caratteristiche delle istanze di associazione”. Possono essere:
obbligatori, scalari (1,1);
obbligatori, multipli (1,N);
opzionali, scalari (0,1);
opzionali, multipli (0,N).
Le chiavi sono invece insieme di attributi identificatori di istanze di

entità o associazioni. Una chiave deve essere totale, obbligatoria, unica,
esplicita e non può contenere valori nulli.
135
L’entità “elemento”
codice
codice costruttore (0,1) costruttore
note
codice
altri costruttori (0,N) costruttore
ELEMENTO note
posizione magazzino (0,1)
numero pezzi
operazioni magazzino (0,N) data
causale
link
documenti/files allegati (0,N)
note
descrizione (1,1)
data (1,1)
obsoleto (1,1)
note (0,1)
codice elemento (1,1)
L’entità “utente”
nome completo (1,1)
nome utente (1,1)

UTENTE permesso (1,1)
email (1,1)
136
L’entità “fornitore”
id (1,1)
nome fornitore (1,1)
FORNITORE via (0,1)

c.a.p. (0,1)
città (0,1)
tel. (0,1)
fax (0,1)
nome riferimento (0,1)
tel. riferimento (0,1)
tipo prodotto (0,1)
L’entità debole “revisione” e la sua associazione con l’entità “elemento”

codice elemento
ELEMENTO
(0,1)

HA
(1,1)
descrizione (1,1)
REVISIONE motivazione (0,1)

data (1,1)
conseguenze (0,1)
azioni attuate (0,1)
link (0,1)
137
L’associazione “costi”
codice elemento
ELEMENTO
(0,N) id (1,1)
costo (1,1)
valuta (1,1)
COSTO data (1,1)
numero pezzi (1,1)
note (0,1)
(0,N)
FORNITORE
id
138
L’autoassociazione “distinta”
ELEMENTI codice elemento
codice distinta (1,1)

(0,N)
FIGLIO
PADRE
(0,N)
DISTINTE
posizione (1,1)
quantità (1,1)
reference (0,1)
gestione (0,1)
note (0,1)
139
I componenti speciali

categoria (1,1)
CONDENSATORE case (0,1)
tipo (0,1)
posizione (0,1)
capacità (1,1)
tensione (1,1)
tolleranza (0,1)
passo (0,1)
altro (0,1)

ohm (1,1)
RESISTENZA tolleranza (0,1)
case (0,1)
potenza (0,1)
ppm (0,1)
altro (0,1)

descrizione (1,1)
CONNETTORE tipo (1,1)
numero di poli (1,1)
posizione (1,1)
codice costruttore (1,1)
altro (0,1)
140
categoria (1,1)
CIRCUITO
descrizione (1,1)
INTEGRATO package (1,1)
tipo (1,1)
altro (0,1)

DIODO caratteristica (0,1)
reverse voltage (0,1)
forward current (0,1)
package (0,1)
altro (0,1)

TRANSISTOR tipo (1,1)
tensione (0,1)
corrente (0,1)
package (0,1)
altro (0,1)
Il modello completo
A questo punto il modello concettuale, rappresentato dallo schema
ER, è completo. Abbiamo individuato tutte le entità e le associazioni e i
rispettivi attributi (da notare che per alcune associazioni non vi è alcun
attributo). Non riportiamo l’intero schema completo per motivi di spazio.
141
10.2. La progettazione logica
Il passaggio dallo schema ER al progetto logico può essere fatto in
modo semiautomatico secondo alcune regole di base. Tuttavia è necessario
effettuare delle scelte tra alternative diverse ma comunque valide.
Per la realizzazione dello schema logico dallo schema ER è necessario

eseguire i seguenti passi:
eliminazione delle gerarchie;
selezione delle chiavi primarie ed eliminazione delle identificazioni

esterne;
normalizzazione degli attributi composti o multipli;
traduzione di entità e associazioni in schemi di relazioni;
10.2.1. Lo schema normalizzato

Per giungere allo schema normalizzato è necessario eseguire le prime
tre fasi della procedura illustrata in precedenza. Questo risulta abbastanza
semplice in quanto lo schema ER è stato ottenuto da un’analisi dei requisiti
che teneva conto dei problemi strutturali di maggior rilievo: nella gerarchia
dell’entità elementi, per esempio, sono stati inseriti solo quei componenti
ritenuti importanti dall’azienda, non si prenderà pertanto neanche in
considerazione l’ipotesi di un “collasso verso l’alto” della gerarchia. In
modo analogo gli attributi composti dell’entità elementi sono tali a causa
dell’elevata incidenza di valori nulli rispetto il numero totale di elementi,
non è possibile pertanto una loro integrazione con l’entità elemento.
Possiamo quindi presentare direttamente lo schema scheletro

normalizzato (per motivi di spazio sono riportati solo gli attributi “chiave”).
142
143
10.2.2. Gli schemi di relazioni
L’ultimo passo consiste nella definizione finale degli schemi di
relazioni per le entità e le associazioni.
Per quanto riguarda l’entità “elemento”, l’associazione “approvato”

viene inglobata come attributo tra le proprietà, mentre per gli attributi
composti vengono create relazioni separate. Abbiamo abbreviato i termini
per semplificare la comprensione, le chiavi sono sottolineate e i campi
obbligatori riportati in grassetto.
ELEMENTI (codice_elemento, descrizione, data, approvato,
obsoleto, note);
COD_COSTR (codice_elemento, codice_costruttore,
costruttore, note);
ALTRI_COSTR (codice_elemento, costruttore,
codice_costruttore, note);
MASA (codice_elemento, posizione);
OP_MASA (id, codice_elemento, npezzi, data, causale);
LINK (codice_elemento, link, note);
Le sottocategorie dell’entità “elemento” vengono mantenute separate

mediante la creazione di altrettante relazioni separate.
CONDENSATORI (codice_elemento, categoria, case_cer,
tipo_cer, posiz_elet, capacita, tensione, tolleranza,
passo_thd, altro);
RESISTENZE (codice_elemento, ohm, tolleranza, case,
potenza, ppm, altro)
CONNETTORI (codice_elemento, descrizione, tipo_connettore,
n_poli, posizione, codice_costruttore, altro);
CIRCUITI_INTEGRATI (codice_elemento, categoria,
descrizione, package, tipo_componente, codice_costruttore,
altro);
DIODI (codice_elemento, codice_costruttore, caratteristica,
reverse_voltage, forward_current, package, altro);
144
TRANSISTOR (codice_elemento, codice_costruttore, tipo,
tensione, corrente, package, altro);
L’autoassociazione “distinta” è definita come segue.

DISTINTE (codice_distinta, codice_elemento, pos, quantita,
reference, gestione, note);
L’entità “revisione” contiene il riferimento all’elemento e agli utenti

che l’hanno originata ed approvata.
REVISIONI (codice_elemento, descrizione, motivazione, data,
originato, approvato, conseguenze, azioni_attuate, link);
UTENTI_DB (nome_completo, nome, permesso, email);
L’entità “fornitore” rimane legata all’entità “elemento” attraverso un

associazione di costo. Come si può notare può comunque esistere un costo
relativo a un elemento senza aver assegnato un fornitore.
FORNITORI (id, nome fornitore, via, C.A.P., città, tel.,
fax, nome riferimento, tel. riferimento, tipo prodotto);
COSTI (id, codice_elemento, costo, valuta, data, npezzi,
note, id_fornitore);
10.3. La progettazione fisica

La progettazione fisica consiste nella definizione ultima degli attributi
ed infine nella traduzione delle specifiche relazionali individuate in
conclusione della progettazione logica in un linguaggio interpretabile dal
database che si sceglie di utilizzare e dalle applicazioni che su di esso si
intendono realizzare.
145
10.3.1. Definizione degli attributi
Dallo schema ER normalizzato e dall’analisi statistiche sulle tabelle
preesistenti è possibile, finalmente, definire in maniera precisa tutte le
“nuove” tabelle con i rispettivi attributi. Da questa rappresentazione
“grezza” del database è poi possibile effettuare la traduzione vera e propria
mediante il formalismo del MySQL.
Riporto di seguito le tabelle del database: nella colonna sinistra viene

specificato il nome del campo, in quella centrale la tipologia dei dati
relativi ad esso e nella colonna destra se sono consentiti campi nulli. Sono
evidenziate in grassetto le chiavi primarie.
ELEMENTI TIPO NULL
CODICE_ELEMENTO STRINGA 30 NO
DESCRIZIONE TESTO NO
DATA DATA AAAA-MM-GG NO
APPROVATO STRINGA 30 SI
OBSOLETO BOOLEAN (0/1) NO
NOTE TESTO SI
146
DISTINTE TIPO NULL
CODICE_DISTINTA STRINGA 30 NO
POS INTERO 6 CIFRE NO
QUANTITA INTERO 6 CIFRE NO
REFERENCE TESTO SI
GESTIONE CARATTERE (“S”) SI
NOTE TESTO SI
COD_COSTR TIPO NULL
CODICE_COSTRUTTOR STRINGA 60 NO
E
COSTRUTTORE STRINGA 60 SI
NOTE TESTO SI
ALTRI_COSTR TIPO NULL
COSTRUTTORE STRINGA 60 NO
CODICE_COSTRUTTO STRINGA 60 NO
RE
NOTE TESTO SI
147
LINK TIPO NULL
LINK STRINGA 150 NO
NOTE TESTO SI
REVISIONI TIPO NULL
DESCRIZIONE TESTO NO
MOTIVAZIONE TESTO SI
ORIGINATO STRINGA 30 SI
APPROVATO STRINGA 30 SI
CONSEGUENZE TESTO SI
AZIONI_ATTUATE TESTO SI
LINK STRINGA 150 SI
MASA TIPO NULL
POSIZIONE STRINGA 10 SI
148
OP_MASA TIPO NULL
ID INTERO 6 NO
PROGRESSIVO
NPEZZI INTERO 8 CIFRE NO
CAUSALE TESTO SI
COSTI TIPO NULL
ID INTERO 6 NO
PROGRESSIVO
COSTO DECIMALE 0.00000 NO
NPEZZI INTERO 6 CIFRE SI
NOTE TESTO SI
ID_FORNITORE INT 6 CIFRE SI
149
FORNITORI TIPO NULL
ID INTERO 6 NO
PROGRESSIVO
FORNITORE STRINGA 60 NO
VIA STRINGA 100 SI
CAP STRINGA 20 SI
CITTÀ STRINGA 60 SI
TEL STRINGA 80 SI
FAX STRINGA 80 SI
RIFNOME STRINGA 100 SI
RIFTEL STRINGA 80 SI
TIPO_PRODOTTO STRINGA 80 SI
CONDENSATORI TIPO NULL
CATEGORIA SET DI VALORI NO
CASE_CER INTERO 6 SI
TIPO_CER SET DI VALORI SI
POSIZ_ELET SET DI VALORI SI
CAPACITÀ REALE SI
TENSIONE REALE SI
TOLLERANZA DECIMALE SI
PASSO_THD DECIMALE SI
ALTRO BLOB SI
150
RESISTENZE TIPO NULL
OHM REALE NO
TOLLERANZA DECIMALE SI
CASE INTERO 6 SI
POTENZA REALE SI
PPM INTERO 6 SI
ALTRO BLOB SI
CONNETTORI TIPO NULL
DESCRIZIONE STRINGA 100 NO
TIPO_CONNETTORE SET DI VALORI SI
N_POLI STRINGA 10 SI
POSIZIONE SET DI VALORI SI
CODICE_COSTRUTTOR STRINGA 60 SI
E
ALTRO BLOB SI
151
CIRCUITI_INTEGRATI TIPO NULL
CATEGORIA SET DI VALORI NO
DESCRIZIONE STRINGA 100 SI
PACKAGE STRINGA 100 SI
TIPO_COMPONENTE SET DI VALORI SI
CODICE_COSTRUTTOR STRINGA 60 SI
E
ALTRO BLOB SI
DIODI TIPO NULL
E
CARATTERISTICA SET DI VALORI SI
REVERSE_VOLTAGE REALE SI
FORWARD_CURRENT REALE SI
ALTRO BLOB SI
152
TRANSISTOR TIPO NULL
E
TIPO SET DI VALORI SI
TENSIONE REALE SI
CORRENTE REALE SI
ALTRO BLOB SI
Notare come l’attributo data, dove presente, sia sempre stato

dichiarato “non nullo” quindi obbligatorio, nonostante nel database
preesistente abbastanza spesso presentasse valori nulli. Ciò significa che
nella ridefinizione della struttura a tali valori nulli verrà associato
comunque un valore predefinito, più precisamente il valore 0000-00-00.
Come impostazione per la lunghezza massima possibile delle stringhe

e dei numeri ho scelto circa il doppio del valore massimo rilevato dalle
statistiche effettuate in precedenza.
La traduzione di tali specifiche in istruzioni per il database MySQL

verrà riportata in fase di implementazione del sistema, in particolare nella
parte riguardante la “creazione del database”.
153
11. L’IMPLEMENTAZIONE DEL
SISTEMA
Dopo aver individuato i requisiti necessari per lo sviluppo del sistema
e dopo aver elaborato soluzioni mediante la progettazione della logica di
gestione, viene naturalmente l’implementazione operativa del sistema. Tale
aspetto, pur non essendo il cuore del problema, risulta essere fondamentale
per poter comprendere e far comprendere la qualità del lavoro svolto,
rappresenta il concretizzarsi di idee e ragionamenti fino ad ora astratti.
In questo capitolo presenteremo le metodologie di implementazione

della logica di gestione progettata nei capitoli precedenti e descriveremo il
funzionamento dell’applicazione sviluppata.
11.1. Gli strumenti

La scelta degli strumenti per l’implementazione operativa del sistema
è stata fatta dall’azienda ed è pertanto un prerequisito fondamentale dal
quale non si può prescindere: il sistema dovrà essere sviluppato su
piattaforma Linux, con database MySQL e gestito dall’applicazione
realizzata in linguaggio PHP.
11.1.1. Il linguaggio PHP

Il PHP (PHP: Hypertext Preprocessor) [3] è un linguaggio di scripting
creato nel 1994 da Rasmus Lerdorf [10], disegnato per la generazione
dinamica di pagine web. Fino a dieci anni fa, difatti, un sito web era
costituito essenzialmente da semplici pagine HTML, i documenti erano
raggiungibili mediante un indice generale e non vi era alcuna possibilità di
effettuare ricerche. Oggi, invece, la maggior parte dei siti sono
154
caratterizzati dalla presenza di una grande quantità di informazioni
organizzate all’interno di uno o più database in modo tale da essere
consultate facilmente da particolari programmi chiamati CGI (Common
Gateway Interface) il cui compito è quello di fornire all’utente finale una
pagina HTML generata dinamicamente con i contenuti richiesti.
Il PHP rientra tra questi particolari e ne rappresenta uno tra i migliori

dal punto di vista prestazionale e per numerosi altri vantaggi.
Curva di apprendimento. Il PHP è uno tra i linguaggi più semplici da

imparare, ha una sintassi molto simile ad altri linguaggi da cui prende
spunto come il “C”, Java ed il Perl.
Integrazione col database. Mediante il PHP è possibile interfacciarsi

con i più diffusi database (Oracle, Informix, SyBase, Microsoft SQL
Server, MySQL, mSQL, PostGreSQL) tra i quali la combinazione più
usata e più flessibile è con il MySQL.
Modularità. Il PHP è modulare, l’interprete principale può essere

esteso realizzando, in linguaggio C, ulteriori moduli da affiancare a
quelli preesistenti.
Estensibilità. Il PHP è distribuito con licenza Open Source per cui è

possibile, per un programmatore, estenderne le funzionalità.
11.1.2. Il database MySQL

MySQL è un sistema Open Source di gestione di database relazionali
[2]. Con l’aumentare delle potenzialità dei computer nel contenere enormi
quantità di dati si è reso necessario lo sviluppo di elaborati sistemi di
gestione di basi di dati; MySQL si basa su “SQL” (Structured Query
Language), che è il linguaggio standard, definito dallo standard ANSI/ISO
155
SQL Standard, per l’accesso ai database relazionali in cui i dati sono
conservati su più tabelle collegate tra loro.
Il software MySQL è Open Source, ciò significa che come per il PHP
chiunque può scaricarlo da Internet ed utilizzarlo senza dover pagare nulla
e pertanto un programmatore esperto potrebbe anche modificarlo secondo
le proprie esigenze. L’utilizzo di MySQL è definito da una licenza GPL
(GNU General Public License).
Il server MySQL è uno tra i più utilizzati e conosciuti database, grazie

alle sue numerose qualità tra cui spiccano la velocità, l’affidabilità e la
semplicità d’uso. Riportiamo di seguito le principali caratteristiche.
Può funzionare su diversi tipi di piattaforma ed è utilizzabile da

numerose API (interfacce di programmazione).
Dal punto di vista della sicurezza è estremamente affidabile e

flessibile, le password sono crittate ad ogni connessione.
Può gestire database di grandi dimensioni (fino a 60.000 tabelle e

5.000.000.000 di righe).
I “client” si possono collegare al server MySQL utilizzando il

protocollo TCP/IP.
Supporta numerose lingue e insiemi di caratteri.
Perché MySQL è meglio di Access

Nel presente elaborato si descrive la progettazione e lo sviluppo di un
sistema informativo di un sistema che precedentemente era basato su
Microsoft Access. In questo paragrafo cercheremo di individuare i motivi
per cui, nel contesto aziendale, sia preferibile utilizzare un sistema basato
su MySQL.
156
Riportiamo di seguito le ragioni che spingono verso l’utilizzo di
MySQL a scapito di Microsoft Access [7].
Sviluppo delle informazioni. Se i dati sono contenuti in un database

MySQL è possibile accedere ad essi mediante numerosi tipi di
interfaccia, attraverso lo stesso Access o attraverso numerosi
linguaggi per il Web, dando la possibilità di accedere alle
informazioni in maniere indipendente dalla piattaforma utilizzata.
Accesso multi-utente. Sebbene Access preveda alcune funzionalità

per la condivisione dei dati, esse non sono affatto il suo punto di forza.
Vi è sempre la sensazione di un sistema di gestione dei dati orientato
al singolo utente. MySQL, invece, può gestire simultaneamente molti
utenti in quanto è stato disegnato per l’utilizzo all’interno di network.
Gestione di grandi database. MySQL al contrario di Access può

gestire centinaia di megabytes di informazioni.
Sicurezza. Quando le informazioni sono conservate su database

Access chiunque possa accedere al computer di un utente ha di
conseguenza accesso alla base di dati. E’ possibile in Access
assegnare una password al database, ma la maggior parte degli utenti
regolarmente non lo fa. Con MySQL per connettersi al database è
sempre necessario conoscere l’appropriata password, da qualunque
computer si tenti di accedere.
Costi. MySQL può essere utilizzato gratuitamente, Access no. Inoltre

MySQL può essere utilizzato su piattaforme e con diversi tipi di
interfaccia Open Source riducendo, di conseguenza, la dipendenza da
software proprietari.
157
Scelta dell’hardware. MySQL può funzionare su più piattaforme
mentre Access è una applicazione “single-platform”, per cui la scelta
dell’hardware è già predeterminata.
Prestazioni. Le prestazioni di MySQL superano notevolmente quelle

di Access. Riportiamo di seguito il confronto sui tempi delle più
frequenti operazioni.
158
11.1.3. L’architettura del sistema
Possiamo rappresentare l’architettura del sistema che andiamo ad
implementare come segue.
Server Client
richiesta dati
HTML
DB
PHP Protocollo TCP/IP
LINUX
Notiamo come MySQL e PHP siano entrambe applicazioni allo stesso

livello sulla piattaforma Linux, ma il ruolo di PHP è di più alto livello dal
punto di vista logico in quanto realizza l’interfaccia con il quale l’utente
può accedere al database, generando un codice HTML interpretabile da un
qualsiasi browser.
11.2. La realizzazione del database

In questo paragrafo tratteremo la realizzazione del database, intesa
come costruzione della struttura tabellare del database MySQL secondo le
specifiche di progetto e riporteremo le metodologie di importazione dei dati
preesistenti.
11.2.1. La creazione delle tabelle

Una volta effettuata la progettazione fisica del database abbiamo a
disposizione l’elenco delle istruzioni SQL che realizzano la struttura
completa del database. Le riportiamo di seguito.
159
# Struttura della tabella àltri_costr`
CREATE TABLE àltri_costr` (
`codice_elemento` varchar(30) NOT NULL default '',
`costruttore` varchar(60) NOT NULL default '',
`codice_costruttore` varchar(60) NOT NULL default '',
`note` blob,
PRIMARY KEY (`codice_elemento`,`codice_costruttore`)
) TYPE=MyISAM;
# Struttura della tabella `circuiti_integrati`

CREATE TABLE `circuiti_integrati` (
`categoria`
enum('ANALOG','DIGITAL','MICRO','DSP','PLD','INTERFACE','LINEAR','MEM'
,'REG') NOT NULL default 'ANALOG',
`descrizione` varchar(100) NOT NULL default '',
`package` varchar(100) NOT NULL default '',
`tipo_componente` enum('IND','COM','AUT','MIL') NOT NULL default
'IND',
àltro` blob,
PRIMARY KEY (`codice_elemento`)
) TYPE=MyISAM;
# Struttura della tabella `cod_costr`

CREATE TABLE `cod_costr` (
`costruttore` varchar(60) default NULL,
`note` blob,
) TYPE=MyISAM;
# Struttura della tabella `condensatori`

CREATE TABLE `condensatori` (
`categoria` enum('CER.','ELET.','POL.','TANTALIO','VAR.') NOT NULL
default 'CER.',
`case_cer` int(6) default NULL,
`tipo_cer` enum('NPO','COG','X7R','Z5U','Y5V') default NULL,
`posiz_elet` enum('RAD.','ASS.') default NULL,
`capacita` double NOT NULL default '0',
`tensione` double NOT NULL default '0',
`tolleranza` decimal(4,2) default NULL,
`passo_thd` decimal(4,2) default NULL,
àltro` blob,
) TYPE=MyISAM;
160
# Struttura della tabella `connettori`
CREATE TABLE `connettori` (
`descrizione` varchar(100) NOT NULL default '',
`tipo_connettore` enum('MASC','FEMM') NOT NULL default 'MASC',
`n_poli` varchar(10) NOT NULL default '',
`posizione` enum('ORIZ','VERT') NOT NULL default 'ORIZ',
àltro` blob,
) TYPE=MyISAM;
# Struttura della tabella `costi`

CREATE TABLE `costi` (
ìd` int(6) NOT NULL auto_increment,
`costo` decimal(7,5) NOT NULL default '0.00000',
`valuta` enum(' ','$') NOT NULL default ' ',
`data` date NOT NULL default '0000-00-00',
`npezzi` int(6) NOT NULL default '0',
`note` blob,
ìd_fornitore` int(6) default NULL,
PRIMARY KEY (ìd`)
) TYPE=MyISAM;
# Struttura della tabella `diodi`

CREATE TABLE `diodi` (
`caratteristica` enum('SHOTTKY','RECT','FAST','ULTRA-FAST','HIGH
SPEED') default NULL,
`reverse_voltage` double default NULL,
`forward_current` double default NULL,
`package` varchar(100) default NULL,
àltro` blob,
) TYPE=MyISAM;
# Struttura della tabella `distinte`

CREATE TABLE `distinte` (
`codice_distinta` varchar(30) NOT NULL default '',
`pos` int(6) NOT NULL default '0',
`quantita` int(6) NOT NULL default '0',
`reference` blob,
`gestione` enum('S') default NULL,
`note` blob,
PRIMARY KEY (`codice_distinta`,`codice_elemento`,`pos`)
) TYPE=MyISAM;
161
# Struttura della tabella èlementi`
CREATE TABLE èlementi` (
`descrizione` blob NOT NULL,
àpprovato` varchar(30) default NULL,
òbsoleto` enum('NO','SI') NOT NULL default 'NO',
`note` blob,
) TYPE=MyISAM;
# Struttura della tabella `fornitori`

CREATE TABLE `fornitori` (
`fornitore` varchar(60) NOT NULL default '',
`via` varchar(100) default NULL,
`cap` varchar(20) default NULL,
`citta` varchar(60) default NULL,
`tel` varchar(80) default NULL,
`fax` varchar(80) default NULL,
`rifnome` varchar(100) default NULL,
`riftel` varchar(80) default NULL,
`tipo_prodotto` varchar(80) default NULL,
PRIMARY KEY (ìd`)
) TYPE=MyISAM;
# Struttura della tabella `link`

CREATE TABLE `link` (
`link` varchar(150) NOT NULL default '',
`note` blob,
PRIMARY KEY (`codice_elemento`,`link`)
) TYPE=MyISAM;
# Struttura della tabella `masa`

CREATE TABLE `masa` (
`posizione` varchar(10) default NULL,
) TYPE=MyISAM;
# Struttura della tabella òp_masa`

CREATE TABLE òp_masa` (
`npezzi` decimal(8,0) NOT NULL default '0',
`causale` blob,
PRIMARY KEY (ìd`)
) TYPE=MyISAM;
162
# Struttura della tabella `resistenze`
CREATE TABLE `resistenze` (
òhm` double NOT NULL default '0',
`tolleranza` decimal(4,2) default NULL,
`case` int(6) default NULL,
`potenza` double default NULL,
`ppm` int(6) default NULL,
àltro` blob,
) TYPE=MyISAM;
# Struttura della tabella `revisioni`

CREATE TABLE `revisioni` (
`descrizione` blob NOT NULL,
`motivazione` blob,
òriginato` varchar(30) default NULL,
àpprovato` varchar(30) default NULL,
`conseguenze` blob,
àzioni_attuate` blob,
`link` varchar(150) default NULL,
) TYPE=MyISAM;
# Struttura della tabella `transistor`

CREATE TABLE `transistor` (
`tipo` enum('NPN','PNP','N-MOS','P-MOS','N-MOSFET','N-ENHANCEMENT
FET') NOT NULL default 'NPN',
`tensione` double default NULL,
`corrente` double default NULL,
`package` varchar(100) default NULL,
àltro` blob
) TYPE=MyISAM;
# Struttura della tabella ùtenti_db`

CREATE TABLE ùtenti_db` (
`nome_completo` varchar(100) NOT NULL default '',
`nome` varchar(30) NOT NULL default '',
`permesso` enum('AMMINISTRATORE','SADEL','ESTERNO') NOT NULL default
'ESTERNO',
èmail` varchar(100) NOT NULL default '',
PRIMARY KEY (`nome`),
UNIQUE KEY `nome_completo` (`nome_completo`)
) TYPE=MyISAM;
163
L’applicazione di tali istruzioni al database MySQL è estremamente
semplice se utilizzata una semplice interfaccia standard di gestione del
database denominata PhpMyAdmin.
PhpMyAdmin
PhpMyAdmin consiste in una raccolta di script PHP che consente di
gestire in modo completo uno o più database MySQL mediante
un’interfaccia grafica piuttosto semplice e senza dover conoscere
necessariamente l’SQL. Tra le funzionalità più utili vi è quella che noi
abbiamo utilizzato che consente di dare una serie di istruzioni al database
mediante l’invio di un semplice file di testo, contenente tali istruzioni.
164
11.2.2. La creazione dei permessi iniziali
Oltre alle tabelle è necessario creare almeno un permesso iniziale da
amministratore, per potere in seguito agire sul database e importare i dati
preesistenti.
Questo è realizzato mediante le seguenti istruzione per MySQL.
165
INSERT INTO ùtenti_db` VALUES ('MICHELE BORGHI','mick',
'AMMINISTRATORE', 'michele@bakeka.net');
GRANT ALL ON *.* TO mick@localhost identified by 'mick' WITH GRANT
OPTION;
INSERT INTO ùtenti_db` VALUES ('ANDREA REGAZZI','andrear',

'AMMINISTRATORE', 'andrea.regazzi@sadel.it');
GRANT ALL ON *.* TO andrear@localhost identified by 'sadel' WITH GRANT
OPTION;
INSERT INTO ùtenti_db` VALUES ('PINCO PALLINO','sadel', 'SADEL',

'pinco@pallino.it');
grant create,select on sadel.* to sadel@localhost identified by
'sadel';
grant delete on sadel.approvazione to sadel@localhost identified by
'sadel';
grant update (àpprovato`) on sadel.elementi to sadel@localhost
identified by 'sadel';
grant update (àpprovato`) on sadel.revisioni to sadel@localhost
identified by 'sadel';
INSERT INTO ùtenti_db` VALUES ('TIZIO CAIO','esterno', 'ESTERNO',

'tizio@caio.it');
grant create,select on sadel.* to esterno@localhost identified by
'esterno';
FLUSH PRIVILEGES;
In questo modo si creano due amministratori, un utente interno e un

utente esterno, così come gli abbiamo definiti nell’affrontare l’argomento
dei “permessi utente”. Notare che per un’identificazione completa risulta
anche necessario inserire alcune istanze all’interno della tabella
“utenti_db”.
11.2.3. L’importazione dei dati

Una volta concretizzata la struttura relazionale del database in tabelle
grazie a MySQL, è necessario procedere all’importazione dei dati
preesistenti.
Tale processo è un’operazione molto delicata in quanto deve

assolutamente evitare qualsiasi perdita di informazioni e nello stesso tempo
166
deve essere automatizzata in quanto non è realizzabile il trasferimento
manuale di una mole di dati così elevata.
Tutto il processo di importazione dei dati verrà pertanto affidato ad

una serie di script che provvederanno a svolgere le seguenti funzioni:
trasferire i dati del database preesistente compatibili con il nuovo

sistema, tenendo traccia di eventuali istanze che non è stato possibile
inserire;
importare i documenti allegati e aggiornare i relativi link;
ripulire i dati inseriti dalle “virgolette” che vengono male interpretati

dal sistema;
analizzare i codici degli elementi inseriti rispetto il nuovo sistema di

codifica ed consentirne l’eliminazione o la modifica;
pulire le tabelle eliminando le istanze relative ad elementi non

esistenti;
interpretare e copiare i dati relativi ai “componenti speciali” nelle

apposite tabelle.
Riempimento delle tabelle compatibili

Come si può notare confrontando lo schema ER normalizzato
preesistente con quello elaborato nella progettazione logica del sistema, vi
sono una serie di tabelle con caratteristiche molto simili. Per queste è
possibile sviluppare una procedura di importazione automatica che
trasferisca i dati dal database Access al nuovo sistema in MySQL.
Tale procedura è affidata ad uno script PHP che dato una serie di file
in formato CSV (Comma Separated Values) in rappresentazione delle
167
tabelle preesistenti del database Access, inserisce i dati in esse contenuti
nelle relative tabelle MySQL.
Oltre al trasferimento dei dati tale procedura si occupa di controllare

se i dati rispettano le nuove specifiche strutturali della tabella. Per esempio
se un’istanza è priva di un campo obbligatorio essa non viene inserita e ne
viene tenuto traccia in un apposito file di testo. Non viene invece
controllata in questa fase la correttezza del codice identificativo
dell’elemento.
import_data.php
DB
file CSV
ERRORI
istanze_non_inserite.txt
Il risultato dell’operazione consiste in 130 istanze non inserite a causa

di problemi strutturali, di cui 12 elementi, 3 revisioni, 17 link, 86 codici
costruttori, 4 altri costruttori, un fornitore, 2 costi, 2 posizioni di
magazzino, 3 operazioni di magazzino.
L’importazione dei documenti allegati

Nel sistema preesistente sono presenti oltre 200 megabyte di
documenti allegati che, naturalmente, devono continuare ad essere
rintracciabili ed fruibili nel sistema in fase di sviluppo.
168
Anche in questo caso tale operazione viene affidata ad uno script PHP
che sulla base dei link indicati nel database preesistente cerca il documento
relativo lo copia in una predefinita directory del server e aggiorna
l’appropriata istanza della tabella “link”.
Da notare come in fase di importazione dei dati la tabella “link” è

stata riportata esattamente con gli stessi campi, per questo la procedura di
importazione dei documenti va a ricercare nel nuovo database il vecchio
link e poi lo modifica a seconda della reale posizione del documento.
PROGRAMMA
DI GESTIONE
OLD LINK
DB NEW LINK
COPIA
DOCUMENTO DOCUMENTO
ALLEGATI ALLEGATI
DATABASE DATABASE
MySQL ACCESS
L’esecuzione dello script sopra schematizzato ha portato alla luce 25

link interrotti nel database preesistente.
169
La pulizia dei dati
Le tre operazioni di pulizia dei dati previste in fase di importazione
sono:
l’eliminazione delle virgolette;
l’analisi dei codici;
la pulizia delle tabelle.
L’eliminazione delle virgolette si rende necessaria in quanto le

virgolette all’interno dei campi del database vengono male interpretate in
fase di visualizzazione dei dati da PHP. Questa operazione consiste,
banalmente, nella sostituzione tabella per tabella, istanza per istanza,
campo per campo di tutte le virgolette con l’apice singolo.
L’analisi dei codici consiste, invece, nella operazione di

razionalizzazione del sistema di codifica esistente che abbiamo descritto
nel capitolo relativo al sistema di codifica. Dopo l’importazione risultano
esservi 19 codici errati di cui 9 eliminabili, cioè elementi presenti
esclusivamente nella tabella “elementi” e quindi di importanza limitata.
170
La pulizia delle tabelle riguarda l’eliminazione di tutte le istanze
relative alle tabelle direttamente collegate all’entità “elemento” aventi un
codice elemento inesistente. Tale problema, che viene risolto mediante un
semplice controllo incrociato affidato ad uno script, non ha in ogni caso
alcuna conseguenza sulla qualità dei dati presenti ma viene comunque
effettuato per evitare di mantenere istanze prive di alcun significato. Dopo
l’importazione risultano esservi 67 istanze relative ad elementi inesistenti e
quindi eliminabili.
Importazione dei componenti speciali

Il trasferimento delle informazioni relative ai componenti speciali dal
campo descrizione della tabella “elementi” alle relative tabelle viene
affidata a uno script che esegue la procedura che abbiamo descritto nel
capitolo riguardante la “ricerca e la visualizzazione delle informazioni”. Il
risultato ottenuto da tale programma è il seguente (ricordiamo che vengono
eliminati i componenti la cui descrizione non è stata riconosciuta e che non
sono utilizzati).
Condensatori: totale 660, inseriti 567, eliminati 93;
Resistenze: totale 1351, inseriti 1245, eliminati 106;
Connettori: totale 374, inseriti 312, eliminati 62;
Circuiti integrati: totale 2088, inseriti 620, eliminati 1468;
Diodi: totale 188, inseriti 110, eliminati 78;
Transistor: totale 180, inseriti 100, eliminati 80.
171
11.3. L’interfaccia utente
L’interfaccia utente è lo strumento attraverso il quale l’utente dialoga
con il database, attraverso il quale si accede e si interviene sulle
informazioni. E’ evidente quanto tale aspetto sia rilevante ai fini di una
corretta gestione del sistema ed è per questo che non si può prescindere
dalla “usabilità” nella definizione di una adeguata interfaccia utente.
11.3.1. L’usabilità
Secondo la definizione data dalla norma ISO 9241 [13], l'
usabilità è il
"grado in cui un prodotto può essere usato da particolari utenti per
raggiungere certi obiettivi con efficacia, efficienza e soddisfazione in uno
specifico contesto d'
uso."
La normativa ISO 9241 è del 1993 e si riferisce ai prodotti informatici

in genere. Tuttavia l'
usabilità è un concetto molto precedente ed esteso [4]:
nasce negli anni 60 nell'
ambito dell'
ergonomia in relazione a qualunque
interazione uomo-artefatto. In seguito trova maggior fortuna proprio per i
prodotti a base informatica (soprattutto i software), nel settore
dell'
ergonomia cognitiva. In questo specifico settore dell'
ergonomia si
studia il modo in cui un utente si costruisce un modello mentale del
prodotto che sta usando, e si crea perciò determinate aspettative sul suo
funzionamento. Compito degli studi di usabilità è fare in modo che il
modello mentale di chi ha progettato il software (design model), da cui
deriva il suo reale funzionamento, corrisponda il più possibile al modello
mentale del funzionamento del software così come se lo costruisce l'
utente
finale (user model) [8].
172
L'
usabilità nasce dunque soprattutto come ausilio alla progettazione, e
si applica in particolare alle interfacce. E'con l'
interfaccia di un software,
infatti, che l'
utente si relaziona. Ad ogni sua azione l'
interfaccia proporrà un
risultato, un cambiamento di stato. Poco importa, ai fini dell'
usabilità, come
l'
interfaccia sia giunta a quello stato, attraverso cioè quali meccanismi di
programmazione, che rimangono racchiusi in una vera e propria scatola
nera impermeabile all'
utente.
I principali attributi dell’usabilità sono i seguenti [8].
Utilità: il software serve a qualcosa?
Facilità di apprendimento: è facile capire come utilizzarlo?
Efficienza: gli utenti possono interrogare il sistema e ricevere risposte

sensate in tempi brevi?
Facilità di ricordo: nei successivi utilizzi l’utente ricorda come si

utilizza il software?
Prevenzione degli errori: il software contiene errori?
Soddisfazione: il sistema è soddisfacente da usare o crea ansia e

frustrazione?
173
E’ necessario analizzare il sistema dal punto di vista dell’utente, in
particolare l’esperienza di navigazione deve essere esaminata sotto diversi
aspetti.
Inoltre è necessario definire l’organizzazione e la metodologia di

navigazione del sistema che si deve implementare, in particolare bisogna
orientarsi tra diversi tipologie di “alberi informativi” e trovare l’adeguata
via di mezzo.
L’albero orizzontale, riportato in figura, ha i pregi della semplicità

d’uso di un testo lineare e ha i vantaggi di flessibilità dell’ipertesto, ma non
174
scade nella carenza di organizzazione del grafo né nell’eccessivo
annodamento dell’informazione in un albero verticale.
11.3.2. La struttura di visualizzazione

Prima di addentrarci nella descrizione dettagliata dell’interfaccia
utente e delle varie aree del sistema, è necessario comprendere la struttura
di visualizzazione adottata in tutte le pagine dell’interfaccia.
MENU'DI NAVIGAZIONE
TITOLO DELLA PAGINA
CONTENUTO
INFORMATIVO
Il menù di navigazione
Il menu di navigazione è presente in tutte le pagine generate dal
sistema ed è sempre uguale, consente all’utente di mantenere un punto di
riferimento mediante il quale esso si può spostare tra le aree informative
del database. E’ costituito dall’elenco delle “viste principali” che abbiamo
descritto nel capitolo riguardante la “ricerca e la visualizzazione delle
informazioni” più l’indicazione dell’home page e della pagina per
effettuare il login.
Prendiamo per esempio la prima pagina che viene visualizzata nel

momento in cui ci si connette col sistema.
175
11.3.3. L’home page
In base alle considerazioni sull’usabilità effettuate in precedenza, la
scelta riguardo la struttura informativa più adeguata al sistema è ricaduta su
l’albero orizzontale, per cui assume un ruolo molto importante l’home page
dalla quale deve essere possibile raggiungere, mediante un numero limitato
di passaggi (click), tutte le informazioni conservate nel database.
Come si può notare, l’home page è strutturata in modo molto

semplice. In particolare e suddivisa in quattro aree differenti.
Elenchi. Da qui è possibile accedere alle viste principali del database

in maniera diretta.
176
Componenti. Mediante i link presenti in questa sezione si accede ai
cosiddetti “componenti speciali” per i quali sono previste metodologie
avanzate di ricerca e visualizzazione.
Ricerca. Grazie alla “form” presente in questa area dell’home page è

possibile effettuare ricerche di tipo generale sulle varie “viste” del
database.
Dati login. In questo angolo dell’home page si riportano i dati con cui
l’utente è stato riconosciuto dal sistema e il tipo di permesso assegnato
ad esso.
11.3.4. Le viste principali

La definizione delle viste principali sul database è stata fatta nel
capitolo riguardo la “ricerca e la visualizzazione delle informazioni”.
Ricordiamo che la rappresentazione grafica di tali viste è frutto di un’unica
“funzione di visualizzazione” che data una determinata query SQL è in
grado di visualizzarla in forma standard.
Di seguito riportiamo, a titolo di esempio, alcune tra le viste principali

che sfruttano la “funzione di visualizzazione” sviluppata.
177
Gli elementi
Come si può notare tale vista è la rappresentazione grafica della

tabella “elementi” del database MySQL, da notare vi è il menu sotto il
titolo che consente all’utente di effettuare diverse tipologie di ricerca, di
accedere ai componenti speciali (che, ricordiamo, sono “figli” dell’entità
elementi) e di esportare o stampare la tabella. Inoltre vi sono altre opzioni a
margine della tabella vere e propria:
mediante il link “vedi solo elementi già utilizzati” è possibile

selezionare solo gli elementi della tabella che già sono presenti in
qualche distinta;
mediante le frecce “prev” e “next” si può navigare tra le varie pagine

visualizzate;
mediante il link “vedi tutti in una pagina” è possibile visualizzare in

un’unica pagina tutti gli elementi presenti;
178
cliccando sul titolo delle colonne è possibile ordinare la tabella
secondo il relativo campo.
I prodotti
Tale vista è il frutto di una semplice selezione sulla tabella elementi,

l’unica particolarità da segnalare rispetto quella descritta in precedenza è
l’evidenziazione in rosso degli elementi privi di una distinta.
179
Il magazzino
Individuare l’origine informativa di tale vista è assai più complesso,

essa è, difatti, il frutto di un “join” tra ben quattro tabelle.
In ogni caso la struttura di visualizzazione dell’interfaccia rimane

sempre la stessa per consentire all’utente di continuare ad utilizzare i
medesimi meccanismi di navigazione.
11.3.5. La “scheda elemento”

Un’altra visualizzazione importante delle informazioni è la “scheda
elemento” che consiste in una pagina dalla quale è possibile visualizzare
tutte le informazioni relative ad un specifico elemento del database.
Tale scheda è raggiungibile cliccando sul codice dell’elemento di

interesse da una qualsiasi delle viste sul database.
180
Nella “scheda elemento” sono riportate tutte le informazioni relative
all’elemento di interesse presenti su le tabelle “accessorie” all’entità
“elementi”, più una serie di informazioni derivate: dov’è utilizzato, le altre
revisioni. Se presente dalla scheda elemento è possibile visualizzare
l’esplosione della distinta la cui radice è l’elemento stesso.
11.3.6. L’esplosione della distinta

Sul ramo più basso del nostro “albero informativo” non vi poteva
essere null’altro che la distinta esplosa dell’elemento. La distinta
rappresenta infatti l’informazione di maggior rilievo conservata nel
database ed è molto spesso l’obiettivo delle ricerche effettuate su di esso.
L’esplosione della distinta consiste in una serie di distinte successive,

da quella dell’elemento radice a quella dei figli, a quella dei figli dei figli,
181
ecc. Avendo, per esempio, a disposizione l’esplosione della distinta di un
prodotto si può conoscere il prodotto in tutte le sue parti ed è sufficiente (se
corredata da i documenti di progetto necessari) per la realizzazione del
prodotto stesso.
11.3.7. La ricerca
Grazie alla “funzione di visualizzazione” definita in precedenza il
problema della ricerca si riduce ad una serie di meccanismi che traducano
la ricerca desiderata dall’utente in una query SQL. Tale soluzione dà la
possibilità di implementare diversi tipologie di ricerca, noi ne abbiamo
definiti due: ricerca semplice e ricerca avanzata.
182
La ricerca semplice
La ricerca semplice è possibile dall’home page e da qualsiasi vista del
database (tasto “trova”), consiste nella ricerca di una frase esatta all’interno
di uno o più campi di una determinata vista.
La ricerca avanzata
La ricerca avanzata, che è già stata descritta nel dettaglio, consente di
effettuare ricerche complesse sugli attributi di una qualsiasi vista del
database. Risulta estremamente importante per la ricerca di componenti
speciali. Di seguito riportiamo, a titolo di esempio, la “form” di ricerca di
un condensatore e la ricerca avanzata per un prodotto.
183
184
11.3.8. La gestione dei dati
Fino ad ora abbiamo parlato solo di interfacce di visualizzazione e di
presentazione delle informazioni, tralasciando l’interfaccia attraverso il
quale l’amministratore può modificare i contenuti del database.
Già l’home page si presenta con in aggiunta, rispetto a quella vista in

precedenza, un menu laterale su sfondo grigio che propone alcune opzioni
riservate all’amministratore:
l’inserimento di un elemento;
l’inserimento di un fornitore;
la possibilità di modificare il formato della codifica;
alcune operazioni di pulizia e analisi dei dati;
la gestione dei permessi;
185
la gestione dei backup.
Per motivi di spazio descriveremo nel dettaglio solo alcune delle

procedure di gestione dei dati implementate nel sistema.
L’inserimento di un elemento e la codifica assistita

Scegliendo l’opzione di “inserimento elemento” dall’home page,
l’amministratore ottiene il seguente risultato.
Da qui è possibile inserire direttamente un elemento od affidarsi ad

alcune procedure guidate per l’inserimento di particolari tipologie di
elementi.
A titolo di esempio, simuleremo l’inserimento di un “elemento

generico” utilizzando la funzione di codifica assistita.
186
Utilizzando la funzione di “codifica assistita” e rispondendo ad alcune
domande sul tipo di elemento che si vuole codificare si ottiene un “codice
valido”.
Dopo aver ottenuto il codice si può procedere nell’inserimento

dell’elemento.
187
Come si può notare oltre alla richiesta di conferma viene avvertito
l’utente che verrà inviata una email all’approvatore per chiedere la
conferma sui dati inseriti.
Nell’email inviata al presunto “approvatore” sarà chiesto di recarsi

sull’home page del database nella quale verrà visualizzata la richiesta di
approvazione.
Selezionando il link l’approvatore puà confermare o negare

l’approvazione dell’elemento, secondo la procedura di approvazione
definita.
Il controllo sui dati

La procedura di inserimento di un elemento generico o di qualsiasi
altra tipologia di informazione viene sempre verificata da un sistema di
verifica dei dati inseriti. In particolare viene verificata l’attinenza delle
188
informazioni con la struttura logica della tabella e il formato del codice
dell’elemento.
Per quanto riguarda il controllo sul formato del codice è comunque

prevista un’opzione “evita controllo formato” per il quale si forza
l’inserimento di un codice anche se non corrispondente alle specifiche del
sistema di codifica.
La modifica e l’eliminazione dei dati

La modifica e l’eliminazione dei dati può avvenire esclusivamente
dalla “scheda elemento” che, come l’home page, si presente notevolmente
diversa dalla “scheda elemento” per l’utente generico.
189
Naturalmente l’eliminazione o la modifica di un elemento comporta
l’eliminazione o la modifica di tutte le istanze relative ad esso (eventuali
link, codici costruttori, ecc.). Ciò non avviene invece per gli attributi o le
caratteristiche relative ad esso.
La gestione della distinta

Dalla scheda degli elementi aventi distinta è possibile inoltre accedere
ad una particolare interfaccia per la gestione della distinta e ad una
visualizzazione della distinta con costo (tale possibilità è riservata
esclusivamente agli amministratori).
190
L’interfaccia di gestione della distinta e la visualizzazione della
distinta con costo risultano come nelle due figure seguenti.
Come si nota da qui è possibile inserire, modificare ed eliminare gli

elementi in distinta, eliminare l’intera distinta ed inoltre vi è anche una
procedura guidata per l’inserimento di un documento in distinta.
191
Il costo di una distinta consiste in un calcolo dei costi di tutti gli
elementi dei figli e di tutti i discendenti dei figli. Tale operazione è
effettuata grazie una funzione ricorsiva che procede fino all’ultimo degli
elementi presenti nella gerarchia della distinta. La visualizzazione di tale
calcolo è riservata all’amministratore in quanto il costo ottenuto è
totalmente indicativo e deve essere utilizzato con estrema prudenza.
L’amministrazione dei permessi e la gestione dei backup

All’amministratore come abbiamo già visto in precedenza è affidata
anche la gestione della sicurezza che si concretizza nella gestione dei
permessi e dei backup. Riportiamo di seguito le due interfacce relative.
192
11.3.9. L’esportazione e la stampa
L’esportazione dei dati delle tabelle frutto di interrogazioni semplici o
complesse del database, avviene semplicemente scaricando un file in
formato CSV, generato sulla base della query SQL di riferimento.
193
La stampa avviene invece secondo due modalità:
direttamente mediante il tasto “print” del browser;
mediante una procedura di stampa implementata solo per l’esplosione

della distinta.
La stampa diretta e i CSS

La stampa diretta di una qualsiasi pagina dell’interfaccia è possibile
grazie i fogli di stile, o CSS (Cascading Style Sheet) [11], medianti i quali
è possibile nella progettazione di una pagina HTML distinguere il
contenuto informativo dalla formattazione grafica. Inoltre grazie ad essi è
possibile strutturare una pagina a seconda del supporto con cui tale pagina
è visualizzata [12], in particolare è possibile progettare uno “stile” per la
pagina visualizzata da schermo e uno “stile” per la pagina stampata, senza
dover modificare il contenuto informativo. In tal modo, per esempio, la
stampa di una pagina sarà in bianco e nero anziché a colori, senza il menù,
senza i link evidenziati, ecc.
194
Di seguito riportiamo un esempio di una pagina come viene
visualizzata sullo schermo e come viene poi stampata.
195
La stampa della distinta
L’esportazione su carta di una distinta è una caratteristica
fondamentale per l’azienda e per questo deve essere curata con maggior
attenzione. Tale vincolo si unisce al fatto che i fogli di stile non riescono ad
interagire adeguatamente con il browser per quanto riguarda la dimensione
e la forma del foglio su cui una distinta deve essere stampata.
196
Per questo nel caso della stampa di una distinta è stata implementata
una procedura semiautomatica per la generazione di una pagina
correttamente interpretabile dai CSS.
Nel momento in cui si richiede la stampa di una distinta il sistema

propone la scelta tra diverse opzioni di stampa.
In base alle scelte effettuate viene generata una pagina per la stampa
che dovrebbe essere meglio interpretata dal browser e che comunque deve
essere preventivamente testata con l’opzione “anteprima di stampa” del
browser.
197
Riportiamo di seguito la relativa anteprima di stampa (effettuata con
Microsoft Internet Explorer 6.0).
198
12. VARO DEL SISTEMA E SUA
VALUTAZIONE
Il primo ottobre 2003 il sistema descritto in questo elaborato è entrato
in funzione in azienda.
In questo capitolo cercheremo di dare una valutazione complessiva sul

sistema implementato e lo confronteremo con il sistema in uso
precedentemente nell’azienda.
12.1. Come misurare i miglioramenti ottenuti

Il nostro obiettivo è quello di dare una valutazione il più oggettiva
possibile sui miglioramenti ottenuti rispetto il preesistente sistema. E’
necessario pertanto per prima cosa individuare una serie di caratteristiche
generali sulle quali poter paragonare i due sistemi.
velocità;
usabilità dell’interfaccia;
ricerca delle informazioni;
qualità dei dati;
quantità dei dati contenibili;
sicurezza;
esportazione e stampa dei dati;
stabilità del sistema;
costi.
Su tali caratteristiche dobbiamo rilevare:
199
miglioramenti misurabili quantitativamente, mediante l’individuazione
di indicatori di processo;
livello di soddisfazione dell’utente, misurabile mediante un

questionario.
Le caratteristiche sopra riportate sono, in effetti, estremamente diverse

tra loro: alcune sono misurabili oggettivamente, altre possono essere
valutate solo dalla percezione dell’utente, altre sono note per precedenti
studi. Ve ne sono di più o meno conoscibili ed in modo più o meno preciso,
inoltre ognuna corrisponde ad un diverso livello di importanza.
Procediamo descrivendo per ogni singola caratteristica le prestazioni

dei due sistemi, cercando di individuare le caratteristiche critiche su cui
porre maggiormente l’attenzione e di estrarre indicatori di processo e
quesiti per il questionario.
Velocità
La velocità del database non è un parametro molto importante ai fini
del paragone tra i due sistemi. O meglio risulta estremamente grave la
“lentezza” superato un certo limite, ma all’interno di un intervallo di
velocità adeguato non risulta una importante proprietà distintiva la
maggiore o minore velocità di risposta del sistema. In effetti sia il sistema
preesistente che quello attuale presentano velocità adeguate di
funzionamento, ma comunque è noto che il database MySQL presenta
velocità superiori a Microsoft Access (vedi il confronto dei tempi nel
paragrafo del capitolo precedente: “Perché MySQL è meglio di Access”).
Date le premesse risulta pertanto inutilmente dispendioso effettuare

una rilevazione empirica sulle velocità dei due sistemi, mentre può essere
200
interessante porre una domanda nel questionario risguardo la velocità
percepita.
Usabilità dell’interfaccia
Quanto l’interfaccia è comprensibile e facile da usare e come le
informazioni vengono visualizzate all’utente finale. Questa caratteristiche
non sono misurabili oggettivamente, ma sono fortemente legate alla
percezione dell’utente: l’unica maniera per ottenere una valutazione
sull’usabilità è, pertanto, mediante quesito.
Ricerca delle informazioni

La facilità con cui si trova ciò che si cerca, la precisione nella risposta
del sistema. Sono queste le proprietà relative alla ricerca che bisogna
riuscire a valutare e che pertanto devono essere inserite nel questionario.
Qualità dei dati

La valutazione di questa caratteristica è estremamente ardua in quanto
è scomponibile in due aspetti: la qualità formale dei dati e la qualità
concettuale dei dati. Naturalmente solo la prima di tali caratteristiche può
essere misurata mentre la seconda risulta di difficile valutazione anche per
la percezione dell’utente.
La “qualità formale dei dati” può essere misurata precisamente

mediante diversi indicatori di processo:
numero di “codici” errati;
numero di “link” interrotti;
201
percentuale di volte che il “nuovo” sistema deve intervenire per
evitare un inserimento errato rispetto il totale degli inserimenti (nel
sistema preesistente non vi era alcun meccanismo di verifica dei dati
inseriti);
numero di istanze eliminate nel passaggio dal sistema preesistente

perché sbagliate.
Quantità dei dati contenibili

Questa misura è oggettiva ed indipendente dalla percezione
dell’utente. Non esistono livelli quantitativi precisi in quanto ciò dipende
anche dalla struttura relazionale con cui i dati vengono conservati, ma
secondo diversi studi Access è indicato per piccoli o medi database
dell’ordine di una decina di megabyte mentre MySQL può gestire anche
grandi database dell’ordine di centinaia di megabyte.
Sicurezza
Questa caratteristica è estremamente importante, ma risulta di difficile
valutazione in quanto dipende in buona parte dalla sicurezza del
“supporto”, cioè del server su cui sono installati i database. Nel nuovo
sistema sono implementati sistemi di identificazione degli utenti e di
backup di “alto livello” per il ripristino dei dati che però non possono
essere valutati se non con simulazioni estremamente approfondite e
complicate.
Esportazione e stampa dei dati

L’esportazione e la stampa dei dati è probabilmente il lato più forte
del sistema preesistente in quanto Access si interfaccia perfettamente con
gli altri prodotti Microsoft in commercio e prevede sofisticati meccanismi
202
di esportazione e stampa. In ogni caso è necessario chiamare l’utente a
rispondere sul quesito relativo alla stampa e all’importazione per dare una
valutazione significativa su tale caratteristica.
Stabilità del sistema

Questa proprietà è valutabile dopo un certo periodo di utilizzo del
sistema e sarà oggetto di un quesito nel questionario.
Costi
Il sistema sviluppato utilizza software liberamente reperibili ed
utilizzabili gratuitamente, mentre l’utilizzo di Access è vincolato da licenze
acquistabili sul mercato. Basta questo per dire che il nuovo sistema è
senz’altro più economicamente conveniente per l’azienda.
12.2. Valutazione degli indicatori di processo

Gli indicatori di processo che possiamo rilevare quantitativamente
sono relativi alla caratteristica “qualità formale dei dati”. In particolare
introducendo nuovi meccanismi di verifica dei dati è possibile misurare con
precisione la quantità di errori presenti nel vecchio e nel nuovo sistema
secondo diversi indicatori.
12.2.1. Numero di codici errati

Il numero di “codici elemento” errati è realizzabile mediante uno
script, che abbiamo già descritto in precedenza, e che dato un codice cerca
di interpretarne le caratteristiche della parte parlante e segnala un errore in
caso di fallimento.
Riportiamo il risultato che avevamo ottenuto con i codici del sistema

preesistente.
203
Nel nuovo sistema è implementata una procedura che si può
richiamare in qualsiasi momento e che si rifà al medesimo script che invece
restituisce il seguente risultato.
Come si può notare, oltre ad individuare i codici errati distingue tra

codici eliminabili e non eliminabili ed inoltre ne consente l’eliminazione o
la modifica. Per codice “eliminabile” si intende, come abbiamo già avuto
modo di spiegare, un codice errato che non è utilizzato in alcuna altra
tabella al di fuori della tabella “elementi”.
204
Su 8343 codici elemento nel nuovo sistema, vi sono 19 (0,23%) codici
errati di cui 5 presentano un formato errato e 14 parte parlante di codice
sconosciuta. In ogni caso vi è una netta riduzione di codici errati rispetto il
sistema preesistente.
12.2.2. Numero di link interrotti

Il numero di link interrotti è un buon indicatore della qualità dei dati.
Nel nuovo sistema è stato implementato un meccanismo che lega
indissolubilmente la sorte del documento con la sorte del relativo link, in
tal modo è impossibile che vi siano link che puntino a un documento
inesistente e quindi interrotti. Nel precedente sistema erano presenti invece
ben 25 link interrotti.
12.2.3. Percentuale di errori evitati nell’inserimento

Questo indicatore di processo ci consente di valutare quale
percentuale di dati inseriti sarebbe errata in assenza del sistema di verifica
sui dati. L’idea è quella di contare il numero di volte che il nuovo sistema
deve intervenire per evitare un inserimento errato e quindi per impedire un
inserimento che invece nel preesistente sistema sarebbe stato permesso.
Questo è realizzabile mediante un semplice file di log che registra

tutte le operazioni di modifica od inserimento di dati e tutte le
comunicazioni di errore che il sistema genera in seguito a tali operazioni.
Dall’analisi del suddetto file, in data 10 ottobre 2003 (9 giorni dopo

l’avvio del nuovo sistema) risulta che vi sono 34 errori rilevati ed impediti
dal sistema su 157 operazioni effettuate. Significa che senza il sistema di
verifica sui dati vi sarebbe stato una percentuale di errore, pari a circa il
22% dei dati inseriti.
205
In ogni caso tale valore deve essere preso con cautela in quanto
bisogna tenere conto di due fattori che ne inquinano in parte il valore:
l’operatore addetto all’inserimento è alle prese per la prima volta con

il nuovo sistema;
essendo presenti meccanismi di verifica automatica è probabile che si

proceda con un po’ meno attenzione affidandosi al sistema per la
rilevazione degli errori più banali.
12.2.4. Istanze eliminate nel passaggio al nuovo sistema

In fase di importazione viene tenuto traccia di tutte le istanze
eliminate in un file denominato “istanze_non_inserite.txt”: contando per
ogni tabella il numero di righe risaliamo al totale di errori “strutturali”
presenti in precedenza nel sistema.
Di seguito riportiamo i risultati dell’analisi.
206
TABELLA N° ISTANZE NON INSERITE
elementi 15
distinte 0
revisioni 3
link 18
cod_costr 108
altri_costr 4
fornitori 1
costi 2
masa 2
op_masa 3
TOTALE 156
12.3. Il questionario
L’altro elemento fondamentale per la valutazione dei risultati ottenuti
è la creazione di un questionario da sottoporre a tutti gli utenti del database.
Il formato del questionario è estremamente semplice e punta a dare una
valutazione oggettiva [5] sui miglioramenti ottenuti nel nuovo sistema
rispetto il precedente sulla base di alcune caratteristiche prestazionali
primarie.
Il questionario indaga sull’utilità del sistema solo dal punto di vista

dell’utente comune in quanto essendovi un solo amministratore non
avrebbe senso porre quesiti riguardo l’interfaccia di amministrazione.
Riportiamo nella pagina seguente il questionario che abbiamo

sottoposto agli utenti.
207
Come si può notare viene richiesta una valutazione sull’importanza
relativa alle caratteristiche in analisi e successivamente, nel secondo e nel
terzo riquadro, viene richiesta una valutazione sul livello di prestazione del
preesistente database Access e del nuovo sistema in uso.
208
È possibile pertanto dare una valutazione media per ogni caratteristica
dei due database ed inoltre calcolare una media globale, pesata
sull’importanza attribuita ad ogni prestazione, dei due sistemi.
209
Riportiamo di seguito i risultati ottenuti.
RISULTATO QUESTIONARIO ACCESS

5
MYSQL
TA
tà
tà
à
ca
pa
ne
lit
on
ci
ili
er
SA
am
io
i
lo
ab
ab
zi
ri c
az
PE
za
ve
st
st
us
rt
iz
po
IA
al
es
ED
su
vi
12.4. Valutazioni conclusive sul nuovo sistema

In base alle valutazione statistiche effettuate possiamo affermare che il
sistema implementato presenta innumerevoli lati positivi ed anche qualche
lato negativo
12.4.1. Miglioramenti ottenuti

I principali risultati positivi ottenuti sono:
pulizia dei dati preesistenti: 156 istanze errate eliminate in fase di

importazione dei dati;
azzeramento del numero di link interrotti;
210
riduzione dei codici errati dall’1,08% allo 0,27% sul totale degli
elementi;
blocco dell’inserimento, causa dati errati, del 22% degli inserimenti

effettuati (dato comunque destinato a ridursi nel tempo all’aumentare
dell’esperienza dell’operatore);
netto miglioramento della soddisfazione dell’utente riguardo la

visualizzazione;
maggiore stabilità del sistema.
12.4.2. I lati negativi

Naturalmente vi è anche qualche lato negativo, in particolare sono
state individuate carenze nelle seguenti caratteristiche:
esportazione delle informazioni;
stampa dei dati.
211
Conclusioni
Il sistema informativo che abbiamo sviluppato è entrato in funzione

nell’azienda il primo ottobre 2003 ed attualmente si stanno ottenendo i
primi risultati delle innovazioni gestionali introdotte.
La definizione di meccanismi per la verifica ed il controllo dei dati in

fase di inserimento garantisce al sistema l’integrità e l’affidabilità dei dati
contenuti nel database; la “procedura di approvazione” prevista per i
componenti, le distinte e le revisioni introduce una giusta ed equilibrata
distribuzione delle responsabilità tra gli utenti del sistema; la gestione
integrata dei documenti allegati con il database garantisce la reperibilità e
la sicurezza di tutti i documenti importanti per l’azienda; l’introduzione di
metodologie di ricerca dettagliata consentono all’utente di effettuare
interrogazioni complesse del database e di trovare le informazioni ricercate
con maggiore precisione; la gestione dei permessi utente per l’accesso al
database secondo diversi livelli permette di proteggere le aree riservate;
l’introduzione di un sistema di backup e ripristino dei dati ad “alto livello”,
consente di cautelarsi da errori nell’amministrazione dei dati e da crash
“non gravi” del sistema. Inoltre grazie al supporto informativo dato dalla
coppia formata da PHP e MySQL, si ottiene un risultato estremamente
flessibile, economico, indipendente dalla piattaforma software utilizzata ed
è stato possibile, sfruttando l’attitudine dell’utente alla navigazione nella
rete Internet, implementare un’interfaccia estremamente “user friendly”
nonché estremamente potente.
212
Sviluppi futuri
Il naturale sviluppo per un sistema sviluppato nel linguaggio PHP e su

database MySQL è la rete Internet. Tra i possibili sviluppi futuri del
sistema vi è in effetti un integrazione informativa tra l’azienda e i fornitori
e tra l’azienda e i terzisti che per essa realizzano alcuni prodotti: questi tre
attori della filiera sono legati tra loro proprio dalla distinta base che da un
lato rappresenta una ricetta tecnica per produrre e dall’altro una lista di
componenti da acquistare.
L’altro rilevante sviluppo possibile relativo al sistema sviluppato

riguarda le carenze notate in fase di valutazione per quanto riguarda
l’esportazione e la stampa delle informazioni. E’ in effetti possibile
sviluppare un sistema per l’esportazione delle informazioni in un formato
più portabile e più adeguato alla stampa, il P.D.F. (Portable Document
Format) che è supportato da PHP. Questo consentirebbe di ottenere stampe
migliori ed adatte anche a presentazioni importanti.
213
Bibliografia
[1] Atzeni, Ceri, Paraboschi, Torlone. Basi di dati: concetti,

linguaggi e architetture. McGraw-Hill Italia, 1999.
[2] Axmark David, Widenius Michael. MySQL Reference Manual

(http://www.mysql.com/documentation/mysql/bychapter/index.ht
ml).
[3] Bakken, Aulbach, Schmid, Winstead, Wilsons, Lerdorf,

Zmievski, Ahto. Manuale PHP (http://www.php.net/manual/it/).
[4] Boscarol Maurizio. Che cos'

è l'
usabilità dei siti web
(http://www.usabile.it/012000.htm). Usabile.it, 2000.
[5] Bosco Andrea. Come si costruisce un questionario. Carrocci, Le

Bussole, 2003.
[6] Clancy Jon. Engineering bill of materials. Ciras News

(http://www.ciras.iastate.edu/publications/CIRASNews/fall97/bo
m.htm)
[7] Dubois Paul. Migrating from Microsoft Access to MySQL. 2003

(http://www.kitebird.com/articles/access-migrate.html).
[8] Gugnelli Emanuela. Usabilità dei siti web. HTML.it

(http://www.html.it/usabilita/).
[9] Insinga Filippo. La gestione della produzione e della supply

chain. ISU Università Cattolica, 2002.
[10] Lerdorf Rasmus. PHP Pocket Reference. Hops Libri, 2000.
[11] Meyer Eric. CSS Pocket Reference. Hops Libri, 2001.
214
[12] Stevahn, Waters. CSS Printing Extensions. Håkon Wium Lie
(http://www.w3.org/pub/WWW/TR/WD-print-970626)
[13] Travis David. Bluffers’ guide to ISO9241. Userfocus, 2003

(http://www.userfocus.co.uk/articles/ISO9241.pdf ).
215
Ringraziamenti
Ringraziamenti vanno a tutti coloro che hanno collaborato alla

realizzazione di questa tesi ed in particolare alla Dott. Wilma Penzo, che
come relatore ha fornito le linee guida, all’Ing. Andrea Regazzi, che mi ha
costantemente affiancato nella realizzazione operativa del sistema, agli
ingegneri Katy Proietti e Fabio Galli, che mi hanno dato preziosi consigli e
a tutti i dipendenti di SADEL s.r.l.
216

Progettazione e Sviluppo Di Un Sistema Informativo Per La Gestione Della Distinta Base

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Progettazione e Sviluppo Di Un Sistema Informativo Per La Gestione Della Distinta Base

Caricato da

Copyright:

Formati disponibili

Università degli Studi di Bologna

Corso di Laurea in Ingegneria Gestionale

Progettazione e Sviluppo di un Sistema Informativo

Tesi di Laurea di: Relatore:

Michele Borghi Chiar.ma Prof. Wilma Penzo

Ing. Marco Patella

Ing. Andrea Regazzi

Anno Accademico 2002-2003

1.1. La definizione di distinta base ______________________15

1.2. Le conseguenze di errori nella distinta base ___________16

1.3. La struttura della distinta base _____________________17

1.4. La distinta base nei sistemi MRP ____________________18

1.5. Le problematiche relative alla distinta base ___________19

1.6. L’importanza della distinta base ____________________20

2. IL SISTEMA PREESISTENTE ___________________________21

2.1. Caratteristiche tecniche ___________________________21

2.2. La struttura del database __________________________22

2.3. Analisi della qualità dei dati ________________________39

2.4. Analisi delle procedure di gestione __________________48

2.5. Analisi dei sistemi di sicurezza ______________________55

2.6. Analisi dell’interfaccia ____________________________57

3.1. Gli obiettivi da raggiungere ________________________64

3.2. La soluzione proposta _____________________________64

3.3. La soluzione operativa: il modello di riferimento_______67

4. LA GESTIONE DELLE DISTINTE ________________________73

4.1. I limiti del sistema preesistente _____________________73

4.2. La distinta base per Sadel__________________________74

4.3. I requisiti della distinta base________________________80

4.4. La proposta operativa_____________________________81

5. LA GESTIONE DELLE REVISIONI _______________________87

5.1. Cosa si intende per revisione _______________________87

5.2. Gli obiettivi da raggiungere ________________________88

5.3. Gli elementi obsoleti ______________________________89

5.4. La politica aziendale delle revisioni __________________89

5.5. L’effetto domino sulle revisioni _____________________92

5.6. Il confronto tra le due alternative ___________________94

6. LA PROCEDURA DI APPROVAZIONE ____________________97

6.1. La situazione preesistente__________________________97

6.2. Come affrontare il problema _______________________98

6.3. Il protocollo di approvazione _______________________99

6.4. I miglioramenti apportati _________________________104

7. LA GESTIONE DEI DOCUMENTI _______________________105

7.1. I documenti nel sistema preesistente ________________105

7.2. Una soluzione semplice e potente ___________________106

7.3. Obiettivi raggiunti_______________________________108

8. RICERCA E VISUALIZZAZIONE DELLE INFORMAZIONI _109

8.1. Il limite del sistema preesistente____________________110

8.2. Le viste principali e la struttura delle informazioni ____114

8.3. La struttura di visualizzazione_____________________116

8.4. La ricerca ______________________________________117

8.5. La progettazione operativa________________________119

8.6. Esportazione e stampa delle informazioni____________121

9.1. Gestione dei permessi di accesso ___________________123

9.2. Sistemi di prevenzione e recupero dei dati ___________127

10. IL PROGETTO DELLA BASE DI DATI ___________________131

10.1. La progettazione concettuale ______________________131

10.2. La progettazione logica___________________________142

10.3. La progettazione fisica ___________________________145

11. L’IMPLEMENTAZIONE DEL SISTEMA__________________154

11.1. Gli strumenti ___________________________________154

11.2. La realizzazione del database______________________159

11.3. L’interfaccia utente ______________________________172

12. VARO DEL SISTEMA E SUA VALUTAZIONE _____________199

12.1. Come misurare i miglioramenti ottenuti _____________199