it-swarm-eu.dev

Kdy byste měli denormalizovat?

Myslím, že jsme všichni obeznámeni s normalizace databáze .

Moje otázka zní: Jaké jsou pokyny, které používáte, když chcete tabulky denormalizovat?

47
Richard

Denormalizovat, když je to OLAP operace, normalizovat, když OLTP (z propojeného článku v části Denormalizace)

Databáze určené pro online zpracování transakcí (OLTP) jsou obvykle normalizovanější než databáze určené pro online analytické zpracování (OLAP). OLTP aplikace se vyznačují velkým objemem malých transakcí, jako je aktualizace záznamu o prodeji v pokladně supermarketu. Očekává se, že každá transakce opustí databázi v konzistentním stavu. Naopak, databáze určené pro OLAP operace jsou primárně „většinou čitelné“ databáze. OLAP aplikace mají tendenci extrahovat historická data, která se akumulovala po dlouhou dobu. Pro takové databáze, redundantní nebo „denormalizovaná“ data mohou usnadňovat aplikace business intelligence. Konkrétně rozměrové tabulky ve schématu hvězd často obsahují denormalizovaná data. Denormalizovaná nebo redundantní data musí být pečlivě kontrolována během extrakce, transformace, načítání (ETL) a uživatelé by měli není dovoleno vidět data, dokud nejsou v konzistentním stavu. Normalizovanou alternativou ke schématu hvězd je schéma sněhové vločky. V mnoha případech se potřeba denormalizace zmenšovala, protože počítače a software RDBMS se staly e výkonnější, ale protože objemy dat se obecně zvýšily spolu s výkonem hardwaru a softwaru, OLAP databáze často stále používají denormalizovaná schémata.

Denormalizace se také používá ke zlepšení výkonu na menších počítačích, jako je tomu u počítačových pokladen a mobilních zařízení, protože tato data mohou používat data pouze pro vyhledávání (např. Vyhledávání cen). Denormalizaci lze také použít, pokud neexistuje platforma RDBMS pro platformu (jako je Palm), nebo pokud se v datech nemají provádět žádné změny a je klíčová odpověď Swift).

35
billinkc

Normalizujte, dokud to nebude bolet, denormalizujte, dokud to nebude fungovat (tj .: výkon bude přijatelný) :)

25
Andrei Rînea

Jedním z potenciálně rozumných důvodů pro použití řízené denormalizace je to, že vám umožňuje aplikovat určité omezení integrity na data, která by jinak nebyla možná. Většina SQL DBMS má extrémně omezenou podporu omezení pro více tabulek. V SQL je někdy jediným účinným způsobem, jak implementovat určitá omezení, zajistit, aby atributy obsažené v omezení byly všechny přítomny ve stejné tabulce - i když by normalizace diktovala, že patří do samostatných tabulek.

Kontrolováno denormalizace znamená, že jsou implementovány mechanismy, které zajistí, že kvůli nadbytečným datům nemohou vzniknout nekonzistence. Náklady na tyto zvláštní kontroly a riziko nekonzistentních údajů je třeba vzít v úvahu při rozhodování, zda je denormalizace vhodná.

Dalším běžným důvodem denormalizace je umožnění určité změny ve strukturách úložišť nebo umožnění nějaké jiné fyzické optimalizace, kterou by jinak DBMS nepovolovala. Podle principu Physical Data Independence by DBMS měla mít prostředky pro konfiguraci struktur vnitřního úložiště bez zbytečné změny logické reprezentace dat v databázi. Bohužel mnoho databází DBMS velmi omezuje možnosti fyzické implementace dostupné pro dané schéma databáze. Mají sklon ohrožovat nezávislost fyzické databáze pouze podporováním suboptimální implementace požadovaného logického modelu.

Mělo by to být zřejmé, ale stále je třeba říci: ve všech případech jsou to pouze změny ve fyzických implementačních funkcích, které mohou diktovat výkon - funkce, jako jsou interní datové struktury, soubory, indexování, hardware atd. Normalizace a denormalizace nemají nic společného s optimalizací výkonu nebo úložiště.

15
nvogel

Denormalizujte, pokud často přistupujete k vypočteným datům, jak je doporučeno v odpovědích na tato otázka . Náklady na ukládání a údržbu vypočtených dat budou často nižší než náklady na přepočítávání dat znovu a znovu, pokud je váš profil načítání těžký.

4
Nick Chammas

Rutinně denormalizuji, abych mohl vynutit integritu dat s omezeními. Jedním příkladem je nedávná otázka na tomto web - replikuji sloupec v jiné tabulce, takže mohu použít omezení CHECK k porovnání s jiným sloupcem. Dalším příkladem této techniky je můj blogový příspěvek .

Omezení CHECK nelze použít k porovnání sloupců v různých řádcích nebo v různých tabulkách, pokud tuto funkci nezakalíte do skalárního UDF vyvolaného z omezení CHECK. Co když vlastně potřebujete porovnat sloupce v různých řádcích nebo v různých tabulkách, aby se prosadilo obchodní pravidlo? Předpokládejme například, že znáte pracovní dobu lékaře a chcete zajistit, aby všechny schůzky odpovídaly pracovní době? K implementaci tohoto obchodního pravidla můžete samozřejmě použít spoušť nebo uloženou proceduru, ale ani spoušť ani uložená procedura vám nemohou poskytnout 100% záruku, že všechna vaše data jsou čistá - někdo může spoušť deaktivovat nebo zrušit, zadat některé špinavá data a znovu aktivujte nebo znovu vytvořte spouštěč. Také někdo může přímo upravit vaši tabulku obejít uložené procedury. V každém případě můžete skončit s údaji, která porušují vaše obchodní pravidlo, aniž byste o tom věděli.

Dovolte mi ukázat, jak implementovat toto obchodní pravidlo pomocí omezení FK a CHECK - to zaručí, že všechna data splňují obchodní pravidlo, pokud jsou všechna omezení důvěryhodná.

Ještě dalším příkladem je způsob, jak vynutit, aby časové úseky neměly mezery a žádné překrývání .

3
A-K