Poslední modifikace: 2020-03-25 16:31:03 UTC
architektura webových databázových aplikací
k čemu se používají databázové aplikace na Webu
databázové servery
relační model dat
jazyk SQL
spolupráce webové aplikace s databází
problémy webových databázových aplikací
typická třívrstvá architektura
webový prohlížeč = velmi tenký klient
webový server + webová aplikace = aplikační logika + generování prezentační vrstvy pro prohlížeč
databázový server = databáze (někdy i část aplikační logiky)
hranice jednotlivých vrstev jsou hodně volné
díky JS může být klient i „hodně tlustý“
některé databáze rovnou obsahují REST API, takže webový server jen zajišťuje HTTP komunikaci
skoro každá webová aplikace používá nějakou databázi – data je potřeba někam ukládat
podnikové informační systémy – nízké TCO, ZAC
vyhledávací služby, katalogy, knihovny
i chat je databázová aplikace – jednotlivé zprávy je potřeba někam uložit
nižší náklady na správu, centralizovaná údržba dat a aplikace je snazší a levnější
SŘBD (DBMS), databáze, databázový server, SQL server
přístup datům řídí server (na rozdíl od souborových databází jako MS Access, Paradox, dBase apod.)
lze zajistit současnou práci více uživatelů
snese i velmi vysokou zátěž
komunikace se serverem většinou probíhá po síti (nejčastěji TCP/IP)
Oracle, MS SQL Server, MySQL, PostgreSQL, Sybase, DB/2, PostgreSQL, …
nativní – každá aplikace má svůj protokol
lze plně využít všechny funkce databáze
přenos aplikace na jiný databázový server je komplikovaný
standardizovaná rozhraní – ODBC, JDBC, PDO, …
je přidána vrstva navíc, která odstiňuje nativní protokol
při změně databázového serveru stačí změnit ovladač
pro předávní příkazů se používá jazyk SQL
data jsou ukládána do tabulek (relací)
matematicky je model popsán relační algebrou
pojmy
tabulka
položka/atribut/sloupec – má název a typ
záznam/řádek – je jednoznačně identifikován hodnotou primárního klíče
primární klíč – nejmenší množina atributů, které jednoznačně identifikují záznam
druhy
1:1
1:N
M:N – musí se rozložit na dva vztahy 1:N
v tabulkách se vztahy zaznamenávají pomocí primárních a cizích klíčů
SQL – Structured Query Language
jednoduchý dotazovací jazyk
většina databází implementuje standard plus nějaká rozšíření
výběr dat, přidávání záznamů, mazání záznamů, modifikace záznamů, práce se strukturou databáze, s uživateli a právy, …
příkaz SELECT vybírá data z tabulek
vrací zase tabulku
SELECT seznam výstupních položek
FROM seznam tabulek
WHERE podmínka
GROUP BY seznam položek
HAVING skupinová podmínka
ORDER BY kritéria třídění
SELECT * FROM Zamestnanci;
SELECT Jmeno, Plat FROM Zamestnanci WHERE Plat > 10000;
SELECT * FROM Zamestnanci WHERE Jmeno LIKE 'Nov%';
SELECT * FROM Zamestnanci
WHERE (Plat < 7000) AND NOT (Jmeno LIKE 'Novák %');
SELECT * FROM Zamestnanci
ORDER BY Jmeno;
SELECT Nazev, Jmeno FROM Odberatele, Zamestnanci
WHERE Odberatele.Zastupce = Zamestnanci.OsobniCislo
INSERT INTO jméno tabulky
(jméno položky, jméno položky, …)
VALUES (hodnota, hodnota, …)
INSERT INTO jméno tabulky
VALUES (hodnota, hodnota, …)
INSERT INTO Zamestnanci
VALUES (1023, 'Novák Jan', '561220/0235', 'Levá 13, Praha 4', 12000)
DELETE FROM jméno tabulky WHERE podmínka
DELETE FROM jméno tabulky
DELETE FROM Zamestnanci WHERE OsobniCislo = 1023;
UPDATE jméno tabulky
SET jméno položky = hodnota položky,
jméno položky = hodnota položky,
...
jméno položky = hodnota položky
WHERE podmínka
UPDATE Zamestnanci
SET Jmeno = 'Procházková Alena'
WHERE OsobniCislo = 1168;
CREATE TABLE název tabulky (
název položky typ,
název položky typ,
název položky typ,
název položky typ,
…)
CREATE TABLE Zamestnanci (
OsobniCislo int NOT NULL PRIMARY KEY,
Jmeno varchar(40),
RC char(11),
Adresa varchar(60),
Plat decimal(10,2))
CREATE TABLE Proj_Zam (
ID_Projektu char(6) NOT NULL,
OsobniCislo int NOT NULL,
PRIMARY KEY (ID_Projektu, OsobniCislo))
vytvoření připojení k databázi
zaslání SQL příkazu k provedení
zpracování výsledku
odpojení od databáze
<?php
try
{
// připojení k databázi
$db = new PDO("mysql:host=localhost;dbname=test", "jméno", "heslo");
// zaslání dotazu a čtení výsledku
foreach ($db->query("SELECT * FROM Zamestnanci ORDER BY Jmeno") as $radka)
{
// zpracování jednotlivých řádek výsledku
echo $radka["OsobniCislo"], " ", $radka["Jmeno"], "<br>\n";
}
}
catch (PDOException $e)
{
// obsluha případné chyby při práci s databází
echo "Při práci s databází došlo k chybě: " . $e->getMessage();
}
?>
aplikace nepracuje přímo s databází, ale používá se mezivrstva, která zajišťuje transparentní mapování a perzistenci objektů v paměti na data v databázi
programátor pracuje s objekty, nepíše přímo SQL kód
jednodušší vývoj, menší riziko chyby a překlepu v SQL kódu
v mezních případech může automatické mapování generovat pomalé dotazy a je nutný ruční zásah
příklady: Doctrine (PHP), Hibernate (Java)
dotazovací jazyk a runtime určený zejména pro API
GraphQL umožňuje popsat data dostupná přes API a dotaz pak automaticky vybere a vrátí jen potřebná data v požadované struktuře
není tak dopředu potřeba vymýšlet a optimilizovat API na všechny druhy dotazů, které bude potřeba provádět
implementace GraphQL existují pro různá úložiště, velmi často operují nad klasickou relační databází
typicky jednoduché úložiště klíč/hodnota
hodnota může obsahovat cokoliv, například strukrovaný datový záznam zapsaný pomocí JSON
dotazy je potřeba „dělat ručně“, protože NoSQL nepodporuje dotazovací jazyk, spojení tabulek, …
díky jednoduchosti oproti SQL-databázím teoreticky umožňuje lepší škálovatelnost
kromě samostatných produktů tento přístup často používají cloudová úložiště (Amazon S3, Google Storage, …)
relační datový model je umělý, datový model XML je v mnoha případech mnohem bližší modelované realitě
do databáze se ukládají jednotlivé XML dokumenty – např. stránky v CMS, faktury, objednávky, …
k dispozici jsou speciální dotazovací jazyky pro XML – XQuery, XPath, …
hodí se pro aplikace, které pracují se silně strukturovanými daty, pro které se nehodí relační datový model
databáze rovnou ukládá objekty, se kterými pracuje aplikace
technologie se nikdy příliš nerozšířila
sémantický web – databáze ukládá přímo logické výroky
existují speciální dotazovací jazyky – SPARQL
pro produkční nasazení „v internetovém měřítku“ zatím spíše nevyspělá technologie
perzistentní spojení (connection pooling)
pozor, může dojít k překročení limitu spojení do databáze
použití databází optimalizovaných na čtení – portály
vyrovnávací paměť (cache) – v případě potřeby předgenerovat co se dá do souborů nebo sdílené paměti
v žádném případě nepoužívat MS Access a podobné „rádoby“ databáze
nelze použít klasické zamykání záznamů, protože prohlížeč (klient) se po každém požadavku odpojí
problém se řeší jinak
vítězí, kdo přišel první
zamknutí záznamu s identifikací uživatele a časovým limitem
vhodné pro systémy, kde je možnost kolize vysoká
vítězí, kdo první provede změnu
kontrola změny dat před jejich konečnou modifikací
jednodušší na implementaci
vhodné pouze pro případy, kdy je pravděpodobnost kolizí malá