Podmínky konzistence dat v databázi

[kandri]

Ahoj, asi to tu nepatri, no nemam sa velmi koho spytat a uistit sa. Pripravujem sa na test, a vo vzorovom teste sa objavila otazka, na ktoru odpoved som si nie isty. Hadam sa najde niekto kto mi odpovie. Znenie otazky

Dve paralelne zpracovavane transakcie nemozu poskodit konzistenciu dat prave vtedy ak:
1.) su vykonavane seriovo
2.) su vykonavane na stupni izolovanosti serializable
3.) nedojde k ich vzajomnemu uviaznutiu.

Mam vybrat spravne odpovede, podla mna je spravna len 1cka, no nie som si isty. Vie mi niekto poradit? Dakujem velmi pekne a este raz sa ospravedlnujem.

[Reklama]

[Mirek Prýmek]

Dve paralelné transakcie vykonávané sériovo, to vymyslel ktorý huncút?

[Tomas2]

správně je (2) a i nejspíš (1), podrobnosti máš třeba na wiki https://en.wikipedia.org/wiki/Serializability

(1) je dost strašidelná formulace vzhledem k otázce, ona je totiž podmnožinou (2) a popisuje interní implementaci a osobně bych jí také zvolil. Jedná se právě o běžný způsob jak navrhnout paralelní aplikace - příjmout více požadavků, ale vykonat je ve frontě jeden po druhém a (2) právě popisuje stav, kdy jednotlivé transakce nejsou na sobě závislé - výsledek není závislý na pořadí vykonání jednotlivých transakcí.

[zboj]

Dve paralelné transakcie vykonávané sériovo, to vymyslel ktorý huncút?

A pak proč chodí Slováci studovat do Čech (nebo na Moravu (nebo do Slezska))

[Jenda]

Dve paralelné transakcie vykonávané sériovo, to vymyslel ktorý huncút?

Mně to přijde v pohodě. Představím si pod tím situaci, kdy do DB pošlu druhý požadavek ještě než první doběhl, a ona ho interně pozdrží.

Správně jsou podle mě odpovědi 1 i 2 .

[Reklama]

[Mirek Prýmek]

Mně to přijde v pohodě. Představím si pod tím situaci, kdy do DB pošlu druhý požadavek ještě než první doběhl, a ona ho interně pozdrží.

To pak není "paralelně zpracovávaná", ale "paralelně přijatá"

Když přijdu s kámošem na úřad a stoupnem si za sebe do fronty, tak nás taky úřednice neobsluhuje paralelně

[qwertz]

A pak proč chodí Slováci studovat do Čech (nebo na Moravu (nebo do Slezska))

A proč ne? Jaký je v tom rozdíl?

[Filip Jirsák]

Pokud se jedná o klasické ACID transakce, není správně ani jedna odpověď. To „C“ v „ACID“ znamená „consistency“,  konzistenci dat tak musí zajišťovat samotná databáze (tak, jak je konzistence definována ve struktuře databáze – pomocí cizích klíčů, unikátnosti a dalších omezení). Pokud je myšlena konzistence dat na úrovni aplikace, to nezachrání ani sériové zpracování transakcí, protože i s tím lze snadno vyrobit nekonzistentní data, pokud se to nepoužívá správně.

Jedná se právě o běžný způsob jak navrhnout paralelní aplikace - příjmout více požadavků, ale vykonat je ve frontě jeden po druhém

Běžný způsob možná pro aplikace, kde vůbec nejde o výkon, a když se náhodou sejdou dva uživatelé, tak si holt jeden počká.

kdy jednotlivé transakce nejsou na sobě závislé - výsledek není závislý na pořadí vykonání jednotlivých transakcí

Stačí, že někde máte čítač, který se s každou transakcí zvedne o jedničku –  a na pořadí transakcí hned záleží. Nebo jedna transakce jeden záznam aktualizuje a druhá ten samý maže – opět záleží na pořadí, pokud se provedou v opačném pořadí, než jsme uvedl, druhá transakce skončí chybou.

[Mirek Prýmek]

Stačí, že někde máte čítač

Žádné stačí, žádný čítač. "Serializability" je terminus technicus - viz ta výš odkazovaná stránka na Wiki.

Je to takový způsob provedení transakcí, že výsledek je ekvivalentní tomu, kdyby byly transakce spuštěné za sebou v libovolném pořadí. Čili např. jedna transakce nastaví hodnotu "surname" v řádku 123 na "Prýmek" a druhá hodnotu "name" v řádku 456 na "Mirek". Je jedno, jestli je spustím po sobě jako A,B nebo B,A, nebo je pustím paralelně. Nijak se vzájemně neovlivňují.

Čítač tam být může, ale jenom za nějakých podmínek - např. jeho aktuální hodnota se v transakci nepoužívá, čítač se jenom zvyšuje/snižuje o nějakou hodnotu.

[Kit]

kdy jednotlivé transakce nejsou na sobě závislé - výsledek není závislý na pořadí vykonání jednotlivých transakcí

Stačí, že někde máte čítač, který se s každou transakcí zvedne o jedničku –  a na pořadí transakcí hned záleží. Nebo jedna transakce jeden záznam aktualizuje a druhá ten samý maže – opět záleží na pořadí, pokud se provedou v opačném pořadí, než jsme uvedl, druhá transakce skončí chybou.

Druhá transakce neskončí chybou. Prostě se inkrementace neprovede, protože není na čem, ale chyba to není.

[kandri]

Dakujem velmi pekne vsetkym za odpovede. Na tu jednicku som prisiel prave vdaka prednaskam. 3ka som vedel, ze asi bude skor blbost, no nebol som si isty 2kou. Mimochodom aspon jedna odpoved musi byt spravna. Fakt dakujem velmi pekne, a keby sa este niekto nasiel, kto by mi pomohol s dvoma otazkami, tiez tykajucimi sa databaz, bolo by to skvele. Chcem sa len uistit, ci to je spravne.

Mame entitne typy STUDENT a PREDMET. Znamku udelenu pri skuske z daneho predmeu danemu studentovi budeme na urovni konceptualneho modelu modelovat:
A: Samostatnym entitnym typom
B: Atributom entitneho typu STUDENT
C: Atributom vztahu medzi entitnymi typami PREDMET a STUDENT
D: Atributom entitneho typu PREDMET
E: Inak

Tu to podla mna staci atribut v PREDMETe, cize D, nie?

Mame zadanu relaciu tvorenu spojenim dvoch tabuliek T1 a T2. Primarny kluc tabulky T1 je reprezentovany atributom PK, odpovedajuci cudzi kluc tabulky T2 je reprezentovany atributom FK. Definicia referencnej integrity zaisti, aby pri zmene hodnoty primarneho kluca tabulky T1 doslo aj k prislusnej zmene hodnoty cudzieho kluca tabulky T2.
A: je vlastnostou primarneho kluca, a teda je sucastou definicie tabulky T1
B: je vlastnostou cudzieho kluca, a teda je sucastou definicie tabulky T2
C: vzhladom k tomu, ze je vlastnostou paru tabuliek T1 a T2, nemoze byt sucastou definicie jednotlivych tabuliek T1 a T2

Tuto si nie som vobec isty, s databazami som doteraz na bakalarskom studiu do styku nedosiel, a tieto otazky v prijmackach nie su pre mna velmi jednoduche. Ale dal by som C.

Dakujem este raz velmi pekne vsetkym za ochotu. Ak by ste mi pomohli este s tymto, boli by ste fakt skveli

[Tomáš Roll]

Je to napsané tak, aby studentovi vytekl mozek ušima, ale samozřejmě A.

[Filip Jirsák]

Je to takový způsob provedení transakcí, že výsledek je ekvivalentní tomu, kdyby byly transakce spuštěné za sebou v libovolném pořadí. Čili např. jedna transakce nastaví hodnotu "surname" v řádku 123 na "Prýmek" a druhá hodnotu "name" v řádku 456 na "Mirek". Je jedno, jestli je spustím po sobě jako A,B nebo B,A, nebo je pustím paralelně. Nijak se vzájemně neovlivňují.

Nikoli. Výsledek je ekvivalentní tomu, jako by transakce byly spuštěné postupně, tj. nejprve začne jedna, skončí, a teprve po ní začne druhá. Ale neznamená to, že nezáleží na pořadí. Pokud budou obě transakce měnit příjmení, tak samozřejmě na pořadí transakcí záleží a zvítězí ta druhá. To, že na pořadí záleží, není vlastností izolace transakcí, ale závisí to na tom, co ty transakce provádějí. Klidně můžete spustit transakce s izolací serializable, které dělají takové změny v datech, že na pořadí záleží.

Druhá transakce neskončí chybou. Prostě se inkrementace neprovede, protože není na čem, ale chyba to není.

Chyba to samozřejmě je – když aplikace chce updatovat jeden řádek, musí si zkontrolovat, že se jeden řádek updatoval, a pokud tomu tak není, transakci odroluje. Představte si to na klasickém příkladu s bankovními účty – v jedné transakci 1. update sníží zůstatek na účtu odesílatele a 2. update zvýší zůstatek na účtu příjemce. Pokud druhý update „promáchne na prázdno“, protože účet příjemce byl mezi tím zrušen, musí se celá transakce odrolovat – jinak by došlo k ukázkové chybě, že peníze byly z účtu odesílatele strženy, ale následně zmizely v černé díře.

[Filip Jirsák]

Mimochodom aspon jedna odpoved musi byt spravna.

Možná v kontextu daného předmětu, kdy se „konzistencí dat“ myslí bůhvíco. Pokud se to zadání vezme jako obecné tvrzení o databázích, není pravdivá ani jedna odpověď, protože konzistenci dat (z hlediska interních databázových struktur i z hlediska omezení definovaných nad daty) musí zajišťovat ACID databáze sama o sobě, bez ohledu na úroveň izolace transakcí. Kdybyste zvolil izolaci transakcí třeba „repeatable read“ a při vhodné konstelaci by se vám podařilo zapsat dva řádky se stejnou hodnotou unikátního sloupce, nebo dokonce poškodit interní strukturu databázových souborů, byla by ta databáze k ničemu.

Samozřejmě databáze nemusí zajišťovat plný ACID (zejména u NoSQL databází je to oblíbené), ale to by pak muselo být součástí zadání, jaké předpoklady vlastně databáze splňuje.

Tu to podla mna staci atribut v PREDMETe, cize D, nie?

Určitě ne, vždyť je to známka studenta z předmětu. Kdybyste známku zapisoval k předmětu, bude ta známka jedna pro předmět, tedy všichni studenti by měli stejnou známku. Správně je tedy C, ale mohlo by být i A.

Mame zadanu relaciu tvorenu spojenim dvoch tabuliek T1 a T2. Primarny kluc tabulky T1 je reprezentovany atributom PK, odpovedajuci cudzi kluc tabulky T2 je reprezentovany atributom FK. Definicia referencnej integrity zaisti, aby pri zmene hodnoty primarneho kluca tabulky T1 doslo aj k prislusnej zmene hodnoty cudzieho kluca tabulky T2.
A: je vlastnostou primarneho kluca, a teda je sucastou definicie tabulky T1
B: je vlastnostou cudzieho kluca, a teda je sucastou definicie tabulky T2
C: vzhladom k tomu, ze je vlastnostou paru tabuliek T1 a T2, nemoze byt sucastou definicie jednotlivych tabuliek T1 a T2

Tuto si nie som vobec isty, s databazami som doteraz na bakalarskom studiu do styku nedosiel, a tieto otazky v prijmackach nie su pre mna velmi jednoduche. Ale dal by som C.

Je to vlastností cizího klíče – při definici cizího klíče je možné uvést klauzuli ON UPDATE nebo ON DELETE.

[dustin]

Tu to podla mna staci atribut v PREDMETe, cize D, nie?

Použij selský rozum, není to nic složitého, jen je to složitě naformulované (proč netuším, ale mezi akademiky už to tak bývá).

Známku dostal student z předmětu. Když to dáš přímo k předmětu, bude to pro všechny studenty. Takže musíš vytvořit vztah (v relačních DB tabulku) "studoval předmět" mezi studentem a předmětem  a k tomu přidáš atribut (v relačních DB sloupec) "s výsledkem" s hodnotou známky. Taky bys k tomu vztahu (tabulce) mohl mít další atributy (sloupce) např. "kolikrát nebyl na hodině", "výsledek zápočtové práce", atd.