Archivi categoria: dati e DBMS

Progettare database NoSQL

La progettazione dei DB relazionali segue tecniche consolidate, che bilanciano criteri di efficienza e manutenibilità / evoluzione nel tempo.

Al contrario, la progettazione dei database NoSQL viene perlopiù effettuata puntando unicamente sulle prestazioni. Ma si possono adottare correttivi per migliorare anche la gestione aziendale dei database NoSQL, argomenta Jack Vaughan in “New thinking needed in IT to make NoSQL data modeling process work“.

Modello di dominio

Il modello di dominio consiste nella definizione dei concetti propri di un ambito applicativo, e delle loro associazioni.

Se descriviamo un sistema di formazione, saranno concetti come Scuola, Classe, Materia, Insegnante, Allievo. Nella telefonia, saranno concetti come Chiamante, Destinatario, Chiamata, Operatore. In banca, Cliente, Conto, Movimento, Mutuo. Nessun aspetto tecnologico, solo concetti usati da chi opera nell’ambito della materia di riferimento.

La definizione di questi concetti è un aspetto cruciale di ogni progettazione. Prendiamo ad esempio l’ambito editoriale. Cos’è un libro? Cosa si intende per libro?

Il concetto di “libro” può corrispondere a diverse cose, ad esempio a:

  • “Promessi sposi” di Alessandro Manzoni (l’opera in sé, indipendentemente dalle diverse edizioni in cui è stata pubblicata, dal 1840 ad oggi)
  • “Promessi sposi” di Manzoni, Garzanti, I grandi libri, 2002 (una specifica edizione)
  • una copia fisica dell’edizione Garzanti 2002 dei “Promessi sposi”

Tre cose diverse, con ambiguità da chiarire il prima possibile, per progettare, implementare e verificare la correttezza delle funzioni di un sistema in modo da soddisfare i requisiti degli utenti.

La tecnica tradizionale per la definizione del modello di dominio è l’Entity-Relationship (Entità Relazioni) di Peter Chen, proposta negli anni ‘70 per la progettazione logica delle basi dati. Con la diffusione dell’approccio object oriented, la modellazione dei concetti del dominio è poi arrivata a includere anche la dimensione funzionale associata ai concetti, oltre alla parte relativa agli attributi.

Comunque intesa, la modellazione del dominio basata sul significato dei concetti implica una conoscenza approfondita della materia, e costituisce la base per una migliore definizione delle funzioni applicative.

Un modello di dominio efficace può anche migliorare la qualità della collaborazione tra esperti della materia, analisti applicativi e sviluppatori, attraverso la condivisione di conoscenza sui concetti e sul loro significato, con riferimento ad un vocabolario e a delle regole di integrità condivise. E può ridurre notevolmente i rischi di progetto.

No DBA

In molte organizzazioni la progettazione delle basi dati è un’attività centralizzata, delegata ad un ruolo distinto dai gruppi di sviluppo, la Data Base Administration (DBA).
Le ragioni sono due: favorire una migliore integrazione dei dati tra i diversi sistemi che vi accedono, e usare al meglio competenze specialistiche particolari, come quelle necessarie per ottimizzare le prestazioni negli accessi.

A volte, purtroppo, la DBA centralizzata diventa un collo di bottiglia, e ricorrere ai servizi che offre crea impedimenti e ritardi ai progetti.

Martin Fowler, nell’articolo No DBA, rileva che questi impedimenti possono portare in alcuni casi i gruppi di sviluppo alla scelta di non usare i DBMS relazionali, gestiti dalla DBA, sostituendoli con altri tipi di tecnologia, come i DBMS NoSQL, che invece la DBA non presidia e che vengono gestiti direttamente dai progetti. E che ciò accade anche quando per le caratteristiche dei progetti un DBMS relazionale andrebbe meglio.

Software Engineering Radio

Software Engineering Radio. The Podcast for Professional Software Developers.

Interviste mensili sui temi dello sviluppo software, scaricabili come podcast.

Creato e gestito a partire dal 2006 da Markus Voelter, dall’inizio del 2012 è condotto in associazione con la rivista bimestrale IEEE Software.

Gli episodi sono spesso interessanti, come ad esempio l’intervista a Martin Fowler e a Pramod Sadalage su “Agile Database Development”.