Hvad er trinene i databasedesign?

Databasedesign er en af de vigtigste faktorer, der bidrager til en applikations ydeevne. Derfor er det yderst vigtigt, hvor godt databasen er designet. Databasedesign handler om effektivt at organisere data baseret på produktworkflows, fremtidig køreplan og forventede brugsmønstre.

Outputtet af en databasedesignøvelse er en datamodel. En datamodel repræsenterer alle objekter, enheder, attributter, relationer og begrænsninger i systemet. Stort set kan datamodeller være af to typer:logiske eller fysisk . Repræsentationen af datamodellen udføres ved at oprette et ER-diagram, også kendt som et enhedsrelationsdiagram, et ERD-diagram eller et databasediagram.

Den fysiske datamodel relaterer sig til de faktiske implementeringsdetaljer i databasen. Den logiske datamodel abstraherer på den anden side implementeringstekniske forhold. Dette gør den logiske datamodel brugbar for virksomheden. En vigtig forskel mellem de to modeller er, at den logiske model er databaseagnostisk, mens den fysiske model skal være specifik for den database, der er i brug.

Korrekt databasedesign er ofte undervurderet og forsømt under applikationsudvikling. Omkostningerne ved denne forsømmelse realiseres normalt meget senere, når nye applikationsfunktioner kommer ind, eller når gamle funktioner kræver ændring. Det er her, databasedesignet holder op med at give mening. Selvom det ikke er muligt at fremtidssikre designet af en database, er det meget muligt at gøre en indsats for bedst muligt at forstå business use cases og designe databasen derefter. Læs mere om tips til bedre databasedesign her.

Med det i tankerne, lad os gennemgå trinene i databasedesign.

Trin 1:Indsaml forretningskrav

Det første skridt er at tale med virksomheden om deres krav. Hvis samtalen er effektiv, bør den resultere i nok information til at begynde at arbejde på en konceptuel datamodel, som er en abstraktion af den logiske model. At tale med virksomheden giver først og fremmest et komplet billede af forretningsprocesserne, som igen giver information om de forskellige datapunkter, som er vigtige for virksomheden at fange og spore. For eksempel i en taxabookingmodel er det værd at stille følgende spørgsmål:

Ønsker virksomheden køretøjssporingsdataene i databasen, uanset om der er en aktiv tur eller ej? Hvis ja, så feltet vehicle_trip_id i tabellen vehicle_trips ville være nullable . Ellers vil den ikke være nullbar .
Ønsker virksomheden historikken for ændringer til trip_status gemt i databasen? Hvis ja, så hver gang trip_status ændringer, vil der være endnu en post i trips bord. Ellers hver gang trip_status ændringer, trip_status vil blive opdateret på plads.

Som vist i dette eksempel, baseret på input fra virksomheden, ville du ende med at vælge den ene mulighed frem for den anden. Det ville resultere i at ændre de berørte enheder og deres relationer.

Kravindsamling involverer generelt også at indlede en samtale om datasikkerhed, såsom hvilke data der skal maskeres og krypteres. Kravindsamlingsøvelsen resulterer i et kravdokument ofte understøttet af et arbejdsudkast til den konceptuelle datamodel.

Trin 2:Forstå Business Roadmap

Virksomheder ændrer deres processer hele tiden; deres evne til at tilpasse sig gør dem mindre tilbøjelige til at fejle. Ændring af forretningsprocesser betyder ændring af arbejdsgange og datamodeller. Selvom det ikke er muligt at kende disse ændringer i god tid, er det bestemt muligt at være opdateret med forretningsplanen.

For eksempel, hvis en virksomhed har planer om at målrette mod en ny geografisk region, skal modellen tage højde for sprogunderstøttelse, valutaer, tidszoner og så videre. Fordelene ved at forstå den langsigtede forretningskøreplan viser sig ofte i en smidigere overgang til nye forretningsprocesser.

Lad mig dele endnu et eksempel, som handler mere om løbende udvikling af forretningsprioriteter. Taxaforretningen var hårdt ramt i begyndelsen af COVID-19. Som førerhusfirma vil du handle forebyggende for at forsikre folk om, at du gør alt for at sikre, at din rejse i førerhuset er så sikker som muligt, at køretøjet desinficeres hver dag, at chaufføren overhovedet bærer maske. gange, og at der er håndsprit tilgængeligt i førerhuset. Nu, for at fange al denne information, ændres til to enheder, drivers og vehicles , ville være påkrævet. Flere Booleske flagfelter skal føjes til disse entiteter for at imødekomme denne forretningsanvendelse.

Trin 3:Identificer enheder og attributter

Når forretningskravene er indsamlet, kan oplysningerne bruges til at identificere enheder sammen med det væsentlige sæt af attributter. En eller flere entiteter knytter sig generelt direkte til forretningsprocesser, og forholdet mellem disse enheder efterligner også forretningsprocessets arbejdsgang.

Dette trin bruges også til at identificere, hvilke attributter der vil fungere som identifikatorer i enhederne. Identifikatorer oversættes til primære nøgler i den fysiske model. Derudover er det også almindeligt at angive datatyper for alle attributterne i dette trin.

For eksempel skal du i taxabookingsmodellen identificere de attributter, der vil fungere som de obligatoriske felter for registrering af brugere og chauffører fra bookingappen. Brugerregistrering udføres ved hjælp af user_phone og chaufførregistrering udføres ved hjælp af driver_phone .

På samme måde identificeres andre enheder og attributter under dette trin, efter at de er blevet tilknyttet arbejdsprocesserne i forretningsprocesserne.

Trin 4:Identificer relationer

Efter at have identificeret enhederne og deres attributter, er næste trin at definere relationerne mellem enheder baseret på de forretningsmæssige arbejdsgange, der blev dokumenteret i kravindsamlingsfasen. Ud over at fastslå, at der er et forhold mellem to enheder, er det også vigtigt at identificere, hvilken af de følgende fire typer forhold, der eksisterer mellem dem. Overvej to vilkårlige enheder, A og B:

En-til-en → Én post i A svarer til højst én post i B.
En-til-mange → Én post i A svarer til mange poster i B.
Mange-til-en → Mange poster i A svarer til højst én post i B.
Mange-til-mange → Mange poster i A svarer til mange poster i B.

I taxabookingsmodellen er der kun brugt én type relation, altså en-til-mange. Tag forholdet mellem users og trips som et eksempel. I modellen er der en antagelse om, at kun én bruger kan relateres til en tur, hvilket indebærer, at der ikke er fælles eller poolede førerhuse. Men hvis der var delte eller poolede førerhuse, ville der muligvis have været et mange-til-mange forhold mellem users og trips , hvis mange brugere delte det samme trip_id .

Trin 5:Opret et logisk ER-diagram

Med entiteter, attributter og enhedsrelationer defineret, er det umiddelbare næste trin at tegne ER-diagrammet. Alle ovenstående trin kan udføres i Vertabelo. Der er ingen hårde og hurtige regler for den måde, logisk modellering skal udføres på, med mulig undtagelse af referencenotationen.

Tag for eksempel et kig på følgende eksempel på et logisk ER-diagram. Det fanger en simpel forretningsarbejdsgang for et førerhusfirma, hvor en bruger kan bestille en tur med mulighed for at spore køretøjet.

Trin 6:Valider det logiske ER-diagram

Logisk modellering er en proces, hvor en masse forretningsinformation skal oversættes til et databasedesign. Uden grundig kontrol er denne fase af databaseudvikling tilbøjelig til fejl, som kan vise sig at være ret dyre på et senere tidspunkt.

For at tage sig af dette har Vertabelo en grundig liste over kontroller, der kan udføres på en logisk model. Kontrol kan udføres ved alle granulariteter, fra modellen som helhed til individuelle attributter og alt derimellem. Nogle af de simple kontroller er:

Navne på enheder, attributter, relationer osv. kan ikke være null og skal være unikke.
En enhed skal have mindst 1 attribut.
Id'er (PK'er) skal defineres for hver enhed.
Modellen skal bruge en af de anførte datatyper til attributter.

Alle disse kontroller er valgfri og kan konfigureres til at blive sprunget over, hvis der er en anden valideringsramme på plads. Korrekt validering fra Vertabelo hjælper dig med at gå videre til næste trin med den mindst mulige mængde friktion.

Trin 7:Opret et fysisk ER-diagram

Når det logiske ER-diagram er oprettet, er næste trin at oprette en fysisk datamodel. Den fysiske datamodel vil være specifik for den database, hvor du vil implementere datamodellen. Alle databaser har deres unikke implementering af nomenklaturregler, datatyper og begrænsninger. På grund af dette adskiller Data Definition Language (DDL) sig ofte fra en database til en anden.

Følg disse trin for at oprette en fysisk datamodel:

Find den nærmeste datatype i måldatabasen for at erstatte den generiske datatype valgt i den logiske datamodel.
Følg nomenklaturreglerne for tabeller, kolonner og begrænsninger som foreskrevet af måldatabasen.
Rediger modellen, så den stemmer overens med foruddefinerede forespørgselsarbejdsgange. Dette resulterer generelt i stigende redundans for at gemme joinforbindelser.
Til sidst kan du oprette indekser, partitioner, distributionsnøgler og sorteringsnøgler. Det er her, du kan lave præstationsfremmende ændringer af modellen.

Disse trin kan udføres ved hjælp af et hvilket som helst datamodelleringsværktøj, du kan bruge til at oprette en datamodel fra bunden. Vertabelo har dog en mulighed for at konvertere en logisk datamodel til en fuldgyldig fysisk datamodel for alle de store databasesystemer som MySQL, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Redshift, Google BigQuery og mere. Når den logiske datamodel er konverteret til en fysisk datamodel, kan du fortsætte med de fire trin, vi diskuterede.

Vertabelo har også mulighed for at tilføje scripts før og efter implementering på tabelniveau sammen med eventuelle kommentarer på modellens meget granulære niveau. Kommentarerne viser sig at være nyttige, når funktionen til dokumentationsgenerering, der tilbydes af Vertabelo, bruges. Databasedokumentet kan eksporteres i et af følgende tre formater:HTML, PDF eller DOCX.

Lad os fortsætte med eksemplet med taxireservation, og lad os tage et kig på den fysiske datamodel, der er genereret af Vertabelo.

Trin 8:Valider det fysiske ER-diagram

Ligesom det logiske ER-diagram blev valideret, har Vertabelo et værktøj til at validere fysiske ER-diagrammer med flere yderligere kontroller, som om der eksisterer FK'er eller ej, og om længden af et tabelnavn eller et kolonnenavn overskrider grænsen baseret på den valgte database.

Valideringen behøver ikke at køres eksplicit. Det sker efterhånden som diagrammet ændres. Problemerne med modellen falder i en af tre kategorier:fejl, advarsler og tip, i rækkefølge efter faldende sværhedsgrad. Der er en nyttig, velskrevet artikel, som fortæller om de almindelige fejl, der begås under databasedesignprocessen.

Trin 9:Løs problemer med det fysiske ER-diagram

Resultaterne af valideringen kan identificere problemer, som skal rettes. Nogle af de mest almindelige problemer er:

Manglende fremmednøgler, hvor entitetsrelationer er blevet defineret.
Manglende primærnøgler fra tabeller.
Ikke-understøttede datatyper for den valgte database.

Når disse og andre lignende problemer er løst, er modellen klar til at blive eksporteret til et implementerbart SQL-script til det valgte databasestyringssystem.

Trin 10:Generer DDL-scripts til implementering af modellen

Databasedesign handler ikke kun om at skabe ER-diagrammer. En datamodelleringsøvelse ved hjælp af ER-diagrammer er kun vellykket, hvis den resulterer i noget, der kan implementeres. Vertabelo har en praktisk mulighed for at eksportere den fysiske model til et SQL-script, der er klar til implementering. Når det er genereret, kan eventuelle afventende problemer løses direkte i SQL-scriptet.

Det anbefales dog ikke at ændre det genererede SQL-script. Det forårsager en drift mellem den fysiske datamodel og SQL-scriptet, der er installeret på databasen, hvilket også kan betyde en afdrift mellem de faktiske tabeller og databasedokumentationen.

Nu hvor vi er nået til slutningen af databasedesignprocessen, lad os tage et kig på SQL-koden genereret af Vertabelo.

Del dine tanker

Databasedesign er en aktivitet med stor indflydelse inden for softwareudvikling. Området for databasedesign har udviklet sig gennem årene med nye måder at repræsentere designet for virksomheden, for ingeniørerne og for dataanalytikerne. Dette har ofte resulteret i nye typer diagrammer, modelleringsstandarder og notationer. Meget af udviklingen er blevet dækket i afsnittet om grundlæggende design.

Vi vil med glæde se, hvad dine erfaringer har været med at designe databaser. Skriv til os på [email protected].