Il Sistema Informativo Aziendale
Come un'azienda raccoglie, organizza e distribuisce le informazioni per far funzionare i propri processi e prendere decisioni — dalla gestione con semplici archivi fino alla progettazione professionale di una base di dati e all'integrazione con un ERP.
01Il concetto di sistema informativo aziendale
Prima di parlare di database serve un punto fermo: che cos'è, esattamente, un sistema informativo, e in che cosa si distingue dal sistema informatico che spesso — sbagliando — gli viene sovrapposto.
Definizione
Il sistema informativo (SI) è l'insieme organizzato di persone, procedure, dati e tecnologie che un'azienda utilizza per raccogliere, elaborare, archiviare e distribuire le informazioni necessarie a svolgere le proprie attività e a supportare le decisioni, a ogni livello dell'organizzazione.
Il sistema informativo esiste in ogni azienda, anche in quelle che non usano un solo computer: un negozio che tiene i conti su un quaderno ha comunque un sistema informativo, semplicemente non automatizzato.
Sistema informativo e sistema informatico non sono sinonimi. Il sistema informatico è la parte del sistema informativo che viene realizzata con l'ausilio di hardware, software e reti: è cioè la componente automatizzata. Il sistema informativo, più ampio, comprende anche le procedure manuali, le persone e le regole organizzative che non passano da un computer.
Le componenti del sistema informativo
Risorse umane
Le persone che producono, raccolgono, elaborano e utilizzano le informazioni: impiegati, dirigenti, addetti al data entry, analisti.
Procedure
Le regole, manuali o automatizzate, che stabiliscono come i dati vengono raccolti, trattati e comunicati all'interno dell'organizzazione.
Dati e informazioni
Il dato è un fatto grezzo (es. 07/03); l'informazione è il dato interpretato in un contesto che gli dà significato (es. "il 7 marzo è la data di scadenza della fattura n. 118").
Tecnologie
Hardware, software e reti di comunicazione che, quando presenti, costituiscono il sistema informatico: la parte automatizzata del sistema informativo.
Il flusso informativo
Qualunque sia il grado di automazione, il sistema informativo compie sempre lo stesso ciclo di operazioni sui dati aziendali:
- Raccolta — acquisizione dei dati dalla realtà aziendale (un ordine ricevuto, una consegna, un pagamento).
- Elaborazione — trasformazione dei dati grezzi in informazioni utili (calcolo di un totale, di una giacenza, di uno scaduto).
- Archiviazione — memorizzazione dei dati per un uso futuro.
- Distribuzione — comunicazione delle informazioni a chi ne ha bisogno, nel momento e nella forma adeguati.
L'organizzazione per livelli: la piramide di Anthony
Le informazioni prodotte dal sistema informativo non servono tutte allo stesso modo: cambiano per dettaglio, frequenza e orizzonte temporale a seconda del livello organizzativo a cui sono destinate.
Livello operativo
Attività quotidiane e ripetitive: registrare una fattura, aggiornare il magazzino, evadere un ordine. Servono informazioni dettagliate e frequenti.
Livello direzionale (tattico)
Controllo di gestione e pianificazione a medio termine: verificare gli scostamenti dal budget, valutare le vendite del trimestre. Servono informazioni aggregate e periodiche.
Livello strategico
Decisioni di lungo periodo: aprire un nuovo mercato, lanciare una linea di prodotto. Servono informazioni sintetiche, spesso integrate con dati esterni all'azienda.
Requisiti di qualità
A ogni livello, l'informazione deve essere rilevante, tempestiva, accurata, chiara ed economica da produrre rispetto al beneficio che porta.
02Gestione tradizionale e gestione tramite database
Lo stesso sistema informativo automatizzato può essere realizzato in modi molto diversi. Il confronto tra archivi tradizionali e basi di dati spiega perché, dagli anni '70 in poi, il secondo modello abbia sostituito il primo in quasi ogni contesto aziendale.
Nella gestione tradizionale, ogni applicazione gestisce i propri archivi (file) di dati, progettati in modo indipendente dalle altre applicazioni. Ufficio vendite, ufficio fatturazione e magazzino, ad esempio, tengono ciascuno un proprio archivio clienti.
Via Roma 12, Prato
Via Roma 12, Firenze
Via Roma 12, Prato
L'indirizzo del cliente è duplicato in tre archivi diversi: se uno viene aggiornato e gli altri no, i dati diventano incoerenti tra loro.
I problemi tipici
- Ridondanza — gli stessi dati sono ripetuti in più archivi, con spreco di spazio e di lavoro.
- Inconsistenza — aggiornando un dato in un archivio e non negli altri, le informazioni diventano discordanti.
- Dipendenza dati-programmi — la struttura fisica dei file è scritta dentro il codice dei programmi: cambiare un archivio significa dover modificare tutti i programmi che lo usano.
- Difficoltà di condivisione — applicazioni diverse non accedono facilmente agli stessi dati.
- Interrogazioni rigide — si possono ottenere solo i report previsti in fase di programmazione; una domanda "nuova" richiede di scrivere nuovo codice.
- Sicurezza debole — è difficile controllare in modo fine chi può leggere o modificare cosa.
Nella gestione tramite base di dati (database), i dati sono un'unica risorsa centralizzata, condivisa da tutte le applicazioni e gestita da un software specializzato: il DBMS (Data Base Management System).
Rossi Mario — Via Roma 12, Prato
un'unica versione del dato, letta da vendite, fatturazione e magazzino
I vantaggi
- Controllo della ridondanza — i dati non scompaiono, ma vengono condivisi invece che duplicati.
- Indipendenza dati-programmi — grazie a un'architettura a livelli, i programmi non "conoscono" il modo in cui i dati sono fisicamente memorizzati.
- Condivisione — più utenti e applicazioni accedono agli stessi dati, anche contemporaneamente.
- Integrità — il DBMS applica vincoli (di dominio, di chiave, referenziali) che impediscono l'inserimento di dati scorretti.
- Sicurezza — utenti e permessi granulari su chi può leggere, inserire, modificare, cancellare.
- Gestione della concorrenza — meccanismi (transazioni, blocchi) che regolano accessi simultanei senza conflitti.
- Backup e ripristino — strumenti integrati per recuperare i dati dopo un guasto.
- Linguaggi di interrogazione — con SQL si possono formulare domande nuove sui dati senza scrivere un programma dedicato.
L'indipendenza dei dati: l'architettura a tre livelli
Il vantaggio più importante del modello a database — l'indipendenza tra dati e programmi — si realizza tramite un'architettura a tre livelli di astrazione, nota come modello ANSI/SPARC. È anche il ponte naturale verso il prossimo argomento: le tre fasi di progettazione corrispondono, non a caso, a questi tre livelli.
| Caratteristica | Gestione tradizionale | Gestione tramite database |
|---|---|---|
| Ridondanza dei dati | Alta | Controllata |
| Coerenza tra dati | A rischio | Garantita da vincoli |
| Dipendenza dati-programmi | Forte | Minima |
| Condivisione tra applicazioni | Difficile | Nativa |
| Sicurezza e permessi | Limitata | Gestita dal DBMS |
| Interrogazioni non previste | Richiedono nuovo codice | SQL, immediate |
03Le tre fasi della progettazione di una base di dati
Progettare una base di dati significa costruire uno schema che rappresenti fedelmente la realtà di interesse — la porzione di mondo reale che vogliamo modellare — rispettando correttezza ed efficienza. Il processo si articola in tre fasi, ciascuna a un livello di astrazione via via più concreto: concettuale → logica → fisica, esattamente i tre livelli visti nel capitolo precedente.
La progettazione concettuale traduce la realtà di interesse in uno schema indipendente da qualsiasi DBMS: si descrive cosa rappresentare, non come verrà poi implementato. Lo strumento standard è il modello Entità-Relazioni (E-R).
Entità
Una classe di oggetti del mondo reale, con esistenza autonoma e di interesse per l'applicazione (es. Cliente, Prodotto, Ordine). Si rappresenta con un rettangolo.
Attributi
Le proprietà che descrivono un'entità (es. Cliente: CodiceCliente, Nome, Indirizzo). Uno o più attributi costituiscono la chiave, che identifica in modo univoco ogni occorrenza dell'entità.
Associazioni (relazioni)
Il legame logico tra due entità (es. Cliente EMETTE Ordine). Si rappresenta con un rombo collegato alle entità coinvolte.
Cardinalità
Indica quante occorrenze di un'entità sono associate a occorrenze dell'altra: 1:1, 1:N, N:N (massima), più una minima (0 = opzionale, 1 = obbligatoria).
Un'associazione N:N può avere attributi propri, che non appartengono a nessuna delle due entità ma alla relazione stessa: ad esempio la quantità di un prodotto in un ordine appartiene alla relazione "Ordine–Prodotto", non al Prodotto né all'Ordine singolarmente.
Esempio: schema E-R di un'azienda commerciale
La progettazione logica traduce lo schema concettuale in uno schema logico, tipicamente secondo il modello relazionale: i dati sono organizzati in tabelle (relazioni), le righe sono tuple (record), le colonne sono attributi (campi). Lo schema è ancora indipendente dal DBMS fisico specifico che verrà scelto in seguito.
Le regole di derivazione da E-R a relazionale
- Ogni entità diventa una tabella; i suoi attributi diventano colonne; l'identificatore diventa chiave primaria (PK).
- Un'associazione 1:N si traduce inserendo la chiave primaria della tabella "1" come chiave esterna (FK) nella tabella "N".
- Un'associazione N:N richiede una tabella ponte, la cui chiave primaria è l'unione delle due chiavi esterne provenienti dalle tabelle collegate, con l'aggiunta degli eventuali attributi propri dell'associazione.
- Un'associazione 1:1 può essere risolta fondendo le due entità in un'unica tabella, oppure inserendo la FK in una delle due.
Lo schema logico del caso Cliente–Ordine–Prodotto
| CodiceCliente | RagioneSociale | Indirizzo |
|---|---|---|
| C001 | Rossi Mario | Via Roma 12, Prato |
| NumeroOrdine | DataOrdine | CodiceCliente |
|---|---|---|
| O1001 | 12/09/2026 | C001 |
| CodiceProdotto | Descrizione | Prezzo |
|---|---|---|
| P200 | Trapano avvitatore | 64,90 |
| NumeroOrdine | CodiceProdotto | Quantità |
|---|---|---|
| O1001 | P200 | 3 |
chiave primaria in ambra, chiave esterna in verde-teal. Nella tabella ponte le due FK insieme formano la PK composta.
La normalizzazione
Uno schema logico va verificato — e se serve corretto — per eliminare ridondanze e anomalie di inserimento, modifica e cancellazione. Il processo si chiama normalizzazione ed è organizzato in forme via via più restrittive:
- 1ª Forma Normale (1NF) — ogni attributo deve contenere un valore atomico, non ripetitivo (niente elenchi multipli in una sola cella).
- 2ª Forma Normale (2NF) — ogni attributo non chiave deve dipendere dall'intera chiave primaria, non solo da una sua parte (rilevante quando la chiave è composta).
- 3ª Forma Normale (3NF) — nessun attributo non chiave può dipendere da un altro attributo non chiave (eliminazione delle dipendenze transitive).
A questo livello si definiscono anche i vincoli di integrità referenziale: il valore di una chiave esterna deve corrispondere a un valore esistente della chiave primaria referenziata, oppure essere nullo.
La progettazione fisica traduce lo schema logico in una struttura effettivamente implementabile su un DBMS specifico: qui, per la prima volta, entrano in gioco le caratteristiche del prodotto software scelto (es. MySQL, PostgreSQL, Oracle, SQL Server) e dell'hardware su cui verrà eseguito.
Le attività principali
- Scelta del DBMS in base a costi, prestazioni, compatibilità con l'infrastruttura esistente.
- Traduzione delle tabelle in strutture fisiche reali: file, record, tipi di dato specifici del DBMS scelto (es.
VARCHAR,DECIMAL,DATE). - Definizione degli indici per velocizzare le ricerche più frequenti — tipicamente sulle chiavi primarie e sulle colonne usate spesso nelle ricerche o negli ordinamenti.
- Allocazione dello spazio su disco: organizzazione dei file, eventuale partizionamento delle tabelle più grandi.
- Ottimizzazione delle prestazioni: bilanciare velocità di lettura, velocità di scrittura e spazio occupato.
- Politiche di sicurezza fisica e pianificazione dei backup.
Il risultato della progettazione fisica è lo schema fisico: a differenza di quello concettuale e di quello logico, questo schema dipende dal DBMS scelto. È il motivo per cui, in teoria, si può cambiare DBMS senza dover rifare l'intera progettazione concettuale e logica: solo lo schema fisico va riadattato.
Il caso Cliente–Ordine–Prodotto implementato in SQL
Lo schema logico del capitolo precedente, tradotto in linguaggio DDL (Data Definition Language) per un DBMS relazionale: si scelgono i tipi di dato concreti, si dichiarano chiavi primarie ed esterne, e si crea un indice sulla colonna più interrogata.
CREATE TABLE Clienti ( CodiceCliente CHAR(5) PRIMARY KEY, RagioneSociale VARCHAR(60) NOT NULL, Indirizzo VARCHAR(80) ); CREATE TABLE Ordini ( NumeroOrdine CHAR(6) PRIMARY KEY, DataOrdine DATE NOT NULL, CodiceCliente CHAR(5) NOT NULL, FOREIGN KEY (CodiceCliente) REFERENCES Clienti(CodiceCliente) ); CREATE TABLE Prodotti ( CodiceProdotto CHAR(5) PRIMARY KEY, Descrizione VARCHAR(80), Prezzo DECIMAL(8,2) ); CREATE TABLE DettaglioOrdine ( NumeroOrdine CHAR(6), CodiceProdotto CHAR(5), Quantita INT NOT NULL, PRIMARY KEY (NumeroOrdine, CodiceProdotto), FOREIGN KEY (NumeroOrdine) REFERENCES Ordini(NumeroOrdine), FOREIGN KEY (CodiceProdotto) REFERENCES Prodotti(CodiceProdotto) ); -- indice per velocizzare le ricerche degli ordini di un cliente CREATE INDEX idx_ordini_cliente ON Ordini (CodiceCliente);
Notare la scelta dei tipi: CHAR(5) per codici a lunghezza fissa, VARCHAR per testi a lunghezza variabile, DECIMAL(8,2) per gli importi (mai FLOAT, che introduce arrotondamenti). L'indice su CodiceCliente è una scelta tipicamente fisica: non cambia il significato dei dati, ma accelera le interrogazioni più frequenti.
Perché tre fasi e non una sola?
Separare concettuale, logico e fisico permette di rimandare le scelte tecniche alla fine del processo: prima si capisce bene la realtà da rappresentare (fase concettuale, con l'utente/committente), poi la si struttura in modo formale ma ancora astratto (fase logica), infine la si adatta a un prodotto reale (fase fisica). Un errore nella comprensione della realtà, se scoperto solo alla fine, costerebbe molto di più da correggere.
Altri esempi di progettazione
Tre casi diversi da quello dell'azienda commerciale, per vedere all'opera le altre cardinalità e qualche difficoltà pratica in più: un'associazione 1:1, una 1:N in un contesto diverso, e una N:N che richiede una chiave surrogata.
Dipendente e Badge aziendale
Ogni dipendente ha esattamente un badge, e ogni badge è assegnato a un solo dipendente: cardinalità (1,1) su entrambi i lati.
In fase logica, un'associazione 1:1 non richiede una tabella a parte: si può fondere tutto in un'unica tabella Dipendenti, oppure — se le due entità restano concettualmente separate — inserire la chiave esterna, resa univoca, in una delle due tabelle.
| MatricolaDipendente | Nome | CodiceBadge |
|---|---|---|
| D014 | Bianchi Laura | B-0091 |
Istruttore e Corso in una palestra
Un istruttore tiene più corsi nel corso della settimana, ma ogni corso è tenuto da un solo istruttore: la stessa struttura vista per Cliente–Ordine, applicata a un altro dominio.
| CodiceCorso | Nome | Orario | CodiceIstruttore |
|---|---|---|---|
| CR07 | Pilates | Lun/Mer 18:00 | I003 |
Prestiti in biblioteca
Un utente può prendere in prestito più libri e uno stesso libro può essere prestato, in momenti diversi, a più utenti: è una N:N, come Ordine–Prodotto. Ma qui c'è una complicazione in più.
Se lo stesso utente potesse prendere in prestito due volte lo stesso libro (in date diverse), la coppia (CodiceUtente, CodiceLibro) da sola non sarebbe più univoca: non potrebbe fare da chiave primaria della tabella ponte, perché si ripeterebbe. La soluzione è introdurre una chiave surrogata: un identificativo artificiale, generato dal sistema, che non ha significato nella realtà ma garantisce l'unicità di ogni riga.
| IdPrestito | CodiceUtente | CodiceLibro | DataPrestito | DataRestituzione |
|---|---|---|---|---|
| 1 | U120 | L045 | 03/02/2026 | 17/02/2026 |
| 2 | U120 | L045 | 28/08/2026 | — |
Le due righe mostrano proprio lo stesso utente che prende in prestito lo stesso libro in due periodi diversi: senza IdPrestito le due righe sarebbero indistinguibili come chiave.
04I sistemi ERP e l'integrazione dei processi aziendali
Tutto ciò che abbiamo visto — gestione tramite database, indipendenza dei dati, progettazione a fasi — trova la sua applicazione più ambiziosa in un ERP: un'unica base di dati che, invece di sostenere una sola applicazione, sostiene l'intera azienda.
Che cos'è un ERP
Un ERP (Enterprise Resource Planning, "pianificazione delle risorse d'impresa") è un sistema informativo integrato che gestisce, attraverso un'unica base di dati condivisa, la maggior parte dei processi aziendali: amministrazione e contabilità, vendite, acquisti, gestione del magazzino, produzione, risorse umane, e spesso anche la relazione con i clienti (CRM).
Un ERP non è un singolo programma, ma un insieme di moduli — uno per ciascuna area aziendale — che condividono tutti gli stessi dati, invece di tenerne copie separate.
Dalle isole informative all'integrazione
Prima della diffusione degli ERP (a partire dagli anni '90, evolvendo dai sistemi MRP — Material Requirements Planning, anni '70 — e MRP II, anni '80), ogni reparto aziendale tendeva ad avere un proprio programma gestionale scollegato dagli altri: le cosiddette isole informative (o "isole di automazione"). È esattamente il problema della gestione tradizionale visto nel capitolo 2, ma su scala aziendale.
Prima: isole informative
propria e separata
non sincronizzate
inserite a mano
Ogni reparto lavora con i propri dati: un ordine inserito in Vendite non aggiorna automaticamente Magazzino o Contabilità.
Con l'ERP: un processo, un dato
Tutti i moduli leggono e scrivono sulla stessa base di dati: un evento registrato in un modulo è immediatamente visibile agli altri.
La funzione di integrazione dei processi
Il valore di un ERP non sta tanto nei singoli moduli — che, presi da soli, farebbero più o meno quello che farebbe un programma gestionale dedicato — quanto nel fatto che i processi attraversano i moduli senza soluzione di continuità, perché tutti condividono lo stesso dato.
Un addetto alle vendite registra un ordine cliente nel modulo Vendite. Automaticamente: il modulo Magazzino impegna la quantità di prodotto disponibile; se il prodotto non è sufficiente, il modulo Produzione (o Acquisti) può generare un ordine di produzione o di riordino; alla consegna, il modulo Contabilità genera la fattura, senza che nessuno debba re-inserire manualmente cliente, prodotto o importi in un sistema separato.
Questa integrazione elimina i doppi inserimenti e, di conseguenza, gran parte della ridondanza e delle incoerenze descritte nel capitolo 2: è la stessa logica della gestione a database, applicata non più a una singola applicazione ma all'intera azienda.
Vantaggi e criticità
Vantaggi
- Elimina i silos informativi e la ridondanza tra reparti diversi.
- Offre una visione unica e aggiornata dei dati aziendali (single source of truth).
- Aumenta l'efficienza e la tracciabilità dei processi end-to-end.
- Migliora il supporto alle decisioni, grazie a dati coerenti e in tempo reale a ogni livello della piramide di Anthony.
Criticità
- Costi di acquisto e implementazione elevati.
- Tempi di adozione lunghi e necessità di formare il personale.
- Forte impatto organizzativo: spesso richiede di ripensare le procedure esistenti (change management).
- Necessità di personalizzazione per adattarlo alle esigenze specifiche dell'azienda.
Anche la base di dati di un ERP nasce da uno schema concettuale (E-R), tradotto in schema logico e poi fisico, esattamente come nel caso Cliente–Ordine–Prodotto — solo su scala molto più ampia: centinaia di entità collegate, invece di tre o quattro.
05Glossario lampo
Clicca su ogni scheda per vedere la definizione. Utile per un ripasso veloce prima dell'interrogazione.
06Verifica autocorrettiva
Quindici domande a risposta multipla in stile esame. Scegli una risposta per vedere subito se è corretta, con spiegazione.