cviceni

• UML – primárně pro OOP
• ER model – šitý na míru relačním databázím

• typy objektů
• vztahy mezi objekty
  • arita – kolika objektů se týká daný vztah
  • kardinalita – např. kolik studentů si může zapsat jeden předmět (nejvýš jeden, aspoň jeden, několik, … ?)
• atributy – co všechno potřebujeme o objektech a vztazích ukládat
  • kardinalita

počítače, OS, SW s verzemi

• „všechny povolené dvojice kin“ – ((„dvojice kin a filmy z prvního“ U „dvojice kin a filmy z druhého“) – „dvojice kin a společné filmy“)

(cinemas<name→name1>[name1<name2]cinemas<name→name2>)[name1,name2]

((program<name→name1>×cinemas<name→name2>)[name1,name2,title] ∪ (program<name→name2>×cinemas<name→name1>)[name1,name2,title])
- (program<name→name1,title→title1>[name1<name2]program<name→name2>)(title1=title)[name1,name2,title]

)[name1,name2] ```

• disky pracují s bloky, čtecí operace přečte blok
• datové struktury musejí být zarovnané na bloky
• sekvenční čtení je výrazně rychlejší než náhodné (to platí pro HDD)
• časová složitost je primárně ovlivněna množstvím bloků, které musíme přečíst
• jeden blok obsahuje nějaké řádky
• někdy je problém s tím, že řádka může mít proměnnou šířku

• pracuje nad pamětí (bufferem), na disk se zapisuje nezávisle
• aby to bylo rychlé
• záznamy lze v souboru mít uloženy na hromadě (heap) nebo v nějakém pořadí (sorted file)
• taky jsou v souborech typicky nějaké indexy

• clustered × unclustered
  • unclustered index
    • bloky nemají správné řazení → musím ukazovat na jednotlivé záznamy
    • intervalové hledání trvá déle, musí se procházet různé bloky
  • clustered index
    • stačí ukazovat jen na začátky bloků
• jak se ukládají indexy
  • $B^+$-stromy
    • ukládají data po blocích
    • jsou vyvažované
    • algoritmus vkládání a mazání je dělaný tak, aby bloky byly aspoň z poloviny zabrané
    • „plus“ znamená to, že jsou listy (obsahují data) pospojované, takže se dají efektivně dělat sekvenční dotazy
  • to se ale nehodí třeba pro binární hodnoty
    • k tomu se používají bitmapové indexy
    • vyrobí se několik bitmap – pro každou hodnotu výčtového typu bude jedna

• databáze typicky nedělá pro jednu tabulku jeden reálný soubor
• vyrobí si jeden reálný soubor, v něm má spoustu logických souborů, ty si spravuje sama

• vyrábějí se automaticky pro primary a unique sloupce
• dají se vyrábět i ručně
• pokud dělám index nad více sloupečky, tak to bude efektivně index nad zřetězením sloupečků

• parsování SQL a validace
• kontrola existence plánu v shared poolu
• pokud plán neexistuje, vygeneruje se co nejvíc plánů a spočítají se jejich ceny → vybere se nejlevnější plán
• plán se vykoná

• jsou různé metody přístupu k datům – každá trvá jinak dlouho
• nejlepší plán lze vybrat podle toho, jaké metody používá (rule based), nebo podle toho, jak dlouho by mohl trvat (cost based)
• můžeme dávat doporučení plánovači, ale bacha na premature optimization