• konceptuální modelování
  • UML – primárně pro OOP
  • ER model – šitý na míru relačním databázím
• ze zákazníka chceme dostat
  • 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
• když si potřebuju vztah pamatovat vícekrát, převedu ho na entitu/třídu
• evidence HW/SW
  • počítače, OS, SW s verzemi
• řešení úlohy s dvojicemi kin, které mají stejné filmy
  • „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]

Poznámky z poslední přednášky

• tabulky jsou uložené v souborech na disku, aby přežily vypnutí počítače
  • 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
• databáze má obvykle mezivrstvu
  • 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
• cena operací – heap file vs. sorted file
• index
  • 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
• soubory
  • 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
• indexy
  • 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ů
• životní cyklus select query
  • 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á
• plán
  • 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