En databasedesigners opgave er at oversætte kundens forretningskrav til en datamodel, der ikke kun gemmer forretningsdataene korrekt, men også understøtter de processer, der bruger dataene.
En databasedesigner, nogle gange kaldet en databasearkitekt eller en dataansvarlig, er ansvarlig for at designe databaserne i en organisation. Han/hun vurderer omhyggeligt forretningskravene og udarbejder datamodellerne. Derefter opstår indledende diskussioner med virksomheden for at validere forståelsen af dataene og forretningsprocesserne. En databasedesigners job inkluderer også at udarbejde understøttende dokumentation ved opbygning af den fysiske database.
Hvad er datamodellering?
Datamodellering er en proces, hvor en databasedesigner opretter en datamodel, der understøtter hans/hendes applikation. Dens formål er at repræsentere, hvordan databaseobjekter interagerer, og hvordan de løser forretningsproblemer.
En datamodel beskriver strukturen af dataene i databasetabellerne og relationerne mellem dem. Det er repræsenteret af en række ER-diagrammer, der indeholder de vigtigste enheder, deres attributter og relationerne mellem enhederne. Det er meget vigtigt at bygge den rigtige datamodel fra starten.
Datamodellering skal også tage højde for fleksibilitet. Ingen datamodel er nogensinde hugget i sten, selv efter at databasen er implementeret. En datamodel skal tilpasses over tid for at afspejle nye data og nye krav. Derfor er det vigtigt at tage højde for fleksibilitet, når du designer det.
Datamodellering hjælper dig med at oversætte forretningskravene til tekniske krav til opbygning af den fysiske database nemmere. Det hjælper dig også med at finde potentielle ydeevneproblemer med forespørgsler, før du overhovedet opretter databasen. Af alle disse grunde er datamodellering meget vigtig.
Typer af datamodeller
Når du bygger en ny database, tager dit arbejde som databasedesigner dig igennem mindst tre store faser. En datamodel gennemgår en evolutionær proces med udgangspunkt i en konceptuel datamodel. Det udvides derefter til en logisk datamodel. Dette er til gengæld udvidet yderligere til en fysisk datamodel, senere implementeret med SQL-scripts.
Hver type datamodel er designet til at interagere med forskellige typer af interessenter. Vi vil kort beskrive og forklare brugen af disse datamodeller nedenfor. Hvis du gerne vil have en mere dybdegående forklaring, så tag et kig på denne artikel.
Begrebsdatamodel
Den konceptuelle datamodel er den første datamodel, vi bygger. I en konceptuel datamodel er hovedenhederne defineret, normalt ved hjælp af ER-diagrammer. Det er også her, de vigtigste interessenter fra erhvervssiden deltager.
En konceptuel datamodel hjælper med at identificere og definere det indledende omfang af forretningsproblemet, de enheder, der er involveret i at løse problemet, og hvordan de interagerer. Disse entiteter er generiske repræsentationer af begreber som ordre, butik og medarbejder.
Relationerne mellem disse entiteter er typisk repræsenteret med linjer, der forbinder de entiteter, der interagerer i den virkelige verden. Så som et eksempel bør ordre-, butiks- og medarbejderenhederne have relationer, der forbinder dem.
Logisk datamodel
Den logiske datamodel bygger på den konceptuelle datamodel. Normaliseringsteknikker såsom 3NF (den tredje normale form) anvendes. Vi sikrer, at alle relationer mellem enheder er repræsenteret i vores datamodel. Dette trin er den vigtigste forskel mellem de konceptuelle og de logiske datamodeller.
Physisk datamodel
Den fysiske datamodel er den endelige og mest detaljerede version af vores datamodel. I dette trin definerer vi alle tabellerne i vores applikation. Vi definerer også relationerne mellem tabeller, indstiller deres kardinalitet, transformerer enhedsattributter til kolonner og vælger eller definerer datatyper for hver kolonne. Vi sørger for at indstille standardværdier eller begrænsninger på kolonneværdier, begrænsninger mellem tabeller og sæt sammenstillinger.
Når først en fysisk datamodel er designet, bygger vi normalt et sæt SQL-scripts, der definerer denne struktur for at skabe vores database. I stedet for bare at skrive alt i hånden, er det meget bedre at bruge et databasemodelleringsværktøj som Vertabelo Database Modeler.
Databasedesignerens job
En databasedesigners opgaver er ikke begrænset til teknisk udvikling og diagramdesign. En typisk dag involverer at se på efterslæbet af forretningskrav og se, om noget har ændret sig.
En dag i en databasedesigners liv
Når der er ændringer, analyserer databasedesigneren kravene og mødes med virksomheden for at afklare konsekvenserne af ændringerne på datamodellen og databasen. Efter disse præciseringer opdaterer databasedesigneren modellen med ændringerne. Dette kan variere fra blot at ændre en enkelt datatype til at omdesigne enhedsrelationer og anvende normalisering, hvis ændringen har en større indvirkning.
Hvis der er en præstationsmetrik, der skal opfyldes, skal databasedesigneren muligvis finde og specificere indekser, der skal oprettes. Hvis der er en ETL-proces, der skal kortlægges, kan han/hun angive, hvilke lagrede procedurer der udfører datatransformationen.
En databasedesigner skal overveje konsekvenserne af ændringerne på vedligeholdelsesopgaver på databasen, såsom sikkerhedskopier, gendannelser og logforsendelse. Hvis ændringer er større, skal databasedesigneren diskutere med databaseadministrationsteamet eller med udviklingsteamet, der overvåger databasen. Et andet ansvar for designeren er at definere og vedligeholde dataordbogen for databasen.
Risici og problemer, som en databasedesigner står over for
Som med ethvert job er nogle problemer forudsigelige, så du kan få skitseret en plan. Men der er problemer, du ikke kan forudsige, og en databasedesigners job er ikke en undtagelse.
En af de mest risikable ting, en databasedesigner kan gøre, er at lave antagelser. Dette kan forårsage uventede problemer senere i projektet. Når du er i tvivl, er det bedst at afklare med virksomheden i stedet for at komme videre. Jeg har set det ske mange gange, både for mig selv og mine kollegaer.
Vi kan lave små antagelser om datatyper eller mængden af data for en specifik tabel. Hvis vi tager fejl, kan dette imidlertid påvirke den fysiske datamodel og forårsage en masse omarbejde for at nå målene for ydeevne.
Et andet problem er at antage, at du har dækket alt, og at der aldrig vil være fejl. Problemer opstår normalt i slutningen af et projekt, når alt allerede er implementeret.
Nogle scenarier kræver justeringer, selv efter din database allerede er implementeret. Dette kan skyldes en stigning i de lagrede data, ændringer i forretningskrav eller behov for nye rapporter. Disse hændelser påvirker ikke kun dine tabeller, men også dine databaseobjekter, dine indekser, muligvis datatyper, relationer og mange andre ting.
Fordele og ulemper ved at være databasedesigner
Som med ethvert job er der fordele og ulemper afhængigt af, hvordan du ser på tingene, hvad du nyder, og hvordan du vil leve.
Fordelene er, at du altid finder interessante forretningsmæssige sammenhænge at kortlægge ind i en datamodel og bygge ind i en database. Det er et godt job for folk, der kan fokusere, og som kan lide at løse svære problemer. Det er et godt job, hvis du kan lide at kommunikere og løse tekniske problemer, og hvis du kan og er nysgerrig efter at forstå både forretningsmæssige og teknologiske sammenhænge.
Som med enhver svær færdighed er lønnen ganske god. Hvis du arbejder på projekter med kunder fra store virksomheder, kan forretningsrejser være en bonus, hvis du nyder at rejse og møde nye mennesker i nye miljøer.
Ulemperne er efter min mening ikke mange. Men for nogle mennesker er nogle af de ting, der er nævnt i fordelene, faktisk ulemper. Hvis du foretrækker at fokusere dybt på dit arbejde og minimere kommunikation, eller hvis du ikke kan eller ønsker at rejse på grund af familiemæssige begrænsninger, så passer databasedesignerjobbet muligvis ikke til dig.
Bliv databasedesigner!
Med en vis teknisk ekspertise på området, en vis programmeringsbaggrund og åbenhed over for kommunikation, tror jeg, at enhver kan have en databasedesigners karriere, selvom du ikke markerer alle boksene. De ideelle færdighedskrav for at være databasedesigner er kort listet nedenfor.
- Datamodellering og normaliseringsteknikker.
- Kundskab til databaseforespørgsler og ydeevnejustering.
- Interne databaser, der er specifikke for databasemotoren, der kræves af kunden.
- Kendskab til ETL-processer.
- Kendskab til business intelligence og rapportering.
- Kendskab til generel softwarearkitektur og design.
- Projektledelseskompetencer.
- Gode kommunikationsevner.
Overvejer du at blive databasedesigner? Hvis du finder dig selv at afkrydse nogle elementer på listen ovenfor, så tøv ikke - vi har din ryg! Uanset om du søger dit første job som databasedesigner eller blot ønsker at blive bekendt med de vigtigste emner for rollen, har vi opsat en liste med interviewspørgsmål relateret til databasemodellering.
Er du lige kommet i gang med databasemodellering? Det er vigtigt at have et værktøj som Vertabelo Database Modeler til at hjælpe dig med at designe, dele og versionere dine datamodeller.
Vi håber du kunne lide artiklen! Du er velkommen til at søge rundt for at få flere oplysninger om databasernes fantastiske verden.