Il database

Capitolo 4. Realizzazione di un sistema efficace ed efficiente di raccolta dati

60

Figura 4.3 - Nuova struttura per l'organizzazione delle informazioni

61

informazioni legate ai controlli di qualità. La struttura logica sulla quale si fonda il sistema segue precisamente quella relativa alla necessità di creare un collegamento tra i principali elementi utilizzati: le specifiche di produzione, il difetto, l’intervento e la data di effettuazione. In questo modo è possibile progettare un sistema che presenti queste caratteristiche attraverso un database. Quest’ultimo rappresenta un'entità nella quale è possibile immagazzinare dei dati in modo strutturato e con un certo grado di univocità. I dati contenuti in una tabella, facente parte di un database, possono essere inseriti, aggiornati e cancellati in qualsiasi momento, con il grande vantaggio di essere sempre accessibili facilmente ed efficacemente. Oltretutto, è possibile relazionare i dati contenuti in tabelle differenti modo tale da avere un sistema snello, ma all’occorrenza fornire tutte le informazioni generali di cui si ha bisogno. La flessibilità quindi che dimostra il database lo rende lo strumento migliore nell’implementazione del sistema, oggetto di questo elaborato.

Le scelte di natura progettuale hanno portato alla realizzazione di una base di dati che raccogliesse e gestisse tutte le informazioni relative agli interventi da registrare.

L’elemento a cui ruoterà tutto il sistema è rappresentato proprio dalla registrazione degli eventi, ovvero le “difettosità”, e le relative azioni che verranno svolte per limitare la loro incidenza. La memorizzazione dei dati secondo la logica già introdotta (specifica - difetto – azione – data) sarà il fulcro attorno al quale ruoterà la parte di progettazione del database. A partire dalle funzionalità che verranno introdotte nel nostro sistema si è definito lo schema di partenza attorno al quale tutte queste proprietà possano essere implementate. La progettazione di un qualsiasi database passa attraverso diverse fasi che dall’idea astratta iniziale portano alla realizzazione fisica di quest’ultimo. In questo senso occorre innanzitutto definire il modello concettuale alla base della realizzazione della base di dati. Un modello concettuale di dati identifica uno strumento per la rappresentazione dal punto di vista concettuale dei dati ad un alto livello di astrazione, caratterizzato dalla presenza di alcuni particolari tipi di costrutti. Per la realizzazione di uno schema astratto che definisse le linee generali del nostro sistema si è costruito un modello E-R, ovvero entity-relationship (Figura 4.4). La sua rappresentazione si basa su elementi di base definiti come: entità, attributi e relazioni logiche; le quali sono state individuate e rappresentate nel modello in figura.

Capitolo 4. Realizzazione di un sistema efficace ed efficiente di raccolta dati

62

Figura 1.4 - Modello Entity-Relationship del sistema

Questo modello identifica quelle che sono le componenti astratte sulle quali viene costruito il modello fisico, rappresentante il database, vero e proprio. Le entità quindi riprendono la logica descritta in precedenza; sarà possibile associare un difetto, che potrà coinvolgere differenti specifiche, ad uno o più particolari interventi a disposizione. Le relazioni identificano invece i legami che intercorrono tra le diverse entità, esprimendo in maniera chiara il collegamento che unisce le due entità. Le associazioni presenti sulle relazioni identificano invece le molteplicità, cioè ad esempio un evento può essere associato ad un solo difetto, mentre un difetto può essere associato a più eventi. Infine,

63

per ogni entità vengono individuati gli attributi che definiscono le proprietà che caratterizzeranno i costrutti (Naiburg, Eric J., and Robert A. Maksimchuck). La fase successiva è invece rappresentata dalla definizione del modello fisico che costituisce il database (Figura 4.5), ovvero l’insieme di tabelle e relazioni tra le varie componenti del sistema. Successivamente verranno definiti gli attributi che rappresenteranno i valori contenuti nel database e le relazioni che hanno lo scopo di collegare le informazioni contenute nelle differenti tabelle. La differenza tra il modello E-R e quello fisico è espressa dal grado di dettaglio delle informazioni contenute; il primo delinea le relazioni di alto livello il secondo i legami fisici veri e propri tra tabelle.

Figura 4.5 -. Modello fisico del database

Capitolo 4. Realizzazione di un sistema efficace ed efficiente di raccolta dati

64

Il seguente modello ci fornisce una idea più complessa rispetto alla logica con cui è stato progettato il database, delineando quali sono le tabelle previste nell’immagazzinare le informazioni raccolte:

• Evento

• Intervento

• Macchina

• Specifica

• Difetto

• Operatore

La tabella “Macchine” raccoglie tutti i dati relativi alle macchine che rientrano nel lavoro svolto dagli operatori di qualità, all’interno del reparto NextMirs ma anche in altre aree dell’azienda Pirelli. Queste sono state suddivise, oltre che in base al reparto alle quali esse appartengono, rispetto alle “sub-aree” individuate in confezione. L’introduzione di un campo “codice” risulta necessario per la definizione di una chiave primaria della tabella, ma anche successivamente per creare l’associazione con quella contenete gli eventi. La tabella “Difetto” comprende tutte le informazioni relative ai difetti, ripresi direttamente dal manuale della qualità dell’azienda. Oltre alla lista della difettosità, si sono riportate le informazioni comprendenti la codifica già utilizzata in tutti i sistemi e la descrizione del difetto. Inoltre, è stato previsto un campo che catalogasse i difetti in base alla loro tipologia: visivo, uniformità, raggi X e shearografia. La tabella “Operatore” racchiude tutti i dati relativi agli istruttori di qualità e dei team leader, con i codici identificativi per creare il collegamento con gli eventi. La tabella “Specifica” contiene i dati relativi ai diversi modelli di pneumatici prodotti, riportando la codifica utilizzata all’interno dell’azienda; per questo molti dati di questa tabella sono stati importati da altri sistemi in maniera tale da creare il massimo livello di integrazione. La tabella “Intervento”

comprende tutte le azioni in ambito qualità che sono state sottoposte al processo di standardizzazione iniziale. Per queste infatti è stato previsto un codice identificativo che dipende però dalle macro area nelle quali vengono svolte, ma anche descrizione e reparto.

In questa parte si è introdotta una suddivisione binaria che permette di classificare tra attività che sono importanti e devono essere svolte tempestivamente, da quelle che hanno bassi livelli rispetto a queste due proprietà. Questa informazione diventa fondamentale in fase di analisi quando si vuole individuare effetti di particolari interventi che sono stati compiuti in situazioni di criticità.

65

La tabella “Evento” è la tabella principale che comprende tutte le informazioni relative a ciò che avviene nel controllo di qualità, nel reparto NextMirs. L’insieme degli eventi definiti con la logica specifica-difetto-azione-data vengono memorizzati in questo spazio, dal quale partono tutte le relazioni che collegano le rispettive tabelle, costituenti il database. Gli altri dati importanti contenuti rappresentano le macchine, sulle quali possono essere effettuati interventi, il turno di lavoro, lo stato, ovvero se “in corso” o

“chiuso”, e l’esito qualitativo, “positivo” o “negativo”. Altre informazioni supplementari possono essere inserite, come i barcode da monitorare o il campo note per aggiungere altre indicazioni utili.