první

druhý

třetí

čtvrtý

pátý

šestý

první

druhý

třetí

čtvrtý

pátý

šestý

texttext

texttext

text

text

text text text text text text text text text text text

text text text text text text text text text text

text text text text text text text

(ordered list) nečíslované
(unordered list) položky seznamu
• (list item)
  
  • horizontální seznam (menu) .menu_horizontalni li { display: inline; list-style-type: none; }
  
  
  • První odrážka
  • Druhá odrážka
  • Třetí odrážka
  • Čtvrtá odrážka
  
  
  . menu_horizontalni li {display: inline} .nic {list-style-type: none;} .zvyraznovat li:hover {color: blue; text-decoration: underline;}
  • prvni
  • druhy
  • treti
  • ctvrty
  • paty
  
  
  • • •
  
  Všechny prvky formuláře musí být uvnitř elementu form. Formuláře není možné vnořovat. Prvky formuláře: • • • • • •
  
  •
  
  input – tlačítko (submit, reset, image, button), editační pole (text), soubor (file), heslo (password), rádio (radio), checkbox (checkbox) skrytý (hidden) textarea – víceřádková editace select – výběr jedné nebo více (atribut multiple) položek (option), optgroup – seskupení položek label – popis prvku, umožňuje snadnější navigaci fieldset – orámování formuláře, legend – popis orámování
  
  Více v části webové aplikace
  
  • na obrazovce se barvy míchají aditivně • nastavení barvy je možné • • •
  
  názvem – black, white, blue… složkami – rgb(255, 0, 0) číslem v 16 soustavě – #FF0000 • • •
  
  složkové zadání udává intenzitu složky rgb(255, 255, 255) nebo #FFFFFF je tedy bílá zkrácený zápis #FFF
  
  • na papíře se barvy míchají subtraktivně •
  
  barva na papíře odráží světlo
  
  • velikost: •
  
  šířka/výška – width/height
  
  • odsazení: • • •
  
  odsazení – margin rámeček – border vyplnění – padding
  
  • margin je okolo HTML prvku • padding je uvnitř HTML prvku • border je uvnitř HTML prvku
  
  • Prvek head může obsahovat následující prvky: • • • • •
  
  title – nastavení záhlaví stránky meta - nastavení informací o stránce (metadata) style – vložení stylu do stránky link – definice souvisejících souborů (nejčastěji používaný je externí styl) script – vložení skriptu nebo odkazu na skript na spuštěný na straně klienta (nejčastěji Javascript)
  
  Databáze (obecně)
  
  • data – údaje získané pozorováním, měřením • informace – interpretace dat a vztahů mezi nimi (data, která snižují míru entropie) • databáze / báze dat (DB) – obecná struktura pro uchovávání dat • systém řízení báze dat (SŘBD) – programové prostředky pro správu dat v databázi • databázový systém (DBS) – databáze a systém řízení báze dat • rozhraní – prostředky k propojení systémů
  
  • Cílem HZD je získat z dat informace. • Nejvíce aplikací pro hromadné zpracování dat tvoří informační systémy: • •
  
  podnikové IS specializované (speciální) IS
  
  • Podnikový informační systém je tvořen množstvím agend (např: sklad, účetnictví, mzdy, výroba, evidence docházky). • Specializovaný IS je úzce zaměřený na konkrétní činnost.
  
  • Často bývá spojená datová a aplikační vrstva. • Informační systém je tvořen souborem nezávislých programů – agend. • IS je tvořen souborem několika specializovaných ISů. • Formát a struktura dat jsou definované potřebami každé agendy. • problémy: • • •
  
  závislost dat a programu (agendy) nekompatibilita a izolovanost redundance a nekonzistence
  
  • izolovanost a nekompatibilita dat – datový formát definuje aplikace, jiná aplikace nemůže data využívat • redundance (nadbytečnost) – jedny údaje jsou uloženy na několika místech • nekonzistence (rozpory) – vzniká při neúplné aktualizaci redundantních dat • špatné možnosti zabezpečení dat • pro neplánované dotazy je potřeba nová aplikace • problém zajištění integrity dat
  
  • integrita (celistvost) – stav databáze, ve kterém jsou všechna data úplná a korektní • příklady: • • •
  
  věk je kladné číslo každý člověk má věk (pole věk nesmí být prázdné) každý občan ČR má trvalé bydliště
  
  • k porušení integrity může dojít: • • •
  
  špatným ošetřením vstupních dat chybnou definicí databáze (chybou aplikace) chybou databázového serveru
  
  • Důvody použití: •
  
  Historie – nerozvinuté prostředky pro databázové systémy Paralelní vývoj více aplikací a nerozvinutá systémová integrace:
  
  • • •
  
  •
  
  Různé aplikace v průběhu vývoje mohou začít požadovat stejná data Sloučení společností s různými informačními systémy
  
  Jednodušší počáteční vývoj, mělo by se ale počítat s budoucí integrací
  
  • Často jsou spojené s třívrstvou architekturou. • Data jsou uložena a spravována centrálně. • Datové soubory mají jednotnou vnitřní strukturu, skrytou vnějším aplikacím. • K datům je možno přistupovat jen prostřednictvím rozhraní databázového systému (SŘBD). • Je vyřešen současný přístup více klientů, oprávnění, integrita dat atd. • Operace v DBS jsou optimalizované, mají malou časovou složitost.
  
  • •
  
  •
  
  soubor prostředků k modelování a popisu dat výstupem je databázové schéma – deklarace databáze (šablona databáze) různé prostředky: • • • • •
  
  • •
  
  funkce množiny grafy relace objekty
  
  Databáze je něco, do čeho se dají uložit data. Databázové schéma je popis struktury databáze.
  
  • Data jsou organizována ve stromových strukturách. • Mezi záznamy je pouze vztah rodič-potomek: • •
  
  potomek má jednoho rodiče rodič může mít více potomků
  
  • Pro databáze není příliš výhodné a obecně se nepoužívá. • Speciální využití: . • • •
  
  DNS, LDAP Souborové systémy XML
  
  cz mendelu
  
  seznam
  
  com
  
  • Vznikl rozšířením hierarchického modelu. • Každá datová položka (uzel) může být propojena a libovolným počtem jiných položek. • Umožňuje vazby 1:N, N:M i cyklické vazby. • Jedná se spíš o koncept, který již není příliš funkční: • •
  
  univerzální a velice flexibilní těžko popsatelný a implementovatelný
  
  • Někdy je mezi síťové modely zařazován HTML DOM (Document Object Model)
  
  • • • • •
  
  popis dat pomocí relací (tabulek) navržen v roce 1970 (E. F. Codd, v rámci projektu IBM) je postaven na matematickém aparátu - relační algebře využívá standardizovaný dotazovací jazyk SQL velmi rozšířený: • • • • • • •
  
  Adaptive Server Enterprise (Sybase) DB2 (IBM) Firebird MySQL Oracle Database PostgreSQL SQL Server (Microsoft)
  
  •
  
  kombinace relačního a objektového modelu: • • • • • • •
  
  • • •
  
  dotazovací jazyk SQL nebo jiný relační implementace struktury modelování dat pomocí objektů zapouzdření hierarchie tříd rychlejší dobře podporuje vícehodnotové atributy
  
  místo záznamů se pracuje s instancemi objektů existují i čistě objektové databáze není zatím úplně rozšířené
  
  • Množina n-tic ve tvaru (a1, a2, a3, ..., an) • ai – hodnota atributu v dané n-tici, ai in Di • Di – doména atributu (množina hodnot, kterých může atribut nabývat) • Ai – jméno i-tého atributu (textový řetězec) • Příklad: •
  
  OSOBA(RČ: STRING, VĚK: INTEGER, JMÉNO: STRING) • •
  
  klíč atribut je podtržen domény není povinné uvádět
  
  •
  
  Na chvíli budeme předpokládat, že platí: •
  
  •
  
  schéma / relační schéma – jméno a záhlaví tabulek (definice tabulek) •
  
  • • • •
  
  relace – tabulka
  
  pojmy relace, schéma a tabulka jsou v praxi často zaměňovány, ale neznamenají totéž
  
  prvek relace – řádek tabulky atribut – sloupec tabulky doména atributu – datový typ sloupce tabulky příklad: • •
  
  OSOBA(RČ: STRING, VĚK: INTEGER, JMÉNO: STRING) OSOBA(RČ, VĚK, JMÉNO)
  
  • popis datových struktur pomocí matematické logiky • úsporný, jednoduchý a ověřený koncept • umožňuje pracovat s daty (tabulkami) před vytvořením programu • postavený na množinových operacích •
  
  součin, sjednocení, průnik, rozdíl, …
  
  • základ pro dotazovací jazyk SQL
  
  • standardní množinové operace: •
  
  kompatibilní sloupce: • • •
  
  •
  
  sjednocení (union) rozdíl (difference) průnik (intersection)
  
  kartézský součin (Cartesian product)
  
  • speciální operace • • • •
  
  projekce (projection) selekce (selection) / restrikce (restriction) Θ-spojení (Θ-join) přirozené spojení (natural join)
  
  R1  R2
  
  R1 Barva
  
  Vzhled
  
  Barva
  
  Vzhled
  
  bílá
  
  tučně
  
  bílá
  
  tučně
  
  zelená
  
  kurzívou
  
  zelená
  
  kurzívou
  
  červená
  
  podtržené
  
  červená
  
  podtržené
  
  růžová
  
  KAPITÁLKY
  
  R2 Barva
  
  Vzhled
  
  růžová zelená
  
  R1  R2 Barva
  
  Vzhled
  
  KAPITÁLKY
  
  bílá
  
  tučně
  
  kurzívou
  
  červená
  
  podtržené
  
  R1  R2 Barva
  
  Vzhled
  
  zelená
  
  kurzívou
  
  R1
  
  R1[ Barva,Vzhled ]
  
  R1[ Barva]
  
  Barva
  
  Vzhled
  
  Barva
  
  Barva
  
  Vzhled
  
  bílá
  
  tučně
  
  bílá
  
  bílá
  
  tučně
  
  zelená
  
  kurzívou
  
  zelená
  
  zelená
  
  kurzívou
  
  červená
  
  podtržené
  
  červená
  
  červená
  
  podtržené
  
  R1[( B  bílá )  ( B  červená)]
  
  R2 Barva
  
  Vzhled
  
  Barva
  
  Vzhled
  
  růžová
  
  KAPITÁLKY
  
  bílá
  
  tučně
  
  červená
  
  podtržené
  
  zelená
  
  kurzívou
  
  ( R2[ Barva  zelená ])[Vzhled ] Vzhled kurzívou
  
  R1
  
  R2
  
  Barva1
  
  Vzhled
  
  Barva2
  
  Velikost
  
  Písmo
  
  zelená
  
  tučně
  
  růžová
  
  17
  
  Arial
  
  zelená
  
  kurzívou
  
  červená 24
  
  Times
  
  červená
  
  podtržené
  
  zelená
  
  Courier
  
  20
  
  R1[ Barva1  Barva2]R2 Barva1
  
  Vzhled
  
  Barva2
  
  Velikost
  
  zelená
  
  tučně
  
  zelená
  
  20
  
  Písmo Courier
  
  zelená
  
  kurzívou
  
  zelená
  
  20
  
  Courier
  
  červená
  
  24
  
  Times
  
  červená podtržené
  
  (( R1[ Barva1  Barva2]R2)[Velikost 20])[Písmo]
  
  Písmo Times
  
  http://kantorek.webzdarma.cz/
  
  • •
  
  •
  
  Definice relace vyžaduje jednoznačnou identifikaci. Klíč je minimální množina vlastností, které jednoznačně identifikují každou entitu. Příklad – identifikace osoby: • • •
  
  •
  
  •
  
  jméno + příjmení + datum narození (složený klíč) rodné číslo (jednoduchý klíč) číslo osoby (jednoduchý klíč)
  
  Obecně je nejbezpečnější využívat umělé (dumb) atributy, i když to představuje více práce. Klíč je nejzákladnější integritní omezení – tj. každá relace musí mít klíč.
  
  •
  
  Klíčů může být v tabulce více: •
  
  • • •
  
  OSOBY(ID, RČ, JMÉNO, PŘÍJMENÍ, ČOP)
  
  Jeden z klíčů označíme jako primární. Volba primárního klíče není důležitá z hlediska analýzy, ale z hlediska implementace. primární klíč by měl být co nejmenší (z hlediska ukládání) • • •
  
  hodnoty primárního klíče by měly být snadno porovnatelné nejvhodnější volbou je jeden atribut typu integer nejvýhodnější pro stroje, lidé s databázemi nepracují
  
  • referenční integritní omezení (foreign key) • atribut jedné relace (R2), který je označen jako cizí klíč, musí mít: • •
  
  prázdnou hodnotu hodnotu primárního klíče jiné relace (R1)
  
  • R1 – hlavní relace (master, parent) • R2 – vedlejší relace (detail, dependent) • Příklad: •
  
  •
  
  VZTAHY(ID_VZTAHY, ID_OSOBY1, ID_OSOBY2, DATUM) ID_OSOBY1 a ID_OSOBY2 jsou cizí klíče
  
  http://kantorek.webzdarma.cz/
  
  Databáze – jazyk SQL (úvod)
  
  • SQL je programovací jazyk, pomocí kterého je možné komunikovat s relačním DBS. • SQL je vychází z relační algebry, ale je bohatší. • Pomocí SQL je možné: • •
  
  •
  
  „dotazovat se databáze na její stav“ – získávat data z databáze „zasílat databázi požadavky na aktualizaci“ – měnit stav databáze definovat tabulky (definovat schémata)
  
  • Data jsou uložena v databázi ve formě tabulek. • Program, který zaslal dotaz, se nemusí starat o fyzickou strukturu dat a jejich uložení. • Pořadí tabulek ani sloupců v databázi není důležité, protože jsou identifikovány jménem. • Pořadí řádků není důležité, protože jednotlivé řádky jsou identifikované hodnotou klíče. • Deklarativní jazyk: •
  
  definujeme, CO chceme udělat (procedurální jazyk definuje, jak se něco udělá – proceduru)
  
  • první prototyp v r. 1974 – jazyk Sequel • standardizace ANSI a ISO v roce 1986 a 1987 – SQL-86 • další verze SQL-89 • nový standard ANSI a ISO v roce 1992 – SQL-92 • a další SQL:1999 • a další SQL:2003 • a další SQL:2006(7?) – rozšíření o XML • SQL:2003 má 3606 stran
  
  • bez speciálních znaků → A...Z, a...z, 0...9, _ • název (sloupce, tabulky, databáze, ...) ne příliš dlouhý (30 znaků) • pokud možno anglicky • dodržovat jednotnou konvenci velikosti písmen: • • • •
  
  id_person (C) idPerson (Java, C++) IdPerson (Delphi) Id_Person (exoti)
  
  • název by měl vystihovat obsah
  
  • Název by neměl obsahovat zbytečné údaje •
  
  u tabulky není nutné uvádět, že je to tabulka
  
  • je zbytečné k názvu sloupce přidávat název tabulky/databáze • používat zavedené zkratky • •
  
  id / person_id / id_person item_count / item_cnt
  
  • id_person se v tabulce „persons“ může zdát zbytečné, ale může se využít při NATURAL JOIN • je dobré vyhnout se klíčovým slovům jazyka
  
  • • •
  
  Zapomeňte procedurální programování. Pomocí SQL se definuje co má DBS udělat, SQL server požadavek zpracuje (převede na procedurální kód) a vyhodnotí. K dílčím prvkům databáze se přistupuje přes operátor „.“ (tečka) • • • •
  
  •
  
  databáze.tabulka.sloupec (schéma.tabulka.sloupec) project.persons.id_person databáze se zpravidla neuvádí (během spuštění programu se nemění) tabulku je vhodné uvádět vždy
  
  SQL má vysokou redundanci (mnoho možností)
  
  • základní datové typy •
  
  řetězce • •
  
  •
  
  varchar(mohutnost) – standardní řetězec, omezený délkou text – „neomezený“ řetězec
  
  čísla •
  
  int(mohutnost) / number – celé číslo, např. int(4) • signed / unsigned • float
  
  •
  
  datum •
  
  datetime / date
  
  • více o datových typech později
  
  • • • •
  
  Tabulky mohou být skutečné – odpovídají databázovém schématu. Tabulky mohou být virtuální – pohledy (externí schémata). Výsledkem libovolného dotazu je také tabulka (dočasná). Pohled (view): • • • • • •
  
  •
  
  je definován dotazem je zpravidla jen pro čtení umožňuje zjednodušení dotazů vytváří „uživatelské verze“ databáze umožňuje odstínit jednotlivé programové moduly aktualizuje se automaticky ze základních tabulek
  
  Výsledek dotazu (ani pohled) obecně není relace
  
  • •
  
  funkce a klíčová slova jazyka VELKÝMI PÍSMENY kurzívou se značí rozvinutí (zástupný symbol) •
  
  • • •
  
  DELETE FROM tabulka;
  
  [ ] – nepovinný prvek { } – množina prvků | – vyloučení prvků •
  
  [ LEFT | RIGHT ] JOIN • • •
  
  •
  
  LEFT JOIN RIGHT JOIN JOIN
  
  a{=|<|>}b •
  
  a = b nebo a < b nebo a > b
  
  http://kantorek.webzdarma.cz/
  
  •
  
  pro definici struktury dat (tabulek) – DDL (data definition language): • • •
  
  •
  
  pro manipulaci s daty – DML (data manipulation language): • • • •
  
  •
  
  CREATE (SCHEMA | TABLE | INDEX ) ALTER TABLE DROP TABLE
  
  INSERT SELECT UPDATE DELETE
  
  mezi jednotlivými DBS jsou v některých oblastech značné rozdíly!
  
  Databáze – jazyk SQL
  
  • příkaz CREATE • Syntaxe je poměrně složitá a v mnoha ohledech velmi závisí na konkrétním databázovém systému. • Viz. příslušný manuál oblíbeného databázového systému.
  
  osoby
  
  id_osoby prezdivka jmeno prijmeni
  
  datum_narozeni id_aadresy
  
  kontakty
  
  id_kontakty id_osoby id_typy_kontaktu kontakt vztahy
  
  id_vztahy id_osoby1 id_osoby2 poznamka id_typy_vztahu schuzky
  
  id_schuzky datum misto poznamka osoby_schuzky
  
  id_osoby id_schuzky
  
  typy_vztahu
  
  id_typy_vztahu nazev typy_kontaktu
  
  id_typy_kontaktu nazev
  
  • příkaz INSERT • logika: INSERT kam VALUES co • INSERT INTO tabulka (seznam_sloupců) VALUES (seznam_hodnot) • INSERT [ IGNORE ] [ INTO ] tabulka •
  
  [ ( sloupec1, sloupec2, … ) ] VALUES ( { výraz1 | DEFAULT | NULL }, … ) INSERT INTO osoby (jmeno, prijmeni) VALUES (‘Chlastislav’, ‘Peruňka’);
  
  •
  
  Nemusí se vkládat všechny hodnoty •
  
  •
  
  Velmi zkrácený zápis: •
  
  •
  
  INSERT osoby VALUES ('Chlastislav', 'Sosna', 'Chlastík');
  
  Vložení data (PgSQL): •
  
  •
  
  INSERT INTO osoby (jmeno, prijmeni, prezdivka, datum_narozeni, id_adresy); VALUES ('Chlastislav', 'Peruňka', 'Chlastík', NULL, DEFAULT);
  
  INSERT INTO osoby (jmeno, prijmeni, prezdivka, datum_narozeni) VALUES ('Chlastislav', 'Sosna', 'Chlastík', TO_TIMESTAMP('5.1.1984', 'DD.MM.YYYY'), );
  
  Vložení data (MySQL): •
  
  INSERT INTO osoby( jmeno, prijmeni, prezdivka, datum_narozeni) VALUES ('Chlastislav', 'Sosna', 'Chlastík' STR_TO_DATE('5.1.1984', '%d.%m.%Y' ), );
  
  •
  
  Pravidla vkládání dat •
  
  nevkládá se hodnota automaticky generovaného klíče: auto_increment (MySQL), serial (PgSQL) •
  
  •
  
  výjimkou je hromadný import dat do více tabulek
  
  pokud to definice sloupce (vlastnost NULL) umožňuje není nutné hodnotu vkládat neuvedení sloupce má stejný efekt jako uvedení DEFAULT (vloží se výchozí hodnota z definice sloupce) uvedení hodnoty NULL nevloží žádnou hodnotu) datum se musí vkládat ve formátu DB serveru nebo se do něj musí převést
  
  • • • •
  
  formátovací funkce se liší pro různé DB servery
  
  • příkaz UPDATE • logika: UPDATE kde SET jak WHERE co • UPDATE tabulka SET seznam_modifikací WHERE vyhledávací_podmínka • UPDATE tabulka SET sloupec1 = hodnota1 [,sloupec2 = hodnota2 ...] [ WHERE vyhledávací_podmínka ] • UPDATE osoby SET vyska = '196' WHERE id_osoby=42;
  
  • Pokud není uvedená podmínka WHERE, aktualizují se všechny záznamy v tabulce •
  
  UPDATE osoby SET datum_narozeni=NULL;
  
  • V podmínce se nejčastěji používá klíč: •
  
  UPDATE osoby SET prezdivka = 'Chlastík' WHERE id=42 UPDATE osoby SET prezdivka = 'Chlastík' WHERE jmeno='Chlastislav' AND prijmeni='Peruňka' AND prezdivka='Chlastik';
  
  • •
  
  pokud je klíč složený, musí se uvádět všechny složky
  
  • • • •
  
  příkaz SELECT logika: SELECT co FROM odkud WHERE jak co – jaká data chceme, nejčastěji jaké sloupce odkud – zdroj dat, nejčastěji tabulka nebo kombinace tabulek • jak – jakým způsobem data získat, tedy jaké podmínky pro požadovaná data platí • příkaz SELECT je nejpoužívanější a také nejsložitější příkaz jazyka SQL
  
  SELECT [ ALL | DISTINCT ] výběrový_výraz1, výběrový_výraz2, … [ FROM odkazy_na_tabulky [ WHERE vyhledávací_podmínka ] [ GROUP BY { jméno_sloupce | výraz } [ ASC | DESC ], … ] [ HAVING vyhledávací_podmínka ] [ ORDER BY { jméno_sloupce | výraz } [ ASC | DESC ], … ] ]
  
  • nejjednodušší struktura: •
  
  SELECT seznam_sloupců FROM tabulka [ WHERE podmínka ]
  
  • SELECT id_osoby, jmeno, prijmeni FROM osoby WHERE vyska > 190 • Co (operace projekce): •
  
  hodnoty ve sloupcích jmeno a prijmeni
  
  • Odkud: •
  
  z tabulky osoby
  
  • Jak (operace selekce): •
  
  všechny osoby vyšší než 190 cm
  
  SELECT [ ALL | DISTINCT ] výběrový_výraz1, výběrový_výraz2, … [ FROM odkazy_na_tabulky [ WHERE vyhledávací_podmínka ] [ GROUP BY { jméno_sloupce | výraz } [ ASC | DESC ], … ] [ HAVING vyhledávací_podmínka ] [ ORDER BY { jméno_sloupce | výraz } [ ASC | DESC ], … ] ]
  
  SELECT [ ALL | DISTINCT ] { * | tabulka.* | [tabulka.]sloupec1 [AS alias1] [,tabulka.]sloupec2 * AS alias2+ *,…+ } FROM … – • * – vybere všechny sloupce, které se objeví v části FROM • tabulka.* – vybere všechny sloupce zadané tabulky • tabulka.sloupec – vybere sloupec ze zadané tabulky • AS – přiřadí dočasně sloupci jiný název (alias)
  
  •
  
  Varianty téhož dotazu: •
  
  • • •
  
  •
  
  Výběr všech míst na kterých se koná nějaká schůzka: • •
  
  •
  
  SELECT schuzky.id_schuzky, schuzky.datum, schuzky.misto, schuzky.poznamka FROM schuzky; SELECT id_schuzky, datum, misto, poznamka FROM schuzky; – SELECT schuzky.* FROM schuzky; SELECT * FROM schuzky; SELECT misto FROM schuzky; SELECT ALL misto FROM schuzky;
  
  Bez duplicitních řádků (tabulka × relace) •
  
  SELECT DISTINCT misto FROM schuzky;
  
  http://kantorek.webzdarma.cz/
  
  SELECT [ ALL | DISTINCT ] výběrový_výraz1, výběrový_výraz2, … [ FROM odkazy_na_tabulky [ WHERE vyhledávací_podmínka ] [ GROUP BY { jméno_sloupce | výraz } [ ASC | DESC ], … ] [ HAVING vyhledávací_podmínka ] [ ORDER BY { jméno_sloupce | výraz } [ ASC | DESC ], … ] ]
  
  • Výběr dat z jedné tabulky není příliš užitečný. • Data je možné získat současně z více tabulek jejich spojením. • Spojením tabulek (Θ - join) dochází k rekonstrukci původního schématu DB. • Tabulkou může být: • • • •
  
  relace (skutečná tabulka ve schématu) pohled (virtuální tabulka ve schématu) výsledek dotazu (virtuální tabulka) (rekurze) výsledek spojení tabulek (virtuální tabulka)
  
  … FROM tabulka1 [AS alias1] [ [ LEFT | RIGHT | INNER | NATURAL ] JOIN tabulka2 [AS alias1] [ ON spojovací_podmínka ] ] [ WHERE …
  
  • • • •
  
  Na levé i pravé straně operátoru JOIN je tabulka Pro spojení je nutné zadat spojovací podmínku, která platí pro všechny řádky výsledné tabulky Pro NATURAL JOIN (přirozené spojení) je spojovací podmínka automatická – rovnost hodnot ve stejně pojmenovaných sloupcích Kartézský součin (všechny kombinace): •
  
  SELECT * FROM osoby, kontakty;
  
  •
  
  SELECT * FROM osoby INNER JOIN kontakty ON osoby.id_osoby = kontakty.id_osoby; • •
  
  •
  
  Vybere z obou tabulek takové kombinace záznamů pro které platí podmínka (1:1 nebo 1:1..N). Vybere všechny osoby, které mají nějaký kontakt, každá osoba je uvedena tolikrát kolik má kontaktů.
  
  SELECT * FROM osoby NATURAL JOIN kontakty; • •
  
  Vybere všechny záznamy ve kterých se rovná hodnota stejně pojmenovaných sloupců. JOIN, INNER JOIN, NATURAL JOIN je symetrický
  
  •
  
  SELECT * FROM osoby LEFT JOIN kontakty ON osoby.id_osoby = kontakty.id_osoby; • •
  
  •
  
  Vybere z levé tabulky vše a z pravé všechny záznamy, pro které platí podmínka (1:0..1 nebo 1:0..N) Vybere všechny osoby a pokud má osoba kontakty, tak vypíše i kontakty (1:0..1 nebo 1:0..N)
  
  SELECT * FROM osoby RIGHT JOIN kontakty ON osoby.id_osoby = kontakty.id_osoby; • •
  
  Vybere z pravé tabulky vše a z levé záznamy, pro které platí podmínka. Vybere všechny kontakty a ke každému vypíše osoby (v tomto konkrétním případě je stejné jako INNER JOIN).
  
  •
  
  SELECT * FROM vztahy LEFT JOIN typy_vztahu ON vztahy.id_typy_vztahu = typy_vztahu.id_typy_vztahu; • •
  
  •
  
  Vybere všechny vztahy a ke každému přiřadí typ vztahu. Vypíše i vztahy, které nemají žádný typ (neměly by existovat).
  
  SELECT * FROM vztahy RIGHT JOIN typy_vztahu ON vztahy.id_typy_vztahu = typy_vztahu.id_typy_vztahu; • •
  
  Vybere všechny typy vztahů a ke každému přiřadí vztahy, které mají daný typ. Vypíše i typy vztahů, které nejsou použité.
  
  •
  
  Ekvivalentní dotazy: •
  
  •
  
  •
  
  SELECT * FROM kontakty LEFT JOIN typy_kontaktu ON kontakty.id_typy_kontaktu = typy_kontaktu.id_typy_kontaktu; SELECT * FROM typy_kontaktu RIGHT JOIN kontakty ON kontakty.id_typy_kontaktu = typy_kontaktu.id_typy_kontaktu;
  
  Ekvivalentní dotazy: •
  
  •
  
  SELECT * FROM kontakty INNER JOIN typy_kontaktu ON kontakty.id_typy_kontaktu = typy_kontaktu.id_typy_kontaktu; SELECT * FROM kontakty NATURAL JOIN typy_kontaktu;
  
  … FROM { tabulka1 [AS alias1] | pod_dotaz [ AS alias2] } [ [ LEFT | RIGHT | INNER | NATURAL ] JOIN tabulka2 [ ON tabulka_1.sloupec1 { > | >= | < | <= | = | <> } tabulka_2.sloupec2] ] * WHERE … • •
  
  Nejčastěji se spojení používá k rekonstrukci původního schématu. Spojovací podmínka je tedy nejčastěji rovnost hodnot dvou sloupců, které zajišťují vazbu mezi relacemi. •
  
  •
  
  Spojovací podmínka může být i exotičtější, ale potom je obvykle výhodnější použít WHERE.
  
  Spojovat je možné tabulky – tedy relace i pohledy i výsledky jiných dotazů.
  
  http://kantorek.webzdarma.cz/
  
  SELECT [ ALL | DISTINCT ] výběrový_výraz1, výběrový_výraz2, … [ FROM odkazy_na_tabulky [ WHERE vyhledávací_podmínka ] [ GROUP BY { jméno_sloupce | výraz } [ ASC | DESC ], … ] [ HAVING vyhledávací_podmínka ] [ ORDER BY { jméno_sloupce | výraz } [ ASC | DESC ], … ] ]
  
  WHERE { výraz1 [NOT] { = | <> | < | <= | > | >= } výraz2 | { ALL | ANY | SOME } pod-dotaz | výraz [NOT] IN { množina_hodnot | pod-dotaz } | výraz [NOT] LIKE vzor | výraz [NOT] BETWEEN dolní_mez AND |horní_mez | výraz [NOT] EXISTS (pod-dotaz) } [ { AND | OR } …+
  
  • SELECT jmeno,prijmeni FROM osoby WHERE jmeno LIKE ‘P%’; • SELECT jmeno,prijmeni FROM osoby WHERE (jmeno LIKE ‘P%’) OR (jmeno LIKE ‘L%’); • SELECT jmeno,prijmeni FROM osoby WHERE jmeno LIKE ‘_etr’; • SELECT jmeno,prijmeni FROM osoby WHERE jmeno IN ('Petr', 'Pavel'); • SELECT jmeno,prijmeni FROM osoby WHERE jmeno BETWEEN 'Pavel' AND 'Petr';
  
  • Osoby, které jsou vyšší než nejvyšší Petr: SELECT jmeno,prijmeni FROM osoby WHERE vyska >= ALL ( SELECT vyska FROM osoby WHERE jmeno = 'Petr' ); • Seznam osob, které bydlí v Brně: SELECT osoby.jmeno, osoby.prijmeni, adresy.mesto FROM osoby JOIN adresy ON osoby.id_adresy = adresy.id_adresy WHERE mesto = 'Brno';
  
  • Seznam osob, které bydlí v Brně, nebo neznámo kde: SELECT osoby.jmeno, osoby.prijmeni, adresy.mesto FROM osoby LEFT JOIN adresy ON osoby.id_adresy = adresy.id_adresy WHERE (mesto = 'Brno') OR (mesto is NULL);
  
  • Seznam osob, které bydlí v Brně (s využitím pod-dotazu): SELECT osoby.jmeno, osoby.prijmeni, adresy_brno.mesto FROM osoby JOIN ( SELECT mesto,id_adresy FROM adresy WHERE mesto = 'Brno' ) as adresy_brno ON osoby.id_adresy=adresy_brno.id_adresy;
  
  • Seznam všech osob a jejich adresa, pokud bydlí v Brně: SELECT osoby.jmeno, osoby.prijmeni, adresy_brno.mesto FROM osoby LEFT JOIN ( SELECT mesto,id_adresy FROM adres WHERE mesto = 'Brno' ) as adresy_brno ON osoby.id_adresy=adresy_brno.id_adresy;
  
  •
  
  Výběr všech osob, které mají e-mail (s e-maily a s využitím JOINu):
  
  SELECT osoby.jmeno,osoby.prijmeni,kontakty.kontakt FROM (osoby JOIN kontakty ON osoby.id_osoby = kontakty.id_osoby ) NATURAL JOIN typy_kontaktu WHERE typy_kontaktu.nazev LIKE '%mail';
  
  •
  
  Výběr všech osob, které mají e-mail (s e-maily a s využitím pod-dotazu): SELECT osoby.prezdivka, kontakty_emaily.kontakt FROM osoby JOIN ( SELECT kontakt,id_osoby FROM kontakty NATURAL JOIN ( SELECT id_typy_kontaktu FROM typy_kontaktu WHERE nazev LIKE '%mail') AS typ_email) AS kontakty_emaily ON osoby.id_osoby = kontakty_emaily.id_osoby;
  
  •
  
  Výběr všech osob, které mají e-mail (bez e-mailů a s využitím pod-dotazu): SELECT jmeno,prijmeni FROM osoby WHERE id_osoby IN ( SELECT id_osoby FROM kontakty WHERE id_typy_kontaktu IN ( SELECT id_typy_kontaktu FROM typy_kontaktu WHERE nazev LIKE '%mail‚ ) );
  
  • Výběr všech osob, které mají e-mail (bez e-mailů): SELECT osoby.jmeno, osoby.prijmeni FROM osoby WHERE EXISTS ( SELECT 1 FROM kontakty WHERE EXISTS ( SELECT 1 FROM typy_kontaktu WHERE nazev LIKE '%mail' AND kontakty.id_typy_kontaktu = typy_kontaktu.id_typy_kontaktu ) AND osoby.id_osoby = kontakty.id_osoby );
  
  http://www.xkcd.com/
  
  SELECT [ ALL | DISTINCT ] výběrový_výraz1, výběrový_výraz2, … [ FROM odkazy_na_tabulky [ WHERE vyhledávací_podmínka ] [ GROUP BY { jméno_sloupce | výraz } [ ASC | DESC ], … ] [ HAVING vyhledávací_podmínka + [ ORDER BY { jméno_sloupce | výraz } [ ASC | DESC ], … ] ]
  
  • • • •
  
  COUNT(*), COUNT(sloupec) – počet záznamů SUM(sloupec) – suma hodnot ve sloupci AVG(sloupec) – průměr hodnot ve sloupci MAX(sloupec), MIN(sloupec) – maximum/minimum hodnot ve sloupci • počet záznamů: • • • •
  
  COUNT(sloupec) – počet hodnot (počítá duplicity) COUNT (DISTINCT sloupec) – počet unikátních hodnot COUNT(*) – zahrnuje i duplicity a prázdné řádky COUNT(*) – nelze použít v kombinaci s DISTINCT
  
  • počet e-mailů každé osoby, která má kontakt • stačí tabulka kontakty • výchozí stav:
  
  • rozdělení do skupin podle sloupce v GROUP BY
  
  • •
  
  agregační funkce se aplikuj na každou skupinu zvlášť výsledek se zapíše do tabulky, kterou tvoří: • •
  
  •
  
  sloupce z agregace výsledek agregační funkce
  
  pro každou skupinu je ve výsledné tabulce jeden řádek •
  
  dochází ke sloučení (agregaci) řádků
  
  SELECT COUNT(*) FROM osoby; SELECT COUNT(*) FROM osoby NATURAL JOIN kontakty; SELECT COUNT(*) FROM osoby LEFT JOIN kontakty ON osoby.id_osoby = kontakty.id_osoby; SELECT COUNT(kontakt) FROM osoby LEFT JOIN kontakty ON osoby.id_osoby = kontakty.id_osoby; SELECT COUNT(DISTINCT id_osoby) FROM osoby NATURAL JOIN kontakty;
  
  • • •
  
  GROUP BY rozdělí tabulku na skupiny a pro každou skupinu zvlášť spustí agregační funkci. GROUP BY často obsahuje klíč tabulky. Počet kontaktů každé osoby která má alespoň jeden kontakt:
  
  SELECT COUNT(*), id_osoby FROM osoby JOIN kontakty ON osoby.id_osoby = kontakty.id_osoby GROUP BY osoby.id_osoby;
  
  •
  
  Počet kontaktů všech osob (pokud osoba nemá kontakt je uvedena hodnota 1): SELECT COUNT(*), id_osoby FROM osoby LEFT JOIN kontakty ON osoby.id_osoby = kontakty.id_osoby GROUP BY osoby.id_osoby; • Počet kontaktů všech osob: SELECT COUNT(kontakty.kontakt), id_osoby FROM osoby LEFT JOIN kontakty ON osoby.id_osoby = kontakty.id_osoby GROUP BY osoby.id_osoby;
  
  • COUNT(*) vrátí počet řádků skupiny
  
  •
  
  Při použití agregace musí být všechny sloupce v částí SELECT také v části GROUP BY. • Počet kontaktů každé osoby včetně jmen (musí se použít pod-dotaz): SELECT jmeno, prijmeni, pocet FROM osoby JOIN ( SELECT COUNT(kontakty.kontakt) AS pocet, osoby.id_osoby FROM osoby LEFT JOIN kontakty ON osoby.id_osoby = kontakty.id_osoby GROUP BY osoby.id_osoby ) AS osoby_pocet ON osoby.id_osoby = osoby_pocet.id_osoby;
  
  • Podmínka aplikovaná na agregaci SELECT jmeno, prijmeni, pocet FROM osoby JOIN ( SELECT COUNT(kontakty.kontakt) AS pocet, osoby.id_osoby FROM osoby LEFT JOIN kontakty ON osoby.id_osoby = kontakty.id_osoby GROUP BY osoby.id_osoby HAVING pocet > 2 ) AS osoby_pocet ON osoby.id_osoby = osoby_pocet.id_osoby;
  
  • Počet kontaktů osob, které mají vztah: SELECT osoby.jmeno, osoby.prijmeni, osoby_pocet.pocet FROM osoby JOIN ( SELECT COUNT(kontakty.kontakt) AS pocet, kontakty.id_osoby FROM osoby LEFT JOIN kontakty ON osoby.id_osoby = kontakty.id_osoby GROUP BY osoby.id_osoby HAVING (( osoby.id_osoby IN (SELECT id_osoby1 FROM vztahy) ) OR ( osoby.id_osoby IN (SELECT id_osoby2 FROM vztahy) ) ) ) AS osoby_pocet ON osoby.id_osoby=osoby_pocet.id_osoby;
  
  • Počet kontaktů osob, které mají vztah: SELECT osoby.jmeno, osoby.prijmeni, osoby_pocet.pocet FROM osoby JOIN ( SELECT COUNT(kontakty.kontakt) AS pocet, osoby.id_osoby FROM osoby JOIN kontakty ON osoby.id_osoby = kontakty.id_osoby GROUP BY osoby.id_osoby HAVING ( EXISTS (SELECT 1 FROM vztahy WHERE (id_osoby1 = osoby.id_osoby) OR (id_osoby2 = osoby.id_osoby) ) ) ) AS osoby_pocet ON osoby.id_osoby = osoby_pocet.id_osoby;
  
  SELECT [ ALL | DISTINCT ] výběrový_výraz1, výběrový_výraz2, … [ FROM odkazy_na_tabulky [ WHERE vyhledávací_podmínka ] [ GROUP BY { jméno_sloupce | výraz } [ ASC | DESC ], … ] [ HAVING vyhledávací_podmínka ] [ ORDER BY { jméno_sloupce | výraz } [ ASC | DESC ], … ] ]
  
  • Řadit je možné podle více kriterií. SELECT osoby.jmeno, osoby.prijmeni, adresy.mesto FROM osoby LEFT JOIN adresy ON osoby.id_adresy = adresy.id_adresy ORDER BY adresy.mesto DESC, osoby.prijmeni ASC, osoby.jmeno ASC;
  
  • SELECT co FROM odkud WHERE podmínky GROUP BY agregace HAVING vlastnosti ORDER BY jak • Pořadí vyhodnocování: •
  
  odkud – první zdroj dat •
  
  • • • • •
  
  JOIN – levá strana, pravá strana, podmínka
  
  podmínky – podmínky výběru agregace – seskupení výběru vlastnosti – výběr ze skupin co – omezení na sloupce jak – seřazení výsledku
  
  • Pro porovnání hodnot NULL se používá konstrukce IS NULL • Osoby, které nemají e-mail: SELECT osoby.jmeno, osoby.prijmeni, kontakty_email.kontakt FROM osoby LEFT JOIN ( SELECT kontakt,id_osoby FROM kontakty NATURAL JOIN ( SELECT id_typy_kontaktu FROM typy_kontaktu WHERE nazev LIKE '%mail') AS typ_email) AS kontakty_email ON osoby.id_osoby = kontakty_email.id_osoby WHERE kontakty_email.kontakt IS NULL;
  
  • Při výpisu hodnot NULL se může použít funkce COALESCE(): SELECT osoby.jmeno, osoby.prijmeni, COALESCE(kontakt, '[email protected]') FROM osoby LEFT JOIN ( SELECT kontakt,id_osoby FROM kontakty NATURAL JOIN ( SELECT id_typy_kontaktu FROM typy_kontaktu WHERE nazev LIKE '%mail') AS typ_email) AS kontakty_email ON osoby.id_osoby = kontakty_email.id_osoby;
  
  • Trvalé virtuální tabulky definované dotazem. • Automaticky se aktualizují. • Jména a příjmení osob, které mají e-mail: CREATE VIEW osoby_emaily AS SELECT DISTINCT osoby.id_osoby,osoby.jmeno,osoby.prijmeni FROM ( osoby NATURAL JOIN kontakty ) NATURAL JOIN typy_kontaktu WHERE typy_kontaktu.nazev LIKE '%mail';
  
  • Vztahy, kde oba účastníci mají e-mail: SELECT vztahy.*, osoby1.prezdivka, osoby2.prezdivka FROM ( vztahy JOIN osoby AS osoby1 ON vztahy.id_osoby1 = osoby1.id_osoby ) JOIN osoby AS osoby2 ON vztahy.id_osoby2 = osoby2.id_osoby WHERE osoby1.id_osoby IN (SELECT id_osoby FROM osoby_emaily) AND osoby2.id_osoby IN (SELECT id_osoby FROM osoby_emaily);
  
  • Pod-dotaz se musí použít při agregaci a výpisu více sloupců. • JOIN se musí použít při získávání dat z více tabulek (dotazů). • SQL je neprocedurální jazyk: • • •
  
  Při psaní a ladění se musí postupovat hierarchicky, nikoliv sekvenčně. Komentáře se píší k celému dotazu. Pokud SQL dotaz nic nevypíše, neznamená to, že je špatně a naopak.
  
  Vytvoření databáze
  
  • •
  
  Obecná metoda modelování datových struktur Popis dat pomocí entit a vztahů (E-R): • •
  
  • • • • •
  
  entita (entity) – jednoznačně identifikovatelný objekt reálného světa (záznam v tabulce) typ entity (entity types) – třídy reálných objektů stejného typu vztah (relationship) – vazba mezi entitami atribut (attribute) – vlastnost entity nebo vztahu hodnota (value) – konkrétní hodnota (instance) atributu doména atributu (attribute domain) – množina hodnot, kterých může atribut nabývat klíč (key) – množina atributů, jejichž hodnoty jednoznačně identifikují entitu
  
  • • • •
  
  Entity-Relationship model Relationship není relace znázorňuje se ER diagramy (ERD) klasická varianta: typy entit (třídy objektů)
  
  atributy (vlastnosti)
  
  vztahy mezi entitami
  
  •
  
  Zadání příkladu ze cvičení:
  
  Vytvořte webovou aplikaci pro evidenci přítelkyň, přítelů, adres, vztahů a schůzek. Hlavním prvkem aplikace je evidence osob a schůzek mezi nimi, tedy jakýsi adresář. U každé osoby se zaznamenává jméno, příjmení, věk, bydliště a kontaktní údaje. Každá osoba může mít libovolný počet kontaktních údajů (mobil, Jabber, Skype, …). Každá osoba může mít vztah s libovolnými jinými osobami v databázi. U každého vztahu se zaznamenává délka trvání a typ (známý, přítel, přítelkyně, manžel, …). Dále se také zaznamenávají schůzky mezi jednotlivými osobami. Schůzky se může účastnit libovolný počet osob. U schůzky se dále zaznamenává datum a místo. Využijte navržené schéma databáze a vytvořte pro tuto aplikaci databázi. Aplikace by měla umožňovat snadné přidávání a změnu osob a schůzek. Typy kontaktů jsou definované dynamicky v databázi a uživatel je může měnit. Osoba může mít více kontaktů stejného typu (např. dva emaily).
  
  • násobnost vztahu (kardinalita vztahu, cardinality ratio, relationship degree) • parcialita vztahu (úplné/částečné členství) • R (Entity1:(min, max), Entity2:(min, max)) • 1:1 – ŘÍDÍ(OSOBA:(0,1), AUTO:(0,1)) • 1:N – VLASTNÍ(OSOBA:(0,N), AUTO:(1,1)) • N:M – POUŽÍVÁ(OSOBA:(0,M), AUTO:(0,N))
  
  • E-R konceptuální model je velice blízký relačnímu datovému modelu • typ entity – tabulka • entita – záznam v tabulce • atribut – sloupec tabulky • hodnota atributu – buňka tabulky • vztah – ?
  
  • Vztahy mohou být reprezentovány: • •
  
  samostatnými tabulkami skrytě uvnitř jiných tabulek
  
  • Obecně je vztah reprezentován tabulkou pokud: • •
  
  se jedná o vztah M:N pokud má vztah atributy •
  
  •
  
  VZTAH(ID, OSOBA1, OSOBA2, DATUM_VZNIKU)
  
  má vztah nepovinné členství a není přípustná prázdná hodnota atributu
  
  • Příklad (osoba – adresa): •
  
  Pokud má osoba maximálně jednu adresu, může být uvedena v tabulce osob: •
  
  •
  
  OSOBA(ID_OS, JMÉNO, PŘÍJMENÍ, MĚSTO, ULICE)
  
  Pokud má osoba více adres je nutné zavést tabulku adres a v ní odkaz na osobu: • •
  
  •
  
  OSOBA(ID_OS, JMÉNO, PŘÍJMENÍ) ADRESA(ID_AD, MĚSTO, ULICE, ID_OS)
  
  Pokud na jedné adrese bydlí více osob je nutné zavést další tabulku přiřazení: • • •
  
  OSOBA(ID_OS, JMÉNO, PŘÍJMENÍ) ADRESA(ID_AD, MĚSTO, ULICE) BYDLIŠTĚ(ID_BY, ID_OS, ID_AD, OD_KDY)
  
  • Normalizace – převod do normální formy (NF) • Normálních forem je více, ale prakticky se používají první 3. • 1. NF – hodnoty atributů jsou atomické • 2. NF – relace neobsahuje částečné funkční závislosti neklíčových atributů na klíči • 3. NF – žádný neklíčový atribut není tranzitivně závislý na klíči • Další normální formy nejsou příliš praktické • NF jsou pouze doporučení (ale nedodržení musí být opodstatněné)
  
  • NF jsou vnořené – tj. relace je ve 3. NF pokud je v 1. i v 2. i ve 3. NF. • Pokud je DB v 3NF je zajištěno, že bude mít určité kladné vlastnosti.
  
  Jméno 1. osoby
  
  Jméno 2. osoby
  
  Adresa 1. osoby
  
  Adresa 2. osoby
  
  Chlastislav Peruňka
  
  Sosna Orbnicová
  
  Olomoucká 23, Brno
  
  Brněnská 1.1.2004 32, Olomouc
  
  Růžeslav Mekota
  
  Chlastislav Peruňka
  
  Pražská 12, Brno
  
  Olomoucká 23, Brno
  
  Květoslav Blekota
  
  Sosna Orbnicová
  
  Brněnská 56, Praha
  
  Brněnská 5.1.2007 32, Olomouc
  
  •
  
  Datum vzniku vztahu
  
  12.3.2006
  
  Tato definice relace VZTAHY není v 1. NF • • • •
  
  není jasné pořadí jméno-příjmení nelze řadit podle jména, příjmení, města, ulice nelze vypsat nebo hledat jen příjmení atomičnost se vyžaduje z hlediska aplikace
  
  Jméno 1. osoby
  
  Příjmení RČ 1. 1. osoby osoby
  
  RČ 2. osoby
  
  Chlastislav
  
  Peruňka 123456
  
  213456 Sosna
  
  Růžeslav
  
  Mekota
  
  543256
  
  123456 Chlastislav Peruňka
  
  Květoslav
  
  Blekota
  
  456456
  
  213456 Sosna
  
  •
  
  Jméno 2. osoby
  
  Příjmení 2. osoby
  
  Datum vzniku vztahu
  
  Orbnicová 1.1.2004 12.3.2006
  
  Orbnicová 5.1.2007
  
  Tato definice relace VZTAHY je v 1.NF a není v 2.NF •
  
  klíčem jsou atributy RČ1 a RČ2, protože datum vzniku vztahu závisí na jejich kombinaci jméno a příjmení 1. osoby závisí na RČ 1. osoby – tedy závisí na klíči pouze částečně redundance dat anomálie vložení, anomálie zrušení
  
  • • • •
  
  nelze vložit osobu, která nemá žádný vztah
  
  VZTAHY:
  
  •
  
  OSOBY:
  
  RČ 1. osoby
  
  RČ 2. osoby
  
  123456
  
  213456 1.1.2004
  
  123456 Chlastislav Peruňka
  
  543256
  
  123456 12.3.2006
  
  456456 Květoslav
  
  Blekota
  
  456456
  
  213456 5.1.2007
  
  543256 Růžeslav
  
  Mekota
  
  Datum vzniku
  
  RČ
  
  Jméno
  
  213456 Sosna
  
  Příjmení Orbnicová
  
  Tato definice relací VZTAHY a OSOBY je v 2. NF (a tedy i v 1. NF) • • • •
  
  žádná data nejsou redundantní vložení vztahu neznamená vložení osoby zrušení vztahu nezruší osobu rozklad schématu musí být bezztrátový tak, aby bylo možné rekonstruovat původní schéma
  
  ADRESY:
  
  •
  
  ID
  
  Město
  
  Ulice
  
  ČO
  
  PSČ
  
  1
  
  Brno
  
  Pražská
  
  3
  
  643 00
  
  3
  
  Brno
  
  Olomoucká 54
  
  656 00
  
  4
  
  Brno
  
  Brněnská
  
  653 00
  
  22
  
  Tato definice relace ADRESY není v 3. NF • • •
  
  atribut PSČ závisí na atributu Město změna hodnoty města zcela jistě vyvolá změnu PSČ každý neklíčový atribut plně závisí na klíči (definice klíče) pokud neklíčový atribut závisí na jiném neklíčovém atributu, pak závisí na klíči také tranzitivně (nepřímo)
  
  MĚSTSKÉ ČÁSTI:
  
  ADRESY:
  
  •
  
  ID
  
  Ulice
  
  ČO
  
  PSČ
  
  Město
  
  PSČ
  
  1
  
  Pražská
  
  3
  
  643 00
  
  Brno-město
  
  643 00
  
  3
  
  Olomoucká
  
  54
  
  656 00
  
  Brno-kr.pole
  
  656 00
  
  4
  
  Brněnská
  
  22
  
  653 00
  
  Brno-č.pole
  
  653 00
  
  Rozložením relace ADRESY je nová relace v 3NF: • •
  
  klíčem tabulky městských částí je PSČ hypotetické přečíslování PSČ by ale mohlo způsobit problémy
  
  • „klasický“ diagram obsahuje entity a vztahy • některé vztahy se nemusí projevit tabulkami • „crow’s foot“ diagram obsahuje spíše definice jednotlivých tabulek
  
  Databáze – speciality šéfkuchařů
  
  •
  
  Nejpoužívanější relační databázové systémy: • • • • • • • •
  
  • •
  
  Adaptive Server Enterprise (Sybase) DB2 (IBM) Firebird MySQL Oracle Database PostgreSQL SQL Server (Microsoft) SQLite
  
  Každý systém implementuje jazyk SQL jinak a žádný úplně. Mezi jednotlivými DBS bývají velké rozdíly.
  
  •
  
  Pro práci s databázovým systémem se vždy používá nějaké rozhraní: •
  
  Firemní • • •
  
  •
  
  Obecná • • •
  
  •
  
  pouze pro jeden konkrétní DB systém zpravidla více funkcí optimální výkon obvykle větší podpora standardů použitelné z různých aplikací a pro různé DBS ODBC, ADODB, JDBC, …
  
  Každé rozhraní poskytuje funkce pro připojení k databázi, vykonání dotazu, vypsání výsledku dotazu a zjištění chyb.
  
  • character_varying(mohutnost) / varchar(mohutnost) / nvarchar(mohutnost) • •
  
  standardní řetězec, omezený délkou mohutnost se udává v byte [B]
  
  • char(mohutnost) / character(mohutnost) / nchar(mohutnost) • • •
  
  řetězec omezený délkou doplňuje se mezerami operátor LIKE porovnává řetězce bez mezer
  
  • text / ntext •
  
  „neomezený“ řetězec
  
  • bigint(šířka) – 8B – -263..263 •
  
  • • • •
  
  263 = 9 223 372 036 854 775 808
  
  integer(šířka) – 4B – -231..232 mediumint(šířka) – 3B – -223..223 smallint(šířka) – 2B – -215..215 tinyint(šířka) – 1B – -27..27 • • • •
  
  celé číslo signed (se znaménkem) – záporné rozsahy unsigned (bez znaménka) – pouze kladná čísla pozor na převod mezi signed a unsigned
  
  • real / float(velikost) • • •
  
  plovoucí desetinná čárka velikost <= 24 – 7 číslic, 4 byty velikost > 24 – 15 číslic, 8 bytů
  
  • number / numeric / decimal(přesnost, měřítko) • • • •
  
  pevná desetinná čárka přesnost – maximální počet platných číslic měřítko – počet číslic za desetinnou čárkou velikost – 5..17 bytů podle nastavení
  
  • money -263..263 = 922 337 203 685 477,5808
  
  •
  
  timestamp • • • • •
  
  •
  
  •
  
  Datum a čas se ukládá jako časové razítko. Časové razítko je počet milisekund od 1.1.1970. platné pouze do 19.1.2038 03:14:07
  
  Převod na běžný formát data je velice složitý, je nutné počítat se přestupnými dny a sekundami. Timestamp není možné použít k uložení intervalu (rok, měsíc, den, …). Podle SQL standardu by měl typ timestamp obsahovat i časovou zónu.
  
  datetime / date / time • • •
  
  větší rozsah a přesnost uložení intervalu komplexní datový typ
  
  •
  
  •
  
  je možné použít také formát data aplikace – např. •
  
  pg_query("UPDATE osoby SET datum_narozeni=". time());
  
  •
  
  datový typ sloupce je integer
  
  výhody: •
  
  •
  
  jednoduché, pro jednu aplikaci bezproblémové
  
  nevýhody: •
  
  není atomické, nelze vyhledávat podle části data (lze pouze řadit) obtížně se zobrazuje interval – respektive závisí to na aplikaci
  
  • •
  
  •
  
  vracíme se k problému závislosti dat a aplikace
  
  nespolehlivé pokud k databázi přistupuje více aplikací
  
  • •
  
  bit / boolean / binary – jedna hodnota BLOB / image – binární data • •
  
  •
  
  Jednodušší případ: • •
  
  •
  
  BLOB – binary large object Detaily práce s binárními daty závisí na použitém rozhraní. Data je možno odesílat (po správném escapování) SQL dotazem a přijímat v rámci jeho výsledků. Od určité velikosti nemusí fungovat správně.
  
  Složitější případ: •
  
  Binární data (může zahrnovat i typ text) je nutné odesílat a přijímat speciálními funkcemi.
  
  • •
  
  •
  
  SQL příkaz CREATE CREATE TABLE nazev_tabulky ( sloupec datovy_typ [NOT NULL] [DEFAULT hodnota] [PRIMARY KEY] [,sloupec datovy_typ …] ) CREATE TABLE kontakty ( id serial PRIMARY KEY, osoba integer NOT NULL REFERENCES osoby, typ integer REFERENCES typy_kontaktu, kontakt varchar(200) NOT NULL )
  
  •
  
  Prakticky není možné využívat SQL pro definici databáze mezi jednotlivými DBS. • • •
  
  • •
  
  Každý DB systém používá jiné datové typy Generovaný primární klíč je implementován různě Jednotlivé DBS používají rozšíření, která významně ovlivňují práci s DB (např. MySQL – MyISAM × InnoDB)
  
  SQL pro definici struktury se používá nejčastěji pro import a export struktury v rámci jednoho DBS. Pro převod dat mezi DB systémy je nutné používat nástroje pro migraci (migration toolkit)
  
  • nejčastěji používaný typ primárního klíče • • • •
  
  abstraktní identifikátor záznamu nezávislý na vnějších podmínkách odpadají problémy se složeným klíčem kromě něj by měl existovat ještě jiný klíč (definice relace)
  
  • Žádný databázový systém neodpovídá přesně standardu. • Mezi jednotlivými databázovými systémy jsou velké rozdíly.
  
  • sloupci se přiřadí speciální atribut auto_increment • při vložení dat INSERT dotazem se klíč automaticky aktualizuje i v případě, že je hodnota zadaná (např. při importování) • SELECT LAST_INSERT_ID(); • pouze jeden sloupec v tabulce může mít atribut nastaven musí být klíčem • CREATE TABLE tabulka ( id int(5) unsigned NOT NULL auto_increment)
  
  • •
  
  • •
  
  sloupci se přiřadí speciální atribut is_identity při vložení dat INSERT dotazem se klíč automaticky aktualizuje SELECT IDENT_CURRENT('nazev_tabulky'); v případě, že je hodnota sloupce zadaná, je nutné použít příkazy: • • •
  
  •
  
  SET IDENTITY INSERT on – povolí vkládání dat SET IDENTITY INSERT off – ukončí vkládání dat vkládání dat do generovaného klíče může být povoleno pouze pro jednu tabulku
  
  CREATE TABLE tabulka ( id int(5) unsigned NOT NULL is_identity,
  
  • Sloupci se přiřadí speciální datový typ SERIAL • Automaticky se vytvoří sekvence pro generování hodnot klíče. • Při vložení dat INSERT dotazem se klíč automaticky aktualizuje. • SELECT currval('nazev_sekvence') • V případě, že je hodnota sloupce explicitně zadaná se klíč neaktualizuje! • CREATE TABLE tabulka ( id serial NOT NULL,
  
  • Pro zjištění hodnoty ID posledního vloženého záznamu se musí používat předdefinované funkce. •
  
  Nefunguje: SELECT MAX(id) FROM tabulka
  
  • Zjištění hodnoty musí být thread-safe • viz Obrázky: • • •
  
  http://akela.mendelu.cz/~xpopelka/cs/apv/ost/sek vence-currval.pdf http://akela.mendelu.cz/~xpopelka/cs/apv/ost/sek vence-max.pdf http://akela.mendelu.cz/~xpopelka/cs/apv/ost/sek vence-max-soubeh.pdf
  
  • • • •
  
  integritní omezení – NOT NULL, UNIQUE, PRIMARY KEY, CHECK cizí klíč zpravidla představuje referenční integritní omezení nelze změnit záznam v jedné tabulce bez aktualizace záznamů, které se na něj odkazují Příklad: • sloupec osoba v tabulce kontakty se odkazuje na tabulku osoby • při smazání osoby je žádoucí upravit i všechny připojené kontakty • • •
  
  CASCADE – smazat RESTRICT / NO ACTION - nepovolit smazání osoby SET NULL – nastavit hodnoty ve sloupci na NULL
  
  •
  
  CREATE TABLE kontakty ( osoba integer NOT NULL REFERENCES osoby ON DELETE CASCADE
  
  •
  
  osoby-kontakty vs. osoby- adresy
  
  Adresy id_adresy mesto
  
  ulice
  
  11
  
  Brno
  
  Polní
  
  12
  
  Praha
  
  Jarní
  
  id_osoby
  
  jmeno
  
  id_adresy
  
  1
  
  Pavel
  
  11 NULL
  
  2
  
  Karel
  
  12
  
  Při odstranění adresy se stane id_adresy=11 neplatné. ON DELETE SET NULL smaže pouze referenci, pravděpodobně není žádoucí smazat odkazující se záznam.
  
  Osoby
  
  Kontakty
  
  Při odstranění Karla z databáze se stane id_osoby=2 neplatné. ON DELETE CASCADE smaže i záznamy, které se na tuto hodnotu odkazují.
  
  id_kontakty
  
  kontakt
  
  id_osoby
  
  21
  
  [email protected]
  
  2
  
  22
  
  [email protected]
  
  2
  
  23
  
  [email protected]
  
  1
  
  • Struktura databáze je uložena ve speciální databázi INFORMATION_SCHEMA • Pro DBS, které INFORMATION_SCHEMA nepodporují je možné použít příkazů DESCRIBE, SHOW, LIST, ALTER, RENAME, DROP, MODIFY, ADD… • Příklad: • •
  
  SHOW TABLES FROM databaze; SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE' ;
  
  • Nestandardní (PgSQL, MySQL): • •
  
  SELECT ... LIMIT n; SELECT vyska FROM osoby ORDER BY vyska DESC LIMIT 10;
  
  • Standardní (SQL Server): • •
  
  SELECT [TOP | BOTTOM n] FROM ... SELECT TOP 10 vyska FROM osoby ORDER BY vyska DESC;
  
  • A další: •
  
  SELECT vyska FROM osoby ORDER BY vyska DESC WHERE ROWNUM <= 10;
  
  •
  
  volba primárního klíče souvisí se způsobem ukládání dat v DBS
  
  •
  
  ISAM (Index Sequential Access Method) •
  
  •
  
  využívá se indexových souborů (telefonní seznam)
  
  u moderních DBS už se využívají jiné metody, pro snížení časové složitosti operací
  
  index
  
  id 1 2 3
  
  pozice 1 563 1124
  
  datový soubor
  
  jméno
  
  příjmení
  
  Chlastislav Peruňka
  
  rodné číslo
  
  647423/3452
  
  Sosna
  
  Orbnicová 624783/7332
  
  Růžeslav
  
  Mekota
  
  737902/7145
  
  •
  
  Firebird: •
  
  •
  
  MySQL •
  
  •
  
  http://www.oracle.com/technology/products/database/or acle10g/index.html
  
  PostgreSQL •
  
  •
  
  http://msdn2.microsoft.com/en-us/sql/default.aspx
  
  Oracle (Express edice) •
  
  •
  
  http://dev.mysql.com/
  
  Microsoft SQL Server (Express edice) •
  
  •
  
  http://www.firebirdsql.org/
  
  http://www.postgresql.org/
  
  SQLite •
  
  http://www.sqlite.org/
  
  http://kantorek.webzdarma.cz/
  
  Úvod do počítačové grafiky
  
  • • •
  
  elmag. záření s určitou vlnovou délkou dopadající na sítnici našeho oka vnímáme jako barvu v rámci viditelné části spektra je člověk schopen rozlišit přibližně 10 milionů barev a jejich odstínů http://www.xrite.com/custom_page.aspx?PageID=77
  
  • •
  
  barva - vlastnost nějakého objektu barevný model (color model) • • •
  
  •
  
  •
  
  systém pro reprezentaci jednotlivých barev je snaha popsat barvu co nejpřesněji popisují se základní barvy a míšení těchto základních barev do výsledného odstínu přidáním informací o okolních podmínkách (dopadající světlo) získáme barevný prostor (color space)
  
  základní rozdělení • •
  
  aditivní subtraktivní
  
  • •
  
  pracuje se světelnými zdroji barev (např. monitor nebo projektor) 70 léta 19. století
  
  • model RGB (Red, Green, Blue) • •
  
  • • •
  
  barvy jsou vytvářeny přidáváním barvy do černé (míchání vyzařovaného světla) přidáním všech složek vznikne bílá (svítíme barevnými reflektory) odpovídá fyziologii vnímání barev lidským okem aditivní barevné prostředí proto nepotřebuje vnější světlo (barvy na monitoru jsou zobrazovány i v naprosté tmě) barevné prostory CIE-XXX, HSV, HSL
  
  • každá barva je udána intenzitou tří základních komponent • 256 (1 byte) úrovní pro každou základní barvu • 2563 = 16 777 216 barev ve 3 bytech • nebo 65536 barev ve dvou bytech • RGBA – barevný pseudo prostor • • •
  
  rozšíření o alfa kanál (A) alfa kanál – informace o průhlednosti pixelu (alpha blending) obvykle je 256 úrovní průhlednosti (1 byte)
  
  •
  
  pracuje s odrazem bílého světla (tiskárny a všechno hmotné)
  
  •
  
  model CMY (Cyan – tyrkysová, Magenta – purpurová, Yellow – žlutá) •
  
  subtraktivní prostředí je prostředí, které odráží světlo, a proto potřebuje vnější zdroj světla CMY a RGB jsou komplementární
  
  • • •
  
  • • •
  
  tyrkysová pohlcuje červenou a odráží zelenou a modrou (ink) zelené + modré světlo = tyrkysové světlo (color)
  
  odpovídá 3 základním barvám (tonerům) používaným při tisku základní barvy jsou odečítány od bílé (čím více „odebereme“, tím více se blížíme černé) „odebírání“ – omezujeme odraz světla, smícháním základních barev vznikne černá
  
  • CMYK – rozšíření o černou (blacK, Key – klíčová) •
  
  teoreticky postačují k vytvoření černé pouze tři barvy modelu CMY ve skutečnosti ale vzniká barva tmavě šedivá
  
  • •
  
  •
  
  technické barvy (ink) obsahují pigment (mikroskopické částečky, které nelze dokonale promíchat)
  
  navíc je černá levnější, proto většina tiskových zařízení používá ještě čtvrtou černou barvu barevné prostory různé – závisí na technologii výroby barvy, tisku a podobně
  
  • •
  
  univerzální např. Pantone
  
  • monitor, projektor vyzařuje světlo, oko pohlcuje světlo • reálné objekty odráží světlo
  
  • kompletní sada barev něčeho (zařízení, obrázku, atd.) • gamut je jedno z kritérií zobrazovacích schopností zařízení • • •
  
  je dáno fyzikálním omezením zařízení každé zařízení má jiné schopnosti každé oko má jiné schopnosti
  
  • • • •
  
  obraz má danou velikost mřížky každý bod mřížky má určenou barvu bod mřížky – pixel (picture element) příklady: JPG, GIF, PNG, BMP, TIFF
  
  • • • • •
  
  geometrický popis obrazu elementární prvky: bod, úsečka, křivka, písmeno dají se vytvářet plochy, definovat barvy CAD aplikace příklady: CDR, AI, EPS, PDF (někdy)
  
  • Vektorový formát • • •
  
  matematický popis neomezená přesnost (libovolné měřítko) pro tisk a zobrazení se musí konvertovat do bitmapy
  
  • Rastrový formát • • • •
  
  ne všechno je možné geometricky popsat velké množství dat (viz BMP) změna velikosti je dost složitá operace s nejistým výsledkem pozor na ztrátovou kompresi!
  
  • •
  
  •
  
  počet bitů potřebných k uložení barvy pixelu větší barevná hloubka zvětšuje škálu použitelných barev a také paměťovou náročnost obrázku obrazy podle počtu použitých barev: • • •
  
  monochromatické: 1 pixel = 1 bit (bílá nebo černá) stupně šedi: 1 pixel = 8 bitů (intenzita jedné barvy) s paletou (indexovaná barva): 1 pixel = 2, 4, 8, 16 bitů • • • •
  
  • •
  
  tabulka barev uložená v souboru s obrazem barva pixelu je zadána jako index do tabulky barev malá paměťová náročnost a možnost změny barev používá se do 256 barev
  
  pravé barvy: 1 pixel = 24 bitů (16 mil. barev) pravé barvy s částečnou průhledností: 1 pixel = 32 bitů
  
  • •
  
  • •
  
  • •
  
  počet obrazových bodů na jednotku délky obrazu obvykle se měří v počtu obrazových bodů na palec (dots per inch, dpi) 1 palec = 2,54 cm příklad: obraz o rozměrech 1×1 palec s rozlišením 100 dpi obsahuje celkem 10 000 obrazových bodů, stejný obraz s rozlišením 300 dpi obsahuje celkem 90 000 obrazových bodů velikost obrazu na obrazovce je určena rozměry v obrazových bodech, velikostí a nastavením monitoru velikost obrazu (souboru) na disku je určena celkovým počtem obrazových bodů a jejich barevnou hloubkou
  
  • obyčejně rastrová • vektorová grafika není nijak zvlášť podporovaná • •
  
  obtížná implementace, chybějící standardy SVG (Scalable Vector Graphics) • •
  
  •
  
  Popis obrázku pomocí XML souboru: <path fill="#0000FF" d="M330.248, 144.0928c33.5879, 19.5713, 58.0996, 53.8916, 63.6465, 95.4014 c9.5371, 71.3516-40.5762, 136.9219-111.9277, 146.459c29.8262, 3.9863-58.6504-2.4551-82.7891-16.5098" /> Není podporováno Internet Explorerem (plug-in)
  
  • Pozor na přenášená data •
  
  velikost – obrázky je nutno optimalizovat • •
  
  •
  
  obrázky designu 0..10 kB obrázky s daty < 500 kB
  
  počet požadavků •
  
  nepoužívat obrázky na prvky, které je možné vytvořit pomocí CSS (rámečky, linky) • recyklovat – pro celou aplikaci stačí jedna ikona „smazat“ • slučovat • span.mce_bold {background-position: 0 0} • span.mce_italic {background-position: -60px 0}
  
  • barvy používat střízlivě • nepoužívat modrou barvu u malých objektů nebo tenkých čar (lid. oko není příliš citlivé na odstíny modré) • na pozadí nepoužívat červenou a zelenou barvu (časté přeostřování – únava oka) • nekreslit vedle sebe syté barvy vzdálené ve spektru (náročné přeostřování oka) • odstíny šedé neruší • super bílá je trošku namodralá bílá
  
  • • • • • • • • •
  
  http://standanovak.borec.cz/ http://henryklahola.nazory.cz/ http://standa.chytrak.cz/ http://4a.chytrak.cz/ http://flussor.chytrak.cz/ http://cimrman.chytrak.cz/ http://www.vesmirni-lide.cz/default_c.htm http://simona.kvalitne.cz/index2.php a další …
  
  Webové aplikace
  
  • Rozdíly oproti webové stránce: • • • •
  
  interaktivní řádově vyšší počet požadavků práce s datovým skladem problémy se souběhem více uživatelů
  
  • Webová aplikace se skládá z webových stránek • Webová aplikace je serverová aplikace • •
  
  zahltit server není problém zahltit server znamená odříznutí všech uživatelů
  
  • Rozdíly oproti lokální (nesíťové) aplikaci • • • • • •
  
  vzdálený přístup problémy se souběhem více uživatelů potíže s uchováváním stavu závislost na webových prohlížečích vysoká dostupnost levnější údržba aplikace
  
  •
  
  Nastavení dat v HTTP hlavičkách: •
  
  •
  
  •
  
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8;language=cs"> nastavení ukládání do cache (mezipaměti)
  
  Nastavení informací pro vyhledávače a prohlížeče: • • • • • •
  
  klíčová slova (keywords) autor (author) popis (description) <meta name=‘kewords’ content="html, sql, php"> Při nastavování těchto metadat je nutné brát v úvahu, že vyhledávače se brání ovlivňování výsledků. pro webové aplikace není příliš významné
  
  http://mendelu.cz/ http://mendelu.cz/cz http://mendelu.cz/css/rs_base.css http://mendelu.cz/css/jquery/jquery.fancybox-1.2.5.css http://mendelu.cz/img.pl?rscss=86 http://mendelu.cz/js/jquery/jquery.js http://mendelu.cz/css/rs/galerie_pas.css http://mendelu.cz/js/jquery/jquery.fancybox-1.2.5.js http://mendelu.cz/js/rs/galerie_pas.js http://mendelu.cz/img.pl?rsunid=52494 http://mendelu.cz/img.pl?rsunid=52239 http://mendelu.cz/img.pl?rsunid=52257 http://mendelu.cz/img.pl?rsunid=52251 http://mendelu.cz/img.pl?rsunid=52246 http://mendelu.cz/img.pl?rsunid=52241 http://mendelu.cz/img.pl?rsunid=52309 http://mendelu.cz/img.pl?rsunid=52299 http://mendelu.cz/img.pl?rsunid=53312 http://mendelu.cz/img.pl?rsunid=52247 http://mendelu.cz/rs/obrazek.pl?id=4181;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=3463 http://mendelu.cz/img.pl?rsunid=52262 http://mendelu.cz/rs/obrazek.pl?id=4192;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4198;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4200;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4201;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4202;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4203;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4204;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4182;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4184;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4183;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4185;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4186;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4187;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4189;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4190;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4191;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4193;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4194;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4195;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4196;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4197;nahled=1; http://mendelu.cz/rs/obrazek.pl?id=4199;nahled=1; http://www.google-analytics.com/ga.js http://mendelu.cz/rs/obrazek.pl?id=4188;nahled=1; http://www.google-analytics.com/__utm.gif?utmwv=4.6.5&utmn=1111052810&utmhn=mendelu.cz&utmcs=iso-8859-2&utmsr=1920x1200&utmsc=32bit&utmul=cs&utmje=1&utmfl=10.0%20r45&utmcn=1&utmdt=MENDELU&utmhid=1707450468&utmr=-&utmp=%2Fcz&utmac=UA-77341921&utmcc=__utma%3D109547801.1087977834.1270485352.1270485352.1270485352.1%3B%2B__utmz%3D109547801.1270485352.1.1.utmcsr%3D(direct)%7Cutmccn%3D(direct)%7Cutmcmd%3D(none)%3B http://mendelu.cz/favicon.ico http://mendelu.cz/img.pl?sysid=fancy_shadow_n http://mendelu.cz/img.pl?sysid=fancy_shadow_ne http://mendelu.cz/img.pl?sysid=fancy_shadow_e http://mendelu.cz/img.pl?sysid=fancy_shadow_se http://mendelu.cz/img.pl?sysid=fancy_shadow_sw http://mendelu.cz/img.pl?sysid=fancy_shadow_s http://mendelu.cz/img.pl?sysid=fancy_shadow_w http://mendelu.cz/img.pl?sysid=fancy_shadow_nw
  
  56 HTTP požadavků
  
  • rychlost závisí na neovlivnitelných okolnostech • fyzikální omezení přenosu
  
  mendelu.cz
  
  embarcadero.com
  
  POST https://login.szn.cz/loginProcess HTTP/1.1 Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/xshockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322) Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate Host: login.szn.cz Content-Length: 131 Connection: Keep-Alive Cache-Control: no-cache Accept-Language: cs loggedURL=http%3A%2F%2Femail.seznam.cz%2Fticket&serviceId=email&forceSS L=0&username=mrkvicka&domain=seznam.cz&password=cibulka&js=1
  
  • •
  
  Cache = mezipaměť Při prvním požadavku na webovou stránku je nutné načíst všechny externí soubory. •
  
  •
  
  •
  
  Při dalším požadavku na stránku není nutné stahovat soubory znovu – pravděpodobně se nezměnily. Cache je dočasná paměť pro uložení webových stránek. • •
  
  •
  
  obrázky, styly, skripty (klientské)
  
  dramatické zvýšení rychlosti načítání pevný disk nebo RAM
  
  Existuje také sdílená cache – velké organizace, někteří poskytovatelé internetu
  
  • •
  
  Systém pro definovaní doby uchovávání stránky (lifetime, time-to-live, ttl) v cache prohlížeče. První načtení stránky: •
  
  •
  
  Druhý požadavek na stránku: •
  
  •
  
  9 požadavků (2175 B)
  
  Obnovení stránky: •
  
  •
  
  55 požadavků (435 954 B z toho 18872 B stránka)
  
  54 požadavků
  
  http://www.w3.org/Protocols/rfc2616/rfc2616sec14.html
  
  • Hlavička Cache-control • • •
  
  Cache-control: public, max-age=259200 Cache-control: private, max-age=3600, mustrevalidate Cache-control: private, no-cache, no-store, mustrevalidate
  
  • Koncept 1 • •
  
  soukromý vs. veřejný obsah (public × private × nocache × no-store) rozhoduje zda uložit nebo neuložit
  
  • Koncept 2 – vypršení (expiration) •
  
  doba platnosti [s]: •
  
  •
  
  max-age=3600
  
  povinné ověření: •
  
  must-revalidate
  
  • Koncept 3 – ověření platnosti •
  
  Pokud klient požaduje zaručeně čerstvou stránku může odeslat hlavičku (CTRL + F5): •
  
  •
  
  Pragma: no-cache
  
  Server musí buď odpovědět platnou stránkou nebo klienta přesvědčit, že jeho verze je platná (HTTP status 304).
  
  •
  
  Podle data poslední změny •
  
  Server může odeslat hlavičku udávající poslední změnu souboru: •
  
  •
  
  Klient může ověřit zda došlo ke změně posláním hlavičky: •
  
  •
  
  Last-Modified: Wed, 13 Oct 2004 09:43:02 GMT If-Modified-Since: Wed, 13 Oct 2004 09:43:02 GMT
  
  Podle obsahu •
  
  Server může odeslat kód, který se změní při změně obsahu: •
  
  •
  
  ETag: "3fe48-527f-52237c0"
  
  Klient může ověřit zda došlo ke změně posláním hlavičky: •
  
  If-None-Match: "38cac-1f34-7333bcc0"
  
  •
  
  Minimalizace objemu přenášených dat mezi serverem a klientem • •
  
  Ověření platnosti = přenos přibližně 500B Pro statický obsah je zajištěno automaticky (posílá se Lastmodified) Pro dynamický obsah nutno řešit při generování stránky (ETag)
  
  • •
  
  •
  
  U dynamicky generovaných stránek je vhodné zajistit, aby se generovaly jen pokud je to nutné. •
  
  •
  
  zejména pro skripty, které vracejí obrázky a velké soubory
  
  snížení zátěže serveru
  
  http://www.fiddlertool.com/
  
  http://www.xkcd.com/
  
  • přihlášení, stav formuláře, aktuální stránka… • protokol HTTP je nestavový •
  
  Z pohledu serveru není mezi jednotlivými požadavky klientů žádná spojitost. Jedna akce uživatele odpovídá mnoha HTTP požadavkům. Požadavky jednotlivých klientů se na serveru prolínají. Udržování stavu webové aplikace je možné několika způsoby.
  
  • •
  
  • •
  
  všechny jsou špatné • a některé ještě horší…
  
  Map of the internet (2006) http://xkcd.com/195/
  
  o většina PC nemá statickou IP adresu o většinu PC používá více jak jeden uživatel o na většině PC je spuštěn více jak jeden program
  
  • •
  
  • • • •
  
  GET je základní HTTP požadavek Udržování stavu metodou GET znamená vkládání parametrů do URL. Není nijak zabezpečeno, adresu je možné podstrčit Pouze malý objem textových dat (2 048B), bez speciálních znaků (funkce urlencode() ) K předávání dochází pouze při kliknutí na odkaz nebo odeslání formuláře. Uživatel může libovolně měnit •
  
  http://www.google.cz/search?q=test&hl=cs&start=10&sa= N
  
  • • • • • •
  
  •
  
  POST je jiný způsob odeslání HTTP požadavku, při kterém klient odesílá (post) serveru data. POST požadavek vzniká pouze při odeslání formuláře (method='post') nebo JavaScriptem. Není nijak zabezpečeno. Data jsou ve zdrojovém kódu HTML stránky. Pouze textová data bez speciálních znaků (urlencode()) Je mírně odolnější proti podstrčení a proti změně ze strany uživatele. Není univerzální, musí se explicitně zopakovat při každém požadavku.
  
  •
  
  Data pro udržení stavu se ukládají v prohlížeči •
  
  nespolehlivé •
  
  •
  
  nebezpečné • •
  
  •
  
  není šifrováno přístupné komukoliv
  
  Nastavuje se vypršení cookie souboru • •
  
  •
  
  uživatel může libovolně mazat a měnit
  
  po zavření prohlížeče (dočasný cookie v RAM) doba platnosti (tj. platné i po zavření prohlížeče, trvalý cookie na HDD)
  
  Do cookie se dají ukládat jen textová data (max. 4096B na doménu), přenáší se při každém požadavku automaticky.
  
  •
  
  Internet Explorer •
  
  •
  
  Firefox •
  
  •
  
  %USERPROFILE%\Cookies %USERPROFILE%\Data aplikací\Mozilla\Firefox\Profiles\hash.default\cookies.txt
  
  Opera •
  
  %USERPROFILE%\Data aplikací\Opera\Opera\Profile\cookies4.dat
  
  • Internet Explorer (www.google.cz): PREF ID=e0e8437d79da2a4e:LD=en:NR=30:TM=1196797760:LM=1196797793:S=I1OK7fza FXPVH5SQ google.cz/ 1536 3355346560 30045265 3381481456 29898414 *
  
  • Data pro uchování stavu se ukládají na serveru. • Vzniká problém identifikace klienta • Automatická správa session: •
  
  • • • •
  
  při prvním požadavku server generuje identifikační kód session vytvoří prostor pro data identifikační kód zašle klientovi klient uloží kód do dočasného cookie souboru s každým požadavkem zašle klient serveru kód session
  
  vytvoření SESSION ID a uložení dat 1. požadavek odpověď + SESSION ID Session ID: xyz
  
  Data
  
  Session ID: abc
  
  Data
  
  načtení dat podle SESSION ID
  
  2. požadavek + SESSION ID (abc)
  
  odpověď + SESSION ID Session ID: xyz
  
  Data
  
  Session ID: abc
  
  Data
  
  • •
  
  • •
  
  Umožňuje ukládání větších objemů dat i netextových dat. Data jsou uložena na serveru a přístupná pouze webovému serveru. Přenáší se pouze identifikační kód (SESSION ID). Slabým místem je identifikační kód • •
  
  •
  
  identifikační kód je možno zcizit nebo podstrčit (session fixation) po zapomenutí kódu (zavření prohlížeče) je session nepřístupná
  
  Nejpoužívanější způsob ukládání stavu webových aplikací.
  
  • viz příloha • •
  
  http://akela.mendelu.cz/~xpopelka/cs/apv/ost/ses sion-soubory.pdf http://akela.mendelu.cz/~xpopelka/cs/apv/ost/ses sion-databaze.pdf
  
  • Uchování stavu je nutná podmínka k realizaci zabezpečení
  
  • Problém 1: •
  
  uživatel
  
  • Problém 2: •
  
  uchování stavu přihlášení, zabránění zcizení stavu
  
  • Problém 3: •
  
  zabezpečení jména a hesla
  
  • Problém 4: •
  
  kontrola uživatelských vstupů
  
  • Jméno kočičky není dobré heslo •
  
  • • • •
  
  tedy pokud se kočička nejmenuje XdTg42W
  
  Jakékoliv heslo složené ze slov je slabé Jakékoliv heslo napsané na nástěnce je slabé Čím častěji je heslo použité tím je slabší Pro srovnání: • • •
  
  slušný jazyk = 250 000 slov 8 míst = 6 553 600 000 000 kombinací 10 míst = 10 485 760 000 000 000 kombinací
  
  • autentizace – authentication – ověření identity uživatele • autorizace - authorization – ověření oprávnění uživatele • autentification – zkomolenina authentication • 4 způsoby ověření identity uživatele: • • • •
  
  co víte (heslo) co máte (klíč, certifikát – velmi dobré) kdo jste (otisk prstu – nepřesné) co děláte (hlasu, rukopisu – napodobitelné)
  
  • 2F (two-factor) ověřování
  
  • Heslo je možné zadat do HTML formuláře • • •
  
  Odesílá se nešifrované (plaintext) v POST požadavku. Odposlechnutí hesla je jednoduché. Podstrčení formuláře je jednoduché.
  
  • Pro přihlášení je možné využít přihlášení protokolu HTTP •
  
  Odposlechnutí hesla je složitější
  
  • Při přihlášení přes webový formulář se posílá heslo jednorázově (při odeslání formuláře) •
  
  po ověření hesla musí server uchovávat stav přihlášení problém identifikace klienta různé metody verifikace
  
  • • • •
  
  kontrolní kódy, časově omezené kódy není spolehlivé
  
  POST https://login.szn.cz/loginProcess HTTP/1.1 Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.msxpsdocument, application/xaml+xml, application/vnd.ms-excel, application/vnd.mspowerpoint, application/msword, */* User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322) Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate Host: login.szn.cz Content-Length: 131 Connection: Keep-Alive Cache-Control: no-cache Accept-Language: cs loggedURL=http%3A%2F%2Femail.seznam.cz%2Fticket&serviceId=email&forceSSL=0&use rname=mrkvicka&domain=seznam.cz&password=cibulka&js=1
  
  • Při přihlášení pomocí HTTP se heslo odesílá při každém požadavku • •
  
  je možné uchovávat stav přihlášení nebo je možné ověřovat jméno a heslo při každém požadavku heslo je mnohočetným přenosem oslabováno
  
  • •
  
  • • •
  
  je nutné kombinovat s šifrováním
  
  umožňuje ukládání Session do databáze odpadá problém identifikace klienta 2. nejbezpečnější způsob 1F přihlašování (hned po přihlášení osobním certifikátem)
  
  • 2 základní varianty: •
  
  basic • •
  
  •
  
  jednoduché ověřování heslo se posílá nešifrované
  
  digest • • • •
  
  komplexní dvoustranné ověřování heslo se nikdy neposílá plaintextově umožňuje ověření integrity stránky ověřování každého přístupu • braní se opakování požadavku • složitá implementace
  
  GET /eyen2/ HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/xshockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Accept-Language: cs UA-CPU: x86 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322) Host: virklis.cust.ignum.cz Connection: Keep-Alive
  
  HTTP/1.1 401 Unauthorized Date: Thu, 16 Apr 2009 08:26:07 GMT Server: Apache X-Powered-By: PHP/5.1.6 Set-Cookie: PHPSESSID=05pbojjjidmtu8s94avgp3djo0; path=/ Last-Modified: Thu, 16 Apr 2009 08:26:07 GMT Cache-control: private, no-cache, no-store, must-revalidate Set-Cookie: PHPSESSID=f2rsf9ijsfk97vmifk4pkpajt1; path=/ WWW-Authenticate: Basic realm="Eyen - Amadeo installer" status: 401 Unauthorized Content-Length: 1039 Keep-Alive: timeout=15, max=64 Connection: Keep-Alive Content-Type: text/html;charset=utf-8;language=cs
  
  GET /eyen2/ HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/xshockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Accept-Language: cs UA-CPU: x86 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322) Cookie: PHPSESSID=f2rsf9ijsfk97vmifk4pkpajt1 Connection: Keep-Alive Host: virklis.cust.ignum.cz Authorization: Basic bG9naW46bW9qZXRham5laGVzbG8=
  
  • base64_decode(‘bG9naW46bW9qZXRham5laG VzbG8=‘); • login:mojetajneheslo
  
  GET /eyen/ HTTP/1.1 Accept: */* Accept-Language: cs UA-CPU: x86 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322) Host: 192.168.1.123 Connection: Keep-Alive Pragma: no-cache Cookie: PHPSESSID=3cf24mkcm3u6mb91m65aah8s90
  
  HTTP/1.0 401 Unauthorized Date: Thu, 16 Apr 2009 08:33:28 GMT Server: Apache/2.2.10 (Win32) DAV/2 mod_ssl/2.2.10 OpenSSL/0.9.8i SVN/1.5.4 PHP/5.2.7 X-Powered-By: PHP/5.2.7 Last-Modified: Thu, 16 Apr 2009 08:33:28 GMT Cache-control: private, no-cache, no-store, must-revalidate WWW-Authenticate: Digest realm="EyenInstaller", qop="auth", nonce="cbf80c608e0ba3bfcaf8ec4d1f3ea0cc", opaque="ceef418ef038687855e6755e91d68b01" Content-Length: 1557 Connection: close Content-Type: text/html;charset=utf-8;language=cs
  
  GET /eyen/ HTTP/1.1 Accept: */* Accept-Language: cs UA-CPU: x86 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322) Cookie: PHPSESSID=3cf24mkcm3u6mb91m65aah8s90 Connection: Keep-Alive Pragma: no-cache Authorization: Digest username="login",realm="EyenInstaller",nonce="cbf80c608e0ba3bfcaf8ec4d1f3 ea0cc",uri="/eyen/",cnonce="757efac677e3fe31bb5e4744b212822f",nc=00000 001,response="8699a023df2dc7205f51c29a35ad51e0",qop="auth",opaque="ce ef418ef038687855e6755e91d68b01" Host: 192.168.1.123
  
  • • • •
  
  • •
  
  •
  
  nonce – token unikátní pro každé přihlášení cnonce – unikátní token generovaný klientem nc – počet použití nonce response – • $a1_hash = md5($user_name.":".SYS_REALM.":".$password) • $a2_hash = md5($_SERVER['REQUEST_METHOD'].":". $digest['uri']); • $response = md5($a1_hash.":".$digest['nonce'].":". $digest['nc'].":".$digest['cnonce'].":".$digest['qop'].":".$a2_hash); qop – auth/auth-int – přihlášení/přihlášení + verifikace poslaného obsahu opaque – kontrolní kód • $opaque = md5(uniqid(rand(), true).SYS_REALM) http://www.ietf.org/rfc/rfc2617.txt
  
  • Šifrovaný přenos je možný pomocí protokolu HTTPS • Funguje jako obálka protokolu HTTP. • Při šifrovaném přenosu zbývá zabránit podstrčení stránky • K ověření pravosti stránky slouží certifikáty. • Šifrovaný přenos není nikdy cachovaný • •
  
  zpomalení přenosu zvýšení zátěže serveru
  
  • Cílem certifikátu je ověřit pravost subjektu •
  
  Každý certifikát musí ověřit certifikační autorita.
  
  • Existují i self-signed certifikáty pro testovací účely
  
  • Prakticky stačí použít jednosměrný kódovací algoritmus • •
  
  sha1, md5, tth, atd... dekódování je natolik náročné, že se útočník raději zaměří na jinou část aplikace
  
  • Bezpečnější je použít (jednosměrný) šifrovací algoritmus. •
  
  Vyžaduje uchování/generování klíče.
  
  • Hesla by měla být uložena v DB s vhodně nastavenými oprávněními.
  
  • Aby byl šifrovaný přenos bezpečný, musí být platné certifikáty. • Heslo musí být silné, jinak se dá uhádnout a žádné zabezpečení nepomůže. • Uživatel musí být ostražitý. • 2F zabezpečení je úplně někde jinde než 1F zabezpečení. • 2F zabezpečení není zadaní dvou hesel!
  
  http://www.xkcd.com/
  
  • Ošetření speciálních znaků při vkládání dat do databáze (pg_escape_string()) • • •
  
  SQL injection uvozovky, znak #0 podle DB serveru případně i další
  
  • Ošetření speciálních znaků při zobrazování stránky na webu (html_special_chars()) • • •
  
  Cross site scripting (XSS) HTML značky Skripty na straně klienta
  
  • <script>alert(‘no nazdar'); • http://error-nerds.com/how-tofix/?id=Driver%20error • Vzhledem k tomu, že escapování je nutné u každého řetězce – mají PHP funkce k tomu určené velmi krátké názvy • mysql_real_escape_string(htmlspecialchars($st ring, ENT_QUOTES, 'UTF-8')); • pokud je to možné je dobré ukládat data escapovaná
  
  http://error-nerds.com/how-tofix/?id=%3C%3cscript%3Ef=String.fromCharCode;document.images%5B5%5D.src=f%28104%29%2bf%28116%29%2bf%28116%29%2bf%28112%29%2bf %2858 %29%2bf%2847%29%2bf%2847%29%2bf%28105%29%2bf%28109%29%2bf%2897%29%2bf%28103%29%2bf%28101%29%2bf%28115%29%2bf%2846%29%2 bf%28101%29%2bf%28110%29%2bf%2899%29%2bf%28121%29%2bf%2899%29%2bf%28108%29%2bf%28111%29%2bf%28112%29%2bf%28101%29%2bf%2 8100%29%2bf%28105%29%2bf%2897%29%2bf%28100%29%2bf%28114%29%2bf%2897%29%2bf%28109%29%2bf%2897%29%2bf%28116%29%2bf%28105 %29%2bf%2899%29%2bf%2897%29%2bf%2846%29%2bf%2899%29%2bf%28111%29%2bf%28109%29%2bf%2847%29%2bf%28105%29%2bf%28109%29%2b f%2897%29%2bf%28103%29%2bf%28101%29%2bf%28115%29%2bf%2847%29%2bf%2853%29%2bf%2847%29%2bf%2853%29%2bf%28100%29%2bf%2847 %29%2bf%2872%29%2bf%28101%29%2bf%28108%29%2bf%28108%29%2bf%28111%29%2bf%2846%29%2bf%28106%29%2bf%28112%29%2bf%28103%29 %3C/script%3E
  
  • je závislé na kontextu ve kterém se data zobrazují • •
  
  buď se musí escapovat při zobrazení nebo při uložení a pak dost složitě konvertovat
  
  function esc($string) { return mysql_real_escape_string( htmlspecialchars($string, ENT_QUOTES, 'UTF-8'));
  
  } function esc($string) { return pg_escape_string( htmlspecialchars($string, ENT_QUOTES, 'UTF-8'));
  
  }
  
  Aplikace
  
  • Aplikace je program určený pro uživatele. • Aplikaci je možné rozdělit na části: •
  
  prezentační vrstva •
  
  •
  
  vstup dat, zobrazení výsledků, uživatelské rozhraní, logika uživatelského rozhraní
  
  aplikační vrstva •
  
  •
  
  zpracování dat, výpočty, logika práce s daty, business logic
  
  datová vrstva •
  
  ukládání a čtení dat, logika skladování dat
  
  • Postup vytvoření aplikace zahrnuje: • • • • •
  
  rozbor zadání návrh architektury volba technologie programování testování
  
  • Volba technologie a návrh architektury probíhají souběžně a prolínají se • Počítač je nutný pouze na závěr programování a testování
  
  • • • •
  
  záleží na okolnostech nejzásadnější proces celého vývoje aplikace vyžaduje analýzu prostředí zákazníka nejosvědčenější metody: • • • • •
  
  kvalifikovaný odhad nekvalifikovaný odhad psychologie věštění z křišťálové koule věštění z čajových lístků
  
  • http://www.projectcartoon.com/ProjectCartoo n.pdf
  
  http://stuffthathappens.com
  
  • struktura a způsob rozložení služeb aplikace • • • • •
  
  prezentační služby (zobrazování) prezentační logika (rozložení UI) logika aplikace (aplikační algoritmy) logika dat (algoritmy pro práci s daty) ovládání dat (řízení přístupu k úložišti)
  
  • Obecně je nejvýhodnější třívrstvá (3-tier) architektura. • Přesto se používá i dvojvrstvá (2-tier) architektura •
  
  několik variant
  
  prezentační vrstva aplikační vrstva datová vrstva
  
  • • • • •
  
  klient-server se vzdálenými daty (file server) velká zátěž klienta velká zátěž přenosového kanálu malá zátěž serveru subversion, DFS, NFS
  
  • • • •
  
  klient-server se vzdálenou prezentací malé zatížení klienta a přenosového kanálu velká zátěž serveru z pohledu klienta není rozlišitelné od třívrstvé architektury • případ mnoha webových aplikací
  
  • • • •
  
  klient-server s rozdělenou logikou (hybridní) dobré rozložení zátěže horší rozšiřitelnost a přenositelnost z pohledu klienta není rozlišitelné od třívrstvé architektury • případ některých webových aplikací
  
  • Data jsou uložena ve formátu daném potřebami aplikace – jsou nepřenositelná. • Změna datového skladu vyžaduje změnu všech klientů. • Důvody používání byly: • •
  
  snadnější první implementace a návrh nerozvinuté nebo nedostupné univerzální technologie • • •
  
  databázové servery aplikační servery komponenty
  
  • dobré rozložení zátěže • malá zátěž komunikačních kanálů • dobrá rozšiřitelnost (s využitím standardizovaných rozhraní) • flexibilní architektura • webové aplikace
  
  • Prezentační a datová vrstva jsou oddělené aplikační vrstvou. •
  
  prezentační klienta nemůže ovlivnit datový sklad •
  
  • •
  
  zvýšení bezpečnosti, spolehlivosti a flexibility
  
  při použití vhodných rozhraní je možné měnit prezentační klienty při použití vhodných rozhraní je možné měnit datový sklad
  
  • Rozhraní (interface) je něco, co je mezi něčím a něčím jiným.
  
  • Webový prohlížeč je zcela nezávislý na databázovém serveru. • • •
  
  Webovému prohlížeči je lhostejné, jaký databázový server poskytl data. Můžeme změnit datový sklad a prohlížeč „si toho nevšimne“. Můžeme změnit prohlížeč a databázový server „si toho nevšimne“.
  
  • Aplikační úroveň tvoří rozhraní mezi datovou a prezentační vrstvou.
  
  • podpora distribuovaných systémů
  
  • výběr technologie podle požadovaných vlastností aplikace: • • • •
  
  síťová / lokální klient-server / samostatná (standalone) kompilovaná / interpretovaná nativní (native) / runtime
  
  • databázová aplikace • webová aplikace • výběr jazyka a vývojového prostředí •
  
  IDE – integrated development environment
  
  Roste:
  
  • interpretovaný kód •
  
  náklady na vývoj
  
  skriptovací jazyky (PHP, VBS (ASP), JSP), …
  
  výkon
  
  možnosti interakce s uživatelem množství dostupných funkcí OS
  
  • runtime prostředí •
  
  jazyky Java (JRE), C# (.NET), …
  
  Roste: rychlost vývoje
  
  • nativní aplikace •
  
  C, C++, Delphi, …
  
  přenositelnost
  
  • WA je aplikace přístupná přes webový server. • Webová stránka slouží jen k poskytování obsahu (jen čtení dat). • Webová aplikace umožňuje interakci s uživatelem (čtení i vkládání dat). • Webová aplikace je soubor více či méně propojených programů. •
  
  každý skript je téměř samostatný
  
  • Výhody: rychlý vývoj (RAD), vysoká přenositelnost, nízké náklady na provoz
  
  • O některé věci se programátor nemusí starat • O některé věci se programátor nemůže starat
  
  
  
  
  
  1.Vložit mezeru mezi slovy „Přenosová rychlost:“ a veličinou přenosové rychlosti: 2.Opravit chybu ve větě: „Před otevřením souboru thoto typu vždy zobrazit tento dotaz“.
  
  Znakové sady
  
  • Znak – symbol • Kódování ≈ znaková sada = kódová stránka (encoding ≈ character set (charset) = code page) • • •
  
  Je systém přiřazování číselných kódů znakům. Je reprezentováno tabulkou (mapování). Cílem je možnost ukládat symboly ve formě čísel.
  
  • Kódové slovo – kód přiřazený symbolu • Kódová jednotka – elementární část kódu
  
  • •
  
  Délka kódu je maximálně jeden byte (single-byte) Znaková sada ASCII (základní) • •
  
  délka kódu: 7 bitů → 128 znaků Obsahuje znaky anglické abecedy, čísla, základní interpunkční znaménka a řídící (netisknutelné) znaky (control characters) •
  
  •
  
  NULL, CR, LF, TAB, ...
  
  Rozšířená sada ASCII = „Národní znakové sady“ • • • •
  
  délka kódu: 8 bitů → 256 znaků Různé varianty obsahují různé specifické národní znaky. Výhodou je snadné zpracování a rychlost. Nevýhodou je nedostatečný rozsah sady (čínština má tisíce znaků).
  
  • Délka kódu je jeden a více bajtů (multi-byte) • Kódovou jednotkou je jeden byte. • Rozsah znakové sady závisí na počtu kódových jednotek. • Dvě základní varianty: • •
  
  Všechny znaky jsou kódované stejným počtem bytů. Každý znak může být kódován různým počtem bytů podle potřeby (operace s řetězci jsou náročnější).
  
  • • • •
  
  Základní znaková sada ASCII obsahuje pouze znaky anglické abecedy – jedno-bytové kódování. Neobsahuje žádné znaky národních abeced. V 80. letech vzniklo množství národních znakových sad. Pro češtinu existují: • • • •
  
  •
  
  ISO-8859-2 (ISO Latin 2) windows-1250 (CP1250) CP852 (PC Latin 2) a další: KEYBCS2 (kódování bratrů Kamenických, CP859), East8, ICL, Cork
  
  Klíčovým problémem je nedostatek pozic pro různé národních znaky - jednotlivé znaky se překrývají.
  
  •
  
  • • • • • •
  
  Současně se vznikem národních kódování začala vznikat univerzální znaková sada – více-bytové kódování. Dvě iniciativy – Unicode Consortium a ISO. V roce 1991 se již dříve kompatibilní standardy sloučily do Unicode. Všechny verze standardu Unicode vychází souběžně jako ISO standardy. Jednotlivé verze standardu jsou vzájemně kompatibilní. Poslední verze Unicode 6.0 vyšla v roce 2010 http://www.unicode.org
  
  • Znaková sada Unicode definuje několik kódování: UTF-7, UTF-8, UTF-16 a UTF-32. • Kromě kódování Unicode (UTF-n) se používají ještě starší kódování ISO: UCS-2, UCS-4. • Velikost kódové jednotky je 1, 2 nebo 4 byty. • Pokud je kódová jednotka větší jak 1 byte, tak je nutné určit pořadí bytů. • •
  
  Big Endian (výchozí pořadí) nebo Little Endian Pořadí bytů se určuje značkou BOM (Byte Order Mark) na začátku souboru/dat.
  
  Min. počet bytů Max. počet bytů Velikost kódové jednotky • • •
  
  UTF-8 UTF-16 UTF-32 UCS-2 UCS-4 1 2 2 2 4 4
  
  4
  
  8 bitů
  
  16 bitů
  
  4
  
  2
  
  4
  
  32 bitů 16 bitů 32 bitů
  
  Unicode má nyní 98,884 tisknutelných znaků. Více jak 800000 dalších pozic je volných. Kromě toho umožňuje i definice vlastních znaků.
  
  Všechny znaky Proměnná délka znaku Režie Kompatibilní s ASCII Závisí na pořadí bytů Doporučeno k používání
  
  UTF-8 UTF-16 UTF-32 UCS-2 UCS-4 ano ano ano ne ano ano
  
  ano
  
  ne
  
  ne
  
  ne
  
  malá ano
  
  střední ne
  
  velká ne
  
  ne
  
  ano
  
  ano
  
  ano
  
  ano
  
  ano
  
  ano
  
  ano
  
  ne
  
  ne
  
  střední velká ne ne
  
  function utf8_strlen($str) { $count = 0; for ($i = 0; $i < strlen($str); $i++) { //pres vsechny znaky $value = ord($str[$i]); if ($value > 127) { if ($value >= 192 && $value <= 223) { $i++; } elseif ($value >= 224 && $value <= 239) { $i = $i + 2; } elseif($value >= 240 && $value <= 247) { $i = $i + 3; } else { echo ‘Not a UTF-8 compatible string ' } } $count++; } return $count; }
  
  • UTF-8 řeší naprostou většinu všech problémů s kódováním. • Aplikace může pracovat s daty v libovolném jazyce. • Podpora ze strany aplikací je stále ještě špatná. • Pro reprezentaci dat uvnitř aplikace může být někdy výhodnější využít kódování s konstantním počtem bytů na jeden znak. • Příliš žluťoučký kůň pěl ďábelské ódy.
  
  http://kantorek.webzdarma.cz/
  
  • uložené procedury (stored procedures) • triggery, sekvence, pohledy, funkce, parametrické dotazy (prepared statements) • komplexní agregace a SQL dotazy • jiné databázové systémy • ukládání strukturovaných dat – seznamy, stromy, … • ukládání speciálních dat – obrázky, soubory, … • optimalizace SQL dotazů, konfigurace DB serveru • Databázové systémy I, Databázové systémy II
  
  • Sítě, síťové protokoly, topologie • Detaily protokolů používaných v internetu – HTTP, maily, přenos souborů, šifrování • XML, DTD, schémata • DOM, Javascript , skriptování na straně klienta, AJAX • Grafika, vytváření CSS, zásady designu, uživatelská rozhraní • Počítačová grafika I, Webový design, Webové aplikace, XML aplikace,
  
  • metodiky pro • •
  
  • •
  
  návrh aplikace, výběr technologií, vytvoření architektury aplikace návrh datových struktur, vytváření databázového schématu návrh uživatelského rozhraní testování software, QA
  
  • Informační systémy a technologie, Bezpečnost informačních systémů, Informační systémy (projektování), Softwarové inženýrství I, Softwarové inženýrství II
  
  • jiné jazyky než PHP • kompilované jazyky • PHP • • • • •
  
  jiná databázová rozhraní objekty polymorfismus interpretovaného jazyka akcelerátory, moduly frameworky
  
  • Java aplikace, Programovací jazyk Perl,
  
  In theory, there is no difference between theory and practice. But, in practice, there is. Jan L. A. van de Snepscheut