PROGETTO DI UNA BASE DI DATI PER LA GESTIONE DI UN GATTILE COMUNALE

Transcript

1 UNIVERSITÁ DEGLI STUDI DEL MOLISE CORSO DI LAUREA IN INFORMATICA Progetto per il corso di Basi di Dati PROGETTO DI UNA BASE DI DATI PER LA GESTIONE DI UN GATTILE COMUNALE Studente : Gianandrea Giovanni Lepore Antonio Ricciuti Paolo Valente Lorenzo Docente : Prof. Remo Pareschi

2 INDICE 1. INTRODUZIONE ANALISI DEI REQUISITI Descrizione del problema Specifiche sulle operazioni PROGETTAZIONE CONCETTUALE Schema concettuale secondo il modello Entità-Relazione Anagrafe felina Gattile Integrazione di schemi Vincoli di integrità dei dati Analisi di qualità PROGETTAZIONE LOGICA Analisi delle prestazioni Ristrutturazione dello schema E-R Analisi delle ridondanze ed Eliminazione delle gerarchie Partizionamento/accorpamento di concetti Eliminazione di attributi composti Scelta degli identificatori principali Traduzione verso il modello relazionale Proprietà Rilevazione Sottoposizione Residenza Registrazione Prelevamento Ritrovamento Destinazione Appartenenza Conclusioni Verifica di normalizzazione PROGETTAZIONE FISICA Definizione dello schema della base di dati Definizione delle tabelle Formulazione delle interrogazioni... 32

3 1. INTRODUZIONE Il gattile sanitario è il luogo in cui sono raccolti e mantenuti dalla Provincia tutti quei gatti che risultano essere senza padrone, perché randagi, smarriti o abbandonati, oppure quelli che vengono consegnati dal padrone stesso, perché impossibilitato a prendersene cura. Le provincie della regione sono organizzate in modo tale che il Servizio Veterinario di ciascuna A.S.L. si occupa di registrare i dati anagrafici di tutti i gatti di proprietà residenti nei comuni associati. Così, chiunque possieda un gatto è obbligato a denunciarne l'esistenza al proprio comune entro i primi tre mesi di vita e la scomparsa o la morte entro 15 giorni dall'avvenimento. Al momento dell'iscrizione all'anagrafe felina, ciascun gatto viene identificato univocamente mediante microchip, cosicché sia sempre possibile rintracciarne il padrone. Tuttavia non tutti i gatti raccolti dal gattile sono stati precedentemente denunciati e, se nessuno ne reclamerà lo smarrimento, i comuni in cui sono stati raccolti dovranno occuparsi del loro mantenimento durante i giorni di carico al gattile. La realtà presa in considerazione per lo sviluppo della seguente base di dati comprende una A.S.L che si occupa dell'anagrafe felina e nella cui sede si trova anche il gattile sanitario della provincia. Si tratta quindi di analizzare due realtà diverse ma strettamente correlate fra loro: A. la gestione dell'anagrafe felina: - attribuzione del microchip al gatto; - registrazione dei dati del padrone; - compilazione della scheda clinica; - prestazioni veterinarie; B. la gestione del gattile: - entrate/uscite dei gatti dal gattile; - iscrizione all'anagrafe; - organizzazione delle spese di mantenimento; - prestazioni degli operatori (accalappiagatti). L'introduzione di un programma applicativo semplificherebbe notevolmente il lavoro dell'amministratore del gattile, ora costretto a compilare a mano tutti i documenti da inviare ai Comuni e alle A.S.L. A questi enti, infatti, devono essere spedite periodicamente schede di riepilogo sulle presenze di gattile randagi al gattile e sulle prestazioni di Igiene Pubblica Veterinarie e/o di assistenza zooiatrica effettuate, ai fini di richiederne il rimborso spese previsto.

4 2. ANALISI DEI REQUISITI 2.1 Descrizione del problema Si vuole automatizzare l'organizzazione interna di un gattile sanitario per ottenere la gestione completa dei seguenti aspetti: la registrazione dei dati anagrafici e clinici dei gatti; la registrazione dei dati di entrata/uscita dei gatti raccolti dal gattile; le visite veterinarie cui vengono sottoposti; le spese di sostentamento del gatto in relazione a coloro che le sosterranno (padrone, Comune, A.S.L.); l'intervento dei quattro operatori (accalappiagatti); il registro, sul quale viene segnalato ciascun gatto che entra al gattile per mezzo di un numero progressivo preceduto da una lettera indicante l'anno (si presuppone che un gatto non viva più di 25 anni, numero pari alle lettere dell'alfabeto, oltre i quali si potrà riattribuire lo stesso codice ad un altro gatto); qui saranno rilevati i dati principali del gatto: data e modo di entrata (randagio, consegnato, pericoloso), razza, taglia, sesso, mantello, data e modo di uscita e sullo spazio riservato alle note, tramite un codice a barre, si farà riferimento al microchip d'identificazione. la scheda personale del gatto, suddivisa in: - scheda di identificazione con riferimento a n di registro, data di entrata, microchip (sempre tramite codice a barre), medaglia (solo ad uso interno), tatuaggio, età (anche presunta), sesso, razza, colore del mantello, pelo, segni particolari, luogo del ritrovamento e comune, eventuale persona che lo ha segnalato e operatore che lo ha prelevato; - scheda clinica sulla quale si registra la data e l'esito delle visite veterinarie cui viene sottoposto, specificando diagnosi, terapia, vaccini, risultati dei test ed eventuale sterilizzazione chirurgica; - scheda esito su cui vengono rilevati la data e il modo di uscita del gatto che può essere: riscattato, ceduto, eliminato, pericoloso ritirato o morto (la causa dovrà essere specificata). la scheda di riepilogo presenze di gatti nel gattile, tramite la quale vengono segnalati ai comuni i giorni e i microchip in carico per richiederne le spese e la cui compilazione è effettuata ogni tre mesi interamente a mano dall'amministratore. Si chiede inoltre la gestione delle spese alle quali va incontro il gattile. Quelle di cattura, trasporto, vaccinazione, sterilizzazione, smaltimento animali morti, ecc., saranno sostenute dall'as.l. di cui fa parte il comune di provenienza del gatto, mentre per quanto riguarda il suo mantenimento esiste una distinzione basata sui diversi modi di entrata al gattile:

5 a) può essere raccolto dall'accalappiagatti sotto segnalazione o abbandonato alle porte del gattile. Se nessuno ne reclamerà lo smarrimento, il gatto sarà considerato randagio e le spese riguardanti il suo sostentamento e il costo del microchip ( 15) graveranno sul comune di provenienza (costo giornaliero 5). Al costo dei gatti abbandonati nel comune di residenza del gattile stesso contribuiscono tutti gli altri comuni con una quota aggiuntiva di 5. b) può essere consegnato dal padrone stesso perché non più in grado di occuparsene. In questo caso e in quello in cui un gatto randagio venga riscattato, il costo del microchip ( 25) e quello giornaliero, che ammonta a 10 per i primi 5 giorni e a 5 per i giorni successivi, sono a carico del proprietario. c) può essere segnalato come pericoloso. Qui vale la stessa distinzione fatta fra gatto randagio o di proprietà. Riassumendo, è possibile realizzare un glossario (Figura 1.1) che, per ogni concetto di interesse alla base di dati, contenga: una breve descrizione, i dati inerenti e altri termini con i quali esiste un legame logico. 2.2 Specifiche sulle operazioni Le operazioni che si vogliono automatizzare sono le seguenti: Op. 1 : Inserimento dei dati relativi ad un nuovo gatto. Op. 2 : Modifica dei dati di un gatto. Op. 3 : Visualizzazione/Stampa dei dati di un gatto (anagrafici, sanitari, di entrata/uscita). Op. 4 : Ricerca di un gatto tramite microchip. Op. 5 : Ricerca di un gatto tramite il nome del padrone (il risultato può essere multiplo). Op. 6 : Lista complessiva dei gatti entrati al gattile in un certo anno. Op. 7 : Lista dei gatti attualmente in carico. Op. 8 : Lista dei gatti randagi attualmente in carico. Op. 9 : Lista dei gatti entrati in una certa data. Op. 10 : Lista dei gatti di una certa razza. Op. 11 : Visualizzazione del numero di gatti di una certa razza. Op. 12 : Visualizzazione del numero di gatti in carico. Op. 13 : Visualizzazione del numero di gatti randagi in carico. Op. 14 : Visualizzazione del numero di microchip assegnati in un periodo a gatti randagi. Op. 15 : Visualizzazione delle date di Entrata e di Uscita dei gatti randagi presenti al gattile in un periodo raggruppati per comune. Op. 16 : Visualizzazione dei dati relativi a ciascun comune. Op. 17 : Registrazione di una nuova scheda clinica. Op. 18 : Visualizzazione dei dati di un operatore. Op. 19 : Statistica periodica (mensile, trimestrale e annuale) sul movimento dei gatti. Op. 20 : Conteggio e tipo (sanitaria, di trasporto o di smaltimento) delle prestazioni a carico di ciascuna A.S.L. in un periodo. Termine Descrizione Dati Collegamenti Gatt Gatto Gatto registrato all'anagrafe. Può essere randagio o privato. Anagrafici, Clinici Comune, Padrone, Visita Entrata/Uscita Dati dei gatti raccolti dal Numero di registro, Gatto,

6 Comune A.S.L. Padrone Visita Operatore gattile. Comune di provenienza del gatto. Il costo giornaliero e del microchip dei gatti randagi è a suo carico. A.S.L.alla quale appartiene il comune. Si occupa delle spese sanitarie, di trasporto e di smaltimento di ciascun gatt. Proprietario delgatto. Provvede alle spese di mantenimento e del microchip del proprio gatto. Esito della visita veterinaria cui viene sottoposto periodicamente ciascun gatto. Accalappiagatti che preleva il gatto. Attualmente sono quattro. Data e modo di entrata, Eventuale segnalatore, Data e modo di uscita Codice del comune, Nome, Sindaco Numero AS.L., Responsabile, Indirizzo, o. Città Codice fiscale, Cognome, Nome, Indirizzo, Residenza, Telefono, Cellulare Data, Esami, Diagnosi, Terapia, Cognome, Nome, Indirizzo, Città Operatore, Comune Gatto, A.S.L. Comune Gatto Gatto Gatto Figura 1.1 Glossario dei termini

7 3. PROGETTAZIONE CONCETTUALE 3.1 Schema concettuale secondo il modello Entità-Relazione Sviluppo secondo le metodologie BOTTOM-UP e TOP-DOWN (strategia mista). Dalle specifiche del problema possiamo generare un primo schema scheletro (Figura 3.1) che, tramite le entità GATTO, PADRONE e COMUNE, rappresenta i concetti principali. Tra queste entità esistono delle relazioni che descrivono il comune di provenienza dei gatti e la proprietà dello stesso da parte di un padrone. COMUNE provenienza GATTO proprietà PADRONE Figura 3.1 Schema scheletro Prima di procedere con i raffinamenti successivi (strategia top-down), è opportuno suddividere lo schema iniziale tra i due aspetti che caratterizzano la realtà d'interesse, per poterli prima analizzare distintamente (strategia bottom-up). Si otterranno quindi due schemi scheletro: uno si riferisce all'anagrafe felina (Figura 3.2), l'altro alla gestione del gattile (Figura 3.6) Anagrafe Felina COMUNE residenza GATTO proprietà PADRONE Figura 3.2 schema scheletro Anagrafe Felina Lo schema scheletro differisce da quello iniziale solo per una modifica: la relazione che lega GATTO a COMUNE è diventata residenza e indica il comune in cui vive il gatto dichiarato all'anagrafe. Primo raffinamento

8 Poiché ciascun gatto viene periodicamente sottoposto a visite veterinarie, è necessario rappresentare nello schema la nuova entità VISITA (Trasformazione T 1 bottom-up) che appare in Figura 3.3. Figura 3.2 schema scheletro Anagrafe Felina COMUNE residenza GATTO sottoposizione VISITA proprietà PADRONE Secondo raffinamento Ora si possono aggiungere a ciascuna entità e a ciascuna relazione i rispettivi dati sotto forma di attributi (Trasformazioni T 5 e T 6 top-down). Tuttavia dalle specifiche del problema si apprende che i numerosi dati riferiti all'entità GATTO possono essere raggruppati in due classi relative all'anagrafe felina secondo lo schema di Figura 3.4. Classe di dati Attributi Descrizione Anagrafici Microchip AnnoN Sesso Razza Taglia Colore Pelo Tatuaggio SegniP Numero del microchip attribuito Anno di nascita (anche presunto) Sesso Razza Taglia Colore del pelo Tipo di pelo (lungo/corto, liscio/ruvido,...) Eventuale tatuaggio Eventuali segni particolari (attributo formato testo in Sanitari Figura 3.4 DataVacc Vacc AntiPar TestFil SterChir Prof Terzo raffinamento Tabella dei dati riferiti all'entità Gatto cui vengono elencati i segni particolari) Data in cui è stato effettuato il vaccino Tipo di vaccino Antiparassitario Esito del test filaria (positivo/negativo) Effettuazione sterilizzazione chirurgica (SI/NO) Esito profilassi (positivo/negativo) Per ottenere una base di dati più efficiente si può quindi suddividere verticalmente l'entità GATTO in due entità (Trasformazione T 1 top-down): 1. la prima, che manterrà il nome di quella di origine, aggrega i dati anagrafici;

9 2. la seconda registra tutti i dati sanitari e prende il nome di SCHEDA CLINICA ed è identificata dall'entità di origine con un identificatore esterno. La maggiore efficienza è data dal fatto che questa divisione introduce: - maggiore velocità di risposta (in genere viene interrogata una singola classe di dati per volta), - maggiore chiarezza nello schema E-R (l'entità VISITA è legata solo all'entità SCHEDA CLINICA). La nuova entità sarà legata a GATTO dalla relazione 1:1 rilevazione. Ora è possibile tracciare la prima parte dello schema E-R (Figura 3.5) completo di attributi, identificatori e cardinalità. COMUNE residenza Colore Pelo (1,1) (0,N) AnnoN Sesso Razza Taglia GATTO Microchip Tatuaggio SegniP (0,1) rilevazione (1,1) (1,1) DataVacc AntiPar Vacc TestFil SterChir Prof SCHEDA CLINICA Sindaco NomeC CodCom (1,1) DataReg (1,N) proprietà sottoposizione (1,N) (1,1) Via N Indirizzo Città PADRONE (0,1) Tel Cell Data Diagnosi Terapia VISITA CodFisc Nome Cognome Figura 3.5 schema finale Anagrafe Felina Gattile COMUNE ritrovamento Gatto

10 Figura 3.6 schema scheletro Gattile In questo caso lo schema scheletro è costituito dalle sole entità Gatto e COMUNE, legate dalla relazione ritrovamento che indica il comune in cui il gatto è stato raccolto dall'accalappiagatti e che si occuperà del suo mantenimento nel caso in cui si tratti di un randagio. Primo raffinamento Innanzi tutto sarà introdotta l'entità OPERATORE, che racchiude i dati personali degli accalappiagatti che hanno provveduto all'eventuale prelevamento dell'animale. Inoltre, poiché l'a.s.l. di appartenenza del comune da cui proviene il gatto si occupa delle spese riguardanti le prestazioni di Igiene Pubblica Veterinaria (sanitarie, di trasporto e di smaltimento animali morti), sarà necessario rappresentare nello schema questa nuova entità. Ora lo schema ha assunto un aspetto più dettagliato (Trasformazione T 1 bottom-up), come si può vedere in Figura 3.7. Gatto prelevamento OPERATORE ritrovamento A.S.L. appartenenza COMUNE Figura 3.7 risultato del primo raffinamento dello schema Gattile Secondo raffinamento Nell'aggiungere i dati sotto forma di attributi (Trasformazioni T 5 e T 6 ) ci accorgiamo nuovamente che i numerosi dati riferiti all'entità gatto possono essere raggruppati questa volta in tre classi secondo lo schema seguente: Classe di dati Attributi Descrizione Anagrafici Microchip AnnoN Sesso Numero del microchip attribuito Anno di nascita (anche presunto) Sesso

11 Entrata Uscita Razza Razza Taglia Taglia Colore Colore del pelo Pelo Tipo di pelo (lungo/corto, liscio/ruvido,...) Tatuaggio Eventuale tatuaggio SegniP Eventuali segni particolari (attributo formato testo in cui vengono elencati i segni particolari) NProg Numero di registro DataEnt Data di entrata al gattile ModoE Modo d'entrata (randagio/consegnato/pericoloso) Segnalatore Eventuale nome della persona che ha chiamato DataU ModoU Note l'accalappiagatti Data di uscita dal gattile Modo di uscita (decesso/rifugio/affidamento/riscatto) Note o causa dell'eventuale morte Figura 3.8 Tabella dei dati riferiti all'entità GATTO Terzo raffinamento Sempre ai fini di ottenere una base di dati più efficiente si può ancora suddividere verticalmente l'entità GATTO in tre entità (Trasformazione T 1 top-down): 1. la prima, che manterrà il nome di quella di origine, aggrega i dati anagrafici; 2. ENTRATA registra i dati riguardanti l'entrata al gattile ed ha come identificatore un numero progressivo e la data di entrata; 3. USCITA raccoglie i dati riguardanti l'uscita ed è identificata dall'entità ENTRATA con un identificatore esterno. La maggiore efficienza è data dal fatto che questa divisione: - minimizza l'introduzione di valori nulli (tutti i gatti attualmente accolti dal gattile hanno nulli i dati riguardanti l'uscita), - permette una maggiore velocità di risposta (in genere viene interrogata una singola classe di dati per volta). L'entità ENTRATA sarà collegata all'entità GATTO dalla relazione 1:N registrazione (uno stesso gatto può smarrirsi ed essere raccolto dal gattile più di una volta) e l'entità USCITA sarà legata ad ENTRATA dalla relazione 1:1 destinazione, dove la partecipazione della prima è opzionale. Anche la seconda parte dello schema è stata raffinata (Figura 3.9) ed è completa di attributi, identificatori e cardinalità.

12 USCITA (1,1) destinazione prelevamento (0,1) Note (0,1) (0,1) (0,1) ModoU Via DataU Indirizzo Città Nome CodFisc N Cognome (1,N) Tel Cell OPERATORE NProg DataEnt ModoE Segnalatore (0,1) (1,1) (1,1) Medaglia ENTRATA registrazione GATTO Pelo Colore (0,N) Taglia Razza Sesso AnnoN (0,1) SegniP Tatuaggio Microchip ritrovamento NA.S.L. Resp (0,N) Sindaco A.S.L. (N,M) appartenenza (1,1) COMUNE NomeC CodCom Via Città Indirizzo N Figura 3.9 schema finale Gattile Integrazione di schemi Ora è possibile fondere i due schemi ottenuti sovrapponendo le entità rispettivamente omonime GATTO e COMUNE ed eventualmente modificando le cardinalità dove opportuno (Figura 3.10).

13 OPERATORE prelevamento rilevazione SCHEDA CLINICA USCITA destinazione ENTRATA registrazione GATTO sottoposizione ritrovamento VISITA A.S.L. appartenenza COMUNE residenza proprietà PADRONE Figura 3.10 fusione dei due schemi (priva di attributi) Ultimo raffinamento Fondamentale per la gestione delle spese di sostentamento è la distinzione fra gatti randagi e gatti di proprietà. Questo scopo può essere facilmente raggiunto con l'introduzione di una generalizzazione (Trasformazione T 2 top-down) totale ed esclusiva in cui GATTO è l'entità padre e le due entità figlie RANDAGIO e PRIVATO specificano rispettivamente se si tratta di un gatto randagio o di proprietà. Ora le relazioni proprietà e residenza coinvolgono solo l'entità figlia interessata, cioè PRIVATO. In questo modo è stato completato lo schema concettuale finale secondo il modello E-R, completo di attributi, identificatori e cardinalità, come si può vedere a pagina 14. I dizionari dei dati sono in Figura 3.11 e 3.12.

14 Entità Descrizione Attributi Identificatore GATTO Gatto che viene registrato Microchip, AnnoN, Sesso, Microchip all'anagrafe felina. Entità padre. Razza, Taglia, Colore, Pelo, Tatuaggio, SegniP (0,1) RANDAGIO Gatto senza padrone. Entità v. entità padre figlia. PRIVATO Gatto di proprietà. Entità v. entità padre PADRONE figlia. Proprietario di un gatto privato. CodFisc, Cognome, Nome, Indirizzo (Via, N ), Città, Tel, Cell (0,1) CodCom, NomeC, Sindaco COMUNE Comune di residenza o di ritrovamento di un gatti. A.S.L. A.S.L.cui appartiene il NASL, Resp, Indirizzo (Via, comune. N ), Città ENTRATA Raccolta dei dati del gatti NProg, DataEnt, ModoE, relativi all'entrata al gattile. Segnalatore (0,1) OPERATORE Accalappiagatti. CodFisc, Cognome, Nome, Indirizzo (Via, N ), Città, Tel, Cell (0,1) SCHEDA CLINICA Raccolta dei dati sanitari del gatto. USCITA Raccolta dei dati riguardanti la destinazione raggiunta dal gatto. VISITA Visita veterinaria a cui il gatto viene sottoposto. Vacc, DataVacc, AntiPar, TestFil, SterChir, Prof DataU, ModoU, Note (0,1) Data, Esami, Diagnosi, Terapia CodFisc CodCom NASL NProg, DataEnt CodFisc Gatto Entrata Data, Scheda Clinica Figura 3.11 Dizionario dei dati delle entità

15 Relazione Descrizione Entità coinvolte Attributi Proprietà Associa un gatto privato al PRIVATO (1,1) DataReg suo padrone. PADRONE (1,N) Residenza Associa un gatto privato al comune in cui risiede. PRIVATO (1,1) COMUNE (0,N) Ritrovamento Associa un gatto entrato al gattile al comune in cui è ENTRATA (1,1) COMUNE (0,N) stato ritrovato. Appartenenza Associa un comune all'a.s.l. COMUNE (1,1) Registrazione Prelevamento Rilevazione Sottoposizione Destinazione di cui fa parte. Associa un gatto alla voce di registro che ne dichiara l'entrata al gattile. Associa la voce di registro di un gatto all'operatore che lo ha prelevato. Associa un gatto alla propria scheda clinica. Associa la scheda clinica di un gatto ad una visita veterinaria. Associa un gatto alla sua scheda esito. A.S.L. (N,M) GATTO (0,N) ENTRATA (1,1) OPERATORE (N,M) ENTRATA (0,1) GATTO (1,1) SCHEDA CLINICA (1,1) SCHEDA CLINICA (1,N) VISITA (1,1) GATTO (0,1) USCITA (1,1) Medaglia Figura 3.12 Dizionario dei dati delle associazioni

16

17 3.2 Vincoli di integrità dei dati Regole di vincolo: (RV1) Non sono ammesse duplicazioni di tuple per alcuna tabella. (RV2) Gli identificatori di tutte le entità non possono assumere valori nulli. (RV3) Non può essere registrato più di un gatto con lo stesso microchip. (RV4) Non può essere registrato più di un gatto con lo stesso numero progressivo nello stesso anno. (RV5) Non è possibile inserire i dati sanitari di un gatto non registrato all'anagrafe felina. (RV6) Non è possibile compilare la scheda di uscita di un gatto che non risulta essere mai entrato al felina (RV7) Tutti i gatti che entrano al gattile devono essere sottoposti alla visita veterinaria. (RV8) Una volta registrato tramite Microchip, nessun gatto può essere cancellato. 3.3 Analisi di qualità CORRETTEZZA Lo schema è corretto in quanto sono stati utilizzati correttamente i costrutti del modello Entità - Relazione. COMPLETEZZA Lo schema concettuale rappresenta tutti i dati di interesse e tutte le operazioni possono essere eseguite a partire dai concetti descritti. Per questo lo schema può essere definito completo. LEGGIBILITA' Lo schema concettuale è leggibile, autoesplicativo e rappresenta i requisiti in maniera naturale e facilmente comprensibile. MINIMALITA' Tutte le specifiche sui dati sono rappresentate una sola volta nello schema, con una eccezione. Infatti la generalizzazione che specifica se un gatto è randagio o privato può essere una fonte di ridondanza: i gatti privati possono essere rilevati dalle occorrenze della relazione proprietà o da quelle della relazione residenza. Per questo motivo lo schema proposto non può essere definito minimale. Tuttavia il raggiungimento della minimalità sarà uno degli scopi della progettazione logica.

18 4. PROGETTAZIONE LOGICA 4.1 Analisi delle prestazioni Tavola dei volumi Concetto Tipo Volume GATTO E RANDAGIO E 50 PRIVATO E PADRONE E ENTRATA E 750/anno COMUNE E 95 A.S.L. E 3 SCHEDA CLINICA E VISITA E 4000/anno OPERATORE E 4 USCITA E 750/anno Registrazione R 750/anno Proprietà R 3000/anno Ritrovamento R 750 Appartenenza R 95 Rilevazione R 3000/anno Residenza R 3000/anno Prelevamento R 600/anno Sottoposizione R 4000/anno Destinazione R 750/anno Tavola delle operazioni Operazione Tipo Frequenza Op. 1 I 3000/anno Op. 2 I 400/anno Op. 3 I 1000/anno Op. 4 I 1000/anno Op. 5 I 1000/anno Op. 6 B 1/anno Op. 7 B 4/anno Op. 8 B 4/anno Op. 9 I 600/anno Op. 10 I 5/anno Op. 11 I 5/anno Op. 12 B 4/anno Op. 13 B 4/anno Op. 14 I 4/anno Op.15 B 4/anno Op. 16 B 4/anno Op. 17 I 3000/anno Op. 18 I 1/mese Op. 19 B 1/mese Op. 20 B 4/anno Figura 4.1 Tavole dei volumi e delle operazioni La tavola dei volumi e quella delle operazioni raffigurate qui sopra permettono di conoscere rispettivamente: Volume dei dati: - Numero di occorrenze di ogni entità e associazione dello schema. Caratteristiche delle operazioni: - Tipo dell'operazione (interattiva o batch); - Frequenza (numero medio di esecuzioni in un certo intervallo di tempo). Tali informazioni potranno essere utili in seguito per studiare gli indici di prestazione del sistema e poter prendere decisioni appropriate sul tipo di ristrutturazione dello schema E-R da effettuare.

19 4.2 Ristrutturazione dello schema E-R Per semplificare la traduzione verso il modello logico sarà necessario riorganizzare e ottimizzare lo schema concettuale Analisi delle ridondanze ed Eliminazione delle gerarchie C'è un solo dato ridondante nello schema: la distinzione tra gatto RANDAGIO e PRIVATO introdotta dalla generalizzazione può essere effettuata semplicemente verificando le occorrenze della relazione proprietà o della relazione residenza. I gatti che non partecipano a queste associazioni, infatti, sono stati iscritti all'anagrafe felina in seguito ad un ritrovamento e non per volontà del proprio padrone, e per di più tale padrone, se esistente, non è stato rintracciato. Ciò porta a concludere che si tratta di gatti randagi. Così il raggiungimento della minimalità è possibile solo eliminando la gerarchia che vede come padre l'entità GATTO e come figlie le entità RANDAGIO e PRIVATO. Tuttavia questa modifica risulta essere d'obbligo per permettere la traduzione verso il modello logico relazionale, poiché tale modello non permette di rappresentare direttamente una gerarchia. Il modo migliore per tradurre questa generalizzazione totale ed esclusiva è quello di accorpare le figlie al padre: in questo modo le proprietà di RANDAGIO e PRIVATO vengono aggiunte a GATTO, insieme con un nuovo attributo che distinguerà il tipo (randagio o privato) di ogni occorrenza di gatto. Nel nostro caso nessuna delle due entità figlie possiede attributi che non siano quelli comuni, così non ci sarà alcuno spreco di memoria dovuto all'introduzione di valori nulli. Inoltre le due associazioni di PRIVATO, ora collegate direttamente a GATTO, muteranno la loro cardinalità: infatti la partecipazione dell'entità padre a proprietà e residenza sarà opzionale, a seconda che si tratti di una occorrenza di tipo randagio o privato. E' facile accorgersi che l'eliminazione della gerarchia non ha permesso il raggiungimento della minimalità, poiché ha causato l'introduzione di una nuova forma di ridondanza: l'attributo che indica il "tipo" di GATTO è un attributo derivabile da operazioni di conteggio di occorrenze. Dando uno sguardo alle tavole dei volumi e delle operazioni in Figura 4.1 (operazioni 1, 8, 13 e 15), vediamo che la frequenza con cui vengono effettuate nuove iscrizioni all'anagrafe felina (circa 1000 volte l'anno) è nettamente superiore a quella con cui vengono richieste distinzioni tra gatti randagi e privati (circa 4 volte l'anno). Quindi gli svantaggi di mantenere il dato derivato, quali una maggiore occupazione di memoria e la necessità di effettuare operazioni aggiuntive per mantenere il dato aggiornato, sono molto maggiori dell'unico vantaggio dato dalla riduzione degli accessi necessari per calcolarlo. La decisione per la quale si opterà sarà quindi quella di eliminare la ridondanza e raggiungere così lo stato di minimalità Partizionamento/accorpamento di concetti Non si ritengono necessarie delle trasformazioni di questo genere, poiché già in sede di progettazione concettuale sono state effettuate delle decomposizioni verticali di entità (vedi GATO e ENTRATA) per motivi di efficienza che tuttora si ritengono validi. Inoltre non sono presenti attributi multivalore da eliminare, ma solo attributi opzionali per i quali si accetta l'introduzione di valori nulli.

20 4.2.3 Eliminazione di attributi composti L'attributo "Indirizzo" composto da "Via" e "N " deve essere sostituito o da un singolo attributo, con conseguente perdita della nozione di componente, o considerando ciascuna componente come un singolo distinto attributo, provocando la perdita della nozione di interrelazione tra le componenti. Poiché per i nostri scopi non è necessario accedere in maniera indipendente alla via o al numero civico della persona o dell'ente considerato, la soluzione migliore risulta essere quella di sostituire l'attributo composto con un singolo attributo "Indirizzo" Scelta degli identificatori principali L'identificatore di ENTRATA è costituito da due attributi; le entità deboli USCITA, SCHEDA CLINICA e VISITA hanno un identificatore esterno e per quanto riguarda quest'ultima tale identificatore è affiancato da un attributo interno. Queste situazioni verranno risolte, quando possibile, in sede di mapping, quando si cercherà di scegliere chiavi primarie semplici, formate dal minimo numero di attributi e utilizzate da molte operazioni. Tutte le altre entità presentano un unico identificatore. Abbiamo con questo terminato la fase di ristrutturazione dello schema E-R originale. Lo schema risultante è quello in Figura 4.2.

21

22 4.3 Traduzione verso il modello relazionale Completata la ristrutturazione dello schema concettuale, è ora possibile effettuarne la traduzione verso lo schema logico relazionale. In ciascun paragrafo sarà affrontato singolarmente il mapping di ogni associazione binaria, seguito dalla discussione della scelta delle chiavi primarie delle tabelle ottenute e dalla schematizzazione dei vincoli di integrità referenziale introdotti Proprietà Associazione 1:N tra GATTO e PADRONE con un attributo (DataReg) che indica la data in cui la persona è stata registrata come padrone del gatto in questione. La partecipazione di GATTO è opzionale. Per evitare l'introduzione di ulteriori valori nulli, optiamo per il seguente schema (l'apice asterisco indica che l'attributo può assumere il valore nullo): GATTO (Microchip, AnnoN, Sesso, Razza, Taglia, Colore, Pelo, Tatuaggio, SegniP * ) PADRONE (CodFisc, Cognome, Nome, Indirizzo, Città, Tel, Cell * ) PROPRIETA' (Microchip, CodFisc, DataReg) La chiave di PROPRIETA' è costituita solo dall'identificatore di GATTO perché le cardinalità dell'associazione ci dicono che ogni gatto può avere al più un solo padrone. Per una migliore leggibilità dello schema è più opportuno modificare i nomi degli attributi referenti nel modo seguente: PROPRIETA' (GATTO Padrone, DataReg) I vincoli di integrità referenziale introdotti dalla traduzione sono rappresentati in Figura 4.3. PADRONE CodFisc Cognome Nome Indirizzo Città Tel Cell PROPRIETA Gatto Padrone DataReg GATTO Microchip AnnoN Sesso Razza Taglia Colore Pelo Tatuaggio SegniP Figura 4.3 Rappresentazione grafica dei vincoli d'integrità referenziali di PROPRIETA' Rilevazione

23 Associazione 1:1 tra GATTO e SCHEDA CLINICA. Quest'ultima è un'entità debole ed ha GATTO come unico identificatore esterno. Poiché entrambi gli schemi delle entità avranno come chiave l'identificatore dell'entità forte, una soluzione potrebbe essere quella di rappresentarli in un unico schema. Tuttavia, per motivi di efficienza citati precedentemente, si preferisce mantenere i due schemi distinti: GATTO (Microchip, AnnoN, Sesso, Razza, Taglia, Colore, Pelo, Tatuaggio, SegniP * ) SCHEDA CLINICA (Microchip, DataVacc, Vacc, TestFil, AntiPar, SterChir, Prof) I vincoli di integrità referenziale introdotti dalla traduzione sono rappresentati in Figura 4.4. SCHEDA CLINICA Microchip DataVacc Vacc TestFil AntiPar SterChir Prof GATTO Microchip AnnoN Sesso Razza Taglia Colore Pelo Tatuaggio SegniP Figura 4.4 Rappresentazione grafica dei vincoli d'integrità referenziali di SCHEDA CLINICA Sottoposizione Associazione 1:N tra VISITA e SCHEDA CLINICA. VISITA è un'entità debole ed ha come identificatore l'attributo Data e l'entità SCHEDA CLINICA. L'unico modo per tradurre questa associazione è il seguente: VISITA (Microchip, Data, Diagnosi, Terapia) SCHEDA CLINICA (Microchip, DataVacc, Vacc, TestFil, AntiPar, SterChir, Prof) La chiave di VISITA è costituita dall'attributo Data e dall'identificatore di SCHEDA CLINICA. E' da notare che Microchip è anche chiave di GATTO, cosicché esiste una referenza anche con questo schema di relazione. Tuttavia ciò è introdotto dal fatto che SCHEDA CLINICA e GATTO sono legati da una associazione 1:1. I vincoli di integrità referenziale introdotti dalla traduzione sono rappresentati in Figura 4.5.

24 VISITA Microchip Data Diagnosi Terapia SCHEDA CLINICA Microchip DataVacc Vacc TestFil AntiPar SterChir Prof Figura 4.5 Rappresentazione grafica dei vincoli d'integrità referenziali di VISITA Residenza Associazione 1:N tra GATTO e COMUNE. Entrambe le partecipazioni sono opzionali. Per evitare lo spreco di memoria causato dalla generazione di una terza relazione, accettiamo questa volta l'introduzione di eventuali valori nulli, ottenendo il seguente schema: GATTO (Microchip, AnnoN, Sesso, Razza, Taglia, Colore, Pelo, Tatuaggio, SegniP *, CodCom * ) COMUNE (CodCom, NomeC, Sindaco) Per una migliore leggibilità dello schema è più opportuno modificare il nome dell'attributo referente in GATTO: GATTO (Microchip, AnnoN, Sesso, Razza, Taglia, Colore, Pelo, Tatuaggio, SegniP *, Residenza * ) I vincoli di integrità referenziale introdotti dalla traduzione sono rappresentati in Figura 4.6. GTTO Microchip AnnoN Sesso Razza Taglia Colore Pelo Tatuaggio SegniP Residenza COMUNE CodCom NomeC Sindaco Figura 4.6 Rappresentazione grafica dei vincoli d'integrità referenziali di GATTO Registrazione

25 Associazione 1:N tra ENTRATA e GATTO con un attributo (Medaglia) che indica il numero della medaglia che permette il riconoscimento del gatto all'interno del gattile. La partecipazione di GATTO è opzionale. In questo caso lo schema di GATTO rimane invariato, mentre per ENTRATA otteniamo: ENTRATA (NProg, DataE, ModoE, Segnalatore *, Microchip, Medaglia) I vincoli di integrità referenziale introdotti dalla traduzione sono rappresentati in Figura 4.7. ENTRATA NProg DataE ModoE Segnalatore Microchip Medaglia GATTO Microchip AnnoN Sesso Razza Taglia Colore Pelo Tatuaggio SegniP Residenza Figura 4.7 Rappresentazione grafica dei vincoli d'integrità referenziali di ENTRATA Prelevamento Associazione 1:N tra ENTRATA e OPERATORE. La partecipazione di ENTRATA è opzionale. Per evitare l'introduzione di ulteriori valori nulli, optiamo per il seguente schema: ENTRATA (NProg, DataE, ModoE, Segnalatore *, Microchip, Medaglia) OPERATORE (CodFisc, Cognome, Nome, Indirizzo, Città, Tel, Cell * ) PRELEVAMENTO (NProg, DataE, CodFisc) La chiave di PRELEVAMENTO è costituita solo dall'identificatore di ENTRATA perché le cardinalità dell'associazione ci dicono che ogni gatto può prelevato al più da un solo padrone. Per una migliore leggibilità dello schema è più opportuno modificare i nomi degli attributi referenti nel modo seguente: PRELEVAMENTO (NReg, Data, Operatore) I vincoli di integrità referenziale introdotti dalla traduzione sono rappresentati in Figura 4.8.

26 OPERATORE CodFisc Cognome Nome Indirizzo Città Tel Cell PRELEVAMENTO NReg Data Operatore ENTRATA NProg DataE ModoE Segnalatore Microchip Medaglia Figura 4.8 Rappresentazione grafica dei vincoli d'integrità referenziali di PRELEVAMENTO Ritrovamento Associazione 1:N tra ENTRATA e COMUNE. La partecipazione di COMUNE è opzionale. In questo caso lo schema di COMUNE rimane invariato, mentre ENTRATA acquista un nuovo attributo: ENTRATA (NProg, DataE, ModoE, Comune, Segnalatore *, Microchip, Medaglia) Sempre per motivi di comprensione e leggibilità, l'attributo referente ha mutato il nome da CodCom a Comune e indica il comune in cui il gatto è stato ritrovato. I vincoli di integrità referenziale introdotti dalla traduzione sono rappresentati in Figura 4.9. ENTRATA NProg DataE ModoE Comune Segnalatore Microchip Medaglia COMUNE CodCom NomeC Sindaco Figura 4.9 Rappresentazione grafica dei vincoli d'integrità referenziali di ENTRATA

27 4.3.8 Destinazione Associazione 1:1 tra ENTRATA e USCITA. Quest'ultima è un'entità debole ed ha ENTRATA come unico identificatore esterno. La partecipazione di ENTRATA è opzionale. Poiché entrambi gli schemi delle entità avranno come chiave l'identificatore dell'entità forte, una soluzione potrebbe essere quella di rappresentarli in un unico schema. Tuttavia, per motivi di efficienza citati precedentemente e per evitare l'introduzione di valori nulli, si preferisce mantenere i due schemi distinti. Lo schema di ENTRATA rimane invariato, mentre USCITA è tradotto nel modo seguente: USCITA (NReg, DataEntrata, DataU, ModoU, Note * ) Sempre per motivi di comprensione e leggibilità, gli attributi referenti hanno mutato il nome da NProg e DataE a NReg e DataEntrata. I vincoli di integrità referenziale introdotti dalla traduzione sono rappresentati in Figura USCITA NReg DataEntrata DataU ModoU Note ENTRATA NProg DataE ModoE Comune Segnalatore Microchip Medaglia Figura 4.10 Rappresentazione grafica dei vincoli d'integrità referenziali di ENTRATA Appartenenza Associazione 1:N tra COMUNE e A.S.L. Il modo più conveniente per tradurre questa associazione è il seguente: COMUNE (CodCom, NomeC, Sindaco, A.S.L.) A.S.L.(NA.S.L., Resp, Indirizzo, Città) All'interno dello schema COMUNE, per quanto riguarda l'attributo referente, al nome NA.S.L. è stato preferito semplicemente quello di A.S.L.. I vincoli di integrità referenziale introdotti dalla traduzione sono rappresentati in Figura 4.11.

28 COMUNE CodCom NomeC Sindaco A.S.L. A.S.L. NA.S.L. Resp Indirizzo Città Figura 4.11 Rappresentazione grafica dei vincoli d'integrità referenziali di COMUNE Conclusioni Abbiamo così terminato il processo di traduzione e lo schema logico relazionale risultante è riportato di seguito. GATTO (Microchip, AnnoN, Sesso, Razza, Taglia, Colore, Pelo, Tatuaggio, SegniP *, Residenza * ) PROPRIETA' (Gatto, Padrone, DataReg) PADRONE (CodFisc, Cognome, Nome, Indirizzo, Città, Tel, Cell * ) SCHEDA CLINICA (Microchip, DataVacc, Vacc, TestFil, AntiPar, SterChir, Prof) VISITA (Microchip, Data, Diagnosi, Terapia) COMUNE (CodCom, NomeC, Sindaco, A.S.L.) A.S.L. (NA.S.L., Resp, Indirizzo, Città) ENTRATA (NProg, DataE, ModoE, Comune, Segnalatore *, Microchip, Medaglia) PRELEVAMENTO (NReg, Data, Operatore) OPERATORE (CodFisc, Cognome, Nome, Indirizzo, Città, Tel, Cell * ) USCITA (NReg, DataEntrata, DataU, ModoU, Note * )

29 4.4 Verifica di normalizzazione Uno schema di relazione R è in forma normale di Boyce e Codd se per ogni dipendenza funzionale (non banale) X Y definita su di essa, X è superchiave per R. Lo schema di base di dati ottenuto non presenta alcuna dipendenza funzionale che non soddisfi la forma normale di Boyce e Codd. Inoltre gli attributi delle relazioni sono definiti su valori atomici e non su valori complessi. Quindi possiamo concludere che tutti gli schemi soddisfano la condizione di prima forma normale, di BCNF e, di conseguenza, di seconda e terza forma normale.

30 5. PROGETTAZIONE FISICA Ora seguirà la formulazione in SQL dello schema della Base di Dati, dei vincoli di integrità, e dì alcune interrogazioni previste nella fase di analisi dei requisiti funzionali. L'omissione della dichiarazione di alcuni vincoli d'integrità indica che si assumono validi i valori di default. 5.1 Definizione dello schema di base di dati create schema gattile; start schema gattile; 5.2 Definizione delle tabelle GATTO: create table GATTO ( Microchip char (20) primary key, AnnoN char (10), Sesso char (1), Razza char (20), Taglia char (10), Colore char (15), Pelo char (15), Tatuaggio char (20), ) SegniP Residenza char (50) default nessuno, char (5) default sconosciuta references Comune (CodCom), PROPRIETA': create table Proprietà ( Gatto ) Padrone DataReg char (20) primary key references Gatto (Microchip), char (16) not null references Padrone (CodFisc), date

31 PADRONE: create table Padrone ( CodFisc Cognome ) Nome Indirizzo char (50), Città char (20), Tel char (20), Cell char (20) char (16) primary key, char (20) not null, char (20) not null, SCHEDA CLINICA: create table Scheda Clinica ( Microchip char (20) primary key references Gatto (Microchip), DataVacc date, Vacc char (20), TestFil char (10), AntiPar char (20), SterChir char (2), Prof char (10) ) VISITA: create table Visita ( Microchip char (20) references Gatto (Microchip), Data date, Diagnosi char (50), Terapia char (50), primary key (Microchip, Data) )

32 COMUNE: create table Comune ( CodCom NomeC Sindaco A.S.L. ) char (5) primary key, char (20), char (40), char (2) referencesa.s.l. (N A.S.L.) A.S.L.: create table A.S.L. ( N A.S.L. Resp Indirizzo Città ) char (2) primary key, char (40), char (50), char (20) ENTRATA: create table Entrata ( N Prog DataE ModoE Comune ) Segnalatore Microchip Medaglia primary key (N Prog, DataE) char (5), date, char (15), char (5) not null references Comune (CodCom), char (40), char (20), char (5),

33 PRELEVAMENTO: create table Prelevamento ( N Reg char (20), ) Data Operatore date, char (16) not null references Operatore (CodFisc), primary key (N Reg, Data), foreign key (N Reg, Data) references Entrata (N Prog, DataE) OPERATORE: create table Operatore ( CodFisc Cognome Nome Indirizzo Città Tel Cell ) char (16) primary key, char (20) not null, char (20) not null, char (50), char (20), char (20), char (20) USCITA: create table Uscita ( N Reg DataEntrata DataU ModoU Note ) char (5), date, date, char (15), char (50), primary key (N Reg, DataEntrata), foreign key (N Reg, DataEntrata) references Entrata (N Prog, DataE)

34 5.3 Formulazione delle interrogazioni Per quanto riguarda le operazioni di inserimento, modifica e cancellazione, è riportata solo la sintassi, mentre le interrogazioni sono svolte interamente. Per permettere la formulazione delle operazioni interattive, sono state introdotte variabili parametriche nelle quali saranno inseriti i dati d'ingresso. Operazione n 1: insert into Gatt [ Microchip, AnnoN, Sesso, Razza, Taglia, Colore, Pelo, Tatuaggio, SegniP, Residenza] < values ( ListaDiValori ) > Operazione n 2: update NomeTabella [ ListaAttributi ] set Attributo = ValoreAttr [ where Condizione ] Operazione n 3: select * from Gatto G inner join (Scheda Clinica) SC on C.Microchip = SC.Microchip where C.Microchip = [Numero Microchip:]; Operazione n 4: select * from Gatto where Microchip = NumMicrochip; Operazione n 5: select * from (Gatto G inner join Proprietà Pr on C.Microchip = Pr.Gatto) inner join Padrone P on Pr.Padrone = P.CodFisc where P.Nome = [Inserire Nome:] and P.Cognome [Inserire Cognome:]; Operazione n 6: select * from Entrata where datepart("yyyy",datae) = Anno;

35 Operazione n 7: select * from Entrata as E left outer join Uscita as U on (E.NProg = U.NReg and E.DataE = U.DataEntrata) where not exists (select NReg, DataEntrata from Uscita as U where E.NProg = U.NReg and E.DataE = U.DataEntrata); Operazione n 8: select * from (Entrata as E left outer join Uscita as U on E.NProg = U.NReg and E.DataE = U.DataEntrata) left outer join Proprietà as P on E.Microchip = P.Gatto where not exists (select NReg, DataEntrata from Uscita as U where E.NProg = U.NReg and E.DataE = U.DataEntrata) and E.Microchip not in (select Gatto from Proprietà); Operazione n 9: select * from Entrata where DataE = [Inserire Data:]; Operazione n 10: select * from Gatto where Razza = [Inserire Razza:]; Operazione n 11: select count(*) from Gatto where Razza = [Inserire Razza:]; Operazione n 12: select count(*) as NGattiCarico from Entrata as E left outer join Uscita as U on (E.NProg = U.NReg and E.DataE = U.DataEntrata) where not exists (select NReg, DataEntrata from Uscita as U where E.NProg = U.NReg and E.DataE = U.DataEntrata);

36 Operazione n 13: select count(*) as NRandagi from (Entrata as E left outer join Uscita as U on E.NProg = U.NReg and E.DataE = U.DataEntrata) left outer join Proprietà as P on E.Microchip = P.Gatto where not exists (select NReg, DataEntrata from Uscita as U where E.NProg = U.NReg and E.DataE = U.DataEntrata) and E.Microchip not in (select Gatto from Proprietà); Operazione n 14: SELECT count(*) as NMicrochip FROM Entrata E left outer join Proprietà P ON E.Microchip = P.Gatto where E.DataE >= DataInizio and E.DataE < DataFine and E.Microchip not in (select Gatto from Proprietà); Operazione n 15: select Comune, E.NProg, E.DataE, U.DataU from (Entrata as E left outer join Uscita as U on (E.DataE = U.DataEntrata) and (E.NProg = U.NReg)) left outer join Proprietà as Pr on Pr.Gatto = E.Microchip where (U.DataU > DataInizio or (not exists (select O.NReg, O.DataEntrata from Uscita O where O.NReg = E.Nprog and O.DataEntrata = E.DataE))) and E.DataE <= DataFine and (E.Microchip not in (select Gatto from Proprietà as P where P.DataReg <> U.DataU)) group by Comune, E.NProg, E.DataE, U.DataU order by Comune; Operazione n 16: select * from Comune; Operazione n 17: insert into (Scheda Clinica) [ Microchip, DataVacc, Vacc, TestFil, AntiPar, SterChir, Prof ] < values ( ListaDiValori ) >

37 Operazione n 18: select * from Operatore where CodFisc = [Codice Fiscale:]; Operazione n 20: Vista la complessità di questa interrogazione, è più opportuno dividerla in più query. Query20a: restituisce il numero di prestazioni di smaltimento di gatti randagi morti raggruppate per comune. select E.Comune, Count(*) as Smaltimenti from (Uscita as U inner join Entrata as E on (U.DataEntrata = E.DataE) and (U.NReg = E.NProg)) left join Proprietà on E.Microchip = Proprietà.Gatto where ([DataInizio] <= U.DataU) and ([DataFine] > U.DataU) and (U.ModoU = 'deceduto') and ((E.Microchip) Not In (select Gatto from Proprietà)) group by E.Comune; Query20b: restituisce il numero di prestazioni di cattura e trasporto di gatti randagi raggruppate per comune. select E.Comune, count(*) as NumTrasporti from (Entrata as E inner join Prelevamento as Pv on (E.DataE = Pv.Data) and (E.NProg = Pv.NReg)) left join Proprietà on E.Microchip = Proprietà.Gatto where ([DataInizio] <= E.DataE and E.DataE < [DataFine]) and (E.Microchip) Not In (select Gatto from Proprietà) group by E.Comune; Query20c: restituisce il numero di prestazioni veterinarie di gatti randagi raggruppate per comune. select E.Comune, count(*) as PrestVeter from ([Scheda Clinica] as SC inner join Entrata as E on SC.Microchip = E.Microchip) left join Proprietà on E.Microchip = Proprietà.Gatto where ([DataInizio] <= SC.DataVacc and SC.DataVacc < DataFine) and (E.Microchip) Not In (select Gatto from Proprietà) group by E.Comune;