Cítíte se ohromeni množstvím času, který vám zabere naučit se být návrhářem databází? Přečtěte si o základních dovednostech a talentech, které budete potřebovat – není to tak hrozné!
Když procházíte uličkami supermarketu, v jedné ruce máte nákupní košík a ve druhé seznam potravin, na co myslíte? Pokud jste jako já, přemýšlíte, jak zlepšit organizaci regálů, aby vaše týdenní nákupy byly méně časově náročné. Nebo možná cítíte stejnou touhu organizovat a strukturovat informace, když vám přítel ukazuje svou velkou sbírku časopisů. Nebo možná zasáhne, když spravujete své seznamy skladeb tak, aby lépe vyhovovaly vašim preferencím. Pokud procházíte životem a přemýšlíte o tom, jak reprezentovat realitu z hlediska entit, atributů a vztahů, pak je vaším posláním být databázovým modelářem.
Možná nejste tak extrémní, ale stále vás přitahuje myšlenka věnovat se návrhu databáze jako kariéře. V každém případě budete muset zvládnout několik nových dovedností. Některé z nich jsou čistě technické; tyto dovednosti se můžete naučit studiem nebo čtením a prohloubit je prostřednictvím pracovních zkušeností. Další dovednosti zahrnují netechnické znalosti, které se můžete naučit prostřednictvím kurzů, článků na blogu nebo pozorováním ostatních.
Zde je souhrn základních znalostí a dovedností, které musí mít každý návrhář databází.
Hard Skills Database Designers Potřebují
Tvrdé dovednosti jsou ty, které se získávají studiem a zdokonalují praxí. Pokud dokážete konkrétními důkazy prokázat, že jste zvládli náročnou dovednost, znamená to, že jste schopni provést jakýkoli úkol, který ji zahrnuje.
Pokud jde o znalost databáze, tvrdé dovednosti zahrnují základy teorie databází a různé techniky používané k aplikaci teoretických konceptů k řešení konkrétních problémů. Podívejme se na každou z náročných dovedností, které návrháři databází potřebují.
Teorie databáze
Teorie databáze je plná abstraktních pojmů, kterým může být obtížné porozumět, pokud nejsou spojeny s reálnými fakty. Relační model, domény, atributy, vztahy a vztahy, primární a cizí klíče, integrita entity, referenční integrita a omezení domény jsou jen některé příklady. Pokud přidáte ještě složitější záležitosti (jako je vztahová algebra nebo vztahový kalkul), možná vás napadne, zda by nebylo lepší zvolit si kariéru zabývající se konkrétními věcmi, jako je zahradničení nebo gurmánské vaření.
Nepanikařte. Důkladná znalost teorie databází je důležitá, pokud plánujete vyučovat na vysoké škole nebo vymyslet nový způsob organizace informací. K navrhování databází však potřebujete pouze zvládnout teoretické koncepty, které se vztahují na řešení skutečných problémů. Nejdůležitější z nich – ABC návrhu databází – je relační model.
Relační model
Vysokoškolští profesoři vám řeknou, že relační model je mechanismus organizace dat založený na teorii množin a predikátové logice. To vám ale ve vaší každodenní práci databázového modeláře moc neprospěje. V praxi musíte vědět, že relační model je intuitivní a přímočarý způsob organizace dat ve formě tabulek – tzv. relace – které se skládají z řádků (kterým se také říká n-tice). Každá tabulka (nebo vztah) je definována svými atributy (nebo sloupci).
Základní koncepty relačního modelu.
Všechny vztahy by měly mít jeden nebo více nevyřízených atributů, které představují jedinečný identifikátor pro každou n-tici. V databázovém slangu je to klíč tabulky. Neklíčové atributy jsou závislé na klíči v tom smyslu, že každá hodnota klíče určuje jednu možnou hodnotu pro každý atribut.
Představte si tabulku informací o vozidle, ve které je klíčem SPZ. SPZ určuje atributy každého vozidla (jako je výrobce, model, vlastník atd.), protože pravidla domény zabraňují tomu, aby dvě různá vozidla sdílela stejnou SPZ.
Relační databáze
Systémy pro správu relačních databází (RDBMS) implementují relační model, respektujíc jeho principy. Nabízejí způsoby, jak získat informace prostřednictvím dotazů a aktualizovat informace prostřednictvím transakcí. Aby informace v relační databázi odrážely skutečná fakta a situace, můžete definovat podmínky nebo omezení specifická pro doménu, na kterou se databáze vztahuje. Například v tabulce, která uchovává informace o studentech školy, lze zavést omezení, aby data narození neumožňovala budoucí data nebo data, která jsou příliš daleko v minulosti.
Organizace tabulek v databázi se běžně nazývá databázové schéma. Kromě tabulek schéma podrobně popisuje omezení zahrnující dvojice tabulek nazývané vztahy. Vztah spojuje dvě tabulky uložením omezení, že hodnoty v poli jedné z tabulek odpovídají hodnotám v primárním klíči druhé tabulky.
Databázová schémata jsou obvykle reprezentována diagramem entit-relationship diagram (ERD), běžným nástrojem pro každého návrháře databází.
ERD představující datový model zákazníka.
Anomálie a normalizace
Všechny koncepty, o kterých jsme dosud diskutovali, jsou docela jasné, že? Nyní můžeme mluvit o anomáliích, které se vyskytují v databázích kvůli vadnému nebo neadekvátnímu návrhu (tj. databáze dostatečně neodráží realitu, kterou se snaží reprezentovat).
K anomáliím dochází, když operace vložení, aktualizace nebo odstranění generuje nekonzistence v datech. Předpokládejme například, že máte tabulku pro ukládání dat o prodeji. U každého prodeje (tedy v každém záznamu tabulky) je zaznamenáno jméno a adresa zákazníků. Anomálie je následující:
- Pokud je adresa zákazníka změněna v jednom z prodejů, a
- Stejný zákazník má jiné prodeje,
- Ostatní prodeje budou mít zastaralou adresu.
Abyste se vyhnuli anomáliím, můžete použít návrhovou techniku zvanou normalizace databáze. To zahrnuje rozložení tabulek a sloupců (tj. jejich rozdělení na menší části), aby se předešlo konstrukčním chybám, jako jsou:
- Sloupce, které obsahují více než jednu informaci (např. identifikační číslo položky a její název).
- Ukládání stejných informací více než jednou do stejné tabulky.
- Pole, která závisí na jiných neklíčových polích.
Nenormalizovaná tabulka (vlevo) versus normalizované schéma (vpravo).
Datové sklady a denormalizace
Některé databáze se používají k dotazování na velké objemy informací namísto online zpracování transakcí (OLTP). Tyto databáze se nazývají datové sklady.
Informace v datovém skladu nepocházejí z uživatelských rozhraní (např. zadané přímo z objednávkového systému elektronického obchodu). Pochází z dávkových procesů, které shromažďují informace z různých zdrojů, zpracovávají je, čistí a ukládají do tabulek. Z tohoto důvodu můžeme předpokládat, že datové sklady nejsou vystaveny stejným anomáliím jako konvenční databáze.
Datové sklady proto nemusí udržovat stejné podmínky normalizace jako databáze OLTP. Na druhou stranu je důležitější optimalizovat efektivitu dotazů v datových skladech. To je důvod, proč se v datovém skladu používá denormalizace; tato technika využívá určité množství redundance ke zjednodušení dotazů a zamezení zahlcení schémat nadměrným počtem tabulek.
Typické schéma datového skladu.
Velká data
Stejně jako datové sklady se koncept Big Data týká úložišť, která uchovávají velké množství dat. Mezi těmito dvěma pojmy je však důležitý rozdíl. Datový sklad je navržen pro konkrétní účel a je zaměřen na generování sestav, jejichž chování a formát jsou předem známy.
Na druhé straně se Big Data zaměřují na shromažďování velkých objemů dat, která jsou generována vysokou rychlostí z různých zdrojů – např. informace ze sociálních sítí, mikrotransakcí nebo chytrých senzorů. Toto obrovské množství informací lze použít k průzkumu a analýze nebo k trénování modelů strojového učení.
Při návrhu databáze velkých dat je prioritou úspora úložného prostoru a rozdělení dat (mimo jiné), aby se umožnil paralelismus a sběr dat v reálném čase. Kromě toho se používají nerelační nebo NoSQL databázové systémy, které nabízejí lepší alternativy pro práci s nestrukturovanými informacemi.
Technologie jako NoSQL a samotný koncept Big Data jsou relativně nové ve srovnání s relačními databázemi, které jsou již více než 40 let staré. To je důvod, proč jako návrhář databází musíte být pozorní k novému vývoji v této oblasti. Mějte na paměti, že velká data jsou také velký byznys. Mnoho společností v něm chce zaujmout vedoucí postavení a vyvíjí k tomu nové nástroje a technologie.
Správa databáze
Jakmile je databáze v provozu, někdo se musí starat o její každodenní správu. To znamená provádět rutinní úkoly, aby se databáze nikdy nestala úzkým hrdlem pro aplikace, které ji používají. Úlohy správy zahrnují údržbu záloh, sledování spotřeby úložného prostoru, zjišťování selhání mezi procesy a odstraňování problémů s daty, které brání normálnímu provozu aplikací.
Osoba, která má databázové dovednosti, aby se postarala o tyto úkoly, je správce databáze nebo DBA – pokud existuje. Ve velmi malých organizacích – nebo ve vývojových prostředích, kde provoz databází není pro podnikání kritický – může odpovědnost za údržbu databáze padnout na databázového modeláře. Proto byste měli mít určité znalosti, které vám umožní v určitých situacích převzít řízení od DBA. Za žádných okolností byste však neměli přijmout odpovědnost za správu databáze v produkčním prostředí, které podporuje obchodní nebo kritické aplikace .
Úlohy správy se značně liší v závislosti na databázovém systému a infrastruktuře, na které je připojen. Například úkoly správy databází Microsoft SQL Server se velmi liší od úkolů správy databází MySQL nebo Oracle. A správa serveru, který máte spuštěný lokálně v notebooku, se velmi liší od správy serveru, který běží v cloudu.
Nedoporučuji věnovat mnoho úsilí tomu, abyste se naučili spravovat konkrétní databázový server, protože během své kariéry budete pracovat s velmi odlišnými databázemi a prostředími. Specializovat se jen na jeden vám moc nepomůže.
Správa souběžnosti a transakcí
Současný přístup k databázi může způsobit problémy v aplikacích, když se několik uživatelů pokouší o přístup ke stejnému zdroji současně. Mohli bychom si myslet, že jako designérům to není naše věc a že je odpovědností DBA se s těmito problémy vypořádat. Můžeme si také myslet, že je to chyba programátorů, kteří vytvářejí aplikace, které jim to umožňují.
Návrháři však mohou přispět k minimalizaci potenciálních problémů souběžnosti tím, že navrhnou schémata, která jim zabrání.
Při provádění dlouhých a složitých transakcí v databázi dochází k mnoha problémům souběžnosti; během zpracování transakce jsou příslušné tabulky blokovány pro jiné procesy, které je potřebují ke čtení nebo zápisu informací. Chcete-li se tomuto druhu problému vyhnout, nejlepší věc, kterou můžete udělat, je zajistit, aby vaše návrhy vyhovovaly alespoň třetí normální formě. Pak bude odpovědností programátora, aby transakce správně promyslel, aby se zabránilo uváznutí.
Ale můžete také použít strategie, které se vyhýbají souběžnosti, jako je rozdělení schémat nebo seskupení tabulek podle funkce, kterou každé z nich plní.
Představme si databázi pro stránky elektronického obchodu. Tabulky kmenových dat pro produkty, zásoby a ceny můžete umístit do jednoho schématu a objednávky a prodeje do jiného, společně s pohledy nebo replikami tabulek z prvního schématu pouze pro čtení. To pomáhá vyhnout se chybám při provádění transakcí, které aktualizují kmenová data.
Nástroje pro návrh databáze
Pokud rozumíte relačnímu modelu, diagramům vztahů mezi entitami a normalizačním technikám, můžete navrhovat databáze pomocí jiného nástroje než tužky a papíru. Váš výkon se však výrazně zvýší, pokud použijete inteligentní nástroj, zejména takový, který dokáže automatizovat určité návrhové úlohy, jako je přemístění nebo úprava objektů v diagramu, zjišťování chyb návrhu, generování skriptů SQL pro vytvoření nebo aktualizaci databáze a zpětný chod. navrhování existujícího návrhu databáze.
Zvládnutí specializovaného nástroje, jako je platforma Vertabelo, vám umožní pracovat mnohem rychleji. A umožní vám odlišit se od ostatních designérů, kteří tuto pomoc nemají.
SQL a programování
Všichni bychom chtěli umět dodat návrh databáze, hrdě říci „Moje práce je tady“ a odjet na zaslouženou dovolenou. Ale obvykle taková ideální situace nikdy nenastane. Jakmile dokončíte svůj návrh, budou ho muset použít programátoři aplikací a budou muset mít vás nablízku, abyste jim pomohli.
Jedním ze způsobů, jak byste měli nadále pomáhat ve vývojovém projektu, je psát pohledy, spouštěče, uložené procedury a další věci v SQL (Structured Query Language) pro řešení konkrétních potřeb aplikací. Dalším způsobem je dohlížet na programovací úlohy, které se provádějí pomocí něčeho, co se nazývá objektově-relační mapování (ORM).
ORM jsou určeny k abstrahování přístupu k datům z konkrétního RDBMS. Dobrou stránkou toho je, že se programátoři nemusí starat o specifika databáze, kterou budou používat – jinými slovy, nemusí se starat, zda je RDBMS MySQL, Oracle, IBM DB2, MS SQL Server. , nebo něco jiného.
Nevýhodou ORM je, že objekty návrhu databáze – tabulky, atributy a vztahy – jsou definovány v kódu programovacího jazyka na vysoké úrovni, jako je Java, Python, R nebo C#. Jinými slovy, jsou tam, kde je my návrháři databází nevidíme.
Řešení tohoto problému spočívá v agilních vývojových metodologiích a jejich filozofii spolupráce. Ty podporují designéry a programátory, kteří spolupracují v průběhu projektu, takže budete chtít udržovat dobrý vztah s programátory. Měli byste být ochotni sedět vedle nich, podívat se na programovací kód a společně napsat definice datových objektů.
Měli by mít návrháři databází měkkých dovedností
Kromě teoretických a technických znalostí specifických pro návrh databáze by měl mít návrhář v ideálním případě další dovednosti známé jako „soft skills“. Tyto dovednosti – jako je dobrý komunikátor a porozumění obchodní vizi konečného produktu – nepřímo ovlivňují úspěch vaší práce. Ty, které uvádím níže, jsou jen některé příklady, ale existuje mnohem více měkkých dovedností, které potenciální zaměstnavatelé velmi oceňují.
Obchodní vize
Když navrhujete databázi, reprezentujete realitu podnikání z hlediska vzájemně souvisejících datových objektů. Viděli jsme, že návrh musí splňovat standardizační podmínky a že se musí vyvarovat nekonzistencí, anomálií a problémů se souběžností. Ale stejně důležité – nebo možná ještě důležitější – je, že design je v souladu s obchodní vizí toho, kdo vám platí plat.
Pochopení obchodní vize vám umožní lépe pochopit důležitost každého požadavku a vést vaše rozhodnutí tak, aby vaše návrhy lépe odpovídaly cílům organizace.
Zde je jednoduchý příklad toho, jak pochopení obchodní vize utváří vaši práci. Můžete si myslet, že použití náhradního klíče v tabulce ruší váš design a přidává zbytečný a obtěžující prvek. Ale vynecháním náhradního klíče můžete zpomalit dotazy na tuto tabulku, protože klíč typu INTEGER může poskytnout vynikající výkon. Pokud je obchodní vizí poskytování rychlých dotazů, pak je náhradní klíč správnou cestou.
Komunikační dovednosti
Nestačí dělat skvělé návrhy. Musíte být také schopni vysvětlit, proč váš návrh funguje. Způsob, jak toho dosáhnout, je vědět, jak to prezentovat, a to jak diskurzivně (mluvené nebo písemné), tak vizuálně.
Udělejte si seznam předností svého designu, aby vynikly. Přemýšlejte o rozhodnutích, která jste učinili, abyste jej vytvořili, a zapište si důvody těchto rozhodnutí. Buďte připraveni obhajovat svá rozhodnutí a svůj návrh před těmi, kteří tomu nerozumí nebo je chtějí změnit, čímž se stanou nedokonalými nebo vadnými.
Ale musíte být také ochotni přijmout konstruktivní kritiku a zvážit názory, které se liší od vašich vlastních. Někdy může programátor zaznamenat problém, který jste neviděli, a poskytnout vám dobrou radu. Nepropouštějte své spolupracovníky v domnění, že nemají znalost databáze.
Interpersonální dovednosti
Výše jsem se vyjádřil k výhodám dobrého vztahu s programátory. Bez ohledu na to, jak pokročilí jste ve své oblasti odborných znalostí, je důležité, abyste si zachovali přátelský přístup ke všem členům týmu, ať už je to tester, který zjistil závadu, která vás nutí přehodnotit část vašeho návrhu, nebo projektový manažer, který potřebuje abyste splnili úkol do určitého data. Stručně řečeno, musíte být týmový hráč . Nikdo nechce mít ve svém týmu primadony, které se cítí nenahraditelné a chtějí vnucovat svá pravidla.
Může se stát, že nejste jediným návrhářem databáze ve vývojovém týmu. Možná musíte vést podskupinu svých kolegů. Chcete-li tak učinit, musíte prokázat vůdčí schopnosti a jednat jako projektový manažer a zajistit, aby tým návrhářů databází splnil své cíle a zůstal motivovaný.
Jak se naučit dovednosti návrhu databáze
Dovednosti, které potřebujete k tomu, abyste byli návrhářem databází, můžete získat z univerzitních diplomů, kurzů, knih a odborných článků. Výhodou univerzitních kurzů je, že vám poskytnou všechny znalosti, které potřebujete, a potvrdí je uznávaným titulem. Nevýhodou je, že vyžadují velkou investici času a peněz.
Pokud se raději učíte sami čtením knih a článků, ušetříte čas i peníze – ale budete potřebovat průvodce, který vás provede zásadními tématy a zhodnotí vaše znalosti. A své znalosti budete muset prokázat praktickým způsobem, protože nebudete mít žádný titul, který by je podpořil.
V každém případě, ať už se učíte absolvováním kurzů nebo čtením, tyto znalosti budou sloužit pouze jako základ. Nejvíce se naučíte vytvářením modelů, konfrontací se skutečnými problémy a pozorováním jednání svých kolegů a spolupracovníků.