Tipi di Database

• Database "Legacy": sono modelli, ormai rietenuti obsoleti, ma in certi casi ancora usati.

  • Modello Gerarchico: è particolarmente adatto per rappresentare situazioni nelle quali è possibile fornire all’insieme dei dati una struttura nella quale ci sono entità che stanno in alto ed entità che stanno in basso, secondo uno schema ad albero, nel quale i nodi rappresentano le entità e gli archi rappresentano le associazioni. Nella pratica l’entità è un file, l’istanza è un record e gli attributi sono i campi del record. è particolarmente adatto a rappresentare le associazioni 1:N. Soffre però di problemi nelle associazioni N:1 o N:N in quanto bisogna duplicare i dati. Presenta dei limiti soprattutto nella rigidità della struttura di dati creata, che talvolta non riesce ad evitare ridondanze dei dati.

  • Modello Reticolare: In questo modello le entità rappresentano i nodi e le associazioni rappresentano gli archi di uno schema a grafo orientato: si tratta cioè di una estensione del modello gerarchico. Non esiste quindi una gerarchia predefinita tra le entità, un record figlio può avere un numero qualsiasi di padri: in questo modo vengono evitate situazioni di ripetizione di dati uguali. Risulta però più difficile l’implementazione e la costruzione del software applicativo. Ha avuto una discreta diffusione negli anni ’70 soprattutto nei sistemi di grandi dimensioni.

• Il modello relazionale rappresenta il database come un insieme di tabelle. Esso viene considerato attualmente il modello più semplice ed efficace, perché è più vicino al modo consueto di pensare i dati, e si adatta in modo naturale alla classificazione e alla strutturazione dei dati. Il modello relazionale nasce nel 1970, proposto da Edward F. Codd, ricercatore dell’IBM come idea di un modello logico molto semplice e nello stesso tempo in grado di superare i limiti degli altri modelli utilizzati. Entra a far parte di sistemi commerciali a partire dal 1978. Esso si basa su alcuni concetti fondamentali tipicamente matematici e assegna grande importanza all’uso rigoroso del linguaggio matematico, con due obiettivi importanti:

  • utilizzare un linguaggio conosciuto a livello universale, qual è il linguaggio matematico (definito da E. Cood)
  • eliminare i problemi di ambiguità nella terminologia e nella simbologia

  Inoltre nei database di tipo relazionale dobbiamo sottolineare l’importanza dei Tipi di Relazione:

  • Relazione uno-a-uno (1:1): Sono corrispondenze biunivoche, ad ogni istanza della classe A ne corrisponde una della classe B e viceversa: ad un record di una prima tabella può corrispondere al più un record della seconda tabella e viceversa.

  • Relazione uno-a-molti (1:N): La corrispondenza diretta è multipla e in generale parziale (ad ogni istanza della classe A ne corrispondono zero, una o più della classe B) mentre l’associazione inversa è univoca e totale (ad ogni istanza della classe B ne corrisponde una ed una sola della classe A): ad un record di una prima tabella possono corrispondere uno o più record della seconda tabella.

  • Relazione molti-a-molti (M:N): La corrispondenza è multipla e parziale in entrambe le direzioni (ad ogni istanza della classe A ne corrispondono zero, una o più della classe B e viceversa): ad un record di una prima tabella possono corrispondere uno o più record della seconda tabella e viceversa. Nei database relazionali per far ciò è necessaria una tabella ponte.

  È possibile anche associare un’entità con sé stessa (associazione ricorsiva).

  I database di tipo relazionale gestiscono in maniera "nativa" solamente le assosciazioni 1:N. Nelle associazioni 1:1 e/o N:N si effettuano opportune "implosioni"/"esplosioni" delle relazioni.

• I database post relazionali rappresentano il futuro dei database. Il modello relazionale è potente, flessibile e assai diffuso, ma ha dei limiti, soprattutto quando è necessario trattare moli enormi di dati o quando è difficile strutturare a priori il dato nelle entità del database. Tra questi troviamo:

  • Database (realazionali) dimensionali: basati sui database di tipo relazionale, ma che rappresentano meglio la relazione molti-a-molti. Spesso sono delle estensioni dei database di tipo relazionale.
  • Database (relazionali) ad oggetti: basati sui database relazionali, ma supportano tipi di dato complessi con sottoattributi. Spesso sono delle estensioni dei database di tipo relazionale.
  • Key-Valued Stores: Questa categoria di database consente di memorizzare e recuperare in maniera rapidissima coppie di chiave e valore. Questi database sono i più facili da implementare grazie alla loro struttura semplice e sono anche i più performanti quando la priorità sono le prestazioni in scrittura (salvataggio rapido di dati). Inoltre, sono chiaramente i più adatti quando l’accesso ai dati si basa sulle chiavi.
  • Column Family Stores: Questa famiglia di database memorizza i dati ottimizzati per la ricerca su colonne e sono progettati per gestire enormi quantità di dati distribuiti su più server. Trovano la loro migliore applicazione quando è necessario distribuire e recuperare i dati sa più server.
  • Document Databases: Questa famiglia di database gestisce i dati in un formato documentale semi-strutturato. In questo caso ogni record può avere una struttura diversa, l’onere di conoscere la struttura del dato, in questo caso, è delegato all’applicazione e non al database. I dati possono essere rappresentati in formato JSON e possono contenere sotto documenti. Questo tipo di database è indicato quando si devono salvare dati che non hanno sempre la stessa struttura o oggetti provenienti da applicazioni; inoltre, forniscono funzionalità di alta affidabilità, Sharding indicizzazione, gestione di dati geo spaziali, etc.
  • Graph Databases: Un database a grafo che utilizza nodi e archi per archiviare le informazioni. Il loro utilizzo principale è rappresentato dalla gestione delle relazioni tra molti oggetti.

  Spesso questi tipi di database di nuova generazione vengono associati al termine "NoSQL". sta per “Not Only SQL” e questo sottolinea che la tecnologia NoSQL non è del tutto incompatibile con SQL (Structured Query Language), anzi, in alcuni casi è possibile utilizzare lo stesso linguaggio SQL per interrogare i database NoSQL, seppure con alcune importanti limitazioni come le JOIN.