Federalna agencija za obrazovanje
Državna obrazovna ustanova visokog stručnog obrazovanja
"ČELJABINSKO DRŽAVNO SVEUČILIŠTE"
Tečajni rad
Razvoj aplikacija za baze podataka
Analiza domene
Opis predmetnog područja i funkcija zadataka koje treba riješiti
U predmetnom radu, u skladu sa zadatkom, automatizirane su aktivnosti prodajnog odjela poduzeća Russian Food.
Predmet područja automatizacije su neke radne funkcije odjela prodaje. Odjel prodaje ima plan puštanja gotovih proizvoda izrađen za tri mjeseca. U skladu s ovim planom trgovine proizvode proizvode, ali stvarna proizvodnja ovisi o mnogim čimbenicima i može se razlikovati od planirane. Odjel prodaje također prima račune trgovine, koji odražavaju stvarni učinak proizvoda i njihovu isporuku u određena skladišta.
Zadatak službe prodaje je analiza izvršenja plana isporuke proizvoda u skladišta. Da biste to učinili, morate odabrati planirane i stvarne podatke za određeno razdoblje za određeno skladište i analizirati odstupanje činjenice od plana.
Tvrtka ima 3 radionice u kojima se proizvode proizvodi. Raspon proizvedenih proizvoda naveden je u tablici.
Stol 1.
Broj radionice Naziv radionice Naziv proizvoda Minimalna jedinica proizvodnje Cijena po jedinici mlijeka 3,5% kutija 50 komada650,00 rub. kutija za kremu 50 komada1 200,00 rub. kuhana kobasicapakiranje 50 komada2 500,00 rub.2 kobasica dimljena kobasicapakiranje 50 komada3 400,00 rub. kobasice pakiranje od 50 komada1 200,00 rub. kutija smuđa u konzervi 50 limenki 670,00 rub.3 crna kutija kavijara od ribe 50 limenki 5 400,00 rub. kutija crvenog kavijara 50 limenki 5 370,00 rub. Proizvodi proizvedeni u radionicama dostavljaju se u skladišta Tablica 2. Skladište br. Skladište br.1 Skladište br. 12 Skladište br. 23 Skladište br. 3 Popis ulaznih (primarnih) dokumenata. Kao primarni dokumenti za rješavanje ovog problema koriste se: tlocrt trgovine popis faktura trgovine Broj radionice Broj računa trgovine Datum isporuke specifikacija računa trgovine Broj trgovine Broj računa trgovine Šifra proizvoda Količina Ograničenje područja predmeta. Prilikom izrade projekta tečaja dopuštena su sljedeća ograničenja: gotov proizvod je raspoređen u jedno skladište gotovih proizvoda i može ga proizvoditi više radionica. gotov proizvod ima samo jednu jedinicu mjere. jedna radnja može proizvoditi više vrsta proizvoda. U jednom skladištu može se skladištiti više vrsta gotovih proizvoda. proizvodnja gotovih proizvoda po radionici planirana je mjesečno. isti proizvod može biti pušten u prodaju u različitim mjesecima. faktura radionice za isporuku gotovih proizvoda u skladište može sadržavati više stavki, njegov broj je jedinstven samo za jednu radionicu. Formulacija problema Organizacijska i ekonomska bit kompleksa zadataka. Jedan od glavnih problema u poduzeću je neusklađenost između planirane količine proizvodnje, koja se formira prema zahtjevima kupaca, i stvarne količine proizvoda koje radionice otpremaju u skladišta. Za rješavanje ovog problema potrebno je pravovremeno (promptno) dobivanje informacija o prisutnosti, manjku ili višku proizvoda u skladištima u odnosu na plan. Višak se skladišti u skladištu, može doći do prekoračenja roka trajanja i stvaranja nelikvidnih sredstava. Opis izlaznih informacija Izlazne informacije bit će predstavljene u obliku obrasca za izvješćivanje. Analiza realizacije plana isporuke proizvoda u skladište _________________ Mjesec Naziv proizvoda Jedinica mjere Količina VišakPlan Činjenica Za dobivanje ovog obrasca koriste se podaci primarnih dokumenata: lista proizvoda; popis skladišta; popis radionica; plan proizvodnje proizvoda po radionicama; popis faktura trgovine; Opis ulaznih informacija. Ulazne informacije dijele se na uvjetno konstantne (direktorije), koje dugo zadržavaju svoje vrijednosti, i stalno promjenjive, odnosno operativne računovodstvene informacije. Uvjetno trajne informacije uključuju: popis proizvedenih proizvoda; popis proizvodnih trgovina; popis skladišta; priručnik mjernih jedinica. Operativne računovodstvene informacije uključuju: plan proizvodnje proizvoda po radionicama; popis faktura trgovine; specifikacija računa trgovine. Predstavimo primarne dokumente s detaljima u tablici 3: Broj artikla Naziv dokumenta Detalji 1 Popis proizvedenih proizvoda 1. Šifra proizvoda 2. Naziv proizvoda. 3. Šifra mjerne jedinice. 4.Cijena. 5. Skladište broj 3 Popis skladišta 1. Šifra skladišta. 2.Naziv skladišta.2Popis radionica 1.Šifra radionice. 2.Naziv radionice.4Imenik mjernih jedinica 1.Šifra mjerne jedinice. 2. Naziv mjerne jedinice 5 Plan proizvodnje proizvoda po radionicama 1. Broj radionice. 2. Mjesec izlaska. 3. Šifra proizvoda. 4.Količina6Popis faktura trgovine 1.Broj trgovine. 2. Broj računa trgovine. 3. Datum isporuke. 7 Specifikacija računa trgovine 1. Broj trgovine. 2. Broj računa trgovine. 3. Šifra proizvoda. 4. Količina. Dizajn baze podataka Izbor informacijskih objekata Jedna od najtežih faza u procesu projektiranja baze podataka je razvoj tablica, budući da rezultati koje bi baza podataka trebala dati (izvješća, izlazni obrasci itd.) ne daju uvijek potpunu sliku strukture tablice. Podaci u tablici ne smiju se umnožavati. Ne bi trebalo biti ponavljanja između tablica. Kada je određena informacija pohranjena u samo jednoj tablici, tada će se morati mijenjati samo na jednom mjestu. To čini rad učinkovitijim, a također eliminira mogućnost neusklađenosti informacija različite tablice Oh. Svaka tablica treba sadržavati podatke samo o jednoj temi. Informacije o svakoj temi mnogo se lakše obrađuju ako su sadržane u tablicama koje su neovisne jedna o drugoj. Svaka tablica sadrži podatke o zasebnoj temi, a svako polje u tablici sadrži zasebne informacije o temi tablice Za implementaciju podatkovne veze iz različitih tablica, svaka tablica mora sadržavati polje ili skup polja koja će postaviti pojedinačnu vrijednost svakog zapisa u tablici. Takvo polje ili skup polja naziva se primarni ključ. Nakon distribucije podataka po tablicama i definiranja ključnih polja, trebate definirati odnose između tablica. Tablica 4 Informacijski objekti InfoobjektOdgovarajući dokumentDetaljiKljučni proizvodiPopis proizvedenih proizvoda Šifra proizvodaDa Naziv proizvoda Naziv proizvodaŠifra jediniceCijena Skladišni brojShopNo.ShopListShopNumberYesShopNameWarehousesWarehouseListWarehouseNumberDaWarehouseNameMjerna jedinicaRječnik mjernih jedinicaŠifra mjerne jediniceDaSpecifikacije Shop fakture SpecificationMonleShopBroyYesShopNameWarehousesWarehouseListWarehouseNumberYesWarehouseNameMjerna jedinicaRječnik mjernih jedinicaŠifra mjerne jediniceDaSpecifications Shop fakture SpecificationMonShopLaseShop codeRethplanityProizvodDa "Broj mjeseca Da Naziv mjeseca Informacijsko-logičko modeliranje i određivanje veza između informacijskih objekata Informacijsko-logički model je podatkovni model koji prikazuje predmetno područje u obliku skupa informacijskih objekata i strukturnih odnosa među njima. Naš informacijsko-logički model izgledat će ovako: Sl. 1. infoološki model Kao rezultat razvoja baze podataka dobiveno je 8 informacijskih objekata. Definirajmo tip veze u svakom paru ovih inf. objekti. Mjerna jedinica - Proizvod Tip odnosa je 1-prema-više, jer se više proizvoda može mjeriti jednom mjernom jedinicom, ali svaki proizvod se trenutno mjeri jednom mjernom jedinicom. Veza između ovih objekata temelji se na atributu Šifra mjerne jedinice. Skladišta - Proizvod Tip odnosa je 1-prema-više, budući da se u jednom skladištu može skladištiti više stavki gotovih proizvoda. Komunikacija - traženim skladišnim brojem. Proizvodi - Plan izdavanja Vrsta odnosa je 1-prema-više jer se jedna stavka može zakazati za puštanje u različitim mjesecima, ali svaka planirana količina se odnosi samo na jednu stavku u tom mjesecu. Komunikacija atributom Šifra proizvoda. Mjesec - Plan izdavanja Tip odnosa 1-prema-više, svaki mjesec se izrađuje plan izlaska proizvoda. Kontakt po atributu Broj mjeseca. Radionice - Plan izdanja Vrsta komunikacije 1 - za mnoge, jedna trgovina trebala bi biti puštena u prodaju u različitim mjesecima. Komunikacija atributom Broj radionice. Radionice - Računi za radionice Radionice - Specifikacije Vrsta odnosa 1 prema više, jedna trgovina izdaje mnogo računa. Komunikacija atributom Broj radionice. Računi za kupovinu - Specifikacije Vrsta odnosa 1-prema-više, jedna faktura trgovine može sadržavati nekoliko sastavnica za proizvod. Komunikacija putem detalja - Broj računa trgovine i broj trgovine. Specifikacije proizvoda Vrsta odnosa 1-prema-više, ista stavka se proizvodi više od jednom, ali se određena količina puštena odnosi samo na jednu stavku. Komunikacija atributom Šifra proizvoda. Logička struktura baze podataka Logička struktura relacijske baze podataka primjeren je odraz dobivenog informacijsko-logičkog modela predmetnog područja. Kanonski model ne zahtijeva dodatne transformacije. Svaki informacijski objekt modela podataka preslikan je u odgovarajuću relacijsku tablicu. Struktura relacijske tablice određena je sastavom atributa odgovarajućeg informacijskog objekta, pri čemu svaki stupac (polje) odgovara jednom od atributa. Atributi ključa čine jedinstveni ključ relacijske tablice. Za svaki stupac tablice navedeni su tip, veličina podataka i druga svojstva. Topologija projekta podatkovne sheme praktički se poklapa s topologijom informacijsko-logičkog modela. U okviru ovoga seminarski rad logička struktura baze izgledat će ovako (slika 2.): sl.2. Logička struktura baze podataka Implementacija baze podataka u Microsoft Accessu Za implementaciju projektirane baze podataka koristit ćemo jedan od najpopularnijih sustava za upravljanje bazama podataka za operativni sustav Microsoft Windows pristup. Ovaj DBMS uključen je u rasprostranjeni integrirani paket tvrtke Microsoft Office i potpuno je kompatibilan s programima ovog paketa. Velika prednost MS Accessa je dostupnost alata za razvoj informacijskih sustava za korisnike različitih kvalifikacija: od početnika do profesionalaca. MS Access DBMS je fokusiran na rad sa sljedećim objektima: Tablice su glavni element svake relacijske baze podataka, dizajnirane za definiranje i pohranu podataka; Upiti služe kao izvori za izradu drugih upita, obrazaca i izvješća. Upiti vam omogućuju izmjenu i analizu podataka. Najčešća vrsta upita, upit odabira, skup je pravila koja odabiru podatke iz jedne ili više povezanih tablica. Rezultati upita za odabir prikazuju se u obliku virtualne tablice. Obrasci - objekt dizajniran uglavnom za unos podataka, njihov prikaz na ekranu ili upravljanje radom aplikacije. Moguće je koristiti obrasce za realizaciju korisničkih zahtjeva za prezentaciju podataka iz upita ili tablica, a obrasce je moguće i ispisati. Izvješća su alat za organiziranje izlaza podataka za ispis. Uz pomoć izvješća moguće je prikazati potrebne podatke u željenom obliku. Izvješće možete pregledati prije ispisa. Izvori podataka za izvješća su tablice i upiti; Makronaredbe - objekt koji je strukturirani opis jedne ili više akcija koje MS Access mora izvršiti kao odgovor na određeni događaj. Moduli su objekti koji sadrže programe napisane na jeziku Visual Basic za aplikacije (VBA). Kao dio zadatka, nema potrebe za kreiranjem makronaredbi i modula u dizajniranoj bazi podataka. Svi MS Access objekti smješteni su u jednu datoteku na disku. MS Access ima sučelje s više prozora, ali može obrađivati samo jednu bazu podataka u isto vrijeme. Za izradu nove baze potrebno je pokrenuti MS Access, odabrati " Nova baza podaci", unesite naziv baze podataka i odaberite njezino mjesto na disku. Tablice projektirane baze podataka su informacijski objekti, polja tablica su detalji informacijskih objekata. Za popunjavanje ulaznih podataka bit će potrebno izraditi korisničko sučelje – forme: obrazac "Proizvodi" - za uređivanje tablice "Proizvodi"; obrazac "Plan proizvodnje" - za korekciju plana za broj proizvedenih proizvoda; obrazac "Shop fakture" koji povezuje tablicu "Shop fakture" i tablicu "Specifikacije prodajnih računa" ovisno o "Shop fakturama". Za realizaciju izvještaja "Analiza izvršenja plana isporuke proizvoda na skladište" bit će dovoljno izvršiti jedan upit za odabir mjeseca (tablica "Mjesec"), naziva proizvoda (tablica "Proizvodi"), jedinica mjere (tablica "Jedinica mjere"), količina prema planu (tablica "Plan proizvodnje"), količine naknadno (tablica "Specifikacije"), uz dodatak stupca "višak" s formulom za oduzimanje . Stvaranje tablice i sheme podataka prodaja baze podataka aplikacije Postoji nekoliko načina za izradu tablica (način tablice, dizajner, čarobnjak za tablice, uvoz tablica, povezivanje s tablicama iz drugih baza podataka). Najsvestraniji način za izradu tablice je korištenje načina dizajna. Da biste kreirali tablicu u ovom načinu rada, morate definirati polja tablice. Svako polje karakterizira naziv, tip podataka i svojstva. Naziv polja ne smije sadržavati posebne znakove. Microsoft Access podržava sljedeće vrste podataka: Tekst - koristi se za pohranu alfanumeričkih informacija. Dužina polja ne smije biti veća od 255 znakova; MEMO polje - dizajnirano za pohranjivanje alfanumeričkih informacija duljine do 65535 znakova; Numerički - koristi se za numeričke podatke uključene u izračune; Datum / vrijeme - datum i (ili) vrijeme u rasponu od 100 do 9999; Monetarni - koristi se za novčane vrijednosti i numeričke podatke koji se koriste u matematičkim izračunima, koji se provode s točnošću do 15 znamenki u cijelosti i do 4 znamenke u razlomku; Brojač - služi za generiranje jedinstvenih sekvencijalno rastućih ili slučajnih brojeva koji se automatski unose u polje prilikom dodavanja svakog novog zapisa u tablicu. Vrijednosti polja tipa Counter ne mogu se mijenjati; Boolean - dizajniran za Boolean vrijednosti (Da/Ne, True/False). Duljina logičkog polja - 1 bit; Polje OLE objekta je bilo koji objekt u binarnom formatu (Word dokument, Excel proračunska tablica, slika, zvučna snimka) povezan ili ugrađen u MS Access tablicu. Veličina takvog polja ne smije prelaziti 1 GB; Čarobnjak za pretraživanje - stvara polje koje nudi izbor vrijednosti s popisa ili iz kombiniranog okvira koji sadrži skup konstantnih vrijednosti ili vrijednosti iz druge tablice. Odabirom ove opcije s popisa u ćeliji pokreće se čarobnjak za pretraživanje koji određuje vrstu polja. Svojstva polja postavljaju se na dnu prozora dizajnera tablice na kartici Općenito. Popis svojstava je različit za svaku vrstu podataka. Razmotrimo neke od njih: Veličina polja - ograničava duljinu polja na određeni broj znakova; Format - određuje format za datume i brojeve; Broj decimalnih mjesta - za monetarna i numerička polja postavlja broj decimalnih mjesta; Maska za unos - za tekstualna polja i datumska polja definira predložak prema kojem će se podaci unositi u polje; Indeksirano polje - omogućuje kreiranje indeksa koji će služiti za ubrzavanje pretraživanja i sortiranje tablice po ovo polje. Indeks je interna servisna tablica koja se sastoji od dva stupca: vrijednost indeksiranog polja i broj tablice. Možete postaviti sljedeća svojstva za indekse: a) "Da (podudaranja su dopuštena)" - kreira se indeks koji uključuje podudarne vrijednosti polja, b) "Da (podudaranja nisu dopuštena)" - indeks se stvara na temelju jedinstvenog vrijednost polja, c) "Ne ' - indeks nije kreiran Tablica u MS Accessu obično sadrži primarni ključ. Da biste kreirali ključ, trebate odabrati polje u konstruktoru i dodijeliti ga kao ključ kroz kontekstni izbornik. Polje Tip podataka Veličina polja Primarni ključ Kod jedinice Numerički dugi cijeli broj Da Naziv jedinice Tekst50 Tablica "Proizvodi" FieldData TypeField SizePrimary Key ItemCodeNumeric Long IntegerYes ItemNameText100Unit CodeNumericLong IntegerPrice Monetary-WarehouseNumberNumericByte Tablica "Skladišta" Polje Tip podataka Veličina polja Primarni ključ Broj skladišta Numerički bajt Da Naziv skladišta Tekst20 Mjesečna tablica Polje Tip podataka Veličina polja Primarni ključ Broj mjeseca Numerički cijeli broj Da (nisu dopuštena podudaranja) Naziv mjeseca Tekst 20 Stol "Radionica" Polje Tip podataka Veličina polja Primarni ključ Broj trgovine Numerički bajt Da Naziv trgovine Tekst30 Tablica plana izdanja FieldData TypeField SizePrimary KeyShop NumberNumericByteYesMonthNumberNumericIntegerYesPartCodeNumeric LongIntegerYesQuantityNumericReal(16) Tablica "Računi trgovine" Polje Tip podataka Veličina polja Primarni ključ Broj trgovine Numerički bajt Da Broj fakture trgovine Numerički Dugi cijeli broj Da Datum isporuke Datum\vrijeme- Tablica "Specifikacije" FieldData TypeField SizePrimary KeyShop NumberNumericByteYesShop Invoice NumberNumericLong IntegerYesPart CodeNumeric Long IntegerYesQuantityNumericReal (16) Stvorite podatkovnu shemu u Microsoft Accessu: sl.3. Shema podataka Stvaranje korisničko sučelje
Obrasci su primarni način stvaranja korisničkog sučelja koje pruža najprikladniji način za predstavljanje, pregled, uređivanje podataka i kontrolu napretka aplikacije. Glavne funkcije obrazaca su unos podataka, ispis i uređivanje informacija, kontrola napredovanja aplikacije, ispis poruka i ispis informacija. Postoje sljedeće vrste obrazaca: Normalno - prikazuje jedan zapis izvora podataka; Više stranica - dizajnirano za rad s izvorom podataka koji ima veliki broj polja; Vrpca - prikazuje nekoliko zapisa izvora podataka, pogodno za ne veliki broj polja; Skočni prozor - prikazan na prvi plan zaslon i omogućuje vam rad s drugim oblicima; Ekskluzivno - ne dopušta prebacivanje na druge oblike dok se ne zatvori; Rob - dobar lijek za predstavljanje podataka koji su na "mnogo" strani odnosa jedan-prema-više, ugrađen je u glavni obrazac i uvijek ovisi o njemu. Strukturno, obrazac se sastoji od tri dijela - zaglavlje, bilješka i područje podataka. Odjeljci obrasca sadrže kontrole. Bilo koja se kontrola može postaviti na obrazac pomoću okvira s alatima koji se prikazuje u dizajneru obrasca. Najčešće korišteni elementi: (natpis) - služi za izradu trajnih natpisa u formi; (polje) - element koji prikazuje vrijednost iz izvora podataka; (combo box) - dizajniran za izradu u obliku padajućih popisa; (gumb) - dizajniran za stvaranje naredbenih gumba u obliku koji izvode određene radnje; (potvrdni okvir) - element koji vam omogućuje da omogućite ili onemogućite vrijednost parametra; (podobrazac) - služi za ugradnju podforme u glavni obrazac. Praktičnije je izraditi obrazac pomoću čarobnjaka. Prvi korak je odabir izvora podataka i polja za obrazac. U drugom koraku morate navesti izgled dizajniranom obliku. Treći korak je odabir stila obrasca ( pozadinska slika za oblik, format fonta i shemu boja). Zadnji korak je unos naziva obrasca pod kojim će biti pohranjen u bazi. Obrazac kreiran pomoću čarobnjaka potrebno je finalizirati u načinu dizajna. Dodajte potrebne natpise, gumbe, podobrasce. U sklopu nastavnog rada izrađeni su sljedeći obrasci: Riža. 4. Proizvodi. sl.5. Plan izdavanja. Obrazac "Računi radionice" sadrži podobrazac "Specifikacije" sl.6. Kupujte fakture. Izvješće o implementaciji Prije izrade izvješća potrebno je izraditi upit. Upiti su bitan alat u svakom sustavu upravljanja bazom podataka. Svrha zahtjeva - u opisu vrsta zahtjeva. Upiti se mogu kreirati u načinu rada čarobnjaka za upite (tada morate odabrati vrstu upita) ili u alatu za sastavljanje upita. U Microsoft Accessu postoje četiri vrste upita: jednostavni odabirni upiti prikazuju podatke iz jedne ili više tablica u obliku tablice; dopušteno je dodavanje parametra (uvjet odabira); unakrsni upiti prikupljaju podatke iz jedne ili više tablica u obliku proračunske tablice i koriste se za analizu podataka; dopušteno je dodavanje parametra (uvjet odabira); zahtjevi za promjenama koriste se za stvaranje novih tablica iz rezultata upita i za izmjene (dodavanje, brisanje) podataka postojeće tablice; dopušteno je dodavanje parametra (uvjet odabira); upit za traženje zapisa koji ne odgovaraju niti jednom zapisu u podređenoj tablici. Korištenjem upita u modu čarobnjaka za upite (odabirom sumarnog izvješća upita) moguće je izvršiti izračun (zbroj, prosjek, min, maks) pomoću odabranih podataka. Za realizaciju izvješća "Analiza izvršenja plana isporuke proizvoda u skladište br. ___" bit će dovoljno izvršiti jedan upit za odabir mjeseca (tablica "Mjesec"), naziv proizvoda (tablica "Proizvodi" ), jedinica mjere (tablica "Jedinica mjere"), količina prema planu (tablica "Plan otpuštanja"), količina naknadno (tablica "Specifikacije"), uz dodatak stupca "višak" s formulom za oduzimanje, kao i s odabirom broja skladišta (tablica "skladišta") s uvjetom odabira bez prikaza ovog skladišta u rezultirajućoj tablici. Za ovo izvješće, upit je kreiran pomoću konstruktora: sl.8. Rezultat zahtjeva. Po drugačiji iznos robe iz specifikacije vidljivo je da je smuđ u konzervi isporučen na skladište iu srpnju i u rujnu dva puta. Izvještavanje Izvještaji su najbolji lijek za predstavljanje informacija iz baze podataka u obliku tiskani dokument. Oni pružaju dovoljno mogućnosti za grupiranje i izračunavanje međuzbrojeva i ukupnih zbrojeva za velike skupove podataka. Izvješća se mogu koristiti za izradu lijepo dizajniranih faktura, narudžbenica, poštanskih naljepnica, prezentacijskih materijala i drugih dokumenata koji su vam potrebni za uspješno poslovanje. Izvješće sadrži sljedeća područja: naslov - prikazuje se samo jednom na početku izvješća; zaglavlje i podnožje - ponavljaju se na svakom listu izvješća, koriste se za prikaz stalnih ili periodičnih informacija (datum izvješća, brojevi stranica itd.); naslovi i bilješke za grupe - prikazuju se prilikom grupiranja u izvještaju na početku odnosno na kraju svake grupe. Možete stvoriti do deset razina grupiranja u izvješću; područje podataka - služi za unos informativnih redaka izvješća; bilješka o izvješću - dizajnirana za prikaz sažetih informacija o izvješću kao cjelini, ispisana jednom na kraju izvješća. Stvaranje izvješća, kao i obrazaca, praktičnije je izvesti pomoću čarobnjaka. Nakon što izradite izvješće, možete promijeniti njegovu strukturu u prikazu dizajna (ispraviti i oblikovati zaglavlja stupaca izvješća, dodati ili ukloniti polja itd.). Kao rezultat izrade izvješća dobiven je njegov tiskani oblik. Analiza provedbe plana isporuke proizvoda u skladište br. 1, 2, 3 - sl. 10-12. Dodano je polje "Broj fakture trgovine" kako bi bilo jasno da se proizvod može isporučiti u skladište dva puta mjesečno na dva različita računa. Sl.9. Dizajner izvješća Sl.10. Analiza realizacije plana isporuke proizvoda u skladište br.1 Sl.11. Analiza realizacije plana isporuke proizvoda u skladište br.2 sl.12. Analiza realizacije plana isporuke proizvoda u skladište br.3 Bibliografija Tarasov V.L. Rad s bazama podataka u okruženju Access, Vodič / Sveučilište Nizhny State, Nižnji Novgorod, 2005. Shekhtman V.E. Baze podataka, SQL Obrazovno-metodički priručnik o disciplinama "Baze podataka", "Baze podataka i ekspertni sustavi", " Moderna tehnologija programiranje SQL". / - NFI KemGU, Novokuznetsk, 2006. Andreev V.A., Tupikina E.N., Sustavi upravljanja bazama podataka (Microsoft Access), smjernice/ DVGAEU, Vladivostok, 2003. Veiskas D., Učinkovit rad s ACCESS-om, udžbenik / St. Petersburg, 1996. Homonenko A.F., Tsygankov V.M., Maltsev M.G. Baze podataka, udžbenik za srednje škole / Ured. prof. A.D. Homonenko.- St. Petersburg: CROWN print, 2002.
- tutorial
- način oporavka
Bok svima! Moje ime je Oleg i amaterski sam programer za Android. Amater jer trenutno zarađujem programirajući u sasvim drugom smjeru. I ovo je hobi kojem se posvećujem slobodno vrijeme. Nažalost, ne poznajem Android programere i sve svoje osnovno znanje Crtam ili iz knjiga ili s interneta. U svim onim knjigama i člancima na Internetu koje čitam vrlo malo prostora je dodijeljeno stvaranju baze podataka za aplikaciju, a zapravo se cijeli opis svodi na stvaranje klase koja je nasljednica SQLiteOpenHelper i naknadno uključivanje SQL koda u Java kod. Ako ne uzmemo u obzir da dobivamo slabo čitljiv kod (a ako se u našoj aplikaciji pojavi više od 10 tablica, onda je pamćenje svih tih odnosa između tablica i dalje pakao), onda u principu možete živjeti, naravno, ali nekako ne uopće ne želim.
Zaboravio sam reći ono najvažnije, možemo reći da je ovo moja proba olovke ovdje. I tako smo krenuli.
O vječnom pitanju: zašto?
Iskreno ne znam zašto knjige i članci o Android programiranju ne opisuju alate za projektiranje arhitekture baze podataka i bilo kakve obrasce za rad s bazama podataka u fazi njihove izrade. Čini se da je dodavanje samo nekoliko stranica u knjigu ili pisanje zasebnog članka (kao što ja sada radim) lako kao guljenje krušaka - ali ne. U ovom članku ću se ukratko osvrnuti na alate koje koristim u svom radu i detaljnije na kod koji je odgovoran za početno stvaranje DB koji s moje točke gledišta izgleda čitljiviji i praktičniji.
Ako naša aplikacija ima više od 5 tablica, onda ne bi bilo loše koristiti neki alat za vizualno oblikovanje arhitekture baze podataka. Budući da je ovo za mene hobi, apsolutno koristim besplatan alat pod nazivom Oracle SQL Developer Data Modeler (možete ga preuzeti).
Ovaj program omogućuje vam vizualno crtanje tablica i izgradnju odnosa s njima. Mnoge pogreške u dizajnu arhitekture baze podataka mogu se izbjeći ovim pristupom dizajnu (to vam već govorim kao profesionalni programer baza podataka). Izgleda otprilike ovako:
Nakon što smo projektirali samu arhitekturu, prelazimo na dosadniji dio koji se sastoji od sql kreacije kod za izradu tablica. Kako bih pomogao s ovim problemom, već koristim alat pod nazivom SQLiteStudio (koji se može preuzeti ovdje).
Ovaj alat je analog tako poznatih proizvoda kao što su SQL Naviagator, Toad itd. Ali kao što naziv implicira, dizajniran je za rad sa SQLiteom. Omogućuje vam vizualno stvaranje baze podataka i dobivanje DDL koda izrađene tablice. Usput, također vam omogućuje stvaranje pogleda (View), koje također možete koristiti u svojoj aplikaciji ako želite. Ne znam koliko je ispravan pristup korištenja prikaza u Android programima, ali ja sam ih koristio u jednoj od svojih aplikacija.
Zapravo, više nisam alate treće strane Ne koristim ga, a onda počinje magija s Android Studiom. Kao što sam gore napisao, ako počnemo ugrađivati SQL kod u Java kod, tada ćemo na izlazu dobiti slabo čitljiv, a samim tim i slabo proširiv kod. Stoga vadim sve SQL naredbe vanjske datoteke koji su u mom imeniku imovina. U Android Studiju to izgleda otprilike ovako:
O db i podatkovnim imenicima
Unutar imenika imovina stvorio sam dva imenika db_01 I podaci_01. Brojevi u imenima imenika odgovaraju broju verzije moje baze podataka s kojom radim. U imeniku db kod mene su pohranjene SQL skripte za stvaranje tablica. I u imeniku podaci pohranjuju se podaci potrebni za početno popunjavanje tablica.
Sada pogledajmo kod u mom DBHelper koje koristim u svojim projektima. Prvo, varijable klase i konstruktor (ovdje nema iznenađenja):
Privatni statički konačni String TAG = "RoadMap4.DBHelper"; String mDb = "db_"; String mData = "podaci_"; Kontekst mKontekst; int mVerzija; public DBHelper(kontekst konteksta, naziv niza, int verzija) ( super(kontekst, naziv, null, verzija); mKontekst = kontekst; mVerzija = verzija; )
Sada metoda onCreate i tu stvari postaju zanimljive:
@Override public void onCreate(SQLiteDatabase db) ( ArrayList
Logično, podijeljen je u dva ciklusa, u prvom ciklusu dobijem popis SQL instrukcija za izradu baze podataka i potom ih izvršim, u drugom ciklusu već popunjavam prethodno izrađene tablice s početnim podacima. Dakle, prvi korak:
Privatni ArrayList
Ovdje je sve vrlo jednostavno, samo čitamo sadržaje datoteka i povezujemo sadržaj svake datoteke u element niza. Imajte na umu da sortiram popis datoteka, jer tablice mogu imati strane ključeve, što znači da se tablice moraju kreirati određenim redoslijedom. Koristim numeraciju u nazivu datoteke i pomoću nje sortiram.
Privatna klasa QueryFilesComparator implementira Comparator
Uz ispunjavanje tablica sve je zabavnije. Moje tablice su ispunjene ne samo tvrdo kodiranim vrijednostima, već i vrijednostima iz resursa i UUID ključeva (nadam se da ću jednog dana doći do mrežne verzije svog programa kako bi moji korisnici mogli raditi s dijeljenim podacima). Sama struktura datoteka s početnim podacima izgleda ovako:
Unatoč činjenici da moje datoteke imaju ekstenziju sql, unutra nema sql koda, već ovo:
Prioriteti
pri_id:UUID:UUID
pri_name:string:normalno
pri_color:color:colorGreen
pri_default:int:1
prioriteti
pri_id:UUID:UUID
pri_object:string:object_task
pri_name:string:drži
pri_boja:boja:bojaPlava
pri_zadano:int:0
prioriteti
pri_id:UUID:UUID
pri_object:string:object_task
pri_name:string:važno
pri_boja:boja:bojaCrvena
pri_zadano:int:0
prioriteti
pri_id:UUID:UUID
pri_name:string:normalno
pri_color:color:colorGreen
pri_default:int:1
prioriteti
pri_id:UUID:UUID
pri_object:string:object_project
pri_name:string:drži
pri_boja:boja:bojaPlava
pri_zadano:int:0
prioriteti
pri_id:UUID:UUID
pri_object:string:object_project
pri_name:string:važno
pri_boja:boja:bojaCrvena
pri_zadano:int:0
Struktura datoteke je ovakva: Pozivam funkciju podjela(":") u odnosu na liniju i ako dobijem da je njena veličina 1, onda je to naziv tablice u koju treba upisati podatke. U suprotnom, to su sami podaci. Prvo polje je naziv polja u tablici. Drugo polje je tip kojim određujem što trebam napisati u to polje. Ako je to UUID, to znači da moram generirati jedinstvena vrijednost UUID. Ako mi string znači, potrebno je izvući string vrijednost iz izvora. Ako je boja, onda opet, trebate izdvojiti kod boje iz izvora. Ako je int ili tekst, tada jednostavno pretvaram danu vrijednost u int ili String bez ikakvih pokreta. Sam kod izgleda ovako:
Privatni ArrayList
30.04.2009 Aleksej Kovjazin
Relacijske baze podataka infiltrirale su se u gotovo sve. Informacijski sustavi, i, čini se, postali su najuglednije područje IT-a, gdje se malo toga može izmisliti, ali stvarno stanje stvari daleko je od idealnog.
Relacijske baze podataka danas se koriste u gotovo svim aplikacijama, od ugrađenih u mobilne i specijalne uređaje, aplikacija temeljenih na webu pa sve do sustava upravljanja poduzećima. Prodor baza podataka u sve vrste aplikacija ubrzava se, a programeri dobivaju sve više alata i pristupa lakših za korištenje. Možda ćete steći dojam da su programeri aplikacija za baze podataka "najbogatiji" sloj programera koji imaju alate za sve, ali to je daleko od slučaja. Embarcadero Technologies, 2008. godine, preuzimajući Borlandov CodeGear posao razvojnih alata, kombinirao je profesionalne alate za razvoj i dizajn aplikacija, razvojne alate i alate za upravljanje bazom podataka kako bi eliminirao probleme aplikacija i baze podataka.
Kaotičan dizajn baze podataka
U suvremenoj industriji razvoja softvera uvriježeno je uvjerenje da je nemoguće odrediti zahtjeve za proizvod prije pokretanja projekta, te se stoga razvoj mora prilagođavati njihovoj stalnoj promjeni. Kao rezultat toga, pojavili su se procesi temeljeni na iteracijama, uzimajući u obzir promjenjive zahtjeve, a refaktoriranje izvornog koda postalo je sastavni dio razvoja softvera. A što se događa u procesu iterativnog razvoja s bazama podataka? Promjena zahtjeva tjera vas da prilagodite shemu baze podataka, a najčešće se to događa na netransparentan način, bez analize velike slike i ovisnosti. Tablice, polja, strani ključevi i ograničenja stvaraju se i mijenjaju nasumično, nitko ne prati referentni integritet i nitko ne može sa sigurnošću reći kako se baza podataka u iteraciji N razlikuje od svog stanja u iteraciji N-1.
Zapravo, razvoj baza podataka danas se odvija “patch” metodom, kao u doba dominacije “waterfall” procesa – na početku projekta “crta se” određeni model baze podataka, na temelju parcijalnih zahtjeva koji su trenutno poznati, zatim se generira fizička baza podataka, a zatim se model zaboravlja unošenjem promjena izravno u bazu podataka. Nedostaci ovog pristupa su očiti: dijeljenje znanja i razumijevanje velike slike je teško, a promjene su neprozirne, mogu generirati kontradikcije u logici i shemi baze podataka, koje će ostati neotkrivene do trenutka uvođenja. programski sustav u rad, što dovodi do vrlo velikih gubitaka. Moderni programeri aplikacija baze podataka trebaju alate skrojene za iterativni razvoj baze podataka.
Prvi i najvažniji uvjet za takvu kondiciju je prisutnost pune mogućnosti obrnuti inženjering(obrnuti inženjering, stvaranje modela baze podataka na temelju analize njezine fizičke sheme) i izravni inženjering(unaprijed inženjering; kreiranje i promjena fizičke sheme baze podataka na temelju modela). U praksi to znači da uz pomoć dizajnerskog alata možete analizirati shemu postojeće baze podataka, iz nje kreirati model baze podataka, promijeniti model i odmah primijeniti promjene koje bi trebale zaista ispravno i dosljedno promijeniti shemu baze podataka, a ne ga pokvariti ili zbuniti.
Iterativni pristup također nas tjera na stvaranje podmodela povezanih s određenom iteracijom. Odvajanje entiteta i njihovih atributa u podmodel pomaže u razdvajanju područja odgovornosti između njih različitih programera, i između različitih iteracija, uz jamstvo ukupnog integriteta modela. Naravno, potrebna vam je i mogućnost usporedbe dva modela, i to ne u obliku SQL skripti, već na razini entiteta i atributa, kako biste vidjeli i u potpunosti razumjeli promjene nastale tijekom iteracije i njihov utjecaj na cijeli model.
Programeri aplikacija rijetko rade sami, pa im trebaju alati za suradnju, ali ako je to u redu na strani razvoja aplikacija, tada suradnja na bazi podataka obično uopće nije podržana na razini alata. Suradnja nužno podrazumijeva sustav kontrole verzija: sve verzije modela i fizičke sheme baze podataka moraju biti pohranjeni u jednom repozitoriju, pružajući mogućnost vraćanja i usporedbe shema od samog početka procesa razvoja.
Razvoj baze podataka jednako je važan kao i razvoj aplikacije, stoga je strateški smjer osigurati procesu razvoja baze podataka kontrolu verzija i alate za upravljanje zahtjevima, kao i eksplicitno povezivanje faza modeliranja i modificiranja baza podataka s iteracijama i promjenom zahtjeva. softverski projekt. Kako bi riješio ove probleme i podržao moderni iterativni proces razvoja baze podataka, Embarcadero nudi ER / Studio - alat za dizajn, analizu, obrnuti i naprijed inženjering koji vam omogućuje kontrolu verzija modela na temelju vašeg vlastitog repozitorija. Alat Change Manager može se koristiti kao sredstvo za kontrolu promjena metapodataka u fizičkim bazama podataka.
Fragmentacija koda
Najpoznatiji problem koji uvelike usporava razvoj aplikacija baze podataka je potreba za korištenjem različitih alata za debugiranje aplikacijskog koda i SQL koda u bazi podataka.
Razmotrimo jednostavan primjer. Pretpostavimo da se u Delphiju razvija aplikacija koja poziva pohranjenu proceduru DBMS Oracle. Koristeći Delphi alate, razvojni programer aplikacije može proći kroz način ispravljanja pogrešaka dok se ne pozove SQL upit, vidjeti parametre proslijeđene pohranjenoj proceduri i rezultat koji će procedura vratiti. Ali što se događa unutar procedure kada se izvrši na poslužitelju baze podataka? To se ne može utvrditi iz razvojnog okruženja naše aplikacije - za ovo morate preuzeti aplikaciju za SQL razvoj, koja ima mogućnost debugiranja pohranjenih procedura, a također prikazuje planove SQL upita, statistiku o njihovom izvršenju, omogućuje pregled i promijeniti shemu baze podataka. Međutim, ne možete proslijediti parametre iz okruženja za razvoj aplikacija u SQL razvojno okruženje i morate ih kopirati ručno prebacivanjem iz jednog prozora u drugi. Također je nemoguće vidjeti detaljne rezultate izvršenja SQL koda, kao što je plan upita, statistika izvršenja i tako dalje, u alatu za izradu aplikacija. Pojava tehnologije otklanjanja grešaka na više jezika omogućila je rješavanje ovih problema.
Prvi Embarcadero proizvod koji podržava višejezično ispravljanje pogrešaka je RapidSQL Developer (bivši PowerSQL), čiji se vizualni dio temelji na Eclipse tehnologiji i stoga vam omogućuje integraciju u bilo koje razvojno okruženje temeljeno na njoj (uključujući, naravno, JBuilder) i izvođenje dinamičkog unakrsnog ispravljanja pogrešaka - jezično ispravljanje pogrešaka. Sada, u trenutku izvršavanja pohranjene procedure na poslužitelju, programer se automatski prebacuje na punopravno okruženje za otklanjanje pogrešaka SQL-a unutar istog alata, sposobno otklanjati pogreške i uobičajenih SQL upita i pohranjenih procedura. Programer vidi stvarne ulazne parametre upita i pohranjenih procedura, dobivajući priliku da korak po korak otkloni pogreške u SQL kodu. Integracija RapidSQL Developera u razvojne alate kompatibilne s Eclipse prvi je korak u integraciji razvoja aplikacija i baza podataka, a sljedeći je na redu da pruži slične mogućnosti za Delphi, C++ Builder i druge alate za razvoj aplikacija iz Embarcadera.
Višeplatformske aplikacije baze podataka
Poseban izazov za programere je razvoj aplikacija baze podataka koje moraju raditi s više DBMS-a. Na primjer, banke i osiguravajuća društva obično imaju nekoliko veliki uredi i mnoge male grane. Većina poslovnih procesa vezanih uz unos operativnih informacija i dnevni tijek rada jednaki su u sjedištu i poslovnicama, ali je razmjer drugačiji. Prirodna želja da se uštedi na cijeni licenci za industrijski DBMS za korištenje u poslovnicama dovodi do ideje da bi bilo dobro odabrati drugačiji DBMS bez promjene aplikacije.
Iskusni programeri baza podataka dobro su svjesni suštine problema koji se ovdje pojavljuju: razlika u tipovima podataka i SQL dijalektima, nedostatak mehanizama za migraciju i replikaciju između različitih DBMS-a, složenost verifikacije migracije čine pisanje i rad aplikacija za različite DBMS-ove. noćna mora. Od strane alata za razvoj aplikacija, ovaj problem pokušavaju riješiti stvaranjem biblioteka za pristup podacima (dbExpress u Delphiju i C++ Builderu, ADO i ADO.Net od Microsofta), izgrađenih na zajedničkim arhitektonskim principima i metodama pristupa, kao i kao korištenjem brojnih objektno-relacijskih "omotača" (Object Relation Mapping, ORM) nad relacijskom logikom i strukturom baze podataka, generiranjem izvornog koda za rad s podacima na temelju analize sheme baze podataka i korištenjem mehanizma "adaptera" za implementaciju protokol određenog DBMS-a. Među najpopularnijim ORM-ovima su Hibernate for Java i ActiveRecord u RubyOnRails, koji pružaju objektno orijentirano sučelje za podatke pohranjene u DBMS-u. Za Delphi postoji sličan projekt tiOPF, za C# - NHibernate.
Naravno, korištenje takvih univerzalne knjižnice i skupovi komponenti mogu značajno smanjiti broj rutinskih operacija u procesu razvoja multiplatformske baze podataka. Međutim, to nije dovoljno kada pričamo o aplikacijama koje koriste složenije baze podataka koje aktivno koriste logiku ugrađenu u pohranjene procedure i okidače - za njihovu implementaciju, otklanjanje pogrešaka i testiranje potrebni su zasebni alati, ponekad potpuno različiti za različite DBMS. Za razvoj višeplatformskih aplikacija baze podataka, Embarcadero nudi alat RapidSQL.
Svi proizvodi baze podataka Embarcadero temeljeni su na više platformi i bazirani su na shemi baze podataka Thunderbolt i motoru za analizu statistike. Svaki podržani DBMS i svaka specifična verzija DBMS-a ima odgovarajuće ogranke koda u Thunderbolt jezgri, što vam omogućuje mapiranje sheme baze podataka s internim prikazom u ovoj jezgri što je točnije moguće i, što je najvažnije, izvođenje ispravnih konverzija između prikaza i prave baze podataka. Zahvaljujući jezgri Thunderbolt RapidSQL vam omogućuje razvoj visokokvalitetnog SQL koda za sve podržane platforme (Oracle, MS SQL, Sybase i razne opcije IBM DB2) i ER/Studio mogu izvesti precizan obrnuti i naprijed inženjering shema baze podataka.
Bilo da razvijate aplikaciju za dvije ili više platformi ili migrirate postojeću aplikaciju s jedne platforme na drugu, RapidSQL će pružiti sve potrebni alati za migraciju sheme, korisnika i dopuštenja između različitih DBMS-ova. Naravno, RapidSQL ne pretvara automatski PL/SQL procedure u T-SQL - to i dalje zahtijeva programera, ali alat pruža jedan prozor za razvoj na više platformi, objedinjene uređivače za objekte sheme, korisnike i njihova prava te SQL ispravljanje pogrešaka na svim podržanim platformama. Prema korisnicima RapidSQL-a, kao rezultat toga, štedi se do 70% vremena utrošenog na migraciju između različitih DBMS-ova.
Promjene podataka i sheme
Migracija s jednog DBMS-a na drugi je nemoguća bez njegove provjere. Tko i kako može jamčiti da su podaci koji se prenose iz jednog DBMS-a u drugi stvarno identični? Različite klijentske biblioteke, različite vrste podataka i različita kodiranja čine proces usporedbe podataka netrivijalnim zadatkom.
U stvarnom svijetu posao ne završava implementacijom aplikacije i baze podataka - održavanje je u tijeku, pojavljuju se nove verzije izvršnih datoteka aplikacije i zakrpe za bazu podataka. Kako možete biti sigurni da su sva potrebna ažuriranja primijenjena na bazu podataka i da će cijeli programski paket raditi ispravno?
Embarcadero je razvio alat Change Manager za usporedbu podataka, shema i konfiguracija baze podataka. Usporedba se odvija unutar jednog ili više DBMS-a, sa automatska provjera korespondencija između tipova podataka i formiranje SQL skripti razlika koje se mogu odmah primijeniti kako bi se baze podataka dovele u identično stanje. Modul za usporedbu metapodataka pruža usporedbu shema baze podataka između "živih" baza podataka i između baze podataka i SQL skripte i generira skriptu za razlike metapodataka. Ova se funkcionalnost može koristiti ne samo za provjeru baza podataka u odnosu na referentnu vrijednost, već i za organiziranje redovnog procesa ažuriranja baze podataka, kao i za provjeru neovlaštenih promjena, recimo, u udaljenim podružnicama velike organizacije. Slična je situacija s konfiguracijskim datotekama - Change Manager uspoređuje konfiguracijske datoteke i omogućuje vam da osigurate da konfiguracija implementiranih aplikacija zadovoljava zahtjeve za ovaj softver.
Izvedba aplikacije baze podataka
Koliko često vidimo aplikacije koje odlično rade na malim količinama testnih podataka, ali postaju neprihvatljivo spore na stvarnim količinama. Pogrešne procjene u zahtjevima, nedovoljno testiranje u ranim fazama, žurba s isporukom projekta poznati su uzroci lošeg razvoja aplikacija. Teoretičari razvoja softvera u ovom slučaju predlažu samopoboljšanje i temeljno poboljšanje kvalitete programa, ali svi praktičari znaju da je ponekad nemoguće ponovno napisati projekt bilo ekonomski ili, u nekim slučajevima, politički, a zadatak je optimizacija performansi mora se riješiti na bilo koji način.
Glavni uzrok problema s performansama u aplikacijama baze podataka leži u neoptimiziranim SQL upitima i pohranjenim procedurama. Optimizatori suvremenih baza podataka prilično su moćni, ali i oni imaju određene granice svojih mogućnosti, a da bi se postigla dobra izvedba, potrebno je pravilno sastaviti SQL upite, kreirati (ili izbrisati) dodatne indekse, denormalizirati bazu podataka u određenim slučajevima, prebaciti dio logike na okidače i pohranjene procedure.
Tijekom faze razvoja, optimizacija upita može se izvesti pomoću RapidSQL-a, koji uključuje modul SQL Profiler koji može analizirati planove i generirati savjete za poboljšanje performansi SQL upita. Ali što ako se problem pojavi već tijekom rada i nije lokaliziran u određenom SQL upitu? Ako performanse padaju u određeno doba dana ili, još gore, problem se javlja na udaljenoj kopiji sustava, dok je na glavnom poslužitelju sve u redu? Za takve slučajeve, DBOptimizer je alat za profiliranje baze podataka za Oracle, Microsoft SQL Poslužitelj, Sybase i IBM DB2.
Kada pokrenete način profiliranja, DBOptimizer prikuplja informacije o bazi podataka i okruženju za izvođenje, uključujući informacije o korištenju procesora i drugim parametrima operativnog sustava, te ih zapisuje u sesiju profiliranja. Rezultat je popis zahtjeva koji se izvode u bilo kojem vremenskom intervalu, razvrstanih prema utrošenim resursima. Za svaki problematični upit možete vidjeti njegov plan, statistiku izvršenja i druge detalje. Štoviše, DBOptimizer također pokazuje savjete-preporuke za poboljšanje upita u odnosu na određeni DBMS.
Kutija s alatima
Svi spomenuti alati, iako vam mogu pomoći u rješavanju problema, koriste se u različitim fazama životnog ciklusa razvoja baze podataka. Prilično je nezgodno i skupo držati desetak aplikacija za sve prilike koje mogu biti potrebne (ili možda neće biti potrebne) u procesu projektiranja, razvoja, migracije, optimizacije i održavanja baza podataka.
Objavljen u veljači 2009., Emdacadero All-Access svestrani je alat koji uključuje bitne alate za sve faze razvoja aplikacije baze podataka, od ER/Studio do DBOptimizera, od Delphija i C++Buildera do DBArtisana. Najbolji način da se All-Access opiše je da se usporedi s kutijom za alat koju svaki marljivi vlasnik ima kod kuće. Možda se svi alati ne koriste svaki dan, ali podesivi ključ bi uvijek trebao biti pri ruci u slučaju curenja.
All-Access ne prisiljava programere baza podataka ili arhitekte baza podataka na uloge, ali pruža univerzalni skup alata prikladnih za sve uloge u procesu razvoja aplikacije baze podataka, od arhitekta do testera; svim članovima razvojnog tima nudi alate za sve faze razvoja baze podataka, kao i set visoko specijaliziranih alata za optimizaciju baza podataka (DBOptimizer) i aplikacija (JOptimizer), omogućujući vam "proširenje" uska mjesta. Paket podržava višestruke DBMS-ove, što omogućuje uštedu troškova.
Tehničke razlike između objektno orijentiranih i relacijske baze podataka podaci doveli su do kulturološke podjele koja još uvijek odvaja zajednicu za upravljanje podacima od razvojne zajednice. Što dalje s ovim?
Delphi je razvojno okruženje koje koristi jezik Delphi programiranje(počevši od verzije 7, jezik u okruženju se zove Delphi, bivši Object Pascal), razvijen od strane Borlanda i izvorno implementiran u njegov Borland Delphi paket, po kojem je dobio sadašnje ime 2003. godine. Object Pascal je u biti nasljednik jezika Pascal s objektno orijentiranim proširenjima.
Delphi je najbolji alat za izradu aplikacija baze podataka. Optimalno, jer podržava tehnologiju vizualnog razvoja, koja može značajno smanjiti vrijeme razvoja uz zadržavanje dobre kvalitete i pouzdanosti softverski proizvod. Delphi u strukturi jezika omogućuje izbjegavanje skrivenih pogrešaka.
Značajke obitelji Delphi 7:
*Okruženje za brzi razvoj aplikacija koje integrira alate za simulaciju za razvoj i implementaciju aplikacija za e-trgovinu i web usluga.
* Podrška za programske jezike za Win32 (Delphi i C/C++) i za .NET (Delphi i C#) u jednom razvojnom okruženju, što olakšava održavanje i stvaranje novih Win32 aplikacija i lakše ovladavanje .NET tehnologijama;
*Sposobnost za programere tradicionalnih Windows aplikacija i Java programere da razviju .NET aplikacije bez napuštanja korištenog alata, uz zadržavanje vještina i sa sličnim konceptima programiranja;
* Novi sustav predložaka koda i druge inovacije u razvojnom okruženju kvalitativno poboljšavaju rad s izvornim kodom i povećavaju produktivnost razvoja;
Microsoft SQL Server 2000 cjelovita je baza podataka i ponuda analize podataka za brzo stvaranje skalabilna rješenja za e-trgovinu, poslovne aplikacije i skladišta podataka.
Značajno skraćuje vrijeme izlaska ovih rješenja na tržište, a istovremeno pruža skalabilnost za ispunjavanje najviših zahtjeva.
Paket Delphi je nastavak Borlandove linije Pascal prevodilaca. Pascal je kao jezik vrlo jednostavan, a snažno upisivanje podataka pomaže u ranom otkrivanju pogrešaka i omogućuje vam brzu izradu pouzdanih i učinkovitih programa.
Razvoj aplikacija baze podataka jedna je od najtraženijih značajki programskog okruženja Delphi. Snaga i fleksibilnost Delphija pri radu s bazama podataka temelji se na jezgri niske razine - Borland Database Engine (BDE). Njegovo sučelje za programiranje aplikacija naziva se sučelje za programiranje integrirane baze podataka (IDAPI). BDE vam omogućuje pristup podacima koristeći i tradicionalni pristup orijentiran na zapise (navigacijski) i pristup orijentiran na skup koji se koristi u SQL poslužiteljima baze podataka.
Biblioteka objekata sadrži skup vizualnih komponenti koje uvelike pojednostavljuju razvoj aplikacija za DBMS s arhitekturom klijent-poslužitelj. Objekti se inkapsuliraju u sebe Niži nivo- Borland Database Engine.
Postoje posebni skupovi komponenti odgovornih za pristup podacima i komponenti koje prikazuju podatke. Komponente za pristup podacima omogućuju povezivanje s bazom podataka, odabir, kopiranje podataka itd.
Komponente za vizualizaciju podataka omogućuju prikaz podataka u obliku tablica, polja, popisa. Prikazani podaci mogu biti tekstualni, grafički ili slobodnog oblika.
Tablice su pohranjene u bazi podataka. Neki DBMS-ovi pohranjuju bazu podataka u nekoliko zasebnih datoteka koje su tablice (uglavnom svi lokalni DBMS-ovi), dok se drugi sastoje od jedne datoteke koja sadrži sve tablice i indekse (InterBase).
Objekti baze podataka u Delphiju temelje se na SQL-u i uključuju punu snagu Borland Database Enginea. Delphi također uključuje Borland SQL Link, tako da je pristup Oracle, Sybase, Informix i InterBase DBMS vrlo učinkovit. Dodatno, Delphi uključuje lokalni Interbase poslužitelj tako da možete razvijati izvanmrežne aplikacije koje se mogu proširiti na bilo koji vanjski SQL poslužitelj.
Skalabilnost u praksi - ista aplikacija može se koristiti i za lokalne i za ozbiljnije klijent-poslužitelj opcije.
Iako Delphi nema vlastiti format tablice baze podataka, on ipak pruža snažnu podršku za veliki broj različitih DBMS-ova - i lokalnih (npr. dBase ili Paradox) i industrijskih (npr. Sybase ili InterBase).
