Esplora E-book
Categorie
Esplora Audiolibri
Categorie
Esplora Riviste
Categorie
Esplora Documenti
Categorie
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
Il personale della struttura che si intende gestire solo quello medico ed amministrativo.
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
CARTELLA
RICOVERO
MEDICO
CARTELLA
PAZIENTE
RICOVERO
PAZIENTE
REPARTO
PERSONALE
REPARTO
RICOVERO
PRIMARIO
MEDICO
PRIMARIO
REPARTO
MEDICO
PERSONALE
PAZIENTE
RICOVERO
REPARTO
MEDICO
AMMINISTRATIVO
MEDICO
RICOVERO
REPARTO
PRIMARIO
PERSONALE
DEGENZA
DEGENZA
PAZIENTE
MEDICO
AMMINISTRATIVO
RICOVERO
PERSONALE
ACCETTAZIONE
ACCETTAZIONE
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.
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.
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)
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
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
TIPO
E
E
R
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.
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
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.
TIPO
E
ACCESSO
L/S
NUMERO
1/1
TIPO
E
E
R
ACCESSO
L
L
S
NUMERO
1
1
1
TIPO
E
ACCESSO
L/S
NUMERO
1/1
TIPO
E
ACCESSO
L/S
NUMERO
1/1
13
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.
14
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
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.
[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
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
19
AGGIORNAMENTO DEGENZA
AGGIORNAMENTO RICOVERO
20
AGGIORNAMENTO AMMINISTRATIVO
AGGIORNAMENTO MEDICO
21