LINUXSOFT.cz Přeskoč levou lištu
Uživatel: Heslo:  
   CZUKPL

> PostgreSQL (2) - Proč PgSQL, data a relace

V tomto díle si napíšeme o tom, proč používat zrovna PostgreSQL, přiblížíme si význam architektury klient/server a především o uložení dat v databázi.

1.9.2004 10:00 | MaReK Olšavský | Články autora | přečteno 24772×

Komerční sdělení: Pořádáme Kurzy PgSQL

Proč používat PostgreSQL

PostgreSQL je relační databáze podporující SQL92 a SQL99 normu a dalších mnoho moderních rysů:

  • komplexní dotazy
  • foreign keys (cizí klíče)
  • triggery (spouště)
  • views (pohledy)
  • transakce
  • vlastní datové typy
  • agregační funkce
  • stored procedures (uložené procedury a to nejen ve vlastním PL/SQL)

Server je vysoce rozšiřitelný (právě možnostmi definovat si vlastní datové typy a uložené procedury) a objektově-relační, což si také postupně ukážeme, co znamená.

Z hlediska programátora je výborná možnost přístupu z mnoha jazyků C/C++ (knihovny libpq a libpq++), scriptovacích jazyků Perl (pgsql_perl5), Python (PyGreSQL), ale i třeba javy (jdbc) a PHP. Ja sám jsem použil "pouze" poslední tři přístupy.

Vím, že teď asi vyvolám nevoli a možná i divoký flame pod článkem, ale PostgreSQL se mi jeví jako mnohem lepší databázové řešení, než MySQL, protože nabízí spoustu vymožeností, které MySQL nezvládá. Naproti tomu MySQL je nepoměrně rychlejší a na menší webové aplikace více, než dostatečná. Jako vždy je to především o aplikaci.

Data a relace

Databáze slouží k uložení nejrůznějších dat, jak už plyne z názvu. Data mohou být nejrůznějších typů od čísel celých, nebo v plovoucí desetinné čárce, přes textové údaje, datumy, časy až po binární soubory (o vkládání těch si myslím něco velmi nepěkného, ale jde to). Data představují vlastně vše, co chceme, aby nám databáze umožnila nějakým způsobem uložit a potom dále zpracovávat.

Databáze (ne databázový server) si můžeme představit jako sešit, kde se ukládají datové tabulky jako listy. V datových tabulkách pak najdeme rádky dat, které se v korektní terminologii nazývají větami. Každý záznam do databéze je jednou větou a skládá se z jedné (to by asi moc význam nemělo), nebo více položek. Každá z položek má určený svůj typ a tím ve většině případů i určenou velikost v bytech.

Pojem a koncepce relační databáze vychází s toho z matematického modelu, kdy můžeme pospojovat data z různých tabulek pomocí tak zvaných relačních operátorů (tj. =, <, > a jejich kombinací). Výsledkem je kartézký součin spojených množin.

Relace nám umožňují data rozebrat (tento proces se také nazývá normalizace databáze) do několika tabulek, v tomto díle si ukážeme logiku, jak data rozdělit. Rozdělení dat nám umožní jednako redukovat velikost databáze, obsazeného prostoru, odstraněním redundantních dat a druhako nám urychlí manipulaci, zejména pak vyhledávání, s daty, protože to je podstatně rychlejší v tabulkách, kde jsou kratší věty, než dlouhé. Na druhou stranu rozdělení dat do několika vět zvyšuje nároky kladené na programátora, protože je třeba uhlídat konzistenci dat. K tomu nám mohou pomoci i triggery (spouště).

Relace jsou několika typů, je to relace 1:1, tzn. jednomu záznamu v tabulce t1 odpovídá (přes nějaký spojovací klíč) právě jeden záznam v tabulce t2, relace 1:n, kdy jednomu záznamu v t1 odpovídá (zase přes klíč) n z tabulky t2 a nakonec m:n, která se v praxi nepoužívá, protože je i neefektivně matematicky popsatelná a převádí se na relace m:1 a 1:n přes rozumnou spojovací tabulku. Příkladem na poslední relaci může být vztah kategorie_výrobků <-> výrobky, kdy jeden výrobek může patřit do více kategorií a je obvyklé, že jedna kategorie obsahuje více výrobků.

Architektura klient/server

V dobách prvních PC byly aplikace ve většině případů jednovrstvé, to znamená, že aplikace řešila nejen nějaké zpracování dat, ale i jejich lokální uložení. Většina firem si nemohla dovolit zasíťovat kanceláře a vybudovat nějaký centrální databázový, nebo aplikační server. I dnes můžeme najít řadu aplikací, která takto pracují. Jsou to například kancelářské aplikace, či většina her.

Pro práci s většími a velkými objemy dat je vhodné přejít alespoň na dvouvrstvou architekturu, která může v případě potřeby běžet i lokálně na jednom počítači. Vy v aplikaci zpracováváte data, vyhodnocujete data, ale o jejich ukládání a případné filtrování, třídění, když o nějaká požádáte se stará SQL server. Troufám si tvrdit, že lokálně spuštěný server, na stejném počítači, kde pracuje, má tak 90-95% lidí, kteří věnují wwwývoji.

Při této architektuře máte v optimálním případě oddělenu práci s daty od jejich uskladnění a komunikaci mezi klientskou aplikací a serverem řešíte pomocí nějakého standardního rozhraní, kterým může být třeba SQL jazyk.

Při práci na velkých projektech, jaké se dělají třeba pro banky, vstupuje do hry třívrstvá architekrura, kdy mezi klientskou část (která se pak skoro už redukuje jen na formuláře pro zadávání a čtení dat) a databázový server vstupuje nějaký aplikační server, kde běží tzv. middleware. Poslední dobou se střetávám s tím, že mnoho takovýchto věcí běží na J2EE, takže se používají servery, nebo rozšíření serverů, Tomcat, JBoss, BEA Weblogic, případně nastupuje architektura .NET. Třeba Java běžící na 64 bitovém systému přímo od SUN Microsystem je rychlý a robusní nástroj na řešení této vrstvy aplikace.

Normalizace databáze

Nyní si už pomůžeme modelovým příkladem databáze, na které si ukážeme, jak se prakticky provádí normalizace (tj. základní metoda optimalizace). Použijeme fiktivní obchod. O každé objednávce potřebujeme vědět, komu patří, co obsahuje za produkty a případně i dodavatele těchto produktů. Takže tabulka by mohla obsahovat tyto položky: ID_položky, jméno_zákazníka, příjmení_zákazníka, Adresa, Název_produktu, Popis,Cena, Číslo_objednávky, Datum, Množství, Dodavatel. Pro každou položku objedbávky by přibyla do databáze jedna věta, takže by objem dat rostl díky redundanci (nadbytečnosti) nade všechny meze.

Normalizace je sada pravidel, jak byste měli postupovat při návrhu struktury databázových tabulek. Je 7 stupňů normalizace, protože v praxi se používají v podstatě jen první 3 stupně, povíme si jen o nich. Jednolivé stupně jsou:

1. Stupeň normalizace

První stupeň nám říká, že bychom měli rozdělit data tak, aby opakující se sloupce byly v nových tabulkách pouze jednou a zároveň musí být mezi těmito sloupci definovatelná relace, obvykle přes nějaký číselný indikátor. Takže v našem případě by se tabulka rozpadla na tabulky:
Zákazníci: ID_zákazníka, Jméno, Příjmení, Adresa, Číslo_objednávky, Datum, ID_Zboží, Množství, Dodavatel
Produkty: ID_Produktu, Název, Popis, Cena, Obrázek.

Každý asi hned na první pohled vidí, že to také není ještě to pravé ořechové, protože když při objednávání zboží se nám budou neustále opakovat v databázi všechna data o zákazníkovi. Každopádně už zde nastane jistá úspora místa a nárůst rychlosti vůči původnímu stavu.

2. Stupeň normalizace

Druhý stupeň znamená že rozdělíme opakující se sloupce, které vytvářejí částečné závislosti do nových tabulek. V našem případě je logické, že každá tabulka obsahuje několik položek, takže je logické, kdy oddělíme tabulku objednávky od tabulky zákazníků, takže budeme mít následující tabulky:
Zákazníci: ID_Zákazníka, Jméno, Příjmení, Adresa
Produkty: ID_Produktu, Název, Cena
Objednávky: ID_Objednávky, ID_Zákazníka, Datum, Množství, Dodavatel
Objednávky_kompletace: ID_Komletace, ID_Zákazníka, ID_Objednávky
Přičemž poslední tabulka tvoří nějaké logické propojení mezi zbývajícími dvěmi.

V tomto stupni ještě stále není optimalizace na vysoké úrovni, opakuje se nám třeba název dodavatele v každé položce objednávky.

3. Stupeň normalizace

Vyžaduje důsledné odstranění dat, které nejsou v přímém vztahu s objektem. Tento krok bude v té mojí ukázkové databázi asi nejrazantnější. Při tomto třetím kroku optimalizace našeho příkladu se dostaneme k následující struktuře databáze:
Zákazníci: ID_Zákazníka, Jméno, Příjmení, Adresa
Produkty: ID_Produktu, Název, Popis, Cena
Dodavatelé: ID_Dodavatele, Jméno
Objednávky: ID_Objednávky, ID_Zákazníka, Datum
Objednávka_položka: ID_Položky, ID_Objednávky, ID_Produktu, Počet, ID_Dodavatele
Jednotlivé položky jsou v databázi pojmenované logicky, takže jsou, snad, vidět klíče, neboli položky, přes které jsou tabulky provázané.

Další stupně normalizace

Další stupně si dovolím jen vyjmenovat, protože z jejich názvu a z pozdějších kapitol vyplyne k čemu slouží, ale tyto stupně většinou zůstávají už jen na teoretické úrovni.

  • Čtvrtý stupeň normalizace (nemá název, takže tady nic nevyplyne, ale jedná se o další stupeň "rozbití" tabulek).
  • Normalizace pro spojovou transmutaci (Join-projection).
  • Odolná normalizace pro spojovou transmutaci (Strong Join-Projection).
  • Hyperodolná normalizace pro spojovou transmutaci (Over-Strong Join-Projection).
  • Normalizace pro klíč domény (Domain Key)

Databázi jsem ale nenormalizoval příliž optimálně, do tabulky položek objednávky by bylo slušné přidat cenu zboží v momentě objednávky, protože pokud se tato změní (obvykle zvýší), je slušné dodat zákazníkovi zboží za cenu v době objednání, pokud cenu obchodník sníží, je asi slušné mít obchod ošetřený tak, abyste dodávali zboží za novou cenu, ale to už je na uvážení programátora i obchodníka.

Kdy, jak a proč normalizovat

Vždy normalizujte databázi, jak moc a jakým způsobem bude nakonec vždy záležet pouze na Vašem vhledu a na zkušenostech, které už jste při programování získali.

Hlavním důvodem pro optimalizaci je úspora místa na disku a tím i zrychlení databáze, protože server nebude muset procházet tabulky, které mu narůstají takřka nekonečnou rychlostí. Zkuste si cvičně započítat, kolik místa ušetříte, když budete mít třeba 15.000 objednávek, pro popisy a názvy položek vyhradíte 100 bytů, ale ID_xxx budou mít bytů 10. Při třeba 100.000 objednávek, z nichž každá bude mít průměrně 3 položky už dojdete na velmi zajímavá čísla.

Normalizace dat přináší také jednu menší nevýhodu. Programátor musí více hlídat integritu dat. Při zrušení nějakého produktu jej tedy nejen smazat v tabulce produktů, ale informovat i všechny, kdo ten produkt měli objednaný a smazat všechny položky objednávek, kde byl tento produkt, nebo jej jinak zneplatnit. V té původní verzi stačilo jen informovat zákazníky a smazat věty, které jej obsahovaly. K tomuto mu mohou pomoci triggery (spouště) a uložené (stored) procedury, kteréžto nástroje PostgreSQL umí velmi dobře.

Závěrem

Dneska jsem napsal o důvodech, proč používat (proč mám rád PostgreSQL), něco o tom, proč databáze nazýváme relačními a něco malinko o optimalizaci tabulek pro ukládání dat. Příští díl bude o vytvoření databáze, uživatele a možná i o instalaci PostgreSQL serveru na LINUXu.

Verze pro tisk

pridej.cz

 

DISKUZE

Relace není vztah mezi tabulkami 19.5.2006 23:10 Lukáš Zapletal




Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

15.5.2017 23:50 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt, který se bude konat ve čtvrtek 18. května od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

12.5.2017 16:42 /Honza Javorek
PyCon CZ, česká konference o programovacím jazyce Python, se po dvou úspěšných ročnících v Brně bude letos konat v Praze, a to 8. až 10. června. Na konferenci letos zavítá např. i Armin Ronacher, známý především jako autor frameworku Flask, šablon Jinja2/Twig, a dalších projektů. Těšit se můžete na přednášky o datové analytice, tvorbě webu, testování, tvorbě API, učení a mentorování programování, přednášky o rozvoji komunity, o použití Pythonu ve vědě nebo k ovládání nejrůznějších zařízení (MicroPython). Na vlastní prsty si můžete na workshopech vyzkoušet postavit Pythonem ovládaného robota, naučit se učit šestileté děti programovat, efektivně testovat nebo si v Pythonu pohrát s kartografickým materiálem. Kupujte lístky, dokud jsou.
Přidat komentář

2.5.2017 9:20 /Eva Rázgová
Putovní konference československé Drupal komunity "DrupalCamp Československo" se tentokrát koná 27. 5.2017 na VUT FIT v Brně. Můžete načerpat a vyměnit si zkušenosti z oblasti Drupalu 7 a 8, UX, SEO, managementu týmového vývoje, využití Dockeru pro Drupal a dalších. Vítáni jsou nováčci i experti. Akci pořádají Slovenská Drupal Asociácia a česká Asociace pro Drupal. Registrace na webu .
Přidat komentář

1.5.2017 20:31 /Pavel `Goldenfish' Kysilka
PR: 25.5.2017 proběhne v Praze konference na téma Firemní informační systémy. Hlavními tématy jsou: Informační systémy s vlastní inteligencí, efektivní práce s dokumenty, mobilní přístup k datům nebo využívání cloudu.
Přidat komentář

15.4.2017 15:20 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě IoT a radiokomunikace? Přijď na sraz spolku OpenAlt, který se bude konat ve středu 19. dubna od 18:30 v Šenkovně (Sokolská 60, Praha 2).
Přidat komentář

5.3.2017 19:12 /Redakce Linuxsoft.cz
PR: 23. března proběhne v Praze konferenci na téma Cloud computing v praxi. Hlavními tématy jsou: Nejžhavější trendy v oblasti cloudu a cloudových řešení, Moderní cloudové služby, Infrastruktura současných cloudů, Efektivní využití cloudu, Nástrahy cloudových řešení a jak se jim vyhnout.
Přidat komentář

27.2.2017 22:12 /František Kučera
Pozvánka na 137. sraz OpenAlt – Praha: Tentokrát jsme si pro vás připravili neobvyklou akci. Ve středu 1.3. v 17:30 nás přivítá sdružení CZ.NIC ve svých prostorách v Milešovské ulici číslo 5 na Praze 3, kde si pro nás připravili krátkou prezentaci jejich činnosti. Následně navštívíme jejich datacentrum pod Žižkovskou věží. Provedou nás prostory, které jsou běžnému smrtelníkovi nedostupné!
Po ukončení prohlídky se všchni odebereme do hostince U vodoucha, Jagelonská 21, Praha 3 pochutnat si na některém z vybraných piv či dát si něco na zub. Rezervaci máme od 19:30, heslo je OpenAlt.
Ale pozor! Do prostor datového centra máme omezený přístup, dostane se tam pouze 10 lidí! Takže kdo přijde dříve, ten má přednost, a občanky s sebou! Kdo nebude chtít na prohlídku datového centra, může se pomalu přesunout do hostince U vodoucha a u nepřeberné nabídky piv počkat na ostatní.
Přidat komentář

18.1.2017 0:49 /František Kučera
Členové a příznivci spolku OpenAlt se pravidelně schází v Praze a Brně. Fotky z pražských srazů za uplynulý rok si můžete prohlédnout na stránkách spolku. Příští sraz se koná už 19. ledna – tentokrát je tématem ergonomie ovládání počítače – tzn. klávesnice, myši a další zařízení. Také budete mít příležitost si prohlédnout pražský hackerspace Brmlab.
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

1.8.2017 7:32 / Cassidy
structural consultants

30.7.2017 11:12 / Jaromir Obr
Národní znaky

27.7.2017 12:24 / Jaromir Obr
Cteni/zapis

26.7.2017 21:12 / Jaromir Obr
Podminka

15.6.2017 9:34 / Ondřej Havlas
php,

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2017) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze