Progetto Basi Di Dati Gattile

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

INDICE
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
1. INTRODUZIONE .................................................................................................................... 2
2. ANALISI DEI REQUISITI ..................................................................................................... 3
2.1 Descrizione del problema ....................................................................................................... 3
2.2 Specifiche sulle operazioni ..................................................................................................... 4
3. PROGETTAZIONE CONCETTUALE ................................................................................. 6
3.1 Schema concettuale secondo il modello Entità-Relazione .................................................. 6
3.1.1 Anagrafe felina ................................................................................................................ 6
3.1.2 Gattile ............................................................................................................................... 9
3.1.3 Integrazione di schemi ...................................................................................................... 12
3.2 Vincoli di integrità dei dati .................................................................................................... 16
3.3 Analisi di qualità ..................................................................................................................... 16
4. PROGETTAZIONE LOGICA ............................................................................................... 17
4.1 Analisi delle prestazioni ......................................................................................................... 17
4.2 Ristrutturazione dello schema E-R ....................................................................................... 18
4.2.1 Analisi delle ridondanze ed Eliminazione delle gerarchie ............................................... 18
4.2.2 Partizionamento/accorpamento di concetti ....................................................................... 19
4.2.3 Eliminazione di attributi composti .................................................................................... 19
4.2.4 Scelta degli identificatori principali .................................................................................. 19
4.3 Traduzione verso il modello relazionale ............................................................................... 21
4.3.1 Proprietà ............................................................................................................................ 21
4.3.2 Rilevazione ....................................................................................................................... 22
4.3.3 Sottoposizione ................................................................................................................... 22
4.3.4 Residenza .......................................................................................................................... 23
4.3.5 Registrazione .................................................................................................................... 24
4.3.6 Prelevamento .................................................................................................................... 24
4.3.7 Ritrovamento .................................................................................................................... 25
4.3.8 Destinazione ..................................................................................................................... 26
4.3.9 Appartenenza .................................................................................................................... 26
4.3.10 Conclusioni ..................................................................................................................... 27
4.4 Verifica di normalizzazione ................................................................................................... 28
5. PROGETTAZIONE FISICA .................................................................................................. 29
5.1 Definizione dello schema della base di dati .......................................................................... 29
5.2 Definizione delle tabelle ......................................................................................................... 29
5.3 Formulazione delle interrogazioni ........................................................................................ 32

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.

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:

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,

gattile. Data e modo di entrata,
Eventuale segnalatore,
Comune Comune di provenienza del
gatto. Il costo giornaliero e
del microchip dei gatti
randagi è a suo carico.
.
Data e modo di uscita
Codice del comune,
Nome,
Sindaco
A.S.L. A.S.L.alla quale appartiene il Numero AS.L.,
comune. Si occupa delle Responsabile,
spese sanitarie, di trasporto e Indirizzo,
di smaltimento di ciascun gatto.
Città
Padrone Proprietario delgatto.
Provvede alle spese di
mantenimento e del
microchip del proprio gatto.
Visita Esito della visita veterinaria
cui viene sottoposto
periodicamente ciascun gatto.
Operatore Accalappiagatti che preleva il
gatto. Attualmente sono
quattro.
Figura 1.1 Glossario dei termini
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

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
Figura 3.1 Schema scheletro
GATTO proprietà PADRONE
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).
3.1.1 Anagrafe Felina
COMUNE
residenza
Figura 3.2 schema scheletro Anagrafe Felina
GATTO proprietà PADRONE
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

Poiché ciascun gatto viene periodicamente sottoposto a visite veterinarie, è necessario rappresentare
nello schema la nuova entità VISITA (Trasformazione T1 bottom-up) che appare in Figura 3.3.
Figura 3.2 schema scheletro Anagrafe Felina
COMUNE
Secondo raffinamento
residenza
GATTO
proprietà
PADRONE
sottoposizione VISITA
Ora si possono aggiungere a ciascuna entità e a ciascuna relazione i rispettivi dati sotto forma di
attributi (Trasformazioni T5 e T6 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
Sanitari DataVacc
Vacc
AntiPar
TestFil
SterChir
Prof
Figura 3.4 Tabella dei dati riferiti all'entità Gatto
Terzo raffinamento
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
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 T1 top-down):
1. la prima, che manterrà il nome di quella di origine, aggrega i dati anagrafici;

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
Sindaco
NomeC
CodCom
3.1.2 Gattile
residenza
Colore
Pelo
(1,1) (0,N)
Figura 3.5 schema finale Anagrafe Felina
Via
N°
Indirizzo
Città
AnnoN
Sesso
Razza
Taglia
GATTO rilevazione
(1,1)
proprietà
(1,N)
PADRONE
Microchip
Tatuaggio
SegniP
(0,1)
(1,1) (1,1)
DataReg
CodFisc Cognome
Nome
COMUNE ritrovamento Gatto
(0,1)
Tel
Cell
Data
Diagnosi
Terapia
DataVacc
AntiPar
Vacc
SCHEDA
CLINICA
(1,N)
sottoposizione
(1,1)
TestFil
SterChir
Prof
VISITA

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 T1 bottom-up), come si può
vedere in Figura 3.7.
A.S.L.
appartenenza
Gatto prelevamento OPERATORE
ritrovamento
COMUNE
Figura 3.7 risultato del primo raffinamento dello schema Gattile
Secondo raffinamento
Nell'aggiungere i dati sotto forma di attributi (Trasformazioni T5 e T6) 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

Entrata NProg
DataEnt
ModoE
Segnalatore
Uscita DataU
ModoU
Note
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)
Numero di registro
Data di entrata al gattile
Modo d'entrata (randagio/consegnato/pericoloso)
Eventuale nome della persona che ha chiamato
l'accalappiagatti
Figura 3.8 Tabella dei dati riferiti all'entità GATTO
Terzo raffinamento
Data di uscita dal gattile
Modo di uscita (decesso/rifugio/affidamento/riscatto)
Note o causa dell'eventuale morte
Sempre ai fini di ottenere una base di dati più efficiente si può ancora suddividere verticalmente
l'entità GATTO in tre entità (Trasformazione T1 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à.

USCITA
(1,1)
destinazione
Note (0,1)
(0,1) (0,1)
(0,1)
ModoU
DataU
Via
N°
Indirizzo Città
Nome CodFisc
Cognome
A.S.L.
NA.S.L.
Resp
(N,M)
Città
Indirizzo
Via
N°
NProg
DataEnt
ModoE
Segnalatore
appartenenza
(0,1)
(1,1)
Figura 3.9 schema finale Gattile
3.1.3 Integrazione di schemi
(1,1)
prelevamento
(1,1)
Medaglia
(1,N)
Tel
Cell
(0,N)
OPERATORE
ENTRATA registrazione GATTO
Pelo
ritrovamento
(0,N)
COMUNE
Sindaco
NomeC
CodCom
Colore
Taglia
Razza
(0,1)
SegniP
Sesso
Tatuaggio
AnnoN Microchip
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).

OPERATORE prelevamento
USCITA
A.S.L.
destinazione
appartenenza
ENTRATA registrazione GATTO
ritrovamento
COMUNE
residenza
Figura 3.10 fusione dei due schemi (priva di attributi)
Ultimo raffinamento
rilevazione
SCHEDA
CLINICA
sottoposizione
VISITA
proprietà
PADRONE
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 T2 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.

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

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 PRIVATO (1,1)
comune in cui risiede. COMUNE (0,N)
Ritrovamento Associa un gatto entrato al ENTRATA (1,1)
gattile al comune in cui è
stato ritrovato.
COMUNE (0,N)
Appartenenza Associa un comune all'A.S.L. COMUNE (1,1)
di cui fa parte.
A.S.L. (N,M)
Registrazione Associa un gatto alla voce di GATTO (0,N)
Medaglia
registro che ne dichiara
l'entrata al gattile.
ENTRATA (1,1)
Prelevamento Associa la voce di registro di OPERATORE (N,M)
un gatto all'operatore che lo
ha prelevato.
ENTRATA (0,1)
Rilevazione Associa un gatto alla propria GATTO (1,1)
scheda clinica.
SCHEDA CLINICA (1,1)
Sottoposizione Associa la scheda clinica di SCHEDA CLINICA (1,N)
un gatto ad una visita
veterinaria.
VISITA (1,1)
Destinazione Associa un gatto alla sua GATTO (0,1)
scheda esito.
USCITA (1,1)
Figura 3.12 Dizionario dei dati delle associazioni

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.

4. PROGETTAZIONE LOGICA
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
4.1 Analisi delle prestazioni
Tavola dei volumi
Concetto Tipo Volume
GATTO E 22000
RANDAGIO E 50
PRIVATO E 21950
PADRONE E 21950
ENTRATA E 750/anno
COMUNE E 95
A.S.L. E 3
SCHEDA CLINICA E 22000
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
Figura 4.1 Tavole dei volumi e delle operazioni
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
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.

4.2 Ristrutturazione dello schema E-R
Per semplificare la traduzione verso il modello logico sarà necessario riorganizzare e ottimizzare lo
schema concettuale.
4.2.1 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à.
4.2.2 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.

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".
4.2.4 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.

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.
4.3.1 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
PROPRIETA’
Gatto Padrone
GATTO
Microchip AnnoN Sesso Razza
Indirizzo Città Tel Cell
DataReg
Taglia Colore Pelo Tatuaggio SegniP
Figura 4.3 Rappresentazione grafica dei vincoli d'integrità referenziali di PROPRIETA'
4.3.2 Rilevazione

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.
GATTO
SCHEDA CLINICA
Microchip DataVacc Vacc TestFil AntiPar SterChir Prof
Microchip AnnoN Sesso Razza Taglia Colore Pelo Tatuaggio SegniP
Figura 4.4 Rappresentazione grafica dei vincoli d'integrità referenziali di SCHEDA CLINICA
4.3.3 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.

VISITA
Microchip
SCHEDA CLINICA
Microchip DataVacc
Data Diagnosi Terapia
Vacc TestFil AntiPar SterChir Prof
Figura 4.5 Rappresentazione grafica dei vincoli d'integrità referenziali di VISITA
4.3.4 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
4.3.5 Registrazione

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
4.3.6 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.

OPERATORE
ENTRATA
CodFisc Cognome Nome Indirizzo
PRELEVAMENTO
NReg Data Operatore
NProg DataE ModoE Segnalatore
Città Tel Cell
Microchip Medaglia
Figura 4.8 Rappresentazione grafica dei vincoli d'integrità referenziali di PRELEVAMENTO
4.3.7 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

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 4.10.
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
4.3.9 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.

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
4.3.10 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 * )

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.

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 char (50) default nessuno,
Residenza char (5) default sconosciuta
references Comune (CodCom),
)
• PROPRIETA':
create table Proprietà
(
Gatto char (20) primary key
references Gatto (Microchip),
Padrone char (16) not null
references Padrone (CodFisc),
DataReg date
)

• PADRONE:
create table Padrone
(
CodFisc char (16) primary key,
Cognome char (20) not null,
Nome char (20) not null,
Indirizzo char (50),
Città char (20),
Tel char (20),
Cell char (20)
)
• 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)
)

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

• PRELEVAMENTO:
create table Prelevamento
(
N°Reg char (20),
Data date,
Operatore 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
)
• USCITA:
create table Uscita
(
N°Reg
DataEntrata
DataU
ModoU
)
Note
char (16) primary key,
char (20) not null,
char (20) not null,
char (50),
char (20),
char (20),
char (20)
char (5),
date,
date,
char (15),
char (50),
primary key (N°Reg, DataEntrata),
foreign key (N°Reg, DataEntrata)
references Entrata (N°Prog, DataE)

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;

• 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);

• 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

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 (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]