A.A.

2008/09

Database Ospedaliero
Elaborato 02 di Basi di Dati
Si effettui la progettazione concettuale e logica della base di dati motivando se necessario le
scelte di progetto.

Studente:

Prof. :

CASORIA PELLEGRINO
CERCIELLO RAFFAELLA
COLICCHIO ELEONORA
ESPOSITO VINCENZO

534/3489
534/3475
534/3320
534/3476

A. CHIANESE - V. MOSCATO

[A-De]
[A-De]
[A-De]
[Df- M]

SPECIFICHE DI PARTENZA
Si vuole progettare una base di dati per una struttura ospedaliera che contenga informazioni relative sia ai
pazienti sia ai ricoveri fatti nellospedale. Dei pazienti devono essere conservate le usuali informazioni
anagrafiche e quelle relative alla propria cartella clinica, dove sono contenuti i dati anamnestici e le terapie
in corso. La base dei dati deve tenere traccia di tutti i ricoveri fatti nellospedale con data di ricovero e di
dimissione e il reparto, identificato da un codice, in cui il paziente stato ricoverato. Devono essere inoltre
gestite, per ogni ricovero, le informazioni relative ai medici ed al personale amministrativo che lo hanno
seguito. In particolare il personale amministrativo interviene nella fase di accettazione, mentre quello
medico nella fase di degenza. Per ciascun reparto deve essere memorizzato il relativo consulente medico
primario. Devono essere, infine, gestite le informazioni relative ai medici ed al personale amministrativo
afferenti alla struttura, con relativo nome, cognome e del reparto presso cui ogni medico lavora.
Specifiche sulle Operazioni
A regime nellarco del prossimo biennio la Base di Dati dovr gestire la seguente mole di informazioni:
circa 10000 ricoveri
8000 dei quali si conoscono gi le informazioni
2000 dei quali sono nuovi ricoveri attesi [gestiti in media da 2 medici]
circa 5000 pazienti
4000 dei quali si conosce lanagrafica
1000 dei quali sono nuovi pazienti attesi
circa 300 tra medici e personale amministrativo
50 amministrativi
250 medici [in media afferiscono a 2 reparti]
circa 20 reparti

Le principali operazioni previste sulla Base di Dati sono:

inserimento di un nuovo paziente che deve avvenire contestualmente alla generazione della sua

cartella clinica [FREQUENZA: 3 volte al giorno]

aggiornamento della cartella clinica di un paziente [FREQUENZA: 20 volte al giorno]
inserimento di un nuovo ricovero [FREQUENZA: 5 volte al giorno]
inserimento/aggiornamento delle degenze [FREQUENZA: 10 volte al giorno]
aggiornamento delle informazioni legate ai ricoveri [FREQUENZA: 20 volte al giorno]
aggiornamento delle afferenze dei medici ai reparti [FREQUENZA: 1 volta al mese]
aggiornamento delle informazioni del personale medico [FREQUENZA: 1 volta a semestre]
aggiornamento del personale amministrativo [FREQUENZA: 1 volta a semestre]

Il personale della struttura che si intende gestire solo quello medico ed amministrativo.

ANALISI DEI REQUISITI

Strutturazione dei Requisiti
Al fine di avere una visione pi chiara di quelli che sono gli obiettivi che ci prefiggiamo di raggiungere, si
scelto di effettuare una prima settorializzazione delle specifiche fornite, suddividendo in blocchi le
informazioni relative ai singoli concetti ritenuti fondamentali per la realt che ci accingiamo a
rappresentare.

INFORMAZIONI GENERALI
Si vuole progettare una base di dati per una struttura ospedaliera che contenga informazioni
relative sia ai pazienti sia ai ricoveri fatti nellospedale.

DATI PAZIENTE
Dei pazienti devono essere conservate le usuali informazioni anagrafiche e quelle relative alla
propria cartella clinica, dove sono contenuti i dati anamnestici e le terapie in corso.

DATI RICOVERO
La base dei dati deve tenere traccia di tutti i ricoveri fatti nellospedale con data di ricovero e di
dimissione e il reparto, identificato da un codice, in cui il paziente stato ricoverato. Devono essere
inoltre gestite, per ogni ricovero, le informazioni relative ai medici ed al personale amministrativo
che lo hanno seguito.

DATI REPARTO
Per ciascun reparto deve essere memorizzato il relativo consulente medico primario.

DATI PERSONALE
Deve essere, infine, gestite le informazioni relative ai medici ed al personale amministrativo
afferenti alla struttura con relativo nome, cognome e del reparto presso cui ogni medico lavora. In
particolare il personale amministrativo interviene nella fase di accettazione, mentre quello medico
nella fase di degenza. Il personale della struttura che si intende gestire solo quello medico ed
amministrativo.

Per chiarificare ulteriormente i concetti appena esposti, abbiamo raccolto in forma schematica le specifiche
forniteci dal committente, indicando con il termine OSPEDALE la realt di interesse che siamo intenzionati a
rappresentare.

OSPEDALE
PAZIENTE (Anagrafica, Cartella)
RICOVERO (Data_Ricovero, Data_Dimissione, Reparto, Paziente, Medico, Amministrativo)
REPARTO (Codice, Nome, Primario)
MEDICO (Reparto)
PERSONALE (Nome, Cognome)
AMMINISTRATIVO
CARTELLA (Anamnestici, Terapie)

Si preferito introdurre il concetto CARTELLA [caratterizzato dai campi Anamnestici e Terapie] a causa della
sua natura di informazione strutturata. Noto, inoltre, che il Personale dellospedale risulta composto
3

esclusivamente da Medici ed Amministrativi, si optato per una rappresentazione del tipo sopraesposto al
fine di evidenziare le informazioni comuni ad entrambi e, al tempo stesso, quelle relative ai singoli concetti.
Glossario dei Termini
Riportiamo nel seguito una spiegazione pi dettagliata dei termini ritenuti rilevanti allinterno delle
specifiche fornite.
TERMINE

DESCRIZIONE

TERMINI COLLEGATI

PAZIENTE

Individuo ricoverato almeno una volta allinterno della

struttura ospedaliera.

CARTELLA
RICOVERO
MEDICO

CARTELLA

Documento contenente tutte le informazioni riguardanti

un determinato paziente, relative sia allattuale ricovero
che a quelli eventualmente successivi. Una volta
assegnata, viene aggiornata o modificata di volta in volta
al sopraggiungere di nuove informazioni.

PAZIENTE

RICOVERO

Sistemazione di un paziente allinterno della struttura

ospedaliera in seguito ad un malessere di varia natura.

PAZIENTE
REPARTO
PERSONALE

REPARTO

Sezione di un ospedale adibita al trattamento di una

determinata patologia e dotata di un proprio medico
primario.

RICOVERO
PRIMARIO
MEDICO

PRIMARIO

Medico incaricato della supervisione di un dato reparto

della struttura ospedaliera. ammesso un unico
primario per ciascun reparto.

REPARTO
MEDICO

PERSONALE

Insieme dei dipendenti assunti dallospedale, composto

esclusivamente da medici ed amministrativi.

PAZIENTE
RICOVERO
REPARTO
MEDICO
AMMINISTRATIVO

MEDICO

Individuo facente parte dello staff ospedaliero ed

incaricato della cura dei pazienti ricoverati ad egli
assegnati. Pu, inoltre, assumere la carica di medico
primario di al pi un reparto presente nellospedale.

RICOVERO
REPARTO
PRIMARIO
PERSONALE
DEGENZA

DEGENZA

Permanenza a letto per malessere di varia natura

allinterno dellospedale considerato.

PAZIENTE
MEDICO

AMMINISTRATIVO

Individuo facente parte dello staff ospedaliero ed

incaricato della fase di accettazione.

RICOVERO
PERSONALE
ACCETTAZIONE

ACCETTAZIONE

Fase di registrazione di un ricovero relativo ad un

paziente.

PAZIENTE
AMMINISTRATIVO

Abbiamo deciso di non specificare alcun sinonimo per i termini sopraelencati [diversamente dalla struttura
di norma utilizzata] in quanto ritenuti superflui ai fini dellanalisi e per lassenza di vocaboli di una
complessit tale da renderne necessaria la presenza. I Termini Collegati, inoltre, sono stati scelti sulla
base di logiche riflessioni definite in relazione alle specifiche rese disponibili dal committente.

PROGETTAZIONE CONCETTUALE
Terminata la fase di Analisi dei Requisiti, nella quale abbiamo cercato di rielaborare le specifiche in una
forma pi schematica ed esente da eventuali ambiguit, possiamo procedere alla progettazione di un
Diagramma E-R, ovvero una rappresentazione grafica della realt di interesse in termini di Entit costituenti
ed Associazioni tra queste ultime.
Scelta della Strategia
Si impone, a questo punto, la necessit di scegliere una strategia da seguire nella progettazione: piuttosto
che procedere mediante un approccio di tipo puramente Top-Down o Bottom-Up, abbiamo optato per una
strategia Ibrida, fusione delle caratteristiche di entrambe le precedenti. Tale metodologia risulta, infatti,
molto pi flessibile delle altre, in quanto lascia a noi progettisti la libert di adattare le scelte a seconda
delle esigenze in modo molto intuitivo, senza essere vincolati da procedure statiche e prefissate che
potrebbero comportare difficolt nel raggiungimento dello schema finale.
Si avvisa che, per la realizzazione del Diagramma E-R nelle varie fasi di sviluppo, si fatto uso del Tool
Applicativo JDER 1.3 [Java Diagrammi ER], sviluppato da Alessandro Ballini. A causa, per, degli evidenti
limiti presenti nellapplicazione *tra cui limpossibilit di rappresentare attributi composti], siamo stati
costretti ad effettuare alcune modifiche manuali agli schemi originariamente prodotti dal tool.
Scheletro del Diagramma E-R
Abbiamo individuato, a partire dai concetti evidenziati nel corso delle prime fasi di Analisi, le entit
autonome e significative della nostra realt di interesse e le associazioni che le legano: la scelta ricaduta
su PAZIENTE, REPARTO e PERSONALE, collegati tra loro dallassociazione Ricovero. Poich, in tempi diversi,
un paziente pu essere ricoverato in vari reparti e seguito da personale differente, lentit PAZIENTE
partecipa allassociazione Ricovero con cardinalit (1,N). Sulla base di analoghe considerazioni sono state
scelte le cardinalit relative alle altre Entit. Al fine di indicare il legame che intercorre tra il PERSONALE ed
il REPARTO in cui tali dipendenti lavorano, abbiamo aggiunto unulteriore associazione Afferenza tra le due.
Essendo il personale composto da differenti ruoli, non necessariamente una sua occorrenza deve afferire
ad uno o pi reparti [cardinalit (0,N)], mentre, viceversa, un reparto non ha ragione di esistere se non gli
viene preventivamente assegnato alcun dipendente che lavori al suo interno [cardinalit (1,N)].

Aggiunta Attributi
Partendo dallo schema base elaborato nella fase precedente, abbiamo aggiunto alle varie entit ed
associazioni i relativi attributi ricavati dalle specifiche, indicando al tempo stesso gli Identificatori scelti per
ciascuna di esse. Mentre lattributo ID_Reparto, appartenente allentit REPARTO, si prestava a ricoprire
tale funzione, le altre entit non disponevano di alcun attributo che potesse identificarle in maniera
univoca [per la presenza di soli attributi composti in PAZIENTE e linefficienza dellidentificatore
(Nome,Cognome) nel caso di omonimie in PERSONALE]: per tale motivo si resa necessaria laggiunta degli
attributi ID_Paziente ed ID_Personale nelle rispettive entit. Si noti, inoltre, luso dellIdentificatore Esterno
su Ricovero: le sole entit, infatti, non risultano sufficienti allindividuazione univoca delle occorrenze di tale
associazione, ma necessitano anche degli ulteriori attributi Data_Inizio e Data_Fine [propri di Ricovero], in
quanto uno stesso paziente potrebbe avere pi ricoveri in un medesimo reparto e con medesimo
personale, ma in momenti diversi. Abbiamo infine trattato Anagrafica e Cartella, per come definiti nelle
specifiche, come attributi composti.

Diagramma E-R FINALE

Da una pi approfondita analisi delle specifiche, ci siamo resi conto di come lassociazione Ricovero risulti
essere un concetto indipendente dalle entit che legava, ragion per cui abbiamo preferito effettuare la
sostituzione di questultima con unomonima entit. Le cardinalit relative alle entit che prima legava sono
rimaste invariate da quelle indicate nella versione precedente del diagramma E-R [quando partecipavano
ancora allex-associazione Ricovero], mentre, al contrario, la nuova entit RICOVERO partecipa
allassociazione Assegnazione con cardinalit (1,1), Gestione con cardinalit (1,N) ed Attribuzione con
cardinalit (1,1), che rispettivamente la relazionano con le entit PAZIENTE, REPARTO e PERSONALE. Il
motivo di questultima scelta va ricercato nel fatto che ogni ricovero relativo ad un solo paziente,
assegnato ad un determinato reparto, ma gestito da uno o pi medici.
Si noti la decisione di definire lattributo Data_Fine come opzionale, in quanto non disponibile allatto
dellaccettazione, ma reso noto solo al termine della degenza relativa ad un determinato paziente [oppure
nel caso di memorizzazione di informazioni relative a ricoveri passati]. Il solo attributo Data_Inizio non
risultava, inoltre, sufficiente allidentificazione univoca delle occorrenze di tale entit [Data_Fine, essendo
opzionale, non pu essere preso in considerazione]: questo ci ha costretto a dover usufruire, mediante
6

Identificatore Esterno, anche degli identificatori di PERSONALE e REPARTO. [non stato possibile fare
riferimento anche a PERSONALE per via della cardinalit (1,N) dellassociazione Gestione+
Constatato che il personale della struttura ospedaliera risulta composto soltanto da medici ed
amministrativi, di entrambi dei quali siamo intenzionati a conoscere gli attributi Nome e Cognome, abbiamo
preferito trasformare lentit PERSONALE in una generalizzazione totale e disgiunta *stabilita lassenza di
sovrapposizione dei ruoli], specializzandola nelle entit figlie AMMINISTRATIVO e MEDICO. La scelta
motivata, oltre che dalla presenza di attributi comuni, dal fatto che solo un medico, diversamente da un
amministrativo, ha ragione di afferire ad un determinato reparto: la generalizzazione ci ha quindi permesso
di legare REPARTO esclusivamente a MEDICO [sfruttando lassociazione Afferenza gi definita], ma
imponendo la partecipazione obbligatoria dellentit MEDICO alle occorrenze di tale associazione
[cardinalit (1,N)], diversamente da come avveniva negli schemi precedenti. Laggiunta dellattributo
Specializzazione, non richiesto dalle specifiche, ci sembrato opportuno, nellottica che un medico venga
assegnato ad dato reparto in virt, appunto, della propria specializzazione.
Si noti , infine, laggiunta di unulteriore associazione Primario sempre tra le entit MEDICO e REPARTO,
indicante per ciascun reparto il corrispettivo medico primario: osservando che non tutti i medici possono
ricoprire tale ruolo, mentre ad un reparto deve necessariamente essere assegnato un proprio primario, si
spiegano le cardinalit visibili nella figura sottostante. Ovviamente avremmo potuto assegnare un attributo
Primario, di tipo Booleano, allassociazione Afferenza, con la funzione di specificare se, allinterno di
unoccorrenza di questultima, il medico risulti anche ricoprire il ruolo di primario di quel determinato
reparto. Questo avrebbe, per, comportato linapplicabilit di tale informazione su un numero di
occorrenze molto superiore a quelle in cui risultava, invece, applicabile [ammettendo ogni reparto uno ed
un solo primario, avremmo avuto, per come definito nelle specifiche, 230 occorrenze dellattributo prive di
informazione]. Tale considerazione stata ritenuta sufficiente a scartare questa alternativa in favore di
quella descritta in precedenza.

Dizionario dei Dati: ENTIT

Riportiamo ora in forma schematica tutte le informazioni relative alle Entit presenti nel Diagramma E-R
finale, specificando per ognuna di esse nome, elenco degli attributi ed il proprio identificatore. Nel caso
della generalizzazione, abbiamo utilizzato la notazione [NOME_ENTIT_PADRE] Attributo per indicare
quanti e quali attributi sono stati ereditati da unentit figlia dal corrispettivo padre.
RICOVERO
Sistemazione di un paziente allinterno della struttura ospedaliera in seguito ad un malessere di
varia natura.

Data_Inizio: data in cui ha avuto inizio il ricovero

Data_Fine: data in cui terminato il ricovero

IDENTIFICATORE: Data_Inizio, ID_Paziente, ID_Reparto
PAZIENTE
Individuo ricoverato almeno una volta allinterno della struttura ospedaliera.

ID_Paziente: identificativo di un paziente

Anagrafica: insieme delle informazioni relative al paziente. composto da:

Cod_Fiscale
Nome
Cognome
Data_Nascita
Cartella: documento contenente le informazioni relative al paziente. composto da:
Anamnestici
Terapie
IDENTIFICATORE: ID_Paziente
REPARTO
Sezione di un ospedale adibita al trattamento di una determinata patologia.

ID_Reparto: identificativo di un reparto

Nome: nome del reparto

IDENTIFICATORE: ID_Reparto
PERSONALE
Insieme dei dipendenti assunti dallospedale.

ID_Personale: identificativo di un membro del personale

Nome: nome del dipendente

Cognome: cognome del dipendente

IDENTIFICATORE: ID_Personale
AMMINISTRATIVO
Individuo facente parte dello staff ospedaliero ed incaricato della fase di registrazione di un
ricovero relativo ad un paziente.

[PERSONALE] ID_Personale: identificativo di un amministrativo

[PERSONALE] Nome: nome dellamministrativo

[PERSONALE] Cognome: cognome dellamministrativo

IDENTIFICATORE: ID_Personale
MEDICO
Individuo facente parte dello staff ospedaliero ed incaricato della cura dei pazienti ricoverati ad egli
assegnati.

[PERSONALE] ID_Personale: identificativo di un medico

[PERSONALE] Nome: nome del medico

[PERSONALE] Cognome: cognome del medico

Specializzazione: campo in cui il medico si specializzato

IDENTIFICATORE: ID_Personale

Dizionario dei Dati: RELAZIONI

Riportiamo ora in forma schematica tutte le informazioni relative alle Associazioni presenti nel Diagramma
E-R finale, specificando per ognuna di esse nome ed Entit coinvolte ed indicando, sia per associazioni che
per entit, le relative cardinalit.

ASSEGNAZIONE
Relaziona i diversi pazienti con i relativi ricoveri.

PAZIENTE

RICOVERO
ATTRIBUZIONE
Associa ad ogni ricovero il relativo reparto e, viceversa, ad ogni reparto i relativi ricoveri.

RICOVERO

REPARTO

(1,N)
(1,N)
(1,1)
(1,N)
(1,1)
(1,N)

GESTIONE
Relaziona ad un dato ricovero il personale che si occupa della sua gestione.

RICOVERO

PERSONALE

(N,N)

AFFERENZA
Relaziona i medici con i reparti di afferenza.

MEDICO

REPARTO

(N,N)

PRIMARIO
Relaziona un dato reparto con il proprio medico primario.

MEDICO

REPARTO

(1,1)

(1,N)
(1,N)

(1,N)
(1,N)

(0,1)
(1,1)

UML: Diagramma delle Classi

Mediante linguaggio UML risulta ugualmente possibile esprimere i concetti esposti nel Diagramma E-R
ottenuto precedentemente: per tale motivo abbiamo utilizzato un Diagramma delle Classi per poter
rappresentare la nostra realt in termini di classi ed associazioni. Si fa notare come gli attributi composti
Anagrafica e Cartella siano stati definiti come strutture a parte, legate a PAZIENTE tramite unaggregazione
stretta.

Siamo ricorsi alle potenzialit del linguaggio OCL [Object Constraint Language], il quale si serve di una
sintassi molto simile al linguaggio naturale, al fine di sopperire alle mancanze del linguaggio UML, tra cui
limpossibilit di indicare gli identificatori nel Diagramma delle Classi. Riportiamo, perci, nel seguito la
sintassi relativa alla segnalazione degli identificatori interni ed esterni relativi a ciascuna classe sopra
descritta, in cui abbiamo fatto in parte ricorso al linguaggio naturale.
OCL

CONTEXT Paziente
INV: ID_Paziente = Identificatore Interno
CONTEXT Ricovero
INV: Data_Inizio = Identificatore Interno
INV: ID_Paziente = Identificatore Esterno
INV: ID_Reparto = Identificatore Esterno
CONTEXT Personale
INV: ID_Personale = Identificatore Interno
CONTEXT Reparto
INV: ID_Reparto = Identificatore Interno

10

PROGETTAZIONE LOGICA: TRASFORMAZIONE

Analisi delle Prestazioni
In questa ulteriore fase vogliamo effettuare alcune valutazioni di efficienza del diagramma E-R ricavato
nella fase di progettazione concettuale: ovviamente i valori riscontrati non saranno altro che Indici di
Prestazione, ovvero valori orientativi su cui basare eventuali osservazioni e, generalmente, non
corrispondenti alle reali prestazioni della Base Dati ottenuta da una futura implementazione fisica
[fortemente dipendenti dallarchitettura su cui si intende operare].
Riportiamo, quindi, di seguito la TAVOLA DEI VOLUMI, indicante il numero di occorrenze previste a regime
per ciascuna Entit e Relazione. Mentre i volumi delle entit sono statici sono stati forniti quasi
completamente dalle specifiche, quelli relativi alle varie associazioni sono stati ricavati sulla base di logiche
osservazioni. Si notino, in particolare, i valori associati a Gestione ed Afferenza, calcolati considerando che
ogni ricovero gestito in media da due medici, che generalmente afferiscono a due reparti, ed un
amministrativo.
CONCETTO
RICOVERO
PAZIENTE
CARTELLA
PERSONALE
MEDICO
AMMINISTRATIVO
REPARTO
GESTIONE
ASSEGNAZIONE
ATTRIBUZIONE
POSSESSO
AFFERENZA
PRIMARIO

TIPO
E
E
E
E
E
E
E
R
R
R
R
R
R

VOLUME
10000
5000
5000
300
250
50
20
30000
10000
10000
5000
500
20

Sfruttando i valori contenuti nella tabella precedente, stato possibile ricavare la TAVOLA DEI
CONTRIBUTI, il cui campo CONTRIBUTO rappresenta una misura media della partecipazione delle
occorrenze di una determinata entit alle occorrenze delle associazioni da cui sono legate [CONTRIBUTO =
Vol_Relazione/Vol_Entit].
RELAZIONE

VOLUME

ENITIT

VOLUME

CONTRIBUTO

10000

GESTIONE

30000

RICOVERO

GESTIONE

30000

PERSONALE

300

100

ASSEGNAZIONE

10000

PAZIENTE

5000

ASSEGNAZIONE

10000

RICOVERO

10000

ATTRIBUZIONE

10000

RICOVERO

10000

ATTRIBUZIONE

10000

REPARTO

20

500

POSSESSO

5000

CARTELLA

5000

POSSESSO

5000

PAZIENTE

5000

AFFERENZA

500

MEDICO

250

AFFFERENZA

500

REPARTO

20

25

PRIMARIO

20

MEDICO

250

0.08

PRIMARIO

20

REPARTO

20

11

Abbiamo, inoltre, elaborato unulteriore tabella, denominata TAVOLA DELLE OPERAZIONI, riportante in
forma schematica la frequenza con cui le operazioni definite nelle specifiche verranno effettuate sulla Base
Dati.
OPERAZIONE
Inserimento/Aggiornamento delle degenze.
Inserimento di un nuovo ricovero.
Inserimento di un nuovo paziente.
Aggiornamento della cartella clinica di un paziente
Aggiornamento delle informazioni legate ai ricoveri
Aggiornamento delle afferenze dei medici ai reparti
Aggiornamento delle informazioni del personale medico
Aggiornamento del personale amministrativo

TIPO
I
I
I
I
I
I
I
I

FREQUENZA
10
5
3
20
20
1
1
1

PERIODO
Giorno
Giorno
Giorno
Giorno
Giorno
Mese
Semestre
Semestre

In ultima analisi abbiamo definito, per ogni operazione, le cosiddette TAVOLE DEGLI ACCESSI, indicando
allinterno il numero ed il tipo [Lettura o Scrittura] di accessi alle entit e relazioni coinvolte. Si avvisa che
con il termine Aggiornamento stata intesa esclusivamente la modifica delle informazioni gi presenti nella
Base Dati. Si noti, inoltre, che laccesso in L/S per alcune operazioni legato al fatto che tutte le
informazioni necessarie allindividuazione di una data occorrenza di un entit sono presenti allinterno
dellentit stessa, motivo per cui necessario un primo accesso per lindividuazione dellinformazione da
modificare ed un secondo accesso per la modifica vera e propria.
INSERIMENTO DELLE DEGENZE
CONCETTO
GESTIONE

TIPO
R

ACCESSO
S

NUMERO
1

ACCESSO
L
L
S

NUMERO
1
1
1

AGGIORNAMENTO DELLE DEGENZE

CONCETTO
RICOVERO
MEDICO
GESTIONE

TIPO
E
E
R

INSERIMENTO DI UN NUOVO RICOVERO

CONCETTO
RICOVERO
ASSEGNAZIONE
ATTRIBUZIONE
GESTIONE

TIPO
E
R
R
R

ACCESSO
S
S
S
S

NUMERO
1
1
1
3

Linserimento di un nuovo ricovero non implica soltanto lassegnazione di valori agli attributi propri di RICOVERO, ma
necessita anche del collegamento di questultimo al relativo paziente, reparto, amministrativo e medico curante. Il
numero di accessi in scrittura allassociazione Gestione si giustifica ricordando che un ricovero gestito mediamente
da due medici e da un singolo amministrativo.

INSERIMENTO DI UN NUOVO PAZIENTE

CONCETTO
PAZIENTE

TIPO
E

ACCESSO
S

NUMERO
1

La creazione della cartella clinica relativa al paziente inserito, definita come attributo composto, avviene
contemporaneamente allassegnazione dei valori degli altri attributi dellentit, in occasione dellunico accesso a
PAZIENTE. Nel caso in cui fosse stata definita unentit CARTELLA per lomonimo concetto, linserimento di un paziente
avrebbe necessitato un preventivo inserimento della corrispettiva cartella e, naturalmente, la scrittura della relazione
legante tale entit con PAZIENTE.

12

 AGGIORNAMENTO DELLA CARTELLA CLINICA DI UN PAZIENTE

CONCETTO
PAZIENTE

TIPO
E

ACCESSO
L/S

NUMERO
1/1

Anche in questo caso, se avessimo definito unentit CARTELLA, avremmo avuto un accesso in lettura in PAZIENTI che,
mediante una lettura dellassociazione intercorrente tra le due, ci avrebbe permesso di raggiungere e sovrascrivere la
cartella cercata.

AGGIORNAMENTO DELLE INFORMAZIONI RELATIVE AI RICOVERI

CONCETTO
RICOVERI

TIPO
E

ACCESSO
L/S

NUMERO
1/1

AGGIORNAMENTO DELLE AFFERENZE DEI MEDICI AI REPARTI

CONCETTO
MEDICO
REPARTO
AFFERENZA

TIPO
E
E
R

ACCESSO
L
L
S

NUMERO
1
1
1

AGGIORNAMENTO DELLE INFORMAZIONI DEL PERSONALE MEDICO

CONCETTO
MEDICO

TIPO
E

ACCESSO
L/S

NUMERO
1/1

AGGIORNAMENTO DEL PERSONALE AMMINISTRATIVO

CONCETTO
AMMINISTRATIVO

TIPO
E

ACCESSO
L/S

NUMERO
1/1

Analisi delle Ridondanze

Data lassenza di operazioni di conteggio o di ricavo di informazioni dalle entit o relazioni presenti nel
nostro diagramma, abbiamo ritenuto superfluo effettuare uno studio delle ridondanze, in quanto non
significative allinterno della nostra realt di interesse.

Eliminazione di Attributi Composti

Non possibile procedere allelaborazione di uno schema logico per la nostra realt di interesse senza
effettuare preventivamente alcune operazioni di trasformazione sullo schema concettuale sopra definito:
prima fra tutte la rielaborazione degli eventuali attributi composti presenti allinterno del diagramma E-R.
Nel nostro caso, gli attributi su cui risulta necessario operare sono Anagrafica e Cartella di PAZIENTE, il
primo, come sappiamo, costituito dai campi Cod_Fiscale, Nome, Cognome e Data_Nascita, il secondo da
Anamnestici e Terapie. La traduzione stata effettua utilizzando le usuali tecniche di risoluzione, ovvero
riducendo le singole componenti dellattributo composto ad attributi atomici propri dellentit PAZIENTE. A
valle di questa operazione, lutilizzo dellidentificatore ID_Paziente si rivelato superfluo, in quanto un
codice fiscale risulta pi che sufficiente per lindividuazione univoca di un determinato paziente. Per tale
motivo lelevazione di Cod_Fiscale ad identificatore delle occorrenze di suddetta entit ha comportato la
cancellazione dellormai inutile attributo ID_Paziente.

13

Eliminazione delle Gerarchie

A questo punto si rivela necessario dover risolvere la generalizzazione PERSONALE del nostro Diagramma ER, altrimenti non traducibile in uno schema logico. Prima di procedere nella scelta dobbiamo, per,
effettuare alcune considerazioni legate non solo al tipo di generalizzazione che ci troviamo a trattare, ma
anche alle operazioni ed ai volumi di dati specificati negli appositi paragrafi *vedi Analisi delle Prestazioni+.
Innanzitutto si noti come le operazioni relative a tale generalizzazione siano sempre riferite alle singole
entit figlie AMMINISTRATIVO e MEDICO e non a tutto il personale assunto dalla struttura ospedaliera.
Dalla tavola dei volumi si evince, inoltre, come il volume delle occorrenze di PERSONALE sia proprio pari
alla somma di quelle di AMMINISTRATIVO e MEDICO [in termini numerici, 50 + 250 = 300], ovvero ad ogni
occorrenza dellentit padre corrisponde sempre una ed una sola occorrenza di una delle due entit figlie.
Tale risultato appare coerente con la definizione della generalizzazione di tipo Totale Disgiunto. La
convergenza di queste tre caratteristiche fa si che la scelta di accorpare lentit padre nei figli [i quali
acquisteranno tutti gli attributi in precedenza assegnati al padre] risulti la pi appropriata per la realt da
noi considerata. A seguito di ci, lassociazione Gestione stata specializzata in Accettazione e Degenza [le
quali relazionano RICOVERO rispettivamente con AMMINISTRATIVO e MEDICO], con laccortezza di
impostare la cardinalit (1,1) per RICOVERO sullassociazione Accettazione, nellottica che un ricovero possa
essere gestito da un unico amministrativo. Lattributo ID_Personale, inoltre, stato rinominato in
ID_Amministrativo ed ID_Medico, con lintento di evitare confusione e dare maggiore leggibilit al nostro
schema.

Split di Entit
A seguito di una rilettura della Tavola delle Operazioni definita nel paragrafo Analisi delle Prestazioni, si
osservato che, tra le operazioni effettuate pi frequentemente, figura laggiornamento delle cartelle
cliniche relative ai diversi pazienti [20 volte al giorno]. Allo stato attuale il nostro Diagramma E-R non
ottimizzato per la gestione di tale operazione, in quanto la presenza di un numero elevato di attributi
allinterno dellentit PAZIENTE rende alquanto problematica leventuale ricerca di una determinata
cartella per effettuarne la modifica. Per ovviare al problema abbiamo preferito raggruppare in ununica
entit, denominata appunto CARTELLA, tutti gli attributi relativi alle cartelle cliniche dei vari pazienti
[Anamnestici e Terapie], aggiungendo lattributo ID_Cartella quale Identificatore Interno, e legando tale
nuova entit a PAZIENTE tramite lassociazione Possesso [avente cardinalit (1,1)]. Laumento di memoria
necessario allallocazione fisica dellentit CARTELLA stato ritenuto irrilevante in confronto allincremento
dellefficienza operazionale raggiunta grazie a tale configurazione.

Scelta degli Identificatori

Levidente complessit dellidentificatore scelto per lentit RICOVERO ci ha spinto a ricercare una
soluzione pi efficiente. Abbiamo, perci, definito un attributo ID_Ricovero da utilizzare in alternativa al
precedente identificatore, in quanto meno oneroso in termini di occupazione di memoria e, soprattutto, di
pi semplice gestione.

14

Diagramma E-R TRASFORMATO

A seguito della fase di trasformazione il Diagramma E-R definitivo, privato di tutte le generalizzazioni ed
attributi composti, assumer la seguente conformazione.

UML: Diagramma delle Classi TRASFORMATO

Analogamente a quanto fatto per il Diagramma E-R, riportiamo nel seguito il Diagramma delle Classi nella
forma assunta al seguito della fase di trasformazione, indicando, anche in questo caso, il corrispondete
codice OCL.

15

OCL

CONTEXT Paziente
INV: Cod_Fiscale = Identificatore Interno
CONTEXT Cartella
INV: ID_Cartella = Identificatore Interno
CONTEXT Ricovero
INV: ID_Ricovero = Identificatore Interno
CONTEXT Amministrativo
INV: ID_Amministrativo = Identificatore Interno
CONTEXT Medico
INV: ID_Medico = Identificatore Interno
CONTEXT Reparto
INV: ID_Reparto = Identificatore Interno

PROGETTAZIONE LOGICA: TRADUZIONE

Possiamo finalmente concentrarci sulla traduzione del nostro Diagramma E-R nello schema logico, ovvero
una rappresentazione in termini di relazioni e vincoli dai cui partire per la successiva fase di progettazione
fisica della Base Dati commissionata.
Nel caso di associazioni uno a uno ed uno a molti, la traduzione stata effettuata eliminando lassociazione
considerata ed assegnando alla relazione che traduce una delle entit coinvolte [quella dal lato 1] gli
identificatori delle altre, definendoli come Chiavi Esterne. In riferimento, quindi, alle associazioni Possesso,
Assegnazione, Attribuzione, Accettazione e Primario, lo schema assume la forma seguente.
PAZIENTI (cod_fiscale, nome, cognome, data_nascita, codCartella: CARTELLE)
CARTELLE (ID_cartella, anamnestici, terapie)
RICOVERI (ID_ricovero, data_inizio, data_fine, codPaziente: PAZIENTI, codReparto: REPARTI,
codAmministrativo: AMMINISTRATIVI)
AMMINISTRATIVI (ID_amministrativo, nome, cognome)
MEDICI (ID_medico, nome, cognome, specializzazione)
REPARTI (ID_reparto, nome, primario: MEDICI)
Nel caso di associazioni molti a molti, invece, lassociazione considerata stata trasformata in una relazione
avente come Chiave Primaria ed Esterna gli identificatori delle entit coinvolte. Per le associazioni Degenza
ed Afferenza avremo, perci, il seguente schema logico.
DEGENZE (codMedico: MEDICI, codRicovero: RICOVERI)
AFFERENZE (codMedico: MEDICI, codReparto: REPARTI)

16

Riportiamo nel seguito, infine, il cosiddetto Cammino di Join, ovvero una rappresentazione intuitiva dello
schema appena trovato, in funzione dei vincoli di integrit referenziale.

Verifica Forma Normale

Lo schema relazionale da noi ottenuto potrebbe malauguratamente non essere quello ottimale per la
progettazione di una Base Dati consistente: per tale motivo ci resta da fare unultima operazione di verifica
della forma normale in cui tale schema risulta trovarsi. Riteniamo sufficientemente consistente uno schema
in BCNF [Boyce e Codd Normal Form]. Nel caso questo non sia verificato, dovremo effettuare delle
operazioni di modifica delle relazioni individuate fino al raggiungimento di tale forma, in modo da
permettere ad un differente team di sviluppo di procedere allimplementazione fisica della Base Dati.
Possiamo preventivamente escludere dalla nostra verifica le relazioni DEGENZE ed AFFERENZE, in quanto,
essendo costitute da una singola coppia di attributi, sono gi, per definizione, in BCNF.
Avendo provveduto, in fase di traduzione, alleliminazione degli attributi composti *vedi Eliminazione
Attributi Composti+, sappiamo per certo che tutti gli attributi presenti nel nostro schema sono di tipo
atomico: per cui la 1NF sicuramente verificata. Si noti, inoltre, che le uniche dipendenze funzionali
riscontrate sono quelle relative alle chiavi, eccetto che nelle relazioni PAZIENTI e REPARTI, dove abbiamo:
codCartella (cod_fiscale, nome, cognome, data_nascita)
primario (ID_reparto, nome)
nome (ID_reparto, primario)

[PAZIENTI]
[REPARTI]
[REPARTI]

Dal momento, per, che tali determinanti sono anche candidati chiave per le relazioni considerate, la
definizione di BCNF sussiste, permettendoci di affermare che tutto lo schema logico da noi elaborato in
BCNF.
17

GRAFICI UML AGGIUNTIVI

In conclusione della nostra progettazione riportiamo una serie di diagrammi UML che potranno essere di
ausilio per eventuali progettazioni future da parte di differenti team di sviluppo.
Use Case Diagram
Tale grafico esprime le operazioni che possono essere effettuate dai differenti utenti che accederanno alla
Base Dati, ovvero DBA, Amministrativo e Medici. Con Gestione Ospedale, per il DBA, si intende una
qualsiasi delle operazioni permesse alle altre categorie di utenti. Si noti, inoltre, la scelta di indicare
esclusivamente le operazioni enunciate nelle specifiche fornite.

Activity Diagram
I seguenti diagrammi di flusso mostrano la sequenza di attivit da effettuare per lesecuzione di un
determinato caso duso.
INSERIMENTO PAZIENTE

18

 AGGIORNAMENTO CARTELLA

INSERIMENTO RICOVERO [CARTELLA preventivamente creata PAZIENTE non ancora creato]

19

 AGGIORNAMENTO DEGENZA

AGGIORNAMENTO RICOVERO

20

 AGGIORNAMENTO AMMINISTRATIVO

AGGIORNAMENTO MEDICO

21