In un mondo in cui i dati sono sempre pi\u00f9 al centro delle decisioni aziendali<\/strong>, \u00e8 fondamentale comprendere le differenze tra i database relazionali e non-relazionali. <\/p>\n\n\n\n In questo articolo, rispondiamo a tutte queste domande ed esploriamo i concetti chiave che definiscono questi due tipi di database, spiegando cosa sono e come si differenziano i Database Relazionali vs Non-Relazionali: SQL vs NoSQL<\/strong>, quali i vantaggi e gli svantaggi.<\/p>\n\n\n\n Una breve premessa sui dati nell\u2019era digitale, che possono essere classificati in dati operativi e analitici<\/strong>.<\/p>\n\n\n\n I dati operativi<\/strong> sono utilizzati per le transazioni quotidiane e devono essere sempre aggiornati, ad esempio l\u2019inventario dei prodotti o il saldo bancario. Questi dati vengono acquisiti in tempo reale con sistemi di elaborazione delle transazioni online (OLTP).<\/p>\n\n\n\n I dati analitici<\/strong> sono quelli che le aziende usano per ottenere informazioni sul comportamento dei clienti, sulle prestazioni dei prodotti e sulle previsioni. Comprendono i dati raccolti in un periodo di tempo e sono solitamente archiviati in sistemi OLAP (Online Analytical Processing<\/em>), warehouse o data lake.<\/p>\n\n\n\n I database sono il modo pi\u00f9 efficiente per archiviare e recuperare <\/strong>in modo permanente e digitale i dati operativi e analitici.<\/p>\n\n\n\n In base ai requisiti del progetto, le aziende devono scegliere un database<\/strong> in grado di raccogliere e memorizzare tutti i tipi di dati; accedervi rapidamente e ottenerne rapidi insight per prendere decisioni strategiche.<\/p>\n\n\n\n La maggior parte delle aziende ha bisogno sia dei sistemi OLTP (operativi) sia di quelli analitici (OLAP), per archiviare i propri dati, e pu\u00f2 quindi utilizzare un database relazionale, un database non relazionale o entrambi.<\/p>\n\n\n\n Vediamoli nel dettaglio.<\/p>\n\n\n\n Un database relazionale, o sistema di gestione di database relazionali (RDMS), \u00e8 basato sul modello relazionale, in cui i dati sono organizzati in tabelle con righe e colonne<\/strong>.\u00a0<\/p>\n\n\n\n Le tabelle sono collegate tra loro tramite relazioni definite tra le chiavi primarie e le chiavi esterne<\/strong>. Il database relazionale utilizza il linguaggio SQL (Structured Query Language<\/em>) per interrogare e manipolare i dati.<\/p>\n\n\n\n Ancora oggi i DB relazionali vengono usati per assolvere a qualsiasi esigenza informativa, in cui i dati sono correlati tra loro e devono essere gestiti in modo sicuro e coerente, per tenere traccia degli inventari, elaborare transazioni di e-commerce, gestire enormi quantit\u00e0 di informazioni mission-critical sui clienti, ecc. <\/p>\n\n\n\n Nel database relazionale, tutti i dati sono organizzati e memorizzati in strutture fisse, dette tabelle. Infatti, i database relazionali si basano sul modello relazionale, ovvero su relazioni univoche fra i dati rappresentati nelle tabelle<\/strong> che contengono dati specifici e di tipo diverso.<\/p>\n\n\n\n La tabella \u00e8 formata da righe e colonne<\/strong>: ogni riga \u00e8 un record con un ID univoco chiamato \u2018chiave\u2019 e contiene il dato effettivo; mentre le colonne rappresentano gli attributi dei dati. <\/p>\n\n\n\n La colonna<\/strong> deve contenere valori unici (\u2018chiave primaria\u2019)<\/strong> e pu\u00f2 essere utilizzata in altre tabelle, se si vogliono creare relazioni tra una o pi\u00f9 tabelle. Quando la chiave primaria di una tabella viene utilizzata in un\u2019altra tabella, la colonna della seconda tabella viene definita \u2018chiave esterna\u2019<\/strong>.<\/p>\n\n\n\n Facciamo un esempio di un DB relazionale.<\/strong><\/p>\n\n\n\n Poniamo il caso di un negozio<\/strong> che voglia memorizzare i nomi e gli indirizzi dei clienti in una tabella e i dettagli dei loro ordini in un\u2019altra.\u00a0<\/p>\n\n\n\n La prima tabella<\/strong> contiene i dati sul cliente<\/strong>, quindi ogni record include informazioni di contatto come il nome, l\u2019indirizzo, i recapiti per la spedizione e la fatturazione, il numero di telefono e altre informazioni. Ogni informazione diventa un attributo contenuto in una colonna, e il database assegna un ID univoco (una chiave) a ogni riga. <\/p>\n\n\n\n Nella seconda tabella<\/strong> inseriamo gli ordini dei clienti<\/strong>, ogni record include l\u2019ID del cliente che ha fatto l\u2019ordine, il prodotto, la quantit\u00e0, la taglia e il colore selezionati ecc., ma non il nome o le informazioni di contatto del cliente.<\/p>\n\n\n\n In sostanza, queste due tabelle condividono solo la colonna ID (la chiave)<\/strong>, <\/strong>grazie alla quale il database relazionale pu\u00f2 assolvere alla sua funzione, quindi creare una relazione tra le due tabelle per estrapolare le informazioni corrette sull\u2019ordine del prodotto, e utilizzare l\u2019ID del cliente da quella tabella per cercare le informazioni di fatturazione e spedizione nella tabella che contiene i dati del cliente. <\/p>\n\n\n\n Per identificare le informazioni appartenenti a uno stesso oggetto si utilizzano operazioni logiche come il JOIN<\/strong>, che basa i propri calcoli sulle chiavi esterne (o foreign keys), per creare il collegamento tra le due tabelle. <\/p>\n\n\n\n La sua \u201crigidit\u00e0\u201d \u00e8 la faccia della medaglia buona, quella che presenta i suoi molteplici vantaggi in fatto di coerenza, sicurezza e integrit\u00e0 dei dati<\/strong>. <\/p>\n\n\n\n Per garantire che i dati siano sempre accurati e accessibili, i database relazionali seguono determinate regole di integrit\u00e0<\/strong>. Ad esempio, una regola di integrit\u00e0 pu\u00f2 specificare che non siano ammesse righe duplicate in una tabella, per eliminare le probabilit\u00e0 di informazioni errate nel DB. <\/p>\n\n\n\n Questo DB \u00e8 la scelta consigliabile se si sta lavorando a un progetto in cui i dati sono prevedibili, in termini di struttura, dimensioni e frequenza di accesso<\/strong>. Non \u00e8 un caso che i database relazionali si trovino spesso nelle applicazioni finanziarie. <\/p>\n\n\n\n Il modello relazionale \u00e8 il migliore anche per mantenere la coerenza dei dati<\/strong> tra applicazioni e le copie del database (istanze). Esempio ne sia quando facciamo un\u2019operazione offline e vogliamo per\u00f2 vederne gli effetti immediati nell\u2019applicazione mobile. Le prestazioni dei database relazionali, in merito alla coerenza dei dati, sono tra le migliori permettendo a pi\u00f9 istanze di un database di mantenere sempre gli stessi dati (coerenza).<\/p>\n\n\n\n Vediamo tutti i vantaggi del DB relazionale.<\/strong><\/p>\n\n\n\n L\u2019integrit\u00e0 referenziale \u00e8 una delle caratteristiche chiave dei database relazionali, garantita dalle relazioni tra le tabelle, che assicurano che i dati siano coerenti<\/strong> e che non si verifichino anomalie come la duplicazione o la perdita di dati.<\/p>\n\n\n\n ACID \u00e8 acronimo di atomicit\u00e0, consistenza, isolamento e durata, uno standard che garantisce l\u2019affidabilit\u00e0 delle transazioni dei database<\/strong>. Il presupposto \u00e8 che se una modifica fallisce, l\u2019intera transazione fallisce, ma il database rimane nel medesimo stato in cui si trovava prima del tentativo di transazione.<\/p>\n\n\n\n L\u2019accuratezza dei dati poggia sulla esclusivit\u00e0 delle informazioni<\/strong>, di cui si pu\u00f2 evitare la duplicazione grazie alle chiavi primarie ed esterne.\u00a0<\/p>\n\n\n\n Il processo di normalizzazione consiste nel garantire che i dati siano organizzati in modo da ridurre o eliminare le anomalie<\/strong>.<\/p>\n\n\n\n Anche i non addetti ai lavori<\/strong> possono generare report e query a partire dai dati, grazie alla longevit\u00e0 degli RDMS, o database SQL, e all\u2019esistenza dei tanti strumenti e risorse per interagire con i database relazionali.\u00a0<\/p>\n\n\n\n D\u2019altra parte, per\u00f2, non possiamo ignorare i limiti di questo tipo di struttura<\/strong> che comporta la frammentazione delle informazioni tra differenti tabelle, anche nel caso in cui i dati descrivono lo stesso oggetto. <\/p>\n\n\n\n Per questo stesso motivo si sconsiglia l\u2019uso di tabelle SQL troppo grandi<\/strong>, perch\u00e9 difficile da gestire anche con sistemi computazionali molto potenti.<\/p>\n\n\n\n Questa peculiarit\u00e0 della frammentazione<\/strong> richiede ai sistemi SQL di svolgere continue interrogazioni, in quanto i dati devono essere raccolti e combinati fra loro da differenti tabelle, anche per operazioni semplici (inserimento, cancellazione e aggiornamento).<\/p>\n\n\n\n Questa forte frammentazione prescrive anche un rigido controllo<\/strong> sulle relazioni e sulla validit\u00e0 dei dati inseriti nelle differenti tabelle, in modo da preservare l\u2019integrit\u00e0 del database, tuttavia a scapito della flessibilit\u00e0<\/strong>.\u00a0<\/p>\n\n\n\n \u00c8 anche per questo motivo che i database relazionali si basano su schemi tabellari \u201centit\u00e0-relazione\u201d predefiniti, che difficilmente possono essere riadattati pena il rischio di una corruzione dei dati.<\/p>\n\n\n\n Gli RDMS nascono per essere eseguiti su un\u2019unica macchina. Se le dimensioni dei dati non fossero supportati, ne andrebbe\u00a0<\/p>\n\n\n\n migliorato l\u2019hardware (scalabilit\u00e0 verticale). Questo upgrade pu\u00f2 essere molto costoso<\/strong> e avere un limite massimo, oltre il quale l\u2019hardware non pu\u00f2 andare. <\/p>\n\n\n\n Nei database relazionali, lo schema \u00e8 rigido<\/strong>: si definiscono le colonne e i tipi di dati per le colonne, il formato e\/o la lunghezza.\u00a0<\/p>\n\n\n\n Se da un lato questa caratteristica permette una maggiore facilit\u00e0 nell’interpretazione dei dati e nell\u2019identificare le relazioni tra le tabelle, dall\u2019altro \u00e8 pure vero che significa che in un simile contesto operativo diventa complicato apportare modifiche alla struttura dei dati<\/strong>.<\/p>\n\n\n\n Ci\u00f2 significa pure che quando si lavora con un DB relazionale bisogna avere le idee molto chiare<\/strong> fin dall\u2019inizio su come saranno i dati. Se si volessero fare modifiche in seguito, bisogna modificare tutti i dati.<\/p>\n\n\n\n \u00c8 chiaro che maggiore \u00e8 la complessit\u00e0 delle tabelle, in relazione al numero e alla quantit\u00e0 di dati contenuti in esse, maggiore \u00e8 il tempo necessario per eseguire le query.<\/p>\n\n\n\n Cos’\u00e8 un database non relazionale o NoSQL?<\/p>\n\n\n\n I database non relazionali sono completamente differenti da quelli SQL, e oggi sono diventati una necessit\u00e0 perch\u00e9 pi\u00f9 flessibili e scalabili<\/strong>. Non \u00e8 un caso, infatti, che siano stati progettati pensando al cloud.<\/p>\n\n\n\n Un database non relazionale pu\u00f2 essere enorme. E poich\u00e9 in alcuni casi possono crescere in modo esponenziale, hanno bisogno di un ambiente di hosting espandibile<\/strong>, <\/strong>che possa crescere con loro. La scalabilit\u00e0 intrinseca del cloud lo rende un ambiente ideale per i database non relazionali.<\/p>\n\n\n\n Ma andiamo per gradi.<\/p>\n\n\n\n Il database non relazionale, chiamato anche NoSQL (Not Only SQL<\/em>) \u00e8 un modello di database che non memorizza i dati in forma tabellare<\/strong>, basandosi invece su strutture di dati come i documenti. I dati sono conservati in documenti e non in tabelle. <\/p>\n\n\n\n Un documento pu\u00f2 contenere diversi tipi di informazioni in formati diversi. Questa caratteristica rende i database non relazionali molto pi\u00f9 flessibili di quelli relazionali, particolarmente adatti per gestire grandi volumi di dati non strutturati o semi-strutturati<\/strong>. <\/p>\n\n\n\n I database non relazionali memorizzano i dati in documenti<\/strong>, e non in strutture logiche, e vengono aggregati per oggetto in documenti di tipo Key-Value (la forma primitiva di database NoSQL) o Document Store basati su semantica JSON. Di solito, infatti, sono strutture simili a JSON che supportano una variet\u00e0 di tipi di dati. <\/p>\n\n\n\n Riprendendo l\u2019esempio di prima, in questo caso tutti i dati dei clienti vengono inseriti in un unico posto, in un solo documento. <\/p>\n\n\n\n Possono esserci diversi tipi di di DB non relazionali:<\/strong> database a documenti, i database a chiave-valore; i database a grafo; i database a colonne.<\/p>\n\n\n\n I database non relazionali sono spesso utilizzati quando \u00e8 necessaria la flessibilit\u00e0<\/strong> nella memorizzazione in termini di forma o dimensione (grandi quantit\u00e0 di dati complessi e diversi) o se devono essere aperti ai cambiamenti futuri. <\/p>\n\n\n\n Per esempio un grande negozio<\/strong> potrebbe avere un database in cui ogni cliente ha un proprio documento contenente tutte le sue informazioni, dal nome e l\u2019indirizzo allo storico degli ordini e ai dati della carta di credito. Nonostante i diversi formati, tutte queste informazioni possono essere memorizzate nello stesso documento.<\/p>\n\n\n\n Con l\u2019avvento dei social, delle applicazioni mobile e del cloud computing, in un\u2019epoca di crescente complessit\u00e0 dei dati provenienti da diversi fonti, nei reparti IT si \u00e8 imposta la necessit\u00e0 di lavorare con database flessibili, scalabili, veloci<\/strong>. <\/p>\n\n\n\n E i database non relazionali offrono una grande flessibilit\u00e0 nella progettazione dei database. In particolare quando accompagnati al cloud<\/strong>, questi DB non relazionali eliminano i problemi relativi ai limiti della raccolta, organizzazione e analisi dei dati.<\/p>\n\n\n\n Ecco perch\u00e9 i database non relazionali hanno ricevuto un forte impulso di sviluppo<\/strong>, tanto da diventare quasi una scelta obbligata in determinati contesti, rispetto ai database relazionali o SQL. <\/p>\n\n\n\n Proprio in virt\u00f9 delle diverse fonti, i dati assumono forme diverse: numeri e stringhe, contenuti fotografici e video, ecc. <\/p>\n\n\n\n In questo scenario, un database deve essere capace di memorizzare questi diversi formati<\/strong> di informazioni, comprendere le relazioni tra di essi ed eseguire query dettagliate. <\/p>\n\n\n\n Con i database SQL, il peso computazionale cresce con l\u2019aumento dei dati inseriti, del numero di tabelle e delle informazioni da gestire. Questo pu\u00f2 diventare un limite, sempre considerando il contesto in cui serve disporre di un DB che risponda a determinate esigenze.<\/p>\n\n\n\n Al contrario, i database NoSQL non prevedono operazioni di aggregazione sui dati, in quanto tutte le informazioni sono gi\u00e0 raccolte in un unico documento associato all\u2019oggetto in questione. Il NoSQL non impone limiti di dimensioni. Infatti, i database di documenti sono adatti a gestire i \u201cbig data\u201d e i dati non strutturati<\/strong>. <\/p>\n\n\n\n I database non relazionali sono schemaless<\/em>, ovvero privi di tabelle e di qualsiasi schema definito a priori, in quanto il documento JSON contiene tutti i campi necessari.<\/p>\n\n\n\n In questo modo, possiamo inserire sempre nuovi dati e informazioni nei documenti JSON, senza alcuna ricaduta sulla loro integrit\u00e0. <\/p>\n\n\n\n I database non relazionali, a differenza di quelli SQL, si rivelano quindi adatti a inglobare velocemente nuovi tipi di dati <\/strong>e a conservare dati semistrutturati o non strutturati.<\/p>\n\n\n\n A differenza dei database relazionali, i NoSQL non richiedono uno schema fisso, il che li rende ideali per gestire dati non strutturati o che possono cambiare nel tempo.\u00a0<\/p>\n\n\n\n E ancora, a differenza dei database relazionali, per i quali \u00e8 possibile scalare solo in senso verticale (CPU, spazio su disco rigido, ecc.), i database non relazionali, compresi quelli documentali, possono essere scalati in senso orizzontale<\/strong>. Ci\u00f2 significa che i database possono distribuire i dati su pi\u00f9 nodi per far fronte a carichi di lavoro crescenti. <\/p>\n\n\n\n Di fatto, i moderni database NoSQL sono stati progettati per il cloud, il che li rende naturalmente adatti allo scaling orizzontale grazie all\u2019aggregazione dei dati e all\u2019assenza di uno schema definito a priori.\u00a0<\/p>\n\n\n\n I database non relazionali non solo possono memorizzare enormi quantit\u00e0 di informazioni, ma possono anche interrogare questi set di dati con rapidit\u00e0<\/strong>. <\/p>\n\n\n\n Generalmente i database non relazionali sono pi\u00f9 veloci perch\u00e9 una query non deve visualizzare diverse tabelle per fornire una risposta, come invece accade con i database relazionali. Indipendentemente dal formato delle informazioni, i database non relazionali possono riunire diversi tipi di informazioni<\/strong> nello stesso documento.<\/p>\n\n\n\n I vantaggi di un database non relazionale <\/strong>risiedono nel fatto che oggi le aziende vogliono raccogliere e memorizzare quantit\u00e0 di dati sempre pi\u00f9 grandi e pi\u00f9 complessi. Dati che fanno comodo per costruire strategie di marketing sempre pi\u00f9 precise.<\/p>\n\n\n\n A questo punto, dopo tanto scrivere, dovrebbe essere chiara la differenza principale tra i due tipi di database<\/strong>, che sta nella loro struttura e nel modo in cui memorizzano e gestiscono le informazioni.<\/p>\n\n\n\n Ecco un recap al volo<\/strong>, <\/p>\n\n\n\n Conclusioni<\/strong><\/p>\n\n\n\n Cosa \u00e8 meglio? Dipende. <\/p>\n\n\n\n Il database relazionale e NoSQL sono due tipi di database che utilizzano differenti modelli di dati e struttura <\/strong>per organizzare e gestire le informazioni.<\/p>\n\n\n\n La scelta<\/strong> tra database relazionali e non-relazionali dipende dalle esigenze e dalle caratteristiche specifiche del progetto. <\/p>\n\n\n\n Se \u00e8 necessario lavorare con dati strutturati e garantire l\u2019integrit\u00e0 referenziale, un database relazionale<\/strong> potrebbe essere la scelta migliore. In generale, si consideri che il database relazionale viene utilizzato per gestire grandi quantit\u00e0 di dati strutturati e complessi<\/strong>, come ad esempio i dati finanziari o i dati di inventario.<\/p>\n\n\n\n D\u2019altra parte, se i dati sono non strutturati o cambiano frequentemente, e se la flessibilit\u00e0 e la scalabilit\u00e0 sono priorit\u00e0 assolute<\/strong>, allora un database NoSQL \u00e8 la soluzione pi\u00f9 adatta.<\/p>\n\n\n\n Con il database NoSQL<\/strong>, che non usa il modello tabellare, invece, possiamo gestire grandi quantit\u00e0 di dati non strutturati o semistrutturati, come per esempio i dati dei social media o i dati delle app mobili, delle immagini e dei sensori.<\/p>\n\n\n\n Piattaforme come Facebook, Twitter e altri social usano i database NoSQL per sfruttare la velocit\u00e0 di esecuzione nell\u2019elaborazione di terabyte e terabyte di dati, la scalabilit\u00e0 orizzontale, un elevato livello di availability, la disponibilit\u00e0 di migliaia di dati non strutturati.Esiste anche la via di mezzo<\/strong>, ovvero l\u2019approccio ibrido che combina database relazionali e non-relazionali, nel caso in cui si volesse trovare un equilibrio tra integrit\u00e0 e flessibilit\u00e0 dei dati.<\/p>\n","protected":false},"excerpt":{"rendered":" Quali sono le differenze tra un database relazionale come MySQL e un database non relazionale o NoSQL? Quale \u00e8 meglio tra l\u2019uno e l\u2019altro? Quando si pianifica un nuovo progetto o una nuova applicazione, spesso si discute dei requisiti del database. Che tipo di database si dovrebbe usare? In un mondo in cui i dati […]<\/p>\n","protected":false},"author":4,"featured_media":18737,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_eb_attr":"","footnotes":""},"categories":[108],"tags":[343,185,188],"class_list":["post-256140","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sviluppo","tag-big-data","tag-database","tag-sql"],"yoast_head":"\nTipi di Dati<\/h2>\n\n\n\n
Cos\u2019\u00e8 un Database Relazionale (o SQL)<\/h2>\n\n\n\n
![\"SQL\"](\"https:\/\/www.artera.net\/wp-content\/uploads\/2014\/06\/sql.jpg\")
<\/figure>\n\n\n\nCome funziona il DB relazionale?<\/h3>\n\n\n\n
Esempio di tabella del database relazionale <\/h3>\n\n\n\n
I vantaggi del DB relazionale\u00a0<\/h2>\n\n\n\n
Integrit\u00e0 referenziale<\/h3>\n\n\n\n
Conformit\u00e0 ACID<\/h3>\n\n\n\n
Accuratezza dei dati<\/h3>\n\n\n\n
Normalizzazione<\/h3>\n\n\n\n
Semplicit\u00e0<\/h3>\n\n\n\n
I limiti e gli svantaggi del Database Relazionale<\/h2>\n\n\n\n
Ridotte scalabilit\u00e0 e flessibilit\u00e0<\/h3>\n\n\n\n
Prestazioni correlate alla complessit\u00e0 delle tabelle<\/h3>\n\n\n\n
Database Non-Relazionali (NoSQL)<\/h2>\n\n\n\n
![\"NoSQL\"](\"https:\/\/www.artera.net\/wp-content\/uploads\/2014\/06\/nosql.jpg\")
<\/figure>\n\n\n\nQuando utilizzare i DB non relazionali<\/h3>\n\n\n\n
I vantaggi del DB NoSQL (non relazionali)<\/strong><\/h3>\n\n\n\n
Leggerezza computazionale <\/h3>\n\n\n\n
Assenza di schema<\/h3>\n\n\n\n
Flessibilit\u00e0 e Scalabilit\u00e0<\/h3>\n\n\n\n
Velocit\u00e0<\/h3>\n\n\n\n
I database non relazionali sono quindi ideali per archiviare dati che possono variare spesso, o per applicazioni che gestiscono molti tipi di dati diversi. Possono supportare applicazioni in rapido sviluppo che richiedono un database dinamico, in grado di cambiare rapidamente<\/strong> e di ospitare grandi quantit\u00e0 di dati complessi e non strutturati. <\/p>\n\n\n\nDifferenze tra DB SQL e DB NoSQL<\/h2>\n\n\n\n
I database non relazionali (NoSQL) differiscono dai database relazionali (SQL) in diversi modi, tra cui la struttura dei dati, il linguaggio di query, la scalabilit\u00e0 e l\u2019affidabilit\u00e0.<\/p>\n\n\n\n\n
<\/li>\n\n\n\n
Al contrario, i database NoSQL utilizzano spesso linguaggi di query proprietari o specifici del tipo di database, come ad esempio il MongoDB Query Language per i database documentali o il Gremlin per i database a grafo.
<\/li>\n\n\n\n
Al contrario, i database NoSQL sono progettati per la scalabilit\u00e0 orizzontale e possono gestire grandi quantit\u00e0 di dati in modo distribuito e scalabile.
<\/li>\n\n\n\n