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 24196×

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ů

8.1.2017 17:51 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Přijď na sraz spolku OpenAlt, který se bude konat ve čtvrtek 19. ledna od 18:30 v pražském hackerspacu Brmlab. Tentokrát je tématem srazu ergonomie ovládání počítače – tzn. klávesnice, myši a další zařízení. K vidění bude mechanická klávesnice dasKeyboard, trackball Logitech nebo grafický tablet (a velký touchpad) Wacom. Přineste i vy ukázat svoje zajímavé klávesnice a další HW. V 18:20 je sraz před budovou, v 18:30 jdeme společně dovnitř, je tedy dobré přijít včas. Podle zájmu se později přesuneme do nějaké restaurace v okolí.
Přidat komentář

1.12.2016 22:13 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Přijď na sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.
Komentářů: 1

4.9.2016 20:13 /Pavel `Goldenfish' Kysilka
PR: Dne 22.9.2016 proběhne v Praze konference Cloud computing v praxi. Tématy bude např. nejnovější trendy v oblasti cloudu a cloudových řešení, provozování ERP v cloudu, o hostování různých typů softwaru, ale třeba i o zálohování dat nabízeném podnikům formou služby.
Přidat komentář

1.9.2016 11:27 /Honza Javorek
Česká konference o Pythonu, PyCon CZ, stále hledá přednášející skrz dobrovolné přihlášky. Máte-li zajímavé téma, neváhejte a zkuste jej přihlásit, uzávěrka je již 12. září. Konference letos přijímá i přednášky v češtině a nabízí pomoc s přípravou začínajícím speakerům. Řečníci mají navíc vstup zadarmo! Více na webu.
Přidat komentář

27.8.2016 8:55 /Delujek
Dnes po 4 letech komunitního vývoje vyšla diaspora 0.6.0.0
diaspora* je open-source, distribuovaná sociální síť s důrazem na soukromý
Více v oficiálním blog-postu
Přidat komentář

24.8.2016 6:44 /Ondřej Čečák
Poslední týden CFP LinuxDays 2016; pokud byste rádi přednášeli na LinuxDays 2016 8. a 9. října v Praze, můžete svůj příspěvek přihlásit, následovat bude veřejné hlasování.
Přidat komentář

9.8.2016 22:56 /Petr Ježek
Zařazení souborového systému reiser4 do jádra 4.7 znamená konečně konec patchování jádra jen kvůli možnosti použít reiser4.
Přidat komentář

12.7.2016 13:14 /František Kučera
Spolek OpenAlt zve na 130. distribuovaný sraz příznivců svobodného softwaru a otevřených technologií (hardware, 3D tisk, SDR, DIY, makers…), který se bude konat ve čtvrtek 21. července od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

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

> Poslední diskuze

18.1.2017 20:18 / martin horky
Spolupraca linuxu a microsoftu

17.1.2017 9:57 / Pavel Hrubeš
Re: Externí USB televizní karta

4.1.2017 11:24 / Marcum
extension to house

3.1.2017 10:09 / bolden
country cottages

4.12.2016 22:54 / František Kučera
Dárek

Více ...

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