Tips för bättre databasdesign

Under årens lopp, som datamodellerare och databasarkitekt, har jag märkt att det finns ett par regler som bör följas under datamodellering och utveckling. Här beskriver jag några tips i hopp om att de kan hjälpa dig. Jag har listat tipsen i den ordning som de inträffar under projektets livscykel istället för att lista dem efter betydelse eller efter hur vanliga de är.

1. Planera framåt

Att misslyckas med att planera planerar att misslyckas.

Alan Lakein

Ett problem som jag har sett är när datamodellering sker samtidigt som mjukvaruutveckling. Det här är som att bygga grunden innan du slutför ritningarna. Tidigare verkade planering vara ett självklart steg innan utvecklingen påbörjades. Utvecklingsteam skulle inte skapa databaser utan planering precis som arkitekter inte skulle bygga byggnader utan ritningar.

Vid applikationsutveckling är det viktigt att förstå informationens natur.

Planering ignoreras ofta så att utvecklare bara kan "börja koda". Projektet startar och när problem dyker upp finns det ingen slack i schemat för att ta itu med dem. Utvecklare tar genvägar med avsikten att fixa dem senare, men detta händer sällan om någonsin.

Noggrann planering är hur du säkerställer att du får en ordentlig databas som inte hackas ihop. Om du inte lägger ner tid och ansträngning i förväg på att ta itu med de data som krävs av processerna, betalar du för det senare med en databas som måste omarbetas, ersättas eller skrotas.

Även om planering inte alltid görs, följer många datamodellerare fortfarande dessa riktlinjer. Det betyder inte att vi kan förutsäga varje designbehov i förväg, men de flesta modellbyggare anser att det är värt ansträngningen att förstå data och dess användning. Du vill inte ha en design för transaktionsbearbetning när behovet är att skapa analytiska rapporter.

Tiderna har förändrats; Agila metoder är vanligare så databasteam måste ompröva sin strategi för datamodellering. I Agile används domänmodellen från användningsfall istället för Entity Relationship Diagrams. Planeringsbehovet har dock inte minskat. Vi måste förstå informationen och vad den ska göra. I allmänhet måste de första sprintarna fokusera på datadesign.

Så det är inte Agile som är problemet för databasmodellerare, utan snarare individer som inte förstår datas natur. Vissa ser databasutveckling som samma sak som applikationsutveckling. Databasmodellering och mjukvaruutveckling är olika och behöver lämpligt fokus.

Databasen är kärnan i de flesta programvaror. Du måste ta dig tid att analysera kraven och hur datamodellen kommer att uppfylla dem. Detta minskar chansen att utvecklingen tappar kurs och riktning.

Utvecklarna måste förstå vikten av data och dess bidrag till utvecklingsprocessen. Vi lever i informationsåldern. Applikationer visar och manipulerar data. Det är informationen som finns i data som ger mening åt applikationen.

Det är inte möjligt att förutse alla krav och inte heller varje fråga, men det är viktigt att förbereda sig för problem genom noggrann planering.

2. Dokumentera din modell

När man gör en datamodell verkar allt självklart. Du namnger föremålen så att deras syfte är uppenbart och alla kommer att förstå innebörden bara genom att läsa namnet. Detta kan vara sant, men det är inte så självklart som du kanske tror. När du väljer namn för tabeller och kolumner, gör det tydligt vad användningen av varje objekt kommer att vara. Med tiden kommer innebörden av objekt att vara otydlig utan dokumentation.

Att använda en namnkonvention är ett steg mot effektiv dokumentation. När du måste göra ändringar i framtiden kommer du att uppskatta all befintlig dokumentation. Ett kort, enkelt dokument som beskriver de beslut du fattade och beskriver designen hjälper dig att förklara designvalet vid den tidpunkten.

Du vill ha tillräckligt med dokumentation så att databasen kan hanteras av en ny administratör och de kan förstå innebörden utan att behöva återkomma till dig för förklaring. Om datamodellen och miljön inte är dokumenterad är det svårt att underhålla eller ändra den i takt med att kraven förändras.

Till viss del har dokumentation lite med datamodelleringen att göra. Dokumentation handlar om att kommunicera designen och göra den begriplig i framtiden.

Dokumentation är ofta en eftertanke. När scheman är korta ignoreras dokumentationen. Ändå är detta teknisk skuld med höga kostnader. Att skära hörn under utvecklingscykeln kommer att dra på sig kostnader i framtiden för databasändringar, problemidentifiering, spårning av buggar och för att förstå datamodellen och datans natur.

Som ett exempel har datamodeller ofta ett "ID"-fält som primärnyckel för en tabell eller en del av namnet på en nyckel. Detta kan vara en primärnyckel som TransactionID på Transaction tabell. Om vissa tabeller använder "Nummer" som en del av namnet på en nyckel, är det bra att dokumentera varför. Kanske ReferenceNumber används som namn på primärnyckeln på meddelandet eftersom det är så referensen heter inom affärsområdet. Till exempel i finansiella tjänster innehåller finansiella meddelanden vanligtvis ett referensnummer.

Dokumentera definitionen av tabeller, kolumner och relationer så att programmerare kan komma åt informationen. Dokumentationen ska beskriva förväntningar på databasstrukturen.

I Vertabelo-verktyget kan jag omedelbart inkludera kommentarer på alla objekt:tabeller, kolumner, referenser, alternativa nycklar, vilket innebär att dokumentationen lagras omedelbart med min modell snarare än i något extra dokument som ska underhållas separat.

Dålig eller frånvarande dokumentation beror ofta på kortsiktigt tänkande, men ignorera inte dess betydelse. Detta är fortfarande ett problem att lösa.

3. Följ konventioner

Namnkonventioner kanske inte verkar viktiga under designen. I verkligheten ger namn insikten för att förstå en modell. De är en introduktion och bör vara logiska.

Inkonsekvent namngivning tjänar inget syfte. Det frustrerar bara utvecklare som måste komma åt data, administratörer av databasen och modellbyggare som måste göra ändringar i framtiden.

När "ID" används för vissa konstgjorda nycklar men vissa tabeller använder en annan namnkonvention (som nummer), kan utvecklare, analytiker och DBA:er slösa tid på att förstå undantagen. Svaga namnkonventioner leder också till fel i utvecklingen eftersom namngivningen inte är konsekvent.

Hand i hand med dokumentation, genom att använda en namnkonvention, blir det i framtiden för någon att förstå modellen. Växla inte slumpmässigt mellan att använda "ID" (som CustomerID ) och "Number" (AccountNumber ) som nycklar för tabeller. Gör undantag från konventionerna endast när de är motiverade. Dokumentera vad undantaget är och varför konventionen inte respekteras.

Detsamma gäller kryptiska namn som "XRT1" – är det de utökade referenstabellerna? Din gissning är lika bra som min. Jag hoppas att designern visste varför han valde ett så kryptiskt namn, men jag tvivlar på att nästa person som kommer åt databasen kan gissa anledningen.

Namnkonventioner är en fråga om personligt val. Se till att besluten är konsekventa och dokumenterade.

Om jag lyckades övertyga dig att tillämpa namnkonventionen i din databasdesign, läs gärna min nästa artikel som helt ägnas åt detta ämne.

4. Tänk noga på nycklar

Nycklar skapar ofta kontroverser:primärnycklar, främmande nycklar och konstgjorda nycklar. Tabeller behöver en primärnyckel som identifierar varje rad. Konsten är att bestämma vilka kolumner som ska vara en del av primärnyckeln och vilka värden som ska inkluderas.

För korrekt normalisering behöver varje tabell en identifieringsnyckel. Det unika måste garanteras. Ändå behöver naturliga nycklar och primärnycklar inte vara samma. Faktum är att de kanske inte är det, så länge bordet har en naturlig nyckel.

Vissa datamodellerare föredrar en konstgjord nyckel för att vara unik. Ändå föredrar vissa modellbyggare en naturlig nyckel för att säkerställa dataintegritet.

Så, ska vi använda en naturlig nyckel som primärnyckel? En utmaning uppstår om den naturliga nyckeln måste ändras. Om den naturliga nyckeln består av många kolumner kan du behöva göra ändringar på många ställen. En annan utmaning är att använda en konstgjord nyckel som den enda nyckeln för ett bord.

Som ett exempel kan du ha en tabell med information om produkter. Tabellen kan definieras med en konstgjord nyckel såsom en sekvens, en kod för produktens korta alfabetiska namn och produktdefinitionen. Om unikhet endast säkerställs av den konstgjorda nyckeln, kan det finnas två rader med samma produktkod. Är det samma produkt som anges två gånger? Kanske är en nyckel med produktkoden lämpligare.

5. Använd integritetskontroller försiktigt

För att säkerställa dataintegritet behöver vi främmande nycklar och begränsningar. Var noga med att inte överanvända eller underutnyttja dessa integritetskontroller.

Domäntabeller är effektiva för att upprätthålla integritet. Domäntabeller fungerar bra när det finns många värden att kontrollera mot, eller om värdena som ska kontrolleras ofta ändras.

En fråga kan vara att utvecklare beslutar att applikationen ska kontrollera integriteten. Problemet här är att en central databas kan nås av många applikationer. Dessutom vill du vanligtvis skydda data där den finns:i databasen.

Om de möjliga värdena är begränsade eller inom ett intervall, kan en kontrollbegränsning vara att föredra. Låt oss säga att meddelanden definieras som antingen inkommande eller utgående, i vilket fall det inte finns något behov av en främmande nyckel. Men för något som giltiga valutor, även om dessa kan verka statiska, ändras de faktiskt från tid till annan. Länder går med i en valutaunion och valutor ändras.

Applikationer bör också utföra integritetskontroller, men lita inte bara på applikationen för integritetskontroll. Att definiera integritetsregler på databasen säkerställer att dessa regler aldrig kommer att överträdas. På detta sätt uppfyller data alltid de definierade integritetsreglerna.

6. Glöm inte index i din design

Viss indexeringsdesign är användbar under databasmodellering, även om index kan ändras under faktisk driftsättning och användning. Naturligtvis är det möjligt att ha för många index, precis som det är möjligt att ha för få.

Indexering är en pågående process. Under design startar du processen på din modell. Designarbetet ligger på de primära nycklarna och begränsningarna.

Index är viktiga när man överväger frågor om data. När du modellerar bör du överväga hur data kommer att efterfrågas. Se till att inte överindexera. Indexering kretsar kring frågeoptimering.

7. Undvik vanliga uppslagstabeller

Jag har ofta sett en vanlig uppslagstabell för attributpar. Att definiera en enda, generisk domäntabell uppfattas för att förenkla designen. Denna stil av domäntabell gör en abstrakt definition för att hålla text. Jag har hört att det kallas en "Tillåtet värde" eller "Giltigt värden"-tabell, men termen "MUCK"-tabell myntades för detta antimönster 2006:Massively Unified Code-Key.

MUCK-tabeller innehåller orelaterade data.

Du kan till exempel ha en tabell som definierar domänen, posten och en beskrivning. Om vi ​​tänker tillbaka på meddelandeexemplet ovan kan två poster vara:

Lägg nu till poster för en annan domän:

Det här är bara en enda röra. Vad betyder tabellen?

Bara för skojs skull modellerade jag ett enkelt exempel på ett MUCK-bord (eller OTLT, "One True Lookup Table" om du är ett Tolkien-fan) och inkluderade några kommentarer. Observera att detta är ett antimönster och jag rekommenderar inte att du använder det i din datamodell.

Med MUCK-tabeller kan begränsningar inte definieras. MUCKs kan bli många rader utan någon mening. När du måste fråga en annan tabell för att förstå innebörden av ett fält, är detta inte idealiskt.

Dessa "allt går"-tabeller gör integritetskontroller komplicerade eller till och med omöjliga. En anledning till att dessa tabeller kan skapas är att flera tabeller i databasen har en liknande definition. Då blir dataintegritetskontroller omöjliga. Dessutom kan deras storlek bli ganska stor.

Normalisering bör leda bort från MUCK-tabeller. En enda tabell ska representera en enda domän; snarare än en enda (MUCK) tabell som representerar alla domänerna. Utan MUCK-tabeller kan vi införa begränsningar för främmande nyckel.

Använd separata tabeller för domänobjekt istället för att stoppa in dem i en enda tabell. Detta tillåter korrekta kolumntyper, begränsningar och relationer. En "Tillåtna värden"-tabell är bara smuts och har ingen plats i en datamodell.

8. Definiera en arkiveringsstrategi

Alltför ofta har jag sett databaser skapade utan en ordentlig strategi för datalagring och arkivering. Hur länge kommer data att hållas tillgängliga online i aktiva databastabeller? De flesta system är byggda för att hålla data i databasen "för alltid". För de flesta system är detta inte en rimlig långsiktig strategi för datalagring. Vid något tillfälle bör aktiv data arkiveras.

Ett tillvägagångssätt som jag förespråkar är att inkludera datalagring som en del av dina designöverväganden. Kommer du att ha aktiva och historiska tabeller så att insättningar av nya rader i de aktiva tabellerna förblir snabba, medan sökningar på historiska data kan optimeras?

Detta undviker att behöva designa om arkivering i din databas ovanpå den ursprungliga designen.

9. Testa tidigt, testa ofta

För att parafrasera Al Capone (eller John Van Buren, son till den 8:e amerikanska presidenten), "testa tidigt, testa ofta". På så sätt följer du den kontinuerliga integrationens väg. Att testa i ett tidigt utvecklingsskede sparar tid och pengar.

Testning är alltid en utmaning i utvecklingsplanen. Det finns ofta en testfas i slutet av en Agile Sprint och systemtestning i slutet av utvecklingen. Testning är i allmänhet det första som måste klämmas när tiden blir knapp.

Vid testning av databasen bör målet vara att simulera en produktionsmiljö:"A Day in the Life of the Database". Vilka volymer kan förväntas? Vilka användarinteraktioner är troliga? Handläggs gränsfallen?

Så testplanen och korrekt testning måste vara en integrerad del av datamodelleringen och databasutvecklingen.

Slutsats

Det här är de viktigaste frågorna som jag har sett när jag arbetat med datamodellerare och granskat datamodeller. Genom att uppmärksamma dessa tips kommer din databas att bli bättre utformad och mer robust. Ändå är återbetalningen på vissa av dessa investeringar inte alltid uppenbar eller synlig. Planera, dokumentera, använd standarder, skapa nycklar, säkerställ integritet, utför indexering, undvik MUCK, utveckla strategier och TEST!

Ingen av dessa aktiviteter kommer att ta enormt lång tid men har en enorm inverkan på kvaliteten på din datamodell.

Vad tycker du om dessa tips?

Har du egna tips?