Issuu on Google+

A.S. 2012-2013 IIS BLAISE PASCAL di Reggio Emilia PROGETTO DI INFORMATICA - GESTIONE TICKET ANALISI DESCRITTIVA L’obiettivo primario del nostro progetto è quello di gestire le chiamate (ticket) ricevute da un’azienda di assistenza informatica e le relative informazioni per la loro gestione. Le chiamate stesse saranno quindi l’elemento fondamentale del nostro progetto: per ogni chiamata, la quale si tradurrà sempre in un intervento (che può essere efficace e risolvere il problema o meno), le informazioni più importanti sono l’azienda presso la quale viene effettuata la richiesta di assistenza e chi la esegue, ovvero il tecnico che esce ad effettuare fisicamente l’intervento. Altre informazioni di rilevanza sono lo stato del ticket e la sua durata per riuscire ad ottenere statistiche precise sull’efficienza dei tecnici e dell’azienda in generale: la qualità dell’intervento tramite una valutazione, il tempo impiegato dai singoli dipendenti nell’eseguire l’intervento e se ci riescono o meno, oppure le distanze percorse dagli stessi per arrivare nei luoghi d’assistenza e mappare così le aziende-clienti sul territorio. Si vuole quindi creare un resoconto dell’assistenza svolta finora per eventuali miglioramenti futuri o premi ai tecnici più efficienti. Poichè nell’azienda c’è un tecnico responsabile per ogni settore d’assistenza (hardware, reti, audio ecc.), ognuno di essi deve poter controllare in ogni momento lo stato degli interventi attuale e poter modificare in tempo reale l’intervento da lui eseguito (per esempio, non appena completa un intervento, aggiornare subito il suo stato in “completato”). Stessa cosa vale per chi dovrà inserire le richieste di assistenza dei clienti (i centralinisti/segretari) e aggiornare l’elenco degli stessi. Ogni dipendente dovrà quindi disporre di un account personale dal quale accedere al proprio pannello di gestione. Per rendere accessibili, modificabili e gestibili tutti questi dati a più persone con ruoli diversi e contemporaneamente, occorre memorizzarli in un DataBase e fornire ad ognuno un’interfaccia semplice e funzionale dalla quale poter compiere le operazioni richieste. Per rendere tutto più accessibile e flessibile, la soluzione più semplice e versatile è una web application dalla quale ognuno dei dipendenti dell’azienda possa compiere queste operazioni dopo essersi loggato. Gli unici requisiti sono quindi un browser e una connessione ad internet, in modo da non essere vincolati nell’utilizzo della piattaforma da particolari tipologie di computer o software.


IPOTESI AGGIUNTIVE  Ogni settore ha uno e un solo tecnico, ma un tecnico può appartenere a settori

diversi.  Una chiamata si trasforma sempre in un intervento...se il problema è così banale

da essere risolto al telefono dall’operatore o per qualche motivo la chiamata non si traduce in un intervento effettivo da parte di un tecnico, essa non dovrà nemmeno essere inserita nel DB: in pratica, non gestiamo la totalità delle chiamate ma solo quelle che hanno un riscontro in termini di interventi dei tecnici.  Ad ogni azienda corrisponde una sola sede di intervento...non prendiamo in

considerazione il caso in cui l’intervento possa essere svolto in una “succursale” diversa dalla sede principale.

DESCRIZIONE ENTITÀ E RELATIVI ATTRIBUTI TICKET: è l’entità attorno a cui ruota la struttura del DataBase: ad ogni richiesta di assistenza ricevuta dalla nostra azienda ne viene creata una nuova istanza, nella quale si memorizzano l’identificativo (chiave primaria), la data di apertura, la data di chiusura (sarà NULL nel caso di ticket aperti o non riusciti), il settore dell’intervento, il tecnico che andrà ad eseguire l’intervento, lo stato (Open / Closed / Failed), il preventivo, il prezzo effettivamente pagato dal cliente, l’azienda presso la quale si effettua l’intervento, la valutazione da parte della stessa sulla qualità dell’intervento e la descrizione. Poiché tutti gli interventi dello stesso settore vengono eseguiti dallo stesso tecnico, per evitare ridondanza dei dati sarà opportuno avere l’entità dei settori e quella dei tecnici, in modo che ogni intervento sia associato al settore a cui appartiene tramite chiave esterna, e quindi al tecnico di riferimento. TECNICI: Per ogni tecnico memorizziamo i dati anagrafici: codice fiscale (che sarà anche chiave primaria in quanto univoco), nome, cognome, indirizzo di residenza e luogo e data di nascita. Ad ogni tecnico è poi associato uno e un solo account per accedere al sistema interno di gestione dei ticket: per questo tra gli attributi da memorizzare per ogni tecnico abbiamo bisogno di un username (che sarà anch’esso chiave e indice univoco) e della relativa password.

SETTORI: Ad ogni intervento corrisponde un settore ⇒ ogni intervento avrà quindi una chiave esterna che rimanda all’id del settore corrispondente. Ogni settore avrà quindi come attributi l’ID (chiave primaria), il nome e la descrizione.


AZIENDE: Ogni intervento è associato all’azienda presso la quale viene effettuato, di cui vogliamo memorizzare il numero di partita IVA (che è chiave primaria in quanto univoco), nome, numero di telefono, indirizzo, indirizzo e-mail (anch’esso chiave e indice univoco) e ragione sociale. Per poter gestire efficacemente tutte le informazioni relative ai luoghi geografici (indirizzi dei tecnici e delle aziende) utilizziamo le seguenti entità: CITTÀ, di cui memorizziamo l’ID (chiave primaria), il nome e la provincia. Per città intendiamo i Comuni, in modo da non lasciare scoperte fette di territorio; PROVINCE, di cui memorizziamo l’ID (chiave primaria), il nome e la regione. Questa entità si rende utile come entità indipendente in quanto non è improbabile incombere in un cambio dell’ordinamento delle province italiane; REGIONI, di cui memorizziamo l’ID (chiave primaria) e il nome.

DESCRIZIONE RELAZIONI E RELATIVI ATTRIBUTI RICHIEDE: Collega ogni singolo ticket all’azienda che l’ha richiesto. Siccome un’azienda può aver richiesto più ticket ma un ticket può essere richiesto da una e una sola azienda, essa sarà una relazione 1:N. Cardinalità: Ticket (0, ∞) ⇔(1,1) Aziende HA SEDE A: Collega ogni azienda alla città in cui ha la sede in una relazione 1:N, poiché in ogni città posso trovarsi più aziende, ma un’azienda non può avere sede in due città diverse. Cardinalità: Aziende(0,∞) ⇔(1,1) Città RESIDENZA: Collega un tecnico alla città in cui risiede in una relazione 1:N, poichè un tecnico può avere la residenza solo in una città ma una città può essere la residenza di vari tecnici. Questa relazione si rende utile nel completamento dell’indirizzo di casa del tecnico. Cardinalità: Tecnico (0,∞) ⇔(1,1) Città NASCITA: Come la precedente, ma indica il luogo di nascita del tecnico. Cardinalità: Tecnico (0,∞) ⇔(1,1) Città IN PROVINCIA DI: Collega ogni città alla provincia di appartenenza in una collegamento 1:N, poiché una provincia contiene varie città ma una città non può essere in due province diverse. Cardinalità: Province (1,1) ⇔(1,∞) Città


SI TROVA IN: Come la precedente, ma collega le province alle regioni. Cardinalità: Regioni (1,1) ⇔(1,∞) Province È AFFIDATO A: Collega ogni settore al tecnico di riferimento in una relazione 1:N ⇒ ogni settore ha il suo tecnico di riferimento, ma un singolo tecnico può essere il responsabile di più settori. Cardinalità: Settori (1,∞) ⇔(1,1) Tecnici APPARTIENE A: Collega ogni ticket al settore di appartenenza in una relazione 1:N ⇒ ogni ticket può appartenere solo ad un settore, ma ad un settore vengono associati più ticket. Cardinalità: Settori (1,1) ⇔(0,∞) Ticket

RAFFINAMENTI E AGGIUNTE Gli interventi saranno suddivisi in settori, che a loro volta saranno suddivisi in tipologie: ogni tecnico, essendo associato a più settori, sarà di conseguenza associato a tutte le tipologie relative ai suoi settori. Un tecnico non potrà quindi essere assegnato ad un intervento di una tipologia diversa da quelle di cui è responsabile. Esempio: il settore “hardware” avrà le tipologie “installazioni”, “riparazioni”, “aggiornamenti driver” ecc...il tecnico dell’hardware non potrà eseguire però una riparazione dell’impianto audio (seppure rientri nelle sue conoscenze) poiché l’intervento rientrerebbe nel settore audio. Aggiungiamo quindi la seguente entità: TIPOLOGIE: di cui memorizziamo l’ID (chiave primaria), il nome e una descrizione facoltativa. Per migliorare ancora le funzionalità dell’applicazione, andando oltre le richieste iniziali del cliente, vogliamo gestire due tipologie di dipendenti: i tecnici e i centralinisti. I tecnici sono coloro che effettuano gli interventi, mentre i centralinisti sono coloro che ricevono le chiamate, e devono avere quindi la possibilità di aggiungere i ticket al DB con le relative informazioni, alla ricevuta di una chiamata. Essi provvederanno quindi ad inserire l’azienda richiedente, la tipologia dell’intervento, la sua descrizione, la data di apertura (che verrà in realtà gestita automaticamente dal sistema), il preventivo (il centralinista dovrà essere in grado di valutare a grandi linee il costo dell’intervento, chiedendo al cliente le informazioni utili a questa valutazione). I tecnici invece dovranno avere solo la possibilità di visualizzare tutti i ticket e di modificare solo quelli relativi al proprio settore d’ appartenenza: saranno i tecnici a provvedere ad operazioni quali la chiusura di un ticket o l’inserimento della valutazione, che si possono eseguire solo ad intervento avviato.


Ogni dipendente avrà un account per accedere alla sua interfaccia ed effettuare le sue operazioni: per ogni account memorizzeremo quindi l’username, la password e il dipendente a cui è associato, di modo che i centralinisti accedano al pannello di inserimento di un ticket e i tecnici al pannello di modifica dei ticket dei loro settori. La differenza tra i due tipi di dipendente consiste solo nella mansione svolta all’interno dell’azienda, ma gli attributi che vogliamo memorizzare sono esattamente gli stessi. Non ci conviene quindi gestire due entità separate per le due mansioni, ma rinominare l’entità “Tecnici” in “Dipendenti” e aggiungere un campo “tipo” per l’identificazione del ruolo ricoperto. Vogliamo inoltre gestire lo storico dei tecnici che hanno lavorato nella nostra azienda ed eventuali cambi nelle relazioni coi vari settori: se un tecnico viene licenziato dovrà comparire comunque nel DB e dobbiamo poter risalire al periodo in cui è stato in attività. Se un tecnico, inoltre, smette di lavorare nel settore “sicurezza” per lavorare nel settore “reti”, dovremo gestire questo cambio di attività inserendo la data di fine lavoro in un determinato settore. Per gestire queste eventualità diventa utile collegare i tecnici ai settori con una relazione N:N...verrà aggiunta quindi la seguente entità. LAVORA (ID_lavora, FK_CF, FK_ID_set, data_inizio, data_fine) che memorizzerà quindi uno storico delle relazioni tra i tecnici che si sono succeduti in azienda nei vari settori: se un tecnico ha solo relazioni con la data di fine impostata vorrà dire che non lavora più in azienda e, di conseguenza, se la data_fine non è settato significherà che il tecnico lavora attualmente nel settore considerato.

VOLUME DELLE ENTITÀ Una stima dei volumi che assumeranno le entità nell’utilizzo del DB:  DIPENDENTI: L’attuale dimensione dell’azienda fa pensare ad un numero di dipendenti nell’ordine di poche decine;  SETTORI: Il numero di settori potrà essere al massimo uguale, se non inferiore, a quello dei tecnici...anch’esso nell’ordine di poche decine;  TIPOLOGIE: Per ogni settore esistono diverse tipologie di intervento, e non sarà difficile, nel corso dell’attività aziendale, incombere man mano in nuove problematiche. Questa sarà quindi un’entità in possibile continua espansione, nell’ordine delle centinaia;  LAVORA IN: Dato l’attuale numero di dipendenti nell’azienda e il loro basso tasso di ricambio, questa entità assumerà un volume nell’ordine delle decine;  AZIENDE: Il numero di aziende servite sarà senz’altro in continua espansione e il numero di chiamate giornaliere fa pensare ad un’entità nell’ordine delle migliaia;  TICKET: Ogni giorno si ricevono in media una trentina di chiamate (ipotesi); Poichè qui dovremo tenere traccia di tutti i ticket valutiamo che questa entità possa avere un volume nell’ordine delle decine di migliaia;


 CITTÀ: La lista dei comuni italiani conta attualmente 8092 elementi ⇒ volume dell’ordine delle migliaia;  PROVINCE: Le province italiane sono attualmente poco più di 100, e difficilmente potranno arrivare a contare poche centinaia;  REGIONI: Volume nell’ordine delle decine (attualmente questa entità conterebbe 20 elementi)

SCHEMA E-R Prima dei raffinamenti


Dopo i raffinamenti

Notiamo che, dopo i raffinamenti, si è aggiunta l’entità TIPOLOGIE tra i TICKET e i SETTORI, l’entità dei tecnici è rinominata in DIPENDENTI (con l’aggiunta dell’attributo “Tipo”) e si collega ai settori con una relazione N:N, la quale dà vita ad una nuova entità: LAVORA_IN.


SCHEMA LOGICO E FISICO LEGENDA: in grassetto tutte le chiavi, sottolineate le chiavi primarie, in azzurro le chiavi esterne. Ogni attributo è seguito dal suo tipo dato ●

Tipologie

Settori

Lavora_in

Ticket

Aziende

Dipendenti

Città

(ID_citta: INT, Nome_citta: VARCHAR, FK_ID_prov: INT);

Province

(ID_prov: INT, Nome_prov: VARCHAR, Sigla: TINYTEXT; FK_ID_reg:

(ID_tip: INT, Nome_tip: VARCHAR, Descrizione_tip: TINYTEXT, FK_ID_set: INT); (ID_set: INT, Nome: VARCHAR, Descrizione_set: TINYTEXT);

(ID_lavora: INT, FK_CF: VARCHAR(16), FK_ID_set: INT, data_inizio: DATE, data_fine: DATE) (ID_ticket: INT, Data_apertura: DATETIME, Data_chiusura: DATETIME, Stato: VARCHAR(6), Voto: TINYINT, Preventivo: FLOAT, Prezzo_pagato: FLOAT, Descrizione: TEXT, FK_ID_tip: INT, FK_P_IVA: VARCHAR(11)); (P_IVA: VARCHAR(11), Nome: VARCHAR, Tel: VARCHAR(10), Indirizzo: VARCHAR, Email: VARCHAR, Ragione_sociale: VARCHAR, FK_ID_CITTÀ: INT); (CF: VARCHAR, Nome: VARCHAR, Cognome: VARCHAR, Data_nascita: DATE,Indirizzo: VARCHAR, Username: VARCHAR, Password: VARCHAR, Tipo: VARCHAR, FK_ID_citta_nascita: INT, FK_ID_citta_residenza: INT );

INT); ●

Regioni

(ID_reg: INT, Nome_reg: VARCHAR);

SCHEMA FUNZIONALE (FUNZIONI E QUERY) 1 O 2 FUNZIONI DA REALIZZARE Tutti i valori preceduti dal simbolo “$” indicano variabili php che vengono passate alla query già controllate e sicuramente prive di errori. Anche nel caso di valori calcolati automaticamente dallo script (come il codice fiscale) questo meccanismo ci consente di essere sicuri del funzionamento delle query indipendentemente dai dati inseriti.


-Inserimento di un ticket Descrizione: Vogliamo dare la possibilità di inserire nel database un nuovo Ticket andando ad aggiungere ogni singolo valore di ogni singolo attributo che andrà a comporre l' entità TICKET. Nel nostro esempio il valore dell' attributo Data_apertura è definito grazie alla funzione predefinita NOW() dell' SQL, mentre il valore degli attributi "Stato, Preventivo, Descrizione, Settore, Tipologia" vengono definiti dai valori che la centralinista inserirà nella apposita form per la creazione di un ticket, che vengono poi salvati in 5 variabili php distinte in base all' attributo che dovranno andranno a rappresentare sul database.

INSERT INTO Ticket ( ID_ticket, Data_apertura, Stato, Preventivo, Descrizione, FK_P_IVA, FK_ID_tip) VALUES (“, DAY(NOW()), ‘OPEN’, ‘$preventivo’, ‘$Descrizione’, ‘$P_IVA’, ‘$ID_tipologia’); -Chiusura di un ticket Descrizione: Vogliamo dare la possibiltà di definire “Chiuso” un ticket, andando a definire il valore dell’ attributo Stato con “CLOSED”, mentre il valore degli attributi “Voto”, “Prezzo_pagato” e “Data_chiusura” viene definite tramite i valori inseriti nella form che vengono salvati nella variabile identificattiva dei singoli attributi.

UPDATE Ticket SET Stato= ‘$_stato’, Data_chiusura= ‘$dataC’, Voto=’$Voto’, Prezzo_pagato=’$pPagato’ WHERE ID_ticket= ‘$ID’; -Ricerca di un ticket Descrizione: Vogliamo dare la possibilità di poter ricercare nel database un ticket, utilizzando come chiave di ricerca un attributo fra: ID del ticket, Nome dell’ Azienda, Codice Fiscale del tecnico, Stato del ticket.

SELECT DISTINCT Data_apertura, Data_chiusura, Stato, Voto, Preventivo, Prezzo_pagato, Descrizione, Aziende.Nome, Dipendenti.Nome, Dipendenti.Cognome FROM Ticket, Aziende, Lavora_in, Settori, Tipologie, Dipendenti WHERE Ticket.FK_P_IVA=P_IVA AND Ticket.FK_ID_tip=ID_tip AND Tipologie.FK_ID_set=ID_set AND Lavora_in.FK_ID_set=ID_set AND Lavora_in.FK_CF=CF AND Aziende.Nome= 'Azienda1' AND


-Inserimento di un’azienda Descrizione: Vogliamo dare la possibilità di inserire nel database un nuova Azienda andando tutti gli attributi relativi alle aziende. I valori di tutti gli attributi vengono definiti dai valori che la centralinista inserirà nella apposita form per l’inserimento di un’azienda, che vengono poi salvati in 7 variabili php.

INSERT INTO Aziende VALUES (‘$piva’, ‘$Nome’, ‘$tel’, ‘$email’, ‘$ind’, ‘$ID_citta’, ‘$rag_soc’); -Cancellazione di un’azienda Descrizione: Vogliamo dare la possibilità di cancellare dal database una Azienda, selezionandone la Partita Iva o la ragione sociale (essendo le uniche chiavi univoche), che verranno salvate in una variabile php.

DELETE FROM Aziende WHERE P_IVA= ‘$piva’ OR Ragione_Sociale= ‘$rag_soc’; -Modifica di un’azienda Descrizione: Vogliamo dare la possibilità di modificare nel database una certa Azienda, selezionandola per partita IVA, che verrà salvata in una variabile php. In questo caso andiamo a caricare tutti gli attributi relativi all’azienda da modificare: se uno di essi è stato modificato, allora il corrispondente valore sarà aggiornato, mentre i valori degli attributi che non subiscono modifiche verranno semplicemente ricaricati (La form di caricamento dovrà quindi avere i campi degli attributi riempiti coi valori attuali dell’istanza da modificare).

UPDATE Aziende SET Nome= ‘$Nome’, Tel = ‘$tel’, Indirizzo= ‘$ind’, Email= ‘$email’, Ragione_sociale= ‘$rag_soc’ FK_ID_citta= ‘$citta’ WHERE P_IVA= ‘$P_iva’; -Inserimento Dipendente Descrizione: Vogliamo dare la possibilità di inserire nel database un nuovo dipendente andando ad aggiungere i valori di tutti gli attributi. Il codice fiscale non deve essere necessariamente inserito dall’utente, poichè può essere calcolato automaticamente in base alle altre informazioni in nostro possesso (nome, cognome, data e luogo di nascita).

INSERT INTO Dipendenti VALUES (‘$cf’, ‘$Cognome’, ‘$Nome’, ‘$dataN’, ‘$indirizzo’, ‘$user’, ‘$pw’, ‘$ID_cittaR’, ‘$ID_cittaN’, ‘$tipo’);


-Cancellazione Dipendente Descrizione: Vogliamo dare la possibilità di cancellare dal database un dipendente selezionandolo dallo username.

DELETE FROM Dipendenti WHERE Username= ‘$user’; -Modifica Dipendente Descrizione: Vogliamo dare la possibilità di modificare nel database un certo dipendente, selezionandolo per codice fiscale. In questo caso andiamo a caricare tutti gli attributi relativi al dipendente da modificare: se uno di essi è stato modificato, allora il corrispondente valore sarà aggiornato, mentre i valori degli attributi che non subiscono modifiche verranno semplicemente ricaricati (La form di caricamento dovrà quindi avere i campi degli attributi riempiti coi valori attuali dell’istanza da modificare).

UPDATE Dipendenti SET Nome= ‘$Nome’, Cognome= ‘$Cognome’, Username= ‘$user’, Password= ‘$pw’, Indirizzo= ‘$ind’, Data_nascita= ‘$dataN’, FK_ID_citta_nascita= ‘$ID_cittaN’, FK_ID_citta_residenza=‘$ID_cittaR’, Tipo=‘$tipo’ WHERE CF= ‘$cf’; -Tempo medio d’ intervento Descrizione: Vogliamo dare la possibilità di ottenere la durata media degli interventi fino ad oggi. Per fare ciò faremo la media della differenza fra i valori dei due attributi “Data_chiusura” e “Data_apertura” di ogni Ticket , prendendo in considerazione solo i ticket chiusi. Questa funzione restituirà quindi semplicemente un valore numerico, approssimato alla prima cifra decimale (l’unità di misura è il giorno).

SELECT TRUNCATE(AVG(DATE_FORMAT(Data_chiusura, ‘%d-%m-%Y’)DATE_FORMAT(Data_apertura, ‘%d-%m-%Y’)),1) AS ‘Tempo_Medio’ FROM Ticket WHERE Stato= ‘CLOSED’;


-Tempo medio d’ intervento per tipologia (in ordine crescente di durata) Descrizione: Come la funzione precedente, ma raggruppiamo i risultati per tipologia, in modo da avere per ogni tipo di intervento la relativa durata media. SELECT Nome_tip, TRUNCATE(AVG(DATE_FORMAT(Data_chiusura, ‘%d-%m-%Y’)DATE_FORMAT(Data_apertura, ‘%d-%m-%Y’)),1) AS ‘Tempo_Medio’ FROM Ticket, Tipologie WHERE FK_ID_tip=ID_tip AND Stato= ‘CLOSED’; GROUP BY ID_tip;

-Tempo medio d’ intervento per tecnico (in ordine crescente di durata) Descrizione: Vogliamo dare la possibilità di ottenere la durata media degli interventi di ogni tecnico fino ad oggi. Per fare ciò calcoleremo, per ogni tecnico, la media della differenza fra i valori dei due attributi “Data_chiusura” e “Data_apertura” di ogni intervento da lui eseguito, raggruppando i risultati in base al codice fiscale e ordinando i risultati proprio in base alla durata media, per mettere in risalto i tecnici migliori.

SELECT Dipendenti.Nome AS ‘Nome’, Dipendenti.Cognome AS ‘Cognome’, TRUNCATE(AVG(DATE_FORMAT(Data_chiusura, '%d-%m-%Y') DATE_FORMAT(Data_apertura, '%d-%m-%Y')), 1) AS ‘Tempo_Medio’ FROM Ticket, Tipologie, Settori, Lavora_in, Dipendenti WHERE FK_ID_tip=ID_tip AND Tipologie.FK_ID_set=ID_set AND Lavora_in.FK_ID_set=ID_set AND FK_CF=CF AND Stato='CLOSED' AND Tipo='Tecnico' GROUP BY CF ORDER BY TRUNCATE(AVG(DATE_FORMAT(Data_chiusura, '%d-%m-%Y')DATE_FORMAT(Data_apertura, '%d-%m-%Y')),1) ASC;


-Tempo medio d’ intervento x settore (in ordine crescente di durata) Descrizione: Vogliamo dare la possibilità di ottenere la durata media degli interventi fino ad oggi, differenziando per Settori. Per fare ciò faremo la media della differenza fra i valori dei due attributi “Data_chiusura” e “Data_apertura” di ogni Ticket (grazie alla funzione predefinita AVG() ) , raggruppando i risultati per i quali il settore è il medesimo

SELECT Nome_set AS ‘Settore’, TRUNCATE(AVG(DATE_FORMAT(Data_chiusura, '%d-%m-%Y')DATE_FORMAT(Data_apertura, '%d-%m-%Y')),1) AS ‘Tempo_Medio’ FROM Ticket, Tipologie, Settori WHERE FK_ID_tip=ID_tip AND Tipologie.FK_ID_set=ID_set AND Stato='CLOSED' GROUP BY Nome_set; -Numero di ticket non pagati per intero Descrizione: Vogliamo dare la possibilità di ottenere il numero di ticket che non sono stati pagati. Prenderemo quindi in considerazione solo i ticket in cui il preventivo è maggiore del prezzo effettivamente pagato.

SELECT FROM WHERE

COUNT(*) AS ‘TicketNonPagati’ Ticket Preventivo> Prezzo_pagato;

-Numero di ticket per ogni stato (ordinati per numero di ticket) Descrizione: Vogliamo dare la possibilità di ottenere il numero di ticket differenziando per Stato ( CLOSED, OPEN o FAILED). Per fare ciò, dopo aver preso in considerazione tutti i ticket esistenti (sia aperti che chiusi) andiamo a raggruppare i risultati in base al valore dell’ attributo Stato. Ordiniamo poi i risultati in base al numero di ticket per rogni stato.

SELECT FROM GROUP BY ORDER BY

Stato, COUNT(*) AS ‘NumeroTicket’ Ticket Stato COUNT(*) DESC;


-Media indici di gradimento per tecnico Descrizione: Vogliamo dare la possibilità di ottenere la media dei voti di indice di gradimento di ogni singolo tecnico (grazie alla funzione predefinita AVG() ) . Per fare ciò calcoliamo la media dei valori dell’ attributo Voto, raggruppando i risultati per medesimo codice fiscale del tecnico.

SELECT FROM WHERE

Nome, Cognome, TRUNCATE(AVG (Voto),2) AS 'MediaVoto' Dipendenti, Lavora_in, Settori, Tipologie, Ticket FK_CF=CF AND Lavora_in.FK_ID_set=ID_set AND FK_ID_tip=ID_tip AND Tipologie.FK_ID_set= ID_set GROUP BY CF ORDER BY AVG(Voto); -Media indici di gradimento per settore Descrizione: Vogliamo dare la possibilità di ottenere la media dei voti di indice di gradimento di ogni singolo settore. Per fare ciò calcoliamo la media dei valori dell’ attributo Voto, raggruppando i risultati per settore.

SELECT FROM WHERE

Nome_set, TRUNCATE(AVG(Voto),2) AS 'Media_Voti' Ticket, Tipologie, Settori FK_ID_set=ID_set AND FK_ID_tip=ID_tip GROUP BY ID_set ORDER BY AVG(Voto) DESC;


Progetto Informatica Gennaio 2013