Diff for ''

Revision 1
Time:
2024-06-13 22:22
Revision 3
Author:
black
Time:
2026-10-04 13:39
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
# Zvlastni veci ve slajdech

<{ForumPost(poster="Lukas Mach", timestamp=2007-05-29 00:00:22)}>
Ahoj,
  
mozna je to tim, ze uz je dost vecer, ale nektere veci se mi na slajdech moc nezdaji:
  
---
  
Ve slajdech je priklad na rekurzivni binarni vztah:
  
[http://labts.troja.mff.cuni.cz/~machl5bm/files/db1.gif](http://labts.troja.mff.cuni.cz/~machl5bm/files/db1.gif)
  
Jestli to dobre chapu, tak to ma prave byt priklad ilustrujici, jaka se v tom da udelat chyba: znamena to, ze kazdy clovek ma 0 az 1 podrizeneho ("vystupuje 0 az 1krat na leve strane vztahu nadrizeny/podrizeny"), zatimco kazdy clovek ma az n sefu ("vystupuje v relaci nadrizeny/podrizeny jako podrizeny 0 az n-krat"). Coz je divne.
  
---
  
Na slajdu popisujicim prevod (0/1,n) : (1,1) IMHO nema byt podtrzene v druhe tabulce RC, protoze to tam neni klic (jedna osoba muze vlastnit nekolik mobilu a tim padem v tabulce Mobil nebude RC vlastnika jednoznacne urcovat radek). Je to jen cizi klic do tabulky Osoba a ten se na predchozim slajdu znacil jen tucne. No, je to asi detail - ale mozna neco chapu blbe...
  
[http://labts.troja.mff.cuni.cz/~machl5bm/files/db3.gif](http://labts.troja.mff.cuni.cz/~machl5bm/files/db3.gif)
  
---
  
Na slajdu pred aktualizacnimi anomaliemi (2. prednaska) se uvedeny ER diagram prevadi nasledujicim zpusobem:
  
[http://labts.troja.mff.cuni.cz/~machl5bm/files/db2.gif](http://labts.troja.mff.cuni.cz/~machl5bm/files/db2.gif)
  
Pritom o nekolik slajdu nazpet je prevod (0/1,n) : (1,1) realizovany samozrejme jinak (viz slajd z minuleho bodu, je to prave on).
  
Sice se zde popisuje, jak se muze prihodit urcita chyba (v dusledku niz vznikne anomalie), ale ta chyba je v necem jinem nez v prevodu ER schematu do relacniho modelu.
  
---
  
U definice 2PL je napsane:
  
[http://labts.troja.mff.cuni.cz/~machl5bm/files/db4.gif](http://labts.troja.mff.cuni.cz/~machl5bm/files/db4.gif)
  
bod 2 by IMHO mel byt spis nejak takhle:
  
2) transakce nemuze na entite A pozadovat zadny zamek, pokud uz na nejake (klidne jine) entite zamek mela a uvolnila ho.
  
Podle definice ze slajdu by 2PL mohlo vypadat nasledovne:
  
X(A)
U(A)
X(B)
U(B)
  
a v teto posloupnosti zadne 2 faze (zamykaci, odemykaci) nejsou.
<{/ForumPost}>

<{ForumPost(poster="stnicolaus", timestamp=2007-05-29 09:40:26)}>
1) podle mne je to přesně naopak - každý zaměstnanec má 0 až 1 nadřízených a 0 až n podřízených
  
2) klíč je buď jenom sériové číslo nebo seriové číslo + RČ, ale ne samotné RČ
  
3) tady má Skopal asi chybu - žádnou chybu návrhu v tom ER diagramu nevidím
  
4) máš úplnou pravdu viz definice na [Wikipedii](http://en.wikipedia.org/wiki/2PL)
<{/ForumPost}>

<{ForumPost(poster="peva", timestamp=2007-05-29 10:01:45)}>
Takze, ako som to pochopila ja:)
pokial mas rekurzivny vztah, tak podla mna nejak zvlast nezalezi,co vstupuje kde, iba si to musi exlicitne povedat, ze co znamena co, v tomto pripade,ze cloevk na 0-1 sefa a n podriadenych (on tam mohol napisat aj nadrizeny/podrizeny nemiesto podrizeny/nadrizeny a vyznam by to nemenilo, akurat by si si musel znova uvedomit, co znamena co) (ak hovoril nieco take, ze zalezi na tom, co napises do toho kosotvorca podla toho, ake entity idu zlava alebo zprava, sorry, ale pripada mi to mierne uchylne:P)
  
ten prevod je podla mna dobre, pretoze to by malo znamenat, pretoze schema MOBIL sucasne urcuje aj ten vztah a vztah je jednoznacne urcenu klucmi entit, ktore don vstupuju - teda to znamena, SC a RC jedznocne urcuje vztah - mobil so vsetkymi svojmi atributami je vlastneny prave jednym clovekom
  
Na to dalsie to sice moc nesedi, ale bude niekde chyba, skor si myslim, ze to malo sluzit ako varovanie, ze nemame prihazovat seriove cislo k entite OSOBA(aj ked v tom pripade to tam mohol aspon pripisat,ze to tam prihadzuje!),ponevadz v tom pripade ten vztah straca zmysel a dostavame obrovsku tabulku s niekolkonasobnymi osobami a iba inymi - potazne ziadnym - mobilom
  
A to s tymi transakciami uznavam, to mne uniklo,vyzera to na chybu
<{/ForumPost}>

<{ForumPost(poster="stnicolaus", timestamp=2007-05-29 10:25:57)}>

 > peva wrote:ten prevod je podla mna dobre, pretoze to by malo znamenat, pretoze schema MOBIL sucasne urcuje aj ten vztah a vztah je jednoznacne urcenu klucmi entit, ktore don vstupuju - teda to znamena, SC a RC jedznocne urcuje vztah - mobil so vsetkymi svojmi atributami je vlastneny prave jednym clovekom

Tady bych se trochu hádal - podle mne může být klíč seriové číslo + RČ stejně jako samotné sériové číslo. Žádnou informaci tím neztratíš :D
<{/ForumPost}>

<{ForumPost(poster="peva", timestamp=2007-05-29 10:35:12)}>

 > stnicolaus wrote:
 > > peva wrote:ten prevod je podla mna dobre, pretoze to by malo znamenat, pretoze schema MOBIL sucasne urcuje aj ten vztah a vztah je jednoznacne urcenu klucmi entit, ktore don vstupuju - teda to znamena, SC a RC jedznocne urcuje vztah - mobil so vsetkymi svojmi atributami je vlastneny prave jednym clovekom
 >
 >
 > Tady bych se trochu hádal - podle mne může být klíč seriové číslo + RČ stejně jako samotné sériové číslo. Žádnou informaci tím neztratíš :D

Aha..hm..pravda:) Kazdopadne z tej jednej entity mozes spravit vztah a v tom pripade sa ti tam niekde objavi aj cudzi kluc. No a potom pri takomto vztahu (1,1)..Hm, jasne, klic = SC :P
<{/ForumPost}>

<{ForumPost(poster="stnicolaus", timestamp=2007-05-29 10:37:42)}>

 > peva wrote:Aha..hm..pravda:) Kazdopadne z tej jednej entity mozes spravit vztah a v tom pripade sa ti tam niekde objavi aj cudzi kluc. No a potom pri takomto vztahu (1,1)..Hm, jasne, klic = SC :P

Jasně, cizí klíč tam bude, ale nemusí být primární :D
<{/ForumPost}>

<{ForumPost(poster="Lukas Mach", timestamp=2007-05-29 13:37:33)}>
Diky za reakce.

 > stnicolaus wrote:1) podle mne je to přesně naopak - každý zaměstnanec má 0 až 1 nadřízených a 0 až n podřízených
   
No jo, jenze jak to? Jestli ta horni cara prislusi roli "byt sefem" a dolni cara prislusi roli "byt podrizenym", tak muze nejaky clovek delat sefa maximalne jednomu cloveku.
  
Samozrejme, vysvetleni podle Evy to resi - pokud tam Skopal nabouchal ty cary a slova nadrizeny/podrizeny v nahodnem poradi, tak je cela zahada vysvetlena. Jen bych cekal, ze vzhledem k tomu, ze cteme zleva-doprava/zezhora-dolu, tak bude horni cara prisluset tomu, co je nalevo od lomitka (= nadrizeny).

 > stnicolaus wrote:2) klíč je buď jenom sériové číslo nebo seriové číslo + RČ, ale ne samotné RČ
   
Seriove cislo + RC neni klic, je to nadklic. Nadklice nema smysl nejak zvlast zvyraznovat podtrzenim, protoze to bych taky mohl podtrhat uplne vsechno.

 > stnicolaus wrote:3) tady má Skopal asi chybu - žádnou chybu návrhu v tom ER diagramu nevidím
   
V tom ER diagramu je ta chyba, ze tam je prilis mnoho atributu u jednotlivych entit a tim vznikne redundance. Navic je tam ale podivna chyba pri prevodu ER diagramu na relace, ktera tam je uplne nanic.
<{/ForumPost}>

<{ForumPost(poster="Lukas Mach", timestamp=2007-05-29 13:42:10)}>

 > peva wrote:ten prevod je podla mna dobre, pretoze to by malo znamenat, pretoze schema MOBIL sucasne urcuje aj ten vztah a vztah je jednoznacne urcenu klucmi entit, ktore don vstupuju - teda to znamena, SC a RC jedznocne urcuje vztah
   
Ale problem je, ze ten vztah je urcen jednoznacne uz tim jen tim SC, protoze z te stranu to je (0,1) vztah.
<{/ForumPost}>

<{ForumPost(poster="stnicolaus", timestamp=2007-05-29 13:50:26)}>

 > Lukas Mach wrote:Seriove cislo + RC neni klic, je to nadklic. Nadklice nema smysl nejak zvlast zvyraznovat podtrzenim, protoze to bych taky mohl podtrhat uplne vsechno.

To záleží na tom jaké vytvoříš funkční závislosti. Takže SČ + RČ může být klidně klíč.
  
Jinak k těm zaměstnancům - Skopal to má správně - čteš zhora a zleva: Zaměstnanec má 0 až 1 nadřízených (nahoře a vlevo) + Zaměstnanec má 0 až n podřízených (dole a vpravo).
<{/ForumPost}>

<{ForumPost(poster="melda", timestamp=2007-05-29 14:02:31)}>
Na slajdech 09 - strana 21 je rozvrh:

    T1 T2 T3
    R(A) W(A)COMMIT
    W(A)
    COMMITW(A)COMMIT
    

Jaktoze je tento rozvrh usporadatelny?
Prece kdyz vykonam T2, T1, T3 tak v A muze byt neco jinyho nez kdyz vykonam T3,T1,T2, nebo ne?
<{/ForumPost}>

<{ForumPost(poster="Lukas Mach", timestamp=2007-05-29 14:43:21)}>

 > melda wrote:Jaktoze je tento rozvrh usporadatelny? Prece kdyz vykonam T2, T1, T3 tak v A muze byt neco jinyho nez kdyz vykonam T3,T1,T2, nebo ne?

Protoze T3 ti to prepise hodnotou, ktera je nezavisla na promenne A (protoze transakce T3 ani A necte). Takze je uplne jedno, co tam predtim bylo a jaky nesmysl se tam dostal, protoze bude vzapeti prepsan necim, co je pravdepodobne nejaka konstanta.
  
Podle me se da usporadatelnost nejlip zjistit tak, ze si transakcim priradim nejaky vyznam, v tomhle pripade napr:
  
T1 inkrementuje A o jednicku
T2 nastavi A na 1
T3 vynuluje A
  
(Je videt, ze tenhle prirazeny vyznam respektuje to, jak ty transakce vypadaji - napriklad T2 neobsahuje R(A) a tudiz se nemuze jednat o "zvyseni o jednicku", protoze ke zvyseni o jednicku potrebuju precist puvodni hodnotu.) Kdyz mam tenhle svuj "vyznam", tak si zkusim provest rozvrh a podivam se na vysledek. Potom zkusim se stejnym prirazenim vyznamu provest 3! seriovych rozvrhu a podivam se, jestli to nekdy vyslo stejne. Jestli jo, je rozvrh skoro jiste usporadatelny.
  
Zjistovat usporadatelnost je otrava, pracne a proto to taky v pisemkach neni.
<{/ForumPost}>

<{ForumPost(poster="melda", timestamp=2007-05-29 14:58:10)}>
Dik za odpoved, ale podle definice:
  
rozvrh Sch(T1, T2, ... Tn) je** uspořádatelný** (přesněji řečeno serializovatelný, z angl. serializable), pokud jeho vykonání vede ke konzistentnímu stavu DB, tj. k témuž stavu databáze, který obdržíme **libovolným** sériovým rozvrhem na stejných transakcích
  
Myslim tedy, ze by usporadetlny rozvrh mel mit za vysledek stav DB stejny jako jakykoli jiny seriovy rozvrh.
  
Tedy pokud T2 zvysi A o 1 a pak T3 A vynuluje, tak vysledky jsou dva mozne A=0 v A=1; A tedy nemuze existovat rozvrh, ktery by mel za vysledek A=0 **&** A=1.
  
Pokud tim **libovolnym** mysli, ale aspon jeden tak je potom pravda co rikas ty, ovsem mel by to tam napsat nejak lip a jednoznacne :/\[/b]
<{/ForumPost}>

<{ForumPost(poster="Lukas Mach", timestamp=2007-05-29 15:36:25)}>

 > melda wrote:Pokud tim **libovolnym** mysli, ale aspon jeden tak je potom pravda co rikas ty, ovsem mel by to tam napsat nejak lip a jednoznacne :/

Souhlasim, mas pravdu - melo by tam byt "nejakym" misto "libovolnym". Ani sem si toho pri cteni nevsiml...
<{/ForumPost}>

<{ForumPost(poster="Michy", timestamp=2007-06-05 20:29:22)}>
Zrovna jsem narazil na další spornou věc ve slidech - u definice WW konfliktu je, že se přepisují data, která ještě nebyla potvrzena. Ale u příkladu precedenčního grafu ve slidech (slide 09 - strana 22, stejný příklad jako ymiňovaný slide 09 - strana 21) je WW konflikt (i RW) pro T3, přestože rozhodně s nepotvrzenými daty nic nedělá (a tedy u ní žádný konflikt dle definice nemůže nastat)...
<{/ForumPost}>

<{ForumPost(poster="Ersin", timestamp=2007-06-06 13:47:10)}>
Zdar
  
Myslíte si, že Skopal čte tohle fórum? A jestli ne, myslíte si, že je dobré jej na ně upozornit, aby mohl ty slajdy poupravit (případně nám říct, že je blbě chápeme)?
<{/ForumPost}>

<{ForumPost(poster="vektor", timestamp=2007-06-06 14:56:54)}>

 > Ersin wrote:Myslíte si, že Skopal čte tohle fórum? A jestli ne, myslíte si, že je dobré jej na ně upozornit, aby mohl ty slajdy poupravit (případně nám říct, že je blbě chápeme)?

Vies, ako dobre sa to naucime, ked v tom budeme mat 3 dni ucenia totalny chaos? ;) Ty by si to buducim generaciam odoprial? ;)
<{/ForumPost}>