Laravel poskytuje mnoho užitočných nástrojov na testovanie vašich databázových aplikácií. Najprv môžete použiť pomocnú metódu PHP seeInDatabase() skontrolovať, či údaje v databáze zodpovedajú určitému súboru kritérií. Napríklad, ak chcete skontrolovať, či sa v tabuľke používateľov nachádza záznam s poľom e-mailu rovným [e-mail chránený], môžete urobiť nasledovné:
PHP
{
// Uskutočňuje sa volanie aplikácie...
$this -> seeInDatabase("users" , [
"e-mail" => " [e-mail chránený]"
]);
}
Samozrejme, metódy ako PHP seeInDatabase() vytvorené pre pohodlie. Na rozšírenie testov môžete použiť ktorúkoľvek zo vstavaných overovacích metód PHPUnit.
Resetovanie databázy po každom teste
Často je užitočné obnoviť databázu po každom teste, aby údaje z predchádzajúceho testu neovplyvnili nasledujúce testy.
Používanie migrácií
Jedným zo spôsobov, ako obnoviť stav databázy, je vrátiť databázu späť po každom teste a migrovať ju pred ďalším testom. Laravel poskytuje jednoduchú vlastnosť DatabaseMigrations, ktorá to automaticky urobí za vás. Stačí použiť túto vlastnosť vo svojej testovacej triede a všetko sa urobí za vás:
PHP /**
{
používať DatabaseMigrations ;
*
* @return void
*/
{
$this -> visit("/" )
-> pozri("Laravel 5" );
}
}
Používanie transakcií
Ďalším spôsobom, ako obnoviť stav databázy, je zabaliť každý testovací prípad do databázovej transakcie. A preto Laravel poskytuje aj praktickú vlastnosť DatabaseTransactions, ktorá to automaticky urobí za vás:
PHP Použite Illuminate \ Foundation \ Testing \ WithoutMiddleware ; trieda PríkladTest rozširuje TestCase /**
použite Illuminate \ Foundation \ Testing \ DatabaseMigrations ;
použite Illuminate \ Foundation \ Testing \ DatabaseTransactions ;
{
používať DatabaseTransactions ;
* Príklad základného funkčného testu.
*
* @return void
*/
{
$this -> visit("/" )
-> pozri("Laravel 5" );
}
}
V predvolenom nastavení táto vlastnosť zabalí do transakcie iba predvolené pripojenie k databáze. Ak vaša aplikácia používa viacero databázových pripojení, musíte definovať vlastnosť PHP $connectionsToTransact vo svojej testovacej triede. Táto vlastnosť by mala byť pole názvov pripojení, aby sa s nimi mohli vykonávať transakcie.
Vytváranie tovární
Pri testovaní možno budete musieť pred vykonaním testu vložiť do databázy viacero záznamov. Pri vytváraní týchto údajov vám Laravel umožňuje manuálne definovať predvolenú sadu atribútov pre každý z vašich modelov Eloquent pomocou tovární namiesto manuálneho zadávania hodnôt každého stĺpca. Najprv sa pozrite na súbor database/factories/ModelFactory.php vo vašej aplikácii. Spočiatku tento súbor obsahuje jednu definíciu továrne:
PHP $factory -> define (App \ User ::class, function (Faker \ Generator $faker ) (
statické $heslo ;
vrátiť[
"name" => $faker -> name ,
"email" => $faker -> unique()-> safeEmail ,
"password" => $password ?: $password = bcrypt("tajné"),
"remember_token" => str_random(10),
];
});
V uzávere, ktorý slúži ako definícia továrne, môžete vrátiť predvolené hodnoty testu pre všetky atribúty modelu. Uzavretie dostane inštanciu knižnice Faker PHP, ktorá umožňuje pohodlne generovať rôzne náhodné dáta na testovanie.
Do súboru ModelFactory.php môžete samozrejme pridať svoje vlastné ďalšie továrne. Pre lepšiu organizáciu môžete pre každý model vytvoriť aj ďalšie výrobné súbory. Môžete napríklad vytvoriť súbory UserFactory.php a CommentFactory.php vo svojom priečinku Database/factory. Laravel automaticky stiahne všetky súbory v priečinku factorys.
Stavy továrne
Stavy vám umožňujú definovať jednotlivé zmeny, ktoré je možné aplikovať na vaše modelové závody v akejkoľvek kombinácii. Napríklad váš používateľský model môže mať delikventný stav, ktorý mení predvolenú hodnotu jedného z atribútov. Svoje stavové transformácie môžete definovať pomocou metódy PHP štát() :
PHP $factory -> state (App \ User ::class, "deliquent" , function ($faker ) (
vrátiť [
"account_status" => "delikvent" ,
];
});
Používanie tovární
Vytváranie modelov
Keď sú továrne definované, môžete použiť globálnu funkciu PHP továreň() vo vašich testoch alebo počiatočných súboroch na generovanie inštancií modelu. Poďme sa teda pozrieť na niekoľko príkladov vytvárania modelov. Najprv použijeme metódu PHP urobiť() vytvárať modely, ale neukladať ich do databázy:
PHP verejná funkcia testDatabase()
{
$user = factory(App\User::class)-> make();
Môžete tiež vytvoriť kolekciu modelov alebo vytvoriť modely konkrétneho typu:
PHP $users = factory(App\User::class, 3)-> make();
Akékoľvek môžete použiť aj na modely. Ak chcete na modely použiť viaceré zmeny stavu, musíte zadať názov každého štátu, ktorý chcete použiť:
PHP $users = factory(App\User::class, 5 )-> state("delikvent")-> make();
$users = factory (App \ User ::class, 5 )-> state("premium" , "delikvent" )-> make();
Prevažujúce atribúty
Ak chcete prepísať niektoré predvolené hodnoty svojich modelov, môžete metóde PHP odovzdať pole hodnôt urobiť(). Nahradia sa iba špecifikované hodnoty a zvyšok sa nastaví podľa hodnôt špecifikovaných vo výrobe:
PHP $user = factory(App\User::class)-> make([
"name" => "Abigail" ,
]);
Permanentné modely
metóda PHP vytvoriť () nielen vytvára inštancie modelov, ale ich aj ukladá do databázy pomocou metódy Eloquent PHP uložiť () :
PHP verejná funkcia testDatabase()
{
// Vytvorenie jednej inštancie App\User...
$user = factory(App\User::class)->create();
// Vytvorte tri inštancie App\User...
$users = factory(App\User::class, 3)->create();
// Použitie modelu v testoch...
}
Atribúty modelu môžete prepísať odovzdaním poľa metóde PHP vytvoriť ():PHP make());
});
Zachytenie vzťahov a atribútov
Môžete tiež pripojiť vzťahy k modelom pomocou atribútov uzáveru v definíciách továrne. Ak napríklad chcete pri vytváraní príspevku vytvoriť novú inštanciu modelu používateľa, môžete to urobiť takto:
PHP $factory ->
vrátiť [
"title" => $faker -> title ,
"content" => $faker -> odsek ,
"user_id" => function() (
return factory (App \ User ::class)-> create ()-> id ;
}
];
});
Tento uzáver tiež získa špecifické pole atribútov pre továreň, ktorá ho obsahuje:
PHP $factory -> define (App \ Post ::class, function ($faker ) (
vrátiť [
"title" => $faker -> title ,
"content" => $faker -> odsek ,
"user_id" => function() (
return factory (App \ User ::class)-> create ()-> id ;
},
"user_type" => funkcia (pole $post ) (
return App \ User :: find ($post [ "user_id" ])-> type ;
}
];
});
: Ako testovať a ladiť databázy
Automatizované jednotkové testovanie kódu aplikácie je priamočiare a priamočiare. Ako otestovať databázu? Alebo aplikácia, ktorá pracuje s databázou. Koniec koncov, databáza nie je len programový kód, databáza je objekt, ktorý ukladá svoj stav. A ak počas testovacieho procesu začneme meniť údaje v databáze (a bez toho, aké testovanie budeme mať?!), tak po každom teste sa databáza zmení. To môže narušiť následné testy a trvalo poškodiť databázu.
Kľúčom k riešeniu problému sú transakcie. Jednou z vlastností tohto mechanizmu je, že kým sa transakcia nedokončí, vždy môžete vrátiť späť všetky zmeny a vrátiť databázu do stavu, v akom bola transakcia spustená.
Algoritmus je tento:
- otvoriť transakciu;
- v prípade potreby vykonávame prípravné akcie na testovanie;
- spustiť test jednotky (alebo len spustiť skript, ktorý chceme testovať);
- skontrolujte výsledok skriptu;
- zrušiť transakciu a vrátiť databázu do pôvodného stavu.
Aj keď sú v testovanom kóde neuzavreté transakcie, vonkajší ROLLBACK bude stále správne vracať všetky zmeny.
Je dobré, ak potrebujeme otestovať SQL skript alebo uloženú procedúru. Čo ak testujeme aplikáciu, ktorá sa pripája k samotnej databáze otvorením nového pripojenia? Navyše, ak ladíme, tak sa zrejme chceme na databázu pozrieť očami ladenej aplikácie. Ako byť v takom prípade?
Neponáhľajte sa zapisovať distribuované transakcie, existuje jednoduchšie riešenie! Pomocou štandardných nástrojov SQL servera môžete otvoriť transakciu na jednom pripojení a pokračovať v ňom na inom.
Ak to chcete urobiť, musíte sa pripojiť k serveru, otvoriť transakciu, získať token tejto transakcie a potom odovzdať tento token testovanej aplikácii. Pripojí sa k našej transakcii vo svojej relácii a od tohto momentu v našej relácii ladenia uvidíme údaje (a tiež pocítime zámky) presne tak, ako ich vidí testovaná aplikácia.
Postupnosť akcií je nasledovná:
Po spustení transakcie v relácii ladenia musíme zistiť jej identifikátor. Toto je jedinečný reťazec, pomocou ktorého server rozlišuje medzi transakciami. Tento identifikátor musí byť nejakým spôsobom odovzdaný testovanej aplikácii.
Teraz je úlohou aplikácie naviazať sa na našu riadiacu transakciu skôr, ako začne robiť to, čo má robiť.
Potom aplikácia začne pracovať, vrátane spúšťania jej uložených procedúr, otvárania transakcií, zmeny režimu izolácie... Ale naša relácia ladenia bude po celý čas prebiehať v tej istej transakcii ako aplikácia.
Povedzme, že aplikácia uzamkne tabuľku a začne upravovať jej obsah. V tomto bode sa do zamknutej tabuľky nemôžu pozerať žiadne ďalšie spojenia. Ale nie naša relácia ladenia! Z nej sa môžeme na databázu pozerať rovnako ako aplikácia, keďže SQL server považuje za jednu transakciu.
Zatiaľ čo pre všetky ostatné relácie sú akcie aplikácie skryté pomocou zámkov...
Naša relácia ladenia ticho prechádza cez zámky (server si myslí, že sú to naše vlastné zámky)!
Alebo si predstavte, že aplikácia začne pracovať so svojimi verziami riadkov v režime SNAPSHOT. Ako nahliadnuť do týchto verzií? Aj to je možné, ak vás spája spoločná transakcia!
Na konci tohto vzrušujúceho procesu nezabudnite odvolať kontrolnú transakciu. Dá sa to urobiť z relácie ladenia (ak sa proces testovania dokončí normálne), ako aj zo samotnej aplikácie (ak sa v nej stane niečo neočakávané).
Viac sa o tom dozviete v kurze.
Testovanie databázy nie také bežné ako testovanie iných častí aplikácie. V niektorých testoch databázy všeobecne zmoknúť. V tomto článku sa pokúsim analyzovať nástroje na testovanie relačných a NoSQL databázy.
Táto situácia je spôsobená tým, že mnohé databázy sú komerčné a všetku potrebnú sadu nástrojov na prácu s nimi dodáva organizácia, ktorá túto databázu vyvinula. Nárast popularity NoSQL a rôznych forkov MySQL v budúcnosti však môže tento stav zmeniť.
Porovnanie databázy
Database Benchmark je .NET nástroj na záťažové testovanie databáz s veľkými dátovými tokmi. Aplikácia vykonáva dva hlavné testovacie scenáre: vkladanie veľkého počtu náhodne vygenerovaných záznamov so sekvenčnými alebo náhodnými kľúčmi a čítanie vložených záznamov zoradených podľa ich kľúčov. Má širokú škálu možností generovania údajov, grafických zostáv a konfigurácie možných typov zostáv.
Podporované databázy: MySQL, SQL Server, PostgreSQL, MongoDB a mnoho ďalších.
Databázový jazdec
Database Rider je navrhnutý tak, aby umožňoval testovanie databáza bola Nebolo to ťažšie ako testovanie jednotiek. Tento nástroj je založený na Arquillian a preto je v projekte Java potrebná iba závislosť pre DBUnit. Je tiež možné použiť anotácie, ako naprJUnit, integrácia s CDI cez interceptory, podpora JSON, YAML, XML, XLS a CSV, konfigurácia cez rovnaké anotácie resp. yml súborov, integrácia s Uhorka, podpora viacerých databáz, práca s dočasnými typmi v datasetoch.
DbFit
DbFit – vývojový rámec Databáza prostredníctvom testovania. Bolo to prepísané FitNesse, čo je vyspelý a výkonný nástroj s veľkou komunitou. Testy sú písané na základe tabuliek, vďaka čomu sú čitateľnejšie ako bežné testy. jednotka - testy. Môžete ich spustiť z IDE, pomocou príkazového riadku alebo pomocou nástrojov CI.
Podporované databázy: Oracle, SQL Server, MySQL, DB2, PostgreSQL, HSQLDB a Derby.
dbstress
dbstress je nástroj na testovanie výkonu databázy a záťažové testovanie napísaný v Scala a Akka. Pomocou špeciálneho JDBC-ovládač, vykoná paralelne požiadavky určitý počet krát (možno aj niekoľkým hostiteľom) a uloží konečný výsledok do csv súbor.
Podporované základne: všetky rovnaké ako v JDBC.
DbUnit
je rozšírenie JUnit (používa sa aj s Ant), ktorá sa môže medzi testami vrátiť databázy do správneho stavu. Táto funkcia vám umožňuje vyhnúť sa závislosti medzi testami, ak jeden test zlyhá a poruší základ, ďalší test začne od nuly. DbUnit má schopnosť prenášať dáta medzi databázou a XML dokumentom. Nechýba ani možnosť práce s veľkými datasetmi v režime streamovania. Môžete tiež skontrolovať, či výsledná databáza zodpovedá určitému štandardu.
Podporované základne: všetky rovnaké ako v JDBC.
DB Test Driven
DB Test Driven je nástroj pre jednotka - testovanie Databáza. Tento nástroj je veľmi ľahký, pracuje s natívnym SQL a inštaluje sa priamo do databázy. Ľahko sa integruje s nástrojmi nepretržitej integrácie a verzia SQL Server má schopnosť vyhodnotiť pokrytie kódu pomocou testov.
Podporované databázy: SQL Server, Oracle.
HammerDB
HammerDB – nástroj na testovanie záťaže a porovnávania Databáza. Ide o automatizovanú aplikáciu, ktorá je tiež viacvláknová a má schopnosť používať dynamické skripty. jav open source a nástroj na porovnávanie. Je automatizovaný, viacvláknový a rozšíriteľný s podporou dynamických skriptov.
JdbcSlim
JdbcSlim ponúka jednoduchú integráciu dotazov a príkazov v Slim FitNesse. Hlavným zameraním projektu je ukladanie množstva konfigurácií, testovacích údajov a SQL. To zaisťuje, že požiadavky sú napísané nezávisle od implementácie a sú zrozumiteľné pre podnikových používateľov. V JdbcSlim nie je žiadny kód špecifický pre databázu. Je agnostický špecifický pre databázový systém a nemá špecifický kód pre žiadny databázový systém. V samotnom frameworku je všetko popísané na vysokej úrovni, k zavedeniu akýchkoľvek konkrétnych vecí dochádza zmenou len jednej triedy.
Podporované databázy: Oracle, SQL Server, PostgreSQL, MySQL a iné.
JDBDT (Java DataBase Delta Testing)
JDBDT je knižnica Java na testovanie databázových aplikácií (na báze SQL). Knižnica je určená na automatizované testy inštalácie a overovania databázy. JDBDT nemá žiadnu závislosť od knižníc tretích strán, čo zjednodušuje jeho integráciu. V porovnaní s existujúcimi knižnicami na testovanie databáz je JDBDT koncepčne odlišný vo svojej schopnosti používať δ-príkazy.
Podporované databázy: PostgreSQL, MySQL, SQLite, Apache Derby, H2 a HSQLDB.
NBi
NBi je v podstate doplnok pre NUnit a je určený skôr business intelligence gule. Okrem práce s relačnými databázami je možné pracovať s OLAP platformy (analytické služby, Mondrian atď.), ETL A systémy podávania správ(technológie spoločnosti Microsoft). Hlavným cieľom tohto rámca je vytvárať testy pomocou deklaratívneho prístupu založeného na XML. Nebudete musieť písať testy v C# a používať Visual Studio na kompiláciu testov. Stačí vytvoriť xml súbor a interpretovať ho pomocou NBi, potom môžete spustiť testy. Okrem NUnit môžete portovať aj na iné testovacie rámce.
Podporované databázy: SQL Server, MySQL, PostgreSQL, Neo4j, MongoDB, DocumentDB a ďalšie.
NoSQLMap
NoSQLMap napísaný v Pythone na audit stability sql - injekcia a rôzne exploity v konfigurácii databázy. A tiež posúdiť stabilitu webovej aplikácie pomocou NoSQL databáz na tento druh útoku. Hlavným účelom aplikácie je poskytnúť nástroj na testovanie serverov MongoDB a vyvrátenie mýtu, že aplikácie NoSQL sú imúnne voči vstrekovaniu SQL.
Podporované databázy: MongoDB.
NoSQLUnit
NoSQLUnit je rozšírenie JUnit na písanie testov v aplikáciách Java, ktoré používajú databázy NoSQL. Cieľ NoSQLUnit- riadiť životný cyklus NoSQL. Tento nástroj vám pomôže udržať testované databázy v známom stave a štandardizovať spôsob, akým píšete testy pre aplikácie NoSQL.
Podporované databázy: MongoDB, Cassandra, HBase, Redis a Neo4j.
ruby-plsql-spec
ruby-plsql-spec je rámec na testovanie jednotiek PL/SQL s Ruby. Je založená na dvoch ďalších knižniciach:
- ruby-plsql - Ruby API na volanie procedúr PL/SQL;
- RSpec je rámec pre BDD.
Podporované databázy: Oracle
SeLite
SeLite je rozšírenie z rodiny Selenium. Hlavným bodom je mať databázu založenú na SQLite izolovaný od aplikácie. Budete môcť odhaliť chyby webového servera a tápať v skriptoch medzi testami, pracovať so snímkami atď.
Podporované databázy: SQLite, MySQL, PostgreSQL.
sqlmap
sqlmap je nástroj na penetračné testovanie, ktorý automatizuje proces zisťovania a využívania SQL injekcií a prevzatia databázových serverov. Dodáva sa s výkonným vyhľadávacím motorom a mnohými špeciálnymi funkciami.
Podporované databázy: MySQL, Oracle, PostgreSQL, SQL Server, DB2 a iné.
Open source nástroje na testovanie databáz
https://website/wp-content/uploads/2018/01/data-base-testing-150x150.png
Testovanie databázy nie je také bežné ako testovanie iných častí aplikácie. V niektorých testoch je databáza vôbec zosmiešňovaná. V tomto článku sa pokúsim rozobrať nástroje na testovanie relačných a NoSQL databáz. Táto situácia je spôsobená skutočnosťou, že mnohé databázy sú komerčné a všetku potrebnú sadu nástrojov na prácu s nimi dodáva […]
1) Ciele a zámery …………………………………………………………………... 3
2) Popis databázy …………………………………………………... 4
3) Práca s databázou ……………………………………………………… 6
4) Záťažové testovanie databázy …………………………………...11
5) Záver …………………………………………………………………………....15
6) Literatúra ………………………………………………………………………....16
Ciele a ciele
Cieľ: vytvorte databázu elixírov pre hru Witcher 3, ktorá bude obsahovať informácie o type elixírov, ich vlastnostiach, z čoho sú vyrobené, kde ich možno nájsť a proti ktorým sa dajú použiť príšery. Vytvorte optimalizované dotazy voči tejto databáze a otestujte jej zaťaženie.
Úlohy:
· Vytvorte databázovú schému v MYSQL Workbench s najmenej 5 entitami. Popíšte tieto entity a ich vzťahy.
Popíšte použitie tejto databázy, popíšte hlavné dotazy, pozrite sa na čas ich vykonania a vyvodte závery
Optimalizácia DB
· Vykonajte záťažové testovanie pomocou apache-jmeter. Použite rozšírenia na vykresľovanie grafov.
Popis databázy
Práca v kurze využíva vytvorenú databázu Witcher1, ktorej hlavnými entitami sú tabuľky:
Obr.1 Schematické znázornenie databázy Witcher1
Tabuľka Ingredients obsahuje potrebné ingrediencie na vytvorenie elixírov v hre, ktoré sú popísané v tabuľke Elixíry. Na vytvorenie elixíru sa používa niekoľko ingrediencií, no každá z nich je pre svoj elixír jedinečná. Práve z tohto dôvodu bol medzi týmito tabuľkami vytvorený vzťah 1: n (one-to-many), ktorý je znázornený v databázovom diagrame (obr. 1).
Tabuľka Ingridients obsahuje aj informácie o názvoch ingrediencií (Discription) a o tom, kde túto ingredienciu nájdete (WhereFind). Stĺpec idElixirs je spojovacím stĺpcom pre tabuľky Ingridientov a Elixírov.
Tabuľka Elixíry obsahuje informácie o tom, ako používať konkrétny elixír a názov tohto elixíru. Táto tabuľka je kľúčová pre ostatné tabuľky.
Tabuľka Locations obsahuje informácie o tom, kde presne alebo blízko ktorého mesta možno nájsť konkrétnu ingredienciu.
Tabuľka IL obsahuje súhrnné informácie o tom, kde a ako nájsť konkrétnu zložku v danej oblasti a čo to je. Medzi tabuľkami Ingridients a Locations bol vytvorený vzťah n:m (many-to-many), pretože viaceré ingrediencie možno nájsť na viacerých miestach, ako je uvedené v IL podradenej tabuľke.
Tabuľka Monsters obsahuje informácie o typoch monštier v
"Witcher 3", o tom, ako rozpoznať konkrétne monštrum a ich charakteristické mená.
Tabuľka ML je podriadená tabuľka asociácie n: m tabuliek Location a Monsters a obsahuje konkrétne informácie o tom, ako poraziť toto konkrétne monštrum a aké elixíry na to možno použiť, vrátane špeciálnych zaklínačských znamení, ako aj v akej oblasti. a na základe čoho hľadať tento konkrétny typ príšery.
Práca s databázou
Databáza Witcher1 obsahuje informácie o tom, aké elixíry použiť proti ktorým príšerám, špeciálne taktiky pre obzvlášť nebezpečné príšery, ako sú: Plague Maiden, Devil, Imp, Goblin atď. Analyzovať informácie z každej tabuľky v poradí bude trvať veľmi dlho, preto vytvoríme špeciálne databázové dotazy, ktoré budú pre používateľa najužitočnejšie.
· Žiadosť o to, ako nájsť konkrétne monštrum.
Tento dotaz bude obsahovať kľúčové slovo JOIN, vďaka ktorému sa sprístupní tabuľky ML a Monsters databázy Witcher1.
Táto žiadosť bude vyzerať takto:
ml PRIPOJTE sa k monštrám NA monsters.idMonsters=ml.idMonsters;
Po vykonaní dotazu dostaneme ako výstup pomerne veľkú tabuľku, ktorá je výsledkom spojenia dvoch tabuliek. Aby výstupná tabuľka nebola taká obrovská, môžete určiť, o ktorej príšere sa majú zobrazovať informácie. To znamená, že napríklad pre Hima bude dotaz vyzerať takto:
monsters.MonstersName, monsters.MonstersDiscription,
ml.DiscriptionHowFind, ml.idLocations
ml PRIPOJTE sa k monštrám NA monsters.idMonsters=ml.idMonsters
where monsters.MonstersName='Hym';
Ktorému monštru zodpovedá to či ono ID, zistíte z dotazu do tabuliek Monsters alebo ML. Žiadosti budú vyzerať takto:
VYBRAŤ VYBRAŤ
IdMonsters, MonstersName idMonsters, MonstersName
OD ml; OD príšer;
Ak chcete skontrolovať zhodu, môžete vyhľadávať v tabuľkách ML aj Monsters tak, že ich najprv spojíte pomocou idMonsters.
ml.idMonsters, monsters.MonstersName
ml PRIPOJTE sa k príšerám ON
ml.idMonsters=monsters.idMonsters
ORDER BY monsters.idMonsters;
· Žiadosť o to, aký elixír je pre toto monštrum vhodný.
Na implementáciu tohto dotazu sa použije JOIN. Dotaz bude adresovaný dvom tabuľkám Elixíry a Monštrá a bude obsahovať informácie o tom, kedy a aký elixír piť v boji proti príšere:
monsters.MonstersName ,elixir.ElixirName,elixir.ElixirDiscription
elixíry PRIPOJTE SA k príšerám
elixirs.idElixirs=monsters.idElixirs;
· Opýtajte sa, ktorá zložka je v konkrétnej lokalite.
Na implementáciu tohto dotazu sa použije JOIN. Dotaz bude odkazovať na dve tabuľky Ingridients a Locations a bude obsahovať informácie o tom, ktorá ingrediencia sa nachádza v ktorej lokalite a informácie o jej type:
ingridients.Disscription, location.Disscription, ingridients.Where Find
ingrediencie PRIPOJTE sa k miestam ON
ingrediencie.idIngridients=locations.idIngridients
OBJEDNAŤ PODĽA prísad.Popis;
· Žiadosti o AKTUALIZÁCIU
Tento dotaz implementujeme pre monštrum v tabuľke Monsters s názvom Hym. Povedzme, že chceme zmeniť jeho meno na Neho:
príšery
SET MonstersName="Him"
kde idMonsters=1;
Ale keďže je Hym v anglickej verzii správny, všetko vrátime späť:
príšery
SET MonstersName="Hym"
kde idMonsters=1;
Obr.2. Implementácia UPDATE dotazov
· žiadosti o agregáciu. COUNT a COUNT (DISTINCT)
Funkcia COUNT počíta počet neprázdnych riadkov (interne bez NULL) v danej tabuľke. COUNT má optimalizovanú verziu na výstup počtu riadkov pri použití pre 1 tabuľku. Napríklad:
Obr.3. Počítanie riadkov v stoloch Elixírov, Monsters a Monsters JOIN elixírov.
Funkcia COUNT(DISTINCT) sa používa na zobrazenie počtu neopakujúcich sa riadkov v tabuľkách a je optimalizovanejšou verziou rodiny funkcií COUNT:
Obr.4. Počítanie neopakujúcich sa elixírov v tabuľke Monsters.
· Funkcia DELETE.
Pridajte ďalší riadok do tabuľky elixírov pomocou INSERT:
INSERT INTO elixir VALUES (6,'ForDelete','DiscriptionDelete');
Obr.5. Pridanie riadka do tabuľky elixírov.
Teraz požiadame o odstránenie tohto riadku, pretože nie je potrebný elixír, ktorý nijako nepomôže v boji proti monštrám:
VYMAZAŤ Z elixírov WHERE idElixirs=6;
Obr.6. Odstrániť pridaný riadok.
Testovanie záťaže databázy
Teraz, keď boli vykonané dotazy a bol zriadený prístup k databáze, je možné ju otestovať niekoľkými spôsobmi:
· Čas odozvy v priebehu času – Tento test zobrazuje informácie pre každú požiadavku, jej priemerný čas odozvy v milisekundách.
· Distribúcia časov odozvy alebo Distribúcia času odozvy - táto kontrola zobrazuje počet odpovedí v konkrétnom časovom intervale, počas ktorého bola požiadavka vykonaná.
· Percentily doby odozvy alebo percentily doby odozvy – Tento test zobrazuje percentily hodnôt doby odozvy. Na grafe budú na osi X percentá, na osi Y bude čas odozvy.
Pre najpravdepodobnejšie testy sme nastavili isté
možnosti:
Obr.7. Možnosti testu
Počet vlákien (používateľov) – Počet virtuálnych používateľov. V našom prípade dáme 1000, aby sme našu databázu načítali čo najviac.
Ramp-Up Period – obdobie, počas ktorého budú zapojení všetci používatelia.
Všetky žiadosti o JOIN skontrolujeme na ich plnenie, keď sú súčasne aktivované viacerými používateľmi.
Posledné 3 body sú plotry tých kontrol, ktorými budeme testovať databázu.
· 
Kontrola časov odozvy v priebehu času
Obr.7. Výsledok vykonania dotazu počas testu Čas odozvy v priebehu času
Ako môžete vidieť z grafu, najťažšia požiadavka bola „Monsters&Locations“ a odpoveď na ňu zabrala najviac času. Dôvod dlhého vykonávania požiadavky môžete overiť vykonaním požiadavky v konzole. Hlavným dôvodom tohto oneskorenia je, že tabuľka Monsters aj tabuľka ML obsahujú zdĺhavé vysvetlenia o príšerách alebo o tom, kde ich nájsť. Z tohto dôvodu sa požiadavka vykonáva pomerne dlho.
· 
Vyšetrenie Distribúcia časov odozvy
Obr.8. Výsledok vykonania dotazu počas testu Distribúcia časov odozvy.
Z tohto grafu môžeme usúdiť, že počet odpovedí na každú našu požiadavku v rovnakom časovom období je rovnaký.
· 
Kontrola percentilov doby odozvy
Os y ukazuje čas vykonania a úsečka ukazuje percento z celkového počtu. Podľa grafu môžeme konštatovať, že 90 % požiadaviek sa vykoná v časovom intervale od 0 do 340 milisekúnd a od 5 % do 15 % sa počet požiadaviek zvyšuje lineárne a potom exponenciálne s veľmi malým faktorom nárastu.
Zvyšných 10 % beží v rozmedzí 340 milisekúnd až 700 milisekúnd, čo naznačuje, že databáza je veľmi zaťažená.
Záver
V tomto kurze boli všetky úlohy splnené. Databáza bola navrhnutá, naplnená údajmi, boli ukázané hlavné možnosti jej využitia formou dotazov a ich výsledky.
Na záver prebehlo testovanie a analýza jeho výsledkov s následnými závermi.
Treba si uvedomiť, že samotná databáza bola vytvorená len ako tréningová, takže nie je taká objemná.
Ďalšou dôležitou charakteristikou je bezpečnosť: heslá, ak je takáto tabuľka vytvorená, musia byť uložené v zašifrovanej podobe a chránené pred neoprávneným prístupom.
Literatúra
1. http://phpclub.ru/mysql/doc/- Internetový zdroj "MySQL - referenčná príručka"
2. Schwartz B., Zaitsev P., Tkachenko V. a ďalší - MySQL. Optimalizácia výkonu (2. vydanie)
3. Thalmann L., Kindal M., Bell C. - "Zabezpečenie vysokej dostupnosti systémov založených na MySQL"
4. Andrzej Sapkowski - "The Witcher (veľká zbierka)", Počet strán: 571
5. CD PROJECT RED, GOG COM. Zaklínač 3: Divoký hon.
Podobné informácie.
Testovanie databázy je potrebné, aby ste sa uistili, že databáza funguje. Na tento účel sa v databáze zostavujú dotazy rôznych typov: na výber, s vypočítanými poľami, parametrické, so zoskupovaním údajov, na aktualizáciu, na vymazanie.
Príklad dotazu: Zobrazte zoznam kníh vypožičaných konkrétnym študentom. Priezvisko nastavené ako parameter.
Príklad dotazu: Zobrazte zoznam kníh od konkrétneho autora s uvedením, kde sú v knižnici uložené. Ako parameter nastavte meno autora.
Príklad požiadavky: Podľa čísla čitateľského preukazu určte, v ktorej triede príslušný žiak študuje a kto je jeho triednym učiteľom.
Ryža. 15. Žiadosť 3. „Vyhľadajte študenta podľa čísla čitateľského preukazu a určte, v ktorej triede študuje“
Príklad žiadosti: Určite podľa celého mena žiaka, v ktorej triede sa dlžník učí a kto je jeho triednym učiteľom.
Pre pohodlie práce so záznamami rôznych tabuliek bol vytvorený, pomocou ktorého môžete otvoriť ľubovoľnú tabuľku, ktorú potrebujete na zobrazenie, aktualizáciu a zmenu informácií. Tlačidlo je znázornené na obr. 17.
Ryža. 17. Formulár tlačidla databázy
ZÁVER
Záverečná kvalifikačná práca bola robená na aktuálnu tému „Vývoj informačného systému pre vidiecku školskú knižnicu“.
Cieľ diplomového projektu vytvoriť informačný systém pre školskú knižnicu regiónu Saratov, okres Fedorovský, strednú školu MOU, obec Solnechnyj, bol splnený.
Počas realizácie absolventského projektu sa riešili nasledovné úlohy:
Považujte knižnicu za prvok vzdelávacieho prostredia;
Preštudovať vládnu koncepciu podpory a rozvoja detského čítania;
Analyzujú sa technológie práce knižníc vzdelávacích inštitúcií;
Predmetná oblasť je popísaná na základe uskutočneného prieskumu;
-boli vypracované zadávacie podmienky pre rozvoj informačného systému pre knižnicu vidieckej školy;
- bol vybudovaný funkčný model školskej knižnice;
- popis vstupných a výstupných informačných tokov;
bol vyvinutý informačný systém založený na DBMSpríless;
- bola otestovaná vyvinutá relačná databáza.
V záverečnej kvalifikačnej práci na vybudovanie informačného systému, ktorý zautomatizuje manuálne operácie na zabezpečenie procesov skladovania, vyhľadávania, účtovania výdaja a vrátenia študentmi, na základe analýzy výsledkov prieskumu predmetnej oblasti, je stanovený termín bola vyvinutá referencia. Zadávacie podmienky (TOR) odrážali požiadavky používateľov systému – knihovníkov.
Na základe TOR bol vypracovaný funkčný model činnosti vidieckej školskej knižnice. Funkčný model zase slúžil ako materiál na identifikáciu neautomatizovaných oblastí v práci knižnice.
Výber DBMS ako vývojového prostredia bol určený technickými možnosťami vidieckej knižnice. V dôsledku toho na základe DBMS Prístupbolo vybudované jadro informačného systému – databáza.
Pre pohodlie používateľov bolo vyvinuté tlačidlové rozhranie.
Na testovanie databázy boli vyvinuté zodpovedajúce dotazy. Splnenie týchto požiadaviek nám umožňuje posúdiť bežný výkon informačného systému pre vidiecku školskú knižnicu.
LITERATÚRA
