Sistemi di Archiviazione e Database

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.

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.

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:

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

6. Database Relazionali vs Non Relazionali

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.

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.