Il modello di database relazionale

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:

• Db2: Db2 è un sistema relazionale di gestione del database proprietario di casa IBM, a disposizione dell’utente con licenza commerciale.
   
• Microsoft SQL Server: questo sistema di gestione del database di Microsoft è disponibile con licenza a pagamento Microsoft per l’utente finale.
   
• MySQL: MySQL è uno degli RDBMS open source più utilizzati del mondo. Da quando è stato acquisito da Oracle, MySQL è sul mercato con un doppio sistema di licenze: la comunità di sviluppatori originale continua il progetto con il nome MariaDB.
   
• PostgreSQL: con PostgreSQL gli utenti hanno a disposizione un sistema di gestione di database relazionale a oggetti (ORDBMS) gratuito. La community open source si occupa anche di proseguirne lo sviluppo.
   
• Oracle Database: il sistema di database relazionale dell’omonima azienda Oracle è commercializzato come software proprietario a pagamento.
   
• SQLite: SQLite è una libreria di dominio pubblico contenente un sistema di gestione del database relazionale.

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 = (A₁ : Tipo₁, A₂ : Tipo₂ , … , A_n : Tipo_n)

Lo schema di relazione (R) comprende gli attributi da A₁ a A_n. A ciascun attributo è assegnato un tipo di dato (Tipo_1, Tipo₂ ecc.). Questo schema di relazione può essere illustrato da un esempio concreto.

Lo schema seguente specifica gli attributi della relazione “collaboratore”:

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:

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 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:

• Definire la struttura di dati: nell’ambito della definizione dei dati viene archiviata una descrizione della struttura dei dati attraverso i metadati nel data dictionary del sistema di database. Se ad esempio un utente crea una nuova tabella, viene archiviato uno schema di relazione corrispondente nel dizionario dei dati. Il vocabolario di un linguaggio di database utilizzato per la definizione dei dati, viene chiamato Data Definition Language (DDL).
   
• Definire le autorizzazioni: ogni linguaggio del database fornisce una sintassi che consente di concedere o revocare le autorizzazioni. In questo caso si parla di Data Control Language (DCL), una parte del vocabolario del linguaggio del database.
   
• Definire i vincoli: i vincoli sono i requisiti per lo stato di un database. Definiti i criteri per l’integrità, il database assicura che vengano soddisfatti in ogni momento e per questo si parla di “stato coerente”. Ad esempio un vincolo di base di integrità nei sistemi di database relazionali è che ogni record (tupla) può essere identificato in modo univoco.
   
• Definire le transazioni: quando un database viene spostato da uno stato consistente ad un altro, si parla di transazione. Le transazioni contengono una serie di istruzioni e devono essere sempre portate a termine, perché se una transazione viene interrotta, il database viene ripristinato nello stato iniziale (rollback). Ogni transazione inizia con l’indicazione di connettersi al database. A questo seguono comandi che avviano l’effettiva operazione nonché un commit che garantisce l’integrità del database. Le operazioni pericolose per l’integrità non vengono eseguite (scritte permanentemente nel database). Infine viene chiusa la connessione al database. Il vocabolario del linguaggio di database che soggiace alla manipolazione dei dati viene chiamato Data Manipulation Language (DML).
   
• Definire le view: una view è una vista virtuale dei dati selezionati. Il sistema di gestione del database crea una tabella virtuale (relazione logica) basata su tabelle fisiche. Con queste view gli utenti possono applicare le stesse operazioni del database come se si trattasse di una tabella fisica. Esistono diversi tipi di visualizzazione dei dati a seconda della funzione, le più comuni sono le view che filtrano determinate righe (vista selezione) o colonne (vista proiezione) da una tabella selezionata, nonché view che collegano insieme tabelle diverse (vista composita).

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.

Una semplice query di dati scelti si può implementare per esempio con SQL secondo il seguente schema:

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:

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.

Una chiave del genere con i valori

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:

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.

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.

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:

• INNER JOIN
• OUTER JOIN
• SELF JOIN

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:

• Le proprietà necessarie a descrivere l’entità (attributi)
• Il rinvio ad altri oggetti (relazione)
• Le funzioni che consentono l’accesso ai dati archiviati (metodi)

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:

• i database relazionali non supportano i concetti orientati all’oggetto, come classi ed ereditarietà;
• nel modello di database relazionale non si può effettuare l’identificazione dell’oggetto indipendentemente dallo stato;
• nel modello di database relazionale non è disponibile il meccanismo di protezione dell’incapsulamento dei dati.

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:

• tipi di dati complessi definiti dall’utente;
• type constructors (nella teoria dei tipi, un “costruttore di tipi” è una caratteristica di un linguaggio formale tipizzato che costituisce nuovi tipi da quelli vecchi);
• funzioni e metodi.

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:

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:

• Modello di dati semplice: i database relazionali si basano su un modello di dati relativamente semplice da implementare e gestire. Grazie ai modelli di database relazionale risulta facile mappare le numerose informazioni, come i dati dei clienti, le liste di ordini o le movimentazioni dei conti, che le aziende archiviano nel lungo periodo.
   
• Ridotta ridondanza dei dati: il modello di database relazionale utilizza i vari moduli normali per fornire regole ben definite per l’eliminazione della ridondanza. Se i requisiti per la normalizzazione vengono implementati in modo coerente, i sistemi di database relazionali consentono una memorizzazione dei dati quasi priva di ridondanze. Questo facilita soprattutto il mantenimento e la cura delle scorte di dati, poiché le modifiche devono essere effettuate in un unico luogo.
   
• Elevata coerenza dei dati: i database relazionali normalizzati consentono un’archiviazione dei dati senza contraddizioni, contribuendo alla coerenza dei dati. I sistemi di database relazionali forniscono anche funzionalità che definiscono e verificano automaticamente i vincoli di integrità. Le transazioni che mettono a repentaglio la coerenza dei dati vengono escluse.
   
• Elaborazione dei dati orientata alla quantità: il sistema di database relazionale si basa sull’elaborazione dei dati orientata alla quantità, in cui ogni entità è suddivisa in valori atomici. Ciò consente il collegamento di varie entità attraverso il contenuto, nonché query di database complesse come JOIN.
   
• Lingua unificata per le query: per le query sui database relazionali è stato stabilito un SQL standardizzato per la lingua del database attraverso gli organi di ISO e IEC; il fine di questa standardizzazione è di consentire lo sviluppo e l’esecuzione delle applicazioni indipendentemente dal sistema di gestione del database soggiacente. Tuttavia fino ad ora il supporto di SQL varia a seconda del DBMS.

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).

• Mappatura tabellare dei dati: non tutti i tipi di dati possono essere espressi in uno schema rigido di tabelle bidimensionali interconnessi (Impedance Mismatch). I tipi di dati astratti e i dati non strutturati associati alle applicazioni multimediali e alle soluzioni big data non possono essere mappati nel modello di database relazionale.
   
• Mancanza di uno schema di database gerarchico: i database relazionali, a differenza dei database di oggetti, non offrono la possibilità di implementare schemi di database con classi strutturate gerarchicamente. Concetti come quelli delle “entità figlio” che ereditano le proprietà dalle “entità padre” non possono essere utilizzati. Ad esempio non è possibile utilizzarli per creare sottotuple. Tutte le tuple di un database relazionale si trovano sullo stesso piano gerarchico.
   
• Segmentazione dei dati: il principio di base dei sistemi di database relazionali, che consiste nella suddivisione delle informazioni su tabelle separate (normalizzazione), porta necessariamente ad una segmentazione dei dati: i dati correlati non sono necessariamente memorizzati insieme. Questo design del database genera query complesse su più tabelle a livello di applicazione. Il conseguente maggior numero di segmenti interrogati di solito ha anche un impatto negativo sulle prestazioni.
   
• Performance peggiori rispetto ai database NoSQL: il modello di database relazionale ha requisiti molto rigidi in termini di coerenza dei dati che nelle transazioni vanno a discapito della velocità di scrittura.

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.