Ho pubblicato un nuovo video di introduzione a Entity-Relationship (ER), la tecnica più diffusa per la modellazione dati – Data Modeling:
Il video è un estratto dal corso Data Modeling in auto-istruzione: https://corsi.analisi-disegno.com/corsi/data-modeling/
A porsi le domande necessarie per capire le esigenze e individuare possibili soluzioni.
La prestigiosa Accademia della Crusca prende posizione su come tradurre (o non tradurre) il termine database in italiano.
Le forme preferite in italiano? Secondo l’uso corrente, riscontrato su Google, sono “database” (non tradotto) e “banca dati”.
Qui l’articolo: http://www.accademiadellacrusca.it/it/lingua-italiana/consulenza-linguistica/domande-risposte/database-questione-cos-semplice-cos-complica
Charlie Bachman, “padre dei database” e Turing Award 1973, è mancato a giugno.
Lo ricorda un articolo su Communications of the ACM, September 2017: https://cacm.acm.org/magazines/2017/9/220433-charles-w-bachman/fulltext
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“.
IEEE Computer di giugno 2013 ha una serie di articoli sulle opportunità ed i rischi relativi a Big Data, cioè alla enorme quantità di informazioni (in diversi formati) oggi disponibile agli individui, alle aziende ed alle pubbliche amministrazioni. L’articolo introduttivo è accessibile gratuitamente.
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:
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.
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. 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”.
I punti chiave di NoSQL (le tecnologie che si allontanano dagli schemi relazionali per i database) in una sola pagina, a cura di Pramod Sadalage e Martin Fowler, tratta dal loro libro “NoSQL Distilled”.
La loro conclusione:
“Most applications, particularly nonstrategic ones, should stick with relational technology—at least until the NoSQL ecosystem becomes more mature.”