[NoSQL] Implementare un Document Store NoSQL con Oracle 12c e le SODA API

Avete intenzione di implementare una schemaless application, memorizzando le informazioni in modo “dinamico” e flessibile, secondo il cosiddetto paradigma “NoSQL style document store”?

Anche Oracle DB, a partire dalla versione 12.1.0.2, fornisce il supporto per la memorizzazione, l’indicizzazione e la ricerca di documenti in formato JSON.

Oracle12c

Più dettagliatamente, Oracle DB 12c permette, senza necessità di installare plugin aggiuntivi, l’implementazione di un Document Store e fornisce il seguente set di API, progettate per garantire il supporto allo sviluppo di schemaless application:

  • SODA for Java: interfaccia di programmazione document-store per sviluppatori Java che usano JDBC per comunicare con il database. SODA for Java consiste di un set di semplici classi che rappresentano il database, una collezione di documenti e un documento. I metodi di queste classi forniscono tutte le funzionalità richieste per gestire ed interrogare documenti e collezioni di documenti memorizzati in un database Oracle;
  • SODA for REST: interfaccia REST-based document-store implementata come Java servlet e distribuita come parte dell’Oracle REST Data Services (ORDS) 3.0. Le applicazioni basate su SODA for REST usano il protocollo HTTP per comunicare con la Java Servlet. SODA for REST Servlet può anche essere eseguito su un HTTP Server nativo del database (esistono versioni “bundle” di Web Server, come TomCat e JBoss opportunamente configurati per accedere al DB Oracle tramite API SODA). I metodi HTTP come PUT, POST, GET e DELETE mappano le operazioni eseguite sui documenti JSON. Fornendo API di tipo REST è possibile integrare la soluzione con web application esterne per esporre i dati memorizzati nella base dati Oracle.

Riferimento: http://www.oracle.com/technetwork/database/appdev-with-soda-2606220.pdf

Modello relazionale VS. Modello No-SQL. Volendo comparare un database relazionale con un DB NoSQL “document-store”, è possibile dire che:

  • Una collezione di documenti è una tabella
  • Un documento è una riga di una tabella
  • Un campo del documento è una colonna della tabella

I documenti in formato JSON vengono memorizzati con un ID univoco all’interno di una collezione. Per ciascun documento è possibile recuperare metadati, come data di creazione, dati di aggiornamento, owner e versione del documento, ecc.

Le funzionalità offerte da un document store includono:

  • Creazione e cancellazione di una collezione
  • Creazione, ricerca, aggiornamento o cancellazione di un singolo documento in base al suo ID
  • Recupero dei documenti in una collezione
  • Ricerca di una collezione, tipicamente utilizzando Query By Example (QBE) metaphor
  • Creazione e cancellazione di indici

Dato questo semplice livello di funzionalità fornito da un document store, l’API diventa semplice, particolarmente quando comparato con le tradizionali API SQL-based come JDBC.

Il DBMS Oracle già forniva dalla versione 9 il supporto alla memorizzazione, alla ricerca e all’indicizzazione di documenti XML. Oracle Database 12c estende tale funzionalità ai documenti JSON, introducendo le due implementazioni dell’interfaccia SODA, denominate, come suddetto, SODA for REST e SODA for JAVA, e ponendosi sul mercato come valida alternativa tra i NoSQL-style Document Store.

Oracle NoSQL-style Document Store Capabilities. In Oracle DB 12c, i documenti vengono memorizzati, indicizzati e ricercati senza che il database ne conosca la struttura (schemaless). Ciò lascia agli sviluppatori la libertà di modificare la struttura dei documenti JSON in base alle esigenze. Non esiste un datatype dedicato per memorizzare i documenti JSON, ma gli stessi vengono memorizzati con i tipi standard VARCHAR2, CLOB e BLOB. Viene introdotto il nuovo constraint “IS JSON”, utilizzato per assicurare che il contenuto di una colonna sia un JSON valido, fornendo pieno supporto al trattamento avanzato dei JSON, come disaster recovery, replication, compression ed encryption.

Inoltre, è possibile eseguire delle query SQL direttamente sulle tabelle di documenti JSON del database utilizzando le JSON Path Expressions. Tali espressioni sono equivalenti al linguaggio xPath in XML e sono sintatticamente simili a JavaScript. Si riportano di seguito degli esempi:

JsonPathExpressions.png

SODA API. SODA fornisce un set di API semplice da utilizzare per lavorare con i documenti memorizzati in un Oracle Database. L’oggetto Database, che è richiesto per interagire con le Collections, viene istanziato usando un database connection con le API SQL standard di Oracle. La versione corrente di SODA adotta una strategia di optimistic locking, ma quella di pessimistic locking èsarà probabilmente disponibile nelle future release.

La specifica SODA definisce un set di metodi che forniscono le seguenti funzionalità:

  • Stabilire una connessione ad un Oracle Database Document Store
  • Creare e cancellare una collezione
  • Creare, ricerca, aggiornare e cancellare un documento
  • Elencare i contenuti di una collezione
  • Ricercare una collezione di documenti che “matchino” una espressione Query By Example (QBE)
  • Operazioni di “bulk insert” in una collezione
  • Creazione e cancellazione di indici

Di seguito, riporto alcune caratteristiche dell’implementazione “SODA for JAVA”, tralasciando “SODA for REST” (utile nel caso ci si voglia interfacciare direttamente con il Document Store con il paradigma REST).

SODA for JAVA. Consiste di un set di semplici classi che rappresentano un database, una collezione di documenti e il documento stesso. I metodi che queste classi forniscono permettono di gestire e ricercare le collezioni e i documenti JSON memorizzati. Utilizza una connessione JDBC standard e SQL*NET per comunicare con il database: ciò significa che le API sono transazionali e una serie di operazioni SODA può generare una singola transazione. Poiché SODA utilizza una connessione JDBC, è possibile utilizzare sia le API di SODA for JAVA che quelle tradizionali JDBC.

Di seguito, si riportano le principali classi di “SODA for JAVA” con relativa descrizione:

Classe Descrizione Commenti
OracleClient Classe client generica SODA. L’entry point di SODA per i JSON.
OracleRDBMSClient La classe Client dell’Oracle Database Usata per recuperare l’oggetto OracleDatabase
OracleDatabase Rappresenta un Document Store, il quale consiste di uno o più collezioni. Usato per accedere alle collezioni.
OracleDatabaseAdmin Usato per creare e cancellare collezioni
OracleCollection Rappresenta una collezione di un Document Store
OracleCollectionAdmin Usato per creare e cancellare indici
OracleDocument Rappresenta un documento in un Document Store Aggiorna (o crea) il documento con un dato ID

Struttura di un documento di una collezione. Di seguito, si riporta la struttura SQL di una collezione rappresentata su una tabella Oracle e contenente il JSON in corrispondenza di una colonna CLOB:

Name                                             Null?   Type

—————————————– ——– —————————-

ID                                              NOT NULL VARCHAR2(255)

CREATED_ON                                      NOT NULL TIMESTAMP(6)

LAST_MODIFIED                                   NOT NULL TIMESTAMP(6)

VERSION                                         NOT NULL VARCHAR2(255)

JSON_DOCUMENT                                     CLOB

Le colonne della tabella rappresentano quanto segue:

 ID ID autogenerato del singolo record
 JSON_DOCUMENT Contenuto del documento in JSON
 CREATED_ON Timestamp (autogenerato) di inserimento del record
 LAST_MODIFIED Timestamp (autogenerato) di modifica del record
 VERSION Versione del documento (incrementato automaticamente quando viene modificato)

Per dettagli sulle API di SODA e sulla potenza espressiva delle Query By Example per la ricerca dei documenti di una collezione: http://docs.oracle.com/cd/E63251_01/doc.12/e58124/soda.htm#ADSDA107

Memorizzazione dei documenti JSON (codifica e datatype). Un documento JSON può essere considerato un dato semi-strutturato, ossia non conforme alla struttura formale dei modelli di dato associato con le basi di dati relazionali. Esso, comunque, contiene etichette o altri marcatori per separare gli elementi semantici e rafforzare le gerarchie di record e campi all’interno del dato. E’ anche conosciuto come “dato senza schema” o “dato con struttura autodescritta”.

Oracle raccomanda di memorizzare tali dati utilizzando datatype di tipo LOB, in quanto la quantità di caratteri può essere elevata (maggiore di 4000 byte e, dunque, della massima capacità di un datatype VARCHAR2). I datatype raccomandati per i contenuti testuali sono Characted Large Object (CLOB) e National Character Large Object (NCLOB).

Il datatype CLOB è raccomandato per la memorizzazione di stringhe o documenti di lunghezza fissa. Invece, il datatype NCLOB è raccomandato per quelli a lunghezza variabile.

Riferimento: https://docs.oracle.com/database/121/ADXDB/json.htm#ADXDB6252

Per quanto riguarda il character encoding, conviene adottare quello AL16UTF16 o AL32UTF8. In particolare, Oracle raccomanda l’uso di AL32UTF8 per memorizzare i dati con caratteri Unicode.

Riferimenti:
https://docs.oracle.com/cd/E11882_01/appdev.112/e18294.pdf
https://docs.oracle.com/database/121/NLSPG/ch2charset.htm#NLSPG179

Sicurezza dei dati. Al fine di salvaguardare la sicurezza e l’integrità dei dati,è possibile sfruttare il meccanismo di Oracle Secure Files, il quale consente anche le compressione dei dati memorizzati all’interno di datatype LOB.

Riferimento: https://docs.oracle.com/database/121/ADLOB/toc.htm

[NO-SQL] Appunti su analisi di performance e comparazione dei database NoSQL

Continuando la trattazione dell’argomento dei Database No-SQL, viste le impressioni e segnalazioni via email dei visitatori di questo blog, condivido un pò di appunti in un documento che potete scaricare qui di seguito:

Database NoSQL-Comparazione tecnologie

Il documento raccoglie le considerazioni e le valutazioni oggettive emerse durante la lettura di articoli e documentazioni online sull’argomento dei DB No-SQL. Nello specifico, l’oggetto di studio è stato MongoDB, confrontandolo con altre soluzioni (relazionali e non) e, in particolare, è stata approfondito il suo possibile utilizzo per la gestione di una struttura a grafo.

NoSQL Model

Ecco l’indice dei paragrafi del documento, sperando vi possa essere utile per spunti o per far nascere riflessioni/discussioni sull’argomento:

  1. I database NoSQL
    1. Perché NoSQL? Il teorema di CAP e il No-SQL data model
    2. Un confronto tra le famiglie di DB NoSQL
    3. I database document-oriented e graph-oriented
  2. Breve introduzione su MongoDB
    1. Principali caratteristiche di MongoDB
    2. Comparazione tra MongoDB e MySQL
    3. Ambiti di utilizzo e realizzazione dei direct graph con MongoDB
    4. Soluzioni ibride: MongoDB + database a grafo + RDF triple store
    5. Analisi delle prestazioni di MongoDB all’aumentare dei documenti memorizzati
  3. Confronto tra le performance di MongoDB e di altri database NoSQL
    1. Confronto MongoDB con vari database NoSQL
    2. Confronto HBase e MongoDB
  4. Analisi di performance dei Graph Database
    1. Elenco e caratteristiche di varie implementazioni di Graph Database
    2. Analisi e confronto delle performance di varie implementazioni di Graph Database
    3. Scalabilità
Database NoSQL-Comparazione tecnologie
Titolo: Database NoSQL-Comparazione tecnologie (0 click)
Etichetta:
Filename: database-nosql-comparazione-tecnologie.pdf
Dimensione: 770 kB

[NO-SQL] Not Only SQL: una panoramica sui database NoSQL

NoSQL vs RelIn precedenti articoli su questo blog, si è già accennato al movimento NoSQL (Not Only SQL) e ad una delle sue tecnologie, MongoDB:

Ebbene, da allora (pochi mesi), le tecnologie sono aumentate e l’interesse verso questo modello di dati è esploso, di pari passo alla tematica del Big Data che sta diventando molto di moda nell’ultimo periodo (molti ne parlano, ma chi davvero lo fa???).

Ecco le keywork che riassumono le peculiarità dei DB NoSQL:

  • non-relational: le struttura di memorizzazione dei dati è differente dal modello relazionale. L’approccio a “schema rigido” dei db relazionali non permette di memorizzare dati fortemente dinamici. I db NoSQL sono “schemaless” e consentono di memorizzare “on the fly” attributi, anche senza averli definiti a priori
  • distributed: la flessibilità nella clusterizzazione e nella replicazione dei dati permette di distribuire su più nodi lo storage (e il calcolo), in modo da realizzare potenti sistemi faulttolerance
  • open-source: alla base del movimento NoSQL vi è la filosofia “open-source”, fondamentale per contribuire ad accrescere le potenzialità delle sue tecnologie
  • horizontally scalable: architetture enormemente scalabili, che consentono di memorizzare e gestire una grande quantità di informazioni

Al seguente link, trovate una lista aggiornata dei database NoSQL che rispettano i requisiti su citati: http://nosql-databases.org

Un whitepaper sulla tecnologia dei DB NoSQL l’ho trovato sul sito di CouchBase (un altro DB NoSql document-oriented): NoSQL Database Technology

E ancora, “10 cosa da sapere sui DB NoSQL”: 10 things you should know about NoSQL databases

Essi sono suddivisi nelle seguenti famiglie:

  • Wide Column Store / Column Families

  • Document Store

  • Key Value / Tuple Store

  • Graph Databases

  • Multimodel Databases

  • Object Databases

  • Grid & Cloud Database Solutions

  • XML Databases

  • Multidimensional Databases

  • Multivalue Database

databaseNoSQL

Dal precedente grafico, si possono fare delle considerazioni. Un parametro di valutazione è l’operational complexity: la struttura di memorizzazione dei DB a grafo è particolarmente complessa e anche gli algoritmi che ne permettono la navigazione (traversal) sono i classici algoritmi di routing, di una certa complessità computazione. Ovvio che all’aumentare della complessità nella struttura dati, diminuisce la capacità di memorizzazione dei dati stessi (parametro size). La famiglia dei DB a grafo (graph databases), come NEO4J e OrientDB, dispone di routine di accesso ai dati particolarmente performanti, ma non possono trattare troppi dati – [per una introduzione ben fatta sui database a grafo, eccovi un buon riferimento: Graph Databases An Overview].

Al contrario, la famiglia dei DB a chiave-valore (key-value databases), come Redis, è particolarmente consigliata per memorizzare e gestire grosse quantità di dati. La famiglia dei DB a documenti (document databases), come MongoDB, si trovano in una posizione intermedia.

Un plauso va a due sviluppatori italiani che hanno sviluppato i più utilizzati DB NoSQL del momento:

Un sondaggio aperto agli utilizzatori (previa registrazione) sui vari DB (sia relazionali che non) e che vi permette di comparare le varie caratteristiche, lo trovate a questo link (potete inserire più colonne per confrontare più tecnologie tra loro): http://vschart.com/compare/mongodb/vs/redis-database

Ho cercato online una tesi di laurea in cui poter trovare un benchmark sui DB NoSQL e ho trovato quella ben fatta su Analisi delle performance dei database non relazionali: il caso di studio di MongoDB dell’Università di Padova, dove si compara MongoDB col db relazionale più diffuso, MySQL.

Eccovi un articolo di comparazione tra i principali DB delle famiglie elencate:

Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Couchbase vs Neo4j vs Hypertable vs ElasticSearch vs Accumulo vs VoltDB vs Scalaris comparison

E ancora, un confronto tra alcuni DB NoSQL, dove Cassandra e HBase vincono sul throughput: A vendor-independent comparison of NoSQL databases: Cassandra, HBase, MongoDB, Riak.

Origin of NoSQL

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2013/02/07/no-sql-not-only-sql/.

[BigData] Il Big Data Forum 2012 a Roma: le soluzioni ICT per un vantaggio competitivo

Il 21 Novembre scorso si è tenuta a Roma la 2° edizione del Big Data Forum, dallo slogan “Big Data Forum 2012: per fare chiarezza sul fenomeno dell’esplosione dei dati e scoprire le soluzioni ICT che consentono di trasformarlo in vantaggio competitivo“.

L’evento, pubblicizzato da ICT4Executive, con partner di eccezione come Microsoft, Oracle e Informatica Software, è stato condotto da relatori di riguardo, particolarmente distinti sia nel campo della ricerca ICT (in particolare, nella Business Intelligence), che in quello strategico aziendale.

Ho partecipato all’evento e vi riporto un resoconto dettagliato delle tematiche affrontate ed estrapolate dagli interventi dei relatori presenti.

 

La Big Data Analysis

Il moderatore Carlo Vercellis, responsabile dell’Osservatorio di Business Intelligence & Big Data Analytics e professore alla School Management del Politecnico di Milano, ha sottolineato che il BigData è un tema di attualità molto in voga nell’ultimo periodo, come il cloud computing del resto, ma che da fenomeno del momento deve trasformarsi in innovazione tecnologica, in grado di cambiare gli attuali schemi e paradigmi del modo di trattare le informazioni su Internet.
Come non citare lo slogan di Tim Berners-LeeROW DATA, NOW!“. Dati grezzi da trattare, che sono diventati (e diventeranno ancora) troppi e dai cui è difficile poter estrarre informazione. Un fenomeno di cui si vocifera particolarmente nell’ultimo periodo, visti gli impegni delle varie iniziative di Open Data e eGov, che “impongono” ai detentori illegittimi di dati (ndr. come pubbliche amministrazioni) di distribuire informazioni di proprietà dei cittadini.

 

I dati diventano “interessanti” solo se siamo capaci di estrarre da essi un contenuto utile, da trasformare in servizio per gli utenti finali.

 

Continua la lettura

[NO-SQL] Il Teorema di CAP e il No-SQL data model

Volendo continuare la serie sulla “filosofia” NO-SQL e sulle prerogative per cui è necessaria (vedi l’articolo riportato su questo blog, “NO-SQL e introduzione a MongoDB“), estrapolo qui le motivazioni e le caratteristiche lette negli articoli riportati su BigDataNERD:

Perché NO-SQL?

Per poter rispondere alla domanda occorre esaminare il “teorema di CAP” e ricordare che un concetto fondamentale degli RDBMS è quello delle “ACID transactions” (A=Atomicity, C=Consistency, I=Isolation, D=Durability)

  • A come Atomicità. La transazione è indivisibile, ossia o tutti gli statements che la compongono vengono applicati ad un database o nessuno.
  • C come Consistenza. Il database deve rimanere in uno stato consistente prima e dopo l’esecuzione di una transazione, quindi non devono verificarsi contraddizioni (inconsistency) tra i dati archiviati nel DB.
  • I come Isolamento. Quando transazioni multiple vengono eseguite da uno o più utenti simultaneamente, una transazione non vede gli effetti delle altre transazioni concorrenti.
  • D come Durabilità. Quando una transazione è stata completata (con un commit), i suoi cambiamenti diventano persistenti, ossia non vengono più persi.

I più comuni e diffusi RDBMS supportano le transazioni ACID e i principi su esposti sembrerebbero bastare. Ma dov’è il problema?

Nell’era del Web 2.0, le applicazioni devono lavorare su bilioni e trilioni di dati ogni giorno e la scalabilità è un concetto che in tale ambito ricopre un ruolo importantissimo. Per questo motivo i database hanno bisogno di essere distribuiti sulla rete per realizzare una scalabilità orizzontale. Esaminiamo qui il concetto di “CAP theorem” per valutare le caratteristiche di un siffatto sistema di storage distribuito dei dati.

Il teorema di CAP fu teorizzato da Eric Brewer nel 2000 (C=Consistency, A=Availability, P=Partition-Tolerance). Per maggiori informazioni si veda il seguente articolo: ACID vs. BASE il Teorema di CAP (di Stefano Pedone).

Nell’ambito di un sistema di storage distribuito, i 3 principi hanno la seguente definizione:

Consistency: se viene scritto un dato in un nodo e viene letto da un altro nodo in un sistema distribuito, il sistema ritornerà l’ultimo valore scritto (quello consistente).

Availability: Ogni nodo di un sistema distribuito deve sempre rispondere ad una query a meno che non sia indisponibile.

Partition-Tolerance: è la capacità di un sistema di essere tollerante ad una aggiunta o una rimozione di un nodo nel sistema distribuito (partizionamento) o alla perdita di messaggi sulla rete.

Secondo la teoria CAP, è impossibile garantire tutti e tre i principi del teorema di CAP. Infatti, si consideri un sistema distribuito e si supponga di aggiornare un dato su un nodo 1 e di leggerlo da un nodo 2, si verificheranno le seguenti conseguenze:

  1. Il nodo 2 deve ritornare l’ultima “miglior” versione del dato (quella consistente) per non violare il principio della Consistenza
  2. Si potrebbe attendere la propagazione del dato modificato nel nodo 2 e, quest’ultimo, potrebbe mettersi in attesa della versione più aggiornata, ma, in un sistema distribuito, si ha un’alta possibilità di perdita del messaggio di aggiornamento e il nodo 2 potrebbe attenderlo a lungo. Così non risponderebbe alle query (indisponibilità), violando il principio dell’Availability
  3. Se volessimo garantire sia la Consistency che l’Availability, non dovremmo partizionare la rete, violando il principio del Partition-Tolerance

Le web applications progettate in ottica Web 2.0, caratterizzate da architetture altamente scalabili e profondamente distribuite con politiche di prossimità geografica, puntano in maniera forte sulla garanzia di alte prestazioni ed estrema disponibilità dei dati. Si trovano quindi ad essere altamente scalabili e partizionate. La filosofia NO-SQL è sbilanciata verso la ridondanza dei nodi e la scalabilità.

Di seguito, si riporta una tabella dei maggiori database NO-SQL del momento:

Il NoSQL data model può essere implementato seguendo differenti approcci a seconda delle strutture dati con cui si rappresentano i record di dato.

  • Famiglie di colonne o “wide column store” (come Cassandra e HBase): le informazioni sono memorizzate in colonne, in coppie chiave/valore. Tipicamente sono usati nell’ambito della memorizzazione distribuita dei dati;
  • Document Store (come CouchDB, MongoDB): le informazioni sono organizzate in “Document“, rappresentati in XML, JSON o BSON, e l’accesso ai dati avviene attraverso API che interrogano veri e propri dizionari. Sono molto usati nello sviluppo di attuali web applications;
  • Key/Value Store (come Membase, Redis): la struttura dati di memorizzazione è una Hash Table (coppia chiave-valore). Indicate per sistemi di caching o Hash Table distribuite;
  • Graph Data Store (come Neo4J, InfoGrid, OrientDB). Il modello di programmazione è il grafo e l’accesso ad archi e nodi avviene attraverso algoritmi di ricerca su grafo. Tipicamente si usano nei social network.

 

[DB] Perché denormalizzare una basedati?

Prima di parlare della denormalizzazione di una basedati, ricordiamo cos’è la sua normalizzazione: è il procedimento che ha come conseguenza la riduzione della ridondanza all’interno del database, e che quindi consente un risparmio in termini di spazio occupato. Tale operazione andrebbe eseguita in fase di progettazione, riuscendo quindi subito ad identificare i dati raggruppabili in tabelle separate da mettere in relazione. Effettuare subito questo procedimento porta anche ad una migliore comprensione del database e dei legami che intercorrono tra le varie tabelle.

Ci sono tre diverse forme di normalizzazione (dette forme normali di Boyce e Codd):

  • la 1° Forma Normale (1NF) consiste nel fare in modo di non presentare gruppi di attributi che si ripetono (ossia ciascun attributo è definito su un dominio con valori atomici) e nel far esistere una chiave primaria per ciascuna relazione (ossia esiste un insieme di attributi, che identifica in modo univoco ogni tupla della relazione)
  • una volta portato il database alla 1° Forma Normale, dobbiamo portarlo alla 2° Forma Normale (2NF), ossia per ogni relazione tutti i campi non chiave dipendono funzionalmente dall’intera chiave composta e non da una parte di essa.
  • la 3° Forma Normale (3NF) si ha quando la relazione è, innanzitutto, in 2° forma normale e tutti gli attributi non-chiave dipendono dalla chiave soltanto, ossia non esistono attributi che dipendono da altri attributi non-chiave.

Per definizione, una relazione R è in forma normale di Boyce e Codd (BCNF) se e solo se è in 3NF e, per ogni dipendenza funzionale non banale X –> Y,  dove X è una superchiave per R.

In questo modo si riducono ulteriormente sia la ridondanza dei dati nelle tabelle che la possibilità di errori umani in fase di inserimento dei dati.

La denormalizzazione, invece, è il processo che permette di ottimizzare le performance in lettura di un database aggiungendo ridondanza nei dati o raggruppandoli. Tale operazione viene effettuata spesso per risolvere l’inefficienza dei database relazionali, visto che, se normalizzati, possono soffrire di pesantezza nel caricamento dei dati.

Quando si valuta la normalizzazione tra le alternative di progettazione di una basedati, è utile tenere presente le diverse tecniche che consentono di denormalizzare intenzionalmente un database. La denormalizzazione intenzionale dei dati può essere motivata dal rilevamento di problemi di prestazioni oppure nel caso in cui si desideri semplificare la creazione di report ad-hoc. I problemi di prestazioni derivano dalle query per le quali, in produzione, è richiesto un numero troppo elevato di join di tabelle con un accesso intensivo al disco. Lo scopo della creazione di report ad-hoc è consentire anche agli utenti finali di eseguire query non strutturate, in quanto è possibile che utenti finali poco esperti non siano certi delle procedure necessarie per ottenere informazioni da più tabelle correlate.

Continua la lettura

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2012/06/07/db-perche-denormalizzare-una-basedati/.