ACID
ACID è un acronimo fondamentale nel contesto dei sistemi di gestione di database (DBMS) e delle transazioni, che descrive un insieme di proprietà essenziali per garantire l’affidabilità e l’integrità dei dati. Le quattro proprietà sono:
1. Atomicità (Atomicity): Una transazione è considerata un’unità indivisibile di lavoro. O tutte le operazioni che la compongono vengono completate con successo (commit), o nessuna di esse viene applicata, e l’intera transazione viene annullata (rollback). Questo assicura che il database non si trovi mai in uno stato parzialmente aggiornato.
2. Consistenza (Consistency): Una transazione deve portare il database da uno stato valido a un altro stato valido. Deve rispettare tutte le regole, i vincoli, i trigger e le relazioni definite nello schema del database, mantenendo l’integrità dei dati e la coerenza logica.
3. Isolamento (Isolation): Le transazioni concorrenti devono apparire come se fossero eseguite in sequenza, senza interferire l’una con l’altra. L’esecuzione di una transazione non deve essere influenzata o influenzare altre transazioni in corso, prevenendo problemi come letture sporche (dirty reads) o letture non ripetibili (non-repeatable reads).
4. Durabilità (Durability): Una volta che una transazione è stata confermata (commessa), le modifiche apportate sono permanenti e devono sopravvivere a eventuali guasti del sistema, come interruzioni di corrente o crash. Questo è tipicamente garantito attraverso la scrittura dei dati su memoria non volatile e l’uso di log di transazione.
attributi
Nel contesto dei database relazionali, un attributo è una caratteristica o proprietà specifica che descrive un’entità (o una tupla/riga) all’interno di una tabella. Rappresenta un tipo di informazione che viene memorizzata per ogni istanza dell’entità. Concettualmente, un attributo corrisponde a una colonna in una tabella.
Ogni attributo possiede un nome univoco all’interno della tabella e un dominio, ovvero l’insieme di tutti i valori possibili che può assumere (definito dal suo tipo di dato, come testo, numero intero, data, booleano, ecc.). Ad esempio, in una tabella “Clienti“, “Nome“, “Cognome“, “Indirizzo” e “Telefono” sarebbero attributi.
Gli attributi sono fondamentali per la struttura e la semantica dei dati. Possono essere semplici (atomici, non ulteriormente scomponibili) o composti (formati da più attributi semplici, come “Indirizzo” che può essere scomposto in “Via”, “Civico”, “Città”). Possono anche essere a valore singolo o a valori multipli (sebbene questi ultimi siano spesso normalizzati in tabelle separate nei database relazionali).
Un attributo o un insieme di attributi può fungere da primary key / chiave primaria (identificatore univoco di una riga) o da foreign key / chiave esterna (stabilendo relazioni tra tabelle), evidenziando il loro ruolo cruciale nell’integrità e nella relazionalità dei dati.
B.A.S.E.
B.A.S.E. è un acronimo che descrive un insieme di proprietà desiderabili per i sistemi di database distribuiti, in particolare quelli NoSQL, che privilegiano la disponibilità e la tolleranza alle partizioni rispetto alla consistenza forte, in linea con il Teorema CAP. L’acronimo sta per:
* Basically Available (Disponibile di Base): Il sistema garantisce che ogni richiesta riceverà una risposta (non di errore) da almeno un nodo, anche in presenza di guasti parziali. La disponibilità è la priorità.
* Soft state (Stato Malleabile/Morbido): Lo stato del sistema può cambiare nel tempo anche senza input esterni, a causa della natura asincrona della propagazione dei dati. Non esiste una singola “fonte di verità” immediatamente consistente.
* Eventually consistent (Consistente alla Fine): Se non ci sono ulteriori aggiornamenti per un dato, tutte le repliche di quel dato finiranno per convergere allo stesso valore. La consistenza è garantita nel tempo, ma non istantaneamente.
A differenza dei sistemi transazionali ACID (Atomicity, Consistency, Isolation, Durability), che mirano a una consistenza immediata e forte, il modello B.A.S.E. accetta una temporanea inconsistenza dei dati per massimizzare la disponibilità e la scalabilità orizzontale. È particolarmente adatto per applicazioni su larga scala dove la latenza è critica e una leggera “stalezza” dei dati è tollerabile, come nei social network, nei sistemi di raccomandazione o nei cataloghi di e-commerce.
Big Data
Insiemi di dati di dimensioni, complessità e velocità tali da superare le capacità dei tradizionali strumenti e metodi di gestione e analisi dei database relazionali, sono caratterizzati dalle “3 V” principali:
– Volume (quantità massiva di dati)
– Velocità (rapidità di generazione, acquisizione ed elaborazione)
– Varietà (diversità di formati, da strutturati a semi-strutturati e non strutturati)
il Big Data richiede architetture e tecnologie innovative.
Nell’ambito dei database, ciò implica l’adozione di sistemi distribuiti, database NoSQL (come document-oriented, key-value, graph o column-family) e piattaforme di elaborazione parallela (es. Hadoop, Spark). L’obiettivo è non solo immagazzinare efficacemente questi dati eterogenei e dinamici, ma anche estrarne valore attraverso analisi avanzate, machine learning e intelligenza artificiale, per supportare decisioni strategiche e scoprire pattern nascosti. La gestione dei Big Data è cruciale per ottenere insight competitivi e guidare l’innovazione in numerosi settori.
CRUD
CRUD è un acronimo che sta per Create, Read, Update e Delete, e rappresenta le quattro operazioni fondamentali e basilari che possono essere eseguite su dati persistenti all’interno di un sistema di gestione di database (DBMS) o di un’applicazione che interagisce con un database.
Queste operazioni sono essenziali per la gestione del ciclo di vita delle informazioni:
1. Create (Creazione): L’operazione di aggiungere nuovi record o nuove righe a una tabella del database. Corrisponde tipicamente all’istruzione SQL `INSERT`.
2. Read (Lettura/Recupero): L’operazione di recuperare dati esistenti dal database. Permette di visualizzare o elaborare le informazioni memorizzate. Corrisponde tipicamente all’istruzione SQL `SELECT`.
3. Update (Aggiornamento): L’operazione di modificare i dati di record esistenti nel database. Permette di alterare i valori di uno o più campi di una riga. Corrisponde tipicamente all’istruzione SQL `UPDATE`.
4. Delete (Eliminazione): L’operazione di rimuovere record esistenti dal database. Corrisponde tipicamente all’istruzione SQL `DELETE`.
Il modello CRUD è un pilastro nello sviluppo di applicazioni software, in quanto quasi ogni applicazione che gestisce dati deve implementare queste funzionalità per interagire efficacemente con il proprio backend di archiviazione dati. È un concetto chiave per comprendere l’interazione tra applicazioni e database.
Data Model
Un Data Model (Modello di Dati) è una rappresentazione astratta e formale della struttura dei dati all’interno di un database. Definisce gli elementi di dati, le loro proprietà, le relazioni tra di essi e i vincoli che ne governano integrità, coerenza e semantica.
Il suo scopo è organizzare i dati in modo logico e coerente, fornendo la base progettuale per la creazione, l’implementazione e la gestione di un database. Specifica come i dati saranno memorizzati, acceduti e manipolati, riflettendo accuratamente la realtà che intendono rappresentare.
Esistono tre livelli principali:
* Concettuale: Descrive il “cosa” del dominio (es. Entità, Relazioni), indipendente dalla tecnologia (es. Modello Entità-Relazione).
* Logico: Descrive il “come” i dati sono organizzati per un tipo specifico di database (es. relazionale, a oggetti), indipendente dall’implementazione fisica (es. Schema relazionale).
* Fisico: Descrive l’implementazione concreta del database, inclusi dettagli del DBMS come tipi di dati, indici e allocazione dello storage.
Un Data Model ben progettato è cruciale per l’efficienza, la manutenibilità e l’affidabilità di un database, fungendo da strumento essenziale per la comunicazione tra tutti gli stakeholder.
Data Redundancy
La ridondanza dei dati in ambito database si riferisce alla duplicazione non necessaria delle stesse informazioni in più posizioni all’interno di un sistema di gestione dati (es. singola tabella, tra tabelle, o database distribuiti).
Principalmente, la ridondanza non controllata è un problema di progettazione, spesso causato dalla mancata normalizzazione. Le sue conseguenze negative includono: spreco di spazio di archiviazione, degrado delle prestazioni nelle operazioni di aggiornamento e aumento dei costi di manutenzione. Il rischio maggiore è l’inconsistenza dei dati: se un dato duplicato viene aggiornato in una posizione ma non in tutte, si creano informazioni contraddittorie, generando “anomalie di aggiornamento“, “inserimento” e “cancellazione“.
Esiste, tuttavia, una ridondanza controllata o intenzionale, implementata strategicamente per scopi specifici. Questa può migliorare le prestazioni di lettura (es. denormalizzazione), garantire alta disponibilità e tolleranza agli errori (es. replicazione per backup e disaster recovery), o facilitare l’integrazione tra sistemi eterogenei.
In sintesi, mentre la ridondanza non intenzionale è un difetto da mitigare con la normalizzazione per assicurare integrità ed efficienza, una ridondanza strategica può essere un compromesso accettabile per soddisfare specifici requisiti di performance, disponibilità o resilienza del sistema.
Data warehouse
Un Data warehouse è un sistema di archiviazione dati, tipicamente un database relazionale, progettato specificamente per supportare le attività di business intelligence, reporting e analisi. A differenza dei database transazionali (OLTP) ottimizzati per le operazioni quotidiane, il Data warehouse consolida e integra dati storici e attuali provenienti da molteplici fonti operative eterogenee.
Le sue caratteristiche distintive sono:
1. Orientato al soggetto: Organizza i dati attorno ad aree tematiche specifiche (es. vendite, clienti).
2. Integrato: Uniforma i dati provenienti da sistemi diversi, risolvendo incoerenze.
3. Variabile nel tempo: Mantiene una cronologia dei dati, permettendo l’analisi delle tendenze.
4. Non volatile: Una volta caricati, i dati non vengono modificati o cancellati, garantendo stabilità per l’analisi storica.
Il suo obiettivo è fornire una visione unificata, coerente e affidabile dei dati aziendali, facilitando l’esecuzione di query complesse e l’analisi multidimensionale (OLAP) per supportare il processo decisionale strategico e tattico.
Database Management System (DBMS)
Un DBMS (Sistema di Gestione di Basi di Dati) è un software progettato per definire, creare, interrogare, aggiornare e gestire basi di dati. Agisce come un’interfaccia tra gli utenti finali o le applicazioni e la base di dati stessa, facilitando l’organizzazione e l’accesso efficiente ai dati.
Le sue funzioni principali includono la modellazione dei dati (schema), l’inserimento e la modifica delle informazioni, l’esecuzione di query complesse per il recupero dei dati e la gestione della sicurezza e dell’integrità dei dati. Un DBMS garantisce che i dati siano coerenti, affidabili e protetti da accessi non autorizzati. Offre inoltre meccanismi per la gestione della concorrenza (permettere a più utenti di accedere contemporaneamente) e per il ripristino dei dati in caso di guasti.
Esistono diverse tipologie di DBMS, tra cui i più diffusi sono i DBMS relazionali (RDBMS), che organizzano i dati in tabelle, e i DBMS NoSQL, progettati per gestire grandi volumi di dati non strutturati o semi-strutturati con maggiore flessibilità. Indipendentemente dalla tipologia, il DBMS è un componente fondamentale di qualsiasi sistema informatico che necessiti di archiviare e manipolare grandi quantità di informazioni in modo strutturato e controllato.
DBaaS
DBaaS (Database as a Service) è un modello di servizio cloud che fornisce l’accesso a un database completamente gestito da un provider esterno. In questo paradigma, gli utenti possono utilizzare un database senza doversi preoccupare della gestione dell’infrastruttura sottostante, che include hardware, sistema operativo, installazione del software del database, patching, backup, manutenzione e scalabilità.
Il DBaaS delega al provider la responsabilità delle operazioni infrastrutturali e della manutenzione del database, permettendo agli sviluppatori e alle aziende di concentrarsi esclusivamente sullo sviluppo delle applicazioni e sulla gestione dei dati.
Le caratteristiche principali del DBaaS includono:
* Provisioning rapido: Creazione e configurazione di istanze database in pochi minuti.
* Scalabilità on-demand: Possibilità di aumentare o diminuire le risorse (CPU, RAM, storage) in base alle esigenze, spesso in modo automatico.
* Alta disponibilità e resilienza: Molti servizi DBaaS integrano repliche e failover automatici per garantire la continuità operativa.
* Backup e ripristino automatici: Gestione automatizzata dei backup e facilità di ripristino dei dati.
* Sicurezza: Il provider gestisce la sicurezza a livello infrastrutturale, con opzioni per la crittografia dei dati e il controllo degli accessi.
* Modello di costo pay-as-you-go: Si paga solo per le risorse effettivamente utilizzate, ottimizzando i costi operativi.
Il DBaaS supporta un’ampia gamma di tipi di database, inclusi relazionali (es. MySQL, PostgreSQL) e NoSQL (es. MongoDB, Redis), ed è disponibile su piattaforme cloud pubbliche, private o ibride, rappresentando una soluzione efficiente per ridurre la complessità operativa e accelerare lo sviluppo.
Document-oriented database
Un database orientato ai documenti (o “document-oriented database“) è una tipologia di database NoSQL che archivia i dati in collezioni di documenti semi-strutturati, anziché in tabelle rigide come nei database relazionali. Ogni documento è un’unità autonoma e autoconsistente, tipicamente in formati come JSON, BSON o XML, e può contenere dati complessi e nidificati.
La caratteristica distintiva è la flessibilità dello schema (schema-less o schema-on-read): i documenti all’interno della stessa collezione possono avere strutture diverse, permettendo un’evoluzione agile del modello dati senza la necessità di migrazioni complesse. Questo approccio facilita lo sviluppo di applicazioni, in quanto i documenti si mappano naturalmente agli oggetti nei linguaggi di programmazione.
I database documentali sono progettati per offrire elevata scalabilità orizzontale e prestazioni rapide per carichi di lavoro che richiedono l’accesso e la manipolazione di interi documenti. Sono particolarmente adatti per la gestione di contenuti web, cataloghi di prodotti, profili utente, dati IoT e applicazioni con requisiti di dati in continua evoluzione. Esempi noti includono MongoDB, Couchbase e RavenDB.
Embedded database
Un database embedded è un sistema di gestione di database (DBMS) che viene integrato direttamente all’interno di un’applicazione software, diventandone una componente intrinseca. A differenza dei database tradizionali client-server, non richiede un processo server separato né un’amministrazione indipendente, operando nello stesso spazio di memoria o processo dell’applicazione che lo utilizza.
Questa architettura offre vantaggi significativi in termini di semplicità di deployment, ridotto overhead e prestazioni elevate, grazie all’accesso diretto ai dati tramite API native. È particolarmente adatto per scenari dove la leggerezza, la portabilità, la minima configurazione e l’autonomia operativa sono essenziali.
Tipici ambiti di applicazione includono dispositivi mobili (smartphone, tablet), sistemi IoT (Internet of Things), applicazioni desktop stand-alone, sistemi embedded industriali e soluzioni edge computing. Esempi noti sono SQLite, H2 e Berkeley DB. La sua scelta è dettata dalla necessità di un’integrazione stretta e di un’esperienza utente senza la complessità di un’infrastruttura database esterna.
Graph Database
Un Graph Database è un tipo di database NoSQL che modella e archivia i dati utilizzando strutture grafiche. A differenza dei database relazionali o documentali, dove le relazioni sono spesso implicite o calcolate, in un Graph Database i dati sono rappresentati come “nodi” (entità) e “relazioni” (connessioni dirette tra nodi), entrambi i quali possono avere “proprietà” (attributi descrittivi).
Questa architettura rende le relazioni elementi di prima classe, ottimizzando l’archiviazione e l’interrogazione di dati altamente interconnessi. I Graph Database eccellono nell’esecuzione di query complesse che attraversano molteplici connessioni o cercano pattern specifici all’interno del grafo, offrendo prestazioni superiori rispetto ai database tradizionali in scenari con un elevato numero di “join” o attraversamenti di relazioni.
Sono particolarmente adatti per applicazioni che richiedono l’analisi di reti complesse, come social network, sistemi di raccomandazione, rilevamento di frodi, gestione di identità, grafi della conoscenza e analisi di dipendenze. Le interrogazioni vengono tipicamente eseguite tramite linguaggi specifici per i grafi, come Cypher o Gremlin, che consentono di esprimere pattern di connessione in modo intuitivo ed efficiente.
Hierarchical Model
Il Modello Gerarchico è un tipo di modello di dati per database che organizza le informazioni in una struttura ad albero. In questo modello, i dati sono rappresentati come una collezione di record, collegati tra loro da relazioni “genitore-figlio”.
Ogni record “figlio” può avere un solo “genitore”, mentre un record “genitore” può avere zero, uno o più “figli”. Questa relazione è intrinsecamente uno-a-molti. La struttura inizia con un singolo nodo “radice” dal quale si diramano tutti gli altri dati.
L’accesso ai dati avviene navigando lungo i percorsi definiti dalla gerarchia, partendo dalla radice e scendendo attraverso i rami fino al record desiderato.
Storicamente, è stato uno dei primi modelli di database ad essere implementato (es. IBM IMS). Sebbene semplice da comprendere per certe strutture dati, presenta limitazioni significative: la sua rigidità rende difficile rappresentare relazioni complesse (come le relazioni molti-a-molti) e richiede una predefinizione rigida della struttura, rendendo le modifiche complesse.
Maria DB
Sistema di gestione di database relazionali (RDBMS) open source e libero, nato come fork della comunità di MySQL. Sviluppato dagli stessi creatori originali di MySQL dopo la sua acquisizione da parte di Oracle, MariaDB si propone come un’alternativa performante, sicura e completamente compatibile con MySQL, pur introducendo significative migliorie e nuove funzionalità.
Basato sul linguaggio SQL, MariaDB è progettato per offrire elevata scalabilità, affidabilità e velocità, rendendolo una scelta popolare per un’ampia gamma di applicazioni, dalle piattaforme web dinamiche e i servizi cloud, al data warehousing e alle soluzioni enterprise. La sua architettura modulare supporta diversi motori di storage, come InnoDB, Aria e MyISAM, permettendo agli utenti di ottimizzare le prestazioni in base alle specifiche esigenze. Supportato da una fondazione e una vasta comunità di sviluppatori, MariaDB è costantemente aggiornato e mantenuto, garantendo un futuro stabile e innovativo nel panorama dei database.
MS Sql Server
RDBMS sviluppato da Microsoft, progettato per archiviare, recuperare e gestire dati in modo efficiente, rappresenta una soluzione fondamentale per applicazioni aziendali di ogni dimensione.
Si distingue per la sua robustezza, scalabilità e un’ampia gamma di funzionalità integrate. Tra queste, spiccano strumenti avanzati per la sicurezza dei dati, la replica, il recupero di emergenza e l’ottimizzazione delle prestazioni. Supporta il linguaggio SQL standard (con la sua estensione T-SQL, Transact-SQL) per l’interrogazione e la manipolazione dei dati.
Oltre alla gestione transazionale, SQL Server offre capacità significative per l’analisi dei dati (SSAS – SQL Server Analysis Services), l’integrazione di dati (SSIS – SQL Server Integration Services) e la reportistica (SSRS – SQL Server Reporting Services), rendendolo una piattaforma completa per la Business Intelligence.
È ampiamente utilizzato in ambienti enterprise per applicazioni web, sistemi ERP, CRM e data warehousing, con versioni disponibili sia on-premise che integrate con servizi cloud come Azure SQL Database, offrendo flessibilità e resilienza.
MySql
RDBMS open source, ampiamente riconosciuto e adottato a livello globale. Sviluppato originariamente da MySQL AB e successivamente acquisito da Sun Microsystems e infine da Oracle Corporation, è basato sul linguaggio SQL (Structured Query Language) per la definizione, manipolazione e interrogazione dei dati.
Caratterizzato da affidabilità, elevate prestazioni e scalabilità, MySQL è la scelta prediletta per un’ampia gamma di applicazioni, in particolare quelle web-based. Costituisce un componente fondamentale dello stack LAMP (Linux, Apache, MySQL, PHP/Python/Perl) e LEMP, alimentando numerosi siti web e servizi online di grande portata.
Offre diverse edizioni: la Community Edition, gratuita e supportata dalla comunità, e edizioni commerciali (Standard, Enterprise, Cluster CGE) che includono funzionalità avanzate, strumenti di gestione e supporto tecnico professionale. La sua architettura client-server permette a più utenti e applicazioni di accedere e gestire contemporaneamente i dati, rendendolo una soluzione robusta e versatile per la memorizzazione e il recupero efficiente delle informazioni.
Navigational DBMS
Un Navigational DBMS (Database Management System Navigazionale) è una tipologia di sistema di gestione di database caratterizzata da un approccio programmatico all’accesso e alla manipolazione dei dati. A differenza dei moderni DBMS relazionali, che utilizzano linguaggi dichiarativi come SQL per specificare “cosa” recuperare, un sistema navigazionale richiede al programmatore di definire esplicitamente “come” navigare attraverso la struttura dei dati.
Questo approccio “record-at-a-time” implica che l’applicazione deve seguire puntatori, link o percorsi predefiniti per spostarsi da un record all’altro, esplorando le relazioni tra le entità. I modelli di database gerarchici (come IBM IMS) e di rete (come CODASYL IDMS) sono gli esempi più noti di DBMS navigazionali, prevalenti prima dell’avvento dei sistemi relazionali negli anni ’70.
La stretta dipendenza tra la logica applicativa e la struttura fisica dei dati rende questi sistemi meno flessibili, più complessi da sviluppare e mantenere, e con una minore indipendenza dei dati rispetto ai loro successori relazionali. Nonostante siano stati largamente superati, i Navigational DBMS hanno rappresentato un passo fondamentale nell’evoluzione della gestione dei dati.
NewSql
NewSQL è una categoria di sistemi di gestione di database relazionali (RDBMS) progettata per combinare la scalabilità orizzontale e le prestazioni elevate dei database NoSQL con le garanzie transazionali (ACID) e il modello relazionale dei database SQL tradizionali.
Emergendo come risposta alle limitazioni di scalabilità dei RDBMS monolitici e alle compromissioni di consistenza dei sistemi NoSQL per carichi di lavoro che richiedono integrità dei dati, NewSQL offre una soluzione ibrida.
Le sue caratteristiche distintive includono:
* Interfaccia SQL: Supporta il linguaggio SQL standard o una sua variante, facilitando la migrazione e l’integrazione con strumenti esistenti.
* Conformità ACID: Garantisce l’atomicità, la consistenza, l’isolamento e la durabilità delle transazioni, anche in ambienti distribuiti.
* Scalabilità Orizzontale: Architettura distribuita che permette di aggiungere nodi per aumentare capacità e throughput, distribuendo dati e carico di lavoro su un cluster di server.
* Alte Prestazioni: Ottimizzato per carichi di lavoro transazionali intensivi, spesso sfruttando l’elaborazione in-memory e la gestione efficiente delle transazioni distribuite.
NewSQL raggiunge questi obiettivi attraverso tecniche avanzate come lo sharding automatico, la replica sincrona e protocolli di commit distribuiti. È particolarmente adatto per applicazioni che richiedono alta velocità, bassa latenza e forte consistenza su larga scala, come servizi finanziari, e-commerce e piattaforme di gaming online.
NoSql
NoSQL (acronimo di “Not Only SQL“) è una categoria di sistemi di gestione di database che si differenziano dai tradizionali database relazionali (SQL) per il loro modello di dati non tabellare. Nati per rispondere alle esigenze di scalabilità orizzontale, flessibilità dello schema e gestione efficiente di grandi volumi di dati non strutturati o semi-strutturati (Big Data), i database NoSQL offrono approcci diversi alla memorizzazione e al recupero delle informazioni.
A differenza dei database relazionali che impongono uno schema fisso e rigido, i NoSQL permettono schemi dinamici o assenti, facilitando lo sviluppo agile e la gestione di dati eterogenei. Sono spesso ottimizzati per prestazioni elevate e alta disponibilità, sacrificando talvolta la piena conformità ACID (Atomicity, Consistency, Isolation, Durability) in favore del modello BASE (Basically Available, Soft state, Eventually consistent) per garantire maggiore scalabilità.
Esistono diverse tipologie di database NoSQL, ognuna con caratteristiche e casi d’uso specifici:
* Key-Value: memorizzano dati come semplici coppie chiave-valore (es. Redis, DynamoDB).
* Document-oriented: organizzano i dati in documenti semi-strutturati, spesso JSON o BSON (es. MongoDB, Couchbase).
* Column-family: strutturano i dati in famiglie di colonne, ottimizzati per query su grandi dataset (es. Cassandra, HBase).
* Graph: modellano le relazioni tra entità come nodi e archi, ideali per dati connessi (es. Neo4j, ArangoDB).
La scelta tra SQL e NoSQL dipende dalle specifiche esigenze dell’applicazione, dalla natura dei dati e dai requisiti di scalabilità e coerenza.
O.L.A.P.
O.L.A.P. (Online Analytical Processing) è una categoria di tecnologie software e metodologie di database progettate per l’analisi rapida e interattiva di grandi volumi di dati aziendali. A differenza dei sistemi OLTP (Online Transaction Processing), ottimizzati per l’elaborazione di transazioni quotidiane, OLAP è specificamente concepito per supportare la business intelligence e il processo decisionale, consentendo agli utenti di esplorare dati complessi da molteplici prospettive.
La caratteristica distintiva di OLAP è l’organizzazione dei dati in modelli multidimensionali, spesso rappresentati come “cubi OLAP“. Questi cubi pre-aggregano e indicizzano i dati lungo diverse dimensioni (es. tempo, prodotto, regione, cliente), facilitando l’esecuzione di interrogazioni analitiche complesse con tempi di risposta estremamente rapidi.
Le operazioni OLAP tipiche includono:
* Drill-down: Scendere a un livello di dettaglio maggiore.
* Roll-up: Aggregare i dati a un livello superiore.
* Slice and Dice: Selezionare sottoinsiemi specifici di dati.
* Pivot (o rotazione): Cambiare la prospettiva di visualizzazione delle dimensioni.
L’obiettivo primario di OLAP è fornire agli analisti e ai manager strumenti potenti per identificare tendenze, anomalie e opportunità, trasformando i dati grezzi in informazioni strategiche.
O.L.T.P.
O.L.T.P. (Online Transaction Processing) è una categoria di sistemi di database e applicazioni progettata per gestire un elevato volume di transazioni brevi, atomiche e simultanee in tempo reale. Il suo scopo primario è supportare le operazioni quotidiane di un’organizzazione, garantendo l’elaborazione rapida e affidabile di ogni singola interazione con i dati.
I sistemi OLTP sono ottimizzati per:
* Alta disponibilità e throughput: Gestire migliaia o milioni di transazioni al secondo.
* Bassa latenza: Rispondere rapidamente a ogni richiesta.
* Integrità dei dati: Mantenere la coerenza e l’accuratezza dei dati attraverso le proprietà ACID (Atomicità, Consistenza, Isolamento, Durabilità).
* Operazioni di lettura/scrittura/aggiornamento/cancellazione (CRUD): Focalizzarsi su piccole modifiche a record specifici.
Tipici scenari d’uso includono sistemi bancari (prelievi, bonifici), piattaforme di e-commerce (ordini, pagamenti), sistemi di prenotazione (voli, hotel) e punti vendita (registrazione vendite). I database OLTP sono il cuore dei sistemi operativi, fornendo i dati aggiornati per le attività transazionali immediate, distinguendosi dai sistemi OLAP (Online Analytical Processing) che sono ottimizzati per l’analisi complessa di grandi volumi di dati storici.
PostgreSQL
PostgreSQL è un potente sistema di gestione di database relazionale (RDBMS) e object-relazionale (ORDBMS) open-source, noto per la sua robustezza, affidabilità e conformità agli standard SQL. Sviluppato da una vasta comunità globale, è rilasciato sotto licenza libera, garantendo flessibilità e trasparenza.
Si distingue per la sua architettura avanzata che supporta transazioni ACID (Atomicità, Consistenza, Isolamento, Durabilità) e il controllo della concorrenza multi-versione (MVCC), assicurando l’integrità dei dati e alte prestazioni anche sotto carichi intensi. Una delle sue caratteristiche più apprezzate è l’estrema estensibilità: permette agli utenti di definire nuovi tipi di dati, funzioni, operatori e linguaggi procedurali, oltre a integrare moduli esterni come PostGIS per dati geospaziali.
Ampiamente utilizzato in una varietà di contesti, dalle applicazioni web e mobili ai sistemi enterprise, data warehousing e applicazioni scientifiche, PostgreSQL è considerato una scelta primaria per progetti che richiedono scalabilità, sicurezza e funzionalità avanzate.
Probabilistic databases
I database probabilistici (Probabilistic Databases) sono una categoria di sistemi di gestione di database (DBMS) progettati per memorizzare, gestire e interrogare dati che sono intrinsecamente incerti o imprecisi. A differenza dei database relazionali tradizionali, che assumono che tutti i valori siano esatti e deterministici, i database probabilistici associano a ogni dato, attributo o relazione una probabilità, un intervallo di confidenza o una distribuzione di probabilità.
Questo permette di rappresentare non un singolo stato del mondo, ma un insieme di “mondi possibili” o istanze del database, ognuno con una certa probabilità di essere quello reale. Le interrogazioni su tali database non restituiscono un risultato deterministico, ma piuttosto un insieme di risposte con associate probabilità di correttezza, o distribuzioni di probabilità sulle risposte stesse.
L’obiettivo principale è fornire un framework robusto per la gestione dell’incertezza a livello di dato, permettendo di quantificare l’affidabilità delle informazioni e delle conclusioni derivate. Trovano applicazione in scenari dove i dati sono rumorosi, incompleti o derivano da fonti eterogenee e imprecise, come l’integrazione di dati, l’estrazione di informazioni, i dati da sensori, la pulizia dei dati, l’apprendimento automatico e l’analisi di big data. Rappresentano un’evoluzione fondamentale per affrontare la complessità e l’imprecisione inerente a molti dataset del mondo reale.
Relational DBMS
Un Relational DBMS (RDBMS) o Sistema di Gestione di Database Relazionale, è un tipo di sistema di gestione di database (DBMS) che organizza i dati secondo il modello relazionale. Questo modello struttura i dati in tabelle (o relazioni), ciascuna composta da righe (tuple) e colonne (attributi). Ogni tabella rappresenta un’entità e le sue proprietà, mentre le righe contengono istanze specifiche di tale entità.
Le relazioni tra le diverse tabelle sono stabilite e mantenute tramite l’uso di chiavi primarie e chiavi esterne, garantendo l’integrità referenziale e la coerenza dei dati. L’interazione con un RDBMS avviene principalmente attraverso il linguaggio SQL (Structured Query Language), standard de facto per la definizione, manipolazione e interrogazione dei dati.
Gli RDBMS sono progettati per assicurare l’integrità, la sicurezza e la disponibilità dei dati, aderendo tipicamente alle proprietà ACID (Atomicità, Consistenza, Isolamento, Durabilità) per le transazioni. Questa robustezza li rende la scelta predominante per applicazioni che richiedono elevata affidabilità e precisione, come sistemi transazionali, gestionali e di business intelligence. Esempi noti includono MySQL, PostgreSQL, Oracle Database e Microsoft SQL Server.
Relational Model
Il Modello Relazionale è un paradigma fondamentale per l’organizzazione e la gestione dei dati in un database, proposto da E.F. Codd nel 1970 e basato sulla teoria matematica degli insiemi e sulla logica del primo ordine.
Al suo nucleo, rappresenta i dati come collezioni di “relazioni”, concettualmente tabelle bidimensionali. Ogni relazione (tabella) è composta da “attributi” (colonne), ciascuno con un nome univoco e un dominio di valori, e da “tuple” (righe), dove ogni tupla è un’istanza di un’entità con valori per gli attributi.
Le relazioni tra le tabelle sono stabilite tramite valori comuni negli attributi, tipicamente usando chiavi primarie e chiavi esterne. Questi meccanismi sono cruciali per l’applicazione di vincoli di integrità referenziale, garantendo coerenza e validità dei dati.
Offre indipendenza logica e fisica dei dati, consentendo un’interazione astratta. La manipolazione e l’interrogazione avvengono tramite linguaggi come SQL (standard de facto), basati sull’algebra o sul calcolo relazionale.
Grazie a robustezza, flessibilità e solido fondamento teorico, è il paradigma dominante per i database transazionali e analitici, alla base della maggior parte dei sistemi RDBMS (Relational Database Management System) moderni.
Snowflake Schema
Lo Snowflake Schema è una variante dello Star Schema, utilizzato nell’ambito dei data warehouse e dell’analisi OLAP, che si distingue per la normalizzazione delle tabelle di dimensione. Mentre nello Star Schema le tabelle di dimensione sono denormalizzate e direttamente collegate alla tabella dei fatti, nello Snowflake Schema le dimensioni vengono ulteriormente scomposte in tabelle correlate, formando una struttura gerarchica e ramificata che ricorda un fiocco di neve.
Questa normalizzazione delle dimensioni riduce la ridondanza dei dati all’interno delle tabelle dimensionali, migliorando l’integrità dei dati e potenzialmente ottimizzando lo spazio di archiviazione per dimensioni molto grandi o complesse. Ad esempio, una dimensione “Tempo” potrebbe essere scomposta in tabelle separate per “Anno”, “Mese” e “Giorno”.
Tuttavia, il costo di questa maggiore normalizzazione è un aumento della complessità delle query, poiché sono necessarie più join tra le tabelle dimensionali per recuperare le informazioni complete. Ciò può portare a prestazioni di query leggermente inferiori rispetto allo Star Schema, sebbene i moderni ottimizzatori di database spesso mitighino questo impatto. È preferito quando le dimensioni sono particolarmente grandi, complesse e stabili, e la riduzione della ridondanza e il mantenimento dell’integrità dimensionale sono prioritari.
Spatial databases
I database spaziali sono sistemi di gestione di database (DBMS) progettati per archiviare, indicizzare, interrogare e analizzare dati che rappresentano oggetti e fenomeni nel mondo reale con una componente geografica o spaziale. A differenza dei database tradizionali, che gestiscono principalmente dati alfanumerici, i database spaziali incorporano tipi di dati specifici per la geometria (punti, linee, poligoni) e talvolta per i raster (immagini satellitari, DEM).
Questi database estendono le capacità SQL standard con funzioni e operatori spaziali che permettono di eseguire query complesse basate su relazioni spaziali. Esempi includono la ricerca di oggetti entro una certa distanza (vicinanza), l’identificazione di intersezioni, la verifica di contenimento (un punto all’interno di un’area) o la determinazione di adiacenza. Per ottimizzare le prestazioni di queste operazioni, utilizzano indici spaziali specializzati (come R-tree).
I database spaziali sono fondamentali per i Sistemi Informativi Geografici (GIS), le applicazioni di mappatura, i servizi basati sulla localizzazione (LBS), la pianificazione urbana, il monitoraggio ambientale e la logistica. La loro capacità di gestire efficientemente grandi volumi di informazioni geografiche li rende strumenti indispensabili per l’analisi e la visualizzazione del mondo fisico.
Sql Server
Un Relational Database Management System (RDBMS) di proprietà di Microsoft, ampiamente utilizzato in ambito corporate per la creazione e la gestione di database relazionali di grandi dimensioni. Utilizza il linguaggio Transact-SQL (T-SQL), che è un’estensione del linguaggio standard SQL, per interrogare e manipolare i dati. Si distingue per le sue funzionalità avanzate come l’elaborazione in memoria e l’alta disponibilità (Always On), ed è fondamentale per applicazioni aziendali critiche come ERP e CRM.
Sql Server Management Studio
SQL Server Management Studio (SSMS) è un ambiente di sviluppo integrato (IDE) e uno strumento software fornito da Microsoft per la gestione, configurazione, amministrazione e sviluppo di tutti i componenti di Microsoft SQL Server. Permette agli amministratori di database (DBA) e agli sviluppatori di interagire con le istanze di SQL Server, Azure SQL Database e Azure Synapse Analytics.
SSMS offre un’interfaccia grafica completa per eseguire query, scrivere script T-SQL, progettare database, gestire oggetti di database (tabelle, viste, stored procedure), monitorare le prestazioni, configurare la sicurezza e risolvere problemi.
Include strumenti come l’Object Explorer per navigare tra gli oggetti, il Query Editor per scrivere ed eseguire query, e il Data Tools per la progettazione visuale. È essenziale per l’ottimizzazione delle prestazioni, la manutenzione e lo sviluppo di soluzioni basate su SQL Server, semplificando le operazioni complesse attraverso un’unica interfaccia unificata.
Star Schema
Lo Star Schema è un modello di database dimensionale, ampiamente utilizzato nei data warehouse e per l’analisi OLAP. La sua struttura è caratterizzata da una tabella centrale, denominata “fact table” (tabella dei fatti), che contiene le misure numeriche (es. vendite, quantità, ricavi) e le chiavi esterne che collegano questa tabella a una serie di tabelle circostanti, chiamate “dimension tables” (tabelle delle dimensioni).
Le tabelle delle dimensioni descrivono gli attributi contestuali dei fatti (es. tempo, prodotto, cliente, luogo, data). Ogni dimensione è tipicamente una tabella denormalizzata, contenente tutti gli attributi descrittivi relativi a quella specifica dimensione.
La configurazione a stella, con la fact table al centro e le dimension tables che la circondano direttamente, facilita la comprensione dei dati e ottimizza significativamente le prestazioni delle query analitiche complesse. Le join tra la fact table e le dimension tables sono semplici e dirette (tipicamente uno-a-molti), migliorando l’efficienza rispetto a modelli più normalizzati. Questo design è ideale per aggregazioni, reporting e analisi multidimensionali, rendendolo uno standard nell’ambito della Business Intelligence.
Stored Procedure
Una Stored Procedure (o Procedura Memorizzata) è un insieme di istruzioni SQL e logica procedurale (come cicli e condizioni) precompilato e memorizzato direttamente nel sistema di gestione del database (DBMS). Funziona come una singola unità eseguibile, richiamabile su richiesta.
I suoi principali vantaggi includono:
* Riutilizzabilità: Permette di incapsulare logiche complesse, richiamabili da diverse applicazioni o utenti, riducendo la duplicazione del codice.
* Performance: Essendo precompilata e risiedendo sul server, riduce il traffico di rete (inviando solo il nome della procedura e i parametri) e ottimizza l’esecuzione.
* Sicurezza: Consente di concedere permessi di esecuzione su specifiche procedure senza esporre direttamente le tabelle sottostanti, migliorando il controllo degli accessi.
* Integrità dei dati: Centralizza la logica di business, garantendo che le operazioni complesse siano eseguite in modo consistente e conforme alle regole aziendali.
* Manutenzione: Semplifica la gestione e l’aggiornamento della logica applicativa, che può essere modificata una sola volta nel database anziché in ogni applicazione client.
Le Stored Procedure possono accettare parametri di input, restituire valori di output o set di risultati, e sono fondamentali per lo sviluppo di applicazioni database efficienti e robuste.
Tabelle
Una Tabella è la struttura fondamentale e più comune per l’organizzazione e la memorizzazione dei dati all’interno di un database relazionale. Concettualmente simile a un foglio di calcolo, una tabella è composta da una collezione di righe (o record) e colonne (o campi).
Ogni riga rappresenta una singola entità o un’istanza specifica di un oggetto o evento (ad esempio, un cliente, un prodotto, una transazione), contenendo un insieme completo di informazioni correlate. Ogni colonna, invece, definisce un attributo specifico o una caratteristica per tutte le entità nella tabella (ad esempio, nome, cognome, prezzo, data). Tutte le celle in una data colonna contengono dati dello stesso tipo (numerico, testuale, data, ecc.).
Le tabelle sono progettate per garantire l’integrità dei dati e facilitare l’accesso, la manipolazione e la gestione delle informazioni. Spesso includono una “chiave primaria” (primary key), un campo o un insieme di campi che identifica univocamente ogni riga, e possono contenere “chiavi esterne” (foreign keys) per stabilire relazioni con altre tabelle all’interno dello stesso database, permettendo la costruzione di modelli di dati complessi e interconnessi. Sono l’elemento centrale per l’interrogazione (querying) e la manipolazione dei dati tramite linguaggi come SQL.
Trigger
Un Trigger è un oggetto di schema che rappresenta una procedura memorizzata speciale, associata a una specifica tabella o vista. La sua peculiarità è l’esecuzione automatica e implicita in risposta a determinati eventi di manipolazione dei dati (DML): `INSERT`, `UPDATE` o `DELETE`.
I trigger sono progettati per implementare logiche di business complesse che non possono essere gestite da vincoli standard (come `PRIMARY KEY`, `FOREIGN KEY`, `CHECK`). Le loro funzioni includono:
* Mantenere l’integrità referenziale avanzata.
* Auditare le modifiche ai dati, registrando chi, quando e cosa è stato modificato.
* Sincronizzare dati tra tabelle diverse.
* Applicare regole di validazione dei dati prima o dopo una modifica.
Un trigger può essere definito per attivarsi `BEFORE` (prima – ‘INSTEAD OF‘ nel dialetto Transact SQL di Microsott) o `AFTER` (dopo) l’evento DML, e può operare `FOR EACH ROW` (per ogni riga influenzata dall’operazione) o `FOR EACH STATEMENT` (una sola volta per l’intera istruzione DML). La loro gestione richiede attenzione per evitare effetti a cascata indesiderati o problemi di performance.
Views
Una View (o Vista) è una tabella virtuale, il cui contenuto non è fisicamente memorizzato ma è derivato dinamicamente da una o più tabelle base (o altre view) attraverso una query SQL predefinita.
Una view agisce come una “finestra” personalizzata sui dati sottostanti. Viene creata e definita tramite un’istruzione `SELECT` che specifica quali colonne, quali righe e quali join tra tabelle devono essere inclusi. Quando una view viene interrogata, il database esegue la query sottostante e presenta il risultato come se fosse una tabella reale.
Gli scopi principali delle view includono:
1. Semplificazione: Permettono di astrarre la complessità di query complesse, presentandole agli utenti come semplici tabelle.
2. Sicurezza: Consentono di limitare l’accesso ai dati, mostrando solo un sottoinsieme di colonne o righe a specifici utenti, senza dover concedere permessi diretti sulle tabelle base.
3. Personalizzazione: Offrono la possibilità di presentare i dati in un formato più significativo o aggregato per diverse applicazioni o gruppi di utenti.
4. Coerenza: Garantiscono che tutti gli utenti accedano ai dati in modo standardizzato e predefinito.
Le view non occupano spazio di archiviazione per i dati stessi, ma solo per la loro definizione. Possono essere considerate un potente strumento per migliorare la gestione, la sicurezza e l’usabilità dei dati in un database.
tuple
Nel contesto dei database relazionali, una tuple (o tupla) rappresenta una singola riga o record all’interno di una tabella. È un insieme ordinato di valori, dove ogni valore corrisponde a un attributo (o colonna) specifico della tabella.
Ogni tuple incapsula un’istanza completa di un’entità descritta dalla tabella. Ad esempio, in una tabella “Clienti“, una tuple potrebbe rappresentare un singolo cliente con i suoi attributi come ID_Cliente, Nome, Cognome, Indirizzo, ecc.
Le tuple sono gli elementi fondamentali che contengono i dati effettivi memorizzati nel database. Sebbene l’ordine degli attributi all’interno di una tuple sia definito dallo schema della tabella, l’ordine delle tuple all’interno di una tabella non è intrinsecamente garantito e può variare a seconda del modo in cui i dati vengono recuperati o memorizzati.
Una tabella è essenzialmente una collezione di tuple, tutte conformi allo stesso schema (stessi attributi e tipi di dati). La combinazione dei valori degli attributi di una tuple è spesso unica, specialmente quando include una chiave primaria, garantendo l’identificazione univoca di ogni record.