Vilka är stegen i databasdesign?

Databasdesign är en av de viktigaste faktorerna som bidrar till en applikations prestanda. Följaktligen är det av yttersta vikt hur väl databasen är utformad. Databasdesign handlar om att effektivt organisera data baserat på produktarbetsflöden, framtida färdplan och förväntade användningsmönster.

Resultatet av en databasdesignövning är en datamodell. En datamodell representerar alla objekt, enheter, attribut, relationer och begränsningar i systemet. I stort sett kan datamodeller vara av två typer:logiska eller fysisk . Representationen av datamodellen görs genom att skapa ett ER-diagram, även känt som ett entitetsrelationsdiagram, ett ERD-diagram eller ett databasdiagram.

Den fysiska datamodellen relaterar till de faktiska implementeringsdetaljerna i databasen. Den logiska datamodellen, å andra sidan, abstraherar bort implementeringsteknikerna. Detta gör den logiska datamodellen förbrukningsbar för verksamheten. En viktig skillnad mellan de två modellerna är att den logiska modellen är databasagnostisk medan den fysiska modellen måste vara specifik för databasen som används.

Korrekt databasdesign är ofta underskattad och försummad under applikationsutveckling. Kostnaden för denna försummelse inses vanligtvis mycket senare när nya applikationsfunktioner kommer in eller när gamla funktioner kräver förändring. Det är då databasens design upphör att vara vettig. Även om det inte är möjligt att framtidssäkra designen av en databas, är det mycket möjligt att anstränga sig för att på bästa sätt förstå affärsanvändningsfallen och utforma databasen därefter. Läs mer om tips om bättre databasdesign här.

Med det i åtanke, låt oss gå igenom stegen i databasdesign.

Steg 1:Samla affärskrav

Det första steget är att prata med företaget om deras krav. Om samtalet är effektivt bör det resultera i tillräckligt med information för att börja arbeta med en konceptuell datamodell, som är en abstraktion av den logiska modellen. Att prata med verksamheten ger först och främst en helhetsbild av affärsprocesserna, vilket i sin tur ger information om de olika datapunkter som är viktiga för verksamheten att fånga och spåra. Till exempel, i en taxibokningsmodell är det värt att ställa följande frågor:

Vill företaget ha fordonsspårningsdata i databasen, oavsett om det är en aktiv resa eller inte? Om ja, fältet vehicle_trip_id i tabellen vehicle_trips skulle vara nullbar . Annars kommer den inte att vara nullbar .
Vill företaget ha historik över ändringar av trip_status lagras i databasen? Om ja, varje gång trip_status ändringar kommer det att finnas ytterligare en post i trips tabell. Annars, varje gång trip_status ändringar, trip_status kommer att uppdateras på plats.

Som visas i det här exemplet, baserat på indata från företaget, skulle du i slutändan välja ett alternativ framför det andra. Det skulle leda till att de berörda enheterna och deras relationer förändras.

Kravinsamling innebär också i allmänhet att inleda en konversation om datasäkerhet, till exempel vilken data som ska maskeras och krypteras. Kravinsamlingsövningen resulterar i ett kravdokument som ofta stöds av ett arbetsutkast till den konceptuella datamodellen.

Steg 2:Förstå Business Roadmap

Företag förändrar sina processer hela tiden; deras förmåga att anpassa sig gör dem mindre benägna att misslyckas. Att förändra affärsprocesser innebär att förändra arbetsflöden och datamodeller. Även om det inte är möjligt att veta dessa förändringar långt i förväg, är det säkert möjligt att vara uppdaterad med affärsplanen.

Till exempel, om ett företag har planer på att rikta in sig på en ny geografisk region, måste modellen tillgodose språkstöd, valutor, tidszoner och så vidare. Fördelarna med att förstå den långsiktiga affärsplanen visar sig ofta i en smidigare övergång till nya affärsprocesser.

Låt mig dela med mig av ytterligare ett exempel, som mer handlar om att ständigt utveckla affärsprioriteringar. Taxiverksamheten drabbades hårt i början av covid-19. Som taxiföretag vill du agera förebyggande för att försäkra folk om att du gör allt för att din resa i hytten ska vara så säker som möjligt, att fordonet desinficeras varje dag, att föraren överhuvudtaget bär en mask. gånger och att det finns handsprit tillgängligt i hytten. Nu, för att fånga all denna information, ändras till två enheter, drivers och vehicles , skulle krävas. Flera Booleska flaggfält måste läggas till i dessa enheter för att tillgodose detta affärsanvändningsfall.

Steg 3:Identifiera enheter och attribut

När affärskraven har samlats in kan informationen användas för att identifiera enheter tillsammans med den väsentliga uppsättningen attribut. En eller flera enheter mappar i allmänhet direkt till affärsprocesser, och relationen mellan dessa enheter efterliknar också affärsprocessens arbetsflöde.

Detta steg används också för att identifiera vilka attribut som kommer att fungera som identifierare i enheterna. Identifierare översätts till primärnycklar i den fysiska modellen. Dessutom är det också vanligt att ange datatyper för alla attribut i detta steg.

Till exempel i taxibokningsmodellen måste du identifiera de attribut som kommer att fungera som de obligatoriska fälten för registrering av användare och förare från bokningsappen. Användarregistrering skulle göras med user_phone och förarregistrering skulle göras med driver_phone .

På liknande sätt identifieras andra enheter och attribut under detta steg, efter att ha mappats till affärsprocessernas arbetsflöden.

Steg 4:Identifiera relationer

Efter att ha identifierat enheterna och deras attribut är nästa steg att definiera relationerna mellan enheter baserat på de affärsarbetsflöden som dokumenterades i kravinsamlingsfasen. Förutom att fastställa att det finns en relation mellan två enheter, är det också viktigt att identifiera vilken av följande fyra typer av relation som finns mellan dem. Betrakta två godtyckliga enheter, A och B:

En-till-en → En post i A motsvarar högst en post i B.
En-till-många → En post i A motsvarar många poster i B.
Många-till-en → Många poster i A motsvarar högst en post i B.
Många-till-många → Många poster i A motsvarar många poster i B.

I taxibokningsmodellen har endast en typ av relation använts, det vill säga en-till-många. Ta relationen mellan users och trips som ett exempel. I modellen finns det ett antagande att endast en användare kan relateras till en resa, vilket innebär att det inte finns några delade eller poolade hytter. Men om det funnits delade eller poolade hytter skulle det möjligen ha funnits ett många-till-många-förhållande mellan users och trips , om många användare delade samma trip_id .

Steg 5:Skapa ett logiskt ER-diagram

Med entiteter, attribut och entitetsrelationer definierade är det omedelbara nästa steget att rita ER-diagrammet. Alla steg som anges ovan kan göras inom Vertabelo. Det finns inga hårda och snabba regler för hur logisk modellering ska göras, med eventuellt undantag för referensnotationen.

Ta till exempel en titt på följande exempel på ett logiskt ER-diagram. Den fångar ett enkelt arbetsflöde för ett taxiföretag, där en användare kan boka en resa med möjligheten att spåra fordonet.

Steg 6:Validera det logiska ER-diagrammet

Logisk modellering är en process där mycket affärsinformation måste översättas till en databasdesign. Utan noggranna kontroller är denna fas av databasutveckling benägen för fel som kan visa sig vara ganska kostsamma i ett senare skede.

För att ta hand om detta har Vertabelo en noggrann lista över kontroller som kan utföras på en logisk modell. Kontroller kan utföras med alla granulariteter, från modellen som helhet till enskilda attribut och allt däremellan. Några av de enkla kontrollerna är:

Namn på enheter, attribut, relationer etc. kan inte vara null och måste vara unika.
En enhet måste ha minst ett attribut.
Identifierare (PK) måste definieras för varje entitet.
Modellen måste använda en av de angivna datatyperna för attribut.

Alla dessa kontroller är valfria och kan konfigureras för att hoppa över, om det finns ett annat valideringsramverk på plats. Korrekt validering från Vertabelo hjälper dig att gå till nästa steg med minsta möjliga friktion.

Steg 7:Skapa ett fysiskt ER-diagram

När det logiska ER-diagrammet har skapats är nästa steg att skapa en fysisk datamodell. Den fysiska datamodellen kommer att vara specifik för databasen där du vill distribuera datamodellen. Alla databaser har sin unika implementering av nomenklaturregler, datatyper och begränsningar. På grund av detta skiljer sig DDL (Data Definition Language) ofta från en databas till en annan.

För att skapa en fysisk datamodell, följ dessa steg:

Hitta den närmaste datatypen i måldatabasen för att ersätta den generiska datatypen som valts i den logiska datamodellen.
Följ nomenklaturreglerna för tabeller, kolumner och begränsningar som föreskrivs av måldatabasen.
Ändra modellen så att den anpassas till fördefinierade frågearbetsflöden. Detta resulterar i allmänhet i ökad redundans för att spara anslutningar.
Slutligen kan du skapa index, partitioner, distributionsnycklar och sorteringsnycklar. Det är då du kan skapa prestandahöjande modifieringar av modellen.

Dessa steg kan utföras med vilket datamodelleringsverktyg som helst som du kan använda för att skapa en datamodell från grunden. Vertabelo har dock ett alternativ att konvertera en logisk datamodell till en fullfjädrad fysisk datamodell för alla stora databassystem som MySQL, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Redshift, Google BigQuery och mer. När den logiska datamodellen har konverterats till en fysisk datamodell kan du fortsätta med de fyra steg vi diskuterade.

Vertabelo har också en möjlighet att lägga till skript före och efter distribution på tabellnivå tillsammans med eventuella kommentarer på modellens mycket detaljerade nivå. Kommentarerna blir praktiska när funktionen för dokumentationsgenerering som erbjuds av Vertabelo används. Databasdokumentet kan exporteras i något av följande tre format:HTML, PDF eller DOCX.

För att fortsätta med exemplet med taxibokning, låt oss ta en titt på den fysiska datamodellen som genereras av Vertabelo.

Steg 8:Validera det fysiska akutdiagrammet

Precis som det logiska ER-diagrammet validerades, har Vertabelo ett verktyg för att validera fysiska ER-diagram med flera ytterligare kontroller, som huruvida FK:er finns eller inte och om längden på ett tabellnamn eller ett kolumnnamn överskrider gränsen baserat på den valda databasen.

Valideringen behöver inte köras explicit. Det händer när diagrammet ändras. Problemen med modellen delas in i en av tre kategorier:fel, varningar och tips, i fallande svårighetsgrad. Det finns en användbar, välskriven artikel som talar om de vanliga misstagen som görs under databasdesignprocessen.

Steg 9:Åtgärda problem med det fysiska akutdiagrammet

Resultaten av valideringen kan identifiera problem som måste åtgärdas. Några av de vanligaste problemen är:

Främmande nycklar saknas där entitetsrelationer har definierats.
Primärnycklar saknas från tabeller.
Datatyper som inte stöds för den valda databasen.

När dessa och andra liknande problem är lösta är modellen redo att exporteras till ett driftsättbart SQL-skript för det valda databashanteringssystemet.

Steg 10:Generera DDL-skripten för implementering av modellen

Databasdesign handlar inte bara om att skapa ER-diagram. En datamodelleringsövning med hjälp av ER-diagram är framgångsrik endast om den resulterar i något utplacerbart. Vertabelo har ett bekvämt alternativ för att exportera den fysiska modellen till ett färdigt att distribuera SQL-skript. När det väl har skapats kan alla pågående problem lösas direkt i SQL-skriptet.

Det rekommenderas dock inte att ändra det genererade SQL-skriptet. Det orsakar en drift mellan den fysiska datamodellen och SQL-skriptet som används på databasen, vilket också kan innebära en avvikelse mellan de faktiska tabellerna och databasdokumentationen.

Nu när vi har nått slutet av databasdesignprocessen, låt oss ta en titt på SQL-koden som genereras av Vertabelo.

Dela dina tankar

Databasdesign är en aktivitet med stor genomslagskraft inom mjukvaruutveckling. Området databasdesign har utvecklats under åren med nya sätt att representera designen för verksamheten, för ingenjörerna och för dataanalytikerna. Detta har ofta resulterat i nya typer av diagram, modelleringsstandarder och notationer. Mycket av utvecklingen har behandlats i avsnittet om designgrunder.

Vi kommer gärna se dina erfarenheter av att utforma databaser. Skriv till oss på [email protected].