itthon - Elektromos mérőórák
Példa egy tantárgyi terület szerkezeti modelljére. Adatbázis normalizálás

MOSZKVA ÁLLAMI MŰSZAKI EGYETEM "MAMI"

TANFOLYAM MUNKA

tudományág: Irányítási rendszerek információs támogatása

témában: „Futballklub adatbázis fejlesztése”

Kitöltötte: a 642. csoport tanulója

Pletnyev Nyikolaj Viktorovics

Ellenőrizte: tanár

Szemenikhin Gennagyij Iljics

Szerpuhov 2009


Tartalom Feladat

Bevezetés

1.A szervezet tevékenységeinek leírása

3.Adatbázis fejlesztése Access 2003 DBMS környezetben

3.1 Táblázatok létrehozása

3.2 Adatséma létrehozása

3.3 Űrlapok létrehozása

3.4 Lekérdezések létrehozása QBE és SQL nyelven

3.5 Jelentések generálása

4. Fogalomtár

Következtetés

Bibliográfia


Gyakorlat

1. Készítse el a Chelsea labdarúgóklub tevékenységének leírását, fogalmazza meg információkezelő rendszerének fő feladatait, és indokolja meg az adatbázisával szemben támasztott követelményeket.

2. Fejlessze ki az adatbázis „entitás-kapcsolati” modelljét:

Készítsen egy listát az entitásokról és azok attribútumairól

Emelje ki az entitások közötti kapcsolatokat

Készítsen diagramokat ER típusú és ER példányokról, figyelembe véve az összes entitást és kapcsolatot

Előzetes kapcsolatkészletek létrehozása, figyelembe véve a kapcsolat mértékét és az entitáspéldányok tagsági osztályát, és minden kapcsolathoz megadva egy előzetes kulcsot, és ER-típusú diagramokat használva

Adjon hozzá nem kulcsfontosságú attribútumokat a kapcsolatokhoz

Ha szükséges, módosítsa az ER-típusú diagramokat

3. A Chelsea futballklub információkezelő rendszeréhez kifejlesztett relációs adatbázis megvalósítása Access 2003 DBMS környezetben.

4. Készítsen legalább 2 jelentést és legalább 5-7 lekérdezést az adatbázisba DBMS eszközök, valamint a QBE és SQL nyelvek felhasználásával, a Szervezetben való használatuk indoklásával.


Bevezetés

Az adatbázis egy adott témával vagy feladattal kapcsolatos információk gyűjteménye, mint például a vásárlói rendelések nyomon követése vagy zenei gyűjtemény karbantartása. Ha az adatbázist nem, vagy csak egy része tárolja a számítógépen, akkor számos más forrásból is nyomon követhetők az információk, amelyeket a felhasználónak magának kell koordinálnia és rendszereznie.

Az adatbázisok Microsoft Access használatával történő fejlesztése gyors és pontos módszer. Az adatbázisok mindenhol elérhetőek, ami arra utal, hogy használatuk nagyban leegyszerűsíti a szervezetek különböző műveleteit.

A Microsoft Access segítségével táblázatokat, űrlapokat és egyéb adatbázisokat alkotó objektumokat hozhat létre. Különlegesség a lekérdezések létrehozása SQL lekérdezéssel.

A lekérdezéseket az adatok különféle módokon történő megtekintésére, módosítására és elemzésére használják. A lekérdezések űrlapok, jelentések és adatelérési oldalak rekordforrásaként is használhatók.

Az SQL-lekérdezés különböző utasításokkal létrehozott lekérdezés, például: Select, UpDate vagy DELETE. Az SQL-lekérdezések példái közé tartoznak a csatlakozási lekérdezések, a szerverlekérdezések, a vezérlőlekérdezések és az alárendelt lekérdezések.

Ez a kurzusmunka egy SQL-ben és QBE-ben bemutatott táblázatokból és lekérdezésekből álló adatbázist mutat be.


1. A Chelsea labdarúgóklub tevékenységének ismertetése

információkezelő hozzáférési adatbázis

A Chelsea Football Clubot 1905-ben alapították Londonban. Ez a klub az angol bajnokságban (English Championship) játszik. A Chelsea FC-nek van egy beceneve a szurkolók körében - az Arisztokraták. Ez a becenév London gazdag területéről származik. Az a terület, ahol Foggy Albion leggazdagabb polgárai élnek. A Chelsea FC teljesítményét a 20. században gyengének tartották, ezért Angliában átlagosnak számított. 1955-ben lettek először Anglia bajnokai. A Chelsea FC ritkán játszott az európai kupákban, és a siker sem volt lenyűgöző. 1971-ben azonban sikerült megnyerniük a Kupagyőztesek Európai Kupáját, miután előző évben megnyerték az FA-kupát. A 20. század végén az arisztokraták újabb Kupagyőztesek Kupát, majd Európa Szuperkupát nyertek. Ez volt a klub történetének legnagyszerűbb címe. Amikor a Chelsea FC-t az orosz milliárdos, Csukotka kormányzója, Roman Abramovics megvásárolta, a klub számos sztárjátékost szerzett, mint Petr Cech, Ricardo Carvalho, Claude Makelele, Jeremy stb. Ilyen játékosokkal a klub Európa egyik legerősebbjévé vált. 2005-ben pedig megszerezte második bajnoki címét Angliában. A közelmúltban olyan nem kevésbé híres játékosok csatlakoztak a klubhoz, mint Arjen Robben, Michael Ballack, Andrej Sevcsenko, Didier Drogba. Ezek a játékosok segítettek megnyerni a harmadik angol bajnoki címet. A Chelsea FC az elmúlt két évben bejutott a Bajnokok Ligája elődöntőjébe.

A Stamford Bridge stadion, ahol a Chelsea játszik, 42 ​​142 fő befogadására alkalmas VIP-ülésekkel együtt. A klub elnöke Bruce Buck. Az arisztokratáknak saját weboldaluk van a rajongóknak: www.chelseafc.com.

A Chelsea futballklub irányítási rendszere több alrendszerre osztható:

Együttműködés a csapattagokkal, mind a fő, mind a tartalék tagjaival. Ez a bekezdés az ifjúsági csapattal való munkáról is szól. Ez az alrendszer a legfontosabb bármely mérkőzés megnyeréséhez.

Munka a személyzettel, nevezetesen a csapatedzővel, a kapusedzővel, az ifjúsági csapat edzőjével, az orvosokkal, a marketingszakemberekkel, a stadion személyzetével, a szurkolói képviselővel stb.

A rajongókkal való együttműködés az erkölcsi támogatás fő része. A szurkolók száma határozza meg egy klub népszerűségét a világon.

A klub pénzügyeivel való munka meghatározza az anyagi helyzetet. Itt számítják ki a játékosok, edzők, orvosok, menedzserek fizetését stb. A pénzügyi helyzet azt mutatja, hogy a klub képes különféle tranzakciókat lebonyolítani, például játékosokat vásárolni megerősítés céljából, korszerűsíteni a stadiont és a klub melletti egyéb épületeket.

Bármely klubtag fizetése a klubban betöltött pozíciójától függ. Ezért minden embernek megvan a saját státusza, amely meghatározza fizetését és szerepét.

A játék minősége is befolyásolja a fizetést. Erre a célra felveszik az elért eredményeit, amelyek a mérkőzések, gólok, kupák számát jelzik. A játékos paraméterei, például magassága és súlya, meghatározzák a harcban való állapotát. Ezen adatok alapján a játékos az ellenfél adatait figyelembe véve kerül egy mérkőzésre. A játékos életkora meghatározza a játékban szerzett tapasztalatait és képességeit.

A futballpályán lévő helyet szerepnek nevezzük. A játékos szerepkör szerinti megválasztása nagyon fontos a csapat játékának minősége szempontjából. Ha egy játékos megsérül, cserére van szükség. De kivel helyettesítsük? Ehhez a vezetőedző szerep szerint választ a rendelkezésre álló játékosok között. Ha nincs elég játékos, akkor az edző a vezetőséghez fordul, hogy egy másik klubtól kell focistát vásárolni.


2.Az adatbázis „entitás-kapcsolat” modelljének kidolgozása

Az entitás-kapcsolat modell kidolgozásához a következő tervezési szakaszokra van szükség:

1. Azonosítsa az entitásokat és a köztük lévő kapcsolatokat.

2. Készítsen ER-típusú diagramokat.

3. Előzetes kapcsolatok halmazának kialakítása, az elsődleges kulcsok feltüntetésével.

4. Nem kulcsfontosságú attribútumok hozzáadása a kapcsolathoz.

5. Előzetes kapcsolatok redukálása 3 erősített normál formára.

A Chelsea futballklub „Entity-connection” modelljének fejlesztése:

1. szakasz: Állapot (kód, állapot típusa)

Játékos (Kód, Vezetéknév, Keresztnév, Szerep, Életkor, ...)

Eredmény (Vezetéknév, Keresztnév, Mérkőzések száma...)

Szerződés (szerződésszám, vezetéknév...)

Személyzet (kód, vezetéknév, keresztnév)

2. szakasz: Válassza ki a kapcsolatokat, és határozza meg a tagsági osztályt:

A játékos állapota van

A játékosnak vannak eredményei

A személyzetnek státusza van

A játékos megfelel a Szerződésben foglaltaknak

A személyzet betartja a Szerződést

A kapott adatok alapján ER-típusú diagramot készítünk:


Játékos
Állapot
1 1
Szerződés
A játékosnak
1 1 1 1
Játékos
Eredmények
M 1 1 1

3. szakasz: Az előzetes kapcsolatok halmazának kialakítása a szabályok szerint történik:

1. szabály: Ha egy bináris kapcsolat mértéke 1:1 és a CP kötelező, akkor egy kapcsolat jön létre. Az elsődleges kulcs bármely entitás kulcsa lehet.

2. szabály: Ha a kapcsolódás mértéke 1:1 és a CP O-N, akkor az egyes entitások esetében az elsődleges kulcsokhoz viszonyítva alakul ki, amelyek a megfelelő entitások kulcsai, majd a kapcsolathoz, az entitáshoz amelynek kötelező CP-je van, az opcionális CP-vel rendelkező entitás kulcsa hozzáadásra kerül attribútumként .

3. szabály: Ha a kapcsolat mértéke 1:1, és mindkét entitás tagsági osztálya nem kötelező, akkor három elsődleges kulcsú kapcsolatot kell használni, két viszonyt, amelyeket arányok kötnek össze.

4. szabály: Ha a kapcsolódás mértéke 1:M és a CP tagsági osztály kötelező, akkor elegendő két kapcsolatot kialakítani, minden entitáshoz egyet.

5. szabály: Ha a kapcsolódás mértéke 1:M, és egy M-vel összekapcsolt entitás tagsági osztálya nem kötelező, akkor 3 kapcsolatot kell kialakítani, 2 kapcsolódó entitásoknak megfelelő kapcsolatot, amelyek kulcsai ebben a kapcsolatban az elsődlegesek. .

6. szabály: Ha az M:M kapcsolat mértéke és az entitás tagsági osztálya kötelező, akkor az független az entitás tagsági osztályától.

Az 1. szabály szerint: 1. Állapot (kód, állapot típusa…)

Az 5. szabály szerint: 1. Állapot (kód, állapot típusa…)

2. Játékos (kód, vezetéknév……)

3. Szerződés (Szerződés száma, vezetéknév…)

Az 1. szabály szerint: 1. Eredmények (Vezetéknév,...)

A 2. szabály szerint: 1. Személyzet (Kód, Vezetéknév...)

2. Szerződés (Szerződés száma, vezetéknév...)


3. Adatbázis fejlesztése Access 2003 DBMS környezetben

3.1 Táblázatok létrehozása

A Microsoft Access segítségével táblákat hozhat létre tervezési módban, táblákat hozhat létre varázsló segítségével, és táblázatokat hozhat létre adatok megadásával.

A Chelsea Football Club adatbázisa 5 táblázatot tartalmaz, amelyeket a Table Wizard segítségével hoztak létre.

A Táblázatvarázsló segítségével gyorsan hozhat létre táblázatokat a meglévő adatokból, ami nagyban leegyszerűsíti a munkáját.




Van egy kattintási esemény. A gombokhoz tartozó kattintásesemény-kezelőket az A. függelékben mutatjuk be. Következtetések A tanfolyami munka során megvalósult a munka célja – gazdasági számviteli adatbázis megtervezése egy futballklub számára. A cél elérése érdekében számos feladatot oldottak meg: tárgyköri leírás összeállítása; fogalom- és terminusszótár összeállítása; a kezdeti modell felépítése (ER-...

Az aggregátumokat nem geometriai alakzatok, hanem szimbólumok vagy jelek ábrázolják, amelyek bizonyos mértékig visszaadják a statisztikai adatok külső képét. Ennek a grafikus ábrázolási módszernek az előnye a nagyfokú áttekinthetőségben rejlik, hogy hasonló megjelenítést kapunk, amely tükrözi az összehasonlított populációk tartalmát. Minden diagram legfontosabb jellemzője a méretarány. Ezért, hogy...

... „Traktor”, „Dynamo”, „Torpedo”, „Kamvolshchik”, „Lokomotiv”, „Skvich” futballkomplexum építése, beleértve az arénát, egy stadiont szabványos futballpályával. 2. Minszk - Fehéroroszország társadalmi-gazdasági fejlődésének forrása A nemrég 940 éves Minszk mindenkor nagy közigazgatási egység volt - egy apanázs fejedelemség fővárosa, vajdasági központ a Nagy...

Mindig is azt hittem, hogy akik a futballban dolgoznak, azok kiváltságosak. Fizetést kapunk azért, hogy olyan munkát végezzünk, amit szeretünk és élvezünk. És az én esetemben szerencsés is voltam, hiszen különböző országokban dolgoztam, különböző kultúrákkal, munkamódszerekkel találkoztam, és bővítettem tudásomat és tapasztalataimat. Ez pedig segít abban, hogy a dolgokat különböző szemszögből nézzem az elemzés során.

Amikor az emberek megvitatják az átigazolásokat, a játékosok piaci értékeit és az okokat, hogy miért veszel vagy adsz el egy játékost, könnyen belátható, hogy sokan nem veszik észre a lényeget. A helyzet túl bonyolult és zavaró lehet a rajongók számára. És ebben a cikkben megpróbálom bemutatni az ilyen problémákkal kapcsolatos véleményemet, személyes tapasztalatok alapján.

Természetesen a klubnál a felelősségi körömre fogok koncentrálni. Ez a futball, a játék iránya, amelyet a menedzser vagy az edző határoz meg – a helyzettől függően.

A klub felépítése

Az első dolog, amit meg kell határoznod, amikor egy új klubhoz jössz, a céljai és a rendelkezésre álló erőforrások pontosan ennek a célnak az eléréséhez. Fontos, különösen, ha külföldön dolgozik, alaposan elemezze a klubstruktúrát.

Szabályok, tabella, keret, klub alkalmazottai és jogköreik, játékos szerződések, környezet, kultúra, klubhagyományok... Mindezek ismerete nagyon fontos a helyes döntések meghozatalához. Legalábbis azokat, amelyek tőled függnek.

Spanyolországban és Olaszországban létezik egy „labdarúgó igazgató” vagy „Cserkészvezető” pozíció. Elméletileg ő a felelős az edző szerződtetéséért és a keret pótlásáért. A legtöbb esetben, bár nem mindig, tanácsot ad a felelősnek, vagy az elnöknek/tulajdonosnak, aki felelős minden olyan folyamatért, ahol az ő végső szóra van szükség.

Angliában mindezt a Menedzser végzi. Feladatkörébe tartozik minden futballügy intézése, beleértve a mérkőzés összetételének meghatározását is.

A gyakorlatban mindkét típusú struktúra egy dologtól függ: az átigazolásokhoz rendelkezésre álló forrásoktól és a játékosok fizetésétől. A „menedzser” és az „edző” is óhatatlanul szembesül azzal, hogy csak három-négy játékost van lehetőségük leigazolni a listájáról. Ez valójában igaz. Ez utóbbi esetben a menedzser kiválaszthatja azokat, akiket akar.

A kompozíció kialakulása

A probléma technikai oldalának felelőseként Önnek kell kiválasztania azt a játékmodellt, amely szerint csapata a pályán viselkedik. Fontos, hogy minden játékost megismerjünk, beszélgessünk velük, megtudjuk véleményüket az összeállítással kapcsolatban. Ha szükséges, egészítse ki a klipet olyan előadókkal, akik képesek minőségileg megerősíteni. Ha nem rendelkezik ezzel a lehetőséggel, akkor a meglévő csapatot a játékmodellhez kell igazítania, és remélnie kell, hogy a játékosok támogatást nyújtanak, amikor szüksége van rá.

Ezenkívül a különböző országok eltérő megközelítést alkalmaznak a szerződések elkészítésében. A nemzetközi versenyeken résztvevő klubokra speciális feltételek vonatkoznak. Vannak bajnokságok, ahol ebből az országból 5 játékosnak kell játszania, másokban limitált a külföldiek szerződtetése, másokban „A” és „B” listákra osztják a játékosokat... Végül minden ország, minden liga rendelkezik saját jellemzőit. És ezeket teljesen meg kell emésztenie, mielőtt csatlakozik a csapathoz, és úgy dönt, hogy megváltoztatja.

Kell lennie egy tervnek, egyfajta „futballprojektnek”. De ha olyan tulajdonosokkal beszélünk, akik az üzleti világból érkeznek a futballhoz, azt csak „üzleti tervnek” szabad nevezni.

És itt ismét a saját tapasztalataimra térek ki. Amikor Olaszországba jöttem, nem volt „üzleti terv”. Erről csak az átigazolási időszak utolsó napján tudtam meg, amikor hirtelen értesültem arról, hogy a klub pénzügyi fair playt fog követni.

Spanyolországban a klubvezetéssel való folyamatos párbeszéd lehetővé teszi, hogy betartsa a gazdasági korlátozásokat, megérti, hol van. Bár egyik nap meglepett az elnök kezdeményezésére, augusztus utolsó napján egy támadószerzés. Ezt az átigazolást a játékos olcsó költségeivel indokolta, mivel kölcsönben volt.

Angliában, különösen a Liverpoolban az első három szezonom során, az elnök-vezérigazgató tájékoztatott minden elérhető korlátozásról és lehetőségről. Később a klubstruktúra megváltozott, és fokozatosan az üzleti terv minden futballprojektnél fontosabbá vált a fontos döntések meghozatalakor.

Amiről szintén nem szabad megfeledkezni, az az ifjúsági akadémia tevékenysége. A helyi játékosokkal való játék nagymértékben növeli a klubhoz való kötődését, és jelentősen csökkenti a költségeket. Spanyolországban és Olaszországban az utánpótlás struktúrát a sportigazgatóra bízzák, a vezetőedző nem szán rá sok időt. Ami Angliában megtörténhet, az történt velem az utolsó liverpooli évemben: a menedzser teljes mértékben irányítja az egész utánpótlás-rendszert, és folyamatosan ugyanazt a játékstílust űzheti minden korosztályban. A barcelonai ifjúsági munkastruktúra jelenleg népszerűsége csúcsán van. Ennél kézenfekvőbb és szembetűnőbb példát nem találni ebben a tekintetben.

A közeljövőben az első csapatban játszani tudó fiatal esélyesek hiányában meg kell nézni az átigazolási piacot.

A sportigazgatónak vagy menedzsernek az ellenőrzése alatt kell tartania az átigazolási költségvetést, valamint ki kell számítania a játékosok fizetését. A jó felderítőhálózat elengedhetetlen, bár nem bolondbiztos, és a pénz befolyásolja bizonyos piaci rések elérhetőségét a klubod számára. A bevétel és a kiadás fontosabb egy menedzsernek, mint egy edzőnek.

Szabályok és előírások fajtái

Amit szintén figyelembe kell venni, az a különféle nemzetközi szabályozás. Általában az első csapat nevezése a szezonra 25 játékosra korlátozódik. Egyes országokban, például Spanyolországban, 5 meccsen játszhat egy juniort, ami után be kell kerülnie a főkeretbe.

Angliában az utánpótlás-válogatott játékosainak szolgáltatásait vehetik igénybe, amelyben az utánpótlást képeztük, ők pedig megkapták az első csapatba kerüléshez szükséges tapasztalatokat.

Rendelkezésedre áll az U18-as csapat. Néhány onnan származó játékosnak, különösen, ha külföldről van, profi szerződéssel kell rendelkeznie. Ellenkező esetben más klubok kikaphatják őket az orra alól.

A Liverpoolnál töltött idő alatt a szurkolók gyakran mondták, hogy túl sok játékost szerződtem le, pedig valójában sokan külön junior csoportban edzettek, és néhányukat nem is ismertem. Spanyolországban az ilyen játékosok a második ifjúsági csapathoz csatlakoznak, és nem szerepelnek a főcsapat megszerzéseinek nyilvántartásában. Ugyanez az elv érvényes Olaszországban is.

[A cikkhez fűzött kommentekben Rafa megjegyezte, hogy a spanyol rendszer jobb, mint az angol, hiszen az utánpótlás-játékosok nem lógnak a társaik között, az alsóbb osztályokban felnőtt focit játszanak, így sokkal könnyebben érthető a versenyképességük magas szintje]

Bajnokok Ligája

Egy másik szabályrendszer, amit mindig figyelembe kell vennünk, hogy a Bajnokok Ligájába való jelentkezéskor saját és helyi diákjaink is szerepeljenek a listán. Ez a szám elérte a 4-et az „akadémiájuk gyakornokai” rovatban, és 4 helyi játékosra is szükség van. Ha egy futballista több mint 3 évet töltött egy klubban, mielőtt betölti a 21. születésnapját, akkor saját tanítványának minősül.

Megint vannak különbségek. Az edző csak a csapatával foglalkozik, az összeállítás a sportvezető kiváltsága. De a menedzsernek tervet kell készítenie a jövőre nézve. A Liverpoolnál a következő feladatot kaptuk: több, 21. születésnapja előtt legalább 3 éves fiatal játékost hozni külföldről (Ayala, Pacheco, Insua), így az akkori szabályok szerint a jövőben tanítványainknak tekintenék, ami segítené a klubot az átigazolásokon és a szerződéskötéseken spórolni, és bekerülne a Bajnokok Ligája pályázatába is. Spanyolországban és általában Európában edzőként csak akkor vesz részt a következő évek tervezésében, ha több éve dolgozik és trófeákat nyer. Ez keveseknek sikerül.

Néhány valós rendszer tanulmányozása két szakaszból áll: az elemzési szakaszból és a szintézis szakaszból.

A rendszer elemzése a rendszer részeinek szétválasztása a rendszer összetételének tisztázása érdekében. Az előző bekezdésben azt mondtuk, hogy a rendszer minden része egy alrendszer, és ennek az alrendszernek megvannak a maga részei. A rendszert azonban lehetetlen a végtelenségig bővíteni. Valaminél meg kell állni, egyes részeket egyszerű, majd oszthatatlan elemként kell elfogadni. Az a kérdés, hogy hol lehet megállítani a rendszer „töredezettségét”, a vizsgálat céljától függ. A rendszer tanulmányozásának célja modelljének megszerzése - hozzávetőleges elképzelés a rendszer felépítéséről és működéséről. Az így kapott modellt a rendszer bizonyos feltételek melletti viselkedésének előrejelzésére, a rendszer vezérlésére, a rendszer működésében fellépő hibák diagnosztizálására stb.

Egy rendszer működési mechanizmusát azonban lehetetlen úgy megérteni, ha csak az összetételét azonosítjuk. Ismerni kell a rendszer részei közötti kapcsolatok szerkezetét. A rendszer állapotát és viselkedését csak az összetétel és a szerkezet összessége értheti meg. Ezért kutatásának első szakasza a rendszerelemzés. A második szakaszt szintézisnek nevezik. A "szintézis" szó kombinációt jelent.

A szintézis részek mentális vagy valós összekapcsolása egyetlen egésszé. A szintézis eredményeként egy holisztikus rendszerszemlélet jön létre, és kifejtik a rendszerhatás mechanizmusát.

A rendszerelemzés a valós objektumok és jelenségek rendszerszemléletű vizsgálata, amely az elemzés és a szintézis szakaszaiból áll.

Egy rendszer bármely leírása modell jellegű, azaz korlátozott számú tulajdonságát tükrözi. A rendszermodell felépítésénél az a fő kérdés, hogy milyen jellemzők lényegesek a jövőbeli modell felhasználási céljai szempontjából?

Fekete doboz modell

A legegyszerűbb esetben elegendő, ha elképzelésünk van a rendszer és a külső környezet kölcsönhatásáról, anélkül, hogy belemennénk a belső szerkezetének részleteibe. Például összetett háztartási készülékek használatakor nem feltétlenül kell tudnia, hogyan működnek. Elég tudni, hogyan kell használni, azaz milyen vezérlési műveleteket lehet vele végrehajtani (mi a bemenet), és milyen eredményeket kapsz (mi a kimenet). Mindezeket az információkat a felhasználói kézikönyv tartalmazza, ezt a rendszerleírást nevezzük „fekete doboz” modellnek (1.2. ábra).

A rendszer bemenete a külső környezet által a rendszerre gyakorolt ​​hatás, a kimenet pedig a rendszer által a környezetre gyakorolt ​​hatás. Ebben a modellben a rendszer belső felépítése rejtett. Ezért nevezik „fekete doboznak”.

A felsőoktatási rendszerhez nem kötődő ember szemszögéből az egyetem „fekete doboz”, amelynek bemenete az iskolai végzettségűek, kimenete pedig az okleveles szakemberek.

Összetételi modell

Mint fentebb megjegyeztük, egy rendszer elemzésének eredménye az összetételének meghatározása. Ha a rendszer leírását a részeinek felsorolására korlátozzuk, akkor egy kompozíciós modellt kapunk. Például az „Egyetemi” rendszer kompozíciós modelljét az ábra mutatja be. 1.3.

ábrán jelöltek mindegyike. A rendszer 1.3 komponensei Az „Egyetem” egy alrendszer, amelynek saját összetétele van. Ezért ezekhez az alrendszerekhez saját kompozíciós modelleket is készíthet. Természetesen egy ilyen modell nem elég ahhoz, hogy megértsük, hogyan működik egy egyetem. Ennek ellenére részletesebb képet ad az egyetemről, mint a fekete doboz modell.

A rendszer szerkezeti modellje

A rendszer szerkezeti modelljét szerkezeti diagramnak is nevezik. A szerkezeti diagram a rendszer összetételét és belső kapcsolatait tükrözi. A grafikonok a rendszer szerkezeti diagramjának megjelenítésére szolgálnak.

A gráf csúcsokból áll, amelyek a rendszer elemeit jelzik, és élekből - vonalakból, amelyek a rendszer elemei közötti kapcsolatokat (kapcsolatokat) jelzik. A sokak számára ismerős moszkvai nagysebességű szállítási séma (1.4. ábra) egy példa a grafikonra. A csúcsok itt metróállomások, az élek pedig vonatvonalak. Ez a séma lehetővé teszi a metró utasának, hogy meghatározza mozgásának útvonalát bármely állomás között. A metró elrendezése tükrözi annak radiális gyűrűs szerkezetét.

A grafikon egy másik példája az ábrán látható. 1.5. Ez egy szénhidrogén-molekula szerkezeti modellje. A csúcsok hidrogén- és szénatomok, az élek vegyértékkötéseket képviselnek.

Két metróállomás összeköttetése egy vonallal kétirányú, mivel a vonatok mindkét irányban közlekedhetnek. A molekula atomjai közötti vegyértékkötésnek szintén nincs előnyös iránya. Az ilyen gráfokat irányítatlannak nevezzük. Ha a rendszer két eleme közötti kapcsolat csak egy irányban működik, akkor az irányított nyílként jelenik meg a grafikonon. Az ilyen gráfot irányítottnak nevezzük. A gráf irányított kommunikációs vonalait íveknek nevezzük.

ábrán. Az 1.6. ábra egy példát mutat egy irányított gráfra az orvostudomány területéről. Köztudott, hogy a különböző emberek különböző vércsoportokkal rendelkezhetnek. Négy vércsoport létezik. Kiderült, hogy amikor vért adnak át egyik személyről a másikra, nem minden csoport kompatibilis. Grafikon az ábrán. 1.6 mutatja a lehetséges vérátömlesztési lehetőségeket. A vércsoportok a grafikon csúcsai a megfelelő számokkal, és a nyilak jelzik az egyik csoport vérének transzfúziójának lehetőségét egy másik csoporthoz tartozó személynek. Ebből a grafikonból például jól látható, hogy az I. csoportba tartozó vért bárkinek át lehet adni, és az I. vércsoportú személy csak a saját csoportjába tartozó vért fogadja el. Az is látható, hogy egy IV-es vércsoportú személy bármilyen vérrel átadható, de a vére csak az azonos csoportba tartozóknak adható át.

A gyakorlatban gyakran találkozunk hierarchikus felépítésű rendszerekkel, amelyek gráfját fának nevezzük (1. 7. ábra).

A fa irányított gráf, bár ábrázolásakor nem mindig rajzolunk nyilakat. Jellemzően a fák teteje a tetejétől lefelé szintekbe rendeződik. Az ívek a felső csúcsoktól az alsók felé irányulnak. Minden csúcs társítható egy legfelső szintű csúcshoz (forrás) és sok alacsonyabb szintű csúcshoz (gyermek). Az ilyen kapcsolatokat egy-a-többhöz nevezzük. A legfelső szinten lévő egyetlen csúcsot a fa gyökerének. A legalsó szinten lévő csúcsokat, amelyeknek nincs gyermekcsúcsuk, a fa leveleinek nevezzük. A fa egy összefüggő gráf Ez azt jelenti, hogy bármely két csúcs között van legalább egy út, amely összeköti őket egymással.A fában nincsenek hurkok – zárt kapcsolatok trajektóriái, ezért a fa mentén bármely két csúcs között mindig egyedi a mozgás útvonala.

A számítógép külső memóriájában a fájlrendszer felépítése hierarchikus. A fájlszerkezetet megjelenítő grafikon csúcsai mappák és fájlok. Az ívek tükrözik az egyik csúcs és a másik csúcs előfordulása közötti kapcsolatokat. A fa többszintű szerkezetű. A legfelső szintű mappát a fa gyökerének nevezik. Egy ilyen fa terminális csúcsai (levelek) fájlok és üres mappák.

Alapfogalmak rendszere

Kérdések és feladatok

1. Milyen típusú rendszermodellek léteznek? Miben különböznek?

2. Mi az a grafikon? Miből áll?

3. Melyik gráfot nevezzük irányítatlannak? Adj rá példákat.

4. Melyik gráfot nevezzük irányítottnak? Adj rá példákat.

6. Rajzolja meg a „Számítógép” rendszer grafikonjának két változatát, amely a következő csúcsokat tartalmazza: processzor, RAM, külső memória, billentyűzet, monitor, nyomtató:

A) a kommunikációs vonal az „információt továbbítja” kapcsolatot jelöli;

B) a kommunikációs vonal a kapcsolatot jelöli: „kontroll”.

Az anyag az "Adatbázis - információs rendszer alapja" témában kínál órafejlesztéseket az alapfokú oktatás 11. évfolyama számára. A fejlesztések 6 tanítási órára szólnak. Az órák a tanulók projekttevékenységeire összpontosulnak, a projektekkel kapcsolatos önálló házi feladat is beletartozik. Kétségtelen, hogy a tanulók minden projekttevékenységéhez hasonlóan a tanárnak is alaposan ismernie kell a tananyagot ezen a területen, hogy megfelelően segítse a tanulókat a projekteken való munkában. Az anyag a Semakin 10-11. osztályos tankönyv alapján készült (a házi feladat erre utal).

Letöltés:


Előnézet:

Az óra fejleményei a témában:

"Az adatbázis az információs rendszer alapja."

Számítástechnika és IKT

11. évfolyam

Számítástechnika és IKT tanár

MBOU 10. számú középiskola

Alekseeva Oksana Jurjevna

2012-2013 tanév

Alapfogalmak:

Információkereső rendszer (DB és DBMS); információs adatstruktúrák fogalma: relációs (tábla), hierarchikus (fák) és hálózati; adatbázis objektumok: mező, s A betű, kulcsmező; az „MS Access” DBMS és annak adattípusainak formátumai n interfész.

Rendszer elemzése. Infológiai modell. Az adatbázis-struktúra létrehozásának folyamata.

DBMS eszközök osztályozása és jellemzői: munkához O Ön adatbázis fájlokkal, információkkal való munkavégzéshez, rekordokkal és mezőkkel való munkához, adatbázis megjelenésének kezeléséhez, kb. b adatfeldolgozás, adatkiadás.

Az adatbázis-struktúra fogalma.

Reda k az adatbázis szerkezetének szerkesztése: mező törlése, új hozzáadása O th mezők; adatbemenet; az adatbázis mentése; az adatbázis formázása; keresés/csere; válogatás; szűrés és lekérdezés; a jelentések és űrlapok készítésének technológiájának leírása.

A téma tanulmányozásának céljai:

  1. Nevelési:
  1. ismertesse meg a hallgatókkal a fogalmakat: információkereső rendszer, adatbázis, rendszerelemzés és információs modell, adatbázis-osztályozással;
  2. bemutatni az elméleti anyag gyakorlati alkalmazását;
  3. kezdeti ismereteket nyújt a Microsoft Access adatbázis-kezelő rendszerrel való munkához.
  1. Nevelési:
  1. fejleszteni kell a tanulók algoritmikus gondolkodását, kialakítani a világnézetet, vagyis hozzájárulni az őket körülvevő világról alkotott nézetek kialakításához, az információ strukturálásához való emberi hozzájárulásról;
  2. alakítsa ki a függőségek kutatásának és keresésének ízlését;
  3. a kognitív folyamatok, például az észlelés, a figyelem, a memória fejlesztésének folytatása.
  1. Nevelési:
  1. stabil kognitív érdeklődés ápolása az informatika tantárgy iránt a téma gyakorlati alkalmazásának bemutatásával;
  2. olyan személyiségtulajdonságok ápolása, mint az aktivitás, a függetlenség és a munka pontossága;
  3. hogy a tanulókban a társadalomban való önmegvalósítás vágyát keltsék.

1. lecke Microsoft Access adatbázis

Tartalmi elemek:az adatbázis célja, az adatmodellek típusai, a relációs modell felépítése, DBMS. 1. számú gyakorlati munka „Bevezetés a Microsoft Access DBMS-be”.

Az óra típusa: lecke az új anyagok tanulásáról.

Az óra típusa: kombinált.

Munkaformák:

Felszerelés:

  1. 1. számú séma;
  2. 2. számú séma;
  3. 3. számú séma;
  4. 1. számú táblázat;
  5. Lapok az adatbázis-struktúra felépítésének sorrendjével (tanulók létszáma szerint);
  6. Iskolai osztályok listája;

AZ ÓRÁK ALATT

I. Szervezési mozzanat.Diákok köszöntése.

Képzelje el magát iskolánk igazgatójaként. Tudna-e emlékezni minden információra a tanulói teljesítményről, a szociális munkáról, a tanulói magatartásról. És a lakcím, a szülők munkahelye, az egyes tanulók egészségi állapota stb. Az ilyen rutinmunka egy nagy csapat minden vezetőjét kísérti.
Hányan tudják, hogyan tárolták korábban egy bizonyos csapat alkalmazottaira vonatkozó adatokat?(Az iratszekrényekben: fiókok formájában, ahol az alkalmazottak személyi aktái ábécé sorrendben voltak).
A számítógépek megjelenésével az emberek elkezdtek gondolkodni azon, hogyan tároljanak adatokat a számítógép memóriájában, majd hogyan dolgozzanak vele (információk keresése, kiegészítése és módosítása). Tehát speciális programokat hoztak létre, amelyek lehetővé tették mindezen műveletek végrehajtását. Ezeket információkereső rendszereknek nevezzük. Jelenleg az emberi tevékenység minden területén használják őket: bankokban, üzletekben, könyvtárakban és így tovább. Az órán áttekintjük az információkereső rendszer fogalmát, az adatbázist, az adatbázisok főbb elemeit, típusait, megismerkedünk az egyik adatbázis-kezelő rendszerrel - a Microsoft Access-lel.
II. Elméleti rész.

Nézzünk egy helyzetet egy nagy csapat vezetőjével. Mindannyian, akik ellátogatnak a könyvtárba, tudják, hogy néha hosszú ideig tart a szükséges könyv keresése a katalógusban, különösen akkor, ha nem ismeri a könyv pontos nevét és a szerzőt.
Az általam idézett helyzetekben sok a közös: nagy mennyiségű adatban keressük azt az információt, amelyre éppen szükség van. Mindkét helyzetben valójában azonos típusú objektumok halmazáról beszélünk. Ezen objektumok mindegyikénél csak néhány jellemző értéke jelentős.
Mit tartasz jeleknek a diákok számára?(Magasság, vezetéknév, keresztnév, családnév, lakcím, születési év stb.)
Minden tanulónál megadhatjuk a jellemzőinket, és megkapjuk a jellemzők értékeit.
Tehát az információkeresést számítógépre lehet bízni. Erre a célra programokat hoztak létre - információkereső rendszereket.

Az információkereső rendszer egy olyan információ tárolására szolgáló rendszer, amelyből a felhasználó kérésére a szükséges információk rendelkezésre állnak, amelyek keresése manuálisan vagy automatikusan történik.(írd a definíciót a füzetedbe).
Információ visszakeresési rendszer
két részből áll:

  1. nagy, speciálisan szervezett adatgyűjtemény (úgynevezett adatbázis);
  2. egy program, amely lehetővé teszi az adatok kezelését (DBMS - adatbázis-kezelő rendszer)(írd füzetbe).

Jelenleg több százezer információkereső rendszert hoztak létre a világon. Bankokban, könyvtárakban, kórházakban, intézetekben, üzletekben stb. használják. Egyes információkereső rendszereket nagy, központosított információkereső rendszerré egyesítik, és ún. adatbankok.

Tekintsük az 1. sémát

1. számú séma.

Alkatrészek

szervezet

Hierarchikus hálózati relációs

D.B.I.G.

IDS RUC, SQL/DS, DB2,

IMS, OKA Bank, Setor, DBASE, KAPAT,

Hálózat, FOXBASE, RBASE,

LED PARADOX, Clarion

– Tehát megvizsgáltuk az információkereső rendszer, adatbázis, DBMS fogalmait.

Gyakorlat . A tábla egy bizonyos adathalmazt mutat. Milyen, számodra hasznos információkat nyerhetsz ki belőle?

1, 3, 5; TU-154; Tyumen; 4, 7; Moszkva; 8-40; AN-24; Izhevsk; 16-20; TU-134;320; 308; 3107; 17-35; 1, 3, 5, 7.

– Ebben az adathalmazban persze érthető, hogy repülőgép indulásról beszélünk, de hogy melyik napon, milyen időpontban stb., azt nem lehet tudni. Ha ezeket az adatokat strukturáljuk, teljes információt kapunk a repülőgépek indulásáról.

Tekintsük az 1. számú táblázatot

1. sz. táblázat.

Repülőtér

találkozók

Szám

repülési

típus

repülőgép

Napok

Indulás

Idő

Indulás

Moszkva

TU-154

1,3,5

16-20

Izsevszk

AN-24

17-35

Tyumen

3107

Tu-134

1,3,5,7

8-40

– Ezt a szerkezet téglalap alakú asztal alakú. Az ilyen típusú struktúrát támogató adatbázist ún relációs (írja fel az adatbázisok típusait). A táblázat minden sora egy adott objektumhoz kapcsolódó attribútumértékek gyűjteménye. mint ez A sort rekordnak, az oszlopokat pedig a rekord mezőinek nevezzük.
A téglalap alakú táblázat az adatstruktúra egyik lehetséges ábrázolása.

2. számú séma.

A 2. ábra egy másik típusú strukturált információt mutat be. Megjelennek az intézet felépítésére vonatkozó információk.
Az ábrán látható fa háromféle objektumot tartalmaz: intézet, kar, tanszék. Ezen objektumok mindegyikét a saját jellemzői is leírják, például: intézet (név, cím, rektor); kar (név, hallgatói létszám, dékán); tagozat (név, tanári létszám, tanszékvezető).
Egy fastruktúrát támogató adatbázist hívunk hierarchikus (írd a füzetbe).

– Az adatstruktúra harmadik típusát ún hálózat.

3. számú séma.

Illusztrálva látható, hogy a hallgatók mely választható tárgyakat veszik fel.
Hálózati adatstruktúrát támogató adatbázist hívunk hálózat (írd füzetbe).
Így vannak
háromféle szerkezet adatok: relációs, hierarchikus, hálózatos.

A DB-k minősítettek: a tárolt információk jellege, az adattárolás módja, az adatszervezet felépítése szerint

  1. a tárolt információ jellege szerint
  1. tényszerű (rövid információ egy formátumban: kartoték)
  2. dokumentumfilm (mindenféle dokumentum - szöveg, grafika, videó, hang stb.: archívum)
  1. adattárolási móddal
  1. központosított (minden információ egy számítógépen, a szerveren van tárolva)
  2. elosztott (az információkat helyi vagy globális hálózaton tárolják)
  1. adatszervezési struktúra szerint
  1. relációs – táblázatos (leggyakrabban használt és univerzális)
  2. hierarchikus
  3. hálózat.

– Tehát ma már a nagy könyvesboltokban és nem csak a könyvesboltokban, a gyógyszertárakban stb., minden szükséges információ adatbázisokban megtalálható, ami segít gyorsan megtalálni a szükséges információkat. De ahhoz, hogy a számítógépben tárolt információkat felhasználhassuk, nemcsak elképzelni kell, hogyan történik ez, hanem meg kell tanulni, hogyan kell ezt saját kezűleg megtenni, vagyis adatbázist kell létrehozni, információkat keresni, különféle információkat helyettesíteni és kiegészíteni.

Az adatbázis-struktúra kialakításának alapelvei:

  1. A kidolgozott szerkezet helyessége (a mezők egyediek, típus, méret, formátum):
  1. minden táblázatelem egy adatelemet képvisel, nincsenek ismétlődő elemek;
  2. a táblázat összes mezője egységes;
  3. a mezők egyedi azonosítókkal rendelkeznek.
  1. A normalizálási feltétel teljesül (a tábla mezőinek tükrözniük kell annak az objektumnak a közvetlen jellemzőit (tulajdonságait, attribútumait), amelyhez a rekord tartozik).
  2. Az adatok teljessége.
  3. Adatkonzisztencia (rekordok megkettőzése).
  4. Kényelmes hozzáférés az adatokhoz.

Bármely adatrendszer tükrözhető táblázatok segítségével. A legegyszerűbb relációs adatbázis egy táblát tartalmaz, míg egy összetettebb több egymással összefüggő táblát is tartalmazhat.

III. 1. sz. gyakorlati munka

– Ma a leckében elkezdjük megismerkedni az adatbázisok létrehozásának folyamatával a Microsoft Access adatbázis-kezelő rendszer (relációs adatbázis) példáján. Képzeljük el, hogy mindannyian egy osztályfőnök, akinek össze kell gyűjtenie minden adatot az iskolánkban tanuló tanulókról, és minden adatot be kell vinnie a számítógépbe.

A tanulók asztalán van egy lap, amelyen az iskolánkban lévő osztályok listája található.

– A következő sorrendben építünk (az építési sorrendet tartalmazó lapokat az asztalokra fektetjük).

Adatstruktúra felépítése a következő sorrend szerint:

  1. A leírás objektumok definiáltak;
  2. Ezeknek a tárgyaknak a jellemzői meghatározásra kerülnek;
  3. Válasszon egy olyan szerkezettípust, amely megjeleníti az objektumok (táblák, fák, hálózatok) közötti kapcsolatokat;
  4. A szerkezet egy adott példánya épül fel.

Ezt a sorrendet a diagram alapján megbeszéljük a tanulókkal (kiemelve objektumok – osztályok, attribútumok – tanulólétszám, osztályfőnök b).
A tanulókkal együtt arra a következtetésre jutunk, hogy ebben az esetben a relációs adatbázis a legalkalmasabb, és ennek a struktúrának az elrendezését felrajzoljuk a táblára.
Ezután a diákok leülnek az asztalukhoz, és a tanár utasítása szerint letöltik a Microsoft Access programot.
A tanár irányítja a tanulók munkáját, parancsokat adva az adatbázis kezeléséhez:

  1. A program betöltése után a számítógép rákérdezHozzon létre egy adatbázist, Nyissa meg a korábban létrehozott adatbázisokat. Az Új létrehozása lehetőséget választjuk.
  2. Ezután a számítógép kéri, hogy adjon nevet az adatbázisának (nevezzüka kereszt- és vezetékneved), utána a kulcsot Hozzon létre.
  3. A párbeszédpanel felépítési lehetőségeket kínál:Asztal építése tervezési módban, Táblázat készítése a varázsló segítségével, Táblázat készítése adatok megadásával(a tanár beszámol az egyes lehetőségek lényegéről). Mi választunkAsztal készítése a konstruktőr segítségével.
  4. A párbeszédpanelenÚj asztal válasszon egy almenüt Konstruktőr . Megjelenik egy ablak, melybe beírjuk az objektumaink, adattípusaink jellemzőit, azaz táblázatelrendezést építünk.
  5. Ezután mentse el ezt a táblázatot a név alatt osztályok és zárja be az ablak jobb felső sarkában lévő keresztre kattintva.
  6. A táblázat neve megjelenik az adatbázis párbeszédpanelen; kattintson duplán a tábla megnyitásához. Javasoljuk a táblázat elrendezését, és itt már megadhatja az általunk meghatározott objektumkészlet jellemzőinek értékeit.

A diákok adatbázist készítenek arról, hogy ki végezte el az összes munkát, és leülnek a helyükre.

Otthon a tanulóknak meg kell tanulniuk a fogalmak összes alapvető definícióját, és meg kell találniuk, hol használják még az adatbázisokat. Tervezze meg az adatbázis elrendezését. Minta témák:

  1. Kórház (fekvőbeteg)
  2. Kórház (klinika)
  3. Az osztályod órarendje
  4. Könyvtár (könyvek, olvasók)
  5. Közúti baleset (résztvevők, autók, a baleset körülményei)
  6. Labdarúgó-bajnokság (csapatok, játékrend, meccseredmények, játékosok)
  7. Városi telefonhálózat (például az összes ismerősöm telefonja)
  8. Légi járatok (repülőgépek, pilóták, repülők, utasok)
  9. Iskolánk humán osztálya (alkalmazottak, pozíciók, szolgálati idő, ...)
  10. Üzlet (részlegek, termékek, eladók, beszállítók)
  11. Felvételi vizsgák egyetemre (karok, szakok, jelentkezők, vizsgák, felmérők)
  12. Zenei katalógus (lemezek, előadók, dalcímek)

§31. §-a utáni kérdésekre tudjon válaszolni.

VI. Összegezve a tanulságot

  1. Információ visszakeresési rendszer.
  2. Adatbázis, adatbázis-kezelő rendszer.
  3. Adatbázis.
  4. Relációs adatbázis.
  5. Rekord.
  6. Rekordok mező.
  7. Hierarchikus adatbázis.
  8. Hálózati adatbázis.

Osztályozás.

2. lecke. Többtáblás adatbázis tervezése

Tartalmi elemek: a témakör rendszerelemzése,a fő tárgyak és a köztük lévő kapcsolatok, információs modell.

Tárgykörben- ÓRATERV

Az információs rendszer használatának célja– oktatási.

Az óra típusa : lecke az új anyagok elsajátításában.

Az óra típusa : kombinált.

Munkaformák:

  1. Új anyag magyarázata - frontális munka
  2. Gyakorlati munka – egyéni munka.

Felszerelés: Szoftver: Microsoft Word.

AZ ÓRÁK ALATT

I. Szervezési mozzanat.Diákok köszöntése.A munka ellenőrzése és osztályozása.

Otthon mindenki megpróbált adatbázistáblát készíteni, és valószínűleg rájött, hogy ez nem túl egyszerű feladat. Az adatbázistáblák rendezett információkat tartalmaznak, és az információs rendszer részét képezik. Az információs rendszer fejlesztése a témakör rendszerelemzésével és információs felépítésével kezdődik(információs-logikai)modellek. A mai órán elkészítjük iskolánk órarendjének modelljét, és megrajzoljuk annak grafikonját.

II. Frontális felmérés:

Mi a modell neve?(Valamilyen célból egy új objektum az eredeti helyébe).

Mitől függenek a modell tulajdonságai?(A modell tulajdonságai a céltól függenek.)

Milyen típusú információs modelleket ismerünk?(Táblázat és grafikon)

Milyen típusú táblázatos modelleket ismerünk?(OS, LLC, ENSZ, OSO)

III. Elméleti rész.

Írd fel a füzetedbe:

Az információs modell egy valós rendszer strukturális modellje, amely tükrözi annak fő összetevőit és a köztük lévő kapcsolatokat. A rendszerelemzés egy infológiai (információs-logikai) modell létrehozásának folyamata.

Az információs modell tulajdonságai a céljától is függenek.

Határozzuk meg leendő információs rendszerünk célját. Tanulnunk kell belőle:

  1. A hét mely napjain tanulunk?
  2. Milyen órákra szól az órarend?
  3. Minden óra eleje és vége
  4. Melyik tanteremben és melyik tanárral zajlik az óra?

Készítsünk grafikont magunkróltájékoztatási rendszer(Az asztalon). Főbb objektumok és a köztük lévő kapcsolatok:

Az általunk vizsgált grafikonoktól eltérően itt a vonalak által ábrázolt összefüggések eltérő jelentéssel bírnak. Például az órák és az órarend közötti vonal azt jelenti, hogy „része van”, a tanórák és az osztálytermek között pedig azt, hogy „benne zajlik”, az órarend és az órák „azokhoz vannak összeállítva”.

Milyen egyéb összefüggéseket látunk itt? Az órarend a hét napjára "készült", az órarend az órákra "készült", az órarend "tantermekre készült" - "egy a sokhoz" típusú. Az órák „tantermekben zajlanak” – egy-egy kommunikáció. Az órák az osztálytermekben „folynak”, az osztályok „tantermekben” – „sok a sok” kapcsolat.

IV. 2. sz. gyakorlati munka.

Most pedig rajzoljunk, srácokinformációs modellinformációs rendszerünket a Word szövegszerkesztőben, és jelölje ki az összes kapcsolatot.

A tanulók rajzolnak egy információs modellt, aki az összes munkát elvégezte, és leülnek a helyükre.

V. Testnevelési perc. Gyakorlatok a szem ellazítására zene kíséretében.

VI. Házi feladat beállítása

Otthon a tanulóknak meg kell tanulniuk a fogalmak összes alapvető definícióját. Készítse el az adatbázisának infológiai modelljét (amely az 1. óra után készült)mintatémákon (lásd az előző leckét).

32. § tankönyv, tudjon válaszolni a § utáni kérdésekre.

VII. Összegezve a tanulságot

Az órán elsajátított összes új fogalmat felírják a táblára, és ezek alapján megismétlik az anyagot a tanulókkal.

  1. Rendszer elemzése.
  2. Infológiai modell.

Egy rövid felmérés segítségével megállapítható, hogy a tanulók hogyan tanulták meg az óra anyagát.

Osztályozás.

3. lecke Adatbázis létrehozása

Az óra célja: adatbázis létrehozása, kapcsolatok létrehozása többtáblás adatbázisban

Az óra típusa: Lecke a tanult anyag megerősítésére

Az óra típusa: kombinált.

Munkaformák:

  1. A munka ellenőrzése és osztályozása
  2. Felmérés az új anyag konszolidációjáról - frontális felmérés
  3. Gyakorlati munka – egyéni munka.

Felszerelés:

  1. Lapok tesztkérdésekkel az „Adatbázisok” témában (tanulók száma szerint);
  2. Szoftver: Microsoft Access DBMS.

AZ ÓRÁK ALATT

I. Szervezési mozzanat. Diákok köszöntése

II. Frontális felmérés:

Mi az a rendszerelemzés?(informológiai (információs-logikai modell) létrehozásának folyamata)

Mi az információs modell?(egy valós rendszer strukturális modellje, amely tükrözi fő összetevőit és a köztük lévő kapcsolatokat)

Mi az az információkereső rendszer?(információ tárolására szolgáló rendszer, amelyből a felhasználó kérésére a szükséges információkat biztosítják)

Miből áll?Információ visszakeresési rendszer(DB, DBMS)

Hogyan osztályozzák az adatbázisokat?? (a tárolt információ jellege, az adattárolás módja, az adatszervezés felépítése szerint)

Mi az a szerkezet?(adatszervezés típusa)

Milyen típusú adatbázis-struktúrákat ismerünk?(relációs - táblák, hierarchikus - fa, hálózat)

Mi az a mező? (DB táblázat oszlop)

Nevezze meg a terület főbb jellemzőit!

Mi az a felvétel?(DB táblázat sora)

(az ő célja)

Az előző leckékben egytáblás adatbázist hoztunk létre, ma ezt a munkát folytatjuk, és 3 további táblát hozunk létre ugyanabban az adatbázisban. Ehhez válasszon ki egy objektumot az adatbázis ablakban Táblázatok és válassza ki a lehetőségettáblázat létrehozása tervezési módban. Egy másik lehetőség, kattintson a gombra Teremt és a megjelenő párbeszédpanelen válassza ki a lehetőséget Konstruktőr . A Tervezési mód teljes ellenőrzést biztosít a létrehozott táblázat mezői felett.

Már megvan az „Osztályok” táblázat. Hozzuk létre a Hét, Ütemezés, Tanórák, Tantermeket a zárójelben feltüntetett mezőkkel (oszlopokkal). Az alábbiakban aláhúzott mezők (oszlopok) segítenek abban, hogy a későbbiekben össze tudjuk kapcsolni táblázatainkat. Így relációs adatbázisban valósítjuk meg az „Órarend” információs modellt. Adatbázisunk kielégíti az I, II, III normálformát. Írjuk le füzetekbe.

Első normálforma – minden mező oszthatatlan egy relációban.

Második normál forma – minden nem kulcsmező funkcionálisan a teljes kulcstól függ.

Harmadik normálforma – egy relációban nem lehetnek tranzitív függőségek.

III. 3. sz. gyakorlati munka.

Adatbázis "Órarend"

Az alapot alkotó kapcsolatok:

Hét (nap, hét napja)

Menetrend (nap, óra, óra , Iroda, Tárgy)

Osztályok (osztály , Tanulók száma, Class_ruk)

Leckék (lecke , Óra kezdete, lecke vége)

Szekrények (Cabinet , Emelet, Tárgy, Tanár)

Access adatbázisban használhatóháromféle kulcsmező: számláló, egyszerű kulcs és összetett kulcs.

A Számláló speciális mezőben minden rekord egyedi számot kap ehhez a mezőhöz, amely minden új rekorddal automatikusan növekszik. A bejegyzések sorszámozására használható.

Az összetett kulcs több mező kombinációja. Olyan esetekben használják, amikor egyetlen mező használatával lehetetlen garantálni egy rekord egyediségét. Ez a helyzet leggyakrabban olyan táblák esetében fordul elő, amelyek két tábla összekapcsolására szolgálnak több-többhöz kapcsolatban. Az elsődleges kulcs az egyik tábla és a másik összekapcsolására szolgál.

A csatolt táblák esetében három lehetséges kapcsolattípus létezik: „egy az egyhez”, „egy a sokhoz”, „sok a sokhoz”.

Az egyes táblák szerkezete a táblázattervezővel jön létre. A konstruktor megadja a mezőneveket, mezőtípusokat és formátumokat, valamint hozzárendeli a kulcsokat. A kapcsolatok a táblák között a létrehozásuk után, de még az adatokkal való feltöltődésük előtt jönnek létre.

A táblák összekapcsolásához a parancsokat kell futtatnia

Szolgáltatás  Adatséma. Megnyílik egy ablak Táblázat hozzáadása.

Válassza ki a tábla nevét, és hajtsa végre a parancsot Add hozzá. Bezárás.

Ennek eredményeként az ablakmezőn Adatséma 5 táblázat képei jelennek meg. Nyomja meg a bal egérgombot, és húzza a kulcsmezőt Osztály Ütemezési táblázatok a pályán Osztály táblázatból Saját alcsoport. Megnyílik egy ablak Kapcsolatok Jelölje be egymás után az „Adatok integritásának biztosítása”, „Kapcsolódó mezők lépcsőzetes frissítése”, „Kapcsolódó rekordok lépcsőzetes törlése” jelölőnégyzeteket. A One to Many kapcsolattípus automatikusan kiválasztásra kerül.

IV. Testnevelés perc. Gyakorlatok a szem ellazítására zene kíséretében.

V. Házi feladat kitűzése

Otthon a tanulóknak legalább 3 táblát és ezek közötti kapcsolatokat kell létrehozniuk az adatbázisukhoz (amely az 1. óra után készült)mintatémákon.

33. § tankönyv, tudjon válaszolni a § utáni kérdésekre.

VI. Összegezve a tanulságot

Az ezen és a korábbi leckéken tanult összes új fogalmat felírják a táblára, és ezek alapján megismétlik az anyagot a tanulókkal.

  1. Rendszer elemzése.
  2. Infológiai modell.
  3. Az objektumok közötti kapcsolatok („egy az egyhez”, „egy a sokhoz”, „sok a sokhoz”)
  4. Parancsok táblák összekapcsolásához (Tools Adatséma  táblázat hozzáadása)
  5. Három normál forma
  6. Elsődleges kulcs - típusok (számláló, egyszerű, összetett)
  7. Mire használható az elsődleges kulcs (egy tábla összekapcsolására a másikkal).

Egy rövid felmérés segítségével megállapítható, hogy a tanulók hogyan tanulták meg ezen órák anyagát.

4. lecke. Az „Órarend” adatbázis létrehozása.

Az óra céljai: többtáblás adatbázis feltöltése adatokkal

Az óra típusa : lecke a tanulmányozott anyag konszolidálásához

Az óra típusa: kombinált.

Munkaformák:

  1. A munka ellenőrzése és osztályozása
  2. Felmérés az új anyagok konszolidációjáról - frontális munka
  3. Gyakorlati munka – egyéni munka.

Felszerelés : Szoftver: Microsoft Access DBMS.

AZ ÓRÁK ALATT

I. Szervezési momentum:Diákok köszöntése.

Az utolsó órán 5 táblázat között hoztunk létre kapcsolatokat, ma pedig ezeket a táblázatokat töltjük ki, i.e. adatok hozzáadása. Emlékezzünk:

II. Frontális felmérés:

Mi az a mező? (DB táblázat oszlop)

A terület főbb jellemzői(a mezők egyediek, típusuk, méretük, formátumuk van)

Mi az a felvétel?(DB táblázat sora)

Mi befolyásolja az adatbázis struktúra kialakítását?(az ő célja)

Milyen elveket kell követni a megfelelő adatbázis-struktúra kialakításához?(a mezők egyediek, típusuk, méretük, formátumuk van; a mezők a rekordok tulajdonságait és attribútumait tükrözik; teljesség; konzisztencia; kényelmes hozzáférés)

Elsődleges kulcs - típusok és felhasználások (számláló, egyszerű, összetett; az egyik táblázat összekapcsolására a másikkal)

Milyen parancsokat kell futtatni a táblák összekapcsolásához?(Eszközök  Adatséma  táblázat hozzáadása)

III. 4. sz. gyakorlati munka.

Adattáblák:

IV. Testnevelés perc. Gyakorlatok a szem ellazítására zene kíséretében.

V. Házi feladat kitűzése

Otthon a tanulóknak egyéni adatbázisban kell táblázatokat kitölteniük.

VI. Összegezve a tanulságot

Tekintsük át az előző leckéken tanult fogalmakat:

  1. Rendszer elemzése.
  2. Infológiai modell.
  3. Az objektumok közötti kapcsolatok („egy az egyhez”, „egy a sokhoz”, „sok a sokhoz”)
  4. Három normál forma

Tartalmi elemek: IS alkalmazás lekérdezések, lekérdezésgeneráló eszközök, kiválasztási lekérdezés szerkezete: mezők listája, rekordkiválasztási feltétel, kulcsok és rendezési sorrend.

Az óra célja: lekérdezések létrehozása többtáblás adatbázisban

Az óra típusa: Lecke az új anyagok tanulásáról

Az óra típusa: kombinált.

Munkaformák:

  1. A munka ellenőrzése és osztályozása
  2. Bevezető előadás bemutatóval multimédiás kivetítőn
  3. Gyakorlati munka – egyéni munka.

Felszerelés: Szoftver: Microsoft Access DBMS, multimédiás projektor, feladatkártyák kérések teljesítéséhez (létszám szerint).

AZ ÓRÁK ALATT

  1. Szervezési idő:Diákok köszöntése.
  2. Elméleti rész.

Ha egy adatbázistáblában kell keresni, akkor használja a „Keresés” menüpontot, ha több táblában kell keresni, használja a Lekérdezést.

A lekérdezés egy többtáblás adatbázisban lévő információk keresésére szolgáló űrlap.

Lekérdezés létrehozásához meg kell nyitnia az adatbázis főablakát, és válassza a „Lekérdezések” lehetőséget - Lekérdezés létrehozása tervezési módban. Megjelenik a „Táblázat hozzáadása” párbeszédablak, amelyben ki kell választani a lekérdezéshez használt táblákat (esetünkben a Hét, Ütemterv, Osztályok, Tanórák, Tantermek táblákat). Menü - Nézet - Adatbázis objektumok.

Megnyílik a „Lekérdezés1: kiválasztási lekérdezés” ablak, ahol a felső részben a lekérdezéshez használt táblák jelennek meg (a kulcsmezők félkövéren vannak kiemelve), az alsó részben pedig a lekérdezéstervező.

A lekérdezési mezők létrehozásához egyszerűen át kell húznia azokat a forrástáblázat mezőinek listájából a „Mező” sorba.

Tekintse meg a táblázatot: Menü – Lekérdezés – Futtatás.

Változások a lekérdezésben: (például, ha lekérdezést kell létrehoznia egy feltétellel)

Menü – Nézet – Tervezési mód.

A lekérdezéskészítő a következőket is lehetővé teszi:

A) rendezze a kérésben kiválasztott adatokat egy adott mező szerint;
B) hozzon létre egy kérelmet feltételekkel.

  1. 5. sz. gyakorlati munka.

Végezze el a kártyán kapott feladatokat:

  1. Mutasd az összes számítástechnika leckét a héten
  2. Hány számítástechnika óra van a hét minden napján?

Egyszerű és összetett logikai kifejezések mintavételi körülmények között:

1. Van-e ütemezett számítástechnika óra kedden a 3. óra után, a 101-es teremben?

2. Mutasd az összes számítástechnika leckét a héten:

3. Hány számítástechnika óra a hét minden napján:

IV. Testnevelés perc. Gyakorlatok a szem ellazítására zene kíséretében.

V. Házi feladat kitűzése

Lekérdezések létrehozása és végrehajtása (legalább 2) egy egyedi adatbázisban.

34. § tankönyv, tudjon válaszolni a § utáni kérdésekre.

Példák kérésekre az egyes feladatokban.

1 . DB 2 táblázatból:

1) Könyv (szerző, cím, rövid leírás (mese, regény, publicisztika, detektív...), példányszám).
2)
Készlet (könyv címe, mennyisége, ára).

2. DB 2 táblázatból:

1) Ruhák (ruhamodell neve, varráshoz használt anyag neve, méret).
2)
Készlet (ruha neve, példányszám, ár).

Megtalálja:

Minden selyemből készült modell egyetlen példányban,
- a legdrágább modell és mérete.

3. DB 2 táblázatból:

1) Termék (név, árak, eladott mennyiség).
2)
Készlet (név, maradék készlet, kell-e még rendelnem (igen/nem)).

Keresse meg azokat a tételeket, amelyekből a legtöbbet adtak el, és döntse el, hogy rendeljen-e többet. Keressen olyan „K” betűvel kezdődő termékeket, amelyek egyenlege több mint 5 tételből áll.

4. Adatbázis 2 táblázatból:

1) Ország (név, főváros, annak a kontinensnek a neve, amelyen az ország található).
2)
Intelligencia (név, népesség, kormányzati rendszer, fő szakirány).

Megtalálja:

Minden afrikai ország, ahol a lakosság meghaladja a 100 ezer főt,
- monarchiával rendelkező ország

VI. Összegezve a tanulságot.

Osztályozás.

6. lecke. Technológia űrlapok és jelentések generálására DBMS-ben.

Az óra célja: űrlapokat és jelentéseket hozhat létre többtáblás adatbázisban

Az óra típusa: lecke a tanultak megszilárdításáról és az új anyagok elsajátításáról

Az óra típusa: kombinált.

Munkaformák:

  1. A munka ellenőrzése és osztályozása
  2. Bevezető definíciók
  3. Gyakorlati munka – egyéni munka.

Felszerelés: Szoftver: Microsoft Access DBMS.

AZ ÓRÁK ALATT

I. Szervezési mozzanat.

II. Elméleti rész.

Űrlapok - az alkalmazás és a felhasználó közötti párbeszédes felület létrehozásának fő eszköze.Létrehozható például egy űrlap, amely lehetővé teszi egymással összefüggő adatbázis-adatok kényelmes bevitelét és megtekintését a képernyőn.

Jelentések - kimeneti dokumentumok generálására tervezték, amely tartalmazza például a felhasználói problémák megoldásának eredményeit a további nyomtatáshoz. A szép dokumentumnyomtatás érdekében célszerű használni jelentéseket . A jelentések származtatott adatbázis-objektumok, és táblák, űrlapok és lekérdezések alapján jönnek létre.

III. Gyakorlati munka 6. sz.

Az utolsó leckében lekérdezéseket hoztunk létre. Ma űrlapokon és jelentéseken fogunk dolgozni.

Készítsen egy „Informatikai leckék” jelentést nyomtatáshoz.

Működési eljárás:

  1. Nyissa meg a Jelentések lapot, ha egy másik ablakban van.
  2. Kattintson a Létrehozás varázslóval gombra
  3. Több párbeszédpanel segítségével állíthatja be a jelentés megjelenési beállításait a Tovább gombra kattintva.
  4. Mentse el a jelentést „Computer Science Lessons” néven. Zárja be a jelentést
  5. Az adatbázis ablakban kattintson a Nézet gombra (vagy nyissa meg a jelentést). A dokumentum nyomtatható formában jelenik meg.

Hozzon létre saját űrlapot a 11. évfolyam H, K, Szerda órarendjének igényléséhez.

IV. Testnevelés perc. Gyakorlatok a szem ellazítására zene kíséretében.

V. Házi feladat kitűzése

Jelentések és űrlapok (legalább 2) létrehozása és végrehajtása egyedi adatbázisban.

35. §-a szerinti tankönyv, tudjon válaszolni a § utáni kérdésekre.

VI. Összegezve a tanulságot. Osztályozás.


Küldje el a jó munkát a tudásbázis egyszerű. Használja az alábbi űrlapot

Diákok, végzős hallgatók, fiatal tudósok, akik a tudásbázist tanulmányaikban és munkájukban használják, nagyon hálásak lesznek Önnek.

Közzétéve: http://www.allbest.ru/

Ukrajna Oktatási és Tudományos Minisztériuma

Csernigovi Állami Műszaki Egyetem

Információs és Számítástechnikai Rendszerek Tanszék

Szoftverrendszer "Football Championship"

Tanfolyam az „Adatbázisok szervezése” tudományágban

Befejezve

tanulók gr. KI-104A.G. Wojciechowski

A.G. paradicsom

Felügyelő

Asszisztens M.V. Harcsenko

Csernyigov 2013

Esszé

Tantárgyi munka, 86 old., 21. ábra, 9 forrás, 2 melléklet.

A tanfolyami munka fejlesztésének célja egy olyan alkalmazás megvalósítása, amely lehetővé teszi az adatbázissal való munkát vékony kliensen és asztali alkalmazáson keresztül egyaránt.

Az alkalmazásmodulok tervezésének fő módszere az UML diagramok használata. Így, ha rendelkezésre állt licencelt szoftver, lehetőség nyílt a kifejlesztett osztályok exportálására az Eclipse EE környezetbe.

A pályázat megírása során két gyárat, a DAOTourFirma-t és a ServiceTourFirma-t fejlesztették ki és hoztak létre az entitásokkal való együttműködésre. A ServiceTourFirma segítségével az üzleti logika is megvalósult.

Servlet és JSP konténertechnológiát is alkalmaztak. Mivel a servleteket és a JSP-oldalakat a HTTP protokollon keresztül hívják, a Servlet-tárolót és a JSP-tárolót gyakran egy másik komponens – egy webszerver – kíséri, amely szintén Java nyelven írható.

A Tomcat 6.0 szervert használták szerverként. Az alkalmazás a JDK 1.7-es verziójával készült.

A tanfolyami munka során a PostgerSQL 9.0 DBMS-t használták az adatbázis kezeléséhez. Létrejött egy adatbázis, amely 9 táblából áll. Minden táblának egyedi elsődleges kulcsa van idegen kulcsként. Ez a tábla meglévő információs mezőihez hozzáadott kiegészítő szolgáltatásmező, amelynek egyetlen célja elsődleges kulcsként szolgálni. Ennek a mezőnek az értékei nem az adatbázisból származó egyéb adatok alapján kerülnek kialakításra, hanem mesterségesen generálódnak. Az idegen kulcs fő előnye, hogy soha nem változik, mivel nem egy informatív táblamező

A fejlesztés során a „Football Championship” vállalati alkalmazás egy stabil verzió szintjére került. A fejlesztés eredményét a kurzusmunka mellékletében közölt szoftverprojekt formájában mutatjuk be.

A vállalati alkalmazás működéséhez minimálisan szükséges: 1024 MB RAM, legalább 1100 MHz-es Atom processzor és bármilyen böngésző. Operációs rendszer követelményei - Windows, Unix.

A munka további fejlesztése a foglalkozások munkájának javítása irányába lehetséges.

Esszé

Tantárgyi munka, 86 oldal, 21 ábra, 9 szöveg, 2 melléklet.

A fejlesztés tárgya egy olyan vállalati program, amely lehetővé teszi az adatbázissal való munkát, vékony klienssel és további webszolgáltatásokkal egyaránt.

A programmodulok tervezésének fő módszere az UML wiki - diagramok. Ily módon, ha elérhető licencelt szoftver, lehetőség nyílik osztálykiterjesztések exportálására az Eclipse EE-be.

A program megírása során két gyárat, a DAOTourFirma-t és a ServiceTourFirma-t különítették el és hoztak létre az entitásokkal való munkavégzéshez. A ServiceTourFirma segítségével az üzleti logika átfogó megvalósításra került.

Ugyanezt a technológiát használták a Servlet és a JSP konténerekhez. Mivel a szervleteket és a JSP-oldalakat HTTP-protokollon keresztül érik el, a Servlet-tárolót és a JSP-tárolót gyakran egy másik komponens – egy webszerver – kíséri, amely szintén Java nyelven írható.

A szerver tartalmazza a Tomcat 6.0 szervert. A programot a JDK 1.7-es verziójának összetevőire osztották fel.

A kurzus során a PostgerSQL 9.0 DBMS-t használták az adatbázis kezeléséhez. 9 táblából álló adatbázis készült. Minden táblának egyedi elsődleges kulcsa van, és külső. Ennek a tábla már meglévő információs mezőihez hozzáadott kiegészítő szolgáltatásmezőnek egyetlen célja van - elsődleges kulcsként szolgálni. Ennek a mezőnek az értékei nem az adatbázisból származó egyéb adatok alapján jönnek létre, hanem egyedileg generálódnak. Az idegen kulcs fő előnye, hogy egyáltalán nem változik, amíg nem tájékoztató mezője a táblázatnak.

A fejlesztés során a „Football Championship” vállalati program megszűnt, és a stabil megjelenés szintjére került. A fejlesztés eredményét egy szoftverprojekt formájában mutatjuk be, amely a tanfolyami munkához kerül.

Munkájához egy vállalati programnak legalább 1024 MB RAM-ra, legalább 1100 MHz-es Atom processzorra és bármilyen böngészőre lesz szüksége. Elérhető operációs rendszerhez - Windows, Unix.

A projekt további fejlesztése a munkamenetekkel való kifinomultabb munka irányába lehetséges.

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

Az Absztrakt

Tantárgyi projekt, 86 p., 21. kép, 9 forrás, 2 melléklet.

A cél egy olyan alkalmazás fejlesztése, amely lehetővé teszi az adatbázissal való munkát, például vékony kliensen vagy asztali alkalmazáson keresztül.

Az alkalmazási modulok tervezésének alapvető módszere - UML használata - diagramok. Így, ha szoftvert lehetne fejleszteni az osztályok exportálására az Eclipse EE környezetbe.

A pályázatok írása során két gyárat fejlesztettek ki és állítottak fel a DAOTourFirma és a ServiceTourFirma az entitásokkal való együttműködésre. A ServiceTourFirma-val tovább valósították az üzleti logikát.

A kurzus során az adatbázis üzemeltetéséhez használt DBMS PostgerSQL 9.0. Egy adatbázis, amely 9 táblából áll. Minden táblában egyedi elsődleges kulcs van külsőleg. Ez egy opcionális szolgáltatásmező, hozzáadva a tábla már meglévő információs mezőihez, és amelynek egyetlen célja elsődleges kulcsként szolgálni. Ennek a mezőnek az értékei nem képezik az adatbázisból származó egyéb adatok alapján, hanem mesterségesen generálódnak. Az idegen kulcs fő előnye, hogy soha nem változik, mert egy informatív táblamező.

Ezenkívül a technológiát használták, és Servlet-JSP-tárolót. Mivel a szervleteket és a jsp-oldalakat HTTP-protokollon keresztül hívják meg, a Servlet-JSP-tárolót és a tárolót gyakran egy másik komponens - webszerver - kíséri, amely szintén Java nyelven írható.

A vállalati alkalmazások fejlesztése során a „Football Championshipat” béta szintre emelték. A kurzusmunka mellékletében található szoftverprojekt forma kidolgozásának eredménye.

Vállalati alkalmazásához minimum: 1024 MiB RAM, a CPU nem Atom 1100 MHz alatt és böngésző. Az operációs rendszerrel szemben támasztott követelmények - Windows, Unix.

A munkamenettel végzett munka javítása érdekében további fejlesztési munkák is lehetségesek.

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

Bevezetés

1. A megoldandó probléma elemzése

1.1 Domain elemzés

1.2 A rendszer céljai és célkitűzései

1.3 A rendszer célja

1.4 Rendszerkövetelmények

2. Tervezés

2.1 Rendszerfejlesztő eszközök kiválasztása

2.1.1 Adatbázis szerver

2.1.2 Rendszermegvalósítási technológiák

2.2 Rendszer architektúra tervezés

2.2.1 Üzleti logika és üzleti szabályok rétegének kialakítása

2.2.2 Adatelérési réteg tervezése

2.2.3 Megjelenítési réteg tervezése

3. Fejlesztés

3.1 A rendszer adatbázis fejlesztése

3.1.1 Tervezze meg az adatbázissémát

3.1.2 Az adatok integritásának biztosítása

3.1.3 Alapvető lekérdezések fejlesztése

3.1.4 Szerepkörök létrehozása, indexek és nézetek kiválasztása

3.1.5 Tárolt eljárások és triggerek fejlesztése

3.1.6 Az adatvédelem megszervezése

3.1.7 Objektum-relációs leképezés

3.2 Rendszermodulok fejlesztése

3.2.1 Üzleti logika és üzleti szabályréteg modulok fejlesztése

3.2.2 Adatelérési réteg modulok fejlesztése

3.2.3 Szolgáltatási réteg modulok fejlesztése

3.2.4 Megjelenítési réteg modulok fejlesztése

A felhasznált források listája

Bevezetés

Jelenleg a számítógépek és az internetes technológiák széles körben elterjedtek az emberi tevékenység minden területén. A számítástechnika alkalmazása annak köszönhető, hogy jelentősen megkönnyíti az emberi munkát, miközben felgyorsítja a feladat elvégzéséhez szükséges időt és növeli az eredmény megbízhatóságát. Mivel a számítástechnika programvezérlés alatt működik, működése a használt szoftvertől függ. Emiatt különféle, rendkívül speciális vállalati alkalmazások készülnek.

Az adatbázis (DB) tervezése az egyik legösszetettebb és legfontosabb feladat, amely a vállalati alkalmazások létrehozásával kapcsolatos. Döntésének eredményeként meg kell határozni az adatbázis tartalmát, minden leendő felhasználója számára hatékony adatrendezési módot, adatkezelési eszközöket. Az adatbázis-tervezés fő célja a tárolt adatok redundanciájának csökkentése, és ezáltal a felhasznált memória mennyiségének megtakarítása, a redundáns másolatok többszöri frissítési műveleteinek költségének csökkentése, valamint az ugyanazon objektumra vonatkozó információk különböző helyeken történő tárolása miatti inkonzisztenciák elkerülése. helyeken.

A vállalati alkalmazás egy olyan szoftveralkalmazás, amelyet nagy mennyiségű adatok kezelésére és üzleti szabályok szerinti feldolgozására terveztek, lehetővé téve, hogy bizonyos előnyökkel járjon a vállalat (vállalkozás) számára, amikor bevezetésre kerül.

A vállalati alkalmazások nem tartalmazzák a szövegfeldolgozó eszközöket, az üzemanyag-fogyasztás szabályozását az autómotorban, a lift- és telefonközpont-berendezések vezérlését, a kémiai folyamatok automatikus vezérlését, valamint az operációs rendszereket, fordítókat, játékokat stb. Egy vállalati alkalmazás jellemzően hosszú távú (néha évtizedes) adattárolást igényel. Az adatok gyakran túlélik a feldolgozó alkalmazások, hardverek, operációs rendszerek és fordítók több generációját.

Több felhasználó párhuzamosan éri el az adatokat. Számuk általában nem haladja meg a százat, de a webes környezetben tárolt rendszerek esetében ez a szám több nagyságrenddel nő.

Nagy mennyiségű adat esetén az alkalmazásnak gazdag felhasználói felületet kell biztosítania.

A vállalati alkalmazások ritkán léteznek elszigetelten. Általában más rendszerekkel való integrációt igényelnek, amelyek különböző időpontokban épültek, különböző technológiák felhasználásával.

A vállalati alkalmazások jellemzően összetett szoftverrendszerek .

1. A megoldandó probléma elemzése

1.1 Domainelemzés

A futballbajnokság egy futballverseny. Ezt a fajta versenyt minden évben megrendezik. A bajnokság során különböző csapatok között zajlanak a mérkőzések, amelyek eredményeit egy adott selejtezőkör állásában rögzítik. A bajnokság következő lépése a döntő forduló lebonyolítása, a selejtezők győzteseiből alakul ki a résztvevő csapatok névsora. Amikor az utolsó forduló összes mérkőzését lejátszották, a szerzett pontok száma alapján megállapítható a bajnokság győztese.

A labdarúgó-bajnokság tömeges esemény, ami viszont azt jelzi, hogy szükség van egy bizonyos belső mechanizmusra, amely koordinálná a lebonyolítását. Így azonosítható a legfelsőbb végrehajtó szerv - a végrehajtó bizottság, amely teljes felelősséget vállal a bajnokság szervezéséért és lebonyolításáért. A bajnokság elnökéből és a bajnokság Kongresszusa (egy adott futballszövetség legmagasabb vezető testülete) által választott más tagokból áll. A kongresszust évente tartják. A Végrehajtó Bizottság második rendes kongresszust kezdeményezhet pénzügyi és/vagy nagyobb jelentőségű ügyek kezelésére.

A Kongresszus által megválasztott elnök és végrehajtó bizottság tagjainak hivatali ideje bizonyos számú év. A végrehajtó bizottság minden tagja újraválasztható. Csak nagyon idős tisztviselőket nem lehet megválasztani vagy újraválasztani. Ha egy hely megüresedik a végrehajtó bizottságban, a következő rendes kongresszus a jelenlegi hivatali idő lejártáig helyettesét választja ki. Ha a végrehajtó bizottsági tag megbízatásának utolsó évében egy hely megüresedik, pótlásra nem kerül sor.

A végrehajtó bizottság elnökének és tagjainak megbízatása annak a kongresszusnak a végén kezdődik, amelyen megválasztják őket, és annak a kongresszusnak a végén ér véget, amelyen az utódját megválasztják. Egy nő négy évre szóló végrehajtó bizottsági taggá történő kinevezése a végrehajtó bizottság alakuló ülésén történik.

A Végrehajtó Bizottság felhatalmazással rendelkezik a szabályzat jóváhagyására és a hatáskörén kívül eső kérdésekben döntéshozatalra. A végrehajtó bizottság irányítja egy adott labdarúgó-szövetség tevékenységét, kivéve azokat az eseteket, amikor a végrehajtó bizottság hatáskört ruházott át - vagy az Alapokmány ruházza át - a labdarúgó-szövetség elnökére vagy adminisztrációjára.

A Végrehajtó Bizottság egy vagy több tagjára ruházhatja át a döntések előkészítésének és végrehajtásának, illetve bizonyos ügyek intézésének feladatait. A Végrehajtó Bizottság arra is felhatalmazást kap, hogy részben vagy egészben hatáskört ruházzon át az elnökre, egy vagy több tagjára és/vagy az adminisztrációra.

A végrehajtó bizottság általában kéthavonta ülésezik, amikor az elnök hívja össze. Az elnök tanácsadóként harmadik feleket is meghívhat a végrehajtó bizottság ülésére.

1.2 A rendszer céljai és célkitűzései

A Football Championship rendszer célja a bajnokságok lebonyolításának automatizálása. Ez az alkalmazás tájékoztató jellegű: lehetővé teszi a győzelmek, vereségek és döntetlenek számának automatizálását, valamint a pontok odaítélését a csapatoknak a mérkőzés eredményeinek megfelelően (3 pont - győzelem, 2 - döntetlen, 1 - veszteség). Az alkalmazás lehetővé teszi új versenytáblázat adatok hozzáadását, törlését és módosítását beviteli/kimeneti űrlapok segítségével. Megtekintheti az alkalmazottak és csapatok adatait, valamint megtekintheti a 10 legjobb csapatot és az aktuális napon lejátszott mérkőzések eredményeit.

1.3 A rendszer célja

A pályaprojekt részeként kidolgozott „Futballbajnokság” rendszer minden olyan felhasználó számára készült, akit érdekelnek a mérkőzések eredményei. A jogosultság nincs megosztva a rendszerünkben. A vendég nem jelentkezhet be, hanem egyszerűen bemegy és megtekintheti a bajnoksággal kapcsolatos információkat. A vezetőnek, az elnöknek és az ügyintézőnek személyes adatokat kell megadnia az azonosításhoz a rendszerben. A személyes adatok bejelentkezést és jelszót jelentenek. Miután a felhasználó megerősítette a megadott adatokat, a szoftverrendszer ellenőrzi azok valódiságát. Először a bejelentkezést ellenőrizzük, ha nem található az adatbázisban, akkor a rendszer egy üzenetet jelenít meg, amely szerint nem létezik ilyen nevű felhasználó. Ha a név helyes, a jelszó ellenőrző összegét a rendszer ellenőrzi. Ha nem egyezik, akkor a jelszó helytelen. A rendszer nagyobb biztonsága érdekében az ellenőrző összeg kiszámítása után a teljes jelszót ellenőrzik, hogy megegyezzenek. Ha a bejelentkezési név és a jelszó valódi és megfelelő, és érték-kulcs pár, akkor a felhasználó belép a rendszerbe, és elnök, adminisztrátor vagy menedzser státuszt kap.

Az 1.1. ábra a Championship elnöki szerep használati eseteinek diagramját mutatja

1.1. ábra – A Championship elnöki szerepkör használati eseteinek diagramja

Bejelentkezés után az elnöknek a következő lehetőségei vannak: személyzeti menedzsment és költségvetés.

Az „Emberi erőforrás menedzsment” használati esete magában foglalja az új alkalmazottról szóló rekord hozzáadását, valamint az alkalmazott távozásakor a megfelelő rekord törlését. A Költségkeret létrehozása használati eset magában foglalja a fizetési rekordok hozzáadását és törlését.

Az 1.2. ábra a rendszergazdai szerepkör használati eseteit mutatja be

1.2. ábra – A rendszergazdai szerepkör használati eseteinek diagramja

Bejelentkezés után a rendszergazdának a következő lehetőségei vannak: fiókok kezelése és az üzenet ellenőrzése az adatbázisban.

A „Fiókok kezelése” használati eset a következő forgatókönyvet mutatja: Ha ez egy új felhasználó hozzáadása, akkor töltse ki a megfelelő képletet, és mentse a változtatásokat; ha ez egy felhasználó módosítása vagy törlése, akkor először meg kell találni az adatbázisban, törlés esetén a felhasználóra vonatkozó adatokat megsemmisíteni, módosítás esetén javítani és elmenteni.

Az 1.3. ábra a Manager szerepkör használati eseteinek diagramját mutatja be.

1.3. ábra – A Manager szerepkör használati eseteinek diagramja

Bejelentkezés után a Menedzsernek a következő lehetőségei vannak: a tabella bejegyzéseinek kitöltése, törlése vagy megtekintése.

Az 1.4. ábra a Vendég szerepkör használati eseteinek diagramját mutatja be.

1.4. ábra – A Vendég szerepkör használati eseteinek diagramja

Az alkalmazás letöltése után a vendég megtekintheti a tabellákat, tájékozódhat a mérkőzésekről, csapatokról.

1.4 Rendszerkövetelmények

A tanfolyami munka részeként kidolgozott „Futballbajnokság” rendszernek a következő objektumokkal kell működnie: ország, mérkőzés, alkalmazott, torna. Olyan rendszer kidolgozása szükséges, amelyben a felhasználó regisztrálni és módosítani tudja a szükséges információkat.

Bizonyos korlátozások vonatkoznak az objektumokra és az objektumok közötti interakció szabályai a rendszerben, amelyek összességét üzleti logikának nevezzük.

A rendszer üzleti logikája szerint meg kell valósítani: az adott mérkőzésen elért győzelemtől, vereségtől vagy döntetlentől függően automatikus pontok odaítélése a csapatoknak.

2. Tervezés

2.1 Rendszerfejlesztő eszközök kiválasztása

Ekkor kerül kiválasztásra az adatbázis szerver, amelyen keresztül a felhasználó kommunikál az adatbázissal, a rendszer megvalósítási technológiája és architektúrája is kiválasztásra kerül.

2.1.1 Adatbázis szerver

Jelenleg rengeteg adatbázis-kiszolgáló létezik, mint például: MySQL, PostgreSQL, Microsoft Access és mások.

A PostgreSQL egy objektum-relációs adatbázis-kezelő rendszer, amely kliens-szerver rendszerként működik. A relációs adatbázisok alapelvei alapján a PostgreSQL számos „objektum” műveletet is támogat, például az öröklődést. A PostgreSQL megfelel az SQL99 alapspecifikációjának, és támogatja az SQL92 szabványban leírt számos szolgáltatást.

Az Oracle némileg felülmúlja a PostgreSQL-t olyan területeken, mint az indexek használata, az adatreplikáció és -helyreállítás, valamint általában az adminisztrációs eszközök. Az Oracle fejlettebb (de összetettebb is). Másrészt a PostgreSQL lehetőséget biztosít a PL/Perl, PL/Python, PL/Tcl használatára eljárási nyelvként, ami lehetővé teszi a fejlesztő számára, hogy ismertebb eszközt válasszon.

A MySQL-ben minden tábla saját fájlba kerül (a legtöbb adatbázistípus esetében), egyetlen fájlszerkezetet szervezve.

A MySQL-ben a hangsúly az adatok legjobb olvasási (mintavételezési) sebességén van, ami megmagyarázza ennek a DBMS-nek a népszerűségét a webfejlesztők körében, ahol a mintavétel a fő művelet. Ezt a tranzakciók hiánya (csak bizonyos táblákhoz valósítják meg, pl. InnoDB, BerkleyDB) és a többszálú működés, de ez is az oka ennek a DBMS-nek valamivel alacsonyabb megbízhatóságának. A jogosultságokat tekintve a MySQL nem csak tábla, hanem oszlop szinten is lehetővé teszi a jogosultságok beállítását, de a PostgreSQL-ben ezt kompenzálja az egyéni nézetek létrehozásának lehetősége.

Az Apache Derby egy Java nyelven írt relációs adatbázis-kezelő rendszer, amelyet Java alkalmazásokba való beágyazásra vagy tranzakciók valós idejű feldolgozására terveztek. 2 MB-ot foglal a lemezen. Az Apache Derbyt nyílt forráskódúként fejlesztették ki, és az Apache 2.0 licenc feltételei szerint terjesztik. A Derby korábban IBM Cloudscape néven volt ismert. A Sun ugyanezeket a bináris fájlokat Java DB néven terjeszti.

Ebben a kurzusmunkában a PostgreSQL-t használtuk - olyan adatbázisok, amelyek nagyfokú információtárolási megbízhatóságot igényelnek, megnövekedett követelményeket támasztanak az összes változás ellenőrzésére, szükségük van nagyszámú adat automatikus kiigazítására, amikor az információ megváltozik az egyik táblában, mivel valamint a nem triviális megoldások kidolgozásának képességét igénylő feladatok, nem szabványos operátorok használata stb.

2.1.2 Rendszermegvalósítási technológiák

A JSP (JavaServer Pages) egy olyan technológia, amely lehetővé teszi a webfejlesztők számára, hogy egyszerűen hozzanak létre statikus és dinamikus összetevőket egyaránt tartalmazó tartalmat. Lényegében a JSP-oldal egy szöveges dokumentum, amely kétféle szöveget tartalmaz: statikus forrásadatokat, amelyek HTML, SVG, WML vagy XML szövegformátumok egyikébe formázhatók, valamint JSP-elemeket, amelyek dinamikus tartalmat hoznak létre. Ezenkívül a JSP címkekönyvtárak, valamint az EL (Expression Language) használható Java kód beágyazására a JSP-oldalak statikus tartalmába.

A JSP a nagy teljesítményű technológiák egyike, mivel a teljes oldalkódot a Jasper JSP oldalfordítójával servlet java kódra fordítják, majd Java virtuális gép (JVM) bájtkódba fordítják. A JSP-oldalak futtatására alkalmas szervlet-tárolók Java nyelven íródnak, amely különféle platformokon futhat. A JSP oldalak betöltése a kiszolgálóra történik, és a Java EE Web Application nevű speciális Java szervercsomag struktúrájából kezelhetők, többnyire .war és .ear fájlarchívumokban.

A JSP technológia előnye más webes technológiákkal szemben, hogy a JSP platformfüggetlen, hordozható és könnyen bővíthető technológia webes alkalmazások fejlesztéséhez.

A JSP 2.0 a JSP specifikáció új verziója, amely olyan funkciókkal bővült, amelyek megnövelik a programozó munkáját. Ugyanis:

– Expression Language (EL) – kifejezési nyelv, amely lehetővé teszi a fejlesztők számára többek között Velocity-stílusú sablonok létrehozását;

– egyszerűbb és gyorsabb módja új címkék létrehozásának .tag fájlokkal, most már nem kell ismernie a Java nyelvet új címkék létrehozásához;

– kényelmes módja a beágyazott babok kezelésének (JavaBeans);

– gyorsabb és egyszerűbb módja a változó paraméterek megjelenítésének.

A szervlet egy Java interfész, amelynek megvalósítása kiterjeszti a szerver funkcionalitását. A szervlet a kérés-válasz elv alapján lép kapcsolatba az ügyfelekkel.

Bár a szervletek bármilyen kérést ki tudnak szolgálni, általában a webszerverek kiterjesztésére használják őket. Az ilyen alkalmazásokhoz a Java Servlet technológia HTTP-specifikus szervlet osztályokat határoz meg.

JSTL (JavaServer Pages Standard Tag Library) – angolról lefordítva „JSP szabványos címkekönyvtár”. Kibővíti a JSP specifikációt egy JSP-címkék könyvtárának hozzáadásával az általános igényekhez, mint például az XML-elemzés, a feltételes feldolgozás, a hurkok és a nemzetköziesítés támogatása. A JSTL a JCP (Java Community Process) keretében kifejlesztett JSR 52 végeredménye.

A JSTL a JSP-be épített logika ilyen típusú alternatívája, mint például a szkriptletek, azaz a Java kód közvetlen beillesztése. A szabványos címkekészlet használata előnyösebb, mert az eredményül kapott kód könnyebben karbantartható, és könnyebb elválasztani az üzleti logikát a megjelenítési logikától.

Java Persistence API (JPA) – a Java 5-höz tartozó API a Java SE és Java EE platformokon, amely lehetővé teszi Java objektumok kényelmes tárolását egy adatbázisban.

Ennek az interfésznek számos megvalósítása létezik, az egyik legnépszerűbb a Hibernate.

Az adatintegritás támogatását biztosítja JPA, a következő területeket fedi le:

– közvetlenül a javax.persistence csomagban megadott API;

– platformfüggetlen objektumorientált lekérdezési nyelv Java Persistence Query Language;

– az objektumok közötti kapcsolatokat leíró metainformáció;

– DDL létrehozása entitások számára.

2.2 Rendszer architektúra tervezés

rétegű adatbázis modul servlet

A rendszer architektúrája megegyezik az elemzésben (1.1. ábra) és a probléma megoldási módszereivel.

Az integrációs réteg (adatforrás réteg) szerepe az, hogy lehetővé tegye az alkalmazás számára a különféle infrastruktúra-összetevőkkel való interakciót a szükséges funkciók végrehajtása érdekében. A probléma fő összetevője az adatbázissal való párbeszéd fenntartása – a legtöbb esetben relációs. A relációs rendszerek sikerének egyik legnagyobb oka az SQL támogatása, amely a leginkább szabványosított adatbázis-kommunikációs nyelv.

Az integrációs réteg megvalósításának módja az üzleti logika és az adatbázis kölcsönhatásától függ. Az ebben a szakaszban meghozott döntéseknek messzemenő következményei vannak, és nehéz vagy akár lehetetlen visszafordítani.

Ezért a leggondosabb mérlegelést érdemli. Gyakran az ilyen döntések határozzák meg az üzleti logika elrendezési lehetőségeit.

Ésszerűbb az SQL kódot az üzleti logikától elkülöníteni úgy, hogy speciális osztályokba helyezi. Az ilyen osztályok szervezésének jó módja az egyes adatbázis-objektumok struktúrájának „másolása” egy külön osztályba, amely átjárót képez, amely támogatja a táblaelérési képességeket. Mostantól a fő alkalmazáskódnak nem kell semmit „tudnia” az SQL-ről, és minden SQL-művelet az osztályok kompakt csoportjába koncentrálódik. Jobb megoldás a tartománymodell elkülönítése az adatbázistól, így a köztes szoftver teljes felelősséget vállal a tartományobjektumok adatbázis-objektumokhoz való leképezéséért. Egy ilyen adatkonverter kezeli az üzleti logika által kezdeményezett információk betöltésének és tárolásának összes műveletét, és lehetővé teszi a tartománymodell és az adatbázisséma egymástól függetlenül történő változtatását. Az alkalmazási objektumok és a relációs struktúrák közötti megfelelést biztosító építészeti megoldások közül ez a legösszetettebb, de tagadhatatlan előnye a két réteg teljes szétválasztása.

Ma a Java fejlesztők kihasználhatják a meglévő eszközök előnyeit: szerializáció, objektum-relációs leképezési eszközök, objektum adatbázisok és EJB-k. Ezen eszközök mindegyikének megvannak a saját felhasználási területei, és ezért vannak hátrányai is. A JDO kiküszöböli ezeket a hiányosságokat, és nagyobb átláthatóságot biztosít.

Sorozatosítás. Beépített Java-motor, amely az objektumokat bájtok sorozatává alakítja, amely fájlba menthető vagy hálózaton keresztül továbbítható. A sorozatosítás nagyon könnyen használható, de nagyon korlátozott is. A szerializáció használatakor az objektum egyetlen egészként kerül tárolásra. Nem támogatja a tranzakciókat vagy ugyanazon szerializált objektum használatát különböző szálakban vagy programokban anélkül, hogy konfliktusok lépnének fel közöttük;

Objektum-relációs leképezés (JPA). A JPA nem egy új technológia, hanem a legjobb elérhető technológiák, például a Hibernate, a TopLink és a JDO ötletek gyűjteménye. Ennek eredményeként a JPA egy szabványosított specifikáció, amelyet a J2EE5 tartalmaz, amely lehetővé teszi az adatmegmaradási réteg felépítését az adott szolgáltatótól függetlenül. Azok. A JPA specifikációnak számos megvalósítása lehet, ezek egyike például az OpenJPA keretrendszer vagy ugyanaz a Hibernate.

Objektum adatbázisok. Az objektum-adatbázisokat kifejezetten az objektumok tárolására tervezték, és teljes mértékben illeszkednek az objektum-orientált programozás koncepciójába. Az Object Database Management Group (ODMG) egyetlen API fejlesztésére jött létre az ilyen adatbázisokkal való munkavégzéshez. Sok adatbázis-szállító azonban még mindig tétovázik, hogy átváltson-e egy jól bevált relációs rendszerről egy objektumorientáltra. Emellett kevesebb adatelemző eszköz áll rendelkezésre az objektum adatbázisokhoz, és már nagyon nagy mennyiségű adatot tárolnak a relációs adatbázisokban. Ezen és sok más ok miatt az objektum-adatbázisok nem találtak olyan széles körben elterjedt használatot, mint ahogyan azt alkotóik remélték;

Enterprise Java Beans (EJB). Az EJB-k olyan összetevők, amelyek állapotukat relációs adatbázisban tárolják, és a perzisztens adatok objektum-orientált megjelenítését biztosítják. Az objektum-relációs leképezési termékektől eltérően az EJB-k merev specifikációval rendelkeznek, amely lehetővé teszi a különböző gyártók termékeinek használatát. Sajnos az EJB szabvány objektumorientált vonatkozásaiban korlátozott. Nem támogatják az öröklődést, a polimorfizmust stb. Az EJB-komponensek írása is sok erőfeszítést igényel, és gyakran speciális szoftverre van szükség a futtatásukhoz.

Manapság különféle keretrendszerek használják ezt a programozási technikát. Itt van néhány közülük:

Hibernálás, iBATIS, Java Data Objects (JDO), JPOX, Cayenne, TopLink, JPA.

Az ORM különféle technológiákkal történő szervezésekor objektumleképezési fájlokat kell létrehozni; konfigurációs fájlok létrehozása, amelyek meghatározzák az erőforrásfájlokat, adatforrásokat, tranzakciós támogatást stb.

2.2.1 Üzleti logika és üzleti szabályok rétegének megtervezése

Ennek a rendszernek a működési elve:

Az adminisztrátor adatokat visz be a dolgozókról, bajnokságokról, csapatokról;

A felhasználók megtekinthetik a bajnokság állását és információit;

Regisztráció nem kötelező, csak adatmódosításhoz szükséges;

Egy további tábla jött létre a sok a sokhoz kapcsolat megvalósításához. zakaz_dop_uslugi (összekapcsolja a megrendelést további szolgáltatásokkal).

Ezért lehetőség van ilyen tartományosztályok tervezésére (2.4. ábra).

2.4 ábra – Tartományosztályok

A rendszer üzleti logikája szerint a veszteségekért, nyerésekért, döntetlenekért automatikusan pontokat kell adni.

2.2.2 Az adatelérési réteg tervezése

A külső tárhelyen tárolt adatok eléréséhez a legkényelmesebb külön interfészek definiálása az adatok kezelésének módszereivel. Ezeknek a felületeknek a megvalósítása bármi lehet, például JDBC vagy JPA, JAXB vagy akár egyszerű Java gyűjtemények használatával. A JPA-t a kurzusprojekt egyszerűsítésére választották. Az adatelérési interfészek különböző implementációinak használatához célszerű az „Abstract Factory” vagy „Factory Method” tervezési mintát használni. Ebben az esetben ilyen gyár a DAOFactory absztrakt osztály, amely tartalmazza az interfészek implementációit visszaadó absztrakt metódusok definícióját (2.4. ábra).

Az összes adatelérési művelet között egyértelműen megkülönböztethetők az alapvető CRUD (létrehozás, olvasás, frissítés, törlés) műveletek - objektum létrehozása, objektum törlése, objektum frissítése, objektum lekérése azonosító alapján és összes objektum lekérése. Ha ezeket a műveleteket egy külön szuperosztályba helyezi át, elkerülhető a kódduplikáció. Az ilyen alapműveletek is átkerültek egy külön alapfelületre, az IGenericDao-ra , amely a Java Generics használatával lehetővé teszi az objektumok azon osztályának megadását, amellyel dolgozni fog.

2.4 ábra – DAO osztálydiagram

2.2.3 Megjelenítési réteg tervezése

Ez a réteg vékony kliens.

Az alkalmazással való munkavégzéshez oldalakat hoztak létre, amelyek az adatok kimenetét, hozzáadását, szerkesztését és törlését biztosítják. A főoldal, amelyre egy nem regisztrált felhasználó kerül, index.jsp. További oldalak is készültek az adatok hozzáadására és szerkesztésére, de csak rendszergazdai jogokkal.

3. Fejlesztés

3.1 A rendszer adatbázis fejlesztése

3.1.1 Tervezze meg az adatbázissémát

Az elemzés, az üzleti logikai réteg kialakítása és a szabályok alapján az adatbázis felépítése a következőképpen állítható fel (3.1. ábra)

3.1 ábra - Az adatbázis logikai diagramja

Az adatbázis fizikai elrendezését a 3.2. ábra mutatja

3.2 ábra - Az adatbázis fizikai diagramja

A szoftverrendszer adatbázisa tartalmazza az objektumokkal kapcsolatos összes információt, nevezetesen:

Versenyasztal;

Csapatok;

Felhasználó;

Munkás;

Fizetés;

Bajnokság.

Minden táblának egyedi elsődleges kulcsa van idegen kulcsként. Ez a tábla meglévő információs mezőihez hozzáadott kiegészítő szolgáltatásmező, amelynek egyetlen célja elsődleges kulcsként szolgálni. Ennek a mezőnek az értékei nem az adatbázisból származó egyéb adatok alapján kerülnek kialakításra, hanem mesterségesen generálódnak. Az idegen kulcs fő előnye, hogy soha nem változik, mivel nem egy informatív táblamező (nem hordoz semmilyen információt a rekord által leírt objektumról). Akkor van értelme idegen kulcsot használni, ha a (természetes) elsődleges kulcsot alkotó mezők változhatnak. Ebben az esetben az úgynevezett „lépcsőzetes változások” problémája merül fel. Ha idegen kulcsot használ elsődleges kulcsként, akkor nem kell módosítania. Ezenkívül idegen kulcsokat használó lekérdezések futtatásakor a mező-összehasonlítások gyorsabbak lesznek, különösen, ha a természetes elsődleges kulcs egy karakterlánc.

3.1.2 Az adatok integritásának biztosítása

Az integritási megszorításokat a 3.1. táblázat tartalmazza

3.1. táblázat – Az adatbázistáblák leírása

A táblázat neve

Leírás

Adattípus

Korlátozás

alkalmazott azonosító kódja

Elsődleges kulcs

Munkavállaló címe

sor, 20 karakter

kötelező belépés

Születési dátum

sor, 20 karakter

kötelező belépés

Vezetéknév Keresztnév. Az alkalmazott középső neve

sor, 60 karakter

a belépéshez szükséges;

Munkavállaló telefonszáma

Karakterlánc 20 karakter

kötelező belépés

Felhasználói idegen kulcs

egész szám

Bajnoki idegen kulcs

egész szám

bevitelhez; egyedi értékek

egyezzen meg az azonosító kóddal

Elsődleges kulcs

A mérkőzés dátuma

sor, 20 karakter

kötelező belépés

Idegenben lévő csapat

sor, 20 karakter

kötelező belépés

Házigazda csapat

sor, 20 karakter

kötelező belépés

Game Score

sor, 20 karakter

Túraszám

egész szám

kötelező belépés

Parancs idegen kulcs

egész szám

bevitelhez; egyedi értékek

felhasználói azonosító kód

Elsődleges kulcs

Az oldalra való belépéshez jelentkezzen be

sor, 20 karakter

kötelező belépés

Jelszó az oldalra való bejelentkezéshez

sor, 20 karakter

kötelező belépés

Szerepkörű idegen kulcs

egész szám

bevitelhez; egyedi értékek

táblázat azonosító kódja

Elsődleges kulcs

A döntetlennel lejátszott mérkőzések száma

egész szám

kötelező belépés

Pontok száma mérkőzésenként

egész szám

kötelező belépés

Az elvesztett mérkőzések száma

egész szám

kötelező belépés

A megnyert mérkőzések száma

egész szám

kötelező belépés

fizetés azonosító kódja

Elsődleges kulcs

Ledolgozott órák száma

egész szám

kötelező belépés

Prémium összeg

Valódi adattípus

A bírság összege

Valódi adattípus

Alkalmazotti idegen kulcs

egész szám

bevitelhez; egyedi értékek

engedély azonosító kódja

Elsődleges kulcs

Szerepkörű idegen kulcs

egész szám

bevitelhez; egyedi értékek

Olyan művelet, amely képes végrehajtani a megadott szerepet

sor, 30 karakter

bevitelhez; egyedi értékek

szerepazonosító kód

Elsődleges kulcs

sor, 30 karakter

kötelező belépés

csapatazonosító kód

Elsődleges kulcs

Város Név

sor, 20 karakter

kötelező belépés

Csapat név

sor, 20 karakter

kötelező belépés

Edző neve

sor, 60 karakter

kötelező belépés

Táblázat idegen kulcs

egész szám

kötelező belépés

bajnokság azonosító kódja

Elsődleges kulcs

A bajnokság időpontja

kötelező belépés

Az ország neve

sor, 40 karakter

kötelező belépés

Táblázat idegen kulcs

egész szám

kötelező belépés

3.1.3 Alapvető lekérdezések fejlesztése

Az alaplekérdezések fejlesztése során a JPQL-t választották fejlesztési nyelvnek.

Az alábbiakban a főbb lekérdezések leírása található, megvalósításuk az A függelékben található.

getKomandasByTablicaId - kérés értékek kiválasztására a „Csapat” táblából, ahol a táblázatazonosító egy parancs fogadásának paramétere.

A findKomandaByName egy parancs kiválasztására irányuló kérés, ahol a táblanév a parancs fogadásának paramétere.

getTablicaByChampionatId - kérés értékek kiválasztására a „Táblázat” táblázatból, ahol a bajnoki azonosító a táblázat megszerzésének paramétere.

getKomandasByTablicaId - kérés értékek kiválasztására a „Csapat” táblából, ahol a táblázatazonosító a táblázat lekérésének paramétere.

A findUserByNameAndPassword egy kérés, hogy válasszon értékeket a „Felhasználó” táblából, ahol a felhasználó bejelentkezési adatai megegyeznek az első paraméterrel, a jelszó pedig a második paraméterrel.

A getWorkerByChampionatId egy olyan kérés, hogy válasszon értékeket a „Worker” táblázatból, ahol a Championship id a munkavállaló megszerzésének paramétere.

getZarplatasByWorkerId - kérés értékek kiválasztására a „Bérek” táblázatból, ahol az alkalmazotti azonosító a fizetés fogadásának paramétere.

3.1.4 Szerepek létrehozása, indexek és nézetek kiválasztása

Szerepek:

Számos szerepkör jött létre különböző hozzáférési jogokkal az adatbázisokhoz:

Szerepkör létrehozása "admin" BEJELENTKEZÉS NEM TISZTÍTOTT JELSZÓ "qwerty"

"Manager" szerepkör létrehozása BEJELENTKEZÉS NEM TISZTÍTOTT JELSZÓ "qwerty1"

"Direktor" szerepkör létrehozása BEJELENTKEZÉS NEM TISZTÍTOTT JELSZÓ "qwerty2"

A chempionat, komanda, matchi, prava, "role", tablica, users, worker, zarplata kapcsolatokhoz való hozzáférési jogok az alábbiak szerint írhatók le:

engedély kijelölés, törlés, beszúrás, frissítés a chempionat, komanda, matchi, prava, "szerep", tablica, felhasználók, dolgozó, fizetés adminisztrátornak

kijelölés, törlés, beszúrás, frissítés a tablicán, a matchi-n, a csapaton a menedzsernek megadása

Indexek:

Az indexek kiválasztásánál a fő szempont az adott mezőhöz való gyakori hozzáférés volt

Az adatokkal való munka hatékonyságának javítása érdekében indexeket hoztak létre az adatok lekérésekor gyakran használt mezőkhöz:

i_worker index létrehozása a worker(id);

i_komanda index létrehozása a komanda(id);

i_matchi index létrehozása a matchi(id);

i_zarplata index létrehozása itt: zarplata(id)

Reprezentáció:

A tablica táblához való részleges hozzáférés megvalósításához a következő nézet jött létre:

w_guest (kolnichiyih,kolocheck,kolproigrashey,kolviigrashey,idchampionata) nézet létrehozása mint

válassza ki a tablicából a kolnichiyih, kolocheck, kolproigrashey, kolviigrashey, idchampionata elemeket;

szerep létrehozása vendég BEJELENTKEZÉS NEM TISZTÍTOTT JELSZÓ "qwerty3"

a w_guest-en válassza a vendégnek

3.1.5 Tárolt eljárások és triggerek fejlesztése

Kiváltó okok:

1) Egy trigger, amely értéket ír be a premiya mezőbe, amikor rekordot ad hozzá a Zarplata táblához. Ha a kolChasov mező értéke meghalad egy bizonyos értéket.

FUNKCIÓ LÉTREHOZÁSA VAGY CSERÉJE ins()

RETURNS trigger AS

FRISSÍTÉS "fizetés"

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

"zarplata", "munkás" szóból

ahol ("kolchasov" >8);

NYELV "plpgsql";

TRIGGER LÉTREHOZÁSA trig_11 „zarplata” BEHELYEZÉSE UTÁN

MINDEN SOR VÉGREHAJTÁSA ELJÁRÁST ins();

2) Trigger, amely rekordot ad a fizetési táblázat összegmezőjéhez, amikor rekordot ad hozzá vagy frissít a táblázatban. Ennek a mezőnek az értékét a ráta, büntetés és prémium mezők értéke határozza meg.

az addSumInZarplata() függvény létrehozása vagy cseréje visszaadja a triggert mint

deklarálja shtr float:=(válasszuk ki az shtraf-ot a zarplatából ahol id=new.id);

deklarálja prem float:=(válasszuk ki a premiya-t a zarplatából ahol id=new.id);

deklarálja s float:= (válasszon összeget a zarplatából, ahol id=új.id);

frissítse a fizetési készletet

summa = s+prem-shtr ahol id=új.id;

nyelv plpgsql;

trigger trigAddSumZarplat létrehozása

minden sor fizetéséről

addSumInZarplata();

Tárolvaeljárások:

1) Hozzon létre egy tárolt eljárást, amely visszaadja a ma tervezett mérkőzések listáját. Nincsenek bemeneti paraméterek. A kimeneti paraméter a match table lesz.

FUNKCIÓ LÉTREHOZÁSA VAGY CSERÉJE func_1()

RETURNS TABLE(id integer, gost karakter változó(30), hozain karakter változó(30),

schet karakter változó(10), tur integer, idkomandy integer, data date) AS $$

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

2) Dolgozzon ki egy tárolt eljárást, amely visszaadja annak a csapatnak a nevét, amelyik a legkevesebb pontot szerezte egy adott bajnokságban. Beviteli paraméterek - ország neve. A kimeneti paraméter a parancs neve lesz.

FUNKCIÓ LÉTREHOZÁSA VAGY CSERÉJE func_2 (az ország karaktere változó (40))

SELECT "name" FROM "komanda", "tablica", "chempionat" WHERE "komanda"."idtablici" = "tablica"."id" ÉS "kolocheck" IN (SELECT MIN("kolocheck") FROM "tablica") ÉS "idchampionata" IN (SELECT "id" FROM "championata" WHERE "ország" = 1 USD); $$

3) Dolgozzon ki egy tárolt eljárást, amely visszaviszi a legjobb 10 csapatot a versenytáblázatba. Beviteli paraméterek - ország neve. A kimeneti paraméter egy táblázat lesz, amely a 10 legjobb csapat nevét és pontjait tartalmazza.

FUNKCIÓ LÉTREHOZÁSA VAGY CSERÉJE func_3 (az ország karaktere változó (40))

RETURNS TABLE(_név karakter változó(20), kolocheck integer) AS $$

WITH segédlekérdezés AS (SELECT "name", "kolocheck" FROM "komanda", "tablica", "chempionat" WHERE "komanda"."idtablici" = "tablica"."id" AND "idchampionata" IN (SELECT "id" FROM "chempionat" WHERE "strana" = 1 USD) GROUP BY 1, 2 ORDER BY "kolocheck" DESC)

SELECT * FROM "allekérdezés" GROUP BY 1, 2 HAVING COUNT("név")<= 10; $$

4) Dolgozzon ki egy tárolt eljárást, amely visszaadja a csapatvezető nevét egy adott bajnokság állásában. Beviteli paraméterek - ország neve. A kimeneti paraméter a vezető neve lesz.

FUNKCIÓ LÉTREHOZÁSA VAGY CSERÉJE func_5 (az ország karaktere változó (40))

VISSZAÁLLÍTÁSA karakter változó(20) AS $$

KIVÁLASZTÁSA "név" A "komanda", "tablica", "chempionat" közül

WHERE "komanda"."idtablici" = "tablica"."id" ÉS "kolocheck" IN (SELECT MAX("kolocheck") FROM "tablica") AND "idchampionata" IN (SELECT "id" FROM "chempionat" WHERE " ország" = 1 USD); $$

3.1.6 Adatvédelmi szervezet

A kifejlesztett rendszernek több szerepe van, és mindegyikhez más-más funkcionalitás tartozik a „Football Championship” szoftverrendszerben. A szoftverrendszer egyes felhasználói típusainak képességeit a 3.2. táblázat mutatja be

3.2 táblázat - Adatvédelem

Felhasználó/

oldal

Adminisztrátor

Regisztrált Felhasználó

Nem regisztrált felhasználó

Bajnokságok listájának megtekintése, az aktuális napon lezajlott mérkőzések listája, a bajnokság táblázata, lapozás, bajnoki táblázat adatok módosítása

Tekintse meg a bajnokságok listáját, a bajnokság aktuális napján lezajlott mérkőzések listáját, lapozzon át oldalakon, lépjen a személyes információs oldalra

Tekintse meg a bajnokságok listáját, a bajnokság aktuális napján lezajlott mérkőzések listáját, navigáljon az oldalakon, és regisztráljon

Táblázat adatok szerkesztése

Tekintse meg a tabellákat, részletes információkat a csapatról, a legjobb 10 csapatot, a legjobb és legrosszabb csapatot

Tekintse meg a tabellákat, részletes információkat a csapatról, a legjobb 10 csapatot, a legjobb és legrosszabb csapatot

addEdtKomanda.jsp

A csapat adatainak szerkesztése

Részletes információk megtekintése egy csapatról

Részletes információk megtekintése egy csapatról

Találatok megtekintése, hozzáadása, törlése, szerkesztése

Mérkőzések megtekintése, meccsadatok módosítása

Meccsek nézése

Jogok hozzáadása, törlése, módosítása

Fizetés megtekintése

Fizetés megtekintése és szerkesztése

3.1.7 Objektum-relációs leképezés

A program fejlesztése során az adatok elérése történik, ezért egy ilyen program fejlesztésének egyszerűsítése, valamint a kapott adatokkal való munka hatékonyságának és sebességének növelése érdekében objektum-relációs leképezést alkalmaztunk.

Az objektum-relációs leképezés (ORM) egy olyan programozási technika, amely összekapcsolja a relációs adatbázist objektumorientált programozási koncepciókkal, és létrehoz egy "virtuális objektum adatbázist".

Az ORM-ek automatikusan szinkronizálják a memóriába betöltött objektumokat az adatbázissal. Ennek lehetővé tétele érdekében az objektum-SQL-transzformációs SQL-lekérdezés létrehozása után az eredményül kapott adatokat a rendszer az objektum mezőibe másolja, mint minden más ORM-megvalósításnál.

A relációs adatbázis-kezelő rendszerek jó teljesítményt mutatnak az adatbázis nagy részét érintő globális lekérdezéseknél, de az objektumorientált hozzáférés hatékonyabb, ha kis mennyiségű adattal dolgozik, mivel csökkenti az objektum- és a relációs adatformák közötti szemantikai rést.

Valamennyi ORM rendszer általában megnyilvánul valamilyen formában, ami valamilyen módon csökkenti az adatbázis figyelmen kívül hagyásának lehetőségét. Ráadásul a tranzakciós réteg lassú és nem hatékony (különösen a generált SQL tekintetében). Mindez azt eredményezheti, hogy a programok lassabban futnak és több memóriát használnak, mint a kézzel írt programok.

Az ORM azonban megkíméli a programozót a nagy mennyiségű, gyakran monoton és hibára hajlamos kód írásától, ezáltal jelentősen megnöveli a fejlesztés sebességét. Ezenkívül a legtöbb modern ORM implementáció lehetővé teszi, hogy a programozó szükség esetén szigorúan meghatározza az SQL lekérdezési kódot, amelyet bizonyos műveletekhez (adatbázisba mentés, betöltés, keresés stb.) használni fog egy állandó objektum segítségével.

Az adatokhoz való hozzáférést igénylő alkalmazás fejlesztésénél egyszerűsíteni kell az ilyen alkalmazás fejlesztését, növelve a kapott adatokkal való munka hatékonyságát és sebességét. Ezért ez a probléma ma is aktuális.

A probléma megoldására a JPA-t (Java Persistence API) választottuk.

Az alábbi diagram a JPA architektúra fő összetevői közötti kapcsolatot mutatja be.

3.3. ábra – JPA architektúra

Perzisztencia – Az osztály statikus segédmetódusokat tartalmaz az EntityManagerFactory szolgáltatótól független beszerzéséhez.

Az EntityManagerFactory egy olyan felület, amelynek megvalósítása az EntityManager objektumok létrehozásának gyára.

Az EntityManager az alkalmazásokban használt fő JPA interfész. Minden EntityManager tárolt objektumok halmazát kezeli, és tartalmaz egy API-t az új objektumok beszúrásához és a meglévők törléséhez. Minden EntityManagerhez saját EntityTransaction tartozik, és az EntityManager a Query objektumok gyáraként is működik.

Entitás – olyan entitás, amely tárolt objektum.

Az EntityTransaction egy olyan objektum, amely tranzakciókezelést hajt végre, amikor tárolt entitásobjektumokkal hajt végre műveleteket. A műveletek csoportosítva vagy teljesen befejeződnek, vagy nem, így az adattár változatlan állapotban marad.

A Query egy interfész a lekérdezések végrehajtására a meghatározott feltételeknek megfelelő tárolt objektumok megtalálásához. A JPA támogatja a Java Persistence Query Language (JPQL) és a szabványos Structured Query Language (SQL) lekérdezéseket. A Query példányokat az EntityManager objektumból szerezheti be.

3.2 Rendszermodulok fejlesztése

3.2.1 Üzleti logika és üzleti szabályréteg modulok fejlesztése

Ez a modul az adatbázisunkban lévő összes entitás leírását tartalmazza. Tizenegy osztályt foglal magában, nevezetesen:

A Matchi.java egy olyan osztály, amely leírja az egyezéseket. A következő információkat tartalmazza: mérkőzés dátuma, vendég, házigazda, mérkőzés eredménye, fordulószám. Módszereket tartalmaz a mezők megszerzésére és írására.

A Komanda.java egy parancsokat leíró osztály. A következő információkat tartalmazza: csapat neve, edző neve, csapat városa. Módszereket tartalmaz a mezők megszerzésére és írására.

A Tablica.java egy osztály, amely leírja a versenytáblázatot. Mezőket tartalmaz: csapatpontok száma, vereségek, győzelmek és döntetlenek száma. Módszereket tartalmaz a mezők megszerzésére és írására.

A Championat.java egy bajnokságot leíró osztály. A következő információkat tartalmazza: a konferencia kezdő dátuma, befejezési dátuma, annak az országnak a neve, ahol a konferenciát tartják. Módszereket tartalmaz a mezők megszerzésére és írására.

A Worker.java egy dolgozót leíró osztály. A következő adatokat tartalmazza: az alkalmazott teljes neve, születési ideje, telefonszáma, címe. Módszereket tartalmaz a mezők megszerzésére és írására.

A User.java egy olyan osztály, amely leírja a felhasználót. A következő információkat tartalmazza: bejelentkezési név és jelszó a rendszerbe való belépéshez. Módszereket tartalmaz a mezők megszerzésére és írására.

A Role.java egy olyan osztály, amely leírja a felhasználó szerepét. A következő információkat tartalmazza: felhasználónév. Módszereket tartalmaz a mezők megszerzésére és írására.

A Prava.java egy olyan osztály, amely leírja a felhasználói jogokat. A következő információkat tartalmazza: azokat a jogokat, amelyek alapján a felhasználó bejelentkezik a rendszerbe

3.2.2 Adatelérési réteg modulok fejlesztése

Az adatok elérése a DAO segítségével történik. Ezt a modult két csomag képviseli interfészekkel és azok implementációival. A következő interfészeket tartalmazza:

– ITablicaDao.java – olyan felület, amely a táblával való munkavégzés módszereinek leírását tartalmazza. A következő módszereket írja le:

nyilvános gyűjtemény A getTablicasByChampionatId(Integer chId) a PersistenceException metódust dobja, hogy egy adott bajnokság összes asztalát megkapja.

A metódusok megvalósítása a TablicaDaoJpa osztályban található.

– IKomandaDao.java – egy felület, amely a parancsok listájával való munkavégzés módszereinek leírását tartalmazza. A következő módszereket írja le:

a)nyilvános Gyűjtemény getKomandasByTablicaId(Integer chId) dobások PersistenceException módszer egy adott tabella összes csapatának megszerzésére;

b)nyilvános A Komanda findKomandaByName(String name) PersistenceException metódust dob ​​a parancs név szerinti lekéréséhez.

c) a getTheWorstKomandaByChampId(karakterlánc neve) PersistenceException metódust dob, hogy a bajnokság legrosszabb csapatát szerezze meg;

d)nyilvános String getTheBestKomandaByChampId(String name) PersistenceException metódust dob, hogy megszerezze a legjobb csapatot a bajnokságban;

e)nyilvános Gyűjtemény A getTopTenKomandasByChampId(String name) PersistenceException metódussal dobja be a bajnokság legjobb 10 csapatát;

...

Hasonló dokumentumok

    Adatbázis szerkezet. Egy prezentációs rétegből, egy üzleti rétegből és egy adatbázisrétegből álló háromszintű architektúra vizualizálása, UML diagramokkal megvalósítva. Háromrétegű alkalmazások alapvető szerkezeti jellemzői. Egyes modulok forráskódja.

    tanfolyami munka, hozzáadva 2012.11.03

    A fejlesztés alatt álló szállodai adatbázis modelljének tervezése. Triggerek, tárolt eljárások, lekérdezések fejlesztése. Felhasználói felület létrehozása. A regisztrációval, könyveléssel, kereséssel kapcsolatos munka automatizálása, valamint a munkáltatókról szóló jelentések készítése.

    tanfolyami munka, hozzáadva 2015.11.29

    A vállalkozásban meglévő főbb adatfolyamok jellemzői. A szoftverfejlesztés módszerei és eszközei. Felhasználói felület kialakítása. Adatbázis interakciós réteg fejlesztése. Üzleti szolgáltatási réteg kialakítása.

    szakdolgozat, hozzáadva: 2017.10.07

    Funkcionális függőségek meghatározása. Az adatbázis szerkezetének fejlesztése. Lekérdezések rendszerezése az adatbázisban. Triggerek használata az adatok naprakészen tartásához. Tárolt eljárások és funkciók fejlesztése. Az adatbázis-karbantartás korlátai.

    tanfolyami munka, hozzáadva 2014.06.17

    Az adatbázis lényege egy halmaz, fájlok gyűjteménye, amelyben információk találhatók. Az adatbázis-kezelő rendszer olyan szoftverrendszer (alkalmazás), amely adatbázissal (adatfájlokkal) való munkát biztosít. A triggerek használatának célja és előnyei.

    tanfolyami munka, hozzáadva 2011.02.22

    Relációs adatbázis tervezése, az abból való információ-visszakeresés megszervezése. Nézetek fejlesztése az eredmények megjelenítéséhez. Tárolt eljárások tervezése. Adatkezelési mechanizmus triggerekkel. A műszaki támogatás követelményei.

    szakdolgozat, hozzáadva: 2011.07.03

    Bútorgyártáshoz "Termékkönyvelés" webes felülettel rendelkező szerver típusú adatbázis fejlesztése, hibakeresése. Fizikai adatmodell. Ismertesse meg az indexeket és a megszorításokat, a lekérdezéseket és az adatnézeteket, a jelentéseket és a diagramokat. A triggerek és a tárolt eljárások leírása.

    tanfolyami munka, hozzáadva 2015.02.20

    Adatkezelési nyelv. Adatkiválasztási folyamat. Aggregált függvények és speciális operátorok használata kiválasztási feltételek mellett. Nézetek és tárolt eljárások létrehozása és használata. Triggerek használata, felhasználói felület kialakítása.

    labormunka, hozzáadva 2013.02.13

    Az adatbázis logikai és fizikai felépítése. Rendszer hardver és szoftver. Nézetek, tárolt eljárások, egyedi függvények, triggerek létrehozása. Az ASP.NET dokumentumok alapstruktúrájának leírása. Felhasználói felület.

    tanfolyami munka, hozzáadva 2013.05.21

    Az adatbázis fogalma. Táblázatok, adatbeviteli és -kiadási űrlapok, alapvető lekérdezések, tárolt eljárások és triggerek fejlesztése a Bulletin Board adatbázishoz. Nyomtatás előkészítése. Adminisztrációs és információbiztonsági eszközök szükségességének elemzése.

 


Olvas:



Türkiz függönyök a belső térben: frissesség és elegancia Sötét türkiz függönyök

Türkiz függönyök a belső térben: frissesség és elegancia Sötét türkiz függönyök

A türkiz története Nemrég Európában a türkiz gyászszín volt. Minden ember türkizkék ruhába öltözött egy hozzátartozója halála esetén...

Modern türkiz függönyök a belső térben: jellemzők, kombinációk, típusok és dizájn Fehér tüll türkiz függönnyel

Modern türkiz függönyök a belső térben: jellemzők, kombinációk, típusok és dizájn Fehér tüll türkiz függönnyel

A nappali türkiz függönyei a fő textilkiegészítők, amelyek egyedi bájt és kényelmet adhatnak a helyiségnek. A függönyöket úgy tekintik...

Bézs függönyök - a függöny bézs árnyalatának tökéletes kombinációja (70 fotó) Függönyök a konyhához bézs tónusban

Bézs függönyök - a függöny bézs árnyalatának tökéletes kombinációja (70 fotó) Függönyök a konyhához bézs tónusban

Minden alkalommal, amikor hazatér, szeretné érezni szülőfészkének kényelmét és meghittségét. Amikor készen áll arra, hogy karjaiba vegyen minden megjelenésével és...

Tulipán virágok. Tulipán virág. Tulipán termesztése. Tulipán gondozása Tulipán termesztett növény

Tulipán virágok.  Tulipán virág.  Tulipán termesztése.  Tulipán gondozása Tulipán termesztett növény

A turbán a földön nő. Egy látszólagos csúsztatás felfedi a tulipán nevének lényegét. Hazájuk Közép-Ázsia. Keleten észrevették a bimbók hasonlóságát...

feed-image RSS