Consiglio per progettazione db

Rosa84

il 15 nov 2018, 20:11

27 risposte

27 Risposte - Pagina 2

gibra
Molto attivo
Iscritto da
gen, 2013
Messaggi:
1647
Re: Consiglio per progettazione db
19 nov 2018, 21:46
Rosa84 ha scritto:
è tutto perfetto ma credo a questo punto di aver spiegato male la mia esigenza,
Credo proprio di sì.

Rosa84 ha scritto:
perdonami, (o non sto capendo io il modus operandi) con "Record" intendo i valori degli esami dei pazienti,
TU hai parlato fino ad ora di MODELLI, non di registrazione (quella viene dopo)
Il MODELLO è uno schema, un tracciato record. Niente di più niente di meno.
Il MODELLO serve per dirti (o per ricordarti) quali sono i valori (esami) contemplati da una determinata analisi.

E' ovvio poi che quel modello può servire a te per preparare una maschera di inserimento predefinita.
Dal punto di vista pratico, la sequenza temporale è costituita, a grandi linee, da 4 fasi:

1) il medico fa la prescizione
Chiaro che lui non può mettersi lì a cercare quali sono gli esami previsti per quella determinata analisi (es. URINE), mica può ricordarseli tutti a memoria. Lui stabilisce che il paziente deve fare l'esame dell URINE.

2) Il sistema tramite il tuo MODELLO, predisporrà l'inserimento dei dati.
L'operatore stabilirà l'appuntamento per il paziente.

3) Una volta eseguiti gli esami, l'utente preposto del laboratorio provvederà ad inserire i dati delle analisi fatte dal paziente.

4) Infine, il medico alla successiva visìta di controllo, visualizzerà la 'cartella dela paziente con le analisi inserite dall'operatore.

Rosa84 ha scritto:
Non so dove salvare questi dati, questo è il mio problema.
I dati andranno salvati in apposite tabelle che non fanno altro che rispecchiare i MODELLI di cui si è discusso fino ad ora.
Queste tabelle avranno ovviamente nomi diversi, es. AnalisiTest e AnalisiDettaglio

Queste tabelle (a differenza dei MODELLI) includeranno anche una serie di campi supplementari (per cui saranno necessarie ulteriori tabelle relazionate) che servono ad identificare in modo univoco:
- il paziente (codice sanitario, eventuale tipo di Esenzione, ecc.)
- data prescizione degli esami
- data esecuzione degli esami
- medico che li ha prescritti
e via discorrendo...

Ma tutte queste cose dovresti già saperle tu, se non le conosci allora consultati con chi ti ha commissionato il lavoro.

@amorosik
Scusa la franchezza, ma quell'esempio c'entra come i cavoli a merenda. Cioè NULLA!
Cerchiamo di non divagare, ed evitiamo di creare confusione a chi pone un determinato problema.
R
Rosa84
Pochi posts
Iscritto da
nov, 2018
Messaggi:
9
Re: Consiglio per progettazione db
19 nov 2018, 22:28
gibra ha scritto:

TU hai parlato fino ad ora di MODELLI, non di registrazione (quella viene dopo)
Il MODELLO è uno schema, un tracciato record. Niente di più niente di meno.
Il MODELLO serve per dirti (o per ricordarti) quali sono i valori (esami) contemplati da una determinata analisi.

E' ovvio poi che quel modello può servire a te per preparare una maschera di inserimento predefinita.
Dal punto di vista pratico, la sequenza temporale è costituita, a grandi linee, da 4 fasi:

1) il medico fa la prescizione
Chiaro che lui non può mettersi lì a cercare quali sono gli esami previsti per quella determinata analisi (es. URINE), mica può ricordarseli tutti a memoria. Lui stabilisce che il paziente deve fare l'esame dell URINE.

2) Il sistema tramite il tuo MODELLO, predisporrà l'inserimento dei dati.
L'operatore stabilirà l'appuntamento per il paziente.

3) Una volta eseguiti gli esami, l'utente preposto del laboratorio provvederà ad inserire i dati delle analisi fatte dal paziente.

4) Infine, il medico alla successiva visìta di controllo, visualizzerà la 'cartella dela paziente con le analisi inserite dall'operatore.

I dati andranno salvati in apposite tabelle che non fanno altro che rispecchiare i MODELLI di cui si è discusso fino ad ora.
Queste tabelle avranno ovviamente nomi diversi, es. AnalisiTest e AnalisiDettaglio

Queste tabelle (a differenza dei MODELLI) includeranno anche una serie di campi supplementari (per cui saranno necessarie ulteriori tabelle relazionate) che servono ad identificare in modo univoco:
- il paziente (codice sanitario, eventuale tipo di Esenzione, ecc.)
- data prescizione degli esami
- data esecuzione degli esami
- medico che li ha prescritti
e via discorrendo...

Ma tutte queste cose dovresti già saperle tu, se non le conosci allora consultati con chi ti ha commissionato il lavoro.

Facciamo un passo indietro... come ti ho detto l'inserimento dei dati è una cosa che farà il gestionale in automatico, l'ho predisposto cosi per comodità (l'utente preposto del laboratorio, figurati se per ogni esame di ogni paziente deve perdere 5-10minuti a inserire manualmente i valori), esce l'esame dalla macchina, viene creato il file xml di riepilogo, esempio:

"idesame" "ph" --> valore, "proteine" --> valore, "colore" --> valore

nel mio DB ho, seguendo il tuo ragionamento di prima:

Modelli:
```
IDModello  Modello 
1          Urine
2          Emocromo
ecc.
```
CampiModello
```
IDCampoModello  IDModello  Campo 
1               1          Aspetto 
2               1          Colore 
ecc. 
```
Cosi riesco a gestire i vari tipi di esami, e le loro sottocategorie, perfetto. Cosa rimane da fare? inserire i valori degli esami nel db (quelli nel file xml). Ma dove e in che modo? Seguendo quanto detto fino adesso.

in seguito il medico cliccando sulla cartella del paziente, dove avrà le date di tutte le visite che ha fatto, vedrà che giorno X il paziente ha fatto l'esame Y e l'esame J, cliccando poi sull'esame in questione, con una query vado a prendermi i valori di quell'esame.
O
OsvaldoLaviosa
Super Famoso
Iscritto da
apr, 2012
Messaggi:
7501
Re: Consiglio per progettazione db
19 nov 2018, 22:46
Rosa84 ha scritto:
l'inserimento dei dati è una cosa che farà il gestionale in automatico, l'ho predisposto cosi per comodità (l'utente preposto del laboratorio, figurati se per ogni esame di ogni paziente deve perdere 5-10minuti a inserire manualmente i valori),

Rosa84 ha scritto:
Cosi riesco a gestire i vari tipi di esami, e le loro sottocategorie, perfetto. Cosa rimane da fare? inserire i valori degli esami nel db (quelli nel file xml). Ma dove e in che modo?
In questa sezione del forum si discute di "Progettazione database", ossia la STRUTTURA (lo scheletro se preferisci), quindi capire quali sono le tabelle e le loro relazioni.
Ho la sensazione che la struttura di gibra sia troppo "particolareggiata" e pare che Rosa si accontenti di qualche tabella in meno.
Se Rosa ha capito la SUA struttura, la discussione potrebbe terminare qui.

Invece Rosa vuole sapere come "automatizzare" il passaggio dati da xml in database MySQL. Io credo che bisogna aprire una nuova discussione nella sezione MySQL.
R
Rosa84
Pochi posts
Iscritto da
nov, 2018
Messaggi:
9
Re: Consiglio per progettazione db
19 nov 2018, 22:52
OsvaldoLaviosa ha scritto:
Rosa84 ha scritto:
l'inserimento dei dati è una cosa che farà il gestionale in automatico, l'ho predisposto cosi per comodità (l'utente preposto del laboratorio, figurati se per ogni esame di ogni paziente deve perdere 5-10minuti a inserire manualmente i valori),

Rosa84 ha scritto:
Cosi riesco a gestire i vari tipi di esami, e le loro sottocategorie, perfetto. Cosa rimane da fare? inserire i valori degli esami nel db (quelli nel file xml). Ma dove e in che modo?
In questa sezione del forum si discute di "Progettazione database", ossia la STRUTTURA (lo scheletro se preferisci), quindi capire quali sono le tabelle e le loro relazioni.
Ho la sensazione che la struttura di gibra sia troppo "particolareggiata" e pare che Rosa si accontenti di qualche tabella in meno.
Se Rosa ha capito la SUA struttura, la discussione potrebbe terminare qui.

Invece Rosa vuole sapere come "automatizzare" il passaggio dati da xml in database MySQL. Io credo che bisogna aprire una nuova discussione nella sezione MySQL.
No, non voglio sapere come automatizzare il passaggio dei dati da xml al DB sql, quella è una cosa semplice (leggere un xml in pratica), vorrei idee sul dove salvare i dati sul db, in che struttura.

Credo a questo punto che l'opzione 1 del mio primo post sia l'unica soluzione (se tralasciamo il passaggio a mariaDB con le tabelle dinamiche che è un'opzione valida).
Quindi avere per ogni esame una tabella sul db, con ognuno i suoi campi, cosi, leggo il file xml, e vado a mettere i dati nella tabella corrispondente all'esame.
O
OsvaldoLaviosa
Super Famoso
Iscritto da
apr, 2012
Messaggi:
7501
Re: Consiglio per progettazione db
19 nov 2018, 22:59
Rosa84 ha scritto:
No, non voglio sapere come automatizzare il passaggio dei dati da xml al DB sql, quella è una cosa semplice (leggere un xml in pratica), vorrei idee sul dove salvare i dati sul db, in che struttura.
gibra ha detto la sua. La mia proposta è proprio sbagliata?

Rosa84 ha scritto:
Quindi avere per ogni esame una tabella sul db, con ognuno i suoi campi,
No, questo è errato dal punto di vista della normalizzazione. Da una delle strutture che ti sono state proposte puoi sempre "estrapolare" una QUERY che ti mostra i valori del singolo Esame.
R
Rosa84
Pochi posts
Iscritto da
nov, 2018
Messaggi:
9
Re: Consiglio per progettazione db
19 nov 2018, 23:22
OsvaldoLaviosa ha scritto:
Rosa84 ha scritto:
No, non voglio sapere come automatizzare il passaggio dei dati da xml al DB sql, quella è una cosa semplice (leggere un xml in pratica), vorrei idee sul dove salvare i dati sul db, in che struttura.
gibra ha detto la sua. La mia proposta è proprio sbagliata?

Rosa84 ha scritto:
Quindi avere per ogni esame una tabella sul db, con ognuno i suoi campi,
No, questo è errato dal punto di vista della normalizzazione. Da una delle strutture che ti sono state proposte puoi sempre "estrapolare" una QUERY che ti mostra i valori del singolo Esame.
Ho seguito il tuo ragionamento fino a un certo punto. Da qui in poi non riesco a capire cosa vorresti fare.

DettagliEsami
IDDA (PK)
Nomenclatura
Valore
IDEsame (FK)

TipiEsami
IDTipoEsame (PK)
TipoEsame

Nomenclature
IDNomenclatura (PK)
Nomenclatura
IDTipoEsame (FK)

Se mi riesci a fare un'esempio con i dati che abbiamo scritto sopra magari ti posso dire se puo andare bene o no, ma da quello che ho capito, nella tabella "dettagli esame" ci infileresti ogni valore di ogni singolo esame?
se fosse cosi, avremo una tabella dettagliEsami di dimensioni stratosferische, con tutti i rallentamenti che ne seguirebbero nel momento in cui andrei a fare le statistiche.

EDIT: Conta che non stiamo lavorando in locale, se devo fare una query su un server sql, devo per forza di cose cercare di avere risultati mirati, controllando meno record possibili o mi si impalla il sistema, la mole di dati è consistente.

L'idea di avere 500 tabelle se ci pensi snellisce parecchio la cosa e semplifica poi le query per ottenere i dati: SELECT * from Esami_urine WHERE ph>5 per esempio. la questione della normalizzazione beh, non la vedo un grosso problema avendo tabelle distinte per ogni esame, se per esempio il PH è un valore che possono avere 20 esami, con il tuo sistema avrei comunque PH_IDesame, quindi andrei a ripeterlo piu volte per ogni esame, non cambia molto dall'avere la colonna PH su 20 tabelle ma con il vantaggio di non dover fare 20 JOIN per ottenere i dati.
willy55
Molto attivo
Iscritto da
nov, 2015
Messaggi:
836
Re: Consiglio per progettazione db
20 nov 2018, 00:57
In generale, dalla descrizione si evince che hai delle apparecchiature sulle quali si effettuano degli esami clinici ed in uscita da queste si ottengono dei file XML con i dati che devono confluire nella struttura che si vuole implementare.
Quindi se hai, citando, l'esempio:
"idesame" "ph" --> valore, "proteine" --> valore, "colore" --> valore
dovrai per ciascun esame procedere alla memorizzazione dei relativi valori.
Una soluzione che punta ad una struttura normalizzata, ad esempio, dovrà riportare i dati, ipotizzando una struttura 1<->N con una tabella "Esami" correlata (lato molti) con la tabella "ValoriEsame" come nello schema a seguire:
```
Tabella Esami

idesame   Esame
1         "Urine"
```
```
Tabella ValoriEsame

Idesame     TipoEsame               Valore		
1               "ph"                 7
1               "proteine"           30
1               "colore"  	        "paglierino"
```
Questo in forma minimale in quanto, come traspare dai vari interventi, la struttura può essere molto più complessa.
Ad esempio, memorizzare dati aggiuntivi come: le informazioni del paziente, delle prenotazioni esami, dei modelli degli esami previsti e dei valori nella norma o fuori norma, ecc.

Ma visto che parli di 500 tabelle sarebbe da capire se i modelli di esami possono essere ricondotti ad una forma normale in quanto tale numero si potrebbe ipotizzare che si legato alla struttura alla possibile sequenza fornita, in output, dalla apparecchiatura.
Qualora si impiega tale struttura si avrebbe una dispersione dei valori e al contempo si ha l'immediatezza dell'esame in base al codice caratteristico dell'esame (tipo idesame = 1 dell'esempio sopracitato); ma qualora si debba cercare (citando tuo ultimo esempio il "ph > 5") o si ha una struttura posizionale (ove il valore del "ph" è prestabilito nella sequenza dei campi) oppure la struttura inizialmente citata è sicuramente più versatile.
Nelle operazioni si può implementare del codice che in base alla ricerca voluta (ad esempio il "ph" maggiore di un valore prestabilito determini prima in quale posizione (di campo) è presente il "ph" e vada ad estrarre quella colonna in base alla corrispondenza per l'identificativo esame (idesame = 1 dell'esempio).
Sono comunque tutte operazioni che implicano una attenta analisi delle funzionalità da assicurare e delle velocità che prioritariamente si vogliono assicurare.
Ma solo tu sai le effettive esigenze e le modalità operative principali che vuoi assicurare allo studio di analisi cliniche.
M
migliorabile
Super Famoso
Iscritto da
apr, 2013
Messaggi:
6073
Re: Consiglio per progettazione db
20 nov 2018, 03:06
.
O
OsvaldoLaviosa
Super Famoso
Iscritto da
apr, 2012
Messaggi:
7501
Re: Consiglio per progettazione db
20 nov 2018, 08:41
Rosa84 ha scritto:
Ho seguito il tuo ragionamento fino a un certo punto. Da qui in poi non riesco a capire cosa vorresti fare.

DettagliEsami
IDDA (PK)
Nomenclatura
Valore
IDEsame (FK)

TipiEsami
IDTipoEsame (PK)
TipoEsame

Nomenclature
IDNomenclatura (PK)
Nomenclatura
IDTipoEsame (FK)

Se mi riesci a fare un'esempio con i dati che abbiamo scritto sopra magari ti posso dire se puo andare bene o no, ma da quello che ho capito, nella tabella "dettagli esame" ci infileresti ogni valore di ogni singolo esame?
se fosse cosi, avremo una tabella dettagliEsami di dimensioni stratosferische, con tutti i rallentamenti che ne seguirebbero nel momento in cui andrei a fare le statistiche.
Io ho parlato di maschera/sottomaschera Esami/DettagliEsami. Entra il Paziente Laviosa Osvaldo nel tuo studio e il dottore dice che deve fare il giorno 5/11/2018 un "esame urine". Tu compili la maschera (singola) Esami (se Laviosa Osvaldo è la prima volta che mette piede nello studio, occorrerà alimentare anche la tabella "anagrafica" Pazienti). Nell'ultimo campo ci scrivi l'IDTipoEsame=1 che corrisponde a "urine". Adesso arriva il bello su DettagliEsami. TEORICAMENTE bisognerebbe compilare VERTICALMENTE tutte le Nomenclature, poi i Valori, tutti associati al IDTipoEsame=1. Sarebbe un bagno di sangue scrivere sempre manualmente tutte le (non so) 20 voci che riguardano le urine. Per questo motivo ho parlato di una "query di accodamento" che va messa in moto con semplice clic di pulsante. Qua si tratta di AUTOMATIZZARE un po' la questione (in Access si usa il codice VBA per fare questo). Nella tabella Nomenclature vengono associate tutte le 20 voci di urine--->IDTipoEsame=1, tutte le 30 voci di sangue--->IDTipoEsame=3...ecc...
Quindi una volta compilato il singolo record di Esami (quello del 5/11/2018 di Laviosa Osvaldo, IDTipoEsame=1). Allora tu clicchi sul pulsante che innesca la query di accodamento e vedrai "scendere rapidamente" tutti i 20 record verticali di tutte le Nomenclature relative solo a IDTipoEsame=1. A questo punto ti basta compilare il solo campo Valore corrispondente a ogni Nomenclatura. Nulla di tutto questo ti andrebbe ad appesantire il database. Le applicazioni pensate per database sono molto-molto più potenti di Excel e possono contenere mole di dati molto molto più consistenti. Quindi questo non è affatto un problema.

Le statistiche vengono molto dopo, ossia quando avrai un bel numero di dati nel tuo datase che ti consente di farle.

Rosa84 ha scritto:
se fosse cosi, avremo una tabella dettagliEsami di dimensioni stratosferische
Attenta le TABELLE nelle applicazioni di database sono solo CONTENITORI PRIMORDIALI di dati...come dire...non vanno nemmeno "guardate" dall'utente. Per vedere tutti i dati riferiti a Laviosa Osvaldo, oppure solo di Laviosa Osvaldo del 5/11/2018 ti servi di filtri e/o query. Ma qui si parla poi di tutt'altro che non ha più a che vedere con il discorso "struttura database", ma nel merito delle caratteristiche dell'applicazione database che usi tu.
A
amorosik
Utente Attivo
Iscritto da
nov, 2018
Messaggi:
254
Re: Consiglio per progettazione db
21 nov 2018, 17:25
gibra ha scritto:
Rosa84 ha scritto:

@amorosik
....Scusa la franchezza, ma quell'esempio c'entra come i cavoli.....

Si va bene, per questa volta accetto le scuse
Che non si ripeta piu' pero'
A
amorosik
Utente Attivo
Iscritto da
nov, 2018
Messaggi:
254
Re: Consiglio per progettazione db
21 nov 2018, 18:06
gibra ha scritto:
Rosa84 ha scritto:

@amorosik
Scusa la franchezza, ma quell'esempio c'entra come i cavoli a merenda. Cioè NULLA!
Cerchiamo di non divagare, ed evitiamo di creare confusione a chi pone un determinato problema.
Mi sembra chiaro che:
1- non hai letto il link che ho indicato
or
2- non hai capito quello che c'e' scritto
or
3- non sai come fare un db che risolva il problema posto

Quale delle tre?
Mah, mi augiro per te sia la prima
Perche' leggendo quel 3d si vede che basta cambiare le parole:

-anagrafiche
-esami
-esami dettaglio

con

-articolo
-categoria1
-categoria2

e la descrizione del problema e' IDENTICA
Degli articoli di categorie diverse, ogni categoria ha informazioni di tipo diverso da memorizzare (per le stampanti-peso e velocita, per gli hard-disk transfer-rate e peso, per i monitor peso, diagonale, tecnologia)
Come dire
Degli utenti con esami diversi, ogni esame ha informazioni di tipo diverso da memorizzare (per urine ematocrito e colore, per es-sangue globuli bianchi e colore, per le feci colore, odore, sapore, peso)

E quindi ricapitolando
1 tabella articoli (anagrafica utenti - gigi, toni, piero)
2 tabella categorie1 (esami - urine, sangue, feci)
3 tabella categoria2 (tipo_informazione - peso, colore, sapore, odore, ematocrito, globuli bianchi)
4 tabella tuttelecategorie2xognicategoria1 (esami->tipo_informazioni - per esame urine ci sara' ematocrito e colore, per esame sangue ci sara' globuli bianchi e colore, ...)
5 tabella prenotazioni (il sig GIGI in data 21/11/2018 ha prenotato i seguenti esami...)
6 tabella pren_esami (...urine, sangue, feci, ...)
7 tabella pren_esami_informazioni (ematocrito, colore, globuli bianchi, colore, ....)

Il trucco sta nella tabella 4 che e' quella che consente di associare ad ogni esame uno o piu' tipi_informazioni
Su quella tabella il programma si basera' per sapere quali righe inserire automaticamente nella tabella 7 ogni volta che l'operatore inserisce un esame (riga in tabella 6) in una prenotazione (riga in tabella 5)
In questo modo ogni esame potra' avere un numero qualsiasi di parametri memorizzabili anche diverse centinaia se servisse, la tabella 3 non ha limiti (o comunque sono moltissimo alissimi) come numero di righe inserite

E ciao
O
OsvaldoLaviosa
Super Famoso
Iscritto da
apr, 2012
Messaggi:
7501
Re: Consiglio per progettazione db
21 nov 2018, 18:28
Invito tutti gli utenti a usare toni civili nel pieno rispetto delle regole del forum.

amorosik non puoi dare per scontata la sostituzione dei termini come hai spiegato tu ora. Ci sono decine e decine di database con analoghe similitudini, ma occorre sempre mettere in campo la "logica circostanziale".
In questa sezione del forum si discute di "Progettazione database". L'utente Rosa84 ha iniziato parlando di Esami clinici. Occorre continuare in tale direzione con i nomi tabelle e campi appropriati.

Chiedo a amorosik di chiarire ulteriormente (solo per me...che sono duro di comprendonio):
- i campi chiave di ogni tabella che hai esposto
- le relazioni
A
amorosik
Utente Attivo
Iscritto da
nov, 2018
Messaggi:
254
Re: Consiglio per progettazione db
21 nov 2018, 19:23
Ho solo risposto a chi ha tirato inballo i "cavoli a marenda"
L'analogia tra problema del link che ho indicato ed il problema posto in questo 3d e' PERFETTA
Ora non riesco perche' una pizza fumante mi attende con impazienza
A breve charimenti ulteriori
Ovviamente attendo riscontro dal 'sior dei anei'

Devi accedere o registrarti per scrivere nel forum

27 risposte