PROGETTO DI UNA BASE DI DATI PER LA GESTIONE DI UN …users2.unimi.it/lzzmsm/DB Gest Canile.pdf ·...

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


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


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


COMUNECOMUNEappartenenzaappartenenzaULSSULSS

SCHEDACLINICASCHEDACLINICArilevazionerilevazione

sottoposizionesottoposizione

VISITAVISITA


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.


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.


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 ]


select * from Cane C inner join (Scheda Clinica) SC on C.Microchip = SC.Microchip where C.Microchip = [Numero Microchip:];


select * from Cane where Microchip = NumMicrochip;


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:];


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


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


select * from Entrata where DataE = [Inserire Data:];


select * from Cane where Razza = [Inserire Razza:];


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:];


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;

DDOOCCUUMMEENNTTII AALLLLEEGGAATTII ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

PROGETTO DI UNA BASE DI DATI PER LA GESTIONE DI UN …users2.unimi.it/lzzmsm/DB Gest Canile.pdf ·...

Documents

Transcript of PROGETTO DI UNA BASE DI DATI PER LA GESTIONE DI UN …users2.unimi.it/lzzmsm/DB Gest Canile.pdf ·...