Denormalisering
Denormalisering är en strategi som används på en tidigare normaliserad databas för att öka prestandan. Inom datorer är denormalisering processen att försöka förbättra läsprestandan för en databas , på bekostnad av att förlora en del skrivprestanda, genom att lägga till redundanta kopior av data eller genom att gruppera data. Det är ofta motiverat av prestanda eller skalbarhet i relationsdatabasprogramvara som behöver utföra ett mycket stort antal läsoperationer . Denormalisering skiljer sig från den onormaliserade formen genom att denormaliseringsfördelarna endast kan realiseras fullt ut på en datamodell som annars är normaliserad.
Genomförande
En normaliserad design kommer ofta att "lagra" olika men relaterade delar av information i separata logiska tabeller (kallade relationer). Om dessa relationer lagras fysiskt som separata diskfiler kan det vara långsamt att slutföra en databasfråga som hämtar information från flera relationer (en join-operation ). Om många relationer förenas kan det gå oöverkomligt långsamt. Det finns två strategier för att hantera detta.
DBMS-stöd
En metod är att hålla den logiska designen normaliserad, men tillåta databashanteringssystemet (DBMS) att lagra ytterligare redundant information på disken för att optimera frågesvar. I det här fallet är det DBMS-programvarans ansvar att se till att alla redundanta kopior hålls konsekventa. Denna metod implementeras ofta i SQL som indexerade vyer ( Microsoft SQL Server ) eller materialiserade vyer ( Oracle , PostgreSQL ). En vy kan, bland andra faktorer, representera information i ett format som är lämpligt för sökning, och indexet säkerställer att frågor mot vyn optimeras fysiskt.
DBA implementering
Ett annat tillvägagångssätt är att denormalisera den logiska datadesignen. Med försiktighet kan detta uppnå en liknande förbättring av frågesvar, men till en kostnad – det är nu databasdesignerns ansvar att se till att den denormaliserade databasen inte blir inkonsekvent. Detta görs genom att skapa regler i databasen som kallas constraints , som specificerar hur de redundanta kopiorna av information måste hållas synkroniserade, vilket lätt kan göra avnormaliseringsproceduren meningslös. Det är den ökade logiska komplexiteten i databasdesignen och den ökade komplexiteten hos de ytterligare begränsningarna som gör detta tillvägagångssätt farligt. Dessutom introducerar begränsningar en avvägning , påskyndar läsningar ( SELECT i SQL) medan skrivningar saktar ner ( INSERT , UPPDATERA och DELETE ). Detta innebär att en denormaliserad databas under hög skrivbelastning kan erbjuda sämre prestanda än dess funktionellt likvärdiga normaliserade motsvarighet.
Denormalisering kontra ej normaliserade data
En denormaliserad datamodell är inte detsamma som en datamodell som inte har normaliserats, och denormalisering bör endast ske efter att en tillfredsställande nivå av normalisering har ägt rum och att alla nödvändiga begränsningar och/eller regler har skapats för att hantera den inneboende anomalier i designen. Till exempel är alla relationer i tredje normalform och alla relationer med sammanfognings- och flervärdesberoenden hanteras på lämpligt sätt.
Exempel på denormaliseringstekniker inkluderar:
- "Lagra" antalet "många" element i en en-till-många-relation som ett attribut för "en"-relationen
- Lägga till attribut till en relation från en annan relation som den kommer att kopplas till
- Stjärnscheman , som även kallas faktadimensionsmodeller och har utökats till snöflingascheman
- Förbyggd sammanfattning eller OLAP-kuber
Med den fortsatta dramatiska ökningen av alla tre av lagring, processorkraft och bandbredd, på alla nivåer, har denormalisering i databaser flyttats från att vara en ovanlig eller förlängningsteknik, till det vanliga, eller till och med normen. Till exempel var en specifik nackdel med denormalisering helt enkelt att den "använder mer lagring" (det vill säga bokstavligen fler kolumner i en databas). Med undantag för riktigt enorma system, har just denna aspekt gjorts irrelevant och att använda mer lagring är en icke-fråga.