Databasedesign går langt ud over blot at tegne linjer og felter. I denne artikel reflekterer jeg over processen med datamodellering med vægt på bedste praksis, samt hvordan man bruger værktøjer til at implementere disse bedste praksisser for at skabe et godt databasedesign.
Databasedesign er processen med at producere en detaljeret model af en database. Starten på databasemodellering involverer at få styr på forretningsområdet og den funktionalitet, der udvikles.
Hvis du er lidt usikker på de trin, der er involveret i databasedesignprocessen, vil jeg henvise dig til denne beskrivelse af databasedesigntrin.
Start modellering:Tal med virksomheden
Dette er et nøgleprincip inden for informationsteknologi. Vi løser et forretningsproblem fra datasiden, så de nødvendige data er tilgængelige. Vi er nødt til at tale med forretningsfolkene for at forstå deres behov.
Vi skal stille spørgsmål som:
- "Hvad er domænet?"
- "Hvad er udfordringerne på dette domæne?"
- "Hvilke problemer skal løses?"
- "Hvilke oplysninger skal vi opbevare?"
Ved at tale med virksomheden kan vi overveje afvejninger, der kan påvirke databasemodellen. Vi lægger også grundlaget for modellering.
Lad os bruge et konkret eksempel. Tag en regnskabsapplikation for en virksomhed:du skal modellere kunder, leverandører, fakturaer, betalinger, konti, saldi osv. Du skal lære om disse begreber og om regnskab. Du kan kun gøre dette ved at tale til forretningsfolkene.
Sådan får du orden på koncepter
Dette indledende arbejde med erhvervslivet vil føre dig ind i en model for, hvilke "begreber" der skal gemmes i databasen (læs denne forklaring af de forskellige niveauer af modeller). Fra konceptet om, hvad vi skal gemme i databasen, det vil sige vores konceptuelle model, går vi over til en logisk. Den logiske model dokumenterer de forretningskoncepter og regler, som vi lægger detaljer på (du kunne være interesseret i at læse denne diskussion om, hvorvidt logisk datamodellering er forældet).
Hvis du er usikker på de forskellige typer datamodeller, kan du se vores artikel om, hvordan du implementerer konceptuelle, logiske og fysiske datamodeller med Vertabelo.
Den logiske datamodel tilføjer mere information til de begreber, vi allerede har dokumenteret. Den beskriver, hvordan data er struktureret, og hvordan enhederne er relateret til hinanden. Derudover indeholder det oplysninger om de typer data, vi administrerer.
I Vertabelo kan vi skabe en logisk datamodel gennem et logisk entity-relationship diagram (ERD). Tjek detaljerne om, hvordan du udfører logisk datamodellering med Vertabelo.
Her er en enkel, og endnu ikke fuldstændig, logisk datamodel for kunder, leverandører, fakturaer, betalinger og konti.
En anden fordel, som jeg finder ved at arbejde med Vertabelo, er, at jeg ikke behøver at bekymre mig for meget om den nøjagtige notation. Modelleringsværktøjet giver dig mulighed for at bekymre dig om designet og ikke om detaljerne i entity-relationship diagram (ERD) notationer og symboler, hvilket naturligvis burde være det mindste af dine bekymringer under databasedesignprocessen.
Lad os blive fysiske
For rent faktisk at arbejde med databasen skal vi gå fra vores logiske model til en fysisk. Vertabelo-værktøjet giver os mulighed for nemt at generere en fysisk datamodel ud fra en logisk. Du opretter først en logisk datamodel, derefter kan du "auto-magisk " generer en fysisk ved at vælge den logiske model og klikke på "Generer fysisk datamodel" (se denne detaljerede vejledning for de nøjagtige trin).
Det er klart, at den genererede fysiske datamodel vil ligne den logiske model; logiske datatyper vil dog blive oversat til datatyper, der er tilladt for det bestemte databasestyringssystem (DBMS), som du genererer den fysiske model for. Den fysiske model vil også indikere, hvilke attributter der er fremmednøgler mellem tabeller. Du ønsker måske også at udføre yderligere modellering relateret til de fysiske aspekter af databasen – for eksempel indekser og visninger.
Derudover er det muligt at oprette en fysisk datamodel direkte; du behøver ikke oprette en logisk først. At gå direkte til en fysisk model vil give mening for mindre, mere rettede modelleringsaktiviteter, hvor forretningsdomænet er bedre defineret. Den fysiske databasemodelleringsproces er ligetil og bør ikke byde på for mange udfordringer. At have en logisk datamodel vil vise sig nyttig til større projekter, men at have mindst en fysisk er bedre end slet ingen.
Udvikling af dit databasedesign
Udviklere mener generelt, at databasemodellen skal dreje sig om den faktiske kode, mens datamodelbyggere mener, at koden skal skabes ud fra en relativt statisk datamodel. Datamodellering i dag skal være samarbejdende . Koden og datamodellen påvirker hinanden frem og tilbage.
Så vi har brug for et værktøj, der understøtter en kollaborativ databasedesignproces og -modellering. Udover at arbejde med virksomheden for at skabe det konceptuelle design, skal datamodellerere samarbejde under udviklingscyklussen for at opdatere de logiske og fysiske datamodeller efter behov. Modelbyggere og udviklere skal tilpasse modellen, indtil den virkelig understøtter systemets forretningsmæssige og ikke-funktionelle krav.
Det er klart, at ændringer kan føre til fejl. Igen kan det hjælpe at have et værktøj; et værktøj, der konstant validerer din datamodel, er uvurderligt. Vertabelo har en indbygget, live, online validering for både logiske og fysiske datamodeller, så problemer opdages under modellering, ikke under implementering. Og fejl forbliver synlige for alle, der samarbejder om det. Du kan også justere valideringsindstillingerne efter behov. Her er et eksempel på min ufuldstændige datamodel med flere fejl og advarsler.
Går vi tilbage til regnskabseksemplet, opdager du måske under udviklingen, at det ikke er nok at modellere en enkelt valuta som f.eks. euro eller dollars til fakturaer og betalinger. I stedet skal du gemme beløb med deres respektive valuta og konvertere dem til den "basis" valuta, som virksomhedens bogføring holdes i. Du har muligvis også brug for valutakurserne og historiske oplysninger om de kurser, der tidligere blev brugt til omregning af valutaer.
Det er her et samarbejdende databasemodelleringsværktøj som Vertabelo virkelig beviser sit værd. Du kan finde flere oplysninger om brug af Vertabelo til kollaborativ modellering. Du klikker bare og deler din model med dine teammedlemmer.
Fysisk til implementering
Når du har din første version af den fysiske model, vil du sandsynligvis være ivrig efter at begynde at arbejde med selve databasen. For at gøre det vil Vertabelo generere SQL DDL (Data Definition Language) scripts for at oprette databasen. Jeg vil ikke skrive alle detaljerne her, da du kan finde dem i artiklen om online vidensbase, hvordan man genererer et SQL-script og skaber en database.
Lad mig fortælle dig af erfaring - dette er sådan en velkommen funktion. Du slipper for at skulle håndtere lunerne i forskellige database SQL DDL-syntakser, og du kan fokusere på dit design .
Versionering
Nu, som jeg skrev ovenfor, vil dine modeller udvikle sig, uanset om det er under databasedesign, under softwareudvikling eller bagefter under den faktiske brug af din database. Der er to fantastiske funktioner ved Vertabelo, som jeg vil være sikker på, at du er opmærksom på.
For det første inkluderer Vertabelo versionsstyring. Du kan spore ændringer og administrere versioner af datamodellerne, så det er nemt at "skrue tiden tilbage" og rulle tilbage til en tidligere version, hvis det er nødvendigt. Hvis du er disciplineret, kan du mærke de forskellige versioner med præcise navne, uanset om det kan være udkast eller faktiske udgivelser af databasen.
Den anden funktion, som jeg har drømt om i mange år under min databasemodellering, er Vertabelo-værktøjets evne til automatisk generere migreringsscripts mellem versioner af din datamodel. Jeg har mistet tællingen af de gange, jeg skulle manuelt skrive og rette migreringsscripts gentagne gange. Her er et eksempel på generering af migreringsscripts mellem to versioner af en database til en onlineundersøgelse.
Hvilken velsignelse for datamodelbyggere at have et værktøj, der effektivt administrerer versioner og finder ud af virkningen af ændringer mellem versionerne!
Store modeller
Først, lad mig være ærlig. Jeg arbejder ikke altid med store modeller, men nogle gange er jeg nødt til at skabe dem. Her tilbyder Vertabelo os igen en løsning til at organisere vores modeller.
Vi kan visuelt gruppere tabeller med emneområder; hvis du gerne vil se, hvordan du gør det, kan du også se en video om håndtering af store datamodeller i Vertabelo.
Du kan også bruge denne teknik, når du reverse engineering fra et SQL DDL-script til en datamodel.
Kom godt i gang med databasedesign
Hvis du leder efter nogle bedste praksisser for databasedesign, vil jeg anbefale dig at tage et kig på denne artikel. For tips til bedre databasedesign behøver du ikke lede længere end denne artikel. Og se denne for at få råd om, hvordan du kommer i gang med at bruge Vertabelo til dit databasedesign.