L’evoluzione dell’accesso ai dati nell’informatica

Di - 26 March 2014 - in
Post image for L’evoluzione dell’accesso ai dati nell’informatica

In questo articolo, un po’ didattico, cercherò di presentare quella che è stata l’evoluzione dell’accesso e della gestione dei dati da parte dei programmi per computer. L’evoluzione si snoda attraverso periodi storici che sono segnati da particolari sviluppi delle tecnologie informatiche, un susseguirsi di innovazioni che hanno portato la programmazione dall’essere parte di un sistema autarchico, a costituire unità separate che si uniscono e comunicano liberamente sulla rete.

1950 al 1960 – I programmi e i dati sono completamente isolati

In questo periodo i computer e i sistemi operativi muovevano i loro primi passi. I programmi esistevano più che altro sotto forma di schede perforate che venivano inserite all’interno di lettori. Un programma veniva quindi processato e caricato all’interno della memoria del computer. Il risultato dell’esecuzione dello stesso veniva poi stampato su carta.
L’interazione tra computer, essere umano e dati era molto lineare e di tipo uno ad uno. Non esisteva nessuna interazione diretta tra l’utente e il computer. Tutto si riassumeva nell’inserire delle schede in un lettore, schiacciare un pulsante e poi stampare i risultati. Non c’era modo di condividere i dati se non duplicando fisicamente il materiale cartaceo processato dal computer.

1960 – Accesso a dati archiviati in modo indipendente.

Verso la metà degli anni sessanta i computer divennero più sofisticati, soprattutto per quel che riguardava i sistemi operativi. Finalmente era possibile separare i dati dalle macchine, grazie a lettori a nastro multipli e memorie RAM di maggiore capacità. Per il resto non ci furono altri sostanziali cambiamenti nel modo di accedere e maneggiare i dati. I programmi venivano scritti su schede perforate oppure su nastri .Il processo di esecuzione prevedeva che il programma venisse letto, compilato e quindi eseguito. Questi sono gli anni in cui il modello di database management system dominante era quello navigazionale che prevedeva la navigazione manuale tra dati disposti secondo un modello a rete.
Alla fine degli anni sessanta il sistema che si diffuse maggiormente era  l’IBM System/360 con il celebre sistema operativo OS 360, capace addirittura di eseguire processi multipli. Questo computer era anche dotato di banchi di memoria su disco per un totale di otto banchi e 24mb. IBM sviluppò anche un altro DBMS chiamato IMS, un sistema sviluppato a partire da un’implementazione specifica per il Programma Spaziale Apollo.

Nonostante questo la relazione tra computer-utente-dati era sempre lineare e non prevedeva nessuna interazione diretta tra l’utente e il computer.

1970 – Accesso ai dati attraverso database relazionali.

Verso la fine degli anni sessanta cominciarono ad apparire DBMS basati su un modello nuovo chiamato relazionale. Questi sistemi erano in grado, attraverso la creazione di tabelle ed un approccio più logico e matematico, di supportare l’accesso ai dati da parte di utenti diversi situati online. Alcuni DBMS gestivano i dati archiviati completamente su supporti di massa.
Gli utenti utilizzavano dispositivi tipo Telescrivente, che fornivano risultati stampati su carta, per utilizzare computer dotati di supporti a disco. In alcuni casi invece l’interazione avveniva attraverso monitor CRT, anche se non esisteva una vera e propria grafica.

Telescrivente

Pubblicità di una telescrivente

Nonostante questi progressi, non vi era nessun tipo di interoperabilità tra gli utenti. L’accesso ai dati avveniva direttamente e singolarmente tra utente e computer.
Il sistema navigazionale più famoso, l’IBM IMS (Information Management System), prevedeva l’accesso ai dati in modo diretto oppure attraverso un programma in COBOL.
Il COBOL divenne il linguaggio di programmazione di default per l’accesso ai DBMS.
Di seguito potete vedere un esempio di Hello World in COBOL.

000001 IDENTIFICATION DIVISION.
000002 PROGRAM-ID.     HELLOWORLD.
000003 ENVIRONMENT DIVISION.
000004 CONFIGURATION SECTION.
000005 DATA DIVISION.
000006 PROCEDURE DIVISION.
000007
000008     DISPLAY 'HELLO, WORLD.'.
000009     STOP RUN.

Gli utenti che accedevano online dovevano connettersi sia al DBMS che al database vero e proprio. Non vi era modo per l’utente di accedere a più di un database alla volta oppure trasferire dati da un database all’altro. Cosa ancora più vincolante, non era possibile cambiare la struttura del database in modo semplice. Farlo significava dover ricompilare tutti i programmi che accedevano al database.
In questo stadio della storia dei DBMS non esisteva però nessun linguaggio di tipo query.

1980-1990 – i programmi accedono al database attraverso viste create ad hoc.

Gli anni tra il 1980 e il 1990 videro il diffondersi di diversi avanzamenti tecnologici. Nel comparto dei database furono introdotte le viste che fornivano una modalità di interazione molto più avanzata, creando uno strato di separazione tra il DBMS ed il programma. Attraverso le viste il DBMS poteva effettuare la scansione gerarchica del database e selezionare i record prima che gli stessi venissero presentati al programma.

Durante gli anni ’80 i due modelli di database predominanti erano ancora il modello navigazionale e quello relazionale. Dei due, il secondo fu quello che su diffuse maggiormente. Furono anche gli anni di SQL, letteralmente Structured Query Language, un linguaggio standardizzato per database di tipo relazionale. Venne inventato nel 1974 da un ricercatore che lavorava nei laboratori di IBM e fu fortemente sponsorizzato in ambito accademico oltre che da IBM stessa.
Durante questi anni si combatté quella che viene ricordata come la guerra dei DBMS. I due sistemi in lizza erano i due predominanti e cioè quello navigazionale e quello relazionale. Il secondo, benché molto diffuso, veniva considerato inaffidabile da tutta una serie di settori come quello bancario, assicurativo e governativo. Il motivo era principalmente quello che tutta una serie di processi, come la selezione dei dati e il controllo della loro integrità, venivano lasciati sulle spalle dell’utilizzatore finale.

Questo gap non venne colmato se non verso la fine degli anni ’90, che videro l’introduzione, con SQL 1999, di funzionalità chiamate SQL Object Oriented Features. Queste ultime permettevano l’esecuzione lato server di funzioni quali strutturazione dei dati complessi e processi embedded.

Per quanto riguarda l’hardware, negli anni tra il 1980 e la fine degli anni ’90, si diffusero progressivamente sempre più i Personal Computer. Queste unità, inizialmente rese celebri da Apple e Radio Shack, permettevano di localizzare facilmente dei mini mainframe. Questi dispositivi venivano connessi alla rete ed erano in grado di comunicare e trasferire file da e verso la rete.
Questi furono gli anni d’oro delle BBS (bulletin board system).

2000 – accesso ai dati costruiti come flussi di XML

In questi anni si inziò ad usare il formato XML per la costruzione, l’organizzazione e la gestione dei dati. XML, che sta per eXtensible Markup Language è un sistema che prevede l’assegnazione di marcatori specifici ad elementi contenuti in un documento. Parlando di XML vengono subito in mente concetti come i tag o il web, in cui questo linguaggio viene impiegato.
Per quanto riguarda i DBMS, XML ebbe il grande merito di spostare le regole per la definizione dei dati entro i confini dei dati stessi. Conseguenza diretta di ciò fu il fatto che divenne possibile definire delle specifiche o convenzioni comuni per la conversione dei dati in un formato libero da vincoli di formato.
Tuttavia l’XML non fu però tanto una pallottola d’argento, quanto piuttosto l’opportunità di una pallottola d’argento. A differenza di un altro famosissimo linguaggio a markup, ovvero l’HTML, il linguaggio XML non prevede una grammatica rigida e un numero certo e definito di tag. Piuttosto è un metalinguaggio che permette di definire tag a seconda dell’utilizzo. Da ciò deriva il fatto che se l’organizzazione “A” definisce il valore “0” per la frutta “fragole” e l’organizzazione “B” definische il valore “1” per la frutta “arance”, ecco che i problemi di interoperabilità permangono.
In questi anni la rete si identificava estensivamente con Internet, sul cui protocollo TCP/IP transitavano i dati da e per i terminali fisici.

2006 ed oltre – architettura SOA come metodo di accesso ai dati

Lo step finale del nostro percorso di liberazione dei dati dagli albori dell’informatica ai più recenti sviluppi, passa dalla architettura SOA. Questa sigla sta per Service Oriented Architecture e definisce un trend per cui il design dei programmi si compone di parti di software slegate le une dalle altre e che forniscono servizi ad altri applicativi. Ogni servizio si occupa di compiere una specifica operazione (come fare il sorting di dati in una tabella ad esempio) che si combina, assieme ad altre, a formare un applicativo più vasto (come un DBMS). Questo tipo di approccio rende più semplice la cooperazione di computer diversi connessi ad una rete. Ciascun computer può far girare un numero arbitrario di servizi che comunicano, indipendentemente dall’intervento umano, con altri servizi presenti nella rete e facenti parte dello stesso applicativo generale.
I servizi dell’architettura SOA sono disassociati tra di loro e monolitici, in sé, per quanto riguarda le funzionalità che incorporano. Sono come pacchetti modulari che compongono un programma più complesso ma suddiviso in diverse unità altamente specializzate ed interoperabili. I servizi inoltre, utilizzano non solo protocolli ben definiti ma (ed è geniale!) i dati stessi in essi contenuti, grazie all’uso estensivo del XML, come forma descrittiva di comunicazione con altri servizi. Un sistema di scambio dati che, neanche troppo lentamente scalzando XML, è JSON.  Nell’era SOA XML e JSON non hanno comunque sostituito i database, ma sono soltanto metodi di presentazione e trasmissione di dati che sono comunque contenuti in database (relazionali, ma anche non relazionali: i nuovi sistemi alternativi a quello relazionale aumentano sempre di piú, soprattutto per l’analisi di grandi moli di dati).
La cosa molto emozionante dell’approccio SOA è che  i dati, dall’essere parte del programma, vivono ormai di vita propria fornendo interfacce per l’accesso abbastanza indipendenti tanto dal software per consultarli tanto dalla struttura dati che li contiene.

Ci sarebbe moltissimo da dire sul concetto di SOA. Quel che interessa a noi è che questa architettura rappresenta il tassello finale (per ora) di quello che è stato un percorso di liberazione dei dati e dei programmi da sistemi concettualmente (e per necessità) impermeabili verso un approccio che vede in essi il potere di comunicare e costruire nuovi percorsi informativi.

Fonte | Data and Process Binding Evolution, Part 1, Part 2

Fonte Immagini | nachiketkapre – dukeunivlibraries

Leave a Reply

Gabriele Visconti Articolo scritto da

Editor in Chief per Engeene. Appassionato di Linux, FOSS, videogame e, da poco, di cucina. Parla quattro lingue ed ama leggere libri in lingua inglese.

Contatta l'autore

Previous post:

Next post: