BASI DI DATI PER LA VENDITA E GESTIONE DISPOSITIVI MEDICI

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

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

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.

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.

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.

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.

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

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)

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


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

Nome Id Nome Destinazione 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

Id Id

Id

Id

Nome

Nome

Sede Legale

Data_fine Data_inizio Descrizione

Indirizzo

Telefono

E-mail

Telefono

E-mail

Telefono

Descrizione

Alimentazione

Rischio

Complessità

(1,N)

(1,N)

Cap Civico Via Città

(1,N) (1,N)

Indirizzo


(1,N)


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:

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à

CDA CDNA

(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_inizio Descrizione

CERT. TECNICA

CERT. SUL

RISCHIO

CERT. ISO

CERTIFICAZIONE

Id Data_fine Data_inizio Descrizione

Tipo

Soluzione 3

Soluzione 2

Soluzioni 2 e 3

Soluzione 2

/

PAGINA 11

SCHEMA ER FINALE

recapito3

TELEFONO

VENDITA

DISPOSITIVO MEDICO

AZIENDA PRODUTTRICE


D.M.

NON ATTIVO

D.M.

ATTIVO

CERTIFICAZIONE

ORGANISMO NOTIFICATO

effettua

oggetto

presso

redige

autocertificazione

marcatura CExxxx

controllo

Nome Id Nome Destinazione 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

Id Id

Id

Id

Nome

Nome

Data_fine Data_inizio Descrizione

E-mail E-mail

Descrizione

Alimentazione

Rischio

Complessità

Tipo

Tipo

CSM CA

(1,N)

(1,N)

CDA

CDNA

(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

Via Città

Cap Civico

Cap

Civico

Via

Città

recapito2

(1,1)

recapito1

(1,1)

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))

PAGINA 13

DISPOSITIVI_MEDICI(CIVAB,NOME,DESCRIZIONE,ALIMENTAZIONE,RISCHIO,COMPLESSITA,DATA_MAN,AZIENDA:AZIENDE) DISPOSITIVI_MEDICI_ATTIVI(DISPOSITIVO_MEDICO:DISPOSITIVI_MEDICI,TIPO,ORGANISMO_NOTIFICATO:ORGANISMI_NOTIFICATI) 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)

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.

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;

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));

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

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;

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) );

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) );

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);

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' ,'[email protected]');

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,'[email protected]','NAPOLI')

INSERT INTO TELEFONO_AO('817716107','HO01');

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')

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 [email protected] MILANO GAETANO CASCATI

SIE SIEMENS ITALIA 28 20126

[email protected] MILANO

VIALE PIERO & ALBERTO PIRELLI

VAR VARIAN 28 20052 [email protected] TORINO TORINO

GEO

GEO HEALTHCARE 19 196 [email protected] ROMA VIALE TIZIANO

ID_ON NOME VIA CIVICO CAP CITTA PAESE

NB0050 IMQ ISTITUTO ITALIANO MARCHIO DI QUALITà

QUINTILIANO 43 20138 MILANO

ITALIA

NB0302 ANCCP CERTIFICATION AGENCY SRL NICOLODI 43 5712 LIVORNO ITALIA

NB0023 RICOTEST SANTA CHIARA 4 80040 NAPOLI

ITALIA

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

[email protected] NAPOLI

HO02 CARDARELLI

ANTONIO CARDARELLI 9 80131

[email protected] NAPOLI

HO03 SAN RAFFAELE OLGETTINE 58 20131

[email protected] MILANO

HO04 SAN CAMILLO

CIRCONVALLAZIONE GIANICOLESE 87 118

[email protected] ROMA

PAGINA 26

Dispositivi_medici

Dispositivi_medici_attivi

CIVAB AZIENDA NOME DESCRIZIONE RISCHIO ALIMENTAZIONE COMPLESSITA DATA_MONITOR

LITSIELT SIE

LITHOSTAR MODULARIS

LITOTRITORE EXTRACORPOREO

MEDIO-BASSO ELETTRICA MEDIO-BASSA 04-dic-12

SSPSIE16 SIE

BIOGRAPH SENSATION

SISTEMA TAC-PET INTEGRATO ALTO ELETTRICA ALTA 05-dic-10

TACSIESE SIE

SOMATON EMOTION DUO

TOMOGRAFO COMPUTERIZZARTO ALTO ELETTRICA ALTA 07-dic-11

TRMPHIAN PHI GYROSCAN T5

TOMOGRAFO A RISONANZA MAGNETICA 1.5T ALTO ELETTRICA ALTA 02-dic-12

ADGPHIC9 PHI INTEGRIS C9

SISTEMA PER ANGIOGRAFIA-EMODINAMICA ALTO ELETTRICA MEDIO-ALTA 02-dic-13

LSCPHI01 PHI

LIGHT INTERSURGEON

LAMPADA SCIALITICA MOBILE BASSO ELETTRICA BASSA 01-feb-13

LGCVAR12 VAR

BED CAMERA

LETTO PER GAMMA CAMERA BASSO

NO ALIMENTAZIONE BASSA 01-dic-12

CATVAR20 VAR CATETERE

CATETERI VENOSI PERIFERICI

MEDIO-BASSO

NO ALIMENTAZIONE BASSA 12-feb-13

TERVAR02 VAR TERMOMETRO

TERMOMETRO A MERCURIO BASSO

NO ALIMENTAZIONE BASSA 02-feb-10

TERVAR05 VAR

TERMOMETRO E2000

TERMOMETRO ELETTRONICO BASSO NON ELETTRICA BASSA 28-feb-00

ECGVAR06 VAR

ELETTROCARD 2010

ELETTROCARDIOGRAFO PORTATILE

MEDIO-ALTO NON ELETTRICA MEDIO-ALTA 03-mar-10

CARPHI32 PHI CARDIOVER 100 ELETTROCARDIOGRAFO

MEDIO-ALTO ELETTRICA MEDIO-ALTA 03-mar-10

CARSIE32 SIE CARDIOASP 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

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

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

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

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

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

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

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

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

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;

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.

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.

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


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

PAGINA 39


TELEFONO_ON

occorrenze=12000

NUMBER VARCHAR(50) 50

ORGANISMO_NOT CHAR(6) 6

TOTALE 56 672 Kb


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


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

PAGINA 40


TELEFONO_IO

occorrenze=10000

NUMERO VARCHAR(50) 50

OSPEDALE CHAR(4) 4 TOTALE 54 540 Kb


VENDITE

occorrenze=10000

ID_VENDITA VARCHAR(50) 50

OSPEDALE CHAR(4) 4

DESTINAZIONE_USO VARCHAR(50) 50 TOTALE 104 1,040 Mb


TRANSIZIONI EFFETTUATE

occorrenze=10000

AZIENDA CHAR(3) 3

VENDITA CHAR(5) 5

TOTALE 8 80 KB


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

PAGINA 41


OGGETTI_VENDUTI

occorrenze=10000

VENDITA CHAR(5) 5

DISPOSITIVO MEDICO CHAR(8) 8

TOTALE 13 130 Kb


DISPOSITIVI_MEDICI_ATTIVI

occorrenze=10000

CODICE CHAR(5) 5

TIPO CHAR(8) 8

ORG_NOT CHAR(6) 6 TOTALE 19 190 Kb


DISPOSITIVI_MED_NN_ATT

occorrenze=10000

CODICE CHAR(8) 8

TOTALE 8 80 Kb


DISPOSITIVI_STERILI/MISURA

occorrenze=10000

CODICE CHAR(8) 8

ORG_NOT CHAR(6) 6

TOTALE 14 140 Kb


DISPOSITIVI_ALTRO

occorrenze=10000

CODICE CHAR(8) 8

AZIENDA CHAR(3) 3

TOTALE 11 110 Kb

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.

BASI DI DATI PER LA VENDITA E GESTIONE DISPOSITIVI MEDICI

Data & Analytics

Transcript of BASI DI DATI PER LA VENDITA E GESTIONE DISPOSITIVI MEDICI