Il compito di un progettista di database è tradurre i requisiti aziendali del cliente in un modello di dati che non solo memorizzi correttamente i dati aziendali, ma supporti anche i processi che utilizzano i dati.
Un progettista di database, a volte chiamato architetto di database o responsabile dei dati, è responsabile della progettazione dei database in un'organizzazione. Valuta attentamente i requisiti aziendali e redige i modelli di dati. Quindi, si verificano discussioni iniziali con l'azienda per convalidare la comprensione dei dati e dei processi aziendali. Il lavoro di un progettista di database include anche la preparazione della documentazione di supporto durante la creazione del database fisico.
Che cos'è la modellazione dei dati?
La modellazione dei dati è un processo in cui un progettista di database crea un modello di dati che supporta la propria applicazione. Il suo scopo è rappresentare come interagiscono gli oggetti del database e come risolvono i problemi di business.
Un modello di dati descrive la struttura dei dati nelle tabelle del database e le relazioni tra di loro. È rappresentato da una serie di diagrammi ER che contengono le entità principali, i loro attributi e le relazioni tra le entità. È molto importante creare il giusto modello di dati fin dall'inizio.
La modellazione dei dati deve anche considerare la flessibilità. Nessun modello di dati viene mai scolpito nella pietra anche dopo la distribuzione del database. Un modello di dati deve essere modificato nel tempo per riflettere nuovi dati e nuovi requisiti. Questo è il motivo per cui tenere conto della flessibilità è importante quando la progetti.
La modellazione dei dati consente di tradurre i requisiti aziendali in requisiti tecnici per creare più facilmente il database fisico. Ti aiuta anche a trovare potenziali problemi di prestazioni con le query prima ancora di creare il database. Per tutti questi motivi, la modellazione dei dati è molto importante.
Tipi di modelli di dati
Quando crei un nuovo database, il tuo lavoro come progettista di database ti guida attraverso almeno tre fasi principali. Un modello di dati attraversa un processo evolutivo a partire da un modello di dati concettuale. Viene quindi ampliato in un modello di dati logico. Questo, a sua volta, viene ulteriormente ampliato in un modello di dati fisico, successivamente implementato con script SQL.
Ogni tipo di modello di dati è progettato per interagire con diversi tipi di stakeholder. Descriveremo e spiegheremo brevemente l'uso di questi modelli di dati di seguito. Se desideri una spiegazione più approfondita, dai un'occhiata a questo articolo.
Modello concettuale dei dati
Il modello di dati concettuale è il primo modello di dati che costruiamo. In un modello di dati concettuale, vengono definite le entità principali, solitamente utilizzando i diagrammi ER. Questo è anche il momento in cui partecipano i principali stakeholder dal lato commerciale.
Un modello di dati concettuale aiuta a identificare e definire l'ambito iniziale del problema aziendale, le entità coinvolte nella risoluzione del problema e il modo in cui interagiscono. Queste entità sono rappresentazioni generiche di concetti come ordine, negozio e dipendente.
Le relazioni tra queste entità sono tipicamente rappresentate con linee che collegano le entità che interagiscono nel mondo reale. Quindi, ad esempio, le entità ordine, negozio e dipendente dovrebbero avere relazioni che le colleghino.
Modello di dati logici
Il modello dati logico si basa sul modello dati concettuale. Vengono applicate tecniche di normalizzazione come 3NF (la terza forma normale). Garantiamo che tutte le relazioni tra entità siano rappresentate nel nostro modello di dati. Questo passaggio è la differenza fondamentale tra i modelli di dati concettuali e logici.
Modello di dati fisici
Il modello di dati fisici è la versione finale e più dettagliata del nostro modello di dati. In questo passaggio, definiamo tutte le tabelle nella nostra applicazione. Definiamo anche le relazioni tra le tabelle, ne impostiamo la cardinalità, trasformiamo gli attributi di entità in colonne e scegliamo o definiamo i tipi di dati per ciascuna colonna. Ci assicuriamo di impostare valori o vincoli predefiniti sui valori delle colonne, vincoli tra tabelle e regole di confronto.
Una volta progettato un modello di dati fisico, di solito costruiamo una serie di script SQL che definiscono questa struttura per creare il nostro database. Invece di scrivere tutto a mano, è molto meglio utilizzare uno strumento di modellazione di database come Vertabelo Database Modeler.
Il lavoro del progettista di database
I compiti di un progettista di database non si limitano allo sviluppo tecnico e alla progettazione di diagrammi. Una giornata tipo consiste nell'esaminare l'arretrato dei requisiti aziendali e vedere se qualcosa è cambiato.
Un giorno nella vita di un progettista di database
Quando ci sono modifiche, il progettista del database analizza i requisiti e incontra l'azienda per chiarire le implicazioni delle modifiche sul modello di dati e sul database. Dopo questi chiarimenti, il progettista del database aggiorna il modello con le modifiche. Ciò può variare dalla semplice modifica di un singolo tipo di dati alla riprogettazione delle relazioni di entità e all'applicazione della normalizzazione se la modifica ha un impatto maggiore.
Se è necessario soddisfare una metrica delle prestazioni, il progettista del database potrebbe dover trovare e specificare gli indici da creare. Se è presente un processo ETL da mappare, può specificare quali stored procedure effettuano la trasformazione dei dati.
Un progettista di database deve considerare le implicazioni delle modifiche sulle attività di manutenzione del database, come backup, ripristini e log shipping. Se le modifiche sono importanti, il progettista del database deve discutere con il team di amministrazione del database o con il team di sviluppo che monitora il database. Un'altra responsabilità del progettista è definire e mantenere il dizionario dei dati per il database.
Rischi e problemi affrontati da un progettista di database
Come con qualsiasi lavoro, alcuni problemi sono prevedibili in modo da poter avere un piano abbozzato. Ma ci sono problemi che non puoi prevedere e il lavoro di un progettista di database non fa eccezione.
Una delle cose più rischiose che un progettista di database può fare è fare ipotesi. Ciò può causare problemi imprevisti più avanti nel progetto. In caso di dubbio, è meglio chiarire con l'azienda piuttosto che andare avanti. L'ho visto accadere molte volte, sia a me stesso che ai miei colleghi.
Possiamo fare piccole ipotesi sui tipi di dati o sulla quantità di dati per una tabella specifica. Se ci sbagliamo, tuttavia, ciò può influire sul modello di dati fisici e causare molte rielaborazioni per soddisfare le metriche delle prestazioni target.
Un altro problema è presumere di aver coperto tutto e che non ci saranno mai errori. I problemi di solito si verificano alla fine di un progetto quando tutto è già distribuito.
Alcuni scenari richiedono modifiche, anche dopo che il database è già stato distribuito. Ciò può essere dovuto a un aumento dei dati archiviati, a modifiche dei requisiti aziendali o alla necessità di nuovi report. Questi eventi influiscono non solo sulle tabelle, ma anche sugli oggetti del database, sugli indici, eventualmente sui tipi di dati, sulle relazioni e su molte altre cose.
Pro e contro di essere un progettista di database
Come in ogni lavoro, ci sono pro e contro a seconda di come guardi le cose, cosa ti piace e come vuoi vivere.
I vantaggi sono che trovi sempre contesti aziendali interessanti da mappare in un modello di dati e creare un database. È un ottimo lavoro per le persone che sanno concentrarsi e che amano risolvere problemi difficili. È un ottimo lavoro se ti piace comunicare e risolvere problemi tecnici e se puoi e sei curioso di capire sia i contesti aziendali che quelli tecnologici.
Come con qualsiasi abilità difficile, la paga è abbastanza buona. Se stai lavorando a progetti con clienti di grandi aziende, i viaggi di lavoro possono essere un vantaggio se ti piace viaggiare e incontrare nuove persone in nuovi ambienti.
I contro non sono molti a mio avviso. Ma per alcune persone, alcune delle cose menzionate nei pro sono in realtà contro. Se preferisci concentrarti profondamente sul tuo lavoro e ridurre al minimo la comunicazione o se non puoi o non vuoi viaggiare a causa di vincoli familiari, allora il lavoro di progettista di database potrebbe non essere adatto a te.
Diventa un progettista di database!
Con una certa esperienza tecnica nel campo, un po' di esperienza nella programmazione e apertura alla comunicazione, penso che chiunque possa avere la carriera di progettista di database anche se non selezioni tutte le caselle. I requisiti di abilità ideali per essere un progettista di database sono elencati brevemente di seguito.
- Tecniche di modellazione e normalizzazione dei dati.
- Conoscenza delle query del database e dell'ottimizzazione delle prestazioni.
- Interni del database specifici per il motore del database richiesto dal cliente.
- Conoscenza dei processi ETL.
- Conoscenza di business intelligence e reporting.
- Conoscenza dell'architettura generale e del design del software.
- Capacità di gestione del progetto.
- Buone capacità di comunicazione.
Stai pensando di diventare un progettista di database? Se ti ritrovi a spuntare alcuni elementi nell'elenco sopra, non esitare:ci pensiamo noi! Sia che tu stia facendo domanda per il tuo primo lavoro come progettista di database o semplicemente desideri conoscere gli argomenti più importanti per il ruolo, abbiamo creato un elenco di domande del colloquio relative alla modellazione di database.
Hai appena iniziato con la modellazione di database? È importante disporre di uno strumento come Vertabelo Database Modeler che ti aiuti a progettare, condividere e creare versioni dei tuoi modelli di dati.
Speriamo che l'articolo ti sia piaciuto! Sentiti libero di navigare per ulteriori informazioni sul fantastico mondo dei database.
