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.[1][2]
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
Jegyzetek
- ↑ G. L. Sanders and S. K. Shin. Denormalization effects on performance of RDBMS Archiválva 2017. december 1-i dátummal a Wayback Machine-ben. In Proceedings of the HICSS Conference, January 2001.
- ↑ S. K. Shin and G. L. Sanders. Denormalization strategies for data retrieval from data warehouses. Decision Support Systems, 42(1):267-282, October 2006.