Si supponga di avere il database relazionale BLOG costituito dalle tabelle AUTORI, ARTICOLI, COMMENTI e CATEGORIE. Definiamo le seguenti relazioni:
AUTORI -> ARTICOLI (1 a molti) | Un autore può scrivere più articolo, ma un articolo è scritto da un solo autore |
ARTICOLI -> COMMENTI (1 a molti) | Un articolo contiene più commenti, ma un commento riguarda un solo articolo |
ARTICOLI -> CATEGORIE (molti a molti) | Un articolo può appartenere a più categorie e ad una categoria possono appartenere più articoli |
Pertanto avremo:
Mentre lo schema relazionale sarà il seguente:
AUTORI(autore_ID, username, password)
ARTICOLI(articolo_ID, titolo, testo, data, autore_ID)
COMMENTI(commento_id, nome, testo, email, articolo_ID)
CATEGORIE(categoria_ID, descrizione)
ART_CATEG(articolo_ID, categoria_ID)
In grassetto la chiave primaria e la sottolineatura per la chiave esterna!!!
Per visualizzare la pagina di un articolo con tutte le sue informazioni avremo bisogno dell’accesso all’articolo, al nome dell’autore, ai commenti e alle categorie di appartenenza con il coinvolgimento della tabella ART_TAG, quindi avrò bisogno di tutte e cinque le tabelle.
Ora vediamo come lo stesso database viene gestito nel database orientato a documenti con particolare riferimento a mongodb. Avremo bisogno di una collection siffatta:
Collection ARTICOLI
{ titolo:”Il database noSQL”, testo:”Il database NoSQL sono appositamente realizzati per modelli di dati specifici e hanno schemi flessibili per creare applicazioni moderne. …”, data: Date(), autore:”Rossi Mario”, commenti: [{nome:”Bianchi Ada”, testo:”Un articolo davvero interessante. Complimenti”, email:”adabianchi@blaisepascal.it”}, {nome:”Neri Aldo”, testo:”Trovo l’articolo privo di documentazione adegua”, email:”aldoneri@blaisepascal.it”} ], categorie:[“database”, “nosql”, “mongodb”] } |
e di un’altra collection
Collection AUTORI
{
_id:”Rossi Mario,
username:”mariorossi”,
password:”issoroiram” }
Ci chiediamo a quante collection dovrò accedere per la visualizzazione di una pagina di un singolo articolo?
La risposta è una sola collection!
Dunque come abbiamo visto mancano le join e le transaction.
Attraverso la figura seguente osserviamo la definizione di transaction e le operazioni di commit e rollback
Vediamo in questa slide come cambia il modo di pensare da un modello di database relazionale a un modello di database orientato a documenti.