Baze de date Fundamente

O carte a comunitii pentru comunitate

Neeraj Sharma, Liviu Perniu, Raul F. Chong, Abhishek Iyer, Adi-Cristina Mitea, Chaitali Nandan, Mallarswami Nonvinkere, Mirela Danubianu Ediie tradus n limba romn de ctre conf. dr. ing. Liviu Perniu

Prima ediie

Baze de date - Fundamente

Prima ediie (November 2010) Copyright IBM Corporation 2010. All rights reserved.
IBM Canada 8200 Warden Avenue Markham, ON L6G 1C7 Canada

Aceast ediie face referire la produsul software IBM DB2 Express-C Version 9.7 for Linux, UNIX and Windows.

Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A.

For license inquiries regarding double-byte character set (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd. 3-2-12, Roppongi, Minato-ku, Tokyo 106-8711
The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. The licensed program described in this document and all licensed material available for it are

Baze de date - Fundamente

provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. The sample programs are provided "AS IS", without warranty of any kind. IBM shall not be liable for any damages arising out of your use of the sample programs. References in this publication to IBM products or services do not imply that IBM intends to make them available in all countries in which IBM operates.

If you are viewing this information softcopy, the photographs and color illustrations may not appear.

Observaii
Aceste informaii se refer la produse i servicii oferite n Statele Unite ale Americii. S-ar putea ca IBM s nu ofere produsele, serviciile sau caracteristicile prezentate n acest document n alte ri. Consultai reprezentana local IBM pentru informaii referitoare la produsele i serviciile disponibile la aceast or n zona dumneavoastr. Prin referire la un produs, program, sau serviciu

5
IBM nu nseamn neaprat faptul c doar acel produs, program sau serviciu poate fi folosit. Se poate folosi orice alt produs funcional echivalent, program sau serviciu care nu ncalc nici unul dintre drepturile de proprietate intelectual IBM. Rmne n responsabilitatea utilizatorului s evalueze i s verifice operarea cu orice alt produs, program sau serviciu ce nu este n proprietatea IBM. IBM poate avea patente sau cereri de patente care s acopere subiectele discutate n cadrul acestui document. Prin furnizarea acestui document nu vi se ofer licene n ceea ce privete patentele. Putei trimite cereri de liceniere, n scris, la adresa: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A.

Pentru cereri de liceniere referitor la setul de caractere pentru reprezentare pe doi bytes (DBCS), contactai departamentul de proprietate intelectual de la IBM (IBM Intellectual Property Department) din ara n care locuii sau trimitei cererile n scris la adresa: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd. 3-2-12, Roppongi, Minato-ku, Tokyo 106-8711
Urmtorul paragraf nu se aplic n Marea Britanie sau n orice alt ar n care aceste cereri contravin legii locale: COMPANIA INTERNATIONAL BUSINESS MACHINES OFER ACEAST PUBLICAIE CA ATARE FR A OFERI NICI UN FEL DE GARANII, NICI IMPLICITE I NICI EXPLICITE, INCLUZND, DAR FR A SE LIMITA LA, GARANIILE IMPLICITE DE NENCLCARE, COMERCIALIZARE SAU UTILIZARE N ALTE SCOPURI. Anumite state nu permit acordarea de garanii nici implicite i nici explicite la efectuarea unor tranzacii, motiv pentru care aceast formulare s-ar putea s nu se aplice n situaia respectiv. Informaiile prezente n acest document s-ar puteas s conin imprecizii tehnice sau erori de dactilografiere. Din acest motiv aceste informaii s-ar putea modifica periodic; astfel de modificri vor apare n ediiile urmtoare ale acestei publicaii. IBM poate aduce mbuntiri i/sau face modificri n cadrul produsului (produselor) i/sau programului (programelor) ce apar n aceast publicaie n orice moment fr a face notificri prelabile. Orice referire fcut n materialul de fa la informaii ce provin de la site-uri non-IBM este introdus doar din motive de conformitate i nu are, sub nici o form, aprobarea acestora. Materialele provenite din cadrul acelor site-uri nu fac parte din materialele acestui produs IBM, iar utilizarea site-urilor respective se va face pe propria rspundere. IBM poate utiliza sau distribui oricare dintre informaiile furnizate aa cum crede de cuvin fr a necesita vreo obligaie din partea dumneavoastr. Programele liceniate prezentate n acest document, precum i toate materialele asociate acestora sunt furnizate de ctre IBM pe baza termenilor din acordul IBM Customer Agreement, IBM International Program License Agreement sau orice alt acord echivalent existent ntre pri.

Baze de date - Fundamente

Toate datele performante prezentate aici au fost determinate ntr-un mediu controlat. De aceea, rezultatele obinute n alte medii de operare s-ar putea s difere n mod semnificativ. Anumite msurtori s-au fcut pe medii de dezvoltare, motiv pentru care este posibil s nu existe nici o garanie a faptului c aceste msurtori vor fi identice pe medii obinuite. Mai mult dect att, anumite msurtori s-au fcut prin extrapolare, iar rezultatele obinute s-ar putea s difere. Utilizatorii acestui document trebuie s-i verifice datele folosite n propriile medii. Informaiile despre produsele non-IBM au fost obinute de la furnizorii acestor produse, anunurile fcute de ctre acetia, sau din alte surse disponibile. IBM nu a testat aceste produse i nu poate confirma acurateea performanelor, compatibilitatea sau alte probleme ale produselor non-IBM. Eventuale ntrebri referitoare la produsele non-IBM trebuie adresate furnizorilor acestora. Toate afirmaiile referitoare la direciile viitoare sau tendinele IBM se pot modifica sau se pot retrage, fr notificare, acestea nereprezentnd altceva dect obiective sau scopuri propuse. O serie de informaii conin exemple de date i rapoarte folosite n activitatea de zi cu zi. Pentru a le prezenta ct mai complet posibil, exemplele conin nume de persoane, companii, branduri i produse. Toate acestea sunt fictive i orice asemnare cu nume sau adrese din realitate este pur ntmpltoare. DREPTUL DE AUTOR: Informaiile prezente n document conin exemple de programe de aplicaii prezentate n limbajul surs, pentru a arta tehnicile de programare folosite pe diverse platforme de operare. Aceste exemple se pot copia, modifica sau distribui sub orice form fr a se percepe nici o tax de ctre IBM, n scopuri de dezvoltare, utilizare, vnzare sau distribuire a programelor de aplicaii n conformitate cu interfaa de programare a aplicaiilor platformei de operare pentru care au fost scrise exemplele respective. Aceste exemple nu au fost testate amnunit n diverse condiii. De aceea, IBM nu poate garanta sau susine fiabilitatea, mentenana sau funcionarea acestor programe. Aceste exemple de programe sunt oferite ca atare, fr a oferi garanii de nici un fel. IBM nu poate fi fcut rspunztoare pentru eventualele pagube aprute n urma folosirii acestor programe. Referirile fcute n aceast publicaie la produse sau servicii IBM nu nseamn automat i faptul c IBM intenioneaz s le promoveze n toate rile n care opereaz.

Dac citii acest document n format electronic este posibil s nu vedei fotografiile sau ilustraiile color.

Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at Copyright and trademark information at www.ibm.com/legal/copytrade.shtml. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries.

Other company, product, or service names may be trademarks or service marks of others.

Mrci
IBM, logo-ul IBM i site-ul ibm.com sunt mrci sau mrci nregistrate de compania International Business Machines Corp., nregistrate n multe jurisdicii din ntreaga lume. Alte nume de produse i servicii pot fi mrci ce aparin IBM sau altor companii. Lista curent a mrcilor IBM o gsii pe Web, sub denumirea Copyright and trademark information la adresa www.ibm.com/legal/copytrade.shtml. Java i toate mrcile bazate pe Java aparin Sun Microsystems, Inc. din Statele Unite ale Americii, din alte ri, sau ambele. Microsoft i Windows sunt mrci ale Microsoft Corporation din Statele Unite ale Americii, din alte ri, sau ambele. Linux este marc nregistrat a Linus Torvalds din Statele Unite ale Americii, din alte ri, sau ambele. UNIX este marc nregistrat a The Open Group din Statele Unite ale Americii, din alte ri, sau ambele.

Alte companii, nume de produse sau servicii pot fi mrci sau servicii ce aparin unor teri.

Cuprins
Prefaa ........................................................................................................................... 15 Cui se adreseaz aceast carte? .............................................................................. 15 Cum este structurat acest carte?........................................................................... 15 O carte pentru comunitate ......................................................................................... 15 Convenii ................................................................................................................... 16 Ce urmeaz?............................................................................................................. 16 Autorii............................................................................................................................ 18 Au contribuit ................................................................................................................. 21 Mulumiri ....................................................................................................................... 23 Capitolul 1 Baze de date i modele de informaie................................................... 25 1.1 Ce este o baz de date?................................................................................. 25 1.2 Ce este un sistem de gestiune al bazelor de date?......................................... 26 1.2.1. Evoluia sistemelor de gestiune a bazelor de date........................................... 26 1.3 Introducere n modelele de informaii i modelele de date................................... 29 1.4 Tipuri de modele de informaii ............................................................................. 30 1.4.1 Modelul reea................................................................................................ 30 1.4.2 Modelul ierarhic ............................................................................................ 31 1.4.3 Modelul relaional ......................................................................................... 32 1.4.4 Modelul entitate-relaie ................................................................................. 33 1.4.5 Modelul relaional-obiectual .......................................................................... 34 1.4.6 Alte modele de date...................................................................................... 34 1.5 Roluri tipice i direcii n carier pentru profesionitii bazelor de date .................. 34 1.5.1 Arhitectul de date.......................................................................................... 34 1.5.2 Arhitectul bazei de date ................................................................................ 35 1.5.3 Administratorul bazei de date (DBA)............................................................. 35 1.5.4 Programatorii de aplicaii .............................................................................. 36 1.6 Rezumat .............................................................................................................. 37 1.7 Exerciii................................................................................................................ 37 1.8 ntrebri recapitulative ......................................................................................... 38 Capitolul 2 Modelul relaional de date ..................................................................... 41 2.1 Modelul relaional de date: Vedere de ansamblu................................................. 41 2.2 Concepte de baz ............................................................................................... 42 2.2.1 Atribute ......................................................................................................... 43 2.2.2 Domenii ........................................................................................................ 43 2.2.3 Tupluri .......................................................................................................... 44 2.2.4 Relaii ........................................................................................................... 44 2.2.5 Scheme ........................................................................................................ 45 2.2.6 Chei .............................................................................................................. 45 2.3 Constrngerile modelului relaional de date......................................................... 48 2.3.1 Integritatea entitii ....................................................................................... 48 2.3.2 Integritatea referenial ................................................................................. 49 2.3.3 Constrngeri de integritate semantic .......................................................... 51 2.4 Algebra relaional............................................................................................... 53

Baze de date - Fundamente

10

2.4.1 Reuniunea .................................................................................................... 53 2.4.2 Intersecia..................................................................................................... 54 2.4.3 Diferena....................................................................................................... 54 2.4.4 Produsul cartezian........................................................................................ 55 2.4.5 Selecia......................................................................................................... 56 2.4.6 Proiecia ....................................................................................................... 57 2.4.7 Jonciunea .................................................................................................... 58 2.4.8 mprirea ..................................................................................................... 60 2.5. Calcul relaional .................................................................................................. 61 2.5.1 Calculul relaional orientat pe tupluri............................................................. 62 2.5.2 Calculul relaional orientat pe domeniu......................................................... 63 2.6 Rezumat .............................................................................................................. 64 2.7 Exerciii................................................................................................................ 64 2.8 ntrebri recapitulative ......................................................................................... 66 Capitolul 3 Modelul conceptual de date .................................................................. 69 3.1 Modelarea conceptual, logic i fizic: vedere de ansamblu ............................. 69 3.2 Ce este un model? .............................................................................................. 71 3.2.1 Model de date............................................................................................... 71 3.2.2 Modelul bazei de date .................................................................................. 71 3.2.3 Conceptele modelului conceptual de date .................................................... 72 3.3 Studiu de caz cu sistemul de management al unei biblioteci - Partea 1 din 3...... 81 3.3.1 Elaborarea modelului conceptual.................................................................. 82 3.4 Rezumat .............................................................................................................. 89 3.5 Exerciii................................................................................................................ 90 3.6 ntrebri recapitulative ......................................................................................... 90 Capitolul 4 Proiectarea bazelor de date relaionale ................................................ 93 4.1 Problema redundanei ......................................................................................... 93 4.1.1 Anomalii de inserare..................................................................................... 94 4.1.2 Anomalii la tergere...................................................................................... 94 4.1.3 Anomalii de actualizare ................................................................................ 95 4.2. Descompuneri .................................................................................................... 95 4.3. Dependene funcionale...................................................................................... 97 4.4 Proprietile dependenelor funcionale ............................................................... 98 4.4.1 Axiomele lui Armstrong................................................................................. 99 4.4.2 Determinarea mulimii de nchidere a atributelor .......................................... 99 4.4.3 Concluzie.....................................................................................................100 4.5 Forme normale ...................................................................................................101 4.5.1 Prima form normal (1FN) .........................................................................101 4.5.2 Forma normal 2 (2FN) ...............................................................................103 4.5.3 Forma normal 3 (3NF) ...............................................................................103 4.5.4 Forma normal Boyce-Codd (FNBC)...........................................................104 4.6 Proprieti ale descompunerii .............................................................................106 4.6.1 Pierderea de informaie prin normalizare i evitarea acesteia......................106 4.6.2 Pstrarea dependenelor la descompunere .................................................107 4.7 Acoperirea minimal ...........................................................................................107

11 4.8 Fuziunea schemelor n forma normal 3 ........................................................... 110 4.9 Descompunerea n forma normal 3 ................................................................. 110 4.10 Forma normal 4 (4FN) ................................................................................... 111 4.10.1 Dependene multivaloare.......................................................................... 111 4.11 Alte forme normale .......................................................................................... 113 4.12 Studiu de caz cu sistemul de management al unei biblioteci - Partea 2 din 3 .. 113 4.13 Rezumat .......................................................................................................... 115 4.14 Exerciii............................................................................................................ 116 4.15 ntrebri recapitulative ..................................................................................... 117 Capitolul 5 Introducere n SQL ............................................................................... 119 5.1 Istoricul SQL...................................................................................................... 119 5.2 Definirea n SQL a schemei bazei de date relaionale ....................................... 120 5.2.1 Tipuri de date ............................................................................................. 120 5.2.2 Crearea unui tabel ...................................................................................... 121 5.2.3 Crearea unei scheme ................................................................................. 125 5.2.4 Crearea unei vederi .................................................................................... 125 5.2.5 Crearea altor obiecte ale bazei de date ...................................................... 126 5.2.6 Modificarea obiectelor bazei de date .......................................................... 126 5.2.7 Redenumirea obiectelor unei baze de date ................................................ 126 5.3 Manipularea datelor folosind limbajul SQL ........................................................ 126 5.3.1 Extragerea datelor ...................................................................................... 126 5.3.2 Introducerea datelor ................................................................................... 128 5.3.3 tergerea datelor........................................................................................ 128 5.3.4 Actualizarea datelor.................................................................................... 129 5.4 Jonciuni ale tabelelor........................................................................................ 129 5.4.1 Jonciunea intern ...................................................................................... 129 5.4.2 Jonciuni externe ........................................................................................ 130 5.5 Operaiile de reuniune, intersecie i diferen ................................................... 133 5.5.1 Reuniunea .................................................................................................. 133 5.5.2 Intersecia................................................................................................... 135 5.5.3 Diferena (EXCEPT) ................................................................................... 135 5.6 Operatori relaionali ........................................................................................... 136 5.6.1 Operatori de grupare .................................................................................. 137 5.6.2 Operatori de agregare ................................................................................ 137 5.6.3 Clauza HAVING.......................................................................................... 137 5.7 Subinterogri ..................................................................................................... 138 5.7.1 Subinterogri ce returneaz o valoare scalar ........................................... 138 5.7.2 Subinterogri care returneaz mai multe valori .......................................... 138 5.7.3 Subinterogri corelate ................................................................................ 139 5.7.4 Subinterogri n clauzele FROM................................................................. 139 5.8 Corespondena dintre conceptele folosite la programarea orientat pe obiecte i cele folosite la bazele de date relaionale ................................................................ 139 5.10 Studiu de caz cu sistemul de management al unei biblioteci - Partea 3 din 3 .. 140 5.9 Rezumat ............................................................................................................ 145 5.10 Exerciii............................................................................................................ 145

Baze de date - Fundamente

12

5.11 ntrebri recapitulative ......................................................................................145 Capitolul 6 Proceduri stocate i funcii ..................................................................149 6.1 IBM Data Studio .................................................................................................149 6.1.1 Crearea unui proiect ....................................................................................150 6.2 Lucrul cu proceduri stocate.................................................................................152 6.2.1 Tipuri de proceduri.......................................................................................152 6.2.2 Crearea unei proceduri stocate ...................................................................154 6.2.3 Modificarea i eliminarea unei proceduri stocate .........................................157 6.3 Operarea cu funcii .............................................................................................157 6.3.1 Tipuri de funcii ............................................................................................157 6.3.2 Crearea unei funcii .....................................................................................159 6.3.3 Apelarea unei funcii ....................................................................................160 6.3.4 Modificarea i eliminarea unei funcii ...........................................................161 6.4 Rezumat .............................................................................................................161 6.5 Exerciii...............................................................................................................161 6.6 ntrebri recapitulative ........................................................................................162 Capitolul 7 Folosirea SQL n aplicaii......................................................................165 7.1 Folosirea SQL n aplicaii: vedere de ansamblu..................................................165 7.2 Ce este o tranzacie?..........................................................................................166 7.3 SQL ncorporat ...................................................................................................167 7.3.1 Comenzi SQL statice...................................................................................167 7.3.2 Comenzi SQL dinamice ...............................................................................173 7.3.3 Comenzi SQL statice sau dinamice? ...........................................................176 7.4 Interfeele de programare a aplicaiilor pentru bazele de date ............................177 7.4.1 ODBC i driverul IBM Data Server CLI ........................................................177 7.4.2 JDBC...........................................................................................................179 7.5 pureQuery ..........................................................................................................180 7.5.1 IBM pureQuery Client Optimizer ..................................................................183 7.6 Rezumat .............................................................................................................183 7.7 Exerciii...............................................................................................................184 7.8 ntrebri recapitulative ........................................................................................184 Capitolul 8 Limbaje de interogare pentru XML.......................................................187 8.1 Vedere de ansamblu asupra tehnologiei XML ....................................................187 8.1.1 Elementele XML i obiectele bazei de date .................................................187 8.1.2 Atributele XML.............................................................................................189 8.1.3 Nume de domeniu .......................................................................................190 8.1.4 Document Type Definition ...........................................................................191 8.1.5 Schema XML...............................................................................................192 8.2 XML Schema......................................................................................................193 8.2.1 Tipuri simple ................................................................................................193 8.2.2 Tipuri complexe ...........................................................................................195 8.2.3 Constrngeri de integritate ..........................................................................196 8.2.4 Evoluia schemelor XML ..............................................................................197 8.3 XPath .................................................................................................................198 8.3.1 Modelul de date XPath ................................................................................198

13 8.3.2 Noduri de tip document .............................................................................. 199 8.3.3 Expresii de cale .......................................................................................... 200 8.3.4 Parcurgere avansat n XPath.................................................................... 200 8.3.5 Semantica XPath........................................................................................ 200 8.3.6 Interogri XPath.......................................................................................... 202 8.4 XQuery .............................................................................................................. 203 8.4.1 Fundamentele limbajului XQuery................................................................ 204 8.4.2 Expresii FLWOR......................................................................................... 205 8.4.3 Jonciuni n XQuery .................................................................................... 206 8.4.4 Funcii definite de utilizator ......................................................................... 206 8.4.5 XQuery i XML Schema ............................................................................. 207 8.4.6 Gruparea i agregarea ............................................................................... 207 8.4.7 Cuantificarea .............................................................................................. 209 8.5 XSLT ................................................................................................................. 209 8.6 SQL/XML........................................................................................................... 211 8.6.1 Transformarea relaiilor n documente XML................................................ 211 8.6.2 Pstrarea i publicarea documentelor XML ................................................ 212 8.6.3 Funcii SQL/XML ........................................................................................ 212 8.7 Interogarea documentelor XML pstrate n tabele............................................. 216 8.8 Modificarea datelor ............................................................................................ 217 8.8.1 XMLPARSE................................................................................................ 217 8.8.2 XMLSERIALIZE.......................................................................................... 218 8.8.3 Expresia TRANSFORM .............................................................................. 218 8.9 Rezumat ............................................................................................................ 219 8.10 Exerciii............................................................................................................ 220 8.11 ntrebri recapitulative ..................................................................................... 220 Capitolul 9 Securitatea bazelor de date ................................................................. 225 9.1 Securitatea bazelor de date: vedere de ansamblu............................................. 225 9.1.1 Necesitatea asigurrii securitii bazei de date........................................... 227 9.1.2 Controlul accesului ..................................................................................... 229 9.1.3 Studiu de caz referitor la securitatea unei baze de date ............................. 229 9.1.4 Vederi ......................................................................................................... 235 9.1.5 Controlul integritii..................................................................................... 236 9.1.6 Criptarea datelor......................................................................................... 236 9.2 Politici i proceduri de securitate ....................................................................... 237 9.2.1 Controlul personalului ................................................................................. 237 9.2.2 Controlul accesului fizic .............................................................................. 237 9.3 Rezumat ............................................................................................................ 238 9.4 Exerciii.............................................................................................................. 238 9.5 ntrebri recapitulative ....................................................................................... 238 Capitolul 10 Tendine n tehnologie i n bazele de date ...................................... 241 10.1 Ce este Cloud computing? .............................................................................. 241 10.1.1 Caracteristicile unui Cloud ........................................................................ 242 10.1.2 Modele de servicii Cloud computing ......................................................... 243 10.1.3 Furnizorii de servicii Cloud........................................................................ 243

Baze de date - Fundamente

14

10.1.4 Gestionarea securitii pe Cloud................................................................247 10.1.5 Baze de date i Cloud Computing .............................................................247 10.2 Elaborarea de aplicaii mobile...........................................................................249 10.2.1 Elaborarea aplicaiilor pentru un anumit dispozitiv mobil ...........................250 10.2.2 Elaborarea aplicaiilor mobile pentru o anumit platform de aplicaii........250 10.2.3 Platforme pentru dispozitive mobile ...........................................................251 10.2.4 Platforme de dezvoltare a aplicaiilor mobile..............................................252 10.2.5 Valul urmtor de aplicaii mobile ................................................................253 10.2.6 DB2 Everyplace.........................................................................................254 10.3 Prelucrarea datelor cu caracter economic ........................................................254 10.4 db2university.com: Implementarea unei aplicaii n Cloud (studiu de caz) ........254 10.4.1 Moodle - sistem open source de management al cursurilor.......................255 10.4.2 Activarea contului de nregistrare openID ..................................................258 10.4.3 Folosirea Amazon Cloud ...........................................................................259 10.4.4 Utilizarea unui telefon Android pentru a obine notele de la curs ...............260 10.5 Rezumat ...........................................................................................................261 Anexa A Rspunsuri la ntrebrile recapitulative ..................................................263 Anexa B Instalarea i rularea DB2...........................................................................268 B.1 DB2: vedere de ansamblu..................................................................................268 B.2 Pachetele DB2 ...................................................................................................269 B.2.1 Servere DB2 ...............................................................................................269 B.2.2 Clienii si driverele DB2 ...............................................................................270 B.3 Instalarea DB2 ...................................................................................................271 B.3.1 Instalare pe Windows..................................................................................271 B.3.2 Instalare pe Linux........................................................................................272 B.4 Instrumente DB2 ................................................................................................272 B.4.1 Control Center.............................................................................................272 B.4.2 Instrumente n linie de comand .................................................................274 B.5 Mediul DB2 ........................................................................................................277 B.6 Configurarea DB2 ..............................................................................................278 B.7 Conectarea la o baz de date ............................................................................279 B.8 Exemple de programe de baz ..........................................................................280 B.9 Documentaia DB2 .............................................................................................282 Resurse ........................................................................................................................283 Site-uri Web .............................................................................................................283 Cri..........................................................................................................................283 Bibliografie ...............................................................................................................284 Date de contact ........................................................................................................285

Prefaa
Pstrarea actualizat a competenelor reprezint o provocare tot mai mare n lumea de astzi, deoarece pe zi ce trece apar din ce n ce multe tehnologii noi, iar timpul avut la dispoziie pentru a le stpni pe toate este din ce n ce mai scurt. Din acest motiv, seria de cri DB2 on Campus a fost realizat tocmai n scopul reducerii timpului i eforturilor necesare n vederea familiarizrii dumneavoastr cu ct mai multe dintre aceste noi tehnologii. Cartea de fa i propune s sprijine profesionitii nou venii n domeniul bazelor de date astfel nct acetia s neleag conceptele fundamentale ale bazelor de date in contextul amplorii i profunzimii informaiilor.

Cui se adreseaz aceast carte?

Aceast carte se adreseaz entuziatilor din domeniul bazelor de date, programatorilor, administratorilor de baze de date, dar i tuturor celor care au un interes n aceast direcie, cum ar fi studenii sau absolvenii instituiilor de nvmnt superior.

Cum este structurat acest carte?

Cartea este structurat pe capitole i pornete de la conceptele fundamentale ale bazelor de date, dar i a modelelor de informaii care sunt prezentate n capitolul I. n capitolul al IIlea se discut despre modelele relaionale de date, iar capitolele al III-lea i al IV-lea explic modelarea conceptual i proiectarea bazelor de date relaionale. n capitolele al Vlea, al VI-lea i al VII-lea se pune accentul pe limbajul SQL, iar capitolul al VIII-lea abordeaz aspecte referitoare la stocarea i extragerea datelor n format XML folosind limbajele SQL i XQuery. n capitolul al IX-lea se prezint o serie de aspecte legate de securitatea bazelor de date. Cartea se ncheie prin prezentarea altor tehnologii importante i aplicaii relevante care prezint un interes din ce n ce mai mare n industria actual. n cadrul celor mai multe dintre capitole vei avea i o parte de exerciii i ntrebri recapitulative ale cror rspunsuri le putei regsi n anexa A.

O carte pentru comunitate

Aceast carte a aprut avnd la nceput un nucleu de cadre didactice universitare, studeni i profesioniti (inclusiv angajai IBM), dar, pe parcurs, o serie de alte persoane din ntreaga lume i-au adus contribuia la forma final a crii. Versiunea online a acestei cri este gratuit pentru ntreaga comunitate. Pentru cei care doresc s ofere feedback sau s contribuie cu material nou n scopul mbunttirii coninuturilor existente, sau pentru cei care doresc s contribuie la traducerea crii n limba natal se pune la dispoziie un e-mail la adresa [email protected] la care putei trimite un mesaj cu titlul Database fundamentals book feedback.

Baze de date - Fundamente

16

Convenii
Pe parcursul acestei cri se vor folosi o serie de exemple de comenzi, clauze SQL, dar i diverse alte coduri, ceea ce a impus utilizarea unor convenii pentru o mai bun nelegere. Astfel, cuvintele cheie specifice sunt scrise cu litere mari, ngroate. De exemplu: NULL care reprezint o stare necunoscut. Pentru comenzi se folosesc caractere ngroate, scrise cu litere mici. De exemplu: comanda dir care afieaz toate fiierele i subdirectoarele din Windows. Clauzele SQL sunt prezentate cu caractere ngroate, scrise cu litere mari. De exemplu, clauza SELECT care se folosete pentru a regsi datele inserate n cadrul unui tabel. Numele obiectelor folosite n cadrul exemplelor sunt prezentate cu litere ngroate, nclinate. De exemplu, tabelul flights care are cinci coloane. Caracterele nclinate se mai folosesc i n cazul numelor de variabile din sintaxa unei comenzi sau clauze. Dac numele variabilei este alctuit din mai multe cuvinte, se folosete caracterul de subliniere pentru a nlocui spaiile libere. De exemplu, CREATE TABLE nume_tabel

Ce urmeaz?
Pentru a obine mai multe informaii despre subiectele discutate n cadrul acestei cri v recomandm s parcurgei i alte cri din aceast serie, cum ar fi: Getting started with DB2 Express-C Getting started with InfoSphere Data Architect Getting started with data warehousing Getting started with DB2 application development n figura urmtoare este prezentat o list de cri n format electronic din cadrul seriei DB2 on Campus disponibile n mod gratuit la dresa db2university.com

17

Cri din seria DB2 on Campus

Baze de date - Fundamente

18

Autorii
Neeraj Sharma este specialist senior IT la Dynamic Warehousing Center of Competency, IBM India Software Labs. Rolul su principal este proiectarea, configurarea i implementarea depozitelor mari de date n diverse domenii industriale; implementarea de soluii personalizate i execuia de teste de performan la solicitarea clienilor. Are diplom de licen n Electronic i Ingineria Comunicaiilor i diplom de master n Sisteme software. Liviu Perniu este confereniar la Catedra de Automatic a Universitii Transilvania din Braov, Romnia i pred cursuri n domeniul analizei cerinelor i modelrii datelor. Este posesorul unui premiu IBM n 2006 n cadrul programului Faculty Award la seciunea Eclipse Innovation Awards i a titlului IBM Champion conferit n anul 2011. Raul F. Chong este conductorul programului DB2 on Campus pornit la IBM Toronto Laboratory fiind promotor al aspectelor tehnice din cadrul sistemului DB2. Principala responsabilitate pe care o are este creterea comunitii DB2 n ntreaga lume. Raul s-a alturat IBM din anul 1997, deinnd numeroase poziii n cadrul companiei. Din poziia de consultant, Raul a ajutat partenerii IBM s migreze de la alte sisteme de baze de date relaionale la DB2, dar i s rezolve problemele legate de performana bazelor de date i de proiectarea aplicaiilor. Din poziia de consultant tehnic DB2, Raul a ajutat la rezolvarea problemelor DB2 pe platformele OS/390, z/OS, Linux, UNIX i Windows. Raul a participat la numeroase laboratoare de lucru DB2, a publicat numeroase articole i a contribuit la realizarea tutorialelor pentru examenele DB2 Certification. Raul i-a adunat cea mai mare parte a experienei cptate de-a lungul anilor n DB2 n cartea Understanding DB2 - Learning Visually with Examples 2nd Edition (ISBN-10: 0131580183) la care este autorul coordonator. Este, de asemenea, coautor al crii DB2 SQL PL Essential Guide for DB2 UDB on Linux, UNIX, Windows, i5/OS, and z/OS (ISBN 0131477005), fiind coordonatorul proiectului i coautor al multor cri din seria DB2 on Campus. Abhishek Iyer este inginer la Warehousing Center of Competency, IBM India Software Laboratory. Rolul su principal este acela de a furniza soluii viabile i de a executa teste de performan la solicitrile clienilor. Expertiza sa acoper implementri ale volumelor mari de date i n regsiri ale datelor in depozite de date de mari dimensiuni. Are diplom de licen n tiina Calculatoarelor. Adi-Cristina Mitea este confereniar la Catedra de tiina Calculatoarelor, de la Facultatea de inginerie a universitii Lucian Blaga din Sibiu. Pred cursuri n domeniul bazelor de date, a sistemelor distribuite, a algoritmilor paraleli i distribuii, a sistemelor tolerante la defectri i altele. Activitile sale de cercetare fac parte din aceste domenii. Are diplom de licen i doctorat in tiina Calculatoarelor. Chaitali Nandan este inginer software n echipa DB2 Advanced Technical Support a laboratorului IBM India Software Laboratory. Rolul su principal n cadrul acestui colectiv este acela de a oferi primul ajutor i sprijin n producie utilizatorilor de sisteme de baze de date DB2 Enterprise. Este specializat n rezolvarea de probleme critice aprute la

19 sistemele de baze de date DB2 i are diplom de licen n Tehnologia informaiei. Mallarswami Nonvinkere este specialist n tehnologia pureXML la IBMs India Software Laboratory i lucreaz pentru echipa de activare a caracteristicilor DB2 pureXML n India. Lucreaz cu clieni IBM i ISV pentru a-i ajuta s neleag folosirea tehnologiei pureXML i s elaboreze aplicaii de mare performan folosind XML. Mallarswami ofer clienilor recomandri practice, fiind activ implicat n oferirea de soluii legate de tehnologiile DB2. A luat cuvntul la numeroase conferine internaionale, printre care cele de la IDUG Australasia, IDUG India i IMTC i este activ n numeroase forumuri din cadrul developerWorks Mirela Danubianu este ef de lucrri la Universitatea tefan cel Mare din Suceava, Facultatea de Inginerie Electric i tiina Calculatoarelor. Posed o diplom de master n tiina Calculatoarelor obinut la Universitatea din Craiova (1985 Automatizri i Calculatoare) i o alta n Economie la Universitatea tefan cel Mare din Suceava, (2009 Management). De asemenea, deine doctoratul n tiina Calculatoarelor la Universitatea tefan cel Mare din Suceava (2006 Contribuii la dezvoltarea metodelor i tehnicilor de exploatare a datelor i managementul cunotinelor). Cercetrile actuale se ncadreaz n domeniul teoriei i implementrii bazelor de date, data mining, data warehouse, aplicaiilor avansate ale tehnologiei informaiei n economie i sntate. Mirela este coautoare la 7 cri i la peste 25 de articole. A participat la peste 15 conferine i este membru n conferine internaionale cu comitet de program.

Au contribuit
La elaborarea acestei cri, au avut o contribuie semnificativ n scopul editrii, revizuirii, sau oferirii de coninuturi, urmtoarele persoane: Contribuabil Agatha Colangelo Cuneyt Goksu Companie/Universitate ION Designs, Inc Poziie/Ocupaie Modelator de date Contribuie A elaborat cuprinsul crii Recenzie tehnic

VBT Vizyon Bilgi Teknolojileri IBM US

DB2 SME i IBM Gold Consultant Programator

Marcus Graham

Recenzie tehnic i a limbii engleze pentru capitolul 10 Recenzia limbii engleze pentru toat cartea fr capitolele 5 i 7 Recenzie tehnic i controbuii la capitolul 10 Recenzia limbii engleze pentru capitolul 7 Recenzie tehnic

Amna Iqbal

IBM Toronto Lab

Asigurarea calitii Lotus Foundations

Leon Katsnelson

IBM Toronto Lab

Director de program, IBM Data Servers

Jeff (J.Y.) Luo

IBM Toronto Lab

Technical Enablement Specialist

Fraser McArthur

IBM Toronto Lab

Promotor n domeniul Managementul informaiei STG ISV Enablement, Web Services

Danna Nicholson

IBM US

Recenzia limbii engleze pentru ntreaga carte Recenzie tehnic

Rulesh Rebello

IBM India

Advisory Manager - IBM Software Group Client Support Arhitect baze de date

Suresh Sane

DST Systems, Inc

Recenzia diverselor capitole, n special a celor legate de SQL

Baze de date - Fundamente Nadim Sayed IBM Toronto Lab Specialist n proiectarea centrat pe utilizator Recenzia limbii engleze pentru capitolul 1

22

Ramona Truta

University of Toronto

ef de lucrri

A elaborat cuprinsul ntregii cri

Mulumiri
Mulumim urmtoarelor persoane pentru ajutorul acordat la elaborarea materialelor din aceast carte. Natasha Tolub pentru realizarea coperii crii. Susan Visser pentru ajutorul acordat la publicarea crii.

1
Capitolul 1 Baze de date i modele de informaie
Datele reprezint unul dintre cele mai importante atuuri ale oricrei afaceri. Acestea sunt utilizate i colectate practic de oriunde, de la companiile care i propun s identifice abloane ce pot fi aplicate consumatorilor n funcie de utilizarea crilor de credit, pn la ageniile spaiale care urmresc s obin date despre alte planete. Datele, pe msura importanei lor, au nevoie de produse software robuste i sigure, cu un grad ridicat de disponibilitate care s le poat stoca i procesa cu rapiditate. Aceste cerine sunt ndeplinite cu ajutorul unor produse solide i fiabile numite baze de date. Utilizarea produselor software de baze de date este omniprezent, acest lucru fiind obligatoriu pentru a permite accesul zilnic la date al utilizatorilor din ntreaga lume. Prezena acestor baze de date o regsim pretutindeni, de la preluarea banilor drintr-un bancomat pn la accesul securizat la birou cu ajutorul cartelelor magnetice. Capitolul de fa ofer o trecere n revist a elementelor fundamentale ale sistemelor de gestiune a bazelor de date i a modelelor de informaii.

1.1 Ce este o baz de date?

nc de la apariia lor, bazele de date au reprezentat unul dintre domeniile cele mai cercetate n informatic. O baz de date este un depozit de date destinat s sprijine stocarea eficient a datelor, dar i regsirea i ntreinerea acestora. Pentru a rspunde cerinelor diverse care exist n industrie s-au creat n timp mai multe tipuri de baze de date. O baz de date poate fi folosit pentru a stoca fisiere binare, documente, imagini grafice sau video, date relaionale, date multidimensionale, date tranzactionale, date analitice, date geografice, pentru a numi doar cteva dintre tipurile cele mai uzuale. Datele pot fi stocate n diferite formate, cum ar fi: tabelar, ierarhic sau graf. n cazul n care datele sunt stocate n format tabelar, atunci avem de a face cu o baz de date relaional. Atunci cnd datele sunt organizate ntr-o structur arborescenta, avem de a face cu o baz de date ierarhic. Datele stocate sub forma unui graf care reprezint relaiile dintre obiecte alctuiesc o baz de date de tip reea. n aceast carte, ne vom concentra atenia asupra bazelor de date relaionale.

Baze de date - Fundamente

26

1.2 Ce este un sistem de gestiune al bazelor de date?

n timp ce o baz de date reprezint doar un simplu depozit de date, sistemele de gestiune ale bazelor de date, pe scurt SGBD, reprezint un grup de instrumente software cu ajutorul crora se controleaz accesul, se organizeaz, nmagazineaz, gestioneaz, se extrag i se ntrein datele din cadrul unei baze de date. n practic, termenii de baz de date, server de baz de date, sistem de baze de date, server de date i sistem de gestiune al bazelor de date se folosesc de cele mai multe ori n mod alternativ. De ce avem nevoie de un produs software pentru bazele de date? Oare nu s-ar putea pstra datele n simple fiiere text, de exemplu? Rspunsul se afl n felul n care utilizatorii acceseaz datele i rezolv diversele probleme care apar la fiecare situaie n parte. n primul rnd, apare necesitatea de a avea mai muli utilizatori care s insereze, s actualizeze i s tearg datele n cadrul aceluiai fiier de date fr a se incomoda unul pe cellalt. Acest lucru presupune faptul c utilizatorii nu vor putea ntreprinde aciuni n urma crora datele s devin inconsistente i nici nu se vor pierde date n urma efecturii anumitor operaii. De asemenea, este nevoie de o interfa standard folosit la accesul datelor, de instrumente pentru realizarea de copii de rezerv, de restaurare i recuperare a datelor, precum i de o modalitate de a rezolva i alte aspecte, cum ar fi capacitatea de a lucra cu volume mari de date i utilizatori. Produsele software destinate lucrului cu baze de date au fost proiectate tocmai pentru a rezolva toate aceste aspecte. Cele mai mature sisteme de baze de date aflate n producie sunt sistemele relaionale de gestiune a bazelor de date (SGBDR). Sistemele SGBDR reprezint coloana vertebral a celor mai multe aplicaii folosite n industrie, cum ar fi cele din domeniul bancar, transporturi, sntate i altele. Apariia interfeelor ce folosesc Web a fcut s creasc foarte mult volumul i domeniul de utilizare al SGBDR-urilor, care servesc pstrrii datelor aflate n spatele celor mai importante aplicaii de comer electronic.

1.2.1. Evoluia sistemelor de gestiune a bazelor de date

n anii 60, sistemele ierarhice i n reea cum ar fi CODASYL sau IMSTM reprezentau tehnologiile cele mai folosite pentru sistemele bancare, de contabilitate i de prelucrare a comenzilor odat cu introducerea sistemelor de tip mainframe n domeniul comercial. Dei aceste sisteme ofereau o baz solid pentru sistemele incipiente, arhitectura acestora fcea s se amestece manipularea fizic a datelor cu manipularea logic a acestora. Atunci cnd se modifica locaia fizic a datelor dintr-o zon a discului n alta, aplicaiile trebuiau s fie actualizate pentru a face referire la noua locaie. Un articol revoluionar din 1970 scris de ctre E.F. Codd, angajat al IBM San Jose Research Laboratory, a fcut s se schimbe toate acestea. Lucrarea, intitulat Modelul relaional al datelor pentru bnci de date distribuite de mari dimensiuni [1.1] a introdus noiunea de independen a datelor, care separa reprezentarea fizic a acestora de reprezentarea logic folosit n cadrul aplicaiilor. Datele puteau fi mutate dintr-o parte n

Capitolul 1 Baze de date i modele de informaie 27 alta a discului sau pstrate n formate diferite fr a necesita rescrierea aplicaiilor. Programatorii de aplicaii erau acum eliberai de detaliile fizice plictisitoare de manipulare a datelor putndu-se concentra mai mult pe aspectele logice de manipulare a acestora n contextul diverselor aplicaii specifice la care lucrau. Figura 1.1. ilustreaz evoluia sistemelor de gestiune a bazelor de date

Integrare

Date care se autodescriu

Organizare federativ

Date eterogene

Extensibilitate

Extinderea funcionalitii

Distribuire

Scalabilitate, paralelism

Optimizare

Performan ridicat

Independena datelor

Modelul logic de date

Figura 1.1 Evoluia sistemelor de gestiune a bazelor de date Figura de mai sus descrie evoluia sistemelor de gestiune a bazelor de date cu model relaional care asigur independena datelor. Produsul System R de la IBM a fost primul sistem care a implementat ideile lui Codd punnd bazele SQL/DS care va deveni ulterior DB2. Prin intermediul acestuia s-a introdus pentru prima dat limbajul SQL, limbaj destinat lucrului cu date n sistemele relaionale, care a devenit ulterior standard i a deschis porile sistemelor comerciale de gestiune a bazelor de date. Astzi, sistemele relaionale de gestiune a bazelor de date reprezint cele mai utilizate sisteme de gestiune a bazelor de date i sunt furnizate de cteva companii productoare de software. Unul dintre liderii de pia n acest domeniu este IBM cu produsul server de baze de date numit DB2. Printre alte sistemele de gestiune a bazelor de date relaionale putem enumera: Oracle, Microsoft SQL Server, INGRES, PostgreSQL, MySQL, i dBASE. Deoarece bazele de date relaionale au devenit din ce n ce mai populare, a aprut necesitatea de a folosi interogri de nalt performan. Din acest motiv, optimizatorul DB2 este una dintre cele mai sofisticate componente ale produsului. Din punct de vedere al utilizatorului, optimizatorul nu reprezint altceva dect o cutie neagr spre care este transmis orice interogare SQL. Optimizatorul DB2 va calcula apoi care este cea mai rapid modalitate de a regsire a datelor, lund n considerare mai muli factori, cum ar fi viteza procesorului i a discului, cantitatea de date disponibile, localizarea datelor, tipul de date, existena unor indeci, i aa mai departe. Optimizatorul DB2 se bazeaz pe estimarea costurilor.

Baze de date - Fundamente

28

Datorit creterii cantitii de date care sunt colectate i stocate n bazele de date, sistemele de gestiune a bazelor de date trebuiau s permit scalabilitate. De exemplu, DB2 pentru Linux, UNIX i Windows prezint o caracteristic numit Database Partitioning Feature (DPF) ce permite bazelor de date s se extind i pe alte maini folosind o arhitectur special. Fiecare main adugat vine cu propriul procesor (procesoare) i disc (discuri), ceea ce permite o scalabilitate aproape liniar. Fiecare interogare dintr-un astfel de mediu este paralelizat astfel nct fiecare main poate extrage prile de care are nevoie din rezultatul final. Ulterior, n evoluia sistemelor de gestiune a bazelor de date relaionale a aprut conceptul de extensibilitate. Limbajul structurat de interogare (SQL) descoperit de ctre IBM la nceputul anilor 70 a fost constant mbuntit pe parcurs. Chiar dac acest limbaj este unul foarte puternic, utilizatorii sunt totui ncurajai s-i dezvolte propriul cod pe care s-l extind. De exemplu, n DB2 se pot crea funcii definite de ctre utilizator i proceduri stocate care permit extinderea limbajului SQL pe logica specific fiecruia. n continuare, sistemele de gestiune a bazelor de date au nceput s abordeze problema manipulrii diferitelor tipuri de date provenite din surse diverse. La un moment dat, serverul de date DB2 a fost redenumit pentru a include termenul "universal" aa cum apare n "DB2 Universal Database" (DB2 UDB). Dei acest termen a fost abandonat ulterior din motive de simplitate, acest lucru a fost important deoarece s-a evideniat faptul c serverul de date DB2 poate stoca toate tipurile de informaii, inclusiv video, date audio, binare, i aa mai departe. Mai mult dect att, prin conceptul de federalizare, o interogare poate fi folosit n DB2 pentru a accesa datele de la alte produse ale IBM, sau chiar de la produse non-IBM. Urmatorul pas evolutiv ce este pus n eviden la finalul figurii de mai sus este acela de integrare. Astzi multe organizaii au nevoie s fac schimb de informaii, iar Extensible Markup Language (XML) este tehnologia de baz, care este utilizat n acest scop i care folosete un limbaj de autodescriere extensibil. Utilizarea acestuia a marcat o cretere exponenial datorit apariiei Web 2.0, i a arhitecturii orientate spre servicii (SOA). IBM a recunoscut din vreme importana XML i, prin urmare, a dezvoltat o tehnologie numita pureXML, care este disponibil n cadrul serverelor de baze de date DB2. Folosind aceast tehnologie, documentele XML se pot stoca ntr-o baz de date DB2 n format ierarhic (care este formatul nativ XML). n plus, motorul DB2 a fost mbuntit, astfel nct s poat lucra cu XQuery, care este limbajul folosit pentru parcurgerea documentelor XML. Prin folosirea pureXML, DB2 aduce cea mai bun performan n lucrul cu tehnologia XML, oferind n acelai timp securitate, robustee si scalabilitate, obiectiv urmrit nc de la nceputuri la folosirea datelor relaionale. Acum, la momentul scrierii acestei cri, subiectul fierbinte l constituie conceptul de Cloud Computing, iar din acest punct de vedere, DB2 este un produs bine poziionat pentru a face fa noilor provocri de lucru n Cloud. De fapt, exist deja imagini DB2 disponibile pe cloud-ul Amazon EC2, i pe dezvoltarea i testarea mediului inteligent de afaceri de pe IBM Cloud (cunoscut, de asemenea, sub numele de dezvoltare i testare n mediul IBM Cloud). Caracteristica de partiionare a bazei de date existent n DB2 amintit anterior se potrivete perfect ntr-un mediu cloud n care se pot cere la comand noduri standard sau servere ce pot fi adugate unui cluster existent. Rebalansarea datelor este efectuat n

Capitolul 1 Baze de date i modele de informaie 29 mod automat de ctre DB2 n timpul lucrului. Acest aspect poate fi extrem de util pe parcurs, de exemplu, n momentul n care se solicit mai mult putere ce trebuie acordat serverului de baze de date pentru a putea finaliza tranzaciile de la sfritul lunii sau de la sfritul anului.

1.3 Introducere n modelele de informaii i modelele de date

Un model al informaiilor este o reprezentare abstract, formal a entitilor cu ajutorul creia se precizeaz proprietile, relaiile i operaiile ce pot fi efectuate asupra acestora. Entitile care se modeleaz pot proveni din lumea real, cum ar fi dispozitivele existente n cadrul unei reele, sau pot s fie le nsele abstracte, cum ar fi entitile utilizate n cadrul sistemelor de facturare. Scopul principal care se ascunde n spatele acestui concept este acela de a formaliza descrierea domeniului unei probleme fr a avea n vedere constrngerile prin care descrierea respectiv este afectat la momentul transformrii acesteia n cadrul implementrii software. n practic pot exista mai multe corespondene ale unui model al informaiilor. Corespondenele sunt numite modele de date, indiferent dac acestea sunt modele obiect (de exemplu, folosirea un limbaj unificat de modelare - UML), modele entitate-relaie, sau scheme XML. Modelarea este un aspect deosebit de important, deoarece trebuie luate n considerare aspecte ce trebuie avute n vedere n cazul eventualelor modificri ulterioare, fr a afecta n mod semnificativ utilizarea produsului. Modelarea permite compatibilizarea cu modelele anterioare i prevede soluii pentru extensiile viitoare. Modelele de informaii i modelele de date sunt distincte deoarece au scopuri diferite. Scopul principal al unui model al informaiilor este acela de modelare a obiectelor gestionate la nivel conceptual, independent de orice implementare specific sau protocoale folosite la transportul datelor. Nivelul de detaliere al abstractizrii efectuate n cadrul unui model al informaiilor depinde de necesitile de modelare ale proiectanilor. Pentru a face proiectarea de ansamblu ct mai uor de realizat, un model al informaiilor trebuie s ascund toate protocoalele de comunicare i detaliile de implementare. O alt caracteristic important a unui model al informaiilor o reprezint stabilirea relaiilor dintre obiectele avute n vedere. Pe de alt parte, modelele de date sunt realizate la un nivel mult mai concret i conin mai multe detalii. Deoarece sunt destinate programatorilor, conin construcii specifice referitoare la protocoalele folosite. Un model de date reprezint planul unui sistem de baze de date. Figura 1.1 ilustreaz relaia dintre un model al informaiilor i un model de date.

Baze de date - Fundamente

30

Model de informaii

Model conceptual/abstract folosit de proiectani i operatori

Model de date

Model de date

Model de date

Model concret/detaliat folosit de ctre implementatori

Figura 1.1 Legtura dintre modelul de informaii i modelul de date Deoarece modelele conceptuale pot fi implementate n diverse moduri, se pot obine mai multe modele de date dintr-un singur model de informaii.

1.4 Tipuri de modele de informaii

Propunerile de modele de informaii pot fi clasificate n 9 perioade istorice: Reea (CODASYL): n anii 70 Ierarhic (IMS): la sfritul anilor 60 i nceputul anilor 70 Relaional: n anii 70 i nceputul anilor 80 Entitate-relaie: n anii 70 Relaional extins: n anii 80 Semantic: la sfritul anilor 70 i nceputul anilor 80 Orientat pe obiect: la sfritul anilor 80 i nceputul anilor 90 Relaional-obiectual: la sfritul anilor 80 i nceputul anilor 90 Semi-structurat (XML): de la sfritul anilor 90 pn n prezent Seciunile urmtoare se vor referi mai n detaliu la unele dintre aceste modele.

1.4.1 Modelul reea

n 1969 CODASYL (comitetul care se ocup cu limbajele sistemelor de date) a lansat prima specificaie referitoare la modelul reea. Aceasta a fost urmat n 1971 i 1973 de specificaiile referitoare la limbajul de manipulare a datelor de tip nregistrare n timp. Un exemplu de model de date de tip reea este prezentat n Figura 1.2.

Capitolul 1 Baze de date i modele de informaie 31

urmtor anterior direct

urmtor

Printe
direct

anterior

urmtor

Printe

direct urmtor anterior

Copil

urmtor anterior

Copil

Copil

...

Copil

Figura 1.2 Modelul reea Figura arat tipurile nregistrare reprezentate prin dreptunghiuri. Aceste tipuri pot folosi i chei pentru a identifica o nregistrare. O colecie de tipuri de nregistrri i chei alctuiesc o reea CODASYL sau o baz de date CODASYL. Se observ faptul c un copil poate avea mai muli prini i fiecare tip de nregistrare se poate lega de altul folosind pointerii urmtori, anteriori sau direci.

1.4.2 Modelul ierarhic

Modelul ierarhic i organizeaz datele pe baza unei structuri arborescente. Rdcina arborelui este printele, urmat de nodurile copil. Un nod copil nu poate avea mai multe noduri printe, dar un nod printe poate avea mai multe noduri copil. Acest lucru este prezentat n Figura 1.3.

Preedinte

Vicepreedinte Marketing

Vicepreedinte Financiar

Vicepreedinte Vnzri

Director media social

Director Marketing

Director vnzri America

Director vnzri Asia

Figura 1.3 Model ierarhic ntr-un model ierarhic, colecia de cmpuri mpreun cu tipurile de date asociate este denumit tip nregistrare. Fiecare instan a unui tip nregistrare este obligat s se supun descrierii datelor care se afl n definiia acelui tip nregistrare. Unele dintre cmpurile unui tip nregistrare sunt chei. Primul sistem de gestiune al bazelor de date de tip ierarhic a fost IMS (sistem de management al informaiilor) lansat de ctre IBM n 1968. Iniial, a fost construit pentru a servi ca baz de date a programului spaial Apollo care a lansat primul om pe lun. IMS este o baz de date foarte robust care se mai afl nc n funciune la mai multe companii din ntreaga lume.

Baze de date - Fundamente

32

1.4.3 Modelul relaional

Modelul relaional de date este simplu i elegant avnd un suport matematic solid bazat pe teoria mulimilor i calcul predicativ, fiind cel mai folosit model de date pentru bazele de date actuale. Unul dintre punctele de pornire ale cercetrii lui Codd a fost acela c programatorii care foloseau sistemul IMS pierdeau o mare parte din timp pentru mentenena aplicaiilor IMS n care apreau modificri logice sau fizice. Din acest motiv, scopul a fost acela de a introduce un model care s permit o mai bun independen a datelor. Propunerea sa a fost: Pstrarea datelor ntr-o structur simpl de date (tabele) Accesarea datelor la un nivel nalt folosind limbajul de manipulare a datelor (DML) Independena datelor din punct de vedere al stocrii fizice Avnd de a face cu o structur de date simpl, exist o ans mai bun de a oferi independena logic a datelor. De asemenea, avnd la dispoziie un limbaj de nivel nalt, se poate oferi o independen mare a datelor din punct de vedere fizic. Din acest motiv, modelul relaional permite independena fa de dispozitivul fizic de stocare a datelor, ceea ce nu era posibil nici cu IMS, nici cu CODASYL. Figura 1.4 arat un exemplu de diagram entitate-relaie care prezint tipurile de entiti (tabelele) mpreun cu relaiile dintre acestea n cadrul unui exemplu de model relaional de date. n seciunea urmtoare se va discuta mai n detaliu despre diagramele entitate-relaie.

Figura 1.4 Diagrama entitate-relaie ce prezint un model relaional de date

Capitolul 1 Baze de date i modele de informaie 33

1.4.4 Modelul entitate-relaie

La mijlocul anilor 70, Peter Chen a propus modelul de date entitate-relaie (E-R). Acesta a reprezentat atunci o alternativ la modelele relaionale, CODASYL i ierarhice de date. El a propus un mod de gndire asupra bazelor de date sub forma unei colecii de instane de entiti. Entitile sunt obiecte care au o existen independent de existena oricrei alte entiti dintr-o baz de date. Entitile au atribute, ce reprezint elementele de date ce caracterizeaz entitatea respectiv. Unul sau mai multe dintre aceste atribute pot fi desemnate ca fiind chei. ntre entiti pot exista relaii, care pot fi 1-la-1, 1-la-muli, muli-la1, sau muli-la-muli, n funcie de modul de participare a acestora la relaie. Relaiile pot avea la rndul lor atribute care descriu relaia repectiv. Figura 1.5 ofer un exemplu de diagram E-R.

Figura 1.5 - Diagrama E-R pentru un model de date n figur, tipurile de entiti sunt reprezentate sub forma unor dreptunghiuri i sunt denumite name, address, voice, fax i modem. n interiorul fiecrui tip de entitate sunt afiate atributele corespunztoare. De exemplu, tipul de entitate voice are atributele vce_num, rec_num i vce-type. PK reprezint cheia primar, iar FK reprezint cheia extern. Conceptul de cheie va fi discutat mai n detaliu ntr-o alt seciune a acestei cri. Modelul E-R a avut mare succes fiind folosit ca instrument de proiectare al bazelor de date relaionale. Articolul lui Chen ofer o metodologie de creare a unei diagrame iniiale E-R, prin intermediul creia se pune la dispoziie un proces simplu de convertire a unei diagrame E-R ntr-o colecie de tabele aflate n forma normal 3. Despre forma normal 3 i teoria normalizrii aflai mai multe ntr-o alt seciune a acestei cri. Astzi, crearea de diagrame E-R este facilitat prin intermediul unor instrumente de modelare a datelor, cum ar fi IBM InfoSphere Data Architect. Pentru a afla mai multe

Baze de date - Fundamente

34

despre acest instrument ajuttor citii cartea n format electronic, Getting started with InfoSphere Data Architect, care este parte a seriei de cri din cadrul proiectului DB2 on Campus.

1.4.5 Modelul relaional-obiectual

Modelul obiectual-relaional (OR) este foarte asemntor cu modelul relaional, cu deosebirea c trateaz fiecare entitate sub forma unui obiect (instan a unei clase) i o relaie sub forma unei moteniri. Dintre caracteristicile i avantajele modelului OR amintim: Suport pentru tipuri complexe, definite de utilizator Motenirea obiectelor Obiecte extensibile Bazele de date obiectual-relaionale au capacitatea de a pstra relaiile dintre obiecte sub o form relaional.

1.4.6 Alte modele de date

Ultima decad s-a remarcat prin concentrarea eforturilor n domeniul modelelor de date semi-structurate, semantice i orientate pe obiecte. XML reprezint modalitatea ideal de stocare a datelor semi-structurate. Modelele bazate pe XML i-au ctigat o mare popularitate n industrie datorit Web 2.0 i a arhitecturilor orientate pe servicii (SOA). Modelele de date orientate pe obiecte sunt foarte populare n universiti, dar nu au fost acceptate pe scar larg n industrie; instrumentele existente de realizare a corespondenelor obiectual-relaionale (ORM) permit o integrare perfect ntre aplicaiile orientate pe obiecte i bazele de date relaionale.

1.5 Roluri tipice i direcii n carier pentru profesionitii bazelor de date

La fel ca orice alt domeniu de activitate, i domeniul bazelor de date are cteva roluri i direcii n carier asociate. n continuare se va face o prezentare a acestor roluri.

1.5.1 Arhitectul de date

Arhitectul de date este responsabil de proiectarea unei arhitecturi care s sprijine cerinele existente i viitoare ale unei organizaii n ceea ce privete managementul datelor. Arhitectura trebuie s acopere partea de baze de date, partea de integrare a datelor, precum i modalitatea de obinere a datelor. De obicei, arhitectul de date atinge aceste obiective prin stabilirea unor standarde n cea ce privete datele organizaiei. Arhitectul de date mai este cunoscut i sub denumirea de modelator de date, dei un astfel de rol implic mult mai multe dect simpla creare de modele de date. O parte din deprinderile fundamentale ale unui arhitect de date trebuie s se afle n zona:

Capitolul 1 Baze de date i modele de informaie 35 Modelrii logice a datelor Modelrii fizice a datelor Elaborrii de strategii a datelor precum i a politicilor asociate Alegerii caracteristicilor i sistemelor care s ndeplineasc cerinele informaionale ale unei organizaii

1.5.2 Arhitectul bazei de date

Acest rol este asemntor arhitectului de date, fiind ns mai mult orientat ctre o soluie ce conine o baz de date. Arhitectul bazei de date este responsabil de ndeplinirea urmtoarelor activiti: Achiziionarea i documentarea cerinelor de la utilizatori i de la managementul organizaiei i introducerea acestora n cadrul unei soluii arhitecturale. Partajarea arhitecturii ntre utilizatori i managementul organizaiei Crearea i implementarea bazei de date, precum i elaborarea de standarde i procese pentru dezvoltarea aplicaiilor. Crearea i punerea n aplicare a nelegerilor la nivel de serviciu (SLA) n cadrul organizaiei, n special n ceea ce privete disponibilitatea, realizarea de copii de siguran i restaurare, precum i securitatea. Studierea produselor noi, a compatibilitii versiunilor i a fezabilitii introducerii n mediul real de funcionare, cu asigurarea de recomandri pentru echipele de programatori i de management. nelegerea suportului hardware, a sistemului de operare, a arhitecturii pe baz de componente la mai multe nivele i a interaciunii dintre aceste componente. Pregtirea documentaiei de nivel nalt corespunztoare cerinelor. Revizuirea proiectelor detaliate i a detaliilor de implementare. Esenial pentru un arhitect de baze de date este de a ine pasul cu noile instrumente, produse de baze de date, platforme hardware si sisteme de operare provenite de la diveri productori pe msur ce acestea evolueaz i sunt mbuntite.

1.5.3 Administratorul bazei de date (DBA)

Administratorul bazei de date este rspunztor de mentenena, performanele, integritatea i securitatea acesteia. Mai pot exista cerine suplimentare, cum ar fi planificarea, dezvoltarea i depanarea. Activitatea administratorului bazei de date poate s difere n funcie de tipul organizaiei i de nivelul de responsabilitate asociat postului. Astfel, se poate avea n vedere doar simpla mentenan sau se poate implica administratorul bazei de date n activiti de dezvoltare a bazei de date.

Baze de date - Fundamente Responsabilitile obinuite includ printre altele:

36

Determinarea cerinelor utilizatorilor i monitorizarea securitii i accesului acestora la baza de date; Monitorizarea performanelor i administrarea parametrilor n scopul creterii vitezei de rspuns ctre utilizatori; Realizarea modelului conceptual al bazei de date; Luarea n considerare att a organizrii datelor pe partea de back-end ct i a accesibilitii pe partea de front-end din punctul de vedere al utilizatorilor; Rafinarea modelului logic astfel nct acesta s poat fi uor adaptat unui model specific de date; Rafinarea n continuare a modelului fizic pentru a ndeplini cerinele legate de partea de stocare a sistemului; Instalarea i testarea noilor versiuni de sisteme de gestiune a bazelor de date (SGBD); Asigurarea respectrii standardelor, inclusiv aderarea la regulile de protecie a datelor personale prevzute n legislaia Data Protection Act; Scrierea documentaiei bazei de date, inclusiv standardele datelor, procedurilor i definiiilor ce apar n dicionarul de date (metadatele) Controlul drepturilor de acces i a privilegiilor; Elaborarea, gestionarea i testarea planurilor pentru realizarea copiilor de siguran i a recuperrii datelor; Asigurarea faptului c sunt respectate i folosite corect procedurile de stocare, arhivare, realizarea de copii de siguran i de recuperare a datelor; Capacitatea de planificare; Lucrul mpreun cu managerii proiectului IT, programatorii bazei de date i programatorii de aplicaii Web; Comunicarea permanent cu personalul tehnic, operaional i de realizare a aplicaiilor n scopul asigurrii integritii i securitii bazei de date; Punerea n funciune i instalarea de noi aplicaii Datorit creterii pericolului de furt al datelor, dar i a naturii sensibile a datelor stocate, securitatea i recuperarea acestora sau restaurarea datelor n cazul apariiei unui dezastru au devenit aspecte din ce n ce mai importante.

1.5.4 Programatorii de aplicaii

Programatorii de aplicaii cu baze de date sunt acele persoane care elaboreaz aplicaii ce acceseaz baze de date. Un astfel de programator are nevoie de urmtoarele cunotine:

Capitolul 1 Baze de date i modele de informaie 37 Folosirea de medii de dezvoltare integrate ce folosesc baze de date (IDEs). Folosirea de plug-in-uri pentru IDE-uri. Instrumente de programare ce folosesc SQL. Monitorizarea i pstrarea performanelor bazei de date. Medii pentru servere de aplicaii, punerea n mediul real de funcionare a aplicaiilor, depanarea i monitorizarea performanelor aplicaiilor. Un exemplu de mediu de dezvoltare integrat este IBM Data Studio, un mediu de dezvoltare bazat pe Eclipse care permite programatorilor s lucreze cu obiectele DB2, cum ar fi tabele, vederi, indeci, proceduri stocate, funcii definite de utilizatori i servicii Web. Cu ajutorul acestui mediu se asigur faciliti de depanare, de folosire a limbajelor SQL i XQuery, dar i integrarea cu alte servere de aplicaii cum ar fi WebSphere Application Server. DB2 mai conine i module de integrare cu mediul de dezvoltare Microsoft Visual Studio, punnd la dispoziie o serie de instrumente de lucru cu obiectele DB2 (tabele, vederi, proceduri stocate, funcii definite de ctre utilizatori etc.). n acest fel programatorii .NET nu trebuie s treac alternativ de la instrumentele DB2 la cele din Microsoft Visual Studio. Rolurile i responsabilitile discutate pn acum sunt prezentate n sens foarte larg deoarece organizaiile au propria lor viziune asupra acestora n funcie de contextul activitii lor. Trecerea n revist a acestor roluri s-a fcut cu scopul a oferi o imagine de ansamblu referitoare la diversele aspecte din jurul administrrii bazelor de date, a dezvoltrii de aplicatii si a utilizrii acestora.

1.6 Rezumat
n cadrul acestui capitol s-au discutat cteva dintre conceptele fundamentale referitoare la lucrul cu bazele de date, pornind de la simpla definiie a unei baze de date i ajungnd pn la sistemele de gestiune a bazelor de date. Apoi s-au trecut n revist modelele de date i de informaii cum ar fi, modelele reea, ierarhic i relaional. La sfritul acestui capitol s-au prezentat o serie de roluri asociate domeniului bazelor de date. n capitolele urmtoare se vor prezenta mai detaliat conceptele din domeniul bazelor de date.

1.7 Exerciii
1. nvai mai multe despre bazele de date lucrnd cu DB2 Express-C, versiunea gratuit a serverului de baze de date DB2. Acest produs se poate descrca de la adresa: ibm.com/db2/express 2. nvai mai multe despre mediile integrate de dezvoltarea (IDE) lucrnd cu produsul gratuit IBM Data Studio. Acest produs se poate descrca de asemenea de la adresa ibm.com/db2/express

Baze de date - Fundamente

38

1.8 ntrebri recapitulative

1. Ce este o baz de date? 2. Ce este un sistem de gestiune al bazelor de date? 3. Care este diferena dintre un model al informaiilor i un model de date? 4. Care este principalul avantaj al modelului relaional comparativ cu alte modele? 5. Prezentai dou dintre activitile ce trebuie desfurate de ctre un administrator de baze de date. 6. Care dintre urmtoarele nu este un model al informaiilor: A. modelul pureXML B. modelul relaional C. modelul ierarhic D. modelul reea E. nici unul dintre cele enumerate 7. n evoluia sistemelor de gestiune a bazelor de date, la ce se refer noiunea de optimizare? A. Disponibilitate ridicat B. Securitate C. Performan D. Scalabilitate E. Nici una dintre cele enumerate 8. Care dintre urmtoarele nu este menionat n evoluia sistemelor de gestiune a bazelor de date: A. Distribuirea B. Independena datelor C. Integrarea D. Federalizarea E. Nici una dintre cele enumerate 9. Din punct de vedere al evoluiei sistemelor de gestiune al bazelor de date, n care stadiu s-ar afla pureXML? A. Independena datelor B. Extensibilitate C. Optimizare

Capitolul 1 Baze de date i modele de informaie 39 D. Integrare E. Nici una dintre cele enumerate 10. Prin ce este diferit DB2 atunci cnd opereaz n Cloud? A. Are o extensie spaial B. Are o caracteristic de partiionare a bazei de date C. Are o tehnologie pureXML D. Toate cele enumerate E. Nici una dintre cele enumerate

2
Capitolul 2 Modelul relaional de date
n cadrul acestui capitol se vor lua n considerare aspectele fundamentale ale modelului relaional de date, introducnd conceptele de atribut, tuplu, relaie, domeniu, schem i cheie. Se vor mai prezenta diverse tipuri de constrngeri ale modelului relaional precum i o serie de informaii referitoare la algebra relational i calculul relaional. Capitolul de fa este puternic legat de Capitolul 3, Modelul conceptual de date, n care se va prezenta cum se face trecerea de la modelul conceptual de date la schema relaional a bazei de date i de Capitolul 4, Proiectarea bazelor de date relaionale, n care se prezint aspecte importante referitoare la proiectarea unei baze de date relaionale. Acest capitol este foarte important pentru nelegerea limbajului SQL. n cadrul acestui capitol se vor aborda aspectele: Vedere de ansamblu asupra modelului relaional de date Definiiile atributelor, tuplurilor, relaiilor, domeniilor, schemelor i cheilor Constrngerile modelului relaional Operatorii folosii n algebra relaional Calculul relaional

2.1 Modelul relaional de date: Vedere de ansamblu

Modelele de informaii urmresc s pun complexitatea informaiilor din lumea real ntr-un ablon care s poat fi mai bine folosit pentru nelegere. Modelele de date trebuie s surprind structura i caracteristicile datelor, relaiile dintre date, regulile de validare i constrngerile aplicate datelor, precum i toate transformrile ce trebuie suportate de ctre acestea. Un astfel de model poate fi privit ca un instrument de comunicare dintre proiectanii, programatorii i utilizatorii unei baze de date. Pe piaa de astzi exist mai multe tipuri de modele de date, fiecare avnd propriile caracteristici, dar n cadrul acestui capitol ne vom ndrepta atenia ctre modelul relaional de date care este cel mai folosit la ora actual. Principalele aspecte ale modelului relaional de date sunt prezentate n Figura 2.1.

Baze de date - Fundamente

42

Modele de informaii Modelul de date ierarhic Algebra relaional Modelul de date reea

Modelul relaional de date Concepte Atribut Tuplu Relaie Domeniu Schem Cheie Restricii Integritatea entitii Integritatea referenial Constrngeri semantice

Calcul relaional

Modelul de date obiectualrelaional

Figura 2.1 Modelul relaional de date n cadrul modelelor de informaii: vedere de ansamblu Figura 2.1 prezint principalele aspecte ale modelului relaional de date: Concepte specifice modelului relaional de date: atribute, tupluri, domenii, relaii, scheme, chei. Restriciile (constrngerile) modelului relaional de date: integritatea entitii, integritatea referenial, precum i constrngerile de natur semantic care sunt folosite pentru a impune reguli n cadrul unei baze de date relaionale. Operaii din algebra relaional precum reuniunea, intersecia, diferena, produsul cartezian, selecia, proiecia, jonciunea i mprirea care se folosesc pentru manipularea relaiilor din cadrul modelului relaional de date. Calculul relaional care reprezint o alternativ la algebra relaional n ceea ce privete partea de manipulare a modelului.

2.2 Concepte de baz

Modelul relaional de date folosete termeni formali pentru definirea conceptelor sale. n capitolele urmtoare se va folosi terminologia formal relaional ce conine concepte cum ar fi: atribut, domeniu, tuplu, relaie, schem, cheie candidat, cheie primar i cheie extern. S vedem n continuare definiiile acestor termeni.

Capitolul 2 Modelul relaional de date 43

2.2.1 Atribute
Un atribut este o caracteristic a unei date. Fiecare caracteristic a unei date din lumea real va fi modelat n baza de date sub forma unui atribut. Fiecare atribut trebuie s aibe un nume astfel nct s se poat face referire la acea caracteristic n orice alt moment este necesar, iar numele trebuie s fie ct mai relevant posibil. De exemplu, atributele unei persoane pot fi: Nume, Sex, DataNasterii. Termenii informali folosii pentru definirea unui atribut sunt: coloana n cazul unui tabel, sau cmp n cazul unui fiier. n figura 2.2 se pot observa caracteristicile unei maini: Tip, Producator, Model, AnFabricatie, Culoare, Combustibil. Celelalte elemente care apar n figur vor fi discutate n seciunile urmtoare.

Figura 2.2 Relaia CARS Antetul conine atribute, iar coninutul este alctuit din tupluri

2.2.2 Domenii
Un domeniu este un grup de valori la nivel atomic care sunt toate de acelai tip. O valoare reprezint cea mai mic unitate de date din modelul relaional. De exemplu, BMW, Mercedes, Audi, i VW sunt valori ale atributului Producer. Acele valori care nu mai pot fi descompuse n continuare sunt considerate a fi la nivel atomic. Domeniul atributului Producer este constituit din mulimea numelor de productori de maini. Un atribut are ntotdeauna asociat un domeniu de valori. De exemplu, atributul de mai sus, conine toate valorile posibile pentru numele de productori de maini. Pe acelai domeniu se pot defini 2 sau mai multe atribute. Orice domeniu trebuie s posede un nume, astfel nct s se poat face referire la el i o mrime care este dat de numrul de valori pe care l are domeniul. De exemplu, domeniul atributului Fuel are doar 2 valori (GAS, DIESEL). Un domeniu poate fi vzut ca un depozit de valori, din care sunt extrase valorile care apar n cadrul atributului

Baze de date - Fundamente

44

respectiv. De reinut este faptul c n orice moment pot exista valori ntr-un anumit domeniu care nu sunt folosite de ctre nici unul dintre atributele ce aparin domeniului respectiv. Domeniile au o anumit semnificaie operaional. Dac dou atribute i preiau valorile din cadrul aceluiai domeniu, atunci operatorii de comparare folosii sunt operaionali deoarece compar valori compatibile. n schimb, dac dou atribute i preiau valorile din domenii diferite i se fac operaii de comparare ntre valorile respective, compararea celor dou atribute nu are sens. Domeniile sunt n primul rnd de natur conceptual. n cele mai multe cazuri, acestea nu sunt n mod explicit stocate n baza de date. Domeniile se specific ca parte a definiiei bazei de date dup care fiecare definiie a unui atribut include o referin la domeniul corespunztor, astfel nct sistemul poate s identifice atributele care se pot compara unele cu altele. Un atribut poate avea acelai nume ca i domeniul su corespunztor, dar aceast situaie trebuie evitat, deoarece se poate genera confuzie. Cu toate acestea, este posibil s se includ numele domeniului ca parte final a numelui atributului n scopul de a oferi mai multe informaii n numele atributului

2.2.3 Tupluri
Un tuplu este un grup ordonat de valori care descriu caracteristicile datelor n orice moment. n Figura 2.2 de mai sus, se poate observa un exemplu de tuplu. Un alt termen formal folosit la definirea unui tuplu este n-tuplul. Termenii informali folosii la denumirea tuplurilor sunt rnd n cadrul unui tabel sau nregistrare n cadrul unui fiier ce conine date.

2.2.4 Relaii
Relaia reprezint partea central a modelului relaional de date. n conformitate cu introducerea n sistemele de baze de date [2.1] o relaie pe domeniile D1, D2, , Dn (nu neaprat distincte) este alctuit dintr-un antet i un coninut. Antetul este alctuit dintr-un grup fix de atribute A1, A2, , An, astfel nct fiecare atribut Ai are exact un corespondent n domeniile respective Di (i=1, 2, , n). Coninutul este alctuit dintr-un grup de tupluri variabil n timp, n care fiecrare tuplu conine un numr de perechi atribut-valoare (Ai:vi) (i=1, 2, , n), cte o pereche pentru fiecare atribut Ai din antet. Pentru fiecare pereche atribut-valoare (Ai:vi), vi exist o valoare din domeniul unic Di care este asociat atributului Ai. n Figura 2.2 se poate observa relaia CARS. Antetul acestei relaii are un grup fix de 6 atribute: Type, Producer, Model, FabricationYear, Color, Fuel. Fiecare dintre aceste atribute are un domeniu de valori corespunztor. Coninutul relaiei este alctuit dintr-un numr de tupluri (n figur sunt prezentate 5 tupluri, dar acest numr este variabil), fiecare dintre tupluri fiind alctuit din 6 perechi atribut-valoare, cte unul pentru fiecare dintre cele 6 atribute din antet.

Capitolul 2 Modelul relaional de date 45 Gradul unei relaii reprezint numrul de atribute al relaiei. Relaia din Figura 2.2 are gradul 6. O relaie de gradul I este numit unar, o relaie de gradul II este numit binar, o relaie de gradul III ternar i aa mai departe. O relaie de gradul n este numit n-ar. Cardinalitatea unei relaii reprezint numrul de tupluri din relaia respectiv. Relaia din Figura 2.2 are cardinalitatea egal cu 5. Cardinalitatea unei relaii se modific frecvent, n timp ce gradul relaiei nu se modfic la fel de des. Aa cum se vede n relaia respectiv, coninutul este alctuit dintr-un grup de tupluri al crui numr se modific n timp. La un moment dat, cardinalitatea relaiei poate fi m, n timp ce dup un timp cardinalitatea poate deveni n. Starea n care se afl o relaie la un moment dat este numit instana relaiei, ceea ce nseamn faptul c pe parcursul existenei unei relaii pot exista foarte multe instane ale acesteia. Relaiile pot avea anumite proprieti importante. Aceste proprieti sunt consecine ale definiiei relaiei dat anterior. Cele 4 proprieti sunt: ntr-o relaie nu pot exista tupluri duplicat ntr-o relaie tuplurile nu sunt ordonate (de sus n jos) ntr-o relaie atributele nu sunt ordonate (de la stnga la dreapta) Toate valorile atributelor se afl la nivel atomic Denumirile informale folosite pentru termenul de relaie sunt tabel sau fiier de date.

2.2.5 Scheme
Schema unei baze de date este o descriere formal a tuturor relaiilor existente n baza de date precum i a tuturor asocierilor dintre acestea. n Capitolul 3, Modelarea conceptual a datelor, i n Capitolul 4, Proiectul relaional al unei baze de date, se vor oferi mai multe informaii despre schemele bazelor de date relaionale.

2.2.6 Chei
Modelul relaional de date apeleaz la chei pentru a defini identificatori asociai tuplurilor unei relaii. Cheile sunt utilizate pentru a impune reguli i/sau constrngeri pe datele bazei de date. Aceste constrngeri sunt eseniale pentru pstrarea consistenei i corectitudinii datelor. Sistemele de gestiune a bazelor de date relaionale permit definirea cheilor, iar sistemele de gestiune ale bazelor de date relaionale trebuie s verifice i s pstreze corectitudinea i consistena datelor din baza de date. n continuare se va defini fiecare tip de cheie. 2.2.6.1 Cheie candidat O cheie candidat reprezint un identificator unic al tuplurilor unei relaii. Prin definiie, fiecare relaie are cel puin o cheie candidat (prima proprietate a unei relaii). n practic, cele mai multe dintre relaii au mai multe chei candidat. C. J. Date [2.2] d urmtoarea definiie unei chei candidat:

Baze de date - Fundamente

46

Fie R o relaie ce are atributele A1, A2, , An. Mulimea K=(Ai, Aj, , Ak) a relaiei R se numete cheie candidat a acesteia dac i numai dac satisface urmtoarele dou proprieti independente de timp: Unicitatea La un anumit moment, nu pot exista dou tupluri distincte ale relaiei R care s aibe aceeai valoare att pentru atributele Ai, ct i pentru atributele Aj, , sau pentru atributele Ak. Minimalitatea Nici unul dintre atributele Ai, Aj, , Ak nu pot fi eliminate din K fr a distruge proprietatea de unicitate. Fiecare relaie are cel puin o cheie candidat, deoarece cel puin combinaia tuturor atributelor sale are proprietatea de unicitate (prima proprietate a unei relaii), dar de obicei exist cel puin o alt cheie candidat alctuit din mai puine atribute ale relaiei respective. De exemlu, relaia CARS prezentat anterior n Figura 2.2 are doar o singur cheie candidat K=(Type, Producer, Model, FabricationYear, Color, Fuel) avnd n vedere faptul c putem avea mai multe maini care au aceleai caracteristici n cadrul relaiei. ns, dac vom crea o alt relaie CARS aa cum se vede n Figura 2.3 prin adugarea altor dou atribute SerialNumber (numrul serial al motorului) i IdentificationNumber (numrul de identificare al mainii) vom avea 3 chei candidat n cadrul relaiei.

Figura 2.3 Noua relaie CARS i cheile sale candidat O cheie candidat mai este numit uneori i cheie unic. O cheie unic poate fi definit la nivelul limbajului de definire a datelor (DDL) folosind parametrul UNIQUE la definirea atributului respectiv. Dac o relaie are mai multe chei candidat, cheia aleas s reprezinte relaia este numit cheie primar, iar cheile candidat rmase sunt numite chei alternative.

Capitolul 2 Modelul relaional de date 47 Observaie: Pentru a defini corect o cheie candidat trebuie luate n considerare toate instanele relaiei pentru a nelege semnificaia atributelor astfel nct s se poat stabili dac este posibil apariia de duplicate pe parcursul existenei relaiei.

2.2.6.2 Chei primare O cheie primar este un identificator unic pentru tuplurile din cadrul unei relaii. Aa cum s-a artat anterior, cheia primar este o cheie candidat aleas s reprezinte o relaie din cadrul unei baze de date i s ofere o modalitate de identificare unic a fiecrui tuplu al relaiei. O relaie din cadrul unei baze de date are ntotdeauna o cheie primar. Sistemele relaionale de gestiune a bazelor de date permit specificarea unei chei primare din momentul crerii relaiei (tabelului). Sublimbajul de definire a datelor are o construcie ajuttoare n acest sens, numit PRIMARY KEY. De exemplu, n cazul relaiei CARS din Figura 2.3 cheia primar este cheia candidat IdentificationNumber. Valorile acestui atribut trebuie s posede constrngerile UNIQUE i NOT NULL pentru toate tuplurile tuturor instanelor relaiei. Exist situaii n care caracteristici preluate din lumea real a datelor, modelate pentru relaia respectiv, s nu posede valori unice. De exemplu, prima relaie CARS din Figura 2.2 se afl n aceast situaie. Pentru a rezolva aceast problem va trebui s se formeze cheia primar prin combinaia tuturor atributelor relaiei. O astfel de cheie primar nu este convenabil din motive practice, deoarece ar necesita prea mult spaiu fizic pentru pstrare, iar mentenana asocierilor dintre relaiile bazei de date ar fi prea dificil. n astfel de situaii, soluia adoptat este aceeea de a introduce un alt atribut, cum ar fi ID, care nu are nici o semnificaie n lumea real, dar care va avea valori unice i poate fi folosit drept cheie primar. Acest atribut este de obicei denumit cheie surogat. Uneori, n literatura de specialitate, un astfel de atribut mai poate fi ntlnit i sub denumirea de cheie artificial. Cheile surogat au de obicei valori numerice cu caracter de unicat care cresc sau descresc automat prin aplicarea unui increment (de obicei, cu pasul de 1). 2.2.6.3 Chei externe O cheie extern este un atribut (sau o combinaie de atribute) din cadrul unei relaii R2 ale crei valori trebuie s corespund celor ale cheii primare din relaia R1 (relaiile R1 i R2 nu trebuie s fie neaprat distincte). De notat este faptul c att cheia extern ct i cheia primar corespunztoare trebuie s fie definite pe acelai domeniu de baz. De exemplu, n Figura 2.4 avem o alt relaie numit OWNERS care conine date despre proprietarii mainilor din relaia CARS.

Baze de date - Fundamente

48

Figura 2.4 Relaia OWNERS i cheile sale primar i extern Cheia extern IdentificationNumber din cadrul relaiei OWNERS face referire la cheia primar IdentificationNumber din cadrul relaiei CARS. n acest fel, putem afla persoana creia i aparine maina. Corespondenele dintre cheia primar i cheia extern reprezint asocierile stabilite ntre dou relaii i alctuiesc liantul cu care se pstreaz integritatea bazei de date. Corespondenele dintre cheia primar i cheia extern reprezint asocierile dintre tupluri, ceea ce nseamn un alt fel de a spune acelai lucru. Trebuie precizat totui c nu toate asocierile de acest fel sunt reprezentate prin corespondene de tip cheie primar-cheie extern. Sublimbajul de definire a datelor folosete de obicei o construcie FOREIGN KEY pentru definirea cheilor externe. Pentru fiecare cheie extern trebuie precizat cheia primar i relaia creia i aparine aceasta.

2.3 Constrngerile modelului relaional de date

n cadrul unui model relaional de date, integritatea datelor se poate pstra cu ajutorul regulilor de integritate sau a constrngerilor. Astfel de reguli au caracter general, sunt specificate la nivelul schemei bazei de date i trebuie respectate de ctre fiecare instan a schemei. Dac se dorete obinerea unei definiii corecte a unei baze de date relaionale, trebuie s se declare astfel de restricii [2.2]. Dac un utilizator ncearc s execute o operaie care ncalc restricia respectiv, atunci sistemul trebuie s resping operaia sau n cazuri mai complexe, s efectueze anumite operaii de compensare ntr-o alt parte a bazei de date. n acest fel se obine asigurarea c rezultatul final se afl n continuare ntr-o stare corect. S vedem n continuare care sunt constrngerile modelului relaional de date.

2.3.1 Integritatea entitii

Constrngerea integritatea entitii afirm faptul c nici un atribut care aparine cheii

Capitolul 2 Modelul relaional de date 49 primare a unei relaii nu poate s aibe valori nule. O valoare null reprezint o proprietate inaplicabil sau o informaie necunoscut. Null este un simplu marcator care arat absena unei valori sau existena unei valori nedefinite. Aceast valoare care reprezint un concept, nu poate lua locul nici unei valori reale din cadrul unui anumit domeniu de valori folosit pentru atributul respectv. De exemplu, pentru atributul ce reprezint culoarea unei maini, null nseamn c n acel moment nu se cunoate culoarea mainii respective. Justificarea pentru integritatea entitii este: Relaiile din cadrul unei baze de date corespund entitilor din lumea real i prin definiie entitile din lumea real sunt distincte, avnd un identificator unic de un anumit fel. Cheile primare ndeplinesc funcia de identificare unic n cadrul modelului relaional n acest caz, valoarea de null a unei chei primare se afl n contradicie de termeni deoarece s-ar putea spune c exist anumite entiti care nu au identitate, ceea ce nu se poate ntmpla.

2.3.2 Integritatea referenial

Constrngerea de integritate referenial arat faptul c dac o relaie R2 conine o cheie extern FK corespunztoare cheii primare PK a altei relaii R1, atunci fiecare valoare a FK din R2 trebuie fie s fie egal cu valoarea PK din anumite tupluri ale relaiei R1 fie s fie n ntregime nul (fiecare valoare a unui atribut participant n acea valoare FK trebuie s fie null). R1 i R2 nu trebuie s fie neaprat distincte. Justificarea constrngerii de integritate referenial este: Dac un anumit tuplu t2 ce aparine relaiei R2 se asociaz cu un alt tuplu t1 ce aparine relaiei R1, atunci tuplul t1 trebuie s existe, altfel legtura nu are sens. Din acest motiv, valoarea unei chei externe trebuie s corespund unei valori a cheii primare undeva n cadrul relaiei referite, dac valoarea cheii externe nu este nul. Uneori, din motive practice, este necesar s se accepte pentru cheia extern i valori nule De exemplu, n relaia OWNERS cheia extern este IdentificationNumber. Valoarea acestui atribut trebuie s corespund valorilor aflate n relaia CARS deoarece o persoan trebuie s posede o main existent pentru a deveni proprietar. Dac cheia extern are valoare nul, aceasta nseamn faptul c persoana nu posed nc o main, dar ar putea cumpra una existent. Pentru fiecare cheie extern din baza de date, proiectantul bazei de date trebuie s rspund la trei ntrebri importante: Poate cheia primar s accepte valori nule?

Baze de date - Fundamente

50

De exemplu, este corect s avem un proprietar care s posede o main necunoscut? Trebuie fcut observaia c rspunsul la o astfel de ntrebare depinde de contextul situaiei din lumea real reprezentat n baza de date. Ce ar trebui s se ntmple dac se ncearc eliminarea valorii cheii primare aflat ntr-o asociere cu o cheie extern? De exemplu, ce se ntmpl dac se ncearc s se elimine o main care se afl n proprietatea unei persoane? De obicei exist trei posibiliti: 1. CASCADE se folosete operaia de tergere n cascad pentru a elimina tuplurile corespondente (tuplurile din relaia n care se afl cheia extern). n cazul de fa, dac se elimin o main, se elimin i proprietarul acesteia. 2. RESTRICT - se folosete operaia de tergere cu restricie pentru situaia n care nu exist tupluri corespondente (altfel, nu se accept). n cazul de fa, o main poate fi eliminat din list doar dac nu aparine unei persoane. 3. NULLIFIES cheia extern va lua valoarea nul n toate situaiile de coresponden, iar tuplurile ce conin cheia primar sunt apoi eliminate (desigur, o astfel situaie nu se poate aplica n cazul n care cheia extern nu poate avea valori nule). n cazul de fa, maina poate fi eliminat din list doar dup ce valoarea atributului IdentificationNumber corespunztoare fostului proprietar a fost setat pe null. Ce se ntmpl atunci cnd se dorete actualizarea valorii unei chei primare aflat n relaie cu o cheie extern? De obicei, exist, de asemenea, trei posibiliti 1. CASCADE operaia de actualizare n cascad actualizeaz valoarea cheii externe a tuplurilor corespondente (inclusiv a tuplurilor relaiei n care se afl cheia extern). n cazul de fa, dac numrul de identificare a unei maini se modific, atunci trebuie s se modifice i numrul de identificare a mainii ce aparine unei persoane. 2. RESTRICT operaia de actualizare cu restricie n cazul n care nu exist tupluri corespondente (altfel, nu se accept). n cazul de fa, numrul de identificare a unei maini poate fi actualizat numai dac aceasta nu aparine unei persoane. 3. NULLIFIES cheia extern se seteaz pe null n toate cazurile de coresponden, iar tuplurile ce conin cheia primar sunt actualizate (desigur, acest lucru nu este valabil dac cheia extern nu poate accepta valori nule). n cazul de fa, numrul de identificare a unei maini poate fi actualizat numai dup ce valoarea atributului IdentificationNumber a fostului proprietar a fost setat pe valoarea nul.

Capitolul 2 Modelul relaional de date 51

2.3.3 Constrngeri de integritate semantic

O constrngere de integritate semantic se refer la nelesul real al datelor. De exemplu, valoarea atributului referitor la numrul unei strzi din relaia OWNERS trebuie s fie pozitiv, deoarece aa se ntmpl n lumea real. O constrngere de integritate semantic poate fi vzut sub forma unui predicat folosit pentru pstrarea strii de corectitudine a tuturor instanelor unei relaii din cadrul unei baze de date. Dac utilizatorul ncearc s execute o operaie care nu respect constrngerea, sistemul trebuie fie s resping operaia sau posibil, n anumite situaii complicate, s efectueze aciuni de compensare pe unele obiecte ale bazei de date pentru a obine asigurarea c rezultatele existente se afl ntr-o stare corect. n acest fel, limbajul folosit pentru speicifcarea unei constrngeri de integritate semantic trebuie s conin nu doar posibilitatea de a defini diverse predicate specifice, ci i specificarea aciunilor compensatorii atunci cnd este nevoie. Constrngerile de integritate semantic se introduc, de obicei de ctre administratorul bazei de date i trebuie pstrate n catalogul sistemului sau n dicionarul de date. Sistemul de gestiune al bazei de date monitorizeaz interaciunile utilizatorilor pentru a se asigura de faptul c aceste constrngeri sunt respectate. Sistemele relaionale de gestiune a bazelor de date permit introducerea unor tipuri de constrngeri de integritate semantic cum ar fi constrngerile de domeniu, constrngerile pentru valori nule, constrngeri de unicitate, constrngeri de verificare a unor condiii impuse. 2.3.3.1 Constrngeri de domeniu O constrngere de domeniu implic faptul c un atribut al unei relaii ia valori ntr-un anumit domeniu de valori. O astfel de constrngere verific dac valorile luate de ctre atributul respectiv se ncadreaz n domeniul de valori prestabilit. De exemplu, domeniul de valori al atributului Street din cadrul relaiei OWNERS este de tip CHAR(20), deoarece strzile au de obicei nume, iar domeniul atributului Number este de tip NUMERIC, deoarece numerele strzilor au valori numerice. Exist o serie de forme particulare ale constrngerilor de domeniu, numite constrngeri de format sau constrngeri de interval de valori. O constrngere de format poate fi ceva de tipul unui ablon de valori pentru date. De exemplu, valorile atributului IdentificationNumber trebuie s fie de formatul XX99XXX, n care X reprezint o liter din alfabet, iar 9 reprezint o cifr. O constrngere de interval de valori specific intervalul de valori n care poate lua valori un anumit atribut. De exemplu, valorile atributului FabricationYear se pot afla n intervalul 1950 i 2010. 2.3.3.2 Constrngeri de tip Null O constrngere de tip Null specific faptul c valorile atributului respectiv nu pot fi nule. Pentru fiecare tuplu al unei instane a unei relaii atributul trebuie s aib o valoare care s existe n domeniul din care acesta i ia valorile. De exemplu, valorile atributelor FirstName i LastName nu pot fi nule, ceea ce nseamn c proprietarul unei maini

Baze de date - Fundamente trebuie s posede un nume.

52

O constrngere de tip Null este de obicei specificat folosind construcia NOT NULL care urmeaz dup numele atributului. n afar de NOT NULL, se mai poate folosi opional i cuvntul cheie adiional WITH DEFAULT pentru ca sistemul s introduc o valoare implicit a atributului n cazul n care acesta are valoare nul la introducere. WITH DEFAULT se poate aplica doar valorilor numerice (integer, decimal, float etc.) i de tip dat calendaristic (date, time, timestamp). Pentru alte tipuri de date, valorile implicite trebuie introduse n mod explicit cu ajutorul limbajului de definire a datelor. 2.3.3.3 Constrngere de unicitate O constrngere de unicitate arat faptul c valorile unui atribut trebuie s fie diferite, nefiind posibil ca dou tupluri din cadrul unei relaii s posede aceleai valori pentru aceleai atribute. De exemplu, n relaia CARS valorile atributului SerialNumber trebuie s fie unice deoarece nu este posibil ca s avem dou maini i doar un singur motor. O constrngere de unicitate este de obicei introdus prin intermediul unui nume de atribut urmat de cuvntul UNIQUE. Se observ faptul c NULL este o valoare unic acceptat. Obs: NULL nu face parte din nici un domeniu de valori, motiv pentru care rezultatul unei operaii de comparare SQL este ntotdeauna unknown dei nici una dintre valorile implicate n cadrul operaiei nu este nul. Din acest motiv, pentru a putea gestiona corect valorile nule, SQL introduce dou predicate speciale, IS NULL i IS NOT NULL pentru a verifica dac exist valori nule sau nu. Mai jos este prezentat o tabel de adevr care arat felul n care sunt gestionate de ctre SQL valorile nule ("Unknown"). Platformele sau productorii de baze de date pot avea diverse modaliti de gestionare a valorilor nule.
A True True True False False False Unknown Unknown Unknown B True False Unknown True False Unknown True False Unknown A OR B True True True True False Unknown True Unknown Unknown A AND B True False Unknown False False False Unknown False Unknown A=B True False Unknown False False False Unknown False Unknown A True False Unknown NOT A False True Unknown

2.3.3.4 Constrngeri de verificare O constrngere de verificare introduce o condiie (un predicat) pe datele unei relaii, care

Capitolul 2 Modelul relaional de date 53 verific ntotdeauna datele cu care se lucreaz. Predicatul arat ce trebuie verificat i, opional, ce trebuie fcut dac nu este respectat condiia (rspuns la nclcarea condiiei). Dac se primete un rspuns de nclcare a condiiei, operaia este anulat i se ntoarce un cod de eroare corespunztor. La aplicarea constrngerii, sistemul verific dac starea curent a bazei de date rmne corect i dup impunerea constrngerii. Dac acest lucru nu se ntmpl, constrngerea este respins, altfel este acceptat i impus permanent din acel moment. De exemplu, salariul unui angajat nu poate fi mai mare dect salariul directorului administrativ sau un director de departament nu poate avea mai mult de 20 de persoane subordonate. Pentru relaiile folosite anterior, de exemplu, anul de fabricaie al unei maini nu poate fi mai mare dect anul n care aceasta a intrat n posesia unei persoane. Acest tip de constrngere poate fi introdus uneori n cadrul unei baze de date prin intermediul restriciei CHECK sau a unui declanator. Constrngerea de verificare poate fi testat de ctre sistem nainte sau dup operaii cum ar fi cele de inserare, actualizare sau tergere.

2.4 Algebra relaional

Algebra relaional este aplicat prin intermediul unui grup de operatori folosii la manipularea relaiilor. Fiecare operator al algebrei relaionale se aplic pe una sau dou relaii la intrare producnd o relaie nou la ieire. Codd [2.3] a definit 8 astfel de operatori, cte 2 grupuri a cte 4 fiecare: Operaiile tradiionale pe mulimi: reuniunea, intersecia, diferena i produsul cartezian Operaii relaionale speciale: selecia, proiecia, jonciunea i mprirea.

2.4.1 Reuniunea
Reuniunea a dou relaii compatibile la reuniune R1 i R2, R1 UNION R2, reprezint mulimea tuturor tuplurilor t care aparin att lui R1 ct i lui R2 sau ambelor. Dou relaii sunt compatibile la reuniune dac au acelai grad, iar atributul i al fiecreia aparine aceluiai domeniu de valori. Notaia formal pentru operaia de reuniune este U. Operaia UNION este asociativ i comutativ. Figura 2.5 prezint un exemplu de operaie UNION. Operanzii sunt relaiile R1 i R2 iar rezultatul este o alt relaie R3 care are 5 tupluri.

Baze de date - Fundamente

R1 R2

54

Name A C B

Age 20 21 21

Sex M M F Name Age

Name Age D A E Sex M M F F F 20 20 21

Sex F M F

R3= R1 U R2

A C B D E

20 21 21 20 21

Figura 2.5 Exemplu de operaie UNION dintre dou relaii: R1 i R2

2.4.2 Intersecia
Intersecia dintre dou relaii compatibile la reuniune R1 i R2, R1 INTERSECT R2, reprezint mulimea tuturor tuplurilor t care aparin att lui R1 ct i lui R2. Notaia formal pentru operaia de intersecie este . Operaia INTERSECT este asociativ i comutativ. Figura 2.6 prezint un exemplu de operaie INTERSECT. Operanzii sunt relaiile R1 i R2 iar rezultatul este o alt relaie R3 cu un singur tuplu.

Figura 2.6 Exemplu de operaie INTERSECT dintre dou relaii: R1 i R2

2.4.3 Diferena
Diferena dintre dou relaii compatibile la reuniune R1 i R2, R1 MINUS R2, reprezint mulimea tuturor tuplurilor t care aparin relaiei R1 dar nu i relaiei R2.

Capitolul 2 Modelul relaional de date 55 Notaia formal pentru operaia de diferen este Operaia de DIFEREN nu este asociativ i comutativ. Figura 2.7 prezint un exemplu al operaiei de diferen. Operanzii sunt relaiile R1 i R2 iar rezultatul este o alt relaie R3 care are 2 tupluri. Aa cum se poate observa, rezultatul dintre R1-R2 este diferit fa de R2-R1.

R1

R2

Name A C B

Age 20 21 21

Sex M M F Name Age C 21 B 21 Name Age D 20 E 21

Name Age D A E Sex M F Sex F F 20 20 21

Sex F M F

R3= R1 - R2

R3= R2 R1

Figura 2.7 Exemplu de operaie de diferen dintre 2 relaii: R1 i R2

2.4.4 Produsul cartezian

Produsul cartezian dintre dou relaii R1 i R2, R1 TIMES tuplurilor t n care t reprezint concatenarea unui tuplu r din din relaia R2. Prin concatenarea unui tuplu r = (r1, r2, (sm+1, sm+2, , sm+n) se obine tuplul t = (r1, r2, , rm, R1 i R2 nu trebuie s fie compatibile la reuniune. Notaia formal pentru o operaie de produs cartezian este . Dac R1 are gradul n i cardinalitatea N1 iar relaia R2 are gradul m i cardinalitatea N2 atunci rezult c relaia R3 are gradul (n+m) i cardinalitatea (N1*N2). Acest lucru este prezentat n Figura 2.8. R2, este mulimea tuturor relaia R1 i a unui tuplu s , rm) cu un tuplu s = sm+1, sm+2, , sm+n).

Baze de date - Fundamente

56

Figura 2.8 Exemplu de produs cartezian ntre dou relaii

2.4.5 Selecia
Operaia de selecie alege o submulime de tupluri dintr-o relaie. Este un operator unar care se aplic pe o singur relaie. Submulimea tuplurilor trebuie s satisfac condiia de selecie sau predicatul. Notaia formal pentru operaia de selecie este:

<condiia de selecie> (<relaia>)

n care <condiia de selecie> este <atribut> <operator de comparare> <constanta>/<atribut> [AND/OR/NOT <atribut> <operator de comparare> <constanta>/<atribut>] Operatorul de comparare poate fi <, >, <=, >=, =, <> i depinde de domeniul de valori al atributului sau de tipul de dat al constantei. Gradul relaiei rezultate este egal cu cel al relaiei iniiale pe care se aplic operatorul. Cardinalitatea relaiei rezultate este mai mic sau egal cu cardinalitatea relaiei iniiale. Dac se constat o cardinalitate sczut se spune c selectivitatea condiiei de selecie este ridicat, iar dac cardinalitatea este mare se spune c selectivitatea condiiei de selecie este redus. Operaia de selecie este comutativ n Figura 2.9, sunt dou exemple de operaii de selecie efectuate pe relaia R. Prima condiie de selecie este Age=20 iar rezultatul este relaia R1 iar a doua condiie de selecie este (Sex=M) AND (Age>19) iar rezultatul este relaia R2.

Capitolul 2 Modelul relaional de date 57

R1= (Age=20)(R)

Name A M B F A R C

Age 20 21 20 19 20 21 21

Sex M F F M F F M

Name Age A B A 20 20 20

Sex M F F

R2= (Sex=M AND Age>19)(R)

Name Age A C 20 21

Sex M M

Figura 2.9 Exemplu de operaie de selecie (cu dou condiii diferite de selecie)

2.4.6 Proiecia
Operaia de proiecie produce o alt relaie prin selectarea unei submulimi de atribute dintr-o relaie existent. Tuplurile duplicat din relaia rezultant sunt eliminate. i aici avem de a face cu un operator unar. Notaia formal pentru operaia de proiecie este:

<lista de atribute> (<relatie>)

n care <lista de atribute> reprezint submulimea atributelor unei relaii existente. Gradul relaiei rezultate este egal cu numrul de atribute din <lista de atribute> deoarece doar acele atribute apar n relaia rezultant. Cardinalitatea relaiei rezultante este mai mic sau egal cu cardinalitatea relaiei iniiale. Dac lista de atribute conine o cheie candidat a relaiei, atunci cardinalitatea este egal cu cardinalitatea relaiei iniiale. Dac nu conine o cheie candidat, atunci cardinalitatea poate fi mai mic datorit posibilitii apariiei tuplurilor duplicat, care sunt eliminate din relaia rezultant. Proiecia nu este comutativ. n Figura 2.10 sunt prezentate dou exemple de operaii de proiecie efectuate asupra relaiei R. n prima, proiecia este efectuat pe atributele Name i Sex iar rezultatul este relaia R1 iar n a doua, proiecia este efectuat pe atributele Age i Sex iar rezultatul este relaia R2.

Baze de date - Fundamente

58

R1= (Name, Sex)(R) Name Sex

Name A M B F A

Age 20 21 20 19 20

Sex M F F M F
R2= (Age, Sex)(R)

A M B F A Age 20 21 20 19

M F F M F Sex M F F M

Figure 2.10 Exemplu de operaie de proiecie (dou liste diferite de atribute)

2.4.7 Jonciunea
Operaia de jonciune produce cuplarea a dou relaii pe baza unei condiii de jonciune sau a unui predicat. Relaiile trebuie s posede cel puin un atribut comun pe care se aplic condiia de jonciune care are acelai domeniu de valori n ambele relaii. Notaia formal pentru operaia de jonciune este:

<condiia de jonciune>

n care <condiia de jonciune> este <atribut din R> <operator de comparare> < <atribut din S> Operatorii de comparare pot fi <, >, <=, >=, =, <> i depind de domeniile de valori ale atributelor. Dac relaia R are atributele A1, A2, , An, iar relaia S are atributele B1, B2, , Bm i atributele Ai i Bj au acelai domeniu de valori se poate defini o operaie de jonciune ntre relaia R i relaia S punndu-se o condiie de jonciune ntre atributele Ai i Bj. Rezultatul este o alt relaie T care conine toate tuplurile t astfel nct t reprezint concatenarea unui tuplu r care aparine relaiei R i a unui tuplu s care aparine relaiei S dac condiia de jonciune este adevrat. Acest tip de operaie de jonciune mai este cunoscut i sub denumirea de theta-jonciune. Aceasta corespunde definiiei conform creia rezultatul unei jonciuni trebuie s conin dou atribute identice din punct de vedere al valorilor pe care le au. Dac unul dintre cele dou atribute este eliminat, jonciunea este

Capitolul 2 Modelul relaional de date 59 numit jonciune natural. Mai exist i alte forme de operaii de jonciune. Cea mai des folosit este operaia numit echijonciune, care nseamn c operatorul de comparare este =. Exist situaii n care nu toate tuplurile unei relaii R au un tuplu corespondent n relaia S. Acele tupluri nu vor apare n rezultatul operaiei de jonciune dintre relaiile R i S. n practic, uneori, este necesar s apar toate tuplurile n rezultatul final, astfel nct a fost creat un alt tip de jonciune: jonciunea extern. Exist 3 forme de jonciune extern: jonciunea extern stnga, n care toate tuplurile relaiei R apar n rezultatul final, jonciunea extern dreapta, n care n rezultatul final apar toate tuplurile relaiei S i jonciune extern complet, n care apar n rezultatul final toate tuplurile ce aparin att relaiei R ct i relaiei S. Dac nu exist tuplu corespondent, sistemul va lua n considerare un tuplu ipotetic cu toate valorile atributelor setate pe valoarea nul, iar acesta va fi folosit la concatenare. n Figura 2.11 se pot observa dou relaii R1 i R2 cuplate printr-o condiie de jonciune n care LastName din relaia R1 este egal cu LastName din relaia R2. Relaia rezultant este R3.
R1 R2

First Name A B C

Last Name Mary John Ann

Last Name Ann John Mary Bill Last Name Mary John Ann Last Name Mary John Ann Sex F M F

Sex F M F M

R3=R1(Last Name=Last name) R2

First Name A B C

Figure 2.11 Exemplu de operaie de jonciune n Figura 2.12 se pot vedea rezultatele unei jonciuni naturale dintre R1 i R2 i rezultatul unei jonciuni externe dreapta.

Baze de date - Fundamente

60

Figura 2.12 Exemple de jonciune natural i de jonciune extern dreapta

2.4.8 mprirea
Operatorul de mprire mparte relaia R1 de grad (n+m) la relaia R2 de grad m producnd o relaie de grad n. Atributul (n+i) al relaiei R1 i atributul the i al relaiei R2 trebuie definite pe acelai domeniu. Rezultatul unei mpriri dintre relaia R1 i relaia R2 este o alt relaie care conine toate tuplurile care concatenate cu toate tuplurile relaiei R2 aparin relaiei R1. Notaia formal pentru operaia de mprire este . Figura 2.13 prezint un exemplu de operaie de mprire dintre relaia R1 i relaia R2.
R1

Name A B A C D C
R2

Sex M F F F M M

R3= R1 R2

Name A C

Sex M F

Figura 2.13 Exemplu de operaie de mprire

Capitolul 2 Modelul relaional de date 61

2.5. Calcul relaional

Calculul relaional este o alternativ la algebra relaional fiind folosit pe partea de manipulare a modelului relaional de date. Diferena dintre cele dou este: Algebra relaional introduce o colecie de operaii explicite, cum ar fi reuniunea, intersecia, diferena, selecia, proiecia, jonciunea etc. care se pot folosi cu scopul de a crea o anumit relaie dorit pe baza unor relaii existente n baza de date. Calculul relaional ofer o notaie cu ajutorul creia se pot formula definiii ale relaiei dorite pe baza relaiilor date. De exemplu, s lum interogarea Afieaz numele complet i oraele proprietarilor de maini care posed o main roie. Folosind algebra relaional acest lucru se poate face: Se cupleaz relaia OWNERS IdentificationNumber cu relaia CARS folosind atributele

Alegerea din relaia rezultant doar a tuplurilor ale cror maini au culoarea roie: Colour = RED Se face o proiecie pe rezultat astfel nct s se obin doar atributele proprietarului mainii FirstName, LastName i City Spre deosebire de algebra relaional, calculul relaional s-ar aplica astfel: S se obin atributele proprietarilor de maini FirstName, LastName i City astfel nct s existe o main cu acelai identificator IdentificationNumber i care s posede culoarea roie RED. Aici, s-au declarat doar caracteristicile definitorii ale setului de tupluri dorit, sistemul fiind lsat s decid exact cum va fi fcut acest lucru. Se poate spune c formularea de calcul relaional este descriptiv n timp ce algebra relaional este prescriptiv. Calculul relaional prezint doar care este problema n timp ce algebra relaional prezint cum trebuie soluionat problema. De fapt, algebra relaional i calculul relaional sunt echivalente, astfel nct pentru orice expresie din algebra relaional exist o expresie echivalent n calculul relaional i invers. ntre cele dou exist o coresponden de unu-la-unu, iar diferenele nu reprezint altceva dect diferene de stil. Calculul relaional este mai apropiat de limbajul natural, n timp ce algebra relaional este mai apropiat de un limbaj de programare. Calculul relaional se bazeaz pe o ramur a matematicii numit calcul predicativ. Kuhns [2.4] pare a fi printele unei astfel de idei de folosire a calcului predicativ ca fundament al unui limbaj de lucru cu baze de date, dar Codd a fost primul care a propus conceptul de calcul relaional ca tip de calcul predicativ destinat special bazelor de date relaionale [2.3]. De asemenea, Codd a prezentat n [2.5] un limbaj explicit bazat pe calculul relaional pe care l-a denumit sublimbaj de date ALPHA dar care nu a fost niciodat implementat n forma sa original. Limbajul QUEL de la INGRES este astzi foarte apropiat de sublimbajul de date ALPHA. Codd a prezentat i un algoritm numit

Baze de date - Fundamente

62

algoritm de reducere, prin care o expresie oarecare din calculul relaional poate fi convertit ntr-o expresie semantic echivalent n algebra relaional. Exist dou tipuri de calcul relaional: Calcul relaional oprientat pe tupluri se bazeaz pe conceptul de variabil de tip tuplu Calcul relaional orientat pe domeniu se bazeaz pe conceptul de variabil de tip domeniu

2.5.1 Calculul relaional orientat pe tupluri

O variabil de tip tuplu este acea variabil care ia valori n cadrul unei relaii. Valorile pe care le poate lua aceast variabil reprezint doar tupluri ale relaiei respective. Cu alte cuvinte, dac variabila T ia valori n relaia R, atunci, n orice moment, T reprezint un anumit tuplu t al relaiei R. O variabil de tip tuplu se definete sub forma: RANGE OF T IS X1; X2; ; Xn n care T reprezint variabila de tip tuplu, iar X1, X2, , Xn sunt expresii de tip tuplu n calculul relaional care reprezint relaiile R1, R2, , Rn. Relaiile R1, R2, , Rn trebuie s fie toate compatibile la reuniune, iar atributele corespunztoare trebuie denumite identic n fiecare dintre relaii. Variabila de tip tuplu T ia valori n cadrul reuniunii relaiilor respective. Dac lista expresiilor de calcul relaional de tip tuplu gsete doar o singur relaie R (situaia obinuit), atunci variabila de tip tuplu T ia valori doar din tuplurile existente n cadrul relaiei respective. Fiecare instan a unei variabile de tip tuplu poate fi independent sau cu legtur. Dac o variabil de tip tuplu apare n contextul unei asocieri cu un atribut de forma T.A, n care A este un atribut al relaiei n care T ia valori, aceasta este denumit variabil de tip tuplu independent. Dac o variabil de tip tuplu apare ca variabil imediat dup unul dintre cuantificatorii: the existential quantifier sau the universal quantifier aceasta este denumit variabil de tip tuplu cu legtur. O expresie de calcul relaional de tip tuplu este definit astfel: T.A, U.B, , V.C WHERE f n care T, U, , V sunt variabile de tip tuplu, A, B, , C sunt atribute ale relaiilor asociate, iar f este o formul de calcul care folosete variabilele independente T, U, , V. Valoarea unei astfel de expresii se definete ca fiind o proiecie a submulimii produsului cartezian TUV (n care T, U, , V iau toate valorile posibile) pentru care formula f este adevrat sau, dac condiia WHERE f nu este prezent, o proiecie a ntregului porodus cartezian. Proiecia se face pe atributele indicate prin notaia cu punct T.A, U.B, , V.C. Nici un element nu poate apare mai mult de o dat n cadrul listei respective. De exemplu, interogarea Afieaz numele complet i oraele proprietarilor de maini care posed o main roie se poate reprezenta sub forma:

Capitolul 2 Modelul relaional de date 63

RANGE OF OWNERS IS OWNERS.FirstName, OWNERS.LastName, OWNERS.City WHERE CARS(CARS.IdentificationNumber=OWNERS.IdentificationNumber AND CARS.Color=RED)

Calculul relaional orientat pe tupluri este n mod formal echivalent cu algebra relaional. Limbajul QUEL de la INGRES se bazeaz pe calculul relaional orientat pe tupluri.

2.5.2 Calculul relaional orientat pe domeniu

Lacroix i Pirotte propun n [2.6] o alternativ la calculul relaional numit calculul relaional pe domeniu n care variabilele de tip tuplu sunt nlocuite cu variabile de domeniu. O variabil de domeniu este acea variabil care ia valori n cadrul unui anumit domeniu, nu n cadrul unei relaii. Fiecare instan a unei variabile de domeniu poate fi la rndul su independent sau cu legtur. O variabil de domeniu cu legtur apare imediat dup variabil mpreun cu unul dintre cuantificatorii: the existential quantifier sau the universal quantifier . n toate celelalte cazuri, variabila este o variabil independent. Calculul relaional orientat pe domeniu folosete condiii condiie de apartenen are forma R (termen, termen, ) n care R este numele relaiei, iar termen este o pereche de forma A:v, n care A este un atribut al R i v este fie o variabil de domeniu, fie o constant. Condiia este adevrat numai i numai dac exist un tuplu al relaiei R care s posede valorile specificate pentru atributele respective. De exemplu, expresia OWNERS(IdentificationNumber:SB24MEA, City:SIBIU) este o condiie de apartenen care este adevrat dac i numai dac exist un tuplu al relaiei OWNERS care s posede pentru atributul IdentificationNumber valoarea SB24MEA iar pentru atributul City valoarea SIBIU. Altfel, condiia de apartenen R (A:AX, B:BX, ) este adevrat dac i numai dac exist un tuplu n R care s posede valoarea atributului A egal cu valoarea curent a variabilei de domeniu AX (oricare ar fi), valoarea atributului B egal cu valoarea curent a variabilei de domeniu BX (oricare ar fi) i aa mai departe. De exemplu, interogarea Afieaz numele complet i oraele proprietarilor de maini care posed o main roie poate fi reprezentat sub forma:
FirstNameX, LastNameX, CityX WHERE IdentificationNumberX (OWNERS (IdentificationNumber:IdentificationNumberX, FirstName:FirstNameX, LastName:LastNameX, City:CityX)

de

apartenen. O

Baze de date - Fundamente

AND CARS(IdentificationNumber:IdentificationNumberX, Color:RED)

64

Calculul relaional de domeniu este echivalent din punct de vedere formal cu algebra relaional. Lacroix i Pirotte prezint n [2.7] un limbaj numit ILL bazat pe calculul relaional. Un alt limbaj relaional bazat pe calculul relaional de domeniu este Query-By-Example (QBE).

2.6 Rezumat
Acest capitol prezint conceptele de baz ale modelului de date relaional. Pentru o mai bun nelegere, sunt explicate i se prezint exemple ale conceptelor : atribut, tuplu, relaie, domeniu, schem, cheie candidat, cheie primar, cheie alternativ i cheie extern. Capitolul mai prezint i constrngerile modelului relaional de date. Au fost discutate o serie de tipuri de constrngeri, cum ar fi: integritatea entitii, integritatea referenial, integritatea semantic, prezentndu-se avantajele i rolul acestora n cadrul bazelor de date relaionale. S-au mai prezentat, de asemenea, n detaliu, operatorii folosii n algebra relaional, cum ar fi reuniunea, intersecia, diferena, produsul cartezian, selecia, proiecia, jonciunea i mprirea. Este important de neles rolul jucat de ctre fiecare dintre aceti operatori din algebra relaional n mediul relaional, deoarece toate interogrile efectuate asupra unei baze de date relaionale folosesc astfel de operatori. Ca o alternativ la algebra relaional a fost prezentat calculul relaional pentru a putea lucra cu schema modelului relaional de date. Diferenele dintre acestea au fost prezentate n cursul capitolului de fa, mpreun cu calculul relaional orientat pe tupluri care are n centru conceptul de variabil de tip tuplu i calculul relaional orientat pe domeniu, care folosete conceptul de variabil de domeniu.

2.7 Exerciii
Pe parcursul acestui capitol s-au prezentat conceptele de baz folosite n cadrul modelului relaional de date. Pentru a obine o mai bun nelegere a acestora s parcurgem urmtoarea situaie preluat din lumea real pe care s o modelm apoi ntr-o baz de date relaional: O companie are mai multe departamente. Fiecare departament are un numr corespunztor, un nume, un director administrativ, o adres i un buget. Dou departamente diferite nu pot avea acelai identificator i acelai director administrativ. Fiecare departament are un singur director administrativ i angajai diferii. Pentru fiecare angajat trebie cunoscut numele, funcia, salariul, data naterii i identificatorul personal care este unic. Aceste informaii se pot modela folosind o baz de date relaional n care vor apare dou relaii: DEPARTMENTS EMPLOYEES

Capitolul 2 Modelul relaional de date 65 DeptNo, DepName, Manager, Address, Budget sunt atributele relaiei DEPARTMENTS. ID, EmpName, Job, Salary, BirthDate, DepNo sunt atributele relaiei EMPLOYEES. Fiecare atribut trebuie s posede un domeniu de valori asociat. De exemplu: DEPARTMENTS DepNo Numeric(2,0) DepName Character(20) Manager Numeric(3,0) Address Character(50) Budget Numeric(10,2) EMPLOYEES ID Numeric(3,0) EmpName Character(30) Job Character(10) Salary Numeric(7,2) BirthDate Date DepNo Numeric(2,0)

Fiecare relaie trebuie s posede o cheie primar. Cheile candidat existente n cadrul relaiei DEPARMENTS sunt: DepNo i Manager. Una dintre acestea este cheia primar a relaiei iar cealalt va fi cheia alternativ. De exemplu, se poate alege DepNo drept cheie primar iar Manager drept cheie alternativ. Cheia primar a relaiei EMPLOYEES este ID. Se vor folosi constrngerile de tip cheie primar. Unele dintre atribute nu pot avea valori nule, astfel nct trebuie folosite constrngeri NOT NULL. n DB2 se pot crea aceste relaii cu ajutorul comenzilor: CREATE TABLE Departments ( DepNo Numeric(2,0) NOT NULL PRIMARY KEY, DepName Char(20) NOT NULL, Manager Numeric(3,0) NOT NULL, Address Char(50), Budget Numeric(10,2) ); CREATE TABLE Employees ( ID Numeric(3,0) NOT NULL PRIMARY KEY, EmpName Char(30) NOT NULL, Job Char(10) NOT NULL, Salary Numeric(7,2), BirthDate Date NOT NULL, DepNo Numeric(2,0) ); ntre relaiile DEPARTMENTS i EMPLOYEES se va introduce o asociere. Fiecare angajat lucreaz ntr-un sigur departament, ceea ce se reprezint prin intermediul unei chei externe. Fie DepNo cheia extern a relaiei EMPLOYEES care este asociat cheii primare DepNo din relaia DEPARTMENTS. n DB2 acest lucru se poate reprezenta folosind integritatea referenial: ALTER TABLE Employees ADD FOREIGN KEY (DepNo) REFERENCES Departments (DepNo) ON DELETE RESTRICT

Baze de date - Fundamente ON UPDATE RESTRICT ENFORCED ENABLE QUERY OPTIMIZATION;

66

Tuplurile relaiilor EMPLOYEES i DEPARTMENTS mpreun cu valorile acestora, care respect toate ipotezele de mai sus, pot fi vzute n Figura 2.14.

Figura 2.14 Relaiile DEPARTMENTS i EMPLOYEES

2.8 ntrebri recapitulative

1. Fie relaia FURNIZOR cu patru atribute: Id numrul de identificare al furnizorului (unic, nenul), Name nume furnizor (nenul), Address adresa furnizorului, Discount reducerea de pre oferit de furnizorul respectiv (nenul, cu valori ntre 0 % i 50 %). Artai constrngerile necesare pentru definirea corect a acestei relaii. 2. Fie patru operaii primitive algebrice: reuniunea, diferena, produsul cartezian, selecia i proiecia. Celelalte se pot defini pe baza acestora. Dai cte o definiie pentru intersecie, jonciune i mprire folosind definiiile operaiilor de mai sus. 3. n cazul relaiei definit anterior, la punctul 1, obinei numele furnizorului din New York care acord o reducere de pre mai mare de 5%, folosind operaiile din algebra relaional.

Capitolul 2 Modelul relaional de date 67 4. Se repet ntrebarea 3 folosind calculul relaional orientat pe tupluri. 5. Se repet ntrebarea 3 folosind calculul relaional orientat pe domeniu. 6. Care dintre urmtoarele afirmaii definesc un atribut din punctul de vedere al modelului relaional de date? A. O caracteristic din lumea real modelat n cadrul bazei de date. B. O mulime de valori atomice. C. O caracteristic a datelor. D. O mulime ordonat de valori care descriu caracteristicile datelor. E. Nici una dintre cele enumerate 7. Care dintre urmtoarele sunt proprieti ale relaiilor? A. Cheia primar nu poate avea valori nule. B. ntr-o relaie nu pot exista tupluri duplicat. C. Atributele au valori atomice. D. ntr-o relaie pot exista tupluri duplicat. E. Nici una dintre cele enumerate 8. O relaie poate avea: A. Domeniu. B. Instan. C. Valoare. D. Grad. E. Nici una dintre cele enumerate 9. Care dintre urmtoarele afirmaii este adevrat? A. Cheia primar este i o cheie candidat. B. Fiecare relaie are cel puin o cheie extern. C. Cheile externe nu pot avea valori nule. D. Cheia primar poate fi i cheie alternativ. E. Nici una dintre cele enumerate 10. La eliminarea unui tuplu dintr-o relaie care are o cheie primar, care dintre urmtoarele opiuni aplicate cheii externe va elimina toate tuplurile care au aceeai valoare n cadrul relaiei ce conine cheia extern? A. Restrict. B. Set to null.

Baze de date - Fundamente C. Delete. D. Cascade. E. Nici una dintre cele enumerate

68

3
Capitolul 3 Modelul conceptual de date
Acest capitol trece n revist conceptele folosite la elaborarea unui model conceptual al bazei de date i descrie n ntregime modul de implementare al acestuia. La ncheierea acestui capitol ar trebui s putei: Oferi informaiile necesare pentru a descrie cu acuratee un anumit domeniu. Preveni greelile i nenelegerile de comunicare. Ajuta la desfurarea discuiilor. Stabili grupul de reguli folosite n domeniul care se modeleaz. Forma o baz solid pentru proiectarea logic a bazei de date. Lua n considerare reguli i legi care guverneaz o anumit organizaie.

3.1 Modelarea conceptual, logic i fizic: vedere de ansamblu

Termenii modelare conceptual, modelare logic i modelare fizic sunt termeni des folosii atunci cnd se lucreaz cu bazele de date. Modelarea conceptual prezint informaia aa cum apare n cadrul unui anumit domeniu, identificnd tipurile de entiti i relaii din cadrul acestuia. Modelarea logic se bazeaz pe modelarea matematic, prezentnd informaiile i entitile ntr-o manier complet normalizat n scopul eliminrii redundanelor. Modelarea fizic implementeaz modelul logic pentru un anumit produs i versiune a unei baze de date. n cadrul acestui capitol ne vom concentra atenia pe modelarea conceptual, de la care ncep toate, dar care trebuie vzut n relaie cu modelarea logic i fizic. La sfritul acestui capitol se va prezenta un studiu de caz de elaborare a unui model conceptual ce va fi transformat ulterior ntr-un model logic (Capitolul 4), i apoi ntr-unul fizic (Capitolul 5). Pentru a nelege mai bine obiectivele clienilor i pentru a evita nenelegerile ce ar putea apare se recomand s se elaboreze modele care s porneasc de la analiza cerinelor. n acest scop IBM a creat o serie de instrumente ajuttoare cum ar fi Rational RequisitePro i InfoSphere Data Architect. Figura 3.1 prezint modul n care cele trei categorii de modele, conceptual, logic i fizic, se completeaz reciproc n cadrul ciclului de via al modelrii mpreun cu instrumentele IBM care vin n sprijinul realizrii acesteia.

Baze de date - Fundamente

70

Figura 3.1 Modelarea conceptual, logic i fizic n cadrul ciclului de via al modelrii datelor Un model de date arat felul n care se reprezint i acceseaz datele, definind elementele de dat i asocierile dintre acestea. Datele reprezint colecii de litere, numere, fapte i documente ce pot fi interpretate n diverse feluri. Datele sunt lipsite de semnificaie dac sunt luate ca atare, dar n momentul n care se prelucreaz ofer informaii de mare valoare. Figura 3.2 prezint o imagine sugestiv a relaiei dintre date i informaii.

Capitolul 3 Modelul conceptual de date 71

Figura 3.2 Procesarea datelor n aceast figur, datele reprezint intrarea n sistemul de informaii, unde se prelucreaz i se transform, obinndu-se la ieire informaii. Un exemplu de date n contextul unei universiti, poate fi numele unui student, iar un exemplu de informaie n cadrul aceluiai context poate fi numrul acestora.

3.2 Ce este un model?

Un model reprezint o abstractizare sau o reprezentare a lumii reale n care se introduc toate caracteristicile din cadrul domeniului de interes pentru utilizatorul de informaii. Modelele se creeaz n scopul unei mai bune nelegeri a unui proces, fenomen, sau activitate. Modelele se utilizeaz, de obicei, pentru a oferi o reprezentare a obiectelor, evenimentelor i tipurilor de relaii dintre acestea precum i pentru a introduce toate conceptele de baz dar i regulile necesare unei bune comunicri dintre programatori i utilizatori.

3.2.1 Model de date

Modelarea datelor stabilete toate informaiile necesare a fi obinute din lumea real. La modelarea datelor trebuie s se obin asigurarea c acestea sunt reprezentate o singur dat n cadrul modelului. Aa cum arat Connolly, un model de date este un instrument folosit pentru abstractizarea datelor, a reprezentrii n ntregime a unei organizaii precum i pentru a ajuta utilizatorii s comunice clar i precis referitor la datele existente n cadrul organizaiei [3]. Modelarea datelor reprezint prima parte a procesului de proiectare i elaborare a unei baze de date.

3.2.2 Modelul bazei de date

Modelul unei baze de date se folosete pentru a introduce date care descriu alte date i care sunt cunoscute de obicei sub denumirea de metadate. Modelul unei baze de date este o colecie integrat de concepte folosite la descrierea datelor, a relaiilor dintre acestea, a semanticii datelor, precum i a constrngerilor introduse. De obicei, modelul unei baze de date se folsoete la descrierea schemei bazei de date. Tipurile de modele de baze de date sunt: Modelul extern de date. Acest model se folosete la obinerea unei reprezentri a fiecrui utilizator, fiind cunoscut i sub denumirea de univers al discursului. Principalul model folosit este modelul logic bazat pe nregistrri.

Baze de date - Fundamente

72

Modelul conceptual de date. Acest model se folosete pentru a obine o vedere general asupra datelor i este independent de orice implementare specific a unui sistem de gestiune al bazelor de date. Modelul logic bazat pe obiecte este un astfel de model. Modelul intern de date. Acest model se folosete pentru a translata modelul conceptual de date ntr-un sistem specific de gestiune al bazelor de date. Modelul de date fizic este un astfel de model. Cel mai rspndit model de date folosit astzi este modelul relaional al bazelor de date. Acest model este un model de tip entitate-relaie i folosete una dintre reprezentrile modelului conceptual. Cele mai importante caracteristici ale modelului relaional sunt cele referitoare la simplitate i puternicul fundament teoretic oferit. Componentele unui model de baze de date sunt Componenta structural care implic grupul de reguli comune folosite la elaborarea unei baze de date. Componenta de manipulare stabilete operaiile ce pot fi utilizate n baza de date (pentru cutarea sau actualizarea datelor din baza de date, sau pentru modificarea structurii bazei de date). Componenta de integritate a datelor un grup de reguli de integritate care asigur corectitudinea datelor.

3.2.3 Conceptele modelului conceptual de date

n cadrul procesului de elaborare a unui model de date trebuie creat mai nti un model conceptual al datelor. Modelul conceptual al datelor reprezint o imagine mental a unui obiect familiar fizic i nu este specific nici unei baze de date reale. La nivel nalt, sunt descrise aspectele prin care o organizaie dorete s colecteze date precum i asocierile dintre obiecte. Obiectivul unui proiect conceptual al unei baze de date este acela de a construi un model conceptual de date. Pentru a face acest lucru se recomand s se parcurg urmtoarele etape: 1. Elaborarea diagramei entitate-relaie. Mai nti se creeaz tipurile de entiti, stabilindu-se atributele i tipurile de relaii corespunztoare. 2. Stabilirea constrngerilor de integritate. Identificarea i documentarea constrngerilor de integritate, cum ar fi datele necesare, integritatea referenial, constrngerile de domeniu ale atributelor, constrngerile organizaei i integritatea entitii. 3. Revizuirea modelului final. n acest scop se elimin relaiile de tip muli-la-muli, se elimin relaiile recursive, se elimin supertipurile, se elimin relaiile care au atribute i se revd relaiile 1:1, care de obicei nu sunt necesare.

Capitolul 3 Modelul conceptual de date 73 3.2.3.1 Modelul entitate-relaie Aa cum s-a artat n Capitolul 1, modelul entitate-relaie a avut un mare succes din momentul n care a nceput s fie folosit sub forma unui instrument de proiectare a bazelor de date relaionale. Pentru reprezentarea cerinelor datelor n funcie de tipul de baz de date cerut se folosete o diagram entitate-relaie. Diagrama entitate-relaie este o form de reprezentare a datelor structurate. Conceptele folosite n modelul entitate-relaie sunt: Tip de entitate Atribut Tip de relaie Constrngere Domeniu Extensie Intensie 3.2.3.2 Entiti i tipuri de entiti Un tip de entitate reprezint o mulime de entiti de acelai tip care au aceleai proprieti. Pentru reprezentarea unui tip de entitate se folosete un substantiv. O entitate este o instan a unui tip de entitate. O entitate este un obiect, un concept sau fenomen de sine stttor i bine definit din cadrul unui tip de entitate. O entitate poate fi: concret (TEACHER sau STUDENT) abstract (GRADE) un eveniment (EXAM) Figura 3.3 arat exemple de entiti i tipuri de entiti

Figura 3.3 - Exemple de tipuri de entiti i entiti n funcie de context, un anumit substantiv cum ar fi de exemplu TEACHER poate fi folosit att ca entitate ct i ca tip de entitate. De exemplu, dac este nevoie s se reprezinte grupuri diferite de persoane, cum ar fi TEACHER sau STUDENT, se va crea un tip de

Baze de date - Fundamente entitate numit PERSON care va avea entitile TEACHER i STUDENT.

74

Dac este nevoie s se modeleze o universitate se va folosi TEACHER ca tip de entitate ce va avea entiti cum ar fi PROFESSOR, ASSOCIATE PROFESSOR, ASSISTANT PROFESSOR. Obs: n modelul logic entitile sunt numite tupluri, iar tipurile de entiti sunt numite relaii. De exemplu, se poate crea o relaie numit PERSON care are dou atribute: NAME i ADDRESS. Din punct de vedere formal, acest lucru se va scrie cu ajutorul relaiei PERSON=(NAME, ADDRESS)

3.2.3.3 Atribute Un atribut este un tip de dat care descrie o proprietate a unui tip de entitate. Atributele determin, explic sau clasific un tip de entitate. Atributele au valori, care pot aparine unor tipuri de date diverse, cum ar fi numere, iruri de caractere, date calendaristice, imagini, sunete etc. Fiecare atribut poate avea o singur valoare pentru fiecare instan a unui tip de entitate. n modelul fizic, atributele sunt numite coloane n cadrul unui tabel i au un anumit domeniu de valori. Fiecare tabel are o list de atribute (sau coloane). Exist urmtoarele tipuri de atribute: Simple (atomice) Acest tip de atribut are o singur component. De exemplu, atributul Gender are o singur component i poate lua doar dou valori. Compuse Un atribut compus este alctuit din mai multe componente. De exemplu, atributul Name are componentele nume de familie i prenume. Cu o singur valoare Acest tip de atribut are o singur valoare pentru fiecare entitate. De exemplu, atributul Title are o singur valoare pentru fiecare cadru didactic. Cu valori multiple Un atribut multivaloare are mai multe valori pentru fiecare entitate. De exemplu, o persoan poate avea mai multe numere de telefon. Conform definiiei, fiecare atribut poate avea o singur valoare pentru fiecare instan a unui tip de entitate. n momentul n care se constat c avem de a face cu un atribut cu valori multiple, acesta va trebui transformat ntr-un nou tip de entitate. Derivat Un atribut derivat are valorile obinute pe baza calculelor fcute cu valorile altui atribut sau atribute. De exemplu, suma tuturor studenilor dintr-o facultate. Atributul derivat nu trebuie s apar n nici unul dintre tabelele bazei de date, dar este folosit n modelul conceptual din motive de claritate sau este folosit n model pentru a putea oferi informaii suplimentare programatorilor. Variabile Acest tip de atribut are valori care se modific n timp. De exemplu, anul

Capitolul 3 Modelul conceptual de date 75 de studii al unui student. Constante Acest tip de atribut i modific valoarea foarte rar, dac nu deloc. Obs: Se recomand folosirea doar a atributelor constante; de exemplu, folosii data de nceput a studiilor unui student i nu anul de studii.

Obligatorii Atributele obligatorii trebuie s posede neaprat o valoare. De exemplu, n situaiile n care se urmresc datele personale ale cuiva, este necesar s existe o valoare n cmpul Name. Obs: Folosind InfoSphere Data Architect, ca instrument de modelare a bazelor de date, vei gsi opiunea Required pe fila Attributes de pe pagina Properties n momentul selectrii unui tip de entitate din diagrama entitate-relaie. Acest lucru este prezentat n Figura 3.4 de mai jos.

Figure 3.4 Stabilirea unui atribut ca fiind obligatoriu Opional Atributele opionale pot avea sau nu valori. Identificator unic Acest tip de atribut are rolul de a deosebi o entitate de alta. De exemplu, ntr-o sal de curs se poate deosebi un student de altul prin utilizarea unui identificator unic. n modelul logic se va folosi un alt concept pentru identificatorul unic, numit cheie. O cheie este un atribut sau un grup de atribute dintr-o relaie care are/au o valoare unic pentru fiecare tuplu al relaiei. Cheia se folosete cu scopul de a obine asigurarea c n cadrul unei relaii nu se pot ntlni tupluri duplicat. Exist mai multe tipuri de chei, fiecare dintre acestea avnd propriile caracteristici: Cheie candidat O cheie candidat este un atribut sau un grup de atribute care identific n mod unic un tuplu dintr-o relaie. Cheie primar O cheie primar este una dintre cheile candidat din cadrul unei

Baze de date - Fundamente

76

relaii. Orice relaie trebuie s posede o cheie primar care trebuie s ndeplineasc cel puin condiiile de: - Stabilitate. Valoarea unei chei primare nu trebuie s se modifice sau s devin nul pe toat existena entitii respective. De exemplu, n cazul unui student folosirea vrstei drept cheie primar nu este potrivit, deoarece aceasta se modific n timp. - Minimalitate. Cheia primar trebuie s fie alctuit din ct mai puine atribute care s asigure unicitatea. Cheie alternativ O cheie alternativ este una dintre cheile candidat care nu a fost desemnat s ndeplineasc rolul de cheie primar. Aceasta poate deveni n orice moment cheie primar dac cea aleas anterior nu mai este corespunztoare. Cheie surogat O cheie surogat acioneaz la fel ca o cheie primar, dar aceasta nu exist ca entitate n lumea real. Deoarece cheia surogat nu spune nimic despre relaia pentru care a fost desemnat, introducnd date fr semnificaie care conduc la creterea artificial a bazei de date, se recomand ca ori de cte ori este posibil s se renune la utilizarea acesteia. Cheile surogat pot fi definite atunci cnd se modeleaz o baz de date folosind instrumentul ajuttor InfoSphere Data Architect, aa cum se arat n Figura 3.5.

Figura 3.5 Introducerea unei chei surogat Chei simple Aceste chei sunt alctuite dintr-un singur atribut. Chei compuse Aceste chei sunt alctuite din mai multe atribute. Chei externe Aceste chei se folosesc, de obicei, atunci cnd exist dou sau mai multe relaii n baza de date. Un atribut din cadrul unei relaii trebuie s aib un corespondent n cadrul celeilalte/celorlalte relaii. ntre cele dou atribute se creeaz un tip de relaie. O situaie special se ntlnete la folosirea unui tip de relaie unar. n acest caz, trebuie folosit o cheie extern n cadrul aceleiai relaii.

Capitolul 3 Modelul conceptual de date 77 3.2.3.4 Tipuri de relaii Un tip de relaie reprezint o mulime de asocieri dintre dou sau mai multe tipuri de entiti i se reprezint de obicei prin folosirea unui verb. O relaie reprezint o instan a unui tip de relaie stabilind legtura dintre tipurile de entiti aflate n asociere. Aceste relaii trebuie s reprezinte ceva important din cadrul modelului, deoarece ntre dou tipuri de entiti se pot stabili mai multe asocieri. Un tip de relaie se stabilete ntre dou tipuri de entiti (sau ntre un tip de entitate i el nsui). Fiecare tip de relaie trebuie citit n ambele sensuri, de la un tip de entitate ctre cellalt i invers. Un tip de relaie se poate defini n mod formal, sub forma unei relaii matematice ntre tipurile de entiti pe care le asociaz, aa cum se prezint n continuare. Pentru a realiza acest lucru se vor folosi urmtoarele variabile: Tip de entitate: Entitate: Tip de relaie: Relaie: E e R r

Avnd o mulime de tipuri de entiti E1, E2 Ek, o relaie R stabilete o regul de coresponden ntre aceste tipuri de entiti. O instan r(E1, E2,, EK) a relaiei R arat c, la un anumit moment dat, n relaia R se afl tipurile de entiti E1, E2 Ek 3.2.3.5 Constrngeri n orice domeniu de activitate sunt permise doar anumite valori ale atributelor folosite. Pentru a face acest lucru, n modelul conceptual se folosesc constrngerile. O constrngere reprezint o cerin pe care trebuie s o ndeplineasc un tip de entitate n cadrul unei relaii. Constrngerile pot face referire la un singur atribut al unui tip de entitate sau la un tip de relaie dintre dou tipuri de entiti. De exemplu, "fiecare TEACHER trebuie s funcioneze doar ntr-un singur DEPARTMENT". Tipurile de constrngeri sunt: Cardinalitatea reprezint numrul de tipuri de relaii posibile pe care le poate avea fiecare tip de entitate. Tipurile de constrngeri de cardinalitate sunt prezentate mai jos. Fie o relaie binar R ntre E (tipul de entitate din stnga din figura de mai jos) i F (tipul de entitate din dreapta din figura de mai jos). Se spune c R poate fi: - Unu-la-unu (1:1) dac att E ct i F au cte o singur valoare participant n relaie, aa cum se vede n figura de mai jos.

- Unu-la-muli (1:M) - dac E are o singur valoare iar F are mai multe valori

Baze de date - Fundamente participante n relaie, aa cum se vede din figura de mai jos.

78

- Muli-la-muli (M:M) dac att E ct i F au mai multe valori participante n relaie.

Tipurile de relaii muli-la-muli nu sunt suportate n modelul relaional de date i trebuie rezolvate prin separarea tipului de relaie original M:M n dou tipuri de reaie 1:M. De obicei, identificatorii unici ai celor dou tipuri de entiti particip la crearea identificatorului unic al celui de-al treilea tip de entitate. Participarea (opionalitatea). Acest tip de constrngere arat dac existena unui tip de entitate depinde de legtura acestuia cu un alt tip de entitate printr-un tip de relaie. Participarea poate fi: - Total sau obligatorie: Fiecare tip de entitate trebuie s participe ntr-o relaie i nu poate exista fr acea participare; participarea este obligatorie. - Partial sau opional: Fiecare tip de entitate poate participa ntr-o relaie; participarea nu este obligatorie. Figura 3.6 prezint att constrngerile de cardinalitate ct i pe cele de participare.

participare = cardinalitate =

trebuie ci ?

sau

poate ?

Un tip de relaie are ntotdeauna dou laturi Exemple 1. Fiecare student poate s studieze cu unul sau mai muli profesori 2. Fiecare profesor poate s educe unul sau mai muli studeni 3. Un anagajat poate conduce unul sau mai muli anagajai 4. Un angajat trebuie s fie condus de ctre un singur angajat
Figura 3.6 Cardinalitatea i participarea Subtipuri i supertipuri

Capitolul 3 Modelul conceptual de date 79 Atunci cnd un grup de instane are proprieti speciale cum ar fi atribute sau tipuri de relaii care exist doar pentru grupul respectiv, se recomand s se mpart tipul de entitate corespunztor n subtipuri. Tipul de entitate de la nivelul superior este numit printe i reprezint un supertip. Fiecare dintre grupuri reprezint subtipuri i se numesc copii. Un subtip este alctuit din toate atributele supertipurlui i preia toate tipurile de relaii ale acestuia. Pentru aputea exista, un supertip trebuie s aib cela puin dou subtipuri asociate, care la rndul lor pot avea subtipuri asociate. Un subtip, de obicei, adaug propriile atribute sau tipuri de relaii fa de cele motenite de la supertip. Cu ajutorul supertipurilor i subtipurilor se pot crea ierarhii. Examplu Un tip de entitate PERSON poate avea dou subtipuri STUDENT i TEACHER aa cum se vede n Figura 3.7 de mai jos.

Figura 3.7 Supertipul PERSON mpreun cu subtipurile asociate STUDENT i TEACHER Ierarhia O ierarhie reprezint o mulime ordonat de obiecte. De exemplu, ntr-o coal, poate exista o ierhie de tipul celei prezentate n Figura 3.8.

Figura 3.8 Exemplu de ierarhie dintr-o coal Tipuri de relaii unare n situaia acestui tip de constrngere, acelai tip de entitate

Baze de date - Fundamente

80

particip de mai multe ori n acelai tip de relaie. Mai este cunoscut i sub denumirea de tip de relaie recursiv. Exemplu Directorul adjunct este i el un profesor, astfel nct se poate realiza o asociere ntre profesorii subordonai folosind un tip de relaie ntre tipul de entitate TEACHER i el nsui. Acelai tip de entitate particip de mai multe ori n acelai tip de relaie. Figura 3.9 arat un astfel de exemplu.

Figura 3.9 Exemplu de tip de relaie unar Date istorice n anumite situaii este nevoie s se pstreze datele folosite de-a lungul timpului n baza de date. De exemplu, la modificarea valorilor atributelor, sau atunci cnd se modific tipurile de relaii. Datele istorice se pot folosi sub forma unei constrngeri de timp. De exemplu, constrngerea poate specifica faptul c o dat calendaristic de final trebuie s urmeze ntotdeauna dup o dat calendaristic de nceput a unei activiti oarecare. n modelul fizic se poate folosi o constrngere de tip CHECK n acest scop. Constrngerile de acest tip trebuie s aib n vedere i faptul c data de nceput nu poate fi modificat la o dat anterioar fa de momentul nceperii unei activiti, sau data de nceput i cea de sfrit a unei activiti nu pot fi identice. Exemplu Un student trebuie s termine studiile dup data nceperii acestora, nu nainte. n acest caz, data de final a studiilor unui student trebuie s fie dup data de nceput a acestora. Obs: Pentru a introduce o constrngere de verificare, vedei seciunea Adding constraints din cartea Getting Started with InfoSphere Data Architect, care face parte din seria actual de cri. Mai mult dect att, se poate ntmpla ca atunci cnd se modific datele existente, s se doreasc s se pstreze o copie a valorilor anterioare. Acest lucru este posibil s se cear atunci cnd datele au un caracter sensibil, cum ar fi, de exemplu, modificarea notelor unui student.

Capitolul 3 Modelul conceptual de date 81 Exemplu La modificarea notelor unui student este necesar s se pstreze nregistrarea a ceea ce se modific, adic nota veche, nota nou i persoana care a fcut modificarea. Figura 3.10 arat un exemplu de jurnalizare.

Figura 3.10 Exemplu de jurnalizare 3.2.3.6 Domeniul de valori Un domeniu de valori reprezint mulimea valorilor posibile ce poate fi asociat unuia sau mai multor atribute. Utilizatorul poate stabili domeniul de valori pe care l dorete. Modelele de domeniu permit utilizatorului stabilirea tipurilor de date necesare n domeniul respectiv. Obs Folosind InfoSphere Data Architect, este posibil s se foloseasc modele de domeniu pentru a restrnge valorile i domeniile respective la nivelul tipurilor de date. Clauza CHECK din standardul SQL permite introducerea de restricii pe domenii. Clauza CHECK permite proeictantului schemei s introduc un predicat care trebuie validat de ctre orice valoare atribuit unei variabile al crui tip se afl n domeniul respectiv. 3.2.3.7 Extensia Bazele de date se modific n timp. Datele aflate ntr-o baz de date la un anumit moment dat formeaz extensia bazei de date. Extensia reprezint mulimea actual de tupluri din cadrul unei relaii i este o instan a mulimii de nregistrri i de tipuri de relaii dintre acestea. 3.2.3.8 Intensia Intensia sau schema reprezint modelul logic al unei baze de date i se reprezint prin intermediul tipurilor de entiti. O instan prezint i restrnge structura tuplurilor permise. O instan este reprezentat prin intermediul tipurilor de entiti i este modelul unei baze de date. Operaiile de manipulare ale datelor sunt permise numai dac acestea respect intensiile relaiilor pe care le modific.

3.3 Studiu de caz cu sistemul de management al unei biblioteci Partea 1 din 3

Acest studiu de caz prezint un sistem de management folosit n cadrul unei biblioteci. Se presupune c toate cerinele sistemului au fost specificate de ctre client exact n aceti

Baze de date - Fundamente termeni:

82

"Sistemul va gestiona informaii referitoare la autori i la cei care mprumut cri, pstrnd un istoric al crilor mprumutate. Informaiile referitoare la cei care mprumut cri au n vedere numele, adresa, e-mail-ul i numrul de telefon. Informaiile despre autori se refer la nume, adres i e-mal.. Se pot introduce n sistem toate crile noi, cu autorii respectivi i cu informaiile referitoare la cei ce mprumut cri. Atunci cnd o persoan mprumut o carte, sistemul va nregistra data la care s-a mprumutat cartea respectiv i va calcula numrul de zile pn la care cartea trebuie returnat. Dac cititorul aduce cartea mai trziu, trebuie s plteasc o amend n funcie de numrul de zile de ntrziere."

3.3.1 Elaborarea modelului conceptual

Se vor parcurge urmtorii pai pentru elaborarea modelului conceptual: Pasul 1 Identificarea tipurilor de entiti Pentru a identifica un tip de entitate, trebuie citite cu atenie toate cerinele subliniindu-se toate substantivele ntlnite n descriere. Se poate crea o list cu toate aceste atribute, cu duplicate cu tot, din care se vor elimina ulterior toate cele ce nu prezint interes pentru sistemul care se proiecteaz. n acest studiu de caz s-au ntlnit urmtoarele substantive: Cri, autori, nume, adres, e-mail, cititor, persoan, nume adres, e-mail, telefon, data la care se face mprumutul, data la care trebuie returnat cartea, numrul de zile pe care se mprumut cartea, amenda. Fiecare substantiv poate deveni un tip de entitate, dar o parte dintre acestea vor fi atribute. n aceast faz se va stabili care dintre aceste substantive sunt tipuri de entiti. Se ncepe prin stabilirea dependenelor. n exemplul de fa, numele, adresa i e-mail-ul depind de autor, iar numele, adresa, e-mail i numrul de telefon depind de cititor. Pornind de la aceast prim analiz, se vor stabili urmtoarele tipuri de entiti: BIBLIOTECA, CARTE, AUTOR, CITITOR, CLIENT i CEL CE MPRUMUTA ca tipuri de entiti din modelul nostru, deoarece acestea sunt obiecte de interes n cadrul sistemului. Rezultatul analizei este prezentat n tabelul de mai jos: Nr. Crt. 1 2 3 4 5 Tip de entitate BIBLIOTECI CARTI AUTORI CITITORI CLIENI

Capitolul 3 Modelul conceptual de date 83 6 CEI CE MPRUMUT

Pasul 2 Eliminarea tipurilor de entiti duplicat n momentul n care se scriu cerinele se obinuiete s se foloseasc diverse cuvinte care nseamn acelai lucru, motiv pentru care mai nti trebuie s identificm cuvintele redundante. n exemplul dat, exist mai multe cuvinte sinonime: cititor, client, cei ce mprumut cri. n final trebuie s rmn doar unul dintre aceste sinonime. Vom alege cititor. Un aspect deosebit de important este acela de a nu face greeala de a introduce ca tip de entitate separat chiar numele sistemului, motiv pentru care cuvntul biblioteca trebuie eliminat. n sfrit, trebuie determinat tipul entitilor, adic trebuie stabilit dac un tip de entitate este puternic sau slab. Un tip de entitate este slab dac existena sa depinde de existena unui alt tip de entitate. Un tip de entitate puternic este acela a crui existen este independent de orice alt tip de entitate. Acest lucru este necesar mai trziu, atunci cnd trebuie stabilit tipul de relaie. Rezultatele obinute sunt prezentate n tabelul de mai jos: Nr. crt. 1 2 3 Tip de entitate CRI AUTORI CITITORI Tip Puternic Puternic Puternic

Pasul 3 Lista atributelor fiecrui tip de entitate n continuare se va obine asigurarea c fiecare tip de entitate este neaprat necesar. Se verific dac nu cumva un anumit tip de entitate nu este de fapt un atribut al altui tip de entitate. De exemplu, numrul de telefon este un tip de entitate sau un atribut al tipului de entitate AUTORI? Se va ine legtura cu clientul pentru a stabili dac nu cumva mai sunt necesare i alte atribute pentru tipurile de entiti identificate. n exemplul prezentat, am folosit doar cteva atribute pentru fiecare tip de entitate rmas, aa cum se arat n tabelele urmtoare: Tipul de entitate CITITORI Nume atribut ID_CITITOR NUME EMAIL Tip Identificator unic Atribut compus Atribut cu o singur valoare Domeniu Text Text Text Opional Nu Nu Da

Baze de date - Fundamente TEL ADRESA ID_CARTE DATA_IMPRUMUT DURATA DATA_RETUR Atribut multivaloare Atribut compus Atribut cu o singur valoare Atribut cu o singur valoare Atribut derivat Atribut derivat Text Text Text Text Text Text Da Da Nu Nu Nu Nu

84

Tipul de entittate AUTORI Nume atribut ID_AUTOR NUME EMAIL TEL ADRESA Tip Identificator unic Atribut compus Atribut cu o singur valoare Atribut multivaloare Atribut compus Domeniu Text Text Text Text Text Opional Nu Nu Da Da Da

Tipul de entitate CARTI Nume atribut ID_CARTE TITLU EDITIE AN PRET ISBN PAGINI INTERVAL Tip Identificator unic Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Domeniu Text Text Numeric Numeric Numeric Text Numeric Text Opional Nu Nu Da Da Da Da Da Da

Capitolul 3 Modelul conceptual de date 85 DESCRIERE Atribut simplu Text Da

Aa cum s-a artat n seciunea 3.2.3.3 Atribute, sunt cteva lucruri care trebuie stabilite pentru atributele din tabelele de mai sus: 1. Trebuie s se ia o hotrre referitoare la atributele compuse: se pstreaz aa cum sunt sau se separ n dou sau mai multe. n cazul de fa dac clientul dorete s fac o cutare dup numele de familie sau dup prenume este mai bine s se separe atributul compus. n acest fel vom avea n locul atributului NUME, atributele NUME i PRENUME. 2. Atunci cnd se gsete un atribut multivaloare, acesta trebuie transformat ntr-un alt tip de entitate. n cazul de fa, nu este nevoie de mai multe numere de telefon, aa c se va modifica tipul atributului din multivaloare n singur valoare. 3. DURATA este un atribut derivat care se poate calcula de ctre sistem pe baza atributului DATA_IMPRUMUT. n exemplul de fa, fiecare carte poate fi mprumutat doar pe durata a 10 zile. Acest atribut trebuie eliminat. Dup aceast analiz, rezultatele acestui pas sunt prezentate n tabelele de mai jos: Tipul de entitate CITITOR Nume atribut ID_CITITOR NUME PRENUME EMAIL TEL ADRESA ID_CARTE DATA_IMPRUMUT DATA_RETUR Tip Identificator unic Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Atribut compus Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Domeniu Text Text Text Text Text Text Text Text Text Opional Nu Nu Nu Da Da Da Nu Nu Nu

Tipul de entitate AUTORI Nume atribut ID_AUTOR Tip Identificator unic Domeniu Text Opional Nu

Baze de date - Fundamente NUME PRENUME EMAIL TEL ADRESA Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Atribut compus Text Text Text Text Text Nu Nu Da Da Da

86

Tipul de entitate CARTI Nume atribut ID_CARTE TITLU EDITIE AN PRET ISBN PAGINI INTERVAL DESCRIERE Tip Identificator unic Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Atribut cu o singur valoare Domeniu Text Text Numeric Numeric Numeric Text Numeric Text Text Opional Nu Nu Da Da Da Da Da Da Da

Pas 4 Alegerea unui identificator unic n cazul tipului de entitate CARTI, exist posibilitatea de a alege identificatorul unic dintre atributele ID_CARTE i ISBN. n cazul de fa vom alege ID_CARTE, care reprezint identificatorul unic al fiecrei cri din sistemul de management al bibliotecii, deoarece clientul nu dispune de un scaner manual, motiv pentru care, att la mprumutul ct i la returnarea crilor, bibliotecarul trebuie s introduc n cmpul ISBN toate cifrele acestuia ceea ce poate fi neplcut i ineficient. Pas 5 Stabilirea tipurilor de relaii n acest pas trebuie examinate asocierile multiple dintre diversele tipuri de entiti, deoarece, de obicei, este posibil s se gseasc mai multe tipuri de relaii pentru o pereche de tipuri de entiti. De exemplu, o carte poate fi scris de ctre o persoan sau poate fi mprumutat de ctre o persoan.

Capitolul 3 Modelul conceptual de date 87 n continuare se vor identifica cardinalitatea i participarea tipurilor de relaii alese, eliminndu-se tipurile de relaii redundante. De asemenea, se va stabili dac un tip de relaie este puternic sau slab pe baza tipurilor de entiti care intr n asociere. Tipurile de relaii slabe se stabilesc ntre un tip de entitate puternic i un tip de entitate slab. Tipurile de relaii puternice se stabilesc ntre dou tipuri de entiti puternice. n instrumentul InfoSphere Data Architect acestea sunt cunoscute sub denumirea de identifying, respectiv non-identifying. O asociere de tip identifying se alege atunci cnd tipul respectiv de relaie este unul n care unul dintre tipurile de entiti subordonate este un tip de entitate dependent de existena altui tip de entitate. Tipurile de relaii non-Identifying se aleg atunci cnd ambele tipuri de entiti participante ntr-o relaie sunt independente. Pentru a stabili tipurile de relaii trebuie s se identifice perechile de tipuri de entiti, analizndu-se toate scenariile posibile. O idee simpl ar fi folosirea tabelelor, aa cum se vede mai jos: Tip de relaie Identifying Verbul din stnga mprumut Verbul din dreapta Cardinalitatea Participarea

CITITORI -> CARTI AUTORI - > CARTI AUTORI - > CARTI

Nu

Este mprumutat Este scris

Muli-la-muli

Poate

Nu

Scrie

Muli-la-muli

Poate

Nu

mprumut

Este mprumutat

Muli-la-muli

Poate

n tabelul de mai sus se observ 3 tipuri de relaii muli-la-muli care trebuie rezolvate. Acest lucru se poate face prin descompunerea tipului de relaie iniial n dou tipuri de relaii unu-la-muli. n acest scop trebuie gsit un al treilea tip de entitate intermediar. n cazul de fa vom avea: 1. CITITORI -> CARTI Pentru a rezolva acest tip de relaie se va folosi tipul de entitate COPIE care se creeaz n mod natural deoarece, de fapt, o persoan nu mprumut o carte, ci o copie a acesteia. Tipul de entitate COPIE va arta astfel: Tipul de entitate COPIE Nume atribut ID_COPIE STARE Tip Identificator unic Atribut cu o singur valoare Domeniu Text Text Opional Nu Nu

2. AUTORI - > CARTI

Baze de date - Fundamente

88

Pentru a elimina tipul de relaie muli-la-muli dintre tipul de entitate AUTORI i tipul de entitate CARTI se creeaz tipul de entitate LISTA_AUTHORI. Noul tip de entitate va arta astfel: Tipul de entitate LISTA_AUTORI Nume atribut ROL Tip Atribut cu o singur valoare Domeniu Text Opional Nu

n acest fel, noul tabel cu tipuri de relaii va arta astfel: Tip de relaie Identifying Verbul din stnga mprumut Verbul din dreapta Cardinalitatea Participarea

CITITORI - > COPIE CARTI - > COPIE AUTORI - > LISTA_AUTORI LISTA_AUTORI - > CARTI

Nu

Este mprumutat Este creat

Unu-la-muli

Poate

Nu

Are

Unu-la-muli

Poate

Nu

Apare

Are

Unu-la-muli

Poate

Nu

Este creat

Are

Multi-la-multi

Poate

3. AUTORI - > CARTI Cel de-al treilea tip de relaie care trebuie de asemenea descompus se prezint din nou din motive de uiurin a citirii: Tip de relaie Identifying Verbul din stnga mprumut Verbul din dreapta Cardinalitatea Participarea

AUTORI CARTI

>

Nu

Este mprumutat

Muli-la-muli

Poate

Parcurgnd acest studiu de caz s-ar putea s vi se par curios de ce avem un tip de entitate AUTORI i alt tip de entitate CITITORI, la care cele mai multe dintre atribute sunt identice. De ce nu se creeaz un singur tip de entitate PERSOANA care s fie un supertip al subtipurilor AUTORI i CITITORI? n definitiv, i autorii pot mprumuta cri. Acest model poate fi creat folosind un singur tip de entitate PERSOANA, dar exist dou motive pentru care nu vom proceda n acest fel:

Capitolul 3 Modelul conceptual de date 89 Simplitatea nelegerii acestui model (n principal, de natur didactic, pentru a nelege conceptele mai uor) Simplitatea n momentul elaborrii aplicaiei corespunztoare acestui model. Presupunnd c sistemul se adreseaz bibliotecii unui ora mic, ansele ca autorii crilor s locuiasc n acel ora sunt foarte reduse, ceea ce nseamn faptul c ansele ca autorii crilor s mprumute cri de la biblioteca respectiv sunt i acestea foarte reduse. n acelai timp de ce s avem n vedere un astfel de scenariu n aplicaia pe care o elaborm? n cazul puin probabil ca autorul unei cri s locuiasc n acel ora, bibliotecarul poate s cear acestuia s-i creeze propriul cont de cititor. n acest fel programatorul nu mai trebuie s-i fac griji cu privire la elaborarea unei singure interfee n care autorul este i cititor. Desigur, o parte dintre aceste aspecte trebuie vzute ca reguli de domeniu i trebuie interpretate ca atare. Alte consideraii care vor fi discutate ulterior vor avea n vedere constrngerile asupra datelor care se introduc n tabele. De exemplu, se poate introduce o restricie prin care s se verifice dac data de returnare a crilor mprumutate este ulterioar datei la care acestea au fost mprumutate. Se va discuta acest aspect atunci cnd se va disctua despre constrngerea CHECK n modelul fizic prezentat n Capitolul 5. Pas 6 Stabilirea regulilor de domeniu Regulile de domeniu trebuie implementate prin intermediul unei aplicaii. n cazul de fa vom lua n considerare urmtoarele reguli de domeniu: 1. Doar administratorii sistemului pot modifica date 2. Se va permite ca sistemul s poat face rezervri de cri. Fiecare cititor poate si vad poziia n lista de ateptare pentru a obine cartea de care este interesat. 3. Aplicaia va trimite un mesaj prin e-mail prin care se va aminti cititorului de faptul c va trebui s returneze cartea n termen de 3 zile de la trimiterea mesajului. 4. Dac cititorul nu returneaz la timp cartea, acesta va fi amendat cu 0.1% din preul crii pentru fiecare zi de ntrziere. Acest studiu de caz v-a prezentat o serie de recomandri de care este bine s inei seama la proiectare. Totui, modelarea conceptual este un proces iterativ, astfel nct este necesar s elaborai mai multe versiuni ale aceluiai model din care s o alegei apoi pe cea optim. Nu exist un rspuns ferm la ntrebarea dac un model este mai bun dect altul, dar cu siguran putei gsi soluii mai bune dect altele. Acest studiu de caz va continua n Capitolul 4, n care se va discuta despre modelarea logic a acestui sistem de management al unei biblioteci.

3.4 Rezumat
n cadrul acestui capitol s-a discutat despre modelarea conceptual, explicndu-se felul n care trebuie s se abordeze situaiile atunci cnd se lucreaz cu diagramele entitaterelaie. Pe parcurs s-au prezentat o serie de concepte, cum ar fi: tipuri de entiti, atribute,

Baze de date - Fundamente tipuri de relaie, constrngeri, domenii .a.m.d.

90

Folosirea unui instrument grafic, cum ar fi de exemplu InfoSphere Data Architect, se dovedete a fi de mare ajutor, n special atunci cnd se lucreaz la proiecte foarte complexe, fiind nevoie de transmiterea acestor modele ntre diferitele persoane interesate de bunul mers al proiectului sau ntre cei care lucreaz la modelele de date logice sau fizice. Conceptele de baz din modelarea conceptual sunt prezentate i n cartea Getting Started with InfoSphere Data Architect. Acest capitol mai discut i despre modul de organizare a modelului de date apelnd la reguli pentru elaborarea modelului ER i crearea de diagrame. Dei n aceast carte nu se urmresc aspecte referitoare la programare, acest capitol v ofer o baz solid n nelegerea modelrii conceptuale prin folosirea de exemple realizate cu ajutorul instrumentului InfoSphere Data Architect.

3.5 Exerciii
Fie urmtoarele tipuri de entiti din cadrul unei universiti: Facultate Profesor Functie Curs Student

Se cere s se realizeze o reprezentare grafic a tipurilor de relaii i entiti. Reprezentai grafic toate aspectele care se modeleaz folosind o diagram entitate-relaie creat cu ajutorul instrumentului InfoSphere Data Architect. Pentru a obine mai multe informaii despre acest instrument urmrii cartea Getting started with InfoSphere Data Architect ce face parte din seria de cri din care face parte i cea de fa.

3.6 ntrebri recapitulative

1. Care dintre urmtoarele aparin unui tip de entitate: A. O coloan dintr-un tabel B. Colecie de obiecte sau concepte din lumea real C. Date care descriu o caracteristic a unui obiect sau concept D. Mulime de entiti de acelai tip care au aceleai proprieti. E. Nici unul dintre cele enumerate. 2. Atributele variabile: A. Au valori care se modific frecvent. B. Se modific rar, dac nu deloc C. Au valori ce provin de la alt atribut sau atribute

Capitolul 3 Modelul conceptual de date 91 D. Au mai multe valori pentru fiecare entitate E. Nici unul dintre cele enumerate. 3. Trebuie rezolvat un tip de relaie M:M. Noul tip de relaie are ntotdeauna: A. O participare opional pe partea de muli B. Participare obligatorie pe partea de unu C. Participare obligatorie pe partea de muli D. Redundan pe partea de muli E. Recursivitate pe partea de unu 4. Care dintre urmtoarele afirmaii este adevrat atunci cnd se vorbete despre modelarea conceptual? A. Un tip de entitate trebuie s apar o singur dat ntr-un model de date B. Modelul conceptual trebuie s prezinte i atributele derivate C. ntr-un model conceptual trebuie reprezentate toate datele posibile D. Toate cele enumerate E. Nici una dintre cele enumerate 5. Care dintre urmtoarele formulri NU reprezint definiia unui tip de entitate? A. Un tip de entitate este o colecie de obiecte sau concepte din lumea real care au aceleai caracteristici. B. Un tip de entitate este o instan a unor obiecte din lumea real C. Un tip de entitate este un obiect care are existen proprie i care este distinct de toate celelalte. D. Toate cele enumerate E. Nici una dintre cele enumerate 6. Care dintre urmtoarele afirmaii NU este adevrat referitor la un tip de relaie? A. Un tip de relaie prezint felul n care tipurile de entiti se asociaz unele cu altele. B. Un tip de relaie trebuie s existe ntotdeauna ntre dou tipuri de entiti C. Un tip de relaie trebuie citit n ambele sensuri. D. Un tip de relaie este un substantiv E. Toate cele enumerate. 7. Care dintre urmtoarele afirmaii este adevrat atunci cnd se face referire la tipurile de relaii obligatorii? A. Prezint felul n care de entitie se asociaz ntre ele.

Baze de date - Fundamente B. Fiecare tip de entitate trebuie s participe ntr-o asociere. C. Fiecare tip de entitate poate s participe ntr-o asociere D. Exist mai multe posibiliti de asociere pentru fiecare tip de entitate E. Nici una dintre cele enumerate.

92

8. Un grup de instane care au atribute sau tipuri de relaii care exist numai pentru acel grup este numit: A. Constrngere B. Cardinalitate C. Supertip D. Subtip E. Toate cele enumerate 9. Denumii o clauz din standardul SQL, care permite restricionarea domeniilor: A. RELATIONSHIP B. PRIMARY KEY C. CHECK D. CONSTRAINT E. Nici una dintre cele enumerate 10. Datele existente ntr-o baz de date la un anumit moment dat sunt denumite: A. Intensie B. Extensie C. Schem D. Instan E. Nici una dintre cele enumerate

4
Capitolul 4 Proiectarea bazelor de date relaionale
Acest capitol prezint conceptele de proiectare folosite n domeniul bazelor de date relaionale care ajut la modelarea diverselor domenii din lumea real sub forma bazelor de date relaionale. Se vor oferi o serie de recomandri pentru crearea tabelelor, coloanelor i stabilirea de asocieri dintre tabele astfel nct s se obin minimum de redundan a datelor. n cadrul acestui capitol se vor urmri: Modelarea obiectelor din lumea real sub forma tabelelor relaionale Identificarea problemelor i minimizarea redundanelor Identificarea dependenelor i introducerea acestora n cadrul proiectului bazei de date relaionale Revizuirea tabelelor relaionale pentru a obine o proiectare optim

4.1 Problema redundanei

Redundana datelor nseamn regsirea acelorai date n mai multe locaii din cadrul unei baze de date. Existena redundanelor n cadrul unei scheme relaionale semnific o proiectare lipsit de optimizare a acesteia, datorit apariiei anomaliilor: de inserare de tergere de actualizare Tabelul 4.1 prezint un exemplu de redundan a datelor deoarece informaiile despre colegiu i informaiile despre studeni sunt pstrate la un loc. Folosind un astfel de model de proiectare, vor trebui introduse aceleai informaii despre colegiu de mai multe ori, cte o dat pentru fiecare student nscris. De exemplu, informaia despre nivelul colegiului se repet de dou ori, o dat pentru studentul George Smith, i alt dat pentru studentul Will Brown.

Baze de date - Fundamente ID_STUDENT 0001 0002 0003 0004 STUDENT Ria Sinha Vivek Kaul George Smith Will Brown POZITIE 6 15 9 1 COLEGIU Fergusson PICT IIT IIT

94 NIVEL_COLEGIU 4 5 1 1

Tabel 4.1 Exemplu de redundan a datelor (schema Student)

Obs: Tabelul 4.1 se va folosi la toate exemplele din cadrul acestui capitol. Coloana ID_STUDENT care reprezint numrul matricol al studentului este cheie primar n cadrul schemei Student.

4.1.1 Anomalii de inserare

O anomalie de inserare are loc atunci cnd, la introducerea datelor n cadrul unui rnd al unui tabel, se constat c acest lucru nu se poate face pn cnd nu se introduc alte date suplimentare n cadrul rndului (date care nu au nici o legtur cu datele ce trebuie introduse). De exemplu, introducerea informaiilor despre student impune i introducerea datelor despre colegiu (coloana NIVEL_COLEGIU din Tabelul 4.2). ID_STUDENT 0005 STUDENT Susan Fuller POZITIE 10 COLEGIU Fergusson NIVEL_COLEGIU

Tabelul 4.2 Anomalii de inserare Exemplu n plus, se va constata o repetare a acelorai date n diverse locaii din cadrul bazei de date deoarece datele referitoare la nivelul colegiului trebuie introduse pentru fiecare student nou introdus in tabel.

4.1.2 Anomalii la tergere

O anomalie la tergere apare atunci cnd la eliminarea unei nregistrri se pierd i alte informaii care nu au legtur cu datele eliminate, dar care au fost stocate ca parte a nregistrrii care se elimin din cadrul tabelului. De exemplu, prin eliminarea unui student se vor pierde i informaiile referitoare la colegiu i la nivelul colegiului care reprezint informaii despre colegiul respectiv, neavnd legtur cu studentul. Acest lucru se poate vedea n Tabelul 4.3, n care se pierd toate informaiile referitoare la colegiul IIT dac se elimin ambii studeni, George Smith i Will Brown, care aparin acestui colegiu.

Capitolul 4 Proiectarea bazelor de date relaionale 95 ID_STUDENT 0003 0004 STUDENT George Smith Will Brown POZITIE 9 1 COLEGIU IIT IIT NIVEL_COLEGIU 1 1

Tabelul 4.3 Anomalii la tergere - Exemplu

4.1.3 Anomalii de actualizare

O anomalie de actualizare apare atunci cnd modificnd datele unei entiti ntr-o singur locaie se va obine o inconsisten a datelor fa de alte date redundante existente n alt locaie din cadrul bazei de date. De exemplu, dac se modific nivelul colegiului la valoarea '1' n cazul studentului cu identificatorul ID_STUDENT 0003, atunci colegiul 'Fergusson' are un conflict de informaie, deoarece va avea dou nivele: 1 i 4. ID_STUDENT 0001 0003 STUDENT Ria Sinha George Smith POZITIE 6 9 COLEGIU Fergusson Fergusson NIVEL_COLEGIU 4 1

Tabelul 4.4 Anomalii de actualizare Exemplu n seciunile urmtoare, se vor sugera soluii pentru rezolvarea problemelor cauzate de redundana datelor.

4.2. Descompuneri
Normalizarea folosit n proiectarea unei baze de date relaionale presupune descompunerea schemei relaionale n relaii mai mici i mai simple astfel nct s se evite apariia redundanelor. Ideea este aceea de a interoga relaii mai mici pentru a obine exact aceleai informaii pe care le obineam anterior din schema relaional iniial. Schema Student din Figura 4.1 prezint un exemplu de normalizare pentru cazul de fa. n Figura 4.1, se prezint descompunerea schemei Student (a) n relaiile COLEGIU i STUDENT din (b) i (c). n acest fel, informaia referitoare la nivelul colegiului nu este pstrat n mod redundant, oferind doar o singur valoare pentru fiecare colegiu existent n baza de date. Colegiul de care aparine un student se alege prin intermediul unui atribut al relaiei STUDENT, astfel nct se poate restaura informaia existent n schema iniial.

Baze de date - Fundamente

96

Figura 4.1 Exemplu de normalizare Dac am face o descompunere sub forma: COLEGIU NIVEL_COLEGIU ID_STUDENT STUDENT POZITIE

se va constata c se va pierde informaie, deoarece nu mai putem afla din ce colegiu face parte un student. O alt posibilitate de descompunere ar fi: COLEGIU NIVEL_COLEGIU ID_STUDENT ID_STUDENT STUDENT POZITIE

n aceast situaie descompunerea va conduce la introducerea de mai multe ori a nivelului colegiului (obinem din nou redundan) pentru fiecare student introdus. Dei este necesar s realizm descompuneri ale schemelor relaionale pentru a evita apariia redundanelor, trebuie totui s fim ateni s nu pierdem informaia pe care o aveam n schema iniial. Acest lucru conduce la concluzia c este posibil s refacem schema relaional iniial pe baza relaiilor mai mici obinute la descompunere. Pentru a obine aceast reversibilitate a informaiilor ne vom folosi de noiunea de dependen funcional.

Capitolul 4 Proiectarea bazelor de date relaionale 97

4.3. Dependene funcionale

Dependena funcional (DF) reprezint un tip de constrngere de integritate care se bazeaz pe ideea de supercheie. Cu ajutorul dependenelor funcionale se identific dependenele dintre submulimile atributelor unei relaii. O definiie formal a dependenei funcionale este prezentat mai jos: Definiie: Fie schema relaional R, cu submulimile de atribute A i B. Se spune c avem o dependen funcional A B dac valorile din A au o valoare corespunztoare n B pentru fiecare instan r a relaiei R. Se spune c DF generalizeaz conceptul de supercheie deoarece valorile atributelor din mulimea A determin n mod unic valorile atributelor din mulimea B n cazul unei anumite relaii date R. Cu alte cuvinte, se mai poate spune c avem o dependen funcional A B atunci cnd valorile lui B sunt dependente funcional de A. Se spune funcional deoarece, asemntor conceptului de funcie, o dependen funcional ajut la realizarea unei corespondene dintre o mulime de valori ale atributului A i o alt mulime de valori ale atributului B. Pe relatia R exist o DF dac aceasta exist pentru toate instanele valabile r ale relaiei R. n acelai timp, pentru a verifica dac o instan r satisface o DF, trebuie s verificm dac fiecare tuplu al instanei r corespunde DF definite astfel nct A B (A determin pe B sau A implic B pentru fiecare rnd de date introduse n tabel la un anumit moment dat). Dependena funcional se citete sub forma A l determin pe B, B este dependent de A sau A implic B i se noteaz sub forma A B. Dac A1 B1 , A2 B2, A3 B3 An Bn, atunci vom scrie: A1 A2 A3. An B1 B2 B3 Bn Mai jos se poate vedea o instan a relaiei R ( A, B, C, D ) n care A D : A a1 a2 a3 a4 B b1 b2 b3 b3 C c1 c2 c3 c4 D d1 d1 d1 d2

Tabelul 4.5 Dependena funcional Una dintre DF de mai sus este A --- D. Se poate observa cu uurin de ce reciproca D -- A nu este adevrat. Dac se dau aceleai valori n D, valorile coerspunztoare din A se modific aa cum se vede n tuplurile (a1 , b1 , c1, d1) i (a2, b2, c2, d1).

Baze de date - Fundamente Exemplu

98

Folosind schema Student din primul exemplu, se va prezenta n Tabelul 4.7, o DF, ID_STUDENT COLEGIU valabil pe schema Student, n timp ce DF STUDENT COLEGIU nu este valabil pe schema relaiei deoarece pot exista studeni care au acelai nume, dar s fie n colegii diferite. ID_STUDENT 0001 0002 0003 0004 STUDENT Ria Sinha Vivek Kaul George Smith Will Brown POZITIE 6 15 9 1 COLEGIU Fergusson PICT IIT IIT

Tabelul 4.7 Exemplu de dependen funcional Urmtoarea mulime de DF este adevrat: {ID_STUDENT COLEGIU , ID_STUDENT STUDENT , ID_STUDENT STUDENT COLEGIU ID_STUDENT STUDENT POZITIE} Dependene funcionale triviale o dependen funcional care este valabil pentru toate valorile unui atribut al unei relaii date este numit dependen funcional trivial. Exemplu (prenume, nume) prenume n general, o dependen funcional A B este trivial dac B este o submulime a lui A, ceea ce nseamn c B este inclus n A (partea dreapt este o parte a prii stngi). n proiectul unei baze de date suntem interesai, de fapt, mai mult de dependenele funcionale netriviale, deoarece acestea ajut la determinarea constrngerilor de integritate ale unei relaii n timp ce dependenele funcionale triviale sunt evidente i vor fi verificate n orice situaie.

4.4 Proprietile dependenelor funcionale

Pentru a determina toate dependenele funcionale care exist ntr-o mulime dat de dependene funcionale, se va folosi o proprietate important a DF numit Mulimea de nchidere a dependenelor funcionale. Mulimea de nchidere a dependenelor funcionale Toate dependenele funcionale care sunt deduse dintr-o mulime de dependene funcionale S, alctuiesc mulimea de nchidere a dependenelor funcionale, notat cu, S+. Mulimea de nchidere reprezint, n esen, setul complet de valori ce pot fi determinate pe baza unui set cunoscut de valori

Capitolul 4 Proiectarea bazelor de date relaionale 99 din cadrul unei relaii cu ajutorul dependenelor sale funcionale. Acest lucru conduce la faptul c orice instan r a relaiei R care satisface mulimea dat de dependene funcionale, S, va satisface i mulimea de nchidere a dependenelor funcionale, S+. n subseciunile urmtoare se va parcurge setul de reguli necesar pentru calculul mulimii de nchidere a dependenelor funcionale.

4.4.1 Axiomele lui Armstrong

Axiomele lui Armstrong mai sunt cunoscute i sub denumirea de Reguli de inferen i ne ajut s deducem toate dependenele funcionale ale unei mulimi de dependene funcionale date. Exist trei reguli de inferen: 1. Reflexivitatea: Dac B este o submulime a atributului A, atunci A B. (dependen funcional trivial) 2. Augmentarea: Dac A B iar C este un alt atribut, atunci AC BC Prin aplicarea reflexivitii se obine c AC B. 3. Tranzitivitatea: Dac A B i B C, atunci A C. Suplimentar, mai exist i alte reguli care pot fi dovedite cu ajutorul celor 3 axiome ce se folosesc pentru a uura crearea mulimii de nchidere a dependedenelor funcionale i care sunt cunoscute sub denumirea de reguli adiionale. 1. Reuniunea: Dac A B i A C, atunci A BC. 2. Descompunerea: Dac A BC, atunci A B i A C. Axiomele lui Armstrong sunt solide i complete. Ele genereaz numai dependene funcionale n mulimea de nchidere a dependenelor funcionale, S+ i produc mulimea complet a dependenelor funcionale din S+.

4.4.2 Determinarea mulimii de nchidere a atributelor

Exist o metod alternativ de a obine mulimea de nchidere a dependenelor funcionale pornind de la o dependen funcional dat. Aceasta poate fi folosit i pentru a afla dac o mulime dat de atribute reprezint o supercheie a unei relaii. Mulimea de nchidere a atributelor n cazul unui atribut, A, reprezint mulimea tuturor atributelor din cadrul unei relaii R care pot fi determinate n mod unic de ctre A, pe baza unor dependene funcionale date. Obs: Dndu-se inchidere(A), A+ fiind mulimea care conine toate atributele relaiei R, se poate spune c atributul A este o supercheie a relaiei R. Calcul Fie o relaie R care are o mulime de atribute. Se poate calcula mulimea de nchidere a

Baze de date - Fundamente atributului A, ce va fi numit inchidere(A) astfel: 1. Mulimea iniial inchidere(A) = A

100

2. Pentru fiecare dependen funcional dat, dac A B, atunci se adaug B la inchidere(A), ceea ce nseamn, inchidere(A) U B 3. Pentru orice submulime a lui A, (fie C o submulime a lui A), A C (dependen funcional trivial) i dac C D, dar D nu este o submulime a lui A, atunci se adaug D mulimii inchidere(A) 4. Se repet pasul 3 pn nu mai rmn atribute ce pot fi adugate mulimii inchidere(A) Exemplu Fie o relaie R (A, B, C, D, E) cu dependenele funcionale date A B, B DE i D C Calcul Pas 1. inchidere(A) = A Pas 2. A B, adic inchidere(A) = A U B, care se noteaz cu AB Pas 3. Prima iteraie: B DE, dar B a devenit o submulime a inchidere(A), adic inchidere(A) = ABDE A doua iteraie: AD C, dar D a devenit o submulime a mulimii inchidere(A), ns C nu este o submulime a mulimii inchidere(A), deci inchidere(A), A+ = ABDEC. n mod asemntor, inchidere(B), B+ = BDEC inchidere(C), C+ = C inchidere(D), D+= DC inchidere(E), E+= E

4.4.3 Concluzie
Dependenele funcionale ajut la descompunerea corect a relaiilor astfel nct valorile aflate n legtur s poat fi pstrate ntr-un singur tabel. n momentul n care datele sunt inserate n baza de date, acestea trebuie s se conformeze constrngerilor specificate. n afara constrngerilor de integritate, datele mai trebuie s se conformeze i dependenelor funcionale. Proprietile dependenelor funcionale ajut la alctuirea mulimii de nchidere a dependenelor funcionale, astfel nct s obinem o formul structurat cu ajutorul creia s deducem o mulime exhaustiv de constrngeri pentru a modela cu eficien depdendenele din lumea real. Axiomele lui Armstrong ne sunt de mare ajutor prin fapul c sunt solide i complete. nchiderea atributelor pentru o mulime dat de dependene funcionale nu ofer doar o

Capitolul 4 Proiectarea bazelor de date relaionale 101 alternativ la calculul mulimii de nchidere a dependenelor funcionale, dar ajut i la identificarea supercheii unei relaii verificnd dac o dependen funcional dat, X Y aparine mulimii de nchidere a dependenelor funcionale.

4.5 Forme normale

Normalizarea reprezint o procedur folosit la proiectarea bazelor de date relaionale prin care se transform schemele relaionale ntr-o form mult mai convenabil. Scopul este acela de eliminare a redundanelor din cadrul relaiilor i a problemelor generate de ctre acestea, numite anomalii de inserare, de tergere i de actualizare. Formele normale trec dintr-una n alta obinndu-se n final un proiect optimizat. Normalizarea este un proces care se face pas cu pas, la fiecare pas producndu-se o transformare a schemelor relaionale ntr-o form normal superioar. Fiecare form normal conine toate formele normale anterioare pe care se fac optimizri.

4.5.1 Prima form normal (1FN)

O relaie se consider c se afl n prima forma normal dac toate atributele sale se afl la nivel indivizibil sau atomic. Nivelul atomic al valorilor asigur faptul c nu exist grupuri repetitive. Acest lucru este necesar deoarece sistemul de management al bazelor de date relaionale nu poate s pstreze o valoare dect la intersecia unui rnd cu o coloan. Grupurile repetitive se refer la faptul c s-ar putea pstra mai multe valori la intersecia unui rnd cu o coloan, iar un tabel n care s-ar ntmpla acest lucru nu ar mai putea fi considerat relaional. C. J. Dates extinde aceast definiie n [4.8], Un tabel se afl n prima form normal dac i numai dac satisface urmtoarele condiii: Nu exist o ordonare de sus n jos a rndurilor. Nu exist o ordonare de la stnga la dreapta a coloanelor. Nu exist rnduri duplicat. Fiecare intersecie de rnd cu coloan conine exact o singur valoare din domeniul specificat (i nimic altceva). Toate coloanele sunt de tip obinuit [rndurile nu au componente ascunse cum ar fi identificatori de rnd, identificatori de obiecte sau amprente de timp].

O coloan care pstreaz, de exemplu, rudele din cadrul unei familii nu se afl la nivel atomic, deoarece se face referire la o mulime de nume. n acelai timp, coloana ce conine identificatorul unui angajat nu mai poate fi desfcut n valori subordonate, astfel nct aceasta se afl la nivel atomic. Exemplu S urmrim tabelul de mai jos care prezint relaia Filme. n aceast relaie, combinaia de atribute {Titlu, An} alctuiete o cheie candidat.

Baze de date - Fundamente Titlu An Tip Regizor Regizor_D N 05/06/1956 Aparitie Actori

102

Notting Hill

1999

Romantic

Roger M

30

Hugh G Rhys I

Lagaan

2000

Drama

Ashutosh G

15/02/1968

50

Aamir K Gracy S

Tabelul 4.8 Relaia denormalizat Filme Relaia de mai sus nu se afl n forma normal 1 nefiind nici mcar strict relaional. Acest lucru se ntmpl deoarece apare atributul Actori ce conine valori care pot fi descompuse n continuare. Pentru a o transforma ntr-o relaie n forma normal 1, vom descompune tabelul n relaiile Film i Distributie aa cum se vede din Figura 4.2 de mai jos

Figura 4.2 Transformarea n prima form normal. Exemplu de relaie n forma normal 1 n Figura 4.2, la intersecia dintre un rnd i o coloan a tabelului se afl acum o valoare la nivel atomic care nu se mai poate descompune n continuare, astfel nct se poate spune c relaia se afl n forma normal 1, presupunnd faptul c numele actorilor nu se descompun n nume i prenume.

Capitolul 4 Proiectarea bazelor de date relaionale 103

4.5.2 Forma normal 2 (2FN)

O relaie se afl n forma normal 2 dac se afl n forma normal 1 i fiecare atribut care nu face parte din cheie depinde de ntreaga cheie, nu doar de o parte a acesteia. Din definiia de mai sus se poate trage concluzia c o relaie care are cheia alctuit dintrun singur atribut se afl cu siguran n forma normal 2. Exemplu Pentru a normaliza mai departe relaia cu filme de mai sus, se vor elimina dependenele referitoare doar la o parte a cheii. n acest exemplu, APARITIE depinde de AN. Acest lucru nseamn c AN APARITIE dar cheia candidat este {TITLU, AN}. Astfel pentru a ajunge la forma normal 2, vom descompune n continuare tabelele de mai sus n relaia FILME, relaia APARITIE i relaia DISTRIBUTIE aa cum se prezint n Figura 4.3.

Figura 4.3 Trecerea n cea de-a doua form normal n figura de mai sus, fiecare atribut care nu face parte din cheie este acum depdendent de ntreaga cheie i nu doar de o parte a acesteia. Astfel, descompunerea de mai sus conduce la cea de-a doua form normal.

4.5.3 Forma normal 3 (3NF)

O relaie se afl n forma normal 3 dac se afl n forma normal 2 i nu exist atribut care nu este sau nu face parte din cheie care s depind tranzitiv de un alt atribut care nu face parte din cheie. Acest lucru nseamn faptul c fiecare atribut depinde direct de cheia primar i nu printr-o relaie tranzitiv n care un atribut Z poate depinde de un atribut Y, care nu este cheie iar Y depinde de cheia primar X. Tranzitiv nseamn, aa cum am vzut anterior, dac XY i Y Z, atunci XZ.

Baze de date - Fundamente

104

Acest lucru nseamn c o relaie aflat n forma normal 3 are atributele care nu fac parte din cheie mutual independente. Exemplu Pentru a normaliza n continuare relaia aflat n forma normal 2, adic pentru a o aduce n forma normal 3, se vor elimina toate dependenele tranzitive. n Figura 4.3, REGIZOR_DN depinde de REGIZOR, adic REGIZOR REGIZOR_DN. Dar cheia primar este {TITLU, AN}. n cazul de fa {TITLU, AN} REGIZOR i REGIZOR REGIZOR_DN adic exist o dependen tranzitiv. Din acest motiv, pentru a ajunge la forma normal 3 trebuie descompuse n continuare tabelele de mai sus n relaia FILME, relaia REGIZOR, relaia APARITIE i relaia DISTRIBUIE aa cum se vede din Figura 4.4.

Figura 4.4 Transformarea n forma normal 3 n figura de mai sus, fiecare atribut care nu face parte din cheie este independent mutual i dependent doar de cheie n totalitate. Astfel, descompunerea de mai sus ne-a adus n forma normal 3.

4.5.4 Forma normal Boyce-Codd (FNBC)

Forma normal Boyce-Codd este o versiune mai restrictiv a formei normale 3 care se aplic relaiilor n care pot exista chei suprapuse.

Capitolul 4 Proiectarea bazelor de date relaionale 105 Se spune c o relaie se afl n forma normal Boyce-Codd dac se afl n forma normal 3 i fiecare dependen funcional netrivial a acestei relaii are o cheie candidat ca determinant, adic pentru fiecare X Y, X este o cheie. Exemplu S considerm relaia Sali predare la un colegiu, aa cum se prezint n Tabelul 4.9 de mai jos. Se presupune c fiecare profesor pred o singur disciplin. Chei: {DISCIPLINA, ZI_PREDARE}, {ZI_PREDARE, PROFESOR} DISCIPLINA Grafic Baze de date Java Grafic Java ZI_PREDARE Luni Luni Miercuri Mari Joi PROFESOR Dr. Arindham Singh Dr. Emily Jose Dr. Prasad Dr. Arindham Singh Dr. George White

Tabelul 4.9 Relaia SALI PREDARE n relaia de mai sus, nu exist valori care s nu se afle la nivel atomic, motiv pentru care relaia se afl n forma normal 1. Toate atributele fac parte din cheie, motiv pentru care relaia este n formele normale 2 i 3. n relaia de mai sus exist o dependen funcional Pofesor Disciplina, dar atributul Profesor nu alctuiete singur cheia, motiv pentru care relaia nu se afl n forma normal FNBC. Pentru a o transforma n FNBC, se va descompune n relaiile EXPERTI_DOMENIU i GRAFIC_PREDARE aa cum se vede din Figura 4.5.

Figura 4.5 Transformarea n forma normal Boyce-Codd

Baze de date - Fundamente

106

Relaia din Tabelul 4.9 este descompus acum n FNBC pe baza dependenei funcionale netriviale Profesor Disciplina. Profesorul este acum cheie n Figura 4.5 (a) Relatia EXPERTI.

4.6 Proprieti ale descompunerii

n cadrul acestei seciuni vom reveni la conceptul de descompunere pentru a trece n revist cteva dintre proprietile de care avem nevoie. Normalizarea reprezint descompunerea unei scheme a unei relaii n relaii mai mici astfel nct fiecare dintre atribute s fie prezent n cel puin una dintre noile relaii, realiznd astfel un proiect optimizat. Scopul este acela de a elimina redundanele.

4.6.1 Pierderea de informaie prin normalizare i evitarea acesteia

Descompunerea unei relaii R n relaiile X i Y se face fr pierdere de informaie dac nu se pierde, dup descompunere, nici o informaie din relaia iniial. Cu alte cuvinte, relaia iniial poate fi refcut din relaiile obinute la descompunere fr a fi nevoie s se adauge rnduri suplimentare. Prin urmare, dac rezultatul descompunerii conduce la pierdere de informaie fa de relaia iniial R atunci descompunerea nu este corect. Fie R o relaie care are o dependen funcional F i care se descompune n R1 i R2. Descompunerea este fr pierdere de informaie dac una dintre urmtoarele dependene funcionale este adevrat pentru relaiile R1 i R2: R1 R2 R1 sau R1 R2 R2

Mai simplu, dac atributele comune din relaiile R1 i R2 (adic, R1 R2) alctuiesc o supercheie fie pentru R1 fie pentru R2, atunci relaia iniial R nu a fost supus unei pierderi de informaie prin descompunere n relaiile R1 i R2. O proprietate esenial a descompunerii n proiectarea bazelor de date relaionale este aceea c nu este permis ca aceasta s se fac cu pierdere de informaie. O reunire n R, fr pierdere de informaie, a relaiilor X i Y obinute prin descompunere conduce la lipsa pierderii de informaie, nefiind nevoie s se adauge informaie suplimentar ajuttoare. Exemplu Fie relaia ANGAJATI: ID_ANG NUME_ANG EXP ID_DEPT NUME_DEPT

O descompunere fr pierdere de informaie a relaiei de mai sus este:

ID_DEPT

NUME_DEPT

ID_ANG

NUME_ANG

EXP

ID_DEPT

Relaia DEPARTAMENT

Relaia ANGAJAT

Capitolul 4 Proiectarea bazelor de date relaionale 107 Prin reunirea relaiilor de mai sus, (DEPARTAMENT) (ANGAJAT) = ID_DEPT iar ID_DEPT {ID_DEPT, NUME_DEPT}, ceea ce nseamn faptul c ID_DEPT este o supercheie a relaiei DEPARTAMENT iar descompunerea se face fr pierdere de informaie. O descompunere cu pierdere de informaie pentru situaia de mai sus ar putea fi: ID_DEPT NUME_DEPT NUME_ANG ID_ANG NUME_ANG EXP

Relaia DEPARTAMENT

Relaia ANGAJAT

Prin reunirea relaiilor de mai sus, (DEPARTAMENT) (ANGAJAT) = NUME_ANG care nu este o supercheie nici n tabelul cu departamente nici n cel cu angajai, motiv pentru care descompunerea se face cu pierdere de informaie. n exemplul anterior, NUME_ANG nu se tie dac este unic, motiv pentru care nu se poate spune cu siguran pentru ce departament lucreaz un anumit angajat. Acest lucru conduce la pierderea de informaie.

4.6.2 Pstrarea dependenelor la descompunere

Prin descompunerea relaiei R n relaiile X i Y se pstreaz toate dependenele funcionale care exist separat pe X i Y, iar la reunire, se obin toate dependenele funcionale care exist n mulimea de nchidere a dependenelor funcionale F+ din relaia iniial, R. Pe o proiecie a unei mulimi de dependene funcionale a relaiei R, F reprezint o mulime a atributelor acesteia, iar X reprezint mulimea dependenelor funcionale de forma C D n care C i D aparin lui X. Acest lucru se noteaz cu Fx. n acest fel o descompunere a relaiei R n relaiile X i Y i pstreaz dependenele dac reuniunea mulimilor de nchidere a dependenelor funcionale din X i Y este echivalent cu mulimea de nchidere a dependenelor funcionale F+ existente n R. Acest lucru nseamn c prin Fx U Fy se obine F+ n care Fx reprezint mulimea dependenelor funcionale din F+ care trebuie verificate numai n X, iar Fy reprezint mulimea dependenelor funcionale care se verific doar n Y. Acest lucru conduce la ideea c avnd o descompunere cu pstrare de dependene, dac toate constrngerile se verifica pe tabelul obinut prin descompunere, nu mai trebuie s facem verificarea i pe tabelul iniial. Descompunerea cu pstrare de dependene nu presupune i descompunerea fr pierdere de informaie la cuplare i invers. n timp ce jonciunea fr pierdere de informaie este obligatorie la descompunere, pstrarea dependenelor nu este ntotdeauna posibil.

4.7 Acoperirea minimal

Acoperirea minimal, Fc reprezint cea mai mic mulime de dependene funcionale astfel nct mulimea de nchidere a dependenelor funcionale att a acoperirii minimale ct i

Baze de date - Fundamente

108

mulimii date de dependene funcionale F ale relaiei R sunt echivalente. Acest lucru conduce la F+ = Fc+ Scopul folosirii acoperirii minimale este acela de a face o verificare mai uoar a constrngerilor la introducerea datelor ntr-un sistem de gestiune a bazelor de date relaionale. Datele introduse n cadrul tabelelor trebuie s satisfac constrngerile care exist ntr-o anumit relaie. Folosind acoperirea minimal, vom face un numr minim de verificri n raport cu mulimea iniial de dependene funcionale care exist ntr-o relaie i, prin urmare, verificarea constrngerilor este mult mai economic. Acoperirea minimal, Fc provine din mulimea F astfel nct: 1. Partea dreapt a fiecrei dependene funcionale din acoperirea minimal este un singur atribut. 2. Dac se elimin un atribut din partea stng a fiecrei dependene funcionale, nchiderea acoperirii minimale se schimb. 3. Eliminarea unei dependene funcionale din acoperirea minimal produce modificarea nchiderii acoperirii minimale. Acoperirea minimal a unei mulimi date de dependene funcionale nu este unic. Atribute externe. Pentru fiecare care exist n F, se definete un atribut extern ca fiind acel atribut care dac este eliminat din i nu produce modificarea mulimii de nchidere a dependenelor funcionale. Prin urmare, dac se elimin A din n Fc, se obine ( Fc { } ) U ( { A} ) iar prin eliminarea lui B din n Fc se obine ( Fc { } ) U ( { B } ) . Pentru a calcula acoperirea minimal Fc, se parcurg paii: 1. Prin folosirea regulilor de descompunere puse la dispoziie prin axiomele lui Armstrong se descompune fiecare dependen funcional pentru a obine un singur atribut n partea dreapt. 2. Se reduce partea stng a fiecrei dependene funcionale la Fc eliminnd toate atributele externe. 3. Se folosesc axiomele lui Armstrong pentru a reduce ct mai mult dependenele funcionale redundante rmase n acoperirea minimal astfel nct inchiderea sa s nu se modifice, ceea ce nseamn c trebuie s se menin egalitatea F+ = Fc+ Exemplu Fie relaia R (A, B, C, D) cu urmtoarea mulime de dependene funcionale F: A BC, B C, A B,

Capitolul 4 Proiectarea bazelor de date relaionale 109 AB C, AC D Pentru a determina acoperirea minimal Fc se urmeaz paii prezentai antreior, modificrile fiind marcate cu litere ngroate: Pas 1: Se reduce fiecare dependen funcional din cadrul mulimii, astfel nct partea dreapt a expresiei s conin un singur atribut (folosind descompunerea: Dac X YZ, atunci X Y i X Z). A B, B C, A B, AB C, AC D Pas 2: Reducerea prii stngi a expresiei pentru a elimina atributele externe, dac exist. Avem B C i AB C deci A este extern n AB C. Se nlocuiete cu B C care deja exist n mulimea dependenelor funcionale. Asemntor, A C i AC D astfel nct C este extern n AC D. Se nlocuieste cu A D Astfel mulimea minimal devine: A B, B C, A B, B C, AD Pas 3: Eliminarea dependenelor funcionale redundante Avem duplicatele A B i B C. Pe baza acestora se obine relaia tranzitiv: A C, Dup care mulimea minimal ne conduce la rezultatul: A B, B C, AD Acoperirea minimal Fc = { A B , B C, A D }. A C, A C,

Baze de date - Fundamente

110

4.8 Fuziunea schemelor n forma normal 3

Fuziunea schemelor n forma normal 3 este un concept care se aplic abordnd tehnica de jos-n-sus i este utilizat pentru a obine o cuplare fr pierdere de informaie i cu pstrarea depdendenelor la descompunerea unei relaii n forma normal 3. Procesul este unul de tip de jos-n-sus deoarece se pornete cu realizarea mulimii minime de dependene funcionale, crendu-se schemele obinute prin descompunere n mod direct prin adugarea cte unei scheme pe rnd n list, obinndu-se astfel relaiile n forma normal 3. Schemele obinute prin descompunere se bazeaz pe acoperirea minimal a unei mulimi date de dependene funcionale existente ntr-o relaie R. Dup aceea se verific dac schemele obinute nu pierd, prin descompunere, informaie la reunirea acestora. Dac se pierde informaie, se adaug o alt schem care conine cheia candidat astfel nct s se rezolve problema descompunerii n forma normal 3. Procedura folosit pentru descompunerea relaiei R n R1, R2 ,R3 ..... , Rn este: 1. Pentru fiecare dependen funcional, din acoperirea minimal Fc , dac nici una dintre schemele R1, R2 ,R3 ..... , Rn nu conine , se adaug Ri = ( , ). 2. Pentru fiecare relaie Ri din lista R1, R2 ,R3 ..... , R n se verific dac cel puin una dintre aceste relaii conine o cheie candidat din R. Dac nu conine, se adaug o alt relaie mulimii schemelor obinute prin descompunere, R n +1 , astfel nct R n +1 s fie cheie candidat n R.

4.9 Descompunerea n forma normal 3

Descompunerea n forma normal 3 se poate realiza folosind metoda se sus-n-jos prin procesul de normalizare n care o relaie este descompus pe baza definiei formei normale 3, dup care se obine asigurarea c nu s-a pierdut informaie i s-au pstrat dependenele, verificndu-se relaiile obinute. Seciunea 4.5.3 prezint aceast procedur. n aceast seciune vom prezenta un exemplu de descompunere n forma normal 3 a schemelor relaionale urmnd tehnica de abordare de jos-n-sus, folosind algoritmul explicat anterior. Exemplu Se pornete de la schema relaional Carte(nume_carte, autor, autor_dn, vnzari, evaluare) care are urmtoarea mulime de dependene funcionale: (nume_carte, autor) vanzari autor autor_dn vanzari evaluare i cheia candidat {nume_carte, autor} Folosind algoritmul de fuziune descris n seciunea anterioar, se descompune relaia Carte n scheme aflate n forma normal 3 astfel:

Capitolul 4 Proiectarea bazelor de date relaionale 111 Pas 1: Mulimea de dependene funcionale de mai sus reprezint o acoperire minimal. Pas 2: Pe baza depdendenelor funcionale date se obin relaiile: (nume_carte, autor, vanzari) (autor, autor_dn) (vanzari, evaluare) Pas 3: Deoarece relaia (nume_carte, autor, vanzari) conine cheia candidat, nu mai trebuie adugate alte relaii acestor scheme. Descompunerea n forma normal 3 conduce la relaiile: (nume_carte, autor, vanzari) (autor, autor_dn) (vanzari, evaluare)

4.10 Forma normal 4 (4FN)

Forma normal 4 poate fi neleas pe baza dependenelor multivaloare. O relaie se afl n forma normal 4 atunci cnd n acea relaie nu exist dect o singur dependen multivaloare. Pentru a nelege acest lucru s vedem ce nseamn o dependen multivaloare.

4.10.1 Dependene multivaloare

Se spune c un atribut A multi-determin un alt atribut B atunci cnd fiecrei valori a lui A, i corespund mai multe valori n B. Dependenele multivaloare (DMV) se noteaz sub forma A B. Aceasta nseamn c A l multi-determin pe B, B este multi-dependent de A sau A sgeat dubl ctre B. O relaie se afl n forma normal 4 atunci cnd nu exist dou sau mai multe DMV n relaia respectiv, iar atributele multivaloare sunt mutual independente. Din punct de vedere formal o relaie R(A,B,C) se afl n forma normal 4 dac n respectiva relaie exist o DMV astfel nct A B i A C, iar B i C sunt independente, adic, de exemplu, C nu este o submulime a lui B. Exemplu Fie relaia inghetata prezentat n Tabelul 4.10. Vanzator Amul Amul Tip_I Scoop Softy Aroma_I Vanilie Vanilie

Baze de date - Fundamente Amul Amul Baskin Robbins Baskin Robbins Baskin Robbins Baskin Robbins Baskin Robbins Baskin Robbins Scoop Softy Scoop Sundae Scoop Sundae Scoop Sundae Ciocolata Ciocolata Ciocolata Ciocolata Capsuni Capsuni Unt i zahr brun Unt i zahr brun

112

Tabelul 4.10 Relaia inghetata aflat n forma normal FNBC Relaia de mai sus se afl n forma normal FNBC, astfel c toate atributele sunt parte a cheii candidat. Exist urmtoarele dependene multivaloare: Vanzator Tip_I Vanzator Aroma_I n acest fel, n relaia de mai sus, exist o serie de redundane ce conduc ctre apariia de anomalii. Din acest motiv, se aduce relaia la forma normal 4, aa cum se prezitn n Figura 4.6.

Figura 4.6 Relaii n forma normal 4 Relaiile din Figura 4.6 sunt descompuse n forma normal 4 deoarece nu exist dect o singur dependen multivaloric (DMV) mutual independent n relaia ce rezult la descompunere.

Capitolul 4 Proiectarea bazelor de date relaionale 113

4.11 Alte forme normale

Mai exist alte trei forme normale suplimentare. Acestea sunt denumite forma normal 5 [4.10], forma normal cu dependene de domeniu/cheie (FNDC) [4.11] i forma normal 6 [4.12, 4.13]. Aceste forme sunt folosite n cazuri speciale, motiv pentru care nu vor fi discutate aici. Pentru a afla mai multe informaii despre aceste forme normale se pot urmri referinele bibliografice specificate.

4.12 Studiu de caz cu sistemul de management al unei biblioteci Partea 2 din 3

n aceast parte a studiului de caz ne vom ocupa de realizarea modelului logic al sistemului care pornete de la modelul conceptual. Modelul logic are rolul de validare a modelului conceptual folosind tehnica normalizrii, n care relaiile sunt verificate pentru a vedea dac ndeplinesc o serie de reguli numite forme normale. Modelul logic este necesar pentru a elimina redundanele pe care modelul conceptual nu le poate detecta (n modelul conceptual nu exist noiunea de redundan). Tabelul urmtor prezint corespondena dintre modelul conceptual i modelul logic din punct de vedere al folosirii termenilor: Concept din modelarea conceptual Nume de tip de entitate Tip de entitate Entitate Atribut Tip de relaie Concept din modelarea logic Variabil de tip relaie, R Relaie Tuplu Atribut, A1, A2, etc. O pereche cheie primarcheie extern Cheie primar

Identificator unic

n exemplul nostru, transformarea modelului conceptual n model logic va nsemna modificarea schemei dup cum urmeaz (cheia primar este subliniat) CITITOR = {ID_CITITOR, NUME, PRENUME, EMAIL, TEL, ADRESA, ID_CARTE, DATA_IMPRUMUT, DATA_RETUR} AUTOR = {ID_AUTOR, NUME, PRENUME, EMAIL, TEL, ADRESA) CARTE = {ID_CARTE, TITLU, EDITIE, AN, PRET, ISBN, PAGINI, INTERVAL, DESCRIERE} COPIE = {ID_CARTE, STARE}

Baze de date - Fundamente LISTA_AUTOR = {ROL}

114

Pentru a pstra tipurile de relaii iniiale n vederea respectrii integritii datelor, i pentru a evita pierderea de informaie, trebuie introduse cheile externe corespunztoare, motiv pentru care relaiile devin dup cum urmeaz (cheia extern este subliniat cu linie ntrerupt):

CITITOR = {ID_CITITOR, ID_COPIE, NUME, PRENUME, EMAIL, TEL,

ADRESA, DATA_IMPRUMUT, DATA_RETUR}

AUTOR = {ID_AUTOR, NUME, PRENUME, EMAIL, TEL, ADRESA} CARTE = {ID_CARTE, TITLU, EDITIE, AN, PRET, ISBN, PAGINI,
INTERVAL, DESCRIERE}

COPIE = {ID_COPIE, ID_CITITOR, ID_CARTE, STARE} LISTA_AUTOR = {ID_AUTOR, ID_CARTE, ROL}

Acum s spunem c, aa cum a fost stabilit cu ajutorul regulilor de domeniu, un cititor poate mprumuta doar o singur carte pe zi. Din acest motiv relaia CITITOR trebuie s aib cheia primar alctuit din atributele: {ID_CITITOR, ID_COPIE, DATA_IMPRUMUT}. S verificm acum fiecare relaie pentru a vedea dac respect regulile formelor normale. Pentru a valida dac o relaie se afl n prima form normal trebuie s ne asigurm c nu exist gruprui repetitive, deci atributele se afl la nivel atomic. n acest exemplu nu toate atributele se afl la nivel atomic, cum ar fi ADRESA din relaia CITITOR i din relaia AUTOR. Acest atribut se poate descompune n {ADRESA, ORAS, TARA}. n acelai timp, se observ faptul c exist grupuri repetitive n relaia CITITOR, deoarece un cititor poate mprumuta mai multe cri n timp, astfel c relaia CITITOR trebuie descompus n CITITOR i IMPRUMUT:

CITITOR = {ID_CITITOR, ID_COPIE, NUME, PRENUME, EMAIL, TEL,

ADRESA}

IMPRUMUT = {ID_CITITOR, ID_COPIE, DATA_IMPRUMUT, DATA_RETUR}

Dup descompunere se constat faptul c toate relaiile se afl n forma normal 1. S vedem n continuare dac ne aflm i n forma normal 2. Regula formei normale 2 spune c fiecare atribut al unei relaii trebuie s depind de ntreaga cheie i nu doar de o parte a acesteia. n exemplul nostru fiecare relaie care are o cheie primar alctuit dintrun singur atribut, deci se afl n mod automat n forma normal 2, astfel nct nu trebuie verificate dect relaiile la care cheia primar este o cheie compus. Verificnd aceste relaii se constat faptul c att DATA_IMPRUMUT ct i DATA_RETUR depind de ambele atribute ID_CITITOR i ID_COPIE, iar ROL depinde de ID_AUTOR i de

Capitolul 4 Proiectarea bazelor de date relaionale 115 ID_CARTE, motiv pentru care se concluzioneaz c toate relaiile se afl n forma normal 2. Pentru forma normal 3 trebuie verificat dac exist un atribut care nu face parte din cheie care s depind de un alt atribut care nu face parte din cheie. n exemplul nostru, nu exist o astfel de situaie, motiv pentru care se constat c toate relaiile se afl n forma normal 3 i c nu exist motiv pentru continuarea descompunerii. Acum ne putem ntoarce la modelul conceptual i putem face modificrile necesare. Se va crea tipul de entitate IMPRUMUT i se va crea tipul de relaie corespunztor, stabilind cheia extern. Cu ajutorul unui instrument cum ar fi InfoSphere Data Architect (IDA) vom realiza foarte uor astfel de modificri care sunt prezentate sintetic n figura de mai jos n care se vede modelul logic final:

Figura 4.7 Modelul logic final O alt abordare ce poate fi la fel de corect este i aceea n care se pornete cu modelul logic n care se introduc toate relaiile i atributele ce au fost identificate n partea I a studiului de caz (vezi capitolul precedent) dup care se trece la rafinarea modelului prin introducerea cheilor primare i normalizarea relaiilor. La final trebuie s se ajung la acelai model logic de mai sus. Partea a III-a a acestui studiu de caz continu n capitolul 5, unde vom arta felul n care se transform modelul logic n model fizic.

4.13 Rezumat
n cadrul acestui capitol a fost descris felul n care se modeleaz obiectele din lumea real,

Baze de date - Fundamente

116

astfel nct s se obin tabelele din cadrul bazei de date relaionale, proprietile ce trebuie asociate acestor obiecte pentru a deveni coloane n aceste tabele, precum i asocierile care se stabilesc ntre tabele pentru a fi ct mai aproape de ceea ce se ntmpl n realitate. Existena datelor redundante n cadrul acestor tabele provoac o serie de probleme, cum ar fi anomaliile de inserare, de actualizare sau de tergere, motiv pentru care trebuie revizuite schemele relaionale cu scopul declarat de a obine o redundan ct mai mic posibil. n acest scop s-au folosit formele normale cu ajutorul crora se verific tabelele bazei de date, astfel nct procesul de normalizare s ofere un proiect optim al bazei de date relaionale. Fiecare form normal superioar provine din una anterioar. Dependenele funcionale dintre atributele unui tabel ne ajut la realizarea descompunerii acestor tabele. Proprietile dependenelor funcionale ale atributelor stabilite prin axiomele lui Armstrong i mulimea de nchidere fac ca activitatea s devin mai eficient pentru a putea efectua verificri ct mai economic posibil. Relaiile trebuie descompuse n aa fel nct s nu se piard informaie i s se pstreze dependenele existente iniial. Prin parcurgerea acestui capitol vei putea face un proiect complet al unei baze de date relaionale, astfel nct toate informaiile existente n realitate s poat fi modelate n cadrul bazei de date, realizndu-se totodat i optimizrile necesare pentru a gestiona eficient spaiul de stocare, fr a avea redundane i cu posibilitatea extragerii cu uurin a datelor din baza de date.

4.14 Exerciii
1. S se determine atributele din mulimea de nchidere pentru fiecare atribut din relaia dat R(A,B,C,D,E) pentru care mulimea dependenelor funcionale este: { AB C , A DE , B D, A B , EC }

S se identifice n acelai timp i supercheia. 2. n ce form normal se afl relaia urmtoare? Comanda ( ID_PRODUS, ID_CLIENT , PRET, CANTITATE, TIP_COMANDA) n care (ID_PRODUS, ID_CLIENT) reprezint cheia candidat, iar TIP_COMANDA are valorile: lux dac preurile sunt peste 1000$ i obinuit dac preurile sunt sub 1000$. S se normalizeze n continuare relaia pentru a o aduce la forma normal 3.. 3. S se determine acoperirea minimal a relaiei R (A, B, C, D) pe baza mulimii de dependene funcionale: AB C, BC, ACD 4. S se aduc relaia CARTE_BIBLIOTECA ( ID_CARTE, NUME_CARTE, AUTOR, SUBIECT) la forma normal 3 fr a se pierde informaie sau dependenele

Capitolul 4 Proiectarea bazelor de date relaionale 117 existente. 5. S se determine mulimea de nchidere a dependenelor funcionale F+ pentru relaia R(A,B,C,D,E) care are urmtoarea mulime de dependene funcionale { AB C, A DE, B D, A B, EC }

4.15 ntrebri recapitulative

1. S se arate c urmtoarea descompunere a unei relaii despre organizarea unei nuni se face fr pierdere de informaie sau dependene: COMANDA (ID_CLIENT, MIREASA, MIRE, BUGET) TIP_NUNTA (BUGET, TIP_NUNTA) 2. Fie relaia Telefon mobil: MOBIL N93 Diamond N97 MotoSlim 3315 ZN50 BRAND Nokia HTC Nokia Motorola Nokia Motorola LOCATIE_BIROU New Delhi Hyderabad New Delhi Mumbai New Delhi Mumbai

Relaia TELEFON_MOBIL Care dintre urmtoarele comenzi de modificare n cazul acestei relaii va produce o anomalie de actualizare? A. UPDATE TELEFON_MOBIL set MOBIL = 6600 where MOBIL = N97 B. UPDATE TELEFON_MOBIL set BRAND = Samsung where MOBIL = ZN50 C. UPDATE TELEFON_MOBIL set LOCATIE_BIROU = Bangalore where MOBIL = N97 D. UPDATE TELEFON_MOBIL set BRAND = Samsung , MOBIL = X210 where MOBIL = MotoSlim E. Nici una dintre cele enumerate 3. Care este forma normal a relaiei BIBLIOTECA_CARTE de mai jos: BIBLIOTECA_CARTE (ID_CARTE, NUME_CARTE, AUTOR, SUBIECT)

Baze de date - Fundamente A. Prima form normal B. A doua form normal C. A treia form normal D. Forma normal Boyce - Codd E. A patra form normal

118

4. Care dintre urmtoarele nu poate fi determinat pe baza proprietilor dependenelor funcionale? A. Mulimea de nchidere a dependenelor funcionale, F+ B. Descompunerea fr pierdere de informaie C. X Y aparine lui F+ D. Supercheia E. Nici una dintre cele enumerate 5. n cazul unei relaii aflate n forma normal Boyce-Codd, dac exist mai multe dependene multivalorice, aceasta se afl n forma normal 4 numai dac: A. Dependenele multivalorice sunt mutual independente. B. Dependenele multivalorice se afl n legtur unele cu altele. C. Cheia candidat determin dependenele multivalorice. D. Cheile candidat sunt identice. E. Nici una dintre cele enumerate 6. Care dintre urmtoarele afirmaii este incorect? A. Descompunerea fr pierdere de informaie trebuie s se fac ntotdeauna. B. Dependenele funcionale sunt un fel de constrngeri de integritate. C. Pstrarea dependenelor implic jonciunea fr pierdere de informaie i viceversa. D. BCNF nu se poate obine n orice situaie. E. Nici una dintre cele enumerate

5
Capitolul 5 Introducere n SQL
Limbajul structurat de interogare (SQL) este un limbaj de nivel nalt care permite utilizatorilor s opereze cu date relaionale. Unul dintre aspectele de for ale limbajului SQL este acela c utilizatorii nu trebuie dect s specifice informaia de care au nevoie fr a fi nevoii s cunoasc felul n care aceasta este extras. Sistemul de management al bazei de date este responsabil cu stabilirea cii de acces pentru a ajunge la date. SQL lucreaz cu mulimi, adic va extrage rnduri din unul sau mai multe tabele. SQL are trei sublimbaje, n funcie de funcionalitatea cerut: DDL Data definition language (limbaj de definire a datelor) folosit pentru a defini, modifica sau elimina obiecte din baza de date DML Data manipulation language (limbaj de manipulare a datelor) folosit pentru a citi i modifica date DCL Data control language (limbaj de control al datelor) folosit pentru a permite sau retrage autorizri n cadrul acestui capitol se va face o prezentare a istoricului limbajului SQL i se va arta felul n care se lucreaz cu ajutorul acestui limbaj. Ne vom concentra atenia spre patru operaii de baz din SQL folosite de cele mai multe orii n cadrul aplicaiilor: Create, Read, Update i Delete (CRUD).

5.1 Istoricul SQL

Don Chamberlin i Ray Boyce de la compania IBM au elaborat limbajul SQL n anii 1970 n cadrul proiectului System R, care i propunea s ofere o implementare practic a modelului relaional propus de ctre Codd. La nceput, limbajul a fost denumit Structured English Query Language (limbaj structurat de interogare n limba englez) sau SEQUEL, dar a fost schimbat ulterior n SQL deoarece SEQUEL aparinea deja unei companii din Marea Britanie. SQL este astzi recunoscut ca limbaj standard pentru lucrul cu bazele de date relaionale. SQL a fost adoptat ca limbaj standard n anul 1986 de ctre organizaia American National Standards Institute (ANSI) i de ctre International Standards Organization (ISO) n anul 1987. Din momentul n care a devenit standard, limbajul SQL a fost modificat

Baze de date - Fundamente

120

de ase ori. Ultima modificare a avut loc n anul 2008 iar versiunea este cunoscut sub denumirea de SQL:2008. SQL este un limbaj care folosete limba englez pentru a elabora cuvinte cheie i construcii specifice bazelor de date, fiind simplu de utilizat i neles. Limbajul suport diverse mecanisme de acces pentru a formula o serie de cerine i proceduri. Pe parcursul seciunilor care urmeaz se vor prezenta, unul cte unul, aceste mecanisme.

5.2 Definirea n SQL a schemei bazei de date relaionale

Aa cum s-a artat n capitolele anterioare, schema unei baze de date relaionale reprezint o descriere formal a tuturor relaiilor i asocierilor din cadrul unei baze de date. Cu ajutorul limbajului SQL se poate realiza o implementare fizic a unei astfel de scheme (ceea ce mai este cunoscut i sub denumirea de "model fizic de date"). Dei cei mai muli dintre productorii de baze de date respect standardele ANSI i ISO pentru limbajul SQL, exist totui o serie de diferene de sintax la fiecare dintre acetia. Din acest motiv, fiecare model fizic de date este specific unui anumit produs de baze de date. n aceast carte se va folosi produsul DB2 Express-C, versiunea gratuit a serverului de baze de date IBM DB2. n cadrul unui model fizic de date exist o serie de elemente i proprieti care vor fi luate n discuie n cadrul capitolului de fa, prezentndu-se totodat i implementarea specific n SQL.

5.2.1 Tipuri de date

La fel ca n cazul oricrui alt limbaj de programare i bazele de date lucreaz cu o serie de tipuri de date care se folosesc pentru stabilirea valorilor ce pot fi introduse n cadrul coloanelor unui tabel. Dintre tipurile de date folosite n limbajul SQL amintim: integer, float, decimal, char, date, time, blob etc. De asemenea, exist i posibilitatea de a crea date definite de utilizator, dar acestea sunt limitate la combinaii ntre tipurile de baz suportate. Tipuri de date definite de utilizatori pot fi, de exemplu, addresa, tara, telefon, CNP, cod postal, pentru a da doar cteva exemple. 5.2.1.1 Tipuri de date calendaristice Toate produsele de baze de date suport diverse funcii i tipuri de date calendaristice specifice. DB2 folosete urmtoarele tipuri de ate calendaristice: Date (YYYY-MM-DD) Time (HH:MM:SS) Timestamp (YYYY-MM-DD-HH:MM:SS:ssssss) n care, ssssss, reprezint o parte a timpului curent, n milisecunde. Urmtoarele reprezint o parte dintre funciile care folosesc tipurile de date calendaristice: Year

Capitolul 5 Introducere n SQL 121 Month Day Dayname Hour Minute Second Microsecond

5.2.2 Crearea unui tabel

Un tabel reprezint o mulime de date organizate i pstrate n rnduri i coloane. Un tabel poate conine date, de exemplu, despre studeni, profesori, discipline, cri etc. Tipurile de entiti din modelul conceptual se transform n tabele n cadrul unei baze de date, iar atributele acestora se transform n coloane ale tabelului. S ncepem prin crearea un tabel simplu cu o cantitate minim de informaie. De exemplu:
create table myTable (col1 integer)

Comanda de mai sus creeaz un tabel care are numele myTable, cu o singur coloan numit col1 care poate pstra date de tip integer. Acest tabel poate accepta orice valoare ntreag sau nul ce poate fi introdus n coloana col1. Valorile nule sunt prezentate ulterior n cadrul acestei seciuni. 5.2.2.1 Valori implicite La introducerea datelor n cadrul unui tabel, cteodat poate fi util s se genereze automat valori implicite pentru unele dintre coloanele tabelului. De exemplu, atunci cnd utilizatorii unui site se nregistreaz la site-ul respectiv, dac las necompletat cmpul profession atunci coloana corespunztoare din tabelul USERS ia valoarea Student. Acest lucru este prezentat cu ajutorul urmtoarei comenzi:
CREATE TABLE USERS (NAME CHAR(20), AGE INTEGER, PROFESSION VARCHAR(30) with default 'Student')

Pentru a introduce o coloan care ia ca valoare un numr de departament introdus n mod incremental, pornind de la un numr introdus iniial, se poate folosi comanda:
CREATE TABLE DEPT (DEPTNO SMALLINT NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 500, INCREMENT BY 1), DEPTNAME VARCHAR(36) NOT NULL, MGRNO CHAR(6), ADMRDEPT SMALLINT NOT NULL, LOCATION CHAR(30))

Baze de date - Fundamente

122

Comanda SQL de mai sus creaz tabelul DEPT, n care coloana DEPTNO are valori implicite ncepnd cu 500 i incrementate cu un pas. La introducerea rndurilor n acest tabel, nu trebuie introduse valori n cmpul DEPTNO, baza de date genernd n mod automat valori pentru fiecare rnd inserat. 5.2.2.2 Valori nule O valoare nul reprezint o stare necunoscut. De exemplu, un tabel ce pstreaz date despre notele studenilor poate s permit valori nule. Acest lucru nseamn pentru profesor faptul c studentul respectiv fie nu a fost nc evaluat, fie nu s-a prezentat la examen. Aceast valoare face distincia fa de valoarea zero care nseamn faptul c studentul a dat examenul, dar a greit la toate ntrebrile. Exist situaii n care nu se accept valori nule. De exemplu, dac un cmp al unui tabel care conine numele rilor trebuie s ofere o valoare aplicaiei, atunci trebuie s se interzic apariia valorilor nule, astfel:
create table myTable (name varchar(30), country varchar(20) NOT NULL)

Comanda de mai sus semnific faptul c valorile nule nu sunt premise n coloana country, dar valorile duplicate sunt permise 5.2.2.3 Constrngeri Constrngerile permit stabilirea unor reguli pentru datele introduse n cadrul unui tabel. Exist urmtoarele tipuri de constrngeri: UNIQUE interzice introducerea valorilor duplicat n cadrul unui tabel. Acest lucru se specific cu ajutorul comenzii CREATE TABLE prin folosirea cuvntului cheie UNIQUE. Se pot introduce valori nule. Constrngerii UNIQUE i este ntotdeauna asociat un index. PRIMARY KEY este similar constrngerii UNIQUE cu deosebirea faptului c sunt interzise valorile nule. Cheile primare au ntotdeauna asociat un index. REFERENCES se folosete pentru a asigura integritatea referenial care permite gestionarea relaiilor dintre tabele. Acest lucru se va discuta n detaliu n seciunea urmtoare. CHECK se folosete pentru a verifica dac valorile introduse n cadrul unei coloane a unui tabel respect regulile stabilite n cadrul constrngerii. Exemplul urmtor prezint definiia unui tabel care are cteva constrngeri de tip CHECK i o cheie primar:
CREATE TABLE EMPLOYEE (ID INTEGER NOT NULL PRIMARY KEY, NAME VARCHAR(9), DEPT SMALLINT CHECK (DEPT BETWEEN 10 AND 100), JOB CHAR(5) CHECK (JOB IN ('Sales','Mgr','Clerk')), HIREDATE DATE, SALARY DECIMAL(7,2), CONSTRAINT YEARSAL CHECK ( YEAR(HIREDATE) > 1986 OR SALARY > 40500 )

Capitolul 5 Introducere n SQL 123

)

nainte de a se introduce date n cadrul acestui tabel trebuie respectate patru constrngeri: Cheia primar pe coloana ID Aceasta nseamn faptul c nu sunt premise valorile duplicat. Constrngerea CHECK pe coloana DEPT Se permite introducerea datelor n aceast coloan doar dac valorile acestora sunt ntre 10 i 100. Constrngerea CHECK pe coloana JOB Se permite introducerea datelor n aceast coloan doar dac valorile acestora sunt Sales, Mgr sau Clerk'. Constrngerea CHECK pe combinaia de coloane HIREDATE i SALARY Se permite introducerea datelor doar dac data angajrii este superioar anului 1986 iar salariul este mai mare de 40500. 5.2.2.4 Integritatea referenial Aa cum s-a artat n capitolul 2, integritatea referenial permite stabilirea de asocieri ntre tabele. Prin folosirea unei perechi cheie primar-cheie extern se verific validitatea datelor introduse. Integritatea referenial reduce complexitatea codului aplicaiei prin eliminarea nevoii de a face aceast verficare la nivel de aplicaie. Un tabel ale crui valori depind de valorile altui tabel se numete dependent, sau tabel copil, iar un tabel la care se face referire se numete tabel de baz sau printe. Doar tabelele care au coloane cu restriciile UNIQUE sau PRIMARY KEY pot fi referite de ctre alte tabele prin intermediul cheii externe. Integritatea referenial poate fi stabilit n cadrul definiiei unui tabel sau dup crearea unui tabel, aa cum se prezint n n exemplul de mai jos n care sunt prezentate trei sintaxe diferite:
Sintaxa 1: CREATE TABLE DEPENDANT_TABLE (ID INTEGER REFERENCES BASE_TABLE(UNIQUE_OR_PRIMARY_KEY), NAME VARCHAR(9), : : : );

Sintaxa 2: CREATE TABLE DEPENDANT_TABLE (ID INTEGER, NAME VARCHAR(9),

Baze de date - Fundamente

: : :, CONSTRAINT constraint_name FOREIGN KEY (ID) REFERENCES BASE_TABLE(UNIQUE_OR_PRIMARY_KEY) );

124

Sintaxa 3: CREATE TABLE DEPENDANT_TABLE (ID INTEGER, NAME VARCHAR(9), : : : ); ALTER TABLE DEPENDANT_TABLE ADD CONSTRAINT constraint_name FOREIGN KEY (ID) REFERENCES BASE_TABLE(UNIQUE_OR_PRIMARY_KEY);

n codul de mai sus, atunci cnd nu se specific numele unei constrngeri, acesta este creat n mod automat de ctre sistemul DB2. irul generat are lungimea de 15 caractere, de exemplu CC1288717696656. Ce se ntmpl atunci cnd aplicaia trebuie s elimine un rnd din tabelul de baz care este referit n tabelul copil? Aa cum s-a artat n capitolul 2, exist trei reguli diferite care gestioneaz tergerile i actualizrile din cadrul unui tabel, iar comportamentul de tergere depinde de urmtoarele construcii introduse la crearea tabelului: CASCADE Aa cum arat i numele, folosind aceast opiune, operaia se efectueaz n cascad i n tabelele copil associate, iar valoarea se actualizeaz sau se elimin din tabelul printe. SET NULL Folosind aceast opiune, toate valorile din tabelul referit sunt trecute pe valoarea nul NO ACTION Folosind aceast opiune nu se produce nici o aciune fiind necesar pstrarea integritii refereniale att nainte ct i dup executarea comenzii. RESTRICT Folosind aceast opiune nu se permite valorilor care au referine ctre tabelul printe s se modifice sau s fie eliminate. Comanda de mai jos arat unde sunt specificate regulile de tergere sau actualizare:
ALTER TABLE <TABEL_DEPENDENT>

Capitolul 5 Introducere n SQL 125

ADD CONSTRAINT <nume_constrangere> FOREIGN KEY <nume_coloana> ON DELETE <tip_de_actiune_la_stergere> ON UPDATE < tip_de_actiune_la_actualizare> ;

O aciune de tergere poate fi de tip CASCADE, SET NULL, NO ACTION sau RESTRICT. O aciune de actualizare poate fi de tip NO ACTION sau RESTRICT.

5.2.3 Crearea unei scheme

La fel ca i n cazul pstrrii fiierelor n directoarele sistemului de fiiere ale unui sistem de calcul n care se pstreaz fiierele ce aparin aceluiai domeniu de interes, schema unei baze de date DB2 este un obiect al bazei de date ce permite pstrarea n comun a tuturor obiectelor ce aparin bazei de date respective. n DB2, fiecare obiect are dou pri, numele schemei i numele obiectului. Pentru a crea o schem se folosete comanda:
create schema mySchema

Pentru a crea un tabel n schema de mai sus se scrie:

create table mySchema.myTable (col1 integer)

Atunci cnd nu se specific numele schemei, DB2 folosete o schem implicit, care, de obicei, are numele identificatorului utilizatorului care se conecteaz la baza de date respectiv. Numele implicit al schemei se poate modifica folosind sintaxa SET CURRENT SCHEMA aa cum se arat mai jos:
set current schema mySchema

5.2.4 Crearea unei vederi

O vedere este un tabel virtual ce provine din unul sau mai multe tabele sau din alte vederi. Este virtual deoarece nu conine date, ci doar o definiie a unui tabel ce rezult dintr-o operaie de selecie. De exemplu, pentru a crea o vedeere bazat pe tabelul EMPLOYEE trebuie scris:
CREATE VIEW MYVIEW AS SELECT LASTNAME, HIREDATE FROM EMPLOYEE

Odat ce o vedere este creat, se poate folosi la fel ca orice alt tabel. De exemplu, se poate folosi o comand se selecie pe aceasta:
SELECT * FROM MYVIEW

Vederile permit ascunderea datelor sau limitarea accesului la date, ceea ce nseamn c acestea pot fi folosite si pe motive de securitate.

Baze de date - Fundamente

126

5.2.5 Crearea altor obiecte ale bazei de date

n mod asemntor comenzii CREATE TABLE folosit n SQL pentru crearea de tabele, mai exist i alte comenzi pentru fiecare dintre obiectele bazei de date, cum ar fi indeci, funcii, proceduri stocate, declanatori, .a.m.d. Pentru informaii suplimentare despre aceste comenzi vedei DB2 9.7 Information Center.

5.2.6 Modificarea obiectelor bazei de date

Un obiect odat creat poate fi modificat pentru a rspunde cerinelor impuse. Eliminarea i recrearea obiectului este o variant de a face aceste modificri, dar acest lucru poate avea uneori efecte inacceptabile. O modalitate mai bun de modificare a obiectelor bazei de date este aceea de utilizare a comenzii SQL ALTER. De exemplu, dac se dorete s se modifice definiia unui tabel astfel nct s nu se permit introducerea de valori nule ntr-o anumit coloan a acestuia, se poate folosi conmanda:
alter table myTable alter column col1 set not null

n mod asemntor, i alte modificri, cum ar fi adugarea sau eliminarea unei coloane, stabilirea sau eliminarea cheii primare, .a.m.d., se pot realiza folosind sintaxa corespunztoare alter table. Comanda ALTER se mai poate folosi i pentru alte obiecte ale bazei de date.

5.2.7 Redenumirea obiectelor unei baze de date

Odat create obiectele bazei de date, acestea pot fi redenumite folosind comanda SQL, RENAME. Pentru a redenumi un obiect al unei baze de date se poate folosi sintaxa:
RENAME <tip obiect> <nume obiect> to <nume nou>

n care tipul obiectului poate fi, de exemplu, un tabel, un spaiu rezervat tabelului, sau un index. Nu toate obiectele bazei de date pot fi redenumite dup creare. Pentru a redenumi o coloan, se va folosi comanda SQL ALTER TABLE mpreun cu RENAME. De exemplu:
ALTER TABLE <nume tabel> RENAME COLUMN <nume coloan> TO <nume nou>

5.3 Manipularea datelor folosind limbajul SQL

Aceast seciune arat felul n care se folosesc operaiile de citire, actualizare sau tergere a datelor n SQL.

5.3.1 Extragerea datelor

Extragerea datelor n SQL este o operaie ce permite citirea (extragerea) rndurilor i coloanelor dintr-un tabel relaional. Acest lucru se poate face cu ajutorul comenzii SELECT.

Capitolul 5 Introducere n SQL 127 Dac tabelul are numele myTable, cea mai simpl comand de extragere a datelor din cadrul acestui tabel este:
select * from myTable

Caracterul special *, reprezint toate coloanele din cadrul tabelului. Folosirea * n cadrul unei interogri nu este recomandat n practic, deoarece se obine mai mult informaie dect este necesar. De obicei, nu sunt necesare toate coloanele unui tabel, caz n care trebuie specificat o list de coloane. De exemplu,
select col1, col2 from myTable

extrage col1 i col2 cu toate rndurile tabelului myTable n care col1 i col2 sunt numele coloanelor din care se extrag datele. 5.3.1.1 Ordonarea rezultatelor Comanda SELECT ntoarce rezultatele fr a respecta nici o ordine. Dac se folosete aceeai comand SELECT de mai multe ori se va ntoarce acelai grup de rnduri, dar ntr-o ordine diferit. Pentru a fi siguri c rezultatele vor fi afiate n aceeai ordine n permanen, fie cresctor, fie descresctor, se va folosi clauza ORDER BY. De exemplu, comanda de mai jos returneaz rezultatul ordonnd datele din coloana col1 cresctor:
SELECT col1 FROM myTable ORDER BY col1 ASC

ASC provine de la ordonarea cresctoare, care este implicit. Ordonarea descresctoare a datelor se face folosind DESC aa cum se vede mai jos:
SELECT col1 FROM myTable ORDER BY col1 DESC

5.3.1.2 Cursoare Un cursor este un mecanism al bazei de date prin care se pstreaz rezultatele obinute din execuia unei clauze SELECT. Sintaxa prin care se declar, se deschide, se parcurge i se nchide un cursor se prezint mai jos:
DECLARE <nume cursor> CURSOR [WITH RETURN <tinta retur>] <comanda SELECT >; OPEN <nume cursor>; FETCH <nume cursor> INTO <variabile>; CLOSE <nume cursor>;

n loc s returneze unei aplicaii toate datele unei comenzi SQL dintr-o dat, cursorul permite aplicaiei s proceseze rndurile unul cte unul. Folosind comenzile FETCH mpreun cu o bucl din cadrul aplicaiei, progrmatorii pot ajunge de la un rnd la altul cu ajutorul cursorului aplicnd anumite reguli unuia dintre acestea sau n funcie de coninutul acestuia. De exemplu, urmtorul fragment de cod adun toate salariile angajailor cu ajutorul unui cursor.

Baze de date - Fundamente

... DECLARE p_sum INTEGER; DECLARE p_sal INTEGER; DECLARE c CURSOR FOR SELECT SALARY FROM EMPLOYEE; DECLARE SQLSTATE CHAR(5) DEFAULT '00000'; SET p_sum = 0; OPEN c; FETCH FROM c INTO p_sal; WHILE(SQLSTATE = '00000') DO SET p_sum = p_sum + p_sal; FETCH FROM c INTO p_sal; END WHILE; CLOSE c; ...

128

Cursoarele sunt folosite pe scar larg pentru a parcurge mai multe rnduri din cadrul unui tabel i pentru a le prelucra cu ajutorul aplicaiilor.

5.3.2 Introducerea datelor

Pentru a introduce date n cadrul unui tabel se folosete comanda INSERT. Exist mai multe modaliti de a introduce date. De exemplu, se poate introduce cte un rnd pentru fiecare comand INSERT, mai multe rnduri pentru fiecare comand INSERT sau toate rndurile folosind o interogare, aa cum se arat n exemplele urmtoare. n acest prim exemplu, comanda de inserare introduce un singur rnd n tabelul myTable.
insert into myTable values (1); insert into myTable values (1, myName, 2010-01-01);

n cel de-al doilea exemplu, comanda introduce mai multe (trei) rnduri n tabelul myTable.
insert into myTable values (1),(2),(3); insert into myTable values (1, myName1,2010-01-01), (2, myName2,2010-02-01), (3, myName3,2010-03-01);

n sfrit, n cel de-al treilea exemplu, comanda de inserare introduce toate rndurile unei subinterogri, select * from myTable2 n tabelul myTable.
insert into myTable (select * from myTable2)

5.3.3 tergerea datelor

Pentru a terge rnduri dintr-un tabel se folosete comanda DELETE. Prin specificarea unei condiii n clauza WHERE se pot elimina dintr-un tabel unul sau mai multe rnduri folosind o singur comand. De exemplu, comanda urmtoare terge din tabelul myTable toate rndurile n care col1 > 1000.
DELETE FROM myTable WHERE col1 > 1000

Capitolul 5 Introducere n SQL 129 Trebuie avut mare atenie la folosirea comenzii de tergere. Dac n comanda de tergere nu apare i clauza WHERE comanda DELETE va terge toate rndurile din tabel.

5.3.4 Actualizarea datelor

Pentru a actualiza datele existente n cadrul unui tabel se folosete comanda UPDATE. Folosind o singur comand de actualizare mpreun cu condiia WHERE se pot actualiza mai multe rnduri din cadrul unui tabel. Pentru fiecare rnd desemnat a fi actualizat, comanda poate modifica una sau mai multe coloane. De exemplu:
UPDATE myTable SET col1 = UPDATE myTable SET col1 = col2 = col3 = WHERE col4 -1 WHERE col2 < 0 -1, a, 2010-01-01 = 0

Trebuie avut mare atenie la folosirea comenzii de actualizare. Dac n comanda de actualizare nu apare i clauza WHERE aceasta va actualiza toate rndurile din tabel.

5.4 Jonciuni ale tabelelor

O comand SQL simpl de selecie este acea comand care extrage valorile din una sau mai multe coloane ale unui singur tabel. Urmtoul nivel de complexitate apare atunci cnd trebuie extrase date din dou sau mai multe tabele, ceea ce conduce la multiple posibiliti referitoare la felul n care pot fi obinute rezultatele. n cadrul unei comenzi SQL exist dou posibiliti de cuplare a tabelelor: 1. Inner join (jonciunea intern) 2. Outer join (jonciunea extern) Acestea sunt detaliate n seciunile urmtoare.

5.4.1 Jonciunea intern

O jonciune intern este cea mai obinuit form de jonciune folosit ntr-o comand SQL. Aceasta poate fi de tipurile: Equi-join (echi-jonciunea) Natural join (jonciunea natural) Cross join (jonciunea ncruciat) 5.4.1.1 Equi-join Acest tip de jonciune apare atunci cnd dou tabele sunt cuplate pe baza egalitii coloanelor specificate; de exemplu:

Baze de date - Fundamente

SELECT * FROM student, enrollment WHERE student.enrollment_no=enrollment.enrollment_no SAU SELECT * FROM student INNER JOIN enrollment ON student.enrollment_no=enrollment.enrollment_no

130

5.4.1.2 Jonciunea natural O jonciune natural este o versiune mbuntit de echi-jonciune n care coloanele care se cupleaz nu au nevoie de nici o specificaie. Sistemul selecteaz automat coloana cu acelai nume din tabele i aplic operatorul de egalitate asupra acesteia. Jonciunea natural elimin toate atributele duplicat, ca n exemplul:
SELECT * FROM STUDENT NATURAL JOIN ENROLLMENT

Jonciunile naturale provoac mai multe ambiguiti dect uurina de folosire. De exemplu, pot apare probleme atunci cnd tabelele care se cupleaz au mai multe coloane cu acelai nume, sau atunci cnd tabelele nu au acelai nume pentru coloanele care se cupleaz. Cele mai multe dintre sistemele de baze de date nu suport jonciunea natural. 5.4.1.3 Jonciunea ncruciat O jonciune ncruciat este un produs cartezian simplu al tabelelor care se cupleaz. De exemplu:
SELECT * FROM STUDENT, ENROLLMENT

5.4.2 Jonciuni externe

O jonciune extern este o form specializat de jonciune folosit n comenzile SQL. ntro jonciune extern, primul tabel specificat n comanda SQL din clauza FROM se apreciaz ca fiind tabelul din stnga, iar cellalt tabelul din dreapta. O jonciune extern poate fi de trei tipuri: Left outer join (jonciune extern stnga) Right outer join (jonciune extern dreapta) Full outer join (jonciune extern complet) Figura 5.1 prezint cele trei tipuri de jonciuni externe.

Capitolul 5 Introducere n SQL 131

Figura 5.1 Tipurile de jonciuni externe n seciunile urmtoare, se va descrie mai n detaliu fiecare dintre aceste jonciuni. Pentru o mai bun nelegere a fiecrei situaii, exemplele sunt oferite folosind tabelele din Figura 5.2.

Figura 5.2 Tabelele folosite la exemplificarea jonciunilor externe 5.4.2.1 Jonciunea extern stnga n acest tip de jonciune, rezultatul va fi o reuniune a rezultatelor unei echi-jonciuni,

Baze de date - Fundamente

132

incluznd i rndurile ce nu au corespondent ale tabelului din STNGA. De exemplu, urmtoarea comand va returna rndurile prezentate Figura 5.3.
SELECT * FROM STUDENT LEFT OUTER JOIN ENROLLMENT ON STUDENT.ENROLLMENT_NO = ENROLLMENT_NO

Figura 5.3 Rezultatul unei jonciuni externe stnga 5.4.2. Jonciunea extern dreapta n cazul acestui tip de jonciune, rezultatul reprezint reuniunea unei echi-jonciuni, care include i rndurile care nu au corespondent din tabelul din drepata. De exemplu, urmtoarea comand ntoarce rndurile prezentate n Figura 5.4.
SELECT * FROM STUDENT RIGHT OUTER JOIN ENROLLMENT ON STUDENT.ENROLLMENT_NO = ENROLLMENT_NO

Figura 5.4 Rezultatul unei jonciuni externe dreapta 5.4.2.3 Jonciune extern complet n acest caz, rezultatul este o reuniune a rezultatelor unei echi-jonciuni, care include i rndurile ce nu au corespondent nici n tabelul din STNGA nici n tabelul din DREAPTA. De exemplu, comanda urmtoare va returna rndurile prezentate n Figura 5.5.
SELECT * FROM STUDENT FULL OUTER JOIN ENROLLMENT ON STUDENT.ENROLLMENT_NO = ENROLLMENT_NO

Capitolul 5 Introducere n SQL 133

Figura 5.5 Rezultatul unei jonciuni externe complete Fiecare tip de jonciune returneaz seturi de date diferite, motiv pentru care acestea trebuie folosite n mod explicit pentru fiecare dintre cerinele aplicabile domeniului. De exemplu, dac se dorete o list a studenilor nregistrai la oricare dintre cursuri, dar i a studenilor care nu au fost nregistrai nicieri, probabil c va fi nevoie de o jonciune extern stnga.

5.5 Operaiile de reuniune, intersecie i diferen

Operatorii de reuniune, intersecie i diferen folosii n teoria mulimilor sunt folosii i m comenzile SQL att timp ct cerinele necesare sunt respectate.

5.5.1 Reuniunea
Operatorul Union poate fi folosit pentru a reuni dou seturi de date care au aceleai definiii ale coloanelor i care apar n aceeai ordine. Operatorul de reuniune elimin duplicatele din rezultat. De exemplu, urmtoarea comand ntoarce rndurile prezentate n Figura 5.6.
SELECT * FROM student_table_a UNION SELECT * FROM student_table_b

Baze de date - Fundamente

134

Figure 5.6 Exemplu cu operatorul de reuniune n Figura 5.6, se observ faptul c operatorul de reuniune elimin rndurile duplicat. Pot exista situaii n care eliminarea rndurilor duplicat nu este necesar. n astfel de cazuri se folosete operatorul UNION ALL ca n exemplul urmtor:
SELECT * from student_table_a UNION ALL SELECT * from student_table_b

Figura 5.7 prezint un exemplu de rezultat n care se folosete operatorul UNION ALL.

Capitolul 5 Introducere n SQL 135

Figura 5.7 Exemplu de folosire a operatorului UNION ALL

5.5.2 Intersecia
Operatorul de intersecie INTERSECT returneaz un rezultat n care se prezint datele care sunt comune ambelor tabele, folosindu-se comanda:
select * from student_table_a INTERSECT select * from student_table_b

Figura 5.8 prezint un exemplu de rezultat al comenzii anterioare.

Figura 5.8 Exemplu de rezultat obinut dup folosirea operatorului INTERSECT Operatorul de intersecie va returna toate datele comune care exist n ambele tabele A i B, iar acestea vor fi afiate o singur dat, chiar dac n cele dou tabele exist mai multe rnduri duplicat. Pentru a returna toate datele duplicat n rezultatul final, se va folosi operatorul INTERSECT ALL, ca n exemplul:
select * from student_table_a INTERSECT ALL select * from student_table_b

5.5.3 Diferena (EXCEPT)

Operatorul de diferen (EXCEPT) ntoarce ca rezultat doar datele care exist n tabelul din STNGA.

Baze de date - Fundamente Din punct de vedere logic, A EXCEPT B = A MINUS [A INTERSECT B] De exemplu:
select * from student_table_a EXCEPT select * from student_table_b

136

va ntoarce rezultatul din Figura 5.9.

Figura 5.9 Exemplu de rezultat obinut dup aplicarea operatorului EXCEPT Operatorul EXCEPT va returna datele care exist n tabelul A, dar nu i n tabelul B, iar datele comune sunt afiate o singur dat, chiar dac exist mai multe rnduri duplicat n tabelul A. Pentru a returna toate datele, inclusiv duplicatele, se va folosi operatorul EXCEPT ALL. De exemplu:
select * from student_table_a EXCEPT ALL select * from student_table_b

5.6 Operatori relaionali

Operatorii relaionali reprezint teste i operaii de baz care se pot aplica datelor. Aceti operatori conin: Operaii matematice de baz, cum ar fi +, -, * i / Operatori logici, cum ar fi AND, OR i NOT Operatori de manipulare a irurilor de caractere, cum ar fi CONCATENATE, LENGTH, SUBSTRING Operatori de comparare, cum ar fi =, <, >, >=, <= and != Operatori de grupare i agregare Alte operaii, cum ar fi DISTINCT Vom elimina din discuie operatorii matematici de baz, operatorii logici i cei de comparaie, i ne vom opri asupra celorlali operatori.

Capitolul 5 Introducere n SQL 137

5.6.1 Operatori de grupare

Operatorii de grupare efectueaz operaii cu dou sau mai multe seturi de date obinnduse un rezultat totalizator. De exemplu, s spunem c avem un tabel care conine lista tuturor studenilor, precum i cursurile la care acetia sunt nregistrai. Fiecare student se poate nregistra la mai multe cursuri, fiecare curs avnd mai muli studeni nregistrai. Pentru a obine numrul studenilor nregistrai la cursuri se folosete comanda SQL:
select count(*) from students_enrollment

Dac se dorete s se obin numrul studenilor nscrii la fiecare curs, trebuie ordonate datele tabelului pe baza cursurilor existente, dup care se numr studenii nscrii la cursul respectiv. Acest lucru se face folosind clauza GROUP BY astfel:
select course_enrolled, count(*) from students_enrollment group by course_enrolled ---------------Resultset---------------COURSE_ENROLLED STUDENT_COUNT ------------------------- ------------English 10 Mathematics 30 Physics 60

Gruparea se poate face i pe mai multe coloane, caz n care ordonarea se face ncepnd cu coloana cea mai din stnga.

5.6.2 Operatori de agregare

Operatorii care acioneaz pe dou sau mai multe tupluri sau rnduri, ntorcnd un rezultat scalar se numesc operatori de agregare. Acetia ar putea fi: COUNT, SUM, AVERAGE, MINIMUM, MAXIMUM .a.m.d. Aceti operatori se folosesc mpreun cu clauza GROUP BY aa cum se prezint n comenzile SQL de mai sus.

5.6.3 Clauza HAVING

HAVING este un operator special ce poate fi folosit numai mpreun cu clauza GROUP BY pentru a selecta anumite rnduri din rezultatul obinut prin grupare. Privii exemplul din seciunea operatorilor de grupare; se vor prezenta doar acele cursuri care au mai puin de 5 studeni nregistrai; se va folosi clauza HAVING aa cum se vede mai jos:
SELECT course_enrolled, count(*) FROM students_enrollment GROUP BY course_enrolled HAVING count(*) < 5

Pentru a reduce n continuare numrul de rnduri din rezultatul scalar se va folosi clauza WHERE; dar aceast clauz nu poate fi folosit la gruparea rndurilor.

Baze de date - Fundamente

138

5.7 Subinterogri
Atunci cnd o interogare se folosete n cadrul altei interogri, interogarea exterioar se numete interogarea principal sau interogarea printe, iar interogarea interioar se numete subinterogare. Aceast subinterogare poate ntoarce o singur valoare scalar, unul sau mai multe tupluri, sau valori nule. Subinterogrile se execut primele, dup care se execut interogrile printe folosind datele furnizate de ctre subinterogare.

5.7.1 Subinterogri ce returneaz o valoare scalar

Valorile scalare reprezint o singur valoare a oricrui atribut sau entitate, cum ar fi de exemplu NUME, VARSTA, CURS, AN etc. Interogarea urmtoare folosete o subinterogare care ntoarce o valoare scalar, care apoi se folosete n interogarea printe pentru a obine rezultatul dorit:
SELECT name FROM students_enrollment WHERE age = ( SELECT min(age) FROM students )

Interogarea de mai sus ntoarce o list a celor mai tineri studeni. Subinterogarea SELECT min(age) FROM students ntoarce o valoare scalar care arat studentul cu vrsta cea mai mic. Interogarea printe ntoarce o list a tuturor studenilor a cror vrst este egal cu valoarea returnat de subinterogare.

5.7.2 Subinterogri care returneaz mai multe valori

Atunci cnd subinterogarea returneaz un grup de rezultate ce conin mai multe valori din cadrul unei coloane (cum ar fi lista numelor) sau o mulime de valori ce provin din mai multe coloane (cum ar fi numele, vrsta i data naterii studenilor) atunci se spune c subinterogarea returneaz valori multiple. De exemplu, pentru a obine o list a studenilor care sunt nscrii la un anumit curs oferit de ctre departamentul de calculatoare, se va folosi subinterogarea:
SELECT name FROM students WHERE course_enrolled IN ( SELECT distinct course_name FROM courses WHERE department_name = Computer Science )

n acest exemplu, subinterogarea ntoarce o list a tuturor cursurilor oferite de departamentul de calculatoare, iar interogarea exterioar afieaz toi studenii nscrii la cursurile obinute cu ajutorul subinterogrii. Se observ faptul c pot exista mai multe variante de a obine acest rezultat. Exemplele prezentate n cadrul acestui capitol arat metodele de lucru i nu comanda SQL optim.

Capitolul 5 Introducere n SQL 139

5.7.3 Subinterogri corelate

Atunci cnd o subinterogare se execut pentru fiecare rnd al tabelului printe, n loc de a fie executat dintr-o singur trecere, (aa cum se ntmpl n exemplul de mai sus), aceasta este denumit subinterogare corelat. De exemplu:
SELECT dept, name, marks FROM final_result a WHERE marks = ( SELECT max(marks) FROM final_result WHERE dept = a.dept )

Comanda de mai sus caut o list a studenilor pe departamente care au primit cele mai mari note n departamentele respective. Pentru fiecare rnd din tabelul din STNGA, subinterogarea gsete max(marks) pentru departamentul rndului curent i dac valoarea notei din rndul curent este egal cu rezultatul obinut din subinterogare, atunci se adaug rezultatului ce va fi furnizat de ctre interogarea exterioar.

5.7.4 Subinterogri n clauzele FROM

O subinterogare poate fi folosit i ntr-o caluz FROM aa cum se vede din exemplul urmtor:
SELECT dept, max_marks, min_marks, avg_marks FROM ( SELECT dept, max(marks) as max_marks, min(marks) as min_marks, avg(marks) as avg_marks FROM final_result GROUP BY dept ) WHERE (max_marks min_marks) > 50 and avg_marks < 50

Interogarea de mai sus folosete subinterogri ntr-o caluz FROM. Subinterogarea returneaz nota minim, maxim i media notelor pe fiecare deparatament. Interogarea exterioar folosete datele pe care le filtreaz n continuare prin adugarea unor condiii de filtrare n clauza WHERE a interogrii exterioare.

5.8 Corespondena dintre conceptele folosite la programarea orientat pe obiecte i cele folosite la bazele de date relaionale
Muli programatori folosesc astzi limbaje de programare orientat pe obiecte, dorind n acelai timp s acceseze baze de date relaionale. Tabelul urmtor arat corespondena dintre unele concepte folosite n programarea orientat pe obiecte i conceptele folosite n bazele de date relaionale. Lista din tabelul de mai jos nu este exhaustiv.

Baze de date - Fundamente Conceptele din programarea orientat pe obiecte elemente de clas Nume Atribut Metod Constructor/Destructor Identificator obiect Concepte ale relaionale Nume tabel Nume coloan Procedur stocat Declanator Cheie primar bazelor de

140 date

Table 5.1 Corespondena dintre conceptele folosite la programarea orientat pe obiecte i cele folosite la bazele de date relaionale Bibliotecile folosite la realizarea corespondenei obiectual-relaional, cum ar fi ObjectHibernate sunt foarte populare la oferirea unui cadru pentru realizarea unei astfel de transformri. pureQuery, o nou tehnologie introdus de ctre IBM, ofer suport suplimentar i mbunttiri ale performanelor n acest domeniu. Pentru mai multe informaii despre aceast tehnologie, vedei cartea gratuit Getting started with pureQuery, care face parte din aceast serie de cri.

5.10 Studiu de caz cu sistemul de management al unei biblioteci Partea 3 din 3

Partea final a studiului de caz arat modul de transfornare a modelului logic n model fizic, n care se vor crea obiectele specifice bazelor de date DB2. Tabelul de mai jos prezint corespondena dintre conceptele modelelor conceptual, logic i fizic: Conceptele modelrii conceptuale Numele tipului de entitate Tip de entitate Entitate Atribut Tip de relaie Conceptele modelrii logice Conceptele modelrii fizice Nume tabel Tabel Rnd Coloan Constrngere

Variabila relaie, R Relaie Tuplu Atribut, A1, A2, etc. O pereche cheie primar-cheie extern Cheie primar

Identificator unic

Cheie primar

Transformarea din modelul logic n modelul fizic este simpl. Din modearea logic s-au

Capitolul 5 Introducere n SQL 141 obinut toate relaiile i asocierile dintre acestea pentru a crea sistemul de management al unei biblioteci. Tot ceea ce mai rmne de fcut este specificarea domeniilor de valori (tipurilor de date) pentru fiecare atribut din cadrul fiecrui tabel, mpreun cu constrngerile corespunztoare. Sugerm folosirea urmtoarelor prefixe la acordarea numelor constrngerilor: PRIMARY KEY: pk_ UNIQUE: uq_ DEFAULT: df_ CHECK: ck_ FOREIGN KEY: fk_ S privim din nou fiecare relaie, dup adugarea tipurilor de date i constrngerilor: Relaia CITITOR Nume atribut ID_CITITOR NUME PRENUME EMAIL TEL ADRESA ORAS TARA Domeniu Text Text Text Text Text Text Text Text Sub-domeniu CHAR(5) VARCHAR(30) VARCHAR(30) VARCHAR(40) VARCHAR(15) VARCHAR(75) CHAR(3) DATE Opional Nu Nu Nu Da Da Da Nu Nu Constrngere Pk_

Relaia AUTOR Nume atribut ID_AUTOR NUME PRENUME EMAIL Domeniu Text Text Text Text Sub-domeniu CHAR(5) VARCHAR(30) VARCHAR(30) VARCHAR(40) Opional Nu Nu Nu Da Constrngere Pk_

Baze de date - Fundamente TEL ADRESA ORAS TARA Text Text Text Text VARCHAR(15) VARCHAR(75) VARCHAR(40) VARCHAR(40) Da Da Da Da

142

Relaia CARTE Nume atribut ID_CARTE TITLU EDITIE An PRET ISBN PAGINI INTERVAL DESCRIERE Domeniu Text Text Numeric Numeric Numeric Text Numeric Text Text Sub-domeniu CHAR(5) VARCHAR(40) INTEGER INTEGER DECIMAL(7,2) VARCHAR(20) INTEGER VARCHAR(10) VARCHAR(100) Opional Nu Nu Da Da Da Da Da Da Da Constrngere Pk_

Relaia IMPRUMUT Nume atribut ID_CITITOR ID_COPIE DATA_IMPRUMUT DATA_RETUR Domeniu Text Text Text Text Sub-domeniu CHAR(5) VARCHAR(30) DATE DATE Opional Nu Nu Nu Nu Constrngere Pk_, fk_ Pk_, fk_ < RETURN_DATE

Capitolul 5 Introducere n SQL 143 Relaia COPIE Nume atribut ID_COPIE ID_CARTE STARE Domeniu Text Text Text Sub-domeniu CHAR(5) VARCHAR(30) VARCHAR(30) Opional Nu Nu Nu Constrngere Pk_ Fk_

Relaia AUTOR_LISTA Nume atribut ID_AUTOR ID_CARTE ROL Domeniu Text Text Text Sub-domeniu CHAR(5) VARCHAR(30) VARCHAR(30) Opional Nu Nu Nu Constrngere Pk_, fk_ Pk_, fk_

n acest moment se pot crea tabelele folosind sintaxa:

CREATE TABLE AUTHOR ( AUTHOR_ID CHAR(5) CONSTRAINT AUTHOR_PK PRIMARY KEY(AUTHOR_ID) NOT NULL, LASTNAME VARCHAR(15) NOT NULL, FIRSTNAME VARCHAR(15) NOT NULL, EMAIL VARCHAR(40), CITY VARCHAR(15), COUNTRY CHAR(2) ) CREATE TABLE AUTHOR_LIST ( AUTHOR_ID CHAR(5) NOT NULL CONSTRAINT AUTHOR_LIST_AUTHOR_FK FOREIGN KEY(AUTHOR_ID) REFERENCES AUTHOR (AUTHOR_ID), BOOK_ID CHAR(5) NOT NULL, ROLE VARCHAR(15) CONSTRAINT AUTHOR_LIST_PK PRIMARY KEY (AUTHOR_ID,BOOK_ID) NOT NULL ) CREATE TABLE BOOK ( BOOK_ID CHAR(3) CONSTRAINT BOOK_PK PRIMARY KEY(BOOK_ID)

Baze de date - Fundamente

144

CONSTRAINT AUTHOR_LIST_BOOK_FK FOREIGN KEY(BOOK_ID) REFERENCES BOOK (BOOK_ID) NOT NULL, TITLE VARCHAR(40) NOT NULL, EDITION INTEGER, YEAR INTEGER, PRICE DECIMAL(7 , 2), ISBN VARCHAR(20), PAGES INTEGER, AISLE VARCHAR(10), DESCRIPTION VARCHAR(100) ) CREATE TABLE COPY ( COPY_ID CHAR(5) CONSTRAINT COPY_PK PRIMARY KEY(COPY_ID) NOT NULL, BOOK_ID CHAR(5) CONSTRAINT COPY_BOOK_FK FOREIGN KEY(BOOK_ID) REFERENCES BOOK(BOOK_ID) NOT NULL, STATUS VARCHAR(10) ) CREATE TABLE LOAN ( COPY_ID CHAR(5) CONSTRAINT LOAN_COPY_FK FOREIGN KEY(COPY_ID) REFERENCES COPY(COPY_ID) NOT NULL, BORROWER_ID CHAR(5) CONSTRAINT LOAN_BORROWER_FK FOREIGN KEY (BORROWER_ID) REFERENCES BORROWER (BORROWER_ID) NOT NULL, LOAN_DATE DATE NOT NULL, LOAN_DAYS INTEGER NOT NULL, RETURN_DATE DATE CONSTRAINT LOAN_PK PRIMARY KEY(COPY_ID, BORROWER_ID) ) CREATE TABLE BORROWER ( BORROWER_ID CHAR(5) NOT NULL CONSTRAINT BORROWER_PK PRIMARY KEY (BORROWER_ID), LASTNAME VARCHAR(15) NOT NULL, FIRSTNAME VARCHAR(15) NOT NULL, EMAIL VARCHAR(40), PHONE VARCHAR(15), ADDRESS VARCHAR(60), CITY VARCHAR(15), COUNTRY CHAR(2) )

Capitolul 5 Introducere n SQL 145 Folosind InfoSphere Data Architect se poate transforma n mod automat modelul logic n model fizic, generndu-se n acelai timp i codul DDL corespunztor.

5.9 Rezumat
n cadrul acestui capitol se face o prezentare de ansamblu a limbajului SQL mpreun cu unele dintre caracteristicile sale. Pornind de la standardele ISO/ANSI SQL productorii introduc o serie de alte caracteristici i funcionaliti proprii. Aceste caracteristici influeneaz proiectarea i arhitectura intern a produsului, oferind performane superioare funciilor din standardul SQL. Una dintre aceste caracteristici este mecanismul de indexare folosit n cadrul bazelor de date. Comportamentul de baz al unui index este acelai n toate bazele de date, dar productorii pot introduce caracteristici suplimentare pentru a mbuntti scrierile/citirile n/din baza de date prin intermediul algoritmilor proprii. Pentru detalii i pentru obinerea unei liste complete a comenzilor SQL, a cuvintelor cheie i a sintaxei, apelai la SQL Reference Guide [5.3].

5.10 Exerciii
1. Creai un tabel cu coloane de tip ntreg, dat calendaristic i text cu valori implicite. 2. Introducei 10 rnduri n cadrul acestui tabel folosind comanda SQL INSERT. 3. Scriei o comand SQL cu o subinterogare ce are o jonciune de tip INNER JOIN. 4. Scriei o comand SQL cu o subinterogare ce are o clauz GROUP BY. 5. Scriei o comand SQL ce are o funcie agregat i clauzele WHERE, HAVING. 6. Scriei o comand SQL ce folosete ORDER BY pe mai multe coloane.

5.11 ntrebri recapitulative

1. Care sunt categoriile de baz ale limbajului SQL referitor la funcionalitate? A. Definirea datelor B. Modificarea datelor C. Controlul datelor D. Toate cele enumerate E. Nici una dintre cele enumerate 2. Cine a inventat limbajul SQL? A. Raymond F. Boyce B. E F Codd C. Donald D. Chamberlin D. A i C

Baze de date - Fundamente E. Nici unul dintre cei enumerai 3. Limbajul SQL a fost adoptat ca limbaj standard de ctre A. American National Standards Institute B. Bureau of International Standards C. International Standards Organizations D. Toate cele enumerate E. Nici una dintre cele enumerate

146

4. Care dintre urmtoarele reprezint corespondena corect dintre domeniul orientat pe obiecte i domeniul relaional? A. Nume Nume tabel B. Atribut Nume coloana C. Metod Procedur stocat D. Toate cele enumerate E. Nici una dintre cele enumerate 5. Care dintre urmtoarele funcii sunt specializate pentru lucrul cu date calendaristice? A. Year B. Dayname C. Second D. Toate cele enumerate E. Nici una dintre cele enumerate 6. Care este modalitatea implicit de ordonare a datelor n SQL? A. Cresctor B. Descresctor C. Ordine aleatoare D. Toate cele enumerate E. Nici una dintre cele enumerate 7. Nu se pot introduce mai multe rnduri cu o singur comand INSERT A. Adevrat B. Fals 8. Care dintre urmtoarele sunt tipuri corecte de jonciune intern? A. Echi-jonciunea

Capitolul 5 Introducere n SQL 147 B. Jonciunea natural C. Jonciunea ncruciat D. Toate cele enumerate E. Nici una dintre cele enumerate 9. Care dintre urmtoarele sunt tipuri corecte de jonciuni externe? A. Jonciunea extern stnga B. Jonciunea extern dreapta C. Jonciunea extern complet D. Toate cele enumerate E. Nici una dintre cele enumerate 10. Operatorul Union pstreaz duplicatele n rezultat. A. Adevrat B. Fals

6
Capitolul 6 Proceduri stocate i funcii
Procedurile stocate i funciile sunt obiecte ale bazei de date care pot ncorpora comenzi SQL i elemente de logic a aplicaiei. Prin pstrarea unei pri a logicii aplicaiei n baza de date se obine o cretere a performanelor prin reducerea considerabil a traficului de pe reea ntre baza de date i aplicaie. Suplimentar, aceste obiecte ofer o locaie centralizat de pstrare a codului, astfel nct acesta se poate refolosi. n cadrul acestui capitol se va discuta despre: Utilizarea produsului IBM Data Studio pentru elaborarea de funcii i proceduri stocate Lucrul cu funcii SQL Lucrul cu proceduri stocate

6.1 IBM Data Studio

IBM Data Studio se folosete la elaborarea de proceduri stocate i de funcii definite de ctre utilizator. IBM Data Studio este un mediu de dezvoltare i de administrare bazat pe Eclipse fiind gratuit. El nu este ncorporat n DB2, fiind oferit sub forma unei imagini separate, cu dou apariii: IDE: permite partajarea aceluiai Eclipse cu alte produse cum ar fi InfoSphere Data Architect i produsele Rational. De asemenea se ofer suport i pentru servicii de date Web. Stand-alone: Aceast versiune ofer aproape aceeai funcionalitate ca i versiunea IDE dar fr a oferi suport pentru serviciile de date Web, fiind mult mai mic ca dimensiune. Obs: Pentru o mai bun cunoatere a produsului IBM Data Studio, vedei cartea gratuit, n format electronic, Getting started with IBM Data Studio for DB2 care este parte a seriei de cri gratuite elaborate n cadrul programului DB2 on Campus. n cadrul acestui capitol vom folosi versiunea stand-alone ce poate fi descrcat de la adresa ibm.com/db2/express. Figura 6.1 prezint produsul IBM Data Studio 2.2.

Baze de date - Fundamente

150

Figura 6.1 IBM Data Studio 2.2 n acest capitol ne vom concentra atenia pe vederea Data Project Explorer marcat n colul din stnga sus al figurii. Aceast vedere este destinat dezvoltrii pe parte de server.

6.1.1 Crearea unui proiect

nainte de a elabora proceduri stocate, sau funcii definite de ctre utilizator, folosind mediul Data Studio, trebuie creat un proiect. Din meniul Data Studio se alege File -> New > Project dup care se alege Data Development Project, aa cum se arat n Figura 6.2.

Figura 6.2 Crearea unui proiect de date

Capitolul 6 Proceduri stocate i funcii 151 Se urmeaz paii din programul ajuttor pentru a introduce numele proiectului i pentru a specifica baza de date care se asociaz acestuia. Dac nu se poate realiza conectarea la baza de date, se apas butonul New din seciunea Select Connection ceea ce va conduce la apariia unei ferestre, aa cum se vede n Figura 6.3.

Figura 6.3 Parametrii unei conexiuni noi n Figura 6.3, trebuie selectat opiunea DB2 for Linux, UNIX and Windows n cmpul Select a database manager field din partea stng a figurii. Din meniul derulant JDBC driver, implicit dup alegerea DB2 for Linux, UNIX and Windows este JDBC type 4 driver afiat sub denumirea IBM Data Server Driver for JDBC and SQLJ (JDBC 4.0) Default. Se va alege acest driver implicit. Pentru cmpul host, se poate introduce o adres IP sau o adres local. n exemplul prezentat IBM Data Studio i baza de date DB2 se afl pe acelai calculator, astfel nct se introduce localhost. Se testeaz conexiunea cu baza de date cu ajutorul butonului Test Connection care se vede n colul din stnga al figurii. Dac testul este reuit se apas Finish, iar numele bazei de date se adaug listei de conexiuni ce pot fi asociate proiectului. Se alege baza de date, dup care se apas butonul Finish iar proiectul apare n vederea Data Project Explorer. n cadrul acestei vederi dac se apas pe semnul "+" se poate expanda proiectul astfel nct se pot vedea diverse foldere, cum ar fi pachete PL/SQL, scripturi SQL, proceduri stocate etc.

Baze de date - Fundamente

152

6.2 Lucrul cu proceduri stocate

O procedur stocat este un obiect al bazei de date care ncorporeaz comenzi SQL i elemente de logic a aplicaiei. Aceasta ajut la mbuntirea performanelor prin reducerea traficului de date de pe reea.

Figura 6.2 Reducerea traficului pe reea prin folosirea procedurilor stocate n colul din stnga sus al figurii, se pot vedea cteva comenzi SQL executate una dup cealalt. Fiecare comand SQL se trimite de la client la serverul de date, iar serverul de date ntoarce rezultatul napoi la client. Prin executarea mai multor astfel de comenzi SQL, crete traficul pe reea. n partea de jos a figurii se vede o metod alternativ care propune un trafic mai redus. Aceast a doua metod apeleaz o procedur stocat, numit myproc pstrat pe server, care conine acelai cod SQL; dup care, pe partea de client (n stnga), se folosete comanda CALL pentru a apela procedura. Cea de-a doua metod este mult mai eficient, deoarece exist un singur apel al comenzii care se trimite pe reea, fiind returnat un singur rezultat napoi la client. Procedurile stocate pot fi utile n cadrul bazei de date i din motive de securitate. De exemplu, se poate permite utilizatorilor s acceseze tabele sau vederi numai prin intermediul procedurilor stocate, ceea ce asigur serverul i ine la distan utilizatorii care altfel ar putea accesa informaii cheie pe care nu ar trebui s le obin. Acest lucru este benefic deoarece utilizatorii nu au nevoie de anumite privilegii explicite pe tabele sau vederi, ci doar de acele privilegii care s le permit accesarea procedurilor stocate.

6.2.1 Tipuri de proceduri

n principal, exist dou tipuri de proceduri stocate: procedurile SQL i procedurile externe. Procedurile SQL sunt scrise n limbaj SQL, iar procedurile externe sunt scrise ntr-un limbaj

Capitolul 6 Proceduri stocate i funcii 153 gazd, dar mai exist i alte diferene importante ntre acestea att n comportament ct i n pregtire. Procedurile SQL i procedurile externe sunt alctuite dintr-o parte de definire i codul propriu-zis al acestora. Att procedurile SQL ct i procedurile externe au nevoie de urmtoarele informaii: Numele procedurii. Parametrii de intrare i de ieire. Limbajul n care se scrie procedura. Pentru procedura SQL acesta este SQL. Informaiile ce trebuie folosite la apelul procedurii, cum ar fi opiunile adoptate la execuie, timpul de execuie al acesteia precum i dac procedura ntoarce sau nu un rezultat. Exemplul urmtor prezint definiia unei proceduri SQL.
CREATE PROCEDURE UPDATESALARY (IN EMPNUMBR CHAR(10), IN RATE DECIMAL(6,2)) LANGUAGE SQL UPDATE EMP SET SALARY = SALARY * RATE WHERE EMPNO = EMPNUMBR (1) (2) (3) (4)

n acest exemplu: 1. Numele procedurii este UPDATESALARY. 2. Exist doi parametri, EMPNUMBR ce are tipul de date CHAR(10), i RATE ce are tipul de date DECIMAL(6,2). Ambii sunt parametri de intrare. 3. LANGUAGE SQL arat faptul c este vorba de o procedur SQL, astfel nct corpul procedurii furnizeaz ceilali parametri. 4. Corpul procedurii conine o comand SQL UPDATE care actualizeaz valorile din tabelul cu angajai. Exemplul urmtor prezint o definiie a unei proceduri externe echivalente scris n limbajul COBOL. Programul procedurii stocate care actualizeaz salariile anagajailor se numete UPDSAL.
CREATE PROCEDURE UPDATESALARY (IN EMPNUMBR CHAR(10), IN RATE DECIMAL(6,2)) LANGUAGE COBOL EXTERNAL NAME UPDSAL; (1) (2) (3) (4)

n acest exemplu: 1. Numele procedurii stocate este UPDATESALARY.

Baze de date - Fundamente

154

2. Procedura are doi parametri, EMPNUMBR ce are tipul de date CHAR(10) i RATE care are tipul de date DECIMAL(6,2). Ambii sunt parametri de intrare. 3. LANGUAGE COBOL arat c avem o procedur extern, astfel nct codul procedurii stocate se afl ntr-un program COBOL separat. 4. Numele modulului care se ncarc i care conine programul executabil al procedurii stocate este UPDSAL.

6.2.2 Crearea unei proceduri stocate

Pentru a crea o procedur stocat Java, PL/SQL sau SQL PL n Data Studio, se urmeaz paii de mai jos. Se observ faptul c procedurile stocate scrise n alte limbaje de programare nu pot fi create cu Data Studio. n continuare se va prezenta, ca exemplu, o procedur SQL (reprezentat prin SQL PL ca limbaj al procedurii stocate), dar pai asemntori se aplic i n situaia folosirii limbajelor Java sau PL/SQL. Pas 1: Scrierea sau generarea codului procedurii stocate Atunci cnd se dorete crearea unei proceduri stocate, se apas butonul din dreapta al mouse-ului atunci cnd acesta se afl deasupra folderului Stored Procedures i se alege New -> Stored Procedure. Se introduce informaia cerut n programul ajuttor New Stored Procedure adic, proiectul cruia i se asociaz procedura, numele i limbajul procedurii, precum i comenzile SQL folosite n cadrul procedurii. Implicit, Data Studio ofer un exemplu de comand SQL. Se pstreaz valorile implicite i se apas butonul Finish fiind creat procedura cu ajutorul unui ablon de cod, aa cum se vede din Figura 6.3.

Capitolul 6 Proceduri stocate i funcii 155 Figura 6.3 Exemplu de procedur stocat n Figura 6.3, se prezint codul procedurii MYPROCEDURE aa cum a fost generat. Tot acest cod se poate nlocui cu un alt cod propriu. Pentru simplitate, se va folosi n cadrul acestui capitol exemplul de procedur de mai sus, ca i cum l-am fi scris noi. Pas 2: Punerea n mediul de funcionare a procedurii stocate Dup ce a fost creat, procedura trebuie depus n mediul real de funcionare, motiv pentru care se merge n vederea Data Project Explorer, se apas butonul din dreapta al mouse-ului i se alege Deploy. Punerea n mediul real de funcionare este esenial pentru comanda CREATE PROCEDURE, deoarece compileaz procedura i o stocheaz n baza de date, aa cum se vede din Figura 6.4.

Figura 6.4 Punerea n mediul de funcionare a procedurii stocate Dup selectarea opiunii Deploy, n seciunea Deploy options, se las valorile implicite i se apas butonul Finish. Pas 4: Executarea procedurii Dup depunerea procedurii n mediul de funcionare, aceasta poate fi executat prin selectare, apsarea butonului din dreapta al mouse-ului i alegerea comenzii Run. Rezultatele vor apare pe fila Results n colul din dreapta jos al interfeei grafice Data Studio aa cum se vede n Figura 6.5.

Baze de date - Fundamente

156

Figura 6.5 Rezultatul obinut dup executarea procedurii stocate Pentru a executa o procedur stocat din DB2 Command Window sau din Command Editor, se poate folosi comanda CALL <nume procedura>. De reinut este faptul c mai nti trebuie asigurat conexiunea la baza de date, deaorece acesta este locul n care se afl procedura stocat. Figura 6.6 prezint acest lucru.

Figura 6.6 Apelul unei proceduri stocate din DB2 Command Window

Capitolul 6 Proceduri stocate i funcii 157 Aa cum se procedeaz cu o procedur stocat n DB2 Command Window, la fel se procedeaz i ntr-o aplicaie Java, C, Visual Basic .a.m.d. Nu trebuie dect s se foloseasc sintaxa corect pentru fiecare tip de limbaj de programare.

6.2.3 Modificarea i eliminarea unei proceduri stocate

Exist dou modaliti de modificare a unei proceduri stocate existente: 1. Se elimin procedura existent i se recreeaz din nou cu noua definiie. 2. Se folosete sintaxa CREATE OR REPLACE PROCEDURE' n locul sintaxei CREATE PROCEDURE'. Se mai poate folosi i comanda ALTER PROCEDURE, dar aceasta poate fi folosit doar pentru modificarea anumitor proprieti ale procedurii i nu codul propriu-zis. Pentru a elimina o procedur, se folosete numele complet al acesteia n comanda DROP PROCEDURE aa cum se prezint n exemplul de mai jos.
drop procedure myschema.EMPLOYEE_COUNT

Pentru a modifica o procedur este de preferat s se foloseasc sintaxa CREATE OR REPLACE PROCEDURE n locul eliminrii i recrerii procedurii, deoarece eliminarea unei proceduri poate avea alte consecine, cum ar fi invalidarea altor obiecte ce depind de procedura respectiv. Folosind sintaxa CREATE OR REPLACE PROCEDURE o astfel de situaie nu va mai avea loc.

6.3 Operarea cu funcii

O funcie SQL este o metod sau o comand care poate avea zero sau mai muli parametri de intrare, dar care returneaz o singur valoare. Toate bazele de date au o serie de funcii predefinite destinate efecturii de operaii matematice, manipulrii cu iruri de caractere sau introducerii altor metode specifice bazelor de date. Utilizatorul poate, la rndul su, si elaboreze propriile funcii, cunoscute sub denumirea de funcii definite de ctre utilizator, pentru a-i rezolva anumite cerine care nu pot fi realizate cu funciile puse la dispoziie de ctre sistem.

6.3.1 Tipuri de funcii

Funciile pot fi clasificate n urmtoarele tipuri n funcie de comportamentul acestora i de setul de date de intrare cu care opereaz: Scalare - Agregat - ir de caractere Tabelare n plus, mai pot exista funcii create n cadrul sistemului care sunt funcii oferite de ctre sistem sau funcii definite de ctre utilizator. O funcie definit de ctre utilizator este o

Baze de date - Fundamente

158

extensie a limbajului SQL. Este un program de dimensiuni reduse ce poate fi scris n mod asemntor unui subprogram scris ntr-un limbaj gazd. O funcie definit de ctre utilizator, reprezint de multe ori cea mai bun soluie ntr-o aplicaie SQL, deoarece aceasta poate fi apelat n cadrul unei comenzi SQL. n DB2, se pot crea funcii scalare sau tabelare folosind SQL PL, PL/SQL, C/C++, Java, CLR (Common Language Runtime), i OLE (Object Linking and Embedding). 6.3.1.1 Funcii scalare O funcie scalar este o funcie care, pentru fiecare set de unul sau mai muli parametri scalari ntoarce o singur valoare. Funciile scalare se folosesc de obicei la manipularea irurilor de caractere sau la efectuarea de operaii matematice simple n cadrul comenzilor SQL. Funciile scalare nu pot conine comenzi SQL care s modifice starea bazei de date, adic comenzile INSERT, UPDATE i DELETE nu sunt permise. De exemplu, funcia predefinit LENGTH ntoarce lungimea unui ir de caractere, aa cum se prezint mai jos:
SELECT length('Mary') FROM sysibm.sysdummy1

Comanda SQL de mai sus executat atunci cnd se realizeaz conexiunea la baza de date DB2 ntoarce valoarea 4 care reprezint lungimea irului de caractere 'Mary'. Funciile scalare pot fi folosite oriunde n cadrul unei comenzi SQL acolo unde este posibil, adic, de exemplu, ntr-o list de selecie, sau ntr-o clauz FROM. De exemplu:
SELECT EMPNO, LASTNAME, YEAR(CURRENT DATE - BRTHDATE) FROM EMPLOYEE WHERE WORKDEPT = 'D01'

Exemplul de mai sus introduce funcia YEAR care este folosit pentru a extrage anul dup efectuarea operaiei "CURRENT DATE - BRTHDATE". Funciile scalare predefinite se execut eficient deoarece se execut pe serverul bazei de date ca parte a unei comenzi SQL de care se asociaz. Atunci cnd se folosete n cadrul unor predicate, o funcie scalar poate mbunti performana general a interogrii. Atunci cnd o funcie scalar se aplic pe mai multe rnduri, aceasta poate aciona sub forma unui filtru, limitnd numrul de rnduri ce trebuie returnate ctre client. 6.3.1.1.1 Funcii agregat O funcie agregat este o funcie care, pentru fiecare set de unul sau mai muli parametri scalari, returneaz o singur valoare scalar. De exemplu, AVG(COL_NAME) ntoarce valoarea medie a coloanei COL_NAME. 6.3.1.1.2 Funcii folosite pentru operarea cu iruri de caractere O funcie folosit pentru operarea cu iruri de caractere este o funcie care accept cel puin unul sau mai muli parametri scalari i zero sau mai muli parametri de tip ntreg pentru o singur valoare scalar (de tip ir de caractere sau ntreg). De exemplu, SUBSTR('abcdefghi',3,4) are trei parametri (irul surs, subirul locului de ncepere i

Capitolul 6 Proceduri stocate i funcii 159 numrul de caractere ncepnd cu locul de pornire) i returneaz subirul corespunztor. n exemplul de fa, rezultatul este 'cdef'. 6.3.1.2 Funcii tabelare Funciile tabelare returneaz ca rezultat un tabel. Acestea pot fi folosite n clauza FROM a unei interogri. Funciile tabelare, spre deosebire de funciile scalare, pot modifica starea bazei de date, motiv pentru care se pot folosi comenzile INSERT, UPDATE i DELETE. Exemple de funcii tabelare predefinite n SQL sunt SNAPSHOT_DYN_SQL() i MQREADALL(). Funciile tabelare sunt asemntoare vederilor, dar deoarece permit modificri ale datelor (INSERT, UPDATE i DELETE) sunt mult mai puternice. Mai jos se prezint un exemplu de funcie tabelar care afieaz angajaii din departamente:
CREATE FUNCTION getEnumEmployee(p_dept VARCHAR(3)) RETURNS TABLE (empno CHAR(6), lastname VARCHAR(15), firstnme VARCHAR(12)) SPECIFIC getEnumEmployee RETURN SELECT e.empno, e.lastname, e.firstnme FROM employee e WHERE e.workdept=p_dept

6.3.2 Crearea unei funcii

La fel ca n cazul procedurilor stocate, se poate folosi instrumentul IBM Data Studio pentru a crea o funcie definit de ctre utilizator, singura diferen fiind aceea c trebuie apsat butonul din dreapta al mouse-ului atunci cnd acesta se afl deasupra folderului userdefined functions, urmnd apoi toi paii descrii anterior n cazul crerii unei proceduri. Comanda CREATE FUNCTION se folosete pentru a nregistra sau defini o funcie definit de ctre utilizator sau un model de funcie pe serverul de baze de date curent. Mai jos se prezint o sintax simplificat de utilizare a acestei comenzi:
>>-CREATE--+------------+--FUNCTIONnume-functie--------------> '-OR REPLACE-' .-IN------. >--(--+---------+--nume-parametru--| tip-data1 |--+-------------+--|-)--> | | '-| clauza-implicita |-' +-OUT-----+ '-INOUT---' >-- RETURNS--+-| tip-data2 |-------------+--| lista-optiuni |-----> '-+-ROW---+--| lista-coloane |-' '-TABLE-' >--| corp-functie-SQL |---------------------------------------><

Baze de date - Fundamente

160

De exemplu, urmtoarea funcie SQL PL ntoarce un ir de caracatere n ordine invers:

CREATE FUNCTION REVERSE(INSTR VARCHAR(40)) RETURNS VARCHAR(40) DETERMINISTIC NO EXTERNAL ACTION CONTAINS SQL BEGIN ATOMIC DECLARE REVSTR, RESTSTR VARCHAR(40) DEFAULT ''; DECLARE LEN INT; IF INSTR IS NULL THEN RETURN NULL; END IF; SET (RESTSTR, LEN) = (INSTR, LENGTH(INSTR)); WHILE LEN > 0 DO SET (REVSTR, RESTSTR, LEN) = (SUBSTR(RESTSTR, 1, 1) CONCAT REVSTR, SUBSTR(RESTSTR, 2, LEN - 1), LEN - 1); END WHILE; RETURN REVSTR; END @

Pentru informaii complete despre sintaxa CREATE FUNCTION precum i a opiunilor posibile, vedei DB2 v9.7 Information Center.

6.3.3 Apelarea unei funcii

Funciile pot fi apelate n cadrul unei comenzi SQL sau n cadrul oricrei alte operaii de manipulare a datelor. Funciile nu pot fi apelate n mod explicit folosind comanda CALL. Funciile obinuite se apeleaz dintr-o comand SELECT sau VALUES. De exemplu, funcia REVERSE definit anterior poate fi apelat astfel:
SELECT reverse(col_name) from myschema.mytable SAU VALUES reverse('abcd')

n cazul unei funcii tabelare, aceasta se apeleaz ntr-o clauz FROM a unei comenzi SQL deoarece ntoarce ca rezultat un tabel. Atunci cnd se folosete funcia special TABLE() trebuie utilizat un alias dup apelare. De exemplu, pentru a apela funcia tabelar getEnumEmployee creat anterior n cadrul acestei seciuni, se va folosi o comand SQL de genul celei prezentate n Figura 6.1 de mai jos:

Capitolul 6 Proceduri stocate i funcii 161

Figura 6.1 Apelarea unei funcii tabelare.

6.3.4 Modificarea i eliminarea unei funcii

Exist dou modaliti de modificare a unei funcii existente definit de ctre utilizator: 1. Eliminarea funciei existente i recrearea acesteia cu o nou definiie. 2. Folosirea sintaxei CREATE OR REPLACE FUNCTION n locul comenzii CREATE FUNCTION. Mai exist i posibilitatea folosirii comenzii ALTER FUNCTION, dar aceasta se folosete mai degrab pentru modificarea unor proprieti i nu pentru modificarea codului propriuzis. Pentru a elimina o funcie se folosete numele complet al acesteia n cadrul comenzii DROP FUNCTION aa cum se vede din exemplul de mai jos:
DROP FUNCTION myschema.reverse

Pentru modificarea unei funcii se prefer folosirea sintaxei CREATE OR REPLACE FUNCTION n locul eliminrii i recrerii funciei respective, deoarece eliminarea unei funcii poate avea alte consecine, cum ar fi invalidarea altor obiecte din baza de date care depind de acea funcie. Folosind sintaxa CREATE OR REPLACE FUNCTION astfel de situaii nu mai pot s apar.

6.4 Rezumat
Procedurile stocate i funciile sunt instrumente foarte importante i utile pentru implementarea metodelor specifice domeniului care nu sunt disponibile n cadrul sistemului n mod implicit. Procedurile stocate i funciile au nevoie de permisiunea EXECUTE pentru ca utilizatorii s le poat apela. Acestea ofer o modalitate de mbuntire a performanelor prin reducerea traficului de pe reea, prin centralizarea codului n cadrul bazei de date i prin creterea securitii acesteia.

6.5 Exerciii
1. Creai o procedur stocat SQL PL folosind IBM Data Studio. Folosind baza de date SAMPLE din DB2, procedura trebuie s preia identificatorul unui angajat ca parametru de intrare i s extrag toate coloanele corespunztoare acestui angajat din tabelul EMPLOYEE.

Baze de date - Fundamente

162

2. S se creeze o funcie definit de ctre utilizator cu aceleai cerine din exerciiul (1). 3. S se creeze o funcie SQL care nu accept parametri de intrare i returneaz numlele unei zile a sptmnii sub forma unui ir de caractere (luni, mari etc.) prin preluarea datei curente a sistemului ca dat de intrare. 4. S se creeze o funcie SQL care are o dat calendaristic ca parametru de intrare i returneaz numele unei zile a sptmnii sub forma unui ir de caractere (luni, mari etc.). 5. S se creeze o procedur stocat fr parametri de intrare care s returneze numrul de tabele din baza de date. 6. S se creeze o procedur care primete numele unui tabel ca parametru de intrare i ntoarce numrul de rnduri din acel tabel.

6.6 ntrebri recapitulative

1. Care dintre urmtoarele este o funcie corect? A. Select B. Update C. Count D. Delete E. Nici una dintre cele enumerate 2. Care dintre urmtoarele nu este o funcie corect? A. avg B. count C. insert D. substr E. Nici una dintre cele enumerate 3. Care dintre urmtoarele este o funcie scalar? A. avg B. count C. max D. substr E. Toate cele enumerate 4. Care dintre urmtoarele nu este o funcie scalar? A. trim

Capitolul 6 Proceduri stocate i funcii 163 B. upper C. min D. substr E. Nici una dintre cele enumerate 5. Care dintre urmtoarele este o funcie agregat? A. lcase B. year C. max D. substr E. Nici una dintre cele enumerate 6. Care dintre urmtoarele nu este o funcie agregat? A. sum B. min C. max D. len E. Nici una dintre cele enumerate 7. Care dintre urmtoarele este o funcie pentru operarea cu iruri de caractere? A. avg B. year C. max D. substr E. Nici una dintre cele enumerate 8. Care dintre limbajele de programare sunt suportate de ctre Data Studio pentru a crea o procedur stocat? A. SQL PL B. PL/SQL C. Java D. Toate cele enumerate E. Nici unul dintre cele enumerate 9. O funcie poate fi apelat folosind comanda VALUES A. Adevrat

Baze de date - Fundamente B. Fals 10. O procedur poate fi apelat folosind comanda CALL A. Adevrat B. Fals

164

7
Capitolul 7 Folosirea SQL n aplicaii
n capitolele precedente s-a discutat despre limbajul structurat de interogare (SQL), care reprezint limbajul standardizat de lucru cu bazele de date, de manipulare a obiectelor din cadrul acestora i de extragere a datelor existente. Acest capitol va prezenta conceptele cu ajutorul crora poate fi apelat codul SQL din cadrul aplicaiilor care, n general, sunt scrise n limbajele obinuite cum ar fi C, C++, Java, .NET i altele. n cadrul acestui capitol v vei familiariza cu: Conceptul de tranzacie Operarea cu cod SQL ncorporat Diferenele dintre codul SQL static i dinamic Interfeele de programare a aplicaiilor pentru baze de date (API), cum ar fi ODBC, CLI i JDBC Tehnologia pureQuery

7.1 Folosirea SQL n aplicaii: vedere de ansamblu

SQL este limbajul standard ce permite utilizatorilor s comunice cu serverul bazei de date, dar pentru a scrie aplicaii complexe de mari dimensiuni care folosesc baze de date, utilizarea doar a limbajului SQL nu este suficient. Limbajele folosite la elaborarea aplicaiilor, cum ar fi C, C++ sau Java ofer utilizatorilor un control mai riguros i o logic funcional mai puternic. Aceste limbaje, cunoscute sub denumirea de limbaje gazd se pot integra bine cu limbajul SQL pentru a putea comunica cu baza de date n cadrul aplicaiilor. n acest caz, se spune c limbajul SQL este ncorporat n aplicaia gazd. Alte tehnici permit utilizarea direct a apelurilor ctre interfaa de programare a aplicaiilor (API) pentru a obine accesul la baza de date. De exemplu, ODBC, CLI i JDBC sunt astfel de interfee de programare aplicaiilor folosite n cazul bazelor de date. Toate tehnicile de folosire a limbajului SQL precum i a modului n care acestea interacioneaz cu baza de date sunt prezentate n Figura 7.1 de mai jos i vor fi discutate n detaliu n seciunile urmtoare.

Baze de date - Fundamente

166

Figura 7.1 Rezumatul tuturor tehnicilor folosite n aplicaiile SQL

7.2 Ce este o tranzacie?

nainte de a intra n detaliile diferitelor tehnici utilizate n aplicaiile ce folosesc SQL, v vei familiariza cu conceptul de tranzacie. O tranzacie sau unitate de operare este un grup de operaii efectuate n baza de date care trebuie executate cu succes n ntregime pentru ca tranzacia s reueasc. Dac una dintre operaii nu reuete, tranzacia este anulat. De exemplu, dac o banc trebuie s transfere 1000 de dolari din contul A n contul B, atunci trebuie s reueasc fiecare dintre urmtoarele secvene nainte s se efectueze transferul: Se reduce balana contului A cu valoarea de 1000 Se mrete balana contului B cu valoarea de 1000 n SQL, cerinele de mai sus se rezolv cu ajutorul a dou comenzi SQL. Dac una sau mai multe dintre aceste comenzi eueaz, transferul de bani nu reuete. Din acest motiv se spune c cele dou comenzi din exemplul de mai sus alctuiesc o tranzacie. Dac o tranzacie nu reuete, se realizeaz o rulare napoi n baza de date astfel nct datele si pstreze consistena, adic s se afle n starea de dinainte de nceperea tranzaciei. Cele mai ntlnite exemple de aplicai ce folosesc tranzacii sunt, de exemplu, sistemele de rezevri online, sistemele de cumprturi online, .a.m.d.

Capitolul 7 Folosirea SQL n aplicaii 167

7.3 SQL ncorporat

Aa cum i arat i numele, SQL ncorporat presupune ncorporarea codului SQL n cadrul aplicaiilor gazd scrise n limbaje de programare de nivel nalt, cum ar fi C, C++, sau COBOL. Aplicaia gazd conine logica de baz necesar, apelnd comenzile SQL la nevoie pentru a obine informaii din baza de date. Atunci cnd se ntmpl acest lucru, apare o ntrebare: cum se pot compila aplicaiile scrise n limabjul de programare de nivel nalt care conin cod SQL ncorporat, deoarece nici unul dintre limbajele de programare de acest tip nu poate compila i valida sintaxa SQL? Rspunsul la aceast ntrebare este oferit prin intermediul operaiei de pre-compilare. n cazul sistemului DB2, acesta are un pre-compilator care efectueaz conversiile necesare sintaxei SQL direct n apeluri de servicii API la execuia DB2. Codul pre-compilat este apoi compilat i ataat folosind instrumentele de dezvoltare ale limbajului respectiv. Comenzile SQL ncorporate n limbajul gazd trebuie identificate cu ajutorul unei propoziii sau a unui bloc. n cazul C, C++ i COBOL, comanda de iniializare este EXEC SQL. Aceast comand este urmat de comanda SQL care se va executa i se termin cu simbolul (;), care reprezint terminatorul comenzii. De exemplu:
EXEC SQL UPDATE employee.details SET emp_desig = 'Mgr' WHERE emp_desig = 'Asst Mgr';

Comenzile SQL pot fi ncorporate i n cadrul aplicaiilor Java, iar aplicaiile ce conin cod SQL ncorporat sunt denumite aplicaii SQLJ. n mod asemntor comenzii de iniializare din C, EXEC SQL, n aplicaiile SQLJ se folosete comanda de iniializare #sql. De exemplu, comanda SQL UPDATE din exemplul anterior arat astfel n aplicaia SQLJ:
#sql { UPDATE employee.details SET emp_desig = 'Mgr' WHERE emp_desig = 'Asst Mgr'};

Ambele exemple prezentate anterior conin comenzi SQL statice deoarece numele tabelului, numele de coloane i alte obiecte ale bazei de date sunt cunoscute i rmn constante de fiecare dat cnd ruleaz aplicaia. Dac aceste obiecte ar fi introduse n program n timpul execuiei acestuia, vom vorbi despre comenzi SQL dinamice deoarece comanda SQL este determinat la momentul execuiei. Vom discuta despre comenzile statice i dinamice mai trziu, n seciunile urmtoare.

7.3.1 Comenzi SQL statice

Comenzile SQL statice reprezint modalitatea tradiional de elaborare a aplicaiilor cu SQL ncorporat. Aplicaiile ce conin cod SQL static sunt destinate situaiilor n care aplicaiile vor folosi de fiecare dat cnd interacioneaz cu baza de date aceleai comenzi

Baze de date - Fundamente

168

SQL. De exemplu, o aplicaie care actualizeaz stocul de inventar, va folosi ntotdeauna aceeai comand SQL pentru a modifica stocul. n mod asemntor, sistemul de rezervare online va actualiza ntotdeauna acelai tabel i va marca aceeai coloan pentru rezervare. Pentru a vedea situaia rezervrilor la un moment dat, se va folosi aceeai comand SELECT pe acelai tabel. O aplicaie SQL ncorporat n care sintaxa SQL este cunoscut complet dinainte i n care comenzile SQL sunt ncorporate n codul surs al aplicaiei este cunoscut sub denumirea de aplicaie SQL ncorporat static. Singura intrare (intrri) care trebuie introduse n comenzile SQL din cadrul aplicaiei este (sunt) valorile de date curente ce trebuie inserate n cadrul tabelelor sau valorile predicatelor din comenzile SQL. Aceste valori de intrare sunt introduse n comenzile SQL cu ajutorul variabilelor gazd. 7.3.1.1 Variabile gazd Variabilele gazd sunt variabile ale limbajului de programare ce pot fi folosite doar pentru procesarea codului SQL static. Aceste variabile gazd trebuie declarate n aplicaie nainte de a fi folosite. Se recomand ca aceste variabile s fie iniializate folosind valori implicite, n momentul declarrii. O alt recomandare este aceea de a se aduga la numele variabilei gazd sufixul _hv to pentru a face diferena de celelalte variabile sau de nume de coloane. S vedem fragmentul de cod SQL ncorporat ntr-o aplicaie scris n limbajul C prezentat n Lista 7.1
EXEC SQL SELECT INTO FROM WHERE emp_name, emp_dept, emp_salary :name_hv, :dept_hv, :salary_hv employee.details emp_id = :id_hv ;

EXEC SQL UPDATE employee.details SET emp_salary = :new_salary_hv WHERE emp_id = :id_hv ;

Lista 7.1 - Fragmentul de cod SQL ncorporat ntr-o aplicaie scris n limbajul C n ambele comenzi, numele tabelului (employee.details) i numele coloanelor (emp_name, emp_dept etc.) sunt toate hard-codate. Introducerea informaiei n comenzile SQL la momentul execuiei se face cu ajutorul variabilelor gazd (id_hv, dept_hv etc.). Simbolul (:) din faa fiecrei variabile gazd este parte a sintaxei codului SQL ncorporat. 7.3.1.2 Structura unei aplicaii cu cod SQL ncorporat Spre deosebire de limbajul gazd, toate aplicaiile care au cod SQL ncorporat sunt alctuite din urmtoarele trei elemente principale necesare pregtirii i executrii comenzilor SQL.

Capitolul 7 Folosirea SQL n aplicaii 169 O seciune declarativ, DECLARE SECTION, pentru declararea variabilelor gazd. Corpul principal al aplicaiei, care este alctuit din pregtirea i execuia comenzilor SQL. Plasarea de elemente care fie ncheie cu succes, fie ruleaz napoi modificrile fcute de comenzile SQL (dac este necesar). Lista 7.2 prezint un fragment de cod SQL ncorporat ntr-o aplicaie scris n limbaj C care folosete cele trei elemente.
int getDetails( int employee_id, double new_salary) { int ret_code = 1; EXEC SQL INCLUDE SQLCA; EXEC SQL BEGIN DECLARE SECTION; sqlint32 id_hv = 0; // identificatorul angajatului char name_hv[129] = {0}; // numele angajatului char dept_hv[129] = {0}; // departamentul angajatului double salary_hv = 0; // salariul angajatului EXEC SQL END DECLARE SECTION; // Se copiaza identificatorul si salariul din aceast functie // n variabilele gazda id_hv = employee_id; salary_hv = new_salary; // Se foloseste comanda UPDATE pentru a introduce noul salariu al unui // angajat EXEC SQL UPDATE employee.details SET emp_salary = :salary_hv WHERE emp_id = :id_hv; if (SQLCODE < 0) { printf(\n UPDATE SQL Error:%ld\n,SQLCODE); EXEC SQL ROLLBACK; // Tranzactia se ruleaza inapoi ret_code = 0; // eroare } else { EXEC SQL COMMIT; // Tranzactia s-a realizat cu succes // Se foloseste o comanda SELECT pentru a parcurge salariile // actualizate EXEC SQL

Baze de date - Fundamente

SELECT INTO FROM WHERE emp_name, emp_dept, emp_salary :name_hv, :dept_hv, :salary_hv employee.details emp_id = :id_hv;

170

if (SQLCODE < 0) { printf(\n SELECT SQL Error:%ld\n,SQLCODE); Ret_code = 0; } else { // Se afiseaza salariile actualizate printf(\n Employee name: %s,name_hv); printf(\n Employee Id: %d,id_hv); printf(\n Employee Department: %s,dept_hv); printf(\n Employee New Salary: Rs. %ld p.a,salary_hv); } } return ret_code; }

Lista 7.2 Structura unei aplicaii scris n limbajul C ce conine cod SQL ncorporat Exemplul de mai sus arat felul n care comenzile SQL pot fi ncorporate n cadrul unei aplicaii scrise n limbajul de programare C. Alte limbaje de programare cum ar fi C++, COBOL, Java, trebuie s foloseasc aceleai trei elemente principale ca n exemplul de mai sus. 7.3.1.3 Zona de comunicaii SQL, SQLCODE i SQLSTATE Zona de comunicaii SQL (SQLCA) este o structur de date care se folosete ca mediu de comunicare dintre serverul bazei de date i clienii si. Structura de date SQLCA conine un numr de variabile care sunt actualizate la sfritul fiecrei execuii. SQLCODE este una dintre variabilele din structura de date care este setat pe valoarea 0 (zero) dup fiecare execuie SQL. Dac comanda SQL se ncheie cu un mesaj de avertizare, variabila trece pe o valoare pozitiv, diferit de zero, iar dac se ncheie cu eroare trece pe o valoare negativ. Valorile SQLCODE pot reprezenta fie probleme de hardware, fie de sistem de operare; de exemplu, atunci cnd sistemul de fiiere este plin, sau atunci cnd apare o eroare la accesarea unui fiier. Se recomand s se urmreasc valorile returnate de ctre SQLCODE dup fiecare execuie SQL aa cum se arat n aplicaia de mai sus. SQLSTATE este o alt variabil oferit de ctre SQLCA ce pstreaz coduri de retur sub form de iruri de caractere care prezint rezultatul celei mai recente comenzi SQL executate. SQLSTATE prezint un mesaj generic, standardizat, folosit de ctre diveri productori de baze de date.

Capitolul 7 Folosirea SQL n aplicaii 171 7.3.1.4 Paii necesari pentru compilarea unei aplicaii SQL statice Aa cum s-a artat anterior aplicaiile SQL ncorporate trebuie s fie pre-compilate nainte de a fi folosite de pre-compilatorul DB2. Pre-compilatorul verific comenzile SQL din cadrul codului surs, le nlocuiete cu API-urile echivalente folosite la execuie de DB2 i suportate de ctre limbajul gazd i rescrie rezultatul (mpreun cu comenzile SQL comentate) ntr-un fiier nou care poate fi compilat i asociat cu ajutorul instrumentelor de dezvoltare folosite de limbajul gazd. Pre-compilatorul DB2 se apeleaz cu ajutorul comenzii DB2 PRECOMPILE (sau PREP). Pre-compilatorul DB2 efectueaz urmtoarele activiti: 1. Valideaz sintaxa SQL pentru fiecare comand SQL codat i introduce tipurile de date corespunztoare pentru variabilele gazd prin compararea acestora cu tipurile de date ale coloanelor. De asemenea se determin metoda de conversie a datelor ce trebuie folosit la parcurgerea sau inserarea datelor n baza de date. 2. Reevalueaz asocierile cu obiectele bazei de date, creeaz planurile de acces i le introduce n cadrul unui pachet din baza de date. Planul de acces al unei comenzi SQL reprezint calea optim ctre obiectele bazei de date la care face referire codul SQL. Optimizatorul DB2 estimeaz planurile de acces la momentul pre-compilrii unei comenzi SQL ncorporate static. Aceast estimare se bazeaz pe informaia disponibil n cadrul optimizatorului la momentul pre-compilrii, care este urmrit prin intermediul cataloagelor sistemului. Suplimentar, fiecare aplicaie este asociat pachetului corespunztor din baza de date. Avantajul pstrrii acestor planuri de acces n baza de date este acela c ori de cte ori se execut aplicaia, se parcurge i se execut planul de acces corespunztor din cadrul pachetului, ceea ce asigur o cretere a vitezei de execuie a codului SQL, deoarece este cunoscut dinainte calea optim de accesare a obiectelor din baza de date. n acest moment se pot stabili comenzile SQL statice al cror plan de acces poate fi determinat, cunoscut dinainte i pstrat n baza de date pentru a crete viteza de execuie. Din acest motiv, n cazul unei comenzi SQL care urmeaz s fie ncorporat static n cadrul unei aplicaii, sintaxa acesteia trebuie cunoscut la momentul pre-compilrii. Odat ce aplicaia SQL ncorporat este pre-compilat i introdus n baza de date, aceasta poate fi compilat i asociat cu ajutorul instrumentelor de dezvoltare ale limbajului gazd. De asemenea, este posibil s se amne asocierea aplicaiei pn la momentul execuiei. Acest pas poate fi fcut cu ajutorul clauzei BINDFILE <fisier_de_asociere> din comanda PRECOMPILE, care creeaz un fiier de asociere ce conine datele necesare crerii pachetului din baza de date. Acest <fisier_de_asociere> poate fi apoi utilizat de ctre utilitarul DB2 BIND pentru a crea un pachet n baza de date cruia s-i ataezeze aplicaia. Acest tehnic este cunoscut sub denumirea de asociere ntrziat Figura 7.2 de mai jos descrie ntregul proces de compilare a codului SQL. Aceast diagram reprezint setul general de aciuni ce trebuie efectuate pe perioada compilrii i

Baze de date - Fundamente poate fi diferit n funcie de compilatorul folosit.

172

Figura 7.2 Compilarea i execuia codului static SQL n cazul aplicaiilor SQLJ, asemntor pre-compilatorului pentru aplicaii SQL ncorporate, exist un modul, SQLJ translator care detecteaz clauzele SQL din cadrul aplicaiilor SQLJ pe care le convertete n comenzi JDBC. JDBC se va prezenta mai n detaliu n seciunile urmtoare.

Capitolul 7 Folosirea SQL n aplicaii 173

7.3.2 Comenzi SQL dinamice

Comenzile SQL dinamice conin parametri ale cror valori nu sunt cunoscute pn la momentul execuiei, fiind introduse cu ajutorul aplicaiei. Comenzile SQL dinamice se ntlnesc foarte des n cadrul aplicaiilor interactive n care utilizatorul introduce cea mai mare parte a informaiilor necesare pentru a crea comanda SQL dorit. S lum de exemplu aplicaia prezentat n Figura 7.3, "Formular de cutare a unui angajat", care face parte dintr-o aplicaie de resurse umane din cadrul unei companii.

Figura 7.3 - Formular de cutare a unui angajat Formularul de mai sus permite utilizatorului s ofere detaliile necesare stabilirii rolului unui angajat. Valorile de intrare sunt fie Nume angajat fie Identificator angajat. n cazul acestui tip de aplicaii, codul SQL nu poate fi cunoscut dect n momentul execuiei, fiind un exemplu de necesitate a folosirii codului SQL dinamic. Spre deosebire de tehnica folosirii statice a codului SQL, planurile de acces pentru interogrile SQL dinamice pot fi generate numai n momentul execuiei. 7.3.2.1 Structura aplicaiei SQL ncorporate Lista 7.3 prezint codul corespunztor Formularului de cutare aunui anagajat din Figura 7.3. Acesta arat o demonstraie a felului n care se execut o comand SQL n mod dinamic din cadrul unei aplicaii ncorporate.

Baze de date - Fundamente

int findEmployee(char * field, char * value, char * emp_name, char * emp_id, char * emp_desig) { int ret_code = 1; char sqlstmt[250] = {0}; EXEC SQL INCLUDE SQLCA;

174

EXEC SQL BEGIN DECLARE SECTION; char name_hv[129] = {0}; // Nume angajat char desig_hv[129] = {0}; // Rolul angajatului char id_hv[10] = {0}; // Identificator angajat char value_hv[250] = {0}; // valoare camp EXEC SQL END DECLARE SECTION; // Copiaza valoarea din campul de cautare obtinuta cu aceasta functie in // sirul de caractere sqlstmt sprintf(sqlstmt,SELECT emp_name, emp_id, emp_desig FROM employee.details WHERE %s = ?,field); // Copiaza valoarea obtinuta cu aceasta functie in // variabila gazda strcpy(value_hv,value) ; // Pregateste mai intai comanada SQL dianmica // Comanda va crea planul de acces la executie EXEC SQL PREPARE dynsqlstmt FROM :sqlstmt; if (SQLCODE <0) { printf(\n Error during Prepare statement:%ld,SQLCODE); ret_code = 0; //error } else { EXEC SQL DECLARE cur1 CURSOR FOR :dynsqlstmt; if (SQLCODE <0) { printf(\n Error during Declare Cursor:%ld,SQLCODE); ret_code = 0; //error } else { EXEC SQL OPEN cur1 USING :value_hv; if (SQLCODE <0) { printf(\n Error during Open Cursor:%ld,SQLCODE); ret_code = 0; //error

Capitolul 7 Folosirea SQL n aplicaii 175

} else { EXEC SQL FETCH cur1 INTO :name_hv, :id_hv, :design_hv; if (SQLCODE <0) { printf(\n Error during Fetch cursor:%ld,SQLCODE); ret_code = 0; //eroare } else { EXEC SQL CLOSE cur1; if (SQLCODE <0) { printf(\n Error during Close cursor:%ld,SQLCODE); Ret_code = 0; //eroare } else { // Copiaza rezultatele obtinute in variabilele // corespunzatoare strcpy(emp_name,:name_hv); strcpy(emp_id,:id_hv); strcpy(emp_desig,:desig_hv); } } } } } return ret_code; }

Lista 7.3 Cod SQL ncorporat n C cu elemente statice i dinamice n lista de mai sus, informaiile referitoare la cmpul de cutare al formularului angajailor (pe care utilizatorul l completeaz la execuie) este mai nti reinut n varaibila numit field. Aceast informaie este copiat n comanda SQL fiind pstrat apoi ntr-o variabil de tip ir de caractere (vezi sqlstmt de mai sus). S spunem c utilizatorul alege s caute angajatul dup cmpul Identificator angajat. n acest caz, comanda SQL (fr valorile predicatului) va arta astfel:
SELECT emp_name, emp_id, emp_desig from employee.details WHERE emp_id =?

Semnul ntrebrii folosit n cadrul comenzii se numete marcator de parametru. Aceti marcatori se folosesc n locul valorilor predicatelor i arat faptul c valorile curente se vor introduce mai trziu, la execuie. Deoarece valorile exacte ale predicatelor nu sunt necesare la generarea planului de acces, informaia SQL existent este suficient n acest

Baze de date - Fundamente

176

moment pentru a crea acest plan. Planul de acces este elaborat folosind comanda SQL dinamic de pregtire (vezi EXEC SQL PREPARE din lista de mai sus). Dac utilizatorul introduce date n cmpul Nume angajat codul SQL devine:
SELECT emp_name, emp_id, emp_desig from employee.details WHERE emp_name =?

n acest fel comanda SQL complet este generat doar la execuie, iar pregtirea acestei comenzi va conduce la un plan de acces diferit de cel anterior. Odat ce comanda a fost pregtit cu succes, este posibil s se execute folosind valorile predicatelor introduse de ctre utilizator. n cazul unei comenzi SELECT acest lucru se realizeaz prin declararea mai nti a unui cursor pe comanda SQL, dup care acesta se deschide i se introduc valorile predicatelor, iar la final se folosesc rezultatele obinute n urma interogrii n cadrul variabilelor gazd. La terminarea operaiei cursorul trebuie nchis. 1. Codul de mai sus conine unele comenzi SQL statice necesare pregtirii comenzii, declarrii cursorului .a.m.d. Aceasta nseamn c astfel de aplicaii au nevoie de pre-compilare sau traducere a codului SQL (pentru aplicaiile SQLJ), deoarece mai sunt nc dependente de comenzile SQL statice. 2. Dac exist o modalitate de nlocuire a tuturor comenzilor SQL statice cu echivalentele API, pre-compilarea/ traducerea codului SQL al aplicaiei nu ar mai fi necesare deloc. ntrebarea care apare ntr-o astfel de situaie este cum ar putea fi scrise astfel de aplicaii SQL dinamice care s nu necesite deloc comenzi SQL statice (nici pentru comenzile PREPARE, EXECUTE, CURSOR .a.m.d.). rspunsul la aceast ntrebare este dat n seciunile urmtoare.

7.3.3 Comenzi SQL statice sau dinamice?

n ceea ce urmeaz se vor prezenta cteva dintre diferenele existente ntre modurile de execuie static i dinamic ale aplicaiilor ce au cod SQL ncorporat: 1. Spre deosebire de comenzile SQL statice, planurile de acces ale comenzilor dinamice sunt generate la execuie, motiv pentru care comenzile dinamice trebuie s fie pregtite n cadrul aplicaiei. 2. Timpul necesar pentru generarea planului de acces la execuie face ca aplicaiile ce conin cod SQL dinamic s fie un pic mai lentre dect cele care coninj cod SQL static. Totui, aplicaiile ce conin cod SQL dinamic sunt mult mai flexibile dect cele ce conin cod SQL static, ceea ce face ca primele s fie mult mai robuste. 3. Uneori, o comand SQL dinamic poate s aib performane mai bune dect una static echivalent deoarece poate folosi ultimele statistici disponibile n baza de date n momentul execuiei. Planul de acces generat n cazul unei comenzi SQL statice este memorat dinainte i poate deveni depit de noile statistici din baza de date, ceea ce nu este cazul pentru comenzile dinamice. 4. Unul dintre avantajele comenzilor SQL dinamice asupra comenzilor statice se poate vedea chiar dac aplicaia nu este modificat sau actualizat. Dac se modific.partea static a comenzii SQL este necesar refacerea planului de

Capitolul 7 Folosirea SQL n aplicaii 177 acces. Aceasta presupune pre-compilarea aplicaiei i refacerea asocierilor cu pachetele. n cazul comenzilor SQL dinamice, deoarece planurile de acces sunt generate la execuie, nu sunt necesare pre-compilarea sau reasocierea.

7.4 Interfeele de programare a aplicaiilor pentru bazele de date

Aa cum am vzut anterior, dei codul SQL ncorporat are posibilitatea de executare dinamic a comenzilor SQL, acesta tot mai conine comenzi SQL statice care necesit precompilare sau traducere. Mai mult dect att, pentru a elabora planurile de acces, este necesar o conexiune la baza de date deoarece pre-compilarea aplicaiilor cu cod SQL ncorporat necesit informaii statistice preluate din catalogul bazei de date. Aceasta ne aduce ntr-o alt zon a elaborrii de aplicaii SQL care utilizeaz interfeele de programare a aplicaiilor pentru bazele de date (APIs). Aceste interfee de programare a aplicaiilor sunt, n totalitate, dinamice prin natur i pot fi elaborate n mod independent de produsul de baze de date utilizat, fr a fi necesar pre-compilarea. Interfeele de programare a aplicaiilor pentru bazele de date, aa cum le sugereaz i numele, reprezint un grup de interfee de programare a aplicaiilor puse la dispoziie de ctre productorii de baze de date pentru comunicarea cu diverse limbaje de programare cum ar fi C, C++, Java .a.m.d. Prin intermediul acestora se ofer programatorilor un mecanism de interaciune cu bazele de date din cadrul unei aplicaii doar prin simpla apelare a acestor interfee de apelare a codului SQL. Stratul intermediar dintre aplicaie i serverul bazei de date, care face posibil interaciunea, este driver-ul de conectare la baza de date. Productorii de baze de date ofer ei nii astfel de drivere i, oadat ce bibliotecile driverelor sunt asociate cu bibliotecile codului surs, codul surs al aplicaiei poate fi compilat i executat cu uurin. Aplicaiile pot fi elaborate actualmente, n mod independent de bazele de date cu care lucreaz, fr a fi nevoie s existe conexiune cu baza de date n momentul compilrii. Aceasta permite programatorilor s elaboreze aplicaii fr a fi nevoie s cunoasc sintaxa codului SQL ncorporat. Seciunile urmtoare prezint n detaliu aceste drivere necesare pentru realizarea conectivitii.

7.4.1 ODBC i driverul IBM Data Server CLI

Pentru a se pstra o anumit standardizare la nivelul bazelor de date ntre toi productorii care ofer drivere de conectivitate, X/Open Company i SQL Access Group au elaborat mrpreun o specificaie de apelare a interfeei SQL numit X/Open Call Level Interface. Scopul acestei interfee este acela de a crete portabilitatea aplicaiilor prin oferirea independenei de productor. Cele mai multe dintre specificaiile X/Open Call Level Interface au fost acceptate ca parte a standardului ISO Call Level Interface International Standard (ISO/IEC 9075-3:1995 SQL/CLI). Microsoft a elaborat o interfa de apelare a codului SQL numit Open Database Connectivity (ODBC) care se folosete pe sistemele de operare Microsoft i care se

Baze de date - Fundamente

178

bazeaz pe un draft preliminar al X/Open CLI. Totui, ODBC nu se mai limiteaz la sistemele de operare Microsoft, iar actualmente, exist multe implementri i pe alte platforme. Driverul IBM Data Server CLI este o interfa de apelare creat pentru DB2 care se bazeaz pe specificaiile ODBC de la Microsoft i pe specificaiile International Standard for SQL/CLI. Aceste specificaii au fost alese ca baz pentru DB2 Call Level Interface pentru a rspunde standardelor din domeniu i pentru a oferi o soluie mai simpl programatorilor obinuii cu alte asemenea tipuri de interfee. Pe lng acestea au fost adugate anumite extensii specifice DB2 pentru ca programatorii s se poat folosi de caracteristicile specifice acestui produs. DB2 este o interfa de programare a aplicaiilor destinat limbajelor de programare C i C++ pentru lucrul cu baze de date relaionale care folosesc apeluri de funcii pentru a executa comenzi SQL dinamice introduse sub form de argumente ale acestor funcii. Chiar i pentru comenzile PREPARE i EXECUTE exist comenzi corespunztoare cum ar fi SQLPrepare() i, respectiv, SQLExecute(), care accept comenzi SQL ca argument. Aceasta nseamn c nu mai este nevoie de comenzi statice n aplicaii care s se introduc cu comanda EXEC. De exemplu, s lum o comand SQL dinamic care trebuie pregtit cu ajuorul API-ului SQLPrepare(). Trebuie s ne amintim c, prin folosirea codului SQL ncorporat, obinem acelai lucru ca atunci cnd folosim comanda EXEC SQL PREPARE.
SQLCHAR *stmt = (SQLCHAR *)"UPDATE employee.details SET emp_id = ? WHERE emp_name = ? "; /* pregatirea comenzii */ int rc = SQLPrepare(hstmt, stmt, SQL_NTS);

IBM CLI mai ofer i alte interfee, cum ar fi SQLConnect(), SQLFetch(), SQLExecute .a.m.d. Specificaiile ODBC mai presupun i existena unui mediu de operare, n care driverele ODBC sunt ncrcate n mod dinamic la execuie de ctre un manager de drivere n funcie de sursa de date (numele bazei de date) introdus n cererea de conectare. Driverul IBM DB2 Call Level Interface corespunde standardelor ODBC 3.51, ceea ce nseamn faptul c acioneaz ca un diver ODBC atunci cnd este ncrcat de un manager de drivere. Figura 7.4 prezint locul n care este nevoie de folosirea driverului IBM DB2 CLI n cadrul mediului de dezvoltare a aplicaiilor ce ncorporeaz cod SQL dinamic. De asemenea se observ faptul c driverul IBM DB2 CLI se poate comporta la fel ca orice alt driver ODBC atunci cnd este ncrcat prin intermediul managerului de drivere ODBC.

Capitolul 7 Folosirea SQL n aplicaii 179

Figura 7.4 - IBM DB2 CLI i ODBC

7.4.2 JDBC
JDBC nseamn Java Database Connectivity. Aa cum i arat i numele, este o interfa de programare a aplicaiilor SQL similar cu ODBC i CLI, dar folosit pentru aplicaiile Java. La eleborarea unei aplicaii CLI, bibliotecile dependente CLI trebuie asociate aplicaiei. n mod asemntor, n JDBC, pachetele relevante Java care conin suportul pentru API-urile Java trebuie importate. Un exemplu de comand SQL ce poate fi apelat din cadrul unei aplicaii JDBC este prezentat n Lista 7.4.

Baze de date - Fundamente

180

// SQL pentru SELECT. Informatiile despre nume, tara, strada si provincie // ce sunt oferite de utilizator sunt pstrate in variabilele // corespunzatoare. String sqlSel = "select +name+, +country+, +street+, +province+, +zip+ from CUSTOMER where Customer = ?"; //pregatirea comenzii SELECT PreparedStatement pstmt=con.prepareStatement(sqlSel); pstmt.setString (1, "custCountry"); //alege parametrul the Input pstmt.execute(); //executa comanda SELECT ResultSet result = pstmt.getResultSet (); //obtine rezultatul si seteaza //valorile List<Customer> custList = new ArrayList<Customer>(); while (result.next ()) { Customer cust = new Customer(); cust.name = result.getString (1); cust.country = result.getString (2); cust.street = result.getString (3); cust.province = result.getString (4); cust.zip = result.getString (5); custList.add (cust); } }catch (SQLException e) {e.pringStackTrace ();}

Lista 7.4 Fragment de cod cu folosirea JDBC n fragmentul de cod de mai sus: Comanda complet SQL, odat alctuit, este mai nti introdus n cadrul unei variabile de tip ir de caractere (sqlSel de mai sus). Comanda dinamic SQL este apoi pregtit folosind marcatori pentru parametru n locul valorilor predicatului. nainte de execuie, valorile curente sunt asociate marcatorilor corespunztori parametrilor. Comanda JDBC pstmt.setString (1, "custCountry") va nlocui primul marcator de parametru n comanda SQL dinamic cu valoarea custCountry. Dup execuie, programatorii trebuie s mapeze rezultatele returnate de JDBC pe obiectele Java corespunztoare.

7.5 pureQuery
Comenzile SQL dinamice ofer flexibilitate programatorilor, dar au nevoie de activiti suplimentare. Pentru fiecare comand SQL care se execut, comanda trebuie mai nti pregtit n cadrul aplicaiei, dup care valorile curente ale predicatelor trebuie asociate

Capitolul 7 Folosirea SQL n aplicaii 181 marcatorilor de parametri asociai, iar rezultatele primite de la driverul JDBC se mapeaz cu obiectele Java corespunztoare. pureQuery este o platform oferit programatorilor Java pentru a exploata avantajele comenzilor SQL dinamice fr a fi preocupai de activitile suplimentare de pregtire i mapare. S lum fragmentul de aplicaie JDBC prezentat n Lista 7.4. Aceeai comand SQL SELECT, atunci cnd este scrisp folosind pureQuery, are mai puine linii de cod, aa cum se vede din Lista 7.5.
//Numele, tara, strada i provincia sunt variabile ce se vor //popula la executie folosind datele introduse de utilizator. String sqlSel = "select +name+, +country+, +street+, +province+, +zip+ from CUSTOMER where Customer = ?"; Data data = DataFactory.getData (con); //se executa comanda Select si se obtine lista clientilor List<Customer> customerList = data.queryList (sqlSel, Customer. class, "custCountry");

Lista 7.5 Fragment de cod cu folosirea pureQuery API-ul pureQuery queryList va executa comanda sqlSel ce are valoarea predicatului custCountry returnnd rezultatul interogrii n cutomerList. La fel ca i n JDBC, comanda SQL se genereaz tot la execuie, dei codul scris are mai puine linii de cod n comparaie cu aplicaia JDBC. n acest fel, nu doar se maximizeaz viteza de elaborare a aplicaiei, dar se obine i o reducere a complexitii. Metoda de mai sus cu folosirea pureQuery se numete metoda inline, care suport executarea dinamic a codului SQL. pureQuery suport i execuia static a aplicaiilor SQL folosind metoda adnotrii. Folosind metoda inline, comenzile SQL sunt elaborate sub forma unor obiecte Java de tip ir de caractere i transmise API-ului pureQuery API. Pe de alt parte, folosind metoda adnotrii, irul SQL se definete ca fiind o adnotare pureQuery. Metoda adnotrilor folosit de pureQuery este urmtoarea: @Select (care marcheaz interogrile SQL) @Update (care marcheaz comenzile DML SQL) @Call (care marcheaz comenzile CALL SQL). S lum urmtoarea comand SELECT: SELECT Name, Country, Street, Province, Zip FROM customer where Customer =? n cazul pureQuery, tot ceea ce trebuie fcit este s: Se introduc codul SQL SELECT n marcajul corespunztor.

Baze de date - Fundamente

182

Se declare o funcie definit de ctre utilizator care este folosit pentru a executa acelai cod SQL. De exemplu, n Lista 7.6, comanda SQL SELECT este plasat n marcajul @Select.
public interface CustomerData { //Selecteaza PDQ_SC.CUSTOMER pe baza parametrilor i populeaz componenta //Customer cu rezultatele @Select(sql="select Name, Country, Street, Province,Zip from CUSTOMER where Customer =?") Customer getCustomer(int cid); }

Lista 7.6 Comentariul @Select Pentru a executa acum comanda SQL, aplicaia nu mai are nevoie s implementeze interfaa de mai sus CustomerData. pureQuery implementeaz aceste interfee definite de ctre utilizator prin utilizarea unui utilitar intern numit generator pureQuery, care creeaz stratul de acces la date necesar aplicaiei. Aplicaia poate creea n mod direct o varaibil pentru CustomerData folosind API-ul pureQuery API apelnd n mod direct metoda getCustomer()pentru a executa comanda SQL de mai sus, aa cum se vede n Lista 7.7.
// se foloseste DataFactory pentru a instatia interfata definita de // utilizator CustomerData cd = DataFactory.getData(CustomerData.class, con); // se executa codul SQL pentru getCustomer() si se obtin rezultatele // pentru componentele Customer Iterator<Customer> cust = cd.getCustomer();

Lista 7.7 Execuia comenzii SQL folosind pureQuery i metoda adnotrii Rezultatul obinut cu ajutorul utilitarului de generare este un fiier de implementare Java (CustomerDataImpl.java n exemplul de mai sus) al interfeei definite de ctre utilizator (CustomerData). Acest fiier de implementare Java conine codul SQL curent precum i definiia metodelor declarate (getCustomer). Folosind un astfel de stil de programare, programatorul aplicaiei introduce toate comenzile SQL mpreun cu metodele corespunztoare n cadrul interfeelor. Aceste metode sunt apoi folosite pentru a executa comenzile SQL n cadrul aplicaiilor. n acest fel, comenzile SQL sunt separate de logica aplicaiei n codul aplicaiei. Stilul de programare ce folosete metoda adnotrii pureQuery permite modul de execuie static al aplicaiilor, n timp ce metoda inline folosete execuia dinamic. n funcie de cerinele utilizatorului se poate folosi oricare dintre aceste stiluri de programare pureQuery pentru a elabora o aplicaie Java cu baze de date. Mai multe detalii referitoare la tehnicile de lucru folosind pureQuery gsii la adresele: http://publib.boulder.ibm.com/infocenter/idm/v2r2/index.jsp?topic=/com.ibm.datatools.javat

Capitolul 7 Folosirea SQL n aplicaii 183 ool.runtime.overview.doc/topics/helpindex_pq_sdf.html http://publib.boulder.ibm.com/infocenter/idm/v2r2/index.jsp?topic=/com.ibm.datatools.javat ool.runtime.overview.doc/topics/helpindex_pq_sdf.html

7.5.1 IBM pureQuery Client Optimizer

O foarte interesant caracteristic suportat de ctre pureQuery, este pureQuery Client Optimizer. n seciunile anterioare am discutat despre reducerea de performan evideniat n aplicaiile SQL dinamice. pureQuery Client Optimizer ofer o tehnic de reducere a pierderilor de performan. Aplicaia JDBC dinamic existent poate fi optimizat pentru a rula anumite comenzi SQL static, fr a face nici o modificare codului aplicaiei. Pentru folosirea pureQuery Client Optimizer, tebuie efectuai urmtorii pai: Atunci cnd se execut mai nti aplicaia dinamic, pureQuery Client Optimizer preia comenzile SQL din aplicaie ntr-un fiier pureQueryXml. Comenzile SQL din fiierul XML sunt apoi separate n pachete, cu ajutorul instrumentului n linie de comand Configure. Folosind staticBinder, aceste pachete sunt apoi create n cadrul serverului bazei de date, fcndu-se o asociere ntre acestea i aplicaie. n sfrit, la executarea aplicaiei, trebuie setat modul static, care permite ca anumite comenzi din SQL s se execute n mod static. n principiu, fiecare comand SQL preluat din aplicaie corespunde unei comenzi SQL din fiierul XML. n momentul n care se gsete o astfel de coresponden, se parcurg liniile pachetului respectiv cu ajutorul fiierului XML i, deoarece SQL este deja asociat unui anumit pachet existent n serverul bazei de date, comanda poate fi executat static. Fiecare comand SQL care nu are o coresponden este executat n modul dinamic.

7.6 Rezumat
n acest capitol am discutat despre diverse tehnici de utilizare a limbajului SQL n cadrul aplicaiilor. S-a nceput prin descrierea conceptului de "tranzacie" dup care a urmat descrierea modului n care comenzile SQL pot fi ncorporate n cadrul aplicaiilor. Capitolul explic diferenele dintre modurile static i dinamic de execuie, artndu-se faptul c modul static ofer o perfoman superioar fa de modul dinamic de execuie, n timp ce modul dinamic ofer o flexibilitate mult mai bun la programare precum i abilitatea de a elabora i executa aplicaii fr a fi nevoie de pre-compilare i conectare la baza de date. Alegerea ntre modul de lucru static i cel dinamic se face n funcie de cerinele aplicaiei i de proiectarea acesteia, neexeistnd reguli prin care unul s-I fie preferat celuilalt. Aplicaiile ncorporate SQL i SQLJ pot suporta ambele, att cod SQL static ct i dinamic. Totui, chiar dac aplicaiile SQL ncorporate folosesc preponderent comenzi SQL dinamice, tot mai este nevoie de unele comenzi SQL statice, ceea ce nseamn faptul c

Baze de date - Fundamente aplicaiile tot mai trebuie pre-compilate i conectate la baza de date.

184

Un concept diferit de utilizare a API-ului bazei de date, cum ar fi ODBC, CLI i JDBC introduce modul dinamic complet de elaborare a aplicaiilor. Acest concept surmonteaz multe dintre problemele datorate ncorporrii codului SQL. Principalul avantaj este acela c programatorii pot scrie cod standard ce poate fi folosit cu orice sistem de gestiune al bazelor de date fcnd foarte mici modificri. La final, n capitol se discut despre folosirea tehnicii pureQuery, o tehnologie IBM ce permite fructificarea avantajelor oferite de ctre codul SQL dinamic fr a fi preocupai de activitile suplimentare de pregtire sau de mapare a obiectelor.

7.7 Exerciii
Proiectai n ntregime o aplicaie pentru sistemul de management al unei biblioteci care trebuie s efectueze urmtoarele activiti: A. ntroducerea crilor noi n baza de date. B. Regsirea crilor dup numele autorului sau dup titlu. C. Rezervai n baza de date un spaiu de pstrare a datei de retur a crilor mprumutate. D. La o anumit dat se va afia lista crilor mprumutate cu data la care trebuie returnate. ncercai s stabilii care dintre interogri sunt mai potrivite pentru executarea dinamic i care sunt mai potrivite pentru executarea static.

7.8 ntrebri recapitulative

1. Execuia static a unei comenzi SQL presupune c planul de acces: A. Se va genera doar la momentul execuiei aplicaiei. B. Este generat la momentul pre-compilrii sale. C. Ambele D. Nici una 2. Executarea dinamic a comenzii SQL: A. Nu necesit existena informaiei complete despre sintaxa SQL de dinainte. B. Necesit informaia complet despre sintaxa SQL n faza de pre-compilare. C. Ambele D. Nici una 3. Codul SQL ncorporat n aplicaiile C/C++: A. Nu necesit pre-compilarea DB2.

Capitolul 7 Folosirea SQL n aplicaii 185 B. Necesit pre-compilarea DB2. 4. SQLJ este: A. O tehnic de ncorporare a codului SQL n aplicaiile Java. B. Un apel programabil SQL la nivel de interfa. 5. ODBC vine de la: A. Open Database Community B. Open Database Connectivity C. Open Source Database Community D. Open Database Connection. E. Nici una dintre cele enumerate 6. Care dintre urmtoarele suport rularea att n mod static ct i dinamic? A. JDBC B. SQLJ C. DB2 CLI D. Toate cele enumerate E. Nici una dintre cele enumerate 7. Care dintre urmtoarele aplicaii necesit la pre-compilare/compilare o conexiune la baza de date? A. JDBC B. SQLJ C. DB2 CLI D. Toate cele enumerate E. Nici una dintre cele enumerate 8. Marcatorii de parametri (?) se folosesc ca nlocuitori pentru: A. Valorile predicatelor introduse la momentul execuiei B. Nume de coloane, nume de tabele etc. C. Comanda SQL nsi. D. Toate cele enumerate E. Nici una dintre cele enumerate 9. Tehnica pureQuery numit annotated style suport: A. Comenzi SQL dinamice

Baze de date - Fundamente B. Comenzi SQL statice C. Toate cele enumerate D. Nici una dintre cele enumerate 10. pureQuery Client Optimizer:

186

A. Necesit modificarea codului aplicaiilor JDBC existente astfel nct acestea s poat fi executate n modul static. B. Nu necesit modificarea codului aplicaiilor JDBC existente astfel nct acestea s poat fi executate n modul static.

8
Capitolul 8 Limbaje de interogare pentru XML
n ziua de astzi datele din lumea real pot fi reprezentate cu ajutorul mai multor modele de date. Modelul tradiional relaional de reprezentare a datelor folosit pe scar larg de peste zece ani are nevoie de modificri pentru a putea lucra cu date obinute din surse diverse. Uneori, datele nu pot fi reprezentate n mod structurat, aa cum impune modelul relaional. De fapt, majoritatea datelor cu care se lucreaz astzi se afl fie n format semistructurat fie n format nestructurat. Datele nestructurate pot fi poze sau imagini, motiv pentru care datele structurate au nevoie de metadate asociate acetora. Datele semistructurate nu impun un format rigid, aa cum sunt nregistrrile din cadrul unui tabel, motiv pentru care sunt mult mai flexibile putnd reprezenta diverse tipuri de obiecte din cadrul unui domeniu. XML este o metod foarte bun de reprezentare a datelor semi-structurate fiind folosit cu succes de ceva timp. XML a devenit de facto standardul folosit la schimbul de informaii pe Internet. Datorit faptului c n ultimul timp din ce n ce mai multe tranzacii se produc online pe Internet, a aprut necesitatea urmririi tuturor acestor tranzacii, dar i a pstrrii acestora pentru o utilizare ulterioar. Unele organizaii pstreaz aceste informaii pentru audit i cerine de compatibilitate, iar altele pe motive de cretere a performanelor prin efectuarea de analize a datelor ce se pstreaz. Acest lucru necesit o baz de date foarte puternic care ofer suport real pentru pstrarea eficient i interogarea unui volum mare de date n format XML. DB2 este un astfel de server de date care ofer suport nativ att pentru datele relaionale ct i pentru cele n format XML, motiv pentru care este cunoscut sub denumrea de server hibrid de date.

8.1 Vedere de ansamblu asupra tehnologiei XML

Denumirea XML vine de la eXtensible Markup Language (limbaj extensibil de marcare). XML este un model de date ierarhic alctuit din noduri de tipuri diferite legate ntre ele printr-o relaie de tip printe/copil. Un model de date XML poate fi reprezentat n format de tip text sau binar.

8.1.1 Elementele XML i obiectele bazei de date

Un element XML este conceptul de baz al unui document XML. Fiecare document XML trebuie s aib cel puin un element XML, cunoscut i sub numele de rdcin sau elementul documentului. Acest element poate avea n continuare, oricte atribute i

Baze de date - Fundamente elemente copil. Avei mai jos un exemplu de element XML simplu
<name>I am an XML element</name>

188

Fiecare element XML are cte o etichet de nceput i una de sfrit. n exemplul de mai sus <name> reprezint eticheta de nceput, iar </name> reprezint eticheta de sfrit. Elementul mai are i o valoare de tip text: I am an XML element. Mai jos se prezint un document XML care are mai multe elemente XML i un atribut.
<employees> <employee id=121> <firstname>Jay</firstname> <lastname>Kumar</lastname> <job>Asst. manager</job> <doj>2002-12-12</doj> </employee> </employees>

n exemplul de mai sus, <employees> reprezint rdcina documentului XML care are un element subordonat numit <employee>. Elementul <employee> are, la rndul su, elemente subordonate i un atribut numit id cu valoarea 121. n DB2, ntregul document XML poate fi pstrat sub forma unei singure valori ntr-o coloan a unui tabel. De exemplu, structura tabelului de mai jos:
department(id integer, deptdoc xml)

Coloana id pstreaz valoarea de tip ntreg id a fiecrui departament, n timp ce coloana deptdoc care este de tip XML, va pstra cte un document XML pe departament. Din acest motiv, ntregul document XML este tratat ca i cum ar fi o singur valoare/obiect n cadrul tabelului. n Figura 8.1 putei urmri o reprezentare grafic a felului n care sunt pstrate datele XML n sistemele DB2.

Capitolul 8 Limbaje de interogare pentru XML 189

Figura 8.1 Stocarea nativ n format XML n DB2 documentul XML este analizat n momentul inserrii, iar formatul ierarhic analizat este pstrat n cadrul bazei de date. Datorit acestui fapt nu este necesar analizarea documentului la momentul interogrii, ceea ce conduce la o cretere a performanelor de interogare.

8.1.2 Atributele XML

Atributele sunt ntotdeauna pri constitutive ale elementelor care ofer informaii suplimentare despre acestea. Mai jos avei un exemplu de elemennt cu dou atribute, id i uid ce au valorile 100-233-03 i respectiv 45:
<product id=100-233-03 uid=45/>

De remarcat faptul c n cadrul unui element numele atributelor trebuie s fie unice, ceea ce nseamn c acelai element nu poate avea dou atribute cu acelai nume. De exemplu, urmtoarea definiie de element va genera o eroare n momentul analizei.
<product id=100-233-03 id=10023303/>

De remarcat este i faptul c valorile atributelor se afl ntotdeauna ntre ghilimele. n schema unui document XML, atributele sunt definite dup ce au fost definite toate celelalte elemente din cadrul unui element complex. Mai jos avei un exemplu de element

Baze de date - Fundamente complex care are un singur atribut i dou elemente subordonate.
<xs:element name="employee"> <xs:complexType> <xs:sequence> <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> </xs:sequence> <xs:attribute name=empid type=xs:integer/> </xs:complexType> </xs:element>

190

8.1.3 Nume de domeniu

Numele de domeniu XML ofer un mecanism de marcare a unui atribut i a unui nume de element pentru a evita conflictul de nume n cadrul unui document XML. De exemplu, dac o companie de asigurri de sntate primete informaii despre asigurat de la o alt companie sub forma unui document XML, este foarte probabil ca dou sau mai multe companii s aib acelai nume de element, dar care s reprezinte lucruri diferite n formate diferite. Prin marcarea acestor elemente cu ajutorul unui nume de domeniu se rezolv conflictul de nume. n XML, un nume poate fi marcat cu ajutorul unui nume de domeniu. Un nume marcat are dou pri: Un nume de domeniu de tip Uniform Resource Identifier (URI) Un nume local De exemplu, http://www.acme.com/names este un nume de domeniu de tip URI, iar customer este numele local. De multe ori, numele marcate folosesc un prefix pentru numele de domeniu n locul unui nume de tip URI. De exemplu, elementul customer care aparine domeniului URI http://www.acme.com/names mai poate fi scris i sub forma acme:customer, n care acme este prefixul numelui de domeniu corespunztor http://www.acme.com/names. Prefixele numelor de domeniu pot fi declarate n antetul XQuery, aa cum se vede mai jos. Declare namespace acme "http://www.acme.com/names" De asemenea, prefixul numelui de domeniu poate fi declarat n cadrul constructorului elementului, aa cum se vede mai jos.
<book xmlns:acme="http://www.acme.com/names">

De remarcat este faptul c numele de domeniu aparine aceluiai domeniu cu cel al elementului declarat, ceea ce nseamn c toate elementele subordonate pot face referire la acest nume de domeniu. Urmtoarele prefixe de nume de domeniu sunt predefinite i nu trebuie folosite ca prefixe de domeniu definite de utilizator:
Xml, xs, xsi, fn, xdt.

Capitolul 8 Limbaje de interogare pentru XML 191 Se mai pot declara, de asemenea, nume de domeniu implicite, adic un nume de domeniu fr prefix astfel:
declare default element namespace http://www.acme.org/names (n antetul XQuery) <book xmlns="http://www.acme.com/names"> (n elementul constructor)

8.1.4 Document Type Definition

Document Type Definition (DTD) este o schem de document XML cu ajutorul creia se pot stabili structurile ce sunt permise a fi create n cadrul unui document XML. Cu ajutorul acestor scheme se stabilete lista elementelor i a atributelor ce pot apare n cadrul documentului pe care l valideaz. Schema DTD poate fi declarat n interiorul unui document XML sau n exteriorul acestuia fcndu-se o referire pentru verificare. Mai jos putei vedea un exemplu de schem DTD.
<!DOCTYPE TVSCHEDULE [ <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT PRODUCTS (PRODUCT+)> PRODUCT (NAME,PRICE,DESCRIPTION)> NAME (#PCDATA)> PRICE (#PCDATA)> DESCRIPTION (#PCDATA)>

<!ATTLIST PRODUCTS ID CDATA #REQUIRED> ]>

Ambele documente de mai jos sunt validate cu schema DTD de mai sus:
<PRODUCTS> <PRODUCT ID=100-200-43> <NAME>Laptop</NAME> <PRICE>699.99</PRICE> <DESCRIPTION>This is a Laptop with 15 inch wide screen, 4 GB RAM, 120 GB HDD </DESCRIPTION> </PRODUCT> </PRODUCTS>

Baze de date - Fundamente

192

<PRODUCTS> <PRODUCT ID=100-200-56> <NAME>Printer</NAME> <PRICE>69.99</PRICE> <DESCRIPTION>This is a line printer </DESCRIPTION> </PRODUCT> <PRODUCT ID=100-200-89> <NAME>Laptop</NAME> <PRICE>699.99</PRICE> <DESCRIPTION>This is a Laptop with 13 inch wide screen, 4 GB RAM, 360 GB HDD </DESCRIPTION> </PRODUCT> </PRODUCTS>

8.1.5 Schema XML

O schem XML stabilete structura, coninutul i tipurile de date acceptate n cadrul unui document XML. Aceasta poate fi alctuit din unul sau mai multe documente de tip schem. Un document de tip schem poate avea un nume de domeniu.

Figura 8.2 - Schema XML: exemplu O schem XML este o variant de schem DTD. Schema XML descrie structura unui document XML. Limbajul folosit mai este denumit i XML Schema Definition (XSD). Schemele XML sunt mult mai puternice dect cele DTD, deoarece acestea ofer un control mai bun asupra documentelor XML. Prin folosirea schemelor XML, n afara tipurilor de date obinuite, cum ar fi integer, date, decimal i datetime, se pot crea i tipuri de date definite de utilizator, tipuri de elemente complexe etc. Se pot specifica lungimea, valorile minime sau maxime, tipurile de valori de iruri de caractere permise sau enumerrile. De asemenea, se mai pot specifica modurile de apariie a elementelor n cadrul unui document

Capitolul 8 Limbaje de interogare pentru XML 193 XML. Un alt avantaj al folosirii schemei XML fa de utilizarea schemei de tip DTD este i acela al posibilitii acordrii de nume de domeniu. Suplimentar, schema XML ofer suport pentru motenirea tipului. Schema XML devine o recomandare a organizaiei W3C ncepnd cu luna mai a anului 2001. n continuare se prezint un exemplu de schem XML alctuit din trei documente de tip schem i dou nume de domeniu.

Figura 8.3 Mai multe nume de domeniu n cadrul unei scheme XML n DB2, utilizarea schemelor XML este opional i se aplic pe fiecare document XML. Aceasta nseamn c se pot folosi acelai coloane pentru pstrarea ambelor tipuri de documente XML, att pentru documente ce au scheme asociate, ct co pentru documente fr scheme asociate. Din acest motiv, nu este nevoie de o anumit schem pe o coloan ce conine documente XML. Validarea documentelor XML se face pe document (adic pe fiecare rnd). Se pot folosi zero sau mai multe scheme pe fiecare coloan XML. De asemenea, se poate ca o singur coloan a unui tabel s conin att documente XML validate ct i nevalidate. DB2 mai permite utilizatorilor s interzic inserarea de documente care nu sunt validate n cadrul coloanelor XML cu ajutorul clauzei IS VALIDATED n cadrul unei comenzi SELECT.

8.2 XML Schema

XML reprezint o aplicaie a limbajului standard generalizat de marcare Standard Generalized Markup Language (SGML), fiind foarte puternic i uor de folosit. XML nu are limitri n ceea ce privete complexitatea structural sau numele de domeniu. Fiind un metalimbaj, poate fi folosit la crearea altor limbaje specifice pieei sau industriei. XML suport o mare varietate de tipuri de date i constrngeri de integritate, ce vor fi discutate n cele ce urmeaz.

8.2.1 Tipuri simple

Specificaiile W3C XML Schema introduc o serie de tipuri simple de date, aa cum se prezint n Figura 8.4.

Baze de date - Fundamente

194

Figure 8.4 Tipuri de date n XML Schema n Figura 8.4 sunt vizibile o serie de tipuri de date simple, dar exist multe altele ce nu apar n figur i care pot fi folosite pentru a defini elementele existente n documentele XML. n afara tipurilor de date simple se mai pot folosi i tipuri de date definite de utilizator, create pe baza celor simple. De exemplu, mai jos este prezentat un tip de dat definit de utilizator, myInteger, creat pe baza tipului simplu de date xs:integer i care permite folosirea doar a valorilor din intervalul -2 la 5. Obinerea unui tip de date definit de utilizator dintr-un tip de date simplu este numit derivaie.

<xs:simpleType name= "myInteger" > <xs:restriction base= "xs:integer" > <xs:minInclusive value = "-2" /> <xs:maxExclusive value = "5" /> </xs:restriction> </xs:simpleType>

Acest tip de derivaie este denumit derivaie prin restricie. Mai jos este prezentat un alt exemplu de derivaie care este folosit pentru a face o enumeraie:

Capitolul 8 Limbaje de interogare pentru XML 195

<xs:simpleType name= "passGrades" > <xs:restriction base= "xs:string" > <xs:enumeration value = "A" /> <xs:enumeration value = "B" /> <xs:enumeration value = "C" /> </xs:restriction> </xs:simpleType>

Orice element de tip passGrades poate avea doar una dintre cele trei posibile valori (A, B sau C). Orice alt valoare luat de acest element va genera un mesaj de eroare din partea schemei XML. De asemenea, se mai pot introduce abloane de valori ce pot fi pstrate n cadrul unui element, aa cum se prezint n exemplul de mai jos:
<xs:simpleType name= "CapitalNames" > <xs:restriction base= "xs:string" > <xs:pattern value = "([A-Z]( [a-z]*)?)+" /> </xs:restriction> </xs:simpleType>

Alte dou tipuri de derivaie sunt derivaiile de tip list i derivaiile de tip reuniune. Mai jos este prezentat un exemplu de derivaie de tip list:
<xs:simpleType name= "myintegerList" > <xs:list itemType= "xs:integer" /> </xs:simpleType>

Acest tip de dat poate fi folosit pentru a defini atribute sau elemente care accept spaii libere ntre grupurile de numere ntregi, cum ar fi de exemplu: "1 234 333 -32321". n continuare este prezentat un exemplu de derivaie prin reuniune.
<xs:simpleType name= "intordate" > <xs:union memberTypes= "xs:integer xs:date" /> </xs:simpleType>

Acest tip de dat poate fi folosit pentru a defini atribute sau elemente care accept spaiul liber ca marcator de separare ntre liste de numere ntregi, ca n exemplul: 1 223 2001-1026". De remarcat este faptul c n acest caz sunt alturate tipuri de date diferite (tipul de dat ntreg i tipul de dat calendaristic) care alctuiesc membrii listei.

8.2.2 Tipuri complexe

Tipurile complexe reprezint o descriere a structurii de marcare care se bazeaz pe tipurile de date simple pentru elaborarea unei construcii formate din elemente sau atribute individuale care alctuiesc tipul de dat complex. Cu alte cuvinte, elementele unui tip de dat complex conin alte elemente/atribute. Un element complex poat fi gol, sau poate conine alte elemente, text, sau ambele, dar i atribute. n continuare este prezentat un exemplu de tip complex de dat.

Baze de date - Fundamente

<xs:complexType name=employeeType> <xs:sequence> <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> </xs:sequence> </xs:complexType>

196

Pentru a defini un element de tipul complex prezentat anterior, se folosete sintaxa:

<xs:element name="employee" type=employeeType>

O alt modalitate de creare a unui tip complex de dat este prezentat mai jos:
<xs:element name="employee"> <xs:complexType> <xs:sequence> <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element>

Diferena dintre cele dou, const n faptul c definiia primului tip complex de dat este independent de element i poate fi reutilizat la definirea altor elemente.

8.2.3 Constrngeri de integritate

Schemele XML permit diverse modaliti de identificare i asociere a diferitelor pri de informaie. Se pot, de exemplu, emula n mod direct tipurile de atribute ID i IDREF pe baza schemei DTD, folosind tipurile de dat xs:ID sau xs:IDREF din schema XML. n schemele XML aceste dou tipuri de date mai pot fi folosite i pentru elemente, nu doar pentru atribute, aa cum este cazul n schemele DTD. De asemenea se mai poate impune respectarea unicitii elementelor prin folosirea tipului de element xs:unique, aa cum se poate vedea din exemplul urmtor.
<xs:element name =book > <xs:complexType> . </xs:complexType> <xs:unique name=book> <xs:selector xpath=book/> <xs:field xpath=isbn/> </xs:unique> </xs:element>

Acest lucru permite obinerea asigurrii c exist un singur ISBN pentru fiecare carte n cadrul documentului XML respectiv. Se mai pot folosi i tipurile de elemente xs:key i xs:keyref pentru a asigura respectarea

Capitolul 8 Limbaje de interogare pentru XML 197 constrngerilor de integritate. O cheie este o constrngere de unicitate cu restricia suplimentar c toate nodurile corespondente trebuie s existe. Definiia este asemntoare cu definiia unui element de tip unic:
<xs:element name =book > <xs:complexType> . </xs:complexType> <xs:key name=book> <xs:selector xpath=book/> <xs:field xpath=isbn/> </xs:key> </xs:element>

Pentru a face referire la aceast cheie se folosete xs:keyref. De remarcat este faptul c atributul de referin al elementului de tip xs:keyref trebuie s refere un element de tip xs:key sau xs:unique definit n cadrul aceluiai element sau al unuia dintre elementele printe.

8.2.4 Evoluia schemelor XML

Unul dintre motivele folosirii pe scar larg a tehnologiei XML este flexibilitatea acesteia la modelarea datelor, care se caracterizeaz prin efectuarea cu uurin a modificrilor pentru a corespunde schemei. n zilele noastre, fiecare segment al industriei are o specificaie proprie sub forma unui document de tip schem XML. Aceste standarde sunt n permanent modificare, fiind necesar respectarea compatibilitii, motiv pentru care este necesar adaptarea rapid la aceste modificri fr a afecta aplicaiile. DB2 ofer o serie de posibiliti de gestionare a modificrilor aprute n cadrul schemelor. De exemplu, n DB2 se pot pstra documente XML fr a fi nevoie de a pstra i asocierea cu schemele corespunztoare n cadrul aceleiai coloane. O alt situaie poate fi aceea de a pstra documente XML compatibile cu diferite scheme XML n cadrul aceleiai coloane de tip XML. DB2 mai ofer i o funcie de verificare a compatibilitii dintre dou versiuni de scheme XML. Dac le gsete compatibile ofer opiunea de a nlocui versiunea mai veche cu cea curent. Dac documentele existente n baza de date trebuie validate cu ajutorul unei scheme de validare care urmeaz a fi modificat, exist dou modaliti de face acest lucru n DB2 pureXML: Dac cele dou scheme sunt asemntoare (compatibile), se poate nregistra schema nou n cadrul XML Schema Repository (XSR), nlocuind schema veche i continund validarea. Ambele nume de scheme (numele SQL i numele URI) rmn aceleai n cadrul ambelor scheme. n cazul n care cele dou scheme XML nu sunt asemntoare (nu sunt compatibile), noua schem se va nregistra cu un nume SQL nou i un nume nou pentru URI.

Baze de date - Fundamente

198

Odat cu trecerea la noua schem compatibil, prin folosirea XMLVALIDATE, se poate continua referirea la noua schem folosind numele SQL existent, sau numele URI cu condiia ca numele URI s rmn neschimbat att pentru documentele existente ct i pentru cele noi. De obicei, trecerea la noua schem compatibil se face atunci cnd modificrile petrecute n cadrul schemei sunt nesemnificative. De exemplu, s urmrim situaia n care apar o serie de modificri minore n cadrul unei scheme. Paii ce trebuie urmai presupun nlocuirea schemei existente cu schema nou, modificat, pentru a realiza cu succes operaia n XSR: 1. Se apeleaz procedura stocat XSR_REGISTER sau se execut comanda REGISTER XMLSCHEMA pentru a nregistra schema cea nou n XSR. De remarcat este faptul c nu trebuie validate documentele cu ajutorul noii scheme XML, dac nu se urmrete dect nlocuirea vechii scheme cu una nou, aa cum se arat n pasul urmtor. 2. Se apeleaz procedura stocat XSR_UPDATE sau se execut comanda UPDATE XMLSCHEMA pentru a actualiza noua schem XML n XSR prin nlocuirea schemei vechi. Odat realizat nlocuirea, doar schema cea nou mai poate fi folosit. Dac se folosete opiunea dropnewschema n procedura stocat XSR_UPDATE sau n comanda XMLSCHEMA, atunci schema cea nou poate fi folosit doar cu numele celei vechi i nu cu numele folosit la nregistrare.

8.3 XPath
XPath 2.0 este un limbaj folosit la prelucrarea valorilor care corespund modelului de date XQuery/XPath Data Model (XDM). XPath folosete expresii de cale ce verific calea ce trebuie parcurs pentru a naviga prin documentele XML. Acesta reprezint un aspect foarte important att n XSLT ct i n XQuery i este o recomandare W3C.

8.3.1 Modelul de date XPath

XDM are trei reprezentri ale documentelor XML. Valorile din XDM sunt secvene ce conin zero sau mai multe obiecte ce pot fi: Valori atomice, cum ar fi cele de tip integer, string, sau Boolean Noduri XML cum ar fi documente, elemente, atribute sau text Expresiile XQuery sau XPath lucreaz cu instanele XDM i produc instane XDM. O secven este o instan XDM ce conine o colecie ordonat de zero sau mai multe obiecte. Un obiect poate fi sau o valoare atomic, aa cum s-a artat mai sus, sau un nod. Valorile atomice sau nodurile pot fi introduse n orice ordine n cadrul unei secvene. Secvenele nu pot fi imbricate. Dac se combin dou sau mai multe secvene, rezultatul obinut este o secven care conine toate obiectele existente n secvenele surs. De exemplu, introducerea unei secvene (<x/>, <y/>, 45) ntre dou obiecte ale secvenei

Capitolul 8 Limbaje de interogare pentru XML 199 ("beta", 2) conduce la obinerea secvenei ("beta", <x/>, <y/>, 45, 2). Notaia utilizat n acest exemplu este consistent fa de sintaxa folosit pentru crearea secvenei n XQuery. ntreaga secven este introdus ntre paranteze, iar obiectele se separ prin virgule.

8.3.2 Noduri de tip document

Un nod de tip document este un nod n cadrul unui document XML care marcheaz nceputul documentului XML. Fiecare document XML trebuie s posede un nod de tip document, iar ntr-un document XML nu pot exista mai multe noduri de tip document. n DB2, n cazul unei secvene returnat prin intermediul unei comenzi XQuery sau XPath, aceasta trebuie tratat sub forma unui document XML, folosindu-se nodul constructor. Figura 8.5 prezint diverse tipuri de noduri ce pot alctui un model de date XML.

Figura 8.5 Model de date XML Data Model: tipuri de noduri De exemplu, urmtoarea comand conine o expresie de coninut care returneaz un document XML care conine un element rdcin numit customer-list:
document { <customer-list> {db2-fn:xmlcolumn('MYSCHEMA.CUSTOMER.INFO')/ns1:customerinfo/name} </customer-list> }

ntr-un document XML alctuit corect, primul nod este nodul rdcin. De exemplu, n documentul XML de mai jos, elementul <products> este un nod de tip

Baze de date - Fundamente document. Nodul de tip document este, uneori, numit i nodul rdcin.
<products> <product pid="100-201-01"><description> <name>Ice Scraper, Windshield 4 inch</name> <price>3.99</price></description> </product> </products>

200

8.3.3 Expresii de cale

Expresiile de cale se folosesc de obicei n XPath. Acestea sunt alctuite din unul sau mai muli pai separai prin intermediul unui slash (/) sau dublu slash (//). Fiecare pas produce o secven de noduri care se folosesc sub forma unor noduri de tip coninut pentru pasul urmtor. Valoarea unei expresii de cale este secvena obiectelor obinute la ultimul pas al expresiei de cale. Primul pas stabilete punctul de pornire sau locaia. De obicei, se folosete o funcie sau o variabil care ntoarce secvena de noduri. Primul "/" nseamn c acea cale ncepe de la nodul rdcin. "//" nseamn c acea cale ncepe cu o secven alctuit din nodul rdcin i toi descendenii si.

8.3.4 Parcurgere avansat n XPath

Fiecare pas poate reprezenta o etap de tip ax sau o expresie de filtrare. O etap de tip ax este alctuit din trei pri: O ax opional care specific direcia deplasrii prin documentul XML sau prin fragmentul de document; Un nod de testare care stabilete criteriile folosite la selecia nodurilor; i Zero sau mai multe predicate care filtreaz secvena produs n etapa respectiv. Rezultatul etapei de tip ax este o secven de noduri, fiecare nod avnd ataat o valoare ce corespunde poziiei din cadrul secvenei. Fiecare nod poate fi accesat prin intermediul poziiei sale.

8.3.5 Semantica XPath

Tabelul de mai jos prezint diversele axe suportate n DB2. Axa Proprie Copil Descendent Descrierea ntoarce nodul de tip coninut. ntoarce copilul nodului de tip coninut ntoarce descendenii nodului de tip coninut Direcia Spre nainte Spre nainte Spre nainte

Capitolul 8 Limbaje de interogare pentru XML 201 Descendent propriu Printe Atribut sau ntoarce nodul de tip coninut mpreun cu descendenii si ntoarce printele nodului de tip coninut ntoarce atributele nodului de tip coninut Spre nainte

Spre napoi Spre nainte

Un nod de testare reprezint o condiie ce trebuie s fie adevrat pentru fiecare nod care este selectat prin intermediul unei axe. Nodul de testare poate fi sau un test de nume sau un test de tip. Un test de nume filtreaz nodurile pe baza numelor lor. Este alctuit din QName sau un caracter nlocuitor i, atunci cnd este folosit, selecteaz nodurile (elemente sau atribute) care corespund QNames. QNames corespunde dac QName expandat al nodului este egal cu QName expandat din testul de nume. Dou QNames expandate sunt egale dac aparin aceluiai domeniu de nume, iar numele lor locale sunt identice. Tabelul de mai jos arat toate testele de nume ce pot fi folosite. Test QName Descriere Corespunde tuturor nodurilor al cror QName este acelai cu QName specificat Corespunde tuturor nodurilor al cror nume de domeniu URI este acelai cu numele de domeniu la care este asociat prefixul specificat. Corespunde tuturor nodurilor al cror nume local este acelai cu NCName specificat Corespunde tuturor nodurilor

NCName.*

*.NCName

Un test de tip al nodurilor de filtrare depinde de tipul acestora. Tabelul de mai jos arat toate testele de tip suportate n DB2. Test node() text() comment() processing-instruction() element() Descriere Corespunde oricrui tip de nod Corespunde oricrui nod de tip text Corespunde oricrui nod de tip comentariu Corespunde oricrui nod de tip instruciune de procesare Corespunde oricrui nod de tip element

Baze de date - Fundamente attribute() Document-node() Corespunde oricrui nod de tip atribut Corespunde oricrui nod de tip document

202

Exist dou sintaxe pentru paii de tip ax: abreviat i neabreviat. Sintaxa neabreviat este alctuit dintr-un nume de ax i un test al nodului care se separ prin dou puncte (::). n sintaxa abreviat, axa este omis prin folosirea de notaii prescurtate. Tabelul de mai jos arat sintaxa abreviat suportat n DB2. Sintaxa abreviat Nu este specificat axa @ // Descriere child:: cu excepia cazurilor n care testul de nod este de tip attribute(). n acest caz, se omite prescurtarea axei pentru attribute:: attribute:: /descedent-or-self::node() cu excepia cazurilor n care apare la nceputul expresiei de cale. n acest caz, paii de tip ax seleteaz rdcina arborelui plus toate nodurile descendente. self::node() Parent::node()

. ..

De exemplu, urmtorul tabel preiznt expresiile de cale echivalente Expresia de cale /dept/emp/firstname/child::node() /dept/emp//firstname/parent::node()/@id Expresia de cale cu sintaxa abreviat /dept/emp/firstname /dept/emp/firstname/../@id

8.3.6 Interogri XPath

n DB2 se pot scrie expresii XPath prin ncorporarea acestora n XQuery. De exemplu, urmtoarea interogare XQuery returneaz numele (numele elementelor) tuturor produselor existente n coloana DESCRIPTION din tabelul PRODUCT.

Capitolul 8 Limbaje de interogare pentru XML 203

XQuery db2-fn:xmlcolumn('PRODUCT.DESCRIPTION')/product/description/name Execution result 1 -----------------------------------------------------<name>Snow Shovel, Basic 22 inch</name> <name>Snow Shovel, Deluxe 24 inch</name> <name>Snow Shovel, Super Deluxe 26 inch</name> <name>Ice Scraper, Windshield 4 inch</name> 4 record(s) selected.

Aa cum se vede, xmlcolumn este o funcie XQuery care preia un argument de tip ir de caractere de forma NUMESCHEMA.NUMETABEL.NUMECOLOANAXML. Dac tabelul pe care se execut interogarea se afl n schema implicit, atunci nu trebuie specificat dect NUMETABEL.NUMECOLOANAXML. Db2-fn reprezint domeniul de nume de care aparine funcia xmlcolumn. Funcia xmlcolumn returneaz toate documentele XML existente n coloana specificat. DB2 are i o alt funcie numit sqlquery care ajunge la acelai rezultat cu funcia xmlcolumn. Diferena dintre cele dou funcii const n abilitatea funciei sqlquery de a folosi documente XML specifice spre deosebire de documentele XML returnate prin intermediul funciei xmlcolumn. De exemplu, interogarea XQuery de mai jos ntoarce doar numele acelor produse al cror pid este 100-201-01, n care pid este o coloan relaional.
XQuery db2-fn:sqlquery("select DESCRIPTION from PRODUCT where pid= '100201-01'")/product/description/name Execution result : 1 --------------------------------------------------<name>Ice Scraper, Windshield 4 inch</name> 1 record(s) selected.

8.4 XQuery
XQuery este un limbaj de interogare folosit n cadrul surselor de date XML. XQuery a fost elaborat de grupul de lucru al organizaiei W3C i se afl astzi n faza de recomandare. XQuery este folosit ca standard industrial pentru interogarea documentelor XML, oferind acces declarativ la datele din documentele XML la fel cum face limbajul SQL n cazul datelor relaionale. Figura 8.6 prezint limbajul XQuery i alte standarde XML asociate. Figura arat faptul c att XPath ct i XQuery folosesc ca baz XPath apelnd la expresiile de cale XPath.

Baze de date - Fundamente

204

Figura 8.6 - XQuery i standardele asociate

8.4.1 Fundamentele limbajului XQuery

Fiecare interogare XQuery are dou pri: Prologul, care este opional, este alctuit din declaraii ce stabilesc mediul de execuie al interogrii. Corpul interogrii care este alctuit dintr-o expresie ce pezint rezultatul interogrii. Datele de intrare i de ieire ale unei interogri XQuery sunt ntotdeauna instane XDM. Mai jos este prezentat un exemplu de interogare XQuery, n care comanda declare default element namespace reprezint prologul, iar corpul este alctuit din expresii FLWOR. Expresiile FLWOR vor fi prezentate ntr-o seciune ulterioar.
XQUERY declare default element namespace "http://posample.org"; for $cust in db2-fn:xmlcolumn('CUSTOMER.DESCRIPTION') return $cust/Name/LastName;

Corpul unei interogri XQuery poate fi alctuit din oricare sau din toate expresiile ce urmeaz: Literale sau variabile

Capitolul 8 Limbaje de interogare pentru XML 205 Expresii Path Predicate Construcii If ..then..else Constructori Operatori de comparare Expresii FLWOR

8.4.2 Expresii FLWOR

Expresiile FLWOR reprezint partea esenial a limbajului XQuery. FLWOR este o abreviere provenit din expresiile FOR LET WHERE ORDER BY i RETURN ale XQuery. De multe ori, expresiile FLWOR sunt comparate cu comenzile is SELECT FROM WHERE ORDER BY din limbajul SQL. Mai jos este prezentat o expresie FLWOR simpl n XQuery.
XQuery for $x in db2-fn:xmlcolumn('PRODUCT.DESCRIPTION') let $p := $x/product/description/name where $x/product/description/price < 3 return <cheap_products> {$p} </cheap_products>

Clauza for parcurge secvena i asociaz variabila obiectelor din cadrul secvenei, cte unul odat. n cazul de fa, $x este asociat secvenei de documente XML existente n coloana DESCRIPTION. Pentru fiecare iteraie a clauzei for, $x reine cte un obiect (instana XDM) din grupul de documente XML corespunztor variabilei $p. De exemplu, dac documentul XML este asociat variabilei $x se obin patru nume de produse, dup care toate numele produselor vor deveni parte a secvenei i vor fi asociate variabilei $p. Clauza where este asemntoare clauzei where din SQL i filtreaz grupul de rezultate pe baza unui anumit predicat. n exemplul de fa, clauza where selecteaz doar acele produse al cror pre este mai mic de 3. Clauza return arat instana XDM care se returneaz. Instana XDM poate fi returnat imediat ce este extras cu ajutorul interogrii sau printr-o combinaie de elemente suplimentare existente n clauza return, aa cum se poate vedea n exemplul de mai sus. Mai jos sunt prezentate alte cteva exemple de expresii FLWOR:

Baze de date - Fundamente

1. XQuery for $i in (1 to 3) return $i SAU 2. XQuery for $x in db2-fn:xmlcolumn(PRODUCT.DESCRIPTION)//text() Execution Result 1 ----1 2 3

206

Interogarea de mai sus va returna toate nodurile de tip text din toate documentele existente n coloana DESCRIPTION a tabelului PRODUCT.

8.4.3 Jonciuni n XQuery

ntr-o interogare XQuery pot exista jonciuni efectuate pe mai multe surse XML. Acest lucru este foarte util atunci cnd este nevoie s se interogheze datele XML din mai multe coloane XML. Mai jos este prezentat un exemplu de utilizare a jonciunilor n XQuery.
for $book in db2-fn:xmlcolumn('BOOKS.DOC')/book for $entry in db2-fn:xmlcolumn('REVIEWS.DOC')/entry where $book/title = $entry/title return <review> {$entry/review/text()} </review>;

n exempllul de fa avem o jonciune efectuat pe dou coloane XML numite DOC din dou tabele diferite, numite BOOKS i REVIEWS. Coloana DOC din tabelul BOOKS pstreaz toate informaiile principale despre cri, cum ar fi titlul, autorul i preul crilor n format XML. Coloana DOC din tabelul REVIEWS pstreaz informaiile referitoare la recenzii, cum ar fi titlul crii i recenzorii crii, mpreun cu recenzia propriu-zis. Interogarea XQuery de mai sus returneaz recenziile (doar nodurile de tip text) acelor cri care exist att n tabelul BOOKS ct i n tabelul REVIEWS.

8.4.4 Funcii definite de utilizator

Potrivit specificaiilor XQuery, se pot crea funcii definite de utilizator n cadrul interogrilor XQuery ce pot fi invocate asemntor funciilor obinuite pe perioada execuiei interogrii respective. DB2 are o serie de funcii predefinite ca pot fi folosite n cadrul unei interogri XQuery. Acestea sunt funcii de manipulare a irurilor de caractere, a numerelor i a datelor calendaristice. De asemenea, se mai pot folosi funcii pentru a efectua operaii pe secvene, cum ar fi afiarea invers a secvenei etc. De exemplu, urmtoarea interogare XQuery folosete funcia contains din DB2:

Capitolul 8 Limbaje de interogare pentru XML 207

XQuery declare default element namespace "http://posample.org"; for $x in db2-fn:xmlcolumn('PRODUCT.DESCRIPTION') let $p := $x/product/description/name where $x/product/description/name/fn:contains(text(),'Scraper') return $p Execution result 1 --------------------------------------------------------------------<name>Ice Scraper, Windshield 4 inch</name> 1 record(s) selected.

8.4.5 XQuery i XML Schema

XQuery i XML Schema sunt ambele standarde elaborate de ctre grupurile de lucru ale organizaiei W3C. Specificaiile XML Schema se refer la asocierile dintre tipul de date i instanele XDM. DB2 are o serie de funcii predefinite care transform n mod explicit o serie de valori ale nodurilor n tipuri de scheme XML; de exemplu, interogarea XQuery de mai jos folosete funcia predefinit xs:double.
XQuery declare default element namespace "http://posample.org"; for $x in db2-fn:xmlcolumn('PRODUCT.DESCRIPTION') let $p := $x/product/description/name where $x/product/description/xs:double(price) = 3.99 return $p

8.4.6 Gruparea i agregarea

XQuery suport att gruparea ct i agregarea datelor XML. Mai jos este un exemplu de grupare a datelor XML preluate din dou coloane XML din dou tabele diferite. Interogarea grupeaz numele clienilor din tabelul CUSTOMER. Clauza for efectueaz iteraia n documentele ce conin informaii despre clieni i asociaz fiecare element numit city variabilei $city. Pentru fiecare element city, clauza let face o asociere ntre variabila $cust-names i o list neordonat a tuturor clienilor din oraul respectiv. Interogarea returneaz elementele city care conin numele oraelor precum i numele elementelor imbricate ale tuturor clienilor din oraul respectiv.

Baze de date - Fundamente

XQuery for $city in fn:distinct-values(db2-fn:xmlcolumn('CUSTOMER.INFO') /customerinfo/addr/city) let $cust-names := db2-fn:xmlcolumn('CUSTOMER.INFO') /customerinfo/name[../addr/city = $city] order by $city return <city>{$city, $cust-names} </city>

208

Interogarea ntoarce rezultatul:

Execution result : 1 <city>Aurora <name>Robert Shoemaker</name> </city> <city>Markham <name>Kathy Smith</name> <name>Jim Noodle</name> </city> <city>Toronto <name>Kathy Smith</name> <name>Matt Foreman</name> <name>Larry Menard</name> </city>

Mai jos este prezentat un exemplu de agregare n XQuery. n acest exemplu, interogarea face o iteraie pe elementul PurchaseOrder din anul 2005 i asociaz elementul cu variabila $po n clauza for. Expresia de cale $po/item/ mut apoi poziia coninutului ctre fiecare element din cadrul elementului PurchaseOrder. Expresia (price * quantity) determin valoarea total a acelui obiect. Funcia fn:sum adaug secvena rezultat valorii totale a fiecrui obiect. Clauza let asociaz rezultatul funciei fn:sum variabilei $revenue. Clauza order by sorteaz apoi rezultatele pe baza veniturilor totale ale fiecrei comenzi de achiziie.
for $po in db2-fn:xmlcolumn('PURCHASEORDER.PORDER')/ PurchaseOrder[fn:starts-with(@OrderDate, "2005")] let $revenue := sum($po/item/(price * quantity)) order by $revenue descending return <tr> <td>{string($po/@PoNum)}</td> <td>{string($po/@Status)}</td> <td>{$revenue}</td> </tr>

Capitolul 8 Limbaje de interogare pentru XML 209

8.4.7 Cuantificarea
Expresiile de cuantificare ntorc adevrat sau fals n funcie de satisfacerea unei anumite condiii de ctre unele sau toate obiectele din una sau mai multe secvene. De exemplu:
some $i in (1 to 10) satisfies $i mod 7 eq 0 every $i in (1 to 5) , $j in (6, 10) satisfies $i < $j

Expresiile de cuantificare ncep cu un cuantificator: some or every. Cuantificatorul este urmat de una sau mai multe clauze care asociaz variabile cu secvenele returnate de ctre expresii. n primul exemplu, $i reprezint variabila, iar (1 la 10) reprezint secvena. n cel de-al doilea exemplu, avem dou variabile $i i $j care se asociaz la (1 la 5) i, respectiv, (6 la 10). n continuare se folosete o expresie de testare n care apar variabilele asociate. Expresia de testare se folosete pentru a determina dac unele sau toate variabilele asociate satisfac o anumit condiie. n primul exemplu, condiia este $i mod 7 este egal cu 0. Calificatorul acestei expresii este some, existnd o valoare pentru care expresia de testare este adevrat, astfel c rezultatul este adevrat. n cel de-al doilea exemplu, condiia este $i este mai mic dect $j. Calificatorul este every, astfel c trebuie verificat dac fiecare valoare a lui $i este mai mic dect fiecare valoare a lui $j. n acest caz rezultatul este adevrat.

8.5 XSLT
XSLT este acronimul pentru eXtensible Stylesheet Language Transformations, care este parte a standardului XSL i care descrie felul n care se transform (modific) structura unui document XML ntr-o alt structur n cadrul altui document XML. Aceasta ajut la reprezentarea acelorai date n diverse formate. De exemplu, detaliile comenzilor de achiziie pstrate sub forma unor documente XML pot fi transformate, folosind o serie stiluri, n diverse formate. Acelai document poate fi prezentat pe un site Web n format tabelar prin folosirea etichetelor HTML. Figura 8.7 arat felul n care se folosete XSLT.

Figura 8.7 - XSL (XML): o singur surs, mai multe formate

Baze de date - Fundamente n DB2 9.7, pentru a efectua transformri XSLT sunt necesare dou lucruri. 1. Documentul XML surs 2. XSLT Stylesheet

210

XSLT Stylesheet reprezint tot un document XML corect alctuit, motiv pentru care poate fi pstrat ntr-o coloan XML a unui tabel din DB2. Mai jos se prezint un exemplu de document XSLT Stylesheet.
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <html> <body> <h2>Product Details</h2> <table border="1"> <tr > <th>Name</th> <th>Price</th> </tr> <xsl:for-each select="product/description"> <tr> <td><xsl:value-of select="name"/></td> <td><xsl:value-of select="price"/></td> </tr> </xsl:for-each> </table> </body> </html> </xsl:template> </xsl:stylesheet>

Exemplu de document surs ce trebuie transformat:

<products> <product pid="100-201-01"> <description> <name>Ice Scraper, Windshield 4 inch</name> <details>Basic Ice Scraper 4 inches wide, foam handle</details> <price>3.99</price> </description> </product> </products>

DB2 9.7 pune la dispoziie funcia XSLTransform care preia documentul XML surs i fiierul de stil XSLT ca date de intrare i returneaz rezultatul transformrii (tot un

Capitolul 8 Limbaje de interogare pentru XML 211 document XML). De exemplu, urmtoarea comand SELECT care folosete funcia XSLTransform ntoarce documentul HTML care poate fi salvat sub forma unui fiier .html
SELECT XSLTRANSFORM (description USING stylesheet AS CLOB (10M)) FROM product where pid like 100-201-01 Execution Result : 1 ---------------------------------------------------------<html> <body> <h2>Product Details</h2> <table border="1"> <tr> <th>Name</th><th>Price</th> </tr> </table> </body> </html> 1 record(s) selected.

8.6 SQL/XML
SQL/XML stabilete un mecanism standard de utilizare a datelor XML mpreun cu comenzi SQL. Este un standard ANSI/ISO care definete o serie de extensii bazate pe SQL (funcii) care permit efectuarea de operaii att pe datele relaionale ct i pe documentele XML. De asemenea se mai introduce XML ca tip de dat. Aceste funcii sunt tratate ca extensii ale comenzilor SQL. Se mai stabilesc i funciile care analizeaz documentele XML i care valideaz documentele XML n conformitate cu schema corespunztoare. Exist i alte funcii cum ar fi XMLCONCAT sau XMLAGG ce pot fi folosite pentru a aduna mai multe fragmente XML ntr-un singur document XML de dimensiuni mai mari.

8.6.1 Transformarea relaiilor n documente XML

SQL/XML are funcii de transformare a datelor relaionale n format XML i invers. Exist funcii de validare, analizare i serializare a documentelor XML. Funciile de publicare sunt necesare atunci cnd este nevoie s se trimit date n format XML ctre o aplicaie. De exemplu, dac se invoc un serviciu Web care returneaz cotaia stocului ce are un anumit cod (sub forma unui document XML) atunci stocul, care este pstrat n tabelele relaionale poate fi adus n format XML, dup care serviciul Web poate trimite documentul XML ctre aplicaia care are nevoie de acesta. n multe situaii, s-ar putea s fie necesar folosirea echivalentului relaional al unor fragmente XML ctre instrumente ce folosesc acest format pentru a-l folosi la prelucrarea ulterioar.

Baze de date - Fundamente

212

8.6.2 Pstrarea i publicarea documentelor XML

Funciile de publicare sunt funcii SQL/XML care se folosesc pentru a transforma datele relaionale n format XML i invers.

8.6.3 Funcii SQL/XML

S vedem cteva astfel de funcii i sintaxa acestora. 8.6.3.1 XMLELEMENT i XMLATTRIBUTES XMLELEMENT i XMLATTRIBUTES sunt dou dintre cele mai folosite funcii de publicare. Aa cum i sugereaz i numele, funcia XMLELEMENT creeaz un element XML pe baza unor date relaionale. De exemplu, urmtoarea comand SELECT produce rezultatele de mai jos.
Select XMLELEMENT(NAME "firstname", firstnme) from employee Execution Result: 1 -------------------------------------------<FIRSTNAME>CHRISTINE</FIRSTNAME> <FIRSTNAME>MICHAEL</FIRSTNAME> <FIRSTNAME>SALLY</FIRSTNAME> <FIRSTNAME>JOHN</FIRSTNAME> <FIRSTNAME>IRVING</FIRSTNAME> <FIRSTNAME>EVA</FIRSTNAME> 6 record(s) selected.

n acest exemplu, NAME este un cuvnt cheie care arat c irul ce urmeaz dup acesta reprezint numele unui element ce trebuie creat. irul arat c numele elementului este urmat de un nume de coloan, care este firstname, n acest exemplu. Funcia XMLATTRIBUTES se utilizeaz pentru a crea atribute pe baza datelor relaionale. De exemplu, comanda SELECT va produce rezultatul de mai jos.
Select XMLELEMENT(NAME "emp" , XMLATTRIBUTES(EMPNO AS "employee_num" )) from employee Execution Result : 1 ------------------------------------------------------<EMP EMPLOYEE_NUM="000010"/> <EMP EMPLOYEE_NUM="000020"/> <EMP EMPLOYEE_NUM="000030"/> <EMP EMPLOYEE_NUM="000050"/> <EMP EMPLOYEE_NUM="000060"/> 6 record(s) selected.

Capitolul 8 Limbaje de interogare pentru XML 213 Funcia XMLATTRIBUTES preia att numele atributului ct i valoarea acestuia sub forma unui singur parametru n format A AS "B", n care A reprezint valoarea atributului, care poate fi o coloan relaional (empno) urmat de cuvntul cheie AS i de un ir de caractere care arat numele atributului (employee_num). De remarcat este faptul c elementul EMP nu are nici o valoare de tip text. Mai jos este prezentat un alt exemplu de utilizare a funciei XMLATTRIBUTES n care elementul EMP are dou atribute (NUM i SALARY). De asemenea mai are i dou elemente subordonate (FIRST i LAST), care indic numele i prenumele unui angajat.
Select XMLELEMENT(NAME "emp" , XMLATTRIBUTES(EMPNO AS "NUM",SALARY as "salary" ), XMLELEMENT(NAME "first" , firstnme), XMLELEMENT(NAME "last", lastname) ) from employee Execution Result : 1 ----------------------------------------------------------<EMP NUM="000010" SALARY="152750.00"><FIRST>CHRISTINE</FIRST><LAST>HAAS</LAST></EMP> <EMP NUM="000020" SALARY="94250.00"><FIRST>MICHAEL</FIRST><LAST>THOMPSON</LAST></EMP> <EMP NUM="000030" SALARY="98250.00"><FIRST>SALLY</FIRST><LAST>KWAN</LAST></EMP> <EMP NUM="000050" SALARY="80175.00"><FIRST>JOHN</FIRST><LAST>GEYER</LAST></EMP> <EMP NUM="000060" SALARY="72250.00"><FIRST>IRVING</FIRST><LAST>STERN</LAST></EMP>

8.6.3.2 XMLQUERY Unul dintre avantajele folosirii SQL/XML doar cu interogri XQuery este acela c se pot extrage att date relaionale ct i date n format XML din acelai tabel n acelai timp. XMLQUERY este o funcie SQL/XML ce permite efectuarea acestei operaii. Funcia XMLQUERY preia o constant de tip expresie XQuery, o expresie ce ntoarce valori n format XML. De exemplu, urmtoarea comand SELECT ntoarce identificatorii i numele tuturor produselor din tabelul PRODUCT.

Baze de date - Fundamente

SELECT pid , XMLQUERY('$DESCRIPTION/product/description/name' "PRODUCTNAME" FROM product Execution Result : PID PRODUCTNAME -----------------------------------------------------------100-100-01 <name>Snow Shovel, Basic 22 inch</name> 100-101-01 <name>Snow Shovel, Deluxe 24 inch</name> 100-103-01 <name>Snow Shovel, Super Deluxe 26 inch</name> 100-201-01 <name>Ice Scraper, Windshield 4 inch</name> 4 record(s) selected. ) AS

214

Numele produselor se gsesc n coloana DESCRIPTION care conine documente XML ce descriu produsul. De remarcat este faptul c dac sunt mai multe coloane DESCRIPTION (ca rezultat al jonciunii dintre dou sau mai multe tabele) atunci se poate folosi clauza PASSING aa cum se vede mai jos.
SELECT pid , XMLQUERY('$D/product/description/name' PASSING prod.description as "D" ) AS "PRODUCTNAME" FROM product prod, purchaseorder po

Dac documentele XML conin nume de domenii, atunci interogarea trebuie rescris, aa cum se vede n exemplul urmtor:
SELECT pid , XMLQUERY('$DESCRIPTION/*:product/*:description/*:name' ) AS "PRODUCTNAME" FROM product Execution Result : PID PRODUCTNAME -------------------------------------------------------------------100-100-01 <name xmlns="http://posample.org">Snow Shovel, Basic 22 inch</name> 100-101-01 <name xmlns="http://posample.org">Snow Shovel, Deluxe 24 inch</name> 100-103-01 <name xmlns="http://posample.org">Snow Shovel, Super Deluxe 26 inch</name> 100-201-01 <name xmlns="http://posample.org">Ice Scraper, Windshield 4 inch</name> 4 record(s) selected.

n acest exemplu, funcia XMLQUERY returneaz o secven XML din toate documentele XML din coloana respectiv. Dac se dorete s se extrag doar un anumit produs pe baza unui predicat, atunci trebuie folosit funcia XMLEXISTS mpreun cu XMLQUERY. De exemplu, urmtoarea comand SELECT va extrage numele produselor care au pid 100-103-01 i preul de 49.99

Capitolul 8 Limbaje de interogare pentru XML 215

SELECT pid , XMLQUERY('$DESCRIPTION/*:product/*:description/*:name' ) AS "PRODUCTNAME" FROM product where XMLEXISTS($DESCRIPTION/*:product[@pid="100-10301"]/*:description[*:price="49.99"]) Execution Result : PID PRODUCTNAME ---------------------------------------------------------------------100-103-01 <name xmlns="http://posample.org">Snow Shovel, Super Deluxe 26 inch</name> 1 record(s) selected.

Un aspect important de utilizare a funciilor XMLEXISTS i XMLQUERY, pentru a corespunde condiiilor cerute de predicat, este acela c se elimin secvenele goale. Acestea sunt returnate de XMLQUERY ca rnduri ce nu corespund. XMLEXISTS va returna adevrat sau fals n funcie de ndeplinirea condiiei din predicat. Funcia XMLQUERY va returna apoi o secven pentru fiecare valoare corespondent adevrat returnat de funcia XMLEXISTS eliminnd astfel secvenele goale. De exemplu, dac comanda SELECT cu predicate este scris fr a folosi funcia XMLEXISTS aa cum se vede mai jos, rezultatul va crea confuzie. n comanda SELECT de mai jos, predicatul este parte a constantei de tip expresie XQuery introdus ca parametru al funciei XMLQUERY
SELECT pid , XMLQUERY(' $DESCRIPTION/*:product[@pid="100-10301"]/*:description[*:price="49.99"]/*:name') AS "PRODUCTNAME" FROM product Execution Result: PID PRODUCTNAME ----------------------------------------------------------------------100-100-01 100-101-01 100-103-01 <name xmlns="http://posample.org">Snow Shovel, Super Deluxe 26 inch</name> 100-201-01 4 record(s) selected.

Motivul pentru care exist 3 secvene goale este acela c XMLQUERY ntoarce ntotdeauna o secven. Se va ntoarce o secven corespondent dac predicatul este ndeplinit i o secven goal dac predicatul nu este ndeplinit. De aceea se recomand folosirea funciei XMLEXISTS mpreun cu funcia XMLQUERY pentru a realiza corespondena. 8.6.3.3 XMLAGG Funcia XMLAGG ntoarce o secven ce conine un obiect pentru fiecare valoare nenul dintr-un set de valori XML. De exemplu, urmtoarea comand SELECT va pune angajaii

Baze de date - Fundamente ce aparin unui singur departament ntr-un singur grup:
SELECT XMLELEMENT (NAME "Department", XMLATTRIBUTES (e.workdept AS "name" ), XMLAGG ( XMLELEMENT (NAME "emp", e.firstnme) ) AS "dept_list" FROM employee e GROUP BY e.workdept;

216

Rezultatul execuiei va fi::

dept_list -------------------------------------------------------------------<Department name="A00"> <emp>CHRISTINE</emp> <emp>VINCENZO</emp> <emp>SEAN</emp> <emp>GREG</emp> </Department> <Department name="B01"> <emp>MICHAEL</emp> </Department> <Department name="C01"> <emp>SALLY</emp> <emp>DELORES</emp> <emp>HEATHER</emp> <emp>KIM</emp> </Department> <Department name="D21"> <emp>EVA</emp> <emp>MARIA</emp> </Department> <Department name="E01"> <emp>JOHN</emp> </Department>

8.7 Interogarea documentelor XML pstrate n tabele

n afara crerii de documente XML pe baza datelor relaionale folosind funcii SQL/XML se mai pot folosi i interogri XQuery pentru a interoga documentele pstrate n coloanele de tip XML. Dac este nevoie s se foloseasc comanda SQL SELECT atunci se poate folosi funcia XMLQUERY din SQL/XML creia i se trece, sub forma unui parametru al acestei funcii, interogarea XQuery. Alegerea limbajului de interogare depinde de tipul de date ce trebuie extrase. Dac sunt necesare doar date n format XML, atunci exist posibilitatea utilizrii XQuery sau a funciei

Capitolul 8 Limbaje de interogare pentru XML 217 XMLQUERY, ntr-o comand SELECT. Dac trebuie extrase att date relaioanle ct i date n format XML, atunci alegerea ideal este folosirea comenzilor SELECT mpreun cu XMLQUERY.

8.8 Modificarea datelor

Pstrarea documentelor XML n interiorul unei baze de date este un aspect important al managementului datelor. Aceasta reprezint o cerin obligatorie a zilelor noastre n scopul compatibilizrii cu standardele existente i de a rspunde rapid la cererile de modificare solicitate de ctre clieni. DB2 nu numai c ofer o stocare eficient a documentelor XML, pstrnd formatul nativ al acestora, dar ofer i modaliti de manipulare a datelor XML stocate. Se ofer o serie de funcii cum ar fi XMLPARSE i XMLSERIALIZE, pentru a converti prezentarea sub form de text a documentelor XML n format nativ XML i invers.

8.8.1 XMLPARSE
Aa cum s-a artat mai sus, XMLPARSE este o funcie care analizeaz un text XML transformndu-l n format nativ XML (formatul ierahic de tip arbore). n mod implicit, la inserare, DB2 face o analiz a textului XML, dar dac utilizatorul dorete s analizeze n mod explicit textul XML, atunci trebuie folosit funcia XMLPARSE. De exemplu, urmtoarea comand INSERT mai nti analizeaz textul XML i dac textul este corect alctuit, continu cu introducerea documentului XML n coloana specificat din tabel.
INSERT INTO PRODUCT(PID,DESCRIPTION) VALUES(100-345-01, XMLPARSE( DOCUMENT <product xmlns="http://posample.org" pid="100-100-01"> <description><name>Snow Shovel, Basic 22 inch</name> <details>Basic Snow Shovel, 22 inches wide, straight handle with DGrip</details> <price>9.99</price> <weight>1 kg</weight> </description> </product> ))

Un alt motiv de utilizare a funciei XMLPARSE este acela c se permite specificarea modului de tratare a spaiilor libere. Implicit, DB2 elimin spaiile libere dintre elemente, dar dac utilizatorul dorete s le pstreze, atunci poate folosi clauza PRESERVE WHITESPACE aa cum se arat mai jos.
INSERT INTO PRODUCT(PID,DESCRIPTION) VALUES(100-345-01, XMLPARSE( DOCUMENT <product xmlns="http://posample.org" pid="100-100-01"> <description><name>Snow Shovel, Basic 22 inch</name> <details>Basic Snow Shovel, 22 inches wide, straight handle with DGrip</details> <price>9.99</price> <weight>1 kg</weight> </description> </product> PRESERVE WHITESPACE))

Baze de date - Fundamente

218

8.8.2 XMLSERIALIZE
Aa cum i arat i numele, funcia XMLSERIALIZE se folosete pentru a serializa structura arborescent XML n format ir de caractere/binar. Se permite ca arborele s fie serializat n formate de tip CHAR/CLOB/BLOB. Acest tip de serializare este necesar atunci cnd trebuie manipulat documentul XML n format text, deoarece orice dat returnat de ctre o interogare XQuery este n format XML. De exemplu, urmtoarea comand SELECT va parcurge documentele XML din coloana DESCRIPTION a tabelului PRODUCT i le va returna sub forma unor obiecte serializate de tip CLOB ce aparin produsului ce are pid 10010001.
SELECT XMLSERIALIZE(DESCRIPTION AS CLOB(5K)) FROM PRODUCT WHERE PID LIKE 10010001

Execution Result:
1 -----------------------------------------------------------------------<product xmlns="http://posample.org" pid="100-100-01"> <description><name>Snow Shovel, Basic 22 inch</name> <details>Basic Snow Shovel, 22 inches wide, straight handle with DGrip</details><price>9.99</price><weight>1 kg</weight> </description> </product> 1 record(s) selected.

8.8.3 Expresia TRANSFORM

Expresia TRANSFORM a fost introdus n versiunea DB2 9.5 i permite utilizatorului s modifice documentele XML existente n coloanele de tip XML. Expresia de transformare aparine XQuery Facilitatea de actualizare permite urmtoarele operaii ce pot fi efectuate ntr-o instan XDM. Inserarea unui nod Eliminarea unui nod Modificarea unui nod prin modificarea unor proprieti, dar cu pstrarea identitii Crearea unei copii modificate a unui nod cu o nou identitate. Mai jos este prezentat un exemplu de utilizare a expresiei de transformare care actualizeaz un document XML al unui client cu identificatorul cid=1000. Expresia de transformare actualizeaz att valoarea elementului phone number ct i valoarea atributului type la valoarea home. Documentul XML nainte de comanda de actualizare:

Capitolul 8 Limbaje de interogare pentru XML 219

<customerinfo> <name>John Smith</name> <addr country=Canada"> <street>Fourth</street> <city>Calgary</city> <state>Alberta</state> <zipcode>M1T 2A9</zipcode> </addr> <phone type="work">963-289-4136</phone> </customerinfo>

Comanda de actualizare cu expresia de transformare:

update customer set info = xmlquery( 'copy $new := $INFO modify ( do replace value of $new/customerinfo/phone with "416-123-4567", do replace value of $new/customerinfo/phone/@type with "home" ) return $new') where cid = 1000;

Documentul XML dup actualizare:

<customerinfo> <name>John Smith</name> <addr country=Canada"> <street>Fourth</street> <city>Calgary</city> <state>Alberta</state> <zipcode>M1T 2A9</zipcode> </addr> <phone type="home">416-123-4567</phone> </customerinfo>

8.9 Rezumat
XML este un model de date foarte flexibil fiind foarte potrivit pentru un anumit gen de aplicaii. Este o alegere ideal pentru aplicaiile care necesit modificri, actualizri de scheme i pentru obiectele care sunt prin natura lor de tip ierarhic. Posibilitatea de a reprezenta date semi-strucutrate face din XML o alegere bun pentru a face schimb de date precum i pentru integrarea datelor atunci cnd acestea provin din surse diverse. DB2 ofer suport pentru pstrarea documentelor XML n forma lor nativ, gestionnd eficient i permind interogarea cu uurin a documentelor XML. Se ofer utilizatorului posibilitatea alegerii limbajului pe care l dorete. Astfel se poate utiliza XQuery sau SQL/XML, n funcie de datele accesate, dar i de preferine. DB2 mai ofer avantajul flexibilitii n ceea ce privete nmagazinarea schemelor i a validrii instanelor de documente XML relativ la aceste scheme.

Baze de date - Fundamente

220

Caracteristica de transformare existent n DB2 ofer o modalitate uoar de a face modificri n cadrul documentelor XML fr a fi necesare modificri la nivelul aplicaiei.

8.10 Exerciii
1. S se creeze un tabel cu o singur coloan relaional (cid) i o coloan de tip XML. Apoi s se insereze documente XML cu urmtoarea structur:
<customer id=C62> <firstname>Pete</firstname> <lastname>Bush</lastname> <address> <door>No 34</door> <building>Galaxy Apartment</building> <road>Meera road</road> <city>Mumbai</city> <zip>411202</zip> </address> </customer>

2. S se insereze datele provenite de la 5 clieni sub forma unor documente XML folosind aceeai structur ca cea de mai sus, folosind comanda INSERT. Identificatorii cid ai celor 5 clieni sunt respectiv, 10, 13, 15, 20, 23. 3. S se efectueze o comand SELECT pe un tabel pentru a extrage toate datele relaionale i XML. 4. S se scrie interogarea XQuery necesar pentru a obine toate documentele XML pstrate n tabel. 5. S se scrie interogarea XQuery necesar pentru a extrage documentele XML selectate din cadrul coloanei XML al crei identificator cid este cuprins ntre 10 i 20

8.11 ntrebri recapitulative

1. Care dintre urmtoarele funcii SQL/XML nu este o funcie de publicare? A. XMLELEMENT B. XMLATTRIBUTE C. XMLCONCAT D. XMLPARSE E. Nici una dintre cele enumerate 2. Fie urmtoarea definiie de tabel:
create table clients( id int primary key not null,

Capitolul 8 Limbaje de interogare pentru XML 221

name status contactinfo varchar(50), varchar(10), xml )

i datele XML aflate n coloana contactinfo

<customerinfo> <name>Kathy Smith> <addr country=Canada> <city>Toronto</city> <prov-state>Ontario</prov-state> <zip>M5H-4C9</zip> </addr> </customerinfo> <customerinfo> <name>Amit Singh> <addr country=Canada> <city>Markham</city> <prov-state>Ontario</prov-state> <zip>N9C-3T6</zip> </addr> </customerinfo>

Care este rezultatul urmtoarei interogri?

select xmlquery('$c/customerinfo/addr/city[1]' passing info as "c") \ from xmlcustomer \ where xmlexists('$c/customerinfo/addr[prov-state="Ontario"]' \ passing xmlcustomer.info as "c")

A. Toronto Markham B. <City>Toronto</City> <City>Markham</City> C. <City>Toronto Markham</City> D. Nici unul dintre cele enumerate 3. Analizarea unui document XML reprezint un proces de conversie a: A. Datelor relaionale din formatul relaional n format ierarhic. B. Datelor XML din formatul ir de caractere serializat n forma ierarhic

Baze de date - Fundamente C. Datelor XML din formatul ierarhic n formatul ir de caractere serializat D. Datelor XML din formatul ierarhic n formatul relaional E. Nici una dintre cele enumerate 4. FLWOR vine de la: A. For, Lower, Where, Or, Run B. From, Let, Where, Or, Reset C. For, Let, Where, Order by, Reset D. For, Let, Where, Order by, Return 5. Cnd se folosete o interogare XQuery mpreun cu o interogare SQL: A. Trebuie lucrat cu atenie deoarece XQuery este case sensitive, iar SQL nu. B. Nu trebuie s v ngrijorai deoarece ambele sunt case insensitive. C. Trebuie lucrat cu atenie deoarece SQL este case sensitive, iar XQuery nu. D. Nu trebuie s v facei griji. E. Nici una dintre cele enumerate 6. Ce face urmtoarea interogare XQuery:
" xquery db2-fn:xmlcolumn('NNXML1.XMLCOL')/a/b "

222

A. Extrage elementul b, care este subordonat elementului a, din coloana XML numit XMLCOL a tabelului NNXML1 B. Extrage elementul a, care este subordonat rdcinii b, din coloana XML numit XMLCOL a tabelului NNXML1 C. Extrage elementul b, care este subordonat rdcinii a, din coloana XML numit NNXML1 a tabelului XMLCOL D. Extrage elementul a in coloana XML numit XMLCOL a tabelului NNXML1 7. Dac urmtorul tabel are un singur document XML n coloana DOC ca mai jos. Descriere tabel: CONTEST (DOC XML)
<dept bldg="111"> <employee id="901"> <name>Ajit Patil</name> <phone>567 789 1342</phone> <office>124</office> </employee> <employee id="922"> <name>Peter Jose</name> <phone>121 768 3456</phone>

Capitolul 8 Limbaje de interogare pentru XML 223

<office>213</office> </employee> </dept>

Care dintre urmtoarele interogri va returna numele elementului <name>Peter Jose</name>? A. db2-fn:xmlcolumn('CONTEST.DOC')/dept/employee[@id="922"]/name B. select xmlquery('$d/dept/employee[@id="922"]/name' passing DOC as "d") from contest C. Ambele D. Nici una dintre cele enumerate 8. Care dintre urmtoarele este echivalent cu interogarea XQuery dat?
xquery db2-fn:xmlcolumn('CONTEST.DOC')/dept/employee[@id="922"]/name

A. xquery db2-fn:xmlcolumn(CONTEST.DOC) /dept/employee/name[../@id=922] B. xquery db2-fn:xmlcolumn(CONTEST.DOC) /dept/employee[../@id=922]/name C. xquery db2-fn:xmlcolumn(CONTEST.DOC) /dept/employee/name[@id=922] D. Nici una dintre cele enumerate 9. n DB2 9.7, care dintre urmtoarele este adevrat atunci cnd se folosete o comand de actualizare, dac expresia XPath $new/customer/phone ntoarce mai multe elemente phone?
update customer set info = xmlquery('copy $new := $information modify do replace value of $new/customer/phone with "091-454-8654" return $new') where cid = 67;

A. Comanda UPDATE nu reuete i apare un mesaj de eroare B. Comanda UPDATE va nlocui toate elementele phone cu noul element phone ce are valoarea de tip text "091-454-8654" C. Comanda UPDATE nlocuiete doar prima apariie a elementului phone cu noul element phone ce are valoarea de tip text "091-454-8654" D. Nici una dintre cele enumerate

9
Capitolul 9 Securitatea bazelor de date
Odat cu dezvoltarea organizaiilor ce au ca obiect de activitate tehnologia informaiei, s-a acumulat un volum foarte mare de date din diferite domenii de activitate. Toate aceste date pot sta la baza unor decizii foarte importante, ceea ce nseamn faptul c datele au devenit extrem valoroase pentru organizaii, astfel nct este necesar s se acorde mare atenie securitii acestora. Din aceste motive, fiecare persoan din cadrul organizaiei trebuie atenionat i responsabilizat referitor la breele de securitate ce pot apare lundu-se msuri pentru a proteja datele din domeniul n care lucreaz. n acest capitol vom discuta despre necesitatea asigurrii securitii n bazele de date, despre conceptele de control al accesului i de siguran n cadrul sistemelor de management al bazelor de date precum i despre o serie de alte aspecte care privesc politicile i procedurile de securitate.

9.1 Securitatea bazelor de date: vedere de ansamblu

De cele mai multe ori, problemele de securitate sunt complexe i pot implica aspecte legale, sociale, sau etice, dar i aspecte legate de politicile implementate sau referitoare la controlul echipamentelor fizice. Securitatea unei baze de date se refer la protecia bazei de date mpotriva pericolelor intenionate sau nu, folosind elemente de control ce pot fi sau nu bazate pe echipamente de calcul. Analiza securitii unei baze de date nu include doar serviciile oferite de sistemul de gestiune al bazei de date, dar i o serie de aspecte asociate bazei de date i securitii mediului. Mai mult, aspectele legate de securitate nu se refer doar la datele existente n baza de date, deoarece breele de securitate pot afecta i alte pri ale sistemului, care, ca rezultat, pot afecta baza de date. n consecin, prin concentrarea ateniei doar asupra securitii bazei de date nu se va obine o baz de date sigur. Toate componentele sistemului trebuie s fie sigure: baza de date, reeaua, sistemul de operare, cldirea n care se afl baza de date, dar i persoanele care acceseaz sistemul. Figura 9.1 prezint vederea de ansamblu asupra securitii unei baze de date.

Baze de date - Fundamente

226

Figura 9.1 Securitatea bazei de date Proiectarea i implementarea unei baze de date sigure implic atingerea urmtoarelor obiective: Caracterul privat, care nseamn c datele nu pot fi cunoscute de persoane neautorizate; Integritatea, care nseamn faptul c doar utilizatorii autorizai pot modifica datele; Disponibilitatea, care nseamn faptul c utilizatorilor autorizai nu trebuie s li se interzic accesul; Pentru a atinge aceste obiective, trebuie eleborat o politic de securitate n care s se fac referire la msurile ce trebuie impuse. n particular, trebuie determinai utilizatorii care pot accesa baza de date precum i datele la care acetia au acces. Suplimentar, trebuie stabilite i operaiile permise pe setul de date. Pentru a atinge aceste obiective se poate apela la mecanismul de securitate oferit de ctre sistemul de gestiune al bazei de date sau la cel oferit de ctre sistemul de operare. Orice alt mecanism exterior, cum ar fi securizarea accesului n cldirea n care se afl baza de date, nu face obiectul discuiilor din cadrul acestui capitol. Persoanele responsabile cu securitatea bazelor de date sunt numite administratori de baze de date (ABD) i trebuie s aib n vedere diversele pericole care pndesc sistemul. ABD stabilesc regulile de autorizare prin care se stabilesc celelalte persoane care vor avea acces la baza de date, care parte a acesteia poate fi accesat de ctre ce utilizator, precum i operaiile permise acestora.

Capitolul 9 Securitatea bazelor de date 227

9.1.1 Necesitatea asigurrii securitii bazei de date

Motivul pentru care securitatea unei baze de date a devenit un aspect att de important este acela al creterii cantitii i importanei cruciale a datelor care sunt colectate i pstrate pe sistemele de calcul. Orice pierdere a disponibilitii datelor sau a pierderii efective a acestora poate avea dimensiuni catastrofice. O baz de date reprezint o resurs colectiv esenial care trebuie asigurat n mod adecvat, folosind elementele de control cele mai potrivite. Pericolele ce pot afecta securitatea datelor pot reprezenta orice situaie sau eveniment intenionate sau nu care ar putea afecta n mod negativ un sistem i, la final, ntreaga organizaie. Distrugerile pot fi tangibile (pierderea datelor) sau intangibile (pierderea credibilitii sau ncrederii clientului). Orice pericol trebuie vzut ca o bre potenial n securitatea sistemului, care dac reuete, va afecta ntreaga organizaie. Cteva exemple de pericole ce pot fi luate n considerare: Datele folosite de ctre un utilizator ce are acces la disc Colectarea sau copierea neautorizat a datelor Modificarea programelor Acces ilegal al unor persoane ru intenionate Furtul datelor, programelor sau echipamentelor Instruirea inadecvat a personalului Prezentrile neautoirizate de informaii Calamiti (foc, inundaii, explozii) Ruperea sau deconectarea cablurilor Virui

Ct de mult sufer o organizaie afectat de materializarea unor astfel de pericole depinde de o serie de factori, cum ar fi existena msurilor de securitate i a planurilor de msuri pentru situaii speciale. De exemplu, dac apare o defeciune hardware care modific capacitatea de stocare, toate activitile de procesare trebuie ntrerupte pn la remedierea problemei. Perioada de inactivitate i viteza de restaurare a bazei de date depind de posibilitatea utilizrii de elemente alternative hardware i software, de perioada de timp trecut de la realizarea ultimei copii de siguran, de timpul necesar pentru restaurarea sistemului, precum i de faptul c datele pierdute nu pot fi restaurate i recuperate. Organizaiile trebuie s identifice tipurile de pericole la care se expun i s adopte planuri i msuri corespunztoare care s aib n vedere i costul implementrii acestora. Pierderea unei cantiti mari de timp, efort i bani pentru rezolvarea unor pericole care ar putea aduce inconveniente minore poate conduce la ineficien, din punct de vedere economic. De fapt, fiecare afacere influeneaz tipurile de pericole ce trebuie avute n

Baze de date - Fundamente

228

vedere, deoarece unele dintre acestea pot apare foarte rar. Totui, i aceste pericole trebuie luate n considerare dac au un impact semnificativ asupra organizaiei. Nu conteaz ct de sigur pare a fi un sistem de calcul, securitatea nu poate fi obinut dect dac i mediul este sigur. Urmtoarele pericole trebuie avute n vedere n orice plan complet de securitate a datelor: Furtul i frauda. Aceste aciuni pot fi ntreprinse de ctre persoane i pot sau nu s modifice datele. n acest caz, atenia trebuie ndreptat ctre fiecare dintre posibilele locaii n care datele sau aplicaiile se afl la un moment dat n mod fizic. Securitatea fizic concret poate fi realizat astfel nct persoanele neautorizate s nu aib posibilitatea s obin accesul la ncperile n care se afl calculatoarele, serverele sau fiierele acestora. Prin folosirea unui firewall se realizeaz protecia la accesul neautorizat la pri ale bazei de date prin stabilirea de conexiuni de comunicare. Pierderea caracterului privat sau al confidenialitii. Confidenialitatea se refer la necesitatea de a pstra secretul datelor. Acest lucru prezint un aspect major pemntru orice organizaie, n timp ce caracterul privat are n vedere protecia datelor cu caracter personal. Pierderea caracterului privat poate conduce la pierderea competitivitii, iar pierderea controlului asupra caracterului privat poate conduce la antaje, probleme sociale sau furt de parole. Unele dintre aceste aspecte pot conduce la probleme cu aspect juridic ale organizaiei din care face parte persoana respectiv. Pierderea integritii datelor. Dac integritatea datelor este compromis, datele vor deveni invalide sau corupte. n acest caz, organizaia va avea de suferit pierderi importante sau va lua decizii greite pe baza detelor eronate. Pierderea disponibilitii. Acest lucru nseamn faptul c datele, sistemul, sau ambele, nu pot fi accesate. Uneori acest fenomen este acompaniat de modificarea datelor i poate conduce la dificulti operaionale severe. O astfel de situaie poate apare ca rezultat al sabotajului, al pierderii conexiunii de reea, al aplicaiilor defectuoase, sau ca urmare a aciunii viuilor. Pierderea accidental a datelor. Aceasta poate fi rezultatul unei erori umane, sau a breelor din cadrul software-ului sau hardware-ului. Pentru a evita pierderea accidental a datelor, organizaia trebuie s stabileasc proceduri clare de autorizare a utilizatorilor, a instalrii software-urilor sau a mentenanei hardware. La fel ca n toate cazurile n care este implicat personal uman, anumite pierderi sunt inevitabile, dar este de dorit ca prin folosirea de politici i proceduri adecvate pierderile sa fie ct mai mici. Securitatea bazei de date i propune s minimizeze pierderile cauzate de evenimentele amintite anterior ntr-o modalitate eficient din punct de vedere al costurilor, fr a impune utilizatorilor constrngeri insuportabile. Deoarece criminalitatea pe calculator este n plin expansiune, iar acest tip de infraciuni poate amenina toate componentele unui sistem, introducerea de msuri de securitate adecvate devine vital.

Capitolul 9 Securitatea bazelor de date 229 Cele mai folosite msuri ce se pot lua pentru a asigura protecia i integritatea datelor sunt: controlul accesului, folosirea vederilor, controlul integritii i criptarea. Este de asemenea necesar s se stabileasc cele mai adecvate politici i proceduri de securitate care se refer la personal i la controlul fizic al accesului.

9.1.2 Controlul accesului

n practic, exist dou concepte importante referitoare la securitatea datelor. Cele dou sunt cunoscute sub denumirea de control discreionar i control obligatoriu. n ambele situaii, unitatea de dat sau obiectul de dat care se protejeaz poate diferi de la ntreaga baz de date la cteva rnduri. Folosind controlul discreionar, utilizatorul va avea diferite drepturi de acces, cunoscute sub denumirea de privilegii acordate pe anumite obiecte. Evident, exist o serie de limitri din punct de vedere al drepturilor pe care un utilizator le are asupra unui anumit obiect. De exemplu, n cazul n care se folosete controlul discreionar, un utilizator poate avea acces la obiectul X din baza de date, dar nu poate avea acces la obiectul Y, n timp ce utilizatorul B poate accesa obiectul Y, dar nu poate accesa obiectul X. Schemele de control diiscreionar sunt foarte flexibile. Se pot combina drepturi care se atribuie utilizatorilor i obiectelor n funcie de necesiti. n cazul controlului obligatoriu, fiecare obiect de dat este asociat unui anumit nivel de clasificare i fiecare utilizator are un anumit nivel de permisiuni. Un anumit obiect de dat poate fi accesat doar de ctre utilizatorii care au permisiunile corespunztoare. Schemele obligatorii sunt ierarhice, motiv pentru care sunt mult mai rigide dect cele discreionare. n funcie de tipul de schem de securitate care se folosete, toate deciziile referitoare la drepturile pe care le au diveri utilizatori asupra obiectelor din baza de date sunt decizii ce depind de domeniul de care aparin i nu de decizii tehnice. Pentru a decide care sunt constrngerile de securitate aplicabile unei cereri de acces, sistemul trebuie s poat recunoate sursa cererii. Cu alte cuvinte, trebuie s recunoasc utilizatorul care a lansat n execuie aplicaia i trebuie s verifice drepturile pe care la are acesta.

9.1.3 Studiu de caz referitor la securitatea unei baze de date

n cadrul acestei seciuni vom analiza felul n care DB2, serverul principal de baze de date de la IBM, rezolv aceste probleme de securitate folosind propriile mecanisme de securitate. Mecanismele de securitate de la DB2 au n vedere dou operaii principale: autorizarea i autentificarea, care sunt folosite mpreun pentru a asigura securitatea accesului la resursele DB2. 9.1.3.1. Autentificarea Autentificarea este prima aciune efectuat n vederea conectrii cu succes la o baz de date DB2. Autentificarea reprezint procesul prin care utilizatorii sunt identificai de ctre sistemul de gestiune al bazei de date, demonstrndu-i identitatea pentru a obine accesul la baza de date.

Baze de date - Fundamente

230

Validarea identitii utilizatorilor i a grupurilor de utilizatori se obine cu ajutorul unor faciliti de securitate care se afl n afara sistemului de gestiune a bazei de date, ceea ce nseamn faptul c acestea acioneaz ca parte a sistemului de operare sau prin utilizarea unor aplicaii separate cum ar fi Kerberos sau Lightweight Directory Access Protocol (LDAP). Autentificarea unui utilizator necesit dou elemente identificatorul utilizatorului i simbolul de autentificare. Identificatorul utilizatorului permite componentei de securitate s identifice utilizatorul i, prin introducerea corect a simbolului de autentificare (de obicei o parol cunoscut doar de ctre utilizator i de ctre componenta de securitate), s verifice identitatea acestuia. Uneori, dac este necesar o flexibilitate mai mare, se pot crea module de securitate personalizate care s fie folosite de ctre DB2. Dup autentificarea cu succes a unui utilizator, identificatorul utilizatorului se asociaz unui identificator de autorizare. Aceast coresponden este determinat prin intermediul unui modul de autentificare. Dac se folosete modulul de securitate implicit pus la dispoziie de ctre IBM, atunci vom avea de a face cu doi identificatori de autorizare derivai: identificatorii de sistem i de sesiune. n acest caz ambii identificatori de autorizare sunt derivai n acelai fel pe baza identificatorului utilizatorului i sunt identici. Identificatorul de autorizare al sistemului se folosete la verificarea privilegiilor de conectare pentru a realiza conectarea. Identificatorul de autorizare al sesiunii este identificatorul primar al coenxiunii urmtoare. 9.1.3.2. Autorizare Dup autentificarea utilizatorului, este necesar s se determine dac utilizatorul respectiv are dreptul s utilizeze anumite date sau resurse. Autorizarea este procesul de acordare a privilegiilor care permit unui subiect s obin accesul legitim la un sistem sau la un obiect al acestuia. Definiia autorizrii conine termenii de subiect i obiect. Subiectul se refer la un utilizator sau program, iar obiectul se adreseaz unui tabel, vedere, aplicaie, procedur sau orice alt obiect ce poate fi creat n cadrul sistemului. Controlul autorizrii poate fi implementat cu ajutorul unor elemente software i poate reglementa att sistemele ct i obiectele la care utilizatorul are acces preciznd ce poate face utilizatorul cu acestea. Din acest motiv, autorizarea se mai numete i controlul accesului. De exemplu, un utilizator poate fi autorizat s citeasc nregistrri din baza de date, dar nu poate modifica sau insera o nregistrare nou. Regulile de autorizare sunt elemente de control ncorporate n cadrul SGBD care restricioneaz aciunile pe care un utilizator le poate ntreprinde la accesarea datelor. Pentru a nregistra permisiunile asociate fiecrui utiliaztor n parte, n DB2 se folosesc tabele i fiierele de configurare. Atunci cnd un utilizator autentificat ncearc s acceseze date, numele de autorizare al acestuia precum i setul de privilegii asociate, acordate direct sau indirect printr-un grup sau rol, sunt comparate cu permisiunile nregistrate. Rezultatul comparaiei se folsoete pentru a stabili dac accesul este permis sau respins. Pentru un identificator de autorizare, exist mai multe surse de permisiuni. Mai nti, exist

Capitolul 9 Securitatea bazelor de date 231 permisiuni acordate n mod direct identificatorului de autorizare. Apoi, exist permisiuni acordate grupurilor i/sau rolurilor al cror membru este utilizatorul. Permisiunile publice sunt acele permisiuni acordate grupuluii PUBLIC n timp ce permisiunile ce depind de context sunt cele acordate unui anumit rol sigur. Pentru a putea efectua diverse activiti, SGBD-ul cere fiecrui utilizator s fie autorizat n mod specific, implicit, sau explicit. Privilegiile explicite sunt acordate unui utilizator, unui grup sau unui rol, n timp ce privilegiile implicite sunt cele obinute prin intermediul grupurilor de care aparine utilizatorul sau prin intermediul rolurilor asociate. DB2 lucreaz cu trei forme de autorizri nregistrate: autoritatea administrativ, privilegii i credeniale Label-Based Access Control (LBAC controlul accesului bazat pe etichete). Un utilizator, un grup, sau un rol poate avea unul sau mai multe dintre aceste tipuri de autorizri. 9.1.3.3 Autoritatea administrativ Autoritatea administrativ confer unei persoane dreptul de a controla baza de date i de a rspounde pentru integritatea datelor. Autoritatea administrativ n DB2 este ierarhic. Pe nivelul cel mai nalt se afl SYSADM. Sub SYSADM se afl dou tipuri de autoriti: la nivel de instan i la nivel de baz de date. Nivelele de autoritate ofer o metod de grupare a diverselor privilegii. Autoritatea pe instana DB2 se aplic tuturor bazelor de date din cadrul instanei i este acordat prin apartenena la grup. Numele grupului ce are acest nivel de autoritate se pstreaz n baza de date, n fiierele de configurare ale managerului bazei de date corespunztoare fiecrei instane. La acest nivel, exist patru tipuri de autoriti de instan DB2: SYSADM (administrator de sistem) controleaz toate resursele create i pstrate de ctre managerul bazei de date. Utilizatorii care au autoritatea SYSADM pot efectua urmtoarele aciuni: migrare de baze de date, modificarea fiierelor de configurare ale managerului baze de date i ale bazei de date, efectuarea de copii de siguran ale bazei de date i fiierelor jurnal i restaurri ale bazei de date i obiectelor acesteia, cum ar fi spaii pentru tabele, acordarea de drepturi i privilegii utilizatorilor, grupurilor sau rolurilor, control complet al instanelor precum i auditul controlului la nivel de instan. SYSCTRL (controlul sistemului) ofer controlul asupra operaiilor care afecteaz resursele sistemului. Un astfel de utilizator poate crea, actualiza, porni, sau opri o baz de date. De asemenea, poate porni sau opri o instan, dar nu poate accesa date din tabele. SYSMAINT (mentenana sistemului) permite efectuarea de operaii de mentenan pe toate bazele de date dintr-o instan. Aceste operaii sunt cele de actualizare a configuraiei bazei de date, de realizare a copiilor de siguran ale bazei de date sau ale spaiilor pentru tabele, de restaurare a unei baze de date sau de monitorizare a acesteia. SYSMAINT nu are acces la date.

Baze de date - Fundamente

232

SYSMON (monitorizarea sistemului) poate opera la nivel de instan. Mai concret, are autoritatea necesar pentru a utiliza monitorul sistemului de baze de date. Autoritile bazelor de date DB2 se leag de o anumit baz de date din cadrul unei instae DB2. Acestea sunt: DBADM (administratorul bazei de date) se folosete la nivel de baz de date i ofer autoritatea administrativ pe o singur baz de date. Administratorul bazei de date are toate privilegiile necesare pentru a crea obiecte, a executa comenzi, i de a accesa toate datele. El poate, de asemenea, s acorde sau s retrag privilegii n mod individual Administratorul bazei de date poate crea fiiere de jurnalizare, tabelele catalog ale sistemului, actualizarea fiierelor de jurnalizare, reorganizarea tabelelor bazei de date sau obinerea de statistici din cataloage. SECADM (administrator de securitate) poate crea, elimina, aproba sau retrage autorizri sau privilegii, cu transferul drepturilor de proprietate pe obiectele de securitate (de exemplu, roluri i etichete LBAC). Nu are dreptul de a accesa date din tabele. CONNECT permite utilizatorului s se conecteze la o baz de date. BINDADD permite utilizatorului s creeze pachete noi n cadrul bazei de date. CREATETAB permite crearea de tabele noi n baza de date. CREATE_EXTERNAL_ROUTINE permite crearea unei proceduri utilizate n cadrul unei aplicaii sau de ctre ali utilizatori. CREATE_NOT_FENCED_ROUTINE permite crearea unei funcii definite de utilizator sau a unei proceduri. IMPLICIT_SCHEMA permite crearea unei scheme sau a unui obiect cu ajutorul comenzii CREATE. n acest caz, SYSIBM devine proprietarul schemei create n mod implicit, iar rolul PUBLIC are dreptul de a crea obiecte n cadrul acestei scheme. 9.1.3.4 Privilegii Privilegiile sunt autoriti atribuite utilizatorilor, grupurilor, sau rolurilor, ce le permit efectuarea diverselor activiti cu obiectele bazei de date. Figura 9.2, prezint o serie dintre aceste privilegii existente n DB2 [9.1].

Capitolul 9 Securitatea bazelor de date 233

Figura 9.2 Lista unor privilegii din DB2 Privilegiile stabilesc activitile ce pot fi efectuate de ctre utilizator cu obiectele bazei de date i pot fi acordate utilizatorilor individuali, grupurilor, roluilor sau rolului PUBLIC. PUBLIC este un grup special cruia i se pot acorda sau retrage anumite autoriti sau privilegii n cadrul unei baze de date. Acest lucru se poate face de ctre utilizatorul care s-a autentificat cu succes pe o instan DB2. Dup crearea unei baze de date se acord implicit urmtoarele privilegii rolului PUBLIC: CONNECT, CREATETAB, BINDADD, IMPLICIT_SCHEMA, SELECT, UPDATE, EXECUTE, USE. Utilizatorii sau grupurile care primesc privilegiile CONTROL pot acorda la rndul lor privilegiul altor utilizatori sau grupuri. 9.1.3.5 Controlul accesului bazat pe etichete Label Based Access Control (LBAC) este o implementare flexibil a controlului obligatoriu al accesului (mandatory access control - MAC). LBAC acioneaz att la nivel de rnd ct

Baze de date - Fundamente

234

i la nivel de coloan i completeaz controlul discreionar al accesului (discretionary access control - DAC). Cele dou nivele de protecie se pot folosi separat sau mpreun. LBAC poate fi configurat s ndeplineasc cerinele de securitate ale fiecrui mediu. Toate configuraiile sunt realizate de ctre administratorul de securitate prin crearea politicilor de securitate care descriu criteriile ce vor fi folosite pentru a decide cine are acces la ce date. Odat stabilit politica de securitate, administratorul de securitate poate crea obiecte numite etichete de securitate ca parte a acestei politici. Dup crearea etichetelor de securitate, acestea pot fi asociate coloanelor i rndurilor din cadrul tabelelor pentru protecia datelor. Datele protejate cu ajutorul unei etihcte de securitate sunt numite date protejate. Administratorul de securitate permite accesul utilizatorilor la datele protejate prin acordarea de etichete de securitate. Atunci cnd un utilizator ncearc s acceseze date protejate, eticheta pe care o deine este comparat cu eticheta acordat datelor. n acest fel se determin dac utilizatorul are dreptul s acceseze datele la nivel de coloan, de rnd sau ambele, sau i este interzis accesul la date. Administratorul de securitate poate folosi excepii pentru a permite accesul acestora la date la care altfel nu ar avea acces. Etichetele de securitate i excepiile sunt credeniale LBAC care se pstreaz n cataloagele bazei de date. Principallul avantaj al folosirii LBAC pentru protecia datelor importante este acela c nici o alt autoritate (SYSDBA, DBADM, i SECADM) nu mai are privilegii implicite de accesare a datelor utilizatorului. 9.1.3.6 Roluri n practic exist situaii n care mai muli utilizatori trebuie s posede acelai grup de privilegii. n acest caz, cel mai bine este ca s se gestioneze acest set de privilegii n comun i nu individual, introducndu-se astfel noiunea de rol. Un rol dintr-o baz de date este un obiect care grupeaz la un loc unul sau mai multe privilegii sau autoriti ale bazei de date. Se poate asocia utilizatorilor, grupurilor, rolului PUBLIC sau altor roluri folosind comanda GRANT. De exemplu, se poate defini rolul de programator, permind acestuia s introduc, actualizeze sau elimine date dintr-un grup de tabele. Prin atribuirea de roluri utilizatorilor, acetia motenesc toate privilegiile rolului respectiv, suplimentar privilegiilor pe care le au deja. Un rol poate controla accesul la o baz de date la nivelul de abstractizare corespunztor structurii organizaiei, deoarece se pot crea roluri corespunztoare celor existente n organizaia respectiv. n acest caz utilizatorii sunt ataai rolurilor pe baza responsabilitilor pe care le au n organizaie. Atunci cnd responsabilitile utilizatorilor se schimb, acetia pot fi trecui n cadrul altui rol. Rolurile pot fi actualizate fr a fi nevoie s se realizeze acest lucru la nivelul fiecrui utilizator. Rolurile sunt gestionate n cadrul bazei de date, iar DB2 poate stabili cnd se modific autorizarea, acionnd corespunztor.

Capitolul 9 Securitatea bazelor de date 235 9.1.3.7 Contexte de ncredere ntr-o arhitectur a modelului organizat pe trei nivele, n care se afl un server Web, o aplicaie server i un server de baze de date, nivelul de mijloc, sau serverul aplicaiei rspunde de autentificarea utilizatorilor care ruleaz aplicaia client i gestioneaz interaciunile cu serverul bazei de date. Identificatorul de autorizare al serverului aplicaiei trebuie s posede toate privilegiile atribuite utilizatorilor pentru a putea efectua operaiile de care are nevoie. n acest fel modelul de aplicaii pe trei nivele prezint o serie de avantaje, prin realizarea tuturor interaciunilor cu serverul bazei de date (aa cum cere utilizatorul) n funcie de identificatorul de autorizare al serverului aplicaiei. Aceasta ns, ridic o serie de probleme de securitate, cum ar fi de exemplu, faptul c nu se va putea determina care client a efectuat o interogare n momentul apariiei unei erori. Contextele de ncredere stabilesc o relaie de ncredere ntre DB2 i o entitate extern, cum ar fi un server de aplicaie sau un alt server DB2. Aceast relaie de ncredere se bazeaz pe urmtoarele atribute: autorizarea sistemului, adresa IP sau numele de domeniu i fluxul de date criptat. Dup conectarea la baza de date atributele conexiunii respective sunt comparate cu definiia fiecrui obiect de tip context de ncredere din cadrul bazei de date. Dac aceste atribute corespund definiiei unui obiect de tip context de ncredere, atunci conexiunea se numete conexiune de ncredere. Acest tip de conexiune permite iniiatorului su s obin faciliti suplimentare care nu sunt valabile dect n cadrul acelei conexiuni de ncredere. Se poate lucra cu dou tipuri de conexiuni de ncredere: explicite sau implicite. O conexiune de ncredere explicit este o conexiune de ncredere care se cere n mod explicit i care permite iniiatorului su s treac de identificatorul curent din cadrul conexiunii la un alt identificator cu sau fr autentificare, i s obin privilegii suplimentare care este posibil s nu mai fie valabile n afara conexiunii de ncredere. O conexiune de ncredere implicit este o conexiune de ncredere care nu este cerut n mod explicit i care permite doar facilitatea de a obine privilegii suplimentare. Pentru a stabili o conexiune de ncredere trebuie definite urmtoarele atribute: Un identificator de autorizare al sistemului care este identificatorul ce trebuie folosit de ctre o conexiune pentru a deveni de ncredere. O list de adrese IP ce reprezint adresele IP de la care trebuie s provin conexiunea pentru a fi declarat de ncredere. Un flux de date criptat ce reprezint nivelul criptrii ce trebuie folosit de ctre o conexiune pentru a fi declarat de ncredere.

9.1.4 Vederi
Alturi de procesul de autorizare, vederile reprezint o component important a mecanismului de securitate oferit de ctre un SGBD relaional. Vederile permit utilizatorului s vad informaiile care i sunt permise n timp ce alte informaii, la care acesta nu are acces, s rmn ascunse.

Baze de date - Fundamente

236

O vedere este un rezultat dinamic al uneia sau mai multor operaii relaionale care se aplic pe unul sau mai multe tabele pentru a produce un alt tabel. O vedere se bazeaz ntotdeauna pe datele curente existente n tabelele de baz din care se obin. Avantajul unei vederi este acela c poate fi creat pentru a arta doar datele la care utilizatorul are acces, mpiedicnd vizualizarea altor date ce pot avea caracter privat sau confidenial. Utilizatorul poate primi dreptul de a accesa o vedere, dar nu i tabelele de baz din care provin.

9.1.5 Controlul integritii

Scopul controlului integritii este acela de protejare a datelor mpotriva utilizrii neautorizate, prin restrngerea variabilelor admise i a operaiilor ce pot fi efectuate pe date. Controlul integritii poate conduce i la declanarea execuiei unei proceduri prestabilite, cum ar fi introducerea de date n cadrul unui jurnal n care se pstreaz istoricul lucrului cu date din partea utilizatorilor. Exist multe forme de control al integritii. Prima form pe care o vom discuta este integritatea domeniului. Un domeniu poate fi vzut ca o modalitate de creare a unui tip de dat definit de utilizator. Odat ce se creeaz un domeniu, acesta poate fi folosit la declararea unei coloane n cadrul unui tabel. La crearea unui domeniu se pot folosi constrngeri (de exemplu, constrngerea CHECK) pentru a restriciona valorile folosite pentru a satisface condiia impus. Un avantaj important al unui domeniu este acela c dac trebuie modificat, atunci modificarea va avea loc ntr-un singur loc n definiia domeniului. Aseriunile reprezint de asemenea o constrngere foarte puternic prin care se impun anumite condiii n baza de date. Acestea sunt verificate n mod automat de ctre SGBD la efectuarea de tranzacii care implic tabele sau cmpuri care au astfel de aseriuni. Dac condiia nu este adevrat, SGBD-ul va genera un mesaj de eroare. Din motive de securitate, n celai scop, se mai pot folosi declanatori. Declanatorii sunt blocuri de cod procedural pstrat n baza de date i care se execut numai la efectuarea unei comenzi de tip INSERT, UPDATE sau DELETE. Un declanator, care conine un eveniment, o condiie i o aciune poate fi mult mai complex dect o aseriune. Poate interzice efectuarea de aciuni nepotrivite, poate controla modul de execuie a anumitor proceduri, sau poate permite scrierea unui rnd n cadrul fiierului de jurnalizare pentru a pstra informaii importante despre utilizator sau despre tranzaciile efectuate asupra datelor critice din baza de date.

9.1.6 Criptarea datelor

Datele cu caracter critic sau personal pstrate n cadrul tabelelor, precum i datele critice transmise prin intermediul reelei, cum ar fi conturile utilizatorilor (ID i parol), sunt vulnerabile i trebuie protejate mpotriva atacatorilor. Criptarea este procesul de codificare a datelor cu ajutorul unui algoritm special, care face imposibil citirea datelor de ctre program fr a dispune de o cheie de decriptare. De

Capitolul 9 Securitatea bazelor de date 237 obicei, criptarea protejeaz datele transmise pe liniile de comunicaie. Exist foarte multe tehnici de criptare a datelor, dintre care unele sunt reversibile, n timp ce altele sunt ireversibile. Tehnicile de criptare ireversibile nu permit cunoaterea datelor originale, dar pot fi folosite pentru a obine informaii statistice. Orice sistem care ofer faciliti de criptare poate s ofere i tehnicile corespunztoare de decriptare, cod ce trebuie protejat folosind mijloace specifice de securitate.

9.2 Politici i proceduri de securitate

Este obligatoriu s se stabileasc setul de politici i proceduri administrative pentru a crea un context pentru implementarea efectiv a msurilor de securitate. Exist dou tipuri de politici i proceduri de securitate: controlul personalului i controlul accesului fizic.

9.2.1 Controlul personalului

De obicei, cele mai mari pericole ce pndesc securitatea datelor sunt cele interne, astfel nct trebuie stabilite i urmate o serie de controale ce privesc personalul ce lucreaz cu date. Procedurile de autorizare i autentificare trebuie impuse cu ajutorul altor proceduri care s ajute la procesul de selecie a personalului prin care s se valideze potenialul acestuia n ceea ce privete pregtirea i trsturile de caracter urmrite. Angajaii trebuie pregtii n acele aspecte de securitate relevante postului pe care sunt angajai fiind atenionai i ncurajai s urmeze msurile standard de securitate. Dac un angajat prsete organizaia trebuie stabilite o serie de proceduri prin care s se elimine toate datele referitoare la autorizarea i autentificarea acestuia, precum i transmiterea de notificri ctre ceilali angajai referitoare la aceste modificri.

9.2.2 Controlul accesului fizic

Un control al accesului fizic important se refer la limitarea accesului la anumite zone din cadrul cldirii. n acest scop se poate folosi un card de proximitate a accesului pentru a obine accesul n acele zone. n acest caz, fiecare acces poate fi nregistrat ntr-o baz de date. Dac este nevoie, vizitatorii trebuie s primeasc ecusoane i trebuie escortai n interiorul acestor zone. Echipamentele sensibile pot fi amplasate n zone de securitate. Celelelte echipamente pot fi nchise n birouri sau pot avea alarme ataate. Mediile pe care se fac copii de siguran trebuie pstrate n zone ferite de foc sau n alte locaii din afar. Procedurile trebuie s stabileasc explicit un plan de transfer al datelor pe alte suporturi media, etichetndu-se i indexndu-se. n ultimul timp, tot mai multe organizaii au tendina s-i desfoare activitatea pe medii mobile pentru a rspunde mai bine cerinelor pieii. Laptop-urile sunt astfel de medii mobile, fiind mai sensibile la atacuri, ceea ce face ca datele pstrate pe aceste dispozitive s fie supuse riscurilor de mai mare amploare. Criptarea i autentificrile multiple pot ajuta la protectia acestor date. Dispozitivele antifurt, cum ar fi cablurile de securitate sau cipurile de urmrire geografic, pot identifica pericolul i recupera rapid laptop-urile pe care se pstreaz date critice.

Baze de date - Fundamente

238

9.3 Rezumat
Acest capitol acoper aspecte generale legate de securitatea bazelor de date. Capitolul ncepe prin descrierea necesitii protejrii datelor i a mediului n care se afl, precum i pericolele ce pot afecta datele existente n bazele de date, dar i ntreaga organizaie. Prima msur de securitate se refer la controlul accesului, care poate fi discreionar sau obligatoriu. Au fost prezentate diverse situaii de control al accesului ce pot fi implementate n DB2, cum ar fi folosirea mecanismelor de autentificare i autorizare, a privilegiilor i a rolurilor, a controlului accesului bazat pe etichete, dar i a folosirii contextelor de ncredere. O modalitate simpl i flexibil de a ascunde pri mari dintr-o baz de date o constituie utilizarea vederilor. Scopul controlului de integritate este acela de a proteja datele de accesul neautorizat, prin restricionarea valorilor ce pot fi atribuite precum i a operaiilor ce pot fi efectuate pe o baz de date. Din aceste motive, se definesc domenii, aseriuni i declanatori. Datele cu caracter critic transmise prin intermediul reelei, precum i datele cu caracter personal trebuie protejate folosind tehnica criptrii. Msurile prezentate n cadrul acestui capitol s-ar putea s nu stopeze toate atacurile accidentale sau ru intenionate, sau modificarea datelor. Din acest motiv, este necesar s se stabileasc o serie de politici i proceduri cu caracter administrativ pentru a crea un context eficient de implementare a acestor msuri. Cele mai utilizate politici i proceduri de securitate folosite se refer la controlul personalului i la controlul fizic al accesului.

9.4 Exerciii
Citii capitolul 10, "Securitatea bazelor de date" din cartea gratuit n format electronic Getting started with DB2 Express-C i creai doi utilizatori n cadrul sistemului de operare. Pot cei doi utilizatori crea o baz de date? De ce? Pot cei doi utilizatori s se conecteze la o baz de date? De ce? Pot cei doi utilizatori s foloseasc vederea SYSCAT.TABLES? De ce?

9.5 ntrebri recapitulative

1. De ce este necesar s se protejeze datele din cadrul unei baze de date? 2. Este suficient s se protejeze doar datele din cadrul bazei de date? 3. Care sunt cteva dintre pericolele ce trebuie luate n considerare atunci cnd se elaboreaz un plan complet de securitate? 4. Care este definiia controlului discreionar al accesului? 5. Care sunt formele de autorizare n DB2?

Capitolul 9 Securitatea bazelor de date 239 6. Ce sunt privilegiile? 7. Cum se folosesc contextele de siguran n DB2? 8. Ce este o vedere i de ce este considerat o component important a mecanismului de securitate? 9. Cum poate fi asigurat controlul integritii? 10. Care sunt cele mai folosite poliitci i proceduri de securitate?

10
Capitolul 10 Tendine n tehnologie i n bazele de date
Un sondaj efectuat de ctre IBM n anul 2010 scoate la vedere o serie de tendine noi n tehnologie ce pot fi evideniate pn n anul 2015. Sondajul folosete rspunsurile a mai mult de 2,000 profesioniti n domeniul IT din ntreaga lume ce au expertiz n domenii cum ar fi testarea software, administrarea reelei i a sistemelor, arhitectura software, precum i elaborarea de aplicaii Web sau de tip organizaie. Dou aspecte principale se desprind n urma acestui sondaj: Cloud computing va prelua conducerea n domeniul achiziionrii de resurse IT de ctre organizaii. Elaborarea de aplicaii pentru dispozitivele mobile cum ar fi iPhone i Android, i chiar a tabletelor, cum ar fi iPad i PlayBook, va fi superioar elaborrii de aplicaii pentru alte platforme. Acest capitol se va referi la Cloud computing, la elaborarea de aplicaii mobile, precum i la alte tendine existente n tehnologie, explicnd rolul bazelor de date n cadrul acestora. Suplimentar, capitolul mai prezint i un scenariu real n care se folosesc astfel de tehnologii. Dup parcurgerea acestui capitol ar trebui s avei o nelegere mai bun referitor la aceste tehnologii, pentru a beneficia de avantajul folosirii lor n soluiile adoptate n viitor.

10.1 Ce este Cloud computing?

Cloud computing nu este o tehnologie nou, ci un model nou de furnizare a resurselor IT. Acesta ofer iluzia faptului c persoanele pot avea acces la un numr infinit de resurse de calcul disponibile la cerere. Prin folosirea Cloud computing, se poate nchiria putere de calcul fr a avea nici un angajament. Nu este nevoie s cumperi un server, doar plteti ce foloseti. Acest nou model este comparat, de multe ori, cu felul n care oamenii procedeaz cu plata utilitilor. De exemplu, se pltete doar apa sau electricitatea consumate pe o anumit perioad de timp. Cloud computing a modificat drastic modalitatea de obinere a resurselor de calcul, permind aproape oricui, de la companii ale persoanelor fizice, pn la companii guvernamentale s lucreze la proiecte ce nu puteau fi altfel abordate anterior.

Baze de date - Fundamente

242

Tabelul 10.1 compar modelul IT tradiional al unei ntreprinderi cu modelul Cloud computing. Modelul IT tradiional Este necesar bugetarea Investiii mari n avans Se planific ncrcarea maxim 120 zile necesare pentru pornirea unui proiect Modelul Cloud computing Parte a cheltuielilor de operare ncepe de la 2 ceni / or Scalabil la cerere Mai puin de 2 ore pentru a avea un sistem funcional.

Tabelul 10.1 Compararea modelului tradiional IT cu modelul Cloud computing. n timp ce n modelul tradiional IT este nevoie de obinerea unui buget pentru achiziionarea de suport hardware, fiind necesar investirea unei mari sume de bani, n modelul Cloud computing cheltuielile sunt considerate cheltuieli de operare necesare desfurrii activitii; se pltete la cerere o sum mic pe or pentru aceleai resurse. n modelul IT tradiional, cererea bugetului, achiziionarea de hardware i software, instalarea acestora n cadrul unui laborator sau centru de date, precum i operaia de configurare necesit un mare consum de timp. n medie se poate spune c un proiect poate dura 120 de zile sau mai mult pentru a putea ncepe. Folosind modelul Cloud computing, se poate obine un sistem configurat i gata de lucru n mai puin de 2 ore! Companiile care se bazeaz pe modelul IT tradiional trebuie s planifice ncrcarea maxim. De exemplu, ncrcarea medie a unei companii este de 3 servere pentru 25 de zile ale unei luni, dar mai are nevoie de alte 2 servere pentru ultimele 5 zile ale lunii, motiv pentru care compania trebuie s achiziioneze 5 servere, nu 3. Folosind modelul Cloud computing aceeai companie poate investi doar n 3 servere i nchiria 2 servere pentru ultimele 5 zile ale lunii.

10.1.1 Caracteristicile unui Cloud

Cloud Computing se bazeaz pe trei caracteristici simple: Standardizarea. Standardizarea ofer posibilitatea de obinere a unui set important de resurse IT omogene pe baza unor componente oarecare. Standardizarea este opus personalizrii. Virtualizarea Virtualizarea ofer o metod de partiionare a unui grup mare de resurse IT i alocarea lor la cerere. Dup utilizare, resursele pot fi returnate grupului pentru fi folosite de ctre alii. Automatizarea

Capitolul 10 Tendine n tehnologie i n bazele de date 243 Automatizarea permite utilizatorilor unui Cloud s obin controlul asupra resurselor folosite fr a fi nevoie de intervenia administratorului care s gestioneze cererile. Acest lucru este foarte important ntr-un mediu Cloud de mari dimensiuni. Dac v gndii bine, probabil c ai folosit anterior o serie de servicii Cloud. Facebook, Yahoo, i Gmail, de exemplu, furnizeaz servicii standardizate, virtuale i automate. Pentru utilizarea acestor servicii trebuie create conturi.

10.1.2 Modele de servicii Cloud computing

Exist trei modele de servicii Cloud computing: Infrastructur sub form de servicii (IaaS) Platform sub form de servicii (PaaS) Software sub form de servicii (SaaS) Furnizorii de servicii de tip infrastructur pun la dispoziie infrastructura de care este nevoie la un moment dat (centru de date, hardware, sistem de operare) astfel nct nu mai trebuie s mai fim preocupai de astfel de aspecte. Furnizorii de servicii de tip platform pun la dispoziie infrastrctura de care este nevoie pentru o aplicaie sau pentru aplicaiile de tip middleware. De exemplu, n cazul produselor middleware de la IBM, PaaS ofer serverul DB2, serverul de aplicaii WebSphere application server, .a.m.d. Furnizorii de servicii de tip software pun la dispoziie aplicaia necesar n cadrul activitii. Ne putem gndi la aceti furnizori ca la nite depozite de aplicaii din care se pot nchiria aplicaiile dorite cu ora. Un exemplu tipic de SaaS este Salesforce.com.

10.1.3 Furnizorii de servicii Cloud

Astzi, exist pe pia o serie de furnizori de servicii de tip Cloud computing, cum ar fi IBM cu oferta "Smart Business Development and Test on the IBM Cloud", Amazon cu oferta Amazon Web Services (AWS), Rackspace, .a.m.d. 10.1.3.1 IBM Smart Business Development and Test on the IBM Cloud IBM Smart Business Development and Test on the IBM Cloud, sau IBM developer cloud, ofer servicii create special pentru dezvoltare i testare. Acest Cloud i are centrele de date situate n Statele Unite i Europa i pemite folosirea de instane bazate pe Intel pe 32 i 64 de bii folosind sistemele de operare RedHat sau SUSE Linux, sau Microsoft Windows. O instan este de fapt un server virtual. IBM Developer Cloud poate fi accesat la adresa https://www-147.ibm.com/cloud/enterprise Figura 10.1 prezint ecranul IBM Developer Cloud. Se prezint trei instane diferite care ruleaz, sistemul de operare folosit i adresa IP.

Baze de date - Fundamente

244

Figura 10.1 - Ecranul IBM Developer Cloud ncrcarea i rularea unui sistem se face n doar cteva minute prin apsarea butonului "Add instances". Apoi se alege din multitudinea de instae disponibile cea de care este nevoie, aa cum se vede n Figura 10.2.

Figura 10.2 Alegerea instanei care se folosete n IBM Developer Cloud

Capitolul 10 Tendine n tehnologie i n bazele de date 245 De exemplu, dac se dorete s se lucreze cu IBM DB2 Express-C 9.7.1 - PAYG (Pay as you go plteti n funcie de ct foloseti) pe sistemul de operare SUSE Linux, se alege pur i simplu opiunea respectiv. Dup selectare, se apas Next, i se va ajunge la ecranul din Figura 10.3 n acest ecran se poate alege tipul de instan dorit (pe 32 de bii, sau pe 64 de bii) precum i numrul de procesoare necesare n funcie de categorie (cupru, bronz, argint, aur). De exemplu, cupru pe 32 de bii ofer, de obicei, 1 CPU cu frecvena de 1.25GHz, 2GB de memorie i 175GB spaiu pe disc. Figura 10.3 prezint ceea ce este necesar s se introduc pentru a crea o cheie de care este nevoie pentru descrcarea pe calculatorul personal astfel nct ulterior, prin intermediul SSH s se obin accesul la instana creat, asemntor folosirii putty.

Figura 10.3 Configurarea instanei Dup ce se apas Next, instana va fi disponibil, ceea ce nseamn faptul c sunt alocate procesoarele i memoria, este instalat sistemul de operare, iar software-ul din imagine (serverul de baze de date DB2 Express-C n acest exemplu) este i acesta instalat. Procesul poate dura cteva minute. Ulterior, se poate aduga spaiu suplimentar de stocare pe disc. 10.1.3.2 Amazon Web Services Amazon Web Services, sau AWS, este liderul de pia la furnizarea de infrastructuri de tip cloud public. AWS are centre de date situate in patru regiuni: US-East, US-West, Europa i

Baze de date - Fundamente

246

Asia Pacific. Fiecare regiune are mai multe zone de disponibilitate pentru mbuntirea activitii. Asemntor IBM developer cloud, prin folosirea AWS se pot alege servere virtuale numite Elastic Cloud compute (EC2) instances. Aceste instane se bazeaz pe Intel (32 i 64bii) i pot rula sistemele de operare Windows sau Linux (diverse distribuii). Se alege din tipurile predefinite de instane n funcie de cerinele de processor, memorie i stocare local. Figura 10.4 prezint diverse tipuri de instane AWS EC2. Fiecare tip are un pre diferit pe or aa cum se arat n documentaia de la aws.amazon.com.

Figura 10.4 Tipuri de instane AWS EC2 De asemenea se poate aduga spaiu suplimentar de stocare pentru instan. AWS ofer trei variante: Stocare pe instan: Aceast variant este inclus n instana aleas fr costuri suplimentare; totui, datele nu sunt persistente, ceea ce nseamn faptul c acestea vor dispare dac instana se distruge sau se ncheie. Simple Storage Service (S3). S3 se comport asemntor unui mediu de stocare bazat pe fiiere i organizat pe foldere. Se poate interaciona cu acesta folosind cereri http de tip put sau get. Elastic Block Storage (EBS). Volumele EBS pot fi tratate asemntor discurilor din cadul unui sistem de calcul. Acesta permite stocarea persistent, fiind ideal pentru lucrul cu baze de date.

Capitolul 10 Tendine n tehnologie i n bazele de date 247

10.1.4 Gestionarea securitii pe Cloud

Securitatea este motivul principal pentru care companiile evit s foloseasc un cloud public. Faptul c datele confideniale ale companiei sunt pstrate la un ter este vzut de ctre companii ca riscuri de securitate i de pstrare a caracterului privat al datelor. Dei aceste temeri sunt ndreptite, totui tehnologia Cloud computing evolueaz n continuu. Norii de calcul privai (private cloud) ofer o modalitate de reasigurare a utilizatorului c datele sale sunt pstrate n siguran. Produsele software, de tipul IBM Cloudburst i IBM WebSphere Cloudburst Appliance lucreaz mpreun pentru a permite companiilor s-i dezvolte propriile sisteme de tip cloud. Companii precum Amazon i IBM ofer servicii de creeare a norilor de calcul privai virtuali (VPC) n care serverele continu s se afle n centrele de date ale furnizorilor, nefiind accesibile pe Internet; securitatea poate fi gestionat complet prin intermediul infrastructurii de securitate i de procesele proprii companiei. Companiile pot folosi i nori de calcul hibrizi pstrnd datele critice n norii de calcul privai, n timp ce datele folosite pentru dezvoltare i testare se pstreaz pe norii de calcul publici.

10.1.5 Baze de date i Cloud Computing

Cloud Computing este o metod nou de furnizare a resurselor IT, inclusiv a bazelor de date. Serverul de date IBM DB2 este pregtit pentru a lucra pe Cloud, att din punct de vedere al licenierii ct i al caracteristicilor. Pe AWS sunt disponibile diverse ediii de DB2 pentru producie, dezvoltare i testare folosind imagini IBM developer cloud. Imaginile DB2 sunt disponibile i pentru norii de calcul privai folosind VMware sau maina WebSphere Cloudburst. Figura 10.5 prezint imaginile DB2 disponibile pe nori privai, publici i hibrizi.

Figura 10.5 Imagini DB2 disponibile pe nori privai, hibrizi i publici

Baze de date - Fundamente Pentru liceniere se pot folosi metodele:

248

Bring your own license (BYOL) permite utilizarea licenelor DB2 existente n cloud. Pay as you go (PAYG) permite plata doar a ceea ce se folosete ntotdeauna se poate folosi DB2 Express-C n Cloud fr s se plteasc, dar s-ar putea s se cear s se plteasc pentru infrastructura folosit. n ceea ce privete caracteristicile DB2 care prezint avantaje particulare n mediul Cloud amintim: Database Partitioning Feature (DPF) caracteristica de partiionare a bazelor de date High Availability Disaster Recovery (HADR) disponibilitate ridicat la refacerea datelor dup dezastre Comprimare DPF se bazeaz pe arhitectura de lucru individual care se potrivete foarte bine n modelul Cloud. DPF este ideal pentru depozite mari de date n care trebuie regsite date pentru efectuarea de rapoarte. Folosind DPF, interogrile sunt n mod automat paralelizate pe un grup de servere, acest lucru fiind transparent pentru utilizator. Se pot aduga servere din cadrul Cloud-ului la cerere care au propriile procesoare, memorii i spaii de stocare. DB2 va rebalansa apoi automat datele, performanele obinute fiind mbuntite aporape liniar. HADR este o caracteristic robust a DB2 avnd mai mult de 10 ani de existen. HADR folosete dou servere, unul primar i altul n ateptare. Atunci cnd ambele servere se afl n aceeai locaie, aceast caracteristic ofer o disponibilitate ridicat. Atunci cnd unul dintre servere este plasat ntr-o locaie, iar cellalt se afl ntr-o alt locaie (de obicei ntr-un alt jude sau ar), HADR ofer caracteristica de refacere dup dezastre. Disaster Recovery (DR refacerea dup dezastre) reprezint unul dintre cele mai importante i costisitoare domenii din IT. Este costisitor deoarece companiile trebuie s plteasc pentru spaiul ocupat n alte locaii, dar i pentru resursele IT (servere, medii de stocare, reea) necesare. Cloud Computing rspunde foarte bine la aceste cerine. Se poate nchiria un spaiu n cadrul unui Cloud dintr-un centru de date distribuit, fr a se plti pentru spaiul ocupat, electricitatea consumat, rcirea necesar, securitate .a.m.d. n acelai timp, se pot obine toate resursele IT necesare fr a avea un buget destinat special acestui lucru. Accesarea site-ului DR de pe Cloud poate fi realizat din orice locaie n mod sigur, doar prin folosirea unui browser si a ssh. Avnd HADR se poate plasa serverul primar dup cum este nevoie, iar cellalt server pe Cloud. Pentru a avea o securitate mai bun, cel de-al doilea server se poate pstra pe un cloud privat virtual. HADR permite sistemului s-i reia activitatea n mai puin de 15 secunde de la cderea serverului primar. Se mai poate folosi i caracteristica de comprimare a DB2 pe Cloud pentru economisire de spaiu. Comprimarea realizat de DB2 depinde de gradul de ncrcare, astfel nct pot fi mbuntite performanele generale ale sistemului. Mai exist i o serie de alte caracteristici din DB2 care nu au fost prezentate n acest capitol, dar care se preteaz foarte bine unei astfel de abordri.

Capitolul 10 Tendine n tehnologie i n bazele de date 249

10.2 Elaborarea de aplicaii mobile

Aplicaiile mobile sunt produse software care se execut pe dispozitive mobile. Aplicaiile mobile obinuite folosesc tehnologia de calcul mobil pentru a obine informaiile pstrate pe un server n orice loc i moment. n ultimul timp, aplicaiile mobile care folosesc un mediu Cloud devin din ce n ce mai populare. Proiectarea i implementarea aplicaiilor mobile nu este la fel de simpl ca elaborarea aplicaiilor de tip desktop. Este foarte important ca programatorii de aplicaii mobile s aib n vedere contextul n care se folosesc astfel de aplicaii. Din punct de vedere al afacerii, este foarte dificil pentru managerii de proiect s estimeze riscurile unui proiect de aplicaii mobile datorit dificultilor ce apar la compararea diverselor caracteristici de pe platformele mobile existente. Astzi, platformelor consacrate, cum ar fi Symbian, Microsoft Windows Mobile, Linux i BlackBerry OS li s-au alturat Apples OS X iPhone, Android i mai recent Palms Web OS, ceea ce contribuie la creterea complexitii n programare. Figura 10.6 prezint o arhitectur tipic folosit la elaborarea unei aplicaii mobile. Aplicaii mobile Platforma de dezvoltare a aplicaiei mobile Platforma dispozitivului mobil (sistem de operare ncorporat i dispozitiv mobil) Figura 10.6 Elaborarea unei aplicaii mobile: vedere de ansamblu n Figura 10.6, se observ faptul c aplicaiile mobile se afl deasupra a dou straturi: Platforma dispozitivului mobil se refer la dispozitivul mobil i sistemul su de operare i/sau produsul software integrat. De exemplu, sistemul de operare Microsoft Windows Mobile 5.0 este instalat pe un dispozitiv Dell AXIM X51v. Platforma de elaborare a aplicaiei mobile se refer la combinaia de limbaje de programare, API-uri generale de dezvoltare i medii de execuie specifice limbajului pe dispozitivul mobil. Platforma de elaborare a aplicaiilor mobile ruleaz deasupra platformei dispozitivului mobil i ofer un strat suplimentar sub forma unui produs software ca barier de protecie mpotriva produselor software ce au erori sau a celor ru intenionate. De exemplu, mediul obinuit de elaborare a aplicaiilor mobile pentru Windows Mobile 6.0 este Microsoft Visual Studio 2005/2008 i Windows Mobile 6.0 SDK. Deoarece exist diverse tipuri de platforme pentru dispozitivele mobile i platforme pentru elaborarea de aplicaii mobile, alegerea uneia dintre acestea se poate face prin rspunsul la ntrebarea: se produce o aplicaie pentru un anumit dispozitiv, sau o platform de elaborare a aplicaiilor mobile?

Baze de date - Fundamente

250

10.2.1 Elaborarea aplicaiilor pentru un anumit dispozitiv mobil

Atunci cnd se scrie o aplicaie pentru un anumit dispozitiv (sau grup de dispozitive) sau sistem de operare al unui dispozitiv, furnizorul dispozitivului respectiv pune la dispoziie un SDK, un emulator, i alte instrumente ce pot ajuta programatorul s scrie aplicaii specifice acelei platforme. Tabelul 10.2 prezint unele dintre platformele de dispozitive mobile precum i ce anume ofer acestea din punct de vedere al SDK-urilor, instrumentelor .a.m.d.

Sistem de operare (OS) Symbian OS

Limbaj/ opiuni OS C++, Java, Ruby, Python, Perl, OPL, Flash Lite, .NET Java, C++

SDK-uri/instrumente

Site Web pentru programator developer.symbian.com

Carbide C++, IDE(Nokia) C++, i Java SDK, pe dispozitiv

Windows Mobile

Visual Studio, Platform Builder, Embedded Visual C++ (eVC), Free Pascal, i Lazarus Xcode Eclipse, Android SDK, Android Development Tool Plugin, JDK 5 Palm OS SDK, Java development cu IBM Websphere EveryPlace Micro Environment, Palm Windows Mobile SDK pentru produse Palm pe platforme Windows Mobile

Microsoft Windows Embedded Developer Center

iPhone OS Android

Objective-C Java

www.apple.com/iphone www.android.com

Palm OS

C, C++, Java

www.palm.com/us/developer

Tabelul 10.2 Instrumente i platforme pentru dispozitive

10.2.2 Elaborarea aplicaiilor mobile pentru o anumit platform de aplicaii

Fiecare programator are ncredere ntr-un anumit limbaj de programare i un anumit mediu de dezvoltare. De ce se prefer anumite limbaje de programare i medii de dezvoltare?

Capitolul 10 Tendine n tehnologie i n bazele de date 251 Elaborarea aplicaiilor mobile redeschide aceste ntrebri, fiind necesar o re-evaluare a rspunsurilor n lumina elaborrii de aplicai mobile. Java, .NET (C#, VB), C, C++ i alte limbaje de programare sunt toate opiuni valabile n elaborarea de aplicaii mobile. ntr-o anumit privin, aceleai criterii se folosesc i la evaluarea limbajelor de programare folosite pentru aplicaiile de tip desktop Cu toate acestea, elaborarea aplicaiilor mobile aduce n discuie consideraii care modific modul vechi de elaborare a aplicaiilor de tip desktop/server. De exemplu, puterea limbajului de programare Java va fi ntotdeauna portabilitatea sa. Java este o platform disponibil pe scar larg i se poate folosi pe cele mai multe dintre dispozitivele mobile. Totui, Java nu este prezent pe toate aceste dispozitive. Pentru ca Java s corespund diferitelor stiluri i platforme, arhitectura Java a fost descompus ntr-o serie de configuraii i profile. Configuraiile i profilele difer n funcie de dispozitiv i de caracteristicile acestuia. Din acest motiv, s-ar putea ca scrierea pe o anumit platform s nu rspund cerinelor clienilor. Prin urmare cum trebuie cutate platformele software destinate aplicaiilor mobile? Urmtoarele dou seciuni prezint cele mai importante platforme pentru dispozitivele mobile precum i a platformelor de elaborare a aplicaiilor mobile, prezentnd modaliti de compare a acestora.

10.2.3 Platforme pentru dispozitive mobile

n continuare vor fi prezentate unele dintre cele mai folosite platforme pentru dispozitivele mobile. 10.2.3.1 Windows Mobile Windows Mobile, provine din Windows CE (aprut n 1996), i ofer un subgrup de API-uri Microsoft Windows pe un sistem de operare n timp real compact destinat dispozitivelor de calcul mobil i terminalelor wireless. Dup cteva ncercri nereuite pe PDA-uri, Windows Mobile a reuit n sfrit s obin succesul ateptat pe aceste dispozitive i pe handseturi, probabil cele mai notabile fiind pe Motorola Q i pe anumite dispozitive Treo. Microsoft ofer tehnologia ActiveSync pentru sincronizarea utilizatorilor. Versiunea curent de Microsoft Windows Mobile este o platform versatil pentru programatori, care permite elaborarea de aplicaii scrise n limbajele de programare C sau C++ , suportnd n acelai timp i codul folosit n mediul .NET Compact Framework. 10.2.3.2 Symbian OS Symbian OS este un sistem de operare proprietar destinat dispozitivelor mobile care are biblioteci asociate, interfa utilizator, framework-uri i implementri ce fac legtura cu instrumentele uzuale dezvoltate de ctre Symbian Ltd. Symbian a nceput sub denumirea de EPOC Release 5. Symbian este o platform foarte puternic care folosete limbajul C++ n cadrul unui framework pus la dispoziie de ctre Symbian pentru elaborarea de aplicaii i servicii. Platforma Symbian ruleaz Java ME, astfel c telefoanele Symbian pot rula att aplicaiile Symbian native ct i aplicaiile Java ME.

Baze de date - Fundamente 10.2.3.3 iPhone

252

iPhone este proiectat i vndut de ctre Apple Inc. Este o platform nchis, care permite folosirea aplicaiilor mobile doar sub un browser Web Safari. Deoarece interfaa minimal hardware nu are tastatur fizic, ecranul multi-touch prezint la nevoie o tastaur virtual. iPhone i iPod Touch SDK folosesc limbajul Objective C, bazat pe C. Mediul de dezvoltare integrat folosit la elaborarea aplicaiilor iPhone se numete Xcode, i este alctuit dintr-o suit de instrumente de programare pentru elaborarea de software pe Mac OS X de la Apple. 10.2.3.4 Android Android este un produs software deschis i gratuit destinat dispozitivelor mobile care conine sistem de operare, middleware, i alte aplicaii cheie. Limbajul de programare pentru Android este Java. Programarea aplicaiilor Android se face exclusiv n Java. Pentru aceasta este nevoie de un anumit SDK Java pentru Android care conine un set de instrumente de dezvoltare. Printre acestea putem enumera un depanator, biblioteci, emulator handset (bazat pe QEMU), documentaie, exemple de cod i tutoriale. Platformele de dezvoltare suportate n prezent conin arhitecturi de calcul bazate pe x86 ce ruleaz Linux (orice distribuie recent de Linux pentru desktop), Mac OS X 10.4.8 sau mai nou, Windows XP sau Vista. Mai sunt necesare Java Development Kit, Apache Ant i Python 2.2 sau mai nou. Mediul integrat de dezvoltare suportat n mod oficial este Eclipse (3.2 sau mai nou) ce folosete Plug-in-ul Android Development Tools (ADT), prin care programatorii pot folosi orice editor de texte pentru editatea fiierelor Java i XML dup care apeleaz un instrument n linie de comand pentru crearea, compilarea i depanarea aplicaiilor Android.

10.2.4 Platforme de dezvoltare a aplicaiilor mobile

n aceast seciune se vor prezenta platformele de elaborare a aplicaiilor folosite la implementarea acestora pe dispozitivele mobile. 10.2.4.1 Java Micro Edition (Java ME) Java ME, numit anterior Java 2 Micro Edition (J2ME), este o platform ce mpac dispozitivele mobile uoare cu alte dispozitive de calcul netradiionale, cum ar fi dispozitivele media. Lozinca promis odat programatorilor care spunea scrie odat, ruelaz oriunde continu s se aplice i pentru Java ME, aplicaiile fiind disponibile pe diverse dispozitive, deoarece limbaje cum ar fi C sau C++ pe alte platforme necesit cunotine solide despre API-urile specifice acesteia, cum sunt cele de la Windows Mobile sau Symbian OS. De fapt, exist numeroase implementri Java pentru diverse dispozitive suportate pe Java ME. 10.2.4.2 .NET Compact Framework Aceast platform este o versiune a.NET Framework folosit pe platformele Windows CE. Aceasta este un subset standard .NET framework, dar conine i alte cteva clase

Capitolul 10 Tendine n tehnologie i n bazele de date 253 suplimentare ce rspund cerinelor specifice dispozitivelor mobile. Actualmente, sunt disponibile .NET Compact Framework V1.0, V2.0 i V3.5. Ce versiune de .NET Compact Framework trebuie aleas? "Ultima" poate fi rspunsul normal, dar, ca multe alte aspecte ce privesc dispozitivele mobile, nu este chiar aa simplu! Ca programator de aplicaii mobile, trebuie s alegei versiunea de .NET Compact Framework pe care s v dezvoltai aplicaia. Dac se alege versiunea 1.0, putei fi sigur c aplicaia va rula pe toate dispozitivele, deoarece versiunile ncepnd cu 2.0 ruleaz aplicaii care au fost create s ruleze pe versiuni anterioare. Totui, dac se scrie cod ce utilizeaz caracteristici valabile doar n versiunea .NET Compact Framework 2.0, trebuie ca mediul de execuie corespunztor s fie instalat pe dispozitivul pe care se va folosi aplicaia. 10.2.4.3 Native C++ Aplicaiile C++ pot rula nativ pe dispozitiv, fcnd n acest fel ca acestea s fie mai puin portabile, dar aceasta nseamn, de obicei, o vitez sporit precum i un control mai bun asupra dispozitivului. De obicei, programele C++ native au nevoie de instrumente cum ar fi Microsoft Visual C++ 6/.NET, Eclipse IDE alturi de C++ SDK, sau Borland C++ Builder. n mod deosebit, pentru Symbian OS, se poate alege i Metrowerks CodeWarrior Studio care cere la rndul su un SDK, Symbian C++ SDK de la Nokia. 10.2.4.4 Mediu binar de execuie pentru Wireless Binary Runtime Environment for Wireless (BREW - mediul binar de execuie pentru Wireless) este o platform de programare dezvoltat de ctre Qualcomm pentru telefoanele bazate pe CDMA. BREW ofer SDK i emulator pentru elaborarea i testarea aplicaiilor scrise n C sau C++. Pentru a lucra cu BREW, este nevoie de instrumente de programare cum ar fi BREW SDK, instrumente de compilare ARM RealView, Visual C++ etc.

10.2.5 Valul urmtor de aplicaii mobile

Un spectru larg de aplicaii mobile i servicii din generaia urmtoare a ieit la suprafa n ultimul timp. Noile aplicaii mobile au n spate furnizorii de servicii de telefonie care caut aplicaii i servicii pentru sistemele 3G i alte infrastructuri de date wireless. Aplicaiile mobile tradiionale, cum sunt cele de voce sau serviciile simple de date care ofer navigare pe Internet nu mai sunt suficiente astzi; consumatorii cautnd s beneficieze din plin de avantajele mobilitii la putere redus, de folosirea de dispozitive wireless mobile pentru distracie, accesarea de informaie de oriunde, dar i efectuarea de operaii flexibile n domeniul afacerilor. Multe piee mari sunt astzi inundate de dispozitivele mobile, cum ar fi sistemele telematice, servicii m-commerce i m-enterprise, servicii de streaming multimedia pe dispozitive mobile, mesageria mobil, localizarea bazat pe calcul mobil, .a.m.d. Cu siguran, n urmtorii civa ani, vom fi martorii multor descoperiri interesante i inovaii tehnologice n domeniul calcului mobil.

Baze de date - Fundamente

254

10.2.6 DB2 Everyplace

Ediia pentru servicii mobile a DB2 se numete DB2 Everyplace. Caracteristicile DB2 Everyplace, o baz de date relaional de mici dimensiuni i de performan ridicat, permit folosirea aplicaiilor de tip organizaie, dar i a datelor, ntr-un mediu sigur, pe dispozitive mobile. Obs: Pentru a afla mai multe despre elaborarea aplicaiilor mobile, vedei cartea n format electronic, Getting started with mobile application development, ce face parte din seria de cri a programului DB2 on Campus.

10.3 Prelucrarea datelor cu caracter economic

Bazele de date se folosesc de obicei pentru a efectua tranzacii online, cum ar fi tranzaciile bancare, dar mai pot fi folosite i n scopul prelucrrii datelor cu caracter economic pentru a observa tendinele i modelele ce ajut la luarea deciziilor corecte. Astzi, companiile culeg zilnic cantiti uriae de date, care sunt pstrate n depozite de date de mari dimensiuni n scopul crerii de rapoarte cu ajutorul unor aplicaii cum ar fi IBM Cognos . Companiile care lupt din greu pentru ntreinerea depozitelor de date de mari dimensiuni sunt din ce n ce mai atrase de ideea achiziiei de maini care s lucreze cu asttfel de depozite. O astfel de main este alctuit din componente hardware i software care sunt integrate i testate pentru a dezvolta anumite funcionaliti. IBM Smart Analytics System este una dintre aceste maini folosite la lucrul cu depozite mari de date cu caracter economic. Obs: Pentru a afla mai multe amnunte despre depozitele mari de date i datele cu caracter economic, vedei cartea n format electronic, Getting started with data warehousing, ce face parte din seria de cri a programului DB2 on Campus.

10.4 db2university.com: Implementarea unei aplicaii n Cloud (studiu de caz)

Progresele obinute n tehnologie permit progrese n alte domenii. Datorit Internetului, multe universiti ofer diplome online. Se acord creditele corespunztoare studenilor care se nregistreaz i particip la cursurile online. Aceste cursuri constau deseori din seminarii nregistrate, sesiuni live, forumuri i altele. Pundits spune c n viitorul apropiat oricine are acces la Internet va putea s primeasc o educaie excelent fr a fi nevoie s urmeze fizic o universitate. Educaia online d posibilitatea nvrii n ritmul propriu, dispunnd n acelai timp de confortul de acas. Datorit dispozitivelor mobile se pot apela resurse educaionale chiar i pe perioada deplasrilor.

Capitolul 10 Tendine n tehnologie i n bazele de date 255 n aceast seciune se va prezenta db2university.com, un site Web educaional care a fost implementat folosind multe dintre tehnologiile descrise n acest capitol. Figura 10.7 prezint aspectul acestui site la momentul scrierii crii.

Figura 10.7 Pagina de pornire a site-ului db2university.com

10.4.1 Moodle - sistem open source de management al cursurilor

O serie de materiale, de la materialele video la prezentri media distribuite prin intermediul Internetului, dar i cri n format electronic, sunt disponibile permanent pe Internet pentru studiu individual, dar de cele mai multe ori, acestea nu sunt organizate ntr-o modalitate care s permit utilizarea lor cu uurin. Pe de alt parte, o serie dintre informaiile obinute pe aceast cale s-ar putea s nu mai fie de actualitate. Sistemele de management al cursurilor permit instructorilor s creeze i s aranjeze materialele existente fiind astfel mai uor de urmrit. La db2university.com se folosete sistemul open source de management al cursurilor, numit Moodle. Moodle, scris n PHP, este unul dintre cele mai bune, dac nu cel mai bun sistem de acest tip de pe pia. Martin Dougiamas de la Curtin University of Technology din Perth, Australia a elaborat prima versiune a sistemului n anul 2001. Astzi, sunt peste 52,000 de site-uri Moodle nregistrate i peste 950,000 de utilizatori nregtistrai la moodle.org din peste 175 de ri din ntreaga lume. Contactul cu Moodle a nceput la sfritul anului 2009. Studenii de la California State University, Long Beach (CSULB) au fost desemnai, ca parte a unuia dintre cursurile pe care le aveau, s fac ca versiunea Moodle 1.9.6 s lucreze mpreun cu DB2 Express-C. Contribuia acestora pentru comunitate poate fi vzut la adresa http://moodle.org/mod/data/view.php?d=13&rid=3100&filter=1. La nceputul lui 2010 am fcut ca versiunea Moodle 2.0 s foloseasc DB2 Express-C.

Baze de date - Fundamente

256

Moodle 2.0 reprezint o revizuire major a aplicaiei Moodle, prezentnd modificri fundamentale fa de versiunile precedente prin felul n care realizeaz conexiunile cu bazele de date. La momentul scrierii acestei cri, este disponibil pentru public versiunea Moodle 2.0 Release Candidate 1. Aceasta este versiunea pe care am fcut-o s se conecteze cu DB2 Express-C, i cea care ruleaz pentru db2university.com. La momentul n care versiunea Moodle 2.0 va fi disponibil, se va actualiza site-ul db2university.com i vom marca aceast contribuie pentru comunitatea Moodle. Figura 10.8 prezint o serie de cursuri disponibile la db2university.com. La aceast pagin se poate ajunge prin alegerea filei Learn aflat pe pagina de pornire. Fila Learn prezint implementarea de Moodle aleas. S-a creat o tem Moodle specific pentru db2university.

Figura 10.8 Fila Learn conduce ctre implementarea Moodle n db2university Cursurile de la db2university.com nu sunt doar despre DB2. Se pot urmri i alte subiecte, cum ar fi cele despre PHP sau Ruby on Rails, dar fiecare lecie din cadrul cursurilor respective care are nevoie de o interaciune cu o baz de date, folosete DB2. Instructorii cursurilor sunt membrii ai comunitii DB2 care include cadre didactice universitare, specialiti, angajai IBM i studeni. Exist dou categorii de cursuri la acest site: Free courses i Paid courses. Pentru Paid courses se folosete plug-in-ul Paypal inclus n Moodle. Figura 10.9 i 10.10 ofer mai multe detalii despre cursul "DB2 Essential Training I". Am luat acest curs drept exemplu a ceea ce se poate face n aceast implementare de Moodle. Se observ faptul c acest curs are multe prezentri video, texte (fiiere PDF), i link-uri ctre cartea folosit ca referin. Nu se prezint n figur link-urile ctre forumul cursului, paginile Web, evaluri i examene.

Capitolul 10 Tendine n tehnologie i n bazele de date 257

Figura 10.9 Coninuturile cursului DB2 Essential Training I

Figura 10.10 - Coninuturile cursului DB2 Essential Training I (continuare)

Baze de date - Fundamente

258

La adresa IBM developerWorks este disponibil un tutorial care v nva cum s creai un curs n db2university.com. Obs: Pentru a afla mai multe despre ce este nevoie pentru a elabora produse software de tip open source, vedei cartea n format electronic Getting started with open source development, ce face parte din seria de cri sin cadrul programului DB2 on Campus.

10.4.2 Activarea contului de nregistrare openID

Cercetrile arat faptul c persoanele care ajung pe o pagin Web care are o procedur complicat sau lung de nregistrare au tendina de a renuna rapid la acel site. Pentru a ncuraja utilizatorii s se nregistreze la db2university.com am activat contul de nregistrare openID. Aceasta nseamn faptul c persoanele care au deja un cont pe Facebook, Google, Yahoo, AOL, ChannelDB2 i altele, nu trebuie s introduc informaii de nregistrare. db2university va cere n schimb celorlali furnizori - cu consimmntul dumneavoastr - s foloseasc informaiile existente acolo. Figura 10.11 prezint acest proces.

Figure 10.11 Procesul de nregistrare folosind openID Mai nti se apas pe link-ul Sign in with OpenID. Va apare o fereastr ce prezint furnizorii de informaii pentru contul openID. Se va alege unul dintre aceti furnizori. n exemplul de mai sus, s-a ales ChannelDB2. n sfrit, se va introduce contul corespunztor pentru ChannelDB2. Prima dat cnd se parcurge acest proces va apare o pagin de la furnizorul de informaii prin care se cere acceptul de trimitere a acestora. Dac se accept, informaia se transmite, fiind automat nregistrat la db2university!. De fiecare dat cnd se

Capitolul 10 Tendine n tehnologie i n bazele de date 259 dorete accesul la db2university.com se vor urma aceeai pai. La adresa IBM developerWorks se gsete un articol care explic felul n care se realizeaz activarea cu ajutorul contului openID.

10.4.3 Folosirea Amazon Cloud

db2university.com este gzduit de ctre cloud-ul de la Amazon. Aceasta permite preluarea tuturor avantajelor oferite prin intermediul Cloud computing, inclusiv setarea caracteristicii HADR din DB2 pentru refacerea n caz de dezastre n Cloud. Pentru cloud-ul AWS folosim: O instan mare EC2 standard (64-bit, 4 ECUs, 7.5 GB de memorie, 850GB capacitate de stocare pe instan) Volume EBS de 50 GB Grupuri S3 cu dimensiuni ntre 3 i 1 GB CloudFront Pentru regiunea US-East au fost prevzute trei instane EC2. Una dintre acestea, se folosete pentru a rula aplicaia Moodle application i serverul Web, iar cealalt pentru a rula serverul de baze de date DB2 (serverul primar DB2 HADR). Serverul secundar DB2 folosete cea de-a treia instan EC2 ntr-o alt zon de disponibilitate din regiunea USEast ca site de refacere n caz de dezastre. n ceea ce privete stocarea, folosim stocare pe instan, volumele S3 i EBS. Figura 10.12 prezint detaliile.

Figura 10.12 Stocarea DB2 pe cloud-ul Amazon n figur: Volumele EBS se folosesc pentru stocarea datelor DB2 i a jurnalelor de refacere

Baze de date - Fundamente

260

DB2. Am ales 50GB pentru aceasta. Opional, lum n considerare folosirea RAID. Un volum EBS diferit, mai mic, de 2GB se folosete pentru pstrarea codului i a fiierelor de configurare DB2. Spaiul de stocare al instanei se folosete pentru a stoca temporar copii de siguran ale DB2. Ulterior vom muta aceste copii pe S3 pentru a crete perioada de pstrare a acestora. Mediul de stocare S3 se folosete pentru pstrarea copiilor de siguran i a arhivelor jurnalelor pentru o perioad de timp mai lung. Imaginile volumului ESB se fac repetat i se pstreaz pe S3. AWS CloudFront se folosete pentru a permite utilizatorilor s descarce materiale pentru cursuri de la un server Amazon care este mai apropiat locaiei la care se afl utilizatorul. Fiierele care se descarc sunt mai nti copiate pe un grup S3, fiind apoi replicate pe aceste servere. Din punct de vedere software se folosesc: Ubuntu Linux 10.04.1 LTS DB2 Express 9.7.2 for Linux 64-bit Moodle 2.0 Release Candidate 1 PHP 5.3.3 Se folosete DB2 Express i nu DB2 Express-C, deoarece se folosete caracteristica DB2 HADR, care este disponibil doar pe ediia DB2 Express. RightScale este ideal pentru managementul resurselor AWS. RightScale este partener IBM, iar produsele sale software permit crearea rapid de medii prin folosirea abloanelor i a scripturilor. Un articol aflat la adresa IBM developerWorks explic detaliie AWS folosite la db2university.

10.4.4 Utilizarea unui telefon Android pentru a obine notele de la curs

Moodle permite studenilor s-i vad notele de la evaluri i examene pe Web; suplimentar, a fost elaborat o aplicaie pentru telefoanele Android folosind App Inventor. Aceast aplicaie simpl este prezentat n Figura 10.13. Mai nti trebuie introdus un cod de acces pentru mobil care este un cuvnt cheie unic pentru fiecare student ce poate fi obinut pe baza profilului studentului din Moodle. Apoi, se poate alege cursul respectiv pentru care se afieaz notele. Pentru ca aceast aplicaie s funcioneze, este necesar un cod pe parte de client scris cu App Inventor, i unul pe parte de server (folosind un serviciu Web creat cu Ruby/Sinatra). Articolul de la IBM developerWorks explic acest lucru.

Capitolul 10 Tendine n tehnologie i n bazele de date 261

Figura 10.13 - App Inventor pentru aplicaia Android folosit la accesarea db2university

10.5 Rezumat
Acest capitol a luat n discuie tendinele importante manifestate n tehnologie ce vor fi disponibile pn n anul 2015, subliniind rolul bazelor de date n cadrul acestor tehnologii. Cloud computing se afl n vrful acestei liste, fiind actualmente cea mai discutat tem. Cloud computing este o metod nou de furnizare a resurselor IT prin care se permite companiilor i persoanelor fizice accesul la practic orice fel de resurse de calculator la cerere. Cloud computing este foarte eficient din punct de vedere financiar deoarece se

Baze de date - Fundamente pltete doar ce se consum.

262

n continuare s-a discutat despre aplicaiile mobile. Aplicaiile mobile reprezint un alt domeniu de interes n mare cretere n ultimul timp. Capitolul de fa a fcut o prezentare a diferitelor platforme de dispozitive mobile, precum i a platformelor de dezvoltare. Dup aceea, s-au prezentat pe scurt, modul de prelucrare a datelor cu caracter economic i a mainilor folosite n acest scop. Companiile au interes s obin informaii cu caracter economic pe baza datelor pe care le dein pentru a lua cele mai bune decizii n desfurarea activitii. n acelai timp, acestea nu doresc ca departamentul IT s consume prea mult timp cu setarea i configurarea depozitelor mari de date. Pentru rezolvarea unei astfel de stiuaii se pot folosi depozite mari de date pe baza crora se fac prelucrri de date cu caracter economic folosind maini configurate special n acest scop. Astfel de soluii sunt oferite cu ajutorul sistemului IBM Smart Analytics. Capitolul se ncheie cu o discuie despre db2university.com ca studiu de caz ce folosete multe dintre tehnologiile descrise aici.

A
Anexa A recapitulative
Capitolul 1 1. O baz de date este un depozit de date proiectat s suporte stocarea eficient a datelor, extragerea i mentenana acestora. 2. Un sistem de gestiune al bazelor de date, pe scurt SGBD, este un grup de instrumente software care controleaz accesul, organizarea, stocarea, obinerea i mentenana datelor dintr-o baz de date. 3. Modelul informaiilor este o reprezentare abstract i formal a entitilor mpreun cu proprietile, relaiile i operaiile ce pot fi efectuate asupra lor. Modelele de date, pe de alt parte, sunt definite la un nivel mult mai concret i conin mai multe detalii. Modelele de date sunt mult mai specifice i servesc la proiectarea sistemelor de baze de date. 4. Principalul avantaj este independena datelor (nu este specific nmagazinrii fizice). 5. Instalarea i testarea noilor versiuni de sisteme de gestiune a bazelor de date (SGBD), cu permisiuni i privilegii de control al accesului 6. Un model pureXML 7. C. Performan 8. E. Nici unul dintre enumerate 9. D. Integrare 10. B. Folosirea pureXML este principala diferen dintre DB2 i celelalte sisteme relaionale de gestiune a bazelor de date, pentru Cloud principala diferen este caracteristica Database Partitioning Feature (DPF). Aceasta permite scalabilitatea n cloud atunci cnd sunt oferite doar instane standard.

Rspunsuri

la

ntrebrile

Capitolul 2 1. Constrngerea de integritate a entitii sau constrngerea de unicitate mpreun cu cea nenul puse pe numrul de identificare al furnizorului, valoare nenul pentru numele furnizorului, domeniul de valori i valoarea nenul pentru discountul

Baze de date - Fundamente furnizorului. 2. Intersecia: R1 R2 = R1-(R1-R2). Jonciunea: R1join_condition R2 = join_condition (R1X R2) mprirea relaiilor R1(A,B) i R2(A): R1R2 = B(R1) - B((R2XB(R1)) - R1) 3. Name(Address=New York AND Discount>0.05(R))

264

4. RANGE OF SUPPLIERS IS SUPPLIERS.Name WHERE (SUPPLIERS.Address =New York AND SUPPLIERS.Discount>0.05) 5. NameX WHERE (DiscountX >0.05 AND SUPPLIERS Discount:DiscountX, Address:New York) 6. A. Date din lumea real modelate n baza de date. C. Caracteristic a datelor. 7. B. ntr-o relaie nu exist tupluri duplicat. C. Atributele au valori atomice. 8. B. Instana. D. Gradul. 9. A. O cheie primar este n acelai timp i cheie candidat. 10. D. Cascade. (Name:NameX,

Capitolul 3 1. D. 2. A. 3. C. 4. A. 5. B. 6. D. 7. B. 8. D. 9. C. 10. B.

Capitolul 4

Capitolul 10 Tendine n tehnologie i n bazele de date 265 1. Vedei exemplul din seciunea 4.6.1 descompunere fr pierdere de informaie 2. C 3. B 4. E 5. B 6. C Capitolul 5 1. D. 2. D. 3. A, C. 4. D. 5. D. 6. A. 7. B. 8. D. 9. D. 10. B. Capitolul 6 1. C 2. C 3. E 4. C 5. C 6. D 7. D 8. D 9. A 10. A Capitolul 7 1. B. 2. A.

Baze de date - Fundamente 3. B. 4. A. 5. B. 6. B. 7. B. 8. A. 9. B. 10. B. Capitolul 8 1. D. 2. B. 3. B. 4. D. 5. A. 6. A. 7. C. 8. A. 9. A. Capitolul 9

266

1. Dezvoltarea tehnologiei informaiei conduce la colectarea unor mari volume de date de ctre organizaii. Aceste date acoper domenii vaste de activitate i se pot afla n spatele lurii de decizii importante. Pentru a pstra secretul datelor, coerena i disponibilitatea acestora trebuie luate msuri de securitate. 2. Nu. Doar concentrarea pe securitatea bazelor de date nu va asigura sigurana acestora. Toate prile unui sistem trebuie s fie sigure: baza de date, reeaua, sistemul de operare, cldirea n care se afl baza de date precum i persoanele care au posibilitatea s acceseze sistemul. 3. ntr-un plan de securitate complet, exist mai multe pericole ce trebuie avute n vedere. Acestea sunt: furtul i frauda, pierderea caracterului privat i al confidenialitii datelor, pierderea integritii datelor, pierderea disponibilitii i pierderea accidental a datelor. 4. Controlul discreionar al accesului este o metod ce permite utilizatorilor s acceseze i s efectueze diverse operaii pe date n funcie de drepturile de acces sau a privilegiilor pe obiectele bazei de date.

Capitolul 10 Tendine n tehnologie i n bazele de date 267 5. DB2 lucreaz cu trei forme de autorizare: autoritatea administrativ, privilegii i controlul accesului pe baza etichetelor 6. Privilegiile sunt autoriti atribuite utilizatorilor, grupurilor sau rolurilor care permit acestora s efectueze diverse activiti cu obiectele din baza de date. 7. Contextele de ncredere stabilesc relaii de ncredere ntre DB2 i o entitate extern, cum ar fi un server Web sau un server de aplicaie. Aceast relaie se bazeaz pe autorizarea sistemului, adresa IP i fluxul de date criptat i se definete cu ajutorul unui obiect de tip context de ncredere n cadrul bazei de date. 8. O vedere este un tabel virtual obinut ca rezultat dinamic al efecturii uneia sau mai multor operaii relaionale pe tabelele de baz. O vedere se poate crea pentru a prezenta doar datele pentru care utilizatorul primete acceptul s le vad, fr a afia datele care au caracter privat sau confidenial. 9. Controlul integritii are ca scop protecia datelor la accesul neautorizat i la actualizare prin restricionarea valorilor ce pot fi luate de ctre acestea n momentul efecturii unor operaii. n acest scop, se pot folosi: definiii de domenii, aseriuni i declanatori. 10. Cele mai folosite politici i proceduri de securitate sunt: controalele personalului i controalele de acces fizic.

Baze de date - Fundamente

268

B
Anexa B Instalarea i rularea DB2
Aceast anex introduce o serie de aspecte de baz necesare lucrului cu DB2. Anexa vine n sprijinul celor care doresc s instaleze i s ruleze rapid i uor DB2. n cadrul acestei anexe vei nva despre: Pachetele DB2 Instalarea DB2 Instrumentele DB2 Mediul DB2 Configuraia DB2 Conectarea la o baz de date Exemple de programe de baz Documentaia DB2 Obs: Pentru mai multe informaii despre DB2, vedei cartea n format electronic Getting Started with DB2 Express-C ce face parte din aceast serie de cri.

B.1 DB2: vedere de ansamblu

DB2 este un server de date ce permite pstrarea i obinerea n siguran a datelor. Comenzile DB2, XQuery i SQL sunt folosite la interaciunea utilizatorului cu serverul DB2 permind crearea de obiecte i manipularea datelor ntr-un mediu sigur. Pentru a introduce aceste comenzi se folosec o serie de instrumente aa cum se vede din Figura B.1. Aceast figur prezint o vedere de ansamblu asupra DB2 i provine din cartea n format electronic Getting Started with DB2 Express-C.

Anexa B Instalarea i rularea DB2 269

Figura B.1 - DB2 Vedere de ansamblu n partea stng a figurii, se prezint exemple de comenzi ce pot fi folosite de ctre utilizatori. n centrul figurii, se prezint cteva instrumente n care se pot introduce aceste comenzi, iar n partea dreapt a figurii se poate vedea mediul DB2 n care se pstreaz baza de date. n seciunile urmtoare vom discuta n detaliu despre unele dintre elementele ce apar n aceast figur.

B.2 Pachetele DB2

Serverele, clienii i driverele DB2 se creeaz folosind aceleai componente de baz, dup care se mpacheteaz ntr-o modalitate care permite utilizatorilor s aleag funciile de care au nevoie la preul corect. Aceast seciune descrie diversele ediii de DB2 sau pachete de produse disponibile.

B.2.1 Servere DB2

Figura B.2 prezint o vedere de ansamblu a diferitelor servere de date DB2.

Baze de date - Fundamente

270

DB2 Enterprise Edition DB2 Workgroup Edition

DB2 Express Edition

DB2 Express-C

Extra functionality

Extra functionality

Extra functionality

Figure B.2 Pachetele de server DB2 Aa cum se vede din Figura B.2, toate ediiile de servere DB2 sunt construite unul pe baza celuilalt. DB2 Express-C este versiunea gratuit de DB2 i este componenta de baz a tuturor produselor DB2. Prin adugarea de funcionaliti suplimentare, aceasta devine DB2 Express. Prin adugarea de funcionaliti suplimentare la DB2 Express, se obine DB2 Workgroup .a.m.d. Figura B.2 prezint motivul pentru care este foarte uor s se treac de la DB2 Express-C la orice alt server DB2: Toate ediiile de servere DB2 sunt construite pornind de la DB2 Express-C. De asemenea, aplicaiile create pentru DB2 Express-C sunt valabile n toate celelalte ediii. Aplicaiile create vor funciona fr a fi necesar nici un fel de modificare!

B.2.2 Clienii si driverele DB2

La instalarea serverului DB2 se instaleaz i o component de client DB2. Dac se dorete doar instalarea clientului, se poate alege ntre IBM Data Server Client, sau IBM Data Server Runtime Client. Figura B.3 prezint cei doi clieni.

Figure B.3 Clieni DB2 Din figura de mai sus, se poate observa clientul IBM Data Server Runtime care are toate

Anexa B Instalarea i rularea DB2 271 componentele necesare (suport pentru driver i reea) pentru a se conecta i a lucra cu serverul de date DB2. Clientul IBM Data Server are acelai suport, incluznd i instrumentele de interfa grafic utilizator i bibliotecile pentru elaborarea de aplicaii. Suplimentar, se mai ofer i urmtorii clieni i drivere: DB2 Runtime Client Merge Modules pentru Windows: se folosete n principal pentru a ncorpora un client DB2 ca parte a instalrii unei aplicaii Windows IBM Data Server Driver for JDBC and SQLJ: permite aplicaiilor Java s se conecteze la serverele DB2 fr a fi necesar s se instaleze clientul IBM Data Server Driver for ODBC and CLI: permite aplicaiilor ODBC i CLI s se conecteze la serverul DB2 fr a fi necesar s se instaleze clientul IBM Data Server Driver Package: conie un driver specific Windows cu suport pentru mediile .NET suplimentar ODBC, CLI i open source. Acest driver se numea anterior IBM Data Server Driver for ODBC, CLI and .NET. Clienii i driverele DB sunt gratuite.

B.3 Instalarea DB2

n aceast seciune se arat cum se instaleaz DB2 folosind programul ajuttor existent.

B.3.1 Instalare pe Windows

Instalarea DB2 pe Windows este simpl i preuspune parcurgerea umtoarelor etape: 1. Se va folosi un cont local sau utilizator de domeniu care este parte a grupului Administrator de pe serverul pe care se instaleaz DB2. 2. Dup descrcarea i dezarhivarea ediiei DB2 Express-C for Windows de la adresa ibm.com/db2/express, se caut fiierul setup.exe, care se execut. 3. Se urmresc instruciunile explicative din cadrul programului ajuttor. Se aleg valorile implicite, ceea ce este suficient pentru nceput. 4. n timpul instalrii se efectueaz urmtoarele: - DB2 se instaleaz n C:\Program Files\IBM\SQLLIB - Se creeaz grupurile DB2ADMNS i DB2USERS n cadrul sistemului de operare Windows. - Se creeaz instaa DB2 n C:\Program Files\IBM\SQLLIB\DB2 - Se creeaz DB2 Administration Server (DAS) - Jurnalele de instalare se gsesc n: My Documents\DB2LOG\db2.log My Documents\DB2LOG\db2wi.log

Baze de date - Fundamente - Se creeaz cteva servicii Windows.

272

B.3.2 Instalare pe Linux

Instalarea DB2 pe Linux este simpl i preuspune parcurgerea umtoarelor etape: Logarea ca utilizator Root pentru instalarea DB2. 1. Dup descrcarea DB2 Express-C for Linux de la adresa ibm.com/db2/express, se caut fiierul db2setup, care se execut: ./db2setup 2. Se urmeaz instruciunile explicative din programul ajuttor. Se aleg valorile implicite. 3. Pe parcursul instalrii se efectueaz urmtoarele n mod implicit: - Se instaleaz DB2 n /opt/ibm/db2/V9.7 - Se creeaz trei identificatori de utilizatori cu valorile implicite: db2inst1 (proprietarul instanei) db2fenc1 (utilizatori protejai, rutine protejate) dasusr1 (utilizatorDAS) - Se creeaz trei grupuri de utilizatori corespunztori identificatorilor anteriori: db2iadm1 db2fadm1 dasadm1 - Se creeaz instana db2inst1 - Se creeaz dasusr1 - Jurnalele de instalare se gsesc n: /tmp/db2setup.his /tmp/db2setup.log /tmp/db2setup.err

B.4 Instrumente DB2

Exist o serie de instrumente incluse n serverul de date DB2 cum ar fi DB2 Control Center, DB2 Command Editor .a.m.d. ncepnd cu versiunea DB2 9.7 aceste instrumente nu mai sunt de actualitate (adic, ele sunt suportate n continuare, dar nu mai sunt mbuntite) folosindu-se n schimb IBM Data Studio. IBM Data Studio este oferit ca pachet suplimentar nefiind inclus n DB2. Vedei cartea n format electronic Getting started with IBM Data Studio for DB2 pentru a obine mai multe detalii.

B.4.1 Control Center

nainte de versiunea DB2 9.7, instrumentul principal al DB2 pentru administrarea bazelor de date era Control Center, aa cum se vede din Figura B.4. Acest instrument nu mai este de actualitate, dar exist nc n serverele DB2.

Anexa B Instalarea i rularea DB2 273

Figura B.4 - DB2 Control Center Pentru a porni Control Center pe Windows se folosete Start -> Programs -> IBM DB2 -> DB2COPY1 (Default) -> General Administration Tools -> Control Center sau, se scrie comanda db2cc n Windows Command Prompt sau n Linux. Control Center este un instrument centralizat de administrare ce permite: Urmrirea sistemului, instanelor, bazelor de date i a obiectelor din cadrul bazelor de date. Crearea, modificarea i gestionarea bazelor de date i a obiectelor acestora Pornirea altor instrumente grafice DB2 Fereastra din partea stng prezint ierarhia obiectelor bazei de date din cadrul sistemului, prezentnd cte un folder pentru tabele, vederi etc. Atunci cnd se apas pe un folder (de exemplu folderul Tables, aa cum se vede din Figura B.5), fereastra din partea dreapt sus va prezenta toate obiectele corespunztoare, n acest caz toate tabelele existente n baza de date SAMPLE. Dac se alege un anumit tabel din fereastra din dreapta sus, fereastra din dreapta jos va afia o serie de informaii despre tabel. Prin apsarea butonului din dreapta al mouse-ului, atunci cnd acesta este poziionat pe foldere sau obiecte n arborele Object vor apare meniurile disponibile pentru acel folder sau obiect. De exemplu, prin apsarea pe o instan i alegerea comenzii Configure parameters se va permite vizualizarea i actualizarea parametrilor la nivel de instan. La

Baze de date - Fundamente fel se procedeaz pentru bazele de date.

274

B.4.2 Instrumente n linie de comand

Exist trei tipuri de instrumente n linie de comand: DB2 Command Window (doar pe Windows) DB2 Command Line Processor (DB2 CLP) DB2 Command Editor (o interfa grafic utilizator, care nu se mai folosete) Aceste instrumente sunt prezentate pe larg n seciunile urmtoare. B.4.2.1 DB2 Command Window DB2 Command Window este disponibil doar pe sistemele de operare Windows i se confund deseori cu Windows Command Prompt. Dei arat la fel, DB2 Command Window, iniializeaz mediul de lucru cu DB2. Pentru pornirea acestui instrument, se folosete Start -> Programs -> IBM DB2 -> DB2COPY1 (Default) -> Command Line Tools > Command Window sau se scrie comanda db2cmd din Windows Command Prompt pentru a se deschide ntr-o alt fereastr. Figura B.5 prezint DB2 Command Window.

Figura B.5 - DB2 Command Window Se poate afla cu uurin c se lucreaz cu DB2 Command Window dac se citete titlul ferestrei, care ntotdeauna conine cuvintele DB2 CLP aa cum se vede din figur. Din DB2 Command Window, toate comenzile trebuie scrise cu prefixul db2. De exemplu, n figura de mai sus, se vd dou comenzi:
db2 connect to sample db2 select * from staff

Anexa B Instalarea i rularea DB2 275 n Linux, echivalentul pentru DB2 Command Window este mediul Linux (aplicaia Terminal) n care mediul DB2 se configureaz prin folosirea fiierului db2profile. Acest filier se creeaz implicit i se adaug fiierului .login pentru proprietarul instanei DB2. Implicit, proprietarul instanei este db2inst1. B.4.2.2 DB2 Command Line Processor DB2 Command Line Processor (CLP) este asemntor cu DB2 Command Window, cu singura excepie c prompterul este db2=> i nu prompterul sistemului de operare. Pentru a porni DB2 Command Line Processor pe Windows, se folsoete Start -> Programs -> IBM DB2 -> DB2COPY1 (Default) -> Command Line Tools -> Command Line Processor sau se scrie n DB2 Command Window sau n Linux db2 i se apas Enter. Prompterul se va schimba n db2 aa cum se vede n Figura B.6.

Figura B.6 - DB2 Command Line Processor (CLP) Se observ i faptul c Figura B.6 mai arat i c dac se lucreaz n CLP, nu mai trebuie prefixate comenzile cu DB2. Pentru a iei din CLP, se introduce comanda quit. B.4.2.3 DB2 Command Editor DB2 Command Editor este o versiune grafic utilizator a DB2 Command Window sau DB2 Command Line Processor aa cum se vede din Figura B.7. Acest instrument nu se mai folosete n versiunea DB2 9.7.

Baze de date - Fundamente

276

Figura B.7 - DB2 Command Editor

Anexa B Instalarea i rularea DB2 277

B.5 Mediul DB2

Figura B.8 ofer o vedere de ansamblu asupra mediului DB2.

Figura B.8 - Mediul DB2 Figura prezint instalat un server DB2 Express-C. Cutiile mai mici n verde deschis (Environment Variables, Database Manager Configuration File, Database Configuration File, DB2 Profile Registry) sunt zonele diferite n care poate fi configurat serverul DB2, acestea fiind explicate detaliat n seciunea urmtoare. Cutia mai mare n verde nchis reprezint o instan care n exemplul de fa are numele myinst. O instan este mediul n care se creeaz obiectele bazei de date. Pe acelai server se pot crea mai multe instane, fiecare dintre acestea fiind tratat separat. De exemplu, se poate folosi o instan pentru dezvoltare, alta pentru testare i alta pentru producie. Tabelul B.1 prezint cteva comenzi utile ce pot fi folosite la nivel de instan. Comenzile prezentate n cadrul acestei seciuni se pot folosi i n cadrul instrumentelor grafice DB2. Comanda db2start db2stop db2icrt <instance_name> db2idrop <instance_name> db2ilist Descrierea Pornete instana curent Oprete instana curent Creaz o instan nou Elimin o instan Afieaz instanele existente pe sistem

Baze de date - Fundamente db2 get instance Afieaz instanele active existente

278

Tabelul B.1 Instane utile comenzi la nivel de DB2 n cadrul unei instane se pot crea mai multe baze de date. O baz de date este o colecie de obiecte, cum ar fi tabele, vederi, indeci .a.m.d. De exemplu, n Figura B.8, baza de date MYDB1 a fost creat n cadrul instanei myinst. Tabelul B.2 prezint cteva comenzi ce pot fi folosite la nivel de baz de date. Comand create database <nume_baza_de_date> drop database <nume_baza_de_date> connect to <nume_baza_de_date> Descriere Creeaz o baz de date nou Elimin o baz de date Se realizeaz conexiunea la o baz de date Comenzi SQL pentru crearea tabelelor, vederilor i, respectiv, a indecilor.

create table/create view/create index Tabelul B.2 - Comenzi la nivel de baze de date

B.6 Configurarea DB2

Parametrii DB2 pot fi configurai cu ajutorul instrumentului Configuration Advisor GUI. Configuration Advisor poate fi accesat prin intermediul Control Center apsnd butonul din dreapta al mouse-ului atunci cnd acesta se afl deasupra unei baze de date i alegnd Configuration Advisor. n funcie de rspunsurile la ntrebri referitoare la resursele sistemului i ncrcare, se vor pune la dispoziie o serie de parametrii DB2 care vor opera optimal prin intermediul valorilor sugerate. Dac dorii mai multe informaii despre configurarea DB2, citii n continuare, altfel folosii Configuration Advisor i totul este pregtit pentru lucrul cu DB2! Serverul DB2 poate fi configurat la patru nivele diferite, aa cum ai vzut n Figura B.8: Environment variables sunt variabilele la nivel de sistem de operare. Principala variabil de mediu care v intereseaz n mod deosebit este DB2INSTANCE. Aceast variabil arat instana curent cu care lucrai i la ce comenzi DB2 se aplic. Database Manager Configuration File (dbm cfg) conine parametrii care afecteaz instana i toate bazele de date existente acolo. Tabelul B.3 prezint cteva comenzi utile pentru gestionarea dbm cfg. Comanda get dbm cfg Descriere Obine informaii despre dbm cfg

Anexa B Instalarea i rularea DB2 279 update dbm cfg using Actualizeaz valoarea parametrului dbm cfg <nume_parametru> <valoare> Tabelul B.3 Comenzi pentru controlul dbm cfg Database Configuration File (db cfg) conine parametrii care afecteaz o anumit baz de date. Tabelul B.4 prezint cteva comenzi utile pentru controlul db cfg. Comanda get db cfg for <nume_baza_de_date> update db cfg for <nume_baza_de_date> using <nume_parametru> <valoare> Descriere Obine informaii despre db cfg pentru o anumit baz de date Actualizeaz parametrului db cfg valoarea

Tabelul B.4 Comenzi pentru controlul db cfg DB2 Profile Registry variables conine parametri ce pot fi specifici platformei i care pot fi configurai global (afecteaz toate instanele), sau la nivel de instan (afecteaz doar o anumit instan). Tabelul B.5 prezint cteva comenzi care controleaz registrul profilului DB2. Comanda db2set -all Descriere Afieaz toate variabilele registrului de profil DB2 care pot fi configurate

db2set <parametru>=<valoare> Introduce o valoare n cadrul unui parametru Tabelul B.5 - Comenzi pentru controlul registrului de profil DB2

B.7 Conectarea la o baz de date

Dac baza de date este local, adic aceasta se afl pe acelai sistem pe care se efectueaz operaii cu baza de date, setarea conexiunii se realizeaz automat la crearea bazei de date. Mai trebuie doar executat comanda connect to nume_baza_de_date pentru a v conecta la baza de date respectiv. Dac baza de date se afl la distan, cea mai simpl metod pentru realizarea conexiunii la baza de date este folosirea instrumentului Configuration Assistant, urmnd paii: 1. Se pornete Configuration Assistant de pe sistemul n care se dorete conexiunea la baza de date. Pentru a porni acest instrument, se folosete comanda db2ca din Windows command prompt sau Linux. Figura B.9 prezint instrumentul Configuration Assistant.

Baze de date - Fundamente

280

Figura B.9 Instrumentul DB2 Configuration Assistant 2. Din Configuration Assistant, se alege meniul Selected --> Add database using Wizard 3. Din Select how you want to set up a connection window, se poate folosi Search the network dac reeaua este mic i are mai multe dispozitive de conectare. Dac se cunoate numele serverului pe care se afl DB2, se alege Known systems i se caut baza de date la care se dorete s se realizeze conexiunea. Se folosete programul ajuttor cu valori implicite. Dac nu se cunoate numele sistemului se alege Other systems (Search the network). De remarcat c n acest caz este nevoie de mai mult timp dac reeaua este mare. 4. Dac Search the network nu funcioneaz, v ntoarcei la fereastra Select how you want to set up a i alegei Manually configure a connection to a database. Alegei TCP/IP i apsai Next. Introducei hostname sau IP address acolo unde se afl serverul DB2. Introducei fie numele serviciului fie numrul portului. 5. Continuai s folosii programul ajuttor i folosii valorile implicite. 6. Dup terminarea configuraiei, va apare o fereastr care v ntreab dac dorii s se fac testarea conexiunii cu baza de date. Putei testa conexiunea i dup terminarea configurrii, prin apsarea butonului din dreapta al mouse-ului atunci cnd acesta se afl deasupra bazei de date i alegerea Test Connection.

B.8 Exemple de programe de baz

n funcie de limbajul de programare folosit, se folosesc sintaxe diferite la conectarea cu baza de date, pentru a putea efectua operaiile dorite. n continuare se prezint o serie de link-uri ctre exemple de programe de baz care ajut la conectarea cu o baz de date pentru a putea obine date. V sugerm s descrcai toate aceste programe de la adresa

Anexa B Instalarea i rularea DB2 281 ftp://ftp.software.ibm.com/software/data/db2/udb/db2express/samples.zip) Produsul CLI http://www.ibm.com/developerworks/db2/library/techarticle/dm0401chong/index.html#scenario1 Produsul ODBC http://www.ibm.com/developerworks/db2/library/techarticle/dm0401chong/index.html#scenario2 Produsul C cu codul SQL ncorporat http://www.ibm.com/developerworks/db2/library/techarticle/dm0401chong/index.html#scenario3 Produsul JDBC cu folosirea driverului Type 2 Universal (JCC) http://www.ibm.com/developerworks/db2/library/techarticle/dm0401chong/index.html#scenario6 Produsul JDBC cu folosirea driverului Type 4 Universal (JCC) http://www.ibm.com/developerworks/db2/library/techarticle/dm0401chong/index.html#scenario8 Produsul Visual Basic and C++ ADO Folosirea provider-ului IBM OLE DB pentru DB2 (IBMDADB2) http://www.ibm.com/developerworks/db2/library/techarticle/dm0402chong2/index.html#scenario1 Produsul Visual Basic and C++ ADO - Folosirea provider-ului OLE DB Provider pentru ODBC (MSDASQL) http://www.ibm.com/developerworks/db2/library/techarticle/dm0402chong2/index.html#scenario2 Visual Basic and C# ADO.Net folosind IBM DB2 .NET Data Provider http://www.ibm.com/developerworks/db2/library/techarticle/dm0402chong2/index.html#scenario3 Visual Basic and C# ADO.Net folosind Microsoft OLE DB .NET Data Provider http://www.ibm.com/developerworks/db2/library/techarticle/dm0402chong2/index.html#scenario4 Visual Basic and C# ADO.Net folosind Microsoft ODBC .NET Data Provider http://www.ibm.com/developerworks/db2/library/techarticle/dm0402chong2/index.html#scenario5

Baze de date - Fundamente

282

B.9 Documentaia DB2

DB2 Information Center ofer online cele mai recente informaii despre DB2. DB2 Information Center este o aplicaie Web ce poate fi accesat la adresa (http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp), sau se poate descrca i instala local. Adresa pentru DB2 Information Center, dar i pentru versiunile ce pot fi descrcate este: http://www.ibm.com/software/data/db2/9/download.html?S_TACT=download&S_CMP=exp csite

Resurse
Site-uri Web
1. DB2 Express-C ibm.com/db2/express Aceasta este pagina de pornire pentru DB2 Express-C. Pe aceast pagin se pot gsi link-uri pentru descrcarea DB2 Express-C. 2. IBM Data Studio http://www-01.ibm.com/software/data/optim/data-studio/ Aceasta este pagina de pornire pentru IBM Data Studio, un instrument Eclipse ce poate fi folosit mpreun cu DB2. 3. Descrcarea DB2 Express-C i a IBM Data Studio (gratuite) http://www.ibm.com/db2/express/download.html?S_CMP=ECDDWW01&S_TACT=D OCBOOK01 4. InfoSphere Data Architect http://www-01.ibm.com/software/data/optim/data-architect/

Cri
1. Carte gratuit n format electronic: Getting started with DB2 Express-C (3rd Edition) Raul F. Chong et all - June 2009 http://www.db2university.com 2. Carte gratuit n format electronic: Getting started with IBM Data Studio for DB2 Debra Eaton et all - Dec 2009 http://www.db2university.com 3. DB2 9 pureXML Guide Whei-Jen Chen, Art Sammartino, Dobromir Goutev, Felicity Hendricks, Ippei Komi, Ming-Pang Wei, Rav Ahuja August 2007 - SG24-7315-01 http://www.redbooks.ibm.com/abstracts/sg247315.html 4. Free Redbook : DB2 Security and Compliance Solutions for Linux, UNIX, and Windows, Whei-Jen Chen, Ivo Rytir, Paul Read, Rafat Odeh, March 2008, SG 247555-00 http://www.redbooks.ibm.com/abstracts/sg247555.html?Open

Baze de date - Fundamente

284

Bibliografie
[1.1] CODD, E.F. A relational model of data for large shared data banks, CACM 13, NO 6, 1970 [2.1] DATE, C.J. An introduction to database systems, Addison-Wesley Publishing Company, 1986 [2.2] MITEA, A.C. Relational and object-oriented databases, Lucian Blaga University Publishing Company, 2002 [2.3] CODD, E.F. Relational completeness on data base sublanguage, Data Base Systems, Courant Computer Science Symposia Series, Vol.6 Englewood Cliffs, N.J, Prentice-Hall, 1972 [2.4] KUHNS, J.L. Answering questions by computer: A logical study, Report RM-5428-PR, Rand Corporation, Santa Monica, California, 1967 [2.5] CODD, E.F. A data base sublanguage founded on the relational calculus, Proceedings ACM SIGFIDET Workshop on Data Description, Access and Control, 1971 [2.6]LACROIX, M., PIROTTE, A. Domain oriented relational languages, Proceedings 3rd International Conference on Very Large Data Bases, 1977 [2.7]LACROIX, M., PIROTTE, A. Architecture and models in data base management systems, G.M. Nijssen Publishing company, North-Holland, 1977 [3.1] IBM Rational Data Architect Evaluation Guide [3.2] Connolly, T., Begg, C., Strachan, A. Database Systems A Practical Approach to Design, Implementation and Management, Addison Wesley Longman Limited 1995, 1998 [3.3] IBM InfoSphere Data Architect Information Center [3.4] http://www.ibm.com/developerworks/data/bestpractices/ [3.5] 03_dev475_ex_workbook_main.pdf, IBM Rational Software, Section 1: Course Registration Requirements, Copyright IBM Corp. 2004 [4.1] Codd, E. F. The Relational Model for Database Management [4.2] Codd, E.F. "Further Normalization of the Data Base Relational Model." [4.3] Date, C. J. "What First Normal Form Really Means" [4.4] Silberschatz, Korth, Sudershan - Database System Concepts [4.5] William Kent - A Simple Guide to Five Normal Forms in Relational Database Theory [4.6] Raghu Ramakrishnan, Johannes Gehrke - Database management systems [4.7] Vincent, M.W. and B. Srinivasan. "A Note on Relation Schemes Which Are in 3NF But Not in BCNF." [4.8] C. J Date : An Introduction to Database Systems 8th Edition [4.9] William Kent: A simple guide to five normal forms in relational database theory

Resources 285 http://www.bkent.net/Doc/simple5.htm [4.10] Ronald Fagin, C J Date: Simple conditions for guaranteeing higher normal forms in relational databases http://portal.acm.org/citation.cfm?id=132274 [4.11] Ronald Fagin: A Normal Form for Relational Databases That Is Based on Domains and Keys http://www.almaden.ibm.com/cs/people/fagin/tods81.pdf [4.12] C. J. Date, Hugh Darwen, Nikos A. Lorentzos: Temporal data and the relational model p172 [4.13] C J Date: Logic and databases, Appendix C [5.1] Differences between SQL procedures and External procedures http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db29.doc.apsg/db2z_ differencesqlprocexternalproc.htm [5.2] SQL Reference Guide http://www.ibm.com/developerworks/data/library/techarticle/0206sqlref/0206sqlref.html [6.1] http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db29.doc.apsg/db2z_ differencesqlprocexternalproc.htm

Date de contact
Contact email: Csua potal a programului DB2 on Campus: [email protected]

Parcurgerea crii Baze de date - Fundamente s-ar putea s nu fie uoar. Citii aceast carte pentru a: Afla la ce se folosesc bazele de date nelege modelele relaional, de informaii i conceptual nva cum se proiecteaz bazele de date Scrie comenzi SQL, funcii i proceduri n bazele de date Afla cum se pot integra datele XML i cele relaionale folosind DB2 pureXML nelege securitatea bazelor de date Efectua o serie de exerciii

Datele tind s devin cele mai importante bunuri critice ale unei afaceri. Prin pierderea datelor exist riscul de pierdere a afacerii. Bazele de date sunt folosite peste tot, de la cele mai simple aplicaii care pstreaz informaii individuale, pn la cele mai complexe care pstreaz informaii despre milioane de utilizatori. Aceast carte v introduce n fascinanta lume a bazelor de date. Se prezint elementele fundamentale ale sistemelor de gestiune a bazelor de date fcndu-se referire la sistemele IBM DB2. Folosind DB2 ExpressC, versiunea gratuit a DB2, putei trece n revist toate elementele constitutive ale sistemelor de baze de date, ale bazelor de date, ale limbajelor SQL i XML. Cartea conine exemple i exerciii ce v ajut s v mbogii experiena i v permit s aplicai conceptele bazelor de date. Pentru a obine mai multe informaii despre fundamentele bazelor de date i a subiectelor referitoare la gestiunea informaiilor, vizitai: ibm.com/developerworks/data/ Pentru a obine mai multe informaii sau pentru a descrca DB2 ExpressC, vizitai: ibm.com/db2/express Pentru a socializa i pentru a urmri materialele video vizitai: channelDB2.com Aceast carte face parte din seria de cri DB2 on Campus, cri n format electronic, gratuite. Aflai mai multe la adresa: db2university.com

Pre: 24.99USD