7 smrtelných hříchů návrhu databáze

Jak se vyvarovat nejhorších problémů při návrhu databáze

Jason Tiret

Existuje řada faktorů, které mohou vést ke špatně navržené databázi - příčinou může být třeba nedostatek zkušeností a dovedností, napjatý harmonogram či nedostatečné zdroje. Naopak návrh databáze "spíchnutý horkou jehlou" sebou přináší mnoho problémů jako je například snížený výkon, obtížné přizpůsobování vznikajícím požadavkům na databázi či nízká kvalita dat, které zvyšují finanční i časové náklady na vývoj aplikací.

Neustále slyším od profesionálů, že pokud jim nedáte správné podklady, nelze nic jiného očekávat.  Ale je to častokrát ocas (to jest aplikace), který vrtí psem, místo toho aby pes vrtěl ocasem. Je to právě databáze, která řídí, jakým způsobem aplikace porostou co do rozsahu a funkčnosti.

Dodržováním několika jednoduchých zásad pro datové modelování lze významně omezit většinu, ne- li všechna výše uvedená rizika. V tomto článku se soustředím na sedm nejčastějších „hříchů" databázového návrhu, kterým se lze snadno vyhnout, a navrhnu kroky k jejich odstranění v budoucích projektech:

1. Nedostatečná, nebo zcela chybějící dokumentace pro produkční databáze
2. Nízká nebo žádná normalizace
3. Ignorování faktu, že datový model je živým organismem
4. Nevhodné uložení referenčních dat
5. Absence cizích klíčů, kontrol a omezení
6. Absence domén a jmenných konvencí
7. Chybná volba primárních klíčů

Hřích číslo 1: Nedostatečná, nebo zcela chybějící dokumentace pro produkční databáze

Nedostatky v dokumentaci databáze lze obvykle zařadit do jedné ze tří kategorií: dokumentace je neúplná, nepřesná, nebo zcela chybí.  Aby toho nebylo málo, prakticky nikdy není dostupná v ucelené podobě na jednom místě.  Bez řádné, centralizované dokumentace je porozumění dopadům změn v lepším případě komplikované, v tom horším nemožné. Vývojáři, správci, architekti a analytici tak často vynalézají každý zvlášť stejné kolo. Je totiž ponecháno jen na jejich představivosti, jak budou interpretovat význam nebo použití datových prvků.

Vývojáři pak předpokládají, že jména tabulek a sloupců jsou dostatečně popisná a plně vypovídají jak nakládat s obsaženými daty (podrobněji viz hřích 6). Bohužel, jak se střídají zaměstnanci, může se snadno stát, že pokud není udržována řádná dokumentace, znalosti o systému doslovně odejdou otevřenými dveřmi. Za sebou zanechají propast, kterou je prakticky nemožné překlenout. Významného zmírnění projevů nedostatečné dokumentace lze dosáhnout postupem fyzického návrhu zdola nahoru.

Nejvhodnějším přístupem je uložení modelu do společného úložiště a následná tvorba automatizovaných výstupů. Přes poměrně malé úsilí to přináší všeobecný užitek. Vybudování centrálního skladiště modelů je ale jen poloviční vítězství. Ve chvíli, kdy je dokončeno, je třeba vytvořit soustavu měření a kontrol pro postupné zvyšování kvality uložených modelů. Se zvyšující se mírou řízení lze zároveň rozšiřovat i rozsah metadat, která budou v rámci modelů uchovávána.

Hřích číslo 2: Nízká nebo žádná normalizace

Jsou okamžiky, kdy se struktury databáze denormalizují pro dosažení optimálního výkonu, je to ale vždy na úkor pružnosti. Navzdor odvěkému přesvědčení vývojářů není použití jediné tabulky pro ukládání všeho vždy tím nejlepším řešením. Metoda „jedné tabulky" může zjednodušit přístup k datům, ale pravidelně se zde bude objevovat mnoho prázdných či nedefinovaných hodnot ve sloupcích, které jsou pro daný záznam nepoužitelné. Toto je následně nezbytné ošetřit v kódu aplikace. Dalším častým omylem je ukládání opakujících se hodnot. Opět tím klesá pružnost a komplikuje se aktualizace záznamů.

Aplikace alespoň základní úrovně normalizace zvýší pružnost návrhu a redukuje nadbytečná data. Ve většině případů je dostačující použití prvních třech úrovní normalizace:

• První normální forma: Odstranění duplicitních sloupců a opakujících se hodnot ve sloupcích
• Druhá normální forma: Odstranění dat, používaných ve více sloupcích
• Třetí normální forma: Každý sloupec tabulky by měl být závislý na primárním klíči

Stejná struktura po uplatnění normalizace:

První normální forma nám říká, abychom rozdělili Adresu a Telefon do samostatných tabulek s jednoznačným identifikátorem. V souladu s druhou normální formou vyčleníme samostatnou tabulku pro směrovací číslo, aby se předešlo jeho opakování pro každou adresu. Je možné se rovněž zamyslet nad osamostatněním tabulek pro město a stát, v tomto případě však pravděpodobně zvítězí výkonnostní pohled. Třetí normální forma nás přivádí k názvu organizace a odvětví v tabulce zákazník. Oběma údajům by bylo podobně jako u Města a Státu možné přidělit samostatnou tabulku, pokud zde neexistuje jednoznačná vazba na zákazníka.

Hřích číslo 3: Ignorování faktu, že datový model je živým organismem

Viděl jsem nespočetně příkladů zákazníků, kteří poctivě používali modelování pro návrh, avšak jen do doby, kdy byl systém předán do produkce. Je vždy výhodnější nejdříve plánovat a poté stavět. Je ověřeno, že odstranění chyby ve fázi návrhu je výrazně méně nákladné než oprava v provozu.

Hřích vyvstává, když ke změnám v databázi dochází plíživě, vinou kritických provozních problémů. Model nevyhnutelně chátrá, pokud neexistuje proces, zajišťující, že bude aktualizován spolu s databází. Čím více změn se v databázi odehrává, tím se model stává bezcennějším.

Nedokumentovaná data mohou být rovněž zdrojem bezpečnostních rizik či nesouladu s různými normami či nařízeními.  Snižují také schopnost porozumět přicházejícím změnám a přizpůsobit se budoucím obchodním potřebám.  Jakkoli může být přístup „nejdříve návrh, pak realizace" vnímán jako utopie, které nebude nikdy dosaženo, změny si cestu zpět do modelu prostě najít musí.

Hřích číslo 4: Nevhodné uložení referenčních dat

V oblasti referenčních dat vidím především dva zásadní problémy. Jsou buď uložena na řadě míst, nebo jsou v horším případě přímo v kódu aplikace. Téměř nikdy to není zachyceno v datovém modelu či jinak zdokumentováno. To způsobuje obrovské problémy, když vyvstane potřeba tato data změnit. Referenční hodnoty poskytují hodnotné informace, které je třeba komunikovat. Nejvhodnější způsobem je prostřednictvím modelu. Nemusí být praktické uložit referenční data do modelu, pokud se jedná o velké objemy, neomluvitelné ovšem je, nejsou-li modelem ani odkazována. Klíčové je mít na jediném místě popsána a následně je na dalších místech používat.

Hřích číslo 5: Absence cizích klíčů, kontrol a omezení

Neustále slýchám od zákazníků stížnosti na nedostatečně definovanou referenční integritu (RI) a kontroly v databázi, když provádějí její zpětné inženýrství. U starších databázových systémů se předpokládalo, že referenční integrita zpomaluje práci databáze, a že RI spolu s dalšími kontrolami mají být prováděny aplikacemi. Dříve to mohlo platit, ale databázové stroje od té doby urazily dlouhou cestu.

Dopady na kvalitu dat, pokud nejsou databází důsledně ověřena, mohou být velmi rozsáhlé. Pokud lze validovat data na straně databáze, je to nejlepší volba. Dramaticky se tím zjednoduší ošetření chyb a následně zvýší i kvalita dat.

Hřích číslo 6: Absence domén a jmenných konvencí

Použití domén a jmenných konvencí jsou možná dvě z nejdůležitějších myšlenek, o které můžete rozšířit své modelovací postupy. Domény umožňují definovat opakovaně použitelné atributy, takže se při jejich opětovném použití na různých místech nebudou jejich vlastnosti lišit. Je velmi důležité mít sadu základních prvků, které může používat každý napříč všemi modely. Jmenné konvence umožňují takové prvky jednoznačně identifikovat.

Mít definované standardy také zaručuje konzistenci napříč systémem a zvyšuje čitelnost modelu i kódu. Nechcete krátká, šifrovaná jména, která bude uživatelům třeba jedno po druhém vysvětlovat. Díky rozšířením v nových verzích můžeme při budování nových databází zapomenout na dny, kdy mohla mít jména sloupců jen omezenou délku. Vždy mějte sadu jmenných tříd pro označení klíčových typů dat a pro jejich další rozlišení použijte popisné modifikátory.

Hřích číslo 7: Chybná volba primárních klíčů

Jednou mi řekl jeden starší datový architekt: „Když vybíráš primární klíč, buď raději hodně opatrný, protože každá pozdější změna bude po čertech bolestivá."  Později jsem pracoval pro zákazníka, který měl nezáviděníhodné starosti s řízením množství migračních projektů, protože jeho systém používal jako primární klíč osoby číslo sociálního pojištění (obdobu našeho rodného čísla). Na obtíže narazil ve chvíli, když zjistil, že číslo sociálního pojištění není vždy unikátní a ne každý je má.

Nejjednodušším způsobem, jak si zapamatovat zásady pro volbu primárního klíče je SUM: statický (neměnný), unikátní a minimální. Není třeba zabředat do diskuzí, zda dát přednost přirozenému či uměle vytvořenému klíči, byť je důležité vědět, že ačkoli umělý klíč jednoznačně identifikuje záznam, nemusí jednoznačně identifikovat hodnotu. Místo je zde pro obě varianty a vždy můžete vytvořit alternativní klíč pro přirozené klíče, pokud je umělý klíč používán jako primární.

Jason Tiret je ředitelem produktového oddělení nástrojů pro modelování a návrh společnosti Embarcadero.