Revista si suplimente
MarketWatch
Inapoi Inainte

Baze de date

19 Martie 2024



Colecții organizate de date alfa-numerice, bazele de date constituie un domeniu predilect al tehnologiei informatice. Mai mult, încă din copilăria domeniului, ele au fost motivație și motor pentru dezvoltare hardware și software. Iar astăzi, deși suntem în trendul global de recesiune din sfera software-ului comercial, avem aplicări ale lor atât în small-business (IMM) cât și în entreprise (organizații mari), ba chiar și în aplicații globale (servicii www/internet).

Începând cu anii 1960 s-au studiat diverse modalități de organizare a datelor numerice și textuale, vizându-se colectarea și exploatarea informațiilor economice în cadrul organizațiilor (dar găsindu-se curând și alte aplicări semnificative, precum statistica, enciclopediile, evidența populației, agenții guvernamentale, ș.a.). În perioada de apogeu a calculatoarelor mainframe a fost definit și aplicat modelul relațional al bazelor de date (E.F. Codd, 1970, IBM), model robust, asigurând consistența datelor prin considerarea implictă a legăturilor dintre atomii informaționali (similar conceptului de tuplu din matematică); model care mai rezistă și astăzi (deși în ultimele decenii și-au dovedit avantajele și alte arhitecturi de organizare, precum modelul obiectual, inspirat de OOP). Pe atunci s-a omologat și acronimul DBMS (database management system), respectiv, în limba română, SGBD(R) – sistem de gestionare a bazelor de date (relaționale).
Când ne gândim la baze de date, ne putem foarte bine imagina informațiile organizate tabelar (în rânduri și coloane), deși aranjarea internă a datelor alfa-numerice în fișierele bazei de date nu reflectă neapărat formatul tabelar (ba chiar constituie, prin diverse artificii de aranjare, direcție de optimizare internă a bazei de date, pentru creșterea vitezei de operare, respectiv constituind atu pentru diferențierea pe piață a furnizorilor). Și este bine să ni le imaginăm ca fiind tabele, pentru că astfel înțelegem esența modelului relațional: fiecare rând de tabel constituie un set de date referitoare la (sau descriind) o entitate, iar pe coloane avem atributele acelei entități (entitatea fiind obiectul vizat de respectiva colectare/procesare informatică: lucru, ființă, fenomen, activitate, operație, etc). (Eventual facem mental legătura între rândul de tabel și conceptele de set și de înregistrare/record din jargonul limbajelor de programare.)



Exemplificări didactice
Să ne imaginăm nucleul unui scenariu de informatizare în domeniul comercial: vânzarea unui produs dintr-un magazin/depozit. În baza de date se vor înregistra denumirea produsului, codul lui de identificare, prețul, cantitatea, data, ora, casierul, iar acestea vor constitui un rând în tabelul nostru ipotetic, un rând ale cărui date sunt legate între ele implicit, pentru că ele descriu o entitate (operațiunea de vânzare). Ulterior, la sfârșit de zi sau de lună, din baza de date vom afla: ce și cât s-a vândut, ce valoare au încasările, ce produse trebuie procurate pentru reaprovizionare. (Dar, la alt nivel/sector, se poate afla și ce oră din zi este mai favorabilă, sau ce vânzator a fost mai productiv. Eventual prefigurând aplicările de tip data-mining.)
Desigur, când gestionăm finanțele personale sau ale familiei, un tabel realizat într-o aplicație precum Microsoft Excel ne este suficient. (Vedeți eventual articolul meu din revista Market Watch nr. 257/2023.) Și astfel ajungem la cheia de înțelegere a diferenței dintre aplicațiile de tip database și cele de tip spreadsheet: cantitatea înregistrărilor și complexitatea/implicațiile acestora (după cum vom vedea mai departe).
Al doilea mare avantaj al modelului relațional (pe lângă cel al legăturilor implicite) constă în posibilitatea de a defini legături logico-funcționale între două sau mai multe tabele ale bazei de date, aceasta realizându-se prin considerarea/desemnarea câte unei coloane ca fiind depozitară de chei comune.
Revenind la exemplul anterior (cel comercial, subsumat adesea acronimului ERP – Enterprise Resource Planning), vom ajunge de fapt la două tabele: unul înregistrând operațiunile efective de vânzare (un rând înseamnă o vânzare de articol) și altul pentru gestiunea univocă a articolelor din depozit (urmărind stocurile acelor articole); și fiecare tabel conține o coloană (identificatorul articolului) ale cărei valori relaționează logic operațiile (vânzarea unui produs va determina scăderea stocului său), iar această relație este favorizată prin mecanismele bazei de date și respectiv prin interogările interne de tip SQL, interogări de genul SELECT (coloane) FROM (tabel_1), (tabel_2) WHERE (coloană_1_tabel_1) = (coloană_1_tabel_2); sau SELECT (coloane) FROM (tabel_1) JOIN (coloana_cheie) ON (cheie_tabel_1) = (cheie_tabel_2);.
Ba probabil că în dezvoltarea aplicației reale vor mai apărea niște tabele: unul pentru evidența furnizorilor de produse (dacă le datorăm bani); unul pentru evidența beneficiarilor/clienților (dacă ne datorează bani); unul pentru conturile specifice operațiunilor financiar-contabile (în care se vor reflecta operațiunile organizației); ș.a..



Evoluție și diversificări
În urmă cu o jumătate de secol informatica era un domeniu foarte ambițios. (Nici nu putea fi altfel, fiind vorba atât de eforturi/investiții substanțiale, cât și de un sector foarte intelectual.) Informatizările vizau organizații mari (companii, întreprinderi, administrații, instituții), astfel că primele baze de date (fie ele experimentale/proprietare sau comerciale) erau mari și complexe. Însă răspândirea micro-calculatoarelor personale avea să influențeze (democratizând) și acest subdomeniu: au apărut în mod firesc aplicații software preluând (și chiar emulând) cenceptele deja consacrate ale DBMS. Iar când PC-urile s-au dezvoltat suficient de mult (ca performanțe hardware și ca abilități ale sistemului de operare, inclusiv în multi-tasking) au apărut chiar și SGBD-uri de tip client-server (ceea ce însemna că arhitectura mainframe putea ceda locul PC-ului devenit calculator server). Avem deci o primă departajare în evoluția DBMS (o scindare atât tehnologică cât și comercială, de piață): (1) bazele de date desktop (pentru aplicări mici și medii) și respectiv (2) bazele de date client-server (pentru aplicări mari). Și iată că revine cumva în antenție criteriul cantitativ, despre care spuneam mai devreme prin comparația între spreadsheet și database. Și dacă tot am revenit la acea comparație, voi sublinia aici o altă diferență esențială între aplicațiile/sistemele de baze de date și aplicațiile de calcul tabelar: în timp ce spreadsheet-ul înglobează inteligența (logica de procesare a datelor) chiar în tabel (angajând, în celulele tabelului, formule, funcții și operatori logico/matematici), baza de date este doar depozitarul datelor, iar logica de procesare se realizează mai degrabă prin aplicații exterioare. Da, SGBD-ul oferă mecanisme pentru manevrarea datelor și pentru diverse interogări, însă acestea nu sunt lesne accesibile utilizatorului, așa încât – pentru aplicările profesionale – de cele mai multe ori SGBD-ul devine (doar) nucelul unei aplicații software cu funcții și interfețe foarte adaptate la cerințele beneficiarului.
Încercăm acum să explicăm succint diferența „arhitecturală” dintre bazele de date desktop și cele client-server. SGBD-ul desktop este un pachet software care, odată instalat pe PC, acumulează local toate funcțiile necesare utilizării: stocare, administrare și exploatare. De partea cealaltă, arhitectura client-server presupune că logistica necesară stocării și gestionării datelor rezidă pe un calculator de tip server (SGBD-ul fiind un software de tip server), iar exploatarea de către utilizatorul final se realizează de pe calculatoare personale, legătura dintre cele două nivele realizându-se prin protocoale interne de tip cerere-răspuns (aplicația client cere o informație sau solicită să înregistreze/modifice un set de date, iar serverul răspunde returnând informația cerută sau confirmând realizarea acelei editări de date). Însă cu mențiunea că există o legătură fizică (cablată sau prin unde radio) între client și server, și anume prin rețeaua locală de calculatoare (LAN).
Nominalizăm alfabetic o serie de software-uri desktop: Access, Approach, Clipper, dBASE, FileMaker, FoxPro, Paradox, OpenOffice Base etc. Iar printre cele mai cunoscute servere de baze de date regăsim: Adabas, DB2, Informix, Ingres, InterBase, MySQL, MongoDB, Oracle, Progress, PostgreSQL, SQL Server, Sybase, TeraData ș.a..
În evoluția și diversificarea acestui subdomeniu IT merită menționată și apariția SGBD-urilor capabile să gestioneze și informații non-alfanumerice: informații geo-spațiale (vectoriale), informații bitmap/rasteriale, înregistrări multimedia, alte tipuri de obiecte. Un bun exemplu ar fi aici Oracle Spatial, pentru aplicări în subdomeniul GIS (sisteme geo-informatice).
Și închei articolul cu prezentarea succintă a următorului/ultimului nivel în evoluția/complexitatea DBMS: aplicații cu baze de date via internet. De fapt, dacă am reușit să înțelegem esența protocolului client-server descris mai sus, lucrurile ne devin simple: este vorba de aplicații/sisteme la care comunicația dintre serverele de baze de date și aplicațiile client se realizează prin conexiuni internet (aplicația client fiind de regulă broswer-ul de world-wide-web). Exemple?!... Toate magazinele de vânzări virtuale (e-commerce) folosesc acest soi... Toate sistemele e-mail. Nu scapă nici Google Search, și nici multe altele.



Parerea ta conteaza:

(0/5, 0 voturi)

Lasa un comentariu



trimite