DS

Z OI wiki

Přejít na: navigace, hledání

Obsah

1. semestr 2. semestr 3. semestr 4. semestr 5. semestr 6. semestr
Povinné předměty DMA ¤ LAG
PR1 ¤ RPH
ALG ¤ BP1 ¤ LGR
MA2 ¤ PR2
JAG ¤ PSI ¤ SPS APO ¤ BP2 ¤ FYZ OPT SZZ - LS 2012
Inf. a poč. vědy NUM ¤ OSS DS ¤ FLP ¤ ZUI RPZ
Počítačové syst. EAM ¤ EM DSP ¤ OSD PKS ¤PSR ¤NVS
Softwarové syst. OSS ¤ SI ASS ¤ DS ¤ TUR WA1
Volitelné předměty ACM ¤ EPD ¤ ET1 ¤ FI1 ¤ HI1 ¤ HSD ¤ HT1 ¤ IA+AZK ¤ MME ¤ MMP ¤ MPS ¤ PAP ¤ PPR ¤ PRS ¤ RET ¤ SOJ ¤ UFI
Grafický minor

PGR ¤ MVR ¤ KMA ¤ MGA ¤ GRT

Info o předmětu

  • Cvičící: Ing. Petr Křemen; Ing. Lenka Nováková, Ph.D.; Ing. Marek Šmíd


Pravidla předmětu

Pravidla předmětu na hlavní stránce předmětu


Studijní materiály

Google drive

Stránka předmětu na CourseWare

Prednaskove slidy spojene do jednoho pdf

Online cvičení z SQL Pro vyšší obtížnost nastavte min. počet bodů.

YouTube: TransactionIsolationLevels.wmv (dobré a rychlé vysvětlení)

Stupně izolovanosti ve zkratce

  1. Read uncommited - dovoluje číst uncommited data (dirty read)
  2. Read commited - zaručuje, že přečte pouze již commitlá data
  3. Repeatable read - opakované čtení vede ke stejným výsledkům (chrání ale pouze proti updatu, při insertu z jiné transakce se nový záznam objeví - phantom read)
  4. Serializable - řeší problém s phantomem


Semestrální práce

Zkoušky

Zkoušky na Google drive

Formát zkoušky

Zkouška u doc. Kouby má jen písemnou část. Dostanete písemku celkem za 65b (dříve 75b), která skoro vždy obsahuje čtyři příklady. Na písemku máte zhruba hodinu. Pak doc. Kouba začne individuálně volat studenty a písemku před nimi opravuje. Pokud máte štěstí, můžete některé chyby v písemce okomentovat a uvést na pravou míru, Kouba se vás případně na něco se vás doptá a můžete ještě známku ovlivnit. Písemka je navržena tak, aby spolu s body ze semestru dala 100b - na ně se potom aplikuje klasická bodová stupnice pro A-F.

Příklady v písemce jsou vždy typově podobné:

  1. První příklad testuje logický a konceptuální model a dotazování v SQL. Dostanete jeden model, máte nakreslit druhý. Pak většinou napíšete nad tím modelem nějaký SQL dotaz zadaný přirozeným jazykem.
  2. V druhém příkladě dostanete přirozeně zadaný nějaký příklad ze skutečného světa (banka, meals on wheels, letiště, atd.) - chce se po vás navrhnout entity, vztahy a zakreslit model.
  3. Třetí příklad testuje JPA. Dostanete logický nebo konceptuální model a máte napsat java třídu se správnými anotacemi nebo naopak.
  4. Většinou vždy zaměřen na transakce. Řeší se stupně izolace, konflikty, uspořádatelnost rozvrhu, apod. Otázka je vždy teoretická.

Někdo říkal, že jednotlivé příklady hodnotí příliš subjektivně. Já jsem takový pocit neměl, bylo to ale hodně na hraně.

Zkouška 26.5.2011

1. [30b] Namalovat konceptuální a logický model databáze zadané slovně. Pozor na to, že v logickém modelu nejsou notace, ale šípky viz přednášky. Slo o e-shop (zakaznik, objednavka, zasilka, dodaci list, reklamace), mohlo se to zdat tezky, ale nakonec to slo udelat se 6-7 entitama a asi 5 vazebnima tabulkama (vztah N:M).

2. [30b] Zadané 3 tabulky, napište SELECT. Pozor, šlo o dost "pěknej" SELECT, kde bylo potřeba použít UNION a GROUP BY pro 3 tabulky.

-nemusel se pouzit UNION, stacilo tabulky JOINout (Ondra J.)

3. [15b] Zadanej JPA model dvou entit s OneToMany vztahem. Úkolem bylo namalovat logickej model. Pozor, bylo potřeba namalovat také vazební tabulku (anotace JoinColums v JPA). Byl to presne slajd 36 v prvni prednasce o JPA.

Opravovalo se to za jízdy. Takže jste si sebrali písemku a on ji před vámi opravil. Stíhal tak 8 lidí za hodinu. Bodování moc nebylo, spíš styl "Tohle se mi nelíbí.. tohle je dost špatné. No tak vám dám.. polovinu bodů". (Za předpokladu, že máte dost bodů ze cvičení.)

Podle mého názoru tuto zkoušku není problém dát. Avšak zda budete spokojeni se známkou je jiná věc. Honza
doplneno --Ondra "Kofolák" Jelínek 26. 5. 2011, 15:31 (UTC)

Zkouška 9.6.2011

1. Opět konceptuální model, tentokrát letiště.

2. Select z tabulek:

OSOBA(*rc, id_porodnice, datum_narozeni, jmeno, prijmeni)
PORODNICE(*id_porodnice, id_mesta)
MESTO(*id_mesta, id_kraje)
KRAJ(*id_kraje)
HEJTMAN(rc, id_kraje, datum_od, datum_do)

Udělat žebříček hatemanů podle toho, kolik se za jejich funkční období (HEJTMAN.datum_od - HEJTMAN.datum_do) narodilo osob. Hateman může být zvolen vícekrát (jiné období, i jiné kraje), součet jde přes všechna období působení jednoho hatemana. Do hitparády nezahrnovat ty hatemany, kteří mají na kontě méně než 1000 děcek.

3. JPA - Zadaná obousměrná anotace ManyToMany, ale špatně. Mělo se opravit. Na obou stranách nebyly vázané entity v kolekcích:

Entita1 data1; --> Collection<Entita1> data1;

a na inversní straně bylo potřeba doplnit zdroj

@ManyToMany --> @ManyToMany(mappedBy="data1")

a potom k tomu nakreslit logický model

--Milicmar 9. 6. 2011, 15:27 (UTC)

Zkouška 15.5.2012

1. (20 b) Rekurzivní vztah. Byla zadána tabulka jako konceptuální schéma, vypadalo to cca takhle: (Není náhodou tohle logické schéma? - to je se šipkama ) -- není, šipka tam nebyla, byla tam místo ní crowe's foot

         ----------
         V        | 
------------      | Ma matku
| Osoba    |------|
------------
| rodne_c  |
| jmeno    |
| prijmeni |
------------

Úkolem bylo z toho udělat schéma logické. V podstatě se akorát k atributům doplnil cizí klíč "rodne_c_matky" a atribut "rodne_c" označit jako primární klíč. Pozor musí být nullovatelné, jinak by do tabulky nešlo vůbec vložit první záznam.

Dál se měl napsat SELECT co vybere jména a příjmení matek, které mají tři a více dětí. Dělalo se to tak, že se najoinovala ta samá tabulka, musela se aliasovat, s tím že ON bylo potom dite.rodne_c_matky=osoba.rodne_c a tohle se sgrupovalo podle rodne_c_matky a přes HAVING se z toho vybraly jen ty matky co mají dost dětí.

SELECT matka.jmeno, matka.prijmeni, COUNT(*) AS pocet_deti
FROM osoba AS matka
JOIN osoba AS dite ON (matka.rc = dite.rc_matky)
GROUP BY matka.rc, matka.jmeno, matka.prijmeni
HAVING COUNT(*)>=3


2.) (30 b) Úkolem bylo nakreslit konceptuální schéma pro informační systém sítě multikin. Evidovaly se zvlášť kina, sály, řady, sedačky, lístky, rezervace... Docela náročné z toho pohledu aby se něco nepřehlídlo, jinak principiálně pohoda. Nebylo nutné vymýšlet žádné atributy, stačilo mít dobře dekomponované věci na entity a hlavně dobře relace. M:N se nerozkládala, notaci jsem použil klasicky Crowe's Foot a byl s tím spokojený.

3.) (15 b) Příklad na JPA. Byla zadána notace v UML a měl se napsat JAVA kód s anotacema. Příklad zcela převzatý přednášek:

Soubor:zk_ds_3.png


4.) (10 b) Vysvětlit, co to znamená "dirty read" -> viz přednášky o transakcích.

Zkouška celkem pohodová, ale Koubovo bodování je dost na nic. Když se mu to líbí, tak vám body dá i když tam je chybka (jestli si jí všimne je druhá věc..), když se mu to nelíbí, strhává hodně... Měl jsem detailní chybu v tom SELECTu a nedal mi za něj ani bod, i když jsem mu řekl že jsem se spletl a že vím jak to udělat. Neukecáte ho a pokud budete vyloženě chtít ústní o body, připravte se, že se pěkně zapotíte i kdyby to bylo o bod jen jeden.

Zkouška 23.5.2012

1). (15b)Vytvořit JPA podle zadaného schematu, specifikováno něco jako bdnmena JPA

|--------------|                     |----------------|
|  knihy       |                     |    autori      |
|--------------|                     |----------------|
|  isbn        |>|-----------------|<|    jmeno       |
|  ....        |                     |     ....       |
|--------------|                     |----------------|

Důležité bylo použití @ManyToMany a na druhé straně mappedBy, u ústní části chtěl slyšet ještě o možnosti použít @JoinTable</br>

2). (25b)Vyrobit select asi z 5 tabulek, vybrat nakladatelství , pro ně dílo s největším nákladem, nakladatelství muselo být z Prahy a celkový počet vydaných výtisků musel přesáhnout 100000

tabulky byly nějak takhle
----------------------------------
|naklad  | idd,idn,pocet_vytisku |
----------------------------------
|nakladatelstvi | idn,mesto      |
----------------------------------
|dilo | idd,ida                  |
----------------------------------
|autor | ida                     |
----------------------------------
|dila_autori | idd,ida           |
----------------------------------

3). (25b)Udělat konceptuální schéma pro zhruba toto zadání.

Evidujte:
  • lidi - místo narození, datum, otce, matku
  • sňatky - ženicha, nevěstu, 2 svědky, datum, místo a instituci
  • rozvody - osoby, které se rozvádějí, datum a místo instituce
  • přejmenování - osobu, datum, místo a instituci
  • úmrtí - osoba, místo, příčina

4). (10b)Popište co znamená SET ISOLATION LEVEL READ UNCOMMITED nebo tak nějak.

Jako odpověď stačilo zmínit "dirty read" a "phantom problem"

Zkouška 12.6. 2013

1) Konceptuální model

Docela slohovka přes A4. Bylo zapotřebí správně určit entity. Byla tam i dekompozice. Uznává se i UML. Na první úlohu doporučuji mazací pero nebo tužku.

2) SQL dotaz

Prosím někoho o doplnění.

3) JPA

Přepsat kód (@EmbeddedId) do logického schématu. Úplně přesně 2. slide z 9. přednášky.

4) Transakce

a) Jaké 4 problémy při přístupu k transakci více uživatelů mohou vzniknout?
b) Jaké z těchto problémů nastanou při READ UNCOMMITED a jaké READ UNCOMMITED řeší?

Zkouška 26.5.2015

Zadání zkoušky strana 1
Zadání zkoušky strana 2

Zkouška 31.5.2016

1. (20 bodů) Vytvořit konceptuální model matriky. Obsahovalo narození,úmrtí,sňatek,rozvod,změna příjmení. U změny příjmení uvést jeden ze 3 důvodů (použít něco jako enum nebo číselník). 2. (20 bodů) Zadány tabuky person - prid,jmeno,prijmeni; project - prjid,nazev,popis; per_prj - prid,prjid,datum,odpracovane hodiny (vazební tabulka). Za úkol bylo napsat SQL dotaz, který pro každého člověka vypíše počet odpracovaných hodin pro každý projekt, na kterém se podílel. Dál to bylo omezeno datem. 3. (10 nebo 15 bodů) Vymyslet N:M vazbu a napsat k ní třídy v JPA. V podstatě úplně to samé jako v přednáškách na JPA. 4. (10 nebo 15 bodů) Zadaná historie transakce, bylo potřeba určit, jestli je serializovatelná. Dalo se z toho vyvodit, že není, protože T1 přečte A, do kterého pak T2 zapíše, takže T1 nemá aktuální informaci o A.

   T1: READ(A)
   T2: WRITE(A)
   T2: WRITE(B)
   T1: READ(B)

(Informace nemusí 100% sedět, psáno z paměti den po zkoušce.)

Events Upcoming
More »