Introduzione ai sistemi informativi
Un sistema informativo (SI) deve provvedere alla raccolta e alla classificazione delle informazioni, da attuarsi con procedure integrate e idonee, al fine di produrre in tempo utile e ai giusti livelli le sintesi necessarie per i processi decisionali, nonché per gestire e controllare le attività dell'ente nel suo complesso. I sistemi informativi trasformano dati (e informazioni) in informazioni e conoscenza così come materie prime e semilavorati sono trasformati in prodotti finiti dai sistemi di produzione.
Che cosa rende un'informazione utile nel processo decisionale?
- Soggettività: il valore associato a un'informazione differisce da individuo a individuo e dipende dal tipo di decisione.
- Rilevanza: l'informazione deve essere pertinente alla decisione da prendere.
- Tempestività: l'informazione è utile alla decisione solo se è disponibile nel momento decisionale.
- Accuratezza: le informazioni devono essere corrette e precise.
- Presentazione: l'informazione deve essere utilizzabile direttamente per la decisione senza ulteriori elaborazioni.
- Completezza: il decisore deve avere a disposizione le informazioni necessarie per prendere una decisione corretta.
- Accessibilità: le informazioni devono essere disponibili appena necessarie a chi le richiede (tenendo in debito conto le necessarie problematiche di sicurezza e privatezza).
DBMS
Un DBMS è un sistema software che gestisce grandi quantità di dati persistenti e condivisi, e che offre supporto per almeno un modello dei dati in grado di fornire agli utenti un'astrazione di alto livello attraverso cui definire strutture di dati complesse e interagire con il DB. La persistenza e la condivisione richiedono che un DBMS fornisca meccanismi per garantire l'affidabilità dei dati (fault tolerance), per il controllo degli accessi e per il controllo della concorrenza.
Un DBMS attua indipendenza tra programmi e dati, e tra programmi e operazioni. Le basi di dati sono elementi fondamentali per la realizzazione di un sistema informativo. Di conseguenza si rende necessaria la presenza di un DBMS come componente essenziale del sistema informatico a supporto del sistema informativo di un ente.
Un Database Engine o Storage Engine è un componente software che un DBMS usa per gestire le operazioni su un DB: Create, Read, Update, Delete (CRUD). Spesso il termine è usato come sinonimo di Database Server o anche di DBMS.
Un Database Instance indica i processi e le strutture dati di un database engine in esecuzione. Un DBS (Data Base System) consiste di un DBMS e di uno o più DB.
Un RDBMS (Relational Data Base Management System) è un DBMS che offre il modello relazionale come modello logico dei dati. La maggior parte dei RDBMS usa il linguaggio SQL (Structured Query Language) per definire, creare, aggiornare e gestire DB.
Una delle caratteristiche più rilevanti di un RDBMS è l'ottimizzazione automatica dell'esecuzione di una query (questa funzionalità nei DBMS di tipo NoSQL è ancora sviluppata a un livello "primitivo"). L'ottimizzatore (optimizer) è un modulo software che si fa carico di determinare il miglior piano di accesso (query plan) per eseguire una query. Sfrutta i metodi di accesso a disposizione e informazioni quantitative (statistiche) sui dati. Un metodo di accesso è un modo (interfaccia) per accedere ai dati, che utilizza una specifica organizzazione "fisica" (implementazione), ad esempio un indice B+tree.
Le fasi di progettazione di un sistema informativo
Raccolta e analisi dei requisiti
Obiettivo: fornire una descrizione organica e coerente dei requisiti informativi illustrando aspetti statici, funzionali e dinamici. A partire dalle prime interviste, il processo di analisi porta, per passi successivi di raffinamento, alla stesura di documenti in grado di rappresentare un modello dell'organizzazione e descrivere i requisiti del sistema informativo da realizzare.
È molto importante ai fini del successo di questa fase che l'interazione fra utenti e analisti sia svolta in modo strutturato e coerente, cercando di superare incomprensioni derivanti dai differenti patrimoni conoscitivi e ambiguità proprie del linguaggio naturale, attraverso verifiche appropriate in itinere. La scelta di un opportuno livello d'astrazione per la stesura delle specifiche è altrettanto essenziale.
Rappresenta la fase in cui sono raccolte e analizzate le specifiche informali ed eterogenee che i vari utenti forniscono circa le procedure da automatizzare mediante un DBMS:
- Requisiti informativi: caratteristiche dei dati;
- Requisiti sui processi: operazioni sui dati;
- Requisiti sulla dinamica: evoluzione nel tempo;
- Requisiti sui vincoli di integrità: proprietà dei dati e delle operazioni.
Attività principali:
- Costruzione di un glossario dei termini;
- Eliminazione delle ambiguità (sinonimi, omonimi);
- Raggruppamento dei requisiti "omogenei".
Fase solo apparentemente semplice, nella realtà è spesso la più complessa perché è difficilmente standardizzabile il processo che porta comprendere che cosa vogliono in realtà gli utenti.
Tassonomia dei metodi di analisi
L'orientamento di un metodo (analisi orientata agli oggetti, analisi funzionale o analisi orientata agli stati) è determinato sia dalla tipologia di SI sia dall'approccio seguito dal team che pone un diverso accento nella modellazione della realtà verso un aspetto ritenuto predominante. La tendenza attuale, negli approcci all'analisi e alla progettazione, consiste nell'integrare modelli di rappresentazione nati per finalità diverse.
Analisi orientata alle funzioni
L'obiettivo è rappresentare un sistema come: una rete di processi, un insieme di flussi informativi tra processi. Ciò corrisponde alla progressiva costruzione di una gerarchia funzionale. Sinonimi di funzione: processo, bolla, attività, trasformazione, transazione.
Spesso in passato nella modellazione funzionale si è fatto ricorso alla rappresentazione con DFD (Data Flow Diagram). Si cita ad esempio l'approccio denominato: Structured Systems Analysis and Design Method (SSADM). Applicazioni orientate alle funzioni —> La complessità risiede nel tipo di trasformazione input-output operata.
Analisi orientata agli oggetti
L'enfasi è posta sull'identificazione degli oggetti e sulla loro classificazione; sulle interrelazioni tra oggetti (come nell’ER). Nel tempo le proprietà strutturali degli oggetti osservati restano abbastanza stabili, mentre l'uso che degli oggetti si fa può mutare in modo sensibile. Applicazioni orientate agli oggetti —> L’aspetto più significativo sono le informazioni, le funzioni svolte non sono molto complesse.
Analisi orientata agli stati
Per alcune categorie di applicazioni può essere utile pensare fin dall'inizio in termini di stati operativi, in cui si può trovare il sistema allo studio, e transizioni di stato. Applicazioni orientate al controllo —> L’aspetto più significativo da modellare è la sincronizzazione fra attività cooperanti nel sistema.
Progettazione concettuale
Obiettivo: fornire specifiche indipendenti dagli strumenti di realizzazione. A partire dai requisiti informativi viene creato uno schema concettuale, cioè una descrizione formalizzata e integrata delle esigenze aziendali, espressa in modo indipendente dal DBMS adottato. A tale scopo si adotta un modello concettuale che permette di fornire descrizioni ad alto livello indipendenti dall'implementazione.
Lo schema concettuale è indipendente anche dal tipo di DBMS che sarà utilizzato (relazionale, gerarchico, key-value, …). Un tipico metodo di progettazione concettuale fa uso di: Schemi Entity/Relationship per modellare gli aspetti statici; Data Flow Diagram per modellare gli aspetti funzionali; State Diagram per modellare gli aspetti dinamici.
Progettazione logica (relazionale)
Obiettivo: descrivere la base dati secondo il modello logico (relazionale) adottato dal DBMS (RDBMS). Consiste nella traduzione dello schema concettuale nel modello dei dati del DBMS. Il risultato è uno schema logico, che è ancora descritto indipendentemente dal particolare DBMS adottato; una volta scelto il DBMS lo schema sarà espresso nel DDL (Data Definition Language) del DBMS stesso.
In questa fase si considerano anche aspetti legati a: integrità e consistenza (vincoli); efficienza. La progettazione logica si articola in due sotto-fasi:
- Ristrutturazione dello schema concettuale;
- Traduzione verso il modello logico
Progettazione fisica
Obiettivo: scelta delle strutture di memorizzazione e degli indici (in parte dipendente dal particolare DBMS), considerando anche il carico di lavoro atteso in termini di query. ES: indice su LINEE_AEREE.CodLinea (chiave primaria) clustered; indice su DESTINAZIONI.CodDest (chiave primaria) clustered; indice su DESTINAZIONI.NomeDest (chiave secondaria) unclustered…
Progettazione dell’applicazione
Obiettivo: realizzazione dei moduli software per le funzioni e per l'interfaccia utente.
Meccanismi di astrazione
L'analista deve far ricorso a tecniche che gli consentano di organizzare e interrogare la conoscenza sul problema via via acquisita. I principali meccanismi di astrazione usati durante il processo di analisi per costruire una base di conoscenza sul problema sono: classificazione, generalizzazione, aggregazione, proiezione.
Classificazione
Consente di raggruppare in classi oggetti, funzioni, o stati in base al loro significato, alle loro caratteristiche e ai vincoli che devono essere soddisfatti.
Classe a livello intensionale
A livello intensionale una classe C denota in modo astratto un insieme U(C) di elementi che sono caratterizzati da proprietà comuni e che devono rispettare determinati vincoli, senza specificare concretamente i singoli elementi, ma avendo ben presente le caratteristiche che ciascuno di essi deve possedere per appartenere alla classe. U(C) è l'insieme universo (detto anche insieme ambiente) delle possibili istanze che la classe rappresenta.
La definizione intensionale di una classe C rappresenta un concetto attraverso la dichiarazione di un tipo di elemento, descrivendo le caratteristiche che deve possedere ogni elemento dell'insieme che C rappresenta, con regole e/o costrutti che consentano la generazione dei suoi elementi.
Esempio U(AUTOMOBILE): { ( Targa: targa_eu, Alimentazione: tipo_alim, Colore: colore_auto, ...) } Ogni elemento dell'insieme che la classe AUTOMOBILE rappresenta una ennupla di valori di proprietà; ciascuna proprietà ha un nome (ad esempio Alimentazione) e assume valori in un certo dominio, ad esempio il tipo tipo_alim definisce il dominio di valori {benzina, metano, GPL, gasolio, ibrida}. Si deve specificare almeno un vincolo d'identificazione perché, per definizione d'insieme, tutti gli elementi devono essere distinti: Targa è identificatore.
Si possono definire inoltre vincoli di varia natura, ad esempio: non è obbligatorio indicare il Colore; la massima emissione di HC dipende dal tipo d'alimentazione e dalla categoria EURO d'appartenenza; ecc.
Classe a livello estensionale
A livello estensionale una classe C, osservata in un certo istante di tempo t, è costituita da un insieme popolato di elementi distinti E(C,t) = {e1, e2, e3,...}, detto anche estensione di C al tempo t; ciascun elemento, detto istanza di E(C,t) (o anche più semplicemente istanza di C), è caratterizzato dai valori delle proprietà definite a livello intensionale. E(C,t) è uno dei possibili sottoinsiemi dell'insieme U(C) definito intensionalmente, cioè E(C,t) U(C); ovviamente un'istanza di E(C,t) è un'istanza di U(C).
Esempio U(GATTO_REGISTRATO) : {( Id: cod_g, CodProp: cod_fiscale, Nome: nome_g, Razza: razza_g, ...) } E(GATTO_REGISTRATO,t) : { (A001, RSSMRA65L22F839J, Briciola, Siamese, ...),(A002, BRNCRL82L70A944K, Fiocco, Persiano, ….), …}
Estensioni legali
E(C,t) deve rispettare tutti i vincoli dichiarati nella definizione di C, sia quelli impliciti derivanti dalla definizione dei domini di valori per le proprietà, sia quelli d'identificazione, sia gli ulteriori vincoli definiti esplicitamente, sia quelli che sono imposti dalla partecipazione ad associazioni con altre classi. Si dice che E(C,t) è "legale" se rispetta tutti i vincoli; altrimenti si dice che è "illegale". La legalità delle estensioni ha molte implicazioni pratiche nella gestione di un DB; violare i vincoli significa portare un DB in uno stato inconsistente.
Cardinalità
Non è in genere possibile avere cognizione certa circa il numero degli elementi (cardinalità) che un'estensione di una classe di oggetti E(C,t) può o deve contenere a un generico istante di tempo, né come è la sua evoluzione nel tempo. Tuttavia, il progettista dovrà in proposito effettuare stime adeguate, d'altra parte a livello fisico l'estensione di una classe è memorizzata in uno spazio in memoria persistente, vi sono esigenze di produrne copie, di trasmissione in una rete di comunicazione, di ordinamento dei suoi elementi secondo un certo criterio, ecc.
Per semplicità di notazione in seguito con E(C) indicheremo una generica estensione di C, eliminando l'indicazione esplicita del tempo, e con |E(C)| la cardinalità di E(C) e, se necessario e sensato, con |U(C)| la cardinalità di U(C). Si tenga presente che in molti casi U(C) è potenzialmente infinita, o comunque non nota a priori e, nella pratica in un DB, ai fini del funzionamento, ciò che interessa in via prioritaria è una stima sensata del valore massimo di |E(C)| che si può osservare.
Esistono classi che a livello estensionale non subiscono variazioni dinamiche rilevanti in termini di cardinalità (si pensi ad esempio a E(CITTÀ) destinata a ospitare le città italiane). Esistono casi in cui è abbastanza semplice effettuare stime per le cardinalità in gioco anche se le variazioni possono essere significative; si pensi ad esempio a E(ORDINE) che contiene gli ordini effettuati da clienti a fornitori, oppure a E(BONIFICO) che ospita i bonifici effettuati dai clienti di una banca. Altre classi invece subiscono, a livello estensionale, una variabilità di cardinalità veramente notevole; si pensi ad esempio ai dati acquisiti da sensori ambientali su un territorio o ai post su Facebook, o in generale al fenomeno dei Big Data.
Cruciale è pertanto, ai fini del buon funzionamento di un SI, la stima del volume dei dati, e del conseguente carico di lavoro atteso in termini di interrogazione, cancellazioni, inserimenti, modifiche.
Generalizzazione
La generalizzazione cattura le relazioni "è un" ovvero permette di astrarre le caratteristiche comuni fra più classi definendo superclassi. Una classe C è una generalizzazione di un gruppo di classi C1, C2, ..., Cn se E(C), E(C1), E(C2),..., E(Cn) ) ogni istanza di E(C1), E(C2), ..., E(Cn) è anche un'istanza di E(C), (cioè qualunque siano le estensioni considerate insieme purché valide). La specializzazione è il processo d'astrazione inverso rispetto alla generalizzazione. Dire che ogni istanza di E(Ci) è anche istanza di E(C) sottintende che l'oggetto è comunque unico indipendentemente da quali proprietà sono considerate (quelle definite per la superclasse o quelle della sottoclasse).
Non possiamo interpretare la frase alla lettera poiché dal punto di vista insiemistico siamo di fronte a insiemi non omogenei.
Copertura delle generalizzazioni
Le generalizzazioni si caratterizzano per due dimensioni indipendenti.
- Confronto fra unione delle specializzazioni e classe generalizzata: totale se E(C), E(C1), E(C2),..., E(Cn) ) si ha E(C)=Ui E(Ci), ovvero la classe generalizzata è l'unione delle specializzazioni; parziale se E(C), E(C1),...,E(Cn) ) tale che E(C) Ui E(Ci), ovvero la classe generalizzata contiene l'unione delle specializzazioni.
- Confronto fra le classi specializzate: esclusiva se E(C), E(C1),...,E(Cn) ) si ha E(Ci) E(Cj) ≠ ∩ ∅, (i≠j), cioè gli insiemi delle specializzazioni sono fra loro disgiunti; sovrapposta (overlapped) se E(C1), E(C2),...,E(Cn) ) tale che (E(C),j) con i≠j per cui E(Ci) E(Cj) ≠ ∩ ∅ ovvero può esistere un'intersezione non vuota fra insiemi delle specializzazioni. Sono ovviamente possibili le quattro combinazioni: (t,e) (p,e) (t,o) (p,o).
Aggregazione
L’aggregazione esprime le relazioni “parte di” che sussistono tra oggetti, tra funzioni, o tra stati. L’astrazione dell’aggregazione consente anche di individuare una classe a partire da un insieme di concetti componenti.
Proiezione
La proiezione cattura la vista delle relazioni strutturali fra gli oggetti, le funzioni, gli stati. Ad esempio, nel descrivere il funzionamento di un certo personal computer può essere necessario distinguere il punto di vista dell'utente operatore, dell'installatore, del programmatore.
Associazioni
È importante modellare anche le associazioni (relationship) che sussistono fra le varie classi. Le associazioni (corrispondenze tra classi) sono di fatto aggregazioni di cui le classi sono le componenti. Un'istanza di un'associazione è una (fra quelle possibili) combinazione (aggregazione) di istanze delle classi che prendono parte all'associazione. Dal punto di vista della modellazione, è importante inoltre caratterizzare queste corrispondenze in termini di vincoli di cardinalità.
Livelli intensionale ed estensionale
Sia A un'associazione fra C1 e C2 (in generale C2 può coincidere con C1). Si può definire A a livello intensionale, pensando genericamente alla possibilità di stabilire legami tra
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.