Agjencia Federale për Arsimin
Institucion arsimor shtetëror i arsimit të lartë profesional
"UNIVERSITETI SHTETËROR CHELYABINSK"
Puna e kursit
Zhvillimi i aplikacionit të bazës së të dhënave
Analiza e domenit
Përshkrimi i fushës lëndore dhe funksionet e detyrave që zgjidhen
Në punën e kursit, në përputhje me detyrën, aktivitetet e departamentit të shitjeve të ndërmarrjes ruse të ushqimit janë të automatizuara.
Lënda e automatizimit janë disa nga funksionet e punës së departamentit të shitjeve. Departamenti i shitjeve ka një plan lëshimi të produktit të përfunduar të hartuar për tre muaj. Në përputhje me këtë plan, punishtet prodhojnë produkte, por prodhimi aktual varet nga shumë faktorë dhe mund të ndryshojë nga ai i planifikuar. Departamenti i shitjeve merr edhe faturat e dyqaneve, të cilat pasqyrojnë prodhimin aktual të produkteve dhe dërgimin e tyre në magazina të caktuara.
Detyra e departamentit të shitjeve është të analizojë zbatimin e planit për dërgimin e produkteve në depo. Për ta bërë këtë, ju duhet të zgjidhni të dhënat e planifikuara dhe aktuale për periudhë të caktuar për një magazinë specifike dhe analizoni devijimin e faktit nga plani.
Kompania ka 3 punishte në të cilat prodhohen produkte. Gama e produkteve është paraqitur në tabelë.
Tabela 1.
Emri i punishtes Emri i produktit të prodhuar Njësia minimale e prodhimit Çmimi për njësi qumësht 3,5% kuti 50 copë 650,00 RUR 1 qumësht 4,0% kuti 50 copë 700,00 RUR krem, kuti me 50 copë 1200,00 RUB sallam i zier, pako me 50 copë 2,500,00 RUB 2 suxhuk sallam i tymosur, pako me 50 copë 3,400,00 RUB salsiçe, pako me 50 copë 1200,00 RUB purtekë e konservuar pike, kuti me 50 kanaçe 670,00 RUB 3 havjar peshku, kuti e zezë me 50 kanaçe 5,400,00 RUB kuti havjar i kuq me 50 kanaçe 5,370,00 RUR Produktet e prodhuara nga punishtet dorëzohen në magazina Tabela 2. Magazina nr. Emri i magazinës 1 Magazina nr. 12 Magazina nr. 23 Magazina nr. 3 Lista e dokumenteve hyrëse (primare). Si dokumente parësore për zgjidhjen e këtij problemi përdoren dokumentet e mëposhtme: plani i prodhimit për punëtori lista e faturave të dyqaneve Numri i punishtes Numri i faturës së punishtes Data e dorëzimit specifikimi i faturës së dyqanit Numri i punishtes Numri i faturës së punishtes Kodi i produktit Sasia Kufizimi i zonës së lëndës. Kur zhvilloni një projekt kursi, lejohen kufizimet e mëposhtme: produkti i përfunduar caktohet në një depo të produktit të përfunduar dhe mund të prodhohet në disa punishte. produkti i përfunduar ka vetëm një njësi matëse. një punishte mund të prodhojë disa lloje produktesh. Disa lloje të produkteve të gatshme mund të ruhen në një depo. Prodhimi i produkteve të gatshme nga punishtja është planifikuar çdo muaj. I njëjti produkt mund të planifikohet të lëshohet në muaj të ndryshëm. Një faturë punishteje për dërgimin e produkteve të gatshme në një magazinë mund të përmbajë disa emra produktesh; numri i saj është unik vetëm për një punishte. Formulimi i problemit Thelbi organizativ dhe ekonomik i një sërë detyrash. Një nga problemet kryesore në ndërmarrje është mospërputhja midis sasisë së planifikuar të prodhimit të produktit, e cila formohet në përputhje me kërkesat e klientëve, dhe sasisë aktuale të produkteve të dërguara nga punishtet në magazina. Për të zgjidhur këtë problem, është e nevojshme të merren informacione (të menjëhershme) në kohë për disponueshmërinë, mungesën ose tepricën e produkteve në magazina në lidhje me planin. Teprica ruhet në magazinë, mund të tejkalohet afati i përdorimit dhe krijohet stoku jolikuid. Përshkrimi i informacionit dalës Ne do të paraqesim informacionin e prodhimit në formën e një formulari raportimi. Analiza e zbatimit të planit për dërgimin e produkteve në magazinë _________________ Muaji Emri i produktitNjsia e matjesSasiaTeprisPlanFakt Për të marrë këtë formular, përdoren të dhënat nga dokumentet parësore: lista e produkteve; lista e depove; lista e punëtorive; plani i prodhimit për punëtori; lista e faturave të dyqaneve; Përshkrimi i informacionit hyrës. Informacioni i hyrjes ndahet në konstante me kusht (drejtori), të cilat ruan vlerat e tij për një periudhë të gjatë kohore, dhe vazhdimisht ndryshojnë, domethënë informacione të kontabilitetit operacional. Informacioni i përhershëm me kusht përfshin: lista e produkteve të prodhuara; lista e dyqaneve prodhuese; lista e depove; libri referues i njësive matëse. Informacioni i kontabilitetit operativ përfshin: plani i prodhimit për punëtori; lista e faturave të dyqaneve; specifikimi i faturës së punishtes. Le të paraqesim dokumentet kryesore me detaje në Tabelën 3: Nr. Emri i dokumentit Detajet 1 Lista e produkteve të prodhuara 1. Kodi i produktit 2. Emri i produktit. 3. Kodi i njësisë. 4.Çmimi. 5. Numri i magazinës 3 Lista e depove 1. Kodi i magazinës. 2. Emri i magazinës 2 Lista e punishteve 1. Kodi i punishtes. 2.Emri i punishtes.4Direktoria e njësive matëse 1.Kodi i njësisë matëse. 2. Emri i njësisë matëse 5 Plani për prodhimin e produkteve sipas punishteve 1. Numri i punishtes. 2. Muaji i lëshimit. 3.Kodi i produktit. 4. Sasia 6 Lista e faturave të punishtes 1. Numri i punishtes. 2. Numri i faturës së punishtes. 3. Data e dorëzimit 7 Specifikimi i faturës së punishtes 1. Numri i punishtes. 2. Numri i faturës së punishtes. 3.Kodi i produktit. 4.Sasia. Projektimi i bazës së të dhënave Përzgjedhja e objekteve të informacionit Një nga fazat më të vështira në procesin e hartimit të bazës së të dhënave është zhvillimi i tabelave, pasi rezultatet që duhet të prodhojë baza e të dhënave (raportet, formularët e daljes, etj.) jo gjithmonë japin një pamje të plotë të strukturës së tabelës. Informacioni në tabelë nuk duhet të dyfishohet. Nuk duhet të ketë përsëritje midis tabelave. Kur një informacion i caktuar ruhet vetëm në një tabelë, atëherë ai do të duhet të ndryshohet vetëm në një vend. Kjo e bën punën më efikase dhe gjithashtu eliminon mundësinë e mospërputhjes së informacionit ndërmjet tyre tabela të ndryshme Oh. Çdo tabelë duhet të përmbajë informacion vetëm për një temë. Informacioni për secilën temë përpunohet shumë më lehtë nëse përmbahet në tabela të pavarura nga njëra-tjetra. Çdo tabelë përmban informacione për një temë të ndryshme dhe secila fushë në tabelë përmban informacion të veçantë për temën e tabelës. Për të zbatuar lidhjen e të dhënave nga tabela të ndryshme, secila tabelë duhet të përmbajë një fushë ose grup fushash që do të specifikojnë vlerën individuale të çdo regjistrimi në tabelë. Kjo fushë ose grup fushash quhet çelësi primar. Pas shpërndarjes së të dhënave nëpër tabela dhe përcaktimit të fushave kryesore, ju duhet të përcaktoni marrëdhëniet midis tabelave. Tabela 4 Objektet e informacionit Objekti i informacionit Dokumenti përkatësDetaletÇelësiProduktiLista e produkteve të prodhuara Kodi i produktitPo Emri i produktitNjësia e matjes kodiÇmimi Numri i magazinës PunëtoritëLista e punishteve Numri i punëtorisëPoEmri i punishtesDepot Lista e magazinësNumri i magazinësPoEmri i magazinës kodi i matjesU njësia e matjesNj. plani i veprimitPlani i prodhimit të produkteve sipas punishteve Numri i punëtorisëPo Numri i muajit Po Kodi i produktitPo SasiaPunëtori faturatLista e faturave të punishtes Numri i punëtorisë Po Numri i faturës së punëtorisë Po Data e dorëzimitSpecifikimet e faturës së dyqanit Specifikimi i faturës së punëtorisë Po numri i faturës së punishtes Po numri i faturës së dyqanit fatura Po Kodi i produktit Po SasiaMuajiPër “Planin e prodhimit”Objekt Emri i muajitM Modelimi informatik-logjik dhe përcaktimi i lidhjeve ndërmjet objekteve informative Një model informacioni-logjik është një model i të dhënave që shfaq një zonë lëndore si një grup objektesh informacioni dhe lidhje strukturore midis tyre. Modeli ynë informativ-logjik do të ketë formën e mëposhtme: Fig.1. Modeli infologjik Si rezultat i zhvillimit të bazës së të dhënave, u morën 8 objekte informacioni. Le të përcaktojmë llojin e lidhjes në secilën palë të këtyre informacioneve. objektet. Njësia matëse - Produkt Lloji i marrëdhënies është 1-me-shumë, pasi disa elementë mund të maten me një njësi matjeje, por secili artikull matet aktualisht me një njësi matjeje. Lidhja ndërmjet këtyre objekteve bazohet në atributin Unit of Measurement Code. Magazina - Produkt Lloji i lidhjes është 1-me-shumë, pasi disa artikuj të produkteve të gatshme mund të ruhen në një depo. Kontakt - me referencë Numri i magazinës. Produktet - Plani i lëshimit Lloji i marrëdhënies është 1-me-shumë sepse një artikull mund të planifikohet për prodhim në muaj të ndryshëm, por çdo sasi e planifikuar lidhet vetëm me një artikull në një muaj të caktuar. Detajet e kontaktit Kodi i produktit. Muaji - Plani i lëshimit Lloji i lidhjes është 1-me-shumë; një plan lëshimi i produktit hartohet çdo muaj. Kontaktoni me detaje Numri i muajit. Punëtori - Plani i prodhimit Lloji i lidhjes 1 - për shumë, një punëtori është planifikuar të lëshohet në muaj të ndryshëm. Kontaktoni me detaje Numri i seminarit. Workshops - Faturat e punishtes Punëtoritë - Specifikimet Lloji i komunikimit 1-me-shumë, një punishte lëshon shumë fatura. Kontaktoni me detaje Numri i seminarit. Faturat e punishtes - Specifikimet Lloji i komunikimit është 1-me-shumë; një faturë punishteje mund të përmbajë disa specifikime për një produkt. Detajet e kontaktit - Numri i faturës dhe numri i punishtes. Specifikat e produktit Lloji i marrëdhënies 1-me-shumë, një produkt lëshohet më shumë se një herë, por një sasi e caktuar e lëshuar i referohet vetëm një produkti. Detajet e kontaktit Kodi i produktit. Struktura logjike e bazës së të dhënave Struktura logjike e një baze të dhënash relacionale është një pasqyrim adekuat i modelit informatik-logjik që rezulton i fushës lëndore. Modeli kanonik nuk kërkon ndonjë transformim shtesë. Çdo objekt informacioni i modelit të të dhënave përfaqësohet nga një tabelë relacionale përkatëse. Struktura e një tabele relacionale përcaktohet nga përbërja e nevojshme e objektit përkatës të informacionit, ku çdo kolonë (fushë) korrespondon me një nga detajet. Detajet kryesore formojnë një çelës unik të tabelës relacionale. Për secilën kolonë të tabelës, specifikohen lloji i të dhënave, madhësia e të dhënave dhe vetitë e tjera. Topologjia e dizajnit të qarkut të të dhënave praktikisht përkon me topologjinë e modelit informatik-logjik. Në kuadër të kësaj puna e kursit struktura logjike e bazës së të dhënave do të duket si (Fig. 2.): Fig.2. Struktura logjike e bazës së të dhënave Implementimi i bazës së të dhënave në Microsoft Access Për të zbatuar bazën e të dhënave të projektuar, ne do të përdorim një nga sistemet më të njohura të menaxhimit të bazës së të dhënave për sistemin operativ Windows Microsoft Qasja. Kjo DBMS është pjesë e paketës së integruar gjerësisht të përdorur të kompanisë Microsoft Office dhe është plotësisht në përputhje me programet e kësaj pakete. Avantazhi i madh i MS Access është disponueshmëria e mjeteve të zhvillimit të sistemit të informacionit për përdoruesit e kualifikimeve të ndryshme: nga fillestarët tek profesionistët. MS Access DBMS është krijuar për të punuar me objektet e mëposhtme: Tabelat janë elementi kryesor i çdo baze të dhënash relacionale, të krijuara për të përcaktuar dhe ruajtur të dhënat; Pyetjet shërbejnë si burime për ndërtimin e pyetjeve, formularëve dhe raporteve të tjera. Pyetjet ju lejojnë të ndryshoni dhe analizoni të dhënat. Lloji më i zakonshëm i pyetjes, një pyetje përzgjedhëse, është një grup rregullash që zgjedhin të dhëna nga një ose më shumë tabela të lidhura. Rezultatet e pyetjes së përzgjedhjes paraqiten në formën e një tabele virtuale. Format janë një objekt i krijuar kryesisht për futjen e të dhënave, shfaqjen e tyre në ekran ose kontrollin e funksionimit të një aplikacioni. Është e mundur të përdoren formularët për të zbatuar kërkesat e përdoruesve për paraqitjen e të dhënave nga pyetjet ose tabelat; formularët gjithashtu mund të printohen. Raportet janë një mjet për organizimin e daljes së të dhënave për printim. Duke përdorur raportin, është e mundur të shfaqen informacionet e nevojshme në formën e kërkuar. Mund ta shikoni raportin përpara printimit. Burimet e të dhënave për raportet janë tabelat dhe pyetjet; Makrot janë një objekt që është një përshkrim i strukturuar i një ose më shumë veprimeve që MS Access duhet të kryejë në përgjigje të një ngjarjeje specifike. Modulet janë objekte që përmbajnë programe të shkruara në një gjuhë Bazë vizuale për Aplikime (VBA). Në kuadër të detyrës, nuk ka nevojë të krijohen makro dhe module në bazën e të dhënave të projektuar. Të gjitha objektet e MS Access janë të vendosura në një skedar në disk. MS Access ka një ndërfaqe me shumë dritare, por mund të përpunojë vetëm një bazë të dhënash në të njëjtën kohë. Për të krijuar një bazë të dhënash të re, duhet të nisni MS Access, zgjidhni " Baza e re data", shkruani emrin e bazës së të dhënave dhe zgjidhni vendndodhjen e saj në disk. Tabelat e bazës së të dhënave të dizajnuara janë objekte informacioni, fushat e tabelave janë detaje të objekteve të informacionit. Për të plotësuar informacionin e hyrjes, do t'ju duhet të krijoni një ndërfaqe përdoruesi - formularët: Formulari "Produkte" - për redaktimin e tabelës "Produkte"; Formulari “Plani i prodhimit” - për rregullimin e planit për numrin e produkteve të prodhuara; formulari “Faturat e Dyqanit”, që lidh tabelën “Faturat e Dyqanit” dhe tabelën “Specifikimet e faturës së Dyqanit”, e cila varet nga “Faturat e Dyqanit”. Për të zbatuar raportin "Analiza e zbatimit të planit për dërgimin e produkteve në magazinë", do të mjaftojë të ekzekutohet një kërkesë për zgjedhjen e muajit (tabela "Muaji"), emri i produktit (tabela "Produktet") , njësia matëse (tabela “Njësia e matjes”), sasia sipas planit (tabela “Plani i prodhimit”), sasitë aktuale (tabela “Specifikimet”), me shtimin e një kolone “tepricë” me formulën e zbritjes. Krijimi i tabelave dhe skemave të të dhënave bazës së të dhënave të aplikacionit këtë shitje Ekzistojnë disa mënyra për krijimin e tabelave (modaliteti i tabelës, projektuesi, magjistari i tabelave, importimi i tabelave, lidhja me tabela nga bazat e tjera të të dhënave). Mënyra më universale për të krijuar një tabelë është përdorimi i modalitetit të dizajnit. Për të krijuar një tabelë në këtë mënyrë, duhet të përcaktoni fushat e tabelës. Çdo fushë karakterizohet nga një emër, lloj i të dhënave dhe veti. Emri i fushës nuk duhet të përmbajë karaktere të veçanta. Llojet e mëposhtme të të dhënave mund të përdoren në Microsoft Access: Tekst - përdoret për të ruajtur informacionin alfanumerik. Gjatësia e fushës nuk duhet të kalojë 255 karaktere; Fusha MEMO - projektuar për të ruajtur informacione alfanumerike deri në 65535 karaktere të gjata; Numerike - përdoret për të dhënat numerike të përfshira në llogaritjet; Data/ora - data dhe (ose) koha në rangun nga 100 në 9999; monetare - përdoret për vlerat monetare dhe të dhënat numerike të përdorura në llogaritjet matematikore të kryera me një saktësi deri në 15 shifra në tërësi dhe deri në 4 shifra në pjesën e pjesshme; Numëruesi - përdoret për të gjeneruar numra unikë në rritje ose të rastësishëm që futen automatikisht në fushë kur çdo rekord i ri shtohet në tabelë. Vlerat e fushave të llojit Counter nuk mund të ndryshohen; Boolean - projektuar për vlerat Boolean (Po/Jo, E vërtetë/False). Gjatësia e fushës logjike është 1 bit; Një fushë objekti OLE është çdo objekt në format binar (dokument Word, tabelë Excel, fotografi, regjistrim zëri) i lidhur ose i ngulitur në një tabelë MS Access. Madhësia e një fushe të tillë nuk duhet të kalojë 1 GB; Magjistari i kërkimit - krijon një fushë që ofron një zgjedhje vlerash nga një listë, ose nga një kuti kombinuese që përmban një grup vlerash konstante ose vlerash nga një tabelë tjetër. Zgjedhja e këtij opsioni nga lista në një qelizë hap magjistarin e kërkimit, i cili përcakton llojin e fushës. Karakteristikat e fushës vendosen në fund të dritares së projektuesit të tabelës në skedën "Të përgjithshme". Lista e vetive është e ndryshme për çdo lloj të dhënash. Le të shohim disa prej tyre: Madhësia e fushës - kufizon gjatësinë e fushës në numrin e caktuar të karaktereve; Format - specifikon formatin për datat dhe numrat; Numri i numrave dhjetorë - për monedhat dhe fushat numerike cakton numrin e numrave dhjetorë; Maska hyrëse - për fushat e tekstit dhe fushat e datës, përcakton shabllonin sipas të cilit të dhënat do të futen në fushë; Fusha e indeksuar - ju lejon të krijoni një indeks që do të shërbejë për të shpejtuar kërkimin dhe renditjen e tabelës sipas këtë fushë. Një indeks është një tabelë e brendshme e shërbimit që përbëhet nga dy kolona: vlera e fushës së indeksuar dhe numri i tabelës. Ju mund të vendosni vetitë e mëposhtme për indekset: a) "Po (lejohen ndeshjet)" - krijohet një indeks që përfshin vlerat e fushës që përputhen, b) "Po (përputhjet nuk lejohen)" - krijohet një indeks bazuar në një unik vlera e fushës, c) "Jo " - indeksi nuk është krijuar Një tabelë në MS Access zakonisht përmban një çelës primar. Për të krijuar një çelës, duhet të zgjidhni një fushë në projektues dhe ta caktoni atë si një çelës përmes menysë së kontekstit. Lloji i të dhënave të fushës Madhësia e fushës Çelësi primar Kodi i njësisëNumerike Numër i gjatë i plotë Po Emri i njësisëText50 Tabela "Produktet" Lloji i të dhënave të fushës Madhësia e fushës Çelësi primar Kodi i produktitNumerik Numër i gjatë i plotë Po Emri i produktitTeksti100Kodi i njësisëNumërorNumër i gjatë i plotëÇmimi Monetar-Numri i magazinësNumericByte Tabela "Depot" Lloji i të dhënave të fushës Madhësia e fushës Çelësi primar Numri i magazinësBajt numerik Po Emri i magazinësTeksti20 Tabela e muajit Lloji i të dhënave të fushës Madhësia e fushës Çelësi primar Numri muaji Numri i plotë numerik Po (përputhjet nuk lejohen) Emri i muajit Teksti20 Tabela "Punëtori" Lloji i të dhënave të fushës Madhësia e fushës Çelësi primar Numri i dyqanitBajt numerik Po Emri i dyqanitText30 Tabela e planit të lëshimit Lloji i të dhënave të fushës Madhësia e fushës Çelësi parësor Numri i punëtorisëNumerikBajtiPo Numri i muajitNumerikNumri i plotëPo Kodi i produktitNumerik Numri i gjatë i plotëPo SasiaNumerikReal (16) Tabela "Faturat e punëtorisë" Lloji i të dhënave të fushës Madhësia e fushës Çelësi parësor Numri i punëtorisëNumerikBytePo Numri i faturës së seminaritNumerikNumër i gjatë i plotëPo Data e dorëzimitData\ora- Tabela "Specifikimet" Lloji i të dhënave të fushës Madhësia e fushës Çelësi primar Numri i punëtorisëNumerikBajtiPo Numri i faturësNumërorNumri i gjatë i plotë Po Kodi i produktitNumerik Numri i plotë i gjatëPo SasiaNumerikeReal (16) Krijoni një skemë të dhënash në Microsoft Access: Fig.3. Skema e të dhënave Krijim ndërfaqja e përdoruesit
Formularët janë mjeti kryesor për krijimin e një ndërfaqeje përdoruesi që ofron mënyrën më të përshtatshme për të paraqitur, parë, modifikuar të dhënat dhe menaxhuar përparimin e një aplikacioni. Funksionet kryesore të formularëve janë futja e të dhënave, shfaqja dhe redaktimi i informacionit, menaxhimi i përparimit të aplikacionit, shfaqja e mesazheve dhe printimi i informacionit. Ekzistojnë llojet e mëposhtme të formave: Normal - shfaq një rekord të burimit të të dhënave; Multipage - projektuar për të punuar me një burim të dhënash me një numër të madh fushash; Shirit - tregon disa regjistrime të burimit të të dhënave, të përshtatshme për jo sasi e madhe fusha; Pop-up - shfaqet në plan të parë ekran dhe ju lejon të punoni me forma të tjera; Ekskluzive - nuk ju lejon të kaloni në forma të tjera derisa të mbyllet; vartës - ilaç i mirë për të përfaqësuar të dhënat në anën "shumë" të një marrëdhënieje një me shumë, ato janë të ngulitura në formën kryesore dhe gjithmonë varet nga ajo. Strukturisht, formulari përbëhet nga tre seksione - një kokë, një shënim dhe një zonë të dhënash. Seksionet e formularit përmbajnë kontrolle. Çdo kontroll mund të vendoset në një formular duke përdorur shiritin e veglave, i cili shfaqet në projektuesin e formularit. Elementet më të përdorura: (mbishkrim) - përdoret për të krijuar mbishkrime të përhershme në formë; (fushë) - një element që tregon vlerën nga burimi i të dhënave; (kuti kombinuese) - synohet të krijohet në formën e listave rënëse; (buton) - synohet të krijohet në formën e butonave komandues që kryejnë veprime të caktuara; (kutia e kontrollit) - një element që ju lejon të aktivizoni ose çaktivizoni vlerën e një parametri; (forma e varur) - shërben për të futur një formë të nënrenditur në atë kryesore. Është më i përshtatshëm për të krijuar një formë duke përdorur magjistarin. Hapi i parë është të zgjidhni një burim të dhënash dhe fushat për formularin. Në hapin e dytë duhet të specifikoni pamjen formë e projektuar. Hapi i tretë është zgjedhja e një stili forme ( foto sfondi për formën, formatin e shkronjave dhe skemën e ngjyrave). Hapi i fundit është futja e emrit të formularit nën të cilin do të ruhet në bazën e të dhënave. Forma e krijuar duke përdorur magjistarin duhet të modifikohet në modalitetin e projektimit. Shtoni etiketat, butonat dhe nënformat e nevojshme. Si pjesë e punës së kursit, u krijuan format e mëposhtme: Oriz. 4. Produktet. Fig.5. Plani i lëshimit. Formulari "faturat e dyqanit" përmban një formular të varur "Specifikimet" Fig.6. Faturat e punishtes. Zbatimi i raportit Para se të krijoni një raport, duhet të krijoni një pyetje. Pyetjet janë një mjet i rëndësishëm në çdo sistem të menaxhimit të bazës së të dhënave. Qëllimi i kërkesave është në përshkrimin e llojeve të kërkesave. Pyetjet mund të krijohen ose në modalitetin Query Wizard (më pas duhet të zgjidhni llojin e pyetjes) ose duke përdorur Query Builder. Ekzistojnë katër lloje të pyetjeve në Microsoft Access: pyetjet e thjeshta të përzgjedhjes shfaqin të dhëna nga një ose më shumë tabela në formë tabelare; shtimi i një parametri (kushti i përzgjedhjes) lejohet; pyetjet e kryqëzuara mbledhin të dhëna nga një ose më shumë tabela në një format të ngjashëm me një spreadsheet dhe përdoren për të analizuar të dhënat; shtimi i një parametri (kushti i përzgjedhjes) lejohet; pyetjet e ndryshimit përdoren për të krijuar tabela të reja nga rezultatet e pyetjeve dhe për të bërë ndryshime (shtim, fshirje) në të dhëna tabelat ekzistuese; shtimi i një parametri (kushti i përzgjedhjes) lejohet; një pyetje për të gjetur rekorde që nuk përputhen me asnjë rekord në nëntabelë. Duke përdorur pyetjet në modalitetin Query Wizard (duke zgjedhur raportin përmbledhës të pyetjes), është e mundur të kryhet një llogaritje (shuma, mesatarja, minimumi, maksimumi) duke përdorur të dhënat e zgjedhura. Për të zbatuar raportin “Analiza e zbatimit të planit për dërgimin e produkteve në magazinën nr. ___”, do të mjaftojë të ekzekutohet një kërkesë për zgjedhjen e muajit (tabela “Muaji”), emri i produktit (tabela “Produktet”) , njësia matëse (tabela “Njësia e matjes”), sasia sipas planit (tabela “Plani i prodhimit”), sasitë aktuale (tabela “Specifikimet”), me shtimin e një kolone “tepricë” me formulën e zbritjes, si dhe me zgjedhjen e një numri magazine (tabela "Depot") me kushtin e përzgjedhjes pa shfaqur këtë magazinë në tabelën që rezulton. Për këtë raport, pyetja u krijua duke përdorur konstruktorin: Fig.8. Rezultati i kërkesës. Nga sasi të ndryshme Specifikimet e produktit tregojnë se purteka e konservuar e pikut është dorëzuar në magazinë dy herë në korrik dhe shtator. Gjenerimi i raporteve Raportet janë ilaçi më i mirë për të përfaqësuar informacionin nga një bazë të dhënash në formë dokument i printuar. Ato ofrojnë aftësi të gjera për grupimin dhe llogaritjen e nëntotaleve dhe totaleve të përgjithshme për grupe të mëdha të dhënash. Raportet mund të përdoren për të prodhuar fatura të dizajnuara bukur, urdhra blerjesh, etiketa postare, materiale prezantimi dhe dokumente të tjera që mund t'ju nevojiten për të drejtuar një biznes të suksesshëm. Raporti përmban fushat e mëposhtme: titulli - shfaqet vetëm një herë në fillim të raportit; header dhe footer - të përsëritura në secilën fletë të raportit, të përdorura për të shfaqur informacione të përhershme ose periodike (data e raportit, numrat e faqeve, etj.); Titujt dhe shënimet e grupit - Shfaqen kur grupohen në një raport, përkatësisht në fillim dhe në fund të secilit grup. Mund të krijoni deri në dhjetë nivele grupimi në një raport; zona e të dhënave - përdoret për të futur linjat e raporteve informative; shënim raporti - synon të shfaqë informacionin përmbledhës mbi raportin në tërësi, të printuar një herë në fund të raportit. Është më i përshtatshëm për të krijuar një raport, ashtu si një formular, duke përdorur një magjistar. Pas krijimit të një raporti, mund të ndryshoni strukturën e tij në modalitetin e projektimit (korrigjoni dhe formatoni titujt e kolonave të raportit, shtoni ose hiqni fushat, etj.). Si rezultat i ekzekutimit të raportit, merret forma e tij e printuar. Analiza e zbatimit të planit për dërgimin e produkteve në magazinën nr. 1, 2, 3 - Fig. 10-12. Fusha “Numri i faturës së punishtes” u shtua për të bërë të qartë se produkti mund të dorëzohej në magazinë dy herë në muaj duke përdorur dy fatura të ndryshme. Fig.9. Projektuesi i raportit Fig. 10. Analiza e zbatimit të planit për dërgimin e produkteve në magazinën nr.1 Fig. 11. Analiza e zbatimit të planit për dërgimin e produkteve në magazinën nr.2 Fig. 12. Analiza e zbatimit të planit për dërgimin e produkteve në magazinën nr.3 Bibliografi Tarasov V.L. Puna me bazat e të dhënave në mjedisin Access, Teksti mësimor / Universiteti Shtetëror i Nizhny Novgorod, Nizhny Novgorod, 2005. Shekhtman V.E. Bazat e të dhënave, SQL Manual arsimor dhe metodologjik për disiplinat "Bazat e të dhënave", "Bazat e të dhënave dhe sistemet e ekspertëve", " Teknologji moderne Programimi SQL". / - NFI KemSU, Novokuznetsk, 2006. Andreev V.A., Tupikina E.N., Sistemet e menaxhimit të bazës së të dhënave (Microsoft Access), udhëzime/ DVGAEU, Vladivostok, 2003. Veiskas D., Punë efektive me AKSES, tekst shkollor/ Shën Petersburg, 1996. Khomonenko A.F., Tsygankov V.M., Maltsev M.G. Bazat e të dhënave, Teksti mësimor për Universitetet / Ed. prof. A.D. Khomonenko - Shën Petersburg: shtypi CORONA, 2002.
- Tutorial
- Mënyrë shërimi
Pershendetje te gjitheve! Emri im është Oleg dhe jam një programues amator Android. Një amator sepse për momentin po fitoj para duke programuar në një drejtim krejtësisht tjetër. Dhe ky është një hobi të cilit ia kushtoj kohë e lirë. Fatkeqësisht, unë nuk njoh asnjë programues Android dhe të gjithë janë të mitë. njohuri baze E marr ose nga librat ose nga interneti. Në të gjithë librat dhe artikujt në internet që kam lexuar, krijimi i një baze të dhënash për një aplikacion i kushton shumë pak hapësirë dhe, në fakt, i gjithë përshkrimi zbret në krijimin e një klase që është trashëguese SQLiteOpenHelper dhe zbatimi i mëpasshëm i kodit SQL në kodin Java. Përveç faktit që marrim kodin e dobët të lexueshëm (dhe nëse në aplikacionin tonë shfaqen më shumë se 10 tabela, atëherë të kujtosh të gjitha këto marrëdhënie midis tabelave është ferr), atëherë në parim mund të jetojmë, natyrisht, por disi nuk duam te.
Kam harruar të them gjënë më të rëndësishme, mund të thuash që kjo është përpjekja ime e parë për të shkruar këtu. Dhe kështu le të shkojmë.
Rreth pyetjes së përjetshme: pse?
Për të qenë i sinqertë, sinqerisht nuk e di pse librat dhe artikujt mbi programimin për Android nuk përshkruajnë mjete për hartimin e arkitekturës së bazës së të dhënave dhe disa modele për të punuar me bazat e të dhënave në fazën e krijimit të tyre. Do të dukej e lehtë të shtoni vetëm disa faqe në një libër ose të shkruani një artikull të veçantë (siç po bëj tani) - por jo. Në këtë artikull, unë do të shqyrtoj shkurtimisht mjetet që përdor në punën time dhe më në detaje rreth kodit që është përgjegjës për krijimi fillestar Një bazë të dhënash që, nga këndvështrimi im, duket më e lexueshme dhe e përshtatshme.
Nëse aplikacioni ynë ka më shumë se 5 tabela, atëherë do të ishte mirë të përdornim ndonjë mjet për dizajnin vizual të arkitekturës së bazës së të dhënave. Meqenëse ky është një hobi për mua, e përdor absolutisht. mjet falas i quajtur Oracle SQL Developer Data Modeler (mund ta shkarkoni).
Ky program ju lejon të vizatoni vizualisht tabela dhe të krijoni marrëdhënie me to. Shumë gabime në hartimin e arkitekturës së bazës së të dhënave mund të shmangen me këtë qasje të projektimit (Unë tashmë po jua them këtë si një programues profesionist i bazës së të dhënave). Duket diçka si kjo:
Pasi kemi projektuar vetë arkitekturën, kalojmë në pjesën më të lodhshme, e cila konsiston në krijimet sql kodi për krijimin e tabelave. Për të ndihmuar me këtë çështje, unë tashmë përdor një mjet të quajtur SQLiteStudio (i cili nga ana tjetër mund të shkarkohet këtu).
Ky mjetështë një analog i produkteve të tilla të njohura si SQL Naviagator, Toad etj. Por siç sugjeron emri, ai është krijuar për të punuar me SQLite. Kjo ju lejon të krijoni vizualisht një bazë të dhënash dhe të merrni kodin DDL krijuar tabela. Nga rruga, ju lejon gjithashtu të krijoni Views, të cilat mund t'i përdorni gjithashtu në aplikacionin tuaj nëse dëshironi. Nuk e di sa e saktë është qasja e përdorimit të pamjeve në programet Android, por i përdora ato në një nga aplikacionet e mia.
Në fakt, unë nuk jam më çfarë mjete të palëve të treta Unë nuk e përdor atë, dhe më pas magjia fillon me Android Studio. Siç e kam shkruar tashmë më lart, nëse fillojmë të zbatojmë kodin SQL në kodin Java, dalja që do të marrim është e dobët e lexueshme, dhe për rrjedhojë, kodi i shtrirë dobët. Prandaj, i vendos të gjitha deklaratat SQL skedarë të jashtëm, të cilën e kam në drejtori aseteve. Në Android Studio duket diçka si kjo:
Rreth drejtorive db dhe të dhënave
Brenda drejtorisë aseteve Kam krijuar dy drejtori db_01 Dhe data_01. Numrat në emrat e drejtorive korrespondojnë me numrin e versionit të bazës së të dhënave sime me të cilën punoj. Në drejtori db Unë ruaj skriptet SQL për krijimin e tabelave vetë. Dhe në drejtori të dhëna Ruhen të dhënat e nevojshme për plotësimin fillestar të tabelave.
Tani le të shohim kodin brenda tim DBHelper të cilat i përdor në projektet e mia. Së pari, variablat e klasës dhe konstruktori (nuk ka surpriza këtu):
Private statike përfundimtare String TAG = "RoadMap4.DBHelper"; String mDb = "db_"; String mData = "të dhënat_"; Konteksti mContext; int mVersion; publik DBHelper (konteksti i kontekstit, emri i vargut, versioni int) ( super(kontekst, emër, null, version); mContext = kontekst; mVersion = version; )
Tani metoda onKrijo dhe këtu bëhet më interesante:
@Override public void onCreate(SQLiteDatabase db) (ArrayList
Logjikisht ndahet në dy cikle, në ciklin e parë marr një listë me instruksione SQL për krijimin e bazës së të dhënave dhe më pas i ekzekutoj ato, në ciklin e dytë tashmë plotësoj tabelat e krijuara më parë me të dhëna fillestare. Pra, hapi i parë:
ArrayList Private
Gjithçka është mjaft e thjeshtë këtu, ne thjesht lexojmë përmbajtjen e skedarëve dhe lidhim përmbajtjen e secilit skedar në një element grupi. Ju lutemi vini re se unë jam duke renditur listën e skedarëve, pasi tabelat mund të kenë çelësa të huaj, që do të thotë se tabelat duhet të krijohen në një rend të caktuar. Unë përdor numërimin në emrat e skedarëve dhe me ndihmën e tij rendit.
QueryFilesComparator i klasës private zbaton Comparator
Plotësimi i tabelave e bën atë gjithnjë e më argëtues. Tabelat e mia janë të mbushura jo vetëm me vlera të koduara, por edhe me vlera nga burimet dhe çelësat UUID (shpresoj që një ditë të vij në një version të rrjetit të programit tim, në mënyrë që përdoruesit e mi të mund të punojnë me të dhëna të përbashkëta). Struktura e skedarëve me të dhënat fillestare duket si kjo:
Përkundër faktit që skedarët e mi kanë shtrirjen sql, nuk ka asnjë kod sql brenda, por diçka si kjo:
Prioritetet
pri_id:UUID:UUID
pri_name:string:normal
pri_color:color:colorE gjelbër
pri_default:int:1
prioritetet
pri_id:UUID:UUID
pri_object:string:objekt_detyrë
pri_name:string:hold
pri_color:color:colorBlue
pri_default:int:0
prioritetet
pri_id:UUID:UUID
pri_object:string:objekt_detyrë
pri_name:string:i rëndësishëm
pri_color:color:colorE kuqe
pri_default:int:0
prioritetet
pri_id:UUID:UUID
pri_name:string:normal
pri_color:color:colorE gjelbër
pri_default:int:1
prioritetet
pri_id:UUID:UUID
pri_object:string:object_project
pri_name:string:hold
pri_color:color:colorBlue
pri_default:int:0
prioritetet
pri_id:UUID:UUID
pri_object:string:object_project
pri_name:string:i rëndësishëm
pri_color:color:colorE kuqe
pri_default:int:0
Struktura e skedarit është si kjo: Unë bëj një thirrje funksioni ndarje (":") në lidhje me një rresht dhe nëse marr se madhësia e saj është 1, atëherë kjo do të thotë emri i tabelës ku duhet të shkruhen të dhënat. Përndryshe janë vetë të dhënat. Fusha e parë është emri i fushës në tabelë. Fusha e dytë është lloji me të cilin përcaktoj se çfarë duhet të shkruaj pikërisht në këtë fushë. Nëse ky është një UUID, kjo do të thotë që unë duhet të gjeneroj vlerë unike UUID. Nëse vargu do të thotë, më duhet të nxjerr një vlerë vargu nga burimet. Nëse ngjyra, atëherë përsëri, duhet të nxirrni kodin e ngjyrës nga burimet. Nëse int ose tekst, atëherë unë thjesht e konvertoj këtë vlerë në int ose String pa asnjë lëvizje fizike. Vetë kodi duket si ky:
ArrayList Private
30.04.2009 Alexey Kovyazin
Bazat e të dhënave relacionale kanë depërtuar pothuajse në gjithçka Sistemet e Informacionit, dhe duket se ato janë bërë zona më e vendosur e IT, ku pak mund të shpiket, por gjendja reale e punëve është larg nga ideale.
Bazat e të dhënave relacionale përdoren sot në pothuajse të gjitha aplikacionet, duke filluar nga ato të integruara në pajisje të lëvizshme dhe speciale, aplikacione në ueb dhe duke përfunduar me sistemet e menaxhimit të ndërmarrjeve. Depërtimi i bazave të të dhënave në të gjitha llojet e aplikacioneve po përshpejtohet dhe zhvilluesit po marrin mjete dhe qasje gjithnjë e më të lehta për t'u përdorur. Mund të duket se zhvilluesit e aplikacioneve të bazës së të dhënave janë grupi më i pasur i programuesve që kanë mjete për të gjitha rastet, por kjo është larg nga rasti. Embarcadero Technologies, me blerjen e biznesit të mjeteve të zhvillimit të Borland CodeGear në 2008, kombinoi mjetet profesionale të zhvillimit dhe projektimit të aplikacioneve, mjetet e zhvillimit dhe menaxhimit të bazës së të dhënave për të eliminuar pengesat ekzistuese si në anën e aplikacionit ashtu edhe në anën e bazës së të dhënave.
Dizajni kaotik i bazës së të dhënave
Në industrinë e sotme të zhvillimit të softuerit, është një besim i mirëvendosur se është e pamundur të përcaktohen kërkesat e produktit përpara fillimit të një projekti, dhe për këtë arsye zhvillimi duhet të përshtatet me ndryshimin e tyre të vazhdueshëm. Si rezultat, u shfaqën procese të bazuara në përsëritje që marrin parasysh ndryshimin e kërkesave dhe rifaktorimi i kodit burimor u bë një pjesë integrale e krijimit të softuerit. Çfarë ndodh në procesin e zhvillimit iterativ me bazat e të dhënave? Ndryshimi i kërkesave ju detyron të rregulloni skemën e bazës së të dhënave, dhe më shpesh kjo ndodh në mënyrë të errët, pa analizuar pamjen e përgjithshme dhe varësitë. Tabelat, fushat, çelësat e huaj dhe kufizimet krijohen dhe ndryshohen në mënyrë kaotike, askush nuk monitoron integritetin e referencës dhe askush nuk mund të thotë me siguri se si ndryshon baza e të dhënave në përsëritjen N nga gjendja e saj në përsëritjen N-1.
Në fakt, zhvillimi i bazave të të dhënave sot kryhet duke përdorur një metodë "patch", si në ditët e mbizotërimit të procesit "ujëvara" - në fillim të projektit, "vizatohet" një model i caktuar i bazës së të dhënave. bazuar në kërkesat e pjesshme të njohura në atë moment, atëherë gjenerohet një bazë e të dhënave fizike dhe më pas modeli harrohet, duke bërë ndryshime direkt në bazën e të dhënave. Disavantazhet e kësaj qasjeje janë të dukshme: ndarja e njohurive dhe të kuptuarit e pamjes së madhe është e vështirë, dhe ndryshimet nuk janë transparente dhe mund të gjenerojnë kontradikta në skemën logjike dhe bazën e të dhënave që do të mbeten të pazbuluara deri në momentin e hyrjes. sistemi softuerik në funksionim, gjë që çon në humbje shumë të mëdha. Zhvilluesit e sotëm të aplikacioneve të bazës së të dhënave kanë nevojë për mjete të dizajnuara për zhvillimin e përsëritur të bazës së të dhënave.
Kushti i parë dhe më i rëndësishëm për një palestër të tillë është prania mundësi të plota inxhinieri e kundërt(inxhinieri e kundërt, krijimi i një modeli të bazës së të dhënave bazuar në analizën e paraqitjes fizike të saj) dhe inxhinieri direkte(inxhinieri përpara; krijimi dhe ndryshimi i skemës së bazës së të dhënave fizike bazuar në model). Në praktikë, kjo do të thotë që duke përdorur një mjet projektimi, ju mund të analizoni skemën e një baze të dhënash ekzistuese, të krijoni një model bazë të dhënash bazuar në të, të ndryshoni modelin dhe të aplikoni menjëherë ndryshime që në fakt duhet të ndryshojnë skemën e bazës së të dhënave në mënyrë korrekte dhe të vazhdueshme, dhe jo të prishin ose ngatërroje atë.
Qasja përsëritëse gjithashtu na inkurajon të krijojmë nënmodele të lidhura me një përsëritje specifike. Ndarja e çdo entiteti dhe atributet e tyre në një nënmodel ndihmon në ndarjen e fushave të përgjegjësisë ndërmjet të dyjave nga zhvillues të ndryshëm, dhe ndërmjet përsëritjeve të ndryshme, duke siguruar integritetin e përgjithshëm të modelit. Natyrisht, na duhet edhe aftësia për të krahasuar dy modele, jo në formën e skripteve SQL, por në nivel entitetesh dhe atributesh, për të parë dhe kuptuar plotësisht ndryshimet e bëra gjatë përsëritjes dhe ndikimin e tyre në të gjithë modelin.
Zhvilluesit e aplikacioneve rrallë punojnë vetëm, kështu që ata kanë nevojë për mjete bashkëpunimi, por ndërsa në anën e zhvillimit të aplikacionit kjo është në rregull, atëherë bashkëpunimi në bazën e të dhënave zakonisht nuk mbështetet fare në nivel mjetet. Bashkëpunimi përfshin domosdoshmërisht një sistem kontrolli të versioneve: të gjitha versionet e modeleve dhe skema fizike e bazës së të dhënave duhet të ruhen në një depo të vetme, duke ofruar mundësinë e rikthimit dhe krahasimit të skemave që nga fillimi i procesit të zhvillimit.
Zhvillimi i bazës së të dhënave nuk është më pak i rëndësishëm se zhvillimi i aplikacionit, kështu që drejtimi strategjik i zhvillimit është sigurimi i procesit të zhvillimit të bazës së të dhënave me kontrollin e versionit dhe mjetet e menaxhimit të kërkesave, si dhe lidhja e qartë e fazave të modelimit dhe modifikimit të bazës së të dhënave me përsëritjet dhe ndryshimin e kërkesave. projekt softuerik. Për të zgjidhur këto probleme dhe për të mbështetur procesin modern të zhvillimit të bazës së të dhënave përsëritëse, Embarcadero ofron ER/Studio, një vegël projektimi, analize, inxhinierike e kundërt dhe përpara që lejon kontrollin e versioneve të modeleve bazuar në depon e vet. Mjeti Change Manager mund të përdoret si një mjet për monitorimin e ndryshimeve të meta të dhënave në bazat e të dhënave fizike.
Fragmentimi i kodit
Problemi më i njohur që ngadalëson shumë zhvillimin e aplikacioneve të bazës së të dhënave është nevoja për të përdorur mjete të ndryshme për të korrigjuar kodin e aplikacionit dhe kodin SQL në bazën e të dhënave.
Le të shohim një shembull të thjeshtë. Le të supozojmë se po zhvillon një aplikacion në Delphi që thërret një procedurë të ruajtur në Oracle DBMS. Duke përdorur mjetet e Delphi, zhvilluesi i aplikacionit, në modalitetin e korrigjimit, mund të shkojë hap pas hapi deri në momentin e thirrjes së një pyetjeje SQL, të shohë parametrat e kaluar në procedurën e ruajtur dhe rezultatin që procedura do të kthehet. Por çfarë ndodh brenda procedurës kur ajo ekzekutohet në serverin e bazës së të dhënave? Kjo nuk mund të përcaktohet nga mjedisi i zhvillimit të aplikacionit tonë - për ta bërë këtë, duhet të shkarkoni një aplikacion për zhvillimin e SQL, i cili ka aftësi për korrigjimin e procedurave të ruajtura, dhe gjithashtu tregon planet e pyetjeve SQL, statistikat e ekzekutimit të tyre dhe ju lejon të shikoni dhe ndryshoni skemën e bazës së të dhënave. Sidoqoftë, nuk mund t'i kaloni cilësimet nga mjedisi i zhvillimit të aplikacionit në mjedisin e zhvillimit të SQL dhe duhet t'i kopjoni ato manualisht duke kaluar nga një dritare në tjetrën. Gjithashtu nuk është e mundur të shihen rezultate të detajuara të ekzekutimit të SQL, të tilla si plani i pyetjeve, statistikat e ekzekutimit, etj., në mjetin e zhvillimit të aplikacionit. Ardhja e teknologjisë së korrigjimit ndër-gjuhësh i ka zgjidhur këto probleme.
Produkti i parë Embarcadero që mbështet korrigjimin ndër-gjuhësh është Zhvilluesi RapidSQL (dikur PowerSQL), pjesa vizuale e të cilit bazohet në teknologjinë Eclipse dhe për këtë arsye ju lejon të integroheni në çdo mjedis zhvillimi të bazuar në të (duke përfshirë, natyrisht, JBuilder) dhe kryeni korrigjimin dinamik ndër-gjuhësor. Tani, kur një procedurë e ruajtur ekzekutohet në server, një zhvillues brenda të njëjtit mjet kalon automatikisht në një mjedis të plotë të korrigjimit të SQL, i aftë për të korrigjuar si pyetjet e rregullta SQL ashtu edhe procedurat e ruajtura. Zhvilluesi sheh parametrat aktualë të hyrjes së pyetjeve dhe procedurat e ruajtura, duke i dhënë atij mundësinë për korrigjimin hap pas hapi të kodit SQL. Integrimi i Zhvilluesit RapidSQL në mjetet e zhvillimit të pajtueshëm me Eclipse është hapi i parë në integrimin e zhvillimit të aplikacioneve dhe bazës së të dhënave, me aftësi të ngjashme që vijnë më pas për Delphi, C++ Builder dhe mjete të tjera të zhvillimit të aplikacioneve nga Embarcadero.
Aplikacionet e bazës së të dhënave me shumë platforma
Një sfidë e veçantë për zhvilluesit është zhvillimi i aplikacioneve të bazës së të dhënave që duhet të punojnë me shumë DBMS. Për shembull, bankat dhe kompanitë e sigurimeve zakonisht kanë disa zyra të mëdha dhe shumë degë të vogla. Shumica e proceseve të biznesit që lidhen me futjen e informacionit operacional dhe rrjedhën e përditshme të dokumenteve janë të njëjta në selinë qendrore dhe në degë, por shkalla është e ndryshme. Dëshira e natyrshme për të kursyer në koston e licencave DBMS industriale për përdorim në degë çon në idenë se do të ishte mirë të zgjidhni një DBMS tjetër pa ndryshuar aplikacionin.
Zhvilluesit me përvojë të bazës së të dhënave e kuptojnë mirë thelbin e problemeve që lindin këtu: ndryshimet në llojet e të dhënave dhe dialektet SQL, mungesa e mekanizmave të migrimit dhe riprodhimit midis DBMS-ve të ndryshme dhe kompleksiteti i verifikimit të migrimit e bëjnë shkrimin dhe funksionimin e aplikacioneve për DBMS të ndryshme një makth. Nga ana e mjeteve të zhvillimit të aplikacioneve, ata po përpiqen ta zgjidhin këtë problem duke krijuar biblioteka të aksesit të të dhënave (dbExpress në Delphi dhe C++ Builder, ADO dhe ADO.Net nga Microsoft), të ndërtuara mbi parime uniforme arkitekturore dhe metoda aksesi, si dhe nga duke përdorur "mbështjellës" të shumtë relacionalë objektesh (Object Relation Mapping, ORM) mbi logjikën relacionale dhe strukturën e bazës së të dhënave, duke gjeneruar kodin burimor për të punuar me të dhënat bazuar në analizën e skemës së bazës së të dhënave dhe duke përdorur mekanizmin "përshtatës" për të zbatuar protokollin e një protokolli specifik. DBMS. Ndër ORM-të më të njohura, duhet të përmendim Hibernate për Java dhe ActiveRecord në RubyOnRails, të cilat ofrojnë një ndërfaqe të orientuar nga objekti për të dhënat e ruajtura në një DBMS. Ekziston një projekt i ngjashëm tiOPF për Delphi, dhe NHibernate për C#.
Sigurisht, përdorimi i të tilla bibliotekat universale dhe grupet e komponentëve mund të zvogëlojnë ndjeshëm numrin e operacioneve rutinë në procesin e zhvillimit të bazës së të dhënave në shumë platforma. Megjithatë, kjo nuk mjafton kur ne po flasim për në lidhje me aplikacionet që përdorin baza të të dhënave më komplekse, në të cilat përdoret në mënyrë aktive logjika e ngulitur në procedurat dhe nxitësit e ruajtur - për zbatimin, korrigjimin dhe testimin e tij, kërkohen mjete të veçanta, ndonjëherë krejtësisht të ndryshme për DBMS të ndryshme. Për zhvillimin e aplikacioneve të bazës së të dhënave ndër-platformë, Embarcadero ofron mjetin RapidSQL.
Të gjitha produktet e bazës së të dhënave Embarcadero mbështesin platforma të shumta dhe bazohen në analizën dhe motorin e statistikave të skemës së bazës së të dhënave Thunderbolt. Secila DBMS e mbështetur dhe çdo version specifik i DBMS ka degët përkatëse të kodit në kernelin Thunderbolt, i cili ju lejon të hartoni më saktë skemën e bazës së të dhënave në përfaqësimin e brendshëm në këtë kernel dhe, më e rëndësishmja, të kryeni konvertime të sakta midis përfaqësimit dhe reales. bazat e të dhënave. Falë bërthamës Thunderbolt sistemi RapidSQL ju lejon të zhvilloni kodin SQL me cilësi të lartë për të gjitha platformat e mbështetura (Oracle, MS SQL, Sybase dhe opsione të ndryshme IBM DB2), dhe ER/Studio mund të kryejnë inxhinieri të saktë të kundërt dhe përpara të skemave të bazës së të dhënave.
Nëse jeni duke zhvilluar një aplikacion për dy ose më shumë platforma ose po migroni një aplikacion ekzistues nga një platformë në tjetrën, atëherë RapidSQL do t'ju ofrojë të gjitha mjetet e nevojshme për të migruar skemën, përdoruesit dhe lejet ndërmjet DBMS-ve të ndryshme. Sigurisht, RapidSQL nuk i konverton automatikisht procedurat PL/SQL në T-SQL - kjo kërkon ende një programues, por mjeti ofron një dritare të vetme për zhvillimin e shumë platformave, redaktues të unifikuar për objektet e skemës, përdoruesit dhe të drejtat e tyre, si dhe Korrigjimi i SQL në të gjitha platformat e mbështetura. Sipas përdoruesve të RapidSQL, si rezultat, ruhet deri në 70% e kohës së shpenzuar për migrimin midis DBMS-ve të ndryshme.
Ndryshimet në të dhënat dhe skemat
Migrimi nga një DBMS në tjetrin është i pamundur pa verifikimin e tij. Kush dhe si mund të garantojë që të dhënat e transferuara nga një DBMS në tjetrën janë vërtet identike? Bibliotekat e ndryshme të klientëve, lloje të ndryshme të dhënash dhe kodime të ndryshme e bëjnë procesin e krahasimit të të dhënave një detyrë jo të parëndësishme.
Në botën reale, puna nuk përfundon me vendosjen e aplikacionit dhe bazës së të dhënave - mirëmbajtja vazhdon, shfaqen versione të reja të skedarëve të ekzekutueshëm të aplikacionit dhe arna të bazës së të dhënave. Si mund të siguroheni që të gjitha përditësimet e nevojshme janë aplikuar në bazën e të dhënave dhe se e gjithë paketa e softuerit do të funksionojë siç duhet?
Embarcadero ka zhvilluar një mjet Change Manager i krijuar për të krahasuar të dhënat, skemat dhe konfigurimet e bazës së të dhënave. Krahasimi bëhet brenda një ose më shumë DBMS, me kontroll automatik korrespondenca midis llojeve të të dhënave dhe formimi i skripteve SQL të dallimeve, të cilat mund të aplikohen menjëherë për të sjellë bazat e të dhënave në një gjendje identike. Moduli i krahasimit të meta të dhënave ofron krahasimin e skemave të bazës së të dhënave si midis bazave të të dhënave "të drejtpërdrejta" dhe midis një databaze dhe një skripti SQL dhe gjeneron një skript të ndryshimit të meta të dhënave. Ky funksionalitet mund të përdoret jo vetëm për të kontrolluar bazat e të dhënave kundrejt një standardi, por edhe për të organizuar një proces të rregullt të përditësimit të bazave të të dhënave, si dhe për të kontrolluar për ndryshime të paautorizuara, të themi, në degët e largëta të një organizate të madhe. Situata është e ngjashme me skedarët e konfigurimit - Change Manager krahason skedarët e konfigurimit dhe ju lejon të siguroheni që konfigurimi i aplikacioneve të vendosura plotëson kërkesat për këtë softuer.
Performanca e aplikacionit të bazës së të dhënave
Sa shpesh shohim aplikacione që funksionojnë shkëlqyeshëm në vëllime të vogla testimi të të dhënave, por ngadalësohen në mënyrë të papranueshme në vëllime reale. Llogaritjet e gabuara në kërkesat, testimi i pamjaftueshëm në fazat e hershme, nxitimi për të ofruar një projekt - të gjitha këto janë arsye të njohura për zhvillimin e dobët të aplikacionit. Në këtë rast, teoricienët e zhvillimit të softuerit propozojnë të angazhohen në vetë-përmirësim dhe të përmirësojnë rrënjësisht cilësinë e programeve, por të gjithë praktikuesit e dinë se ndonjëherë është e pamundur të rishkruhet një projekt, qoftë ekonomikisht apo, në disa raste, politikisht, dhe problemi i optimizimi i performancës duhet të zgjidhet në çfarëdo mënyre.
Shkaku kryesor i problemeve të performancës së aplikacionit të bazës së të dhënave qëndron në pyetjet e pa optimizuara të SQL dhe procedurat e ruajtura. Optimizuesit e bazave të të dhënave moderne janë mjaft të fuqishëm, megjithatë, ata gjithashtu kanë kufij të caktuar të aftësive, dhe për të arritur performancë të mirë, duhet të hartoni saktë pyetjet SQL, të krijoni (ose fshini) indekse shtesë, në raste të caktuara të çnormalizoni bazën e të dhënave dhe zhvendosni një pjesë të logjikës tek nxitësit dhe procedurat e ruajtura.
Gjatë fazës së zhvillimit, optimizimi i pyetjeve mund të bëhet duke përdorur RapidSQL, i cili përfshin një modul SQL Profiler që mund të analizojë planet dhe të gjenerojë sugjerime për përmirësimin e performancës së pyetjeve SQL. Por, çka nëse problemi ndodh gjatë operimit dhe nuk lokalizohet në një pyetje specifike SQL? Po nëse performanca bie në periudha të caktuara të ditës ose, edhe më keq, problemi ndodh në një kopje të largët të sistemit, ndërsa gjithçka është në rregull në serverin kryesor? Për raste të tilla, është projektuar DBOptimizer - një mjet për profilizimin e bazës së të dhënave për Oracle, Microsoft SQL Serveri, Sybase dhe IBM DB2.
Kur fillon modaliteti i profilizimit, DBOptimizer mbledh informacionin e bazës së të dhënave dhe kohën e funksionimit, duke përfshirë ngarkesën e CPU-së dhe parametrat e tjerë të sistemit operativ, dhe e regjistron atë në seancën e profilizimit. Rezultati është një listë kërkesash që ekzekutohen në çdo interval kohor të caktuar, të renditura sipas burimeve të konsumuara. Për çdo kërkesë problematike, mund të shihni planin e saj, statistikat e ekzekutimit dhe detaje të tjera. Për më tepër, DBOptimizer gjithashtu tregon sugjerime dhe rekomandime për përmirësimin e pyetjes në lidhje me DBMS specifike.
Kutia e veglave
Të gjitha mjetet e përmendura, megjithëse ofrojnë zgjidhje për problemet, përdoren në faza të ndryshme të ciklit jetësor të zhvillimit të bazës së të dhënave. Është mjaft e papërshtatshme dhe e shtrenjtë të mbash një duzinë aplikacionesh për të gjitha rastet që mund të nevojiten (ose nuk mund të nevojiten) gjatë projektimit, zhvillimit, migrimit, optimizimit dhe funksionimit të bazave të të dhënave.
I lëshuar në shkurt 2009, Emdacadero All-Access ofron mjete thelbësore për të gjitha fazat e zhvillimit të aplikacionit të bazës së të dhënave: nga ER/Studio te DBOptimizer, nga Delphi dhe C++ Builder tek DBArtisan. Mënyra më e mirë për të përshkruar All-Access është ta krahasoni atë me kutinë e veglave që çdo pronar kursimtar ka në shtëpinë e tij. Ndoshta jo të gjitha mjetet përdoren çdo ditë, por një çelës i rregullueshëm duhet të jetë gjithmonë në dispozicion në rast rrjedhjeje.
All-Access nuk imponon role të tjera për programuesit ose arkitektët e bazës së të dhënave, por ofron një grup universal mjetesh të përshtatshme për të gjitha rolet në procesin e zhvillimit të aplikacionit të bazës së të dhënave, nga arkitekti tek testuesi; u ofron të gjithë anëtarëve të ekipit të zhvillimit mjete për të gjitha fazat e zhvillimit të bazës së të dhënave, si dhe një grup mjetesh shumë të specializuara për optimizimin e bazave të të dhënave (DBOptimizer) dhe aplikacioneve (JOptimizer), duke ju lejuar të "zgjeroni" vende të ngushta. Paketa mbështet disa DBMS, të cilat ofrojnë kursime në kosto.
Dallimet teknike midis objektit të orientuar dhe bazat e të dhënave relacionale të dhënat çuan në një ndarje kulturore që ende ndan komunitetin e menaxhimit të të dhënave nga komuniteti i zhvillimit. Çfarë duhet të bëjmë më pas?
Delphi është një mjedis zhvillimi që përdor gjuhën Programimi Delphi(duke filluar nga versioni 7, gjuha në mjedis quhet Delphi, më parë Object Pascal), e zhvilluar nga Borland dhe e zbatuar fillimisht në paketën e saj Borland Delphi, nga e cila mori emrin aktual në 2003. Object Pascal është në thelb një pasardhës i gjuhës Pascal me zgjerime të orientuara nga objekti.
Delphi është mjeti optimal për krijimin e aplikacioneve të bazës së të dhënave. Optimale, sepse mbështet teknologjinë e zhvillimit vizual, e cila mund të zvogëlojë ndjeshëm kohën e zhvillimit duke ruajtur cilësinë dhe besueshmërinë e mirë produkt software. Struktura gjuhësore e Delphi ju lejon të shmangni gabimet e fshehura.
Karakteristikat e familjes Delphi 7:
*Mjedisi i zhvillimit të shpejtë të aplikacioneve që integron mjete për modelimin e zhvillimit dhe vendosjes së aplikacioneve të tregtisë elektronike dhe shërbimeve të Uebit.
*Mbështetje për gjuhët e programimit për Win32 (Delphi dhe C/C++) dhe për .NET (Delphi dhe C#) në një mjedis të vetëm zhvillimi, gjë që e bën më të lehtë mirëmbajtjen dhe krijimin e aplikacioneve të reja Win32 dhe zotërimin më të lehtë të teknologjive .NET;
*Mundësia për zhvilluesit tradicionalë të Windows dhe Java për të zhvilluar aplikacione .NET pa braktisur mjetet që përdorin, duke ruajtur të njëjtat aftësi dhe duke përdorur koncepte të ngjashme programimi;
*Sistemi i ri i shablloneve të kodeve dhe risive të tjera në mjedisin e zhvillimit përmirësojnë cilësisht punën me kodet burimore dhe rrisin produktivitetin e zhvillimit;
Microsoft SQL Server 2000 është një ofertë e plotë e të dhënave dhe analizave të të dhënave për krijimi i shpejtë zgjidhje të shkallëzueshme të tregtisë elektronike, aplikacione biznesi dhe depo të dhënash.
Ai redukton ndjeshëm kohën për t'u tregtuar për këto zgjidhje duke siguruar shkallëzim për të përmbushur kërkesat më të kërkuara.
Paketa Delphi është një vazhdim i linjës së përpiluesve të gjuhës Pascal të Borland Corporation. Pascal si gjuhë është shumë e thjeshtë dhe kontrolli i rreptë i llojit të të dhënave ndihmon në zbulimin e hershëm të gabimeve dhe ju lejon të krijoni shpejt programe të besueshme dhe efikase.
Zhvillimi i aplikacionit të bazës së të dhënave është një nga aftësitë më të kërkuara të mjedisit programues Delphi. Fuqia dhe fleksibiliteti i Delphi kur punon me bazat e të dhënave bazohet në një procesor të bazës së të dhënave të nivelit të ulët - Motori i bazës së të dhënave Borland (BDE). Ndërfaqja e tij me programet e aplikacionit quhet Ndërfaqja e Programimit të Programit të Integruar të Bazës së të Dhënave (IDAPI). BDE ju lejon të aksesoni të dhënat duke përdorur qasjen tradicionale të orientuar drejt regjistrimit (navigimit) dhe qasjen e orientuar nga grupi i përdorur në serverët e bazës së të dhënave SQL.
Biblioteka e objekteve përmban një grup komponentësh vizualë që thjeshtojnë shumë zhvillimin e aplikacioneve për DBMS me arkitekturë klient-server. Objektet përmbledhin veten e tyre Niveli më i ulët- Motori i bazës së të dhënave Borland.
Ekzistojnë grupe të veçanta të komponentëve përgjegjës për aksesimin e të dhënave dhe komponentët që shfaqin të dhëna. Komponentët e aksesit të të dhënave ju lejojnë të lidheni me bazën e të dhënave, të merrni, kopjoni të dhënat, etj.
Komponentët e vizualizimit të të dhënave ju lejojnë të shfaqni të dhënat në formën e tabelave, fushave dhe listave. Të dhënat e shfaqura mund të jenë në format teksti, grafik ose pa pagesë.
Tabelat ruhen në bazën e të dhënave. Disa DBMS ruajnë bazën e të dhënave në formën e disa skedarëve të veçantë që përfaqësojnë tabela (në thelb të gjitha DBMS-të lokale), ndërsa të tjerët përbëhen nga një skedar i vetëm që përmban të gjitha tabelat dhe indekset (InterBase).
Objektet e bazës së të dhënave të Delphi janë të bazuara në SQL dhe përfshijnë fuqinë e plotë të motorit të bazës së të dhënave Borland. Delphi përfshin gjithashtu Borland SQL Link, kështu që qasja në bazat e të dhënave Oracle, Sybase, Informix dhe InterBase është shumë efikase. Përveç kësaj, Delphi përfshin një server lokal Interbase në mënyrë që aplikacionet të mund të zhvillohen jashtë linje dhe të zgjerohen në çdo server të jashtëm SQL.
Shkallueshmëria në praktikë - i njëjti aplikacion mund të përdoret si për opsionet lokale ashtu edhe për ato më serioze klient-server.
Megjithëse Delphi nuk ka formatin e vet të tabelës së bazës së të dhënave, ai megjithatë ofron mbështetje të fuqishme për një numër të madh të DBMS-ve të ndryshme - si lokale (për shembull, dBase ose Paradox) dhe industriale (për shembull, Sybase ose InterBase).
