Návrh databáze

25.9.2006 21:11 | Přečteno: 8887× | Ze života |

Prakticky žádný větší program pracující s nějakými daty se neobejde bez databáze. Klíčovou etapou je návrh databáze (ještě důležitější je návrh datového modelu, ale ten teď nechme stranou). Pojďme se podívat, jaké chyby se nejčastěji objevují.

Kdo někdy pracoval na nějakém větším softwarovém projektu, určitě to zná. Výchozí požadavky se přetaví (kromě jiného) v datový model, podle něj se navrhne databáze, a pak už se nad touto databází navrhují a implementují různé operace. Už samotný datový model bývá pořádný oříšek - a když se navrhne špatně, mnohdy to znamená krach celého projektu, nebo aspoň těžké problémy. Zaměřme se ale na další krok - datový model máme, a nyní se podle něj musí vytvořit databáze, zatím ještě většinou relační (i když třeba s objektovými prvky).

Jedná-li se o složitější databázi, není tato činnost rozhodně triviální. Velkou část lze automatizovat, ale stejně do toho musí zasáhnout člověk a dodat tomu ty správné myšlenky. Dodá-li špatné, výsledkem je buď nefungující databáze, nebo v lepším případě databáze neefektivní, špatně spravovatelná, obtížně měnitelná apod. Podívejme se nyní, s jakými chybami se můžeme u relačních databází nejčastěji setkat.

Nestrukturovaná data

Podstata spočívá v tom, že tvůrce "namastí" do jednoho atributu (pole, sloupce) nějaká data bez ladu a skladu. Může to být například nestrukturovaná poštovní adresa, ale třeba i nějaká historie změn, serializované nebo "serializované" datové struktury atd. Je snad jasné, co to přinese - velice obtížnou práci, vysoké riziko chyb, téměř nemožné prohledávání, validaci, řazení, filtraci a další podobné činnosti. Kdo něco takového vytvoří v systému pro produkční nasazení, zasloužil by urazit ruce.

Honba za normálními formami

Tohle je pravý opak. Zejména mezi databázovými teoretiky se rodí návrháři, kteří se snaží o co "nejčistší" databázi (rozuměj: v co nejvyšší normální formě), ovšem bez ohledu na ostatní aspekty. Výsledkem je rozdrobení databáze do spousty relací, z nichž je podstatná část zbytečná. Nejenže se taková databáze špatně spravuje (prase aby se v tom vyznalo), ale získat z ní nějaké informace znamená vytvářet obludné dotazy, kde se spojuje větší počet tabulek. Kromě složitosti takových dotazů je pořádně nepříjemná i jejich operační složitost, hlavně u databázových strojů s nižšími schopnostmi optimalizace. Obecně se doporučuje navrhnout databázi na 3. normální formu, a pak se ji snažit zjednodušit tak, aby přitom neutrpěla sémantika.

Špatná volba klíčů

Překvapivě rozšířený druh chyby, navíc s hrozbou vážných následků, a to přes relativní primitivnost řešení. Představme si například firemní informační systém. Návrhář uvažuje: "kód oddělení je číselný, unikátní a není důvod ho měnit, proto z něj udělám primární klíč". A problém je na světě. Pokud bude v databázi jen nějaká jednoduchá evidence oddělení, nebude se dít nic dramatického. Jenže pokud se bude nějak ukládat i historie změn, už začne tikat časovaná bomba. Pak stačí, aby si nějaký bláznivý manažer vymyslel, že přečísluje oddělení, a je o zábavu postaráno. Přitom je to jednoduché - stačí mít vždy klíč zcela samostatný, bez vlastního významu. Pak lze zvolit nejlepší datový typ, může být vždy unikátní, hodnotu není nikdy důvod měnit a to malé množství "nadbytečných" dat nehraje roli.

Nevhodné pojmenování atributů

Tento problém již souvisí s konkrétní verzí SQL a využitím konkrétních funkcí. Každopádně není vhodné, aby se libovolné dva atributy v různých tabulkách jmenovaly stejně. Pokud k tomu dojde, může se člověk dočkat velice podivného a záludného chování, například při využití přirozeného spojení (NATURAL JOIN). Spojuje se totiž vše, co jde - a pokud se více atributů ve spojovaných tabulkách jmenuje stejně, jsou zahrnuty do porovnání. Jedinou výjimkou (právě kvůli snadné realizovatelnosti přirozeného spojení) jsou cizí klíče, které odkazují na primární klíče jiných tabulek - tam se naopak shoda názvů hodí, ovšem pozor na výskyt stejně pojmenovaných cizích klíčů v různých tabulkách.

Opomíjení referenční integrity

Referenční integrita je výborná věc - zabrání nežádoucím změnám v datech, nebo naopak přenese nějakou změnu na další relace, takže databáze zůstane konzistentní. Bohužel, mnozí návrháři databází referenční integritu zcela opomíjejí, a to i přesto, že pracují s databází, ve které je k dispozici. Např. složitější rušení záznamů pak musejí realizovat celou řadou operací, čímž hrozí riziko zanesení chyby - i když by třeba stačilo provést jeden DELETE a zbytek by proběhl kaskádovitě sám.

Opomíjení indexů

Podobný případ jako ten předchozí. Kdo zná základy programovacích technik, jistě ví, že vyhledávat v datech lze i podstatně rychleji než jejich sekvenčním průchodem. Jenže někteří vývojáři to zjevně nevědí nebo to ani nechtějí vědět. Jinak by totiž u atributů, podle kterých se často hledají data, vytvářeli indexy. Je-li v databázi milion záznamů, najít ten jediný znamená projít průměrně půl milionu z nich. Když se ale vytvoří index (implementovaný typicky stromem), zjednodušeně to znamená projít - podle konkrétní podoby stromu - pouhé desítky uzlů. Ten několikařádový rozdíl je pak patrný hlavně při větší zátěži - databáze bez indexu kolabuje.

Uvedené chyby jsou samozřejmě jen některé z mnoha. Uvedl jsem je proto, aby si na ně všichni dávali pozor a přispělo to ke kvalitě navrhovaných databází.

       

Komentáře

[VícNežNic]

Hm, proč a pro koho takové články?

[Käyttäjä 11133]

Jaký smysl má ta patička, něco mi snad uniklo?

[VícNežNic]

No, tobě by to uniknout nemělo. Ale asi se David nepochlubil

(jinak každou zmínkou riskuju život, tak si toho važte)

[David Watzke]

Riskuješ :-P, ale to sem nepatří...

[Käyttäjä 11133]

Aha, už vím :)

[Kníže Ignor]

VícNežNic totiž umí řešit jenom dobře zadané úlohy. A ještě se tím chlubí!

[VícNežNic]

Já umím řešit všechno. Jenom se nesmí klást přehnaný důraz na správnost výsledku.

[Käyttäjä 11133]

Jasně, prázdná množina řešení je taky řešení.

[VícNežNic]

Ona nemusí být ta množina řešení vždy prázdná. Prázdný může být třeba průnik množiny mých řešení a správných řešení. Ale to jsou maličkosti, to se stává.

[Käyttäjä 11133]

Tak to je to s ním špatné.

[Luk]

No, pravda je, že ti co by to potřebovali, si to stejně nepřečtou

[Dalibor Smolík]

Opakování je matka moudrosti. Šel jsem do sebe a upravil si nedostatek v procesu rušení faktur.(jo, ty kaskády ... )

[Pavel 'lingeek' Szalbot]

Nahradil bych článek linkem - základy databází. A vytahal spoustu lidí za uši...

[Luk]

Musel jsem to napsat, protože jsem si nedávno přečetl tohle (část druhá - "Kalvárie údržby kódu") a opravdu mi to nedalo

[Lukáš Zapletal]

NJN s0 blog rules Pškný příspěvek, opakování matka moudrosti.

[springer]

...Pak stačí, aby si nějaký bláznivý manažer vymyslel, že přečísluje oddělení, a je o zábavu postaráno ...

to jsou ty typicke priklady, ktere se vykladaji studentum ve skolach a na ruznych kurzech. Nemaji s praxi vubec nic spolecneho. Bohuzel jsou ucitele na skolach (i tech vysokych) vetsinou lide, kteri jeste nikdy nemuseli nejaky projekt obhajovat v praxi.

Ono to je totiz tak, ze kdyz si nekdo rozmysli neco precislovat, co je zafixovano na stovkach formularu, telefonich seznamech, prospektech a pod. tak ta prace se zmenou techto dat je 100 x vetsi, nez ten jeden batch, ktery v noci ty udaje v databazi zprehazi.

Pamatuj: cislo dodavatele jako primarni klic neni chybou!

[Luk]

...Pak stačí, aby si nějaký bláznivý manažer vymyslel, že přečísluje oddělení, a je o zábavu postaráno ...

to jsou ty typicke priklady, ktere se vykladaji studentum ve skolach a na ruznych kurzech. Nemaji s praxi vubec nic spolecneho.

Tenhle příklad jsem uvedl právě proto, že jsem ho v praxi skutečně zažil (naštěstí ne s databází, která by byla takto špatně navržena).

Ono to je totiz tak, ze kdyz si nekdo rozmysli neco precislovat, co je zafixovano na stovkach formularu, telefonich seznamech, prospektech a pod. tak ta prace se zmenou techto dat je 100 x vetsi, nez ten jeden batch, ktery v noci ty udaje v databazi zprehazi.

Zrovna to číslo oddělení je v podstatě interní záležitost, která nemusí nikde příliš figurovat (např. pouze na vnitrofiremních účetních dokladech).

Pamatuj: cislo dodavatele jako primarni klic neni chybou!

Nemusí být, ale obecně je lepší vyhnout se použití atributu, který přímo nese nějakou eventuálně měnitelnou informaci.

[happy barney]

Pamatuj: cislo dodavatele jako primarni klic neni chybou!

Nemusí být, ale obecně je lepší vyhnout se použití atributu, který přímo nese nějakou eventuálně měnitelnou informaci.

suhlas, kazda tabulka by podla mna mala mat int4/int8 stlpec id, idealne auto-increment idealne unikatny v celej db

ad cislo dodavatela, niekto ich ma integer (123), iny si napr k cislu priklada info o roku (123/2004), dalsi stat (SK-123), atd, atd. Jeden dodavatel moze mat v roznych casovych obdobiach rozne cisla. To, ze si autor sw nevie predstavit inu situaciu, to nie je chyba nasadenia

[Kyosuke]

„idealne unikatny v celej db“

Proč mi to smrdí objekty?

[happy barney]

nemusi smrdiet ... je to len obrana voci odpozorovanym castym chybam, ked niekto nevie pisat joiny. Taka primitivna kontrola datoveho typu aj v selectoch.

[zde]

Jde o velmi častou praxi ve větších systémech.. umělé klíče různých tabulek běží od různých počátečních hodnot, s "dostatečnými" rozestupy, takže stačí vidět první cifru a hned je jasné do které tabulky to ukazuje.. a ano, smrdí to objekty, a je to dobře :)

[Ladislav Thon]

Přirozené spojení, to taky nějaká databáze umí? V MySQL je klauzule using, která to řeší IMHO hezkým jednoduchým způsobem, ale o implementaci opravdového přirozeného spojení jsem ještě neslyšel.

[Luk]

Co třeba:

CREATE TABLE T1 (t1_id INT, t1_txt VARCHAR(100),
PRIMARY KEY (t1_id));

CREATE TABLE T2 (t2_id INT, t2_txt VARCHAR(100), t1_id INT,
PRIMARY KEY (t2_id));

...

SELECT t1_txt,t2_txt FROM T1 NATURAL JOIN T2;

[Ladislav Thon]

No jo, ono to tam fakt je, už mlčím (ale používat mne to nikdo nedonutí :) ).

[Pavel Kysilka]

mazaci dodaji:

- pouzivat pohledy a obcas hromadne ozkouset, zda jeste funguji...

- nedelat pravopisne chyby v nazvech tabulek a sloupcu. pak by clovek pri implementaci a s omezenymi pravy a s rozkopirovanim v kodu zabijel....

- selecty a klidne i dalsi provadet podle potreby do xml nebo do neceho strukturovaneho.

- mrknout se na to, ze existuji i objektove database nebo objektova struktura na relacni databasi

- pouzivat database, kde neni problem dostat zpet data z dumpu

- pouzivat database s prijatelnym vyvojovym prostredim

- database neni vhodna na ukladani videa a __ne vzdycky__ na ukladani souboru.

- vytvaret tabulky stylem forum0, forum1, forum2 a doplnte neni to prave

- pres sql se daji vyborne generovat skripty

- mazak kvuli zjisteni casu neprejde z databasove konsole jinam nebo se nediva na hodinky, ale napise select now() ci jiny prikaz na zjisteni casu.

- pouzivat ty transkace....

- mysql neni zrovna vhodna na vetsi ucetnictvi..... flamesisti si to pokusi nejdrive napsat.

- je dobre si zkontrolovat, ze do database jde to prave kodovani. sice se s tim pocita automaticky, ale webmasteri jaksi ne...

- podivat se treba na to, jak ty database pracuji a na princip jejich fungovani.

- selectuj jen co potrebujes. ta hvezdicka sice setri praci, ale brutalne obcas zpomaluje. dokonce jsou database, ktere neumi poradne limit a offset - ta s tou divnou baterkou na rootu.

- je dobre podtaktovat cpu pri zkouseni sveho vytvoru.

a je toho mraky co se clovek naucil nebo ho to kolega lstiburek dost dobre naucil.

bye gf

[Luk]

- mysql neni zrovna vhodna na vetsi ucetnictvi..... flamesisti si to pokusi nejdrive napsat

...není vhodná na větší cokoliv (i když verze 5 už je o něco lepší). Čtyřka neumí pohledy a triggery, složitější dotazy jsou pomalé (i v pětce) a má některé další neduhy.

- je dobre si zkontrolovat, ze do database jde to prave kodovani. sice se s tim pocita automaticky, ale webmasteri jaksi ne...

Ať žije čaj

Od doby, co univerzálně používám UTF-8, už mě takové přízemní problémy netrápí

[wake]

CREATE FUNCTION tuid() RETURNS TRIGGER AS $$
DECLARE
 i RECORD;
 q text;
BEGIN
 q:='';
 FOR i IN SELECT id, condition FROM t LOOP
  if( q='' ) THEN
   q:='SELECT * FROM vtx'||i.id||' ';
  ELSE
   q:='UNION SELECT * FROM vtx'||i.id||' ';
  END IF;
  EXECUTE
   'CREATE OR REPLACE VIEW vtx'||i.id|| AS '||
   'SELECT '||i.id||' AS id_t, x.id AS id_x '||
   'FROM x WHERE '||i.condition||' ';
 END LOOP;
 EXECUTE 'CREATE OR REPLACE VIEW vtx AS '||q;
 IF (TG_OP = 'DELETE') THEN
  return old;
 ELSE
  return new;
 END IF;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER tuid AFTER INSERT OR UPDATE OR DELETE ON v
 FOR EACH STATEMENT EXECUTE PROCEDURE tuid();

[Lukáš Zapletal]

existuji databaze (pravda, ne relacni), ktere jsou vhodne (doslova urceny) na ukladani multimedii.

[happy barney]

zakladnou chybou pri navrhu databaz je nepouzivanie nastrojov, ktore to urobia z modelu (povedzme z moderneho UML), rovno aj s pristupovymi kniznicami pre pouzivany jazyk. Niekolko XSLT sablon a problem nenastane

[Luk]

Tyto nástroje jsou velice cenné, ale nejsou samospasitelné. Vždycky to musí člověk zkontrolovat a případně upravit.

[happy barney]

ano, ale na to staci jeden (dvaja) ludia, a odbura sa tym mnozstvo chyb celeho tymu Dalsou vyhodou je to, ze tie nastroje sa nestaraju o prog. jazyk ci db ... sablonu clovek napise raz a pouziva vo vsetkych dalsich projektoch. Tej prace co to usetri ... a btw, (x)emacs je lepsi

[zde]

Jsem jedinej komu přijdou normální formy jako akademickej bulšit odtrženej od reality? Si pamatuju jak nás třeba učili strkat duplicitní atributy do další tabulky, a vůbec jim nevadilo že umělý klíč této tabulky není o mnoho kratší než sám atribut, takže výsledek je nejen složitější, ale i paměťově náročnější.

[Jiří Veselský]

Šedivá je teorie, věčně zelený je strom života...

Máte pravdu, normální formy jsou akademická sračka a najdete spoustu praktických situací, kdy je lepší tyto akademické šablony porušit. NICMÉNĚ, považuju za docela nezbytné je znát a uvažovat v jejich intencích - a podle potřeby je promyšleně porušit kvůli efektivitě.

Problém je bohužel v tom, že hromada lidí tudle teorii vůbec nezná a porušuje ji nikoliv se zacílením na výkon, alébrž v důsledku nedostatečného pochopení celé problematiky. A pak vznikají zoufale neoptimalizované produkční systémy.

Ony totiž i ty akademické sračky mají něco do sebe... Pokud opravdu VÍTE co děláte, tak teoreticky optimální návrh změníte. Tragédie (a bohužel mnohočetná) je v tom, že spousta praktiků ani netuší, jak by ten teoreticky optimální návrh mohl vypadat... A pak vznikají děsné zrůdnosti...

[Luk]

To je přesné

[Michal Kubeček]

To je přesně ono. Ke skoro každému pravidlu existují situace, kdy je žádoucí ho porušit. Ale ten, kdo ho poruší by měl to pravidlo dobře znát, vědět, čím je motivováno a být schopen poznat, kdy nastane ona mimořádná situace. Pokud někdo pravidla porušuje proto, že je nezná, nebo proto, že ze zásady nechce dodržovat "nějakej akademickej bulšit", výsledkem je obvykle katastrofa…

[zde]

..a podle potřeby je promyšleně porušit kvůli efektivitě.

což mi připomíná ,,don't forget that Linux became only possible because 20 years of academic OS research was carefully studied, analyzed, discussed and finally thrown away''

[Jiří Veselský]

Tak toto jsem neznal

[zde]

Jde o 7 let starý a drobet nepřesný citát Ingo Molnara..

http://www.cs.helsinki.fi/linux/linux-kernel/Year-1999/1999-22/1302.html

[Karel Benák]

No nevim jestli jsou normalni formy bullshit, ale co jsem cetl nekolik skript z FELu apod. instituci o tvorbe databazi, pak tam byla vylozene zminka o tzv. procesu denormalizace a ze nekdy je fackt vyhoda pouzit nizsi normalni formu.

Co se tyce mazani v databazi, pravidla ON DELETE CASCADE ON UPDATE CASCADE jsou skvela, ale nekdy se vazne hodi mit implicitni ON DELETE RESTRICT a promazavat to rucne nekolika na sebe navazujicimi prikazy.