1. Sistemi di Archiviazione Classici

I sistemi di archiviazione classici si riferiscono alla gestione e conservazione dei dati prima della diffusione massiva di database e software avanzati. Possono essere:

  • Fisici: Archivi cartacei, documenti, schedari organizzati manualmente.
  • Digitali non strutturati: File di testo, fogli di calcolo, o semplici strutture di directory su computer.

Caratteristiche

  • Architettura semplice.
  • Dati spesso duplicati o ridondanti.
  • Difficoltà nella ricerca e aggiornamento.
  • Vulnerabilità a errori umani e problemi di sicurezza.

Esempi

  • Schedari fisici per documenti.
  • File system per organizzare manualmente dati in cartelle.

2. Database e DBMS

Un database è una raccolta organizzata di dati strutturati che consente l’accesso, la gestione e l’elaborazione rapida delle informazioni. Un database è come una biblioteca altamente organizzata, dove ogni libro rappresenta un record e le informazioni contenute nel libro (titolo, autore, data di pubblicazione) sono i campi. A differenza di una biblioteca fisica, un database digitale permette di cercare, ordinare e aggiornare le informazioni in modo estremamente rapido ed efficiente.

Tipi di database:

  1. Relazionali: Strutturati in tabelle con relazioni tra di esse.

Esempio pratico: Un database relazionale per un negozio online potrebbe avere tabelle per i prodotti (ID prodotto, nome, prezzo, descrizione), i clienti (ID cliente, nome, cognome, indirizzo) e gli ordini (ID ordine, data, cliente, prodotti).

  1. Non relazionali: Dati non strutturati o semi-strutturati (es. JSON, XML).

Esempio pratico: Un database NoSQL documentale potrebbe essere utilizzato per archiviare i post di un social network, dove ogni post è un documento con campi come autore, data, testo e allegati.

Pubblicità

DBMS (Database Management System)

Un DBMS è un software che consente agli utenti di interagire con un database. È responsabile della creazione, lettura, aggiornamento e cancellazione dei dati.

Funzioni principali:

  • Creazione e gestione di database.
  • Fornitura di interfacce per query (es. SQL).
  • Sicurezza dei dati e controllo degli accessi.
  • Garantire integrità e coerenza dei dati.

Esempi di DBMS:

  • Relazionali: MySQL, PostgreSQL, Oracle Database.
  • Non relazionali: MongoDB, Cassandra, Redis.

Esempi specifici:

Netflix

  • Cassandra: Per gestire i metadati dei contenuti, come i dettagli di film e serie.
  • DynamoDB: Per gestire informazioni sugli utenti e le loro preferenze.
  • MySQL: Per dati relazionali e reportistica interna.
  • ElasticSearch: Per la ricerca nei cataloghi di contenuti.
  • S3 (Amazon Web Services): Per l'archiviazione di contenuti multimediali e backup.

Amazon

  • DynamoDB: Database NoSQL altamente scalabile per la gestione del catalogo prodotti, ordini, e informazioni transazionali.
  • Aurora (RDS): Database relazionale per applicazioni che richiedono conformità ACID.
  • Redshift: Per analisi di big data e business intelligence.
  • ElasticSearch: Per migliorare la funzionalità di ricerca sul sito.
  • S3 (Simple Storage Service): Per archiviazione scalabile e distribuita.

Facebook (Meta)

  • MySQL: Per gestire dati relazionali come profili utenti e connessioni tra amici, con una struttura pesantemente modificata per scalare a miliardi di utenti.
  • Cassandra: Per la gestione di dati distribuiti e alta scalabilità.
  • RocksDB: Database key-value interno utilizzato per alta efficienza nei servizi backend.
  • HBase: Utilizzato per archiviare e analizzare grandi quantità di dati in tempo reale.
  • TAO: Un sistema di database interno per gestire le relazioni tra gli utenti.

Instagram

  • PostgreSQL: Come database principale per i dati relazionali, incluso il backend dell'app.
  • Cassandra: Per la gestione dei feed degli utenti e per garantire la scalabilità.
  • Redis: Per la gestione di dati temporanei e caching (es. velocizzare i feed).
  • Memcached: Per la memorizzazione nella cache di query frequenti.

TikTok

  • TiDB: Un database SQL distribuito per gestire grandi quantità di dati in modo scalabile.
  • HBase: Per la gestione di dati in tempo reale e per lo storage a lungo termine.
  • Redis: Utilizzato per il caching e migliorare le performance in tempo reale.
  • Kafka: Anche se non è un database, è usato per la gestione di messaggi e lo streaming di dati.

Google

  • Bigtable: Un database distribuito altamente scalabile, utilizzato per diversi prodotti (ad esempio, la ricerca web e Gmail).
  • Spanner: Un database relazionale distribuito che garantisce coerenza globale e alta disponibilità.
  • Firestore: Un database NoSQL document-based utilizzato principalmente per app Firebase.
  • MySQL: Per servizi relazionali in varie applicazioni.
  • Colossus: Sistema di archiviazione distribuita che alimenta servizi come Google Drive.

3. Sistemi Informativi e Sistemi Informatici

Sistemi Informativi

Sono sistemi organizzati per raccogliere, elaborare, immagazzinare e distribuire informazioni utili per il processo decisionale.

  • Possono essere manuali (documenti cartacei) o digitalizzati.
  • Utilizzati per ottimizzare il flusso di informazioni in un’organizzazione.

Componenti principali:

  1. Hardware: Computer, server.
  2. Software: DBMS, applicazioni gestionali.
  3. Persone: Utenti e amministratori.
  4. Procedure: Regole e processi per gestire il sistema.

Sistemi Informatici

Un sottoinsieme dei sistemi informativi che si focalizza sull’uso della tecnologia informatica per automatizzare i processi.

Pubblicità

Differenza chiave:

Tutti i sistemi informatici sono sistemi informativi, ma non tutti i sistemi informativi sono informatici.

4. Proprietà ACID

Le proprietà ACID sono un insieme di garanzie per garantire l’affidabilità delle transazioni in un database.

  1. Atomicità: Ogni transazione è indivisibile. O viene completata completamente, o viene annullata.
    Esempio: Se trasferisci denaro da un conto all’altro, entrambe le operazioni devono avvenire.
  2. Coerenza: Dopo una transazione, il database rimane in uno stato valido.
    Esempio: Non si possono trasferire più soldi di quanti ne sono disponibili.
  3. Isolamento: Le transazioni simultanee non interferiscono tra loro.
    Esempio: Due utenti che accedono agli stessi dati non si danneggiano a vicenda.
  4. Durabilità: Una volta completata, una transazione è permanente, anche in caso di guasti.
    Esempio: Dopo un trasferimento di denaro, i dati restano intatti anche in caso di spegnimento improvviso del sistema.

Le proprietà ACID (Atomicità, Consistenza, Isolamento, Durabilità) sono fondamentali per garantire che le transazioni nei database siano affidabili e sicure. Vediamo un esempio pratico per ciascuna proprietà, utilizzando una transazione bancaria come scenario.

Scenario: Trasferimento di denaro

Supponiamo che un utente voglia trasferire €100 dal Conto A al Conto B. Questa operazione può essere rappresentata da due passaggi principali:

  1. Sottrarre €100 dal Conto A.
  2. Aggiungere €100 al Conto B.

Questi passaggi devono rispettare le proprietà ACID per garantire la correttezza della transazione.

1. Atomicità

Definizione: Una transazione è atomica, cioè tutto o niente. O viene eseguita completamente o viene annullata senza lasciare effetti parziali.

  • Esempio pratico: Durante il trasferimento:
    • Se il primo passaggio (sottrarre €100 dal Conto A) riesce, ma il secondo passaggio (aggiungere €100 al Conto B) fallisce per un qualsiasi motivo (es. crash del sistema), allora l'intera transazione viene annullata. Il Conto A deve rimanere invariato, senza perdere i €100.
  • Garanzia: Nessun conto sarà in uno stato incoerente (es. i soldi sono stati prelevati da A, ma non sono stati aggiunti a B).

2. Consistenza

Definizione: Una transazione deve mantenere il database in uno stato consistente, rispettando tutte le regole e i vincoli definiti.

  • Esempio pratico: Prima della transazione, il saldo totale nei due conti è €500 (Conto A: €400, Conto B: €100).
    • Dopo il trasferimento, il saldo totale deve rimanere €500 (Conto A: €300, Conto B: €200).
    • Se un errore interrompe la transazione, la somma dei saldi non deve mai risultare incoerente (es. €400 invece di €500).
  • Garanzia: Le regole del database, come la somma totale dei saldi, vengono sempre rispettate.

3. Isolamento

Definizione: Anche se più transazioni vengono eseguite contemporaneamente, ciascuna transazione deve essere eseguita come se fosse l'unica in corso, senza interferenze.

  • Esempio pratico: Supponiamo che contemporaneamente:
    1. L'utente A trasferisca €100 dal Conto A al Conto B.
    2. Un altro utente visualizzi il saldo dei conti.
    • Durante l'esecuzione della transazione, il secondo utente non deve vedere uno stato intermedio (es. Conto A: €300, ma Conto B: ancora €100). Il saldo aggiornato sarà visibile solo dopo il completamento della transazione.
  • Garanzia: Ogni transazione è isolata dalle altre e il database evita problemi come:
    • Letture sporche (un'operazione legge dati non confermati).
    • Letture non ripetibili (il valore di un dato cambia durante una transazione).
    • Phantom reads (un'altra transazione modifica i dati visibili a una query).

4. Durabilità

Definizione: Una volta confermata una transazione, le sue modifiche devono essere permanenti, anche in caso di guasti al sistema.

  • Esempio pratico: Dopo che il trasferimento di €100 è stato completato e confermato:
    • Anche se il server si spegne improvvisamente o c'è un'interruzione di corrente, i saldi aggiornati (Conto A: €300, Conto B: €200) devono essere conservati nel database.
  • Garanzia: Il database utilizza tecniche come log delle transazioni o write-ahead logging per assicurarsi che i dati confermati non vadano persi.

Esecuzione completa della transazione

  1. Inizio transazione: Il sistema avvia il trasferimento.
  2. Step 1: Sottrae €100 dal Conto A.
  3. Step 2: Aggiunge €100 al Conto B.
  4. Commit: Le modifiche vengono confermate e rese permanenti.
  5. Failover: Se un errore si verifica in uno qualsiasi degli step, il sistema esegue un rollback e riporta il database allo stato precedente all'inizio della transazione.

Ecco un altro scenario pratico che rispetta le proprietà ACID, legato a un sistema di prenotazione di biglietti per un evento.

Scenario: Prenotazione di biglietti per un concerto

Un cliente vuole acquistare 2 biglietti per un concerto. Il sistema deve:

Copertina: 50 Algoritmi per imparare PHP
📚 Consigliato per te

50 Algoritmi per imparare PHP

Una guida step by step per imparare PHP con esercizi svolti.

Vedi su Amazon
  1. Controllare la disponibilità dei biglietti.
  2. Ridurre il numero di biglietti disponibili.
  3. Confermare la prenotazione e registrare i dati del cliente.

La transazione deve rispettare le proprietà ACID per garantire affidabilità, anche in un sistema con molti utenti che prenotano contemporaneamente.

1. Atomicità

Definizione: L'intera operazione deve essere eseguita completamente o annullata senza lasciare effetti parziali.

  • Esempio pratico:
    • Il cliente seleziona 2 biglietti e inizia la prenotazione.
    • Se il pagamento non riesce o il sistema si blocca, i biglietti non devono essere sottratti dal totale né riservati parzialmente.
    • Se il processo fallisce, i biglietti devono rimanere disponibili per altri clienti.

Garanzia: Non ci sono biglietti persi o bloccati inutilmente.

2. Consistenza

Definizione: La transazione deve mantenere il sistema in uno stato consistente, rispettando i vincoli definiti.

  • Esempio pratico:
    • Numero iniziale di biglietti disponibili: 100.
    • Dopo la prenotazione di 2 biglietti, il sistema deve assicurarsi che il numero di biglietti sia ridotto a 98.
    • Se la transazione fallisce, il totale rimane 100.
    • Il database deve rispettare vincoli come: non vendere più biglietti di quelli disponibili.

Garanzia: Nessun dato incoerente (ad esempio, vendere più biglietti di quelli effettivamente disponibili).

3. Isolamento

Definizione: Ogni transazione deve essere isolata dalle altre, garantendo che non interferiscano tra loro.

  • Esempio pratico:
    • Mentre il cliente A sta prenotando 2 biglietti, il cliente B sta contemporaneamente cercando di acquistare gli ultimi 5 biglietti.
    • Se il cliente A completa la prenotazione prima, il cliente B vedrà solo 98 biglietti disponibili nel sistema.
    • Non ci saranno letture intermedie o conflitti tra le transazioni.

Garanzia: Ogni cliente vede uno stato consistente dei biglietti disponibili e le transazioni concorrenti non si sovrappongono.

4. Durabilità

Definizione: Una volta confermata la prenotazione, i dati devono essere permanenti, anche in caso di guasto.

  • Esempio pratico:
    • Dopo che il cliente ha completato la prenotazione e il pagamento è stato confermato:
      • I biglietti vengono registrati come venduti nel database.
      • Se il sistema si blocca immediatamente dopo, al riavvio i biglietti devono risultare ancora prenotati.
    • Questo è garantito da tecniche come write-ahead logging o backup dei dati transazionali.

Garanzia: La prenotazione è salvata in modo permanente una volta confermata.

Esecuzione della transazione

  1. Inizio transazione: Il cliente seleziona i biglietti e avvia la prenotazione.
  2. Controllo disponibilità: Il sistema verifica se ci sono abbastanza biglietti disponibili.
  3. Aggiornamento database: Riduce il numero di biglietti disponibili nel database.
  4. Registrazione dati cliente: Salva la prenotazione associandola al cliente.
  5. Commit: Le modifiche vengono confermate.
  6. Rollback (in caso di errore): Se qualcosa va storto, il sistema riporta i biglietti allo stato originale.

Conclusione

Questo scenario mostra come le proprietà ACID garantiscono che:

  • Non ci siano prenotazioni incomplete o errate.
  • Il database mantenga uno stato coerente anche in presenza di molti utenti concorrenti.
  • I dati delle prenotazioni confermate siano protetti e persistenti.

Le proprietà ACID sono fondamentali per garantire affidabilità nei sistemi di ticketing, dove errori o inconsistenze potrebbero causare perdita di vendite o conflitti tra prenotazioni.

Le proprietà ACID garantiscono che i dati rimangano corretti, coerenti e protetti in tutte le fasi di una transazione. Questo è essenziale in scenari critici come le operazioni bancarie, la gestione degli ordini online o i sistemi di prenotazione.

5. Vantaggi e Svantaggi: Sistemi Classici vs Moderni

CaratteristicaSistemi ClassiciSistemi Moderni
VantaggiSemplici, economici, richiedono poca tecnologia.Velocità, automazione, analisi avanzate, sicurezza.
SvantaggiLenti, errori manuali, difficoltà di accesso.Complessità tecnica, costi elevati, richiedono manutenzione.
FlessibilitàBassa, adattabili solo a piccoli contesti.Elevata, scalabili per grandi volumi di dati.
SicurezzaVulnerabili (fisicamente e digitalmente).Sistemi avanzati di protezione (crittografia, accessi).

6. Database Relazionali vs Non Relazionali

CaratteristicaDatabase RelazionaliDatabase Non Relazionali
ModelloTabelle con righe e colonne (es. SQL).Dati strutturati in documenti, grafi o colonne.
LinguaggioUsano SQL.Query basate su API o linguaggi specifici.
EsempiMySQL, PostgreSQL, SQLite.MongoDB, Cassandra, DynamoDB.
ScalabilitàVerticale (più risorse a un singolo server).Orizzontale (aggiungere server).
Adatto perSistemi ben strutturati (es. ERP, CRM).Big data, dati semi-strutturati (es. social media).
VantaggiIntegrità dati, transazioni ACID.Flessibilità, velocità con grandi volumi di dati.
SvantaggiRigidità nella struttura.Mancanza di ACID in alcune implementazioni.

7. Ridondanza e Inconsistenza

Ridondanza dei Dati

La ridondanza si verifica quando gli stessi dati sono memorizzati in più punti all'interno di un sistema. La ridondanza può portare a risparmi in termini di accesso e performance, ma può anche causare inconsistenza se i dati non vengono aggiornati in tutti i luoghi in cui si trovano.

Inconsistenza dei Dati

L'inconsistenza si verifica quando i dati non sono uniformi, spesso a causa di errori nelle transazioni o nella gestione della ridondanza. Questo può portare a dati errati o contraddittori nel sistema.

📘 Vuoi approfondire l'argomento? Dai un'occhiata a 50 Algoritmi per imparare PHP — vedi su Amazon.

Strategie di Gestione:

  • Normalizzazione: Evita la ridondanza nei database relazionali, migliorando la coerenza.
  • Replica dei dati: Utilizzata per migliorare la disponibilità, ma rischia di introdurre

8 La Concorrenza e il Locking nei Database

Concorrenza nei Database

La gestione della concorrenza è cruciale per un DBMS. Più utenti o applicazioni possono cercare di accedere o modificare i dati contemporaneamente. Senza una corretta gestione, si possono generare conflitti e incoerenze nei dati.

Locking (Blocco)

  • Locking a livello di riga: Blocca solo la riga di dati in cui un'operazione è in corso.
  • Locking a livello di tabella: Blocca tutta la tabella durante l'operazione.
  • Deadlock: Si verifica quando due o più transazioni sono in attesa l'una dell'altra, e nessuna di esse può proseguire.

Gestione della Concorrenza

I DBMS moderni utilizzano algoritmi di controllo della concorrenza per evitare deadlock e garantire che le transazioni siano eseguite in modo sicuro senza interferire con altre operazioni.

9 La Sicurezza dei Dati nei Sistemi Informativi

Sicurezza dei Dati

Un tema cruciale che si lega alla protezione dell’integrità, della riservatezza e della disponibilità dei dati. I sistemi di gestione dei database devono implementare misure di autenticazione, autorizzazione, crittografia e audit per proteggere i dati da accessi non autorizzati.

Tecniche di Sicurezza

  • Crittografia: Protezione dei dati sensibili tramite l'uso di algoritmi che rendono il dato incomprensibile senza la chiave di decrittazione.
  • Autenticazione e Autorizzazione: Verifica dell'identità degli utenti (autenticazione) e gestione dei permessi su ciò che possono fare con i dati (autorizzazione).
  • Audit: Monitoraggio delle attività nel database per garantire che non vi siano violazioni delle politiche di sicurezza.

Vantaggi della Sicurezza Avanzata:

  • Protezione dei dati sensibili.
  • Garanzia di conformità alle normative sulla protezione dei dati (ad esempio, GDPR).
  • Minimizzazione del rischio di attacchi o violazioni.

Svantaggi:

  • Costi aggiuntivi per implementare soluzioni di sicurezza avanzate.
  • Possibile rallentamento delle prestazioni a causa delle operazioni di crittografia e autenticazione.

Conclusioni

  • I sistemi classici hanno ancora un ruolo, ma le soluzioni moderne (DBMS) dominano per complessità e volumi elevati.
  • Le proprietà ACID garantiscono la robustezza dei database relazionali, ma le soluzioni non relazionali offrono flessibilità per specifici scenari.
  • La scelta tra sistemi relazionali e non dipende dal contesto d’uso: dati strutturati vs semi-strutturati o non strutturati.