Sebbene da un punto di vista prettamente informatico la distinzione è netta, spesso capita di far confusione fra programma, banca dati e dati stessi. Queste tre entità sono in genere accomunate dalla “soluzione informatica” e pertanto accade che vengano considerate come un unico artefatto. Tanto per essere chiari, per banca dati si intende il contenitore delle informazioni, per programma le istruzioni che consentono di interagire con la banca dati ed infine per dati si intendono le informazioni memorizzate nella banca dati attraverso il programma.

Tale distinzione è fondamentale nell’ottica della proprietà. Infatti, salvo casi rari in cui un’azienda sviluppa il sistema informatico in proprio, questo viene acquistato presso software house. E quindi si è portati a pensare che la software house sia proprietaria del sistema ma non è così. Vediamo lo scenario standard. I programmi sorgenti Un sistema informatico in genere si compone di un software che implementa l’interfaccia utente o Graphic User Interface (GUI), la business logic dell’applicazione ed infine si occupa del
reperimento e memorizzazione dei dati gestiti. Il software viene prodotto dalle software farm ed implementato utilizzando dei linguaggi di programmazione quali Java, C#, Pascal, ecc. Insomma il software è il fulcro dell’applicazione e la software farm che lo sviluppa è la stessa che si occupa della sua commercializzazione e ne detiene tutti i diritti. Si badi però che il software non viene “venduto”, bensì viene ceduta la licenza di utilizzo. La distinzione è di notevole importanza: il software viene ceduto in formato binario e l’utente finale non ha alcuna possibilità di modificarlo. Se l’utente finale desiderasse acquistare i sorgenti (il che significa la tecnologia, metodologia, l’invenzione e l’applicazione delle soluzioni progettate dal team di ricerca e sviluppo), dovrebbe sborsare centinaia di migliaia di euro. Per chiarire la distinzione con un esempio, si pensi al software in formato binario come ad un’automobile che noi acquistiamo: abbiamo l’automobile, la possiamo usare, rivendere, buttare via, ma non possiamo costruirne una uguale in quanto non abbiamo il progetto, cioè i disegni e i dettagli tecnici che consentono di costruire una macchina simile che, nel nostro esempio, possono essere considerati i sorgenti di un programma.

La banca dati Tutti i programmi che si occupano di gestire dei dati organizzano questi ultimi in forma strutturata utilizzando un contenitore di informazioni chiamato database. Il sistema di gestione di database (Database Management System o DBMS) è un tipo specifico di software e, come già visto, la proprietà dello stesso appartiene alla ditta produttrice. Di conseguenza, l’utente finale, insieme alla licenza di utilizzo del programma gestionale, acquista anche la licenza del database. Il produttore del software dal canto suo, acquista una licenza del DBMS per progettare l’architettura della banca dati. Difatti il DBMS è un contenitore di informazioni che va modellato, uno strumento che consente di progettare e rappresentare banche dati utilizzando concetti come tabelle, indici, chiavi, foreign key, Esistono diversi tipi di DBMS prodotti da ditte differenti che utilizzano diverse metodologie di rappresentazione dei dati. Un dato memorizzato in un DBMS non può essere letto mediante un altro DBMS a meno di appositi programma di conversione. Sempre parafrasando il mondo delle automobili, esistono diversi modelli di utilitarie e, sebbene siano spesso molto simili fra loro, non è possibile staccare un componente di un’automobile e montarlo su un’altra di modello differente. I dati I dati sono le informazioni gestite dal programma, cioè i dati che vengono inseriti dagli utenti e memorizzati, attraverso il software gestionale, nella banca dati. Senza andare a scomodare la legislazione vigente, il raziocinio non lascia alcun dubbio sul fatto che i dati siano di proprietà dell’utente (privato o azienda) che li ha forniti al software.

Indipendenza dal fornitore Da quanto si evince da questo scenario è importante per l’utente finale prestare molta attenzione durante l’acquisto dei prodotti informatici. E’ importante che il software che si acquista sia dotato di procedure di import/export che consentono di estrarre dal database i dati in esso contenuti in un formato “leggibile”, per esempio in formato ASCII oppure XML. Sebbene non sia la soluzione ideale questo fornisce una certa garanzia all’acquirente: se infatti per qualsiasi motivo è necessario cessare il rapporto con il fornitore, si ha almeno la possibilità di recuperare i dati elaborati. Certo, questo non è abbastanza, in quanto poi tali dati dovranno essere passati ad un altro database la cui struttura interna in formato di tabelle verosimilmente è differente, ma comunque è sempre un prezzo inferiore rispetto a quello di dover ripartire da zero. Indipendenza dal fornitore significa sentirsi libero nelle proprie scelte; significa avere la certezza che l’investimento che si va a fare non verrà vanificato per il fatto che il sistema scelto diventi obsoleto. Nell’eventualità di cambio del sistema, il “patrimonio informativo” potrà essere recuperato ed introdotto in un sistema più moderno. Soluzione ideale Ogni produttore di software organizza i dati secondo la propria tecnologia, metodologia, secondo scelte progettuali differente.

Per cui, se consideriamo due prodotti informatici che svolgono lo stesso compito, è alquanto improbabile che gli stessi utilizzino la stessa struttura concettuale del database. Si prenda ad esempio la gestione dell’ufficio tributi dei comuni, in particolare la gestione dell’ICI: tutti i software presenti sul mercato consentono di gestire le denunce, i bollettini, le liquidazioni e gli accertamenti, interrogare il catasto comunale, emettere eventuali provvedimenti sanzionatori, ruolo coattivo e quanto altro. Ma nonostante ciò, ogni software utilizza una struttura di database proprietaria e differente dalle altre. Nel privato c’è poco da fare: ognuno è libero di progettare un artefatto come meglio desidera. Nel pubblico invece, vale a dire nelle PA, a nostro avviso qualcosa potrebbe essere fatto, per esempio, definendo una serie di tracciati record pubblici di interscambio dei dati, qualcosa del tipo di quello già fatto nell’ambito del progetto SAIA per l’interscambio dei dati dei servizi demografici. Si badi, non si sta affermando che il Governo Italiano debba definire il DBMS da utilizzare e stabilire la strutturazione dei dati al suo interno. Questo è senz’altro una prevaricazione alla libertà concettuale delle ditte di produzione. E’ come se si imponesse a tutti i produttori di automobili di fare lo stesso modello e tra l’altro ritengo che nessuna software farm sia disposta a tanto.

Ciò che si auspica è che un’autority indipendente proceda alla definizione più formale della struttura dei dati per l’interscambio, cioè definire degli standard (siano essi in formato ASCII o XML) che diano indicazioni precise su come effettuare l’import/export. Una volta stabilito questo standard, tutte le software farm potranno realizzare solo due procedure una per l’esportazione dei dati nel formato stabilito e l’altra per l’importazione. Lo standard dovrà definire il contenuto dei dati da estrarre ed il loro formato. In questa fase non è importante che i dati siano ben strutturati: le problematiche relative all’ottimizzazione delle ricerche, eliminazione ridondanze, Backus Naur Form, ecc. non dovranno essere prese in considerazione. Quello che è importante è predisporre dei tracciati che possano contenere “tutte le informazioni necessarie per il servizio in oggetto”. Ovviamente qualche programma potrebbe gestire più dati rispetto allo standard stabilito e in tale circostanza tali informazioni potranno andare perdute, ma almeno la parte essenziale del “patrimonio informativo” sarà preservata. Si ribadisce che l’idea non è quella di “imporre”: siamo profondamente contrari a qualsiasi tipo di tecnologia imposta con la forza, sia essa la tv digitale terrestre piuttosto che Internet. L’idea invece è di definire questo standard per facilitare l’interscambio dei dati fra  prodotti differenti, principalmente a garanzia dell’utente finale ma anche a garanzia delle software farm che non avranno più la necessità di realizzare complesse procedure di import specializzate per ogni differente competitor.