Database per manutenzioni

di il
36 risposte

Database per manutenzioni

Ciao a tutti,
stavo cercando di risolvere un problema con il mio DB Access, ma, su valido consiglio di Osvaldo, provo a ripresentare qui il mio progetto per cercare di migliorarlo.
Dato l'argomento un po' non alla portata di tutti faccio una breve premessa.
Allora lavoro nel campo delle manutenzioni degli impianti e questo database vorrebbe, per il momento, ottenere due obiettivi principali: raccogliere le informazioni sui componenti da manutenere e tenere traccia delle manutenzioni eseguite e da eseguire (Registro della manutenzione).
Immaginate di essere un elettricista e di avere diversi contratti di manutenzione: ho diversi clienti, diversi immobili/siti su cui intervenire, diversi impianti da manutenere. Dico diversi, perché all'interno degli impianti elettrici ci sono diversi componenti come cabine di media tensione, quadri elettrici, gruppi elettrogeni, illuminazione, prese (detta anche forza motrice) e ogni componente ha necessità e manutenzioni diverse, proprio come la nostra auto, dove il cambio olio si fa ogni tot km, le gomme ogni tot, la cinghia di distribuzione e via dicendo.

Detto questo provo a spiegare il mio progetto.
Nel mio DB le tabelle sono le seguenti:
[Clienti], con NomeCliente come testo e chiave primaria.
[Immobili] con la sua denominazioneImmobili come chiave primaria
[Attività Manutentive] ID come chiave. Qui vengono inserite le manutenzioni che devono essere eseguite e la loro frequenza (mensile, semestrale, annuale, etc..)
Le varie tabelle [CENSIMENTOxxxx] con l'ID come chiave primaria (al momento sono 4, ma devono aumentare, quadri elettrici, forza motrice, illuminazione e illuminazione di emergenza)
La tabella [REGISTROmanutenzione] con il suo ID chiave. Qui vengono inserite le attività eseguite e quelle da eseguire.
Relazioni:
[Clienti]NomeCliente é relazionata (integrità referenziale) con [Immobili] e con tutte le tabelle Censimento e [RegistroManutenzione]
[Immobili]DenomImmobili é relazionata con i Censimenti e [RegistroManutenzione].
I due componenti principali del database sono 2: il componente e la sua attività.
Il componente non può essere identificato in modo univoco con un nome, perché, per esempio, i quadri elettrici si chiamano sempre QGBT (quadro generale di bassa tensione, QEP1, quadro elettrico piano primo, etc). Per questo motivo le tabelle censimenti contengono sempre il Cliente, l'immobile e il campo 'Impianto' che mi definisce la tipologia. Lo stesso dicasi per la tabella [REGISTROManutenzione].
Funzionalità
Nel DB si parte a compilare i dati del cliente e poi i suoi immobili.
Fatto questo si inseriscono i dati nei vari censimenti. Facciamo l'esempio di un quadro elettrico.
Inserisco i dati nella maschera corrispondente alla tabella [CENSIMENTOQuadriBT]; da qui faccio partire una query di accodamento che inserisce i dati nella tabella [REGISTROManutenzione]:
'Cliente' da [CENSIMENTOQuadriBT]
'Immobile' da [CENSIMENTOQuadriBT]
'Impianto' da [CENSIMENTOQuadriBT]
'IDImpianto' [CENSIMENTOQuadriBT]
'Attività manutentiva' da [Attività Manutentive]
'Frequenza' da [Attività Manutentive]
'FrequenzaGG' da [Attività Manutentive] (la frequenza trasformata in numero di giorni)
'Da effettuare il' che viene calcolato sommando i giorni della frequenza alla data di oggi.
Rimane vuoto il campo 'Effettuata il' perché deve essere compilato quando la manutenzione è stata eseguita.

Suggerimenti, idee, miglioramenti??

36 Risposte

  • Re: Database per manutenzioni

    cridema ha scritto:


    [Clienti]NomeCliente é relazionata (integrità referenziale) con [Immobili]
    OK.

    Non capisco perchè usi la parola CENSIMENTO per una tabella.
    Io creerei la relazione Immobili uno-a-molti Impianti.
    Poi prevederei una tabella TipiImpianti uno-a-molti Impianti.
    Non vedo ad es. una tabella Marche. Un Impianto immagino che abbia le seguenti caratteristiche:
    TipoImpianto: Caldaia
    Marca: Argo
    Modello: A-110
    ...altro che non saprei...

    Poi direi una relazione Impianti uno-a-molti Componenti......bisogna fare attenzione però...magari può bastare una tabella più generalizzante con un campo che specifica se si tratta di un Impianto o di un Componente...questo particolare occorre vederlo con cura.

    Il fatto che tu hai bisogno di tenere sotto controllo tutte le scadenze di manutenzione è giusto e sacrosanto...ma temo che vada gestito diversamente...non riesco a dirti molto di più per ora.
    Analizziamo queste piccole cose al momento.

    Sappi che hai fatto una richiesta non da poco per il forum.......OK...proviamo ad andare avanti ugualmente.
  • Re: Database per manutenzioni

    Forse CENSIMENTO non è il massimo, ma quando l'ho creato mi è venuto in mente solo quello...
    Credo che le relazioni che mi suggerisci ci siano già:

    upload
  • Re: Database per manutenzioni

    Hai fatto bene a visualizzare la finestra Relazioni, così abbiamo una idea completa di tutto.

    1. Problema: Vedo che ogni tabella ha il campo ID. Lo eleggi quale chiave primaria, ma non lo usi come tale.
    Rimedio: Nomina tutti i campo ID in maniera propria, ossia IDCliente, IDImmobile...
    Nelle tabelle figlie devi avere ominimi campi IDCliente, IDImmobile (tipo Numerico, Intero Lungo) con la relazione conseguente. Quando imposti la relazione metti sempre la spunta su "Applica integrità referenziale", gli altri 2 sono facoltativi, ma io preferisco mettere la spunta ugualmente (Aggiorna a catena, Elimina...)

    2. Per me non è felice la denominazione CENSIMENTO. Immobili va benissimo. Impianti pure.
    Tutte quelle tabelle che iniziano per CENSIMENTO e hanno campi nominati uguali o simili DEVONO diventare una tabella sola. Un campo aggiuntivo di discriminazione deve stabilire se A è un Impianto, Componente elettrico, Componente gas...

    3. Regione-Provincia-Comune non vale la pena scriverli sempre ogni volta. Prevedi una tabella Comuni (ne esiste una già preconfezionata con tutti i Comuni d'Italia) con i seguenti campi:
    IDComune
    Comune
    CAP
    Provincia
    Regione
    Nella tabella Immobili prevedi un solo campo IDComune e la relazione Comuni.IDComune uno-a-molti con Immobili.IDcomune.

    Mi fermo qui per ora.
  • Re: Database per manutenzioni

    1. Direi che è un ottimo suggerimento! Sistemo tutti gli ID ed elimino quelli che non servono. L'integrità referenziale esiste già completa degli altri 2 flag.
    2. Su questa ci ragiono, ma credo che non sia possibile. Di un quadro elettrico ho bisogno di sapere alcune cose, tipo la taglia dell'interruttore generale, che linee alimenta e altre cose. Di un impianto di illuminazione mi serve sapere marca, tipo, modello e quanti ne sono presenti. Per questo motivo quando l'ho creato le ho tenute separate..
    2bis. L'idea della tabella marche e modelli sarebbe interessante, ma crearla sarebbe infinitamente lunga. Si potrebbe fare una tabella che man mano che registro una marca e un modello si aggiorna?
    3. Non ha relazioni per cui non si vede, ma esiste già ed è utilizzata dalle maschere quindi Provincie e Comuni vengono scelti da un elenco che si filtra man mano (Regione, provincia, Comune, CAP). Sarebbe bello trovare un DB completo dei CAP, comprensivo delle vie (Milano p.e. ha 20100, ma anche molti altri...). Non posso relazionare Comune del Cliente con il Comune dell'Immobile. Nella tabella Clienti viene registrata la sede legale del Cliente, ma un Cliente può avere diversi immobili. Immagina, per esempio, un amministratore di Condomini, sarà il mio Cliente, ma avrà diversi Immobili.
  • Re: Database per manutenzioni

    1. OK.

    cridema ha scritto:


    2. Su questa ci ragiono, ma credo che non sia possibile. Di un quadro elettrico ho bisogno di sapere alcune cose, tipo la taglia dell'interruttore generale, che linee alimenta e altre cose. Di un impianto di illuminazione mi serve sapere marca, tipo, modello e quanti ne sono presenti. Per questo motivo quando l'ho creato le ho tenute separate..
    Per capire bene anche io questo punto, avrei bisogno di 2-3 esempi di Impianti e per ogni Impianto tutti i Componenti. Considera che, anche quando 2 compilazioni di campi non sembrassero "omogenei", talvolta bisogna saperla cogliere tale omogeneità. Ricordo di un database passato Rubrica in cui l'utente lamentava il fatto che avrebbe voluto separare i ContattiAmici, da ContattiLavoro in quanto per i primi lui andava a compilare più certi campi, viceversa certi altri ancora per i secondi. Io gli dissi che non era un problema se determinati campi rimanevano vuoti perchè insignificanti per il singolo record da inserire. Ma, ripeto, vorrei capirne di più sul tuo campo applicativo cosa intendi ecc...

    cridema ha scritto:


    2bis. L'idea della tabella marche e modelli sarebbe interessante, ma crearla sarebbe infinitamente lunga. Si potrebbe fare una tabella che man mano che registro una marca e un modello si aggiorna?
    Certamente puoi pensare l'input di questi valori in questo ordine di idee. Tale problema si risolve agevolmente con le maschere e qualche macro o codice VBA che gestisce l'apertura momentanea di una maschera di livello superiore, per poi aggiornare il nuovo valore.

    cridema ha scritto:


    3. Non ha relazioni per cui non si vede, ma esiste già ed è utilizzata dalle maschere quindi Provincie e Comuni vengono scelti da un elenco che si filtra man mano (Regione, provincia, Comune, CAP).
    Mi sembra strano che non hai relazioni Regioni--->Province--->Comuni...vabbè che sei riuscito ugualmente a gestirlo in maniera funzionante, ma la relazione quando c'è va messa.

    cridema ha scritto:


    Sarebbe bello trovare un DB completo dei CAP, comprensivo delle vie (Milano p.e. ha 20100, ma anche molti altri...).
    La mia risposta è NI. In linea teorica hai ragione, ma sono dell'avviso che una via viene scritta spesso e volentieri in tanti modi diversi:
    Via Filippo Turati, 25
    Via F. Turati 25
    Via Turati n. 25
    V. F. Turati 25
    Via Turati Filippo
    Turati Filippo, Via, 25 (per tentare di trovare un minimo di indicizzazione in questo campo)
    ...fai come meglio credi, io ho sempre avuto problemi in proposito.
    Piuttosto, il database che ricordo io non contempla i CAP multipli per i grandi Comuni. Tale tabella va comunque concepita in maniera dinamica, cioè aggiornabile all'occasione.

    cridema ha scritto:


    Non posso relazionare Comune del Cliente con il Comune dell'Immobile. Nella tabella Clienti viene registrata la sede legale del Cliente, ma un Cliente può avere diversi immobili. Immagina, per esempio, un amministratore di Condomini, sarà il mio Cliente, ma avrà diversi Immobili.
    Nessuno ti vieta di relazionare 2 volte Comuni.IDComune uno-a-molti Clienti.IDcomune e Comuni.IDComune uno-a-molti Immobili.IDComune.
    Anche se, mi sembrerebbe alquanto strano che un Cliente Amministratore che amministra molti Immobili, non usi anche il proprio Domicilio per farsi servire da te. Un campo specifico può determinare se ImmobileX è o no il Domicilio.
  • Re: Database per manutenzioni

    A quanto pare le manutenzioni stanno diventando di moda...
    La mia risposta è NI. In linea teorica hai ragione, ma sono dell'avviso che una via viene scritta spesso e volentieri in tanti modi diversi:
    Via Filippo Turati, 25
    Via F. Turati 25
    Via Turati n. 25
    V. F. Turati 25
    Via Turati Filippo
    Turati Filippo, Via, 25 (per tentare di trovare un minimo di indicizzazione in questo campo)
    ...fai come meglio credi, io ho sempre avuto problemi in proposito.
    Piuttosto, il database che ricordo io non contempla i CAP multipli per i grandi Comuni. Tale tabella va comunque concepita in maniera dinamica, cioè aggiornabile all'occasione.
    E' veramente un macello, anche perché bisognerebbe arrivare al numero civico: mi è capitato di vedere vie di Roma che hanno un CAP fino ad un certo civico e un altro per i seguenti civici. Sarebbe interessante vedere come gestisce la questione il sito delle poste... Io mi limito a lasciare modificabile il campo CAP. La mia tabella è semplice con i 4 campi Regione, provincia, comune e CAP. Nella maschera di inserimento, man mano che scendo di livello filtro con un where. Giusto per capire meglio, che vantaggi mi da relazionare i campi Regione, Provincia e Comune con i campi delle 2 tabelle Clienti e Immobili?
    Anche se, mi sembrerebbe alquanto strano che un Cliente Amministratore che amministra molti Immobili, non usi anche il proprio Domicilio per farsi servire da te. Un campo specifico può determinare se ImmobileX è o no il Domicilio.
    Ti assicuro che nel campo immobiliare ho visto di tutto, può anche succedere di avere 2 clienti diversi nello stesso immobile, per esempio.
    Certamente puoi pensare l'input di questi valori in questo ordine di idee. Tale problema si risolve agevolmente con le maschere e qualche macro o codice VBA che gestisce l'apertura momentanea di una maschera di livello superiore, per poi aggiornare il nuovo valore.
    Ci ragionerò, non so se mi è veramente utile, ma l'idea è interessante.
    Per capire bene anche io questo punto, avrei bisogno di 2-3 esempi di Impianti e per ogni Impianto tutti i Componenti. Considera che, anche quando 2 compilazioni di campi non sembrassero "omogenei", talvolta bisogna saperla cogliere tale omogeneità. Ricordo di un database passato Rubrica in cui l'utente lamentava il fatto che avrebbe voluto separare i ContattiAmici, da ContattiLavoro in quanto per i primi lui andava a compilare più certi campi, viceversa certi altri ancora per i secondi. Io gli dissi che non era un problema se determinati campi rimanevano vuoti perchè insignificanti per il singolo record da inserire. Ma, ripeto, vorrei capirne di più sul tuo campo applicativo cosa intendi ecc...
    Torniamo al nocciolo della questione. Eccoti un esempio:

    free image hosting
    Ed eccone un altro:

    host image
    Per entrambi lascia pure stare l'ultimo campo calcolato che era una prova che stavo facendo.
    Considerando che la tabella REGISTROManutenzione sarà bella grossa (ogni record dovrà contenere anche un allegato..) ho ragionato oggi che mi restano 3 possibilità:
    1. Lascio come ora, cioè una tabella CENSIMENTO per ogni impianto e una sola REGISTRO. In questo caso non riesco a mettere in relazione i vari ID dei CENSIMENTOxxx perché la query di accodamento mi dà errore (non so perché), però riesco a fare i report.
    2. Potrei provare a fare un'unica tabella CENSIMENTO creando campi generici che non sarebbero sempre pieni in ogni record. Non avrei problemi a fare le maschere, ma non sono sicuro di potere ottenere dei report ben organizzati.
    3. Potrei fare N tabelle CENSIMENTO e altrettante tabelle REGISTRO. Anche in questo caso non sono sicuro di riuscire a creare dei report corretti.

    Il report principale che mi serve è quello delle scadenze. In pratica, allo stato attuale, creo un report ordinando le date del campo [REGISTROManutenzione]'da effettuare il' in modo da vedere quale è la scadenza più vicina. Ovviamente il tutto poi è ordinato per gli altri campi.

    Quale la struttura migliore?
  • Re: Database per manutenzioni

    cridema ha scritto:


    La mia tabella è semplice con i 4 campi Regione, provincia, comune e CAP. Nella maschera di inserimento, man mano che scendo di livello filtro con un where. Giusto per capire meglio, che vantaggi mi da relazionare i campi Regione, Provincia e Comune con i campi delle 2 tabelle Clienti e Immobili?
    Se tu conosci subito il nome del Comune, a cosa ti serve fare tutto il giochetto delle filtrazioni? La tabella Immobili deve avere UN SOLO campo IDComune. Una casella combinata (quella che i profani chiamano menu a tendina) "ben congeniata" mostrerà il testo del Comune di cui tu digiterai solo i primi caratteri, il resto lo scegli e vai direttamente.
    La relazione serve a dare forza a tutto questo meccanismo che Access prevede in maniera relativamente agevole. L'aver messo in moto WHERE apposite, significa aver scomodato codici o espressioni superflue.
    Se, a fini estetici/istituzionali (es. report), ti serve mostrare Regione e Provincia, sfrutti una query che riprende questi campi a monte della tabella Comuni.

    OsvaldoLaviosa ha scritto:


    Certamente puoi pensare l'input di questi valori in questo ordine di idee. Tale problema si risolve agevolmente con le maschere e qualche macro o codice VBA che gestisce l'apertura momentanea di una maschera di livello superiore, per poi aggiornare il nuovo valore.

    cridema ha scritto:


    Ci ragionerò, non so se mi è veramente utile, ma l'idea è interessante.
    Quando un database è vuoto o "acerbo" (cioè con pochi dati) si possono prospettare 2 strategie di input dati in tabella madre. Se se ne conoscono già tanti sicuri, può essere utile inserirli a fiume direttamente in essa. Però se tu lavori principalmente su una maschera di livello inferiore, parallelamente ti torna molto utile questo mio suggerimento...ma si tratta di una cosa da fare più in là...non ha nulla a che vedere con la progettazione in senso stretto.

    Quelle immagini mi aiutano poco. In verità vorrei che tu mi descrivessi ad es. che:
    - nell'Immobile del Cliente Rossi Mario sito in Roma, Via Nazionale 12, vi sono 2 Impianti con le SEGUENTI CARATTERISTICHE...
    - nell'Immobile del Cliente Cassano Antonio sito in Bari, Piazza Chiurlia 10, vi è un Impianto con le seguenti caratteristiche...
    Vorrei che tu dessi un NOME a ogni Impianto.
    Per ogni Impianto descrivi tutti i Componenti
    Poi descrivi cosa succede (a livello di manutenzione) a questi tre impianti dalla loro DataInstallazione in poi...
  • Re: Database per manutenzioni

    Se tu conosci subito il nome del Comune, a cosa ti serve fare tutto il giochetto delle filtrazioni? La tabella Immobili deve avere UN SOLO campo IDComune. Una casella combinata (quella che i profani chiamano menu a tendina) "ben congeniata" mostrerà il testo del Comune di cui tu digiterai solo i primi caratteri, il resto lo scegli e vai direttamente.
    La relazione serve a dare forza a tutto questo meccanismo che Access prevede in maniera relativamente agevole. L'aver messo in moto WHERE apposite, significa aver scomodato codici o espressioni superflue.
    Se, a fini estetici/istituzionali (es. report), ti serve mostrare Regione e Provincia, sfrutti una query che riprende questi campi a monte della tabella Comuni
    Mi hai convinto.
    Funziona anche con le LIST box, vero? Se non ho letto male i manuali la differenza tra LIST e COMBO è che la seconda permette anche un dato non in lista, giusto?
    Quelle immagini mi aiutano poco. In verità vorrei che tu mi descrivessi ad es. che:
    - nell'Immobile del Cliente Rossi Mario sito in Roma, Via Nazionale 12, vi sono 2 Impianti con le SEGUENTI CARATTERISTICHE...
    - nell'Immobile del Cliente Cassano Antonio sito in Bari, Piazza Chiurlia 10, vi è un Impianto con le seguenti caratteristiche...
    Vorrei che tu dessi un NOME a ogni Impianto.
    Per ogni Impianto descrivi tutti i Componenti
    Poi descrivi cosa succede (a livello di manutenzione) a questi tre impianti dalla loro DataInstallazione in poi...
    Allora, vediamo..
    Nell'Immobile del Cliente Cassano Antonio sito in Bari, Piazza Chiurlia 10 abbiamo i seguenti Impianti elettrici:
    - QGBT (Quadro generale di bassa tensione) è il quadro che alimenta tutto il palazzo.
    - QEP1 (Quadro elettrico piano 1) è il quadro che, alimentato dal QGBT, alimenta le utenze (p.e. Illuminazione e prese) del piano primo.
    - QEP2 (Quadro elettrico piano 2) è il quadro che, alimentato dal QGBT, alimenta le utenze del piano secondo.
    - Illuminazione piano 1: sono gli apparecchi illuminanti (lampadine, plafoniere, lampade al neon, etc..) che fanno luce al piano 1.
    Illuminazione piano 2: come sopra.
    - Illuminazione di emergenza piano 1: sono le lampade di emergenza del piano 1, cioè quelle che si accendono/rimangono accese in caso di black out.

    Per identificare un quadro elettrico inserisco questi dati:
    - il Cliente di riferimento 'Cassano Antonio'
    - l'immobile di ubicazione 'Bari Chiurla 10'
    - il nome del quadro 'QGBT' o uno degli altri
    - l'ubicazione del quadro 'piano terra' per esempio: serve ai tecnici che intervengono a trovarlo più facilmente
    - Marca 'ABB'
    - Portata interruttore generale '160' (misura di grandezza A)
    - Misure HxLxP (espresse in mm) '4000x1000x800'
    - data di installazione
    - data ultima revisione (queste due date mi definiscono che i documenti del quadro sono a norma oppure no)
    - pulsante di sgancio sì/no (la presenza di un pulsante di sgancio lontano dal quadro mi definisce che, nei controlli da eseguire, devo verificare anche il funzionamento del pulsante)
    - foto fronte quadro: mi da un'idea immediata della generalità del quadro (è un campo allegato)
    - Note: è campo libero che serve per segnalare eventuali problemi, etc...

    Per identificare l'illuminazione indico:
    - il Cliente di riferimento 'Cassano Antonio'
    - l'immobile di ubicazione 'Bari Chiurla 10'
    - l'ubicazione dell'impianto: 'piano 1'
    - tipologia di illuminazione (alogene, neon, incandescenza, led, etc..)
    - n° di elementi (la manutenzione da fare a degli apparecchi illuminanti è uguale per tutti. Non è necessario identificarli uno per uno ma è sufficiente aggregarli)

    Per identificare l'illuminazione di emergenza indico:
    - il Cliente di riferimento 'Cassano Antonio'
    - l'immobile di ubicazione 'Bari Chiurla 10'
    - l'ubicazione dell'impianto: 'piano 1'
    - tipologia di illuminazione (alogene, neon, incandescenza, led, etc..)
    - n° di elementi (come per l'illuminazione)
    - se hanno la batteria a bordo oppure no 'sì/no'
    - se sono sempre accese o solo emergenza

    Molti di questi dati aiutano parecchio a identificare i guasti oltre che il tempo necessario alla manutenzione preventiva.
    Dalla buona norma tecnica nonché dalla normativa UNI, ogni impianto (ogni quadro elettrico, illuminazione o illuminazione di emergenza) ha le sue manutenzioni preventive periodiche.
    Per questo motivo la tabella [attività manutentive] me le descrive una per una, definendole per impianto e per frequenza.
    A questo punto quando ho finito di compilare la maschera CENSIMENTO con i vari dati di cui sopra, attivo la query di accodamento che crea nel [REGISTROManutenzione] le attività manutentive che devono essere eseguite per ogni impianto. Ad ogni attività viene data una scadenza. Faccio un esempio pratico semplificato.
    Per il QGBT del nostro amico Cassano ci sono un totale di 3 attività: una mensile, una quadrimestrale, una annuale.
    La query mi crea 3 record con data di scadenza pari alla data odierna (la data in cui attivo la query) sommata dei giorni residui alla scadenza (30, 120, 365). Come data di riferimento prendo la data di attivazione della query perché la considero come la data di attivazione del contratto tra me e il cliente.
    A questo punto grazie ad un report posso vedere quelle che sono le mie scadenze e organizzare i giri delle squadre di manutenzione.
    A manutenzione effettuata, registro la data di esecuzione, allego il rapportino di intervento e attivo un query che mi genera la prossima manutenzione basata su quella appena eseguita. E così via fino a quando non scade il contratto...
  • Re: Database per manutenzioni

    cridema ha scritto:


    Funziona anche con le LIST box, vero? Se non ho letto male i manuali la differenza tra LIST e COMBO è che la seconda permette anche un dato non in lista, giusto?
    Non è questa la differenza fra i due...non importa approfondire. La ListBox, onestamente non la uso mai e ha opzioni più complesse che non saprei spiegarti. Le ComboBox sono più usate, facili e opportune per il tuo caso.

    Potresti dirmi tutti i Componenti di QEP1 e "Illuminazione emergenza piano 1"?
    Quali manutenzioni periodiche sono previste?
  • Re: Database per manutenzioni

    Non è questa la differenza fra i due...non importa approfondire. La ListBox, onestamente non la uso mai e ha opzioni più complesse che non saprei spiegarti. Le ComboBox sono più usate, facili e opportune per il tuo caso.
    Ok, ero più che altro curioso di capire la differenza tra le 2, ma ho sempre usato le combo.
    Potresti dirmi tutti i Componenti di QEP1 e "Illuminazione emergenza piano 1"?
    Quali manutenzioni periodiche sono previste?
    Va beh, se vuoi una lezione sulle manutenzioni puoi chiedere!
    Scherzi a parte:
    QEP1 (nello scorso elenco mi ero dimenticato di incarti gli ID.. )
    - IDQuadriBT: '2'
    - Cliente 'Cassano Antonio'
    - immobile 'Bari Chiurla 10'
    - nome quadro 'QEP1'
    - ubicazione quadro 'piano primo'
    - Marca 'Schneider'
    - Portata interruttore generale '64'
    - Misure HxLxP (espresse in mm) '2000x2000x800'
    - data di installazione
    - data ultima revisione
    - pulsante di sgancio 'sì'
    - foto fronte quadro: allegato

    Illuminazione emergenze piano 1
    - IDILLem: '2'
    - Cliente 'Cassano Antonio'
    - immobile 'Bari Chiurla 10'
    - l'ubicazione dell'impianto: 'piano 1'
    - tipologia di illuminazione 'neon'
    - n° di elementi '16'
    - batteria a bordo 'sì'
    - SE o SA : 'Solo Emergenza'

    MANUTENZIONI (te ne indico qualcuna solo di esempio)
    - IDMan: '1'
    - CATEGORIA IMPIANTI: 'Impianti elettrici'
    - IMPIANTO: 'Quadri BT'
    - TIPO DI ATTIVITà: 'Controllo visivo'
    - ATTIVITà: 'Verifica del corretto funzionamento degli strumenti indicatori'
    - FREQUENZA: 'Mensile'

    - IDMan: '2'
    - CATEGORIA IMPIANTI: 'Impianti elettrici'
    - IMPIANTO: 'Quadri BT'
    - TIPO DI ATTIVITà: 'Prove strumentali'
    - ATTIVITà: 'Ispezione termografica per mezzo di telecamera a infrarossi'
    - FREQUENZA: 'Annuale'

    - IDMan: '3'
    - CATEGORIA IMPIANTI: 'Impianti elettrici'
    - IMPIANTO: 'Quadri BT'
    - TIPO DI ATTIVITà: 'Mantenimento'
    - ATTIVITà: 'Pulizia delle parti esterne, delle griglie di aspirazione e di espulsione e verifica del corretto funzionamento di eventuali apparati di ventilazione forzata'
    - FREQUENZA: 'Semestrale'

    - IDMan: '47'
    - CATEGORIA IMPIANTI: 'Impianti elettrici'
    - IMPIANTO: 'Illuminazione di emergenza'
    - TIPO DI ATTIVITà: 'Mantenimento'
    - ATTIVITà: 'Pulizia degli schermi e dei corpi dei corpi illuminanti interni ed esterni.'
    - FREQUENZA: 'Semestrale'

    - IDMan: '49'
    - CATEGORIA IMPIANTI: 'Impianti elettrici'
    - IMPIANTO: 'Illuminazione di emergenza'
    - TIPO DI ATTIVITà: 'Controllo visivo'
    - ATTIVITà: 'Verifica degli ancoraggi dei corpi illuminanti a soffitto/parete'
    - FREQUENZA: 'Quadrimestrale'

    Credo di avere risposto alle tue domande.
  • Re: Database per manutenzioni

    Buona descrizione. Forse sono a un passo dalla struttura generale del database, ma non mi torna ancora qualcosa. Perchè è stata nominata la parola COMPONENTI? Io pensavo che ogni Impianto avesse molti Componenti e che tu AGISSI (manutenzione) su ognuno di essi. Invece vedo che una SINGOLA MANUTENZIONE viene fatta direttamente sull'Impianto (certo con tutti quei campi di specificazione/descrizione). Puoi chiarirmi dove non colgo ancora?
  • Re: Database per manutenzioni

    Buona descrizione. Forse sono a un passo dalla struttura generale del database, ma non mi torna ancora qualcosa. Perchè è stata nominata la parola COMPONENTI? Io pensavo che ogni Impianto avesse molti Componenti e che tu AGISSI (manutenzione) su ognuno di essi. Invece vedo che una SINGOLA MANUTENZIONE viene fatta direttamente sull'Impianto (certo con tutti quei campi di specificazione/descrizione). Puoi chiarirmi dove non colgo ancora?
    Certo!
    Allora, le manutenzioni di cui stiamo parlando sono quelle preventive, vale a dire che vengono eseguite per evitare che si verifichi un guasto, oppure per rivelare un guasto prima che l'impianto si fermi.
    Di conseguenza le manutenzioni vengono eseguite sui singoli impianti. Non è necessario, definire ogni singolo componente dell'impianto, anche perché stiamo trattando impianti non industriali. Quel genere di dettaglio è utile per macchinari complessi e industriali che credo sia il caso della discussione di ruud.crews.
    A livello di CENSIMENTO, la definizione dei Componenti (intese come parti costituenti l'impianto) serve a questo:
    - Quando intervengo su un guasto, so che attrezzatura e che pezzi di ricambio ho bisogno.
    - Allo stesso modo, in base al problema posso decidere di mandare una squadra piuttosto che un'altra
    - Sulla base dei Componenti posso determinare (lo svilupperò successivamente) quanto tempo è necessario per eseguire la manutenzione (esempio semplice: intervenire su 100 plafoniere è diverso che intervenire su 20) e quindi si può organizzare le giornate delle squadre
    - Anche questo verrà sviluppato successivamente, ma si potrebbe determinare i costi/ricavi di una commessa
    - Ultimo ma non meno importante, al mio cliente devo consegnare un REGISTRO della manutenzione ed è corretto che nei documenti sia presente una descrizione dell'Impianto.
  • Re: Database per manutenzioni

    Ma allora vorresti anche contabilizzare i movimenti di Dipendenti con relative mansioni ecc... I Componenti giocherebbero un ruolo importante da questo punto di vista e....
    Ma questo non appare in alcuna tabella della tua prima finestra Relazioni.
    Il discorso anzichè chiudersi, tende ad allargarsi: Aiuto!!!

    Io nel frattempo avevo elaborato questo (vedi immagine):

    Considera che:
    1. tutte le tabelle con un solo campo sono da ritenersi "satelliti" e di minore importanza
    2. le tabelle che ti servono veramente sono Clienti, Immobili, Impianti, UbicazioniImpianti, Operazioni
    3. Operazioni è un termine più generico di Manutenzioni. Significa tutta una serie di operazioni che vengono svolte intorno al ImpiantoUbicato. Voglio dire che anche la stessa Installazione iniziale è una operazione con tanto di Data che fa partire il tempo per le successive Manutenzioni.
    4. Al momento le Operazioni possono essere descritte solo genericamente
    5. Il campo Domicilio è di tipo Sì/No per quel discorso che dicevo in un post precedente
    6. I campi Portata e Misure sono messi un po' lì...non prenderli troppo sul serio...

    Volevo mettere una prima pietra miliare al discorso che potrebbe allargarsi in maniera esponenziale. Fatto sta che credo di aver NORMALIZZATO gli indizi fin qui forniti. L'ultimo tuo post...va ancora molto oltre...
    Allegati:
    10250_c6fb22c9a1162e462c074e642f071aa1.jpg
    10250_c6fb22c9a1162e462c074e642f071aa1.jpg
  • Re: Database per manutenzioni

    Ma allora vorresti anche contabilizzare i movimenti di Dipendenti con relative mansioni ecc... I Componenti giocherebbero un ruolo importante da questo punto di vista e....
    Ma questo non appare in alcuna tabella della tua prima finestra Relazioni.
    Il discorso anzichè chiudersi, tende ad allargarsi: Aiuto!!!
    Per il momento puoi stare tranquillo, prima di arrivare allo sviluppo dei costi/ricavi devo rendere questo perfettamente funzionante, comprensivo di report, quindi di tempo ne passerà.

    Oltre a ringraziarti per lo sbattimento, ti faccio i miei complimenti, quella architettura è molto pulita! Mi piace un sacco.
    Devo, però, chiederti alcune spiegazioni:
    1. Non ho capito la tabella contatti. Immagino che tipicontatti abbia dentro tipo Clienti/Fornitori, ma [Contatti] sfugge alla mia comprensione.
    2. Mi pare di capire che la tabella impianti sia unica: se faccio un report complessivo riesco a filtrare gli eventuali campi vuoti?

    Per gestire questa cosa, mi viene un'idea mentre scrivo: se mantengo una tabella unica da far lavorare con le altre tabelle principali e creo N sottobelle collegate per la sola registrazione dei componenti di cui abbiamo parlato?

    Ancora grazie mille!
Devi accedere o registrarti per scrivere nel forum
36 risposte