Normalizace databáze

[registrovany123]

Existuje normalni forma na tento typ redundance dat?

Mejme databazovy relacni model z domeny rekneme bankovnictvi. Budu mit 3 tabulky:

1. Transaction
2. Account
3. Balance

Account 1..N transaction
Account 1..N Balance

Balance UNIQUE contraint "account_id + datetime"

Balance pro dany Account je vypocitatelny na zaklade historie transakci v Transaction. Programator se vsak rozhodne, ze hodnoty bude prepocitavat do tabulky Balance z vykonostnich duvodu.

Jaky stupen Normalni formy rika, ze se to tak nesmi delat?

[Reklama]

[RDa]

Muzes to delat, pokud mas DB s plnou podporou transakci a uzamykani, tj.

Kód: [Vybrat]

BEGIN
lock T1T2B1B2
insertT1, insertT2
updateB1, updateB2
unlock T1T2B1B2
COMMIT.
Problem je tedy praktickeho duvodu - v podstate musis hnat veskere transakce (insert/update) skrze 1 vlakno, abys nemel  zapis do balance ktery je blbost:

Kód: [Vybrat]

BA = read B
BB = read B
BA += T1
BB += T2
write BA
write BB
ti skonci nespravne spocitanym balance.

[Pavel Stěhule]

Jaky stupen Normalni formy rika, ze se to tak nesmi delat?

Tohle neřeší normalizace, ale transaction isolation levels

[_Tomáš_]

1NF - atribut nesmí být dále dělitelný, součet hodnot je dělitelný na jednotlivé podsoučty
3NF - atribut musí být závislý pouze na primárním klíči, vypočítané hodnoty v balance tabulce jsou závislé na datech v transakcích, nikoliv pouze na svém primárním klíči

když už se bavíš o normálních formách, tak tabulka balance by měla mít primary key (account_id, datetime), unique je pak implicitní, aby se dodržela 2NF.

Balance u účtů můžeš uchovávat, pokud takový údaj ale pochází z venku a nikoliv ze samotných transakcí, tj. záleží jaká je vlastně vazba mezi hodnotami. V bankovních systémech se extra počítá účetní stav k nějakému dni, ten je dán aplikační logiku a nepřímo pochází z transakcí (ovlivňuje ho ale třeba i zaokrouhlování, tj. nikoliv jen transakce), ten stav je pak materializován v databázi a denní změny jsou k němu připočítávány za provozu. Tím se samotná normalizace neporušuje.

Je pak otázka jestli takové cachování v balance tabulce není předčasná optimalizace.

[Filip Jirsák]

Jaky stupen Normalni formy rika, ze se to tak nesmi delat?

Žádný – normální formy jsou jen doporučení, ne zákazy. A někdy jsou dobré důvody normální formy porušit – třeba právě kvůli výkonu.

Tohle je čistě věc optimalizace výkonu, takže se to řeší tak, že se zkoumá, zda je k tomu důvod (databáze nestíhá). Ideální je udělat to tak, že se ta data čtou z view. Pak už aplikaci nemusí zajímat, jestli je za tím view dotaz a nebo jestli je tam předpočítaná tabulka (případně rovnou materializované view). Klidně tam i teď může být dotaz, a až se v budoucnosti ukáže, že se to příliš zpomalilo, předělá se to.

[Reklama]

[registrovany123]

Tak normalni formy urcite nejsou doporuceni, jsou to matematicke definice. Ale vskutku, dival jsem se na ne az po 6NF a zadna z nich neresi muj typ duplicity dat.

Nektere odpovedi tady jsou trochu mimo btw.

[registrovany123]

Jaky stupen Normalni formy rika, ze se to tak nesmi delat?

Pak už aplikaci nemusí zajímat, jestli je za tím view dotaz a nebo jestli je tam předpočítaná tabulka (případně rovnou materializované view). Klidně tam i teď může být dotaz, a až se v budoucnosti ukáže, že se to příliš zpomalilo, předělá se to.

Ja nejak ty materializovane views nemusim, umi to delat jenom refresh vsech dat naraz, nenasel jsem na to doposud uplatneni, a tam kde jsem to videl pouzito to bylo nevhodne. Mozna tak nejake co 1 za den staci aktualizovat, ale s tim jsem se nesetkal.

[Filip Jirsák]

Ja nejak ty materializovane views nemusim, umi to delat jenom refresh vsech dat naraz, nenasel jsem na to doposud uplatneni, a tam kde jsem to videl pouzito to bylo nevhodne. Mozna tak nejake co 1 za den staci aktualizovat, ale s tim jsem se nesetkal.

Já je také nemusím. Nicméně to, kdy se materializovaný pohled obnovuje, je implementační detail – může být i takový materializovaný pohled, který se aktualizuje rovnou s aktualizací primárních dat.

Jinak použití těch obvyklých materializovaných pohledů, které se aktualizují jendou za čas, je pro různé agregace či statistiky, kde se neočekává, že máte v každém okamžiku absolutně přesné hodnoty (protože ani nedávají smysl).

[Logik]

Filip:
Takto definované "materializované views" (automaticky updatované ze zdrojových dat) není ale nic jiného, než určitý typ denormalizované tabulky.... To pak už je vlastně definice kruhem: denormalizaci dat vyřeš denormalizací dat... :-)

registrovany123:
Materialized views mají poměrně dost užití a poměrně typických, jen poněkud specifických. Vhodné je je použít např. pro (zpravidla agregovaná) data, kde nezáleží na aktuálnosti dat. Např. pro různé našeptávání, doporučování atd... Také se hodí v případě, kdy se data pořizují z nějakého externího systému dávkovým importem a tedy se nějakou dobu nemění. Takových možných usecase se určitě dá najít více. Ale není to "univerzální nástroj", to souhlas.

Jinak správná odpověď je ta od Pavla Stěhuleho. Toto je opravdu vhodné řešit pomocí správně nastavené transaction isolation, a neporušuje to pravidla normality.

[Standa Blábol]

Normalizace v tomto pripade znamena, ze balance je view nad transakcema, ktere stav uctu vypocitaji pri selectu.

Coz je vykonove neprijatelne, nutna je urcita denormalizace.

Osobne tento problem resim tak, ze aplikace dostane ucet s pravy read a execute, a vytvorim pro ni PLSQL API, ktere si pohlida vsechny potrebne kroky k zajisteni konzistence dat.

[Filip Jirsák]

Takto definované "materializované views" (automaticky updatované ze zdrojových dat) není ale nic jiného, než určitý typ denormalizované tabulky.... To pak už je vlastně definice kruhem: denormalizaci dat vyřeš denormalizací dat... :-)

Materializované views jsou z definice vždy denormalizací dat – vždy jsou to data, která můžete spočítat z jiných tabulek.