Evoluční návrh databáze - Evolutionary database design - Wikipedia

Evoluční návrh databáze zahrnuje přírůstkové vylepšení databázové schéma tak, aby mohl být průběžně aktualizován změnami, odrážejícími požadavky zákazníka. Lidé na celém světě pracují na stejném softwaru ve stejnou dobu, proto je potřeba technik, které umožní hladký vývoj databáze jak se design vyvíjí. Tyto metody využívají automatizovaně refaktorování a kontinuální integrace tak, aby to podporovalo agilní metodiky pro vývoj softwaru. Tyto vývojové techniky jsou aplikovány na systémy, které jsou v předvýroba na systémech, které již byly vydány. Tyto techniky pokrývají nejen relevantní změny ve schématu databáze podle měnících se potřeb zákazníka, ale také migraci upravených dat do databáze a také odpovídající přizpůsobení přístupového kódu k databázi beze změny datová sémantika.^[1]

Dějiny

Po použití model vodopádu po dlouhou dobu byl softwarový průmysl svědkem nárůstu přijetí agilních metod pro vývoj softwaru. Agilní metodiky nepředpokládejte požadavky být trvalý v kterékoli fázi životní cyklus softwaru. Tyto metody jsou navrženy tak, aby podporovaly sporadické změny na rozdíl od techniky návrhu vodopádu. Důležitou součástí tohoto přístupu je iterativní vývoj, kde je celý životní cyklus softwaru spuštěn několikrát během životnosti projektu. Každá iterace je svědkem celého životního cyklu vývoje softwaru, přestože iterace mají krátké trvání, které se může pohybovat mezi týdny až několika měsíci.^[1]

Před přijetím těchto metodik byl celý systém navržen před zahájením vývoje kódu. Stejný princip byl aplikován také na databázové schéma, kde bylo považováno za odvozené z softwarové požadavky které byly následně vyvinuty na základě spolupráce mezi zákazníkem, koncovými uživateli, obchodními analytiky atd. a neočekávalo se, že se tyto požadavky budou s vývojem softwaru měnit. Tento přístup se ukázal jako těžkopádný, protože jak čas postupoval, byla evidentní redundance ve stávajícím schématu databáze ve formě nepoužívaných řádků nebo sloupců. Tato nadbytečnost spolu s kvalita dat problémy se staly nákladnou záležitostí. Byl učiněn závěr, že praxe, kdy nebyl návrh prokládán konstrukcí a testováním, byla vysoce neúčinná.^[1]

Techniky

Jak bylo zmíněno v předchozí části, evoluční metody jsou v podstatě iterační a tyto metody se v posledních dvou desetiletích staly nesmírně populární. Evoluční návrh databáze si klade za cíl vytvořit databázové schéma v průběhu projektu namísto vytvoření celého databázového schématu na začátku projektu. Tato metoda návrhu databáze dokáže zachytit a efektivně řešit měnící se požadavky projektů.

Existuje pět evolučních technik návrhu databáze, které mohou vývojářům pomoci při iteračním vytváření jejich databáze. Níže je uveden stručný přehled pěti technik.

Refaktorování databáze

Refaktorování je proces provádění změn v programu bez ovlivnění funkčnosti programu. Refaktorování databáze je technika implementace malých změn do schématu databáze bez ovlivnění funkčnosti a informací uložených v databázi.^[2] Hlavním účelem refaktorování databáze je zlepšit návrh databáze aby byla databáze více synchronizována s měnícími se požadavky. Uživatel může upravit tabulky, pohledy, uložené procedury a spouští. Závislost mezi databází a externími aplikacemi činí z refaktoringu databáze výzvu.

Evoluční modelování dat

Datové modelování je technika identifikace subjekty sdružování atributy subjektům a rozhodování o datová struktura reprezentovat atributy.^[3] V tradičním databázovém scénáři je na začátku vytvořen logický datový model, který představuje entity a jejich přidružené atributy. V evolučním datovém modelování se technika datového modelování provádí iterativním způsobem, tj. Je vyvíjeno více datových modelů, přičemž každý model představuje jiný aspekt databáze. Tento druh techniky modelování dat se praktikuje v agilním prostředí a je jedním z hlavních principů agilního vývoje.^[4]

Regresní testování databáze

Kdykoli je do systému přidána nová funkce, je nutné ověřit, zda aktualizace nepoškodí nebo nepoužije systém. V databázi je obchodní logika implementována v uložené procedury, ověření dat pravidla a referenční integrita a při implementaci jakékoli změny do systému je nutné je důkladně otestovat. Regresní testování je proces provádění všech testovací případy kdykoli je do systému přidána nová funkce. test-první vývoj (TFD) je forma regresního testování následovaná v evolučním návrhu databáze. Kroky zahrnuté v přístupu TFD jsou,^[3]

Před přidáním nové funkce do systému přidejte test do sady testovacích případů, aby systém test nevyhověl
Spusťte testy, buď celou sadu testovacích případů, nebo jen podmnožinu a zajistěte, aby nově přidaný test skutečně selhal
Aktualizujte funkci tak, aby test vyhověl
Spusťte znovu testy, abyste se ujistili, že vše proběhlo úspěšně a že systém není poškozený

Správa konfigurace databázových artefaktů

Správa konfigurace je podrobný záznam verzí a aktualizací, které byly použity v jakémkoli systému. Správa konfigurace je užitečná v vrácení zpět aktualizace a změny, které negativně ovlivnily systém. Aby bylo možné vrátit všechny aktualizace provedené v refaktoringu databáze, je důležité udržovat databázové artefakty jako jazyk definice dat skripty, soubory datových modelů, referenční údaje, uložené procedury atd. v systému správy konfigurace.^[5]

Sandbox pro vývojáře

A pískoviště je plně funkční prostředí, ve kterém lze systém postavit, otestovat a spustit. Aby bylo možné provádět změny v databázovém schématu evolučním způsobem, je pro každého vývojáře ideální mít vlastní fyzický sandbox, kopii zdrojový kód a kopii databáze. V prostředí karantény může vývojář provádět změny ve schématu databáze a spouštět testy, aniž by to ovlivnilo práci ostatních vývojářů a jiných prostředí. Jakmile je změna úspěšně implementována, je povýšena na předvýroba prostředí kde v přejímací zkoušky je provedeno a po úspěšném přijetí přejímacích testů je nasazeno do Výroba.

Výhody a nevýhody

Výhody

Vysoká kvalita návrhu databáze: V evolučním návrhu databáze provede vývojář drobné změny schématu databáze přírůstkovým způsobem a tím se dosáhne vysoce optimalizováno databázové schéma.
Změna manipulace: V a tradiční databáze Při změně požadavků se mnoho času věnuje přestavování a restrukturalizaci databáze. V evoluční databázové technice je schéma databáze se pravidelně upravuje, aby držela krok s měnícími se požadavky. Proto je evoluční technika návrhu databáze vhodnější pro řešení měnících se požadavků.
Zaručená funkčnost systému za všech okolností: Následuje přístup k vývoji evoluční databáze test-první vývoj model, ve kterém je testováno úplné fungování systému před a po implementaci aktualizace. Je tedy zaručeno, že systém vždy funguje.
Kompatibilní s vývojem softwaru: IT průmysl postupuje směrem k agilní metodě vývoje softwaru a vývoj evoluční databáze zajišťuje synchronizaci vývoje dat s vývojem softwaru.
Snížené celkové úsilí: V evolučním prostředí je implementována pouze funkce, která je v daném okamžiku požadována, a ne více.

Nevýhody

Kulturní překážky: Přístup k vývoji evoluční databáze je relativně novější koncept a mnoho dobře kvalifikovaných datoví profesionálové stále obhajuje tradiční přístup. Většina databází se proto stále navrhuje sériovým způsobem a vývojový návrh databáze zatím nezíská podporu a trakci mezi zkušenými profesionály v oblasti dat.
Vyžaduje křivku učení: Většina vývojářů je více obeznámena s tradičním přístupem a naučit se evolučnímu designu vyžaduje čas, protože není intuitivní.
Složité: Když má databáze mnoho externích závislostí, provádění změn ve schématu se stává o to komplikovanější, že externí závislosti by měly být také aktualizovány, aby zvládly změny provedené ve schématu databáze. S nárůstem počtu závislostí se přístup Evolutionary Database Design stává extrémně složitým.

Srovnání s tradičním návrhem databáze

Tradiční technika návrhu databáze nepodporuje změny, jako je technika evolučního návrhu databáze. `` Tradiční komunita dat bohužel předpokládala, že vývoj schématu databáze je obtížná věc, a proto nikdy nepřemýšleli, jak to udělat.^[1] Svým způsobem je vývojový design lepší pro vývojáře aplikací a tradiční design je lepší pro datové profesionály.^[6]

Vlastnosti	Tradiční návrh databáze	Evoluční návrh databáze
Design	Tradiční databáze byly vyvinuty na základě spolupráce mezi obchodní analytici a uživatelé.	Evoluční databáze byly navrženy vývojáři softwaru a datovými profesionály.
Problémy s designem	Ukazují některé konstrukční problémy v databázích. Komerčně dostupné databáze byly vyvinuty zkušenými jednotlivci, ale nyní jsou obsluhovány databází, nikoli datovými profesionály.^[6]	Jsou vyvinuty úzkou aliancí vývojářů softwaru a profesionálů v oblasti dat. Databáze se vyvíjí s vývojem, a proto ji zpracovávají stejní jednotlivci, kteří byli zodpovědní za vývoj.
Přístup ke změně	Jakákoli změna požadovaná uživatelem je začleněna do logického modelu následovaného fyzickým modelem a poté testována, aby byla zajištěna dokonalá funkčnost.^[6]	Změna je nedílnou součástí návrhu evoluční databáze. Jakákoli změna požadovaná uživatelem je okamžitě implementována do databáze i do kódu. The migrace dat skripty je také třeba aktualizovat.
Závislost na ER diagramu	Tradiční design je metodický a vzhledem k jeho závislosti na ER diagram a jeho podrobné fáze návrhu, jako je uživatel, logika a fyzika, můžeme sledovat data i jejich význam.^[6]	Návrh je prokládán mezi fázemi vývoje evolučního návrhu databáze. Vztah mezi entitami se tedy může během cyklu vývoje softwaru měnit, stejně tak se mění diagram ER.

Nástroje

Níže je uveden seznam nástrojů, které poskytují funkce navrhování a vývoje databáze evolučním způsobem.

Viz také

Reference

^ ^A ^b ^C ^d „Evoluční návrh databáze“. Citováno 2016-09-14.
^ Vial, G. (2015-11-01). "Refaktorování databáze: Poučení ze zákopů". Software IEEE. 32 (6): 71–79. doi:10.1109 / MS.2015.131. ISSN 0740-7459.
^ ^A ^b Ambler, Scott; Sadalage, Pramod J (2006). Refaktorování databáze: Evoluční návrh databáze. Addison Wesley Professional. ISBN 978-0-321-29353-4.
^ „Principy agilního modelování (AM)“. www.agilemodeling.com. Citováno 2016-09-22.
^ „Osvědčené postupy evoluční / agilní databáze“. agiledata.org. Citováno 2016-09-14.
^ ^A ^b ^C ^d Data, velká; data, díky nebesům za křemíkový čip: A. KRÁTKÁ historie; motor, odhalena tajemství hackerů automobilů: Klasicky svírá motor nádrže; Za genomem: Zase jsi byl dekódován. „Evoluční vs. tradiční návrh databáze“. Citováno 2016-09-14.

[:1-1] A ^b ^C ^d „Evoluční návrh databáze“. Citováno 2016-09-14.

[2] Vial, G. (2015-11-01). "Refaktorování databáze: Poučení ze zákopů". Software IEEE. 32 (6): 71–79. doi:10.1109 / MS.2015.131. ISSN 0740-7459.

[:0-3] A ^b Ambler, Scott; Sadalage, Pramod J (2006). Refaktorování databáze: Evoluční návrh databáze. Addison Wesley Professional. ISBN 978-0-321-29353-4.

[4] „Principy agilního modelování (AM)“. www.agilemodeling.com. Citováno 2016-09-22.

[5] „Osvědčené postupy evoluční / agilní databáze“. agiledata.org. Citováno 2016-09-14.

[:2-6] A ^b ^C ^d Data, velká; data, díky nebesům za křemíkový čip: A. KRÁTKÁ historie; motor, odhalena tajemství hackerů automobilů: Klasicky svírá motor nádrže; Za genomem: Zase jsi byl dekódován. „Evoluční vs. tradiční návrh databáze“. Citováno 2016-09-14.

[1]

[2]

[3]

[4]

[5]

[6]