Debutul unei cariere solistice sau o repetiție generală
pentru integrarea în Designer/2000?

Este un fapt incontestabil că marea majoritate a bazelor de date utilizate actualmente în lume se bazează pe modelul relațional, iar o bună parte dintre acestea utilizează diferite dialecte ale limbajului SQL. Prin însăși destinația lor, SGBD-urile din această categorie reprezintă adesea fundamentul multor sisteme informatice de mari dimensiuni, vitale pentru funcționarea organizațiilor respective. În aceste condiții, obținerea unui spor de productivitate în proiectare, creșterea nivelului de control în administrare și întreținere sau scurtarea timpului de instruire pot constitui sursa unor beneficii globale importante. Aceasta este explicația apariției unei pleiade de instrumente auxiliare destinate sistemelor de baze de date relaționale, unele provenind chiar de la producătorii de SGBD-uri (cum este cazul produsului prezentat în acest articol), altele de la terți producători.

Oracle Database Designer este, în esență, destinat evitării unui anumit subset al limbajului SQL, și anume DDL – Data Definition Language. În locul acestuia se utilizează o interfață mai intuitivă, bazată pe diagrame reprezentând principalele obiecte ale bazei de date (tabele, views și relații între ele) precum și pe formulare cuprinzând celelalte elemente implicate (domenii, atribute diverse, restricții, secvențe, etc.). Procesul este bidirecțional. Se poate porni de la descrierea sub formă de diagramă a structurilor de date, pe baza căreia se poate genera un script DDL, sau – dacă se operează on-line – se poate genera direct structura de date descrisă. Procedeul invers, numit reverse engineering (sau design recovery), pornește fie de la un script DDL fie de la informațiile echivalente extrase (on-line) din cataloagele sistem ale bazei de date și se concretizează într-o diagramă.

Avantajele se repercutează atât asupra procesului de proiectare a bazei de date, prin faptul că proiectanții nu utilizează direct limbajul SQL (mai precis unul sau altul dintre multele sale dialecte), cât și în procesul de întreținere a bazei de date, prin posibilitatea de a vizualiza și a modifica cu ușurință structurile de date. utilizate. Cu toate că, în mod firesc, produsul este orientat cu precădere spre SGBD-urile Oracle (Oracle7, Personal Oracle Lite și Rdb pentru generare, la care se adaugă Oracle6 pentru reverse engineering), oferă suport și pentru IBM DB2 și Microsoft SQLServer. Pentru alte baze de date SQL se poate folosi limbajul standard ANSI SQL 92. În plus, există suport pentru surse de date ODBC (Open Database Connectivity). Gama bogată de SGBD-uri suportate recomandă programul și pentru delicatele operații de portare a aplicațiilor între diferite sisteme relaționale.

Principalele componente funcționale ale lui Oracle Database Designer sunt Data Diagrammer, Generation Wizard și Reverse Engineering Wizard.

Data Diagrammer

Data Diagrammer este componenta care asigură reprezentarea structurii de date sub formă grafică precum și interacțiunea cu utilizatorul. O parte dintre funcțiile pe care le asigură se referă la controlul reprezentării grafice (amplasarea componentelor, culori, linii, fonturi, etc.) și sunt cele obișnuite în majoritatea programelor Windows. Mai importante sunt însă funcțiile de proiectare, asupra căruia voi insista în continuare.

O diagramă poate fi construit㠄de la zero“, pe baza unei analize realizate în prealabil de către proiectant, sau poate fi obținută dintr-o bază de date existentă. În ambele cazuri, proiectarea sau reproiectarea se realizează în continuare la fel.

Crearea unei tabele sau a unui view se realizează printr-un simplu drag-and-drop. Inițial însă aceasta nu are decât un nume implicit dat de sistem, așa că urmează definirea tuturor atributelor sale, începând cu numele, coloanele și terminând cu indecși asociați. O bună parte dintre elementele care descriu o tabelă sunt opționale, având fie rol de documentare (descrieri, note, observații, etc.), fie specificând detalii de implementare pentru SGBD-urile Oracle (tablespace, storage definition, etc), fie oferind informații utile generatoarelor de cod din Oracle Designer/2000. Toate acestea sunt reprezentate într-o casetă de dialog multiplă (tabbed):
• Tabul Table permite în principal specificarea elementelor de identificare a tabelei (nume, alias, nume afișat). Celelalte elemente sunt opționale și reprezintă detalii de implementare.
• Tabul Column Definition cuprinde definițiile coloanelor. Alături de atributele triviale (nume, tipul de dată sau eventual domeniul) există posibilitatea de a specifica pentru fiecare coloană obligativitatea introducerii unei valori (echivalentul clauzei NOT NULL), o valoare implicită, secvența (pentru generarea automată a cheilor), etc.
• Tabul Column Display cuprinde doar informații utile pentru generatoarele de cod din Designer/2000 (specificând elemente privind interfața aplicațiilor generate). Nici una dintre aceste nu are consecințe la generarea scriptului DDL.
• Tabul Constraints cuprinde restricții de integritate. Este la rândul lui subdivizat după cele patru tipuri de restricții posibile: Primary key (coloană sau grup de coloane servind la identificarea unică a fiecărei linii a unei tabele), Foreign key (coloană sau grup de coloane ale căror valori trebuie să se potrivească valorilor cheii primare a unei tabele referite), Unique key (alternative opționale ale cheii primare) și Check Constraints (reguli de validare pentru valorile unei coloane cu rol de cheie).
• Tabul Validation permite definirea de restricții suplimentare pentru valorile diferitelor coloane. Aceste reguli se referă de obicei la intervale sau liste de valori admisibile și permit definirea unor abrevieri pentru aceste valori.
• Tabul Index permite definirea de indecși pentru coloanele care se presupune că sunt cele mai solicitate în operațiile de regăsire a liniilor tabelei respective. De regulă se stabilesc indecși pentru cheile primare și, eventual, pentru cheile străine (din considerente legate de performanță).

Asemănătoare este și procedura de definire a unui view. Diferența este că se pot selecta tabele de bază și coloanele corespunzătoare. Desigur, nu se pot stabili indecși.

Pentru stabilirea relațiilor între tabele (fie ele de bază sau derivate) există două metode. Una este grafică (se „trage“ o cheie străină de la o tabelă la alta), iar cealaltă implică definirea completă a cheii străine în tabul Foreign Key Contraints al unei tabele. De fapt, prima variantă nu duce treaba până la capăt, așa că oricum implică precizarea în tabul amintit a detaliilor definiției.

Generation Wizard

Odată ce o diagramă a fost finalizată, se poate trece la utilizarea ei. Deși există posibilitatea de a genera on-line structura de date, procedeul îmi pare destul de periculos, având în vedere că editorul de diagrame nu dispune de un mecanism de verificare semantică. Varianta mai cuminte ar fi generarea unui script SQL, care poate fi rulat apoi de SGBD și care, în plus, nu poate să lipsească din documentație.

Procesul de generare este extrem de simplu, fiind condus pas cu pas de un „vrăjitor“ gen Microsoft. În cazul în care se generează un script, se cere să se precizeze numele fișierului care va fi creat și SGBD-ul țintă. Generarea directă în cataloagele bazei de date este posibilă doar pentru baze de date Oracle7 (conectarea se face prin SQL*Net) sau ODBC (caz în care trebuie să existe conexiunea la sursa de date). Pasul următor este mai pasionant, deoarece trebuie să precizăm care anume tipuri de obiecte dorim să fie generate (avem din fericire șansa să le alegem pe toate dintr-un singur clic). Apoi suntem invitați să alegem obiectele propriu-zise care dorim să fie selectate (se poate selecta fiecare tabelă, view sau index). În fine, se generează scriptul dorit (un fișier ASCII cu extensia .sql).

Generarea directă a structurii pune o problemă suplimentară: ce se întâmplă în situația în care există deja în baza de date un obiect având numele și tipul unuia care urmează a fi generat? Există o opțiune Alter care dacă este selectată determină generatorul să păstreze obiectul respectiv și doar să-l modifice pentru a corespunde specificațiilor din diagramă. În practică aceasta se reduce de obicei la adăugarea unor coloane la o tabelă existentă.

Reverse Engineering Wizard

Procesul invers generării constă din construirea automată a unei diagrame dintr-o bază de date on-line sau dintr-un script DDL existent. Procedeul este util fie pentru reproiectarea structurii de date, fie pentru migrarea unei baze de date și a aplicațiilor care o exploatează spre un alt SGBD.

Procedeul este simetric celui de generare, fiind la fel de simplu. În cazul în care se accesează on-line cataloagele bazei de date, atunci există posibilitatea de a selecta tipurile de obiecte care dorim să apară în diagramă. Dacă se pornește de la un script atunci toate tipurile de obiecte vor apare în diagramă (desigur, dacă Database Designer le recunoaște).

La treabă

Micul exercițiu pe care vi-l propun poate fi mai edificator decât o prezentare oricât de amplă. Tema ar fi o bază de date de personal, cuprinzând o tabelă cu angajați (ANGAJAT) și o tabelă cu departamente (DEPT), ambele minimale. Relațiile pe care le propun ar fi una prin care fiecare angajat este asociat unui departament (lucrează-la) și una prin care departamentele sunt asociate unui angajat care este șeful respectivului departament.

O bună obișnuință este să creăm în prealabil niște domenii pentru datele de aceeași factură care vor apărea în diferite coloane. Deoarece Database Designer oferă această posibilitate, am creat domeniile ID (numeric, pentru chei unice), NUME (alfanumeric, pentru denumiri) și SAL (pentru salarii, cu restricția că trebuie să se încadreze în intervalul 200.000 - 10.000.000). Am definit de asemenea o secvență ID_ORD (un obiect specific Oracle care se asociază unor coloane pentru care SGBD-ul generează automat valori unice).

Definirea tabelelor a mers fără probleme. Secvența nu a putut fi legată de domeniul ID, cum aș fi dorit, ci a trebuit să o precizez în mod explicit pentru coloanele MARCA și COD_DEPT.

Pentru definirea relațiilor am procedat atât prin drag-and-drop (caz în care a fost adăugată automat o cheie străină în tabela many) cât și prin definirea explicită a unei coloane ca fiind cheie străină). Pentru relația lucrează_la am definit și o regulă de integritate referențială: actualizare în cascadă (adică: dacă se schimbă codul unui departament, schimbarea se va reflecta în valorile coloanei DEPT pentru angajații care lucrează în acel departament). Aș dori desigur ca această regulă să fie verificată la nivelul serverului (există posibilitatea de a alege între server și client).

Un exercițiu util ar fi crearea unei vederi care să se bazeze pe tabele anterior create. De exemplu o imagine asupra departamentelor care să cuprindă și numele șefului (VIEW_DEP). Lucrurile sunt simple pentru vederile formate dintr-un subset al coloanelor unei tabele, dar pentru vederi ceva mai consistente, fraza SELECT trebuie scrisă explicit (cum este și cazul acestei vederi).

Am generat un script pentru Oracle7 și un script pentru ANSI SQL. Câteva surprize s-au arătat: domeniile nu au fost generate în nici unul dintre cazuri (cu toate că CREATE/ALTER/DROP DOMAIN face parte din standard) ci s-a distribuit definiția domeniului în fraza CREATE TABLE. Condiția însă nu a fost distribuită, astfel încât pentru a forța o validare a valorilor coloanei SAL a trebuit să reproduc restricția la nivelul coloanei (în Validation).

Nici regula de integritate referențială nu a fost generată, deși clauza ON UPDATE CASCADE face parte atât din standardul ANSI cât și din dialectul utilizat de Oracle.

Comentariile și notele pe care le-am atașat diferitelor obiecte au fost doar în parte transpuse în scriptul pentru Oracle7 (prin COMMENT ON), dar nu s-au regăsit deloc în scriptul ANSI.

Operațiile inverse, de reverse engineering pe scripturile generate au condus la rezultatele scontate. Dar... clauza WHERE din definiția vederii VIEW_DEP a fost ignorată (deși a fost corect generată). În schimb clauza ON DELETE CASCADE pe care am adăugat-o manual în corpul frazei ALTER TABLE prin care se adăuga cheia străină în tabela ANGAJAT, a fost corect reprodusă în diagramă.

Utilizarea produsului a dat la iveală și unele scame sau necorelări. Controlul vizual al obiectelor este destul de grosier (de pildă, selectarea coloanelor unui view dintre coloanele tabelelor de bază se face absolut pe nimerite, deoarece zona de afișare rezervată este prea mică) iar actualizările nu se propagă complet (de pildă ștergerea unei coloane nu conduce la ștergerea restricțiilor asupra sa sau a coloanelor corespunzătoare din vederile care o referă). Cu siguranță versiunile viitoare vor rezolva aceste probleme.

Inevitabile comparații

Cu toate că sloganurile publicitare de genul „easy to use“, „user friendly“ și „15 minutes and you're in business“ sunt foarte la modă, adevărul este că utilizarea lui Database Designer nu scutește pe nici un proiectant de cunoașterea fundamentelor modelului relațional și a limbajului SQL. Definirea unui view util implică utilizarea explicită a limbajului SQL, iar dacă se încearcă definirea unui trigger atunci lucrurile se complică și mai mult, deoarece se cere utilizarea lui PL/SQL, extensia procedurală de la Oracle. Pentru utilizarea la putere maximă a produsului, sunt necesare și multe noțiuni de administrare a SGBD-urilor Oracle (vă spun ceva noțiunile Tablespace, Storage Definition, Init trans, Max trans, Pct free sau Pct used ?).

Din perspectiva proiectantului, produsul este puternic orientat pe faza de implementare, ceea ce are atât avantaje cât și dezavantaje. Dintre dezavantaje mă mulțumesc să remarc faptul că această orientare nu sprijină o metodologie clară de proiectare. În contrast, S-Designor, un produs concurent, susține în mod coerent modelul ER (Entity-Relationship) oferind două nivele de proiectare: primul este cel conceptual, în care se operează cu tabele și relații la modul general. Abia al doilea nivel, cel fizic, aduce în discuție noțiuni se implementare (cum ar fi cea de cheie străină), generând pe baza modelului conceptual o schemă specifică SGBD-ului țintă. Din această perspectivă, suportul lui Database Designer pentru bazele de date non-Oracle este echivalent doar cu un gest de politețe.

O carență importantă a produsului este lipsa unui suport pentru documentarea schemei generate. Orice proiectant sau administrator de baze de date știe că orice schemă de date necesită o documentație solidă, care servește în egală măsură în administrare și în proiectarea aplicațiilor. Care sunt implicațiile faptului că, din motive de performanță, desfac o tabelă în două și plasez în locul ei un view? Răspunsul la o astfel de întrebare nu poate să vină decât dintr-o documentație care, printre altele, trebuie să cuprindă și referințele încrucișate ale obiectelor din schemă. S-Designor – termenul de comparație cel mai cunoscut – poate să genereze pentru orice schemă documentații detaliate, în care sunt cuprinse și notele, observațiile și explicațiile proiectanților. În cazul lui Database Designer, toate observațiile prin care proiectantul documentează semantica datelor se pierd sau sunt îngropate într-un script SQL.

Câteva concluzii

Foarte multe dintre facilitățile oferite de Database Designer sunt destinate generatoarelor de cod cuprinse în familia de produse RAD de la Oracle (Designer/2000 și Developer/2000). Informațiile mai noi oferite în situl Web al firmei Oracle precum și un articol prezentare apărut în ultimul număr al revistei Oracle Magazine dezvăluie faptul că în cursul acestui an, o nouă versiune a lui Designer/2000 Workgroup Edition va integra complet Database Designer, într-o formă nouă, cuprinzând un mediu de proiectare nou (Design Editor) care va îmbunătăți interfața cu utilizatorul și va face disponibile proiectantului puternicele generatoare de cod, inclusiv pentru generarea de aplicații complete pentru Oracle WebServer. În lumina acestei evoluții viitoare, produsul în forma actuală este mai degrabă un pre-release menit să canalizeze spre echipa de dezvoltare de la Oracle sugestiile și observațiile utilizatorilor.

De altfel produsul poate fi descărcat în mod gratuit pentru testare de la situl Oracle.