Utgåvan av DNS-servern KnotDNS 2.9.0

Inför starten av den kommande omgången av kursen Databaser har vi förberett ett litet originalmaterial med viktiga tips för databaskonstruktion. Vi hoppas att detta material kommer att vara till nytta för dig.

Databaser finns överallt: från enklaste bloggar och kataloger till robusta informationssystem och stora sociala nätverk. Det spelar inte så stor roll om databasen är enkel eller komplex, så länge den är korrekt designad. När en databas designas slarvigt och utan en tydlig förståelse för syftet, blir den inte bara ineffektiv, utan det kommer också att bli ett verkligt lidande för användare att arbeta med den. Här är några tips för att konstruera en databas som kan hjälpa till att skapa en användbar och lättanvänd produkt.

1. Bestäm vad tabellen är till för och vilken dess struktur ska vara

Idag hjälper utvecklingsmetoder som Scrum eller RAD (snabb applikationsutveckling) IT-team att snabbt utveckla databaser. Men i jakten på tid är det lätt att få för sig att börja bygga databasen utan att riktigt förstå syftet och vilka slutresultat som bör uppnås.
 
Teamet kan tyckas sikta på effektiv och snabb arbetsprocess, men det är en illusion. Ju längre och snabbare man går in i projektet, desto mer tid krävs för att identifiera och rätta till fel i databasdesignen.

Så det första som behöver fastställas är syftet med din databas. För vilken typ av applikation utvecklas databasen? Kommer användaren bara att arbeta med poster och behöva fokus på transaktioner eller är det mer dataanalys som intresserar dem? Var ska databasen implementeras? Ska den spåra kundbeteenden eller bara hantera relationer mellan dem? 

Ju tidigare designteamet kan svara på dessa frågor, desto smidigare kommer processen att bli för databasen design.

2. Vilka data ska väljas för lagring?

Planera i förväg. Tänk på vad webbplatsen eller systemet kommer att göra i framtiden för vilket databasen designas. Det är viktigt att tänka bortom de enkla kraven i den tekniska specifikationen. Men snälla, börja inte omedelbart tänka på alla möjliga typer av data som användaren någonsin kan lagra. Tänk istället på om användarna kan skriva inlägg, ladda upp dokument eller foton eller skicka meddelanden. Om så är fallet, måste det finnas utrymme för dem i databasen.

Arbeta med teamet, avdelningen eller organisationen som i framtiden kommer att stödja den designade databasen. Kommunicera med människor på olika nivåer, från kundtjänstspecialister till avdelningschefer. Genom återkoppling får du en tydlig bild av företagets krav. 

Användarnas behov, även inom en avdelning, kommer ofrånkomligen att krocka. Om du stöter på detta, tveka inte att lita på din egen erfarenhet och hitta en kompromiss som tillfredsställer alla parter och uppfyller databassystemets slutmål. Var säker: i framtiden kommer du att få +100500 i karma och en hög med kakor.

3. Modellera data med försiktighet

Det finns några viktiga punkter att tänka på när du modellerar data. Som vi tidigare har nämnt beror vilka metoder som används vid modellering på databasens syfte. Om vi designar en databas för operationell bearbetning av poster (OLTP), det vill säga för att skapa, redigera och ta bort dem, använder vi transaktionsmodellering. Om databasen däremot ska vara relationsbaserad, är det bäst att tillämpa flerdimensionell modellering.

Under modelleringen skapas konceptuella (CDM), fysiska (PDM) och logiska (LDM) datamodeller. 

Konceptuella modeller beskriver entiteter och datatyper som de omfattar, samt relationerna mellan dem. Dela upp dina data i logiska bitar - det blir mycket enklare att hantera.
Det viktigaste är måttfullhet, överdriv inte.

Om en entitet är mycket svår att klassificera med ett enda ord eller fras, är det dags att använda underkategorier (barnentiteter).

Om en enhet lever ett eget liv, har attribut som beskriver dess beteende och dess typ, samt relationer med andra objekt, kan både under- och supertyp (föräldraanordning) användas utan tvekan. 

Om man bortser från denna regel kommer andra utvecklare att bli förvirrade över din modell och inte helt förstå datan och reglerna för hur de ska samlas.

Konceptuella modeller implementeras med hjälp av logiska modeller. Dessa modeller fungerar som en vägkarta för att designa en fysisk databas. I den logiska modellen identifieras affärsdatens enheter, datatyper definieras, nyckelstatus regleras och relationer mellan data anges.

Den logiska datamodellen kopplas sedan till den i förväg valda DBMS-plattformen (databashanteringssystemet för databashantering) och en fysisk modell erhålls. Den beskriver sättet att fysiskt lagra data.

4. Använd lämpliga datatyper

Användning av fel datatyp kan leda till mindre exakta data, svårigheter att sammanfoga tabeller, synkronisera attribut och uppblåsta filstorlekar.
För att garantera dataintegritet bör ett attribut endast innehålla accepterade datatyper. Om ålder matas in i databasen, se till att kolumnen lagrar heltal med högst 3 siffror.

Skapa så få tomma kolumner med NULL-värde som möjligt. Om du skapar alla kolumner som NULL, är det ett grovt misstag. Om du däremot behöver en tom kolumn för att utföra en specifik affärsfunktion när data är okända eller inte meningsfulla, skapa den utan rädsla. Vi kan ju inte fylla i kolumner som "Dödsdatum" eller "Uppsägningdatum" i förväg, vi är ju inte spådomsvisare som pekar på himlen :-).

De flesta mjukvaror för modellering (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) tillåter skapandet av prototyper av datadomäner. Detta säkerställer inte bara korrekt datatyp, applikationslogik och bra prestanda, utan också ett obligatoriskt värde.

5. Föredra naturlig

När du bestämmer vilken kolumn i tabellen som ska väljas som nyckel, bör du alltid ta hänsyn till vilka fält användaren kan redigera. Välj dem aldrig som nyckel – det är en dålig idé. Vad som helst kan hända, och du måste garantera unikhet.

Det är bäst att använda en naturlig eller affärsnystartnyckel (natural key). Den har en meningsfull innebörd, så att du undviker dubbletter i databasen. 

Om inte affärsnystartnyckeln är unik (namn, efternamn, befattning) och upprepas i olika rader i tabellen eller måste ändras, bör en genererad artificiell nyckel (artificial key) utses som primär nyckel.

6. Normalisera i måttlig omfattning

För att effektivt organisera data i databasen måste du följa en uppsättning rekommendationer och normalisera databasen. Det finns fem normalformer som du måste följa.
Genom normalisering undviker du överflöd och säkerställer dataintegritet som används i applikationen eller på webbplatsen.

Som alltid bör allt göras med måtta, även normalisering. Om databasen har för många tabeller med samma unika nycklar har du blivit för ivrig och normaliserat databasen för mycket. Överdriven normalisering påverkar databasens prestanda negativt.

7. Testa tidigt, testa ofta

Testplanen och korrekt testning bör vara en del av databasen design.

Det är bäst att testa databasen genom Continuous Integration (kontinuerlig integrering). Modellera scenariot "En dag i databasen liv" och kontrollera om alla gränsfall hanteras, samt vilka användarinteraktioner som är sannolika. Ju tidigare du hittar buggar, desto mer tid och pengar sparar du.

Detta är bara sju råd som du kan använda för att designa en fantastisk databas i fråga om prestanda och effektivitet. Genom att följa dem undviker du de flesta huvudvärk i framtiden. Dessa råd är bara toppen av isberget inom databasmodellering. Det finns många livshackar. Vilka använder du?

Källa: habr.com