Principalul "vinovat" pentru această (aparentă, totuşi) stagnare este modelul de date relaţional, care pare nemuritor. De la elaborarea sa de către dr. Codd în 1970, puţine au fost inovaţiile care să-i fi marcat existenţa. Produsele bazate pe acest model domină copios piaţa (peste 95%), astfel încât putem constata că, practic, toate sistemele de gestiune a bazelor de date care nu sunt relaţionale sunt produse "de nişă", destinate unor domenii foarte particulare.

Cu toate acestea, modelul relaţional este departe de a fi perfect, iar limitările sale devin tot mai evidente pe măsură ce informatica evoluează spre domenii care nici nu puteau fi imaginate în anii '70. Mă voi limita doar la trei dintre cele mai flagrante:

• Inabilitatea de a trata date nestructurate, cum ar fi texte, documente informale, informaţii de natură audiovizuală şi altele asemenea;

• Comunicarea greoaie între sisteme diferite impune o organizare centralizată, în contrast flagrant cu natura eminamente distribuită a Internetului;

• Costurile foarte mari legate de achiziţia, instalarea, dezvoltarea şi întreţinerea sistemelor de baze de date precum şi a aplicaţiilor care se bazează pe acestea.

Puţină gramatică

Ideea modelului asociativ îi aparţine lui Simon Williams, preşedintele firmei britanice Lazy Software, firmă care de altfel a dezvoltat primul (şi, deocamdată, sigurul) produs comercial bazat pe acesta, numit Sentences.

Deşi se bazează pe o diversitate de cercetări academice în domenii destul de disparate (reţete semantice, modelul entitate-relaţie etc.), modelul asociativ este de o simplitate surprinzătoare, deoarece reprezentarea informaţiei se face într-o formă care ne este familiară încă din copilărie. Este vorba de fraze foarte simple, având structura subiect-predicat-obiect. Iată câteva exemple din domeniul organizării unei biblioteci, domeniu pe care-l voi folosi în continuare pentru exemplificări:

      Jorge Luis Borges a scris "Biblioteca Babel".
      Editura Univers a publicat "Cartea de nisip".

O primă observaţie este că, în general, astfel de fraze admit şi exprimări inverse. De pildă:

      "Biblioteca Babel" a fost scrisă de Jorge Luis Borges.

A doua observaţie este că o frază poate juca rolul subiectului sau obiectului într-o altă frază:

      (Editura Univers a publicat "Cartea de nisip") în anul 1984.

În fine, a venit vremea să ne despărţim de gramatică. Predicatele din modelul asociativ (scrise în cursive) nu se exprimă doar prin verbe, ci chiar şi prin prepoziţii sau expresii. Adoptând terminologia modelului asociativ, ceea ce am numit până acum "frază" se cheamă asociere, iar structura "subiect-predicat-obiect" va fi exprimată ca sursă-verb-ţintă. Vom adopta şi un nou mod de a scrie asocierile:

      Editura Univers a publicat Cartea de nisip
        ... în anul 1984

Am scris în aldine piesele de informaţie (datele propriu-zise). Cele trei puncte din linia a doua ţin locul întregii asocieri exprimate în prima linie. Prin indentări corespunzătoare (similare celor folosite la scrierea programelor) se pot exprima în mod succint informaţii complexe.

Entităţi şi asocieri

Din perspectivă conceptuală, modelul asociativ utilizează doar două noţiuni fundamentale: entităţi şi asocieri:

• Entităţile sunt elemente atomice, a căror existenţă este independentă de orice altceva;

• Asocierile sunt elemente a căror existenţă depinde de cel puţin un alt element, în sensul că dacă acel element ar înceta să mai existe, asociaţia ar dispărea la rândul ei (sau şi-ar pierde înţelesul).

Distincţia dintre entităţi şi asocieri este dependentă de domeniul problemei modelate şi de "granulariţia" aleasă de proiectant. Câteva exemple ne pot fi de folos:

O persoană este o entitate, în timp ce rolurile pe care le poate juca în cadrul problemei modelate se exprimă prin asocieri. Dacă revenim la problema bibliotecii, autorii cărţilor sunt persoane. Tot persoane sunt şi clienţii bibliotecii. Persoana este entitate, în timp ce calitatea de autor sau client se exprimă prin asocieri.

O carte se exprimă ca entitate sau ca asociere? Aici intervine "granulaţia" (nivelul de detaliere ales de proiectant). Dacă voi modela o bibliotecă personală de mici dimensiuni, probabil ca voi alege să reprezint o carte ca pe o entitate. Pentru o bibliotecă mare însă, noţiunea de carte probabil că nici nu va apărea ca atare, ci va fi exprimată printr-un lanţ întreg de asocieri. De pildă: autorii scriu lucrări, editorii publică titluri, biblioteca gestionează exemplare, iar asocierile dintre aceste entităţi stabilesc imaginea completă asupra domeniului.

Unul dintre aspectele cele mai interesante ale modelului asociativ este faptul că informaţiile despre structura datelor (schema bazei de date) se reprezintă la fel ca şi datele. Mai mult chiar, această reprezentare reprezintă tiparul după care sunt reprezentate datele. Iată care ar fi schema unei baze de date minimale pentru o biblioteca:

      Lucrare are ca autor Persoana
      Titlu cuprinde Lucrare
      Titlu publicat de Editor
        ... în anul An
          ... identificat prin ISBN
          ... există ca Exemplar
      Persoana împrumută Exemplar
        ... de la Data
          ... până la Data
            ... restituit Da/Nu

Înainte de a trece la modul în care sunt reprezentate datele propriu-zise, mai trebuie spus că specificarea concretă a unei asocieri implică şi nişte informaţii de cardinalitate, cum ar fi caracterul obligatoriu sau opţional precum şi posibilitatea de a avea mai multe ţinte pentru aceeaşi sursă. În plus, pentru fiecare asociere există în mod implicit şi o asociere inversă. De pildă, pentru prima asociere din exemplu, inversa poate fi numită a scris :

      Persoana a scris Lucrare

În schema de mai sus, prima asociere este opţională (pot exista lucrări cărora să nu li se specifice autorii, de pildă pentru o enciclopedie) şi multiplă (există lucrări care au mai mulţi autori). Inversa are aceleaşi caracteristici: pot exista persoane care nu sunt autori (de pildă cei mai mulţi dintre clienţii bibliotecii) precum şi persoane care sunt autorii mai multor lucrări. În schimb identificarea prin ISBN este unică.

Iată şi câteva date:

      Learning Perl are ca autor Randal Schwartz
      Learning Perl are ca autor Tom Christiansen
      Learning Perl cuprinde Learning Perl
      Learning Perl publicat de O'Reilly
        ... în anul 1997
          ... identificat prin 1-56592-284-0
          ... există ca RSTC001
          ... există ca RSTC002

Este foarte uşor de înţeles că este vorba despre o carte (Learning Perl) având doi autori (Randal Schwartz şi Tom Christiansen), publicată de o anumită editură (O'Reilly), sub un anumit ISBN (1-56592-284-0) şi disponibilă în două exemplare (RSTC001 şi RSTC002).

O observaţie legată de terminologie: pentru a face diferenţa dintre date şi metadate, în schemă se vorbeşte despre tipuri (entitate sau asociere) pe când în date se vorbeşte despre instanţe ale acestor tipuri.

Piese şi legături

Dacă din punctul de vedere al structurării datelor, entităţile şi asocierile au fost eroii principali, din perspectiva stocării lor avem de-a face cu alte două noţiuni: piese (items) şi legături (links). Astfel, o bază de date asociativă constă din:

• Un set de piese, fiecare având un identificator unic, un nume şi un tip. Piesele reţin informaţii despre entităţi şi verbe.

• Un set de legături, fiecare având un identificator unic împreună cu încă trei valori, corespunzătoare identificatorilor sursei, verbului şi respectiv ţintei. Legăturile memorează asocierile.

Datele din exemplul de mai sus se vor reprezenta cam în felul următor:

      Piese
      Id    Nume
      101  Learning Perl
      102  are ca autor
      103  Randal Schwartz
      104  Tom Christiansen
      105  Learning Perl
      106  cuprinde
      107  publicat de
      108  O'Reilly
      109  în anul
      110  1997
      111  identificat prin
      112  1-56592-284-0
      113  există ca
      114  RSTC001
      115  RSTC002

      Legături
      Id    Sursa   Verb    Ţinta
      116   101     102     103
      117   101     102     104
      118   105     106     101
      119   105     107     108
      120   119     109     110
      121   120     111     112
      122   120     113     114
      123   120     113     115

Ceea ce este remarcabil este faptul că o bază de date asociativă cuprinde doar două structuri de stocare şi, mai mult chiar, schema este stocată în aceleaşi structuri (deşi nu am inclus în exemplificare şi schema, este uşor de dedus cum se procedează).

Dezvoltare incrementală

O altă caracteristică interesantă este că schema poate fi dezvoltată incremental, fără ca aceasta să influenţeze datele deja stocate. Să presupunem că ne interesează să memoram informaţii detaliate despre o lucrare. De pildă, pentru un volum de povestiri sau de poezii ne-ar putea interesa să memorăm şi povestirile sau poeziile cuprinse. Nu avem decât să adăugăm o asociere:

      Lucrare cuprinde Lucrare

Această nouă informaţie va fi memorată (printr-o legătură) şi în continuare pot fi memorate şi astfel de informaţii. Această asociere poate să nu fie prevăzută în primele fazele ale dezvoltării unei aplicaţii concrete, dar poate deveni interesantă pe parcurs. Cu ajutorul acestei se poate memora, de exemplu, că povestirea "Biblioteca Babel" de Jorge Luis Borges face parte din ciclul "Grădina potecilor ce se bifurcă", parte a lucrării "Ficţiuni". Pornind de la nivelul cel mai de jos se poate constata că această povestire a apărut în limba română atât în titlul "Grădina potecilor ce se bifurcă" din seria "Meridiane" a editurii Univers, cât şi în "Opere", editată de aceeaşi editură.

Se pot imagina şi alte dezvoltări ulterioare. De pildă, o asociere "este pseudonimul lui" ar putea memora că matematicianul Dan Barbilian este una şi aceeaşi persoană cu poetul Ion Barbu sau că Isak Dinesen este pseudonimul scriitoarei Karen Blixen.

La nivelul implementării, există şi alte mecanisme care susţin dezvoltarea incrementală şi permit modificări importante în schemă fără ca aceasta să implice pierderi de date sau reorganizarea acestora. Sentences permite, de exemplu, definirea unui supertip comun pentru mai multe entităţi. Dacă într-o primă fază, "angajat" şi "client" erau entităţi separate, se poate adăuga un supertip comun "persoana". În sens invers, se pot defini subseturi, apartenenţa la acestea fiind tranzitorie. În exemplul tratat se pot defini subseturile "autor" şi "client" pe baza unei condiţii susţinute de o căutare: autori sunt persoanele care figurează ca ţintă pentru cel puţin o instanţă a asocierii "are ca autor".

În fine, o caracteristică ce derivă din uniformitatea datelor şi metadatelor este posibilitatea de a defini tipuri de asocieri care sunt specifice unei instanţe particulare a piesei sursă. Dacă această asociere se dovedeşte utilă în mai multe cazuri, sursa ei poate fi schimbată de la instanţa particulară la tipul corespunzător acesteia, fără a pierde informaţie.

Capitole şi profiluri

O bază de date se compune dintr-un număr de capitole, fiecare dintre acestea stocând anumite entităţi şi asociaţii. Imaginea unui utilizator asupra bazei de date este determinată de un aşa numit profil, care nu este altceva decât o listă a capitolelor la care respectivul utilizator are acces. Este interesant de remarcat faptul ca această organizare vizează în egală măsură atât schema cât şi datele. Dacă o entitate nu apare într-unul dintre capitolele la care un utilizator are acces, acesta nu va acces nici la datele corespunzătoare şi, de fapt, nici nu va ştii că aceasta există. În cazul asocierilor, dacă fie sursa fie ţinta nu sunt în profilul utilizatorului, acesta nu va vedea asocierea.

În exemplul bibliotecii, ne putem imagina următoarea împărţire pe capitole:

• Capitolul Baza cuprinde doar entităţile Persoana, Data, Da/Nu şi An.

• Capitolul Bibliograf cuprinde entităţile Lucrare, Titlu, Editor şi ISBN.

• Capitolul Împrumuturi cuprinde entitatea Exemplar.

În baza acestor capitole se pot stabili câteva profiluri, corespunzătoare unor roluri tipice:

• Supervizor -- va cuprinde toate capitolele, ceea ce va furniza o imagine exhaustivă a bazei de date.

• Cititor -- va cuprinde capitolele Baza şi Bibliograf, ceea ce va furniza o imagine completă asupra bazei bibliografice, dar nu va furniza informaţii despre operaţiile de împrumut.

• Operator -- va cuprinde capitolele Baza şi Împrumuturi, astfel încât un utilizator având acest profil va putea consemna operaţiile de împrumut şi restituire, fără să aibă însă acces la informaţiile bibliografice.

Această împărţire este oarecum gândită la nivel funcţional, dar acelaşi mecanism se poate utiliza pentru împărţirea datelor. Se poate imagina ca anumiţi bibliotecari lucrează în domeniul literaturii beletristice şi alţii în domeniul literaturii tehnice, datele corespunzătoare fiind în capitole diferite.

Profilurile utilizatorilor pot fi schimbate în mod dinamic, prin simpla adăugare sau eliminare a unor capitole. De fapt, la adăugarea unui capitol se pot produce schimbări spectaculoase, deoarece în afară de entităţi noi pot apăra şi asocieri noi, care până atunci erau invizibile datorită faptului că sursa sau ţinta nu erau cuprinse în capitolele ce formau profilul.

Deoarece simpla concatenare a capitolelor dezvoltă schema -- şi implicit funcţionalitatea -- bazei de date, se pot imagina o mulţime de aplicaţii ale acestui mecanism. Extrem de valoroase sunt cele care se referă la posibilitatea de a furniza funcţionalitate personalizată. De pildă, un furnizor de aplicaţii Internet poate dispune de un set de capitole de bază şi de capitole speciale pentru diverşi clienţi, astfel încât fiecare lucrează de fapt cu o aplicaţie personalizată (parametrizările aplicaţiilor clasice sunt departe de astfel de performanţe). Mai mult chiar, capitole speciale care s-au dovedit utile mai multor clienţi pot fi incluse între cele de bază sau pot fi pur şi simplu plasate în profilurile altor clienţi care au nevoie de funcţionalitatea respectivă.

De asemenea, capitolele şi profilurile pot îmbunătăţi livrarea şi testarea unor noi versiuni ale unei aplicaţii (un upgrade se reduce la furnizarea unor capitole suplimentare), sau pot permite utilizatorilor să-şi personalizeze aplicaţia.

Sentences

Implementarea realizată de Lazy Software este un SGBD care poartă numele Sentences (evocând astfel metafora primordială a modelului asociativ) şi este realizată exclusiv în Java. Versiunea comercială cuprinde un server (un servlet Java) şi un client (un applet Java care rulează într-un browser). Există şi o ediţie personală (care combină serverul şi clientul într-o singura aplicaţie), servind pentru evaluare, dar având întreaga funcţionalitate a versiunii comerciale. De asemenea, Sentences cuprinde şi un API complet, care permite realizarea unor aplicaţii Java care să utilizeze suportul asociativ de stocare furnizat de Sentences.

În mod interactiv, Sentences permite construirea schemei şi manevrarea datelor. Interfaţa este simplă şi naturală iar elementele din schemă sunt imediat reflectate în formularele (generate automat) de culegere a datelor, numite dataforms. Explorarea datelor se face extrem de simplu, prin detalierea succesivă a asocierilor directe şi inverse, pornind de la orice entitate sau asociere [...]. În plus, două instrumente (la fel de simple) permit filtrarea datelor şi poziţionarea în cadrul seturilor.

Pentru selecţii mai complexe, Sentences furnizează un mecanism mai sofisticat de elaborare a interogărilor, numit Query Editor. Deşi descrierea mecanismelor prin care se descriu interogările depăşeşte cadrul acestei prezentări introductive, este interesant de remarcat că o interogare se concretizează tot într-un set de entităţi şi asocieri, în care pot interveni variabile şi parametri. Astfel, interogările pot fi păstrate şi pot fi considerate ca parte integrantă a schemei. Ele pot fi utilizate oricând pentru a obţine rezultate actuale, sau pot fi utilizate în definirea unor subseturi.

Faţă în faţă

Modelul relaţional este matur, are o largă acceptare, iar implementările au fost perfecţionate în 30 de ani. Este greu de crezut că modelul asociativ îl va înlocui peste noapte. Este însă cert că acesta din urmă dispune de câteva avantaje care îl pot propulsa în mainstream.

În primul rând, modelarea datelor este mai simplă şi mai naturală în modelul asociativ, ceea ce implică o exploatare la fel de uşoară. Cu siguranţă o bază de date asociativă (cum este Sentences) poate fi mai uşor stăpânită de un nespecialist decât una relaţională (cum este Access, de exemplu).

În al doilea rând, modelul asociativ este în mod natural unul distribuit. Simpla alăturare a două baze de date asociativă are sens, iar adăugarea câtorva asocieri le poate unifica fără costurile enorme pe care le implică o operaţie similară pentru baze de date relaţionale.

În fine, posibilităţile de personalizare a aplicaţiilor pot fi extrem de atractive pentru furnizorii de aplicaţii prin Internet, ceea ce ar putea stimula tendinţa spre externalizarea serviciilor informatice.