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
2.
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
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.
7.
8.
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
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
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
9.
8.5.
La progettazione operativa________________________119
8.6.
Esportazione e stampa delle informazioni____________121
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.
6
La progettazione fisica ___________________________145
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” qualiquantitativo 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).
TBLELEMENTI
(0,N) PADRE
TBLDISTINTE
(0,N) FIGLIO
A questo punto è possibile ricavare lo “schema scheletro” della
struttura del database preesistente.
24
(1,1)
(0,N)
tblaltricostruttori
tblcodicicostruttori
Tabellamasa
(0,N)
(1,N)
(0,1)
(0,N)
(1,1)
(0,1)
(1,1)
(0,1)
(0,1)
tblelementi
(0,N)
PADRE
(0,N)
FIGLIO
tbllink
tblrevisioni
tbldistinte
(0,N)
tblcosti
(0,N)
(1,1)
Tabellaoperazionimas
tblfornitori
(0,N)
(0,N)
tblLottoProd
(0,1)
(1,1)
tblordini
(0,1)
(0,1)
(0,N)
tblTipoAcq
(0,N)
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
DELLA
PRODUZIONE
(1,1)
(0,N)
tblaltricostruttori
tblcodicicostruttori
Tabellamasa
(0,N)
(1,N)
(0,1)
(0,N)
(1,1)
(0,1)
(1,1)
(0,1)
(0,1)
tblelementi
(0,N)
PADRE
(0,N)
FIGLIO
tbllink
tblrevisioni
tbldistinte
(0,N)
tblcosti
(0,N)
(1,1)
Tabellaoperazionimas
tblfornitori
(0,N)
(0,N)
tblLottoProd
(0,1)
(1,1)
tblordini
(0,1)
(0,1)
(0,N)
tblTipoAcq
(0,N)
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 autoincrementante;
“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.
Per
L’inserimento di una distinta
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 semiparlante 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
1
codice corretto
SIGNIFICATO
codice errato
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
PARTE_1
TIPO_1
3.3.2.
FORMATO_2
PARTE_2
TIPO_2
TIPO_3
FORMATO_3
PARTE_3
TIPO_4
NUMERO
TIPO_5
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
formato2:descrizione_formato2
formato3:descrizione_formato3
69
[parte2_formato2]
tipo1_parte2_formato2:descrizione_tipo1_parte2_formato2
tipo2_parte2_formato2:descrizione_tipo1_parte2_formato2
tipo3_parte2_formato2:descrizione_tipo1_parte2_formato2
tipo4_parte2_formato2:descrizione_tipo1_parte2_formato2
tipo5_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
HS0030-03
AC0060
MC0013
PM0025-02
PM0513-01
UN1004
UN1221
PS0035-SM03
Quantità
1
1
1
1
1
4
14
0
Descrizione
SCHEDA OBOE OUT VER6
CAVO
MODULO GSM/GPRS
CUSTODIA IN ALLUMNINIO OBOE OUT
GHIERA DI FISSAGGIO
VITE
RONDELLA
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
1 TS0036
1
2 1CC6214
2 CAP7 CAP11
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
Descrizione
CIRCUITO STAMPATO
CONDENSATORE CERAMICO
DIGITAL INVERTER (CIRCUITO INTEGRATO)
CONNETTORE
DIODO
INDUTTORE
LED VERDE
RESISTENZA
RESISTENZA
RESISTENZA
TRASFORMATORE AUDIO
TRANSISTOR
CONDENSATORE ELETTROLITICO VERTICALE
CONDENSATORE ELETTROLITICO RADIALE
CONNETTORE FISSO 19 POLI MASCHIO
INDUTTORE
OPTOISOLATORE
SCHEMATICO
PCB
GERBER
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
Codice elemento
AC0036
PM0025-CM01
Quantità
Descrizione
CUSTODIA IN ALLUMINIO 140X180X70
1
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
Codice elemento
2SCO0152
AC0040
Quantità
Descrizione
CONNETTORE FISSO 19 POLI MASCHIO
1
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
HS0030-03
AC0060
MC0013
PM0025-02
PM0513-01
UN1004
UN1221
PS0035-SM03
Quantità
1
1
1
1
1
4
14
0
DISTINTA HS0030-03
DISTINTA PM0025-02
Pos
Codice
Qtà
Reference
1 TS0036
1
2 1CC6214
2 CAP7 CAP11
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
Codice elemento
AC0036
PM0025-CM01
Quantità
1
0
DISTINTA 2SCO1035-01
Codice elemento
2SCO0152
AC0040
4.3.
Quantità
1
19
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 autoassociazione relativa all’entità ELEMENTI, come in effetti era nel database
preesistente: “un elemento può essere padre o figlio di un altro elemento”.
ELEMENTI
(0,n)
(0,n) padre
DISTINTE
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
ELEMENTI
data
(0,n) padre
DISTINTE
approvato
(0,n)
figlio
obsoleto
gestione
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
SCHEDA-01
A
SCHEDA-02
B
5.2.
C
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
(OBS)
HS0001-01
PS0003-01
(OBS)
X
REVISIONE
PS0003-01
(OBS)
Y
Y
HS0001-01
PS0123-01
J
K
X
HS0001-02
REVISIONE
PS0123-01
J
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
(OBS)
HS0001-01
PS0003-01
(OBS)
X
REVISIONE
PS0003-01
(OBS)
Y
X
Y
HS0001-01
(OBS)
PS0123-01
(OBS)
HS0001-01
PS0123-01
J
J
K
REVISIONE
HS0001-02
K
PS0123-02
J
K
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
dell’albero della distinta implica una sola
revisione.
Il cambiamento di un elemento alla base
dell’albero della distinta implica la
propagazione di nuove revisione fino
all’elemento radice.
Il totale delle revisioni per scheda o
componente è in media basso (esempio: se
un prodotto contiene 5 schede e per ogni
scheda escono 3 revisioni, viene
aggiornata la distinta del prodotto 15
volte, ma il numero di revisione non
cambia).
Il totale delle revisioni per scheda o
componente sarebbe in media
notevolmente più alto (esempio: se un
prodotto contiene 5 schede e per ogni
scheda escono 3 revisioni, per il prodotto
verranno generate ben 15 revisioni e
relative distinte).
Si perdono informazioni storiche sulla
composizione esatta delle vecchie distinte
(esempio: se un cliente riscontra un
problema su un prodotto non si è in grado
di sapere con certezza quali versioni di
schede sono presenti su di esso). Possibili
problemi in fase di ASSISTENZA.
Vi è la reperibilità totale delle
informazioni relative a vecchie distinte
successivamente sottoposte a revisioni (a
un determinato codice di scheda
corrisponde esattamente una e una sola
distinta perché non è mai stata
modificata).
In fase di PRODUZIONE non vi sono
problemi perché vi è la certezza che ogni
distinta non obsoleta è composta con le
ultime versioni esistenti dei suoi
componenti.
In fase di PRODUZIONE non vi sono
problemi: l'
ultima revisione di un prodotto
ha, in distinta, tutte le ultime revisioni dei
sui componenti.
Se un componente è presente in più
distinte (ha più padri), la sua eventuale
revisione, non propagandosi, non influisce
sul numero di revisione degli elementi
padre.
Un componente con più padri propaga
l’aggiornamento di revisioni in più
direzioni con l’effetto collaterale di
ritrovarsi nuove revisioni di prodotti che
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
DEL SISTEMA
L'
utente richiede all'
amministratore
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
AMMINISTRATORE
DEL SISTEMA
UTENTE
1) L'
amministratore
richiede
l'
identificazione
3) Se l'
amministartore ha i
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
DB
100
DATABASE
SADEL
FASE 3: INSERIMENTO DEI DATI
UTENTE
3) Il programma
invia un'
email all'
utente
informandolo che gli è
stata richiesta una
approvazione
1) L'
amministratore
inserisce i dati relativi alla
codifica o alla revisione
di un elemento e
sceglie se farlo
approvare e da
chi
AMMINISTRATORE
DEL SISTEMA
2) Il programma controlla e
reinvia iterativamente i dati
all'
amministartore finché
non risultano formalmente
corretti
PROGRAMMA
DI GESTIONE
4) Vengono inseriti nel database tutti i dati tranne
la conferma di approvazione dell'
utente
DB
DATABASE
SADEL
101
FASE 4: LOGIN DELL'UTENTE
AMMINISTRATORE
DEL SISTEMA
UTENTE
1) L'
utente richiede
l'
identificazione
3) Se l'
utente ha i
dovuti permessi viene
restituita l'
autorizzazione
all'
approvazione e 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
DB
102
DATABASE
SADEL
FASE 5: APPROVAZIONE FINALE
UTENTE
1) Dopo aver controllato i dati inseriti
l'
utente decide se approvarli o meno,
inviando la sua scelta
al programma di gestione
AMMINISTRATORE
DEL SISTEMA
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 è
concessa, i dati inseriti rimangono
nel database, ma senza la "firma"
dell'
utente.
DB
DATABASE
SADEL
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)
CONDENSATORI
.....
RESISTENZE
.....
CIRCUITI
INTEGRATI
.....
CONNETTORI
.....
DIODI
.....
TRANSISTOR
.....
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
ELEMENTI
(0,n)
(0,n)
(1,1)
CONDENSATORI
.....
(1,1)
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"
LIVELLO "ELEMENTI"
LIVELLO
"CARATTERISTICHE"
8.4.
DISTINTA
PRODOTTI
MAGAZZINO
PS0001
PS0002
PS0003
REVISIONE
COSTO
COSTRUTTORI
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
TESTUALE
NUMERICO
OPZIONI
DATA
FORM
parola ricercata
=
valore
K (E +03)
± valore
intervallo su cui ricercare
menu a tendina con l'
elenco delle opzioni possibili
opzione_1
>
ordine di grandezza
giorno
mese
anno
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.
QUERY SQL
FUNZIONE DI
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
QUERY SQL
FUNZIONE DI
SELEZIONE
FUNZIONE DI
VISUALIZZAZIONE
8.6.
SPECIFICHE
HTML
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
UTENTE
DATI
APPLICAZIONE
PERMESSO
UTENTE
DATI
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à
e-mail
nome_completo
permesso
relativa ad essa.
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
ELEMENTO
altri costruttori (0,N)
costruttore
note
posizione magazzino (0,1)
numero pezzi
operazioni magazzino (0,N)
data
causale
documenti/files allegati (0,N)
link
note
descrizione (1,1)
data (1,1)
obsoleto (1,1)
note (0,1)
codice elemento (1,1)
L’entità “utente”
nome completo (1,1)
UTENTE
nome utente (1,1)
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)
codice elemento (1,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)
COSTO
valuta (1,1)
data (1,1)
numero pezzi (1,1)
(0,N)
note (0,1)
FORNITORE
id
138
L’autoassociazione “distinta”
PADRE
FIGLIO
(0,N)
(0,N)
codice distinta (1,1)
codice elemento
codice elemento (1,1)
ELEMENTI
DISTINTE
posizione (1,1)
quantità (1,1)
reference (0,1)
gestione (0,1)
note (0,1)
139
I componenti speciali
codice elemento (1,1)
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)
codice elemento (1,1)
RESISTENZA
ohm (1,1)
tolleranza (0,1)
case (0,1)
potenza (0,1)
ppm (0,1)
altro (0,1)
codice elemento (1,1)
CONNETTORE
descrizione (1,1)
tipo (1,1)
numero di poli (1,1)
posizione (1,1)
codice costruttore (1,1)
altro (0,1)
140
codice elemento (1,1)
CIRCUITO
INTEGRATO
categoria (1,1)
descrizione (1,1)
package (1,1)
tipo (1,1)
codice costruttore (1,1)
altro (0,1)
codice elemento (1,1)
DIODO
codice costruttore (1,1)
caratteristica (0,1)
reverse voltage (0,1)
forward current (0,1)
package (0,1)
altro (0,1)
codice elemento (1,1)
TRANSISTOR
codice costruttore (1,1)
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
CODICE_ELEMENTO
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_ELEMENTO
STRINGA 30
NO
CODICE_COSTRUTTOR
E
STRINGA 60
NO
COSTRUTTORE
STRINGA 60
SI
NOTE
TESTO
SI
ALTRI_COSTR
TIPO
NULL
CODICE_ELEMENTO
STRINGA 30
NO
COSTRUTTORE
STRINGA 60
NO
CODICE_COSTRUTTO
RE
STRINGA 60
NO
NOTE
TESTO
SI
147
LINK
TIPO
NULL
CODICE_ELEMENTO
STRINGA 30
NO
LINK
STRINGA 150
NO
NOTE
TESTO
SI
REVISIONI
TIPO
NULL
CODICE_ELEMENTO
STRINGA 30
NO
DESCRIZIONE
TESTO
NO
MOTIVAZIONE
TESTO
SI
DATA
DATA AAAA-MM-GG
NO
ORIGINATO
STRINGA 30
SI
APPROVATO
STRINGA 30
SI
CONSEGUENZE
TESTO
SI
AZIONI_ATTUATE
TESTO
SI
LINK
STRINGA 150
SI
MASA
TIPO
NULL
CODICE_ELEMENTO
STRINGA 30
NO
POSIZIONE
STRINGA 10
SI
148
OP_MASA
TIPO
NULL
ID
INTERO 6
PROGRESSIVO
NO
CODICE_ELEMENTO
STRINGA 30
NO
NPEZZI
INTERO 8 CIFRE
NO
DATA
DATA AAAA-MM-GG
NO
CAUSALE
TESTO
SI
COSTI
TIPO
NULL
ID
INTERO 6
PROGRESSIVO
NO
CODICE_ELEMENTO
STRINGA 30
NO
COSTO
DECIMALE 0.00000
NO
DATA
DATA AAAA-MM-GG
NO
NPEZZI
INTERO 6 CIFRE
SI
NOTE
TESTO
SI
ID_FORNITORE
INT 6 CIFRE
SI
149
FORNITORI
TIPO
NULL
ID
INTERO 6
PROGRESSIVO
NO
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
CODICE_ELEMENTO
STRINGA 30
NO
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
CODICE_ELEMENTO
STRINGA 30
NO
OHM
REALE
NO
TOLLERANZA
DECIMALE
SI
CASE
INTERO 6
SI
POTENZA
REALE
SI
PPM
INTERO 6
SI
ALTRO
BLOB
SI
CONNETTORI
TIPO
NULL
CODICE_ELEMENTO
STRINGA 30
NO
DESCRIZIONE
STRINGA 100
NO
TIPO_CONNETTORE
SET DI VALORI
SI
N_POLI
STRINGA 10
SI
POSIZIONE
SET DI VALORI
SI
CODICE_COSTRUTTOR
E
STRINGA 60
SI
ALTRO
BLOB
SI
151
CIRCUITI_INTEGRATI
TIPO
NULL
CODICE_ELEMENTO
STRINGA 30
NO
CATEGORIA
SET DI VALORI
NO
DESCRIZIONE
STRINGA 100
SI
PACKAGE
STRINGA 100
SI
TIPO_COMPONENTE
SET DI VALORI
SI
CODICE_COSTRUTTOR
E
STRINGA 60
SI
ALTRO
BLOB
SI
DIODI
TIPO
NULL
CODICE_ELEMENTO
STRINGA 30
NO
CODICE_COSTRUTTOR
E
STRINGA 60
NO
CARATTERISTICA
SET DI VALORI
SI
REVERSE_VOLTAGE
REALE
SI
FORWARD_CURRENT
REALE
SI
PACKAGE
STRINGA 100
SI
ALTRO
BLOB
SI
152
TRANSISTOR
TIPO
NULL
CODICE_ELEMENTO
STRINGA 30
NO
CODICE_COSTRUTTOR
E
STRINGA 60
NO
TIPO
SET DI VALORI
SI
TENSIONE
REALE
SI
CORRENTE
REALE
SI
PACKAGE
STRINGA 100
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 `altri_costr`
CREATE TABLE `altri_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` (
`codice_elemento` varchar(30) NOT NULL default '',
`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',
`codice_costruttore` varchar(60) NOT NULL default '',
`altro` blob,
PRIMARY KEY (`codice_elemento`)
) TYPE=MyISAM;
# Struttura della tabella `cod_costr`
CREATE TABLE `cod_costr` (
`codice_elemento` varchar(30) NOT NULL default '',
`codice_costruttore` varchar(60) NOT NULL default '',
`costruttore` varchar(60) default NULL,
`note` blob,
PRIMARY KEY (`codice_elemento`)
) TYPE=MyISAM;
# Struttura della tabella `condensatori`
CREATE TABLE `condensatori` (
`codice_elemento` varchar(60) NOT NULL default '',
`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,
`altro` blob,
PRIMARY KEY (`codice_elemento`)
) TYPE=MyISAM;
160
# Struttura della tabella `connettori`
CREATE TABLE `connettori` (
`codice_elemento` varchar(30) NOT NULL default '',
`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',
`codice_costruttore` varchar(60) NOT NULL default '',
`altro` blob,
PRIMARY KEY (`codice_elemento`)
) TYPE=MyISAM;
# Struttura della tabella `costi`
CREATE TABLE `costi` (
`id` int(6) NOT NULL auto_increment,
`codice_elemento` varchar(60) NOT NULL default '',
`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,
`id_fornitore` int(6) default NULL,
PRIMARY KEY (`id`)
) TYPE=MyISAM;
# Struttura della tabella `diodi`
CREATE TABLE `diodi` (
`codice_elemento` varchar(30) NOT NULL default '',
`codice_costruttore` varchar(60) NOT NULL default '',
`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,
`altro` blob,
PRIMARY KEY (`codice_elemento`)
) TYPE=MyISAM;
# Struttura della tabella `distinte`
CREATE TABLE `distinte` (
`codice_distinta` varchar(30) NOT NULL default '',
`codice_elemento` 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 `elementi`
CREATE TABLE `elementi` (
`codice_elemento` varchar(30) NOT NULL default '',
`descrizione` blob NOT NULL,
`data` date NOT NULL default '0000-00-00',
`approvato` varchar(30) default NULL,
`obsoleto` enum('NO','SI') NOT NULL default 'NO',
`note` blob,
PRIMARY KEY (`codice_elemento`)
) TYPE=MyISAM;
# Struttura della tabella `fornitori`
CREATE TABLE `fornitori` (
`id` int(6) NOT NULL auto_increment,
`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 (`id`)
) TYPE=MyISAM;
# Struttura della tabella `link`
CREATE TABLE `link` (
`codice_elemento` varchar(30) NOT NULL default '',
`link` varchar(150) NOT NULL default '',
`note` blob,
PRIMARY KEY (`codice_elemento`,`link`)
) TYPE=MyISAM;
# Struttura della tabella `masa`
CREATE TABLE `masa` (
`codice_elemento` varchar(30) NOT NULL default '',
`posizione` varchar(10) default NULL,
PRIMARY KEY (`codice_elemento`)
) TYPE=MyISAM;
# Struttura della tabella `op_masa`
CREATE TABLE `op_masa` (
`id` int(6) NOT NULL auto_increment,
`codice_elemento` varchar(30) NOT NULL default '',
`npezzi` decimal(8,0) NOT NULL default '0',
`data` date NOT NULL default '0000-00-00',
`causale` blob,
PRIMARY KEY (`id`)
) TYPE=MyISAM;
162
# Struttura della tabella `resistenze`
CREATE TABLE `resistenze` (
`codice_elemento` varchar(30) NOT NULL default '',
`ohm` 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,
`altro` blob,
PRIMARY KEY (`codice_elemento`)
) TYPE=MyISAM;
# Struttura della tabella `revisioni`
CREATE TABLE `revisioni` (
`codice_elemento` varchar(30) NOT NULL default '',
`descrizione` blob NOT NULL,
`motivazione` blob,
`data` date NOT NULL default '0000-00-00',
`originato` varchar(30) default NULL,
`approvato` varchar(30) default NULL,
`conseguenze` blob,
`azioni_attuate` blob,
`link` varchar(150) default NULL,
PRIMARY KEY (`codice_elemento`)
) TYPE=MyISAM;
# Struttura della tabella `transistor`
CREATE TABLE `transistor` (
`codice_elemento` varchar(30) NOT NULL default '',
`codice_costruttore` varchar(60) NOT NULL default '',
`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,
`altro` blob
) TYPE=MyISAM;
# Struttura della tabella `utenti_db`
CREATE TABLE `utenti_db` (
`nome_completo` varchar(100) NOT NULL default '',
`nome` varchar(30) NOT NULL default '',
`permesso` enum('AMMINISTRATORE','SADEL','ESTERNO') NOT NULL default
'ESTERNO',
`email` 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 `utenti_db` VALUES ('MICHELE BORGHI','mick',
'AMMINISTRATORE', '[email protected]');
GRANT ALL ON *.* TO mick@localhost identified by 'mick' WITH GRANT
OPTION;
INSERT INTO `utenti_db` VALUES ('ANDREA REGAZZI','andrear',
'AMMINISTRATORE', '[email protected]');
GRANT ALL ON *.* TO andrear@localhost identified by 'sadel' WITH GRANT
OPTION;
INSERT INTO `utenti_db` VALUES ('PINCO PALLINO','sadel', 'SADEL',
'[email protected]');
grant create,select on sadel.* to sadel@localhost identified by
'sadel';
grant delete on sadel.approvazione to sadel@localhost identified by
'sadel';
grant update (`approvato`) on sadel.elementi to sadel@localhost
identified by 'sadel';
grant update (`approvato`) on sadel.revisioni to sadel@localhost
identified by 'sadel';
INSERT INTO `utenti_db` VALUES ('TIZIO CAIO','esterno', 'ESTERNO',
'[email protected]');
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
ALLEGATI
DATABASE
MySQL
DOCUMENTO
ALLEGATI
DATABASE
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
fornitori
costi
4
1
2
masa
op_masa
2
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
4
3
2
1
12.4.
PE
SA
TA
M
ED
IA
st
am
pa
es
po
rt
az
io
ne
tà
st
ab
ili
ri c
er
ca
vi
su
al
iz
za
zi
on
e
lit
à
us
ab
i
ve
lo
ci
tà
0
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