• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Carte
 

Carte

on

  • 2,007 views

 

Statistics

Views

Total Views
2,007
Views on SlideShare
2,007
Embed Views
0

Actions

Likes
2
Downloads
32
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Carte Carte Document Transcript

    • PerenitateaConceptelor Promovate de BAZELE DE DATE Editia I-a Alexandru Lelutiu Cluj -Napoca 2002
    • Copiilor nostri, Smaranduca, Cristi si Raducu Sa învete sa fie curajosi. Tuturor celor apropiati prin preocupari, care, datorita interesului acordat disciplinei de Baze de Date, m-au încurajat sa-mi exprim parereape un tarâm ce depaseste Tehnica si Ingineria, patrunzând în misterul Informatiei, fara de care pentru noi n-ar exista nimic din ceea ce ar putea exista si fara noi, si nici chiar noi.
    • DIALOGSOCRATE – Suntem de acord, nu-i asa, ca pentru a ne aminti un lucru, trebuie sa-l fi cunoscut înainte.SIMMIAS – Intru totul de acord.SOCRATE – Putem oare a conveni în aceasta privinta ca daca cunostinta ne vine într-o anume maniera, aceasta e o reminiscenta. Iata ce înteleg prin aceasta anume „maniera”: Daca un om care a vazut, a auzit a perceput un lucru într-o maniera diferita decât a lua cunostinta de el, ci gândindu-se la altul, care nu apartine aceluiasi domeniu de cunostinte, nu-i asa ca nu avem drept de a spune ca si-a reamintit lucrul la care s-a gândit?SIMMIAS – Cum asta?SOCRATE – Sa luam un exemplu: Una e cunoasterea unui om si alta e cunoasterea unei lire.SIMMIAS – Fara îndoiala.SOCRATE – Ei bine, n-ai spus tu ce trezeste într-un prieten vederea unui mantou sau a oricarui alt lucru de care amicul sau are obiceiul sa se serveasca? In acelasi moment în care el recunoaste lira el receptioneaza în gândirea sa imaginea prietenului caruia îi apartine acea lira. Si aceasta e o reminiscenta ca si atunci când vazându-l pe Simias îti amintesti de Kebes. Si aici pot sa citez mii de exemple de acest fel.SIMMIAS – Intr-adevar mii, pe Zeus!SOCRATE – Nu este în acest caz un soi de reminiscenta, mai ales când e vorba de lucruri pe care timpul sau neatentia ne-a facut sa le uitam?SIMMIAS – Sigur ca da.SOCRATE – Dar, vazând un cal sau o lira, nu pot oare sa-mi amintesc de un om, si vazând portretul lui Simias sa-mi amintesc de Kebes?SIMMIAS – Desigur.SOCRATE – Si vazând portretul lui Simias sa-mi amintesc de însusi Simias?SIMMIAS – Desigur, se poate Socrate! Platon Dialoguri / Fedon „Doctrina aducerii aminte” (extras)
    • Rostirea evocata poarta o patina de aproape doua milenii si jumatate. Ea a fost transcrisa de catre Profesorul francez Jean Raymond Abrial, de laUniversitatea din Grenoble, în deschiderea prezentarii conceptului de Baza de Date (denumitasimbolic SOCRATE), pornind de la Modelul de Informatii: Entitate – Caracteristica –Valoare, elaborat în colectivul de cercetare pe care îl conducea la începutul anilor 1970. Ce legatura poate avea cugetarea amintita cu Bazele de Date? In aceasta descoperire a puterii de Evocare în reconstituirea unei Realitati trecute seregasesc o multime de raporturi de dualism între conceptele de baza cu care se opereaza înconstruirea Modelelor de Informatii si Date. Dintre acestea amintim urmatoarele: o Informatie - Data în conceperea, proiectarea si prelucrarea Structurilor o Semantic – Sintactic în reprezentarea continutului si formei Informatiei o Nume – Valoare în reprezentarea Structurile de Date si Informatii o Plan Logic – Fizic în descrierea Structurilor de Date si Informatii o Model de Date – Baza de Date Logica în proiectarea generala si particulara a acelorasi structuri Raporturile de mai sus stau la baza definirii Nivelelor de Abstractizare în operarea cuStructurile de Informatii si Date, deschizând calea spre nivelele înalte de concepere siproiectare a structurilor ce stau la baza oricarui sistem de aplicatii. Ca urmare, putem folosi în locul Valorii concrete a Datei, Numele general al Datei, înlocul Nivelului Fizic de reprezentare, Nivelul Logic de descriere, în locul Bazei de DateLogice particulare, Modelul de Date c e permite generarea mai multor instante de Baze deDate adaptate resurselor disponibile, apelând chiar la Sisteme de Gestiune diferite. Legaturile care se creeaza izvorasc toate din puterea asociativa pe care o oferaplanurile paralele de reprezentare a realitatii, Concreta si Simbolica, sustinute de competentafactorului uman, uneori înnascuta, cel mai adesea învatata, de a extrage din simple asocieri,lucruri aparent ascunse si recuperate prin amintire. In exemplele enumerate, ce apartin în întregime Sistemelor cu Baze de Date, în sensulde a fi initiate si apoi promovate cu perseverenta în timp, de mai bine de o jumatate de veac,gasim motivatia frumoasei evocari folosite de profesorul francez. Ideile cresc în stralucire atunci când vin de la o distanta de patru secole înainte de eranoastra, de unde o fiinta reala, recunoscuta ca filosof, nu numai Iubitor de Întelepciune, ci sifondator al filozofiei morale, deci deopotriva I ubitor de Oameni, transmitea semenilor deatunci si de mai apoi mesajul, purtat din gura-n gura, ca Viata nu e un pret prea mare cândpoti da nastere unui Simbol care sa-i lumineze pe cei ce vin, înlesnindu-le cunoasterea,sporindu-le puterea de aflare a caii spre Adevar, Dreptate si Iubire.
    • Prefata 5 “Trecutul este usa Viitorului“ B.P. Hasdeu PREFATA Timpul este Judecatorul neînduplecat al Conceptelor. El da adevaratalor masura, reala lor profunzime, dar mai ales confirmarea fertilitatii lor. Aceasta veche constatare poate fi foarte bine verificata în cazulSistemelor cu Baze de Date (SBD), atunci când se analizeaza aportul lor îndomeniul prelucrarii automate a informatiilor si datelor, dar mai ales când seîncearca aprecierea importantei lor trecute, prezente, dar mai ales viitoare. Aceste sisteme au asistat de-a-lungul deceniilor la aparitii spectaculoasede noi metode, tehnici si limbaje de prelucrare, care au cazut apoi în uitaresau au fost mistuite de noi încercari si descoperiri. In tot acest timp SBD si-aucontinuat nestingherit drumul, pastrându-si personalitatea p domeniul de rinpreocupari, devenind tot mai prietenoase cu utilizatorii prin accesibilitateaconceptelor implementate. Tinta acestor sisteme a ramas permanentconstruirea unei viziuni cât mai unitare si cât mai controlabile asupra Spatiilorde Informatii reprezentate si prelucrate cu tehnici din ce în ce maiperformante. Fidele acestui deziderat ele au asimilat toate noutatile pe carele-au filtrat dupa capacitatea lor de a servi ideilor initiale de gestiune acolectiilor mari de informatii si date. Intre aceste noutati tinem sa mentionampe cele legate de conceptele structuraliste de organizare a datelor siprocedurilor, cele ce promovau viziunea functionala în prelucrare, cele cedezvoltau conceptul de independenta, deschizând orientarea spreorganizarea obiectuala etc. Multe din facilitatile dezvoltate au usurat într-atât utilizarea produselorcomerciale care abunda piata informatica, încât a creat falsa impresie caoricine se pricepe la Baze de Date, ca odata însusite câteva cunostinte deoperare, proiectarea SBD e la îndemâna oricui. De aici s-a nascut simentalitatea multor beneficiari ca achizitia unor asemenea aplicatii trebuie safie gratuita, neglijând urmarile pe care diletantismul în proiectare le aduce maidevreme sau mai târziu, când de fapt totul trebuie reproiectat si de obiceiabia acum se realizeaza faptul ca aceasta costa. Un alt pericol consta în faptul ca pâna si unii proiectanti considera ca,de vreme ce exista utilizatori multumiti cu sisteme improvizate, precis cadomeniul de interes al Bazelor de Date s-a deplasat spre construireainterfetelor de acces spectaculoase, acolo unde tehnologiile în inflatielanseaza mereu o noua moda, chiar si atunci când nu sunt înca suficientdefinite, mai ales în ceea ce priveste raportul lor cu sistemele traditionale, pecare refuza sa le înteleaga considerându-le apuse. Atitudinea: „Sursa de Datetrebuie lasata la latitudinea utilizatorului, fie el si neinstruit” determina înmultirearapida a produselor de ocazie, efemere si inconsistente ca structura. Pornind
    • 6 Prefatade la observatiile facute, consideram utila o prezentare a conceptelor debaza, care în lumina timpului trecut de la prima lor lansare, au fost permanentconfirmate, dezvoltate si corelate, asa încât sa permita în prezent o corectadefinire a SBD si sa ofere totodata fundamentul pentru dezvoltarea acestoraspre o proiectare de nivel mai înalt. Acest nivel va implica definirea siconstruirea structurilor de date si proceduri, reunite în domeniul mai larg alModelelor de Date, ce încorporeaza atât Structurile de Date cât si Restrictiile siOperatiile aferente, declarate la un nivel superior de abstractizare, cucapacitate generativa sporita. Aceasta intentie justifica absenta unor capitolede interes recent, legate de tehnologiile de acces de la distanta la sursele dedate organizate ca Baze de Date, în favoarea concentrarii atentiei asupraîntelegerii acelor particularitati care mentin si azi interesul în jurul SBD. Cititorulva fi ajutat sa caute raspuns la unele întrebari importante, legate deprocesarea datelor, cum ar fi: o De ce Sistemele cu Baze de Date sunt înca în voga? o Este conceptul de Independenta asociat cu SBD? o Este Modelul Relational perisat? o Model Relational sau Obiectual? o Simplitatea Tabelei mai poate ascunde secrete? o Explorarea Dependentele între Informatii e straina Bazelor de Date? Cu acest cadru propus lucrarea nu va oferi prilejul de învatare a unuiLimbaj, a unui Produs sau a unei Tehnici, ci posibilitatea însusirii unei viziunigenerale asupra drumului parcurs de SBD si mai ales asupra zestrei decunostinte pe care acest domeniu îl pune la dispozitia Cercetatorului,Proiectantului si Utilizatorului. Ca urmare ea se adreseaza tuturor acestorcategorii de specialisti, la care se adauga bineînteles cei ce se initiaza prinstudiu sau practica în acest domeniu promitator (studenti sau elevi). Numerosi colaboratori (cadre didactice, cercetatori, proiectanti,implementatori, studenti), însirati pe un drum de 30 de ani de activitate îndomeniu, gasesc aici cuvântul meu de multumire pentru spijinul acordat cugenerozitate si pasiune. Daca acest sprijin a fost cu adevarat folosit va puteahotarî desigur numai cititorul. Exista între cei apropiati o categorie apartepentru care cuvântul meu de multumire e de prisos, caci au alergat preaaproape de mine, ducându-ma spre tinta si ferindu-se la vederea liniei desosire si care doresc acum doar sa afle daca am trecut-o cu bine. Dar siiaceasta informatie o pot afla doar de la cititor. Mai este loc pe prezentapagina pentru o lacrima de iubire închinata celor care mi-au împartasitsinguratatea, asteptându-ma. Autorul
    • Prefata 7Cluj – Napoca, septembrie 2002
    • 8 Prefata C U P R I N SPREFATA .................................................................................................................................................. 51 Introducere......................................................................................................................................17 1.1 Importanta Sistemelor cu Baze de Date .........................................................................17 1.2 Aportul Sistemelor cu Baze de Date ...............................................................................19 1.3 Continutul Lucrarii .............................................................................................................212 Sisteme cu Baze de Date...............................................................................................................28 2.1 Aparitia Conceptului de Baza de Date ...........................................................................28 2.1.1 Nivele de Abstractizare într-un SBD ..........................................................................28 2.1.2 Functiile unui SGBD .....................................................................................................33 2.1.3 Raportul Date - Proceduri .............................................................................................34 2.2 Definitia Bazelor de Date ...................................................................................................36 2.3 Avantajele utilizarii Bazelor de Date ..............................................................................37 2.4 Exemple de Baze de Date ...................................................................................................383 Concepte de Baza...........................................................................................................................42 3.1 Multimi si Relatii..................................................................................................................42 3.1.1 Multimi ............................................................................................................................42 3.1.1.1 Caracteristicile de baza ale Multimii......................................................................43 3.1.1.2 Incluziunea Multimilor .............................................................................................43 3.1.1.3 Identitatea Multimilor ...............................................................................................44 3.1.1.4 Multimea Totala .........................................................................................................44 3.1.1.5 Numararea Partilor unei Multimi Totale ................................................................45 3.1.1.6 Operatii Booleene pe Multimea Partilor unei Multimi Totale ...........................46 3.1.1.7 Acoperire si Partitie ...................................................................................................46 3.1.1.8 Latice............................................................................................................................47 3.1.2 Relatii între Multimi ......................................................................................................48 3.1.2.1 Produs Cartezian de multimi....................................................................................49 3.1.2.2 Reuniunea Disjuncta a Multimilor..........................................................................49 3.1.2.3 Relatia n-ara ................................................................................................................49 3.1.2.4 Implicarea relatiilor (Extensii si Restrictii)...........................................................50 3.1.2.5 Proiectia relatiilor ......................................................................................................51 3.1.2.6 Proprietatile Relatiilor Binare ..................................................................................52 3.1.2.6.1 Relatii Binare pe Doua Multimi Distincte .....................................................52 3.1.2.6.2 Relatii Binare pe Aceeasi Multime .................................................................53 3.1.2.6.2.1 Tipuri de Relatii Binare pe Aceeasi Multime ........................................55 3.1.2.6.2.1.1 Relatia de Echivalenta .......................................................................55 3.1.2.6.2.1.2 Relatii de Ordine.................................................................................56 3.1.2.6.2.1.2.1 Relatia de Ordine Partiala ..........................................................57 3.1.2.6.2.1.2.2 Relatia de Ordine Totala ............................................................58
    • Cuprins 9 3.1.2.6.2.1.2.3 Relatia de Bine Ordonare ..........................................................59 3.1.2.6.2.1.3 Relatia de Similitudine (Asemanare) ..............................................59 3.1.3 Relatii, Aplicatii, Functii .............................................................................................60 3.1.4 Grafuri ..............................................................................................................................60 3.1.4.1 Graful ca Relatie ........................................................................................................60 3.1.4.2 Graful ca Aplicatie .....................................................................................................61 3.1.4.3 Arbori...........................................................................................................................623.2 Informatie si Data ................................................................................................................65 3.2.1 Modelul Matematic ........................................................................................................66 3.2.2 Modelul Semiotic ...........................................................................................................67 3.2.3 Modelul Propozitional...................................................................................................683.3 Date si Proceduri..................................................................................................................713.4 Structuri de Informatii si Date .........................................................................................73 3.4.1 Structura, Organizare si Acces.....................................................................................73 3.4.1.1 Structura Logica si Fizica.........................................................................................77 3.4.1.2 Spatiul de Informatii si de Date...............................................................................80 3.4.2 Structuri Fundamentale de Informatii si Date ...........................................................83 3.4.2.1 Definirea Structurilor Fundamentale ......................................................................83 3.4.2.2 Transformarea Structurilor Fundamentale .............................................................91 3.4.2.2.1 Tipuri de transformari .......................................................................................91 3.4.2.2.1.1 Eliminarea Redondantei............................................................................92 3.4.2.2.1.2 Inversarea Partiala (Indexarea).................................................................93 3.4.2.2.1.3 Eliminarea Redondantei + Inversarea Partiala ......................................94 3.4.2.2.1.4 Inversarea Totala ........................................................................................96 3.4.2.2.1.5 Reorganizarea Structurii............................................................................98 3.4.2.2.2 Generalizarea Conceptului de Inversare.........................................................99 3.4.3 Reprezentarea Structurilor de Informatii si de Date...............................................101 3.4.3.1 Reprezentarea Fizica (Reprezentarea Clasica)....................................................101 3.4.3.2 Reprezentarea Logica (Reprezentarea Simbolica).............................................103 3.4.3.3 Arborele de Structura ..............................................................................................107 3.4.3.4 Diagrama Entitati – Relatii.....................................................................................111 3.4.3.5 Schema de Descriere ..............................................................................................115 3.4.4 Structuri de Informatii la Utilizator...........................................................................116 3.4.4.1 Structura de Ansamblu............................................................................................116 3.4.4.2 Structuri Partiale ......................................................................................................119 3.4.4.3 Reprezentarea Structurii de Ansamblu .................................................................124 3.4.5 Diversificarea Tipurilor de Legaturi între Entitati..................................................127 3.4.5.1 Viziunea în Produsul ORACLE ............................................................................127 3.4.5.2 Viziunea în Produsul ERWIN ...............................................................................1353.5 Structuri de Proceduri......................................................................................................138 3.5.1 Operatie si Procedura ..................................................................................................138 3.5.2 Operatii de control .......................................................................................................139 3.5.2.1 Compozitia ................................................................................................................139 3.5.2.2 Selectia .......................................................................................................................139 3.5.2.3 Repetitia .....................................................................................................................141
    • 10 Cuprins 3.5.2.4 Substitutia..................................................................................................................142 3.5.3 Elementele Structurilor de Proceduri........................................................................142 3.5.4 Descrierea Formala a Procedurilor............................................................................144 3.5.5 Descrierea în Pseudo - Cod ........................................................................................145 3.5.6 Arborele de Programare ..............................................................................................1464 Modele de Informatii si Date.....................................................................................................152 4.1 Modele de Informatii ........................................................................................................152 4.1.1 Modelul Entitate – Caracteristica – Valoare (Modelul ECV) ..............................152 4.1.1.1 Descrierea Spatiului de Informatii ........................................................................152 4.1.1.2 Descrierea Spatiului de Date..................................................................................155 4.1.1.3 Entitate – Caracteristica – Valoare .......................................................................157 4.1.1.3.1 Entitate ...............................................................................................................158 4.1.1.3.2 Clasa de Entitati................................................................................................159 4.1.1.3.3 Metaclasa de Entitati .......................................................................................161 4.1.1.3.4 Caracteristica.....................................................................................................162 4.1.1.3.5 Valoare ...............................................................................................................163 4.1.1.3.6 Relatii de Asociere ...........................................................................................165 4.1.1.3.7 Ansamblu de Entitati .......................................................................................166 4.1.1.3.8 Clasa de Ansambluri de Entitati ....................................................................168 4.1.1.4 Modelul formal ECV în termeni de Multimi si Relatii ....................................171 4.1.1.4.1 Definire matematica.........................................................................................171 4.1.1.4.2 Descriere g rafica...............................................................................................171 4.1.2 Modelul Obiectelor Abstracte (OA) .........................................................................174 4.1.2.1 Procesul de Abstractizare .......................................................................................174 4.1.2.2 Obiecte Abstracte.....................................................................................................175 4.1.2.2.1 Obiecte Generice ..............................................................................................175 4.1.2.2.2 Obiecte Agregate..............................................................................................178 4.1.2.3 Ierarhii de Obiecte Abstracte .................................................................................179 4.1.2.4 Realizari de Obiecte Abstracte..............................................................................182 4.1.2.5 Ierarhii de Obiecte Abstracte în Planul Realizarilor..........................................183 4.1.2.6 Relativitatea Viziunii asupra Obiectelor Abstracte............................................186 4.1.2.7 Sintaxa Abstracta.....................................................................................................189 4.1.2.8 Operatii Abstracte....................................................................................................191 4.1.2.9 Principiul Conservarii Semantice..........................................................................191 4.1.2.10 Metodologia de Proiectare în Modelul OA.....................................................192 4.1.2.10.1 Continutul Metodologiei de Proiectare ......................................................192 4.1.2.10.2 Erori de Utilizare a Metodologiei ...............................................................193 4.1.2.10.2.1 Stabilirea Categoriilor Directe .............................................................193 4.1.2.10.2.2 Stabilirea Componentelor Directe.......................................................194 4.1.2.10.2.3 Identificarea Incompleta .......................................................................195 4.1.2.10.2.4 Tratarea Obiectelor Abstracte de tip Rol............................................195 4.1.3 Modelul Conceptual.....................................................................................................200 4.2 Modele de Date ...................................................................................................................206 4.2.1 Tipuri de Modele de Date ...........................................................................................206 4.2.1.1 Arhitectura Modelelor de Date Stricte .................................................................207 4.2.1.1.1 Descrierea Structurii........................................................................................209
    • Cuprins 11 4.2.1.1.2 Descrierea Restrictiilor....................................................................................210 4.2.1.1.3 Descrierea Operatiilor .....................................................................................2134.2.2 Modelul Ierarhic ...........................................................................................................214 4.2.2.1 Segmentul de Articol ca si Constructor de Structura.........................................214 4.2.2.2 Avantajele si Dezavantajele Modelului Ierarhic ................................................2164.2.3 Modelul Retea...............................................................................................................217 4.2.3.1 Setul de Articole ca si Constructor de Structura.................................................217 4.2.3.2 Avantajele si Dezavantajele Modelului Retea ....................................................2224.2.4 Modelul Relational.......................................................................................................224 4.2.4.1 Relatia ca si Constructor de Structura ..................................................................224 4.2.4.2 Proprietatile Relatiei................................................................................................228 4.2.4.3 Intensiunea si Extensiunea Relatiilor ...................................................................230 4.2.4.4 Cheile Relatiilor.......................................................................................................231 4.2.4.4.1 Reguli de Integritate a Relatiilor ...................................................................232 4.2.4.4.2 Identificare, Acces si Ordonare în Structuri Relationale ...........................232 4.2.4.4.2.1 Chei de Identificare ..................................................................................233 4.2.4.4.2.2 Chei de Acces............................................................................................236 4.2.4.4.2.3 Chei de Ordonare......................................................................................242 4.2.4.5 Manipularea Structurilor Relationale ...................................................................244 4.2.4.5.1 Metoda bazata pe Algebra Relationala .........................................................245 4.2.4.5.1.1 Operatori Relationali................................................................................245 4.2.4.5.1.2 Operatori Relationali Traditionali..........................................................247 4.2.4.5.1.3 Operatori Specific Relationali................................................................251 4.2.4.5.1.4 Set Complet de Operatori Relationali...................................................257 4.2.4.5.1.5 Sintaxa unui LMD bazat pe Algebra Relationala ...............................257 4.2.4.5.1.6 Limbajul de Navigare si Operatorii Algebrei Relationale .................259 4.2.4.5.1.7 Tipuri de SGBD-uri Relationale ............................................................260 4.2.4.5.2 Metoda bazata pe Calculul Relational..........................................................261 4.2.4.5.2.1 Limbajul Logic ..........................................................................................261 4.2.4.5.2.2 Calculul Relational al Tuplelor..............................................................264 4.2.4.5.2.2.1 Elementele Expresiilor în CRT ......................................................264 4.2.4.5.2.2.2 Variabile Libere si Legate...............................................................265 4.2.4.5.2.2.3 Expresii de Calcul Relational al Tuplelor ....................................267 4.2.4.5.2.2.4 Implementare Calcului Relational al Tuplelor ............................268 4.2.4.5.2.2.4.1 Exemple de ECT .......................................................................268 4.2.4.5.2.2.4.2 Limbajul SQL............................................................................270 4.2.4.5.2.3 Calculul Relational al Domeniilor.........................................................277 4.2.4.5.2.3.1 Elementele Expresiilor în CRD......................................................277 4.2.4.5.2.3.2 Variabile Libere si Legate...............................................................279 4.2.4.5.2.3.3 Expresii de Calcul Relational al Domeniilor ...............................279 4.2.4.5.2.3.4 Implementare Calcului Relational al Domeniilor.......................280 4.2.4.5.2.3.4.1 Exemple de ECD.......................................................................280 4.2.4.5.2.3.4.2 Limbajul QBE ...........................................................................281 4.2.4.6 Nivelul Extern în Modelul Relational ..................................................................285 4.2.4.6.1 Vederea ca si Constructor al Nivelului Extern ............................................285 4.2.4.6.2 Operatii în LMD asupra Vederilor................................................................287 4.2.4.6.3 Vederile si Independenta Datelor..................................................................290
    • 12 Cuprins 4.2.4.7 Modelul Relational ca Model Strict de Date.......................................................292 4.2.4.7.1 Structura datelor..............................................................................................292 4.2.4.7.2 Tipuri de Structuri Relationale .......................................................................297 4.2.4.7.2.1 Tipuri de Legaturi Relationale ...............................................................298 4.2.4.7.2.2 Tipuri de Relatii........................................................................................300 4.2.4.7.2.2.1 Relatii de tip Entitate .......................................................................301 4.2.4.7.2.2.1.1 Entitate Completa .....................................................................301 4.2.4.7.2.2.1.2 Entitate Incompleta...................................................................302 4.2.4.7.2.2.2 Relatii de tip Legatura .....................................................................304 4.2.4.7.2.2.2.1 Legatura Simpla ........................................................................304 4.2.4.7.2.2.2.2 Legatura Completa ...................................................................307 4.2.4.7.2.2.3 Relatii de tip Mixt .............................................................................308 4.2.4.7.3 Implementarea Relationala a Operatiilor de Abstractizare .......................311 4.2.4.7.3.1 Implementarea Agregarii.........................................................................312 4.2.4.7.3.2 Implementarea Generalizarii ..................................................................312 4.2.4.7.3.3 Tip General de Structura Relationala ....................................................314 4.2.4.7.4 Restrictii impuse Datelor..............................................................................315 4.2.4.7.4.1 Restrictii Implicite....................................................................................315 4.2.4.7.4.2 Restrictii Explicite....................................................................................316 4.2.4.7.5 Operatii asupra datelor....................................................................................318 4.2.4.7.5.1 Operatii Procedurale – Navigarea în Tabele .......................................319 4.2.4.7.5.2 Operatii Neprocedurale ...........................................................................322 4.2.4.7.5.3 Nivele de Definire a Operatiilor.............................................................323 4.2.4.8 Construirea Structurilor Relationale .....................................................................324 4.2.4.8.1 Generalizarea Entitatilor .................................................................................324 4.2.4.8.2 Agregarea Entitatilor .......................................................................................328 4.2.4.8.2.1 Structuri 1 - n.............................................................................................328 4.2.4.8.2.2 Structuri m - n ...........................................................................................329 4.2.4.8.3 Reprezentarea Structurilor Ierarhice .............................................................345 4.2.4.8.3.1 Reprezentarea Entitatii ............................................................................347 4.2.4.8.3.2 Reprezentarea Subentitatii ......................................................................349 4.2.4.8.4 Reprezentarea Structurilor Matriciale ...........................................................357 4.2.4.8.5 Reprezentarea Datelor de Tip Multime ........................................................359 4.2.4.9 Conditiile ca o BD sa fie Relationala ...................................................................362 4.2.4.9.1 Reguli de Fundamentare – Regula 0 si 12 ...................................................362 4.2.4.9.2 Reguli Structurale – Regula 1 si 6.................................................................363 4.2.4.9.3 Reguli de Integritate – Regula 10 si 3 ..........................................................364 4.2.4.9.4 Reguli de Manipulare a Datelor – Regula 5, 2, 7 si 4................................365 4.2.4.9.5 Reguli de Independenta a Datelor – Regula 8, 9 si 11...............................3665 Optimizarea Modelelor de Date................................................................................................369 5.1 Optimizarea Structurilor de Date .................................................................................369 5.1.1 Introducere.....................................................................................................................370 5.1.2 Abordarea Formalizata a Normalizarii Relatiilor...................................................371 5.1.2.1 Definitii si Notatii....................................................................................................371 5.1.2.2 Dependente Functionale .........................................................................................373 5.1.2.2.1 Definitii si Notatii ............................................................................................373
    • Cuprins 13 5.1.2.2.1.1 Proprietatile Formale ale Dependentelor Functionale.......................374 5.1.2.2.2 Relatii Normalizate BCNF .............................................................................378 5.1.2.3 Dependente Multivalorice ......................................................................................379 5.1.2.3.1 Proprietatile Formale ale Dependentelor Multivalorice:...........................381 5.1.3 Abordarea Istorica a Normalizarii Relatiilor...........................................................383 5.1.3.1 Studiu de Caz............................................................................................................384 5.1.3.1.1 Spatiul Informatiilor ........................................................................................384 5.1.3.1.1.1 Descrierea Spatiului de Informatii.........................................................384 5.1.3.1.1.2 Diagrama Simbolica.................................................................................385 5.1.3.1.1.3 Diagramele Dependentelor Functionale ...............................................386 5.1.3.1.2 Spatiul Datelor..................................................................................................387 5.1.3.1.2.1 Descriere Intensionala .............................................................................387 5.1.3.1.2.2 Arborele de Structura ...............................................................................389 5.1.3.1.2.3 Descriere Extensionala – Valori Memorate .........................................389 5.1.3.2 Etapele Normalizarii................................................................................................390 5.1.3.2.1 Relatii Normale de Grad 1..............................................................................391 5.1.3.2.2 Relatii Normale de Grad 2..............................................................................391 5.1.3.2.3 Relatii Normale de Grad 3..............................................................................394 5.1.3.2.4 Descompunerea Relatiilor ..............................................................................395 5.1.3.2.5 Relatii Normale BCNF....................................................................................399 5.1.3.2.5.1 Relatii cu Chei Candidate Multiple Disjuncte.....................................399 5.1.3.2.5.2 Relatii cu Chei Candidate Multip le Nedisjuncte.................................400 5.1.3.2.6 Relatii Normale de Grad 4..............................................................................403 5.1.3.2.7 Relatii Normale de Grad 5 (PJNF) ................................................................405 5.1.3.2.8 Concluzii............................................................................................................410 5.1.4 Abordarea Semantica a Normalizarii Relatiilor......................................................411 5.1.4.1 Abordarea Sistemica a Proiectarii.........................................................................413 5.1.4.2 Utilizarea Modelului Obiectelor Abstracte .........................................................427 5.1.4.2.1 Implementarea Relationala a Modelului Obiectelor Abstracte................428 5.1.4.2.2 Definirea Restrictiilor......................................................................................428 5.1.4.2.3 Definirea Procedurilor Stocate.......................................................................428 5.1.4.3 Concluzii finale ........................................................................................................429 5.2 Optimizarea Cererilor ......................................................................................................430 5.2.1 Evaluarea Costurilor de Prelucrare a Cererilor.......................................................430 5.2.2 Reorganizarea Cererilor..............................................................................................431 5.2.2.1 Tratarea Produselor Carteziene .............................................................................431 5.2.2.2 Tratarea Reunirilor..................................................................................................433 5.2.3 Strategii Generale de Optimizare ..............................................................................4336 Securitatea Bazelor de Date.......................................................................................................436 6.1 Controlul Accesului la Date.............................................................................................436 6.1.1 Categorii de Informatii gestionate în Controlul Accesului la Date .....................436 6.1.2 Controlul Drepturilor de Acces la Date cu ajutorul LMD....................................438 6.1.3 Controlul Confidentialitatii de Acces la Date .........................................................439 6.2 Prelucrari Tranzactionale ...............................................................................................443 6.2.1 Erori în Tranzactii Necontrolate ................................................................................444
    • 14 Cuprins 6.2.2 Tipurile de Întreruperi ale unei Tranzactii...............................................................446 6.2.3 Starile unei Tranzactii .................................................................................................447 6.2.4 Jurnalizarea Tranzactiilor ...........................................................................................450 6.2.5 Proprietatile unei Tranzactii Atomice.......................................................................451 6.2.6 Planul de Operatii Tranzactionale .............................................................................452 6.2.7 Proprietatile Tranzactiilor în Refacerea Bazei de Date .........................................453 6.2.8 Serializarea Tranzactiilor............................................................................................455 6.2.9 Controlul Concurentei.................................................................................................461 6.2.10 Granularitatea Datelor.................................................................................................466 6.3 Refacerea B azelor de Date ...............................................................................................467 6.3.1 Termeni si Concepte....................................................................................................467 6.3.2 Tehnici de Refacere .....................................................................................................471 6.3.2.1 Tehnica bazata pe Actualizarea Amânata............................................................472 6.3.2.2 Tehnica bazata pe Actualizarea Imediata ............................................................4737 Baze de Date Evoluate ................................................................................................................475 7.1 Baze de Date Deductive ....................................................................................................476 7.1.1 Inferenta bazata pe Calculul Propozitional..............................................................477 7.1.2 Inferenta bazata pe Calculul Predicativ ....................................................................482 7.1.3 Descrierea Formala a unui Limbaj Predicativ .........................................................483 7.1.3.1 Predicate ....................................................................................................................483 7.1.3.2 Formule Bine Construite ........................................................................................483 7.1.4 Interpretare si Model ...................................................................................................485 7.1.4.1 Interpretarea Formulelor.........................................................................................485 7.1.4.2 Evaluarea Formulelor Bine Construite.................................................................488 7.1.4.3 Model.........................................................................................................................489 7.1.5 Forme Clauzale .............................................................................................................491 7.1.6 Deducere în Baze de Date...........................................................................................493 7.1.7 Viziunea Inferentiala a unei BDD.............................................................................500 7.1.8 Metode de Deducere în SBD......................................................................................505 7.1.8.1 SBD Pur Deductive .................................................................................................505 7.1.8.2 SBD Deductive Mixte .............................................................................................507 7.1.8.3 SBD Deductiv-Generative......................................................................................510 7.2 Baze de Date Distribuite ...................................................................................................513 7.2.1 Generalitati....................................................................................................................513 7.2.2 Solutii Generale de Proiectare....................................................................................515 7.2.3 Proiectarea Structurilor de Date Distribuite ............................................................520 7.2.3.1 Generalitati................................................................................................................520 7.2.3.1.1 Baze de Date Distribuite ( BDS) ...................................................................521 7.2.3.1.2 Arhitecturi Client - Server ..............................................................................522 7.2.3.2 Tehnici de proiectare a BDS..................................................................................523 7.2.3.2.1 Tehnica de Fragmentare ..................................................................................524 7.2.3.2.1.1 Fragmentarea Orizontala ........................................................................526 7.2.3.2.1.2 Fragmentarea Verticala ..........................................................................527 7.2.3.2.1.3 Fragmentarea Mixta ................................................................................527 7.2.3.2.2 Tehnica de Replicare .......................................................................................528
    • Cuprins 15 7.2.3.2.3 Tehnica de Alocare ..........................................................................................528 7.2.3.2.4 Studiu de Caz....................................................................................................529 7.2.3.3 Tipuri de Baze de Date Distribuite .......................................................................534 7.2.3.3.1 Criteriul de Omogenitate.................................................................................534 7.2.3.3.2 Criteriul de Autonomie....................................................................................534 7.2.3.3.3 Criteriul de Transparenta................................................................................535 7.2.3.4 Procesarea Cererilor în Baze de Date Distribuite ........................................535 7.2.3.4.1 Costurile în Procesarea Distribuita................................................................535 7.2.3.4.2 Procesarea Cererilor Distribuite prin Operatia de SEMIJOIN.................538 7.2.3.4.3 Descompunerea Cererilor si Actualizarilor .................................................540 7.2.3.5 Controlul Concurentei si al Securitatii.................................................................543 7.2.3.5.1 Generalitati........................................................................................................543 7.2.3.5.2 Controlul Concurentei Distribuite cu Copie Distincta a Datelor .............544 7.2.3.5.2.1 Tehnica Statiei Primare ...........................................................................544 7.2.3.5.2.2 Tehnica Statiei Primare cu Statie de Salvare .......................................545 7.2.3.5.2.3 Tehnica Copiei Primare ...........................................................................545 7.2.3.5.2.4 Tehnica Alegerii Dinamice a Coordonatorului...................................545 7.2.3.5.3 Controlul Concurentei Distribuite prin Tehnica Votarii............................545 7.2.3.5.4 Securitatea Distribuita .....................................................................................546 7.3 Baze de Date Obiectuale...................................................................................................547 7.3.1 Generalitati....................................................................................................................547 7.3.2 Independenta Obiectelor.............................................................................................550 7.3.2.1 Clase de Obiecte.......................................................................................................553 7.3.2.2 Metode si Mesaje .....................................................................................................557 7.3.2.3 Restrictii impuse Obiectelor...................................................................................558 7.3.3 Mostenirea între Obiecte.............................................................................................558 7.3.3.1 Mostenire Structurala ..............................................................................................560 7.3.3.2 Mostenirea Comportamentala ................................................................................563 7.3.3.2.1 Mostenire Simpla .............................................................................................565 7.3.3.2.2 Mostenire Multipla ...........................................................................................566 7.3.3.3 Meclase, Clase si Obiecte.......................................................................................568 7.3.4 Identitatea Obiectelor ..................................................................................................569 7.3.5 Comunicarea între Obiecte .........................................................................................575 7.3.6 Solutii de Implementare pentru BDO.......................................................................576 7.4 Consideratii Critice ...........................................................................................................577ANEXE....................................................................................................................................................5828 Scurt Istoric al Evolutiei SBD...................................................................................................5829 Principalele Surse de Informare...............................................................................................583POSTFATA...........................................................................................................................................584Lista Figurilor si Tabelelor.................................................................................................................585Bibliografie.............................................................................................................................................592Index de Termeni ..................................................................................................................................598
    • 16 Importanta Sistemelor cu Baze de DatePARTEA 1 -a INTRODUCERE Sectiunile de Introducere subliniaza interesul, consolidat în timp, referitor la Sistemele cu Baze de Date si indirect atractia mentinuta vreme de mai bine de o jumatate de veac în jurul dezbaterilor având în centrul lor subiecte din domeniul SBD. Sectiunile continute în Introducere puncteaza notele caracteristice ale acestei atractii îndelungate. 1.1 – Importanta Sistemelor cu Baze de Date – se face o trecere în revista a domeniilor din Stiinta Calculatoarelor si din Informatica Aplicata care vizeaza SBD. Un accent special este pus pe domenii noi, de mare atractie în prezent (Warehousing, Data Mining), care au în fundal aceleasi Arhitecturi promovate de BD. 1.2 – Aportul Sistemelor cu Baze de Date – sunt enumerate principalele avantaje care mentin SBD în centrul preocuparilor legate de Prelucrarea Automata a Datelor. Rezulta cu usurinta faptul ca avantajele amintite îsi vor mentine perenitatea în contextul cresterii interesului pentru Industrializarea Procesului de Elaborare de Programe si Aplicatii. 1.3 – Continutul Lucrarii – face oficiul consacrat de Ghid al Cititorului în lucrarea gândita ca o Monografie de Concepte, promovate într-un domeniu deosebit de peren.
    • Importanta Sistemelor cu Baze de Date 171 Introducere1.1 Importanta Sistemelor cu Baze de Date Sistemele cu Baze de Date (SBD) apar ca produse de software individualizate îndeceniul al saptelea al secolului al XX-lea. Un traseu al drumului parcurs de SBD esteprezentat în Tab. 9.1 din Anexe. Viziunea noua pe care ele o aduc asupra prelucrarii automate adatelor polarizeaza atentia specialistilor, cercetatorilor si comerciantilor de-a lungul a mai binede patru decenii. Afirmatia nu este exagerata întrucât, oricât de mare a fost în timp dorinta deînnoire prin introducerea de noi termeni (unii ramasi pentru multi la nivelul unor atragatoare“cuvinte claxon”) – Sisteme cu Reguli Inteligente, Baze de Cunostinte, Baze de DateObiectuale, Explorarea Datelor (Data Mining), Gestiunea Specializata a Depozitelor(Warehousing) etc., acesti noi termeni nu au putut regasi taria principiilor fundamentate siconfirmate prin nenumarate implementari de catre Sistemele cu Baze de Date si înca mai mult,s-au sprijinit puternic pe acestea, în masura în care nu au vrut sa ramâna doar captivanteexercitii de testare a abilitatii discipolilor în prelucrarea informatiei. Argumentatia poate fi completata cu o serie de întrebari retorice: - Ce implementare reala de Reguli Inteligente e mai fecunda decât sistemele de Restrictii ale Bazelor de Date? - Ce Sistem de Constrângeri nu devine mai puternic când e implementat în centrul nucleului de informatii ca si Constrângeri Intrinseci? - Ce Dependente între informatii ramân straine Sistemelor Normalizate ale Bazelor de Date? - Ce Explorare de Date (Data Mining) poate fi efectuata cu succes în afara unei Surse de Date construita pe o Baza de Date? - Ce Warehousing nu e construit pe structura unei Baze de Date Specializate? - Ce Cunostinte nu pot fi înmagazinate în Procedurile Stocate ale unei Baze de Date? - Ce rafinament semantic de Agregare, Generalizare, Specificare, Taxonomie nu poate fi exprimat de Modelele de Date ce stau în spatele structurii logice ale unei Baze de Date?Si exemplele pot continua sub semnul transformarii conceptelor teoretice bine fundamentate îninstrumente practice puse la dispozitia unor categorii foarte diverse de utilizatori finali.Înseamna ca interesul Bazelor de Date mentinut si în prezent este motivat. Motivata apare sicresterea acestui interes prin încorporarea în sistemele ce Baze de Date a tuturor noilor cuceririîn domeniul tehnologiilor avansate de prelucrare a informatiei. Se poate afirma ca în timp cemulte limbaje, metode si tehnici, de mare senzatie în momentul aparitiei lor, au intrat în muzeu(evitam aici enumerari pentru a nu stârni gratuite adversitati), Sistemele cu Baze de Date augasit mereu noi cai de dezvoltare odata cu dezvoltarea tehnologiei de calcul. In prezent oricesistem complex nu poate fi privit în afara unei puternice surse de date, structurata, consistenta,persistenta, care implica un sistem adecvat de gestiune. De data aceasta enumerarile nu ne maipot aduce prejudicii:
    • 18 Importanta Sistemelor cu Baze de Date o Sistemele Informatice pentru Conducere – privite ca Sisteme cu Baze de Date o Bazele de Date din Sistemele de Programare Logica o Bazele de Date pentru Prelucrarea Textelor si Metatextelor o Bazele de Date Grafice pentru Proiectarea Asisteta de Calculator (CAD) o Bazele de Date din Sistemele Informatice Geografice (GIS) o Bazele de Date Orientate Obiectual o Bazele de Date InteligenteSi în cazul acestei enumerari exemplele pot continua. In privinta interesului pe care piata informatica l-a aratat Sistemelor cu Baze de Dateeste foarte semnificativ numarul deosebit de mare de Sisteme de Gestiune a Bazelor de Date(SGBD-uri) oferite de producatori în acest rastimp pe toate platformele Hardware si Software,precum si în toate tehnologiile de prelucrare, de la SGBD-uri pentru calculatoare individuale latehnologii Client – Server si apoi la arhitecturi pe trei nivele (three tired architectures). SGBD-urile pot fi întâlnite între primele trei produse Software cerute, vândute si utilizate pe piatainformatica. Rasfoiti la întâmplare orice ziar de oferte de servicii informatice si veti puteavedea ce convingator este si în prezent procentul de solicitari de specialisti în domeniul Bazelorde Date. Ca o consecinta fireasca a acestui interes nu exista programa de învatamânt despecialitate, universitar sau preuniversitar, care sa nu contina disciplina de Baze de Date subforma de curs, seminarii, lucrari practice si proiecte. Dar si pentru nespecialisti (chimisti,fizicieni, dar si biologi, filologi, juristi etc.) necesitatea crearii unor Colectii de Informatii binestructurate reprezinta o cerinta primordiala. Potentialul înca neatins al SBD consta pe de o parte în deschiderea pe care ele o au de aconstrui cu ajutorul Modelelor de Date noi nivele de abstractizare în abordarea problemelorreale, carora însa le ofera si promisiunea, sustinuta de garantia necesara, ca vor putea fiimplementate. In al doilea rând SBD sunt pregatite pentru a folosi performantele în continuacrestere ale platformelor Hardware, ceea ce va spori interesul pentru Solutiile Normalizate deStructura, pentru Independenta reala a Nivelului Extern de definire a datelor, pentruimplementarea Obiectelor Active direct în Nivelul Extern etc. Nu putem încheia aceasta scurta pledoarie în favoarea SBD fara a sublinia contributiadeosebita pe care Bazele de Date au adus-o în domeniul dezvoltarii si implementarii unorconcepte deosebit de fructuoase cum ar fi Viziunea Structuralista, Independenta Structurala,Formele de Dependenta Structurala, Unificarea Date-Proceduri prin Materializarea Datelor,Orientarea pe Eveniment a Procedurilor, Conceptia Integratoare de Sistem. Neglijarea concluziilor acumulate timp de aproape o jumatate de secol, poate duce laexperimente foarte costisitoare, nu numai în sfera producatorilor, mai mici dar foarte numerosi,de Sisteme de Aplicatii, dar si în categoria marilor producatori de Produse Specializate, cum arfi SGBD-urile. In acelasi sens, întelegerea aportului real pe care aceste sisteme de prelucrarel-au adus în domeniul procesarii volumelor mari de date, complex structurate, pot orientacercetari si dezvoltari care sa combine cresterea Performantelor în FunctionareaEchipamentelor cu ridicarea Nivelului Conceptual de Proiectare.
    • Aportul Sitemelor cu Baze de Date 191.2 Aportul Sistemelor cu Baze de Date Dorim sa raspundem în aceasta sectiune, în mod succint, la întrebarea: “Care e motivulperenitatii Sistemelor cu Baze de Date?”, perenitate care a facut obiectul pledoariei anterioare. Ne simtim obligati sa facem pentru început o precizare utila legata de acceptiatermenului de Sistem cu Baza de Date (SBD) si a-l separa de cel de Sistem de Gestiune aBazelor de Date (SGBD): - SBD – Sistem de Aplicatii având în centru o Colectie Structurata de Date de volum mare a carui continut e gestionat în mod direct de un SGBD, dar care pe lânga acesta implica prezenta si a altor componente specializate cum ar fi Interfetele Utilizator, Retelele de Comunicatie, Instrumente de Ingineria Programarii Asistata de Calculator (Computer-Aided Software Engineering - CASE) etc., dar si Personalul (Utilizatori Finali sau Intermediari) însarcinat cu conceperea, proiectarea, întretinerea si dezvoltarea sistemului - SGBD – Sistem specializat în Gestiunea nemijlocita a Colectiei de Date, activitate ce implica doua Functii Principale, cea de Definire si cea de Manipulare a Datelor (vezi functiile unui SGBD descrise în sectiunea 2.1.3) In mod ciudat, într-o sectiune consacrata acestui subiect, vom evita enumerarea aceloravantaje practice aduse de Sistemele cu Baze de Date, ca instrumente de organizare si control avolumelor mari de informatii ce se cer prelucrate în orice domeniu, avantaje care vor fiprezentate în sectiunea 2.3, pentru a ne putea concentra asupra aportului la nivel conceptual,sustinut si consacrat în plan teoretic si confirmat în cenusiul de zi de zi al utilizarii acestorsisteme. Este vorba de concepte si principii lansate de SBD, a caror paternitate le este unanimrecunoscuta si pe care se bazeaza longevitatea lor, dar care nu pot fi exprimate usor într-un„singur cuvânt”.Observatie Organizarea datelor într-o Baza de Date a adus, cu scurgerea timpului, în afara rezultatelor directe, si un câstig indirect, la început aproape neperceput. Aceasta activitate migaloasa de organizare a unui material imens de Fapte a format utilizatorului, indiferent de rolul jucat în Sistemul Informatic, o noua viziune asupra Informatiilor prelucrate. Întregul arsenal de tehnici si metode dezvoltat sub semnul Structuralismului si al Independentei maxime a fiecarei componente a sistemului a declansat resurse sinergetice în descoperirea de noi raporturi si conexiuni între obiectele extrase din realitatea privita ca sursa inepuizabila de informatii, din ce în ce mai complexe si mai rafinate. In acest continuu izvor de noi înfatisari ale aceleiasi prezente trebuie cautata si perenitatea preocuparilor, a interesului si a rezultatelor mereu înnoite obtinute în aproape o jumatate de veac de existenta a domeniului. Ne-a aparut ca foarte sugestiv pentru ideea pe care o avansam, experimentul facut de o echipa de ingineri, biologi si logicieni, condusi de cercetatorul M. McKay. S-a constatat ca inteligenta efectueaza permanent o filtrare a informatiei brute receptionate. Efectul e evident atât în zona constienta, cât si în cea subconstienta a activitatii cerebrale.
    • 20 Aportul Sitemelor cu Baze de DateEchipa de cercetatori a suprapus peste o miscare browniana doua retele reticulare deforme diferite obtinând imagini deosebite ale aceleiasi existente, imagini rezultate dinfiltrarea, stimulata de retea, dar operata de factorul uman (Fig. 1.2.1).Filtrarile operate au fost induse de structurile particulare prin care a fost privitaaceeasi realitate din care au fost separate detalii initial pierdute în multimea deevenimente dezordonate. + ⇒ Miscare Retea Miscare Browniana Circulara Centrifuga + ⇒ Miscare Retea Miscare Browniana Reticulara Circulara Fig. 1.2.1 Experimentul lui M. McKayOrganizarea informatiilor si datelor în modele si structuri permite, asemenea Retelelorde Filtrare, evidentierea unor Relatii esentiale existente în Colectiile cu care opereazautilizatorul, dar care ramân pentru el pierdute în multitudinea de evenimenteparticulare, supuse hazardului, daca nu i se ofera Instrumente adecvate de introspectie,de scrutare a Planurilor Secunde, generatoare de Legi de Organizare.Înarmate cu metode impuse de necesitatea rezolvarii cazurilor concrete, SBD nu s-ausfiit sa caute un raspuns la întrebari mari: “Poate Independenta sa fie o cale spre Unitate?”Intentionam sa aducem, pe tot parcursul acestei lucrari argumente în sprijinul Ideiloravansate. Personalizarea fiecarei componente a Sistemelor cu Baze de Date prinextinderea conceptului de Independenta va reprezenta punctul central din care vor luanastere argumentele promise.
    • Continutul Lucrarii 211.3 Continutul Lucrarii Lucrarea contine prezentarea conceptelor principale dezvoltate în activitatea depromovare a Sistemelor cu Baze de Date. Sunt referite totodata conceptele matematice care austat la baza notiunilor cu care opereaza Bazele de Date, în special cele referitoare la ModelulRelational. Aceasta cuprindere face expunerea mult mai accesibila si pentru specialistul care aîntrerupt contactul cu studiul teoretic. Este recomandata si specialistului în domenii conexe,care poate gasi interesante solutii ce-i prilejuiesc comparatii cu cele din domeniul propriu deinteres si totodata îl îndeamna sa vada unde anume conceptele prezentate, suficient decuprinzatoare, l-ar putea ajuta. Parcurgerea lucrarii este utila atât pentru studentul preocupat de studiul disciplinelor deprogramare a calculatoarelor, dar si pentru specialistii care activeaza în domeniul SistemelorInformatice si care pot gasi în lucrare suficiente solutii pentru probleme practice. Lucrarea abunda în ilustratii grafice bazate pe simboluri si formalisme careconcentreaza expunerea prin evitarea descrierilor extinse, greu de urmarit si totodata ofera unsuport bogat de exemple lamuritoare. Se insista de asemenea pe frecvente clasificari, însotite de definitii de termeni si notiuni,strict necesare pentru a putea discuta despre un domeniu dinamic de probleme în careelaboratorii de produse comerciale, ba chiar si Colectivele de Lucru în domeniulTerminologiei, fac cu greu fata necesitatilor de unificare. Lucrarea e structurata pe 7 Sectiuni principale, detaliate poate prea amanuntit peSubsectiuni. S-a preferat aceasta detaliere pentru a oferi cititorului, înca de la lecturaCuprinsului, o orientare în continutul lucrarii si de asemenea posibilitatea regasirii rapide aunui anume subiect. Situatia e ceruta si de faptul ca acelasi subiect este reluat în sectiunidiferite, apelându-se la forme diferite de prezentare si unghiuri diferite de vedere. Prezentarileintuitive alterneaza cu reluari riguros definite, care vin sa fixeze materialul initial, oferind obaza si pentru specialistul interesat în cercetarea domeniului. Aceste sectiuni de prezentare au ca axa de organizare Definitia Bazelor de Date la cares-a oprit autorul si care e prezentata înca în sectiunea 2.2. Sunt urmarite asadar elementele de Descriere a Structurilor de Date privite înindependenta lor fata de proceduri, alaturi de cele ale Limbajelor de Manipulare a Datelor încele doua forme de realizare, prin Navigare si prin Specificare. Pentru a completa cerinta impusa de prelucrarea Volumelor mari de Date sunt tratate însectiunea 6 problemele ridicate de Prelucrarile Tranzactionale, Refacerea Bazelor de Date încaz de incident si Controlul Accesului la Date. Acestor subiecte li se adauga o prezentare finala concentrata asupra viitorului dedezvoltarea a Sistemelor cu Baze de Date. Materialul e completat cu prezentari de informare documentara reunite în câtevasectiuni de Anexa. O Lista de Figuri si Tabele, precum si un Index de Termeni asigura, alaturide cuprinsul detaliat, instrumente de consultare punctuala rapida a întregului material continutîn lucrare.
    • 22 Continutul LucrariiIn cele ce urmeaza se prezinta continutul celor sapte sectiuni principale ale lucrarii. - Sectiunea 1 – IntroducereSe scoate în evidenta interesul unuia din cele mai raspândite domenii de preocupare înprelucrarea automata a datelor, cel al Sistemelor cu Baze de Date. Este subliniataimportanta cunoasterii rezultatelor obtinute în aceasta sfera de preocupari, cât si ainstrumentelor puse la dispozitia utilizatorilor. - Sectiunea 2 – Sisteme cu Baze de DateSectiunea îsi propune sa prezinte personalitatea Sistemelor cu Baze de Date, ca mijloacespecifice de abordare a problemelor de conceptie, proiectare si implementare asistemelor cuprinzatoare de prelucrare a informatiilor si datelor.Un istoric al aparitiei si consolidarii conceptelor, atât de specifice domeniului, econsiderata necesara în aceasta parte a lucrarii. Se initiaza prezentarea conceptuluiconsiderat fundamental pentru Sistemele cu Baze de Date si anume IndependentaStructurala. Multiplele forme de aparitie ale acestei proprietati definitorii a structurilorde tip Baza de Date, vor contribui în sectiunile ce urmeaza la nuantarea conceptului.Pornind de la Independenta Structurala se sintetizeaza o definitie a Bazelor de Date,supuse de-a-lungul evolutiei lor la multe interpretari si chiar denaturari. Aceastadefinitie este apoi urmarita pe tot parcursul lucrarii, prin acumularea de caracteristici sidirectii de preocupari, toate venind sa încarce cu continut formularea initiala foarteconcentrata.Enumerarea avantajelor principale pe care le aduce viziunea de Sistem cu Baza de Date,întaresc conturul domeniului. Ca exemplu, se prezinta succint Baza de Date care adeschis preocuparile legate de separarea datelor de proceduri si anume PrelucrareaStructurilor de tip Nomenclator. - Sectiunea 3 – Concepte de BazaPrezentarea Conceptelor de Baza este grupata în jurul notiunilor de Multimi si Relatii.Acestea vor contribui mai târziu la construirea Modelului Formal al Structurilor deInformatii si Date, ce va fi utilizat ca model de referinta pentru toti termenii introdusiulterior. Am considerat foarte utila aceasta formalizare întrucât ea evita confuziile într-un domeniu ce sufera de o inflatie terminologica.Aceeasi idee ne-a condus si în cazul prezentarii raporturilor Informatie – Data, a carorcircumscriere într-o acceptiune adecvata demersului lucrarii, am considerat-o foarteutila pentru operarea cu termenii Structurilor de Informatii si Date. Antinomia Date –Proceduri vine sa adânceasca cutele de expresie ale produselor cu pretentii de Baze deDate. Este reluata ideea structuralista a Programarii Structurate, prezentata în paralel cuStructura atasata, dar separata a Datelor, la care însa se adauga viziunea Functionalaintrodusa de Virtualizarea Datelor, atât de proprie Bazelor de Date si care reapropieProcedurile de Date.Toate conceptele prezentate sunt în continuare utilizate si particularizate în prezentareaStructurilor de Informatii si Date. Se începe cu prezentarea conceptelor de Organizare,Structura si Acces, cu insistenta asupra acceptiunilor în definirea nivelelor Logic – Fizicîn reprezentarea datelor.
    • Continutul Lucrarii 23Se consacra un capitol al acestei sectiuni pentru motivarea importantei recunoasteriiStructurilor Fundamentale pentru analiza si sinteza structurilor complexe, dar si pentrucompararea diferitelor Modele de Date ale SGBD-urilor, pentru evaluareaperformantelor si a perspectivelor lor de evolutie. Problema Structurilor Fundamentalee reluata în lucrare ori de câte ori se face o trecere în revista a constructorilor destructuri, punându-se accentul cuvenit asupra faptului ca orice Model de Date esteatunci stapânit când se cunosc formele de implementare a cestor tipuri de structuri dedate.Metodele de reprezentare, în special cele ce apeleaza la conciziunea grafica, gasesc unspatiu suficient în capitolul care urmeaza si creeaza o baza pentru întelegerea usoara aexemplelor redate în lucrare. Fara o parcurgere atenta a conventiilor propuse, conventiiîn marea majoritate întâlnite în literatura de specialitate (cu exceptia Arborelui deStructura a Datelor) interpretarea exemplelor foarte numeroase din lucrare va întâmpinadificultati.Aplicarea conceptelor cu care s-a început sectiunea continua cu transpunerea lor înslujba disciplinarii gândirii celor care opereaza cu structurile în spatiul problemelorreale. Rafinarile necesare care se cer aduse prezentarilor Structurilor Fundamentaleîncheie aceasta sectiune. Viziuni ale unor producatori de notorietate în domeniulconstruirii Modelelor de Date sunt aduse la cunostinta prin intermediul produselorORACLE si ERWIN. - Sectiunea 4 – Modele de Informatii si DateSectiune vasta, întrucât îsi propune sa sustina ideea ca viitorul construirii SistemelorInformatice îl reprezinta metodele conceptuale, reprezentative, care dau prioritateabordarii de tip Top - Down (realizare de Sus în Jos), pe care nu uita sa o combine cudezvoltarile analitice, cumulative, de tip Bottom - Up (realizare de Jos în Sus).Procesele de Engineering (Generare automata Proiect din Model) si Reengineering(Completare Model cu detalii din Proiect), atât de familiare deja Bazelor de Date, stauchezasie pentru aplicarea acestei metode de lucru în mod industrial.In aceasta tratare Procedurile urmeaza sa migreze în Modelul de Informatii sau Date,care va deveni instrumentul esential pentru aducerea viziunii asupra problemei realeîntr-un singur punct, cel de reprezentare globala a realitatii de modelat. Când s-a reusitaceasta concentrare, reprezentarea câstiga o deosebita putere generativa pentru întregproiectul ce urmeaza sa prinda viata. Vor germina în mod natural Structuri de Date,Restrictii impuse, Proceduri asociate, Reguli de Comportament, Interfete de colaborarecu Utilizatorul, pe scurt tot ce urmeaza a se naste în sistem chiar fara a fi prevazuteanume în Specificatiile Initiale.Acest deziderat a determinat regruparea în aceasta sectiune atât a problemelorconceptuale, desfasurate în Spatiul Informatiilor, cât si a celor de proiectare, dezvoltateîn Spatiul Datelor. Sunt reunite de asemenea descrierile Structurilor de Date (propriiLimbajelor de Descriere a Datelor – LDD) împreuna cu descrierile de Proceduriasociate (proprii Limbajelor de Manipulare a Datelor – LMD).Sectiunea e împartita în doua parti consacrate Modelelor de Informatii si Modelelor deDate. Se regasesc aici exemplificate cele doua acceptiuni date anterior Informatiei capurtatoare a încarcaturii semantice conferite de utilizator Spatiului Modelat (Spatiul
    • 24 Continutul LucrariiInformatiilor) si Datei ca forma de reprezentare a Modelului în consonanta cuinstrumentul de prelucrare folosit (Sistemul de Calcul).Modelele de Informatii îsi încep prezentarea cu primul model de nivel înalt (fundamenatde colectivul profesorului Abrial), Modelul ECV (Entitate, Caracteristica, Valoare),continua cu Modelul Obiectelor Abstracte (fundamentat de lucrarile de cercetare alesotilor Smith) si se încheie cu un model propus de autor, Modelul Conceptual.Primul model contine definirea notiunilor de baza cu care continua sa opereze toatecelelalte modele dezvoltate: Entitate, Caracteristica, Valoare, Ansamblu de Entitati,Baza de Date Logica, Baza de Date Fizica. Este prezentat aici si un model formal dedescriere a unui Spatiu de Informatii prin stabilirea corespondentelor între termeniimodelului ECV si notiunile din Teoria Multimilor.Al doilea model introduce notiunile generale de Abstractizare, Generalizare, Agregare,Obiecte Abstracte, Operatii Abstracte, Integritate a Obiectelor Individuale etc. Proiectialor într-o reprezentare relationala asigura legatura cu nota generala de aplicabilitate atuturor conceptelor prezentate.In ultimul model se încerca o generalizare a conceptelor anterioare într-o solutie noua,care alege ca si constructor unic Conceptul în forma lui de prezentare în Logica. Suntdiscutate problemele de Identificare si de Derivare a Conceptelor.Modelele de Date sunt tratate într-o sectiune care reuneste teme foarte diverse, de laTipurile de SGBD-uri, la Componentele diverselor Nivele de Abstractizare, de laTipurile de Structuri de Date la modurile de Procesare a Datelor. Aceasta sectiuneformeaza de altfel si centrul lucrarii prin problemele pe care le dezbate si prin solutiilepe care le ofera.Aici este cuprinsa si descrierea Modelului Relational, pe care prezenta lucrare îl vede cao solutie de neînlocuit în reprezentarea structurilor de date si în viitor, cel putin la unnivel intern, apropiat de calculator si netransparent pentru utilizator. Utilizatorul vapastra astfel posibilitatea alegerii unor viziuni agreate de reprezentare, a carorconsistenta conceptuala va fi garantata de posibilitatea proiectiei lor în Modelul InternRelational.Sectiunea debuteaza cu încadrarea Modelelor de Date utilizate de SGBD-uri încontextul general de modelare a structurilor. Modelele Stricte de Date sunt apoiprezentate în formele lor istorice de evolutie: Ierarhic, Retea si Relational, încercându-se o marcare a acumularilor realizate pe linia descrierii structurale.Întrucât atentia ramâne concentrata pe Modelul Relational, dezvoltarea facilitatiloroferite de el au ramas grupate în subsectiunile adiacente, ceea ce a încarcat indentareacapitolelor. S-a urmarit ca prezentarea sa fie organizata pe cele trei componente ale unuiModel Strict de Date: Structura, Restrictii, Operatii.Problemei Identificarii, Accesului si Ordonarii îi sunt consacrate dezbateri interesante înpartea de descriere a structurii.Alaturi de acestea o dezvoltare proprie a Tipurilor de Relatii în Structurile Relationalevin sa pregateasca terenul unor ample exemplificari de implementare a Proceselor deAbstractizare în Structuri Relationale precum si de aplicare a lor în practica deproiectare a Structurilor Relationale. O legatura fertila este astfel stabilita între
    • Continutul Lucrarii 25conceptele proiectarii în Modelul Obiectelor Abstracte si formele de implementare aacestor concepte în proiectarea Structurilor Relationale.Relatiile de tip Entitate, Legatura si Mixte sunt definite si utilizate apoi în construireaStructurilor Elementare a caror însusire va crea competenta viitorului proiectant deStructuri Relationale. Se creeaza acum baza pentru metodele de proiectare dezvoltate însectiunea 5.1.4, care vor asigura un înalt grad de Normalizare, fara apelul la algoritmiiconsacrati acestor activitati de Optimizare a Structurilor.Partea de descriere a Restrictiilor aduce detalii de realizare pentru clasificarile operate însectiunea 3.4.5. Sunt trecute în revista diferitele forme de încorporare a Conditiilor deValidare a Structurilor în Modelul de Date prin intermediul Constrângerilor, Triggerilorsi Procedurilor Stocate.Incursiunea în Limbajele de Manipulare a Datelor (Algebra Relationala - AR, StructureQuery Language - SQL si Query By Example - QBE, preced încadrarea acestor formede procesare în tipurile de limbaje, de Navigare, Specificare Operatoriala si SpecificarePredicativa.Nivelul extern este analizat prin prisma Independentei pe care acesta o prezinta fata deoperatiile care se efectueaza asupra structurii unei Baze de Date.Un set bogat de exemple de implementare a Structurilor Relationale de Baza încheiesectiunea, cu incursiuni în aplicarea Generalizarii si Agregarii, a construirii Structurilorde tip 1 – n si m – n, a descrierii Structurilor Ierarhice, a implementarii Datelor de tipMultime etc. - Sectiunea 5 – Optimizarea Modelelor de DateO sectiune aparte este rezervata problemei optimizarii Modelelor de Date. Divizata îndoua parti, sectiunea dezbate în prima parte conceptul de Normalizare a structurilor deDate, rezervând problema Optimizarii Cererilor pentru cea de a doua. Se observa si aicitratarea alternativa a Datelor si Procedurilor în ceea ce aduce particular fiecare elementîn problema optimizarii.O prezentare formalizata a Modelului Relational creeaza cadrul necesar dezbaterilorcentrate pe problema Dependentelor Functionale în structurile relationale. Noutateadezbaterii o constituie doua aspecte aparte asupra carora este concentrata atentia.Primul aspect este legat de încadrarea normalizarii structurilor în problematica mai largaa asigurarii Independentei Structurale, de data aceasta transferata la nivelul AtributelorDesciptoare ale Relatiilor.Al doilea aspect aduce în discutie alternativele conceptuale oferite pentru proiectareastructurilor consistente, vizavi de metodele pur analitice de optimizare „post festum” aunor structuri vicioase. Este aici interesant de urmarit demersul provocat de întrebarearetorica: ”De ce sa tratezi când poti simplu sa previi?”. Numeroase exemple ofera solutiipractice utile. - Sectiunea 6 – Securitatea Bazelor de DateAceasta sectiune vine sa raspunda ultimei parti a definitiei Bazei de Date avansata încaîn sectiunea 2. Prelucrarea Volumelor Mari aduc în atentie problema Securizarii Datelorprelucrate.
    • 26 Continutul LucrariiIn capitole dedicate sunt prezentate cele trei probleme importante legate de acest aspect.Prima tratare se refera la asigurarea Controlului Accesului la Date prin metodele clasicede interzicere a accesului neautorizat.Al doilea subiect concentreaza atentia asupra Prelucrarilor Tranzactionale în forma lorde implementare a restrictiilor ACID (Atomicitate, Consistenta, Izolare, D urabilitate).Si în acest caz nu se pierde ocazia de a încadra solutiile de rezolvare a StarilorConflictuale prin urmarirea asigurarii maximei Independente Procedurale aTranzactiilor.Problema Restaurarii Bazelor de Date în caz de incident este în final tratata în strânsalegatura cu prelucrarea tranzactionala. - Sectiunea 7 – Baze de Date EvoluateIn cadrul facilitatilor ce urmeaza a fi transferate catre Bazele de Date, cum ar fi cele deDeducere de Fapte, Distribuire de Resurse, Creare de Viziune Obiectuala sunt gasitenoi prilejuri de a privi sub alte aspecte problema Independentei Structurale.In cazul Bazelor de date Deductive problema Independentei reiese ca forma deMaterializare a Datelor prin functii de Calcul Logic, ceea ce readuce în discutieopozitia Redondanta – Inconsistenta. Se reitereaza importanta procesului deductiv nuatât sub aspectul evitarii redondantei, cât sub aspectul asigurarii consistentei, prinevitarea memorarii datelor dependente ca date ce pot fi aduse în contradictie prinactualizare independenta.In cazul Bazelor de Date Distribuite atentia e îndreptata catre problema IndependenteiSurselor de Date. Încalcarea unicitatii datelor din motive de performanta, prinacceptarea replicarii, determina construirea unor proceduri de sistem care sa transferecontrolul consistentei Bazelor de Date Distribuite din Structural în Procedural.In cazul Bazelor de Date Obiectuale problema Independentei e tratata mai amplu. Inprimul rând prin sublinirea structurii obiectuale ca forma de asigurare maxima aIndependentei elementelor sale, fie ele Date sau Proceduri.In al doilea rând se atrage atentia asupra pericolului pe care îl reprezinta implementareala nivel intern a structurilor obiectuale nenormalizate, prin eliminarea ModeluluiRelational.Acestui subiect îi este consacrat si capitolul de consideratii critice. Se acrediteaza dinnou ideea ca Viziunea Obiectuala, adaptata în general pozitiei Utilizatorului, nu trebuiesa constituie o solutie pentru construirea Nivelului Conceptual, ci o alternativa aNivelului Extern al unei Baze de Date, capabil în aceasta forma sa implementeze viziunimultiple asupra aceleiasi Structuri de Date. Si în acest caz sursa pentru Structura deDate a Obiectelor se recomanda a fi alcatuita din Vederile consacrate Structurilor deBaza de Date, împreuna cu tot arsenalul de Proceduri Stocate aferent.Consideram ca, în sprijinul ideilor avansate, vine întreaga evolutie prezenta ainterfetelor create pentru a avea acces la Sursele de Date din orice mediu (ClientSpecializat – Thick Client, Client Banal – Thin Client, Interfete Vocale, Interfete MassMedia etc.) utilizând Tehnologia Obiectelor Active.
    • Continutul Lucrarii 27PARTEA a 2 -a SISTEME cu BAZE de DATE Legate într-un fel de Partea Introductiva, sectiunile prezentei Parti initiaza cititorul neavizat în problematica Sistemelor cu Baze de Date (SBD). Sectiunile incluse pornesc de la o fundamentare istorica a preocuparilor în domeniu, definesc Conceptul de Baza de Date, consolidându-l cu exemple. 2.1 – Aparitia Conceptului de Baza de Date – o incursiune istorica în Prelucrarea Automata a Datelor subliniaza modul natural de aparitie a preocuparilor legate de cresterea performantelor calitative si cantitative în Prelucrarea Informatiilor si Datelor. 2.2 – Avantajele Utilizarii Bazelor de Date – sunt concretizate o suma de avantaje, în prezent indispensabile în conceperea si utilizarea Sistemelor Complexe, pe care le ofera abordarea acestora ca Sisteme cu Baze de Date. 2.3 – Exemple de Baze de Date – se prezinta Structura primului Sis tem cu Baze de Date, a carui actualitate se mentine si în prezent prin modul de Proiectare si prin Avantajele finale oferite..
    • 28 Nivele de Abstractizare într-un SBD2 Sisteme cu Baze de Date Ca orice concept care si-a câstigat o anume popularitate, si cel al Bazelor de Date nueste unul de trecut cu vederea din aceasta privinta, cel cu care ne vom ocupa în continuare nu ascapat de alterare pâna la chiar golirea de continut. Desi credem ca orice sechestrare aconceptului de BD de catre o singura categorie de utilizatori, fie ea chiar reprezentata decercetatori în domeniul dependentelor operatoriale abstracte, este neavenita, dorim sa limitamacceptiunea termenului prin circumscrierea domeniului care a putut sa reziste atâta timp înlumea diversa a teoreticienilor, comerciantilor si utilizatorilor.2.1 Aparitia Conceptului de Baza de Date In paginile care urmeaza vom încerca sa parcurgem pe scurt un istoric de aparitie anecesitatii de abordare a prelucrarii datelor de volum din ce în ce mai mare, care a determinatfundamentarea acelor concepte care au stat la radacina Sistemelor cu Baze de Date. Existadesigur destule voci care sustin ca nu e nevoie sa acordam o asa atentie trecutului si sa neconcentram mai mult asupra cerintelor prezentului. Raspunsul nostru consta în faptul caprezenta lucrare îsi propune sa se ocupe mai mult de viitor si de aceea rememorarea drumuluiparcurs de SBD, deloc neglijabil în timp, este o chezasie a presupunerilor corecte de evolutie înviitor a acestor sisteme. Nu putem însa omite nici aportul pe care întelegerea corecta a noutatiiconceptelor promovate de SBD o are la utilizarea lor în prezent. Ne referim în special larecuperarea importantei pe care Sursele de Date, construite solid, o au în prezent si o vor aveaîn viitor pe tarâmul prelucrarii de informatii.2.1.1 Nivele de Abstractizare într-un SBD Aparitia Bazelor de Date a fost o urmare fireasca a dezvoltarii tehnologiilor în procesulde prelucrare a datelor. Aceste transformari pot fi urmarite sub doua aspecte: o sub aspect cantitativ – ca o crestere a numarului datelor ce urmau a fi prelucrate automat; colectii de date incluzând milioane de date care se cereau memorate, actualizate, regasite, calculate si transmise cu ajutorul dispozitivelor automate de calcul (calculatoare si retele de interconectare) o sub aspect calitativ – ca o crestere a complexitatii structurii datelor prelucrate atât în ceea ce privea relatiile descrise între date, cât si a distribuirii datelor, puternic legate prin intercorelare, pe diferitele medii de stocare Trei etape pot fi semnalate în procesul de evolutie prezentat anterior: o Prima etapa – Separarea Numelor de Valorile datelor o A doua etapa – Cresterea Complexitatii datelor prelucrate o A treia etapa - Separarea Datelor de Proceduri Separarea Numelor de Valorile datelor determina aparitia a doua nivele de descriere aacestora: o Un nivel Concret de descriere – descriere cu ajutorul Valorilor numit nivel Fizic de descriere (descriere de Instanta)
    • Nivele de Abstractizare într-un SBD 29 o Un nivel Abstract de descriere – descriere cu ajutorul Numelor numit nivel Logic de descriere (descriere de Notiune) Prezenta nivelului abstract de descriere a datelor va facilita: o Gruparea (separarea) descrierii datelor într-o sectiune specializata numita Dictionarul datelor o Definirea sistematica a Tipurilor de Date (prin generalizarea Datelor de acelasi Tip) o Asocierea Restrictiilor impuse la Datele de acelasi Tip o Asocierea Operatiilor adecvate diverselor Tipuri de Date Toate aceste noutati aduse descrierii structurilor de date reprezinta primul pas importantîn definirea Bazelor de Date, ca metode de prelucrare care centreaza atentia asupra obiectuluiprelucrarii - Datele. In ceea ce priveste cresterea complexitatii structurii datelor ea poate fi analizata îndirecta legatura cu raportul între cele doua componente ale procesului de prelucrare automata adatelor: § Date ce descriu Starile (Structura) § Calcule asupra datelor, ce descriu Operatiile (Transformarile) Trei perioade distincte pot fi sesizate în evolutia conceptiei de prelucrare a datelor cuajutorul sistemelor de calcul: o Prima perioada – descrisa prin Date Simple si Calcule Complexe Datele simple sunt considerate date de volum mic, nestructurate, prezentate sub forma de scalari sau multimi simple si statice de scalari (vectori, matrici) utilizate pentru calcule stiintifice reprezentate de proceduri si functii care implementeaza instrumente matematice de calcul complex (calcule numerice, statistice, vectoriale, matriciale etc.). Acestea sunt reunite în biblioteci specializate de proceduri si functii ce pot fi cu usurinta apelate din diverse programe orientate spre rezolvarea unor probleme cu caracter particular. Cel mai reprezentativ limbaj de prelucrare utilizat în aceasta perioada este limbajul FORTRAN. o A doua perioada - descrisa prin Date Complexe si Calcule Simple Datele complexe sunt constituite din date de volum mare, structurate prin gruparea lor în înregistrari de lungimi fixe sau variabile si multimi de înregistrari corelate între ele. Aceste date sunt utilizate în aceasta etapa preponderent pentru calcule economice simple (adunari si scaderi). Este descoperita acum importanta regasirii datelor, prin localizarea lor în ansamblul structurat. Cel mai reprezentativ limbaj de prelucrare utilizat în aceasta perioada este limbajul COBOL. o A treia perioada - descrisa prin Date Complexe si Calcule Complexe In aceasta perioada datelor complexe li se adauga functii complexe grupate în biblioteci extinse. Functiile sunt specializate pentru prelucrarea diferitelor tipuri si
    • 30 Nivele de Abstractizare într-un SBD structuri de date, de la datele de tip numeric, caracter sau sir de caractere, pâna la date de tip înregistrare, tablouri de înregistrari, liste, arbori, stive, cozi, indecsi etc. Atunci când volumul de date de prelucrate este redus, structurile prelucrate pot fi încarcate în memoria interna si transferul din si în memoria externa se efectueaza printr-o citire initiala, respectiv o scriere finala. Cel mai reprezentativ limbaj de prelucrare utilizat în acest caz este limbajul PASCAL. Prin cresterea volumului de date, structurile de date trebuiesc retinute în memoria externa si comunicarea cu memoria interna se efectueaza exclusiv prin operatii de regasire a fragmentelor de structura care se cer consultate sau actualizate. Cele mai reprezentative limbaje de prelucrare care îndeplinesc aceste cerinte sunt Limbajele de Descriere (LDD) si de Manipulare (LMD) a Datelor din Sistemele de Gestiune a Bazelor de Date (SGBD). Asa dupa cum s-a mentionat anterior, a treia etapa în evolutia procesului de prelucrareautomata aduce ca noutate necesitatea Separarii Datelor de Proceduri. Acest dezideratreprezinta pasul cel mai important pentru conturarea specificului viitoarelor Sisteme cu Bazede Date. Complexitatea sporita a datelor prelucrate ridica pretentii noi în actualizarea permanentaa structurilor de date, atât în definirea initiala a acestora prin actualizarea nivelului logic dedescriere a datelor, cât si în extinderea, modificarea sau eliminarea instantelor concretereprezentate prin valorile memorate în nivelul fizic de descriere a datelor. Toate acestemodificari frecvente solicitau actualizarea simultana a procedurilor asociate structurilor dedate, în cazul în care aceste proceduri includeau descrierea datelor. Pentru solutionarea acesteidificultati a fost necesara în prima etapa introducerea unei fragmentari în tratarea ansambluluicomplex de colectii de date, prin introducerea conceptului de Nivele de Abstractizare înreprezentarea structurii datelor într-o Baza de Date. J. D. Ullman descrie în [ULMA80] treiNivele de Abstractizare într-un Sistem cu Baza de Date (SBD). Acestea sunt sugestivreprezentate în Fig. 2.1.1. La nivelul interior de abstractizare, denumit si Nivel Intern, este reprezentata Baza deDate Fizica, care e stocata întotdeauna pe suportul extern de memorare, datorita volumului dedate ce necesita un spatiu mare de depozitare. Ea consta din: o Setul de Valori de Date care sunt memorate pe suportul extern conform conventiilor de reprezentare adoptate de Sistemul de Gestiune al Bazei de Date, în acord cu sistemul de operare pe care acesta e implementat. Aceste conventii includ metodele de organizare si acces la date, conventiile de codificare si compresie a datelor etc. o Setul Informatiilor de Control asociate informatiilor utile stocate în Baza de Date. Aceste informatii suplimentare sunt determinate de tehnicile adoptate pentru gestiunea suportului fizic In centrul reprezentarii se regaseste Nivelul Conceptual în forma Bazei de DateLogice, care grupeaza elementele ce descriu Datele cu ajutorul Numelor si anume: o Modelul de Descriere a Datelor care poate fi: § Ierarhic
    • Nivele de Abstractizare într-un SBD 31 § Retea § Relational o Setul de Caracteristici de descriere: § Nume § Tipuri § Limite de Valori o Limbajul de Descriere a Datelor ( LDD) Baza de Date Logica contine Schema de Descriere a Datelor. Cel de al treilea nivel de abstractizare este reprezentat de Nivelul Extern. Acest niveleste construit cu ajutorul a doua concepte: Vederea si Data Virtuala. Acest nivel va contine: o O multime de Vederi incluzând parti din datele descrise în Baza de Date Logica si memorate în Baza de Date Fizica o O multime de Date Virtuale care extind informatiile ce pot fi regasite în Baza de Date ca date memorate. Datele efectiv memorate în Baza de Date (cea Logica si cea Fizica) sunt denumite Date Reale. Datele Virtuale sunt date ce pot fi obtinute pe baza Datelor Reale prin aplicarea unei Functii de Calcul de forma: VD = f ( RD ) Procesul prin care, pornind de la un set de Date Reale tratate ca Argumente, se determina o Valoare de Data Virtuala (se instantiaza o Data Virtuala) poarta numele de Materializarea Datelor Se remarca faptul ca asupra naturii Functiei de Calcul nu este impusa nici-o restrictie. Ea poate implica un Calcul Aritmetic, Logic, pe Siruri de Caractere etc.Exemplu: Intr-o Baza de Date PERSOANE: o Data Nasterii e memorata într-o Data Reala cu numele DN o Daca Vârsta, VR, e tratata ca o Data Virtuala, ea nu va fi memorata în Baza de Date ca valoare reala, ci va apare doar într-o Vedere la nivelul extern, fiind definita printr-o Expresie de Calcul redactata ca o functie: VR = f (DN) = DC – DN unde: § DC este Data Curenta furnizata de sistem § DN este Data Nasterii memorata în Baza de Date. Se observa usor ca ori de câte ori o Data poate fi exprimata ca fiind dependenta de altedate memorate în sistem, consistenta ansamblului de date nu poate fi mentinuta decât prinrecalcularea automata a valorii dependente în functie de valorile momentane ale valorilorindependente (argumentele functiei de calcul). În exemplul nostru Vârsta (variabiladependenta) va putea fi exprimata în orice moment cu precizia dorita, prin referirea la valoareaDatei curente (argument) care se modifica permanent.
    • 32 Nivele de Abstractizare într-un SBD U1 U2 vedere 1 U3 U4 vedere 2 U5 BAZA de DATE BAZA de DATE LOGICA FIZICA vedere 3 U6 U7 vedere n Un nivel nivel nivel EXTERN CONCEPTUAL INTERN (LOGIC) (FIZIC) INTERFATA INTERFATA LOGICA FIZICA Fig. 2.1.1 Nivele de Abstractizare într-o Baza de Date La nivel Extern, prin intermediul conceptului de Vedere, poate fi schimbat si Modelulde reprezentare a Structurii de Date. Spre exemplu, la nivel Conceptual se poate utiliza odescriere în termenii unui model Relational de date, în timp ce la nivel Extern poate fi utilizatun model Ierarhic, Retea sau Obiectual (si viceversa). Viziunea Sistemelor cu Baze de Date ca o succesiune de Nivele de Abstractizareconduce la recunoasterea a doua Interfete de legatura între nivele: o Interfata Fizica – care asigura Imunitatea Fizica a Datelor definita de stabilitatea Nivelului Conceptual la modificari operate în Nivelul Fizic
    • Nivele de Abstractizare într-un SBD 33 o Interfata Logica - care asigura Imunitatea Logica a Datelor definita de stabilitatea Nivelului Extern la modificari operate în Nivelul Logic Ambele Interfete permit, prin intermediul protectiilor pe care le asigura, construireadiferitelor nivele de Independenta în structurarea datelor. In final, deoarece Vederile definite în nivelul Extern vor fi încorporate în Procedurilediverselor aplicatii, nivelele de abstractizare prezentate vor asigura Imunitatea Procedurilor,definita de stabilitatea Procedurilor la modificarile operate în cele doua nivele de descriere aStructurii Datelor (cel Logic si cel Fizic). Aceasta forma finala de imunitate poarta numele deIndependenta a Datelor fata de Proceduri. Când trebuie sa se verifice fara întârziere daca un produs software îndeplinesteconditiile unui Sistem de Gestiune a Bazelor de Date (SGBD), e suficient sa se verifice gradulîn care acel produs asigura Independenta între Date si Proceduri.2.1.2 Functiile unui SGBD Toate Sistemele de Gestiune a Bazelor de Date (SGBD) asigura trei functii principale: o Functia de Definire a Datelor – care asigura declararea elementelor care compun Structura de Date precum si a Relatiilor existente între ele o Functia de Manipulare a Datelor – care regrupeaza Operatiile de Intrare / Iesire, care asigura Adaugarea, Stergerea si Modificarea Valorilor Datelor memorate în Baza de Date o Functia de Utilizare a Datelor – care permite construirea Sistemului de Aplicatii ce prelucreaza datele continute în Baza de Date; aceasta functie e asigurata de Mediul de Programare asociat Nivelului de Acces la Baza de Date Exista si alte functii pe care un SGBD trebuie sa le asigure pentru gestionareaColectiilor Mari de Date: o Functia de Control a Accesului la Date – care include metodele de acordare si revocare Drepturilor de Acces la Date (câmpuri, tabele, fisiere, domenii, operatii de actualizare) o Functia de asigurare a Integritatii Datelor – care ofera posibilitatea de declarare a Restrictiilor impuse structurii de date (Unicitate, Referire, Compatibilitate etc.) o Functia de asigurare a Accesului Concurent la Date – care grupeaza operatiile de Blocare / Deblocare a accesului simultan la date o Functia de Salvare / Restaurare a Datelor – ce asigura crearea si folosirea Copiilor de Securitate în caz de incidente o Functia de Acces Tranzactional la Date – ce ofera facilitatea de grupare a operatiilor de actualizare în Unitati Atomice de Executie (Tranzactii), care se pot efectua doar integral sau refuza integral Mediile de Programare care implementeaza Accesul la Baza de Date aduc si ele noiFunctii specializate, care sunt incluse tot în Functia de Utilizare a Datelor.
    • 34 Raportul Date - Proceduri2.1.3 Raportul Date - Proceduri Datele si Procedurile reprezinta Elementele de Baza ale oricarei prelucrari de date.Aspectele ridicate de aceasta constatare sunt pe larg explicate în lucrarea de referinta[WIRT76]. Datele reprezinta în procesul de prelucrare elementul static, descriind la un moment datStarea în care se afla sistemul de prelucrare, în timp ce Procedurile reprezinta elementuldinamic, ce defineste Transformarea între doua stari succesive. In timp ce datele descriuStructura Sistemului, procedurile descriu Secventele de Operatii care modifica în timp stareasistemului. Cu cât aceste elemente sunt mai precis delimitate, cu atât sistemul este mai: o Adaptabil - întelegând prin aceasta capacitatea sa de a suporta modificari intervenite în definirea initiala a cerintelor si totodata deschiderea la dezvoltari ulterioare o Controlabil - prin posibilitatile oferite pentru verificarea modului sau de functionare în vederea corectarii sale, precum si a îmbunatatirii performantelor Evolutia procesarii datelor în prelucrarea automata este strâns legata de evolutiaraporturilor existente între aceste doua elemente fundamentale. Trei etape pot fi delimitate în evolutia raportului între Date si Proceduri în cadrulprelucrarii automate a datelor: o Prima etapa - este caracterizata de importanta predominanta acordata Procedurilor, prin descoperirea aportului calculului automat la urgentarea procesarii. Procedurile înghit datele în corpul lor îmbracând forma unei Cutii Negre, ce are precizate spre exterior doar Datele de Intrare si Datele de Iesire ca rezultate ale prelucrarii o A doua etapa - este caracterizata de revolutia provocata de Eliberarea Datelor de sub dominanta Procedurilor. Prin câstigarea Independentei lor fata de proceduri, datele încep sa fie personalizate din ce în ce mai mult prin descoperirea importantei de definire a Tipurilor de Data, precum si a Conditiilor pe care trebuie sa le respecte fiecare Tip si Instantiere de Tip (Limite de Valori, Restrictii de Identitate si de Referire, Restrictii de Dependenta Functionala, Restrictii de Consistenta, Restrictii de Validare a Corectitudinii si Compatibilitatii). Datele sunt deja capabile sa se organizeze în Structuri din ce în ce mai complexe, care contin înca înainte de procesare o încarcatura semantica din ce în ce mai mare. Ele nu mai deservesc trecator un singur proces de prelucrare, ci constituie Rezervorul de Informatii al întregului sistem, pe toata durata lui de viata. Fiind independente, datele pot fi preocupate în mod sporit de dezvoltarea si rafinarea modului de a-si Descrie Structura. Independenta dobândita fata de proceduri se manifesta prin Separarea Numelor de Valorile Datelor punându-se astfel bazele aparitiei Nivelelor de descriere Logica (prin Nume) si Fizica (prin Valori). Datele se vor refugia în Nivelele
    • Raportul Date – Proceduri 35 proprii de definire (Conceptual si Intern). De asemenea starea de autonomie ofera datelor posibilitatea de a fi modificate cu tot mai multa usurinta, chiar si în timpul functionarii sistemului, prin compensatia pe care o ofera procedurilor de a deveni imune la modificarile operate în cercul datelor. Consolidate într-un mediu cu reguli proprii de organizare, constiente de aportul lor foarte precis definit în prelucrarea informatiilor, datele pornesc sa exercite o atractie irezistibila asupra procedurilor în privinta preluarii conceptelor de structuralism. Sunt stimulate organizarile pe Module, care transpun în cadrul fragmentelor de proceduri principiile de independenta reciproca, si odata cu acestea cresc adaptabilitatea si controlabilitatea procedurilor complexe. Acum Procedurile încep sa înteleaga ca separându-se tot mai mult fata de datele pe care le prelucreaza îsi pot multiplica utilitatea prin autonomia care le-o confera Reentranta. In acest sens însa descoperirea cea mai mare care se produce este cea de a putea asimila cu o Data Potentiala orice Procedura, care este privita functional, ca o expresie de dependenta între datele de intrare si de iesire. Acest concept este repede asimilat de Date, care adopta noii constructori de structuri, le boteaza Date Virtuale, si le acorda îndata misiuni precise de a reduce Redondanta si a spori Consistenta informatiilor memorate cu ajutorul Datelor Reale (datele efectiv înregistrate pe suportul fizic). Se pun astfel bazele proceselor de Materializare a Datelor, prin definirea în cadrul structurilor a unor noi tipuri de date (Datele Virtuale), care se instantiaza doar în momentul apelului, prin executia procedurilor de calcul atasate. Cu aceasta noua achizitie se construieste un nou nivel de interfata între Utilizator si Structurile de Date, si anume Nivelul Extern, care adaugat la nivelele anterioare, cel Conceptual si cel Intern, definitiveaza independenta initiata în cadrul modelelor structurate de date ( vezi Fig. 2.1.1). o A treia etapa - este caracterizata de reîntâlnirea datelor cu procedurile în corpul Obiectelor, care respecta drepturile la definirea independenta si transanta a Structurilor si Operatiilor, dar le reuneste prin comunitatea sarcinilor pe care sunt chemate sa le îndeplineasca împreuna, aceea de a da nastere la o noua entitate, nu numai cu Structura Specifica, ci si cu un Comportament Individualizat (capacitati de mostenire si de transmitere a însusirilor, de receptie si interpretare a mesajelor, de executie a comenzilor primite prin mesaje etc.). Reîntâlnirea se produce deci sub semnul definitiei facuta în lucrarea [WIRT76] mai susamintita : “ Un Tip de Data este o Structura + Operatorii acceptati. “ Noutatea adusa de Bazele de Date consta în Virtualizarea Datelor, care determinaunificarea Datelor cu Procedurile prin înglobarea modificarilor potentiale de stari în structurasistemului. Procedurile Stocate orientate pe Eveniment asigura acest lucru. Se realizeaza astfel o concentrare a cunostintelor asupra Sistemului ce urmeaza a fiproiectat în asa numitul Model de Date, cu o mare putere de generare a diverselor componentece vor alcatui sistemul.
    • 36 Definitia Bazelor de Date2.2 Definitia Bazelor de Date In literatura de specialitate se gaseste o diversitate de definitii ale Bazelor de Date. Vomprezenta în continuare o definitie bazata pe caracteristicile desprinse din prezentarile facute însectiunile anterioare. Am ales aceasta definire datorita preciziei si conciziunii sale. O Baza de Date este o Colectie Memorata de Date, variabila în timp, avândurmatoarele caracteristici: o Asigura Independenta Datelor prin: § Prezenta Schemei de Date (cel mai adesea si a Subschemelor de Date) precum si a Limbajului de Definire a Datelor (LDD), asociat Schemelor de Date o Asigura Accesul (cel mai adesea Multiaccesul) la Colectii Mari de Date prin: § Prezenta Nivelul Fizic de Acces la Date precum si a Limbajului de Manipulare a Datelor (LMD) § Asigurarea functiilor de Securitate a Datelor prin: • Controlul Accesului la Date • Restaurarea Colectiilor de Date în caz de incident Am încercat sa sintetizam în definitia prezentata acele caracteristici pe care leconsideram strict necesare pentru recunoasterea calitatilor de Baza de Date pentru o Colectiede Date, ca si pentru un Produs Comercial care gestioneaza aceste colectii. Gasim aici grupateurmatoarele caracteristici: - Precizarea Independentei Datelor ca si însusire principala a oricarui produs din categoria SGBD. Asa dupa cum se va vedea pe parcursul lucrarii, proprietatea de Independenta va fi promovata de conceptele Bazelor de Date si în alte raporturi decât cele de Date – Proceduri. O vom regasi între Structura – Ordine, Valoare – Suport, Atribute Descriptoare, Tranzactii, etc. Sectiuni numeroase din lucrare vor sustine interesul pe care SBD îl acorda definirii, întretinerii si perfectionarii Structurilor de Date privite sub aspectul Independentei lor - Precizarea importantei Gestiunii Datelor prin Limbaje Specializate. Sunt prezentate, categoriile de Limbaje de Navigare, de Specificare Operatoriala si de Specificare Predicativa. O sectiune speciala este destinata problemelor ridicate de Prelucrarile Tranzactionale - Legata de Gestiunea Datelor de Volum Mare, este cuprinsa în lucrare si o sectiune care trateaza problema Securitatii Datelor. Doua subiecte sunt dezvoltate aici: unul ce dezvolta problema ampla a Subsistemelor de Salvare / Restaurare si celalalt consacrat Controlului Accesului la Bazele de Date Se observa ca, exceptând sectiunea finala care este orientata spre caile de dezvoltare înviitor a Sistemelor cu Baze de Date, restul sectiunilor sunt axate pe componentele Definitieiadoptate pentru Baza de Date. Ca urmare, toate informatiile prezentate vin sa argumentezeacele caracteristici ce au fost alese ca definitorii pentru asemenea produse atât de variate castructura si ca utilizare.
    • Avantajele Utilizarii Bazelor de Date 372.3 Avantajele utilizarii Bazelor de Date Din numeroasele avantaje ale Sistemelor cu Baze de Date, avantaje care au asiguratperenitatea acestor sisteme, le enumeram pe cele considerate cele mai importante: - Facilitatile oferite pentru Gestiunea Colectiilor Mari de Date § posibilitatile de definire a Structurilor Complexe de Date cu ajutorul unui Limbaj Unificat de Definire a Datelor ( LDD) § posibilitati multiple de regasire si actualizare a datelor din si în memoria externa prin intermediul unui Limbaj unificat de Manipulare a Datelor (LMD) - Scurtarea duratelor de proiectare si implementare a proiectelor complexe § asigurarea unei structuri deschise prin caracteristica de Independenta a datelor § oferirea unei mari flexibilitati de manevrare a structurilor de date prin mediile de programare disponibile în diferite tehnologii de prelucrare - Adaptabilitate la modificarea specificatiilor initiale § Independenta Datelor fata de Proceduri asigura Imunitatea Procedurilor § legaturile strânse cu produsele de Construire a Modelelor de Date permit Generare Automata a Structurilor Logice de Date - Facilitati de definire a Proiectelor Integrate § existenta unei Descrieri Unice de Structura cu functie de Dictionar de Date § existenta posibilitatilor de cuprindere în Baza de Date a sectiunii de definire a Restrictiilor Asociate Datelor § materializarea datelor prin Proceduri Orientate pe Eveniment si memorate tot în Baza de Date sub forma de Proceduri Declansate (Triggeri) - Controlul validitatii datelor § utilizarea conceptului de Integritate a Bazei de Date, asigurat prin Restrictiile de Integritate puse la dispozitia utilizatorului § posibilitati multiple de declarare a regulilor suplimentare de validare (Unicitate de Chei, Constrângeri,Triggeri, Proceduri Stocate) - Raspuns la Întrebari Neprevazute initial § posibilitatea adresarii de Cereri Instantanee Bazei de Date prin Limbaje Neprocedurale (SQL - Structure Query Language sau QBE - Query By Example) - Flexibilitate de adaptare la noile Tehnologii de Proiectare § construirea Surselor de Date accesibile de pe diferite platforme Hardware si Software § Îmbunatatirea dialogului Utilizator - Calculator § dezvoltarea Interfetelor Utilizator cu mare grad de interactivitate
    • 38 Exemple de Baze de Date2.4 Exemple de Baze de Date Dam ca exemplu de Baza de Date prima structura de date care, pornind de la cerintelepractice ridicate de industrie, a stimulat dezvoltarea conceptelor care au stat la baza domeniuluide prelucrare a colectiilor mari de date. Este vorba de Prelucrarea Nomenclatoarelor (List ofPart Processing). Provenind din domeniul constructiilor de masini, prelucrarea consta îndeterminarea necesarului de Repere componente într-un Ansamblu privit ca un ProdusCompus.Exemplu simbolic: Structura de Informatii descrie cantitatea q necesara dintr-un COMPONENT pentru a produce 1 bucata de COMPUS. In forma concentrata structura e reprezentata în Fig. 2.4.1. COMPUS q COMPONENT Fig. 2.4.1 Structura de informatii ce descrie componenta unui produsExemplu general: Un exemplu detaliat al structuri anterioare e redata în Fig. 2.4.2. unde: - A, B, .... sunt COMPUSI sau COMPONENTE -q este Cantitatea Necesara Doua colectii de date sunt folosite pentru a descrie structura de mai sus: - Colectia Principala continând Elementele A, B, .. - Colectia de Legatura ce descrie Legaturile AB q1 , BD q2 , .. Procedurile consacrate pentru prelucrarea structurile de genul celor prezentate sunt: - Explozie Detaliata – lista structurii COMPUS - COMPONENTE desfasurata pe nivele, sub forma: Compusul A are Componenta B în cantitatea q 1 Componenta C în cantitatea q 2 Compusul B are Componenta D în cantitatea q 3 Componenta E în cantitatea q 4 Compusul C are Componenta F în cantitatea q 5 Componenta E în cantitatea q 6 - Explozie Cumulata – lista necesarului cumulat de COMPONENTE pentru un nivel dat de COMPONENT sub forma:
    • Exemple de Baze de Date 39 Compusul A are Componenta B în cantitatea q 1 Componenta C în cantitatea q 2 Componenta D în cantitatea q 1 x q 3 Componenta E în cantitatea q 1 x q 4 + q 2 x q 6 Componenta F în cantitatea q 2 x q 5 A q2 q1 B C q3 q4 q5 q6 D E F E Fig. 2.4.2. Structura generala de informatii pentru componenta unui produs - Implozie – lista COMPUSILOR în care apare un COMPONENT dat sub forma: Componenta B apare în Compusul A în cantitatea q 1 Componenta C apare în Compusul A în cantitatea q 2 Componenta D apare în Compusul B în cantitatea q 3 Compusul A în cantitatea q 1 x q 3 Componenta E apare în Compusul B în cantitatea q 4 Compusul C în cantitatea q 6 Compusul A în cantitatea q 1 x q 4 + q 2 x q 6 Componenta F apare în Compusul C în cantitatea q 5 Compusul A în cantitatea q 2 x q 5Date de Intrare: o Informatii Tehnice si Tehnologice legate de structura produselor si de necesarul de materiale pentru fabricarea acestor produse o Informatii Comerciale asupra Comenzilor de Produse si Componente de ProduseDate de Iesire: o Lista Componentelor care se cer achizitionate sau fabricate pentru onorarea Comenzii o Lista Necesarului de Materiale necesare fabricarii produselor solicitate o Lista Modificarilor în listele anterioare, modificari generate de schimbarea continutului Comenzilor
    • 40 Exemple de Baze de Date o Lista Produselor afectate de un dis ponibil insuficient de ComponenteExemplu concret: Sa consideram structura de date care descrie componenta unei Retele de Calculatoare si care e reprezentata în detaliu în tabelul 2.4.3. RETEA de CALCULATOARE Componenta SERVER (1) STATII de LUCRU (8) Memorie 128 Mb Memorie 32 Mb Memorie Interna Principala Principala Memorie 1024 Kb Memorie 1024 Kb Cache Cache Porturi 4 Porturi 2 Hard Disc 2 GB Hard Disc 1 GB Drive 2 GB Drive 1 GB Memorie Externa Controler de SCASI Controler de IDE Disc Disc CD drive CD drive 3.5 Floppy Disc 3.5 inches Floppy Disc inches 5.25 5.25 inches inches Display Monitor Monitor Placa Video Placa Video Tastatura Carcassa Mouse Tab. 2.4.3 Componenta unei Retele de Calculatoare Cerintele de informatii care se ridica în legatura cu structura descrisa si memorata încalculator sub forma celor doua colectii de date prezentate anterior (Colectia Principala siColectia de Legaturi) sunt: o Fiind data o Comanda de achizitie a unor Ansambluri (Retele integrale) si a unor Componente separate (Piese), sa se determine Necesarul Total pentru fiecare Componenta o Cunoscând Disponibilul (Stocul) de Componente sa se determine Necesarul de Aprovizionat pentru fiecare tip de Componenta în vederea onorarii Comenzii o Cunoscând Disponibilul (Stocul) de Componente sa se determine Comenzile care se pot onora imediat sau care se cer amânate Se pot remarca doua aspecte legate de genul de prelucrari de date prezentat anterior: o Amploarea Colectiilor de Date care formeaza Sursa de Date pentru asemenea prelucrari: § Calitativ - structuri de tip Padure de Arbori § Cantitativ - mii de Noduri si sute de mii de Legaturi o Utilitatea informatiilor care se ofera cu implicatii directe asupra procesului de conducere a activitatilor principale ale unei întreprinderi
    • Exemple de Baze de Date 41PARTEA a 3 -a CONCEPTE de BAZA Conceptele de Baza sunt grupate în jurul a trei Antinomii, cu care Sistemele cu Baze de Date opereaza curent si al caror continut ca notiuni nu întruneste unanimitate în rândul specialistilor: Multimi – Relatii Informatie – Data Date – Proceduri Pentru a consolida claritatea expunerii din lucrare se sacrifica aceste prime sectiuni pentru a rememora anumite concepte fundamentale si a cladi pe ele acceptiuni ale altor concepte supuse interpretarilor. Sectiunile subordonate au fost organizate astfel: 3.1 – Multimi si Relatii – conceptele rememorate sunt de un real folos pentru întelegerea aportului Modelului Relational la viziunea structuralista a SBD si mai ales la aprecierea rolului acestui model în perspectiva timpului. 3.2 – Informatie si Data – notiuni de baza pentru SBD, ele sunt supuse numeroaselor interpretari, asa încât definirea clara a acceptiunilor din lucrare se impune. 3.3 – Date si Proceduri – opozitia Date-Proceduri nu poate fi ocolita în cadrul unui subiect care readuce frecvent în discutie problema Independentei celor doua elemente. 3.4 – Structuri de Informatii si Date – orienteaza conceptele deja prezentate spre sarcina lor principala: Construirea si Controlul Structurilor. 3.5 – Structuri de Proceduri – reia problema Structurii în cadrul Procedurilor pentru a da unitate Viziunii Structuraliste
    • 42 Concepte de de Baza / Multimi3 Concepte de Baza Prezentarea Conceptelor de Baza este organizata în jurul a trei opozitii de termeni cucare opereaza frecvent Bazele de Date: o Multimi si Relatii – ca elemente fundamentale de descriere a existentei o Informatie si Data – ca forme de reprezentare a Semnificatului si Semnificandului în SBD o Data si Procedura – ca mijloace de descriere a Starilor si Transformarilor unui Sistem Termenii introdusi sunt apoi folositi pentru descrierea Structurilor de Informatii, Datesi Proceduri, notiuni pe care se bazeaza construirea si utilizarea Sistemelor cu Baze de Date.3.1 Multimi si Relatii Începerea prezentarii Conceptelor de Baza cu care opereaza disciplina de Baze de Dateprin reamintirea unor notiuni fundamentale legate de Multimi si Relatii aduce urmatoarelebeneficii: - Permite raportarea conceptelor proprii disciplinei, precum si a terminologiei de specialitate la notiuni consistente - Înlesneste întelegerea evolutiei modelelor utilizate în diferite etape de dezvoltare a disciplinei - Permite orientarea în perspectivele de dezvoltare ale modelelor promovate si utilizate în SBD - Faciliteaza compararea si evaluarea conceptelor din domeniu, prin raportarea lor la cele din domeniile înrudite ( rogramare Clasica, Programare Obiectuala, P Ingineria Programarii, Instrumente CASE etc.)3.1.1 Multimi Multimea – poate fi privita ca o colectie de Elemente distincte (concrete sau abstracte),ce au o proprietate comuna. Definitia lui Cantor: “O multime este rezultatul cuprinderii într-un singur tot a unor obiecte determinate ale perceperii sau gândirii noastre; aceste obiecte se numesc elemente ale multimii.” Multimea si Elementul sunt notiuni primare si nu pot ca urmare sa fie definite în planabstract (ex.: într-un sistem formalizat). Având în vedere utilitatea proprietatilor generale ale multimilor pentru tratareaColectiilor de Informatii si Date cu care opereaza SBD, se retranscriu în continuareCaracteristicile de Baza ale Multimii. Se va observa în cele ce urmeaza ca ele vor fi preluateca Restrictii implicite ale Modelului Relational de Date.
    • Concepte de Baza / Multimi 433.1.1.1 Caracteristicile de baza ale Multimii o Individualitatea Elementului – Fiecare Element al Multimii trebuie sa se deosebeasca de celelalte. Orice Colectie de Date privita ca o Multime trebuie sa contina aceasta prima proprietate si sa asigure posibilitatea ca fiecare element din colectie (articol, înregistrare, tupla etc.) sa fie referit unic. De aici deriva necesitatea existentei unui Identificator pentru toate colectiile de date care, intrând în relatii reciproce, constituie un tot unitar si consistent. o Individualitatea Multimii – Fiecare Multime se individualizeaza prin existenta unei Proprietati Comune, definitorie pentru multime (multimea sa fie Bine Definita) Proprietatea de Multime Bine Definita poate interveni doar în cazul Colectiilor de Date ce sunt definite intensional în cadrul Bazelor de Cunostinte sau a Bazelor de Date Deductive. o Asemanarea Elementelor (Echivalenta Elementelor) – Din punctul de vedere al Proprietatii Comune nu exista Element Privilegiat si ca urmare nu exista nici Ordine a Elementelor (aceasta fiind o proprietate nespecificata în Proprietatea Comuna). Evidentiata în special de modelul Relational de date, caracteristica de Asemanare e prezenta prin modul de definire a Relatiei (Tabelei) ca si colectie de tuple sau rânduri care initial apar în Ordine Naturala (ordinea cronologica de înregistrare în colectie), ceea ce corespunde inexistentei unui element privilegiat, nici macar în ceea ce priveste Ordinea în Colectie, care survine doar ulterior în prelucrare, prin atasarea explicita a unui Criteriu de Ordonare si a unei Ordini introduse de o Tabela de Index. o Unitatea Elementelor – Proprietatea Comuna permite ca Multimea sa fie privita si tratata ca un nou Element (o noua entitate), care în aceasta calitate poate participa în alta Multime. Esenta prelucrarilor în sistemele cu Baze de Date este capacitatea de generare a unor noi Colectii de Date prin Regrupare sau Combinare de multimi. Fiecare noua colectie trebuie sa fie Identificabila (printr-un Nume, printr-o Proprietate sau printr-un Proprietar) si prin aceasta sa fie recunoscuta ca un Element într-o noua Colectie de Colectii de Date. Legatura între Element si Multime este realizata prin proprietatea de Apartenenta, careva sta la baza Relatiei de Echivalenta.3.1.1.2 Incluziunea Multimilor Fie M 1 si M 2 doua multimi.
    • 44 Concepte de de Baza / Multimi Se zice: M 2 ⊆ M 1 (M 2 e Inclus în M 1 sau M 2 e Parte Proprie a lui M 1 ) daca: ∀ x∈ M2 ⇒ x∈ M1 Se zice: M 2 ⊂ M 1 (M 2 e Strict Inclus în M 1 ) daca: ∀ x∈ M2 ⇒ x∈ M1 si ∃ x∈ M2 ⇒ x∉ M1 Prima forma de legatura între Multimi este realizata prin proprietatea de Incluziune si ebazata pe generarea de noi multimi prin Regrupare de Elemente. (Cea de a doua forma delegare a multimilor va fi introdusa odata cu prezentarea Relatiei.).3.1.1.3 Identitatea Multimilor Fie M 1 si M 2 doua multimi. Se zice: M 1 = M 2 (M 1 , M 2 identice sau egale) daca: ∀ x∈ M1 ⇔ x∈ M2 sau: ∀ x∈ M1 ⇒ x∈ M2 ∀ x∈ M2 ⇒ x∈ M1 O multime de multimi se numeste Clasa sau Familie. Notiunile de Clasa de Entitatisi Clasa de Obiecte îsi au originea în notiunea de Clasa, atât Entitatea Notiune cât si EntitateaObiect fiind privite ca Mutimi de Caracteristici, respectiv Multimi de Tuple de Valori.3.1.1.4 Multimea Totala Multimea Totala este multimea constituita pe baza unei Proprietati Fundamentale(Primare) a unor Elemente.
    • Concepte de Baza / Multimi 45 Toate celelalte proprietati care pot fi recunoscute pentru elementele unei Multimi Totalese adauga Proprietatii Primare purtând numele de Proprietati Secundare. Proprietatilesecundare definesc în multimea totala Parti ale acestei multimi. Referitor la o Multime Totala exista trei categorii de Proprietati: § Echivalente - definesc Multimea Totala (Multimea Plina), fiind echivalente din acest punct de vedere cu proprietatea fundamentala § Straine - definesc Multimea Vida a Multimii Totale § Restrictive - definesc Submultimi Parti ale Multimii Totale Proprietatile Restrictive sunt cele care asigura generarea de noi multimi prinRegruparea Elementelor unei Multimi date. Fiind data o Multime Totala M, se definesc: P(M) – Multimea Partilor lui M, care contine: • Submultimile lui M • Multimea Vida • Multimea Plina P*(M) – Multimea Partilor Nevide ale lui M, care contine: • Submultimile lui M • Multimea Plina Exista expresia de legatura: P*(M) = P(M) { ∅ } Fiind data o Multime M, Familia tuturor Submultimilor lui M e o Familie Bine Definitade multimi numita Familia Partilor Multimii M.3.1.1.5 Numararea Partilor unei Multimi Totale n Pentru o Multime M având n Elemente P(M) va avea 2 Elemente (reprezentate deMultimile Parti). Pentru o Multime M având definite n Submultimi (Multimi Parti) oarecare (nedisjuncte)acestea genereaza în multimea data: C n0 + C n1 + C n2 + … + C nn = 2 n Parti Disjuncte (obtinute prin Intersectia Submultimilor Oarecare pentru fiecare Combinatie de Submultimi) (C0 2 ) n + (C1 2 ) n + (C3 2 ) n + … + (Cn2 ) n = (2 n ) n Parti Disjuncte si Nedisjuncte (obtinute prin Reuniunea Submultimilor Disjuncte pentru fiecare Combinatie de Submultimi) Pentru n=9 Submultimi rezulta un Numar de Parti mai mare decât numarul estimat alelectronilor si protonilor din univers, de unde si puterea de generare de noi multimi prin
    • 46 Concepte de de Baza / MultimiRegrupare de Elemente (Partitii sau Acoperiri), procedeu mult utilizat în generarea de noicolectii de date. Notiunea de Multime Totala corespunde notiunii de Univers de Discurs din CalcululPredicatelor si notiunii de Univers din unele Sisteme Formale Axiomatizate. In domeniulBazelor de Date ea poate fi atasata fie unei Baze de Date (Logice sau Fizice) sau chiar uneiRelatii (Tabele) care, fiind Bine Definite pot conduce la generarea unor numeroase Medii deLucru (Colectii de Date) prin simpla adaugare de Filtre de Selectie (Proprietati Secundare).3.1.1.6 Operatii Booleene pe Multimea Partilor unei Multimi Totale Fie M Multimea Totala si M i ∈ P (M), pentru ∀ i ∈ {1,2, .. ,n}. Complementara unei multimi M 1C = { m ∈ M | m ∉ M 1} Reuniunea multimilor M 1 ∪ M 2 = { m ∈ M | m ∈ M 1 sau m ∈ M 2 } “sau” e inclusiv Intersectia multimilor M 1 ∩ M 2 = { m ∈ M | m ∈ M 1 si m ∈ M 2 } Diferenta multimilor M 1 M 2 = { m ∈ M | m ∈ M 1 si m ∉ M 2 } Diferenta simetrica a multimilor M 1 ∆ M 2 = { m ∈ M | m ∈ M 1 sau exclusiv m ∈ M 2 si m ∉ ( M 1 ∩ M 2 )} Multimi Disjuncte M 1 M 2 sunt disjuncte pentru M 1 ∩ M 2 = ∅3.1.1.7 Acoperire si Partitie M2 M1 M3 Fig. 3.1.1.7.1. Submultimi în Relatie de Acoperire Multimile Parti M 1 , M 2 , M 3 , .. , M n formeaza o Acoperire pe M pentru:
    • Concepte de Baza / Multimi 47 M 1 ∪ M 2 ∪ M 3 ∪ .. ∪ M n = M M2 M4 M1 M6 M5 M3 Fig. 3.1.1.7.2. Submultimi în Relatie de Partitie Multimile Parti M 1 , M 2 , M 3 , .. , M n formeaza o Partitie Neordonata pe M pentru: M 1 ∩ M 2 = ∅ pentru ∀ i , j ∈ {1,2, .. ,n} si i # j3.1.1.8 Latice Conceptul de Latice s-a format cu scopul generalizarii si unificarii raporturilor careexista între submultimile anumitor structuri. LATICEA – O Multime L împreuna cu doua Operatii de Compozitie: Intersectie (∩)si Reuniune (∪), care respecta urmatoarele Axiome: o Comutativitate a ∩ b=b ∩ a a ∪ b=b ∪ a o Asociativitate (a ∩ b) ∩ c = a ∩ (b ∩ c) (a ∪ b) ∪ c = a ∪ (b ∪ c) o Absorbtie a ∪ (a ∩ b) = a a ∩ (a ∪ b) = a pentru: ∀ a, b, c ∈ L
    • 48 Concepte de Baza / Relatii între Multimi3.1.2 Relatii între Multimi Exista doua metode de a genera noi multimi pornind de la multimi date prin: - Regrupare de Elemente – operatie întâlnita la stabilirea Multimilor Parti (de tip Partitie sau Acoperire) prin definirea de Proprietati Secundare - Combinare de Elemente - operatie întâlnita la efectuarea Produsului Cartezian a multimilor Combinarea de elemente se realizeaza cu ajutorul notiunii de Cuplu. Fiind date multimile M 1 si M 2 , perechea ordonata (m 1 , m 2 ) cu m 1 ∈ M 1 si m 2 ∈M 2 poarta numele de Cuplu. Se observa ca notiunea de Cuplu introduce pentru prima data îndiscutie problema Ordinii în multimile de elemente, prin aceea ca termenul “perecheaordonata (m 1 , m 2 )” este folosit, într-un sens intuitiv, ca o alaturare a elementelor m 1 si m 2astfel încât m 1 poate fi perceput ca un Element Aparte (Primul Element) al perechii ordonate(m 1 , m 2 ) si m 2 ca Celalalt Element (al Doilea Element). Faptul ca definirea formalizata a relatiilor de Ordine pe multimi apeleaza la conceptulde Cuplu, ne face sa consideram Ordinea, alaturi de Multime si Element, ca o notiuneprimara. Pentru aceeasi idee pledeaza si definirea în cadrul Teoriei Multimii a notiunii dePereche Ordonata, nu pur si simplu ca { m 1, m 2 }, ci prin postularea urmatoarei egalitati prindefinitie: (m 1 , m 2 ) = def { { m 1 } , { m 1 , m 2 } }înteleasa în modul ca, daca m 1 # m 2 , membrul stâng al perechii ordonate (m 1 , m 2 ) esteelementul multimii formate dintr-un singur element, pe când membrul drept este constituit cuelementul ce nu se gaseste în aceasta multime. Definitia folosita extrage elementul m 1 dinmultime eliberându-l de proprietatea de echivalenta si acordându-i o proprietate noua, pe ceade Pozitie în multime pe care se bazeaza de fapt conceptul de Ordine. Se mai poate remarca sifaptul ca daca, prin reducere la absurd, consideram: (m 1 , m 2 ) = { { m 1 } , { m 1 , m 2 } } = { { m 2 } , { m 1 , m 2 } }rezulta: m1 =m 2 Din aceasta definitie se poate deriva si urmatoarea proprietate fundamentala a perechilorordonate, cunoscuta si sub numele de Axioma Cuplului si care se enunta astfel: (x , y ) = (x’ , y’) ⇒ x = x’ si y = y’ , Aceasta definitie subliniaza o data în plus faptul ca modul de enumerare (pozitia înmultime), care pâna acum era indiferenta începe deja sa conteze. Notiunea de Cuplu se generalizeaza pentru n multimi, M 1 , M 2 , M 3 , .., M n , priminddenumirea de n-TUPLU (sau n-UPLU) si având forma: (m 1 , m 2 , m 3 , .. , m n).
    • Concepte de Baza / Relatii între Multimi 493.1.2.1 Produs Cartezian de multimi Produsul Cartezian a n multimi M 1 , M 2 , M 3 , .. , M n se defineste ca fiind multimea: M 1 x M 2 x M 3 x .. x M n = Π M i = { (m 1 , m 2 , m 3 , .. , m n) | m i ∈ M i pentru ∀ i ∈ {1,2, .. ,n} } Pentru M 1 = M 2 = M 3 = .. = M n = M , Produsul Cartezian a n multimi se transformaîn Puterea Carteziana a unei multimi, notata M n.3.1.2.2 Reuniunea Disjuncta a Multimilor Cu ajutorul notiunii de Produs Cartezian poate fi definita operatia de ReuniuneDisjuncta a doua multimi: M 1 ∪ d M 2 = ( M 1 x {1} ) ∪ ( M 2 x {2} )operatie care realizeaza dedublarea elementelor comune multimilor M 1 si M 2 . Aceastaoperatie da justificarea prelucrarilor în sistemele ce nu respecta unicitatea de identificare aelementelor de date si cu toate acestea implementeaza proceduri consistente de tratare adublurilor, prin Reguli Specializate de tratare a Elementelor Dublate potrivit Provenientei lordin Colectii de Date diferite, în cazul Interclasarii. Reguli Specializate similare pot trata siPozitia în Colectie a Elementelor Dublate.3.1.2.3 Relatia n-ara O Relatie n -ara R pe multimile nevide M 1 , M 2 , M 3 , .. , M n se defineste ca oSubmultime a Produsului Cartezian M 1 x M 2 x M 3 x .. x M n . Deci: R ⊆ M 1 x M 2 x M 3 x .. x M n Cu alte cuvinte, orice Multime Parte a unui Produs Cartezian e o Relatie. Numarul Multimilor pe care e definit Produsul Cartezian confera Gradul Relatiei, înspeta n, cu conditia impusa n ≥ 2. (Orice Relatie implica minimum doua Domenii, nu neaparatDistincte.) Relatia e deci o multime si are ca urmare o Proprietate Definitorie, care e valabilapentru toate n-Tuplele Relatiei. Întrucât fiecare n-tupla contine mai multe elemente primare mi ,provenind din multimile de definitie M i , Proprietatea Definitorie a relatiei poate fi privita caun Predicat Polinar; P (m 1 , m 2 , m 3 , .. , m n). In definirea unei Relatii se pot recunoaste cele doua forme de definitie ale uneimultimi: - Intensionala – prin: P (m 1 , m 2 , m 3 , .. , m n) = ‘adevarat’
    • 50 Concepte de Baza / Relatii între Multimi pe multimea Produsului Cartezian M 1 x M 2 x M 3 x .. x M n , privit ca Multime Totala - Extensionala – prin: { (m 1 , m 2 , m 3 , .. , m n) | m i ∈ M i pt. ∀i ∈ {1,2, .. ,n} si (m 1 , m 2 , m 3 , .. , m n) ∈ R } Conditia ca Multimile de Definitie M i sa nu fie vide se motiveaza prin necesitatea cafiecare n-tuplu sa contina în mod constant n elemente, absenta unuia din elementele n-tupluluidistrugând ideea de Ordine pe care n-tuplul trebuie sa o instituie între elementele sale. Relatiapoate însa sa fie Vida , fiind în acest caz reprezentata de Submultimea Vida a ProdusuluiCartezian M 1 x M 2 x M 3 x .. x M n, care semnifica faptul ca Proprietatea Definitorie, înacest caz, este o Proprietate Straina (neîndeplinita de nici o combinatie de elemente dinMultimile de Definitie). Pentru n = 2 se obtin Relatiile Binare , relatii foarte utile pentru descrierea naturiilegaturilor între Multimi, dar si între Elementele Multimilor (în speta Atributele unei Relatiidin Modelul Relational de Date). Pentru relatiile binare se folosesc doua conventii de notatie echivalente: x R y ⇔ (x , y) ∈ R Fiind data o relatie binara R definita pe o singura multime M se pot defini notiunile: - Domeniul de Definitie al Relatiei (numit si Suport), reprezentat de Proiectia de Rang 1 a Puterii Carteziene M x M: DD R = P R , 1 - Domeniul de Valori al Relatiei (numit si Codomeniu), reprezentat de Proiectia de Rang 2 a Puterii Carteziene M x M: DV R = P R ,2 - Domeniul Relatiei , reprezentat de Reuniunea Domeniului de Definitie cu Domeniul de Valori: DR R = DD R ∪ DV R De unde rezulta: DD R ⊆ DR R si DVR ⊆ DR R3.1.2.4 Implicarea relatiilor (Extensii si Restrictii) Fie doua relatii R 1 si R 2 definite pe acelasi Produs Cartezian de Multimi. Se zice ca: Relatia R 1 implica relatia R 2
    • Concepte de Baza / Relatii între Multimi 51 si se noteaza cu: R1 ≤ R2 Daca: R 2 e adevarata ori de câte ori R 1 e adevarata Aceasta proprietate determina existenta unei Legaturi de Dependenta (Incluziune) siîntre Domeniile de Valori ale celor doua Relatii. R1 ≤ R2 ⇔ R1 ⊆ R2 (în Intensiune) (în Extensiune) R 1 - se zice Restrictie a lui R 2 R 2 - se zice Extensie a lui R 13.1.2.5 Proiectia relatiilor Proiectia relatiilor reprezinta o forma de Generare de noi Multimi care se înscrie înforma de Regrupare, dar de data aceasta a Multimilor de tip Relatie. Ca urmare Relatiareprezentând o multime: R={ (m 1 , m 2 , m 3 , .. , m n) | m i ∈ M i pentru ∀i ∈ {1,2, .. ,n} si P (m 1 , m 2 , m 3 , .. , m n) = ‘adevarat’} de multimi ordonate: (m 1 , m 2 , m 3 , .. , m n)Regruparea se va extinde în doua planuri: - Planul Multimii de Elemente ce formeaza n-Tupla – prin definirea Rangului Proiectiei - Planul Multimii de n-Tuple ce formeaza Relatia – prin definirea Conditiei de Proiectie Proiectia de rang j a Relatiei n-are: R ⊆ M 1 x M 2 x M 3 x .. x M j x .. x M k x .. x M n e data de Multimea: - pentru Proiectia Neconditionata πR, j = {m j|m k ∈ Mk pentru ∀ k ∈ {1,2, .. ,n} { j } si (m 1 , m 2 , m 3 , .. , m j , .. , m k.. , m n) ∈ R} unde j reprezinta Rangul pe care se face Proiectia Relatiei R - pentru Proiectia Conditionata
    • 52 Concepte de Baza / Relatii între Multimi π R , j, Mk’ = { m j | m k ∈ M k‘ pentru ∀ k ∈ {1,2, .. ,n} { j } , M k‘ ⊂ M k si (m 1 , m 2 , m 3 , .. , m j , .. , m k.. , m n) ∈ R} unde M k‘ ⊂ M k reprezinta Conditia dupa care se face proiectia relatiei R (de fapt o multime de conditii suplimentare impuse tuplelor din care se extrag elementele de rang j ) In aceasta forma completa, Proiectia Relatiilor sta la baza Operatorilor Relationali deSelectie si Proiectie din Algebra Relationala.3.1.2.6 Proprietatile Relatiilor Binare Asa dupa cum rezulta din conditia impusa Gradului Relatiilor n ≥ 2 , Relatiile Binarereprezinta categoria de relatii de Rang Minim. Analiza proprietatilor Relatiilor Binare estefoarte importanta pentru clasificarea raporturilor în care pot sta doua multimi legate prin relatii.Proprietatile relatiilor binare definesc tot atâtea Tipuri de Relatii Binare.3.1.2.6.1 Relatii Binare pe Doua Multimi Distincte In acest caz: R ⊆ M 1 x M2 . unde: R = { (m 1 , m 2 ) | m i ∈ M i pentru ∀i ∈ {1,2}si P (m 1 , m 2 ) = ‘adevarat’} Relatia Inversa R –1 ⊆ M 1 x M 2 - proprietate: (m 1 , m 2 ) ∈ R –1 ⇒ (m 2 , m 1 ) ∈ R Relatia Complementara Rc ⊆ M1 x M2 - proprietate: (m 1 , m 2 ) ∈ R c ⇒ (m 1 , m 2 ) ∉ R Relatia Unica la Stânga R us ⊆ M 1 x M 2 - proprietate: (m 1 , m 3 ) ∈ R us si (m 2 , m 3 ) ∈ R us ⇒ m 1 = m 2
    • Concepte de Baza / Relatii între Multimi 53 Relatia Unica la Dreapta R ud ⊆ M 1 x M 2 - proprietate: (m 1 , m 2 ) ∈ R ud si (m 1 , m 3 ) ∈ R ud ⇒ m 2 = m 3 Relatia Biunica Relatia Biunica este o Relatie Unica la Stânga si Unica la Dreapta. Relatia Binara Functionala Relatia Binara Functionala este o Relatie Unica la Stânga sau Unica la Dreapta Întrucât proprietatea de Unicitate nu e simetrica au loc urmatoarele determinari: - pentru Relatia Unica la Stânga PR,M2 → PR,M1 P R , M 2 determina functional pe P R , M 1 P R , M 1 depinde functional de P R , M 2 - pentru Relatia Unica la Dreapta PR,M1 → PR,M2 P R , M 1 determina functional pe P R , M 2 P R , M 2 depinde functional de P R , M 1 Dependenta Functionala între doua Multimi: M 1 si M 2 în cadrul unei Relatii n-are: R ⊆ M 1 x M 2 x M 3 x .. x M n poate fi determinata din analiza proprietatii proiectiei: PR,M1xM2 . Daca Proiectia este o Relatie Binar Functionala, atunci: Multimile M 1 si M 2 sunt Functional Dependente în cadrul Relatiei n-are R3.1.2.6.2 Relatii Binare pe Aceeasi Multime In acest caz:
    • 54 Concepte de Baza / Relatii între Multimi R ⊆ Mx M.unde: R = { (m 1 , m 2 ) | m i ∈ M pentru ∀i ∈ {1,2} si P (m 1 , m 2 ) = ‘adevarat’} Relatia Identica (Nula) Ri ⊆ Mx M - proprietate: ∀ m ∈ M ⇒ (m , m) ∈ R si (m 1 , m 2 ) ∈ R ⇒ (m 1 = m 2 ) Relatia Totala – relatie identica cu Produsul Cartezian Rt = Mx M Relatia Reflexiva – orice relatie ce contine o Relatie Identica Rr ⊆ Mx M - proprietate: ∀ m ∈ M ⇒ (m , m) ∈ R r sau altfel exprimat: Rr ≥ Ri Relatia Nereflexiva – orice relatie ce nu contine nici un element al Relatiei Identice Rn ⊆ Mx M - proprietate: ∀ m ∈ M ⇒ (m , m) ∉ R n Relatia Simetrica – contine toate perechile de cupluri simetrice Rs ⊆ Mx M - proprietate: (m 1 , m 2 ) ∈ R ⇒ (m 2 , m 1 ) ∈ R s sau altfel exprimat: R s -1 = R s Relatia Asimetrica– contine si cupluri fara perechea simetrica R as ⊆ M x M
    • Concepte de Baza / Relatii între Multimi 55 - proprietate: ∃ (m 1 , m 2 ) | (m 1 , m 2 ) ∈ R as ⇒ (m 2 , m 1 ) ∉ R as Relatia Antisimetrica– nu contine nici-o pereche de cupluri simetrice Ra ⊆ Mx M - proprietate: (m 1 , m 2 ) ∈ R a ⇒ (m 2 , m 1 ) ∉ R a sau altfel exprimat: R a ∩ R a -1 ≤ R i Relatia Tranzitiva Rt ⊆ Mx M - proprietate: (m 1 , m 2 ) ∈ R t si (m 2 , m 3 ) ∈ R t ⇒ (m 1 , m 3 ) ∈ R t sau altfel exprimat: Rt * Rt ≤ Rt Relatia Conexa Rx ⊆ Mx M - proprietate: (m 1 , m 2 ) ∈ R x sau inclusiv (m 2 , m 1 ) ∈ R x3.1.2.6.2.1 Tipuri de Relatii Binare pe Aceeasi Multime3.1.2.6.2.1.1 Relatia de Echivalenta Relatia de Echivalenta este o Relatie Binara cu urmatoarele proprietati: § Reflexivitate § Simetrie § Tranzitivitate Multimea tuturor Echivalentelor pe o multime data M se noteaza cu E ( M ) si se bucurade proprietatea: E( M ) ⊆ P ( M x M ) . Clasa de Echivalenta a Elementului m ∈ M fata de Echivalenta E e data de Multimea:
    • 56 Concepte de Baza / Relatii între Multimi [m]E ={m 1 |mEm 1 } . Reprezentant al Clasei de Echivalenta se considera a fi: ∀m∈ [m]E Multimea Cât , se noteaza M | E si reprezinta Multimea Claselor de Echivalenta aletuturor Elementelor unei Multimi M fata de o Echivalenta E: M|E = {[m]E | ∀ m∈ M} Cardinalul Multimii Cât este o masura a Gradului de Omogenitate al unei Multimi Mfata de o Echivalenta E. Pe baza definitiei Claselor de Echivalenta, [ m ] E , pot fi demonstrate urmatoareleproprietati ale acestora: - Clasele de Echivalenta formeaza o Acoperire pe Multimea de Definitie M: ∪ [m] E = M Rezulta din proprietatea de Reflexivitate a Echivalentei: ∀ m|mEm - Clasele de Echivalenta formeaza o Partitie pe Multimea de Definitie M: [m 1 ] E ∩ [m 2 ] E = ∅ , pentru (m 1 , m 2 ) ∉ E Rezulta din proprietatea de Tranzitivitate a Echivalentei : Daca: ∃ m | m ∈ [ m 1 ] E si m ∈ [ m 2 ] E Atunci: (m 1 , m 2 ) ∈ E. Reciproc : Orice Partitie pe o Multime data M determina o Relatie de Echivalenta E pe aceasta multime.3.1.2.6.2.1.2 Relatii de Ordine Relatia de Ordine este o Relatie Binara cu urmatoarele proprietati: § Reflexivitate § Antisimetrie § Tranzitivitate Importanta relatiilor de Ordine consta în faptul ca ele permit introducerea conceptuluide Multime Ordonata, definita ca o pereche ordonata:
    • Concepte de Baza / Relatii între Multimi 57 - O Multime -M - O Relatie de Ordine - O Mo ≡ ( M , O ) Acest concept este preluat de Modelul Relational de organizare a datelor prinurmatoarele restrictii implicite: o Orice Colectie de Date este privita ca o Multime (de tuple, sau înregistrari), deci neordonata o Cu ajutorul acestor Colectii de Date, care constituie Structura de Baza a Modelului de Date, se poate construi, utilizând conceptul de Relatie, orice structura de date oricât de complexa o Toti Operatorii implementati pe aceasta Structura de Baza nu pretind existenta prealabila a unei Ordini o Ordonarea Colectiilor de Date se face prin adaugarea unor Structuri Auxiliare de date (Indecsi), care folosesc exclusiv pentru ridicarea performantelor de prelucrare (la Identificare, Acces sau Ordonare) si nu la construirea structurilor de date o Unei Colectii de Date i se pot adauga oricâti Indecsi transformând-o în tot atâtea Colectii Ordonate, care dispar odata cu eliminarea structurilor auxiliare atasate, ceea ce confera un caracter dinamic procesului de ordonare o Procesul de Navigare în aceste Colectii de Date ramâne si el dinamic prin posibilitatea modificarii Ordinii de Inspectie prin simpla înlocuire a Indexului Activ pe parcursul navigarii In functie de proprietatile suplimentare care se adauga proprietatilor de baza ale Relatieide Ordine se pot defini mai multe Tipuri de Relatii de Ordine: § Relatii de Ordine Partiala § Relatii de Ordine Totala § Relatii de Bine Ordonare3.1.2.6.2.1.2.1 Relatia de Ordine Partiala O Relatie de Ordine fara alte restrictii suplimentare se zice Relatie de Ordine Partiala– O P . Denumirea provine din faptul ca proprietatile exprimate fac ca relatia sa nu se extindaasupra tuturor Elementelor Multimii. Ca exemplu tipic de relatie de Ordine Partiala este:“ Multimea partilor unei multimi P ( M ) , care e partial ordonata prin relatia de Incluziune a Partilor. “ In cadrul structurii generate de apartenenta Partilor la o Multime data, alaturi deraporturile de Incluziune, care sunt ordonate de legatura Ascendent – Descendent, extinsa petoate nivele de imbricare ale submultimilor, este prezenta si legatura d Echivalenta între e
    • 58 Concepte de Baza / Relatii între Multimisubmultimile sau elementele aflate pe acelasi nivel si între care, neexistând prioritate, nu existanici relatie de ordine. O Multime Partial Ordonata este o pereche ordonata ( M , O P ) , unde: § M – Multime § O P – Relatie de Ordine Partiala In exemplul dat, multimea Partilor unei Multimi, privita ca Multime Ordonata, sedefineste prin cuplul (P ( M ) , I ) , unde: § P ( M ) - Multimea Partilor lui M § I - Relatia de Incluziune definita de: ( p 1 , p 2 ) ∈ I ⇒ “ Multimea Parte p 1 include Multimea Parte p 2 “3.1.2.6.2.1.2.2 Relatia de Ordine Totala O Relatie de Ordine Partiala care se extinde asupra tuturor elementelor Multimii M,se zice Relatie de Ordine Totala – O T . O relatie de Ordine Totala îndeplineste, fata derelatia de Ordine Partiala, urmatoarea conditie suplimentara: ∀ m 1 , m 2 ∈ M ⇒ m 1 O T m 2 sau exclusiv m 2 O T m 1 (sau e Exclusiv întrucât relatia ramâne Antisimetrica) Conditia suplimentara putea fi exprimata si în forma: O T ∪ O T -1 = R T unde: R T e Relatia Totala (Puterea Carteziana a Multimii M) Ca exemplu reprezentativ de Relatie de Ordine Totala este: “ Multimea Numerelor Reale - R , care e Total Ordonata prin relatia Naturala de Ordine - ON .“ o Relatia Naturala de Ordine se poate exprima între oricare doua Numere Reale. O Multime Total Ordonata este o pereche ordonata (M , O T ) , unde: § M – Multime § O T – Relatie de Ordine Totala In exemplul dat, Multimea Numerelor Reale, privita ca Multime Ordonata, se definesteprin cuplul (R , O N ) , unde: § R - Multimea Numerelor Reale § O N - Relatia Naturala de Ordine definita de:
    • Concepte de Baza / Relatii între Multimi 59 ( r 1 , r 2 ) ∈ O N ⇒ “ numarul r 1 ≤ numarul r 2 “ Se verifica: ∀ r 1 , r 2 ∈ R ⇒ r 1 ≤ r 2 sau exclusiv r 2 ≤ r 13.1.2.6.2.1.2.3 Relatia de Bine Ordonare O Relatie de Ordine Totala care are un Element Cel Mai Mic, se zice Relatie de BineOrdonare – O B . O Relatie de Bine Ordonare îndeplineste, fata de Relatia de Ordine Totala,urmatoarea conditie suplimentara: ∀ M 1 ⊂ M,M 1 # ∅ ⇒ ∃ m 1 ∈ M1 | ∀ m ∈ M1 ,m 1 O T m Altfel exprimat: “ Pentru orice Submultime Nevida din M, exista un Element Cel Mai Mic. “ Ca exemplu reprezentativ de Relatie de Bine Ordonare este:“ Multimea Numerelor Naturale - N , care e total ordonata prin relatia Naturala de Ordine - ON .“ Fata de Multimea Numerelor Reale, în Multimea Numerelor Naturale se poateîntotdeauna gasi un Numar Cel Mai Mic. O Multime Bine Ordonata este o pereche ordonata ( M , O B ) , unde: - M – Multime - O B – Relatie de Bine Ordonare In exemplul dat, Multimea Numerelor Naturale, privita ca Multime Ordonata, sedefineste prin cuplul (N , O B ) , unde: - N - Multimea Numerelor Naturale - O B - Relatia Naturala de Ordine definita de: ( n 1 , n 2 ) ∈ O B ⇒ “ numarul n 1 ≤ numarul n 2 “ se verifica: ∀ r 1 , r 2 ∈ R ⇒ r 1 ≤ r 2 sau exclusiv r 2 ≤ r 1 si “ în orice submultime de numere exista un numar cel mai mic “3.1.2.6.2.1.3 Relatia de Similitudine (”Asemanare”) Relatia de Similitudine este o Relatie Binara cu urmatoarele proprietati: o Reflexivitate
    • 60 Concepte de Baza / Grafuri si Arbori o Simetrie O relatie de Similitudine Tranzitiva devine Relatie de Echivalenta.3.1.3 Relatii, Aplicatii, Functii Relatia generalizeaza notiunile de Aplicatie si Functie, concepte de baza înmatematica. O Functie pe o multime DD cu valori în DV este o Relatie Unica la Dreapta cuSuportul DD si Domeniul Valorilor DV: F = {(x,y) ∈DD x DV | (x,y) ∈ R ud } . Daca nu impunem conditia de Relatie Unica la Dreapta, ajungem la definirea maigenerala a Aplicatiilor cu particularitatile lor: - Aplicatii Injective – aplicatii din DD în DV – când Suportul relatiei atasate e întregul DD - Aplicatii Surjective – aplicatii din DD pe DV – când Domeniul Valorilor relatiei atasate e întregul DV - Aplicatii Bijective – aplicatii ce sunt Relatii Biunice Particularizând aceste proprietati în cazul Functiilor obtinem: - Functiile Injective – sunt Relatii Unice la Stânga si ca urmare, pe baza definitiei Functiilor ca Relatii Unice la Dreapta, sunt totodata si Functii Injective si, în final, sunt Functii Bijective (Biunivoce sau Inversabile) - Functiile Inverse notate F –1 sunt definite pe o multime DV cu valori în DD F –1 = {( y,x ) ∈DV x DD | ( x,y ) ∈F } astfel încât orice Element din DD are o Imagine Inversa Unica în DD si Inversa unei Functii Bijective este tot Bijectiva.3.1.4 Grafuri Prezentarea notiunii de Graf si a celor atasate acestuia se face întrucât reprezentareaStructurilor de Informatii si de Date cu ajutorul Grafurilor este foarte frecvent întâlnita îndisciplina de Baze de Date.3.1.4.1 Graful ca Relatie In forma cea mai generala Graful poate fi definit ca o Relatie pe un Produs deMultimi: G ⊆ ∏ Mi
    • Concepte de Baza / Grafuri si Arbori 61 In aceasta viziune Graful e privit nu doar ca o Multime de Arce ce leaga Perechi deVârfuri, ci si c un set de alte caracteristici atasate Arcelor si Vârfurilor ce intra în legatura a(Intensitati, Debite, Fluxuri, Rezistente etc.). In Teoria Grafelor notiunea de Graf se obtine prin particularizarea definitiei de maisus: § Graful e definit de o Relatie Binara § Relatie Binara e definita pe o Singura Multime § Multimea de Definitie a Relatiei e Numarabila3.1.4.2 Graful ca AplicatieDefinitia I - a: Graful e reprezentat de expresia: G = (X , T) si contine: o O Multime Nevida de Elemente X o O Aplicatie T a lui X în Multimea Partilor lui X T : X→ P ( M )Definitia a II - a: Graful e reprezentat de expresia: G = (X , U) si contine: o O Multime Nevida de Elemente X numite Vârfuri sau Noduri: X = { x 1 , x 2 , .. , x n } o O Multime de Perechi de Elemente U: Neordonate { x i , x j } – numite Muchii (neorientate) cu x i , x j - Extremitati sau Ordonate ( x i , x j ) - numite Arce (orientate) cu x i - Origine si x j - Extremitate
    • 62 Concepte de Baza / Grafuri si Arbori Intr-un Graf Orientat, G = ( X , U ) pot fi definite urmatoarele elemente: - Succesor al unui Vârf x i – toate Vârfurile x j pentru care exista Arcele (x i , x j) - Predecesor al unui Vârf x i – toate Vârfurile x j pentru care exista un Arc de forma (x j, x i ) - Vârfuri Adiacente – doua Vârfuri legate printr-un Arc - Drum Orientat – o Succesiune de Vârfuri Adiacente (x 1 , x 2 , .. , x d-1 , x d ) astfel încât: (x 1 , x 2 ) , (x 1 , x 2 ) , .. , (x d-1 , x d) ∈ U - Circuit– un Drum Orientat în care Extremitatea ultimului Arc coincide cu Originea primului Arc - Graf Tare Conex – un Graf Orientat în care fiecare Cuplu de Vârfuri defineste un Drum Orientat - Lungime de Drum – Numarul Arcelor unui Drum - Bucla – un Drum de Lungime 1 - Descendent al unui Vârf x i – toate Vârfurile x j din G astfel încât sa existe un Drum Orientat de la i la j - Ascendent al unui Vârf x i – toate Vârfurile x j din G astfel încât sa existe un Drum Orientat de la j la i In cazul unui Graf Neorientat definitiile anterioare ramân valabile facând urmatoarelesubstitutii: • Arc cu Muchie • Circuit cu Ciclu • Graf Tare Conex cu Graf Conex3.1.4.3 Arbori Arborii reprezinta cazuri particulare de Grafuri, adica Grafuri având proprietatisuplimentare, pe care le prezentam în continuare: - Arbore – un Graf Conex care are un singur Vârf, numit Radacina, fara nici-un Ascendent - Vârf Terminal – toate Vârfurile unui Arbore care nu au nici-un Descendent - Nivelul unui Vârf – Lungimea Drumului între Radacina si Vârf - Subarbore al unui Arbore – un Arbore a carui Radacina are un Ascendent într- unul din Vârfurile Arborelui în care e continut - Padure de Arbori – o Multime Ordonata de Arbori (exemplu: multimea Subarborilor unui Arbore )
    • Concepte de Baza / Grafuri si Arbori 63 Structurile de Date ale Bazelor de Date Fizice se aliniaza la caracteristicile Padurii de Arbori, datorita prezentei obligatorii a Relatiilor de Incluziune, care genereaza Partitiile necesare în Multimea de Instante ale Claselor de Entitati (Ex. Produsele contractate de Beneficiari, Unitatile unei Structuri Organizatorice pentru care sunt definite alte Resurse etc.) A R S1 S2 S3 A - Arbore Subarbore → Arbore R – Radacina (Apel Recursiv) S – Subarbore Fig. 3.1.4.1 Reprezentarea Recursiva a structurii unui Arbore Definitiile de mai jos introduc termeni specifici structurilor de date din Sistemele cuBaze de Date, cum sunt Arborele Simplu si Arborele Invers si care forteaza în anumite limiterigoarea definirii matematice, ramânând însa suficient de clare pentru a putea fi utilizate înpractica fiind de asemenea prezente si în literatura de specialitate. - Arbore Simplu – un Arbore în care toate nodurile, cu exceptia Radacinii, au un singur Ascendent Proprietatile Arborilor Simpli: § într-un Arbore Simplu între oricare doua Vârfuri exista un singur Drum § într-un Arbore Simplu daca se exclude Radacina, celelalte Vârfuri pot fi împartite într-un numar de multimi disjuncte de Vârfuri, fiecare multime alcatuind la rândul ei un Arbore, numit Subarbore al Arborelui initial
    • 64 Concepte de Baza / Grafuri si Arbori - Arbore Invers – un Arbore care are cel putin un Vârf cu mai mult de un Ascendent Arborele Invers preia denumirea de la aparitia unei Ierarhii de Ascendenta (mai multi Asscendenti pentru un Descendent), alaturi de Ierarhia de Descendenta (mai multi Descendenti pentru un Ascendent) Cea mai importanta Proprietate a Arborelui este Structura sa Recursiva. Ea este pusa înevidenta atât de definirea structurii de Arbore utilizând Reguli de Descriere, cât si dinreprezentarea grafica din Fig. 3.1.4.1. Arbore → Radacina {Subarbore 1 , Subarbore 2 ,.., , Subarbore i } Subarbore → Arbore Avantajele utilizarii Proprietatii de Recursivitate a structurilor de tip Arbore suntmultiple. Enumeram câteva: - Concentrarea Definirii Logice a structurilor de date - Reducerea numarului de Structuri Fizice Memorate - Simplificarea Interfetelor Utilizator pentru actualizarea datelor - Utilizarea Procedurilor Recursive de Traversare a Arborilor Problema tratarii Recursivitatii este deosebit de importanta si pentru Limbajele deManipulare a Datelor. Limbajele Neprocedurale utilizate în Bazele de Date nu dispun defacilitatea de recursivitate, ceea ce a determinat Extensiile Limbajelor de Manipulare a Datelor(ex. PL SQL), care sa permita apelul la Limbajele de Navigare pentru Traversarea Arborilor.Exista trei forme de Inspectie a Arborilor (Parcurgere a Arborilor), numita si Traversare aArborilor: - Parcurgere în Preordine – Utilizata pentru Listarea Structurii prin transformare Structurii Arborescente în structura Secvential - Ierarhizata Radacina, Subarbore Stâng, Subarbore Drept - Parcurgere în Endordine – Utilizata pentru Acumularea Informatiei din Descendenti în Ascendent (ex. Proceduri de Centralizare) Subarbore Stâng, Subarbore Drept, Radacina - Parcurgere în Postordine – Utilizata pentru Transferul Informatiei între Descendenti cu consultarea Ascendentului Subarbore Stâng, Radacina, Subarbore Drept Traversarea Arborilor reprezinta proceduri laborioase, care devin adesea neadecvateconsultarii interactive a Bazelor de Date. Aceste proceduri pot fi cu succes înlocuite de altemetode de calcul: o Ridicarea recursivitatii prin Liniarizarea Structurii o Materializarea datelor prin Functii de Calcul încorporate în Proceduri Stocate. Structurile de tip Arbore sunt utilizate în Bazele de Date si pentru Generarea Automataa Codurilor Structurate, eliminând operatiile laborioase de întocmire a Cataloagelor deObiecte, carora sa li se ataseze manual coduri ce trebuie si gestionate în continuare.
    • Concepte de Baza / Informatie si Data 653.2 Informatie si Data Clarificarea notiunilor de Informatie si Data, precum si a raportului dintre eleconstituie un demers necesar înaintea oricarei dezbateri care îsi propune tratarea problemelorlegate de Construire a Structurilor de Informatii si de Date, de Prelucrare Automata sauManuala a acestora, de Optimizare a Structurilor, de legatura a lor cu Procedurile dePrelucrare, si în final de stabilire a utilizarii lor cât mai profitabile în practica. Investigatia este cu atât mai necesara cu cât , având de a face cu Notiuni Primare, sepoate vorbi mai degraba despre acceptiuni ale acestor concepte, despre Modele preferate îndefinirea lor, decât despre adoptarea unor Definitii unanim recunoscute de catre specialisti. Întrucât se poate considera ca Teoria Informatiei se constituie în primul rând ca osuma de Concepte si Modele - întelegând prin Model, o aproximare a unei realitatii prinpostularea unor prezumtii - problema care se pune este alegerea unui model adecvat studiuluiîntreprins. In cazul nostru vom cauta sa alegem acele Modele care slujesc cel mai bineDescrierii cu ajutorul Structurilor de Informatii si Date a domeniilor specifice Sistemelor cuBaze de Date, deci cele care vizeaza memorarea, regasirea, transmiterea si prelucrareaavantajoasa a Volumelor de Informatii si de Date, folosind tehnica sistemelor de calcul. Utilizata în stiinta si tehnica, informatia e greu de definit în toata complexitatea sa. Inlegatura cu definirea riguroasa a notiunii de Informatie, cercetatorul W. R. Ashby [ASBY56]afirma: " Evolutiile în aceste regiuni sunt ca deplasarile într-o jungla plina de gropi-capcana. Cei care stiu cel mai mult despre aceste subiecte sunt si cei mai precauti când vorbesc despre ele. " particula de materie particula de reflectare REALITATE preluare de informatii IMAGINE înconjuratoare reflectata prelucrare de informatii Fig. 3.2.1. Reflectarea realitatii prin informatii Pornind de la schema ilustrata de Fig. 3.2.1, în care se reprezinta relatia existenta întreRealitatea înconjuratoare si Imaginea reflectata în constiinta unui Observator, Informatiapoate fi privita ca o Notiune Primara ce sta la baza procesului de cunoastere, bazat pe
    • 66 Concepte de Baza / Informatie si Dataactivitatea de Reflectare a Realitatii prin Contemplare si Meditatie. Informatiile reprezintametaforic Caramizile cu ajutorul carora constiinta Observatorului recladeste Realitatea dinFapte culese, îmbogatind-o cu Adevaruri Nepercepute si completând-o apoi cu LumiImaginate, Deduse sau Închipuite, ce pot în final sa fie comparate cu RealitateaÎnconjuratoare. Pentru a defini acceptiunea notiunii de Informatie, ce va fi folosita în continuare, vomapela la trei schite de Modele de Definire, pe care le vom prezenta succint în cele ce urmeaza: • Modelul Matematic • Modelul Semiotic • Modelul Propozitional Modelul Matematic reprezinta punctul de plecare în definirea oricarui Model Specificadoptat pentru descrierea Informatiei. Aceasta datorita formularilor cantitative precise, careofera exactitate conceptelor introduse. Modelul Semiotic la care se va apela apoi va permiteprecizarea proprietatilor de natura calitativa ale notiunii de Informatie. Ultimul modelconturat, Modelul Propozitional, este cel mai adecvat activitatii de Prelucrare a Informatiilorsi Datelor, fiind utilizat în special pentru stabilirea diferentelor si asemanarilor dintreconceptele de Informatie si Data.3.2.1 Modelul Matematic Modelul Matematic, elaborat de Hartley si generalizat de Shannon urmarestedeterminarea în exprimare cantitativa a Masurii Gradului de Nedeterminare pe care îl continSistemele Complete de Evenimente. Pornind de la exprimarile calitative: " Informatia este ceea ce elimina o Nedeterminare sau, " Informatia este o Nedeterminare Înlaturata" ,se încearca obtinerea expresiei cantitative a Masurii Gradului de Nedeterminare a unui SistemComplet de Evenimente. Prin Sistem Complet de Evenimente se întelege: Orice Proces X cu n Stari distincte,sau: Orice Experiment X cu n Rezultate distincte,în care sunt cunoscute: n - întreg si pozitiv p(x i ) - Probabilitatile de realizare ale starilorastfel încât : n 0 ≤ p( xi) ≤ 1 si ∑ p ( xi) = 1 1
    • Concepte de Baza / Informatie si Data 67 Daca se noteaza cu: Ex - Masura Gradului de Nedeterminare,altfel exprimat: Cantitatea Medie de Informatie obtinuta prin cunoasterea starii x isau: Entropie Informationalaatunci expresia: Cantitatii Medii de Informatie obtinuta prin cunoasterea Starii x ieste data de formula lui Shannon : n E ( p1 , p2 , ... , pn ) = - ∑ pi log 2 pi i =1 Pentru Evenimente Echiprobabile si n = 2 , Hartley, pornind de la expresia: BI = n unde : n - Numarul Starilor B - Baza Procesului de Cautare prin Divizare I - Cantitatea de Informatiesi de la alegerea unui sistem cu n = 2 Stari, obtine expresia: Cantitatii Elementare de Informatie: I0 = - log 2 1 / 2 = 1 .3.2.2 Modelul Semiotic In cadrul Modelul Semiotic se releva aspecte calitative semnificative ale notiunii deInformatie si anume cele legate de cele trei elemente care intervin în Procesul de Reflectare: - Observatorul ca Interpretor de Mesaj - Sensul în calitate de Continut ce urmeaza a fi transmis, prelucrat sau memorat - Semnul ca Forma Purtatoare a Sensului Ca urmare Informatia va putea sa fie privita din urmatoarele puncte de vedere : - Unul Pragmatic - legat de modul în care Observatorul interpreteaza continutul informational al mesajului
    • 68 Concepte de Baza / Informatie si Data - Unul Semantic - legat de Continutul Informatiei, deci de Sensul acordat mesajului - Unul Sintactic - legat de Forma mesajului care transmite Informatia prin Semne Referitor la aspectele calitative ale Informatiei, mentionam rezultatele publicate înlucrarea [IRIM82] de profesorul clujean Ion Irimie, în care autorul recurge la o Definire prinCaracteristici a Informatiei. Dupa ce preia definirea cantitativa din Modelul Matematic,autorul considera ca definitorii pentru Informatie urmatoarele însusiri: § Opus al Nedeterminarii § Nota Calitativa a Comunicarii Neredondante § Factor Antientropic § Neenergie In ciuda formularii negative a ultimei caracteristicii, care se cere de altfel completata cudefinitia Informatiei din Modelul Matematic si care intervine în prima însusire selectata,retinem modelul propus pentru urmatoarea observatie concluziva facuta de autor: “ Ultimul continut (nenenrgie) devine prioritar prin aceea ca el caracterizeaza cel mai bine specificul informatiei ca entitate de sine statatoare. Informatia ramâne informatie si când este redondanta 100%, caz în care eliminarea nedeterminarii ramâne potentiala sau când, prin abatere de la regula, ea genereaza efecte entropice (prin utilizarea ei eronata în orientarea prin decizie a conduitei ). “ Redam si definitia finala la care se opreste autorul: “ Informatia este entitatea existentiala, care, pe fondul reflectarii, se naste în contextele situatiei semiotice, se instituie în câmpul semnelor si / sau al semnalelor si devine continut si esenta a oricarei comunicari. “3.2.3 Modelul Propozitional Modelul Propozitional este dezvoltat ca o particularizare a celorlalte modeleprezentate, fiind considerat ca fiind cel mai adecvat pentru studiul Structurilor de Informatii siDate si pentru prelucrarea acestora, în special cu mijloace automate. Asemenea modeluluianterior, el preia definirea cantitativa a informatiei din modelul matematic, urmarind sarealizeze particularizarea ei sub aspect calitativ. In acest model Informatia este definita ca: O eliminare de Nedeterminare prin formularea unei Propozitii. Informatia este un cuplu Subiect - Stare (sau Însusire ) rezultat prin selectarea unei Stari (Însusiri) constatate, din multimea Starilor (Însusirilor) posibile si atasarea ei Subiectului aflat în discutie. Întocmai ca si Propozitiile, Informatiile pot fi simple sau compuse, Informatia Simplafiind acea care nu se mai poate descompune în alte informatii, indiferent de cantitatea deinformatie pe care o poarta.
    • Concepte de Baza / Informatie si Data 69 Data este Forma de Reprezentare a Informatiei în vederea transmiterii, înmagazinarii si prelucrarii ei. Datele constituie Suportul Informatiilor. Fiecare Data semnifica o Informatie princuplul care se stabileste între Numele Datei, alcatuind Subiectul si Valoarea Datei,reprezentând Însusirea. Aceleiasi Informatii îi pot corespunde diferite forme de reprezentare prin Date, carepot diferi fie prin Formatul de Reprezentare al Valorilor, fie prin Numele Datelor, fie prinambele. Tab. 3.2.3.1 reda un exemplu sugestiv de reprezentare cu ajutorul Datelor diferite aaceleiasi Informatii: ”Cantitatea-Livrata este 100”. Informatie Data Observatii Nume Valoare Cantitate 100 Tipul Datei: Întreg CantLiv 100 Tipul Datei: Întreg Zecimal Cantitatea-Livrata este 100 Cantitate 1100100 Tipul Datei: Binar CL 64 Tipul Datei: Hexazecimal Cantitate ’Suta’ Tipul Datei: Sir de Caractere Tab. 3.2.3.1 Reprezentarea Informatiei prin Data Valorile Datelor vor reprezenta o Informatie numai în momentul în care sunt atasateunor Nume de Date. Informatia se constituie în plan Semantic, reprezentând Sens, în timp ce Data seconstituie în plan Sintactic, reprezentând Semn. Relatiile între Informatii reprezinta ele însele noi Informatii. Din punct de vedere alnaturii acestor Relatii ele pot fi de doua feluri: - Relatii de Dependenta (Relatii de Echivalenta sau Incluziune) - aceste relatii, specifice proceselor de clasificare, apar ca însusiri reciproce a doua sau mai multe Subiecte (Informatii corespunzatoare Predicatelor Poliadice), fiind apoi transferate, în Sfera Datelor, asupra Numelor de Date, caracterizând raporturile existente între acestea. Exemplu: Structura Ierarhica definita pin Nume (de Entitati si de Atribute): BEEFICIAR (Cod, Nume, ADRESA (Oras, Strada, Numar)) Conduce la Structura Ierarhica de Instantiere, definita pin Valori: Beneficiar 1 - {c1 , n1 , {o1 , s1 , n1 }} Beneficiar 2 - {c2 , n2 , {o2 , s2 , n2 }} Beneficiar 3 - {c3 , n3 , {o1 , s3 , n3 }} ..
    • 70 Concepte de Baza / Informatie si Data Beneficiar n - {cn, nn, {o1 , sn, n3 }} Unde regasim urmatoarele elemente: § Nume de Entitati – BEEFICIAR, ADRESA § Nume de Atribute – Cod, Nume, Oras, Strada, Numar § Nume de Instante – Beneficiar 1, Beneficiar 2, .. § Valori de de Atribute – c1 , n 1 ,o 1 , s1 , n 1 , c2 , n 2 ,o 2 , s2 , n 2 , .. § Valori (Instante) de Entitati – {c1 , n 1 ,{o 1 , s1 , n 1 }}, {c2 , n 2 ,{o 2 , s2 , n 2 }} .. - Relatii de Identitate si de Relatii de Ordine Naturala - aceste relatii apar între Însusiri, respectiv Valori ale Datelor, putându-se apoi transfera si asupra Subiectelor, respectiv a Numelor de Date Exemplul 1 – Relatie de Ordine transferata Sa ordonam Beneficiarii din structura anterioara dupa Oras: { Beneficiar i}| Oras i = ’ o 1 ’ ≡ { Beneficiar 1, Beneficiar 3, .. , Beneficiar n } { Beneficiar j}| Oras j = ’ o 2 ’ ≡ { Beneficiar 2 } Exemplul 2 – Relatie de Identitate transferata Sa consideram o structura de Societati – Partenere (vezi Fig. 4.2.4.8.2.2.5). Fiecare SOCIETATE poate fi privita ca Producator, Beneficiar si / sau Furnizor. Dorim sa identificam SOCIETATILE care au ca Furnizori si Beneficiari acelasi PARTENER. Este suficient sa testam Egalitatea Valorilor Atributului Societate din PARTENER care refera asociativ o SOCIETATE pentru Tipuri diferite de PARTENER ( urnizor si Beneficiar) si sa transferam Egalitatea a F cestor Valori asupra Identitatii Entitatilor SOCIETATI (Nume de Instante de Societati). PARTENER i . Societate = PARTENER j . Societate si PARTENER i . Partener (Conditie de Furnizor) = PARTENER j . Partener (Conditie de Beneficiar) ⇒SOCIETATE m (Conditie de Partener pentru PARTENER i) ≡ SOCIETATE n (Conditie de Partener pentru PARTENER j) In problema diferentei existente între Informatie si Data consideram ca foarteexpresiva si concisa formularea data de cercetatorul Bo Sundgren în [SUND75], pe care oretranscriem: “ Daca o persoana aranjeaza intentionat un obiect al realitatii ca sa -l reprezinte pe celalalt, acest aranjament se denumeste Data. Cel mai adesea Data reprezinta: - în primul rând o Cunostinta umana (Informatie) - doar secundar, Obiectul Propriuzis din realitate care este el .“ In proiectarea Structurilor de Informatii si Date se convine sa se numeasca descriereaunei realitati cu ajutorul informatiilor ca facând parte din Spatiul Informatiilor, iarmodelarea cu ajutorul datelor a unei descrieri prin informatii deja definite, se considera caapartine Spatiului Datelor. Totodata, atât în Spatiul Informatiilor cât si în Spatiul Datelor,descrierea cu ajutorul Numelor se considera ca apartine Nivelului Logic sau Conceptual dereprezentare, în timp ce descrierea cu ajutorul Valorilor se considera ca apartine NiveluluiFizic de reprezentare.
    • Concepte de Baza / Date si Proceduri 713.3 Date si Proceduri Prezentarea Antinomiei Date-Proceduri apare motivata daca avem în vedere faptul cadiferentierea Sistemelor cu Baze de Date de Sistemele Clasice a fost conturata odata cuSepararea Datelor de Proceduri (vezi sectiunea 2.1), caracteristica mentinuta ca dominanta.Sa analizam pentru început principala opozitie dintre aceste doua elemente ale prelucrariiautomate a datelor: § Datele reprezinta Partea Statica a cestui proces – descriu Starile sistemului la un moment date, jalonând totodata evolutia acestuia prin descrierea stadiului în care el a ajuns § Procedurile reprezinta Partea Dinamica a aceluiasi proces – descriu Transformarile care intervin în cadrul sistemului prin intermediul Secventelor de Operatii Exista doua viziuni diferite ale procesului de prelucrare a datelor: o Viziunea Sistemelor Clasice – descrierea Datelor precum si a Procedurilor sunt elementele constitutive ale unitatilor de prelucrare, denumite cel mai general Programe o Viziunea Sistemelor cu Baze de Date – descrierea Datelor este separata de descrierea Procedurilor, prin Zone Specializate de depozitare a descrierierilor, Limbaje Dedicate fiecarui scop, Caracteristici individualizate pentru fiecare sectiune Câstigurile unei asemenea viziuni devin remarcabile, fiind grupate sub numele de – Independenta Datelor fata de Proceduri: § Specializarea Instrumentelor de Lucru § Specializarea Personalului însarcinat cu functiile de Conceptie, Proiectare, Dezvoltare si Întretinere : • Colective de Administrare a Structurilor de Date • Colective de Proiectare a Procedurilor si Aplicatiilor • Colective de Implementare a Sistemelor de Aplicatii § Specializarea Unitatilor de Executie (Statii Server, Statii Client) Nu trebuie neglijat faptul ca aparitia ideii de separare a fost sustinuta si de unele Limbaje Clasice de Programare (Limbajele de Programare folosite în Gestiunea Economica). Actiunea este însa partiala deoarece separarea se efectueaza doar în cadrul sectiunilor de program, fara existenta unui Dictionar al Datelor. D aici e deriva si amestecarea Datelor Interne (Variabilele de Program) cu Datele din Baza de Date (Atribute – Câmpuri de Date). Ceea ce constituie o caracteristica specifica procedurilor în Sistemele cu Baze de Date este renuntarea la Variabilele de Program (utilizate de obicei ca Variabile de Conditie - Switch-uri sau Variabile de Marcare - Flag-uri). Necesitatea utilizarii lor denota în cele mai multe cazuri o insuficienta populare cu Atribute a Structurii de Date din Baza de Date, fapt ce va fi resimtit, mai devreme sau mai târziu în utilizarea BD.
    • 72 Concepte de Baza / Date si Proceduri Asemanarea elementelor Date – Proceduri este tot atât de importanta în Sistemele cuBaze de Date. Ea se manifesta în urmatoarele privinte: o Datele pot fi privite ca Stari Curente – sunt definite declarativ (prin precizarea unei Valori Memorate). In aceasta forma Datele sunt întotdeauna tratate ca Date Reale, date existente în Baza de Date. o Procedurile pot fi privite ca Stari Viitoare – sunt definite functional (prin precizarea unei Functii de Calcul). Valoarea rezultata din calcul poate fi Memorata, luând forma de Data Reala (Redondanta) sau numai Afisata, înfatisându-se ca Data Virtuala (Data care se Instantiaza la Cerere). In aceasta definire Procedurile reprezinta, prin ele însele, Date Virtuale. Functiile de Calcul vor fi în fiecare caz Memorate în Baza de Date si sub aceasta forma ele constituie Date Potentiale. Doar din motive de performanta (economie de timp de calcul) Rezultatele pot fi Memorate, caz în care implica prezenta Redondantei în Baza de Date, cu posibile inconsistente (daca Procedurile de Calcul nu sunt Declansate si Controlate Automat). Se mai poate remarca faptul ca facilitatea de definire functionala a datelor este implementata foarte natural, Functia de Calcul putând fi reprezentata de orice tip de Procedura (Program sau Fragment de Program si chiar Secvente de Operatii sau simple Expresii de Calcul). Pentru ca demersul de acceptare a Procedurilor în familia de Stari Descriptoare ale unui sistem sa fie consemnat mai lipseste un element si acesta este Momentul de Declansare a Procedurilor. Acest moment va fi ales din multimea Evenimentelor pe care sistemul de procesare (Mediul de Programare le recunoaste). Se impune concluzia conform careia Procedurile pot fi privite ca Date în Devenire doar în Mediile de Programare Orientate pe Evenimente. Majoritatea mediilor Client actuale se bucura de asemenea facilitati. Începând cu atasarea Fragmentelor de Proceduri (Snippets) la diferite momente de prelucrare a datelor de intrare (memorate în Componenta Client) si continuând cu Trrigerii si Procedurile Stocate (vezi sectiunea 4.2.4.7.5) memorate direct în Baza de Date, toate acestea reprezinta implementari de Proceduri Declansate pe Eveniment si prin aceasta creeaza mediul prielnic de transpunere în realitate a conceptelor prezentate anterior, ce pot parea la prima vedere Pedanterii Academice. Apropierea Procedurilor de Date face un salt important în construirea unei ViziuniStructuraliste asupra procesului de prelucrare a datelor. Datele si Procedurile sunt privite caStari (Caramizi) din care se construieste sistemul. Completarea ideilor structuraliste este facutaîn sectiunea Structuri de Proceduri. Unghiul de abordare va fi însa diferit. El va încerca sasublinieze, în acel context, necesitatea coborârii conceptului de Structura si în interiorulProcedurilor, pentru ca apoi sa se arate aportul Sistemelor cu Baze de Date în sprijinireaprocesului de Structurare a Procedurilor, pornind de la Structura Datelor supuse prelucrarii.Paralela între cele doua structuri este cu atât mai necesara cu cât în Sistemele cu Baze de DateProcedurile vor migra în Modelul de Date, fiind tot mai frecvent atasate, sub formaFragmentelor de Proceduri, anumitor Structuri de Date, si ramânând definite ca Entitati de sinestatatoare (Obiecte) în Baza de Date. Dar si atunci când ele vor fi destinate prelucrariiCursorilor generati prin Denormalizarea Relatiilor, Structura de Provenienta a acestora vatrebui sa ghideze Structura Procedurilor atasate, pentru a usura construirea si depanarea lor.
    • Structuri de Informatii si Date / Structura, Organizre si Acces 733.4 Structuri de Informatii si Date3.4.1 Structura, Organizare si Acces Spunem ca un ansamblu e Structurat atunci când Multimea sa de Elemente poate fiprivita ca o Multime de Multimi. Altfel exprimat: Orice recunoastere într-o Multime a uneilegaturi de Echivalenta sau Incluziune, alta decât cea primara de apartenenta a elementelor lamultimea data, indica prezenta unei Structuri interne. Întrucât Legaturile de Echivalenta siIncluziune sunt toate Relatii definite pe aceeasi Multime, si cum Legaturile între Multimi suntdescrise tot de Relatii, putem afirma ca orice prezenta a unei Relatii într-un Sistem de Multimiconfirma existenta unei Structuri interne a acelui sistem. Gradul de structurare al unei Multimi de Elemente sau de Multimi depinde de numarulde Submultimi distincte care pot fi definite la un moment dat, precum si de raporturile existenteîntre ele: Legaturi de Echivalenta, Nivele de Incluziune, Domenii de Intersectie etc.Organizarea Elementelor în Submultimi usureaza Controlul Ansamblului (manevrabilitatea sa),dar poate creste, în anumite conditii, Timpul de Acces la elemente. Din acest motiv modul deorganizare a elementelor în multimi si submultimi este, în abordarile traditionale, subordonatscopurilor de prelucrare. Este de mult încetatenita afirmatia ca: “Organizarea aleasa depinde de Accesul dorit.” Dupa cum se va vedea din analiza instrumentelor dezvoltate în proiectarea Bazelor deDate, o desprindere totala de aceasta afirmatie nu este pâna în prezent posibila datoritarestrictiilor impuse de performantele sistemelor de calcul. Cu toate acestea desprindereaamintita a reprezentat, reprezinta si va reprezenta un deziderat important al sistemelor cu Bazede Date, pasi remarcabili fiind deja realizati pe aceasta cale. Specificul colectiilor de Informatiisi Date în cadrul sistemelor cu Baze de Date consta în aceea ca ele sunt aprioric destinate sadeserveasca fie: § Scopuri Multiple § Scopuri Neprecizate initial Aceasta constatare justifica aspiratia specialistilor spre structuri care ofera înainte decalitatea de a fi Bine Organizate, pe cea de a fi Capabile De Reorganizare rapida. Se preferaasadar însusirii de Optimalitate, care e legata de un Criteriu sau de o Lista de Criterii,cunoscuta si ordonata dupa Prioritati, pe cea de Adaptabilitate la Liste de Criterii definiteAdhoc. Pe baza conceptele de Cupluri sau Tupluri, privite ca Multimi Intrinsec Ordonate,Structura implica instituirea unei Ordini într-o Multime de Elemente, prin succesiuneaLegaturilor de Echivalenta si Incluziune, precum si a Legaturilor între Multimi, prin cuplareaacestora. In acest demers orice Structura gata construita poate reprezenta o Înghetare aSistemului de Elemente într-o anumita Ordine Momentana care se poate adeveri ca Temporara,întrucât este generata de o Viziune Partiala asupra Multimii de Elemente. Construirea unei NoiStructuri pornind de la Vechea Structura implica doua operatii principale: - Demontarea Vechii Structuri pentru obtinerea Elementelor constitutive necesare în pasul urmator - Remontarea unei Noi Structuri cu Elementele obtinute în primul pas
    • 74 Structuri de Informatii si Date / Structura, Organizre si Acces Ambele operatii sunt mari consumatoare de timp în cazul Colectiilor Mari de Date (înSBD). Acest inconvenient conduce la dezvoltarea a doua tipuri de abordari în construireaStructurilor de Informatii si Date cu care opereaza Sistemele cu Baze de Date: § Structuri Dedicate – obtinute prin Specializarea domeniului de interes (Spatiul de Informatii) cu limitarea tipurilor de Elemente si Legaturi care urmeaza a fi tratate (ex. Baze de Date Documentare, Baze de Date Finaciare, Baze de Date pentru Tranzactii Comerciale, Baze de Date pentru CAD etc.) § Structuri Generale – destinate Sistemelor cu Utilizare Multipla, privite mai mult ca Surse de Date si mai putin ca si Colectii de Aplicatii predefinite (ex. Baze de Date pentru Sisteme Integrate, Banci de Date etc.) Întrucât conceptele dezvoltate de disciplina de Baze de Date trebuie sa faca fata ambelorcerinte ele vor trebui sa ofere într-un înalt grad capacitatea de Adaptabilitate la Cerinte Noi,initial neprecizate. Solutia propusa este urmatoarea: “Salvarea vine nu din Perfectiunea Structurii, ci din Capacitatea ei de a se Adapta” Altfel exprimat: “ Daca nu exista o Ordine General Valabila pentru Elementele Constitutive, acestea sa fie pastrate în cea mai mare Neordine posibila, pentru a se putea Reorganiza Instantaneu în Ordinea ceruta.” Aceasta valenta este oferita de maxima Independenta a Elementelor Constitutive,concentrata în Elementaritatea descrierii Spatiului de Informatii si Date. Referitor la solutia propusa pentru Construirea si Reconstruirea Structurilor din AtomiStructurali, facem o mica digresiune, pentru a comenta unul din reprosurile facute ModeluluiRelational si care convine problemei aflata în discutie: Eliminarea Relationala a Redondantei Descriptorilor nu se aplica si Identificatorilor, pentru care se promoveaza o acuta Redondanta In Fig. 3.4.1.1 se prezinta comparativ descrierile Ierarhice si Relationale ale structuriiBneficiari – Produse – Contracte. Pot fi facute urmatoarele observatii: o Modelul Ierarhic § Structura este gata Construita (Înghetata) în varianta Ierarhica (BPC) § Structura este Contextuala ceea ce o face Compacta (fara Redondanta de Identificatori) § Orice Reorganizare (de exemplu PBC) necesita demontarea primei structuri § Structura implica Redondanta mare de Descriptori (Descriptorii lui P) § Adaugarea de Restrictii Suplimentare (ex. un singur Produs pentru un Beneficiar) necesita o tratare Procedurala o Modelul Relational § Structura este Elementara (Atomica), în varianta Relationala (B, P, C) § Structura este Necontextuala ceea ce o face Reorganizabila prin schimbarea dinamica a Viziunilor
    • Structuri de Informatii si Date / Structura, Organizre si Acces 75 § Orice Reorganizare (de exemplu P, B, C) este doar o alta Viziune asupra aceleiasi structuri (se modifica doar Ordinea de Inspectie a Relatiei C prin Indecsi adecvati) § Structura implica Redondanta Aparenta de Identificatori, deoarece Componentele Atomice de Structura {bi , pj, ck} au ca Identificator unic Identificatorul Compus din cele trei componente enumerate (acesta este si motivul pentru care Structura ramâne Necontextuala, Componentele pastrându-si Identitatea si în urma unei reamplasari, prin schimbarea Ordinii lor) § Structura nu implica nici-o Redondanta de Descriptori § Adaugarea de Restrictii Suplimentare (ex. un singur Produs pentru un Beneficiar) poate fi rezolvata Structural, prin adaugarea unei Constrângeri de Cheie Candidata (Index unic) pentru combinatia B+P Model Relational Model Ierarhic Intensiune Extensiune Intensiune B BENEFICIAR {b1, b2, .. } BENEFICIAR Cod P Cod Nume {p1, p2, .. } Nume END C PRODUS PRODUS {{b1, p1, c1} Cod Cod {b1, p1, c2} Nume Nume .. CONTRACT END {b1, p2, c1} Numar CONTRACT {b1, p1, c2} Cantitate Beneficiar .. END Produs {b2, p2, c1} END Cantitate {b2, p2, c2} Extensiune END .. {b2, p3, c1} BPC {b2, p3, c1} {{ b1, {p1, {c1, c2, .. }, p2, {c1, c2, .. }, .. }, { b2, {p2, {c1, c2, .. }, p3, {c1, c2, .. }, .. }, .. } .. } Fig. 3.4.1.1 Compararea Redondantei în Modelele de Date Modelul Relational de descriere a Structurilor de Date asigura, în cel mai înalt grad,realizarea Independentei Elementelor cu ajutorul carora se descriu si se prelucreazaStructurile de Date, prin implementarea urmatoarelor Concepte de Independenta: - Interfetele între Nivelele de Abstractizare în descrierea datelor § Interfata între Nivelul Intern si cel Conceptual – asigura Independenta Nivelului Conceptual fata de modificarile din Nivelul Intern § Interfata între Nivelul Conceptual si cel Extern – asigura Independenta Nivelului Extern fata de modificarile din Nivelul Conceptual
    • 76 Structuri de Informatii si Date / Structura, Organizre si Acces § Interfata între Nivelul Extern si Proceduri – asigura Independenta Procedurilor fata de modificarile din Date - Normalizarea Structurilor de Date – asigura Independenta între Atributele descriptoare ale Entitatilor - Propagarea Atributelor de Legatura – asigura Independenta Legaturilor fata de Atributele ce nu sunt de Legatura (nu sunt definite pe Domenii Comune) - Constructor Elementar Unic (Relatia) – asigura Independenta Structurii fata de Constructorul de Structura § Implementare Unica a Claselor de Entitati si a Legaturilor între Clasele de Entitati – asigura Independenta descrierii Legaturilor fata de descrierea Claselor de Entitati § Implementarea oricarui Tip de Structura – asigura Independenta Componentelor de Structura prin implementarea identica a Structurilor de Tip Echivalenta (n – n), a Structurilor de Tip Incluziune – Arborescenta (1 – n) si a Structurile de Tip Incluziune - Retea (m – n) § Modificarea Dinamica a Tipului de Structura – asigura Independenta relativa a Definirii de Structura fata de Specificatiile de Definitie § Implementarea Proceselor de Abstractizare – asigura Independenta Componentelor de Structura prin implementarea identica a Structurilor de Tip Generalizare, precum si a Structurilor de Tip Agregare - Utilizarea Descrierilor Deschise – asigura Independenta Descrierilor Noi fata de Descrierile Vechi - Referirea Asociativa – asigura Independenta Descrierii Fizice (prin Valori) de Suportul de Memorare - Distribuirea Bazelor de Date– asigura Independenta Surselor de Date fata de Localizarea lor pe Statii - Tranzactiile Consistente – asigura Independenta Operatiilor Tranzactionale asupra Bazei de Date Enumerarile facute dau o imagine sugestiva asupra perseverentei cu care Sistemele cuBaze de Date au urmarit fructificarea Ideii de Independenta în construirea structurilor. Este denetagaduit faptul ca multe încadrari în acest principiu sunt facute în urma unor analizeretrospective ale diverselor directii de activitate, urmate doar apoi de sintezele necesare. Acestlucru nu micsoreaza valabilitatea constatarii facute, înca la începutul prezentarii materialului, sianume ca promovarea Principiului de Independenta în Structura este indisolubil legat deSistemele cu Baze de Date, ca aplicarea lui a fost fortata de necesitatea mentinerii controluluiasupra unor Sisteme Complexe, ce reuneau Structuri de Date si de Proceduri, care se cereauaplicate în domenii foarte diverse. Aceste caracteristici ale Modelului Relational, concentrateîn Elementaritatea sa de descriere, reprezinta nu numai motivele extinderii sale prezente însistemele cu Baze de Date, ci si perspectiva mentinerii lui în viitor, ca instrumentul cel maieficient de reprezentare a Colectiilor de Date ce urmeaza a satisface Cerinte initial Incompletesi ulterior Dinamice.
    • Structuri de Informatii si Date / Structura, Organizre si Acces 773.4.1.1 Structura Logica si Fizica Asa dupa cum au fost descrise Nivelele de Abstractizare în Bazele de Date se potremarca doua Nivele de Descriere: - Conceptuala (Logica) – descrierea Datelor prin Nume - Interna (Fizica) – descrierea Datelor prin Valori; aici însa sunt adaugate la datele care prezinta interes direct pentru Utilizator si cele care sunt utile doar pentru Gestionarea Suportului si care contin Informatiile de Control a Suportului Întrucât, referitor la utilizarea termenilor de nivel Logic si Fizic, exista atât în literaturade specialitate, cât si în produsele comerciale, unele utilizari ce pot conduce la ambiguitati,facem urmatoarele precizari legate de Planurile de Descriere a Datelor. Termenii de descriereLogica si Fizica au aparut în legatura directa cu procesarea datelor, adica în Spatiul Datelorunde erau prezente doua categorii de Utilizatori: § Programatorul de Aplicatii – interesat în special de Valorile Datelor înregistrate pe Suport si grupate în asa numite Articole Logice § Programatorul de Sistem – interesat în ansamblul tuturor informatiilor existente pe Suport ( Valori si Date de Control), utile gestiunii eficiente a proceselor de Memorare – Regasire a informatiilor, prin intermediul prelucrarii Blocurilor de Realizari de Articole Logice, numite Articole Fizice Au luat ca urmare nastere termenii prezentati în mod sugestiv în Fig. 3.4.1.1.1, careredau sugestiv implementarea planurilor de descriere Logica si Fizica a Datelor. In schitaîntocmita se face o comparatie de termeni între viziunea de Prelucrare Clasica a Fisierelor sicea preluata si dezvoltata de Bazele de Date: o In Prelucrarea Clasica Programele de Aplicatii opereaza, cu: § Articolele Logice descrise în Programe § Articolele Fizice, atunci când se cere o gestiune a Informatiilor de Control a Suportului o In Bazele de Date: § Nivelul Fizic se rezuma la descrierea prin Valori a Datelor § Prelucrarea Articolelor Fizice este lasata exclusiv în seama Nivelului Intern, deci a Modulelor SGBD-ului, însarcinate cu Gestiunea Structurii Fizice § Nivelul Logic se dezvolta catre o descriere detaliata regrupata în Dictionarul de Date Termenii au reaparut apoi în legatura cu descrierea cerintelor din ce în ce mai complexeale utilizatorului determinate de preluarea maxima de informatie din domeniul lui de interes,deci din Spatiului Informatiilor (din Descrierea Problemei) si ulterior de transpunere a lor înSpatiul Datelor (pentru construirea Modelului de Date celui mai adecvat pentru prelucrare).
    • Concepte de Baza / Structuri de Informatii si Date 78 Legenda DESCRIERE ARTICOL prin N – NUME de DATA NUME DICTIONARE de DATE V – VALOARE de DATA ( ARTICOL LOGIC ) ICA – informatii de CONTROL ARTICOL (SABLOANE de DESCRIERE) ICB – informatii de CONTROL BLOC SB – separator SFARSIT de BLOC Plan N1 N2 . . . . Nn NUME . . Plan VALORIICB1 ICA1 V 11 V 12 . . . . V 1n ICA 2 V 21 V 22 . . . . V 2n . . ICA m V m1 Vm2 . . . V mn SB . . 11 . . . 11 . . 1 REPREZENTARE VALORI ARTICOL LOGIC pe FISIERE de DATE pe SUPORT SUPORT BLOCURI de INREGISTRARI ( INREGISTRARE LOGICA ) REPREZENTARE COMPLETA ARTICOLE LOGICE pe SUPORT (VALORI + DATE de CONTROL = BLOC de INREGISTRARE) ( INREGISTRARE FIZICA ) Fig. 3.4.1.1.1. Implementarea planurilor de descriere Logica si Fizica a Datelor
    • Concepte de Baza / Structuri de Informatii si Date 79 Ambele categorii de Utilizatori chemati sa colaboreze în acest moment: UtilizatorulFinal si Proiectantul de Aplicatie au agreat existenta a doua planuri de descriere: - Descriere Logica – cea care descrie Nivelul Abstract (Descriere Notiuni prin Nume) - Descriere Fizica - cea care descrie Nivelul Concret (Descriere Instante prin Valori) Au luat nastere astfel termenii prezentati cu ocazia prezentarii Nivelelor deAbstractizare în Bazele de Date. Unificarea celor doua acceptiuni de termeni este prezentata întabelul sintetic. 3.4.1.1.2. Elementul Nivelul general Mijlocul Nivelul diferentiat de descriere Descris de descriere de descriere Interpretare Viziune Gestiune ENTITATE LOGIC NUME ENTITATI Informatii NOTIUNE + + RELATII DATE ARTICOL Gestiune LOGIC DATE ENTITATE LOGIC / FIZIC VALORI / + OBIECT ARTICOL FIZIC Proceduri SUPORT FIZIC Reprezentare VALORI Gestiune + ARTICOL FIZIC DATE Date de CONTROL + SUPORT Tab. 3.4.1.1.2 Raportul Structura Logica de Date - Structura Fizica de Date Mentionam ca, desi termenii de Articol Fizic si Articol Logic sunt folositi în prezentdoar în Programarea Clasica, am tinut sa prezentam relatia lor cu termenii din Sistemele cuBaze de Date din doua motive: - Pentru a ilustra cronologia aparitiei si consolidarii anumitor concepte - Pentru a sublinia mai mult apropierea dintre diferite concepte, decât diferentele lor, legate firesc de momentelor de dezvoltare în care au aparut Se poate nota existenta Nivelului hibrid Fizic / Logic (Fizic pentru noua acceptiune,Logic în acceptiunea clasica) în descrierea datelor si care împaca cele doua viziuni, subliniindtotodata faptul ca aceleasi planuri de reprezentare sunt diferit vazute de categorii diferite deutilizatori, în speta Proiectantul de Aplicatie si Programatorul de Sistem. In sectiunea ceurmeaza va fi accentuata importanta ca Utilizatorii, Specialisti sau Utilizatori Finali, sagândeasca în cele doua planuri: - Logic – pentru a le asigura Generalitatea necesara cuprinderii într-un Tot Unitar a unui volum adesea imens de informatii - Fizic – pentru a nu pierde nici o clipa contactul cu Lumea Faptelor, acea Realitate unde se naste si se utilizeaza Informatia si de unde trebuie extrase cerintele reale legate de Modelarea Informatiilor si Datelor
    • 80 Spatiul de Informatii si de Date3.4.1.2 Spatiul de Informatii si de Date Conform definirii conceptelor de Informatie si Data se pot face urmatoarele delimitari: o Spatiul Informatiilor – este alcatuit din ansamblul Informatiilor definite si descrise pe baza Analizei Realitatii (Stari, Fapte, Evenimente, Transformari, Cunostinte), Realitate în care activeaza Utilizatorul si care se cere cunoscuta, modelata si în final adaptata necesitatilor de control al Informatiilor care o descriu; se mai numeste si Spatiul Problemei o Spatiul Datelor – este alcatuit din ansamblul Datelor pe care Proiectantul le alege pentru a transpune Informatiile descrise într-un Model de Date adecvat prelucrarii automate; se mai numeste si Spatiul Calculatorului Neglijând reprezentarea pe suport a datelor se poate ajunge la schema din Fig. 3.4.1.2.1.Dupa cum descrierea este facuta cu ajutorul Numelor sau Valorilor, în fiecare Spatiu se poatedistinge un Nivel Logic sau un Nivel Fizic, grupate în doua Planuri de Descriere distincte. Seremarca faptul ca unui Spatiu de Informatii îi pot corespunde mai multe Spatii de Date(utilizând acelasi Tip de Model de Descriere, sau unul diferit: Ierarhic, Retea sau Relational).Fiecare Plan de Descriere prin Nume poate fi concretizat (instantiat) prin Seturi de Valoridiferite. Aceasta este semnificatia Legaturilor 1 – n, între Structura Logica de Informatii (SLI)si Structura Logica de Date (SLD), respectiv între Structurile Logice de Informatii si de Date(SL) si Structurile Fizice de Informatii si de Date (SF). Reprezentarea punctata a legaturii întreStructurile Fizice de Informatii si de Date trebuie înteleasa ca o Legatura Derivata din cele treiLegaturi Primare: SLI → SFI, SLI → SLD, SLD → SFD. Gruparile efectuate si Raporturile stabilite între acestea permit trecerea la reprezentareadin Fig. 3.4.1.2.2. Prin aceasta ne apropiem de modul în care SBD utilizeaza Spatiile siPlanurile de organizare a Informatiilor si Datelor. Pornind de la prezenta unei multiplicarigenerativa la trecerea între diferitele Planuri si Spatii de realizare a descrierilor, se naste ideeautilizarii unor Produse Specializate pentru Descrierea Nivelelor si pentru Conversia acestorDescrieri. Se ofera astfel un Control riguros al Variantelor de Descriere de pe NiveleleInferioare generate de Descrierile de pe Nivele Superioare. Exista urmatoarele ProduseSpecializate pentru gestiunea Nivelelor: - Nivelul SI - Produse CASE care descriu Modele de Date (Modelere) - Nivelul SLD – Componente ale SGBD care descriu Structura Logica - Nivelul SFD – Componente ale SGBD care gestioneaza Structura Fizica Procese deja consacrate asigura si Conversiile necesare între Nivelele de mai sus: - Conversie SI - SLD – Procesul de Engineering al unui Model de Date - Conversie SLD - SI – Procesul de Reengineering al unui Model de Date - Conversie SLD - SFD – Operatiile de Actualizare ale unui SGBD Lucrul cel mai important de retinut din prezentarea anterioara este faptul ca Sistemelecu Baze de Date nu se opresc la simpla Separare a Nivelelor Logic si Fizic de Descriere, ciprin diferentierile operate între Spatiile Informatiilor si Datelor deschid perspective pentru oProiectare la un Nivel mai Înalt de Abstractizare.
    • Spatiul de Informatii si de Date 81 SPATIUL INFORMATIILOR STRUCTURA LOGICA 1 n STRUCTURA FIZICA de de INFORMATII INFORMATII 1 1 n n 1 n STRUCTURA LOGICA STRUCTURA FIZICA de de DATE DATE SPATIUL DATELOR Planul Planul NUMELOR VALORILOR Fig. 3.4.1.2.2 Spatii si Planuri de descriere a Informatiilor si Datelor Demersurile facute pâna în prezent, începând cu delimitarea diferentelor de acceptiuneîntre Informatie si Data si terminând cu valorificarea raporturilor între diferitele Planuri siSpatii de reprezentare, apare ca foarte utila în procesul de proiectare a sistemelor complexe cuBaze de Date. Precizarea zonelor în care se poarta discutia în timpul realizarii unui Proiect estefoarte importanta din mai multe puncte de vedere, dintre care enumeram: - Utilizarea corecta a Notiunilor Specifice domeniului în discutie - Recurgerea la Instrumentele Consacrate de reprezentare - Redactarea concisa si precisa a Specificatiilor de Definitie - Deducerea cu usurinta a implicatiilor pe care le au modificarile inerente ale Specificatiilor de Definitie Aceste Notiuni vor fi regasite, indiferent de denumire, în produsele care se ocupa cuProiectarea de Nivel Înalt, întelegând prin aceasta formele de proiectare care apeleaza laModele de Date pentru descrierea tot mai directa a Spatiului de Informatii si continuând apoi
    • 82 Spatiul de Informatii si de Datecu Proceduri Automate de Generare a Nivelelor de Descriere corespondente, prin proceduri deEngineering / Reengineering (conform prezentarilor anterioare). Caracteristici de descriere a STRUCTURA de INFORMATII INFORMATIILOR 1 n Caracteristici de descriere a STRUCTURA LOGICA de DATE DATELOR ( STRUCTURA TEORETICA) 1 n Caracteristici de descriere a STRUCTURA FIZICA de DATE SUPORTULUI ( STRUCTURA de STOCARE) Fig. 3.4.1.2.1 Spatiul de Informatii – Structura Logica de Date – Structura Fizica de Date Este demn de remarcat drumul parcurs de Conceptul de descriere prin Nume si prinValoare, de la prima initiativa de Separare a Nivelelor de Descriere a Datelor, pâna lafundamentarea Proiectarii de Nivel Înalt în cadrul Modelelor de Date, Modele ce încorporeazaatât Structura, cât si Restrictiile si Operatiile aferente. Este înca o dovada ca perenitateaSistemelor cu Baze de Date s-a bazat pe selectarea cu atentie a Valorii Conceptelor adoptate,completata cu perseverenta în urmarirea extragerii tuturor Consecintelor Derivate dinvaloarea acestor concepte. Vorbind despre Proiectarea la Nivel Înalt, folosind Modele de Date gasim un prilej de aprezenta diferitele acceptii de termeni, care trebuiesc interpretate de fiecare data cu atentie.Desi în cadrul unui Model de Date nu gasim reprezentat Planul Valorilor, proiectarearezumându-se la Planul Numelor, întâlnim notiunea de Model Logic de Date si Model Fizic deDate. Termenul se refera la raportul 1 – n între SI si SLD. Modelul Logic de Date va descrie înacest caz Structura de Informatii, în timp ce Modelele Fizice de Date vor descrie InstanteleStructurii Logice de Date, generate pentru diferite Platforme de Implementare a Bazei de Date.Aceasta particularizare nu anuleaza notiunile prezentate, care doar îi usureaza întelegerea.
    • Structuri Fundamentale de Informatii si Date 833.4.2 Structuri Fundamentale de Informatii si Date Sectiunea este consacrata prezentarii acelor concepte care ne permit sa abordamproblema construirii de structuri într-un mod sistematic. In primul rând se raspunde laîntrebarea: Care sunt Raporturile între Elementele unei Structuri care se cer implementate? Raspunsul obtinut la aceasta întrebare va fi apoi utilizat pe tot parcursul lucrarii înscopuri foarte diverse: o Pentru determinarea Structurilor Elementare care permit implementarea Raporturilor strict necesare în cadrul unei Structuri de Informatii si de Date. Vor putea fi elaborate astfel Module de Structura a caror combinare s permita a industrializarea construirii de Structuri Complexe. o Pentru obtinerea unui Instrument de Comparatie si de Evaluare a diferitelor Modele de Date utilizate în SGBD-urile existente, modul de implementare a Raporturilor Fundamentale fiind un Criteriu esential. o Pentru determinarea Calitatii Structurilor Proiectate un asemenea Instrument este deosebit de util. El va putea folosi nu numai pentru Evaluarea unui Proiect de Structura, ci mai ales pentru formarea unei Discipline de Proiectare a Structurilor. o Pentru a putea gândi la formele de Construire a Structurilor în viitor, prin apelul la acelasi Instrument de Comparatie si de Evaluare3.4.2.1 Definirea Structurilor Fundamentale Pentru construirea unei Structuri de Informatii sau Date este important sa se cunoascacare sunt Tipurile de Structuri Fundamentale, care se regasesc în orice Multime Particularade Informatii dintr-o Realitate ce se cere modelata. Cunoscând aceste Tipuri de Structuri,împreuna cu modul lor specific de implementare într-un Model de Date aflat la dispozitie,reprezentarea unei realitati prin informatii si date poate deveni un proces de rutina. Tipurile fundamentale de structuri se definesc pornind de la evidentierea Relatiilor deDependenta între Multimile de Elemente ce descriu realitatea. Aceste Relatii de Dependentapot fi de Echivalenta sau de Incluziune. Trei tipuri de Structuri Fundamentale pot fi regasite într-o structura data (vezi Fig.3.4.2.1, Fig. 3.4.2.2 si Fig. 3.4.2.3), daca la dependentele anterioare se adauga si raporturile încare pot sta Multimile Parti (Mi ) ale unei multimi date (M) si anume: o Relatia de Echivalenta o Relatia de Incluziune § De tip Partitie § De tip Acoperire
    • 84 Structuri Fundamentale de Informatii si Date - de Acoperire - UM i i = M - de Partitie - UM i = M si Mi I Mj = ∅ pt. ∀ i si j i Diagrama VENN E E1 n E2 n E3 n E4 n E5 n Structura GRAF E n E4 n E5 n E1 n E2 n E3 n Fig. 3.4.2.1 Structura de tip Echivalenta - Nivel Relatia de Echivalenta decurge din proprietatea de Apartenenta a Elementelor laaceeasi Clasa de Echivalenta.
    • Structuri Fundamentale de Informatii si Date 85 Relatia de Echivalenta implica existenta unei relatii de Incluziune si reciproc relatia deIncluziune implica existenta unei relatii de Echivalenta. In primul caz Incluziunea rezulta dinînsasi existenta unei proprietati comune ce sta la baza definirii Clasei de Echivalenta în cadrulunei Multimi Totale care include aceasta clasa. In mod reciproc recunoasterea unei proprietaticomune de Incluziune implica existenta unei Echivalente între membrii incluziunii aflati laacelasi nivel (între care nu exista nici macar o relatie de Ordine). Aceasta observatie conduce laideea reprezentarii relatiei de Incluziune printr-o legatura între relatii succesive de Echivalenta.Relatia de Echivalenta implica o legatura în plan Orizontal sau pe Nivel (Fig. 3.4.2.1). Aceastaîntrucât ea descrie relatia în care se afla elementele aflate pe acelasi nivel formând o Clasa deEchivalenta generata de aceasta proprietate (multimea E). Dependenta elementelor fata deaceasta multime e luata în considerare doar în masura în care transfera asupra Elementelorproprietatea de Echivalenta. De aici provine si utilizarea liniei punctate pentru reprezentareadependentei Elemente – Multime si totodata denumirea aleasa pentru acest gen de structura -Nivel. S-a considerat mai sugestiva aceasta denumire fata de cea îndeobste folosita deSecventa, care ar implica existenta Ordinii în aceasta structura. Pentru faptul ca aceastaprecizare nu reprezinta o speculatie teoretica, ci un concept ancorat în practica proiectariiStructurilor de Informatii si de Date, pledeaza urmatoarele doua argumente: - Modelul Relational de Date se bazeaza pe proprietatea de Multime a Tuplelor apartinând oricarei relatii, fapt ce implica mentiunea ca Ordinea lor este indiferenta, iar atunci când se cere implementata, aceasta se face prin atasarea la Multimea de Tuple a unei Relatii de Ordine sub forma structurilor auxiliare de tip Index - Daca între Elementele aflate pe acelasi Nivel de ascendenta într-o Structura Ierarhica se doreste utilizarea unei Relatii de Ordine, aceasta trebuie implementata cu un Atribut destinat acestei proprietati si anume Ordinea pe Nivel Relatia de Incluziune (Fig. 3.4.2.2 si Fig. 3.4.2.3) implica o legatura în plan Verticalsau în Adâncime (pe mai multe Nivele). Aceasta relatie implementeaza întotdeauna în planVertical o Relatie de Ordine. Aceasta relatie de Ordine este într-adevar Partiala pentru ca, asacum s-a precizat deja, relatia de Incluziune defineste totodata la fiecare Nivel de descendentaClase de Echivalenta descrise de proprietatea : Toate Elementele ce au acelasi Ascendent Relatiile de Incluziune se descompun în doua categorii, în functie de NumarulAscendentilor: o Incluziune de tip Arborescenta – structura cu Ascendent Unic, de Tip Partitie o Incluziune de tip Retea– structura cu Ascendent Multiplu, de Tip Acoperire In timp ce Relatia de Echivalenta corespunde unei legaturi de Coordonare întreElemente, Relatia de Incluziune corespunde legaturilor de Subordonare. De asemenea, în timp ce Relatia de Incluziune implementeaza legatura de Posesiune: Un Posesor – O multime de Obiecte PosedateRelatia de Echivalenta implementeaza doar legatura de Alaturare de Elemente: Elemente de acelasi Fel
    • 86 Structuri Fundamentale de Informatii si DateDiagrama VENN E E1 n E2 n E‘ " E3 n E ‘’ E4 n E5 nStructura GRAF E n E‘ n E’’ n E4 n E5 nE1 n E2 n E3 n Fig. 3.4.2.2 Structura de tip Incluziune - Partitie
    • Structuri Fundamentale de Informatii si Date 87 Aceste doua tipuri de legaturi (Echivalenta si Incluziunea) vor reapare în toateStructurile de Informatii si de Date la care se va face referire în continuare. Atât Legatura dePosesiune cât si cea de Alaturare pot primi concretizari semantice dintre cele mai diferite. Dinprima categorie mentionam una foarte des întâlnita si anume cea de: Compus – Componente.Relatia de Echivalenta se defineste ca legatura care exista între Elementele apartinând aceleiasiMultimi, iar relatia de Incluziune ca legatura între Elementele Multimii si Multimeapropriuzisa privita ca Element la alt Nivel. Prezinta interes o alta Antinomie între cele douatipuri de legaturi. Este vorba despre implementarea relatiilor: are (has) si este (is a).Echivalenta implementeaza operatia de Clasificare prin stabilirea unor Clase de Echivalenta. Semai spune ca implementeaza prin legatura Clasa de Echivalenta – Elemente, relatia GenProxim – Diferenta Specifica. Relatia de Incluziune implementeaza operatia de generare noiobiecte prin Agregare de Componente. Sa analizam însusirile tipurilor de structuri la care amajuns si pe care le consideram unice si prin aceasta fundamentale în construirea structurilor. o Nivelul § Se descrie ca un Arbore Simplu cu un singur Nivel (Fig. 3.4.2.1), deoarece se considera ca aceasta reprezentare este cea mai semnificativa pentru descrierea relatiei de Echivalenta § Legaturile Clasa de Echivalenta – Elemente nu intereseaza decât în masura în care defineste Proprietatea Comuna, întrucât relatia se manifesta între Elemente (de aceea ea mai e definita ca o legatura n – n) § Legatura n – n este diferita de cea m – n (many to many). Prima este o structura de tip Echivalenta, cea de a doua de tip Incluziune § Legatura n – n înlocuieste structura de tip Secventa folosita în literatura de specialitate. Recunoasterea ei este stric necesara în cadrul unei abordari exhaustive a Structurilor Fundamentale § Tipul de structura Nivel subliniaza Omogenitatea elementelor în relatie de Echivalenta § Legatura se considera desfasurata pe Orizontala (pe Nivel). § Tipul de structura este considerat Structura Primara (prin opozitie, celelalte tipuri de structuri vor fi denumite Structuri Evoluate). La prima vedere acest tip de structura indica mai degraba absenta structurii, decât prezenta ei. A fost însa tratat ca prima forma de structurare întrucât relatia pe care o defineste determina recunoasterea în cadrul unui ansamblu de elemente a unei Proprietati Comune (a unei Multimi), proprietate considerata importanta din punct de vedere a prelucrarii elementelor (aceasta proprietate difera de cea de banala apartenenta la ansamblul initial de elemente, care reprezinta Multimea Totala, prin aceea ca ea determina recunoasterea Elementelor ca fiind de Acelasi Fel pentru prelucrarea lor ulterioara) § Implementeaza operatia de Coordonare sau Alaturare de elemente § Este utilizata ca Structura de Baza în multe Modele de Date (ex. Modelul Relational, Modelul Obiectelor Abstracte etc.)
    • 88 Structuri Fundamentale de Informatii si Date o Arborescenta § Se descrie ca un Arbore Simplu cu mai multe Nivele (Fig. 3.4.2.2), structura Ierarhica care implementeaza legatura 1 – n (datorita Unicitatii Ascendentului). § Reprezinta o structura Verticala indicând o descompunere pe Nivele, în care toate Elementele de pe un Nivel sunt legate de un singur Element de pe un Nivel superior (Structura de Tip Partitie) § Implementeaza o semantica de tip Posesor – Membri Posedati: Un Ascendent ca Posesor are n Descendenti ca Membri § Structura în Profunzime pe care o implementeaza se pastreaza si pentru cazul n = 1, când legatura ia caracterul particular 1 – 1. § Tipul de structura subliniaza Heterogenitatea elementelor în Relatie de Incluziune (diferenta între Elementul Posesor si Elementele Posedate) § Implementeaza operatia de Subordonare Simpl a între elementele de pe nivele diferite. o Reteaua § Se descrie ca un Arbore Invers cu mai multe Nivele (Fig. 3.4.2.3), structura Ierarhica care implementeaza legatura m – n (datorita Neunicitatii Ascendentului). § Reprezinta o structura Verticala indicând o descompunere pe Nivele, în care toate Elementele de pe un Nivel sunt legate de unul sau mai multe Elemente de pe un Nivel superior (Structura de Tip Acoperire) § Implementeaza o dubla semantica de tip Posesor – Membri Posedati: Un Ascendent ca Posesor are n Descendenti ca Membri Un Descendent ca Posesor are n Ascendenti ca Membri § Tipul de structura subliniaza Heterogenitatea elementelor în relatie de Incluziune (diferenta între Elementul Posesor si Elementele Posedate) § Implementeaza operatia de Subordonare Multipl a între elementele de pe nivele diferite. In Fig. 3.4.2.4 este data în recapitulare o sinteza a Tipurilor de Structuri Fundamentale.Apreciem ca deosebit de utila cunoasterea Constructorilor (Modulele care implementeazaStructurile Fundamentale) cu care trebuie sa opereze proiectantul de structuri în vedereagarantarii unui punct de pornire sanatos al oricarui Sistem cu Baza de Date. Indiferent care estetipul de Model de Date utilizat pentru construirea Structurii de Date, stabilirea modului deimplementare a Constructorilor de Structuri Fundamentale ramâne esential pentru calitateafinala a oricarui proiect. O prezentare detaliata a Construirii Structurilor de Date este rezervatapentru sectiunea 4.2.4.8, cu referire la Modelul de Date Relational.
    • Structuri Fundamentale de Informatii si Date 89Diagrama VENN E E1 n E2 n E‘ " E3 n E ‘’ E4 n E5 nStructura GRAF E E‘ E’’ E4 n E5 n E1 n E2 n E3 n Fig. 3.4.2.3 Structura de tip Incluziune - Acoperire
    • Structuri Fundamentale de Informatii si Date 90 de tip relatie ECHIVALENTA structura n-n raport de NIVEL structura orizontala PRIMARA pe orizontala COORDONARE relatie raport de STRUCTURI 1 -n SUBORDONARE pe verticala SIMPLA ARBORESCENTA de tip ascendent unic PARTITIE de tip structura INCLUZIUNE structura verticala EVOLUATA relatie raport de m-n SUBORDONARE pe verticala MULTIPLA RETEA de tip ascendent neunic ACOPERIRE Fig. 3.4.2.4. Structuri Fundamentale
    • Transformarea Structurilor Fundamentale 913.4.2.2 Transformarea Structurilor Fundamentale Transformarea Structurilor Fundamentale reprezinta o operatie de baza în exploatareaModelelor de Informatii si de Date. Ea vizeaza legatura directa între operatiile de Organizare siAcces referitoare la Colectiile de Informatii si de Date si ofera o metoda riguroasa de asigurarea performantelor de Acces, fara a compromite calitatea pretinsa Organizarii Colectiilor aflate îndiscutie. Poate fi de asemenea recunoscuta sorgintea ideii de separare a Structurilor în: - Structuri Principale – care contin informatiile propriuzise, cele care intereseaza Utilizatorul Final - Structuri Secundare – care asigura doar alegerea strategiei dorite de Acces la Date Termeni ca si cel de Cheie de Inversare (Inversion Key), prezenti nu numai înliteratura de specialitate, dar si în produse de notorietate, dovedesc ca subiectul legat deTransformarea Structurilor Fundamantale nu este o preferinta teoretica, ci o motivare aconceptelor a caror paternitate apartine Bazelor de Date, dintre care amintim: o Perfectionarea Modelelor de Date pe care sunt construite succesiv Sistemele de Gestiune ale Bazelor de Date o Dezvoltarea Indecsilor ca Structuri Anexe performante de Acces si nu de Organizare a Colectiilor de Date3.4.2.2.1 Tipuri de transformari Vom analiza Tipurile de Transformari aplicate Colectiilor de Date în sensul de cresterea calitatii Organizarii precum si a performantelor de Acces. Aceasta evolutie se petrece prinaplicarea succesiva a aceluiasi proces de Inversare a structurilor. Sa consideram urmatoarea Colectie de Informatii care descrie Clasa de EntitatiSTUDENTI: STUDENTI Marca Nume Vârsta Localitate M1 N1 V3 L2 M2 N2 V2 L1 M3 N3 V1 L2 M4 N4 V3 L3 M5 N5 V1 L1 Fig. 3.4.2.2.1.1 Colectie de Informatii STUDENTI Sa mai observam ca Marca poate reprezenta cu succes Identificatorul Colectiei de Date,întrucât Numele, desi în extensia reprezentata în Fig. 3.4.2.2.1.1 este unica, în cazul generalaceasta supozitie nu se verifica. Celelalte caracteristici (Nume, Vârsta si Localitate) seconstituie ca si Descriptori ai Clasei de Entitati.
    • 92 Transformarea Structurilor Fundamentale Identificatorul unei Colectii de Date este candidat pentru organizarea unei Chei Primare,denumita si Criteriu Primar sau Index Primar. Datorita aplicatiei bijective ce exista întremultimea Valorilor Identificatorului si multimea Instantelor din Colectie, Cheia Primara e ceamai performanta cale pentru: § Accesarea datelor § Validarea unicitatii instantelor Pentru a efectua aceste functie Identificatorul trebuie construit ca o Colectie Secundarade tip Index (vezi Fig. 3.4.2.2.1.2.1). Este de remarcat faptul ca o Colectie de Date poate avea mai multi Identificatori(Identificatori Candidati). Dintre acestia unul este ales ca Primar, ceilalti ramânândSecundari Iau nastere ca urmare o Cheie Primara si eventual mai multe Chei Secundare (CheiCandidate). Clasificarea Cheilor în Primare si Secundare iau în considerare doar criterii deuzualitate în ceea ce priveste regasirea informatiilor pornind de la valorile Cheii de Cautare: § Disponibilitate § Lungime § Usurinta de Memorare § Obisnuinta Utilizatorului3.4.2.2.1.1 Eliminarea Redondantei La cresterea volumului colectiei STUDENTI, numarul Localitatilor de Resedintadiferite nu va creste în aceeasi masura ceea ce va determina aparitia si cresterea redondantei înColectia de Date. Eliminarea redondantei se poate face prin separarea colectiei initiale în douacolectii: STUDENTI si LOCALITATI, conform Fig. 3.4.2.2.1.1.1. STUDENTI Marca Nume Vârsta Localitate Referinta M1 N1 V3 R-L2 M2 N2 V2 R-L1 M3 N3 V1 R-L2 M4 N4 V3 R-L3 M5 N5 V1 R-L1 LOCALITATI Localitate L1 L2 L3 Fig. 3.4.2.2.1.1.1 Eliminarea Redondantei
    • Transformarea Structurilor Fundamentale 93 In Colectia STUDENTI atributul Localitate va fi înlocuit cu o Referinta la noua colectiecreata. Desigur ca în noua Colectie atributele descriptoare ale LOCALITATILOR pot sasporeasca (Tip, Cod Postal, Judet etc.). Apare implicit posibilitatea unei economii de spatiu, Ingeneral lungimea referintei fiind inferioara celei a denumirii (fara a lua în considerare si ceilaltidescriptori adaugati Intre timp), dar câstigul principal consta în mentinerea ConsistenteiDatelor, prin memorarea într-un singur loc a informatiei: Denumirea Localitatii. Rezultatotodata o crestere a timpului de acces la caracteristica eliminata din colectie, prin necesitateaunui dublu acces la ambele Colectii, dar câstigul realizat prin garantarea Consistentei Datelorjustifica aceasta pierdere. Noua colectie de date regrupeaza Valorile Izotipe (vezi sectiunea4.1.1.3.4) din structura definind, pe multimea STUDENTILOR, Ansambluri de Entitati: vezisectiunea 4.1.1.3.5) - STUDENTII având aceeasi LOCALITATE de resedinta.3.4.2.2.1.2 Inversarea Partiala (Indexarea) Aparitia noii colectii creeaza însa si un alt avantaj în afara Eliminarii Inconsistentei sianume sugerarea posibilitatii de a modifica Strategia de Acces la Date: o Strategia 1 – Acces de la Entitate la Caracteristica (Fig. 3.4.2.2.1.1.1 – acces de la STUDENT la Localitate) o Strategia 2 – Acces de la Caracteristica la Entitate (Fig. 3.4.2.2.1.2.1 - acces de la LOCALITATE la STUDENTI) LOCALITATI Localitate Student Referinta L1 R-S2 R-S5 L2 R-S1 R-S3 L3 R-S4 STUDENTI Marca Nume Vârsta M1 N1 V3 M2 N2 V2 M3 N3 V1 M4 N4 V3 M5 N5 V1 Fig. 3.4.2.2.1.2.1 Inversarea Partiala (Indexarea) Pentru a realiza aceasta inversare de strategie de acces referinta între colectii se mutadin STUDENTI în LOCALITATI . Se asigura totodata si un acces nu doar la o Instanta(Entitate Obiect), ci la o Multime de Instante (toti Studentii cu aceeasi Localitate de
    • 94 Transformarea Structurilor FundamentaleResedinta). Aceasta se realizeaza prin inspectia tuturor Referintelor atasate unei Valori dinColectia Secundara de tip Index. Solutia acestei grupari a referintelor aduce însa si douainconveniente importante, ce provin din numarul variabil al Valorilor Izotipe din STUDENTI(Studenti din aceeasi Localitate): o Prezenta Instantelor de Lungime Variabila în Colectia Secundara LOCALITATI o Actualizarea dificila a Colectiei Index (LOCALITATI) Termenul de Inversare îsi are originea în procedura initiala prin care se asigura aceastamodificare de strategie prin Inversarea Ordinii de Sortare a Colectie Principale (Ordinea deSortare dupa Identificatorul de Student e înlocuita cu Localitatea de Referinta). Clasa de Entitati LOCALITATI poarta denumirea de Index Secundar sau Cheie deInversare (Inversion Key), pentru Clasa de Entitati STUDENTI, spre deosebire de IndexulPrimar definit anterior (Marca). Colectiile de Date de tip Index pot fi: o Dense – când Realizarile (Instantele) Colectiei Secundare refera fiecare Entitate Obiect (Realizare sau Instanta) din Colectia Principala. Altfel zis – pentru a ajunge la oricare Instanta din Colectia Principala se inspecteaza doar Colectia Index care ofera o Referinta pentru fiecare înregistrare (Instanta) din Colectia Principala. In acest caz se zice ca Indexul are o Intrare pentru fiecare Instanta din Colectia Principala. o Nedense – când Realizarile (Instantele) Colectiei Secundare refera un Ansamblu de Entitati Obiect (Realizari sau Instante) din Colectia Principala. Altfel zis – pentru a ajunge la oricare Instanta din Colectia Principala se inspecteaza întâi Colectia Index apoi Grupul de Instante din Colectia Principala. In acest caz se zice ca Indexul are o Intrare pentru fiecare Grup de Instante din Colectia Principala. Se numesc Puncte de Intrare în Colectia de Date Principala Instantele Colectiei deDate Index (fiecare Pereche de Date: (Vi , Rj) Valoare de Caracteristica – Referinta la oInstanta din Colectia Principala). Denumirea de Dens, Nedens se foloseste si atasata direct Indecsilor.Exemple Indecsi Densi – Indecsii din Fig. 3.4.2.2.1.2.1si Fig. 3.4.2.2.1.4.1. Indecsi Nedensi – Indexul din Fig. 3.4.2.2.1.3.1 si Fig. 3.4.2.2.1.3.23.4.2.2.1.3 Eliminarea Redondantei + Inversarea Partiala Ideea combinarii celor doua metode survine imediat, întrucât prin aceasta se oferaambele strategii de acces, pornind de la Entitate sau de la Caracteristica (Fig. 3.4.2.2.1.3.1 siFig. 3.4.2.2.1.3.2).
    • Transformarea Structurilor Fundamentale 95 In prima varianta transformarea nu face decât sa puna laolalta cele doua metodeprecedente, asigurând posibilitatea accesului si de la STUDENTI la Localitatea de Resedinta,dar si de la o LOCALITATE la toti STUDENTII având Resedinta în aceasta Localitate.Numarul Variabil de Referinte se pastreaza în colectia LOCALITATI, complicând gestiuneaei. STUDENTI Marca Nume Vârsta Localitate Referinta M1 N1 V3 R-L2 M2 N2 V2 R-L1 M3 N3 V1 R-L2 M4 N4 V3 R-L3 M5 N5 V1 R-L1 LOCALITATI Localitate Student Referinta L1 R-S2 R-S5 L2 R-S1 R-S3 L3 R-S4 Fig. 3.4.2.2.1.3.1 Eliminarea Redondantei + Inversarea Partiala (Varianta 1) Pentru a înlatura inconvenientul mentionat mai sus se înlocuiesc referintele dinLOCALITATI cu referinte între Instantele din STUDENTI. In acest fel, Înregistrarile înambele Colectii ramân de Lungime Fixa. Modificarea transforma Colectia de DateLOCALITATI din Index Dens (LOCALITATI în varianta 1 în Nedens ( OCALITATI în ) Lvarianta 2). Un anume STUDENT dintr-o LOCALITATE data va fi localizat prin douainspectii: - Inspectia Colectiei Secundare LOCALITATI pentru o anume Localitate - Inspectia Colectiei Principale STUDENTI pornind de la Referinta din LOCALITATI (Referintele cu linie întrerupta) si continuând cu Referintele la Entitatile Obiect (Instantele) STUDENTI (Referintele punctate) Prin aceasta modificare de structura se obtin urmatoarele efecte:Avantaje: - Structura de Date care descrie Referintele devine din Statica (Vectori de Valori) Dinamica (Liste de Articole) - Actualizarea Referintelor devine mai comoda, prin Alocarea Dinamica de Spatiu de Memorare, odata cu înregistrarea noilor instante în Colectia Principala
    • 96 Transformarea Structurilor FundamentaleDezavantaje: - Creste Numarul Acceselor la regasire (se inspecteaza ambele Colectii de Date) - Durata parcurgerii Listelor de Referinte poate deveni critica - Necesitatea dublarii Referintelor în Lista de Referinte (înlantuire directa si inversa) în cazul actualizarilor frecvente (în special Stergeri) LOCALITATI Localitate Student Referinta L1 R-S2 L2 R-S1 L3 R-S4 STUDENTI Marca Nume Vârsta Localitate Localitate Referinta Referinta Izotipa M1 N1 V3 R-L2 R-S3 M2 N2 V2 R-L1 R-S5 M3 N3 V1 R-L2 - M4 N4 V3 R-L3 - M5 N5 V1 R-L1 - Fig. 3.4.2.2.1.3.2 Eliminarea Redondantei + Inversarea Partiala (Varianta 2) Aceasta structura a fost introdusa de Modelul Retea, reprezentând primii pasi pe caleaobtinerii Structurilor de Date Integrate de tip m - n.3.4.2.2.1.4 Inversarea Totala Inversarea Totala duce la o structura care a câstigat interes pe masura cresteriiperformantelor de procesare a datelor, în special în ceea ce priveste gestionarea simultana amai multor Colectii de Date. Se reia ideea de Indexare simpla, care se repeta pentru toatecaracteristicile care descriu Colectia Principala. Se spune în acest caz ca s-a realizat InversareaTotala a Colectiei de Informatii întrucât s-a asigurat câte un Punct de Intrare pentru fiecareValoare a fiecarei Caracteristici. Pentru a nu pierde avantajul mentinerii ambelor Strategii deAcces, în Colectia Principala se cere mentinerea tuturor caracteristicilor descriptoare, chiardaca aparent aceasta sugereaza o mare redondanta. (Faptul ca nu este vorba despre redondantaîn acest caz îl justifica observatia ca Structura de Informatii este descrisa doar de Colectia
    • Transformarea Structurilor Fundamentale 97Principala, Colectiei Secundare revenindu-i întotdeauna doar rolul de a descrie Strategiile deAcces. STUDENTI Marca Nume Vârsta Localitate M1 N1 V3 L2 M2 N2 V2 L1 M3 N3 V1 L2 M4 N4 V3 L3 M5 N5 V1 L1 MARCI Marca Student Referinta M1 R-S1 M2 R-S2 M3 R-S3 M4 R-S4 M5 R-S5 NUME Nume Student Referinta N1 R-S1 N2 R-S2 N3 R-S3 N4 R-S4 N5 R-S5 VARSTE Vârsta Student Referinta V1 R-S3 R-S5 V2 R-S2 V3 R-S1 R-42 LOCALITATI Localitate Student Referinta L1 R-S2 R-S5 L2 R-S1 R-S3 L3 R-S4 Fig. 3.4.2.2.1.4.1 Inversarea Totala
    • 98 Transformarea Structurilor Fundamentale Din motive de claritate s-a evitat reprezentarea grafica a referintelor. In aceasta noua structura preocuparile de performanta sunt legate doar de perfectionareaStructurilor Secundare în care ideile de tratare a Valorilor Izotipe prin Liste de Referintegaseste un câmp fertil. Prin aceasta structura s-au obtinut urmatoarele efecte:Avantaje: - Structura de Date dispune de maximum de Puncte de Intrare în Colectia Principala - Se întrevede si posibilitatea modificarii dinamice a Caracteristicilor de Inversare chiar în timpul procesarii datelor din Colectia PrincipalaDezavantaje: - Spatiul necesar Colectiilor Secundare depaseste în general pe cel al Colectiei Principale In practica se foloseste, din motive de performanta, o Inversare Partiala în careUtilizatorul îsi alege singur Caracteristicile de Inversare generând si eliminând ColectiileSecundare atasate, chiar si în timpul proceselor de prelucrare. Aceasta structura a fost cu succes promovata de Modelului Relational, fiind proprieStructurilor de Date Integrate.3.4.2.2.1.5 Reorganizarea Structurii Aceasta metoda de transformare se concentreaza asupra Colectiei Principale în careopereaza modificari de structura prin segmentarea Entitatilor. Se ajunge la descriereaSecvential Ierarhizata a unei Structuri Ierarhice. Operatia consta în parcurgerea în Preordinea unui Arbore de Structura si alocarea pentru fiecare Nod a unei Entitati de descriere adecvata.Pentru detalii a se vedea Viziunile Partiale descrise în Spatiul de Informatii la Utilizator(sectiunea 3.4.4). Localitate Marca Nume Vârsta L1 M2 N2 V2 M5 N5 V1 L2 M1 N1 V3 M3 N3 V1 L3 M5 N5 V1 Fig. 3.4.2.2.1.5.1 Reorganizarea Structurii Aceasta Structura de Date sta la baza Modelului Ierarhic, stimulând concepereaProcedurilor de Prelucrare organizate pe Aplicatii Independente.
    • Transformarea Structurilor Fundamentale 99 Remarcile care se pot face aici sunt urmatoarele:Avantaje: - Deschide drumul spre întelegerea necesitatea de a crea Viziuni Partiale asupra unui Ansamblu de Informatii, prin Transformarea Structurilor - Este capabila sa foloseasca Medii de Memorare cu Performante ReduseDezavantaje: - Modificarea Ordinii de Acces la Date implica Reorganizari de Structura, adaptate fiecarei Viziuni Particulare, ceea ce implica timpi mari de prelucrare, care devin prohibitivi când se opereaza cu volume mari de date - Absenta posibilitatilor de combinare a Strategiilor de Acces descrise anterior3.4.2.2.2 Generalizarea Conceptului de Inversare Este deosebit de instructiva urmarirea procesului de Transformare a Structurilor îndomeniul Structurilor Fundamentale. Am vazut ca la baza procesului de Transformare aStructurilor sta operatia de Inversare care poate fi redefinita prin generalizare în trei moduri: - In cazul Structurilor Fundamentale: § Inversarea – este un proces de Structurare (crestere a Calitatii unei Structuri) prin stabilirea în cadrul unei Mutimi date a unor Clase de Echivalenta - In domeniul Structurilor de Informatii descrise în Spatiul Entitate-Caracteristica- Valoare definitia poate fi refrazata astfel: § Inversarea – este un proces de determinare a Valorilor Izotipe Identice pentru Caracteristicile unei Structuri de Informatii In general Inversarea poate fi privita ca o simplificare a descrierii unui ansamblu prinidentificarea unor Parti Comune si scoaterea lor în Factor. Aceste Parti Comune trebuieprivite ca niste Invarianti ai ansamblului, care odata evidentiati cristalizeaza StructuraAnsamblului. Fixându-ne în domeniul structurilor Fundamentale putem face urmatoareleconstatari: § Structura de tip Arborescenta poate rezulta dintr-o structura de tip Nivel prin aplicarea unei operatii de Inversare § Structura de tip Retea poate rezulta dintr-o structura de tip Arborescenta prin aplicarea aceleiasi operatii de Inversare Aceasta necesita descoperirea unor elemente comune în Entitatile structurii de tipinferior. In caz de esec Structura de Tip Inferior (Nivel respectiv Arborescenta) nu poate fitransformata în Structura de Tip Superior (Arborescenta respectiv Retea). Se regasesc astfel cele trei tipuri de Structuri Fundamentale definite anterior: § Nivel – Structura Primara § Arborescenta – Structura Evoluata de grad I
    • 100 Transformarea Structurilor Fundamentale § Retea – Structura Evoluata de grad II In Spatiul Datelor procesul de Inversare sta la baza Indexarii Colectiilor de Date, acarei implementare da Nota de Performanta a oricarui Sistem de Gestiune a Bazelor de Date.Observatii: Poate fi facuta urmatoarea comparatie între Modelele de Date utilizate în SGBD: o Modelul Ierarhic § Arborescenta pentru Colectiile Principale • Confera rigiditate Structurii de Date datorita necesitatii de refacere a Contextului prin inspectia secventiala a Segmentelor § Retea pentru Colectiile Secundare • Limiteaza accesul la nivelul Segmentelor din Colectia Principala o Modelul Retea § Retea pentru Colectiile Principale • Mentine rigiditate în Structura de Date prin inspectia secventiala a Listelor de Articole (Setului) § Retea pentru Colectiile Secundare • Limiteaza accesul la nivelul Articolelor Principale o Modelul Relational § Nivel pentru Colectiile Principale • Asigura simplitatea Colectiilor Principale • Ofera flexibilitate în inspectia si extinderea Colectiilor Principale § Retea pentru Colectiile Secundare • Asigura accesul la nivelul Tuplelor Simple sau de Legatura • Maxim dinamism în crearea, modificarea si refacerea Colectiilor Secundare Toti Operatorii Relationali sunt definiti doar pe Structura Simpla a Colectiei Principale (Multime de Tuple Neordonate, de Valori Elementare). Structura de tip Retea prezenta în Colectiile Secundare nu afecteaza cu nimic simplitatea structurii Modelului Relational întrucât Colectiile Secundare nu intervin niciodata în construirea structurilor relationale, care se bazeaza exclusiv pe Referirea Asociativa. Prin aceasta se mentine totodata independenta fata de Suportul de Memorare al Structurii de Date, Colectiile Secundare putând sa fie refacute în orice moment prin operatia de Reindexare a Structurii Principale. Consecintele acestei caracteristici se regaseste în faptul ca orice portare de Structura Relationala pe alt suport de memorare este asigurata prin copierea doar a Structurii Principale (eventual a Expresiilor de Indexare atasate acestor colectii), Colectiile Secundare, de tip Index fiind apoi refacute pe noul suport.
    • Reprezentarea Structurilor de Informatii si de Date 1013.4.3 Reprezentarea Structurilor de Informatii si de Date Reprezentarea Structurilor de Informatii si Date se refera la utilizarea unor instrumentecare formalizeaza descrierea concentrata, dar totodata fidela a continutului în Informatii si Dateal unor Spatii de Reprezentare destinate a preciza: - Specificatiile de Definitie ale unor Cerinte ce se cer îndeplinite de un Proiect, cerinte ce se nasc în Spatiul Utilizatorului (Spatiul Informatiilor) - Modelul de Reprezentare a Datelor în vederea prelucrarii lor cu ajutorul unor instrumente adecvate de calcul Ca metode generale de reprezentare se folosesc cel mai adesea metodele grafice,datorita caracteristicilor lor de: § Expresivitate § Precizie § Conciziune § Simplitate Dintre metodele cele mai des folosite în descrierea Sistemelor cu Baze de Dateprezentam urmatoarele: o Reprezentarea Fizica o Reprezentarea Logica (Simbolica) o Arborele de Structura o Diagrama Entitati– Relatii o Schema de Descriere Pentru întelegerea termenilor utilizati în descrierea simbolurilor grafice se vor faceadesea referiri la notiunile prezentate în detaliu in sectiunea 4.1.1. De aceea o reluare aprezentei sectiuni, dupa parcurgerea sectiunii mai sus amintita, este binevenita.3.4.3.1 Reprezentarea Fizica (Reprezentarea Clasica) In reprezentarea Fizica se utilizeaza descrierea Structurilor cu ajutorul Valorilor, caredesemneaza Entitatile Obiect, denumite si Instantele (Realizarile) de Entitati Notiune, precumsi Legaturile de Structura existente între Elementele Concrete cu care se opereaza pentrurezolvarea unei probleme date. De aici provin si principalele caracteristici ale acestei forme dereprezentare, constituite atât ca avantaje cât si ca dezavantaje: - Precizia de reprezentare, chiar a situatiilor complicate sau delicate - Expresivitatea care permite întelegerea usoara a specificului fiecarui element în parte, precum si a legaturilor dintre ele - Comunicarea simpla, directa si rapida între utilizatori diversi ca pregatire - Grad mare de detaliu, cu extinderea pronuntata a reprezentarilor integrale
    • 102 Reprezentarea Structurilor de Informatii si de Date Aceste reprezentari pot fi extinse de la simpla prezenta a relatiilor de Incluziune siEchivalenta, la rafinarea Echivalentelor în Disjunctive si Conjunctive, Incluziunile în Partitiisi Acoperiri s.a.m.d. Reprezentarea se bazeaza pe prezenta Entitatilor Obiect vazute succesiv ca: - Elemente individuale (Ascendenti) - Multimi de Elemente (Descendenti) Entitate Obiect ≡ Clasa de Entitati Obiecte - ascendent - Entitate Obiect ≡ Entitate Obiect ≡ Entitate Obiect ≡ Clasa de Entitati Obiecte Clasa de Entitati Obiecte Clasa de Entitati Obiecte - descendent / ascendent - - descendent / ascendent - - descendent / ascendent - Entitate Obiect Entitate Obiect - descendent - - descendent - Fig. 3.4.3.1.1. Reprezentarea Fizica Reprezentarea se poate continua pâna când se ajunge la Elemente Nedecompozabile. Utilitatea reprezentarilor este limitata la lamurirea detaliilor de structura, în special încazurile neclare sau controversate, cum ar fi: Partajarea Elementelor, Nivelele Variabile deDescendenta pe ramuri diferite, Semantica Legaturilor de Descendenta, Modul de Identificare(Contextuala sau Necontextuala) etc. Metoda se foloseste pentru reprezentarea StructurilorFizice de Informatii si Date.Exemplu Fig. 3.4.3.1.2 ofera un exemplu de utilizare a metodei Fizice de descriere a uneistructuri de Informatii în cazul Structurii Organizatorice a unei unitati de învatamânt superior.Particularitatile de structura pe care le releva detaliile reprezentarii Fizice în exemplul analizatsunt: - Se poate distinge o Structura Organizatorica Administrativa a Anilor si Grupelor de Studenti - Structura Organizatorica Administrativa nu poate satisface toate cerintele didactice de constituire a Formatiilor de Studiu - Formatiile de Studiu asigura necesitatile de regrupare a studentilor pentru: o Instruirea în cadrul Trunchiurilor Comune de Studiu
    • Reprezentarea Structurilor de Informatii si de Date 103 o Redistribuirea pe Formatii pentru Optiuni de Studiu (Limbi Straine, Educatie Fizica, Specialitati etc.) Se evidentiaza faptul ca structura poate fi privita ca o Padure de Arbori, fiecareArbore putând sa fie extras prin filtrare cu ajutorul unei conditii prestabilite ( tructura SOrganizatorica sau / si Structura Didactica). U F1 F2 F3 FS 1 FS 2 P1 P2 P3 P1 P2 P3 P1 P2 P3 A1 A2 A3 A1 A2 A3 A1 A2 A3 G1 G2 G3 G1 G2 G3 G1 G2 G3 S1 S2 S3 Sn S1 S2 S3 SnLegenda U – Universitate A- An de Studenti FS – Formatie de Studiu F – Facultate G – Grupa de Studenti P – Profil S - Student Fig. 3.4.3.1.2. Structura unei Universitati în Reprezentare Fizica3.4.3.2 Reprezentarea Logica (Reprezentarea Simbolica) In reprezentarea Logica se utilizeaza descrierea cu ajutorul Numelor, pentruprecizarea Entitatilor Notiune, care desemneaza totodata, în forma potentiala, Clase deEntitati Obiecte, precum si Legaturi de Structura între Entitatile Notiune definite anterior.Forma potentiala de reprezentare a Clasei de Entitati Obiecte, sugereaza faptul ca populareaClasei de Entitati cu Instante (Entitati Obiecte) se va face doar la încarcarea cu Valori a Bazeide Date. La acestea se adauga si constatarea ca Multimea Valorilor de Instanta este în continuaschimbare prin operatiile de actualizare a Bazei de Date, fara ca Entitatea Notiune atasata sasufere vreo modificare. Neglijarea Planului de Valori în reprezentarea Simbolica introduce unNivel mai Abstract de descriere a Caracteristicilor Esentiale ale Structurii, prin accentuareaGeneralului, odata cu omiterea Particularului.
    • 104 Reprezentarea Structurilor de Informatii si de Date Conventiile de reprezentare se reduc la cele continute în Fig. 3.4.3.2.1. n - Entitate Notiune – numele Entitatii Notiune, Entitate Notiune ≡ care reprezinta si Clasa potentiala de Clasa potentiala de Entitati Entitati Obiecte Obiecte - n – Numarul estimat de elemente în Clasa de Entitati Obiecte - Sageata Continua – Legatura Fundamentala 1 n între Entitati Notiuni i - n – Numarul de elemente în Clasa de Ansambluri de Entitati Obiecte Membri (unul sau mai multi Membri) m n - m - Numarul de elemente în Multimea Proprietarilor unei Clase de Ansambluri de Entitati Obiecte Membri (unul sau mai multi i Proprietari) - i – Descrierea Intensionala (prin Nume) a 1 n relatiei între Entitatile Notiuni (poate fi în general subînteleasa) i - Sageata Punctata – Legatura Derivata între m n Entitati Notiuni i Fig. 3.4.3.2.1 Conventiile grafice de reprezentare a Schemei Simbolice Caracteristici acestei forme de reprezentare sunt: - Conciziunea de Reprezentare, chiar pentru spatii mari de cuprindere - Putine Conventii de Reprezentare a specificului Caracteristicilor si Legaturilor - Comunicarea Rapida între utilizatori cu o pregatire relativ redusa Reprezentarea se bazeaza pe prezenta Entitatilor Notiune vazute simultan ca: - Elemente Abstracte (Entitati Notiune) - Multimi Potentiale de Elemente Concrete (Clase de Entitati Obiect) Conventiile folosite conduc la reprezentari de forma celei din Fig. 3.4.3.2.2. Utilitatea reprezentarilor este foarte generala, datorita conciziei si expresivitatii sale. Sefoloseste pentru reprezentarea Structurilor Logice de Informatii si Date. Pornind de la numelecercetatorului care a introdus aceasta metoda de reprezentare pe scara larga în activitatea de
    • Reprezentarea Structurilor de Informatii si de Date 105proiectare, în cadrul laboratoarelor firmei IBM, formalismul mai poarta si numele deDiagrama Bachman. 1 n Entitate Notiune 1 ≡ Entitate Notiune 2 ≡ Clasa potentiala de Entitati Clasa potentiala de Entitati Obiecte 1 Obiecte 2 i 1 m 1 i i n n i n n 1 Entitate Notiune 3 ≡ Entitate Notiune 4 ≡ Clasa potentiala de Entitati Clasa potentiala de Entitati Obiecte 3 Obiecte 4 i 1 n i Fig. 3.4.3.2.2 Reprezentarea Simbolica In legatura cu specificarea semnificatiei Descrierii Intensionale (i) s-a facutobservatia ca ea poate în general sa fie subînteleasa în acele scheme de reprezentare în care nerezumam exclusiv la descrierea Naturii Legaturilor, în termenii Legaturilor Fundamentaleîntre Informatii si Date. Atunci când între doua Entitati Notiune apar Legaturi Multiple acestease cer diferentiate semantic prin Legaturi Concretizate, fapt ce determina si necesitateaimplementarii lor separate. Diferentierea se realizeaza cu ajutorul Descrierii Intensionale, carepoate fi ca urmare: o Generala – descrie doar natura Legaturii între Posesor si Membri ca de exemplu: § Legaturi 1 – 1 § Legaturi 1 – n § Legaturi m – n o Concreta – precizeaza un raport expres între Posesor si Membri ca de exemplu: § m Ascendenti au n Descendenti § 1 Document are n Rânduri § 1 Producator are 1 Adresa § 1 Grupa are n Studenti § 1 Unitate este de n Tipuri Legaturile de tip Are si Este pot descrie Semantica Legaturii în termenii ModeluluiObiectelor Abstracte, care utilizeaza facilitati de Abstractizare de genul urmator: - Agregare - descrisa de o legatura de tip Are - Generalizare sau Categorisire - descrisa de o legatura Este
    • 106 Reprezentarea Structurilor de Informatii si de Date Exista si alte categorii de Legaturi Generale a caror semnificatie poate fi cuprinsa înDescrierea Intensionala rafinând-o semantic, cum ar fi implementarea Rolurilor Abstracte aSubtipurilor de Clasificare (Disjuncte sau Nedisjuncte) etc. Când declararea unor asemeneaLegaturi, mai profund descrise, dispune de Conventii Precise de Implementare, continutulcrescut în informatii al reprezentarii poate fi în mod automat transpus în Structurile de Dategenerate. Produsele Evoluate de Modelare permit si Descrierea Orientata a IntensiuniiLegaturilor: - Legatura Directa – de la Entitatea 1 la Entitatea 2 (1 Grupa are n Studenti) - Legatura Inversa – de la Entitatea 2 la Entitatea 1 (1 Student apartine la 1 Grupa) 1 U 1 1 n n d d 3 2 F 1 FS d 1 1 1 d n n 5 A d d 1 d n n n d 3 1000 G S 1 nLegenda U – Universitate A - An de Studenti FS – Formatie de Studiu F – Facultate G – Grupa de Studenti d – Legatura de Descendenta P – Profil S - Student Fig. 3.4.3.2.3 Structura unei Universitati în Reprezentare SimbolicaExemplu Ca exemplificare se apeleaza la aceeasi structura organizatorica a unei unitati de învatamânt superior, ilustrata în Reprezentare Logica în Fig. 3.4.3.2.3. Utilizarea aceluiasi exemplu permite evidentierea diferentelor între celor doua tipuri de reprezentari. In reprezentarea din exemplu, întrucât apar doar Legaturi de Descendenta, mentionarea expresa a semnificatiei lor poate fi omisa ceea ce descarca schema de repetari de descrieri.
    • Reprezentarea Structurilor de Informatii si de Date 1073.4.3.3 Arborele de Structura Arborele de Structura utilizeaza tot reprezentarea cu ajutorul Numelor, deci ceaspecifica Nivelului Logic. Particularitatea acestei metode de reprezentare consta în orientareaei spre implementarea descrierilor din Spatiul de Informatii în Modelele specifice SpatiuluiDatelor. Urmarind aceste deziderate formalismul va desemna caracteristicile ce descriu NivelulConceptual al Modelului de Date ales pentru implementarea Structurilor de Informatii.Conventiile de reprezentare sunt cele din Fig. 3.4.3.3.1. - Cerc – Relatie n - R - Numele Relatiei R - n – Numarul estimat de tuple în relatie - Punct – Atribut al Relatiei - a – Numele Atributului a - Asterisc – Constituent de Identificator al Relatiei, Cheie Primara sau Candidata (toti i * - Constituentii aceleiasi Chei vor porni din acelasi punct, marcând astfel Identificatorii Relatiei) i – Nume Constituent de Identificator - Linie Continua – Legatura de Agregare Relatie- Atribut - Sageata Punctata – Legatura Relationala între Cheie Straina si Cheie Primara - Linie Punctata – Legatura Relationala între Atribute Comune Fig. 3.4.3.3.1 Conventiile grafice pentru Arborelui de Structura în varianta Relationala Reprezentarile prin Arbore de Structura sunt destinate Structurilor Logice de Date,indiferent de Modelul de Date utilizat (Ierarhic, Retea, Relational etc.). Conventiile grafice,care contin reprezentari nu numai pentru Entitati, ci si pentru Caracteristicile lor componente,vor fi însa diferit interpretate în Modele diferite, în special în ceea ce priveste LegaturileSpecifice între Caracteristici, legaturi care construiesc structura si anume: - Legatura Ierarhica între Segmente (Fig. 4.2.2.1.3) - Legatura de tip Lista între Articolele din Set (Fig. 4.2.3.1.2) - Legatura Relationala între Relatii (Fig. 3.4.3.3.4)
    • 108 Reprezentarea Structurilor de Informatii si de DateExemplu: Ca exemplificare se apeleaza la aceeasi Structura de Date, ilustrata în Reprezentarile Fizice si Logice anterioare. Se va urmari în continuare modul de transformare într-o reprezentare în Model Relational de Date a acestor structuri definite în Spatiul de Informatii (pentru lamuriri vezi si sectiunea 3.4.4.3). Sa consideram în reprezentare concentrata Entitatile Notiune si Legaturile dintre ele (Fig. 3.4.3.1.8). o 1 nU – Entitate UNITATE m 300 o – Legatura Organizatorica d U s d – Legatura Didactica f – Legatura Functionala s – Legatura Derivata de Structura n 1 n f Fig. 3.4.3.3.2 Structura unei Universitati în reprezentare Simbolica Concentrata Este de notat faptul ca în aceasta noua forma de reprezentare a aceluiasi Spatiu de Informatii (Fig. 3.4.3.2.3) apar urmatoarele particularitati: - Se mentine dezinteresul fata de Forma de Implementare a Legaturilor între Entitati, aceste detalii fiind transferate în Modelul de Date - Apare ca strict necesara Descrierea Intensionala Nuantata a Legaturilor între Entitati, prin aceasta recuperându-se o parte importanta a continutului de informatii ce se cere cunoscut Înainte de a ajunge în Spatiul Datelor trecem printr-o forma intermediara de Reprezentare Simbolica a Structurii Logice de Date prin figurarea si a altor Entitati: o Relatia de Legatura STRUCTURA (S) care va permite Implementarea Relationala a Legaturilor de Structura (Ascendenta si Descendenta) o Relatiile TIP UNITATE (TU) si TIP STRUCTURA (TS) care vor permite Clasificarea Claselor de Entitati descrise de Relatiile UNITATE si STRUCTURA Se obtine Diagrama din Fig. 3.4.3.3.3, unde se observa: o Transformarea Legaturilor de Descendenta (Organizatorice, Didactice si Functionale) pe U în Legaturi de Ascendenta si Descendenta între U si S o Mentinerea Legaturii Induse (Derivate) pe U (Legatura m – n) o Aparitia Legaturilor de Clasificare (c) între TU si U, respectiv între TS si S
    • Reprezentarea Structurilor de Informatii si de Date 109 sU – Entitate UNITATE m nTU – Entitate TIP UNITATES – Entitate STRUCTURATS – Entitate TIP STRUCTURA 300 c 50 Ud – Legatura de Descendenta TU n 1 • - Organizatorica • - Didactica • - Functionala 1 1a – Legatura de Ascendenta d a • - Organizatorica n • - Didactica e • - Functionalas – Legatura Derivata de Structura 1500c – Legatura de Categorisire n 1 5 S TS c Fig. 3.4.3.3.3 Structura unei Universitati în reprezentare Simbolica Extinsa Modelul de Date la care se ajunge în final este reprezentat în Fig. 3.4.3.3.4. Legaturile din Diagramele Simbolice se transforma aici in Legaturi Relationale implementate prin Referirea Asociativa între Atribute Comune: o U. t → TU. i – Semantica: Unitatile de un Tip & Tipul unei Unitati o S. t → TS. i – Semantica: Structurile de un Tip & Tipul unei Structuri o S. uc → U. i – Semantica: Descendentii unei Unitati & Ascendentul unei Unitati o S. ua → U. i – Semantica: Ascendentii unei Unitati & Descendentul unei Unitati Arborele de Structura ca metoda de reprezentare face parte, dupa cum s-a mentionatînca de la începutul sectiunii, din categoria Reprezentarilor Logice, întrucât cuprindecaracteristicile specifice Modelului de Date, descrise prin Nume. El va fi ca atare utilizat pentrudescrierea Spatiului Datelor în Plan Logic. Deoarece vor exista caracteristici specifice fiecaruiModel de Date vor exista ca urmare si simboluri particulare de reprezentare a acestorcaracteristici. Ceea ce trebuie retinut în finalul exemplificarilor legate de ultima metoda dereprezentare descrisa sunt urmatoarele observatii: - Arborele de Structura se refera la Modelul de Date utilizat pentru prelucrarea datelor cu ajutor SGBD-ului (în speta un Model de Date Relational) - In spatele acestui Model de Date sta o viziune corespunzatoare a Spatiului de Informatii, adica un Model de Informatii, modificat fata de prima Reprezentare Simbolica ; el este redat în Fig. 3.4.3.3.2 si Fig. 3.4.3.3.3
    • 110 Reprezentarea Structurilor de Informatii si de Date - Exista nu numai mai multe Modele de Date corespunzatoare unui Model de Informatii, ci si mai multe Modele de Informatii corespunzatoare unor Viziuni diferite ale aceleiasi Realitati supuse analizei - Procesul de transformare a unei Viziuni în Spatiul Informatiilor într-o Viziune în Spatiul Datelor poarta numele de Transformare Directa (Proces de Engineering), vezi secventa de reprezentari continute în Fig. 3.4.3.3.2, Fig. 3.4.3.3.3 si Fig. 3.4.3.3.4. - Procesul de modelare poate parcurge si un drum Invers, din Spatiul Datelor spre Spatiul de Informatii, în acest caz având de a face cu o Transformare Inversa (Proces de Reengineering), vezi secventa precedenta în ordine inversa U TU * t * i n i n a TS S uc n * ua i * * t Relatii Atribute U – UNITATE i – Identificator S – STRUCTURA UNITATII t – Tip TU – TIP UNITATE n – Nume (Universitate, Facultate, Profil, Specializare, An, Grupa) a - Adresa TS – TIP STRUCTURA uc – Unitate Curenta (Organizatorica, Didactica, Functionala) ua – Unitate Ascendenta Fig. 3.4.3.3.4 Structura unei Universitati reprezentata prin Arbore de Structura Procesele de Transformare a Structurilor între Nivelele diferite de Reprezentare,vizeaza ansamblul componentelor care descriu un Model de Informatii si de Date (Structura,Restrictii, Operatii). Pentru detalii vezi sectiunea 4.2, precum si explicatiile referitoare la Fig.4.2.4.8.3.2.6.
    • Reprezentarea Structurilor de Informatii si de Date 1113.4.3.4 Diagrama Entitati – Relatii In reprezentarea Entitati - Relatii sunt continute aceleasi elemente ca si înReprezentarea Simbolica, dar se folosesc simboluri diferite, care încearca sa atraga mai multatentia asupra prezentei Legaturilor ca elemente de aceeasi importanta ca si Entitatile. n - Entitate Notiune – numele Entitatii Notiune, Entitate Notiune ≡ care reprezinta si Clasa potentiala de Entitati Clasa potentiala de Entitati Obiecte Obiecte - n – Numarul estimat de elemente în Clasa de Entitati Obiect m n - Romb cu linie continua – Legatura între doua I1 i I2 Entitati Notiune - n – Numarul de elemente în Clasa de Ansambluri de Entitati Obiect Membri (unul sau mai multi Membri) m n - m - Numarul de elemente în Multimea I1 i I2 Proprietarilor unei Clase de Ansambluri de Entitati Obiect Membri (unul sau mai multi Proprietari) - i – Descrierea Intensionala (prin Nume) a I3 Legaturii între Entitatile Notiune - Ii – Intrare în Legatura (Entitate Notiune) 1 1 m n - Romb cu intrari multiple – Legatura între mai I1 i I2 mult de doua Entitati Notiune (maxim patru) n 1 - 1, n , m – Cardinalitatea Legaturilor Adiacente - i – Decrierea Intensionala (prin Nume) a m n Relatiei Polinare între Entitatile Notiune - Ii – Intrare în Legatura (Entitate Notiune) I4 m n I1 i I2 - Romb cu linie punctata – Legatura Derivata între Entitati Notiune - Aceleasi Conventii ca în cazul Legaturilor m n Principale I1 i I2 Fig. 3.4.3.4.1 Conventiile grafice de reprezentare a Diagramei Entitati - Relatii Aceasta varianta de reprezentare obliga pe utilizator sa înscrie în simbolul grafic atasatRelatiei de Legatura Numele acestei Legaturi, informatie care va putea fi direct transportataîntr-un produs care se ocupa în mod special cu Modelarea Datelor (ex. ERWIN, RATIONAL
    • 112 Reprezentarea Structurilor de Informatii si de DateROSE, CAEN, VISIO etc.) si care va utiliza în descriere inclusiv Intensiunile L egaturilor.Conventiile de reprezentare utilizate în cadrul acestei metode sunt cele din Fig. 3.4.3.4.1.Exemplul 1: Ca exemplificare se aplica noua metoda pentru reprezentarea structurilor din Fig. 3.4.3.3.2 si Fig. 3.4.3.3.3. Consideratiile legate de continutul informatiilor reprezentate ramân valabile si în acest caz. Au rezultat schemele din Fig. 3.4.3.4.2, Fig. 3.4.3.4.3. 1 n o 300 n m U d sU – Entitate UNITATE 1 n o – Legatura Organizatorica d – Legatura Didactica f – Legatura Functionala 1 n s – Legatura derivata de Structura f Fig. 3.4.3.4.2 Structura unei universitati în reprezentare Entitati – Relatii (Varianta 1) Reprezentarea cu ajutorul Legaturilor Binare aduce cea mai mare precizie în metodaEntitati – Relatii, întrucât permite evidentierea pentru fiecare Legatura între Entitati a: § Descrierii Intensionale § A Cardinalitatii (Tipului 1 –1, 1 – n, m – n) Utilizarea Legaturilor Polinare efectueaza o concentrare a reprezentarii, din care se potdeduce, prin descompunere Relatiile Binare implicate. Din reprezentare lipseste marcareaEntitatii de Legatura, care reprezinta Produsul Cartezian al celorlalte Entitati. O Solutie înacest caz ar putea fi cea d orientare a liniilor care intra si care ies din Romburile de Legatura.Necesitatea acestei precizari rezulta din exemplul ilustrat în Fig. 3.4.3.4.3.Exemplul 2: Se urmareste reprezentarea unei structuri care descrie Rezultatele la Examene aleStudentilor. Structura se realizeaza cu urmatoarele Entitati si Legaturi: - Se pleaca de la trei Relatii de tip Entitate, ce pot fi privite ca Domenii de Definire a relatiei finale
    • Reprezentarea Structurilor de Informatii si de Date 113 • DISCIPLINA • PROFESOR • STUDENT - Se genereaza o Relatie de Legatura continând Rezultatele la Examene • NOTA - N ⊆ P x D x S m n s 300 n 1 50 U c TU U – Entitate UNITATE 1 1 TU – Entitate TIP UNITATE S – Entitate STRUCTURA TS – Entitate TIP STRUCTURA d – Legatura de Descendenta - Organizatorica, Didactica, Functionala d a a – Legatura de Ascendenta - Organizatorica, Didactica, Functionala s – Legatura derivata de STRUCTURA c – Legatura fundamentala de CATEGORISIRE n n 1500 n 1 5 S c TSFig. 3.4.3.4.3 Structura unei Universitati în reprezentare Entitati – Relatii (Varianta 2) Pot fi facute urmatoarele observatii legate de reprezentarea din Fig. 3.4.3.4.4: - S-au impus urmatoarele Restrictii: § Se considera o singura Nota la o Disciplina, neglijându-se Forma de Examinare (Scris, Oral, Proiect, Lucrari Practice etc.) § Se accepta ca un Profesor poate preda mai multe Discipline si o Disciplina poate fi predata de mai multi Profesori
    • 114 Reprezentarea Structurilor de Informatii si de Date § Se accepta ca un Profesor examineaza mai multi Studenti si un Student e examinat de mai multi Profesori - Se remarca prezenta urmatoarei Restrictii Derivate: § O Nota e data de un singur Profesor, la o singura Disciplina, unui singur Student - Pentru Legatura Polinara (r) si pentru Legaturile Binare Derivate (dp, ps, nd, ns, np) rezulta Cardinalitatile specificate în Diagrama din Fig. 3.4.3.4.4 - Daca Relatiile Binare au si descriptori proprii, ele vor trebui materializate prin Relatii de Legatura corespunzatoare 800 dp P ps m m 1 n 1 m 1 400 n n 10000 r np D S 1 1 n 1 n n 1 n 30000 n nd ns NP – Entitate PROFESOR r – Legatura polinara REZULTATED – Entitate DISCIPLINA dp – Legatura binara derivata DISCIPLINE / PROFESORS – Entitate STUDENT ps – Legatura binara derivata STUDENTI / PROFESORN –Entitate NOTA nd – Legatura binara derivata NOTE / DISCIPLINA N ⊆ PxDxS ns – Legatura binara derivata NOTE / STUDENT np – Legatura binara derivata NOTE / PROFESOR Fig. 3.4.3.4.4 Rezultatele la Examene în reprezentare Entitati – Relatii
    • Reprezentarea Structurilor de Informatii si de Date 1153.4.3.5 Schema de Descriere Reprezentarea unei Structuri de Date cu ajutorul Schemei de Descriere se bazeaza pedefinirea unui limbaj specializat, denumit Limbaj de Descriere Date (LDD), care sa permitaprecizarea tuturor Elementelor (Obiectelor) care descriu o Baza de Date. Grupate pe Categoriiacestea sunt urmatoarele: o Elemente ce descriu Structura (Tabele de Baza, Atribute, Vederi) o Elemente ce descriu Restrictii § Restrictii de Identitate (Chei Primare, Chei Candidate) § Restrictii de Referire (Chei Straine) § Constrângeri (Limite de Valori, Valori Compatibile, Restrictii semantice) o Elemente ce descriu Operatii (Definire Proceduri Stocate, Triggeri)Exemplu Se exemplifica metoda de reprezentare pentru structura din Fig. 3.4.3.4.4: RELATION PROFESOR (Marca, Nume, Prenume, Functie, Titlu); PRIMARY KEY (Marca); RELATION STUDENT (Marca, Nume, Prenume, Grupa); PRIMARY KEY (Marca) RELATION DISCIPLINA (Cod, Denumire, Fel); PRIMARY KEY (Cod); CANDIDATE KEY (Denumire) RELATION EXAMEN (Profesor, Disciplina, Student, Nota); PRIMARY KEY (Profesor, Disciplina, Student); FOREIGN KEY (Profesor REFERENCES Profesor.Marca) ; FOREIGN KEY (Disciplina REFERENCES Disciplina.Cod); FOREIGN KEY (Student REFERENCES Student.Marca); CHECK (Nota >= 1 and Nota <=10) Fig. 3.4.3.5.1 Rezultatele la Examene – Schema de Descriere Initial un instrument de declarare a continutului unei Baze de Date, Limbajul deDescriere a Datelor a fost pe parcurs înlocuit cu Interfete Interactive de introducere, stergere simodificare dinamica a continutului Bazei de Date Logice. Ridicat Intre timp la un nivel avansatde standardizare, LDD îsi m entine în prezent un important rol în descrierea continutului uneiBDL în vederea asigurarii urmatoarelor activitati de administrare a Bazei de Date: - Salvarea / Restaurarea continutului unei BDL - Conversia (Transferul) continutului unei BDL între diferite SGBD-uri
    • 116 Structuri de Informatii la Utilizator3.4.4 Structuri de Informatii la Utilizator In aceasta sectiune se încearca sa se prezinte într-un mod sugestiv noutatea pe care oaduc Sistemele cu Baza de Date în ceea ce priveste organizarea Structurilor de Informatii. Seva putea vedea de ce o multime de Colectii de Date poate sa nu satisfaca gradul de integrarecerut de o Baza de Date. De asemenea va apare deslusit faptul ca Informatiile sunt continutenu doar în Entitati si Atribute, ci si în Legaturile între Entitati. Se insista în final asupra noiiViziuni asupra Spatiului propriu de Informatii pe care Utilizatorul trebuie sa o dobândeasca.3.4.4.1 Structura de Ansamblu Sa consideram nucleul informatiilor dintr-un compartiment de Vânzari, alcatuit din treiCategorii de Informatii: Beneficiari, Produse si Contracte. Atributele care descriu acesteColectii de Date sunt redate mai jos: o BENEFICIARI – Categorie de Informatii ce descrie Partenerii Comerciali interesati în cump ararea unor Produse. Atributele care caracterizeaza aceasta Clasa de Entitati sunt: - Cod - Telefon - Nume - Banca - Tip Societate - Cont - Adresa - Etc. o PRODUSE - Categorie de Informatii ce descrie Produsele în care Beneficiarii sunt interesati. Atributele care caracterizeaza aceasta Clasa de Entitati sunt: - Cod - Greutate - Denumire - Stoc - Pret - Calitate - Culoare - Etc. o CONTRACTE - Categorie de Informatii ce descrie Documentele Comerciale (Contractele) care stau la baza relatiilor de Vânzare – Cumparare. Atributele care caracterizeaza aceasta Clasa de Entitati sunt: Antet Document Rânduri Document - Beneficiar (Codul Beneficiarului) - Produs (Codul Produsului) - Numar Contract - Cantitate Contractata - Data Contract - Pret de Livrare - Clauze Contractuale - Termen de Livrare - Etc. - Etc. In cele ce urmeaza CONTRACTELE vor fi reprezentate de Antet, în timp ce Informatiile din Rânduri vor descrie Pozitiile Contractuale (vezi Fig. 3.4.4.1.1).
    • Structuri de Informatii la Utilizator 117 Categoriile de Informatii sugerate în enumerarea precedenta vor putea fi completate, dela caz la caz cu alte detalii. O structura reala însa implica un numar mult mai mare deInformatii care sa rafineze descrierea. Pentru a putea urmari demersul legat de desprindereanoutatii pe care o aduce viziunea Structurilor de tip Baza de Date ne vom rezuma doar lainformatiile de baza (Fig. 3.4.4.1.1), prezentate în contextul consemnarii urmatoarelor Fapte: o Beneficiarul B1 a stabilit Relatiile Comerciale din Contractele {C1 , C3 } § Contractul C1 contine Pozitiile Contractuale referitoare la Produsele {P1 } § Contractul C3 contine Pozitiile Contractuale referitoare la Produsele (P1 , P2} o Beneficiarul B2 a stabilit Relatiile Comerciale din Contractele {C2 } § Contractul C2 contine Pozitiile Contractuale referitoare la Produsele {P1 , P2, P3 } PRODUSE BENEFICIAR I P1 n n Obligatii n n Contractuale P2 B1 P3 n n n B2 C1 n C3 n C2 n Relatii Contractuale CONTRACTE Pozitii Contractuale Fig. 3.4.4.1.1 Structura de Informatii în compartimentul Vânzari Din aceste Informatii Primare iau nastere urmatoarele Informatii Derivate: o Pentru Beneficiarul B1 rezulta Obligatiile Comerciale referitoare la Produsele {P1 , P2 }
    • 118 Structuri de Informatii la Utilizator o Pentru Beneficiarul B2 rezulta Obligatiile Comerciale referitoare la Produsele (P1 , P2 , P3 } Din Fig. 3.4.4.1.1 rezulta prezenta în Spatiul Informatiilor a doua tipuri de informatii: - Informatii descriptive ale Categoriilor (Grupurilor) definite: • BENEFICIARI • PRODUSE • CONTRACTE - Informatii de Legatura între Categoriile de Informatii definite: § Relatii Contractuale – consemnarea în cadrul unui CONTRACT a conditiilor generale de livrare catre un anume BENEFICIAR B i are Legaturile Contractuale din C j § Pozitii Contractuale – specificarea în cadrul CONTRACTELOR a conditiilor detaliate de livrare pentru fiecare PRODUS C i are Pozitiile Contractuale pentru P k § Obligatii Contractuale – centralizarea pe PRODUSE a sarcinilor de livrare catre fiecare BENEFICIAR Fata de B i sunt consemnate Obligatiile Contractuale pentru P k Luând în considerare si modul în care iau nastere informatiile în Spatiul de Informatii sepoate realiza o categorisire a acestora. o In domeniul Categoriilor de Informatii: § Categorii de Informatii Independente • BENEFICIARI • PRODUSE § Categorii de Informatii Dependente • CONTRACTE o In domeniul Legaturilor între Categorii de Informatii: § Legaturi Primare (reprezentate în figura prin linii continue) • Relatii Contractuale • Pozitii Contractuale § Legaturi Derivate (reprezentate în figura prin linii punctate) • Obligatii Contractuale Legaturile Derivate pot fi deduse din proprietatea de Tranzitivitate a relatiei descrisede Categoria de Informatii CONTRACTE si conferita de semantica atasata Legaturilor întreCategoriile de Informatii. Se zice ca Legaturile Derivate sunt induse de Legaturile Primare.
    • Structuri de Informatii la Utilizator 119 Din cele prezentate se remarca urmatoarele: - In lumea reala Spatiile de Informatii sunt încarcate de informatii care se cer transpuse în Modelele de Date care doresc sa ofere o fidelitate cât mai mare - Utilizatorii Structurilor de Ansamblu lipsesc în general, fiind înlocuiti de Grupuri de Utilizatori interesati doar în Viziuni Partiale ale ansamblului - Definirea continutului general al Structurii de Ansamblu trebuie sa fie rezultatul unei activitati de sinteza, ce cade în sarcina Informaticianului, neputând fi rodul unei simple actiuni de colationare a cerintelor partiale deduse prin analiza3.4.4.2 Structuri Partiale Pornind de la remarcile anterioare sa urmarim cu ce viziuni particulare se confruntaproiectantul de structuri. Structura Partiala I Structura este specifica utilizatorului interesat de imaginea CONTRACTELOR cuBeneficiarii. Structura e reprezentata de o viziune ierarhica pe trei nivele care descrie: Relatiile Contractuale cu Beneficiarii B i defalcate pe Contractele Cj si Produsele Pk din Pozitiile Contractuale B1 n B2 n BENEFICIARI Relatii Contractuale C1 n n C2 C3 n CONTRACTE Pozitii Contractuale P1 PRODUSE n P2 n P3 n Fig. 3.4.4.2.1 Structura Partiala I (BENEFICIARI / CONTRACTE / PRODUSE) Legaturile de dependenta Ierarhica sunt ilustrate în Diagrama Simbolica din Fig.3.4.4.2.2.
    • 120 Structuri de Informatii la Utilizator BENEFICIARI 1 Relatii Contractuale n PRODUSE m Pozitii Contractuale n CONTRACTE Fig. 3.4.4.2.2 Structura Partiala I (Diagrama Simbolica) Structura Partiala II Structura este specifica utilizatorului interesat de imaginea regrupata pe BENEFICIARIsi PRODUSE a CONTRACTELOR cu BENEFICIARII. Structura e reprezentata de o viziuneierarhica pe trei nivele care descrie: Obligatiile Contractuale fata de Beneficiarii B i centralizate pe Produsele Pk si defalcate pe Pozitiile Contractuale din Contractele Cj B2 n BENEFICIARI B1 n Obligatii Contractuale P3 P1 n P2 n n PRODUSE Pozitii Contractuale C1 n C2 n C3 n CONTRACTE Fig. 3.4.4.2.3 Structura Partiala II (BENEFICIARI / PRODUSE / CONTRACTE)
    • Structuri de Informatii la Utilizator 121 BENEFICIARI m Obligatii Contractuale n PRODUSE Pozitii m Contractuale n CONTRACTE Fig. 3.4.4.2.4 Structura Partiala II (Diagrama Simbolica) Structura Partiala III Structura este specifica utilizatorului interesat de imaginea regrupata pe PRODUSE siCONTRACTE a CONTRACTELOR cu BENEFICIARII. Gruparea e utila pentru Programelede Productie orientate pe clauzele contractuale (Termene). Structura e reprezentata de oviziune ierarhica pe trei nivele care descrie: Pozitiile Contractuale centralizate pe Produsele Pk din Contractele Cj si regrupate pe Relatiile Contractuale cu Beneficiarii B i P1 P2 P3 n n n PRODUSE Pozitii Contractuale C1 n C2 n C3 n CONTRACTE Relatii Contractuale B1 n B2 n BENEFICIARI Fig. 3.4.4.2.5 Structura Partiala III (PRODUSE / CONTRACTE / BENEFICIARI)
    • 122 Structuri de Informatii la Utilizator PRODUSE m Pozitii Contractuale n CONTRACTE n Relatii Contractuale 1 BENEFICIARI Fig. 3.4.4.2.6 Structura Partiala III (Diagrama Simbolica) Structura Partiala IV Structura este specifica utilizatorului interesat de imaginea regrupata pe PRODUSE siBENEFICIARI a CONTRACTELOR cu BENEFICIARII. Gruparea e utila pentru Programelede Livrare orientate pe destinatiile expeditiilor (Adrese de Beneficiari). Structura ereprezentata de o viziune ierarhica pe trei nivele care descrie: Obligatiile Contractuale pentru Produsele Pk regrupate pe Beneficiarii B i si defalcate pe Pozitiile Contractuale din Contractele Cj P3 P1 n P2 n n PRODUSE Obligatii Contractuale BENEFICIARI B1 n B2 n Pozitii Contractuale C1 n C2 n C3 n CONTRACTE Fig. 3.4.4.2.7 Structura Partiala II (PRODUSE / BENEFICIARI / CONTRACTE)
    • Structuri de Informatii la Utilizator 123 PRODUSE m Obligatii Contractuale n BENEFICIARI 1 Relatii Contractuale n CONTRACTE Fig. 3.4.4.2.8 Structura Partiala II (Diagrama Simbolica) Structura Partiala V Structura este specifica utilizatorului interesat de imaginea regrupata pe PRODUSE aCONTRACTELOR cu BENEFICIARII. Gruparea e utila pentru Situatiile Statistice utilizatepentru evaluarea indicatorilor de performanta ai Produselor (Valoare Contractata, Ritmicitatede Livrare etc.). Structura e reprezentata de o viziune ierarhica pe doua nivele care descrie: Sinteza pe Produsele Pk a valorilor Obligatiilor Contractuale fata de Beneficiarii B i si a valorilor din Pozitiile Contractuale din Contractele Cj P1 P3 n n P2 n PRODUSE Obligatii Contractuale B1 n BENEFICIARI B2 n Pozitii Contractuale C1 n C2 n C3 n CONTRACTE Fig. 3.4.4.2.9 Structura Partiala II (PRODUSE / BENEFICIARI si CONTRACTE)
    • 124 Structuri de Informatii la Utilizator PRODUSE m m Relatii Obligatii Contractuale Contractuale n n BENEFICIARI CONTRACTE Fig. 3.4.4.2.10 Structura Partiala V (Diagrama Simbolica)3.4.4.3 Reprezentarea Structurii de Ansamblu Din analiza sectiunilor anterioare se pot trage urmatoarele concluzii: - Structurile reale de informatii, prin continutul lor semantic, devin rapid suprapopulate - Utilizarea metodelor de Reprezentare Fizica a Structurilor de Ansamblu sunt inoperante datorita încarcarii cu detalii a schemelor de reprezentare - Reprezentarile Fizice ramân instrumente utile pentru relevarea cerintelor rafinate de structura în vederea încorporarii acestor detalii în Structura de Ansamblu - Descompunerea în Structuri Partiale este o metoda specifica proiectarii clasice de aplicatii, orientate spre prelucrarea fisierelor de date - In general, fiecare Structura Partiala corespunde în Programarea Clasica unei Aplicatii, întrunind cerintele doar a unui grup de utilizatori (vezi semnificatiile viziunilor ierarhice prezentate mai sus) - Încercarea de tratare prin descompunere esueaza rapid prin numarul mare de variante combinatoriale (pentru trei Categorii de Informatii desfasurate pe trei nivele de ierarhizare rezulta 3! = 6 variante de descompunere, fara a lua în calcul si descompunerile pe doar doua nivele) - Fiecare Structura Partiala anterior prezentata pierde aspecte de reprezentare a detaliilor structurale ale informatiilor, aspecte care ulterior pot fi cu greu recuperate Solutia de Integrare a Viziunilor Partiale ale unei Structuri de Informatii esteconstruirea unei Reprezentari Globale asupra întregului Spatiu de Informatii, care sa cuprindatoate tipurile de informatii prezente: Entitati, Atribute, precum si a Relatiilor între Entitati. O asemenea reprezentare trebuie sa apeleze la conventii care sa elimine Particularul,încarcat de detalii, în favoarea Generalului sintetizator si reprezentativ. Din acest motivreprezentarile simbolice sunt cele care ofera solutia cautata (Fig. 3.4.4.3.1).
    • Structuri de Informatii la Utilizator 125 BENEFICIARI 1 m Relatii Contractuale n Obligatii CONTRACTE Contractuale n Obligatii Contractuale n m PRODUSE Fig. 3.4.4.3.1 Structura de ANSAMBLU (Diagrama Simbolica - Varianta Extinsa) Varianta Extinsa contine toate trei Categoriile de Informatii si pe cele Independente(BENEFICIARI si PRODUSE) si pe cele Dependente (CONTRACTE). Se poate observa însafaptul ca a doua Categorie de Informatii este purtatoarea Informatiilor de Legatura întreprimele doua, putând ca urmare sa fie dedusa din Legatura existenta între acestea. Se ajunge lastructura din Fig. 3.4.4.3.2, denumita si Varianta Concentrata de reprezentare (vezi sectiunea3.4.3.2). Ca urmare, s-a ajuns la un mod de reprezentare care elimina o întreaga Categorie deInformatii (Informatiile de Legatura), care pot fi implicate de marcarea corecta a Relatiilor deLegatura între Entitatile Notiune din Structura. BENEFICIARI m Obligatii Contractuale n PRODUSE Fig. 3.4.4.3.2 Structura de ANSAMBLU (Diagrama Simbolica - Varianta Concentrata) Se întelege acum de ce Proiectarea la Nivel Înalt solicita Modele de Date care dispunde facilitatea, îndeobste neglijata de proiectantii începatori, de a descrie Relatii Fundamentalem – n, ce nu pot fi de fapt implementate direct în Structurile Bazelor de Date Relationale.
    • 126 Structuri de Informatii la UtilizatorProdusele care accepta introducerea unor asemenea structuri dispun si de posibilitatea de agenera automat Relatiile de Legatura sub forma unor Tabele de Baza distincte (ex. pornind dela descrierea din Fig. 3.4.4.3.2 produsul de modelare va genera automat structura din Fig.3.4.4.3.1 prin adaugarea Tabelei de Baza CONTRACTE cu Legaturile Relationale aferente). In concluzie se fac urmatoarele constatari: - Varianta Concentrata se preteaza pentru reprezentari de Structuri Complexe, fiind si singura care poate fi controlabila în practica proiectarii - Aceasta forma de reprezentare poate fi cu succes folosita pentru generarea automata a Categoriilor de Informatii Dependente, în cadrul produselor de Proiectare Asistata de Calculator a Modelelor de Date (ex. produsul ERWIN, [ERWM01] ) - Din ultima varianta de reprezentare se pierd detaliile legate de descrierea Atributelor Proprii Relatiilor de Legatura, în speta atributele proprii relatiei CONTRACTE (Numar Contract, Data Contract, Cantitate Contractata, Pret de Livrare, Termen de Livrare, Clauze Contractuale) - In cazul generarii automate a Informatiilor Dependente (Tabelele de Legatura), ramâne în sarcina Proiectantului sa adauge Atributele Proprii acestor Tabele, atribute care descriu Intensitatea Relatiilor între Entitati - O problema importanta legata de crearea Viziunilor de Ansamblu care sa ofere structurile adecvate construirii Bazelor de Date este legata de formarea Utilizatorului General, singurul interesat în crearea acestei baze de integrare a sistemului; de obicei acest Utilizator General trebuie selectat din esaloanele de Conducere a Unitatii care doreste implementarea unui Sistem Integrat Înainte de a încheia aceasta sectiune, pe care o consideram foarte utila în definireaconturului Sistemelor cu Baze de Date, gasim aici locul de a face o referire la una dinobservatiile facute la începutul lucrarii si care a putut sa fie apreciata atunci doar ca o „Figurade Stil” în caracterizarea SBD. Este vorba de Comparatia folosita în sectiunea 1.2 cuExperimentul lui M. McKay. Instrumentele de Investigare a Structurilor de Informatii si deDate prezentate în aceasta sectiune pot juca rolul Retelelor de Filtrare utilizate în experimentulmentionat, pentru a descoperii Ordini Interne acolo unde se pare ca domina Hazardul,Întâmplarea Neprevazuta. Necesita multa Educatie pregatirea Utilizatorilor în a întelege caSistemul asteptat nu se poate construi acumulând Cerinte de Moment, Urgente Cotidiene, ci caacestea trebuie subordonate unor Comandamente Superioare. Descoperirea RelatiilorFundamentale în Structurile de Informatii si de Date, capacitatile acestora de a fi îmbunatatiteprin Transformare, stabilirea prioritatilor între Informatiile Independente si cele Dependente,toate ridicate la forme de sinteza prin adecvate Mijloace de Reprezentare, ofera toate suportulde concepte necesar pentru mentinerea controlului asupra unor volume imense de Informatii. Acesta este unul din drumurile deschise de preocuparile SBD spre un domeniu maigeneral de analiza si sinteza a Structurilor de Informatii, preocupare care prin îmbogatireacontinutul în detalii al structurilor pune bazele Ingineriei Informatiilor. Atunci se va întelegeîndemnul SBD de a renunta în conceperea Structurilor la simpla juxtapunere de CerinteParticulare si Momentane, conferind procesului o Competenta Superioara în întelegerearolului pe care îl joaca în Ansamblu fiecare Element de Structura.
    • Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati 1273.4.5 Diversificarea Tipurilor de Legaturi între Entitati Daca la Tipurile Fundamentale de Legaturi între entitati se adauga criteriisuplimentare, se obtin deferite subclasificari ale acestor legaturi. Adaugarea de noi criteriiînseamna sporirea semanticii atasata Relatiilor de Legatura si prin aceasta se cresteposibilitatea introducerii de noi Restrictii Generale în descrierea intensionala a datelor. AcesteRestrictii vor fi încorporate în Nivelul Conceptual al Bazelor de Date sau, daca se proiecteazala un nivel înalt, în Modelul de Date (vezi sectiunea 4.2.1.1). Deoarece predilectia pentru continutul semantic adaugat legaturilor între relatii difera dela un producator l altul, am ales sa prezentam aceasta rafinare prin prizma a doua viziuni aparticulare promovate de doi cunoscuti producatori comerciali: ORACLE (SGBD-ulORACLE) si LOGITECH (Produsul pentru construirea de Modele de Date ERWIN).3.4.5.1 Viziunea în Produsul ORACLE ORACLE [BARK01] foloseste în clasificarea legaturilor urmatoarele Criterii: o Gradul Legaturii (Cardinalitatea) § Legaturi m - 1 Mai multe instante ale unei Entitati refera o instanta a altei Entitati § Legaturi 1 - 1 O instanta a unei Entitati refera o instanta a altei Entitati § Legaturi m – n Mai multe instante ale unei Entitati refera mai multe instante ale altei Entitati o Optionalitatea Legaturii § Optionala Fiecare instanta a unei Entitati poate exista independent, cu sau fara asocierea cu alta instanta din Entitatea referita § Mandatata O instanta a unei Entitati poate exista numai daca exista o instanta asociata din Entitatea referita Se remarca faptul ca tipul legaturii trebuie interpretata la cele doua extremitati, ceea ce determina descrierea tipului unei legaturi printr-o pereche de alternative: Optionala sau Mandatata. Se va remarca în conventiile grafice ce vor fi utilizate în continuare, aceasta dubla descriere a legaturii prin prezenta segmentului continuu pentru extremitatea Mandatata si a segmentului punctat pentru extremitatea Optionala. o Repetitivitatea Legaturii § Nerecursiva Legatura porneste si se termina în Entitati diferite § Recursiva Legatura porneste si se termina în aceeasi Entitate Aceeasi legatura poate fi clasificata dupa Criterii diferite. Rezulta urmatoarele cazuri decombinare:
    • 128 Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati o Legatura Nerecursiva § Legatura m - 1 • Mandatata la Optionala Copiii Angajatilor COPII ANGAJATI Fig. 3.4.5.1.1 Copiii Angajatilor Un Copil nu poate apare în Baza de Date decât asociat cu un Angajat. Presupunerea poate conduce la solutii care impun aceasta restrictie si anume: Un Copil nu poate fi identificat decât în asociere cu un Angajat. • Optionala la Mandatata Produsele unui Pachet PRODUS PACHET Fig. 3.4.5.1.2 Produsele unui Pachet Un Pachet nu poate apare în Baza de Date decât daca ambaleaza niste Produse. In acest caz restrictia semantica nu se reflecta si în modul de identificare a instantei de pachet întrucât un pachet poate contine în general mai multe produse. Ca atare restrictia semantica trebuie adaugata restrictiilor de identificare. • Mandatata la Mandatata Rândurile unei Comenzi RANDURI COMANDA Fig. 3.4.5.1.3 Rândurile unei Comenzi Structura descrisa ia în considerare faptul ca o Comanda comerciala se descrie prin doua Clase de Entitati: COMENZI si RANDURI de COMANDA între care se descrie explicit Legatura Relationala Rândurile Comenzii. Doar aceasta viziune explica necesitatea restrictiei duble: § Nici-un Rând fara Comanda § Nici-o Comanda fara cel putin un Rând Restrictia apare ca foarte utila în momentul în care Aplicatia o presupune, caci altfel Structura de Date poate face invizibile pentru prelucrari datele eronate: Rândurile necuprinse în Comenzi sau Comenzile fara Rânduri. Baza de Date având aceasta restrictie va împiedica introducerea datelor eronate.
    • Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati 129 Se impune o observatie importanta referitoare la legaturile Mandatata la Mandatata si anume faptul ca restrictiile impuse sunt întotdeauna verificate la sfârsitul unei tranzactii, care în acest caz trebuie sa implice actualizarea ambelor referiri aflate la extremitatile legaturii. (Ex. în aceeasi tranzactie trebuie prevazute adaugarile si stergerile necesare în sau din ambele colectii de date COMENZI si RANDURI, în caz contrar actualizarea Bazei de Date ar ramâne blocata). • Optionala la Optionala Copii adoptatii COPII PERSOANE ABANDONATI Fig. 3.4.5.1.4 Copii adoptatii Fie o Baza de Date continând doua Clase de Entitati: COPII ABANDONATI si PERSOANE. Se urmareste consemnarea printr-o Relatie de Legatura a adoptiilor legalizate. In acest caz ambele extremitati ale legaturi ramân OPTIONALE putând exista COPII ABANDONATI ce nu au fost înca adoptati sau PERSOANE ce doresc sa adopteze, dar nu au gasit înca prilejul favorabil. § Legatura 1 - 1 • Mandatata la Optionala Cazul propus în Fig. 3.4.5.1.5 este semantic similar cu cel prezentat în Fig. 3.4.5.1.1 (inclusiv restrictia de identificare), cu noutatea pe care o aduce particularitatea n=1, în societatile cu monogamie recunoscuta. Sotia Angajatului SOTIA ANGAJAT ANGAJATULUI Fig. 3.4.5.1.5 Sotia Angajatului • Optionala la Mandatata Întrucât, datorita particularitatii n=1, relatia matematica implicata de legatura este simetrica, pentru acest caz poate fi utilizat exemplul din Fig. 3.4.5.1.5 inversat. Se remarca diferenta între cele doua cazuri: • Fig. 3.4.5.1.5 - pornind de la ANGAJAT se afla SOTIA sa • Fig. 3.4.5.1.6 - pornind de la SOTIE se afla sotul ca ANGAJAT
    • 130 Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati Angajatul Sotiei SOTIA ANGAJAT ANGAJATULUI Fig. 3.4.5.1.6 Angajatul Sotiei Exemplul a fost preferat pentru a se ilustra dubla functionalitate a oricarei legaturi relationale (directa si inversa) si prin aceasta relativitatea în alegerea Proprietarului si a Membrilor definitii printr-o relatie între doua multimi. • Mandatata la Mandatata CERTIFICAT Certificatul unei Persoane De PERSOANA NASTERE Fig. 3.4.5.1.7 Certificatul unei Persoane Orice PERSOANA trebuie sa aiba un CERTIFICAT de NASTERE si orice CERTIFICAT de NASTERE trebuie sa se refere la o PERSOANA. Aceasta realitate poate fi considerata ca o restrictie necesara într-o Baza de Date orientata spre utilizarea acestor informatii. Si aici se manifesta proprietatea de simetrie a relatie de legatura. • Optionala la Optionala Casatoriti - Fi BARBAT FEMEIE Fig. 3.4.5.1.8 Casatoriti Intr-o Baza de Date care contine persoane cu Stare Civila diferita, grupate în doua Colectii de Date, organizate dupa atributul Sex, actualizarea oricareia dintre colectii ramâne Optionala. Restrictia semantica în acest caz ar putea sa fie în continuare rafinata în sensul transformarii tipului de legatura în functie de valoarea atributului Stare Civila (casatorit sau necasatorit), dar acest caz iese din sfera declararii pur Structurale a restrictiilor semantice si patrunde în sfera declararii Procedurale (corelarea amintita va trebui în acest caz rezolvata cu ajutorul unei Proceduri Stocate de tip Trigger, care sa evite actualizarile inadvertente). Discutia poate continua în sensul unei completari a declaratiei de Optionalitatea a Legaturii prin adaugarea unei Conditii
    • Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati 131 Suplimentare (ex. Starea Civila=’casatorit’ pentru Mandatat si Starea Civila=’necasatorit’ pentru Optional). In acest caz ramânem în sfera declaratiilor Structurale. § Legatura m - n • Mandatata la Optionala Membrii Echipei MEMBRI ECHIPE Fig. 3.4.5.1.9 Membrii Echipei Prima Clasa de Entitati a fost aleasa ca MEMBRI si nu ca PERSOANE pentru a se consemna acceptia semantica ca persoanele sunt înregistrate în Baza de Date doar în calitatea lor de Membri ai unei Echipe. ECHIPA poate fi însa înregistrata înainte ca sa-i fie definiti MEMBRII. Un Membru însa poate face parte din mai multe Echipe (sa zicem activând în ramuri diferite de activitate). • Optionala la Mandatata Echipele unei Persoane PERSOANE ECHIPE Fig. 3.4.5.1.10 Echipele unei Persoane Sa modificam acum acceptia semantica din Fig. 3.4.5.1.9, pe care o dorim implementata în Baza de Date dupa cum urmeaza. ECIPELE sunt urmarite numai ca un atribut al PERSOANELOR existente în Baza de Date. Persoanele vor intra si iesi în sau din Baza de Date optional, în timp ce echipele doar în masura în care sunt referite, parasind Baza de Date la stergerea ultimei persoane care le refera. Se remarca înca o data dependenta stricta a tipului de legatura de semnificatia care se doreste implementata în structura de date. Modificarea semnificatiei atasata unei legaturi determina necesitatea modificarii tipului de legatura memorat în descrierea Bazei de Date. Este evidenta problema adaptarii Valorii Datelor deja existente în Baza de Date la noile restrictii impuse. Produsele de proiectare avansata ofera doua posibilitati: • Restrictie valabila retroactiv (se aplica si valorilor existente) • Restrictie valabila ulterior (se aplica numai valorilor noi)
    • 132 Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati • Mandatata la Mandatata Jucatorii unui Joc JUCATORI JOCURI Fig. 3.4.5.1.11 Jucatorii unui Joc Nu se accepta existenta în Baza de Date a unui JUCATOR fara JOC si nici a unui JOC fara JUCATORI, acceptându-se participarea unui JUCATOR la mai multe JOCURI simultan si evident si reciproc. • Optionala la Optionala Parteneri Barbati Femei Fig. 3.4.5.1.12 Parteneri Urmarirea cuplurilor care se creeaza poate fi cu succes realizata într-o structura care accepta introducerea optionala a potentialilor parteneri (BARBATI si FEMEI) si declararea explicita a relatiei de Parteneri. (Se poate observa si faptul secundar ca structura oferita n satisface toate u gusturile de Parteneriat.) o Legatura Recursiva § Legatura m – 1 • Mandatata la Optionala - Infinita Legaturile recursive sunt acceptate doar pe aceeasi Clasa de Entitati. Acest tip de legatura conduce la un apel continuu în structura daca cel putin una din extremitati este Mandatata. Aceasta situatie este structural inacceptabila, datorita neprecizarii Punctului de Taiere a Recursivitatii. Ca urmare, legatura e considerata Infinita fiind inacceptabila. • Optionala la Mandatata - Infinita • Mandatata la Mandatata - Infinita • Optionala la Optionala Acest tip de structura descrie Ascendenta într-o Structura Ierarhica (n Descendenti – 1 Ascendent).
    • Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati 133 In exemplul din Fig. 3.4.5.1.13. Structura Ierarhica e reprezentata de Structura Organizatorica a unei Companii care contine mai multe Departamente. Pentru a putea folosi proprietatea de Recursivitate (vezi sectiunea 3.1.3.) în structura de date se cere unificarea într-o singura descriere a tuturor Unitatilor care apar în structura de informatii (Companie, Departament, Birou, Grupa etc.). Aceasta este semnificatia Clasei de Entitati unice UNITATE din Figura. Ascendenta UNITATE Fig. 3.4.5.1.13 Ascendenta Legatura fundamentala implementata este de tip Ierarhie (vezi s ectiunea 3.4.3.). Restrictia adaugata structurii este cea de ascendent unic pentru fiecare UNITATE, mai putin Radacina, ceea ce implica acceptarea conditiei Nedefinit pentru referinta ascendenta, implementata ca un atribut al UNITATII. Relatia de Legatura e implementata de relatia: Ascendenta = { (Uc ,Ua ) }  Uc are ca ascendent pe Ua unde Uc reprezinta instanta curenta a UNITATII si Uc reprezinta instanta ascendenta a UNITATII. § Legatura 1 - 1 • Mandatata la Optionala – Infinita • Optionala la Mandatata - Infinita • Mandatata la Mandatata – Infinita • Optionala la Optionala Structura descrie perechi de instante de ANGAJATI ce apartin relatiei: Înlocuire = {(Ac , Ai )  Ac e înlocuit de AI } unde Ac reprezinta instanta curenta a ANGAJATULUI si Ai reprezinta instanta ANGAJATULUI înlocuitor. Datorita implementarii Angajatului Înlocuit si a celui Înlocuitor prin aceeasi Clasa de Entitatii (ANGAJAT), implementarea legaturii recursive 1 – 1 trebuie sa implice existenta unei Chei
    • 134 Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati Candidate pe atributul Înlocuitor din ANGAJAT, care sa asigure unicitatea Înlocuitorului pe multimea Înlocuitilor. Deci declararea acestui tip de legatura va determina generarea automata a Cheii Candidate Înlocuitor. Inlocuire ANGAJAT Fig. 3.4.5.1.14 Înlocuire § Legatura m - n • Mandatata la Optionala – Infinita • Optionala la Mandatata – Infinita • Mandatata la Mandatata - Infinita • Optionala la Optionala Componenta PRODUS Fig. 3.4.5.1.15 Componenta Pentru acest tip de relatie s-a ales ca exemplu structura de date utilizata în Prelucrarea Nomenclatoarelor (vezi sectiunea 2.4). Aceasta structura implementeaza relatia fundamentala de tip Retea (vezi sectiunea 3.4.3.) Legatura e descrisa de relatia: Componenta = {(Pc , Pm )  Pc are ca si component pe Pm } unde Pc reprezinta instanta de PRODUS Compus si Pm reprezinta instanta de PRODUS Component.
    • Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati 1353.4.5.2 Viziunea în Produsul ERWIN Produsul ERWIN [ERWM01] promoveaza o Metoda proprie pentru ModelareaDatelor descrisa în urmatoarele documente: o IDEFX1 (Information Definition – Definirea Informatiilor) [IDEF1X] – o metoda dezvoltata de Fortele Aeriene ale Statelor Unite. Ea e în prezent folosita pentru: § Agentii guvernamentale § Industria aerospatiala § Piata bancara § Corporatii majore o IE (Information Engineering – Ingineria Informatiilor) – o metoda dezvoltata de James Martin & Clive Finkelstein. Ambele metode sunt cuprinse în produsul ERWIN. Aceste metode sunt orientate catredescrierea Modelelor de Date complexe, caracterizate prin: • Volume mari de date • Conceptie riguroasa de structurare • Spatii de Informatii ale Intreprinderilor mari Modelele de Date create cu ajutorul acestor tehnici formeaza nucleul procesului degenerare a Structurii Logice (Nivelul Conceptual) al Bazelor de Date, prin procesul deInginerie a Datelor specific produselor de Ingineria Programarii Asistate de Calculator(Computer-Aided Software Engineering – CASE). Criteriile de Clasificare a Structurilor deDate în produsul ERWIN sunt prezentate mai jos. Pot fi urmarite cu usurinta asemanarile cumetoda ORACLE, precum si particularitatile produsului ERWIN. o Gradul si Cardinalitatea Legaturii § Gradul Legaturii - (1 sau n) înseamna ca 0, 1 sau mai multe (n) Instante ale unei Entitati refera o Instanta a altei Entitati § Cardinalitatea Legaturii – proprietate de legatura care indica precis numarul Instantelor Copil legate de o Instanta Parinte (0, 1, n) o Independenta Entitatilor § Entitate Independenta - Entitatea care nu depinde în procesul de identificare de alta Entitate (nu are Constituenti de Identificator care migreaza din exterior, adica sunt Chei Straine) Exemplu: TIPUL-UNITATII sau TIPUL-STRUCTURII-UNITATII (Fig. 3.4.3.4.3 ) § Entitate Dependenta - o Entitate Copil a carei identificare (unicitate) depinde de o Cheie Straina
    • 136 Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati • Dependenta ca Existenta – Entitatea nu poate exista daca nu exista Entitatea Parinte Exemplu: Rândurile unei Comenzi (Document) nu pot exista fara Antetul Comenzii (Documentului) • Dependenta ca Identificare – Entitatea nu poate fi completa fara prezenta Identificatorului Parintelui Exemplu: Entitatea UNITATE daca identificarea ei se face cu Codul-Unitatii + Codul-Tipului-de-Unitate (Atribut preluat din Entitatea Parinte TIP-UNITATE) o Optionalitatea Legaturii § Legatura Optionala - Entitatea Copil nu e Dependenta ca Existenta, nici Dependenta ca Identificare de Entitatea Parinte Exemplu: Entitatea UNITATE daca identificarea ei se face numai cu Codul- Unitatii, Codul-Tipului-de-Unitate fiind doar un atribut descriptor, preluat din Entitatea Parinte TIP-UNITATE, care ramâne evident Cheie Straina § Legatura Mandatata - Entitatea Copil e Dependenta ca Existenta de Entitatea Parinte Exemplu: vezi exemplul de mai sus, referitor la Dependenta ca Existenta o Repetitivitatea Legaturii § Nerecursiva – Legatura porneste si ajunge în Entitati diferite § Recursiva – Legatura porneste si ajunge în aceeasi Entitate o Tipuri Suplimentare de Legaturi § Legaturi m-n (Many to Many) - vezi exemplele de la ORACLE (Legatura poate fi definita doar în Spatiul de Informatii (si nu în cel al Datelor Relationale); Modelerul de Date ERWIN permite descrierea unor asemenea legaturi si generarea automata a Entitatii de Legatura si a Legaturilor Relationale care o implementeaza în Spatiul Datelor (în Baza de Date) § N-aritatea Legaturii – precizarea numarului maxim admis de Instante ale Entitatii Copil ( > 2 ) § Legaturi de Clasificare (Subtipuri si Supertipuri) – Legarea unei Entitati Comune, cu Atribute Generale (Supertip) de mai multe Entitati Specifice, cu Atribute Particulare (Subtip) Exemplu: Clasificarea Rolurilor unei Entitati Persoana • PERSOANA - Entitate Generica (Gen Proxim) o PROFESOR – Entitate Specifica o STUDENT – Entitate Specifica (Diferenta Specifica) o CANDIDAT – Entitate Specifica
    • Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati 137 Se prezinta în continuare conventiile grafice utilizate pentru reprezentarea Structurilorde Informatii si Date descrise mai sus. Simboluri de Legaturi Descrierea IDEF1X IE Cardinalitatii Identificatoare Neidentificatoare Identificatoare Neidentificatoare 1 – 0,1,n 1 – 1,n 1 – 0,n 0,1 – 0,1,n neidentifi- catoare 0,1 – 0,1 neidentifi- catoare Fig 3.4.5.2.1. Conventiile de reprezentare grafica IE si IDEF1X In Fig. 3.4.5.2.1 sunt continute doua variante de Conventii Grafice (IDEF1X si IE)pentru reprezentarea Structurii de Date în Modelele construite cu ajutorul produsului demodelare ERWIN. Ambele conventii fac parte din Standardul American [IDEF-0], utilizat înconstruirea Modelelor de Date. Caracteristica aparte în aceasta conventie de reprezentare o constituie LegaturileIdentificatoare, respectiv Neidentificatoare, determinate de Migrarea Cheii Primare înIdentificatorul, respectiv într-un Descriptor al Relatiei Dependente.
    • 138 Concepte de Baza / Structuri de Proceduri3.5 Structuri de Proceduri Ideile si Conceptele care vor fi prezentate succint în aceasta sectiune par sa depaseascacadrul unei dezbateri a problematicii Bazelor de Date. Ele apartin altor domenii de interes, cumar fi Programarea Clasica sau Programarea Structurata. Argumentul principal care adeterminat cuprinderea lor în aceasta lucrare sunt urmatoarele: o Bazele de Date nu au pregetat sa asimileze orice descoperire aparuta în alte domenii de cercetare o Orice preluare a fost însotita de introducerea ei în contextul propriu de preocupari, subordonata scopului principal urmarit: Integritate prin Independenta o Însusirea unor idei si concepte a fost întotdeauna marcata de transpunere lor în practica, de valorificarea potentialului lor teoretic în confruntare directa cu solutionarea unor probleme de interes cotidian, dar nu dintre cele mai simple, datorita comp lexitatii conferite de situatiile reale ce asteptau rezolvare Noutatea pe care o aduce discutia despre Structura Procedurilor este legata de paralelafacuta cu Structura Datelor, al carei beneficiu consta în promovarea Simplificarii Procedurilorsi a cresterii simultane a Gradului de Control al acestora. Aceste idei vin sa defineasca în plusceea ce am desemnat adesea pe parcursul acestei lucrari prin sintagma: ViziuneStructuralista.3.5.1 Operatie si ProceduraDefinitii: Operatie – o interventie asupra unui ansamblu de date, în scopul transformarii sau evaluarii lui, dupa cum urmeaza: o Transformare pentru obtinerea de noi date: § Ca Forma – conversie § Ca Pozitie – reamplasare § Ca Ordine – reordonare § Ca si Continut – calcul aritmetic sau logic o Evaluare prin marcarea ca Adevarat sau Fals a rezultatului unei comparatii Ca urmare Operatiile pot fi: § De Atribuire – Fortare de Egalitate – Actiune § De Evaluare – Testare de Egalitate – Conditie Procedura – o Succesiune de Operatii având drept scop trecerea unui ansamblu de date dintr-o Stare Initiala într-una Finala. Instructiune – forma de comunicare a unei Operatii.
    • Concepte de Baza / Structuri de Proceduri 139 Elementele cu care vor opera Procedurile apartin la doua categorii distincte: o Date § Principale – reprezentate de Atribute din Baza de Date § Auxiliare – reprezentate de Variabilele de Program o Operatii § Specifice – descriu Actiuni si Evaluari proprii Mediilor de Programare (în speta Bazelor de Date) § De Control – descriu Logica Procedurii (relatiile de Echivalenta si de Incluziune între Operatii, alaturi de Repetitivitatea lor)3.5.2 Operatii de control In cele ce urmeaza se face o trecere în revista, într-o reprezentare grafica, a Operatiilorde Control utilizate în limbajele procedurale. In reprezentarile grafice care urmeaza s-au folositurmatoarele simboluri: - Cercul – Grup de Operatii - Punctul – Operatie Elementara sau Grup Elementar de Operatii - n - Numarul de aparitii (Instante) ale unui Grup de Operatii - oi – Operatie Elementara sau Grup Elementar de Operatii - c – Operatie de tip Conditie - B – Bloc Nerepetitiv - R – Bloc Repetitiv3.5.2.1 Compozitia Compozitia, denumita si Bloc sau Secventa este reprezentata de un Grup de Operatii(Elementare sau Grupuri de Operatii Elementare, marcat printr-un Început si un Sfârsit (Fig.3.5.2.1.1). Numarul de Aparitii (Instante) ale Blocului este 1. 1 BEGIN B .. Operatiei .. • • END o1 • on o2 Fig 3.5.2.1.1 Structura de Control de tip Compozitie3.5.2.2 Selectia Selectia, denumita si Structura Alternativa, are doua forme de realizare: SelectiaSimpla si Multipla.
    • 140 Concepte de Baza / Structuri de Proceduri Selectia Simpla este reprezentata de un Bloc care are în componenta o Conditie alaturide alte doua Blocuri subordonate primului. Cele doua Blocuri subordonate vor fi executate înfunctie de rezultatul conditiei (cel din stânga pentru conditia Adevarata, cel din dreapta pentruconditia Falsa (Fig. 3.5.2.2.1). Si Selectia are o singura Instanta. 1 C * IF Conditie c THEN .. Operatiei .. 1 ELSE .. Operatiej .. 1 B1 B2 END • • • • o1 • on o1 • on o2 o2 Fig 3.5.2.2.1 Structura de Control de tip Selectie Simpla Selectia Multipla este reprezentata de un Bloc care are în componenta o multime deBlocuri Conditionale care au fiecare în alcatuire o Conditie alaturi de un singur Bloc. Blocul seva executa pentru Conditia Adevarata. Un Bloc special si optional (OTHER - ALTE) încheiestructura. El se va executa în cazul în care nici-o alta Conditie nu a fost îndeplinita. BlocurileConditionale sunt disjunctive, în sensul ca unul singur va fi executat în ordinea de prioritatedata de pozitia lor în structura (vezi Fig. 3.5.2.2.2). 1 B DO CASE CASE Conditie1 .. Operatiei 1 .. 1 1 CASE Conditie2 C1 C2 .. C0 .. Operatiej * * * co .. c2 c1 CASE .. .. OTHER 1 1 1 .. Operatiek .. B1 B2 B0 END • • • • • • • • o1 • on o1 on o1 on o2 o2 o2 Fig 3.5.2.2.2 Structura de Control de tip Selectie Multipla
    • Concepte de Baza / Structuri de Proceduri 1413.5.2.3 Repetitia Repetitia, denumita si Bucla, are în alcatuire un Bloc Principal caruia îi este atasata oConditie care determina Numarul de Repetari (de Instante) ale Blocului Repetitiv. In functie delocul de amplasare a Conditiei, Repetitia are doua variante de realizare: o Repetitia Posibil Nula (Fig. 3.5.2.3.1) – Conditia e amplasata la Intrarea în Bucla (în stânga în reprezentarea grafica), putându-sa parasi Bucla daca la prima intrare Conditia de Iesire e satisfacuta r≥0 BEGIN R IF Conditie THEN EXIT END .. Operatiei * .. c 1 REDO END B1 • • o1 • on o2 Fig 3.5.2.3.1 Structura de Control de tip Repetitie (Repetitie Posibil Nula) o Repetitia Nenula (Fig. 3.5.2.3.2) – Conditia e amplasata la Iesirea din Bucla (în dreapta în reprezentarea grafica), Bucla executându-se cel putin o data r>0 BEGIN R .. Actiunej .. * IF Conditie THEN EXIT END c 1 REDO B1 END • • o1 • on o2 Fig 3.5.2.3.2 Structura de Control de tip Repetitie (Repetitie Nenula) Repetitia apeleaza la Operatia de Fortare a Iesirii din Bucla (EXIT) care poate fifolosita si în afara Conditiei de Repetare a Structurii. Desigur ca orice regrupare a conditiilorde parasire a structurii aduce un plus de control în comportarea în functiune a secventei deOperatii.
    • 142 Concepte de Baza / Structuri de Proceduri3.5.2.4 Substitutia Substitutia, este reprezentata de o Operatie de Apel, care determina executia tuturorOperatiilor continute în Procedura invocata, cu revenirea la Operatia de dupa Apel (Fig.3.5.2.4.1. .. 1 DO Nume-Procedura .. P * PROCEDURE Nume-Procedura a BEGIN 1 .. B Operatiei .. END • • o1 • on o2 Fig 3.5.2.4.1 Structura de Control de tip Substitutie3.5.3 Elementele Structurilor de Proceduri Elementele cu care se vor construi Structurile Procedurilor sunt grupate în Tab. 3.5.3.1.Din clasificarea prezentata rezulta si modul recursiv de construire a Procedurilor. GrupurileCompuse se formeaza din Grupuri Elementare în care pe pozitia Operatiilor apar GrupuriElementare. Acest proces se poate repeta indefinit, conducând la Proceduri Complexe.Respectând o structura bine definita procesul de construire, dar mai ales de depanare afunctionarii ei, pot fi tinute sub control. Câteva remarci legate de Tipurile de Structuri definitesunt utile. - Selectia Multipla include Selectia Simpla oferind totodata posibilitatea transformarii ei în selectie multipla - Selectia Simpla ofera posibilitatea, exploatata de unele Medii de Programare, de a fi transformata în Functie, putând fi utilizata ca Data. O asemenea implementare este oferita de structura Selectie Imediata ( IMMEDIATE IF): IIF (Conditie, Atribuire1 , Atribuire2 ) - Repetitia în cele doua variante, diferentiate prin amplasarea conditiei în structura se refera la numarul de inspectii efectuate: § Varianta Posibil Nula (Cât Timp) – considera pornirea de la o Conditie îndeplinita si se opreste la prima neîndeplinire § Varianta Nenula (Pentru) – inspecteaza toata multimea de elemente selectându-le pe cele care verifica Conditia - Substitutia reprezinta „Cuiul lui Pepelea” pentru Programare – Cu sau fara instructiunea GO TO? Am denumit cele doua variante de încorporare într-un punct a unei alte secvente de proceduri în mod sugestiv:
    • Concepte de Baza / Structuri de Proceduri 143 Operatie Atribuire ACTIUNE Evaluare CONDITIE Neconditional COMPOZITIA Simpla Nerepetitiv BLOC Conditional SELECTIA Multipla Grup Elementar (Grup de Operati) Posibil Nula Element REPETITIA Grup Nenula Repetitiv BUCLA Fixa (CALL) SUBSTITUTIA Variabila (GO TO) Grup Compus (Grup de Grupuri) Tab. 3.5.3.1 Elementele Structurilor de Procedurii
    • Concepte de Baza / Structuri de Proceduri 144 § Repetitie Fixa – cu referire la faptul ca înlocuirea prin invocare (CALL) conduce la definirea precisa a structurii ce urmeaza a fi încorporata, prin necesitatea revenirii în punctul de plecare dupa încheierea executiei § Repetitie Variabila – care reprezinta tot o forma de „Substitutie”, structura ce urmeaza a fi încorporata este necunoscuta depinzând de Conditiile întâlnite pe parcurs; de asemenea revenirea în punctul de pornire nu e impusa Este evident ca sistemele complexe, cum sunt Sistemele cu Baze de Date, prefera prima varianta, cea care ofera maxim control în proiectare si depanare, ramânând astfel fidele concluziilor Programarii Structurate.3.5.4 Descrierea Formala a Procedurilor In Fig. 3.5.4.1 este definita formal Procedura cu ajutorul expresiilor de rescriere înformat BNF (Backus Normal Form). Se regasesc constructiile prezentate anterior înclasificarea din Fig. 3.5.3.1. Traducerea atasata face ca sintaxa descrisa sa poata fi usor folositapentru definirea unui Pseudo-Cod de descriere generala a Procedurilor. - procedura → [PROCEDURE nume-procedura (parametri)] corp-procedura [END] - parametri → nume-data [parametri] actiune [END] - corp-procedura → [corp-procedura] structura-elementara - structura-elementara → compozitie → selectie → repetitie → substitutie - compozitie → BEGIN corp-procedura END - selectie → IF conditie THEN corp-procedura1 ELSE corp-procedura2 END WHILE - repetitie → DO conditie [END] corp-procedura END FOR - substitutie → DO nume-procedura END - operatie → operatie-specifica → operatie –de-control - operatie-specifica → actiune → conditie
    • Concepte de Baza / Structuri de Proceduri 145 - operatie –de-control → structura-elementara Traducerea Mnemonicelor PROCEDURE - PROCEDURA IF - DACA BEGIN - INCEPUT THEN - ATUNCI END - SFARSIT ELSE - ALTFEL DO - EXECUTA WHILE - CAT TIMP FOR - PENTRU Fig. 3.5.4.1 Definirea în Sintaxa BNF a Procedurii3.5.5 Descrierea în Pseudo - Cod Un Pseudo – Cod este denumit un limbaj conventional, foarte apropriat de LimbajulNatural, folosit pentru descrierea precisa, rapida si foarte comoda a Procedurilor de catre oriceUtilizator. Aceste cerinte pot fi traduse în practica prin: - Precizie – adoptarea unor Reguli de Descriere (a unei Sintaxe de Limbaj) - Rapiditate – evitarea regulilor amanuntite, impuse de limbajele compilabile - Comoditate – exprimarea elementelor de baza cu usurinta în limbajul natural: § Actiunea – se exprima printr-un Enunt Imperativ ce trebuie executat § Conditia – se exprima printr-un Enunt Afirmativ ce trebuie verificat Acest instrument este utilizat pentru transpunerea în Proceduri de Prelucrare aSpecificatiilor de Descriere a Proceselor identificate în cadrul unui Sistem. Reprezinta un pasintermediar între faza de Specificare si cea de Programare prin aceea ca permite: - Descrierea facila a Procedurilor - Transpunerea directa a descrierii în Programe Specificul Limbajelor Formale de Descriere a Procedurilor este strâns legat despecificul Structurilor de Date ce urmeaza a fi prelucrate. Pentru acest motiv Sistemele cu Bazede Date se preteaza pentru asemenea descrieri, întrucât nivelul de descriere Logica a Datelorofera Entitati, Atribute si Relatii extrase direct din Spatiul de Informatii, deci foarte familiareutilizatorului si totodata unice pe parcursul evolutiei sistemelor de aplicatii, prin prezentaModelului de Date. Pentru a construi un asemenea instrument de lucru trebuiesc respectateurmatoarele conditii: o Preluarea Structurilor de Control din Limbajele Procedurale (vezi Fig. 3.5.3.1) o Definirea unui Limbaj Formal general (vezi Fig. 3.5.4.1) o Exprimarea Operatiilor Specifice din sistemele ce urmeaza a fi descrise (în speta SBD) în Limbaj Natural
    • Concepte de Baza / Structuri de Proceduri 1463.5.6 Arborele de Programare Arborele de Programare reprezinta un formalism grafic utilizat în ProgramareaStructurata. El se construieste prin stabilirea relatiilor de Echivalenta sau de Incluziune întreElementele de Structura precizate cu ajutorul Regulilor Formale ce descriu Procedura (veziFig. 3.5.4.1). Prezentarea Arborelui de Programare se va face pe baza unor exemple.Exemplul 1 Sa consideram ca, din motive de performanta dorim sa sortam nu prin Indexare, ci în memorie, dupa Nume, lexicografic, descrescator, structura de date descrisa mai jos, care prezinta forma unei structuri statice de tip Matrice: BENEFICIAR B Cod c Nume n Arborele de Programare va arata ca în Fig. 3.5.6.1.Exemplul 2 Fie Structura de Date simbolica a unui Model de Date de tip Retea, descrisa în Fig. 3.5.6.2. Se recunosc urmatoarele caracteristici: - A – Entitate - B, C, D, E – Subentitati - a, b, c, c, d, e – Descriptori - ri – Referinta la Lista de Membri (Lista de Articole din Entitatea de tip E) - r – Referinta la Posesor (Entitate de tip D) Sa mai consideram urmatoarele Specificatii de Definitie a unei Proceduri de interogare a Structurii de Date prezentate: - Obtinerea Rezultatelor trebuie confirmata de Utilizator la începutul procedurii - Rezultatele constau din: • Numararea Instantelor (Realizarilor) Entitatii A care verifica o Conditie data (a > v) • Numararea tuturor Instantelor (Realizarilor) Subentitatii E din prima instanta a Entitatii A • Afisarea Rezultatelor In Fig. 3.5.6.3 este redata o descriere în Pseudo – Cod a Procedurii descrisa anterior, iarîn Fig. 3.5.6.4 este redata aceeasi Procedura cu ajutorul Arborelui de Programare. In urma analizei exemplelor prezentate se cuvin câteva concluzii: o Ultimul exemplu prezentat lasa sa se observe faptul ca Arbore de Programare nu reprezinta un instrument practic de lucru pentru descrierea Procedurilor. Utilitatea
    • Concepte de Baza / Structuri de Proceduri 147 lui consta însa în educarea modului de a ”gândi” procedura. In cest scop se fac urmatoarele remarci: § Procedura e privita ca o Constructie din Module precis definite separate în cele doua categorii: • Operatii de Control • Operatii Specifice Mediului de Programare (vezi Operatia o10 din Fig. 3.5.6.1 si Fig. 3.5.6.2, care evita o structura de control de tip Repetitie) 1 M ≥0 1 I S * 1 1 C • i<n A i=1 * 1 n(i) ≥ n(i+1) T • i=i+1 n 1 ≥0 1 E D R • • * • • • j >1 si n(j) =mj=i+1 m=n(j) n(j-1)>m n(j)=n(j-1) j=j-1 Legenda M – Sortare Matrice T – Transpunere Elemente e - Element I – Initializare Index E – Extragere Element i, j – Indecsi A – Actualizare Index D – Deplasare Elemente n - Nume S – Scanare Matrice R – Reamplasare Element m – Variabila Interna C – Test Conditie Fig. 3.5.6.1 Arborele de Programare pentru procedura de Sortare prin Transpunere
    • Concepte de Baza / Structuri de Proceduri 148 § Operatia de Substitutie, care nu poate fi în viziunea structurala decât Fixa, invita la Modularizarea Procedurii, cu rezultate directe atât în faza de constructie cât si în cea de depanare § Viziunea Structuralista consta în construirea ansamblului din Structuri Elementare si prin aceasta se apropie de procedeele de construire a Structurilor de Date o Se remarca asemanarea Arborelui de Programare cu Arborele de Structura a Datelor: § Ambele au o Organizare Structurala Ierarhica pe Nivele § Nivelele de Procedura pe care apar Repetitii trebuie sa corespunda unor Nivele de Structura a Datelor care descriu date de tip Multime (Clase de Entitati, Ansambluri de Entitati etc.) § Nu întâmplator s-a ales în Exemplul 2 un Model de Date de tip Retea în care sa fie mai vizibile Nivelele de Subordonare Ierarhica. In Modelele Relationale cel mai adesea Procedurile de Prelucrare opereaza pe Cursori, care sunt Vederi rezultate din operatii de Cuplare de Relatii si care vor contine în reprezentare Secvential Ierarhizata diferite Nivele de Ierarhizare în functie de Vederea Partiala utilizata (vezi sectiunea 3.4.4), dar aceasta transformare de structura ar fi complicat prezentarea A • a B E • b C • * D e r • • • * c1 c2 d ri Fig. 3.5.6.2 Structura Simbolica de tip Retea (Arbore de Structura) o Utilizarea Procedurilor Structurate este foarte adecvata Sistemelor cu Baze de Date. Când se opereaza cu Baze de Date, se manifesta anumite particularitati: § In descrierea Structurilor de Control de tip Repetitie vor apare Operatii Specifice orientate pe Inspectia si Filtrarea Multimilor de Instante ale Colectiilor de Date
    • Concepte de Baza / Structuri de Proceduri 149PROCEDURA Interogare Cerere-Raspuns (r) …………………………….. operatia o 1 DACA R=nedefinit ………………………. conditia c1 ATUNCI IESIRE …………………………….. operatia o 2 SFARSIT Initializare Contor …………………………….. operatia o 3 TEST CAZ CAZ R=’A’ EXECUTA Scanare1 …………………………….. operatia o 4 CAZ R=’E’ EXECUTA Scanare2 …………………………….. operatia o 5 ALTFEL EXECUTA Eroare (1) …………………………….. operatia o 6 SFARSIT EXECUTA Listare(R, Contor) …………………….. operatia o 7SFARSITPROCEDURA Scanare1 Cerere-Raspuns (v) …………………………….. operatia o 8 PENTRU TOATE Instantele A având a > v ……... conditia c2 Incrementare Contor …………………………….. operatia o 9 SFARSITSFARSITPROCEDURA Scanare2 Contor = Cardinal Multime de Instante E ………………….….. operatia o 10SFARSITPROCEDURA ListarePARAMETRII Nume-Entitate, Contor Listare Nume-Entitate, Contor …………………………….. operatia o 11SFARSITPROCEDURA EroarePARAMETRII Numar-Eroare TEST CAZ CAZ Numar-Eroare =1 ………………………. conditia c3 Listare ‘Valoare Raspuns Eronata’ ………………….. operatia o 12 CAZ .. .. ALTFEL .. SFARSITSFARSIT Fig. 3.5.6.3 Procedura de Interogare (Descriere în Pseudo – Cod)
    • Concepte de Baza / Structuri de Proceduri 150 1 1 I E 1• * L 1 1 o7o1 Te T * • c3* 1 1 1 1c1 1 o11 C1 C2 E1 E2 .. A • • • o3 1 • • o2 Tc o12 * c2 1 1 1 1 1 S1 S2 C1 C2 .. A • ≥0 o8 S * * • * o4 o5 o6 o10 * • c2 o9 Legenda I – Interogare L – Listare S 1 – Scanare 1 E – Eroare S 2 – Scanare 2 T – Test Raspuns S – Scanare Multime de Instante E Tc – Test Caz Te – Test eroare Fig. 3.5.6.4 Procedura de Interogare (Arborele de Programare) § In Conditii este recomandat sa apara doar Atribute din Structura de Date si nu Variabile de Memorie, care denota o descriere insuficienta a Structurii de Date (în exemplul prezentat în conditii nu apar decât Variabile specifice unei Proceduri de Interogare si anume: Raspunsuri de Continuare sau Constante de Filtrare)
    • Concepte de Baza / Structuri de Proceduri 151PARTEA a 4 -a MODELE de INFORMAT II si DATE Sectiunile reunite în aceasta parte formeaza Centrul de Greutate al lucrarii, prin volumul de informatii pus la dispozitie si de asemenea prin viziunea pe care o consolideaza, referitoare la Sistemele cu Baze de Date. Conceptele de Baza prezentate anterior sunt aici pe îndelete folosite pentru a construi în doua planuri distincte: Spatiul Informatiilor – Viziunea Utilizatorului Spatiul Datelor – Viziunea Sistemului de Calcul structurile care formeaza fundamentul unei Surse de Date Bine Definite. Sectiunile alaturate, deosebit de numeroase, poate prea numeroase din intentia de a mentine cursivitatea în înlantuirea Structurilor & Restrictiilor & Operatiilor, ca elemente inseparabile în cadrul Modelelor de Date, sunt grupate în doua parti: 4.1 – Modele de Informatii – creeaza baza Abordarii Semantice a Modelelor de Structuri si deschide calea Proiectarii Asistate de Calculator a SBD. Punctul central îl formeaza Modelul Obiectelor Abstracte, ale carui concepte, bazate pe Procesele de Abstractizare, vor fi urmarite, în formele de transpunere si implementare în Spatiul Sistemului de Calcul, de-a- lungul întregii lucrari. Se pun astfel bazele unei Proiectari de Nivel Înalt, care începe din Spatiul Utilizatorului si continua cu Instrumente de definire conceptuala a Modelelor de Date. 1.4 – Modele de Date – se alege Modelul Strict de Date, cu întreaga sa Arhitectura, ca forma cea mai fidela de transpunere a conceptelor Modelelor de Informatii în Spatiul Sistemelor de Calcul. Prezentarea comparativa a Tipurilor de Modele de Date (Ierarhic, Retea, Relational) satisface cerintele de cronologie ale unei Monografii de Concepte. Accentul prezentarii va cadea asupra Modelului Relational (Structuri, Limbaje, Particularitati, Exemple).
    • 152 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare4 Modele de Informatii si Date4.1 Modele de Informatii Modele de Informatii sunt dezvoltate în Spatiul de Informatii care descrie ProblemaUtilizatorului, fiind ca atare încarcate cu maximum de semantica, ce urmeaza a fi transpusa înModelul de Date, care ia în discutie si instrumentele ce vor fi folosite în prelucrare.4.1.1 Modelul Entitate – Caracteristica – Valoare (Modelul ECV) Modelul ECV introduce elementele fundamentale de descriere a Structurilor deInformatii (vezi si Modelul lui Langefors, aparut ulterior si referit în sectiunea 4.2.1).4.1.1.1 Descrierea Spatiului de Informatii Cu ajutorul Informatiilor, care poarta semnificatia (Sensul) cunostintelor noastreasupra unui domeniu de interes al realitatii, descriem elementele si legaturile între ele ce permitconstruirea acelor structuri a caror evolutie în timp dorim sa o urmarim. Aceste structuridescriptive le vom denumi, în termenii sistemelor cu Baze de Date, Spatiul de Informatii. Elevor reprezenta întotdeauna legatura directa cu Utilizatorul în vederea supravegherii domeniuluilui de interes. Fie urmatoarele informatii care descriu un asemenea Spatiu de Informatii,reprezentând – Studentii unui An de Studiu reuniti în Grupe de Activitate (Fig. 4.1.1.1.1).Informatiile cuprinse în domeniul specificat mai sus, au putut fi structurate prin grupare înMultimi de Informatii: - Entitati Obiect • Student 1 • Student 2 • .. • Student i - Clasa de Entitati Obiect STUDENTI ≡ [Student 1, Student 2, .., Student i} Prin abstractizare se poate obtine o noua Multime foarte importanta în descriereainformatiilor si anume: - Entitatea Notiune • STUDENTcare descrie pe oricare din Studenti dar pe nici unul anume. Structurarea poate continua si în interiorul Categoriilor definite pâna acum,obtinându-se noi Multimi de Informatii: - Caracteristici descriptive pentru entitatea STUDENT • Marca • Nume • Prenume • Vârsta • Sex
    • Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 153 • Sectie • Responsabilitate • Membru-în-Grupa - Valori ale Caracteristicii Marca • 101 • 102 • 103 • etc. - Valori ale Caracteristicii Nume • Ionescu • Varga • Pop • etc. - Valori ale Caracteristicii Prenume • Andrei • Stefan • Maria • etc. - Valori ale Caracteristicii Vârsta • 22 • 21 • etc. - Valori ale Caracteristicii Sex • Barbatesc • Femeiesc - Valori ale Caracteristicii Specialitate • Informatica • Electronica • etc. - Valori ale Caracteristicii Responsabil-de-Grupa • Da • Nu - Valori ale Caracteristicii Membru-în-Grupa cu Responsabil-de-Grupa = Studentul-2 • Sstudentul-1, Studentul-2, etc. • etc. - Valori ale Caracteristicii Membru-în-Grupa • Studentul-1, Studentul-2, etc. • Studentul-3, Studentul-4, etc. • etc. - Valori de Caracteristica (în general) • 101 • Ionescu • Stefan • Barbatesc • Informatica • Studentul-1, Studentul-2, etc. • etc.
    • 154 Modele de Informatii si Date un Student are Marca este 101 un Student are Nume este Ionescu un Student are Prenume este Andrei Student-1 un Student are Varsta este 22 un Student are Sex este Barbatesc un Student este Informatician un Student nu este Responsabil-de-Grupa un Student are un Responsabil-de-Grupa este Student-2 un Student are Marca este 102 un Student are Nume este Varga un Student are Prenume este Stefan un Student are Varsta este 22 Student-2Studenti un Student are Sex este Barbatesc un Student este Informatician un Student este Responsabil-de-Grupa un Student are un Responsabil-de-Grupa este Student-2 un Student are Marca este 103 un Student are Nume este Pop un Student are Prenume este Maria Student-3 un Student are Varsta este 21 un Student are Sex este Femeiesc un Student este Electronist un Student nu este Responsabil-de-Grupa un Student are un Responsabil-de-Grupa este Student-4 Fig. 4.1.1.1.1. Descrierea Clasei de Entitati STUDENTI
    • Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 1554.1.1.2 Descrierea Spatiului de Date In vederea transformarii Informatiilor în Obiectul prelucrarii lor cu ajutorul unorinstrumente consacrate (automate sau manuale), vom utiliza Datele în calitate de SemnePurtatoare ale Semnificatiei Informatiilor. Vom putea reface constructiile de structuridescifrate în Spatiul Informatiilor utilizând conventii simplificatoare, care sa usurezeculegerea, memorarea, prelucrarea, transmiterea si extragerea Datelor purtatoare deInformatii. Noile structuri vor descrie Spatiul Datelor, ce va fi personalizat conform cerintelorimpuse de instrumentele de prelucrare utilizate. Se prezinta în continuare într-un pseudo-limbaj formalizat trei Modele de reprezentare în trei Spatii de Date distincte ale aceluiasiSpatiu de Informatii descris mai sus. ENTITY STUDENT-RESPONSABIL (10) BEGIN Marca numeric 3 Nume character 25 Prenume character 25 Varsta numeric 2 Sex value-set (M, F) Sectie value-set (I, E, M) ENTITY GRUPA (1) BEGIN ENTITY STUDENT -MEMBRU (15) BEGIN Marca numeric 3 Nume character 25 Prenume character 25 Varsta numeric 2 Sex value-set (M, F) END END END Fig.4.1.1.2.1 Spatiul de Date cu model Ierarhic ENTITY STUDENT (150) BEGIN Marca numeric 3 Nume character 25 Prenume character 25 Varsta numeric 2 Sex value-set (M , F) Sectie value-set (I , E , M) Responsabil logical Grupa entity-set { STUDENTI } END Fig. 4.1.1.2.2 Spatiul de Date cu model Retea
    • 156 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare ENTITY STUDENT (150) BEGIN Marca numeric 3 Nume character 25 Prenume character 25 Varsta numeric 2 Sex value-set (M , F) Grupa numeric 3 END ENTITY GRUPA (10) BEGIN Cod numeric 3 Responsabil numeric 3 Sectie value-set (I , E , M) END Fig. 4.1.1.2.3 Spatiul de Date cu model Relational Din analiza descrierilor celor doua Spatii de Descriere se desprind urmatoareleobservatii: - Continutul Spatiului de Informatii trebuie sa fie: § cuprinzator - pentru satisfacerea cerintelor de complexitate § clar - în fata unor categorii diverse de utilizatori § concis - pregatit pentru transpunere formalizata - Continutul Spatiului de Date trebuie sa fie: § fidel - sensurilor multiple din domeniul de interes al utilizatorilor § adecvat - la instrumentele de prelucrare § extensibil - în fata modificarilor sau adaugarilor de noi informatii - Ideile de organizare, sistematizare si clasificare a unor volume mari de cunostinte trebuie sa apara înca în descrierea Spatiului de Informatii si aceasta e posibil prin utilizarea unor Modele de Date performante pentru culegerea cerintelor de informare ale utilizatorilor - Unui Spatiu de Informatii unic îi pot corespunde mai multe Spatii de Date. Alegerea celui mai adecvat este o conditie pentru valorificarea unui volum bine cules de informatii si depinde de instrumentele de prelucrare aflate la dispozitie - Semnificatiile din Spatiul de Informatii pot fi în mod diferit transpuse în diferite Spatii de Date, cu posibile nuantari în gradul de fidelitateExemplu: Informatia: “un STUDENT este Responsabil-de-Grupa” poate fi transpusa în descriereaLOGICA prin urmatoarele elemente: o Implicit (printr-o Entitate) în modelul Ierarhic § Se prevad în Structura de Date doua Entitati STUDENT cu roluri diferite (Responsabil si Membru al Grupei)
    • Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 157 § Se economiseste astfel o Caracteristica de descriere (Responsabil) în cadrul Entitatilor § Se iroseste o dubla descriere prin Caracteristici a Entitatii STUDENT în cele doua roluri § Informatia e pastrata în Modelul Ierarhic si în cazul particular al neactualizarii Subentitatii Student-Membru prin existenta Entitatii Student- Responsabil o Explicit (prin Caracteristica Responsabil din Entitatea STUDENT) în Modelele Retea si Relational § Informatia ar putea fi reprezentata si în absenta Caracteristicii Responsabil, prin simpla prezenta a unei multimi nevide de Membri ai Grupei § In cazul particular al neactualizarii Caracteristicii de tip Multime ( Grupa), informatia e pierduta daca ar lipsi Caracteristica Explicita (Responsabil) Observatiile facute nu au avut drept scop sa orienteze cititorul catre o solutie în cazuldiscutat, ci sa evidentieze multitudinea de probleme pe care le ridica construirea structurilor înspatiul Entitate-Caracteristica-Valoare. In acest punct merita relevat faptul ca singurafidelitate fata de Cerintele Utilizatorului nu sunt suficiente, daca nu se adauga unui procescompetent si rabdator de surprindere a aspectelor mai profunde legate de construireaStructurilor de Informatii si Date, a caror calitate îsi va pune amprenta pe întregul proiect.Aceasta preocupare va oferi Sistemelor cu Baze de Date capacitatea de a raspunde nu numaiCerintelor Curente ale Utilizatorului, ci si celor pe care el nu le prevede înca. Acest lucru ne-adeterminat sa vorbim despre culegerea de Cunostinte asupra informatiilor ce urmeaza a fidescrise si nu o simpla fotografiere a unui volum momentan vehiculat de informatii, care celmai adesea descrie în primul rând Obisnuinte si nu Realitati. Fara a insista asupra ideii seaccentueaza faptul ca orice Sistem Informatic implica si Resursele Umane care trebuiesc adusela un grad de Cultura Informatica în consonanta cu stadiul Tehnologiei Avansate de prelucrarea Informatiilor si a Datelor. Prezentarea facuta are drept tinta construirea unui formalism de reprezentare aStructurilor de Informatii si Date prin reducerea legaturilor interne la conceptele introduse însectiunea 3.4.1.1.3 Entitate – Caracteristica – Valoare In aceasta sectiune se pun bazele d efinirii formalismului general amintit. Îl numimgeneral întrucât îl dorim desprins de Modelul de Date ales pentru construirea Spatiului de Date(Ierarhic, Retea, Relational, Obiectual etc.). Promisiunea de realizare a acestui dezideratconsta în faptul ca, pentru construirea lui, se va apela la concepte mai abstracte, din domeniulmatematic ce defineste notiunile de Multimi si Relatii, cu tot arsenalul aferent reamintit însectiunile consacrate acestui subiect. Modelul Relational de descriere a datelor, care va fiutilizat cu predilectie pe tot parcursul lucrarii, va gasi bineînteles o buna fundamentare, fiindcel mai apropiat de implementarea directa a acestui formalism. Pentru început se cere o Definire de Termeni. Toate definitiile enuntate pot fi regasite caexemplificare în studiul de caz prezentat la începutul sectiunii. Continutul lor se va regasitotodata în Modelul Formal descris în Tab. 4.1.1.4.1 si în Fig. 4.1.1.4.2.1.
    • 158 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare4.1.1.3.1 EntitateDefinitia 1 (Generala) Entitate – o Unitate Identificabila într-un univers de obiecte, concrete sau abstracte.Definitia 2 (Particularizata pentru Spatiul Informatiilor) Entitate – orice Existenta, Concreta sau Abstracta, caracterizata printr-un anumit numar de informatii, care o individualizeaza. Multimea de informatii care descriu Entitatea poarta denumirea de Însusiri sauCaracteristici. Ca urmare Entitatea se defineste deja ca o Multime de Însusiri si totodata ca oMultime de Elemente ce pot fi descrise cu ajutorul acestor Însusiri. Entitatea poate fi privita în doua moduri, unul Abstract (General) si unul Concret(Particular): o Entitate Notiune – un Element Abstract reprezentativ pentru elementele multimii (oricare din multime, dar nici unul anume). Ea va contine descrierea generala prin Nume de Caracteristici (Însusiri) a fiecarui element din multime. Exemplu: STUDENT Entitatea Notiune descrie Tipul de Entitate spre a o deosebi de altele (Entitatea STUDENT de Entitatea GRUPA). In expresie analitica Entitatea Notiune se descrie ca o Multime Ordonata de Caracteristici: Ei ≡ ( c i1 , c i2 , .. , c in ) Multimea Ordonata care descrie Entitatea Notiune mai poarta numele si de Tupla Logica. o Entitate Obiect – un Element Concret din multimea de elemente ( ealizare sau R Instanta de Entitate Notiune). Particularizarea va fi facuta prin acordarea de Valori particulare fiecarei Caracteristici (Însusiri) generale. Exemplu: Studentul 1 sau Studentul cu Nume ‘Ionescu’ si Prenume ‘Andrei’ In expresie analitica Entitatea Obiect se descrie ca o Multime Ordonata de Valori de Caracteristici: E ir ≡ ( v 1 , v 2 , .., vr .. , ve ) Multimea Ordonata care descrie Entitatea Obiect mai poarta numele si de Tupla Fizica. Multimea tuturor Entitatilor Obiect formeaza extensiunea Clasei de Entitati omonime:
    • Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 159 E i ‘ ⊆ C1 x C2 x .. x Cr .. x Ce E i ‘ = { ( v 1 , v 2 , .., vr .. , v e )} | v r ∈ Cr pt. ∀r ∈ {1,2, .. ,e} Asemenea demersului legat de Mutimi, o problema esentiala care se ridica legat deEntitati este cea de definire a posibilitatilor de Identificare. Identificarea Entitatii poate fi facutaîn mai multe moduri: - Prin Caracteristici – declararea Valorilor de Caracteristici (Însusiri) atasate Entitatii, care permit selectare unei Submultimi de Entitati din întreaga Multime existenta de Entitati: § Identificare Discriminanta – când multimea selectata contine un singur element; Exemplu: Studentul cu Marca ‘101’ § Identificare Nediscriminanta - când multimea selectata poate contine mai multe elemente; Exemplu: Studentul cu Vârsta ‘22’ - Prin Nume – Numele este o caracteristica aparte de identificare, ce are în componenta doua elemente: § Însusirea Comuna tuturor Entitatilor Obiect (Numele Entitatii Notiune). Exemplu: Studentul § Însusirea Specifica unei Entitatii Obiect. Exemplu: 1 Identificarea prin Nume este întotdeauna Discriminanta. In Modelul ECV Entitatea Notiune apare în sectiunea de Descriere a Informatiilor,urmând sa stea la baza crearii Dictionarului Datelor. In acest sens ea va apare în ModelulFormal descris în termenii de Multimi si Relatii ca element în Multimea Entitatilor E, caredescrie semantica Spatiului de Informatii (Fig. 4.1.1.4.1.3): E = { e 1 , e 2 , .. , e n }si se va regasi apoi în Descrierea unei Bazei de Date (BDL - Baza de Date Logica): BDL = { E 1 , E 2 , .. , E mb }4.1.1.3.2 Clasa de Entitati Fiind declarata Clasa aceasta structura trebuie sa fie definita ca o Multime de Multimi.Clasa de Entitati asigura aceasta conditie întrucât vom regasi în continutul ei: o O Multime Ordonata (Multimea de Caracteristici) o O Multime de Multimi Ordonate (Multimea de Entitati Obiect)
    • 160 Modele de Informatii / Modelul Entitate – Caracteristica - ValoareDefinitie: Clasa de Entitati – o Multime de Entitati Obiect, de acelasi fel, având aceleasi Caracteristici de descriere, dintre care una definitorie pentru întreaga Clasa. Caracteristica Definitorie da Numele Clasei, care se transfera apoi si asupra Entitatilor Obiect din Clasa. Orice Clasa de Entitati este definita prin Entitatile asociate: § O Entitate Notiune – contine descrierea Clasei si reprezinta Intensiunea ei. Constituie partea constanta în timp de definire a Clasei. Exemplu: Entitatea Notiune STUDENT descrisa de Caracteristicile: - Marca - Sex - Nume - Sectie - Prenume - Responsabil - Vârsta - Grupa § O Multime de Entitati Obiect – reprezinta Extensiunea Clasei. Constituie partea variabila în timp pentru definirea Clasei prin Valori (Instante). Exemplu: Multimea de Entitati Obiect STUDENTI: { Student 1, Student 2, .. } Pentru a deosebi Entitatea Notiune de Clasa de Entitati Obiect este binevenita utilizarea pentru denumirea lor a formelor de singular (pentru prima) si de plural (pentru a doua). Exemplu: Entitatea Notiune STUDENT Entitatea Obiect Student 1 Clasa de Entitati Obiect STUDENTI Proprietatile Clasei de Entitati: § Entitatile din Clasa au o Caracteristica Definitorie comuna § Caracteristica Definitorie da Numele Clasei § Entitatile din Clasa au aceleasi Însusiri care caracterizeaza toate Entitatile Obiect din Clasa, individualizându-le prin Instantiere § Entitatile din Clasa se supun acelorasi Relatii cu alte Clase de Entitati Continutul notiunii de Clasa de Entitati este dat de descrierea formala de mai jos: CE i ≡ (E i , E i ‘) Ei ≡ ( c i1 , c i2 , .. c ij , .. , c in ) E i are c ij E i ‘≡ {E i1 , E i2 , .., E ir .. , E im } E ir ≡ ( v 1 , v 2 , .., vr .. , ve ) E ir este E i
    • Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 161 Se regasesc elementele definitiei anterioare: Clasa de Entitati este alcatuita din: o O Entitate Notiune (E i ) – definirea în intensiune printr-o Lista de Caracteristici (Tupla de Nume) o O Multime de Entitati Obiect (E i ‘ ) - definirea în extensiune printr-o Multime de Tuple de Valori Din aceasta definire decurge si continutul semantic atasat legaturilor intrinseci aleacestui concept: o E i are c ij - O Entitate Notiune are Caracteristica c j ca si componenta de descriere o E ir este E i - O Entitate Notiune generalizeaza o Entitate Obiect si reciproc, o Entitate Obiect specifica o Entitate Notiune Este anticipata prezenta planurilor de Agregare si Generalizare ca operatii abstractede generare de Obiecte (vezi Modelul Obiectelor Abstracte în sectiunea 4.1.2).4.1.1.3.3 Metaclasa de Entitati O situatie particulara apare atunci când Elementele Multimii de Entitati Obiecte suntEntitati Notiuni. Sa analizam Multimea de Entitati Notiune E (vezi si Fig. 4.1.1.4.2.1. Si înacest caz putem sa recunoastem o Clasa de Entitati asa cum am definit-o anterior, prin simplaechivalare de termeni ce descriu continutul acestei noi Clase. Putem regasi cu usurinta acestitermeni de definitie în: o O Entitate Notiune – ce defineste în intensiune Multimea de Elemente printr-o singura Caracteristica si anume Numele Comun atasat Clasei (cel de Entitate Notiune pentru toate elementele Clasei) E ≡ (Nume) o O Multime de Entitati Obiect - ce defineste în extensiune Multimea prin enumerarea Entitatilor Notiune, care formeaza Instantele Clasei, definite doar prin Nume: E ‘≡ { E 1 , E 2 , .. , E i , .. , E n } unde: e i reprezinta un Nume de Entitate Notiune Întrucât aceasta noua Clasa de Entitati Obiect joaca rolul unei Clase Generice pentrutoate Entitatile definite în Structura de Informatii, ea mai este definita si Metaclasa. Amconsiderat însa mai utila asimilarea acestui nou termen cu Clasa de Entitati, având în vedere cadefinirea prezentata pentru Metaclasa ca o Clasa de Entitati este lipsita de echivoc si conducela o unificare de termeni care va simplifica în continuare tratarea Metaclasei. Procesul de unificare de termeni prin asimilare va fi reîntâlnit si în continuare când vorfi analizate notiunile de Caracteristica si Valoare.
    • 162 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare4.1.1.3.4 CaracteristicaDefinitia 1: Caracteristica – orice Însusire a unei Entitati. Caracteristica mai poarta si numele de Atribut.Definitia 2: Caracteristica – o Clasa de Entitati care nu mai admite descrierea cu alte însusiri (Caracteristici) si ale carei Entitati Obiect sunt reprezentate de Elemente Nedecompozabile (Valori de Însusiri). Ca urmare aceasta Clasa de Entitati elementara va fi definita prin: § Numele Caracteristicii reprezentând intensiunea ei data de sensul acordat Caracteristicii. Exemple: Vârsta Sex § O Multime de Entitati Obiect reprezentate de Valorile pe care le poate lua însusirea descris a. Exemple: { 19, 20, .., 35} { Masculin, Feminin } Orice Caracteristica este la rândul ei o Clasa de Entitati subordonata altei Clase deEntitati, pe lânga care joaca rolul de descriptor. Descriind o Clasa de Entitati cu ajutorul unorCaracteristici se realizeaza o asociere între Clase de Entitati: Clasei de Entitati descrise i seasociaza Clasele de Entitati descriptoare (Caracteristicile). In general o Clasa de Entitati poatefi descrisa prin asociere cu orice alta Clasa de Entitati (Elementara ca si Caracteristica sauNeelementara ca si Entitatea). Orice Relatie de Asociere genereaza doua Informatii: - Informatia de Asociere Directa: STUDENTUL are GRUPA - Informatia de Asociere Inversa: GRUPA are STUDENTI Definirea completa a Caracteristicii rezulta numai prin luarea în considerare aafirmatiei prin care o Caracteristica este o Clasa de Entitati si anume una Elementara, prinaceea ca e descrisa numai de Valori si nu de alte Caracteristici. Ca urmare continutul oricareiCaracteristici este definit de: o O Entitate Notiune – definirea în intensiune printr-un Nume de Caracteristica (Însusire sau Proprietate) o O multime de Entitati Obiect - definirea în extensiune printr-o Multime de Valori (Valorile Proprii Caracteristicii) C j = P 2 R ; R = { cj } x V (proiectie de rang 2 a lui R) Se poate si în acest caz evidentia acelasi continutul semantic atasat legaturilor intrinseciale conceptului de Caracteristica:
    • Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 163 o C j are v jk - O Caracteristica are Valoarea vjk ca si componenta de descriere o v jk este C j - O Caracteristica generalizeaza o Multime de Valori privite ca Entitati Obiect (Intensitati ale Caracteristicii) si reciproc, o Valoare specifica în planul instantelor o Caracteristica privita ca Entitate Notiune4.1.1.3.5 Valoare Necesitatea utilizarii Planului Valorilor în descrierea Structurilor de Informatii rezultadin urmatoarele constatari legate de aportul Valorii în tripletul Entitate - Caracteristica -Valoare: o Caracteristica este definita ca o Clasa de Entitati Elementara, având ca Elemente Valorile o Valorile sunt Entitati Nedecompozabile o Proprietatile Caracteristicii sunt Valorile o Rolul Valorii este de a descrie o Intensitate de Însusire (Însusire) o Entitatea este descris a Intensional de Caracteristici si Extensional de Valori de Caracteristici Rezulta urmatoarele definitii:Definitia 1: Valoare – Intensitatea unei Însusiri (Caracteristici).Definitia 2: Valoare – Entitatile Obiect ale unei Clase de Entitati Caracteristica. Informatiile definite prin propozitii (cuplu Subiect – Însusire) având termenul Însusire oValoare sunt Informatii Elementare (Nedecompozabile). De aici rezulta ca Valorile trebuie safie Elemente Autoidentificabile. Daca luam în considerare legatura indirecta care se stabileste între multimile de Entitati,Caracteristici si Valori, se pot defini urmatoarele Ansambluri de Valori: • C1 V1 C2 E1 • V2 Cj • Vj Fig. 4.1.1.3.5.1 Valori Izonime
    • 164 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare o Valori Izonime - reprezentând Valorile pe care le iau Caracteristicile ce descriu o Entitate Obiect (vezi exemplul simbolic din Fig. 4.1.1.3.5.1) In Modelul Relational Valorile Izonime descriu Tabelele de Baza. C1 E1 • V1 C1 E2 C1 • V2 En • Vi Fig. 4.1.1.3.5.2 Valori Izotipe o Valori Izotipe - reprezentând Valorile pe care le ia o Caracteristica în toate Entitatile Obiect din Colectia de Date (vezi exemplul simbolic din Fig. 4.1.1.3.5.2) In Modelul Relational Valorile Izotipe descriu Indecsii asociatii Tabelelor de Baza. Valorile sunt descrise printr-o serie de proprietati: § Tipul Datei § Limitele de Valori admise § Conditii de Validare (Constrângerile) impuse In expresie analitica (Fig. 4.1.1.4.1.2) Multimea Valorilor V cuprinde toate valorile carepot fi întâlnite în Colectiile de Date: V = { v 1 , v 2 , .. , v p } Multimea de Valori pe care le poate lua o Caracteristica data formeaza Domeniul deValori al acelei Caracteristici definit analitic: C j = P 2 R ; R = { cj } x V (proiectie de rang 2 a lui R) Definirea Domeniului Valorilor este de o importanta deosebita în proiectareaStructurilor de Informatii datorita urmatoarelor motive: o Permite stabilirea legaturilor initiale care exista între Informatiile multiple care populeaza un Spatiu de Informatii o Prin adaugarea de noi cunostinte se ajunge la stabilirea unor Clase de Echivalenta pe baza Criteriului de asemanare, nu numai Formala, ci si Informala o Derivarea ulterioara a Atributelor ce descriu Clasele de Entitati va putea fi consolidata prin utilizarea unor Surse Comune care sa asigure Mostenirea de Proprietati o Legaturile bazate pe Referinta Asociativa vor gasi terenul gata pregatit
    • Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 1654.1.1.3.6 Relatii de Asociere Relatiile de Asociere sunt Relatii între Clase de Entitati. Cele mai frecvente Relatii deAsociere sunt Relatii Binare de forma: A ⊆ E i ‘ x E j‘ unde: A – este Relatia de Asociere E i ‘ - Extensiunea Clasei de Entitati E i E j‘ – Extensiunea Clasei de Entitati E j In cazul Structurilor de Informatii Clasele de Entitati pe care se defineste Relatia deAsociere poarta semnificatii specializate si anume: E i – se denumeste Clasa de Entitati Posesori (P) E j – se denumeste Clasa de Entitati Membri (M) Tabelul 4.1.1.3.6.1, prin exemplificarile de Relatii de Asociere ofera o paralela întredescrierile Formale si Informale, Generale si Particulare, ca si cea între Legaturile Are si Este,care sunt transpuse prin inversare doar în cazul anumitor semantici continute în Relatia deAsociere. Se poate urmari cum Cuplul (e i , e j), încarcat cu o Semantica Generica, seinstantiaza apoi în diferite Intensiuni Concrete atasate Relatiei de Asociere. Descrierea Asocierilor Formala Informala Generala Particulara Directa Directa Inversa Inversa e i are Component pe e j e j este Compus pentru e i e j este Categorie pentru e i ei ∈ P e i are ca Specie pe e j ej ∈ M e i are Membru pe e j e i Poseda pe e j (e i , e j) ∈ A e j are Posesor pe e i e j e Posedat de e i e i are Descendent pe e j e j are Ascendent pe e i e i are Copil pe e j e j are Parinte pe e i Tab. 4.1.1.3.6.1. Legatura Relatii de Asociere – Tipuri de Structura Fiind data o Clasa de Entitati (Membri) careia i se ataseaza o Însusire de Asociere cu oalta Clasa de Entitati ( osesori), Relatia de Asociere defineste, în general, pe Multimea PMembrilor o Acoperire si doar cu o Restrictie suplimentara (unicitatea Posesorului) o Partitie.
    • 166 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare Se remarca descrierea oricarei Asocieri prin doua Relatii: - Relatia Directa – care descrie legatura Posesor - Membri - Relatia Inversa – care descrie legatura Membru - Posesor Raportul Relatiilor de Asociere cu Relatiile Fundamentale este redata în tabelul4.1.1.3.6.2. Relatie de Asociere Directa Inversa Semantica Tip Structura Semantica Tip Structura Posesor - Membri 1 -n Membru-Posesor 1 -1 Posesori - Membri m-n Membru-Posesori 1 -m Tab. 4.1.1.3.6.2. Legatura Relatii de Asociere – Tipuri de Structura In cazul Relatiilor de Asociere care descriu Relatii Fundamentale de tip m – n, RelatiaInversa defineste si ea pe Multimea Posesorilor o Acoperire. Relatia de Asociere poate fi privita ca orice Relatie în dublul ei continut: o Intensional – descris a de Proprietatea de Asociere (RA ), care extrage Relatia de Asociere (A i ) din Produsul Cartezian A i ⊆ E i ‘ x E j‘ ⇔ RA unde RA are semnificatia: e i are Membru pe e j si e j are Posesor pe e i cu e i ∈ P si e j ∈ M o Extensional – descris a de Multimea de Cupluri de Asociere care descriu fizic Relatia de Asociere A e ≡ { (e i , e j ) } | e i RA e j4.1.1.3.7 Ansamblu de Entitati Ansamblul de Entitati are la baza conceptul de Relatie între Clasele de Entitati.Aceasta Relatie ia forma Asocierii între Entitatile Obiect continute în Clasele de Entitati,Posesori si Membri. Ansamblul de Entitati urmareste sa prezinte din alt unghi de vedere Relatia de Asocieresi anume ca o Multime de Cupluri: A e ≡ { (p i , {m pj}) } | p i RA m pj pentru ∀ i si j
    • Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 167Exemplu: Studentii Grupelor≡ {(Grupa 1 , {Student 1, Student 3, ..}), (Grupa 2 , {Student 2, Student 5, ..}), ..}Definitie Ansamblul de Entitati – o Submultime de Entitati Obiect ale unei Clase de Entitati (Membri), care au o însusire comuna, ce poate fi exprimata ca o Relatie de Asociere între o Entitate Obiect Posesor (al Ansamblului), extras dintr-o Clasa de Entitati Posesori si mai multe Entitati Obiect Membri (ai Ansamblului), extrase din Clasa de Entitati Membri. Posesorul Ansamblului nu face parte din Ansamblu.Exemplu: {Student 1, Student 3, ..} Ansamblul de Entitati, la fel ca Entitatea poate fi si el privit în cele doua moduri, unulAbstract (General) si unul Concret (Particular): o Ansamblul de Entitati Notiune – un Element Abstract reprezentativ pentru elementele multimii ( ricare din multime, dar nici unul anume). Ea va contine o descrierea generala a Relatia de Asociere prin: § Numele Clasei de Entitati Membri (E i ) § Numele Clasei de Entitati Posesori (E j) § Relatia de Asociere (RA ) Exemplu: Studentii unei Grupe Ansamblul de Entitati Notiune descrie Tipul de Ansamblu de Entitati spre a le deosebi de altele (Studentii unei Grupe de Grupa unui Responsabil etc.). Se observa ca Ansamblul de Entitati Notiune încorporeaza, în Numele atasat, semantica acordata acestui element de structura. Ea e data de Intensiunea Relatiei de Asociere RA . Formal Ansamblul de Entitati Notiune AE n va putea fi definit prin Intensiunea Relatiei de Asociere A i , care implica si desemnarea Claselor de Entitati Posesori E i si Membri E j pe care ea e definita: AE n ≡ A i o Ansamblul de Entitati Obiect – un Element Concret din multimea de elemente (Realizare sau Instanta de Ansamblu de Entitati Notiune). Particularizarea va fi facuta prin acordarea de Valori concrete fiecarui Ansamblu de Entitati. Exemplu: Pentru Grupa 1 - {Studentul 1, Studentul 3 ..} Ansamblul de Entitati Obiect se descrie prin proiectia de rang 2 a extensiuni Relatiei de Asociere (Ae) pentru un element Posesor (t). Sau în expresie analitica:
    • 168 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare § Relatia de Asociere (A i ) pentru un element Posesor (t) se defineste ca o Proiectie Conditionata a Relatiei de Asociere (vezi sectiunea 3.1.2.5): A t ≡ { (e i , e j ) } | i = t si e t ∈ E i ‘ si e j ∈ E j‘ si (e i , e j ) ∈ Ae § Ansamblul de Entitati Obiect va putea fi definit formal prin Proiectia de rang 2 a lui A t: AE o t ≡ P 2 A t E evident extensiunea acestei multimi este o Restrictie a Multimii Entitatilor Obiect din Clasa de Entitati Membri E i ‘: AE o t ⊆ E i ‘ Ansamblul de Entitati va putea lua forme diferite de utilizare în Modele de Datediferite: o Caracteristica – în cazul în care el apare ca descriptor al altei Clase de Entitati § Caracteristica ce descrie Posesorul – Data de implementare poate fi elementara (pentru legaturi 1 – n), sau trebuie sa fie de Tip Multime (pentru legaturi m – n) § Caracteristica ce descrie Membrii – Data de implementare trebuie sa fie întotdeauna de Tip Multime o Clasa de Entitati – în cazul în care este definit independent § Clasa de Entitati va descrie integral Relatia de Asociere (A) în forma: A e ≡ { (p i , m j ) } | p i RA m j unde: p i ∈ P – Multimea Posesorilor m j ∈ M – Multimea Membrilor4.1.1.3.8 Clasa de Ansambluri de Entitati Întocmai ca si în cazul Clasei de Entitati si acum termenul de Clasa este justificat decontinutul acestei noi notiuni. Ea urmareste sa regrupeze notiunile definite în legatura cuAnsamblul de Entitati.Definitie Clasa de Ansambluri de Entitati – multimea Ansamblurilor de Entitati Obiect considerate ca Membri, asociate tuturor Entitatilor Obiect din Clasa de Entitati Obiect, considerate ca Posesori. Caracteristica definitorie (Relatia Posesor – Membri) da Numele Clasei, care se transfera apoi si asupra Entitatilor Obiect din Clasa. Orice Clasa de Ansambluri de Entitati este definita prin Entitatile asociate:
    • Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 169 § Un Ansamblu de Entitati Notiune – ce contine descrierea Clasei si reprezinta Intensiunea ei . Constituie partea constanta în timp de definire a Clasei. AE n ≡ A i Exemplu: Studentii unei Grupe § O Multime de Ansambluri de Entitati Obiect – care reprezinta extensiunea Clasei. Constituie partea variabila în timp de definire a Clasei. Exemplu: Multimea de Ansambluri de Entitati Obiect Studentii Grupelor: {{ Student 1, Student 3, .. }, {Student 3, Student 5, .. }, ..} Formal Multimea de Ansambluri de Entitati Obiect va fi definita prin toate Multimile de Membri E o t asociate tuturor Posesorilor P: AE o ≡ { E o t } pentru ∀ t ∈ P unde: P – Multimea Posesorilor Ca urmare Clasa de Ansambluri de Entitati se construieste cu ajutorul urmatoarelorconcepte: o Ansamblul de Entitati Notiune - Studentii unei Grupe o Ansamblul de Entitati Obiect - Studentii Grupei 1 o Multimea de Ansambluri de Entitati Obiect - Studentii Grupelor Continutul notiunii de Clasa de Ansambluri de Entitati este redat de descriereaformala completa de mai jos: CAE ≡ (AE n, AE o ) AE n ≡ A i A i ⊆ E i ‘ x E j‘ ⇔ RA e i are Membru pe e j si e j are Posesor pe e i e i ∈ P si e j ∈ M AE o ≡ { E o t } pentru ∀ t ∈ P A t ≡ { (e i , e j ) } | i = t si e t ∈ E i ‘ si e j ∈ E j‘ si (e i , e j ) ∈ Ae AE o t ≡ P 2 A t Desi definitia formala a Clasei de Ansambluri de Entitati apare mai complicata, ea sereduce în final la continutul cunoscut al notiunii de Clasa de Entitati (vezi sectiunea 4.1.1.3.2).Este suficienta simpla echivalare de termeni prin corespondentele: Entitatea Notiune (E i ) ≡ Ansamblul de Entitati Notiune (AE n) Multimea de Entitati Obiect (E i ‘) ≡ Multimea de Ansambluri de Entitati Obiect (AE o )
    • 170 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare Element de Structura Definitie Exemple Nume Nivel Nume Nivel Notiune O existenta descrisa printr-un STUDENT Nume General GRUPA + O Multime Ordonata de Caracteristici Entitate Obiect O Existenta Identificabila O existenta descrisa printr-un Student 1 descrisa informational Nume Particular Grupa 1 + O Multime Ordonata de Valori Clasa O Entitate Notiune STUDENTI ={Student 1, Student 2,..} + O Multime de Entitati ObiectCaracteristica Notiune Proprietate descrisa prin Nume Marca Obiect Însusire a unei Entitati O Instanta (Valoare) de Caracteristica Nume Clasa Proprietate descrisa printr-un Prenume Nume + O Multime de Valori Compatibile Valoare - Intensitate a unei Însusiri O Entitate Autoidentificabila 101 Ionescu Andrei Notiune O Relatia de Asociere descrisa printr-un STUDENTII unei GRUPE Nume General de Clasa de Entitati Posesori O Relatie de Asociere între + Nume General de Clasa de Entitati Membri O Clasa de Entitati PosesoriAnsamblu de Obiect O Relatia de Asociere descrisa printr-un Studentii Grupei 1= {Student 1, Student 3,..} Entitati si Nume Particular de Clasa de Entitati Posesori + O Clasa de Entitati Membri Nume Particular de Clasa de Entitati Membri Clasa Un Ansamblu de Entitati Notiune Studentii Grupelor={Studentii Grupei 1, + Studentii Grupei 2, ..} O Multime de Ansambluri de Entitati Obiect Tab. 4.1.1.4.1 Notiunile definite în Modelul ECV - Recapitulare
    • Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 171 Proprietatile Clasei de Ansambluri de Entitati: § Ansamblurile de Entitati din Clasa au o Caracteristica Definitorie comuna data de semantica Relatiei de Asociere (Posesor – Membri) § Caracteristica Definitorie da Numele Clasei de Ansambluri § Ansamblurile de Entitati din Clasa au aceleasi Însusiri care le caracterizeaza, individualizându-le prin instantiere § Ansamblurile de Entitati din Clasa se supun acelorasi Relatii cu alte Clase de Entitati Înainte de a trece la construirea Formalismului de descriere a Modelului Entitate -Caracteristica - Valoare facem o recapitulare a notiunilor definite în sectiunile anterioare,sinteza cuprinsa în Tabelul 4.1.1.4.1. Recapitularea facuta are drept scop extragerea, dinmultimea de detalii folosite în definirea notiunilor, a esentelor care se vor regasi mai departefixate prin expresiile matematice si simbolurile grafice utilizate in sectiunile urmatoare.4.1.1.4 Modelul formal ECV în termeni de Multimi si Relatii4.1.1.4.1 Definire matematica Elementele Structurilor de Informatii definite în contextul Modelului Entitate -Caracteristica – Valoare, elemente care vor fi regasite într-o forma sau alta în toate modeleleprezentate în lucrare sunt descrise prin corespondenta cu expresiile matematice introduse însectiunea Multimi si Relatii (Fig. 4.1.1.4.1.2). Punerea în corespondenta a acestor expresii cucontinutul notiunilor definite si comentate pe larg a fost facuta deja în sectiunile anterioare.4.1.1.4.2 Descriere grafica Fig. 4.1.1.4.1.3 reda, cu ajutorul simbolurilor grafice, elementele de baza ale ModeluluiEntitate - Caracteristica –Valoare. Asa dupa cum s-a mai mentionat simbolurile descrise întermenii acelorasi raporturi stabilite în sectiunea referitoare la Multimi si Relatii pot ficonsiderate de referinta pentru fixarea notiunilor si a conversiei sau asimilarii de termeni în alteModele de Informatii si de Date. Ca urmare, desi structurile reprezentate sunt orientate sprearhitectura Sistemelor cu Baze de Date, ele pot fi utilizate cu succes pentru întelegereaterminologiei specifice domeniului mai general al Modelelor de Date cu a caror manevrarecititorul se va simti poate mai familiar. In legatura cu aportul acestei noi forme de reprezentare facem urmatoarele sublinieri: o Marcarea diferentei între Multimile Neordonate { } si Ordonate ( ) o Ilustrarea formelor de Generare a Multimilor, prin Regrupare si prin Combinare o Conturarea prin suprafete texturate a continutului Claselor de Entitati, în diferitele lor contexte de aparitie, Entitate, Caracteristica, Ansamblu de Entitati o Punctarea formei particulare de aparitiei a Relatiilor de Asociere ca legatura Posesor - Membri
    • Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 172 Notiune Nume Simbol Expresie Observatii Multimea Valorilor V V = { v 1 , v 2 , .. , v p } Multimea Caracteristicilor C C = { c 1 , c 2 , .. , c n } Multimea Entitatilor Notiune E E = { e 1 , e 2 , .. , e n } Caracteristica Cj Cj =P2R proiectie de rang 2 a lui R R = { cj } x V Entitate Notiune Ei E i = (c 1 , c 2 , .. , c m ) ∈ C x C x .. x C Entitate Obiect E ir E ir ≡ (v 1 , v 2 , .., v r .. , v e) Multimea Entitatilor Obiect E i‘ E i ‘ ⊆ C1 x C2 x .. x Cr .. x Ce E i‘ E i ‘ = { ( v 1 , v 2 , .., v r .. , v e )} | v r ∈ Cr pt. ∀r ∈ {1,2,..,e} Clasa de Entitati CE i CE i ≡ (E i , E i ‘ ) E i are c j E ir este E iAnsamblu de Entitati Notiune A A ⊆ E i‘ x E j‘Ansamblu de Entitati Obiect Ei s t Ei s t ⊆ A restrictie a lui A Ei s t Ei s t = P 1 A proiectie de rang 1 a lui AClasa de Ansambluri de Entitati Ei s Ei s ⊆ { E i s 1 , E i s 2 , .. , E i s q } ⊆ P ( E i ‘ ) Obiect Baza de Date Logica BDL BDL = { E 1 , E 2 , .. , E mb } Baza de Date Fizica BDF BDF = { E 1 ’ , E 2 ’ , .. , E mb ’ } Fig. 4.1.1.4.1.2. Modelul ECV în expresii de Multimi si Relatii - Definire matematica
    • Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 173 VALORI CARACTERISTICI ENTITATI V C Notiuni Ei E vk C j ENTITATE Notiune Ei BAZA de DATE LOGICA BDL (c 1 , c 2 , …. , c i s , … , c m ) C 1 C 2 C m vk,j BAZA de DATE C 1 CLASA de ENTITATI FIZICA Ei BDF ENTITATECARACTERISTICA Obiect Cj Eir ( v 1 , v 2 , …. , v e ) Multimi de ENTITATI OBIECT E i‘ CLASA de ANSAMBLURI de ANSAMBLU de ENTITATI ENTITATI Obiecte C is ≡ Eis Ei s t Fig. 4.1.1.4.2.1 Modelul ECV reprezentat prin Multimi si Relatii
    • 174 Modele de Informatii / Modelul Obiectelor Abstracte4.1.2 Modelul Obiectelor Abstracte (OA) Modelul Obiectelor Abstracte descris în referinta bibliografica [SMIT82], a fostdezvoltat de autorii J.M. Smith si D.C.P. Smith, în jurul anilor ‘80, ca un instrumentpromitator de proiectare a structurilor în Spatiul Informatiilor, deci înainte de a fi precizat unModel de Date care sa implementeze, pe un sistem automat de calcul, structurile proiectate. Caurmare metodele propuse vor fi întâlnite în domeniul Proiectarii Conceptuale a Structurilorde Informatii.4.1.2.1 Procesul de Abstractizare Conceptele de Abstractizare fundamentate prin aceste cercetari vor sta la bazaProiectarii Obiectuale dezvoltate în deceniul care a urmat. Cu toate acestea consideram caModelul de Structura de Informatii prezentat ca rezultat al acestor cercetari este mult maigeneral, putându-si gasi aplicatii mai largi decât Programarea Orientata pe Obiecte (OOP –Object Oriented Programming). In domeniul Structurilor de Informatii se gaseste o asemeneaaplicare, care fara sa apeleze la Viziunea Obiectuala din Programarea Clasica, utilizeazaconceptele initiale pentru activitati foarte fertile, cum ar fi implementarea Generalizarii pentruoperatiile de Clasificare, a Agregarii pentru Relatiile de Asociere, descrierea Tipurilor deRelatii, operatii care pot transforma în proceduri automate activitatea de transpunere aproceselor de Agregare si Generalizare în Structuri de Date si de Proceduri, în cadrulSistemelor cu Baze de Date (vezi sectiunile 4.2.4.7.2 si 4.2.4.7.3). In deslusirea si definirea Entitatilor Notiune dintr-un Spatiu de Informatii seapeleaza în permanenta la un proces fundamental de Abstractizare, întelegând prin operatia deabstractizare initiata într-un sistem: “ o culegere de detalii ce pot fi denumite într-un mod convenabil ca un întreg “ . Aceasta operatie care utilizeaza una din caracteristicile de baza ale notiunii de Multimesi anume cea a unitatii elementelor, conferita de proprietatea comuna si care permite caMultimea sa fie privita si tratata ca un nou Element (o noua Entitate). Abstractizarea poate fi operata în doua planuri : o cel al Starilor unui Sistem si atunci conduce la definirea Obiectelor Abstracte o cel al Transformarilor unui Sistem si atunci conduce la definirea Operatiilor Abstracte Obiectele si operatiile definite prin acest proces primar de generalizare poarta numelede Obiecte Primitive sau Operatii Primitive. Primordiala în conceperea structurilor estedefinirea Obiectelor Abstracte, deoarece o definire corecta a acestora usureaza simtitor etapade definire a Operatiilor Abstracte. Se pot retine urmatoarele echivalente de termeni: Obiect Abstract ≡ Concept ≡ Entitate Notiune Cu aceste notiuni precizate, se poate afirma ca obiectivul Proiectarii Conceptuale aStructurilor este reprezentat de definirea Structurii Relative a Obiectelor Abstracte.
    • Modele de Informatii / Modelul Obiectelor Abstracte 1754.1.2.2 Obiecte Abstracte Generarea unor Obiecte Abstracte (OA) din alte obiecte abstracte ( rimitive sau PNeprimitive ) se face în doua moduri (vezi Generarea de Multimi din sectiunea 3.1.2): o Prin Generalizare - generarea unui Obiect Generic dintr-o Multime de Obiecte Categorie, corespunde operatiei de formare de multimi prin Regrupare de Multimi Parti o Prin Agregare - generarea unui Obiect Agregat dintr-o Relatie existenta între Multimi de Obiecte, corespunde operatiei de formare de multimi prin Combinare de Multimi4.1.2.2.1 Obiecte Generice Procesul de Generalizare permite realizarea operatiei de Clasificare a Entitatilor prinobservarea caracteristicilor Comune si a celor Specifice dupa modelul prezentat în Fig.4.1.2.2.1.1. Multimi de Obiecte Obiect Generic {Câine, Pisica, Elefant, Cal} Animal {Student, Profesor, Copil, Angajat} Persoana {Examen, Colocviu, Proiect} Verificare {Vehicol-Terestru, Vehicol-Aerian, Vehicol-Naval} Vehicol {Camion, Turism, Avion} Autovehicol {Producator, Beneficiar, Furnizor} Partener {O1 , O2 , O3 , .. , On } Og O g – Obiect Generic O c - Obiect Categorie O c este O g Generalizarea suprima diferentele între Categorii Fig. 4.1.2.2.1.1 Exemplificarea procesului de Abstractizare prin Generalizare Operatia de Clasificare include doua operatii inverse: o Generalizarea – pornind de la o multime de Obiecte Categorie se genereaza un Obiect Generic Procesul de Generalizare permite construirea unei noi Colectii de Informatii (ex. Persoana), pornind de la existenta altor Colectii de Informatii (ex. Student, Profesor, Copil, Angajat), prin recunoasterea unor Caracteristici Comune, ce vor fi transferate noii Colectii de Informatii. Caracteristicile Specifice Colectiilor Initiale vor continua sa le defineasca în parte, individualizându-le. In cadrul Noii Colectii, care va descrie în ansamblu Obiectul Generic, diferentierea Obiectelor Categorie va fi realizata cu ajutorul unui Criteriu de Clasificare atasat unui Domeniu de valori, prezent în colectie sub forma unui Atribut (ex. Tip-Persoana).
    • 176 Modele de Informatii / Modelul Obiectelor Abstracte o Specializarea – pornind de la un Obiect Generic se genereaza mai multe Obiecte Categorie Procesul de Specializare permite construirea unor noi Colectii de Informatii (ex. Student, Profesor, Copil, Angajat), pornind de la definirea unui Criteriu de Clasificare atasat unui Domeniu de valori ce va fi implementat în Colectia initiala sub forma unui Atribut (ex. Tip-Persoana). Domeniile de Valori, care descriu Criteruil de Clasificare, pot reprezenta fie Obiecte Primitive (vezi Fig. 4.1.2.2.1.2), fie Multimi de Valori de Identificatori ai unor Obiecte rezultate dintr-un proces de abstractizare anterior (vezi Fig. 4.1.2.2.1.3) Operatiile de Clasificare sunt reunite sub numele de Proces de Abstractizare prinGeneralizare. Conceptele ce stau la baza acestui proces sunt reprezentate în Fig. 4.1.2.2.1.2 siîn Fig. 4.1.2.2.1.3, ca doua variante de implementare a Criteriului de Clasificare. • Obiectul Abstract Generic PERSOANA ce urmeaza a fi Clasificat prin Generalizare • Obiectul Abstract Categorie Profesor ce rezulta din Obiectul Abstract Generic PERSOANA care are, ca Valoare a Atributului Tip-Persoana, Valoarea de Categorie Profesor • Realizare a Obiectului Abstract Categorie Profesor, reprezentat de o aparitie concreta a acestui Obiect Abstract • Atributul Categorie Tip-Persoana, care va fi ales ca si Criteriu de Clasificare • Valoare de Categorie (Profesor), reprezentata de o Valoare a Atributului Categorie în Obiectul Abstract Generic PERSOANA PERSOANA Marca Nume Prenume Vârsta Tip-Persoana Student M1 N1 P1 V1 Student M2 N2 P2 V2 Profesor Profesor M3 N3 P1 V3 Student M4 N4 P3 V2 Profesor Angajat M5 N5 P4 V4 Angajat Obiect Abstract Obiecte Abstracte Generic Categorie Fig. 4.1.2.2.1.2. Generalizarea cu Atribut de tip Categorie In legatura cu cele doua variante de implementare a Generalizarii se fac urmatoareleobservatii: - In exemplul din Fig. 4.1.2.2.1.2 Clasificarea se realizeaza prin simpla alegere a Atributului Tip-Persoana (corespunzator unui Domeniu de Valori anterior definit) si descrierea Colectiilor de Realizari: Studenti, Profesori, Copii, Angajati, prin considerarea Valorilor concrete ale acestui Atribut în cadrul PERSOANEI.
    • Modele de Informatii / Modelul Obiectelor Abstracte 177 • Obiectul Abstract Generic PERSOANA ce urmeaza a fi Clasificat prin Generalizare • Obiectul Abstract Categorie Profesor, ce rezulta din Obiectul Abstract Generic PERSOANA care are, ca Valoare a Atributului Tip-Persoana, Valoarea de Categorie Identificator de Profesor, • Realizare a Obiectului Abstract Categorie Profesor, reprezentat de o aparitie concreta a acestui Obiect Abstract • Atributul Categorie Tip-Persoana, care va fi ales si în acest caz ca si Criteriu de Clasificare • Valoare de Categorie (C2) reprezentata de o Valoare a Atributului Categorie în Obiectul Abstract Generic PERSOANA, reprezentata de data aceasta nu de Nume de Categorie, ci de Identificatorul de Realizare al Obiectului Abstract Categorie (TIP-PERSOANA) • Obiectul Abstract TIP-PERSOANA, care descrie un Criteriu de Clasificare ce urmeaza sa realizeze Generalizarea si care contine Valorile de Categorii ca si Valori ale Atributului Nume din TIP- PERSOANA • Realizare a Obiectul Abstract TIP-PERSOANA, care va reprezenta o aparitie concreta de Valoare de Categorie (Profesor ca Valoare de Nume TIP-PERSOANA) Obiecte Abstracte Categorie Student Profesor AngajatPERSOANA Marca Nume Prenume Vârsta Tip-Persoana TIP-PERSOANA M1 N1 P1 V1 C1 Cod Nume M2 N2 P2 V2 C2 C1 Student M3 N3 P1 V3 C1 C2 Profesor M4 N4 P3 V2 C2 C3 Copil M5 N5 P4 V4 C4 C4 Angajat Obiect Abstract Obiect Abstract Generic Criteriu de Clasificare Fig. 4.1.2.2.1.3. Generalizarea cu Obiect Abstract de tip Criteriu de Clasificare
    • 178 Modele de Informatii / Modelul Obiectelor Abstracte - Pentru cresterea Gradului de Consistenta a Colectiei de Date initiale se poate construi o noua Colectie de Date care descrie chiar Criteriul de Clasificare (TIP-PERSOANA), prin doua Atribute proprii: TIP-PERSOANA (Cod*, Nume) In Colectia Initiala este acum suficient sa înlocuim Valorile Atributului Tip- Persoana cu Identificatorul corespunzator din Colectia nou creata. Realizarea consistentei se manifesta, ca în cazul general, prin urmatoarele avantaje: • In structura anterioara sistemul nu poate sa verifice corectitudinea Numelor de Categorii (Student, Profesor, Copil, Angajat), putându- se strecura cu usurinta erori de actualizare, nu numai prin introducerea unor Categorii Neadmise, ci si prin simpla tastare incorecta a Numelor de Categorii • Modificarea unor Nume de Categorii, deja introduse în structura, necesita inspectia tuturor realizarilor Obiectului Generic pentru a modifica toate aparitiile Valorii Modificate4.1.2.2.2 Obiecte Agregate Procesul de Agregare permite construirea unei Colectii de Informatii pornind de ladefinirea unei Relatii între mai multe Domenii de Valori. Domeniile de Valori pot reprezentafie Obiecte Primitive (vezi definitia de mai jos), fie multimi de valori de Identificatori aiunor Obiecte rezultate dintr-un proces de abstractizare anterior. Exemplificarea modului deConstruire prin Agregare a obiectelor este redata în Fig. 4.1.2.2.2.1. Relatii între Obiecte Obiect Agregat Un tip de Persoana are un Cod si un Nume Tip Persoana O Persoana are o Marca, un Nume, un Prenume, o Vârsta Persoana si un Tip de Persoana Un Autovehicol are un Numar, un Producator, o Valoare Tip Element si o Categorie Un Vehicol transporta o Incarcatura, la o Data Transport catre o Destinatie Un Producator contracteaza cu un Furnizor un Serviciu de o Contract Valoare Og (O1 , O2 , O3 , .. , On ) O a – Obiect Agregat O c - Obiect Componenta O a are O c Agregarea suprima numele Componentelor Fig. 4.1.2.2.2.1 Exemplificarea procesului de Abstractizare prin Agregare
    • Modele de Informatii / Modelul Obiectelor Abstracte 179 Agregarea se naste dintr-o Relatie între alte Obiecte. Asa dupa cum Obiectul Genericse construieste din Obiecte de tip Categorie, Obiectul Agregat se construieste din Obiecte detip Componente. Agregarea preia în general numele Verbului din Relatia care îl defineste.Definitie: Obiect Primitiv – Obiectul Abstract Nedecompozabil, care nu are ca urmare în structura sa alte Obiecte Abstracte (nici Categorii, nici Componente).4.1.2.3 Ierarhii de Obiecte Abstracte Acelasi obiect poate fi privit simultan ca Obiect Generic, si ca Obiect Agregat, celedoua Procese de Abstractizare desfasurându-se simultan, pe mai multe nivele si conducând lagenerarea, în doua planuri distincte, a Ierarhiilor de Abstractizare: • Ierarhia de Generalizare • Ierarhia de Agregare Ierarhia de Generalizare va fi alcatuita din Categoriile Obiectelor AbstracteGenerice, desfasurate pe nivele succesive de subordonare. Ierarhia de Agregare va fi alcatuita din Componentele Obiectelor Abstracte Agregate,desfasurate pe nivele succesive de subordonare. Pentru exemplificare se prezinta o Structura de Informatii care descrie GestiuneaVehicolelor de Transport, ce cuprinde urmatoarele Obiecte: AUTOVEHICOL (Numar*, Producator*, Valoare, Categorie) PRODUCATOR (Companie*, Sediu) INTRETINERE (Autovehicol*, Data*, Mecanic) MECANIC (Nume*, Atelier) TRANSPORT (Autovehicol*, Data*, Destinatie, Incarcatura) Sa mai consideram urmatoarele clasificari semantice ale Obiectului VEHICOL.Aceasta se realizeaza prin precizarea Criteriilor de Clasificare împreuna cu Categoriile pentrufiecare Criteriu: o Mediu de Deplasare – Blocul B1 VEHICOL (Terestru, Aerian, Naval) o Mijloc de Propulsie – Blocul B2 VEHICOL (Auto, Manual, Naval) o Încarcatura – Blocul B3 VEHICOL (Persoane, Marfa)
    • Modele de Informatii / Modelul Obiectelor Abstracte 180 VEHICOL B1 B2 B3Terestru Aerian Naval Auto Manual Hipo Persoane Marfa C1 C2 C3 C4 C5 C6 C7 C8 Fig. 4.1.2.3.1 Structura pe Blocuri a Categoriilor VEHICOL Terestru Auto AerianBicicleta Camion Turism Avion Planor C11 C41 C42 C43 C21 Marca Marca Marca Marca M1 M2 M3 M4 Fig. 4.1.2.3.2 Ierarhii de Generalizare
    • Modele de Informatii / Modelul Obiectelor Abstracte 181 INTRETINERE TRANSPORT AUTOVEHICOL Data Destinatie Incarcatura MECANIC DataNume Atelier Numar PRODUCATOR Valoare Categorie Companie Sediu Fig. 4.1.2.3.3 Ierarhia de Agregare
    • 182 Modele de Informatii / Modelul Obiectelor Abstracte Rezulta în mod direct gruparea pe Blocuri a Categoriilor, daca se respecta conditia caMultimile de Categorii pe Blocuri sa fie Disjuncte (Fig. 4.1.2.3.1). Conditia ca Blocurile sa fiedisjuncte este fireasca daca se tine seama de urmatoarele restrictii impuse de ModelulObiectelor Abstracte: - Fiecare Criteriu de Clasificare, deci fiecare Bloc va fi atasat unui Atribut de tip Categorie din Obiectul Generic - Fiecare Atribut reprezinta un Obiect Primitiv, deci Nedecompozabil In Fig. 4.1.2.3.2 este reprezentata o Ierarhie de Generalizare bazata pe clasificarileanterior prezentate. In Ierarhia de Generalizare se observa prezenta unor Categorii distribuitepe mai multe nivele si care sunt partajate de mai multe Categorii aflate pe nivele superioare.Nu se încalca însa restrictia de disjunctivitate întrucât atunci când se va dori cuprindereaîntregului Arbore de Clasificare, în Lista de Atribute vor trebui sa se regaseasca toate Criteriilede Clasificare, a caror combinare de Valori va asigura acoperirea Ierarhiei de Generalizareprezentata. In exemplul care va fi folosit la prezentarea Ierarhiei de Agregare se recurge la osimplificare a Ierarhiei de Generalizare datorita interesului acordat doar Obiectului AbstractAUTOVEHICOL. In Ierarhia de Agregare (Fig. 4.1.2.3.3) se regasesc cele cinci Obiecte Abstracte:AUTOVEHICOL, PRODUCATOR, INTRETINERE, MECANIC, TRANSPORT, împreuna cuObiectele de tip Componente. Se poate remarca: - Prima categorisire a tipurilor de Atribute este legata de posibilitatea de Identificare a Obiectelor: § Identificatori reprezentati de Atributele marcate cu asterisc § Descriptori reprezentati de celelalte Atribute - Orice Descriptor apare doar într-un Obiect Abstract - Existenta a doua tipuri de Atribute în Ierarhia de Agregare si anume: § Categorii - Valori de Categorii ale Obiectului Abstract AUTOVEHICOL § Componente - restul Atributelor care descriu continutul Obiectului Abstract4.1.2.4 Realizari de Obiecte Abstracte Reprezentarea Ierarhiilor de Generalizare si de Agregare se continua prin desfasurarealor în planul Realizarilor, în momentul implementarii. Desfasurarea se realizeaza prinInstantierea cu Valori a Obiectelor Abstracte. Imaginile astfel obtinute sunt cele ale Tabelelorcare corespund Relatiilor, deci corespund de la bun început modului de constructie prinAgregare, specific Relational. Fiecarui Obiect Abstract îi corespund mai multe Realizari (Instante) în Spatiul deInformatii si implicit ulterior în Spatiul Datelor. Preluând conceptele dezvoltate cu ocaziaintroducerii nivelelor Logic si Fizic de descriere a Informatiilor si Datelor putem sa operamurmatoarea adaptare: § La nivel Logic – se defineste Tipul de Obiect Abstract (Definire Intensionala)
    • Modele de Informatii / Modelul Obiectelor Abstracte 183 § La nivel Fizic – se Instantiaza prin Valori Tipul de Obiect Abstract (Definire Extensionala); Instanta mai poarta si numele de Token In construirea Planului Realizarilor de Obiecte Abstracte (OA) se au în vedereurmatoarele Reguli de Reprezentare: o Orice Realizare de OA e reprezentata de Identificatorii Realizarilor Componentelor sale o Realizarile Obiectelor Primitive sunt Autoidentificabile o Realizarile Obiectelor Neprimitive sunt Identificabile Asociativ, prin declararea unui numar suficient de Identificatori de Componente (Atribute), care vor defini o Cheie o Atributele Tipului de Obiect Abstract sunt Componentele si Categoriile (sub forma de Nume) o Atributele Realizarii de Obiect Abstract sunt Realizarile de Componente si Categorii (sub forma de Valori) o Identificarea OA este Asociativa, întrucât se face cu ajutorul Identificatorilor de Componente, deci a Valorilor de Componente Un exemplu de reprezentare a unui OA în Planul Realizarilor e data în Fig. 4.1.2.4.1. AUTOVEHICOL Numar* Producator* Valoare Categorie N1 P1 V1 C42 N2 P2 V2 C41 N3 P1 V3 C41 N4 P3 V4 C43 N5 P4 V5 NULL Identificatori de Realizari Identificatori de Realizari de Componente de Categorii Fig. 4.1.2.4.1 Realizarile OA AUTOVEHICOL4.1.2.5 Ierarhii de Obiecte Abstracte în Planul Realizarilor Pentru construirea de Ierarhii de Agregare în Planul Realizarilor se face apel laurmatoarele Reguli de Reprezetare: o Fiecare OA are un Identificator (Cheie) o Fiecare Realizare de Componenta este reprezentata de Identificatorul de Realizare (prin Referire Asociativa) si nu de Realizarea propriuzisa; Aceasta determina: • Simplificarea reprezentarii prin eliminarea Redondanta si asigurarea Consistentei
    • 184 Modele de Informatii / Modelul Obiectelor Abstracte • Realizarea referita trebuie sa fie deja definita • Se asigura Ierarhizarea Realizarilor în Planul de Agregare • Se asigura partajarea Realizarilor prin Referire Multipla o Exista Realizari de OA care nu apar în nici-o Relatie (nu sunt referite de nici-o alta Realizare a altui OA) Regulile prezentate sunt ilustrate de exemplul continut în Fig. 4.1.2.5.1. Din aceasta prezentare se remarca faptul ca Modelul Obiectelor Abstracte se aseamana,în punctele esentiale este chiar identic, cu Modelul Relational. In continuare se vor semnala sideosebiri, în special în forma de implementare a Generalizarii. Asemanarile însa ramânpreponderente si ele atrag atentia, întrucât punctele de pornire si caile parcurse de cele douaModele difera: - Modelul Relational porneste de la definirea matematica, formala si riguroasa a Multimilor si Relatiilor - Modelul Obiectelor Abstracte porneste de la Principii Logice de formare a Conceptelor, punând accent pe procesul mental de Reflectare a Realitatii INTRETINERE MECANIC Autovehicol* Data* Mecanic Nume* Atelier N1 D1 M1 M1 A1 N2 D2 M1 M2 A2 AUTOVEHICOL Numar* Producator* Valoare Categorie PRODUCATOR N1 P1 V1 C42 Companie * Sediu N2 P2 V2 C41 N1 S1 N3 P1 V3 C41 N2 S2 N4 P3 V4 C43 TRANSPORT Autovehicol* Data* Destinatie Incarcatura N1 D1 T1 I1 N2 D2 T2 I2 N3 D1 T1 I3 Fig. 4.1.2.5.1 Ierarhie de Agregare în Planul Realizarilor In cazul transpunerii OA în Planul Realizarilor (vezi Figurile 4.1.2.5.1 si 4.1.2.5.2)trebuie respectate urmatoarele Reguli de Reprezentare:
    • Modele de Informatii / Modelul Obiectelor Abstracte 185 o Obiectul Abstract Generic desfasurat în Planul Realizarilor va avea doua tipuri de Componente: • Componente Comune, care pot fi: Transferabile (Mostenite) sau Netransferabile asupra OA Categorie • Componente Specifice, care caracterizeaza si individualizeaza OA de tip Categorie o Realizarile Obiectului Generic si ale Obiectelor Categorie, care descriu aceeasi realitate se numesc Imagini Reciproce (ale aceluiasi Obiect) o In Imaginile Reciproce de OA, Componentele Comune trebuie sa fie identice o Fiecare Realizare de OA din Planul de Generalizare nu apare în mai mult de o Categorie de OA (pentru a respecta restrictia dupa care Valoarea Categoriei în orice OA e Unica si nu Multipla) Aceasta conditie impusa asigura tratarea unitara a Realizarilor de Componente si de Categorii. o O multime de Categorii Disjuncte ale unui OA formeaza un Bloc (vezi Fig. 4.1.2.3.1), care corespunde unui Criteriu de Clasificare Unic Avion (C43)Imagini Reciproce Numar* Producator* Valoare Nr-Aripi ale OA N4 P4 V4 A1 Autovehicol N1 Turism (C42) Numar* Producator* Valoare Nr-Usi N1 P1 V1 U1 Camion (C41) Numar* Producator* Valoare Tonaj N2 P2 V2 T1 N3 P1 V3 T2 AUTOVEHICOL Numar* Producator* Valoare Categorie N1 P1 V1 C42 N2 P2 V2 C41 N3 P1 V3 C41 N4 P3 V4 C43 N5 P4 V5 NULL Fig. 4.1.2.5.2 Ierarhie de Generalizare în Planul Realizarilor
    • 186 Modele de Informatii / Modelul Obiectelor Abstracte4.1.2.6 Relativitatea Viziunii asupra Obiectelor Abstracte Pentru a putea discuta acest subiect vom face referire la Figurile 4.1.2.2.1.2 si4.1.2.2.1.3. Totodata vom schita în Fig. 4.1.2.6.1 o Ierarhie de Generalizare cu considerareaBlocurilor din Fig. 4.1.2.3.1, la care adaugam si elemente din Ierarhia de Agregare (vezi OAAUTOVEHICOL si INTRETINERE). Ierarhiile vor fi reprezentate în Planul Realizarilor. Relativitatea Viziunii asupra Obiectelor Abstracte nu sterge nimic din precizia dedefinire a acestora. Ea provine din unghiul de vedere al Utilizatorului asupra Structurii de OAsi totodata din raporturile multiple în care OA este angajat. Aceste raporturi multiple suntdatorate generalitatii de definire a OA ca Unic Constructor al Structurilor de Informatii. OApoate îndeplini simultan mai multe functii în cadrul Structurii de Informatii. Dintre acestefunctii multiple enumeram: o OA Agregat cu Realizari Multiple – este functia de baza cu care OA este definit si introdus în sistem, prin precizarea continutului sau principal de informatii, adus de OA de tip Componente si / sau Categorie o OA Categorie cu Realizari Multiple – OA de tip Criteriu de Clasificare care provine în general dintr-un OA de tip Categorie, referit în definirea unui OA Generic o Realizare de OA – Instanta de OA este considerata tot OA, dar în Planul Realizarilor o OA Primitiv – OA Nedecompozabil, care apare pe post de Atribut al unui alt OA, cu functia de : § OA de tip Componenta când apare ca: • Atribut Autoidentificabil pe post de Componenta • Identificator de OA care refera de pe post de Componenta un alt OA § OA de tip Categorie care contribuie la: • Descrierea unui nou OA si includerea lui în sistem • Generalizarea unui OA deja existent în sistem Privit dintr-un punct de vedere exterior Modelului OA un Obiect Abstract poateîndeplini functii diverse de reprezentare: - Functie de Entitate – OA descrie o Existenta printr-o Multime de Atribute - Functie de Relatie – OA descrie o Legatura între alte OA - Functie de Atribut – OA descrie o Însusire Elementara Acest punct de vedere este sistematic reprezentat în Tab. 4.1.2.6.2, care ilustreazadiversele ipostaze ale OA, rezultate în etapele succesive de Abstractizare. Se regasescregrupate conceptele cu care opereaza Modelul Obiectelor Abstracte. Este oferita totodataechivalarea acestor concepte cu notiunile care au fost introduse în cadrul Modelului Entitate –Caracteristica – Valoare.
    • Modele de Informatii 187 INTRETINERE Vehicol-Naval (C3) Vehicol-Hipo (C6) Autovehicol* Data* Mecanic N1 D1 M1 N2 D2 M1 Vehicol-Aerian (C2) Vehicol-Manual (C5) Vehicol-Marfa (C8) Vehicol-Terestru (C1) Autovehicol (C4) Vehicol-Persoane (C7) Auto N1 P1 V1 C41VEHICOL Numar* Producator* Valoare Mediu de Mijloc de Incarcatura MIJLOC-PROPULSIE Deplasare Propulsie Cod* Nume Grad Putere N1 P1 V1 C4 Poluare Tipica N2 P2 V2 C4 C4 Auto G1 P3 N3 P1 V3 C4 C5 Manual G2 P2 N4 P3 V4 C4 C6 Hipo G3 P5 N5 P4 V5 C4 Viziuni ale Obiectului Abstract AUTOVEHICOL - Obiect Abstract Agregat cu mai multe realizari - Realizare de Obiect Abstract - Obiect Abstract Categorie cu mai multe realizari - Valoare de Categorie - Obiect Abstract Primitiv Componenta - Realizare de Obiect Abstract Categorie - Obiect Abstract Primitiv Categorie Fig. 4.1.2.6.1 Viziunile Multiple ale Obiectului Abstract AUTOVEHICOL
    • Modele de Informatii 188 COMPONENTA VALOARE de PRIMITIV COMPONENTA ATRIBUT CATEGORIE VALOARE de OBIECT CATEGORIEABSTRACT AGREGARE OBIECT ABSTRACT RELATIE AGREGAT OBIECT ABSTRACT NOTIUNE NEPRIMITIV COMPONENTA ENTITATE GENERALIZARE OBIECT ABSTRACT GENERIC OBIECT OBIECT ABSTRACT CATEGORIE Tab. 4.1.2.6.2 Relativitatea viziunii utilizatorului asupra Obiectelor Abstracte
    • Modele de Informatii / Modelul Obiectelor Abstracte 1894.1.2.7 Sintaxa Abstracta Definirea structurilor în Modelul Obiectelor Abstracte se face prin intermediul unuiLimbaj de Descriere, a carui Sintaxa este descrisa cu ajutorul Metalimbajului prezentat înFig. 4.1.2.7.1. Limbajul, concis si simplu, permite declararea Obiectelor Abstracte prin: o Numirea OA cu ajutorul Simbolurilor Unice o Precizarea Identificatorilor de Instanta pentru OA, prin intermediul Cheilor o Indicarea Continutului OA: § Componentele OA – cu precizarea Componentelor Comune si Specifice, prin intermediul Conditiei de Aparitie § Categoriile OA – cu precizarea Ierarhiei de Categorii prin intermediul Conditiei de Aparitie si totodata cu enumerarea Valorilor Admise de Categorii (pentru detalii legate de construirea prin Generalizare a Obiectelor Abstracte vezi Figurile 4.1.2.3.1 si 4.1.2.3.2) def < obiect> obiect [cheie] < componenta > [conditie] ; < componenta > [conditie] ; . . . < componenta > [conditie] ; < componenta > = (categorie , categorie , ... , categorie) [conditie] ; < componenta > = (categorie , categorie , ... , categorie) [conditie] ; . . . < componenta > = (categorie , categorie , ... , categorie) [conditie] ; end unde : cheie → componenta, componenta, .. , componenta conditie → componenta categorie = valoare categorie Fig. 4.1.2.7.1 Sintaxa Abstracta pentru Limbajul de Definire a Obiectelor Abstracte Fata de modelul de descriere oferit de autori s -au luat în considerare urmatoarelecompletari: o descrierea Componentelor Condi tionale prin adaugarea în limbaj a Conditiei de Prezenta a Componentelor în corpul obiectului, cu urmatoarele consecinte: § In cazul Componentelor Simple - prezenta Conditiei permite delimitarea Componentelor Comune si a celor Specifice, pentru Imaginile Reciproce ale Obiectelor Individuale
    • 190 Modele de Informatii / Modelul Obiectelor Abstracte § In cazul Componentelor de tip Categorie - prezenta Conditiei usureaza descrierea Arborilor de Clasificare desfasurati pe nivele multiple, prin concentrarea descompunerii în Blocuri a Categoriilor § In ambele cazuri - prezenta Conditiei micsoreaza simtitor numarul de Obiecte Abstracte care se cer descrise explicit în Modelul Conceptual, fara însa a reduce finetea de rafinare în definirea Obiectelor de tip Categorie, a caror identificare poate fi facuta automat de sistem , prin preluarea Valorii de Categorie, în calitate de Nume de Obiect de tip CategorieExemplu: Ca exemplificare a Sintaxei Abstracte se da în continuare, în Fig. 4.1.2.7.2, descrierea Structurii Organizatorice a unei Unitati de Învatamânt Superior. Structura prezentata este de tip Recursiv, m – n. def UNITATE obiect Cod Cod; Nume; Tip (Universitate, Facultate, Specializare, Profil, An, Grupa, Subgrupa, Secretariat, .. ,) end def UNITATE_CRONOLOGICA obiect Cod, Data_Inceput Cod; Data_Inceput; Data_Sfarsit; Nume; Forma_Invatamant (Facultate, Colegiu, Masterat, .. ,); Profil (Tehnic, Economic, Matematic, .. ,) Acreditare (Da, Nu) end def STRUCTURA obiect Unitate_Curenta,Unitate_Asscendenta Unitate_Curenta; Unitate_Asscendenta; Tip (Organizatorica, Functionala, Admitere, .. ,) end Fig. 4.1.2.7.2 Structura Organizatorica Universitara (descriere ca structura de OA Se remarca regruparea în cadrul unui singur OA a tuturor OA de tip Categorie(Universitate, Facultate, Specializare, Profil, An, Grupa, Subgrupa, Secretariat). Pentrusimplificare este prezentata doar varianta de implementare cu Atribute de tip Categorie (Fig.4.1.2.2.1.2)
    • Modele de Informatii / Modelul Obiectelor Abstracte 1914.1.2.8 Operatii Abstracte A doua directie de abstractizare în Modelul OA se efectueaza în PlanulTransformarilor la care sunt supuse Obiectele Abstracte si are ca rezultat definireaOperatiilor Abstracte. Întrucât în orice Structura definita, problema care se pune este cea dePastrare a Integritatii ei în urma Transformarilor pe care le sufera, în definirea OperatiilorAbstracte intereseaza Setul Minim de Operatii care asigura mentinerea Semanticii Agregariisi a Generalizarii continute în Structura de Informatii. Operatiile care actioneaza în cadrulModelului Obiectelor Abstracte se împart în doua categorii: o Operatii Primitive - operatii ce actioneaza direct asupra Realizarilor de Obiecte o Operatii de Utilizator - operatii ce actioneaza asupra Obiectelor IndividualeDefinitie: Prin Obiecte Individuale se întelege Ansamblul tuturor Realizarilor de OA care descriuîn Modelul Obiectelor Abstracte aceeasi Existenta din Spatiul Informatiilor.4.1.2.9 Principiul Conservarii Semantice Autorii formuleaza Principiul Conservarii Semantice a Obiectelor Individuale astfel: Fiecare Operatie de Utilizator trebuie sa pastreze Integritatea Obiectelor Individuale. Un set de cinci restrictii sunt definite pentru precizarea Conditiilor de Pastrare aIntegritatii Obiectelor Individuale. Acestea sunt: 1. Fiecare Realizare (Instanta) de Categorie trebuie sa aiba o Imagine în Realizarile (Instantele) Obiectelor Abstracte (întrucât o Valoare de Categorie defineste un OA Categorie, ca o submultime de Realizari ale OA Generic – Fig. 4.1.2.6.1) 2. Daca exista o Valoare de Componenta Categorie c1 într-o Realizare de Obiect Abstract Categorie OAC1, care este Imaginea Realizarii de Obiect Abstract în Planul de Generalizare, atunci va exista si o Valoare (Realizare) de Categorie c1 în Obiectul Abstract Categorie, care descrie Structura pe Categorii a Obiectului Generic OA (Fig. 4.1.2.2.1.3) 3. Imaginile de Realizari trebuie sa fie Consistente (toate Valorile Componentelor Comune sa fie Identice si Valoarea Atributului Categorie în Imagine sa fie egala cu Valoarea unei Realizari de Categorie – vezi Figurile citate anterior) 4. Valorile Componentelor Cheie în Realizarile de Obiecte Abstracte trebuie sa fie Unice (fiecare Imagine trebuie sa fie identificabila în Planul de Agregare) 5. Atributele oricarei Imagini trebuie sa fie Identificatori de Realizari de Obiecte Abstracte deja existente
    • 192 Modele de Informatii / Modelul Obiectelor Abstracte4.1.2.10 Metodologia de Proiectare în Modelul OA In finalul prezentarii Modelului Obiectelor Abstracte autorii stabilesc urmatoareaMetodologie de Proiectare a Structurilor de Informatii. Etapele si pasii propusi pentrufiecare etapa se vad în Fig. 4.1.2.10.1.1.4.1.2.10.1 Continutul Metodologiei de Proiectare Metodologia consta dintr-o suita de cinci pasi subdivizati în faze: o Definirea Dictionarului Obiectelor Abstracte § Stabilirea, în urma Analizei Cernitelor, a Obiectelor ce urmeaza a fi tratate si care constituie o Categorie Primara, Categoria Obiectelor Abstracte o Construirea Planului de Generalizare § Determinarea corespondentei Obiect - Categorie § Împartirea Categoriilor fiecarui obiect în Blocuri o Construirea Planului de Agregare § Determinarea corespondentei Obiect – Componenta o Construirea Planului de Realizari de Obiecte § Determinarea Valorilor de Chei pentru fiecare Obiect § Determinarea Valorilor Categoriilor fiecarui Obiect § Determinarea Valorilor Categoriilor pe Bloc pentru fiecare Categorie o Descrierea structurii cu ajutorul Sintaxei Abstracte § Specificarea pentru fiecare Obiect a Componentelor, Categoriilor si CheilorFig. 4.1.2.10.1.1 Modelul Obiectelor Abstracte (Metodologia de Proiectare) Este de notat simplitatea metodei propuse si totodata utilitatea informatiilor culesepentru construirea ulterioara a unui Model de Date. In special atunci când Modelul de Dateprevazut este Relational majoritatea informatiilor îsi gasesc corespondenta directa cuelementele de structura cu care urmeaza sa se faca implementarea. In sensul de evidentiere a acestor corespondente între Modelul Obiectelor Abstracte siModelele de Date va fi purtata si discutia referitoare la Implementarea Relationala aProceselor de Abstractizare (vezi sectiunea 4.2.4.7.3).
    • Modele de Informatii / Modelul Obiectelor Abstracte 1934.1.2.10.2 Erori de Utilizare a Metodologiei Pentru a asigura Principiul Integritatii Obiectelor Individuale se cere a se analiza cuatentie anumite capcane care pot abate Metodologia de la acest deziderat, afirmat înca înpreambulul prezentarii Modelului Obiectelor Abstracte. Câteva cazuri sugestive sunt oferite încele ce urmeaza, sub forma unor erori de concepere a Structurilor OA, pentru care se ofera sisolutii de remediere.4.1.2.10.2.1 Stabilirea Categoriilor Directe Sa consideram OA de tip Categorii din Fig. 4.1.2.10.2.1.1. Ierarhia de Generalizareeste eronata datorita nivelului pe care apare Categoria Amfibiu. Motivele sunt urmatoarele: - Categoriile descrise nu sunt Disjuncte - Amfibiu nu este o Categorie Imediata (Directa) a OA VEHICOL, întrucât ea este simultan o Categorie a altor doua OA: • VEHICOL Terestru • VEHICOL Acvatic - Categoria Amfibiu nu poate fi adaugata în Ierarhia de Generalizare înaintea celor doua Categorii de care depinde VEHICOL Terestru Acvatic Amfibiu Fig. 4.1.2.10.2.1.1 Categorii Indirecte Pentru aceste consideratii se impune modificarea Ierarhiei de Generalizare dupa cumeste ilustrat în Fig. 4.1.2.10.2.1.2. VEHICOL Terestru Acvatic Amfibiu Fig. 4.1.2.10.2.1.2 Categorii Directe
    • 194 Modele de Informatii / Modelul Obiectelor Abstracte4.1.2.10.2.2 Stabilirea Componentelor Directe Daca în primul caz semantica este bazata pe cunostinte obisnuite de limbaj, în acest aldoilea caz trebuie pornit de la o precizare expresa pe care Utilizatorul o face în legatura cusemantica continuta în Spatiul de Informatii pe care doreste sa-l modeleze. Aceasta cunostinta suna în cazul exemplificat astfel: Înscrierea Studentilor se face numai dupa ce s-a format o Clasa INSCRIERE CLASA STUDENT Curs* An* Instructor Marca* Nume Prenume Vârsta Fig. 4.1.2.10.2.2.1 Componente Indirecte In aceste conditii Ierarhia de Agregare a Obiectelor Abstracte din Fig. 4.1.2.10.2.2.1este eronata deoarece: - Permite construirea OA INSCRIERE înainte ca OA CLASA sa existe - Nu se respecta Integritatea Obiectelor Individuale (este vorba de referirea unui OA care nu exista în structura) - Componentele Curs si An nu sunt Componente Directe ale OA INSCRIERE INSCRIERE STUDENT CLASA Marca* Nume Prenume Vârsta Curs* An* Instructor Fig. 4.1.2.10.2.2.2 Componente Directe
    • Modele de Informatii / Modelul Obiectelor Abstracte 195 Pentru a corecta Structura OA Curs si An vor trebui legate la OA INSCRIERE doar prinOA CLASA, dupa cum se vede în Fig. 4.1.2.10.2.2.2. Acum pentru a introduce un OAINSCRIERE trebuie în prealabil definite OA CLASA si STUDENT.4.1.2.10.2.3 Identificarea Incompleta Având la baza Referirea Asociativa, Modelul OA trebuie sa impuna restrictia deCompleta Identificare a fiecarei Instante (Realizari) de OA. Pentru toate cazurile în careaceasta conditie nu este respectata se adauga Componente la Identificator. Acest motiv face caîn Ierarhia de Realizari de OA Cheia sa fie precizata pentru fiecare OA.4.1.2.10.2.4 Tratarea Obiectelor Abstracte de tip Rol Exista Obiecte Abstracte ce se definesc printr-o Relatie, legata de un anume moment întimp, si care dispar odata cu disparitia Relatiei care le-a definit. Aceste Obiecte Abstracte senumesc Roluri. Întrucât prezenta lor este determinata de alte OA de care ele depind, se discutastatutul lor în cadrul Structurii de OA. De data aceasta dificultatea este creata de lipsa deIndependenta a unui OA, care urmeaza sa fie încorporat în structura.Exemplu: Sa consideram evenimentul CASATORIE. El va defini Obiecte legate de acest eveniment, cum ar fi: (MIRE, MIREASA, NAS, NASA) Ele provin din Obiectul Abstract PERSOANA, dar ramân legate de Relatia de Definitie CASATORIE. Fig. 4.1.2.10.2.4.1 reda Ierarhia de Agregare pentru aceste Obiecte. In exemplul prezentat se remarca urmatoarele particularitati: - Desi Atributele: Mire, Mireasa, Nas, Nasa, Ofiter al Starii Civile, Componente ale OA CASATORIE, reprezinta toate Functii în evenimentul CASATORIE, statutul lor de independenta este diferit - Atributele: Mire, Mireasa, Nas, Nasa nu pot fi tratate ca si Componente Obisnuite ale Obiectului Abstract CASATORIE, întrucât nu exista independent, ca OA de sine statatoare, care sa poata fi referite prin Identificatori de Instanta - Atributul Ofiter al Starii Civile poate fi privit ca OA, caci exista independent de Relatia CASATORIE, cu toate ca si el reprezinta o Functie în OA CASATORIE, dar nu este dependent de el, fiind definit anterior evenimentului - MIRE, MIREASA, NAS, NASA sunt Roluri si nu Obiecte Abstracte Obisnuite, caci depind de Obiectul Abstract CASATORIE, care le defineste - Definirea Rolurilor MIRE, MIREASA, NAS, NASA ca Obiecte Abstracte de tip Categorie ale OA Generic PERSOANA întâmpina dificultati datorita aparitiei si disparitiei lor, independenta de Valoarea Categoriei atasate (Rol în Casatorie)
    • Modele de Informatii / Modelul Obiectelor Abstracte 196 CNP – Cod Numeric Personal PERSOANA CASATORIECNP* Nume Prenume Vârsta Ofiter al Starii Civile Mire Mireasa Nas Nasa Numar* Data* Loc Fig. 4.1.2.10.2.4.1 Definire Roluri în Casatorie (Ierarhie de Agregare) Bloc B1 – Meserie PERSOANA Bloc B2 – Rol în Casatorie B1 B2 Ofiter al Doctor Profesor Balerina Mire Mireasa Nas NasaStarii Civile C12 C13 C14 C21 C22 C23 C24 C11 Fig. 4.1.2.10.2.4.2 Definire Roluri în Casatorie (Ierarhie de Generalizare)
    • Modele de Informatii / Modelul Obiectelor Abstracte 197 Balerina (C14) Nasa (C24) Profesor (13) Nas (C23) Doctor (C12) Mireasa (C22) Ofiter Stare Civila (C11) Mire (C21) PERSOANA CNP* Nume Prenume Vârsta Meserie Rol în Casatorie N1 P1 P1 V1 C11 NULL N2 P2 P2 V2 C12 C23 N3 P1 P3 V3 C13 C24 N4 P3 P4 V4 C13 C21 N5 P4 P5 V5 C14 C22 CASATORIE Numar* Data* Loc Ofiter Mire Mireasa Nas Nasa Stare Civila N1 D1 L1 N1 N4 N5 N2 N3 N2 D1 L1 N1 N6 N7 N2 N3 N3 D2 L1 N1 N9 N8 N4 N5 Fig. 4.1.2.10.2.4.3 Definire Roluri în Casatorie (Ierarhie de Agregare – Varianta 1)
    • Modele de Informatii / Modelul Obiectelor Abstracte 198 Balerina (C14) Profesor (13) Doctor (C12) Ofiter Stare Civila (C11) PERSOANA CNP* Nume Prenume Vârsta Meserie N1 P1 P1 V1 C11 N2 P2 P2 V2 C12 N3 P1 P3 V3 C13 N4 P3 P4 V4 C13 N5 P4 P5 V5 C14 CASATORIE Numar* Data* Loc Ofiter Stare Civila Mire Mireasa Nas Nasa Pesoana Pesoana Pesoana Pesoana N1 D1 L1 N1 N4 N5 N2 N3 N2 D1 L1 N1 N6 N7 N2 N3 N3 D2 L1 N1 N9 N8 N4 N5 Fig. 4.1.2.10.2.4.4 Definire Roluri în Casatorie (Ierarhie de Agregare – Varianta 2)
    • Modele de Informatii / Modelul Conceptual 199 In continuare se prezinta doua solutii de tratare a Obiectelor de tip ROL.Solutia 1: In aceasta varianta de tratare: - Se evita recunoasterea Rolurilor la Nivel Conceptual (Nivelul de Definire a OA) - Rolurile apar numai la Implementare (Nivelul de Definire a Realizarilor de OA) - Rolurile, privite ca Obiecte Abstracte Categorie vor fi actualizate în functie de actualizarile operate în Relatia de care depind - Rolurile se considera Obiecte Abstracte Virtuale, care se recreeaza în Planul Realizarilor de OA din alte OA (în speta din PERSOANA si CASATORIE). Modul de recreare a Obiectelor Abstracte Virtuale este redat de schemele din Figurile mentionate mai jos: § Ierarhia de Generalizare cuprinzând Criteriul de Clasificare Rol în Casatorie (Blocul B2 ) – vezi Fig. 4.1.2.10.2.4.2 § Ierarhia OA în Planul Realizarilor reprezentata în Fig. 4.1.2.10.2.4.3Solutia 2: In aceasta varianta de tratare: - Obiectul va fi tratat ca Rol în cadrul Relatiei de Definitie - Rolul va apare si va dispare odata cu Relatia de Definitie, implicând dependenta Obiectelor Abstracte de Relatii - Apar Structuri Ierarhice în definirea Obiectelor Abstracte Ierarhia OA în Planul Realizarilor pentru aceasta varianta de structura este reprezentata în Fig. 4.1.2.10.2.4.3. Mentionam ca si în acest caz este folosita Ierarhia de Generalizare din Fig. 4.1.2.10.2.4.2. Se poate observa faptul ca problema definirii corecte a Rolurilor în Structurile cu careopereaza Bazele de Date este foarte utila. Modelul Relational vine sa ofere o multime de solutiide implementare pentru conceptele promovate de Modelul Obiectelor Abstracte, în special celelegate de implementarea Generalizarii Obiectelor Abstracte si a Rolurilor Abstracte. Inîncheiere gasim utila prezentarea unor solutii de implementare a OA într-un Model de DateRelational, solutii care dau o rezolvare practica multor probleme ridicate: - Implementarea Operatiilor de Abstractizare prin Structuri Relationale consacrate, care sa ofere baza pentru o transpunere automatizata a Modelului Obiectelor Abstracte în Structura Logica Relationala (vezi sectiunea 4.2.4.7.3) - Evitarea Mosteniri Datelor Comune în cazul implementarii Obiectelor Abstracte de tip Categorie, prin utilizarea Referirii Asociative la Obiectul Generic - Implementarea Obiectelor Abstracte de tip Rol utilizând Relatii adecvate de Generalizare, combinate cu Relatii d tip Legatura (vezi sectiunea 4.2.4.7.3) - Implementarea Obiectelor Individuale prin utilizarea Nivelului Extern al Bazelor de Date Relationale - Implementarea Operatiilor Abstracte asupra Obiectelor Individuale prin utilizarea Procedurilor Stocate
    • 200 Modele de Date4.1.3 Modelul Conceptual Modelul Conceptual ce urmeaza a fi schitat poate fi privit ca solutie de viitor pentrureprezentarea Informatiilor. El încearca sa sintetizeze acumularile facute pâna în prezent îndescrierea Spatiului de Informatii. Modelul propus se arata a fi realizabil si stimulativ, însensul posibilitatii sale de implementare si totodata de adâncire a sensurilor si semnificatiilorinformatiilor implicate. Analizând rezultatele obtinute în directia perfectionarii Structurii Elementare care sareprezinte un posibil Constructor Unic de Structura în domeniul reprezentarii Informatiilor, amconstatat ca toate încercarile converg, în mod firesc, spre forma naturala de Reflectare aRealitatii, care este Notiunea din Logica. Redam mai jos o definire prin caracteristici aNotiunii [BOTE97]: o Este Forma Logica Elementara care reprezinta în planul cunoasterii rationale Reflectarea Claselor de Obiecte o Reprezinta Sinteza Cunostintelor referitoare la un Obiect determinat o Descrie Fiinta Obiectului, Unica si Constanta o Exprima Esenta Obiectelor, prin precizarea Notelor lor Comune si Stabile o Defineste o Clasa de Obiecte ca o Unitate o Un Element al Ansamblului Termen: Notiune (Forma Logica) – Nume (Forma Lingvistica) Întrucât în limbajul uzual Notiunea este recunoscuta ca sinonim al Conceptului, înModelul Conceptual s-a optat pentru aceasta a doua forma. Desi consideram deschisa calea catre rafinari de genul celor continute în definirearaporturilor Functie – Concept si Concept – Obiect [FREG77], am fost obligati sa le evitam înaceasta prima forma de prezentare a Modelului. Pentru simplificarea operata a pledat si dorinta de a unifica Constructorul de Structura.Desigur în acest scop a fost necesara introducerea termenilor de Concept Primar(Autoidentificator si Identificator) si Concept Derivat, care sa asigure viziunea pragmaticanecesara unor implementari. Asa dupa cum se va vedea în continuare, Modelul propus preia o multime de notiunideja implementate în Tehnica Modelarii Informatiilor (vezi Modelele Clasice, ModelulRelational, Modelul Obiectelor Abstracte). Modelul de Baza, dezvoltat în aceste constructiianterioare, care precede Conceptului este Clasa de Entitati. Aportul Modelului Conceptual semanifesta prin urmatoarele particularitati: - Realizeaza o Sinteza a notiunilor anterioare - Accentueaza Viziunea Structuralista prin încorporarea Procedurii în Concept, ca aptitudine potentiala de generare a unui nou Concept - Asigura Unicitate prin reducerea tuturor Elementelor de Structura la notiunea de Concept
    • Modele de Informatii / Modelul Conceptual 201 Conceptul, ca forma Unica de Reprezentare a Structurilor de Informatii, preiaElementele de Definire a Notiunii utilizata în Logica: o Definirea Conceptului o Definirea Continutului Conceptului (Nivel Logic de Definire) prin: § Numele Conceptului (forma lexicala de Singular) care va asigura referirea Conceptului în Operatiile de Transformare § Proprietatile Conceptului – Operatiile care asigura Definirea Functionala a Conceptului prin formele: o Agrega conceptele ... o Se generalizeaza prin ... o Este echivalent cu ... o Deriva din ... prin transformarea ... Conceptul poate fi: • Primar o Se Autodefineste Structural prin Instanta Unica (Numele se confunda cu Valoarea) o Nu contine în Definitia Structurala alte Concepte o Se Autoidentifica prin Valoarea Instantei o Se Defineste Operational prin Metode Implicite de Sistem o Apare la Nivelul Instantelor de Concepte având atributii de: § Identificator – Identifica unic o Instanta de Concept Derivat § Descriptor – Descrie o Instanta de Concept Derivat prin alte Instante de Concepte Primare § Înlocuitor – Refera (Substituie) o Instanta de Concept Derivat o Exemple: Întreg, Real, Caracter, Sir de Caractere, Figura, Imagine etc. • Derivat o Se Defineste Structural cu ajutorul altor Concepte o Poate avea i Instante (unde i reprezinta Cardinalitatea Conceptului) o Se identifica prin conceptul de Identificator de Instanta o Se Defineste Operational prin Metode Explicite de Utilizator
    • 202 Modele de Date o Exemple: Vezi Formele de Derivare o Definirea Sferei Conceptului prin: § Numele Clasei de Instante atasata Conceptului (forma lexicala de Plural) care va asigura referirea Clasei de Instante în Operatiile de Prelucrare § Clasa de Instante atasata Conceptului (Nivel Fizic de Definire) prin: • Instanta de Concept - care descrie o Aparitie Concreta (Instantiere) a Conceptului realizata cu ajutorul Conceptelor Primare • Identificatorul de Instanta - care reprezinta un Concept Primar Autoidentificator utilizat în continuare în cadrul altei Instante ca si Concept Primar Identificator al primei Instante • Multimea de Instante – ansamblul tuturor Instantelor care descriu Extensional Clasa de Instante, variabila în timp Nume Concept (plural) ≡ { Concept i } Multimea de Instante reprezinta un Concept Primar în calitate de Valoare de tip Multime ce va contine Identificatori de Instante sub forma de Concepte Primare de tip Înlocuitor (Referinte Asociative la Instantele continute în Multime)o Conceptul acopera definitia urmatoarelor notiuni: Clasa de Entitati ≡ Relatie ≡ Clasa de Obiecteo Conceptul acopera si notiunile de: Domeniu Caracteristica ≡ Atribut vazute ca si Clase de Entitati (vezi sectiunea 4.1.1.3.4)o Conceptul acopera si notiunea de: Valoare vazuta ca si Concept Primaro Conceptul acopera si notiunile de: Superclasa de Obiecte Subclasa de Obiecte Metaclasa de Obiecte vazute ca si Clase de Entitati (vezi sectiunea 4.1.1.3.3)
    • Modele de Informatii / Modelul Conceptual 203o Conceptul se defineste sub doua aspecte: Structural ( .. are Proprietatile) sau Operational ( .. este rezultatul Transformarii), ambele pastrând forma Predicativa Nesaturata [FREG77] § Definire Structurala - prin precizarea Starilor Conceptului sub forma Proprietatilor care îl descriu în doua planuri: • Planul Logic – se descrie prin alte Concepte invocate prin Nume Conceptele care descriu alte Concepte vor juca rolul de Caracteristici • Planul Fizic – descriere prin Concepte Primare Conceptele Primare vor fi reprezentate de Instante de Concepte, care sunt descrise cu ajutorul Valorilor § Definire Operationala - prin precizarea operatiilor care determina Transformarile admise asupra Conceptelor Transformarile de Concepte preiau forma de transformare a Obiectelor prin Metode invocate de Mesaje. Noutatea consta în faptul ca orice Transformare de Concept returneaza un nou Concept, sau cu alte cuvinte, orice transformare genereaza un nou Concept potrivit relatiei de echivalenta: Concept 1 ≡ Concept 2 (Transformare) Transformarea poate fi privita ca un Concept Virtual (Concept în devenire)o Derivarea Conceptelor se poate face printr-una din urmatoarele forme: § Derivare prin Definire • Definire prin Agregare Conceptul 1 ≡ (Conceptul 2 , Conceptul 3 , ... Conceptul n ) Orice invocare a unui Concept pentru Definirea prin Agregare: o La nivel Logic – se face prin invocarea de Concepte prin Nume, care însa nu implica Mostenire de Stari o La nivel Fizic - se face prin invocare a unui Concept Primar Identificator (Valoare de Identificator de Instantiere) Se zice : Conceptul 1 agrega Conceptul 2 , Conceptul 3 , ... Conceptul n Exemplu: PERSOANA ≡ (Marca , Nume , Prenume, Sex, Grupa) unde: Marca, Nume, Prenume, Sex, Grupa sunt Concepte de tip Domeniu anterior definite: MARCA ≡ (Intreg)
    • 204 Modele de Date NUME ≡ (Sir de Caractere) .. • Definire prin Generalizare Conceptul 1 ≡ (Conceptul 2 , Conceptul 3 , ... Conceptul n ) Conceptul 2 ≡ Categorie Unde: Categorie este un Concept Definit prin Agregare Se zice : Conceptul 1 se generalizeaza prin Conceptul 2 Definitia de Categorie poate genera automat structura: Concept 2 ≡ (Cod ≡ Intreg, Nume ≡ Sir) Unde:Domeniul de Valori al atributului Nume contine Valorile de Categorie ale Conceptului 2 Orice definire prin Generalizare: o Genereaza noi concepte cu numele construite din: Nume Concept 1 + Valoare-Categorie din Concept 2 o Adaugarea de concepte specifice de definire pentru fiecare Concept-Categorie se va face prin completarea definirii prin agregare (adaugarea de noi Componente alaturi de cele generate automat – Cod si Nume) Exemplu: PERSOANA ≡ (Marca , Nume , Prenume, Sex, Adresa, Rol) unde: ROL ≡ (Cod, Nume) ROLURI ≡ {(1,’Profesor), (2,’Student)’,(3,’Angajat’)} • Definire prin Echivalenta Conceptul 1 ≡ Conceptul 2 Se zice : Conceptul 1 este echivalent cu Conceptul 2 Definirea prin Echivalenta permite declararea Sinonimiei în cadrul Conceptelor § Derivare prin Transformare Conceptul 1 ≡ Conceptul 2 (Transformare) Se zice :
    • Modele de Informatii / Modelul Conceptual 205 Conceptul 1 deriva din Conceptul 2 prin transformarea invocata de Mesaj Se remarca ca Derivarea prin Transformare este cea mai generala forma, ea putând suplini, cu metode adecvate de transformare, Derivarea prin Definire Exemplu 1: PERSOANA-Profesor ≡ PERSOANA (Rol=’Profesor’) PERSOANA-Student ≡ PERSOANA (Rol=’Student’ si Sex=’Barbat’) Exemplu 1: GRUPA ≡ (Cod , Nume , Limba-Predare) PERSOANA-Student-Grupa1 ≡ PERSOANA-Student (Grupa=’1’) Având în vedere faptul ca Transformarea se implementeaza în Concept ca si Proceduri de Utilizator, posibilitatea de generare a noi Concepte r mâne a deosebit de mare. o Conceptul exclude Mostenirea de Structura de Concept. Mostenirea de Nume de Concepte nu duce decât la Redondanta si Inconsistenta posibila. Ea e înlocuita cu invocarea unui Concept în definirea altui Concept prin Nume sau a unei Instante prin Valoare o Mostenirea de Metode se face între Conceptele legate prin Derivarea prin Generalizare, care e o legatura de tip Este (IS-A) si care poate fi Multipla o Legatura de Clasa - Subclasa e considerata o Structura Ierarhica de natura Statica, fiind înlocuita cu trei forme proprii de mo stenire care corespund celor trei forme de definire a Conceptelor: § Mostenire prin legatura de Abstractizare prin Agregare § Mostenire prin legatura de Abstractizare prin Generalizare § Mostenire prin legatura de Echivalenta o Modelul foloseste doar Regasirea Asociativa a Instantelor o Modelul apeleaza la doua nivele de reprezentare a datelor: § Reprezentare Conceptuala la Nivel Extern § Reprezentare Relationala la Nivel Intern o Modelul foloseste notiunea de Concepte Persistente bazata pe memorarea Conceptelor definite utilizând Proiectia Relationala de la Nivelul Intern, precum si a Descrierii Conceptelor la Nivelul Extern In dorinta de a prezenta si o tendinta întrevazuta pentru dezvoltarea noilor tehnologii deprelucrare a informatiilor si datelor am tinut sa prezentam si Schita unui Model Conceptual.Desigur numeroase încercari de implementare vor fi necesare pentru a valida, definitiva sauînlocui ideile anticipate în aceasta încercare. Ramânem însa cu convingerea ca multe din ideileavansate aici, vor fi regasite sub o forma sau alta în instrumentele din viitor.
    • 206 Modele de Date4.2 Modele de Date Modelele de Date sunt discutate în contextul apropierii Structurilor concepute în Spatiulde Informatii de instrumentul de prelucrare – Calculatorul. Vom regasi conceptele dezvoltate însectiunile precedente, la care se vor adauga cele specifice reprezentarilor pe Suportul deMemorare. Având în vedere Planurile de Descrise introduse în sectiunea 3.4.1.2 (al Numelor sial Valorilor) si în aceasta sectiune vom vedea procesul de implementare desfasurat pe nivelediferite de abstractizare (de la cele Conceptuale la cele Fizice).4.2.1 Tipuri de Modele de Date Interpretarea realitatii are nevoie de un instrument care sa asigure doua cerinteimportante [TSIC82]: - Suficienta Abstractie - care sa stearga perturbatiile concretului - Suficienta Putere - pentru a surprinde esenta realitatii modelate Sau altfel exprimat: “Modelul trebuie sa reprezinte un instrument de abstractie, care sa permita: Sa vezi Padurea - si anume informatiile continute în date, în locul Copacilor – datele privite detasat de semnificatiile de ansamblu.” Langefors, în 1977, propune ca Element Atomic pentru modelarea Spatiului deInformatii si de Date tupla: ( Nume Obiect , Proprietate Obiect, Valoare Obiect, Timp) Pentru reducerea volumului de date memorate si prelucrate, cel mai adesea sesacrifica ultimul component al tuplei si anume Timpul. Ramâne atunci ca Element Atomic dedescriere tupla : ( Nume Obiect , Proprietate Obiect, Valoare Obiect)retinându-se pentru prelucrare doar ultimul eveniment semnificativ în timp . Structurile de Informatii si de Date pot fi atunci construite în doua moduri : o Crearea, pe baza continutului în Informatii al Tuplei Elementare de descriere, a unor Categorii de Informatii sau Date (Abrial, 1974), reprezentate de Multimi de Informatii sau Date împreuna cu Relatiile dintre ele (vezi Modelul Formal tratat în sectiunea 4.1.1.3). Gruparea Multimilor în Categorii se face pe baza similaritatilor constatate, sub forma celor de mai jos: § aceleasi Proprietati § acelasi Nume Comun § aceleasi Relatii
    • Modele de Date 207 o Pornind de la o multime de asemenea Elemente Atomice, acestea sunt ad-hoc conectate între ele pe baza Relatiilor de Legatura desprinse din spatiul ce urmeaza a fi descris Cele doua moduri de utilizare a Tuplei Atomice conduc la doua variante de construirea Structurilor de Informatii si / sau de Date: § Informatii / Date Strict categorisite – Structuri zise de Tip Strict § Informatii / Date Vag categorisite – Structuri zise de Tip Vag Cu aceste doua Tipuri de Date pot acum sa fie construite doua feluri de Modele: o Modele Stricte (Omogene) - care fac distinctie între Entitati, Caracteristici si Valori, tratându-le în mod diferentiat ca: § Elemente Autoidentificabile - Valorile § Elemente Nedecompozabile - Caracteristicile § Elemente Agregate - Entitatile o Modele Vagi (Heterogene) - care impun o tratare unitara a tuturor Elementelor, indiferent ca sunt Entitati, Caracteristici sau Valori Fiecare Tip de Model prezinta avantaje si dezavantaje care favorizeaza anumiteutilizari, defavorizându-le pe altele. Se prezinta în continuare însusirile si utilizarile specificepentru fiecare model: o Modelele Stricte - se preteaza pentru prelucrari de colectii de volum mare, care solicita un acces rapid, atât la nivel de entitate cât si la nivel de caracteristica (exemplu: Sisteme de Gestiune Baze de Date) § Pretind Structura Ferma a datelor § Impun Omogenizare fortata § Realizeaza Performante Ridcate la prelucrari de Volum Mare § Limiteaza utilizarea procedurilor de Adaptabilitate Inteligenta o Modelele Vagi - se preteaza pentru prelucrari care accepta structurare slaba a datelor la intrare si care genereaza structuri prin declarare de reguli de construire (exemplu: Sisteme de Programare Logica) § Accepta Structura Vaga a datelor § Realizeaza Formalizare Unica si Adaptabila a realitatii § Realizeaza Performante Acceptabile numai pentru Volume Mici de date § Asigura Adaptabilitate Inteligenta mare4.2.1.1 Arhitectura Modelelor de Date Stricte Modelele Stricte se bazeaza pe existenta unei puternice Structuri de Date a careidescriere amanuntita se concepe si se memoreaza înainte de precizarea oricarei proceduri deprelucrare si care urmareste în continuare urmatoarele obiective:
    • 208 Modele de Date o Sa realizeze Independenta Datelor fata de Proceduri si totodata a diferitelor Nivele de Descriere a Datelor M G O Model de DateGs Gr S Baza de Date LogicaSs Sc Ol Baza de Date On Os D Fizica Legenda M - Model G - Reguli de Generare - LDD (Limbaj de Descriere Date) Gs - Reguli de Specificare Structura Gr - Reguli de Specificare Restrictii S - Schema de Descriere (Baza de Date Logica - BDL) S s - Lista de Categorii, Proprietati, Relatii S c - Lista de Restrictii D - Realizare de BDL (Baza de Date Fizica) O - Operatii de Acces Admise – LMD (Limbaj de Manipulare a Datelor) Ol - Lista Operatiilor Utilizate On - Operatii de Navigare Os - Operatii de Specificare Fig. 4.2.1.1.1 Componentele Modelelor Stricte de descriere a datelor o Sa asigure Necesitatile de Informare pentru oricare utilizator pentru Cereri prezente si viitoare
    • Modele de Date 209 o Sa ofere tuturor procedurilor Facilitatile de Acces la Date conform criteriilor de performanta preconizate o Sa garanteze mentinerea în permanenta a unei Structuri de Date Deschise oricaror modificari, optimizari sau extensii cerute, fie datorita schimb arii conditiilor initiale de proiectare, fie datorita cerintelor de îmbunatatire a performantelor (viteza de acces, consistenta, distribuire etc. ) Aceste cerinte solicita dezvoltarea unui nou Nivel de Proiectare Conceptuala, al caruiaport sa fie marcat de urmatoarele avantaje: - Un Grad mai Abstract de Formalizare o Extinderea Validarii Datelor de la simple Limite sau Conditii, la Proceduri (Restrictii) atasate Operatiilor de Actualizare (Evenimente) o Îmbogatirea Semanticii atasate Structurilor de Informatii si Date prin încorporarea Operatiilor Compatibile cu Structurile Proiectate în corpul Modelului de Date - Posibilitati sporite de Control a Structurilor Complexe o Gruparea Obiectelor diverse (Structuri, Constrângeri, Reguli de Integritate, Restrictii, Operatii) în Modelul de Date o Corelarea Conditiilor de Definire a Obiectelor Multiple - Facilitati de Adaptabilitate la Modificari crescute o Instrumente Grafice performante pentru reprezentarea Formalismelor o Procese de Generare Directa (Engineering) si Inversa (Reengineering) a Structurilor de Implementare Aceste conditii pot fi îndeplinite daca se adauga un nou nivel de Definirea a Structurilorde Informatii si Date în forma unui produs specializat în constructia Modelelor de Date, care saaiba în alcatuire trei componente principale (vezi Fig. 4.2.1.1.1: o Descrierea Structurii o Descrierea Restrictiilor o Descrierea Operatiilor Pentru exemple vezi Baza de Date Medicala din sectiunea 4.2.4.4.2.1.1.1 Descrierea Structurii Descrierea Structurii contine declararea Proprietatile Principale (Statice), care sementin Invariante în timp (Fig. 4.2.1.1.2.1). Declararea Structurii se efectueaza prinintermediul unui set de Reguli de Specificare (Fig. 4.2.1.1.1) – G (LDD) § Specificarea Elementelor de Structura (Proprietatile de Baza) – G s • Specificarea Numelor de Categorii (Clase de Entitati)
    • 210 Modele de Date • Specificarea Proprietatilor pentru Categorii (Atribute Descriptoare, Dependente între Atribute, Identificatori de Entitati) § Specificarea Relatiilor între Categorii (Proprietatile de Referire)– G s Regulile de Specificare definite în cadrul Modelului de Date vor fi convertite în Listede Categorii, Proprietati si Relatii (S s ), care vor constitui Nivelul Logic de Descriere al Bazeide Date (S) (Fig. 4.2.1.1.1). Aceasta transformare se va face automat printr-un Proces deGenerare a Descrierii de Structura (Engineering).4.2.1.1.2 Descrierea Restrictiilor Daca Structura unui Model de Date reuneste Proprietatile de Baza ce descriu Datele,Restrictiile suplimenteaza descrierea cu informatii referitoare la Conditiile Impuse fiecaruiObiect din Structura de Date (vezi Tab. 4.2.1.1.2.1). Specificarea Restrictiilor impuseEntitatilor si Atributelor definite în Structura se face prin intermediul unor Reguli deSpecificare a Restrictiilor – G r, care vor fi convertite în Baza de Date Logica, asemeneaElementelor de Structura, în Liste de Restrictii S c. Regulile de Specificare a Restrictiilor vin sacompleteze semantica acordata datelor continute în structura, precizând conditiile pe careValorile Datelor trebuie sa le respecte la încarcarea în Structura. Ca urmare Restrictiile retinProprietati Auxiliare ale Datelor si anume Conditiile Logice impuse, ce descriu Cunostintedespre Structura. Se prezinta în continuare o clasificare a Categoriilor de Informatii pe careRestrictiile le adauga într-un Model de Date: § Restrictii de Identificare – pentru evitarea Dublurilor § Restrictii de Referire – pentru evitarea ”Copiilor Orfani” § Restrictii de Domeniu, ce vor fi apoi transferate asupra tuturor Atributelor provenite din Domeniu § Expresiile Dependentelor de Materializare a Datelor, implicând acele Date, Dependente Functional de Date Reale si care se memoreaza în Baza de Date din motive de performanta la regasire, având însa nevoie de un Control Procedural al Consistentei Restrictiile sunt de doua feluri Implicite si Explicite: § Restrictii Implicite – Denumite si Restrictii de Sistem (Inerente), ele sunt legate de Tipul de Model utilizat, verificarea lor cazând în seama SGBD - ului § Restrictii Explicite - Denumite si Restrictii de Utilizator, ele sunt specifice formelor particulare de implementare a Modelului de Date, fiind declarate de Utilizator Modelele sunt cu atât mai Restrictive , cu cât Restrictiile Implicite sunt mai multe, iarRestrictiile Explicite sunt mai putine. Analizând natura Informatiilor aduse de Restrictii se poate remarca, în calitate deCaracteristici de Baza ale acestor Obiecte, faptul ca ele reprezinta în Modelul de Date simultanRestrictii Logice si totodata Reguli Generice – G r.
    • Modele de Date 211 Exista doua moduri de declarare a Restrictiilor Intr-un Model de Date: § Statica – prin Specificare Predicativa § Dinamica – prin Specificare Operationala Datorita functiei pe care Restrictiile o au în asigurarea Conditiilor de Validitate acontinutului unei Baze de Date, Gradul lor de Îndeplinire masoara calitatea Bazei de Date.Gradul de Îndeplinire a Restrictiilor este masurat prin Propritatile lor la un moment dat: o Proprietati sintetice ale unei Restrictii § Consistenta § Realizabila (posibil de satisfacut) § Realista o Proprietati detaliate ale unei Restrictii C i § Bine Formata - daca C i satisface proprietatile sintetice § Realizata - daca C i e adevarata pentru starea curenta a BD (DBS k ) § Realizabila - daca exista o stare DBS care satisface C i § Invalida - daca nu exista nici-o stare DBS care satisface C i § Consecventa Logica - C i e o consecventa logica a unui set de alte restrictii C1 , .. , C n daca C i e satisfacuta când C 1 , .. , C n sunt satisfacute • Redondanta - daca Ci e o consecventa logica a restrictiilor C1 , .. , Cn • Echivalenta - Ci , Cj sunt echivalente daca Ci si Cj sunt consecvente logice reciproce Proprietatile Restrictiilor se transfera asupra Bazei de Date pe care o supravegheaza. Caurmare Proprietatile unei Baze de Date la un moment dat pot fi: o Consistenta a unei stari DBS k a BD - daca toate Restrictiile Schemei sunt satisfacute o Inconsistenta a unei stari DBS k a BD - daca nu toate Restrictiile Schemei sunt satisfacute o Schema satisfacuta a unei stari DBS k - daca toate Restrictiile Schemei sunt satisfacute o Schema realizabila a unei BD - daca exista unele stari DBS k care nu satisfac schema o Schema inconsistenta a unei BD - daca nici-o stare DBS k nu satisface schema o O Schema Buna pentru o BD - o Schema care e: § Realizabila (poate fi satisfacuta) § Disponibila pentru Specificatii Precise § Disponibila pentru Validare
    • 212 Modele de Informatii si Date Entitati Proprietati Structura Primare Obiectelor Relatii Integritatea Integritatea Actualizarii Proprietatile Structurala Obiectelor Primitive Obiectelor Proprietati Secundare Integritatea Actualizarii Obiectelor Individuale Integritatea Operationala Generarea Datelor Derivate Tab. 4.2.1.1.2.1 Clasificarea Proprietatilor Obiectelor stocate într-un Model de Date
    • Modele de Date / Modelul Ierarhic 2134.2.1.1.3 Descrierea Operatiilor Transferul Operatiilor în Modelul de Date are o contributie deosebita pe linia asigurariimaximei Independente a elementelor constitutive ale Sistemelor cu Baze de Date. Desi aparent paradoxal, apropierea Operatiilor de Date în cadrul Modelelor de Datecreste Independenta Aplicatiilor fata de Structurile memorate prin aceea ca ele oferaUtilizatorului nu Colectii de Date, ci Metode de Regasire si Actualizare a acestora. Migrarea Operatiilor în Modelele de Date se face pe cai multiple, prin Biblioteci deFunctii, Proceduri Stocate, Triggeri. O trecere în revista a acestor facilitati oferite de Sistemelede Gestiune a Bazelor de Date precum si de Programele de construire a Modelelor de Date vafi facuta în sectiunea 4.2.4.7.5, cu ocazia prezentarii Modelului Relational. In aceasta prezentare generala a Modelelor Stricte de Date se ofera argumentele de bazacare au facut ca Sistemele cu Baze de Date sa promoveze acest transfer al Operatiilor catreStructurile de Date: o Materializarea Datelor prin utilizarea Functiilor de Calcul pentru instantierea Datelor Virtuale doar în momentul apelului lor, a dat o rezolvare corecta a Dependentelor Functionale cauzatoare de inconsistenta în cazul memorarii redondante a datelor o Atasarea Operatiilor la Structurile de Date ofera pentru Utilizator o Interfata necesara care sa-l degreveze de cunoasterea detaliilor de structura a datelor, ferindu-l de posibile erori în operarea la acest nivel o Orientarea pe Evenimente a Operatiilor efectuate asupra Datelor sunt stimulate de concentrarea lor în jurul Modificarilor operate în Structura o Prelucrarile Tranzactionale, indispensabile în contextul structurilor complexe prelucrate în regim de multiacces, cer o Viziune Globala asupra întregii colectii de Date o Colectiile Mari de Date pretind tot mai multa Logica de Prelucrare (Business Logic) în asigurarea coerentei datelor memorate, ceea ce determina dezvoltarea unui nivel de Proceduri orientate catre Structura de Date si nu catre Aplicatie, care asteapta în fiecare moment Date Validate In consecinta ultima sectiune a unui Model de Date va fi consacrata descrieriiStructurilor de Proceduri atasate Structurilor de Date. Descrierea Transformarilor(Operatiilor) - contine declararea proprietatilor Dinamice, care asigura Evolutia structurii întimp, prin intermediul unui set acordat de Operatii de Acces Admise – O (LMD). Din acesteOperatii de Acces Admise de Modelul de Date vor fi selectionate cele ce descriu Prelucrarile lacare se cer a fi supuse Datele în cadrul Sistemelor de Aplicatii. Fiind grupate în Modelul Unicde Date sansa de a fi concepute Modular este foarte ridicata. Se spune ca Procedurileîncorporate în Model vor fi mai degraba orientate catre Structurile de Date decât catreAplicatii, cu un efect benefic asupra Controlabilitatii lor. Operatii de Acces Admise – O vor da nastere în BD Logica, prin generare automata, laListele de Operatii Ol (Fig. 4.2.1.1.1). Ultimul nivel din Figura va reprezenta Baza De DateFizica (D), având atasate Listele finale de Proceduri Individualizate On si Os .
    • 214 Modele de Date4.2.2 Modelul Ierarhic Modelul Ierarhic de organizare a datelor este primul model utilizat în construireaStructurilor de Date ce au stat la baza Sistemelor de Gestiune a Bazelor de Date (SGBD). Cutoate ca în prezent, din motive legate de resursele necesare pentru conversie (timp si bani),continua sa existe Sisteme cu Baze de Date ce utilizeaza structura de baza promovata de acestmodel, din punct de vedere teoretic modelul pastreaza doar o importanta istorica. La aceastarecunoastere istorica trebuie însa adaugata si utilitatea de evidentiere a traseului parcurs înperfectionarea metodelor de structurare a colectiilor de date, în vederea întelegerii sensului dedezvoltare a conceptelor din domeniu. Este sugestiv în special de urmarit începutul de drumspre câstigarea independentei componentelor de structura. Cunoasterea neajunsurilor acestuimodel este o buna cale de a învata cum se proiecteaza o structura sanatoasa.4.2.2.1 Segmentul de Articol ca si Constructor de Structura Modelul accepta mai multe Tipuri de Articole Fizice (ansambluri de câmpuri care sememoreaza în Baza de Date), denumite Segmente de Articole, care prin reasamblare potconstrui Articolele Logice (ansambluri de câmpuri care se retin în memoria interna în scopulprelucrarii). Ca atare constructorul oricarei structuri de date în acest model este Segmentul, iaroperatia de asamblare a structurilor este cea de concatenare secventiala, prin alaturarea în urmacitirii secventiale a diferitelor tipuri de segmente pe baza unei Ierarhii prestabilite de Tipuri deSegmente. Intre caracteristicile acestei forme de reprezentare pe suport a structurilor de datementionam: - Implementarea unei prime forme de eliminare a redondantei prin extragerea câmpurilor de date comune altor segmente si gruparea lor într-un Segment Ascendent - Construirea unei structuri de date de forma unui Arbore de Segmente, putându-se vorbi despre Segmente Ascendente si Segmente Descendente - Exploatarea Structurii Secventiale a primilor suporti de memorare a datelor (benzi magnetice) - Deducerea formei de reprezentare a Structurii Logice din organizarea pe suport a Structurii Fizice a datelor pe suport - Asigurarea posibilitatilor de reprezentare doar a Structuri Fundamentale de tip 1-n (Structuri de tip Partitie) - Reprezentarea fizica se efectueaza prin Traversarea structurii de tip Ierarhie (Arborescenta) în Preordine (Radacina – Subarbore Stâng – Subarbore Drept) - Realizarea unei Structuri de Date Contextuale cu Context Unic reprezentat de drumul de la Radacina Arborelui pâna la nodul reprezentat de Segmentul CurentExemplu: Ca exemplu se ofera transpunerea în Model de Date Ierarhic a reprezentarii structuriide informatii descrisa în sectiunea 3.4.4.
    • Modele de Date / Modelul Ierarhic 215 Memorie externa Segment tip 1 Beneficiarul 1 B1 N1 C1 O1 Segment tip 2 Produsul 1 contractat de Beneficiarul 1 P1 N1 C1 V1 S1 Q1 Segment tip 2 P2 N2 C2 V2 S2 Q2 Produsul 2 contractat de Beneficiarul 1 Segment tip 1 B2 N2 C2 O2 Beneficiarul 2 Segment tip 2 P1 N1 C1 V1 S1 Q3 Produsul 1 contractat de Beneficiarul 2 Segment tip 2 P2 N2 C2 V2 S2 Q4 Produsul 2 contractat de Beneficiarul 2 Segment tip 2 P3 N3 C3 V3 S3 Q5 Produsul 3 contractat de Beneficiarul 2 Segment tip 1 . . . . Segment tip 2 . . . . . . B1 N1 C1 O1 P1 N1 C1 V1 S1 Q1 Articol Memorie interna Produsul 1 contractat de Beneficiarul 1 Logic Fig. 4.2.2.1.1 Componentele Modelului Ierarhic Vor fi utilizate doua Tipuri de Segmente (Fig. 4.2.2.1.1), care regrupeaza o multime deCâmpuri de Date (Fig. 4.2.2.1.2): PRODUS - P BENEFICIAR - B Cod - Ci Cod – Bi Nume (Denumire) - Ni Nume (Denumire) - Ni Culoare - Ci Culoare - Ci Pret - Vi Oras -Oi Stoc - Si Cantitate - Qi Fig. 4.2.2.1.2 Descrierea Segmentelor BENEFICIAR (B) si PRODUS (P) Întrucât Segmentele reprezinta Elementele de Memorare pe suportul extern ele poartanumele si de Articole Fizice. Articolele Fizice, ce reprezinta Fragmente de Entitati, au îngeneral nevoie de alte Articole Fizice (Segmentele Ascendente) pentru a descrie în întregimeEntitatile implicate. Articolele Fizice Ascendente descriu contextual Articolelor Descendente.
    • 216 Modele de Date Limbajul de manipulare a datelor îsi manifesta caracteristica specifica în special prinmodul de inspectie a Structurii de Segmente pentru reconstituirea Structurii Articolului Logic,elementul de prelucrare a datelor. Operatiile de citire segmente sunt: - GET UNIQUE – Regasire Articol Fizic (Segment) cautat, împreuna cu Contextul atasat (Multimea de Segmente Ascendente) - GET NEXT – Citire Articol Fizic urmator punctului în care se afla prelucrarea Operatiile de actualizare, Adaugare si Stergere sunt însotite în general de rescriereaSecventei de Segmente pe suport. Formalismul grafic de reprezentare, prezentat în sectiunea 3.4.3.3 pentru ModelulRelational, sub numele de Arbore de Structura, poate fi usor adaptat la Modelul Ierarhic. InFig. 4.2.2.1.3 se foloseste o asemenea reprezentare. * B c • n • • • o P t q • v * • • c n l Fig. 4.2.2.1.3 Arborele de Structura pentru Modelului Ierarhic4.2.2.2 Avantajele si Dezavantajele Modelului Ierarhic In concluzie se prezinta urmatoarele avantaje si dezavantaje ale Modelului Ierarhic:Avantaje: - Model simplu si natural de reprezentare a Relatiei Fundamentale Ierarhie (1–n) - Posibilitatea de utilizare si a suportilor secventiali de memorare a datelor (benzi magnetice), in calitate de suporti neadresabiliDezavantaje: - Modelarea Structurilor m-n doar prin Structuri 1-n, cu repetarea descendentilor partajati de mai multi ascendenti, implica redondanta si prin aceasta inconsistenta, greu de controlat procedural (Exemplu: Modificarea Culorii unui Produs implica actualizarea acestuia în contextul tuturor Beneficiarilor care au contractat acest Produs – vezi Fig. 4.2.2.1.1) - Accesul la date trebuie efectuat întotdeauna pe linia Contextului Unic implicat de structura de tip Arbore - Încercarea de modificare a Strategiei de Acces la Segmente, prin atasarea Structurilor de tip Index, face ca Indecsii sa participe la construirea Structurii Principale de Date
    • Modele de Date / Modelul Retea 2174.2.3 Modelul Retea Acest Model de Baza de Date a fost propus si fundamentat de grupul de lucru pentrustandardizare Data Base Task Group (DBTG). Ca si Modelul Ierarhic, Modelul Reteaurmareste sa gaseasca un Constructor de Structura care sa permita reprezentarea unei Structuride Baza (în speta Structura Fundamentala m – n), cu ajutorul careia sa poata fi apoi construitecât mai multe Structuri reale, complexe de date. Structurile care le realizeaza ambele Modeleramân însa statice în timp, reconfigurarea lor implicând consumuri mari de resurse.4.2.3.1 Setul de Articole ca si Constructor de Structura Modelul Retea a aparut ca o solutie de rezolvare a impasurilor ridicate de reprezentareaStructurilor Fundamentale de tip m-n. Rezolvarea Contextelor Multiple de aparitie a aceluiasiArticol de Date a fost gasita în utilizarea Listelor de Articole denumite Seturi de Articole. Caurmare, constructorul Modelului Retea este Setul de Articole. El este definit prin: - Posesorul Listei (Capul Listei sau Header) implementat ca o Referinta de Adresa la Primul Articol din Lista (vezi Referintele de Adresa rc din Articolele BENEFICIARI si PRODUSE - Fig. 4.2.3.1.1); Posesorul Listei nu face parte din Lista de Articole, ci doar o refera. - Membrii Listei reprezentati de Articolele de Date înlantuite prin Referintele de Adresa care construiesc Lista (vezi Referintele de Adresa rc din Articolele POZITII CONTRACTUALE - Fig. 4.2.3.1.1) In Fig. 4.2.3.1.1 este redata Structura Fizica de Date utilizata de modelul Retea. Seremarca elementele de baza ale structurii si anume Articolele Principale si de Legatura: - Articolele Principale contin datele care identifica si descriu Articolele Principale împreuna cu referintele de adresa la Seturile de Articole pe care le refera § BENEFICIAR • Identificator – Codul Beneficiarului (Bi ) • Descriptori – Nume, Cont, Oras (Ni , Ci , Oi ) • Referinta de Adresa la Setul de Produse Contractate (rci ) § PRODUS • Identificator – Codul Produsului (Pj) • Descriptori – Denumire, Culoare, Pret, Stoc (Nj, Cj, Vj, S j) • Referinta de Adresa la Setul de Beneficiari Contractanti (rcj) - Articolele de Legatura contin datele care identifica si descriu Articolele de Legatura împreuna cu referintele de adresa la Capetele de Lista precum si la celelalte Articole de Legatura din acelasi Set de Articole § POZITIE CONTRACTUALA • Identificator – Codul Beneficiarului+Codul Produsului accesate prin Referinte de Adresa (rbk si rpk)
    • 218 Modele de Date / Modelul ReteaMemorie externa rc i – referinta de adresa la Beneficiarul unei BENEFICIARI o Pozitie Contractuala i Pozitii Contractuale rb j – referinta de adresa la un Beneficiar j rc 1 B1 N1 C1 O1 rp k – referinta de adresa la un Produs k rc 3 B2 N2 C2 O2 . . . . . rc 2 rb 1 Q1 rp 1 rc 3 Pozitii Contractuale ale unui Beneficiar - rb 1 rp 2 rc 4 Q2 POZITII rc 4 rb 2 Q3 rp 1 - CONTRACTUALE rc 5 rb 2 Q4 rp 2 - - rb 2 Q5 rp 3 - Produsul unei . . . . . Pozitii Contractuale P1 N1 C1 V1 S1 rc 1 P2 N2 C2 V2 S2 rc 2 P3 N3 C3 V3 S3 rc 5 Pozitii Contractuale . . . . . . ale unui Produs PRODUSEMemorie interna rc 1 B1 N1 C1 O1 Beneficiar P1 N1 C1 V1 S1 rc 1 Produs rc 2 rb 1 Q1 rp 1 rc 3 Pozitie Contractuala Fig. 4.2.3.1.1 Componentele Modelului Retea
    • Modele de Date / Modelul Retea 219 • Descriptori – Cantitate Contractata (Qk) • Referinte de Adresa la: • Posesorul 1 al Articolului Membru Beneficiarul Contractant (rbk) • Posesorul 2 al Articolului Membru Produsul Contractat (rpk) • Articolul Membru urmator în Lista de Pozitii Contractate (rck) Constructorul Set de Articole este o notiune echivalenta cu Ansamblul de Realizari dinSpatiul de Informatii. Setul de Articole se defineste: - In plan Logic – prin Numele Setului construit din Numele Posesorului alaturat printr-o Relatie cu Numele Membrilor (Exemplu: Produsele contractate de un Beneficiar) - In plan Fizic – prin instanta (realizarea) Articolul Posesor si instantele (realizarile) Articolelor Membri Setul este descris asadar: - Prin Tipul Setului – defineste Setul Logic - Prin Instanta Setului (Multimea Membrilor) – defineste Setul Fizic In structura fizica din Fig. 4.2.3.1.1 sunt înregistrate doua categorii de informatii: o Valorile Caracteristicilor Simple – ansamblul Insusirilor Descriptoare ale Claselor de Entitati o Referintele de Adresa (Pointeri) – descriu legaturile între Clasele de entitati si sunt ca urmare denumite Caracteristici de Structura Pentru a întelege cum se utilizeaza structura fizica prezentata în Fig. 4.2.3.1.1 seprezinta în continuare Strategia de Acces la date prin Navigarea în structura cu exploatareaReferintelor de Adresa. o Reconstituirea Ierarhiei Simple (Produsele contractate de un Beneficiar) § Se localizeaza un Beneficiar § Se inspecteaza Setul de Articole Produsele contractate de un Beneficiar pornind din referinta de adresa (rci din Beneficiar), memorata în Posesorul Setului (Beneficiarul localizat) § Pentru fiecare Articol de Legatura din Lista de Articole începând cu rci din Beneficiar se citeste Produsul punctat de Referinta de Adresa rpk din Pozitia Contractuala în curs de prelucrare o Reconstituirea Ierarhiei Inverse (Beneficiarii care au contractat un Produs) § Se localizeaza un Produs § Se inspecteaza Setul de Articole Beneficiari care au contractat un Produs pornind din referinta de adresa (rci din Produs), memorata în Posesorul Setului (Produsul localizat)
    • 220 Modele de Date / Modelul Retea § Pentru fiecare Articol de Legatura din Lista de Articole începând cu rci din Produs se citeste Beneficiarul punctat de Referinta de Adresa rbj din Pozitia Contractuala în curs de prelucrare BENEFICIAR m Produsele contractate Beneficiarii care au de un Beneficiar contractat un Produs n PRODUS Fig. 4.2.3.1.2 Relatia Fundamentala între BENEFICIAR si PRODUS Se poate remarca cu usurinta modul în care se reprezinta în structura fizica de dateRelatia Fundamentala m descrisa în Spatiul Informatiilor (Fig. 4.2.3.1.2), precum si dubla -nrelatie 1-n care implementeaza relatia m-n în Spatiul Datelor (Fig. 4.2.3.1.3). Se prezinta si pentru Modelul Retea o reprezentare grafica folosind Arborele deStructura (vezi Fig. 4.2.3.1.4). Fata de Modelul Relational în noua reprezentare cu liniepunctata este reprezentata legatura Posesor – Membri, descrisa de Listele de Articole care aparîn Modelul Retea. Conventia pe care am adoptat-o este ca sageata sa fie orientata de la Posesorcatre Membri. In aceasta reprezentare se vede clar cum Articolul de Legatura POZITIE-CONTRACT se afla înregistrat în doua Liste de Articole: - POZITIILE–CONTRACTUALE ale unui BENEFICIAR (Legatura B.c → C.b) - POZITIILE–CONTRACTUALE ale unui PRODUS (Legatura P.c → C.p) BENEFICIAR PRODUS 1 1 Produsele contractate Beneficiarii care au de un Beneficiar contractat un Produs n n POZITIE CONTRACTUALA Fig. 4.2.3.1.3 Diagrama Simbolica B-P-C
    • Modele de Date / Modelul Retea 221 Ca si în cazul precedentului model, Limbajul de manipulare a datelor îsi manifesta si înacest caz caracteristica specifica în special prin modul de exploatare a Referintelor de Adresamemorate în structura: - FIND – localizare Articol Fizic si actualizarea Indicatorului de Articol Curent - GET – încarcare Articol Fizic Curent Operatiile de actualizare, Adaugare si Stergere sunt însotite în general de executiaprocedurilor de actualizare a Listelor de Articole. B P • • * • o c • * • • v n t c n l C * • b * q p Fig. 4.2.3.1.2 Relatia Fundamentala între BENEFICIAR si PRODUS Pentru fixarea particularitatilor la care apeleaza Modelul Retea pentru construireaStructurilor de Date de tip m – n, dam în continuare reprezentarea în acest model a unuiArbore Invers în forma cea mai generala de Graf (structura tipica de Retea în variantaRecursiva),. In Fig. 4.2.3.1.3 este redata Reprezentarea Fizica, pentru ca apoi sa poata fiurmarita transformarea ei în Reprezentare Simbolica (Fig. 4.2.3.1.4). 1 2 3 4 5 6 7 8 Fig. 4.2.3.1.3 Arbore Invers în Reprezentare Fizica Descrierea concentrata a Structurii de Date într-un LDD conventional este continuta înFig. 4.2.3.1.4. Se marcheaza doar prezenta Articolului Principal (Nod), a Articolului deLegatura (Arc), precum si a caracteristicilor de tip Set de Articole (Arce în Intrare si Arce înIesire).
    • 222 Modele de Date / Modelul Retea NOD 1 1 Arce în Arce în Iesire Intrare n n ARC Fig. 4.2.3.1.4 Arbore Invers în Reprezentare Simbolica Figurile 4.2.3.1.5 si 4.2.3.1.5 redau implementarea structurii în Plan Fizic (al Valorilor). Nod BEGIN Identificator Descriptor 1 Descriptor 2 .. Arce-în-Intrare Set de Articole Arce-în-Iesire Set de Articole END Arc BEGIN Nod Ascendent Nod Descendent Descriptor 1 .. END Fig. 4.2.3.1.4 Arbore Invers în Reprezentare Simbolica4.2.3.2 Avantajele si Dezavantajele Modelului Retea In concluzie se prezinta urmatoarele avantaje si dezavantaje ale Modelului Retea:Avantaje: - Eliminarea dificultatilor de actualizare specifice secventei de Segmente, prin posibilitatea de actualizare independenta a Articolelor Principale (Clasele de Entitati) si a Articolelor de Legatura (Relatiile între Clasele de Entitati) - Eliminarea redondantei în cazul reprezentarii structurilor m-nDezavantaje: - Legatura prea strânsa a descrierii Logice de reprezentarea Fizica pe suport prin prezenta structurii de Lista de Articole în Schema de Descriere - Dependenta reprezentarii fizice de suportul de memorare prin intermediul Referintelor de Adresa - Actualizare dificila a Listelor de Articole dependente de Referintele de Adresa
    • Modele de Date 223 NOD Caracteristici Nume Identificator Descriptor1 Descriptor2 Primul Arc Primul Arc în Intrare în Iesire Nodk Nod 1 1 D11 D21 .. NULL Arc 12 Nod 2 2 D12 D22 .. Arc 12 Arc 24 Nod 3 3 D13 D23 .. Arc 13 Arc 35 Nod 4 4 D14 D24 .. Arc 24 NULL Nod 5 5 D15 D25 .. Arc 25 Arc 57 Nod 6 6 D16 D26 .. Arc 36 NULL Nod 7 7 D17 D27 .. Arc 57 NULL Nod 8 8 D18 D28 .. Arc 58 NULL Fig. 4.2.3.1.4 Descrierea Nodurilor ca Articole Principale ARC Nodi Caracteristici Nume Identificator Descriptor1 Arc Succesor Arc Succesor Nod Nod (Intensitate în Intrare în Iesire Ascendent Descendent de Legatura) Arc 12 1 2 D12 .. NULL Arc 13 Arc 13 1 3 D22 .. NULL NULL Arc 24 2 4 D23 .. NULL Arc 25 Arc 25 2 5 D24 .. Arc 35 Arc 35 Nodj Arc 35 3 5 D25 .. NULL Arc 36 Arc 36 3 6 D26 .. NULL NULL Arc 57 5 7 D27 .. NULL Arc 58 Arc 58 5 8 D28 .. NULL NULL Fig. 4.2.3.1.4 Descrierea Arcelor ca Articole de Legatura
    • 224 Modele de Date / Modelul Relational / Relatia ca si Constructor de Structura4.2.4 Modelul Relational Promovat de cercetatorul Codd, prin articolele aparute la începutul anilor 1970[CODD70], [CODD71], Modelul Relational se bazeaza pe Teoria Matematica a Relatiilor(vezi sectiunea 3.1.2), ceea ce îi confera consistenta, prin fundamentarea teoretica a tuturorconceptelor. Ceea ce trebuie mai ales retinut pentru viitorul descrierii Structurilor de Date esteElementaritatea acestui model, înteles prin aceea ca nu exista metode mai simple si maicomplete de descriere a oricaror structuri. Modelele de SGBD-uri anterioare erau preocupate de reprezentarea unor StructuriFundamentale (Modelul Ierarhic – Structura 1 - n, Modelul Retea – Structura m -n). Seconsidera atunci ca modelul care poate reprezenta Structura Fundamentala cea mai generala vafi si cel preferat în descrierea oricarei structuri. Se neglija caracteristica dinamica a structurii,data de evolutia ei inevitabila în timp. Modelul Relational schimba obiectivul constructiv al modelelor precedente, orientându-l spre construirea Structurilor Elementare, care vor permite apoi configurarea oricarui tip deStructura de Date, diferita de la un moment la altul. Elementele de Baza pentru construireastructurilor sunt: Clasele de Entitati si Legatura între Clasele de Entitati. Pentru ambeleelemente poate fi folosit acelasi Constructor si anume Relatia. Aceasta unicitate dereprezentare a Elementelor de Baza reprezinta descoperirea esentiala a Modelului Relational,care ofera pentru prima data robustete si dinamism Structurilor de Date prin aceea ca, având ladispozitie Modulele de Baza (Caramizile) constructia dorita poate fi în orice momentconstruita si reconstruita dupa preferinta utilizatorului, fara a necesita dezasamblare sireasamblare (vezi facilitatile oferite de conceptul de Vedere din Nivelul Extern al ModeluluiRelational). De aceea orice dezvoltare a acestui model trebuie conceputa ca un alt nivel dedescriere care poate oferi alte viziuni cerute de utilizatori asupra datelor, dar care trebuie sapastreze la baza forma elementara de descriere (Modelul Relational). Pentru evidentierea avantajelor enuntate mai sus se vor folosi în continuare mai multeforme de prezentare ale acestui Model de Date, de la cele intuitive spre cele formalizate. Seîncepe cu o prezentare simplificata, care sa ofere la acest nivel posibilitatea unei comparatiidirecte cu celelalte modele descrise în sectiunile precedente si care are totodata scopul de atrasa directia de evolutie în perfectionarea metodelor de reprezentare a structurilor.4.2.4.1 Relatia ca si Constructor de Structura Constructorul de Structura în Modelul Relational este Relatia, conform definitieipreluate din matematica (vezi sectiunea 3.1). Notiuni ca Domeniu, Tupla, Relatie se vor regasiimplementate direct în mediul Structurilor de Informatii si Date. Vorbind despre Structurile deDate specifice Modelului Relational putem face urmatoarele asocieri: o Domeniul– este reprezentat de Multimea Valorilor pe care le poate lua o anumita Însusire (Caracteristica) a unei Entitati în Colectia de Date • D i ≡ Codul Beneficiarului ≡ {101, 102, 103, 104, ..} • D i+1 ≡ Culoarea Produsului ≡ {alb, rosu, negru, ..} • D i+2 ≡ Cantitatea Contractata ≡ {10, 20, 100, ..}
    • Modele de Date / Modelul Relational / Relatia ca si Constructor de Structura 225 o Tupla § Logica – o Multime Ordonata de Atribute (Însusiri) extrase din Multimea Insusirilor definite în Colectia de Date si care descrie o anumita Entitate • T j ≡ BENEFICIAR (Cod, Nume, Companie, Cont) – Beneficiarul are un Cod, un Nume, o Companie si un Cont § Fizica – o Multime Ordonata de Valori extrase din Domenii care descriu o Legatura (Relatie) confirmata de realitate ca un fapt • T jk ≡ Beneficiarul k ≡ {101, Compania X, 11123, Oras Y} – exista un Beneficiar cu urmatoarele Valori de Caracteristici: Codul ≡ 101; Numele ≡ Compania X; Contul ≡ 11123 - Relatia – este o Submultime a Produsului Cartezian a mai multor Domenii, reprezentate ca o Multime de Tuple o BENEFICIAR ⊆ Cod Beneficiar x Nume Beneficiar x Cont Beneficiar x Oras Resedinta Beneficiar Sau: BENEFICIAR ≡ { T j } pentru ∀ j ∈ {1 .. b}, unde b e Numarul de Beneficiari memorati în Baza de Date Se regaseste asadar definitia cunoscuta: “Fiind data o multime i de Domenii Di , nevide, dar nu neaparat distincte, o Relatie R este o Multime de Tuple privite fiecare ca multimi ordonate de Valori (v 1 , v2 .. vi ), astfel încât vj ∈ D j pentru ∀ j∈ {1 .. i}. Elementele multimii R se numesc Tuple (sau n-Tuple), iar Gradul Relatiei e dat de i.” Domeniile pe care e definita o Relatie reapar ca si Atribute descriptoare ale Relatiei.Distinctia între Domeniu si Atribut provine din faptul ca Domeniile pe care este definita oRelatie nu trebuie sa fie neaparat distincte (vezi relatia ANSAMBLU din Fig. 4.2.4.3), în timpce Atributele Relatiei trebuie sa respecte conditia de unicitate ca Nume. Spatiul Informatiilor Modelul Relational Spatiul Datelor Clasa de Notiune Relatie Definita Fisier Definit Entitati (Tabela de Baza) Omogen Obiecte Instantiata Memorat (Vedere) Entitate Notiune Tupla Logica Articol Logic Obiect Fizica Fizic Nume Domeniu Tip Caracteristica Atribut Data Nume Valoare Valoare Valoare Tab. 4.2.4.1 Comparatie de termeni – SI / MR / SD
    • 226 Modele de Date / Modelul Relational / Relatia ca si Constructor de Structura O Relatie poate fi reprezentata foarte sugestiv printr-un Tabel datorita corespondenteice poate fi facuta între Coloanele Tabelei si Atributele Relatiei pe de o parte si RândurileTabelei si Tuplele Relatiei pe de alta parte.Exemplu: Sa reluam exemplul din Fig. 2.4.2, COMPUS – COMPONENT dându-i o reprezentarerelationala. Pentru început se definesc Domeniile (Fig. 4.2.4.2), pe care se vor construiRelatiile PRODUS (Fig. 4.2.4.3), ca o Clasa de Entitati si ANSAMBLU (Fig. 4.2.4.4) ca oLegatura între Clasa de Entitati PRODUS, vazuta ca si COMPUS si ca si COMPONENT. DOMENIU ATRIBUT Nume Valori Relatie Nume PRODUS Cod Cod {A, B, C, D, E, F} ANSAMBLU Cod-Compus ANSAMBLU Cod-Component Nume {N1, N2, N3, N4, N5, N6} PRODUS Nume Culoare {C1, C2, C3} PRODUS Culoare Greutate {G1, G2, G3, G4} PRODUS Greutate Tab. 4.2.4.2 Domeniile Structurii Relationale COMPUS – COMPONENT PRODUS COD* NUME CULOARE GREUTATE A N1 C1 G1 B N2 C2 G2 C N3 C3 G2 D N4 C1 G3 E N5 C3 G4 F N6 C1 G1 Tab. 4.2.4.3 Relatia PRODUS ANSAMBLU COD-COMPUS* COD-COMPONENT* CANTITATE A B Q1 B C Q2 B D Q3 B E Q4 C F Q5 C E Q6 Tab. 4.2.4.4 Relatia ANSAMBLU Datele reprezentate extensional în figurile mentionate sunt apoi descrise intensional cuajutorul unui Limbaj de Descriere a Datelor (LDD). Redam mai jos Schema de Descriere aModelului de Date Relational PRODUS – ANSAMBLU (Fig. 4.2.4.3). Arborele de Structuradin Fig. 4.2.4.6 concentreaza caracteristicile Modelului Relational.
    • Modele de Date / Modelul Relational / Relatia ca si Constructor de Structura 227 DOMAIN Cod CHARACTER 8 DOMAIN Nume CHARACTER 20 DOMAIN Culoare CHARACTER 6 DOMAIN Greutate NUMERIC 4 DOMAIN Cantitate NUMERIC 10 RELATION Produs (Cod, Nume, Culoare, Greutate) KEY (Cod) RELATION Ansamblu (Cod-Compus DOMAIN Cod, Cod-Component DOMAIN Cod, Cantitate) KEY (Cod-Compus, Cod-Component ) Fig. 4.2.4.5 Schema de Descriere a structurii PRODUS - ANSAMBLU Legat de Elementele unei Structuri Relationale de Date se pot face urmatoareleobservatii: - Domeniul descrie natura unei Multimi de Valori (Nume, Tip, Restrictii impuse) - Relatia se descrie ca o Multime de Atribute provenite din Domenii anterior definite AN P P-PRODUS AN-ANSAMBLU c-cod • cs q c • cp * • n-nume • cl g * * cl-culoare g-greutate n cs-cod-compus cp-cod-component q-cantitate Fig. 4.2.4.6 Arbore de Structura PRODUS – ANSAMBLU - Relatiile pot fi categorisite în: o Relatii ce stabilesc doar legatura între Domenii (ex. PRODUS) o Relatii ce stabilesc, prin intermediul Domeniilor, o legatura între alte Relatii (ex. ANSAMBLU) - Definirea Domeniilor poate fi si este adesea evitata, prin transferarea Descrierii Domeniilor în Descrierea Atributelor din Relatii - Rolul definirii Domeniilor este însa mai larg decât simpla economie de declarare a Tipurilor si Restrictiilor atasate Atributelor; el se extinde asupra definirii, înca din aceasta faza incipienta, a Legaturilor Structurale între Date prin recunoasterea Domeniilor Comune ale Atributelor, care vor realiza Cuplarea Tabelelor prin operatia de Reunire (JOIN), operatie ce în viitor va putea sa fie automat invocata pe baza cunoasterii Domeniilor Comune
    • 228 Modele de Date / Modelul Relational / Proprietatile RelatieiDefinitie: Baza de Date Relationala – O colectie de Relatii Normalizate, de diverse grade, variabile în timp ca si continut [DATE95].4.2.4.2 Proprietatile Relatiei Cercetatorul Codd [CODD70] este cel care defineste si acele proprietati fundamentalepe care Constructorul Modelului Relational trebuie sa le îndeplineasca pentru a respectadefinirea teoretica a Relatiei ca Multime. Aceste Proprietati referitoare la o Relatie sunt: o Nici o Tupl a nu e identica cu alta Tupla Fiecare Tupla a unei Relatii, în calitate de Element al unei Multimi, trebuie sa fie Unica (vezi sectiunea 5.2.4.4). Aceasta proprietate va permite în continuare, la Manipularea Structurilor Relationale, sa se preia cu usurinta operatorii din Teoria Multimilor (Reuniune, Intersectie, Diferenta, Produs Cartezian – vezi sectiunea 4.2.4.5.1.2). o Ordinea Tuplelor e indiferenta Relatia respecta conditia de Multime prin care proprietatea de Echivalenta între Elemente (Tuple) implica absenta oricarui privilegiu (inclusiv cel al Ordinii). Ca urmare Ordinea Tuplelor va fi introdusa, la fel ca în modelul matematic, cu ajutorul unei Relatii de Ordine auxiliara (reprezentata de Tabela de Index curenta), care se ataseaza Multimii Tuplelor pentru a o transforma într-o Multime Ordonata. o Ordinea Domeniilor e indiferenta Definirea Relatiei ramâne aceeasi indiferent de Ordinea Domeniilor. Trebuie însa remarcat ca, odata Relatia definita, Ordinea Domeniilor trebuie mentinuta pe toata durata de viata a Relatiei, pentru a se putea reface în orice moment corespondenta Atribut – Domeniu. Sistemele de Gestiune, care permit la un moment dat schimbarea Ordinii Domeniilor, efectueaza o operatie automata de recopiere a vechii Relatii (Tabele de Baza) într-una noua, cu stergerea (sau arhivarea) în final a celei vechi. o Toate Atributele sunt Date Elementare (Nedecompozabile) Prin aceasta restrictie, care cere ca, în Tabelele de Baza, Câmpurile de Date sa fie de tip Scalar si nu de tip Multime, impune mentinerea Relatiei ca Unic Constructor de Structura. O Relatie care îndeplineste aceasta restrictie se zice Relatie Minim Normalizata (cu grad minim de normalizare – vezi sectiunea 5.3.1). Exemplu: Structura de mai jos, în ciuda reprezentarii ei tabelare nu este o structura acceptata de Modelul Relational, întrucât contine Date Decompozabile (vezi atributul Obligatie, care are ca descendenti atributele Produs si Cantitate. Structura se considera Nenormalizata.
    • Modele de Date / Modelul Relational / Proprietatile Relatiei 229 CONTRACT Beneficiar Obligatie Produs Cantitate B1 P1 Q1 B1 P2 Q2 B1 P3 Q3 B1 P4 Q2 B1 P5 Q4 B2 P1 Q5 B2 P2 Q1 B3 P2 Q3 B4 P5 Q6 Tab. 4.2.4.2.1 Structura Nenormalizata Eliminarea Nenormalizarii se face simplu prin eliminarea Structurii Ierarhice din cadrul Tabelei prin eliminarea atributului compus Obligatie (vezi structura din Fig.4.2.4.2.2). CONTRACT Beneficiar Produs Cantitate B1 P1 Q1 B1 P2 Q2 B1 P3 Q3 B1 P4 Q2 B1 P5 Q4 B2 P1 Q5 B2 P2 Q1 B3 P2 Q3 B4 P5 Q6 Tab. 4.2.4.2.2 Structura Normalizata Se cere aici mentionat faptul ca o diversitate de implementari ale Modelului Relationalau profitat cu succes de licente bazate pe abateri de la restrictiile prezentate anterior. Toateaceste succese momentane nu trebuiesc însa privite decât ca adaptari ingenioase la stadiulmomentan de evolutie a puterii de calcul. Evolutiile ulterioare au dovedit însa valabilitateaacestor restrictii în mediile de procesare adaptate unor abordari avansate în ceea ce privesteîncorporarea sporita de semantica în Modelele de Date. Ne exprimam totodata rezervele legate de orice implementare la nivel intern aModelelor Relationale Extinse, care încalca restrictiile precedente si prin aceasta se abat de laElementaritatea Modelului. Revenirea la Modelul Relational de Baza se va face oricândputerea de calcul creste suficient pentru a putea oferi performante adecvate de implementare aMotorului Relational. Extinderea ceruta de utilizari specifice va putea fi însa realizata la unnivel superior de implementare a structurilor dorite, care sa se sprijine însa în interior pe unModel Consistent de Date (vezi si sectiunea 6.3).
    • 230 Modele de Date / Modelul Relational / Proprietatile Relatiei4.2.4.3 Intensiunea si Extensiunea Relatiilor Relatiile, fiind Multimi definite pe Produsul Cartezian al Domeniilor, preiau de laMultimi descrierea Intensionala si Extensionala. Notiunile sunt deosebit de utile în definireaPlanurilor Logice si Fizice de descriere a Structurilor Relationale. In primul plan vom întâlniSchemele de Relatii descrise prin precizarea Tuplelor Logice (vezi Fig. 4.2.4.2). In cel de aldoilea plan vom regasi ansamblul Tuplelor Fizice, care descriu partea variabila în timp arelatiilor (vezi tabelele 4.2.4.3 si 4.2.4.4). Intensiunea Relatiei – este reprezentata de Ansamblul Caracteristicilor care descriuRelatia ca Multime, definita prin Enuntarea de Proprietati. Intensiunea Relatiei reprezintapartea constanta în timp a relatiei. Ea contine Descrierea Logica, prin Nume, Tipuri si Conditiia Proprietatilor Generale ale Structurii de Date, proprietati care vor controla si vor validaactualizarea Structurii Fizice cu Instante. Intensiunea Relatiei contine urmatoarele elemente: o Denumirea Structurii § Numele Domeniilor § Numele Relatiei § Numele Atributele (cu Domeniile asociate) o Restrictiile de Integritate § Restrictii de Identificare • Declarare Chei Candidate o Cheia Primara o Chei Candidate (Alternative) • Declarare Proceduri de Verificare a Unicitatii § Restrictii de Referire • Declarare Chei Straine • Declarare Conditii de Validare a Referirii (vezi sectiunea 3.4.5) § Alte Restrictii • Declarare Conditii de Validare a Valorilor o De Corectitudine (tipuri, limite, liste de valori etc.) o De Compaibilitate (conditii de corelare a valorilor diferitelor Atribute, din aceeasi Tupla sau din Tuple diferite) Extensiunea Relatiei – este reprezentata de Ansamblul Valorilor care descriu Relatiaca Multime definita prin Enumerarea de Elemente (tuple). Extensiunea Relatiei reprezintapartea variabila în timp a relatiei. Ea contine Descrierea Fizica, prin Instante (Valori) aStructurii de Date, fiind foarte utila pentru extragerea acelor Proprietati Particulare ce vorputea fi sintetizate în Proprietati Generale pentru a fi încorporate în Descrierea Logica.
    • Modele de Date / Modelul Relational / Reguli de Integritate a Relatiilor 2314.2.4.4 Cheile Relatiilor Cheile Relatiilor sunt Atribute Speciale ale Relatiilor, care joaca un rol aparte înIdentificarea, Accesul si Ordonarea Tuplelor componente ale Relatiilor. Functia lor principalaeste cea de Identificare, subdivizata în: - Identificare Propriuzisa – Chei Primare, Chei Candidate (Alternative) - Referire – Chei Straine In Tab. 4.2.4.4.1 se da o clasificare a Cheilor care pot apare în Relatii. Tip Cheie Redondanta - Compusa m Atribute Componente 1 Cheie Candidata Simpla 1 Atribut Component Proprie Compusa m Atribute Componente Neredondanta n Chei Candidate Simple 1 Atribut Component - 1 Cheie Primara Compuse m Atribute Componente - n-1 Chei Candidate Straina - Simpla 1 Atribut Component Compusa m Atribute Componente Tab. 4.2.4.4.1 Tipuri de CheiDefinitii: Domeniu Primar – Domeniul pe care este definit cel putin un Atribut Constituent al unei Chei Primare. Cheie Proprie – Multime de Atribute ce constituie Identificatorul unei Relatii (nu exista doua Tuple cu aceeasi combinatie de Valori pentru aceste Atribute). Constituent de Cheie – Atribut participant într-o Cheie si care mai poarta numele de Atribut Primar. Cheie Straina – Multime de Atribute din cadrul unei Relatii, care constituie Identificatorul (Cheia Primara) a altei Relatii. Cheie Redondanta - Multime de Atribute care ramâne Cheie prin excluderea unei submultimi de Atribute Constituenti de Cheie. Cheie Neredondanta - Multime de Atribute din care nu poate fi exclus nici-un Atribut astfel ca ea sa ramâna Cheie. Cheie Candidata (Alternativa) – fiecare Cheie Neredondanta a unei Relatii. Cheie Primara – orice Cheie Candidata aleasa de utilizator (din motive subiective – simplitate, obisnuinta, preferinta etc.) ca Identificator Privilegiat. Cheie Surogata (Interna) – o Cheie Primara generata automat de Sistem.
    • 232 Modele de Date / Modelul Relational / Cheile Relatiilor4.2.4.4.1 Reguli de Integritate a Relatiilor Având în vedere Elementaritatea Structurilor memorate într-o Baza de DateRelationala, apare în mod firesc necesitatea verificarii consistentei lor pentru a putea garanta castructurile care vor fi construite pe baza elementelor atomice stocate vor fi corecte. Asigurareaacestei proprietati se face prin adaugarea la Elementele de Structura a Conditiilor de Validitate,impuse de semantica atasata structurii. Aceste conditii iau forma Regulilor de Integritate caresunt memorate în Baza de Date. Exista doua categorii principale de Reguli de Integritate: o Integritatea de Identificare (Entitatii) – Fiecare Entitate trebuie sa aiba o Cheie Primara în care nici-un Constituent nu poate fi nedefinit, pentru pastrarea posibilitatilor ca fiecare Identificator sa corespunda unei Entitati (de aici si cealalta denumire a Restrictiei – Integritatea Entitatii). o Integritatea de Referire – Cheia Straina poate fi nedefinita, dar atunci când ea e definita, Valoarea ei trebuie sa faca parte din Ansamblul Valorilor memorate în Cheia Primara pe care Cheia Straina o refera.4.2.4.4.2 Identificare, Acces si Ordonare în Structuri Relationale Identificarea, Accesul si Ordonarea în Structurile Relationale se realizeaza cu ajutorulCheilor. Asa dupa cum s-a aratat deja, prin Cheie se întelege orice Combinatie de Atribute aleunei Relatii care îndeplineste o functie specializata de tratare a Tuplelor (de exemplu,identificare, acces, ordonare). In prelucrarea datelor Cheile sunt în mod eronat asimilate cu Tabelele de Index,prescurtat, cu Indecsii, care reprezinta Structuri Secundare atasate Relatiilor si care ridica doarperformanta în îndeplinirea anumitor functii. Cu alte cuvinte Cheile trebuie privite ca siProprietati ale Relatiilor, conferite acestora de functiile pe care le joaca anumite Atribute aleRelatiilor. Pentru asigurarea acestor proprietati SGBD-ul poate utiliza diferite mijloace, întrecare se numara si Tabelele de Index, obiecte ce pot fi definite si eliminate direct de Sistemul deGestiune sau de catre Utilizator. Dupa cum se va vedea în continuare, Tabelele de Index pot asigura realizarea, înanumite conditii, a functiilor atasate Atributelor de tip Cheie. Functiile specifice Tabelelor deIndex sunt enumerate mi jos: - Asigurarea Functiei de Acces Rapid, cu toate ca functiile de Localizare, ca de altfel si cea de Identificare (verificare a Unicitatii) pot fi asigurate teoretic si prin Acces Lent (inspectie secventiala a Tuplelor în absenta Tabelelor de Index) (ex. comenzile LOCATE, SET FILTER din produsele Xbase) - Asigurarea dinamica (în timpul actualizarii) a Functiei de Ordonare, ce poate fi altfel realizata doar prin Sortare Fizica (dupa actualizare) a Fisierelor Memorate atasate Tabelelor de Baza (comanda SORT din produsele Xbase) - Asigurarea Functiei de Identificare doar în acele SGBD-uri care au atasate Tabelelor de Index proprietati declarative de tipul: Index Primar, Index Candidat
    • Modele de Date / Modelul Relational / Identificare, Acces si Ordonare 2334.2.4.4.2.1 Chei de Identificare Cheile de Identificare sunt proprietati atasate Relatiilor pe baza semanticii care esteacordata Colectiilor de Date sursa. Ca urmare recunoasterea si declararea acestor proprietatiface parte din analiza Spatiului de Informatii al utilizatorului în vederea precizarii CerintelorSistemului de Aplicatii (Business Logic Definition). Cheile de Identificare sunt reprezentatede Cheile Candidate si de Cheile Straine care se declara într-o Structura Relationala de Dateprin urmatoarele Chei: o Chei Primare - desemnate sa asigure Integritatea Entitatii (posibilitatea de localizare unica a fiecarei Entitati Obiect (Tuple) o Chei Straine - desemnate sa asigure Integritatea de Referire o Chei Candidate - desemnate sa ofere forme diversificate de Identificare a Entitatilor Obiect si în plus posibilitatea de analiza a Gradului de Normalizare a Relatiilor (vezi sectiunea 5.1.3); Cheile Candidate sunt denumite si Chei Secundare sau Alternative SGBD-urile care nu beneficiaza de facilitatea de definire a Cheilor de Identificare, nupot asigura Conditiile de Integritate în mod Structural (prin simpla declarare în StructuraDatelor a Functiei de Identificare pe care o îndeplineste un Atribut) si ca urmare ele nu potevita, fara interventia programatorului (în mod Procedural), inserarea de Omonime (Tuple cuacelasi Identificator), în alta exprimare, inserarea de Coduri Duble. O amagire o poate constitui facilitatea oferita de optiunea de declarare a unui IndexUnic. Aceasta facilitate permite însa numai filtrarea Dublurilor, prin crearea unui Index special,în care Dublurile nu sunt inserate, cu toate ca adaugarea în Relatie (în Fisierul Memorat) esteefectuata. Un asemenea Index va oferi posibilitatea eliminarii dublurilor dintr-un rezultat deSelectie (echivalenta cu comanda SELECT UNIQUE din SQL), dar nu va proteja datelememorate în Tabelele de Baza contra ambiguitatii de identificare. B L c * n l c * n t BENEFICIAR LOCALITATE c - Cod c - Cod n - Nume n - Nume l - Localitate t - Tip Fig. 4.2.4.4.2.1.1 Arbore de Structura BENEFICIAR – LOCALITATEExemplul 1: Se considera Relatia BENEFICIAR cu atributele Cod, Nume, Localitate. Sa se selecteze Orasele în care exista Beneficiari (vezi relatia BENEFICIAR din Fig. 4.2.4.4.2.1.1).
    • 234 Modele de Date / Modelul Relational / Identificare, Acces si Ordonare Este suficient sa se Indexeze Unic relatia BENEFICIAR dupa Localitate si sa se afiseze continutul (spre exemplu prin comanda BROWSE). Se vor citi toate valorile definite de Localitati, care vor aparea o singura data, chiar daca în aceea Localitate se afla mai mult de un BENEFICIAR. Alternativa oferita de produsele Xbase pentru a asigura Integritate de Identificare estecea Procedurala. Pentru a prezenta modul de asigurare a Conditiilor de Integritate de Identificaresi de Referire pe cale procedurala se dau urmatoarele exemple:Exemplul 2: Sa se actualizeze relatia LOCALITATE din Fig. 4.2.4.4.2.1.1, cu ajutorul comenzii în mod ecran BROWSE astfel încât sa se asigure pentru orice adaugare de tupla Integritatea de Identificare pentru Cheia Primara COD. Pentru a asigura, în regim de afisare a datelor (mod ecran BROWSE) posibilitatea de verificare a unicitatii valorii unui atribut, trebuie sa se asocieze atributului respectiv o Procedura de Validare, a carei structura este urmatoare: - Se verifica prezenta unei tuple cu Valoarea de Atribut egala cu cea din Tupla care se adauga - Se returneaza Fals daca exista o Tupla cu aceasta Valoare; în aceasta situatie actualizarea în regim de afisare este r efuzata, sistemul mentinând Vechea Valoare a atributuluiExemplul 3: Sa se scrie procedura care realizeaza actualizarea celor doua relatii cu asigurarea urmatoarelor restrictii: - Actualizarea simultana a relatiilor pornind de la datele pe BENEFICIARI - Garantarea Integritatii de Identificare pentru ambele relatii - Garantarea Integritatii de Referire între cele doua relatii Structura Procedurilor de Actualizare descrisa în Pseudo-Cod este urmatoare: o Procedura de Actualizare BENEFICIAR § Se citeste Valoarea Identificatorului pentru tupla care se adauga (valoarea atributului Cod Beneficiar) § Se verifica prezenta unei Tuple cu Valoarea de Atribut Cod Beneficiar egala cu cea citita • daca exista o Tupla cu aceasta Valoare § se refuza actualizarea § se solicita o noua Valoare de Identificator • daca nu exista o Tupla cu aceasta Valoare
    • Modele de Date / Modelul Relational / Identificare, Acces si Ordonare 235 § se genereaza o noua tupla cu valoarea citita de Identificator § Se citesc si se actualizeaza restul valorilor de atribute din relatia BENEFICIAR § La citirea Valorii de Cheie Straina (atributul Localitate Beneficiar) se efectueaza Procedura de Verificare LOCALITATE • daca Procedura a raspuns ADEVARAT se actualizeaza Cheia Straina cu Valoarea citita • daca Procedura a raspuns Fals se solicita o noua Valoare de Cheie Straina o Procedura de Verificare LOCALITATE § Se verifica prezenta unei tuple cu valoarea Cod LOCALITATE = Localitate BENEFICIAR • daca exista o Tupla cu aceasta Valoare se returneaza ADEVARAT • daca nu exista o Tupla cu aceasta Valoare se solicita adaugarea unei noi LOCALITATI § la confirmare • se genereaza o noua Tupla cu valoarea de Identificator data de Localitate BENEFICIAR • se citesc si se actualizeaza restul Valorilor de Atribute din relatia LOCALITATE • se returneaza ADEVARAT § la infirmare se returneaza Fals Proceduri ca cele de sus pot fi c usurinta parametrizate si introduse ca Module de uActualizare în Bibliotecile de Proceduri atasate Bazei de Date. Este primul pas spre construireaProcedurilor Stocate, ca Obiecte ale Bazei de Date. In SGBD-urile evoluate ( RACLE, INFORMIX, SYBASE, dar chiar si VISUAL FOX) OProcedurile de Verificare a Integritatilor de Identificare si de Referire sunt încorporate înfacilitatile oferite de sistem, ceea ce determina aparitia în Limbajul de Definitie a clauzelordeclarative de tip: Cheie Primara, Cheie Candidata, Cheie Straina. Întrucât aceste Proceduride Control necesita, din motive de performanta acces rapid, clauzele mai sus enumerate aparatasate Tabelelor de Index. Aceasta determina declansarea automata a procedurilor deverificare a Integritatii Structurii de Date în momentul reperarii anumitor Evenimente, îngeneral legate de Actualizarea Structurilor Relationale ( daugari, Stergeri, Modificari), la Anivel de Tuple sau Atribute. Controlul de creare si mentinere a Integritatii Structurilor ia formefoarte diverse, ceea ce implica completarea simplelor Declaratii de Chei cu atasarea la Regulilede Integritate a unor Conditii Specifice solicitate de Utilizator în procesul permanent deactualizare a extensiunii Relatiilor (vezi sectiunile 3.4.5. si 4.2.1.1.2.).
    • 236 Modele de Date / Modelul Relational / Identificare, Acces si Ordonare4.2.4.4.2.2 Chei de Acces Cheile de Acces reprezinta facilitati atasate Structurilor de Date în vederea cresteriiPerformantei în Prelucrarea lor. Aceste facilitati sunt orientate catre diversificarea Strategiilorde Acces la Date, prin ext inderea Accesului Direct (ex. Acces dupa Valori de Expresii, IndecsiMultipli etc.) precum si a celui Secvential (ex. Ordinii de Inspectie Multiple, Filtrate etc.).Accesul la Date este strâns legat de Operatiile asupra Structurilor, în cazul de fata StructurileRelationale (pentru detalii vezi sectiunea 4.2.5.3). Dintre cele doua moduri de prelucrare aStructurilor Relationale (vezi sectiunea 4.2.4.7.5): - Procedurala - prin Navigarea în Tabele - Neprocedurala - prin Specificarea Cererilor de Regasireprimul mod este cel mai adecvat pentru clasificarea Strategiilor de Acces, datorita faptului caîn al doilea caz selectarea modului de acces este preluat de SGBD, în cadrul operatiilorimplementate în Motorul Relational. In cele ce urmeaza clasificarea va fi facuta pe bazafacilitatilor oferite de Mediile de Programare care utilizeaza preponderent Procedurile deNavigare în Tabele (produsele din gama Xbase). Procedurile de Navigare introduse înExtensiile de Limbaje Neprocedurale Standardizate (PL/SQL) opereaza exclusiv asupraCursorilor, care reprezinta Structuri Secventiale Denormalizate. Fiecare Tabela de Baza (fisier DBF) reprezinta o Multime de Tuple, care poate fi privita,în absenta oricarei Tabele de Index atasata, ca o Multime Logic Neordonata (Ordinea Logicapresupune prezenta unui Criteriu de Ordonare important pentru prelucrarea datelor). Datoritasecventialitatii suportului de memorare, Tabela de Baza apare întotdeauna ca o Multime deTuple Fizic Ordonata. Ordinea tuplelor corespunde în acest caz Ordinii Cronologice deInserare si Eliminare de Tuple din Tabela de Baza. Întrucât operatia de Eliminare de Tuplemodifica Numarul de Ordine al Tuplelor, s-au adoptat doua operatii de Stergere Tuple înStructurile de Date Relationale din produsele comerciale din clasa Xbase: o Stergere Logica - Marcare Tupla pentru a putea deveni Invizibila pentru Utilizator (comanda DELETE), mentinându-se posibilitatea de demarcare ulterioara (comanda RECALL) cu reintegrarea Tuplei în Tabela de Baza o Stergere Fizica – Eliminare Tupla din Tabela de Baza, cu refacerea Numerelor de Ordine ale Tuplelor (comenzi DELETE urmate de comanda PACK); Operatia este Ireversibila Numarului de Ordine al Tuplelor îi corespunde un Identificator Intern de Tupla (Numarde Înregistrare), care este gestionat de sistem. In produsele Xbase, care au la baza un sistem decomenzi orientat pe Prelucrarea Procedurala (Navigarea în Tabele), sistem ce a fost doarulterior extins cu comenzi Neprocedurale (SQL), o mare importanta o au notiunile descrise maijos (vezi Fig. 4.2.4.7.5.1.1, cu mentiunea ca în produsele Xbase, Zona de Lucru (Cursorul)corespunde unei singure Tabele de Baza): o Tabela de Baza Curenta - Tabela de Baza, atasata unei Zone de Lucru Curente (prin comanda OPEN); Tabela de Baza ramâne unica în Baza de Date, ea este însa vazuta prin intermediul unei anumite Zone de Lucru o Zona de Lucru Curenta - Zona de Memorie Interna atasata la un moment dat unei Tabele de Baza (prin comanda SELECT); aceeasi Tabela de Baza poate fi
    • Modele de Date / Modelul Relational / Identificare, Acces si Ordonare 237 deschis a în mai multe Zone de Lucru Curente fiecare având atribuite Proprietati Specifice dintre care cele mai importante sunt: • Un Nume (de tip Alias –„alt Nume”) • O Ordine de Inspectie data de Indexul de Ordonare atasat • O Pozitie de Tupla în Multime, pozitie memorata într-o Variabila de Sistem numita Cursor; (de la acest termen provine si cealalta denumire a Zonei de Lucru si anume Cursor) o Tupla Curenta - Tupla pe care s-a facut pozitionarea la un moment dat a Variabilei de Sistem Indicator de Pozitie (Cursor), care memoreaza Identificatorul Intern al Tuplei Curente, denumit si Numarul de Înregistrare Curenta o Ordine Curenta – Ordinea de Inspectie la un moment dat a Tabelei de Baza, specificata de Indexul Selectat pentru a defini Ordinea Logica a Tuplelor la acel moment Referitor la o Tabela de Baza se pot utiliza doua Functii de Sistem deosebit de utilepentru navigare: - Cardinalul Multimii de Tuple din Tabela de Baza la un moment dat, indicând Numarul Total de Înregistrari din Tabela de Baza (functia RECOUNT() din produsele Xbase) - Ordinalul Multimii de Tuple din Tabela de Baza la un moment dat, precizat de Tupla Curenta memorata în Indicatorul de Pozitie (functia RECNO() din produsele Xbase) Valorile Functiilor de Sistem descrise anterior sunt Protejate la Scriere, permitândUtilizatorului doar Acces în Citire. Chiar si utilizarea lor pentru Referirea Structurala estecontraindicata, datorita posibilei lor modificari de catre sistem în procesul de actualizare sauîntretinere a Tabelelor de Baza (inserari, eliminari sau reordonari fizice de tuple) Cu aceste notiuni se poate trece la analiza Strategiilor de Acces la Tuplele Tabelelor deBaza: o Strategii de Acces dupa Numarul Tuplelor Accesate § Accesul la o Tupla - în acest caz regasirea se efectueaza prin comanda de Cautare Tupla. (comenzile FIND si SEEK ce utilizeaza Indecsi Densi) § Accesul la o Submultime de Tuple care au o Proprietate Comuna - în acest caz regasirea se efectueaza în doi pasi : • se cauta Submultimea de Tuple care satisface Conditia de Cautare si se pozitioneaza Cursorul pe prima Tupla din Submultime (comenzile FIND si SEEK ce utilizeaza Indecsi Nedensi) • se inspecteaza Tuplele din Multimea gasita (comanda CONTINUE) Definirea unei Submultimi de Tuple se realizeaza prin doua procedee: • Cuantificare - definirea Ariei de Cautare data de Multimea de Tuple pe care se face cautarea pe baza Ordinii Tuplelor în Tabela de
    • 238 Modele de Date / Modelul Relational / Identificare, Acces si Ordonare Baza. Definirea Ariei de Cautare se face cu ajutorul clauzei SCOPE din Comenzile de Acces, comanda ce are ca optiuni: o ALL - Toate Tuplele din Tabela de Baza o REST - Restul Tuplelor, începând cu Pozitia Curenta o NEXT n - Urmatoarele n Tuple o RECORD n - Tupla cu Numarul Intern de Identificare n • Filtrare - cautarea si selectarea Tuplelor din Aria definita anterior si care satisfac o Conditie Data. Definirea Filtrului se face cu clauzele: o FOR expresie (Pentru Expresia Adevarata) - Toate Tuplele din Aria de Cautare, ce satisfac Conditia Logica continuta în Expresie o WHILE expresie (Cât Timp Expresia e Adevarata) - Toate Tuplele consecutive din Aria de Cautare, ce satisfac Conditia Logica continuta în Expresie, începând cu Tupla Curenta si terminând la prima Tupla care nu mai îndeplineste Conditia o Strategii de Acces dupa Modul de Realizare a Accesului § Acces prin Inspectie - accesul se realizeaza prin trecere de la o Tupla la alta în Ordinea Logica sau Fizica atasata Tabelei de Baza; inspectia poate fi realizata: • Pas-Cu-Pas - Salt peste un Numar de Tuple înainte (+) sau înapoi (-) (comanda SKIP ± n) • Cursiva - parcurgerea Repetitiva a Tuplelor unei Tabele de Baza (comenzile SCAN – ENDSCAN) § Acces prin Selectie - accesul se realizeaza prin cautarea unei Submultimi de Tuple care verifica o Conditie de Selectie • Secventiala - cautarea se realizeaza prin verificarea Tuturor Tuplelor din Tabela de Baza o Asociativa - Selectia Secventiala se realizeaza prin verificarea Valorii Conditiei de Selectie pentru Toate Tuplele din Tabela de Baza (comenzile LOCATE si SET FILTER) • Directa - cautarea se realizeaza prin Adresare Rapida o Interna - pe baza Numarului de Înregistrare (comanda GO) o Asociativa - prin Valoare de Conditie de Selectie, cu ajutorul Tabelelor de Index (comenzile FIND si SEEK) Cheile de Acces sunt reprezentate, în cazul Accesului Direct Asociativ (regasire pe baza de Valoare de Conditie
    • Modele de Date / Modelul Relational / Identificare, Acces si Ordonare 239 de Selectie), de catre Atributele din Tabelele de Baza, ce intra în Expresia Conditiei de Selectie atasata Tabelului de Index utilizat pentru acces. Localizarea unei Tuple sau a unei Multimi de Tuple se poate face, în absenta Tabelelorde Index, prin inspectia exhaustiva a Tuplelor dintr-o Tabela de Baza (comenzile LOCATE siSET FILTER), ceea ce subliniaza înca o data faptul ca Structurile Relationale se construiescexclusiv cu ajutorul Tabelelor de Baza, Tabelele de Index fiind doar Structuri Auxiliare decrestere a performantelor de prelucrare a datelor. Tabelele de Index reprezinta totodata Structuri Dinamice ce pot fi atasate sau eliminate înorice moment de evolutie a Tabelelor de Baza, fara ca datele continute în acestea sa fie afectate.Se asigura astfel o noua forma de Independenta în cadrul Sistemelor cu Baze de Date si anumeIndependenta Structurii fata de Metodele de Acces (Independenta Tabelelor de Baza fata deTabelele de Index definite). O a doua forma de independenta se manifesta între Proceduri si Tabelele de Index atasateStructurii de Date. Independenta Procedurilor fata de Metodele de Acces masurata prinImunitatea Procedurilor la modificarile efectuate în Structurile Auxiliare este realizata în cadrulLimbajelor de Specificare (vezi sectiunea 4.2.4.5.2). Exista însa SGBD-uri care realizeaza aceastaindependenta si în cadrul Limbajelor de Navigare, prin încorporarea dinamica a ModulelorSpecifice de Acces în functie de Operatiile de Acces cuprinse în Proceduri (Sistemul R). Se poateafirma cu toate acestea ca pâna în prezent problema Independentei Procedurilor fata deStrategiile de Acces nu este în totalitate rezolvata, întrucât Viteza de Raspuns la Cereri continuasa fie dependenta de modul de definire a Tabelelor de Index. Fiecare Tabela de Index are atasata o Expresie de Indexare, care e evaluata pentrufiecare Tupla din Tabela de Baza indexata, expresie dupa care se face Inversarea Colectiei deDate continuta în Tabela de Baza (vezi sectiunea 3.4.2.2). Unei Tabele de Baza i se pot atasaoricâte Tabele de Index. Exista o mare varietate de Tipuri de Tabele de Index si de moduri deutilizare a acestora. Se indica în continuare mai multe clasificari ale Tabelelor de Index, cumentionarea Criteriului de Clasificare: o Tabele de Index dupa Rolul Indecsilor la un moment dat § Indecsi Pasivi - nu se actualizeaza cu datele actualizate în Tabelele de Baza (actualizarea lor va fi facuta ulterior, prin Reindexare, în cadrul unei Proceduri Seriale – Off Line) § Indecsi Activi - se actualizeaza la fiecare actualizare de date în Tabelele de Baza (prin Proceduri Paralele – On Line) • Index Principal – Indexul Curent selectat pentru a defini Ordinea Logica a Tuplelor la un moment dat (poate exista un singur astfel de Index, cu toate ca el poate fi modificat în mod dinamic) • Indecsi Secundari – ceilalti Indecsi Activi Asupra Tabelelor de Index (Indecsilor) se pot efectua mai multe operatii: - Creare Index - se genereaza o structura de Arbore Binar pornind de la o Tabela de Baza si o Expresie de Indexare (vezi sectiunea 3.4.2.2.1.2) - Dezactivare Index - se detaseaza Tabela de Index de Tabela de Baza
    • 240 Modele de Date / Modelul Relational / Identificare, Acces si Ordonare - Atasare Index - se ataseaza Tabela de Index de Tabela de Baza - Selectare Index - un Index Secundar e selectat ca Index Principal - Reactualizare Index - se refac Structurile de Arbori Binari ale Indecsilor Activi - Eliminare Index - se detaseaza Tabela de Index de Tabela de Baza si se sterge Indexul de pe suport o Tabele de Index dupa Multimea de Tuple Localizate (vezi si sectiunea 3.4.2.2.1.2) § Indecsi Densi - localizeaza o Tupla § Indecsi Nedensi - localizeaza o Multime de Tuple o Tabele de Index dupa Numarul Indecsilor Memorati într-un Fisier de Indecsi § Indecsi Individuali – Fisierul de Indecsi atasat Tabelei de Baza contine un singur Index § Indecsi Multipli - – Fisierul de Indecsi atasat Tabelei de Baza contine o Multime de Indecsi, identificati prin Nume (Etichete) o Tabele de Index dupa Complexitatea Expresiei de Indexare § Indecsi Simpli - Expresia de Indexare se rezuma la valoarea unui singur Atribut din Tabela de Baza § Indecsi Compusi - Expresia de Indexare se construieste pe baza mai multor Atribute din Tabela de Baza, putând include si apeluri de Functii de Sistem sau de Utilizator . o Tabele de Index dupa Numarul Tuplelor care participa la indexare § Indecsi Neconditionati - sunt indexate toate Tuplele din Tabela de Baza § Indecsi Conditionati - sunt indexate numai Tuplele din Tabela de Baza care verifica Conditia de Indexare atasata Indexului o Tabele de Index dupa Modul de Tratare al Omonimelor (Tuple având aceeasi Valoare a Expresiei de Indexare) § Indecsi Neunici - participa toate Omonimele § Indecsi Unici - participa doar Prima Tupla întâlnita dintr-o Multime de Omonime o Tabele de Index dupa Modul de Organizare a Tabelei de Baza § Indecsi Neblocati (Neclusterati) – Daca Tabela de Baza nu are atasat nici-un Index Blocat ea va fi organizata pe Înregistrari si Ordinea Fizica a Tuplelor din Tabela de Baza este cea Cronologica, acestea fiind apoi accesate din Tabela de Index prin Referire de Adresa (Varianta obisnuita) § Indecsi Blocati (Clusterati) - Daca Tabela de Baza are atasat un Index Blocat (un singur Index Blocat este admis pentru o Tabela de Baza) Ordinea Fizica a Tuplelor din Tabela de Baza este aceeasi cu Ordinea Logica data de
    • Modele de Date / Modelul Relational / Identificare, Acces si Ordonare 241 expresia de Indexare atasata Tabelei de Index; Tuplelor din Tabela de Baza sunt accesate din Tabela de Index prin Referirea Blocului apoi prin inspectie secventiala în cadrul Blocului (Optiune speciala continuta în standardul SQL) Varianta este deosebit de avantajoasa pentru consultarea integrala a Tabelei de Baza dupa o Ordine Preferentiala, dar complica Operatiile de Actualizare prin Gestiunea Blocurilor de Înregistrari La aparitia si impunerea Limbajelor Neprocedurale în domeniul interogarii Bazelor deDate lumea specialistilor s-a grabit sa decreteze apusul Prelucrarii Procedurale. Datorita uneimultimi de factori situatia asteptata nu s-a confirmat. Enumeram dintre acesti factori: - Controlul crescut în gestionarea volumelor mari de date a crescut complexitatea structurilor ce puteau fi prelucrate (Structuri Recursive, Imp lementari de Procese de Abstractizare definite la nivelul Modelelor de Date, Structuri Active, Viziuni Obiectuale etc.) - Limbajele Neprocedurale de Interogare au trebuit supuse unui proces de Standardizare în vederea Unificarii si a Generalizarii lui, ceea ce a limitat posibilele dezvoltari ale versiunilor standardizate succesive, general acceptate - Necesitatea mentinerii unui anumit grad de siguranta si ca urmare de simplitate în formularea si validarea Cererilor In aceste conditii Navigarea în structurile de date a trebuit sa fie mentinuta. Este vorbaînsa de o forma redusa de navigare, care în primul rând a eliminat gestionarea manuala astrategiilor de acces prin controlul Tabelelor de Index. Alegerea Strategiei de Acces, GenerareaTabelelor de Index si utilizarea acestora în procesul de descompunere a Cererilor si de executiea Operatiilor Relationale care este lasata pe seama Optimizatorului de Cereri si a MotoruluiRelational, ambele componente ale SGBD-ului Relational. Dupa cum se cunoaste din descrierea Nivelului Extern al Modelului de Date Relational,orice Cerere reprezinta în Limbajul Neprocedural o descriere de Rezultat sub forma uneiRelatii. Acest Rezultat poate însa sa fie o Valoare Individuala (un Atribut Unic sau o TuplaUnica) sau o Valoare de tip Multime (o Multime de Tuple). Atunci când rezultatul este livratunui Instrument (Tool) care stie sa-l prelucreze indiferent de tipul sau (Individual sau Multime)descrierea, care este privita întotdeauna ca un tot, este suficienta. Exemple sunt oferite deLimbajele Interactive de Interogare, care stiu sa afiseze rezultatul în formatul ales dereprezentare, indiferent de numarul tuplelor continute în rezultat, precum si Instrumentele deConstruire a Rapoartelor. Când însa rezultatele Cererilor sunt furnizate unui Limbaj Gazda(un limbaj care încorporeaza Cererile pe post de Comenzi de Acces la Baza de Date),Rezultatul de tip Multime trebuie inspectat prin Navigare, pentru a se oferi o prelucrarespecifica fiecarui element (Tupla) din multime. Aceasta forma aditionala de prelucrare aRezultatului de tip Multime se poate face în Limbajul Gazda sau în Limbajul Extins de Cereri(exemplu PL/SQL). Limbajul Extins de Cereri contine, pe post de Comanda de Navigarecomanda: FETCH [[ <directia de navigare> ] FROM] <nume cursor> INTO <lista de variabile>unde: - Directia de navigare – este reprezentata de clauzele: o NEXT – urmatoarea tupla
    • 242 Modele de Date / Modelul Relational / Identificare, Acces si Ordonare o PRIOR – precedenta tupla o FIRST – prima tupla o LAST – ultima tupla o ABSOLUTE i – tupla cu Numarul Intern de Identificare i o RELATIVE i – urmatoarea a i – a tupla pornind de la tupla curenta - Nume Cursor – Numele atasat Variabilei Interne care memoreaza Pozitia Tuplei Curente (tupla aflata în curs de prelucrare) si a carui valoare este gestionata automat de sistem în urma interpretarii comenzilor FETCH - Lista de Variabile – Variabilele interne în care vor fi transferate atributele din rezultat Rezultatul de tip Multime destinat unei operatii ulterioare de prelucrare prin Navigarepoarta si denumirea improprie de Cursor, aceasta denumire fiind indusa de Cursorul atasatRezultatului si care gestioneaza Pozitia Tuplei Curente din Rezultat.4.2.4.4.2.3 Chei de Ordonare Cheile de Acces îndeplinesc simultan si functia de Ordonare, datorita procedeului deindexare utilizat (Indexare prin Arbori Binari). O Tabela de Baza poate avea atasate mai multe Criterii de Ordonare si ca urmare maimulte Ordini de Inspectie. Dam o clasificare în cele ce urmeaza: o Ordinea Naturala data de: § Ordinea Cronologica de introducere a Tuplelor în Tabela de Baza, atunci când: • Tabela de Baza este construita ca un Fisier Secvential de Înregistrari • Adaugarea de Tuple se efectueaza printr-o scriere de Înregistrari la sfârsitul Fisierului • Stergerea Fizica se realizeaza prin rescrierea Fisierului § Sortarea Fizica prin Reordonarea Tabelei de Baza cu rescrierea Fisierului § Ordonarea Fizica dupa un Criteriu Logic (vezi Indecsii Blocati), caz în care: • Tabela de Baza este construita ca un Fisier Secvential de Blocuri (Secvente Fizice, înlantuite prin Referinte de Adresa) • Adaugarea de Tuple se efectueaza ca o scriere de Înregistrari la sfârsitul Blocurilor Ordonate printr-un Criteriu de Ordonare • Stergerea Fizica se realizeaza prin reorganizarea (rescrierea) Blocurilor O Tabela de Baza admite a singura Ordine Naturala (Ordine Fizica). Acesta este si motivul pentru care o Tabela de Baza admite un singur Index Blocat. Alegerea Indexului care sa fie Blocat (Clusterat) este o problema delicata întrucât efectul
    • Modele de Date / Modelul Relational / Identificare, Acces si Ordonare 243 poate fi uneori invers (de crestere a duratei totale de prelucrare). Pentru aceasta alegere se fac urmatoarele recomandari: o Cheia Primara a Tabelelor de Baza reprezinta în majoritatea cazurilor o buna alegere, întrucât este solicitata foarte frecvent în procesul de actualizare pe post de Cheie de Acces (inclusiv pentru Cautarea în Vecinatate) o Atributul Nume, prezent în majoritatea Tabelelor, daca îndeplineste si conditia de a fi discriminat (Cheie Candidata) poate reprezenta o alternativa, atunci când principalele Rapoarte Finale folosesc aceasta Ordine de Inspectie o Numele Categoriilor din Tabelele ce descriu Criterii de Clasificare sunt întotdeauna candidate pentru Indecsi Blocati datorita utilizarii lor în cadrul Listelor de Selectie din Interfetele Utilizator o Ordinea Logica data de: § Ordinea Valorilor unui Criteriu de Ordonare în Tabela de Index (asigurata de Structura de Arbore Binar a Tabelei de Index) si care adreseaza în final Înregistrarile din Tabela de Baza prin Referinte de Adresa (vezi sectiunea 3.4.2.2.1.2) Întrucât Ordinea Logica se implementeaza prin Structurile Auxiliare de tip Index, o Tabela de Baza poate admite oricâte Ordini Logice atasate. In acest caz Indecsii sunt grupati într-o Lista de Indecsi, diferentiati prin Numele Indexului (Eticheta Indexului). La un moment dat însa Ordinea Logica a Tabelei de Baza este si ea unica, fiind data de Indexului Principal din Lista de Indecsi, selectat ca Index Curent. Modificarea Indexului Curent are un caracter dinamic, putând fi utilizata chiar între doua Operatii de Prelucrare a Tabelei de Baza. Trebuie retinut faptul ca Indexul, fiind o structura atasata Tabelei de Baza, fiecare actualizare a acesteia determina o actualizare corespunzatoarele a Tabelei de Index. Numarul Indecsilor din Lista de Indecsi determina durata de actualizare a unei Tuple în Tabela de Baza, fiind recomandabila evitarea supraîncarcarii cu Indecsi Activi a Listelor de Indecsi. Întrucât o buna parte din Indecsi sunt utilizati doar în faza finala a prelucrarii, cu ocazia extragerii Rapoartelor Finale (a Suporturilor de Decizie) se recomanda utilizarea urmatoarelor procedee de lucru: • Utilizarea de Indecsi Temporari, Tabele de Index ce se creeaza dupa încheierea fazei de actualizare a Bazei de Date, prin Reindexarea Tabelelor de Baza dupa Criterii de Ordonare ce corespund Ordinii de Inspectie utilizate pentru mai multe Iesiri (Familii de Rapoarte); Tabelele de Index Temporare vor fi apoi abandonate • Resortarea Fizica a Tabelelor de Baza dupa încheierea fazei de actualizare, potrivit unui Criteriu de Ordonare Preferential (daca acesta exista), pentru extragerea datelor în Rapoartele Principale
    • 244 Modele de Date / Modelul Relational / Identificare, Acces si Ordonare4.2.4.5 Manipularea Structurilor Relationale Manipularea Structurilor Relationale se bazeaza pe Expresii (ansambluri de OperatoriRelationali) având atât ca Operanzi, cât si ca Rezultat, chiar Constructorul de Structura –Relatia, ceea ce va permite în orice moment concatenarea Expresiilor Relationale întrucâtorice Rezultat Intermediar poate constitui un nou Operand într-o noua Expresie.Exemple: Sa consideram Structura Relationala BENEFICIARI, PRODUSE, CONTRACTE,descrisa extensional în Fig. 5.1.3.1.2.3.1. Fie urmatoarele întrebari adresate Colectiei de Date: Întrebarea 1 – Codul PRODUSELOR contractate de BENEFICIAUL având codul B2? Raspuns 1: Cod* P2 P3 P4 Tab. 4.2.4.5.1. Produsele Contractate de Beneficiarul cu Codul ’B2’ Întrebarea 2 – Numele si Contul BENEFICIARILOR din Orasul O1? Nume Cont N1 C1 N2 C2 Tab. 4.2.4.5.2 Numele si Contul Beneficiarului din Orasul ’O1’ Întrebarea 3 – Codul PRODUSULUI si Orasul în care trebuie livrate conformCONTRACTULUI? Codp* Oras P1 O1 P3 O1 P3 O1 P2 O2 P3 O2 P4 O2 Tab. 4.2.5.1. Codul Produsului si Orasul în care trebuie livrate
    • Modele de Date / Modelul Relational / Manipularea Datelor 245 Se remarca situatia anticipata si anume faptul ca toate raspunsurile la întrebarile formulateca si Cereri sunt reprezentate de Tabele (de fapt de Clase de Entitati), de Relatii. ModelulRelational ofera doua cai de a descrie noi Relatii care sa reprezinte raspunsurile solicitate. o Precizarea detaliata a Secventei de Operatii din Algebra Relationala, care trebuie executate pentru a obtine Rezultatul o Specificarea Rezultatului prin Formularea unei Definitii a Rezultatului cerut în termenii Calculului Relational, lasând sistemul (SGBD) sa stabileasca secventa de operatii ce trebuiesc executate pentru obtinerea Rezultatului Întrucât definirea Modelului Relational are la baza Teoria Matematica a Multimilor încare definirea Relatiilor este un capitol continut (vezi sectiunea 4.1), este firesc sa se regaseasca oasemanare directa între caile de descriere a Relatiilor Rezultat si modurile de definire aMultimilor în general: o Prin precizarea Operatiilor pe Multimi (Reuniune, Intersectie, Negare, Diferenta etc.) o Prin definirea unui Predicat care sa constituie Însusirea Definitorie a Rezultatului, privit ca o noua Multime Diferenta dintre cele doua cai prezentate anterior este cea între: o Proceduralitate – bazata pe enumerarea succesiva a operatorilor de Algebra Relationala o Neproceduralitate – bazata pe specificarea cu ajutorul Calculului Relational a Rezultatului (întotdeauna o Relatie)4.2.4.5.1 Metoda bazata pe Algebra Relationala Algebra Relationala reprezinta o baza pentru un Limbaj de Manipulare a DatelorRelationale, care se constituie ca un Limbaj de Nivel Înalt. Ea contine o colectie de Operatoriavând drept Operanzi Relatii, si care produc de fiecare data ca Rezultat o noua Relatie. Avândîn vedere ca orice raspuns la o întrebare poate fi reprezentat de o Clasa de Entitati (deci de oRelatie) sarcina Limbajului de Manipulare a Datelor este de a permite, pentru orice întrebareformulata, gasirea unei secvente de Operatori care sa conduca la Rezultatul cautat.4.2.4.5.1.1 Operatori Relationali Doua categorii de Operatori Relationali (vezi Tab. 4.2.4.5.1.1.1) pot fi recunoscuti înAlgebra Relationala, domeniu matematic ce se ocupa cu definirea Expresiilor Relationale: - Operatori Traditionali, provenind din operarea cu Multimi, aici privite ca si Clase de Entitati - Operatori Specific Relationali, provenind din operarea cu Relatii Ambele categorii de Operatori Relationali sunt utilizati în Limbajele RelationaleProcedurale. Operatorii Traditionali de felul Reuniunii (UNION) si Intersectie (INTERSECT)vor fi regasiti însa si în Limbajele Neprocedurale pentru a le extinde puterea de calcul.
    • 246 Modele de Date Traditionali REUNIUNE UNION R1 ∪ R2 pe INTERSECTIE INTERSECT R1 ∩ R2 Multimi DIFERENTA MINUS R1 R2 PRODUS CARTEZIAN TIMES R1 x R2 SELECTIE SELECT σ ls (R1 ) PROIECTIE PROJECT π lp (R1 ) Operatori = (R1 ) ρ (e1 = e2) (R2 ) Relationali Specific < (R1 ) ρ (e1 < e2) (R2 ) Relationali REUNIRE JOIN > (R1 ) ρ (e1 > e2) (R2 ) (CUPLARE) NATURALA (R1 ) ρ (e) (R2 ) POSIBILA (R1 ) ρ p (e) (R2 ) EXTERIOARA (R1 ) ρ x (e) (R2 ) IMPARTIRE DIVIDEBY R1 / R2 Tab. 4.2.4.5.1.1.1 Clasificarea Operatorilor din Algebra Relationala
    • Modele de Date / Modelul Relational / Manipularea Datelor 2474.2.4.5.1.2 Operatori Relationali Traditionali o Operatiile Relationale Tradi tionale – sunt operatii din teoria multimilor aplicate Relatiilor privite ca Multimi de Tuple. Pentru ca doua Relatii sa poata juca rolul de Operanzi în Operatiile Relationale Traditionale, ele trebuie sa îndeplineasca proprietatea de Compatibilitate la Reuniune, definita prin urmatoarele conditii: • Relatiile sa fie definite pe aceleasi domenii • Ordinea Atributelor provenind din Domenii Corespondente sa fie aceeasi • Numele Atributelor provenind din Domenii Corespondente pot sa difere • Relatiile sa respecte restrictia de Integritate de Identificare Spre deosebire de Relatiile de Baza definite de utilizator cu ajutorul Limbajului de Definire a Datelor (LDD), Relatiile care apar ca Rezultate ale aplicarii Operatorilor Relationali din Limbajul de Manipulare a Datelor (LMD), poarta numele de Relatii Derivate. Pentru denumirea Atributelor din Relatiile Derivate se folosesc urmatoarele conventii: • Pentru operatiile Reuniune, Intersectie si Diferenta Numele Atributelor din Rezultat se preiau din primul operand • Pentru operatia Produs Cartezian - Numele Atributelor din Rezultat se preiau din ambii operanzi astfel: o Pentru R1 x R2 numele atributelor în rezultat vor fi calificate astfel: R1 . a1 , R1 . a1 , .. , R1 . am , R2 . am+1 , R2 . am+2 , .. , R2 . am+ n o Pentru R1 x R1 , a doua aparitie a relatiei R1 trebuie înlocuita prin redenumire ( 1 ’ ALIASES R1 ) si se aplica R conventia anterioara pentru numele atributelor § REUNIUNE • Mnemonica în Limbajele Relationale – UNION • Simbol în Expresii Relationale ∪ • Forma generala a operatiei este: ( <nume relatie 1>) ∪ ( <nume relatie 2>) unde ∪ - desemneaza operatorul Reuniune • Defineste o relatie care contine reuniunea multimilor de tuple din doua alte relatii • Proprietatile operatorului sunt:
    • 248 Modele de Date / Modelul Relational / Manipularea Datelor o este un operator binar o este un operator comutativ o rezultatul contine toate Atributele ce refera Domenii Comune o gradul relatiei Rezultat este acelasi cu gradul relatiilor initiale o relatia Rezultat va contine tuple care exista în prima sau a doua Relatie Initiala o tuplele Duplicate vor fi eliminate din Rezultat, folosind Integritatea de Identificare (vezi sectiunea 5.2.4.4.1) o numarul de tuple în Rezultat este mai mic sau egal cu (n + m), unde n este numarul tuplelor în relatia 1 si m este numarul tuplelor în relatia 2 Exemplul 1: Fie o relatiile GRUPA si STUDENT definite intensional ca în Fig. 4.2.4.5.1.1 si extensional ca în Tab. 4.2.4.5.1.1. GRUPA (Cod, Nume, Limba-predare) KEY (Cod) STUDENT (Marca, Nume, Prenume, Sex, Grupa) KEY (Marca) Fig. 4.2.4.5.1.1 Intensiunea relatiilor GRUPA si STUDENT GRUPA COD* NUME Limba-predare C1 N1 L1 C2 N2 L2 C3 N3 L1 C4 N4 L1 C5 N5 L2 C6 N6 L1 STUDENT Marca* Nume Prenume Sex Grupa M1 N1 P1 S1 G1 M2 N2 P2 S2 G2 M3 N3 P3 S2 G2 M4 N4 P1 S1 G3 M5 N5 P3 S2 G4 M6 N6 P1 S1 G1 Tab. 4.2.4.5.1.1 Extensiunea relatiilor GRUPA si STUDENT Sa descriem în expresie de Algebra Relationala raspunsul la întrebarea: Studentii care fac parter din Grupa G1 sau G2? (σ ( Grupa=’G1’ ) (STUDENT)) ∪ (σ (Grupa=’G2’) (STUDENT))
    • Modele de Date / Modelul Relational / Manipularea Datelor 249 Acelasi rezultat poate fi obtinut mai simplu: (σ (Grupa=’G1’ or Grupa=’G2’) (STUDENT)) Exemplul 2: Sa adaugam la structura relationala anterioara si relatia PROFESOR: PROFESOR (Marca, Nume, Prenume, Sex, Titlu) KEY (Marca) Fig. 4.2.4.5.1.2 Intensiunea relatiei PROFESOR PROFESOR Marca* Nume Prenume Sex Titlu M1 N1 P1 S1 T1 M12 N12 P12 S2 T2 M13 N13 P13 S1 T3 Tab. 4.2.4.5.1.1 Extensiunea relatiei PROFESOR Fie întrebarea: Marca, Numele si Prenumele Persoanelor(Studenti sau Profesori)? (π ( Marca,Nume, Prenume) (STUDENT)) ∪ (π (Marca,Nume, Prenume) (PROFESOR)) In acest caz expresia nu poate fi rescrisa. § INTERSECTIE • Mnemonica în Limbajele Relationale – INTERSECT • Simbol în Expresii Relationale ∩ • Forma generala a operatiei este: ( <nume relatie 1>) ∩ ( <nume relatie 2>) unde ∩ - desemneaza operatorul INTERSECTIE • Defineste o relatie care contine intersectia multimilor de tuple din doua alte relatii • Proprietatile operatorului sunt: o este un operator binar o este un operator comutativ o rezultatul contine toate Atributele ce refera Domenii Comune o gradul relatiei Rezultat este acelasi cu gradul relatiilor initiale o relatia Rezultat va contine numai tuplele care exista în ambele Relatii Initiale o tuplele Duplicate vor fi eliminate din Rezultat, folosind Integritatea de Identificare (vezi sectiunea 5.2.4.4.1)
    • 250 Modele de Date / Modelul Relational / Manipularea Datelor o numarul de tuple în Rezultat este mai mic sau egal cu (n + m), unde n este numarul tuplelor în relatia 1 si m este numarul tuplelor în relatia 2 Exemplul 3: Considerând aceleasi structuri relationale sa raspundem la întrebarea: Studentii care fac parter din Grupa G1 si au Sexul S2? (σ ( Grupa=’G1’ ) (STUDENT)) ∩ (σ (Sex=’S2’) (STUDENT)) Acelasi rezultat poate fi obtinut mai simplu: (σ (Grupa=’G1’ and Sex=’S2’) (STUDENT)) Exemplul 4: Fie întrebarea: Marca, Numele si Prenumele Persoanelor care sunt si Studenti si Profesori)? (π (Marca,Nume, Prenume) (STUDENT)) ∩ (π (Marca,Nume, Prenume) (PROFESOR)) In acest caz expresia nu poate fi rescrisa. § DIFERENTA • Mnemonica în Limbajele Relationale – MINUS • Simbol în Expresii Relationale • Forma generala a operatiei este: ( <nume relatie 1>) ( <nume relatie 2>) unde - desemneaza operatorul DIFERENTA • Defineste o relatie care contine diferenta multimilor de tuple din alte doua relatii • Proprietatile operatorului sunt: o este un operator binar o este un operator necomutativ o rezultatul contine toate Atributele ce refera Domenii Comune o gradul relatiei Rezultat este acelasi cu gradul relatiilor initiale o relatia Rezultat va contine numai tuplele care exista în prima Relatie si nu exista în a doua o numarul de tuple în Rezultat este mai mic sau egal cu (n + m), unde n este numarul tuplelor în relatia 1 si m este numarul tuplelor în relatia 2 Exemplul 5: Considerând aceleasi structuri relationale sa raspundem la întrebarea: Studentii care fac parter din Grupa G1 si nu au Sexul S2? (σ ( Grupa=’G1’ ) (STUDENT)) (σ (Sex=’S2’) (STUDENT))
    • Modele de Date / Modelul Relational / Manipularea Datelor 251 Acelasi rezultat poate fi obtinut mai simplu: (σ (Grupa=’G1’ a nd Sex ≠ ’S2’) (STUDENT)) Exemplul 6: Fie întrebarea: Marca, Numele si Prenumele Persoanelor care sunt Studenti si nu sunt Profesori)? (π (Marca,Nume, Prenume) (STUDENT)) (π (Marca,Nume, Prenume) (PROFESOR)) In acest caz expresia nu poate fi rescrisa. § PRODUS CARTEZIAN • Mnemonica în Limbajele Relationale – TIMES • Simbol în Expresii Relationale x • Forma generala a operatiei este: ( <nume relatie 1>) x ( <nume relatie 2>) unde x - desemneaza operatorul PRODUS CARTEZIAN • Defineste o relatie care contine produsul cartezian al multimilor de tuple din doua alte relatii • Proprietatile operatorului sunt: o este un operator binar o este un operator comutativ o rezultatul contine toate combinatiile de tuple din cele doua relatii (poate fi asimilata cu o operatie de Reunire cu Conditia de Reunire valabila pentru toate combinatiile de tuple) Întrucât operatia de Produs Cartezian este utilizata doar în cadrul operatiilor de Reunire (Cuplare), exemple vor fi date la prezentarea acelor operatori, specific relationali.4.2.4.5.1.3 Operatori Specific Relationali o Operatiile Specific Relationale – sunt operatii ce transforma Relatiile Initiale în noi Relatii prin doua procedee fundamentale (vezi si sectiunea 4.1.2): • Regrupare – prin Selectie Orizontala (PROJECT) si Verticala (SELECT) • Combinare – prin Cuplare (Reunire) de Tabele (JOIN) § SELECTIE • Mnemonica în Limbajele Relationale – SELECT • Simbol în Expresii Relationale σ
    • 252 Modele de Date / Modelul Relational / Manipularea Datelor • Forma generala a operatiei este: σ < condi tie de selectie > ( <nume de relatie>) unde σ - desemneaza operatorul SELECTIE < conditie de selectie > - este o expresie Booleana • Defineste o submultime de tuple ale unei relatii care satisfac o Conditie de Selectie • Proprietatile operatorului sunt: o este un operator unar o Conditia de Selectie e construita numai cu Valori de Atribute apartinând unei singure Tuple o gradul relatiei Rezultat este acelasi cu gradul relatiei initiale o numarul de tuple în Rezultat este mai mic sau egal cu numarul tuplelor din relatia initiala Exemplul 7: Considerând aceleasi structuri relationale sa raspundem la întrebarea: Studentii care au Sexul S2? σ ( Sex=’S2’ ) (STUDENT) § PROIECTIE • Mnemonica în Limbajele Relationale – PROJECT • Simbol în Expresii Relationale π • Forma generala a operatiei este: π < lista de attribute de proiectie > ( < nume de relatie >) unde π - desemneaza operatorul PROIECTIE < lista de attribute de proiectie > - este Lista Atributelor de Definitie pentru relatia Rezultat • Defineste o noua relatie având ca Lista de Atribute de Definitie o submultime de atribute (Lista de Atribute de Proiectie) din Lista de Atribute de Definitie ale relatiei initiale • Proprietatile operatorului sunt: o este un operator unar o tuplele Duplicate vor fi eliminate din Rezultat, pastrând Integritatea de Identificare (vezi sectiunea 4.2.4.4.1) în Relatia Rezultat o Lista de Atribute de Proiectie e continuta în Lista Atributelor de Definitie ale relatiei initiale o gradul relatiei Rezultat este egala cu numarul atributelor cuprinse în Lista de Atribute de Proiectie
    • Modele de Date / Modelul Relational / Manipularea Datelor 253 o numarul de tuple în Rezultat este mai mic sau egal cu numarul tuplelor din relatia initiala Exemplul 8: Considerând aceleasi structuri relationale sa raspundem la întrebarea: Marca Numele si Prenumele Studentilor? π (Marca,Nume, Prenume) (STUDENT) § REUNIRE (CUPLARE) • Mnemonica în Limbajele Relationale – JOIN • Simbol în Expresii Relationale ρ • Forma generala a operatiei este: (<nume relatie 1>) ρ < conditie de reunire > (<nume relatie 2>) unde ρ - desemneaza operatorul REUNIRE < conditie de reunire > - este o conditie cu atribute din cele doua relatii initiale • Defineste o combinatie de tuple corespondente din doua Relatii care vor fi reunite într-o singura tupla în Relatia Rezultat, pe baza unei Conditii de Reunire (Cuplare) • Proprietatile operatorului sunt: o este un operator unar o este un operator comutativ o Rezultatul contine numai Valori de Atribute din Tuplele care satisfac Conditia de Reunire o tuplele Duplicate vor fi eliminate din Rezultat, pastrând Integritatea de Identificare (vezi sectiunea 5.2.4.4.1) în Rezultat o tuplele cu Valori Nule pentru Atributele din Conditia de Reunire vor lipsi din Rezultat o gradul relatiei Rezultat este egala cu (n + m), unde n este numarul tuplelor în relatia 1 si m este numarul tuplelor în relatia 2 o numarul de tuple în Rezultat este mai mic sau egal cu numarul tuplelor din Produsul Cartezian al relatiilor initiale Exemplul 9: Considerând aceleasi structuri relationale sa raspundem la întrebarea: Atributele Studentilor împreuna cu Atributele Grupei din care fac parte? (STUDENT) σ ( STUDENT. grupa = GRUPA . cod) (GRUPA) Exista o mare varietate de operatori de Reunire. Lista acestora împreuna cu o scurta descriere e redata în Tab. 4.2.4.5.1.3.
    • 254 Modele de DateVarianta de SubvariantaOperator de de Mnemonica Descriere Reunire Operator de Reunire Reunire EQUIJOIN Operatorul de Comparatie din Conditia de Reunire este = EGALA Reunire LESSJOIN Operatorul de Comparatie din Conditia de Reunire este < MAI MICA Reunire GREATHERJOIN Operatorul de Comparatie din Conditia de Reunire este >MAI MARE Reunire NATURAL JOIN Conditia de Reunire contine doar Atribute Omonime din relatiile initialeNATURALA (membrul drept al conditiei poate fi omis) STANGA LEFT OUTER Rezultatul contine toate tuplele din relatia din Stânga (cu valori NULE JOIN în locul atributelor din tuplele corespondente care lipsesc la Dreapta) Reunire DREAPTA RIGHT OUTER Rezultatul contine toate tuplele din relatia din Dreapta (cu valori NULEEXTERNA JOIN în locul atributelor din tuplele corespondente care lipsesc la Stânga) COMPLETA FULL OUTER Rezultatul contine toate tuplele din ambele relatii (cu valori NULE în JOIN locul atributelor din tuplele corespondente care lipsesc – la Stânga sau la Dreapta) Reunire POSSIBLE JOIN Conditia de Reunire e adevarata doar pentru Valori Nedefinite dePOSIBILA Atribute Tab. 4.2.4.5.1.3 Variantele de Operatori de Reunire
    • Modele de Date / Modelul Relational / Manipularea Datelor 255 § IMPARTIRE • Mnemonica în Limbajele Relationale – DIVIDEBY • Simbol în Expresii Relationale / • Forma generala a operatiei este: R = (R1 / R2 ) unde: o R – Rezultat o R1 – Deîmpartit o R2 – Impartitor • Definitie 1: Daca: R1 ({am+n}) si R2 ({an}) sunt Relatii Initiale definite pe Listele de Atribute {am+n} si {an}, cu {an} ⊂ {am+n}, astfel încât {am+n} {an} = {am } ≠ ∅ , atunci: operatorul IMPARTIRE construieste o relatie R ({am }), definita pe Lista de Atribute {am } si având extensia reprezentata de o multime de tuple {vmi }, care verifica proprietatea: {vni } ∈ R ⇔ {vmj} ∈ R2 si {v(n+m)i, vmj} ∈ R1 , pentru ∀ j ∈ {(m+1) .. (m+n)} Definitie 2: Definirea operatiei se face de asta data cu ajutorul operatorilor deja cunoscuti: Fie doua relatii initiale: R1 (la1 ) si R2 (la2 ), unde la1 si la2 sunt Liste de Atribute, cu la = la1 la2 . Atunci: R 1 / R 2 = RI1 RI 2 unde: RI1 = π <la> (R1 ) T2 = π <la> (R2 x RI1 ) R1 ) Definitie 3: Pentru fiecare tupla din Rezultat, Valorile Atributelor trebuie sa apara în prima Relatie Initiala cu toate Valorile Atributelor din cea de a doua Relatie Initiala.
    • 256 Modele de Date / Modelul Relational / Manipularea DatelorExemplul 10: Fie Structura Relationala descrisa extensional în Fig. 4.2.4.5.1.4.1: CERERE Beneficiar* Produs* B1 P1 B1 P2 B1 P3 B1 P4 B1 P5 B2 P1 B2 P2 B3 P2 B4 P5 STOC Produs* P1 P2 Fig. 4.2.4.5.1.4.1 Structura CERERE - STOC Sa consideram Întrebarea: Care sunt Beneficiarii cu cerere maxima de Produse care pot fi satisfacuti? Raspuns: o In expresie de Algebra Relationala: REZULTAT = CERERE / STOC o In exprimare extensionala Rezultatul e reprezentat în Fig. 4.2.4.5.1.4.2: REZULTAT Beneficiar* B1 B2 Fig. 4.2.4.5.1.4.2 Rezultatul Beneficiarii care au cerut toate Produsele din STOC • Proprietatile operatorului sunt: o este un operator binar o este un operator necomutativ o Lista de Atribute reprezinta DIFERENTA dintre Listele de Atribute ale Relatiilor Initiale o gradul r elatiei Rezultat este egal cu diferenta gradelor Relatiilor Initiale o numarul de tuple în Rezultat este mai mic sau egal cu numarul tuplelor din proiectia primei Relatii Initiale pe Atributele Necomune
    • Modele de Date / Modelul Relational / Manipularea Datelor 2574.2.4.5.1.4 Set Complet de Operatori Relationali Un Set Complet de Operatori Relationali este reprezentat de orice Submultime deOperatori Relationali care au proprietatea ca oricare Operator Relational necuprins în Setpoate fi exprimat ca o Secventa de Operatori cuprinsi în Set. Exista mai multe asemeneaSeturi. Un exemplu reprezentativ de Set Complet de Operatori Relationali este submultimea deOperatori Relationali din Fig. 4.2.4.5.1.4.1:. - SELECTIE σ - PROIECTIE π - REUNIRE ρ - DIFERENTA - - PRODUS CARTEZIAN x Fig. 4.2.4.5.1.4.1 Set Complet de Operatori Relationali Cu ajutorul operatorilor din Setul anterior pot fi exprimati toti ceilalti operatori. Se daumai jos doua asemenea exemple: Exemplul 1: Operatorul de INTERS