Capitolo 5

Progettazione del database.

 

 

 

In questo capitolo verrà descritto in modo approfondito il processo di creazione del database che funge da base all’applicazione. Possiamo vedere questo processo come due blocchi separati: il processo di creazione del database che gestisce le cartelle cliniche e quello che gestisce le rappresentazioni iconiche delle immagini. Tratteremo separatamente i due processi per poi evidenziare il link tra di essi. Alla fine verrà visualizzato il flow-chart che descrive il database completo e l’elenco delle tabelle mentre per la visualizzazione del codice di creazione delle tabelle si rimanda all’appendice A.

 

5.1 Database di gestione delle cartelle cliniche.

Il Diagramma E-R.

Per organizzare in maniera opportuna tutte le informazioni della cartella clinica, si sono seguiti i passi standard della progettazione logica, a partire dalla costruzione del diagramma entità-relazione che fornisce una rappresentazione schematica delle entità coinvolte e delle relazioni esistenti tra esse.

Nel definire la struttura del database si è fatto in modo di evitare la ripetizione e la ridondanza dei dati e le conseguenti anomalie ed incongruenze, utilizzando il processo di normalizzazione. Il diagramma che ne risulta, rappresentante la struttura del database, è in 3NF in quanto per nessuna relazione sono presenti attributi multivalore, attributi che dipendono funzionalmente da sottoinsiemi della chiave o attributi che dipendono transitivamente dalla chiave.

Dall’analisi della situazione del mondo reale che si vuole descrivere sono state individuate cinque entità (vedi fig 5.1); ciascuna di esse può essere definita tramite un opportuno predicato proposizionale:

PAZIENTE = { X | X è persona che si sottopone ad almeno un

esame clinico presso lo studio medico}

L’entità PAZIENTE ha come attributi tutti i dati anagrafici del paziente e come chiave il codice fiscale, in quanto è tale informazione che nella realtà consente di identificare in maniera univoca una persona.

MALATTIA = { Z | Z è una malattia infettiva di cui X ha presentato

regolare denuncia, X Î PAZIENTE}

L’entità MALATTIA è un’entità debole in quanto l’esistenza di un’occorrenza Z Î MALATTIA dipende dall’esistenza di un’occorrenza X Î PAZIENTE, e per definire tale entità si fa ricorso alla relazione R tra PAZIENTE e MALATTIA (relazione di esistenza); per tale ragione un’entità debole è definibile solo attraverso una proposizione predicativa a due variabili. Dal punto di vista semantico, questo significa che la registrazione di una malattia ha senso solo se esiste un paziente che l’ha denunciata.

L’unico attributo dell’entità MALATTIA è il nome della malattia stessa.

CARTELLA CLINICA = { Y | Y è un documento che registra i dati relativi

ad X, X Î PAZIENTE}

L’entità CARTELLA CLINICA ha come attributi il numero di pratica e l’anno di archiviazione che ne costituiscono la chiave. Essa è un’entità debole che dipende dall’entità PAZIENTE in quanto, semanticamente, ha senso avere una cartella clinica solo se esiste un paziente a cui essa è associata.

MODULO DI ACCETTAZIONE = { V | V è il modulo che registra lo stato

di X al momento dell’accettazione, X Î PAZIENTE}

L’entità MODULO DI ACCETTAZIONE ha come attributi gran parte delle informazioni di carattere medico previste ed ha come chiave un numero di modulo.

La presenza di questa entità è stata ritenuta utile per gestire la situazione in cui uno stesso paziente si rivolge allo studio medico più volte per diversi motivi. Una cartella viene creata ed associata ad un paziente solo la prima volta che egli si presenta allo studio medico, mentre le volte successive viene aperto un nuovo modulo di accettazione nell’ambito della stessa cartella, in cui si riporta la diagnosi di accettazione, l’esame obiettivo e l’anamnesi relativi al nuovo evento patologico.

ESAME = { T | T è una prestazione diagnostica o terapeutica}

La presenza di questa entità è giustificata dalla necessità da parte dell’utente medico di disporre di una tabella di consultazione che per ogni tipo di esame riporti la descrizione di tale esame e associ ad esso un codice riconosciuto convenzionalmente a livello internazionale. L’entità ESAME ha come attributi tali informazioni ed in più un attributo ‘nota’ che specifica il tipo di ambulatorio presso il quale tale prestazione è erogabile; la chiave dell’entità è costituita dal codice dell’esame.

Sono state, inoltre, individuate quattro relazioni tra le suddette entità; ciascuna di esse può essere definita tramite un opportuno predicato proposizionale a due variabili:

ASSOCIATO_A = { (X,Y) | X è associato a Y; X Î PAZIENTE, Y Î

CARTELLA}

La relazione ASSOCIATO_A rappresenta l’associazione tra un paziente e la sua cartella clinica; in particolare, essa costituisce la relazione di esistenza per l’entità CARTELLA CLINICA. E’ una relazione 1:1 che non ha attributi propri; la sua chiave è composta dal codice fiscale del paziente e dal numero di pratica e anno di archiviazione della sua cartella clinica;

CONTIENE = {(Y,V) | V è contenuto in Y; V Î MODULO DI

ACCETTAZIONE, Y Î CARTELLA}

La relazione CONTIENE rappresenta l’associazione tra il modulo di accettazione di un paziente e la sua cartella clinica che funge da raccoglitore per tutti i moduli di quel paziente. E’ una relazione 1:N che non ha attributi propri; la sua chiave è composta dal numero di pratica e dall’anno di archiviazione della cartella clinica e dal numero di modulo del modulo di accettazione.

HA_DENUNCIATO = { (X,Z) | X ha esposto regolare denuncia

dichiarando di aver contratto Z; X Î PAZIENTE, Z Î MALATTIA}

La relazione HA_DENUNCIATO rappresenta l’associazione tra un paziente e le malattie infettive da lui denunciate; in particolare, essa costituisce la relazione di esistenza per l’entità MALATTIA. E’ una relazione N:M che ha come attributo proprio la data della denuncia; la sua chiave è composta dal codice fiscale del paziente ed dal nome della malattia denunciata;

HA_EFFETTUATO = { (X,T) | X si è sottoposto a T; X Î PAZIENTE,

T Î ESAME}

La relazione HA_EFFETTUATO rappresenta l’associazione tra un paziente e gli esami clinici a cui si è sottoposto; è una relazione N:M che ha come attributi propri la data in cui il paziente ha effettuato l’esame ed il referto di tale esame. La chiave della relazione è composta dal codice fiscale del paziente, dal codice dell’esame effettuato e dalla data in cui è stato effettuato.

In conclusione, il diagramma entità-relazione normalizzato dà origine al seguente insieme di relazioni:

PAZIENTE (Codice-fiscale, Generalità(Nome, Cognome, Paternità, Data-nascita, Luogo-nascita), Residenza(Indirizzo, Luogo-residenza, Provincia, Regione, Tel.), Professione, Sesso, Stato-civile, Capo-famiglia(Nome, Cognome, Data-nascita, Luogo-nascita))

CARTELLA CLINICA (Numero-pratica, Anno-archiviazione)

MODULO DI ACCETTAZIONE (Numero-modulo, Data-accettazione, Diagnosi-accettazione, Medico-accettante, Esame-obiettivo, Anamnesi)

ESAME (Codice, Nome-esame, Descrizione, Nota, Tariffa)

ASSOCIATO_A (Codice-fiscale, Numero-pratica, Anno-archiviazione)

CONTIENE (Numero-pratica, Anno-archiviazione, Numero-modulo)

HA_EFFETTUATO (Codice-fiscale, Codice, Data-esame, Referto)

HA_DENUNCIATO (Codice-fiscale, Nome-malattia, Data-denuncia)

Come già precedentemente detto, in un database relazionale ad ogni relazione corrisponde una tabella avente per colonne gli attributi della relazione e per righe le occorrenze (tuple) della relazione stessa.

L’implementazione

Attraverso un’attenta analisi sono emerse alcune necessità di carattere pratico; in particolare, affinché si possa accedere ai dati di una stessa cartella clinica in modo più veloce ed efficiente sarebbe utile che tutti i moduli di accettazione di uno stesso paziente siano memorizzati insieme in modo da condividere gli stessi blocchi di memoria. Ciò può essere realizzato attraverso l’uso di un cluster, una struttura dati che l’RDBMS Oracle usa per memorizzare insieme diverse tabelle che condividono colonne comuni dette cluster key. In questo modo tutte le righe necessarie per una join sulla cluster key si trovano nello stesso blocco e poiché tali cluster key vengono memorizzate solo una volta, a prescindere dal numero di righe delle differenti tabelle che contengono quei valori, oltre al miglioramento della performance delle join ci sarà un conseguente vantaggio in termini di spazio e tempi di accesso.

Nel nostro caso, i campi condivisi da tutti i moduli di accettazione che fanno parte di una cartella clinica sono il numero di pratica e l’anno di archiviazione, ma tale informazione non è inclusa nell’entità MODULO DI ACCETTAZIONE così come definita nel diagramma E-R. Affinché l’entità possa soddisfare la condizione richiesta è stato necessario unificare la catena di relazioni CARTELLA --- CONTIENE --- MODULO DI ACCETTAZIONE in un’unica relazione ACCETTAZIONE che ha tali caratteristiche.

La relazione ACCETTAZIONE ha come attributi Numero-pratica, Anno-accettazione, Numero-modulo, Data-accattazione, Diagnosi-accettazione, Medico-accettante, Esame-obiettivo, Anamnesi, di cui i primi tre ne costituiscono la chiave primaria.

Continuando l’analisi del diagramma E-R segue un’altra importante considerazione: poiché è possibile avere più moduli accettazione in una stessa cartella clinica, ognuno a sua volta legato ad un particolare evento patologico, risulta necessario mantenere la corrispondenza tra esami effettuati dal paziente e l’evento patologico per cui sono stati descritti, ma ciò non è possibile fino a quando il diario clinico resta legato al paziente e non alla sua cartella clinica. Per questo è stato necessario trasformare la relazione HA_EFFETTUATO tra pazienti ed ESAME nella relazione REGISTRA, semanticamente equivalente, tra ACCETTAZIONE ed ESAME. La relazione REGISTRA ha gli stessi attributi della relazione HA_EFFETTUATO tranne il Codice-fiscale che, avvalendosi della corrispondenza 1:1 tra Codice-fiscale e la coppia Numero-pratica, Anno-archiviazione, viene sostituito con quest’ultima. Inoltre, per poter mantenere la corrispondenza tra esami prescritti ed evento patologico è stato necessario aggiungere l’attributo Numero-modulo.

Nella relazione REGISTRA così ottenuta, per tutti gli esami di uno stesso paziente viene riportato anche il Numero-pratica e Anno-archiviazione; di conseguenza, è sembrato logico memorizzare negli stessi blocchi tali informazioni utilizzando, ancora una volta, un cluster mantenendo vicine righe correlate ed evitando la duplicazione di informazioni condivise.

Viene clusterizzata la tabella corrispondente alla relazione REGISTRA e la cluster key è la coppia di campi Numero-pratica, Anno-archiviazione.

Si può pensare di includere nel cluster anche la tabella corrispondente alla relazione ASSOCIATO_A che condivide la stessa cluster key; in questo modo verranno memorizzate insieme non solo le informazioni relative a tutti gli esami effettuati da un paziente, ma anche il corrispondente Codice-fiscale che rappresenta il collegamento alle informazioni anagrafiche del paziente.

A questo punto converrebbe introdurre nel cluster anche la tabella corrispondente alla relazione HA_DENUNCIATO facendo in modo che per ogni paziente, quindi in corrispondenza di un valore della cluster key Numero-pratica, Anno-archiviazione, vengono memorizzate insieme oltre alle informazioni riguardanti gli esami effettuati dal paziente, anche quelle relative a particolari malattie regolarmente denunciate dal paziente stesso.

Per poter realizzare ciò, occorre modificare la relazione HA_DENUNCIATO tra PAZIENTE e MALATTIA nella relazione RIPORTA, semanticamente equivalente, tra ACCETTAZIONE e MALATTIA. La relazione RIPORTA ha gli stessi attributi della relazione HA_DENUNCIATO ad eccezione del Codice-fiscale che, avvalendosi della corrispondenza 1:1 esistente tra Codice-fiscale e la coppia Numero-pratica, Anno-archiviazione, viene sostituita con quest’ultima.

Attraverso questa organizzazione dei dati si è cercato di memorizzare fisicamente insieme, in blocchi contigui, tutti i dati relativi ad una stessa cartella clinica cercando di ottimizzare lo spazio a disposizione ed i tempi necessari per accedere ai dati.

In conclusione, sono state create le seguenti tabelle:

ed il seguente cluster:

 

5.2 Database di gestione delle immagini.

Diagramma E-R.

Per costruire il database di immagini mediche e loro rappresentazioni iconiche e consentire un’efficiente implementazione della strategia di ricerca proposta, è necessario individuare quali siano le strutture dati più opportune da utilizzare e, prima ancora, definire le entità e le relazioni coinvolte nella progettazione, così da poter costruire il relativo diagramma E-R.

Tale diagramma deve essere in grado di descrivere la situazione reale, ovvero quella in cui si vuole gestire un archivio di immagini mediche. Un’immagine, referto di un esame diagnostico, viene inclusa in tale archivio solo se contiene un’anomalia, ovvero una patologia visibile attraverso l’immagine stessa sotto forma di ‘hot spot’. Per poter realizzare il recupero delle immagini archiviate in base al loro contenuto, è necessario, inoltre, che ad ogni immagine sia legata la sua rappresentazione iconica e, quindi, che ad ogni anomalia siano associate informazioni relative alle sue caratteristiche geometrico-morfologiche e alla sua posizione nell’immagine rispetto agli altri oggetti in essa presenti.

Come conseguenza immediata di quanto precedentemente detto, sono state individuate le entità IMMAGINE e ANOMALIA e la relazione CONTIENE definite come segue:

IMMAGINE = { X | X è un’immagine referto di un esame diagnostico}

ANOMALIA = {Y | Y è una patologia visibile attraverso l’immagine}

CONTIENE = {(X,Y) | Y è visibile in X, Y Î ANOMALIA e X Î IMMAGINE}.

L’entità IMMAGINE ha come attributo un codice, che la identifica univocamente e che la lega al paziente al quale appartiene e a tutti gli altri dati ad esso relativi, ed il contenuto informativo dell’immagine stessa, ossia il flusso binario che la codifica.

L’entità ANOMALIA ha come attributi un codice che la classifica, le sue caratteristiche geometrico-morfologiche e la sua posizione nell’immagine rispetto agli oggetti canonici.

La relazione CONTIENE rappresenta l’associazione tra un’immagine medica e l’anomalia che essa contiene. Essa è una relazione 1:N, in quanto una stessa immagine potrebbe contenere diverse anomalie, non ha attributi propri e la sua chiave è composta dal codice dell’immagine e dal codice che classifica l’anomalia in essa presente.

Il diagramma E_R corrispondente è il seguente:

Poiché nell’Intersection of Similar Triples strategy la posizione dell’anomalia è data rispetto agli altri oggetti presenti nell’immagine ed è espressa sotto forma di un insieme di triple, l’attributo posizione è in realtà un macroattributo composto dagli attributi semplici oggetto-canonico, relazione-x, relazione-y ; esso è, inoltre, un attributo non atomico perché per ogni anomalia ci sono più triple che ne individuano la posizione nell’immagine e, quindi, il diagramma E-R risultante, mostrato nella figura 5.2 che segue, non è in prima forma normale.

Per portare il diagramma E-R in terza forma normale, si è ritenuto necessario effettuare ‘un’operazione di shift2’ dell’attributo non atomico Posizione, dando origine all’entità TRIPLA e alla relazione E’-POSIZIONATA-DA. L’entità e la relazione risultanti da uno shift hanno, per definizione, rispettivamente, come chiave un attributo semanticamente equivalente all’attributo shiftato e, molteplicità pari a quella di tale attributo. Le due nuove relazioni possono essere definite come segue:

TRIPLA = {Z | Z è una sequenza di tre simboli separati da virgole che

codifica la posizione di Y rispetto ad un oggetto,

YÎ ANOMALIA}.

E’_POSIZIONATA_DA = {(Y, Z) | Z individua la posizione di Y rispetto ad

un oggetto canonico, Y Î ANOMALIA

e Z Î TRIPLA}.

L’entità TRIPLA ha come attributi l’oggetto canonico, la relazione spaziale dell’anomalia rispetto all’oggetto canonico lungo l’asse x e la relazione spaziale dell’anomalia rispetto all’oggetto canonico lungo l’asse y; l’insieme di questi tre attributi rappresenta la chiave dell’entità. Più precisamente, le istanze dell’entità TRIPLA sono tutti e soli gli elementi dell’insieme prodotto cartesiano Ob x Op x Op, dove Ob è l’insieme degli oggetti canonici previsti per il particolare tipo di immagine medica in esame ed Op è l’insieme dei sette operatori spaziali della tavola 3.2 del capitolo 3.

La relazione E’_POSIZIONATA_DA rappresenta l’associazione tra un’anomalia e tutte le triple che ne individuano la posizione nell’immagine. Essa è una relazione N:M in quanto, data un’anomalia, ci saranno più triple che insieme ne determinano la posizione, una per ogni oggetto canonico presente nell’immagine che contiene l’anomalia; viceversa, data una tripla ci saranno più anomalie che condividono le stesse relazioni spaziali rispetto all’oggetto nella tripla. La chiave della relazione è composta dal codice che individua l’anomalia, dall’oggetto canonico rispetto al quale si sta posizionando l’anomalia, e dalle relazioni spaziali lungo entrambi gli assi tra tale oggetto e l’anomalia. Il diagramma E-R definitivo è il seguente:

Tale diagramma E-R dà, quindi, vita al seguente insieme di relazioni:

IMMAGINE (codice-immagine, contenuto-informativo)

ANOMALIA (codice-anomalia, densità, uniformità, orientazione, spreadness, convessità, area, asimmetria)

TRIPLA (oggetto-canonico, relazione-x, relazione-y)

CONTIENE (codice-immagine, codice-anomalia)

E’_POSIZIONATA_DA (codice-anomalia, oggetto-canonico, relazione-x, relazione-y)

Come si nota, il diagramma E-R definitivo, che comprende le entità e le relazioni relative ad entrambe le fasi del motore di ricerca, è in 3NF in quanto per nessuna relazione sono presenti attributi multivalore, attributi che dipendono funzionalmente da sottoinsiemi della chiave o attributi che dipendono transitivamente da essa.

L’implementazione del diagramma E-R

Una prima modifica al diagramma E-R nasce dalla considerazione che la relazione CONTIENE tra IMMAGINE e ANOMALIA, che è stata inizialmente rappresentata come una relazione 1:N, può essere considerata una relazione 1:1, se vale l’ipotesi in cui ogni immagine è archiviata con una sola anomalia; infatti, in questo caso, i concetti di immagine e anomalia si sovrappongono, essendo l’immagine archiviata solo quando in essa è presente un’anomalia, e non ha più senso identificare le due entità con due codici diversi. Questo ragionamento ha condotto alla fusione della catena di relazioni CONTIENE -- ANOMALIA in un’unica relazione IMMAGINE_CON_ANOMALIA i cui attributi sono le sei caratteristiche geometrico-morfologiche dell’anomalia e la cui chiave è il codice dell’immagine che contiene tale anomalia. Alla nuova relazione corrisponde una tabella del database, chiamata GEO_MORPH, le cui colonne sono esattamente gli attributi della relazione.

La relazione IMMAGINE funge da trait d’union tra il database della gestione delle cartelle cliniche e quello del trattamento delle immagini. Infatti essa viene inglobata dalla tabella DIARIO_CLINICO come campo Referto. In realtà essa ha vari campi quali il nome del file e soprattutto il codice del referto che poi fa da riferimento alle tabelle che gestiscono i dati delle immagini.

Il diagramma E-R presentato comporta, inoltre, la creazione di altre due tabelle corrispondenti alle relazioni TRIPLA ed E’_POSIZIONATA_DA; tuttavia, analizzando le informazioni che esse contengono, si è ritenuto opportuno implementare solo la relazione E’_POSIZIONATA_DA considerando, però in essa, non il codice dell’anomalia, ma, per i motivi suddetti, il codice dell’immagine.

Nella relazione E’_POSIZIONATA_DA esistono numerose tuple che condividono una stessa tripla, ovvero tutte quelle relative ad immagini che presentano la stessa relazione spaziale relativamente ad uno stesso oggetto. E’ sembrato, quindi, opportuno memorizzare fisicamente insieme, negli stessi blocchi di memoria i record corrispondenti a tali tuple, ottenendo in questo modo il duplice effetto di mantenere vicine righe correlate ed evitare la duplicazione delle informazioni condivise.

Per memorizzare fisicamente insieme record correlati è necessario che essi condividano il valore di uno o più campi; questa è, infatti, la condizione necessaria in un database Oracle affinché si possa utilizzare un cluster. I cluster costituiscono un metodo opzionale per memorizzare i dati delle tabelle. Le tabelle che fanno parte di un cluster condividono colonne comuni dette cluster key, i cui valori verranno memorizzati una sola volta, indipendentemente dal numero di righe delle differenti tabelle che contengono quei valori, con conseguente vantaggio in termini di spazio e tempi di accesso. Soprattutto le join beneficiano dell’uso dei cluster, in quanto tutte le righe necessarie per una join sulla cluster key si trovano nello stesso blocco e ciò migliora la performance delle query. Nella maggior parte dei casi i cluster sono gruppi di tabelle, anche detti cluster multi-table, tuttavia in alcuni casi ha senso clusterizzare anche una sola tabella, per esempio, quando tale tabella viene usata spesso nelle join con se stessa, oppure quando è costituita da molte righe e molte colonne, e le sue righe hanno valori comuni in una o più colonne. In quest’ultimo caso utilizzando un cluster si ha la garanzia che l’ordine delle righe nella tabella sia tale che tutte quelle che condividono il valore della colonna cluster key siano fisicamente memorizzate l’una di seguito all’altra nello stesso blocco, essendo così tutte facilmente e velocemente reperibili conoscendo il valore cluster key, la quale rappresenta l’indice del cluster stesso. Ricordando quanto detto nel capitolo terzo, a proposito della strutturazione dei dati più oppurtuna per l’implementazione della prima fase della strategia di ricerca proposta, si intuisce immediatamente come il cluster rappresenti la struttura dati più adatta a tale scopo; infatti, scegliendo la combinazione di colonne corrispondenti alle componenti delle triple come cluster key, il cluster implementa in maniera automatica la corrispondenza tra ogni possibile tripla ordinata e tutte le immagini nel database che contengono tale tripla nella loro rappresentazione iconica e consente, a partire dalla tripla stessa, l’accesso diretto ad esse.

Si è pensato, quindi, di creare un cluster, SPATIAL_CLU, che contenesse la tabella, SPATIAL_REL, corrispondente alla relazione E’_POSIZIONATA_DA, la cui cluster key fosse la terna di colonne Oggetto, Relazionex, Relazioney.

Riassumendo, l’implementazione della strategia di ricerca proposta impone la creazione delle seguenti strutture dati all’interno del database:

I links tra le due tabelle Spatial_rel e Geo_morph, e tra queste e la tabella Imaggini contenente le immagini reali, sono stati implementati tramite il concetto di foreign key.

 

5.3 Flow chart completo del database.

Per completare la strutura del database, in relazione alle esigenze dell’applicazione abbiamo creato altre due tabelle:

In più, visto che nell’esecuzione dell’applicazione dobbiamo sempre fare riferimento ai dati principali del paziente abbiamo deciso di spostare i campi Nome,Cognome e Data_nasc dalla tabella PAZIENTI alla tabella ASSOCIAZIONE.

Nelle figure seguenti sono visualizzate le tabelle con i rispettivi campi ed il flow-chart completo del database.

Tabelle:

Associazione

Nprat

Number (6,0)

Anno

Number (4,0)

Codfisc

Varchar2 (16)

Cognome

Varchar2 (30)

Nome

Varchar2 (20)

Data_nasc

Date

 

Pazienti

Codfisc

Varchar2 (16)

Luogo_nasc

Varchar2 (35)

Sesso

Char (1)

Luogo_res

Varchar235)

Indirizzo

Varchar2 (60)

Prov_res

Varchar2 (2)

Regione

Varchar2 (21)

Tel

Varchar2 (16)

Prov_nasc

Varchar2 (2)

Padre

Varchar2 (20)

Profess

Varchar2 (30)

Stato_civ

Varchar2 (15)

Nome_cf

Varchar2 (20)

Cognome_cf

Varchar2 (30)

Data_nasc

Date

Luogo_nasc

Varchar2 (35)

 

Denunce

Nprat

Number (6,0)

Anno

Number (4,0)

Malattia

Varchar2 (30)

Data

Date

Accettazioni

Nprat

Number (6,0)

Anno

Number (4,0)

Nmodulo

Number (4,0)

Data

Date

Medico

Varchar2 (50)

Diagnosi

Varchar2 (240)

Esame_obiettivo

Varchar2 (1600)

Anamnesi

Varchar2 (2000)

Esami

Codice

Varchar2 (7)

Nome_esame

Varchar2 (150)

Descrizione

Varchar2 (700)

Tariffa

Number

Nota

Varchar2 (1)

 

Diario_clinico

Nprat

Number (6,0)

Anno

Number (4,0)

Nmodulo

Number (4,0)

Cod_esame

Varchar2 (7)

Data_esame

Date

Note

Varchar2 (1000)

Immagine

Varchar2 (50)

Codref

Number (7,0)

Geomorph

Viid

Number (7,0)

Area

Number (10,4)

Densità

Number (10,4)

Asimmetria

Number (10,6)

Orientazione

Number (10,7)

Spreadness

Number (10,5)

Uniformità

Number (10,5)

Convessità

Number (1,0)

FileBMP

Varchar2 (30)

SizeX

Number (4,0)

SizeY

Number (4,0)

Spatial_rel

Viid

Number (7,0)

Oggetto

Number (2,0)

RelX

Number (3,0)

RelY

Number (3,0)

Canonici

Viid

Number (7,0)

FileBMP

Varchar2 (50)

Desc

Varchar2 (70)

SizeX

Number (4,0)

SizeY

Number (4,0)

 

 

 

 

Home