Corso di Sistemi informativi e basi di dati

Introduzione a sistemi informativi e basi di dati

Ogni sistema aziendale è dotato di un sistema organizzativo, processi, risorse ed un sistema informativo. L’obiettivo dell’azienda è infatti produrre valore tramite un sistema produttivo che trasformi input in output gestendo quanto disponibile tramite un utilizzo coordinato delle risorse. Parametri come efficienza ed efficacia sono fondamentali per massimizzare il risultato dell’azienda: l’efficienza è infatti l’output effettivo rispetto agli input mentre l’efficacia è l’output effettivo rispetto all’output atteso.

Ogni sistema è poi strutturato ed articolato in sottosistemi che, dotati di funzioni specifiche, interagiscono tra loro e con l’esterno. È proprio il (sotto)sistema informativo che gestisce (acquisisce, elabora, conserva, produce) le informazioni utili agli scopi dell’organizzazione stessa eseguendo quelli che vengono chiamati processi informativi. Nonostante si senta spesso parlare di sistema informatico ricordiamo che esso costituisce unicamente la porzione automatizzata del sistema informativo che ne è quindi completamente indipendente.

Le finalità dell’automazione sono infatti l’aumento della capacità elaborativa e l’incremento dell’efficienza (riduzione dei tempi e dei meccanicismi) e dell’efficacia (realizzazione di strumenti utili ai fini dell’aumento dell’output). Il sistema informatico permette dunque di avere importanti riflessioni sull’organizzazione riducendo le risorse slack, estendendo le capacità elaborative dei singoli, favorendo strategie che aumentano la capacità elaborativa e supportando sistemi informativi verticali.

I processi aziendali costituiscono flussi di attività collegate tra loro che seguono una determinata classificazione. Tali processi coinvolgono dati specifici che andranno adeguatamente organizzati.

DBMS e basi di dati

I dati transazionali costituiscono una risorsa strategica per l’azienda poiché più stabili nel tempo rispetto ad altre componenti quali processi o tecnologie. Diamo quindi una definizione di:

• Dato: unità elementare grezza presenza alla conoscenza prima di ogni elaborazione
• Informazione: notizia, dato o elemento che consente di avere conoscenza su fatti o situazioni

Abbiamo espresso qualitativamente i rapporti vigenti tra l’azienda ed i propri (sotto)sistemi riassumibili con l’immagine seguente per memorizzare la struttura caratterizzante di una generica organizzazione.

I primi sistemi di Electronic Data Processing (EDP) nati attorno alla fine degli anni ‘60 permettevano l’automazione di attività viste come processi indipendenti utilizzando linguaggi di programmazione ad alto livello per la gestione dei dati. Essi non solo necessitavano di personale specializzato che potesse utilizzare ogni applicazione ma la portabilità dei sistemi era estremamente ridotta. Non esisteva indipendenza tra dati e programmi poiché, a seguito della modifica dei dati, i programmi dovevano anch’essi subire variazioni e ricompilazioni.

Tali sistemi sfruttavano dei File System che permettevano la gestione fisica dei dati e il controllo degli accessi. Tali caratteristiche portavano ad una ridondanza dei dati (spreco di memoria ed inconsistenza) oltre che alla perdita di capacità di diffusione (stessi significati dei campi ma con nomi diversi di programma in programma). Inoltre l’espressività limitata dei linguaggi di programmazione non permetteva un’adeguata strutturazione e controllo dei dati. Un ulteriore (ma non meno importante problema) era rappresentato dalla mancanza di meccanismi di controllo dell’integrità ma anche di riservatezza e sicurezza che si limitavano alle sole funzionalità previste dal sistema operativo utilizzato.

I metodi tradizionali di creazione e gestione degli archivi su memoria di massa non consentivano quindi di ottenere soluzioni che potessero offrire risposte rapide, flessibili ed affidabili. Nel 1968 si forma il DBTG che stabilirà che obiettivi fondamentali da raggiungere per la gestione e la supervisione dei dati:

• Indipendenza fisica dei programmi dai dati
• Aggregazione di dati omogenei
• Dichiarazione dei soli dati utili nel programma applicativo

Si passa da un modello centrato sul processo ad un modello centrato sul dato. Si definiscono Database Management Systems (o DBMS) i prodotti software disponibili sul mercato che permettono di operare e gestire Basi di Dati ovvero collezioni di dati che supportano le operazioni utili ai fini dell’organizzazione. Tali basi di dati saranno quindi:

• Grandi: poiché di dimensioni maggiori della memoria centrale dei sistemi di calcolo utilizzati
• Condivise: poiché ogni attività dell’organizzazione deve avere un proprio (sotto)sistema informativo
• Persistenti: poiché il loro tempo di vita deve essere indipendente dall’esecuzione dei programmi

La centralizzazione della gestione dovrà quindi garantire:

• Affidabilità
• Privatezza
• Efficienza
• Efficacia

I programmi tradizionali contengono una descrizione della struttura dei file stessi invece nei DBMS esiste una partizione della base di dati, il catalogo o dizionario, che contiene una descrizione centralizzata dei dati che può essere utilizzata dai vari programmi. In ogni base di dati esisteranno:

• Schema: invariante nel tempo e descrivente la struttura (aspetto intensionale - relazione e attributi)
• Istanza: variante nel tempo e rappresentante i valori attuali (aspetto estensionale - righe)

Si definisce come modello di dati un insieme di costrutti utilizzati per organizzare i dati di interesse e descriverne la dinamica. La componente fondamentale di un modello sono i costruttori di tipo, elementi presenti anche in altri linguaggi di programmazione. Modelli logici: sono utilizzati dai programmi ed indipendenti dalle strutture fisiche. Essi vengono adottati nei DBMS esistenti per l’organizzazione dei dati.

• Relazionale (basato sul costruttore di tipo "relazione")
• Reticolare (basato sull’uso dei grafi)
• Gerarchico (basato sull’uso di strutture ad albero)
• Ad oggetti (che estende alle basi di dati il paradigma della programmazione ad oggetti)

Modelli concettuali: permettono di rappresentare i dati in modo indipendente da ogni sistema. Cercano di descrivere i concetti del mondo reale così da essere utilizzati nelle fasi preliminari di progettazione. Il modello più diffuso è quello di Entity-Relationship (E-R).

L’architettura semplificata di un DBMS ricalca dunque la figura seguente:

• Schema logico: descrizione della base di dati nel modello logico (struttura della tabella)
• Schema interno, o schema fisico: rappresentazione dello schema logico per mezzo di strutture di memorizzazione (file, record…)

Le richieste dell’utente espresse tramite linguaggio ad alto livello vengono trasformate in informazioni a basso livello in direzione del disco. È possibile partizionare e ricomporre parti dello schema logico del DBMS così che siano più comprensibili all’utente. Si costituisce dunque uno schema esterno che permette di vedere solo le informazioni di interesse per l’utente proteggendo allo stesso tempo anche i dati.

Schema esterno

• Descrive una parte della base di dati in un modello logico (viste parziali)

L’indipendenza dei dati è la proprietà più importante dei DBMS: è la conseguenza dell’articolazione in vari livelli di astrazione. Infatti utenti e programmi accedono ai dati al più alto livello di astrazione (ovvero il livello esterno che può coincidere con il livello logico) trascurando i dettagli di più basso livello. Si possono distinguere due forme di indipendenza:

• Indipendenza fisica che consente di interagire con il DBMS in modo indipendente dalla struttura fisica dei dati. Quindi livello logico ed esterno risultano indipendenti dal livello fisico (ovvero dallo schema interno) facendo sì che una tabella possa essere utilizzata qualsiasi sia la sua realizzazione fisica tramite organizzazione e allocazione dei file. Viceversa la realizzazione fisica può cambiare senza dover modificare i programmi che utilizzano la base di dati.
• Indipendenza logica che consente di interagire con il livello esterno dei dati in modo indipendente dal livello logico. Quindi livello esterno e livello logico risultano indipendenti tra loro (e dal livello fisico) facendo sì che aggiunte o modifiche alle viste non richiedano modifiche al livello logico o fisico. Viceversa modifiche allo schema logico lasciano inalterato lo schema esterno.

È necessario affermare come gli accessi alla base di dati avvengano unicamente attraverso il livello esterno (o logico qualora coincidessero): è il DBMS stesso che traduce le operazioni in termini dei livelli sottostanti. I DBMS garantiscono quindi:

• Privatezza, poiché si possono definire meccanismi di autorizzazione
• Efficienza, poiché utilizzano al meglio le risorse di spazio di memoria
• Efficacia, poiché rendono produttive le attività dei loro utilizzatori offrendo funzionalità potenti
• Affidabilità, poiché c’è resistenza a malfunzionamenti hardware e software tramite le transazioni

Le transazioni sono un insieme di operazioni:

• Indivisibili, la sequenza di operazioni viene eseguita per intero o per niente
• Corrette, l’effetto di transazioni concorrenti sarà equivalente all’esecuzione separata
• Permanenti, la conclusione positiva di una transazione corrisponde ad un impegno "commit" a mantenere traccia del risultato in modo definitivo, anche in presenza di guasti e di esecuzione concorrente.

Poiché su un DBMS è possibile specificare operazioni di vario tipo, si distinguono i linguaggi per basi di dati in due categorie:

• Linguaggi di Definizione dei Dati (o DDL) utilizzati per definire gli schemi logici, esterni, fisici e le autorizzazioni per l’accesso
• Linguaggi di manipolazione dei dati (o DML) utilizzati per l’interrogazione e l’aggiornamento delle istanze di basi di dati.

L’accesso ai dati, ad ogni modo, può essere effettuato tramite:

• Linguaggi testuali interattivi (SQL)
• Comandi SQL immersi in un linguaggio ospite (Pascal, Java, C++…)
• Comandi SQL immersi in un linguaggio ad hoc che permetta anche altre funzionalità
• Interfacce User-Friendly

Varie categorie di persone possono interagire con gli strumenti visti. Descriviamoli:

• Progettisti e realizzatori di DBMS
• Progettisti e amministratori della Base di Dati (DBA), persona o gruppo responsabile del controllo centralizzato della gestione del sistema, delle prestazioni, dell’affidabilità e delle autorizzazioni. Tali funzioni includono anche quelle di progettazione.
• Progettisti e programmatori di applicazioni
• Utenti: finali che utilizzano transazioni o casuali che operano formulando interrogazioni

Le transazioni possono avere due accezioni: possono infatti essere per l’utente programmi messi a disposizione per realizzare funzioni di interesse (o di utilizzo frequente) mentre per il sistema rappresentano sequenze indivisibili di operazioni. I vantaggi dei DBMS consistono nella gestione di dati condivisi ed organizzati in basi di dati che rispecchiano e costituiscono un modello della realtà con la possibilità di generare economie di scala. Essi permettono di ridurre ridondanze ed inconsistenze promuovendo l’indipendenza dei dati e favorendo con essa lo sviluppo delle applicazioni. Essi risultano efficaci grazie all’utilizzo di linguaggi appositi piuttosto che linguaggi General-Purpose.

Gli svantaggi consistono unicamente nei costi dei DMBS e delle transizioni verso di essi da sistemi usati in precedenza. Non si ha poi la possibilità di scorporare funzionalità particolari che potrebbero non essere di interesse per l’organizzazione con conseguente riduzione di efficienza. Infine il modello di transazione non scala nel caso di architetture cloud, il concetto di schema risulta piuttosto rigido e le operazioni associative sono particolarmente costose.

Il modello logico relazionale

Il modello relazionale fu proposto da E.F. Codd nel 1970 per favorire l’indipendenza, fisica e logica, dei dati. A differenza dei due modelli logici tradizionali (gerarchico e reticolare) il modello relazionale utilizza i valori, anche per i riferimenti tra dati in relazioni diverse, piuttosto che puntatori fra record. Fu reso disponibile sui DBMS dal 1981 basandosi appunto sul concetto matematico di relazione, con una piccola variante, poiché le relazioni hanno naturale rappresentazione per mezzo di tabelle.

Tale concetto di relazione assume significati diversi a seconda dell’accezione considerata:

• Relazione matematica, come nella teoria degli insiemi
• Relazione, come classe di fatti, nel modello Entity-Relationship
• Relazione, come nel modello relazionale dei dati (il nostro caso)

Dati due insiemi D₁ e D₂ si definisce prodotto cartesiano [D₁ X D₂] l’insieme delle coppie ordinate (d₁,d₂) tali che d₁ ∈ D₁ e d₂ ∈ D₂. Una relazione matematica R sugli insiemi D₁ e D₂, detti domini della relazione, è un sottoinsieme del prodotto cartesiano [D₁ X D₂], quindi R ⊆ [D₁ X D₂]. Essa costituisce un insieme di n-uple ordinate d₁,…,d_n tali che siano d₁ ∈ D₁ … d_n ∈ D_n. Poiché una relazione è un insieme si ha che non c’è ordinamento tra le n-uple che sono, quindi, tutte distinte tra loro. Ciascuna ennupla è internamente ordinata poiché il valore i-esimo proviene dal dominio i-esimo.

Per passare da una struttura posizionale ad una non posizionale si associa un nome, detto attributo, che descrive il ruolo del dominio. Invece che una n-upla ogni istanza rappresenta un insieme di coppie {(D₁,v₁),…,(D_n,v_n)} dove D è il nome dell’attributo e v il valore nel dominio del relativo attributo. Quando però una tabella rappresenta formalmente una relazione? Se…

• I valori di ogni colonna sono tra loro omogenei rispetto al significato dell’attributo
• Le righe sono diverse tra loro (come da definizione di insieme)
• Le intestazioni delle colonne sono diverse tra loro

L’ordinamento tra righe e colonne è sempre irrilevante, questa caratteristica è propria delle relazioni. Una base di dati si definisce dunque come un insieme di relazioni collegate tra loro dove i riferimenti fra dati in relazioni diverse sono rappresentati attraverso i valori dei domini che compaiono nelle ennuple. Una struttura basata su valori ha diversi vantaggi quali:

• Indipendenza dalle strutture fisiche
• Rappresentazione dei soli dati rilevanti per l’applicazione
• Visione univoca dei dati per utenti e programmatori
• Portabilità dei dati tra diversi sistemi
• Presenza di puntatori direzionali

Proponiamo alcune definizioni.

• Schema di relazione: un nome R con un insieme di attributi X = {A₁,…,A_n}
  R(X) oppure R(A₁,…,A_n)
  Casa(Indirizzo, Città, Cap)
• Schema di base di dati: un insieme R di schemi di relazione R₁,…,R_n con insiemi di attributi X₁,…,X_n
  R = {R₁(X₁),…,R_n(X_n)}
  Abitazioni {Casa(via, città, paese), Persona(nome, cognome, c.f)}
• (Istanza di) relazione su uno schema R(X): un insieme r di tuple sugli attributi X
• (Istanza di) base di dati su uno schema di base di dati R = {R₁(X₁),…,R_n(X_n)}: un insieme di relazioni r={r₁,r₂,…,r_n} dove ogni r_i è una relazione sullo schema R_i(X_i) per 1<=i<=n

Definiamo inoltre come tupla su un insieme di attributi X = (A₁,…,A_n) una funzione che associa ad ogni attributo A ∈ X un valore del dominio di A. Dunque t : X -> dominio(X). La notazione di tupla assomiglia a quella di ennupla ma sottolinea la notazione non posizionale. Si definisce inoltre t[A] come la restrizione della tupla su A ovvero il valore della tupla "t" sull’attributo A. Dalle definizioni descritte sopra si evince che è possibile avere relazioni costituite un solo attributo. Nel caso di strutture nidificate, come è necessario comportarsi? Nel caso in cui siano presenti ordinazioni identiche avvenute in momenti differenti nello stesso tavolo occorrerà introdurre un attributo che indichi il numero di riga dell’operazione.

Il modello relazionale impone ai dati una struttura rigida che prevede la rappresentazione delle informazioni per mezzo di ennuple di formato corrispondente agli schemi di relazione. È quindi possibile che i dati disponibili non corrispondano al formato previsto. Si presentano dunque casi in cui determinati valori non risultano ammissibili a causa della presenza di:

• Valori sconosciuti
• Valori inesistenti
• Valori senza informazione

Un tale tipo di informazione incompleta potrebbe essere rappresentato mediante valori non utilizzati del dominio che però potrebbero diventare significativi o potrebbero non esistere. Sarebbe inoltre necessario, in fase di utilizzo dei programmi, tener conto del significato di tali valori. Si risolve il problema utilizzando quelli che vengono definiti come valori nulli (non appartenenti al dominio) che denotano l’assenza di un valore del dominio. Dunque è possibile scrivere che t[A] per ogni attributo A può essere un valore appartenente al dominio(A) oppure un valore NULL. Non si possono avere troppi valori nulli poiché esistono istanze di basi di dati che pur essendo sintatticamente corrette non rappresentano informazioni possibili ai fini delle applicazioni utili e di interesse per l’organizzazione. Lo stesso principio si estende anche a tutti i tipi di valori che, pur compresi nel dominio dell’attributo, non rappresentano situazioni reali. Si introduce quindi la nozione di vincolo.