Virtuálny futbal: algoritmy a simulácia hry futbalových robotov. Vytvorenie databázy „Futbalové kluby

Odoslanie dobrej práce do databázy znalostí je jednoduché. Použite nižšie uvedený formulár

Študenti, postgraduálni študenti, mladí vedci, ktorí pri štúdiu a práci využívajú vedomostnú základňu, vám budú veľmi vďační.

Hostené na http://www.allbest.ru/

Ministerstvo školstva a vedy Ukrajiny

Štátna technologická univerzita v Chernihiv

Katedra informačných a počítačových systémov

Softvérový systém "Futbalové majstrovstvá"

Kurz v disciplíne "Organizácia databáz"

Dokončené

študenti gr. KI-104A.G. Voitsekhovský

A.G. Raj

Dozorca

Asistent M.V. Charčenko

Chernihiv 2013

abstraktné

Kurz, 86 s., Obr. 21, 9 zdrojov, 2 aplikácie.

Účelom vypracovania práce na kurze je implementácia aplikácie, ktorá vám umožní pracovať s databázou ako cez tenkého klienta, tak aj cez desktopovú aplikáciu.

Hlavnou metódou navrhovania aplikačných modulov je použitie diagramov UML. Za prítomnosti licencovaného softvéru tak bolo možné exportovať vyvinuté triedy do prostredia Eclipse EE.

V procese písania aplikácie boli vyvinuté a vytvorené dve továrne DAOTourFirma a ServiceTourFirma na prácu s entitami. S pomocou ServiceTourFirma bola dodatočne implementovaná obchodná logika.

Použitá bola aj technológia kontajnerov Servlet a JSP. Keďže servlety a stránky jsp sa vyvolávajú cez protokol HTTP, kontajner Servlet a kontajner JSP sú často sprevádzané ďalším komponentom, webovým serverom, ktorý môže byť tiež napísaný v jazyku Java.

Server bol Tomcat 6.0. Aplikácia bola vyvinutá pomocou JDK verzie 1.7.

V priebehu tejto práce na kurze bol na prácu s databázou použitý PostgerSQL 9.0 DBMS. Bola vytvorená databáza, ktorá pozostáva z 9 tabuliek. V každej tabuľke je jedinečný primárny kľúč cudzí kľúč. Toto je dodatočné pole služby pridané k existujúcim informačným poliam tabuľky, ktorého jediným účelom je slúžiť ako primárny kľúč. Hodnoty tohto poľa nie sú tvorené na základe žiadnych iných údajov z databázy, ale sú generované umelo. Hlavnou výhodou cudzieho kľúča je, že sa nikdy nemení, pretože nejde o informatívne pole tabuľky.

Firemná aplikácia „Football Championship“ sa v priebehu vývoja dostala na úroveň stabilnej verzie. Výsledok vývoja je prezentovaný vo forme softvérového projektu, ktorý je uvedený v prílohe práce kurzu.

Firemná aplikácia na svoju činnosť vyžaduje minimum: 1024 MB RAM, procesor aspoň Atom 1100 MHz a ľubovoľný prehliadač. Požiadavky na operačný systém - Windows, Unix.

Ďalší rozvoj práce je možný v smere zlepšovania práce na reláciách.

abstraktné

Kurz, 86 str., 21 kresieb, 9 dzherel, 2 doplnky.

O "vývoji" je podnikový program, ktorý vám umožňuje pracovať s databázou, a to ako za pomoci tenkého klienta, tak aj za pomoci webových služieb.

Hlavnou metódou navrhovania programových modulov je použitie UML - diagramov. Týmto spôsobom, s prítomnosťou licencovaného softvéru, je možné exportovať rozbitú triedu v Eclipse EE.

V procese písania programu boli rozšírené a vytvorené dve továrne DAOTourFirma a ServiceTourFirma pre prácu s entitami. S pomocou ServiceTourFirma bola dodatočne implementovaná obchodná logika.

Zrodila sa tiež technológia kontajnera Servlet a JSP. Keďže servlety a JSP komunikujú cez protokol HTTP, kontajner Servlet a kontajner JSP sa často dodávajú s ešte jedným komponentom, webovým serverom, ktorý môže byť napísaný aj v jazyku Java.

V kapacite servera je server Tomcat 6.0. Program bol distribuovaný s verziou JDK 1.7.

V priebehu tejto práce na kurze bol testovaný PostgerSQL 9.0 DBMS na prácu s databázou. Bola vytvorená databáza, ktorá pozostáva z 9 tabuliek. V tabuľke vzhľadov sa volá jedinečný primárny kľúč. Tse dodatkove pole služby, pridané k už zrejmým informačným poliam tabuľky, jediné rozpoznanie tohto - slúži ako primárny kľúč. Hodnoty tohto poľa nie sú nastavené na základe žiadnych iných údajov z databázy, ale sú generované individuálne. Šmrncovná dôstojnosť pôvodného kľúča spočíva v tom, že víno nie je nijako zmenené, črepy nie sú informatívnym poľom tabuľky.

V priebehu vývoja bol firemný program „Futbal Championship“ zrušený, keďže bol dovedený na úroveň stabilného vydania. Výsledok vývoja je zarámovaný vo forme softvérového projektu, ktorý by mal byť pridaný k práci kurzu.

Pre jeho robotický firemný program je minimálna požiadavka: 1024 MB RAM, procesor nie nižší ako Atom 1100 MHz a ľubovoľný prehliadač. Wimogi do operačného systému - Windows, Unix.

Ďalší rozvoj projektu by mohol viesť k lepšej práci s reláciami.

Java, C#, ORM, JSP, JPA, SQL, Servlet, HTML, TAG, JS

Abstrakt

Projekt kurzu, 86 s., obr. 21, 9 zdrojov, 2 v prílohe.

Cieľom je vyvinúť aplikáciu, ktorá vám umožní pracovať s databázou ako cez tenkého klienta alebo cez desktopovú aplikáciu.

Základná metóda navrhovania aplikačných modulov - použitie UML - diagramov. Ak by sa teda dal vyvinúť softvér na export tried v prostredí Eclipse EE.

Počas písania aplikácií boli vyvinuté a zriadené dve továrne DAOTourFirma a ServiceTourFirma pre spoluprácu s entitami. S ServiceTourFirma bola ďalej implementovaná obchodná logika.

V priebehu kurzu práce na obsluhu databázy využívali DBMS PostgerSQL 9.0. Databáza, ktorá pozostáva z 9 tabuliek. V každej tabuľke je jedinečný primárny kľúč externý. Toto je voliteľné pole služby pridané k už existujúcim informačným poliam tabuľky, ktorého jediným účelom je slúžiť ako primárny kľúč. Hodnoty tohto poľa nie sú tvorené na základe žiadnych iných údajov z databázy a sú generované umelo. Hlavnou výhodou cudzieho kľúča je, že sa nikdy nemení, pretože ide o informatívne pole tabuľky.

Tiež bola použitá technológia a Servlet-JSP-kontajner. Pretože servlety a jsp-stránky sa vyvolávajú cez HTTP-protokol, Servlet-JSP-container a kontajner je často sprevádzaný ďalším komponentom – web-serverom, ktorý môže byť napísaný aj v Jave.

Počas vývoja podnikových aplikácií boli prijaté "Futbal championat" posunuté na úroveň beta. Výsledok vypracovania formy softvérového projektu, obsiahnutý v prílohe práce kurzu.

Pre svoju firemnú aplikáciu vyžaduje minimum: 1024 MiB RAM, CPU nie je Atom pod 1100 MHz a prehliadač. Požiadavky na operačný systém - Windows, Unix.

Ďalšie vývojové práce sú možné na zlepšenie práce s reláciou.

Java, C#, ORM, JSP, JPA, SQL, Servlet, HTML, TAG, JS

Úvod

1. Analýza riešeného problému

1.1 Analýza domény

1.2 Ciele a ciele systému

1.3 Účel systému

1.4 Systémové požiadavky

2. Dizajn

2.1 Výber nástrojov na vývoj systému

2.1.1 Databázový server

2.1.2 Technológie implementácie systému

2.2 Návrh architektúry systému

2.2.1 Návrh vrstvy obchodnej logiky a obchodných pravidiel

2.2.2 Návrh vrstvy prístupu k údajom

2.2.3 Návrh vrstvy zobrazenia

3. Vývoj

3.1 Vývoj databázy systému

3.1.1 Návrh schémy databázy

3.1.2 Zabezpečenie integrity údajov

3.1.3 Vytváranie základných dopytov

3.1.4 Vytváranie rolí, výber indexov a zobrazení

3.1.5 Vývoj uložených procedúr a spúšťačov

3.1.6 Organizácia ochrany údajov

3.1.7 Objektovo-relačné mapovanie

3.2 Vývoj modulov systému

3.2.1 Vývoj modulov vrstvy obchodnej logiky a obchodných pravidiel

3.2.2 Vývoj modulov vrstvy prístupu k dátam

3.2.3 Vývoj modulov servisnej vrstvy

3.2.4 Vývoj modulov zobrazovacej vrstvy

Zoznam použitých zdrojov

Úvod

V súčasnosti sa počítače a internetové technológie rozšírili vo všetkých sférach ľudskej činnosti. Použitie výpočtovej techniky je spôsobené tým, že výrazne uľahčuje prácu človeka, pričom urýchľuje čas na dokončenie úlohy a zvyšuje spoľahlivosť výsledku. Keďže výpočtová technika pracuje pod softvérovou kontrolou, jej funkčnosť závisí od použitého softvéru. Preto vznikajú rôzne podnikové aplikácie úzkej špecializácie.

Návrh databázy (DB) je jednou z najzložitejších a najzodpovednejších úloh spojených s tvorbou podnikovej aplikácie (podnikovej aplikácie). Na základe jeho rozhodnutia by sa mal určiť obsah databázy, efektívny spôsob organizácie údajov pre všetkých jej budúcich používateľov a nástroje na správu údajov. Hlavným cieľom návrhu databázy je znížiť redundanciu uložených údajov, a teda ušetriť množstvo použitej pamäte, znížiť náklady na viacnásobnú aktualizáciu redundantných kópií a eliminovať možnosť nekonzistentnosti v dôsledku ukladania informácií o rovnakom objekte do rôznych Miesta.

Firemná aplikácia je softvérová aplikácia určená na správu veľkých objemov dát a ich spracovanie podľa obchodných pravidiel, čo umožňuje spoločnosti (podniku) pri jej implementácii priniesť určité výhody.

Podniková aplikácia nezahŕňa spracovanie textu, palivové hospodárstvo automobilových motorov, ovládanie výťahových a telefónnych ústrední, automatické riadenie chemických procesov, ako aj operačné systémy, kompilátory, hry atď. Podniková aplikácia zvyčajne zahŕňa potrebu dlhodobého (niekedy desaťročia) ukladania údajov. Údaje sú často schopné prežiť generácie aplikácií na spracovanie údajov, hardvéru, operačných systémov a kompilátorov.

Mnoho používateľov pristupuje k dátam paralelne. Ich počet spravidla nepresahuje sto, ale v prípade systémov hostených na webe sa toto číslo zvyšuje o niekoľko rádov.

Pri veľkom objeme dát musí aplikácia poskytovať bohaté používateľské rozhranie.

Podnikové aplikácie zriedka existujú izolovane. Zvyčajne vyžadujú integráciu s inými systémami vytvorenými v rôznych časoch pomocou rôznych technológií.

Podnikové aplikácie bývajú zložité softvérové ​​systémy .

1. Analýza riešeného problému

1.1 Analýza domény

Futbalový šampionát - futbalová súťaž. Tento typ súťaže sa koná každý rok. Počas šampionátu sa konajú zápasy medzi rôznymi tímami, ktorých výsledky sa zaznamenávajú do poradia určitého kvalifikačného kola. Ďalším krokom šampionátu je uskutočnenie finálového kola, ktorého zoznam zúčastnených tímov je zostavený z víťazov kvalifikačných kôl. Keď sa odohrajú všetky zápasy finálového kola, na základe informácií o počte získaných bodov môžete určiť víťaza šampionátu.

Futbalový šampionát je masové podujatie, čo zase naznačuje potrebu určitého vnútorného mechanizmu, ktorý by koordinoval jeho priebeh. Tak možno vyčleniť najvyšší výkonný orgán – výkonný výbor, ktorý preberá plnú zodpovednosť za organizáciu a priebeh šampionátu. Skladá sa z prezidenta a ďalších členov zvolených kongresom (najvyšším riadiacim orgánom určitého futbalového zväzu) šampionátu. Kongres sa koná každoročne. Výkonný výbor môže iniciovať druhý riadny kongres na riešenie finančných záležitostí a/alebo záležitostí vyššej dôležitosti.

Funkčné obdobie prezidenta a členov výkonného výboru volených Kongresom je pevne stanovený počet rokov. Všetci členovia výkonného výboru môžu byť zvolení opätovne. Len veľmi starí funkcionári nemôžu byť zvolení ani znovuzvolení. Ak sa uvoľní miesto vo výkonnom výbore, najbližší riadny kongres zvolí náhradníka do konca aktuálneho funkčného obdobia. Ak sa miesto člena výkonného výboru uvoľní v poslednom roku funkčného obdobia, náhrada sa nevyberá.

Funkčné obdobie prezidenta a členov výkonného výboru sa začína uplynutím kongresu, na ktorom sú volení, a končí uplynutím kongresu, na ktorom je zvolený jeho nástupca. Menovanie ženy za členku výkonného výboru na štyri roky sa robí na ustanovujúcom zasadnutí výkonného výboru.

Výkonný výbor je oprávnený schvaľovať predpisy a rozhodovať o všetkých záležitostiach, ktoré nespadajú do jurisdikcie. Výkonný výbor riadi činnosť konkrétneho futbalového zväzu, s výnimkou prípadov, keď výkonný výbor delegoval právomoc - alebo bola delegovaná zakladateľskou listinou - na prezidenta alebo správu futbalového zväzu.

Výkonný výbor môže delegovať zodpovednosť za prípravu a vykonávanie rozhodnutí alebo za vedenie určitých záležitostí na jedného alebo viacerých svojich členov. Výkonný výbor je tiež oprávnený delegovať právomoci – úplne alebo čiastočne – na prezidenta, jedného alebo viacerých svojich členov a/alebo administratívu.

Výkonný výbor zasadá spravidla každé dva mesiace na zvolanie prezidenta. Prezident môže na zasadnutie výkonného výboru prizvať aj tretie osoby ako poradcov.

1.2 Ciele a ciele systému

Cieľom systému Football Championship je automatizovať proces konania majstrovstiev. Táto aplikácia je informatívna: umožňuje vám automatizovať výpočet počtu výhier, prehier a remíz, ako aj prideľovanie bodov tímom v súlade s výsledkami zápasu (3 body - výhra, 2 - remíza, 1 - prehra ). Aplikácia umožňuje pomocou vstupno-výstupných formulárov pridávať nové, mazať a meniť údaje turnajovej tabuľky. Je možné zobraziť údaje o zamestnancoch a tímoch, ako aj zobraziť 10 najlepších tímov a výsledky zápasov, ktoré sa hrali v aktuálny deň.

1.3 Účel systému

Systém Football Championship vyvinutý v rámci tohto projektu kurzu je určený pre všetkých užívateľov, ktorých zaujímajú výsledky odohraných zápasov. Autorizácia sa v našom systéme nezdieľa. Hosť sa nemusí prihlásiť, ale jednoducho sa prihlási a zobrazí informácie o šampionáte. Manažér, prezident a správca musia zadať osobné údaje, ktoré sa majú určiť v systéme. Osobnými údajmi sa rozumie prihlasovacie meno a heslo. Po potvrdení zadaných údajov používateľom softvérový systém skontroluje ich platnosť. Najprv sa skontroluje prihlásenie, ak sa nenájde v databáze, systém zobrazí hlásenie, že neexistuje používateľ s týmto menom. Ak je názov správny, skontroluje sa kontrolný súčet hesla. Ak sa nezhoduje, heslo je nesprávne. Pre väčšiu bezpečnosť systému sa po výpočte kontrolného súčtu skontroluje zhoda celého hesla. Ak sú používateľské meno a heslo autentické a vhodné a ide o pár hodnota-kľúč, používateľ sa prihlási a je mu priradený status prezidenta, správcu alebo manažéra.

Obrázok 1.1 je diagram prípadov použitia pre rolu prezidenta šampionátu.

Obrázok 1.1 - Schéma prípadov použitia pre úlohu prezidenta šampionátu

Po prihlásení má prezident tieto možnosti: personálny manažment a rozpočtovanie.

Prípad použitia „riadenia ľudských zdrojov“ zahŕňa pridanie záznamu o novom zamestnancovi a pri prepustení zamestnanca vymazanie zodpovedajúceho záznamu. Prípad použitia zostaviť rozpočet zahŕňa pridávanie a odstraňovanie záznamov miezd.

Obrázok 1.2 je diagram prípadov použitia pre rolu Správca

Obrázok 1.2 - Schéma prípadov použitia pre rolu Správca

Po prihlásení má administrátor tieto možnosti: spravovať účty a kontrolovať správu v databáze.

Prípad použitia "Spravovať účty" má nasledujúci scenár: Ak ide o pridávanie nového používateľa, vyplňte príslušný vzorec a uložte zmeny; ak sa jedná o zmenu alebo vymazanie užívateľa, tak ho musíte najskôr nájsť v databáze, pri vymazaní zničiť užívateľské údaje, pri zmene opraviť a uložiť.

Obrázok 1.3 je diagram prípadu použitia pre rolu manažéra.

Obrázok 1.3 - Schéma prípadov použitia pre rolu Manažér

Manažér má po prihlásení nasledovné možnosti: vypĺňať, mazať alebo prezerať záznamy v rebríčku.

Obrázok 1.4 je diagram prípadu použitia pre rolu hosťa.

Obrázok 1.4 - Schéma prípadov použitia pre rolu Hosť

Po stiahnutí aplikácie si hosť môže pozrieť poradie, zistiť informácie o zápasoch a tímoch.

1.4 Požiadavky na systém

Systém futbalových majstrovstiev vyvinutý v rámci tohto kurzu by mal fungovať s nasledujúcimi objektmi: krajina, zápas, zamestnanec, turnaj. Je potrebné vyvinúť taký systém, v ktorom by sa užívateľ mohol registrovať a upravovať potrebné informácie.

Na objekty a pravidlá interakcie medzi objektmi v systéme sú uložené určité obmedzenia, ktorých súhrn sa nazýva obchodná logika.

Podľa obchodnej logiky systému je potrebné implementovať: automatické prideľovanie bodov tímom v závislosti od výhry, prehry alebo remízy v danom zápase.

2. Dizajn

2.1 Výber nástrojov na vývoj systému

V tomto bode sa vyberie databázový server, cez ktorý bude užívateľ komunikovať s databázou, zvolí sa technológia implementácie systému a architektúra.

2.1.1 Databázový server

V súčasnosti existuje veľké množstvo databázových serverov ako MySQL, PostgreSQL, Microsoft Access a iné.

PostgreSQL je objektovo-relačný databázový systém, ktorý funguje ako systém klient-server. Na základe základných konceptov relačných databáz PostgreSQL podporuje aj množstvo „objektových“ operácií, ako je napríklad dedičnosť. PostgreSQL je v súlade so základnou špecifikáciou SQL99 a podporuje mnohé z funkcií popísaných štandardom SQL92.

Oracle je o niečo lepší ako PostgreSQL v takých záležitostiach, ako je používanie indexov, replikácia a obnova údajov a nástroje na správu vo všeobecnosti. Oracle je pokročilejší (ale aj zložitejší). Na druhej strane PostgreSQL poskytuje možnosť použiť ako procedurálny jazyk okrem PL/pgSQL (veľmi podobný PL/SQL používanému v Oralce), tiež PL/Perl, PL/Python, PL/Tcl, čo umožňuje vývojárovi vybrať známy nástroj.

V MySQL je každá tabuľka uložená vo svojom vlastnom súbore (pre väčšinu typov databáz), ktorý organizuje štruktúru jedného súboru.

V MySQL je kladený dôraz na čo najlepšiu rýchlosť čítania (výberu) dát, čo vysvetľuje obľúbenosť tohto DBMS vo webovom vývojovom prostredí, kde je výber hlavnou operáciou. Dosahuje sa to absenciou transakcií (sú implementované len pre niektoré typy tabuliek, napr. InnoDB, BerkleyDB) a viacvláknovou prácou, čo je však aj dôvodom o niečo nižšej spoľahlivosti tohto DBMS. Čo sa týka oprávnení, MySQL umožňuje nastaviť oprávnenia nielen na úrovni tabuľky, ale aj na úrovni stĺpcov, no v PostgreSQL je to kompenzované možnosťou vytvárať vlastné pohľady.

Apache Derby je relačný DBMS napísaný v jazyku Java navrhnutý tak, aby bol vložený do aplikácií Java alebo spracovával transakcie v reálnom čase. Na disku zaberá 2 MB. Apache Derby je vyvinutý ako open source a distribuovaný za podmienok licencie Apache 2.0. Derby bolo predtým známe ako IBM Cloudscape. Sun distribuuje rovnaké binárne súbory pod názvom Java DB.

V tejto kurzovej práci bol použitý PostgreSQL - databázy, ktoré vyžadujú vysoký stupeň spoľahlivosti ukladania informácií, majú zvýšené požiadavky na kontrolu všetkých zmien, majú potrebu automaticky opravovať veľké množstvo údajov pri zmene informácií v niektorej z tabuliek, napr. aj úlohy, ktoré vyžadujú schopnosť vyvíjať netriviálne riešenia, používanie neštandardných operátorov atď.

2.1.2 Technológie implementácie systému

JSP (JavaServer Pages) je technológia, ktorá umožňuje webovým vývojárom jednoducho vytvárať obsah, ktorý má statické aj dynamické komponenty. Stránka JSP je v podstate textový dokument, ktorý obsahuje dva typy textu: statické zdrojové údaje, ktoré môžu byť v jednom z textových formátov HTML, SVG, WML alebo XML, a prvky JSP, ktoré vytvárajú dynamický obsah. Na vloženie kódu Java do statického obsahu stránok JSP je navyše možné použiť knižnice značiek JSP, ako aj jazyk EL (Expression Language).

JSP je jednou z vysoko výkonných technológií, pretože všetok kód stránky je preložený do kódu java servletu pomocou kompilátora JSP stránky Jasper a potom skompilovaný do bytekódu java virtual machine (JVM). Kontajnery servletov schopné spúšťať stránky JSP sú napísané v jazyku Java, ktorý môže bežať na rôznych platformách. Stránky JSP sú načítané na server a spravované zo špeciálnej štruktúry paketov Java servera nazývanej Java EE Web Application, väčšinou zabalené v archívoch súborov .war a .ear.

Výhodou JSP oproti iným webovým technológiám je, že JSP je platformovo nezávislá, prenosná a ľahko rozšíriteľná technológia na vývoj webových aplikácií.

JSP 2.0 je nová verzia špecifikácie JSP s pridanou funkcionalitou, ktorá zvyšuje rýchlosť programátora. menovite:

– Expression Language (EL) -- vyjadrovací jazyk, ktorý okrem iného umožňuje vývojárom vytvárať šablóny v štýle Velocity;

- jednoduchší a rýchlejší spôsob vytvárania nových značiek pomocou súborov .tag, teraz na vytváranie nových značiek nepotrebujete poznať Javu;

– pohodlný spôsob spravovania vnorených fazúľ (JavaBeans);

– rýchlejší a jednoduchší spôsob zobrazenia premenných parametrov.

Servlet je rozhranie Java, ktorého implementácia rozširuje funkčnosť servera. Servlet interaguje s klientmi prostredníctvom princípu požiadavka-odpoveď.

Hoci servlety môžu obsluhovať akúkoľvek požiadavku, bežne sa používajú na rozšírenie webových serverov. Pre takéto aplikácie technológia Java Servlet definuje triedy servletov špecifické pre HTTP.

JSTL (JavaServer Pages Standard Tag Library) – v preklade z angličtiny „JSP Standard Tag Library“. Rozširuje špecifikáciu JSP pridaním knižnice značiek JSP pre bežné potreby, ako je analýza údajov XML, podmienené spracovanie, cyklovanie a podpora internacionalizácie. JSTL je konečným výsledkom JSR 52 vyvinutého v rámci JCP (Java Community Process).

JSTL je alternatívou k tomuto druhu vstavanej logiky JSP, ako sú skriptlety, teda priame vkladanie kódu Java. Použitie štandardizovanej sady značiek je vhodnejšie, pretože výsledný kód sa ľahšie udržiava a je jednoduchšie oddeliť obchodnú logiku od logiky zobrazenia.

Java Persistence API (JPA) – Od verzie Java 5 je súčasťou Java 5 v platformách Java SE a Java EE a poskytuje možnosť pohodlne uchovávať Java objekty v databáze.

Existuje niekoľko implementácií tohto rozhrania, jedna z najpopulárnejších na to používa Hibernate.

Poskytuje sa podpora uchovávania údajov JPA, pokrýva oblasti:

- priamo API špecifikované v balíku javax.persistence;

– objektovo orientovaný dotazovací jazyk nezávislý na platforme Java Persistence Query Language;

– metainformácie popisujúce prepojenia medzi objektmi;

– generovanie DDL pre entity.

2.2 Návrh architektúry systému

servlet modulu databázy vrstvy

Architektúra systému bude taká, ako je znázornená v analýze (obrázok 1.1) a metódy na riešenie problému.

Úlohou integračnej vrstvy (vrstvy zdroja údajov) je umožniť aplikácii interakciu s rôznymi komponentmi infraštruktúry, aby mohla vykonávať potrebné funkcie. Hlavná zložka takéhoto problému súvisí s udržiavaním dialógu s databázou – vo väčšine prípadov relačného. Jedným z najväčších dôvodov úspechu relačných systémov je ich podpora pre SQL, najviac štandardizovaný jazyk na komunikáciu s databázou.

Spôsob implementácie integračnej vrstvy závisí od toho, ako obchodná logika interaguje s databázou. Rozhodnutia prijaté v tejto fáze majú ďalekosiahle dôsledky a môže byť ťažké alebo dokonca nemožné ich zvrátiť.

Preto si zaslúži čo najdôkladnejšie zváženie. Takéto rozhodnutia často určujú možnosti rozloženia obchodnej logiky.

Je zmysluplnejšie izolovať kód SQL od obchodnej logiky umiestnením do špeciálnych tried. Dobrým spôsobom, ako organizovať tieto triedy, je „skopírovať“ štruktúru každého databázového objektu do samostatnej triedy, ktorá tvorí bránu podporujúcu možnosti prístupu k tabuľkám. Teraz hlavný aplikačný kód nemusí nič „vedieť“ o SQL a všetky operácie SQL sú sústredené v kompaktnej skupine tried. Lepšou možnosťou je izolovať doménový model od databázy a ponechať strednú vrstvu výhradne zodpovednú za mapovanie doménových objektov na databázové objekty. Takýto prevodník údajov spracováva všetky operácie načítania a ukladania informácií iniciované obchodnou logikou a umožňuje vám nezávisle meniť model domény aj schému databázy. Ide o najkomplexnejšie architektonické riešenie, ktoré poskytuje korešpondenciu medzi objektmi aplikácie a relačnými štruktúrami, ale jeho nesporná výhoda spočíva v úplnej izolácii týchto dvoch vrstiev.

K dnešnému dňu môžu vývojári Java využívať nástroje, ktoré sú už k dispozícii: serializáciu, objektovo-relačné mapovacie nástroje, databázy objektov a EJB. Každý z týchto nástrojov má svoje vlastné oblasti použitia, a preto má určité nevýhody. JDO rieši tieto nedostatky a poskytuje väčšiu transparentnosť.

Serializácia. Vstavaný nástroj Java, ktorý konvertuje objekty na sekvenciu bajtov, ktoré možno uložiť do súboru alebo preniesť cez sieť. Serializácia je veľmi jednoduchá na použitie, ale aj dosť obmedzená. Pri použití serializácie je objekt uložený ako jedna entita. Nepodporuje transakcie, rovnako ako použitie rovnakého serializovaného objektu v rôznych vláknach alebo programoch bez konfliktov medzi nimi;

Objektovo-relačné mapovanie (JPA). JPA nie je nová technológia, ale skôr zbierka nápadov z najlepších dostupných technológií ako Hibernate, TopLink a JDO. Výsledkom je, že JPA je štandardizovaná špecifikácia zahrnutá v J2EE5, ktorá vám umožňuje vybudovať vrstvu perzistencie údajov nezávislú od akýchkoľvek konkrétnych poskytovateľov. Tie. Môže existovať veľa implementácií špecifikácie JPA, jednou z nich je napríklad rámec OpenJPA alebo rovnaký Hibernate.

Objektové databázy. Objektové databázy boli špeciálne navrhnuté na ukladanie objektov a dokonale zapadali do konceptu objektovo orientovaného programovania. Skupina Object Database Management Group (ODMG) bola vytvorená s cieľom vyvinúť jednotné API pre prácu s takýmito databázami. Mnohí predajcovia databáz však stále váhajú, či prejsť zo zabehnutého relačného systému na objektovo orientovaný. Pre objektové bázy je tiež k dispozícii menej nástrojov na analýzu údajov a v relačných databázach je už uložené veľmi veľké množstvo údajov. Z týchto a mnohých ďalších dôvodov neboli databázy objektov tak široko používané, ako ich tvorcovia dúfali;

Enterprise Java Beans (EJB). EJB sú beans, ktoré ukladajú svoj stav v relačnej databáze a poskytujú objektovo orientovaný pohľad na perzistentné údaje. Na rozdiel od produktov objektovo-relačného mapovania majú EJB pevnú špecifikáciu, ktorá umožňuje používať produkty od rôznych predajcov. Bohužiaľ, štandard EJB je obmedzený z hľadiska objektovo orientovaného. Nepodporujú dedičnosť, polymorfizmus atď. Komponenty EJB sú tiež drahé na zápis a často vyžadujú špeciálny softvér na ich spustenie.

K dnešnému dňu existujú rôzne rámce, ktoré používajú túto programovaciu techniku. Tu sú niektoré z nich:

Hibernate, iBATIS, Java Data Objects (JDO), JPOX, Cayenne, TopLink, JPA.

Pri organizovaní ORM pomocou rôznych technológií je potrebné vytvoriť súbory mapovania objektov; vytvorte konfiguračné súbory, ktoré špecifikujú zdrojové súbory, zdroje údajov, podporu transakcií atď.

2.2.1 Navrhovanie vrstvy obchodnej logiky a obchodných pravidiel

Ako tento systém funguje:

Správca zadáva údaje o zamestnancoch, majstrovstvách, tímoch;

Používatelia si prezerajú poradie a informácie o majstrovstvách;

Registrácia nie je povinná, je potrebná len na úpravu údajov;

Na implementáciu vzťahu many-to-many bola vytvorená ďalšia tabuľka. zakaz_dop_uslugi (spája objednávku s doplnkovými službami).

Preto je možné navrhnúť také triedy domén (obrázok 2.4).

Obrázok 2.4 - Triedy domén

Podľa obchodnej logiky systému je potrebné automaticky prideľovať body za prehry, výhry a remízy, resp.

2.2.2 Návrh dátovej prístupovej vrstvy

Na prístup k údajom uloženým v externom úložisku je najvhodnejšie definovať samostatné rozhrania s metódami manipulácie s údajmi. Implementácia týchto rozhraní môže byť ľubovoľná, napríklad pomocou JDBC alebo JPA, JAXB alebo aj jednoduchých kolekcií Java. JPA bol vybraný ako realizácia tohto projektu kurzu. Aby bolo možné použiť rôzne implementácie rozhraní pre prístup k údajom, je vhodné použiť návrhový vzor „Abstract Factory“ alebo „Factory Method“. V tomto prípade je takouto továrňou abstraktná trieda DAOFactory, ktorá obsahuje definíciu abstraktných metód, ktoré vracajú implementácie rozhrania (obrázok 2.4).

Medzi všetkými operáciami prístupu k údajom možno jasne rozlíšiť základné operácie CRUD (create, read, update, delete) - vytvorenie objektu, vymazanie objektu, aktualizácia objektu, získanie objektu podľa identifikátora a získanie všetkých objektov. Zaradením takýchto operácií do samostatnej supertriedy sa vyhnete duplicite kódu. Takéto základné operácie boli tiež presunuté do samostatného základného rozhrania IGenericDao , ktorý vám pomocou Java Generics umožňuje určiť triedu objektov, s ktorými budete pracovať.

Obrázok 2.4 - Diagram triedy DAO

2.2.3 Navrhovanie zobrazovacej vrstvy

Táto vrstva je tenký klient.

Pre prácu s aplikáciou boli vytvorené stránky, ktoré poskytujú výstup, pridávanie, úpravu a mazanie dát. Hlavná stránka, na ktorú sa dostane neregistrovaný používateľ, index.jsp. Boli vytvorené aj ďalšie stránky na pridávanie a úpravu údajov, avšak len s administrátorskými právami.

3. Vývoj

3.1 Vývoj databázy systému

3.1.1 Návrh schémy databázy

Na základe analýzy, návrhu vrstvy obchodnej logiky a pravidiel je možné vytvoriť štruktúru databázy nasledovne (obrázok 3.1)

Obrázok 3.1 - Logická schéma databázy

Fyzická schéma databázy je znázornená na obrázku 3.2

Obrázok 3.2 - Fyzická schéma databázy

Databáza softvérového systému obsahuje všetky informácie o jeho objektoch, a to:

Turnajová tabuľka;

tímy;

Používateľ;

zamestnanec;

plat;

majstrovstvá.

V každej tabuľke je jedinečný primárny kľúč cudzí kľúč. Toto je dodatočné pole služby pridané k existujúcim informačným poliam tabuľky, ktorého jediným účelom je slúžiť ako primárny kľúč. Hodnoty tohto poľa nie sú tvorené na základe žiadnych iných údajov z databázy, ale sú generované umelo. Hlavnou výhodou cudzieho kľúča je, že sa nikdy nemení, keďže nejde o informatívne pole tabuľky (nenesie žiadnu informáciu o objekte popísanom záznamom). Má zmysel použiť cudzí kľúč, keď sú možné zmeny v poliach, ktoré tvoria (prirodzený) primárny kľúč. V tomto prípade vzniká problém takzvaných „kaskádových zmien“. Ak používate cudzí kľúč ako primárny kľúč, nebudete ho musieť meniť. Taktiež pri vykonávaní dotazov, ktoré používajú cudzie kľúče, bude porovnávanie polí rýchlejšie, najmä ak je prirodzený primárny kľúč reťazec.

3.1.2 Zabezpečenie integrity údajov

Obmedzenia integrity sú uvedené v tabuľke 3.1

Tabuľka 3.1 - Popis databázových tabuliek

3.1.3 Vytváranie základných dopytov

Pri vývoji základných dotazov bol ako vývojový jazyk zvolený JPQL.

Nižšie je uvedený popis hlavných dotazov, ich implementácia je uvedená v prílohe A.

getKomandasByTablicaId - požiadavka na výber hodnôt z tabuľky "Team", kde id tabuľky je parameter pre príjem príkazu.

findKomandaByName - dotaz na výber príkazu, kde názov tabuľky je parameter na získanie príkazu.

getTablicaByChempionatId - požiadavka na načítanie hodnôt z tabuľky "Table", kde Championship id je parameter na získanie tabuľky.

getKomandasByTablicaId - požiadavka na výber hodnôt z tabuľky "Team", kde id tabuľky je parameter na získanie tabuľky.

findUserByNameAndPassword - požiadavka na výber hodnôt z tabuľky "Používateľ", kde prihlásenie používateľa je prvým parametrom a heslo je druhým parametrom.

getWorkerByChempionatId - požiadavka na načítanie hodnôt z tabuľky "Zamestnanec", kde Championship id je parameter na získanie pracovníka.

getZarplatasByWorkerId - požiadavka na výber hodnôt z tabuľky "Plat", kde ID zamestnanca je parametrom pre príjem mzdy.

3.1.4 Vytváranie rolí, výber indexov a zobrazení

Roly:

Bolo vytvorených niekoľko rolí s rôznymi prístupovými právami k databáze:

Vytvoriť rolu "admin" PRIHLÁSENIE NEŠIFROVANÉ HESLO "qwerty"

Vytvoriť rolu "manažér" PRIHLÁSENIE NEŠIFROVANÉ HESLO "qwerty1"

Vytvoriť rolu "riaditeľ" PRIHLÁSENIE NEŠIFROVANÉ HESLO "qwerty2"

Prístupové práva k vzťahom chempionat, komanda, matchi, prava, "rola", tablica, users, worker, zarplata možno opísať takto:

udeliť výber, odstrániť, vložiť, aktualizovať na chempionat, komanda, matchi, prava, "role", tablica, users, worker, zarplata to admin

udeliť výber, vymazať, vložiť, aktualizovať na tablica, matchi, komanda manažérovi

Indexy:

Pri výbere indexov bol hlavným kritériom častý prístup do konkrétneho poľa

Na zvýšenie efektívnosti práce s údajmi boli pre polia často používané pri vzorkovaní údajov vytvorené indexy:

vytvoriť index i_worker na worker(id);

vytvoriť index i_komanda na príkaz (id);

vytvoriť index i_matchi na matchi(id);

vytvoriť index i_zarplata na zarplata(id)

zastúpenie:

Na implementáciu čiastočného prístupu k tabuľke tablica bolo vytvorené nasledujúce zobrazenie:

vytvoriť zobrazenie w_guest (kolnichiyih,kolocheck,kolproigrashey,kolviigrashey,idchampionata) ako

vyberte kolnichiyih, kolocheck, kolproigrashey, kolviigrashey, idchampionata z tablica;

vytvoriť rolu hosť PRIHLÁSIŤ SA NEŠIFROVANÉ HESLO "qwerty3"

udeliť výber na w_guest hosťovi

3.1.5 Vývoj uložených procedúr a spúšťačov

Spúšťače:

1) Spúšťač, ktorý pridáva hodnotu do prémiového poľa pri pridávaní záznamu do tabuľky Zarplata. Ak hodnota poľa kolChasov prekročí určitú hodnotu.

VYTVORIŤ ALEBO NAHRADIŤ FUNKCIU ins()

VRÁTI spúšť AS

AKTUALIZÁCIA "plat"

SET "premiya" =("kolchasov" - 176)*100

Od „zarplata“, „robotník“

kde("kolchasov">8);

JAZYK "plpgsql";

VYTVORIŤ SPÚŠŤAČ trig_11 PO VLOŽENÍ NA „zarplata“

PRE KAŽDÝ RIADOK VYKONAŤ POSTUP ins();

2) Spúšťač, ktorý pridá záznam do poľa sumy v tabuľke platov, keď sa záznam pridá alebo aktualizuje v tabuľke. Hodnota tohto poľa je určená hodnotou polí Sadzba, Pokuta a Prémia.

vytvoriť alebo nahradiť funkciu addSumInZarplata() vráti spúšťač ako

deklaruj shtr float:=(vyber shtraf zo zarplata kde id=new.id);

deklaruj prem float:=(vyber prémiu zo zarplata kde id=new.id);

deklaruj s float:= (vyber summa zo zarplata kde id=new.id);

aktualizovať platovú sadu

summa = s+prem-shtr, kde id=new.id;

jazyk plpgsql;

vytvoriť spúšťač trigAddSumZarplat

o mzde za každý riadok

spustiť procedúru addSumInZarplata();

Uloženépostupy:

1) Vytvorte uloženú procedúru, ktorá vráti zoznam zápasov, ktoré sa majú uskutočniť dnes. Neexistujú žiadne vstupné parametre. Výstupným parametrom bude tabuľka zhôd.

VYTVORIŤ ALEBO NAHRADIŤ FUNKCIU func_1()

TABUĽKA NÁVRATOV(ID celé číslo, rôzny znak gost(30), rôzny znak hozainu(30),

schet character varying(10), tur integer, idkomandy integer, data date) AS $$

SELECT * FROM "matchi" WHERE "data" = timenow()::date; $$

2) Vytvorte uloženú procedúru, ktorá vráti názov tímu, ktorý získal najmenej bodov v určitom šampionáte. Vstupnými parametrami je názov krajiny. Výstupným parametrom bude názov príkazu.

VYTVORIŤ ALEBO NAHRADIŤ FUNKCIU func_2(strana znak sa mení(40))

VYBERTE "meno" FROM "komanda", "tablica", "chempionat" WHERE "komanda"."idtablici" = "tablica"."id" A "kolocheck" IN (SELECT MIN("kolocheck") FROM "tablica") AND "idchampionata" IN (SELECT "id" FROM "championat" WHERE "strana" = $ 1); $$

3) Vytvorte uloženú procedúru, ktorá vráti 10 najlepších tímov turnajovej tabuľky. Vstupnými parametrami je názov krajiny. Výstupným parametrom bude tabuľka pozostávajúca z mien 10 najlepších tímov a ich bodov.

VYTVORIŤ ALEBO NAHRADIŤ FUNKCIU func_3(strana znak sa mení(40))

VRÁTI TABUĽKU(_menný znak premenlivý(20), kolocheck integer) AKO $$

S poddotazom AS (SELECT "name", "kolocheck" FROM "komanda", "tablica", "chempionat" WHERE "komanda"."idtablici" = "tablica"."id" AND "idchampionata" IN (SELECT "id" OD "chempionat" KDE "strana" = 1 $) SKUPINA PO 1, 2 OBJEDNAJTE PODĽA "kolocheck" DESC)

VYBERTE * Z "poddotazu" GROUP BY 1, 2 HAVING COUNT("name")<= 10; $$

4) Vytvorte uloženú procedúru, ktorá vráti meno vedúceho tímu v poradí určitého šampionátu. Vstupnými parametrami je názov krajiny. Výstupným parametrom bude meno vedúceho.

VYTVORIŤ ALEBO NAHRADIŤ FUNKCIU func_5(strana znak sa mení(40))

RETURNS znak premenlivý(20) AKO $$

VYBERTE „meno“ Z „komanda“, „tablica“, „chempionat“

WHERE "komanda"."idtablici" = "tablica"."id" A "kolocheck" IN (VYBERTE MAX("kolocheck") Z "tablica") A "idchampionata" IN (VYBERTE "id" FROM "chempionat" WHERE " krajina" = 1 USD); $$

3.1.6 Organizácia ochrany údajov

Vo vyvinutom systéme je viacero rolí a pre každú z nich v softvérovom systéme "Futbal Championship" iná funkcionalita. Možnosti každého typu používateľa v tomto softvérovom systéme sú uvedené v tabuľke 3.2

Tabuľka 3.2 - Ochrana údajov

3.1.7 Objektovo-relačné mapovanie

Pri vývoji programu sa pristupuje k dátam, preto sa pre zjednodušenie vývoja takéhoto programu a pre zvýšenie efektivity a rýchlosti práce s prijatými dátami použilo objektovo-relačné mapovanie.

Objektovo-relačné mapovanie (ORM) je programovacia technika, ktorá spája relačné databázy s konceptmi objektovo orientovaného programovania a vytvára „virtuálnu databázu objektov“.

ORM automaticky synchronizujú objekty načítané v pamäti s databázou. Aby to bolo možné, po vytvorení SQL dotazu na transformáciu objektu do SQL sa výsledné údaje skopírujú do polí objektu, ako vo všetkých ostatných implementáciách ORM.

Systémy správy relačných databáz vykazujú dobrý výkon pri globálnych dotazoch, ktoré ovplyvňujú veľkú oblasť databázy, ale objektovo orientovaný prístup je efektívnejší pri práci s malým množstvom údajov, pretože znižuje sémantickú medzeru medzi objektovými a relačnými formami údajov.

Všetky systémy ORM majú tendenciu prejavovať sa tak či onak, čím sa znižuje možnosť ignorovania databázy nejakým spôsobom. Transakčná vrstva môže byť navyše pomalá a neefektívna (najmä z hľadiska generovaného SQL). To všetko môže spôsobiť, že programy bežia pomalšie a využívajú viac pamäte ako ručne písané programy.

Ale ORM šetrí programátora od písania veľkého množstva kódu, často opakovaného a náchylného na chyby, čím výrazne zvyšuje rýchlosť vývoja. Okrem toho väčšina moderných implementácií ORM umožňuje programátorovi v prípade potreby napevno nakódovať SQL dotazy, ktoré budú použité na určité akcie (ukladanie do databázy, načítanie, vyhľadávanie atď.) s perzistentným objektom.

Pri vývoji aplikácie, ktorá vyžaduje prístup k dátam, je potrebné zjednodušiť vývoj takejto aplikácie, zvýšiť efektivitu a rýchlosť práce s prijatými dátami. Preto je tento problém aktuálny aj dnes.

Na jeho vyriešenie bol vybraný JPA (Java Persistence API).

Nižšie uvedený diagram ukazuje vzťah medzi hlavnými komponentmi architektúry JPA.

Obrázok 3.3 - Architektúra JPA

Perzistencia – Trieda obsahuje pomocné statické metódy na získanie EntityManagerFactory spôsobom nezávislým od dodávateľa.

EntityManagerFactory je rozhranie, ktorého implementácia je továreň na vytváranie objektov EntityManager.

EntityManager je hlavné rozhranie JPA používané v aplikáciách. Každý EntityManager spravuje množinu trvalých objektov a obsahuje API na vkladanie nových objektov a odstraňovanie existujúcich. Každý EntityManager má priradenú vlastnú transakciu EntityTransaction a EntityManager funguje aj ako továreň na objekty Query.

Entita – entita, ktorá je uloženým objektom.

EntityTransaction - objekt, ktorý vykonáva správu transakcií pri vykonávaní operácií s uloženými objektmi Entity. Operácie sú zoskupené a buď sa vykonajú v plnom rozsahu, alebo nie, pričom dátové úložisko zostane v nezmenenom stave.

Query je rozhranie na vykonávanie dotazov na nájdenie uložených objektov, ktoré zodpovedajú daným kritériám. JPA podporuje dotazy v jazyku Java Persistence Query Language (JPQL) a štandardnom jazyku Structured Query Language (SQL). Inštancie Query môžete získať z objektu EntityManager.

3.2 Vývoj modulov systému

3.2.1 Vývoj modulov vrstvy obchodnej logiky a obchodných pravidiel

Tento modul je popisom všetkých entít našej databázy. Zahŕňa jedenásť tried, a to:

Matchi.java je trieda, ktorá popisuje zápasy. Obsahuje nasledujúce informácie: dátum zápasu, hosť, hostiteľ, skóre zápasu, číslo zájazdu. Obsahuje metódy na získavanie a zapisovanie polí.

Komanda.java je trieda, ktorá popisuje príkazy. Obsahuje nasledujúce informácie: názov tímu, meno trénera, mesto tímu. Obsahuje metódy na získavanie a zapisovanie polí.

Table.java – trieda, ktorá popisuje turnajový stôl. Obsahuje polia: počet bodov tímu, počet prehier, výhier a remíz. Obsahuje metódy na získavanie a zapisovanie polí.

Chempionat.java je trieda, ktorá opisuje majstrovstvá. Obsahuje tieto informácie: dátum začiatku, dátum ukončenia mempionátu, názov krajiny, v ktorej je držaný. Obsahuje metódy na získavanie a zapisovanie polí.

Worker.java je trieda, ktorá popisuje pracovníka. Obsahuje tieto údaje: celé meno zamestnanca, dátum narodenia, telefónne číslo, adresu. Obsahuje metódy na získavanie a zapisovanie polí.

User.java je trieda, ktorá popisuje používateľa. Obsahuje nasledujúce informácie: prihlasovacie meno a heslo pre vstup do systému. Obsahuje metódy na získavanie a zapisovanie polí.

Role.java je trieda, ktorá popisuje rolu používateľa. Obsahuje nasledujúce informácie: používateľské meno. Obsahuje metódy na získavanie a zapisovanie polí.

Prava.java je trieda, ktorá popisuje práva používateľa. Obsahuje tieto informácie: práva, pod ktorými sa používateľ prihlasuje

3.2.2 Vývoj modulov vrstvy prístupu k dátam

K údajom sa pristupuje pomocou DAO. Tento modul predstavujú dva balíky s rozhraniami a ich implementáciami. Obsahuje nasledujúce rozhrania:

– ITablicaDao.java – rozhranie, ktoré obsahuje popisy metód pre prácu s tabuľkou. Opisuje nasledujúce metódy:

verejná zbierka getTablicasByChempionatId(Integer chId) vyvolá metódu PersistenceException na získanie všetkých stolov pre daný šampionát.

Implementácia metód je v triede TablicaDaoJpa.

– IKomandaDao.java - rozhranie, ktoré obsahuje popisy metód pre prácu so zoznamom príkazov. Opisuje nasledujúce metódy:

a)verejnosti zber getKomandasByTablicaId(Integer chId) hádže Metóda PersistenceException na získanie všetkých tímov na konkrétnom umiestnení;

b)verejnosti Komanda findKomandaByName(Názov reťazca) vyvolá metódu PersistenceException na získanie príkazu podľa názvu.

c) getTheWorstKomandaByChampId(názov reťazca) hodí metódu PersistenceException na získanie najhoršieho tímu v šampionáte;

d)verejnosti String getTheBestKomandaByChampId(názov reťazca) vyvolá metódu PersistenceException na získanie najlepšieho tímu na šampionáte;

e)verejnosti zber getTopTenKomandasByChampId(názov reťazca) hodí metódu PersistenceException na získanie 10 najlepších tímov v šampionáte;

Podobné dokumenty

Štruktúra databázy. Vizualizácia trojvrstvovej architektúry pozostávajúcej z prezentačnej vrstvy, obchodnej vrstvy a databázovej vrstvy, realizovaná pomocou UML diagramov. Základné konštrukčné vlastnosti trojvrstvových aplikácií. Zdrojový kód niektorých modulov.

ročníková práca, pridaná 11.03.2012


Návrh modelu vyvíjanej hotelovej databázy. Vývoj spúšťačov, uložených procedúr, dotazov. Vytvorenie používateľského rozhrania. Automatizácia práce na evidencii, účtovníctve, vyhľadávaní, ako aj reportingu o zamestnávateľoch.

ročníková práca, pridaná 29.11.2015


Charakteristika hlavných dátových tokov, ktoré existujú v podniku. Spôsoby a prostriedky vývoja softvéru. Dizajn používateľského rozhrania. Vývoj vrstvy interakcie s databázou. Rozvoj vrstvy obchodných služieb.

diplomová práca, pridané 7.10.2017


Definícia funkčných závislostí. Vývoj štruktúry databázy. Organizácia dopytov do databázy. Používanie spúšťačov na udržanie aktuálnych údajov. Vývoj uložených procedúr a funkcií. Obmedzenia údržby databázy.

semestrálna práca, pridaná 17.06.2014


Podstatou databázy je súbor, zbierka súborov, ktoré obsahujú informácie. Systém správy databáz - softvérový systém (aplikácia), ktorý zabezpečuje prácu s databázou (dátovými súbormi). Účel a výhody používania spúšťačov.

ročníková práca, pridaná 22.02.2011


Navrhovanie relačnej databázy, organizovanie výberu informácií z nej. Navrhnite zobrazenia na zobrazenie výsledkov. Navrhovanie uložených procedúr. Mechanizmus správy údajov pomocou spúšťačov. Požiadavky na technickú podporu.

práca, pridané 7.3.2011


Vývoj a ladenie databázy serverového typu s webovým rozhraním "Produktové účtovníctvo" pre výrobu nábytku. Fyzický dátový model. Popis indexov a obmedzení, dotazov a dátových pohľadov, zostáv a grafov. Popis spúšťačov a uložených procedúr.

ročníková práca, pridaná 20.02.2015


jazyk na manipuláciu s údajmi. Proces výberu údajov. Používanie agregovaných funkcií a špeciálnych operátorov v podmienkach výberu. Vytváranie a používanie pohľadov a uložených procedúr. Použitie spúšťačov, vývoj používateľského rozhrania.

laboratórne práce, doplnené 13.02.2013


Logická a fyzická štruktúra databázy. Systémový hardvér a softvér. Vytváranie pohľadov, uložených procedúr, užívateľom definovaných funkcií, spúšťačov. Popis základnej štruktúry dokumentov ASP.NET. Užívateľské rozhranie.

ročníková práca, pridaná 21.05.2013


Koncept databázy. Vývoj tabuliek, formulárov pre vstup a výstup informácií, základných dotazov, uložených procedúr a spúšťačov databázy Bulletin Board. Príprava na tlač. Analýza potreby administratívy, nástrojov informačnej bezpečnosti.

Ciele lekcie: vytvoriť podmienky na vnímanie a konsolidáciu vzdelávacieho materiálu na tému „Modelovanie v textovom procesore“

1. Pokračovať v oboznamovaní študentov s možnosťami modelovania v textovom editore Word;
2. Oboznámiť študentov s pojmom a typmi konštrukčných modelov;
3. Naučiť všeobecný prístup k vytváraniu modelov obrazových znakov v textovom procesore;
4. Zabezpečte vykonávanie úloh modelovania v prostredí textového procesora.

vyvíja sa:

Rozvoj techník duševnej činnosti (zovšeobecnenie, analýza, syntéza, porovnávanie), pamäti (najlepšie si zapamätáme to, čo je spojené s prekonávaním prekážok), rozvoj modelového štýlu študentov.

Vzdelávacie:

Rozvoj kognitívnych schopností žiakov zvažovaním rôznych modelovacích úloh v prostredí textového procesora.

Typ lekcie: kombinovaná.

Vybavenie hodiny: počítač, projektor, prezentácia ( Príloha 1), kartičky s úlohami na praktickú prácu ( prihláška 2).

Stanovenie cieľov hodiny, informovanie študentov o hlavných fázach hodiny.

- Ktoré modely nazývam ikonické?

- Aké typy ikonických modelov poznáte?

– Aký znakový model sa nazýva verbálny?

Aký textový dokument sa nazýva zložený?

– Uveďte príklady návrhových úloh riešených tvorbou zložených dokumentov v textovom editore.

Štruktúra je usporiadanie komponentov niečoho.

Štruktúra údajov – súbor informačných prvkov, ktoré sú v určitom, vopred určenom vzťahu, ako aj spôsob opisu takéhoto vzťahu. ( Príloha 1 snímka 3),

Štrukturálny dátový model je dátový model prezentovaný ako štruktúra – súbor dátových typov a vzťahov medzi nimi.

Najbežnejšie v textových dokumentoch sú tieto typy informačných štruktúr: ( príloha 1 snímka 4)

• Tabuľka
• Schéma - odráža vzhľad klasifikácie objektov
(príloha 1 snímka 5)

Navonok klasifikačná schéma pripomína obrátený strom a predstavuje hierarchiu objektov. V hierarchických schémach má každý objekt iba jedného rodiča a môže mať viacero potomkov. Najvyššia úroveň (koreň stromu) nemá žiadneho predka a definuje hlavné črty, ktoré umožňujú odlíšiť objekty tejto triedy od ostatných.

Podobné vzorce vidíte v biológii, histórii a iných predmetoch.

Cvičenie: Vytvorte blokovú schému pre rodokmeň podľa nasledujúceho popisu:

Novomanželia bežne používajú pravú ruku. V rodine ženy boli ešte dve sestry, ktoré bežne používajú pravú ruku, a traja bratia ľaváci. Matka ženy je praváčka, otec ľavák. Môj otec má sestru a 2 pravákov. Môj starý otec z otcovej strany je pravák, moja stará mama je ľavák. Matka ženy má dvoch bratov a sestru, všetci sú praváci. Manželova mama je pravák, otec ľavák. ( Príloha 1 snímka 6)

Na hodinách ruštiny ste museli urobiť syntaktickú analýzu vety, a keďže veta je systém pozostávajúci zo slov, môžete si zostaviť diagram, ktorý zobrazuje hlavné a vedľajšie členy vety. ( Príloha 1 snímka 7)

• Bloková schéma
- súbor geometrických tvarov, z ktorých každý označuje konkrétnu činnosť, pričom vzťah medzi nimi je stanovený pomocou šípok alebo čiar ( Príloha 1 snímka 8)
• Dokumenty so štruktúrou definovanou legislatívou

Veľmi často sa v živote stretávame s rôznymi druhmi dokumentov. Sú to certifikáty, výpisy, objednávky a mnoho iného. Ktorýkoľvek z uvedených dokumentov je nosičom informácií a musí byť právne správny. V súčasnosti sa na zostavovanie takýchto dokumentov čoraz viac využíva aplikačné prostredie textového editora.

Z triednej schôdze ste, samozrejme, museli urobiť zápisnicu.

– Čo je protokol? ( Zápisnica - dokument upravujúci priebeh diskusie o problémoch a rozhodovania na stretnutiach, stretnutiach atď.)

- Aké povinné informácie by sa podľa vás mali odraziť v protokole? (dátum schôdze; počet prítomných osôb; program; priebeh diskusie; rozhodnutia schôdze)(Príloha 1 snímka 9)

Na snímka 10 prílohy 1 uvádza sa vzor zápisnice z triednej schôdze.

Vykonávanie praktickej práce „Vytvorenie modelu štruktúry značky“ na počítači ( prihláška 2)

1. Analýza výsledkov praktickej práce:

- čo sa stalo?
- čo nefungovalo?
Aké ťažkosti ste mali pri plnení úloh?

2. Označenie pre praktickú prácu.

Vypracujte do pracovných zošitov (v textovom procesore) klasifikačnú schému školských pomôcok.

MOSKVA ŠTÁTNA TECHNICKÁ UNIVERZITA "MAMI"

KURZOVÁ PRÁCA

podľa disciplíny: Informačná podpora riadiacich systémov

na tému: "Vývoj databázy futbalového klubu"

Vyplnil: študentská 642 skupina

Pletnev Nikolaj Viktorovič

Kontroloval: učiteľ

Semenikhin Gennadij Iľjič

Serpukhov 2009

Úvod

1. Popis činnosti organizácie

3. Vývoj databázy v prostredí Access 2003 DBMS

3.1 Vytváranie tabuliek

3.2 Vytvorenie dátovej schémy

3.3 Vytváranie formulárov

3.4 Vytváranie dotazov v QBE a SQL

3.5 Vytváranie správ

4. Slovník pojmov

Záver

Bibliografia

1. Urobte popis činnosti futbalového klubu Chelsea, sformulujte hlavné úlohy jeho systému správy informácií a zdôvodnite požiadavky na jeho databázu.

2. Vytvorte model "vzťahu entít" databázy:

Vytvorte zoznam entít a ich atribútov

Zvýraznite vzťahy medzi entitami

Zostavte diagramy typu ER a inštancií ER, berúc do úvahy všetky entity a vzťahy

Generujte sady predbežných vzťahov, berúc do úvahy stupeň pripojenia a triedu členstva inštancií entity a špecifikujte predbežný kľúč pre každý vzťah a pomocou diagramov typu ER

Pridajte do vzťahov nekľúčové atribúty

V prípade potreby upravte diagramy typu ER

3. Implementovať vyvinutú relačná databázu informačného manažérskeho systému futbalového klubu "Chelsea" v prostredí Access 2003 DBMS.

4.Vypracujte aspoň 2 správy a aspoň 5-7 databázových dotazov pomocou nástrojov DBMS a jazykov QBE a SQL s odôvodnením ich použitia v organizácii.

Databáza je zbierka informácií súvisiacich s konkrétnou témou alebo úlohou, ako je sledovanie objednávok zákazníkov alebo udržiavanie zbierky hudby. Ak databáza nie je uložená v počítači, alebo sú v počítači uložené iba jej časti, informácie možno sledovať z rôznych iných zdrojov, ktoré musí používateľ koordinovať a organizovať sám.

Vývoj databázy pomocou Microsoft Access je rýchly a presný. Databázy sú všade, čo naznačuje, že ich používanie výrazne zjednodušuje rôzne operácie dostupné v organizáciách.

Pomocou programu Microsoft Access môžete vytvárať tabuľky, formuláre a iné objekty, ktoré tvoria databázu. Funkciou je vytváranie dotazov pomocou SQL dotazu.

Dotazy sa používajú na zobrazenie, úpravu a analýzu údajov rôznymi spôsobmi. Dotazy možno použiť aj ako zdroje záznamov pre formuláre, zostavy a stránky prístupu k údajom.

SQL dotaz je dotaz vytvorený pomocou rôznych príkazov ako Select, Update alebo DELETE. Príklady SQL dotazov sú spojovacie dotazy, serverové dotazy, riadiace dotazy a poddotazy.

V tejto práci na kurze bude prezentovaná databáza pozostávajúca z tabuliek, dotazov prezentovaných v SQL a QBE.

1. Popis činnosti futbalového klubu Chelsea

prístup k základni informačného manažéra

Futbalový klub Chelsea bol založený v roku 1905 v Londýne. Tento klub hrá v anglickej Premier League (Anglický šampionát). FC Chelsea má medzi fanúšikmi prezývku – The Aristocrats. Táto prezývka pochádza z bohatej oblasti Londýna. Práve oblasť, v ktorej žijú najbohatší obyvatelia hmlistého Albionu. Výkon Chelsea FC v 20. storočí sa nepovažoval za veľmi dobrý, a preto boli v Anglicku považované za priemerné. V roku 1955 sa prvýkrát stali majstrami Anglicka. FC Chelsea hrávala v európskych pohároch zriedkavo a úspech nebol ohromujúci. V roku 1971 sa im však podarilo vyhrať Európsky pohár víťazov pohárov po tom, čo rok predtým vyhrali FA Cup. Na konci 20. storočia vyhrali aristokrati ďalší pohár pohárov a potom aj Európsky superpohár. Bol to najväčší titul v histórii klubu. Keď Chelsea FC kúpil ruský miliardár Čukotka guvernér Roman Abramovič, klub získal mnoho hviezdnych hráčov ako Petr Čech, Ricardo Carvalho, Claude Makelele, Jeremy atď. S takýmito hráčmi sa klub stal jedným z najsilnejších v Európe. A v roku 2005 získal v Anglicku svoj druhý ligový titul. Nedávno do klubu prišli nemenej známi hráči ako Arjen Robben, Michael Ballack, Andriy Shevchenko, Didier Drogba. Títo hráči pomohli získať tretí anglický titul. FC Chelsea sa v posledných dvoch rokoch prebojovala do semifinále Ligy majstrov.

Štadión Chelsea je Stamford Bridge s kapacitou 42 142 miest vrátane VIP miest. Prezidentom klubu je Bruce Buck. Aristokrati majú vlastnú fanúšikovskú stránku www.chelseafc.com.

Systém riadenia futbalového klubu Chelsea možno rozdeliť do niekoľkých podsystémov:

Pracujte s tímom, s hlavným aj s rezervou. V tomto odseku sa uvažuje aj o práci s mládežou. Tento subsystém je najdôležitejší pre víťazstvo v akomkoľvek zápase.

Práca s personálom, a to s trénerom mužstva, trénerom brankárov, trénerom mládeže, lekármi, marketingovými špecialistami, špecialistami na štadióny, zástupcom fanúšikov a pod.

Práca s fanúšikmi ako hlavná súčasť morálnej podpory. Práve počet fanúšikov určuje obľúbenosť klubu vo svete.

Práca s financiami klubu určuje finančnú situáciu. Tu sa počíta plat hráčov, trénerov, lekárov, manažérov atď. Finančná situácia svedčí o schopnosti klubu pri rôznych transakciách, ako je nákup hráčov na posilnenie, modernizácia štadióna a ďalších budov susediacich s klubom.

Plat ktoréhokoľvek člena klubu závisí od jeho pozície v ňom. Preto má každý človek svoj vlastný status, ktorý určuje jeho plat a úlohu.

Kvalita hry ovplyvňuje aj plat. Na tento účel berú jeho údaje o úspechu, ktoré udávajú počet zápasov, gólov, pohárov. Parametre hráča ako výška, váha určujú jeho kondíciu v boji. Podľa týchto údajov je hráč umiestnený na zápas s prihliadnutím na údaje súpera. Vek hráča určuje jeho skúsenosti a zručnosť v hre.

Miesto na futbalovom ihrisku sa nazýva rola. Výber hráča podľa roly je pre kvalitu hry mužstva veľmi dôležitý. Ak sa hráč zraní, je potrebná výmena. Ale koho nahradiť? Za týmto účelom si hlavný tréner vyberie spomedzi dostupných hráčov podľa roly. Ak nie je dostatok hráčov, tak sa tréner obracia na vedenie o potrebe kúpy futbalistu z iného klubu.

2. Vývoj modelu databázy „entity-relationship“.

Na vytvorenie modelu vzťahu medzi entitami sú potrebné tieto kroky návrhu:

1. Vyberte entity a vzťahy medzi nimi.

2. Zostavte diagramy typu ER.

3. Vytvorenie súboru predbežných vzťahov s uvedením ich primárnych kľúčov.

4. Pridávanie nekľúčových atribútov do vzťahov.

5. Zníženie predbežných vzťahov na 3 posilnenú normálnu formu.

Vývoj modelu "Entity-Relationship" futbalového klubu Chelsea:

1. fáza: Stav (kód, typ stavu)

Hráč (kód, priezvisko, meno, pozícia, vek, ...)

Úspech (priezvisko, meno, počet zhôd...)

Zmluva (číslo zmluvy, priezvisko...)

Personál (kód, priezvisko, meno)

2. fáza: Vyberte spojenia a definujte triedu členstva:

Hráč má status

Hráč má úspechy

Personál má štatút

Hráč zodpovedá zmluve

Personál dodržiava Zmluvu

Na základe prijatých údajov zostavíme diagram typu ER:

Fáza 3: Vytvorenie súboru predbežných vzťahov sa vykonáva podľa pravidiel:

Pravidlo 1: Ak je stupeň binárneho vzťahu 1:1 a CP je povinný, potom sa vytvorí jeden vzťah. Primárnym kľúčom môže byť ľubovoľný kľúč entity.

Pravidlo 2: Ak je stupeň vzťahu 1:1 a CP je O-N, potom sa pre každú z entít vytvorí vo vzťahu k primárnym kľúčom, ktoré sú kľúčmi zodpovedajúcich entít, potom k vzťahu, entita ktorý má povinný CP, sa ako atribút pridá kľúč entity s voliteľným CP.

Pravidlo 3: Ak je stupeň vzťahu 1:1 a trieda členstva oboch entít je voliteľná, potom musíte použiť tri vzťahy s primárnymi kľúčmi, dva vzťahy súvisiace vzťahmi.

Pravidlo 4: Ak je stupeň vzťahu 1:M a členská trieda CP je povinná, potom stačí vytvoriť dva vzťahy, jeden pre každý subjekt.

Pravidlo 5: Ak je stupeň vzťahu 1:M a trieda členstva pripojenej entity M je voliteľná, potom je potrebné vytvoriť 3 vzťahy, 2 vzťahy zodpovedajúce spriazneným entitám, ktorých kľúče sú v tomto vzťahu primárne. .

Pravidlo 6: Ak je stupeň vzťahu M:M a vyžaduje sa členská trieda entity, potom je nezávislá od členskej triedy entity.

Podľa pravidla 1: 1. Stav (kód, typ stavu…..)

Podľa pravidla 5: 1. Stav (kód, typ stavu……)

2. Hráč (kód, priezvisko……)

3. Zmluva (číslo zmluvy, priezvisko …..)

Podľa pravidla 1: 1. Úspechy (Priezvisko, ...)

Podľa pravidla 2: 1. Personál (kód, priezvisko ....)

2. Zmluva (číslo zmluvy, priezvisko ....)

3. Vývoj databázy v prostredí Access 2003 DBMS

3.1 Vytváranie tabuliek

Pomocou programu Microsoft Access môžete vytvárať tabuľky v režime návrhu, vytvárať tabuľky pomocou sprievodcu a vytvárať tabuľky zadaním údajov.

Databáza futbalového klubu Chelsea obsahuje 5 tabuliek vytvorených pomocou Sprievodcu tabuľkou.

Sprievodca tabuľkou vám umožňuje rýchlo vytvárať tabuľky z existujúcich údajov, čo výrazne zjednodušuje vašu prácu.

Má udalosť kliknutia. Obslužné programy kliknutí na tlačidlá sú uvedené v prílohe A. Záver V priebehu práce v kurze bol dosiahnutý cieľ práce - návrh databázy podnikového účtovníctva futbalového klubu. Na dosiahnutie cieľa sa riešilo množstvo úloh: zostavenie popisu predmetnej oblasti; zostavovanie slovníka pojmov a pojmov; vytvorenie pôvodného modelu (ER-...

Agregáty nie sú znázornené geometrickými obrazcami, ale symbolmi alebo znakmi, ktoré do určitej miery reprodukujú vonkajší obraz štatistických údajov. Výhoda tohto spôsobu grafického znázornenia spočíva vo vysokej miere prehľadnosti, v získaní podobného zobrazenia, ktoré odráža obsah porovnávaných populácií. Najdôležitejšou vlastnosťou každého diagramu je mierka. Preto, aby...

... "Traktor", "Dynamo", "Torpedo", "Worsted", "Lokomotiv", výstavba futbalového areálu "Skvich" vrátane arény, štadióna so štandardným futbalovým ihriskom. 2. Minsk je zdrojom sociálno-ekonomického rozvoja Bieloruska Minsk, ktorý nedávno oslávil 940 rokov, bol vždy veľkou administratívnou jednotkou - hlavným mestom konkrétneho kniežatstva, centrom vojvodstva vo Veľkej ...

Futbal je kolektívny šport, v ktorom je cieľom kopnúť loptu do súperovej bránky nohami alebo inými časťami tela (okrem rúk) viackrát ako súperovi. Je to najpopulárnejší šport na svete. Za základ databázy Access Football Team bol vybraný futbalový klub Spartak. Tematická oblasť - futbalové družstvo. Cieľom je vytvoriť databázu na ukladanie, vyhľadávanie a prístup k informáciám o hráčoch, hrách, výsledkoch zápasov, futbalových tímoch atď. Táto databáza má možnosť zobraziť strelcov klubu, zobraziť zoznam legionárov FC Spartak, načítať kalendár zápasov, zobraziť štatistiky každého hráča FC Spartak, štatistiky zápasov. Môžete tiež vytvoriť poradie po každom kole, zobraziť pohyb každého tímu v šampionáte RFPL vo forme grafu. V prípade potreby je možné databázu previesť na akýkoľvek iný futbalový klub.

Databáza Football Team Access obsahuje 7 tabuľky, 12 dotazov, 8 formulárov + hlavný tlačidlový formulár, 7 reportov. Táto databáza Accessu je vzdelávacia, vhodná na ďalšiu optimalizáciu a dolaďovanie pre vaše vlastné potreby.

Vysvetľujúca poznámka nie!

Účelom praktických úloh je osvojiť si zručnosti analýzy predmetu, návrhu databázy a jej fyzickej implementácie v Access DBMS.
Výsledok práce je prezentovaný vo forme databázy Access, ktorá by mala obsahovať:
štruktúra navrhnutých tabuliek,
dátová schéma so vzťahmi medzi tabuľkami,
formuláre, ktoré poskytujú používateľské rozhranie,
žiadosti,
správy,
formulár hlavného tlačidla.

Tabuľka kalendára 2016-2017 – futbalový tím s prístupom k databáze

Formulár "Rozpis zápasov" - DB Access Football Team

Hráčska uniforma - prístup k databáze futbalového tímu

Formulár zhrnutia turnaja – prístup k databáze futbalového tímu

Štatistika tímových zápasov – prístup k databáze futbalového tímu

Report "Štatistiky hráčov 2016-2017" - DB Access Football Team

Správa o zozname zahraničných hráčov – prístup k databáze futbalového tímu

Prehľad výsledkov po kole N – prístup k databáze futbalového tímu

Správa kalendára 2016-2017 – futbalový tím s prístupom k databáze

Správa "Pohyb na turné tímu Spartak" — DB Access Football Team

Stiahnuť databázu (DB) MS Access; futbalový tím DB Access; Spartakus; futbalový klub; prístupová databáza; db prístup; subd prístup; prístup k databázam; príklad prístupu; programovanie prístupu; pripravená databáza; vytvorenie databázy; DBMS databáza; prístup k kurzom; príklad databázy; prístupový program; popis prístupu; prístupový abstrakt; žiadosti o prístup; príklady prístupu; sťahovanie prístupu k databáze; prístupové objekty; db v prístupe; sťahovanie subd prístup; ms prístupová databáza; subd prístupový abstrakt; subd ms prístup; prístupové výhody; databáza; sťahovanie databázy pri prístupe; Databáza; relačná databáza; systémy na správu databáz; databáza kurzov; sťahovanie databázy; sťahovanie prístupovej databázy; sťahovanie prístupovej databázy;