Ti senti sopraffatto dalla quantità di tempo che ti ci vorrà per imparare a diventare un progettista di database? Leggi le abilità e i talenti essenziali di cui avrai bisogno:non è così terribile!
Quando cammini per i corridoi del supermercato, con il carrello in una mano e la lista della spesa nell'altra, cosa stai pensando? Se sei come me, stai immaginando come migliorare l'organizzazione degli scaffali in modo che la tua spesa settimanale richieda meno tempo. O forse senti lo stesso desiderio di organizzare e strutturare le informazioni quando un amico ti mostra la sua vasta collezione di riviste. O forse colpisce quando gestisci le tue playlist per soddisfare meglio le tue preferenze. Se attraversi la vita pensando a come rappresentare la realtà in termini di entità, attributi e relazioni, allora la tua vocazione è quella di essere un modellatore di database.
Forse non sei così estremo, ma sei comunque attratto dall'idea di perseguire la progettazione di database come carriera. In ogni caso, dovrai padroneggiare alcune nuove abilità. Alcuni di loro sono puramente tecnici; puoi apprendere queste abilità studiando o leggendo e approfondirle attraverso esperienze lavorative. Altre abilità implicano conoscenze non tecniche che puoi apprendere attraverso corsi, articoli di blog o osservando gli altri.
Ecco un riepilogo delle conoscenze e delle competenze essenziali che ogni progettista di database deve possedere.
Necessità di progettisti di database con competenze specifiche
Le abilità difficili sono quelle che si acquisiscono con lo studio e si affinano con la pratica. Se puoi dimostrare con prove concrete di aver padroneggiato un'abilità difficile, significa che sei in grado di svolgere qualsiasi compito che lo implichi.
In termini di conoscenza dei database, le hard skills includono i fondamenti della teoria dei database e le varie tecniche utilizzate per applicare concetti teorici per risolvere problemi concreti. Diamo un'occhiata a ciascuna delle competenze difficili di cui hanno bisogno i progettisti di database.
Teoria dei database
La teoria dei database è piena di concetti astratti che possono essere difficili da capire se non sono associati a fatti della vita reale. Il modello relazionale, i domini, gli attributi, le relazioni e le relazioni, le chiavi primarie e esterne, l'integrità dell'entità, l'integrità referenziale e i vincoli di dominio sono solo alcuni esempi. Se aggiungi argomenti ancora più complessi (come l'algebra relazionale o il calcolo relazionale) potresti chiederti se non sarebbe meglio scegliere una carriera che si occupi di cose concrete come il giardinaggio o la cucina gourmet.
Niente panico. Una conoscenza approfondita della teoria dei database è importante se si prevede di insegnare alle classi universitarie o di inventare un nuovo modo di organizzare le informazioni. Ma per progettare database, devi solo padroneggiare i concetti teorici che si applicano alla risoluzione di problemi della vita reale. Il più importante, l'ABC della progettazione di database, è il modello relazionale.
Il modello relazionale
I professori universitari ti diranno che il modello relazionale è un meccanismo di organizzazione dei dati basato sulla teoria degli insiemi e sulla logica dei predicati. Ma questo non ti farà molto bene nel tuo lavoro quotidiano come modellatore di database. In pratica, devi sapere che il modello relazionale è un modo intuitivo e diretto di organizzare i dati sotto forma di tabelle – dette relazioni – che sono composte da righe (che sono anche chiamate tuple). Ogni tabella (o relazione) è definita dai suoi attributi (o colonne).
Concetti fondamentali del modello relazionale.
Tutte le relazioni devono avere uno o più attributi in sospeso che rappresentano un identificatore univoco per ciascuna tupla. Nello slang del database, questa è la chiave della tabella. Gli attributi non chiave dipendono dalla chiave, nel senso che ogni valore chiave determina un singolo valore possibile per ogni attributo.
Immagina una tabella di informazioni sul veicolo in cui la chiave è la targa. La targa determina gli attributi di ciascun veicolo (come produttore, modello, proprietario, ecc.), poiché le regole del dominio impediscono a due veicoli diversi di condividere la stessa targa.
Banche dati relazionali
I sistemi di gestione dei database relazionali (RDBMS) implementano il modello relazionale, rispettandone i principi. Offrono modi per recuperare informazioni tramite query e aggiornare le informazioni tramite transazioni. Affinché le informazioni in un database relazionale riflettano fatti e situazioni della vita reale, è possibile definire condizioni o vincoli specifici del dominio a cui si applica il database. Ad esempio, in una tabella che memorizza informazioni sugli studenti delle scuole, può essere imposto un vincolo affinché le date di nascita non consentano date future o date troppo lontane nel passato.
L'organizzazione delle tabelle in un database viene comunemente definita schema del database. Oltre alle tabelle, lo schema descrive in dettaglio i vincoli che coinvolgono coppie di tabelle denominate relazioni. Una relazione collega due tabelle imponendo il vincolo che i valori nel campo di una delle tabelle corrispondano ai valori nella chiave primaria dell'altra tabella.
Gli schemi di database sono generalmente rappresentati dal diagramma entità-relazione (ERD), uno strumento comune per qualsiasi progettista di database.
Un ERD che rappresenta un modello di dati del cliente.
Anomalie e normalizzazione
Tutti i concetti che abbiamo discusso finora sono abbastanza chiari, giusto? Ora possiamo parlare delle anomalie che si verificano nei database a causa di un design difettoso o inadeguato (cioè il database non riflette adeguatamente la realtà che sta cercando di rappresentare).
Le anomalie si verificano quando un'operazione di inserimento, aggiornamento o eliminazione genera incoerenze nei dati. Si supponga, ad esempio, di disporre di una tabella in cui archiviare i dati sulle vendite. Per ogni vendita (cioè in ogni record della tabella) viene registrato il nome e l'indirizzo dei clienti. L'anomalia è la seguente:
- Se l'indirizzo del cliente viene modificato in una delle vendite e
- Lo stesso cliente ha altre vendite,
- Le altre vendite avranno un indirizzo obsoleto.
Per evitare anomalie, è possibile applicare una tecnica di progettazione denominata normalizzazione del database. Ciò comporta la scomposizione di tabelle e colonne (ovvero suddividerle in parti più piccole) per evitare difetti di progettazione come:
- Colonne che contengono più di un'informazione (ad es. il numero ID di un articolo e il suo nome).
- Memorizzare le stesse informazioni più di una volta nella stessa tabella.
- Campi che dipendono da altri campi non chiave.
Tabella non normalizzata (a sinistra) e schema normalizzato (a destra).
Data Warehouse e denormalizzazione
Alcuni database vengono utilizzati per eseguire query su grandi volumi di informazioni anziché per l'elaborazione delle transazioni online (OLTP). Questi database sono chiamati data warehouse.
Le informazioni in un data warehouse non provengono da interfacce utente (es. immesse direttamente da un sistema di ordinazione e-commerce). Proviene da processi batch che raccolgono informazioni da diverse fonti, le elaborano, le puliscono e le archiviano in tabelle. Per questo motivo possiamo presumere che i data warehouse non siano esposti alle stesse anomalie dei database convenzionali.
Per questo motivo, i data warehouse non devono mantenere le stesse condizioni di normalizzazione di un database OLTP. D'altra parte, è più importante ottimizzare l'efficienza delle query nei data warehouse. Ecco perché la denormalizzazione viene applicata in un data warehouse; questa tecnica utilizza una certa ridondanza per semplificare le query ed evitare di ingombrare gli schemi con un numero eccessivo di tabelle.
Un tipico schema di data warehouse.
Big Data
Come il data warehousing, il concetto di Big Data si riferisce a repository che ospitano grandi quantità di dati. Tuttavia, c'è una differenza importante tra i due concetti. Un data warehouse è progettato per uno scopo specifico ed è finalizzato alla generazione di report il cui comportamento e formato sono noti in anticipo.
I Big Data, d'altra parte, mirano a raccogliere grandi volumi di dati generati ad alta velocità da diverse fonti, ad es. informazioni da social media, microtransazioni o sensori intelligenti. Questa enorme quantità di informazioni può essere utilizzata per l'esplorazione e l'analisi o per l'addestramento di modelli di machine learning.
Nella progettazione di database Big Data, l'economia dello spazio di archiviazione e il partizionamento dei dati (tra le altre cose) hanno la priorità per consentire il parallelismo e l'acquisizione dei dati in tempo reale. Inoltre, vengono utilizzati sistemi di database non relazionali o NoSQL, che offrono alternative migliori per la gestione di informazioni non strutturate.
Tecnologie come NoSQL e il concetto stesso di Big Data sono relativamente nuove rispetto ai database relazionali, che hanno già più di 40 anni. Ecco perché, come progettista di database, devi essere attento ai nuovi sviluppi in questo settore. Tieni presente che i Big Data sono anche grandi affari. Molte aziende vogliono assumere una posizione di primo piano e stanno sviluppando nuovi strumenti e tecnologie per farlo.
Amministrazione del database
Una volta che un database è attivo e funzionante, qualcuno deve occuparsi della sua gestione quotidiana. Ciò significa eseguire attività di routine in modo che il database non diventi mai un collo di bottiglia per le applicazioni che lo utilizzano. Le attività di amministrazione includono il mantenimento dei backup, il monitoraggio del consumo di spazio di archiviazione, il rilevamento di arresti anomali tra i processi e la risoluzione di problemi di dati che impediscono il normale funzionamento delle applicazioni.
La persona che ha le competenze nel database per occuparsi di queste attività è l'amministratore del database, o DBA, quando ce n'è uno. In organizzazioni molto piccole, o in ambienti di sviluppo in cui il funzionamento dei database non è fondamentale per l'azienda, la responsabilità della manutenzione del database può ricadere sul modellatore di database. Pertanto, dovresti avere alcune conoscenze che ti consentiranno di subentrare al DBA in determinate situazioni. Tuttavia, in nessun caso dovresti accettare la responsabilità di amministrare un database in un ambiente di produzione che supporta applicazioni aziendali o mission-critical .
Le attività di amministrazione variano notevolmente a seconda del sistema di database e dell'infrastruttura su cui è montato. Ad esempio, le attività di gestione dei database di Microsoft SQL Server sono molto diverse da quelle di gestione di database MySQL o Oracle. E gestire un server che hai in esecuzione localmente sul tuo notebook è molto diverso dalla gestione di uno che gira nel Cloud.
Non consiglio di dedicare molti sforzi all'apprendimento di come gestire un particolare server di database, dal momento che ti occuperai di database e ambienti molto diversi nel corso della tua carriera. Non ti farà molto bene specializzarti in uno solo.
Gestione della concorrenza e delle transazioni
L'accesso simultaneo a un database può causare problemi nelle applicazioni quando più utenti tentano di accedere alla stessa risorsa contemporaneamente. Potremmo pensare che, come designer, non siano affari nostri e che sia responsabilità del DBA affrontare questi problemi. Potremmo anche pensare che sia colpa dei programmatori che creano applicazioni che li consentono.
Tuttavia, i progettisti possono fare la loro parte per ridurre al minimo potenziali problemi di concorrenza progettando schemi che li evitino.
Molti problemi di concorrenza si verificano quando si eseguono transazioni lunghe e complesse su un database; durante l'elaborazione della transazione, le tabelle coinvolte vengono bloccate per altri processi che richiedono la lettura o la scrittura di informazioni. Per evitare questo tipo di problema, la cosa migliore che puoi fare è assicurarti che i tuoi progetti rispettino almeno fino alla terza forma normale. Quindi sarà responsabilità del programmatore pensare correttamente alle transazioni per evitare deadlock.
Ma puoi anche utilizzare strategie che evitano la concorrenza, come il partizionamento di schemi o il raggruppamento di tabelle in base alla funzione che ciascuno svolge.
Immaginiamo un database per un sito di e-commerce. È possibile inserire le tabelle dei dati anagrafici per prodotti, stock e prezzi in uno schema e ordini e vendite in un altro, insieme a visualizzazioni o repliche di sola lettura delle tabelle del primo schema. Questo aiuta a evitare errori durante l'esecuzione di transazioni che aggiornano i dati anagrafici.
Strumenti di progettazione del database
Se conosci il modello relazionale, i diagrammi entità-relazione e le tecniche di normalizzazione, puoi progettare database con nessun altro strumento che carta e matita. Tuttavia, le tue prestazioni saranno notevolmente migliorate se utilizzi uno strumento intelligente, in particolare uno in grado di automatizzare determinate attività di progettazione come il trasferimento o la modifica di oggetti in un diagramma, il rilevamento di errori di progettazione, la generazione di script SQL per creare o aggiornare un database e invertire- progettare un database esistente.
Padroneggiare uno strumento specializzato come la piattaforma Vertabelo ti consentirà di lavorare molto più velocemente. E ti permetterà di distinguerti dagli altri designer che non hanno questo aiuto.
SQL e programmazione
Vorremmo tutti essere in grado di fornire un progetto di database, dire con orgoglio "Il mio lavoro qui è finito" e partire per una meritata vacanza. Ma di solito, quella situazione ideale non si verifica mai. Una volta terminato il tuo progetto, i programmatori dell'applicazione dovranno usarlo e avranno bisogno di te in giro per aiutarli.
Un modo in cui dovresti continuare ad assistere in un progetto di sviluppo è scrivere viste, trigger, stored procedure e altre cose in SQL (Structured Query Language) per risolvere particolari esigenze applicative. Un altro modo è supervisionare le attività di programmazione che vengono eseguite con qualcosa chiamato Object-Relational Mapping (ORM).
Gli ORM hanno lo scopo di astrarre l'accesso ai dati da un particolare RDBMS. Il lato positivo di questo è che i programmatori non devono preoccuparsi delle specifiche del database che utilizzeranno, in altre parole, non devono preoccuparsi se l'RDBMS è MySQL, Oracle, IBM DB2, MS SQL Server , o qualcos'altro.
Lo svantaggio degli ORM è che gli oggetti di progettazione del database (tabelle, attributi e relazioni) sono definiti nel codice di un linguaggio di programmazione di alto livello come Java, Python, R o C#. In altre parole, sono dove noi progettisti di database non possiamo vederli.
La soluzione a questo problema risiede nelle metodologie di sviluppo Agile e nella loro filosofia collaborativa. Questi promuovono designer e programmatori che lavorano insieme nel corso di un progetto, quindi ti consigliamo di mantenere un buon rapporto con i programmatori. Dovresti essere disposto a sederti accanto a loro, guardare il codice di programmazione e scrivere insieme le definizioni degli oggetti dati.
I progettisti di database delle competenze trasversali dovrebbero avere
Oltre alle conoscenze teoriche e tecniche specifiche per la progettazione di database, un designer dovrebbe idealmente avere altre competenze note come "competenze trasversali". Queste abilità, come essere un buon comunicatore e comprendere la visione dell'azienda per il prodotto finale, influiscono indirettamente sul successo del tuo lavoro. Quelli che menziono di seguito sono solo alcuni esempi, ma ci sono molte altre competenze trasversali che sono molto apprezzate dai potenziali datori di lavoro.
Visione aziendale
Quando si progetta un database, si rappresenta la realtà di un'azienda in termini di oggetti dati correlati. Abbiamo visto che il progetto deve soddisfare le condizioni di standardizzazione e che deve evitare incoerenze, anomalie e problemi di concorrenza. Ma altrettanto importante, o forse di più, è che il design sia in linea con la visione aziendale di chi paga il tuo stipendio.
Comprendere la visione aziendale ti consentirà di comprendere meglio l'importanza di ogni requisito e di guidare le tue decisioni in modo che i tuoi progetti siano meglio allineati con gli obiettivi dell'organizzazione.
Ecco un semplice esempio di come la comprensione della visione aziendale plasmerà il tuo lavoro. Potresti pensare che l'uso di una chiave surrogata in una tabella ingombra il tuo design, aggiungendo un elemento non necessario e fastidioso. Ma omettendo la chiave surrogata, potresti rallentare le query su quella tabella perché una chiave di tipo INTEGER potrebbe fornire prestazioni superiori. Se la visione aziendale è quella di fornire query rapide, la chiave surrogata è la strada da percorrere.
Abilità comunicative
Non basta fare grandi progetti. Devi anche essere in grado di spiegare perché il tuo design funziona. Il modo per farlo è sapere come presentarlo, sia discorsivamente (parlato o scritto) che visivamente.
Fai un elenco dei punti di forza del tuo design in modo che si distinguano. Pensa alle decisioni che hai preso per crearlo e scrivi le ragioni di tali decisioni. Preparati a difendere le tue decisioni e il tuo design da chi non lo capisce o vuole cambiarlo, renderlo imperfetto o imperfetto.
Ma devi anche essere disposto ad accettare critiche costruttive e considerare punti di vista diversi dal tuo. A volte un programmatore può individuare un problema che non hai visto e darti buoni consigli. Non licenziare i tuoi colleghi pensando che non abbiano una conoscenza del database.
Abilità interpersonali
Ho commentato sopra i vantaggi di avere un buon rapporto con i programmatori. Non importa quanto tu sia avanzato nella tua area di competenza, è importante mantenere un atteggiamento di compagnia con tutti i membri del team, sia che si tratti di un tester che ha rilevato un difetto che ti costringe a ripensare parte del tuo design o di un project manager che ha bisogno di portare a termine un compito entro una certa data. In breve, devi essere un giocatore di squadra . Nessuno vuole avere primedonne nella propria squadra che si sentono insostituibili e vogliono imporre le proprie regole.
Può succedere che tu non sia l'unico progettista di database in un team di sviluppo. Forse devi guidare un sottogruppo dei tuoi colleghi. Per fare ciò, devi dimostrare capacità di leadership e agire come project manager, assicurandoti che il team di progettisti di database soddisfi i suoi obiettivi e rimanga motivato.
Come apprendere le abilità di progettazione di database
Puoi acquisire le competenze necessarie per essere un progettista di database da diplomi universitari, corsi, libri e articoli specializzati. Il vantaggio dei corsi universitari è che ti danno tutte le conoscenze di cui hai bisogno e le avallano con un titolo riconosciuto. Lo svantaggio è che richiedono un grande investimento di tempo e denaro.
Se preferisci imparare da solo leggendo libri e articoli, risparmierai tempo e denaro, ma avrai bisogno di una guida che ti guidi attraverso gli argomenti essenziali e per valutare le tue conoscenze. E dovrai dimostrare le tue conoscenze in modo pratico, dal momento che non avrai una laurea per sostenerle.
In ogni caso, sia che impari seguendo corsi o leggendo, quella conoscenza servirà solo come base. Imparerai di più creando modelli, affrontando problemi reali e osservando le azioni dei tuoi colleghi e colleghi.
