Search  
Saturday, June 24, 2017 ..:: Articole » Tehnici de proiectare a bazelor de date ::.. Register  Login
 Articole Minimize

Tehnici de proiectare a bazelor de date

Autor: Markus Egger
Notă: Proiectarea bazei de date este unul din cei mai importanţi paşi în dezvoltarea unei aplicaţii. Din păcate, este şi foarte complex. Dar prin aplicarea modelelor care şi-au dovedit funcţionalitatea se poate ajunge uşor la o soluţie viabilă. În această expunere veţi găsi informaţii utile pentru a proiecta corect şi sigur o bază de date.

Una din noţiunile des vehiculate în domeniul informaticii, şi mai ales în lumea FoxPro, este termenul "model". Modelele sunt omniprezente. Ele vă ajută să creaţi aplicaţii orientate pe obiect, ele vă ajută să scrieţi codul pentru algoritmi, ş.a.m.d. Dar destul de puţină lume sesizează faptul că modelele sunt utile şi în proiectarea bazelor de date. Bineînţeles, modelele OO sunt mult mai evidente, pentru că există foarte multe scenarii în privinţa datelor. Dar o mare parte din modele descriu entităţi similare. Într-o bază de date se stochează adrese, articole, contracte, documente, etc.

În calitate de programator, am intrat în contact cu multe cazuri - de la firme de vânzări până la utilizatori individuali, care voiau să îşi facă o agendă telefonică. Toate aceste cazuri au ceva în comun: sunt extrem de diferite! :-) Modelul de date este particularizat şi complet diferit de toate celelalte. Dar chiar este? Nu prea-mi vine să cred chestia asta... Dar asta nu îseamnă că susţin că toate modelele de date sunt la fel; mai degrabă contrariul. Ca să fiu sincer, nu am reuşit până acum să refolosesc în totalitate un model de date proiectat pentru altcineva. Dar am reuşit să "văd" câteva modele (câteodată cu ajutorul altora, trebuie să recunosc). Ideea este că modelele diferă în detalii: nume diferite pentru câmpuri, reguli diferite care descriu modul în care datele sunt stocate în tabele, etc.

Gestionarea informaţiilor despre oameni şi organizaţii

Oamenii par să fie extrem de importanţi în aproape orice aplicaţie. Acest lucru nu este deloc surprinzător, pentru că toate firmele au oameni care lucrează acolo. Ceea ce este surprinzător, în schimb, este faptul că o mare parte a aplicaţiilor nu gestionează corect informaţiile despre ei. Oamenii au, de obicei, mai multe numere de telefon, iar unii dintre ei au mai multe adrese. Oamenii intră în relaţii cu alţi oameni sau alte firme. Unii dintre ei lucrează pentru mai multe firme, câteodată chiar simultan!

Şi totuşi, cele mai multe aplicaţii nu sunt capabile să gestioneze corect toate aceste informaţii. De cele mai multe ori, în aplicaţii găsim o singură tabelă în care sunt câteva câmpuri care conţin câmpuri în care sunt scrise numele, adresa, telefonul, etc.

Prezentarea părţilor

Oamenii şi organizaţiile au multe informaţii şi relaţii comune, şi de cele mai multe ori nici nu este nevoie să facem o distincţie. De exemplu, putem trimite o factură sau o plată către o persoană fizică (tipul care a reparat acoperişul, sau pentru care am scris un mic soft de evidenţă), sau o firmă (banca la care avem contul sau firma căreia i-am vândut programele). Până la urmă, o firmă este o persoană juridică. Din acest motiv voi folosi termenul "părţi".

Pentru a stabili proprietăţile fiecărei entităţi, va trebui să aveţi o discuţie cu clientul dvs., pentru că ele diferă foarte mult, funcţie de tipul aplicaţiei. Dar există şi câteva care sunt "de bun simţ". Toate părţile au un nume. Dacă partea este o persoană fizică, acesta este numele de familie. În acest caz, are şi un prenume, şi o iniţială a tatălui. Dacă partea este o persoană juridică, aceste câmpuri rămân necompletate. Raţionând identic, ajungem la concluzia că persoanele juridice au proprietăţi specificie, cum ar fi scopul (client, furnizor).

Există mult mai multe proprietăţi aplicabile şi persoanelor fizice şi celor juridice; una dintre ele este adresa. Modul în care este stocată adresa în tabele depinde de câţiva factori. De când cu Internetul, este foarte important să putem stoca adresele în formate diferite. în România adresele arată altfel decât în SUA. Şi întotdeauna îmi vine damblaua când trebuie să introduc şi "ZIP Code" (care vrea neapărat 5 caractere). Evident, aceste probleme pot fi rezolvate printr-o proiectare adecvată a interfeţei (această expunere nu tratează interfaţa).

După o analiză atentă a tuturor factorilor, am ajuns la concluzia că este posibilă identificarea unui set standard de proprietăţi a adresei. În Figura 1 este afişată entitatea "parte".

Figura 1.
database1.gif

Aţi putea spune: "Bine, dar n-am făcut nimic deosebit faţă de alte aplicaţii. Tot nu pot să stochez mai multe adrese...". Şi este adevarat ce spuneţi. Hai să vedem ce putem face în această privinţă. Soluţia evidentă este aceea de a adăuga o tabelă relaţionată care să conţină una sau mai multe adrese. Modelul va arăta ca în Figura 2.

Figura 2.
database2.gif

Acest model este suficient în scenarii simple. Nu are sens să facem modelul mai complex decât este necesar. Trebuie să ţineţi cont de faptul că modelele pe care le prezint în această expunere sunt doar sugestii, nu reguli. Modelele de date nu sunt greşite niciodată; ele doar sunt mai mult sau mai puţin folositoare într-o situaţie dată. Deci, dacă modelul prezentat satisface necesităţile dvs., folosiţi-l.

Dar este evident faptul că modelul de mai sus nu reflectă viaţa reală. Nu numai că o parte poate avea mai multe adrese, dar părţi diferite pot avea aceeaşi adresă. De exemplu, în clădirea în care lucrez sunt două firme. De asemenea, ambele firme au persoane care lucrează acolo.

Mergând mai departe cu analiza, constatăm că o adresă are şi o dată calendaristică. Dacă o parte îşi schimbă adresa, este incorect să o ştergem pe cea veche şi să o scriem pe cea nouă; acest lucru va avea ca rezultat inconsistenţe în baza de date. Să presupunem că faceţi o factură pentru un client. Doi ani mai târziu, când vă uitaţi din nou la factura aia, constataţi ca nu mai are adresă, pentru că aţi şters-o din baza de date când clientul şi-a modificat adresa. Pe de altă parte, nu puteţi să o lăsaţi acolo, pur şi simplu, pentru că nu mai este valabilă. Puteţi rezolva această problemă prin adăugarea unei entităţi numită "plasament". În Figura 3 este ilustrat acest lucru.

Figura 3
database3.gif

Am înlocuit entitatea Adresă cu entitatea "Locaţie". Motivul este că noţiunea adresă nu este un termen prea bine definit. În conversaţiile zilnice, adresa este de obicei asociată unei singure părţi ("Hei, care e adresa lu' Gogu?") În alte ocazii, termenul este asociat mai multor părţi, sau chiar părţile pot avea aceeaşi adresă, după cum am discutat mai devreme. Termentul plasament ar trebui să clarifice situaţia. Este o adresă fizică mult mai clară.

De asemenea, am mutat proprietatea .Scop a organizaţiei în tabela Plasament. Acest lucru va părea ciudat celor care se ocupă cu analiza modelelor bazelor de date, pentru că soluţia sugerată de obicei în acest caz este plasarea .Scopului în tabela Locaţie. Personal, nu sunt de acord cu acest lucru. Aceeaşi locaţie poate avea scopuri diferite pentru părţi diferite. O locaţie poate fi sediul central pentru o firmă şi, totodată, poate fi centrul de service pentru altă firmă. Un individ care lucrează acasă poate avea scopuri diferite pentru aceeaşi locaţie. Mai mult, scopul unei locaţii se poate modifica de-a lungul timpului - centrul de service poate deveni centrul de vânzări, de exemplu. Argumentele de mai sus sunt suficiente pentru a muta .Scopul în tabela Plasament.

În acest moment avem un model destul de flexibil pentru a trata cele mai multe scenarii. Evident, scenariul poate deveni mult mai complex (se pot adăuga locaţii geografice, sub-zone, etc). Dar ar fi prea mult pentru acest articol.

Gestionarea numerelor de telefon şi a adreselor e-mail

Un alt subiect de interes în privinţa părţilor este gestionarea numerelor de telefon şi a altor informaţii similare. Eu folosesc pentru acest tip de informaţii termenul "informaţii de comunicaţie". Nu este în totalitate corect, pentru că şi adresa este, până la urmă, tot o informaţie de acest tip, dar pentru moment o las aşa...

Informaţiile de comunicaţie pot include numere de telefon, de fax, adrese e-mail, adrese WEB, etc. Sunt destul de dificil de gestionat. Un număr de telefon poate aparţine unui anumit plasament sau unei anumite locaţii, dar poate fi şi un număr de telefon mobil, care este luat oriunde se duce proprietarul său. Chiar dacă proprietarul se mută sau îşi schimbă firma, numărul rămâne valabil. Privind din această perspectivă, numărul trebuie atribuit părţii înseşi, independent de locaţie sau plasament. În privinţa adreselor e-mail, lucrurile sunt identice: unele sunt dependente de firmă, iar în acest caz, dacă persoana se mută la altă firmă, adresa e-mail se va modifica. Alte adrese e-mail pot fi mult mai generice, cum ar fi nume@yahoo.com sau nume@hotmail.com. În acest caz, nu se vor schimba prea des.

Din acest motiv, eu de obicei introduc informaţiile de comunicaţie în două entităţi diferite, după cum este ilustrat în Figura 4.

Figura 4
database4.gif

În acest scenariu, informaţiile de comunicaţie pot fi ataşate unei părţi sau unei locaţii. Bineîinţeles, este o relaţie unu-la-mai-multe, aşa că puteţi scrie oricâte numere de telefon şi adrese e-mail doriţi. De asemenea, este de remarcat că un singur "dispozitiv de comunicaţii" poate fi atribuit simultat şi unei locaţii, şi unei persoane. De ce este important acest lucru? Ei bine, iată un exemplu: am două telefoane mobile (Ăl' mai tare şi mai tare / Are două celulare / Şi pager la cingătoare... :) ). Dar angajez pe cineva şi îi dau unul din ele pentru o perioadă de timp. Astfel, telefonul acela este atribuit simultan către două părţi: eu şi angajatul meu. Dar în realitate nu este atribuit direct. Mai degrabă ar trebui atribuit locaţiei, pentru că telefonul aparţine firmei...

O variantă ar fi plasarea informaţiilor de comunicaţie în tabela Plasament, nu în tabela Locaţie. În acest fel, informaţiile de comunicaţie vor căpăta o dată calendaristică de început şi de sfârşit a funcţionalităţii lor, în corespondenţă cu un plasament, nu cu o parte. Ideea este isteaţă, pentru că de obicei informaţiile de comunicaţie nu mai sunt valabile când o persoană îşi schimbă plasamentul. În schimb, numerele de telefon atribuite direct părţii (cum ar fi numerele de telefon mobil) nu se vor modifica. Acest scenariu este tratat foarte bine de acest model.

O altă metodă ar fi să adăugaţi câmpuri de tip dată calendaristică fiecărui număr de telefon. Dar nu va fi pe placul utilizatorilor (decât dacă este o cerinţă expresă a lor). De asemenea, flexibilitatea trebuie susţinută de o interfaţă simplă.

Partea complicată: Relaţionarea bazei de date

În viaţa reală, relaţiile sunt complicate. Vestea proastă: Modelele de date trebuie să reflecte viaţa reală. Vestea bună: Ăăăă.... Hmmmmm.....

De fapt, viaţa nu este chiar aşa de rea. Hai să privim mai întâi relaţiile interne. Când zic "relaţii interne", mă refer la relaţiile cu o firmă, o organizaţie sau altă parte - cu alte cuvinte, o parte poate fi compusă din mai multe părţi. O firmă poate avea mai multe departamente, în care sunt persoane sau alte părţi. Spre deosebire de viaţa personală, aceste relaţii sunt de tip una-la-mai-multe (bine măcar că nu suntem obligaţi să avem relaţii una-la-mai-multe şi în viaţa personală hi,hi,hi...)

Dar nu este chiar atât de simplu. Nu numai că un departament poate avea mai multe persoane care lucrează acolo, dar o singură persoană poate lucra în mai multe departamente. De-a lungul timpului, complexitatea evoluează. Oamenii se mută, sunt avansaţi, etc. Sarea şi piperul sunt date de situaţia când persoana lucrează în acelaşi departament, dar în altă funcţie.

Modelul ilustrat în Figura 5 permite gestionarea scenariului menţionat anterior. O parte, care reprezintă angajatul, poate fi relaţionat către orice poziţie (de fapt, către mai multe poziţii) folosind entitatea Atribuire poziţii. Puteţi atribui mai multe poziţii oricăreia dintre părţi (aceasta ar fi angajatorul sau departamentul) şi puteţi atribui oricâte părţi oricărei poziţii. Mai mult, în acest fel puteţi urmări cronologic mişcările, folosind câmpurile de tip dată calendaristică din entitatea Atribuire poziţii.

Figura 5
database5.gif

Modelul acesta ar trebui să funcţioneze în majoritatea cazurilor.

Evident, sunt multe feluri de relaţii, cu mult mai multe decât se pot discuta într-un articol. În Figura 6 este ilustrat un model de relaţionare simplificat şi foarte general, care poate fi folosit pentru a relaţiona orice fel de parte către oricâte părţi. El nu este un model de relaţionare particularizată, ci mai degrabă un model de relaţionare încrucişată (crosslink relationship).

Figura 6
database6.gif

Acest model de relaţionare şi-a dovedit funcţionalitatea în multe rânduri. De cele mai multe ori am fost nevoit doar să adaug nişte reguli (business rules) şi câteva câmpuri, dar în rest modelul a rămas la fel. Cu alte cuvinte, încercă să-mi simplific relaţiile (<g>).

Concluzie

În acest articol am demonstrat modul de creare a unui "Data Model" puternic şi flexibil care stochează părţi, adrese şi informaţii de comunicaţii. Eu folosesc acest model în aproape toate aplicaţiile pe care le scriu. Ori de câte ori discut cu un viitor client, această parte a aplicaţiei este făcută deja şi gata de funcţionare chiar înainte ca eu să am primul contact cu clientul. De cele mai multe ori este suficient să refolosesc acest model, să adaug câteva câmpuri, să implementez vreo două-trei reguli în plus, şi voila!

Bineînţeles că am şi câteva clase refolosibile care îmi oferă şi interfaţa adecvată acestui model. Aţi putea gândi că cel puţin o parte din aceste modele sunt simpatice la prima vedere (în teorie), dar dificile pentru utilizator. Sunt de acord cu dvs. Pentru a introduce date aşa cum sunt stocate în model este o acţiune prea complexă şi greu de înţeles. Trucul constă în oferirea unei interfeţe care să ascundă această complexitate. Un exemplu excepţional în această privinţă este Microsoft Outlook. La început, pare să fie un repertoar. Dar pe măsură ce aveţi nevoie de facilităţi suplimentare, Microsoft Outlook vi le pune pe ecran. Sunt acolo. Trebuie doar apelate...

Dar proiectarea unei interfeţe adecvate este cu totul altă chestiune şi va fi tratată în altă expunere.

Aşa cum probabil ştiţi, modelele pot fi găsite în aproape toate aspectele privitoare la proiectarea datelor; acest articol este doar o introducere sumară în subiect. S-au scris cărţi întregi pe acest subiect. Şi eu voi mai atinge subiectul în expuneri viitoare. Sper doar ca, după citirea acestui articol, toate aceste lucruri să vă pară simple şi evidente. Probabil că deja v-aţi stocat datele folosind un model flexibil (poate alfel proiectat decât al meu), sau poate doar gândiţi că toată povestea de mai sus are sens, începând să vă miraţi de ce cele mai multe aplicaţii nu gestionează corect entităţile discutate aici. În acest caz, această expunere şi-a atins scopul.


    

 Google Ads Minimize

    

Copyright 2002-2013 Profox   Terms Of Use  Privacy Statement