Gestire il cambiamento nel tempo delle entità/tabelle con esempio concreto

di il
6 risposte

Gestire il cambiamento nel tempo delle entità/tabelle con esempio concreto

Salve a tutti, ho un problema relativo al tempo, ovvero un'entità che cambia nel tempo (non l'istanza!).
Ho le seguenti tabelle: IMPEGNATIVA, PRESTAZIONE, PRESTAZIONE_IN_IMPEGNATIVA, STRUTTURA_EROGATRICE, AMBULATORIO.

PRESTAZIONE
codice --> id
nome not null
durata not null
descrizione not null

IMPEGNATIVA
codice --> id
medico --> foreign_key
assistito --> foreign_key
numero_prestazioni not null
data_compilazione not null
quesito_diagnostico not null
codice_asl not null
provincia_asl not null

STRUTTURA
codice_struttura --> id
nome not null
indirizzoSede not null
codice_asl --> foreign_key not null
codice_comune --> foreign_key not null

AMBULATORIO
codice_struttura, codice_ambulatorio --> id
codice_ambulatorio not null
nome not null
posizione not null
codice_struttura --> foreign_key not null

PRESTAZIONE_IN_IMPEGNATIVA
codice_prestazione, codice_impegnativa --> id
codice_prestazione --> foreign_key not null
codice_impegnativa --> foreign key not null
codice_ambulatorio --> foreign_key
data_erogazione
ora_erogazione

AMBULATORIO ha la chiave esterna della STRUTTURA_EROGATRICE.
La PRESTAZIONE_IN_IMPEGNATIVA ha la chiave esterna sia della IMPEGNATIVA sia della PRESTAZIONE sia dell'ambulatorio.
Se cancello la struttura o l'ambulatorio perdo il loro riferimento nella tabella PRESTAZIONE_IN_IMPEGNATIVA, come posso aggirare questo problema?
Avevo pensato alla duplicazione inserendo nella tabella PRESTAZIONE_IN_IMPEGNATIVA due attributi opzionali ambulatorio e struttura.
Avevo pensato anche di mantenere le strutture attualmente convenzionate e quelle non convenzionate cosi da evitare la duplicazione dei dati però
dovrei gestire anche l'ambulatorio in modo simile.
Come mi consigliate di operare?
Grazie in anticipo

p.s. ho fatto un mio esempio ma mi interessa soprattutto a livello teorico/generale come ulteriore conoscenza.

6 Risposte

  • Re: Gestire il cambiamento nel tempo delle entità/tabelle con esempio concreto

    Semplice: non devi cancellare nulla.
  • Re: Gestire il cambiamento nel tempo delle entità/tabelle con esempio concreto

    Si scusa effettivamente per come l'ho presentata trae in inganno.
    Innanzitutto manca un altra tabella, ovvero PRESTAZIONE_AMBULATORIO così fatta:

    PRESTAZIONE_AMBULATORIO
    codice_prestazione, codice_ambulatorio --> id
    prezzo

    Inoltre il mio intento è quello di poter prenotare le prestazioni in impegnativa presso un ambulatorio di una struttura che è attualmente convenzionata presso un'asl e tale struttura ha un account.

    Per la convenzione attuale pensavo di eliminare il not null dell'attributo codice_asl nella tabella STRUTTURA così una struttura che non è più convenzionata non ha il riferimento all'asl.
    Il problema è che avrò almeno un attributo NULL per tutte le strutture non convenzionate e se queste sono molte, non è il massimo della progettazione.
    Per l'account pensavo di creare una tabella STRUTTURA_ACCOUNT e una ACCOUNT così fatte:

    ACCOUNT
    username --> id
    password not null

    STRUTTURA_CON_ACCOUNT
    username, codice_struttura --> id

    Quindi se volgio prenotare una prestazione in impegnativa presso un ambulatorio della struttura convenzionata, dovrò controllare se esiste l'attributo codice_asl nella tabella STRUTTURA e non so quanto sia efficiente perchè potrebbero esserci molte strutture non attualmente convenzionate.
    Potrei anche controllare tutte le strutture che hanno un account in quanto queste sono convenzionate, certamente più efficiente ma non so se a rigor di logica sia corretto.
    Inoltre per un ambulatorio appartenente ad una struttura non convenzionata vorrei togliere la relazione con le prestazioni, quindi dovrei togliere l'ennesimo vincolo a livello concettuale e semplicemente dovrei cancellare le istanze relative in PRESTAZIONE_AMBULATORIO a livello fisico.
    Lo schema concettuale (entity relationship) perderà molti vincoli!

    Spero sia chiaro il quadro xD
  • Re: Gestire il cambiamento nel tempo delle entità/tabelle con esempio concreto

    Sinceramente, a mio avviso, la stai facendo più complicata del dovuto.
    Prima di tutto le Prestazioni devono essere gestite con due tabelle Testata e Dettagli, relazionate tra loro.
    Tieni presente che queste due tabelle devono essere considerate come 'storico', il che significa che devono 'vivere di vita propria' .
    Ecco perché ho scritto che non devi cancellare nulla.

    Devi tener presente che non si può relazionare tutto ad ogni costo, in alcune circostanze è assolutamente sbagliato, come in questo caso.
    Chi fa gestionali, come me, lo sa molto bene perché il tutto funziona con lo stesso principio.

    Poi le convenzioni vanno gestite sia sulla testata, sia nei dettagli, in quanto può esistere una convenzione a livello di struttura, ma potrebbe essere che una determinata prestazione (riga di dettaglio) non lo sia.
  • Re: Gestire il cambiamento nel tempo delle entità/tabelle con esempio concreto

    Scusami ma non mi è chiaro cosa intendi con la tabella TESTATA.
    La devo interpretare come una tabella che contiene tutte le prestazioni che eroga una struttura o le prestazioni effettivamente erogate ad un assistito in un giorno?
  • Re: Gestire il cambiamento nel tempo delle entità/tabelle con esempio concreto

    La tabella di TESTATA è quella che contiene i dati generali che, nel tuo caso, mi pare possa essere più o meno come la tabella IMPEGNATIVA.

    In sostanza, dovresti avere due tabelle:
    IMPEGNATIVE_TESTATA
    - IDImpegnativa (PK)
    - altri campi generali

    IMPEGNATIVE_RIGHE
    - IDRiga (PK)
    - IDImpegnativa (FK di IMPEGNATIVE_TESTATA)
    - altri campi della righe

    La prima verrà alimentata dalle varie anagrafiche (Medici, Assistiti, ecc.)
    La seconda va alimentata dalla tabella Prestazioni (anche se è limitativo, ma questo è un'altro discorso che non c'entra).

    Come vedi, non ho inserito nessuna relazione se non quella che lega le righe alla testata: IDImpegnativa.
    Ecco cosa si intende per 'storico'.

    Se, invece, vuoi relazionare altre tabelle anagrafiche, allora sei costretto anche a gestire a parte lo storico di queste ultime.
    Facciamo un esempio pratico di un banalissimo trasferimento di indirizzo:
    La Struttura XYZ era locata in via Roma fino al 12 fino al 31/05/2016; dal 01/06/2016 si è trasferita in via Torino, 22.
    Nell'anagrafica struttura tu dovrai registrare tale modifica, giustamente.
    Ma se vai a ristampare un'impegnativa del 30/05/2016 risulterà che la struttura risiede in via Torino, 22.
    Lo stesso dicasi per il Medico, o l'Assistito, ecc.


    Per evitare questi problemi vi sono diverse soluzioni, più o meno complesse:
    a1) inserisci tutti i dati anagrafici nella tabella di TESTATA
    a2) oppure mantieni i dati anagrafici in una ulteriore tabella, relazionata con l'IDImpegnativa
    c) gestisci lo storico di ogni tabella anagrafica (in una tabella a parte) utilizzando i campi per le date di validità: DataInizio e DataFine.


    Ricorda che i nomi delle tabelle vanno sempre definiti al plurale, quindi Ambulatori, Medici, Prestazioni, ecc.

  • Re: Gestire il cambiamento nel tempo delle entità/tabelle con esempio concreto

    gibra ha scritto:


    La tabella di TESTATA è quella che contiene i dati generali che, nel tuo caso, mi pare possa essere più o meno come la tabella IMPEGNATIVA.

    In sostanza, dovresti avere due tabelle:
    IMPEGNATIVE_TESTATA
    - IDImpegnativa (PK)
    - altri campi generali

    IMPEGNATIVE_RIGHE
    - IDRiga (PK)
    - IDImpegnativa (FK di IMPEGNATIVE_TESTATA)
    - altri campi della righe

    La prima verrà alimentata dalle varie anagrafiche (Medici, Assistiti, ecc.)
    La seconda va alimentata dalla tabella Prestazioni (anche se è limitativo, ma questo è un'altro discorso che non c'entra).

    Come vedi, non ho inserito nessuna relazione se non quella che lega le righe alla testata: IDImpegnativa.
    Ecco cosa si intende per 'storico'.
    Ok ora mi è chiaro, grazie

    gibra ha scritto:


    Ricorda che i nomi delle tabelle vanno sempre definiti al plurale, quindi Ambulatori, Medici, Prestazioni, ecc.
    Scusami ma lo schema relazionale l'ho derivato da quello concettuale ed in quest'ultimo i nomi sono al singolare.
    Suggerimento colto!

    Ti ringrazio per i chiarimenti!
Devi accedere o registrarti per scrivere nel forum
6 risposte