Het is de taak van een databaseontwerper om de zakelijke vereisten van de klant te vertalen in een gegevensmodel dat niet alleen de bedrijfsgegevens correct opslaat, maar ook de processen ondersteunt die de gegevens gebruiken.
Een databaseontwerper, ook wel een database-architect of een datafunctionaris genoemd, is verantwoordelijk voor het ontwerpen van de databases in een organisatie. Hij/zij evalueert zorgvuldig de business requirements en stelt de datamodellen op. Vervolgens vinden de eerste gesprekken met het bedrijf plaats om het begrip van de gegevens en de bedrijfsprocessen te valideren. De taak van een databaseontwerper omvat ook het voorbereiden van ondersteunende documentatie bij het bouwen van de fysieke database.
Wat is gegevensmodellering?
Datamodellering is een proces waarbij een databaseontwerper een datamodel maakt dat zijn/haar toepassing ondersteunt. Het doel is om te laten zien hoe database-objecten op elkaar inwerken en hoe ze zakelijke problemen oplossen.
Een datamodel beschrijft de structuur van de gegevens in de databasetabellen en de onderlinge relaties. Het wordt weergegeven door een reeks ER-diagrammen die de belangrijkste entiteiten, hun attributen en de relaties tussen de entiteiten bevatten. Het is erg belangrijk om vanaf het begin het juiste datamodel te bouwen.
Bij datamodellering moet ook rekening worden gehouden met flexibiliteit. Geen enkel datamodel is ooit in steen gebeiteld, zelfs niet nadat de database is geïmplementeerd. Een datamodel moet in de loop van de tijd worden aangepast aan nieuwe data en nieuwe eisen. Daarom is het belangrijk om rekening te houden met flexibiliteit bij het ontwerpen ervan.
Met datamodellering kunt u de zakelijke vereisten vertalen naar technische vereisten om de fysieke database gemakkelijker te bouwen. Het helpt u ook potentiële prestatieproblemen met query's te vinden voordat u de database zelfs maar maakt. Om al deze redenen is datamodellering erg belangrijk.
Soorten gegevensmodellen
Bij het bouwen van een nieuwe database doorloopt je werk als databaseontwerper minimaal drie grote fasen. Een datamodel doorloopt een evolutionair proces vanuit een conceptueel datamodel. Het wordt vervolgens uitgebreid tot een logisch datamodel. Dit wordt op zijn beurt verder uitgebreid tot een fysiek datamodel, later geïmplementeerd met SQL-scripts.
Elk type datamodel is ontworpen voor interactie met verschillende soorten belanghebbenden. Hieronder zullen we het gebruik van deze datamodellen kort beschrijven en toelichten. Als je een meer diepgaande uitleg wilt, bekijk dan dit artikel.
Conceptueel gegevensmodel
Het conceptuele datamodel is het eerste datamodel dat we bouwen. In een conceptueel datamodel worden de belangrijkste entiteiten gedefinieerd, meestal met behulp van ER-diagrammen. Dit is ook wanneer de belangrijkste belanghebbenden van de zakelijke kant deelnemen.
Een conceptueel datamodel helpt bij het identificeren en definiëren van de initiële omvang van het bedrijfsprobleem, de entiteiten die betrokken zijn bij het oplossen van het probleem en hoe ze met elkaar omgaan. Deze entiteiten zijn generieke representaties van concepten zoals bestelling, winkel en werknemer.
De relaties tussen deze entiteiten worden meestal weergegeven met lijnen die de entiteiten met elkaar verbinden die in de echte wereld op elkaar inwerken. Dus, als voorbeeld, de order-, winkel- en werknemersentiteiten zouden relaties moeten hebben die daartussen linken.
Logisch gegevensmodel
Het logische datamodel bouwt voort op het conceptuele datamodel. Normalisatietechnieken zoals 3NF (de derde normaalvorm) worden toegepast. We zorgen ervoor dat alle relaties tussen entiteiten vertegenwoordigd zijn in ons datamodel. Deze stap is het belangrijkste verschil tussen de conceptuele en de logische datamodellen.
Fysiek gegevensmodel
Het fysieke datamodel is de laatste en meest gedetailleerde versie van ons datamodel. In deze stap definiëren we alle tabellen in onze applicatie. We definiëren ook de relaties tussen tabellen, stellen hun kardinaliteit in, transformeren entiteitskenmerken in kolommen en kiezen of definiëren gegevenstypen voor elke kolom. We zorgen ervoor dat we standaardwaarden of beperkingen instellen voor kolomwaarden, beperkingen tussen tabellen en sorteringen instellen.
Zodra een fysiek gegevensmodel is ontworpen, bouwen we meestal een set SQL-scripts die deze structuur definiëren om onze database te maken. In plaats van alles met de hand te schrijven, is het veel beter om een databasemodelleringstool zoals Vertabelo Database Modeler te gebruiken.
De taak van de databaseontwerper
De taken van een databaseontwerper zijn niet beperkt tot technische ontwikkeling en diagramontwerp. Een typische dag omvat het kijken naar de achterstand van zakelijke vereisten en kijken of er iets is veranderd.
Een dag uit het leven van een databaseontwerper
Wanneer er wijzigingen zijn, analyseert de databaseontwerper de vereisten en overlegt met de business om de implicaties van de wijzigingen voor het datamodel en de database te verduidelijken. Na deze verduidelijkingen werkt de databaseontwerper het model bij met de wijzigingen. Dit kan variëren van het wijzigen van een enkel gegevenstype tot het opnieuw ontwerpen van entiteitsrelaties en het toepassen van normalisatie als de wijziging een grotere impact heeft.
Als er een prestatiestatistiek is waaraan moet worden voldaan, moet de databaseontwerper mogelijk indexen zoeken en specificeren die moeten worden gemaakt. Als er een ETL-proces in kaart moet worden gebracht, kan hij/zij specificeren welke opgeslagen procedures de gegevenstransformatie uitvoeren.
Een databaseontwerper moet rekening houden met de implicaties van de wijzigingen voor onderhoudstaken op de database, zoals back-ups, herstel en verzending van logbestanden. Als de wijzigingen groot zijn, moet de databaseontwerper overleggen met het databasebeheerteam of met het ontwikkelteam dat de database bewaakt. Een andere verantwoordelijkheid van de ontwerper is het definiëren en onderhouden van de datadictionary voor de database.
Risico's en problemen waarmee een databaseontwerper wordt geconfronteerd
Zoals bij elke klus, zijn sommige problemen voorspelbaar, zodat u een plan kunt schetsen. Maar er zijn problemen die u niet kunt voorspellen, en het werk van een databaseontwerper is geen uitzondering.
Een van de meest risicovolle dingen die een databaseontwerper kan doen, is aannames doen. Dit kan later in het project voor onverwachte problemen zorgen. Bij twijfel is het het beste om dit met het bedrijf te verduidelijken in plaats van verder te gaan. Ik heb het vaak zien gebeuren, zowel bij mezelf als bij mijn collega's.
We kunnen kleine veronderstellingen maken over gegevenstypen of de hoeveelheid gegevens voor een specifieke tabel. Als we het echter bij het verkeerde eind hebben, kan dit van invloed zijn op het fysieke datamodel en veel herwerk veroorzaken om aan de beoogde prestatiestatistieken te voldoen.
Een ander probleem is om aan te nemen dat je alles hebt gedekt en dat er nooit fouten zullen zijn. Problemen ontstaan meestal aan het einde van een project wanneer alles al is geïmplementeerd.
Sommige scenario's vereisen aanpassingen, zelfs nadat uw database al is geïmplementeerd. Dit kan te wijten zijn aan een toename van de opgeslagen gegevens, wijzigingen in de zakelijke vereisten of de behoefte aan nieuwe rapporten. Deze gebeurtenissen hebben niet alleen invloed op uw tabellen, maar ook op uw database-objecten, uw indexen, mogelijk gegevenstypen, relaties en vele andere dingen.
De voor- en nadelen van een databaseontwerper
Zoals bij elke baan, zijn er voor- en nadelen, afhankelijk van hoe je naar de dingen kijkt, wat je leuk vindt en hoe je wilt leven.
De voordelen zijn dat je altijd interessante zakelijke contexten vindt om in kaart te brengen in een datamodel en in te bouwen in een database. Het is een geweldige baan voor mensen die zich kunnen concentreren en die graag moeilijke problemen oplossen. Het is een geweldige baan als je graag communiceert en technische problemen oplost en als je zowel zakelijke als technologische contexten kunt en wilt begrijpen.
Zoals bij elke moeilijke vaardigheid, is het loon redelijk goed. Als u aan projecten werkt met klanten van grote bedrijven, kan zakenreizen een bonus zijn als u van reizen en nieuwe mensen in nieuwe omgevingen houdt.
De nadelen zijn naar mijn mening niet veel. Maar voor sommige mensen zijn sommige van de dingen die in de pluspunten worden genoemd, eigenlijk nadelen. Als u zich liever volledig op uw werk concentreert en de communicatie minimaliseert, of als u niet kunt of wilt reizen vanwege gezinsbeperkingen, dan is de baan van databaseontwerper misschien niet geschikt voor u.
Word een databaseontwerper!
Met enige technische expertise in het veld, enige programmeerachtergrond en openheid voor communicatie, denk ik dat iedereen de carrière van een databaseontwerper kan hebben, zelfs als je niet alle vakjes aanvinkt. De ideale vaardigheidsvereisten om een databaseontwerper te zijn, worden hieronder kort opgesomd.
- Gegevensmodellering en normalisatietechnieken.
- Kennis over databasequery's en prestatieafstemming.
- Internals van de database specifiek voor de database-engine die de klant nodig heeft.
- Kennis van ETL-processen.
- Kennis van business intelligence en rapportage.
- Kennis van algemene software-architectuur en ontwerp.
- Projectmanagementvaardigheden.
- Goede communicatieve vaardigheden.
Denkt u erover om databaseontwerper te worden? Als je merkt dat je sommige items in de bovenstaande lijst aanvinkt, aarzel dan niet - we staan voor je klaar! Of je nu solliciteert naar je eerste baan als databaseontwerper of gewoon bekend wilt zijn met de belangrijkste onderwerpen voor de functie, we hebben een lijst met interviewvragen opgesteld met betrekking tot databasemodellering.
Net begonnen met databasemodellering? Het is belangrijk om een tool als Vertabelo Database Modeler te hebben om je te helpen bij het ontwerpen, delen en versiebeheer van je datamodellen.
We hopen dat je genoten hebt van het artikel! Kijk gerust rond voor meer informatie over de wondere wereld van databases.