Università degli Studi di Trieste

Facoltà di Ingegneria
Corso di Laurea Triennale in Ingegneria Informatica

Progettazione e realizzazione di
un’applicazione per la gestione dei privilegi
di accesso ad applicazioni software

Relatore Laureando

Chiar.mo Prof. Maurizio Fermeglia Riccardo Gulin

A.A. 2008/2009
1. INTRODUZIONE.............................................................................................................................................3
2. ANALISI........................................................................................................................................................4
2.1 – Situazione di partenza.........................................................................................................................4
2.2 – Requisiti...............................................................................................................................................4
2.2.1 – Strutturazione dei requisiti in gruppi di frasi omogenee...............................................................6
2.2.2 – Glossario dei termini.....................................................................................................................8
3. PROGETTAZIONE DELLA BASE DI DATI..........................................................................................................9
3.1 – PROGETTAZIONE CONCETTUALE.........................................................................................................9
3.1.1 – Analisi delle entità......................................................................................................................11
3.1.2 – Analisi delle relazioni e delle cardinalità.....................................................................................12
3.2 – PROGETTAZIONE LOGICA...................................................................................................................14
3.2.1 – Tabelle dei volumi.......................................................................................................................14
3.2.2 – Tabelle delle operazioni..............................................................................................................15
3.2.3 – Tabelle degli accessi....................................................................................................................15
3.2.4 – Ristrutturazione del diagramma E-R...........................................................................................17
3.2.4 – Traduzione verso il relazionale...................................................................................................20
4. SVILUPPO DEL PROTOTIPO DELLA BASE DI DATI.........................................................................................22
5. REALIZZAZIONE DELLA BASE DI DATI..........................................................................................................24
5.1 – Esportazione verso SQL Server..........................................................................................................24
5.2 – Trigger e Stored Procedures..............................................................................................................24
5.2.1 – Trigger.........................................................................................................................................25
5.2.2 – Stored Procedures......................................................................................................................27
6. REALIZZAZIONE DELL’INTERFACCIA UTENTE...............................................................................................29
6.1 – ADO.NET............................................................................................................................................29
6.2 – REALIZZAZIONE DEL FRONT-END.......................................................................................................29

2
1. INTRODUZIONE

Questa tesi riguarda la progettazione e lo sviluppo di un’applicazione software

richiesta dall’Ufficio del Servizio Informativo dell’Azienda per i Servizi Sanitari
N°2 “Isontina” di Gorizia.

L’obiettivo finale è lo sviluppo di un prototipo software per la gestione dei

dipendenti degli ospedali di Gorizia e Monfalcone e delle abilitazioni all’utilizzo
di applicativi, che i dipendenti utilizzano internamente all’ospedale. Al
momento attuale la raccolta e la gestione di questo tipo particolare di
informazioni avviene principalmente su supporto cartaceo; lo scopo perciò di
questo progetto è quello di automatizzare queste operazioni.

Da una prima analisi si è stabilita la mancanza di una base dati pre-esistente ed

utilizzabile; quindi lo svolgimento del progetto è iniziato con la progettazione e
lo sviluppo di un prototipo di database, per passare solo in seguito
all’interfaccia utente. Inoltre non è stata rilevata l’esistenza di alcun prodotto
software esistente che possa soddisfare i vincoli organizzativi ed economici
dell’azienda, perciò è stato necessario realizzare un applicativo ad hoc.

Le fasi principali dello sviluppo sono state:

 Analisi della situazione per identificare le esigenze del cliente e degli

utenti e per la definizione di obiettivi e funzionalità
 Progettazione della base di dati
 Sviluppo del prototipo della base dati
 Realizzazione della base dati finale
 Progettazione e sviluppo dell’interfaccia utente

Nei capitoli successivi vengono trattati più a fondo questi passaggi.

3
2. ANALISI

2.1 – Situazione di partenza

L’Ufficio del Servizio Informativo dell’ASS (Azienda per i Servizi Sanitari) di

Gorizia si occupa di più attività , una di queste è la gestione delle abilitazioni
all’utilizzo dei programmi interni all’ospedale, abilitazioni che vengono definite
come ruoli. Agli impiegati dell’ufficio possono arrivare richieste di aggiunta o
rimozione di ruoli per i dipendenti dell’ospedale; tali richieste possono essere
inoltrate all’azienda Insiel, responsabile dell’attivazione dei permessi all’accesso
ad una parte degli applicativi, oppure mantenute in sede in quanto
l’assegnazione di ruoli per una seconda parte degli applicativi può essere
effettuata direttamente dall’ufficio stesso.
La richiesta di sviluppo dell’applicativo software trattato in queste pagine è
stata commissionata da parte del responsabile dell’ufficio per poter
immagazzinare in una base dati informazioni riguardanti i dipendenti, i ruoli e di
conseguenza gli applicativi ai quali essi possono accedere o meno.
Gli utenti del sistema finale, definiti come operatori, sono gli impiegati
dell’ufficio stesso.

2.2 – Requisiti

La fase di analisi è una fase di notevole criticità nel processo di sviluppo; in essa
il fornitore si reca dal cliente per capire ed interpretare quali siano i bisogni di
quest’ultimo.
Lo svolgimento dell’ attività di analisi dei requisiti è avvenuto tramite interviste
ai futuri utenti del sistema finale. Questa fase ha richiesto notevole tempo per
ottenere un’inquadratura migliore possibile delle esigenze, in modo da evitare
che errori dovuti a un’errata interpretazione dei bisogni del committente si
potessero ripercuotere in tutte le successive fasi di lavoro.

Dall’analisi delle informazioni raccolte si è stabilito che per ogni dipendente

4
utente degli applicativi si vuole memorizzare un’anagrafica contenente Nome,
Cognome, Matricola (o Codice Identificativo), Data di Nascita, Codice Fiscale,
Sede di Appartenenza con relativo Reparto ed eventuale Data di Cessazione.

Per ogni Reparto si vuole poter inserire nel database, oltre al nome di questo, un
Numero di telefono interno e la Sede dove esso è locato, sede che sarà
contraddistinta da nome, indirizzo e numero di telefono.

Per quanto riguarda gli Applicativi ai quali un utente può accedere, essi sono
circa trenta, divisibili tra quelli abilitati dall’ufficio informativo stesso e quelli
abilitati da Insiel; ogni applicativo fornisce da uno o più di un centinaio di ruoli.
Ogni dipendente può ottenere anche un numero elevato di abilitazioni, gli viene
cioè assegnato un ruolo per ogni applicativo che egli può utilizzare.
Un operatore del Servizio Informativo o utente della base di dati, può ricevere
una richiesta di modifica delle abilitazioni di uno o più dipendenti; in questo
caso egli vuole poter effettuare una modifica nel database, modifica che può
riguardare più abilitazioni e più utenti ma che deve essere contrassegnata da un
singolo numero di protocollo (o numero di pratica), dalla data di modifica e
dall’operatore che l’ha effettuata. In caso di abilitazioni ad applicativi fornite da
Insiel , ogni nuovo protocollo dovrà poi essere inoltrato a tale azienda; è stata
perciò richiesta la funzionalità di stampa di un modulo contenente tutte le
informazioni sui ruoli, modulo che preferibilmente dovrà essere adattato a una
singola pagina. Il sistema dovrà distinguere tra abilitazioni fornite dall’azienda
esterna e abilitazioni direttamente effettuate dagli operatori del database; solo
nel primo caso è richiesta la stampa di un modulo.

Una richiesta particolare che può arrivare all’operatore è la cancellazione rapida

di tutte le abilitazioni di una persona per il singolo applicativo, perciò il sistema
finale dovrà fornire anche questa opzione. Nel caso venga inserita una data di
cessazione nei dati personali di un dipendente, dovuta al fatto che una persona
ha terminato l’attività lavorativa presso l’ospedale, il sistema dovrebbe
preparare, previa conferma da parte dell’operatore, la possibilità di rimozione
istantanea di tutte le sue precedenti abilitazioni, elencandole a una a una in un
modulo stampabile.

Il sistema deve permettere agli utilizzatori la possibilità di inserire nuovi utenti

con i relativi dati, cancellarli o aggiornarli; può sussistere inoltre l’esigenza
dell’inserimento di nuovi reparti e nuove sedi di appartenenza con tutti i dati a
loro correlati.
5
Oltre alle già sopracitate operazioni sulle abilitazioni, ci può essere la necessità
di inserire nel database anche nuovi applicativi e nuovi ruoli.

Deve inoltre essere fornita la possibilità di effettuare ricerche filtrate per dati
anagrafici, numero di matricola, applicativo, numero di protocollo.

Per quanto riguarda l’interfaccia utente definitiva essa deve essere il più
semplice e sobria possibile secondo le preferenze degli utenti.

Non sono stati espressi particolari vincoli riguardanti sicurezza e prestazioni del
sistema finale.

2.2.1 – Strutturazione dei requisiti in gruppi di frasi omogenee

Si è voluta eseguire una strutturazione dei requisiti in maniera da poter più

facilmente identificare entità e relazioni che andranno a costituire il primo
schema utilizzato per la progettazione del database: lo schema E-R (Entity-
Relationship).

Frasi di carattere generale

 Si vuole progettare e realizzare una base dati che possa permettere agli
operatori di controllare e modificare l’elenco dei dipendenti dell’ospedale
(dell’ordine delle migliaia di persone) che hanno ottenuto l’abilitazione o
meno ad accedere a numerosi applicativi utilizzati a lavoro.

Frasi relative ai dipendenti

 Per ogni dipendente si vuole memorizzare un’anagrafica contenente

Nome, Cognome, Matricola (o Codice Identificativo), Data di Nascita,
Codice Fiscale, Sede di Appartenenza con relativo Reparto ed eventuale
Data di Cessazione e Abilitazioni che egli ha ottenuto per l’accesso agli
applicativi.

6
Frasi relative alla sede

 Per quanto riguarda la Sede si vuole memorizzare Nome della Sede, Città ,
CAP, Indirizzo e Numero di Telefono.

Frasi relative al reparto

 Per quanto riguarda il Reparto si vuole memorizzare Nome del Reparto,

Numero di Telefono e Sede di Appartenenza.

Frasi relative agli applicativi

 Gli applicativi ai quali un utente può accedere sono circa trenta e

suddivisibili in applicativi per i quali è l’ufficio informativo stesso a fornire
l’abilitazione e applicativi per i quali è l’azienda esterna INSIEL a fornire
l’abilitazione.

 Ogni dipendente può avere più o meno privilegi, ma gli viene assegnato
uno e un solo ruolo per ogni applicativo che egli può utilizzare.

Frasi relative al protocollo

 Un operatore può ricevere richieste di modifica delle abilitazioni, cioè dei

ruoli, di uno o più dipendenti; in questo caso egli vuole poter aprire una
nuova pratica per poter effettuare una modifica nel database, modifica che
può riguardare più abilitazioni e più utenti ma che deve essere
contrassegnata da un singolo numero di protocollo, dalla data di modifica
e dall’operatore che l’ha effettuata.

 Il sistema deve essere in grado di distinguere tra abilitazioni fornite

dall’azienda esterna e abilitazioni direttamente effettuate dagli operatori
del database; nel primo caso è richiesta la stampa di un modulo
contenente tutte le informazioni sui ruoli e dipendenti da modificare; il
modulo deve riportare il numero di protocollo e preferibilmente deve
essere adattato a una singola pagina.

7
2.2.2 – Glossario dei termini
Si è costruito un glossario dei termini; per ogni termine significativo ricavato dai
requisiti si sono inseriti una breve descrizione, relazioni con altri termini del
glossario ed eventuali sinonimi.

Termine Descrizione Sinonimi Collegamenti

Dipendent Utilizzatori degli applicativi Utenti-applicativi Reparto,Ruolo

i dell’ospedale. Sono coloro ai quali
dovranno venire assegnati dei
privilegi.

Applicativi Sono i software a cui accedono gli Software Dipendenti, Ruoli

impiegati dell’ospedale e per i quali
hanno più o meno privilegi.

Operatore E’ un dipendente che è anche Protocollo,Dipendent

utilizzatore del sistema in questione. i
Responsabile perciò della creazione di
nuovi protocolli di modifica
abilitazioni.

Ruolo Ogni utente riceve un ruolo per ogni Abilitazione,privilegi Applicativi,Dipendent

singolo applicativo a cui ha accesso. o i

Protocollo Numero progressivo che va a Numero pratica Dipendenti,Ruolo,Op

identificare una richiesta giunta per la eratore
modifica delle abilitazioni alcuni
utenti.

Sede Ente presso cui gli impiegati lavorano Dipendenti, Reparto

o hanno lavorato.

Reparto Suddivisione interna della sede. Sede, Dipendenti

8
3. PROGETTAZIONE DELLA BASE DI DATI

3.1 – PROGETTAZIONE CONCETTUALE

Una volta ottenuta una chiara situazione dei requisiti espressi in linguaggio
naturale si è potuto procedere andando a rappresentare la realtà mediante uno
schema, il diagramma Entity-Relationship. Questo modello permette di
rappresentare i dati a prescindere dal motore database scelto e mette a
disposizione degli elementi utili per rappresentare il contesto mediante una
simbologia ad essi associata. Una breve spiegazione dei costrutti forniti da
questa tipologia di diagramma è la seguente:

 Entità : classe di oggetti significativi nel contesto della realtà in esame.

 Relazione: legame logico tra due o più entità in quanto corrisponde ad
un’interazione esistente tra due o più elementi reali.
 Attributo: proprietà elementare di un’entità o di una relazione.
 Cardinalità : coppia di valori che specificano il numero minimo e massimo
di occorrenze della relationship in cui ciascuna occorrenza dell’entità può
comparire.
 Identificatore: insieme di attributi che consente di individuare
univocamente ciascuna occorrenza di un’entità .
 Generalizzazione: rappresentazione di una o più entità nei casi dove
queste possono essere considerate caso particolare di un’altra entità .
Le proprietà del genitore vengono ereditate da tutti i figli.

Tenendo conto di questi aspetti si è riusciti a costruire un diagramma E-R

primitivo che viene illustrato nella seguente pagina.

9
–

10
3.1.1 – Analisi delle entità

Si elencano di seguito le descrizioni delle singole entità , i loro attributi e i campi

possibili identificatori primari:

Persona
 Matricola: È il codice univoco che identifica qualsiasi dipendente dell’azienda sanitaria
(tuttora lavorante o meno); è candidato ad essere chiave primaria dell’entità
“Persona”.
 Nome: Nome proprio della persona
 Cognome: Cognome della persona
 Data di nascita: Data di nascita della persona
 Sesso: Sesso della persona
 C.F. : Codice Fiscale della persona

Dipendente
 Stessi attributi dell’entità padre “Persona”

Ex-Dipendente
 Stessi attributi dell’entità padre “Persona”
 Data di cessazione: Data in cui l’impiegato ha concluso l’esperienza lavorativa

Operatore
 Stessi attributi del padre “Dipendente”

Non operatore
 Stessi attributi del padre “Dipendente”

Reparto
 RepartoID: codice univoco che identifica il reparto di appartenenza di una Persona.
Questo campo è candidato a essere chiave primaria dell’entità “Reparto”
 Nome Reparto: nome del reparto dell’ospedale
 Telefono: numero di telefono interno del reparto

Sede
 SedeID: codice univoco che identifica la sede nella quale è situato un reparto. Questo
campo è candidato a essere chiave primaria dell’entità “Sede”
 Nome: nome della sede
11
  Città : città dove una sede ha locazione
 Indirizzo: indirizzo della sede
 Telefono: numero di telefono della sede

Applicativo
 ApplicativoID: codice univoco che identifica gli applicativi software utilizzati dai
dipendenti dell’ospedale. Questo campo è candidato a essere chiave primaria
dell’entità “Applicativo”
 Nome: nome usato per definire l’applicativo
 Abilitato da: campo che distingue tra applicativi abilitati dall’azienda esterna o dagli
operatori dell’ufficio informativo stesso

Ruolo
 RuoloID: codice univoco che identifica il ruolo o abilitazione che una persona ha per il
singolo applicativo. Questo campo è candidato a essere chiave primaria dell’entità
“Applicativo”
 Nome: nome dell’abilitazione che un dipendente può ottenere per un applicativo

Protocollo
 ProtocolloID: numero univoco e progressivo che identifica una pratica di modifica
delle abilitazioni dei dipendenti.
 Data di modifica: data in cui è stata aperta la nuova pratica
 Operatore: colui il quale ha aperto la pratica

3.1.2 – Analisi delle relazioni e delle cardinalità

La fase successiva è stata dedicata ad un aspetto fondamentale nella

progettazione delle basi di dati, ossia lo studio delle cardinalità nelle relazioni.
Ponendosi alcune semplici domande sui legami intercorrenti tra le entità si è
giunti alla definizione delle cardinalità per tutte le relazioni presenti nello
schema; di seguito si possono osservare delle tabelle contenenti le descrizioni
delle singole relazioni e i ragionamenti che hanno portato all’identificazione
delle varie cardinalità :

12
RELAZIONE CARDINALITA’
Collega l’entità “Persona” con l’entità “Ruolo”; definisce tutti i ruoli per i
quali un dipendente ha ottenuto l’abilitazione all’utilizzo.

Assegnazione Molti a molti: ogni dipendente può avere ottenuto l’abilitazione a uno o a
più ruoli e viceversa un ruolo può essere stato assegnato a numerosi
dipendenti.

Collega l’entità “Applicativo” con l’entità “Ruolo”; stabilisce quali ruoli

fornisce un singolo applicativo.
Autorizzazione
Uno a molti: ogni applicativo può avere a disposizione molti ruoli da
assegnare all’utente, ma ogni ruolo appartiene a uno e un solo applicativo.

Collega l’entità “Persona” con l’entità “Reparto”; identifica il reparto di

appartenenza del dipendente dell’azienda.
Appartenenza Uno a molti: ogni dipendente ha uno e un solo reparto di appartenenza.
Un reparto però può avere numerosi dipendenti.

Collega l’entità “Reparto” con l’entità “Sede”; definisce la sede di

appartenenza del singolo reparto.
Locazione
Uno a molti: un reparto ha una sola sede di appartenenza ma una sede ha
più di un reparto.

Collega l’entità “Ruolo” con l’entità “Protocollo”; il numero di protocollo

caratterizza una pratica arrivata in azienda che richiede la modifica di
privilegi.
Modifica Molti a molti: ogni volta che viene aggiunto o rimosso un ruolo di un
dipendente, la modifica riceve un numero di protocollo. Un numero di
protocollo invece corrisponde ad uno o più ruoli modificati.

Collega l’entità “Protocollo” con l’entità “Operatore”; ogni protocollo è

creato da un operatore.
Creazione
Uno a molti: un protocollo ha uno e un solo operatore, ma un operatore
può aver creato numerosi numeri di protocollo.
Collega l’entità “Protocollo” con l’entità “Persona”; sotto un numero di
protocollo si trovano i dipendenti ai quali sono stati aggiunti o rimossi dei
ruoli con l’apertura di una nuova pratica
Abilitazione Molti a molti: un dipendente può avere ricevuto più modifiche ai propri
ruoli identificate da diversi numeri di protocollo in quanto avvenute con
pratiche differenti. Viceversa un singolo protocollo può identificare
numerosi dipendenti ai quali sono state effettuate modifiche dei ruoli.

13
3.2 – PROGETTAZIONE LOGICA

Dopo aver ottenuto uno schema E-R con attributi e cardinalità , è stata effettuata
come prima cosa una scelta sul modello dei dati, ovvero come sono organizzati i
dati dal punto di vista dell’elaboratore. La scelta è ricaduta sul modello
relazionale dei dati, attualmente il più diffuso, il quale permette di sistemare i
dati in strutture tabellari fisse. Una volta scelto il modello, si è passati alla
traduzione dello schema logico nello schema relazionale, schema meno astratto
del precedente e più ottimizzato per l’utilizzo finale; non si è trattato di una
semplice traduzione perché questa fase deve necessariamente tenere conto di
prestazioni e aspetti realizzativi.

3.2.1 – Tabelle dei volumi

Una prima indagine di questo tipo ha portato alla costruzione di tabelle dei
volumi riguardanti i numeri di occorrenze sia per quanto riguarda le entità che
le relazioni.

Tabelle dei volumi per entità e relazioni

Concetto Tipo Volume Concetto Tipo Volume

Persona E 10000 Locazione R 20
Dipendente E 5000 Appartenenza R 150
Ex-Dipendente E 5000 Assegnazione R 250000
Operatore E 10 Autorizzazione R 100
Non Operatore E 5000
Creazione R 1000
Applicativo E 100
Abilitazione R 5000
Ruolo E 1000
Modifica R 10000
Reparto E 150
Sede E 20
Protocollo E 1000

14
3.2.2 – Tabelle delle operazioni

Oltre a tenere in considerazione i volumi dei dati sono state effettuate analisi
anche sulle operazioni tipiche sulla base dati, operazioni raccolte nella seguente
tabella:

Operazione Tipo Frequenza

Inserimento nuovo dipendente Interattiva 100 /anno

Aggiornamento dati dipendenti Interattiva 10 /mese

Inserimento nuovi applicativi Interattiva 1 /anno

Visualizzazione elenco dipendenti Interattiva 50/giorno

Inserimento data di cessazione di un Batch 100 /anno

dipendente e conseguente cancellazione di tutti
i ruoli dello stesso

Visualizzazione ruoli dipendente Interattiva 10/giorno

Modifica abilitazioni dei dipendenti Interattiva 50 /settimana

Creazione numero di protocollo Interattiva 10 /settimana

3.2.3 – Tabelle degli accessi

E’ stata effettuata infine un’analisi sugli accessi prendendo in considerazione le

tre operazioni sulla base di dati considerate più frequenti e più importanti di
altre:

15
  Operazione in esame: visualizza tutti gli applicativi e ruoli per i quali un
dipendente ha le abilitazioni

Concetto Costrutto Accessi Tipo

Persona Entità 1 L
Ruolo Entità 10 L
Assegnazione Relazione 10 L
Applicativo Entità 10 L
Autorizzazione Relazione 10 L

 Operazione in esame: visualizza elenco dipendenti dell’ospedale

Concetto Costrutto Accessi Tipo

Persona Entità 10000 L

 Operazione in esame: creazione nuova pratica

Concetto Costrutto Accessi Tipo

Operatore Entità 1 L
Creazione Relazione 1 L

Protocollo Entità 1 S

Abilitazione Relazione 5 S

Persona Entità 5 L

Modifica Relazione 25 S

Ruoli Entià 25 L

3.2.4 – Ristrutturazione del diagramma E-R

16
Una volta ricavate queste informazioni si è potuti passare alle operazioni per la
ristrutturazione del diagramma E-R.

Eliminazione degli attributi composti

L’unico attributo composto rilevato nello schema iniziale è quello riguardante

l’attributo indirizzo dell’entità sede.

Si sono presentate due possibili soluzioni:

 Eliminazione dell’attributo composto in modo da farlo diventare attributo

semplice

 Modifica dei sottoattributi in attributi separati dell’entità

La prima soluzione è stata ritenuta più adatta in quanto nel sistema finale è
sufficiente accedere all’informazione complessiva e non ai campi separatamente.
Scegliendo questa soluzione il campo indirizzo diventa un campo stringa
contenente tutti i precedenti attributi.

Eliminazione degli attributi multi-valore

17
Nel caso in questione è l’attributo telefono ad essere multi-valore in quanto sia
l’entità sede che l’entità reparto possono avere più di un numero di telefono.

E’ stata scelta la soluzione di creare una nuova entità collegata da una relazione
alle vecchie entità che avevano l’attributo multi valore.

Eliminazione delle generalizzazioni

Il modello di struttura dei dati scelto, il modello relazionale, non è in grado di

rappresentare le generalizzazioni, pertanto si cerca di eliminare queste ultime
sostituendole con altri concetti dove possibile.

Ci possono essere tre soluzioni al problema:

 La prima soluzione prevede l’accorpamento dei figli nel padre: le entità

figlie vengono eliminate e le loro proprietà (attributi, associazioni,
generalizzazioni) vengono aggiunte al padre, che deve avere un
attributo in più per distinguere le entità figlie.
 La seconda soluzione prevede l’accorpamento del padre nei figli:
l’entità padre viene eliminata e per ereditarietà i suoi attributi,
identificatori e relazioni vanno ai figli.
 La terza soluzione prevede che la generalizzazione si trasformi in
associazioni uno ad uno che legano padre e figli.

In questo progetto la soluzione adottata è stata la prima per tutti i casi di

generalizzazione, in quanto essa, a differenza delle altre due, non richiede la
creazione di ulteriori tabelle; è principalmente questa caratteristica di
semplicità che ha portato a questa scelta.

18
Le generalizzazioni che si è dovuti eliminare da questo progetto sono le
seguenti:

- La prima generalizzazione riguarda i dipendenti che ormai non lavorano

più presso l’azienda. Per essi viene inserita una data di cessazione che
perciò può diventare un attributo direttamente dell’entità persona
eliminando quindi la generalizzazione.

- Nel secondo caso la generalizzazione distingue tra dipendenti che sono

identificati come operatori del database e i dipendenti che non hanno
questa autorizzazione. Come nel caso precedente anche questa
generalizzazione può essere eliminata andando ad aggiungere un attributo
all’entità dipendente, eliminata nel precedente passo di ristrutturazione;
perciò viene aggiunto l’attributo Operatore Si/No direttamente all’entità
persona.

- L’ultima generalizzazione è quella che specifica se un ruolo è stato

modificato o meno. In questo caso però ci si è trovati di fronte a una
situazione di vincolo non esprimibile, cioè una limitazione imposta dal
contesto. La soluzione al problema può avvenire tramite la scrittura di
opportune procedure del programma che accede al database, oppure
prendendo in considerazione l’utilizzo di un DBMS che può fornire
funzionalità utili alla risoluzione del problema, quali “trigger” che
19
 permettono di eseguire azioni, come riempimenti di tabelle, in
corrispondenza di determinati eventi. La scelta è ricaduta su quest’ultima
soluzione. Per quanto riguarda la fase di progettazione logica si è
proceduto ad eliminare l’ultima generalizzazione tramite l’inserimento di
un’ulteriore un’entità chiamata dettaglio-protocollo, contenente al suo
interno informazioni riguardanti le persone alle quali sono stati modificati
dei ruoli nei singoli protocolli.

Nome Data di
Nome Nome Cognome
Nascita
Applicativo Ruolo Operatore Si/No Codice
ApplicativoID RuoloID Matricola Fiscale
Data di Cessazione

1-N 1-1 RUOLO 0-N 0-N

APPLICATIVO Autorizzazione Assegnazione PERSONA
(PRIVILEGIO)

0-N
0-N

Modifica Modifica

1-N

1-N DETTAGLIO
1-N 1-1 1-1
Dettaglio PROTOCOLLO Creazione
PROTOCOLLO

Data
Modifica ProtocolloID

Parte del diagramma E-R ristrutturato con cardinalità e attributi

Si è giunti pertanto a uno schema E-R ristrutturato e pronto per il passaggio al

relazionale.

3.2.4 – Traduzione verso il relazionale

Sono stati scelti gli identificatori primari in maniera che fossero unici per ogni
entità :

Persona (Matricola, Cognome, Nome, Sesso, Data di Nascita, Codice Fiscale,

OperatoreSi/No,Data di Cessazione, Reparto)
20
Ruolo (RuoloID, Nome Ruolo, Applicativo)

Applicativo (ApplicativoID, Nome Applicativo, Abilitato da)

Reparto (RepartoID, Nome Reparto, Sede, Numero di telefono)

Sede (SedeID, Nome Sede, Indirizzo, Numero di telefono)

Protocollo (ProtocolloID, Data Modifica, Operatore)

Dettaglio-Protocollo (DettaglioID, Matricola, Ruolo, Protocollo)

E’ stato così possibile effettuare la traduzione verso lo schema relazionale; da

notare in particolare l’aggiunta di una “tabella di sponda” per la relazione molti
a molti tra le tabelle Persona e Ruolo:

tblRuolo tblPersona_Ruolo
PK RuoloID PK,FK2 Matricola
PK,FK1 RuoloID
Nome
FK1 ApplicativoID
tblSede
FK2 DettaglioID
PK SedeID

tblReparto Nome
tblPersona Indirizzo
PK RepartoID
PK Matricola
Nome Reparto
Cognome FK1 SedeID
Nome
tblApplicativo
Data di Nascita
PK ApplicativoID Codice Fiscale
FK1 RepartoID
NomeApplicativo Data di Cessazione
Abilitato da Operatore Si/No
tblTelefono
PK TelefonoID

tblProtocollo FK2 SedeID

FK1 RepartoID
PK ProtocolloID Numero
tblDettagli_Protocollo
PK DettaglioID Data
FK1 Operatore
RuoloID
FK1 Matricola
FK2 ProtocolloID

21
4. SVILUPPO DEL PROTOTIPO DELLA BASE DI DATI

Questa fase è consistita nella realizzazione di un prototipo sviluppato tramite

Microsoft Access 2007, prototipo che è stato poi portato in visione al cliente per
accertarsi di aver colto per intero le richieste sue e dei futuri utenti.

Per quanto riguarda questo prototipo, sono state dapprima create tutte le tabelle
e le relative relazioni, seguendo le indicazioni dello schema relazionale come si
può notare dall’immagine sottostante:

Diagramma delle relazioni in Access

Sono stati creati anche vincoli di tipo intra-relazionale e inter-relazionale, e

successivamente si è potuti passare alla creazione di query sulle quali sono state
costruite delle maschere di lettura, aggiornamento o inserimento di dati.

22
 Esempio di maschera in lettura, viene visualizzato a schermo l’elenco dei dipendenti

Esempio di maschera di inserimento, viene offerta la possibilità di creare un nuovo dipendente

Una volta create alcune funzionalità base, questo prototipo è stato portato in
visione al cliente, il quale, confermando che i requisiti individuati in partenza
erano corretti, ha permesso la continuazione del progetto.

23
5. REALIZZAZIONE DELLA BASE DI DATI

5.1 – Esportazione verso SQL Server

Poiché software come Access sono limitati per vari aspetti e non offrono la
possibilità di utilizzare strumenti avanzati come i trigger, è stata effettuata la
scelta di migrare da Microsoft Access 2007 al ben più completo Microsoft Sql
Server 2005 Express. E’ stata effettuata una scelta di questo tipo soprattutto per
la possibilità di implementare i vincoli non esprimibili tramite l’utilizzo di
trigger e non tramite procedure create ad hoc. Questa scelta è stata effettuata
poichè se un vincolo è implementato nel DBMS viene rispettato comunque si
acceda al database; al contrario se invece il vincolo dovesse venire implementato
nel programma che accede alla base dati, esso sarà rispettato solo se l’accesso
viene effettuato tramite tale programma.
Pertanto è stata effettuata la migrazione a Sql Server sfruttando dei tool appositi
per l’esportazione di struttura e dati da Access.

5.2 – Trigger e Stored Procedures

Una volta completata con successo l’esportazione, si è scelto di procedere con la

creazione di tutte le viste che poi saranno utilizzate dal programma di accesso
alla base dati.
Sono state prodotte otto viste in base alle necessità rilevate per lo sviluppo delle
funzionalità del prototipo finale dell’applicativo:
- View_Abilitazioni
- View_DettaglioDipendente
- View_DettaglioProtocollo
- View_ListaDipendenti
- View_Operatori
- View_Reparti
- View_RuoliAssegnati
- View_Ruolo

24
5.2.1 – Trigger

Dopo aver creato le viste tramite codice Sql si è deciso di potenziare il database
tramite la scrittura dei già citati trigger.
Questi strumenti sono particolari tipi di stored procedures, ovvero procedure
memorizzate nel database stesso e scritte in linguaggio Transact-Sql; l’
esecuzione dei trigger è data dallo scatenarsi di un evento particolare, come la
modifica dello stato della base dati, secondo una condizione specificata.
In questo progetto è stato utilizzato un particolare tipo di trigger, i trigger
instead of che verranno illustrati nelle seguenti righe.

Sono stati utilizzati numerosi trigger di tipo instead of; essi sono stati creati
direttamente sulle viste per non dare all’utente dell’applicativo diretto accesso
alle tabelle della base dati; perciò sono stati scritti trigger instead of per ogni
vista del database nella quale ci fosse bisogno di inserire nuovi dati, aggiornare o
eliminare i dati preesistenti nelle tabelle.

Pertanto sono stati creati 15 trigger di tipo instead of per le seguenti viste
aggiornabili:

- View_DettaglioDipendente(trg_InsertDettaglioDipendente,
trg_UpdateDettaglioDipendente, trg_DeleteDettaglioDipendente)
- View_Reparti (trg_InsertReparto, trg_UpdateReparto,trg_DeleteReparto)
- View_Sede(trg_InsertSede,trg_UpdateSede,trg_DeleteSede)
- View_Ruolo(trg_InsertRuolo, trg_UpdateRuolo, trg_DeleteRuolo)
- View_Applicativo(trg_InsertApplicativo,trg_UpdateApplicativo,trg_DeleteA
pplicativo)

Di seguito viene illustrato il codice esempio per un trigger utilizzato per

l’inserzione nella base di dati di un nuovo dipendente:

25
 Codice del trigger trg_InsertDettaglioDipendente

Un secondo esempio riguarda il trigger adibito all’aggiornamento automatico dei

dati anagrafici di un dipendente esistente:

Codice del trigger trg_UpdateDettaglioDipendente

Con la creazione di questi particolari tipi di trigger, ogni modifica effettuata dagli
utenti da programma di front-end sulle viste disponibili può venire gestita in
modo da andare a modificare in maniera controllata le tabelle della base dati.

26
5.2.2 – Stored Procedures

Di seguito sono state create tre stored procedures per l’assegnazione e

rimozione dei ruoli e per la creazione di un nuovo numero di protocollo
nell’apposita tabella.

La prima di queste spAssegnaRuolo è stata creata per memorizzare nella tabella

di sponda tbl_PersonaRuolo le persone e i ruoli ad esse assegnati tramite
creazione di una nuova pratica; inoltre il compito di questa procedura è anche
quello di tracciare la modifica effettuata andando a scrivere nella tabella
tbl_DettaglioProtocollo, inserendo in essa Ruolo e Matricola aggiunti e il numero
di Protocollo ad essi collegato, oltre che inserire la stringa ‘Aggiunta’ nel campo
Operazione Effettuata della stessa tabella. Alla procedura sono passati come
parametri in ingresso l’ ID del protocollo, la Matricola e l’ID del ruolo in
questione.

Codice della procedura spAssegnaRuolo

La seconda procedura spRevocaRuolo è stata creata in maniera molto simile alla

precedente; esse differiscono per il fatto che quest’ultima sia di rimozione dei
ruoli invece che di assegnazione. Di seguito ne viene illustrato il codice:

27
 Codice della procedura spRevocaRuolo

L’ultima stored procedure creata è la spNuovoProtocollo la quale si occupa della

creazione di un nuovo numero di protocollo andando a inserire nella tabella
tbl_Protocollo la data attuale e la matricola dell’operatore che ha creato il nuovo
protocollo; la matricola viene passata come parametro alla procedura.

Codice della procedura spNuovoProtocollo

Tutte queste procedure verranno chiamate in maniera opportuna all’interno del

programma che accede alla base dati.

28
6. REALIZZAZIONE DELL’INTERFACCIA UTENTE

Per la realizzazione dell’interfaccia utente si è scelto di utilizzare il linguaggio di

programmazione C# e la stesura del codice è avvenuta sfruttando la suite
Microsoft Visual Studio 2008 Professional, in quanto perfettamente compatibile
con il lato server dell’applicativo. Il componente per l’accesso ai dati che si
frappone tra Sql Server e l’interfaccia utente è ADO.NET facente parte del frame-
work .NET.

6.1 – ADO.NET

ADO.NET è costituito da vari componenti; fondamentali sono il DataProvider e il

DataSet.

Il primo serve a mantenere la connessione con la base dati fisica ed è specifico

per ogni fonte dati; sono disponibili infatti DataProvider per connessioni di tipo
OleDb, Oracle e quello utilizzato per l’applicativo trattato in questo progetto,
specifico per le connessioni a Sql Server.

Per quanto riguarda il secondo componente, esso può essere visto come la
rappresentazione dei dati contenuti in memoria centrale, dati che sono
nient’altro che la copia della data source fisica con tutte le tabelle e le relazioni.
Fondamentale è che il DataSet lavori in maniera “disconnessa” rispetto alla fonte
dati in quanto non è connesso direttamente ad essa; a fare da ponte tra le due
componenti è l’oggetto DataAdapter, il quale fornisce metodi per trasferire
informazioni contenute nel DataSet alla base dati e viceversa.

6.2 – REALIZZAZIONE DEL FRONT-END

Sfruttando le nozioni riguardanti ADO.Net si è proceduto creando un nuovo

progetto con Visual Studio 2008 e associando il DataSet alla sorgente dati
costituita dal database; così facendo è stato possibile creare sette windows-
form:
29
 - AssegnazioneRuoli.cs
- Dipendente.cs
- ElencoDipendenti.cs
- Home.cs
- Reparti.cs
- RiepilogoAssegnazioneRuoli.cs
- Ruoli.cs

Nelle form sono stati utilizzati prevalentemente oggetti del tipo DataGridView,
che è stato possibile popolare con i dati del database grazie al metodo Fill fornito
dal TableAdapter, pulsanti contenenti codice da scatenare all’evento onclick e
combo-box legate a viste del database.
Qui di seguito vengono illustrate più a fondo le form fondamentali del prototipo:

- La form Home.cs è stata creata per essere la prima ad aprirsi con

l’esecuzione del programma; essa contiene il logo dell’azienda e i pulsanti
per accedere alle altre form:

Home.cs

- La form Dipendente.cs fornisce la possibilità agli utenti di inserire nella

base dati i dati anagrafici di nuovi dipendenti o modificare e cancellare
quelli pre-esistenti; questa form contiene un DataGridView con l’elenco
dei dipendenti prelevato dalla vista view_DettaglioDipendente tramite il
metodo fill del tableadpater, autogenerato da Visual Studio; inoltre
contiene i campi in dettaglio del dipendente selezionato dall’elenco,
sempre ricavati dalla medesima vista; è presente anche un controllo
combo box che fornisce la possibilità di selezionare il reparto di
30
appartenenza del dipendente da un elenco, anche questo popolato dal
metodo fill.

Dipendente.cs

Per quanto riguarda la parte di codice non autogenerato, c’è stato il

bisogno di definire i comandi di tipo update, insert e delete affinchè poi
potessero essere utilizzati dal metodo update del tableadapter,
responsabile della propagazione delle modifiche dal dataset alla base dati
dopo la pressione del pulsante Salva.

Di seguito viene illustrata una porzione di codice riguardante la

definizione del comando update; la sintassi per i comandi insert e delete è
molto simile:

31
 Codice esempio per la definizione del comando UPDATE per l’aggiornamento dell’anagrafica di un dipendente nel
database.

Il pulsante Salva contiene all’interno del proprio evento OnClick due righe
di codice utilizzate per il corretto salvataggio delle modifiche nel database.

Nel dettaglio il comando EndEdit serve per l’aggiornamento del dataset

con i contenuti dei vari controlli della form; il comando Update invece
chiama le istruzioni update, insert e delete definite in precedenza in
maniera da aggiornare il database.

Codice del pulsante Salva

- Per quanto concerne la parte riguardante la creazione di una nuova

pratica e pertanto dell’assegnazione/rimozione di ruoli ai dipendenti si
sono andate a creare due form: AssegnazioneRuoli.cs e

32
RiepilogoAssegnazioneRuoli.cs.
La prima delle due form contiene un elemento DataGridView, riempito
dalla vista view_RuoliAssegnati, e più combo box per la scelta
dell’operatore, dei ruoli e dei dipendenti ai quali assegnare le abilitazioni,
oltre che pulsanti per salvare le modifiche; per rimuovere i ruoli di un
dipendente basta selezionare la riga desiderata dal DataGrid e cancellarla.

AssegnazioneRuoli.cs

Per la parte riguardante il pulsante Abilita modifiche si è andati a scrivere

codice che, dopo aver controllato se dalla combo box apposita è stato
scelto un operatore, crea un comando per l’esecuzione della stored
procedure spNuovoProtocollo, la quale si occupa della creazione di un
nuovo numero di pratica:

Codice di Abilita modifiche

33
Per la rimozione dei ruoli si è creato un nuovo comando delete, il quale si
occupa della chiamata alla stored procedure spRevocaRuolo passandole in
ingresso gli appositi parametri idProtocollo, Matricola e Ruolo in maniera
che essa gestisca la rimozione dei ruoli selezionati dalla tabella corretta e
aggiunga al dettaglio protocollo l’operazione di rimozione effettuata.

Codice per la rimozione dei ruoli

Il pulsante Assegna invece, dopo aver controllato che entrambi i controlli

combo box della scelta dipendente e ruolo abbiano dei valori selezionati, si
occupa della chiamata alla stored procedure spAssegnaRuolo passandole
come parametri oltre all’ idProtocollo anche i valori selezionati dalle due
combo box in questione:

Codice del pulsante Assegna Ruoli

34
Infine il pulsante Salva sfrutta il metodo Update per aggiornare il database
e il pulsante Riepilogo Modifiche va ad aprire un’altra form contenente il
dettaglio dei protocolli come da figura seguente:

RiepilogoAssegnazioniRuoli.cs

35
7. CONCLUSIONI

Lo sviluppo della base dati e del prototipo software per la sua gestione si è
concluso con esito positivo.

Le funzionalità principali dell’applicazione disponibili agli operatori sono:

 Gestione delle anagrafiche dei dipendenti e relativi reparti e sedi.

 Gestione degli applicativi e dei ruoli correlati ad essi.
 Possibilità di creazione di nuove pratiche di modifica ruoli dei dipendenti.

Il vantaggio principale ottenuto dall’utilizzo di questo applicativo per gli

operatori dell’azienda sanitaria è la tracciabilità delle operazioni di modifica dei
ruoli effettuate, oltre che la memorizzazione dei ruoli assegnati ai dipendenti.

Il lavoro svolto può essere quantificato principalmente in:

 Progettazione e creazione di un database contenente 9 tabelle.
 8 viste create in Sql Server.
 15 trigger implementati in Sql Server.
 3 stored procedures create.
 500 righe di codice non autogenerato in Visual Studio.

Lo sviluppo futuro del progetto riguarderà , dopo presa visione del prototipo da
parte del cliente, aggiunta di ulteriori funzionalità utili per il prodotto finale,
miglioramenti per quanto riguarda i vincoli non funzionali del prodotto, una fase
di test e collaudo in sede seguita da installazione e messa in opera
dell’applicativo finale.

36
8. BIBLIOGRAFIA

Atzeni, Ceri, Paraboschi, Torlone “Basi di dati: modelli e linguaggi di

interrogazione”, Mc Graw-Hill

Groh, Stockman, Powell, Prague, Irwin, Reardon “Microsoft Office – Access 2007
Bible” , Wiley Publishing

M. Fermeglia “Slides del corso di complementi di basi di dati”

Google Home Page, http://www.google.com

Microsoft Developer Network, http://msdn.microsoft.com

37