Utilizzi dei modelli di rappresentazione dei dati nei sistemi informativi

Nell’articolo dedicato all’attività di produzione di uno schema o modello dei dati abbiamo visto come esso è strettamente legato alla attività di analisi per un sistema informativo. In effetti gli schemi dei dati possono essere prodotti e utilizzati anche in diversi altri contesti. Essi sono:

• la individuazione del contenuto informativo comune a due o più basi di dati;
• la individuazione delle ridondanze e delle incoerenze tra più basi di dati;
• la produzione dello schema dati della organizzazione;
• l’integrazione di due o più schemi.

Per ciascuno di essi vediamo il significato, l’utilità nel ciclo di vita dei sistemi informativi come possa essere svolta la attività, e qualche esempio di utilizzo.

Individuazione del contenuto informativo comune a due o più basi di dati

Si è detto, in un altro articolo dedicato ai database, che le basi di dati del sistema informativo di una grande organizzazione sono sempre sviluppate nel tempo in maniera disorganica. Per esempio la sola Pubblica Amministrazione (PA) centrale italiana gestisce circa 600 basi di dati di dimensione maggiore di un gigabyte, sviluppate negli ultimi 30 anni. Può essere utile per molte ragioni comprendere quale sia il contenuto informativo comune a due o più basi di dati, ed in particolare:

• per capire se sia opportuno unificare o fondere le due basi di dati, allo scopo di aumentare il numero di interrogazioni o elaborazioni che possono essere effettuate sull’insieme delle due basi di dati, e semplificarne la gestione e l’aggiornamento.
• per capire, anche mantenendo distinte le due basi di dati, quali interrogazioni o elaborazioni ulteriori potrebbero essere fatte collegando le due basi di dati in un sistema
• Per capire quali ulteriori informazioni dovrebbero essere descritte in una o in entrambe le basi di dati per accrescere il contenuto informativo complessivo delle basi di

Per individuare le eventuali ridondanze, intendendo per ridondanza la presenza delle stesse tipologie di informazioni nelle diverse basi di dati. In un sistema distribuito, la presenza di ridondanze è una scelta che va fatta con molta cura, perché ogni ridondanza obbliga a gestire gli aggiornamenti delle diverse copie della stessa informazione attraverso elaborazioni che possono essere anche molto complesse, quanto più l’informazione è duplicata nel sistema. Avendo a disposizione gli schemi concettuali di partenza, il contenuto informativo comune può essere individuato analizzando le entità e le relazioni dei due schemi e selezionando le entità e relazioni con gli stessi nomi, e quelle che pur non avendo gli stessi nomi risultato corrispondere allo stesso concetto del mondo reale.

Individuazione delle incoerenze tra più basi di dati

In questo caso vogliamo comprendere quanto le scelte progettuali effettuate in termini di informazioni rappresentate negli schemi abbiamo portato ad introdurre scelte concettuali diverse nella rappresentazione della stessa tipologie di informazione. Per esempio, in una base dati anagrafica è possibile modellare l’indirizzo di residenza con diverse modalità concettuali:

1. con un unico attributo INDIRIZZO, rappresentato con una stringa di caratteri di lunghezza fissata (esempio, 50 caratteri alfabetici)
2. con quattro attributi: VIA, NUMERO CIVICO, CODICE  AVVIAMENTO POSTALE, CITTÀ, rappresentati rispettivamente con una stringa di caratteri, un numero, un numero, una stringa di caratteri.
3. Con opportune varianti delle scelte

Spesso nel passato, al fine di ottimizzare lo spazio occupato in memoria, sono state effettuate scelte di tipo a, che portano ad una riduzione del numero degli attributi. Ma anche in questo caso, se ci si trovava a realizzare diverse basi di dati in cui compariva lo stesso attributo Indirizzo, potevano essere scelte per le stringhe di caratteri diverse lunghezze. Nella Pubblica amministrazione centrale esistono decine di basi di dati in cui è rappresentato un attributo indirizzo: le basi di dati fiscali, quelle catastali, quelle previdenziali, e cosi via.

Una diversa rappresentazione delle stesse informazioni in basi di dati diverse porta a diversi effetti indesiderati: prima di tutto non è più possibile, o, meglio, diventa molto più difficile, collegare le basi di dati per il tramite della informazione rappresentata in modo incoerente, perché essa può assumere valori diversi. In secondo luogo, diventa molto oneroso l’aggiornamento delle diverse copie. In terzo luogo diventa onerosa qualunque progetto di integrazione delle basi di dati, perché è necessario ricostruire la versione corretta della informazione.

Integrazione di due o più schemi dati

Avere a disposizione gli schemi concettuali delle basi di dati diventa importante anche in qualunque attività di integrazione delle stesse.(vedi figura seguente).

La forma più stretta di integrazione tra basi di dati si ottiene mediante la integrazione delle diverse basi di dati in una unica base dati (figura b), cioè il ritorno alla precedente situazione di totale centralizzazione. In questo caso, avere a disposizione gli schemi concettuali delle basi di dati da integrare permette di arrivare ad una integrazione di natura semantica tra le diverse basi di dati, che tiene cioè conto del significato delle informazioni presenti, e facilita perciò la comprensione tra gli utenti e la correttezza delle elaborazioni. Per fare un esempio, se nelle attuali basi di dati compaiono due  archivi in uno dei quali sono riportati in distinte tabelle i fatturati di un insieme di  aziende nei dodici distinti mesi dell’anno, espressi in migliaia di lire e nell’altro tale insieme di informazioni è rappresentato in  una unica tabella, espressi in milioni, nella base dati integrata tali differenze di rappresentazione vengono rimosse, dando luogo ad una unica omogenea rappresentazione. Questa forma di integrazione è in realtà molto difficile da attuare, per la grande rapidità con cui dati e basi di dati evolvono nelle organizzazioni, e spesso inopportuna o non realizzabile, per la autonomia che utenti e gruppi di utenti intendono mantenere sulle basi di dati da essi create e aggiornate.

Una variante della precedente scelta è quella delle basi di dati distribuite, in cui la base dati è ancora gestita da un unico DBMS, ma può essere frammentata in tante basi di dati locali. Ciò in genere migliora l’efficienza per accessi locali, ma rende più complessi problemi di aggiornamento su diverse basi di dati. In questa soluzione, usualmente, lo schema concettuale dell’insieme delle basi di dati è l’elemento di partenza per compiere le scelte razionali sulle modalità di distribuzione.

Tutte le soluzioni successivamente esposte indeboliscono progressivamente il tipo di integrazione tra le diverse basi di dati. In una base dati federata ad accoppiamento forte le diverse basi di dati vengono gestite autonomamente da diversi DBMS, ma esiste un nuovo componente software che ha la possibilità di accedere omogeneamente  alle diverse basi di dati, coordinandone le operazioni. In questo caso lo schema concettuale è indispensabile per permettere a tale componente software di comprendere dove siano allocate nella federazione le diverse tipologie di informazione, e in quale formato concettuale e logico. In una base di dati federata ad accoppiamento debole, rispetto alla precedente, il nuovo componente garantisce soltanto una visione virtuale integrata, ma non ha potere di intervento gestionale sui sistemi che rimangono fortemente autonomi.

Le tecnologie a gateway (traduttori o filtri tecnologici) permettono di tradurre richieste formulate in un linguaggio per un DBMS A in termini di richieste per il linguaggio adottato dal DBMS B. Hanno il vantaggio che non richiedono nessuno o limitato sviluppo di software aggiuntivo, ma richiedono componenti ad hoc per ogni singola relazione tra sistemi distinti, e fanno perdere la trasparenza resa possibile dalle soluzioni precedenti.

Il meccanismo più debole di integrazione tra basi di dati è quello della estrazione e trasferimento di dati, con aggiornamento periodico della base dati locale a partire dalla base dati remota.

In tutte le precedenti forme di integrazione, questa viene instaurata operando sulle basi di esistenti con nuovi componenti architetturali. Nei data warehouse (magazzini o depositi di dati) viene creata (periodicamente) una nuova base dati, che nasce dalla integrazione stretta delle basi di dati esistenti, e tale nuova base dati viene resa accessibile con potenti linguaggi per l’analisi e la estrazione di informazioni rilevanti a fini decisionali. La produzione dello schema concettuale integrato delle basi di dati è il passo preliminare fondamentale a tutte le attività di produzione del data warehouse.

Produzione dello schema dati della organizzazione

Nella vita di una organizzazione, esistono momenti, ad esempio nella fase di pianificazione dei sistemi informativi, in cui si ha necessità di acquisire una visione integrata e di alto livello, indipendente ciò dalle tecnologie utilizzate e dalle scelte contingenti effettuate, dello stato del sistema informativo della organizzazione. Si pensi ad una Pubblica Amministrazione nella quale sia in corso un processo di riorganizzazione delle competenze, modifica delle strutture organizzative con fusione di alcune, introduzione di strutture di coordinamento, accorpamento delle stesse funzioni in una unica struttura, ecc.

In tali situazioni, può essere molto utile costruire lo schema concettuale di alto livello delle informazioni trattate nella organizzazione, chiamato talvolta “Enterprise schema” o Schema di organizzazione. Naturalmente tale schema può essere prodotto a diversi livelli di dettaglio, e quindi, nella sua versione più estesa può contenere centinaia di entità e relazioni differenti. È ragionevole arrivare alla definizione di uno Schema di organizzazione in cui il numero di entità e relazioni sia contenuto nell’ordine delle decine, non superando mai le 40-50, che possono considerarsi una soglia al di sopra della quale diventa molto complesso e costoso produrre lo schema. Le entità e relazioni che compariranno nello Schema di organizzazione saranno di conseguenza macroentità  e macrorelazioni, cioè entità e relazioni che nascono dalla aggregazione di informazioni elementari utilizzate nella organizzazione.

Come conseguenza del procedimento di costruzione accennato, lo Schema di organizzazione contiene le tipologie di informazioni più importanti trattate nella organizzazione. Collegando in una matrice tali tipologie di informazione, ma soprattutto le entità, con i processi che creano, aggiornano e utilizzano le informazione (vedi tabella seguente) si ha una visione sintetica ma efficace dei flussi informativi tra processi, che permette di individuare le entità aggiornate da più processi, ovvero i gruppi di processi ed entità caratterizzati da alta coesione interna, chiamati in alcune metodologie Aree di business. Una simile matrice può essere prodotta collegando le Unità Organizzative e le Entità.

Matrice o tabella dei Processi/Entità

Processi/ Entità	Entità1	Entità2	Entità3	Entità4	Entità5	Entità6	Entità7
Processo1	Crea			Crea			Usa
Processo2		Usa		Usa	Crea	Usa
Processo3	Usa			Aggiorna	Usa		Crea
Processo4		Usa	Crea
Processo5		Crea				Crea	Usa