A short project created using Oracle 10g to manage the sale and management of medical devices complies with EEC 93/42.

1. ANNO 2013/2014
UNIVERSITA’ DEGLI STUDI DI NAPOLI
FEDERICO II FACOLTA’ DI INGEGNERIA
STUDENTI: GALLO SEBASTIAN, ROSALINDA CARFORA, ARTURO ESPOSITO
DOCENTE:VINCENZO MOSCATO
ORACLE PROJECT
BASI DI DATI PER LA VENDITA E LA GESTIONE DEI
DISPOSITIVI MEDICI

2. PAGINA 1
PRESENTAZIONE DEL PROGETTO
Per essere venduti all’interno dell’unione Europea i prodotti devono
essere conformi alle direttive di prodotto e pertinenti ad essere marcati
CE(figura 1).
FIGURA 1
I requisiti per i dipositivi medici sono più restrittivi rispetto alla
maggior parte delle altre categorie ed in molti casi il produttore deve
obbligatoriamente rivolgersi ad un Organismo notificato per apporre il
marchio CE sul dispositivo.
Per il nostro progetto ci siamo riferiti alla direttiva Europea CE 93/42 la
quale si riferisce ai dispositivi medici in generale, e recepita in Italia con
il D.Lgs 46/97 obbligatoria dal 14/6/1998. Abbiamo intenzionalmente
tralasciato i Dispositivi Medici per Diagnostica in vitro e Dipositivi
medici impiantabili attivi contemplati rispettivamente nelle direttive
98/79/CE e dalla 90/385/CEE.
I passi da seguire per la conformita alla 93/42 CE sono:
1. CLASSIFICAZIONE DEL PRODOTTO: i dispositivi medici sono
raggruppati in funzione della loro complessità e rischio per il
paziente in 4 classi: I, IIa, IIb, III. La classificazione dipende
anche dalla destinazione d’uso indicata dal fabbricante.
I. Classe I: sono i dispositivi medici non attivi. In linea di
massima le procedure di valutazione della conformità possono
essere svolte sotto la sola responsabilità del fabbricante
(autocertificazione) a meno che il dispositivo non sia sterile o di

3. PAGINA 2
misura ed in quel caso c’è bisogno dell’intervento dell’
Organismo Notificato.
II. Classe IIa: sono dispositivi non invasivi utilizzati per la
conservazione o la canalizzazione del sangue o per la
conservazione di organi o controllo di alcuni parametri vitali.
L’ organismo notificato deve effettuare determinati controlli
durante la fase di fabbricazione
III. Classe IIb: sono apparecchi non invasivi intesi a modificare la
composizione biologica o chimica del sangue o di altri liquidi
corporei,dispositivi impiantabili ed i dispositivi e quelli invasivi
a lungo termine di tipo chirurgico. E’ necessario il controllo da
parte dell’ Organismo Notificato sia nella fase di progettazione
sia nella fase di fabbricazione dei DM (per la
commercializzazione dei dispositivi della III classe occorre una
esplicita autorizzazione di conformità preliminare).
IV. Classe III: sono apparecchi invasivi destinati alla diagnosi alla
correzione dei difetti del cuore o del sistema cardiocircolatorio
centrale attraverso contatto diretto con dette parti del corpo
etc.. Essi seguono un iter uguale al precedente.
2. Individuata la classe del dispositivo, l’Organismo notificato
certifica ed appone il marchio CE a seconda della classe del
dispositivo e controlla la documentazione fornite dal produttore.
Tali documenti riguardano:
A. Technical file: dettagli di costruzione e validazione della
conformità del dispositivo
B. Valutazione rischio: valutazione sui materiali utilizzati,
biocompatibilità, etc..
C. Certificazione sulla Qualità dei processi: di solito è rischiesta la
conformità all’ ISO 13458.
Inoltre il produttore deve monitorare i proprio dispositivi una volta
immessi sul mercato per poter, così, intervenire in caso di guasto.

4. PAGINA 3
E’ di fondamentale importanza ricordare che il produttore è obbligato a
mantenere la documentazione per almeno 5 anni.
Per essere facilmente reperibili, i dispositivi medici sono codificati
mediante codifica CIVAB.
La codifica CIVAB rappresenta un sistema univoco di riconoscimento di
una parte consistente delle tecnologie biomediche presenti sul mercato
nazionale, utilizzabile in tutto il processo di acquisto e di gestione di
tali beni.
Il codice , è costituito da una stringa di 8 caratteri alfanumerici
attraverso la quale si individuano:
XXX.YYY.ZZ
A. la classe di tecnologia (primi tre caratteri) (es: ECT =
ecotomografo);
B. la ditta produttrice (seconda terna di caratteri);
C. lo specifico modello di tecnologia di quella classe e di quel
produttore (ultimi due caratteri)
Attualmente vengono codificate tutte le apparecchiature sanitarie e
alcune importanti categorie di consumabilii (reagenti diagnostici,
pellicole radiografiche, cardiostimolatori e defibrillatori cardiaci
impiantabili, protesi ortopediche, cateteri angiografici, filtri per
emodialisi).
OBIETTIVO:
Nel rispetto della direttiva 93/42/CE si vuole tenere traccia dei
dispositivi medici venduti, ad Aziende Ospedaliere, marchiati CE
(mediante autocertificazione del produttore o attraverso l’intervento di
Organismi notificati). Si vuole inoltre avere informazioni circa le
vendite effettuate dall’Azienda produttrice.

5. PAGINA 4
PROGETTAZIONE CONCETTUALE:
QUALITA’ DELLO SCHEMA CONCETTUALE:
I. Correttezza: lo schema rappresenta correttamente
(sintatticamente e semanticamente) i requisiti iniziali;
II. Completezza: lo schema rappresenta tutti i requisiti;
III. Minimalità: lo schema rappresenta solo i requisiti e ogni
loro aspetto appare solo una volta;
IV. Leggibilità: lo schema è facile da interpretare ed esprime i
requisiti in modo naturale;
V. Modificabilità: lo schema può essere facilmente
modificato se i requisiti cambiano;
VI. Auto-documentabilità: lo schema non ha bisogno di
materiale aggiuntivo esterno.
ANALISI DEI REQUISITI:
DATI_AZIENDA_PRODUTTRICE: Devono essere gestite le
informazioni relative all’ azienda produttrice del dispositivo/i
medico/i quali: Nome, Sede(via, civico, città, cap ), Recapito.
DATI_CERTIFICAZIONI: per ogni certificazione(documento)
redatto dall’ Azienda produttrice si vogliono mantenere le
informazioni relative alla descrizione, all’identificativo, alla data di
redazione e scadenza della certificazione. Si vuole tener traccia
solo delle certificazioni tecniche, sul rischio o relativo all’ ISO.
DATI_ISTITUTO_OSPEDALIERO: devono essere gestite le
informazioni riguardanti gli istituti ospedalieri coinvolti
nell’acquisto dei dispositivi/o medico/i quali: Identificativo,
Nome, Indirizzo, Città, Recapito.
DATI_VENDITA: dati relativi alla vendita del dispositivo medico
da parte dell’Azienda Produttrice; quali:
Identificativo,destinazione d’uso e data.

6. PAGINA 5
DATI_DIPOSITIVO_MEDICO: devono essere gestite
informazioni relative al dispositivo medico il quale può essere
attivo o non attivo a seconda che abbia una specifica
alimentazione(elettrica o non) o no sia alimentato.I dispositivi
non attivi sono di classe I e quest’ultimi divisi fra dispositivi
sterili/misura ed altri. I dispositivi medici attivi possono essere di
classe IIa, IIb, III.
DATI_ORGANISMO NOTIFICATO: devono essere gestite
informazioni riguardo all’organismo notificato quali:
Identificativo, nome, sede legale, Paese, Recapito. Un Organismo
Notificato controlla la certificazione dell’ Azienda Produttrice e
appone il marchio CE secondo la 93/42/CE sui dispositivi medici
attivi e su quelli sterili e di misura.
E’ inoltre utile ai fini dell’analisi ricordare che un’ Azienda produttrice
Autocertifica alcuni dispositivi di classe I e monitora tutti i dispositivi
medici da essa venduti.
MODELLO E/R
Il modello E-R si basa su un insieme di concetti molto vicini alla realtà
d’interesse; codesto non è quasi mai sufficiente da solo a rappresentare
nel dettaglio tutti gli aspetti di un'applicazione per varie ragioni.
Innanzitutto in uno schema E-R compaiono solo i nomi dei vari
concetti in esso presenti ma questo può essere insufficiente per
comprenderne il significato. Nel caso di schemi particolarmente
complessi può accadere di non riuscire a rappresentare in maniera
comprensibile ed esaustiva i vari concetti.
Per questo motivo è indispensabile corredare ogni schema E-R con una
documentazione di supporto che possa servire a facilitare
l'interpretazione dello schema stesso e a descrivere proprietà dai dati
rappresentati.

7. PAGINA 6
STRATEGIE DI PROGETTAZIONE
L’obiettivo è, da tali specifiche, ricavare il modello E/R. A tal fine
bisogna individuare quali sono le entità e capire quali sono i legami
concettuali tra le entità. Nella progettazione delle basi di dati esistono
delle giuste strategie (top-down, botton - up, inside - out, miste) che
consentono di raggiungere il suddetto obiettivo. Useremo l’approccio
MISTE mediante i seguenti passi:
Individuazione, in termini di entità e associazioni, dello schema
portante della base di dati
Successivo raffinamento ed estensione dello schema portante,
inserendo tutte le opportune specifiche.
SCHEMA PORTANTE
Dopo aver individuato, dai concetti evidenziati nel corso delle prime
fasi di Analisi, le entità autonome e rilevanti della nostra realtà
d’interesse e le associazioni che le legano; tra questi abbiamo scelto
come Entità:
Aziende
Certificazioni
Vendite
Istituti Ospedalieri
Dispositivi medici
Collegati tra loro con le Associazioni:
Redige
Effettuare
Oggetto
Presso
Monitoraggio
Controllo
Marcatura CE XXXX
Autocertificazione

8. PAGINA 7
Realizziamo dunque uno “SCHELETRO” ovvero uno schema portate
per riuscire ad avere le idee chiare, e iniziare ad avere un modello di
schema relazionale:
VENDITA
DISPOSITIVO
MEDICO
AZIENDA
PRODUTTRICE
ISTITUTO
OSPEDALIERO
CERTIFICAZIONE
ORGANISMO
NOTIFICATO
effettua
oggetto
presso
redige
autocertificazione
marcatura
CExxxx
controllo
(1,1)
(1,1)
(1,N)
(1,N) (1,N)(1,1)(1,1)
(1,N)
(1,N)
(1,1)
(1,1) (0,N)
(1,N)
(1,N)

9. PAGINA 8
RAFFINAMENTI (AGGIUNTA ATTRIBUTI)
Le entità e le associazioni possono essere descritte usando una serie di attributi. Tutti gli
oggetti della stessa classe entità (associazione) hanno gli stessi attributi: questo è ciò che
s’intende quando si parla di oggetti simili. La scelta degli attributi riflette il livello di dettaglio
con il quale si vuole rappresentare le informazioni sulle entità e sulle associazioni. Per ciascuna
classe entità o associazione si definisce una chiave. La chiave è un insieme minimale di attributi
che identifica univocamente un'istanza di entità o associazione.
VENDITA
DISPOSITIVO
MEDICO
AZIENDA
PRODUTTRICE
ISTITUTO
OSPEDALIERO
D.M.
NON ATTIVO
D.M.
ATTIVO
CERTIFICAZIONE
CERT.
TECNICA
CERT.
SUL
RISCHIO
CERT.
ISO
ORGANISMO
NOTIFICATO
CLASSE I
CLASSE IIa
CLASSE IIb
CLASSE III
effettua
oggetto
presso
redige
autocertificazione
marcatura
CExxxx
controllo
NomeId NomeDestinazione d’uso
(1,N) (1,N)(1,1)(1,1)
(1,1)
(0,N)
(1,1)
(1,N)
ALTRO STERILI
MISURA
/
(1,1)
(1,N)
(1,N)
(1,1)
(1,1)
CodCivab
IdId
Id
Id
Nome
Nome
Sede Legale
Data_fine Data_inizioDescrizione
Indirizzo
Telefono
E-mail
Telefono
E-mail
Telefono
Descrizione
Alimentazione
Rischio
Complessità
(1,N)
(1,N)
Cap Civico
ViaCittà
(1,N) (1,N)
Indirizzo
Cap Civico
ViaCittà
(1,N)
Cap Civico
ViaCittà

10. PAGINA 9
PROGETTAZIONE LOGICA
TRASFORMAZIONE
ELIMINAZIONE DI ATTRIBUTI COMPOSTI E MULTIVALORE
Prima di procedere ad uno schema logico che riguarda la nostra realtà di interesse
effettueremo alcune operazoni di “trasformazione” sullo schema concettuale
definito : in primo luogo punteremo alla rielaborazione degli eventuali attributi
composti che sono presenti nel diagramma E/R . Nel nostro caso, gli attributi su
cui risulta necessario operare sono INDIRIZZO e SEDE LEGALE rielaborati come
in figura:
sono stati inoltre eliminati gli attributi multi-valore come TELEFONO e risolti
come segue:

11. PAGINA 10
RISOLUZIONE DELLE GERARCHIE
D.M.
ATTIVO
CLASSE IIa
CLASSE IIb
CLASSE III
D.M.
NON ATTIVO
D.M.
ATTIVO
DISPOSITIVO
MEDICO
CodCivab Nome
Descrizione
Alimentazione
Rischio
Complessità
DISPOSITIVO
MEDICO
CodCivab Nome
Descrizione
Alimentazione
Rischio
Complessità
CDACDNA
(1,1)
(0,1)
(1,1)
(0,1)
D.M.
NON ATTIVO
D.M.
ATTIVO
CodCivab
(0,1)
ALTRO
STERILI
MISURA
CSM
(1,1)
(0,1)
(1,1)
(0,1)
CA
ALTRO STERILE
MISURA
/
CLASSE I
D.M.
ATTIVO
Tipo
D.M.
NON ATTIVO
D.M.
NON ATTIVO
CERTIFICAZIONE
Id Data_fine Data_inizioDescrizione
CERT.
TECNICA
CERT.
SUL
RISCHIO
CERT.
ISO
CERTIFICAZIONE
Id Data_fine Data_inizioDescrizione
Tipo
Soluzione 3
Soluzione 2
Soluzioni 2 e 3
Soluzione 2
/

12. PAGINA 11
SCHEMA ER FINALE
recapito3
TELEFONO
VENDITA
DISPOSITIVO
MEDICO
AZIENDA
PRODUTTRICE
ISTITUTO
OSPEDALIERO
D.M.
NON ATTIVO
D.M.
ATTIVO
CERTIFICAZIONE
ORGANISMO
NOTIFICATO
effettua
oggetto
presso
redige
autocertificazione
marcatura
CExxxx
controllo
NomeId NomeDestinazione d’uso
(1,N) (1,N)(1,1)(1,1)
(1,1) (0,N)
(1,1)
(1,N)
ALTRO
STERILE
MISURA
/
(1,1)
(1,N)
(1,N)
(1,1)
(1,1)
CodCivab
IdId
Id
Id
Nome
Nome
Data_fine Data_inizioDescrizione
E-mailE-mail
Descrizione
Alimentazione
Rischio
Complessità
Tipo
Tipo
CSM
CA
(1,N)
(1,N)
CDACDNA
(1,1)
(0,1)
(1,1)
(0,1)
(1,1)
(0,1)
(1,1)
(0,1)
(1,1)
(1,N)
(1,N)
(1,N)
Numero
Via
Cap
Città
Civico
ViaCittà
CapCivico
Cap
Civico
Via
Città
recapito2
(1,1)
recapito1
(1,1)

13. PAGINA 12
MODELLO LOGICO
TRADUZIONE
La traduzione in relazioni ha portato alle seguenti;
AZIENDE (ID,NOME,VIA,CIVICO,CAP,CITTA,EMAIL)
TELEFONO_AZ (NUMERO,AZIENDA:AZIENDE)
CERTIFICAZIONI (ID, DESCRIZIONE, DATA_IN, DATA FINE,
AZIENDA:AZIENDE,
ORGANISMO_NOTIFICATO:ORGANISMI_NOTIFICATI)
ORGANISMI_NOTIFICATI(ID, NOME, VIA, CIVICO, CAP ,CITTA,
STATO)
TELEFONO_ON
(NUMERO,ORGANISMO_NOTIFICATO:ORGANISMI_NOTIFICATI)
ISTITUTI_OSPEDALIERI(ID,NOME,VIA,CIVICO,CAP,CITTA,EMAIL)
RECAPITO_IO (NUMERO,
ISTITUTO_OSPEDALIERO:ISTITUTI_OSPEDALIERI)
VENDITE (ID_VENDITA,
DESTINAZIONE_USO,
ISTITUTO_OSPEDALIERO:ISTITUTI_OSPEDALIERI)
TRANSIZIONI_EFFETTUATE(AZIENDA:AZIENDE,
VENDITA:VENDITE,DATA)
OGGETTI_VENDUTI (VENDITA:VENDITE,
DISPOSITIVO_MEDICO:DISPOSITIVI_MEDICI))

14. PAGINA 13
DISPOSITIVI_MEDICI(CIVAB,NOME,DESCRIZIONE,ALIMENTAZION
E,RISCHIO,COMPLESSITA,DATA_MAN,AZIENDA:AZIENDE)
DISPOSITIVI_MEDICI_ATTIVI(DISPOSITIVO_MEDICO:DISPOSITI
VI_MEDICI,TIPO,ORGANISMO_NOTIFICATO:ORGANISMI_NOTIFI
CATI)
DISPOSITIVI_MEDICI_NNATT
(DISPOSITIVO_MEDICO:DISPOSITIVI_MEDICI)
DISPOSITIVI_STERILI/MISURA
(DISPOSITIVO_MEDICO_NNATT:DISPOSITIVI_MEDICI_NATT,
ORGANISMO_NOTIFICATO:ORGANISMI_NOTIFICATI)
DISPOSITIVI_ALTRI
(DISPOSITIVO_MEDICO_NATT:DISPOSITIVI_MEDICI_NATT,
AZIENDA:AZIENDE)

15. PAGINA 14
CREAZIONE TABELLE ED INSERIMENTI
Procediamo allora alla creazione delle tabelle; ma prima per evitare di
creare le tabelle direttamente da system creiamo il tablespace
MARCATURA al quale accederà l’ utente Biomedici come dba
identificato dalla password W_moscato.
Cosi’:
Abbiamo deciso di utilizzare un tablespace di 50MB con un ulteriore
estensione di 50 MB fino ad un massimo di 100MB; ciò è stato fatto
mediante un dimensionamento presente nell’appendice A con
opportune ipotesi di occorrenze.

16. PAGINA 15
Creiamo ora,mediante la sintassi:
CREATE USER BIOMEDICI IDENTIFIED BY W_MOSCATO DEFAULT
TABLESPACE MARCATURA
QUOTA UNLIMITED ON MARCATURA;
GRANT DBA TO BIOMEDICI
L’utente biomedici con privilege di Dba.
Accedendo mediante la sintassi
Connect Biomedici/W_MOSCATO
Passiamo alla creazione delle tabelle con la seguente sintassi:
CREATE TABLE AZIENDE (
ID_AZIENDA CHAR(3),
NOME VARCHAR(30) UNIQUE,NOT NULL
VIA VARCHAR(50)
CIVICO INTEGER
CAP VARCHAR(10)
CITTA VARCHAR(50)
EMAIL VARCHAR(30)
CONSTRAINT AZIENDE_PK PRIMARY KEY(ID_AZIENDA));
CREATE TABLE TELEFONO_AZ(
NUMERO VARCHAR(50),
AZIENDA CHAR(3),
CONSTRAINT PK_TELEFONO_AZ PRIMARY KEY(NUMERO)
);
ALTER TABLE TELEFONO_AZ
ADD CONSTRAINT FK_TEL_AZ FOREIGN KEY (AZIENDA)
REFERENCES AZIENDE(ID_AZIENDA) ON DELETE CASCADE;

17. PAGINA 16
CREATE TABLE ORGANISMI_NOTIFICATI(
ID_ON CHAR(6),
NOME VARCHAR (50) UNIQUE,NOT NULL
VIA VARCHAR(50),
CIVICO NUMBER,
CAP VARCHAR(10),
CITTA VARCHAR(50),
STATO VARCHAR(20) NOT NULL
CONSTRAINT PK_ON PRIMARY KEY(ID_ON)
);
CREATE TABLE TELEFONO_ON (
NUMERO VARCHAR(50),
ORGANISMO_NOTIFICATO CHAR(6)
CONSTRAINT PK_TELEFONO_ON PRIMARY KEY(NUMERO)
);
ALTER TABLE TELEFONO_ON
ADD CONSTRAINT FK_TEL_ON FOREIGN
KEY(ORGANISMO_NOTIFICATO) REFERENCES
ORGANISMI_NOTIFICATI(ID_ON) ON DELETE CASCADE;
CREATE TABLE CERTIFICAZIONI (
ID_CERT CHAR(5)
DESCRIZIONE VARCHAR (20) CHECK (DESCRIZIONE='TECNICA' OR
DESCRIZIONE='RISCHIO' OR DESCRIZIONE='ISO'),
DATA_IN DATE NOT NULL,
DATA_FINE DATE NOT NULL CHECK(‘DATA_FINE<DATA_IN)
AZIENDA CHAR(3),
ORGANISMO_NOTIFICATO CHAR(6)
DATA_CONTROLLO DATE NOT NULL
CONSTRAINT PK_CERTIFICAZIONI PRIMARY KEY(ID_CERT));

18. PAGINA 17
ALTER TABLE CERTIFICAZIONI
ADD CONSTRAINT FK1_CERT_AZ FOREIGN KEY(AZIENDA)
REFERENCES AZIENDE(ID_AZIENDA) ON DELETE SET NULL
ALTER TABLE CERTIFICAZIONI
ADD CONSTRAINT FK2_CERT_ON FOREIGN KEY
(ORGANISMO_NOTIFICATO) REFERENCES
ORGANISMI_NOTIFICATI(ID_ON) ON DELETE SET NULL;
CREATE TABLE ISTITUTI_OSPEDALIERI (
ID_OSP CHAR(4)
NOME VARCHAR(50) NOT NULL
VIA VARCHAR(30)
CIVICO INTEGER
CAP VARCHAR(10)
CITTA VARCHAR(50)
EMAIL VARCHAR(30)
CONSTRAINT PK_ISTITUTO_OSPEDALIERO PRIMARY KEY
(ID_OSP)
);
CREATE TABLE TELEFONO_IO(
NUMERO VARCHAR(30),
OSPEDALE CHAR(4),
CONSTRAINT PK_TELEFONO_IO PRIMARY KEY(NUMERO)
);
ALTER TABLE TELEFONO_IO
ADD CONSTRAINT FK_TEL_IO FOREIGN KEY
TELEFONO_IO(OSPEDALE) REFERENCES
ISTITUTO_OSPEDALIERO(ID_OSP);
ON DELETE CASCADE

19. PAGINA 18
CREATE TABLE VENDITE (
ID_VENDITA CHAR(5)
OSPEDALE CHAR(4)
DESTINAZIONE_USO VARCHAR(10) CHECK
(DESTINAZIONE_USO='INTERNO' OR
DESTINAZIONE_USO='ESTERNO')
CONSTRAINT PK_VENDITE PRIMARY KEY(ID_VENDITA)
);
ALTER TABLE VENDITE
ADD CONSTRAINT FK_VENDITE FOREIGN KEY
VENDITE(OSPEDALE) REFERENCES
ISTITUTI_OSPEDALIERI(ID_OSP) ON DELETE SET NULL;
CREATE TABLE TRANSIZIONI_EFFETTUATE(
AZIENDA CHAR(3)
VENDITA CHAR(5)
DATA DATE NOT NULL
CONSTRAINT PK_TRANSIZIONI PRIMARY KEY(AZIENDA,VENDITA)
);
ALTER TABLE TRANSIZIONI_EFFETTUATE
ADD CONSTRAINT FK1_TR_AZ FOREIGN KEY
TRANSIZIONI_EFFETTUATE(AZIENDA) REFERENCES
AZIENDE(ID_AZIENDA);
ON DELETE SET NULL;

20. PAGINA 19
ALTER TABLE TRANSIZIONI_EFFETTUATE
ADD CONSTRAINT FK2_TR_VE FOREIGN KEY
TRANSIZIONI_EFFETTUATE(VENDITA) REFERENCES
VENDITE(ID_VENDITA) ON DELETE SET NULL;
CREATE TABLE DISPOSITIVI_MEDICI(
CIVAB CHAR(8)
AZIENDA CHAR(3)
NOME VARCHAR (30) NOT NULL
DESCRIZIONE VARCHAR(100);
RISCHIO VARCHAR (9) CHECK (RISCHIO='ALTO' OR
RISCHIO='MEDIO-ALTO' OR RISCHIO='MEDIO-BASSO' OR
RISCHIO='BASSO' )
ALIMENTAZIONE VARCHAR(20) CHECK
(ALIMENTAZIONE='ELETTRICA' OR ALIMENTAZIONE ='NON
ELETTRICA' OR ALIMENTAZIONE ='NO ALIMENTAZIONE')
COMPLESSITA VARCHAR (40) CHECK(COMPLESSITA='ALTA' OR
COMPLESSITA='MEDIO-ALTA' OR COMPLESSITA='MEDIO-BASSA'
OR COMPLESSITA='BASSA')
DATA_MONITOR DATE
CONSTRAINT PK_DM PRIMARY KEY(CIVAB)
);
ALTER TABLE DISPOSITIVI MEDICI
ADD CONSTRAINT FK1_DM_AZ FOREIGN KEY DISPOSITIVI
MEDICI(AZIENDA) REFERENCES AZIENDE(ID_AZIENDA)
ON DELETE SET NULL;
CREATE TABLE OGGETTI_VENDUTI(
VENDITA CHAR (5),
DISPOSITIVO_MEDICO CHAR(8)
CONSTRAINT PK_OV PRIMARY
KEY(VENDITA,DISPOSITIVO_MEDICO)
);

21. PAGINA 20
ALTER TABLE OGGETTI_VENDUTI
ADD CONSTRAINT FK1_OG_V FOREIGN KEY
OGGETTI_VENDUTI(VENDITA) REFERENCES
VEDITE(ID_VENDITA) ON DELETE CASCADE;
ALTER TABLE OGGETTI_VENDUTI
ADD CONSTRAINT FK2_OV_DM FOREIGN KEY
OGGETTI_VENDUTI(DISPOSITIVO_MEDICO) REFERENCES
DISPOSITIVI_MEDICI(CIVAB)
ON DELETE CASCADE;
CREATE TABLE DISPOSITIVI_MEDICI_ATTIVI(
CODICE CHAR(8)
TIPO VARCHAR(20) CHECK(TIPO='CLASSE 2A' OR TIPO='CLASSE
2B' OR TIPO='CLASSE 3'
ORG_NOTIF CHAR(6)
CONSTRAINT PK_DMA PRIIMARY KEY (CODICE)
);
ALTER TABLE DISPOSITIVI_MEDICI_ATTIVI
ADD CONSTRAINT FK1_DMA_COD FOREIGN KEY
DISPOSITIVI_MEDICI_ATTIVI(CODICE) REFERENCES
DISPOSITIVI_MEDICI(CIVAB) ON DELETE CASCADE
ALTER TABLE DISPOSITIVI_MEDICI_ATTIVI
ADD CONSTRAINT FK2_DMA_ON FOREIGN KEY
DISPOSITIVI_MEDICI_ATTIVI(ORG_NOTIF) REFERENCES
ORGANISMI_NOTIFICATI(ID_ON)
ON DELETE CASCADE
CREATE TABLE DISPOSITIVI_MEDICI_NON_ATTIVI
CODICE CHAR(8)
CONSTRAINT PK_DMNA PRIMARY KEY(CODICE)
);

22. PAGINA 21
ALTER TABLE DISPOSITIVI_MEDICI_NON ATTIVI
ADD CONSTRAINT FK_DMNA FOREIGN KEY
DISPOSITIVI_MEDICI_NON_ATTIVI(CODICE) REFERENCES ON
DISPOISTIVI_MEDICI(CIVAB) ON DELETE CASCADE;
CREATE TABLE DISPOSITIVI_STERILI/MISURA(
CODICE CHAR(8)
ORG_NOT CHAR(6)
CONSTRAINT PK_DM_SM PRIMARY KEY(CODICE)
);
ALTER TABLE DISPOSITIVI_STERILI/MISURA
ADD CONSTRAINT FK1_DSM FOREIGN KEY
DISPOSITII_STERILI/MISURA(CODICE) REFERENCES
DISPOSITIVI_MEDICI_NON ATTIVI(CODICE) ON DELETE SET
NULL;
ALTER TABLE DISPOSITIVI_STERILI/MISURA
ADD CONSTRAINTFK2_DSM FOREIGN KEY
DISPOSITIVI_STERILI/MISURA(ORG_NOT) REFERENCES
ORGANISMI_NOTIFICATI(ID_ON);
CREATE TABLE DISPOSITIVI_ALTRO(
CODICE CHAR(8)
AZIENDA CHAR(3)
CONSTRAINT PK_da PRIMARY KEY(CODICE)
);
ALTER TABLE DISPOSITIVI_ALTRO
ADD CONSTRAINT FK1_DMA DISPOSITIVI_ALTRO(CODICE)
REFERENCES AZIENDE(ID_AZIENDA)
ALTER TABLE DISPOSITIVI_ALTRO
ADD CONSTRAINT FK2_DMA
DISPOSITIVI_ALTRO(CODICE) REFERENCES
DISPOSITIVI_MEDICI_NON_ATTIVI(CODICE);

23. PAGINA 22
INSERIMENTO TABELLE
Adesso inseriremo all’interno delle tabelle i valori dei vari campi.
Ciò è stato fatto mediante lo statement INSERT per i primi valori di
ogni tabella ed in seguito le tabelle sono state riempite mediante
l’interfaccia grafica “Broswer oggetti” offerta da Oracle 10g xe.
I dati vanno insertiti nel seguente ordine per non violare i vincoli di
integrità referenziale; così a titolo di esempio, avremo che :
INSERT INTO AZIENDE VALUES ('PHI','PHILIPS','23','2031','GAETANO
CASCATI' ,'MILANO' ,'ITALY@PHILIPS.COM');
INSERT INTO TELEFONO_AZ('392031','PHI');
INSERT INTO ORGANISMI_NOTIFICATI('NB0050','IMQ ISTITUTO
ITALIANO MARCHIO
QUALITà',QUINTILIANO,43,20138,MILANO,ITALIA)
INSERT INTO TELEFONO_ON('81456782','NB0050')
INSERT INTO CERTIFICAZIONI ('CR001',RISCHIO,TO_DATE('07-DIC-
2012'),TO_DATE('07-DIC-17'),'PHI',NB0050,TO_DATE(‘06-DIC-12'));
INSERT INTO
ISTITUTI_OSPEDALIERI('HO01','MONALDI','LEONARDO
BIANCHI',1,80131,'MONALDI@NAPOLI.IT','NAPOLI')
INSERT INTO TELEFONO_AO('817716107','HO01');

24. PAGINA 23
INSERT INTO VENDITE('V0001','HO01','ESTERNO');
INSERT INTO
TRANSIZIONI_EFFETTUATE('PHI','V0001',TO_DATE(07-MAR-10));
INSERT INTO DISPOSITIVI_MEDICI('TRMPHIAN','PHI','GYROSCAN
T5','TOMOGRAFO A RISONANZA
MAGNETICA','ALTO','ELETTRICA','ALTA',TO_DATE(02-DIC-13));
INSERT
INTO_DISPOSITIVI_MEDICI_ATTIVI('TRMPHIAN','CLASSE3','NB0050
')
INSERT INTO OGGETTI_VENDUTI('V0001','TRMPHIAN')

25. PAGINA 24
Le tabelle così create sono riportate con i rispettivi riempimenti nelle
figure sottostanti:
Aziende
Organismi_notificati
NUMERO AZIENDA
0222431
SIE
02392031
PHI
011636002275
VAR
06815315625
PHI
8178944561
SIE
Telefono_az
ID NOME CIVICO CAP EMAIL CITTA VIA
PHI PHILIPS 23 2031 ITALY@PHILIPS.COM MILANO GAETANO CASCATI
SIE
SIEMENS
ITALIA 28 20126
SIE.ITALIA@SIEMENS.C
OM MILANO
VIALE PIERO &
ALBERTO PIRELLI
VAR VARIAN 28 20052 VARIAN@TISCALI.IT TORINO TORINO
GEO
GEO
HEALTHCAR
E 19 196 HEALTCARE@GEO.IT ROMA VIALE TIZIANO
ID_ON NOME VIA CIVICO CAP CITTA PAESE
NB0050
IMQ ISTITUTO ITALIANO MARCHIO DI
QUALITà
QUINTILIAN
O 43 20138 MILANO
ITALI
A
NB0302 ANCCP CERTIFICATION AGENCY SRL NICOLODI 43 5712 LIVORNO
ITALI
A
NB0023 RICOTEST
SANTA
CHIARA 4 80040 NAPOLI
ITALI
A

26. PAGINA 25
NUMERO ORGANISMO_NOTIFICATO
0817711843 NB0023
061456782 NB0050
058654123 NB0302
TELEFONO_ON
Istituti_ospedalieri
NUMERO OSPEDALE
0817716107 HO01
0817471111 HO02
0291751156 HO03
0658701 HO04
Telefono_IO
ID_OSP NOME VIA CIVICO CAP EMAIL CITTA
HO01 MONALDI
LEONARDO
BIANCHI 1 80131
MONALDI@NAPOLI.I
T NAPOLI
HO02
CARDAREL
LI
ANTONIO
CARDARELLI 9 80131
CARDARELLI@NAPO
LI.IT NAPOLI
HO03
SAN
RAFFAELE OLGETTINE 58 20131
SANRAFFAELE@MIL
ANO.IT MILANO
HO04
SAN
CAMILLO
CIRCONVALLAZION
E GIANICOLESE 87 118
SANCAMILLO@ROM
A.IT ROMA

27. PAGINA 26
Dispositivi_medici
Dispositivi_medici_attivi
CIVAB AZIENDA NOME DESCRIZIONE RISCHIO ALIMENTAZIONE COMPLESSITA DATA_MONITOR
LITSIELT SIE
LITHOS
TAR
MODUL
ARIS
LITOTRITORE
EXTRACORPOREO
MEDIO-
BASSO ELETTRICA MEDIO-BASSA 04-dic-12
SSPSIE16 SIE
BIOGRA
PH
SENSAT
ION
SISTEMA TAC-PET
INTEGRATO ALTO ELETTRICA ALTA 05-dic-10
TACSIESE SIE
SOMAT
ON
EMOTIO
N DUO
TOMOGRAFO
COMPUTERIZZARTO ALTO ELETTRICA ALTA 07-dic-11
TRMPHIAN PHI
GYROS
CAN T5
TOMOGRAFO A
RISONANZA
MAGNETICA 1.5T ALTO ELETTRICA ALTA 02-dic-12
ADGPHIC9 PHI
INTEGR
IS C9
SISTEMA PER
ANGIOGRAFIA-
EMODINAMICA ALTO ELETTRICA MEDIO-ALTA 02-dic-13
LSCPHI01 PHI
LIGHT
INTERS
URGEO
N
LAMPADA SCIALITICA
MOBILE BASSO ELETTRICA BASSA 01-feb-13
LGCVAR12 VAR
BED
CAMER
A
LETTO PER GAMMA
CAMERA BASSO
NO
ALIMENTAZIONE BASSA 01-dic-12
CATVAR20 VAR
CATETE
RE
CATETERI VENOSI
PERIFERICI
MEDIO-
BASSO
NO
ALIMENTAZIONE BASSA 12-feb-13
TERVAR02 VAR
TERMO
METRO
TERMOMETRO A
MERCURIO BASSO
NO
ALIMENTAZIONE BASSA 02-feb-10
TERVAR05 VAR
TERMO
METRO
E2000
TERMOMETRO
ELETTRONICO BASSO NON ELETTRICA BASSA 28-feb-00
ECGVAR06 VAR
ELETTR
OCARD
2010
ELETTROCARDIOGRAFO
PORTATILE
MEDIO-
ALTO NON ELETTRICA MEDIO-ALTA 03-mar-10
CARPHI32 PHI
CARDIO
VER 100 ELETTROCARDIOGRAFO
MEDIO-
ALTO ELETTRICA MEDIO-ALTA 03-mar-10
CARSIE32 SIE
CARDIO
ASP ELETTROCARDIOGRAFO
MEDIO-
ALTO ELETTRICA MEDIO-ALTA 07-mar-10
CODICE TIPO ORG_NOTIFICATO
LITSIELT CLASSE 2A NB0302
SSPSIE16 CLASSE 2B NB0302
TACSIESE CLASSE 2B NB0050
TRMPHIAN CLASSE 3 NB0023
ADGPHIC9 CLASSE 3 NB0050
ECGVAR06 CLASSE 2A NB0023
CARPHI32 CLASSE 2B NB0023
CARSIE32 CLASSE 2B NB0302

28. PAGINA 27
CODICE
CATVAR20
LGCVAR12
LSCPHI01
TERVAR02
TERVAR05
Dispositivi_medici_non_attivi Dispositivi_sterili/misura
Dispositivi_altri
Vendite
CODICE ORG_NOT
CATVAR20 NB0023
TERVAR02 NB0050
TERVAR05 NB0050
CODICE AZIENDA
LSCPHI01 PHI
LGCVAR12 VAR
ID_VENDITA OSPEDALE DESTINAZIONE_USO
V0001 HO01 ESTERNO
V0002 HO01 ESTERNO
V0003 HO01 INTERNO
V0004 HO01 INTERNO
V0005 HO02 ESTERNO
V0006 HO02 INTERNO
V0007 HO03 INTERNO
V0008 HO03 INTERNO

29. PAGINA 28
Oggetti_venduti Transizioni_effettuate
AZIENDA VENDITA DATA
PHI V0001 07-mar-10
PHI V0002 06-mar-10
SIE V003 04-mar-10
SIE V004 03-mar-12
VAR V0005 01-mar-12
SIE V0006 28-feb-10
VAR V0007 03-dic-12
VAR V0008 04-dic-12
VENDITA DISPOSITIVO_MEDICO
V0001 TRMPHIAN
V0002 LSCPHI01
V0005 LGCVAR12
V0006 LITSIELT
V0007 CATVAR20
V0008 CATVAR20
V003 LITSIELT
V004 LITSIELT

30. PAGINA 29
IMPLEMENTAZIONE DELLE QUERY
Le interrogazioni che abbiamo effettuato sulla base di dati sono
riportati in basso,con i rispettivi risultati.
Query_1: ordina i dispositivi medici per nome
SELECT DM.NOME, DM.CIVAB
FROM DISPOSITIVI_MEDICI DM
ORDER BY DM.NOME
Query 1
Query_2: conta quante aziende produttrici ci sono
SELECT COUNT (A.ID_AZIENDA) AS NUMERO_AZIENDE
FROM AZIENDE A
Query 2

31. PAGINA 30
Query_3: stampare le vendite con le rispettive date e oggetto della
vendita
CREATE VIEW INFO_VENDITA AS
SELECT V.ID_VENDITA AS CODICE_VENDITA, TE.DATA AS DATA, DM.CIVAB AS
CODICE_DISPOSITIVO, DM.DESCRIZIONE AS DISPOSITIVO_VENDUTO
FROM VENDITE V,TRANSIZIONI_EFFETTUATE TE,OGGETTI_VENDUTI
OV,DISPOSITIVI_MEDICI DM
WHERE V.ID_VENDITA=TE.VENDITA AND V.ID_VENDITA=OV.VENDITA AND
OV.DISPOSITIVO_MEDICO=DM.CIVAB
SELECT *
FROM INFO_VENDITA
Query 3

32. PAGINA 31
Query_4: Trovare il nome degli organismi notificati che hanno
marchiato CE gli elettrocardiografi compresi quelli portatili.
SELECT ORGANISMI_NOTIFICATI.NOME
FROM ORGANISMI_NOTIFICATI
WHERE ORGANISMI_NOTIFICATI.ID_ON IN
(SELECT DMA.ORG_NOTIFICATO
FROM DISPOSITIVI_MEDICI_ATTIVI DMA, DISPOSITIVI_MEDICI DM
WHERE DMA.CODICE=DM.CIVAB
AND DM.DESCRIZIONE LIKE 'ELETTROCARDIOGRAFO%')
Query 4

33. PAGINA 32
Query_5: Trovare l’azienda che ha effettuato più vendite
CREATE VIEW AZ_VENDITE AS
SELECT A.NOME AS NOME,COUNT(TE.VENDITA) AS N_VENDITE
FROM TRANSIZIONI_EFFETTUATE TE,AZIENDE A
WHERE TE.AZIENDA=A.ID_AZIENDA
GROUP BY(A.NOME)
Per visualizzare la vista appena creata inseriamo:
SELECT *
FROM AZ_VENDITE
AZ_VENDITE
SELECT V.NOME
FROM AZ_VENDITE V
WHERE N_VENDITE >= ALL (SELECT MAX(V.N_VENDITE)
FROM AZ_VENDITE V );
Query 5

34. PAGINA 33
Query_6: Trovare l’azienda produttrice che ha autocertificato più
dispositivi medici
CREATE VIEW AUTOCERT AS
SELECT A.NOME, COUNT(A.ID_AZIENDA) AS N_AUTOCERTIFICAZIONI
FROM DISPOSITIVI_MEDICI DM,AZIENDE A
WHERE DM.AZIENDA=A.ID_AZIENDA
GROUP BY(A.NOME)
Per visualizzare la vista scriviamo:
SELECT *
FROM AUTOCERT
AUTOCERT
SELECT A.NOME
FROM AUTOCERT A
WHERE A.N_AUTOCERTIFICAZIONI>=ALL (SELECT MAX(A.N_AUTOCERTIFICAZIONI)
FROM AUTOCERT A);
Query 6

35. PAGINA 34
Query _7: conta quanti dispositivi medici sono stati venduti all’ospedale
Cardarelli
SELECT COUNT(OV.VENDITA)
FROM ISTITUTI_OSPEDALIERI IO,VENDITE V, OGGETTI_VENDUTI OV
WHERE IO.ID_OSP=V.OSPEDALE AND V.ID_VENDITA=OV.VENDITA
AND IO.NOME='CARDARELLI'
Query 7
Query_8: Per ogni Ospedale trovare il nome del dispositivo venduto e la
data di monitoraggio
SELECT IO.NOME,DM.DESCRIZIONE,DM.DATA_MONITORAGGIO
FROM ISTITUTI_OSPEDALIERI IO,VENDITE V,OGGETTI_VENDUTI OV,
DISPOSITIVI_MEDICI DM
WHERE IO.ID_OSP=V.OSPEDALE AND OV.VENDITA=V.ID_VENDITA AND
OV.DISPOSITIVO_MEDICO=DM.CIVAB
Query 8

36. PAGINA 35
PROCEDURA PL/SQL TRIGGER
Controlla che all’inserimento del codice CIVAB e nome di un nuovo dispositivo
medico, sia scritto tutto in maiuscolo.
CREATE OR REPLACE TRIGGER UPPER_DM
BEFORE INSERT ON DISPOSITIVI_MEDICI
FOR EACH ROW
BEGIN
:NEW.CIVAB := UPPER(:NEW.CIVAB);
:NEW.NOME := upper(:NEW.NOME);
Nel caso in cui ad un Organismo Notificato venga revocata la licenza di
controllo, cancellare anche i dispositivi medici da essi notificati.
CREATE OR REPLACE TRIGGER DELETE_ON
AFTER DELETE ON ORGANISMI_NOTIFICATI
FOR EACH ROW
BEGIN
DELETE FROM DISPOSITIVI_MEDICI_ATTIVI
WHERE ORG_NOTIFICATO=:OLD.ID_ON
DELETE FROM DISPOSITIVI_STERILI/MISURA
WHERE OR_NOT=:OLD.ID_ON
END;
Quando un dispositivo medico passa da alimentazione elettrica o non
elettrica a nessuna alimentazione cancellarlo dai Dispositivi_medici_attivi.
CREATE OR REPLACE TRIGGER DEL_ATTIVI
AFTER UPDATE ON DISPOSITIVI_MEDICI
FOR EACH ROW
BEGIN
IF(:OLD.ALIMENTAZIONE=’ELETTRICA’ OR :OLD.ALIMENTAZIONE=’NON ELETTRICA’ AND
:NEW.ALIMENTAZIONE=’NESSUNA ALIMENTAZIONE’)
THEN
DELETE DISPOSITIVI_MEDICI_ATTIVI
WHERE CODICE=:OLD.CIVAB
END;

37. PAGINA 36
APPENDICE A
DIMENSIONAMENTO DEL DATABASE
SPECIFICHE
Durante un anno di lavoro si presuppone che il database dovrà gestire la seguente
mole di dati:
Circa 1000 Aziende Produttrici
Circa 10000 Dispositivi Medici
Circa 5000 Certificazioni
Circa 6000 Organismi notificati
Circa 2000 Istituti Ospedalieri (sia pubblici che privati)
Circa 10000 Vendite
L'hardware a nostra disposizione è costituito da:
10 CPU 3.00 GHz con 8 Gb RAM ognuna;
SAN costituita da 20 HD da 1 Tb (20 Tb disponibili in Raid 5);
Sulla nostra macchina è installato un sistema operativo Windows 7 e una versione
di Oracle 10g xe.
Prima della creazione del database abbiamo innanzitutto effettuato il
partizionamento del disco. Ecco la suddivisione effettuata:
/ Dimensione: 50GB
Partizione in cui verrà installato il sistema operativo. Si è scelto di utilizzare la
distribuzione Red Hat Enterprise Linux 5 server;
/Oracle/ Dimensione: 60GB
Partizione dedicata all’installazione di Oracle 11g versione Enterprise e relativi
tool;
/Oractrlfile/ Dimensione: 20GB
Spazio di disco dedicato allo storage dei file di controllo di oracle;
/Oralogfile/ Dimensione: 500GB
Partizione riservata ai logfile di oracle
/Oradatafiles/ Dimensione: 2000GB
Partizione in cui verrà salvata il datafile di oracle
Lo spazio restante verrà utilizzato per eventuali backup e sarà a disposizione in
futuro per altri scopi.

38. PAGINA 37
DISCUSSIONE SUI TIPI
Un passo importante nella progettazione di un database consiste nel
dimensionamento del datafile in cui verranno salvati i dati. A tal fine bisogna fare
uno studio preliminare per decidere che tipo attribuire ai vari dati e stabilire il
numero approssimativo di tuple che ogni tabella conterrà.
Per i nostri scopi è stato deciso di utilizzare i seguenti tipi:
Char e varchar: questi tipi vengono utilizzati per memorizzare caratteri. In
particolare char viene usato quando si è certi della lunghezza della stringa da
inserire. Varchar al contrario permette l'inserimento di parole di lunghezza
variabile, dato però un limite massimo di caratteri. Per questo motivo si è deciso
di utilizzare char per memorizzare i codici alfanumerici degli ID che hanno
lunghezza fissa, mentre varchar per i campi quali nomi, descrizione ecc. Sia il tipo
char che il tipo varchar occupano in memoria 1 byte per carattere.
Number: il tipo number viene utilizzato per memorizzare numeri sia interi
che decimali. Al tempo della definizione va specificato il numero di cifre del
numero da inserire e quante di esse sono decimali. (Es Number(5,3) vuol dire
che dobbiamo memorizzare un numero di 5 cifre delle quali tre decimali). La
dimensione di questo tipo è data dalla formula (n/2)+2, dove n è il numero di
cifre del numero memorizzato.
Date: è il tipo di dato che oracle associa alle date. Esse vengono salvate di
default nel formato 'gg-mmm-aa' e occupano 7 byte in memoria.
DIMENSIONAMENTO TABELLE
In seguito alle scelte fatte si è realizzato il seguente schema che illustra la
struttura interna delle tabelle con relative dimensioni dei vari campi e totali per la
tabella. L'unità di misura scelta per i dati è il byte e si è utilizzata la convenzione
1000b=1Kb. Inoltre le dimensioni indicate solo valide per un solo anno per cui in
seguito verranno fatte ulteriori considerazioni per estendere il ciclo vitale del
nostro database ad un minimo di 2 anni.

39. PAGINA 38
NOME TIPO DIM=[byte] DIM.TAB
AZIENDE occorrenze=1000
ID CHAR(3) 3
NOME VARCHAR(30) 30
VIA VARCHAR(50) 50
CIVICO NUMBER 7
CAP NUMBER 7
CITTA VARCHAR(30) 30
EMAIL VARCHAR(30) 30
Totale 157 157 Kb
NOME TIPO DIM[=]BYTE DIM.TAB
TELEFONO_AZ occorrenze=2000
NUMERO VARCHAR(50) 50
AZIENDA CHAR(3) 3
TOTALE 53 106 Kb
NOME TIPO DIM[=]BYTE DIM.TAB
ORGANISMI _NOTIFICATI occorrenze=6000
ID CHAR(6) 6
NOME VARCHAR(50) 50
VIA VARCHAR(50) 50
CIVICO NUMBER 6
CITTA VARCHAR(50) 50
STATO VARCHAR(50) 50
TOTALE 206 1,236 Mb

40. PAGINA 39
NOME TIPO DIM[=]BYTE DIM.TAB
TELEFONO_ON occorrenze=12000
NUMBER VARCHAR(50) 50
ORGANISMO_NOT CHAR(6) 6
TOTALE 56 672 Kb
NOME TIPO DIM[=]BYTE DIM.TAB
CERTIFICAZIONI occorrenze=5000
ID_CERT CHAR(5) 6
DESCRIZIONE VARCHAR(20) 20
DATA IN DATE 6
DATA FINE DATE 6
AZIENDA CHAR(3) 3
ORGANISMO_NOT CHAR(6) 6
DATA CONTROLLO DATE 6
TOTALE 53 265 Kb
NOME TIPO DIM[=]BYTE DIM.TAB
ISTITUTI_OSPEDALIERI occorrenze=5000
ID_OSP CHAR(4) 4
NOME VARCHAR(50) 50
VIA VARCHAR(50) 50
CIVICO NUMBER 6
CAP CHAR(3) 3
CITTA CHAR(6) 6
EMAIL VARCHAR(50) 50
TOTALE 169 338 Kb

41. PAGINA 40
NOME TIPO DIM[=]BYTE DIM.TAB
TELEFONO_IO occorrenze=10000
NUMERO VARCHAR(50) 50
OSPEDALE CHAR(4) 4
TOTALE 54 540 Kb
NOME TIPO DIM[=]BYTE DIM.TAB
VENDITE occorrenze=10000
ID_VENDITA VARCHAR(50) 50
OSPEDALE CHAR(4) 4
DESTINAZIONE_USO VARCHAR(50) 50
TOTALE 104 1,040 Mb
NOME TIPO DIM[=]BYTE DIM.TAB
TRANSIZIONI EFFETTUATE occorrenze=10000
AZIENDA CHAR(3) 3
VENDITA CHAR(5) 5
TOTALE 8 80 KB
NOME TIPO DIM[=]BYTE DIM.TAB
DISPOSITIVI_MEDICI occorrenze=10000
CIVAB CHAR(8) 8
NOME VARCHAR(50) 50
DESCRIZIONE VARCHAR(70) 70
AZIENDA CHAR(3) 3
RISCHIO VARCHAR(50) 50
COMPLESSITA VARCHAR(50) 50
ALIMENTAZIONE VARCHAR(50) 50
DATA_MONITORAGGIO DATE 6
TOTALE 287 2,87 Mb

42. PAGINA 41
NOME TIPO DIM[=]BYTE DIM.TAB
OGGETTI_VENDUTI occorrenze=10000
VENDITA CHAR(5) 5
DISPOSITIVO
MEDICO CHAR(8) 8
TOTALE 13 130 Kb
NOME TIPO DIM[=]BYTE DIM.TAB
DISPOSITIVI_MEDICI_ATTIVI occorrenze=10000
CODICE CHAR(5) 5
TIPO CHAR(8) 8
ORG_NOT CHAR(6) 6
TOTALE 19 190 Kb
NOME TIPO DIM[=]BYTE DIM.TAB
DISPOSITIVI_MED_NN_ATT occorrenze=10000
CODICE CHAR(8) 8
TOTALE 8 80 Kb
NOME TIPO DIM[=]BYTE DIM.TAB
DISPOSITIVI_STERILI/MISURA occorrenze=10000
CODICE CHAR(8) 8
ORG_NOT CHAR(6) 6
TOTALE 14 140 Kb
NOME TIPO DIM[=]BYTE DIM.TAB
DISPOSITIVI_ALTRO occorrenze=10000
CODICE CHAR(8) 8
AZIENDA CHAR(3) 3
TOTALE 11 110 Kb

43. PAGINA 42
OSSERVAZIONI
Abbiamo deciso che il nostro
database deve contenere le informazioni di almeno due stagioni. Considerando le
dimensioni delle tabelle sopra rappresentate e aggiungendo l'aliquota
corrispondente al secondo anno più
un'altra aliquota corrispondente al 30% circa del totale che tiene conto di
eventuali errori nel dimensionamento, dello spazio necessario a memorizzare altri
oggetti non previsti all'inizio e dei byte riservati agli header dei blocchi,; si è
deciso di creare un tablespace di 50MB con un ulteriore estensione di 50 MB fino
ad un massimo di 100MB.