Foran starten af det næste kursusforløb har vi forberedt et lille originalt materiale med vigtige tips til konstruering af databaser. Vi håber, dette materiale vil være nyttigt for dig.
Databaser er overalt: fra simple blogs og kataloger til pålidelige informationssystemer og store sociale netværk. Det er ikke så vigtigt, om databasen er simpel eller kompleks, men hvor vigtigt det er at designe den korrekt. Når en database er designet tankeløst og uden klart forståelse for formålet, er den ikke bare ineffektiv, men videre arbejde med databasen vil være en reel prøvelse, en uigennemtrængelig skov for brugerne. Her er nogle tips til databasekonstruktion, som kan hjælpe med at skabe et nyttigt og brugervenligt produkt.
1. Bestem, hvad tabellen skal bruges til, og hvad dens struktur er
I dag hjælper udviklingsmetoder som Scrum eller RAD (Rapid Application Development) IT-teams med hurtigt at udvikle databaser. Men i jagten på tid er fristelsen stor for at dykke direkte ned i opbygningen af databasen, uden klart at have en idé om, hvad målet er, og hvilke endelige resultater der skal opnås.
Som om teamet sigter mod effektiv og hurtig arbejdsindsats, men det er en illusion. Jo længere og hurtigere man dykker ind i projektet, desto mere tid vil der være brug for til at identificere og ændre fejl i databaseprojektet.
Derfor er det første, man skal beslutte, at definere målet for din database. Hvilken type applikation udvikles databasen til? Vil brugeren kun arbejde med poster og skal der fokuseres på transaktioner, eller er de mere interesserede i dataanalyse? Hvor skal databasen implementeres? Skal den overvåge kundernes adfærd, eller skal den simpelthen styre forholdet mellem dem?
Jo tidligere designteamet besvarer disse spørgsmål, jo blødere og mere glidende vil processen med at designe databasen forløbe.
2. Hvilke data skal vælges til opbevaring?
Planlæg fremad. Tænk over, hvad hjemmesiden eller systemet, som databasen er designet til, vil gøre i fremtiden. Det er vigtigt at tænke ud over de enkle krav i den tekniske opgave. Men lad venligst være med at begynde at overveje alle mulige typer data, som brugeren nogensinde vil gemme, på én gang. Bedre at overveje, om brugerne vil kunne skrive indlæg, uploade dokumenter eller billeder, eller sende beskeder. Hvis det er tilfældet, skal databasen have plads til det.
Arbejd med teamet, afdelingen eller organisationen, som i fremtiden skal støtte den planlagte database. Kommunikér med personer på forskellige niveauer, fra kundeservicemedarbejdere til afdelingsledere. På den måde får du et klart billede af virksomhedens krav gennem feedback.
Det er uundgåeligt, at brugernes behov, selv inden for én afdeling, vil komme i konflikt med hinanden. Hvis du støder på dette, skal du ikke være bange for at trække på din egen erfaring og finde et kompromis, der tilfredsstiller alle parter og opfylder databasen slutmål. Vær sikker på, at du i fremtiden vil få +100500 i karma og en bjerg af småkager.
3. Modellér data med forsigtighed
Der er flere nøglepunkter, som man skal være opmærksom på ved modellering af data. Som tidligere nævnt afhænger de metoder, der skal anvendes ved modellering, af formålet med databasen. Hvis vi designer en database til operationel behandling af poster (OLTP), med andre ord til oprettelse, redigering og sletning af dem, bruger vi transaktionsmodellering. Hvis databasen derimod skal være relationel, er det bedst at anvende multidemensional modellering.
Under modellering opbygges konceptuelle (CDM), fysiske (PDM) og logiske (LDM) datamodeller.
Konceptuelle modeller beskriver enhederne og de datatyper, der er inkluderet, samt forholdene mellem dem. Del dine data op i logiske stykker — så er det meget nemmere at arbejde med.
Det vigtigste er moderation, lad være med at overdrive.
Hvis enheden er meget vanskelig at klassificere med ét ord eller udtryk, er det tid til at bruge underklasser (under-enheder).
Hvis en enhed lever sit eget liv, har attributter, der beskriver dens adfærd og udseende, samt relationer til andre objekter, kan man trygt bruge både subtype og supertype (forælder enhed).
Hvis man ser bort fra denne regel, vil andre udviklere blive forvirrede over din model og ikke helt forstå dataene og reglerne for, hvordan de skal samles.
Konceptuelle modeller realiseres gennem logiske modeller. Disse modeller fungerer som et vejkort til design af den fysiske database. I den logiske model fremhæves virksomhedens dataenheder, datatyper defineres, nøgleregler og relationerne mellem dataene reguleres.
Derefter sammenlignes den logiske datamodel med den på forhånd valgte DBMS-platform (databasesystem) og der opnås en fysisk model. database managementDen beskriver den fysiske lagringsmetode for data.
4. Brug passende datatyper
Anvendelsen af forkert datatype kan føre til mindre præcise data, vanskeligheder med at sammenflette tabeller, synkronisering af attributter og opblæsning af filstørrelser.
For at sikre integriteten af informationen skal attributten kun indeholde acceptable datatyper. Hvis der registreres en alder i databasen, skal det sikres, at kolonnen kun indeholder heltal på maks. 3 cifre.
Opret minimum af tomme kolonner med NULL-værdier. Hvis du opretter alle kolonner som NULL, er det en alvorlig fejl. Hvis du derimod har brug for en tom kolonne til at udføre en specifik forretningsfunktion, når dataene er ukendte eller endnu ikke giver mening, så opret den trygt. Vi kan jo ikke på forhånd udfylde kolonnerne 'Dødsdato' eller 'Afskedigelsesdato', vi er jo ikke profeter, der peger imod stjernerne :-).
De fleste modelleringssoftware (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) tillader oprettelse af prototyper af dataområder. Dette sikrer ikke kun den korrekte datatype, applikationens logik og god ydeevne, men også en obligatorisk angivelse af værdien.
5. Foretræk naturlige
Når du beslutter, hvilken kolonne i tabellen der skal vælges som nøgle, er det altid vigtigt at være opmærksom på, hvilke felter brugeren kan redigere. Vælg aldrig disse som nøgler – det er en dårlig idé. Alt kan ske, og du skal sikre unikhed.
Det bedste er at bruge en naturlig eller forretningsnøgle (natural key). Den har betydning, så undgår du duplikering i databasen.
Hvis forretningsnøglen ikke er unik (navn, efternavn, stilling) og gentages i forskellige rækker i tabellen, eller hvis den skal ændres, så er det en god idé at anvende en genereret kunstig, surrogatnøgle (artificial key) som primær nøgle.
6. Normaliser i moderation
For effektivt at organisere data i databasen er det nødvendigt at følge et sæt anbefalinger og normalisere databasen. Der er fem normale former, som du skal følge.
Med normalisering undgår du redundans og sikrer dataintegritet for data, der bruges i applikationen eller på hjemmesiden.
Som altid skal der være balance i alt, også normalisering. Hvis der er for mange tabeller i databasen med de samme unikke nøgler, så er du blevet for ivrig og har overnormaliseret databasen. Overnormalisering påvirker databasens ydeevne negativt.
7. Test tidligt, test ofte
Testplanen og korrekt testning bør være en del af designet af databasen.
Det bedste er at teste databasen gennem Continuous Integration (kontinuerlig integration). Modeller scenariet 'En dag i databasen' og kontroller, om alle grænsetilfælde håndteres, og hvilke brugerinteraktioner der er sandsynlige. Jo tidligere du finder fejl, desto mere tid og penge sparer du.
Dette er blot syv råd, som du kan bruge til at designe en fremragende database med hensyn til ydeevne og effektivitet. Hvis du følger dem, undgår du de fleste hovedpiner i fremtiden. Disse råd er kun toppen af isbjerget inden for databasemodellering. Der er mange tricks. Hvilke bruger du?
Kilde: habr.com
