I påvente av starten på neste strømning med hastigheten Vi har utarbeidet et lite forfattermateriale med viktige tips for utforming av en database. Vi håper dette materialet vil være nyttig for deg.
Databaser er overalt: fra de enkleste bloggene og katalogene til pålitelige informasjonssystemer og store sosiale nettverk. Om databasen er enkel eller kompleks er ikke så viktig som det er viktig å utforme den riktig. Når en database er utformet tankeløst og uten en klar forståelse av formålet, er det ikke bare ineffektivt, men videre arbeid med databasen vil være en ekte plage, en ugjennomtrengelig skog for brukerne. Her er noen databasedesigntips som vil hjelpe deg å lage et nyttig og brukervennlig produkt.
1. Bestem hva tabellen er for og hva dens struktur er
I dag hjelper utviklingsmetoder som Scrum eller RAD (Rapid Application Development) IT-team med å utvikle databaser raskt. Men i jakten på tid er fristelsen veldig stor til å dykke rett inn i å bygge en base, vagt forestille seg hva selve målet er, hva de endelige resultatene skal være.
Det er som om teamet er fokusert på effektivt og raskt arbeid, men dette er en luftspeiling. Jo lenger og raskere du dykker ned i dybden av prosjektet, jo mer tid vil det ta å identifisere og endre feil i databasedesignet.
Så det første du må bestemme deg for er å definere formålet med databasen din. Hvilken type applikasjon utvikles databasen for? Vil brukeren kun jobbe med poster og må ta hensyn til transaksjoner, eller er han mer interessert i dataanalyse? Hvor skal basen utplasseres? Vil den spore kundeatferd eller bare administrere kundeforhold?
Jo raskere designteamet svarer på disse spørsmålene, desto jevnere vil databasedesignprosessen være.
2. Hvilke data bør jeg velge for lagring?
Planlegge på forhånd. Tanker om hva nettstedet eller systemet som databasen er designet for vil gjøre i fremtiden. Det er viktig å gå utover de enkle kravene i de tekniske spesifikasjonene. Bare ikke begynn å tenke på alle mulige typer data som en bruker noen gang vil lagre. Tenk heller på om brukere vil kunne skrive innlegg, laste opp dokumenter eller bilder eller utveksle meldinger. Hvis dette er tilfelle, må du tildele plass til dem i databasen.
Arbeid med teamet, avdelingen eller organisasjonen som designbasen vil bli støttet for i fremtiden. Kommuniser med mennesker på ulike nivåer, fra kundeservicespesialister til avdelingsledere. På denne måten vil du ved hjelp av tilbakemeldinger få en klar ide om bedriftens krav.
Uunngåelig vil behovene til brukere innenfor selv samme avdeling komme i konflikt. Hvis du støter på dette, ikke vær redd for å stole på din egen erfaring og finne et kompromiss som passer alle parter og tilfredsstiller det endelige målet med databasen. Vær trygg: i fremtiden vil du motta +100500 i karma og et fjell av informasjonskapsler.
3. Modeller data med forsiktighet
Det er flere viktige punkter å være oppmerksom på når du modellerer data. Som vi sa tidligere, bestemmer formålet med databasen hvilke metoder som skal brukes i modellering. Hvis vi designer en database for online postbehandling (OLTP), med andre ord for å opprette, redigere og slette poster, bruker vi transaksjonsmodellering. Hvis databasen må være relasjonell, er det best å bruke flerdimensjonal modellering.
Under modellering bygges konseptuelle (CDM), fysiske (PDM) og logiske (LDM) datamodeller.
Konseptuelle modeller beskriver enheter og typene data de inkluderer, samt relasjonene mellom dem. Del opp dataene dine i logiske biter – det gjør livet mye enklere.
Det viktigste er moderasjon, ikke overdriv.
Hvis en enhet er svært vanskelig å klassifisere i ett ord eller en setning, er det på tide å bruke undertyper (underordnede enheter).
Hvis en enhet fører sitt eget liv, har attributter som beskriver dens oppførsel og utseende, samt forhold til andre objekter, kan du trygt bruke ikke bare en undertype, men også en supertype (overordnet enhet).
Hvis du neglisjerer denne regelen, vil andre utviklere bli forvirret i modellen din og vil ikke fullt ut forstå dataene og reglene for hvordan de samles inn.
Konseptuelle modeller implementeres ved å bruke logiske modeller. Disse modellene er som et veikart for fysisk databasedesign. I den logiske modellen identifiseres forretningsdataenheter, datatyper bestemmes og statusen til regelnøkkelen bestemmes som regulerer relasjonene mellom data.
Deretter sammenlignes den logiske datamodellen med den forhåndsvalgte DBMS-plattformen (database management system) og en fysisk modell oppnås. Den beskriver hvordan data lagres fysisk.
4. Bruk de riktige datatypene
Bruk av feil datatype kan føre til mindre nøyaktige data, problemer med å slå sammen tabeller, problemer med å synkronisere attributter og oppsvulmede filstørrelser.
For å sikre informasjonsintegritet må et attributt bare inneholde datatyper som er akseptable for det. Hvis alder er lagt inn i databasen, sørg for at kolonnen lagrer heltall på maksimalt 3 sifre.
Opprett et minimum av tomme kolonner med en NULL-verdi. Hvis du oppretter alle kolonnene som NULL, er dette en stor feil. Hvis du trenger en tom kolonne for å utføre en spesifikk forretningsfunksjon, når dataene er ukjente eller ennå ikke gir mening, kan du gjerne lage den. Tross alt kan vi ikke fylle ut kolonnene "Dødsdato" eller "Opsigelsesdato" på forhånd; vi er ikke predikanter som peker fingrene mot himmelen :-).
De fleste modelleringsprogramvare (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) data lar deg lage prototyper av dataregioner. Dette sikrer ikke bare riktig datatype, applikasjonslogikk og god ytelse, men også at verdien er påkrevd.
5. Gå naturlig
Når du bestemmer hvilken kolonne i en tabell som skal brukes som nøkkel, må du alltid vurdere hvilke felt brukeren kan redigere. Aldri velg dem som nøkkel - en dårlig idé. Alt kan skje, men du må sørge for at det er unikt.
Det er best å bruke en naturlig, eller forretningsnøkkel. Det har en semantisk betydning, så du vil unngå duplisering i databasen.
Med mindre forretningsnøkkelen er unik (fornavn, etternavn, posisjon) og gjentas i forskjellige rader i tabellen eller den må endres, skal den genererte kunstige nøkkelen angis som primærnøkkelen.
6. Normaliser med måte
For å effektivt organisere data i en database, må du følge et sett med retningslinjer og normalisere databasen. Det er fem normale former å følge.
Med normalisering unngår du redundans og sikrer integriteten til dataene som brukes i applikasjonen eller nettstedet ditt.
Som alltid skal alt være med måte, til og med normalisering. Hvis det er for mange tabeller i databasen med de samme unike nøklene, har du latt deg rive med og overnormalisert databasen. Overdreven normalisering påvirker databaseytelsen negativt.
7. Test tidlig, test ofte
Testplan og riktig testing bør være en del av databasedesign.
Den beste måten å teste databasen på er gjennom kontinuerlig integrasjon. Simuler en "dag i livet til en database"-scenario og sjekk om alle kantsaker er håndtert og hvilke brukerinteraksjoner som er sannsynlige. Jo raskere du finner feil, jo mer sparer du både tid og penger.
Dette er bare syv tips du kan bruke til å designe en fantastisk produktivitets- og effektivitetsdatabase. Følger du dem, slipper du mest hodepine i fremtiden. Disse tipsene er bare toppen av isfjellet i databasemodellering. Det er et stort antall life hacks. Hvilke bruker du?
Kilde: www.habr.com