Agenția Federală pentru Educație
Instituție de învățământ de stat de învățământ profesional superior
„UNIVERSITATEA DE STAT CHELYABINSK”
Lucru de curs
Dezvoltarea aplicației baze de date
Analiza domeniului
Descrierea domeniului și funcțiile sarcinilor de rezolvat
În cadrul cursului, în conformitate cu sarcina, activitățile departamentului de vânzări al întreprinderii „Mâncare rusească” sunt automatizate.
Subiectul domeniului automatizării îl constituie unele dintre funcțiile postului ale departamentului de vânzări. Departamentul de vânzări are un plan de eliberare a produselor finite întocmit pe trei luni. În conformitate cu acest plan, atelierele produc produse, dar producția reală depinde de mulți factori și poate diferi de cel planificat. Departamentul de vânzări primește și facturile magazinului, care reflectă producția efectivă și livrarea produselor către anumite depozite.
Sarcina departamentului de vânzări este să analizeze implementarea planului de livrare a produselor către depozite. Pentru a face acest lucru, trebuie să selectați datele planificate și reale pentru o anumită perioadă pentru un anumit depozit și să analizați abaterea faptului de la plan.
Întreprinderea dispune de 3 ateliere unde sunt fabricate produsele. Gama de produse este prezentată în tabel.
Tabelul 1.
Nr. magazin Nume magazin Nume produs Unitate de producție minimă Preț pe unitate lapte 3,5% cutie 50 bucăți 650,00 rub.1 lapte lapte 4,0% cutie 50 bucăți 700,00 rub. cutie cremă 50 bucăți1 200,00 rub. carnati fierti ambalare 50 bucati2 500,00 rub.2 carnati afumati ambalare 50 bucati3 400,00 rub. cârnați pachet de 50 bucăți1 200,00 rub. conserve de stiuca cutie de 50 conserve 670,00 rub.3 caviar de peste cutie neagra 50 conserve 5 400,00 rub. cutie roșie caviar 50 conserve 5 370,00 rub. Produsele eliberate de ateliere sunt livrate la depozite Masa 2. Număr depozit Nume depozit 1 Număr depozit 12 Număr depozit 23 Număr depozit 3 Lista documentelor de intrare (primare). Următoarele sunt folosite ca documente primare pentru rezolvarea acestei probleme: plan de producție pentru ateliere lista facturilor magazinului Număr atelier Număr factură atelier Data depunerii caietul de sarcini al facturii atelierului Număr atelier Număr factură atelier Cod produs Cantitate Limitarea domeniului de subiect. La dezvoltarea unui proiect de curs, sunt permise următoarele restricții: produsul finit este repartizat unui singur depozit de produse finite și poate fi produs de mai multe ateliere. produsul finit are o singură unitate de măsură. un atelier poate produce mai multe tipuri de produse. mai multe articole de produse finite pot fi depozitate într-un singur depozit. producerea produselor finite de către atelier este planificată lunar. același articol poate fi programat pentru lansare în luni diferite. O factură de magazin pentru livrarea produselor finite la depozit poate conține mai multe nume de produse, numărul acesteia fiind unic doar pentru un singur magazin. Formularea problemei Esența organizatorică și economică a complexului de sarcini. Una dintre principalele probleme ale întreprinderii este discrepanța dintre cantitatea de producție planificată, care se formează în conformitate cu solicitările cumpărătorilor și cantitatea reală de produse expediate de ateliere către depozite. Pentru a rezolva această problemă, este necesar să primiți în timp util (prompt) informații despre disponibilitatea, lipsa sau surplusul de produse în depozite în raport cu planul. Surplusul rămâne în depozit, perioada de valabilitate a acestora poate fi depășită și se creează active nelichide. Descrierea informațiilor de ieșire Informațiile de ieșire vor fi prezentate sub forma unui formular de raportare. Analiza implementarii planului de livrare a produselor la depozit _________________ Luna Nume produs Unitate de măsură Cantitate Surplus Plan Fapt Pentru obținerea acestui formular se folosesc datele documentelor primare: lista de produse; lista depozitelor; lista atelierelor; un plan de producție de produse prin ateliere; lista facturilor magazinului; Descrierea informațiilor de intrare. Informațiile de intrare sunt împărțite în condiții constante (cărți de referință), păstrându-și valorile pentru o perioadă lungă de timp și schimbându-se constant, adică informații contabile operaționale. Informațiile permanente condiționate includ: lista produselor fabricate; lista atelierelor de producție; lista depozitelor; unități de măsură de referință. Informațiile contabile operaționale includ: un plan de producție de produse prin ateliere; lista facturilor magazinului; specificarea facturii magazinului. Să prezentăm documentele primare cu detaliile din Tabelul 3: Nr. p / p Denumirea documentului Detalii 1 Lista produselor fabricate 1. Cod produs 2. Denumire produs. 3. Cod unitate. 4.Prețul. 5. Numărul depozitului 3 Lista depozitelor 1. Codul depozitului. 2.Denumirea depozitului 2 Lista atelierelor 1. Codul atelierului. 2. Denumirea atelierului 4 Unități de măsură de referință 1. Codul unității de măsură. 2. Denumirea unității de măsură 5 Planul producției de produse de către magazine 1. Numărul magazinului. 2. Luna lansării. 3.Cod produs. 4.Cantitate 6 Lista facturilor magazinului 1. Numărul magazinului. 2.Numărul facturii magazinului. 3. Data livrării 7 Specificarea facturii magazinului 1. Numărul magazinului. 2.Numărul facturii magazinului. 3.Cod produs. 4.Cantitatea. Proiectarea bazei de date Alocarea obiectelor informaționale Una dintre cele mai dificile etape ale procesului de proiectare a bazei de date este elaborarea tabelelor, deoarece rezultatele pe care ar trebui să le producă baza de date (rapoarte, formulare de ieșire etc.) nu oferă întotdeauna o imagine completă a structurii tabelului. Informațiile din tabel nu trebuie dublate. Nu ar trebui să existe repetări între mese. Când anumite informații sunt stocate într-un singur tabel, atunci acestea vor trebui modificate doar într-un singur loc. Acest lucru face munca mai eficientă și, de asemenea, elimină posibilitatea nepotrivirii informațiilor în diferite tabele. Fiecare tabel trebuie să conțină informații despre un singur subiect. Informațiile despre fiecare subiect sunt mult mai ușor de prelucrat dacă sunt conținute în tabele independente unele de altele. Fiecare tabel conține informații despre un subiect diferit, iar fiecare câmp din tabel conține informații separate despre subiectul tabelului Pentru a implementa conexiuni de date din tabele diferite, fiecare tabel trebuie să conțină un câmp sau un set de câmpuri care va stabili o valoare individuală pentru fiecare înregistrare din tabel. Un astfel de câmp sau set de câmpuri se numește cheie primară. După distribuirea datelor în tabele și definirea câmpurilor cheie, trebuie să definiți relațiile dintre tabele. Tabelul 4 Obiecte informaționale Informații obektSootvetstvuyuschy dokumentRekvizityKlyuchIzdeliyaSpisok produs Unitate izdeliyKod izdeliyaDa Nume izdeliyaKod Număr izmereniyaTsena skladaTsehaSpisok tsehovNomer tsehaDa Nume tsehaSkladySpisok skladovNomer skladDaNaimenovanie skladaEdinitsa izmereniyaSpravochnik unități izmereniyaKod unitate de produse cu eliberare unitate izmereniyaDa Nume izmereniyaPlan vypuskaPlan tsehamiNomer tsehaDaNomer cod mesyatsaDa izdeliyaDa KolichestvoTsehovye nakladnyeSpisok magazin nakladnyhNomer tsehaDa numărul breslei nakladnoyDa Data sdachiSpetsifikatsii Specificatii guild nakladnoyNomer tsehaDaNomer magazin facturăDa Cod produsDa CantitateLunăPentru obiectul „Plan de lansare” Numărul luniiDa Numele lunii Modelarea informaţional-logică şi determinarea legăturilor dintre obiectele informaţionale Un model informațional-logic este un model de date care afișează un domeniu sub forma unui set de obiecte informaționale și legături structurale între ele. Modelul nostru logic informațional va arăta astfel: Fig. 1. Model infologic În urma dezvoltării bazei de date au fost obținute 8 obiecte informaționale. Să definim tipul de conexiune în fiecare pereche de aceste inf. obiecte. Unitate de măsură - Produs Tipul de legătură este de la 1 la mai mulți, deoarece mai multe articole pot fi măsurate cu o unitate de măsură, dar fiecare articol este măsurat în prezent cu o unitate de măsură. Conexiunea dintre aceste obiecte este conform atributului Unit code. Depozite - Produs Tipul de legătură este de la 1 la mulți, deoarece mai multe articole de produse finite pot fi stocate într-un singur depozit. Comunicare - după atribut Număr depozit. Produse - Plan de lansare Tipul de relație este de la 1 la mai mulți, deoarece un articol poate fi programat pentru lansare în luni diferite, dar fiecare cantitate planificată se referă la un singur articol într-o anumită lună. Comunicare prin codul de produs necesar. Luna - Plan de lansare Tipul de link este 1-to-many, în fiecare lună se întocmește un plan de producție. Comunicarea după numărul necesar al lunii. Workshop - Plan de lansare Tipul de comunicare 1 - pentru mulți, un atelier este programat să fie lansat în luni diferite. Comunicare prin numărul de magazin necesar. Ateliere - Facturi de atelier Atelier - Specificații Tipul de conexiune este 1-to-many, un magazin emite multe facturi. Comunicare prin numărul de magazin necesar. Facturi atelier - Caietul de sarcini Tipul de link este 1-to-many, o factură de magazin poate conține mai multe BOM. Comunicare prin cerințe - Numărul facturii magazinului și numărul magazinului. Specificațiile produsului Tip de legătură 1 - pentru mulți, un produs este emis de mai multe ori, dar această cantitate emisă se referă la un singur produs. Comunicare prin codul de produs necesar. Structura logică a bazei de date Structura logică a unei baze de date relaționale este o reflectare adecvată a modelului informațional-logic obținut al domeniului de studiu. Nu sunt necesare transformări suplimentare pentru modelul canonic. Fiecare obiect de informații despre modelul de date este mapat la un tabel relațional corespunzător. Structura unui tabel relațional este determinată de atributele obiectului informațional corespunzător, unde fiecare coloană (câmp) corespunde unuia dintre atribute. Atributele cheii formează o cheie unică pentru un tabel relațional. Pentru fiecare coloană din tabel, sunt specificate tipul, dimensiunea datelor și alte proprietăți. Topologia designului schemei de date coincide practic cu topologia modelului informatic - logic. Ca parte a acestui curs, structura logică a bazei de date va arăta ca (Fig. 2.): Fig. 2. Structura logică a bazei de date Implementarea bazei de date în mediul Microsoft Access Pentru a implementa baza de date proiectată, vom folosi unul dintre cele mai populare sisteme de gestionare a bazelor de date pentru sistemul de operare Windows Microsoft Access. Acest SGBD este inclus în pachetul integrat larg răspândit al Microsoft Office și este pe deplin compatibil cu programele acestui pachet. Un mare avantaj al MS Access este disponibilitatea instrumentelor de dezvoltare a sistemelor informatice pentru utilizatorii de diferite calificări: de la începători la profesioniști. MS Access DBMS se concentrează pe lucrul cu următoarele obiecte: Tabelele sunt elementul principal al oricărei baze de date relaționale, sunt concepute pentru a defini și stoca date; Interogările servesc ca surse pentru crearea altor interogări, formulare și rapoarte. Interogările vă permit să modificați și să analizați datele. Cel mai obișnuit tip de interogare, o interogare de selecție, este un set de reguli utilizate pentru a selecta date dintr-unul sau mai multe tabele înrudite. Rezultatele execuției interogării sunt prezentate sub forma unui tabel virtual. Formularele sunt un obiect conceput în primul rând pentru a introduce date, a le afișa pe ecran sau a controla funcționarea unei aplicații. Este posibil să se utilizeze formulare pentru a îndeplini cerințele utilizatorului de prezentare a datelor din interogări sau tabele, formularele putând fi și tipărite. Rapoartele sunt un mijloc de organizare a ieșirii datelor pentru tipărire. Cu ajutorul raportului, este posibilă afișarea informațiilor necesare în formularul solicitat. Puteți previzualiza raportul înainte de imprimare. Sursele de date pentru rapoarte sunt tabelele și interogările; Macro-uri - un obiect care este o descriere structurată a uneia sau mai multor acțiuni care ar trebui efectuate de MS Access ca răspuns la un anumit eveniment. Modulele sunt obiecte care conțin programe scrise în limbajul Visual Basic pentru aplicații (VBA). Ca parte a sarcinii, nu este nevoie să creați macrocomenzi și module în baza de date proiectată. Toate obiectele MS Access sunt localizate într-un singur fișier de pe disc. MS Access are o interfață cu mai multe ferestre, dar poate procesa doar o bază de date la un moment dat. Pentru a crea o nouă bază de date, trebuie să porniți MS Access, să selectați modul „Nouă bază de date”, să introduceți numele bazei de date și să selectați locația acesteia pe disc. Tabelele bazei de date proiectate sunt obiecte informaționale, câmpurile tabelelor sunt detaliile obiectelor informaționale. Pentru a completa informațiile de intrare, va fi necesar să proiectați o interfață cu utilizatorul - formulare: formularul „Produse” - pentru editarea tabelului „Produse”; Formular „Plan de lansare” - pentru corectarea planului pentru numărul de produse fabricate; formularul „Foțe de parcurs atelier” care conectează tabelul „Foțe de parcurs atelier” și tabelul „Specificații scrisori de parcurs atelier” în funcție de „Folosele de parcurs atelier”. Pentru a implementa raportul „Analiza implementării planului de livrare a produselor către depozit”, va fi suficientă executarea unei cereri de selecție a lunii (tabelul „lună”), denumirea produsului (tabelul „Produse” ), unități de măsură (tabelul „Unitate de măsură”), cantități conform planului (tabelul „Plan de producție”), cantități reale (tabelul „Specificații”), cu adăugarea unei coloane „surplus” cu o formulă de deducere. Crearea de tabele și scheme de date vânzări de baze de date de aplicații Există mai multe moduri de creare a tabelelor (mod tabel, designer, expert tabel, import tabele, link către tabele din alte baze de date). Cel mai versatil mod de a crea un tabel este utilizarea modului de proiectare. Pentru a crea un tabel în acest mod, trebuie să definiți câmpurile tabelului. Fiecare câmp este caracterizat de un nume, tip de date și proprietăți. Numele câmpului nu trebuie să conțină caractere speciale. Microsoft Access poate folosi următoarele tipuri de date: Text - servește la stocarea informațiilor alfanumerice. Lungimea câmpului nu trebuie să depășească 255 de caractere; Câmp MEMO - destinat stocării informațiilor alfanumerice de până la 65535 caractere; Numeric - folosit pentru datele numerice implicate în calcule; Data / ora - data si (sau) ora in intervalul de la 100 la 9999; Monetar - folosit pentru valorile monetare și datele numerice utilizate în calculele matematice, efectuate cu o precizie de 15 cifre în totalitate și până la 4 cifre în partea fracționată; Counter - servește pentru a genera numere unice în creștere secvențială sau aleatoare care sunt introduse automat în câmp atunci când fiecare înregistrare nouă este adăugată la tabel. Valorile câmpurilor de tip Counter nu pot fi modificate; Boolean - destinat valorilor booleene (Da / Nu, Adevărat / Fals). Lungimea câmpului logic este de 1 bit; Câmp obiect OLE - orice obiect în format binar (document Word, tabel Excel, imagine, înregistrare audio) legat sau încorporat într-un tabel MS Access. Dimensiunea unui astfel de câmp nu trebuie să depășească 1 GB; Lookup Wizard - Creează un câmp care vă solicită să selectați valori dintr-o listă sau dintr-o casetă combinată care conține un set de valori constante sau valori dintr-un alt tabel. Selectarea acestei opțiuni dintr-o casetă listă dintr-o celulă lansează expertul de căutare, care determină tipul câmpului. Proprietățile câmpului sunt setate în partea de jos a ferestrei de proiectare a tabelului din fila General. Lista de proprietăți este diferită pentru fiecare tip de date. Să luăm în considerare câteva dintre ele: Dimensiunea câmpului - limitează lungimea câmpului la numărul specificat de caractere; Format - specifică formatul pentru date și numere; Număr de zecimale - pentru câmpurile monetare și numerice, stabilește numărul de zecimale; Mască de introducere - pentru câmpurile text și dată, definește șablonul conform căruia datele vor fi introduse în câmp; Câmp indexat - vă permite să creați un index care va servi pentru a accelera căutarea și sortarea tabelului după acest câmp. Un index este un tabel de servicii intern format din două coloane: valoarea câmpului indexat și numărul tabelului. Puteți seta următoarele proprietăți pentru indecși: a) „Da (potrivirile sunt permise)” - se creează un index care include valorile câmpurilor care se potrivesc, b) „Da (nu sunt permise potriviri)” - se creează un index pe baza unicului valoarea câmpului, c) „Nu” – nu este creat niciun index Un tabel din MS Access conține de obicei o cheie primară. Pentru a crea o cheie, trebuie să selectați un câmp din constructor și să îi atribuiți o cheie prin meniul contextual. Tip de date câmp Dimensiunea câmpului Cheie primară Cod unitate Numeric întreg lung Da Nume unitate Text 50 Tabelul „Produse”. Tip de date câmp Dimensiunea câmpului Cheie primară Cod articol Numeric întreg întreg Da Nume articol Text100 Cod unitate Numeric întreg lung Preț Număr monedă-depozit Octet numeric Masa depozitelor Tip de date câmp Dimensiunea câmpului Cheie primară Număr depozit Octet numeric Da Nume depozit Text 20 Tabelul lunii Tip de date câmp Dimensiunea câmpului Cheie primară Numărul lunii Numeric întreg Da (nu sunt permise potriviri) Nume luni Text 20 Masa de atelier Tip de date câmp Dimensiunea câmpului Cheie primară Număr magazin Octet numeric Da Nume magazin Text 30 Tabelul Planului de lansare Câmp Tip de date Dimensiune câmp Cheie principală Număr magazinNumericByteYesMonthNumberNumericIntegerDa Cod produs Numeric întreg lungDaNumărNumericReal (16) Tabel facturi atelier Tip de date câmp Dimensiunea câmpului Cheie primară Număr magazin Octet numeric Da Număr factură magazin NumericLong Întreg Da Data livrăriiData \ Ora- Tabelul „Specificații” Tip de date câmp Dimensiunea câmpului Cheie primară Număr magazin Numeric ByteDa Număr factură magazin NumericLong IntegerDa Cod articolNumeric Long IntegerYesNumberNumericValid (16) Să creăm o schemă de date în Microsoft Access: Fig. 3. Schema de date Crearea unei interfețe cu utilizatorul Formularele sunt mijlocul principal de a crea o interfață cu utilizatorul care oferă cel mai convenabil mod de a prezenta, vizualiza, edita date și controla progresul unei aplicații. Principalele funcții ale formularelor sunt introducerea datelor, ieșirea și editarea informațiilor, controlul progresului aplicației, ieșirea mesajelor, tipărirea informațiilor. Există următoarele tipuri de forme: Normal - afișează o înregistrare a sursei de date; Multi-pagină - conceput pentru a funcționa cu o sursă de date care are un număr mare de câmpuri; Panglică - arată mai multe înregistrări ale sursei de date, convenabile pentru un număr mic de câmpuri; Popup - afișat în prim-planul ecranului și vă permite să lucrați cu alte forme; Exclusiv - nu permite trecerea la alte forme până când nu este închisă; Un sclav este o modalitate bună de a reprezenta date pe partea „mulți” a unei relații unu-la-mulți, este încorporat în forma principală și depinde întotdeauna de aceasta. Din punct de vedere structural, formularul este format din trei secțiuni - titlu, note și zone de date. Secțiunile formularului conțin controale. Orice control poate fi plasat pe un formular folosind Caseta de instrumente, care este afișată în designerul formularului. Cele mai frecvent utilizate elemente: (inscripție) - servește la crearea de inscripții permanente în formă; (câmp) - un element care arată valoarea din sursa de date; (caseta combinată) - concepută pentru a crea liste derulante în formular; (buton) - conceput pentru a crea butoane de comandă sub forma care efectuează anumite acțiuni; (checkbox) - un element care vă permite să activați sau să dezactivați valoarea unui parametru; (subformular) - servește la încorporarea unui subformular în cel principal. Este mai convenabil să creați un formular folosind un expert. Primul pas este să selectați sursa de date și câmpurile pentru formular. La al doilea pas, ar trebui să specificați aspectul formei proiectate. Al treilea pas este alegerea stilului formularului (imaginea de fundal pentru formular, formatul fonturilor și culorilor). La ultimul pas, introduceți numele formularului, sub care va fi stocat în baza de date. Formularul creat cu ajutorul vrăjitorului trebuie finalizat în modul proiectare. Adăugați etichetele, butoanele, subformularele necesare. În cadrul lucrărilor de curs, au fost create următoarele formulare: Orez. 4. Produse. Fig. 5. Planul de lansare. Formularul „facturi magazin” conține subformularul „Specificații” Fig. 6. Facturi de atelier. Implementarea raportului Înainte de a genera un raport, trebuie să creați o interogare. Interogările sunt un instrument esențial în orice sistem de gestionare a bazelor de date. Scopul cererilor este în descrierea tipurilor de cereri. Interogările pot fi create atât în modul Query Wizard (apoi trebuie să selectați tipul de interogare), cât și în Query Designer. Există patru tipuri de interogări în Microsoft Access: interogările simple de selectare afișează date dintr-unul sau mai multe tabele dintr-un tabel; este permisă adăugarea unui parametru (condiția de selecție); Interogările de referință încrucișată colectează date dintr-unul sau mai multe tabele într-un format asemănător unei foi de calcul și sunt folosite pentru a analiza datele; este permisă adăugarea unui parametru (condiția de selecție); Solicitările de modificare sunt folosite pentru a crea tabele noi din rezultatele interogării și pentru a face modificări (adăugare, ștergere) la datele tabelelor existente; este permisă adăugarea unui parametru (condiția de selecție); o interogare pentru a găsi înregistrări care nu se potrivesc cu nicio înregistrare din tabelul subordonat. Cu ajutorul interogărilor în modul expert de interogare (prin selectarea raportului final al interogării), este posibil să se efectueze un calcul (suma, medie, minim, maxim) folosind datele selectate. Pentru a implementa raportul „Analiza implementării planului de livrare a produselor către depozitul nr. ___”, va fi suficientă executarea unei cereri pentru o selecție a lunii (tabelul „lună”), numele produsului (tabelul „ Produse”), unități de măsură (tabelul „Unitate de măsură”), cantități după plan (tabelul (tabelul „Plan de eliberare”), cantități reale (tabelul „Specificații”), cu adăugarea unei coloane „surplus” cu o formulă de scădere, precum si cu o selectie a numarului de depozit (tabelul (tabelul "depozite")) cu o conditie de selectie fara afisarea acestui depozit in tabelul rezultat. Pentru acest raport, a fost creată o interogare folosind constructorul: Fig. 8. Rezultatul interogării. După cantitatea diferită de marfă din caietul de sarcini, se poate observa că conservele de biban a fost predată depozitului atât în iulie, cât și în septembrie de două ori. Generarea rapoartelor Rapoartele sunt cea mai bună modalitate de a prezenta informații dintr-o bază de date sub formă de hârtie. Ele oferă opțiuni puternice pentru gruparea și calcularea subtotalurilor și subtotalurilor pentru seturi mari de date. Rapoartele pot fi folosite pentru a genera facturi frumos concepute, comenzi de achiziție, etichete de corespondență, materiale de prezentare și alte documente de care este posibil să aveți nevoie pentru a vă conduce afacerea cu succes. Raportul conține următoarele domenii: titlu - afișat o singură dată la începutul raportului; antet și subsol - repetate pe fiecare filă a raportului, utilizate pentru afișarea informațiilor permanente sau periodice (data raportului, numerele paginilor etc.); titluri și note pentru grupuri - afișate atunci când gruparea se realizează în raport la începutul și, respectiv, la sfârșitul fiecărei grupe. În raport pot fi create până la zece niveluri de grupare; zona de date - este folosită pentru a introduce linii de raport informativ; notă de raport - concepută pentru a afișa informații rezumative asupra raportului în ansamblu, tipărite o singură dată la sfârșitul raportului. Este mai convenabil să creați un raport, ca un formular, folosind un expert. După crearea unui raport, puteți modifica structura acestuia în modul proiectare (corectați și formatați titlurile de coloană ale raportului, adăugați sau eliminați câmpuri etc.). În urma executării raportului s-a obţinut forma tipărită a acestuia. Analiza implementării planului de livrare a produselor la depozitul nr. 1, 2, 3 - Fig. 10-12. A fost adăugat câmpul „număr factură magazin” pentru a arăta că produsul poate fi predat la depozit de două ori pe lună sub două facturi diferite. Fig. 9. Designer de rapoarte Fig. 10. Analiza implementării planului de livrare a produselor la depozitul nr. 1 Fig. 11. Analiza implementarii planului de livrare a produselor la depozitul nr.2 Fig. 12. Analiza implementării planului de livrare a produselor la depozitul nr. 3 Bibliografie Tarasov V.L. Lucrul cu baze de date în mediul Access, Tutorial / Universitatea de Stat Nizhny, Nijni Novgorod, 2005. Shekhtman V.E. Baze de date, Manual SQL la disciplinele „Baze de date”, „Baze de date și sisteme expert”, „Tehnologia modernă de programare SQL”. / - NPI KemSU, Novokuznetsk, 2006. Andreev V.A., Tupikina E.N., Sisteme de management al bazelor de date (Microsoft Access), ghiduri / FESAEU, Vladivostok, 2003. Veiskas D., Lucru eficient cu ACCESS, ghid de studiu / SPb, 1996. Khomonenko A.F., Tsygankov V.M., Maltsev M.G. Baze de date, Manual pentru Universităţi / Ed. prof. A.D. Khomonenko. - SPb .: print KORONA, 2002.
- Tutorial
- Mod de recuperare
Salutare tuturor! Numele meu este Oleg și sunt programator amator pentru Android. Amator pentru că în momentul de față câștig bani programând într-o cu totul altă direcție. Și acesta este un hobby căruia îi dedic timpul liber. Din păcate, nu am programatori Android familiari și îmi extrag toate cunoștințele de bază fie din cărți, fie de pe Internet. În toate acele cărți și articole de pe Internet pe care le-am citit, foarte puțin spațiu este alocat creării unei baze de date pentru aplicație și, de fapt, întreaga descriere se rezumă la crearea unei clase care este moștenitoare SQLiteOpenHelperși injectarea ulterioară a codului SQL în codul Java. În afară de faptul că obținem cod slab lizibil (și dacă în aplicația noastră apar mai mult de 10 tabele, atunci amintirea tuturor acestor relații dintre tabele este încă un infern), atunci, în principiu, poți trăi, desigur, dar cumva ești absolut nu vreau.
Am uitat să spun cel mai important lucru, putem spune că aici este testul meu al stiloului. Și așa am mers.
La eterna întrebare: de ce?
De ce în cărțile și articolele dedicate programării pentru Android nu descriu instrumente pentru proiectarea unei arhitecturi de baze de date și orice tipare de lucru cu bazele de date în stadiul creării lor, sincer nu știu. S-ar părea să adaugi doar câteva pagini la o carte sau să scriu un articol separat (așa cum fac acum) la fel de ușor ca să decojim perele - dar nu. În acest articol, voi trece pe scurt prin instrumentele pe care le folosesc în munca mea și mai detaliat despre codul care este responsabil pentru crearea inițială a bazei de date, care, din punctul meu de vedere, pare mai lizibil și mai convenabil.
Dacă aplicația noastră are mai mult de 5 tabele, atunci ar fi bine să folosim un instrument pentru proiectarea vizuală a arhitecturii bazei de date. Deoarece acesta este un hobby pentru mine, folosesc un instrument absolut gratuit numit Oracle SQL Developer Data Modeler ( îl puteți descărca).
Acest program vă permite să desenați vizual tabele și să construiți relații cu acestea. Multe greșeli de proiectare în arhitectura bazei de date pot fi evitate cu această abordare de proiectare (vă spun deja asta ca programator profesionist de baze de date). Arata cam asa:
După ce am proiectat arhitectura în sine, trecem la partea mai plictisitoare, care constă în crearea codului SQL pentru crearea tabelelor. Pentru a ajuta în această problemă, folosesc deja un instrument numit SQLiteStudio (care, la rândul său, poate fi descărcat aici).
Acest instrument este analog cu produse cunoscute precum SQL Naviagator, Toad etc. Dar, după cum sugerează și numele, este adaptat pentru lucrul cu SQLite. Vă permite să creați vizual o bază de date și să obțineți codul DDL al tabelelor create. Apropo, vă permite și să creați Vizualizări, pe care le puteți utiliza și în aplicația dvs., dacă doriți. Nu știu cât de corectă este abordarea utilizării vizualizărilor în programele Android, dar într-una dintre aplicațiile mele le-am folosit.
De fapt, nu mai folosesc instrumente terțe și atunci magia începe cu Android Studio. După cum am scris deja mai sus, dacă începem să injectăm cod SQL în codul Java, atunci rezultatul va fi slab lizibil și, prin urmare, codul slab extensibil. Prin urmare, transfer toate instrucțiunile SQL în fișiere externe care se află în director active... În Android Studio, arată cam așa:
Despre db și directoare de date
În interiorul directorului active am creat două directoare db_01și data_01... Numerele din numele directoarelor corespund cu numărul versiunii bazei mele de date cu care lucrez. În director db Stochez scripturile SQL pentru a crea tabele în sine. Și în director date se stochează datele necesare pentru completarea iniţială a tabelelor.
Acum să aruncăm o privire la codul din interiorul meu DBHelper pe care le folosesc în proiectele mele. Mai întâi variabilele de clasă și constructorul (fără surprize aici):
Private static final String TAG = "RoadMap4.DBHelper"; String mDb = "db_"; String mData = "data_"; Context mContext; int mVersion; public DBHelper (context context, nume șir, versiune int) (super (context, nume, nul, versiune); mContext = context; mVersion = versiune;)
Acum metoda onCreate si aici devine mai interesant:
@Override public void onCreate (SQLiteDatabase db) (ArrayList
În mod logic, este împărțit în două bucle, în prima buclă primesc o listă de instrucțiuni SQL pentru crearea unei baze de date și apoi le execut, în a doua buclă umplu deja tabelele create anterior cu date inițiale. Și așa, pasul unu:
Private ArrayList
Totul este destul de simplu aici, doar citim conținutul fișierelor și concatenăm conținutul fiecărui fișier într-un element de matrice. Vă rugăm să rețineți că sortez lista de fișiere, deoarece tabelele pot avea chei străine, ceea ce înseamnă că tabelele trebuie create într-o anumită ordine. Folosesc numerotarea in numele fisierelor, iar cu ajutorul acesteia fac sortarea.
Clasa privată QueryFilesComparator implementează Comparator
Cu completarea tabelelor, totul este mai distractiv. Tabelele mele sunt umplute nu numai cu valori codificate, ci și cu valori din resurse și chei UUID (sper să ajungă într-o zi la versiunea de rețea a programului meu, astfel încât utilizatorii mei să poată lucra cu date partajate). Structura fișierelor de date inițiale arată astfel:
În ciuda faptului că fișierele mele au extensia sql, nu există niciun cod sql în interior, dar acest lucru:
Priorități
pri_id: UUID: UUID
pri_name: șir: normal
pri_color: culoare: colorGreen
pri_default: int: 1
priorități
pri_id: UUID: UUID
pri_object: șir: object_task
pri_name: șir: hold
pri_color: culoare: colorBlue
pri_default: int: 0
priorități
pri_id: UUID: UUID
pri_object: șir: object_task
pri_name: șir: important
pri_color: culoare: colorRed
pri_default: int: 0
priorități
pri_id: UUID: UUID
pri_name: șir: normal
pri_color: culoare: colorGreen
pri_default: int: 1
priorități
pri_id: UUID: UUID
pri_object: șir: object_project
pri_name: șir: hold
pri_color: culoare: colorBlue
pri_default: int: 0
priorități
pri_id: UUID: UUID
pri_object: șir: object_project
pri_name: șir: important
pri_color: culoare: colorRed
pri_default: int: 0
Structura fișierului este astfel: fac un apel de funcție Despică (":")în raport cu o linie și dacă înțeleg că dimensiunea acesteia este 1, atunci acesta este numele tabelului în care ar trebui să fie scrise datele. În caz contrar, sunt datele în sine. Primul câmp este numele câmpului din tabel. Al doilea câmp este tipul prin care determin ce trebuie să scriu chiar în acest domeniu. Dacă este un UUID, înseamnă că trebuie să generez o valoare UUID unică. Dacă șirul înseamnă că trebuie să scot valoarea șirului din resurse. Dacă este culoare, atunci din nou, trebuie să extrageți codul de culoare din resurse. Dacă int sau text, atunci doar convertesc valoarea dată în int sau String fără niciun gest. Codul în sine arată astfel:
Private ArrayList
30.04.2009 Alexey Kovyazin
Bazele de date relaționale au pătruns aproape în toate sistemele informaționale și, s-ar părea, au devenit cea mai consacrată zonă a IT, unde se poate inventa puțin, dar realitatea este departe de a fi ideală.
Bazele de date relaționale sunt folosite astăzi în aproape toate aplicațiile, de la încorporate în dispozitive mobile și speciale, aplicații bazate pe web și terminând cu sistemele de management al întreprinderii. Pătrunderea bazelor de date în tot felul de aplicații este în creștere, iar dezvoltatorii primesc instrumente și abordări din ce în ce mai ușor de utilizat. S-ar putea avea impresia că dezvoltatorii de aplicații de baze de date sunt cel mai „înstărit” strat de programatori care au instrumente pentru toate ocaziile, dar acest lucru este departe de a fi cazul. Embarcadero Technologies, prin achiziționarea diviziei de instrumente de dezvoltare CodeGear a Borland în 2008, a combinat instrumentele profesionale de dezvoltare și proiectare a aplicațiilor, instrumente de dezvoltare și de gestionare a bazelor de date pentru a aborda atât problemele aplicațiilor, cât și ale bazelor de date.
Design haotic de baze de date
În industria modernă de dezvoltare de software, este o credință comună că este imposibil să definiți cerințele de produs înainte de a începe un proiect și, prin urmare, dezvoltarea trebuie adaptată la schimbarea lor constantă. Ca rezultat, au apărut procese iterative pentru a se adapta cerințelor în schimbare, iar refactorizarea codului sursă a devenit o parte integrantă a dezvoltării software. Ce se întâmplă cu bazele de date în timpul dezvoltării iterative? Schimbarea cerințelor vă obligă să ajustați schema bazei de date și cel mai adesea acest lucru se întâmplă într-o manieră opacă, fără a analiza imaginea generală și dependențele. Tabelele, câmpurile, cheile externe și constrângerile sunt create și modificate haotic, nimeni nu monitorizează integritatea referențială și nimeni nu poate spune cu siguranță cum diferă baza de date la iterația N de starea ei la iterația N-1.
De fapt, dezvoltarea bazelor de date astăzi se realizează prin metoda „patch”, ca în zilele dominației procesului „cascada” - la începutul proiectului, un anumit model al bazei de date este „desenat” bazat pe pe cerințele parțiale cunoscute la momentul actual, apoi se generează o bază de date fizică, iar apoi se uită despre model prin efectuarea de modificări direct în baza de date. Dezavantajele acestei abordări sunt evidente: schimbul de cunoștințe și înțelegerea imaginii de ansamblu sunt dificile, iar schimbările sunt opace, pot genera contradicții în logica și schema bazei de date, care vor rămâne nedezvăluite până în momentul punerii sistemului software. în exploatare, ceea ce duce la pierderi foarte mari. Dezvoltatorii moderni de aplicații de baze de date au nevoie de instrumente care sunt orientate spre dezvoltarea iterativă a bazelor de date.
Prima și cea mai importantă condiție pentru o astfel de adaptabilitate este prezența oportunităților cu drepturi depline Inginerie inversă(inginerie inversă, crearea unui model de bază de date pe baza analizei schemei sale fizice) și inginerie directă(inginerie avansată; crearea și modificarea schemei bazei de date fizice pe baza modelului). În practică, aceasta înseamnă că, folosind un instrument de proiectare, puteți analiza schema unei baze de date existente, puteți crea un model de bază de date bazat pe acesta, puteți schimba modelul și puteți aplica imediat modificări care ar trebui să schimbe într-adevăr corect și consecvent schema bazei de date și să nu strice. sau confunda-l.
Abordarea iterativă ne împinge, de asemenea, să creăm submodele asociate cu o anumită iterație. Evidențierea oricăror entități și atribute ale acestora într-un submodel ajută la separarea zonelor de responsabilitate atât între diferiți dezvoltatori, cât și între diferite iterații, asigurând în același timp integritatea generală a modelului. Desigur, aveți nevoie și de capacitatea de a compara cele două modele, și nu sub formă de scripturi SQL, ci la nivel de entitate și atribut, pentru a vedea și înțelege pe deplin modificările efectuate în timpul iterației și impactul lor asupra întregului model.
Dezvoltatorii de aplicații rareori lucrează singuri, așa că au nevoie de instrumente de colaborare, dar dacă acest lucru este în regulă în ceea ce privește dezvoltarea aplicației, colaborarea cu bazele de date nu este de obicei acceptată la nivel de instrumente în niciun fel. Colaborarea implică în mod necesar un sistem de control al versiunilor: toate versiunile modelelor și schema bazei de date fizice trebuie să fie stocate într-un singur depozit, oferind posibilitatea de a derula înapoi și de a compara scheme încă de la începutul procesului de dezvoltare.
Dezvoltarea bazei de date nu este mai puțin importantă decât dezvoltarea aplicațiilor, prin urmare, direcția strategică de dezvoltare este de a oferi procesului de dezvoltare a bazei de date controlul versiunilor și managementul cerințelor, precum și legarea explicită a etapelor de modelare și modificare a bazelor de date cu iterațiile și cerințele în schimbare ale unui proiect software. Pentru a rezolva problemele de mai sus și pentru a sprijini procesul iterativ modern de dezvoltare a bazei de date, Embarcadero oferă ER / Studio - un instrument de proiectare, analiză, inginerie inversă și directă care vă permite să controlați versiunile modelului pe baza propriului său depozit. Instrumentul Change Manager poate fi folosit pentru a controla modificările metadatelor din bazele de date fizice.
Cod dezagregat
Cea mai cunoscută problemă care încetinește foarte mult procesul de dezvoltare a aplicațiilor de bază de date este necesitatea de a folosi diferite instrumente pentru a depana codul aplicației și codul SQL din baza de date.
Să aruncăm o privire la un exemplu simplu. Să presupunem că dezvoltați o aplicație în Delphi care apelează o procedură stocată într-un SGBD Oracle. Folosind instrumentele Delphi, dezvoltatorul aplicației poate pas cu pas în modul depanare până în momentul apelării interogării SQL, să vadă parametrii trecuți procedurii stocate și rezultatul pe care procedura îl va returna. Dar ce se întâmplă în interiorul procedurii când este executată pe serverul bazei de date? Este imposibil să determinați acest lucru din mediul de dezvoltare al aplicației noastre - pentru aceasta trebuie să descărcați o aplicație pentru dezvoltarea SQL, care are capacitatea de a depana procedurile stocate și, de asemenea, arată planuri pentru interogări SQL, statistici ale execuției lor, vă permite pentru a vizualiza și modifica schema bazei de date. Cu toate acestea, nu puteți trece parametri din mediul de dezvoltare a aplicației în mediul de dezvoltare SQL și trebuie să îi copiați manual, trecând de la o fereastră la alta. De asemenea, nu este posibil să vedeți rezultatele detaliate ale execuției codului SQL în Application Builder, cum ar fi planul de interogare, statisticile de execuție și așa mai departe. Apariția tehnologiei de depanare în mai multe limbi a rezolvat aceste probleme.
Primul produs Embarcadero care acceptă depanarea în mai multe limbi este RapidSQL Developer (fost PowerSQL), a cărui parte vizuală se bazează pe tehnologia Eclipse și, prin urmare, vă permite să vă integrați în orice mediu de dezvoltare bazat pe aceasta (inclusiv, desigur, JBuilder) și depanare dinamică între limbi. Acum, când procedura stocată este executată pe server, dezvoltatorul trece automat la un mediu de depanare SQL cu drepturi depline în cadrul aceluiași instrument, capabil să depaneze atât interogările SQL obișnuite, cât și procedurile stocate. Dezvoltatorul poate vedea parametrii de intrare efectivi ai interogărilor și procedurilor stocate, având posibilitatea de a depana pas cu pas codul SQL. Integrarea RapidSQL Developer în instrumentele de dezvoltare compatibile cu Eclipse este primul pas în integrarea dezvoltării de aplicații și baze de date, iar următorul pas este furnizarea de capabilități similare pentru Delphi, C ++ Builder și alte instrumente de dezvoltare de aplicații de la Embarcadero.
Aplicații de baze de date multiplatforme
O provocare specială pentru dezvoltatori este dezvoltarea de aplicații de baze de date care trebuie să funcționeze cu mai multe SGBD. De exemplu, băncile și companiile de asigurări au de obicei mai multe birouri mari și multe sucursale mici. Majoritatea proceselor de afaceri legate de introducerea informațiilor operaționale și fluxul de lucru de zi cu zi sunt aceleași la sediul central și la sucursale, dar baremurile sunt diferite. Dorința firească de a economisi pe costul licențelor SGBD industriale pentru utilizare în sucursale duce la ideea că ar fi bine să alegeți un alt SGBD fără a schimba aplicația.
Dezvoltatorii de baze de date cu experiență înțeleg bine esența problemelor care apar aici: diferența dintre tipurile de date și dialectele SQL, absența mecanismelor de migrare și replicare între diferitele SGBD, complexitatea verificării migrării fac ca scrierea și operarea aplicațiilor pentru diferite SGBD să fie un coșmar. Din partea instrumentelor de dezvoltare a aplicațiilor, aceștia încearcă să rezolve această problemă prin crearea de biblioteci de acces la date (dbExpress în Delphi și C ++ Builder, ADO și ADO.Net de la Microsoft), construite pe principii arhitecturale unificate și metode de acces, precum și ca prin utilizarea a numeroase „Wrappers” obiect-relaționale (Object Relation Mapping, ORM) peste logica relațională și structura bazei de date, generând cod sursă pentru lucrul cu date pe baza analizei schemei bazei de date și folosind mecanismul „adaptoarelor”. " pentru a implementa protocolul unui anumit SGBD. Printre cele mai populare ORM-uri se numără Hibernate pentru Java și ActiveRecord în RubyOnRails, care oferă o interfață orientată pe obiecte pentru datele stocate în DBMS. Pentru Delphi există un proiect similar tiOPF, pentru C # - NHibernate.
Desigur, utilizarea unor astfel de biblioteci universale și seturi de componente poate reduce semnificativ numărul de operațiuni de rutină în procesul de dezvoltare a bazei de date multi-platformă. Cu toate acestea, acest lucru nu este suficient atunci când vine vorba de aplicații care utilizează baze de date mai complexe, în care logica inerentă procedurilor stocate și declanșatorilor este utilizată în mod activ - pentru implementarea, depanarea și testarea acesteia sunt necesare instrumente separate, uneori complet diferite pentru diferite SGBD-uri. . Pentru dezvoltarea aplicațiilor de baze de date multiplatforme, Embarcadero oferă instrumentul RapidSQL.
Toate produsele de bază de date Embarcadero acceptă mai multe platforme și se bazează pe analiza schemei și motorul de statistici a bazei de date Thunderbolt. Fiecare SGBD acceptat și fiecare versiune specifică a SGBD au ramuri corespunzătoare de cod în nucleul Thunderbolt, ceea ce vă permite să mapați schema bazei de date la reprezentarea internă din acest nucleu cât mai precis posibil și, cel mai important, să efectuați conversii corecte între reprezentare. și baze de date reale. Datorită nucleului Thunderbolt, RapidSQL vă permite să dezvoltați cod SQL de înaltă calitate pentru toate platformele acceptate (Oracle, MS SQL, Sybase și diverse variante ale IBM DB2), iar ER / Studio poate efectua o inginerie inversă și directă precisă a bazei de date. scheme.
Dacă dezvoltați o aplicație pentru două sau mai multe platforme sau migrați o aplicație existentă de la o platformă la alta, RapidSQL vă va oferi toate instrumentele necesare pentru migrarea schemei, utilizatorilor și permisiunilor între diferite SGBD. Desigur, RapidSQL nu convertește automat procedurile PL / SQL în T-SQL - acest lucru necesită încă un programator - cu toate acestea, instrumentul oferă o singură fereastră pentru dezvoltarea multi-platformă, editori unificați pentru obiecte de schemă, utilizatori și drepturile acestora și SQL depanare pe toate platformele acceptate... Potrivit utilizatorilor RapidSQL, acest lucru economisește până la 70% din timpul petrecut migrând între diferite SGBD.
Modificări ale datelor și diagramelor
Migrarea de la un SGBD la altul este imposibilă fără verificarea acestuia. Cine și cum poate garanta că datele transferate de la un SGBD la altul sunt cu adevărat identice? Diferite biblioteci client, diferite tipuri de date și diferite codificări fac din procesul de comparare a datelor o sarcină netrivială.
În lumea reală, munca nu se termină cu implementarea aplicației și a bazei de date - există întreținere, apar noi versiuni ale fișierelor executabile ale aplicației și patch-uri la baza de date. Cum puteți obține garanții că toate actualizările necesare au fost aplicate bazei de date și că întregul pachet software va funcționa corect?
Embarcadero a dezvoltat instrumentul Change Manager pentru compararea datelor, schemelor și configurațiilor bazei de date. Comparația are loc în cadrul unuia sau mai multor SGBD, cu verificarea automată a corespondenței dintre tipurile de date și formarea de scripturi SQL de diferențe, care pot fi aplicate imediat pentru a aduce bazele de date într-o stare identică. Modulul de comparare a metadatelor oferă compararea schemelor bazelor de date atât între bazele de date live, cât și între baza de date și scriptul SQL și generează un script pentru diferențele de metadate. Această funcționalitate poate fi folosită nu numai pentru a verifica bazele de date pentru conformitatea cu benchmark-ul, ci și pentru a organiza un proces regulat de actualizare a bazei de date, precum și pentru a verifica modificări neautorizate, de exemplu, în sucursalele îndepărtate ale unei organizații mari. Situația este similară cu fișierele de configurare - Change Manager compară fișierele de configurare și vă permite să vă asigurați că configurația aplicațiilor implementate îndeplinește cerințele pentru acest software.
Performanța aplicației baze de date
Cât de des vedem aplicații care funcționează bine pe volume mici de date de testare, dar devin inacceptabil de lente pe volume reale. Calculele greșite ale cerințelor, testarea inadecvată în etapele incipiente, graba de a livra un proiect sunt toate motive familiare pentru dezvoltarea slabă a aplicației. În acest caz, teoreticienii dezvoltării software își propun să se angajeze în auto-îmbunătățirea și îmbunătățirea fundamentală a calității programelor, totuși, toți practicienii știu că rescrierea unui proiect este uneori imposibilă, fie din punct de vedere economic, fie, în unele cazuri, politic, iar sarcina de a optimiza. performanța trebuie rezolvată în orice mod.
Principala cauză a problemelor de performanță în aplicațiile de baze de date constă în interogările SQL neoptimizate și procedurile stocate. Optimizatoarele moderne de baze de date sunt suficient de puternice, cu toate acestea, au și anumite limite ale capacităților lor și, pentru a obține o performanță bună, trebuie să compuneți corect interogări SQL, să creați (sau să renunțați) indecși suplimentari, în anumite cazuri să denormalizați baza de date, să transferați unele dintre logica declanșatoarelor și procedurilor stocate.
La momentul proiectării, optimizarea interogărilor poate fi efectuată folosind RapidSQL, care include un modul SQL Profiler care poate analiza planuri și genera indicii pentru a îmbunătăți performanța interogărilor SQL. Dar ce se întâmplă dacă problema apare în timpul producției și nu este localizată într-o anumită interogare SQL? Dacă performanța scade la un anumit moment al zilei sau, și mai enervant, problema apare pe o copie de la distanță a sistemului, în timp ce totul este în regulă pe serverul principal? Aici este proiectat DBOptimizer, un instrument de profilare a bazei de date pentru Oracle, Microsoft SQL Server, Sybase și IBM DB2.
Când modul de profilare este pornit, DBOptimizer colectează informații despre baza de date și despre timpul de execuție, inclusiv informații despre încărcarea procesorului și alți parametri ai sistemului de operare, scriindu-le în sesiunea de profilare. Rezultatul este o listă de interogări executate la orice interval de timp dat, sortate după resursele consumate. Pentru fiecare cerere problematică, puteți vedea planul acesteia, statisticile de execuție și alte detalii. Mai mult, DBOptimizer afișează, de asemenea, sugestii și recomandări pentru îmbunătățirea interogării în raport cu un anumit DBMS.
Trusa de scule
Toate instrumentele menționate, în timp ce rezolvă probleme, sunt utilizate în diferite etape ale ciclului de viață al dezvoltării bazei de date. Este destul de incomod și costisitor să păstrezi o duzină de aplicații pentru toate ocaziile care pot fi sau nu necesare în timpul proiectării, dezvoltării, migrării, optimizării și exploatării bazelor de date.
Lansat în februarie 2009, setul de instrumente versatil Emdacadero All-Access include instrumentele esențiale pentru toate etapele dezvoltării aplicațiilor de baze de date, de la ER / Studio la DBOptimizer, de la Delphi și C ++ Builder la DBArtisan. Cel mai bun mod de a descrie All-Access este comparația cu cutia de instrumente pe care fiecare proprietar zelos o are acasă. Poate că nu toate uneltele sunt folosite în fiecare zi, dar o cheie reglabilă ar trebui să fie întotdeauna la îndemână în cazul unei scurgeri.
All-Access nu impune alte roluri programatorilor sau arhitecților de baze de date, dar oferă un set de instrumente universal potrivit pentru toate rolurile din procesul de dezvoltare a aplicației de baze de date, de la arhitect la tester; oferă tuturor membrilor echipei de dezvoltare instrumente pentru toate etapele dezvoltării bazei de date, precum și un set de instrumente foarte specializate pentru optimizarea bazelor de date (DBOptimizer) și a aplicațiilor (JOptimizer) pentru a „extinde” blocajele. Pachetul acceptă mai multe SGBD, ceea ce oferă economii de costuri.
Diferențele tehnice dintre tehnologiile de baze de date orientate pe obiect și relaționale au dus la diferențe culturale care separă în continuare comunitatea de gestionare a datelor de comunitatea de dezvoltare. Ce să faci mai departe cu asta?
Delphi este un mediu de dezvoltare care folosește limbajul de programare Delphi (începând cu versiunea 7, limbajul din mediu se numește Delphi, mai devreme - Object Pascal), dezvoltat de Borland și implementat inițial în pachetul său Borland Delphi, de la care a primit actualul său mediu. numele in 2003... Obiectul Pascal, de fapt, este moștenitorul limbajului Pascal cu extensii orientate pe obiecte.
Delphi este instrumentul suprem pentru construirea de aplicații de baze de date. Optimal, pentru că acceptă tehnologia de dezvoltare vizuală, care poate reduce semnificativ timpul de dezvoltare, menținând în același timp calitatea și fiabilitatea produsului software. Delphi în structura limbii vă permite să evitați erorile ascunse.
Caracteristici ale familiei Delphi 7:
* Un mediu de dezvoltare rapidă a aplicațiilor care integrează instrumente de modelare pentru dezvoltarea și implementarea aplicațiilor de comerț electronic și a serviciilor Web.
* Suport pentru limbaje de programare pentru Win32 (Delphi și C/C++) și pentru .NET (Delphi și C#) într-un singur mediu de dezvoltare, ceea ce facilitează întreținerea și crearea de noi aplicații Win32 și stăpânește mai ușor. tehnologii NET;
* Capacitatea atât pentru dezvoltatorii de aplicații tradiționale Windows, cât și pentru dezvoltatorii care folosesc Java de a dezvolta aplicații .NET fără a abandona instrumentele utilizate, păstrând în același timp abilitățile și cu concepte de programare similare;
* Noul sistem de șabloane de cod și alte inovații în mediul de dezvoltare îmbunătățesc calitativ munca cu codurile sursă și cresc productivitatea dezvoltării;
Microsoft SQL Server 2000 este o bază de date completă și o ofertă de analiză a datelor pentru construirea rapidă de soluții scalabile de comerț electronic, aplicații de afaceri și depozite de date.
Poate reduce semnificativ timpul de lansare pe piață pentru aceste soluții, oferind în același timp scalabilitate pentru a satisface cele mai exigente cerințe.
Pachetul Delphi este o continuare a liniei Borland de compilatoare Pascal. Ca limbaj, Pascal este foarte simplu, iar verificarea puternică a tipurilor de date facilitează detectarea timpurie a erorilor și vă permite să creați rapid programe fiabile și eficiente.
Dezvoltarea aplicației baze de date este una dintre cele mai solicitate caracteristici ale mediului de programare Delphi. Puterea și flexibilitatea bazei de date Delphi se bazează pe un nucleu de nivel scăzut, Borland Database Engine (BDE). Interfața sa cu aplicațiile se numește Interfața de programare a aplicațiilor pentru baze de date integrate (IDAPI). BDE permite accesul la date folosind atât abordarea tradițională orientată spre înregistrare (navigație), cât și abordarea orientată spre set utilizată în serverele de baze de date SQL.
Biblioteca de obiecte conține un set de componente vizuale care simplifică foarte mult dezvoltarea aplicațiilor pentru DBMS cu arhitectură client-server. Obiectele încapsulează stratul inferior, motorul de bază de date Borland.
Există seturi speciale de componente responsabile pentru accesarea datelor și componente care afișează date. Componentele de acces la date permit realizarea de conexiuni la baza de date, efectuarea de selecții, copierea datelor etc.
Componentele de vizualizare a datelor vă permit să afișați date sub formă de tabele, câmpuri, liste. Datele afișate pot fi în text, grafic sau orice format.
Tabelele sunt stocate în baza de date. Unele SGBD-uri stochează baza de date ca mai multe fișiere separate care sunt tabele (în principiu toate SGBD-urile locale), în timp ce altele constau dintr-un singur fișier care conține toate tabelele și indecșii (InterBase).
Obiectele bazei de date din Delphi sunt bazate pe SQL și încorporează întreaga putere a motorului de baze de date Borland. Delphi include și Borland SQL Link, astfel încât accesul la Oracle, Sybase, Informix și InterBase DBMS este foarte eficient. În plus, Delphi include un server Interbase local, astfel încât să puteți dezvolta aplicații extensibile offline pe orice server SQL extern.
Scalabilitate în practică - aceeași aplicație poate fi utilizată atât pentru opțiunile de client/server locale, cât și pentru cele mai serioase.
Deși Delphi nu are propriul format de tabel de bază de date, oferă totuși suport puternic pentru un număr mare de SGBD-uri diferite - atât locale (de exemplu, dBase sau Paradox), cât și industriale (de exemplu, Sybase sau InterBase).
