Jaké jsou kroky v návrhu databáze?

Návrh databáze je jedním z nejdůležitějších faktorů, které přispívají k výkonu aplikace. V důsledku toho je nanejvýš důležité, jak dobře je databáze navržena. Návrh databáze je o efektivní organizaci dat na základě pracovních postupů produktu, budoucího plánu a očekávaných vzorců používání.

Výstupem cvičení návrhu databáze je datový model. Datový model představuje všechny objekty, entity, atributy, vztahy a omezení v systému. Obecně řečeno, datové modely mohou být dvou typů:logické nebo fyzické . Reprezentace datového modelu se provádí vytvořením ER diagramu, známého také jako diagram vztahu entit, ERD diagram nebo databázový diagram.

Fyzický datový model se vztahuje ke skutečným detailům implementace v databázi. Logický datový model na druhé straně abstrahuje technické detaily implementace. Díky tomu je logický datový model pro firmu použitelný. Jedním z klíčových rozdílů mezi těmito dvěma modely je to, že logický model je databázový agnostický, zatímco fyzický model musí být specifický pro používanou databázi.

Správný návrh databáze je často při vývoji aplikací podceňován a zanedbáván. Náklady na toto zanedbání se obvykle projeví mnohem později, když přijdou nové funkce aplikace nebo když staré funkce vyžadují změnu. To je, když návrh databáze přestává dávat smysl. I když není možné zajistit budoucí návrh databáze, je velmi možné vyvinout úsilí k tomu, abychom co nejlépe porozuměli případům obchodního použití a podle toho navrhli databázi. Přečtěte si více o tipech pro lepší návrh databáze zde.

S ohledem na to si projdeme kroky v návrhu databáze.

Krok 1:Shromážděte obchodní požadavky

Prvním krokem je promluvit si s firmou o jejich požadavcích. Pokud je konverzace efektivní, měla by vyústit v dostatek informací k zahájení práce na konceptuálním datovém modelu, který je abstrakcí logického modelu. Rozhovor s obchodem v první řadě poskytuje úplný obraz o podnikových procesech, který zase poskytuje informace o různých datových bodech, které je pro podnik důležité zachytit a sledovat. Například v modelu rezervace taxíků stojí za to položit si následující otázky:

• Potřebuje firma údaje o sledování vozidel v databázi bez ohledu na to, zda se jedná o aktivní cestu, nebo ne? Pokud ano, pak pole vehicle_trip_id v tabulce vehicle_trips bude možnost nulování . V opačném případě nebude možné nulovat .
• Chce firma historii změn trip_status? uloženy v databázi? Pokud ano, pak pokaždé trip_status změny, bude další záznam v trips stůl. Jinak pokaždé, když trip_status změny, trip_status bude aktualizován na místě.

Jak je ukázáno v tomto příkladu, na základě vstupů z podnikání byste nakonec zvolili jednu možnost před druhou. To by vedlo ke změně dotčených subjektů a jejich vztahů.

Shromažďování požadavků také obecně zahrnuje zahájení konverzace o zabezpečení dat, například o tom, která data mají být maskována a šifrována. Výsledkem shromažďování požadavků je dokument požadavků často podporovaný pracovním návrhem koncepčního datového modelu.

Krok 2:Pochopte obchodní plán

Podniky neustále mění své procesy; jejich schopnost přizpůsobit se snižuje pravděpodobnost selhání. Změna obchodních procesů znamená změnu pracovních postupů a datových modelů. Ačkoli není možné znát tyto změny s velkým předstihem, je jistě možné mít aktuální obchodní plán.

Pokud má například společnost v plánu zacílit na novou geografickou oblast, model by musel zohledňovat jazykovou podporu, měny, časová pásma a tak dále. Výhody porozumění dlouhodobé obchodní mapě se často projeví v hladším přechodu na nové obchodní procesy.

Dovolte mi podělit se ještě o jeden příklad, který se týká spíše neustále se vyvíjejících obchodních priorit. Na začátku COVID-19 byl byznys s taxislužbou negativně ovlivněn. Jako taxikáři chcete preventivně ujistit lidi, že děláte vše pro to, aby vaše cestování v kabině bylo co nejbezpečnější, aby bylo vozidlo každý den dezinfikováno, aby řidič vůbec nosil masku. časy a že je v kabině k dispozici dezinfekce na ruce. Pro zachycení všech těchto informací se nyní změní na dvě entity, drivers a vehicles , bude vyžadováno. Několik logických polí příznaků je třeba přidat k těmto entitám, aby bylo možné vyhovět tomuto případu obchodního použití.

Krok 3:Identifikujte entity a atributy

Jakmile jsou obchodní požadavky shromážděny, lze informace použít k identifikaci entit spolu se základní sadou atributů. Jedna nebo více entit se obecně mapuje přímo na obchodní procesy a vztah mezi těmito entitami také napodobuje pracovní postup obchodních procesů.

Tento krok se také používá k identifikaci, které atributy budou v entitách fungovat jako identifikátory. Identifikátory se převádějí na primární klíče ve fyzickém modelu. Kromě toho je v tomto kroku také běžné specifikovat datové typy pro všechny atributy.

Například v modelu rezervace taxíků byste museli identifikovat atributy, které budou fungovat jako povinná pole pro registraci uživatelů a řidičů z rezervační aplikace. Registrace uživatele by byla provedena pomocí user_phone a registrace ovladače by byla provedena pomocí driver_phone .

Podobně jsou během tohoto kroku identifikovány další entity a atributy poté, co byly namapovány na pracovní toky obchodních procesů.

Krok 4:Identifikujte vztahy

Po identifikaci entit a jejich atributů je dalším krokem definování vztahů mezi entitami na základě obchodních pracovních postupů, které byly zdokumentovány ve fázi shromažďování požadavků. Kromě zjištění, že mezi dvěma entitami existuje vztah, je také důležité určit, který z následujících čtyř typů vztahu mezi nimi existuje. Zvažte dvě libovolné entity, A a B:

1. Jedna ku jedné → Jeden záznam v A odpovídá nejvýše jednomu záznamu v B.
2. One-to-many → Jeden záznam v A odpovídá mnoha záznamům v B.
3. Mnoho ku jedné → Mnoho záznamů v A odpovídá nejvýše jednomu záznamu v B.
4. Many-to-many → Mnoho záznamů v A odpovídá mnoha záznamům v B.

V modelu rezervace taxíků byl použit pouze jeden typ vztahu, tj. jeden k mnoha. Vezměte si vztah mezi users a trips jako příklad. V modelu je předpoklad, že k výletu může mít vztah pouze jeden uživatel, což znamená, že neexistují žádné sdílené nebo sdružené taxíky. Pokud by však existovaly sdílené nebo sdružené taxíky, mezi users a trips , pokud mnoho uživatelů sdílelo stejné trip_id .

Krok 5:Vytvořte logický diagram ER

S definovanými entitami, atributy a vztahy entit je bezprostředním dalším krokem nakreslení ER diagramu. Všechny výše uvedené kroky lze provést ve Vertabelo. Neexistují žádná pevná a rychlá pravidla pro způsob, jakým se má logické modelování provádět, snad s výjimkou referenčního zápisu.

Podívejte se například na následující příklad logického ER diagramu. Zachycuje jednoduchý obchodní pracovní postup taxislužby, kde si uživatel může rezervovat jízdu s možností sledovat vozidlo.

Krok 6:Ověřte logický diagram ER

Logické modelování je proces, ve kterém je potřeba převést mnoho obchodních informací do návrhu databáze. Bez důkladných kontrol je tato fáze vývoje databáze náchylná k chybám, které se v pozdější fázi mohou ukázat jako docela nákladné.

Aby se o to postarala společnost Vertabelo, má důkladný seznam kontrol, které lze provést na logickém modelu. Kontroly lze provádět na všech úrovních, od modelu jako celku po jednotlivé atributy a vše mezi tím. Některé z jednoduchých kontrol jsou:

• Názvy entit, atributů, vztahů atd. nemohou být prázdné a musí být jedinečné.
• Entita musí mít alespoň 1 atribut.
• Pro každou entitu musí být definovány identifikátory (PK).
• Model musí pro atributy používat jeden z uvedených datových typů.

Všechny tyto kontroly jsou volitelné a lze je nakonfigurovat tak, aby byly přeskočeny, pokud existuje jiný ověřovací rámec. Správné ověření od Vertabelo vám pomůže přejít k dalšímu kroku s minimálním možným třením.

Krok 7:Vytvořte fyzický diagram ER

Jakmile je vytvořen logický ER diagram, dalším krokem je vytvoření fyzického datového modelu. Fyzický datový model bude specifický pro databázi, do které chcete datový model nasadit. Všechny databáze mají svou jedinečnou implementaci pravidel nomenklatury, datových typů a omezení. Díky tomu se jazyk DDL (Data Definition Language) v jednotlivých databázích často liší.

Chcete-li vytvořit fyzický datový model, postupujte takto:

1. Najděte nejbližší datový typ v cílové databázi, který nahradí obecný datový typ vybraný v logickém datovém modelu.
2. Dodržujte pravidla nomenklatury pro tabulky, sloupce a omezení, jak je předepisuje cílová databáze.
3. Upravte model tak, aby byl v souladu s předdefinovanými pracovními postupy dotazů. To obecně vede ke zvýšení redundance při ukládání spojení.
4. Nakonec můžete vytvořit indexy, oddíly, distribuční klíče a klíče řazení. V tomto případě můžete vytvořit jakékoli úpravy modelu zvyšující výkon.

Tyto kroky lze provést pomocí jakéhokoli nástroje pro datové modelování, který můžete použít k vytvoření datového modelu od začátku. Vertabelo má však možnost převést logický datový model na plnohodnotný fyzický datový model pro všechny hlavní databázové systémy jako MySQL, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Redshift, Google BigQuery a další. Jakmile je logický datový model převeden na fyzický datový model, můžete pokračovat ve čtyřech krocích, které jsme probrali.

Vertabelo má také možnost přidat skripty před a po nasazení na úrovni tabulky spolu s jakýmikoli komentáři na velmi podrobné úrovni modelu. Komentáře se ukáží jako užitečné při použití funkce generování dokumentace, kterou nabízí Vertabelo. Databázový dokument lze exportovat v kterémkoli z následujících tří formátů:HTML, PDF nebo DOCX.

Pokračujeme v příkladu rezervace taxi a pojďme se podívat na fyzický datový model generovaný Vertabelo.

Krok 8:Ověřte fyzický diagram ER

Stejně jako byl ověřen logický ER diagram, Vertabelo má nástroj pro ověření fyzických ER diagramů s několika dalšími kontrolami, jako je, zda existují nebo neexistují FK a zda délka názvu tabulky nebo názvu sloupce překračuje limit založený na vybrané databázi.

Ověření není třeba spouštět explicitně. Stává se to při změně diagramu. Problémy s modelem spadají do jedné ze tří kategorií:chyby, varování a rady v pořadí podle klesající závažnosti. Existuje užitečný, dobře napsaný článek, který hovoří o běžných chybách, kterých se dopouštíte během procesu návrhu databáze.

Krok 9:Opravte problémy s fyzickým diagramem ER

Výsledky ověření mohou identifikovat problémy, které je třeba opravit. Některé z nejběžnějších problémů jsou:

• Chybějící cizí klíče tam, kde byly definovány vztahy entit.
• Chybí primární klíče v tabulkách.
• Nepodporované datové typy pro vybranou databázi.

Jakmile jsou tyto a další podobné problémy vyřešeny, model je připraven k exportu do implementovatelného skriptu SQL pro vybraný systém správy databází.

Krok 10:Vygenerujte skripty DDL pro nasazení modelu

Návrh databáze není jen o vytváření ER diagramů. Cvičení datového modelování pomocí ER diagramů je úspěšné pouze tehdy, má-li za následek něco použitelného. Vertabelo má pohodlnou možnost exportovat fyzický model do skriptu SQL připraveného k nasazení. Jakmile je vygenerován, mohou být jakékoli nevyřízené problémy vyřešeny přímo ve skriptu SQL.

Změna vygenerovaného skriptu SQL se však nedoporučuje. Způsobuje to drift mezi fyzickým datovým modelem a SQL skriptem nasazeným v databázi, což může také znamenat posun mezi skutečnými tabulkami a databázovou dokumentací.

Nyní, když jsme dosáhli konce procesu návrhu databáze, pojďme se podívat na kód SQL generovaný Vertabelo.

Podělte se o své myšlenky

Návrh databáze je činnost s velkým dopadem při vývoji softwaru. Oblast návrhu databází se v průběhu let vyvíjela s novými způsoby, jak reprezentovat návrh pro podnikání, pro inženýry a pro datové analytiky. To často vedlo k novým typům diagramů, standardům modelování a zápisům. Velká část evoluce byla pokryta v sekci Základy designu.

Rádi uvidíme, jaké máte zkušenosti s navrhováním databází. Napište nám na [email protected].