Salta la navigazione
La differenza sostanziale tra la OMICOM BAC Suite e le altre soluzioni offerte sul mercato è data da un avanzata quanto originale struttura dati.
Questa particolare architettura consente di ottenere il massimo grado di astrazione ottenibile tra il livello fisico nel DB ( tabelle/campi ) e le entità rappresentate nella applicazione. In altre parole le entità del mondo reale ( cittadino , medico , contatto ) vengono riprodotte nel DB secondo un modello fisico indipendente dal modello stesso.
Rispetto alla tradizionale architettura del DB costruita attraverso il processo di normalizzazione in cui si analizzano le informazioni che concorrono a definire la singola entità, l'architettura della BAC OMNICOM è stata formalizzata analizzando i tipi di dato comuni e le informazioni necessarie a qualificarne il tipo.
Questa particolare soluzione ha permesso di realizzare un sistema con un avanzato indice di aderenza alla evoluzione dei modelli informativi prolungando il ciclo di vita dello stesso.
In un DB con una architettura per cosi dire tradizionale l'aggiunta di nuove informazioni ad una entità esistente avviene attraverso la modifica delle tabelle e in misura maggiore sulla logica di gestione ( stored procedure , procedure , programmi , ecc. ) . Allo stesso modo introdurre una nuova entità ( dati esenzione , referto , ecc. ) nel DB comporta oltre al processo di normalizzazione e creazione della struttura dati la realizzazione di tutta la logica di gestione ( stored procedure )
Nella BAC OMNICOM il completamento delle informazioni di una entità esistente , come l'implementazione di una nuova entità non avviene attraverso la implementazione fisica ( tabelle , campi ) nel DB , ma attraverso il perfezionamento ( descrizione della nuova struttura ) del catalogo che ne descrive le proprietà. Questo livello di astrazione permette di utilizzare senza modifiche strutturali la stessa logica di gestione ( stored procedure ) per le diverse entità. In altre parole l'aggiunta di un nuovo campo ad una entità esistente o l'implementazione di una nuova entità non comporta nessun intervento nel DB , ne come modifica a livello di tabelle ne come intervento sulle stored procedure , in quanto la variazione avviene solo nel descrittore dell'entità che rappresenta la struttura in campi qualificati in base al tipo.
Nella fig. 1 viene mostrato a titolo esemplificativo la correlazione tra i campi di una entità 'Person' descritti attraverso i tipi dato in una struttura XML e le corrispondenti tabelle nel DB. Di seguito viene mostrato a titolo esemplificativo un esempio di descrittore di una entità in formato XML. Il descrittore oltre a rappresentare le informazioni che caratterizzano l'entità , ne descrive il tipo e come sono strutturate all'interno del DB.
Per garantire il massimo in termini di performance delle BAC tutta la logica di gestione delle entità ( inserimento, aggiornamento e query ) è stata implementata utilizzando le stored procedure. Inoltre visto che le entità sono definite da un descrittore in formato XML, cosi come i dati che vengono passati alla stored procedure nell'identico formato , è stato possibile unificare le procedure generiche per l'insert, l'update e la select per tutte le entità.
Figura 1