Denormalizáció

A denormalizálás egy olyan stratégia, amelyet egy korábban normalizált adatbázison alkalmaznak a teljesítmény növelése érdekében. A számítástechnikában a denormalizálás az a folyamat, amelynek során az adatok redundáns másolatainak hozzáadásával vagy az adatok csoportosításával megpróbáljuk javítani az adatbázis olvasási teljesítményét, némi írási teljesítményveszteség árán.

Ezt gyakran a teljesítmény vagy a skálázhatóság motiválja a relációs adatbázis-szoftverekben, amelyeknek nagyon nagyszámú olvasási műveletet kell végrehajtaniuk. A denormalizálás abban különbözik a nem normalizált formától, hogy a denormalizálás előnyei csak egy egyébként normalizált adatmodellen realizálhatók teljes mértékben.

Végrehajtás

A normalizált tervezés gyakran "tárolja" a különböző, de egymással összefüggő információkat külön logikai táblákban (úgynevezett relációkban). Ha ezeket a relációkat fizikailag különálló lemezfájlokban tárolják, akkor egy olyan adatbázis-lekérdezés eredménye, amely több relációból merít információt (egyesítési művelet), lassú lehet. Ha sok relációt kell létrehozni, akkor ez a művelet rendkívül lassú lehet. Két stratégia létezik ennek kezelésére.

DBMS támogatás

Az egyik módszer az, hogy a logikai felépítést normalizálják, de az adatbázis-kezelő rendszer (DBMS) a lekérdezésekre adott válasz optimalizálása érdekében további redundáns információkat tárol a lemezen. Ebben az esetben a DBMS-szoftver felelőssége, hogy a redundáns másolatok konzisztensek (következetesek) maradjanak. Ezt a módszert gyakran az SQL-ben indexelt nézetek (Microsoft SQL Server) vagy materializált nézetek (Oracle, PostgreSQL) formájában valósítják meg. A nézet többek között a lekérdezéshez kényelmes formátumban reprezentálhat információt, és az index biztosítja, hogy a nézethez kapcsolt lekérdezések fizikailag optimalizáltak legyenek.

DBA megvalósítás

Egy másik megközelítés a logikai adattervezés denormalizálása. Óvatossággal ez is hasonló javulást eredményezhet a lekérdezésekre adott válaszban, de ennek ára van - most már az adatbázis tervezőjének a felelőssége, hogy a denormalizált adatbázis ne váljon inkonzisztenssé. Ez úgy történik, hogy az adatbázisban olyan szabályokat, úgynevezett kényszereket hozunk létre, amelyek meghatározzák, hogy a redundáns információmásolatokat hogyan kell szinkronban tartani, ami könnyen értelmetlenné teheti a de-normalizációs eljárást. Az adatbázis-tervezés logikai bonyolultságának növekedése és a további kényszerek által okozott további bonyolultság teszi ezt a megközelítést veszélyessé. Ráadásul a korlátozások kompromisszumokat hoznak létre, mivel felgyorsítják az olvasást (SELECT az SQL-ben), ugyanakkor lassítják az írást (INSERT, UPDATE és DELETE). Ez azt jelenti, hogy egy denormalizált adatbázis nagy írási terhelés alatt rosszabb teljesítményt nyújthat, mint a funkcionálisan egyenértékű normalizált megfelelője.

Denormalizáció kontra nem normalizált adat

A denormalizált adatmodell nem azonos a normalizálatlan adatmodellel, és a denormalizálásra csak azután kerülhet sor, hogy a normalizálás kielégítő szintje megtörtént, és hogy a tervezésben rejlő anomáliák kezeléséhez szükséges megkötések és/vagy szabályok elkészültek. Például az összes reláció harmadik normál formában van, és az összekapcsolódó és többértékű függőségeket tartalmazó relációkat megfelelően kezelik.

A denormalizációs technikák példái a következők:

• A "sok" elem számának "tárolása" egy egy-a-sokhoz kapcsolatban az "egy" kapcsolat attribútumaként.

• Attribútumok hozzáadása egy olyan relációhoz, amely egy másik relációból származik, amellyel az összekapcsolódik

• Csillag sémák, amelyeket tény-dimenzió modelleknek is neveznek, és amelyeket hópehely sémákra bővítettek ki.

• Előre elkészített összegzés vagy OLAP-kockák

A tárolás, a feldolgozási teljesítmény és a sávszélesség folyamatos drámai növekedésével minden szinten a denormalizáció az adatbázisokban a szokatlan vagy kiterjesztett technikából a hétköznapok, sőt a normák közé került. A denormalizáció egyik konkrét hátránya például egyszerűen az volt, hogy "több tárhelyet használ" (vagyis szó szerint több oszlopot tartalmaz egy adatbázisban). Az elképzelhető leghatalmasabb rendszerek kivételével minden más rendszerben ez a konkrét szempont lényegtelenné vált; a több tárolóhely használatának veszélye nem kérdéses.

Lásd még

• Gyorsítótár (számítástechnika)
• Normalizálás
• Méretezhetőség