UNIVERSITÁ DEGLI STUDI DI PADOVA DIPLOMA IN INGEGNERIA INFORMATICA
Tesina per il corso di Basi di Dati
PROGETTO DI UNA BASE DI DATI PER LA GESTIONE DI UN
CANILE COMUNALE
Studente : Sanson Annalisa Docente : Prof. G. Gradenigo
IINNDDIICCEE ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ 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 canina ................................................................................................................ 6 3.1.2 Canile ................................................................................................................................ 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 ALLEGATI .................................................................................................................................... 37
1. IINNTTRROODDUUZZIIOONNEE ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Il canile sanitario è il luogo in cui sono raccolti e mantenuti dalla Provincia tutti quei cani 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 ULSS
si occupa di registrare i dati anagrafici di tutti i cani di proprietà residenti nei comuni associati. Così, chiunque possieda un cane è 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 canina, ciascun cane viene identificato univocamente mediante microchip, cosicché sia sempre possibile rintracciarne il padrone.
Tuttavia non tutti i cani raccolti dal canile 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 canile.
La realtà presa in considerazione per lo sviluppo della seguente base di dati comprende una Unità
Locale Socio Sanitaria che si occupa dell'anagrafe canina e nella cui sede si trova anche il canile sanitario della provincia.
Si tratta quindi di analizzare due realtà diverse ma strettamente correlate fra loro:
A. la gestione dell'anagrafe canina: - attribuzione del microchip al cane; - registrazione dei dati del padrone; - compilazione della scheda clinica; - prestazioni veterinarie;
B. la gestione del canile:
- entrate/uscite dei cani dal canile; - iscrizione all'anagrafe; - organizzazione delle spese di mantenimento; - prestazioni degli operatori (accalappiacani).
L'introduzione di un programma applicativo semplificherebbe notevolmente il lavoro dell'amministratore del canile, ora costretto a compilare a mano tutti i documenti da inviare ai Comuni e alle Ulss. A questi enti, infatti, devono essere spedite periodicamente schede di riepilogo sulle presenze di cani randagi al canile e sulle prestazioni di Igiene Pubblica Veterinarie e/o di assistenza zooiatrica effettuate, ai fini di richiederne il rimborso spese previsto.
2. AANNAALLIISSII DDEEII RREEQQUUIISSIITTII ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ 2.1 Descrizione del problema Si vuole automatizzare l'organizzazione interna di un canile sanitario per ottenere la gestione completa dei seguenti aspetti: • la registrazione dei dati anagrafici e clinici dei cani; • la registrazione dei dati di entrata/uscita dei cani raccolti dal canile;
• le visite veterinarie cui vengono sottoposti;
• le spese di sostentamento del cane in relazione a coloro che le sosterranno (padrone, Comune,
U.L.S.S.);
• l'intervento dei quattro operatori (accalappiacani);
Attualmente esiste già un programma applicativo che gestisce esclusivamente l'anagrafe canina, ma si è rivelato insufficiente alle esigenze dell'utente, l'amministratore interno; infatti il software, oltre a non occuparsi dell'amministrazione delle spese, non prevede la registrazione né dei dati clinici, né di quelli di entrata/uscita del cane dal canile. Di conseguenza la maggior parte dei documenti e delle schede si trovano ancora su materiale cartaceo: il registro (vedi allegato A), sul quale viene segnalato ciascun cane che entra al canile per mezzo di un
numero progressivo preceduto da una lettera indicante l'anno (si presuppone che un cane non viva più di 25 anni, numero pari alle lettere dell'alfabeto, oltre i quali si potrà riattribuire lo stesso codice ad un altro cane); qui saranno rilevati i dati principali del cane: data e modo di entrata (randagio, consegnato, morsicatore), 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 cane (vedi allegato B), 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 cane che può essere: riscattato, ceduto, eliminato, morsicatore ritirato o morto (la causa dovrà essere specificata).
la scheda di riepilogo presenze di cani nel canile (vedi allegato C), 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 al nuovo software la gestione delle spese alle quali va incontro il canile. Quelle di cattura, trasporto, vaccinazione, sterilizzazione, smaltimento animali morti, ecc., saranno sostenute dall'U.L.S.S. di cui fa parte il comune di provenienza del cane (vedi allegato D), mentre per quanto riguarda il suo mantenimento esiste una distinzione basata sui diversi modi di entrata al canile:
a) può essere raccolto dall'accalappiacani sotto segnalazione o abbandonato alle porte del canile.
Se nessuno ne reclamerà lo smarrimento, il cane sarà considerato randagio e le spese riguardanti il suo sostentamento e il costo del microchip (£ 15.500) graveranno sul comune di provenienza (costo giornaliero £ 5.000). Al costo dei cani abbandonati nel comune di residenza del canile stesso contribuiscono tutti gli altri comuni con una quota aggiuntiva di £ 5.000.
b) può essere consegnato dal padrone stesso perché non più in grado di occuparsene. In questo caso e in quello in cui un cane randagio venga riscattato, il costo del microchip (£ 25.500) e quello giornaliero, che ammonta a £ 10.000 per i primi 5 giorni e a £ 5.000 per i giorni successivi, sono a carico del proprietario.
c) può essere segnalato come morsicatore.
Qui vale la stessa distinzione fatta fra cane 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 cane. Op. 2 : Modifica dei dati di un cane. Op. 3 : Visualizzazione/Stampa dei dati di un cane (anagrafici, sanitari, di entrata/uscita). Op. 4 : Ricerca di un cane tramite microchip. Op. 5 : Ricerca di un cane tramite il nome del padrone (il risultato può essere multiplo). Op. 6 : Lista complessiva dei cani entrati al canile in un certo anno. Op. 7 : Lista dei cani attualmente in carico. Op. 8 : Lista dei cani randagi attualmente in carico. Op. 9 : Lista dei cani entrati in una certa data. Op. 10 : Lista dei cani di una certa razza. Op. 11 : Visualizzazione del numero di cani di una certa razza. Op. 12 : Visualizzazione del numero di cani in carico. Op. 13 : Visualizzazione del numero di cani randagi in carico. Op. 14 : Visualizzazione del numero di microchip assegnati in un periodo a cani randagi. Op. 15 : Visualizzazione delle date di Entrata e di Uscita dei cani randagi presenti al canile 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 cani. Op. 20 : Conteggio e tipo (sanitaria, di trasporto o di smaltimento) delle prestazioni a carico di ciascuna
Ulss in un periodo. Termine Descrizione Dati Collegamenti Cane Cane registrato all'anagrafe.
Può essere randagio o privato.
Anagrafici, Clinici
Comune, Padrone, Visita
Entrata/Uscita Dati dei cani raccolti dal Numero di registro, Cane,
canile. Data e modo di entrata, Eventuale segnalatore, Data e modo di uscita
Operatore, Comune
Comune Comune di provenienza del cane. Il costo giornaliero e del microchip dei cani randagi è a suo carico.
Codice del comune, Nome, Sindaco
Cane, ULSS
ULSS ULSS alla quale appartiene il comune. Si occupa delle spese sanitarie, di trasporto e di smaltimento di ciascun cane.
Numero U.L.S.S., Responsabile, Indirizzo, Città
Comune
Padrone Proprietario del cane. Provvede alle spese di mantenimento e del microchip del proprio cane.
Codice fiscale, Cognome, Nome, Indirizzo, Residenza, Telefono, Cellulare
Cane
Visita Esito della visita veterinaria cui viene sottoposto periodicamente ciascun cane.
Data, Esami, Diagnosi, Terapia,
Cane
Operatore Accalappiacani che preleva il cane. Attualmente sono quattro.
Cognome, Nome, Indirizzo, Città
Cane
Figura 1.1 Glossario dei termini
3. PPRROOGGEETTTTAAZZIIOONNEE CCOONNCCEETTTTUUAALLEE ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ 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à CANE, PADRONE e COMUNE, rappresenta i concetti principali. Tra queste entità esistono delle relazioni che descrivono il comune di provenienza dei cani e la proprietà dello stesso da parte di un 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 canina (Figura 3.2), l'altro alla gestione del canile (Figura 3.6).
3.1.1 Anagrafe Canina
Figura 3.2 schema scheletro Anagrafe Canina
Lo schema scheletro differisce da quello iniziale solo per una modifica: la relazione che lega CANE a
COMUNE è diventata residenza e indica il comune in cui vive il cane dichiarato all'anagrafe.
Primo raffinamento
CANECANE proprietàproprietà PADRONEPADRONEprovenienzaprovenienzaCOMUNECOMUNE
CANECANE proprietàproprietà PADRONEPADRONEresidenzaresidenzaCOMUNECOMUNE
Poiché ciascun cane 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 Canina
Secondo raffinamento
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à CANE possono essere raggruppati in due classi relative all'anagrafe canina 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 cui vengono elencati i segni particolari)
Sanitari DataVacc Vacc AntiPar TestFil SterChir Prof
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)
Figura 3.4 Tabella dei dati riferiti all'entità CANE
Terzo raffinamento
Per ottenere una base di dati più efficiente si può quindi suddividere verticalmente l'entità CANE in due entità (Trasformazione T1 top-down):
1. la prima, che manterrà il nome di quella di origine, aggrega i dati anagrafici;
CANECANE
proprietàproprietà
PADRONEPADRONE
sottoposizionesottoposizione VISITAVISITAresidenzaresidenzaCOMUNECOMUNE
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 CANE dalla relazione 1:1 rilevazione. • Ora è possibile tracciare la prima parte dello schema E-R (Figura 3.5) completo di attributi, identificatori e cardinalità.
Figura 3.5 schema finale Anagrafe Canina 3.1.2 Canile
CANECANEritrovamentoritrovamentoCOMUNECOMUNE
CANECANE rilevazionerilevazione SCHEDACLINICASCHEDACLINICAresidenzaresidenzaCOMUNECOMUNE
proprietàproprietà
PADRONEPADRONE
sottoposizionesottoposizione
VISITAVISITA
MicrochipAnnoNSesso
RazzaTaglia
TatuaggioSegniP
(0,1)Colore
Pelo
CodComNomeC
SindacoDataReg
(1,1) (0,N)
(1,1)
(1,1) (1,1)
(1,N)
(1,N)
(1,1)
TestFilAntiParVacc
DataVaccSterChir
Prof
Data
Terapia
Diagnosi
CodFisc CognomeNome
Città
IndirizzoN°
Via
Cell
Tel
(0,1)
Figura 3.6 schema scheletro Canile
In questo caso lo schema scheletro è costituito dalle sole entità CANE e COMUNE, legate dalla
relazione ritrovamento che indica il comune in cui il cane è stato raccolto dall'accalappiacani 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
accalappiacani che hanno provveduto all'eventuale prelevamento dell'animale. Inoltre, poiché l'ULSS di appartenenza del comune da cui proviene il cane 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.
Figura 3.7 risultato del primo raffinamento dello schema Canile
Secondo raffinamento
Nell'aggiungere i dati sotto forma di attributi (Trasformazioni T5 e T6) ci accorgiamo nuovamente che
i numerosi dati riferiti all'entità cane 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
CANECANE prelevamentoprelevamento OPERATOREOPERATORE
appartenenzaappartenenza
ritrovamentoritrovamento
COMUNECOMUNEULSSULSS
Razza Taglia Colore Pelo Tatuaggio SegniP
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)
Entrata NProg DataEnt ModoE Segnalatore
Numero di registro Data di entrata al canile Modo d'entrata (randagio/consegnato/morsicatore) Eventuale nome della persona che ha chiamato l'accalappiacani
Uscita DataU ModoU Note
Data di uscita dal canile Modo di uscita (decesso/rifugio/affidamento/riscatto) Note o causa dell'eventuale morte
Figura 3.8 Tabella dei dati riferiti all'entità CANE
Terzo raffinamento
Sempre ai fini di ottenere una base di dati più efficiente si può ancora suddividere verticalmente l'entità CANE 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 canile 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 cani attualmente accolti dal canile 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à CANE dalla relazione 1:N registrazione (uno stesso cane
può smarrirsi ed essere raccolto dal canile 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à.
Figura 3.9 schema finale Canile
3.1.3 Integrazione di schemi Ora è possibile fondere i due schemi ottenuti sovrapponendo le entità rispettivamente omonime
CANE e COMUNE ed eventualmente modificando le cardinalità dove opportuno (Figura 3.10).
Note (0,1)
DataU ModoU
Cell
ENTRATAENTRATA registrazioneregistrazione CANECANE
appartenenzaappartenenza
ritrovamentoritrovamento
COMUNECOMUNEULSSULSS
USCITAUSCITA destinazionedestinazione OPERATOREOPERATOREprelevamentoprelevamento
Pelo
SessoRazza
Taglia
Tatuaggio
SegniP(0,1)
Colore
MicrochipAnnoN
Medaglia
CodCom
NomeC
Sindaco
Città Indirizzo N°
Via
NUlss
Resp
(1,1)
(0,1) (0,1)
(1,N)
(1,1) (0,N)
(1,1)
(0,N)
(1,1)(N,M)
NProgDataEnt
ModoE
Segnalatore(0,1)
CittàIndirizzo Via
N°Nome
CognomeCodFisc
Tel
(0,1)
Figura 3.10 fusione dei due schemi (priva di attributi)
Ultimo raffinamento
Fondamentale per la gestione delle spese di sostentamento è la distinzione fra cani randagi e cani di
proprietà. Questo scopo può essere facilmente raggiunto con l'introduzione di una generalizzazione (Trasformazione T2 top-down) totale ed esclusiva in cui CANE è l'entità padre e le due entità figlie RANDAGIO e PRIVATO specificano rispettivamente se si tratta di un cane 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.
ENTRATAENTRATA registrazioneregistrazione CANECANEdestinazionedestinazioneUSCITAUSCITA
OPERATOREOPERATORE prelevamentoprelevamento
ritrovamentoritrovamento
COMUNECOMUNEappartenenzaappartenenzaULSSULSS
SCHEDACLINICASCHEDACLINICArilevazionerilevazione
sottoposizionesottoposizione
VISITAVISITA
proprietàproprietà
PADRONEPADRONE
residenzaresidenza
Entità Descrizione Attributi Identificatore CANE Cane che viene registrato
all'anagrafe canina. Entità padre.
Microchip, AnnoN, Sesso, Razza, Taglia, Colore, Pelo, Tatuaggio, SegniP (0,1)
Microchip
RANDAGIO Cane senza padrone. Entità figlia.
v. entità padre
PRIVATO Cane di proprietà. Entità figlia.
v. entità padre
PADRONE Proprietario di un cane privato.
CodFisc, Cognome, Nome, Indirizzo (Via, N°), Città, Tel, Cell (0,1)
CodFisc
COMUNE Comune di residenza o di ritrovamento di un cane.
CodCom, NomeC, Sindaco CodCom
ULSS Ulss cui appartiene il comune.
NUlss, Resp, Indirizzo (Via, N°), Città
NUlss
ENTRATA Raccolta dei dati del cane relativi all'entrata al canile.
NProg, DataEnt, ModoE, Segnalatore (0,1)
NProg, DataEnt
OPERATORE Accalappiacani. CodFisc, Cognome, Nome, Indirizzo (Via, N°), Città, Tel, Cell (0,1)
CodFisc
SCHEDA CLINICA Raccolta dei dati sanitari del cane.
Vacc, DataVacc, AntiPar, TestFil, SterChir, Prof
Cane
USCITA Raccolta dei dati riguardanti la destinazione raggiunta dal cane.
DataU, ModoU, Note (0,1) Entrata
VISITA Visita veterinaria a cui il cane viene sottoposto.
Data, Esami, Diagnosi, Terapia
Data, Scheda Clinica
Figura 3.11 Dizionario dei dati delle entità
Relazione Descrizione Entità coinvolte Attributi Proprietà Associa un cane privato al
suo padrone. PRIVATO (1,1) PADRONE (1,N)
DataReg
Residenza Associa un cane privato al comune in cui risiede.
PRIVATO (1,1) COMUNE (0,N)
Ritrovamento Associa un cane entrato al canile al comune in cui è stato ritrovato.
ENTRATA (1,1) COMUNE (0,N)
Appartenenza Associa un comune all'Ulss di cui fa parte.
COMUNE (1,1) ULSS (N,M)
Registrazione Associa un cane alla voce di registro che ne dichiara l'entrata al canile.
CANE (0,N) ENTRATA (1,1)
Medaglia
Prelevamento Associa la voce di registro di un cane all'operatore che lo ha prelevato.
OPERATORE (N,M) ENTRATA (0,1)
Rilevazione Associa un cane alla propria scheda clinica.
CANE (1,1) SCHEDA CLINICA (1,1)
Sottoposizione Associa la scheda clinica di un cane ad una visita veterinaria.
SCHEDA CLINICA (1,N) VISITA (1,1)
Destinazione Associa un cane alla sua scheda esito.
CANE (0,1) 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 cane con lo stesso microchip. (RV4) Non può essere registrato più di un cane con lo stesso numero progressivo nello stesso anno. (RV5) Non è possibile inserire i dati sanitari di un cane non registrato all'anagrafe canina. (RV6) Non è possibile compilare la scheda di uscita di un cane che non risulta essere mai entrato al
canile. (RV7) Tutti i cani che entrano al canile devono essere sottoposti alla visita veterinaria. (RV8) Una volta registrato tramite Microchip, nessun cane 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 cane è randagio o privato può essere una fonte di ridondanza: i cani 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. PPRROOGGEETTTTAAZZIIOONNEE LLOOGGIICCAA ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ 4.1 Analisi delle prestazioni
Tavola dei volumi Tavola delle operazioni Concetto Tipo Volume Operazione Tipo Frequenza
CANE E 22000 Op. 1 I 3000/anno RANDAGIO E 50 Op. 2 I 400/anno
PRIVATO E 21950 Op. 3 I 1000/anno PADRONE E 21950 Op. 4 I 1000/anno ENTRATA E 750/anno Op. 5 I 1000/anno COMUNE E 95 Op. 6 B 1/anno
ULSS E 3 Op. 7 B 4/anno SCHEDA CLINICA E 22000 Op. 8 B 4/anno
VISITA E 4000/anno Op. 9 I 600/anno OPERATORE E 4 Op. 10 I 5/anno
USCITA E 750/anno Op. 11 I 5/anno Registrazione R 750/anno Op. 12 B 4/anno
Proprietà R 3000/anno Op. 13 B 4/anno Ritrovamento R 750 Op. 14 I 4/anno Appartenenza R 95 Op.15 B 4/anno Rilevazione R 3000/anno Op. 16 B 4/anno Residenza R 3000/anno Op. 17 I 3000/anno
Prelevamento R 600/anno Op. 18 I 1/mese Sottoposizione R 4000/anno Op. 19 B 1/mese Destinazione R 750/anno 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.
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 cane RANDAGIO e PRIVATO introdotta dalla generalizzazione può essere effettuata semplicemente verificando le occorrenze della relazione proprietà o della relazione residenza. I cani che non partecipano a queste associazioni, infatti, sono stati iscritti all'anagrafe canina 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 cani randagi.
Così il raggiungimento della minimalità è possibile solo eliminando la gerarchia che vede come
padre l'entità CANE 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 CANE, insieme con un nuovo attributo che distinguerà il tipo (randagio o privato) di ogni occorrenza di cane.
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 CANE, 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 CANE è 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 canina (circa 1000 volte l'anno) è nettamente superiore a quella con cui vengono richieste distinzioni tra cani 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 CANE 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 CANE e PADRONE con un attributo (DataReg) che indica la data in cui la persona è stata registrata come padrone del cane in questione. La partecipazione di CANE è 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): CANE (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 CANE perché le cardinalità
dell'associazione ci dicono che ogni cane 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' (Cane, Padrone, DataReg) I vincoli di integrità referenziale introdotti dalla traduzione sono rappresentati in Figura 4.3.
Figura 4.3 Rappresentazione grafica dei vincoli d'integrità referenziali di PROPRIETA'
4.3.2 Rilevazione
Microchip AnnoN Sesso Razza Taglia Colore Pelo Tatuaggio SegniP
CodFisc Cognome Nome Indirizzo Città Tel Cell
Cane Padrone DataRegPROPRIETA’
PADRONE
CANE
Associazione 1:1 tra CANE e SCHEDA CLINICA. Quest'ultima è un'entità debole ed ha CANE 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:
CANE (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.
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 CANE, cosicché esiste una referenza anche con questo schema di relazione. Tuttavia ciò è introdotto dal fatto che SCHEDA CLINICA e CANE sono legati da una associazione 1:1.
I vincoli di integrità referenziale introdotti dalla traduzione sono rappresentati in Figura 4.5.
Microchip DataVacc Vacc TestFil AntiPar SterChir ProfSCHEDA CLINICA
Microchip AnnoN Sesso Razza Taglia Colore Pelo Tatuaggio SegniPCANE
Figura 4.5 Rappresentazione grafica dei vincoli d'integrità referenziali di VISITA
4.3.4 Residenza
Associazione 1:N tra CANE 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: CANE (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 CANE:
CANE (Microchip, AnnoN, Sesso, Razza, Taglia, Colore, Pelo, Tatuaggio, SegniP*, Residenza*) I vincoli di integrità referenziale introdotti dalla traduzione sono rappresentati in Figura 4.6.
Figura 4.6 Rappresentazione grafica dei vincoli d'integrità referenziali di CANE
4.3.5 Registrazione
Microchip DataVacc Vacc TestFil AntiPar SterChir ProfSCHEDA CLINICA
Microchip Data Diagnosi TerapiaVISITA
CANE
CodCom NomeC SindacoCOMUNE
Microchip AnnoN Sesso Razza Taglia Colore Pelo Tatuaggio SegniP Residenza
Associazione 1:N tra ENTRATA e CANE con un attributo (Medaglia) che indica il numero della medaglia che permette il riconoscimento del cane all'interno del canile. La partecipazione di CANE è opzionale.
In questo caso lo schema di CANE 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.
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 cane 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.
NProg DataE ModoE Segnalatore Microchip Medaglia
ENTRATA
CANE
Microchip AnnoN Sesso Razza Taglia Colore Pelo Tatuaggio SegniP Residenza
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 cane è stato ritrovato. I vincoli di integrità referenziale introdotti dalla traduzione sono rappresentati in Figura 4.9.
Figura 4.9 Rappresentazione grafica dei vincoli d'integrità referenziali di ENTRATA
NProg DataE ModoE Comune Segnalatore Microchip Medaglia
ENTRATA
CodCom NomeC SindacoCOMUNE
NReg Data Operatore
PRELEVAMENTO
CodFisc Cognome Nome Indirizzo Città Tel Cell
OPERATORE
NProg DataE ModoE Segnalatore Microchip Medaglia
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.
Figura 4.10 Rappresentazione grafica dei vincoli d'integrità referenziali di ENTRATA
4.3.9 Appartenenza
Associazione 1:N tra COMUNE e ULSS. Il modo più conveniente per tradurre questa associazione è il seguente: COMUNE (CodCom, NomeC, Sindaco, Ulss) ULSS (NUlss, Resp, Indirizzo, Città)
All'interno dello schema COMUNE, per quanto riguarda l'attributo referente, al nome NUlss è stato
preferito semplicemente quello di Ulss. I vincoli di integrità referenziale introdotti dalla traduzione sono rappresentati in Figura 4.11.
NProg DataE ModoE Comune Segnalatore Microchip Medaglia
ENTRATA
NReg DataEntrata DataU ModoU NoteUSCITA
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.
CANE (Microchip, AnnoN, Sesso, Razza, Taglia, Colore, Pelo, Tatuaggio, SegniP*, Residenza*)
PROPRIETA' (Cane, 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, Ulss)
ULSS (NUlss, 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*)
NUlss Resp Indirizzo CittàULSS
CodCom NomeC Sindaco UlssCOMUNE
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. PPRROOGGEETTTTAAZZIIOONNEE FFIISSIICCAA ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
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 Canile; start schema Canile;
5.2 Definizione delle tabelle • CANE:
create table Cane (
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à (
Cane char (20) primary key references Cane (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 Cane (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 Cane (Microchip), Data date, Diagnosi char (50), Terapia char (50), primary key (Microchip, Data)
)
• COMUNE:
create table Comune (
CodCom char (5) primary key, NomeC char (20), Sindaco char (40), Ulss char (2) references Ulss (N°Ulss)
)
• ULSS:
create table Ulss (
N°Ulss char (2) primary key, Resp char (40), Indirizzo char (50), Città char (20)
)
• ENTRATA:
create table Entrata (
N°Prog char (5), DataE date, ModoE char (15), Comune char (5) not null references Comune (CodCom), Segnalatore char (40), Microchip char (20), Medaglia char (5), primary key (N°Prog, DataE)
)
• 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 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)
)
• USCITA:
create table Uscita (
N°Reg char (5), DataEntrata date, DataU date, ModoU char (15), Note 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 Cane [ 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 Cane C inner join (Scheda Clinica) SC on C.Microchip = SC.Microchip where C.Microchip = [Numero Microchip:];
• Operazione n° 4:
select * from Cane where Microchip = NumMicrochip;
• Operazione n° 5:
select * from (Cane C inner join Proprietà Pr on C.Microchip = Pr.Cane) 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.Cane 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 Cane from Proprietà);
• Operazione n° 9:
select * from Entrata where DataE = [Inserire Data:];
• Operazione n° 10:
select * from Cane where Razza = [Inserire Razza:];
• Operazione n° 11:
select count(*) from Cane where Razza = [Inserire Razza:];
• Operazione n° 12: select count(*) as NCaniCarico 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.Cane 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 Cane from Proprietà);
• Operazione n° 14: SELECT count(*) as NMicrochip FROM Entrata E left outer join Proprietà P ON E.Microchip = P.Cane where E.DataE >= DataInizio and E.DataE < DataFine and E.Microchip not in (select Cane 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.Cane = 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 Cane 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 ) >
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 cani 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à.Cane where ([DataInizio] <= U.DataU) and ([DataFine] > U.DataU) and (U.ModoU = 'deceduto') and ((E.Microchip) Not In (select Cane from Proprietà)) group by E.Comune; Query20b: restituisce il numero di prestazioni di cattura e trasporto di cani 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à.Cane where ([DataInizio] <= E.DataE and E.DataE < [DataFine]) and (E.Microchip) Not In (select Cane from Proprietà) group by E.Comune; Query20c: restituisce il numero di prestazioni veterinarie di cani 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à.Cane where ([DataInizio] <= SC.DataVacc and SC.DataVacc < DataFine) and (E.Microchip) Not In (select Cane from Proprietà) group by E.Comune;