SISTEME DE GESTIUNE A BAZELOR DE DATE Obiectivul cursului : Cursul im propune s realizeze o introducere n modelarea , strcturarea , agregarea , stocarea i regsirea

datelor. Definete astfel principalele standarde i practici n acest sens , cu o orientare ferm spre integrarea datelor n arhitectura de integrare a intreprinderii . Se vor considera principalele medii de dezvoltare aplicaii att pentru structuri relaionale ct , poate ntr-o mai mic msur , oi pentru structuri orientate obiect . Planul cursului. Prezentul curs va parcurge urmtoarele capitole: Elemente de teoria bazelor de date Conceptele de baz ale SGBD Access Sisteme informatice SISTEME Se va lua n considerare natura i comportamentul sistemului . Se va extinde , n consecin acest cunotere la sistemele informaionale i la sistemele de stocare i regsire a informaiei . O bun nelegere a sistemului fundamenteaz sntos activitatea analizei sistemelor . Sistem Un sistem poate fi privit ca o colecie de pri interrelaionate carea acioneaz ca un ntreg spre ndeplinirea unui scop comun lor. Un sistem este un set de componente sau variabile , organizate , care interacioneaz , independent i integrat . Secolul XX a scos la iveal o sum enorm de probleme cu care se confrunt umanitatea , care sunt n cretere ca dimensiune , complexitate , dificiltate de rezolvare etc . Explicaii pentru astfel de probleme (n ecosisteme de exemplu) sunt extrem de complexe , eplicaiile simple de cauz-efect , de obicei sunt inacceptabile deoerece cei mai muli stimuli nu au un singur efect ci efecte multiple care ar trebui studiate separat i simultan . Pornind de la ceste consideraii s-a nscut o coal de conceprea sistemelor , n conformitate cu care cele mai multe fenomene pot fi nelese numai n contextul sistemului n acree acestea se produc . Mia mult , soluii la probleme aprute pot fi gsite numai prin proiectarea sau modificarea sistemului ca ntreg , mai degrab dect prin intervena n probleme particurae n ele nsele. Un sistem se va consira avnd modelul sistemului , care poate fi reprezentat ca o succesuine de diagrame , funcionale n internalitatea lor ct i n agregare unele cu altele . ntr-un astfel de gragic (succesiunea diagramelor) pot exista diagramele nsele a pri ale sistemului (subsisteme) i sgei etichetate care indic datele sau amterialele sau infleiena pe care o au sursele lor , pe de o parte i luxul care se stabilete pe de o alt parte .: Relaii - o sgeat care indic o relaie nte subsisteme i/sau obiecte externe unei diagrame . Numele su identific datele sau obiectele care trec de la un subsistem sau

obiect la altul . Sistemul int depinde n corcta sa funcionalitate de de sistemul originar al sgeii. Intrri - datele care intr n sistem . Acestea provin de la o surs definit i se ndreat spre o destinaie deasemeni definit . Un sistem deschis are cel puin o intrare Ieiri - datele care pleac din sistem . Un sistem decshis are cel puin o ieire Declanatoare - evenimente care declneaz activiti n sistem Restricii - restricii ale activitilor sistemului Un sistem n care intrrile i ieirle traverseaz propria-i frontier este un sistem deschis .n alte situaii se defini ca un sistem nchis . Este dificil a se gsi un sistem care s fie de interes i n acelai rtimp s fie nchis . Se definete n consecin sistemul relativ nchis , iar diferenerea lui de sistemul deschis este prezentat n figura de mai jos

Intrri definite

Transformarea intrrilor n ieiri fr perturbaii din exterior

Ieiri definite

Sisteme relativ inchise

Cunoscute Necunoscute

Transformarea coninutului intrrilor cunoscute i necunoscute i a perturbaiilor

Ieiri

Pertubaii Sisteme deschise

Un exemplu pentru sistem relativ nchis poate fi un program de calculator (ale crui intrri pot fi ecranate i n consecin controlate i ale crui ieiri sunt determinate numai de intrrile sale ) . Un exemplu de sistem deschis poate fi dat ca fiind orice sistem care implic , ntr-o form sau alta fiina uman . Ieirile nu pot fi parctic niciodat

predictibile deoarece sunt o sumedenie de intrri cu totul ecunoscute sau n tot cazul necontrolabile , iar anumite intrri n sistem sunt simple interferene . Se face de asemenea distincia dintre sisteme ale cror subsisteme sunt interconectate (fiecare la fiecare ) , n care fiecare subsistem are nevoie de intrri de fiecare dintre celelalte subsisteme , astfel c aceste sunt , clar interdependente iar relaiile care se stabilesc ntre aceste subsisteme sunt complexe i Sisteme conectate n care pri de subsisteme sunt interconectate iar legtura dintre aceste pri se realizeaz printr-o interfa (de obicei unic) simplificat . Acestea reflect mediul restrns n care anumite activiti au loc n interiorul sistemului i conectarea acestui submediu la mediul propriu (submediu) al altor activiti . Funciile ndeplinite de oricare dintre subsitemele interconectate ca subsisteme vor primi minimum de informaii strict necesare ndeplinirii acestora. S1 S2

S3 S6

S4

S5

Toate (sub)sistemele sunt interconectate (interfa complex)

S1

S4

S2 S3

S5

S6

Subsisteme conectate n cadrul unui (sub)sistem i interconecatarea de (sub)sisteme Sisteme care utilizeaz cereri (gen restaurant) , sau liste de ateptare (spitale) , inventare (linii de producie) i standarde (pentru a reduce comunicarea informaiei de la o parte la alta ) i decupleaz subsistemele . Dar trebuie de remarcat c acest decuplare nu este de loc simpl i nici ieftin . Pentru a avea o imagine i o posibilitate de definire a modului n care acest decuplare se poate produce , se face o detaliere a cuplrii sistemelor n : - sisteme tare cuplate , caracterizate printro coordonare direct , avnd ns nejunsul dificultilor severe care apar n sicronizarea aciunilor , evenimentelor etc - sisteme slab cuplate , care sunt fiecare n sinea lor independente i utilizeaz ca tehnici de decuplare : stocare n stive buffere mecanisme de cerere rspuns standarde pentru reducerea comunicaiei Aceste tehnici sunt (saupot fi ) foarte eficiente dar evident este o mare problem a costurilor. Sisteme informaionale Un sistem informaional se definete ca fiind un mecanism care furnizeaz mijloacele pentru stocarea , generarea i distribuirea informaiei al crei scop este susinerea funciilor i operaiilor din cadrul unei organizaii.

Ca paas urmtor , n consecin, sistemul informaional al unei organizaii este acel sistem al fluxurilor de informaii care rezult din interaciunea dintre diferietele sale pri. Deoarece subsistemele au ele nsele o structur algebic de sistem , subsistemele informaionale ale sistemului informaional sunl sut sisteme informaionale , de asemenea. Ca atare , sistemele informaionale sunt mijloace prin care datele curg de la o persoan/deparatment/subsistem la alta . Aceste sisteme inormaionale servesc sistemele organizaionale ale untreprinderii. Se pune intrebarea , relativ fireasc : de ce organizaia are o aa mare nevoie de sisteme informaionale ? Palnificare , control i luarea deciziei pentru acestea este o mae nevoie ca informaiile s circule att orizontal ntre departamente , ct i vertical , n jos i n sus strbtnd nivelele de control i planificare ale fiecrei organizaii . 1. Planificarea strategic - Acest nivel cuprinde stabilrea scopurile i determinarea resurselor necesare pentru atingerea acestora . Aceast activitate de management se detecteaz la realizarea de strategii pe termen mediu i lung . Informaiile , de cele mai multe ori solicitate de o amnier ad hoc (i obinute ca atare ) adreseaz aspectele evoluiei i tendinelor . Deoarece problemele cu care se confrunt managerul , de obicei nu sunt foarte clar stutcturate , informaia este utilizat de cele mai multe ori numai ca un susintor pentru luarea deciziei.

Palnificare strategic

Controlul gestiunii

Controlul operaional

p r o d u c i

C o n t a b i l i t a t e

L a n s a r e

2. Controlul gestiunii managementul mediu necesit informaii ca sprijin pentru Funciile primare obinerea de resurse i cretere att a aeficienei , ct i a productivitii , cu Nivelele de ale organizaiei creterea n densitate a activitilor pe unitatea de timp. La acest nivel probleme control

sunt mult mai bine structurate , iar informaia este utilizat pentru stabilirea cursului adecvat al aciunilor de o manier mai direct i mai eficient. 3. Controlil operaional la acest nivel sunt necesare informaii mai detaliate pentru a da posibilitatea realizrii sarcinilor specifice mai eficient . Problemele conduc ele nsele la analize fiind capabile a fi rezolvate semi-automat , dnd informaii detaliate orar , sau zilnic . Informaia ne apare n acest context , mai clar , ca fiind o resurs , care trebuie tratat ca atare , aidoma cu resursele materiale sau financiare , i exact la fel acesta trebuie s fie gestionat i controlat . Sisteme de stocare i regsire a informaiei Sistemele informaionale pot fi manuale , automate sau ambele , putnd astfel include i activiti ale persoanelor . Modelele naive ale sistemului informaional Tehnicile de modelare sunt caracteristice literaturii i pacticii calclatoarelor . Funciile lor sunt legate de modelarea sistemelor informaionale specifice , predominant n mediul comercial . Suplimentar tehnici formale , cum ar fi diagramele organizaiei , modeleaz forele care acineaz asupra organizaiei att din interior ct i din exteriorul acesteia i care afecteaz sistemele informaionale . Este instructiv dar poatze fi inutil s se caute literatura specializat n calculatoare i management pentru un model de nivel nalt , n sine, al sistemului informaional . Tipic un astfel de model se discut n termeni de stocarea a dfatelor , intrri pe de o parte , procesri , pe de o alta i ieiri pe de o a treia . Stoacarea datelor procesri intrri ieiri

Banalizarea pn la naivitate a modelului erste evident . Cu toate acestea , citnd una dintre lucrile remarcabile n domeniu : este util nu numai n nelegerea procesrii generale a informaiei dar de asemenea i pentru aplicaiile de procesare particulare , deoarece fiecare aplicaie paote fi analizat n termeni de intrri , stocare , procesare i ieiri Naivitatea modelului poate fi explicat prin referirea circumscrierii sau chiar a naturii predefinite a intrrilor i a ieirilor , regsite , tipic , n mai toate aplicaiile tradiionale de procesare a informaiei. Alfel spus , simplificarea , dus pn la extrem a modelului

reflect predeterminarea tipului de informaie acceptat pentru intrri , pentru care sistemul a fost proiectat i bineneles tipul ieirilor care rezult frec dintr-o procesare pas cu pas algoritmic , tipic i acesta pentru o periad de nceput a sistemelor informaionale . Pentu a junge la un model mai complex i mai aproape de realitatea curent se introduce noiunea de sistem de stocare i regsre a informaiei (ISAR) . Acesta este mecanismul cel mai intim a sistemului informaional . n concordan cu aceast definiie informaia care este stocat este i regsit (ntr-o manier oarecare de cutare). Funcia ISAR este de a oferi o organizare intelectual a informaiei stocate , avnd ca scop regsirea acesteia . Aspectul intelectual al organizrii este reallizat prin mijloace tehnologice . Exemple de ISAR ar putea fi o schem de clasificare a documentelor , de definire i indexare a acestora , cataloage de documente etc. n primul rnd , se cuvine s fie luat n discuie reprezentarea pe nivelul cel mai nalt al modelului sistemului informaional astfel definit . Reprezentare va fi structuratp ca n figura de mai jos :
Intrarea 1 Persoane cu cereri de Intrarea2

Achiziii

Achiziii

Declararea cererii

Informaii

Sistemul de stocare i regsire a informaiei

Frontiera sistemului ionformaional

Frontiera sistemului de stocare regsire

Ieire : cleint cu informaii

Aa cum se remarc modelul este descompus n dou stadii . Concentrarea va avea loc asupra nuceului celui mai din interior . Mecanismul cuprins n acest nivel va fi tratat

deocamdat ca un blackbox . Aceast eprezentare de nivel nalt va avea dou tipuri de intrri : una refer persoanele cu probleme din care rezult nevoi (cereri de informaie) i cea de a doua informaii i documente care vor trebui gsite n afara sistemului . Ieirea din sistem , pentru fiecare astfel de nevoie se va constitui dintrt+o colecie de documente sau documente reprezentative (acestea dau informaii asupra documentelor relevante) . Sistemul informaionale funcioneaz astfel : consult cererile aa cum au fost formulate de utilizator i dobndete , stochez i livreaz informaii. O ntrebare fireasc ce apare evident refer mecanismele logice prin care se poate decide dac o nregistrare (n spe un document) aparine clesei e ieire definit.. De fapr ISAR este tocmai acest mecanism , att din punctul de vedere al stocrii ct i evident din punctul de vedere a regsirii informaiei . n conformitate cu McGill i Salton elementele cheie pentru ISAR se descrie ca fiind : a. un set de entiti (denumite n continuare DOCS) b. un set de declaraii de cereri (denumit n continuare QUERIES) un mecanism ( denumit n continuare SIMILAR) care s fie capabil s determine care dintre elementele DOCS ndeplinesc condiiile date QUERIES dac exist vreunul . SIMILAR va reprezenta o funcie care mapeaz cererile specifice pe entiti particulare , relevana DOCS specifice unei QUERIES dat neputnd fi realizat prion comparaie direct. Mecanismul va ncepe cu conversia entitilor la o form standardizat prin utilizarea unui limbaj de clasificare sau standardizare (denumit n continuare , generic, LANG) . Cererile vor fi convertite , n continuare , de asemenea ntr-o reprezentare standardizat constnd din elmente ale aceluiai limbaj de indexare LANG . Msura similaritii se va materializa ntr-o submulime aDOCS care satisfac cererea respectiv.

Intrare 1- cereri utilizator Translatarea din declaraia cererii n sintaxa limbajului de indexare

Intrare 2 informaie dobndit Transformarea informaiei n sintaxa limbajului de indexare Limajul de indexare

Reguli i convenii care guverneaz maparea vocabularului de intrare peste limbajul de indexare Reguli ale formatului : lista autoritii , tezaur

Stocarea cererii

Stocarea informaiei

Indeplinire i afiare Regsirea informaiei rafinare Reformularea cererii Refomularea indexrii

In figura de mai sus se prezint o structur mai detaliat a ISAR . In aceast reprezentare apar dou tipuri de intrri , iar rolul de baz al ISAR este de a corela cele dou intrri . Aceasta nseman c pentru fiecare declaraie de cerere ISAR va cerceta colecia de documente sau de reprezentate ale documentelor dobndite anterior i descoper acele documente care ndeplinesc cererea . ISAR poate , evident fi manual sau automat . Cele dou intrri n sistem sunt , n consecin : 1. declaraia cererii descrierea din partea utilizatorului a informaiei solicitate , descris n termenii limbajului propriu al acestuia (utilizatorului) 2. documentele i/sau reprezentanii documentelor , anterior plasate n baza de adte Rolul ISAR este tocmai de a translata ambele tipuri de informaii , prin intermediul unui vocabular propriu ISAR , ntr-un mecanism de indexare pentru a putea indeplini funcia de similaritate . n acest sens , pentru cerere seva analiza limbajul natural al solicitantului pe cae l va translata n limbajul specific de indexare , conform cu regulile definite la nivelul ISA. Acest vocabular guverneaz selecie termenilor de indexare , forma acestora , semnificaia lor, mijoacele prin acre acetia pot fi combinai n termeni compui . Deoarece aceti termeni descriu att entitile care se gsesc n baza de adte ct

i cererile care se produc asupra acestora , formulrile , dat fiind transformrile care au fost produse , aduc cele dou intrri la posibilitatea real de comparaie asupra creia se acioneaz cu o funcie de apartenen . Entitile sunt indexate practic o singur dat , la introducerea n sistem , iar reprezentaeea indexri este expus n magazinul de informaii (depozitul de documente , setul DOCS) Noiunile de dat, informaie, baz de date, SGBD Scopul principal al contabilitii este comunicarea de informaii relevante indivizilor i organizaiilor, n scopul lurii deciziilor. Pentru a reui n actuala epoc a informaiilor, este imperios necesar nelegerea sistemelor informatice n general, i a celor care asigur suportul logistic al funciei contabile n special. n cadrul unui concept aprut n anii 80, n SUA, acela de management al resurselor informaionale (Information Resource Management), informaia este tratat ca o resurs, aidoma crbunelui, minereurilor i petrolului, doar c este o resurs avnd nite caracteristici mai speciale: 1. Informaia este o resurs rar, costisitoare pentru colectivitate; 2. Pentru a o administra , ea trebuie reperat, localizat, inventariat i actualizat. 3. Administrarea informaiei nseamn n primul rnd valorificarea ei, adic utilizarea aceluiai fond de informaii de mai multe ori, i nu numai de ctre acela care l-a colectat pentru nevoile proprii. Informaia are avantajul de a fi un bun care poate fi consumat - eventual de mai multe ori - fr a fi distrus. Aceast folosire repetat implic o comuniune de concepte i limbaj : informaia nu poate fi utilizat dect dac se atribuie aceeai semnificaie termenilor care o definesc. 4. Administrarea informaiei mai nseamn i adoptarea unui demers de revizuire sistematic a utilitii sociale sau economice a fondurilor de informaii. Aceasta pentru c, spre deosebire de resursele carbonifere sau petroliere, informaia nu ia natere de la sine, spontan.

Date Datele brute reprezint o colecie de numere v, caractere , imagini sau alte tipuri de ieiri provenite de la echipamente care convertesc cantitile fizice n simboluri , n cel mai larg sens . astfel de date sunt , n mod obinuit , procesate ulterior de ctree personal sau pot reprezenta (cazul cel des ntlnit) intrarea ntr-o aplicaie de calculator , unde sunt stocate i procesate , sau transmise ca ieire a procesului altor persoane sau aplicaii . Datele brute reptrezint un termen foarte relativ , procesarea datelor realizndu-se n mod obinuite pe mai multe nivele , astfel nct datele procesate de pe un nivel dat pot reprezenta date brute pentr nivelul superior. Termenii de informaie i cunotin sunt frecvent ntlnii pentru concepte care de multe ori se suprapun. Este dificil o diferenere tranant , principala caracteristic considerat fiind nivelul de abstractizare . Datele reprezint cel mai de jos nivel de abstractizare , informaia urmtorul , iar , n consecin conotinele cel mai nalt astfel de nivel . Exemplu nlimea Everestului este o dat , o carte referitoare la caracteristicile geografice i geologice ale Everestului , poate reprezenta o informaie , iar cele mai bune abordri ale escaladrii i cucerii acestuia o cunotin . Informaia ca i concept suport o diversitate de semnificaii , de la utilizarea termenului cotidian cu semnificaia uzual din limbajele naturale pn la foarte particulare argouri tehnice . n general conceptul de informaie este strns legat de noiunile : restricii , comunicaie , control , date , formuri , instruciuni , cunotine , semnificaie , abloane , percepie i reprezentare . Beynon-Davies [9] utilizeaz conceptual de semn pentru a distinge ntre date i informaie . datele sunt simboluri , informaia aprnd atunci cnd simbolurile sunt utilizate pentru un anumit scop . Datele reprezint caractere i imagini , sau alte metode de ntegistrare , ntr-un format care s poat fi evaluat de persoane sau (n mod special ) de calculatoare , stocate i procesate pe acestea , sau transmise pe un canal digital oarecare . Din acest punct de vedere datele nu au o semnificaie proprie , semnificaia aprnd numai cnd acestea sunt interpreatate ntr-o anumit manier de ctre un sistem de procesare a datelor care le confer astfel neles i prin acesta devenind informaii . Datele constau dintr-o serie de fapte sau specificri care pot au putut fi colectate , stocate , procesate i/sau manipulate , da care nu au fost palsate ntr-un context sau organizate pentru a susine unul. Odat cu organizarea n vederea susinerii unui context datele devin informaii . Informaiile pot fi procesate i utilizate pentru a proiecta concluzii generale sau cunotine . (1) Tehnic vorbind , datele sunt date sau cifre , cum ar fi ordine de plat sau pli , care sunt procesate n informaii , cum ar fi balanele de verificare . astfel , n terminologie curent , de multe ori termenii de date i ninformaii se utilizeaz n sinonimie.

(2) Orice form de informaie fie pe suport hrtie , fie pe suport electronic . Datele pot referi orice fiier pe suport electronic indiferent de formatul acestuia : baze de date , text , imagine audio , video . Tot ce este scris i citibil pe un calculator poate fi considerat ca date , cu excepia instruciunilor constituite ntr-un program care sunt executate. (3) Se poate face reducerea numai la datele coninute ntr-o baz de date ca diferenire de textukl coninut ntr-un document procesabuil word.

Baza de date Accepiunea general refer orice form de agregare de date ; de obicei o colecie masiv de date care au fost formatate n baza unor standarde utilizator . Sunt mai mult progrqame care utilizeaz datele n baze de date , dintre care Access , Oracle , IFMIX i SQL Datele , din punctul de vedere al industriei informaiei , refer elemente distincte de informaie , de obicei formate de o anumit manier . Toate sistemele de informaii mbrac , de o manier sau alte dou mari categorii : date i procesarea acestora(programe) datele pot exista n foarme diferite forme ca numere sau texte pe buci de hrtie , ca bii i ca bytes stocai n memoria electronic , sau pur i simplu ca fapte stocate n memoria (mintea) persoanei . Priogramele , la rndul lor vor referi colecii de instruciuni inteligibile procesorului , pentru manipularea datelor , care pot fi instruciuni calculator (pentrun procesarea automa a datelor) sau instruciuni cae se adreseaz fiinei umane , pentru procesarea manual . O alt definiie (Hornung) refer datele a un set de reprezentri strcturat i formal a informaiei , adecvat comunicaiei , interpretrii i procesrii acestora . Informaie Informaia se poate defini ca rezultatul aplicrii procesrii datelor , datelor inselor , dndu-le acestora context i semnificaie . Informaiile pot fi procesate mai mult pentru a produce cunotine . Persoanele sau calculatoaree pot regsi n date abloane pentru percepia informaiei , iar informaiile la rndul lor pot fi utilizate pentru a mbunti conotinele . deoarece conotinlele sunt precerine pentru judeci , se vor dori din ce n ce mai multe date i informaii . Dar , deoarece , societaea contemporan tinde spre o supra ncrcare cu informaii , trebuie gte cel ami bune abloane . (Krippendorff) Informaia msoar gradul de incertitudine . Un mesaj este purttor de informaie numai n msura n care conine lucruri necunoscute .

Informaie este un stimul care are semnificaie , ntr-un context dat pentru receptor . Cn informaie este agrefat sau este utilizat pentru a a nelege sau a face ceva yaceasta este cunoscut sub numele de cunoti . Cunotine Obiectele , conceptele i relaiile considrate a fi ntr-un domeniu de interes dat . O colecie de cunotine reprezentat prin intermed unui limbaj de repezentare a cunotinelor este cunoscut ca baz de cunotine , iar o aplicaie pentru extinderea i/sau interogarea unei baze de cunotine este un sistm bazat pe cunotine . Cunotinele se difereniaz de date sau informaii prin aceea c noi cunotine pot fi create pornind de la cunotine vechi prin inferene logice . Dac se poate condidera c informaia este date + semnificaie , conotinele sunt informaie + procesare . O alt definiie : cunotinele constau din declaraii conceptuale generalizate care au fost realizate printr-o analiz a informaiilor . i n fine , chiar dac este mai puin formalizat , dsefiniia de mai jos pare a fi mai funcional : n tehnologia informaiei , cunotina este , pentru o intreprindere sa o persoan posesia informaiei sau abilitatea de a o localiza rapid . n contextul intreprinderilor economice sau al utilizrii proprii a calculatorului , conotaia cunotinei refer cu precdere posesia de know-how , sau de informaii faptice sau unde acestea pot fi gsite . Intreprinderile i trateaz astfel propriile cunotine ca investiii i pentru gestiunea acesteia ii realizaez propriile planuri i aplicaii n acest scop. O serie de aplicaii noi , ca tipologie , numite data meaning (semnificaia datelor) i propune s dezvolte i s constituie cunotine din procesarea datelor aferente tranzaciilor la nivelul intreprinderii , acumulate i agregate i a altor date specifice . Baza de date Obiective 1. recunoaterea claselor mari de baze de sisteme de baze de date i recunoaterea unei largi varieti de sisteme de baze de date 2. lmurirea ctorva diferene nttre sistemele de gestiune a bazelor de date i sistemele de regsire a informaiei , n termeni de cerine care se adreseaz stocrii datelor i procesrii acestora 3. explicarera relaiilor care apar intre date i informaii i ntre date i software Se pot ua n considerare dou mari clase : Sistemele de gestiune a bazelor de date (DBMS) i Sisteme de regsirea a datelor (IRS) . n consecin au fost analizate scopurile i structura acestora prin prezentatea caracteristicii bazei de date de unde aceste sisteme deriv : a. necesitile organizaionale b. cerinele datelor cpe acre le stocheaz c. cerinele procesrilor care se manifest asupra datelor prin aplicaii care produc informaii

Bazele de date pot fi definite , n general i provizoriu ca fiind colecii de date care existp cu scopul declarat de a produce informaii . Datele , mpreun cu sistemul care le gestioneaz sunt definite ca fiind sistul de gestiune al bazei de date . Aceasta aare ca o definiie genral i oate chiar surprinde . Mai mult , toate bazele de date pot fi partajate pest6e o reea sau reele de calculatoare . Atand acestui sistem o pot electronic , un sistem de admnistrare a privilegiilor se ajunge rapid la definirea unui birou , integrat , n spaiul virtual . nc pe acest nivel de generalitate al definiiilor sistemele de baze d adte pot fi att manuale ct i manifestante n spaiul virtual . Acestea rmn valide pentru ceel dou mari tipuri de baze de date ODBMS i IRS . Sistemele de baze de date i nevoile organizaionale Este important s se fac distincia ntre baza de adte cae este o colecie de date i sistemul bazei de adte care este constituit din toate componentele care copereaz pentru colectarea datelor , manipuleaz , gestioneaz i livreaz informaiile . Aa cum este de ateptat exist mai multe (chiar multe) sisteme de baze de adte . Printre acestea amintim ODBMS , IRS , sisteme de hipertext , sisteme expert , baze de cunotine , baze de elemente multimedia , biblioteci , fiind doar o parte dint gama de produse specilizate oferite de actualele tehnologii . n abordarea de fa , calarea se va produce asupra primelor dou categorii enunate , cu precdere asupra aa numitelor baze de adte relaionale , acestea fcnd directa referire a coninutului cursului . O DBMS este un sistem complex de baze de date care : 1. gestioneaz stocarea , nteinerea i regsirea datelor 2. asigur faciliti de programare (un editor , un limbaj de programare ) pentru a produce aplicaii specifice consumatorului de informaii 3. ofer un numr de instrumente pentru a crea obiecte ale bazei de date cum ar fi fiiere de date , formuri de ecrane i definirea de rpoarte printabile 4. ofer limbaje pentru exprimarea ad-hoc de cereri la baza de date i asigur rspunsul lizibil al rezultatului procesri n consecin . 5. gestioneaz accesul actorilor multipli (fie persoane (utilizatori) , fie aplicaii (programe)) la un depozit comun de date Noiunea de program se va defini ca entitatea elementar de procesare care prin agregare i mixare cu alte obiecte se constituie ntr-o aplicaie (cu semnificaie pentru utilizator ) gata de rulare , particular sistemului de gestiune a bazei de adte pentru ndeplinirea unui set specific , predefinit de sarcini. O stfel de combinaie de limbaje de programare pentru baze de date , instrumente pentri prezentarea , printarea i colectarea datelor , la care se mai adaug un limbaj de cereri interactiv este , n mod obinuit referit ca 4GL. DBMS uri cum ar fi Access , Oracle , Informix etc . sunt sisteme de baze de date de uz general , a cror puncte tari i puncte slabe vor fi didcutate n continuare . IRS (cunoscute de asemenea i sub numele de sisteme de regre text) sunt priectate pentru a facilita regsirea n cntextul inundrii cu informaii text n intreprindere , care au fost generate cu procesoare word sau au fost importate dein alte baze de date de tip text . n genera aceste IRS sunt integrate cu produsele de automatizare a activtilor de birou : procesoare de imagine , tabloare , procesoare text , baze de documente , baze de date , mail , comunicaie etc.

DBMS exceleaz la procesarea datelor care sunt bine structurate . Gestiunea datelor structurate este la fel de veche ca i utilizarea calculatoarelor nsele . Multe companii , nc , rmnnd ntr-un grad de integrare sczut i gestioneaz propriile adte structurate prin DBMS , tabloare i pachete de programe pentru contabilitate . n contextul DBMS unitatea elementar de date care nc are semantic este nregistrarea . nregistrarea corespunde unei entiti din lumea real presupus a avea un numr fix de atributa (sau proprieti) care sunt de interes . Fiecare astfel de atribut este caracterizat , la rndul lui de o valoare (eventual limitat domeniul de valori acceptate de sistem) . Astfel rin date puternic structurate se va nelege datele ale cror pri sunt predictibile sau regulate . De exemplu un registru de comenzi va trebui s conin ntr-o astfel de aplicaie DBMS atribute cum ar fi : numr comand , furnizor , data comenzii , valoarea comenzii , departamentul care finaneaz . n mod normal , pentru fiecare entitate fiecare dintre aceste atribute vor aea una sau mai multe valori . O nregistrare DBMS este o abstractizare a obiectelor din lumea real ma atrbutelor care sunt de interes pentru organizaie (departament, echip etc.) . Cu ct compania este mai implicat cu att setul specificat de atribute abstractitzate se constituie n entiti arhetipale , vizn esena lucrurilor ( evident o abstractizae care , trecnd peste detalii , pstreaz substana caracterizand). n cazul unei companii cea mai mic entitate cu semnificaie se va numi , n continuare nregistrare . Fiecrui atribut al nregistrrii , entitate elementar , i se asociaz o valoae . Despre caracterizarea atributelor se va discuta mai apoi , dar este de menionat c asupra valorii atributului se pot face o serie de ipoteze : valoarea s se ncadreze ntr-un interval specificat , valoarea este de un anumit tip , corespunztor unitii de msur etc . Aceasta implc o identitate ( identitate pn la izomorfism , cum ar defini-o matematicienii ) a diferitelor entiti de acelai tip , acestea diferind ntre ele prin forma de manifestare (valorile pe care le iau atributele) . Se poate spune , deci, c structura unei nregostrri din baza dse date implic anumite atribute eseniale (ne-accidentale ) care sunt prezente n fiecare entitate . O entitate particular va avea valori proprii pentru aceste atribute , iar aceste valori vor da forma accidental (instanierea) respectivei nregisrri. Prin contrast , un sistem de regsire a informaiei , a fost proiectat pentru a procesa (i n particular pentru a regssi ) nregistrri textuale . Organizarea intern a celor mai multe entiti textuale se plaseaz de la foarte puternic structurate , pn la lipsa structiurii ( nestructurate ) Multe dintre informaiile provenite din lume areal nu pot fi captate ntr-o form structurat , clar definit ca set de atribute . Acolo unde exist o anumit structurare , de obicei se pot utiliza o baz de date de vocabular a entitilor i atributelor . Dezvoltarea vocabularelor ca modalitate de structurare , similar cu vocabularele limbilor naturale vor avea o semnificaie deosebit n seciunile urmtoare . Sisteme de baze de date i procesarea datelor Arhitectura oricrui tip de sistem de baze de date a fost dezvoltat ca rspuns att provocarea evoluiei rapide a cerinelor de la date ct i la provocarea i mai spectaculoas a evoluiei procesrilor acestora . ntr-adevr se poate gndi baza de date ca avnd dou componente semnificative : o component static datee i o component

dinamic programele(procesrile ) care opereaz asupra acestora pentru a produce informaie . Un astfel de proces poate fi privit ca o aciune care urmeaz instruciunile redactate ntrun program pentru manipularea datelor n folosul utilizatorului (consumatorului rezultatelor serviciului sau mai pentru simplificare : consumatorul serviciului). n termeni de mulimi , programul transform (reprezint ) mulimea (setu) de date de intrare in mulimea datelor de ieire . O parte dintre aceste programe vor fi cu totul transparente utilizatorului , care ndeobte nici nu are contiina existenei lor. Acetea din urm includ in general programele care gestioneaz i protejeaz fiierele fizice , sau construiesc , selecteaz i utilizeaz indeci , sau administreaz accesul utilizatorilor multipi . Acest serie de programe este denumit i va fi cunoscut astfel ca administartorul bazei de date . Alte tipuri de pograme intefaeaz cu utilizatorul n mod direct . Acestea se vor cuprinde n urmtoarele categorii : - aplicaii - facilitai ale bazei de adte : un limbaj interactiv de invocare a bazelor de date cum ar fi SQL (structured qoerz language ) care a devenit nc de mult veme un standard n acest sens. DBMS apar n consecin ca un rspuns funcional la cerinele vieii economice i a nevoilor imediate ale intreprinderilor . Sunt utilizate pentu consrucia structurii i funcinalitii datelor cuprinse n bazele de date , organizate de maniera posibilitii aplicrii asupra acestora de aplicai . Este important de reinut c utilizatorii bazelor de date , prin intermediul aplicaiilor sau a simplelor cereri pot fi de la persoane cu abiliti foarte slabe n aciuni asupra bazelor de adte pn la exoeri n tehnologia informaiei . este important ca aplicaiile astfel construite s poat aigura accesul funcional i eficient a tuturor participanilor (actorilor) n consecin DBMS sunt rogramabile i aceasta permiet realizatorilor acestora s dezvolte aplicaii care se adreseaz unui utilizator calat pe propriile activiti i rspunderi . Pe e alt aprte DBMS se adrseaz i unor utilizatori specializai crra trebuie s fie capabil s le ofere interfee interactive (orict de sofisticate) pentru realizarrea de rapoarte , ecrane i construirea de fiiere din mers. DBMS sunt poate cele mai adecvate entiti utilizate la administrareanregistrrilor puternic structurate , precum i a nregistrrilor slab structurate sau chiar nestructurate i a invocrilor ad hoc . Astfel DBMS trebuie s ofere utilizatorului final unul sau mai multe limbaje de invocare care s-i permit acestuia regsirea interactiv a informaiei . Aa cum a fost deja prezentat , SQL este unul dintre astfel de limbaje , standardizat i utilizat pe o scar foarte mare , cae chiar fiind de o fiind de o mare simplitate conceptual , necesit totui o instruie semnificativ a utilizatorului fiunal ceea ce-i poate provoca acestuia angoase. Spre deosebire de bazele de date specifice relaionalului , IRS rspunde altor cerine de procesare : - capacitatea de a stoca ntregul test al fiierelor - icapacitatea de a importa documente n diferite formate - s regseasc nu numai nregistrrile care pot fi unic identificate , probabil printr-un cod (cheie) ci i seturi de nergistrri care sunt

similare cerinelor specificate n cerere , care pot fi la rndul lor reglate prin lrgirea sau micorarea criteriilor de cutare - cutare de o amier ad hoc - permiterea uneri strategi de cutare cu progres euritic i cu trase ale cii utilizate . Utilizatorii informaiei acestor sisteme se regfsesc printre profesiitii unui domeniu de actvitate al organizaie , cu abiliti n TIC relativ mici . Astfel utilizatorul final i mparte din ce n ce mai mult sarcinile legate de ITC cu furnizorii profesioniti de servicii aferente . n consecin sistemele IRS sunt numai n parte programabile , dispun de interfee configurabile i de cele mai multe ori au capacitatea unor faciliti sofisticate de cutare . Accepiunea general refer orice form de agregare de date ; de obicei o colecie masiv de date care au fost formatate n baza unor standarde utilizator . Sunt mai mult progrqame care utilizeaz datele n baze de date , dintre care Access , Oracle , IFMIX i SQL Datele , din punctul de vedere al industriei informaiei , refer elemente distincte de informaie , de obicei formate de o anumit manier . Toate sistemele de informaii mbrac , de o manier sau alte dou mari categorii : date i procesarea acestora(programe) datele pot exista n foarme diferite forme ca numere sau texte pe buci de hrtie , ca bii i ca bytes stocai n memoria electronic , sau pur i simplu ca fapte stocate n memoria (mintea) persoanei . Priogramele , la rndul lor vor referi colecii de instruciuni inteligibile procesorului , pentru manipularea datelor , care pot fi instruciuni calculator (pentrun procesarea automa a datelor) sau instruciuni cae se adreseaz fiinei umane , pentru procesarea manual . Un sistem de gestiune a bazelor de date (SGBD) este un sistem complex de programe ce asigur interfaa ntre utilizator i baza de date. Sistemul de gestiune reprezint software-ul propriu-zis al bazei de date, care asigur realizarea urmtoarelor activiti: definirea structurii bazei de date; ncrcarea bazei de date; accesul la date (interogare, tergere, modificare i indexare); ntreinerea bazei de date (colectarea i refolosirea spatiilor goale, refacerea bazei de date n caz de incident) reorganizarea bazei de date (restructurarea i modificarea strategiei de acces) securitatea datelor. SGBD-ul este format din programe. Perspective pentru sistemele de gestiune a bazelor de date Actualmente, alturi de baze de date clasice, ce memoreaz date de tip numeric, alfanumeric, eventual dat calendaristic i logic, se nasc noi tipuri de baze de date, apte s pstreze documente, cu tabele, diagrame, grafice i chiar secvene de program nglobate. Mai mult dect att, toate aceste documente pot fi partajate ntre utilizatori n cadrul unei reele sau n cadrul mai multor reele de calculatoare. Dac la acestea se

adaug un sistem de post electronic i se numete un administrator de sistem care gestioneaz un sistem de drepturi de acces, iat-ne ajuni n pragul unui birou automatizat. Dar e tot un fel de baz de date ! Bazele de date pot fi memorate pe diferite suporturi de informaie. O simpl plac video adugat pe un PC , creeaz posibilitatea redrii pe ecran a imaginilor preluate de o camer video, sau de la un video recorder sau video-disc, sau transmise de televiziunea prin cablu. n cadrul sistemelor multimedia, utilizatorul poate crea i parcurge pagini nlnuite, exact ca ntr-o carte clasic. Se pot consulta anumite pagini, cuprinsul, indexul, notele de subsol, exact ca pentru o carte obinuit. n pagini pot exista text, grafic i imagini video inserate acolo de "autorul" crii. Aceste aplicaii, numite i aplicaii hipertext, pot fi privite i ele ca sisteme cu baze de date. De asemenea, sistemele informatice geografice (GIS), care memoreaz informaii de tip cartografic, au o organizare de tip sisteme cu baze de date, doar c n acest caz, fiecare element al hrii este considerat un obiect distinct i tratat ca atare. Obiectivele unui SGBD n proiectarea i realizarea sistemelor de gestiune a bazelor de date , se ine cont de o serie de deziderate, care constituie obiective de urmrit: 1. Asigurarea independenei datelor de programe. Modificarea structurii datelor sau a strategiei de acces nu trebuie s aib nici un fel de implicaii asupra programelor de aplicaie. Diferite aplicaii trebuie s poat utiliza viziuni diferite ale acelorai date, iar modificarea structurii trebuie s fie oricnd posibil, fr alte implicaii. Exist dou perspective asupra independentei datelor: independenta fizic i cea logic. Independena fizic a datelor face ca modul de memorare a datelor i tehnicile fizice de memorare s poat fi modificate fr s fie necesar rescrierea programelor de aplicaie. Independena logic a datelor se refer la posibilitatea de a aduga noi articole sau de a extinde structura conceptual (global) a bazei de date fr a fi necesar rescrierea programelor existente. 2. Asigurarea unei redundane minime i controlate a datelor din baza de date. Stocarea datelor n baze de date presupune memorarea fiecrei date o singur dat, afar de situaiile cnd memorarea repetat este determinat de necesitatea realizrii unei performane superioare n ceea ce privete timpul de acces la date i timpul de rspuns. 3. Asigurarea unor faciliti sporite de utilizare a datelor. Aceasta presupune: folosirea datelor de mai muli utilizatori n diferite scopuri; accesul ct mai simplu al utilizatorilor la date, fr a fi necesar cunoaterea structurii ntregii baze de date; existenta unor limbaje performante de regsire a datelor , care permit formularea de interogri acces multicriterial la nregistrrile bazei de date. utilizarea unui limbaj de interogare interactiv, ct mai apropiat de cel natural. 4. Sporirea gradului de securitate a datelor mpotriva accesului neautorizat . 5.Asigurarea integritii datelor mpotriva unor tergeri intenionate sau neintenionate. 6. Asigurarea partajabilitii datelor - ntre mai muli utilizatori, dar i ntre mai multe aplicaii.

Componenta software: Sistemul de gestiune a bazei de date (SGBD, DBMS). Realizeaza administrarea datelor memorate propriu-zis.

a. Utilizatorii:

Funciile unui SGBD

1. Funcia de descriere a datelor permite definirea structurii bazei de date. Rezultatul acestei funcii este schema bazei de date. n cadrul ei se definesc cmpurile din cadrul structurii, legturile dintre entiti, criterii de validare a datelor, metode de acces. 2. Funcia de manipulare a datelor realizeaz urmtoarele activiti: crearea(ncrcarea) bazei de date; adugarea de noi nregistrri ; suprimarea unor nregistrri; modificarea valorilor corespunztoare unor cmpuri; cutarea, sortarea i editarea unor nregistrri. 3. Funcia de utilizare asigur mulimea interfeelor necesare pentru comunicarea tuturor categoriilor de utilizatori cu baza de date. Categoriile de utilizatori sunt: utilizatori finali (end-user)- acetia utilizeaz programe gata scrise sau limbaje de interogare; utilizatori programatori - al cror acces se bazeaz pe proceduri complexe de exploatare a bazei de date; administratorul bazei de date. 4. Funcia de administrare a bazei de date-apare ca o funcie complex i este de competena administratorului bazei de date, care poate fi o persoan sau un grup de persoane, cu o bogat experien n activitatea de analiz, proiectare i programare. Administratorul rspunde de toate activitile i operaiile referitoare la baza de date pe care o gestioneaz, precum i de performanele ntregului sistem implementat. Sarcinile ce revin administratorului bazei de date, se refer la :

a) n etapa de concepie a bazei de date: definirea obiectivelor sistemului informatic, definirea cerinelor de aplicaie, definirea i descrierea datelor; definirea dicionarului de date; definirea structurii virtuale , i mpreun cu inginerul de sistem, a structurii fizice a bazei de date; stabilirea procedurilor de validare a datelor; elaborarea concepiei de protecie i securitate a datelor; stabilirea procedurilor de validare a datelor; elaborarea concepiei de protecie i securitate a datelor; b) n etapa de implementare a bazei de date: definitivarea documentaiei de sistem; definirea tacticii i strategiei de implementare; asigurarea ncrcrii bazei de date; testarea programelor i evaluarea performantelor bazei de date; c) n etapa de exploatare i meninere n funciune: autorizarea accesului la baza de date; asigurarea proteciei i securitii datelor; asigurarea utilizrii raionale a suporturilor fizice rezervate bazei de date; asigurarea funcionrii bazelor de date la nivelul de performan prestabilit. Entiti, articole, cmpuri, atribute. Tipuri de date Bazele de date clasice au urmtoarele caracteristici: o baz de date conine date referitoare la entiti .O entitate este un obiect concret sau abstract reprezentat prin proprietile sale . Exemple de entiti: student, carte, tren, tranzacie. Fiecrei entiti i corespunde n baza de date un articol (nregistrare). articolele conin atributele sau caracteristicile entitilor, numite cmpuri. Exemple de cmpuri: numele studentului, adresa, media anilor de studii etc. Fiecare atribut este caracterizat de natura valorilor pe care le poate lua: numerice, alfanumerice, data calendaristic , logice. datele din fiecare cmp trebuie s se supun unor restricii ce trebuie definite, referitoare la lungimea cmpului (n caractere) sau la valorile pe care le poate lua. articolele pot fi complexe, dar structura lor este bine definit i este unic- toate articolele conin aceleai cmpuri. Acest tip de organizare corespunde marii majoriti a datelor ce trebuie incluse n baze de date. Totui , mai exist i alte tipuri de date: date de tip text, folosite pentru a detalia informaii imposibil sau foarte greu de codificat. cuvinte-cheie, care au avantajul libertii textului , dar i dezavantajul impreciziei. date de tip regul- folosite n tehnologia sistemelor expert, acestea presupun preluarea cunotinelor de la experi dintr-un anumit domeniu i stocarea acestei expertize ntr-o form care poate fi a regulilor, cadrelor, reelelor neuronale etc. Regulile pot fi
memorate ntr-o baz de date clasic, pentru c la o analiz detaliat, reiese c ele au o structur fix: "Dac

perioada de omaj este mai mic de 1 an , atunci omerul primete ajutor de omaj" (dac premiz, atunci concluzie). Totui, ele nu reprezint fapte, ca datele clasice: "Popescu este economist". date de tip grafic; date de tip imagine animat; date de tip voce; date de tip secven audio.

Structura datelor Structura datelor se refer la natura datelor organizate n baza de date, fr s dea nici un fel de indicaii referitoare la cum se face accesul la ele. ns structura i accesul sunt intim legate, pentru c o structur greit proiectat poate duce la un acces greoi. n tehnologia modern a bazelor de date se afirm c o baz de date trebuie vzut din trei perspective diferite: Structura logic a datelor se refer la forma n care fiecare utilizator vede structurarea datelor n funcie de aplicaia pe care ncearc s o realizeze. Structura logic este numit SUBSCHEMA BAZEI DE DATE. Structura virtual se refer la definirea structurii datelor din baza de date, astfel nct aceasta s satisfac cerinele tuturor utilizatorilor n condiii de redundant minim i controlat a acesteia. Aceast structur poart denumirea, de SCHEMA CONCEPTUALA A BAZEI DE DATE. Structura fizic se refer la modul de memorare i structurare a datelor pe suportul fizic. Detaliile tehnice necesare pentru a asigura punerea n practic a schemei conceptuale fac obiectul unui alt document, numit schema intern. Pentru transpunerea unei colecii de date din lumea real ntr-o baz de date, este necesar un model de date. Dintre modelele de date existente, amintim: A. Modelul entitate-asociere: B. Notiunile de baza sunt: entitatea; asocierea; (atributele). A. Definitie (neinformala): O entitate este orice ce poate fi deosebit de restul inconjurator: obiect, eveniment, rol, etc. Orice entitate este descrisa prin atributele sale care se selecteaza pe principiul relevantei: atribute relevante. O entitate este descrisa prin valori ale atributeler. Toate entitatile care pot fi caracterizate prin acelasi set de atribute pot fi grupate intr-o multime de entitati (contine entitati de un tip dat). Tipul entitatii il caracterizam prin atributele corespunzatoare. O entitate dupa definirea tipului ei devine o instanta a tipului de entitate. Asocierile (def formala) relationship: reprezinta modul in care pot fi asociate (puse in corespondenta) doua sau mai multe multimi de entitati. Putem avea asocieri:

binare: doua multimi de entitati K-are (multiple): K>2, ternare,

In proiectarea BD este necesar sa fie definite categoriile de asocieri: a. asociere unul-la-unul (1:1): este o asociere in care unui element (entitati) din multimea E1 ii corespunde un singur element (entitate) din multimea E2 si reciproc; b. asociere unul-la-multe (1:N): unui element din multimea E1 ii corespund mai multe elemente din multimea E2 , pe cand unui element din multimea E2 ii corespunde doar un element din multimea E1; c. asociere multe-la-multe (M:N): unui element din multimea E1 ii corespund mai multe elemente din multimea E2 si invers;

Numarul acesta de asocieri se numeste multiplicitate sau cardinalitate. O asociere binara prezinta doua valori de cardinalitate, raportul celor doua valori reprezinta raportul de cardinalitate (1:1, 1:N, M:N). Tipuri de asociere:

1:1 ; 1:N ; M:N .

Asocierile K-are (K>2) au K valori ale cardinalitatilor (de multiplicitate), cate una pentru fiecare multime de entitati. B. Definitie (mai precisa): Tip de entitate, multimea entitatilor (de acelasi tip) si o entitate = instanta a tipului. Pentru asocieri se definesc:

un tip al asocierii; instanta a asocierii; multimea tuturor instantelor folosind o multime a unui tip de asociere.

Definitia tip de asociere: Fie E1, E2,, En multimi de entitati, fiecare corespunzand unui tip de entitate. Un tip de asociere R={ri}este format dintr-o multime de instante ale acestui tip ri, unde ri este un triplu compus din elemente ri=(e0, e1, , ej, , en), ejEj. Proprietati:

fiecare instanta a asocierii pune in legatura (asociere) exact cate un element din multimile de entitati date; un tip de asociere este o submultime a produsului cartezian a submultimilor de entitati pe care le pune in corespondenta. Este doar o submultime din cauza constrangerilor impuse de raportul de cardinalitate.

Raportul de cardinalitate (asocieri binare) ne da numarul de instante ale asocierii (de un tip dat) in care poate participa o entitate dintr-o multime data. O relatie Ra cu raportul de cardinalitate 1:1 impune conditia ca orice element din E1 sau E2 sa participe intr-un singur element (instanta) a tipului de asociere. Un tip de asociere Rb cu raportul de cardinalitate 1:N impune conditia ca un element din E2 sa participe intr-o singura instanta iar un element din E1 sa participe in N instante. O asociere intre doua multimi de entitati este si o asociere intre tipul de entitati.

Diagrama E-A: pentru reprezentarea modelului entitate-asociere. Notatii:

Atributele se reprezinta prin elipse care contin numele si se leaga de tipul de entitate. Notatie pentru entitati (tip) puternice (numele) sau entitati slabe (dependente):

Diferenta consta in faptul ca entitatile puternice se pot identifica in realitatea modelata direct, pe cand entitatile slabe nu pot exista decat asociate cu alte entitati (tipuri) puternice. Tipul asocierii binare: Poate avea un nume si are multiplicitatile scrise conform raportului de cardinalitate al multimilor. Se reprezinta astfel:

Tipul asocierii > 2:

Exemplu de diagrama E-A: Tipuri de entitati:

entitati puternice: a. tipul de entitate sectie SECTIE (SECTII); Atribute: Numar,Nume,Buget; b. tipul de entitate angajat ANGAJAT; Atribute: Nume, Prenume, Data nasterii, Adresa,Functia, Salariu; c. tipul de entitate proiect PROIECT Atribute: Nume, Data incepere, Buget

entitati slabe: a. tipul de entitate dependent Atribute: Nume, Grad rudenie, Varsta

Tipuri de asocieri: le definim astfel incat sa corespunda realitatii modelate:

SECTIE-ANGAJAT 1:N (o sectie contine mai multi angajati dar un angajat apartine unei singure sectii): poate avea si un nume (A); ANGAJAT-PROIECT M:N, daca se admite ca un angajat sa lucreze la mai multe proiecte; ANGAJAT-DEPENDENTE (1:N).

Obs:

Fara sa fie o regula, din punct de vedere semantic entitatile (tipurile) se reprezinta cel mai bine prin substantive, pe cand asocierile se reprezinta din punct de vedere al intelesului prin verbe:
o o o

o sectie cuprinde mai multi angajari; un angajat intretine mai multi dependenti; mai multi angajati lucreaza la mai multe proiecte.

Pentru aceeasi activitate se pot identifica si apoi dezvolta diferite tipuri de entitati si de asocieri => modele (diagrame E-A) diferite

Granita dintre entitati si asocieri nu este una precisa. De exemplu:

Acesta a fost modelul E-A initial. Cu timpul s-a dezvoltat Modelul Entitate-Asociere extins. In plus apar ierarhii de tipuri de entitati. Ierarhiile se creeaza: a. prin specializare, in care, pornind de la un tip de entitate dat, se creeaza unul sau mai multe tipuri de entitate; b. prin generalizare, in care, pornind de la mai multe tipuri de entitati se poate defini un supertip, prin abstractizare. Aceste tipuri sunt legate intre ele prin relatia de mostenire (atributele se mostenesc); se creeaza ierarhii de tipuri si subtipuri.

Exista diferente de interpretare: Ierarhiile de tipuri de entitati sunt realizate in E-A prin asocierea cu raportul de cardinalitate 1:1. Exemplu: ANGAJAT (Nume, Prenume,): putem defini subtipuri pentru a deservi activitati specifice: SECRETARA, TEHNICIAN, INGINER. Fiecare subtip mosteneste atributele tipului de baza ANGAJAT. Subtipul mai contine si atribute specifice: a. SECRETARA (Viteza redactare); b. TEHNICIAN (Grad, Calificare); c. INGINER (Specialitate). Asemanarea dintre OO si E-A extins: b. dpdv al mostenirii in faza de definire a atributelor;

c. dpdv al instantierii tipurilor si subtipurilor apare o deosebire intre modelul obiectorientat si modelul E-A: in modelul E-A, pentru fiecare instanta a unui subtip din realitatea modelata corespund doua sau mai multe instante si anume o instanta din subtipul respectiv si cate o instanta din supertipurile subtipului.

Diagrama de instantiere a diagramei asociere reprezentate:

B. Modelul ierarhic: acesta presupune stabilirea unei ierarhii; datele sunt descompuse n segmente la diferite nivele ale ierarhiei, n aa fel nct orice nregistrare de pe un nivel inferior nu poate avea dect un singur printe; de exemplu, catalogul de clieni la rdcina ierarhiei, apoi , legat de el , date despre comenzi-produse, istoricul vnzrilor, livrri, etc. Din pricin c n realitate, relaiile dintre date sunt mult mai complexe dect acelea ierarhice(printe-fiu), s-a trecut la urmtorul model, care nltura o parte din aceste restricii.

Notiunile de baza:

existau inregistrari, fiecare fiind de un anumit tip, si fiecare tip era caracterizat printr-un numari de campuri ce contin valori ale atributelor;

link-uri (legaturi): se admit legaturi intre tipurile de inregistrari care realizeaza o asociere de tip parinte-fiu astfel incat schema conceptuala a unei bd ierarhice este un arbore directionat ale carui noduri sunt tipurile de inregistrari iar arcele sunt legaturi cu raportul de cardinalitate 1:N (1:1).

C. Modelul reea: se bazeaz tot pe o structur ierarhic, dar permite i conexiuni pe acelai nivel, precum i ca un "fiu" s aib mai muli prini. O baz de date reea const din dou seturi de date, un set de articole i un set de legturi, n cadrul crora articolele sunt alctuite din cmpuri. D. Modelul relaional se bazeaz pe relaii (tabele). Conform teoriei relaionale, reprezentarea oricrei structuri de date poate fi redus, acceptnd o anumit redundan, la una sau mai multe tabele bidimensionale cu legturi ntre ele.. Tabelele trebuie astfel construite nct s nu se piard informaii de legtur. Unei multimi de entitati din modelul de nivel inalt E-A ii corespunde o relatie (relation). Un atribut al unui tip de entitati este reprezentat prin notiunea de atribut, cu precizarile:

un atribut este definit pe un domeniu de definitie; domeniul de definitie, in sens relational:

o o o o

este o multime de valori; are un nume; valorile sunt de acelasi tip si au aceeasi semnificatie; valorile sunt atomice.

Atomic: indivizibile din punct de vedere semantic (al intelesului). Chiar daca o valoare este reprezentata prin mai multe elemente (ex, sir de caractere), aceste elemente nu au un inteles de sine statator. Definitia 1 a relatiei

Schema relatiei: o lista ordonata de atribute R(A1,A2,,An), reprezentata printr-o schema a relatiei in care R este numele schemei relatiei iar A1,A2,, An reprezinta o lista ordonata de atribute. Fiecare atribut poate sa ia valori dintr-un domeniu de definitie propriu D(AI). Shema relatiei defineste un tip de date: tipul relatie (intensiunea relatiei).

Relatia R, definita de schema R(A1,A2,,An) este o multime de n-tupluri, fiecare tuplu fiind o lista ordonata de valori vi (unde vi este valoarea atributului i si ia valori in domeniul D(AI): t=<v1,v2,,vn> Exista o corespondenta: in modelul E-A: multime de entitati, iar in modelul relational: relatie. O entitate din multimea de entitati corespunde unui tuplu al relatiei. Fiecare tuplu e format din valori ale atributelor, cu aceeasi semnificatie ca in E-A. Observatie: Domeniile atributelor nu sunt neaparat distincte: a. Intr-o relatie nu exista tupluri duplicat!. (doua sau mai multe tupluri cu aceleasi valori ale tuturor atributelor in aceeasi ordine), deoarece relatia este multime in sens matematic. b. Un atribut ia o singura valoare, atomica, intr-un tuplu dat (atributele au valori scalare, nu se admit valori cu vectori). Relatie normalizata: modelul relational pentru BD se ocupa doar de relatia normalizata, ce reprezinta proprietatea de mai sus (altfel spus, este in forma normala 1: FN1).

BD relationala: formata dintr-o multime de relatii in care nu exista doua relatii identice (nu exista doua relatii cu acelasi nume, numele fiind de cele mai multe ori identic cu numele schemei relatiei).

Terminologie:

Gradul (n)=numarul de elemente; Cardinalitatea unei relatii: numarul de tupluri; Tipul relatiei: dat de schema relatiei, R(A1,A2,,An); Variabila relatie: relatia R, ia anumite valori ce se modifica in timp. Se mai numeste si extensiunea relatiei).

Observatie: Tuplurile relatiei nu sunt neaparat ordonate: modelul relational nu presupune nici o ordine.

Definitia a 2-a relatiei Atributele dintr-o schema de relatie nu trebuie neaparat sa fie ordonate.

Schema relatiei: R={A1,,Ai,,An}, o multime de atribute; Relatia R, o multime de n-tupluri, t, fiecare tuplu fiind o multime de perechi ordonate t={<v1,A1>,<v2,A2>,,<vn,An>}. <vi,Ai>=<valoare, atribut>

Reprezentarea relatiilor prin tabele: Tabelul este o reprezentare vizuala a unei relatii:

Un tabel: are un nume, identic cu numele relatiei; este format din coloane (atribute) si linii (tupluri). prima linie e capul tabelului si contine numele atributelor relatiei, iar celelalte linii contin valori ale atributelor.

Tabelul corespunde unei anumite valori a relatiei R la un moment dat. Tabelul de reprezentare al unei relatii pare ca ar presupune: ordonarea liniilor; ordonarea atributelor. Liniile (tuplurile) nu sunt ordonate! Termenul de tabel sau relaie va avea semnificaia de fiier, sau mai general de colecie de date. Un rnd dintr-o tabel va avea semnificaie de nregistrare. Iat, pe scurt, conceptele de baz legate de baze de date relaionale : Tabela sau relaia este un ansamblu format din n coloane (atribute, subansambluri) i m rnduri (linii) care respect urmtoarele condiii minime: s nu existe date la nivel agregat (valorile aflate la intersecia liniilor cu coloanele s fie la un nivel elementar); liniile s fie distincte unele fat de altele; s nu existe coloane repetitive n descriere.

Cheia primar este un atribut care identific n mod unic fiecare nregistrare. Deci, fiecare linie se identific printr-o valoare distinct. Dou sau mai multe atribute care pot fi chei primare se numesc chei candidate. Cheie extern este un atribut (cmp) sau o combinaie de atribute (cmpuri) dintr-un tabel ale crei valori sunt definite pe aceleai domenii cu ale cheii primare din alt tabel (relaie). Coloana tabelei este format din valorile pe care le ia atributul n liniile tabelei respective. Rndul/linia este format din valorile coloanelor ce se refer la o entitate a tabelei. Bazele de date relaionale sunt proiectate folosind o tehnic de analiz a datelor numit normalizare. Normalizarea este folosit pentru a separa datele n tabele, astfel nct cmpurile din fiecare tabel s fie dependente doar de cmpul cheie primar, i s nu fie legate de nici un alt cmp cheie. Relaiile dintre tabele se reprezint prin duplicarea coninutului unor cmpuri. Normalizarea face ca adugarea, modificarea i tergerea articolelor s fie posibile fr consecine nedorite, adic pstrndu-se integritatea bazei de date.

D. Modelul orientat obiect Sistemele de gestiune a bazelor de date obiectuale (SGBDO) fac parte din noul val de produse, menite s asigure administrarea informaiilor tot mai complexe, utilizate n domenii cum ar fi : proiectarea asistat de calculator (CAD), ingineria programrii, sistemele de informare, gestiunea reelelor, gestiunea documentelor, sisteme multimedia, birotica. Astfel de sisteme nglobeaz majoritatea funciilor SGBD-urilor tradiionale i un limbaj orientat pe obiecte pentru a defini schema bazei, a manipula obiectele i a codifica aplicaiile.

Modelele relaionale i SGBD-urile relaionale au fost dezvoltate pentru aplicaiile de gestiune. Ele sunt legate de abordri bazate pe separarea datelor de prelucrri. Modelele pe care se bazeaz aceste instrumente sunt inadecvate pentru modelarea obiectelor provenind din aplicaii din domenii cum ar fi birotica, administrarea documentelor, proiectarea asistat de calculator. n modelul relaional nu exist noiunile de obiect i clas. Orice obiect al lumii reale este descompus n mai multe relaii plate (flat tables) i uneori sunt necesare anumite legturi pentru a putea reconstitui obiectul iniial. Limbajele orientate pe obiecte. Programarea orientat pe obiecte este nu numai o tehnic de programare, ci constituie n mod esenial o tehnic de structurare a programelor care se sprijin pe entiti manipulate de sistem i nu pe funciile sale. Conceptul de programare orientat pe obiecte a aprut ctre 1970 i s-a rspndit ncetul cu ncetul n mediile inteligenei artificiale. Aceste limbaje propun o nou abordare a programrii , bazat pe fuziunea natural dintre prelucrri i date. Programarea obiectual se bazeaz pe 4 axiome: Axioma 1: Orice este obiect. Un obiect se poate caracteriza prin : o structur de date, adic de variabile caracteriznd starea sa i care sunt rezervate pentru a fi folosite n mod privat de ctre obiect; o structur de control a comportamentului, adic mesaje care sunt n general publice. Ele pot fi folosite de alte obiecte pentru a comunica cu obiectul n cauz. Atunci cnd sunt primite de obiect, ele activeaz metode asociate care induc un anume comportament obiectului.

Axioma 2: Orice obiect este creat plecnd de la un model care este propriu acestui obiect: clasa. Se spune despre acel obiect c este o instaniere a clasei sale. Unele obiecte au statut dublu. Pot exista obiecte ale unor clase speciale numite metaclase ale cror instanieri sunt ele nsele clase. Axioma 3: Orice obiect accept mesaje (cu sau fr parametri) la care rspunde. Axioma 4: Orice clas este o subclas a cel puin unei alte clase (superclasa), exceptnd clasa "Obiect" care este rdcina ierarhiei. Limbajele orientate obiect permit dezvoltarea de aplicaii ntr-o form modular, ceea ce favorizeaz prototipizarea, testarea, reutilizarea codului i micorarea sarcinilor dezvoltrii. Un modul implementeaz o clas de obiecte i fiecare nou modul poate fi obinut prin simpl specializare. Conceptele modelrii Conceptul de baz este obiectul , definit ca fiind reprezentarea unei entiti a lumii reale. n baza de date obiectul este identificat ntr-o manier unic printr-un identificator, atribuit de sistem. Un obiect este descris printr-un ansamblu de proprieti constituind atribute i metode. Prin ncapsulare , aceste proprieti intr n proprietatea privat a obiectului. Nici un alt obiect nu cunoate metodele unui obiect dat dect prin semnturile lor (numele metodei, lista parametrilor i tipul rezultatului) i nu are nici un mijloc de a accede la atributele acestuia, care sunt manipulate prin metodele proprii. Obiectele din lumea real, de aceeai natur sau prezentnd similitudini, sunt grupate n cadrul unei clase n care sunt declarate toate atributele , precum i metodele care le manipuleaz. O clas constituie astfel un tipar pentru o mulime de obiecte. Pe planul reprezentrii interne, un obiect creat este o zon de memorie coninnd diferitele valori ale atributelor, iar metodele sunt descrise o singur dat i partajate de toate obiectele din clas. Orice obiect este construit plecnd de la o clas sau un tip care regrupeaz structura datelor i metodele. O clas joac astfel rolul unui generator de obiecte. Pentru ilustrarea noiunii de clas, s lum cazul angajailor dintr-o ntreprindere ; acetia se caracterizeaz printr-un numr de marc, nume, salariu, departament i numr de telefon. Pe de alt parte, fiecrui individ i se poate calcula salariul, i se poate face o mrire de salariu etc. Metodele de creare i de modificare sunt indispensabile tuturor claselor pentru a crea i a actualiza obiectele clasei. ncapsularea datelor asociate obiectului conduce la imposibilitatea de a fi vzute de ctre celelalte obiecte. Definirea unei subclase a unei clase presupune noiunea de motenire simpl. Dac o subclas motenete dou sau mai multe clase, este vorba de o motenire multipl. de atribute i metode.

Modelul de date orientat obiect n filizofia OODB lumea real este reprezentat ca o serie de obiecte . Un obiect poate reprezanta orice element al lumii reale de la un bit la o paltform industrial. Biectel manifest , prin definirea lor caracteristici commune :

Persisten starea unui obiect este reinut n system dup ce programul care-l gestoineaz i-a ncheiat activitatea . Identificator unic la crearea unui obiect este generat un indentificator unic care va rmne asociat obiectului pe ntrrgul ciclu de via . Identificatorul este separat de starea obiectelor fiin astfel capabil s fac diferena ntre dou obiecte cu aceiai stare . Roprietile datelor Un set de date despre proprieti care nregistreaz starea curent a obiectelor . datele accepatate includ : primitive(ntregi , caractere ) , tipuri noi de date )tipuri complexe bca imagini , sunet etc). Aceste tipuri complexe de date pot fi definite cu un mecanism de generare de tipuri abstracte de date . Operatori un set de funcii care manipuleaz starea obiectului . ncapsulare definmirea coninutului de bdate i oeratori n cadrul obiectului . Operatorii formeaz o interfa prin intermediul creia funciile apelante pot manipula obiectele . n rest obiectul este privit ca un black box. Relaii similar cu orice model de date , o proprietate important refer modul n care sunt reprezentate relaiile dintre diferitele componente de date . OODB apar ca fiind de dou tipuri ( caracterizate prin modul de utilizare a pointerilor a se vedea Definirea datelor) inter-clase ierahia claselor

Clase i ierahia claselor Obiectele cu aceleai proprieti i opeartori sunt calsificate de maniera la care se formeaz clase de obiecte distincte. Astfel fiecare obiect este o instaniere a unei calse de obiecte . Fiecare instaniere a unei clase de obiecte primete o identitate unic i acela set de proprieti de ]adte i operatori . n activitatea de construire a unui OODB se vor crea clase de obiecte multiple i ierahiile claselor , asupra crora se pot aplic specializri pentru facilitatreea administraiei. Utilizarea specizrilor se materializeaz prin identificarea proprietilor i operatorilor comuni obiectelor .Obiectele sunt deci restructurate ierarhic , cu superclasa obiectelor n vrful ierarhiei i cu specializrile obiectelor ca sub-clase ale obiectelor comune . Astfel n mecanismul de motenire clasele specializate pot prezenta propriile proprieti i operatori plus cele aferente superclasei din care fac parte (fig. 1) . Acest mecanism reduce dramatic repetare codului i astfedl mbuntete ntreinerea .

O clas obiect cu o singur superclas este denumit cu motenire singular . Specializarea se poate aplica peste tot , pe toate nivelele unei ierahii iar clasele de obiecte pot avea mai mult dect o superclas , fiind astfel referite ca moteniri multiple. Arhitectura

Obiectele sunt gestionate prin intermediul identitii logice , permind micarea obietelor n scopuri de arhivare i partiionare fr s fie necesar modificarea de cod n aplicaie

Definirea datelor Nu exist limbaj standard pentru definirea OODB-urilor , n schimb programatorii pot crea clase de obiecte folosind limbaje care implementeaz OO , ca C++ sau Java . (fig.2)

Relaiile pot fi expuse ca scheme prin includerea proprietilor de date , cunoscute ca pointeri care puncteaz obiectul relaionat .

Modificarea schemei nseman recreerea , restructurarea i recompilarea schemei. Navigarea O OODB poate fi compus dintr-un numr mic pn la un numr mare de obeicte . Cutarea unui obiect prin utilizarea de pointeri se realizeaz prin navigarea de la un obiect la altul (fig.4)

Aceast abordare este consideart ca mai natural pentru cutaea obeictelor dect metoda algebric specific bazelor de date relaionale . Avantajele abordrii ODB Printre cele mai imporatnte avantaje ale abordrii OODB se regsesc : obiectele nu necesit reasamblarea pornind de la tabelele de componente la fiecare utilizare ceea ce conduce la mbuntirea timpului de acces , fiind astfel foarte util n procesele tranzacionale . reducerrea numrului de pagini simplitatea gestiunii evrsiunilor navigarea n baza de date este multa mai natural Relaiile sunt stocate n baza de date odat cu obiectele , pointeri Modelul datelor este reprezentativ pentru lumea real Este adecvat arhitecturilor distribuite client server

Dezavantajele abordrii OODB Se manifest , n egal msur limitri i dezavantaje pentru acest abordare .

lipsa de standarde actuale cererile relative la navigare au limitri de documentare nu exist semantici formale pentru OODB simplitatea tabelelor relaionale este pierdut paradigma orientat obiect face dificil conversia de la baze de date relaopnale la OODB scalare dificiln att n sfera tranzaciilor ct i n sfera conturilor utilizatori

Utilizatorii bazelor de date Acestia acceseaza datele prin intermediul SGBD, prin comenzi Exista cateva categorii de utilizatori: c. utilizatorii programatori (dezvoltatori de aplicatii) Aplicatie de BD: program ce foloseste datele dintr-o baza de date pentru un anumit scop, limitat. d. utilizatorii finali, acceseaza datele prin intermediul unei aplicatii. e. Administratorul bazei de date: se ocupa cu mentinerea in functionare a bazei de date (back-up, drepturi, monitorizare, etc.)

Arhitectura interna a sistemelor de baze de date In 1975, a aparut standardul ANSI/SPARC ce stabileste mai multe nivele de arhitecura a bazelor de date:

nivelul extern, compus din una sau mai multe vederi utilizatori. Aceste vederi sunt descrise de subscheme logice, ce descriu datele accesate; nivelul intermediar, ce contine o descriere printr-o schema conceptuala (logica) unica a bazei de date; interogheaza toate subschemele logice ale fiecarui utilizator. Schema logica a bazei de date este descrisa si analizata de SGBD. Se refera la organizarea datelor din punct de vedere logic. Pentru memorarea efectiva a datelor e necesara o schema interna; nivelul intern: schema interna (fizica). Descrie modul de memorare a datelor pe suport fizic. Exista o corespondenta (mapping) intre schema conceptuala si cea interna, controlata de SGBD.

Aceasta arhitectura a sistemelor de baze de date are ca scop independenta datelor de suportul hardware.

Limbajele si interfetele utilizate in aplicatiile de BD Orice SGBD trebuie sa suporte 2 limbaje din punct de vedere conceptual: d. un limbaj de descriere a datelor (LLD, DDL); e. un limbaj de manevrare a datelor (LMD, DML). In implementarile reale, exista numeroase limbaje prin care se transmit comenzi pentru SGBD-uri. De ex, in SGBD-urile relationale, SQL (Structured Query Language): limbaj de interogare. SQL contine ambele componente conceptuale (LDD si LMD). Comunicatia cu un SGBD se poate realiza prin comenzi (instructiuni):

in mod iterativ:
o o

se transmit comenzi suportate de SGBD-ul respectiv SGBD-ul raspunde cu valorile returnate

prin intermediul aplicatiilor de BD, ce prezinta interfete grafice. De regula, forma cea mai obisnuita pentru aplicatiile de BD este formularul (form), ce are rolul de a restrictiona accesul utilizatorilor finali.

Arhitectura client-server a aplicatiilor de BD

important pentru dezvoltarea aplicatiilor: se poate face o distribuire a sarcinilor distribuirea intr-o retea a clientului (clientilor) si a serverelor

Se disting cateva tipuri de arhitecturi, dupa numarul utilizatorilor si a numarului de statii:

SGBD centralizat
o

aplicatie monoutilizator in retea

aplicatie multiutilizator in retea

SGBD distribuit

In cazul SGBD-urilor distribuite apar probleme:

o o

se doreste transparenta pentru utilizator a distribuirii datelor; optimizarea interogarii este foarte complicata.

Concluzie. SGBDO ofer noi funcionaliti pentru administrarea eficient a datelor complexe i voluminoase. Suportul formal pe care se sprijin (modelele orientate pe obiecte i limbajele de interogare i manipulare) le ofer un plus de rigoare. Totui, rmne ca aceste tehnici s fie perfecionate n continuare, deoarece timpii de rspuns oferii sunt nc destul de mari. Avnd n vedere situaia actual a pieii, nu este posibil nc nlocuirea SGBD-urilor relaionale, care acoper cvasi-totalitatea nevoilor, rspunznd ntr-o manier optim exigentelor aplicaiilor de gestiune, i la ora actual preponderente.

ACCESUL LA BAZELE DE DATE Accesul la date se poate face local, sau de la distant, prin intermediul unui din serviciile oferite de Internet, sau direct, prin conectare de la distan cu calculatorul ce conine baza de date. Din punct de vedere al restricionrii accesului, bazele de date se mpart n: Baze de date publice (accesibile prin dial-up, INTERNET, comercializate pe CD-ROM) Baze de date private (care aparin unei organizaii sau persoane). BAZE DE DATE DISTRIBUITE O baz de date distribuite este o baz de date logic integrat, dar fizic distribuit pe mai multe faciliti de calcul distincte, interconectate ntre ele. Logic integrat -din punctul de vedere al utilizatorului , BDD reprezint o singur baz de date (BDD are o singur schem conceptual global, utilizatorul interacioneaz cu BDD n aceeai manier n care interacioneaz cu o baz de date centralizat, si, n

general, nu are informaii despre partiionarea , replicarea i distribuirea datelor) Prelucrrile iniiate la un nod antreneaz n general prelucrarea informaiilor aflate n alt nod. Fizic distribuit pe mai multe faciliti de calcul distincte: baza de date este partiionat, iar partiiile respective sunt pe calculatoare diferite (se admit copii ale fragmentelor memorate n noduri diferite). Fiecare fragment este vzut, n nodul n care exist, ca baz de date centralizate, care poate fi administrat i exploatat local. Baza de date distribuit (o mulime de colecii de date i legturile dintre ele) este fragmentat conform principiilor : plasarea datelor memorate n nodul de producere i utilizare a lor; minimizarea transportului de date prin reeaua de calculatoare. Pentru a rspunde acestor principii, fragmentarea se realizeaz la dou nivele : partiionarea mulimii de date n submulimi de colecii de date; partiionarea unei colecii de date n fragmente. Fragmentarea coleciei de date se poate realiza n dou moduri : - orizontal - fragmentele rezultate au aceeai structur ca i colecia, dar difer ntre ele prin datele pe care le conin; - vertical - fragmentele rezultate conin fiecare doar cte o parte din structura coleciei. Este admis i combinarea celor dou moduri. Fragmentele rezultate constituie elementele de distribuire a datelor. Totalitatea fragmentelor unei baze de date distribuite , memorate pe un nod al reelei, constituie o baz de date local. 3. Limbajul SQL A aparut in 1971. SQL insemna Structured Query Language: limbajul folosit pentru definitia si manipularea datelor in modelul relational. Majoritatea SGBD suporta SQL. In 1986, primul standard ANSI. In 1992, standarul ANSI/ISO a definit SQL92 (SQL2) ca limbaj standard pentru SGBD relationale. SQL contine atat componenta de descriere a datelor (LDD),cat si componenta de manipulare a datelor (LMD); Manipularea (interogarea) este parte extinsa; Limbaj neprocedural: secventa de comenzi (instructiuni), fiecare comanda este transmisa SGBD-ului, este interpretata si returneaza un rezultat. Standardul SQL3 (SQL 98) defineste modelul obiect-relational de baze de date. Structura sintactica: limbajul este compus din instructiuni (comenzi). O comanda SQL este o secventa de elemente componente (token). Elementele componente pot fi: cuvinte cheie, identificatori, caractere speciale si constante (literali). Cuvintele cheie si identificatorii

Acestia au o structura lexicala identica. Lexical, un cuvant cheie sau un identificator inseamna o secventa de litere si caracterul _. Din punct de vedere semantic, cuvintele cheie sunt elemente cu semnificatie fixa in limbaj: nume de comenzi (clauze): SELECT, INSERT, etc; tipuri de date: integer, numeric, char, varchar, etc. Limbajul SQL nu diferentiaza caracterele mari de cele mici: este case insensitive. Identificatorii au aceeasi structura lexicala; din punct de vedere semantic reprezinta nume intr-o comanda si pot fi: nume de tabele, de coloane, etc. SQL foloseste termenii de tabel, coloana si linie pentru relatie, atribut si tuplu (cei subliniati sunt cei folositi in definirea matematica a modelului relational). Identificatorii sunt: obisnuiti (simpli): Sectie, ANGAJAT, etc; delimitati: reprezinta un nume pus intre ghilimele, care poate sa contina orice fel de caractere. Un identificator delimitat este folosit, in general, un nume mai mare de tabel. Cuvintele cheie si identificatorii nu pot fi deosebiti intre ei decat daca cunoastem limbajul. Constantele Constantele pot fi: de tip numar intreg: ex 1234 (reprezentate pe 4 octeti); de tip numar real: ex 12.5, 12e5 (reprezentate de 8 octeti, in formatul double); de tip sir de caractere: ex Acesta este un sir; de tip NULL: constanta speciala, reprezinta lipsa de informatie. Caracterele speciale operatori (+,-,); ; termina o comanda; punctul zecimal (constante reale, codificari ale coloanelor); separatorii: blank, TAB, CR ; sunt ceruti uneori intre elemente. Operatori, expresii si functii SQL Operatorii SQL: pot fi reprezentati prin unul sau mai multe caractere speciale (+, <,) sau prin cuvinte cheie (AND, OR, NOT, UNION). Operatorii pot fi clasificati: operatori binari: au nevoie de doi operanzi; operatori unari: se aplica unui singur operand si pot fi postfixe sau prefixe. Operatori: aritmetici: +, -, <, <=, <> (!=); logici: AND, OR, NOT. Operatorii logici se aplica asupra unor valori ternare (o valoare ce reprezinta un

operand ce poate avea valoare TRUE (1), FALSE (0) si NULL (lipsa de informatie)). Nu exista tipul de date boolean asupra caruia sa se aplice operatorii logici dar operatorii de comparatie returneaza o valoare booleana. Operatorii de comparatie evalueaza orice expresie la o valoare logica (bool): TRUE, FALSE. Tipul boolean exista insa incepand din SQL3. Operatorii de comparatie pot fi:

aritmetici: <, >, <=, >=, =, != (<>); relationali a. A BETWEEN val_min val_max; b. A LIKE model_sir -> A sir; c. A IS NULL sau A IS NOT NULL; d. A IN lista_valori.

O expresie SQL este o expresie formata din operanzi, operatori si paranteze. Operatorii, in general, sunt nume de coloane (se va folosi valoare atributului definit de acea coloana) sau o constanta. Orice expresie se evalueaza la o valoare care poate fi apoi folosita in alte operatii. Functiile SQL: functii totalizatoare (de grupare): calculeaza anumite valori pentru coloane din tabele: SUM, AVE, MIN, MAX, ; functii matematice: calcule trigonometrice, puteri, logaritmi, rotunjiri; functii pentru siruri; functii pentru date calendaristice; functii pentru conversii. Tipurile de date si domenii de definitie in SQL2: Tipurile de date(SQL2): sunt destul de putine: d. tipul intreg : INTEGER, reprezentat pe 4 octeti( SMALLINT pe 2 octeti) e. tipuri pentru numere reale: a. reprezentarea cu aproximatie a numerelor reale folosind virgula flotanta: FLOAT (4 octeti), DOUBLE [PRECISION] (8 octeti);

b. reprezentate precis (cu o precizie dorita): NUMERIC (DECIMAL) se poate stabili precizia nr de cifre pe care se reprezinta numaruil=p si s= nr de cifre de dupa virgula. NUMERIC reprezinta cu o precizie si scala stabilita de implementarea limbajului: Numeric(3)=precizie 3; Numeric(7,3)=precizie 7; scala 3; Numerele in acest format sunt memorate ca secventa de cifre, iar atunci cand se opereaza cu ele, precizia de calcul este mult mai mare decat la cele in virgula flotanta; f. tipul sir de caractere: CHAR(n), CHARSET(n) sau VARCHAR(n). Argumentul n reprezinta numarul maxim de caractere al sirului. Diferenta este: pentru VARCHAR se atribuie exact numarul de caractere necesar, pentru CHAR se aloca intotdeauna n caractere, indiferent de marimea sirului. g. mai exista si tipul TIME si DATE(yyyy:mm:dd). Domenii de definitie: SQL nu asigura exact notiunea matematica. In SQL2 se folosesc ca domenii ale atributelor tipurile fundamentale ale limbajului. Ceea ce lipseste la o astfel de definitie este semantica (intelesul). SQL este foarte sarac in precizarea semanticii domeniilor folosite pentru atribute. Comenzi SQL Exista doua tipuri de comenzi:

Comenzi de creeare a tabelelor, de stergere a tabelelor si de modificare a tabelelor formeaza comenzile de definire a datelor (Limbaj de definire a datelor); Comenzile de manevrare a datelor (LMD): SELECT (interogarile de baza), INSERT, UPDATE, DELETE.

SQL asigura toate operatiile care se considera necesare intr-o baza de date. A. Comenzile de creeare: CREATE TABLE sau CREATE VIEW: in modelul relational, tabelele pot fi:
o

tabele de baza: un tabel care se defineste si este memorat in fisierele bazei de date; vederi: un tablou virtual, ce reprezinta o parte din liniile sau coloanele unuia sau a mai multor tabele. Cand se creeaza o vedere, datele unui tabelvedere nu se multiplica (datele din vedere sunt chiar cele memorate in tabelele de baza).

Vederile permit restrictionari diferentiate ale drepturilor utilizatorilor. Vederile sunt intotdeauna la zi, o modificare in tabelul de baza se vede si in vedere. Definirea vederilor reprezinta o imixtiune a nivelului utilizator in nivelul conceptual.

CREATE TABLE nume_tabel( nume_col1 tip_date [constrangeri_coloana], nume_col2 tip_date [constrangeri_coloana], nume_coln tip_date [constrangeri_coloana]); Obs: nume_tabel trebuie sa fie unic intr-o baza de date nume_col1, , nume_coln : identificatori; tip_date: tip SQL. Ex: Sectie (Numar, Nume, Buget); Angajat(Nume, Prenume, Data Nasterii, Adresa, Functia, Salariul) CREATE TABLE sectie( Numar integer, Nume varchar(20), Buget numeric(12,2));

CREATE TABLE angajat( Nume varchar(20), Prenume varchar(20), DataNasterii DATE, Adresa varchar(20), Salariul numeric(6,2));
o

DROP TABLE nume_tabel;

Sterge complet tabelul

o

ALTER TABLE nume_tabel Se pot sterge coloane, se pot adauga coloane, etc.

CREATE VIEW nume_vedere AS SELECT. Rezultatul selectiei reprezinta vederea respectiva.

DROP VIEW nume_vedere; Sterge complet vederea.

Comenzile de manipulare de date:

o

SELECT , cea mai importanta comanda de manipulare a datelor. Reprezinta comanda de interogare de baza de date. Este o instructiune foarte puternica, folosita si in alte scopuri nu numai pentru interogare.

SELECT [DISTINCT] lista_coloane FROM lista_tabele WHERE conditie [clauze_secundare]; Exista trei clauze (parti) principale ale comenzii: Clauza SELECT: este urmata de o lista de coloane care vor fi coloanele rezultatului. Rezultatul unei comenzi SELECT este, de regula, un tabel; Clauza FROM introduce numele unuia sau mai multor tabele. Rezultatul va contine tupluri ale produsului cartezian ale tuturor tabelelor date in clauza FROM, pe coloanele indicate de clauza SELECT care respecta conditia introdusa de clauza WHERE; Conditia din WHERE evalueaza la o valoare booleana (TRUE, FALSE). In rezultat se admit acele tupluri pentru care conditia este verificata. Clauza WHERE este optionala (!!). Obs: Suita de tabele trebuie sa fie astfel data incat toate coloanele date in lista sa fie gasite in acele tabele; Numele coloanelor din lista de coloane trebuie sa fie unice. Daca nu sunt unice, se diferentiaza fie prin denumire, fie prin calificare;

* pentru clauza SELECT inseamna toate coloanele posibile. Ex: SELECT * FROM sectie; SELECT * FROM sectie, angajat; = corect, desi avem nume de coloane identice, SQL stie sa le diferentieze SELECT Nume, Nume, Prenume, Salariu, ; = eroare SELECT sectie.Nume, angajat.Nume, Prenume, Salariu FROM sectie, angajat; = corect SELECT Nume, Prenume FROM angajat WHERE Salariu>=1800; Constrangerile de integritate relationala a datelor O baza de date reprezinta un model al unei realitati. Se impun niste constrangeri asupra datelor, pentru a fi respectata realitatea (stabilite de proiectant). Aceste constrangeri: permit sa avem asigurata integritatea datelor; sunt independente de SGBD. Constrangerile pot fi privite si ca o multime C={C1, , Cn}. In baza de date sunt definite m relatii R1, R2, , Rm. Schema unei baze de date este o multime formata din multimea relatiilor la care se adauga multimea constrangerilor. S={R1, R2, , Rm},{C1, C2,, Cn} Constrangerile pot fi: a) intra-relatii: exista in cadrul unei singure relatii; de domeniu: impune conditii domeniului de valori ale atributelor (de coloana) de tuplu: prin intermediul cheilor, asigura integritatea tuplurilor (nu se admit doua sau mai multe tupluri identice); de normalizare: constrangeri de elimina redundantele din relatii, se refera la dependente functionale si multivalorice b) inter-relatii: exista intre mai multe relatii, prin stabilirea unor asocieri (CHEI STRAINE). Constrangerile de domeniu Fiind dat un domeniu (pt atribute), se pot impune anumite restrictii asupra valorilor pe care le pot lua atributele, restrictii ce pot avea un caracter mai general (constrangerea NOT NULL) sau mai specifice (constrangerea CHECK). Constrangerea NOT NULL specifica faptul ca un atribut nu poate lua valoare NULL (lipsa de informatie). Exista cateva cazuri in care NULL poate fi atribuita:

fie pentru tuplul respectiv nu este aplicabil atributul respectiv; fie valoarea va fi stabilita ulterior. Constrangerea CHECK face verificarea valorii unui atribut si este admisa daca rezultatul verificarii este TRUE. Cele doua constrangeri se pot introduce in SQL prin comanda CREATE TABLE. Ex: CREATE TABLE Angajat( Nume varchar(20) NOT NULL, Prenume varchar(20) NOT NULL, DataNasterii Date, Adresa varchar(40), Salariu decimal(8), [CONSTRAINT cs] CHECK (Salariu>=1500)); cs=numele constrangerii. Constrangerile de tuplu Se refera la acele constrangeri ce permit identificaera unica a unui tuplu. Prin definitia relatiei, nu exista doua tupluri identice intr-o relatie. Multimea valorilor tuturor atributelor este unica. Constrangerile se realizeaza prin chei: f. SUPERCHEIA (SK) Fiind data o relatie cu o a doua definitie R={A1, A2, , An}, S c R : este o submultime a multimii {A1, A2, , An} astfel incat nu exista in relatia R doua tupluri ti si tj care sa aiba aceleasi combinatii de valori ale atributelor in submultimea SK. ti [SK] tj [SK] , ij Supercheia este unica. Orice relatie are cel putin o supercheie: multimea tuturor atributelor sale. Este posibil sa putem identifica tuplurile prin atribute mai putine: chei candidate.

CHEIA CANDIDATA (CK)

Cheia candidata este o supercheie ireductibila (minimala). Proprietati:

unicitate: nu pot sa existe doua tupluri ti si tj care sa aiba aceleasi combinatii de valori ale atributelor in submultimea CK ti [CK] tj [CK] , ij

ireductibilitate: Fiind data cheia CK (o submultime a atributelor relatiei), daca se elimina un atribut din CK, submultimea rezultata (CK) nu mai are proprietatea de unicitate.

Cheile candidate se stabilesc de catre proiectant, astfel incat sa asigure unicitatea: Fie relatia Angajat(IdAngajat, Nume, Prenume, DataNasterii, Adresa, Salariu) {Nume, Prenume} nu poate fi o cheie candidata: pot exista mai multi angajati cu acelasi nume si prenume. CK1={Nume, Prenume, DataNasterii, Adresa} poate fi CK CK2={IdAngajat} poate fi CK Intr-o relatie pot exista una sau mai multe chei candidate. Cheile pot sa fie cu un singur atribut (simple) sau cu mai multe atribute (compuse). Se alege din toate cheile candidate o cheie primara.

CHEIA PRIMARA (PK): una din cheile candidate ce va fi folosita ulterior pentru identificarea unica a tuplurilor.

Criteriul de alegere este, in genereal, simplitatea (cu numarul cel mai mic de atribute). Integritatea de tuplu reprezinta aceasta cerinta ca atributele cheii primare sa ia o singura valoare, specifica tuplului respectiv. Restrictii ale cheii primare:

nu poate fi modificata; nu poate contine valori de NULL pe nici un atribut. CHEIA SECUNDARA

Cheile secundare sunt acele chei candidate ce nu sunt chei primare. Se mai numesc si chei alternative sau unice. In cheile secundare se admit atat modificari de valori cat si valori de NULL pentru o parte din atribute, daca:

d. se permite acest lucru; e. se mentine unicitatea cheii secundare.

In SQL, exista doua constrangeri de relatii: PRIMARY KEY = cheie primara UNIQUE = cheie secundara Ex: CREATE TABLE Angajati( IdAngajat integer PRIMARY KEY, Nume varchar(20) NOT NULL, Prenume varchar (20) NOT NULL, DataNasterii Date, Adresa varchar(50), Salariu numeric(8), [CONSTRAINT uk] UNIQUE (Nume, Prenume, DataNasterii, Adresa), [CONSTRAINT cs] CHECK (Salariu>=1500)); De regula, cand se proiecteaza o relatie, se adauga un atribut de identificare unica, ce se foloseste ca si cheie primara. Constrangeri inter-relatii

CHEIA STRAINA

Pentru a asigura categoriile de asocieri intre relatii, se folosesc CHEILE STRAINE, ce impun constrangeri asupra unor valori de atribute. Def: Cheia straina Fiind data o relatie R1={A1, A2, , An} in care exista o submultime de atribute

FKcR1 si o relatie R2={B1, B2, , Bn} cu o CKcR2. FK este cheie straina in R1 si refera cheia candidata CK in R2 daca: B. FK si CK au acelasi numar de atribute, definite pe domenii compatibile; C. Pentru orice valoare a lui FK in R1, se gaseste o valoare a lui CK in R2: t1i[FK]= t2j[CK] sau t1i[FK]=NULL. Valoarea cheii straine o regasim ca valoare a unei chei candidate: INTEGRITATE REFERENTIALA. R1: relatia care refera (FK) R2: relatia referita (CK, PK).

Intre R1 si R2 avem o asociere N:1 Prin FK se modeleaza asocierea N:1 R1:R2 (1:N R2:R1)

Domenii compatibile Def: Doua domenii sunt compatibile din punct de vedere relational daca sunt definite cu tipuri de date compatibile si sunt identice din punct de vedere semantic (au aceeasi semnificatie). Compatibilitate: putem compara valori din cele doua domenii. FK in SQL este o constrangere de tabel: [CONSTRAINT nume_constrangere] FOREIGN KEY (lista_atribute_ch_straina) REFERENCES nume_tabel(lista_astribute_ch_candidata) CREATE TABLE ANGAJAT( .

[CONSTRAINT fk] FOREIGN KEY (IdSectie) REFERENCES Sectie(IdSectie)); In SQL nu se face o verificare a identitatii semantice a domeniilor, deoarece SQL foloseste tipurile de date primitive. Integritatea referentiala: atributele cheii straine trebuie sa aibavalori egale cu atributele cheii primare din relatia definita. Diagrama referentiala Diagrama referentiala reprezinta un graf orientat: h. nodurile: relatiile; i. arcele: referinte de la o relatie ce refera catre relatia referita.

O referire se modeleaza prin o asociere N:1, o asociere unidirectionala. Se observa ca, in modelul relational, asocierea se realizeaza prin egalitatea valoriloe atributelor (fara pointeri, etc.). Intr-o diagrama relationala pot exista cicluri referentiale, in care o relatie referita este, la randul ei, relatie ce refera o alta relatie:

Exista chiar si autoreferiri: Mentinerea integritatii referentiale se face prin restrictii la operatia de INSERT, DELETE, UPDATE:

f. Inserare (INSERT): nerestrictionata intr-o relatie ce este referita. Este restrictionata insa intr-o relatie care refera; g. Stergere (DELETE) : nerestrictionata intr-o relatie ce refera. Restrictionata intr-o relatie care refera; h. Actualizarea (UPDATE): restrictionata la ambele Constrangeri: ON DELETE CASCADE : se admite stergerea, dar se vor sterge celelalte tupluri ce sunt referite de tuplul respectiv ON DELETE RESTRICTED: nu se poate sterge un tuplu ON UPDATE CASCADE ON UPDATE RESTRICTED 5.Transpunerea modelului E-A in modelul relational Face parte din proiectarea BD, a aplicatiilor BD. Datorita diversitatii realitatii, poate exista o diversitate de BD. De aici deriva diversitatea posibilitatilor de abordare soft a aplicatiilor de BD. Etapele proiectarii BD: proiectarea conceptuala: de regula inseamna proiectarea unui model entitate-asociere (E-A), numit si proiect conceptual de nivel inalt al BD. Aceasta faza se mai numeste si proiectare logica. Proiectul conceptual este diferit fata de modelul specific de SGBD, etc. Proiectul logic este dependent de modelul de date (RELATIONAL), este independent de SGDB-ul ce va fi folosit (independenta este relativa). De regula, proiectul logic se dezvolta pentru un anumit SGBD. Fiecare SGBD vine de regula cu toolset-uri pentru proiectarea aplicatiilor dar si pentru proiectarea logica. proiectarea fizica: inseamna o rafinare a proiectului logic; este faza in care se adopta solutii care influenteaza nivelul fizic de organizare a datelor. In proiectarea fizica se implementeaza indecsii. Etapele de transpunere: Multimile de entitati se transpun in relatii; se definesc si constrangeri inter-relatii (cheia primara). Asocierile intre relatii definesc constrangerile inter-relatii. Exemplu: model E-A

INTREPRINDERE Multimile de entitati puternice:

SECTIE (Numar, Nume, Buget) ANGAJAT (Nume, Prenume, DataNasterii, Adresa, Salariu) PROIECT (Nume, Termen, Buget) COMPONENTA (Nume, Descriere) PRODUS (Nume, Descriere,) FURNIZOR (Nume, Prenume, Adresa, Firma) CLIENT (Nume, Prenume, Adresa) Multimile de entitati slabe, dependente

DEPENDENT (Nume, Prenume, Varsta, GradRudenie) Subtipurile de entitati (ale tipului ANGAJAT):

SECRETARA (VitezaDeRedactare) INGINER (Specializarea)

Mostenirea in diagrama E-A se reprezinta prin asocieri 1:1 intre tipul principal si cel derivat. Diagrama E-A:

Multimile de entitati:

I.1. Multimile de entitati puternice devin relatii (de sine statatoare): se poate alege cheia primara: D. o submultime de atribute; E. se adauga un atribut de identificare unica a tuplurilor

In general, atributele de identificare trebuie sa garanteze unicitatea per relatie a valorilor lui: unicitatea depinde de SGBD (ex: Autonumber) I.2. Multimile de entitati slabe devin relatii, obligatoriu in asociere N:1 cu relatia corespunzatoare tipului puternic de care depinde tipul slab: DEPENDENT( IdAngajat, Nume, Prenume, Varsta, GradRudenie) IdAngajat, Nume, Prenume reprezinta cheia primara (se poate adauga un alt atribut care sa fie cheie primara) IdAngajat este cheie straina

I.3. Multimile de subtip se transpun in relatii: f. se defineste o cheie straina care refara cheia primara din relatia tip; g. cheia straina este si cheie primara (!!!) Relatia subtip este in asociere 1:1 cu relatia tip

Asocierile II.1. Asocierile N:1 se realizeaza :

intre relatii corespunzatoare multimilor de entitati puternice si se realizeaza printro cheie straina in prima relatie (N) care refera o cheie primara din relatia a doua; intre o relatie dependenta si una puternica II.2. Asocierile binare M:N

Se realizeaza prin adaugarea unei relatii (numita de asociere) intre cele doua relatii. Aceasta relatie contine cate o cheie straina care se refera la cheile primare din cele doua relatii. Ex: COMPONENTA PRODUS (M:N) COMPONENTA(IdComponenta, Nume,) PRODUS(IdProdus, Nume, ) COMPOZITIE (IdComponenta, IdProdus, , Roata,) IdComponenta = cheie straina (IdProdus = cheie straina) IdComponenta, IdProdus = cheie primara (sau se poate adauga un atribut special pentru cheia primara). II.3. Asocierile M:N:P Reprezinta o extindere a cazului M:N. Se foloseste o relatie noua (relatie de asociere) in care se definesc 3 chei straine care refera relatiile pe care le asociaza. VANZARE (IdAngajat, IdClient, IdProdus, DataVanzarii, NrBuc,) Este necesar un atribut suplimentar (DataVanzarii) pentru a asigura unicitatea cheii primare. II.4. Asocierile 1:1 Reprezinta asocierile 1:1 intre relatiile puternice SOT (IdSot, Nume, Prenume) SOTIE (IdSotie, Nume, Prenume) Aceasta asociere se poate implementa:

j. cu chei straine:

cheie in prima relatie care refera relatia a doua cheie in a doua relatie care refera prima relatie SOT (IdSot, ,IdSotie) SOTIE(IdSotie, Nume,) Aceasta asociere 1:1 este considerata un caz particular al unei asocieri N:1.

g. o relatie de asociere caz particular al asocierii M:N CASATORIE(IdSot, IdSotie,)

Proiectarea relatiilor normalizate In modelul relational si SGBD se admit numai relatii normalizate: cele care respecta reguli de normalizare. Exista grade diferite de normalizare, nivelul cel mai de jos este normalizarea in forma normala 1 (FN1). Pentru ca o relatie sa fie in FN1:

valoarea atributelor trebuie sa fie atomice dpdv semantic: se refera la o caracteristica a domeniului peste care este definit atributul respectiv; un atribut ia o singura valoare (este un scalar, nu un vector). Ex:

Acest aspect de adaugare de relatii suplimentare apare in mai multe situatii, ingeneral atunci cand sunt necesare detalieri ale relatiilor din BD. Proiectarea logica a relatiilor continua cu normalizarea lor. Operatii relationale Bazele de date sunt concepute pentru a prelucra interogarile, in principal. S-au dezvoltat limbaje de manipulare a datelor (cunoscute si sub numele de limbaje de interogare). De ex, SQL poate fi numit si limbaj de interogare. Limbajele de manipulare a datelor fac parte din categoria limbajelor concrete, implementate in diferite SGBD-uri. S-a pornit la inceput cu niste limbaje abstracte de interogare, ce definesc operatii asupra relatiilor. Exista doua tipuri de astfel de limbaje abstracte: h. Algebra relationala Prevede un set de 8 operatii relationale, ce au proprietatea de inchidere (rezultatul unei operatii relationale este tot o relatie). Algebra relationala este mai aproape de formularea in limbajul formal al interogarilor. i. Calculul relational Se bazeaza pe calculul predicatelor:

calculul relational al tuplurilor; calculul relational al domeniului;

Cele trei limbaje abstracte sunt echivalente din punct de vedere al capacitatii de interogare (daca avem o interogare formulata in algebra relationala, se poate gasi o interogare echivalenta in calculul relational al tuplurilor sau al domeniului si invers).

Calculul relational cuprinde o definitie a rezultatului. Un limbaj de interogare se numeste COMPLET RELATIONAL daca implementeaza toate operatiile unuia din limbajele abstracte de interogare. De obicei, SGBD-urile ofera limbaje mai mult decat complet relationale, deoarece cuprind si multe aplicatii diferite de cele teoretice. Limbajele de interogare se bazeaza fie pe un limbaj, fie pe o combinatie. Ex:

limbajul ISBL/IBM (Information System Base Language) este bazat pe algebra relationala; limbajul QUEL/Ingrus este bazat pe calculul relational al tuplurilor; limbajul QBE (Query By Example = Access) este bazat pe calculul relational al domeniului; limbajul SQL2 este bazat in cea mai mare parte pe algebra relationala, dar exista si operatii bazate pe calculul relational.

Algebra relationala Cele 8 relatii al algebrei relationale pot fi impartite in:

operatii pe multimi: acele operatii in care se considera doar proprietatea de multime a relatiei si nu se considera structura unui tuplu:
o o o o

reuniunea; intersectia; diferenta; produsul cartezian;

operatii relationale speciale: se tine seama de structura tuplului:

o o o

restrictia (restriction, selection); proiectia (projection); jonctiunea, cuplarea (joint);

diviziunea (division).

Operatii pe multimi Toate operatiile pe multimi sunt binare.

Reuniunea Fiind date doua relatii R si S, reuniunea T=R U S este o relatie ce contine toate tuplurile ce apartin fie primei relatii, fie celei de-a doua, fie amandurora. R si S trebuie sa fie compatibile. Doua relatii sunt compatibile daca au acelasi numar de atribute si atributele corespunzatoare sunt compatibile din punct de vedere semantic: sa poata fi comparate. Sintaxa SQL: UNION [ALL] SELECT lista_atribute_1 FROM tabel_1 [WHERE conditie_1] UNION SELECT lista_atribute_2 FROM tabel_2 [WHERE conditie_2] Ex: Tabelul ANGAJAT(IdAngajat, Nume, Prenume, Adresa,) Tabelul FURNIZOR(IdFurnizor, Nume, Prenume, Adresa, ) SELECT Nume, Prenume FROM ANGAJAT WHERE Adresa=Bucuresti UNION [ALL] SELECT Nume, Prenume FROM FURNIZOR WHERE Adresa=Bucuresti Optiunea [ALL] produce rezultatul intregii operatii cu tupluri duplicat (daca exista, de ex, in ANGAJAT(Nume=Popescu, Prenume=Ion) si in FURNIZOR(Nume= Popescu, Prenume=Ion), vor aparea ambele tupluri). SQL nu respecta deci complet restrictiile modelului relational, in sensul ca admite si tupluri duplicat. Reuniunea este comutativa si asociativa: RUS=SUR

R U (S U V) = (R U S) U V

Intersectia Fiind date doua relatii R si S, intersectia T=R S ce contine acele tupluri de apartin atat lui R cat si lui S. R si S trebuie sa fie compatibile. Intersectia are proprietatea de comutativitate si de asociativitate. Sintaxa SQL: INTERSECT SELECT lista_atribute_1 FROM tabel_1 [WHERE conditie_1] INTERSECT SELECT lista_atribute_2 FROM tabel_2 [WHERE conditie_2]

Diferenta Fiind date doua relatii R si S, diferenta T = R-S contine toate tuplurile ce apartin lui R dar nu apartin lui S. Diferenta nu este nici comutativa, nici asociativa. Sintaxa SQL: MINUS SELECT lista_atribute_1 FROM tabel_1 [WHERE conditie_1] MINUS SELECT lista_atribute_2 FROM tabel_2 [WHERE conditie_2]

Produsul cartezian

Reprezinta o adaptare a produsului cartezian din matemetica, definit astfel: T=RxS={<a,b>| aR, bS} Fiind date doua relatii R(A1, A2,,An) si S(B1, B2, , Bm), produsul cartezian T=RxS= T(A1, A2,,An, B1, B2, , Bm). Proprietate a produsului cartezian: un tuplu al relatiei rezultat se formeaza prin concatenarea valorilor atributelor unui tuplu din prima relatie cu valorile atributelor

fiecarui tuplu din a doua relatie. Conditia este ca numele atributelor sa fie diferite. Daca nu sunt diferite, se redenumesc (sau se califica atributul cu numele relatiei). Proprietatile produsului cartezian: k. comutativitatea: R x S = S x R; l. asociativitatea: (R x S) x V = R x (S x V); m. gradul produsului cartezian este egal cu suma gradelor celor doua relatii; n. cardinalizatea (nr de tupluri) este egal cu produsul cardinalitatilor celor doua relatii o. produsul cartezian reprezinta operatia de baza pentru jonctiuni. Sintaxa SQL: a) SELECT * FROM R, S; => SELECT * FROM ANGAJAT, SECTIE; b) SELECT lista_atribute FROM R, S; lista_atribute: numele identice trebuie redenumite (calificate) SELECT IdAngajat, Nume, Prenume, DN, Adresa, Salariu, ANGAJAT.IdSectie [AS] AidSectie, SECTIE.IdSectie, Denumire, Buget FROM ANGAJAT, SECTIE.

6.1.2. Operatii speciale ale algebrei relationale i. Restrictia: o operatie unara. Se face o selectionare a unor tupluri a unei relatii, dupa un criteriu. Notatie: T=(R) : operator de restrictie; : conditia de selectie. este o expresie ce va fi evaluata la o valoare logica, ce se obtine folosind o secventa de operatori logici (NOT, AND, OR) si operanzi cu valoare logica (TRUE, FALSE, NULL).

Notam: #=operator logic (NOT, AND, OR); v1, v2,, vn=variabile logice =operator de comparatie (=,!=,<,>,<=,>=) Atunci, =v1#v2##vn, unde vi este rezultatul unei operatii de comparatie Obs: h. In relatia rezultata sunt introduse acele tupluri pentru care ia valoarea TRUE (nici FALSE, nici NULL); i. Operatia de comparatie se aplica fie valorilor a doua atribute, fie se compara un atribut cu o constanta. In general, se dezvolta conditia prin componentele sale conjunctive: = cond_1 AND cond_2 AND AND cond_n, ceea ce va conduce la: T=(R)= cond_1(R)( cond_2(R)( cond_3(R)(( cond_n(R)))) Proprietatea de mai sus se numeste proprietatea de splitare a restrictiei Sintaxa SQL: SELECT * FROM R WHERE conditie Proprietati:

gradul relatiei rezultate dupa restrictie este egal cu gradul relatiei initiale; cardinalitatea este cel mult egala (de obicei mai mica) decat cardinalitatea relatiei initiale; in termeni SQL, restrictia selecteaza o parte din linia unui tabel.

B. Proiectia

Prin proiectie se selecteaza o parte din atributele unei relatii. In termeni SQL, se selecteaza o parte din coloanele unui tabel. Notatie: T=lista_atribute(R). T va contine numai atributele din lista. Sintaxa SQL: SELECT lista_atribute FROM tabel; lista_atribute nu contine toate atributele lui R. Proprietatile proiectiei:

gradul relatiei rezultate este mai mic decat gradul relatiei initiale; cardinalitatea ramane nemodificata; daca lista_atribute contine o cheie, atunci numarul de tupluri rezultat este egal cu numarul de tupluri al relatiei initiale; daca lista_stribute nu contine nici o cheie, se pot obtine tupluri duplicat (in SQL). Eliminarea duplicatelor se face cu ajutorul clauzei SELECT [DISTINCT]

C. Jonctura (jonctiune, cuplare) = JOINT Este o operatie binara. Operatia combina tupluri din cele doua relatii, va rezulta tot o relatie. Jonctiunea seamana cu produsul cartezian. C1) -Jonctiunea este o jonctiune intre doua relatii R si S Notatie: Q=RS este o conditie data printr-o expresie logica ce se evalueaza la o valoare logica. = cond1 AND cond2 AND AND condi AND
a.

condi este o variabila logica ce este rezultatul unui operator de comparatie asupra a doua atribute Ai (din R) si Bi (din S), condi = Ai Bi.

b. {=, !=, <, >, <=, >=} Relatiile R si S sunt:

R(A) , A={A1, A2, ,An} S(B), B={B1, B2, ,Bn} Q(A,B) este o relatie definita pe reuniunea atributelor A si B (diferite, chiar daca perechile (Ai, Bi) trebuie sa fie compatibile). -Jonctiunea mai poate fi scrisa si: Q(A,B)=(R x S) Un tuplu al relatiei -jonctiune se formeaza prin concatenarea unui tuplu din R cu un tuplu din S daca cele doua tupluri respecta conditia . Nu se introduc in rezultat cele ce nu indeplinesc conditia si toate tuplurile ce contin NULL in unul din atributele comparate. Sintaxa SQL: -jonctiunea dintre R si S: SELECT * FROM R, S WHERE cond Ex: SELECT * FROM ANGAJAT, SECTIE WHERE ANGAJAT.IdSectie=SECTIE. IdSectie

C2) Echijonctiunea Echijonctiunea este o jontiune in care operatorul de comparatie este = (egalitate). C3) Jonctiunea naturala Jonctiunea naturala este proiectia unei echijonctiuni ce permite eliminarea coloanelor cu valori identice. Notatie: Q = R S Fiind date R(A1, A2, , An, B1, B2, , Bm) S(B1, B2, , Bm, C1, C2,,Ck) unde B1, B2, , Bm sunt atribute comune ale celor doua relatii, rezultatul jonctiunii naturale va fi: Q = R S = Q(A1, A2, , An, B1, B2, , Bm, C1, C2,,Ck)

Sau, altfel spus, Q = A1, A2, , An, B1, B2, , Bm, C1, C2,,Ck R.B1=S.B1 AND AND R.Bn=S.Bn (R x S) Proiectia ce se face elimina atributele duplicat. Daca se considera atributele comune identice, se poate considera ca atributele relatiei rezultat sunt reuniunea celor doua multimi de atribute ale operanzilor. Obs:

Gradul relatiei obtinute ca rezultat al jonctiunii naturale (q): Q=n+m+k < (n+m) + (m+k)

Cardinalitatea: numarul de tupluri ale relatiei Q: 0 NQ NR*NS

De regula, jonctiunea naturala se realizeaza intre o relatie ce refera si relatia referita (cheie straina egala cu cheia primara) Se completeaza, prin jonctiunea naturala, informatiile din tupluri cu informatii aditionale.

Proprietatile jonctiunii:
o o

comutativitatea: R S = S R; nu intotdeauna este asociativa: (R S) T R (S T)

Sintaxa SQL: Jonctiunea naturala dintre R si S: SELECT lista_atribute FROM R, S WHERE cond D. Diviziunea Diviziunea este o operatie binara. Fiind date doua relatii R(A,B) si S(B), unde:
o

A,B multimi de atribute simple (cu un sg element) sau compuse (cu mai multe elemente) atributele lui S sunt o submultime a atributelor lui R,

se poate face operatia de diviziune:

Q = R S = Q(A) Se mai poate scrie ca: Q = A R.B (R) Din relatia R se retin numai tuplurile ce au atributul B egal cu atributul B al unui tuplu oarecare din S si acele tupluri se proiecteaza astfel incat se obtin numai atributele A. Proprietatile diviziunii: - diviziunea nu este nici comutativa, nici asociativa.

Operatiile algebrei relationale (concluzii) E.F.Codd a propus 8 operatii de baza in algebra relationala (si redenumirea):

5 operatii primitive: a. reuniunea; b. diferenta; c. produsul cartezian; d. restrictia; e. proiectia

3 operatii ce pot fi exprimate pe baza operatiilor primitive:

o o o

jonctiunea (proiectia unei restrictii a unui produs cartezian); diviziunea (proiectia unei restrictii a unei relatii); intersectia R S = R (R S)

Formularea interogarilor in algebra relationala O interogare este ceruta de un beneficiar al bazei de date (utilizator), intr-un limbaj natural. De ex, Care sunt numele si prenumele angajatilor cu salariu > 3000?. Pasii urmati pentru realizarea unei interogari sunt:

j. proiectarea modelului bazei de date; k. proiectarea relatiilor si a asocierilor; l. proiectarea interogarilor: a. transformarea interogarii din limbaj natural intr-un limbaj abstract de interogare (algebra relationala sau calcul relational); b. transformarea din limbaj abstract intr-un limbaj concret. Interogarea in algebra relationala Sunt necesare:
o o o

lista atributelor relatiei rezultat; lista relatiilor (tb sa contina toate atributele necesare); conditia pe are trebuie sa o indeplineasca tuplurile rezultatului (operaiile de comparatie aplicate atributelor)

Atributele necesare provin din lista atributelor necesare si din lista atributelor asupra carora se aplica operatorii de comparatie. Intr-o interogare intervin:

identificatori (nume de relatii si atribute); constante; operatori:

o o o

ai algebrei realtionale: U, , -, x, , , , ; de comparatie: <, >, =, ; logici: AND, OR, NOT

O expresie de algebra relationala ce contine toate aceste elemente si ne da raspuns la toate cerintele va constitui o interogare (expresia sa in algebra relationala). Exista doua situatii ale interogarilor in algebra relationala:

j. interogare pe o singura relatie: daca toate atributele necesare se gasesc intr-o singura relatie; k. interogare pe doua sau mai multe relatii: relatiile contin tot ceea ce este necesar (toate atributele). De regula, relatiile sunt asociate. Cel mai frecvent, o interogare se exprima printr-o forma:

Q = lista_atribute (RS)
Interogari pe o singura relatie Interogarile au forme diferite pentru fiecare limbaj:

Limbaj natural: Care sunt numele si prenumele angajatilor cu salariul 3000?

Limbajul algebrei relationale: Q = Nume, Prenume Salariu>=3000 (ANGAJAT)

Limbajul SQL: SELECT Nume, Prenume FROM ANGAJAT WHERE Salariu>=3000;

Interogari pe doua sau mai multe relatii a. Limbajul natural:

Care sunt numele si prenumele angajatilor care lucreaza in sectia Cercetare? b. Limbajul algebrei relationale: Q = ANGAJAT . Nume, Prenume SECTIE . Nume=Cercetare (ANGAJAT SECTIE) c. Limbajul SQL:

SELECT ANGAJAT.Nume, Prenume FROM ANGAJAT, SECTIE WHERE ANGAJAT.IdSectie=SECTIE.IdSectie AND SECTIE.Nume=Cercetare Obs: se introduc atat conditia necesara pentru selectare, cat si pentru restrictie, conectate prin AND. Indexarea relatiilor Se pot defini urmatoarele structuri de organizare a relatiilor, care permit executia mai eficienta a interogarilor si a celorlalte operatii: un index primar; - zero, unul, sau mai multi indecsi secundari. Indecsii tin mai degraba de nivelul fizic intern al datelor, intrucat se ocupa cu modul de memorare a datelor in fisiere. Indecsii se pot defini la nivel conceptual, intrucat prin instructiunea de creare a tabelelor se creaza indecsi. Scade astfel nivelul independentei datelor. Modul in care sunt definiti indecsii influenteaza puternic eficienta de executie. Este normal ca decizia de indexare sa poata fi luata de catre proiectant. Etapa de definire a indecsilor poarta denumirea de aspect de proiectare fizica a relatiilor (bazei de date). Prin indexare se stabileste o ordonare in cadrul relatiei. O relatie este o multime de tupluri; multimea nu presupune nicicum ordonarea tuplurilor elementelor sale. Multimea se reprezinta printr-o colectie de date: daca alegem o colectie neordonata de N tupluri, toate operatiile de baza: cautarea (element), indexarea (element), stergerea (element) dureaza un anumit timp de cautare TNS, proportional cu numarul de tupluri: TNS = KNS*N = O(N) (pentru cautare) TNS = O(n) (pentru stergere) TNI = O(n) (pentru indexare) s-a studiat reprezentarea multimii prin colectii ordonate. In acest caz, ordonarea se face dupa o componenta a unui element al multimii numit eticheta. etichetele sunt reprezentate ordonat

Vector (tablou) Posibilitatea de ordonare a elementelor prin indexul din tablou:

O astfel de reprezentare da rezultate destul de slabe. Timpul de cautare printr-un vector de cautare: este posibila aplicarea unui algoritm de cautare binara: Trs = Krs * log N = O(log N) Timpul pentru un vector de inserare: Tvi = Kvi * log N + Kvi * N = O(N) Termenul Kvi * N apare de la deplasarea elementelor in cazul in are elementul se introduce pe prima pozitie. Timpul pentru vectorul de stergere: Tvs = O(N). Toate aceste aprecieri sunt din punct de vedere conceptual. Lista inlantuita pentru reprezentarea colectiilor ordonate

Timpul de cautare in lista: TLS = KLS*N = O(N) = TLI = TLD F. Arborii binari ordonati In realitate, bazele de date folosesc alti arbori: arbore echilibrat (balanced tree : BTree).

Conditia este ca eticheta unui nod sa fie mai mare decat eticheta din subarborele stang si mai mica decat cea din subarborele drept. TTS = KTS * logN = O(logN), TS=tree search Se demonstreaza simplu ca si: TTI = TTD = O(logN). Arborii B-Tree sunt folositi pentru indexare Tabele de dispersie (hash-table) Reprezinta o combinatie de vectori in liste inlantuite. Fie N tupluri si eticheta X a fiecarui element. O tabela de dispersie se poate defini astfel: "B grupuri (buchets) in care sunt grupate elementele".

Fiecare grup contine, in medie, N/B elemente si anume acele elemente care au aceeasi valoare de hash b. (valoare de dispersie). Valoarea de dispersie b se calculeaza aplicand o functie de dispersie (h) etichetei elementului: b=h(X). Functia de dispersie depinde de tipul etichetei Tabela de dispersie este compusa dintr-un vector cu b elemente in fiecare pozitie fiind memorat un pointer catre primul element al buchetului, acestea fiind reprezentate ca liste inlantuite:

THS = KH + KHS * (N/B) KH=timpul de calcul al buchetului THS = O(N/B) B se ajusteaza astfel incat sa obtinem performante cat mai bune (nu este constanta). Se observa ca timpul scade proportional cu B fata de timpul pentru o lista inlantuita: THS = O(N/B) hash table TTS = O(logN). Indexul primar Daca se defineste un index primar pe o relatie, acest index primar este folosit pentru stocarea ordonata a tuplurilor. Ordonarea se face folosind ca eticheta de ordonare atributele pe care este definit indexul primar. Indexul primar determina modul de stocare al tuplurilor (!!!). Indecsii sunt caracteristici ce depind de SGBD, nefiind nici macar standardizati. In standardul SQL nu se specifica nimic de indexare. In schimb, orice implementare de SGBD foloseste indecsii. O indexare corecta si eficienta poate sa conduca la o executie cu cateva ordine de marime mai eficienta a interogarilor. Majoritatea SGBD-urilor au obiceiul sa creeze un index pe cheia primara (index primar). Avem o stocare ordonata a tuplurilor care presupune ca acel SGBD foloseste un hash-table. Indexul secundar se introduce pe unul sau mai multe atribute ale unei relatii, care formeaza impreuna eticheta dupa care se face o alta ordonare decat cea initiala care se memoreaza intr-o structura separata, numita "index secundar". Un index secundar este o multime de perechi (V,L) in care V reprezinta eticheta de perechi ordonate, numita eticheta de ordonare, compusa din unul sau mai multe atribute; L reprezinta adresa din indexul primar unde este memorat tuplul.

Ex: Vom avea un index secundar si atributul "Nume". Indexul va fi organizat ca arbore binar ordonat. Ordonarea in cadrul sirului de caractere este o ordonare lexicografica.

Cautarea dupa atributul "Nume" este o cautare accelerata O(logN). Indecsii secundari pot fi: unici (UNIQUE), insemna ca nu exista doua tupluri cu aceeasi valoare a atributelor de indexare: cheie alternativa (unica, secundara); neunici: in fiecare nod pot exista mai multe elemente cu aceeasi valoare a etichetei: strucuta adecvata unei astfel de stocari. Am adaugat doi studenti (Marin Ion, Marin Alexandru), nodul "Marin" se modifica astfel:

Ori de care ori se introduce sau se sterge un element, trebuie actualizat fiecare din indecsii secundari existenti. Indexul secundar: accelereaza acele interogari in care se conditioneaza atributele indexului; consuma spatiu de memorie; creste timpul de adresare si de stergere a tuplurilor: SE ADAUGA INDECSI SECUNDARI NUMAI PE ATRIBUTELE CELE MAI UTILIZATE DE INTEROGARI (NUMAR CAT MAI MIC POSIBIL). Moduri de introducere

Constrangerea UNIQUE, care defineste o cheie alternativa unica, este folosita de foarte multe SGBD-uri pentru a defini un index unic pe acel element;

CREATE [UNIQUE] INDEX nume_index ON nume_tabel (lista_atribute)

Acestea sunt aspectele conceptuale ale indexarii. In realitate, indexarea este mai complexa, pot sa fie definiti indecsi pe mai multe nivele sau indecsi de grupare (clustering). Prelucrarea si optimizarea interogarilor O interogare: pentru utilizator, reprezinta o modalitate de a gasi niste informatii: o intrebare in limbaj natural; dpdv al proiectantului (si al programatorului), interogarea este transformata intr-o expresie de algebra relationala (sau calcul relational), careia ii corespunde o comanda (sau mai multe), pe care le transfera SGBD-ului; dpdv al SGBD-ului, este un program care contine una sau mai multe instructiuni (comenzi) SQL. Rezolvarea interogarii in SGBD implica parcurgerea mai multor etape, folosind mai multe componente software de executie in timp real a SGBD-ului: un compilator de comenzi SQL (ia comanda SQL si o transforma intr-o secventa de instructiuni executabile). Compilarea instructiunilor SQL este obisnuita; un optimizator de interogari: putem avea mai multe expresii si rezultate ale compilarii pentru aceeasi expresie. Optimizatorul alege cea mai buna forma pe baza algoritmilor genetici; generarea de cod executabil; executia comenzilor (a interogarii); returnarea rezultatelor. Normalizarea relatiilor Normalizarea este o operatie efectuata in cadrul proiectarii logice a bazelor de date: definirea schemelor conceptuale (logice) ale relatiilor. Exista proiectari: Proiectare logica "de sus in jos" (top-down) Se porneste de la schema conceptuala de nivel inalt (diagrama E-A) si se transpune in model relational: definirea schemelor logice ale relatiei; Proiectare logica "de jos in sus" (bottom-up) Se defineste mai intai o relatie universala (o schema de relatie ce contine toate atributele). Va fi apoi descompusa dupa anumite criterii logice. Definirea schemelor relatiilor nu reflecta suficient de exact realitatea modelata. Pe langa schemele de relatii se mai definesc anumite constrangeri, conditii:

constrangeri inter-relatii (cheie straina); constrangei intra-relatie (cheie primara, CHECK, NULL); dependente de date: intre atributele aceleiasi relatii Normalizarea relatiilor stabileste criterii de proiectare a relatiilor, criterii definite pe baza dependentelor de date. Se specifica astfel cate de "bune" sunt relatiile. Dependentele de date stabilesc formele normale ale relatiilor. Codd a propus initial 3 forme normale ale relatiilor: FN1, FN2, FN3. Ulterior, au mai aparut FNBC (Boyce-Codd) definita pe baza dependentelor dintr-o relatie, FN4 pe baza dependentelor multivalorice si FN5 pe baza dependentelor de jonctiune. FN1FN2FN3FNBCFN4FN5 formeaza o colectie ordonata: daca o relatie este in FN2, este implicit si in FN1; daca o relatie este in FN3, este implicit si in FN1 si in FN2. Fiecare forma normala impune anumite conditii asupra dependentelor respective, din ce in ce mai restrictive, ce conduc la eliminarea (reducerea) redundantelor datelor in relatii si la eliminarea (reducerea) anomaliilor ce provin din redundanta. Normalizarea relatiilor este un proces de analiza a relatiilor (dependente de date). Unele din dependentele de date provoaca anomalii si redundante, eliminate prin normalizare. Normalizarea se executa prin descompunerea relatiilor: cu respectarea anumitor conditii ce se refera la dependentele de date dependente functionale. 9.1 Dependente functionale Se stabilesc de catre proiectant, pornind de la semnificatia datelor. Anomaliile care pot s apar sunt :

de inserare - nu se pot insera datele unui angajat daca el nu lucreaza la un proiect (!): Proiect este cheie primara in relatie (NOT NULL); de stergere - daca dispare un proiect (de ex Proiect2, se pierd informatiile despre Marinescu Eugen); de actualizare - daca se schimba datele unui angajat, vor trebui schimbate toate tuplurile respective.

Redundanta si anomaliile provin din faptul ca relatia se afla in FN1. Solutia este descompunerea relatiei: APA(IdAngajat, Nume, Prenume, Adresa) + P(IdAngajat, Proiect, Ore)

Dispare astfel redundanta si anomaliile. Dependente functionale (cont) O dependenta functionala este o constrangere pe care trebuie sa o indeplineasca atributele unei relatii (de tip intra-relatie). Pe baza dependentelor functionale, se determina modul in care se efectueaza normalizarea, pana la FNBC. Definitie: Fiind data o schema de relatie R={A1, A2,,An} si fie doua submultimi X, Y ale lui R, se spune ca X determina pe Y (XY) daca pentru orice valoare a lui X exista o singura valoare a lui Y. Se mai spune si ca "exista o dependenta functionala de la X la Y" sau "X este un atribut determinant si Y este un atribut determinat". Notiuni: a. dependenta functionala triviala:: Y submultime a lui X (nu exista nici o constrangere, este indeplinita intotdeauna); b. dependenta functionala partiala: exista o submultime Z din X a. i. ZY; c. dependenta functionala totala: u exista nici o submultime Z a lui X a.i. ZY.

Normalizarea relatiilor O relatie se afla intr-o forma normala daca dependentele functionale respecta anumite conditii. Exprimare: normalizare (forma normala) a relatiei; normalizare (forma normala) a schemei relatiei. Forma normala este o proprietate invarianta, o poseda orica stare a relatiei si, de fapt, este o proprietatea schemei relatiei. Formele normale care depind (sunt impuse) de dependentele functionale sunt: FN1, FN2, FN3 si FNBC. Forma normala FN1 O schema de relatie sau o relatie este in FN1 daca orice atribut ia valori atomice si scalare. Modelul relational impune relatii in FN1. Forma normala FN2 O schema de relatie R este in FN2 daca este in FN1 si orice dependenta functionala a unui atribut neprim fata de o cheie a relatiei este totala.

FN2 exclude dependentele functionale partiale fata de cheie a atributelor neprime. Aplicam proprietatea de tranzitivitate: {IdAngajat, IdProiect}Nume

AP nu este deci in FN2 (avem o dependenta functionala partiala intre IdAngajat si Nume). Normalizarea lui AP prin descompunere: a. Ce forma normala au A si P? b. Descompunerea conserva dependentele functionale? Da c. Descompunerea conserva informatia? c. Folosim regulile lui Ullman care ne spun ca o descompunere a unei relatii in doua relatii conserva informatia daca: (R1 R2) R1-R2 sau (R1 R2) R2-R1 AP={IdAngajat} A-P={Nume, Prenume, Adresa} In relatia A={IdAngajat, Nume, Prenume, Adresa}, FA={a), b), c)} si datorita proprietatii de reuniune a dependentelor functionale se poate scrie: IdAngajat{Nume, Prenume, Adresa}, deci descompunerea este cu conservarea informatiei. Descompunerea este reversibila. Forma normala FN3 O schema de relatie R este in FN3 daca este in FN2 si nu exista nici o dependenta functionala a unui atribut neprim fata de un alt atribut neprim ale relatiei. Ex: AS={IdAngajat, Nume, Prenume, Adresa, Functia, Salariu} este in FN1 F: a) IdAngajatNume; b) IdAngajatPrenume; c) IdAngajatAdresa; d) IdAngajatFunctie. Forma normala se discuta in raport cu o multime de dependente functionale. Daca se impune conditia ca in institutia respectiva toti salariatii cu aceeasi functie sa primeasca acelasi salariu, atunci avem: e) FunctieSalariu.

In ce forma este? Este in FN2? Se calculeaza cheia : PK={IdAngajat}. Nu exista nici o dependenta functionala partiala, deci relatia este in FN2. Dependenta FunctieSalariu este o dependenta a unui atribut neprim care determina un alt atribut neprim, deci relatia nu este in FN3. Forma normala FNBC O schema de relatie R este in FNBC in raport cu o multime de dependente functionale F, daca in orice dependenta functionala XY din F*, X este o cheie a relatiei R. Toate dependentele sunt determinate de chei Acest lucru simplifica proiectarea deoarece: Relatiile in care toate dependentele functionale sunt determinate de chei au mai putine redundante; Constrangerile pe care le reprezinta dependentele functionale pot fi verificate de SGBD. Normalizarea inseamna descompunere in mai multe scheme de relatii cu grad mai scazut. Interogarile necesita mai multe operatii de jonctiune. Proiectarea relatiilor este un compromis intre anomaliile de actualizare si numarul de operatii de jonctiune necesare la interogari. Proiectantul poate alege forma de normalizare dorita, dar trebuie sa asigure si respectarea constrangerilor date de dependentele functionale. Which Database is Right for the New Information System Scopul acestui paragraf este de a modul de a construi un IS scalabil pentru aplicaii economice bazate pe tranzacii care sunt puternic scalabile , pe Intrenet , utiliznd tehnologiile best-of-breead , n vederea oferirii de funcionaliti noi care ncapsuleaz i stratific investiiile din sursele de date i servicii existente. Deoarece aceste sisteme noi se bazeaz , cu adevrat pe tehnologiile obiect , acestea sunt obligate s utilizeze date tradiionale , care nu sunt obiecte.

Rspunsul la ntrebarea crucial relativ la care sunt bazele de date cele mai adecvate pentru noile sisteme informaionale trebuie s in cont de aceste aspecte . Aceste baze de date vor fi utilizate pentru metadate i depozitare de procese , pentru arhivare , pentru componente complexe , noi ui mai mult aduce n actualitate ntrebarea legat de modul n care managementul bazelor de date relaionale tradiionale (RDBMS) rmne adecvat acestor noi necesiti. Pe fond bazele de date relaionale se constituie ntr-un set de baz de tabele , care sunt considerate iruri ordonate de celule. Coloanele definesc structura tabelei , iar liniile vor conine datele . Conceptualitatea acestora se reduce , n substan la aceste aspecte. Acesta nseamn o forare a descrieri i abordrii lumii reale n termeni de tabele , iar modelul datelor va trebui proiectat n aceste concepte , simpliste , n substan. Pentru a fi capabili de construcia unor tabele de date complexe , este necesar atribuirea unor semnificaii deosebite unor coloane . de exemplu , un set de coloane va permite identificarea unic a unei linii n tabela A. acesta reprezint cheia primar. Acest cheie primar trebuie duplicat ntr-o alt tabel B , pentru a reconstrui informaie complex . aceste coloane vor avea restricii de integritate referenial asupra cheii primare a lui A. Coloanele duplicate n B au o cheie secundar , pe cheia primar a lui A. La compunerea unei linii din B cu o linie din A , utiliznd valorile comune ale cheilor primare i secundare , se realizeaz , de fapt un join . n cazul n care n A nu se definete nici un indice pe cheie primar din A ,aceast operaie are coosturi exponeniale , deoarece maina este obligat s baleieze toate liniile din A . Dar chiar i cu definirea de indici , acest operie poate s devin foarte costisitoare , n cazul n care sunt cuprinse n join prea multe tabele.( n mod obinuit 10) . Orice programator n relaional tie c atunci cnd exist prea multe clauze de join n seciunea where a unei declaraii SQL , ordinea n care aceste clauze sunt citate , devine esenial pentru timpul de rspuns. Singura cale de a lega linii care provin din tabele diferite este de a duplica , manual , valori din coloanele cheie. Dei se pot lega linii i coloane care nu sunt incluse n chei , acesta se poate produce numai pentru cazurile n care modelele datelor sunt independente de modalitatea n care datele sunt utilizate. De altfel u join pe coloane care nu sunt cheie este lipsit de sens. Aceasta este de asemenea adevrat pentru operatori care sunt alii dec-t equal. SQL Un alt element important pentru sistemele relaionale se refer la susierea unui limbaj de interogare declarativ normalizat : SQL . Acest limbaj a fost proiectat i a avut un succes remarcabil pentru a trata modelul relaional . Acesta permite inserarea , actualizarea i tergerea liniilor (data Manipulation Language) i pemite programatorilor s adauge sau s elimine coloane , tabele i indici (Data Definition Language) De fapt SQL este pe de o parte prea complicat pentru utilizatorii simplii i prea limitativ pentru programatorii experimentai. De asemena portabilitatea SQL este mai mic dect cea enunat : chiar interogrile asupra datelor sunt diferite pe fiecare implementare. Fiecare furnizor de SQL este constrns n a defini extensii ale SQL care s fac sistemul funcional. Este evident c aceste extensii nu sunt normalizate . Din punctul de vedere al programatorilor , aceste probleme legate de SQL constau n aceea c acest limbaj declarativ nu este integrat suficient de bine cu limbajele de programare procedurale. Arhitectura

Ultimul punct de vedere , este relativ la arhitectura sa puternic centralizat . Toate operaiunile p baza de date sunt realizate pe partea serverului , iar performana scade vizibil n momentul n care numrul de conectri simultane crete. Modelul obiect n primul rnd modelul obiect este mai bogat dect cel relaional. La nceput a fost utilizat n noile limbaje de programare , iatr mai trziu n instrumentele de modelare. n cele mai multe dintre implementrile curente , un obiect este o instaniere a unei clase . O clas apare att ca un model al crerii obiectului, ct i ca un set al tuturor instanelor acesteia. Clasele definesc cmporamentele i strile obiectelor lor . Starea este definit prin valori a unui set de atribute . Comportamentul este definit printr-un set d metode , sau funcii n termeni de limbaje de programare tradiionale. Modele obiect Modelul obiect definete datele i funciile mprun . Pe o astfel de baz , se pot aduga anumite proprieti : - ncapsularea : starea unui obiect prin cae acesta poate fi numai prin metodele respectivului obiect - motenirea : o clas poate fi definit ca o specializare a unei alteia exuistent . Aceasta , motenete , deci , starea i comportamentul clasei printe (superclasa sa ) . Poate , de asemenea s adauge metode noi sau s modifice metodele existente. - Asocierea : un obict poate referi unaltuul utiliznd referine la acesta din urm. - Polimorfism : subclase diferite pot implementa aceiai metod ; metoda corect va fi apelat n funcie de clasa actual. - Mesaj : obiectele comunic prinn intermediul mesajelor. n cele mai multe limbaje de , atributele i metodele pot fi private , publice sau prootejate . Dar n mod uzual , ntr-un proiect corect , fiecare atriv'but trebuie s fie protejat , n vederea ncapsulrii . Metodele publice definesc interfaa clasei (protocoalele sale sau un set de metode pe care alte obiecte le pot apela). Cu alte cuvinte un obiect public mai multe interfee. Alte metode sunt invizibile i sunt rezervate implementrilor interne. Interfeele obiectelor Singura modalitate de a manipula obiecte este de utiliza interfeele acestuia. Aceasta va crete dramatic calitatea sistemului : - Obiectele sunt protejate i izolate . Nici un alt programator nu poate modifica un atribut de o manier inconsistent , astfel c obiectele sunt robuste. - Obiectele implic proiectare modular la cel mai sczut nivel , astfel c obiectele sunt fiabile - Obiectele sunt auto-testabile : n cazul n care starea este eronat , este suficient inspectarea metodelor obiectului , fcnd astfel simpl nteinerea lor.

Este simpl plasarea unui nou obiect n sistem , deoarece toate interaciunile sunt corect definite n interfeele acestuia , astfel c sistemele bazate pe obiecte pot evolua rapid. - Se pot defini cunotine pe nivelul cel mai nalt i toate subclasele le vor utiliza fr necesitatea redefinirii lor , astfel c obiectele sunt eficiente - Polimorfismul evit necesitatea de a scrie structuri de control . Astfel numele metodelor sunt delimitate dinamic . Este foarte simpl adugarea de tipuri noi n sistem , fr modificarea codului d control existent , ceea ce determin posibilitatea unei evoluii rapide a obiectelor sistemului. Toate aceste raiuni explic de ce limbajele obiect sunt general acceptate de comunitatea realizatorilor de sisteme. n practic obiectele sunt mai mult utilizate pentru proiectele tehnice i ceel mai multe dintre acestea sunt interfee obiect grafice , cum ar fi windows. nc , puini realizatori utilizeaz obiecte economice , deoarce acestea sunt , de cele mai multe ori persistente i este destul de dificil stocarea acestora n baze de date tradiionale , relaionale. Printrea alte opiuni ale bazelor de date se numr i utilizarea obiectelor n baze de date relaionale . n acest sens se va considera un model obiect simplu : - companiile au un nume i un set de clieni - clienii pt fi att companii ct i persoane - o persoan este un client special cu o anumit vrst - companiile au deparatmente - un angajat este o persoan special caracterizat printr-un salariu. Devine simplu de a proiecta acest model utiliznd orice instrument UML i a genera codul surs Java asociat. Probleme apar ns n momentul n care aceste obiecte Java trebuie plasate ntr-o baz de date relaional din urmtoarele motive : - nu se pot definii motenirile - nu se pot reprezenta simplu referinele dinte obiecte Astfel , un programator va trebuii s gseasc soluii pentru a stoca i regsi obiecte substaniale ntr-un model de stocare foare srac , de exemplu utiliznd matrici bidimensionale ca n tabloare. Fundamental se pt lua n considerare trei abordri diferite pentru a trata problemele de motenire : - se poate decide stocarea fiecrei clase ntr-o tabel - se poatevdecide stocarea fiecrei ierarhii de clas ntr-o tabel - se poate decide stocarea fiecrui nivel ierarhic ntr-o tabel separat , cu gestionarea legturilor cu nivelul superior Niciuna dinte aceste abordri nu este perfect ; toate au compromisuri. n soluia 1 declaraia SELECT deevine chiar greoaie . Aceasta din cauz c atunci cnd se selecteaz obiectele Person trebuie s fie selectate obiectele Employee ,care sunt clasificate ca obiecte Person. Deci este necesar apelarea a dou SELECT i numai apoi se construiete rezultatul final. De cte ori se adaug o subclas nou trebuie adugat un nou SELECT n list pentru a putea calcula rezultatele finale.

n anumite cazuri se poate automatiza acest mecanism complex . Dac limbajul obiect suport metaclase se poate utiliza inspectarea pentru a verifica dac o clas are subclase i astfel se poate programa un o selectare recursiv.. Cu toate acestea dispare posibilitatea de a exprima simplu restriciile de integrtate refernial . Chiar cele mai simple , cum ar fi unique devin dificile , deoarece unicitatea trebuie verificat ntr-u set de tabele , iar acesta nu este o caracteristic standard a RDBMS. n cea de a doua soluie se calculeaz un set al tuturor atributelor definite n ierarhia unei clase . n consecin , se creeaz o tabel cu toate aceste atribute , la care se adaug unul nou, numele clasei creia i aparine fiecare linie . n cazul n care sunt definite nume egale de atribute n mai multe subclase , acestea devin mai dificil de gestionat . Declaraia SELECT are acelei limitri ca n soluia anterioar , n afar de cazul n care se utilizeaz un nume de clas ierarhic. n orice caz se va pierde un volum mare de spaiu disc. n cea de a treia soluie , de cte ori se produce un INSERT pentru un nou Employee , trebuie , se impune un INSERT pentru o nou Person , ceea ce conduce la definirea unei chei secundare lpe Employee pentru a face legarea acestuia de Person . Asta nseamn c , de cte ori se va face actualizarea ierahiei clasei , se impune schimbarea codului. De asemenea toate cheile primare trebuie sp fie duplicate n subclase , problem care conduce la simplificarea declaraiei de SELECT dar consum volum disc mare. Pe lng aceste probleme apar i cele legate de navigaie . Nu se pot stoca referine ( pointeri singulari sau colecii dinamice de pointeri) direct ntr-o baz de date relaional. Pe de alt parte nu se pot exprima cheile secundare n limbaje obiect . aceasta conduce la obligaia de a reconstrui referinele obiect pornind de la cheile secundare , ceea ce este o sarcin dificil i costisitoare , chiar n situaia n care graful obiectelor nu este prea adnc. n cazul cheilor secundare complexe , problema devine cel puin dificil dac nu chiar insurmontabil. Sisteme hibride Obiect - Relaional Sistemeel Obiect Relaional ofer , pe fondul lucrurilor dou caracteristici noi : - tipuri noi de date - atribute complexe Prima caracteristic permite sistemelor noi s trateze noi tipuri de date cum ar fi cele specifice multimedia , sau serii temporale , coordonate spaiale sao altele. Aceste noi tipuri de date sunt mai mult sau mai puin integrate cu structua relaional de baz i limbajele de invocare . Mai mult , acestea nu sunt orientate obiect , neexistnd o susinere pentru motenire. n concluzie , prin sistemele hibride se permite tratarea de tipuri de date mai compexe , dar nu se ofer posibilitatea de a coopera cu modele noi de date. Cea de a doua caracteristic permite crearea unei tabel noi care s aibe o tabel ca atribut . Aceasta presupune simularea unei asocieri ntr-un model obiect . Faptul este important c apare ca o soluie numai la nivelul sintaxei. Din punctul de vedere al stocrii , sunt n continuare dou tabele separate iar timpul consumat pentru regsirea informaiei este destul de mare.

Acesta , ns reprezint primul pas n calea spre sisteme obiect . n abordarea prinsimulri a sistemelor obiect peste RDBMS , calea este , de altfel destul de nesigur , avnd n vedere , pract imposibilitatea de a simula motenirea. Instrumente de reprezentare Instrumentele d reprezentare permit programatorilor s asocieze linii din tabele relaionale cu instane ale claselor (i.e. obiecte). Acestea , de asemenea , propun o s privesc dinamic liniile ca pe obiecte pure , nlocuind cheile secundare cu pointeri reali. Acesta conduce la o interesant modalitate de a utiliza datele relaionale existente n noile aplicaii obiect. La utilizarea reprezentrii modelelelor existente de date , deoarece modelele de date relaionale existente sunt foarte simple , prin definiie. Cu toate acestea rmn anumite probleme: - reprezentarea unui model obiect este o sarcin de ntindere temporal , iar produsele n domeniu ofer puin asisten. Pentru fiecare atribut al modelului obiect , trebuie indicat manual care dintre coloanele tabelei vor fi stocate , sau regsite - susin , n general algoritmi de reprezentare diferii , fiecare dintre acetia mplicnd stocarea numelui clasei odat cu coloana ceea ce nu este o soluie de proiectare prea elegant. - pointerii i coleciile sunt mapate n coloane. Maparea ID-urilor obiectelor pe cheile primare i secundare , genereaz valori interne . aceasta are caefect blocarea datelor ntr-un mecanism tare codat , black box . N cazul existenei unor erori ascunse , costul cu ntreinerea devine sever.. - maparea cheii secundare consum spaiu disc foarte mare . Acest fenomen se produce i cnd alegerea strategiei de reprezentare pretinde stocarea ntregii ierarhii a clasei ntr-o singur tabel. - Aceste instrumente nu pot elimina erorile produse n faza de reprezentare. Astfel , la asocierea atributului CustomerName cu CustomerID i nu se face notificarea vor putea trece luni pn s se descopere dezastrul. - Chiar n situaia n care codul este scris de o tre persoan abilitat , codul exist i va fi executat avnd un impact sever asupra aspectelor globale de funcionare i al timpului de rspuns vizibil. - Din cauza slabelor performane , aceste sisteme propun o mulime de optimizri i indicaii . Toate aceste reglri ale strategiei vor avea impact asupra proiectrii obiectelor. De exemplu , va fi ncrcat un ntreg graf mare , implicit , la citirea unui obiect. Acesta este obligatorie pentru simularea unei navigri transparente, dar pentru a rezolva problema este necesar utilizarea unei ValueHolder speciale , n locul unui pointer obiect simplu. n acest caz este necesar schimbarea modelului economic pentru a susine tehnologia!chair cu aceste "trucuri" , instrumentele de mapare nu ofer navigarea transparent n modelul obiect. Codul care este scris este specific instrumentului de mapare i dseori de algortm. Bazele de date de tip memorie Bazele de date de tip memorie sunt maini tranzacionale , n memorie , relaionale , care se replic ele nsele asincron ntr-o RDBMS standard , pe disc. Dar acestea sufer nc

din mai multe motive ,cum ar fi : nu susin obiecte , limitarea memoriei fizice , nu susin procesarea distribuit , nu sunt partajabile ntre mai multe instane ale serverului EJB , nu au politici active pentru a gestiona sincron memoria de depozitare cu volumele fizice , nu susin declanatori etc. Avantajele bazelor de date obiect pure ODBMS ofer o nou paradigm pentru a susine complet obiecte pe nivelul de persisten a sistemului informaional. Sunt prezentate mai jos cteva caracteristici ale ODBMS date de ODMG Stocarea unui model obiect Ideea de baz a unei ODBMS este de a stoca direct orice model obiect complex ntr-o baz de date , fr limitarea la conceptele orientate obiect susinute. ODBMS nu este o reprezentare sintactic care s antureze RDBMS , oferind gestiunea complet a bazei de date cu stocarea obiectelor fizice. Modalitatea de satocare se prezint n figura de mai jos :

ID a obiectului La stocarea unui nou obiect ntr-o baz de adte , maina i va asigna un OID (Object Identifier ) unic . n funcie de implementare , acest identificator va fi fizic sau logic , distribuit sau nu.

Mecanismul se va prezenta ca n figura de mai jos : Navigarea

Unul dinte aspectele puternice ale modelului obiect se refer la abilitatea acestui a de a defini referine , sau relaii ntre obiecte. Utiliznd limbajul obiect , aceste referine sunt implementate cu pointeri . n momentul n care se stochez un obiect , cu referine n alte obiecte , ODBMS va transforma pointerii volatili , construii n memorie , n pointeri "inteligeni" , persisteni. Pentru a se produce acest fapt , OID-urile sunt utilizate ca fiind persistente , cu referin unic. Astfel , odat ajuni n baza de date , obiectele fac referin unele la altele prin OID-uri. Odat rencrcai n memorie OID+urile devin transparent mapate n pointeri. Navigarea cu pointeri nu este numai elegant , dar i o modelitate eficient de a regsi obiecte. Se va continua cu exemplificarea anterioar. Se presupune existena unei facturi n memorie , la care trebuie s i se acceseze clientul aferent. Utiliznd SQL , este necesar scrierea unei declaraii de urmtoarea form :

Acest ir va fi trimis de ctre client la serverul RDBMS . Acesta , dup verificarea sintactic i control , va construi arborele de cutare . Optimizerul va tenta mbunptirea performanei. Apoi cererea va fi executat , iar rezultatul obinut va fi trimis napoi la client. Ca urmare , clientul va itera ntre elementele setului de rezultate i va crea obiecte Java pentru fiecare din liniile sale. Acelai eveniment se va defini n ODBMS dup cum urmeaz :

Prin simpla utilizare a unui atribut (care n acest caz este o referin la un customer) , ntro declaraie foarte simpl , customer va fi regsit n baza de date , iar n memorie va fi instaniat un obiect Java Customer. La server nu este nevoie de verificarea sintaxei sau de optimizare , deoarece atributul customer a fost stocat n interiorul obiectului Invoice n form de OID al clientului. Regsirea obiectelor prin navigare se poate derula pn la de 100 ori mai rapid dect prin utilizarea cererilor - chiar i cu indicii definii n RDBMS. La client nu mai este nevoie s se itereze i s se recreeze obiecte pornind de la linie . Transparen Transparena este o cale prin care se stocheaz i se regsesc obiecte ntr-o baz de date fr declaie explicit de cerere. Transparena se bazeaz pe OID i un mecanism intern . la ciecare utilizare a unei referine la un obiect , n cazul n care acest obiect nu se afl deja n memorie , acesta va fi automat extras de la server. Pe de alt parte , la fiecare modificare a strii unui obiect , acesta va fi actualizat n baza de date la urmtoarea nregistrare fr a fi necesar parafrazarea codului Java cu codul bazei de date.

Distribuire Anumite ODBMS susin stocarea i regsirea distribuit . Partiionarea poate fi susinut att orizontal ( fiecare clas este definit n fiecare baz de date ) sau vertical (anumite clase ntr-o baz de date , iar alte clase n alte baze de date) . Stocarea distribuit nseamn posibilitatea de a utiliza anumite politici cum ar fi Round Robin , pentru a stoca obiecte n baze de date fizic diferite. Gsirea distribuit semnific susinerea interogrilor n paralel. Distribuirea nativ este caracteristica cheie pentru scopurile de echilibrarea a ncrcrii.. Interogarea obiectelor Anumite ODBMS dispun de un limbaj de interogare care permite tartarea conceptelor obiect , cumar fi : motenirea , navigarea i distrbuirea Un astfel de limbaj poate fi i VQL(Versant Querz language ) n care se poate scrie declaraia :

n care ONLY - modificator cu semnificaia c nu se dorete ca instanaele subclaselor pentru Company s fie incluse n setul de rezultate. -> are semnificaia de a produce traversarea referinelor obiect (se include coleciile i referinele ) pe parcursul interogrii . department - este un atribut vector Java din Company manager - este o referin la obiectul Manager duin clasa Department , name - un atribut ir simplu n claa Manager IN ALL - clauz care declar c aceast interoga se va produce , n paralel , pe orice baz de date conectat , cu un singur set rezultat , construit pe latura client.

Depozitul de obiecte La ncrcarea obiectelor n memorie , fie n modul implicit , pe parcursul navigrii transparente , fie explicit , pe parcursul interogrii . acestea sunt n special ariile utilizate de JVM (Java Virtual Machine) , sub controlul unui manager obiect. OM va translata pointeri la OID i napoi , va extrage obiecte de la server , transparent , de cte ori este necesar i va marca obiectele modificate pentru ca acestea s fie stocate pe server la urmtoarea nregistrare. Atunci cnd un obiect a fost deja extras pe parcursul unei tranzacii , data viitoare va fi referit i va fi localizat foarte repede pe partea de depozit client. Implicit , acest depozit

foarte eficient , la client , va fi "curat" la finele fiecrei tranzacii , dar exist i mecanisme mult nai sofisticate . Obiecii legate de Obiect ODBMS apar , dup o astfel de prezentare ca o soluie ideal , iar ntrebare care s+ar putea pune se refer la faptul c acestea nu au fost nc complet acceptate de ctre industria TI . O parte dintre clasele de probleme care se ridic : Probleme administrative Furnizorii de ODBMS pretind c aceast soluie dispune de mecanisme de administrare care o fac foarte simpl. n opoziie furnizorii de RDBMS afirm contrariul. Adevrul este undeva pe la mijloc. ODBMS este mai rapid ,ca urmare a acestui fapt nu este nevoie de un reglaj. Cu toate acestea , ODBMS este deseori utilizat n medii n care restriciile de vitez sznt mult mmai mari i ca urmarea optimizarea este nc necesar. Managementul securitii , accesul utilizatorilor , copiile de siguiran , ocuparea discului , memoria disponibil , gradul de utilizare al hardware-ului , configurarea OS , sarcini zilnice ale administratorului de baze de date , rmn la fel ndiferent de tehnologia utilizat penru bazele de date. Multe dintre mainile ODBMS nu permit administrarea on line , iar arhitectura software se bazeaz pe DBMS tradiionale ,astfel c acestea pot fi considerate mai degrab un limbaj de partajare a resursei disc dect o main de baze de date , cu adevrat. Acesta este principalul argument pentru care muli administratori manifest o opoziie la utilizarea ODBMS. Pentru exemplificarea unei soluii n acest sens se consider tehnologia Versant , care a fost proiectat de arhiteci maturi din sfera bazelor de date . ODBMS , n particular , ofer : - arhitectura software a serverului care este foarte similar cu a unui RDBMS. De exemplu exist un mecanism de ascultare care este pus n ateptare pe un port dedicat, un proces carea acceseaz segmente de memorie partajate i multe altele. - Multe dintre sarcinile administratorilor de baze de date pot fi realizate on line - Administatorii bazelor de date pot utiliza SQL standard pentru a actualiza obiecte Necesitatea de instruire Muli dintre directorii IS rejecteaz ODBMS , n special din cauza unei instruiri iniiale de stul de ample pentru a se obine competena controlului tehnologiei . Aa cum rezult i din figura de mai jos , curba nvrii este bine echilibrat , ns , de ROI

Probleme legate de fiabilitate Este cunoscut c multe dintre implementrile ODBMS nu sunt utilizabile fiabil n medii care pretind mare disponibilitate. Cu toate acestea exist tehnologii (Versant) care au depit acest impediment - ofer un sistem complex pentru jurnalizarea sistemului , cu recuperarea automat a cderilor la startare - ofer copii de siguran pe diferite nivele distribute , on line - ofer arhivarea sesiunilor automat pentru a evita pierderile de date dup fiecare cdere sistem. Probleme de scalabilitate Este , de asemenea recunoscut c ODBMS sunt mai rapide dect RDBMS deoarece susin navigarea ntre referinele directe obiect (OID) , dar viteza nu este scalabil Ceea ce caracterizeaz mai multe dintre implementrile actualeeste un nivel srac de reea pentru transportul datelor. Aceasta conduce la o cretere dramatic a timpului de rspuns odat ce crete dimensiunea bazei de date sau apar multe tranzacii concurente , tocmai din cauz c reeua nu accept timpii neproductivi. Varianta Versant ocolete aceste neajunsuri printr-o funcionare similar cu a RDBMS pentru procesarea invocrilor i managementul indecilor . Din acest cauz i datorit faptului c soluia are o arhitectuur real de server obiect , acesta poate scala. Evaluarea ODBMS Micarea spre sistemele ODBMS a nceput s fie direcionat de un numr important de fore din industria TI . Aceste fore includ preteniile de a gestiona noi tipuri de date ,

complexe , deseori asociate cu aplicaii client-server grafice , care prefer stocarea persistent a obiectelor manevrate n limbaje de programare obiect o care necesit gestiunea acestei informaii ntr-un mediu care ofer avantajele tradiionale ale DBMSurilor. Realizatorii aplicaiilor au avut , istoric , de ales ntre dou variante de stocare a informaiei : fiiere sau RDBMS. Fiierele , prin natura lor permit programatorilor s stocheze arbitrar date complexe , fiind lipsite de abilitatea de a coordona aceesele concurente , de a gestiona date distribuite i de oferi integritate tranzacional. RDBMS ofer aceste aceste avantaje tradiionale pentru bazele de date , dar modelul de date orientate tabel este incapabil s stocheze obiectele progrmatice , n forma lor nativ. Bazele de date obiect ofer avantajele ambelor soluii : flexibilitatea de a stoca arbitrar obiecte de date complexe combinate cu fora unei adevrate baze de date. Astfel , pentru organizaiile care gestioneaz date complexe , utiliznd limbaje de programare orientate obiect , soluia de a migra datele de la convenional la tehnologiile bazelor de date obiect poate apare ca fiind surprinztor de simpl. Mai complicat apare , ns alegerea unui ODBMS particular. nelegerea subtilitilor diferitelor produse n acest sens , poate deveni consumatoare de timp i mai ales dificil. Deoarece bazele de date obiect sunt tehnologii relativ noi , poate fi dificil , din perspectiva utilizator s determina cre sunt caracteristicile relevante la evaluarea ODBMS. Categoriile de produse Toate ODBMS i produsele care par a fi astfel se ncadreaz ntr-una din urmtoarele patru catgorii. Ca urmare a faptului primul rspuns n vederea evalurii se refer la partenea acestuia la una dintre aceste categorii : ODBMS pure Produsele ODBMS pure ofer funcionalitile de baz de date tradiionale ( ex persisten , distribuie , integritate , concuren i recuperare) , dar sunt fundamentate pe un model obiect . aceste , n mod tipic , ofer identificatori de obiect , permaneni , imuabili , n vederea asigurrii integritii datelr . Acestea ofer , n general caracteristici de baze de date distribuite ( migrarea transparent a obiectului i tranzacii transparente) i de cele mai multe ori includ funcionaliti avansate pentru baze de date. La fel cu corespondentul lor relaional , acestea se livreaz cu instrumente de administrare a bazei de date integrate. ODBMS sunt cele mai utile pentru aplicaiile de gestionare orientate obiect cae trebuie s susin utilizatori multipli. Aceste aplicaii , de asemenea tind s manifeste o sum de cerine n domeniul scalabilitii , concurenei , distribuiei i/sau al performanei i penetraiei tranzaciilor . Deseori , utilizatorii care solicit ODBMS pure au tentat proiecte care utilizau RDBMS i au descoperit c modelul relaional este prea restrictiv. n alte cazuri migrarea se produce din motive de dificultatea ntreinerii unei astfel de baze de date i a fiierelor sistem aferente . Gestionarii stocrii persistente PMS (Persistent Stoarage Managers) a fost dezvoltat pornind de la cerinele proiectrii susinute de calculator (CAD) izolat i a fost proiectat pentru a gestiona stocarea persistent a unui numr relativ mic de obiecte . PMS , n mod uzual nu utilizeaz

identificatorii obiectelor permanente i astfel ofer un nivel mai sczut dect ODBMS pure pentru integritatea datelor. Aceste sisteme au fost concepute pentru a ndeplini cerinele CAD sau ale altor apicaii capabile s lucreze independent , cu date relativ puine dar cu cerine pentru concuren foarte mare. Acestea ofer , de obicei , o distribuie limitat dau cel puin greoaie , blocarea granularitii brute , gestiunea spaiului online srac i nu permit evoluia schemei . Sarcinile de ntreinere standard pentru astfel de sisteme pretind oprirea activitii bazei de date , reconfigurarea acesteia i repornirea activitii acesteia ., care poate fi un ciclu acceptabil de ntreinere pentru un sistem cu un singur utilizator., dar apar ca inadecvat pentru aplicaii cu mai muli utilizatori pentru bazele de date. n cazul aplicaiilor independente , PMS reprezint o soluie bun. n mediul multi utilizator realizatorii prefer ODBMS pure din motive legate de capacitile acestora de distribuie i multi utilizatori . PMS nu sunt , n geenral realizate pentru a ndeplini cerine ale unei piee largi i sunt de utilizat pentru scopul n care au fost proiectate , anume local , independent , persistent , aa cum este mediul CAD. Anvelopele obiect Anvelopele obiect sunt nivele software care sunt plasate peste RDBMS , n scopul de a oferi o intrefa orientat obiect pentru managerul bazelor de date relaionale bin baz. Anvelopele obiect nu au fost construite pentru aplicaii particulare ci mai degrab ca o tentativ de capitalizare a interseului tehnologiilor obiect n piaa general. Anvelopele obiect ofer anumite avantaje generice ale tehnologiei obiect , cum ar fi creterea productivitii programatorilor i reutilizarea codului. Chiar n aceste condiii problemele legate de gestiunea datelor complexe , deoarece problema de fond legat de datele complexe , specifice abandonrii activitii "pe hrtie" nu are soluie. Pentru a obine performane rezonabile , realizatorii acestor sisteme , de obicei , pun restricii severe asupra modelului de date al aplicaiei. Utilizatorii poteniali au realiza acest flux fundamental , iar anvelopele obiect se descurc greu cu aplicaiile care gestioneaz date complexe. Anvelopele obiect sunt probabil bune pentru creterea productivitii programatorilor care lucreaz cu instrumente din clasa 4GL i nu ca o clas separat de sistem de gestiune a bazelor de date. Baze de date Relaional obiectuale Muli dintre furnizorii de sisteme de gestiune a bazelor de date trebuie s fac fa entuziasmului care a cuprins piaa TI cu privirea la tehnologiile obiect. O parte au abordat acest aspect prin dezvltarea de anvelope obiect ,iar altele au tentat modificarea , b consecin a funcionalitii bazelor de date relaionale n sensul corectrii comportamentului acestora care s apar ,cel puin pe un anumit nivel al granularitii ca fiind unul specific obiectual. Aa cum predecesorii acestora cu baze de date n reea au rspuns la modelul relaional cu extinderi ale bazelor de date reea , toa aa furnizorii de baze de date relaionale rspund probocrii obiectuale cu extensii ale bazelor de date relaionale ,adic baze de date relaional obiectuale (ORDBMS) Bazele de date relaionale ofer un mediu flexibil i foarte puternic pentru gestiunea datelor de tip caracter sau numerice. Cu toate acestea nici una dintre extensiile RDBMS ( ex . declanatoare , proceduri stocate ) nu sporesc abilitatea RDBMS n ceea ce privete abilitatea modelrii i gestionrii datelor mai complexe , care fac obiectul ODBMSDe

exemplu , cazul procesurlor stocate poate oferi o form limitat a ncapsulrii care ns nu este suficient pentru mecanismele de motenire i polimorfism i astfel nu sunt capabile s ofere reutilizabilitate ,productivitate sau calitate a aplicaiei de maniera dat de tehnologia obiect. Deoarece nu susin paradigma O-O complet i nu modeleaz relaii complexe ( de exemplu 1:N , sau M:N ) de o manier satisfctpare ,. Bazele de date relaional obiectuale pot fi privite mai degrab ca fiind o soluie mai bun dect bazele de date relaionale i nu ca o limitare a bazelor de date obiectuale n sine. ORDBMS sunt foarte utile n aplicaii n care nc mai predomin RDBMS-urile Cu alte cuvinte , n nivelele inferioare extensiei oferite de bazele de date relaional obiectuale se regsesc aceleai maini relaionale cu aceleai limitri care sunt legate, n specuial de gestiunea datelor i a relaiilor complexe.

Cuadratura de mai sus devine nu numai funcional , dar i dinamic , iar echilibrul sed stabilete n egalizarea aciunilor celor patru componente. MICROSOFT ACCESS Sistemul de gestiune a bazelor de date Microsoft Access face parte din pachetul Microsoft Office. Acest pachet de programe, dedicat, dup cum arat i numele, muncii de birou, i produs de firma Microsoft, se comercializeaz n dou variante: Microsoft Office Standard conine : Editorul de texte Word Programul de calcul tabelar Excel Programul PowerPoint, destinat realizrii de prezentri Programul Outlook, care cuprinde o agend electronic, un planificator, un program de comunicaie , s.a. . n varianta Professional, pachetul conine, n plus , i sistemul de gestiune a bazelor de date Access. Exist la ora actual pe pia diverse versiuni ale acestor programe, ca i ale pachetului ca ntreg. Exist un Microsoft Office pentru Windows'95, ca i un Microsoft Office '97.

Ce nseamn OLE? OLE( Object Linking and Embedding- legarea i ncapsularea obiectelor) este un protocol de schimb de date ntre aplicaii. Aplicaiile care accept OLE sunt mprite n dou categorii: servere- aplicaii ale cror obiecte pot fi legate sau ncapsulate n alt document; clieni - aplicaii care accept obiecte ncapsulate sau legate. Nu se poate face o distincie net ntre cele dou categorii, unele aplicaii putnd fi n acelai timp i servere i clieni. (Prin obiect se nelege o entitate de informaie creat cu ajutorul unei aplicaii Windows.) ncapsularea . n prealabil, obiectul respectiv trebuie selectat i plasat n Clipboard (prin Edit, Cut sau Edit, Copy). ncapsularea se face prin selectarea comenzii Paste din meniul Edit, semnificnd inserarea unei copii a obiectului provenit din aplicaia-surs n aplicaia destinaie. Prin ncapsulare, se creeaz o copie a obiectului din documentul sursa i se transfera aceasta copie in documentul destinaie. Practic, obiectul ncapsulat nu mai are nici o legtur cu documentul sursa. Cnd se modifica obiectul ncapsulat, documentul sursa nu e afectat. Legarea. Inserarea obiectului n aplicaia-destinaie se face prin comanda Paste-Link, crend astfel o legtur ntre aplicaia-surs i aplicaia-destinaie. Crearea unei legaturi pentru un obiect din aplicaia sursa nu realizeaz o copie, ci o referina ctre documentul sursa . Cnd se fac modificri asupra obiectului legat din aplicaia destinaie, aceste modificri se reflecta in aplicaia sursa. Mai multe documente pot avea legaturi cu un acelai document sursa .De exemplu, un desen poate fi legat in mai multe documente, orice modificare asupra desenului reflectndu-se in toate aceste documente. Ce nseamn DLL? DLL (Dynamic Link Library) - biblioteci cu legare dinamic - legarea lor cu programul principal se face n momentul rulrii programului, i nu la compilarea lui ca n cazul clasic. Aceasta micoreaz dimensiunile programului, dar permite utilizarea unei mai mari varieti de funcii, care o dat construite i introduse n DLL, pot fi apelate de oricare alt program. Ce nseamn DDE? DDE (Dynamic Data Exchange) - schimb dinamic de date- mecanism care permite ca mai multe aplicaii, rulnd n medii diferite de programare, s foloseasc n comun aceleai date. Access-ul nu are un limbaj de programare propriu, toate obiectele putndu-se construi interactiv, acionnd butoane i meniuri. Pentru situaii complexe, este disponibil limbajul Visual Basic, un limbaj orientat pe obiecte i evenimente. La nivelul utilizatorilor neprogramatori, majoritatea problemelor care se pun se pot rezolva folosind doar facilitile proprii ale Access-ului.

O baz de date Access este o colecie de elemente destinate gestionrii informaiilor despre un anumit subiect sau colectate i pstrate ntr-un anumit scop. Elementele unei baze de date Access se numesc obiecte . O baz de date Access poate conine urmtoarele clase principale de obiecte: tabele interogri machete rapoarte controale macro-comenzi module. Obiectele posed proprieti, care le determin nfiarea i comportamentul, precum i metode, care indic ce operaii se pot efectua cu obiectul respectiv. Toate obiectele aparinnd unei clase posed aceleai proprieti i aceleai metode. Individualizarea lor se face prin valorile diferite atribuite acestor proprieti. Obiectele dintr-o baz de date care aparin aceleiai clase alctuiesc o colecie. Baza de date este considerat ca fiind un recipient al coleciilor de obiecte care o compun. O aplicaie Access este alctuit dintr-una sau mai multe baze de date ale cror obiecte sunt conectate, corelate i coordonate pentru a alctui un ansamblu coerent de elemente i de activiti destinate rezolvrii unei probleme concrete. Utilizatorul vede i folosete n mod direct machete i rapoarte, n timp ce alte obiecte susin i controleaz felul n care acestea lucreaz (tabele, interogri, macro-comenzi i module), i sunt transparente pentru utilizator. Aplicaiile folosesc proprietile i metodele obiectelor pentru a le manipula, precum i evenimente care apar n anumite obiecte i dirijeaz evoluiile ulterioare.

Etapele de realizare a unei aplicaii Access 1. Analiza sistemului, sau identificarea problemei de rezolvat, care se concretizeaz n : stabilirea scopului i domeniului de interes; identificarea entitilor sistemului i precizarea legturilor dintre ele; precizarea datelor de intrare, prelucrrilor necesare i prezentrii rezultatelor. 2. Proiectarea aplicaiei. Aceast faz include: proiectarea obiectelor din baza de date; proiectarea interaciunilor dintre obiecte; proiectarea interfeei aplicaie-utilizator. 3. Realizarea aplicaiei , care cuprinde urmtoarele faze: crearea fiierului bazei de date, care va aciona ca un recipient uria pentru obiectele aplicaiei; crearea obiectelor i testarea lor; ncrcarea bazei de date i testarea aplicaiei. Crearea unei baze de date Access

Dup lansarea Access-ului din grupul Microsoft Office, se creeaz o nou baz de date selectnd de pe meniu File, New Database, i apoi directorul i numele bazei de date. Se poate porni de la o baza de date vida (Blank Database), sau de la unul din modelele oferite de Access (Ledger, Expenses, Asset Tracks, Membership, Donations etc.) Dac baza de date exist, pentru a o putea utiliza , este neaprat necesar s o deschidem , i acest lucru se face cu m File, Open Database. Elementele ferestrei Database Aceast fereastr permite vizualizarea rapid a obiectelor ce alctuiesc baza de date. Elementele componente ale ferestrei sunt: Butoanele pentru obiecte, aflate pe orizontal, n partea de sus ferestrei, permit selectarea unei anumite clase de obiecte. Butoanele de comand, n numr de trei, aflate pe vertical, n partea dreapt a ferestrei. Lista cu obiecte, situat n mijlocul ferestrei Database, afieaz obiectele clasei selectate. Fiecare clas de obiecte are anumite proprieti (caracteristici, atribute), care determin modul de lucru al obiectelor i aspectul acestora. Pentru modificarea proprietilor obiectelor, Access-ul pune la dispoziie o serie de instrumente, cum ar fi: WIZARDS - asisteni TOOLS - utilitare. n afar de proprieti, obiectele Access se caracterizeaz prin aciunile pe care le pot executa sau care pot fi efectuate asupra lor. Acestea pot fi folosite pentru manevrarea obiectelor.

Tiprirea obiectelor unei baze de date cuprinde trei etape: previzualizarea stabilirea parametrilor de punere n pagin tiprirea.

Pot fi tiprite :coninutul unei tabele de date, definiia unui obiect, machete, rapoarte, parametri de protecie, module Access Basic. Copierea, redenumirea sau tergerea fiierului bazei de date se poate face cu ajutorul lui File Manager, dup ce, n prealabil, baza de date a fost nchis. nchiderea bazei de date se face din meniu, cu opiunile File, Close Database. La rndul lor, obiectele bazei de date pot fi copiate sau terse din baza de date folosind m Edit, Copy (Cut) i respectiv Paste. TABELE Tabelul este un obiect Access destinat pstrrii datelor despre un anumit subiect. Subiectul la care se refer datele se numete entitate. Pentru fiecare entitate identificat la analiza sistemului, se creeaz cte un tabel. Tabelele se identific prin nume, i apar listate n fereastra Database, cnd este acionat butonul Table. n tabel, datele sunt organizate n rnduri i coloane ; fiecare rnd conine informaii despre un exemplar al entitii i se numete nregistrare, iar fiecare coloan conine informaii despre un atribut al entitii i se numete cmp. Un tabel conine dou tipuri de informaii: informaii despre structura tabelului (modul de alctuire i organizare a tabelului) i datele propriu-zise. Crearea unui tabel (b Table, b New) se poate face n mai multe moduri: a) cu ajutorul Table Wizard; acest mod de lucru este destinat, n general , nceptorilor. Access-ul, prin intermediul Table Wizard, pune la dispoziia utilizatorilor dou categorii de modele : Business, i Personal. Pentru fiecare categorie, exist o serie de tabele ce pot servi drept model (Sample Tables) , fiecare dispunnd de cmpuri-model (Sample Fields). Utilizatorul trebuie s se decid pentru o anumit categorie i un anumit model de la care pornete, n care poate include sau nu cmpurile oferite de Wizard. Crearea tabelului se face pas cu pas. I se d un nume, i se stabilete cheia primar (Wizard poate face acest lucru n locul utilizatorului, eventual), se selecteaz i rearanjeaz cmpurile oferite, dup care se poate trece la introducerea de date n tabel, fie direct, fie prin intermediul unei machete de introducere a datelor, care se poate crea i ea automat, prin intermediul unui Wizard.

b) fr ajutor, n care caz este deschis o fereastr de proiectare (Design View) sau o foaie de date (Datasheet View). Utilizatorul va trebui s introduc, pentru fiecare cmp : - numele (max. 64 caractere, mari si/sau mici, eventual cu spatii intre cuvinte- nu puncte!)

- proprietile cmpului: tipuri de date: Numeric- se pot folosi ,ca opiuni de reprezentare, pentru numere ntregi: Byte , Integer, Long Integer, iar pentru numere reale Single i Double. Text - litere , cifre i semne speciale pe lungime de max. 256 caractere. Memo - pentru introducerea de note, observaii , n lungime maxim de 64 Kocteti. Date/Time - date calendaristice i momente de timp Autonumber - contoare-secvene de numere ntregi create i actualizate automat de Access. Currency - valori numerice cu semnificaie de sume de bani. Yes/No - valori logice sau boolene ("adevrat" sau "fals") OLE object - obiecte provenite din aplicaii ca Excel, Draw sau Word, avnd dimensiunea maxim de 1 Goctet. Proprietile cmpului se refer la: lungime (Field Size), indexare (Indexed) valoarea implicit (Default) indicatorul de valoare necesar (Required) formatul (Format) regula de validare i mesajul de eroare . Stabilirea cheii primare La crearea tabelului, trebuie stabilit cheia primar, care identific n mod unic nregistrrile din tabel. Acest lucru se poate face cu ajutorul Table Wizard, sau direct de ctre utilizator. Iat cteva reguli pentru alegerea cheii primare: nu se accept valori duplicate sau nule n cmpul cheie (prin valoarea nul nelegndu-se aici "fr valoare atribuit"; avnd n vedere c dimensiunea ei afecteaz viteza de operare, trebuie aleas o cheie de dimensiuni ct mai reduse; este de preferat s aib un nume uor de reamintit.

Indexul este un obiect creat pentru un tabel, care nlesnete gsirea de ctre Access a unor articole i grbete ordonarea acestora. Se practic indexarea cmpurilor n care se caut frecvent date. Se pot construi orici indeci, dar acetia ncetinesc actualizrile n tabel, deci trebuie pstrat o msur. Cheia de indexare poate fi simpl - cnd este format dintr-un singur cmp, sau compus- cnd este format din mai multe cmpuri, situaie care apare atunci cnd se permit valori duplicate pe primul cmp. Vizualizarea unui tabel Se poate face n dou moduri: A) n modul Design View - modul de vizualizare folosit implicit la crearea tabelului fr ajutorul Table Wizard , i folosit pentru a putea ulterior s facem modificri n structura tabelului . Pentru accesarea lui, se apas butonul Design. (Este corespondentul ferestrei Setup din FoxPro). B) modul Datasheet View - este utilizat pentru ncrcarea iniial a tabelului, i ulterior pentru efectuarea de actualizri. Permite vizualizarea i modificarea coninutului bazei de date. Corespunde ferestrei Browse din FoxPro. Pentru accesarea lui, se acioneaz butonul Open. n acest mod, fiecare rnd reprezint o nregistrare, i fiecare coloan, un cmp. O sgeat n dreptul nregistrrii este simbolul indicatorului de nregistrare, care indic nregistrarea curent. La sfrsitul fiecrui tabel, se afl o nregistrare goal , marcat cu un '*' n fata nregistrrii. Aceast nregistrare poate fi completat de utilizator, realizndu-se astfel adugarea de articole n baza de date. Imediat, sistemul creeaz o nou nregistrare goal. Modificarea unei nregistrri se face poziionnd indicatorul de nregistrare pe ea, i efectund modificarea dorit. Salvarea nregistrrilor se face la trecerea pe nregistrarea urmtoare, sau la nchiderea tabelului. Pentru tergerea unei nregistrri, aceasta trebuie selectat, i apoi se acioneaz pur i simplu tasta "Delete". Sistemul cere o confirmare, i dac o primete, nregistrarea este tears efectiv. IMPORT - EXPORT N/DIN BAZE DE DATE ACCESS Access poate s foloseasc date care sunt nregistrate n afara bazei de date Access prin trei metode : copierea unui tabel din alt baz de date Access; ataarea unor tabele externe; importarea datelor din surse externe / exportarea datelor ctre destinaii externe. Copierea unui tabel din alt baz de date Access se face folosind mecanismul Copy, Paste: se selecteaz tabelul respectiv i se copiaz n Clipboard cu m Edit, Copy, iar apoi, din baza de date destinaie, se folosete m Edit, Paste, pentru a obine o copie a sa. Se pot copia, dup caz, numai structura tabelului, sau numai datele din tabel, sau i structura i datele. Ataarea unui tabel extern(Link Table ) este operaia prin care se creeaz o legtur cu un alt tabel, dintr-o alt baz de date, oferindu-se astfel posibilitatea vizualizrii i

modificrii datelor din acel tabel. De notat c acele date se vor putea folosi n continuare i din aplicaia originar. Tabelele externe ataate pot aparine: altei baze de date Access, unei baze de date Paradox, Dbase III , IV, FoxPro sau SQL. Numele tabelului din baza de date va fi precedat de o sgeat, simboliznd ataarea. Importul datelor din surse externe.(Import Table) Aceste surse pot fi : -tabele dintr-o baz de date Access, Paradox, FoxPro sau dBase, -foi de calcul tabelar create n Excel sau Lotus1-2-3, sau -fiiere text (cu format fix sau cu delimitatori). Prin aceast operaie se realizeaz o copie a datelor importate n formatul tipic al tabelelor Access. In cazul n care importul datelor nu se face din tabele ale unor baze de date, este neaprat necesar ca acesta s aib loc ntr-un tabel existent, n aa fel nct structura n care se import datele s preexiste. n mod analog, se poate realiza exportul datelor ctre destinaii externe. Destinaiile pot fi baze de date Access, Paradox, FoxPro, dBase, foi de calcul tabelar Lotus, Excel, ca i fiiere text (cu format fix sau cu delimitatori). UTILIZAREA TABELELOR Editarea nregistrrilor unui tabel , ca i adugarea i tergerea unor nregistrri , se efectueaz n modul Datasheet View. Pentru a ajunge n acest mod de lucru, se acioneaz butonul Open. Actualizarea nregistrrilor unui tabel: Adugarea este posibil ntotdeauna n nregistrarea vid marcat cu un '*', oferit de Access la sfritul fiecrui tabel. De ndat ce o nregistrare este completat, o alta vid apare dup ea. Pentru a modifica o nregistrare, este necesar poziionarea pe acea nregistrare i apoi pe cmpul de modificat. Se poate atunci realiza modificarea dorit. Pentru a terge o nregistrare, se localizeaz nregistrarea i se acioneaz tasta Delete. Dup o confirmare cerut de SGBD, nregistrarea este eliminat din tabel. FORMATAREA N FOAIA DE DATE Operaiunea de schimbare a modului de prezentare a datelor se numete formatare. Aceast operaiune se realizeaz , de asemenea, din modul Datasheet View. Se pot formata datelor prin: redimensionarea i mutarea rndurilor i coloanelor; modificarea formatului de reprezentare a valorilor; stabilirea atributelor de format: font, dimensiune, stil. Salvarea configuraiei curente a unui tabel se face din m File, Save Table, iar pentru nchiderea tabelului executm comanda Close din meniul File. Redenumirea unui tabel se face cu Rename , din meniul File. Eliminarea unui tabel se face poziionnd cursorul pe tabelul respectiv i acionnd tasta Delete. Atenie ns: sunt terse att datele, ct i structura tabelului. STABILIREA CORELATIILOR NTRE TABELE Access fiind un SGBD relaional, permite asocierea rapid i extragerea de informaii nrudite memorate n tabele separate. ntr-o baz de date relaional, tabelele sunt

corelate. n faza de definire a tabelelor, trebuie precizate asocierile posibile, pe baza unor criterii logice i de nrudire a datelor. Pentru ca asocierea s fie posibil, tabelele trebuia s aib cmpuri comune, care s se manifeste drept cheie primar n unul din tabele i drept cheie extern n cellalt. Este recomandat ca numele acestor cmpuri s fie identic n toate tabelele corelate, iar tipurile lor s fie compatibile. n acest fel, Access poate crea automat corelaiile atunci cnd tabelele sunt folosite ntr-o interogare. Tipuri de corelaii ntre tabele Se pot stabili trei tipuri de corelaii: Corelaia de tip "1-la-n" este cea mai des ntlnit: o nregistrare din tabelul A poate avea mai multe nregistrri corespondente n tabelul B, ns o nregistrare din tabelul B are cel mult o nregistrare corespondent n tabelul A. Pentru aceasta , cheia primar a tabelei A trebuie s fie cheie extern n B. Exemple: Secii - Angajai Furnizori - Facturi. Corelaia de tip "m-la-n" : o nregistrare din tabelul A poate avea mai multe nregistrri corespunztoare n tabelul B i invers , o nregistrare din tabelul B poate avea mai multe nregistrri corespunztoare n tabelul A. n Access, pentru crearea acestei corelaii , se adaug un tabel suplimentar care "sparge" corelaia n dou corelaii "1-la-n". n acest tabel suplimentar se plaseaz cheile primare din ambele tabele. Exemplu: Profesori- Materii predate. Corelaia de tip "1-la-1" : o nregistrare din tabelul A poate avea cel mult o nregistrare corespunztoare n tabelul B, i invers, o nregistrare din tabelul B poate avea cel mult o nregistrare corespunztoare n tabelul A. n multe cazuri, informaiile din cele dou tabele pot fi restrnse ntr-un singur tabel, prin adugarea unui cmp nou. Pentru crearea acestui tip de corelaie, exist urmtoarele posibiliti: dac tabelele au acelai subiect, se stabilete corelaia punnd acelai cmp n ambele tabele; dac tabelele au subiecte diferite cu chei primare diferite, se alege unul dintre tabele i cheia sa primar va fi adugat pe post de cheie extern n cellalt tabel. Exemple: Angajai - Angajai; Angajai - Premii. Pentru crearea corelaiilor, se folosete comanda Relationships, din meniul Edit, ce provoac deschiderea ferestrei Relationships. Aici se adaug tabelele ntre care se dorete crearea corelaiei, i apoi se indic numele cmpurilor de legtur , precum i tipul corelaiei. Legtura stabilit ntre tabele se numete linie de corelare, iar coninutul ferestrei Relationships formeaz o diagram de corelare. MACHETE Macheta este un obiect Access destinat introducerii datelor ntr-o aplicaie de baze de date. Ea poate fi folosit, secundar , i pentru vizualizarea datelor dintr-o nregistrare a unui tabel sau din mulimea nregistrrilor rezultate n urma unei interogri. Aspectul unei machete poate reproduce ndeaproape formularele tipizate de pe care se culeg datele, sprijinind astfel munca utilizatorilor i diminund riscul introducerii de date eronate. Macheta constituie principalul mijloc de interfa aplicaie-utilizator.

O macheta poate fi afiat n trei moduri diferite: Modul Design (Proiectare) este utilizat pentru a schimba prezentarea i proprietile unei machete, sau pentru a modifica controalele dintr-o machet. Modul Datasheet (Foaie de date) este similar cu afiarea direct a tabelului sau a interogrii. Modul Form (Formular) reprezint modul de afiare normal al unei machete n curs de utilizare. n acest mod, n funcie de opiunea aleas la construire, este afiat o singur nregistrare, sau mai multe nregistrri. Pentru proiectarea unei machete, trebuie definite urmtoarele aspecte: ce date intr n aplicaie; ce elemente (obiecte de control) se folosesc; cum sunt amplasate aceste elemente; aspectul lor; modul de funcionare al machetei.

Macheta conine, pe lng datele propriu-zise, aa-numitele informaii de structur, ce descriu nfiarea i alctuirea machetei. Crearea unei machete se face din fereastra bazei de date, acionnd mai nti butonul Forms (Machete), i apoi butonul New. n continuare, se selecteaz tabelul sau rezultatul interogrii pentru care se dorete construirea machetei. Exist mai multe moduri distincte de a crea o machet: Design view- (modul proiectare) permite crearea machetei manual. Form Wizard- ofer posibilitatea de a controla fiecare etap a procesului; crearea machetei se face pe baza opiunilor utilizatorului AutoForm: Columnar- configurare automat a formularului: aezarea cmpurilor unul sub altul (configuraie potrivit pentru un formular principal) AutoForm: Tabular- configurare automat a formularului: aezarea cmpurilor pe linie, unul lng altul format tabelar(configuraie potrivit pentru un subformular )

AutoForm: Datasheet- configurare automat a formularului: modul Datasheet (configuraie corespunztoare pentru afiarea numrului maxim posibil de nregistrri deodat) Chart Wizard- (program pentru reprezentri grafice) creeaz un grafic afiat pe ecran. PivotTable Wizard- (program pentru tabele pivot) creeaz un formular pentru afiarea datelor din Excel 7.0. Dedesubtul listei programelor Wizard se afl o list derulant n care trebuie s selectai tabelul sau interogarea care va servi ca surs de date pentru formular. Modificarea unei machete se poate face acionnd butonul Design. Este posibil schimbarea poziiei elementelor, a dimensiunii i culorii acestora, adugarea de chenare, sublinieri, etc. Utilizarea machetei se face folosind butonul Open, care permite vizualizarea datelor din tabelul de baz prin prisma respectivei machete. Salvarea unei machete se face cu Save, din meniul File. nchiderea machetei se face cu File, Close. RAPOARTE Un raport este un obiect al unei baze de date Access folosit pentru prezentarea datelor din unul sau mai multe tabele i a rezultatelor prelucrrilor efectuate asupra lor. Rapoartele permit reprezentarea informaiilor de sintez , fcnd posibil ordonarea, gruparea i totalizarea datelor. Rapoartele se pot obine: pe hrtie, la imprimant; pe ecran; ntr-un fiier, pe disc. Pentru mbuntirea aspectului rapoartelor, se folosesc diverse obiecte de control i obiecte grafice. Rapoartele se pot obine i n format grafic, sub form de diagrame. Un raport este alctuit din dou tipuri de informaii: de structur, i datele propriu-zise. Informaiile de structur definesc elementele ce compun raportul : seciunile i obiectele de control, si - caracteristicile acestora, - aranjarea lor n pagin , precum si - legtura cu cmpurile i expresiile ce produc datele prezentate , si - atributele generale ale raportului. Seciunile sunt diviziunile raportului, iar obiectele de control sunt obiecte grafice care fac legtura cu i afieaz datele din cmpuri sau expresii. Exist i obiecte cu caracter pur decorativ. n cazul folosirii repetate a unui aceluiai raport, cu mici modificri, acesta poate fi salvat ca un ablon, din care se creeaz mai multe copii particularizate. ntre machete i rapoarte exist multe asemnri, att din punct de vedere structural, ct i al tehnicilor folosite pentru creare, utilizare i funcionare. Dar exist i o serie de deosebiri:

rapoartele sunt unidirecionale (permit doar extragerea datelor, nu i introducerea)

rapoartele permit gruparea i totalizarea datelor (cu total pe subgrup/grup i total general); rapoartele dau o imagine de ansamblu asupra datelor. Crearea unui raport se face folosind butonul Report, i butonul New. Exist mai multe posibiliti de creare a unui raport: Majoritatea programelor wizard pentru rapoarte sunt similare cu programele corespunztoare pentru formulare. Crearea unui grafic cu Chart Wizard este o metod care, prin rspunsuri la o serie de ntrebri despre cmpuri i modul lor de grupare, duce la construirea unui grafic, care poate fi listat la imprimant. Label Wizard asist crearea de etichete potale . Programul dispune de o serie de formate de etichet standard, predefinite, la care se pot aduga i altele, definite de utilizator. Trebuie adugat fiecare cmp n parte la o etichet prototip. Modificarea unui raport se poate face acionnd butonul Design. Utilizarea raportului se face folosind butonul Preview, care permite previzualizarea paginii ce va fi listat la imprimant . Salvarea unui raport se face cu Save, din meniul File. nchiderea raportului se face cu File, Close.

INTEROGRI N ACCESS O interogare este un obiect ACCESS ce reprezint o ntrebare formulat n legtur cu informaiile din baza de date. Rezultatul unei interogri este o mulime de nregistrri aparinnd unuia sau mai multor tabele. Acestea formeaz setul dinamic al interogrii. Aceast denumire i-a fost atribuit pentru c, dac se lanseaz din nou interogarea, n condiiile n care au avut loc actualizri n tabelele-surs, rezultatul este, de asemenea, modificat. Rolul interogrilor este acela de a extrage din tabelele bazei de date numai acele informaii care sunt necesare la un moment dat.

Modul de funcionare al interogrilor depinde de condiiile de selecie. Specificarea acestor condiii se face printr-o expresie, alctuit din operanzi i operatori. Aceasta se evalueaz pentru fiecare articol, i dac rezultatul este "adevrat", articolul este inclus n setul dinamic, iar n caz contrar, nu. Interogrile Access pot fi folosite n urmtoarele scopuri: ca baz a machetelor, rapoartelor i noilor interogri; sortarea datelor dup valoarea unuia sau mai multor cmpuri; interogarea de tabele externe (FoxPro, Paradox); efectuarea unor calcule pe datele extrase; gruparea datelor dup anumite criterii; actualizarea datelor din tabelele ce stau la baza interogrii; n Access sunt realizabile urmtoarele tipuri de interogri: Interogare pentru selecie : selecteaza din tabele datele care satisfac anumite condiii. Interogare de aciune: efectueaz modificri n mai multe nregistrri printr-o singur operaie. Exist mai multe subtipuri de interogri de aciune: interogri pentru adugarea datelor ntr-un tabel- preiau date dintrun tabel A i le adaug la sfritul altui tabel existent, n aceeai baz de date sau n alta. Adugarea poate fi condiionat de anumite criterii. Cmpurile din cele 2 tabele pot s nu coincid n totalitate. Acestea se numesc Append Query; interogri pentru actualizarea datelor- modific valoarea unui cmp n toate nregistrrile tabelului sau numai n unele - se numesc Update Query; interogri pentru crearea unui tabel - Make Table Query; interogri pentru eliminarea nregistrrilor - Delete Query.

Interogare de sintez : prezint informaiile ntr-o form compact. Interogare de tip "uniune" : combin cmpurile nregistrrilor care satisfac anumite condiii din mai multe tabele.

Modul de creare a unei interogri: Se acioneaz butonul Query, i butonul New

Design View permite crearea unei interogri fr sprijinul programelor Wizard. Tabelele care vor intra n interogare trebuie adugate una cte una; apoi se stabilesc cmpurile de legtur (dac cmpurile au acelai nume i tip, Access va ncerca s o fac automat), i tipul de interogare. Se mai precizeaz eventuale criterii de grupare, totaluri, i condiiile de selecie. Trecnd n modul Datasheet view, se poate vedea rezultatul interogrii. Dac se dorete modificarea condiiilor, se trece din nou n Design View, pentru a realiza acest lucru. Simple Query Wizard creeaz o interogare permind utilizatorului s selecteze cmpurile care vor rezulta din interogare. Crosstab Query Wizard serveste pentru crearea unui tabel ncruciat , ce conine valorile corespunztoare anumitor variabile. Find Duplicates Query Wizard- permite gsirea valorilor care se repet dintr-o tabel (de exemplu, doi angajai cu aceeai marc, doi elevi cu acelai nume, etc. Find Unmatched Query Wizards- permite crearea unei interogri care s gseasc acele nregistrri dintr-o tabel, care nu au corespondent n tabela corelat (ex.: coduri de client n Facturi fr corespondent n Catalogul de Clieni). Intre datele din tabele exist legturi, care se specific prin corelaii, pentru ca aplicaiile de baze de date create s fie capabile s combine corect datele nrudite i s extrag exact informaiile solicitate. Cele trei tipuri de corelaii care se pot stabili ntre tabele sunt: "1 la 1", ""1 la n" i "n la n" i au fost discutate ntr-un curs anterior. n afar de stabilirea corelaiilor, este necesar definirea modului n care vor fi combinate datele din nregistrrile tabelelor corelate, adic tipul de asociere. Exist trei tipuri de asocieri ntre dou tabele: inner join outer join self join. Precizarea tipului de asociere se face fie la definirea corelaiilor dintre tabele, fie la crearea unei interogri. Asocierea de tip "inner join" este o asociere n care nregistrrile din dou tabele sunt combinate i adugate la setul dinamic rezultat, atunci cnd n cmpurile asociate exist valori egale . Asocierea de tip "outer join" este o asociere n care n setul dinamic rezultat sunt adugate toate nregistrrile dintr-unul dintre tabele, chiar dac nu exist valori corespunztoare n cmpul asociat din al doilea tabel . nregistrrile din al doilea tabel sunt combinate cu cele din primul numai atunci cnd exist valori corespunztoare n ambele cmpuri asociate. Asocierea de tip "self-join" este o asociere n care nregistrrile dintr-un tabel sunt combinate cu alte nregistrri din acelai tabel atunci cnd exist valori corespunztoare n cmpurile asociate. Vizualizarea setului rezultat se poate face: -la terminarea proiectrii , cu opiunea din meniu View, Datasheet, sau Query, Run -ulterior, prin acionarea butonului Open dup selectarea interogrii;

Tiprirea setului rezultat: se face din Datasheet View, cu opiunea din meniu File, subopiunea Print. Salvarea interogrii: din meniu, cu File, Save. Crearea i folosirea unu filtru Un filtru este o condiie sau mai multe condiii pentru selectarea anumitor nregistrri dintr-o tabel sau dintr-un set dinamic rezultat. Filtrul este asemntor cu o interogare, deosebirea constnd n aceea c: nu poate fi aplicat dect unui tabel deschis sau unei machete; are o aciune temporar, fiind utilizabil pentru modificarea setului de nregistrri vizualizate. Pentru crearea unui filtru: - din meniul Records, Edit filter/Sort, definete nregistrrile vizibile, introducnd condiiile de filtrare; Pentru aplicarea unui filtru la setul de nregistrri curent : - din meniul Records , Apply Filter/Sort Pentru nlturarea unui filtru se nchide tabelul sau macheta. Eventual, filtrul poate fi salvat ca interogare, folosind opiunea Save Filter As, din meniul File. Ulterior , el se va comporta ca o interogare. MACROCOMENZI O macro-comand este un obiect al unei baze de date Access , care conine o secven de activiti pe care Access le execut automat pentru utilizator. Macro-comenzile pot fi ataate unei machete, unui raport, control, element de meniu sau combinaii de taste. Crearea i utilizarea macro-comenzilor reprezint un mecanism Access destinat automatizrii prelucrrilor de rutin dintr-o aplicaie fr a apela la tehnicile de programare. O macro-comand este compus din aciuni. O aciune ndeplinete o anumit sarcin bine definit: deschide/nchide o machet, tiprete un raport, aplic un filtru. Pentru efectuarea activitii solicitate, unele aciuni au nevoie de anumite informaii suplimentare, numite argumente. Access pune la dispoziia utilizatorilor o gam larg de aciuni ce pot fi executate. MODULE Pentru controlul amnunit i la nivelul detaliilor celor mai intime al operaiilor asupra bazei de date, Access pune la dispoziie limbajul de programare Access Basic. Procedurile scrise n acest limbaj pot rezolva probleme de prelucrare complexe, crora macro-comenzile nu le pot face fat. Comenzile sunt date cu autorul unor enunuri, numite instruciuni. Instruciunile sunt grupate n uniti numite proceduri, care sunt destinate realizrii unei anumite activiti sau operaii. Modulul este un obiect Access care conine o colecie de declaraii, instruciuni i proceduri Access Basic. De obicei, se memoreaz n acelai modul proceduri nrudite, destinate s rezolve o anumit problem (sarcin).

ADMINISTRAREA BAZELOR DE DATE ACCESS Administrarea bazei de date este un ansamblu de activiti necesare pentru ntreinerea unui SGBD i pentru proiectarea, construirea, exploatarea i ntreinerea aplicaiilor de baze de date realizate sub controlul acestuia. Persoana desemnat s execute aceste activiti n cadrul unei organizaii care utilizeaz SGBD i exploateaz aplicaii de baze de date, se numete administratorul bazei de date. n cazul n care este vorba de organizaii mari i aplicaii complexe, acest termen poate desemna un ntreg colectiv de tehnicieni. Activitile administratorului bazei de date cuprind: aplicarea criteriilor i metodelor de protecie a bazei de date; repararea bazei de date - se refer la refacerea unei baze de date care a fost nchis anormal; se face cu ajutorul unei opiuni din meniul File- Repair Database; compactarea bazei de date- o operaie de reamplasare a bazei de date pe disc, pentru o mai bun folosire a spaiului, eliminnd pe ct posibil fragmentarea ; optimizarea performantelor aplicaiilor Access- folosirea configuraiei de calcul i a mediului de lucru n mod optim, corespunztor necesitilor aplicaiei. si eventual proiectarea unei baze de date. Protecia datelor i aplicaiilor Access dispune de o serie de mecanisme de protecie incorporate. Sistemul de protecie Access se bazeaz pe trei elemente: grup de lucru, cont i drept. Implementarea acestora, pentru fiecare aplicaie, permite asigurarea proteciei dorite. Un grup de lucru este o mulime de utilizatori ai aplicaiei care, ntr-un mediu de lucru ce permite accesul multiplu, partajeaz informaiile memorate n baza de date. n cadrul unui grup, se definesc conturi pentru grup i conturi pentru utilizatorii individuali care fac parte, ca membri, dintr-un grup. n fiierele aplicaiei sunt memorate informaiile referitoare la drepturi, care sunt de dou feluri :drepturi de proprietate (asupra obiectelor) i drepturi de acces la obiecte. Prin intermediul conturilor de grup i individuale create anterior, se face atribuirea diverselor tipuri de drepturi. Cel care are drept de proprietate asupra unui obiect l poate i accesa, i i poate modifica structura, iar cel care se bucur doar de drept de acces, poate doar consulta obiectul respectiv. La instalarea Access, exist deja urmtoarele conturi de grup:Admins, Users i Guests, i conturile utilizator: Admin i Guest. Contul de grup Admins este contul grupului administratorului de sistem. Access adaug automat contul Admin n contul de grup Admins. Contul Admin are drepturi depline de acces la obiectele bazei de date. Contul de grup Guests conine toate conturile Guest. Conturile Guest nu au implicit drepturi de acces la obiecte, acestea trebuind s le fie acordate ulterior . Contul de grup Users conine toate conturile utilizator. Access adaug automat conturile utilizator la grupul Users n momentul crerii acestora. Acestea au drepturi depline asupra tuturor obiectelor nou create, cu alte cuvinte, fiecare utilizator este proprietarul obiectelor pe care el le-a creat.

Organizarea conturilor de utilizator n grupuri uureaz gestionarea problemelor de protecie. n locul atribuirii de drepturi de acces pentru fiecare obiect, fiecrui utilizator, se atribuie aceste drepturi unui numr restrns de grupuri. Cnd se adaug n diversele grupuri noi conturi utilizator, acestea motenesc drepturile de acces ale grupului din care fac parte. Pentru crearea i gestionarea grupurilor de lucru, exist programul MS Access Workgroup Administrator, care este furnizat, mpreun cu Access-ul, n pachetul Microsoft Office Professional.

DEPOZITE DE DATE Ideea "depozitelor de date" nu este nou. Cu toate acestea, termenul Data Warehouse a devenit un termen la mod abia n ultimii trei ani, mai ales n cercurile manageriale. Depozitele de informaii reprezint o cerin acut a organizaiilor moderne (fie ele ntreprinderi, bnci, administraie, etc.) si, totodat, o realitate tehnologic pus n practic din ce n ce mai frecvent. Depozitele de date, sub un nume sau altul, au aprut n gndirea comunitii informatice la sfritul deceniului trecut. La nceputul anilor '90, ideea capt contur. William Inmon, vicepreedintele firmei Prism Solutions, este printele necontestat al noiunii n nelesul ei curent. Contextul n care interesul pentru depozitele de date a crescut n ultimii 2-3 ani enorm este intersectarea tendinelor economice i progreselor tehnologice n acest punct. Depozitul de date este ntr-un fel complementul sistemului informatic operaional. Sistemul informatic operaional cuprinde aplicaiile de contabilitate, gestiune a stocurilor, urmrirea comenzilor, facturare, etc. Definiia lui William Inmon este extrem de concis: un depozit de date este o colecie de date tematic, integrat, plasat ntr-un context temporal, i permanent destinate fundamentrii deciziei manageriale Datele din depozitul de date provin din : datele preluate din sistemul informatic operaional, datele de arhiv (n perioada de constituire a depozitului) din surse externe, cum ar fi baze de date publice, de exemplu: - date demografice obinute n urma unui recensmnt, - date statistice furnizate de institute specializate, - date de prognoz economic (furnizate de instituii orientate pe studiul pieei), - date obinute n urma unor sondaje de opinie, etc. Aceste din urm date pot fi cumprate, pot fi preluate pe baz de abonament sau pot fi date publice gratuite. Datele din depozitul de date sunt destinate fundamentrii deciziei manageriale. Spre deosebire de coleciile de date utilizate de sistemul operaional - orientate spre optimizarea i sigurana procesrii datelor - datele dintr-un depozit de date sunt

organizate ntr-o manier care s permit analizarea lor, deci extragerea semnificaiei economice pe care o poart. Rolul unui depozit de date este de a oferi o imagine coerent asupra datelor relative la activitatea unei organizaii i a contextului n care acesta acioneaz. Utilizarea acestei colecii poate consta din : extragerea unor rapoarte (la cerere sau pe baza unui "abonament" cu o anumit periodicitate), extragerea unor date pentru a fi utilizate de aplicaiile de birotic (programe de calcul tabelar, procesoare de text, programe de prezentare, etc.), extragerea unor date pentru a fi utilizate de ctre aplicaii specializate de analiz Acestea ar putea fi mprite n dou categorii: - instrumente de analiz on-line (OLAP - On Line Analytical Processing aplicatii axate pe analiz multidimensional) i - instrumente pentru "minerit" n date (data mining - aplicaii axate pe descoperirea unor abloane semnificative n colecii de date). Caracteristicile depozitelor de date Orientare tematic Datele operaionale sunt orientate pe aplicaii, n sensul c organizarea lor este optimizat pentru a servi procesului tranzacional, dinamicii sistemului. n contrast, depozitul de date este orientat pe subiectele importante ale procesului economic, cum ar fi: clieni, furnizori, produse, activiti. Un exemplu simplu poate fi edificator: o comand lansat de un client va fi consemnat de sistemul operaional printr-un set de nregistrri care vor conine informaii despre client, informaii despre produsele sau serviciile comandate, informaii despre modul de transport i modul de plat, etc. Multe dintre datele eseniale din perspectiv operaional (numrul comenzii, poziiile liniilor n cadrul comenzii, etc.) sunt complet lipsite de relevant din perspectiv informaional. O consecin important a acestei orientri este redundanta datelor. Dac n sistemul operaional redundanta este eliminat (prin procesul de normalizare) pentru a evita anomaliile de actualizare, n depozitul de date redundanta este creat n mod intenionat (prin denormalizare i rezumare) pentru a permite un acces tematic mai facil. Integrarea Este cel mai important aspect al depozitului de date si, n cele din urm, raiunea pentru care acesta este creat. Datele snt adunate aici pentru a rspunde nevoilor informaionale ale ntregii organizaii, asigurnd faptul c rapoartele generate pentru diverse compartimente vor conine aceleai rezultate. Sistemul operaional este de cele mai multe
ori format din subsisteme semi-independente, create la momente diferite, de echipe diferite, n maniere diferite, rezultnd o babilonie care, dei funcional, este imposibil de folosit pentru analiz.

Integrarea datelor provenind din sistemul operaional i din alte surse se refer la numeroase aspecte: Convenii unice privind denumirile datelor - n sistemul operaional acestea difer de la aplicaie la aplicaie;

Modaliti unice de codificare - e suficient s ne gndim la nenumratele variante de a codifica sexul: ('m', 'f'), (0, 1), (True, False), etc. Este evident c o aplicaie pentru analiz va trebui s se bazeze pe o codificare consecvent; Sistem de uniti de msur consecvent - lungimi, suprafee, volume, greuti, temperaturi, etc., toate trebuie exprimate ntr-un set unic de uniti de msur; Sistem stabil de reprezentare fizic a datelor - n aplicaiile tranzacionale este posibil ca aceleai date s fie memorate n moduri diverse; Convenii clare privind modul de reprezentare a datelor calendaristice, a timpului, etc.;

Contextul temporal

Sistemul operaional al unei organizaii tinde mereu s reflecte realitatea curent. Astfel, el se afl ntr-o continu evoluie iar datele pe care le conine snt relevante doar pentru momentul n care sunt accesate. Orizontul de timp pe care l acoper este de regul de 60 pn la 90 de zile, deoarece dup acest interval tranzaciile efectuate snt arhivate, fiind considerate deja de domeniul istoriei, deci neinteresante din perspectiv operativ. Pentru nevoile analizei economice, dimpotriv, informaiile cu caracter istoric snt eseniale, deoarece ele pun n evident tendine care reprezint fundamentul unei prognoze corecte. Depozitul de date se constituie ntr-un istoric al sistemului operaional, constituit dintr-o serie de "instantanee", imagini la diverse momente n timp. Orizontul de timp pe care l acoper depozitul de date este de cel puin cinci ani, ajungnd uneori la zece ani, n funcie de dinamica evoluiei pieei si, deci, de relevanta datelor cu caracter istoric pentru nevoile analizei. Din punct de vedere tehnic, acesta implic faptul c orice nregistrare din depozitul de date poate fi plasat n timp. Orice cheie de acces trebuie s cuprind i o variabil temporal.
Permanena

Esena aplicaiilor operaionale este actualizarea continu a coleciilor de date, actualizare realizat n general pe baz tranzacional. Orice tranzacie procesat implic inserarea unor noi nregistrri, modificarea sau eventual tergerea altora, etc. Cu totul altfel stau lucrurile n cazul depozitului de informaii, unde o astfel de dinamic lipsete. Practic singura actualizare care se realizeaz aici este adugarea periodic a unor date extrase din sistemele operative. Din punctul de vedere al aplicaiilor care folosesc depozitul de date, accesul la date este doar pentru citire. Din punctul de vedere al proiectrii, aceast diferen este extrem de important. n sistemul operaional, o tranzacie trebuie s duc colecia de date dintr-o stare coerent ntr-o alt stare coerent, iar aceast implic mecanisme extrem de complexe de meninere a integritii datelor. n cazul depozitelor de date, aceste mecanisme snt inutile, astfel c gradul de libertate ctigat poate fi utilizat pentru optimizarea accesului la date prin denormalizare, rezumare, statistici ale accesrii datelor i reorganizare dinamic a indexrii, etc.
Structura

Structura tipic a unui astfel de depozit are patru nivele, n funcie de nivelul de agregare i de vechimea acestora. Dac vom face o analogie cu un depozit adevrat, atunci este normal ca datele cele mai utilizate s se gseasc la parter. Aici se vor gsi datele relativ recente, en detail. Acestea

snt n principiu livrate utilizatorilor finali, de regul funcionari de execuie. La primul etaj se vor afla date "semipreparate" printr-o rezumare uoar, destinate n principal managementului mediu. La al doilea etaj se vor afla date preparate pentru nevoile managementului superior. Prepararea implic consolidare, rezumare i mpachetare n formate accesibile instrumentelor de analiz utilizate. n fine, la "subsol" se vor afla date accesate cel mai rar. Este vorba de date avnd o oarecare vechime (de regul peste doi-trei ani), n form detaliat. Datele istorice folosite de obicei de managementul superior snt disponibile ntr-o form rezumat la "etajul al doilea" (eventual i la primul). Aceast structur este dinamic, datele intr n depozitul de date, circul pe diverse nivele, i schimb forma i poziia, etc. Dar aceste aspecte dinamice vor fi analizate mai trziu. Poate cea mai important component a depozitului de date o reprezint nivelul metadatelor. Pentru a putea utiliza depozitul de date, utilizatorii trebuie s cunoasc ce date se gsesc aici, iar metadatele nu snt altceva dect date despre date, date care descriu coninutul depozitului i furnizeaz, asemenea fiselor dintr-o bibliotec, trimiteri directe la date. Tot la nivelul metadatelor se definesc i diverse subscheme asociate unor categorii specifice de utilizatori. Metadatele sunt intens folosite i pentru administrarea depozitului de date, coninnd informaii despre proveniena datelor, algoritmii de rezumare, statistici de utilizare, i multe altele.
Redundan

Deoarece sursa celor mai multe date stocate n depozitul de informaii o constituie mediul operaional, am putea crede c nivelul de redundant ntre cele dou sisteme (cel informatic operaional i cel destinat informrii) este foarte ridicat. De asemenea faptul c ambele sisteme se bazeaz pe operarea cu sisteme de gestiune a bazelor de date, c ambele sisteme implic volume mari de date, etc., pot accentua aceast impresie. Cteva consideraii pe aceast tem pot fi edificatoare n ceea ce privete chiar definiia depozitului de informaii. Din punct de vedere funcional cele dou sisteme snt disjuncte. Sistemul operaional proceseaz tranzacii n timp ce sistemul informaional este exploatat prin interogri. Cerinele snt diametral opuse. n ceea ce privete datele propriu-zise, cteva aspecte pot fi edificatoare: Filtrarea datelor la transferul din sistemul operaional n cel informaional face ca doar datele relevante pentru analiza economic s treac acest prag. Orizontul temporal al celor dou sisteme este diferit. Exist o suprapunere foarte mic ntre cele dou. Depozitul de date conine i date de sinteza, care nu exist niciodat n sistemele operaionale. La preluarea n depozitul de date, datele snt supuse unor transformri radicale att din punct de vedere fizic ct i logic. Conform aprecierii lui Inmon, redundanta datelor ntre cele dou sisteme are de regul o rat mai mic de 1%. Dar chiar dac aceast rat ar fi mult mai mare, valoarea depozitului de date este imens, deoarece ofer managementului organizaiei o imagine unic, coerent i semnificativ asupra datelor relevante din perspectiva analizei economice.

Mai mult, instrumente specializate OLAP permit utilizatorilor s exploreze efectiv aceast baz informaional, fr a avea nevoie de intermedierea unui serviciu specializat. Definiia depozitului de date, accentund contrastul ntre sistemul informatic operaional i cel destinat informrii, ne-ar putea sugera nite imagini de genul urmtor: Sistemul operaional seamn cu ringul unei burse, cu o mulime de brokeri agitndu-se n jurul calculatoarelor, a panourilor de afiare, fcndu-si semne neinteligibile ntre ei, rcnind la telefoane, smulgnd nerbdtori hrtiile din faxuri, etc. Dimpotriv, depozitul de date este un spaiu linitit, respirnd atmosfera seren a unei biblioteci. De fapt, lucrurile nu stau chiar aa. Depozitul de date are i el dinamica lui, chiar dac nu att de agitat ca cea a sistemului operaional. nelegerea modului n care aceste fluxuri acioneaz este cheia succesului construciei i utilizrii unui depozit de date.
DINAMICA DEPOZITULUI DE DATE In-flow (Fluxul de intrare)

Acesta este fluxul de intrare a datelor n depozit. Datele provin din sistemul informaional precum i din surse externe. Actualizarea depozitului de date nu trebuie s afecteze datele existente. Nimic nu se terge, nimic nu se suprascrie. Este vorba doar despre adugarea unui nou "strat" de date. Actualizarea se face de regul n loturi, la intervale regulate, dar anumite cerine pot impune o actualizare n flux continuu, reflectnd actualizri n sistemul informatic operaional. De exemplu, o banc ar putea s doreasc s pstreze un istoric al tuturor operaiunilor efectuate asupra unui cont sau ar putea s se mulumeasc cu balane periodice (de pild la sfritul fiecrei zile). Pentru datele provenind din aplicaiile tranzacionale se pune n primul rnd problema selectrii i extragerii. Datele trebuie s treac apoi printr-un proces complex de integrare. Acest proces implic: eliminarea datelor irelevante (a cror semnificaie se leag de procesul tranzacional, cum ar fi de pild numrul poziiei din factur); conversia la codificri i reprezentri unitare (conform unor convenii clar stabilite de administraia depozitului); curirea datelor (prin eliminarea inconsistenelor, i reconstituirea datelor parial distruse, completarea informaiilor lips cu valori implicite, etc.); reorganizarea datelor (adugarea informaiilor temporale unde este cazul, denormalizare i rearanjare dup subiecte, etc.); n afar de datele provenite din sistemul operaional, o cerin tot mai actual o reprezint integrarea n depozitul de date a datelor provenind din alte surse. Printre acestea se remarc datele non-relaionale cum ar fi texte, e-mail, foi de calcul, imagini, obiecte multimedia, baze de date geografice, chiar i reguli comerciale (business rules). De asemenea, alte surse de date externe pot fi sistemele operaionale ale partenerilor de afaceri, bazele de date publice sau informaiile furnizate pe baz de abonament (cotaii bursiere, buletine meteorologice, etc.).
Up-flow (Fluxul ascendent)

Prin procesul de intrare n depozitul informaional, datele capt un plus de claritate i de semnificaie. Dar odat ajunse n Data Warehouse ele nu rmn n acest stadiu, ci se mbogesc n continuare printr-o serie de alte transformri. Aceste procese snt numite n mod generic up-flow i au rolul de a aduga valoare informaional datelor colectate.

Principalele procedee utilizate n acest scop sunt:

Down-flow

In-flow Depozit de date Meta-flow

Out-flow

Up-flow Schema celor cinci fluxuri de date

Rezumare. Datele intr n depozit la nivel de detaliu. Cu toate c instrumentele de analiz pot aplica funcii de agregare, pentru optimizarea accesului la astfel de informaii de sintez anumite astfel de operaii snt realizate chiar de administraia depozitului de informaii. Rezumarea se realizeaz pe baza dimensiunilor cele mai utilizate i poate implica nu doar nsumarea unor valori, ci i medii, valori minime/maxime, sau valori obinute prin procedee statistice complexe. Un exemplu simplu este rezumarea pe axa timpului. mpachetare. Utilizarea informaiei din depozit nu se face doar on-line. Pentru cea mai mare parte dintre nevoile informaionale ale organizaiei se utilizeaz sistemul abonamentelor: un anumit beneficiar (un funcionar, un birou, un departament, etc.) are nevoie de anumite informaii, la un anume nivel de rezumare, la anumite intervale de timp. Aceste informaii pot fi livrate ca simple rapoarte, dar cel mai adesea ele trebuie livrate n formate care s permit beneficiarului s le utilizeze n continuare pentru analize, prezentri, raportri, etc. Cel mai adesea datele se furnizeaz ca foi de calcul, documente text, baze de date personale, eventual grafice, animaii, etc., toate ntr-un format propriu utilizatorului. De pild datele pot fi plasate n multiple file de calcul tabelar, n diverse nivele de detaliere, coninnd eventual i prezentri grafice. Distribuire - De cele mai multe ori, diverse grupuri de utilizatori sunt interesate doar de anumite categorii de date, astfel nct pentru a creste disponibilitatea informaiilor se realizeaz nite mici depozite departamentale, coninnd replici pariale (cuprinznd doar datele de interes specific) ale depozitului central. Alt situaie frecvent este cnd repartizarea teritorial a organizaiei impune multiplicarea depozitului de date n mai multe locuri (de pild replicarea integral sau parial la filialele din teritoriu).

Down-flow (Fluxul descendent)

Acest flux se refer la administrarea datelor i este destinat s menin "vitalitatea" depozitului de date, Datorit faptului c se lucreaz cu volume imense de date (de regul peste 500 GB), se impune o ierarhizare a prioritii datelor n funcie de gradul lor de utilizare. n general, datele vechi nu se mai consult la nivel de detaliu: foarte rare snt cazurile n care cineva este interesat de numrul de buci dintr-un anumit produs vndute

ntr-o anumit zi a anului 1991 la un anumit magazin. Aceste date vor fi transferate pe un suport mai lent (discuri optice, band magnetic, etc.), pstrnd la nivelele de prioritate nalt doar anumite nivele de rezumare. n esen, acest flux trebuie s asigure c nici o informaie important nu se pierde i totodat c informaiile mai puin actuale sau mai puin importante nu blocheaz n mod inutil canalele de comunicaie i mediile de stocare cu acces rapid.
Out-flow (Fluxul de ieire)

Ieirea datelor spre utilizatori reprezint aa-numitul out-flow. Prin aceast deschidere, valoarea informaional creat prin data warehousing devine disponibil pentru ntreaga organizaie, oferind un substanial suport pentru conducerea optim a activitii. Ca i n cazul fluxul de intrare, fluxul de ieire este posibil doar cu suportul unor echipamente adecvate. Spre deosebire de in-flow, unde legtura se fcea mai ales ctre bazele de date ale sistemului tranzacional, n acest caz sunt vizate staiile de lucru ale clienilor. Outflow reprezint "tejgheaua" depozitului de date. Exist dou activiti principale care formeaz acest flux: Accesarea datelor. Aceast activitate se caracterizeaz prin faptul c iniiativa aparine clientului, care solicit informaiile de care are nevoie. Cererile de acces la date pot fi de natur ocazional (interogri ad-hoc), de rutin (zilnice, sptmnale, etc.) sau, n unele cazuri, chiar n timp-real (continue). Livrarea datelor. n acest caz, iniiativa aparine depozitului de date, care trimite din proprie iniiativ anumite date ctre anumii clieni. Data Warehouse face publice diverse obiecte (business objects) care sunt actualizate periodic, iar clienii pot s-i aleag seturile de obiecte care le snt cele mai utile i s le primeasc automat. Deciziile luate pe baza analizei economice facilitate de informaia din depozitul de date se vor concretiza n operaii economice, consemnate prin tranzacii n sistemul operativ, care la rndul lui va crea viitoarele date de intrare n depozitul de date. Uneori influenta deciziilor poate fi estimat sau msurat tot prin instrumente de analiz. La modul teoretic mcar, putem considera c acest flux este conectat la fluxul de intrare, procesul decizional formnd un cerc nchis.
Meta-flow (Meta-fluxul)

Metadatele, fiind date despre date, descriu structura i coninutul depozitului de date. Dar cum structura i coninutul au la rndul lor o dinamic, exprimat prin cele patru fluxuri descrise pn acum, rezult c exist i o dinamic a metadatelor. n principiu, acest meta-flow descrie i conecteaz cele patru fluxuri, fiind un meta-model al dinamicii depozitului de date. Depozitul de date nu este o aplicaie care s poat fi cumprat "de gata". Mai mult, ea nu este proiectat odat pentru totdeauna. Adaptabilitatea sistemului operaional la condiiile mereu noi ale activitii impune o adaptabilitate corespunztoare a sistemului informaional. Dac apar schimbri n aplicaiile organizaiei, ele trebuie s se reflecte n definiiile procedurilor de intrare astfel nct s nu afecteze ieirile. De asemenea, schimbrile n cerinele utilizatorilor trebuie s poat fi rezolvate prin adaptarea corespunztoare a fluxurilor interne. Exist dou aspecte importante legate de meta-flow. Primul este faptul c, aa cum uor se poate deduce, este instrumentul principal de administrare a depozitului de date. Cum

acest depozit este de fapt puntea dintre datele brute i instrumentele de analiz, o bun proiectare a acestui flux trebuie s asigure imunitatea fiecrui subsistem n parte la schimbri intervenite n celelalte. Al doilea aspect este faptul c meta-flow nseamn de fapt modelare, att a sistemului informatic, ct i a activitii de ansamblu. Ispita perfeciunii ne-ar putea ndemna s ncepem proiectarea unui depozit de date cu modelarea activitii ntregii organizaii i a sistemului informatic. Probabil c dintre toate abordrile posibile, aceasta este cea mai pguboas: practic, nu exist anse de a termina vreodat (cu att mai puin n timp util...) o astfel de analiz. Adevrata provocare a proiectrii i administrrii unui depozit de date este de a obine rezultate imediate i de a permite o evoluie continu a sistemului, prin mbuntiri succesive. Iar cheia succesului n aceast direcie o reprezint dinamica metadatelor. Concluzia ar putea fi c nu ajunge ca depozitul de date s existe, el trebuie s i funcioneze. S funcioneze corect, adic s poarte informaia potrivit ctre omul potrivit, n forma potrivit. SISTEM INFORMATIONAL. SISTEM INFORMATIC. Sistemul informaional se interpune ntre sistemul conductor i sistemul operaional (condus), care asigur cuplarea dintre cele dou sisteme, i ofer i modalitatea de atingere a scopurilor propuse.

SISTEM CONDUCTOR Decizii Informaii

SISTEM INFORMAION

SISTEM INFORMATIC

SISTEM CONDUS

El presupune , n principal, desfurarea urmtoarelor activiti: culegerea datelor despre starea sistemului condus i a mediului su nconjurtor; transmiterea datelor n vederea prelucrrii; prelucrarea datelor n scopul asigurrii cu informaii necesare procesului decizional; adoptarea deciziilor i transmiterea acestora spre execuie; asigurarea controlului i urmririi nfptuirii deciziilor. Utilizarea tehnicii moderne de calcul i comunicaii a dus la mutaii majore n modul de realizare a acestor activiti, i a determinat apariia conceptului de sistem informatic. Sistemul informatic economic este un ansamblu de elemente intercorelate funcional n scopul automatizrii obinerii informaiilor i fundamentrii deciziilor. Sistemul informatic constituie, alturi de sistemul birotic, partea automatizat a sistemului informaional, cu care tinde s se identifice.