Tipy pro lepší návrh databáze

Během let, kdy jsem pracoval jako datový modelář a databázový architekt, jsem si všiml, že existuje několik pravidel, která by se měla při modelování a vývoji dat dodržovat. Zde popisuji několik tipů v naději, že by vám mohly pomoci. Tipy jsem uvedl v pořadí, v jakém se vyskytují během životního cyklu projektu, spíše než podle důležitosti nebo podle toho, jak jsou běžné.

1. Plánujte dopředu

Neschopnost plánovat znamená selhání plánování.

Alan Lakein

Jeden problém, který jsem viděl, je, když k datovému modelování dochází současně s vývojem softwaru. Je to jako stavět základy před dokončením plánů. V minulosti se plánování zdálo samozřejmým krokem před zahájením vývoje. Vývojové týmy by nevytvářely databáze bez plánování, stejně jako by architekti nestavěli budovy bez plánů.

Při vývoji aplikací je zásadní porozumět povaze dat.

Plánování je často ignorováno, takže vývojáři mohou jednoduše „začít kódovat“. Projekt se spustí, a když se objeví problémy, v plánu není žádná mezera na jejich řešení. Vývojáři používají zkratky se záměrem je opravit později, ale to se stává zřídka, pokud vůbec.

Pečlivé plánování je způsob, jak zajistit, že skončíte se správnou databází, která nebude hacknuta dohromady. Pokud nevěnujete čas a úsilí předem řešením dat požadovaných procesy, zaplatíte za to později pomocí databáze, která musí být přepracována, nahrazena nebo vyřazena.

I když plánování není vždy provedeno, mnoho datových modelářů se stále řídí těmito pokyny. To neznamená, že můžeme předem předvídat každou potřebu návrhu, ale většina modelářů věří, že stojí za námahu porozumět datům a jejich použití. Nechtěli byste návrh pro zpracování transakcí, když je potřeba vytvořit analytické sestavy.

Časy se změnily; Více převládají agilní metodiky, takže databázové týmy musí přehodnotit svůj přístup k datovému modelování. V Agile se místo diagramů vztahů entit používá model domény z případů užití. Potřeba plánování se však nezmenšila. Musíme rozumět datům a tomu, co mají dělat. Obecně platí, že prvních několik sprintů se musí zaměřit na návrh dat.

Takže problém pro databázové modeláře není Agile, ale spíše jednotlivci, kteří nechápou povahu dat. Někteří vidí vývoj databáze stejně jako vývoj aplikací. Databázové modelování a vývoj softwaru jsou různé a vyžadují odpovídající zaměření.

Databáze je jádrem většiny softwarových aplikací. Musíte věnovat čas analýze požadavků a tomu, jak je datový model splní. Tím se snižuje šance, že vývoj ztratí směr a směr.

Vývojáři musí chápat důležitost dat a jejich přínos pro vývojový proces. Žijeme v informačním věku. Aplikace zobrazují data a manipulují s nimi. Jsou to informace obsažené v datech, které dávají aplikaci smysl.

Není možné předvídat každý požadavek ani každý problém, ale je důležité se na problémy připravit pečlivým plánováním.

2. Zdokumentujte svůj model

Při vytváření datového modelu se zdá být vše zřejmé. Předměty pojmenováváte tak, aby byl zřejmý jejich účel a každý pochopil význam pouhým přečtením názvu. To může být pravda, ale není to tak zřejmé, jak si možná myslíte. Při výběru názvů pro tabulky a sloupce si ujasněte, jaké bude použití každého objektu. Časem bude význam objektů bez dokumentace nejasný.

Použití konvence pojmenování je jedním krokem k efektivní dokumentaci. Když budete muset v budoucnu provést změny, oceníte jakoukoli existující dokumentaci. Krátký, jednoduchý dokument, který popisuje rozhodnutí, která jste učinili, a popisuje návrh, vám pomůže vysvětlit tehdejší volbu designu.

Chcete dostatek dokumentace, aby databázi mohl spravovat nový správce a ten pochopil význam, aniž by se k vám musel vracet pro vysvětlení. Pokud datový model a prostředí nejsou zdokumentovány, je obtížné je udržovat nebo měnit podle toho, jak se mění požadavky.

Dokumentace má do jisté míry málo společného s datovým modelováním. Dokumentace je o tom, jak sdělit design a učinit jej srozumitelným v budoucnu.

Dokumentace je často dodatečný nápad. Když jsou plány krátké, dokumentace se ignoruje. Přesto se jedná o technický dluh s vysokou cenou. Omezování během vývojového cyklu ponese v budoucnu náklady na změny databáze, identifikaci problémů, sledování chyb a na pochopení datového modelu a povahy dat.

Například datové modely často mají pole „ID“ jako primární klíč pro tabulku nebo část názvu klíče. Může se jednat o primární klíč, jako je TransactionID na Transaction stůl. Pokud některé tabulky používají jako součást názvu klíče „Number“, pak je dobré zdokumentovat proč. Možná ReferenceNumber se používá jako název primárního klíče ve zprávě, protože tak se odkaz nazývá v obchodní oblasti. Například ve finančních službách finanční zprávy obvykle obsahují referenční číslo.

Zdokumentujte definici tabulek, sloupců a vztahů, aby měli programátoři k informacím přístup. Dokumentace musí popisovat očekávání struktury databáze.

V nástroji Vertabelo mohu okamžitě zahrnout komentáře k jakékoli položce:tabulkám, sloupcům, odkazům, alternativním klíčům, což znamená, že dokumentace je uložena okamžitě s mým modelem, nikoli v nějakém zvláštním dokumentu, který by se měl udržovat samostatně.

Špatná nebo chybějící dokumentace je často způsobena krátkozrakým myšlením, ale neignorujte její důležitost. Toto je stále problém, který je třeba vyřešit.

3. Postupujte podle konvencí

Konvence pojmenování se při návrhu nemusí jevit jako důležité. Ve skutečnosti jména poskytují náhled na pochopení modelu. Jsou úvodem a měly by být logické.

Nejednotné pojmenování nemá smysl. Frustruje pouze vývojáře, kteří musí mít přístup k datům, správce databáze a modeláře, kteří musí v budoucnu provádět změny.

Když se pro některé umělé klíče používá „ID“, ale některé tabulky používají jinou konvenci pojmenování (jako je číslo), vývojáři, analytici a správci databází mohou ztrácet čas, aby pochopili výjimky. Slabé konvence pojmenování také vedou k chybám ve vývoji, protože pojmenování není konzistentní.

Ruku v ruce s dokumentací umožňuje použití konvence pojmenování v budoucnu, aby někdo porozuměl modelu. Nepřepínejte náhodně mezi pomocí „ID“ (jako CustomerID ) a „Number“ (AccountNumber ) jako klíče pro tabulky. Výjimky z konvencí dělejte pouze tehdy, jsou-li oprávněné. Zdokumentujte, co je výjimka a proč není konvence dodržována.

Totéž platí pro záhadná jména jako „XRT1“ – jde o rozšířené referenční tabulky? Tvůj odhad je stejně dobrý, jako můj. Doufám, že návrhář věděl, proč zvolil tak tajemné jméno, ale pochybuji, že další osoba, která přistoupí k databázi, dokáže uhodnout důvod.

Konvence pojmenování jsou věcí osobní volby. Ujistěte se, že rozhodnutí jsou konzistentní a zdokumentovaná.

Pokud se mi podařilo přesvědčit vás, abyste ve svém návrhu databáze použili konvenci pojmenování, přečtěte si můj další článek, který je celý věnovaný tomuto tématu.

4. Přemýšlejte pečlivě o klíčích

Klíče často vyvolávají kontroverzi:primární klíče, cizí klíče a umělé klíče. Tabulky potřebují primární klíč, který identifikuje každý řádek. Uměním je rozhodnout, které sloupce by měly být součástí primárního klíče a jaké hodnoty zahrnout.

Pro správnou normalizaci potřebuje každá tabulka identifikační klíč. Jedinečnost musí být zaručena. Přirozené klíče a primární klíče však nemusí být stejné. Ve skutečnosti nemusí být, pokud má tabulka přirozený klíč.

Někteří datoví modeláři preferují umělý klíč kvůli jedinečnosti. Přesto někteří modeláři preferují přirozený klíč k zajištění integrity dat.

Měli bychom tedy jako primární klíč použít přirozený klíč? Pokud je nutné změnit přirozený klíč, vyvstává jeden problém. Pokud se přirozený klíč skládá z mnoha sloupců, možná budete muset provést změny na mnoha místech. Další výzvou je použití umělého klíče jako jediného klíče pro stůl.

Jako příklad můžete mít tabulku s informacemi o produktech. Tabulka může být definována umělým klíčem, jako je sekvence, kód pro krátký abecední název produktu a definice produktu. Pokud je jedinečnost zajištěna pouze umělým klíčem, mohou existovat dva řádky se stejným kódem produktu. Jedná se o stejný produkt, který je zadán dvakrát? Možná je vhodnější klíč s kódem produktu.

5. Pečlivě používejte kontroly integrity

K zajištění integrity dat potřebujeme cizí klíče a omezení. Dávejte pozor, abyste tyto kontroly integrity nepoužívali nadměrně nebo nedostatečně.

Tabulky domén jsou účinné pro vynucení integrity. Tabulky domén fungují dobře, když existuje mnoho hodnot ke kontrole nebo se hodnoty, které mají být kontrolovány, často mění.

Jedním z problémů může být to, že se vývojáři rozhodnou, že aplikace bude kontrolovat integritu. Problém je v tom, že k centrální databázi může přistupovat mnoho aplikací. Obecně také chcete chránit data tam, kde jsou:v databázi.

Pokud jsou možné hodnoty omezené nebo v rozsahu, pak může být vhodnější kontrolní omezení. Řekněme, že zprávy jsou definovány jako příchozí nebo odchozí, v takovém případě není potřeba cizí klíč. Ale pro něco jako platné měny, i když se mohou zdát statické, ve skutečnosti se čas od času mění. Země vstupují do měnové unie a měny se mění.

Aplikace by také měly provádět kontroly integrity, ale nespoléhejte pouze na aplikaci při kontrole integrity. Definování pravidel integrity v databázi zajišťuje, že tato pravidla nebudou nikdy porušena. Tímto způsobem data vždy splňují definovaná pravidla integrity.

6. Nezapomeňte na indexy ve svém návrhu

Určitý návrh indexování je užitečný během modelování databáze, i když se indexy mohou během skutečného nasazení a používání změnit. Samozřejmě je možné mít příliš mnoho indexů, stejně jako je možné mít příliš málo.

Indexování je neustálý proces. Během návrhu zahájíte proces na svém modelu. Návrhářské práce se týkají primárních klíčů a omezení.

Indexy jsou důležité při zvažování dotazů na data. Při modelování byste měli zvážit, jak budou data dotazována. Dejte pozor, abyste nepřeindexovali. Indexování se točí kolem optimalizace dotazů.

7. Vyhněte se běžným vyhledávacím tabulkám

Často jsem viděl běžnou vyhledávací tabulku pro dvojice atributů. Definice jedné obecné tabulky domén je vnímána jako zjednodušení návrhu. Tento styl tabulky domén vytváří abstraktní definici pro uchovávání textu. Slyšel jsem, že se tomu říká tabulka „Povolená hodnota“ nebo „Platné hodnoty“, ale výraz „MUCK“ byl pro tento anti-vzor vytvořen v roce 2006:Masivně sjednocený kódový klíč.

Tabulky MUCK obsahují nesouvisející data.

Můžete mít například tabulku, která definuje doménu, položku a popis. Když se vrátíme k výše uvedenému příkladu zprávy, dvě položky mohou být:

Nyní přidejte položky pro jinou doménu:

Tohle je prostě nepořádek. Co znamená tabulka?

Jen pro zábavu jsem vymodeloval jednoduchý příklad tabulky MUCK (nebo OTLT, „One True Lookup Table“, pokud jste fanouškem Tolkiena) a přidal několik komentářů. Upozorňujeme, že se jedná o anti-vzor a nedoporučuji jej používat ve svém datovém modelu.

U tabulek MUCK nelze definovat omezení. MUCK se může stát mnoha řádky bez jakéhokoli významu. Když se musíte dotazovat na jinou tabulku, abyste pochopili význam pole, není to ideální.

Tyto tabulky „všechno jde“ činí kontroly integrity složitými nebo dokonce nemožnými. Jedním z důvodů, proč mohou být tyto tabulky vytvořeny, je skutečnost, že několik tabulek v databázi má podobnou definici. Pak se kontroly integrity dat stanou nemožnými. Také jejich velikost může být poměrně velká.

Normalizace by měla vést pryč od tabulek MUCK. Jedna tabulka by měla představovat jednu doménu; spíše než jedna tabulka (MUCK) představující všechny domény. Bez tabulek MUCK můžeme zavést omezení cizích klíčů.

Používejte samostatné tabulky pro doménové objekty místo toho, abyste je nacpali do jediné tabulky. To umožňuje správné typy sloupců, omezení a vztahy. Tabulka „Povolené hodnoty“ je jen blábol a nemá místo v datovém modelu.

8. Definujte strategii archivace

Až příliš často jsem viděl databáze vytvořené bez správné strategie uchovávání a archivace dat. Jak dlouho budou data udržována online dostupná v aktivních databázových tabulkách? Většina systémů je postavena tak, aby uchovávala data v databázi „navždy“. Pro většinu systémů to není rozumná dlouhodobá strategie uchovávání dat. V určitém okamžiku by měla být aktivní data archivována.

Jeden přístup, který zastávám, je zahrnout uchovávání dat jako součást vašich návrhových úvah. Budete mít aktivní a historické tabulky, aby vkládání nových řádků do aktivních tabulek zůstalo rychlé a zároveň bylo možné optimalizovat vyhledávání historických dat?

Vyhnete se tak nutnosti předělávat archivaci do vaší databáze nad rámec původního návrhu.

9. Testujte včas, testujte často

Abychom parafrázovali Al Caponeho (nebo Johna Van Burena, syna 8. prezidenta USA), „testujte brzy, testujte často“. Tímto způsobem následujete cestu kontinuální integrace. Testování v rané fázi vývoje šetří čas a peníze.

Testování je vždy výzvou v plánu rozvoje. Na konci Agile Sprintu je často testovací fáze a na konci vývoje testování systému. Testování je obecně první věc, kterou je třeba zmáčknout, když se krátí čas.

Při testování databáze by cílem mělo být simulovat produkční prostředí:„Den v životě databáze“. Jaké objemy lze očekávat? Jaké interakce uživatelů jsou pravděpodobné? Řeší se hraniční případy?

Takže plán testování a správné testování musí být nedílnou součástí datového modelování a vývoje databáze.

Závěr

Toto jsou hlavní problémy, které jsem zaznamenal při práci s datovými modeláři a revizi datových modelů. Když budete těmto tipům věnovat pozornost, bude vaše databáze lépe navržena a bude robustnější. Návratnost některých z těchto investic však není vždy zřejmá nebo viditelná. Plánujte, dokumentujte, používejte standardy, vytvářejte klíče, zajistěte integritu, provádějte indexování, vyhněte se MUCK, vyvíjejte strategie a TESTUJTE!

Žádná z těchto činností nezabere enormní množství času, ale nebude mít obrovský dopad na kvalitu vašeho datového modelu.

Jaký je váš názor na tyto tipy?

Máte vlastní tipy?