Come è noto, i database sono componenti fondamentali di qualsiasi sistema informatico. Infatti ogni programma utilizza dati o genera informazioni che devono essere memorizzate in modo affidabile e permanente. Ciò viene fatto in database strutturati (DB) che sono gestiti dai cosiddetti database management system (DBMS), ovvero sistemi di gestione del database, applicazioni software che interagiscono con gli utenti finali o altri programmi e forniscono loro un sottoinsieme di dati memorizzati nel database.
Ad oggi la gestione elettronica dei dati è dominata dai modelli di database relazionale. Questo è un elenco in ordine alfabetico dei sistemi di gestione di database relazionali (RDBMS) più utilizzati:
Tutti i sistemi nominati si basano su un’organizzazione tabulare di informazione. Ma cosa significa? Vi presentiamo alcuni principi di base della progettazione dei database relazionali, introduciamo i database relazionali con esempi e vi spieghiamo le differenze che intercorrono con altri modelli.
Come è prevedibile, il termine centrale nei modelli di database relazionali è quello di relazione. Un concetto che risale al matematico e teorico dei database britannico Edgar F. Codd. Secondo Codd una relazione rappresenta un insieme di entità con le stesse proprietà: ogni relazione consiste in una serie di dati (le cosiddette tuple), i cui valori sono associati a determinati attributi.
Si definisce quali siano gli attributi compresi da una relazione e quali tipi di dati corrispondano ai valori assegnati agli attributi utilizzando uno schema di relazione secondo la seguente sintassi:
R = (A1 : Tipo1, A2 : Tipo2 ,… , An : Tipon)
Lo schema di relazione (R) comprende gli attributi da A1a An. A ciascun attributo è assegnato un tipo di dato (Tipo1, Tipo2ecc.). Questo schema di relazione può essere illustrato da un esempio concreto.
Lo schema seguente specifica gli attributi della relazione “collaboratore”:
collaboratore = (c_id: integer,
cognome : string,
nome : string,
cf : string,
ind : string,
cap : string,
luogo : string )Questo schema di esempio tocca gli attributi ID del collaboratore (c_id), cognome, nome, codice fiscale (cf), indirizzo (ind), codice di avviamento postale (cap) e luogo e potrebbe per esempio servire alla gestione interna aziendale dei dati personali. A ogni attributo viene assegnata una tipologia di dato (ad esempio string o integer), indicando che in questa relazione ci sono attributi che concepiscono come valori una stringa di segni, mentre altre non accettano che numeri interi.
Una relazione con lo schema appena definito potrebbe contenere la seguente tupla:
(1, Bianchi, Maria, BNCMRA18E47R230W, via Roma 1, 11111 Roma)Per poter rappresentare l’attribuzione di singoli valori di una tupla agli attributi definiti nello schema di relazioni, nel modello di database relazionale viene utilizzato uno dei concetti classici dell’organizzazione delle informazioni: la tabella. Un database relazionale perciò non è altro che un insieme di tabelle correlate.
Le tabelle sono schemi di ordinamento di righe orizzontali e colonne verticali che consentono di raccogliere le informazioni e presentarle in formo ordinato. Ogni riga di una tabella di database corrisponde a una tupla. I valori delle tuple elencate vengono assegnati tramite le colonne della tabella agli attributi definiti nello schema delle relazioni.
Nell’esempio seguente potete vedere come una tabella di database possa rappresentare lo schema dei collaboratori sopra illustrato:
| c_id | Cognome | Nome | cf | Ind | CAP | Luogo |
|---|---|---|---|---|---|---|
| 1 | Bianchi | Maria | BNCMRA55F59F500S | Via Roma 1 | 11111 | Roma |
| 2 | Rossi | Giada | RSSGDI97G54B243L | Via Matteotti 1 | 22222 | Genova |
| 3 | Padovan | Gianluca | PDVGLC55M21L424T | Via F.lli Cervi 1 | 33333 | Gela |
| 4 | Terragna | Elisabetta | TRRLBT32R56C352Z | Via Quasimodo 1 | 44444 | Novara |
La tabella di esempio serve all’archiviazione dei dati personali e consta di quattro record. Ognuno di essi contiene informazioni su un collaboratore preciso.
Il termine “relazione” viene utilizzato da Edgar F. Codd come sinonimo di “tabella”, però nella pratica questa parola viene utilizzata in modi differenti, per esempio per indicare relazioni tra diverse tabelle (relationships). Per non incorrere in equivoci, eviteremo il concetto di “relazione” e parleremo da ora in poi di “tabelle” quando ci riferiamo a tabelle di database in un database relazionale.
Il database di un sistema di database relazionale costituisce la base di dati tabulare strutturata. La sua struttura di dati viene definita dal sistema di gestione del database, che è anche responsabile della gestione degli accessi in lettura e scrittura. Gli utenti interagiscono con il sistema di gestione del database utilizzando un linguaggio di database. Ogni sistema di gestione di database relazionali supporta almeno un linguaggio formale che può essere utilizzato per eseguire le seguenti operazioni di database:
Normalmente l’interfaccia standard per le operazioni di database illustrate sopra nei modelli di database relazionali è quella basata su SQL (Structured Query Language), un linguaggio di database basato sull’algebra relazionale.
Le operazioni del database come le query, la creazione, l’aggiornamento o l’eliminazione di dati vengono eseguite utilizzando le cosiddette SQL statements, una combinazione di comandi SQL selezionati. Essi sono basati semanticamente sulla lingua inglese e sono perciò di ovvio significato. La seguente tabella contiene i termini chiave del modello di dati relazionali e il loro equivalente nella terminologia SQL.
| Modello di dati relazionale | SQL |
|---|---|
| Relazione | Table (tabella) |
| Attributo | Column (colonna) |
| Tupla | Row (riga) |
Una semplice query di dati scelti si può implementare per esempio con SQL secondo il seguente schema:
SELECT colonna FROM tabella WHERE colonna = valore;Inizialmente usiamo il comando SELECT, per assegnare all’RDBMS la richiesta dei dati. In seguito definiamo quali dati vogliamo richiedere, inserendo la tabella e la colonna desiderata. Inoltre utilizziamo “WHERE” per inserire un vincolo nello statement SQL. Non vogliamo richiamare tutto l’insieme di valori degli attributi contenuti nella colonna, ma soltanto il valore di un particolare record. Con riferimento alla nostra tabella di esempio “collaboratori” un simile SQL statement può apparire come segue:
SELECT cf FROM collaboratori WHERE c_id = 3;Lo statement SQL chiede al RDBMS di richiamare dalla tabella “collaboratori” un valore dalla colonna cf. Come vincolo abbiamo definito che il valore debba essere estrapolato dal record il cui valore nella colonna c_id è 3.
Come risultato il database ci riporta “PDVGLC55M21L424T”, ovvero il codice fiscale di Gianluca Padovan, il collaboratore con l’ID numero 3.
Il nostro tutorial MySQL per principianti fornisce una descrizione esauriente delle operazioni di database soggiacenti basandosi sul linguaggio SQL.
Quando si lavora con database relazionali, gli utenti raramente devono gestire singole tabelle. Di norma vengono utilizzate strutture nelle quali i dati vengono ordinati in base al loro significato e memorizzati in tabelle separate. Questo concetto, che si basa sul modello di database relazionale, implica la necessità di collegare tabelle di dati, ad esempio quando si interrogano dati memorizzati in tabelle diverse.
In linea di principio si possono anche riunire tutte le informazioni di un database relazionale in una tabella generale, con il vantaggio che si risparmia il collegamento tra le tabelle del database e la complessa sintassi associata alla query su più tabelle. Ma questa è la forza del modello di database relazionale: la divisione delle informazioni su più tabelle serve a ridurre le voci duplicate (le cosiddette anomalie) e si chiama normalizzazione. Il grado di normalizzazione può essere determinato utilizzando forme normali (Normal form) predefinite. Le comuni forme normali per le tabelle di database relazionali sono:
Boyce-Codd Normalform (BCNF)
Nel nostro articolo sulle basi della normalizzazione approfondiamo quali siano i requisiti per le forme normali elencate e come convertire un database da una forma normale a un’altra.
Le relazioni tra diverse tabelle di database vengono chiamate relationship nei modelli di database relazionale e sono ottenute utilizzando chiavi che collegano le tabelle tra di loro e sono la base per le query o per modificare i dati di diverse tabelle con la stessa istruzione.
Le tabelle del database, come la tabella dei collaboratori dell’esempio, consentono approcci diversi per recuperare singoli valori o interi record. L’attenzione si concentra sulle cosiddette chiavi: nel modello di database relazionale, una chiave è intesa come un insieme di attributi che sono adatti per identificare un record in modo univoco. Riguardo alla tabella di esempio sopra riportata, la seguente chiave consente l’identificazione univoca di una tupla:
{c_id, cognome, nome, cf}Una chiave del genere con i valori
(c_id = '3', cognome = 'Padovan', nome = 'Gianluca', cf = 'PDVGLC55M21L424T') Sarebbe perciò idonea a identificare il record appartenente al dipendente Gianluca Padovan in modo incontrovertibile. A riguardo di questo tipo di chiavi si parla di superchiavi, anche se le superchiavi hanno nella pratica soltanto un significato limitato. Uno dei motivi è che le superchiavi spesso contengono più attributi di quelli che sarebbero necessari per l’identificazione. In altre parole: non sono per nulla minimali.
Nei database relazionali si lavora perciò con i più piccoli sottoinsiemi possibili (i cosiddetti candidati chiave) di una ipotetica superchiave. Una tabella può avere diversi candidati chiave con i quali i record si possono identificare in modo univoco.
Già l’esempio al paragrafo precedente ha mostrato che i record della tabella “collaboratori” si possono identificare in modo univoco e incontrovertibile semplicemente con l’ID del collaboratore. Un ulteriore candidato chiave nella tabella di esempio è il codice fiscale, essendo unico. Una chiave che si basa sul nome e/o il cognome, invece, non è un candidato idoneo, perché questi dati, anche in combinazione, possono non essere ascrivibili in modo preciso ad un solo candidato. Infatti in un’azienda possono lavorare più dipendenti con il nome Gianluca Padovan. Invece è escluso che due persone abbiano lo stesso codice fiscale o lo stesso ID collaboratore.
Per la tabella di esempio illustrata sopra si possono perciò stabilire i seguenti candidati chiave:
{c_id}
{cf}Le tabelle dei database relazionali sono solitamente strutturate in modo che uno dei possibili candidati chiave della serie di record specifichi l’ordine dei record. Questo candidato chiave è nominato chiave primaria (primary key). In pratica le chiavi primarie sono solitamente gli ID progressivi, come accade anche nella tabella dei collaboratori sopra.
Poiché le chiavi identificano in modo univoco i record nelle tabelle di database relazionali, sono perfettamente adatte a collegare tra loro diverse tabelle di un database. Per fare ciò si prende una chiave primaria di una tabella e la si usa come chiave esterna (foreign key) in un’altra tabella.
La seguente tabella contiene dati che un’azienda potrebbe registrare per la propria flotta. La chiave primaria della tabella “auto” è un ID progressivo.
| ID auto | Marca | Modello | Targa | Anno di costruzione | revisione |
|---|---|---|---|---|---|
| 1 | VW | Caddy | B KH 778 | 2016 | 43452 |
| 2 | Opel | Astra | B PO 654 | 2010 | 43689 |
| 3 | BMW | X6 | B MW 780 | 2017 | 43344 |
Per avere sott’occhio quale macchina sia usata da quale collaboratore, occorre collegare la tabella “auto” con quella “collaboratori”, ad esempio integrando la chiave primaria della tabella delle auto (ID auto) come chiave esterna della tabella dei collaboratori.
| c_id | Cognome | Nome | Cf | Ind | Nr | CAP | Luogo | ID_auto |
|---|---|---|---|---|---|---|---|---|
| 1 | Bianchi | Maria | BNCMRA55F59F500S | Via Roma | 1 | 11111 | Roma | 3 |
| 2 | Rossi | Giada | RSSGDI97G54B243L | Via Matteotti | 1 | 22222 | Genova | 1 |
| 3 | Padovan | Gianluca | PDVGLC55M21L424T | Via F.lli Cervi | 1 | 33333 | Gela | 1 |
| 4 | Terragna | Elisabetta | TRRLBT32R56C352Z | Via Quasimodo | 1 | 44444 | Novara | 2 |
Dalla tabella dei collaboratori ora si può stabilire che l’impiegata Bianchi sta utilizzando una vettura aziendale con il numero di identificazione 3, mentre Terragna viaggia con la numero 2; infine Rossi e Padovan condividono la numero 1.
Se si desidera capire quale dipendente deve far revisionare l’auto aziendale, occorre interrogare la tabella “collaboratore” insieme alla tabella “auto”, ma siccome entrambe le tabelle sono collegate attraverso una chiave esterna, si può fare con una sola query. Le operazioni del database che si estendono su più tabelle vengono implementate nel modello di database relazionale utilizzando un JOIN.
Un JOIN (in italiano: interconnessione) è un’operazione di database che consente query su più tabelle di database contemporaneamente. I dati delle tabelle selezionate vengono riepilogati in un set di risultati e l’output viene filtrato in base alle condizioni definite dall’utente.
Le basi matematiche di SQL JOIN sono due operazioni dell’algebra relazionale: il prodotto cartesiano e la selezione. Sono gli utenti, attraverso la scelta del tipo di JOIN e utilizzando una condizione di selezione, a stabilire quali dati delle tabelle interrogate saranno inclusi nel set dei risultati.
Tra i tipi di JOIN più rilevanti rientrano:
Indipendentemente da questo bisogna poi distinguere tra EQUI JOIN e NON EQUI JOIN.
Nel nostro articolo su SQL JOIN illustriamo come funzionano i JOIN SQL con le tabelle di database relazionali e a cosa bisogna prestare attenzione nella scelta del tipo di JOIN.
Occorre distinguere i database relazionali basati su SQL dai concetti che rompono la rigida struttura della tabella e perseguono approcci alternativi alla strutturazione dei dati. I concetti più importanti di questo tipo includono database di oggetti e sistemi basati sui documenti.
Alla fine degli anni 80 i database degli oggetti venivano usati per creare un nuovo modello di database che riprendeva i concetti della programmazione orientata agli oggetti e abilitava la memorizzazione dei dati sotto forma di oggetti. Anche se questo approccio ha avuto poco successo fino ai giorni nostri, il concetto di orientamento agli oggetti è stato proficuamente incorporato nello sviluppo dei sistemi di database relazionali. Il risultato sono prodotti con estensioni relazionali che consentono l’archiviazione di tipi di dati astratti nel modello di database relazionale.
Con l’avvento del web 2.0 e i cambiamenti avvenuti nell’utilizzo di Internet, il modello di database relazionale è tornato al centro dell’attenzione: nell’ambito del movimento NoSQL (abbreviazione per not only SQL, che in italiano significa non solo SQL), sono stati sviluppati modelli alternativi come i database orientati ai documenti. Lo scopo di questo movimento era sviluppare potenti concetti di database per applicazioni ad alta intensità di dati.
I database degli oggetti si differenziano dai modelli di database relazionale e dai database orientati ai documenti soprattutto per il modo in cui i record vengono archiviati e per il modo in cui si accede ai dati archiviati.
Il modello di database orientato all’oggetto prevede l’archiviazione dei dati come oggetti. La modulazione degli oggetti rassomiglia alla programmazione orientata agli oggetti. Un oggetto definisce un’entità e contiene:
In questo modo un oggetto è una combinazione di dati; nei quali viene definita anche l’interfaccia tramite la quale si accede a questi dati. Gli oggetti sono contati tra i tipi di dati astratti.
Il sistema di gestione del database orientato agli oggetti (ODBMS) assegna un ID ad ogni oggetto, consentendo di identificare univocamente l’oggetto e di interrogarlo attraverso formule. Questo ID dell’oggetto è indipendente dallo stato, cioè non accoppiato ai valori dell’oggetto. In questo modo è possibile dare a due oggetti con gli stessi dati (cioè con lo stesso stato) due ID diversi. Il modello di database orientato agli oggetti è chiaramente diverso dal modello relazionale in cui ciascuna tupla può essere identificata dai suoi dati (ad esempio, da una chiave primaria).
Un’altra caratteristica del modello di database orientato agli oggetti è l’incapsulamento dei dati. È possibile accedere ai dati memorizzati solo tramite i metodi precedentemente definiti. I dati incapsulati nell’oggetto sono perciò protetti contro le modifiche tramite interfacce non definite.
Le strutture del database sono definite nel modello di database orientato agli oggetti tramite un sistema di classi gerarchico. Una classe nella programmazione orientata agli oggetti è un insieme di oggetti che hanno le stesse caratteristiche. Ogni classe di oggetti è basata su una definizione di classe. Questo schema specifica gli attributi e i metodi di tutti gli oggetti della classe e così determina in che modo vengono generati e modificati.
Gli utenti interagiscono con l’ODMBS con un linguaggio di query basato su SQL per i database degli oggetti: l’Object Query Language (OQL); il risultato di una query OQL non e un set di risultati come con SQL, ma un elenco di oggetti che soddisfano le condizioni dello statement OQL.
Implementazioni note del modello di database orientato agli oggetti sono Realm, ZODB e Perst.
I database orientati agli oggetti sono stati sviluppati come soluzione a un problema nello sviluppo di applicazioni indicato come object-relational impedence mismatch (in italiano si può tradurre come “incompatibilità oggetto relazione” che fondamentalmente implica l’incompatibilità tra un sistema di gestione del database relazionale e una o piò applicazioni scritte in un linguaggio di programmazione orientato all’oggetto).
Se gli oggetti scritti in un linguaggio di programmazione orientato all’oggetto (come ad esempio C#, C++ o Java) vengono salvati in un database relazionale, infatti, ciò porta immancabilmente a incompatibilità che affondano nelle diversità di base tra i due paradigmi di programmazione:
Un approccio per evitare i menzionati problemi di incompatibilità è quello di evitare i database relazionali e di collocare la programmazione di applicazioni orientate agli oggetti su un database di oggetti; un approccio che ha però l’inevitabile svantaggio che i dati incapsulati negli oggetti non sono disponibili indipendentemente dall’applicazione associata. A ciò si aggiunge la bassa distribuzione dei database a oggetto: la maggior parte degli strumenti e delle interfacce per l’analisi di dati sono ancora basate su database relazionali e non supportano il modello orientato agli oggetti.
Gli sviluppatori di applicazioni che non vogliono rinunciare ai vantaggi dell’archiviazione dei dati relazionali hanno la possibilità di compensare le incompatibilità utilizzando il mapper relazionale a oggetti (O/R mapper). Le funzionalità per l’object-relational mapping (ORM, in italiano mappatura relazionale a oggetti) sono implementate tramite le librerie, che creano un livello un livello di astrazione tra l’applicazione orientata agli oggetti e i dati memorizzati nelle tabelle.
Molti produttori di sistemi di database relazionali forniscono i propri prodotti con funzionalità che compensano anche le incompatibilità di programmazione orientata agli oggetti. I sistemi di database di questo tipo sono chiamati “relazionali a oggetto”.
I database orientati all’oggetto trasferiscono i principi di base dell’orientamento agli oggetti alle tecnologie di database e sono quindi particolarmente adatti per la programmazione di applicazioni orientate agli oggetti. I sistemi di database corrispondenti, tuttavia, sono scarsi e in alcuni casi non ancora pronti per il mercato.
Un sistema di database relazionale orientato agli oggetti è un sistema di database relazionale ampliato con concetti propri dell’orientamento agli oggetti. I principi comprovati del modello di database relazionale verranno estesi a tipi di dati astratti come gli oggetti.
Per consentire la gestione di dati astratti, i database relazionali a oggetti ampliano il modello di database relazionale a:
Mentre i database relazionali sono essenzialmente limitati a tipi di dati alfanumerici, con i tipi di dati definiti dall’utente si possono gestire anche file multimediali strutturati in modo complesso. I type constructor consentono di costituire nuovi tipi di dati a partire dai dati di base forniti. Poiché il linguaggio di database SQL non offre la possibilità di generare funzioni, i sistemi di database relazionali a oggetti devono fornire estensioni che definiscono le modalità di accesso e di elaborazione per tipi di dati complessi.
A partire dal nuovo millennio le estensioni relazionali a oggetti come i tipi strutturati sono state incluse nelle versioni più recenti dello standard SQL. Tuttavia, questi non sono supportati da tutti i DBMS. I sistemi di database noti che forniscono tali estensioni sono IBM Db2, Oracle Database e Microsoft SQL Server.
Mentre l’archiviazione dei dati del database relazionale viene eseguita nelle tabelle del database, il modello di database incentrato sui documenti si basa su un database eterogeneo di singoli documenti. Questi possono essere documenti strutturati come file JSON, YAML o XML, ma anche file non strutturati come Binary Large Objects (BLOB), file immagine, video o audio.
Se sono disponibili documenti strutturati, i dati vengono memorizzati sotto forma di coppie chiave/valore e ad ogni chiave viene assegnato un valore specifico. Va specificato che in questo contesto il termine chiave è utilizzato come sinonimo di attributo e non ha niente a che fare con le chiavi nei sistemi di database relazionali. I valori possono riguardare qualsiasi informazione: anche gli elenchi e gli array con dati annidati sono valori possibili.
Di seguito vi mostriamo il possibile aspetto di un documento in formato JSON (JavaScript Object Notation) per l’archiviazione dei dati dei dipendenti:
Bianchi | Maria | BNCMRA55F59F500S | Via Roma | 1 | 11111 | Roma | 3 |
{
"id" : 1,
"cognome" : "Bianchi",
"nome" : "Maria",
"cf" : "BNCMRA55F59F500S",
"ind" : "via Roma 1",
"cap" : "11111",
"luogo" : "Roma",
"id_auto" : [1, 4]
}Diversi documenti possono essere raggruppati in raccolte di documenti (le cosiddette collection). Ad esempio, il documento del dipendente mostrato potrebbe essere insieme ad altre parti della collection “collaboratore”.
Le query vengono implementate utilizzando le funzioni, ad esempio tramite JavaScript. Anche i sistemi di gestione dei database che lavorano in modo orientato ai documenti assegnano ad ogni documento un ID univoco. A differenza del modello di database relazionale non esiste tuttavia uno schema di database che copra l’intero database: i documenti di un database basato su documenti non devono conformarsi a un modulo normale, né esistono determinate caratteristiche strutturali che devono essere applicate a tutti i documenti. In linea di principio ciascun documento può essere strutturato in modo diverso, anche se nel contesto dello sviluppo di applicazioni è consigliabile produrre documenti in uno schema appropriato al fine di creare i prerequisiti per le query mirate.
Con i database orientati ai documenti non si possono implementare relazioni come il collegamento di tabelle di database. Sebbene sia possibile inserire manualmente l’ID di un documento come riferimento in un altro documento, i sistemi di gestione dei database orientati al documento non offrono JOIN. Le opzioni di query corrispondenti devono perciò essere programmate autonomamente.
I sistemi di database orientati ai documenti sono particolarmente adatti per l’elaborazione di grandi quantità di dati con una struttura eterogenea e una bassa connettività di rete. Pertanto, questo modello di gestione dei dati ha senso soprattutto negli scenari che hanno a che fare con big data.
I sistemi di database relazionali garantiscono che le condizioni specificate nelle definizioni delle tabelle siano soddisfatte in ogni momento. Ciò porta ad una velocità di scrittura relativamente bassa durante l’elaborazione di grandi quantità di dati. I sistemi di database NoSQL non hanno requisiti di coerenza dei dati così rigidi e sono quindi adatti per architetture di grandi dimensioni in cui molte istanze di database vengono utilizzate in parallelo.
Anche le applicazioni web ricorrono sempre più a database orientati ai documenti. Tuttavia, se è richiesta una rete forte, l’archiviazione dei dati basata su documenti richiede più tempo. Gli utenti dovrebbero utilizzare in questi casi sistemi di database relazionali.
Esempi di database orientati ai documenti sono BaseX, CouchDB, eXist, MongoDB e RavenDB.
I database relazionali hanno buoni motivi per essersi affermati come lo standard nell’elaborazione elettronica dei dati:
A seconda dello scenario in cui vengono utilizzati i sistemi di database relazionali, alcuni dei vantaggi menzionati quali la semplicità del modello di dati basato su tabelle e la distribuzione dei dati tra più tabelle collegate possono rivelarsi svantaggi. Inoltre le caratteristiche chiave del modello di dati relazionali sono difficili da conciliare con i moderni requisiti di programmazione delle applicazioni (come orientamento degli oggetti, multimedia e big data).
Il modello di database relazionale è chiaro, matematicamente valido e ha alle spalle più di 40 anni di utilizzo pratico. Eppure l’archiviazione dei dati in tabelle strutturate non soddisfa tutti i requisiti della moderna tecnologia informatica.
I limiti dei classici sistemi relazionali sono messi in evidenza soprattutto dall’amministrazione di grandi quantità di dati nel contesto dell’analisi di big data e dall’archiviazione di tipi di dati astratti, dove si distinguono invece sistemi specializzati come i database a oggetto o i concetti sviluppati nell’ambito del movimento NoSQL. Tuttavia non è possibile lasciarsi completamente alle spalle il modello di database relazionale, che tuttora offre molti vantaggi, specialmente negli ambiti in cui l’elaborazione dei dati delle transazioni è di primaria importanza.
I dati sulle azioni dei clienti o sulle misure di marketing si possono idealmente rappresentare nei sistemi tabulari. Inoltre gli utenti beneficiano di una sintassi che, nonostante la propria semplicità, consente query complesse.
Occupandosi dello sviluppo di software, capiterà di imbattersi nella tavola CRUD. L’acronimo sta per le tipiche operazioni usate nella comunicazione con i database, che sono alla base della gestione dei dati. Ma come si configurano esattamente queste funzioni di accesso per gestire i database? E che ruolo ricoprono i linguaggi di programmazione e il corrispettivo ambiente del database?
Per soddisfare le richieste e unire i dati provenienti da diverse tabelle di database è necessario ricorrere a operazioni basate sull'algebra relazionale, realizzate grazie a diversi tipi di join. Vi introduciamo la query dei database con i join, ne differenziamo i diversi tipi e vi spieghiamo come eseguire join complessi servendovi di chiare dichiarazioni SQL.
Gli in-memory database consentono di analizzare ed elaborare una grande mole di dati in tempo reale; archiviando i dati nella memoria centrale garantiscono notevoli velocità di accesso, a differenza dei database tradizionali che archiviano i dati sul disco rigido. Quali sono gli altri elementi che distinguono gli in-memory database dai sistemi tradizionali? E quali in-memory database dovreste...
Il sistema di gestione del database PostgreSQL, conosciuto anche come Postgres, ha una lunga storia. Originariamente lanciato come progetto dell’Università di Berkeley, il database open source continua a essere sviluppato per arricchirlo di funzionalità e migliorarne le prestazioni, tanto che può competere con i rivali commerciali. Ma cosa caratterizza esattamente PostgreSQL e come si installa su...
Di solito i database si basano su righe di dati. I sistemi di gestione di basi di dati orientati alle colonne capovolgono questo sistema: le voci, invece di essere memorizzate una dopo l’altra, sono archiviate categoria per categoria in un database colonnare. Ciò determina un decisivo aumento di velocità in presenza di grandi quantità di dati. Ma come funzionano esattamente i database a colonne?
Offri ai tuoi clienti servizi professionali e affidabili con l'hosting di IONOS.
Scopri i pacchetti
Dominio omaggio per un anno