Tips til bedre databasedesign

Gennem årene, hvor jeg arbejdede som datamodeller og databasearkitekt, har jeg bemærket, at der er et par regler, der bør følges under datamodellering og udvikling. Her beskriver jeg nogle tips i håbet om, at de kan hjælpe dig. Jeg har listet tipsene i den rækkefølge, de forekommer i løbet af projektets livscyklus i stedet for at angive dem efter vigtighed eller efter, hvor almindelige de er.

1. Planlæg forud

Man planlægger at mislykkes, hvis man ikke planlægger.

Alan Lakein

Et problem, som jeg har set, er, når datamodellering sker samtidig med softwareudvikling. Det er som at bygge fundamentet, før du færdiggør tegningerne. Før i tiden virkede planlægning som et oplagt skridt, før man påbegyndte udviklingen. Udviklingsteams ville ikke oprette databaser uden planlægning, ligesom arkitekter ikke ville bygge bygninger uden tegninger.

I applikationsudvikling er det afgørende at forstå karakteren af ​​dataene.

Planlægning ignoreres ofte, så udviklere bare kan "begynde at kode". Projektet starter, og når problemer dukker op, er der ingen slæk i tidsplanen til at løse dem. Udviklere tager genveje med den hensigt at rette dem senere, men det sker sjældent eller aldrig.

Omhyggelig planlægning er, hvordan du sikrer, at du ender med en ordentlig database, der ikke er hacket sammen. Hvis du ikke bruger tid og kræfter på forhånd på at adressere de data, der kræves af processerne, betaler du for det senere med en database, der skal omarbejdes, udskiftes eller kasseres.

Selvom planlægningen ikke altid udføres, følger mange datamodelbyggere stadig disse retningslinjer. Det betyder ikke, at vi kan forudsige ethvert designbehov på forhånd, men de fleste modelbyggere mener, at det er umagen værd at forstå dataene og deres brug. Du ønsker ikke et design til transaktionsbehandling, når behovet er analytisk rapportoprettelse.

Tiderne har ændret sig; Agile metoder er mere udbredte, så databaseteams må genoverveje deres tilgang til datamodellering. I Agile bruges domænemodellen fra Use Cases i stedet for Entity Relationship Diagrams. Behovet for planlægning er dog ikke blevet mindre. Vi skal forstå dataene, og hvad de skal gøre. Generelt skal de første par Sprints fokusere på datadesign.

Så det er ikke Agile, der er problemet for databasemodellere, men snarere enkeltpersoner, der ikke forstår karakteren af ​​data. Nogle ser databaseudvikling som det samme som applikationsudvikling. Databasemodellering og softwareudvikling er forskellige og kræver passende fokus.

Databasen er kernen i de fleste softwareapplikationer. Du skal tage dig tid til at analysere kravene, og hvordan datamodellen vil opfylde dem. Dette mindsker chancen for, at udviklingen mister kurs og retning.

Udviklerne skal forstå vigtigheden af ​​data og deres bidrag til udviklingsprocessen. Vi lever i informationsalderen. Applikationer viser og manipulerer data. Det er informationen i dataene, der giver mening til applikationen.

Det er ikke muligt at forudse ethvert krav eller ethvert problem, men det er vigtigt at forberede sig på problemer ved omhyggelig planlægning.

2. Dokumenter din model

Når man laver en datamodel, virker alt indlysende. Du navngiver objekterne, så deres formål er tydeligt, og alle vil forstå betydningen blot ved at læse navnet. Dette kan være sandt, men det er ikke så indlysende, som du måske tror. Når du vælger navne til tabeller og kolonner, skal du gøre det klart, hvad brugen af ​​hvert objekt vil være. Over tid vil betydningen af ​​objekter være uklar uden dokumentation.

Brug af en navnekonvention er et skridt mod effektiv dokumentation. Når du skal foretage ændringer i fremtiden, vil du sætte pris på al eksisterende dokumentation. Et kort, simpelt dokument, der beskriver de beslutninger, du har truffet, og beskriver designet vil hjælpe med at forklare designvalget på det tidspunkt.

Du vil have tilstrækkelig dokumentation, så databasen kan administreres af en ny administrator, og de kan forstå meningen uden at skulle vende tilbage til dig for at få forklaring. Hvis datamodellen og miljøet ikke er dokumenteret, er det svært at vedligeholde eller ændre det i takt med at kravene ændrer sig.

Til en vis grad har dokumentation ikke meget med datamodelleringen at gøre. Dokumentation handler om at formidle designet og gøre det forståeligt i fremtiden.

Dokumentation er ofte en eftertanke. Når tidsplanerne er korte, bliver dokumentation ignoreret. Alligevel er dette teknisk gæld med høje omkostninger. At skære hjørner under udviklingscyklussen vil påløbe omkostninger i fremtiden til databaseændringer, problemidentifikation, sporing af fejl og for at forstå datamodellen og dataenes art.

Som et eksempel har datamodeller ofte et "ID"-felt som den primære nøgle til en tabel eller en del af navnet på en nøgle. Dette kan være en primær nøgle såsom TransactionID på Transaction bord. Hvis nogle tabeller bruger "Number" som en del af navnet på en nøgle, så er det godt at dokumentere hvorfor. Måske ReferenceNumber bruges som navnet på den primære nøgle på Beskeden, fordi det er det, referencen hedder i forretningsområdet. For eksempel i finansielle tjenester indeholder finansielle meddelelser typisk et referencenummer.

Dokumenter definitionen af ​​tabeller, kolonner og relationer, så programmører kan få adgang til oplysningerne. Dokumentationen skal beskrive forventninger til databasestrukturen.

I Vertabelo-værktøjet kan jeg med det samme inkludere kommentarer til ethvert element:tabeller, kolonner, referencer, alternative nøgler, hvilket betyder, at dokumentationen gemmes med det samme med min model i stedet for i et ekstra dokument, der skal vedligeholdes separat.

Dårlig eller manglende dokumentation skyldes ofte kortsynet tænkning, men ignorer ikke dens betydning. Dette er stadig et problem, der skal løses.

3. Følg konventioner

Navnekonventioner forekommer måske ikke vigtige under designet. I virkeligheden giver navne indsigten til at forstå en model. De er en introduktion og bør være logiske.

Inkonsekvent navngivning tjener intet formål. Det frustrerer kun udviklere, der skal have adgang til dataene, administratorer af databasen og modelbyggere, der skal foretage ændringer i fremtiden.

Når "ID" bruges til nogle kunstige nøgler, men nogle tabeller bruger en anden navnekonvention (såsom nummer), kan udviklere, analytikere og DBA'er spilde tid på at forstå undtagelserne. Svage navnekonventioner fører også til fejl i udviklingen, fordi navngivningen ikke er konsistent.

Hånd i hånd med dokumentation gør brugen af ​​en navnekonvention det i fremtiden for nogen at forstå modellen. Skift ikke tilfældigt mellem at bruge "ID" (som CustomerID ) og "Number" (AccountNumber ) som nøgler til tabeller. Foretag kun undtagelser fra konventionerne, når de er berettigede. Dokumentér, hvad undtagelsen er, og hvorfor konventionen ikke overholdes.

Det samme gælder kryptiske navne som "XRT1" - er det de udvidede referencetabeller? Dit gæt er lige så godt som mit. Jeg håber, at designeren vidste, hvorfor han valgte et så kryptisk navn, men jeg tvivler på, at den næste person, der får adgang til databasen, kan gætte årsagen.

Navnekonventioner er et spørgsmål om personligt valg. Sørg for, at beslutninger er konsekvente og dokumenterede.

Hvis det lykkedes mig at overbevise dig om at anvende navnekonvention i dit databasedesign, er du velkommen til at læse min næste artikel, der udelukkende er viet til dette emne.

4. Tænk grundigt over nøgler

Nøgler genererer ofte kontroverser:primære nøgler, fremmednøgler og kunstige nøgler. Tabeller har brug for en primær nøgle, der identificerer hver række. Kunsten er at bestemme, hvilke kolonner der skal være en del af den primære nøgle, og hvilke værdier der skal inkluderes.

For korrekt normalisering skal hver tabel have en identifikationsnøgle. Unikitet skal garanteres. Alligevel behøver naturlige nøgler og primære nøgler ikke at være de samme. Det kan de faktisk ikke være, så længe bordet har en naturlig nøgle.

Nogle datamodelbyggere foretrækker en kunstig nøgle for unikhed. Alligevel foretrækker nogle modelbyggere en naturlig nøgle til at sikre dataintegritet.

Så skal vi bruge en naturlig nøgle som den primære nøgle? En udfordring opstår, hvis den naturlige nøgle skal ændres. Hvis den naturlige nøgle består af mange kolonner, skal du muligvis lave ændringer mange steder. En anden udfordring er at bruge en kunstig nøgle som den eneste nøgle til et bord.

Som et eksempel kan du have en tabel med oplysninger om produkter. Tabellen kan defineres med en kunstig nøgle såsom en sekvens, en kode for det korte alfabetiske navn for produktet og produktdefinitionen. Hvis unikhed kun sikres af den kunstige nøgle, kan der være to rækker med samme produktkode. Er det det samme produkt, der indtastes to gange? Måske er en nøgle med produktkoden mere passende.

5. Brug integritetstjek omhyggeligt

For at sikre dataintegritet har vi brug for fremmednøgler og begrænsninger. Pas på ikke at overbruge eller underbruge disse integritetstjek.

Domænetabeller er effektive til at håndhæve integritet. Domænetabeller fungerer godt, når der er mange værdier, der skal kontrolleres i forhold til, eller de værdier, der skal kontrolleres, ofte ændrer sig.

Et problem kan være, at udviklere beslutter, at applikationen vil kontrollere integriteten. Problemet her er, at en central database kan tilgås af mange applikationer. Desuden ønsker du generelt at beskytte dataene, hvor de er:i databasen.

Hvis de mulige værdier er begrænsede eller inden for et område, kan en kontrolbegrænsning være at foretrække. Lad os sige, at beskeder er defineret som enten indgående eller udgående, i hvilket tilfælde der ikke er behov for en fremmednøgle. Men for noget som gyldige valutaer, selvom disse kan virke statiske, ændrer de sig faktisk fra tid til anden. Lande tilslutter sig en valutaunion, og valutaer ændres.

Applikationer bør også udføre integritetstjek, men stoler ikke kun på applikationen til integritetskontrol. At definere integritetsregler på databasen sikrer, at disse regler aldrig vil blive overtrådt. På denne måde opfylder dataene til enhver tid de definerede integritetsregler.

6. Glem ikke indekser i dit design

Noget indekseringsdesign er nyttigt under databasemodellering, selvom indekser kan ændre sig under den faktiske implementering og brug. Det er selvfølgelig muligt at have for mange indekser, ligesom det er muligt at have for få.

Indeksering er en løbende proces. Under design starter du processen på din model. Designarbejde er på de primære nøgler og begrænsninger.

Indekser er vigtige, når man overvejer forespørgsler på dataene. Når du modellerer, bør du overveje, hvordan dataene vil blive forespurgt. Pas på ikke at overindeksere. Indeksering drejer sig om forespørgselsoptimering.

7. Undgå almindelige opslagstabeller

Jeg har ofte set en fælles opslagstabel for attributpar. At definere en enkelt generisk domænetabel opfattes som en forenkling af designet. Denne stil af domænetabel laver en abstrakt definition for at holde tekst. Jeg har hørt det kaldet en "Tilladt værdi"- eller "Gyldige værdier"-tabel, men udtrykket "MUCK"-tabel blev opfundet for dette anti-mønster i 2006:Massively Unified Code-Key.

MUCK-tabeller indeholder ikke-relaterede data.

For eksempel kan du have en tabel, der definerer domænet, posten og en beskrivelse. Når man tænker tilbage på meddelelseseksemplet ovenfor, kan to indgange være:

Tilføj nu indgange for et andet domæne:

Det her er bare noget rod. Hvad betyder tabellen?

For sjovs skyld modellerede jeg et simpelt eksempel på et MUCK-bord (eller OTLT, "One True Lookup Table", hvis du er Tolkien-fan) og inkluderede nogle kommentarer. Bemærk venligst, at dette er et anti-mønster, og jeg anbefaler ikke, at du bruger det i din datamodel.

Med MUCK-tabeller kan begrænsninger ikke defineres. MUCKs kan blive til mange rækker uden nogen betydning. Når du skal forespørge i en anden tabel for at forstå betydningen af ​​et felt, er dette ikke ideelt.

Disse "alt går"-tabeller gør integritetstjek komplekse eller endda umulige. En grund til, at disse tabeller kan oprettes, er fordi flere tabeller i databasen har en lignende definition. Så bliver dataintegritetstjek umuligt. Deres størrelse kan også blive ret stor.

Normalisering bør føre væk fra MUCK-tabeller. En enkelt tabel skal repræsentere et enkelt domæne; snarere end en enkelt (MUCK) tabel, der repræsenterer alle domænerne. Uden MUCK-tabeller kan vi indføre fremmednøglebegrænsninger.

Brug separate tabeller til domæneobjekter i stedet for at proppe dem i en enkelt tabel. Dette tillader korrekte kolonnetyper, begrænsninger og relationer. En "Tilladte værdier"-tabel er bare møg og har ingen plads i en datamodel.

8. Definer en arkiveringsstrategi

Alt for ofte har jeg set databaser oprettet uden en ordentlig strategi for dataopbevaring og arkivering. Hvor længe vil data blive holdt online tilgængelige i aktive databasetabeller? De fleste systemer er bygget til at holde data i databasen "for evigt". For de fleste systemer er dette ikke en rimelig langsigtet dataopbevaringsstrategi. På et tidspunkt skal aktive data arkiveres.

En tilgang, som jeg går ind for, er at inkludere dataopbevaring som en del af dine designovervejelser. Vil du have aktive og historiske tabeller, så indsættelser af nye rækker i de aktive tabeller forbliver hurtige, mens søgninger på historiske data kan optimeres?

Dette undgår at skulle redesigne arkivering i din database oven på det originale design.

9. Test tidligt, test ofte

For at parafrasere Al Capone (eller John Van Buren, søn af den 8. amerikanske præsident), "test tidligt, test ofte". På denne måde følger du den kontinuerlige integrations vej. Test på et tidligt udviklingsstadium sparer tid og penge.

Test er altid en udfordring i udviklingsplanen. Der er ofte en testfase i slutningen af ​​en Agile Sprint og systemtest i slutningen af ​​udviklingen. Test er generelt det første, der skal presses, når tiden bliver knap.

Ved test af databasen bør målet være at simulere et produktionsmiljø:"A Day in the Life of the Database". Hvilke mængder kan forventes? Hvilke brugerinteraktioner er sandsynlige? Behandles grænsesager?

Så testplanen og korrekt test skal være en integreret del af datamodelleringen og databaseudviklingen.

Konklusion

Dette er de vigtigste problemer, som jeg har set, når jeg arbejdede med datamodellere og gennemgang af datamodeller. Ved at være opmærksom på disse tips bliver din database bedre designet og mere robust. Alligevel er tilbagebetalingen på nogle af disse investeringer ikke altid indlysende eller synlig. Planlæg, dokumenter, brug standarder, skab nøgler, sørg for integritet, udfør indeksering, undgå MUCK, udvikle strategier og TEST!

Ingen af ​​disse aktiviteter vil tage enormt lang tid og alligevel have en enorm indflydelse på kvaliteten af ​​din datamodel.

Hvad er dine synspunkter om disse tips?

Har du dine egne tips?