Carte BD

Cuprins
1

Cuprins

Contents7
Prefa ................................................................................................................ 13

Capitolul 1 .......................................................................................................... 15
Elemente de teoria bazelor de date .................................................................. 15
1.1. Evoluia organizrii datelor ........................................................................................... 15
1.2. Caracteristici generale a organizrii datelor n fiiere ................................................... 20
1.3. Concepte utilizate n definirea bazelor de date ............................................................. 26
1.3.1. Conceptul de caracteristic i familie de caracteristici .......................................... 27
1.3.2. Conceptul de colecie de date ................................................................................. 27
1.4. Conceptul de baz de date ............................................................................................. 32
1.5. Conceptul de sistem de baze de date ............................................................................. 35
1.6. Baze de date centralizate i distribuite .......................................................................... 35
1.7. Niveluri de organizare a datelor n baze de date ........................................................... 36

Capitol 2 ............................................................................................................. 39
Sisteme de gestiune a bazelor de date (SGBD -DBMS) ................................. 39
2.1. Definirea SGBD ............................................................................................................ 39
2.2. Obiectivele unui SGBD ................................................................................................. 42
2.3. Funciile unui sistem de gestiune a bazei de date .......................................................... 45
2.4. Arhitectura sistemelor de gestiune a bazelor de date .................................................... 47
2.4.1. Arhitectura unui SGBD n concepia CODASYL .................................................. 47
2.4.2. Arhitectura propus de grupul ANSI/SPARC ........................................................ 48
2.4.3. Arhitectura client/server ......................................................................................... 50
2.4.4. Arhitectura SGBD Oracle ...................................................................................... 51
2.4.4.1. Arhitectura pe componente a SGBD Oracle ....................................................... 53
2.4.4.2. Structura fizic a BD Oracle ............................................................................... 59

Capitolul 3 .......................................................................................................... 61
Administrarea bazelor de date ......................................................................... 61
3.1. Sarcinile administratorului bazei de date (ABD) .......................................................... 61
3.2. Funciuni de administrare a bazelor de date .................................................................. 62
3.3. Instrumente la dispoziia administratorului de baze de date ......................................... 64
3.4. Protecia bazelor de date ............................................................................................... 64
3.4.1. Asigurarea integritii datelor din baze de date ...................................................... 65
3.4.2. Asigurarea confidenialitii datelor din baze de date ............................................ 66

Capitolul 4 .......................................................................................................... 69
Baze de date relaionale .................................................................................... 69
4.1. Domeniu, atribut, valoare .............................................................................................. 69
4.2. Relaie, tuplu ................................................................................................................. 72
Cuprins
2
4.3. Relaii i baza de date .................................................................................................... 74
4.4. Restricii de integritate .................................................................................................. 76
4.5. Chei ............................................................................................................................... 77
4.6. Restricii de integritate minimale .................................................................................. 79
4.7. Baza de date relaional o descriere formal .............................................................. 80

Capitolul 5 .......................................................................................................... 87
Proiectarea bazelor de date relaionale ........................................................... 87
5.1. Consideraii privind proiectarea structurii conceptuale i a structurii logice a bazelor de
date ....................................................................................................................................... 88
5.2. Normalizarea tabelelor bazei de date ............................................................................ 96
5.2.1. Conceptul de normalizare ....................................................................................... 96
5.2.2. Obiectivul i necesitatea normalizrii relaiilor ..................................................... 97
5.2.3. Dependene funcionale .......................................................................................... 99
5.2.4. Formele normale unu, doi i trei .......................................................................... 102
5.2.5. Forma normal BOYCE-CODD (BCNF) ............................................................ 109
5.2.6. Dependena multivaloare i forma normal patru ................................................... 112
5.2.7. Dependena jonciune i forma normal cinci ...................................................... 114
5.2.8. Supranormalizarea. Rezultatul normalizrii ......................................................... 116
5.2.9. Algoritmizarea primelor trei forme normale ........................................................ 117
5.3. Calitatea schemelor ..................................................................................................... 119

Capitolul 6 ........................................................................................................ 121
Algebra relaional i calculul relaional ...................................................... 121
6.1. Operaii tradiionale pe mulimi .................................................................................. 121
6.2. Operaii relaionale speciale ........................................................................................ 128
6.3. Construirea expresiilor n algebra relaional ............................................................. 139
6.4. Echivalena expresiilor n algebra relaional ............................................................. 140
6.5. Calculul relaional ....................................................................................................... 143
6.5.1. Calculul relaional orientat pe domeniu ............................................................... 144
6.5.2. Calculul relaional orientat pe tuplu cu declararea rangului variabilelor libere ... 145

Capitolul 7 ........................................................................................................ 147
Baze de date orientate obiect (BDOO) .......................................................... 147
7.1. Conceptul de BDOO ................................................................................................... 147
7.2. Premisele BDOO ......................................................................................................... 147
7.3. Avantajele i dezavantajele BDOO ............................................................................. 149
7.4. Comparaii ntre abodarea obiectual i cea relaional privind modelarea datelor ... 152
7.5. Moduri de abordare ale dezvoltrii sistemelor de BDOO ........................................... 154
7.6. Modelul conceptual al datelor obiect (CODM) ........................................................... 155
7.6.1. Conceptul de obiect .............................................................................................. 155
7.6.2. Identificatorii obiectelor ....................................................................................... 157
7.6.3. Atribute proprieti ale obiectelor ..................................................................... 158
7.6.4. Tipuri i clase de obiecte ...................................................................................... 160
7.6.5. Metode .................................................................................................................. 168
7.6.6. ncapsularea i interfaa ......................................................................................... 172
7.6.7. Polimorfismul ....................................................................................................... 173
7.6.8. Asocierile ntre clase ............................................................................................ 173
7.6.9. Motenirea ............................................................................................................ 180
Cuprins

3
7.6.10. Generalizarea i specializarea ............................................................................ 181
7.6.11. Agregarea, compunerea i descompunerea ........................................................ 182
7.7. Standardul ODMG pentru baze de date orientate obiect ............................................. 184
7.7.1. Aspecte generale referitoare la standardizare ....................................................... 184
7.7.2. Modelul de obiecte ............................................................................................... 185
7.7.3. Limbajul de definire a obiectelor ......................................................................... 185
7.7.4. Limbajul de cereri obiect OQL ............................................................................ 190
7.8. Sisteme de gestiune a bazelor de date orientate obiect (SGBDOO) ........................... 193
7.8.1. GEMSTOME ....................................................................................................... 193
7.8.2. ONTOS ................................................................................................................. 193
7.8.3. VERSANT ........................................................................................................... 194
7.8.4. ORION ................................................................................................................. 194
7.8.5. ITASCA ............................................................................................................... 195
7.8.6. O2 ......................................................................................................................... 195
7.8.7. Object Store .......................................................................................................... 196
7.8.8. OBJECTIVITY/DB .............................................................................................. 196
7.9. Reguli de evaluare a unui SGBDOO ........................................................................... 197
7.10. Limbaj unificat de modelare (UML )-suport pentru BDOO ..................................... 199
7.10.1. Ce este UML-ul? ................................................................................................ 199
7.10.2. Componentele limbajului unificat de modelare ................................................. 200
7.10.3. Diagrama cazurilor de utilizare .......................................................................... 202
7.10.4. Diagrama claselor ............................................................................................... 204
7.10.5. Diagrama obiectelor ........................................................................................... 207
7.10.6. Diagrama de secven ......................................................................................... 207
7.10.7. Diagrama de stare ............................................................................................... 209
7.10.8. Diagrama de colaborare ..................................................................................... 211
7.10.9. Diagrama de activitate ........................................................................................ 212
7.10.10. Diagrama componentelor ................................................................................. 213
7.10.11. Diagrama de desfurare .................................................................................. 214
7.10.12. Diagrama pachetelor ........................................................................................ 214
7.10.13. Interaciunea dintre diagramele UML .............................................................. 216
7.10.14. Avantajele utilizrii UML ................................................................................ 217
7.11. Modelarea orientat obiect ........................................................................................ 219
7.11.1. Modelarea domeniului (mediului) Domain Model ......................................... 219
7.11.2. Modelarea proceselor afacerii (prelucrrilor) Business Model ....................... 220
7.11.3. Modelarea cazurilor de utilizare ......................................................................... 222
7.11.4. Modelarea structurii statice (diagrama claselor, diagrama obiectelor) .............. 224
7.11.5. Modelarea dinamicii sistemului ......................................................................... 226
7.12. Proiectarea BDOO component a sistemului informatic ....................................... 229
7.12.1. Modelarea proceselor de afaceri ........................................................................ 229
7.12.2. Modelarea cazurilor de utilizare ......................................................................... 234
7.12.3. Modelarea structurii statice a sistemului ............................................................ 240
7.13. RUP-suport de realizare a sistemelor informatice i implicit a BDOO .................... 240
7.13.1. Cele mai bune practici de realizare a sistemelor informatice ............................. 241
7.13.2. Individualizarea RUP ......................................................................................... 243
7.13.3. Identificarea cerinelor ....................................................................................... 246
7.13.4. Analiza orientat obiect ...................................................................................... 248
7.13.5. Proiectarea orientat obiect ................................................................................ 253

Capitolul 8 ........................................................................................................ 259
Cuprins
4
Bazele de date obiectual relaionale - Standardul SQL3 .......................... 259
8.1. Modelul obiectual-relaional ....................................................................................... 259
8.2. Modelul SQL3 standard pentru BDOR .................................................................... 259
8.2.1. Noi tipuri de date n SQL3 ................................................................................... 261
8.3. Compararea SGBDR cu SGBDOR ............................................................................. 267
8.4. Compararea SGBDOO cu SGBDOR .......................................................................... 268

Capitolul 9 ........................................................................................................ 269
Oracle-SGBD obiectual-relaional ................................................................. 269
9.1. Tipuri de obiecte (Object types ) ................................................................................. 269
9. 2. Tabela de obiecte ........................................................................................................ 274
9.3. Tehnica de referire a obiectelor ................................................................................... 276
9.4. Motenirea ................................................................................................................... 278
9.4.1. Implementarea motenirii n Oracle anterior versiunii 9i .................................... 278
9.4.2. Implementarea motenirii utiliznd clauza under ............................................. 279
9.4.3. Motenirea multipl .............................................................................................. 279
9. 5. Relaii de asociere ...................................................................................................... 279
9.6. Agregarea .................................................................................................................... 283
9.6.1. Implementarea agregrii utiliznd tehnica cluster ............................................... 283
9.6.2. Implementarea agregrii utiliznd tehnica tabelelor imbricate ............................ 284
9.6.3. Implementarea agregrii simple ........................................................................... 286
9.6.4. Implementarea agregrii multi-nivel utiliznd tabele imbricate .......................... 287

Capitolul 10 ...................................................................................................... 289
Baze de date distribuite (BDD) ...................................................................... 289
10.1 Definiie i obiective .................................................................................................. 289
10.1.1 Definiie ............................................................................................................... 289
10.1.2. Obiectivele sistemelor de baze de date distribuite ............................................. 292
10.1.3. Baze de date relaionale distribuite .................................................................... 293
10.1.4 Arhitectura sistemelor de baze de date distribuite .............................................. 294
10.1.5. Controlul concurenei ......................................................................................... 295
10.1.6. Dicionarul (catalogul) Sistemului Distribuit ..................................................... 297
10.2. Niveluri de organizare ............................................................................................... 300
10.3. Interaciunea utilizatorilor cu baze de date distribuite .............................................. 300
10.3.1. Baze de Date Locale - Viziuni locale ................................................................. 300
10.3.2. Baza de date global - Viziuni globale ............................................................... 301
10.4. Criterii de Distribuire a Datelor ................................................................................ 302
10.4.1. Criterii de alegere a distribuiei .......................................................................... 304
10.4.2. Construirea bazei de date distribuite .................................................................. 304
10.5. Criterii de localizare i regsire a datelor .................................................................. 306
10.5.1. Cazuri de distribuie ........................................................................................... 307
10.5.2. Criterii de distribuire i localizare a elementelor ............................................... 307
10.5.3. Optimizarea performanelor ............................................................................... 308
10.6. Implementarea distribuiei n SGBDD comerciale ................................................... 310
10.6.1. Implementarea distribuiei n Oracle .................................................................. 310
10.6.2. Implementarea distribuiei n DB2 ..................................................................... 317

Capitolul 11 ...................................................................................................... 321
Depozite de date ............................................................................................... 321
Cuprins

5
11.1. Prezentare general ................................................................................................... 321
11.1.1. Noiuni de baz .................................................................................................... 321
11.1.2. Obiectivele unui depozit de date .......................................................................... 324
11.2. Arhitectura depozitelor de date ................................................................................. 325
11.3. Obiectele depozitului de date .................................................................................... 329
11.4. Structura depozitelor de date ..................................................................................... 330
11.4.1 Schema stea .......................................................................................................... 331
11.4.2. Schema stea pentru un lan de supermarket-uri .................................................... 332
11.4.3. Schema fulg de zpad ........................................................................................ 333
11.4.4. Schema constelaie de fapte ................................................................................. 334
11.5. Operaii pentru analiza datelor .................................................................................. 335
11.5.1. Interfee de formulare a interogrilor ................................................................... 335
11.5.2. Drill-down i roll-up ............................................................................................ 337
11.5.3. Seciuni i rotaii ................................................................................................ 338
11.5.4. Data cube ............................................................................................................. 338
11.6. Dezvoltarea depozitului de date ................................................................................ 340
11.6.1. Indeci de bitmap i indeci de join ...................................................................... 341
11.6.2. Materializarea view-lor .......................................................................................... 342

Capitolul 12 ...................................................................................................... 343
Data Mining ..................................................................................................... 343
12.1. Introducere n data mining ........................................................................................ 343
12.1.2. Probleme de data mining ........................................................................................ 344
12.2. Numrarea apariiilor concomitente .......................................................................... 347
12.2.1. Seturi de obiecte frecvente ................................................................................... 347
12.2.2. Interogrile iceberg .............................................................................................. 349
12.3. Explorarea pentru descoperirea de reguli .................................................................. 351
12.3.1. Reguli de asociere .............................................................................................. 351
12.3.2. Algoritm pentru gsirea regulilor de asociere ....................................................... 351
12.3.3. Regulile de asociere i ierarhiile ISA ................................................................... 352
12.3.4. Reguli de asociere generalizate .......................................................................... 353
12.3.5. Modele secveniale ............................................................................................. 354
12.3.6. Folosirea regulilor de asociere pentru predicii ..................................................... 354
12.3.7. Relaiile Bayesian ................................................................................................ 355
12.3.8. Reguli de clasificare i regresie ............................................................................ 356
12.4. Reguli structurate sub forma de arbori ...................................................................... 357
12.4.1. Arbori de decizie ................................................................................................ 358
12.4.2. Un algoritm de construire a arborilor de decizie ................................................... 359
12.5. Clusterizarea (gruparea) ............................................................................................ 361
12.5.1. Algoritm de clusterizare ..................................................................................... 362
12.6. Cercetarea similitudinii n cadrul secvenelor ......................................................... 363
12.6.1. Un algoritm pentru gsirea secvenelor similare ................................................ 363
12.7. Perspectivele data mining .......................................................................................... 364

Capitolul 13 ...................................................................................................... 365
Baze de date multidimensionale ..................................................................... 365
13.1. Concepte de baz ....................................................................................................... 365
13.1.1. Conceptul de cub n-dimensional ........................................................................ 366
13.1.2. Conceptul de dimensiune ................................................................................... 367
Cuprins
6
13.1.3. Conceptul de ierarhie ......................................................................................... 368
13.1.4. Conceptul de msur .......................................................................................... 369
13.1.5. Conceptul de multicub ....................................................................................... 369
13.2. Modele de date multidimensionale ........................................................................... 370
13.3. Utilizarea limbajului SQL pentru cereri OLAP. Operatorii ROLLUP i CUBE ...... 375
13.4. Integrarea tehnologiei relaionale cu tehnologia multidimensional ........................ 382
13.4.1. Avantajele unui mediu integrat relaional multidimensional ............................. 389
13.5. Arhitectura sistemelor OLAP .................................................................................... 395
13.5.1. Sisteme ROLAP ................................................................................................. 396
13.5.2. Sisteme MOLAP ................................................................................................ 397
13.5.3. Sisteme hibride (HOLAP) .................................................................................. 398

Capitolul 14 ...................................................................................................... 399
Baze de date spaiale ....................................................................................... 399
14.1. Tipuri de date spaiale ............................................................................................... 399
14.2. Structuri de date pentru reprezentarea i indexarea datelor spaiale ......................... 402
14.3. Exploatarea datelor spaiale ...................................................................................... 409

Capitolul 15 ...................................................................................................... 419
Baze de date multimedia ................................................................................. 419
15.1. Cadrul conceptual ...................................................................................................... 419
15.2. Un model generic al datelor multimedia ................................................................... 420
15.3. Organizarea bazelor de date multimedia ca extensie a celor orientate obiect ........... 422
15.4. Sincronizarea n transferul datelor n timp real ......................................................... 424
15.5. Navigarea i interogarea bazelor de date multimedia ............................................... 424
15.6. Gestiunea i procesarea fluxurilor media n baze de date multimedia ...................... 427

Capitolul 16 ...................................................................................................... 435
Baze de date online .......................................................................................... 435
16.1. Elemente introductive ............................................................................................... 435
16.2. Interfee de acces ....................................................................................................... 437
16.2.1. Pagini Web dinamice ......................................................................................... 437
16.2.2. Pagini dinamice pe partea client ......................................................................... 438
16.2.3. Pagini dinamice generate pe partea server ......................................................... 439
16.3. Limbajul de scripting PHP ........................................................................................ 440
16.4. Limbajul de scripting ASP ........................................................................................ 440
16.4.1. Crearea obiectelor .............................................................................................. 444
16.5. Exemplu de lucru cu baze de date online .................................................................. 445
16.6. Aplicaie demonstrativ ............................................................................................. 447

Bibliografie ....................................................................................................... 459

Contents

7

Contents
Foreword ............................................................................................................ 13

Chapter 1 ............................................................................................................ 15
Elements of Databases Theory ......................................................................... 15
1.1. The Evolution of data organizing .................................................................................. 15
1.2. General characteristics of organizing databases ............................................................ 20
1.3. Concepts used in defining databases ............................................................................. 26
1.3.1. The concept of feature (characteristic) and of family of features .......................... 27
1.3.2. The concept of a data collection ............................................................................. 27
1.4. The concept of databases ............................................................................................... 32
1.5. The concept of databases system .................................................................................. 35
1.6. Centralized and distributed databases ........................................................................... 35
1.7. Levels of organizing data in databases .......................................................................... 36

Chapter 2 ............................................................................................................ 39
Databases Management System ....................................................................... 39
2.1. Defining DBMS ............................................................................................................ 39
2.2. Objectives of a DBMS .................................................................................................. 42
2.3. The functions of a DBMS ............................................................................................. 45
2.4. The architecture of a DBMS ......................................................................................... 47
2.4.1. The architecture of a DBMS in the CODASYL conception .................................. 47
2.4.2. The architecture proposed by the ANSI/SPARC group ......................................... 48
2.4.3. Client/server architecture ....................................................................................... 50
2.4.4. The Oracle DBMS architecture .............................................................................. 51
2.4.4.1. The component architecture of Oracle DBMS .................................................... 53
2.4.4.2. The physical structure of Oracle DB ................................................................... 59

Chapter 3 ............................................................................................................ 61
Databases Administration ................................................................................ 61
3.1. The task of the Dabases Administrator ......................................................................... 61
3.2. Administration functions of databases .......................................................................... 62
3.3. Instruments at the disposal of the databases administrator ........................................... 64
3.4. Databases Protection ..................................................................................................... 64
3.4.1. Ensuring databases integrity ................................................................................... 65
3.4.2. Ensuring databases confidentiality ......................................................................... 66

Chapter 4 ............................................................................................................ 69
Relational databases .......................................................................................... 69
4.1. Domain, attribute, value ................................................................................................ 69
4.2. Relation, tuple ............................................................................................................... 72
4.3. Relations and databases ................................................................................................. 74
4.4. Integrity restrictions ...................................................................................................... 76
Contents
8
4.5. Keys ............................................................................................................................... 77
4.6. Minimal integrity restrictions ........................................................................................ 79
4.7. The relational databases-a formal description ............................................................... 80

Chapter 5 ............................................................................................................ 87
Designing Relational Databases ....................................................................... 87
5.1. Considerations on the conceptual structure and logical structure design of databases . 88
5.2. Databases table normalization ...................................................................................... 96
5.2.1. The concept of normalization ................................................................................. 96
5.2.2. The objective of relations normalization and their necessity ................................. 97
5.2.3. Functional dependencies ........................................................................................ 99
5.2.4. The normal forms one, two and three .................................................................. 102
5.2.5. The Boyce-Codd normal form ............................................................................. 109
5.2.6. The multivalues dependency and the normal form four ......................................... 112
5.2.7. The jonction dependency and the normal form five ............................................ 114
5.2.8. Super normalization. Normalization result .......................................................... 116
5.2.9. The first three normal form algorithmization ....................................................... 117
5.3. The quality of schemes ................................................................................................ 119

Chapter 6 .......................................................................................................... 121
Relational algebra and relational calculus .................................................... 121
6.1. Traditional operations ................................................................................................ 121
6.2. Special relational operations ....................................................................................... 128
6.3. Expressions building in relational algebra .................................................................. 139
6.4. The equivalency of expressions in relational algebra ................................................. 140
6.5. Relational calculus ...................................................................................................... 143
6.5.1. Domain oriented relational calculus ..................................................................... 144
6.5.2. Relational calculus oriented on a rank declared tuple ......................................... 145

Chapter 7 .......................................................................................................... 147
Object Databases ............................................................................................. 147
7.1. The concept of Object-oriented databases .................................................................. 147
7.2. Why object oriented databases? .................................................................................. 147
7.3. Advantages and disadvantages of OODBMSs ............................................................ 149
7.4. Comparing of object oriented model with relational model ....................................... 152
7.5. Alternative strategies for developing on OODBMS ................................................... 154
7.6. The conceptual object data model ............................................................................... 155
7.6.1. Object ................................................................................................................... 155
7.6.2. Object identity ...................................................................................................... 157
7.6.3. Attributes .............................................................................................................. 158
7.6.4. Types and classes ................................................................................................. 160
7.6.5. Methods ................................................................................................................ 168
7.6.6. Incapsulation and interface .................................................................................... 172
7.6.7. Polymorphism ...................................................................................................... 173
7.6.8. Associations ......................................................................................................... 173
7.6.9. Inheritance ............................................................................................................ 180
7.6.10. Generalization and specialization ....................................................................... 181
7.6.11. Aggregation and decomposition ......................................................................... 182
7.7. The ODMG standard for object-oriented databases standard and systems ................. 184
Contents

9
7.7.1. Standards and systems .......................................................................................... 184
7.7.2. The object model .................................................................................................. 185
7.7.3. Object definition language ................................................................................... 185
7.7.4. Object query language .......................................................................................... 190
7.8. Object-oriented DBMSs .............................................................................................. 193
7.8.1. GEMSTOME ....................................................................................................... 193
7.8.2. ONTOS ................................................................................................................. 193
7.8.3. VERSANT ........................................................................................................... 194
7.8.4. ORION ................................................................................................................. 194
7.8.5. ITASCA ............................................................................................................... 195
7.8.6. O2 ......................................................................................................................... 195
7.8.7. Object Store .......................................................................................................... 196
7.8.8. OBJECTIVITY/DB .............................................................................................. 196
7.9. Mandatory features of the object-oriented database systems ...................................... 197
7.10. Unified modeling language support for object-oriented databases ........................... 199
7.10.1. What is UML? .................................................................................................... 199
7.10.2. Components of Unified modeling language ....................................................... 200
7.10.3. Use case diagram ................................................................................................ 202
7.10.4. Class diagram .................................................................................................... 204
7.10.5. Objects diagram .................................................................................................. 207
7.10.6. Sequence diagram ............................................................................................. 207
7.10.7. State diagram ..................................................................................................... 209
7.10.8. Collaboration diagram ........................................................................................ 211
7.10.9. Activity diagram ................................................................................................ 212
7.10.10. Components diagram ....................................................................................... 213
7.10.11. Deployment diagram ....................................................................................... 214
7.10.12. Package diagram .............................................................................................. 214
7.10.13. UML diagrams interaction .............................................................................. 216
7.10.14. UML advantages .............................................................................................. 217
7.11. Object-oriented modeling .......................................................................................... 219
7.11.1. Domain Model .................................................................................................... 219
7.11.2. Business Model .................................................................................................. 220
7.11.3. Use case model ................................................................................................... 222
7.11.4. Static model ....................................................................................................... 224
7.11.5. Dynamic model .................................................................................................. 226
7.12. Object oriented database design as a component of information systems (Case study)
.229
7.12.1. Business model .................................................................................................. 229
7.12.2. Use case model .................................................................................................. 234
7.12.3. Static model ....................................................................................................... 240
7.13. Processes for information system developing according to RUP ............................. 240
7.13.1. Best practices in information system developing ............................................... 241
7.13.2. Outlining RUP .................................................................................................... 243
7.13.3. Identifying requirements .................................................................................... 246
7.13.4. Object oriented analysis ..................................................................................... 248
7.13.5. Object oriented design ........................................................................................ 253

Chapter 8 .......................................................................................................... 259
Object-relational databases The SQL standard ......................................... 259
8.1. The object-relational model ........................................................................................ 259
Contents
10
8.2. The SQl model-a standard for ORDB ......................................................................... 259
8.2.1. New types odf data in SQL3 ................................................................................ 261
8.3. Comparing RDBMS and ORDBMS ........................................................................... 267
8.4. Comparing OODBMS and RODBMS ........................................................................ 268

Chapter 9 .......................................................................................................... 269
Oracle-Object-relational DBMS .................................................................... 269
9.1. Object types ................................................................................................................ 269
9. 2. Object table ................................................................................................................ 274
9.3. REF technique ............................................................................................................. 276
9.4. Inheritance. .................................................................................................................. 278
9.4.1. Inheritance implementation in Oracle prior to version 9i .................................... 278
9.4.2. Inheritance implementation using under clause ............................................... 279
9.4.3. Multiple inheritance ............................................................................................. 279
9. 5. Association relationships............................................................................................ 279
9.6. Aggregation ................................................................................................................. 283
9.6.1. Aggregation implementation using clustering technique ..................................... 283
9.6.2. Aggregation implementation using nested tables ................................................. 284
9.6.3. Simple aggregation implementation .................................................................... 286
9.6.4. Multilevel aggregation implementation using nested tables ................................ 287

Chapter 10 ........................................................................................................ 289
Distributed databases ...................................................................................... 289
10.1 Definition and objectives ........................................................................................... 289
10.1.1 Definition ............................................................................................................ 289
10.1.2. Objectives of distributed databases systems ...................................................... 292
10.1.3. Distributed relational databases ......................................................................... 293
10.1.4 The architecture of distributed databases systems .............................................. 294
10.1.5. Concurrency control ........................................................................................... 295
10.1.6. The distributed system dictionary ...................................................................... 297
10.2. Level of organization ............................................................................................... 300
10.3. Users interaction with distributed databases ............................................................. 300
10.3.1. Local DB-local vision ........................................................................................ 300
10.3.2. Global DB-global vision .................................................................................... 301
10.4. Criteria for data distribution ...................................................................................... 302
10.4.1. Criteria for distribution choice ........................................................................... 304
10.4.2. Distributed database design ................................................................................ 304
10.5. Local criteria for data refinding ................................................................................ 306
10.5.1. Cases of distribution ........................................................................................... 307
10.5.2. Criteria for elements distributing and locating ................................................... 307
10.5.3. Optimizing performances ................................................................................... 308
10.6. Implementing distribution in commercial DDBMS .................................................. 310
10.6.1. Distribution implementation in Oracle ............................................................... 310
10.6.2. Distribution implementation in DB2 .................................................................. 317

Chapter 11 ........................................................................................................ 321
Data warehouses ............................................................................................. 321
11.1. General presentation .................................................................................................. 321
11.1.1. Bsic terms ............................................................................................................ 321
Contents

11
11.1.2. Data warehouse objectives ................................................................................... 324
11.2. Data warehouse architecture ..................................................................................... 325
11.3. Data warehouse component objects .......................................................................... 329
11.4. data warehouse structure ........................................................................................... 330
11.4.1 Star schema .......................................................................................................... 331
11.4.2. Star schema for a supermarket chain .................................................................... 332
11.4.3. Snowflake schema ............................................................................................... 333
11.4.4. Fact constellation schema .................................................................................... 334
11.5. Data analysis operations ............................................................................................ 335
11.5.1. Query formulation interfaces ............................................................................... 335
11.5.2. Drill-down and roll-up ......................................................................................... 337
11.5.3. Sections and rotations......................................................................................... 338
11.5.4. Data cube ............................................................................................................. 338
11.6. Data warehouse development .................................................................................... 340
11.6.1. Bitmap indexes and join indexes .......................................................................... 341
11.6.2. Materialized views ............................................................................................. 342

Chapter 12 ........................................................................................................ 343
Data Mining ..................................................................................................... 343
12.1. Introduction in data mining ....................................................................................... 343
12.1.2. Data mining problems ............................................................................................ 344
12.2. Simultaneous occurences counting ........................................................................... 347
12.2.1. Frequent item sets ................................................................................................ 347
12.2.2. Iceberg queries .................................................................................................... 349
12.3. Mining for discovering rules ..................................................................................... 351
12.3.1. Association rules ................................................................................................ 351
12.3.2. Association rule discovery algorithm ................................................................... 351
12.3.3. Association rules and ISA hierarchies .................................................................. 352
12.3.4. Generalized association rules ............................................................................. 353
12.3.5. Sequential models .............................................................................................. 354
12.3.6. Association rules for predictions ......................................................................... 354
12.3.7. Bayesian rules...................................................................................................... 355
12.3.8. Classification and regression rules ....................................................................... 356
12.4. Tree structured rules .................................................................................................. 357
12.4.1. Decision trees ..................................................................................................... 358
12.4.2. Decision trees construction algorithm .................................................................. 359
12.5. Clustering .................................................................................................................. 361
12.5.1. Clustering algorithm .......................................................................................... 362
12.6. Similarity search in sequences ................................................................................ 363
12.6.1. Similarity sequences search algorithm ............................................................... 363
12.7. Data mining future .................................................................................................... 364

Chapter 13 ........................................................................................................ 365
Multidimensional databases ........................................................................... 365
13.1. Main concepts ........................................................................................................... 365
13.1.1. Hypercube .......................................................................................................... 366
13.1.2. Dimension .......................................................................................................... 367
13.1.3. Hierarchy ............................................................................................................ 368
13.1.4. Measure .............................................................................................................. 369
13.1.5. Multi-cube .......................................................................................................... 369
Contents
12
13.2. Multidimensional data models .................................................................................. 370
13.3. OLAP queries with SQL. ROLLUP and CUBE ....................................................... 375
13.4. Integrating relational technology with multidimensional technology ....................... 382
13.4.1. Advantages of a relational multidimensional integrated environment ............... 389
13.5. OLAP systems architecture ....................................................................................... 395
13.5.1. ROLAP systems ................................................................................................. 396
13.5.2. MOLAP systems ................................................................................................ 397
13.5.3. HOLAP systems ................................................................................................. 398

Chapter 14 ........................................................................................................ 399
Spatial databases ............................................................................................. 399
14.1. Types of spatial data .................................................................................................. 399
14.2. Data structured for representing and indexing spatial data ....................................... 402
14.3. Spatial data exploitation ............................................................................................ 409

Chapter 15 ........................................................................................................ 419
Multimedia databases ..................................................................................... 419
15.1. Conceptual framework .............................................................................................. 419
15.2. A generic model of multimedia data ......................................................................... 420
15.3. Organizing multimedia databases as an extension of object-oriented databases ...... 422
15.4. Real time data transfer synchronization .................................................................... 424
15.5. Multimedia databases interogation and navigation .................................................. 424
15.6. The management and the processing of media flows in multimedia databases ........ 427

Chapter 16 ........................................................................................................ 435
Online Databases ............................................................................................. 435
16.1. Introduction ............................................................................................................... 435
16.2. Acess interfaces ......................................................................................................... 437
16.2.1. Dynamic Web pages ........................................................................................... 437
16.2.2. Client-side scripting ........................................................................................... 438
16.2.3. Server-side scripting ........................................................................................... 439
16.3. PHP scripting language ............................................................................................. 440
16.4. ASP scripting language ............................................................................................. 440
16.4.1. Object creation .................................................................................................. 444
16.5. Example of using online databases ........................................................................... 445
16.6. Demo application ...................................................................................................... 447

Bibliography ..................................................................................................... 459

13

Prefa

Plecnd de la ideea c orice sistem, subsistem sau aplicaie informatic, ce implic
lucrul cu volume mari de date, face apel la un mod sau altul de organizare a datelor i c de
modul de organizare a datelor depinde n mare msur performanele soluiei informatice. n
acest context, n prezenta lucrare autorii trateaz problematica bazelor de date ca form
superioar de organizare a datelor.
Lucrarea ncepe prin prezentarea evoluiei organizrii datelor plecnd de la formele
cele mai simple pn la cele mai complexe i de actualitate. Sunt expuse cele dou mari grupe
de moduri de organizare a datelor i anume, n fiiere i n baze de date. n prima grup, se
recurge la o sumar prezentare a organizrii datelor n fiiere secveniale, secveniale
indexate, fiiere cu organizare direct, relativ, partiionate, multiindexate (multiliste sau
multichei), inverse i fiiere integrate ca form intermediar de trecere la baze de date.
Autorii au apreciat ca fiind de interes i prezentarea organizrii datelor n fiiere dintr-
o serie de considerente de ordin teoretic i practic. Pe de o parte, unele metode i tehnici de
organizare, acces i regsire a datelor folosite n lucrul cu fiiere sunt ntlnite i implementate
i n tehnologia utilizrii bazelor de date. Totodat, prin prezentarea diverselor tehnici i
metode amintite, sporete iniiativa i intuiia analitilor i programatorilor de a descoperi noi
metode sau a le perfeciona pe cele existente. Mai mult, unele moduri de organizare a datelor
n fiiere nc se mai folosesc cu mare succes pentru anumite aplicaii.
n ceea ce privete cea de a doua grup de moduri de organizare a datelor, autorii
recurg la prezentarea bazelor de date ca forme superioare i mai performante de organizare a
datelor i anume: baze de date relaionale, obiectuale, obiectual-relaionale, multimedia,
spaiale, bazele de date distribuite, multidimensionale, depozitele de date i bazele de date on-
line (baze de date Web).
Lucrarea este realizat ntr-o abordare gradat a problematicii de referin n sensul c
se pornete de la prezentarea organizrii datelor n fiiere, apoi se trece la prezentarea ntr-o
form original a succesiunii logice a conceptelor ce concur la definirea bazei de date. Se
continu cu tratarea specificului, avantajelor i dezavantajelor bazelor de date relaionale
comparativ cu organizarea datelor n fiiere. Urmeaz bazele de date orientate obiect cu
precizarea specificului lor, avantajelor i dezavantajelor acestora comparativ cu bazele de date
relaionale. innd seama de avantajele i dezavantajele celor dou modele de date, relaional
i obiectual, prin preluarea a ceea ce este mai bun de la fiecare s-a ajuns la modelul de baze de
date obiectual- relaional. Bazele de date multimedia i spaiale sunt considerate i tratate ca
extensii ale modelelor relaional i obiectual. n mod asemntor, se continu cu celelalte
tipuri de baze de date ca fiind extensii ale precedentelor moduri de organizare. Totodat, pe
parcursul ntregii lucrri se recurge la exemplificri, scheme i imagini sugestive. Apreciem
c acest mod de prezentare ofer cititorului faciliti sub aspectele parcurgerii, nelegerii i
nsuirii problematicii abordate. Un spaiu larg este rezervat precizrilor referitoare la
proiectarea i implementarea diferitelor modele de date. Se definesc etapele de urmat i
problemele de rezolvat.
Avnd n vedere domeniul nelimitat de utilizare a bazelor de date i interesul crescnd
pentru acest mod de organizare a datelor, apreciem c lucrarea poate fi de un real folos
elevilor, studenilor, profesionitilor IT, cum ar fi analiti sau proiectani de sisteme

14
informatice, programatori de aplicaii, ingineri de sistem i altor categorii de persoane
interesate n iniierea lucrului cu baze de date.
innd seama de sfera larg a problematicii bazelor de date abordate, suntem convini
de faptul c lucrarea este vulnerabil fa de strecurarea unor erori, omisiuni, confuzii sau
nenelegerea corect a anumitor aspecte, motiv pentru care ne cerem scuze i totodat
aducem mulumiri tuturor celor crora timpul i amabilitatea le va permite s ne transmit
observaii, critici sau eventuale sugestii n ideea unei posibile reeditri.

Autorii

Elemente de teoria bazelor de date

15

Capitolul 1

1.1. Evoluia organizrii datelor

Este cunoscut faptul c orice sistem, subsistem sau aplicaie informatic ce implic un
volum sporit de date, face apel la un mod sau altul de organizare a datelor.
Prin organizarea datelor vom nelege definirea, structurarea, ordonarea i gruparea
datelor n colecii de date, precum i stabilirea legturilor ntre acestea i n cadrul elementelor
coleciei de date.
Organizarea datelor a cunoscut o evoluie marcant n timp, att sub aspect teoretic ct
i practic, extinzndu-se mult gama principiilor i metodelor de structurare, stocare, regsire i
gestiune a datelor, n concordan cu progresul din domeniile hardware i software ct i cu
exigenele tot mai ridicate i diversificate ale utilizatorilor.
Evoluia organizrii datelor a nsemnat un salt calitativ sub aspectul flexibilitii n
exploatare, a timpului de acces, a spaiului de memorie, a proteciei datelor etc.
n evoluia organizrii datelor pot fi marcate anumite aspecte eseniale care au permis
realizarea salturilor calitative, acestea urmnd a fi evideniate pe etape.
Prima etap se refer la perioada dinainte de apariia calculatoarelor din generaia a 3-a
(primul calculator din generaia a 3-a a fost instalat n anul 1965) i se caracterizeaz prin
urmtoarele aspecte:
datele erau organizate n fiiere secveniale,
structura logic coincidea cu structura fizic (figura 1.1) iar programatorul trebuia
s descrie i organizarea fizic a datelor pe suport.

Fig. 1.1 Etapa I-a de organizare a datelor
OPERAII DE I/E
{SOFTWARE}
ORGANIZARE LOGIC ORGANIZARE FIZIC
Capitolul 1
16
nu se asigur independena programelor fa de organizarea datelor; modificarea
structurii datelor sau a dispozitivului de memorare implic i rescrierea
programelor, recompilarea i testarea acestora n noile condiii;
redundana mare ntre fiiere, deoarece acestea erau dedicate aplicaiilor, chiar
dac unele date se regseau n mai multe fiiere;
software-ul realiza numai operaii simple de intrare/ieire.

Etapa a II-a este marcat de apariia dispozitivelor de memorare n acces direct (discuri
magnetice) care permit att accesul secvenial ct i direct la nregistrrile unui fiier (figura
1.2.).

Fig. 1.2. Etapa A-II de organizare a datelor

Aceast etap se caracterizeaz prin:
datele erau organizate sub forma unor fiiere secveniale, indexat-secveniale,
directe i prelucrarea se fcea n batch, on-line sau n timp real;
structura logic nu mai coincide cu structura fizic ca n prima etap, iar
organizarea fizic pe suport nu mai este fcut de programator, ci este realizat de
componente specializate ale sistemului de operare aa numitele metode de acces;
se asigur independena programelor fa de unitatea de memorare (schimbarea
unitii de memorare nu implic modificarea programelor);
se menine totui un grad de redundan ridicat;
accesul se face la nivel de nregistrare i nu de cmp n cadrul nregistrrii;
nu se realiza accesul dup chei multiple;
dac programatorul dorea realizarea unor fiiere cu legturi trebuia s-i
programeze legturile.

Etapa a III-a a nceput prin anii 1970 i este marcat de apariia bazelor de date (figura
1.3.). Elementele noi care apar n aceast etap fa de precedente sunt:
existena unui fond comun de date, pentru mai multe aplicaii (baza de date), a
crui organizare fizic este independent de programele de aplicaii;
constituirea unor fiiere logice, funcie de necesiti, plecnd de la baza de date;
accesul la date se face la nivel de cmp, sau grup;
scade redundana, i este permis accesul dup chei multiple;
existena unor msuri de protecie i securitate a datelor;

ACCES

17
organizarea datelor este realizat de o component a software, cunoscut sub
numele de data management.

Fig. 1.3. Etapa a III-a de organizare a datelor

Etapa a IV-a se caracterizeaz n primul rnd prin asigurarea independenei logice i
fizice a datelor fa de programele de aplicaie (figura 1.4.).

Fig. 1.4. Etapa a IV-a de organizare a datelor

Independena logic se realizeaz prin intermediul unui al 3-lea nivel de descriere a
datelor (nivelul logic global) care se afl sub controlul administratorului bazei de date.
Administratorul bazei de date nu trebuie confundat cu proprietarul datelor. El definete
ORGANIZARE LOGICA ORGANIZARE FIZIC
GESTIUNEA DATELOR (data management)
Capitolul 1
18
structura nregistrrilor din baza de date, dar nu are acces la coninutul acestora, lucru permis
numai proprietarului datelor. Orice modificare a structurii datelor se solicit de proprietar,
administratorul bazei, singurul autorizat s fac acest lucru.
Alte caracteristici ale etapei a IV-a sunt:
crete gradul de protecie i securitate a datelor;
existena unor fiiere inverse, care permit rspunsul rapid la anumite ntrebri
formulate de utilizatori;
existena unor limbaje de specialitate de: descriere, manipulare i interogare a
bazei de date, precum i pentru administrator.
O prezentare mai analitic a evoluiei modurilor de organizare a datelor este redat n
figura 1.5. unde semnificaia notaiilor este:

- - FS
- - FSI
- - FR
- - FOD
- - FP
- - FMI
- - FINV
- - FINT
- - BDA
- - BDSR
- - BDR
- - BDOO
- - BDMM
- - BDSP
- - DD
- - DM
- - BDMD
- - BDWEB
- - *
-
fiiere cu organizarea secvenial,
fiiere secvenial indexate,
fiiere cu organizare relativ,
fiiere cu organizare direct,
fiiere partiionate,
fiiere multiindexate,
fiiere inverse,
fiiere integrate,
baze de date arborescente sau ierarhice,
baze de date cu structuri de tip reea,
baze de date relaionale,
baze de date orientate obiect,
baze de date multimedia,
baze de date spaiale,
depozite de date (Data Warehouse),
Data Mining,
baze de date multidimensionale,
baze de date WEB (BD on-line)
mai exist i alte tipuri de baze de date, dintre care cele mai
semnificative sunt cele distribuite

Analiznd evoluia organizrii datelor conform celor prezentate n figura 1.5 pot fi
desprinse o serie de concluzii, astfel:
Exist dou mari grupe de moduri de organizare a datelor i anume: organizarea
datelor n fiiere i respectiv n baze de date;
Att fiierele ct i bazele de date pot fi de mai multe tipuri;
Un anumit mod de organizare a datelor nu exclude precedentele moduri de
organizare, astfel nct n prezent se recurge att la organizarea datelor n fiiere
ct i n baze de date, cu anumite excepii innd seama de faptul c anumit tipuri
de fiiere sau baze de date nu se mai folosesc sau se folosesc foarte rar (ex. FP,
FMI, FINV, FINT, BDA i BDSR). De remarcat faptul c dei anumite tipuri de
fiiere, cum ar fi FMI, FINV, FINT, nu se mai folosesc ns fundamentul teoretic
i filozofia ce st la baza acestora o regsim implementat la nivelul bazelor de
date.

Fig. 1.5. Evoluia organizrii datelor

Nivel calitativ

BDMM

FS FSI FR FOD FP FINV FMI FINT
BDA BDSR BDR BDOO BDSP DD DM BD WEB
Fiiere Baze de date
Nivelul 1
Nivelul 2
Nivelul 3
Nivelul 4
Nivelul 5

BDMD
Capitolul 1

20
Fiecare mod de organizare a datelor prezint avantaje i dezavantaje. n general
prin nlturarea unor dezavantaje s-a reuit un salt calitativ ajungndu-se astfel la
un alt mod de organizare a datelor;
Nu se poate face o delimitare exact n timp a momentului apariiei sau dispariiei
unui anumit mod de organizare a datelor;
BDMM i BDSP sunt considerate ca extensii ale modelelor relaional i obiectual;
Actualmente BDR dein ponderea mare n domeniul aplicaiilor economice nsui
tendina este spre extinderea BDOO.

1.2. Caracteristici generale a organizrii datelor n
fiiere

n cele ce urmeaz vom recurge la o evideniere a celor mai semnificative aspecte
referitoare la modul de organizare a datelor n fiiere.

Definiia fiierului: un fiier reprezint o colecie de date omogene stocate pe un suport
de memorie extern.

Un fiier conine o multitudine de nregistrri referitoare la un anumit domeniu de
preocupare. Exemplul, informaiile referitoare la Furnizori pot fi organizate ntr-un fiier, iar
datele referitoare la un furnizor vor forma o nregistrare.
nregistrrile pot fi privite la nivel logic i respectiv fizic. De aici se poate desprinde i o
prim concluzie i anume c, n situaia organizrii datelor n fiiere avem de a face cu dou
niveluri de referin i anume nivelul logic i respectiv nivelul fizic.
Nivelul logic sugereaz gndirea analistului proiectantului cu privire la modul de
organizare a datelor. Nivelului logic i corespunde structura logic a fiierului.
Prin structura logic se precizeaz denumirile de atribute/cmpuri cu privire la
caracteristicile obiectelor ce urmeaz a fi organizate i stocate n fiiere.
Nivelul fizic sugereaz suportul tehnic de memorie extern pe care vor fi stocate datele.
Nivelului fizic i corespunde structura fizic a fiierului i reflect modalitatea concret n
care vor fi stocate datele. Se spune ca avem de a face cu proiectarea spaiului logic pe spaiul
fizic. De remarcat faptul c structura logic a descrierii datelor nu coincide cu structura fizic.
La nivelul fizic o nregistrare conine pe lng datele efective descrise la nivelul logic i o
serie de alte informaii auxiliare asociate fiecrei nregistrri.
O alt caracteristic a fiierelor o constituie faptul c ele prezint un grad sporit de
redundan a datelor, ceea ce afecteaz performanele de ordin fizic a acestora cu privire la
spaiul de memorie i timpului necesar actualizrilor i prelucrrii lor pe ansamblul sistemului
informatic ce face apel la organizarea datelor n fiiere.
n cele ce urmeaz vom recurge la o sumar prezentare a diferitelor tipuri de fiiere.

a) Fiierele cu organizare secvenial prezint particularitatea nregistrrilor ce vor fi
stocate pe suportul de memorie extern n succesiunea n care ele apar la intrare.
Totui, nregistrrile pot fi sortate/ordonate cresctor sau descresctor dup valorile
asociate unei anumite caracteristici/cmp atribut din structura logic a nregistrrii.
Fiierele cu organizare secvenial prezint avantaje i respectiv dezavantaje. Ca
avantaje precizm:

21
pot fi organizate pe orice tip de suport de memorie extern,
ocup foarte bine spaiul de memorie extern.
Ca dezavantaj am putea preciza faptul c ofer doar accesul secvenial la nregistrri.

b) Fiiere cu organizare secvenial indexate.
Fiierele cu organizare secvenial indexate pot fi organizate numai pe discuri magnetice.
Ele ofer accesul la nregistrri att secvenial ct i direct pe baz de indeci. Indexarea se va
face dup cheia principal/primar a nregistrrii.
ntr-o astfel de situaie fiierele cu organizare secveniale indexate presupun existena a
dou tipuri de fiiere, i anume:
un fiier principal sau de baz i
un fiier auxiliar care mai poart denumirea de fiier de indeci sau tabel
directoare.
Fiierul principal va conine multitudinea nregistrrilor de date efective despre
colectivitatea de referin (ex. despre furnizori), fiind ordonate cresctor dup valorile
asociate atributului cu semnificaie de cheie primar (exemplu codul furnizorului).
Fiierul de indeci (la baza de date l vom regsi cu denumirea de Tabel de indeci)
conine indeci n funcie de care se va realiza accesul direct la nregistrrile coninute de
fiierul principal.
Un fiier secvenial indexat poate fi asociat cu o carte obinuit, unde cuprinsul crii ce
conine capitolele i paragrafele cu precizarea paginilor la care se regsesc n carte iar paginile
numerotate ar reprezenta fiierul principal.

c) Fiiere cu organizare relativ
Fiierele cu organizare relativ prezint dou particulariti i anume, pe de o parte,
faptul c nregistrrile sunt reinute pe spaiul de memorie extern n succesiunea n care se
prezint la intrare (deci secvenial) iar, pe de alt parte, nregistrrile sunt numerotate de ctre
sistem, n ordine cresctoare de la 1. n acest mod fiecare nregistrarea va avea un numr de
nregistrare.
Accesul la nregistrrile fiierului poate fi secvenial sau pe baza numrului de realizare.

d) Fiiere cu organizare direct
Specificul fiierelor cu organizare direct const n faptul c nregistrrile vor fi stocate
pe suportul de memorie extern (disc magnetic) pe baza unui algoritm de randomizare, prin
care se va determina adresa fizic a fiecrei nregistrri ce urmeaz a fi stocat.
Numrul algoritmilor de randomizare este nelimitat, fiecare programator i poate defini
propriul su algoritm de randomizare. Un exemplu de algoritm de randomizare ar putea fi de
forma:

unde:
KP
i
semnific valoarea cheii primare a nregistrrii i,
NP reprezint un numr prim prestabilit de ctre programator,
rest va reprezenta adresa fizic a nregistrrii i.

n concordan cu aplicarea unui astfel de algoritm fiecare nregistrare va avea o adres
fizic prestabilit, indiferent de succesiunea nregistrrilor la intrare.
Capitolul 1

22
De remarcat faptul c pentru accesarea (regsirea) nregistrrilor din fiier se aplic
acelai algoritm de randomizare folosit la crearea fiierului.

e) Fiiere partiionate
Fiierele partiionate erau folosite pentru lucru cu volume reduse de date precum i
pentru lucru cu biblioteci de programe catalogate. Actualmente fiierele partiionate mai pot fi
ntlnite doar pentru lucru cu biblioteci de programe.
Un fiier partiionat este format din dou tipuri de fiiere i anume:
fiiere de baz stocate sub form de partiii (fiecare fiier de baz apare ca o
partiie),
un fiier auxiliar care mai poart denumirea de Tabel directoare ce conine
adresa fizic a fiecrei partiii.
ntr-o form sugestiv un fiier partiionat poate fi redat precum n figura 1.6.

Tabela directoare
Adresa partiiilor A B C D

Partiia A
Partiia B Partiia C
Partiia D

Spaiu liber

Fig. 1.6. Forma unui fiier partiionat

Fiierele partiionate ofer avantajul c permit reducerea timpului de prelucrare a
datelor pe ansamblu, ca urmare a faptului c descrierea nu se realizeaz la nivelul fiecrei
partiii (fiier) ci concomitent (o singur dat) pentru toate partiiile la nivelul Tabelei
directoare.

f) Fiiere multiindexate
Fiierele multiindexate ofer accesul la nregistrri dup mai multe chei secundare de
regsire.
O cheie secundar se definete de forma:

unde,
- reprezint cheia secundar de regsire,
- reprezint un atribut ce face parte din structura nregistrrii logice,
- valoarea asociat atributului A n funcie de care se definete cheia secundar.

Exemple de chei secundare de regsire ar putea fi:
s se defineasc o cheie secundar de regsire a tuturor studenilor Bucureteni:
Bucuretean = Domiciliu Bucureti

23
s se defineasc o cheie secundar de regsire a tuturor angajailor dintr-o societate
comercial ce au profesia ECONOMIST.
Cheile secundare de regsire se definesc pentru a da un rspuns facil i a spori viteza de
rspuns la ntrebri prestabilite cu o frecven mare de apariie.
Un fiier multiindexat este format din dou tipuri de fiiere i anume:
fiierul principal sau de baz,
un fiier auxiliar sau tabel directoare.
Fiierul principal apare ca un fiier secvenial ns cu nregistrrile sortate n ordine
urmtoare dup valorile cheii primare. Totodat fiecare nregistrare conine pe lng datele
propriu-zise i dou zone de memorie n care se va stoca adresa urmtoarei respectiv adresa
precedentei nregistrri ce face parte din aceiai list. n acest mod la nivelul fiierului pentru
fiecare cheie secundar de acces se genereaz cte o list dublu ntlnit.
Exemplu, pentru o societate comercial ce are un numr considerabil de mare de
angajai, o list ar putea nsemna nlnuirea nregistrrilor corespunztoare tuturor angajailor
ce au profesia economist.
Fiierul auxiliar sau tabela directoare va conine cte o nregistrare pentru fiecare cheie
secundar de regsire, ce va conine la rndul ei denumirea cheii secundare de regsire i
adresa primei nregistrri din fiierul de baz ce face parte din list. Pentru exemplul anterior
nregistrarea din tabela directoare ar conine denumirea cheii ca fiind Economist iar adresa
primei nregistrri din fiierul de baz ce face parte din aceiai list va fi marca primului
angajat ce are profesia Economist.
Datorit faptului c n tabela directoare pot fi definite multiple chei secundare de
regsire cu indexul corespunztor iar n fiierul principal pentru fiecare index se va genera
cte o list de nregistrri, nseamn c vom avea de a face cu multiple chei secundare,
multipli indeci i respectiv n fiierul de baz multiple liste.
Deci, cte chei atia indeci ci indeci attea liste. Tocmai de aici rezult i faptul c
fiierele multiindexate mai poart denumirea de fiiere multichei sau multiliste. In mod
sugestiv, un fiier multiindexat este redat ca form n figura 1.7.

Tabela directoare Fiierul de baz

Fig. 1.7. Fiiere multiindexate

K
1
= 100
K
2
= 105
K
3
= 105
K
4
= 100
.
.
.
.
K
n
=1000
100
K
1
= 102
K
4
= 107
K
1
= 104
102
104
K
1
= *
105
106 107
K
2
= 125
K
3
= . . .
K
4
= 126
120 125 126
K
2
= 1110 K
4
= *

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1000 1001 1110
K
2
= *

K
n
= *

K
n
= 1001

Capitolul 1

24
unde:
fiecare nregistrare din fiierul de baz este sugerat printr-un dreptunghi,
numrul de deasupra dreptunghiului reprezint valoarea cheii primare a
nregistrrii (cheia primar putnd fi de exemplu marca salariatului),
K
1
ar putea fi economist cu lista corespunztoare din fiierul de baz ce ar
include salariaii ce au marca {100, 101, 104},
K
2
ar putea fi strungar cu lista corespunztoare tuturor salariailor ce au profesia
strungar, cu mrcile {105, 125, 1110},
K
3
ar putea fi toxicitate cu lista corespunztoare tuturor salariailor ce lucreaz
n mediu toxic i au marca {105, } etc.,
se observ c anumite nregistrri particip doar la o singur list {1000, 1001},
altele particip la formarea mai multor liste {100, 105}, situaie cum ar fi cazul n
care salariatul are profesia strungar i lucreaz n mediu toxic i situaia n care
anumite nregistrri nu particip la formarea nici unei liste. Astfel de nregistrri ce
nu se regsesc n nici o list nu nseamn c nu se justific s fie pstrate n fiier,
ele pot fi necesare pentru informri de alt tip ce nu implic regsirea dup chei
secundare.
Exploatarea unui fiier multiindexat poate fi realizat n serie i n paralel a listelor de
nregistrri.
Exploatarea n serie presupune urmtoarea succesiune logic de operaii. Cu cheia
secundar ce prezint interes se intr n Tabela directoare i se identific adresa primei
nregistrri din fiierul de baz ce ndeplinete condiia predefinit prin cheia secundar. Cu
cheia astfel identificat se intr cu acces direct n fiierul de baz i se determin prima
nregistrare, care apoi va fi prelucrat sau afiat. Din nregistrarea curent se va prelua adresa
urmtoarei nregistrri ce face parte din aceiai list, cu care apoi se intr din nou n fiierul de
baz cu acces direct i va fi regsit a doua nregistrare etc.
Exploatarea listelor n paralel presupune exploatarea concomitent a listelor dup dou
sau mai multe criterii secundare de regsire. De exemplu, listarea tuturor salariailor ce au
profesia strungar i lucreaz n mediu toxic. ntr-o astfel de situaie exist i algoritmi de
optimizare a parcurgerii listelor.

g) Fiiere cu organizare invers
Fiierele cu organizare invers ofer i ele succesul la nregistrri dup mai multe chei
secundare de regsire. Cheile secundare de regsire avnd aceeai semnificaie precum n
cazul fiierelor cu organizare multiindexat.
Un fiier cu organizare invers la fel ca i n cazul precedent este format din dou tipuri
de fiiere, un fiier principal sau de baz i unul secundar (figura 1.8).
Fiierul principal apare ca un fiier obinuit secvenial cu nregistrri sortate sau
nesortate.
Fiierul secundar este format dintr-un ir de bii, cte un bit corespunztor fiecrei
nregistrri din fiierul principal.
Pentru fiecare cheie secundar de regsire se genereaz cte un astfel de ir de bii.
Iniial toi biii sunt incrementai cu valoarea zero. Ulterior, cu ocazia ncrcrii
fiierului principal cu nregistrri se va testa dac nregistrarea curent ndeplinete sau nu
condiia prestabilit prin specificarea cheii secundare de regsire. Dac da, bitul corespunztor
nregistrrii curente va fi poziionat pe 1, altfel va rmne pe zero.
Exploatarea unui fiier cu organizare invers se va face astfel: se activeaz irul de bii
apoi se procedeaz la explorarea acestuia n mod secvenial.

25
n momentul n care a fost identificat un bit avnd valoarea 1 se va recurge la
determinarea cardinalitii acestuia (al ctelea bit este n cadrul irului de bii).

MARCA NUME PROFESIA DOMICIULIUL
STABIL

111
130
140
152
153
154
160
DAN
ION
RADU
PETRE
ION
VASILE
DAN
EC
ING
MEDIC
EC
EC
TURIST
EC
BUC
PL
BUC
BUC
BUFTEA
SNAGOV
BUC

Fiier secundar
ECONOMIST 1 0 0 1 1 0 1
BUCURESTEAN 1 0 1 1 0 0 1

Fig. 1.8. Fiiere inverse

Pe baza cardinalitii bitului se va proceda la determinarea adresei relative a nregistrrii
din fiierul principal corespunztoare bitului curent, conform urmtoarei formule:

unde:
AR
i
este adresa relativ a nregistrrii corespunztoare cardinalitii bitului curent,
A
0
reprezint adresa relativ de la care ncepe ncrcarea fiierului principal,
D reprezint deplasarea (lungimea nregistrrii),
N
i
reprezint cardinalitatea bitului.

Cu adresa astfel determinat se va intra cu acces direct n fiierul de baz/ principal
unde va fi identificat nregistrarea solicitat care va fi prelucrat sau listat. Apoi, procesul
de explorare a irului de bii va continua n acelai mod.
Marele avantaj a folosirii fiierelor inverse l constituie faptul c, pe lng posibilitatea
accesului la nregistrri dup mai multe chei de regsire, ele ofer i o vitez mare de rspuns
la cererile utilizatorilor datorit faptului c accesul la nregistrri pe baz de adres relativ
este cel mai performant.

h) Fiiere integrate
Fiierele integrate mai poart denumirea de fiiere cu legturi. Particularitatea acestora
const n faptul c structura datelor era separat de datele efective. Structura era definit i
stocat ntr-un fiier ce purta denumirea de dicionar iar datele efective asociate structurii erau
memorate n fiier separate. Totodat, ntre fiierele de date se puteau defini legturi. Tocmai
de la aceast particularitate, fiierele integrate mai purtau denumirea de fiiere nlnuite iar
pentru gestiunea acestora existau pachete software speciale, cum ar fi BOMP, PICS, SCF etc.
Fiierele integrate marcheaz, prin particularitile acestora, trecerea de la modelul de
organizare a datelor n fiiere la modelul bazelor de date.
Remarc. Motivele pentru care s-a recurs la prezentarea organizrii datelor n fiiere
sunt dou i anume:
timp

Capitolul 1

26
- anumite moduri de organizare a datelor n fiiere nc sunt de actualitate n sensul c
se mai folosesc,
- filozofia i anumite tehnici de organizare a datelor n fiiere, cum ar fi organizarea
datelor n fiiere relative, multiindexate, inverse i integrate le regsim implementate i la
nivelul Bazelor de date.

1.3. Concepte utilizate n definirea bazelor de date

Aa dup cum s-a mai precizat anterior, orice sistem, subsistem sau aplicaie
informatic ce implic lucrul cu volume mari de date face apel la un mod sau altul de
organizare a datelor pe un anumit suport de memorie extern. De modul de organizare a
datelor depinde n mare msur performanele sistemului sub aspectele satisfacerii
completitudinii cerinelor informaionale ale utilizatorilor, vitezei de rspuns a sistemului la
solicitrile utilizatorilor, facilitilor de stocare, actualizare i exploatare a datelor etc.
In cadrul modurilor de organizare a datelor, bazele de date reprezint forma cea mai
performant de organizare a datelor, satisfcnd cerinele amintite. Chiar mai mult, ele
contribuie la simplificarea i raionalizarea circuitelor i fluxurilor informaionale prin faptul
c bazele de date apar ca o surs unic de informare la care vin datele din toate direciile i
pleac informaiile ctre toi utilizatorii .
In acest context, n cele ce urmeaz ne propunem s prezentm conceptele care duc la
definirea bazei de date, precum i o serie de alte aspecte legate de baze de date.
n elucidarea conceptului de baz de date considerm necesar a se pleca de la
abordarea ntr-o succesiune logic a elementelor ce concur la definirea acestui concept.
Astfel se va pleca de la definirea conceptelor de caracteristic, familie de caracteristici,
proprieti i relaii dintre acestea, colecie de date i baze de date. n figura 1.9 se sugereaz
succesiunea logic de abordare a acestor elemente.

Fig. 1.9. Succesiunea logic a elementelor ce concur la definirea conceptului
de baze de date


27
1.3.1.Conceptul de caracteristic i familie de caracteristici

Descrierea mulimii entitilor reale sau abstracte ale unui domeniu semantic se
realizeaz cu ajutorul unei serii de caracteristici ( ) n i C
i
, 1 , = . n acest context caracteristica
definete un aspect sau o latur a unui obiect din mulimea respectiv. Deci, caracteristica la
modul general are semnificaia de atribut sau cmp prin care se descriu obiectele din mediul
nconjurtor.
O mulime de caracteristici formeaz o familie de caracteristici A i se noteaz astfel:
{ } N i C
i
e = A

Exemplu:
PERSOANA={NUME_PRENUME, SEX, STARE_CIVIL, FUNCIE, ADRESA,.}
unde, fiecare element dintre acolade reprezint o caracteristic ce concur la descrierea unei
PERSOANE.

Elementele unei caracteristici sunt valorile(datele) corespunztoare acesteia. Fiecrei
caracteristici C i se asociaz o mulime de valori x
i
, mulime notat cu X i care constituie
domeniul de valori pentru acea caracteristic. Familia avnd n caracteristici vor exista n
mulimi de valori i deci n domenii.

Exemplu:
CULOARE-AUTOMOBIL ={rou, alb, galben,, portocaliu}

unde, CULOARE-AUTOMOBIL are semnificaia de caracteristic a automobilului
(constituant) iar culorile rou, alb, galben, . reprezint date/valori fcnd parte din
domeniul culorilor. La modul general, domeniul culorilor va conine ca valori multitudinea
culorilor din paleta de culori.
De remarcat faptul c, pot exista frecvente situaii n care valorile asociate mai multor
caracteristici fac parte dintr-un acelai domeniu. Exemplu, ntr-o familie de caracteristici
(atribute) referitoare la descrierea unei Persoane ar putea exista atribute de forma: localitatea
natal, domiciliul stabil, localitatea unde lucreaz acea persoan. Intr-o astfel de situaie,
fiecare caracteristic va lua valori din cadrul aceluiai domeniu i anume cel al localitilor.
Acesta include multitudinea Denumirilor de localiti. Sau un alt exemplu, culoarea
ochilor, culorile drapelului, culoarea creionului, etc. Toate aceste caracteristici sunt diferite ca
semnificaie ns toate iau valori ce fac parte din acelai domeniu.
Pentru a se arta c o dat aparine sau nu mulimii de valori (X
i
) corespunztoare
caracteristicii
i
C se va scrie: x
ij
e X
i
i respectiv x
ij
e X
i;
i, j=1,n

1.3.2.Conceptul de colecie de date

Fiind dat o familie de caracteristici de forma:

{ }
n
C C C , , ,
2 1
= A

Este de menionat faptul c ntre caracteristicile familiei A nu s-a precizat nici o relaie
de ordine. Pentru a imprima o anumit relaie de ordine ntre aceste caracteristici i a obine o
Capitolul 1

28
informaie cu un anumit sens, n concordan cu satisfacerea anumitor cerine informaionale
necesare diferitelor categorii de utilizatori, asupra acestei familii A se poate aplica unul sau
mai multe predicate P. Prin predicat nelegnd o mulime de reguli (proprieti) cu ajutorul
crora se vor selecta numai acele combinaii de C
i
cu x
ij
e C
i
care ndeplinesc proprietile
prestabilite ca fiind adevrate.
Se obine astfel o submulime de caracteristici cu o anumit semnificaie pe care o
vom numi colecie de date (K), de forma:

( ) n w P K
w w
, , 2 , 1 ; = A =
unde, w semnific unul din mulimea predicatelor ce se aplic asupra familiei A, iar colecia
w
K astfel obinut poate apare astfel:

{ }
m i i i
C C C K
1 2 1
, , , =
unde m n.

Deci, un predicat P este o proprietate asociat coleciei de date K, dac te T atunci

P[K(t)] = Adevrat.

Fiind dat un predicat P i un n-tuplu ordonat x
ij
, de forma :

x
11
x
12
x
13
x
14
x
1n
x
21
x
22
x
23
x
24
x
2n
x
31
x
32
x
33
x
34
x
3n
. . ..
x
m1
x
m2
x
m3
x
m4
x
mn
se poate defini relaia n-ar R asociat predicatului P, astfel:

R={( x
11,
x
12,
x
13,
....., x
1n
) : P [(x
11,
x
12,
x
13,
....., x
1n
)]=Adevrat}

unde x
1i
e X
i
, i=1,2,.,n i P [(x
11,
x
12,
x
13,
....., x
1n
)] reprezint evaluarea predicatului.

Exemplu: Fie familia de caracteristici referitoare la descrierea persoanelor, de forma:

A={CNP, NUME_PERSOAN, VRSTA, PROFESIE, ,LOC_MUNC, NUME_COPIL, ..}

Considerm relaia R de ordinul doi definit astfel:

R={(NUME_PERSOAN, NUME_COPIL): P[(nume_persoan, nume_copil)]=Adevrat}

unde P definete regula prin care unei anumite persoane s i se asocieze numele copiilor ce i
aparin. In mod asemntor pot fi aplicate o serie de alte reguli asupra familiei obinnd alte
submulimi de caracteristici (alte colecii de date).


29
n situaia n care urmrirea evoluiei n timp a ntregii colecii de date prezint interes,
acesteia i se poate asocia o variabil T care definete un decalaj al timpului n intervale
discrete:

T= {t
0,
t
1,
, t
j,
..},
ceea ce nseamn c n timp colecia de date va aprea astfel:

K(t
1
), K(t
2
), ..K(t
j
), , K(t
n
)

Exemple privind evoluia n timp a unei colecii de date pot fi urmrite n capitolul
Depozite de date.
Precizm faptul c ntre colecii de date sau ntre caracteristicile unei aceleai colecii
pot fi definite o serie de relaii. Relaia va avea semnificaie de raport, legtur, asociere sau
corespondena din limbajul curent. In acest context relaia poate fi definit matematic astfel:

Fie K
1
i K
2
dou colecii de date. Numim coresponden (legtur) de la colecia de
date K
1
la colecia K
2
un triplet u = (K
1,
G, K
2
) , unde G este o submulime a lui K
1
K
2.
Submulimea G se numete graficul corespondenei.

ntr-o astfel de situaie, fiind dat o colecie K ={C
i
| ie N} sau mai multe colecii,
ntre caracteristicile acesteia sau ntre colecii de date se pot stabili o multitudine de tipuri de
relaii : binare, ternare, , n-are, de echivalen, de ordine, de apartenen etc. Aceste relaii
se caracterizeaz printr-o serie de proprieti, dintre care cele mai semnificative i cu
aplicabilitate mai mare n teoria bazelor de date sunt cele de reflexivitate, simetrie,
tranzitivitate i antisimetrie.
In continuare se va face o scurt prezentare a unora dintre principalele tipuri de relaii.

a) Relaii binare. Se numete relaie binar ntre valorile a dou colecii de date K
1
i K
2

sau ntre caracteristicile aceleai colecii, o submulime a produsului cartezian X
1
X
2
ce satisface o anumit relaie R, unde X
1
este domeniul valorilor caracteristicii C
1
e K
1
,
iar X
2
este domeniul valorilor caracteristicii C
2
e K
2.

Valorile asociate prin relaie sunt atunci acele elemente x
1i
i x
2k
pentru care (x
1i
e X
1,
x
2k
e X
2
) e R. Notnd cu R simbolul de relaie, se va scrie: x
1i
R x
2k
pentru arta c elementele
x
1i
e X
1
i x
2k
e X
2
sunt asociate prin relaia R
In mod analog, se definete relaia de ordin n ntre n caracteristici ale unei colecii K
sau ntre mai multe colecii ca fiind o parte a produsului cartezian dintre valorile acestor
caracteristici, astfel:

Re X
1
X
2
.. X
n
sau [

X
i
i=1,2,.,n.

Elementele din cadrul unei relaii n-are formeaz un n-tuplu ordonat de forma:

(x
11,
x
12,
x
13,
..x
1n
)

unde x
1i
e X
i
, pentru orice valoare a lui i=1,2,.,n. Elementele se vor numai asociate relaiei
R atunci cnd (x
11,
x
12,
, x
1n
) e R.

Determinarea prii de produs cartezian se poate realiza n dou moduri:
prin enumerarea elementelor produsului cartezian ce fac parte din relaia n-ar;
Capitolul 1

30
prin utilizarea unui predicat P care s realizeze selectarea produsului cartezian.

b) Relaii de echivalen. Se numete relaie de echivalen orice relaie reflexiv,
simetric i tranzitiv. Urmtoarele relaii pot fi considerate ca fiind relaii de
echivalen:
ntr-o baz de date referitoare la activitatea de PERSONAL a fi nscui n acelai
an;
ntr-o baz de date referitoare la activitatea FINANCIAR CONTABIL conturile
corespondente cu aceeai terminaie analitic
ntr-un fiier de OBIECTIVE DE INVESTIII, obiective ce au acelai termen de
punere n funciune;
n mulimea cuvintelor unui vocabular, a fi exprimate cu acelai numr de litere.
Fiind dat o relaie de echivalen n cadrul unei colecii de date , dou tupluri asociate
prin aceast relaie se numesc echivalente. Mai multe tupluri echivalente formeaz o clas de
echivalen.
In general, clasa de echivalen C
x
poate fi definit astfel:

Fiind dat o relaie de echivalen R n mulimea M i un element xe M, se numete clas de
echivalen C
x
, mulimea valorilor x i y astfel ca x R y, adic C
x
={x| xRy}.

Toate aceste tipuri de relaii stau la baza organizrii i prelucrrii automate a datelor.
In faza de organizare i creare a coleciilor de date, relaiile sunt marcate, n general, prin
punctatori logici sau fizici, prin chei sau alte elemente din structura logic sau fizic a
nregistrrii.
La nivelul structurii logice sau virtuale a coleciilor de date, relaiile (legturile) cele
mai frecvente sunt:
relaii de tip owner (printe/proprietar), prin care se stabilesc legturile dintre o
nregistrare (linie /rnd) PRINTE i toate nregistrrile (liniile/rndurile) ce
aparin acesteia ( FIU/COPIL/MEMBER) ;
relaii de tip NEXT (urmtorul), care ofer posibilitatea stabilirii de legturi ntre
tuplurile unei colecii de forma legtura la urmtorul tuplu;
relaii de tip PRIOR (precedentul), ofer posibilitatea stabilirii de legturi ntre
tuplurile unei colecii de forma invers celor de tip NEXT, adic legtur la
precedentul tuplu.
Pe baza acestor tipuri de legturi pot fi proiectate colecii cu nregistrri nlnuite sau
se poate proiecta structura logic, virtual/ conceptual sau fizic a coleciilor de date.
In faza de prelucrare a datelor, pe baza relaiilor amintite se pot efectua o serie de operaii
cum ar fi: operaii de sortare (ordonare), interclasare, diferena a dou colecii de date,
produsul a dou colecii de date, proiecia unei colecii de date etc., operaii ce vor fi
prezentate n capitolul Baze de date relaionale.
Pe baza acestor elemente, se poate da o definiie mai complet unei colecii de date, ca
fiind format din urmtoarele componente:
familie de caracteristici { } n I C
I i i
, , 2 , 1 , = = A
e
;
o suit temporal { } , , , ,
1 0 j
t t t T = care definete un decalaj al timpului n
intervale discrete;
un predicat P aplicat asupra familiei A;
afectarea la fiecare moment
j
t a unei relaii n-are simetrice de spaiu de definire
( )
n
C C C , , ,
2 1
asociat predicatului P.

31
Se va conveni ca evoluia coleciei de date n timp s fie neleas n mod implicit, iar
specificarea explicit a timpului s se fac numai n cazurile n care acest lucru se impune.
Coleciile de date pot fi privite la nivel logic, virtual i fizic, corespunztor celor trei
niveluri de organizare a datelor n concordan cu propunerea CODASYL (a se vedea
nivelurile de organizare a datelor n baze de date)
Pentru a distinge noiunea de colecie de date la nivel logic, virtual i fizic, ntr-o
accepiune mai larg, la nivel fizic vom spune c avem de a face cu realizri de colecii de
date.

C
1
C
2
C
3
C
4
. C
n
x
11
x
12
x
13
x
14
. x
1n
x
21
x
22
x
23
x
24
. x
2n
x
31
x
32
x
33
x
34
. x
3n
. .. .. .. ..
x
m1
x
m2
x
m3
x
m4
x
mn

Fig.1.10. Sinteza elementelor ce definesc colecia de date

n figura 1.10. sunt prezentate elementele ce concur la definirea coleciei de date.
Pentru exemplul de fa, predicatul P poate consta tocmai din enumerarea caracteristicilor
coleciei. Multitudinea caracteristicilor determin gradul coleciei i totodat ele constituie
spaiul de definire al coleciei de date.
O linie din cadrul coleciei definete un tuplu sau nregistrare. Multitudinea tuplurilor
unei colecii determin cardinalitatea coleciei. Colecia de date din figura 1.10 este de gradul
n si cardinalitate m.
Cerinele de ordin practic impun ca fiecare tuplu dintr-o colecie de date s poat fi
identificat n mod unic printr-o anumit caracteristic. Din acest considerent, cu ocazia
definirii structurii logice a coleciei de date, din mulimea caracteristicilor/atributelor se va
alege o anumit caracteristic prin ale crei valori s permit identificarea unic a oricrui
tuplu. O astfel de caracteristic va purta denumirea de cheie primar a coleciei de date i este
supus restriciei de unicitate.
Definiia cheii primare poate fi formulat astfel:

Fiind dat o colecie de date K definit prin mulimea caracteristicilor {
1
C ,
2
C
3
C ,,
n
C } i o submulime de caracteristici Y definit prin{
1
C ,
2
C
3
C ,,
m
C } , unde
YeK iar mn. Se spune c Y reprezint cheia primar a coleciei K dac se bucur de
proprietatea de a permite identificarea unic a oricrui tuplu i dac nu exist o alt
submulime Z care s se bucure de aceiai proprietate.

Observaie : n practic nu este exclus ca n definirea unei colecii de date s existe
dou sau mai multe atribute prin ale cror valori s se poat identifica n mod unic oricare
tuplu . ntr-o astfel de situaie se spune c avem de-a face cu atribute candidate la cheia
Domeniu X
2
eC
2
Valoare(data)
Cardinalitate m
Numrul de caracteristici definete gradul/ordinul coleciei n
tuplu
Capitolul 1

32
primar. Criteriul de alegere a cheii primare dintre mai multe atribute candidate l constituie
minimalitatea lungimii cheii. Exemplu, presupunem o colecie de date referitoare la Angajaii
unei societi comerciale, definit prin caracteristicile:

ANGAJAT= {marca, nume, profesia, funcia, data-nateri, , CNP}

unde, marca este format din 4 cifre, iar CNP din 13 cifre.

Identificarea unic a oricrui angajat se poate face att prin marca ct i prin CNP;
deci avem dou caracteristici (atribute) candidate la cheia primar. Aplicnd criteriul
minimalitii lungimii cheii primare se va alege cheie primar atributul marca, fiind format
doar din patru caractere; desigur exist i excepii de la aplicarea acestui criteriu.
Opus minimalitii lungimii cheii primare avem de-a face cu maximalitatea lungimii
cheii, situaie n care identificarea unic a oricrui tuplu poate fi realizat i prin precizarea
valorilor corespunztoare tuturor caracteristicilor prin care se definete structura logic a
coleciei de date ns, n practic nu se folosete.
Colecia de date se regsete sub diferite denumiri: fiier, n cazul organizrii clasice a
datelor; entitate i domeniu, n concepia bazelor de date cu structuri arborescente i reea;
tabel, relaie, viziune (VIEW) sau cluster (CLUSTER), n concepia bazelor de date
relaionale; clasa de obiecte n concepia bazelor de date orientate obiect.

1.4. Conceptul de baz de date

Una sau mai multe colecii de date
w
K aflate n interdependen, mpreun cu
descrierea datelor i a relaiilor dintre ele formeaz o baz de date (B), adic:

{ } n I K K K B
I i i
, , 2 , 1 , , , ,
2 1
= =
e
.

Apreciem c baza de date, astfel formulat, trebuie s ndeplineasc urmtoarele
condiii:
a. structura bazei de date (SB) trebuie astfel conceput nct s asigure informaiile
necesare i suficiente pentru satisfacerea cerinelor de informare (CI) i decizie ale
utilizatorilor finali:

sb
V >
ci
V

unde : V volumul datelor asociate structurii bazei de date i respectiv cerinelor
informaionale (CI).

b. s permit accesul rapid la informaiile stocate n baz:

| | ( )
ac
N T f , min

unde:
T - reprezint timpul de cutare-rspuns a sistemului pentru efectuarea unei
aplicaii;

33
N
ac
- reprezint numrul de accese la baza de date.

c. s prezinte o redundan minim i controlat a datelor stocate. Prin redundana
datelor vom nelege regsirea unei aceleai caracteristici (atribut) n dou sau mai
multe colecii de date.
Prezena redundanei datelor n cadrul bazei de date genereaz o serie de anomalii de
ordin logic care afecteaz performanele de ordin fizic a bazei de date. Din aceste
considerente este de dorit ca, pe ct posibil, redundana s fie nlturat. Ins, din
anumite considerente de ordin practic uneori se accept un anumit grad de redundan
a datelor. Este de dorit ca redundana s fie minim. Intr-o astfel de situaie,
redundana se va exprima prin intersecia cardinalitii informaiilor coleciilor de date
K
m
ca fiind minim:

card (K
w
) = minim, w=1,2,,n

Acceptarea unui anumit grad de redundan impune cu necesitate instituirea unui
control automat asupra redundanei.
Prin control automat asupra redundanei datelor se urmrete asigurarea coerenei
bazei de date.
Prin coerena bazei de date se va nelege faptul c atributele/caracteristicile acceptate
a fi redundante trebuie s aib aceiai valoare sau nivel de indicator.

Fig. 1.11. Redundana datelor

STUDENI STUD - NOTE STUD - TAXE
Nr.-matricol
Nume

Adresa
Nr.-matricol
------
------
Adresa
Nr.-matricol
------
------
Adresa
controlul redundanei
atribut
redundant
Program de
actualizare
Capitolul 1

34
Exemplu:
Presupunem o baz de date la nivelul unei Faculti, format din trei colecii de date,
astfel (figura 1.11):
STUDENI coninnd informaii generale despre studeni;
STUD_NOTE coninnd informaii despre notele studenilor pe durata anilor de
studii;
STUD_TAXE coninnd informaii despre taxele de colarizare ale studenilor cu
tax.
Totodat, presupunem c din anumite considerente de ordin practic se accept ca
atributul Adresa studentului s se regseasc n toate cele trei colecii de date.
ntr-o astfel de situaie va trebui s instituim control automat (prin program) asupra
redundanei, astfel nct atunci cnd se modific adresa, actualizarea adresei cu noua valoare
s se propage i s se efectueze concomitent n toate cele trei colecii de date.
innd seama de toate aceste aspecte, n condiiile lucrului cu baze de date se spune c
avem de a face cu o redundan minim i controlat a datelor.
Accesarea bazei de date poate fi efectuat prin diverse canale oferite de programe de
aplicaie, limbaje de manipulare (procedurale sau neprocedurale) autonome, interfee cu
limbajele clasice de programare i/sau aplicaii de uz general etc.
Modul de exploatare a bazei de date precum i relaiile dintre coleciile ce compun
baza de date sunt prezentate n mod sugestiv n figura 1.12.
Baza de date implic existena unui SGBD ca mediator ntre utilizatori, sistemul de
operare gazd i baza de date fizic.
n figura 1.12 se sugereaz baza de date fizic stocat pe suport magnetic, compus
din colecii de date interdependente i/sau care prezint submulimi de date partajate (K1, K2,
K3, K4 i K5) sau colecii independente (K6). Utilizatorul interacioneaz cu baza de date
prin intermediul sistemului de gestiune a bazei de date (SGBD) prin utilizarea unor programe
de aplicaie (P1, P2, P3 i P4) sau direct, prin intermediul limbajelor sau utilitarelor oferite de
ctre SGBD. Accesul la baza de date poate fi realizat local sau la distan, utiliznd terminale
on-line, calculatoare personale, calculatoare independente sau reele de calculatoare.
Rezultatul interogrilor utilizatorului poate fi vizualizat, listat, stocat n fiiere, transmis la
distan etc.

Fig. 1.12. Exploatarea bazei de date


35
1.5. Conceptul de sistem de baze de date

n paragraful anterior s-a definit conceptul de baz de date i am mai putea aduga
faptul c ea poate fi asociat cu un depozit sau un container (instalat pe un calculator n care
se introduc i se stocheaz date ce prezint interes i respectiv sunt extrase date n
concordan cu cerinele utilizatorilor). ns, trebuie precizat faptul c baza de date nu se
gsete sau nu poate funciona la modul izolat ci se regsete ncadrat ntr-un anumit mediu,
coopernd cu o serie de alte componente (elemente). Dintre componentele cu care
interacioneaz baza de date, enumerm:
- componentele hardware ale sistemului de calcul (calculatorul propriu-zis) pe care
urmeaz a fi instalat baza d date;
- sistemul de gestiune a bazei de date (SGDB), care reprezint software-ul propriu-zis
al bazei de date. Fr un SGDB corespunztor, baza de date nu ar putea funciona, astfel nct
ea nu s-ar justifica ca existen;
- utilizatorii bazei de date. Acetia pot fi grupai n trei categorii, astfel: utilizatori
finali (beneficiarii bazei de date ), programatorii de aplicaii i administratorul bazei de date.
Despre toate aceste componente vom gsi detalii pe parcursul ntregii cri.
n acest context, se poate spune c un sistem de baze de date reprezint baza de date
mpreun cu multitudinea componentelor cu care interacioneaz. Acest aspect este sugerat
n figura 1.12.

1.6. Baze de date centralizate i distribuite

Vom considera o baz de date B definit conform celor expuse n 1.3.:

{ } . , , 2 , 1 , , ,
2 1
n I K K K B
I i i
= =
e

i o mulime de calculatoare interconectate formnd o reea R:

R={N
1,
N
2, .,
N
j.
} j=1,2,.,m

unde N
j
reprezint nodurile reelei de calculatoare.

Fiecare colecie
i
K este format dintr-o mulime de atribute (cmpuri, coloane)
{ } n k A A A K
ik i i i
. , 2 , 1 , , , ,
2 1
= = i are asociat o mulime de date (linii, rnduri,
nregistrri). O linie din mulimea datelor este reprezentat ca o asociere a valorilor pentru
fiecare atribut din colecie.
n funcie de modul n care sunt stocate coleciile (i/sau datele asociate acestora) care
formeaz baza de date aceasta poate fi:
- Centralizat, n cazul n care totalitatea coleciilor care formeaz baza de date sunt
memorate pe un singur calculator. Dac calculatorul este inclus ntr-o reea de
calculatoare atunci baza de date poate fi considerat i baz de date local;
- Distribuit, n cazul n care coleciile care compun baza de date (cel puin una) sunt
fragmentate, iar fragmentele sunt stocate n nodurile unei reele de calculatoare R.

Capitolul 1

36
n context distribuit baza de date este vzut ca o mulime de partiii
d
P P P , , ,
2 1
cu
m d s , unde o partiie
j
P corespunztoare nodului N
j
este o submulime a bazei de date B,
adic { }
I i i j
K K K P
e
_ , , ,
2 1
cu 2 > d . n funcie de modul n care prile care compun
baza de date sunt disjuncte sau nu baza de date va fi:
integral neduplicat (toate prile componente sunt disjuncte);
parial duplicat (exist o submulime de pri care nu sunt disjuncte);
total duplicat (fiecare parte component, stocat pe un calculator din reea, nu
este disjunct cel puin cu o parte aflat n alt nod al reelei).
n ambele cazuri, utilizatorul obinuit are acces i vede baza de date conform celor
expuse n paragrafele anterioare.
Noiunea de distribuie va fi tratat pe larg n capitolul referitor la baze de date
distribuite.

1.7. Niveluri de organizare a datelor n baze de date

Spre deosebire de sistemele clasice de prelucrare automat a datelor, unde
organizarea datelor n fiiere presupunea dou niveluri de referin (nivelul logic si nivelul
fizic), n cazul bazelor de date se distinge i un al treilea nivel de structurare a datelor i
anume, nivelul virtual (nivel conceptual). In scopul simplificrii prezentrii (i pentru
pstrarea legturii cu organizarea datelor in fiiere) pentru nivelul fizic, virtual (conceptual)
i logic (extern) de organizare a structurii bazei de date, vom utiliza denumirea prescurtat
de structur fizic, virtual (sau conceptual) si respectiv logic (extern) a bazei de date.
Structura logic (nivel extern) a datelor se refer la forma n care fiecare utilizator
vede structurarea datelor n funcie de aplicaia cu care lucreaz sau n funcie de resursele
de date pe care administratorul bazei de date i le-a pus la dispoziie ca structur extern
(subschema bazei de date la care are drepturi de acces).
Structura fizic se refer la modul de memorare si structurare a datelor pe suportul
fizic. Structura fizic a suportului de memorare admis de ctre un SGBD, permite n general
urmtoarele niveluri de referin: volum magnetic, cilindru, pista, sector, bloc, octet si bit.
Structura virtual se refer la definirea structurii datelor din baza de date, astfel nct
aceasta s satisfac cerinele tuturor utilizatorilor n condiii de redundan minim si
controlat a acesteia (nivel conceptual). Aceast structur poart denumirea, n concepia
CODASYL, de SCHEMA BAZEI DE DATE, iar structura logic este numit SUBSCHEMA
BAZEI DE DATE.
O nregistrare virtual, n general se poate materializa n una sau mai multe
nregistrri fizice i poate participa la construirea uneia sau mai multor nregistrri logice.
n general, structura logic a bazei de date apare la nivelul programului de aplicaie,
structura virtual la nivelul administratorului bazei de date iar structura fizic la nivelul
inginerului de sistem.
Legtura dintre nivelul virtual (conceptual) i cel fizic se realizeaz de ctre SGBD.
Aceasta permite mai multe moduri de realizare fizic a unei nregistrri virtuale iar
administratorul bazei de date stabilete tipul de legturi preferabil dintre acestea.
n figura 1.13. se prezint cele trei niveluri de organizare a datelor n baza de date i
raportul dintre ele.

37
Nivelul virtual (conceptual) permite separarea modului de organizare a datelor de
modul de utilizare al acestora.

Fig. 1.13. Niveluri de organizare a datelor la baze de date centralizate i/sau locale

Prin aceast separare a structurii logice de structur virtual se asigur cel puin
urmtoarele dou mari avantaje:
n procesul de creare i exploatare a bazei de date activitatea de elaborare a
programelor poate fi modularizata. Fiecare programator poate s-i scrie
programele sale fr s fie nevoit s cunoasc structura ntregii baze de date, ceea
ce duce la reducerea timpului de realizare a sistemului informatic, avnd drept
nucleu o baz de date. In acelai timp sporete confidenialitatea datelor din
baz, innd seama de faptul c fiecrui utilizator i sunt puse la dispoziie
numai datele pe care le are specificate la nivelul structurii logice a aplicaiei.
La nivel virtual (toate cerinele utilizatorilor) apare posibilitatea gsirii acelei
structuri globale a bazei de date care s permit satisfacerea tuturor acestor cerine
n condiiile:
- reducerii volumului memoriei magnetice necesare pentru stocarea
(memorarea) datelor, prin asigurarea unei redundane minime i controlate
a datelor din baz;
- reducerii timpului de rspuns pentru informaiile solicitate;
- reducerii efortului de pregtire, ncrcare i actualizare a bazei de date.

Cele trei tipuri de structuri, corespunztoare celor trei niveluri de organizare a
datelor (logic, virtual i fizic) sunt mai sugestive i mai bine redate n figura 1.14, unde:
se sugereaz aplicaiile utilizatorilor cu structurile logice implicate (fiecare
aplicaie presupune anumii indicatori, exemplu Aplicaia 1 implic indicatorii A,
B, C, D, H, L);
Schema
Extern A
Schema
Extern B
Schema
Extern N
Schema
Conceptual
Schema
Fizic
Transformarea

Extern <=> Conceptual
Transformarea

Extern <=> Fizic
Nivel
EXTERN
Nivel
CONCEPTUAL
Nivel
FIZIC
Capitolul 1

38
structura logic nu reprezint nimic altceva dect modul n care un utilizator
oarecare percepe/vede structura bazei de date prin prisma intereselor sale de
aplicaie;
se observ c dac datele ar fi stocate pe suportul de memorie extern n
concordan cu structura logic a bazei de date, atunci anumii indicatori/date ar fi
stocai de mai multe ori (exemplu, indicatorii A, B i D). O astfel de situaie ar
genera o redundan a datelor n baza de date;
pentru a prentmpina redundana datelor, administratorul bazei de date recurge la
analiza tuturor cerinelor aplicaiilor utilizatorilor i apoi va defini o structur
unic, capabil s satisfac cerinele tuturor utilizatorilor n condiiile de
redundan minim i controlat a datelor. Deci, se observ la nivelul structurii
virtuale c fiecare indicator se regsete o singur dat. Aceast structur
reprezint punctul de vedere al administratorului de sistem;
datele vor fi stocate n baza de date conform structurii fizice, care nu reprezint
altceva dect punctul de vedere al inginerului de sistem.

Fig. 1.14. Exemplu de tipuri de structuri

Aplicaia 1
A, B,C,D,H,K
Aplicaia 2
B,D,E,F,G
Aplicaia N
A, B,I,J,L

A, B,C,D,E,F,G,H,I,J,K,L
structura
virtuala
BAZA DE DATE
structura
fizic
>
Punctul de vedere
al utilizatorului
Punctul de vedere al
administratorului de
baz de date

>
>
structura
logic
Punctul de vedere al
inginerului de sistem

Sisteme de gestiune a bazelor de date

39

Capitol 2
Sisteme de gestiune a bazelor de
date (SGBD -DBMS)

2.1. Definirea SGBD

SGBD reprezint un pachet complex de componente software, fiecare avnd o
anumit funciune sau obiectiv.
Cu ajutorul componentelor software ale SGBD se realizeaz o multitudine de
activiti, cum ar fi: definirea structurii bazei de date, ncrcarea, exploatarea, ntreinerea,
protecia bazei de date etc. n acest context se apreciaz c Sistemul de Gestiune reprezint
software-ul propriu-zis a bazei de date. Baza de date lipsit de un Sistem de Gestiune nu se
justific i nu poate exista.
Performanele unui sistem depind de eficiena structurilor utilizate pentru
reprezentarea datelor n baza de date i de eficiena cu care sistemul opereaz cu aceste
structuri.
Scopul SGBD este acela de a simplifica i uura accesul la date. Acest lucru este
realizat n general prin asigurarea transparenei (fa de utilizator) a modului de
reprezentare fizic (low_level) fa de modul n care utilizatorul interacioneaz cu
datele (viziuni de nivel nalt - high_level).
n acest context un SGBD poate fi vzut ca o interfa ntre cel mai sczut nivel de
stocare utilizat de baza de date - nivelul fizic - i programele de aplicaie sau cererile
adresate sistemului.
Accesul utilizatorului final la datele stocate n baz de date, poate fi vzut, la modul
general ilustrat n figura 2.1.
In mod obligatoriu SGBD trebuie s cunoasc ce fiiere stocate exist iar, pentru
fiecare dintre ele:
- structura de stocare a nregistrrii;
- cmpurile care compun/descriu nregistrarea;
- cmpurile care pot fi utilizate ca argumente/parametri pentru instruciunile de cutare
n acces direct (dac astfel de cmpuri exist).
n figura 2.2. este prezentat o detaliere a structurii sistemului de gestiune a bazei de
date unde utilizatorii pot fi:
- Programatori de aplicaie - apeluri la limbajul de manipulare a datelor (LMD) din
programe gazda (OCI PRO*C, PRO*Cobol, ... ).
- Utilizatori cauzali - interacioneaz cu sistemul fr a scrie programe prin
intermediul unui limbaj de cereri.
- Utilizatori obinuii - utilizeaz programe de aplicaie.
Capitolul 2

40
- Utilizatori specializai - utilizeaz produse CASE, sisteme expert, baze de cunotine.
- Administratorul BD (ABD) avnd o serie de sarcini, cum ar fi:
- definirea schemei (cu ajutorul limbajului de definire a datelor LDD);
- definirea structurii de stocare i a metodelor de acces;
- modificarea schemei fizice i a celei organizatorice;
- acordarea drepturilor de acces;
- specificarea restriciilor de integritate.

Fig. 2.1. Interfaa cu datele stocate

n figura 2.3 este prezentat o detaliere a interaciunii componentelor sistemului de date
la existena unei cereri utilizator.
Elementele din figura 2.3 sunt descrise sumar n cele ce urmeaz:
- Analizor Cereri (Compilator, Interpretor - Query Parser) - translateaz instruciunile
exprimate n limbajul de cereri n instruciuni cod maina (sau un alt limbaj de nivel
sczut);
- Selectorul Strategiei de Execuie - are rolul de a gsi cea mai bun cale de execuie a
cererii prin consultarea unor date statistice i/sau informaii de sistem.
- Gestionarul Autorizrilor i Integritii - testeaz satisfacerea restriciilor de integritate i
a drepturilor de acces a utilizatorului;
- Gestionarul Relurii - asigur consistena bazei de date n caz de cdere (pan disc,
ntrerupere curent, erori software etc);
- Controlerul Concurenei - asigur medierea cerinelor concurenei;
- Gestionarul Buffer-elor memoriei - este responsabil cu transferul informaiilor ntre disc
i memoria intern;
- Gestionarul de Fiiere - responsabil cu gestiunea spaiului de stocare, alocarea acestuia i
structurile de date utilizate pentru a stoca datele n disc. SGBD-ul utilizeaz diverse
structuri de date ca pri ale structurii fizice de stocare cum ar fi:
- Fiiere de Date - destinate stocrii bazei de date nsi;

41
- Fiiere de Date Sistem - utilizate pentru a stoca date despre structura bazei de
date (Dicionarul Datelor), informaii privind autorizrile i utilizatorii, restricii
de integritate etc.
- Indeci - construii pentru realizarea unui acces rapid la date;
- Date Statistice - informaii statistice despre datele coninute n BD.

Fig. 2.2 Structura sistemului de gestiune a bazei de date

- Gestionarul Bazei de Date (Database Manager) realizeaz cel puin urmtoarele sarcini:
- interaciunea cu gestionarul de fiiere al sistemului de operare (SO) gazd.
Translateaz diversele comenzi ale LMD n comenzi de acces la nivel sczut la
fiiere. De fapt, SGBD este responsabil cu modul curent de stocare, regsire si
actualizare a datelor n baza de date;
- foreaz integritatea (fizic, logic i eventual distributiv (integrity enforcement).
Memorarea datelor n BD este efectuat numai dac sunt ndeplinite anumite
restricii (restricii de integritate sau restricii de consisten) definite de ctre
SGBD. Aceste restricii sunt verificate la orice cerere de actualizare, aciunea
ndeplinit de SGBD n urma verificrii fiind dependent de violarea sau
respectarea acestora;
- foreaz securitatea (security enforcement);
- salvare i refacere (backup and recovery);
SGBD
Program de
aplicaie
Apeluri la
funcii sistem
Memorie
Disc
Utilizatori
obinuii
Programatori
de aplicaie
Utilizator i
cauzali
Administratorul
BD
Cereri Schema BD

Precompilator
LMD
Procesor de
cereri
Compilator
LDD
Codul executat
al programului
de aplicaie
Gestionarul
BD
Utilitare
Gestionarul de
fiiere
Fiiere de
DATE
Dicionar de
DATE
Capitolul 2

42
- jurnalizare /refacere la incident;
- controlul concurenei (i partajarea datelor).

2.2. Obiectivele unui SGBD

Aa dup cum este cunoscut, obiectul de preocupare a informaticii l constituie
culegerea, verificarea, transmiterea, stocarea i prelucrarea automat a datelor cu ajutorul
mijloacelor electronice de calcul, n scopul satisfacerii diferitelor niveluri de conducere cu
informaiile necesare lurii de decizii n condiii de eficien economic sporit.
n condiiile exploziei informaionale, cerina acut de informare trebuie satisfcut
innd seama de o serie de condiii care s asigure:
- minimizarea costului procesului de prelucrare automat a datelor;

Fig. 2.3. Structura Sistemului (Detaliu)


43
- creterea vitezei de rspuns la ntrebrile solicitate de utilizatori;
- adaptarea n mod facil a sistemului informatic la evoluia n timp a
sistemului informaional din care face parte;
- posibilitatea rspunsului la anumite ntrebri neanticipate de ctre proiectanii
de sistem (prin neanticipare nu sunt incluse printre funciunile oferite de sistemul
informatic);
- posibilitatea folosirii sistemului de informare dispunnd de un minim de
cunotine despre modul de organizare a lui n general i despre informatic n
special;
- integritatea i securitatea datelor n ceea ce privete modul de pstrare i acces la
ele etc.
n acest context, sistemului de gestiune al bazei de date i revin o serie de obiective,
cum sunt:
a) Asigurarea independenei datelor. Se spune c o aplicaie este dependent de
date, dac este imposibil s schimbi structura de memorare a datelor (modul n
care sunt memorate datele) sau strategia de acces la date (cum se face accesul la
date) fr s afecteze aplicaia. Independena datelor este necesar cel puin din
urmtoarele considerente:
- diferite aplicaii au nevoie de viziuni diferite ale acelorai date. De
exemplu, o aplicaie utilizeaz un cmp de dat drept o dat zecimal n timp
ce o alt aplicaie utilizeaz acelai cmp de dat ca fiind reprezentat n binar.
Sistemul va asigura automat conversia ntre reprezentarea intern a
acelei date i reprezentarea necesar fiecrei aplicaii;
- administratorul bazei de date trebuie s aib libertatea s schimbe structura de
memorare sau strategia de acces, ca rspuns la cerinele de schimbare
(schimbri de standarde, prioritile aplicaiilor, unitile de memorare etc.),
fr s modifice aplicaiile existente;
- existena unei baze de date i a unor programe de exploatare a ei, care au fost
folosite o perioad de timp, reprezint o investiie major la care nu trebuie s
se renune prea uor. De aceea se impune cu necesitate ca atunci cnd apar
noi cerine n cadrul sistemului informaional sau noi software-uri de baze de
date acesta s poat funciona cu programele i procedurile existente iar
datele existente s poat fi convertite. Deci schimbrile care se fac la nivel de
structur de date nu trebuie s modifice programele de aplicaie.
n astfel de condiii, independena datelor poate fi definit drept imunitatea
programelor de aplicaii la schimbarea structurii de memorare sau/i strategiei de acces.
Independena datelor trebuie privit din dou puncte de vedere generale:
- independena fizic;
- independena logic a datelor;
- i unul specific pentru baze de date distribuite:
- independena distributiv.
Independena fizic a datelor face ca memorarea datelor i tehnicile fizice de
memorare s poat fi schimbate fr a provoca rescrierea programelor de aplicaie.
n ceea ce privete independena logic a datelor, aceasta se refer la posibilitatea
adugrii de noi articole de date sau extinderea structurii conceptuale (globale), fr
necesitatea rescrierii programelor existente.
Independena distributiv a datelor face ca schimbarea nodurilor in care se stocheaz
baza de date s nu provoace rescrierea programelor de aplicaie.
Capitolul 2

44
Prin asigurarea independenei datelor fa de programele de aplicaii se asigur
adaptarea n mod facil a sistemului informatic la evoluia sistemului informaional n care
este integrat.
b) Asigurarea unei redundane minime i controlate a datelor din baza de date.
Aa dup cum s-a mai precizat anterior, prin redundana datelor n baza de date vom
nelege regsirea sau prezena a acelorai date n dou sau mai multe colecii de date.
Spre deosebire de sistemele clasice de prelucrare automat a datelor, stocarea
datelor n cazul bazelor de date se face n aa fel nct fiecare dat s apar o singur dat
(redundan minim). Totui, nu sunt excluse nici cazurile n care din dorina de a realiza
performane sporite, referitoare la timpul de acces la date i rspuns la solicitrile
utilizatorilor, s se accepte o anumit redundan a datelor, ns n acest caz se va institui
control automat asupra ei n vederea asigurrii

coerenei datelor din baz. In acest caz se
spune c avem de a face cu o redundan minim i controlat a datelor.
c) Asigurarea unor faciliti sporite de utilizare a datelor. Sub aspectul facilitilor
de utilizare se urmrete:
- datele s poat fi folosite de mai muli utilizatori n diferite scopuri
(aplicaii);
- utilizatorii s aib acces la date ntr-un mod ct mai simplu, fr ca acetia s
fie nevoii s cunoasc structura ntregii baze de date, acest lucru rmnnd
n atenia administratorului bazei de date;
- existena unor limbaje performante de regsire a datelor, care permit
exprimarea sub forma unei conversaii, a unor criterii de selecie a datelor
i indicarea unor reguli ct mai generale pentru editarea informaiilor
solicitate;
- spre deosebire de sistemul clasic de prelucrare ,,gen fiier, unde exist un
singur criteriu de adresare, cel care a stat la baza organizrii fiierului, n cazul
bazelor de. date, sistemul de gestiune trebuie s ofere posibilitatea unui acces
multicriterial, fr sortri suplimentare, n timp ce modificarea criteriului la
fiierele clasice implic reorganizarea lor;
- utilizarea unui limbaj ct mai apropiat de limbajul natural, cu posibilitatea
exploatrii bazei de date n regim conversaional. Realizarea unui astfel de
obiectiv ofer posibilitatea exploatrii n mod facil a bazei de date i de
ctre utilizatori neinformaticieni.
d) Sporirea gradului de securitate a datelor mpotriva accesului neautorizat la ele.
n condiiile bazelor de date, administratorul bazei de date poate prevedea ca
accesul la baza de date s se fac numai prin canale corespunztoare, iar pe de alt
parte, poate defini verificri de autorizare, care s fie realizate oricnd se ncearc
un acces la anumite date.
e) Asigurarea integritii datelor mpotriva unor tergeri intenionate sau
neintenionate a datelor, prin intermediul unor proceduri de validare, a unor
protocoale de control concurent i a unor proceduri de refacere a bazei de date dup
incidente.
f) Asigurarea partajabilitii datelor. Partajabilitatea datelor trebuie neleas nu
numai sub aspectul asigurrii accesului mai multor utilizatori la aceleai date ci
i aspectul c pot fi dezvoltate aplicaii fr s se modifice structura bazei de date.


45
2.3. Funciile unui sistem de gestiune a bazei de date

Sistemele de gestiune a bazelor de date dispun de o serie de componente ce permit
efectuarea numeroaselor operaii implicate de realizarea obiectivelor enumerate la
paragraful anterior. In funcie de natura lor i scopul urmrit, operaiile pot fi grupate pe
activiti.
Activitile accept i ele o anumit grupare pe funcii.Una sau mai multe activiti,
relativ omogene, vor realiza o anumit funcie.
innd seama de multitudinea sarcinilor ce revin unui SGBD i grupnd aceste
sarcini pe activiti i apoi pe funcii, n final pot fi deduse funciile sistemului de
gestiune.
innd seama de complexitatea sistemului de gestiune, de facilitile propuse a fi
oferite de acesta, de limbajele utilizate i tipul bazei de date ce urmeaz a fi gestionat
de SGBD, gruparea activitilor pe anumite funcii are un caracter relativ. Astfel de exemplu,
sistemele de gestiune pentru baze de date distribuite vor avea de rezolvat probleme privind
accesul concurenial ntr-o forma complex, localizarea nodurilor cooperante pentru
satisfacerea unei cerine informaionale globale ce solicit date din mai multe noduri ale
reelei (din mai multe baze de date locale), dialoguri de comunicare i confirmare de mesaje
etc. Totodat, funciile sistemelor de gestiune vor comporta amprenta limbajelor folosite
(SGBD-uri cu limbaje proprii-autonome i SGBD-uri cu limbaje gazd de nivel nalt -
COBOL, FORTRAN, PL/I, C, C++, ADA etc.).
n situaia sistemelor de gestiune ce utilizeaz limbaje gazda, de nivel nalt,
identificarea i delimitarea funciilor nu este att de evident.

Fig. 2.4. Funciile unui SGBD

Utilizare

Manipulare
Administrare

Descriere
Baza de Date
Fizic
UTILIZATORI
Capitolul 2

46
n ciuda acestor particulariti, totui, se pot deduce cteva funcii cu caracter de
generalizare pentru toate sistemele de gestiune a bazelor de date. n cele ce urmeaz ne
propunem s facem o prezentare sumar a unor astfel de funcii (figura 2.4).

Funcia de definire a datelor permite definirea structurii bazei de date cu ajutorul
limbajului de definire a datelor (LDD). Definirea datelor poate fi realizat la nivel logic,
virtual i fizic. La nivelul acestei funcii se descriu multitudinea atributelor (cmpurilor) din
cadrul structurii bazei de date, legturile dintre entitile bazei de date sau dintre atributele
aceleiai entiti, se definesc eventualele criterii de validare a datelor, metodelor de acces la
date, aspectele referitoare la asigurarea integritii i confidenialitii datelor etc.
Rezultatul compilrii descrierii exprimate n LDD se va concretiza n schema bazei
de date memorat, n cod intern, ntr-un ,,fiier special denumit dicionarul dalelor (DD -
data dictionary). Structura de stocare i metodele de acces utilizate de ctre SGBD sunt
specificate cu ajutorul unor instruciuni specializate ale LDD care fac parte din limbajul de
definire a structurii fizice. Rezultatul compilrii acestor instruciuni este concretizat n
elemente de specificare a detaliilor de implementare a schemei BD. Aceste detalii sunt
transparente pentru utilizator.

Funcia de manipulare a datelor este cea mai complex funcie i realizeaz
urmtoarele activiti:
- crearea (ncrcarea) bazei de date;
- adugarea de noi nregistrri (tupluri);
- suprimarea unor nregistrri;
- modificarea valorilor corespunztoare unor cmpuri;
- cutarea, sortarea i editarea pariala sau total a unei nregistrri virtuale etc.
Datorit complexitii acestei funcii, pentru anumite SGBD-uri ea se poate subdivide
n urmtoarele subfuncii de :
- creare iniial a bazei de date;
- actualizare i interogare/extragere a datelor.
Funcia de manipulare a datelor se realizeaz prin intermediul limbajului de
manipulare a datelor.

Funcia de utilizare asigur mulimea interfeelor necesare pentru comunicarea
tuturor utilizatorilor cu baza de date.
n cadrul realizrii acestei funcii apar mai multe categorii de utilizatori:
- utilizatori ,,liberi sau conversaionali. Acetia reprezint categoria
beneficiarilor de informaii (utilizatori finali) i utilizeaz limbajele de interogare a bazei de
date ntr-o form simplist. Ei apar ca utilizatori neinformaticieni;
- utilizatori programatori care fac uz de limbajele de manipulare, realiznd proceduri
complexe de exploatare a bazei de date;
- administratorul bazei de date apare ca un utilizator special i are rolul hotrtor
n ceea ce privete funcionarea optimal a ntregului ansamblu.

Funcia de administrare a bazei de date apare ca o funcie complex i este de
competena administratorului bazei de date. Aceasta funcie va fi tratat n detaliu la
capitolul privind administrarea bazei de date.


47
2.4. Arhitectura sistemelor de gestiune a bazelor de
date

innd seama de faptul c exist diferite tipuri de sisteme de gestiune, ca ele se
difereniaz prin limbajele utilizate, prin anumite componente ce imprim diferite faciliti
de exploatare a bazei de date, prin faptul c unele ofer posibilitatea lucrului n regim de
teleprelucrare, altele numai n regim local iar altele att n regim local ct i n regim de
teleprelucrare, nu poate fi dat o arhitectur unic valabil pentru toate sistemele. Deci, apar
particulariti de la un sistem la altul.
Totui exist preocupri de standardizare a arhitecturii sistemelor de gestiune, care
caut s defineasc cadrul general al acestora.
n acest context vom cuta s prezentm dou arhitecturi de referin a unui SGBD
propuse de grupul de lucru CODASYL i ANSI/X3/SPARC.
2.4.1. Arhitectura unui SGBD n concepia CODASYL

n figura 2.5. este redat arhitectura unui SGBD n concepia CODASYL. Din figura
2.5. se pot deduce cele trei nivele de organizare a datelor i structurile corespunztoare,
precum i operaiile declanate de derularea unui program de aplicaie sub controlul unui
SGBD.
Succesiunea logic a operaiilor declanate de un program de aplicaie apare astfel:
- Programul de aplicaie A lanseaz o cerere de citire a datelor din baza de date.
Cererea este lansat ctre SGBD.
- Sistemul de gestiune interpreteaz cererea, consultnd SUBSCHEMA
referitoare la programul de aplicaie A.
- Sistemul de gestiune apeleaz SCHEMA bazei de date i determin la nivel logic
datele solicitate din cadrul unei nregistrri virtuale.
- Sistemul de gestiune examineaz descrierea fizic a bazei n raport cu cererea
logic i determin nregistrarea fizic care intereseaz.
- Sistemul de gestiune lanseaz o comand ctre sistemul de operare sub
controlul cruia lucreaz pentru cutarea nregistrrii fizice de citit.
- Sistemul de operare cut nregistrarea fizic.
- nregistrarea fizic gsit este transferat n memoria tampon a sistemului de
gestiune.
- SGBD procedeaz la o comparare ntre SCHEMA bazei de date i SUBSCHEMA
corespunztoare aplicaiei A i identifica datele solicitate de programul A.
- SGBD transfer datele din memoria tampon n zona de lucru rezervat
programului de aplicaie A.
- Programul de aplicaie A preia controlul asupra tratrii datelor solicitate iar pe
parcursul executrii programului se realizeaz un schimb de informaii cu SGBD
referitoare la ,,starea programului sau eventualele erori constatate.

Operaiile de scriere n baza fizic sunt tratate de ctre un procesor, similar, toate
modificrile sau adugirile sunt n general precedate de o operaie de citire.

Capitolul 2

48
2.4.2. Arhitectura propus de grupul ANSI/SPARC

Grupul de cercettori de la ANSI/SPARC prezint o alt arhitectur pentru o baz de
date privit ca sistem. Aceast arhitectur pune accentul pe interfeele dintre componentele
sistemului i pe interfeele dintre componente i diferite categorii de utilizatori (roluri
umane). Partea important a arhitecturii ANSI este prezentat n figura 2.6.
Se remarc trei roluri umane n definirea schemelor:
- Persoana sau grupul de persoane care definete schema conceptual a bazei de
date. Schema conceptual reprezint ,,cel mai bun model pentru ntreprindere.
Ea furnizeaz o viziune pe termen lung i reprezint baza pentru declaraiile de
securitate i integritate, precum i pentru standardele impuse de ntreprindere
diferiilor utilizatori.
- Persoan sau un grup de persoane care descriu o schem extern pentru o
aplicaie particular. ntr-o ntreprindere exist mai multe roluri de acest fel.
- Administratorul bazei de date are responsabiliti privind definirea schemei
interne a bazei de date. Tot el asigur i ntreinerea acesteia.

Fig. 2.5. Arhitectura unui SGBD conform propunerii CODASYL

Schemele astfel definite sunt verificate de procesoarele corespunztoare i, dac sunt
valide, sunt memorate n dicionarul datelor.
Declararea schemei conceptuale a bazei de date se realizeaz prin intermediul
interfeei 1.
Dup compilare definirea conceptual este memorat n cadrul dicionarului datelor prin
interfaa 2. Administratorul bazei de date i administratorii aplicaiilor iau cunotin de
schema conceptual prin intermediul interfeei 3.
Program
Coresp.
Aplicaiei A
Zona de lucru
a aplicaiei A
Program
Coresp.
Aplicaiei B
Program
Coresp.
Aplicaiei C
Subschema BD
Coresp.
Aplicaiei A
Subschema BD
Coresp.
Aplicaiei C
Zona de lucru
a aplicaiei B
Zona de lucru
a aplicaiei C

Nivel
EXTERN
(9)
(10)
(1)
(12)
BUFFERE-LE
SISTEMULUI
SCHEMA BAZEI
DE DATE S G B D
SISTEMUL DE
OPERARE
DESCRIEREA
FIZIC A BD
Administrator
Baza de Date
Programator
de sistem
Baza de Date
Nivel
Conceptual
(LOGIC)
Nivel
FIIZIC
MANIPULARE DESCRIERE
(8) (3)
(4)
(5)
(6)
(7)
Programator
de aplicaie

49
Prin intermediul interfeei 4 se specific declaraiile schemelor externe, a cror form
compilat este memorat n dicionarul datelor prin interfaa 5.
Declaraiile schemei interne a bazei de date se specific prin intermediul interfeei 6.
schema intern compilat este memorat n dicionarul datelor prin intermediul interfeei 7.
Informaiile din dicionarul datelor sunt puse la dispoziia modulelor de transformare prin
interfeele 8, 9 i 10.
Interfeele 11 i 12 sunt utilizate n timpul execuiei, pentru transmiterea datelor i
comenzilor ntre nivelele bazei de date (memorie, intern, conceptual i extern).
Programatorii de aplicaii i utilizatorii finali comunic cu SGBD-ul prin intermediul
limbajului de manipulare sau a limbajului de interogare (interfaa 13).
Prin intermediul interfeei 14 schema extern este pus la dispoziia programului de
aplicaie pentru ca acesta sa poat fi compilat/translatat/interpretat. La execuie toate cererile
de acces la date sunt transmise prin interfaa 14 la sistemul de gestiune a bazei de date.
Dac sunt necesare schimbri ale structurii de memorare sau a strategiei de acces (din
motive de performan, schimbarea suporturilor de memorie etc.) la date, programatorii de
sistem prin intermediul interfeei 15 specific programele respective, ale cror efecte se
transmit SGBD-lui prin intermediul interfeei 16, fr a afecta nivelurile conceptual i
extern.

Fig. 2.6. Arhitectura ANSI a unui SGBD

Arhitectura ANSI pune, n acest fel, n eviden urmtoarele aspecte:
- definirea schemei conceptuale;
- definirea schemelor externe;
- definirea schemei interne;
- funciile de transformare i independena datelor.
Administratorul

ntreprinderii
Administratorul

Aplicaiei
Administratorul
BAZEI DE
DATE
Procesorul Schemei

CONCEPTUALE
Procesorul
SCHEMEI
CONCEPTUALE
PROCESORUL
SCHEMEI
EXTERNE
TRANSFORMAREA

CONCEPTUAL/EXTERN
PROGRAM DE APLICAIE

EXTERN
PROGRAMATOR
DE
APLICAIE
Dicionarul de
DATE
TRANSFORMAREA

INTERN//MEMORIE
PROGRAM DE APLICAIE

INTERN
INGINER DE
SISTEM
TRANSFORMAREA

INTERN//EXTERN
(1)
(3) (3)
(2)
(7) (5)
(9)
(12) (11)
(16)
(15) (13)
(14)
(8)
(4) (6)
(10)
Capitolul 2

50
Fcnd o analiz sumar a celor dou tipuri de arhitectur se pot desprinde unele
aspecte eseniale comune. Astfel, schema bazei de date din cadrul propunerii CODASYL
poate fi identificat cu schema conceptual din arhitectura ANSI/X3/SPARC. i ntr-un
caz i n altul apar schemele la nivel intern i extern, doar denumirile difer ntr-o oarecare
msur. Totodat, se observ c factorul uman este surprins i ntr-un caz i altul, cu o
evideniere mai pronunat n cazul propunerii ANSI.

2.4.3. Arhitectura client/server

n paragrafele precedente au fost prezentate dou tipuri de arhitecturi de SGDB, i
anume CODASYL i ANSI. Acum vom cuta s prezentm arhitectura unui sistem de baze de
date dintr-un alt punct de vedere, i anume, se va avea n atenie partajarea activitilor
sistemului de baze de date ntre dou sau mai multe calculatoare, conectate n reea, i care
coopereaz ntre ele. O astfel de arhitectur poate fi privit ca avnd o structur foarte simpl
format din dou pri, partea client din programele sistemului ce mai poart denumirea de
front-end i partea server ce mai poart denumirea de back-end. Acum s vedem ce
semnificaii au cele dou concepte client i server. Clientul reprezint un solicitant sau un
beneficiar de servicii oferite de server, cu alte cuvinte att clientul ct i serverul reprezint
anumite programe ce execut anumite sarcini/activiti. n contextul bazelor de date, Serverul
este tocmai SGDB n sine, instalat pe un anume calculator. Acesta are rolul de a rezolva i
satisface toate cerinele privind funciile de baz, i anume definirea datelor, manipularea
datelor, protecia bazei de date sub aspectele de securitate i integritate etc. ntr-o astfel de
situaie, conceptul de server reprezint o alt denumire a SGDB.
Clienii sunt diversele aplicaii, care ruleaz deasupra SGDB-ului, att aplicaiile
(programele) scrise de utilizatori, ct i cele ncorporate n cadrul SGDB sau chiar altele
furnizate de altcineva. Remarcm faptul c, din punctul de vedere al serverului nu exist nici
o diferen ntre aplicaiile scrise de utilizator i cele ncorporate, toate folosesc aceeai
interfa cu serverul, i anume interfa la nivel extern.
Referitor la cele dou componente, client i server, componenta client se execut
independent pe fiecare staie de lucru client (client workstation). Ea este activat de utilizator
i rmne activ doar pe durata unei sesiuni de lucru, perioad n care rspunde cerinelor
unui singur utilizator. Componena server se execut pe calculatorul server, funcioneaz non
stop i rspunde cerinelor tuturor posturilor de lucru active.
n figura 2.7. este redat arhitectura client/server, ntr-o form sugestiv.
Referitor la ,,aplicaii, acestea pot fi grupate astfel:
- Aplicaii scrise de utilizator, care sunt altceva dect programe de aplicaii obinuite
scrise ntr-un limbaj de programare, cum ar fi C++, SQL, COBOL, PASCAL etc.;
- Aplicaii furnizate de productor i regsite cu denumirea de instrumente (tools)
avnd ca scop de a uura activitatea utilizatorilor de proiectare, creare, ncrcare i
exploatare a bazei de date. Spre exemplificare am putea aminti: generatoare de
rapoarte, generatoare de aplicaii, utilitare pentru ncrcarea masiv a bazei de
date, utilitare pentru reorganizarea bazei de date, componente statistice,
instrumente de tip CASE, foi de calcul tabelar, utilitare pentru grafic interactiv,
utilitare de import/export de date din baza de date etc.
n ceea ce privete distribuirea activitilor sau sarcinilor pe cele dou componente,
front-end respectiv back-end, s-au conturat anumite orientri, astfel: pe front-end ar fi
asigurarea interfeei cu utilizatori, cereri de date, sau prelucrri, procesarea comenzilor de
interogare sau definire a bazei de date, formatarea rspunsurilor primite de la server i
prezentarea lor utilizatorilor etc. Pe back-end sunt rezolvate o serie de sarcini privind

51
preluarea cererilor referitoare la datele solicitate de utilizatori, evidenierea versiunilor
structurii bazei de date, servicii referitoare la asigurarea confidenialitii i integritii bazei
de date etc.

Fig. 2.7. Arhitectura client/server

n ncheierea acestui paragraf, precizm faptul c exist mai multe variante ale
arhitecturii client/server n funcie de numrul de niveluri adoptat. n paragraful urmtor va fi
prezentat arhitectura client/server pentru SGDB-Oracle.

2.4.4. Arhitectura SGBD Oracle

Oracle este un SGBDR complet relaional, extins cu faciliti din tehnologia orientat
obiect, tehnologia OLAP i tehnologia Internet (8i, 9, 10g) care se situeaz pe primele locuri
pe piaa SGBD-urilor. Este operabil pe toat gama de calculatoare sub diferite sisteme de
operare (Unix, Windows, Linux) i este destinat ntreprinderilor medii i mari, existnd i
versiuni pentru ntreprinderile mici (Express Oracle).
Firma Oracle Corp. a fost nfiinat n 1977 n California SUA i este la ora actual
cel mai mare furnizor de software pentru gestiunea informaiilor. Prima versiune de Oracle
comercial a fost realizat n 1979. Firma a implementat de la nceput limbajul SQL, pe care
l-a dezvoltat ulterior fa de standard.
ncepnd cu versiunea 5.0, SGBD Oracle funcioneaz n arhitectur client/server, are
limbaj procedural propriu PL/SQL, are precompilatoare ca interfa cu limbajele de
programare universale. ntr-o configuraie client/server pe dou niveluri componentele client,
respectiv server sunt plasate pe calculatoare diferite ntr-o reea: serverul asigur memorarea
i manipularea datelor, precum i administrarea bazei de date, iar clientul asigur interfaa cu
utilizatorul i lanseaz aplicaii care acceseaz datele din baza de date.
Clieni
Server
Aplicaii
SGDB
Baza de date

Utilizatori finali
Capitolul 2

52
n 1995 Oracle achiziioneaz Express, una din principalele tehnologii OLAP folosite,
iar n iunie 1997 se lanseaz Oracle versiunea 8 care a marcat o nou generaie cu urmtoarele
caracteristici:
- iniiaz trecerea de la arhitectura client/server la arhitectura Network Computing i
Internet Computing. Avantajele acestei arhitecturi sunt: deschidere, standarde,
flexibilitate, interoperabilitate, extensibilitate, pre redus;
- este un sistem deschis (open system) care respect standardele n vigoare
referitoare la limbajele de definire i manipulare a datelor. Suport comunicarea cu
limbajele procedurale de nivel nalt i pune la dispoziie un limbaj procedural
propriu PL/SQL;
- permite dezvoltarea de sisteme de baze de date de orice dimensiune, centralizate
sau distribuite;
- suport zeci de mii de utilizatori;
- are un optimizator de cereri performant ;
- ofer faciliti de salvare/restaurare automate;
- permite partiionarea tabelelor i a indecilor;
- ofer faciliti din tehnologia orientat obiect, tehnologia OLAP i depozite de
date;
- ofer o securitate sporit .
n 1997 firma lanseaz versiunea 8i cu urmtoarele caracteristici:
- prima baz de date pentru Internet, cu suport nativ Java ;
- este operabil pe toat gama de calculatoare, sub orice sistem de operare;
- ofer o gam larg de instrumente pentru dezvoltare aplicaiilor cu baze de date:
instrumente CASE (Oracle Designer 6i), generatoare (Forms &Reports 6i), Java
Developer, Web DB, etc;
- limbajul PL/SQL i limbajul Java sunt integrate;
- ofer faciliti mbuntite pentru depozite de date i inteligena afacerilor ;
n 1999 firma lanseaz prima baz de date cu suport XML. n 2002 se lanseaz
Oracle9i Release 2 OLAP care integreaz toate facilitile OLAP n baza de date relaional
Oracle, iar n 2003 se lanseaz Oracle 10g (ultima versiune 10.2) care integreaz facilitile
oferite de bazele de date relaionale cu facilitile oferite de tehnologia OLAP, data mining i
depozite de date:
- opiunea OLAP include un motor de calcul multidimensional ce permite analize
foarte complexe pe datele stocate n spaiul analitic i are la baz tehnologia
Express. Datele stocate n spaiile analitice sunt manipulate cu ajutorul limbajului
de manipulare OLAP (OLAP DML). Acest limbaj este echivalentul
multidimensional al limbajului PL/SQL i extinde facilitile analitice ale
limbajului SQL. Include funcii pentru analiza seriilor de timp, funcii financiare,
funcii statistice, o mare varietate de metode de agregare (dup nivelul din ierarhie,
dup anumii membrii, etc). Datele pot fi stocate n tabele (tabele de fapte i tabele
de dimensiuni) sub form de schem stea sau fulg de zpad sau n variabilele din
spaiul analitic, iar utilizatorii pot accesa datele printr-o interfa OLAP (de
exemplu instrumentul Oracle BI Beans) sau cu ajutorul limbajului SQL (de
exemplu instrumentul Oracle Discoverer);
- opiunea Data Mining include un motor data mining ce poate fi accesat printr-o
interfa Java. Ofer algoritmi pentru gsirea de tipare n date i pentru a realiza
predicii plecnd de la aceste tipare ;
- opiunea Partitioning permite administratorilor de baze de date s partiioneze
datele pentru a mbunti performana.

53
ncepnd cu versiunea 10g, pentru mbuntirea managementului resurselor s-a
propus utilizarea unei noi tehnici i anume tehnica grid computing care va influena modul de
repartizare i de folosire simultan a resurselor. Aceast tehnic permite adugarea sau
scoaterea discurilor de stocare, cu pstrarea on-line a aplicaiilor. Performanele serverelor
sunt puse la dispoziia mai multor aplicaii i baze de date, ntr-o structur eficient de tip
cluster. Resursele serverelor se aloc n funcie de necesitile firmei i folosind tehnica load
balancing se urmrete ncrcarea diferitelor echipamente, permind ca maina cu cele mai
puine procese s primeasc o nou sarcin.
Oracle a introdus i un instrument special pentru managementul grid-ului denumit
Oracle Grid Control pe care administratorii de sistem l pot folosi pentru monitorizarea i
modificarea ntregii infrastructuri IT ce include resurse eterogene, distribuite geografic.
Resursele nu mai sunt administrate individual, aa cum se realiza n mod tradiional, ci grupat
prin utilizarea unui browser Web. Astfel se poate realiza managementul resurselor de tip:
servere de aplicaii, servere de baze de date, echipamente de stocare, echipamente de reea.
Oracle Enterprise User Security este o component de management centralizat a
privilegiilor de acces a utilizatorilor. Practic un utilizator este creat o singur dat, putnd
avea acces la multiple baze de date existente n grid. Oracle Identity Management
centralizeaz managementul autentificrii i autorizrii utilizatorilor n cadrul unei soluii
integrate, prin intermediul componentei denumite Oracle Internet Directory.
O arhitectur de tip grid computing presupune o multitudine de echipamente hardware
i de aplicaii software care comunic prin intermediul Intranetului sau a Internetului i
permite n mod transparent accesul utilizatorilor la serviciile grid-ului fr ca acetia s
identifice resursele care proceseaz operaiile ntr-un mod unitar.

2.4.4.1. Arhitectura pe componente a SGBD Oracle

n figura 2.8. este prezentat arhitectura pe componente a SGBD Oracle. Nucleul
sistemului conine componentele care dau tipul relaional pentru SGBD Oracle:
- Limbajul SQL
- Limbajul procedural PL/SQL
- Limbajul Java

Fig. 2.8. Arhitectura pe componente a SGBDR Oracle

Baza de date
Instrumente de dezvoltare
Nucleul Oracle (SQL, PL/SQL, Java)
Instrumente de ntreinere i administrare
Capitolul 2

54
SGBD Oracle creeaz i ntreine n mod automat un dicionar de date format dintr-un
set de tabele i tabele virtuale folosite pentru a oferi informaii despre datele din baza de date.
Dicionarul de date este o surs central de informaii pentru Oracle i pentru toi utilizatorii
bazei de date. Se actualizeaz n mod automat atunci cnd o comanda de definire/manipulare
se execut. Utilizatorii acceseaz foarte rar tabelele de baz, deoarece ele sunt normalizate.
Tabele virtuale ale dicionarului de date conin o sintez a informaiilor din tabelele de
baz. Pe aceste tabele virtuale sunt create sinonime publice pentru ca utilizatorii s le acceseze
mai uor. Tabelele virtuale ale dicionarului sunt clasificate n trei categorii:
- Tabele virtuale a cror denumire este de forma USER_XXX. Aceste tabele sunt
accesibile oricrui utilizator i n general se refer la obiectele aparinnd
utilizatorului curent. De exemplu, tabela virtual USER_TABLES conine
informaii despre tabelele utilizatorului curent:
SELECT TABLE_NAME FROM USER_TABLES;
- Tabele virtuale a cror denumire este de forma ALL_XXX. Aceste tabele sunt
accesibile oricrui utilizator i ofer informaii despre obiectele la care utilizatorii
au acces prin drepturi publice (PUBLIC) sau explicite i roluri. De exemplu, tabela
virtual ALL_USERS conine informaii despre utilizatorii bazei de date:
SELECT USERNAME FROM ALL_USERS;
- Tabele virtuale a cror denumire este de forma DBA_XXX. Aceste tabele ofer
informaii despre toate obiectele bazei de date i sunt folosite de administrator sau
de orice utilizator cu drept de SELECT ANY TABLE. De exemplu, tabela virtual
DBA_DATA_FILES conine informaii despre structurile fizice ale bazei de date :
SELECT * FROM DBA_DATA_FILES;
- Tabele virtuale dinamice (dynamic performance views) care se actualizeaz
automat i ofer informaii legate de performana sistemului. Aceste tabele sunt
accesibile numai administratorului bazei de date. De exemplu, tabela virtual
V$SESSION .
Instrumentele de dezvoltare permit dezvoltarea aplicaiilor cu baze de date. Oracle
Developer Suite integreaz ntr-un singur pachet o serie de instrumente de dezvoltare i
anume:
- Oracle Warehouse Builder este un instrument pentru modelarea i generarea
depozitelor de date, precum i pentru ncrcarea datelor n depozite de date ;
- Oracle Reports este format din: Reports Developer pentru crearea rapoartelor i AS
Report Services pentru distribuirea rapoartelor pe Internet. Utilizatorii pot accesa
rapoartele utiliznd un browser Web (de exemplu Internet Explorer) sau pot alege
formatul de afiare (HTML, XML, pdf, etc) ;
- Oracle Discoverer este un instrument pentru raportare i interogare ad-hoc. Este
proiectat pentru a fi utilizat att de dezvoltatori (Discoverer Administrator) ct i
de utilizatorii finali (Discoverer Desktop). Poate accesa att date relaionale ct i
multidimensionale.
- Oracle JDeveloper este un instrument ce permite dezvoltarea de aplicaii utiliznd
limbajul Java.
- Oracle Forms Developer (figura 2.9.) permite generarea de videoformate i
meniuri, utiliznd limbajul SQL, PL/SQL i Java.
- Oracle Designer este un instrument CASE destinat analitilor de aplicaii i ofer
suport pentru toate etapele de realizare a unui sistem informatic (analiza,
proiectare, implementare). Pentru analiza static a sistemului utilizeaz diagrama
entitate-asociere, pentru analiza funcional i dinamic a sistemului utilizeaz
diagrama de procese (Process Modeler), diagrama ierarhiei de funcii (Function
Hierarchy Diagrammer). Pentru etapa de proiectare folosete Database Design

55
Transformer i Application Design Transformer, instrumente ce transform
modelul entitate-asociere n definiii de tabele, chei primare, chei externe i
diagrama de funcii n definiii de module ale aplicaiei. Pentru etapa de
implementare folosete Design Editor pentru a genera scripturile necesare pentru
creearea bazei de date (a tabelelor) i pentru a genera codul corespunztor
modulelor aplicaiei. Ca metodologie de analiz i proiectare se utilizeaz
metodologia CDM (custom development methodology), o metodologie structurat
ce utilizeaz ca tehnici: tehnica entitate-asociere, matrici de coresponden, etc.
Oracle Designer este integrat cu Oracle Forms Developer i Oracle Reports
Developer i utilizeaz o configuraie client/server. Pe server exist un depozit
central (repository) un set de tabele i alte obiecte stocate n mai multe spaii
tabel distincte ale bazei de date i o interfa API care const din pachete PL/SQL
i subprograme ce permit utilizatorilor s manipuleze datele din repository pentru
a asigura integritatea datelor. Repository stocheaz toate obiectele i informaiile
necesare pentru proiectarea, modelarea i generarea bazei de date i ale aplicaiilor
cu baze de date. Oracle Designer permite definirea i generarea unrmtoarelor
tipuri de baze de date: Oracle 7, 8, 8i, 9i, 10g, DB2, SQL Server i a urmtoarelor
tipuri de aplicaii: videoformate i biblioteci pentru Oracle Forms Builder, aplicaii
Visual Basic, aplicaii Web.
- Oracle BI Beans este un set de componente Java Beans ce i ajut pe dezvoltatori
s implementeze rapid aplicaii analitice, accesnd motorul OLAP.
- Oracle Business Intelligence Spreadsheet Add-In este un instrument care permite
utilizatorilor Excel s execute analize pe datele stocate n spaiul analitic;

Instrumentele pentru ntreinere i administrare sunt destinate ntreinerii i bunei
funcionri a bazei de date:
- Oracle Enterprise Manager Database Control ofer suport pentru administrarea
bazelor de date distribuite, monitorizarea evenimentelor n timp real, analiza
performanelor i analiza datelor (figura 2.10., figura 2.11.). Permite unui
administrator de baze de date s gestioneze mai multe baze de date, noduri, servere
de pe o singur main (nodul central).
- Oracle Label Security permite asigurarea securitii la nivel de tuplu bazndu-se
pe tehnologia etichetrii datelor. Se pot utiliza etichete de tip confidenial, top
secret pentru a clasifica informaiile i pentru a restriciona accesul la aceste
informaii. Oracle Label Security stabilete accesul la tupluri n funcie de eticheta
coninut n tuplu, eticheta asociat cu fiecare sesiune a bazei de date i n funcie
de privilegiile stabilite.

Instrumente pentru configurare i migrare :
- Oracle Database Configuration Assistant se utilizeaz pentru a crea, a configura
sau a terge o baz de date (figura 2.12.).
- Oracle Administration Assistant for WNT se utilizeaz pentru a crea administratori
de baze de date, operatori, utilizatori i roluri n Windows NT. De asemenea,
permite gestionarea serviciilor bazei de date, pornirea/oprirea bazei de date, etc;
- Oracle Database Upgrade Assistant se utilizeaz pentru a se trece de la o
versiunea la alt versiune a bazei de date.

Capitolul 2

56

Fig. 2.9. Un exemplu de videoformat creat cu Oracle Forms Developer

Fig. 2.10. Oracle Enterprise Manager Database Control-faciliti pentru analiza
performanelor serverului

57

Fig. 2.11. Oracle Enterprise Manager Database Control-faciliti pentru administrarea bazei
de date

Fig. 2.12. Instrumentul Database Configuration Assistant

n tabelul 2.1 i n figura 2.13. este prezentat platforma Oracle pentru dezvoltarea
aplicaiilor cu baze de date
Capitolul 2

58
Tabelul 2.1. Platforma Oracle pentru dezvoltarea aplicaiilor
Tipul aplicaiei Instrumentul utilizat
Sisteme informatice
tranzacionale
Oracle Developer Suite
componente Java JDeveloper, Oracle Application Server
site-uri Web Oracle Application Server Portal, Oracle Database Server
Sisteme informatice
pentru inteligena
afacerilor (BI)
Instrumente BI (Reports Developer, Reports Services, BI Beans, BI
Spreadsheet Add-In, Data Miner, BI Discoverer, XML Publisher)
Aplicaii BI preconstruite (Oracle Daily Business Intelligence/DBI,
Corporate Performance Management, PeopleSoft Enterprise
Performance Management, Oracle Activity Based Management, etc

Fig. 2.13.. Platforma Oracle pentru dezvoltarea aplicaiilor

Utilizatorii bazei de date Oracle pot executa:
- simple comenzi SQL folosind un instrument (de exemplu SQL Developer (figura
2.14.));
- o aplicaie ce conine comenzi SQL (de exemplu o aplicaie realizat cu Oracle
Forms Developer).
Un utilizator Oracle se poate conecta la serverul Oracle n mai multe moduri:
- se conecteaz direct la server (pe maina pe care este instalat serverul Oracle
Accesul la informaii

Instrumente BI Aplicaii BI preconstruite
Oracle DBI
Corporate Performance Management
PeopleSoft Enterprise Performance
Management
Data
Miner
BI Discoverer
XML
Publisher
Reports
Services

Baza de date
Portal
Oracle
Warehouse
Builder

Surse de date
Developer Suite
Oracle Reports
Developer
Oracle
Discoverer
Administrator
BI Beans
Oracle BI
Spreadsheet Add-In
OLAP Data
Mining
relaional
Oracle Application Server

59
folosind de exemplu instrumentul SQL Developer );
- folosete o conexiune client/server (de exemplu utilizatorul lanseaz instrumentul
Oracle Forms Developer (modulul Forms Builder) instalat pe client care acceseaz
baza de date stocat pe server);
- folosete o conexiune pe trei niveluri unde clientul comunic cu un server de
aplicaii (Oracle AS) care este conectat prin reea la serverul de baz de date.
Clientul poate fi un simplu browser (de exemplu Internet Explorer) care utilizeaz
o aplicaie rezident pe serverul de aplicaii (de exemplu Oracle e-business suite)
prin care sunt accesate datele stocate pe serverul de baz de date ).

Oracle AS este un server de aplicaii bazat pe Java i const dintr-un set de servicii
(servicii pentru comunicaii, servicii pentru prezentare, servicii pentru managementul datelor
pentru a reduce ncrcarea pe instana bazei de date, etc) i utilitare care pot fi utilizate pentru
a implementa aplicaii ntr-un mediu distribuit.
Oracle AS Portal, care a evoluat din Web DB, este un mediu de dezvoltare a portal-
urilor, bazat pe standardul J2EE. Conine portlet-uri ce pot fi mbuntite, ce pot accesa surse
de date externe prin JDBC sau drivere native Oracle 9i/10g. De asemenea, conine facilitatea
OmniPortlet prin care se pot accesa date stocate n foi de calcul tabelar i documente HTML
i publicarea acestor date n diferite formate.
Oracle e-business Suite este un pachet software integrat de mare complexitate ce ofer
suport integrat pentru activitile de baz ale unei firme: management financiar (contabilitate
general, contabilitatea furnizorilor, contabilitarea clienilor, gestiunea lichiditilor, mijloace
fixe); aprovizionare; gestiunea stocurilor; desfacere; producie; managementul proiectelor de
investiii; analiz financiar (analiz de indicatori de performan financiar); managementul
resurselor umane i salarizare; managementul relaiilor cu clienii (marketing, vnzri,
service, etc), etc. De exemplu, modulul pentru managementul resurselor umane i salarizare
(HRMS) include urmtoarele componente: HR (resurse umane), Payroll (Salarizare), Self
service HR (angajaii au acces on-line la aplicaia HR i pot modifica on-line informaiile
despre ei); Learning Management (managementul cursurilor); iRecruitment (recrutare on-
line); Oracle Timer &Labour (pontaje) i Daily Business Intelligence un set de module de
raportare i pagini portal capabile de a prezenta o sintez zilnic a unei afaceri

2.4.4.2. Structura fizic a BD Oracle

Baza de date Oracle este identificat printr-un nume (parametru DB_Name din fiierul
de parametri) i este format din urmtoarele tipuri de fiiere:
- Fiiere de date (data files). O baz de date Oracle are mai multe fiiere de date
care conin toate datele stocate n baza de date (tabele, indeci, sinonime, triggeri,
proceduri stocate, funcii stocate, pachete, etc). Un fiier de date poate fi asociat cu
o singur baz de date i se poate extinde n dimensiune n mod automat. Unul sau
mai multe fiiere de date corespund unui spaiu tabel (tablespace). Fiierele de date
stocheaz i imagini ale datelor nainte de a fi modificate de tranzaciile curente.
nainte de a face o modificare, procesul server salveaz vechea valoare ntr-un
segment de rollback. Aceast imagine este folosit pentru a anula modificrile,
dac tranzacia este anulat i pentru restaurarea bazei de date.
- Fiiere jurnal de tranzacii. O baz de date are un set de 2 sau mai multe fiiere
jurnal de tranzacii n care sunt nregistrate toate modificrile fcute asupra datelor
din baza de date. Aceste fiiere sunt foarte importante n procesul de restaurare a
Capitolul 2

60
bazei de date.
- Fiierele jurnal de tranzacii arhivate sunt copii ale fiierelor jurnal de tranzacii
on-line. Dac baza de date este configurat la creare cu opiunea ARCHIVELOG
atunci fiierele jurnal de tranzacii on-line sunt arhivate automat.
- Fiierul de control conine informaii despre structura fizic a bazei de date
(numele bazei de date, numele i locaia fiierelor de date i a fiierelor jurnal de
tranzacii), informaii pentru salvri/restaurri utilizate de Recovery Manager. Ori
de cte ori o instan Oracle este pornit, fiierul ei de control este utilizat pentru a
identifica baza de date i fiierele de date respectiv fiierele jurnal de tranzacii ce
trebuie deschise. Oracle recomand cel puin 2 fiiere de control identice.
- Un fiier de parametri utilizat pentru a defini caracteristicile unei instane Oracle
- Un fiier de parole pentru autentificare utilizatorilor.

Fig. 2.14. Instrumentul SQL Developer

Administrarea bazelor de date

61

Capitolul 3

3.1. Sarcinile administratorului bazei de date (ABD)

Sarcina de organizare i administrare a unei baze de date revine unei persoane
sau grup de persoane cu experiena bogat n activitatea de analiz, pr oiectare i
programare.
Pentru rezolvarea acestei sarcini este necesar o funcie de administrare a datelor
care este realizat de regul, de o persoan sau de un grup de persoane denumit n mod
generic, administratorul bazei de date (ABD/DBA). Administratorul rspunde de toate
activitile i operaiile referitoare la baza de date pe care o gestioneaz, precum i de
performanele ntregului sistem implementat. Funcia de administrare a datelor a aprut de fapt
att din necesitatea proiectrii i ntreinerii structurii bazelor de date precum i din necesitatea
realizrii controlului structurii generale a datelor.
Numrul de persoane variaz n funcie de dimensiunea i complexitatea bazelor de
date i a sistemului prin care acestea sunt gestionate.
Membrii grupului de administrare sunt orientai fie pe probleme utilizator, fie pe
probleme tehnice pentru asigurarea unor bune servicii de supervizare funcional asupra
performanei sistemului de baze de date la un cost rezonabil.
n ultimul timp se vorbete de dou tipuri de responsabiliti de administrare a
datelor i anume:
- administrare a datelor, care se refer la aspectele conceptuale ale proiectrii, care nu
vizeaz un anumit sistem de gestiune a datelor (schema conceptual a datelor);
- administrare a bazei de date, care se refer la deciziile i activitile care conduc sau
au impact direct asupra bazei de date operaionale viznd activiti de proiectare
tehnic i implementare n care e implicat SGBD-ul.

Sarcinile ce revin administratorului bazei de date pot fi grupate astfel:
n etapa de concepie a bazei de date:
- definete obiectivele sistemului informatic al crui nucleu urmeaz s fie o
baz de date;
- ajut la definirea cerinelor de aplicaie la definirea i descrierea datelor;
- evalueaz cerinele de aplicaie ale tuturor utilizatorilor, definete
dicionarul de date i relaiile logice dintre diferitele categorii de date;
- definete structura conceptual/virtual a bazei de date innd cont de
cerinele tuturor utilizatorilor;
- mpreun cu inginerul de sistem definete structura fizic a bazei de date,
regulile de apartenen la spaiul fizic, relaiile fizice ntre nregistrrile din
Capitolul 3

62
baza de date, tehnicile de comprimare a datelor n vederea utilizrii ct mai
raionale a memoriei externe;
- stabilete procedurile de validare a datelor;
- elaboreaz concepia de protecie i securitate a datelor;
- evalueaz concepia de ansamblu a sistemului.
n etapa de implementare a bazei de date:
- elaboreaz i definitiveaz documentaia de sistem;
- definete strategia i tactica de implementare a sistemului informatic;
- asigur ncrcarea bazei de date plecnd de la fiierele deja create sau de la
culegerea datelor din documentele primare;
- testeaz lanurile de programe i evalueaz performanele bazei de date.

n etapa de exploatare i meninere n funciune:
- autorizeaz accesul la baza de date i asigur protecia i securitatea
datelor;
- asigur utilizarea raional a spaiului de memorie rezervat bazei de date;
- asigur funcionarea bazei de date la nivelul performanelor stabilite n
proiect.

3.2. Funciuni de administrare a bazelor de date

Administrarea bazelor de date implic mai multe funcii:
- funcii de proiectare, definire i implementare a bazei de date;
- funcii de proiectare a subsistemelor de administrare a bazei de date;
- funcii de asistent la realizarea aplicaiilor care utilizeaz baza de date;
- funcii de monitorizare a utilizrii bazei de date;
- funcii de perfecionare a performantelor exploatrii bazei de date;
- funcii de asistare utilizator;

Funcia de proiectare, definire i implementare a bazei de date const n:
- definirea modelului conceptual al datelor sistemului;
- definirea schemei bazei de date;
- definirea subschemelor la nivelul fizic al aplicaiei;
- stabilirea liniilor directoare de proiectare logic a sistemului de baze de date prin
indicarea organizrii logice a bazei de date, a numrului de realizri pentru fiecare
entitate, a perioadelor de pstrare a datelor;
- descrierea datelor (coninut i structur) din baza de date ntr-un limbaj de descriere a
datelor (LDD) prin definirea atributelor logice i fizice ale datelor, a legturilor
dintre atributele entitilor si a criteriilor de validare;
- specificarea modului de translatare a modelului logic intern n model fizic intern, a
metodelor de acces, controlului securitii i integritii, modelului de alocare a
spaiului de memorare, redundana proiectat, tipuri de erori ce pot apare, tehnici
de compactare;
- realizarea schemelor de ncrcare, determinarea spaiilor primare de ncrcare;
- determinarea capacitii de memorare disponibil;
- determinarea timpului de acces admisibil;
- aprecierea dimensiunii spaiului de memorare suplimentar necesar n procesul de

63
ntreinere a bazelor de date;
- specificarea formatului datelor de intrare i a modului de ncrcare a acestora;

Funciile de proiectare a subsistemului de administrare a bazelor de date se refer
la:
- proiectarea bazei de date pentru satisfacerea cerinelor utilizatorilor i crearea
dicionarului de date asociat acesteia;
- definirea regulilor de utilizare a bazei de date i restriciilor de acces;
- proiectarea sistemului de securitate pentru protejarea bazei de date mpotriva
distrugerilor, accesului neautorizat i autorizat i a modificrilor;
- proiectarea pentru protejarea mpotriva impreciziei, dispariiei datelor, pentru
semnalarea datelor suspecte i pentru adaptarea bazei de date la noile cerine;
- proiectarea software-ului pentru ntreinerea bazei de date, reorganizare.

Funciile de asistare la realizarea aplicaiilor care utilizeaz baza de date se
refer la:
- participarea la identificarea cerinelor relative la baza de date pentru aplicaiile
existente, ct i pentru cele viitoare, n scopul realizrii integritii datelor;
- verificarea dac cerinele de date ale programelor de aplicaie noi pot fi satisfcute de
baza de date existent;
- verificarea dac cerinele de rapoarte ale utilizatorilor pot fi satisfcute de SGBD-ul
utilizat.

Funcia de monitorizare a utilizrii bazei de date const n
- asigurarea integritii, securitii bazei de date;
- mbuntirea performanelor de exploatare.
Monitorizarea trebuie s includ:
- asigurarea duplicrii datelor i pstrarea lor prin utilizarea tehnicilor de
salvare/restaurare;
- asigurarea integritii bazei de date printr-un control centralizat, validarea tuturor
datelor de intrare, examinarea periodic a datelor pentru asigurarea corectitudinii
datelor, pentru actualizarea, modificarea sau tergerea unora.
Monitorizarea performantelor bazei de date const efectiv n:
- statistici relative la timpul de acces;
- frecvena citirilor/scrierilor;
- analiza aspectelor legate de tranzacii i efectuarea lor;
- mesajele care apar;
- analiza costului de obinere a anumitor date.

Perfecionarea performantelor de exploatare a bazei de date se poate face prin:
- optimizarea structurii fizice a bazei de date;
- modificarea dimensiunilor buffer-elor;
- revederea procedurilor de restaurare/salvare.

Funcia de asistare utilizator cuprinde activiti de instruire a personalului tehnic
privind:
- conceptele bazei de date;
- terminologia bazei de date;
- structura bazei de date;
- procedee de memorare i regsire a datelor n baza de date.
Capitolul 3

64
3.3. Instrumente la dispoziia administratorului de
baze de date

Pentru a realiza funciile prevzute anterior, administratorul bazei de date trebuie s
aib la dispoziie diferite instrumente ce pot fi independente sau incluse n SGBD. E1 trebuie
s dispun de:
- programe de ncrcare ;
- rutine de reorganizare (pentru reorganizarea coninutului bazei de date, pentru
recuperarea spaiului ocupat de datele terse;
- rutine de jurnalizare pentru nregistrarea fiecrei tranzacii n baza de date i a
identificrii utilizatorilor care efectueaz aceste tranzacii i pentru nregistrarea strii
bazei de date nainte i dup efectuarea acestor tranzacii;
- rutine de restaurare;
- rutine de iniializare, editare;
- rutine de analiz i comparare.
De exemplu, pentru SGBD-ul ORACLE unele dintre aceste instrumente se
concretizeaz n Export, Import, SQL*Loader etc.
Dicionarul de date este de asemenea un instrument indispensabil pentru organizarea
coleciilor de date, reflectarea modului de memorare a acestora i regsirea informaiilor
referitoare la respectivele date.
Dicionarul de date este de fapt o metabaz i conine n general informaii despre
obiectele din sistem. Este util att administratorului ct i utilizatorilor, acetia putnd
realiza:
- obinerea de informaii despre formele de reprezentare a datelor;
- caracteristicele datelor;
- definirea i structura datelor;
- contextele de utilizare a datelor;
- legturile dintre date i mediu;
- utilizatorii bazei de date.
Persoanele care se ocup de administrarea bazelor de date trebuie s posede o foarte
bun cunoatere a modului de funcionarea sistemului informatic care conine baza de date,
a coninutului structurii bazei de date, cunotine tehnice foarte bune deoarece
implementarea bazei de date necesit un nivel de competen ridicat n domeniul gestionrii
datelor.

3.4. Protecia bazelor de date

Protecia bazelor de date presupune :
- asigurarea confidenialitii datelor (protejarea mpotriva accesului neautorizat la
date);
- asigurarea integritii datelor (protejarea mpotriva deteriorrii coninutului
informaional ca urmare a unor defecte de echipament sau erori de program).
Protecia unei baze de date este una din sarcinile administratorului baze de date.


65
3.4.1. Asigurarea integritii datelor din baze de date

Asigurarea integritii datelor se impune n cazul unor cderi de echipament sau
software i se poate realiza prin procedeul copiilor de siguran sau a fiierelor de urmrire
(jurnale) cu meniunea c (figura 3.1.):
- realizarea fiierelor de urmrire se face de ctre MONITOR ntr-o form decis de
administrator ;
- realizarea copiilor de siguran i a restaurrii se face cu programe utilitare puse la
dispoziia administratorului bazei de date.

Integritatea BD a impus noi abordri n contextul lucrului n reea i a apariiei
produselor de tip virus. Nu numai cderile de echipamente, ci i aciunea expres a unor
factori distructivi poate pune n pericol existena unor informaii nealterate n BD. Dup
cum se tie, viruii informaiei acioneaz asupra BD similar programelor executabile
obinuite. Poate fi vorba de virui generali care se implanteaz n orice program executabil,
sau de virui specifici SGBD. Efectele distructive ale acestora sunt mult mai ample asupra
BD, comparativ cu cele asupra fiierelor individuale, iar efortul recuperrii informaiilor
devine colosal. Iat de ce pstrarea unor copii de siguran, pe suporturi ferite de aciunea
viruilor i cu protecie fizic la scriere, se recomand cu i mai mare acuitate.
Este contraindicat folosirea unor produse software de provenien dubioas, precum i
dispunerea unei BD pe aceeai partiie de disc unde se afl i produse nespecifice SGBD. Pe
ct posibil, datele vor fi separate de programe, iar rularea programelor n acces extins asupra
BD s fie totdeauna supravegheat, evitndu-se astfel 'mprumutarea' drepturilor de acces,
unor virui implantai n aceste programe.
Prezena nejustificat i frecvena unor sectoare defecte, modificarea lungimii unor
programe, ncetinirea ritmului de lucru cu BD, mesaje de interdicie a unor accese la BD
nesolicitate expres de utilizator, reacii spontane necaracteristice lucrului obinuit cu o
baz de date sunt tot attea simptome care impun oprirea rapid a oricrei prelucrri asupra
BD i declanarea unor proceduri de salvare. Pentru aceasta se vor folosi numai programe de
rezerva, aflate pe medii externe despre care se tie c nu sunt contaminate.
Folosirea unor produse de devirusare se va face numai cnd este garantat
proveniena acestora, ntruct multe din acestea sunt i ele nsele virui.
Pentru SGBD-urile care permit stocarea programelor att n cod surs, ct i n forma
executabil, se recomand doar pstrarea codului surs, ntruct este cunoscut inapetena
viruilor fat de fiierele neexecutabile. Este indicat s nzestrai programele de lucru
asupra BD cu mesaje privind derularea fazelor, astfel nct s poat fi semnalat orice
activitate suspect, desfurat n paralel cu cea solicitat expres de utilizator. Nu este indicat
protecia BD prin produse virus, deoarece n anumite contexte greu de anticipat efectul
aciunii lor distructive se poate rsfrnge asupra propriului nostru interes! Nu n ultimul
rnd, msurile organizatorice viznd instruirea personalului de serviciu, asigurarea
controlului periodic al activitii, pstrarea i controlul folosirii documentelor i purttorilor
de informaii pot contribui ntr-o msura hotrtoare la protecia fiierelor i bazelor de date.

Capitolul 3

66

Fig. 3.1. Tehnici de asigurare a integritii datelor

3.4.2. Asigurarea confidenialitii datelor din baze de date

Pentru o BD, problema confidenialitii devine complex datorit numrului
mare de utilizatori, conexiunilor multiple ntre informaii, precum i datorit flexibilitii de
interogare oferite de SGBD i accesului concurenial.
Sunt recunoscute cel puin patru clase de mecanisme distincte ale asigurrii
confidenialitii datelor :
- autorizarea sau controlul accesului, cuprinznd tehnicile de validare a identitii
utilizatorilor, naintea accesului la BD;
- controlul fluxurilor de date viznd supravegherea cilor de circulaie a informaiilor
n sistem, pentru a evita ca informaiile s ajung i la dispoziia neautorizailor ;
- controlul de inferen, prin care se studiaz posibilitile de deducere logic a unor
informaii secrete, pornind de la informaiile la care este permis accesul;
- criptografierea, prin care se asigur codificarea informaiilor pe timpul stocrii sau
transportului, astfel nct numai posesorii parolei pot s le descifreze.
Vom trece pe scurt n revist aspectele principale care apar n cadrul fiecrei categorii
de metoda de securizare a BD.

n cadrul autorizrii i revocrii unor drepturi de acces problemele care trebuie
soluionate se refer la:
- nivelul la care se aplic: la nivelul ntregii BD, a unei relaii, doar asupra unor tupluri
etc.;
- tipul privilegiilor ce pot face obiectul autorizrii/revocrii (citire, scriere, modificare,
BAZA DE
DATE

BAZA DE
DATE

M

I

R

O

R

Copie Activ a
BAZEI DE DATE

a) Copii multiple la diverse momente de timp
BAZA DE
DATE
AFTER
BEFORE
QUICK
JURNALE
c) Jurnalizare

b) Copii pe alte medii (streamer, tape)

67
adugare, tergere, creare de index, execuia unui program);
- modul de transmitere a privilegiilor altor utilizatori, de ctre un utilizator care le-a
dobndit deja.
Se practic sisteme ierarhice sau reea pentru urmrirea transmiterii drepturilor de
acces, pentru a evita supercentralizarea puterii sau dobndirea unor drepturi pe mai multe ci,
ceea ce trebuie cunoscut n momentul unor reorganizri a BD.
- posibiliti de revocare a unor privilegii, cu efecte n lan pentru toi utilizatorii
autorizai de utilizatorul vizat explicit de revocare.

n esen, controlul fluxurilor de date ntr-o BD urmrete evitarea accesului unei
persoane neautorizate la o informaie, prin intermediul altei persoane, care are acces la aceasta
informaie i i face o copie, sustrgndu-se responsabilitii pentru acest act.
Problema apare datorit faptului c privilegiile le-am atribuit n exclusivitate
utilizatorilor, dei ele sunt i un apanaj al resurselor BD, la care se refer. Dificultatea
rezolvrii este sporit prin faptul c pot exista i canale secrete de transmitere sau canale
volatile, de tipul memoriei interne sau terminalelor (informaiile putnd fi preluate nu din
BD, ci din buffere n momentul n care un utilizator autorizat le acceseaz sau pur i simplu
copiindu-le de pe un ecran n timp ce sunt consultate de persoane ndreptite s dispun de
ele).
Pentru a mbunti controlul accesului la o BD, va trebui s legm acest acces nu
numai de utilizatori i resurse, ci i de factorul timp i de diferitele ipostaze n care se
poate afla o informaie ntr-un sistem de calcul.
Modelele mai complicate de asigurare a confidenialitii datelor opereaz cu mai
multe categorii de obiecte protejate: utilizatori, programe, terminale, fiiere etc., cu clase de
securitate (nesecret, confidenial, secret, strict secret, secret de stat) aplicat fiecrei categorii
de resurse informaionale, cu tipuri de acces difereniate (parial, cu aprobare etc.) i cu o
mulime de stri n care se poate afla o informaie. In aceasta manier, accesul apare
definit ca o mulime de cereri ale utilizatorilor N, pentru operaiile O, asupra resurselor R,
ntr-un moment cnd sistemul se afl n starea S.
Caracterul secret al informaiilor depinde i de gradul de agregare. Dac, spre
exemplu, informaiile despre o colectivitate statistic nu au caracter secret, n schimb
informaiile despre o persoan din aceast colectivitate nu sunt de uz public. Indiferent care ar
fi procedeul de sintetizare a informaiilor la nivelul colectivitii, acestea vor purta totui n
ele esen informaiilor elementare din care provin. Rezult c, oricnd, abilitatea unui
utilizator n deducii logice, poate conduce la obinerea de informaii confideniale pornind
de la informaii pur statistice.
Ideea c fiecare cerere este formulat n termenii unor condiii de selecie conduce i
la posibilitatea ca primind condiii foarte restrictive s se rspund cu foarte puine tupluri
care le ndeplinesc. Punnd o succesiune de ntrebri, subcolectivitilor rmase n discuie
pn la un moment dat, pot fi deduse informaii particulare. Pentru nlturarea acestei
posibiliti au fost gndite SGBD care nu rspund la cereri n cazul n care rezultatul este sub
un anumit prag de semnificaie. Acest prag trebuie neles i n sensul complementaritii,
deoarece punnd ntrebri, negaii ale celor n care este interesat un intrus, rspunsurile
cuprinznd aproape toi indivizii colectivitii sunt la fel de 'utile' n deducerea informaiilor
secrete.
Un alt mod de deducere a informaiilor confideniale foarte frecvent folosit se bazeaz
pe calcule statistice. Relaiile existente ntre caracteristicile cantitative stocate n BD pot
permite prin succesiuni de calcule accesul la informaii certe sau foarte apropiate de cele
reale.
Capitolul 3

68
Lupta mpotriva unor tehnici de ,,vnare de informaii nu a fost din pcate ncheiat.
Ar trebui practic ca un SGBD s rspund sau nu la o ntrebare i n funcie de ntrebrile la
care s-a rspuns anterior, lucru foarte costisitor de implementat. Utilizarea unor informaii
pariale cunoscute din alte surse i coroborarea lor cu cele furnizate din BD complic i mai
mult mecanismul protejrii informaiilor.
Problema rmne deschis n continuare, ceea ce s-a reuit pn n prezent fiind
gsirea unor tehnici de descurajare, prin costul obinerii informaiilor secrete.
Amintim alte cteva procedee folosite n controlul inferenei:
- partajarea BD n clase, cu numr critic de elemente, astfel nct nu vor fi niciodat
furnizate informaii despre subgrupe, ci doar despre grup n totalitate. Alegerea grupelor n
concordant cu cerinele informaionale ridic totui destule probleme; distorsionarea voit
a rezultatelor, pe baza unor distribuii aleatoare, astfel nct informaiile furnizate s aib
doar valoare statistic. Pentru cei autorizai ns, rezultatele trebuie s fie exacte, SGBD
fcnd distincie ntre categoriile de utilizatori;
- eantionarea aleatoare a BD, astfel nct un utilizator neavizat s nu poat obine
informaii individuale, ci doar la nivelul unui eantion, a crei alegere scap de sub controlul
utilizatorului.

Existena multor algoritmi de criptare implementai soft sau hard asigur ntr-o
mare msur securitatea informaiilor pe timpul stocrii sau transportului acestora. Tehnicile
de criptografiere au cunoscut un avnt nemaintlnit odat cu exploatarea BD prin reele de
calculatoare. De cele mai multe ori aceste tehnici asigur simultan i compactarea
informaiilor, contribuind la creterea eficienei stocrii datelor.

Baze de date relaionale

69

Capitolul 4

O multitudine din sistemele de baze de date de astzi sunt bazate pe modelul relaional
propus de E.F. Codd n 1970 cu intenia de a pune la dispoziie elementele necesare pentru a
asigura independena datelor. Un model relaional se bazeaz pe dou concepte (figura 4.1):
relaie i tabel, care difer prin natura lor dar care au o puternic legtur prin aceea c:
- noiunea de relaie este formal, formalitate dat de proveniena sa din teoria
matematic a mulimilor, care a permis definirea unei teorii suport a modelului;
- noiunea de tabel care este simpl i intuitiv, conform provenienei sale din
activitile curente, oferind o nelegere natural inclusiv utilizatorilor finali.

Fig. 4.1. Relaia ANGAJAT

Prezena simultan a celor dou noiuni a contribuit la marele succes al modelului relaional.

4.1. Domeniu, atribut, valoare

Un sistem relaional este un sistem n care:
- datele sunt percepute de utilizatori ca tabele;
Capitolul 4
70
- operatorii utilizai pentru manipulare (de exemplu, regsire) sunt operatori care
genereaz noi tabele pornind de la cele existente.
Cea mai mic unitate de date manipulabil n modelul relaional este valoarea
individual, adic valoarea considerat atomic prin faptul c este nedecompozabil. O valoare
este considerat nedecompozabil dac nici unul din algoritmii care o prelucreaz nu utilizeaz
pri ale sale cu un neles anume. De exemplu dac avem valoarea 05051987 care este o dat
de natere (zi, lun, an) atunci aceast valoare este o dat atomic dac nu avem nevoie, pe
parcursul utilizrii sale, numai de unul din elementele care o compun (de exemplu an) ci o
utilizm ca atare, ca un tot.
Definiia relaiei, prin teoria matematic a mulimilor pe care se bazeaz, face apel la
dou concepte de baz: domeniu i atribut. Un domeniu (D
i
) este definit ca mulimea obiectelor
de acelai tip. Semnificaia domeniului este urmtoarea: dac dou sau mai multe atribute
primesc valori din acelai domeniu atunci sunt admise i au sens operaiile de comparare (i alte
operaii ca jonciune, proiecie etc.) ntre aceste atribute (despre atribute putem spune c sunt
semantic comparabile). Un atribut (A
i
) reprezint o interpretare anume a obiectelor domeniului.
Deoarece fiecare definire de atribut (A
i
) trebuie s conin o referire la domeniul corespondent,
la definirea bazei de date este necesar specificarea (ca parte component a definirii bazei de
date) tuturor domeniilor identificate n faza de analiz a sistemului.
De exemplu, n figura 4.1 domeniile sunt MRCI, NUME, SEX, DATE, SALARII,
FUNCII, LOCURI_DE_MUNC. Aceste domenii pot fi considerate domenii specifice ale
relaiei. La aceste domenii avem asocierile de atribute evideniate n figur.
Dintre aceste asocieri putem distinge atributele NR#, i SO i EF care iau valori din
acelai domeniu MRCI. Denumirile diferite ale atributelor ne dau semnificaia valorilor din
doemniul MRCI astfel:
- NR#, este marca (sau codul numeric personal - CNP) unui ANGAJAT;
- SO, n cazul n care n tabel (relaie) sunt nregistrate i datele soului (soiei) va
conine marca acestuia (acesteia);
- EF, marca efului fiecrui angajat.
Domeniile identificate n figura 4.1 pot fi generalizate prin tipurile de mulimi
matematice din care i iau valori astfel:
- ntregi:MRCI, SALARII, LOCURI_DE_MUNC, EF;
- iruri de caractere: NUME, SEX, FUNCIE;
- Date calendaristice: DATE.
n acest context fiecare domeniu este o mulime infinit, mulime care nu poate fi
stocat n practic pe calculator care are resurse finite. Din aceste considerente domeniul de
definiie a atributelor poate fi considerat o submulime a domeniilor generalizante din care fac
parte. Specificarea practic a domeniilor generalizante este efectuat n practic prin asocierea
unui tip de dat fiecrui atribut sau prin definirea subdomeniilor. Definirea practic a
domeniilor specifice este efectuat prin asocierea la fiecare atribut a unor restricii sau
constrngeri cum ar fi apartenena la un interval de valori, list de valori posibile, date
calendaristice minime etc.
n figura 4.2 domeniile sunt COD_UNITI, MNEMONICE_JUDEE,
DENUMIRI_UNITI, ADRESE, TELEFOANE. La aceste domenii avem asocierile de
atribute evideniate n figur. Dintre aceste asocieri putem distinge atributele JD i JUD care au
aceeai interpretare semantic dar iau valori din domenii diferite.
Domeniile diferite pe care sunt definite atributele introduc restricii de integritate
diferite, la definire i utilizare, astfel:
- JD este codul de identificare a unui JUDET i este cuprins n intervalul [01,47];
- JUD este codul mnemonic al judeului care poate lua valori numai dac este unul
dintre elementele listei: {AB, AR, AG, B, BR, BV, ..., VN}.

71

n figura 4.3 este prezentat tabelul (relaia) Jurnal_Curent care conine nregistrarea
rulajelor (parial) contabile aferente lunii 10 a anului 1999 i n care coloanele definite au
semnificaia:

Fig. 4.2 Relaia DJDP (Direcii Judeene de Drumuri i Poduri)

Fig. 4.3. Relaia Jurnal_Curent
Capitolul 4
72
- PozDoc: poziia nregistrrii n documentul justificativ;
- Nota: numrul notei contabile n care se consemneaz nregistrarea;
- NrDoc: numrul/felul documentului intern;
- Zi, Luna, An: data nregistrrii (prinderii) n contabilitate a operaiei;
- ContDB: simbolul contului care se debiteaz cu valoarea operaiei contabile;
- ContCR: simbolul contului care se crediteaz cu valoarea operaiei contabile;
- Valoare: valoarea (suma) nregistrat;
- Obs: explicaii privind operaia;
- Proveniena: proveniena rulajului (subsistemul din care provine);
- Datint: data operrii (introducerii) la calculator a operaiei;
- NrDocExt: numrul documentului atribuit de ctre emitent;
- TipDoc: felul/tipul documentului;
- DataDoc: data emiterii documentului de ctre emitent.
n acest tabel atributele (coloanele) ContDB i ContCR sunt definite n acelai domeniu
denumit "Simboluri Conturi" domeniu format din multitudinea simbolurilor de conturi sintetice
sau analitice ale unei ntreprinderi, simboluri care trebuie s se regseasc n "Planul de
Conturi" al acesteia. Combinaia ContDB-ContCR definete formula contabil a nregistrrii.
Aceste atribute reprezint o interpretare semantic a domeniului, dat de poziia lor n formula
contabil, astfel:
- ContDB reprezint simbolul contului care se debiteaz n cadrul operaiei contabile;
- ContCR reprezint simbolul contului care se crediteaz n cadrul operaiei contabile.

4.2. Relaie, tuplu

O relaie R pe domeniile D
1
, D
2
, ..., D
n
(nu neaprat distincte) const dintr-un cap (de
tabel) i un corp (de tabel). Capul relaiei (tabelului) const dintr-o mulime fix de atribute
(coloane) A
1
, A
2
, ..., A
n
, astfel nct un atribut (o coloan) A
i
corespunde exact unui singur
domeniu D
i
, cu i=1,2,...,n. Fiecrei relaii i se atribuie o <denumire_de_relaie>.
Fiind dat un numr n1 de domenii D
1
, D
2
, ..., D
n
(nu neaprat distincte) o relaie R
definit pe aceste domenii este o submulime a produsului cartezian al acestor domenii, adic
R_D
1
xD
2
x...xD
n

Asocierea denumirii de relaie cu denumirile atributelor componente se numete schema
relaiei (sau schem de definire) notat n mod uzual ca R(A
1
,A
2
,...,A
n
) sau dac X este este
mulimea de atribute a lui R, adic X={A
1
,A
2
,...,A
n
}, atunci relaia poate fi notat ca R(X). Dac
t este un tuplu pe X i A este un atribut al su, A_X, atunci prin notaia t[A] sau t.A vom indica
valoarea tuplui t pentru atributul A (poate fi un singur atribut sau o mulime de atribute). n cele
ce urmeaz prin notaiile de tipul R(X) vom desemna schema de relaie a relaiei R pe mulimea
atributelor X.
Pentru exemplul din figura 4.1 schema relaiei cu denumirea ANGAJAT este:
ANGAJAT(NR#, SO, NUME_PRENUME, SEX, DATA_NATERII, SALARIU, FUNCIE,
LOC_MUNC, EF), n parantez fiind indicat intensia (capul) relaiei.
Relaia ANGAJAT este definit pe produsul cartezian al domeniilor:
MRCI x MRCI x NUME x SEX x DATE x SALARII x FUNCII x LOCURI_DE_MUNC x
MRCI
sau, generaliznd, pe produsul cartezian NTREGI x NTREGI x IR_DE_CARACTERE x
IR_DE_CARACTERE x DATE x NTREGI x IR_DE_CARACTERE x DATE x NTREGI x
NTREGI.

73
Pentru exemplul din figura 4.2 schema relaiei cu denumirea DJDP este:
DJDP(DRDP, JD, JUD#, DJDP, ADRESA, TELEFON).
Pentru exemplul din figura 4.3 schema relaiei Jurnal_Curent este:
Jurnal_Curent(PozDoc, Nota, NrDoc, Zi, Luna, An, ContDB, ContCR, Valoare, Obs,
Proveniena, Datint, NrDocExt, TipDoc, DataDoc).
Schema relaiei reprezint intensia relaiei. De exemplu schema relaiei (tabelei) pentru
Planul de Conturi poate fi definit ca Plan_de_Conturi(Simbol, Descriere, Func), cu:
- Simbol: simbolul contului;
- Descriere: denumirea contului;
- Func: funcionalitea contului.

Pentru Balana curent schema poate fi definit ca Balanta(An, Luna, Simbol, DbIan,
CrIan, DbPrec, CrPrec, DbLuna, CrLuna) cu:
- An: anul balanei;
- Luna: luna balanei;
- Simbol: simbolul contului;
- DbIan: sold debitor la nceput de an fiscal (Ianuarie);
- CrIan: sold creditor la nceput de an fiscal (Ianuarie);
- DbPrec: sume debitoare precedente (sume debitoare cumulate ale perioadelor
precedente adic ntre Ianuarie din anul An i luna curent Luna);
- CrPrec: sume creditoare precedente (sume creditoare cumulate ale perioadelor
precedente adic ntre Ianuarie din anul An i luna curent Luna);
- DbLuna: sume debitoare n luna balanei;
- CrLuna: sume creditoare n luna balanei.

Corpul relaiei (tabelei) const dintr-o mulime de tupluri (rnduri, nregistrri, linii)
variabil n timp (se pot aduga noi rnduri, se elimin sau modific cele existente). O
instan a relaiei (sau simplu o relaie) pe schema R(X) este o mulime r de tupluri pe X. Prin
notaia r(X) sau r vom desemna o instan a relaiei R pe mulimea de atribute X (mulimea
tuplurilor pe X la un moment dat). De exemplu pentru "Balana Curent" putem s adugm
conturi noi analitice (este posibil de fapt adugarea oricrui tip de cont) n orice moment sau
putem s eliminm acele conturi care au sumele 0 (zero) timp de doi ani la rnd.
Rndurile (tuplurile) constau dintr-o mulime de perechi de tipul
(denumire_atribut:valoare), adic o mulime de forma {(A
i
:V
i
), i=1,2,...,n}. Pentru fiecare
atribut (coloan) A
i
din schema relaiei (capul de tabel) exist o astfel de pereche. Pentru fiecare
pereche (A
i
:V
i
) aflat n mulime, V
i
este o valoare din domeniul unic D
i
asociat cu atributul A
i
.
Altfel spus, un rnd (tuplu) t<v
1
,v
2
,...,v
n
> aparine relaiei r dac i numai dac v
1
eDOM.A
1
,
v
2
eDOM.A
2
,...,v
n
eDOM.A
n
, unde prin DOM.A
i
am notat domeniul la care este asociat atributul
A
i
(deoarece domeniile nu sunt obligatoriu distincte aceast notaie este mai sugestiv).
De exemplu, tuplul marcat n figura 4.2 este <03,03,AG,ARGE,PITETI,734327> i
ndeplinete condiia de apartenen a valorilor la domeniile de definire:
03eDOM.DRDP (CODURI_JUDEE),
03eDOM.JD (CODURI_JUDEE),
AGeDOM.JUD (MNEMONICE_JUDEE), etc.

Numrul de atribute al unei relaii se numete gradul relaiei. De exemplu relaia
ANGAJAT din figura 4.1 are gradul 9, relaia DJDP din figura 4.2 are gradul 6 iar relaia
Jurnal_Curent are, conform schemei sale de relaie, gradul 15.
Numrul de rnduri (tupluri) al relaiei se numete cardinalitatea relaiei. Cardinalitatea
unei relaii r va fi desemnat prin |r|. De exemplu relaia ANGAJAT din figura 4.1 are
Capitolul 4
74
cardinalitatea 7 n timp ce relaia Jurnal_Curent din figura 4.3 are cardinalitatea 19 (vezi
indicaia Records).
Corpul relaiei (tabelului) reprezint extensia relaiei. Prin aceste definiii am furnizat
cadrul formal al noiunilor de relaie, tuplu i atribut, utilizate n modelul relaional.
Utilizatorii, datorit diversitii lor, percep i folosesc aceste noiuni n urmtoarele
accepiuni informale (exceptnd, eventual, utilizatorii speciali ca administratorul bazei de date -
ABD - i programatorii de sistem): relaia este un tabel, tuplul este o nregistrare sau un rnd al
tabelului, iar atributul este un cmp din nregistrare sau o coloan a tabelului. n principiu,
gradul relaiei este o mrime constant (adugarea de noi atribute la o schem de relaie se
execut foarte rar) pe cnd cardinalitatea este o mrime variabil n timp.
Deoarece corpul tabelului (relaiei) este o mulime relaia (tabelul) are urmtoarele
proprieti invariante n timp:
- Nu sunt admise rnduri (tupluri) duplicate (identice);
- Rndurile sunt neordonate (de sus n jos);
- Coloanele (atributele) sunt neordonate de la stnga la dreapta;
- Toate valorile atributelor sunt atomice.

Aceste proprieti pot fi interpretate, n cadrul sistemului financiar-contabil, astfel:
- n Balana de Verificare sau Planul de Conturi nu trebuie s avem dou conturi cu
acelai simbol; n Jurnal nu trebuie s nregistrm de dou (sau mai multe) ori
operaiile (rulajele) aceluiai document;
- Adugarea de noi conturi n Planul de Conturi sau n Balana de Verificare nu
necesit reorganizarea acesteia dei conturile trebuie s apar n liste n ordinea
cresctoare a valorii simbolurilor lor. Acestea vor fi adugate la sfritul tabelului,
iar la listare vor fi aranjate, prin posibilitatea de reordonare pus la dispoziie de
limbajul de manipulare, conform cerinelor utilizatorului. Similar orice nregistrare
n jurnal va fi efectuat n ordinea operrii sale la calculator. Aceast proprietate
ne asigur c nu putem s realizm intercalri sau inserri permind astfel
respectarea interdiciei prevzute de legea contabilitii;
- Coloanele din tabel pot fi aranjate conform oricror necesiti tehnice iar la
interogarea (consultarea) bazei de date acestea pot fi aranjate conform
specificaiilor din lege sau ale utilizatorului; De exemplu data nregistrrii n
contabilitate a rulajului este dat sub forma Zi, Luna, An ceea ce ne permite
efectuarea direct de listri aferente unei zi anume lucru cerut n mod expres
pentru Registrul de Cas i Jurnal de Banc prin legislaie.

Descrierea n SQL a intensiei relaiilor este realizat prin intermediul comenzii
CREATE TABLE a limbajului de definire. De exemplu crearea tabelei Plan_de_Conturi poate
fi exprimat n SQL astfel:

CREATE TABLE Plan_de_Conturi
(Simbol TEXT(22) NOT NULL, Descriere TEXT(60), Func TEXT(1))

4.3. Relaii i baza de date

Relaiile pot fi utilizate pentru a organiza datele relevante ale unei aplicaii. n general
nu este suficient o singur relaie pentru a realiza acest lucru ci o mulime de relaii ale cror

75
tupluri (rnduri) conin valori comune necesare stabilirii corespondenei ntre acestea, mulime
care formeaz o baz de date (figura 4.4).
Schema bazei de date B const dintr-o mulime de scheme de relaii cu diverse denumiri,
adic B={R
1
(X
1
), R
2
(X
2
),,R
n
(X
n
)}.
O instan a bazei de date (sau baza de date database) pe schema B={R
1
(X
1
),
R
2
(X
2
),,R
n
(X
n
)} este mulimea relaiilor b={r
1
,r
2
,,r
n
} unde fiecare r
i
, cu 1in, este o relaie
pe schema corespondent R
i
(X
i
).
Schema bazei de date, pe care o vom denumi SALARII, corespunztoare instanei din
figura 4.4 este SALARII(ANGAJAT(CNP, Sot, Nume, Prenume, Sex, Profesia, Data naterii,
Funcie, Telefon, ef, Salariu), PROFESII(Cod Profesie, Profesie), FUNCII(Cod Funcie,
Funcie)). Caracteristica esenial a unei baze de date relaionale este reprezentat de faptul c
referirile dintre diversele relaii (tabele) sunt reprezentate prin semnificaia valorilor din
domeniu care apar n tuplu (rnd). De exemplu, n relaia ANGAJAT valoarea atributului So
din rndul trei a angajatei Ionescu Maria este egal cu valoarea CNP a angajatului Ionescu
Claudiu iar a acestuia cu cea a angajatei Ionescu Maria definind astfel relaia de cstorie dintre
cei doi angajai. Similar coloanele Funcie i Profesia din tabela ANGAJAT iau valori din
coloana Cod Funcie a tabelei Funcii, respectiv coloana Cod Profesie a tabelei Profesii.

Structura modelului relaional se dovedete, prin prisma celor prezentate anterior, foarte
simpl i puternic. n acelai timp acesta impune un anumit grad de rigiditate: informaia
trebuie reprezentat prin tupluri de date adic ni se impune, n fiecare relaie, s reprezentm
numai tupluri care corespund schemei sale. Dac analizm relaia ANGAJAT din figura 4.4 aici
avem un atribut SO ale crui valori sunt luate din domeniul CNP i reprezint faptul c un
angajat este cstorit cu un alt angajat. Dar, pe de o parte nu toi angajaii sunt cstorii iar, pe
de alt parte chiar dac sunt cstorii nu este obligatoriu s avem toate cuplurile printre angajai
ceea ce ne duce la ideea c aceast informaie nu este disponibil pentru toi angajaii. Domeniul
CNP din care ia valori atributul SO conine numai coduri numerice peronale, deci valori
concrete. Pentru a putea reprezenta informaiile indisponibile conceptul de relaie a fost extins
pentru a include posibilitatea ca un tuplu s accepte pentru fiecare atribut fie o valoare dintr-un
domeniu fie o valoare special denumit valoare nul (null value).

Fig. 4.4. Exemplu de instan a bazei de date

Capitolul 4
76
Valoarea nul (nu zero) specific absena informaiei i reprezint o valoare adiional
oricrui domeniu (nu este inclus printre valorile domeniului) i este simbolizat cu NULL (sau
cu Null) n cele ce urmeaz. Pentru tratarea valorilor Null tabelele de adevr ale funciilor logice
de baz i (And), Sau (Or) i Nu (Not) sunt prezentate n tabelul 4.1.

Tabelul 4.1. Tabelele de adevr ale funciilor logice cu tratarea valorii Null
Not And A N F Or A N F
F A A A N F A A A A
A N N N N F N N N F
N F F F F F F F F F
Unde:
A Adevrat (True);
F Fals (False);
N nul (cu sensul de Null, indisponibil - Unavailable, nedefinit
Undefined).

Pe baza acestor tabele de adevr au fost definite dou noi forme de condiii atomice care
verific dac valoarea specificat este Null astfel:
- A Is Null este evaluat la Adevrat pe un tuplu t dac valoarea lui t pe atributul A
este Null i la Fals n caz contrar;
- A Is Not Null este evaluat la Adevrat pe un tuplu t dac valoarea lui t pe atributul
A provine din domeniul lui A nul i la Fals dac valoarea este Null.

4.4. Restricii de integritate

Restriciile (constrngerile) de integritate reprezint proprieti care trebuie s fie
satisfcute de ctre toate instanele corecte ale bazei de date. O constrngere trebuie perceput
ca un predicat care are valoarea Adevrat sau Fals pentru fiecare instan. Ele sunt definite n
general sub form de expresii logice (simple sau complexe) dar nu sunt excluse nici definirile
care implic calcule complexe exprimate pe mai multe coloane. n general unei scheme de baz
de date i se asociaz o colecie de constrngeri, iar instanele bazei de date care le satisfac sunt
considerate corecte. n funcie de elementele bazei de date crora li se asociaz constrngerile
pot fi clasificate n:
- constrngeri intra-relaie dac respectarea lor implic numai o relaie a bazei de
date. Acest gen de constrngeri pot fi clasificate astfel:
- restricii la nivel de tuplu care sunt evaluate independent pentru fiecare tuplu i
sunt definite pe valorile fiecrui tuplu independent de altele;
- restricii asociate valorilor sau restricii de domeniu date pentru a impune
restricii pe domeniul atributului;
- restricii la nivel de tabel care se aplic pe valori care apare n mai multe tupluri
ale relaiei;
- constrngeri inter-relaie dac acestea implic mai mult de o relaie.


77
4.5. Chei

Deoarece corpul unei relaii este o mulime, iar prin definiie mulimile nu conin
elemente duplicate (dubluri), rezult faptul c nu avem, la orice moment, dou sau mai multe
rnduri (tupluri) identice. Acest lucru ne permite s tragem concluzia c exist un atribut sau o
combinaie de atribute ale crui (cror) valori identific n mod unic rndurile (tuplurile).
Aceast proprietate trebuie ndeplinit cel puin de combinaia atributelor care compun ntreg
rndul (tuplul). Evident nu este exclus nici posibilitatea existenei mai multor atribute sau
combinaii de atribute care s realizeze identificarea unic a fiecrui rnd (tuplu).
Dac r este o relaie cu atributele A
1
,A
2
,...,A
n
atunci mulimea de atribute C=(A
i
,A
j
,...,A
m
)
este candidat pentru cheie a lui R dac i numai dac satisface urmtoarele dou proprieti
independente de timp:
- Unicitate care precizeaz c nu exist, n orice moment, dou rnduri (tupluri)
distincte din r care s aib aceeai valoare pentru C;
- Minimalitate care precizeaz c nu putem elimina nici unul din atributele A
i
,A
j
,...,A
K

ale lui C fr a pierde proprietatea de unicitate.

O definiie alternativ a conceptului de cheie folosete noiunea de supercheie:
- mulime de atribute C=(A
i
,A
j
,...,A
k
) este supercheie pentru o relaie r dac r nu poate
conine dou tupluri t
1
i t
2
pentru care t
1
[C]=t
2
[C];
- o mulime de atribute C=(A
i
,A
j
,...,A
k
) ale unei relaii r este o cheie pentru pentru r
dac este o supercheie minimal (adic dac nu exist o alt supercheie C' a lui r
care este coninut ca submulime n C).

Cu aceast definiie putem concluziona c fiecare relaie are cel puin un candidat la
cheie deoarece cel puin combinaia tuturor atributelor rndului (tuplului) are proprietatea de
unicitate.
Pentru exemplul din figura 4.1 avem dou chei candidat NR# (care reprezint marca
angajatului) i cheia format din combinarea atributelor (NUME_PRENUME, SEX,
DATA_NATERII). Pentru exemplul din figura 4.2 avem trei chei candidat DRDP, JD i JUD,
iar pentru exemplul din figura 4.3 avem cheia candidat format din combinaia de atribute:
(PozDoc, Nota, NrDoc, Zi, Luna, An, ContDB, ContCR, NrDocExt, TipDoc, DataDoc).

Pentru fiecare relaie un candidat la cheie va fi desemnat (arbitrar, dar de obicei lund n
considerare minimaliatea) pentru a fi cheia primar.
Pentru modelul relaional cheia primar este un element extrem de important deoarece
reprezint modul de adresare la nivel de rnd (tuplu).
Pentru exemplul din figura 4.1 atributul NR# (marca) a fost desemnat pentru a fi cheie
primar, iar pentru cel din figura 4.2 JUD# (indicativ judet). Pentru exemplul din figura 4.3
singurul su candidat la cheie va fi desemnat drept cheie primar. n cazul n care aceasta nu
convine se poate introduce o coloan suplimentar de tip autoincrementabil (COUNTER,
AUTONUMBER) care poate forma cheia primar numai dac capacitatea sa de reprezentare
(de regul este implementat de SGBD-uri la capacitatea de 2
31
-1) este acoperitoare pentru
necesarul de rulaje ale unei luni.
Pentru Balana i Plan_de_Conturi candidatul la cheie este reprezentat de atributul
Simbol i cheia primar devine acest atribut, care ndeplinete restriciile de unicitate i
minimalitate. Restricia de unicitate a simbolului de cont este definit expres de Legea
Contabilitii numrul 82/1991. De exemplu, la crearea tabelei Plan_de_Conturi declaraia de
cheie primar se poate exprima n SQL astfel:
Capitolul 4
78
CREATE TABLE Plan_de_Conturi (Simbol TEXT(22) CONSTRAINT
cheie_plan_conturi PRIMARY KEY, Descriere TEXT(60), Functionalitate TEXT(1))

O baz de date relaional poate fi definit, n intensie, printr-o schem relaional care
const din una sau mai multe scheme de relaie. n extensie, baza de date relaional este
perceptibil ca o colecie de tabele, fiecare tabel fiind compus din rnduri (denumite i linii
sau nregistrri) i coloane (denumite i atribute sau cmpuri) conform modului ilustrat n
figura 4.1, 4.2 i 4.3. n aceste condiii schema relaional nu reflect, explicit, toate asocierile
ntre relaiile din baza de date. Anumite tipuri de asocieri sunt coninute numai implicit prin
propagarea cheii de la o schem de relaie la alta.
Pentru materializarea asocierilor dintre schemele de relaie se utilizeaz noiunea de
cheie extern, definit ca un atribut (cmp) sau combinaie de atribute (cmpuri) dintr-o relaie
(tabel) ale crei (cror) valori sunt definite pe aceleai domenii cu cele ale cheii primare din alt
tabel (sau acelai tabel). De exemplu, n figura 4.1 avem cheile externe SO i EF, care i iau
valori din domeniile MRCI din care ia valori cheia primar NR#.
Tabela Jurnal_Curent conine dou chei externe ContDB i ContCR ambele putnd lua
valori din domeniul format din valorile coloanei Simbol din tabela Balana. Aceast proprietate
a simbolului de cont debitor (ContDB) i a celui de cont creditor (ContCR) este dat de modul
de definire a formulelor contabile: o formul simpl debiteaz un cont i crediteaz, n acelai
timp, un alt cont ambele conturi trebuind s existe n balana curent a ntreprinderii (i de altfel
n Planul su de conturi).
Pentru a face distincie ntre relaiile stocate n baza de date i cele obinute prin
aplicarea operatorilor relaionali primele tipuri de relaii se numesc relaii de baz iar cel de-al
doilea relaii derivate. De exemplu, pentru sistemul financiar-contabil tabelele Plan_de Conturi,
Balana i Jurnal_Curent reprezint tabele de baz n timp ce o tabel cu rulajele unei note
contabile anume, cum ar fi nota Casa, extras din Jurnal_Curent, reprezint o tabel derivat
utilizat temporar.

Fie R o relaie de baz cu cheia primar C=(A
1
,A
2
,...,A
n
), n>0. Fie S o relaie de baz (R
i S nu neaprat distincte) i fie B
1
,B
2
,...,B
n
atribute din S care satisfac restriciile de
independen de timp. Pentru orice nregistrare s a lui S n care este ndeplinit una din
condiiile:
- s.B
1
,s.B
2
,...,s.B
n
sunt toate nule;
- exist o nregistrare r a lui R astfel nct r.A
1
=s.B
1
,r.A
2
=s.B
2
,...,r.A
n
=s.B
n
;
- combinaia (B
1
,B
2
,...,B
n
) este o cheie extern n S care este identic cu cheia primar
(A
1
,A
2
,...,A
n
) din R.
unde prin construciile de forma r.A
i
am desemnat valoarea atributului A
i
din relaia r.

De exemplu declararea asocierii unui cont din Balana curent cu contul din
Plan_de_Conturi poate fi realizat astfel:

CREATE TABLE Balanta(An SHORT, Luna BYTE, Simbol TEXT (22) CONSTRAINT
este_contul REFERENCES Plan_de_Conturi (Simbol), DbIan DOUBLE, CrIan
DOUBLE, DbPrec DOUBLE, CrPrec DOUBLE, DbLuna DOUBLE, CrLuna
DOUBLE)


79
4.6. Restricii de integritate minimale

Fiecare cheie primar i cheie extern din relaiile (tabelele) bazei de date trebuie s
satisfac urmtoarele restricii de integritate [C.J. DATE, /21; 22; 23/]:
- integritatea entitii (entity integrity):
Nici-un atribut care particip la formarea cheii primare a unei relaii de baz nu
poate primi valori nule
*)
;
- integritatea referenial (referential integrity):
Dac o relaie r
2
include o cheie extern C
e
pe cheia primar C
p
a relaiei r
1
(r
1
i
r
2
nu neaprat distincte) atunci fiecare valoare a cheii C
e
din r
2
trebuie s fie egal
cu valoarea lui C
p
dintr-un tuplu al lui r
1
sau s fie nul.

*) Not! Termenul null nu definete valoarea zero (0) ci o valoare special considerat de
sistem Null (cum ar fi zero binar).

Declaraia restriciilor de integritate este efectuat prin asocierea la definiia de coloan
a clauzei NOT NULL sau prin asocierea unor clauze CONSTRAINT fie la nivel de coloan fie la
nivel de tabel (pentru coloane multiple).
De exemplu, dac ne referim la tabela Jurnal a crei cheie primar este format din
urmtoarea combinaie de atribute (PozDoc, Nota, NrDoc, Zi, Luna, An, ContDB, ContCR,
NrDocExt, TipDoc, DataDoc) atunci crearea tabelei Jurnal ar trebui s arate astfel:

CREATE TABLE Jurnal(PozDoc COUNTER, Nota SHORT NOT NULL, NrDoc
TEXT(16) NOT NULL, Zi BYTE NOT NULL, Luna BYTE NOT NULL, An SHORT
NOT NULL, ContDB TEXT(22) NOT NULL, ContCR TEXT(22) NOT NULL, Valoare
DOUBLE, Obs TEXT(60), Proveniena TEXT(6), Datint DATETIME, NrDocExt
TEXT(16) NOT NULL, TipDoc TEXT(16) NOT NULL, DataDoc DATETIME NOT
NULL)

n acest context relaia r
2
este o relaie care refer (fiu sau membru-member), iar relaia
r
1
este o relaie referit (tat sau posesor-owner).

Justificarea primei reguli de integritate este urmtoarea:
- relaiile (tabelele) corespund entitilor din lumea real;
- entitile din lumea real sunt distincte (ele sunt identificate n mod unic ntr-un
anume fel);
- cheia primar realizeaz funcia de identificare unic n cadrul modelului relaional;
- pentru a-i realiza funcia cheia primar nu poate avea valoare nul.
n ceea ce privete cea de a doua regul de integritate justificarea este urmtoarea:
- dac un tuplu t
2
refer un tuplu t
1
, atunci tuplul t
1
trebuie s existe (de exemplu, dac
un rulaj refer conturi din balana atunci aceste conturi trebuie s existe);
- dac valoarea unei chei externe nu este nul atunci ea trebuie s se regseasc
printre valorile cheii primare ale tabelei referite.

Capitolul 4
80
4.7. Baza de date relaional o descriere formal

Formal un sistem relaional este compus din:
- baz de date relaional;
- o colecie de operatori relaionali;
- dou reguli de integritate;
- o mulime (set) de asocieri.

O baz de date relaional const dintr-o mulime de domenii i o mulime de relaii
peste care se aplic o mulime de asocieri.

Utiliznd notaia BNF putem descrie formal baza de date relaional astfel:
- <baz de date relaional>::=<mulime de asocieri> (<mulime de domenii>,
<mulime de relaii>)
- <mulime de asocieri>::=<asociere>|<asociere> <mulime de asocieri>
- <asocieri>::= <asociere atribute>|<asociere relaii>
- <asociere atribute> ::= <relaie>

Fiecare relaie, din mulimea de relaii, este un rezultat al asocierii atributelor la atributul
(sau grupul de atribute) desemnat cheie primar a relaiei. De fapt, atributele care nu particip la
formarea cheii primare nu reprezint altceva dect caracterizani ai cheii.
Prin asocierile dintre relaii (<asociere relaii>) se pun n eviden legturile de
interdependen/intercondiionare a fenomenelor sau obiectelor modelate.
O asociere ntre dou relaii r i s (nu neaprat distincte) se definete ntr-o direcie dat
(de la ...| la...) i ofer un mecanism de acces prin care pornind de la o realizare (un tuplu) t al
lui r avem acces la realizrile (tuplurile) t
1
, t
2
, ..., t
n
ale lui s care i sunt asociate.
Deci asocierea este o relaie binar ntre dou mulimi (relaii) r i s, nu neaprat
distincte.
Vom nota asocierea, sub form funcional, prin s
G
F
r n care F i G sunt funcii, n
general multivaloare i inverse una alteia. Asocierea este caracterizat de tipul fiecrei funcii.
Asocierea poate fi, n funcie de:
- rezultatul evalurii:
- monovaloare: dac evaluarea sa produce o singur valoare;
- multivaloare: dac evaluarea sa produce o mulime de valori.
Pentru aceste funcii un element caracterizant important este reprezentat de
cardinalitatea minimal i maximal (numrul minim i respectiv maxim de valori produse).

- completitudinea asocierii:
- parial: dac exist elemente (tupluri) n mulimea de plecare care nu au o
imagine n mulimea destinaie;
- total: dac toate elementele (tuplurile) mulimii de plecare au o imagine n
mulimea destinaie.

La o baz de date relaional [AVRAM93] local asocierile, n funcie de modul
perceperii lor, pot fi de tipul :
- implicite, n cazul asocierilor binare ale atributelor la entitatea/relaia creia i
descrie proprietile;

81
- explicite, n cazul n definirii relaiilor de asociere (ca relaii independente sau ca
relaii normale) prin mecanismul <cheie extern> - <cheie primar>;
- transparente/virtuale, n cazul n care realizarea unei asocieri este determinat la
"moment" i n general urmeaz unui proces de transformare a datelor. Dup
realizarea asocierii i efectuarea operaiilor care o solicit, asocierea nu va avea
materializare n baza de date. Realizarea asocierii, la alt moment de timp dar cu
pstrarea condiiilor iniiale, presupune parcurgerea acelorai transformri ale
datelor. Acest gen de asocieri au un
caracter dinamic imperativ ceea ce face ca
ele s nu poat fi consemnate ca valori ale
unor atribute de tip <cheie extern>. Acest
lucru nu nseamn c asocierile de tip
<cheie extern> nu au un dinamism
propriu. Diferena const n faptul c
asocierile de tip <cheie extern> au un
caracter relativ stabil, iar materializarea
este realizat prin existena unei valori
pentru un atribut sau combinaie de
atribute care definete <cheie extern>. Aceste asocieri sunt materializabile numai
prin tipul de legtur 1-1 sau 0-1.

Primele dou tipuri de asociere sunt materializate n relaii (asocieri reale) care pot fi de
oricare din tipurile identificate i pot avea existen real sau virtual.
Referitor la asocierile enunate se pot formula urmtoarele observaii pentru cazul
organizrii datelor n baze de date distribuite:
- toate tipurile de asocieri ale unei baze de date locale pot fi identificate i n baza de
date global i deci implicit pot face obiectul descompunerii;
- asocierile de tip virtual pot fi realizate la distan iar descompunerea se refer la
faptul c decompozabile sunt numai relaiile ntre care apar;
- asocierile explicite care au asociat un index (o cale de acces definit pe cheia extern
i o modalitate de specificare a restriciilor de integritate) impun restricia ca acest
index sa fie descompus orizontal n raport cu cheia extern (nu este admis
descompunerea vertical a cheii externe formate din combinaie de atribute). Indexul
definit reprezint calea prin care o cheie extern multiatribut este vzut ca un
ntreg.

Specificnd la fiecare funcie F i G cardinalitatea maximal (n) (notat cu F(n),
respectiv G(n) vom avea urmtoarele tipuri de asocieri:
- "unu_la_unu" (1-1): aceast asociere (one_to_one) se reprezint grafic (Bachman)
ca n figura 4.5. O asociere de tip 1-1 poate fi vzut i ca 0-1. De exemplu, dac ne
referim la asocierea dintre relaiile Plan_de_Conturi i Balana care este de tip 1-1
atunci putem avea conturi n relaia Plan_de_Conturi care nu se regsesc n Balana.
De exemplu, dac presupunem c avem un client care nu mai desfoar timp de doi
ani activitate cu noi iar soldurile aferente analiticului alocat lui sunt 0 putem s-l
eliminm din Balana dar s-l pstrm n Plan_de_Conturi. Sau un alt exemplu,
Plan_de_Conturi conine Planul de Conturi General n care se regsesc i conturi
privind mprumuturile de la bnci iar firma nu face nici-un mprumut i deci ele nu
apar n Balana.

Fig. 4.5. Asociere 1-1
Capitolul 4
82
Reprezentarea acestei asocieri dintre Plan_de_Conturi i Balana este ilustrat n figura
4.6.

n tabela Plan_de_Conturi este definit cheia primar Simbol prin declaraia Simbol
TEXT(22) CONSTRAINT cheie_plan_conturi PRIMARY KEY iar n Balan coloana Simbol
este declarat cheie extern care refer cheia primar din Plan_de_Conturi cu declaraia
Simbol TEXT (22) CONSTRAINT este_contul REFERENCES Plan_de_Conturi (Simbol).

- "unu_la_mai_muli" (1-n): aceast asociere (one_to_many) se reprezint grafic
(Bachman) ca n figura 4.7. O asociere de tip 1-n poate fi vzut i ca 0-n. De
exemplu, dac ne referim la asocierea dintre relaiile Balana i Jurnal vom avea
dou asocieri de tip 1-n (figura 4.8) dat de faptul c un cont din balan este debitat
de una sau mai multe nregistrri din jurnal i creditat de una sau mai multe
nregistrri.

Un cont din balana curent, de exemplu al unui client care n luna respectiv nu
realizeaz afaceri cu firma, poate s nu aib rulaje asociate n jurnal.
Schimbnd ordinea de plecare (de la S la R, figura 4.7 ) asocierea poate fi privit i
interpretat ca "mai_muli_la_unu" (many_to_one).

n tabela Balanta este definit cheia primar Simbol prin declaraia Simbol TEXT(22)
CONSTRAINT cheie_balanta PRIMARY KEY iar n Jurnal coloana ContDb este declarat cheie
extern care refer cheia primar din Balanta cu declaraia ContDb TEXT (22) CONSTRAINT
debiteaza_pe REFERENCES Balanta (Simbol) iar coloana ContCr este declarat cheie extern
prin ContCr TEXT (22) CONSTRAINT crediteaza_pe REFERENCES Balanta (Simbol).

Notatia "1" din asocierile descrise poate desemna "0" ("nici-un") sau "1" ("exact un")
element.

Fig. 4.7. Asociere 1-n
Fig. 4.6. Asociere de tip 1-1

Fig. 4.8. Asocierile dintre Jurnal i Balana (curente)

83
- "mai_muli_la_mai_muli" (n-m): aceast asociere (many_to_many) se reprezint
grafic (Bachman) ca n figura 4.9.

n general, n tipurile de SGBD clasice (inclusiv n Access), aceast asociere nu poate fi
reprezentat ca atare ci trebuia descompus n asocieri de tip (1-n). Modelul relaional introduce
posibilitatea descrierii directe asocierii (n-m), dar prin aplicarea normalizrii se obine de regul
descompunerea n asocieri (1-n). Aceast descompunere se obine introducnd o relaie
suplimentar, notat cu RxS, pentru a materializa asocierea conform modului ilustrat n figura
4.10.
La implementarea acestor tipuri de asocieri acestea pot fi:
- statice, caz n care se realizeaz prin mecanismul <cheie extern-cheie primar>;
- virtuale, caz n care se realizeaz la moment i sunt n general precedate de un
calcul.

Revenind la descrierea n BNF a bazei de date relaionale avem:
- <mulime de domenii>::=<denumire domeniu><mulime valori
domeniu>[<indicator de ordine>]
- <denumire domeniu>::= <identificator>
- <mulime valori domeniu>::=<valoare domeniu>|<valoare domeniu><mulime
valori domeniu>
- <valoare domeniu>::=<valoare atomic> | <condiie apartenen la domeniu>
- <indicator ordine>::= DA | NU

Fiecrui domeniu i se atribuie o denumire distinct, <denumire domeniu> care
reprezint o generalizare a atributelor care i iau valori din domeniu.
Denumirea atribuit domeniului <denumire domeniu> este un <identificator> format
conform specificaiilor limbajului de definire a datelor (sau componentei care realizeaz
definirea datelor). n cazul n care aceast denumire nu este suficient de explicit este indicat
descrierea sa n dicionarul bazei de date (sub form de comentarii, sub form de linii de text n
relaii caracterizante din baza de date etc.).
n cazul SGBD-urilor existente descrierea poate fi fcut ca un alias asociat coloanei la
interogare (clauza AS) sau n modul Design modificnd proprietatea Caption.
Prin <mulime valori domeniu> sunt desemnate toate valorile admisibile pentru acel
domeniu (<valorile atomice> care verific <condiia de apartenen la domeniu>). Aceste
valori care compun domeniul pot fi eventual ordonate (<indicator de ordine>::= DA). Dac se
cere ordonarea atunci aceast ordonare va fi efectuat conform specificaiilor unei relaii de
ordine ntre valori (<, >,<= etc.).

Fig. 4.9. Asociere m-n

Fig. 4.10. Transformarea
asocierii m-n n asocieri 1-n
Capitolul 4
84
Prin condiiile de apartenen la domeniu am desemnat cel puin informaiile care
definesc natura i lungimea datelor (tipul, de exemplu, ntreg, real etc.; lungimea, de exemplu,
trei caractere, cinci ntregi i dou zecimale etc.) la care se pot aduga, eventual, alte elemente
care precizeaz diverse restricii :
- <relaie>::= <relaie denumit>|<relaie anonim>
- <relaie denumit>::= <relaie de baz>|<relaie virtual>
- <relaie anonim>::= <expresie relaional>
- <relaie virtual>::= <denumire de relaie> <expresie relaional>
- <relaie de baz>::= < denumire de relaie>[<mulime atribute>]
- <cheie primar>[<chei alternative>][<chei externe>]<mulime tupluri>
- < denumire de relaie>::= <identificator>
- <mulime atribute>::= <atribut>|<atribut> <mulime atribute>
- <atribut>::= < denumire atribut> < denumire domeniu>[<restricii valori>]
- < denumire atribut>::= <identificator>
- <cheie primar>::= <cheie alternativ> <restricii cheie primar>
- <cheie alternativ>::= <candidat cheie>[<restricii cheie alternativ>]
- <candidat cheie>::= <mulime denumiri atribut>
- <cheie extern>::=<mulime denumiri atribut> <restricii cheie extern>
- <mulime tupluri>::= <tuplu>|<tuplu> <mulime tupluri>
- <tuplu>::= <mulime valori atribut>
- <mulime valori atribut>::= <valoare atribut> < denumire domeniu>[<restricii
valori atribut>]
Relaiile din baza de date pot avea un nume n cazul n care sunt <relaii de baz> sau
<relaii virtuale> sau nu dac sunt <relaii anonime>.
Diferena dintre o <relaie de baz> i o <relaie virtual> este dat de faptul c o
<relaie de baz> are extensia stocat n spaiul fizic asociat bazei de date relaionale (sub
forma perceptibil de tabel) pe cnd <relaiile virtuale> se obin ca urmare a aplicrii unei
<expresii relaionale> pe relaiile de baz.
O <relaie virtual> (viziune) este obinut la momentul solicitrii utilizatorului i este
disponibil, dup obinere, pentru aplicarea unor alte eventuale <expresii relaionale> de ctre
ali utilizatori.
O <relaie anonim> este un rezultat al aplicrii unei <expresii relaionale> pe
<relaiile de baz> i/sau <relaiile virtuale> i este disponibil, n general, pentru un singur
utilizator. <relaiile de baz> i <relaiile virtuale> sunt definite n <schema de relaii>
(schema bazei de date relaionale).
Relaiile de baz pot fi grupate formal n urmtoarele tipuri:
- nucleu;
- asociere;
- caracterizante;
- utilitare.
Relaiile de tip nucleu sunt entitile (tabelele) fundamentale ale microlumii de interes
(universul lumii reale modelate). Ele reprezint de fapt "despre ce este vorba n baza de date sau
ce poriune din realitate se modeleaz".
Relaiile de asociere sunt relaiile (tabelele) care permit materializarea asocierii dintre
dou sau mai multe relaii (entiti). Fiecare participant la asociere poate fi o relaie de tip
nucleu, asociere sau caracterizant.
Relaiile caracterizante sunt entiti (tabele) al cror rol este de a califica, descrie sau
"caracteriza" alte entiti (de orice tip). Existena entitii caracterizante este dependent de
existena entitii pe care o caracterizeaz: "O entitate R este dependent de entitatea S dac
este imposibil s existe o realizare a lui R dac nu exist o realizare corespondent a lui S".

85
Relaiile de asociere i cele caracterizante nu au o existen independent ci presupun existena
altor relaii n baza de date.
n general acest mod de grupare pe aceste trei tipuri este dependent de aplicaie. Un
tabel (o relaie) poate fi privit() de unii utilizatori ca asociere, de alii ca nucleu etc. De
exemplu, ntr-o baz de date care cuprinde date despre angajai i locuri de munc, entitile
care se refer la locul de munc sunt tratate de ctre utilizatorul "compartimentul resurse
umane" drept caracterizante n timp ce utilizatorul "compartimentul de organizare a produciei
i a muncii" le poate trata ca nucleu.
n descrierea formal a relaiei de baz au fost evideniate att intensia ct i extensia sa.
Relaiile utilitare sunt destinate stocrii unor informaii utilitare (cum ar fi descrierea
restriciilor de integritate, help-uri asociate sistemului, documentaie etc).
Pentru intensie au fost specificate clasele de atribute care o formeaz astfel:
- <mulime atribute>: sunt atribute considerate "ordinare" prin faptul c nu particip la
formarea cheilor;
- <cheie primar>: ca element unic de identificare i desemnare a rndurilor
(nregistrrilor, tuplurilor) reprezentnd calea principal de acces la rnd (tuplu);
- <chei alternative>: pentru eventuala definire a unor ci de acces suplimentare la
rnd (tuplu) din considerente care privesc optimizarea timpilor de rspuns ai unor
aplicaii:
- <chei externe>: ca elemente de importan major n materializarea asocierilor
dintre rndurile (tuplurile) relaiilor. Aceste <chei externe> pot avea (i au n
general) asociate restricii care s asigure coerena logic a asocierilor.
La utilizarea fiecrei <relaii denumite> (definire, manipulare etc.) pentru <cheia
primar> se vor utiliza urmtoarele reguli [DATE86]:
- pentru fiecare atribut care particip la formarea cheii se va specifica faptul c nu sunt
admise valori nule (NOT NULL);
- se va crea un index care admite numai valori unice pe combinaia tuturor atributelor
care formeaz cheia primar (declaraia de cheie primar este, n majoritatea
imlementrilor modelului relaional, echivalent). Declaraia index-ului va fi fcut
fie declarnd cmpurile drept cheie primar cu clauza CONSTRAINT
denumire_restricie PRIMARY KEY sau cu comanda CREATE UNIQUE INDEX
denumire_index ON denumire_tabela (denumire_coloana [ASC|DESC] [, ... ]);
- se va testa existena combinaiei de valori ntre intrrile acestui index la inserarea
oricrui tuplu (rnd) n tabel sau la modificarea valorii unei chei primare;
- specificaiile pentru definirea cheii primare i a restriciilor asociate vor fi trecute
sub form de comentariu n textul de definire sau ntr-o relaie caracterizant definit
n acest scop.

Similar, pentru fiecare cheie extern, se vor utiliza urmtoarele reguli:
- pentru fiecare atribut care particip la formarea cheii se va specifica faptul c nu
admite valori nule dac i numai dac cheia extern nu admite valori nule (NOT
NULL);
- se analizeaz dac este oportun i imperioas crearea unui index (n acest caz
probabil c va admite valori duplicate) pe aceast cheie extern;
- se va utiliza mecanismul de autorizare al SGBD-ului pentru a interzice operaiile on-
line capabile s violeze restriciile aplicate acestor chei externe. Aceste operaii pot
fi: tergere n tabela referit; modificare a cheii primare a tabelei referite; adugare
n tabela care refer; modificare pe cheia extern n tabela care refer.
- restriciile cheii externe vor fi incluse n specificaiile pentru programele de
ntreinere a bazei de date. Ideal este construirea unui singur program sau a unor
Capitolul 4
86
primitive care s manipuleze cheia extern i care s fie apelate parametric de ctre
toi utilizatorii;
- specificaiile pentru cheia extern i restriciile asociate vor fi conservate sub form
de comentarii n textul de definire sau ntr-o relaie caracterizant definit n acest
scop.

La aceste reguli vom aduga urmtoarele:
- deoarece o cheie extern materializeaz o asociere, asocierea reprezentnd o
proprietate calitativ a modelului datelor, este indicat scrierea unor programe
(eventual parametrizate) de testare i verificare a coerenei logice care s
semnalizeze orice violare a restriciilor. Aceste programe vor fi rulate periodic n
conformitate cu strategia impus de administratorul bazei de date;
- pentru cheile alternative pe care se presupune c vom crea indeci se vor utiliza
aceleai reguli ca la cheile externe.

Fiecare <atribut> are o <denumire atribut> care nu trebuie, neaprat, s fie identic cu
<denumire domeniu> a domeniului pe care este definit. Aceast <denumire atribut> reprezint
o interpretare semnatic a <domeniului> i poate avea (conform acestei interpretri semnatice)
asociat o restricie prin care se specific care valori din <mulime valori domeniu> sunt
considerate valide (deci i acceptate) pentru interpretarea semnatic dat.
Extensia unei relaii este o <mulime tupluri>. Aceasta <mulime tupluri> are o
cardinalitate care variaz n timp (se elimin/adaug tupluri).

Proiectarea bazelor de date relaionale

87

Capitolul 5
Proiectarea bazelor de date
relaionale

Activitatea de proiectare a bazelor de date se ncadreaz n metodologia general de
realizare a sistemelor informatice. Plecnd de la existena celor trei niveluri de organizare a
datelor n baze de date, proiectarea structurii bazei de date va fi realizat n mod corespunzator
celor trei niveluri - conceptual, logic i fizic parcurgnd fazele descrise n figura 5.1.
Proiectarea Conceptual. Scopul acestei faze
este acela al reprezentrii cerinelor informal
formulate ale aplicaiei n termenii unei reprezentri
complexe formale independent de criteriile de
reprezentare ale unui SGBD anume. Rezultatul
acestei faze este denumit schema conceptual care
reprezint un model conceptual al datelor n care
organizarea datelor este descris la un nalt nivel de
abstractizare i fr a ine seama de nici-un aspect de
implementare. Proiectantul va trebui s reprezinte
coninutul informaional al bazei de date fr a trata
mijloacele prin care va fi implementat n SGBD-ul
utilizat sau fr s se preocupe de eficiena
programelor care vor utiliza aceste informaii.
Proiectarea Logic. Acest faz const n
translatarea schemei conceptuale definit n faza
precedent ntr-un model de date acceptat de un
SGBD disponibil. Rezultatul acestei faze este
denumit schema logic a bazei de date care face
referire la un model logic al datelor. n acest model
reprezentarea datelor este efectuat independent de
aspectele de reprezentare fizic. n acest faz
proiectantul va trebui s in cont de diverse criterii
de optimizare cerute de operaiile necesare meninerii
i regsirii datelor i s verfice calitatea schemei
logice utilizate. Pentru modelul relaional tehnica formal utilizat pentru aceste optimizri i
verificri calitative este reprezentat de normalizare.
Proiectarea Fizic. n acest faz proiectul logic este completat cu detaliile
implementrii fizice (organizarea fiierelor, definirea partiiilor, caracteristicilor cerute spaiilor
fizice asociate componentelor, indeci etc) specifice unui SGBD anume. Rezultatul acestei faze
este reprezentat de schema fizic care este un model fizic al datelor. Acest model este dependent
de SGBD-ul ales i ine cont de organizarea fizic a datelor n acest SGBD.

Fig. 5.1. Fazele proiectrii bazei de
date
Capitolul 5
88
Pentru ca un sistem informatic proiectat pentru o activitate economico-social s ofere un
nalt grad de generalitate este necesar ca acesta:
- s emuleze perfect cadrul legal general care dicteaz condiiile social economice de
existen i funcionare a sa;
- s emuleze cadrul organizatoric la cel mai nalt grad de generalitate existent (s
reprezinte cel puin o acoperire satisfctoare a cadrelor organizatorice particulare) ;
- s permit modificri ulterioare fr a perturba funcionarea elementelor emulate i
rezolvate ( s aib o arhitectura de sistem deschis) ;
- s ofere canale de comunicaie i operatori care s permit conducerea real a activitii
emulate, conform cerinelor particulare ale unui sistem de conducere specific.
Condiia necesar i suficient pentru acordarea calificativului de sistem generalizat este
respectarea cadrului metodologic i legal care guverneaz funcionarea domeniului de activitate
emulat. Acest cadru legal este acela care asigur schimbul formal de informaii ntre sistemul
emulat i celelalte sisteme cu care este n interaciune. Respectarea complet a cadrului
metodologic i legal permite emularea pentru cel mai complex sistem care funcioneaz guvernat
de acestea. Subsistemele sau sistemele care nu acoper ntreaga sa complexitate vor avea
emularea funcionrii inclus n sistemul complex ( generalizat ).
Asigurarea arhitecturii deschise este cerut de faptul c sistemul proiectat trebuie s
asigure emularea oricror modificri ale cadrului metodologic sau legal. Aceste modificri sunt
implicate de evoluia natural a legilor care guverneaz evoluia sistemelor economico-sociale.
Aceast modificare nu are loc n general brusc dect n cazuri majore de schimbare a legilor
economico-sociale ( cum ar fi schimbarea unui regim social cu altul). Schimbarea natural a
cadrului legal de funcionare are loc ca urmare a percepiei interaciunii cu celelalte domenii de
activitate. De exemplu cadrul legal i metodologic de funcionare i aplicare a legii contabilitii
nu solicit obinerea unor bilanuri (balane) cu un partener de afaceri sau altul. Ceea ce specific
legea c trebuie s circule cu un anumit cadru formal sunt bilanurile, notele contabile,
documente de plat/decontare, jurnale contabile etc. Nevoia de informaii pentru decizie implic
o multitudine de alte analize, detaliate sau sintetice, care s permit fundamentarea i obinerea
eficienei. n acest context un sistem generalizat trebuie s ofere canale i operatori pentru astfel
de informri.
Arhitectura deschis pentru operatorii de manipulare se refer tocmai la faptul de a putea
realiza pe baza datelor existente i alte prelucrri dect cele formale. De asemenea sistemul
trebuie s admit i eventuala modificare a cadrului sau static (structurile de date), fr ns a
afecta emularea cadrului metodologic i legal existent.
Din aceste considerente asigurarea calitii schemelor bazelor de date, ca viitoare
depozite de date utilizate n generarea de informaii, reprezint o cerin esenial pe care trebuie
s o ndeplineasc orice sistem informatic cu baze de date.

5.1. Consideraii privind proiectarea structurii
conceptuale i a structurii logice a bazelor de date

n mod sintetic, succesiunea pailor de urmat n activitatea de proiectare a structurii
conceptuale i logice a bazelor de date apare astfel:
- Identificarea coleciilor (tabelelor) de date corespunztoare sistemului de referin.
Identificarea coleciilor (tabelelor) se face n cadrul etapei de "concepere a sistemului
informatic" pe baza analizei concordanei dintre ieirile sistemului (situaiile de
informare/raportare necesare conducerii) i intrrile sistemului (sursele de date primare).

89
n general, gruparea i stocarea datelor n colecii (tabele) se face prin asocierea acestora
obiectelor, proceselor sau activitiilor desfurate n unitatea economico-social de
referin. Denumirea coleciilor (tabelelor) va fi unic i dat astfel nct s sugereze ct
mai bine obiectele, procesele sau activitile de referin. Indicarea n paranteze a
termenului tabel a fost efectuat pentru a particulariza termenul de colecie pentru
modelul relaional. Deoarece proiectarea modelului conceptual face apel la abstractizri
o colecie de date poate fi referit ca entitate, entitatea nefiind altceva dect ceva care
are identitate proprie i este distingibil de toate celelalte entiti din jurul su. ncadrarea
coleciilor n categoria acestei abstractizri nu face altceva dect s specifice
proprietile generale pe care trebuie s le motenesc o colecie de date. Elementele
entitilor vor fi referite prin termenul realizare sau obiect, termen abstract care este
referit concret n cadrul coleciilor prin: nregistrare, rnd, linie etc.
- Definirea detaliat a coleciilor de date. Este realizat de ctre echipa de proiectare,
parte a grupului de administrare, a bazei de date. Punctul de plecare n proiectarea
structurii logice l reprezint coleciile de date, stabilite la nivel global n etapa de
concepere a sistemului informatic, cnd s-a realizat totodat i schiarea unui prim
model conceptual de ansamblu al datelor. Structura logic este rezultatul rafinrii,
validrii, corectrii i transpunerii n termenii unui model de date, acceptat de un SGBD,
a acestui model de ansamblu al datelor. Se urmrete evidenierea caracteristicilor
(atributelor) obiectelor identificate i a legturilor dintre aceste atribute i coleciile de
date. Pentru un obiect simplu caracteristicile vor fi cele care l identific i l descriu.
Pentru un obiect compus, caracteristicile vor fi cele de identificare a acestuia i cele de
descriere a obiectelor simple care sunt legate de cele compuse. De exemplu, ntr-o
ntreprindere care defoar activitate de producie, caracteristicile (atributele) asociate
obiectelor MATERIALE ar putea fi, printre altele:
- cod material (cmp indentificator, numeric ntreg din 12 cifre);
- denumire material (cmp alfanumeric din 30 caractere);
- unitate de msur (cmp alfanumeric din 6 caractere);
- pre de depozit (cmp numeric zecimal, format din 18 cifre cu dou zecimale);
- stoc normat (cmp numeric, format din 12 cifre cu trei zecimale);
- stoc existent (cmp numeric, format din 12 cifre cu trei zecimale);
- cont de materiale (cmp alfanumeric 22 caractere);

Fig. 5.2. Reprezentarea asocierilor
Capitolul 5
90
Aceast asociere a atributelor la o colecie nu specific care va trebui s fie
comportamentul coleciei de aceea descrierea nu face dect s defineasc structura coleciei care
nu reprezint altceva dect o descriere a proprietilor statice. ntr-o descriere real a unui
sistem definirea unei colecii de date mai trebuie s includ i specificaii privind
comportamentul acestor elemente descriptive sau comportamentul ntregului ansamblu al
acesteia. Descrierea comportamentului (reacia la stimuli) nu reprezint altceva dect definirea
proprietilor dinamice ale coleciei.
- Determinarea asocierilor (legturilor) dintre colecii (tabele). Se realizeaz pe baza
legturilor naturale care exist ntre obiectele descrise cu ajutorul entitilor
identificate. Dependenele dintre obiecte pot fi ilustrate pe baza unui graf orientat n
care fiecare nod reprezint cte un tip de obiect iar arcele cte o dependen. O
asociere (figura 5.2) are loc de la (S) o relaie la(T) alta, privit astfel n funcie de
semnificaia sa pentru aplicaia proiectat. O asociere ntre dou entiti are loc n
ambele sensuri (poate fi traversat n ambele sensuri), fiecare sens putnd avea propria
sa interpretare semantic (interpretare). Asocierea poate fi de mai multe tipuri fiecare
din acestea putnd fi, la rndul lor, asocieri pariale sau totale. Tipul asocierilor i
completitudinea acestora (parial sau total) se indic prin factorul de multiplicitate.
Factorii de multiplicitate ai unei asocieri se specific n text prin construcii de forma
x:y, x-->y sau x-y, unde x indic captul de la iar y captul la. O asociere
definete o conexiune ntre entiti cu unele structuri i semnificaii comune i este
calea de evideniere a faptului c o informaie nu aparine (nu este unic) numai unei
entiti, ci depinde de una sau mai multe entiti. Fiecrei asocieri i se poate da o
denumire (denumire_asociere) i i se poate asocia o denumire de rol (rol_asociere).
Asocierile dintre entiti (tabele, relaii n cadrul modelului relaional) pot fi de unul din
tipurile de baz: "1" la "1" (1:1), "1" la "muli" (1:n) i "muli" la "muli" (m:n). La aceste tipuri
de baz se adaug, n funcie de completitudinea asocierii, cazuri particulare conform celor
ilustrate n cele ce urmeaz. Asocierea de tip m:n nu este implementabil ca atare de nici-un
SGBD ci prin descompunere n relaii de tip 1:n conform modului prezentat n capitolul 4
dedicat modelului relaional i bazelor de date relaionale i n exemplele din acest paragraf.
Reprezentarea grafic a asocierii (figura 5.2) ine cont de sensul acesteia i factorul de
multiplicitate. n figura 5.3 este prezentat modul de reprezentare a asocierii adoptat de ctre
standardul de proiectare a sistemelor informaionale i informatice UML.

Fig. 5.3. Reprezentarea grafic a asocierilor (UML)

91
Determinarea tipului concret de legtur este efectuat pe baza unei analize a
comportamentului tuplurilor coleciilor ntre care apar. n cele ce urmeaz vom prezenta tipurile
de legturi prin studii de caz. Considerm entitile GESTIUNI i MATERIALE ntre care
exist dependen. La fiecare asociere prezentat este exemplificat o instan a asocierii prin
valorile identificatorilor elementelor entitilor respective specificai prin simboluri de forma Gi
pentru gestiuni i Mi pentru materiale. Simbolurile de forma GiMi specific faptul c
elementele entitii respective sunt identificate de combinaia identificator gestiune-identificator
material. Cu aceste specificri asocierea dintre entitile GESTIUNI i MATERIALE poate
apare ca:
- asociere de tip 1:1 atunci cnd n ntreprindere ntr-o gestiune se poate afla un singur
material (gestiune superspecializat, cum ar fi, de exemplu, un depozit de carburani
care gestioneaz numai benzin fr plumb), iar un material poate aparine de o singur
gestiune, asociere reprezentat conform modului ilustrat n figura 5.4.
- asociere de tip 1:n atunci cnd n ntreprindere o gestiune cuprinde unul sau mai multe
materiale (cum ar fi un depozit de carburani-lubrefiani al unei ntreprinderi care
conine benzin 98, benzin fr plumb, motorin etc), iar un material poate aparine
unei singure gestiuni, asociere reprezentat conform modului ilustrat n figura 5.5.

- asociere de tip m:n, cnd n ntreprindere o gestiune cuprinde unul sau mai multe
materiale, iar un material aparine uneia sau mai multor gestiuni, ilustrat grafic n
figura 5.6. Asocierea de tip m:n se descompune, n general n asocieri de tip 1:n, mai
uor de analizat i implementat la diferite SGBD-uri. Transformarea se realizeaz prin
introducerea unei entiti intermediare, denumit n cazul nostru
GESTIUNI_MATERIALE, conform modului ilustrat n figura 5.7. Entitatea de
legtur introdus

Fig. 5.5. Asociere 1:n
Fig. 5.4. Asociere 1:1

Fig. 5.6. Asociere m:n

Fig. 5.7. Transformarea asocierii m:n n
asocieri 1:n
Capitolul 5
92
Asocierile dintre entiti pot fi: totale (cnd toate realizrile entitilor aflate n relaie
apar n realizrile relaiilor) i pariale (cnd unele din realizrile entitilor nu sunt legate prin
relaie).
De exemplu, dac entitatea GESTIUNI cuprinde informaii despre toate gestiunile unei
ntreprinderi (deci inclusiv gestiunile de semifabricate sau produse finite, care nu sunt
materiale) i dorim s reprezentm asocierea sa cu entitatea MATERIALE. n acest caz pot
exista gestiuni care nu dein nici-un material pentru c, de exemplu, sunt gestiuni de produse
finite (n exemplificare referite cu G4) dar nu poate exista un material care s nu aparin unei
gestiuni. Acest gen de asociere poate fi ilustrat astfel:

S T

G1 ------- -------M1
G2 ------- -------M2
G3 ------- -------M3
G4

n acest caz relaia dintre GESTIUNI i MATERIALE este o relaie parial care se
indic prin 1:0 i care se interpreteaz, n primul sens de la S la T, astfel: entitatea S poate
conine realizri care nu au corespondent n entitatea T i n cel de-al doilea sens n entitatea T
nu pot exista elemente care nu au corespondent n S.
Dac s-ar fi avut n vedere numai gestiunile de materiale relaia putea fi o relaie total:

S T

G1 ------- -------M1
G2 ------- -------M2
G3 ------- -------M3

n stabilirea asocierilor dintre entiti trebuie s se in seama de posibilitatea existenei
de asocieri recursive (asocierea unei entiti cu ea nsi).
Asocierile recursive pot fi, ca orice alt asociere de tipul 1:1, 1:n sau m:n, regulile de
reprezentare fiind generale.
Exemple de asocieri recursive (figura 5.8):

- Asocierea de cstorie. Se utilizeaz n cazul materializrii asocierii de tip "So_Soie"
care poate apare ntre realizrile unei entiti PERSOANE pentru a defini proprietatea
stare civil cu valoarea Cstorit(): unei persoane cstorite "So" i corespunde o
persoan "Soie" i unei persoane "Soie" i corespunde o persoan "So". Dac entitatea
PERSOANE conine numai realizri de tipul acestor cupluri atunci asocierea este de
tipul 1:1. Dac entitatea PERSOANE va conine informaii despre toate persoanele
indiferent dac starea lor civil este Castorit() sau nu atunci asocierea este de tipul
1:0 n sensul c nu trebuie s-i corespund fiecrei persoane perechea sa dar persoanele
exist oricum. Reprezentarea grafic a acestei asocieri este prezentat n figura 5.8 a).


93

- Asocierea de subordonare ierarhic a angajailor. Unui angajat (ef de ...) i sunt
subordonai mai muli angajai iar un angajat este subordonat direct unui singur angajat
(eful su ierarhic), ceea ce corespunde unei asocieri de tipul 1:n. Deoarece n situaii
reale exist cel puin un angajat care nu are un ef direct, cum ar fi directorul general
(sau preedinte, administrator etc), ceea ce ne conduce s alegem o asociere de tip 1:0(n)
n sensul c eful suprem este angajat al ntreprinderii dar nu este subordonat nimnui n
timp ce ceilali angajai sunt subordonai direct unui angajat, ceea ce definete o ierarhie.
Reprezentarea grafic a acestei asocieri este prezentat n figura 5.8 b).
- Asocierea de structurare a unui produs. Un produs este alctuit din mai multe pri
componente, pri care pot fi reprezentate de alte produse i un produs este component
al mai multor produse.. De exemplu, un calculator personal are n componen tastatur,
monitor, mouse, etc i reprezint un produs care se vinde ca atare dar, la rndul lor,
componentele enumerate monitor, tastatur, mouse sunt la rndul lor produse care se
vnd ca atare. Dac analizm un calculator de tip main-frame i acesta utilizeaz una sau
mai multe tastaturi, unul sau mai multe monitoare etc. Reprezentarea acestei asocieri,
care este de tipul m:n este redat n figura 5.8 c).
n determinarea asocierilor dintre entiti trebuie s se in seama i de existena aa
numitor asocieri complexe (asocieri ntre mai mult de dou entiti). De exemplu, fie entitile:
FURNIZORI, MATERIALE, DEPOZITE i asocierile binare corespunztoare, conform
modului ilustrat n figura 5.9 a). Aceste asocieri permit s se determine furnizorul unui material,
ce material intr ntr-un depozit i ce furnizor aprovizioneaz un depozit. ns nu se poate
determina ce furnizor aprovizioneaz cu un produs un anume depozit. Aceste informaii se pot
obine numai prin introducerea unei asocieri, ca entitate de legtur, care s lege cele trei
entiti, conform modului ilustrat n figura 5.9 b). Orice asociere complex poate fi descompus
n asocieri binare n acelai mod n care o asociere m:n este descompus n asocieri 1:n.
Odat stabilit o asociere ntre anumite entiti, indiferent de tipul acestora, deosebit de
important este definirea corect a semnificaiei acesteia. nelegerea corect a semanticii
asocierii este esenial n utilizarea ei ulterioar, n interpretarea informaiilor regsite pe baza
acesteia, n memorarea corect a diferitelor informaii. Erorile de interpretare se produc datorit
existenei, n cele mai multe cazuri, a mai multor asocieri ntre entiti.
De exemplu, ntre entitile: PRODUSE i SECTII pot exista asocieri de consum a
produselor n cadrul seciilor sau asocieri de producere (realizare) a produselor n secii. De
aceea, cnd se stabilete asocierea trebuie bine fixat semnificaia, semantica atribuit asocierii.
Sau, ntre entitile: SECTII i ANGAJAI se pot stabili asocieri de ncadrare a unei persoane
n activitatea unei secii sau asocieri de conducere a unei secii de ctre o anumit person (eful
de secie).

Exemple de asocieri complexe: n cadrul subsistemului aprovizionrii pot fi identificate
urmtoarele tipuri de obiecte simple: MATERIALE, PRODUSE, CONTRACTE, FURNIZORI,
GESTIUNI, SECTII, ANGAJATI etc. Se vor analiza n continuare relaiile stabilite ntre aceste

Fig. 5.8. Exemple de asocieri recursive
1
PERSOANE
1 (0)
1
ANGAJAI
n(0)
m
PRODUSE
n
a) b) c)
Capitolul 5
94
obiecte simple apoi se va construi diagrama dependenelor dintre entitile asociate obiectelor
identificate.

- Asocierea dintre MATERIALE i FURNIZORI. Un material poate fi furnizat de unul
sau mai muli furnizori, iar un furnizor poate furniza unul sau mai multe materiale, ceea
ce nseamn c o astfel de situaie genereaz o asociere de tip muli-la-muli (figura 10
a). Pentru transpunerea n practic a unei astfel de asocieri se recurge la transformarea
acesteia de la tipul de legtur m:n la o legtur de tipul 1:n prin introducerea unei
entiti intermediare pe care o vom denumi MATERIALE_FURNIZORI, ceea ce ar
nsemna c asocierea iniial va suporta modificri sub aspectul descrierii ei i va apare
grafic ca n figura 5.10 b). Principial informaia pe care trebuie s o reprezinte entitatea
de asociere ar fi reprezentat de identificatorul realizrilor entitii materiale i
identificatorul entitii furnizori. Datele stocate vor conine perechi de valori ale acestor
identificatori.

- Asocierea dintre MATERIALE i CONTRACTE. Un material poate fi contractat prin
mai multe contracte iar un contract poate cuprinde mai multe materiale, ceea ce
nseamn c i de aceast dat se impune o entitate intermediar, conform modului
ilustrat n figura 5.11 a) i b).
- Asocierea dintre MATERIALE i GESTIUNI. Un material poate aparine uneia sau mai
multor gestiuni i o gestiune cuprinde unul sau mai multe materiale. Reprezentarea
asocierii m:n este prezentat n figura 5.12 a) iar transformarea sa n asocieri de tipul 1:n
n figura 5.12 b).
- Asocierea dintre MATERIALE i TEHNOLOGII. Un material este utilizat de una sau
mai multe tehnologii de fabricaie iar o tehnologie de fabricaie poate utiliza mai multe
materiale. Legtura dintre aceste tipuri simple de obiecte este asigurat de entitatea
intermediar MATERIALE_TEHNOLOGII. ntre aceste obiecte simple exist o
coresponden tot de tipul m:n, care trebuie transformat ntr-o relaie de tipul 1:n,
conform modului ilustrat n figura 5.13 a) i b). n acest caz entitatea de legtur
MATERIALE_TEHNOLOGII poate conine, pe lng identificatorii entitilor
implicate i atribute proprii cum ar fi, de exemplu, consumul specific, preul operaiei
etc.
Prin analogie mai pot fi identificate i alte obiecte i relaii referitoare la subsistemul de
aprovizionare.

a) b)
Fig. 5.10. Asocierea MATERIALE-FURNIZORI
FURNIZORI
n
MATERIALE
m
MATERIALE
FURNIZORI
FURNIZORI_
MATERIALE

95

a) b)
Fig. 5.11. Asocierea MATERIALE-CONTRACTE

a) b)
Fig. 5.12. Asocierea MATERIALE-GESTIUNI

a) b)
Fig. 5.13. Asocierea MATERIALE-TEHNOLOGII
GESTIUNI
n
MATERIALE
m
MATERIALE
GESTIUNI
GESTIUNI_
MATERIALE
TEHNOLOGII
n
MATERIALE
m
MATERIALE
TEHNOLOGII
TEHNOLOGII_
MATERIALE
CONTRACTE
n
MATERIALE
m
MATERIALE
CONTRACTE
CONTRACTE_
MATERIALE
Capitolul 5
96
5.2. Normalizarea tabelelor bazei de date

5.2.1. Conceptul de normalizare

innd seama de faptul c definirea i stocarea datelor sub forma coleciilor sufer n
timp o serie de schimbri, n faa proiectanilor se ridic numeroase probleme de genul:
- pot fi prevzute logic i riguros problemele de actualizare a datelor i inute sub control
toate modificrile ce intervin ?
- cum s-ar putea imagina o structur iniial de colecii de date care s sufere ct mai
puine modificri n viitor i s fie, totui, ct mai flexibil ?
- cum s-ar putea proiecta acea structur iniial de colecii da date care s produc n viitor
cele mai puine dificulti privind actualizarea datelor sau modificarea structurii datelor?
- cum poate fi asigurat o independen sporit a programelor de aplicaie fa de
structura datelor (imunitatea programelor de aplicaie fa de structura datelor) ?
Bazele de date relaionale in foarte mult seama de aspectul dinamic al structurii i strii
datelor i caut s dea soluia unei astfel de probleme. Tocmai ntreaga filozofie a bazelor de
date relaionale pornete de la posibilitatea schimbrii frecvente a structurii i actualizrii
datelor. Ele i regsesc aplicabilitate deplin acolo unde exist o dinamic mare a modificrilor
structurii n timp i spaiu.
n activitatea de proiectare a structurii bazelor de date relaionale se utilizeaz tehnica
normalizrii relaiilor, care caut s dea rspuns ntrebrilor formulate anterior.
Pentru nelegerera tehnicii normalizrii relaiilor inem s precizm c, bazele de date
relaionale se sprijin pe teoria matematic a milimilor. Conform acestei teorii, reprezentarea
oricrei structuri de date poate fi redus, acceptnd o anumit redundan, la un tabel sau mai
multe tabele bidimensionale ce caracterizeaz relaii ntre mulimi. Tabelele trebuie astfel
construite nct s nu piard informaii de legtur. Prin procesul de normalizare se precizeaz
structura logic a unui ansamblu de date, n specificul realiilor lor, sub form de tabele
bidimensionale, nlturnd astfel complexitatea i rigiditatea structurii bazei de date.
Teoria normalizrii este construit n jurul conceptului de forme normale (FN). Au fost
definite numeroase forme normale. Iniial Codd a definit trei forme normale: FN1, FN2, FN3.
Forma normal trei (FN3), definit original de Codd, sufer de anumite inadvertene. O definiie
revzut (mai puternic) a formei normale trei a fost dat de Boyce i Codd n [CODD 74] i
este referit n literatura de specialitate sub prescurtarea BCNF (Boyce Codd Normal Form). R.
Fagin a definit [FAGIN 77] o nou form "a patra" (FN4) i apoi [FAGIN 79] nc o form
normal, numit "forma normal proiecie-jonciune" (PJ/NF), cunoscut i ca forma normal
cinci (FN5). Despre o relaie (un tabel) se spune c este ntr-o form normal particular dac
satisface anumite restricii. Motivarea acestor restricionri este c relaiile n FN2 sunt de
preferat celor n FN1, ntr-un sens ce va fi discutat ulterior, c la rndul lor rndul lor relaiile n
FN3 sunt preferabile celor n FN2 .a.m.d.
Figura 5.14. sugereaz faptul c toate relaiile normalizate sunt n forma normal unu
(FN1), o parte din relaiile FN1 sunt i n forma normal doi (FN2), o parte din relaiile (FN2)
sunt i n forma normal trei (FN3), o parte din relaiile FN3 sunt i n forma normal
Boyce-Codd (BCNF), o parte din relaiile BCNF sunt i n forma normal patru (FN4) i n
sfrit, o parte din relaiile FN4 sunt i n forma normal cinci (FN5). Numrul formelor
normale definite n prezent este de 9 dar majoritatea SGBD actuale lucreaz corect cu baze de
date n forma normal FN3 (BCNF, este preferabil).


97

Prin parcurgerea acestor forme normale se ajunge n mod succesiv s se amelioreze
structura bazei de date, nlturndu-se treptat o serie de neajunsuri i imprimnd faciliti sporite
n privina ncrcrii, actualizrii i exploatrii bazei de date. De remarcat faptul c, nu n toate
cazurile se impune parcurgerea tuturor formelor normale, ns n mod obligatoriu prima form
normal este implicat.

5.2.2. Obiectivul i necesitatea normalizrii relaiilor

E. F. Codd a observat, la modelul de date relaional, c anumite relaii pot genera o serie
de situaii nedorite, aa numitele "anomalii de actualizare". Pentru a ilustra principiile de baz
ale acestora vom considera exemplul din figura 5.15 n care este prezentat un tabel cu informaii
utile privind persoanele implicate n activitatea de cercetare i fondurile implicate la derularea
unor proiecte. Un angajat poate participa la mai multe proiecte de cercetare iar un proiect de
cercetare poate fi realizat de mai muli angajai
.
Angajat Salariu Proiect Buget Funcie
AVRAM 5 BM 80 Proiectant
AVRAM 5 CNEAA 20 Director
BOB 4 CNEAA 20 Consultant
BODEA 6 MEC 50 Director
PTRULESCU 5 BM 80 Programator
SABU 6 BM 80 Director
SABU 6 MEC 50 Consultant
THIESS 3 CNEAA 20 Tehnician
THIESS 3 MEC 50 Tehnician
VOICA 3 BM 80 Proiectant
Fig. 5.15. O instan a relaiei CERCETARE

Cheia primar a acestui tabel este format din atributele Angajat i Proiect. Aceast
relaie respect, n afara proprietilor generale ale unui tabel n modelul relaional, urmtoarele
proprieti:
- salariul fiecrui angajat este unic i depinde numai de angajat (este independent de

Fig. 5.14. Normalizare Forme Normale
Capitolul 5
98
proiectul la care lucreaz);
- bugetul alocat fiecrui proiect depinde numai de proiect i este independent de angajaii
care lucreaz la el.

Vom analiza aceast relaie din punctul de vedere al coninutului su i al operaiilor pe
care dorim s le efectum cu datele sale:
- valoarea pentru salariu a fiecrui angajat este repetat n toate rndurile care se refer la
el; similar valoarea bugetului alocat unui proiect este repetat n toate rndurile legate de
acesta. n aceste cazuri avem o redundan dat de aceste repetri;
- dac se schimb salariul unui angajat sau dac se modific (se suplimenteaz sau
reduce) bugetul unui proiect va trebui s modificm acea valoare n toate liniile n care
apare. Din acest actualizare a informaiei n mai multe tupluri pot rezulta tupluri, din
diverse motive, n care informaia este actualizat i tupluri n care nu este. Aceast
anomalie este referit ca anomalia de actualizare;
- dac un proiect se termin atunci datele sale trebuiesc terse din tabel. Prin tergerea
liniilor referitoare la proiect putem s pierdem informaiile privind angajaii i salariul
lor, de exemplu, prin stergerea proiectului MEC s-ar pierde datele despre angajatul
BODEA care lucreaz numai la acest proiect. Acest lucru apare deoarece Proiect este
parte a cheii primare i n acest context nu putem s pstrm rnduri care nu au valori
pentru atributele cheie. Aceast anomalie este referit ca anomalia de tergere;
- dac dorim s angajm o nou persoan nu vom pute introduce datele sale de
identificare i salariale pn cnd nu-l repartizm la cel puin un proiect sau nu putem s
nregistrm un proiect nou pn cnd nu i repartizm cel puin un angajat. Aceast
anomalie semnalat este referit ca anomalie de tergere.

Anomaliile semnalate apar datorit faptului c:
- n activitile reale este necesar s repetm datele ceea ce face ca o aceeai dat s apar
n diferite tupluri;
- Anomalia de tergere rezult din faptul c tergnd un tuplu al unei relaii, odat cu
eliminarea informaiilor ce trebuiau terse se pierd i informaiile utile, existente n
tuplul respectiv. Aceast anomalie nu apare neaprat atunci cnd tergem tuplul n
ntregime ci mai degrab atunci cnd dorim s tergem numai un cmp iar informaia n
ntregime devine astfel invalid;
- Anomalia de adugare (inserare) rezult din faptul c nu pot fi incluse noi informaii,
necesare, ntr-o relaie dac nu se cunosc i alte informaii cerute pentru adugarea unui
nou tuplu la acea relaie, n principal valorile pentru atributele din cheie;
- Dac o anumit informaie este repetat redundant actualizarea sa trebuie s fie repetat
pentru fiecare apariie a sa. Astzi SGBD-urile comercializate pun la dispoziie, prin
SQL de exemplu, comenzi prin care se poate specifica actualizrile multiple ceea ce
rezolv problema dar numai din punctul de vedere al programatorului i nu a sistemului
bazei de date. Aceast anomalie de modificare rezult din faptul c este dificil de
modificat o valoare a unui atribut atunci cnd ea apare n mai mult dect ntr-un tuplu al
relaiei deoarece la actualizare este necesar accesarea fizic a mai multor tupluri iar
cderile pot provoca timpi de refacere considerabili.
Anomaliile de actualizare nu apar numai la modelul relaional ci i la celelalte modele
de date cum ar fi ierarhic, reea i fiierele clasice. Pentru modelele ierarhic i reea nu exist o
teorie a rezolvrii anomaliilor de actualizare. Rezolvarea lor este lsat n seama utilizatorilor
fr s fie dat cel puin o indicaie n acest sens. Din aceast cauz apar n mod frecvent
anomalii de actualizare la bazele de date de tip ierarhic sau reea deja ncrcate cu date reale,
cnd este foarte costisitor i foarte dificil s schimbi structura bazei de date. Ori, problema

99
anomaliilor de actualizare trebuie rezolvat n etapa de proiectare a bazei de date i nu dup ce
baza de date a fost ncrcat cu date reale i au fost scrise aplicaii pentru ea.
n acest context, teoria normalizrii relaiilor i propune, nlturarea acestor anomalii
nc din faza de proiectare a structurii bazei de date. Deci, se poate arta c prin normalizarea
relaiilor se urmresc n mod deosebit performane de ordin logic i n mod implicit vor rezulta
i performane de ordin fizic, cum ar fi ocuparea raional a suportului de memorie extern sau
reducerea timpului de rspuns al sistemului.

5.2.3. Dependene funcionale

Conceptul de dependen funcional (DF functional dependency), n domeniul
proiectrii structurii bazelor de date, a fost introdus de E.F. Codd n scopul de a caracteriza
relaiile care pot fi descompuse fr pierderi de informaii n dou sau mai multe relaii. O
dependen funcional este o form particular de restricie de integritate a modelului relaional
care descrie asocierile funcionale dintre atributele unei relaii. Pentru a explica acest concept de
dependen funcional vom analiza relaia din figura #.15. n aceast tabel bugetul alocat unui
proiect este unic i ori de cte ori apare acelai proiect ntr-un tuplu valoarea bugetului rmne
aceeai. Putem afirama faptul c valoarea atributului Buget este dependent funcional de
valoarea atributului Proiect, adic formal putem afirma c exist o funcie care asociaz fiecrei
valori pentru atributul Proiect a singur valoare pentru atributul Buget.

Definiie: Fie relaia r cu schema de relaie R(X) cu X = {A
1
,A
2
,...,A
n
} i Y i Z
submulimi nevide de atribute din {A
1
,A
2
,...,A
n
}. Se spune c avem o dependen funcional pe
r ntre Y i Z (notat cu YZ) dac pentru toate toate tuplurile pereche t
1
, t
2
er avnd aceeai
valoare a atributelor Y tuplurile t
1
, t
2
au aceeai valoare pentru atributele Z, adic: t
1
[Y] =
t
2
[Y] t
1
[Z] = t
2
[Z]

Cu alte cuvinte, fiind dat o schem de relaie R(X) i r(X) o instan a sa, atributul
(sau mulimea de atribute) ZeX este dependent funcional de atributul YeX dac i numai
dac dou sau mai multe tupluri din r cu aceeai valoare y
1
n coloana Y implic existena
aceleiai valori z
1
n coloana Z a acelor tupluri.
Mai simplificat, fiind dat o schem de relaie R, atributul YeR este dependent
funcional de atributul XeR, dac i numai dac pentru o valoare atribuit lui X, lui Y i va
corespunde ntotdeauna o singur valoare. Pe orice relaie exist anumite dependene
funcionale care sunt triviale. n general o dependen funcional XY este trivial dac
Y_X.
Cel mai simplu exemplu de dependen funcional l constituie corespondena
biunivoc dintre mulimea codurilor de materiale i mulimea denumirilor de materiale. Unui
anumit cod de material i va corespunde ntotdeauna o anumit denumire de material.
Pentru a sugera dependea funcional dintre un atribut sau o mulime de atribute Y fa de un
atribut sau o mulime de atribute X se recurge la notaia: XY (adic Y depinde funcional de
X), unde X formeaz partea stng, iar Y partea dreapt a dependenei funcionale. Pe exemplul
din figura 5.15 avem dependenele funcionale: ProiectBuget, AngajatSalariu.
Deoarece atributele Angajat i Proiect reprezint cheia i conform definiiei acesteia nu
putem avea dou valori identice vom avea dependena Angajat ProiectSalariu Buget Funcie.
Prin construcia Angajat Proiect se desemneaz de fapt {Angajat, Proiect}, notaie care va fi
utilizat n expunere.
Capitolul 5
100
Noiunea de dependen funcional generalizeaz noiunea de supercheie: mulimea de
atribute K este o supercheie a unei relaii R(X) dac KX. Prin acest generalizare a noiunii
de supercheie dependenele funcionale ne permit s definim restricii de integritate care nu pot
fi exprimate prin supercheie.
Dependenele funcionale pot fi utilizate n dou moduri:
- Pentru a testa dac relaiile sunt legale pe un set de dependene funcionale. Dac o
relaie r este legal pe setul de dependene funcionale F vom spune c relaia r satisface
F;
- Pentru a specifica restriciile pe setul relaiilor legale. n acest mod ne permite s lum n
calcul numai acele relaii care satisfac setul dat de dependenr funcionale.

Plecnd de la relaia produsului cartezian dintre mulimile de atribute A i B aparinnd
domeniilor DOM.A i respectiv DOM.B, forma generalizat a dependenei funcionale apare
astfel: A
1
A
2
...A
n
B
1
B
2
...B
n

ntr-o relaie n care apar chei concatenante (chei formate din combinaia mai multor
atribute), ntre atributele cheie i atributele ce nu fac parte din cheie (noncheie) pot exista
dependene funcionale complete i pariale.

Exemplu: Fie relaia r, definit pe schema R(A,B,C,D):

r A B C D
t
1
a1 b1 c1 d1
t
2
a1 b2 c1 d2
t
3
a2 b2 c2 d2
t
4
a2 b3 c2 d3
t
5
a3 b3 c2 d4

Pe acest relaie se observ c:
- exist dependena AC deoarece avem dou tupluri care au n coloana A valoarea a1
iar aceste tupluri au aceeai valoare c1 n coloana C; similar celor dou tupluri cu
valaorea a2 n A le corespunde aceeai valoare c2 n C i nu mai avem alte perechi
distincte de tupluri cu aceeai valoare pentru A;
- dependena funcional CA nu este satisfcut deoarece dac lum perechea de tupluri
t
4
i t
5
care au ceeai valoare c2 n coloana C acestea nu au aceeai valoare n coloana A,
adic avem tuplurile t
4
i t
5
pentru care t
4
[C]=t
5
[C] dar t
4
[A]#t
5
[A];
- exist i alte dependene satisfcute de relaia r cum ar fi: ABD (observai
combinaiile valorilor din coloanele AB), AA etc.

Exemplu: Fie relaia R cu schema de relaie R(A, B, C, D, E, F, G) i cheia relaiei
format din atributele A i B. ntre atributele relaii dependenele funcionale sunt cele redate n
diagrama dependenelor funcionale reprezentat n figura 5.16. n figura 5.16 se sugereaz c
atributele C i D depind funcional de atributul A, care face parte din cheie, iar atributele E, F, G
depind funcional att de atributul A ct i de B. n primul caz se spune c avem de a face cu o
dependen funcional parial (atributele C i D nu depind de ntreaga cheie a relaiei ci doar
de o parte a acesteia, de A), iar n al doilea caz cu o dependen funcional complet (atributele
E, F, G depind de ntreaga cheie i nu numai de o parte a ei). Deci, atributele C i D pot fi
privite ca dependente parial de A i B i dependente complet de A.

101

n contextul acestor dou exemple se poate spune c un atribut sau o mulime de atribute
B din cadrul unei relaii este dependent() funcional complet de o mulime de atribute A ale
aceleiai relaii dac B este n mod funcional dependent() de ntrega mulime A i nu numai de
o submulime a lui A.
Remarcm faptul c recunoaterea dependenelor funcionale este o parte esenial a
nelegerii semnificaiei sau semanticii datelor. n general, dac avem un set de dependene
funcionale, aceste dependene funcionale pot implica alte dependene funcionale. De exemplu
presupunem c avem o relaie cu schema R(A,B,C,D,E,F) i un set de dependene pe acesta:
{AB, AC, CDE, CDF, BE}, pe care le vom reprezenta grafic ca n figura 5.17
(liniile continue). n general nu este suficient, pentru o relaie dat, s considerm numai
dependenele funcionale date ci toate dependenele funcionale care au loc.
Dac F este un set dat de dependene funcionale se poate demonstra c exist i alte
dependene funcionale, despre care vom spune c sunt logic implicate de F. Pe exemplul
nostru, dependena AE este logic implicat deoarece AB i BE, adic B este dependent
de A iar E este dependent de B ceea ce conduce logic la E depinde de A i similar se poate
deduce dependena AF (figura 5.17 liniile punctate).
Vom nota cu F
+
nchiderea lui F, cu F
+
reprezentat de setul tuturor dependenelor
funcionale logic implicate de F. Dac F este dat atunci aplicnd repetat o serie de reguli
(denumite axiome sau regului de inferen) putem calcula nchiderea sa. Dac F este mare
atunci calculul lui F
+
poate s fie extrem de laborios. Fie W, X, Y i Z mulimi de atribuite
aparinnd unei relaii R.
Dependenele funcionale dintre atributele unei relaii se supun urmtoarelor reguli de
baz (denumite axiome sau reguli de inferen):
- Reflexivitate. Dac X este o mulime de atribute i Y este o submulime a sa, adic
Y_X, atunci XY;
- Cretere. Dac XY, atunci XZYZ. Aceast regul semnific faptul c dac X
determin pe Y atunci aceste dou mulimi de atribute pot fi mbogite printr-o a treia
mulime Z;
- Tranzitivitate. Dac XY i YZ, atunci XZ.
Aceste trei reguli ce guverneaz dependena funcional sunt cunoscute n literatura de
specialitate sub denumirea de <<Axiomele lui Armstrong>> i ele nu genereaz nici-o
dependen funcional incorect.

Fig. 5.16. Exemplu de diagram a dependenelor
funcionale
Capitolul 5
102

Din aceste axiome mai pot fi deduse alte cteva reguli i anume:
- Reuniune. Dac XY i XZ, atunci XYZ;
- Pseudotranzitivitate. Dac XY i YWZ, atunci XWZ;
- Descompunere. Dac XYZ, atunci XY i XZ.
Dac aplicm aceste reguli setului de dependene funcionale F={AB, AC,
CDE, CDF, BE} vom obine, printre altele, urmtoarele dependene din F
+
:
- AE din AB i BE prin tranzitivitate (regula 3);
- CDEF din CDE i CDF prin reuniune (regula 4);
- ADF din AC prin cretere (regula 2) avem ADCD iar CDF prin definiie i
aplicnd tranzitivitatea obinem ADF;
- ADE similar precedentei; etc.
Utiliznd aceste reguli apare posibilitatea definirii noiunii de dependen funcional
elementar de forma XA, unde A este un atribut unic neinclus n X (A.X) i nu exist un alt
atribut X'X astfel nct X'A.
Plecnd de la o mulime de dependene funcionale elementare, se pot compune prin
tranzitivitate alte dependene funcionale elementare. Se ajunge astfel la noiunea de dependen
tranzitiv a unei mulimi de dependene funcionale elementare, mulime de dependene ce va fi
utilizat la definirea formei normale 3 (FN3).

5.2.4. Formele normale unu, doi i trei

Primele trei forme normale au ca obiectiv definirea unei scheme conceptuale a bazei de
date plecnd de la entitile i asocierile iniiale ale modelului real.
n general se pleac de la o relaie universal (entitate unic) sau chiar de la mai multe
relaii i se urmrete descompunerea fr pierderi de informaii a relaiilor n subrelaii care nu
sufer de anomalii de ordin logic i fizic. Descompunerea relaiilor se va face pe baza analizei
dependenelor funcionale dintre atributele cheie i atributele care nu fac parte din cheie.
ntregul proces de normalizare se desfoar n etape succesive (forme normale) i se
caracterizeaz prin rafinament, iar n final va duce la izolarea entitilor i asocierilor lumii reale
n scopul facilitrii manipulrii relaiilor. Descompunerea relaiilor n subrelaii presupune o
bun nelegere a proprietilor semantice a datelor. O proast nelegere a lumii reale i a
semnificaiei datelor ce o descriu poate conduce la relaii problematice.

Fig. 5.17. Dependene funcionale logic implicate

103

Figura 5.18 sugereaz, n principiu, procesul de normalizare plecnd de la o relaie
universal printr-un proces de descompunere. Dac U este o schem de relaii (universal sau
nu) atunci mulimea schemelor de relaii {R
1
,R
2
,...,R
n
} este o descompunere a lui U dac orice
atribut din U apare cel puin ntr-o relaie R
i
, unde i=1,..,n, adic
n
i
i
R U
1 =
= . Fie u o relaie cu
schema U i fie
[
=
i
R
i
u r ) ( cu i=1,2,...,n, adic {r
1
,r
2
,...,r
n
} este baza de date care rezult
prin descompunerea lui U n {R
1
,R
2
,...,R
n
}. ntotdeuna vom avea
i
n
i
r u

=
_
1
.

Pentru exemplificare ne vom referi la definirea schemei conceptuale a unei baze de
date simplificate privind activitatea de aprovizionare cu materii prime i materiale.
n acest scop vom defini dou relaii iniiale cu denumirile CONTRACTE i respectiv
MATERIALE ale unei baze de date pentru activitatea de Aprovizionare. Totodat, vom pleca
de la premisa c un contract se ncheie cu un anumit furnizor, c printr-un contract pot fi
cumprate unul sau mai multe materiale, c un material poate fi livrat ntr-o singur tran sau
n mai multe, ealonate pe termene prestabilite, ceea ce se sugereaz n figura 5.19.

unde:
- F semnific un anumit furnizor;
- C
i
contractul i ncheiat cu un anumit
furnizor;
- M
j
materialele contractate printr-un anumit
contract;
- P
i
tran de materiale;

Fig. 5.18. Semnificaia procesului de normalizare

Fig. 5.19. Structura datelor n relaia
CONTRACTE
Capitolul 5
104
Structura iniial a celor dou relaii apare astfel (figura 5.20):
MATERIALE = <CODM, DENM, UM, PRET_LIVR, STOC_SIG, STOC_EX,
STOC_NORMAT, NECESAR_APROVIZIONAT>
CONTRACTE = <NRC, DATAC, VALC, CODF, DENF, ADRESA<CODL,DENLOC>,
TELEFON, PREFIX, CONTB, MATERIALE<CODM, PU, CANT_CONTR,
ESALONARI<LUNA, CANTPL, CANTLIVR, CANREF>>>

Fig. 5.20. Relaii iniiale

unde semnificaia prescurtrilor este:
CODM-codul materialului; DENM-denumire material; UM-unitatea de msur;
PRET_LIVR-pre livrare; STOC_SIG-stoc de siguran; STOC_EX-stoc existent;
NRC-numr contract; DATAC-data ncheierii contractului; VALC-valoarea
contractului; CODF-codul furnizorului; DENF-denumirea furnizorului; CODL-Cod
Localitate; DENL-Denumire localitate; PREFIX-prefixul telefonic al localitii;
CONTB-cont la banc; CANTPL cantitatea planificat a fi livrat n cadrul unei luni;
CANTLIVR cantitatea livrat n cadrul unei luni; CANTREF - cantitatea refuzat n
cadrul unei luni.

n cadrul relaiilor au fost subliniate atributele care fac parte din cheie ale fiecrei
relaii.

Aplicnd tehnica normalizrii, s urmrim n ce msur relaiile n forma iniial
prezint anumite anomalii de ordin logic i fizic i cum anume pot fi nlturate aceste anomalii,
astfel nct, n final, s se ajung la o structur performant sub aspectul facilitilor de
ncrcare, adugare, modificare i regsire a datelor.
Primul pas n cadrul procesului de normalizare const n a analiza relaiile prin prisma
cerinelor i restriciilor formei normale unu (FN1).

Definiie: O relaie R se gsete n FN1 dac i numai dac atributele ei conin numai
valori elementare (atomice).

Conform definiiei date, relaia MATERIALE se gsete n FN1, ns relaia
CONTRACTE nu ntrunete cerinele specificate i deci ea nu este n FN1. Se observ c n
cadrul relaiei CONTRACTE, atributul ADRESA genereaz valori compuse din codul
localitii (CODL), denumirea localitii (DENLOC) etc.
Totodat, se observ c este posibil ca printr-un contract s se contracteze mai multe
materiale, iar fiecare material s fie ealonat n trane corespunztoare fiecrei luni a anului.
Acest aspect face ca n cadrul relaiei CONTRACTE anumite atribute, cuprinse n paranteze
unghiulare i regrupate sub denumirile de MATERIALE i EALONRI, s genereze valori
repetitive. Deci, exist tupluri ale cror valori nu sunt atomice (valorile ncadrate n
dreptunghiuri punctate).
Prezena n cadrul relaiilor a unor cmpuri compuse (MATERIALE i ESALONARI)
generatoare de atribute cu valori repetitive vor putea produce o serie de anomalii, astfel:
- la modificarea datelor, poate apare necesitatea coreciei acelorai date n mai multe
tupluri;
- cu ocazia tergerii unor tupluri se pot distruge informaiile de legtur existente ntre
anumite relaii;
- ngreuneaz, n ansamblu, activitatea de ncrcare i ntreinere a bazei de date.

105
Referitor la atributul ADRESA, care genereaz valori compuse i acesta poate
determina neajunsuri att sub aspectul ncrcrii i actualizrii acelorai date de mai multe ori,
ct i sub aspectul descrierii i modului de reprezentare pe suportul de memorie extern.
Pentru a normaliza relaia CONTRACTE vom descrie, pe de o parte, atributul ADRESA
sub forma cod-localitate (CODL) i denumire-localitate (DENLOC), iar pe de alt parte, vom
avea n atenie c orice relaie care conine cmpuri compuse se poate "sparge" n attea relaii
suplimentare cte cmpuri generatoare de repetiii exist. Pentru aceasta, fiecare apariie de
cmp compus care genereaz repetiia se asociaz n relaia cu cheia primar.
n mod asemntor, orice structur de date de tip arborescent sau reea se poate descrie
ca o succesiune de relaii dup urmtorul algoritm de normalizare:
- se ia prima relaie de la rdcina arborelui i cheia sa primar se va insera naintea cheii
primare a relaiilor subordonate;
- se suprim n relaia rdcin cmpurile agregate ce accept o descompunere pn la
nivel elementar;
- se repet n aceiai manier operaia cu fiecare subarbore al structurii.
Conform acestor precizri relaia CONTRACTE va fi descompus n urmtoarele
subrelaii:

CONTRACTE = <NRC, CODF, DENF, CODL, DENLOC, TELEFON, PREFIX, CONTB,
DATAC, VALC>
MATERIALE_CONTRACTE = <NRC, CODM, PU, CANT_CONTR>
ESALONRI_LIVRRI = <NRC, CODM, LUNA, CANTPL, CANTLIVR, CANTREF>

Fig. 5.21 Relaii n FN1 deduse din relaia CONTRACTE din figura 5.20

Prin aceast descompunere a relaiei iniiale CONTRACTE s-a ajuns la trei subrelaii cu
chei concatenate (atributele subliniate), ce se gsesc n FN1.
De remarcat faptul c n urma acestor descompuneri nu s-a pierdut nici o informaie de
legtur, relaia iniial putnd fi reconstituita n orice moment.
Raiunea pentru care orice cmp poate genera grupuri de atribute repetitive s fie trecut
ntr-o relaie separat deriv, pe de o parte, din complexitatea relaiei iniiale care poate deveni
necontrolabil sub aspectul gestiunii tuplurilor, iar pe de alt parte, se obin relaii mai simple
care sunt mai uor de ncrcat i actualizat.
Pasul imediat const n a verifica relaiile prin prisma cerinelor formei normale doi
(FN2).

Definitie: Se spune c o relaie R este n FN2 dac i numai dac este n FN1 i dac
este asigurat dependena funcional complet dintre atributele cheie i atributele noncheie.

Remarcm faptul c problema dependenei funcionale complete se pune pentru relaiile
la care s-au definit chei concatenate (chei multi-atribut). Pentru relaiile cu chei formate dintr-un
singur atribut dependena funcional complet este implicit.

Se observ c anumite relaii din figura 5.21 au chei concatenate, formate din dou, <
NRC,CODM> i respectiv trei atribute, < NRC,CODM,LUNA>. n aceast situaie se impune
continuarea analizei relaiilor, punnd n eviden dependenele funcionale dintre atributele
cheie i atributele noncheie. Dependenele funcionale corespunztoare fiecrei relaii din figura
5.21 pot fi evideniate prin diagramele din figura 5.22.
Capitolul 5
106

Studiind diagramele din figura 5.22. se poate observa c n relaiile CONTRACTE,
MATERIALE_CONTRACTE i ESALONRI_LIVRRI este asigurat dependena
funcional complet dintre atributele noncheie i atributele cheie, ceea ce nseamn c cele trei
relaii se gsesc i n FN2.
Dac n cadrul unei relaii ar exista dependene funcionale pariale ar trebui s
descompunem relaia de referin n subrelaii pentru a asigura dependena funcional complet
dintre atributele noncheie i cheia relaiei.

Exemplu: Fie o relaie R cu schema X
1
={A,B,C,D,E,F,G} n care cheia relaiei este dat
de atributele A i B. Considerm c atributele C D E depind de ntreaga cheie A B, iar
atributele F i G depind doar de B (deci de o parte a cheii concatenate). ntr-o astfel de situaie
se spune c relaia R nu este n FN2 ntruct prezint dependene pariale care produc i ele
anomalii de genul celor ntlnite la FN1. Anomaliile vor fi nlturate prin descompunerea
relaiei R n dou subrelaii cu schemele de definire X
2
i X
3
, astfel:
R
2
cu X
2
={A,B,C,D,E} i
R
3
cu X
3
={B,F,G}
Relaiile R
2
i R
3
sunt n FN2.

O alt situaie care poate genera anomalii cu ocazia crerii, actualizrii i exploatrii
unei baze de date o constituie prezena n cadrul unei relaii a dependenei tranzitive a
atributelor fa de cheia primar a relaiei respective. Dependena tranzitiv apare n situaia n
care ntr-o relaie exist atribute noncheie care determin valori pentru alte atribute noncheie.
Dac analizm relaia CONTRACTE din figura 5.21 i diagramele din figura 5.22 putem
deduce prezena dependenei tranzitive n cadrul acestei relaii, redat n mod sugestiv n figura
5.23.

Fig. 5.22. Diagrama dependenelor funcionale

107
Din figurile 5.22 i 5.23 se observ c n cadrul relaiei CONTRACTE (figura 5.21) exist
o dubl tranzitivitate, adic exist dou atribute noncheie (CODF i CODL) care determin
valori pentru alte atribute noncheie, astfel:
- CODF determin valori pentru atributele noncheie DENF, TELEFON i CONTB;
- CODL determin valori pentru atributele noncheie DENLOC i PREFIX.
Tipurile de anomalii determinate de dependena tranzitiv sunt de genul celor amintite la
FN1.
Pentru a evidenia ct mai sugestiv anomaliile provocate de prezena dependenei
funcionale n cadrul relaiei CONTRACTE din figura 5.21, vom recurge la asocierea de valori
corespunztoare atributelor relaiei i aducerea acesteia la o form tabelar (tabela 5.1).
Pe baza datelor din tabela 5.1 vom cuta s evideniem cteva anomalii posibile a fi
generate de prezena dependenei tranzitive n cadrul relaiei CONTRACTE, astfel:
- tergere. n momentul expirrii unui contract acesta urmeaz a fi ters din baza de
date, ceea ce nseamn c vor fi terse informaiile despre furnizori i localiti, iar n
momentul rencheierii contractelor va trebui s se rencarce toate informaiile. n
general, pentru unitile economice, furnizorii se menin cam aceiai de la un an la
altul. Deci, n cadrul bazei de date informaiile despre furnizori i localiti au o mare
stabilitate. ntr-o astfel de mprejurare se pune n mod firesc ntrebarea: de ce s se
tearg aceste informaii de fiecare dat cnd expir un contract ? Este de dorit ca
informaiile despre furnizori i localiti s fie pstrate n relaii separate. n acest fel
va fi evitat activitatea de reculegere i ncrcare a datelor despre furnizori;

Tabela 5.1. CONTRACTE n FN1
NRC
#
CODF# DENF COD
L
DENLOC TELEFON PREFIX CONTB DATAC VALC
100 1000 CV 7000 BUC 4435771 01 1234567 10/01/2001 100
101 1000 CV 7000 BUC 4435771 01 1234567 19/10/2001 700
110 1000 CV 7000 BUC 4435771 01 1234567 11/11/2002 800
115 1010 LO 3300 BV 421973 058 2967812 12/11/2002 300
120 1020 TD 3400 CJ 377216 056 4356916 15/10/2001 600
200 1001 SM 7000 BUC 2116891 01 1224561 23/07/2001 500
Not. Simbolul # asociat atributelor NRC#,CODF# specific faptul c aceste atribute formez cheia
primar.

Fig. 5.23. Dependene tranzitive
Capitolul 5
108

- Inserare. Nu putem insera un nou tuplu referitor la o localitate particular care are un
cod, o denumire i un prefix telefonic (de exemplu: CODL = 0465, DENLOC =
DOMNETI i PREFIX = 048), dac nu avem cel puin un contract cu un furnizor din
acea localitate, deci dac nu se d i valoarea cheii primare a relaiei (nu se accept
atribute din cheia primar cu valori nule-restricie de integritate). n mod analog, nu
putem insera un nou tuplu referitor la un furnizor particular pn nu avem ncheiat cu
acesta cel puin un contract. Ori, este tiut c prezint interes s cunoatem
multitudinea furnizorilor poteniali din domeniul de care ne ocupm pentru a ncheia
cu acetia viitoare contracte;

- Redundana datelor. Precizm faptul c n activitatea curent sunt foarte frecvente
situaiile n care cu un furnizor se ncheie mai multe contracte, ceea ce nseamn c n
baza de date vor apare mai multe tupluri ce vor conine aceleai informaii referitoare
la acelai furnizor (datele din tabel ncadrate prin linie ntrerupt), deci redundan
foarte mare a datelor cu multiple consecine negative, cum ar fi:
- ncrcarea acelorai date de mai multe ori, cnd s-ar putea ncrca o singur dat;
- dac se schimb o informaie referitoare la un anumit furnizor, va trebui s se
actualizeze o multitudine de tupluri, cnd s-ar putea actualiza unul singur;
- o utilizare necorespunztoare a suportului de memorie extern prin duplicarea
informaiei consumndu-se spaiu de memorie suplimentar;
- timp de calculator necesar prelucrrii sporit datorit primelor dou aspecte
menionate etc.
Relaiile care menin dependene tranzitive nu sunt n forma normal trei (FN3).

Definiie: O relaie este n FN3 dac i numai dac ea este n FN2 i dac fiecare
atribut noncheie nu depinde n mod tranzitiv de cheia primar.
Conform definiiei FN3, relaia CONTRACTE din figura 5.21 nu este n FN3. Pentru a
o aduce n FN3 i a scpa astfel de anomaliile amintite anterior, relaia CONTRACTE din
figura 5.21 va fi descompus n trei subrelaii, cu denumirile CONTRACTE (tabela 5.2),
FURNIZORI (tabela 5.3) i LOCALITI (tabela 5.4).

Tabela 5.2. CONTRACTE n FN 3
NRC# CODF# DATAC VALC
100 1000 10/01/2001 100
101 1000 19/10/2001 700
110 1000 11/11/2002 800
115 1010 12/11/2002 300
120 1020 15/10/2001 600
200 1001 23/07/2001 500

Tabela 5.3. FURNIZORI n FN3
CODF# DENF CODL CONTB TELEFON
1000 CV 7000 1234567 4435771
1001 SM 7000 1224561 2116891
1010 LO 3300 2967812 421973
1020 TD 3400 4356916 377216


109
Tabela 5.4. LOCALITI n FN3
CODL# DENLOC PREFIX
3300 BV 058
3400 CJ 056
7000 BUC 01

Se observ c relaiile din tabelele 5.3 i 5.4 conin un numr mai redus de tupluri
datorit faptului c cele dou tabele au fost obinute prin proiecia tabelei 5.1 pe atributele
fiecrei relaii rezultate. n acest mod au fost eliminate dublurile de tupluri.
Deci cele dou relaii rezultate din CONTRACTE (tabela 5.1) au un numr diferit de
tupluri, totui nu s-au pierdut informaii, tabela iniial 5.1 putnd fi reconstituit prin operaia
de jonciune a tabelelor 5.2, 5.3, 5.4, de exemplu, printr-o fraz SQL de genul:

SELECT Contracte.NRC, Contracte.CODF, Furnizori.DENF, Furnizori.CODL,
Localitati.DENLOC, Furnizori.TELEFON, Localitati.PREFIX, Furnizori.CONTB,
Contracte.DATAC, Contracte.VALC
FROM (Furnizori INNER JOIN Contracte ON Furnizori.CODF = Contracte.CODF) INNER
JOIN Localitati ON Furnizori.CODL = Localitati.CODL;

din aplicarea creia rezult tabela original:

NRC CODF DENF CODL DENLO
C
TELEFO
N
PREFIX CONTB DATAC VAL
C 100 1000 CV 7000 BUC 4435771 01 1234567 10/01/2001 100
101 1000 CV 7000 BUC 4435771 01 1234567 19/10/2001 700
110 1000 CV 7000 BUC 4435771 01 1234567 11/11/2002 800
115 1010 LO 3300 BV 421973 058 2967812 12/11/2002 300
120 1020 TD 3400 CJ 377216 056 4356916 15/10/2001 600
200 1001 SM 7000 BUC 2116891 01 1224561 23/07/2001 500

Rezult c reducerea reprezint o descompunere fr pierderi. De remarcat faptul c
nivelul normalizri unei relaii date este o problem semantic i nu de valori ale datelor care
apar n acea relaie la un moment dat. Nu este posibil doar s priveti la valorile dintr-o
relaie, la un moment dat, i s spui dac relaia este sau nu n FN3, ci este necesar s cunoti
semnificaia datelor (dependenele funcionale dintre atributele relaiei). n figura 5.24 este
sintetizat logica normalizrii relaiilor pentru primele trei forme normale.

5.2.5. Forma normal BOYCE-CODD (BCNF)

Considerm urmtoarea relaie cu mai muli candidai cheie: CONTRACTE=<NRC,
FURNIZOR, MATERIAL>
Cheia relaiei este cuplul <NRC, FURNIZOR>; cu dependenele funcionale posibile
prezentate n figura 5.25. Relaia CONTRACTE poate fi considerat corect n FN3 deoarece
nici un atribut noncheie nu depinde de o parte a cheii sau de un atribut noncheie.

Capitolul 5
110

Fig. 5.24. Procesul de Normalizare prezentare sintetic

111

BOYCE i CODD sugereaz c o relaie cu doi sau mai muli candidai cheie poate fi
descompus n dou relaii fr pierderi i mai uor de manipulat.
n acest scop, definiia FN3 a fost nlocuit de BOYCE i CODD cu o alt definiie
mai puternic, ce le poart numele BCNF (Boyce-Codd Normal Form).
Definiia BCNF [Codd 74] este mai simpl dect FN3 deoarece nu face nici o referire la
FN1 i FN2 i nici la conceptele de dependen complet i dependen tranzitiv.
Vom numi determinant un atribut, posibil compus, de care alte atribute sunt complet
dependente funcional.
Definiie: O relaie R este n BCNF dac i numai dac fiecare determinant este un
candidat cheie.
Conform definiiei, relaia CONTRACTE poate fi considerat i n BCNF, deoarece
toate atributele ei formeaz o cheie i nu exist ali determinani. Prin extensie, relaia
CONTRACTE poate s conin redundane apreciabile, care, de obicei, conduc la probleme de
actualizare. Reducerea redundanei se poate face prin descompunerea relaiei CONTRACTE n
alte dou relaii.
Orice relaie poate fi descompus n subrelaii BCNF, fr s se piard informaii. Nu
vom da aceast demonstraie ci vom sugera condiiile n care o relaie poate fi descompus fr
pierdere n dou sau mai multe relaii. Fie r o relaie pe mulimea de atribute X i X
1
i X
2
dou
submulimi ale lui X astfel nct X=X
1
X
2
i X
0
=X
1
X
2
. Dac r satisface dependena
funcional X
0
X
1
sau dependena funcional X
0
X
2
atunci descompunerea lui r n X
1
i X
2

este o descompunere fr pierdere (lossless). Altfel spus o relaie r are o descompunere fr
pierdere n dou relaii dac mulimea de atribute comune celor dou relaii este o cheie pentru
cel puin una din relaiile n care s-a descompus. Pentru a fi corect descompunerea trebuie s
satisfac ntotdeauna dou proprieti:
- Descompunerea fr pierdere. Descompunerea fr pierdere asigur faptul c
informaia din relaia iniial poate fi reconstituit ca atare (fr false informaii n plus
sau fr pierdere de informaie) pe baza informaiilor din relaiile rezultate prin
descompunere. n acest caz prin interogarea relaiilor descompuse vom obine acelai
rezultat pe care l-am fi obinut prin interogarea relaiei originale.
- Conservarea dependenelor. Conservarea dependenelor asigur faptul c relaiile
descompuse au aceeai capacitate de reprezentare a restriciilor de integritate ca i relaia
original i astfel de a scoate n eviden actualizrile ilegale: fiecare tip de actualizare
permis (respectiv, nepermis sau ilegal) pe relaia original corespunde unei
actualizri admise (respectiv respinse) pe relaiile descompuse.
n acest context, pe exemplul nostru, relaia CONTRACTE va fi descompus n
urmtoarele dou relaii: R
1
= <NRC, MATERIAL> i R
2
= <MATERIAL, FURNIZOR>
Relaiile R
1
i R
2
sunt i ele n BCNF, iar din cadrul acestora dispare dependena
funcional (NRC, FURNIZOR) MATERIAL. Totodat, se apreciaz c cele dou relaii R
1

i R
2
sunt mai uor de manipulat, iar n urma procesului de descompunere nu s-au pierdut
informaii, relaia iniial CONTRACTE putnd fi reconstituit prin jonciunea lui R
1
cu R2 pe
atributul MATERIAL.

Fig. 5.25. Dependene funcional
Capitolul 5
112
5.2.6. Dependena multivaloare i forma normal patru

Pn acum, n procesul normalizrii, se poate constata c dependena funcional ne-a
condus la descompunerea relaiilor n primele trei forme normale i n forma normal
BOYCE-CODD. ns, se constat c nici aceasta nu este suficient pentru eliminarea
redundanei i anomaliilor de actualizare n anumite situaii.
Pentru exemplificare, s considerm urmtoarea relaie: MUNCITOR = <CNP,
MESERII, CRI> unde, MESERII reprezint meseriile pentru care are calificare un muncitor,
iar CRI reprezint crile citite de un muncitor. O extensie a relaiei MUNCITOR este redat
n tabela 5.5.

Tabela 5.5. MUNCITOR
CNP MESERII CRI
1000 STRUNGAR SHOGUN
1000 STRUNGAR BRUTA
1000 STRUNGAR VALURILE
2000 STRUNGAR PAIATA
2000 FREZOR PAIATA

Tabela 5.5 sugereaz posibilitatea unei redundane foarte mari a datelor n baza de date.
Totodat se poate deduce insuficiena noiunii de dependen funcional care nu permite
sesizarea independenei ce exist ntre atributele MESERII practicate i CRILE citite de o
anumit persoan.
Pentru aceasta, se generalizeaz noiunea de dependen funcional prin aceea de
dependen multivaloare (DMV).
Definiie: Fie relaia R(X) cu X={A
1
,A
2
,...,A
n
} i W i Y submulimi de atribute
A
1
,A
2
,...,A
n
. Se spune c WY (Y depinde multivaloare fa de W sau W determin o
multitudine de valori pentru Y) dac fiind date valorile lui W exist un ansamblu de valori Y
asociate i acest ansamblu este independent de alte atribute Z= X-W-Y ale relaiei R.
De subliniat faptul c dependena funcional este un caz particular de dependen
multivaloare, n care mulimea valorilor dependente cuprinde, n realitate, doar o singur
valoare, sau cu alte cuvinte, dependena multivaloare este o form generalizat a dependenei
funcionale.
Plecnd de la o relaie compus dintr-un ansamblu de atribute R, ca i n cazul
dependenei funcionale n mod similar i pentru DMV se pot defini cteva proprieti:
- Complementaritate. Fie X,Y i Z trei atribute astfel nct XYZ i
YZX. Atunci XY dac i numai dac XZ. Sau, o alt exprimare,
dac avem XY atunci avem i XRYX
- Reflexivitate. Dac YX atunci XY;
- Cretere (augmentare). Dac ZW i XY atunci ZWYZ;
- Tranzitivitate. Dac XY i YZ atunci XZY;
- Pseudotranzitivitatea. Dac XY i YWZ atunci XWZ i YW;
- Reuniune. Dac XY i XZ atunci XYZ;
- Descompunere. Dac XY i YZ atunci XZ, X Z, XZY;
- Replicare. Dac avem XY atunci avem i XY;
- Contopire. Dac XY i Z_Y i exist W_R i WY=C i WZ atunci XZ;
- Reuniune. Dac avem XY i XZ atunci avem i XYZ;
- Intersecie. Dac avem XY i XZ atunci avem i XYZ;

113
- Diferen. Dac avem XY i XZ atunci avem i XYZ i XZY.
Revenind la problema normalizrii, se observ c problema cu relaiile de tipul
MUNCITOR din tabela 5.5 este c ele menin dependene multivaloare care nu sunt i
dependene funcionale. Deci este de dorit nlocuirea relaiei MUNCITORI cu relaiile R
1
i R
2

(tabelele 5.6 i 5.7).

Tabela 5.6. R
1
n FN4 Tabela 5.7. R
2
n FN4

CNP MESERII
1000 STRUNGAR
2000 STRUNGAR
2000 FREZOR

i de aceast dat R. Fagin a demonstrat c o relaie R (A,B,C) poate fi descompus fr
pierderi n dou proiecii R
1
(A,B) i R
2
(A,C) dac i numai dac relaia R menine dependene
multivaloare AB i AC (sau mai condensat AB/C). Pe baza celor specificate, se
poate trece la definirea formei normale patru (FN4).
Definiie: O relaie R se afl n FN4 dac i numai dac oricnd relaia R menine o
dependen multivaloare, de tipul AB, atunci toate atributele lui R sunt i dependente
funcionale pe A (AX, pentru toate X din R).
Conform definitiei, relaia MUNCITOR (tabela 5.5) nu este n FN4 deoarece implic
dou DMW ntre atributele participante la cheie: CNPMESERII i CNPCRI.
Deci, a patra form normal cere ca relaiile n forma normal trei s nu conin dou
sau mai multe dependene multiple.
n contextul celor specificate, se poate afirma c relaiile R
1
i R
2
(tabelele 5.6 i 5.7)
sunt n FN4.
Datorit faptului c o dependen funcional este un caz particular de DMV, rezult c
o relaie n FN4 este n forma normal BCNF i deci n FN3. Acest lucru ne permite s afirmm
c FN4 se prezint ca o mbuntire a formei BCNF.
n scopul aprofundrii, sugerm i alte exemple de relaii n cadrul crora apare DMV,
precum i modul de trecere al acestora n FN4.
Exemplu: Considerm relaia:
MUNCITOR=<CNP, COPII, CALIFICARE>,
unde un muncitor poate avea una sau mai multe
calificri. Atributele COPII i CALIFICARE sunt
independente, iar DMV sunt evideniate prin
figura 5.26. Ceea ce nseamn c relaia
MUNCITOR se va descompune n dou relaii ce vor fi n FN4: R
1
= <CNP, COPII> , R
2
=
<CNP, CALIFICARE>
Exemplu: Presupunem existena mai multor rute de transporturi auto ce pot fi parcurse
de oricare tip de maina aflat n dotarea unui parc auto. Totodat, presupunem un ansamblu
de oferi care sunt instruii s conduc pe toate tipurile de maini i pe orice curs. n aceste
mprejurri s-ar putea defini o relaie care s rspund cerinei:
CURSA=<RUTA,TIP_AUTO,OFER>, unde TIP_AUTO i OFER sunt atribute
independente. Din cele precizate pot fi desprinse i urmtoarele DMV: RUTA
TIP_AUTO i RUTA OFER . Pentru trecerea relaiei CURSA n FN4, aceasta va fi
descompus n alte dou relaii conform celor dou DMV precizate.
CNP CRI
1000 SHOGUN
1000 BRUTA
1000 VALURILE
2000 PAIATA

Fig. 5.26. Dependene multivaloare
Capitolul 5
114
5.2.7. Dependena jonciune i forma normal cinci

Pn n prezent s-a presupus c singura operaie necesar sau disponibil n procesul de
descompunere este nlocuirea unei relaii prin dou din proieciile sale. Aceast presupunere s-a
realizat cu succes pn la forma normal patru. Apare ca o surpriz faptul c o relaie poate s
fie descompus n dou proiecii cu pierderi, dare se descompune fr pierderi n trei sau mai
multe din proieciile sale.
Deci, nici dependena multivaloare, care a condus la descompunerea relaiilor n FN4,
nu este suficient pentru eliminarea problemelor de redundan i anomalii.
Pentru exemplificare, considerm relaia: BENEFICIARI_MATERIALE_FURNIZORI
din tabela 5.8.

Tabela 5.8. BENEFICIARI_ MATERIALE_FURNIZORI
BENEFICIAR MATERIAL FURNIZOR
CESTRIN Cablu Coaxial COMPUTERLAND
CESTRIN Cablu Electric CSI
ASE Cablu Coaxial COMPUTERLAND
CESTRIN Cablu Coaxial CSI

Atributele relaiei formeaz o cheie concatenat i nu implic dependene funcionale
sau dependene multivaloare, deci este n forma normal patru. S considerm proieciile R
1
, R
2
,
i R
3
ale relaiei BENEFICIARI_MATERIALE_FURNIZORI din figura 5.27.

R
1
BENEFICIAR MATERIAL R
2
MATERIAL FURNIZOR
CESTRIN Cablu Coaxial Cablu Coaxial COMPUTERLAND
CESTRIN Cablu Electric Cablu Electric CSI
ASE Cablu Coaxial Cablu Coaxial CSI

R
3
BENEFICIAR FURNIZOR
CESTRIN COMPUTERLAND
CESTRIN CSI
ASE COMPUTERLAND
Fig 5.27. Proieciile relaiei BENEFICIARI_MATERIALE_FURNIZORI

Cutnd s facem jonciunea () relaiilor vom constata c:
BENEFICIARI_MATERIALE_FURNIZORI = R
1
MATERIAL
R
2
;
1
BENEFICIAR
R
3
;
2
FURNIZOR
R
3
;
Rezultatul jonciunii relaiilor R
1
i R
2
pe atributul MATERIAL apare ca n tabela 5.9.
Se observ c relaia din tabela 5.9 difer de relaia din tabela 5.8 prin apariia unui tuplu fals
<ASE, Cablu Coaxial, COMPUTERLAND>. Acest tuplu fals este nlturat de o a doua
jonciune a relaiei rezultate din prima jonciune (tabela 5.10) cu relaia R
3
pe atributele comune
FURNIZOR i BENEFICIAR. Deci, prin a doua jonciune este reconstituit relaia iniial din
tabela 5.8. Remarcm faptul c rezultatul primei jonciuni va fi acelai oricare ar fi perechea de
proiecii alese, adic aparitia unui tuplu fals.


115
i
X
n
i
R H =
=

1
Tabela 5.9. Jonciunea relaiilor R
1
cu R
2

BENEFICIAR MATERIAL FURNIZOR
CESTRIN Cablu Coaxial COMPUTERLAND
CESTRIN Cablu Electric CSI
CESTRIN Cablu Coaxial CSI
ASE Cablu Coaxial CSI
Fals
ASE Cablu Coaxial COMPUTERLAND

Observnd operaiile descrise se poate da urmtorul enun:
Enunul e
1
- dac perechea <CESTRIN,Cablu Coaxial> apare n relaia R
1
i perechea <Cablu
Coaxial,CSI> apare n relaia R
2
i perechea <CSI,CESTRIN> apare n R
3
atunci tuplul
<CESTRIN,Cablu Coaxial,CSI> apare n relaia BENFICIARI_MATERIALE_FURNIZORI.
n acest caz relaia iniial (tabela 5.8) va fi jonciune de R
1
MATERIAL
R
2
BENEFICIAR.FURNIZOR
R
3
.
Acest enun poate fi formalizat astfel:
Fie o relaie R cu atributele X, Y, Z i R
1
, R
2
, R
3
subrelaii obinute prin proieciile
relaiei R pe diferite atribute ale acesteia de forma: R
1
= x,y e (R); R
2
= y,z e (R) i R
3
= x,z e
(R). Dac perechile <x
1
,y
1
>eR
1
, <y
1
,z
1
>eR
2
i <x
1
, z
1
>eR
3
atunci tuplul <x
1
, y
1
, z
1
> apare
n R, iar relaia R va fi jonciune de R
1
, R
2
, R
3
, adic R=R
1
R
2
R
3

innd cont de enunul e
1
putem scrie urmtoarea restricie asupra relaiei
BENEFICIARI_MATERIALE_FURNIZORI (tabela 5.8):
Enunul e
2
- dac tuplurile:
<CESTRIN,Cablu Coaxial, COMPUTERLAND>,
<ASE, Cablu Coaxial, CSI> i
<CESTRIN, Cablu Electric, CSI>
apar n relaia BENEFICIARI_MATERIALE_FURNIZORI atunci apare sigur i tuplul
<CESTRIN, Cablu Coaxial, CSI>.
Aceast restricie este de tipul dependenei funcionale sau dependenei multivaloare.
Deoarece aceast restricie este satisfcut numai dac relaia n cauz este jonciunea anumitora
din proieciile sale, a fost numit dependen jonciune.
Definiie: Fie R o relaie cu schema = (A
1
,A
2
,...,A
n
) i X
1
,X
2
,...,X
n
submulimii de
{A
1
,A
2
,...,A
n
). Se spune c exist o dependen jonciune
(X
1
,X
2
,...,X
m
) dac R este jonciunea
proieciilor (H) lor pe X
1
,X
2
,...,X
m
, adic: R=HX
1
(R)HX
i
(R) ... X
m
(R), adic:

Pentru exemplul de mai sus se spune c relaia
BENEFICIARI_MATERIALE_FURNIZORI satisface dependena jonciune "
(R
1
, R
2
, R
3
)".
Teorema lui Fagin: "relaia R(A, B, C) poate fi descompus fr pierderi n R
1
(A,B) i
R
2
(B,C) dac i numai dac R menine dependenele multivaloare AB/C", este echivalent
cu enunul: "relaia R(A,B,C) menine dependena jonciune
(AB,AC), dac i numai dac R

menine dependenele multivaloare A B/C".
Din aceast echivalen rezult c dependena multivaloare este un caz particular al
dependenei jonciune, dup cum dependena funcional este un caz particular al dependenei
multivaloare.
Dependena jonciune este forma cea mai general de dependen, att timp ct atenia
noastr asupra dependenelor se ocup cu relaii descompuse prin operaii de proiecie i
recompuse prin operaii de jonciune.
Capitolul 5
116
Relaia BENEFICIARI_MATERIALE_FURNIZORI, cu toate c este n FN4, implic
totui o dependen jonciune. Ca urmare, ea prezint neajunsuri la actualizare. De exemplu,
dac se terge tuplul <CESTRIN,Cablu Coaxial,CSI> trebuie ters nc un tuplu, pentru c altfel
se contrazice enunul e
2
. Care alt tuplu trebuie ters ? Trebuie ales oricare din cele trei. Pentru a
scpa de aceste neajunsuri, relaia BENEFICIARI_MATERIALE_FURNIZORI trebuie
descompus n relaiile specificate de dependen jonciune, adic n subrelaiile R
1
, R
2
, i R
3

din figura 5.27. Procesul de descompunere se poate repeta pn cnd toate proieciile sunt n
forma normal cinci (FN5)
Definiie: O relaie R este n FN5 dac i numai dac fiecare dependen jonciune este
implicat printr-un candidat la cheie al relaiei.
De exemplu, fie o relaie R(A
1
, A
2
, A
3
, A
4
) avnd atributele A
1
i A
2
candidate la cheie.
Atunci este posibil descompunerea fr pierderi a acestei relaii n
(A
1
A
2
, A
1
A
3
, A
1
A
4
) i
de asemenea n
(A
1
A
2
, A
2
A
3
, A
2
A
4
) etc.
Forma normal cinci este o generalizare a formei normale patru, plecnd de la noiunea
de dependen jonciune i este considerat un punct final al descompunerii prin
proiecie-jonciune. Acest motiv l-a determinat pe Fagin s propun denumirea acesteia de
"forma normal de proiecie-jonciune".

5.2.8. Supranormalizarea. Rezultatul normalizrii

n activitatea de proiectare a structurii bazei de date, se recomand normalizarea
complet dac proiectantul se ateapt la adugiri, modificri i tergeri destul de frecvente.
Deci, atunci cnd datele au un caracter extrem de dinamic. n situaia n care datele au un
caracter relativ static i este de ateptat ca prelucrrile s se rezume n special la cereri de
consultare, atunci normalizarea se poate opri la BNCF.
Timpul de rspuns poate fi mbuntit dac relaiile sunt utilizate n FN1, n formate
care s maximizeze cererile pe o singur tabel i s reduc numrul de jonciuni ale mai multor
tabele.
n acest capitol s-a tratat succesiunea logic de normalizare complet a relaiilor. n
general se pornete de la o relaie universal ce descrie lumea real i o mulime de restricii
(dependene funcionale, dependene jonciune) pe atributele acestei relaii. Apoi se reduce
sistematic relaia la o colecie de relaii echivalente utiliznd restriciile ce ne ghideaz n
procesul de reducere.
Procesul de reducere poate fi rezumat astfel:
- Se aleg proieciile relaiei originale, aflat n forma normal unu, care elimin toate
dependenele funcionale pariale. Rezult relaii n forma normal doi;
- Se aleg proieciile relaiilor FN2 care elimin toate dependenele funcionale tranzitive.
Rezult relaii n forma normal trei;
- Se aleg proieciile relaiilor n FN3 care elimin dependenele funcionale n care
determinantul nu este candidat cheie. Rezult relaii n forma BCNF;
- Se aleg proieciile relaiilor BCNF care elimin dependenele multivaloare care nu sunt
i dependene funcionale. Rezult relaii n forma normal patru;
- Se aleg proieciile relaiilor n FN4 care elimin dependenele jonciune care nu sunt
implicate prin candidai cheie. Rezult relaii n forma normal cinci.
Obiectivul general al procesului de normalizare l constituie reducerea redundanei
prin acesta ajungndu-se la evitarea problemelor de actualizare.


117
5.2.9. Algoritmizarea primelor trei forme normale

n literatura de specialitate exist o serie de preocupri pentru a demonstra c problema
normalizrii poate fi rezolvat algoritmic .
Algoritmii elaborai pot fi implementai pe calculator i n final, produsul rezultat, poate
fi un instrument util pentru administratorul bazei de date, n faza de proiectare logic a bazei de
date, indiferent de tipul bazei de date. Produsul va specifica structurile de date (acele grupri de
cmpuri de date, coloane sau atribute) pentru care nu apar anomaliile de actualizare. n acest
context au fost elaborai ase algoritmi, grupai sub denumirea de algoritmii de sintez pentru
primele trei forme normale.
Algoritmii de sintez. Algoritmii de sintez pornesc de la o mulime de dependene
funcionale, F, dintre atributele unei mulimi de atribute i construiesc o schem a bazei de date
cu relaii n FN3. Aceast schem conine cel mai mic numr de relaii posibil. Majoritatea
acestor algoritmi sunt prezentai de ctre autori ntr-o form pur teoretic prin care au cutat s
demonstreze c problema normalizrii poate fi rezolvat algoritmic. n lucrarea de fa
algoritmii sunt prezeni ntr-o form posibil de implementat, aa cum au rezultat n urma
prelucrrilor efectuate de autori. Succesiunea algoritmilor, prezentat ntr-o form sintetic,
apare astfel:
- DF1. Eliminarea atributelor superflue. Fie f:{A
1
,...,A
n
}B i g:{A
1
,...,A
m
}B dou
dependene funcionale (DF), unde m<n. Atributele A
m+1
,...,A
n
sunt denumite atribute
superflue pentru f, deoarece atributele A
1
,...,A
m
sunt suficiente a-l determina pe B. Aa
dup cum s-a mai artat anterior, ntr-o astfel de situaie se spune c B este dependent
parial de A
1
,...,A
n
i dependent complet de A
1
,...,A
m
. Fie F mulimea de DF dat la
intrare. Se noteaz cu G mulimea de DF rezultat prin eliminarea atributelor superflue
din partea stng a fiecrei DF din F.
Acest pas este realizat de Algoritmul 1.
- DF2. Gsirea unei acoperiri neredundante. Fie G o mulime de dependene
funcionale. Se numete nchiderea lui G i se noteaz cu G
+
, mulimea tuturor
dependenelor funcionale (DF) care sunt obinute prin aplicarea succesiv a axiomelor
lui Armstrong (paragraful 5.2.3) asupra mulimii G. Mulimea H se numete acoperire
neredundant a lui G dac H
+
+G
+
i dac nici o submulime J a lui H nu are
proprietatea J
+
+G
+
. Deci, H este o acoperire minim a lui G. n acest context se gsete
o acoperire neredundant, H, a lui G, eliminnd DF redundante din G.
Acest pas este realizat de Algoritmul 2.
- DF3. Partiionarea. Se mparte mulimea H n grupuri de DF astfel nct toate DF
dintr-o grup s aib prile stngi identice.
- DF4. mbinarea cheilor echivalente. Pentru fiecare pereche de grupuri din H, dac
exist n H
+
o bijecie ntre prile lor stngi, atunci se unesc cele dou grupuri.
Construiete mulimea J. Acest pas este realizat de Algoritmul 3.
- DF5. Eliminarea dependenelor tranzitive. Gsete o mulime H'cH astfel nct
(H'+J)
+
=(H+J)
+
i nici un alt subset al lui H' nu are aceast proprietate. Adaug fiecare
DF din J n grupul corespunztor al lui H'. Acest pas este realizat de Algoritmul 4.
- DF6. Construirea relaiilor. Pentru fiecare grup al lui H' se construiete o relaie care
conine toate atributele din acel grup de DF. Acest pas este realizat de Algoritmul 5.
n continuare va fi prezentat fiecare algoritm.
Algoritmul 1. Elimin atributele superflue n urmtoarea succesiune:
- Introducerea dependenelor funcionale. Se introduce n sistem mulimea dependenelor
funcionale, F. DF sunt memorate astfel: atributele din partea stng n variabilele LS(I),
iar atributele din partea dreapt n variabilele RS(J).
- Aducerea la forma canonic redus. Dac exist dou sau mai multe DF n F, cu prile
Capitolul 5
118
stngi identice, se creaz o singur funcie: partea stng identic cu cea a DF
respective, iar partea dreapt rezult din reuniunea prilor drepte ale funciilor
respective (conform regulei DF5, paragraful 5.2.3). Se formeaz n acest fel mulimea
F'.
- Formarea funciei g. Pentru fiecare DF din F' se scoate succesiv cte un atribut din
partea stng. Dac funcia rezultat este n forma canonic (care are n partea dreapt
un singur atribut) atunci ea reprezint funcia g i merge la pasul 4; dac nu, se aduce la
forma canonic (conform regulii DF6). Fiecare din ele este fcut funcie g i pentru
fiecare este apelat pasul 4. La terminarea algoritmului se obine mulimea G.
- Verificarea enunului geG
+
. Se aplic algoritmul 6. Dac g aparine nchiderii G
+
,
atunci atributul respectiv este atribut superfluu pentru acea DF i este eliminat. Se reia
de la pasul 3. Dac funcia g a fost adus la forma canonic (rezultnd, deci, mai multe
funcii: g
1
,...,g
k
). Se aplic pasul 4 pentru fiecare funcie g
i
i concluziile se trag odat
pentru toate cele k funcii.
Algoritmul 2. Gsete o acoperire neredundant.
Presupune:
- Formarea funciei g. Se ia fiecare funcie din G, dac aceasta este n form canonic
reprezint funcia g, dac nu este adus la forma canonic (formndu-se k funcii:
g
1
,...,g
k
).
- Formarea mulimii G-{g}. G:= G-{g};
- Verificarea enunului ge(G-{g})
+
;
- Se aplic algoritmul 6.
Dac ge(G-{g})
+
atunci g este un DF redundant n G
+
i se reia de la pasul 1.
Dac ge(G-{g})
+
rezult c g nu este redundant n G. G:= G+{g}. Se reia de la pasul 1.
Dac G a fost adus la forma canonic, paii 2 i 3 se execut pentru fiecare funcie g
i
, iar
concluziile de la pasul 3 se trag pe baza celor k ecuaii ale pailor 2 i 3.
Rezultatul algoritmului este acoperirea neredundant, H, a lui G.
Algoritmul 3. mbin cheile echivalente.
- Iniializarea funciei J: J=C;
- Formarea funciei g. Pentru fiecare pereche de grupuri din H, H
i
i H
j
, cu prile stngi
X i respectiv Y, se formeaz funciile:
g
1
:XY
g
2
:YX
Pentru fiecare se execut pasul 3.
- Verificarea enunului geH
+
. Se aplic algoritmul 6.
- Formarea funciei J. Dac g
1
i g
2
sunt n H
+
(deci bijecia XYeH
+
) atunci: unesc H
i

i H
j
ntr-un singur grup (acest grup va avea dou chei:X i Y) J:=J+XY, YX.
Merge la pasul 5. Dac g
1
i g
2
nu sunt n H
+
se reia de la pasul 2.
- Verific dependenele pariale dintre X i Y. Pentru fiecare AeY, dac exist XeA n H
atunci elimin din H aceast dependen. Pentru fiecare BeX, dac exist YeB n H
atunci elimin din H aceast dependen.
Algoritmul 4. Verific dependenele tranzitive.
Presupune:
- Eliminarea dependenelor tranzitive. Pentru fiecare DF din H se ia fiecare din
combinaiile posibile dintre atributele din partea dreapt i verific dac exist
dependene funcionale ntre ele n H. Dac exist se elimin atributul/atributele (cele
din partea dreapt a dependenei formate) respectiv din aceea DF. Se reia de la pasul 1.
- Se adaug fiecare DF din J n grupul corespunztor din H. Rezult mulimea H;.
Algoritmul 5. Construirea relaiilor.

119
- Construirea relaiilor. Pentru fiecare grup al lui H' se construiete o relaie care conine
toate atributele din acest grup de DF.
- Desemnarea cheii/cheilor relaiilor. Cheia/cheile relaiilor sunt formate din atributele
din partea stng a DF din fiecare grup din H'.
Algoritmul 6. Verific dac g aparine nchiderii G
+
, adic geG
+
i presupune:
- Formarea mulimii M. Mulimea M este format din elementele 1,2,...,n, unde n
reprezint numrul de DF la intrarea n algoritmul 6.
ROOTS:=C
- Formarea mulimii TEMP. Mulimea TEMP este format din atributele din partea
stng a DF g.
- Verificarea mulimii TEMP. Dac TEMP=0 atunci geG
+
. Se termin algoritmul. Dac
TEMP # 0 se continu de la pasul 4.
- Construirea mulimii ROOTS.
ROOTS:=ROOTS+TEMP;
TEMP:=C;
- Construirea derivrilor. Pentru fiecare I din M se verific dac LS(I)eROOTS. Dac da
atunci TEMP:=TEMP+RS(I) i M:=M-I. Verificarea rdcinii a lui g aparine mulimii
TEMP, atunci funcia g aparine nchiderii. TEMP:=C; altfel algoritmul se continu de
la pasul 3.

5.3. Calitatea schemelor

Schema este o descriere, n termenii modelului bazei de date, a conceptelor i structurii
informaiilor unei aplicaii reale. Ea poate fi structura actual a bazei de date. O schem descrie
toate instanierile posibile ale bazei de date pentru o aplicaie real dat.
Cea mai important aciune a proiectrii bazei de date este proiectarea unei scheme de
calitate cu restriciile SGBD-ului disponibil i al modelului bazei de date. O schem de proast
calitate ofer posibilitatea corupiei datelor, modificrilor greoaie i incorecte, schimbrilor
greoaie la apariia/dispariia conceptelor lumii reale.
O schem este de cea mai bun calitate sau adecvat conceptual dac satisface
urmtoarele criterii:
- Schema descrie conceptele aplicaiei reale n mod natural:
- schema descrie obiectele, categoriile i asocierile aa cum sunt n lumea real;
- utilizatorii pot translata uor ideile n ambele direcii dintre conceptele schemei
i conceptele naturale ale aplicaiei.
- Schema este non-redundant sau are o redundan minim i controlat. Eliminarea
redundanei nu este fcut n scopul economiei de spaiu de stocare. Redundana din
schema nu este legat n mod direct de redundana n spaiul fizic. O schem logic non-
redundant poate fi implementat fizic cu redundan, asigurand creterea eficienei de
exploatare. Principiul care st la baza eliminrii redundanei este reprezentat de
eliminarea anomaliilor la inserare, tergere, modificare etc. Dac redundana este cerut
de convenienele utilizatorilor atunci este evident preferabil s se introduc n viziunile
acestora (subschemele bazei de date). Dac redundana nu poate fi eliminat complet
atunci ea trebuie controlat prin intermediul unor restricii de integritate sau rutine prin
care s se foreze actualizarea simultan a informaiilor, indiferent de locul unde este
cerut aceasta, n toate locurile n care exist.
- Schema nu trebuie s impun restricii de implementare adic trebuie s surprind orice
Capitolul 5
120
situaie probabil din lumea real (orice situaie probabil a aplicaiilor reale trebuie s fie
reprezentat complet n schema).
- Schema trebuie s includ maximul restriciilor de integritate. Restriciile care nu sunt
reprezentate n schema sunt greu de specificat, formulat i forat cu SGBD chiar dac
administratorul bazei de date definete standarde pentru efectuarea diverselor operaii.
Utilizatorul poate s nu foloseasc limbajul standard pentru actualizri simple lucru
acceptat de majoritatea SGBD;
- Schema trebuie s fie flexibil (dac apar schimbri n conceptele aplicaiilor reale atunci
n schem nu trebuiesc fcute schimbri drastice).
- Schema trebuie s fie conceptual-minimal, adic nu trebuie s conin concepte care
sunt irelevante n aplicaiile reale i limiteaz acumularea informaiilor care sunt
irelevante n aceast lume real.
O bun schem conceptual trebuie s posede urmtoarele proprieti pentru a i se putea
verifica calitatea:
- Corectitudine. O schem conceptual este corect atunci cnd utilizeaz corect
elementele constructive puse la dispoziie de modelul conceptual. C i n limbajele de
programare ne confruntm cu dou categorii de erori:
- sintactice, referitoare la utilizarea nepropice a elementelor constructive;
- semantice, referitoare la utilizarea corect a elementelor constructive dar
incorect din punctul de vedere a definiiei lor;
Corectitudinea schemei este verificat prin inspectare i comparare a conceptelor
prezente n schema cu cerinele i definiiile constructorilor modelului conceptual
utilizat.
- Completitudine. O schem conceptual este complet atunci cnd include concepte care
reprezint toate cerinele de date i permite execuia tuturor operaiilor incluse n
cerinele operaionale. Completitudinea schemei poate fi verificat prin controlarea
faptului c sunt reprezentate toate cerinele de date printr-un anumit concept prezent n
schem i c toate conceptele implicate n operaie pot fi atinse prin navigarea pe
schem.
- Relevan. O schem conceptual este relevant atunci cnd reprezint cerinele ntr-un
mod natural i uor de neles. n aceste condiii schema trebuie s fie, pe de o parte,
auto-explicabil, de exemplu, prin denumirile relevante date conceptelor iar, pe de alt
parte, s aib o estetic care s ajute relevana. Poate fi obinut o bun estetic a
schemei care o face i relevant respectnd cerinele:
- se aranjeaz reprezentarea grafic a schemei pe un caroiaj alegnd ca elemente
centrale pe acelea care au cele mai multe legturi cu celelalte;
- se vor utiliza numai linii orizontale i verticale i se vor realiza, pe ct posibil,
ct mai puine intersecii;
- se vor aranja entitile printe naintea celor fiu.
- Minimalitate. O schem este minimal atunci cnd toate specificaiile asociate datelor
sunt reprezentate numai odat n schem. O schem nu este minimal atunci cnd are
redundane.
Algebra relaional i calculul relaional

121

Capitolul 6
Algebra relaional i calculul
relaional

Partea manipulativ a modelului relaional const dintr-un set de operatori cunoscui sub
numele de algebra relaional mpreun cu un operator relaional de atribuire. Operatorul de
atribuire asigneaz o expresie arbitrar a algebrei unei alte relaii.
Algebra relaional a fost conceput de ctre E.F.CODD ca o colecie de operaii
formale asupra relaiilor. Fiecare operaie a algebrei relaionale are una sau mai multe relaii ca
operatori i produce ca rezultat o nou relaie. Aceast relaie poate fi la rndul su subiectul
unor viitoare operaii algebrice. Operanzii oricrei operaii pot fi sau relaii simple sau expresii
cu relaii. Codd a definit o mulime de astfel de operaii i a artat c acestea sunt complet
relaionale, n sensul c ele au cel puin puterea de regsire a calculului relaional.
Algebra relaional utilizeaz dou grupe de operatori: operatori tradiionali pe mulimi
i operatori relaionali speciali. Aceste grupe de operatori permit efectuarea operaiilor
corespunztoare lor.

6.1. Operaii tradiionale pe mulimi

n categoria operaiilor tradiionale pe mulimi includem reuniunea, intersecia,
diferena i produsul cartezian.
Aceste operaii au fost modificate pentru a opera mai degrab pe relaii dect pe
mulimi. Pentru operaiile enumerate, cu excepia produsului cartezian, cele dou relaii operand
trebuie s fie compatibile cu reuniunea, adic, s fie de acelai grad i atributele lor s aparin
acelorai domenii (nu este absolut necesar ca atributele corespunztoare s aib aceeai
denumire, acest lucru fiind cerut de platforma SQL utilizat). n situaiile reale operaiile
algebrei relaionale nu sunt utilizate singular. De cele mai multe ori ele implic o combinaie de
astfel de operaii. De exemplu, operaia de reuniune, necesit dou selecii (identice ca
structur a tabelelor rezultat) ntre care se efectueaz efectiv reuniunea.
SGBD-urile actuale care implementeaz limbajul standard de manipulare a bazelor de
date SQL, n una din versiunile sale, nu pun la dispoziie n mod obligatoriu comenzi distincte
pentru realizarea operaiilor relaionale, ci o singur fraz cu structura general:

SELECT ce_coloane_dorim_s_apar_n_rspuns
FROM din_ce_tabele
[WHERE ce_condiii_trebuiesc_ndeplinite_de_rnduri_pentru_a_fi_luate_n_considerare]

care poate fi exprimat astfel:
Capitolul 6
122
select r
1
.A
1
,...,r
1
.A
n
,r
2
.B
1
,...,r
2
.B
m
,E
1
(),E
2
(),E
n
(),...,r
n
.W
1
,...,W
n
.W
n

from r
1
,r
2
, ... ,r
n
[where <condiie jonciune> [<filtru>]][clauze opionale];

unde:
- prin A
i
, B
i
,,W
i
am desemnat atribute din schemele de relaie corespondente r
i
;
- prin E
i
() am desemnat expresii definite pe mai multe coloane din aceste relaii sau orice alte
expresii coninnd referiri la funcii definite de SGBD sau utilizator, constante, expresii
aritmetice sau logice etc;
- prin construciile de forma r
i
.A
i
am specificat faptul c atributul A
i
este unul din atributele
din schema de relaie a relaiei r
i
.

Reuniunea a dou relaii r
1
(X) i r
2
(X), cu aceeai schem de definire X, reprezint
mulimea tuturor rndurilor (tuplurilor) t aparinnd lui r
1
sau lui r
2
sau ambelor. Rezultatul
reuniunii este o nou relaie r
3
, cu r
3
(X)=r
1
(X) r
2
(X).

Sub form grafic reuniunea poate fi sugerat ca n una din figurile 6.1. a) sau b). n
figura 6.1. b) relaia rezultat r
3
este reprezentat grafic ca partea din relaiile de origine r
1
i r
2

care au aceeai schem de definire.
Pentru exemplificare considerm relaiile R
1
i R
2
cu schemele de definire
{ } C B A Y X , , = = cu
|
|
.
|
\
|
=
1 2 1
1 1 1
1
c b a
c b a
r , ( ) 1 2 2
2
c b a r = . Aplicnd operatorul de reuniune a
celor dou relaii va rezulta o nou relaie r
3
cu aceeai schem de definire Z= {A, B, C} cu
|
|
|
.
|
\
|
=
1 2 2
1 2 1
1 1 1
3
c b a
c b a
c b a
r ceea ce poate fi exprimat n SQL astfel:

SELECT r
1
.* FROM r
1
UNION
SELECT r
2
.* FROM r
2

unde prin * s-au desemnat toate atributele schemei de definire a relaiei specificate.

Exemplu: Reuniunea datelor din balana curent (Balanta) cu datele aferente balanelor
arhivate n vederea analizei evoluiei conturilor:

Select Balanta.* From Balanta
UNION
Select Istoric_Balante.* From Istoric_Balante;

a) b)
Fig. 6.1. Reuniunea relaiilor

123

Prin construcia Balanta.* am desemnat toate coloanele din tabela balana Balanta.
nefiind altceva dect specificaia prin care se spune de ce tabel aparin coloanele respective.
Exemplu: Reuniunea datelor din jurnalul curent cu cele din jurnalul arhivat n vederea
vizualizrii fiei unui cont (n cerere nu se specific acum filtrul de selecie):

Select Jurnal.* From Jurnal
Union
Select Istoric_Jurnal.* From Istoric_Jurnal;

Intersecia relaiilor r
1
(X) i r
2
(X) este mulimea tuturor rndurilor (tuplurilor) ce
aparin att lui r
1
ct i lui r
2
.

Acest tip de operaie permite gruparea ntr-o alt relaie r
3
a tuturor elementelor comune
celor dou relaii r
1
i r
2
, ceea ce grafic este sugerat n figura 6.2 a) sau b).

Fie
|
|
|
.
|
\
|
=
1 2 2
1 2 1
1 1 1
1
c b a
c b a
c b a
r i ( ) 1 2 2
2
c b a r = , intersecia relaiilor r
1
cu r
2
apare astfel:
r
3
=r
1
r
2
adic ( ) 1 2 2
3
c b a r =

a) b)
Fig. 6.2. Intersecia relaiilor

Fig. 6.3. Exemplu de Subschema
Capitolul 6
124
Exemplu: Lista drumurilor internaionale care se regsesc descrise n drumuri naionale
conform definiiei din subschema bazei de date din figura 6.3. poate fi obinut cu fraza:
SELECT r1.dr, r1.drum, r1.kmi, r1.mi, r1.kms, r1.ms FROM drumint r1
INTERSECT
SELECT r2.dr, r2.drum, r2.kmi, r2.mi, r2.kms, r2.ms FROM drumnat r2;

Diferena dintre dou relaii r
1
i r
2
cu aceeai schem de definire X
1
=X
2
, reprezint
mulimea tuturor rndurilor (tuplurilor) ce aparin lui r
1
, dar nu aparin lui r
2
. Relaia rezultat
va avea aceeai schem de definire X
3
=X
1
=X
2
.

Reprezentarea grafic a diferenei poate fi sugerat ca n figura 6.4 a) sau b).
Fie
|
|
|
.
|
\
|
=
1 2 2
1 2 1
1 1 1
1
c b a
c b a
c b a
r i ( ) 1 2 2
2
c b a r = , diferena dintre r
1
i r
2
este:
|
|
.
|
\
|
=
1 2 1
1 1 1
3
c b a
c b a
r

Exemplu: Pentru subschema din figura 6.3 lista poriunilor de drum care nu au drenuri:

SELECT i.dr, i.drum, i.km, i.mi, i.kms, i.ms FROM drumuri I
MINUS
SELECT d.dr, d.drum, d.km, d.mi, d.kms, d.ms FROM drenuri d

Aa cum am enunat n paragrafele anterioare operatorii de reuniune, intersecie i
diferen nu pot fi aplicai dect asupra relaiilor compatibile cu reuniunea, adic tabele cu
acelai numr de atribute, cu atributele corespondente definite pe aceleai domenii, denumite la
fel i date n aceeai ordine. Dac atributele ndeplinesc celelalte condiii exceptnd ordinea (se
afl n poziii diferite) acest caz poate fi rezolvat simplu prin specificarea lor n frazele SQL n
aceeai ordine.
n cazul n care atributele corespondente au denumiri diferite dar ndeplinesc celelalte
criterii compatibilizarea lor cu reuniunea poate fi realizat precednd operaia respectiv cu o
operaie de redenumire a lor. De exemplu dac dorim s vedem prin ce conturi s-au consemnat
operaiunile firmei n luna curent ar trebui s utilizm relaia Jurnal_Curent i s efectum o
reuniune a coloanelor ContDB i ContCR. Pentru a rezolva aceast cerere vom utiliza un
operator de redenumire (introdus n SQL prin clauza AS) a crui aplicare va precede realizarea
efectiv a operaiei de reuniune, astfel:

Select Distinct ContDB AS Simbol From Jurnal_Curent
UNION

a) b)
Fig. 6.4. Diferena relaiilor

125
Select Distinct ContCR AS Simbol From Jurnal_Curent;

Operatorul de redenumire, pe care l vom nota cu , poate fi definit astfel:
Fie r(X) o relaie definit pe mulimea de atribute X i Y o alt mulime de atribute cu aceeai
cardinalitate cu X. Fie A
1
,A
2
,...,A
k
o ordonare a atributelor din X i B
1
,B
2
,...,B
k
o ordonare a
atributelor din Y care asigur faptul c A
i
i B
i
(i=1,2,,k) sunt definite pe acelai domeniu. n
aceste condiii redenumirea, notat

prin

conine un tuplu t' pentru fiecare tuplu t din r, definit astfel: t' este un tuplu din Y i t'[B
i
]= t [A
i
]
pentru i=1,2,,k. Aceast definiie confirm faptul c schimbrile care au loc sunt schimbri
ale denumirii atributelor, valorile acestora rmnnd nealterate i asociindu-se noilor atribute.

Exemplu: Dorim s reprezentm relaiile paterne i materne ale unui arbore genealogic
prin relaiile:

Fig. 6.5. Relaiile Patern i Matern

Dac dorim s obinem o relaie care conine prinii i copii acesta ar fi o reuniune a
celor dou relaii definite anterior i instinctiv am avea pentru ea coloanele (Printe,Copil).
Coloana Printe este denumit n una din relaii Tat iar n cealalt Mam fcnd astfel
imposibil reuniunea prin faptul c nu au acelai nume. Aplicarea operatorului de redenumire
va face posibil reuniunea lor conform modului ilustrat n figura 6.5. Aceast operaie poate fi
descris n SQL astfel:

Select Tat As Printe, Patern.Copil From Patern
Union
Select Mam As Printe, Matern.Copil From Matern

Produsul cartezian a dou tabele (relaii) r
1
i r
2
reprezint mulimea rndurilor
(tuplurilor) t, astfel nct un rnd (tuplu) t este concatenarea unui rnd (tuplu) per
1
cu un rnd
(tuplu) qer
2
.

S considerm relaiile r
1
cu schema de definire X = {A} i r
2
cu schema de definire Y =
{B}. Se poate obine o nou relaie r
3
ca produs al celor dou, cu condiia ca: XY = . Astfel
relaia r
3
= r
1
x r
2
= {(a
i
, b
i
) | a
i
e r
1
i b
i
e r
2
} cu schema Z dat de reuniunea schemelor de
relaie r
1
i r
2
, adic Z=XY. n exemplul din figura 6.6 b) elementele relaiei rezultat sunt
mulimea perechilor [(a,b), (x,y,z)], iar schema de definire pentru r
3
va fi dat de reuniune
schemelor relaiilor r
1
i r
2
, adic Z={A, B}.

Patern
Tat Copil
Adam Cain
Adam Abel
Abraham Isac
Abraham Ismael
Matern
Mam Copil
Eva Cain
Eva Set
Sara Isac
Hagar Ismael
) (
2 1 ,..., ,
,..., , A
2 1
r
k
k
B B B
A A q
Capitolul 6
126

Reprezentarea grafic a produsului cartezian a dou relaii r
1
i r
2
este sugerat n figura
6.6 a) sau b).

n general, aceast operaie se utilizeaz destul de rar singular. Ea este o
operaie de pregtire a datelor n vederea realizrii operaiilor speciale ale algebrei relaionale.
Utilizarea sa singular este uzual n cazuri similare urmtoarelor exemple.

Exemplu: Presupunnd dou relaii cu denumirile de MATERIALE i FURNIZORI,
avnd schemele de definire:
M = {CODM, DEMAT, UM, PRE-LIVR} i F = {CODF, DENFURNIZOR, LOCALITATEA}

Asociind cteva valori atributelor celor dou relaii se va ajunge la forma tabelar a
acestora:
Tabela 6.2. MATERIALE
CODM DENMAT UM PRET-LIVR
1111 CABLU COAXIAL Ml 10
1112 CABLU ELECTRIC Ml 15

Printe Copil
Adam Cain
Adam Abel
Abraham Isac
Abraham Ismael
Eva Cain
Eva Set
Sara Isac
Hagar Ismael
Fig. 6.5. Utilizarea operatorului de
redenumire

(
(
(
(
(
(
(
(
(
(
(
z b
y b
x b
z a
y a
x a
z
y
x
b
a

b)

a)
Fig. 6.6. Produsul cartezian al
relaiilor
PRODUCT
R
1

R
2

x
R
3

) ( ) ( Matern Patern
Mam te in Par Tat te in Par
q q

127
Tabela 6.3. FURNIZORI
CODF DENFURNIZOR LOCALITATEA
100 COMPUTERLAND BUCURESTI
101 LASER CSI CONSTANTA

Se observ c MF = , ceea ce nseamn c are sens efectuarea produsului dintre cele
dou relaii, obinndu-se o nou relaie cu denumirea MATERIALE-FURNIZORI (tabela 6.4)

Tabela 6.4. MATERIALE-FURNIZORI
CODM DENMAT UM PRET-
LIVR
CODF DENFURNIZOR LOCALITATEA
1111 CABLU
COAXIAL
Ml 10 100 COMPUTERLAND BUCURESTI
1111 CABLU
COAXIAL
Ml 10 101 CSI CONSTANTA
1112 CABLU
ELECTRIC
Ml 15 100 COMPUTERLAND BUCURESTI
1112 CABLU
ELECTRIC
Ml 15 101 CSI CONSTANTA

Deci, semnificaia practic a produsului cartezian corespunde generrii unei tabele
(relaii) din dou tabele (relaii) prin combinarea fiecrui rnd (tuplu) din prima relaie cu
fiecare rnd (tuplu) al celei de a doua tabele (relaii).
Produsul cartezian al cele doua relaii se exprim n SQL astfel:

SELECT * FROM MATERIALE, FURNIZORI;

Exemplu: O fabric productoare de automobile produce toate automobilele sale ntr-o
gam unitar de culori. Dac dorim s meninem o eviden a acestora sub forma :

AUTO1
Marca Tip-auto Cilindri Culoare
Dacia SuperNova Berlin 1400 Alb
Dacia SuperNova Berlin 1400 Rou
Dacia SuperNova Berlin 1400 Verde
Dacia 1310 Break 1300 Rou
Dacia 1310 Break 1300 Verde
Dacia 1310 Break 1300 Alb

atunci valorile atributelor Denumire-Auto, Tip-Auto, Cilindri se vor duplica de attea ori cte
culori avem. Pentru a evita aceast situaie n baza de date vor fi meninute dou tabele:

Capitolul 6
128
AUTO CULOARE
Marca Tip-auto Cilindri Culoare
Dacia SuperNova Berlin 1400 alb
Dacia 1310 Brek 1300 rou
verde

Obinerea unei liste cu toate tipurile de automobile i culorile n care se produc, poate fi
realizat prin produsul cartezian dintre: AUTO x CULOARE ceea ce permite obinerea relaiei
iniiale AUTO1 printr-o fraz de genul:

SELECT AUTO.*, CULOARE.* FROM AUTO, CULOARE;

6.2. Operaii relaionale speciale

n aceast categorie de operaii vom include selecia, proiecia, jonciunea (join) i
diviziunea.

Operatorul algebric de selecie produce o subrelaie r' (subset) "orizontal" a unei
relaii r date, supuse operaiei de selecie. Subrelaia obinut va conine multitudinea
rndurilor relaiei supuse seleciei care satisfac un predicat P specificat. Relaia rezultat va
avea aceeai schem de definire ca i relaia operand.

Fie o relaie r cu schema X, A un atribut aparinnd lui X, a un element al atributului A
i t multitudinea rndurilor (tuplurilor) ce satisfac o anumit condiie. Operaia de selecie poate
fi exprimat astfel: r' (X) = {ter | t[A] = a}.
Reprezentarea grafic a operaiei de selecie este redat n figura 6.7. Predicatul P poate
fi o expresie logic care poate combina condiii simple cu ajutorul conectivelor logice AND (.),
OR(v) i NOT().
Operaia de selecie poate fi notat astfel ) (r
F
o , unde F este funcia (expresia) care
descrie predicatul iar r este relaia. Mai precis, fiind dat o relaie r(X), o formul propoziional
(expresia predicatului) F pe X este o formul obinut combinnd condiii atomice de tipul AB
sau Ac cu ajutorul conectivelor . (I - And), v (SAU - Or) i (Nu Not), unde:
- este un operator de relaie (=, >, <, <=, >=,<>, Like, Between etc);
- A i B sunt atribute din X care sunt compatibile (adic comparaiile au sens i neles
pe valorile domeniilor lor);
- c este o constant compatibil cu domeniul lui A.

Fiind dat o formul F i un tuplu t, formula este evaluat la o valoare logic (boolean
sau de adevr) astfel:
- AB este evaluat la Adevrat pe ter(X) dac i numai dac t[A] este n relaia cu t[B]
(de exemplu A=B este adevrat pe t dac i numai dac t[A]=t[B]);
- Ac este evaluat la Adevrat pe t dac i numai dac t[A] este n relaia cu c;
- F
1
vF
2
, F
1
.F
2
, F
1
au un neles uzual.

129

Cu aceste precizri definiia seleciei este:
Selecia ) (r
F
o produce o relaie cu aceleai atribute ca r i care conine numai acele
tupluri din r pentru care F este evaluat la Adevrat.

n figura 6.7 b) se sugereaz faptul c din multitudinea rndurilor tabelei se extrag
numai acelea haurate. Numrul de tupluri din relaia rezultat (cardinalitatea tabelei rezultat)
este mai mic dect (sau cel mult egal cu) cel al relaiei operand.

Exemplu: Presupunem o relaie MATERIALE cu schema de definire :
X={CODM,DENMAT,UM,PU,STOC-EXISTENT,STOC-NORMAT} i valorile asociate
conform tabelei 6.5.

Tabela 6.5 MATERIALE
CODM DENMAT UM PU STOC EXISTENT STOC NORMAT
1111 CABLU COAXIAL Kg 10 10000 11000
1113 CABLU ELECTRIC Kg 15 15000 8000
1115 CONECTOR MAMA BUC 50 200 300
1116 CAPSE BUC 1500 12 11
1120 CONECTOR TATA BUC 100 80 60
.... ...............................

Presupunem c dorim s selectm toate materialele ale cror coduri sunt mai mici dect
1116 i au stocul existent mai mare dect stocul normat. n urma operaiei de selecie va rezulta
subrelaia redat n tabela 6.6.

Tabela 6.6. MATERIALE - SELECTATE
CODM DENMAT UM PU STOC EXISTENT STOC NORMAT
1111 CABLU COAXIAL Kg 10 10000 11000
1115 CONECTOR MAMA BUC 50 200 300

Exemplu: Se solicit listarea tuturor drumurilor judeene din judeul Arge (figura 6.3).
n acest caz tabela implicat, la nivel CESTRIN-AND, este DNJUD, iar condiia (predicatul) de

a) b)
Fig 6.7. Operaia de Selecie
Capitolul 6
130
selecie este JUD = "AG". Prin acest predicat vor fi selectate din tabel numai acele rnduri care
conin n coloana JUD valoarea AG ceea ce se exprim n SQL astfel:
SELECT * FROM DNJUD WHERE JUD='AG';

Se solicita listarea tuturor autostrzilor din judeul Arge (figura 6.13). Este implicat
tabela DNJUD, iar predicatul de selecie implic coloanele JUD (judeul) i DR (categorie
drum) astfel: JUD = "AG" i DR = "A " exprimat n SQL astfel:

SELECT * FROM DNJUD WHERE JUD='AG' AND DR='A ';

Se solicit extragerea din jurnal a tuturor operaiilor prin Casa n Lei. Este implicat
tabela Jurnal iar condiia de selecie este ca fie ContDb fie ContCr s fie egale cu 5311, ceea ce
se exprim n SQL prin:

Select * From Jurnal Where ContDb="5311" Or ContCr="5311";

Se solicit extragerea din balan a conturilor din clasa de cheltuieli (6). Va fi implicat
tabela Balanta iar condiia de selecie este dat de prezena, pe prima poziie din simbol, a
codului clasei (6) ceea ce poate fi exprimat n SQL ca:

Select * From Balanta Where Simbol Like "6*";

Proiecia unei relaii r cu schema X=(A
1
,A
2
,....,A
n
) pe atributele A
1
,A
2
,.....,A
m
(unde
m<n) produce o relaie r' cu schema X'=(A
1
,A
2
,...,A
m
), obinut prin selectarea atributelor
specificate i eliminarea tuplurilor duplicate.

Pentru operaia de proiecie sunt consacrate urmtoarele notaii:
H
Y
(r),
H
A1,A2,......Am

R[A
1
,A
2
,...A
m
]
PROJECT (r/A
1
,A
2
,........A
m
).

n figura 6.8 este redat reprezentarea grafic a operaiei de proiecie.
O definiie alternativ pentru proiecie este urmtoarea: fiind dat o relaie r(X) i o
mulime Y_X atunci proiecia lui r pe Y, indicat prin H
Y
(r), este mulimea tuplurilor din Y
obinute din tuplurile lui r considernd numai valorile pe atributele Y, adic H
Y
(r)={t[Y] | tur}.
Proiecia relaiei H
Y
(r) conine acelai numr de tupluri ca i r (are aceeai cardinalitate) dac i
numai dac Y este o supercheie pentru r.

a) b)
Fig. 6.8. Operaia de Proiecie

131
n figura 6.8 b) se sugereaz faptul c din multitudinea coloanelor tabelei se extrag
numai acelea haurate, proiecia producnd o descompunere vertical a tabelei de origine.
Exemplu: Considernd relaia MATERIALE-CONTRACTATE cu valori asociate
conform tabelei 6.7.

Tabela 6.7. MATERIALE-CONTRACTE
NRC# CODM# PU CANT-CONTR
100 1111 10 10000
101 1112 15 20000
110 1111 10 30000
115 1113 20 10000
120 1112 15 5000

Prin aplicarea operatorului de proiecie asupra atributului CODM# aparinnd relaiei
MATERIALE-CONTRACTE, deci H
CODM
(MATERIALE-CONTRACTATE) se obine:

CODM#
------
1111
1112
1113

Se observ c s-a obinut lista materialelor contractate, din care dublurile au fost
excluse.
Se cere indicativul drumului public i lungimea pentru drumurile care leag localitile
BUCURESTI-PITESTI (schema din figura 6.3). La rezolvarea acestei cereri se va utiliza tabela
DRUMURI din care vor fi selectate atributele (coloanele) DRUM i LUNGIME la care se
aplic condiia (predicatul) de selecie (INCEPUT="BUCURESTI" i Sfrit="PITESTI") sau
(INCEPUT="PITESTI" i Sfrit="BUCURESTI")
Partea marcat n condiie, permite definirea oricruia din sensurile unui DRUM.

SELECT DISTINCT DRUM, LUNGIME FROM DRUMURI WHERE
(UPPER(INCEPUT)='BUCURESTI' AND UPPER(Sfrit)='PITESTI') OR
(UPPER(SfritT)='BUCURESTI' AND UPPER(INCEPUT)='PITESTI')

Selecia din Jurnal a formulelor Contabile i sumelor aferente:

SELECT Jurnal.ContDB As [Cont Debitor], Jurnal.ContCR As [Cont Creditor],
Jurnal.Valoare FROM Jurnal;

Operaia de jonciune (JOIN) este una din cele mai importante operaii ale algebrei
relaionale. Acesta ne permite s stabilim conexiuni ntre datele coninute n diverse relaii, s
comparm valorile coninute n ele i astfel s utilizm caracteristicile fundamentale ale
modelului reieite din bazarea sa pe valori.
Operaia de jonciune este o derivaie a produsului cartezian (n anumite situaii este
redundant cu acesta). n general realizarea produsului cartezian este o operaie laborioas i
costisitoare. Operaia de jonciune presupune utilizarea unui calificator care s permit
compararea valorilor diferitelor (sau acelorai) atribute din dou relaii (sau dintr-o singur
relaie).
Capitolul 6
132
Operaia de jonciune are sens i i gsete o larg aplicabilitate n situaia n care
intersecia schemelor relaiilor este diferit de zero (adic au cel puin un atribut comun
aparinnd aceluiai domeniu, fr s fie obligatoriu ca denumirea acestora s fie identic), ceea
ce poate fi exprimat astfel:

r
1
r
2
pentru X
1
X
2
#.

Notaiile consacrate pentru operaia de jonciune sunt:
- r
1
r
2
;
- JOIN (r
1
,r
2
/);
- r
1
x r
2
[]
unde este un calificator multi-atribut care permite compararea atributelor relaiei r
1
cu
atributele relaiei r
2
. Operatorii de comparaie atribuii lui pot fi: <, =, >, s, > i .
A treia notaie sugereaz faptul c operaia de jonciune este un produs cartezian asupra
cruia se aplic o restricie . Reprezentarea grafic a operaiei de jonciune este similar celei a
produsului cartezian.
n general, jonciunea combin dou sau mai multe relaii, nu neaprat distincte, pe
toate atributele comune lor. Deci, se poate spune c operaia de jonciune a dou relaii r
1
i r
2
,
care au cte un atribut aparinnd aceluiai domeniu, produce o nou relaie r
3
ale crei rnduri
(tupluri) se formeaz prin concatenarea rndurilor (tuplurilor) celor dou relaii care satisfac
restricia asupra valorilor asociate atributelor ce se compar, urmat de eliminarea unuia dintre
atributele comune. Atributele pe care se face jonciune se numesc "atribute de jonciune".
n activitatea practic pot apare mai multe cazuri particulare de jonciune :

Jonciunea natural (natural join), notat cu simbolul , este jonciunea bazat pe
egalitatea atributelor de jonciune ale relaiilor implicate. Dac relaiile r
1
(X
1
) i r
2
(X
2
) au egale
atributele A
i
eX
1
i respectiv B
j
eX
2
atunci jonciunea natural este jonciunea dup calificarea
A
i
=B
j
iar rezultatul jonciunii este o relaie r
3
cu schema definit pe reuniunea mulimilor de
atribute ale operanzilor dar cu atributele comune luate o singur dat, adic pe mulimea
(X
1
X
2
)-(X
1
X
2
). Atributele comune n relaiile operand le vom nota cu X
1,2
i sunt
reprezentate de intersecia schemelor X
1
cu X
2
, adic X
1,2
=(X
1
X
2
) iar t
1
[X
1,2
]=t
2
[X
1,2
]. Cu
aceste precizri jonciunea natural r
1
r
2
a lui r
1
(X
1
) cu r
2
(X
2
) este o relaie definit pe
(X
1
X
2
) astfel:
r
1
r
2
={te(X
1
X
2
) | - t
1
er
1
i t
2
er
2
cu t[X
1
]=t
1
i t[X
2
]=t
2
} sau, mai concis
r
1
r
2
={te(X
1
X
2
) | t[X
1
]er
1
i t[X
2
]er
2
}
Dac pentru fiecare tuplu t
1
din X
1
exist un tuplu t n r
1
r
2
astfel nct t[X
1
]=t
1
i
similar pentru fiecare tuplu t
2
din X
2
exist un tuplu t n r
1
r
2
astfel nct t[X
2
]=t
2
vom spune c
jonciunea este jonciune complet (adic fiecare tuplu din operanzi contribuie la formarea acel
puin un tuplu n rezultat).
Dac exist tupluri n r
1
sau r
2
care nu contribuie la rezultatul r
1
r
2
vom spune c avem
tupluri balansate (dangling tuples) n relaiile joncionate. Numrul de tupluri ale jonciunii
r
1
r
2
va fi cuprins ntre 0 i produsul cardinalitilor |r
1
|x|r
2
| relaiilor opernd cu urmtoarele
precizri:
- dac jonciunea lui r
1
cu r
2
este complet atunci numrul su de tupluri va fi cel
puin egal cu Max(|r
1
|,|r
2
|);

133
- dac X
1
X
2
conine o cheie a lui r
2
jonciunea lui r
1
cu r
2
conine cel mult |r
1
|
tupluri;
- dac X
1
X
2
este o cheie primar a lui r
2
atunci vom avea o restricie referenial
ntre X
1
X
2
n r
1
i acest cheie a lui r
2
iar jonciunea conine exact |r
1
| tupluri.

Operatorul de jonciune natural este:
- comutativ, adic r
1
r
2
este ntotdeauna egal cu r
2
r
1
;
- distributiv, adic r
1
(r
2
r
3
)= (r
1
r
2
)r
3
.

Dac X
1
#X
2
atunci rezultatul jonciunii este definit ntotdeauna pe reuniunea X
1
X
2
i
conine ca tupluri produsul cartezian al r
1
cu r
2
, r
1
xr
2
. Acest produs cartezian poate produce
tupluri nesemnificative n rezultat. Pentru a elimina acest inconvenient a fost introdus un
operator de jonciune derivat, denumit tetha-join (jonciune teta), definit ca produs cartezian
urmat de selecie, astfel: r
1
F r
2
=oF (r
1
r
2
). Dac condiia F este o conjuncie de expresii
atomice formate cu operatorul de egalitate atunci operatorul de jonciune este denumit equi-join.

Exemplu: Din relaia descris n tabela 6.4 (MATERIALE) i relaia descris n tabela
6.6 (MATERIALE_CONTRACTATE) dorim s extragem cantitile contractate din fiecare
material astfel pentru a obine o tabel cu schema <codm, denmat, um, pu, cant_contr>

SELECT m.codm, m.denmat, m.um, m.pu, c.cant_contr
FROM materiale m, materiale_contractate c
WHERE m.codm=c.codm;

Considerm relaiile r
1
i r
2
cu schemele X
1
= {A,B,C} i respectiv X
2
={B,C,D}. n
urma operaiei de jonciune natural a lui r
1
cu r
2
va rezulta r
3
cu X
3
={A,B,C,D} redat n figura
6.9.

r
1

A B C

r
3
= r
1
r
2

a1 b1 c1
a2 b2 c2 A B C D
a3 b1 c2 a1 b1 c1 d1
a4 b2 c3 a1 b1 c1 d2
r
2
a2 b1 c1 d1
B C D a2 b1 c1 d2
b1 c1 d1 a4 b2 c3 d3
b1 c1 d2
b2 c3 d3
Fig. 6.9. Jonciunea natural a lui R1 cu R2 pe coloanele B i C

Exemplu: Se dorete listarea tuturor drumurilor naionale pe judee, din subschema
prezentat n figura 6.3, astfel:

DJDP ADRESA DRUM KMI MI KMS MS Lungime

Coloanele (atributele) DJDP i ADRESA apar n tabela (relaia) DJDP (Direcii
Judeene de Drumuri i Poduri) iar restul coloanelor (DRUM, KMI, MI, KMS, MS,
Capitolul 6
134
LUNGIME) apar n tabela DNJUD (Reea Drumuri Naionale pe Judee). Pentru a rspunde la
aceast cerere se va efectua o jonciune natural ntre tabelele DJDP i DNJUD pe atributul
JUD. Predicatul jonciunii este:
DJDP.JUD = DNJUD.JUD

n situaia n care operatorul de comparaie este > avem de a face cu "jonciune mai
mare dect...". n mod asemntor jonciunea mai poate avea i alte denumiri n funcie de
operatorul de comparaie luat n considerare.

Autojonciunea relaiei r dup atributul A
i
este jonciunea relaiei r cu ea nsi dup
predicatul A
i
=A
j
, ceea ce se poate exprima astfel: JOIN(r,r/A
i
=A
j
).

Exemplu: Se dorete listarea drumurilor pe judeele pe care le parcurg cu poriunile de
drum aferente pentru toate drumurile naionale (subschema din figura 6.3). Tronsoanele de
drum vor fi listate n ordinea natural de continuitate. Pentru rezolvarea acestei cereri va fi
implicat tabela DNJUD creia i se va aplica o autojonciune pe coloana DRUM. Deoarece
operaia de jonciune implic dou relaii (tabele) la intrare vom conveni faptul c tabelei
implicate DNJUD i se vor atribui dou supranume (alias): DNJUD alias R
1
i DNJUD alias R
2
.
Coloanele selectate vor fi: <JUD, DRUM, KMI, MI, KMS, MS>. n acest caz predicatul va arta
astfel: R
1
.DRUM = R
2
.DRUM mpreun cu relaia de ordine dintre rndurile (tuplurile)
rezultate: R
2
.KMI Ascendent, R
2
.MI Ascendent, R
2
.KMS Ascendent, R
2
.MS Ascendent.
Deoarece asocierea implicat n aceast cerere este definit recursiv (DNJUD la DNJUD prin
DRUM) va trebui s introducem n cerere i condiia ca rezultatul s fie format din tupluri
distincte (DISTINCT).

Exemplu: Dorim s obinem din relaia Angajat, lista cu Nume Angajat, Prenume
Angajat, Nume So(ie), Prenume So(ie) ceea ce implic o autojonciune a relaiei Angajat cu ea
nsi. Relaia Angajat este:

Angajat
CNP Sot Nume Prenume
150022301001
7
Ion Ion
152011040234
5
253101733758
1
Ionescu Claudiu
253101733758
1
152011040234
5
Ionescu Maria

iar cererea SQL care realizeaz autojonciunea poate arta astfel:
SELECT Angajat.Nume, Angajat.Prenume, Angajat_1.Nume, Angajat_1.Prenume
FROM Angajat INNER JOIN Angajat AS Angajat_1 ON Angajat.CNP = Angajat_1.Sot;
iar rezultatul este:

Angajat.Nume Angajat.Prenume Angajat_1.Nume Angajat_1.Prenume
Ionescu Claudiu Ionescu Maria
Ionescu Maria Ionescu Claudiu

Pentru relaia Angajat SGBD-ul utilizat a creat un alias (Angajati AS Angajati_1) pentru
a putea utiliza numele su la calificarea atributelor (de jonciune, de regul, dar nu are
importan dac se calific i alte tipuri).

Jonciune extern (outer join). n rezultatul tipurilor de jonciune prezentate pn acum
apreau numai rndurile care se obineau din jonciunea rndurilor celor dou relaii operand

135
(conform condiiei de jonciune). Rndurile dintr-o relaie operand fr corespondent n cealalt
relaie operand nu apreau n rezultatul jonciunii. Exist totui numeroase cazuri n care este
util s apar n rezultatul jonciunii i astfel de rnduri dintr-o relaie operand fr corespondent
de jonciune n cealalt relaie operand. Jonciunea care ofer aceast posibilitate a fost numit
jonciunea extern [DATE86]. Operatorul de jonciune extern are trei variante. Pentru definirea
acestor variante vom considera dou relaii r
1
i r
2
pe care se aplic operandul de jonciune.

Pentru exemplificare vom considera dou relaii astfel:

r
1
Nume Loc_de_Munc r
2
Loc_de_Munc ef
Anton Vnzri Producie Adam
Barbu Producie Achiziie Radu
Costea Achiziie

Cu aceste precizri operatorul de jonciune extern este definit astfel:
- r
1
LEFT r
2
care include n rezultat toate tuplurile din relaia r
1
i numai acele tupluri din r
2

care au corespondent n r
1
, conform modului ilustrat n relaia:

r
1
LEFT
r
2

Nume Loc_de_Munc ef
Anton Vnzri Null
Barbu Producie Adam
Costea Achiziie Adam

- r
1
RIGHT r
2
2
i numai acele tupluri din r
1

care au corespondent n r
2
, conform modului ilustrat n relaia:

r
1
RIGHT
r
2

Nume Loc_de_Munc ef
Barbu Producie Adam
Costea Producie Adam
Null Achiziie Radu
- r
1
FULL r
2
1
i r
2
care au corespondent i
tuplurile din ambele care nu au corespondent, conform modului ilustrat n relaia:

r
1
FULL
r
2

Nume Loc_de_Munc ef
Anton Vnzri Null
Barbu Producie Adam
Costea Producie Adam
Null Achiziie Radu

Exemplu: n rezultatul (obinut prin jonciune) care ofer date despre clienii i
produsele comandate de acetia se dorete s apar i date despre produsele fabricate dar care
nu au fost nc solicitate de nici un client. Produsul fabricat dar necomercializat nc nu are
corespondent n relaia beneficiari. Fie relaiile BENEFICIARI i PRODUSE din figura 6.10.
Capitolul 6
136

BENEFICIARI
COD DENUMIRE ADRESA COD-PRODUS
101 CESTRIN SOVEJA 115 40542
102 ASE CSIE DOROBANTI 40521

PRODUSE
COD-PRODUS DENP CARACTERISTICI
40521 Coprocesor 66 MHz
40542 486;DX2 66 Mhz; 4Mb
41736 Statie lucru IBM Compatibil

Fig. 6.10. Relaiile BENEFICIARI i PRODUSE

Rezultatul solicitat mai sus se obine prin jonciunea extern a celor dou relaii pe
atributul COD-PRODUS i arat astfel:

COD DENUMIRE ADRESA COD PRODUS DENP CARACTERISTICI

101 CESTRIN Soveja 115 40542 Coprocesor 66 MHz
102 ASE DOROBANI 40521 AT486;DX2 66 MHz; 4 Mb
41736 Staie lucru IBM compatibil

Se observ faptul c pentru produsul "Staie lucru" nu exist n rspuns valori n
coloanele corespunztoare relaiei BENEFICIARI.

Obinerea liniilor necesare pentru balana curent utilizeaz subschema bazei de date
ilustrat n figura 6.11 pentru care condiia de jonciune specific includerea n rezultat a tuturor
rndurilor din Balanta i numai a acelor rnduri din tabela Plan_de_Conturi pentru care valoarea
din coloana Simbol este egal cu o valoare Simbol din Balanta.

Fig. 6.11. Subschema pentru operaia de evaluare a
balanei

137

Fraza SQL care realizeaz jonciunea este:
SELECT DISTINCT Balanta.[An Balanta], Balanta.[Luna Balanta], Balanta.Simbol,
Plan_de_Conturi.Descriere, Plan_de_Conturi.DescrExt, Format(Balanta.[DbIan],
"#,#00.00") AS DbIan, Format(Balanta.[CrIan],"#,#00.00") AS CrIan,
Format(Balanta.[DbPrec],"#,#00.00") AS DbPrec, Format(Balanta.[CrPrec], "#,#00.00") AS
CrPrec, Balanta.DbLuna, Balanta.CrLuna, (Balanta.DbIan+ Balanta.DbPrec+
Balanta.DbLuna) AS DbTotal, (Balanta.CrIan+Balanta.CrPrec +Balanta.CrLuna) AS
CrTotal, (IIf((Balanta.DbIan+Balanta.DbPrec+ Balanta.DbLuna)>Balanta.CrIan+
Balanta.CrPrec+ Balanta.CrLuna), (Balanta.DbIan+Balanta.DbPrec+Balanta.DbLuna)-
(Balanta.CrIan+ Balanta.CrPrec+Balanta.CrLuna),0)) AS SoldDB, (IIf((Balanta.DbIan+
Balanta.DbPrec+Balanta.DbLuna)<(Balanta.CrIan+Balanta.CrPrec+ Balanta.CrLuna),
(Balanta.CrIan+Balanta.CrPrec+Balanta.CrLuna)-(Balanta.DbIan+Balanta.DbPrec+
Balanta.DbLuna),0)) AS SoldCR
FROM Plan_de_Conturi
RIGHT JOIN Balanta ON Plan_de_Conturi.Simbol = Balanta.Simbol
ORDER BY Balanta.Simbol;

Centralizarea balanei curente utilizeaz schema din figura 6.12
n aceast subschem tabelele TotalCR i TotalDB sunt cereri formulate ca n figura 6.13
iar Balanta i Plan_de_Conturi sunt tabele de baz ale bazei de date financiar-contabile.

Expresia frazei de calcul este:

Fig. 6.12. Subschema utilizat la calculul balanei
SELECT Balanta.Simbol, Sum(Jurnal.Valoare) AS CrLuna
FROM Balanta, Jurnal
WHERE (((Jurnal.ContCR) Like (Trim([Balanta].[Simbol]) & "*")))
GROUP BY Balanta.Simbol;

SELECT Balanta.Simbol, Sum(Jurnal.Valoare) AS CrLuna
FROM Balanta, Jurnal
WHERE (((Jurnal.ContCR) Like (Trim([Balanta].[Simbol]) & "*")))
GROUP BY Balanta.Simbol;

Fig. 6.13. Cererile TotalCR i TotalDB
Capitolul 6
138
SELECT DISTINCT Balanta.[An Balanta], Balanta.[Luna Balanta], Balanta.Simbol,
Plan_de_Conturi.Descriere, Plan_de_Conturi.DescrExt, Format(Balanta.DbIan, "#,#00.00")
AS DbIan, Format(Balanta.CrIan,"#,#00.00") AS CrIan, Format(Balanta.DbPrec,
"#,#00.00") AS DbPrec, Format(Balanta.CrPrec, "#,#00.00") AS CrPrec, TotalDB.DbLuna,
TotalCR.CrLuna, (Balanta.DbIan+ Balanta.DbPrec+ Balanta.DbLuna) AS DbTotal,
(Balanta.CrIan+ Balanta.CrPrec+ Balanta.CrLuna) AS CrTotal, (IIf((Balanta.DbIan+
Balanta.DbPrec+ Balanta.DbLuna)>
(Balanta.CrIan+Balanta.CrPrec+Balanta.CrLuna),(Balanta.DbIan+Balanta.DbPrec+Balan
ta.DbLuna)-(Balanta.CrIan+Balanta.CrPrec+ Balanta.CrLuna),0)) AS SoldDB,
(IIf((Balanta.DbIan+ Balanta.DbPrec+ Balanta.DbLuna)< (Balanta.CrIan+
Balanta.CrPrec+ Balanta.CrLuna),(Balanta.CrIan+Balanta.CrPrec+Balanta.CrLuna)-
(Balanta.DbIan+Balanta.DbPrec+ Balanta.DbLuna),0)) AS SoldCR
FROM ((Plan_de_Conturi RIGHT JOIN Balanta ON Plan_de_Conturi.Simbol =
Balanta.Simbol) LEFT JOIN TotalCR ON Balanta.Simbol = TotalCR.Simbol) LEFT JOIN
TotalDB ON Balanta.Simbol = TotalDB.Simbol
ORDER BY Balanta.Simbol;

Operaia de mprire realizeaz mprirea unei relaii demprit r
1
, de grad m+n, la o
relaie mpritor r
2
, de grad n i produce o relaie rezultat de grad m. Atributele m+i ale lui r
1
i
atributele i ale lui r
2
, pentru 1<=i<=n, trebuie s fie definite pe aceleai domenii. S considerm
primele m atribute ale lui r
1
ca un atribut compus X, i ultimele n ca un alt atribut compus Y.
Rezult c relaia r
1
poate fi gndit ca o mulime de perechi de valori <x,y>. Similar relaia r
2

poate fi gndit ca o mulime de valori <y>. Rezultatul mpririi lui r
1
prin r
2
l reprezint
mulimea valorilor <x> pentru care perechea <x,y> apare n r
1
pentru toate valorile <y> care apar
n r
2
. Atributele rezultatului au aceleai denumiri ca primele m atribute ale relaiei r
1
.

Notaiile consacrate pentru operaia de mprire sunt:
- r
1
r
2
;
- DIVISION (r
1
,r
2
)

n figura 6.14 a) i b) este redat reprezentarea grafic a operaiei de mprire. n plus
figura 14 b) ofer un exemplu de aplicare.

n figura 6.14 b) din relaia r
1
se ia fiecare valoare distinct, pe care o vom denumi q, a
primei coloane i se constituie mulimea de valori format din valorile asociate din cea de a doua
coloan. Dac aceast mulime format este egal sau include mulimea valorilor din relaia r
2

atunci valoarea q la care s-a asociat apare n rezultat. Operaia de mprire trebuie s respecte

a)
Fig. 6.14. Diviziunea relaiilor
DIVIDE a
r
3

a x x
a y y
a z r
2

b x
c y
r
1
b)
R
1

R
2

R
3


139
condiia ca produsul cartezian al relaiei rezultat r
3
cu relaia mpritor r
2
s produc numai
tupluri din relaia demprit r
1
, adic r
3
xr
2
_r
1
.

6.3. Construirea expresiilor n algebra relaional

Algebra relaional este un limbaj procedural bazat pe concepte algebrice care const
dintr-o colecie de operatori definii pe relaii i care produce ca rezultat relaii. Proceduralitatea
sa este dat de faptul c atunci cnd scriem expresii ale algebrei relaionale nu facem altceva
dect s dm o secven de operaii care vor genera rspunsul cererii noastre. O expresie general
n algebra relaional este construit din subexpresii. Dac E
1
i E
2
sunt expresii ale algebrei
relaionale atunci expresiile:

- E
1
E
2
; E
1
-E
2
; E
1
xE
2
;
- ) (
1
E
P
o , unde P este un predicat pe E
1
;
- H
S
(E
1
), unde S este o list constnd din unele atribute din E
1

sunt expresii ale algebrei relaionale i formeaz operaiile fundamentale ale algebrei
relaionale. Ele sunt suficiente pentru a exprima orice cerere a algebrei relaionale.

Pentru exemplificri considerm baza de date Personal cu schema:

Angajat(CNP, Nume, Vrsta, Salariu, Cod_Loc) i Loc_de_Munc(Cod, Denumire, ef)
cu extensiile relaiilor prezentate n figura 6.15.

Coloanelor Cod_Loc din Angajat i Cod din Loc_de_Munc li s-au dat denumiri diferite
pentru a nu mai fi necesar calificarea n exemplificri. n situaii reale este preferabil
utilizarea aceleiai denumiri pentru coloanele de jonciune.

Angajat
CNP Nume Vrsta Salariu Cod_Loc
148 Ion RADU 54 20 101
149 Nicu
STEFAN
53 20 101
150 Adi ADAM 52 35 102
151 Ion PREDA 51 40 101
250 Mara CUCU 52 30 103
253 Dana
PREDA
49 15 102
267 Lia
STEFAN
35 20 103
280 Mia BRAN 22 15 102

Loc_de_Munc
Cod Denumire Sef
101 Productie 150
102 Vnzri 251
103 Aprovizionar
e
151
Fig. 6.15. Extensia relaiilor bazei de date Personal
Capitolul 6
140
Exemple:
- intersecia relaiilor r
1
cu r
2
poate fi nlocuit cu operaii de diferen astfel:
r
1
r
2
= r
1
- (r
1
- r
2
);
- jonciunea cu predicat (theta-join) a relaiilor r
1
cu r
2
dup predicatul u poate fi nlocuit cu
o selecie, astfel: r
1
u
r
2
=o
u
(r
1
xr
2
);

- jonciunea natural a relaiilor r
1
(X
1
) i r
2
(X
2
), r
1
r
2
, este o relaie pe schema X
1
X
2
i este
proiecia pe X
1
X
2
a unei jonciuni cu predicat care necesit expresii de forma r
1
.A=r
2
.A
pentru fiecare atribut AeX
1
X
2
. Dac X
1
X
2
={A
1
,A
2
,...,A
n
} atunci :
) (
2 . . .... . . 1 2 1
2 1 1 2 1 1 2 1
r r r r
n n
A r A r A r A r X X = . =
H = ;

- diviziunea a dou relaii, r
1
(X
1
) i r
2
(X
2
), cu X
1
_X
2
este o relaie pe schema X
1
-X
2
. Un tuplu
t aparine relaiei r
1
r
2
dac pentru fiecare tuplu t
2
din r
2
exist un tuplu t
1
n r
1
care satisface
urmtoarele dou condiii: t
1
[X
2
]=t
2
[X
2
] i t
1
[X
1
-X
2
]=t[X
1
-X
2
].

Operaia de mprire poate fi exprimat n termenii celor cinci operaii fundamentale astfel:
) ) ) ( (( ) (
1 2 1 1 2 1
2 1 2 1 2 1
r r r r r r
X X X X X X
H H H =

.

6.4. Echivalena expresiilor n algebra relaional

Ca orice limbaj formal algebra relaional permite formularea expresiilor echivalente.
Vom nota echivalena prin . Vom defini echivalena referindu-ne la expresiile definite pe
schemele bazelor de date. Dou expresii pe o schem de baz de date, E
1
i E
2
, sunt echivalente,
adic E
1
R
E
2
dac E
1
(r)=E
2
(r) pentru fiecare instan r a relaiei R. Dou expresii pe o schem
de baz de date, E
1
i E
2
, sunt absolut echivalente, adic E
1
E
2
dac E
1
R
E
2
pentru fiecare
schem de relaie R.
Echivalena expresiilor n algebra relaional este extrem de important la optimizarea
cererilor exprimate n SQL prin aceea c ele sunt translatate n expresii ale algebrei relaionale,
expresii pentru care se evalueaz costul satisfacerii cererii (cost exprimat n termenii
dimensiunii rezultatelor intermediare i finale). Dac exist mai multe expresii diferite
echivalente cererii atunci se va alegea acea expresie care cost cel mai puin. Pentru a obine
expresiile echivalente se utilizeaz transformri echivalente, adic operaii prin care se
substituie o expresie echivalent cu o alta.
Forma general a frazei SQL:

Select A
1
,A
2
,...,A
n
From r
1
,r
2
,...,r
m
[Where P] n care:
- A
1
,A
2
,...,A
n
reprezint atributele care dorim s apar n rezultat;
- r
1
,r
2
,...,r
m
reprezint relaiile implicate;
- P este predicatul sau condiia pe care trebuie s o ndeplineasc tuplurile care vor
contribui la calculul rezultatului;

este echivalent cu urmtoarea expresie a algebrei relaionale:
)) ... ( (
2 1 ,...,
1
m P A A
r r r
n
H o

Dac clauza Where ... lipsete (posibilitate indicat prin [...]) atunci predicatul P este
considerat Adevrat.

141

n cele ce urmeaz vom prezenta cteva exemple de transformri echivalente:
- Atomizarea seleciilor: o selecie construit pe baza unui predicat conjunctiv poate fi
substituit cu o cascad de selecii: )) ( ( ) (
2 1 2 1
E E
F F F F
o o o
.
, unde E este orice
expresie. Conform modului de definire aceast transformare permite aplicarea
transformrilor subsecvente care opereaz pe selecii cu condiii atomice;

- Proiecii n cascad: o proiecie poate fi transformat ntr-o cascad de proiecii care
"elimin" atribute n diverse faze: )) ( ( ) ( E E
XY X X
H H H dac E este definit pe o
mulime de atribute n care sunt incluse atributele X i Y;

- Anticiparea seleciei cu respectarea jonciunii: ) ( ) (
2 1 2 1
E E E E
F F
o o = dac
expresia F refer numai atribute din expresia E
2
;

- Anticiparea proieciei cu respectarea jonciunii:

Fie expresiile E
1
i E
2
definite pe X
1
i respectiv, X
2
. Dac Y
2
cX
2
i Y
2
_X
1
X
2
(adic
atributele X
2
- Y
2
nu sunt implicate n jonciune) atunci are loc echivalena:
) ( ) (
2 1 2 1
2 2 1
E E E E
Y Y X
H H .

Combinnd aceast expresie cu proiecia n cascad obinem urmtoarea expresie
echivalent: )) ( ) ( ( ) (
2 1 2 1
2 1
E E E E
Y F Y Y F Y
H H H H . Vom desemna prin X
1
i X
2

atributele lui E
1
, respectiv, E
2
i cu J
1
i J
2
submulimea de atribute care apar n condiia F. n
aceste condiii vom defini pe Y
1
i Y
2
astfel:
Y
1
=(X
1
Y)J
1
Y
2
=(X
2
Y)J
2

Pe baza acestei echivalene putem s eliminm din fiecare relaie toate atributele care nu
apar n rezultatul final i nu sunt implicate n jonciune.

- Combinarea seleciei i produsului cartezian pentru a forma un tetha-join:
2 1 2 1
) ( E E E E
F F
o

- Distributivitatea seleciei fa de reuniune:
) ( ) ( ) (
2 1 2 1
E E E E
F F F
o o o

- Distributivitatea seleciei fa de diferen:
) ( ) ( ) (
2 1 2 1
E E E E
F F F
o o o

- Distributivitatea proieciei fa de reuniune:
) ( ) ( ) (
2 1 2 1
E E E E
X X X
H H H

Similar acestor transformri condiiile (predicatele) compuse pot fi transformate n
condiii atomice conform exemplelor urmtoare:

O selecie pe predicatul F
1
vF
2
pe relaia R este echivalent cu o reuniune de selecii pe F
1
i
respectiv F
2
pe relaia R: ) ( ) ( ) (
2 1 2 1
R R R
F F F F
o o o
v
;

Capitolul 6
142
Exemplu: Pe relaia Angajat cu extensia prezentat n figura 6.25 se dorete lista cu CNP,
Nume, Vrsta care au fie salariu mai mare de 25 milioane fie locul de munc 101. Acest cerere
poate fi exprimat n SQL ca:

- selecie cu expresie predicativ format cu conectiva Or

SELECT Angajat.CNP, Angajat.Nume, Angajat.Vrsta
FROM Angajat
WHERE (([Angajat]![Salariu]>20 Or [Angajat]![Cod_Loc]=101));

- ca reuniune de selecii

FROM Angajat
WHERE (([Angajat]![Salariu]>20))
UNION
FROM Angajat
WHERE (([Angajat]![Cod_Loc]=101));

ambele exprimri producnd acelai rezultat:

CNP Nume Vrsta
151 Ion PREDA 51
150 Adi ADAM 52
149 Nicu
STEFAN
53
148 Ion RADU 54
250 Mara CUCU 52

1
.F
2
pe relaia R este echivalent cu o intersecie de selecii pe F
1
i
respectiv F
2
pe relaia R: ) ( ) ( ) (
2 1 2 1
R R R
F F F F
o o o
.
;

1
.F
2
pe relaia R este echivalent cu o diferen de selecii pe F
1
i
respectiv F
2
pe relaia R: ) ( ) ( ) (
2 1 2 1
R R R
F F F F
o o o
.
.

Exemplu: Considerm schema bazei de date :

Angajat(CNP, Nume, Vrsta, Salariu, Cod_Loc) i Loc_de_Munc(Cod, Denumire, ef)

cu extensiile relaiilor din figura 6.15.
Dorim s obinem lista CNP, Nume, Vrsta cu angajaii care au salariul mai mare de 25
milioane. Acest cerere este formulat n termenii algebrei relaionale ca o proiecie pe CNP,
Nume, Vrsta din selecia din relaia Angajat dup predicatul Salariu>25, adic H
CNP,Nume,Vrsta

(o
Salariu>25
(Angajat)), exprimat n SQL astfel:

SELECT Angajat.CNP, Angajat.Nume, Angajat.Vrsta FROM Angajat
WHERE ((([Angajat]![Salariu])>25));

i produce ieirea:

143

CNP Nume Vrsta
151 Ion PREDA 51
150 Adi ADAM 52
250 Mara
CUCU
52

Exemplu : S se listeze numele angajailor i denumirea locului de munc cu angajaii
care au salariul mai mare de 25 milioane:
H
Nume,Denumire
(Loc_de_Munc
Cod_Loc=Cod
(o
Salariu>25
(Angajat)));

Cererea SQL poate fi formulat astfel:

SELECT Angajat.Nume, Loc_de_Munc.Denumire FROM Loc_de_Munc
INNER JOIN Angajat ON Loc_de_Munc.Cod = Angajat.Cod_Loc
WHERE ((([Angajat]![Salariu])>25));

i produce rezultatul:

Nume Denumire
Ion PREDA Productie
Adi ADAM Vnzri
Mara CUCU Aprovizionare

6.5. Calculul relaional

Termenul calcul relaional se refer la o familie de limbaje de interogare (cereri) bazate
pe calculul predicatelor de ordinul nti. Fa de algebra relaional care este un limbaj
procedural limbajele bazate pe calculul relaional sunt declarative adic specificarea cererii este
efectuat n termenii proprietilor rezultatului. Exist o multitudine de versiuni ale calculului
relaional dintre care vom prezenta, n cele ce urmeaz, calculul relaional orientat pe domeniu i
calculul relaional orientat pe tuplu cu declararea limitelor (intervalelor) variabilelor libere. n
cadrul calculului relaional simbolurile de predicate corespund relaiilor din baza de date.
Pentru a efectua o comparaie ntre calculul relaional i algebra relaional vom defini, n
cele ce urmeaz, noiunea de independen de domeniu i noiunea de echivalen.
O expresie a unui limbaj de cereri (interogare) este independent de domeniu dac
rezultatul su, pe orice instan corect a bazei de date, nu se schimb dac schimbm domeniile
pe baza crora este evaluat expresia. Un limbaj este independent de domeniu dac toate
expresiile sale sunt independente de domeniu. Cu aceste precizri algebra relaional este un
limbaj independent de domeniu n timp ce calculul relaional nu este.
Dou limbaje de cereri sunt echivalente atunci cnd pentru orice expresie n unul din ele
exist o expresie echivalent n cellalt i reciproc. n concordan cu acest definiie algebra
relaional i calculul relaional pe domeniu nu sunt echivalente deoarece prima este
independent de domeniu n timp ce calculul relaional este dependent de domeniu.

Capitolul 6
144
6.5.1. Calculul relaional orientat pe domeniu

Expresiile calculului relaional orientat pe domeniu au forma {A
1
:x
1
,...,A
k
:x
k
| f }, unde:
- A
1
,...,A
k
sunt atribute distincte care nu trebuie s apar n neaprat n schema bazei de
date pe care se definete interogarea (pot fi constante, apeluri de funcii etc.);
- x
1
,...,x
k
sunt variabile;
- f este o formul care respect urmtoarele reguli:
- este de una din urmtoarele forme atomice:
R(A
1
:x
1
,...,A
p
:x
p
), unde R(A
1
,...,A
p
) este o schem relaional i x
1
,...,x
p
sunt
variabile;
xuy sau xuc, cu x i y variabile iar c constant i u un operator de comparare (=, <,
<=, >, >=, <>).
- dac f
1
i f
2
atunci f
1
.f
2
, f
1
vf
2
i f
1
sunt formule;
- dac f este o formul i x o variabil atunci -x(f) i x(f) sunt formule (-: exist -
EXISTS i : oricare ar fi - ANY).

Lista de perechi A
1
:x
1
,...,A
k
:x
k
este denumit "list int" deoarece definete structura
rezultatului construit din relaia pe A
1
,...,A
k
care conine tupluri ale cror valori substituite pentru
x
1
,...,x
p
evalueaz formula la Adevrat.

Evaluarea formulei la Adevrat urmeaz regulile:
- formul atomic R(A
1
:x
1
,...,A
p
:x
p
) este evaluat la Adevrat pentru valorile x
1
,...,x
p

care formeaz un tuplu n R;
- formul atomic xuy sau xuc este evaluat la adevrat dac x este n relaia u cu y,
respectiv c;
- conectivele .,v i au nelesul general de operatori logici i se evalueaz n
conformitate cu acest neles;
- o formul construit cu cuantificatorii:
- -x(f) este Adevrat dac exist cel puin o valoare pentru x care o face
adevrat pe f;
- x(f) este Adevrat dac f este adevrat pentru orice valoare a lui x.

Exemplu: Considerm schema din figura 6.25 : Angajat(CNP, Nume, Vrsta, Salariu,
Cod_Loc) i Loc_de_Munc(Cod_Loc, Denumire, ef) i dorim s obinem lista cu angajaii
care au salariul mai mare de 25 milioane. Acest cerere este formulat n termenii algebrei
relaionale ca o selecie din relaia Angajat dup predicatul Salariu>25, adic o
Salariu>25
(Angajat).
Acest expresie poate fi formulat n termenii calculului relaional astfel:

{CNP:m, Nume:n, Vrsta:v, Salariu:s, Cod_Loc:l | Angajat(CNP:m, Nume:n, Vrsta:v,
Salariu:s, Cod_Loc:l) .s>25}

n acest exprimare condiia:
- Angajat(CNP:m, Nume:n, Vrsta:v, Salariu:s, Cod_Loc:l) specific faptul c valorile
m,n,v,s,l trebuie s fie tuplu n relaia Angajat;
- s>25 specific faptul c n rspuns vor fi incluse numai acele tupluri pentru care
valoarea variabilei s este mai mare ca 25.

Dac vom considera numai partea de calcul relaional n care expresiile sunt
independente de domeniu vom avea urmtoarele echivalene cu algebra relaional:

145
- pentru fiecare expresie a calculului relaional care este independent de domeniu
exist o expresie a algebrei relaionale echivalent acesteia;
- pentru fiecare expresie a algebrei relaionale exist o expresie a calculului relaional
echivalent acesteia.

SGBD-urile actuale implementeaz un limbaj uzual bazat n parte pe calculul relaional
orientat pe domeniu cunoscut sub numele de QBE (Query_by_Example). Acesta utilizeaz o
interfa grafic cu utilizatorul prin care acesta este eliberat de sarcina specificrii detaliilor.
Pentru cererile exprimate n QBE exist posibilitatea vizualizrii automate a expresiilor
echivalente exprimate n algebra relaional (sub form de fraze SQL).

6.5.2. Calculul relaional orientat pe tuplu cu declararea rangului
(intervalelor de variaie a) variabilelor libere

O expresie n calculul relaional orientat pe tuplu cu declararea rangului variabilelor
libere are forma general: {T | L | f }, unde
- L este lista rangului (intervalelor) care enumereaz variabilele libere ale formulei f cu
intervalul respectiv de variaie. L este o list de tipul x(R), cu x o variabil i R o
denumire de relaie; dac x(R) este n lista rangului atunci n momentul evalurii
expresiei valorile posibile ale lui x sunt exact tupluri din relaia R;
- T este lista int compus din elemente de tipul Y:x.Z (sau mai simplu, prin reducere,
de tip x.Z), unde x este variabil iar Y i Z sunt secvene de atribute (de lungime
egal); atributele din Z trebuie s apar n schema relaiei care determin rangul lui x.
n cazul n care rangul lui x este relaia pe atributele X atunci X:x.X poate fi abreviat
cu x.* i putem s-l scriem n expresii ca atare;
- f este o formul cu:
- atomi de tipul x.Auc sau x
1
.A
1
ux
2
.A
2
care compar, n concordan, valorile lui x
pe atributul A cu constanta c i valorile lui x
1
pe atributul A
1
cu valorile lui x
2
pe
atributul A
2
;
- conective de tip logic .,v i ;
- cuantificatori, care asociaz rangul variabilelor, respectiv:
-x(R)(f) care nseamn "exist un tuplu x n relaia R care satisface formula f";
x(R)(f) care nseamn "fiecare tuplu x din R satisface formula f".

Declarrile de ranguri n lista de ranguri i cuantificri au un rol important: la
introducerea unei variabile x o declaraie de rang R(x) specific faptul c x poate s ia valori
numai dintre tuplurile relaiei R cu care este asociat. Din acest motiv acest limbaj nu necesit
condiii atomice ca cele cerute de calculul relaional orientat pe domeniu.
Exemplu: Considerm schema bazei de date: Angajat(CNP, Nume, Vrsta, Salariu,
Cod_Loc) i Loc_de_Munc(Cod, Denumire, ef) cu extensiile relaiilor din figura 6.15. Lista
angajailor care au salariul mai mare de 25 milioane se exprim astfel:
Capitolul 6
146

Exemplu: Lista angajailor cu structura CNP, Nume, Vrsta pentru angajaii cu salariul
mai mare de 25 milioane se obine printr-o expresie de forma:
{a.( CNP, Nume, Vrsta) | a(Angajat) | a.Salariu>25 }

Exemplu: Lista cu numele angajailor care au salariul mai mare de 25 milioane i
denumirea locului de munc se obine printr-o definiie de forma:
{a.Nume, l.Denumire | a(Angajat), l(Loc_de_Munc) | a.Cod_Loc=l.Cod.a.Salariu>25 }

Dei exprimarea pare uoar dezavantajul calculului relaional orientat pe tuplu cu
declararea rangului nu permite exprimarea oricrei cereri (n particular nu permite, de exemplu,
exprimarea operatorului de reuniune) aa cum o permite algebra relaional (sau calculul
relaional orientat pe domeniu.
Implementarea practic a calculului orientat pe tuplu este efectuat n SGBD-urile
actuale n dou moduri:
- prin acces la cereri SQL din limbaje procedurale pentru prelucrri tipice n care prin SQL
se obine o relaie pe care se efectueaz prelucrrile dorite, la modul tuplu cu tuplu, prin
instruciunile procedurale ale limbajului gazd;
- prin definirea de cursori i a unor instruciuni, pe aceti cursori, care permit accesul i
prelucrarea tuplu cu tuplu (metod implementat, de exemplu, n Oracle prin PL/SQL).

{ a.* | a(Angajat) | a.Salariu>25}

Lista int format
din toate atributele
relaiei
Rangul este reprezentat
de toate tuplurile relaiei
Angajat
Formula de selecie a
tuplurilor
Baze de date orientate obiect

* La aceast problem au colaborat i drd. Sandu Daniela i Posdarie Elena

Capitolul 7
(BDOO)

7.1. Conceptul de BDOO

Pentru definirea unei BDOO vom pleca tot de la definirea unei baze de date la modul
general, i anume:
O baz de date orientat obiect este format dintr-una sau mai multe clase de
obiecte cu asocierile dintre acestea.
Ca i n alte tipuri de baze de date, o BDOO dispune de o schem i instane ale
acesteia.
Schema BDOO conine specificaiile fiecrei clase de obiecte ce pot fi stocate n baza
de date. Pentru fiecare clas C, aceasta include:
- tipul asociat clasei C. Acest tip determin structura fiecrui obiect al clasei C;
- semntura metodelor din cadrul clasei C, care precizeaz denumirea metodei,
tipul i ordinea argumentelor permise metodei i tipul rezultatului oferit de acea
metod;
- relaiile subclaselor care permit identificarea superclasei a lui C;
- restriciile de integritate i restriciile refereniale, sau mai mult afirmaii generale
care sunt similare constrngerilor din modelul bazelor de date relaionale.
O instan a unei BDOO este un set de obiecte pentru multitudinea claselor
specificate n cadrul schemei bazei de date.

7.2. Premisele BDOO

Utilizarea conceptului de obiect n informatic dateaz din jurul anilor 1960, cnd au
fost elaborate primele Limbaje de programare orientate obiect, dintre care amintim: Simula,
EIFFEL, SmallTalk, Ada, C, C++, Common LISP, CLOS, OPAL, O
2
C, O
2
SQL, O
2
API,
SQL++, ACTOR, Object Pascal etc.
De remarcat, faptul c aceste limbaje de programare nu i-au gsit o larg utilizare
pentru aplicaii ce lucreaz cu volume mari de date datorit faptului c nc nu existau
metode corespunztoare de organizare a datelor. O astfel de problem a fost rezolvat n
jurul anilor 1980 cnd au aprut primele sisteme de gestiune a bazelor de date orientate
obiect (SGBDOO) cum ar fi: ONTOS, ObjectStore, O
2
, GemStore, ORION, ITASCA,
Capitolul 7
148
Objectivity/DB, VERSANT, POET etc. Nici n astfel de mprejurri, abordarea obiectual a
sistemelor de gestiune a bazelor de date nu i-au gsit o utilizare extins pentru aplicaii
complexe sau pentru cele ce implicau volume mari de date. Acest lucru s-a datorat faptului
c nc nu existau Metode, tehnici i metodologii de analiz i proiectare orientate obiect a
sistemelor informatice. Acestea au aprut n jurul anilor 1990 i dintre ele enumerm:
- Object Oriented Design (OOD), elaborat de Grady Booch care este o
metodologie similar metodologiei OMT, dezvolt aceeai idee analiza i
proiectare iterativ insistnd asupra prii de proiectare [4,6,31];
- Object Oriented Analysis (OOA) elaborat de Peter Coad i Edward Yourdon;
- Object Oriented Structured Design (OOSD) elaborat de Wasserman;
- Object Oriented System Analysis (OOSA) este o metodologie de proiectare a
sistemelor n timp real propus de Sally Shaler i Steven Mellor. Autorii au
continuat s mbunteasc aceast metodologie, publicnd chiar i o lucrare
despre cum se pot utiliza notaiile UML n cadrul metodologiei Shaler/Mellor;
- Responsability Driven Design (RDD), aparinnd lui Wirfs - Brock, Wilkesson i
Wienner;
- Object Oriented Role Analysis, Synthesis and Structuring aparinnd lui Reens
Kaugh;
- Object Oriented Systems Analysis (OOSA) aparinnd lui Embley;
- Object Modeling Techinque (OMT) elaborat de James Rumbaugh, Michael
Blaha i alii. Metodologia a fost iniial utilizat de General Electric and
Development Center;
- Object Oriented Software Engineering (OOSE) conceput de Ivar Jacobson.
n plus, multe organizaii i-au dezvoltat propria metodologie intern, utiliznd
diagrame i tehnici din diverse surse. Exemple de astfel de metodologii sunt Catalyst creat
de Computer Sciences Corporation (CSC) i Worldwide Solution Design and Delivery
Method (WSDDM), creat de IBM. Aceste metodologii difer, dar n general combin
analiza fluxurilor, identificarea cerinelor, modelarea proceselor de afaceri i modelarea
obiectual utiliznd diverse notaii (OMT, Booch etc.) i uneori includ tehnici adiionale
specifice modelrii orientate obiect, cum ar fi fiele CRC sau cazurile de utilizare.
Toate aceste metodologii prezentau o serie de limite precum i multiple diferenieri
de simboluri, notaii sau tipuri de diagrame. Aceste aspecte generau dificulti n privina
nelegerii, prelurii i folosirii lor de diferite grupuri de utilizatori, n crearea de noi sisteme
sau n procesul de mentenan a sistemelor. Mare parte dintre aceste deosebiri au fost
nlturate n 1997 prin elaborarea unui standard cu privire la simboluri, notaii, tipuri de
diagrame, tipuri de modele etc., numit UML (Unified Modeling Language).
Majoritatea corporaiilor au adoptat UML ca notaii pentru propria lor metodologie.
Unii utilizeaz doar un subset al UML-ului pentru a modela ceea ce i intereseaz, de
exemplu, doar diagrama claselor sau doar cazurile de utilizare. Alii au preluat ntreg setul
UML, utiliznd inclusiv diagramele de stare i de activitate pentru a modela sisteme n timp
real i diagrama de implementare pentru a modela sisteme distribuite.
Dintre premisele ce au dus la abordarea obiectual, n general, a analizei i proiectrii
sistemelor informatice i n special, a bazelor de date orientate obiect, enumerm:
- limitele abordrii structurate n analiza i proiectarea sistemelor informatice
(bazele de date fcnd parte dintr-o disciplin mai larg i anume sisteme
informatice);
- limitele modelului relaional de organizare a datelor;
- schimbrile n ceea ce privete orientarea aplicaiilor ce puneau accent pe
stocarea datelor, ctre aplicaii care pun accent pe prelucrarea mai eficient a
datelor cu algoritmi mai performani;

- succesele dobndite de ctre sistemele expert sub aspectul stocrii cunotinelor;
- progresele dobndite n domeniul instrumentelor de tip CASE;
- multiplele avantaje oferite de limbajele de programare orientate obiect, dintre
care precizm: facilitile de refolosire a codului, modularitate crescut i
extensibilitate sporit;
- apariia unor noi tipuri de aplicaii, cu cerine i particulariti specifice, pentru
care sistemele de gestiune a bazelor de date relaionale (SGBDR) s-au dovedit
inadecvate. Dintre acestea enumerm: proiectarea asistat de calculator (CAD
Computer Aided Design), aplicaii din domeniul meteorologiei, sisteme
informaionale geografice (GIS Geographic Information Systems), ingineria
programrii asistate de calculator (CASE Computer Aided Software
Engineering), sisteme informaionale de birou (OIS Office Information
Systems), aplicaii multimedia n cinematografie i televiziune, extinderea
aplicaiilor informaticii n domeniul medicinii, cercetrii tiinifice etc. Toate
aceste tipuri de aplicaii presupun preluri, stocri, regsiri i prelucrri de
evenimente, tranziii, stri, imagine/poz, voce/sunet, culoare, animaie etc., care
la rndul lor presupun utilizarea i manipularea unor noi tipuri de date pe lng
cele tradiionale (primitive), dintre care amintim:
- tipuri de date abstracte (ADT
s
) definite de utilizator,
- tipuri structurate,
- tipuri de obiecte mari (LOB Large Object) cu cele dou variante numite
BLOB (Binary Large Object) i respectiv CLOB (Character Large Object).
Astfel de noi tipuri de date pot fi regsite i tratate n cadrul acestui capitol i chiar n
urmtoarele capitole.

7.3. Avantajele i dezavantajele BDOO

Ca orice alt mod de organizare a datelor i BDOO prezint avantaje i dezavantaje. n
cele ce urmeaz vom recurge la evidenierea celor dou aspecte:

Avantajele BDOO. ntr-o form sintetic, avantajele BDOO ar putea fi enunate
astfel:
- Ofer faciliti cu privire la extensibilitatea bazei de date. Extensibilitatea apare
ca un avantaj cheie a BDOO deoarece tipurile de date pot fi extinse folosind
proprietatea de motenire. Se pot aduga noi subtipuri fr a fi necesar
restructurarea poriunilor existente ale bazei de date. Aa dup cum s-a mai artat,
n acest mod activitatea de programare se transform ntr-o activitate de
programare doar a diferenelor, sporind productivitatea muncii. Se are n atenie
valorificarea proprietii de motenire prin definirea, sau prin generalizarea, de
superclase de obiecte cu includerea n aceasta a tot ceea ce este comun, iar apoi
partajarea acestora n subclase de obiecte n care vor fi precizate doar elementele
prin care se difereniaz fiecare subclas de celelalte subclase de obiecte. Efectele
benefice rezultate dintr-o astfel de abordare constau n reutilizarea codului,
reducerea redundanei datelor din baza de date, ntreinerea facil a bazei de date,
uurin n dezvoltarea i implementarea de noi aplicaii etc.

Capitolul 7
150
- Reflect mai bine realitile din mediul nconjurtor. Lumea real nu este
format dintr-o colecie de tabele, ci un model a lumii reale apare ca o ierarhie de
ansambluri concretizate n articole de prelucrat. Aici o parte e descompus n
prile ei constituente ca subpri, care la rndul lor sunt descompuse n alte
subpri mai mici. Astfel de structuri sunt greu de reprezentat i manipulat
utiliznd tabele. De fapt prin folosirea unui SQL standard, toate subprile unei
pri date nu pot fi determinate tipic cu o singur instruciune de cereri. n
contrast, o baz de date orientat obiect suport capacitatea obiectelor de a se
referi direct unele la altele ct i facilitatea de calcul a limbajelor orientate obiect
de a procesa obiecte.
Totodat, un model de ntreprindere ar trebui s fie un model ce descrie tipuri de
obiecte, de afaceri, subtipuri, comportarea lor, relaiile dintre obiecte, strile
obiectelor, evenimentele ce determin schimbrile de stri, reguli de afaceri etc.
Modelul ntreprinderii trebuie translatat direct n software care face ca
ntreprinderea s funcioneze. O astfel de situaie necesit baze de date care
stocheaz obiecte i fac metodele asociate s fie operative.

- BDOO permit obiectelor s se refere direct unele la altele pe baz de pointeri. O
astfel de adresare (referire) face BDOO mai rapide n a ajunge de la obiectul X la
Y dect bazele de date relaionale, care trebuie s foloseasc un operator de JOIN
pentru a realiza acest lucru. Chiar un JOIN optimizat e tipic mai ncet dect o
referire direct la obiect pe baz de pointeri.

- BDOO ofer performane sporite referitoare la clasterarea (cluster) fizic a
datelor. Majoritatea sistemelor de baze de date permit proiectantului s plaseze
structurile legate aproape una de alta pe suportul de memorie extern. Prin
clasterare se urmrete sporirea vitezei de rspuns la cererile utilizatorilor ce
implic operaia de jonciune a unor structuri de date. Se reduce astfel n mod
considerabil timpul de regsire pentru datele solicitate, prin reducerea numrului
de accese pentru citirea datelor de pe hard disc. Exemplu, pentru a da rspuns
facil la o cerere de aplicaie de forma: care sunt subprile componente ale unui
produs oarecare sau se cere s se listeze informaiile despre salariaii i
departamentele unei societi comerciale n care lucreaz acetia.
n astfel de situaii proiectanii recurg la definirea de clastere (Clusters). n
condiiile BDOO clasterarea fizic se realizeaz la un singur nivel, de unde
rezult i performanele sporite sub aspectul timpului de regsire. Logica de
clasterare se bazeaz pe clase i ierarhii de agregare. Obiectele care formeaz
grupe sunt stocate laolalt cu obiectele compozite i ntr-un sistem bine proiectat,
structurile de clasificare sunt folosite ca baz natural de clasterizare, pe cnd, n
condiiile BDR se impune un al doilea nivel de claster. Un prim nivel pentru a
grupa tuplurile reprezentnd obiectele individuale i un al doilea pentru grupurile
de tupluri reprezentnd obiectele referite.

- BDOO sporesc extinderea domeniilor de aplicabilitate prin posibilitatea folosirii
diverselor structuri de stocare i prelucrare a datelor. ntr-o baz de date
relaional, datele care nu pot fi exprimate n form tabelar sunt dificil de stocat
i accesat eficient. Ori, exist o multitudine de aplicaii care implic date
complexe, sunet, imagini, text neformatat etc. Modul de stocare pentru BDOO
este nelimitat, din moment ce sistemul este extensibil prin natura sa. BDOO pot

asigura diferite mecanisme de stocare pentru diferite tipuri de date. Drept urmare
ele s-au dovedit foarte eficiente att pentru aplicaii multimedia ct i CAD.

n general, se poate spune c BDOO ofer o mai bun performan atunci cnd avem
de a face cu obiecte complexe i relaii complexe, deoarece nu este nevoie s spargem
obiectele mari n tabele normalizate i apoi s le reasamblm n momentul execuiei
programelor de aplicaii.

Dezavantajele BDOO. n ciuda unor multiple avantaje pe care le ofer BDOO totui
acestea nc nu au reuit s se impun sub aspectul ponderii implementrii lor n diferite
domenii de aplicabilitate. Acest lucru se datoreaz unor dezavantaje ale lor, dintre care
enumerm:
- Lipsa unor standarde ale arhitecturii de SGBDOO, de modelare a datelor sau de
limbaje de integrare standard orientate obiect. Exist totui preocupri i chiar
anumite realizri de standardizare pe domeniile amintite, n mare parte aparinnd
grupului de administrare a bazelor de date orientate obiect (ODMG).
- SGBDOO nu ofer o gam larg de instrumente (TOOLS) utilizatorilor firmei
sau proiectanilor de dezvoltri i ntreineri de aplicaii, comparativ cu SGBDR.
- SGBDOO nu ofer suficient siguran n ceea ce privete rezolvarea
problemelor de acces concurent n condiiile lucrului cu volume mari de date.
- Nu sunt rezolvate n suficient msur problemele referitoare la asigurarea
integritii bazei de date sub aspectul refacerii acesteia n caz de incident.
- ncapsularea poate genera dificulti sub aspectul optimizrii integrrii bazei de
date. Felul n care sunt definite i stocate datele i metodele precum i limitele
Limbajelor de interogare orientate obiect pot influena n sens negativ
performanele de ordin fizic ale bazei de date. Acelai lucru poate s apar i n
situaia n care avem de a face cu anumite cerine informaionale care nu au fost
prestabilite. Cu alte cuvinte, apare ntrebarea: Cum pot fi cutate i regsite
anumite obiecte a cror structur este ncapsulat (ascuns), dac o astfel de
cerin nu a fost prevzut nc din faza de proiectare. Remarcm faptul c unele
SGBDOO de dat mai recent accept interogrile de tip AD-HOC ns, acest
lucru l realizeaz prin distrugerea ncapsulrii sau prin impunerea unor limite
privind interogrile posibile.
- Lipsa de experien n domeniu, comparativ cu experien dobndit n sistemele
tradiionale. Aceast lips de experien poate fi datorat cel puin de urmtorii
factori:
- este un domeniu mai nou de preocupare;
- SGBDOO prin componentelor lor sunt mai mult orientate spre
programatori dect spre utilizatorii finali neinformaticieni;
- se simte o trecere abrupt de la sistemele tradiionale la cele orientate
obiect, iar, nelegerea i nsuirea noului mod de abordare impune
eforturi sporite din partea proiectanilor i utilizatorilor. Acest aspect
genereaz o oarecare rezisten n acceptarea tehnologiei orientate obiect.

Capitolul 7
152
7.4. Comparaii ntre abordarea obiectual i cea
relaional privind modelarea datelor

Prezentarea asemnrilor i deosebirilor dintre modelarea relaional i modelarea
orientat obiect a datelor este semnificativ i de mare importan att pentru proiectanii de
baze de date ct i pentru utilizatori.
Proiectanii, cunoscnd foarte bine modelul relaional i apoi sesiznd asemnrile i
deosebirile dintre cele dou moduri de abordare a modelrii datelor, vor putea valorifica i
folosi experiena dobndit anterior ca baz substanial pentru nelegerea i nsuirea
metodologiei de proiectare a bazelor de date orientate obiect. Totodat, prin cunoaterea
asemnrilor i deosebirilor dintre cele dou moduri de abordare apare posibilitatea
conversiei unui model relaional n obiectual i invers. De altfel, o astfel de practic o
regsim n mod frecvent.
n cele ce urmeaz vom recurge la o prezentare comparativ a modelrii datelor,
lund n considerare conceptele folosite precum i obiectivele urmrite.
n tabelul 7.1 se prezint o comparaie ntre principalele concepte utilizate n
modelarea obiectual i relaional a datelor.

Tabelul 7.1. Compararea BDOO i BDR sub aspectul conceptelor folosite
Modelul orientat pe
obiecte
Modelul
relaional
Diferene
Obiect Entitate Obiectul precizeaz i comportamentul
Clasa de obiecte Tipuri de entiti Clasa de obiecte include i comportamentul
comun obiectelor din clasa respectiv
Ierarhia de clase Schema bazei de
date
Ierarhia de clase implic motenirea iar schema
implic chei externe
Instan de clas Entitate, tuplu sau
nregistrare
Instana poate avea un caracter mai restrictiv
Atribut Atribut Fr diferene
Relaii Relaii Fr diferene
Au semnificaia de descrieri, ns n BDOO
motenirea include att starea ct i
comportamentul
Mesaje / interfa Nu exist
ncapsulare Nu exist
Identificatorul de
obiect (OID)
Cheie primar n modelul relaional dac nu se definete cheia
primar sistemul genereaz n mod automat un
identificator

Deosebirile dintre modelul BDOO i modelul BDR pot fi evideniate i sub aspectul
obiectivelor urmrite sau prin alte caracteristici, aa cum se poate observa din tabelul 7.2.

Tabelul 7.2. Compararea BDOO i BDR sub aspectul obiectivelor urmrite
BDOO BDR
Obiective principale: ncapsularea i
independena datelor.
Obiectiv principal: asigurarea independenei
datelor fa de programele de aplicaii.
Independena claselor: pot fi reorganizate fr
a afecta modul de folosire a lor.
Independena datelor: datele pot fi
reorganizate i modificate fizic fr a afecta
modul de folosire.
BDOO stocheaz date i metode. BDR stocheaz numai date.
ncapsularea: datele pot fi folosite numai prin
metodele claselor.
Partiionarea datelor: datele pot fi
partiionate n funcie de cerinele i
specificul aplicaiilor utilizatorilor.
Obiecte active: obiectele sunt active.
Cerinele cauzeaz obiectelor executarea
metodelor acestora.
Date pasive: datele sunt pasive. Anumite
operaii limitate pot fi n mod automat
antrenate cnd datele sunt folosite.
Complexitate: structura datelor poate fi
complex, implicnd multiple tipuri de date.
Simplitate: utilizatorii percep datele sub
form de coloane, rnduri / tupluri i tabele.
Date nlnuite. Datele por fi nlnuite aa
nct metodele claselor ofer performane
sporite. Datele structurate precum i BLOB
(binary large objects) sunt folosite pentru
sunet, imagine, video etc.
Tabele separate: fiecare relaie / tabel este
separat. Operatorul de JOIN refer date din
tabele separate.
Neredundana metodelor: neredundana
datelor i metodelor sunt realizate prin
ncapsulare i motenire. Motenirea ajut la
reducerea redundanei metodelor.
Neredundana datelor: Normalizarea datelor
are ca scop de a elimina sau reduce
redundana datelor. Ea este folosit n faza
de proiectare a bazei de date i nu n faz de
dezvoltare a aplicaiilor.
Optimizarea datelor: datele pentru un obiect
pot fi interlegate i stocate mpreun, astfel
nct ele pot fi accesate mpreun de
mecanismul de acces.
Performana BDR este legat de nivelul de
complexitate a structurii datelor.
Model conceptual consistent: modelele
folosite pentru analiz, proiectare,
programare i accesul bazei de date sunt
similare. Conceptele aplicaiilor sunt in mod
direct reprezentate prin clasele de obiecte.
Model conceptul diferit: modelul structurii
datelor i acces reprezentat prin tabele i
JOIN-uri este diferit de cel n analiz,
proiectare i programare. Proiectul trebuie
s fie convertit n tabele relaionale i acces
conform SQL.

Analiznd cele dou tipuri de baze de date, obiectuale i relaionale, por fi desprinse
o serie de concluzii, dintre care amintim [21,51,73]:
- O baz de date relaional este format din relaii, care sunt seturi de tupluri, n
timp ce o baz de date orientata pe obiecte este format din clase, care sunt seturi
de obiecte;
- ntr-o baz de date relaional, componentele unui tuplu trebuie s fie tipuri
primitive (real, integer, strings etc.), n timp ce ntr-o baz de date orientat pe
obiecte, componentele unui obiect pot fi att tipuri primitive ct i tipuri
complexe (seturi, tupluri, liste, BLOB-uri etc.);
- Bazele de date orientate pe obiecte au anumite proprieti pentru care nu gsim
analogie n bazele de date relaionale, cum ar fi proprietatea de motenire i
metodele aparinnd obiectelor;
Capitolul 7
154
- n anumite sisteme de baze de date orientate pe obiecte, limbajul de manipulare a
datelor i limbajul gazd sunt aceleai;
- Bazele de date relaionale au ca obiectiv principal asigurarea independenei
datelor. Datele normalizate sunt separate de prelucrri iar, prelucrrile
corespunztoare satisfacerii cerinelor informaionale nu este obligatoriu s fie n
totalitate predefinite deci se accept i cerine ad-hoc;
- Bazele de date orientate obiect au ca obiectiv principal ncapsularea, fiind stocate
mpreun datele i metodele. Ele sunt inseparabile. Se spune c avem de a face cu
independena claselor nu cu independena datelor;
- Nevoia unui SGBDOO i nu unul relaional apare atunci cnd n aplicaiile de
referin avem de a face cu date complexe;
- Limbajele de programare necesit o nou sintax; mixarea, reproducerea i noile
metode de acces necesit de asemenea continuarea cercetrilor; trebuie realizate
caracteristici mai solide ale limbajelor de interogare; se simte nevoia continurii
n domeniul controlului concurenei, semantica mrcilor de timp i concurenei
bazate pe obiectele ;
- Limbajul C++ nu este un limbaj prea adecvat pentru implementarea bazelor de
date ntruct prezint probleme legate de mecanica definirii atributelor, mecanica
referirii la obiecte ntr-un mod sistematic. Totodat, SGBD actuale bazate pe
limbajul C++ duc lipsa unor importante funcii ale bazei de date iar, pentru a
compensa aceasta s-a recurs la implementri simple ale funciilor standard ale
sistemelor de gestiune, cum ar fi: nregistrarea n jurnal a tranzaciilor pentru
refacerea prin derulare nainte; un monitor multifir al tranzaciilor, un limbaj de
interogare i un procesor de interogri ;
- Piaa bazelor de date orientate obiect va continua s creasc, dar va rmne nc
doar o fraciune din piaa tradiional a bazelor de date ;
- Se apreciaz c SGBDR dein ponderea cea mai mare pe piaa bazelor de date,
ns ca perspectiv ele vor coexista nc mult timp mpreun cu SGBDOO.

7.5. Moduri de abordare ale dezvoltrii sistemelor
de BDOO

innd seama de multitudinea avantajelor oferite de modelul BDOO, se pune
problema cum anume se poate trece de la un anumit mod de organizare a datelor existent la
BDOO sau alte variante ce pot fi adoptate. Rspunsul la o astfel de ntrebare const n faptul
c pot fi adoptate diverse abordri, cum ar fi:
- Folosirea unui sistem de gestiune de baz de date convenional existent i
adugarea unui strat (layer) pentru procesarea cerinelor orientate obiect i
metodelor de stocare. ntr-o astfel de abordare sistemul de gestiune a bazei de
date nu se schimb, ceea ce nseamn c se pot folosi componentele software ale
acestuia precum i vechile aplicaii n curs de exploatare. Totodat, se poate
implementa o baz de date orientat obiect mult mai repede dect dac s-ar porni
de la conceperea i dezvoltarea tuturor componentelor sistemului de gestiune a
bazei de date.
- Adugarea de funcionaliti orientate obiect unui sistem de gestiune a bazei de
date relaional. ntr-o astfel de situaie se conteaz pe instrumentele, tehnicile i
experiena vast a tehnologiei relaionale care pot fi folosite pentru a reconstrui
un nou sistem de gestiune a bazelor de date. Pot fi adugai pointri (pointers) la

tabelele relaionale legndu-le de Obiectele mari lineare (BLOB Binary Large
Object).
- Regndirea n totalitate a arhitecturii sistemelor de gestiune a bazelor de date i
producerea unei noi arhitecturi care s fac fa noilor tehnologii orientate obiect.
Conform acestei variante se are n atenie sporirea substanial a performanelor
de ordin fizic a bazelor de date comparativ cu modelul relaional n ceea ce
privete stocarea informaiilor complexe.

7.6. Modelul conceptual al datelor obiect (CODM
-
)

Modelarea reprezint un proces de abstractizare a mediului nconjurtor n scopul
simplificrii nelegerii i redrii mai facile a acestuia.
Abstractizarea presupune ignorarea anumitor aspecte considerate nesemnificative n
favoarea reinerii a celor mai interesante i reprezentative.
Mediul nconjurtor poate fi considerat ca un sistem, subsistem sau parte a acestuia.
Pentru modelarea unor realiti, activiti, procese sau fenomene economice din
domeniul de interes se recurge la utilizarea a diferite metode, tehnici sau instrumente, cum ar
fi:
- utilizarea anumitor tipuri de diagrame sau grafice ;
- prezentarea textual a problematicii de referin;
- redarea fenomenelor i proceselor economice n limbaje formale;
- sintetizarea i redarea aspectelor de interes sub form de scheme logice etc.

n contextul sistemelor informatice n general, i n special al bazelor de date, se
poate recurge la modelarea i implicit elaborarea a o serie de modele, cum ar fi:
- Modelarea domeniului (The Domain Model),
- Modelarea proceselor de afaceri (The Business Process Model),
- Modelarea structurii statice a sistemului (The Static Model),
- Modelarea dinamicii sistemului (The Dynamic Model),
- Modelarea datelor (The Date Model).
Remarcm faptul c modelarea tuturor aspectelor amintite anterior se refer la acelai
sistem, ns prin fiecare tip de model se urmrete satisfacerea cerinelor informaionale de
interes a unei anumite categorii de utilizatori. Pentru a modela astfel de procese sau
activiti, n cele ce urmeaz vom evidenia i defini conceptele cu care se va opera n
contextul UML (Unified Modeling Language).

7.6.1. Conceptul de obiect

Un obiect este o entitate cu un rol bine definit n sistem, caracterizat de proprieti,
stare, comportament i identitate. La modul general, prin obiect vom nelege ceva asupra
cruia se poate ntreprinde o aciune, sau care poate declana / efectua o aciune.
Exemplu: persoan, main, factur, contract, salariat, chitan cas etc. Obiectul
poate fi concret (o entitate tangibil i vizibil, de exemplu o persoan, o mas, o floare etc.),

-
CODM The Conceptual Object Data Model
Capitolul 7
156
o entitate abstract (un concept, un eveniment, idee, un departament etc.) sau un artifact al
procesului de proiectare (de exemplu, interfa cu utilizatorul, control, planificare).
Proprietile unui obiect sunt date de atributele prin care se descriu caracteristicile
obiectului respectiv. Starea unui obiect este dat de valorile pe care le iau proprietile sale
la un moment dat.
Comportamentul arat modul n care un obiect acioneaz sau reacioneaz la
evenimente. O operaie este o simpl aciune pe care o execut un obiect asupra altui obiect
pentru a primi un rspuns.
Multitudinea operaiilor pe care le poate efectua un obiect sau se efectueaz asupra
acelui obiect implementate ntr-un limbaj de programare poart denumirea de metode, iar
multitudinea metodelor se spune c definesc comportamentul obiectului de referin. Un
obiect i expune comportamentul prin intermediul operaiilor care i pot afecta starea.
S considerm cazul unui student ION, reprezentat ca obiect. Obiectul student are
urmtoarele atribute: nume, data-naterii, adresa i telefonul. Starea obiectului este dat de
valorile asociate acestor atribute: ,,ION, ,,23-03-85, ,,Mihai Bravu nr.6, ,,4438601.
Comportamentul studentului este dat de operaii cum ar fi: schimbare-domiciliu, schimbare
telefon, trecerea ntr-un nou an de studii etc.
Toate obiectele au o identitate, astfel c nu exist dou obiecte identice. Dac exist
dou obiecte (instane) de tip student cu aceleai valori asociate atributelor (aceleai nume,
aceeai adres, acelai telefon i aceiai dat de natere) este vorba, totui, de dou obiecte
diferite. Chiar dac obiectele au valori identice ale atributelor, ele au identiti diferite. Un
obiect i pstreaz identitatea de-a lungul existenei sale. Exemplu, dac studentul ION se
cstorete sau i schimb domiciliul, el va fi reprezentat de acelai obiect.
n mod formal un obiect reprezint o pereche de forma <Oid, Val>, unde <Oid> este
identificatorul obiectului, iar <val> este o valoare aparinnd obiectului. Valoarea <Val>
poate lua una dintre urmtoarele forme:
- Valoare primitiv. Un membru de tip de dat Integer, String, Float sau Boolean;
exemplu: ,,B 54 PDD;
- Valoare referin. Un OID a unui obiect, exemplu: # 123;
- Valoare tuplu de forma | |
n n
v A v A : , , :
1 1
, unde
n
A A , ,
1
sunt nume de atribute
distincte i
n
v v , ,
1
sunt valori asociate atributelor;
- Set de valori, de forma { }
n
v v , ,
1
unde
n
v v , ,
1
sunt valori. Exemplu , numere
de telefoane ale unei persoane: 021-3348601, 021-1234567.

Exemplu: presupunem un obiect, din cadrul sistemului bancar romnesc, BCR, cu
urmtoarea descriere:
(# 11, [cod fiscal: 123456,
Denumirea: BCR,
Preedinte: Rdulescu,
Nr. telefon: {021-1234567, 021-7654321},
Sucursale: {# 333, # 444, # 555, # 666},
Localitate: Bucureti])
unde:
- simbolul # 11 reprezint OID-ul obiectului cu denumirea BCR;
- ntre paranteze drepte [ ] se definesc atributele cu valorile asociate acestora, ele
pe ansamblu reprezentnd o valoare a tuplului;
- ntre parantezele acolade { }, se specific seturi de valori cum sunt numerele de
telefoane i OID-urile sucursalelor bncii;

- referinele ctre sucursalele ce aparin bncii mam-BCR, sunt precizate prin
OID-urile acestora {# 333, # 444, # 555, # 666}.

Obiectele pot fi simple sau complexe. Un obiect simplu apare ca un articol sau
entitate din mediul nconjurtor ce nu poate fi descompus sau nu se justific descompunerea
acestuia; el este tratat ca un ntreg.
Exemplu: persoana, porumbel, medicament etc. Un articol complex apare ca o
entitate sau articol din mediul nconjurtor care este privit ca un singur obiect ns acesta se
poate combina cu alte obiecte printr-un set de relaii, cum ar fi: B este parte a lui A sau A
este format din B, C, D . Obiectele B, C, D, coninute de A, la rndul lor pot fi
complexe, ceea ce n final face s asistm la o ierarhie de obiecte. Exemplu, un obiect
complex, Automobil poate fi privit ca un obiect format dintr-o serie de componente care la
rndul lor sunt privite ca obiecte, de forma (figura 7.1).
Gruparea obiectelor n cele dou categorii prezint interes cel puin sub aspectul
manipulrii obiectului coninut. Un obiect coninut poate fi manipulat n dou moduri. ntr-
un prim mod, obiectul coninut poate fi ncapsulat n obiectul complex i astfel formeaz o
parte a acestuia. ntr-o astfel de situaie, structura obiectului coninut reprezint o parte a
structurii obiectului complex, iar obiectul coninut poate fi accesat numai cu metodele
obiectului complex. n al doilea mod, un obiect coninut poate fi considerat ca avnd o
existen independent de cea a obiectului complex. n acest caz, n obiectul printe nu este
stocat direct obiectul membru, ci doar identificatorul su OID. Obiectul coninut are structura
i metodele lui proprii i poate fi deinut de diverse obiecte printe.

Fig. 7.1. Obiect complex

7.6.2. Identificatorii obiectelor

Aa dup cum s-a mai precizat, fiecare obiect are o identitate unic i stabil, numit
identificatorul obiectului OID (Object Identifier), care este independent de valoarea actual
a obiectului.
OID-ul este generat de ctre sistem i atribuit obiectului n momentul
crerii/ncrcrii bazei de date. El este invizibil pentru utilizatori, independeni de valorile
atributelor sale i stabil pe toat durata de existen a obiectului i chiar mai mult dect att,
dac obiectul respectiv este ters din baza de date OID-ul acelui obiect nu se atribuie ulterior
unui alt obiect.
AUTOMOBIL
MOTOR ROI ASIU
PISTOANE CILINDRII BUJII
Capitolul 7
158
Observm asemnarea i deosebirea dintre OID i cheia primar a unei relaii. Ca i
OID-ul cheia primar ofer posibilitatea identificrii unice a oricrui tuplu/obiect, ns
valoarea cheii primare este unic doar la nivelul unei tabele i nu la nivelul ntregului sistem
ca i OID-ul, iar pe de alt parte, valoarea cheii primare poate fi schimbat n timp.
Exemplu, presupunem un obiect automobil avnd cheia primar numrul de
nmatriculare n circulaie. Totodat presupunem faptul c proprietarul vinde automobilul
unei alte persoane. Cu aceast ocazie poate fi schimbat numrul de nmatriculare, deci
implicit valoarea cheii primare, dei automobilul rmne fizic acelai i chiar n aceiai
baz de date la poliie. n contextul bazelor de date orientate obiect OID-ul automobilului
rmne acelai doar c se schimb proprietarul.
Faptul c OID-ul este unic la nivelul ntregului sistem i invariabil n timp prezint o
importan deosebit sub aspectul asigurrii mai facile a integritii entitilor i a celor
refereniale.
Dac n urma tergerii unui obiect din baza de date OID-ul acelui obiect ar fi atribuit
unui alt obiect, o referin anterioar la OID-ul obiectului ters s-ar putea menine, ns de
aceast dat OID-ul referit ar aparine unui alt obiect. Deci n realitate nu ar fi respectat i
meninut integritatea referenial. Exemplu: presupune o relaie referenial ntre obiectul
Printe i Copil. Dac Printele unui copil ar fi ters din baza de date i OID-ul acestuia
ulterior ar fi atribuit altui Printe, n contextul posibil de a se menine relaia referenial s-ar
ajunge la situaia n care un copil ar aparine unui alt printe dect cel iniial declarat.
O alt problem ce merit a fi prezentat, izvorte din faptul c identificatorii OID
ca mecanism pentru identitatea obiectelor sunt independente de coninut, n sensul c
identificatorii OID nu depind n nici un fel de datele coninute n obiect. ntr-o astfel de
situaie, dou obiecte pot prea utilizatorului aceleai (ele avnd toate valorile atributelor
aceleai) i totui au identificatori OID diferii, fiind astfel obiecte diferite. innd seama de
faptul c identificatorii OID sunt invizibili pentru utilizatori, atunci ne ntrebm cum poate
distinge utilizatorul aceste dou obiecte? Dintr-o astfel de stare putem desprinde concluzia c
sunt nc necesare cheile primare, pentru a permite utilizatorului s disting obiectele.
n ncheierea acestui paragraf, facem precizarea c exist o serie de mecanisme,
tehnici i algoritmi pentru identitatea obiectelor, cum ar fi: identitatea obiectelor bazate pe
valoare, identitatea folosind numele variabilelor i pointerii sau adresele de memorie
virtual, identificatori OID logici i fizici, tehnici de mixare a pointerilor etc. Despre astfel
de probleme, i chiar mai multe, cei interesai pot consulta o serie de alte materiale [81,12].

7.6.3. Atribute proprieti ale obiectelor

Fiecare obiect din mediul nconjurtor comport o anumit descriere ce se realizeaz
cu ajutorul atributelor. Multitudinea atributelor prin care se descrie un obiect definesc
proprietile acelui obiect.
Atributele pot fi simple sau complexe, care la rndul lor pot fi refereniale, de
colecii i derivate.
Pentru exemplificarea ne vom referi la descrierea a dou entiti, astfel (figura 7.2.):

DEPARTAMENT: {
Denumire: STRING;
DEPARTAMENT SALARIAT
are 1, -
1.1
aparine de

Cod - dep: INTEGER;
ef - dep: SALARIAT;
Nr. telefoane: SET [STRING];
Angajai: LIST [SALARIAT]}
SALARIAT: {
Marca: INTEGER;
Nume: STRING;
Prenume: STRING;
Profesia: STRING;
Data-naterii: DATE;
Funcia: STRING;
Loc-munc: DEPARTAMENT }

Fig. 7.2. Exemple de atribute

unde:
Atributele simple pot fi un tip de date atomic, care include tipurile de date clasice
prezente n limbaje de programare, cum ar fi: ntreg, real, boolean i iruri de caractere. n
exemplul din figura 7.2, denumire, cod-dep, marca, funcia pot fi considerate ca atribute
simple.
Atributele refereniale sau de asociere, sunt folosite pentru a defini relaii refereniale
ntre obiecte. Ele sunt echivalente pointerilor din limbajele de programare sau cheilor
externe n cazul sistemelor relaionale, ns prezint i diferene importante, astfel:
- Contrar pointerilor, atributele refereniale sunt incoruptibile sau nealterabile, n
sensul c dac obiectul referit a fost ters din baza de date atunci atributul
referenial n mod automat va fi invalidat;
- Contrar cheilor externe, atributele refereniale nu sunt asocieri de valori vizibile
utilizatorilor. n exemplul nostru din figura 7.2., atributele Sef-dep:
SALARIAT i Loc-munc: DEPARTAMENT sunt atribute refereniale.
Atributele colecii fcnd parte din categoria atributelor complexe pot fi la rndul lor
grupate n seturi, liste i tablouri de valori.
Atributele colecii vor conine fie valori ale atributelor simple fie referine.
n exemplul din figura 7.2. Nr.-telefoane este un atribut de tip SET i va conine
multitudinea numerelor de telefon pe care le are un Departament, iar Angajai este un
atribut de tip LIST i va conine ca valori multitudinea identificatorilor OID ale Salariailor
ce lucreaz ntr-un anumit Departament.
Atributele derivate le mai regsim i cu denumirea de atribute de proceduri. Uneori,
n practic, in loc de a stoca n mod explicit valoarea unui atribut, este de preferat de a-l
determina sau calcula printr-o procedur oarecare i apoi a-l da disponibil i a-l face
cunoscut celor interesai. Pe considerentul c valoarea unui atribut derivat se determin
printr-o metod de tip procedur sau funcie, atributul respectiv mai poart denumirea de
atribut procedur. n exemplul nostru de referin nu apare un atribut derivat, ns ar putea fi
definit unul cu denumirea sugestiv Vrsta salariatului. ntr-o astfel de situaie Vrsta ar
putea fi determinat cunoscnd Data-naterii i apoi prelund data curent de sistem. Prin
diferen se obine vrsta.
Capitolul 7
160
7.6.4. Tipuri i clase de obiecte

7.6.4.1. Tipuri de obiecte

n literatura de specialitate nu exist o unanimitate de preri cu privire la definirea i
semnificaia conceptelor de tipuri i clase de obiecte. Astfel, ntlnim situaii n care unii
autori folosesc doar conceptul de tipuri, ali de clas iar o alt categorie folosesc att
conceptul de clas ct i conceptul de tipuri, aa dup cum se va putea vedea n cele ce
urmeaz.
R.G.G. Cattell [10] folosete doar conceptul de tip dei recunoate i conceptul de
clas, ns pentru a nltura anumite ambiguiti, n lucrare renun la folosire termenului de
clas, acesta avnd cel puin urmtoarele semnificaii:
- O clas definete un tip care este o intensie, adic structura i comportamentul
obiectelor de un tip particular. Conceptul de tip este folosit pentru a proiecta o
intensie. Intensia va regrupa structura (atributele i relaiile obiectului) precum i
comportamentul (metodele asociate tipului);
- O clas definete o extensie, adic un ansamblu de obiecte de un tip particular;
- O clas la rndul ei poate fi considerat ca fiind tot un obiect sau meta-obiect
dispunnd de atribute, relaii i metode proprii. Aceste proprieti, relaii i
metode au semnificaie doar la nivelul ntregii clase i nu la nivelul obiectelor ce
fac parte din clas. Exemplu, un atribut avnd semnificaia de SUMA valorilor
tuturor factorilor din clasa FACTURI, are semnificaie doar la nivelul ntregii
clase de obiecte i nu la nivelul fiecrui obiect.
R.G.G. Cattell pentru a defini conceptul de tip recurge la o analogie cu modelul
relaional, considernd c tabelele din modelul relaional sunt definiri de tipuri iar tuplurile
(liniile) unei tabele sunt instane de tupluri.
Thomas Connolly [81] precizeaz c, adesea, n literatura de specialitate, termenii de
tip i clas sunt sinonimi, cu toate c anumii autori fac o distincie ntre ei, aa cum se
va preciza n continuare. Un tip corespunde noiunii de tip de date abstract. Pe de alt parte,
o clas definete modul de creare a obiectelor i formeaz metode care pot fi aplicate
acestora. n acest mod o clas se refer mai degrab la modul de implementare a
proprietilor i comportamentului obiectelor. ntr-un astfel de context, pe parcurs au fost
create dou modele de sisteme de gestiune a bazelor de date orientate obiect, astfel:
- unele care folosesc ca termen de baz clasa, dintre care amintim Smalltalk, Orion,
ITASCA, Object Store, Vision etc.;
- altele care folosesc ca termen de baz conceptul de tip, dintre care amintim:
Versant, Ontos, Simula, O
2
etc.
O astfel de situaie o ntlnim i la nivelul limbajelor de programare. De exemplu,
limbajul C++ folosete conceptul de clas, pe cnd SQL3 recurge la utilizarea conceptului de
tip. n acest fel definirea tipului n SQL3 este similar cu definirea simplificat a clasei n
C++.
Susintorii i realizatorii lui SQL3 folosesc conceptul de tip, preferabil celui de
clas pe considerentul c cel din urm a fost suprancrcat pentru a se referi la un tip sau la
o colecie de instane de un anumit tip. Din cele constatate se pare c exist unii autori care
consider c tipurile i clasele de obiecte sunt nrudite (legate) ns concepte distincte. Din
aceast categorie amintim civa : Michael Kifer, Paolo Alzeni [40,51,65].
ntr-o baz de date orientat obiect tipurile permit definirea proprietilor obiectelor,
att cele statice (descrierea structurii obiectelor) ct i dinamice (descrierea
comportamentului obiectelor ca metode aplicabile obiectelor). Referitor la partea static a

tipurilor, aceasta este construit utiliznd constructorii de tip i un set larg de tipuri de date
atomice, care includ tipurile de date clasice prezente n limbajele de programare, cum ar fi:
ntreg, real, boolean i iruri. Tipurile de date atomice includ i identificatorii de obiecte
(OID).
Constructorii de tipuri permit definirea tipurilor numii tipuri de date complexe, care
dicteaz structura instanelor (numite obiecte complexe) a unei baze de date obiect.
Reprezentarea unui tip se face conform unei expresii de forma:
[CNP: integer, Nume: String, Nr. telefon: {string}, copii: {PERSOANA}]
Aceast definire de tip precizeaz faptul c atributele: CNP accept valori de tip
integer, Nume accept valori din domeniul primitiv string (ir de caractere), Nr. telefon
trebuie s ia valori ce sunt set de iruri de caractere, iar valorile atributului copii sunt
seturi de obiecte ce aparin clasei PERSOANA. Totodat, se poate observa c expresia
anterioar descrie un tip (model) n care structuri complexe pot fi incluse n interiorul altor
structuri. De exemplu, valorile pentru Nr. telefon sunt seturi de valori primitive, n timp ce
valorile pentru copii sunt seturi de obiecte provenite din clasa PERSOANA.
n mod intuitiv se poate deduce faptul c, tipul unui obiect este tocmai colecia
tipurilor componentelor acestuia. Constructorii tip permit definirea de tipuri numite tipuri de
date complexe, care dicteaz structura instanelor numite obiecte complexe a unei baze de
date obiect. Mai precis, o definire recursiv a tipurilor de date complexe corespunztoare
structurii obiectelor complexe, bazat pe constructori de tip, apare astfel:
- tipuri de baz (valori primitive): ntreg, ir, real i boolean; exemplu: B10XYZ
ar putea fi valoarea asociat atributului numrului de nmatriculare n circulaie a
autovehiculului descris astfel Nr. MAINA: STRING;
- tipuri referin: Numele claselor definite de utilizator, cum ar fi SALARIAI i
ECONIMITI, unde ECONOMITII refer SALARIAII, sau un alt exemplu ar
putea fi de forma unui OID al unui obiect.
- tipuri set i liste: Constructorii de tip SET i LISTE permit definirea de tipuri ale
cror instane sunt colecii de valori (posibil complexe) de acelai tip. Seturile
sunt colecii neordonate ce nu accept duplicri, iar listele sunt colecii ordonate
cu posibile duplicri. Valorile din cadrul setului pot fi de orice tip. n exemplul
anterior au fost ntlnite urmtoarele seturi:
- Nr. telefon: {string}, reprezint un set de iruri de caractere cu
semnificaia c stocheaz multitudinea numerelor de telefoane pe care le
are o persoan, de forma: {040-021-334861, , 040-021-3359211};
- Copii: {PERSOANA}, reprezint un set de obiecte aparinnd clasei
PERSOANA.
- tipuri nregistrare / tuplu: un constructor nregistrare permite definirea de tipuri a
cror instane sunt tupluri de valori de diferite tipuri posibile. Constatm faptul c
i n aceast privin unii autori folosesc doar conceptul de constructor tuplu nu i
nregistrare [40], ns sub aspectul formalizrii matematice lucrurile sunt foarte
apropiate. Dac T
1
, , T
n
, sunt denumiri de tipuri i A
1
, , A
n
sunt denumiri de
atribute distincte, atunci:

T = nregistrare de [A
1
:T
1
, , A
n
:T
n
] este un tip nregistrare.

Deosebirea dintre cele dou alternative se observ doar la nivelul limbajelor de
definire a datelor, n funcie de specificul acestora.
Exemplu:
[CNP: ntreg, Nume: string, An-studii: integer, Adresa:
[Localitate: string, Strada: string, Numr: integer]]
Capitolul 7
162
Aceast definire reprezint un tip nregistrare (RECORD) n care primele trei
componente (atribute) au tipuri de date de baz, iar al patrulea (Adresa) este de tip tuplu.
Deci, se poate constata faptul c avem de a face cu un tip nregistrare n cadrul cruia apare
un subtip tuplu Adresa, n mod intuitiv se poate desprinde concluzia c puteam avea de a
face cu subtipuri i supertipuri de date complexe, corespunztoare obiectelor complexe.
Totodat precizm faptul ca n mod obinuit n cele mai multe sisteme orientate obiect o
definire de tip de dat are constructorul nregistrare (RECORD) la nivelul cel mai nalt.
Din punctul de vedere al bazelor de date orientate obiect, o clas poate fi considerat
ca un tip nregistrare constnd din metadata care asigur ntreaga informaie necesar pentru
a construi i a folosi un anume obiect. Totodat e posibil de a considera instanele unei clase
ca fiind nregistrri stocate ntr-un fiier. Noile nregistrri avnd diferite valori pot fi
adugate n fiier. Un dicionar de date pentru SGDB poate conine descrieri a mai multor
tipuri diferite de nregistrri, fiecare cu un set diferit de atribute, aa dup cum se va putea
constata i n exemplul ce urmeaz.
Pentru exemplificare vom considera un obiect complex referitor la structura unei
Universiti, unde:
- O universitate poate avea cel puin dou faculti regsite n aceeai localitate cu
sediul Universitii sau n localiti diferite;
- O facultate poate avea sau nu specializri pe secii;
- n cadrul unei Universiti pot exista unul sau mai multe laboratoare pe care le
pot folosi oricare dintre faculti, dac prezint interes i exist un acord n acest
sens;
- La nivelul unei Universiti pot exista una sau mai multe biblioteci, amplasate
ntr-un singur corp sau n mai multe corpuri de cldiri;
- Catedrele ca departamente, din punct de vedere administrativ i al coordonrii
acestora sunt arondate facultilor;
- O Universitate dispune de un corp didactic propriu, organizat pe Catedre de
specialitate;
- Un profesor poate preda una sau mai multe discipline la o facultate sau la mai
multe faculti.
n situaia n care la nivelul Ministerului nvmntului i Cercetrii ar prezenta interes
proiectarea unei baze de date care s permit evidenierea multitudinii unitilor de
nvmnt superior din Romnia, precum i a altor aspecte, necesare elaborrii unor
studii de analiz, prognoze, evaluri comparative etc., diagrama tipurilor de obiecte ar
putea fi redat astfel (figura 7.3.).



Fig. 7.3. Diagrama tipurilor de obiecte

CARTE CITITOR
0,-
mprumutat de
gestioneaz
1,- 1,-
gestionat de
BIBLIOTECAR
ofer carte
solicit carte
1,- 1,-
1,-
are
1,1
angajat la
BIBLIOTECA
1,* are
se afl n 1,-
1,-
1,1
dispune de
aparine de
UNIVERSITATE PROFESOR LABORATOR
1,- are
este la 1,1
1,1 aparine de
dispune de
1,-
CURS
SECIE
are 10,- 1,- frecventeaz
STUDENT
25,-
1,* predat la
specializeaz 25,-
specialist n 1,1
FACULTATE CATEDRA
coordonat de

1,1
coordoneaz

1,- 1,-
folosit de
folosete
0,-
dispune
de
aparine de
1,1
1,2
urmeaz
urmat de
100,-
frecventat de
1,* mprumut
Capitolul 7
164
Pe baza diagramei tipurilor de obiecte, se poate trece la definirea structurii bazei de
date orientate obiect, ns ne vom limita doar la o parte a acesteia, astfel (figura7.4.).
Universitate: record of (
Denumire:

string,
Nume-rector: string,
Adresa: record of (
Ora: string,
Strada: string,
Nr: string)
Faculti; set of (
record of (
Denumire: string
Nume decan: string
Ora: string))
Secii: set of (
record of (
Denumire: string
Nr - studeni: string))
Biblioteci: set of (
record of (
Corp - cldire: string
Profil: string
Bibliotecari: set of (
record of (
Nume: string
Studii: string)))

Fig. 7.4. Exemplu de definire de tip de obiect complex

Asociind valori compatibile cu definirea tipului, situaia ar putea apare de forma:
I1: [ASE, Brbulescu, [Bucureti, Piaa Roman, 6]
{[CSIE, Popescu, Bucureti, {Informatic, 600], [Cibernetic, 500],
[Statistic, 500], [Economie, 400}]},
{[Dorobani 2700, Informatic, {[Dan, superioare], [Vasile, medii]}],
[Eminescu 1000, Management, {[Barbu, superioare], [Tudor, medii]}]}]

unde:
- nregistrrile sunt definite prin paranteze drepte iar seturile prin acolade;
- I1 reprezint o instan din cadrul definirii tipului de obiect complex.

De remarcat faptul c un obiect poate include referiri explicite la un alt obiect, pe
baz de OID (Object Identifications). Incluznd referiri n structura din figura 7.4., noua
definire de tip obiect complex va apare astfel (figura 7.5):

Universitate: record of (Denumire: string,
Nume-rector: string,
Adresa: record of (
Ora: string,
Strada: string,
Numr: integer),
Faculti: set of (- Faculti),
Biblioteci: set of (-Biblioteci))


Faculti: record of (Denumire: string,
Nume-decan: string,
Ora: string
Secii: set of (- Secii))
Secii: record of (Denumire: string,
Nr - studeni: integer),
Biblioteci: record of (corp cldire: string,
Profil: string,
Bibliotecari: set of (- Bibliotecari))
Bibliotecari: record of (nume: string,
studii: string)

Fig. 7.5. Exemplu de definire implicnd i referine de obiecte

Un set de instane pentru definirile de mai sus, implicnd i referinele la alte obiecte,
apare astfel (figura 7.6.):

01: <OID1, [ASE, Brbulescu, [Bucureti,Piaa Roman, 6], OID2, OID7]>
02: <OID2, [CSIE, Bucureti, {OID3, OID4, OID5, OID6}]>
03: <OID3, [Informatic, 600] >
04: <OID4, [Cibernetic, 500] >
05: <OID5, [Statistitic, 500] >
06: <OID6, [Economie - matematic, 400] >
07: <OID7, {OID8, OID11}>
08: <OID8, [Dorobani - 2700, Informatic, {OID9, OID10}],
09: <OID9, [Dan, superioare] >
10: <OID10, [Vasile, medii] >
11: <OID11, [Eminescu, Management, {OID12, OID13}],
12: <OID12, [Barbu, superioare] >
13: <OID13, [Tudor, medii] >

Fig. 7.6. Exemplu de instan n care apar i referiri

7.6.4.2. Clase de obiecte

Multitudinea obiectelor ce se bucur de aceleai proprieti i comportament
formeaz o clas de obiecte.
Obiectele din cadrul unei clase constituie instanieri ai clasei respective. n UML o
clas se reprezint printr-un dreptunghi cu trei compartimente separate prin linii orizontale:
numele clasei n primul compartiment, lista de atribute n al doilea compartiment i lista de
operaii n al treilea compartiment.
Diagrama claselor indic structura static a modelului orientat obiect, surprinznd
clasele componente i relaiile dintre acestea. n figura 7.7. sunt reprezentate clasele
STUDENT i CURS.
O diagram de obiecte este un graf de instane compatibile cu o diagram de clase
dat. ntr-o diagram de obiecte, un obiect este reprezentat de un dreptunghi cu dou
compartimente. Numele obiectului este dat sub forma numeobiect: numeclasa, unde
numeobiect poate lipsi.
Capitolul 7
166

Fig. 7.7. Exemplu de clase

n figura 7.8. este reprezentat diagrama de obiecte asociat diagramei claselor de
mai sus.

Fig. 7.8. Exemplu de instane

Clasele joac acelai rol n CODM (Conceptual Object Data Model) ca i relaiile n
baze de date relaionale (BRD). n modelul relaional baza de date este format dintr-un set
de relaii i fiecare relaie include un set de tupluri iar in CODM o baz de date este format
dintr-un set de clase i fiecare clas include un set de obiecte. Aadar n BDR putem avea o
relaie numit STUDENT cu tupluri coninnd informaii despre fiecare student iar in
CODM putem avea o clas STUDENT cu obiecte coninnd informaii despre fiecare
student. ntr-o astfel de situaie apare posibilitatea convertirii unei baze de date relaionale
ntr-o baz de date orientat obiect cu ataarea unui OID fiecrui tuplu i invers.
O clas are un tip, care descrie structura comun a tuturor obiectelor ce fac parte din
aceiai clas, i semnturi de metode, care sunt declaraii de operaii ce pot fi aplicate clasei
de obiecte. De remarcat faptul c numai semnturile metodelor sunt parte a CODM,
implementrile nu sunt. Implementarea unei metode este o procedur scris ntr-un limbaj
gazd, ce este memorat pe serverul bazei de date.
Multitudinea obiectelor ce aparin unei clase formeaz un set de obiecte i constituie
extensia (extent) clasei [24,34,42].
ntr-un astfel de context, prin analogie, se poate spune c o clas are rolul de
container de obiecte n / din care obiectele n mod dinamic pot fi adugate sau terse.
n limbajele de definire a datelor (DDL) ex. n O2 definirile tipurilor sunt incluse ca
parte a definirilor claselor de obiecte.
n general, definirea unei clase este separat n dou pri, i anume, partea de
interfa i partea de implementare.
- interfaa descrie tipul obiectelor aparinnd clasei, care include semnturile
tuturor metodelor. Fiecare semntur conine denumirea i tipul fiecrui
parametru a metodei. Parametrii de intrare / ieire n / din metod fac posibil
invocare metodei n cadrul programelor de aplicaii.
- implementarea descrie implementarea metodelor adic, transpunerea operaiilor
ntr-un limbaj de programare.
Ion: Student
- Nume = Ion
- Data Natere = 23-03-1981
- Adres = Bd. Magheru nr.5
- Telefon =4646306
Curs
- Cod = 22
- Denumire = Multimedia
- Sala = 2314
- Ora = 12.00
Student
- Nume
- Data Natere
- Adres
- Telefon
+ schimb-adresa ( )
+ nregistrare la curs ( )
Curs
- Cod
- Denumire
- Sala
- Ora
+ nscrierecurs ( )

Interfaa descrie numai operaiile aplicabile asupra obiectelor n timp ce
implementarea ascunde programul corespunztor operaiilor. De remarcat faptul c unele
SGDBOO ofer posibilitatea abaterii de la interpretarea strict a ncapsulrii permind
accesul de date i prin alte forme / interfee i nu numai prin intermediul metodelor, de
exemplu utiliznd limbajul de cereri.
Din cele prezentate se poate desprinde ideea c tipurile sunt abstractizri ce permit
att descrierea proprietilor (strilor) ct i comportamentul, n timp ce clasele descriu att
partea extensional a obiectelor ct i implementarea metodelor referitoare la un tip. Tipul
descrie proprietile abstracte n timp ce clasa descrie implementarea acelor proprieti
abstracte utiliznd structuri de date i programe.
Aa dup cum s-a mai artat i n paragrafele anterioare, unii autori de SGBDOO sau
de cri folosesc cu precdere conceptul de clas, alii conceptul de tip iar alii utilizeaz
ambele concepte, ele fiind nrudite ns distincte. Paolo Atzeni, Stefano Ceri, Ricardo
Torlone, Michael Kifer i Arthur Bernstein, se situeaz pe o astfel de poziie [65,69,67],
preciznd c:
- tipurile i clasele sunt concepte distincte;
- fiecare clas este asociat la un singur tip;
- conceptul de clas descrie att implementarea ct i extensia unui tip;
- clasele ajut la organizarea obiectelor ntr-o categorie.
n figura 7.9 se sugereaz relaiile ntre clas, tip, obiect, valori, extensie, intensie etc.

Fig. 7.9. Relaia ntre clas i tip

Din figura 7.9 se poate desprinde concluzia c tipul, clasa, extensia i intensia sunt
nrudite ns diferite ca noiuni i semnificaie. Fiecare obiect are valori, asociate unor
atribute ce aparinnd unui tip. Fiecare obiect aparine unei clase care are un tip.
n cele ce urmeaz vom exemplifica modul de descriere a claselor de obiecte ce
includ i definirile de tipuri. n acest scop vom face referiri la clasele, tipurile i conceptele
redate n figurile 7.3., 7.4., 7.6 folosind limbajul O
2
, astfel :

add class Universitate
type tuplu (Denumire: string,
Nume rector: string
Adresa: tuplu (Ora: string,
Strada: string,
Numr: integer)
Clasa
are un
Tip
conine
un set de
Obiecte
au
Valori
extensie intensie

descriere / atribute
Capitolul 7
168
Faculti: set of (-Faculti),
Biblioteci: set of (-Biblioteci))
add class Faculti
Nume decan: string
Ora: string
Secii: set of (- secii)
add class Secii
Nr studeni: integer)
add class Biblioteci
type tuplu (Corp - cldire: string,
Profil: string,
Bibliotecari: set of (- Bibliotecari))
add class Bibliotecari
type tuplu (nume: string,
studii: string)
De remarcat faptul c n O2 avem de a face, pe de o parte, cu schema bazei de date,
care include definirea proprietilor i metodelor claselor, iar pe de alt parte cu baza de date
propriu-zis ce include datele efective. In acest context prin comanda " add " se adaug o
clas la schema bazei de date, presupus c a fost declarat anterior.

7.6.5. Metode

7.6.5.1. Conceptul de metod i aspecte de ordin general

Aa dup cum s-a mai precizat, multitudinea operaiilor pe care le poate efectua un
obiect sau se efectueaz asupra acelui obiect implementate ntr-un limbaj de programare
poart denumirea de metode.
O metod are o semntur, care descrie parametrii metodei i include toate
informaiile ce permit invocarea acesteia i o implementare, care conine codul metodei
(programul corespunztor metodei), elaborat ntr-un limbaj de programare. Semntura
metodei este o component a definirii clasei de obiecte.
n general, fiecare metod este asociat unei clase specifice de obiecte. n acest caz,
metoda are ca int (target) o anume clas de obiecte. Exist i sisteme ce permit definirea de
metode multi-int (multi-target), care se aplic la un numr arbitrar de obiecte fr a
favoriza vreunul ntr-un anumit mod. n acest caz, definirea acestora este dat n mod separat
de definirea clasei. Totodat, precizm faptul c fiecare metod are un numr arbitrar de
parametrii de intrare i un singur parametru de ieire.
Metodele corespunztoare operaiilor pe care le implementeaz pot fi grupate astfel:
- metode constructor (operaii de tip constructor), destinate a crea o nou instan,
un nou obiect al clasei. De exemplu, n clasa Student putem avea metoda
(operaia) CREAZ-STUDENT care creeaz un nou obiect de tip student i i
iniiaz starea. De remarcat faptul c toate clasele trebuie s aib o metod
constructor;
- metode destructor, folosite pentru tergerea / abandonarea obiectelor i posibil
altor obiecte legate de acestea;

- metode de regsire / accesare folosite numai pentru preluarea valorilor asociate
atributelor obiectului. Exemplu: pentru clasa STUDENT, metoda
CALCULEAZ-VRSTA studentului plecnd de la data naterii sale. O astfel
de metod nu afecteaz starea obiectului;
- metode de actualizare, folosite pentru actualizarea strii obiectului. Exemplu,
metoda posibil schimb adresa din clasa student are menirea de a actualiza /
modifica valoarea atributului adresa.

Metodele mai pot fi clasificate i n funcie de specificul cerinelor de aplicaii, astfel:
- metode publice, ce reprezint particularitatea c pot fi apelate din oricare program
de aplicaie;
- metode private, ce prezint particularitatea c pot fi apelate numai din interiorul
altor metode ale aceleai clase.

7.6.5.2. Definirea semnturilor i implementarea metodelor

n cele ce urmeaz vom recurge la un exemplu de definire de semntur i
implementare a unei metode n O2. Totodat, reamintim c o baz de date O2 este format
din dou componente i anume: schema bazei i baza de date propriu-zis. Schema conine
informaii despre structura de date a fiecrei clase, atributele i metodele ei, drepturi i
privilegii de acces etc. Baza conine date actuale n concordan cu schema.
Procedura de lucru cu O2 prevede pentru nceput crearea schemei bazei de date, de
forma:
CREATE SCHEM denumire schema;
CREATE BASE denumire baz;
apoi activarea schemei i bazei, de forma:
SET SCHEM denumire schema;
SET BASE denumire baz;
Dup aceste operaii se poate trece la definirea claselor i metodelor corespunztoare
Schemei setate. Ulterior pot fi fcute noi adugri de clase de obiecte.
Presupunem ca dorim s adugm o metod init schemei bazei n care este inclus
Clasa Universitate, din figura 7.3. Definirea semnturii metodei va apare astfel:

add method init (Denumire par: string,
Nume rector par: string,
Ora par: string,
Strada par: string,
Numr par: integer)
in Class Universitate is public

iar definirea implementrii metodei init implic urmtoarea sintax:

Body method init (Denumire par: string,
Nume rector par: string,
Ora par: string,
Strada par: string,
Numr par: integer)
in Class Universitate
CO2 {self Denumire = Denumire par;
self Nume = Nume par;
Capitolul 7
170
self Ora = Ora par;
self Strada = strada par;
self Numr = Numr par;
return (self);}$

Referitor la definirea semnturilor i implementrii metodelor, n cele ce urmeaz
vom cuta s facem anumite precizri.
Metoda init face parte face parte din categoria metodelor constructor (de creare) de
clas; ea genereaz partea de stare a unui nou obiect creat n cadrul clasei Universitate.
Structura de definire a semnturii apare astfel:
Method den-metod ( )
n
p p p , , ,
2 1
n class den-clasa
(
)
`
private
public

unde:
- partea mai pronunat reprezint cuvinte rezervate;
-
n
p p , ,
2 , 1
reprezint parametrii actuali de apel.

n ceea ce privete partea de implementare a metodei, ea este precizat prin cuvntul
rezervat body i este scris n CO2 (o extensie a limbajului de programare C) care permite
accesul direct i transparent la obiectele stocate n baza de date. La nivelul corpului metodei
(body init) se precizeaz lista de parametrii, conform urmtoarei sintaxe:
Body denn-metod ( )
n
d d d , , .
2 1
in class den-clas
unde:
- partea mai pronunat reprezint cuvinte rezervate;
-
n
d d d , , ,
2 1
reprezint lista de parametrii formali de comunicare.
Implementarea este inclus ntr-un bloc de iniializare delimitat de cuvntul cheie
CO2 i terminat cu simbolul $.
Cuvntul self are semnificaia de variabil de adres ce indic obiectul clasei int
la care metoda se aplic. Cu alte cuvinte, invocarea unei metode pe un obiect dat este
similar cu trimiterea unui mesaj la acel object; self indicnd obiectul primitor, adic
obiectul ce va primi mesajul.
Simbolul este echivalent cu semnificaia punctului () folosit frecvent i n alte
limbaje de programare n scopul de a face o calificare de atribut/cmp, cu ocazia unei
anumite referire la acel atribut. Exemplul:
self Nume-persoan = Nume-paremetru
echivaleaz cu descrierea de forma:
self Nume-persoan = Nume-parametru
unde atributul / cmpul Nume-persoan de la variabila self este iniializat cu o valoare dat
de atributul / cmpul Nume-parametru.

Urmrind cele dou aspecte referitoare la metode i anume, semntura i
implementarea metodei, observm c ambele presupun precizarea unei liste de parametri. Cu
privire la cele dou liste de parametri
i
p i
i
d se pot face anumite precizri, astfel:
- parametrii
i
p poart denumirea de parametri efectivi sau actuali, respectiv
parametri
i
d poart denumirea de parametrii formali;
- o parte dintre parametri efectivi i formali pot avea semnificaia de parametri de
intrare pentru metod, iar, o parte pot fi parametrii de ieire prin care metoda
returneaz rezultatele;

- cele dou liste ofer suportul pentru asigurarea comunicrii ntre semntur i
implementare, n sensul c prin listele de parametrii se transfera datele (valorile)
solicitate de metod;
- corespondena dintre parametrii n i p
i
, , 2 , 1 , = i n i d
i
, , 2 , 1 , = , se face prin
locul ocupat n lista de parametri i nu prin numerele lor; ntr-o astfel de situaie
denumirile parametrilor
i
p i
i
d pot s coincid sau s difere, ns numrul
parametrilor n cele dou liste, precum i tipul lor trebuie s fie acelai.
Necesitatea acestei identiti rezult din faptul c numai parametrilor
n i p
i
, , 2 , 1 , = li se rezerv memorie, parametrii
i
d utilizeaz aceleai zone de
memorie ca i
i
p .

Invocarea metodei init, ntr-un program scris n CO2 apare astfel:
execute CO2
{O2 Universitate X;
X = new (Universitate);
[X init (ASE, Roca, Bucureti, Roman, 1)];}$

unde:
- execute CO2 marcheaz lansarea n execuie a metodei init;
- pentru declararea variabilelor locale se folosete cuvntul cheie CO2;
- linia a doua de program definete o variabil local cu denumirea X i un tip
Universitate;
- linia a treia definete instruciunea de crearea a unui obiect ce aparine clasei
Universitate, invocnd totodat metoda new, metod valabil tuturor claselor
pentru crearea unui nou obiect i inserarea acestuia ntr-o clas
corespunztoare;
- instruciunea de pe linia final a metodei init aplicat la acel obiect, atribuie
valori iniiale proprietilor obiectului nou creat. Se poate observa c n
apelarea metodei se indic obiectul int i numele metodei, urmat de o list
de valori actuale ale parametrilor de intrare.
La sfritul execuiei metodei, obiectul pentru care metoda nsi este invocat este
returnat ca un parametru de ieire.
De remarcat faptul c n cadrul unei metode poate fi invocat i o alta metod,
existnd astfel posibilitatea de a se genera invocri de lanuri de metode, cu precizarea c nu
este permis ca o metod s se invoce pe sine nsi n mod direct sau indirect.

7.6.5.3. Considerente de ordin practic cu privire la proiectarea metodelor

Unul dintre principalele avantaje ale programrii orientate obiect l constituie
posibilitatea reutilizrii n mod facil a anumitor pri sau componente software. Dac
metodele vor fi definite /proiectate cu mare grij, atunci pri de programe sau programe
ntregi vor fi concepute o singur dat, ns vor putea fi incluse n metode i apoi folosite de
diverse aplicaii. Pentru a proiecta astfel de metode este de dorit s se in seama de o serie
de considerente de ordin practic [71,81,22], cum ar fi:
- Metodele trebuie s fie scurte; ele nu trebuie s depeasc circa dou pagini de
text. Metodele mai lungi este de preferat s fie descompuse;
- Metodele trebuie s fie coerente i consecvente n folosirea notaiilor sau a unui
stil comun de definire a denumirilor de variabile;
Capitolul 7
172
- Metodele trebuie s constituie cerine anticipate pentru viitoarele aplicaii i chiar
mai mult dect att, ele nu trebuie s se limiteze la satisfacerea unor cerine
minimale pentru aplicaii curente ci ele vor fi mai largi, de o ntindere mai mare i
vor include cazuri generale.
- Metodele vor fi independente. Ele vor folosi informaii definite local sau
acceptate ca parametrii, evitnd folosirea variabilelor globale;
- Motenirea va fi folosit ct mai mult posibil. Este de preferat ca metodele s fie
definite n superclase i refolosite n subclase de obiecte.

7.6.6. ncapsularea i interfaa

Operaiile formeaz interfaa clasei pentru ca prin intermediul ei clasa i expune
altor clase funcionalitatea fr s i dezvluie structura. Aceast tehnic de ascundere a
detaliilor de implementare a unui obiect poart numele de ncapsulare. Se ascunde att
structura care memoreaz datele ct i implementarea operaiilor. Deci, pentru un utilizator
oarecare clasa de obiecte, sub aspectul coninutului informaional, apare ca o cutie neagr.
Utilizatorii au acces la date prin interfee sau mesaje. Interfaa nu este nimic altceva dect un
mesaj / stimul prin care se citeaz denumirea unei metode dintre multiplele metode ale unei
clase de obiecte. Deci, operaii care arat numai ceea ce face obiectul, nu i cum face.
Denumirea unei metode reprezint tocmai denumirea unei proceduri elaborate ntr-un
limbaj de programare oarecare. Prin citarea denumirii metodei va fi lansat n execuie
programul care n derularea lui va accesa datele conform structurii clasei de obiecte, figura
7.10.

Fig. 7.10. Exemplu de ncapsulare

Asupra metodelor i atributelor unei clase de obiecte pot fi instituite anumite restricii
de acces la ele, care mai poart denumirea de restricii de vizibilitate. n funcie de modul de
restricionare instituit, vizibilitatea poate fi: public, privat, i protejat.
Forma implicit de vizibilitate este public (PUBLIC), situaie n care vizibilitatea i
atributele sunt vizibile pentru toi utilizatorii autorizai, i se noteaz cu semnul (+).
Forma privat (PRIVATE) marcat prin semnul (-), restricioneaz n totalitate
vizibilitatea altor clase. Atributele i metodele sunt vizibile numai nuntrul clasei ce conine
restricia.
FACTURA
- Data-emiterii: Date
- Emitent: string
- Material: string
.
.
.
+ Emite - factura()
+ ncaseaz - factura()
+ ncasare - parial()
+ Calculeaz - factura()

proprieti
metode
mesaj

Forma protejat (PROTECTED), notat cu simbolul (#), restricioneaz doar parial
vizibilitatea. Atributele i metodele protejate sunt vizibile att din interiorul clasei n care se
definesc ct i din toate celelalte subclase ce-i aparin.
Precizm i faptul c, o metod invocat poate invoca la rndul ei o alt metod
dintr-o alt clas, deci apeluri in cascad. Situaia este similar cu lucrul cu programe
principale i apelri de subprograme de tip Procedur sau Funcie, din alte limbaje de
programare.

7.6.7. Polimorfismul

Polimorfismul presupune faptul c un acelai mesaj poate fi adresat uneia sau mai
multor clase de obiecte primind rspunsuri diferite, cu semnificaii diferite. Exemplu,
presupunem drept mesaj comanda PRINT, din meniul de sistem. Ea va avea ca efect
imprimarea unei figuri geometrice dac se adreseaz unui fiier (prin analogie clase) de
figuri; va imprima un text preselectat dintr-un fiier de tip text etc.

7.6.8. Asocierile ntre clase

Legtura este o conexiune ntre obiecte. Asocierea reprezint descrierea unui grup de
legturi cu aceiai structur i semantic. Legturile sunt abstractizate n asocieri aa cum
obiectele sunt abstractizate n clase. Deoarece legturile dintre obiecte sunt instane ale
asocierii dintre dou clase, este util s se modeleze asocierile dintre clase i nu legturile
dintre obiectele acestora.
Asocierile prezint o serie de caracteristici, astfel:

Denumirea asocierii. O asociere dintre dou clase este reprezentat printr-o linie care
conecteaz dou clase (fig. 7.11). Denumirea asocierii, este de regul un verb care se
trece deasupra liniei, indicnd semnificaia asocierii, iar prin sgei se precizeaz sensul
asocierii. Denumirea trebuie s fie ct mai sugestiv.

Fig. 7.11. Reprezentarea asocierii

n cele ce urmeaz vom enumera cteva exemplificri de verbe ce pot indica
asocierea ntre clase de obiecte.

Categorie de verb Exemple de asociere
A e parte fizic din B salcurs - corpcldire
A e fizic coninut n B elev - clas / sal
A e logic coninut n B sal - orar
A e o descriere pentru B pagin web - pagin web Hotel
A e un rnd dintr-un raport B articol - comand
A este membru a lui B juctor - echip
A este o subunitate organizatoric a lui B atelier - secie
Numeclas Numeclas
nume asociere
Capitolul 7
174
A este subaltern a lui B angajat - manager
A conduce B ofer - main
A comunic cu B profesor - student
A este legat la o tranzacie B pasager - bilet
A este o tranzacie n legtur cu o alt
tranzacie
rezervare - anulare
A aparine lui B autoturism - proprietar

Aceste exemplificri ajut n alegerea / definirea ct mai sugestiv a denumirii
asocierii.

Multiplicitatea asocierii. Multiplicitatea reprezint numrul de instane ale unei clase
care pot avea legturi cu o instan a celeilalte clase dintr-o asociere. Multiplicitatea
corespunde cardinalitii asocierilor n raport cu instanele claselor. Ea poate fi de mai multe
feluri i poate comporta multiple forme de notare. n continuare se redau dou dintre acestea.

Varianta 1

Multiplicitatea unei asocieri se exprim printr-un interval de valori de forma (x,y)
unde x reprezint valoare minim, iar y valoarea maxim.

Exemple:
Legtura de tipul unu la unu. Specificul legturilor de tipul unu la unu const n
faptul c fiecare instan are n coresponden obligatoriu o alt instan din clasa cu care
intr n asociere.

O instan din clasa A are ntotdeauna n
coresponden o instan din clasa B (unu la
unu)
1,1
O instan din clasa A poate avea 0 sau 1
instane n corespondena din clasa B (unu la
zero sau unu)
O instan din clasa A poate s aib 0 sau N
corespondene de instane din B (unu la zero
sau mai muli).
O instan din clasa A poate avea 1 sau N
corespondene de instane din B (unu la unu
sau mai muli)
0,-
A B
A B
A B
A B
0,1
1,-


Sugereaz faptul c o localitate poate avea unul i numai un singur primar, iar n sens
invers o persoan poate fi primar la una i numai la o localitate.

Legtura de tipul unu la zero sau unu. Specificul acestui tip de legtur const n
faptul c o instan din clasa A poate avea sau nu coresponden unei instane din clasa B.

Sugereaz faptul c un partid politic poate avea minim 500 de persoane sau mai
multe, ns o persoan poate s nu fac parte din nici un partid, sau s fac parte din cel mult
un partid.

Legtura de tipul unu la zero sau mai muli

O altfel de legtur exprim faptul c la un curs facultativ poate s nu fie nscris nici
un student sau pot s fie mai muli studeni pentru frecventare.

Legtura de tipul muli la muli

Legtura de tipul muli la muli de mai sus exprim faptul c un material poate fi
livrat de unul sau mai muli furnizori, iar un furnizor poate livra unul sau mai multe
materiale.
O multiplicitate de forma (2,5) semnific faptul c la realizarea legturii pot participa
minim 2 i maxim 5 instane dintr-o clas de obiecte. Cnd limita superioar a intervalului
este ,,- nseamn c avem de-a face cu o limit superioar infinit.

MATERII PRIME FURNIZORI
1,-
1,- sunt furnizate de
furnizeaz
CURS FACULTATIV STUDENT
0,-
0,- are nscrii
urmeaz
PERSOANA PARTID
500,-
0,1 este nscris n
are
LOCALITATE PRIMAR
1,1
1,1
este primar la
are
Capitolul 7
176
Varianta 2

Tipul asocierii. Tipul asocierii este dat de numrul claselor participante la o asociere
exist mai multe tipuri de asocieri: unare, binare, ternare .a.m.d. Acestea pot fi notate astfel:

Asocierea unar, presupune faptul c a o clas de obiecte intr n asociere cu ea
nsi. O astfel de asociere este recursiv.

Exemplu: Presupunem o clas numit PERSOANE, la nivelul unei societi
comerciale. n cadrul acestei clase poate fi definit o asociere cu denumirea CSTORIE,
astfel nct s se poat da rspuns la o ntrebare de genul ,,Care sunt persoanele so soie ce
lucreaz n aceeai societate comercial? O astfel de asociere este redat n figura 7.12.

Fig. 7.12. Exemplu de asociere unar

Asocierea binar, presupune existena a dou clase de obiecte de forma (figura 7.13):
0,1 0,1
are soie are so
A B
O instan din clasa A are n coresponden o
instan din clasa B (unu la unu)
A B
O instan din clasa A poate avea 0 sau 1
instane n corespondena din clasa B (unu la
zero sau unu)
A B
O instan din clasa A poate s aib 0 sau N
corespondene de instane din B (unu la zero
sau mai muli).
A B
O instan din clasa A poate avea 1 sau N
corespondene de instane din B (unu la unu
sau mai muli)
0..1
*
1..*
A B
A B
5
O instan din clasa A poate avea n
coresponden exact 5 instane din B
3,5,8
O instan din clsa A poate avea n
coreponden exact 3, 5 sau 8 instane din
clasa B
PERSOANE
CSTORIE



Fig. 7.13. Exemplu de asociere binar

Interpretarea asocierii din figura 7.13 apare astfel: un salariat poate fi angajat cel
puin ntr-un departament i cel mult ntr-un departament. n sens invers, ntr-un departament
pot lucra unul sau mai muli salariai.

Asocierea ternar, presupune existena a trei clase de obiecte. n figura 7.14 se
prezint forma generic a unei astfel de asocieri.

Fig. 7.14. Exemplu general de asociere ternar

Un exemplu pentru reliefarea asocierii ternare este prezentat n figura7.15

Fig. 7.15 Exemplu concret de asociere ternar

Asocierea ,,mprumut este o asociere ntre trei clase: Client, Banc i Investiie,
banca acordnd mprumutul unui client pentru o anumit investiie. Se observ c asocierea
,,mprumut nu poate fi divizat n asocieri ntre dou clase fr a pierde din informaie.

Rolul clasei n cadrul asocierii. Prin rol se indic semnificaia fiecrei clase n cadrul
asocierii. Numele de rol este un concept prin care se identific n mod unic capetele unei
asocieri. O clas, care are mai mult de o asociere, poate juca roluri diferite fa de fiecare
dintre acestea.

Client
Banc
mprumut
Investiie
SALARIAT DEPARTAMENT
1,-
1,1
Nume clas 1
Nume clas 2
Nume
asociere
Nume clas 3
are
angajat n
Capitolul 7
178

Fig. 7.16. Evidenierea rolului fiecrei clase

n figura 7.16 se poate observa c un utilaj, din punct de vedere al bncii, poate
reprezenta o garanie, n timp ce din punct de vedere al firmei, el reprezint un mijloc de
producie. Numele de rol se reprezint prin intermediul unei etichete ataat captului
asocierii. Firma are rolul de proprietar de utilaj.

Atribute i clase ale asocierii. Cnd o asociere are atribute i operaii proprii, sau
cnd particip la asocieri cu alte clase, asocierea se modeleaz ca o clas i poart numele de
clas a asocierii (figura 7.17).
Asocierea dintre clasele mprumut i Banca este caracterizat de urmtoarele
atribute: suma mprumutat, data acordrii mprumutului, data rambursrii mprumutului,
dobnd i operaia de rambursare mprumut. Toate aceste atribute i operaii sunt atribute i
operaii ale asocierii i vor fi reunite n clasa mprumut; ele nu aparin n totalitate nici clasei
Client i nici clasei Banca ci aparin ambelor clase.

Fig. 7.17. Exemplu de asociere cu atribute i operaii

Atribut derivat. Un atribut derivat este un atribut care poate fi calculat sau derivat
plecnd de la alte atribute. Un astfel de atribut se reprezint grafic prin simbolul / pus n
faa denumirii acestuia.
Firm
Proprietar
Mijloc de
producie
Utilaj
deine
Banc
Garanie
1,n
1,n
Client Banc
1,- 1,-
mprumut
Sum mprumut
Data mprumut
Data rambursare
Dobnda
Rambursare ( )


Fig. 7.18. Reprezentarea unui atribut derivat

n figura 7.18. atributul Vrsta este un atribut derivat al clasei Student, ntruct se
poate calcula plecnd de la atributul Data Natere i data curent.

Atribut al clasei. Obiectele se difereniaz ntre ele prin valorile pe care le iau
atributele lor la un moment dat, valori care constituie starea obiectului n acel moment. O
categorie special de atribute sunt atributele clasei.
Un atribut al clasei reprezint un atribut a crui valoare este comun clasei de obiecte
i nu unei instane specifice. Simbolul folosit pentru acest tip atribut este caracterul $
plasat n faa denumirii atributului, aa cum se poate observa n figura 7.19

Fig. 7.19. Atribut al clasei

Clasa Factura, pe lng atributele specifice unei facturi cum ar fi data emiterii,
valoare fr TVA, TVA, valoare cu TVA etc., are i atributul NrTotalFacturi care este o
caracteristic a clasei i nu a instanei.

Ordonare. n cazul unei asocieri n care la unul din capete se specifica ,,muli, setul
de obiecte poate s nu fie ordonat (fiind ca un set de obiecte), sau poate fi ordonat explicit.
Mesajul ordonrii n cazul cnd acest lucru este important, se face prin meniunea {ordered}
lng semnul care indic multiplicitatea. Ordonarea este un tip special de constrngere
aplicabil asocierilor. S lum exemplul alctuit din clasele Ghieu i Persoan (figura 7.20).

Fig. 7.20. Ordonarea ntr-o asociere

Calificarea. Numim asociere calificat o asociere, care leag dou clase, i un
calificator, care are rolul de a reduce multiplicitatea efectiv a unei asocieri. Asocierile de
tipul ,,unul la muli i ,,muli la muli trebuie s fie calificate. Calificarea permite ca din
multitudinea de obiecte aflate la captul ,,muli al asocierii s se identifice unic un anumit
Ghieu Persoan
{ordered}
1,n
deservete
Student
Nume
Data Natere
/Vrsta
Factura
.
$ Nr.TotalFacturi
.

Capitolul 7
180
obiect. Considernd exemplul alctuit din clasele Furnizor i Contracte i asocierea ncheie,
vom aveam o relaie ,,unu la muli; un furnizor ncheie unul sau mai multe contracte iar un
contract nu poate fi ncheiat dect cu un singur furnizor. Calificatorul cod_furnizor permite
reducerea asocierii ,,unu la muli la o asociere ,,unu la unu, ntruct un furnizor i un
numr de contract permit identificarea unic a unui furnizor (figura 7.21):

Fig. 7.21. Calificarea asocierii

7.6.9. Motenirea

Motenirea este un mecanism ce d posibilitatea partajrii atributelor i operaiilor
utiliznd relaia de generalizare. Motenirea poate fi redat astfel: (figura 7.22.):

Fig. 7.22. Motenirea

Motenirea poate fi simpl sau multipl. Motenirea simpl presupune faptul c o
subclas B motenete proprietile i comportamentul doar de la o singur superclas A
(este cazul din figura 7.22.).
Motenirea multipl presupune faptul c o subclas B poate moteni proprietile i
comportamentul de la dou sau mai multe superclase, aa dup cum reiese din figura 7.23.
Se observ c subclasa E motenete proprietile i comportamentul att de la
superclasa A ct i de la B. Clasele constituite special pentru a fi motenite se numesc clase
abstracte i acestea nu au instane, iar numele lor se scrie cu format cursiv (italic ). O clas
construit pentru a crea instane se numete clas concret. Clasele abstracte conin cel puin
o operaie abstract, adic o operaie neimplementat i care urmeaz s fie implementat n
clasele descendente.
Motenirea ofer marele avantaj cu privire la reutilizarea codului i definirea de
ierarhii de clase. n acest mod sporete considerabil de mult productivitatea muncii n
activitatea de programare.

FURNIZORI CONTRACTE Cod_furnizor
FURNIZORI CONTRACTE
ncheie
1..*
cu semnificaia c o clas B motenete de la o
alt clas A proprietile i comportamentul
A
B
ncheiat
1


Fig. 7.23 Exemplu de motenire multipl

7.6.10. Generalizarea i specializarea

Generalizarea i specializarea sunt mecanisme care permit partajarea caracteristicilor
comune ntre clase, pstrnd totodat diferenele dintre acestea. Generalizarea presupune
identificarea atributelor i/sau operaiilor comune mai multor clase i izolarea lor n
superclase. Specializarea claselor este opus generalizrii i are ca punct de plecare o
superclas ce urmeaz a fi descompusa in subclase si la care se pot adaug noi atribute i/sau
operaii relevante numai pentru anumite obiecte din acea clas, crend astfel subclase de
obiecte. Atributele i operaiile superclasei nu mai apar n cadrul subclaselor ataate ei, dar
ele aparin acestora prin motenire. n subclase se descriu numai atributele i/sau operaiile
specifice fiecruia dintre ele. Subclasa rafineaz, specializeaz clasa. Superclasele i
subclasele se mai numesc prini / copii sau strmoi / descendeni. n figura 7.24 se prezint
operaiile de generalizare si specializare.
Un alt exemplu extrem de sugestiv l-ar putea constitui mulimea studenilor din
cadrul unei universiti. Studenii ar putea fi privii ca formnd o singur colectivitate (clas)
la nivelul ntregii universiti i apoi pe subcolectiviti (subclase) n funcie de specializarea
urmat (faculti i secii), deci subclase, ca n figura 7.25.
STUDENTI-ASE apare ca o superclas ce conine proprietile i comportamentul
comun tuturor studenilor, apoi la nivelul fiecrei subclase se precizeaz doar ceea ce i este
specific fiecrei subclase i care permite diferenierea subclaselor.
Se poate deduce faptul c pentru generalizare se pleac de la nite clase deja
existente, din care vor fi desprinse aspectele comune claselor, definind cu acestea o
superclas, iar specializarea presupune existena unei singure clase din care vor fi desprinse
specializri.
De remarcat faptul c generalizarea se implementeaz prin relaia de motenire ns
n cadrul limbajelor de programare orientate obiect, ea capt un aspect mai abstract.
Avantajele utilizrii generalizrii sunt urmtoarele:
- Reutilizarea codului n proiectul n lucru pot fi folosite clase create n cadrul
altor proiecte;
- Standardizarea aspectele comune sunt specificate o singur dat;
- Calitatea superioar reutilizarea claselor create pentru alte proiecte presupune i
faptul c ele au fost testate deja n cadrul acelor proiecte.

A B
C D E F G
H I
Capitolul 7
182

Fig. 7.24. Generalizarea si specializarea

Fig. 7.25. Exemplu 2 de generalizare/specializare

7.6.11. Agregarea, compunerea i descompunerea

Agregarea i descompunerea sunt operaii care permit reprezentarea relaiilor de tipul
parte-ntreg dintre obiecte. Agregarea descrie un obiect ca fiind constituit din mai multe
obiecte. De asemenea, agregarea se folosete la gruparea claselor ntr-o nou clas. Ea este
folosit la construcia unui obiect complex prin compunerea lui din prile componente.
Agregarea este un tip special de asociere ntre o clas ntreg i una sau mai multe clase
parte (figura 7.26.).

STUDENI - ASE
STUDENI
REI
STUDENI
CSIE
STUDENI
MANAGEMENT
. . .
INFORMATIC CIBERNETIC STATISTIC
CLASA 1
Atribute comune
Operaii comune
CLASA 2
Atribute specifice
Operaii specifice
CLASA 3
Atribute specifice
Operaii specifice
Subclas
Subclas
Superclas
generalizare specializare


Fig. 7.26. Agregare, descompunere

Agregarea i compunerea se reprezint grafic prin intermediul unui romb. Un romb
plin semnific o relaie de compunere. ntr-o relaie de compunere, spre deosebire de relaia
de agregare, obiectul parte aparine unui singur obiect ntreg, de exemplu, o camer este
parte a unei singure cldiri, din aceast cauz multiplicitatea prii ntreg dintr-o astfel de
relaie este ntotdeauna 1. Un alt exemplu de agregare si descompunere este redat n figura
7.27.

Fig. 7.27. Exemplu de agregare i descompunere

Universitate
Uniti
administrative
Secii
Cldire
Camere Departamente
1, - 1 , -
1
1
1 1
1, - 1, -
TRACTOR
ROI
Agregare Explozie
MOTOR CABINA . . .

CARBURATOR CILINDRII PISTOANE . . .
Implozie Descompunere

Capitolul 7
184
7.7. Standardul ODMG pentru baze de date
orientate obiect

7.7.1. Aspecte generale referitoare la standardizare

n condiiile exploziei informaionale cu privire la abordarea obiectual n domeniul
informaticii, pentru a veni in sprijinul realizatorilor i utilizatorilor de astfel de produse
software i hardware s-a conturat din ce n ce mai mult preocuparea pentru elaborarea unor
standarde n acest domeniu de interes. Astfel, n 1989 s-a format OMG (Object Management
Group) ca un consoriu non-profit avnd ca principal scop promovarea orientrii spre obiecte
n ingineria programrii i dezvoltarea de standarde. Grupul reuete peste 700 de uniti
membre, ce includ aproape toi realizatorii de produse software i hardware din lume, cum ar
fi: Microsoft, ORACLE, IBM, SAP, SUN, Apple, NCR, DEC, Hewlett-Packard, Object
Design Inc., Objectivity etc.
De remarcat faptul c OMG nu este un grup sau organizaie recunoscut pentru
standarde aa cum sunt: Organizaia Internaional de Standardizare (ISO), Institutul
Naional American pentru Standarde (ANSI) sau Institutul de Inginerie Electric i
Electronic (IEEE) ci Consoriul OMG face propuneri de Standarde care ulterior sunt
supuse spre acceptare de ISO sau ANSI.
Dintre realizrile consoriului OMG precizm faptul c n anul 1990 a elaborat i
publicat o documentaie intitulat Object Management Arhitecture Guide. Ghidul are
menirea de a specifica:
- o terminologie unitar pentru limbaje, sisteme i baze de date orientate obiect;
- un cadru abstract pentru sistemele orientate spre obiecte;
- un set de scopuri tehnice i arhitecturale;
- un model de referin pentru aplicaiile distribuite utiliznd tehnicile orientrii
spre obiecte.
n cadrul modelului de referin pentru aplicaii distribuite au fost identificate
urmtoarele domenii ale standardizrii:
- modelul de obiecte OM (Object Model);
- brockerul de cereri de obiecte ORB (Object Request Brooker), pe baza cruia s-a
definit Arhitectura brockerului de cereri comune cunoscut sub denumirea de
CORBA (Common Request Brocker Arhitecture);
- serviciile de obiecte (memorare, administrarea tranzaciilor, integrrii, realizarea
versiunilor i securitatea sistemului);
- faciliti comune (help, E-mail i browser).

n 1989 civa productori de software pentru baze de date s-au reunit i au format un
grup pentru administrarea bazelor de date orientate obiect ODMG Object Database
Management Grup, avnd ca obiectiv de a defini standarde pentru SGBDOO. Din cadrul
grupului faceau parte productorii: Gemstone Systems, Object Design, O2 Technology,
Versant Object Technology, UniSQL, POET Software, Objectivity, IBEX Computing SA,
Lockheed Martin, Ontos, Servio, Hewlett-Packard, etc.
Grupul de lucru a conceput un model standard incluznd urmtoarele componente
pentru SGBDOO:
- modelul de obiecte (OM),

- limbajul de definire a obiectelor (ODL Object Definition Language),
- limbajul de interogare a obiectelor (OQL Object Query Language),
- interfa cu limbajul C++,
- interfa cu limbajul Smalltalk,
- interfa cu limbajul Java.
Actualmente, sistemele comercializate ce suport standardul ODMG 3.0 includ
GemStone (http://www.gemstone.com), Objectstore (http://www.odi.com.), Poet
(http://www.poet.com) etc.
n cele ce urmeaz ne propunem s facem o trecere n revist doar a primelor trei
componente iar pentru celelalte trei recomandm cititorilor interesai cteva surse mai
nsemnate de documentare (www.odmg).

7.7.2. Modelul de obiecte

Modelul ODMG de obiecte reprezint un superset al modelului OMG de obiecte,
urmrind n mod deosebit de a asigura portabilitatea proiectrii i implementrii aplicaiilor
pe diverse SGBDOO care accept modelul de obiecte.
Elementele fundamentale care constituie suportul pentru modelare sunt:
- Modelul ODMG este bazat pe obiecte, fiecare obiect avnd un identificator unic;
- Obiectele pot fi clasificate n tipuri. Multitudinea obiectelor de un tip dat prezint
un comportament i o stare comun;
- Starea obiectului este dat de valorile pe care le iau proprietile obiectului. O
proprietate poate fi un atribut sau o relaie dintre unul sau mai multe alte obiecte;
- Multitudinea operaiilor pe care le poate efectua un obiect sau alte obiecte asupra
lui implementate ntr-un limbaj oarecare de programare poart denumirea de
metod;
- Multitudinea metodelor aparinnd unui obiect definesc comportamentul acelui
obiect;
- Fiecare metod este nsoit de o semntur prin care se precizeaz denumirea
operaiei, denumirea i tipul tuturor parametrilor de intrarea i ieire i situaii de
excepie ce pot interveni (condiii de eroare);
- Baza de date ce stocheaz obiectele n concordan cu schema acestuia, descris
cu ajutorul unui limbaj de definirea a obiectelor (ODL).
Despre toate aceste elemente fundamentale gsim detalii n paragrafele anterioare,
precum i alte lucrri de referin [4,19,30,51].

7.7.3. Limbajul de definire a obiectelor

Limbajul de definire a obiectivelor ODL (Object Definition Language) este destinat
descrierii schemei bazei de date orientate obiect. El descrie tipuri i nu clase i este
independent de limbajul de programare ales pentru implementarea claselor. El definete
atributele, relaiile dintre tipuri i specific semntura operaiilor (metodelor). De reinut
faptul c el nu se refer la implementarea semnturilor. ODL a fost conceput de ODMG.
Sintaxa ODL se bazeaz pe limbajul de Definire a Interfeei IDL (Interface Definition
Language), fiind o extensie a acestuia. IDL aparine OMG-ului i este parte integrant a lui
CORBA (Common Object Request Broker).
Capitolul 7
186
ODMG a ales IDL ca baz de referin, n loc de a inventa o nou sintax, pe
considerentul c prin aceast alegere se asigur un grad sporit de compatibilitate cu
recunoscutul i importantul standard CORBA pentru sisteme de baze de date distribuite.
Terminologia utilizat n ODL difer n anumite privine de cea utilizat de CODM.
Aceast diferen i gsete explicaia, ntr-o oarecare msur, tocmai n obiectivul urmrit
de ODMG i anume acela de a asigura o maximizare a portabilitii schemei de date pentru
mai multe limbaje de programare.
Ideea avut n vedere de ODMG const n faptul c schema bazei de date definit de
ODL trebuia s permit accesarea obiectelor n mai multe limbaje de programare gazd.
Acest lucru, pentru moment, este posibil n limbajele C++, Java i Smalltalk.
n semnificaia ODMG, pentru fiecare legtur cu limbajele de programare gazd se
prevede extinderea documentaiei sau adaptarea acesteia n contextul respectrii structurii
comune ODMG.
Comunicarea se face printr-un set de variabile din limbajul gazd i un preprocesor
special care modific cadrul surs pentru a nlocui afirmaiile ODL cu apelri la rutinele
SGBD. Codul surs poate fi apoi compilat i linkeditat n mod normal.
Faptul c ODL definete tipuri ce pot fi implementate n numeroase limbaje de
programare ofer numeroase avantaje, astfel:
- ODL permite ca o aceeai baz de date s fie partajat pe multiple limbaje de
programare, sau cu alte cuvinte, o aceeai aplicaie s fie portabil pe numeroase
limbaje de programare fr rescrierea definirii schemei bazei de date.
- ODL este utilizat pentru analiza i conceperea schemei bazei de date naintea
descrierii datelor i operaiilor unei aplicaii independent de un limbaj de
programare. Concepia rezultat poate fi utilizat fie n mod direct fie translatat
ntr-un limbaj de descriere a datelor ales de programator;
- Schema descris n ODL este acceptat de toate SGBD compatibile cu concepia
ODMG.
De remarcat faptul c nu este posibil ntotdeauna obinerea unei compatibiliti de
100% a schemei bazei de date cu alte produse software, datorit unor diferenieri intrinseci a
modelelor limbajelor de programare. Deci, ODL va comporta coloratura i specificul
limbajului gazd cu care realizeaz legtura.
De exemplu, n cazul legturii cu Java, ODL distinge dou feluri de clase. Prima este
numit interfa iar a doua clas. Pentru a evita confuzia cu clasele CODM recurge la
numirea acestora interfa ODMG i respectiv clas ODMG.
n termenii CODM, definiia interfeei i clasei ODMG specific:
- un nume de clas (n sens CODM) mpreun cu partea relevant a ierarhiei de
motenire;
- un tip asociat clasei de referin.
O colecie de astfel de definiii specific schema ntregii baze de date ODMG.

Principalele diferene dintre interfeele ODMG i clasele ODMG sunt:
- O interfa ODMG nu poate include codul (programul) pentru metode; ceea ce
nseamn ca sunt permise doar semnturile metodei, acest aspect constituie
tocmai motivul pentru care se numete interfa. Clasele ODMG includ codul
pentru metodele claselor de referin. Semntura i codul pot fi explicit
specificate prin folosirea unui limbaj gazd sau pot fi motenite de la o clas din
cadrul unei ierarhii de clase de obiecte;
- O interfa ODMG nu poate avea propriile ei obiecte membre, adic instanele de
obiecte ale interfeei nu pot fi create. Din contr, o clas ODMG poate avea
obiecte membre;

- O interfa ODMG nu poate moteni dintr-o clas ODMG dar poate moteni doar
din alt interfa ODMG;
- O clas ODMG poate moteni din multiple interfee ODMG dar nu poate avea
dect cel mult o superclas ODMG imediat.
Distincia dintre clase i interfee se face din urmtoarele dou considerente:
- n primul rnd aceast distincie face ODL-ul un superset al IDL-ului CORBA,
prin aceasta asigurnd un grad sporit de compatibilitate cu acest important
standard pentru sisteme distribuite.
- n al doilea rnd aceast difereniere permite ODL-ului s depeasc cteva
dintre problemele asociate cu motenirea multipl care apare cnd o clas
motenete dou definiri diferite pentru o aceiai metod din superclase diferite.

Precizm faptul c o prezentare complet a sintaxei unui limbaj ODL depete
scopul acestei cri. Totui, urmtorul exemplu va ilustra unele elemente ale limbajului.
Cititorului interesat i recomandm, pentru o definiie complet a ODL-ului, s consulte [11].
Pentru exemplificarea modului de utilizare a ODL ne vom referi la schema parial
prezentat n figura 7.3.
Interface UNIVERSITATE { // Definete interfaa pentru
// entitatea Universitate
/- Urmeaz definirea atributelor -/
atribute string Denumire;
atribute structure Nume-rector (string nume, string prenume);
atribute string Ora;
atribute string Strada;
atribute Set < string > Numr-telefon;
/- Urmeaz definirea relaiilor -/
relationship BIBLIOTECA are
inverse BIBLIOTECA:: aparinede;
relationship PROFESOR are
inverse PROFESOR:: estela;
relationship LABORATOR dispunede
inverse LABORATOR:: aparinede;
/- Urmeaz definirea semnturilor -/
Void adaugunnounr.tel (in string Numr-telefon);
}
Interface FACULTATE: UNIVERSITATE // Definete interfaa pentru
// entitatea/obiectul Faculti
// care motenete obiectul
// Universitate
{
/- Urmeaz definirea atributelor/proprietilor -/
atribute string Nume-decan;
atribute string Ora
relationship Set <Catedr> coordoneaz
inverse Catedra :: coordonatde;
relationship Laborator folosete
inverse Laborator :: folosit_de ;
Capitolul 7
188
relationship Student urmat_de
inverse Student :: urmeaz;
}
Interface SECTIE: FACULTATE // Definete interfaa pentru
// obiectul secie care
// motenete obiectul
// Facultate
{
/- Urmeaz definirea atributelor/proprietilor -/
atribute string Nume-serii;
relationship STUDENT specializeaz
inverse STUDENT :: specialistin;
relationship CURS are
inverse CURS :: sepredla;}
Interface STUDENT // Definete interfaa pentru
// entitate/obiectul STUDENT
(extent STUDENT);
Key CNP)
{
struct Nume-Prenume (string nume, string prenume);
atribute Nume-Prenume nume;
atribute integer CNP;
atribute integer an-studii;
atribute string Adresa;
atribute date Datadenatere;
atribute enum genul { m, f} sex;
relationship FACULTATE urmeaz
inverse FACULTATE:: urmatde;
relationship SECIE specialist n
inverse SECIE:: specializeaz;
relationship CURS frecventeaz
inverse CURS:: frecventat de;
/- Urmeaz definirea operaiilor -/
nscrielacurslasecia (in CURS, in SECIE) raises;
(cererenesatisfcut, cursplin, nrlocuriocupate);
Void transferstudent (in from: SECIE, in to:
SECIE) raises (nuexistlocuridisponibile);
}
Interface CURS // Definete interfaa CURS
}
atribute integer codcurs;
atribute string Denumirecurs;
atribute integer Nrcredite;

relationship SECIE sepredla
inverse SECIE:: are;
relationship STUDENT frecventat_de
inverse STUDENT :: frecventeaz;
Void tergecurs ( ) raises (nu exist acest curs):
}
Interface LABORATOR // Definete interfaa LABORATOR
{
atribute string DenumireLaborator;

atribute string efLaborator;
relationship FACULTATE folositde
inverse FACULTATE:: folosete;
relationship UNIVERSITATE aparinede
inverse UNIVERSITATE :: dispunede;
Interface PROFESOR // Definete interfaa profesor
(extent PROFESORI;
KEYS CNP)
{
atribute integer CNP;
atribute string NUME-PRENUME;
atribute integer MARCA;
atribute string SPECIALIZAREA;
atribute enum grad-didactic { prof, conf, lector, asist};
atribute integer salariu;
relationship UNIVERSITATE estela
inverse UNIVERSITATE:: are;
relationship CATEDRA aparinede
inverse CATEDRA:: dispune de;
Void majoraresalariu (in float);
----------------------------------------------------------------------------------------------------
}

n cele ce urmeaz vom cuta s facem cteva precizri pe marginea exemplului de
utilizare a Limbajului de Definire a Obiectelor, astfel:
- Cuvntul cheie interface este utilizat pentru a defini o clas i a asigura
compatibilitatea cu OMG IDL. Pentru fiecare interfa se poate declara un
extent i specific anumite Keys. Extent-ul precizeaz denumirea pentru setul
curent de obiecte a acelei clase. El est analog cu instana unei relaii i interfaa
este analog schemei relaiei. Dac utilizatorul nu anticipeaz nevoia sa lucreze
cu seturi de obiecte ale unei clase date, deci c ar fi suficient s manipuleze
individual obiectele, atunci declararea Extent-ului poate fi omis. Distincia
dintre numele interfeei (i numele extent-ului ntr-un limbaj de definire a datelor
este mai degrab folosit din punctul de vedere al unui SGBD relaional. Deci,
Capitolul 7
190
ntrim precizarea c numele interfeei ar fi similar cu a da un nume schemei unei
relaii (folosind comanda CREATE TABLE nume) i un nume diferit instanei
relaiei actuale peste acea schem. Oricum, se apreciaz c din punctele de vedere
practic i conceptual, valoarea clauzei extent rmne o problem de discutat.
- Clauza Key specific faptul c extent-ul are o cheie cu o anumit denumire.
Exemplu, extent STUDENT are definit i o cheie cu denumirea CNP care nu
permite existena a dou instane cu o aceiai cheie n cadrul extent-ului.
- Proprietile claselor de obiecte sunt specificate utiliznd ODL i sunt de trei
feluri: atributele, relaii i metode.
- Atributele sunt definite ca fiind de tip integer, string, date, enum (pentru liste de
valori) etc.
- Relaiile dintre clasele de obiecte sunt specificate prin clauzele Relationships i
corespondena acesteia inverse relationships; deci observm c avem de a face
cu o definire bidirecional.
- La nivelul fiecrei interfee a fost precizat cu scop exemplificativ cte o
"semntur de metod, n cadrul crora apar specificate i situaiile de excepie
folosind clauza raises.
n cadrul descrierii structurii BDOO se mai pot desprinde i alte aspecte evideniate
prin comentarii.

7.7.4. Limbajul de cereri obiect OQL

Limbajul de cereri obiect (Object Query Language) constituie o extensie a SQL,
chiar dac asemnrile dintre cele dou limbaje sunt mai mult aparente dect reale, n mare
msur depind de utilizarea acelorai cuvinte-cheie.
OQL ca i SQL, este un limbaj pur pentru cereri. El nu include, de exemplu,
controlul structurilor. Din OQL este posibil s se invoce metode care sporesc puterea
expresiv a acestora. n mod curent OQL nu include primitive pentru actualizarea strii
obiectelor coninute n baza de date, aceste actualizri urmnd a se realiza cu ajutorul
metodelor .
De remarcat faptul c limbajul OQL iniial a fost elaborat pentru O2, apoi a fost
adaptat de ctre ODMG, printr-o serie de modificri, astfel nct actualmente este considerat
ca un limbaj de cereri standard pentru SGBDOO. El poate fi utilizat att ca un limbaj
autonom, ct i ca un limbaj nglobat n alt limbaj, pentru care este definit o legtur de tip
ODMG. Limbajele acceptate n mod curent de ctre OQL sunt Smalltalk, C++ i Java.
Totodat este de precizat faptul c limbajul OQL poate invoca operaii programate n
limbajele amintite anterior.
O cerere/interogare OQL este o funcie care furnizeaz un obiect, al crui tip poate fi
dedus din operatorul care contribuie la expresia de interogare. i de aceast dat facem
precizarea c rezultatul unei cereri OQL nu este obligatoriu s fie un obiect sau o tabel,
aceasta poate fi chiar un ntreg, o list de referin a obiectelor, o structur, un ansamblu de
numere reale sau ntreaga structur de date definind un obiect.
O interogare poate fi compus dintr-o mulime, posibil vid, de expresii, cum ar fi:
expresii de obiecte, de tip atomic, elementare, de definire a interogrii (de forma:
DEFINE Q AS e;
definete o interogare cu denumirea Q, pentru o expresie de interogare e dat), de mulimi
diverse, de conversii etc.
Expresiile pot fi compuse n diferite forme, cum ar fi: prin utilizarea cuantificatorului
universal (for all), cuantificarea existenial (exists), testul de apartenen (in), clauza select

from where, operatorul de sortare (sort), operatorii unari pentru mulimi (min, max, count,
sum, avg) i operatorul de grupare (group).
Formatul clauzei SELECT este foarte apropiat de cel din limbajul standard SQL, i
anume:
SELECT [DISTINCT] <expresie>
FROM <din-list>
[WHERE <extensie>]
[GROUP BY <atribute>]
[HAVING <predicat>]
[ORDER BY <expresie>]

unde, ntr-o form succesiv, elementele din clauza SELECT sunt definite astfel:
<din-list>:: = <denumire_variabil> IN <expresie>|
<denumire_variabil> IN <expresie>, <din-list>|
<expresie] AS <denumire_variabil>, <din-list>

n cele ce urmeaz vom cuta s oferim cteva exemplificri pentru a observa modul
de utilizare a limbajului OQL; referirile fcndu-se la structura bazei de date orientate obiect
din figura 7.3.

Exemplul 1, evideniaz faptul c nu ntotdeauna este necesar utilizarea clauzei
SELECT FROM WHERE; Este suficient a specifica doar:
STUDENT
Aceasta este o cerere complet i are ca efect obinerea / listarea tuturor studenilor (ca
obiecte cu identitate).

Exemplul 2, evideniaz modul n care este utilizat clauza DISTINCT din fraza
SELECT:
SELECT DISTINCT X.Adresa
FROM X IN STUDENT
WHERE X. Nume = IONESCU

are ca efect returnarea setului adreselor tuturor studenilor ce au numele de IONESCU. Mai
exact, datorit clauzei DISTINCT, se va returna o valoare de tip SET <ADRESE> n care
valoarea unei adrese apare o singur dat. Cu alte cuvinte, vor fi listate toate adresele la care
se afl studeni cu numele IONESCU, fiecare adres fiind luat o singur dat. n modelul
relaional, mai precis n algebra relaional, clauza DSTINCT are semnificaia de operator de
proiecie a relaiei STUDENI pe atributul Adresa.
Dac, n cererea de mai sus, ar fi omis clauza DISTINCT din fraza SELECT,
cererea ar returna o valoare de tip Bag <ADRESE>; un Bag de adrese este similar cu un
SET ns poate avea elemente duplicate.
Tipul SET vine cu metodele ncorporate nuntru, care d programatorului accesul la
elementele setului pentru a obine funcionalitatea asigurat de cursori n SQL
(identificator/pointer, cu ajutorul cruia se manipuleaz o zon de memorie alocat i
gestionat de sistem pentru a se executa o comand).

Exemplul 3 evideniaz modul de invocare a unei metode n faza SELECT:
SELECT T. adaug_un_nou_nr_tel (031_456789)
FROM T IN UNIVERSITATE
WHERE T. Denumire = A.S.E.
Capitolul 7
192

Are ca efect adugarea unui nou numr de telefon n setul de numere. Cererea
actualizeaz baza de date ns nu returneaz nimic apelantului metodei.

Exemplu 4 are ca scop evidenierea unei expresii de definire a unei interogri. Se
cere s se gseasc toi studenii ce au domiciliul stabil n Bucureti:

DEFINE Bucureteni AS
SELECT X
FROM X IN STUDENI
WHERE X.Adresa = Bucureti
SELECT X. Nume_Prenume.nume FROM X IN Bucureteni.

Exemplul 5 are ca scop evidenierea modului de creare/cunoatere a unui obiect.
Precizm faptul c OQL accept dou tipuri de obiecte n concepia modelului ODMG: cu
identitate sau mutabile, avnd un OID i fr identitate sau literali, fr OID, n funcie de
care difer i modul de creare sau selecie.
n cele ce urmeaz vom exemplifica modul de creare a unui obiect cu identitate:

PROFESOR (CNP: 1012644400237, NUME-PRENUME: BARBU DAN,
MARCA: 12233, SPECIALITATE: INFORMATIC,
GRAD-DIDACTIC: PROFESOR, SALARIU: 3500)

n situaia n care anumite proprieti/atribute nu sunt iniializate, ele vor lua valori
implicite.
Un obiect cu identitate mai poate fi creat/construit i n alte variante, dintre care una
ar poate fi aceea care presupune un tip obiect predefinit, care apoi se va iniializa cu valori
preluate prin selecie dintr-un alt tip de obiecte. Astfel, presupunem c ar prezenta interes de
a avea i pstra separat un tip/clas de obiecte referitoare la toate cadrele didactice avnd
specializarea informatic i descrise prin proprietile: CNP, NUME-PRENUME i
GRAD-DIDACTIC. ntr-o astfel de situaie, tipul de obiecte cu denumirea sugestiv de
INFORMATICIAN ar putea fi iniializat/populat cu valori preluate din tipul PROFESOR, de
forma:

INFORMATICIAN (SELECT STRUCT (CNP: X.CNP, NUME_PRENUME:
X.NUME_PRENUME, GRAD_DIDACTIC:
X.GRAD_DIDACTIC)
FROM X IN PROFESOR
WHERE X.SPECIALIZAREA = INFORMATIC)

Cazuri asemntoare regsim i n modelul relaional. Obiectele fr identitate sunt
create cu ajutorul tipurilor literale structurate, de forma:

STRUCT (a : 7, b : 10, c : BAZE DE DATE)
Deci, se creeaz o structur cu trei cmpuri a, b i c.


7.8. Sisteme de gestiune a bazelor de date orientate
obiect (SGBDOO)

n domeniul bazelor date orientate obiect pe piaa mondial au aprut o serie de
Sisteme de gestiune a bazelor de date orientate obiect. Unele dintre ele au rezistat timpului i
concurenei, altele au disprut. n cele ce urmeaz vom recurge la o prezentare a unora dintre
SGBDOO.

7.8.1. GEMSTOME

GEMSTOME este unul dintre primele i probabil cel mai pur sistem de gestiune a
bazelor de date orientate obiect care a existat ca produs comercial. Este construit pe o
extensie a lui Smalltalk numit OPAL.
Spre deosibire de ObjectStore, Ontos i Versant, care sunt strns legate de C++,
OPAL nu este strns legat de un limbaj anume dei, limbajul GemStone poate fi accesat i
din alte limbaje cum ar fi Smaltalk i C++.
GemStone este orientat n principal pe aplicaii CAD/CAM i nu trateaz motenirea
multipl.

7.8.2. ONTOS

ONTOS a fost realizat i comercializat n 1990 de ctre Ontos Billerica,
Massachusetts. Utilizeaz C++ ca limbaj de programare pentru baza de date orientat obiect.
Ontos este succesorul unui produs mai vechi numit VBase care utiliza un model orientat
obiect cu propriile sale limbaje COP(C Object Processor o extensie orientat obiect a
limbajului C pentru acces la baza de date) i TDL (Type Definition Language). Ulterior, n
Versiunea 2.0 TDL este nlocuit cu o extensie orientat obiect a SQL, numit Object SQL
sau ONTOS SQL, care adaug sintaxa cererilor obiect la SQL standard. Limbajul COP este
nlocuit i el cu C++.
Dei este strns legat de C++, Ontos este accesibil i din alte limbaje. Versiunea 2.0 a
introdus un 4GL numit Shorthand, un front-end windows, un raport i generator de forme
numit Studio. De asemenea, are un browser grafic i un instrument (tool) grafic capabil s
genereze n C++ fiiere i schema bazei de date. Metodele nu sunt stocate n baza de date aa
c trebuie meninute legturi ntre metode i date. Schema este stocat n baza de date i este
accesibil programatorilor. Clasele speciale sunt prevzute s modeleze structurile de
compunere.
Este suportat n LAN-uri utiliznd un model de arhitectur Client/Server.
Performana produsului este accentuat de posibilitatea clasterizrii (cluster) discului i
utilizrii tehnicilor Caching. ncepnd cu Versiunea 2.2 (1993) ofer suport extins pentru
aplicaii de grup de lucru precum i o mai bun notificare a evenimentelor.
ONTOS posed i alte caracteristici, dintre care enumerm:
- trateaz foarte bine motenirea multipl;
- folosete perechi de atribute inversate, n sensul c menine n mod automat
atribute inverse, deci valorile sunt atribute care reprezint o asociere (valori unice
sau multiple);
Capitolul 7
194
- trateaz obiecte mari de tip BLOB-uri. Pentru inerea n pagin, atributele foarte
voluminoase sunt stocate cu ajutorul unei reprezentri n arbori B;
- gestioneaz versiuni ale obiectelor;
- dispune de utilitare pentru administrare, cum ar fi: un browser interactiv pentru
examinarea i modificarea schemei bazei de date, comenzi de modificare i
regrupare fizic a datelor i un utilitar, numit Make, pentru sincronizarea
programelor cu o schem modificat.

7.8.3. VERSANT

VERSANT este un alt SGBD orientat obiect realizat de Versant Object Technology
la Menlo Park n California. Este implementat pe platforma de sistem UNIX, utiliznd C++
ca limbaj de acces primar ns este posibil i accesul din Smalltalk sau din Object SQL.
VERSANT este cunoscut i folosit n mod deosebit pentru aplicaii multi-user n
mediu de baze de date distribuite. Este bazat pe o arhitectur multi-client/multi-server.
Totodat, ofer posibiliti de comunicare cu alte sisteme, cum ar fi ORACLE, cu
instrumente de dezvoltare pentru GUI (Grafic User Interface) sau generatoare de rapoarte. El
poate asigura i un Depozit de date (Repository) pentru un mediu CASE cum ar fi Rational
ROSE CASE. Alte caracteristici ale sistemului VERSANT constau n faptul c trateaz
structurile compuse, motenirea multipl i variantele de versiuni.
7.8.4. ORION

ORION este un sistem orientat obiect realizat de MCC din Austin, Texas. El ofer
posibilitatea identificrii obiectelor, tratarea motenirii multiple, obiectelor compuse,
gestiunii versiunilor, indecilor pentru acces i tranzacii. De asemenea ofer suport pentru
baze de date distribuite, gestioneaz evoluia dinamic a bazei de date i accesul autorizat la
date. Este implementat n limbajul LISP, versiunea extins orientat obiect a acestuia.
O particularitate mai deosebit a proiectului de cercetare ORION de la MCC const
n faptul c se concentreaz pe evoluia schemei bazei de date. Schema unei baze de date
orientate obiect e dinamic i poate evolua n diferite feluri fr a necesita o recompilare,
astfel ca permite [34]:
- Schimbri in descrierea unui obiect prin adugare, tergere, actualizare de
atribute sau metode;
- Schimbri fa de reprezentarea obiectelor de ctre sistem, de genul: adugare,
tergere sau schimbare de identitate a unui obiect. tergerea unei clase de obicei
are mai degrab efect asupra tuturor subclaselor sale care motenesc proprietile
i comportamentul superclaselor;
- Schimbri n structurile bazei de date ca: adugare, tergere sau modificare a unei
moteniri, compuneri sau relaie asociativ.
n general, evoluia sau dezvoltarea structurii baze de date e complicat datorit
prezenei motenirii, n sensul c dac o superclas comport schimbri atunci trebuie
verificate toate implicaiile dependente de acea schimbare. Este important de observat c
identitatea obiectului e pstrat i trebuie s fie pstrat pe parcursul tuturor schimbrilor
schemei bazei de date orientate obiect. Pentru acest motiv se presupune c schimbrile
schemei trebuie s fie rezonabile i nu n totalitate. Aceast problem este strns legat de
cea a controlului de versiune i majoritatea bazelor de date orientate obiect ofer un mod de
control de versiune la nivel de instan, clas i schem. n acest scop, se poate defini o clas

cu semnificaie de istoric care ar conine ca atribute: versiunea precedent, versiunea
urmtoare i membru de set de versiune, care pot fi motenite de orice obiect care necesit
control de versiune.
Dei ORION a fost n mare parte inspirat dup modelul SMALLTALK exist un
numr important de extensii n model. De exemplu, motenirea multipl e suportat i exist
trei metode prevzute pentru rezoluia de conflict. Se folosete fie o regul left first (nti
stnga) prin care este folosit prima superclas dintr-o list de superclase de la care se
moteneste metoda sau atributul conflictual; sau utilizatorul poate specifica alegerea pe care
ar trebui s o fac obiectul; sau utilizatorul poate specifica c obiectul trebuie s moteneasc
ambele proprieti i s redefineasc una dintre ele.

7.8.5. ITASCA

ITASCA este realizat si comercializat de Itasca Systems Inc din Minesota,
Minneapolis. Este un produs software bazat pe prototipurile de cercetare ORION, ns mult
dezvoltat i perfecionat .
ITASCA ca i ORION utilizeaz limbajul LISP ns accept i alte limbaje de
programare cum ar fi: CLOS, C, C++ i Fortran. Ruleaz pe staii de lucru UNIX.
ITASCA se bazeaz pe o arhitectur multi-client/multi-server distribuit i ofer
posibilitatea urmririi evoluiei schemei dinamice i a unor servicii bune de securitate i
concuren. Trateaz structurile compuse iar notificarea evenimentului poate fi bazat pe
marcare (flag-based) sau mesaj (message-based).
ITASCA ofer facilitile de partiionare a bazei de date i distribuirea acestor partiii
n spaiu geografic, fr a fi nevoie ca utilizatorul s tie unde anume sunt stocate/localizate
datele. Se folosete indexarea claselor pentru a spori performana, iar unde e posibil cererile
se execut n paralel pe diferite maini din cadrul reelei.

7.8.6. O2

Sistemul de gestiune a bazelor de date orientate obiect O2 a fost realizat n Frana de
Consoriul de cercetare Altair ntre 1986 i 1990. Dup 1991 el a fost dezvoltat i
comercializat de O2 Technology la Versailles. O2 este implementat n C++ ns anumite
pri sunt implementate ntr-un limbaj propriu numit O2C. Este disponibil pe platformele
UNIX SUN , HP, IBM, BULL i DEC.
O2 constituie un motor de baze de date, O2 Engine, n interiorul cruia sunt
disponibile trei niveluri de utilizare:
- Limbajele de interfa: C i C++, un L4G, O2C, limbajul de cereri obiect O2SQL
i o interfa de programare a aplicaiilor de nivel de baz O2APL:
- Utilitare GUI: un generator a interfeei O2LOOK i un dispozitiv de manipulare
de grafice O2Graph ;
- Utilitare de mediu: un mediu de programare grafic O2Tools i un ansamblu de
componeni O2Kit.

O2Engine completeaz toate funciunile unui motor de baze de date: rspunde
cerinelor de lucru ntr-un sistem distribuit, arhitectura sa rspunde cerinelor unui model
client-server, distinge gestiunea logic i gestiunea fizic a datelor, furniznd mecanismele
de acces concurent i de reprize, de indexare, de optimizare a cerinelor, de plasament i de
Capitolul 7
196
regrupare a datelor. De asemenea, ofer metode de stocare, de manipulare, de execuie i
prelucrare a datelor.
n esen, O2Engine este compus i privit la trei niveluri:
- Managerul schemei (schema Manager) este nivelul superior al schemei. El este
responsabil cu cererea, cercetarea, modificarea i suprimarea claselor de obiecte,
metodelor i supervizare la nivel global al schemei bazei de date. n aceeai
msur el este responsabil de respectarea constrngerilor de motenire i
verificarea coerenei schemei;
- Managerul obiectelor (Object Manager) este situat la nivel intermediar. El
rspunde de asigurarea identitii obiectelor i de transmiterea mesajelor lor. El
asigur modelul de persisten prin ataarea i implementarea strategiilor de
indexare i de regrupare, bazate pe obiectele complexe i motenire;
- Managerul hardisc (Disk Manager), componenta O2Store genereaz fiiere
secveniale de nregistrri structurale, de fiiere de index de tip Arbore B. Toate
aceste structuri sunt pliate n pagini, unitatea persistent de baz.
O2Store asigur controlul localizrii fizice a paginilor pe disc. Totodat, O2 asigur
ncapsularea la trei niveluri: clase, scheme i baze de date.

7.8.7. Object Store

Object Store este conceput la Burlington, Massachusetts, fiind orientat pe limbajul de
programare a bazelor de date C++. Este primul sistem de gestiune a bazelor de date orientate
obiect ce ruleaz mai degrab n mediul MS Windows dect n mediul UNIX.
Object Store se bazeaz pe o arhitectur multi-client/multi server pentru a suporta
sistemul de lucru distribuit. Bibliotecile de clase sunt prevzute s suporte versiunile de clase
de obiecte, managementul configurrii i structurile compuse. Totodat, bibliotecile de clase
suport indexarea, clusterizarea, cererile asociative managementul relaiilor i iterarea peste
seturi.
n activitatea de programare, pentru adresare se utilizeaz unele tehnici de pointeri
swizzling. Conform unei astfel de tehnici, referinele de obiecte globale sunt convertite n
adrese de memorie local n momentul n care s-a ncrcat un obiect n memoria principal i
invers. [10,67,81]. O astfel de tehnic ofer reducerea timpului de regsire a datelor
solicitate de aplicaii.

7.8.8. OBJECTIVITY/DB

Objectivity (Objectivity Data System Overview; Objectivity, Inc., Menlo Park,
California, 1990) utilizeaz un limbaj de programare de baze de date orientate obiect bazat
pe C++. Este analog cu Object Store, ONTOS i cu VERSANT. Arhitectura sa este de tip
client/server distribuit cu un server central, toate operaiile efectundu-se de o manier
transparent asamblnd baze de date, scheme, utilizatori i calculatoare ntr-un mediu
material de sisteme de exploatare i reele heterogene. Limbajul de interfa cuprinde o
bibliotec de clase n C++, o bibliotec de funcii C i SQL++, suportnd SQL ANSI
complet i numeroase extensii obiect ale lui SQL3.
Un limbaj de nivel nalt, Object Definition Language (ODL), permite declararea
conceptelor de modelare precum i a asocierilor bidirecionale (relaii bazate pe atribute
inverse). Trateaz comportamentul asocierilor ntre obiecte atunci cnd avem de a face cu

mai multe sesiuni i programarea metodelor de traversare a asocierilor. Toate acestea au ca
rezultat generarea automat de metode i de declaraii C++ i C.
Punctul forte a lui Objectivity/DB este arhitectura sa client/Server distribuit, care
ofer o imagine logic unicat pe multiple baze de date instalate pe maini eterogene.
Utilizatorul va avea o imagine logic a obiectelor conectate i el nu va fi preocupat de faptul
c un obiect este ntr-o baz de date pe o staie de lucru SUN sau c un altul se gsete ntr-o
baz de date sub Windows sau VMS. Toate operaiile se desfoar la modul transparent n
acest mediu, unde tranzaciile atomice implic i validarea n dou faze a metodelor de
propagare i versionare a strii sistemului. n acest mod se accept sub control deplasarea
obiectelor dintr-o baz n alta i de pe o platform pe alta fr afectarea aplicaiilor n curs de
desfurare i nici nu reclam modificarea lor. Schemele multiple sunt create fr afectarea
altor utilizatori sau baze de date i sunt utilizabile simultan cu schemele partajate, permind
grupurilor locale s-i defineasc propriile lor modele.
Bazele de date sunt detaabile de acest mediu partajat (baze de date federale) pentru a
fi utilizate pe periferice portabile, reconectri sau deplasate ctre un mediu (compatibil)
diferit sau nc distribuite ca pri separate sau biblioteci de imagini.
Objectivity/DB este comercializat de Digital Corporation sub numele de DEC
Object/DB i este suportat de platformele SUN, DEC, HP/900, IBM, RS/6000, NCR 3300,
SGI, Windows 3.1., Windows 95, Windows NT etc.

7.9. Reguli de evaluare a unui SGBDOO

Aa dup cum Codd E.F. [17,18] a definit o serie de reguli pentru ca un SGBD s fie
cu adevrat relaional, tot la fel un grup de lucru de mare influen a publicat, sub denumirea
de Manifestul sistemelor de baze de date orientate pe obiecte, o serie de cerine sau
principii pe care trebuie s le ndeplineasc un SGBD pentru a putea fi considerat obiectual
[18]. n concordan cu Manifestul sistemelor de baze de date orientate pe obiecte, sunt
definite 13 principii ale SGBDOO, dintre care unele sunt obligatorii iar altele opionale.
Posibilitatea definirii structurilor complexe. O astfel de cerin presupune capacitatea
de a defini structuri complexe plecnd de la tipuri de date atomice folosind o serie de tipuri
de constructori, iar acetia s fie ortogonali, n sensul c fiecare constructor trebuie s se
aplice oricrui obiect. Exemplu, dac folosim constructori de forma SET (TUPLE( )), LIST
(TUPLE ( )) atunci trebuie s avem posibilitatea de a folosi i formele TUPLE (SET ( )) i
TUPLE (LIST ( )). Dintre cei mai folosii constructori amintim:
- ROW ( )
r n
t n t n , , , ,
1 1
, unde un tip reprezint un rnd sau tuplu cu cmpurile
r
n n , ,
1
de tipurile
r
t t , ,
1
;
- ARRAY: Tipurile array suport o metod array index pentru a permite
utilizatorilor s acceseze articolele array (coleciei);
- seturi i multiseturi (Sets and multisets) . Obiectele set pot fi comparate utiliznd
setul de metode tradiional <, , =, , >. Totodat, dou obiecte set (avnd
elementele de acelai tip) pot fi combinate pentru a forma un nou obiect folosind
operatorii , i (diferen).
- Liste: Operaiile pe liste tradiionale includ capul de list (head) care returneaz
primul element, coada listei (tail) care returneaz adresa ultimului element din
list; inserare sau adugare de noi elemente n list i respectiv excluderea unui
element din list.
Capitolul 7
198
Mai exist o serie de operatori, cum ar fi operatorii agregai (COUNT, SUM, AVG,
MAX, MIN), i operatori pentru conversia de tipuri (exemplu, pentru conversia unui obiect
multiset ntr-un obiect set prin eliminarea duplicatelor).
Identitatea obiectului, adic SGBD trebuie s ofere posibilitatea identificrii, fr
ambiguitate, a oricrui obiect din baza de date. n acest sens cu ocazia ncrcrii oricrui
obiect n baza de date se va recurge la generarea unui identificator unic al obiectului, numit
OID.
ncapsularea, presupune faptul c SGBD trebuie s dispun de capacitatea de a
ncapsula datele i metodele aparinnd obiectelor iar utilizatorii pot avea acces la ele doar
printr-o interfa ce citeaz o anumit metod. La rndul su att metodele ct i datele pot fi
definite publice (+), protejate (#) sau private (-).
Tipuri i/sau clase. Cele dou concepte trebuie s fie ambele prevzute. Primul
concept reprezint un mecanism de verificare pentru acurateea programelor n timpul
compilrii. Al doilea concept reprezint un mecanism care colecteaz extensiile de obiecte i
le definete implementarea lor. Invers, nu e necesar s fie dou forme diferite de a exprima
tipuri i clase i astfel e posibil s exprimm un concept n contextul celuilalt.
Clase i/sau tipuri de ierarhii, n contextul motenirii, evideniaz faptul c un
SGBDOO trebuie s asigure ca un subtip sau subclas s poat moteni atributele i
metodele de la superclasele sau supertipurile lor.
SGBD trebuie s ofere suport pentru legarea dinamic, n sensul c metodele trebuie
s se aplice la obiecte de diferite tipuri iar implementarea unei metode va depinde de tipul de
obiect cruia i se aplic. Acest aspect presupune faptul c sistemul nu poate lega denumirea
metodelor pn n momentul execuiei (legare dinamic).
SGBD trebuie s ofere un limbaj de manipulare a datelor LMD cu completitudine de
calcul. n acest sens, de exemplu, se apreciaz c standardul SQL3 posed completitudine de
calcul.
Extensibilitatea mulimii tipurilor de date, ceea ce presupune capacitatea de a defini
noi tipuri bazate pe cerinele utilizatorilor.
Durabilitatea sau persistena datelor, ceea ce presupune capacitatea sistemului de a
asigura/suporta persistena datelor. La fel precum i n situaia SGBD convenionale, datele
trebuie s rmn dup finalizarea aplicaiei care le-a creat. Deci utilizatorul nu trebuie s
deplaseze sau s copieze explicit datele, pentru a le putea refolosi.
SGBD trebuie s fie capabil i s ofere faciliti n ceea ce privete operarea i
gestionarea unor volume mari de date (baze de date de mari dimensiuni).
Asigurarea accesului concurent la aceleai resurse.
Asigurarea capacitii de refacere a bazei de date n cazul unor cderi fizice de
hardware sau software, asemntor sistemelor convenionale.
Asigurarea unor limbaje de cereri de nivel nalt cu multiple faciliti de integrare a
bazei de date.
Manifestul bazelor de date orientate obiect mai face referiri la cteva caracteristici
opionale, care sunt interesante i folositoare dar nu eseniale pentru un SGBDOO. Dintre
acestea enumerm: motenirea multipl, distribuia datelor ntr-o reea, posibilitatea
verificrii unui program n timpul compilrii, managementul tranzaciilor i mecanisme
pentru managementul versiunii lor.


7.10. Limbaj unificat de modelare (UML )-suport
pentru BDOO
*
,

7.10.1. Ce este UML-ul?

Tendina actual din industria software impune dezvoltarea de sisteme extrem de
complexe i n cel mai scurt timp posibil. Se impune cu necesitate adaptarea procesului de
dezvoltare a sistemelor informatice la cerinele din ce n ce mai complexe fa de produsele
informatice.
n plus, odat cu impunerea pe pia a limbajelor orientate obiect i a mediilor
vizuale de programare, au aprut n ultimii ani mai multe propuneri de procese de dezvoltare
orientat obiect a sistemelor informatice, ceea ce a introdus nc o pictur de haos n
ecuaie.
n aceste condiii, trei dintre cei mai importani autori din domeniul proiectrii de
software orientat obiect Ivar Jacobson, Grady Booch i James Rumbaugh [4] au conlucrat
pentru realizarea unui limbaj de modelare standard i a unui proces standard de dezvoltare a
produselor informatice. Limbajul pus la punct de acetia UML (Unified Modeling
Language) nregistreaz un mare succes, fiind adoptat ca standard de Object Management
Group (OMG), organismul de standardizare pentru comunitatea orientat obiect. Deci, UML
nu reprezinta un standard de metodologie de realizare a sistemelor informatice ci un standard
de notatii, concepte,simboluri folosite, diagrame utilizate, modele concepute etc.
Apariia acestui standard reprezint un mare avantaj dac ne gndim la multitudinea
de notaii i metode utilizate pn nu de mult n proiectarea orientat obiect i pe care UML
le substituie cu succes. n prezent este suficient ca proiectanii s cunoasc acest unic sistem
de notaii.
UML-ul reprezint o sintez a celor mai multe notaii i concepte utilizate n
proiectarea orientat obiect. A nceput ca o coroborare a activitii lui Grady Booch, James
Rumbaugh, i Ivar Jacobson, creatorii a trei dintre cele mai cunoscute metodologii orientate
obiect.
n 1996 Object Management Group (OMG) a emis o cerere de ofert pentru un
model semantic i notaii standard pentru analiza orientat obiect. Versiunea UML 1.0 a fost
trimis ca rspuns la aceast cerere n ianuarie 1997. Au existat i alte cinci proiecte
concurente. n cursul anului 1997 toi cei ase rivali s-au unit i au prezentat o versiune
revizuit organizaiei OMG, cunoscut ca UML versiunea 1.1. Acest document a fost
aprobat de OMG n noiembrie 1997 sub denumirea OMG UML versiunea 1.1.
UML propune notaii standard i semantic corespunztoare pentru modelarea
sistemelor orientate obiect. nainte de aceasta un proiect orientat obiect putea fi descris
utiliznd una dintre zecile de metodologii disponibile, ceea ce fcea ca n cazul unei revizuiri
cei responsabili de aceasta s piard mult timp cu analiza notaiilor i semanticii
metodologiei nainte de a ptrunde logica proiectrii. n acest moment, utiliznd UML,
diferii proiectani ce lucreaz la diverse sisteme pot nelege cu uurin munca celuilalt.

Capitolul 7
200
7.10.2. Componentele limbajului unificat de modelare

UML-ul prescrie un set standard de diagrame i notaii pentru analiza i proiectarea
orientat obiect a diverselor tipuri de sisteme (sisteme software, sisteme hardware sau
organizaii), descriind totodat i semantica acestor diagrame i simboluri.
Limbajul unificat de modelare ofer pentru aceasta zece tipuri de diagrame ce pot fi
grupate astfel:
- Diagrame pentru modelarea proceselor de afaceri, respectiv:
Diagrama cazurilor de utilizare n cazul metodologiilor orientate pe cazuri
de utilizare, aceast diagram dirijeaz ntreg procesul de dezvoltare al
sistemului
- Diagrame pentru modelarea structurii statice, respectiv:
Diagrama claselor pentru modelarea structurii statice a claselor sistemului
Diagrama obiectelor pentru modelarea structurii statice a obiectelor
sistemului
- Diagrame pentru modelarea dinamicii:
Diagrame de interaciune, respectiv:
Diagrama de secven pentru modelarea circuitului mesajelor ntre obiecte
Diagrama de colaborare pentru modelarea interaciunilor ntre obiecte
Diagrame de comportament, respectiv:
Diagrama de stare pentru modelarea comportamentului obiectelor din
sistem
Diagrama de activitate - pentru modelarea comportamentului cazurilor de
utilizare, obiectelor sau operaiilor
- Diagrame de implementare, respectiv:
Diagrama componentelor pentru modelarea componentelor
Diagrama de desfurare pentru modelarea distribuirii sistemului
Diagrama pachetelor mijloc de grupare a elementelor diagramelor n
pachete
n figura 7.28. se prezint grafic aceast clasificare a diagramelor UML.
Mecanismele de extensibilitate incluse permit ca n UML s poat fi abordate aspecte care
nu sunt specificate n standard. Aceste mecanisme permit extinderea notaiilor i semanticii
UML.
Stereotipul este cel mai utilizat dintre mecanismele de extensibilitate ale UML-ului.
Un stereotip reprezint un mecanism de calificare din punct de vedere al utilizrii. El se
poate aplica oricrui element de modelare, inclusiv claselor, pachetelor, relaiilor de
motenire, etc. De exemplu, o clas cu stereotipul <<actor>> este o clas utilizat ca agent
extern n modelarea proceselor de afaceri. O clas ablon (template) este modelat ca o clas
cu stereotipul <<parameterized>>, cu semnificaia c aceasta cuprinde parametrii.
Exist o seciune special n specificaiile UML care prevede stereotipuri specifice
pentru clasele i asocierile utilizate n modelarea proceselor de afaceri. Aceasta prevede
stereotipuri ca actor, executant sau entitate pentru o clas i stereotipuri de genul comunicare
simpl sau cale ntre surs i destinaie pentru o asociere.

Diagrama cazurilor de utilizare
MODELAREA PROCESELOR DE AFACERI
Diagrama claselor
Diagrama obiectelor
MODELAREA STRUCTURII STATICE
Diagrama de secven
Diagrama de colaborare
Diagrama de stare
Diagrama de activitate
MODELAREA DINAMICII
Diagrama componentelor
Diagrama de desfurare
Diagrama pachetelor
IMPLEMENTAREA

Fig 7.28. Diagramele UML

Un model grafic nu poate descrie dect o anumit parte din comportament, dup care
alte detalii trebuie specificate n cuvinte. De multe ori ns, utilizarea cuvintelor induce
ambiguitate. Object Constraint Language (OCL) este standardul UML pentru specificarea
detaliilor suplimentare sau precizarea constrngerilor modelului. Dezvoltat n cadrul diviziei
de asigurri a IBM ca un limbaj de modelare a proceselor de afaceri, OCL este un limbaj
formal uor de utilizat. OCL este mai formal ca un limbaj natural, dar nu la fel de precis ca
un limbaj de programare, ceea ce nseamn c nu poate fi utilizat pentru a descrie logica
programului sau pentru controlul fluxurilor. Cum acesta este un limbaj destinat expresiilor,
frazele sale nu au efecte secundare, ele furnizeaz pur i simplu o valoare fr a schimba
starea sistemului.
O tehnic extrem de utilizat pentru a deslui funcionarea modelului orientat obiect
este analiza orientat pe responsabiliti cu fie CRC (CRC cards - Class Responsibility and
Collaborator cards). Cu ajutorul acestei tehnici clasele identificate n cursul etapei de analiz
sunt analizate i selectate pentru a obine doar clasele cu adevrat necesare pentru modelarea
sistemului.
Dei bazele de date orientate obiect devin din ce n ce mai populare, bazele de date
relaionale rmn modalitatea curent de stocare a datelor. Diagrama claselor poate fi
Capitolul 7
202
utilizat pentru a modela baza de date relaional pe care se bazeaz sistemul, cu toate astea
tehnicile tradiionale de proiectare a bazelor de date relaionale cuprind mai mult informaie
i sunt mult mai nimerite pentru astfel de sarcini. Aceast lucrare propune modelul entitate
asociere (Entity Relationship - ER) ca extensie a UML-ului pentru proiectarea bazelor de
date relaionale.

7.10.3. Diagrama cazurilor de utilizare

Cu ajutorul acestei diagrame analistul stabilete aria de cuprindere a sistemului.
Simbolurile folosite ntr-o diagram a cazurilor de utilizare sunt redate n figura 7.29.

Fig. 7.29. Simbolurile diagramei cazurilor de utilizare

Diagrama cazurilor de utilizare este reprezentarea grafic a cazurilor de utilizare i a
actorilor (figura 7.30.) i este adesea nsoit de o descriere textual. Aceast diagram
documenteaz interaciunile sistemului cu mediul, care pot fi interaciuni cu factorul uman,
interaciuni cu alte sisteme i interaciuni ntre calculatoare.

Fig. 7.30. Diagrama cazurilor de utilizare (Use Case Diagram)

Diagrama cazurilor de utilizare furnizeaz un mecanism de colectare a cerinelor de
exploatare a sistemului. Ea identific utilizrile solicitate i comportamentul necesar pentru a
susine aceste utilizri i ajut la identificarea cerinelor sistemului. Atunci cnd este utilizat
n legtur cu diagrama claselor determin limita antrenrii unui proiect n soluii dezvoltate
concurenial, de la sumar la descrieri detaliate, care sunt apoi transformate n scenarii de
cazuri de utilizare multiple.
Un scenariu de caz de utilizare este o instan a unui caz de utilizare, aa cum un
obiect este instan a unei clase. O diagram a unui caz de utilizare nu reprezint un scenariu
de caz de utilizare cu un element model, adic o reprezentare grafic. Un scenariu de caz de
utilizare este alctuit din informaii text care detaliaz evenimentele i rspunsurile la acele
evenimente pentru a satisface cazul de utilizare. Fiecare scenariu de caz de utilizare
furnizeaz o legtur vital pentru nelegerea soluiei de afaceri i a soluiilor tehnice
posibile care o susin.
Fiecare diagram a cazurilor de utilizare are cel puin un caz i un actor. Un caz de

utilizare reprezint secvena aciunilor pe care sistemul le realizeaz pentru a produce ceva
de valoare pentru actorul care interacioneaz cu sistemul. Cu alte cuvinte, un caz de utilizare
poate fi privit ca un serviciu, o utilitate sau funcionalitate oferita de un sistem, subsistem sau
de o componenta a acestuia unui utilizator oarecare. Intr-o astfel de situaie, multitudinea
serviciilor sau funciunilor oferite de sistem utilizatorilor definesc funcionalitatea acelui
sistem. Actorul / utilizatorul poate fi o persoan sau un alt sistem extern. Un actor poate
participa la mai mult de un caz i, invers, la acelai caz de utilizare pot participa mai muli
actori.
Entitatea ofertant de servicii privita ca sistem, subsistem sau o component a
acestuia pentru utilizatori apare ca o cutie neagr, n sensul c nu este nevoie ca ei s
cunoasc ce conine sau cum este organizat acea entitate. Utilizatorii trebuie s cunoasc
doar ce servicii i poate oferi acea entitate. Exemplu, utilizatorii finali ai unui sistem
informatic trebuie s cunoasc doar ceea ce le poate oferi sistemul, cum ar fi: elaborarea i
editarea balanei de verificare, bilanul contabil, rulajul intrrilor, rulajul ieirilor etc. i nu
cum sunt organizate datele n cadrul sistemului, metodele de acces folosite etc. Alte exemple
i mai simple ar putea fi cele referitoare la serviciile oferite de un Bancomat (eliberare de
numerar, consultare sold cont, efectuare de pli, alimentarea bancomatului cu numerar etc.)
sau un Automat de vnzare de bilete de cltorie pentru transporturi feroviare, redat n figura
7.31.
n ambele cazuri utilizatorii nu sunt interesai s cunoasc organizarea fizic intern a
celor dou aparate ci doar serviciile posibile oferite de ele.
O diagram a cazurilor de utilizare poate conine trei tipuri de asocieri/relaii i
anume:
- asocieri de comunicare (<<communicate>>, <<comunic>>);
- asocieri de utilizare (<<uses>>, <<utilizeaz>>) sau in UML incluziune <<
include>>;
- asocieri de extindere(<<extends>>, <<extinde>>).

O asociere de comunicare arat care actor particip ntr-un caz de utilizare. Este tipul
implicit de asociere astfel nct nu este obligatorie precizarea acestuia prin stereotipul
<<comunicate>>.
Asocierea de utilizare arat c un caz de utilizare trebuie s includ comportamentul
altui caz de utilizare. Cu ajutorul stereotipului <<uses>> se evideniaz un comportament
obligatoriu, uneori mprtit n comun de mai multe cazuri de utilizare.
Asocierea de extindere arat c un caz de utilizare poate include opional, n anumite
condiii, un alt caz de utilizare (de extindere) i arat dependena dintre ele.

Capitolul 7
204
Casier

Fig. 7.31. Sistem automat de cumprare bilete

7.10.4. Diagrama claselor

Diagrama claselor este cea mai important diagram n cadrul analizei i proiectrii
orientate obiect. Scopul diagramei claselor este de a structura natura static a claselor n
termeni de atribute, operaii i asocieri (figura 7.32). Majoritatea instrumentelor de modelare
orientate obiect genereaz codul surs numai din diagrama claselor.
Celelalte diagrame UML furnizeaz diferite puncte de vedere din care s fie
identificate atributele, operaiile i asocierile dintre clase. Ele ajut la validarea diagramei
claselor, putnd servi la clarificarea unei probleme specifice pentru o audien specific.
Celelalte diagrame din UML exist, n principal, pentru a alimenta creterea i modificarea
diagramei claselor, fiecare cu o intenie diferit.
Diagrama claselor conine clase i asocieri ntre clase. O clas este un model pentru
obiecte cu structur, comportament i relaii similare. Fiecare clas are un nume, atribute i
operaii. n general numele claselor se scriu cu litere mari.
Proprietile atributelor definesc datele i pot include:
- Vizibilitate (public (+), protejat (#) sau privat (-))
- Tip (implementare specific limbajului tipului de atribut, cum ar fi caracter sau
ntreg)
- Valoare iniial (valoare cu care se iniializeaz obiectul)
- irul de proprieti (valori care se aplica atributului, cum ar fi o serie de numere)

CONSULTARE
MERSUL
TRENURILOR
ELIBERARE
BILETE
CONSULTARE
CONDIII
DE TARIFARE
PRELUARE
NUMERAR
Client



Fig. 7.32. Diagrama claselor (Class Diagram)

Proprietile operaiilor definesc comportamentul i pot include:
- Vizibilitate (public, protejat sau privat)
- Lista parametrilor (elemente transmise operaiei care includ tipul su propriu i
valoarea iniial)
- Tipul de rezultat (implementare specific limbajului tipului de atribut a valorii
rezultate dintr-o operaie)
- irul de proprieti (valori care se aplic argumentului n lista de parametri)
O clas reprezint cel mai important bloc (structur) dintr-un sistem orientat obiect.
i totui, n UML clasele sunt doar un tip de clasificatori denumire dat mai multor
structuri (blocuri) UML. Un clasificator este un mecanism care descrie caracteristicile
structurale i funcionale (comportamentale). Clasificatorii includ clase, interfee, tipuri de
date, semnale(signal), componente, noduri, cazuri de utilizare i subsisteme.
O clas este o descriere a unui set de obiecte care au aceleai atribute, operaii, relaii
i semantic. UML mai are i ali clasificatori n afar de clase i anume:
- Interfaa (interface) - o colecie de operaii care sunt folosite pentru a specifica un
serviciu al unei clase sau componente;
- Tip de date (data type) - un tip cu valori care nu au o anumita identitate, inclusiv
tipurile de date primare (cum ar fi numeric sau string), ca de altfel i enumerrile;
- Semnal (signal) - specificaia unui stimul asincron comunicat ntre instane;
- Componenta (component) - partea fizic i substituibil a unui sistem din
care face parte i care asigur realizarea unui set de interfee;
- Nod (node) - elementul fizic care exist la execuie i care reprezint o
resurs de calcul, de obicei avnd memorie si procesor;
- Cazuri de utilizare - descrierea unui set de secvene a aciunilor;
- Subsistem - un grup de elemente care constituie specificaia comportamental.
n UML, clasificatorii, deci implicit i clasele, se caracterizeaz prin urmtoarele
proprieti: vizibilitatea, scopul i multiplicitatea.
Vizibilitatea unui clasificator este acea caracteristic care specific dac acesta poate
fi folosit sau nu de ali clasificatori.
Exist trei niveluri de vizibilitate n UML:
- public (+) - are acces orice alt clasificator;
- protected (#) - are acces orice descendent;
- private (-) - numai clasificatorul nsui poate folosi aceast caracteristic.
Scopul determin dac elementul apare n fiecare instan a clasificatorului sau exista
Capitolul 7
206
o singur instan a elementului pentru toate instanele clasificatorului.
n UML, dup acest scop, se pot specifica doua tipuri de clasificatori:
- instance valori distincte ale elementului pentru fiecare instan a
clasificatorului;
- classifier o singur valoare pentru toate instanele.
n UML se indic faptul c o clas este abstract scriindu-i numele italic. O clas
concret (normala) este scrisa cu fonturi normale. O clas care nu are descendeni (o clas
frunz) este specificat scriind leaf sub numele clasei. O clas care nu are ascendeni se
numete clasa rdcin i se specific scriind root sub numele clasei.
Operaiile au proprieti similare (vizibilitatea i scopul). De obicei o operaie e
polimorf, ceea ce nseamn c ntr-o ierarhie de clase poi specifica operaii cu aceeai
semntur n puncte diferite din ierarhie. Operaiile din clasele copii suprancarc operaiile
din clasele printe. Operaiile, deci, pot fi: abstracte (ex.: funciile virtuale din C++) i
concrete (leaf) operaia nu poate fi suprascris (ex.: operaii nonvirtuale din C++).
Multiplicitatea reprezint numrul de instane al unei clase. Exist clase:
- cu zero instane, este o clas utilitar care confer doar atribute i operaii;
- cu o singur instan, singleton class;
- cu un numr dat de instane;
- cu multe instane (cazul implicit).
Atragem atenia c n acest context multiplicitatea are o alt semnificaie fa de
aceeai proprietate aplicat asocierilor .
Multiplicitatea se specific scriind un numr n colul dreapta al clasei. Ea se poate
aplica i atributelor scriind n paranteze o expresie dup numele atributului.
n UML sintaxa unui atribut este:
[vizibilitate] nume [multiplicitate] [:tip] [=valoare iniial] [(ir-de-proprieti }]
Exist trei tipuri de proprieti definite pentru atribute:
- changeable, fr restricii de modificare;
- addOnly, pentru atribute cu multiplicitate mai mare ca unu odat creat nu mai
poate fi ters sau modificat;
- frozen - valoarea atributului nu poate fi modificat (ex.: constante din C++).
Sintaxa unei operaii n UML este:
[vizibilitate] nume [(lista-parametri)] [:tip-returnat] [{ir-de-proprieti}]
n semntura unei operaii se pot specifica unul sau mai muli parametrii conform
urmtoarei sintaxe:
[direcie] nume :tip [=valoare implicit]
Direcia poate fi: in (parametru de intrare), out (parametru de ieire), in-out
(parametru de intrare care poate fi modificat).
Exist patru proprieti care pot fi folosite pentru operaii:
- isQuery, starea sistemului rmne neschimbat;
- sequential, trebuie coordonat apelul operaiei astfel nct s se execute doar una
la un moment dat,
- guarded, semantica i integritatea obiectu1ui este garantat n prezena mai
multor fluxuri (operaii executate n acelai timp), este redus la un ape1
secvenial executndu-se cte una pe rnd,
- concurrent se pot apela de mai multe ori din fluxuri concurente.
Ultimele trei proprieti sunt relevante doar n prezena obiectelor active, proceselor
i fluxurilor de execuie (threads).
Clasele template sunt elemente parametrizate (figura 7.33). Rezultatul instanierii
unei clase template este o clas care poate fi folosit ca orice alt clas.



Fig. 7.33. Notaii UML pentru clasele template

Figura 7.33 indic modul de scriere n UML a claselor template. Clasele template se
pot specifica implicit prin nume sau utiliznd bind care arat c sursa instaniaz template-ul
pentru parametrii actuali.

7.10.5. Diagrama obiectelor

Diagrama obiectelor modeleaz instanele elementelor coninute n diagramele de
clase. O diagram obiectual reprezint un set de obiecte i relaiile dintre acestea la un
anumit moment.
O instan este o manifestare concret a unei abstractizri a crui set de operaii poate
fi aplicat i care are o stare care arat efectele operaiilor. Instana i obiectul sunt sinonime.
Grafic, o instan este reprezentat subliniindu-i numele.

Cele mai multe instane modelate cu UML sunt instane ale claselor (i se numesc
obiecte), dei exist i instane de componente, noduri, cazuri de utilizare, asocieri. Instanele
modelate se plaseaz n diagrame obiectuale (pentru detalii a se vedea 7.61).
Operaiile care se fac asupra unui obiect sunt definite n abstractizarea obiectului. n
funcie de motenire operaiile pot sau nu fi polimorfe.
Un obiect are o stare care reprezint proprietile obiectului (cele statice de obicei) i
valorile curente (dinamice) ale acestor proprieti. Aceste proprieti includ atributele
obiectului i prile lui agregate. Deci, starea unui obiect este dinamic.
Diagramele obiectuale conin obiecte i legturi. Ca i celelalte diagrame, poate
conine note i restricii. Mai pot conine anumite pachete sau subsisteme, fiecare fiind
folosite pentru a grupa elementele modelului.
Aceste diagrame se folosesc pentru modelarea static a unui sistem, ca diagramele de
clase, dar din perspectiva unor instane reale sau prototip.

7.10.6. Diagrama de secven

Scenariile cazurilor de utilizare se dezvolt n mod natural din diagrama de secven.
Diagramele de secven transform evenimentele identificate n scenariile cazurilor de
utilizare ntr-o reprezentare grafic a utilizrilor sistemului de ctre actor (figura 7.34).

STUDENT:Popescu Instan cu nume :Popescu Instan anonim
Capitolul 7
208
Fiecare eveniment are ca rezultat un mesaj trimis unui obiect cu perspectiva c acel obiect va
realiza o operaie. Rafinarea operaiei i a atributelor utilizate n semntura operaiei (ca
argumente) actualizeaz clasa n diagrama claselor. Identificarea i definirea operaiilor
bazate pe evenimente furnizeaz capacitatea de urmrire napoi la cazul de utilizare.
Diagrama de secven descrie cronologic interaciunea obiectelor, identificnd
mesajele schimbate ntre obiecte ca rspuns la un eveniment, mpreun cu secvena
mesajelor. Intenia este de a stabili limitele contextuale ale scenariului cazurilor de utilizare.
Este prima vizualizare a intercomunicrii claselor pentru un anumit scenariu al cazurilor de
utilizare. Scopul nu este captarea imediat a operaiilor, ci nelegerea ordinii evenimentelor
pentru a parcurge ntregul scenariu. Pe msur ce ordonarea devine stabil, un eveniment
devine o operaie specific pe care o iniializeaz obiectul receptor.
Diagramele de secven sunt recomandate pentru realizarea de specificaii n timp
real i pentru scenarii complexe. O diagram de secven avansat arat, de asemenea,
execuia condiional.
Diagrama de secven listeaz obiectele diagramelor de secven implicate ntr-un
scenariu al cazurilor de utilizare n partea superioar de la stnga ctre dreapta. Cnd se
include numele clasei cu numele obiectului, se separ clasa de obiect prin ":".
Se plaseaz mesajele schimbate ntre obiecte, pe vertical de sus n jos. Perioada de
existen se propag n jos, de la fiecare obiect. Pentru fiecare pas n scenariul cazurilor de
utilizare, un obiect trimite mesajul din linia sa de viaa ctre linia de viaa a unui alt obiect.
Mesajul conine informaii necesare obiectului doi s acioneze. Cu alte cuvinte, mesajul
declaneaz o aciune n obiectul receptor. Un obiect poate s fie att receptor ct i emitor
(recursiv). Opional se poate include un actor care s participe n scenariul cazurilor de
utilizare ca fiind un obiect care trimite i primete mesajele. Un singur pas n timpul
scenariului cazurilor de utilizare uneori poate crea sau distruge un obiect. Linia de via a
obiectului se monitorizeaz prin alinierea vertical a obiectului cu pasul su de instaniere.
Se marcheaz cu X sfritul liniei de via, adic pasul n care obiectul este distrus.
Dreptunghiul de-a lungul liniei de via a obiectului arat durata aciunii, numit
activare sau amplificarea controlului, ncepnd cu mesajul primit i terminnd cu mesajul
trimis.
Forma diferit a sgeilor reprezint tipuri diferite ale mesajelor. Mesajul sincron,
unde obiectul care l-a trimis ateapt rspunsul de la obiectul care l-a recepionat, este
reprezentat prin urmtoarea sgeat:

Sgeata mesajului de rspuns are aceeai form. Cnd obiectul care trimite mesajul
nu ateapt rspunsul, cazul mesajului asincron, sgeata are urmtoarea forma:



Fig. 7.34. Diagrama de secven (Sequence Diagram)

Se spune c procedura are vrful de sgeat substituit. Mesajul de rspuns nu are nici
un vrf pe sgeat i n schimb are liniua vertical plasat n apropierea mesajului original
trimis. Daca paii se repet, mesajele se plaseaz n interiorul unui dreptunghi. Se poate
aduga textul iteraiei pentru indicarea numrului de iteraii i a condiiei de ieire. Textul
are forma: [i:=1..n] cu semnificaia: repetare folosind variabila i, de la 1 pn la un numr
n.

7.10.7. Diagrama de stare

Modeleaz starea dinamic a unui obiect specific. Diagrama de stare const din stri,
aciuni, activiti i tranziii (figura 7.35).
Diagrama de stare identific evenimentele care fac tranziia unui obiect dintr-o stare
n alta. Conform UML, o stare este o condiie sau o situaie din momentul existenei unui
obiect care satisface n acel moment anumite condiii, efectueaz anumite activiti sau
ateapt anumite evenimente. Diagrama de stare descrie toate operaiile i atributele unei
clase n timpul unui eveniment. Diagrama identific stimulii care declaneaz aciunea.
Diagrama include numele strii, oricrei variabile, n timp ce obiectul este n funciune, i
evenimentul care declaneaz tranziia la o nou stare.
Dreptunghiul cu marginile rotunjite reprezint stri distincte. Orice diagram de stare
include o stare iniial reprezentat printr-un cerc mic de culoare neagr i o stare final
reprezentat prin acelai cerc dar inclus ntr-un cerc puin mai mare. Starea iniial apare la
crearea obiectului. Starea final apare la dispariia obiectului.

Capitolul 7
210

Fig. 7.35. Diagrama de stare (Statechart Diagram)

Diagrama de stare identific evenimentele care fac tranziia unui obiect dintr-o stare
n alta. Conform UML, o stare este o condiie sau o situaie din momentul existenei unui
obiect care satisface n acel moment anumite condiii, efectueaz anumite activiti sau
ateapt anumite evenimente. Diagrama de stare descrie toate operaiile i atributele unei
clase n timpul unui eveniment. Diagrama identific stimulii care declaneaz aciunea.
Diagrama include numele strii, oricrei variabile, n timp ce obiectul este n funciune, i
evenimentul care declaneaz tranziia la o nou stare.
Dreptunghiul cu marginile rotunjite reprezint stri distincte. Orice diagram de stare
include o stare iniial reprezentat printr-un cerc mic de culoare neagr i o stare final
reprezentat prin acelai cerc dar inclus ntr-un cerc puin mai mare. Starea iniial apare la
crearea obiectului. Starea final apare la dispariia obiectului.
Cu excepia strii iniiale i a celei finale fiecare stare are un nume, atributele proprii
unei stri, aciunile i activitile efectuate. Acestor aciuni i activiti le este atribuit un
nume de eveniment, precum i argumente i expresii ale aciunii. Slash-ul "I", separ
expresiile aciunii de la numele evenimentului i argumentele. Aciuni speciale includ:
- Entry / intrare - aciune efectuat la intrare ntr-o stare
- Exit / ieire - aciune efectuata la ieire dintr-o stare
- Do / aciune efectuat aflndu-se ntr-o stare; evenimentele externe pot ntrerupe
aciunile Do.
Obiectul tranziteaz dintr-o stare n alta cnd apare un eveniment i cnd sunt
ndeplinite anumite condiii. Tranziia este artat cu liniue simple de la o stare existent
ctre o stare de intrare / int. Tranziia conine:
- semntura unui eveniment care include un nume i argumentele separate de
virgule care se afl ntre paranteze
- o condiie de securitate opional care interzice tranziia de stare pn cnd nu
sunt ndeplinite toate condiiile
- o aciune introdus cu slash /
n timpul tranziiei se execut o aciune. Aciunea poate s fie o operaie efectuat de
obiect, un mesaj trimis altui obiect, sau o condiie n cadrul obiectului care declaneaz
schimbarea strii. Aciunea nsi poate include o semntur cnd aciunea trimite un mesaj

altui obiect. Expresia aciunii poate include obiectul receptor i parametrii transmii acelui
obiect receptor. O sgeat reprezint trimiterea unui mesaj ctre un alt obiect. Acest mesaj
poate fi trimis de la obiect n timp ce este ntr-o anumit stare sau n timpul tranziiei.

7.10.8. Diagrama de colaborare

Diagrama de colaborare descrie o examinare non-secvenial a modului n care
interacioneaz obiectul. Diagrama de colaborare suport multiple modaliti de modelare a
obiectului. O modalitate arat modul n care obiectele colaboreaz n cadrul unui singur
scenariu al cazurilor de utilizare similar cu diagrama de secven. O interaciune interesant
se produce ntre diagramele de secven i diagramele de colaborare, rezultnd operaiuni
intensificate i descoperirea unor atribute adiionale. Ambele diagrame furnizeaz puncte de
vedere diferite ale aceleiai informaii. Ambele arat implementarea unui scenariu al cazului
de utilizare. Diagrama de colaborare filtreaz timpul sau examinarea secvenial a
scenariului pentru a studia asocierile statice i comportamentele dinamice ale obiectelor
implicate n interaciune. Avem tendina s gndim secvenial, dar cteodat, procesele nu
sunt att de procedurale cum ni le imaginm. Utilizarea diagramei de colaborare poate ajuta
la clarificarea contextului.
Diagrama de colaborare poate fi utilizat pentru a arta legtura tuturor operaiunilor
unei anumite clase. Pentru fiecare operaie, este artat obiectul int al operaiei i orice alt
obiect pe care l solicit pentru a implementa operaia. Diagrama de colaborare, astfel,
devine un context al tuturor obiectelor i al asocierilor care interacioneaz cu un obiect
(figura 7.36).

Fig. 7.36. Diagrama de colaborare (Collaboration Diagram)

Deoarece permite focalizarea asupra unei anumite clase, diagrama de colaborare ajut
la rafinarea diagramei claselor, adugnd atribute i operaii. Furnizeaz, de asemenea,
informaii cu privire la ceea ce face o clas atunci cnd valideaz codul asociat acesteia.
Notaia UML a diagramei de colaborare este asemntoare cu diagrama de secven
cu obiecte, mesaje i semnturi. Fiecare mesaj poate include un numr secvenial care s
ordoneze etapele colaborrii. Virgulele separ secvenele i se termina cu un slash /.
Un predecesor n numrul secvenei indic faptul c alt mesaj trebuie completat naintea
transmiterii acestui mesaj.
Diagrama de colaborare poate arta un comportament repetat cu un asterisc, *,
urmat de numrul de iteraii i de condiia de ieire ncadrat ntre paranteze, de exemplu,
Capitolul 7
212
[i:= 1..n].

7.10.9. Diagrama de activitate

O diagram de activitate permite o mai bun nelegere a operaiilor, n special a celor
foarte complexe. Diagramele de activitate permit mai buna nelegere a detaliilor din cadrul
unei operaii a unei clase. Diagramele de secvena i de colaborare nu capteaz acest nivel de
detaliere suficient de exact pentru ca ele arat doar mesajele schimbate ntre obiecte, nu i
detaliile asociate acestor obiecte. Alte activiti complexe pot necesita un mai mare
rafinament ntr-o alt diagram de activitate care s arate strile sub-aciunilor i sub-
tranziiile.
Diagrama de activitate este un tip de grafic de stare care specific activitatea unei
anumite clase (figura 7.37).
Diferena consta n faptul ca un grafic de stare reprezint ntregul obiect, n timp ce o
diagram de activitate reprezint n mod tipic doar o operaie n cadrul unui obiect.
Terminologia diagramei de activitate este uor confundat eu terminologia diagramei de
stare ntruct ambele utilizeaz termenul stri. Starea din cadrul diagramei de activitate
este stare a unei aciuni, noiune distinct de stare a obiectului.

Fig.7.37. Diagrama de activitate (Activity Diagram)

Starea aciunii reprezint starea unei activiti n cadrul unei operaii. Descrie
descompunerea strii de aciune i tranziiile n cadrul unei anumite stri a obiectului, mai
mult dect de la o stare la alta. Descompunerea strii nu nseamn c obiectul i modific
starea. O aciune a strii reprezint mai degrab, prelucrarea intern care intervine n timpul
aciunii sau activitii surs. Procesarea intern, mai mult dect un eveniment extern,
declaneaz tranziia de la o stare a aciunii la alta. Diagrama de activitate este utilizat
pentru a arata aceast prelucrare intern.

S lum, drept exemplu, un automat. Cnd consumatorul introduce banii ntr-un
automat, activitatea de a da consumatorului un produs poate traversa mai multe aciuni de
stare. De exemplu, oferirea restului, lsarea produsului s cad n tav, avansarea liniei de
produse. Totui, nici una dintre aceste stri ale aciunii nu reprezint stare a obiectului
automatului (ateptarea seleciei, livrarea produsului).
Starea aciunii poate fi declanat de :
- Completarea unei operaii,
- Completarea unei stri, a unei aciuni anterioare sau
- Disponibilitatea unui obiect (starea necesar unei aciuni pentru a ncepe).
Activitatea const n etape procedurale sau operaii declanate mai degrab de
prelucrarea intern dect de evenimente externe. O stare specific unui obiect sau
completarea uneia din operaiile sale declaneaz o operaie, o aciune n cadrul unei stri a
aciunii este deseori ea nsi o operaie. Cnd se termin o aciune, poate face un obiect
disponibil pentru o aciune urmtoare. Cnd se ntmpl acest lucru, activitatea s-a mutat
ctre starea sa de aciune urmtoare.
Un dreptunghi cu colurile rotunjite nconjoar aciunea; capetele deschise ale
sgeilor indic fluxul controlului. Poate include atributele utilizate de o aciune, dar poate
doar s utilizeze atributele i link-urile obiectului care le deine (de exemplu, obiectul pentru
care se definete activitatea).
O diagram de activitate poate avea ramuri de control comune sau separate. Aceste
fluxuri de aciune au drept etichet condiia care declaneaz fluxul.

7.10.10. Diagrama componentelor

Diagrama componentelor adun informaiile din diagrama claselor pentru a crea
componente. Diagrama componentelor modeleaz dependena componentei software n
funcie de codul sursa, codul binar i componentele executabile (figura 7.38).

Fig. 7.38. Diagrama componentelor (Component Diagram)

Capitolul 7
214
Notaia UML pentru componente este dreptunghiul cu dou dreptunghiuri mai mici
scoase n afar, pe una din pri. O component are un nume i opional un tip separate prin
:. Componenta poate include obiectele pe care le conine.
Un vrf de sgeat deschis de la o component la alta indic o dependen a sursei de
int. O relaie de dependen reprezentat de un cerc deschis i o etichet de interfa pot fi
trasate ctre interfaa obiectului; aceasta este iniierea dependenei. O dependen poate fi de
asemenea trasat direct ctre component fr trecerea printr-o interfa; aceasta este o
dependen de compilare.

7.10.11. Diagrama de desfurare

Componentele sunt "plasate" pe echipamente hardware prin intermediul diagramei de
desfurare. Diagrama de desfurare modeleaz procesoare i echipamente fizice,
securitatea i componentele care sunt plasate pe procesoarele fizice (figura 7.39).

Fig..39. Diagrama de desfurare (Deployment Diagram)

Diagrama de desfurare reprezint partiionarea componentelor i a obiectelor active
(de exemplu, o baza de date) pe locaia lor fizic. Acest tip de diagram detaliaz locul de
amplasare a componentelor n cadrul infrastructurii sistemului. Cel mai adesea sunt definite
mai multe diagrame de desfurare independente.
Diagrama de desfurare utilizeaz noduri pentru a reprezenta procesoare i
echipamente. Fiecare nod are un nume i, opional, un tip, separate de dou puncte, :.
O linie continu de la un nod la altul indic faptul c nodurile comunic, de exemplu,
printr-un canal sau o reea. Un vrf de sgeat deschis indic faptul c o component
comunic cu un obiect activ.

7.10.12. Diagrama pachetelor

UML furnizeaz mijloace de grupare a elementelor din cadrul diagramelor, numite
pachete. ntr-un pachet pot fi ambalate alte pachete, clase, cazuri de utilizare, colaborri etc.

Un pachet arat doar structurile pe care le conine (figura 7.40).
Un pachet nu arat comportamentul elementelor sale. Un element de modelare
aparine unui singur pachet, dar alte pachete pot consulta acest element. Dac se arat
explicit coninutul pachetului, atunci numele pachetului se trece pe etichet. Un pachet este
un mecanism destinat unor scopuri generale, care organizeaz elementele n grupuri. Fiecare
pachet are un nume care poate fi simplu sau cu cale (path name). De exemplu: nume
simplu -client nume cale -senzori :: viziuni

Fig. 7.40. Diagrama pachet (Package Diagram)

Un pachet poate conine clase, interfee, componente, noduri, colaborri, cazuri de
utilizare, diagrame i chiar alte pachete. A conine este o relaie compus, ceea ce
nseamn c fiecare element este declarat n pachet. Din punct de vedere al vizibilitii,
pachetele se comport precum clasele.
Importul unui pachet - Presupunem ca avem clasa A n pachetul A i clasa B n
pachetul B. Fiecare sunt elemente publice ale pachetului su. Daca pachetul A import
pachetul B, A poate vedea B, dar B nu poate vedea A. Importul acord o permisiune eu un
singur sens elementelor unei clase asupra elementelor altei clase.
Exist dou tipuri de relaii ntre pachete: importul i dependenele acces, folosite
pentru a importa ntr-un pachet elementele exportate de altul i generalizrile, folosite pentru
a specifica familii de pachete. Un pachet specializat poate fi folosit oriunde este folosit un
pachet.

Capitolul 7
216
7.10.13. Interaciunea dintre diagramele UML

Pe parcursul ciclului de via al unui sistem informatic diagramele UML
interacioneaz ntre ele sau cu alte modele (modelul entitate asociere), figura 7.41.
Cazurile de utilizare i diagramele de interaciune. Toate procesele care trebuie
executate de sistem se regsesc ntr-un caz de utilizare. Procesele sunt descrise apoi textual
sau printr-o succesiune de pai. Pentru modelarea grafic a scenariilor poate fi utilizat
diagrama de activitate. Odat ce comportamentul sistemului a fost astfel surprins, cazurile de
utilizare sunt mai departe analizate pentru a identifica cum interacioneaz obiectele pentru a
modela acest comportament. Diagramele de secven i de colaborare sunt utilizate pentru a
modela aceast interaciune ntre obiecte.
Clasele, obiectele i diagramele de implementare. Pe msur ce sunt identificate
obiectele, acestea pot fi grupate i clasificate n cadrul diagramei claselor i a obiectelor.
Diagrama claselor devine astfel elementul central al procesului de proiectare orientat obiect,
fiind diagrama care descrie structura static a sistemului. Diagrama claselor poate fi
mprit pe trei straturi care s evidenieze clasele ce descriu interfaa cu utilizatorul
(business layer), clasele responsabile de logica aplicaiei (application layer) i clasele pentru
stocarea datelor (data layer). Diagrama componentelor este utilizat pentru a grupa clasele n
componente sau module. Distribuirea fizic n ansamblul sistemului este modelat cu
ajutorul diagramei de desfurare.
Fie CRC o extensie informal a UML-ului. Ca extensie a UML-ului, tehnica
fielor CRC poate fi utilizat pentru a supune sistemul analizei orientate pe responsabiliti.
Clasele sunt analizate, selectate i rafinate pe baza responsabilitilor lor n cadrul sistemului
i a claselor cu care acestea trebuie s colaboreze pentru a-i ndeplini aceste responsabiliti.
Diagramele de stare. Cu ajutorul diagramelor de stare se modeleaz comportamentul
n timp real al fiecrei clase cu un comportament semnificativ dinamic. Diagrama de
activitate poate fi i ea folosit, de aceast dat ca extensie a diagramei de stare, pentru a
detalia aciunile de rspuns ale obiectelor la evenimente interne acestora. Diagrama de
activitate poate fi utilizat i pentru a reprezenta grafic aciunile metodelor claselor.
Implementarea proiectrii (realizarea sistemului). Realizarea sistemului presupune
transformarea informaiei cuprins n mai multe modele UML n cod i structur a bazei de
date. n cazul unui sistem de mari dimensiuni este extrem de util descompunerea acestuia n
trei subsisteme: subsistemul afacerii, care include i elementele de interfa cu utilizatorul
(business layer), subsistemul aplicaiei, care include obiectele de implementare a
funcionalitii sistemului (application layer) i subsistemul datelor, care include structura
bazei de date i obiectele de acces la aceast structur (data layer).
Implementarea aplicaiei (codificarea). Diagrama claselor este utilizat pentru a
genera scheletul aplicaiei n limbajul de programare ales cu ajutorul unui CASE.
Diagramele de interaciune, de stare i de activitate furnizeaz informaii suplimentare pentru
detalierea prii procedurale a codului.
Proiectarea bazei de date. Stratul datelor (data layer) din diagrama claselor poate fi
utilizat pentru a proiecta direct o baz de date orientat obiect sau pentru a construi
corespunztor un model entitate asociere (ER - Entity Relationship) pentru o analiz mai
detaliat a relaiilor. Pe baza modelului entitate asociere se poate construi apoi modelul fizic
al bazei de date relaionale.
Testarea cerinelor. Diagrama cazurilor de utilizare este folosit i pentru a testa dac
sistemul rspunde cerinelor iniiale. Se parcurg toate cazurile de utilizare pentru a vedea
dac sistemul corespunde cerinelor clientului


7.10.14. Avantajele utilizrii UML

Dei nu garanteaz succesul unui proiect informatic, UML poate contribui la
reducerea costurilor de instruire i schimbare a instrumentelor de lucru atunci cnd se face
trecerea de la un proiect la altul sau de la o organizaie la alta. UML ofer o baz pentru
integrarea instrumentelor, proceselor i domeniilor. n primul rnd, UML asigur o
terminologie unic i permite realizatorilor de sisteme s se concentreze asupra obiectivelor
proiectelor i nu asupra instrumentelor de modelare.
Aa cum a fost precizat n documentul UML Summary, Version 1.1, elaborat la 1
septembrie 1997 de Rational Software i ceilali realizatori, scopurile pentru care a fost creat
UML sunt urmtoarele:
- s pun la dispoziia utilizatorilor un limbaj de modelare vizual uor de folosit,
expresiv. Este foarte important ca standardul pentru analiz i proiectare s
suporte un limbaj de modelare care s fie folosit pentru realizarea de taskuri
generale de modelare. Dac standardul ofer numai o descriere de meta-nivel care
reclam ajustarea la un anumit set de concepte de modelare, atunci nu se poate
realiza schimbul de modele fr pierdere de informaii;
- s asigure extensibilitatea precum i mecanismele de specializare prin care s fie
extinse conceptele de baz;
- s permit formularea de specificaii independente de un anumit limbaj de
programare i de procesele de realizare a sistemului;
- s ofere o baz formal pentru nelegerea limbajului de modelare;
- s ncurajeze creterea pieei instrumentelor orientate pe obiecte;
- s suporte concepte, precum: componente, colaborri, cadre;
- s permit diseminarea celor mai bune practici n domeniul realizrii sistemelor
software.
UML reunete conceptele din Booch, OMT i OOSE. Rezultatul l reprezint un
limbaj de modelare posibil de utilizat de ctre utilizatorii acestor metode, dar i a altor
metode orientate pe obiecte.

Diagrame de implementare
Diagrame de interactiune
Cerinte
Cazuri de
utilizare
Carduri CRC
Interfata
grafica
p
r
o
i
e
c
t
a
r
e
a

G
U
I
Diagrama de
colaborare
Diagrama de
secventa
Specificarea procesului de afaceri
Diagrama
claselor
Test
Diagrama de
stare
Diagrama de
activitate
Modele de
date relationale
Modele de
date fizice
Baza de date
relationala
Baza de date
obiectuala
Codificarea
Posibila generare de cod
Metode de acces
Metode de acces
Inginerie inversa
Diagrama de
stare
Diagrama de
stare
Posibila translatare de cod

Fig. 7.41: Interaciunea dintre diagramele UML, tehnica fielor CRC i modelul entitate asociere

n plus, UML extinde posibilitile oferite de metodele menionate mai sus. De
exemplu, prin utilizarea UML se poate realiza modelarea sistemelor concurente i a celor
distribuite.
UML asigur un standard de limbaj, nu i de proces. Dei UML poate fi folosit n
cadrul unei metodologii, experiena echipei de proiect i specificitatea domeniului pot reclama
utilizarea unor procese specifice. UML asigur un acelai meta-model, care unific semantica
i o aceeai notaie, pentru interpretarea acestei semantici. UML promoveaz construirea
iterativ i incremental a sistemelor software dirijat de cazurile de utilizare i centrat pe
arhitectura acestor sisteme.

7.11. Modelarea orientat obiect

Un model orientat obiect are la baz obiecte. Un obiect ncapsuleaz att date cat i
comportament, ceea ce nseamn c analistul poate folosi abordarea orientat obiect att
pentru modelarea datelor ct i pentru modelarea proceselor. Pentru c permite analistului de
sistem s surprind ambele aspecte ntr-o singur reprezentare i pentru c ofer i alte
beneficii cum ar fi mecanismul motenirii i reutilizarea codului, modelarea orientat obiect
ofer un mediu puternic pentru dezvoltarea sistemelor complexe. Teoria obiectelor,
ncapsularea, motenirea i polimorfismul stau la baza dezvoltrii obiectuale a sistemelor.
Exist o varietate larg de metodologii i tehnici utilizate de ctre un analist de sistem
n procesul de analiz i proiectare orientat obiect.
Referitor la consistena modelelor, n alte abordri cum ar fi analiza i proiectarea
structurat modelele care se dezvolt nu folosesc notaii comune i sunt slab conectate ntre
ele, tranziia de la un model la altul fcndu-se n mod abrupt. Abordarea orientat obiect
ofer continuitate n ceea ce privete tranziia ntre modelele analizei, proiectrii i ale
implementrii. De exemplu, trecerea de la analiza orientat obiect la proiectarea orientat
obiect presupune mbogirea modelului de analiz cu detalii referitoare la implementare i nu
dezvoltarea unui nou model.

7.11.1. Modelarea domeniului (mediului) Domain Model

Pentru a aprofunda nelegerea contextului n care va funciona sistemul se utilizeaz
modelul mediului (domeniului). Acest model cuprinde cele mai importante clase ntlnite n
domeniul economic pentru care se realizeaz sistemul informatic i are un caracter de
generalitate. Clasele se identific fie din cerinele exprimate de beneficiar, fie din
intervievarea unor experi n domeniu. Este unul dintre primele modele utilizate n analiza
orientat obiect i are menirea de a sistematiza expertiza din domeniul analizat i a o transmite
sistemului informatic ce urmeaz a fi proiectat.
Sunt trei tipuri de clase care pot fi puse n eviden n acest model:
- clase ce modeleaz obiecte sau concepte utilizate n cadrul sistemului
informaional analizat, cum ar fi comand, contract, factur;
- obiecte sau concepte din lumea real pe care sistemul trebuie s le nregistreze i
s in cont de ele, cum ar fi cursul de schimb al monedei de referin;
- evenimente ce intervin i afecteaz starea sistemului, cum ar fi plasarea unei
comenzi, plata unei facturi.
Capitolul 7
220
Pentru descrierea acestui model vom utiliza preponderent diagrama claselor, dintre
instrumentele puse la dispoziie de UML. Aa cum am vzut n capitolul anterior diagrama
claselor reprezint att entitile domeniului (clasele) ct i relaiile dintre acestea (asocierile),
figura 7.42.
Aa cu am mai precizat scopul principal al acestui model este nelegerea contextului
sistemului. De aceea la realizarea modelului mediului (domeniului) este de preferat s
participe att specialiti n modelare ct i experi din domeniul analizat. Din acest punct de
vedere se remarc asemnarea cu etapa de analiz specific metodologiilor structurate. Aa
cum tim deja, conform unui vechi principiu al analizei sistemelor, n acest proces este de
preferat s fie implicai cei mai buni specialiti n domeniu (experii). Modelul mediului va
conine cele mai importante clase ale domeniului. Odat cu ntocmirea diagramei claselor se
ntocmete i un dicionar al claselor n care se va preciza semnificaia fiecrei clase pentru a
se folosi o terminologie unitar. Se prefer aceast formul pentru a se evita obinerea unui
model prea mare i greu de utilizat.
Uneori, pentru sistemele de mici dimensiuni, se renun chiar la diagrama claselor
pentru modelul mediului, ntocmindu-se doar acest dicionar de termeni.
Dicionarul este deosebit de important i pentru asigurarea unui limbaj comun n
cadrul proiectului. Cu toii intuim problemele ce pot apare n comunicare datorit utilizrii
unei terminologii necunoscute de toi cei implicai n proiect.
n final trebuie s atragem atenia c la acest nivel analistul nu trebuie s insiste prea
mult pe clasele interne sistemului, acest model fiind destinat identificrii i nelegerii
cerinelor ce deriv din contextul sistemului. Modul n care sistemul va trata aceste probleme,
logica intern, urmeaz s fie detaliate n alte etape, cu ajutorul altor modele.
Modelul mediului, format din diagrama claselor domeniului i dicionarul de termeni,
poate fi utilizat att la dezvoltarea modelului cazurilor de utilizare ct i la identificarea
claselor sistemului n etapa de analiz.

Fig. 7.42. Diagram a claselor ce modeleaz domeniul aplicaiei
Produs

descriere
foto
cost
Factur

suma
data facturii
termen plat
Cont

balan
proprietar
Comand

data comenzii
adresa livrare
pltit
cumparator
1
vnztor
1
1..*
1..*

7.11.2. Modelarea proceselor afacerii (prelucrrilor) Business
Model

Aceasta este o tehnic de modelare utilizat pentru a aprofunda nelegerea proceselor
specifice unei organizaii. Dei denumirea ar putea prea ntructva limitativ se folosete

acelai termen i pentru sistemele care nu informatizeaz o afacere, cum ar fi un sistem de
alarm sau un controler hardware.
Utiliznd UML, modelarea afacerii se poate face din dou perspective: fie prin
modelul cazurilor de utilizare, fie prin modelul obiectelor.
n cadrul modelrii cazurilor de utilizare (business use-case model) se surprinde
funcionarea sistemului din perspectiva utilizatorilor acestuia. Procesele se modeleaz prin
cazuri de utilizare, iar iniiatorii acestor procese prin actori (figura 7.43).
Modelul obiectelor (business-object model) surprinde prelucrrile din interiorul
sistemului. Descrie n detaliu cum este tratat fiecare caz de utilizare. Realizarea cazurilor de
utilizare se poate evidenia cu ajutorul diagramelor de interaciune (diagrama de secven,
diagrama de colaborare) sau al diagramei de activitate.
O entitate a sistemului existent (a afacerii) reprezint un lucru pe care utilizatorii l
acceseaz, consult, manipuleaz, realizeaz sau utilizeaz n cadrul unui caz de utilizare. O
unitate de lucru este un set de astfel de entiti care formeaz un ntreg pentru utilizatorul
final. Entitile i unitile de lucru sunt utilizate pentru a reprezenta aceleai concepte ca i
clasele din modelul mediului (comand, produs, factur, cont).

Sistem
Login / Logout
Comand articole
Administrare
Actualizare baz de
date
<< extends >>
<< extends >>
Utilizator
Administrator
Fig. 7.43. Modelarea proceselor afacerii cu ajutorul diagramei
cazurilor de utilizare

Fiecare utilizator, entitate sau unitate de lucru poate participa la realizarea a mai
multor cazuri de utilizare. De exemplu n figura 7.43. Utilizatorul particip la realizarea a
dou cazuri de utilizare, la fel i Administratorul.
Un astfel de model se dezvolt n doi pai:
- Realizarea modelului cazurilor de utilizare
- Detalierea modelului prin specificarea utilizatorilor, entitilor i a unitilor de
lucru, dar i a regulilor care guverneaz anumite procese sau obiecte.
Scopul este crearea unor utilizatori, entiti i uniti de lucru care rezolv problema
evideniat de cazul de utilizare eficient bine, rapid i la cel mai sczut cost posibil.
Modelarea mediului i modelarea afacerii par ntructva asemntoare, mai ales dac
ne gndim c entitile i unitile de lucru corespund claselor din modelul mediului. Exist
totui o serie de diferene, dintre care evideniem trei.
Cele dou abordri difer n primul rnd prin modul de documentare. Una se bazeaz
pe cunotinele unui expert n domeniu sau pe cunotinele despre sisteme similare, n timp ce
a doua are n vedere cerinele beneficiarului. Orice clas a modelului domeniului i regsete
Capitolul 7
222
originea n experiena cunosctorilor domeniului. Orice element al modelului afacerii (entitate
sau unitate de lucru) i regsete originea ntr-o cerin a beneficiarului. Acesta este i
motivul principal pentru care utiliznd cele dou abordri, n mod normal, se obin diferite
clase, atribute, metode i asocieri.
O alt deosebire ar fi c pornind la analiza domeniului vom obine mai multe
informaii despre atributele claselor i mai puine despre comportamentul acestora (clasele
domeniului vor fi srace n metode). Evident n cazul modelrii afacerii se vor identifica att
entitile i unitile de lucru (clasele), ct i utilizatorii (i operaiile pe care acetia le
ntreprind).
i nu n cele din urm, modelul afacerii fiind mult mai detaliat va fi mai bine
valorificat n etapele ce vor urma. Se pot identifica mai bine actorii i cazurile de utilizare ale
sistemului proiectat, i fiecare dintre acestea va putea fi mai bine pus n coresponden cu
cerinele sistemului.
Dac modelul mediului abordeaz cu precdere funcionarea sistemului n contextul
acestuia, modelul afacerii i focalizeaz atenia asupra utilizatorilor i a modului cum
sistemul i deservete.

7.11.3. Modelarea cazurilor de utilizare

Un model al cazurilor de utilizare este format din actori i cazuri de utilizare. Un
actor este o entitate extern ce interacioneaz cu sistemul (similar unei entiti externe dintr-o
diagram de flux a datelor). Actorul este ceva sau cineva care schimb informaie cu sistemul.
Un actor ne este obligatoriu s fie un utilizator uman. El poate fi i un alt sistem sau un
dispozitiv hardware (ex. monitorul) cu care sistemul nostru interacioneaz sau schimb
informaii.
Un caz de utilizare este o secven de aciuni iniiate de un actor, surprinznd un
anumit mod de a folosi sistemul. Nu trebuie fcut confuzie ntre actor al sistemului i
utilizator al sistemului. Un utilizator este oricine folosete sistemul. Un actor este un rol pe
care utilizatorul l poate juca. Numele actorului trebuie s indice acest rol. Un actor este un
tip sau o clas de utilizator. Acelai utilizator poate juca mai multe roluri. De exemplu, dac
domnul Y joac dou roluri, unul de instructor iar cellalt de consultant, va fi reprezentat ca
instan a unui actor numit Instructor i ca instan a unui alt actor numit Consultant.
Actorii fiind entiti externe sistemului, ei nu pot fi descrii n detaliu. Identificarea
actorilor ajut la identificarea cazurilor de utilizare ntruct un caz de utilizare este iniiat de
un actor. Iat cteva ntrebri la care analistul de sistem trebuie s rspund pentru a
identifica cazurile de utilizare:
- Care sunt principalele aciuni executate de fiecare actor?
- Actorul va citi sau va actualiza informaia din sistem?
- Actorul va informa sistemul despre modificrile petrecute n afara acestuia?
- Actorul va fi informat de modificrile din sistem?
S considerm cazul unui sistem de nregistrare a studenilor la cursurile oferite de un
centru de instruire. Entitile externe sistemului sunt studentul care se nscrie la curs, secretara
care face nscrierea studenilor la cursuri, casiera care ncaseaz contravaloarea cursurilor i
instructorul care pred cursurile. Cazurile de utilizare asociate sistemului sunt redate n figura
7.44.
Un caz de utilizare este iniiat ntotdeauna de un actor i poate interaciona i cu ali
actori, nu numai cu cel care l-a iniiat. Cazul de utilizare trebuie s redea o funcionalitate
complet i nu numai o anumit aciune a unei funcionaliti. Transmiterea unui formular de
nscriere la un curs este parte a procesului de nregistrare la curs deci va fi inclus n cazul de

utilizare nregistrare la curs i nu se va construi un caz separat pentru aciunea transmitere
formular de nscriere.
Observm n exemplul anterior etichetarea cu simbolul <<extends>> a asocierii dintre
cele dou cazuri de utilizare ceea ce semnific faptul c opional cazul de utilizare
nregistrare la curs special extinde cazul nregistrare la curs, adugndu-i noi aciuni i
comportamente. nregistrarea unui student la un curs special necesit i permisiunea
instructorului (aciune suplimentar), pe lng paii normali de nscriere la orice curs.
Este evideniat i o relaie de utilizare prin etichetarea cu simbolul <<uses>> a
asocierii dintre cazul nregistrare la curs i cazul nepromovare cursuri obligatorii ceea ce
semnific faptul c un caz de utilizare folosete cellalt caz de utilizare atunci cnd se
execut. nscrierea la cursul Y nu este posibil dect dac studentul a promovat cursurile
pregtitoare acestuia. Cazul nregistrare la curs folosete cazul nepromovare cursuri
obligatorii pentru a verifica dac studentul a promovat cursurile pregtitoare cursului Y.

Fig. 7.44. Sistem de nregistrare studeni

Diagrama cazurilor de utilizare arat care sunt toate cazurile de utilizare din sistem dar
nu indic modul n care acestea sunt realizate de ctre actori. Modelul cazurilor de utilizare
este completat de o descriere textual a fiecrui caz de utilizare, accentul punndu-se pe
interaciunea cu ali actori i mai puin pe modul n care este executat n cadrul sistemului.
Descrierea cazului de utilizare nregistrare la curs sub forma unei succesiuni de pai se face
ca n figura 7.45:

Cazul de utilizare: nregistrare la curs
Actori: Student, Secretar
Descriere:
Acest caz de utilizare se declaneaz atunci cnd
studentul solicit nscrierea la un curs. Secretara verific
dac studentul a parcurs cursurile pregtitoare i a
promovat examenele respective. Dac este vorba despre
un curs special, secretara solicit studentului aprobarea
instructorului. Secretara nregistreaz studentul la curs.
Fig. 7.45. Descrierea cazului de utilizare nregistrare la curs

Capitolul 7
224
Modelarea cazurilor de utilizare permite analiza cerinelor funcionale ale sistemului,
insistnd asupra a CE trebuie s fac un sistem existent sau un nou sistem, fr s se ia n
seam i CUM o s se fac. Modelul cazurilor de utilizare este dezvoltat n faza de analiz a
ciclului de via al sistemelor orientate obiect, avnd rolul de a ajuta dezvoltatorii s neleag
cerinele funcionale ale sistemului fr s intereseze n aceast faz cum vor fi implementate
acestea. Procesul este iterativ iar stabilirea cerinelor se face n urma discuiilor cu
beneficiarul sistemului. Cazurile de utilizare controleaz toate celelalte modele. Dac
cerinele utilizatorului se modific n timpul dezvoltrii, aceste modificri sunt vizibile mai
nti n modelul cazurilor de utilizare. Modificrile n cazurile de utilizare implic modificri
i n celelalte modele. i reciproca este valabil, adic n momentul n care se fac modificri
n modele, acestea trebuie s se reflecte i la nivelul cazurilor de utilizare.

7.11.4. Modelarea structurii statice (diagrama claselor, diagrama
obiectelor)

Diagrama claselor documenteaz structura static a sistemului; mai exact precizeaz
clasele care exist i relaiile dintre acestea, nu i modul n care interacioneaz pentru a
asigura un anumit comportament. Diagrama claselor poate de asemenea evidenia i alte
aspecte ale structurii statice, cum ar fi pachetele care ns vor fi prezentate mai trziu n cadrul
acestui capitol.
Construirea diagramei claselor presupune n primul rnd identificarea claselor din
sistem, acest proces reprezint o parte esenial a proiectrii sistemelor orientate obiect, de
succesul acestuia depinznd n mare parte succesul proiectului.
n acest sens, criteriile de apreciere a unui model al claselor sunt:
- obiectele claselor din model trebuie s poat furniza ntregul comportament cerut
sistemului;
- un bun model al claselor conine (pe ct posibil) clase stabile din domeniul
obiectual, care nu depind de funcionalitatea particular cerut la momentul
proiectrii.
Poate fi utilizat orice tehnic de obinere a claselor atta timp ct modelul obinut
respect criteriile enunate. Implicit dac modelul obinut nu respect criteriile nu va fi nimeni
interesat de tehnica utilizat, orict de profesionist ar fi aceasta.
n practic e puin probabil s reueti din prima. Clasele selectate n modelul de
proiectare se vor modifica pe parcursul desfurrii procesului iterativ de dezvoltare a
sistemului.
n literatura de specialitate se propun dou metode: proiectarea orientat pe date (data
driven design) i proiectarea orientat pe funciuni (responsibility driven design). Primul tip
de metode presupune identificarea tuturor datelor din sistem i mprirea lor pe clase, nainte
de a considera funciunile acestor clase. Tehnica identificrii substantivelor este cea mai
utilizat astfel de metod. Al doilea tip de metode, orientate pe funciuni, presupune
identificarea tuturor funciunilor sistemului i mprirea lor pe clase, nainte de a considera
datele acestor clase.
Tehnica identificrii substantivelor presupune doua etape:
- Identificarea claselor candidate, selectnd din specificarea cerinelor sistemului
toate substantivele i frazele substantivale (se consider substantivele la singular i
nu se aleg fraze ce conin sau ca unici candidai).
- Se elimin candidaii considerai nepotrivii din diverse motive i se redenumesc
clasele rmase dac este necesar.

Unele dintre motivele pentru care o clas candidat ar putea fi considerat nepotrivit
sunt:
- Redundana o clas e prezent sub mai multe denumiri. Este important s ne
amintim ins c obiecte similare pot s nu fie identice. Proiectantul decide dac
lucrurile sunt suficient de diferite pentru a merita clase diferite. De exemplu, dac
a fost selectat o pereche de genul mprumut i mprumut pe termen scurt,
acestea sunt diferite, dar numai la nivelul valorii atributelor. Se recomand n acest
caz alegerea unui nume care s desemneze ntreg coninutul clasei.
- Imprecizia cnd nu se poate spune precis ce care e realitatea descris de
substantivul respectiv. Desigur, trebuie ndeprtat ambiguitatea nainte de a putea
spune dac substantivul reprezint o clas.
- Eveniment sau operaie cnd substantivul se refer la ceva ce este fcut de
sistem. Uneori aceast situaie este bine modelat de o clas, dar nu este acesta
cazul obinuit.
- Metalimbaj unde substantivul face parte din modul de definire a cerinelor. Vom
utiliza substantive ca cerine sau sistem ca parte a limbajului de modelare i nu
pentru a reprezenta obiecte din domeniul problemei.
- Extern sistemului atunci cnd substantivul este relevant pentru a descrie
funcionarea sistemului, dar nu se refer la ceva din interiorul su.
- Atribut atunci cnd este clar c substantivul desemneaz o realitate simpl, fr
un comportament interesant, care este de fapt un atribut al altei clase. Numele
unui client ar putea fi un astfel de exemplu.

Fig. 7.46. Diagrama claselor pentru sistemul de gestiune a comenzilor

Diagrama obiectelor modeleaz instanele elementelor coninute n diagramele de
clase. O diagram obiectual arat un set de obiecte i relaiile dintre acestea la un anumit
moment. Diagramele obiectuale conin obiecte i legturi. Ca i celelalte diagrame, poate
Capitolul 7
226
conine note i restricii. Mai pot conine anumite pachete sau subsisteme, fiecare fiind
folosite pentru a grupa elementele modelului. Aceste diagrame se folosesc pentru modelarea
static a unui sistem, ca diagramele de clase, dar din perspectiva unor instane reale sau
prototip.
Crearea unei diagrame conceptuale se face intr-un singur mod, modelnd structura
obiectelor. Modelarea structurii obiectelor implic fotografierea obiectelor din sistem la un
anumit moment.
In figura 7.46. se prezint o posibil diagram a claselor pentru un sistem de gestiune a
comenzilor. Unii dintre clieni pot beneficia de credit comercial, dar alii trebuie s achite
nainte de livrarea comenzii (aceia pentru care operaia ClientEvaluareSituatie returneaz
valoarea slab).

7.11.5. Modelarea dinamicii sistemului

Pentru modelarea dinamicii sistemului, UML furnizeaz dou tipuri de diagrame, i
anume diagramele de interaciune (diagrama de secven i diagrama de colaborare) i
diagramele de comportament (diagrama de stare i diagrama de activitate) . Principala menire
a acestor diagrame este de a arata cum realizeaz sistemul un caz de utilizare sau un scenariu
particular dintr-un caz de utilizare. Pentru fiecare caz de utilizare se pot realiza mai multe
scenarii (din descrierea cazului de utilizare). Pentru fiecare astfel de scenariu se pot ntocmi,
nu este obligatoriu, o diagram de secven sau o diagram de colaborare (unele dintre
instrumentele CASE pot obine o diagram din alta).
Acest tip de diagrame nlesnete nelegerea cazurilor de utilizare mai dificile. Ele pot
de asemenea susine comunicarea n cadrul echipei de proiectare, n cazul n care de o aceeai
interaciune se ocup mai multe persoane sau grupuri de persoane. Nu e de ateptat s se
dezvolte astfel de diagrame pentru fiecare caz de utilizare sau pentru fiecare operaie, doar
dac beneficiile depesc costurile. n cazul n care se dispune de un CASE ce poate utiliza
aceste diagrame la generarea de cod, atunci devine profitabil s dezvoltam diagrame de
interaciune i diagrame de comportament.
Diagramele de secven descriu modul n care obiectele interacioneaz i comunic
ntre ele. Aceste diagrame permit focalizarea ateniei asupra secvenelor de mesaje, mai precis
asupra mesajelor care sunt trimise i recepionate de ctre obiecte.
Avantajul major al diagramelor de secven, fa de diagramele de colaborare este
posibilitatea de a reprezenta grafic trecerea timpului, fiind deci indispensabile n cazul
proiectrii de sisteme n timp real.
n figura 7.47 este reprezentat un scenariu al cazului de utilizare Comand articole
dintr-un sistem de comer electronic. Scenariul presupune c validarea utilizatorului se
finalizeaz cu succes i c exist un stoc nelimitat de produse.
Diagramele de colaborare permit evidenierea att a interaciunilor ct i a legturilor
dintre un set de obiecte care colaboreaz. Att diagramele de secven ct i cele de
colaborare vizualizeaz interaciunile, dar diagrama de secven ia n considerare timpul, pe
cnd cea de colaborare, spaiul.
Ca i diagramele de secven, diagramele de colaborare pot fi utilizate pentru
descrierea execuiei unei operaii, a unui caz de utilizare sau a unui scenariu de interaciune n
cadrul sistemului. n acest tip de diagram nu pot fi descrise mesajele concurente i asincrone.
Pentru a putea realiza o comparare a celor dou tipuri de diagrame n figura 7.48. a fost
reprezentat acelai scenariu ca i n figura 7.47.



Fig. 7.47. Reprezentarea unui scenariu cu ajutorul diagramei de secven
: Utilizator
: Cont_utilizator : Catalog_articole : Co_comenzi
Login ( user, parola )
Valideaz ()
: Articol
Caut_n_catalog ()
* [ pentru fiecare articol din list ] Detalii_articol
( articol_id )
Detalii_articol ()
return ( list_articole )
return ( info_articol ) return ( info_articol )
Adaug_articol ( articol_id )
return ( ok )

Fig. 7.48. Reprezentarea unui scenariu cu ajutorul diagramei de colaborare
: Utilizator
: Cont_utilizator : Co_comenzi
: Catalog_articole
1. Login ( user, parola )
9. Adauga_articol ( articol_id )
: Articol
2. Valideaz ()
3. Caut_n_catalog ()
5. detalii_articol ( art_id )
4. return ( list_art )
8. return ( info_art )
6.detalii_articol ()
7. return ( info_art )

Pn acum nu am amintit nimic despre modelarea "deciziei" unui obiect despre ceea
ce sa fac la primirea unui mesaj. Diagramele de interaciune pot reprezenta obiecte diferite
ale aceleiai clase care primesc acelai mesaj, dar rspund diferit. Acest comportament este
rezonabil de cele mai multe ori ntruct comportamentul unui obiect poate fi afectat i de
valorile atributelor sale. Pentru a putea implementa, ntreine sau testa o c1as este necesar s
nelegem relaiile de dependen care exist ntre starea unui anumit obiect i reaciile sale la
mesajele primite sau la alte evenimente. Diagramele de stare sunt acelea care nregistreaz
aceste dependene.
Capitolul 7
228
Pornind de aici, se pot folosi aproximativ aceleai notaii pentru a descrie activiti
complexe. Se consider c trecerea de la o activitate la alta atunci cnd prima activitate s-a
ncheiat este similar cu trecerea unui obiect dintr-o stare ntr-alta, semnificativ diferit de
prima, atunci cnd acesta primete un mesaj. Diagramele de activitate sunt o variaiune a
diagramelor de stare, adaptate pentru a evidenia conexiunile i dependenele dintre activiti.
Ele sunt extrem de folositoare atunci cnd se apreciaz c o activitate trebuie s execute o
serie de task-uri diferite i dorim s modelm dependenele eseniale dintre acestea, nainte de
a decide n ce ordine s se execute.

Diagramele de stare au rolul de a captura ciclul de via al obiectelor, subsistemelor i
sistemelor, prin specificarea strilor n care se poate gsi un obiect i a evenimentelor (mesaje
primite, erori, condiii care devin adevrate) care-i afecteaz starea de-a lungul execuiei. O
diagram de stare poate fi ataat oricrei clase care are stri c1ar identificabile i un
comportament complex.
Presupunnd c este vorba despre un sistem contabil, diagrama ce descrie
comportamentul clasei Factur este reprezentat n figura 7.49.

Fig. 7.49. Diagram de stare

O diagram de activitate constituie o variant a diagramei de stare, cu un scop puin
diferit, acela de a evidenia aciuni i rezultate ale acestor aciuni. De fapt, diagramele de
activitate constituie o cale alternativ de descriere a interaciunilor, cu posibilitatea de
specificare a aciunilor care se vor realiza, prin precizarea urmtoarelor elemente:
- Ce fac aciunile? (modificrile strilor obiectului),
- Cnd au loc aciunile? (secvena de aciuni) i
- Unde au loc aciunile?
Diagramele de activitate pot fi utilizate i pentru a descrie cum se desfoar cazuri de
utilizare individuale i cum depind de alte cazuri de utilizare.
Diagramele de activitate pot fi folosite n mai multe scopuri i anume:
- Ilustrarea aciunilor care vor fi realizate atunci cnd este executat o operaie.
Acesta este i cel mai comun caz de utilizare a acestui tip de diagram.
- Prezentarea activitii interne a unui obiect.
- Identificarea aciunilor, care pot fi realizate n mod legat i stabilirea modului n
care aceste seturi de aciuni afecteaz obiectele din jur.
- Ilustrarea modului n care instana unui caz de utilizare poate fi realizat n
termenii aciunilor sau modificrilor intervenite n starea obiectului.
- Ilustrarea modului n care este organizat munca actorilor, care este organizarea i
obiectele folosite.

Activitile realizate la biroul de recepie a unui hotel se pot modela cu ajutorul
diagramei de activitate astfel (figura 7.50.):



Fig. 7.50. Diagrama de activitate pentru recepia unui hotel

7.12. Proiectarea BDOO component a sistemului
informatic

Este tiut faptul c orice sistem informatic sau aplicaie informatic ce opereaz cu
volume mari de date face apel la un mod sau altul de organizare a datelor. De modul de
organizare a datelor depinde n mare msur i performanele sistemului informatic.
Organizarea datelor n baze de date orientate obiect constituie cel mai evoluat mod de
organizare. ntr-o astfel de situaie se poate spune c BDOO constituie o component
semnificativ a sistemului informatic iar proiectarea acesteia are loc n cadrul general de
proiectare a sistemului informatic.
Pentru moment ne vom referi doar la proiectarea strict a BDOO ntr-o form
simplificat privind sistemul de aprovizionare cu materii prime i materiale iar ntr-un
urmtor paragraf vom recurge la proiectarea BDOO ntr-o form extins, mult mai
cuprinztoare, pe exemplul unui sistem de rezervare i vnzri de bilete n transporturile
aeriene n concordan cu metodologia RUP.
n activitatea de proiectare a BDOO pentru aprovizionarea cu materii prime i
materiale vom adopta varianta de proiectare plecnd de la identificarea/cunoaterea cerinelor
sistemului n funcie de care vom recurge la identificarea claselor de obiecte cu structura
corespunztoare.
n concordan cu UML succesiunea pailor de urmat va fi: modelarea proceselor de
afaceri, modelarea cazurilor de utilizare i modelarea structurii statice a sistemului.

7.12.1. Modelarea proceselor de afaceri

Aa dup cum s-a mai precizat, prin modelarea proceselor de afaceri se va urmri
aprofundarea i nelegerea modului de derulare a proceselor ocazionate de activitatea de
aprovizionare cu materii prime i materiale pentru ndeplinirea planului de producie.
Sinteza i succesiunea logic de derulare a acestor procese este redat n figura 7.51.
Capitolul 7
230
Fig.7. 51. Diagrama sintetic a fluxului informaional pentru activitatea de aprovizionare
NOMENCLATOR DE
PRODUSE FINITE
ELABORARE PLAN
DESFACERE
DETERMINAREA
STRUCTURII PRODUSELOR
DETERMINAREA
NECESARULUI DE REPERE
ELABORARE PLAN
PRODUCIE
REPERE DIN PRODUCIA
PROPRIE
REPERE
ACHIZIIONATE
NECESAR DE
MATERII PRIME
PLAN APROVIZIONARE
DE MATERII PRIME
PROSPECTARE
PIAA
CONTRACTARE
DERULARE
CONTRACTARE
PLAN APROVIZIONARE DE
REPERE
PROSPECTARE
PIAA
CONTRACTARE
DERULARE
CONTRACTARE



GRAFIC DE
APROVIZIONARE
PLAN
APROVIZIONARE
STOCURI
PRODUSE
CONTRACTE
COMENZI
NOMENCLATOR.
PRODUSE

CAPACITATE.
DE
PRODUCTIE.
PLANUL DE
DESFACERE
PLANUL DE
PRODUCTIE
SITUATIA
NECESARULUI DE
REPERE
FIA PRODUSE.
SITUATIA
NECESARULUI DE
MATERII PRIME

NECESAR
REPERE
FIA PRODUSE
FIA
TEHNOLOGICA
PLAN
PRODUCTIE
SITUATIA
NECESARULUI DE
APROVIZIONAT

SITUATIE. STOC
EXISTENT
SITUATIA
FURNIZORILOR
POTENIALI FURNIZORI
ELABORAREA PLANULUI
I GRAFICULUI DE
DESFACERE
ELABORARE. PLAN
PRODUCTIE
DETERMINAREA.
STRUCTURII
PRODUSULUI-REPERE
DETERMINAREA
NECESARULUI. DE
MATERII PRIME PENTRU.
REPERE DIN PRODUCTIE
PROPRIE
DETERMINARE
NECESESAR DE
APROVIZIONAT
IDENTIFICARE
FURNIZORI POTENIALI
- - - - - - - -

CERERI DE OFERTE
LANSAREA
CERERILOR DE
OFERTE
- - - - - - - -

OFERTE
SITUATIA.
COMPARATIV
A OFERTELOR

ALEGEREA OFERTEI
OPTIME
A
Capitolul 7
232

Fig. 7.52. Diagrama de detaliu a fluxului informaional pentru
activitatea de aprovizionare

Din schema prezentat pot fi reinute dou aspecte eseniale i anume, pe de o parte,
succesiunea logic a proceselor iar, pe de alt parte, faptul c planul de aprovizionare se face
separat pentru achiziionarea de repere i separat pentru achiziionarea de materii prime i
materiale necesare confecionrii reperelor prin producie proprie.
n figura 7.52. sunt redate ntr-o form mai detaliat aspectele cu privire la activitatea
de aprovizionare. Urmrind figura 7.52. pot fi deduse trei aspecte eseniale i anume:
- pe axul schemei sunt precizate procesele de afaceri (proceduri),
- pe partea din stnga axului schemei sunt specificate intrrile sistemului
(documente primare sau alte surse de intrare) pe baza crora se efectueaz
procedurile,
- pe partea din dreapta axului schemei sunt specificate ieirile sistemului
(documente primare de ieire) ca rezultate ale procedurilor efectuate.
n cele ce urmeaz vom cuta s facem o scurt prezentare a procedurilor evideniate
n figura 7.52, fr a avea pretenia unei lecii de managementul aprovizionrii.
CONTRACTAREA
I PERFECTAREA
CONTRACTULUI
CONTRACTE
FERME
A
DERULAREA
CONTRACTELOR
/ LANSARE COMENZI
COMENZI
NIR
RECEPIA MATERII
PRIME
AVIZ DE
EXPEDITIE.
FACTURA
STOCURI
RULAJE
INTRRI
DAREA N CONSUM
FIA LIMITA
BON DE
CONSUM
STOCURI
RULAJE
IEIRI

- Elaborarea planului i graficului de desfacere lund n considerare ca intrri
informaiile preluate din nomenclatorul de produse finite, stocurile de produse
finite existente, contractele sau comenzile ferme ncheiate cu beneficiarii precum
i capacitile de producie. Ca rezultate ale procedurii se vor obine Planul de
desfacere i Graficul de desfacere.
- Elaborarea planului de producie avnd ca intrri Planul de desfacere, Graficul de
desfacere i alte informaii, rezultnd ca ieire Planul de producie.
- Determinarea structurii produsului finit pe baza informaiilor preluate din Fia
produsului i Planul de producie rezultnd Situaia necesarului de repere.
- Pe baza Situaiei necesarului de repere se va proceda la determinarea necesarului
de repere de achiziionat i necesarului de repere obinute din producie proprie.
Planul de aprovizionare va fi elaborat separat pe cele dou categorii de repere aa
cum se sugereaz i n figura 7.51.
- Determinarea necesarului de materii prime pentru reperele din producia proprie
pe baza informaiilor de intrare preluate din Situaia necesarului de repere, Planul
de producie, Fia produsului (consumurilor specifice de materii prime pe reper) i
Fia tehnologic rezultnd ca ieire Situaia necesarului de materii prime.
- Determinarea necesarului de aprovizionare i elaborarea Planului i Graficului
de aprovizionare, innd seama de Situaia necesarului de materii prime, Situaia
stocurilor existente i preliminare (finale).
- Identificarea furnizorilor poteniali. Pe baza Situaiei necesarului de materii prime
i a informaiilor despre furnizorii poteniali preluate din Baza de date -
furnizorii va fi elaborat Situaia furnizorilor poteniali.
- Lansarea cererilor de oferte. Pe baza informaiilor privind Situaia furnizorilor
poteniali se va proceda la lansarea cererilor de oferte. Cu ct vom cunoate mai
muli furnizori poteniali i crora le vom lansa cereri de ofert cu att vom avea
anse sporite de a realiza o tranzacie comercial mai fericit (mai avantajoas).
- Alegerea ofertei optime fcnd apel la un model de alegere bazat pe teoria
deciziilor multicriteriale, cum ar fi metoda Von Neumann-Morgenstern,
ELECTRE sau o alta dintre cele cca. 20 existente.
- Se va obine Situaia comparativ a ofertelor (Matricea decizional), care nu
nseamn altceva dect un clasament al ofertelor realizat pe baza punctajului
global (criteriu global) acordat fiecrei oferte, lund n considerare o serie de
criterii cu ponderi de importan difereniate. Procedura poate fi extins cu
simularea tratativelor comerciale, modificnd valorile anumitor parametrii din
cadrul Matricei decizionale ca urmare a unor faciliti scontate a fi dobndite pe
parcursul desfurrii tratativelor comerciale. Cu modificrile astfel efectuate se
ntocmete noul clasament al ofertelor. Vor fi reinute primele dou sau trei oferte
mai bine clasate, pentru care se vor purta tratative comerciale cu furnizorii. n
funcie de rezultatele obinute n urma negocierilor se va alege oferta optim.
- Contractarea i perfectarea contractului. Pentru oferta optim se va elabora
contractul care apoi va fi perfectat de ctre factorii de decizie ai unitii beneficiare
i furnizoare.
- Derularea contractelor/lansarea comenzilor de aprovizionare n concordan cu
Planul de producie i Graficul de aprovizionare.
- Recepia materiilor prime pe baza Facturii sau Avizului de expediie i ntocmirea
NIR. NIR-ul va constitui documentul justificativ pe baza cruia se va opera, pe de
o parte asupra stocurilor de materii prime iar, pe de alt parte, se va consemna
intrarea de materii prime n contabilitate Rulaje intrri.
Capitolul 7
234
- Darea n consum a materiilor prime pe baza Fiei limit de consum sau Bonurilor
de consum. Totodat se va opera n Rulajul ieirilor i asupra Stocurilor cu
diminuarea acestora corespunztor cantitilor eliberate.

Observaie. n mod asemntor se va proceda i pentru achiziionarea reperelor.

7.12.2. Modelarea cazurilor de utilizare

Pe baza modelrii proceselor de afaceri au fost desprinse cazurile de utilizare a cror
diagrame sunt redate n figura 7.53, astfel:
Elaborarea planului de desfacere,
Elaborarea planului de producie,
Determinarea structurii produselor pe repere,
Determinarea necesarului de materii prime pentru repere din producie intern,
Determinarea necesarului de aprovizionat,
Prospectarea pieei
Identificarea furnizorilor poteniali,
Lansarea ofertelor,
Primirea ofertelor
Contractarea
Evaluarea ofertelor,
Simularea tratativelor comerciale,
Alegerea ofertei optime
Perfectarea contractelor,
Derularea contractelor,
Lansarea comenzilor,
Recepia materialelor
Acceptare,
Refuz parial
Refuz total
nregistrarea n fia de magazie,
Achitarea facturilor
Achitare parial,
Achitare total
nregistrarea n contabilitate.
Pentru fiecare caz de utilizare se precizeaz denumirea i actorii ce declaneaz cazul
de utilizare. Pot fi observate situaiile n care un actor particip la unul sau mai multe cazuri
de utilizare sau situaia n care la un caz de utilizare particip unul sau mai muli actori.
Totodat, n figura 7.53. pot fi observate utilizarea relaiilor de generalizare (situaiile
Refuz marf i Achitare facturi), de incluziune <include> sau de extensie <extend> ntre
cazuri de utilizare.
De remarcat faptul c fiecare caz de utilizare poate fi extins cu o descriere detaliat pe
baza creia s poat fi elaborate alte tipuri de diagrame necesare.



Elaborare plan
desfacere
funcionar
marketing
Elaborare plan
producie
include
Determinare structura.
productiei. pe repere
Determinare necesar de
materii prime pentru.
repere din productia.
intern
funcionar departament
desfacere
funcionar
departament
producie
tehnolog
funcionar
serviciu. plan
funcionar
aprovizionare
Determinare necesar
de aprovizionat
Prospectarea
pieei
funcionar
marketing
gestionar
Identificare.
furnizori
poteniali
Lansare
oferte
Primire
oferte
include
include
Evaluarea
ofertelor
Simularea
tratativelor
comerciale
Alegerea ofertei
optime
include
Contractare
extend
funcionar
aprovizionare
A
Capitolul 7
236
Fig. 7.53. Diagrama cazurilor de utilizare

extend extend
extend
Derulare
contracte
Recepie
materiale
Refuz
marf
extend
Parial Total
Achitare
parial
Achitare
total
Achitare
facturi
nreg. n
contabilitate
extend
nregistrare
n
fia magazie
Lansare
comenzi
gest.
A
Perfectarea
contractelor
Director
economic.
beneficiar.
jurist
beneficiar
manager.
beneficiar.
manager
furnizor
director
economic
furnizor
jurist.
furnizor
Funcionar
financiar
Funcionar
aprovizionare
Funcionar
contabilitate

Fig. 7.54. Diagrama claselor de obiecte Modelul static
1+
SECIE-PROD.
COMENZI
CONTRACTE
DESFACERE
PRODUS
1+

CANT-COMANDAT
BON-CONSUM
1+
STRUCTURA-PRODUS
- REPERE -
1+

MATERIAL
FURNIZOR
FACTUR

CANT-CONSUM.
GESTIUNE STOC

CANT-RECEPIONAT

CANT-FACTUR
PRE-APROV.
COT-TVA
NIR

CANT-CONTRACT
TERMEN-LIVR.

COMENZI
CONTRACTE
1+
1+
1+
1+
1+
1+
1+
Capitolul 7
238

FURNIZOR MATERIAL
- Den-furnizor: string - cod-mat: number
- Adresa-furnizor: string - den-mat: string
- cod-fiscal: integer - UM: string
- Den-banc: string - pret mediu integer
- cont-banc: string
- telefon: integer + creeaz ( )
- fax: integer + actualizeaz ( )
+ calc. pre. mediu ( )
+ creeaz ( ) + tergere ( )
+ actualizeaz ( ) + vizualizare ( )
+ tergere ( )
+ vizualizare ( )

STOC GESTIUNE
- cod mat: integer - den-gestiune: string
- cod gest: integer - cod-gestiune: integer
- stoc iniial: integer - nume-gestionar: string
- rata-stoc-iniial: integer - garan-gest: number
- stoc-normat: integer
- stoc-siguran: integer + creare gest ( )
- stoc-exist: integer + actualizare ( )
+ vizualizare ( )
+ creeaz ( )
+ calc. stoc. ex. ( )
+ calc. imobilizri ( )
+ calc-necesar-aproviz. ( )
+ actualizare

NIR BON CONSUM
- nr. NIR: number - Nr. bon: number
- data NIR: date - data bon: date
- cant. recep.: integer - cant. eliberat: integer

+ creeaz ( ) + creare ( )
+ vizualizeaz ( ) + adugare ( )
+ vizualizare ( )

239

FACTURA SECIE-PROD.
- Nr. fact.: number - den. secie: string
- Data fact.: Date - ef secie: string
- Explicaie: text
- Suma facturat: number + creare ( )
+ adugare ( )
+ valoare TVA ( ) + tergere ( )
+ valoare Factur + modificare ( )

COMAND COMANDA - MATERIAL
nr. comand: number cod mat.: number
data: date nr. comand: number
den-furnizor: string cant. comand: integer
cod-fiscal: number cant.-livrat: integer
adresa: string ternem-livrare: integer
den-banc: string
cont-banc: string + creare ( )
telefon: number + modificare ( )
termen-livrare: date + adugare ( )
destinaia-livr.: string

+ creare ( )
+ modificare ( )
+ adugare ( )

FACTURA MATERIAL
nr. factur: number
cod-mat: number
cant.-fact.: integer
pre-aprov.: integer
cota-tva: integer

+ creare ( )

Fig. 7.55. Clasele de obiecte modelarea claselor de obiecte

Capitolul 7
240
7.12.3. Modelarea structurii statice a sistemului

Rezultatul modelrii structurii statice va consta n Modelul static care va
reflecta multitudinea claselor de obiecte cu asocierile dintre ele. Clasele de obiecte pot fi
identificate din modelarea proceselor pe baza diagramelor cazurilor de utilizare.
Pentru exemplul de referin, clasele de obiecte i diagrama acestora sunt redate n
figura 7.54. Din considerente de lips de spaiu, descrierea detaliat a fiecrei clase este
redat separat n figura 7.55.
Diagrama claselor de obiecte astfel elaborat poate fi completat i cu alte
elemente desprinse din modelarea dinamic pe baza altor tipuri de diagrame. n final,
diagrama claselor de obiecte poate fi transpus ntr-un limbaj de programare
corespunztor, rezultnd astfel structura bazei de date orientate obiect pentru activitatea
de aprovizionare cu materii prime i materiale.

7.13. RUP-suport de realizare a sistemelor
informatice i implicit a BDOO

Rational Unified Process (RUP) este un proces general pentru dezvoltarea
orientat obiect de produse informatice. Este un ghid care arat cum se poate utiliza
practic UML (Unified Modeling Language) pentru a dezvolta un sistem informatic.
In RUP ciclul de via al proiectului unui sistem informatic este descompus n
patru faze, fiecare avnd asociat un rezultat final (determinarea obiectivelor, definirea
arhitecturii, implementarea funcionalitii i lansarea finala). La sfritul fiecrei faze
este efectuat o analiz pentru a determina dac obiectivele au fost ndeplinite. Trecerea
la urmtoarea faz se realizeaz numai n momentul satisfacerii obiectivelor fazei
curente. Fazele descrise de RUP sunt: explorarea iniial, elaborarea, construcia i
tranziia (figura 7.56.). Pe parcursul fiecrei faze se desfoar procese primare
(identificarea cerinelor, analiza sistemului, proiectarea sistemului, implementarea i
testarea) i procese suport (managementul proiectului, managementul schimbrii,
controlul mediului). n ceea ce privete procesele primare, n fazele iniiale predomin
procesele de identificarea cerinelor i analiz. Pe msura dezvoltrii iterative a fazelor
accentul se mut succesiv pe proiectare, implementare i testare. Procesele suport sunt
prezente ntr-o proporie constant pe parcursul ciclului de dezvoltare, cu excepia
procesului de management al schimbrii. Acesta este mai sczut n fazele iniiale (cnd
modificrile nu sunt cazuri de excepie, ci mai degrab regula) dar i intensific prezena
n final, cnd necesitatea unei modificri trebuie atent analizat i integrat pentru a nu
periclita succesul proiectului (cu ct proiectul este mai avansat cu att este mai dificil de
realizat modificri).

241

Fig. 7.56. Fazele i procesele RUP
PROCESE PRIMARE
PROCESE SUPORT
Identificarea cerinelor
Analiza
Proiectarea
Implementarea
Testarea
Managementul proiectului
Managementul schimbrii
Controlul mediului
ELABORARE CONSTRUCIE TRANZIIE EXPLORARE

7.13.1. Cele mai bune practici de realizare a sistemelor
informatice

Un proces este un o succesiune ordonat de pai necesari pentru atingerea unui
obiectiv. n cazul industriei software scopul este realizarea unui nou produs software sau
dezvoltarea unuia existent. RUP descrie o familie de subprocese corelate care folosesc o
structur i o arhitectur comun. Scopul procesului este acela de a asigura crearea unui
sistem informatic robust care ndeplinete criteriile impuse de utilizator, ntr-un orizont
de timp predictibil i n limitele bugetului alocat. Din acest punct de vedere RUP respect
ntocmai teoria clasic a managementului proiectelor care insist asupra acestor trei
restricii: calitate, timp i buget. RUP surprinde cele mai bune practici folosite n industria
software (dezvoltarea iterativ, managementul cerinelor, arhitectura bazat pe
componente, modelarea vizual, verificarea continu a calitii, controlul schimbrilor )
ntr-o form care poate fi adaptat pentru o plaj foarte larg de proiecte i organizaii. De
asemenea, RUP mbuntete comunicarea n cadrul echipelor descriind un limbaj i un
proces comun pentru toate persoanele implicate n proiect.
Unified Process descrie cum pot fi aplicate efectiv practici care s-au dovedit a fi
eficiente pentru echipele de dezvoltare software. Am utilizat acest termen de cele mai
bune practici nu att pentru c ar fi uor de cuantificat valoarea lor, ci pentru c sunt
practici utilizate n mod obinuit de organizaiile de succes din industria software.

Dezvoltarea iterativ. Abordarea tradiional n care se parcurg secvenial etapele
de definire a problemei, analiz, proiectare, realizare i testare pare s nu mai fie cea mai
potrivit dat fiind complexitatea actual a sistemelor informatice. Este necesar
dezvoltarea iterativ care asigur o mai bun cunoatere i nelegere a problemei pe
msur ce soluia efectiv se dezvolt pe parcursul a mai multor iteraii. RUP suport o
astfel de abordare iterativ care permite tratarea elementelor cu un grad ridicat de risc la
fiecare etap a ciclului de dezvoltare al proiectului, ceea ce reduce semnificativ riscul
ntregului proiect. Riscul pe ansamblu este combtut prin realizarea frecvent de versiuni
Capitolul 7
242
executabile ale sistemului prin care se poate obine implicarea i feedback-ul
beneficiarului. ntruct fiecare iteraie se finalizeaz cu o aplicaie executabil echipa
rmne concentrat pe rezultate, iar verificrile frecvente de stare asigur ncadrarea n
timp. Dezvoltarea iterativ asigur i o mai bun integrare a modificrilor care apar
ulterior n cerine, funcionalitate sau planificare.

Managementul cerinelor. RUP descrie cum se pot obine, organiza i documenta
cerinele funcionale i restriciile, cum se pot urmri negocierile i deciziile, cum se pot
identifica i comunica cu uurin cerinele procesului de afaceri. Noiunile de caz de
utilizare i scenariu s-au dovedit instrumente deosebit de eficiente n identificarea
cerinelor funcionale i transmiterea acestora la nivelul proiectrii, implementrii i
testrii produsului software, ceea ce a crescut considerabil ansele ca produsul final s
corespund nevoilor beneficiarului. Cu ajutorul cazurilor de utilizare se pot verifica att
pe parcurs ct i n final respectarea cerinelor formulate de beneficiar.

Arhitectura bazat pe componente. Procesul se concentreaz pe realizarea ct mai
devreme a unei arhitecturi robuste executabile, nainte de alocarea tuturor resurselor
pentru dezvoltarea aplicaiei. Structura dezvoltat n fazele iniiale va constitui nucleul pe
care se va dezvolta sistemul n continuare. RUP descrie cum se poate dezvolta o
arhitectur flexibil, adaptabil, uor de neles i care s susin utilizarea efectiv a
reutilizrii. UP suport dezvoltarea orientat pe componente. Componentele sunt module
non-triviale, subsisteme ce ndeplinesc o funcie clar. RUP ofer posibilitatea definirii
unei arhitecturi pe baza componentelor existente i a altora noi. Acestea sunt asamblate
ntr-o arhitectur bine definit ad-hoc sau ntr-o infrastructur bazat pe componente cum
ar fi Internet, CORBA i COM (pentru care exist o industrie nfloritoare de componente
reutilizabile).

Modelarea vizual. RUP promoveaz modelarea vizual a structurii i
comportamentului arhitecturii i componentelor sistemului. Mediile speciale de proiectare
asistat (CASE) ofer posibilitatea verificrii continue a consistenei i completitudinii
modelului proiectat. Utilizarea standardului UML, creat de Rational Software, reprezint
certitudinea unei modelri vizuale de succes.

Verificarea calitii. Performane i fiabilitate sczut a aplicaiilor este motivul
principal pentru care proiectele software sunt refuzate. Astfel calitatea trebuie verificat
pe parcurs insistnd asupra fiabilitii, funcionalitii, performanelor aplicaiei (software
i hardware). RUP asist dezvoltatorul n planificarea, proiectarea, implementarea,
execuia i evaluarea acestor teste. Evaluarea calitii este integrat n proces, n toate
activitile, implic toi membrii echipei, utilizeaz obiective msurabile i criterii, ea nu
este tratat ca o activitate separat ce trebuie s se desfoare la final de ctre un grup
restrns de oameni.

Controlul schimbrilor. Posibilitate de gestiune eficient a schimbrii
asigurarea unui mediu n care orice schimbare e posibil i posibilitatea de a urmri
schimbrile fcute este esenial ntr-un mediu n care schimbarea e inevitabil. RUP
asigur controlul, urmrirea i monitorizarea schimbrilor.

243
7.13.2. Individualizarea RUP

Dintre toate cele menionate mai sus, procesul unificat de dezvoltare de software
este individualizat de trei sintagme - orientat pe cazuri de utilizare, centrat pe arhitectura
sistemului, iterativ i incremental.

Proces orientat pe cazuri de utilizare
Scopul central al unui sistem informatic l reprezint satisfacerea cerinelor
utilizatorilor. Fie c acesta aduce noi funcionaliti sau doar mbuntete funcionaliti
existente el se dezvolt pornind de la cerinele utilizatorilor. Dac dorim un sistem care s
fie apreciat drept performant trebuie s acordm o atenie deosebit identificrii acestor
cerine.
n cazul acesta termenul de utilizator nu se refer strict la utilizatorul uman. Orice
alt sistem care interacioneaz cu sistemul pe care urmrim s-l construim este un
utilizator din punctul de vedere al sistemului nostru. Un exemplu de astfel de interaciune
ar putea fi considerat efectuarea unei rezervri prin intermediul unui sistem de rezervri
on-line. Persoana interesat solicit o rezervare, n urma unui schimb de informaii ntre
utilizator i sistem (persoana i definete mai precis cererea, sistemul de rezervare
prezint mai multe opiuni posibile), dar i n urma unei verificri a crii de credit
(verificare ce este fcut de un alt sistem specializat, utilizator al sistemului de rezervare)
se obine confirmarea de rezervare. O astfel de interaciune poart denumirea de caz de
utilizare. Un caz de utilizare reprezint o funcionalitate a sistemului care furnizeaz un
rezultat utilizatorului. Cu ajutorul cazurilor de utilizare se surprind cerinele funcionale
ale sistemului. Totalitatea cazurilor de utilizare formeaz modelul cazurilor de utilizare,
care descrie ntreaga funcionalitate a sistemului. Acest model nlocuiete tradiionala
specificare a cerinelor funcionale, dar nu numai att. Se obine cu ajutorul modelului
cazurilor de utilizare o mai bun focalizare pe client i cerinele acestuia i nu doar o
identificare a funciunilor pe care ar fi bine s le ofere sistemul. Dac n trecut cerinele se
identificau ca rspuns la ntrebarea: Ce trebuie s fac sistemul?, acum accentul cade pe:
Ce trebuie s fac sistemul pentru fiecare dintre utilizatorii si?
Este important de precizat faptul c modelul cazurilor de utilizare nu este doar un
instrument de identificare a cerinelor, ci el urmeaz s dirijeze ntreg procesul de
dezvoltare software, controlnd proiectarea, implementarea i testarea sistemului. Pe
parcursul ntregului proces modelul cazurilor de utilizare rmne ca un model de
referin, proiectanii dezvolt modele care implementeaz cazurile de utilizare, verific
modelele succesive i conformitatea acestora cu modelul cazurilor de utilizare, iar testerii
se asigur c modelul de implementare respect funciunile cazului de utilizare. n acest
mod cazul de utilizare nu este doar un punct de pornire ci este elementul de legtur al
procesului unificat de dezvoltare. Cazurile de utilizare sunt specificate, apoi proiectate i
n final sunt surs de construire a modelelor de testare. La fel de adevrat este ns c ele
nu sunt alese independent ci n corelaie cu arhitectura sistemului. Cazurile de utilizare
impun o anumit arhitectur, iar arhitectura sistemului influeneaz selectarea cazurilor
de utilizare, astfel cele dou se dezvolt n tandem pe msura parcurgerii ciclului de via
al sistemului.

Capitolul 7
244
Proces centrat pe arhitectur
Rolul arhitectului de sistem este similar aceluia de arhitect ntr-un proiect de
construcii. Arhitectul surprinde cldirea din mai multe puncte de vedere: structur,
amenajri, detalii, instalaii i toate acestea permit constructorului s aib o imagine de
ansamblu asupra cldirii nainte ca aceasta s fie construit. n mod similar arhitectul de
sistem descrie din diferite puncte de vedere sistemul ce urmeaz a fi construit.
Arhitectura de sistem cuprinde cele mai semnificante aspecte statice i dinamice
ale sistemului. Arhitectura sistemului i are originea n cerinele utilizatorilor, reflectate
n cazurile de utilizare, dar este influenat de mult mai multe aspecte, cum ar fi:
platforma software pe care va rula aplicaia (arhitectura calculatoarelor, sistemul de
operare, sistemul de gestiune a bazei de date, protocoale de reea i de comunicaie
utilizate), blocuri reutilizabile disponibile (GUI, DAO), consideraii de structur,
reglementri legale, cerine nefuncionale (performan, fiabilitate). Arhitectura este o
imagine a ntregului proiect ce evideniaz prile eseniale, ignornd detaliile. Cum
identificarea a ceea ce este esenial se face n mod subiectiv, calitatea arhitecturii
sistemului depinde de experiena celor implicai n realizarea ei. Cu toate acestea,
procesul unificat stabilete obiective de urmat pentru a optimiza calitatea arhitecturii
sistemului (lizibilitate, uurin n modificare, reutilizare).
Aa cum am mai evideniat n paragraful precedent, cazurile de utilizare i
arhitectura sunt puternic legate. Orice produs are o funciune i o form, n cazul
produselor informatice cazurile de utilizare reprezint funcionalitatea produsului, iar
arhitectura, forma acestuia. Cele dou pri trebuie armonizate pentru a obine un produs
calitativ. Funciunea ns, poate determina o anumit form (n cazul proiectului de
construcii dac se dorete realizarea unei sli de sport aceasta implic o form
predefinit) i forma poate restriciona funciunea (dup 1989 multe spaii de locuit au
fost amenajate ca spaii pentru birouri, faptul c ulterior a existat o cerere semnificativ
de cldiri cu destinaie de birouri susine faptul c reamenajarea, modificarea superficial
a formei, nu a susinut modificarea funciunii). n aceeai msur n cazul unui sistem
software, cazurile de utilizare trebuie s se potriveasc n arhitectur, iar arhitectura
trebuie s ofere cadrul general de utilizare al tuturor cazurilor de utilizare, nu numai a
celor iniiale ci i a cazurilor de utilizare posibile viitoare. Pentru a identifica acea form
care s permit sistemului s evolueze se practic identificarea funciunilor cheie ale
sistemului, a cazurilor de utilizare cheie. Chiar dac de cele mai multe ori acestea nu
reprezint dect 5-10% din totalul cazurilor de utilizare, ele reprezint esena sistemului.

Proces iterativ i incremental
Procesul de dezvoltare al aplicaiilor complexe din zilele noastre poate dura pn
la civa ani, motiv pentru care se practic n mod uzual mprirea proiectelor n
subproiecte. Un subproiect reprezint o iteraie i fiecare iteraie aduce un plus de valoare
(un increment) produsului final. De la o iteraie la alta produsul se mbogete, fie sub
aspect calitativ (mai ales n fazele iniiale ale proiectului, cnd se poate trece de la o
abordare superficial la o abordare mai n detaliu), fie cantitativ (n fazele finale ale
proiectului, cnd produsul dobndete noi funciuni).
Fiecare iteraie trateaz un set de cazuri de utilizare care mpreun sporesc gradul
de utilizare al produsului, dar i riscurile specifice asociate proceselor respective. n
cadrul fiecrei iteraii se vor identifica i specifica n detaliu cazurile de utilizare
245
corespunztoare, se va trece la proiectare lund n considerare i arhitectura sistemului, se
va implementa proiectul n componentele sistemului i n final se vor testa componentele
dac ndeplinesc cerinele surprinse de cazurile de utilizare de la care s-a pornit.
Avantajele unui astfel de proces iterativ sunt multiple. Dintre acestea amintim:
- reducerea costurilor de neconcordan cu cerinele iniiale; dac la un moment
dat este necesar reluarea unei iteraii, atunci pierderile sunt limitate la
costurile iteraiei respective;
- reducerea riscului de a lansa / finaliza produsul cu ntrziere, prin identificarea
din timp a riscurilor majore. n abordarea tradiional abia n momentul
testelor finale erau identificate probleme pentru a cror rezolvare proiectul era
ntrziat;
- accelerarea n ansamblu a ritmului de dezvoltare al proiectului; echipa este
mai bine focalizat pe rezultate i pe respectarea unui plan pe termen scurt;
- o mai bun implicare a beneficiarului, precum i rafinarea iterativ a cerinelor
acestuia. n plus acest mod de abordare permite un mai bun control al
schimbrilor datorate att mediului proiectului ct i modificrii specificaiilor
acestuia.
Iteraiile se planific iniial i rareori suport modificri (tiut fiind c orice
abatere de la un plan iniial implic costuri suplimentare). Acest mod de abordare nu
reprezint o scuz pentru un management haotic i nu implic o dezvoltare aleatoare.
Dezvoltare iterativ nu nseamn reproiectarea la infinit a aceluiai modul pn cnd n
sfrit se nimerete o variant care funcioneaz. Aceasta reprezint, din contr, un
instrument de planificare ce reduce, nc din fazele iniiale, riscurile ce ar putea afecta
buna desfurare a proiectului. Versiunile intermediare permit obinerea unui feedback
din partea tuturor celor interesai de proiect i corectarea din timp a eventualelor abateri
nregistrate.
Dac am reprezenta evoluia riscului ntr-o abordare iterativ, fa de evoluia
riscului n cazul modelului de dezvoltare n cascad, se observ c n abordarea iterativ
riscurile majore sunt eliminate nc din fazele iniiale ale proiectului, n timp ce n cazul
modelului n cascad riscurile scad substanial abia n momentul integrrii i testrii
aplicaiei figura 7.57.
Conform RUP, pentru realizarea unui sistem informatic, trebuiesc parcurse n
cadrul unei iteraii urmtoarele procese primare: identificarea cerinelor, analiza,
proiectarea, implementarea i testarea. n cele ce urmeaz vom prezenta mai pe larg
coninutul proceselor de identificarea cerinelor, analiz i proiectare. Pentru
exemplificarea diagramelor i tehnicilor de modelare UML a fost ales un sistem simplu
de rezervare a biletelor pentru o linie aerian. Au fost atinse urmtoarele probleme:
- organizarea sistemului utiliznd pachete;
- identificarea cerinelor sistemului cu ajutorul cazurilor de utilizare;
- modelarea cu diagrame de secven i de colaborare;
- analiza i proiectarea cu diagrama claselor i utilizarea tehnicii fielor CRC;
- modelarea comportamentului cu diagrame de stare i de activitate;
- modelarea componentelor software, distribuirii i implementrii;
- extinderea UML-ului cu diagrama entitate asociere pentru proiectarea bazelor
de date relaionale.

Capitolul 7
246

dezvoltare n
cascad
integrare,
testare
timp
gravitate
risc
iter.1 iter.2 iter.3
iter.
n
dezvoltare
incremental
iter.
n-1

Figura 7.

Fig. 7.57. Controlul riscului n dezvoltarea incremental

7.13.3. Identificarea cerinelor

Principalele activiti ce trebuiesc parcurse n aceast etap sunt:
- Identificarea cerinelor candidate (n documentaia de iniiere a proiectului,
care n acest caz poart denumirea de viziune);
- Structurarea sistemului (utiliznd pachetele);
- Aprofundarea nelegerii contextului (utiliznd fie modelul mediului, fie
modelul afacerii);
- Identificarea cerinelor funcionale (utiliznd modelul cazurilor de utilizare);
- Identificarea cerinelor non-funcionale.

Identificarea cerinelor candidate
n documentaia de iniiere a proiectului (viziune) se identific cerine posibile
pentru sistemul respectiv. Acestea se completeaz fie pe baza experienei, fie din notele
de interviu sau alte documente. Cel mai important document pentru identificarea acestor
cerine candidate rmne viziunea. n cazul sistemului de rezervare cerinele candidate ar
putea fi: rezervarea de bilete direct la companie sau prin intermediari (ageni de turism),
calculul automat al celei mai avantajoase rute (din punct de vedere al costului sau al
timpului), gestiunea automat a situaiilor speciale (anularea unei curse).

Organizarea sistemului utiliznd pachete
Una dintre sarcinile cheie ale modelrii sistemelor software de mari dimensiuni
este mprirea acestora n arii de mici dimensiuni, mai uor de manevrat. Fie c se
numesc domenii, categorii sau subsisteme, ideea de baz e aceeai: mprirea sistemului
n arii ce mprtesc o problematic similar.
247
UML introduce noiunea de pachet ca entitate de grupare a elementelor,
permind proiectanilor s mpart i s clasifice sistemele complexe. Pachetele pot fi
utilizate la orice nivel, de la cel mai nalt, unde sunt utilizate pentru a mpri sistemul n
domenii, pn la cel mai de jos nivel, unde se utilizeaz pentru a grupa cazuri de utilizare,
clase sau componente. n RUP, ca i n cazul altor metodologii orientate pe cazuri de
utilizare, aceasta poate constitui o prim etap. Sistemul de rezervare a fost structurat n
cinci subsisteme (reprezentate printr-o diagram a pachetelor, figura 7.58.): ntreinerea
flotei, sistem de urmrire a zborurilor, sistem de rezervare, sistem contabil, personal.

Sistem de rezervare
Sistem de urmerire a zborurilor Intretinerea flotei
Sistem contabil Personal

Fig. 7.58. Organizarea sistemului cu ajutorul pachetelor

Identificarea cerinelor sistemului cu ajutorul cazurilor de utilizare
Modelarea cu ajutorul cazurilor de utilizare este tehnica cea mai uoar i mai
eficient pentru identificarea cerinelor din perspectiva utilizatorului. Cazurile de utilizare
sunt folosite pentru a modela modul de funcionare al sistemului actual sau modul de
funcionare al sistemului dorit de utilizatori. Nu utilizeaz o abordare orientat obiect,
este mai degrab o modelare a proceselor, dar cu toate astea este o tehnic excelent de
iniiere a analizei orientat obiect a sistemului. Cazurile de utilizare sunt n general
punctul de pornire n analiza orientat obiect utiliznd UML.
Diagrama cazurilor de utilizare const din actori i cazuri de utilizare. Actorii
reprezint utilizatorii i alte sisteme ce interacioneaz cu sistemul analizat. Ele reprezint
n fapt un tip de utilizator i nu o instan a acestuia. Cazurile de utilizare reprezint
comportamentul sistemului, scenariile pe care acesta le execut ca rspuns la stimulii din
partea actorilor. Acestea se reprezint prin elipse.
n cazul exemplului nostru cazurile n care se face apel la sistemul de rezervare
sunt atunci cnd un pasager dorete s fac o rezervare sau atunci cnd acesta dorete s
anuleze o rezervare fcut anterior. O prim diagram a cazurilor de utilizare este
reprezentat n figura 7.59. ntr-o iteraie ulterioar aceast diagram va putea fi rafinat,
fiind identificate i alte cazuri de utilizare, cum ar fi confirmarea unui zbor.
Fiecare caz de utilizare este documentat printr-o descriere a scenariului.
Descrierea poate fi textual sau pe pai. n figura este prezentat i o descriere sub forma
unei succesiuni de pai pentru cazul de utilizare Rezervare zbor. Fiecare caz de
utilizare poate avea i alte proprieti, cum ar fi pre- sau post- condiii ale scenariului
condiii care trebuie ndeplinite nainte de nceperea execuiei scenariului sau condiii
care trebuie ndeplinite dup executarea scenariului. Diagrama de activitate reprezint un
instrument grafic pentru modelarea proceselor cazurilor de utilizare. Aceasta va fi
detaliat ntr-o seciune ce urmeaz.
Obiectivul final al oricrui proiect software este o aplicaie care rspunde tuturor
cerinelor beneficiarului. Prin identificarea i verificarea cerinelor se urmrete ca toate
cerinele s fie luate n considerare i sistemul s fie proiectat conform cerinelor
Capitolul 7
248
beneficiarului. Cel mai adesea cerinele sunt cuprinse ntr-un document (documentaia de
iniiere a proiectului sau viziunea), iar cazurile de utilizare sunt folosite pentru a corela
fiecare scenariu cu cerina pe care o trateaz. Modelarea sistemului cu ajutorul cazurilor
de utilizare ajut la identificarea cerinelor, dac acestea nu au fost identificate anterior.

1. Pasagerul solicita o anumita cursa vazatorului de bilete
2. Vanzatorul verifica disponivilitatea la linia aeriana
3. Linia aeriana comunica disponibilitatea biletului, furnizeaza detalii
despre cursa
4. Vanzatorul comunica pasagerului detaliile zborului
5. Pasagerul solicita un loc, preferinte
6. Vanzatorul rezerva locul
7. Vanzatorul confirma rezervarea pasagerului
8. Vanzatorul solicita plata pasagerului
9. Pasagerul face plata catre vanzator
10. Vanzatorul face plata catre linia aeriana
11. Linia aeriana face confirmarea finala vanzatorului
12. Vanzatorul emite biletul pasagerului
Rezervare Zbor
Anulare Rezervare
Pasager LinieAeriana
Actor
Caz de utilizare
Descrierea cazului de utilizare sub forma unei
succesiuni de pasi
Substantivele
sunt posibile clase
Verbele sunt
posibile operatii

Fig. 7.59. Modelarea cu ajutorul cazurilor de utilizare

7.13.4. Analiza orientat obiect

Principalele activiti ce trebuiesc parcurse n aceast etap sunt:
- Rafinarea diagramei cazurilor de utilizare;
- Modelarea dinamicii sistemului (utiliznd diagrama de secven sau diagrama
de colaborare);
- Modelarea structurii statice (utiliznd diagrama claselor).

Rafinarea diagramei cazurilor de utilizare
n aceast etap se pot identifica i alte cazuri de utilizare i ali actori, la un alt
nivel de detaliu. n exemplul nostru am identificat n plus agenia de voiaj, ca intermediar
ntre pasager i companie. Odat cu introducerea acestui nou actor am mai luat n calcul
i necesitatea achitrii biletului pentru validarea rezervrii i alte situaii speciale care ar
trebui acoperite (achitare prin carte de credit, plat neacceptat). De asemenea n cursul
analizei proceselor de afaceri se poate dezvolta modelul al cazurilor de utilizare pentru
ntreg sistemul i se pot construi mai multe pachete pentru reprezentarea unor diverse arii
ale afacerii. Fiecare pachet poate fi apoi descompus i reprezentat printr-o diagram ce
conine cazurile de utilizare corespunztoare domeniului i interaciunile cu actorii.
Scopul este de a construi cte o diagram a cazurilor de utilizare pentru fiecare
scenariu al sistemului. Fiecare scenariu descrie o succesiune diferit de interaciuni ntre
actori i sistem, fr condiii SAU.
249
Modelarea structurii alternative prin relaii de tip Extends
n mod obinuit fiecare caz de utilizare se construiete dintr-o secven de aciuni,
dup care pentru fiecare pas se construiesc condiii de tip "what if" i se realizeaz noi
cazuri de utilizare pe baza acestor activiti alternative. Secvenele alternative sunt
cuprinse n cazuri de utilizare distincte conectate printr-o relaie de tip "Extends" de cazul
de utilizare iniial. Relaia de tip "Extends" poate fi privit ca relaie de motenire ntruct
cazul de utilizare ce extinde un alt caz de utilizare motenete i suprascrie
comportamentul acestuia. Presupunnd c achitarea biletului se face implicit prin
numerar, dar opional plata se poate face i prin carte de credit, cazul de utilizare
Achitare prin carte de credit extinde cazul de utilizare Achitare zbor (figura 7.60.).

Eliminarea comportamentului redundant cu ajutorul relaiilor de tip Uses
Pentru a elimina o secven de comportament redundant ce apare n cazuri de
utilizare diferite se poate modela acea secven ntr-un caz de utilizare distinct conectat
de cazurile de utilizare iniiale prin relaii de tip Uses. Relaia de tip "Uses" poate fi
privit ca fiind echivalent cu relaia de agregare. n exemplul nostru, fie c rezervarea se
face direct la linia aerian sau printr-o agenie de voiaj, o rezervare trebuie achitat pentru
a fi validat. Cazul de utilizare achitare zbor este utilizat att de Rezervare zbor, ct
i de Rezervare zbor prin agent (figura 7.60.).

Rezervare Zbor
Pasager LinieAeriana
Agentie de Voiaj
Rezervare Zbor
prin Agent
Achitare Zbor
Achitare prin
carte de credit
Plata neacceptata
<<extends>>
<<uses>>
<<uses>>
<<extends>>
<<extends>>

Fig. 7.60. Relaii de extindere i de utilizare ntre cazuri de utilizare

Cazurile de utilizare sunt folosite i pentru a construi scripturi de testare pentru a
verifica satisfacerea cerinelor beneficiarului de ctre aplicaie. Cnd se atinge nivelul cel
mai fin de descompunere, pentru fiecare caz de utilizare se poate realiza o diagram de
secven. Cu diagramele de secven i de colaborare se modeleaz implementarea
scenariului.

Modelarea dinamicii sistemului Diagramele de secven
Capitolul 7
250
Diagrama de secven este una dintre cele mai potrivite pentru a modela
interaciunile ntre obiectele sistemului. Se realizeaz cte o diagram de secven pentru
fiecare caz de utilizare. n timp ce cazul de utilizare modeleaz un scenariu din puntul de
vedere al utilizatorului, diagrama de secven conine detalii de implementare ale
scenariului, incluznd clasele i obiectele ce vor implementa scenariul i mesajele
transmise ntre obiecte. n mod obinuit se analizeaz descrierea cazului de utilizare
pentru a determina care sunt obiectele necesare pentru implementarea scenariului. Dac
descrierea a fost fcut sub forma unei succesiuni de pai obiectele se determin prin
parcurgerea acestor pai. ntr-o diagram de secven obiectele implicate n scenariu sunt
reprezentate prin linii punctate verticale, iar mesajele transmise ntre acestea prin vectori
orizontali. Mesajele se reprezint cronologic de sus n jos, spaierea pe orizontal a
obiectelor fiind arbitrar. Pentru cazul de utilizare descris mai sus prin pai (Rezervare
zbor) diagrama de secven este prezentat n figura 7.61. Se observ c paii din
descrierea cazului de utilizare se regsesc n secven de sus n jos.

Ionescu : Pasager Vlad : Vanzator Linie Aeriana
solicitare zbor
verifica disponibilitatea
detalii zbor
rezervare disponibila
transmite preferinte loc
detalii zbor
rezerva loc
confirma rezervarea
solicita plata
face plata
face plata
confirmare finala
eliberare bilet

Fig. 7.61. Diagrama de secven pentru un scenariu

n cursul analizei mesajul poart denumirea din sistemul existent. Mai trziu, n
cursul proiectrii acesta este nlocuit cu denumirea metodei obiectului apelat. Metoda
apelat sau invocat aparine clasei instaniate de obiectul ce recepioneaz mesajul.

Modelarea dinamicii sistemului Diagramele de colaborare
Diagrama de colaborare reprezint o alternativ la diagrama de secven pentru
modelarea interaciunilor ntre obiectele sistemului. n timp ce n diagrama de secven
accentul cade pe succesiunea cronologic a mesajelor, n diagrama de colaborare accentul
251
cade pe identificarea i nelegerea tuturor efectelor pe care scenariul le are asupra unui
obiect (figura 7.62). Obiectele sunt conectate, fiecare legtur fiind o instan a asocierii
ntre clasele implicate. Legtura evideniaz mesajul transmis ntre obiecte, tipul
mesajului (sincron, asincron, simplu, opional -balking sau time-out) i vizibilitatea
obiectelor unele fa de altele.

Ionescu : Pasager
Vlad : Vanzator
Linie Aeriana
1: solicitare zbor
6: preferinte loc
10: face plata
2: verifica disponibilitatea
7: rezerva loc
11: face plata
3: rezervare disponibila
4: detalii zbor
12: confirmare finala
5: detalii zbor
8: confirma rezervarea
9: solicita plata
13:eliberare bilet

Fig. 7.62. Diagrama de colaborare pentru un grup de obiecte

Modelarea structurii statice cu ajutorul diagramei claselor
Diagrama claselor este instrumentul principal de analiz i proiectare a structurii
statice a sistemului. n ea se precizeaz structura claselor sistemului, relaiile ntre clase i
structurile de motenire. n timpul analizei diagrama este construit urmrind obinerea
unei soluii ideale. La proiectare se utilizeaz aceeai diagram i se modific pentru a fi
conform cu detaliile de implementare.

Dezvoltarea diagramei claselor pe parcursul analizei

Abordarea orientat pe cazuri de utilizare
n cazul analizei orientat pe cazuri de utilizare, diagrama claselor se construiete
pe baza informaiilor furnizate de cazurile de utilizare, diagramele de secven i
diagramele de colaborare. Obiectele identificate pe parcursul analizei sunt modelate n
termenii claselor instaniate de acestea, iar interaciunile ntre obiecte sunt transpuse n
relaii ntre clasele instaniate (figura 7.63).

Abordarea orientat pe responsabiliti
Tehnica fielor CRC este utilizat uneori ca extensie a UML-ului pentru o analiz
orientat pe responsabiliti. Definiiile claselor sunt rafinate pe baza responsabilitilor
lor i a altor clase cu care acestea colaboreaz pentru a ndeplini aceste responsabiliti.
Pentru fiecare clas se ntocmete o fi pe care se evideniaz responsabilitile clasei i
care sunt clasele cu care ea colaboreaz pentru a ndeplini aceste responsabiliti. Aceste
informaii se transpun direct ntr-o diagram a claselor, responsabilitile corespund
metodelor, iar colaborrile corespund asocierilor dintre clase (figura 7.64.).

+FurnizareDetaliiZbor() : void
+ConfirmareRezervare() : Boolean
+DisponibilitateRezervare : boolean
Linie Aeriana
+RezervaZbor()
+VerificaDisponibilitate()
Vanzator
NumePasager : char
NumarZbor : int
NumarRezervare : int
Rezervare Zbor
1 1..*
+Destinatie : char
+Plecare : char
+DataZbor : char
+OraZbor : char
+Pret : int
+NumarZbor : int
Zbor
1
1..*
+SolicitaZbor() : void
+FacePlata() : void
-NumePasager : char
#AdresaPasager : char
-CNP : unsigned long
Pasager
NumeCompanie : char
PretBilet : int
DataZbor : char
OraZbor : char
NumarZbor : int
NumarBilet : char
Bilet
1..* 1..*
-NumeAgentie : char
-AdresaAgentie : char
Agentie Voiaj
-LinieAeriana : char
+AdresaLinieAeriana : char
Agentie Linie Aeriana
numar zbor
numar rezervare
rezerva zbor
programeaza
este rezervat cu

Fig. 7.63. Diagrama claselor n etapa de analiz

253

Fig. 7.64. O extensie informal a UML tehnica fielor CRC
pentru analiza orientat pe responsabiliti

Pasager
Superclas: <none>
Subclase: <none>
Responsabiliti Colaboratori
Plata biletului Vanzator_bilet
Solicitare zbor Vanzator_bilet

Bilet
Superclas: <none>
Subclase: <none>
Afl pretul Companie, Pasager

Zbor
Superclas: <none>
Subclase: <none>
Locuri disponibile <none>

Vanzator_bilet
Superclas: <none>
Subclase: <none>
Verific disponibilitatea Companie, Zbor
Rezerv zbor Companie, Pasager

Pentru a afl preul trebuie
s colaborez cu pasagerul
i compania aerian

Companie
Superclas: <none>
Subclase: <none>
Furnizeaz detalii zbor Vanzator_bilet, Zbor
Confirm rezervarea Vanzator_bilet, Zbor

7.13.5. Proiectarea orientat obiect

Exist dou obiective principale pe care le urmrim n proiectarea unui sistem
informatic:
- obinerea ct mai rapid a sistemului care s respecte toate cerinele actuale la un
pre ct mai sczut;
- construirea unui sistem uor de ntreinut i adaptat pentru a rspunde unor viitoare
cerine.
Aceste obiective sunt vzute n mod tradiional ca fiind conflictuale; unul dintre
motivele pentru care tehnicile de proiectare orientate obiect au cucerit cu rapiditate piaa este
i concilierea acestor obiective conflictuale.
Ca i n cazul analizei principalele activiti ce trebuiesc parcurse n aceast etap
sunt:
- Modelarea structurii statice (utiliznd diagrama claselor);
- Modelarea dinamicii sistemului (utiliznd diagrama de stare sau diagrama de
activitate);
- Rafinarea diagramei cazurilor de utilizare (utiliznd diagrama de activitate);
- Modelarea arhitecturii sistemului (utiliznd diagrama componentelor i diagrama
de desfurare);
- Proiectarea bazei de date.
Accentul cade de aceast dat pe detaliile concrete ale implementrii sistemului.
Fiecare dintre modele abordate vin s completeze diagrama claselor / obiectelor care n final
va sta i la baza proiectrii bazei de date.
Proiectarea sistemului cu ajutorul diagramei claselor. Pe parcursul proiectrii
diagrama claselor este modificat pentru a lua n considerare detalii concrete ale
implementrii sistemului. Diagrama claselor poate fi dezvoltat ntr-o manier iterativ,
Capitolul 7
254
printr-o succesiune repetat a analizei, proiectrii i implementrii. Acest proces este adesea
referit ca round-trip engineering. Utilizarea unui CASE poate facilita acest proces oferind
posibilitatea implementrii ntr-un limbaj de programare cum ar fi C++ sau Java i invers,
reactualizarea diagramei claselor pornind de la cod (reverse engineering).

Fig. 7.65. Analiza i proiectarea iterativ, documentarea
cu ajutorul diagramei claselor

O preocupare esenial pe parcursul proiectrii este stabilirea arhitecturii sistemului.
Se poate opta ntre o aplicaie simpl ce va rula pe o singur main, un sistem client-server
sau un sistem multi-tier cu obiecte specializate pentru interfaa cu utilizatorul, logica aplicaiei
i pentru baza de date, fiecare putnd potenial s ruleze pe o alt platform. O posibilitate de
a gestiona o astfel de arhitectur complex este mprirea diagramei claselor n trei seciuni
diferite care s evidenieze clasele ce descriu interfaa cu utilizatorul (business layer), clasele
responsabile de logica aplicaiei (application layer) i clasele pentru stocarea datelor (data
layer). Aceasta se poate realiza fizic fie prin segmentarea diagramei claselor i utilizarea unei
diagrame distincte pentru fiecare seciune sau prin adugarea unei proprieti fiecrei clase,
proprietate care s identifice crei seciuni (tier) aparine clasa.
O component este un grup de obiecte sau componente care interacioneaz cu scopul
de a furniza un serviciu. O component este similar unei cutii negre pentru care serviciile
sunt specificate prin interfaa sau interfeele sale, fr a se preciza nimic despre componena
sau implementarea intern a componentei. Dezvoltarea bazat pe componente este procesul
care urmrete asamblarea componentelor celor mai potrivite n configuraia cea mai bun
pentru a obine funcionalitatea dorit pentru sistem. Componentele sunt reprezentate n
diagrama claselor din UML prin specificarea interfeei clasei sau pachetului. Exist dou
posibiliti de reprezentare pentru interfa, ca o clas cu stereotipul <<interface>> i lista
operaiilor suportate de interfa n seciunea destinat metodelor sau n variant prescurtat,
ca un mic cerc ataat printr-o linie continu de clas i preciznd denumirea interfeei n
dreptul cercului.
Exemplul din figura 7.66. arat c interfaa Afiabil a clasei Pasager pune la dispoziie
o operaie mut(x coord, y coord) pentru afiarea n GUI. Sunt evideniate ambele modaliti
255
de reprezentare. Interfaa Persistent a clasei Pasager ofer o operaie salveaz(store at) care ar
putea fi folosit de o clas sau component de acces la baza de date.

+mut(x coord, y coord) ()
+salveaz(store at) ()
Pasager
+mut(x coord, y coord) ()
interface
Afisabil
Afisabil
Persistent
GUI
<<uses>>
<<uses>>

Fig. 7.66. Proiectarea componentelor specificarea interfeei unei clase

Modelarea comportamentului cu diagrame de stare. n timp ce diagramele de
interaciune i de colaborare modeleaz comportamentul dinamic reprezentat de o secven de
aciuni ntre grupuri de obiecte ale sistemului, diagrama de stare este utilizat pentru a modela
comportamentul dinamic al unui singur obiect sau clas de obiecte. Se realizeaz cte o
diagram de stare pentru fiecare clas cu comportament dinamic semnificativ. ntr-o astfel de
diagram se surprinde secvena strilor pe care le parcurge un obiect al clasei pe parcursul
ntregului su ciclu de via ca rspuns la stimulii primii, dar i propriile rspunsuri i aciuni
ale obiectului. Mai concret, comportamentul unui obiect este modelat pornind de la starea sa
iniial i determinnd care sunt strile pe care le tranziteaz atunci cnd intervin diverse
evenimente. Se urmresc i aciunile pe care obiectul le efectueaz atunci cnd se afl ntr-o
anumit stare. Strile reprezint suma condiiilor obiectului la un moment dat. Evenimentele
sunt ntmplri care determin trecerea unui obiect dintr-o stare n alta. Strile de tranziie
caracterizeaz micarea dintr-o stare n alta. Fiecare stare de tranziie (reprezentat printr-o
linie continu ce leag cele dou stri ntre care se efectueaz tranziia) este etichetat cu
evenimentul care determin tranziia. Aciunile sunt efectuate de obiect atunci cnd acesta
sosete ntr-o stare (figura 7.67.).

Rezervare loc
Zbor
programat
Gata de
decolare
Permite
modificari la
clasa I
Locuri
disponibile la
clasa I
Locuri
disponibile
Locuri rezervate
Locuri clasa I
rezervate Soseste ora plecarii
Locuri la clasa I
Anulare
Anulare
Zbor rezervat
Zbor rezervat
Toate locurile ocupate

Fig. 7.67. Modelarea comportamentului dinamic al obiectului Zbor
cu ajutorul diagramei de stare

Diagrame de activitate. Diagrama de activitate este o diagram de flux utilizat pentru
a modela comportamentul sistemului. Ea poate fi folosit n mai multe situaii: pentru a
Capitolul 7
256
modela un caz de utilizare, o clas sau o metod mai complicat. Aa cum am mai spus ea
este similar unei diagrame de flux, diferena esenial fiind accea c o diagram de activitate
poate reprezenta procese paralele. Acest lucru este deosebit de important atunci cnd
diagramele de activitate sunt utilizate pentru a modela procesele de afaceri (multe din acestea
executndu-se n paralel) sau pentru a modela fire multiple de execuie n programarea
concurent.
Utilizarea diagramelor de activitate pentru a modela cazuri de utilizare. Diagrama de
activitate ofer un instrument grafic pentru a modela procesele unui caz de utilizare. Aceasta
poate fi folosit n completarea, sau n locul, unei descrieri textuale / liste de pai a cazului de
utilizare. O descriere textual, cod sau o alt diagram de activitate poate prezenta mai multe
detalii.
Utilizarea diagramelor de activitate pentru a modela clase. Pentru modelarea
comportamentului unei clase diagrama de stare este utilizat atunci cnd predomin
evenimentele asincrone. Diagrama de activitate se folosete cnd toate sau majoritatea
evenimentelor sunt urmare a unor aciuni interne. ntr-o astfel de diagram activitile
trebuiesc ataate claselor (figura 7.68.).

Linie aeriana Pasager Vanzator
Solicitare zbor
Verifica disponibilitatea
Furnizeaza detalii zbor
Furnizeaza optiuni si preturi
Alege zbor
Solicita plata Rezerva zbor
Achita bilet Confirma rezervarea
Emite bilet

Fig. 7.68. Diagrama de activitate

Modelarea componentelor software. Diagrama componentelor este utilizat pentru a
modela structura software-ului, incluznd dependenele ntre componentele software,
componentele n cod binar i componentele executabile. n diagrama componentelor se
257
modeleaz componentele sistemului, grupate uneori n pachete, i dependenele care exist
ntre componente (i pachete de componente) (figura 7.69.).
Modelarea distribuirii i implementrii. Diagrama de desfurare este utilizat pentru
a modela configuraia elementelor de procesare la momentul execuiei i distribuia
componentelor software, proceselor i obiectelor pe aceste elemente de procesare. Se pornete
de la identificarea nodurilor fizice i a comunicaiilor ce exist ntre acestea. Pentru fiecare
nod se precizeaz instanele componentelor care se stocheaz sau se execut pe nodul
respectiv. Se pot evidenia i obiectele componentei respective. Diagrama de desfurare
modeleaz doar componentele existente la momentul execuiei, ea nu surprinde i
componentele folosite doar la compilare sau linkeditare. Se pot modela i componentele care
migreaz dintr-un nod n altul, sau obiectele ce migreaz dintr-o component ntr-alta,
utiliznd relaia de dependen cu stereotipul <<becomes>> (figura 7.70).

Imprimanta
bilete
Statie de
lucru in
aeroport
Server
Firewall Statie de
lucru la
agentia de
turism
Imprimanta
bilete
Calculatoare
clienti (acasa)
Conexiune
Internet
LAN
Acces read-only

Fig. 7.70. Modelarea distribuirii sistemului cu ajutorul diagramei de desfurare

Proiectarea bazelor de date relaionale o extensie UML
Diagrama claselor prezint un mecanism neutru de implementare pentru modelarea
aspectelor ce in de stocarea datelor sistemului. Clasele persistente, atributele acestora i
relaiile dintre ele pot fi implementate direct ntr-o baz de date orientat obiect. Cu toate
SGBD Print Server
Statie de lucru
Plan de zbor
Sistem de rezervare

Fig. 7.69. Modelarea componentelor cu ajutorul diagramei
componentelor
Capitolul 7
258
acestea, n prezent, bazele de date relaionale rmn modalitatea de stocare a datelor cea mai
uzual. Diagrama claselor din UML permite modelarea unor aspecte specifice proiectrii
bazelor de date relaionale, dar nu acoper n ntregime aceast problematic, de notat faptul
c nu prevede noiunea de atribute cheie care sunt mecanismul principal de relaionare a
tabelelor. Pentru a surprinde mai bine aceste aspecte este bine s se apeleze la diagrama
entitate asociere (ER), n completarea setului de diagrame propus de UML. Diagrama claselor
poate fi utilizat pentru a modela logic baza de date, independent de faptul c se alege o
implementare relaional sau orientat obiect, prin clase reprezentndu-se tabelele, iar prin
atribute coloanele acestora. Dac se alege pentru implementare un mediu relaional, atunci
diagrama claselor poate fi uor translatat ntr-o diagram logic entitate asociere. Claselor
persistente i atributelor acestora le corespund entitile logice i atributele lor, iar relaiilor
dintre clase le corespund relaii ntre entiti (figura 7.71).

Interfata cu
utilizatorul
Logica
aplicatiei
Datele
Diagrama claselor - UML
Diagrama entitate
asociere
Schema fizica
Schema fizica
Implementare OO
Translatare obiectual/relational
Translatare logic /
fizic
SGBDOO
SGBDR
SGBDR
Fig. 7.71. Proiectarea bazelor de date relaionale cu ajutorul diagramei entitate
asociere

Odat ntocmit aceast diagram se poate trece la proiectarea bazei de date
relaionale conform tehnicii normalizrii (prezentat ntr-un alt capitol).

Bazele de date obiect-relaionale-Standardul SQL3

259

Capitolul 8
Bazele de date obiectual
relaionale - Standardul SQL3

8.1. Modelul obiectual-relaional

Avnd n vedere faptul c att modelul relaional ct i modelul obiectual al bazelor de
date prezint avantaje i dezavantaje, n jurul anilor 1990 s-a conturat pentru prima dat ideea
de a reuni avantajele celor dou modele, prin extensia modelului relaional cu caracteristici
ale modelului obiectual i crearea unui hibrid de model obiectual-relaional. Dup lungi
dezbateri, n 1999 grupul de lucru SQL a finalizat i adoptat un subset a modelului de date
obiectual-relaional. n 2003 grupul de lucru SQL a oferit suport deplin pentru submodelul
obiectual-relaional cunoscut sub denumirea de SQL-3.
Corespunztor acestui model, o baz de date obiectual-relaional constituie un set de
clase de nivel nalt, care sunt populate de obiecte tuplu [40,21].
Un obiect tuplu este de forma <oid, val>, unde <oid> este identificatorul unui obiect,
iar <val> este o valoare tuplu a crei componente pot fi valori arbitrare, de genul: valori
primitive, seturi, tupluri i referine ctre alte obiecte.
Analiznd cele dou modele, obiectual-relaional i CODM, se poate constata c
principala diferen dintre ele const n faptul c pentru cel dinti structura de nivel nalt a
fiecrei instane obiect este ntotdeauna un tuplu, c acele clase sunt numite relaii, de unde
deducem i termenul de obiectual relaional.
n cel de al doilea model, structura de nivel nalt poate fi o valoare arbitrar.
Comparnd modelele obiectual-relaional i relaional tradiional se poate deduce faptul c,
modelul relaional poate fi privit ca un subset al modelului obiectual-relaional i, deci,
implicit a CODM.

8.2. Modelul SQL3 standard pentru BDOR

Modelul SQL3 constituie un alt standard de mare referin n materie de gestiunea
datelor obiectual-relaionale.
Comitetele de standardizare a SQL, ANSI (X3H2) i ISO (ISO/IEC/JTC1/SC21/WG3)
au avut o preocupare continu de a aduga noi caracteristici specificaiilor SQL pentru ca
acesta s devin suport al bazelor de date obiectual-relaionale (BDOR). Motivaia acestei
preocupri a constituit-o tocmai faptul c trstura principal a unui model obiectual,
Capitolul 8
260
comparativ cu modelul relaional, este bogia sistemului su de tipuri de date cu multiplele
avantaje oferite.
Prima versiune a standardului SQL a fost numit SQL86. Ea era bazat n mare parte
pe Limbajul SEQUEL, limbaj fcnd parte din proiectul System R al firmei IBM. O versiune
revizuit a lui SQL86 a fost publicat n 1989, versiune ce adaug i trateaz integritatea
referenial. n 1992 a fost publicat o alt versiune, sub denumirea de SQL92, ce aduce noi
caracteristici, cum ar fi: integritatea, domeniile, tabele temporare, noi tipuri de operaii de
jonciune, actualizarea schemelor bazelor de date, cu faciliti pentru cursor privind navigarea
n rezultatul unei cereri etc. n acest mod, SQL92 a ajuns a fi considerat limbajul standard
pentru baze de date relaionale. Ulterior, printr-o serie de extensii relevante privind modelarea
obiectual s-a ajuns la SQL3 (SQL3 2003), considerat a fi standardul pentru baze de date
obiectual-relaionale.
n cele ce urmeaz modelul de date utilizat de sistemele de gestiune a bazelor de date
obiectual-relaionale (SGBDOR) va fi numit modelul de date SQL3, deoarece este definit
prin limbajul de definire a lui SQL-3. El este compatibil cu modelul de date relaional, definit
n SQL-2. Astfel, n modelul SQL-3 este posibil s definim tabele SQL-2, cum ar fi tabela
PERSOANA, cu constrngerile de integritate ale lui SQL-2:

CREATE TABLE persoana(
marca INTEGER primary key,
nume CHAR(30),
prenume CHAR(30),
cnp INTEGER,
data-nasterii DATE,
localitatea CHAR(25));

Totui, abordarea sugerat n modelul obiectual-relaional nseamn mai nti s se
defineasc un tip pentru tupluri, care apoi s-l fac reutilizabil.
In definirea oricrui tip este posibil s folosim constructorii de tip complex, care n
mod semnificativ extind noiunea de domeniu prezent n SQL-2. Disponibilitatea
constructorilor de tip este prima mare diferen fa de bazele de date relaionale clasice.
Cele mai semnificative caracteristici cu care a venit SQL3, ca suport pentru structurile
orientate obiect sunt:
- tipuri definite de utilizatori, regsite anterior sub denumirea de tipuri de date
abstracte;
- tipuri rnd;
- tipuri referin;
- constructori pentru tipuri de rnd i tipuri de referin;
- constructori de tip pentru tipuri de colecii (seturi, liste i multiliste);
- funcii i proceduri definite de utilizator;
- suport pentru obiecte mari (BLOB-uri i CLOB-uri);
- valoarea de pe nivelul cel mai nalt a fiecrui obiect, n SQL3, este un tuplu.
Tuplurile i seturile pot fi imbricate.

Prin toate aceste caracteristici s-a urmrit ca SQL3 s devin, pe de o parte, un model
de date foarte puternic, permind reprezentarea datelor neconforme cu formatul tabelar
tradiional relaional, iar pe de alt parte, s dispun de capaciti puternice procedurale n
ideea de a-i conferi completitudinea de programare, asemntor altor limbaje de programare.


261
8.2.1. Noi tipuri de date n SQL3

Comparativ cu versiunile precedente, SQL3 ofer posibilitatea utilizrii unor noi tipuri
de date, pe care le vom prezenta n cele ce urmeaz:
Tipuri rnd (tuplu). Un tip rnd reprezint o secven de perechi de denumire de cmp
i tip de data asemntor definirii unei tabele. Dou rnduri sunt tipuri echivalente dac
amndou au acelai numr de cmpuri i fiecare pereche de cmpuri de pe aceiai poziie au
tipurile compatibile. Tipul rnd furnizeaz un tip de dat ce poate reprezenta tipuri de rnduri
ntr-o tabel, astfel c acestea pot fi stocate n variabile, trecute ca argumente n rutine i
returnnd astfel valori dintr-o funcie invocat. Aceast facilitate, de asemenea, permite
coloanelor dintr-o tabel s conin valori rnd. De exemplu:

CNP INTEGER,
Nume CHAR (30),
Adresa ROW (localitate CHAR (25),
Strada CHAR (25),
Blocul ROW (nr CHAR (4),
scara CHAR (2),
etaj INTEGER
apart INTEGER)));
INSERT INTO persoana
VALUES (1950126400237, VASILE , (Bucureti, Romana, (11, A2, 1, 79)));

n definirea tabelei PERSOANA, constatm prezena a dou atribute adresa i blocul
care sunt de tip ROW i astfel ele pot lua valori rnd.

Tipuri de obiecte mari BLOB i CLOB. Tipurile de obiecte mari (Large Object-
LOB) pot fi grupate n BLOB-uri i CLOB-uri. Tipurile BLOB (Binary Large Object) i
CLOB (Character Large Object) au fost definite ca suport pentru obiecte foarte mari.
Instanele acestor tipuri sunt memorate direct n baza de date, mai degrab dect existnd
menionate n fiiere externe. De exemplu:

CNP INTEGER,
nume VARCHAR (25),
profesia VARCHAR (15),
salariu INTEGER,
caracterizare CLOB (90K),
semnatura BLOB (2M),
poza BLOB (15M));

Tipurile LOB nu accept anumite operaii cum ar fi mai mare dect sau mai mic
dect, ns suport alte operaii cum ar fi cea de regsire, predicatul LIKE etc. Totodat, ele
pot suporta o serie de operaii specifice obiectului. Exemplu, pentru o poz: mrete,
micoreaz sau rotete poza.

Tipuri de date abstracte (TDA) n SOL3. Reamintim faptul c n CODM un tip
reprezint un set de reguli pentru structurarea datelor. Setul de obiecte ce se conformeaz
Capitolul 8
262
acelor reguli reprezint domeniul tipului. n acest context, precizm faptul c una din ideile de
baz care se afl n spatele posibilitilor obiect aduse de SQL3 este aceea c pe lng tipurile
normale, cum ar fi INT, CHAR, FLOAT etc., construite nuntru definirilor n SQL, pot fi
precizate i construite TDA.
Tipurile de date abstracte (Abstract Data Type-ADT) n SQL3 sunt numite tipuri
Definite de Utilizator - TDU.
Crearea unui astfel de tip separat de un tabel, dei folosind o sintax aproape identic
cu cea pentru crearea unui tabel, apare astfel:

CREATE TYPE Adresa (
localitatea CHAR (20),
strada CHAR (20),
numar INTEGER,
bloc CHAR (3),
apartament INTEGER);

O utilizare a unui astfel de tip poate fi ca un tip de dat coloan n cadrul unei tabele,
astfel:

CREATE TABLE persoana (
CNP CHAR (13),
nume CHAR (15),
prenume CHAR (15),
adresa Adresa,
profesia CHAR (20));

Tabela PERSOANA este primul nostru exemplu nonrelaional, ea avnd inclus un
atribut adresa de tip compus, dup oricare regul rezonabil de compoziie.
n acest mod utilizatorii au posibilitatea de a-i defini noi tipuri de date n mod
arbitrar, a le stoca i regsi exact ca pe un obiect de alt tip, cum ar fi integer. Mai mult,
pentru astfel de tipuri de date se pot defini de ctre utilizatorul care le-a creat i operaii
specifice. De exemplu, asupra tipului de date imagini s-ar putea defini operaii ca: rotete
imaginea, decupeaz, mrete rezoluia, comprim imaginea etc.
Un tip de date abstract definit de utilizator, precizeaz atribute i operaii ncapsulate
ntr-o singur entitate. La modul general, un TDA este analog cu definirea unei clase ntr-un
limbaj de programare orientat obiect, el specificnd un ansamblu de definiii de atribute i
declaraii de rutine. Toate instanele unui TDA partajeaz atributele i rutinele acestuia.
Aceste tipuri de date sunt etichetate abstracte pentru c sistemul de baz de date nu
are nevoie s tie cum se stocheaz datele TDA i nici cum funcioneaz metodele TDA. El
trebuie s tie doar ce metode sunt disponibile i tipurile de date de intrare/ieire pentru acele
metode.
n SQL3 atributele sunt considerate atribute stocate, respectiv, virtuale. Atributele
stocate reprezint cazul general de atribute utilizate n multitudinea limbajelor de programare
sub denumirea de cmpuri. Atributele virtuale, n alte limbaje de programare le regsim sub
denumirea de atribute derivate.
Totodat n SQL3 rutinele definite de utilizator (RDU) au semnificaia de metode, aa
dup cum vom vedea i n paragrafele urmtoare. Acum este uor s vedem cum se poate
extinde SQL, ca sistem relaional, cu noi tipuri i trsturi necesare pentru ca el s fie calificat
ca un sistem obiect:
CREATE TYPE Persoanatip AS (

263
PRIVATE
data-naterii DATE CHECK (data-naterii <DATE 2007-08-01),
PUBLIC
CNP INTEGER,
prenume CHAR (15),
nume CHAR (15),
adresa Adresa);

CREATE TYPE Angajattip UNDER Persoanatip AS (
marca INTEGER,
PRIVATE
salariu INTEGER,
comision INTEGER,
PUBLIC
studii CHAR (15),
sex CHAR (1),
MEMBER FUNCTION ctig RETURN integer)

CREATE TYPE BODY Angajattip AS
MEMBER FUNCTION ctig RETURN integer IS
BEGIN
RETURN salariu + comision;
END;

Exemplu anterior arat modul de creare a unui subtip ANGAJATTIP al supertipului
PERSOANATIP, recurgndu-se la proprietatea de motenire evideniat prin clauza UNDER
(Angajattip UNDER Persoanatip). ntr-o astfel de situaie, subtipul ANGAJATTIP, pe lng
proprietile i metodele sale, include i atributele motenite de la supertipul PERSOANATIP.
Deci, de reinut faptul c o instan a unui subtip este considerat ca o instan a tuturor
supertipurilor sale.
Limbajul SQL3 accept conceptul de substituionalitate adic ori de cte ori este de
ateptat o instan a supertipului n locul acestuia poate fi utilizat o instan a subtipului.
Prima instruciune CREATE TYPE din punct de vedere sintactic este similar cu
definirea unei tabele n concepia relaional (CREATE TABLE persoana). Deosebirea const
n faptul c acum noi definim un alt tip dect o tabel, tip ce conine definiri proprii ale
utilizatorului (exemplu tipul Adresa).
Comanda a doua este mult mai interesant. Ea definete un subtip Angajattip al
supertipului Persoanatip, ceea ce este specificat prin clauza UNDER.
n ambele cazuri se ilustreaz utilizarea unor atribute publice i private. Atributele
data-naterii, salariu i comision sunt private. Atributele private sunt utilizabile doar prin
intermediul unor rutine/metode imbricate n definirea TDA-ului. n mod implicit, vizibilitatea
unui atribut public sau privat este aceea a atributului imediat precedent.
Primul atribut a unui TDA, dac nu prevede specificarea vizibilitii, n mod implicit
el este public.
Totodat exemplul evideniaz folosirea de atribute nregistrate/stocate i atribute
virtuale/derivate. Un atribut/nregistrat este cazul implicit, cu o denumire i un tip de date.
Tipul de date poate fi orice tip de date cunoscut, inclusiv alte tipuri definite de utilizator.
Atributul Ctig este declarat cu ajutorul funciei ce comport o aceiai denumire.
Capitolul 8
264
Definirea tipului ANGAJAT include i definirea unei metode tip funcie cu denumirea
Ctig, prin intermediul creia sunt accesate dou atribute private Salariul i respectiv
Comision.
Referitor la TDU (n contextul SQL3) inem s facem urmtoarele precizri:
a) tipurile definite de utilizatori i justific utilitatea doar dac sunt incluse sau asociate
unor tabele, n care urmeaz a fi stocate i obiectele;
b) tipurile definite de utilizatori sunt necesare n urmtoarele dou principale situaii i
anume:
b1) Pentru a specifica cazuri particulare ale domeniilor unor atribute dintr-o tabel,
tocmai ca i tipurile primitive de ntregi sau iruri de caractere, astfel:

CREATE TABLE LICENIAI(
Liceniat REF (Angajattip),
Universitatea CHAR (20),
Facultatea CHAR (25),
Localitatea CHAR (20));

Se poate observa c sintaxa instruciunii CREATE TABLE este similar cu sintaxa
crerii unei tabele obinuite, cu unica deosebire c n definirea atributului Liceniat se
specific domeniul ca fiind un tip complex (ANGAJATTIP). Tipul REF (Angajattip)
precizeaz faptul c valoarea asociat atributului Liceniat trebuie s fie un OID a unui obiect
de tip ANGAJATTIP. Detalii despre tipul referin (REF) se regsesc n capitolul urmtor.
b2) Un TDU poate fi folosit pentru a specifica tipul unei tabele complete. Acest lucru
se realizeaz tot cu ajutorul instruciunii CREATE TABLE ns ntr-un alt mod. n acest
caz, n loc de enumerarea coloanelor/atributelor unei tabele se recurge la simpla
precizare/citare a TDU. Aceasta nseamn c toate tuplurile tabelei trebuie s aib
structura specificat de TDU.
Exemplu 1. Putem crea o urmtoare tabel bazat pe o definire prealabil, astfel:

CREATE ANGAJAT OF ANGAJATTIP;

n acest mod a fost creat tabela ANGAJAT plecnd de la un TDU numit
ANGAJATTIP. Tabelele construite ,,via CREATE TABLE OF sunt numite tabele tip.
Rndurile unei tabele tip sunt considerate a fi obiecte.

Exemplu 2. Considerm tabela PERSOANA creat anterior. In actualul context, ea
poate fi descompus n dou definiri, de forma:

CREATE ROW TYPE persoanatip(
Marca INTEGER primary key,
Nume CHAR(30),
Prenume CHAR(30),
Cnp INTEGER,
Data-nasterii DATE,
Localitatea CHAR(25));

CREATE TABLE persoana of type persoanatip;

Intr-o astfel de situaie, tipul PERSOANATIP poate de asemenea fi utilizat i n
definirea altor tabele, cum ar fi:

265
CREATE TABLE student of type persoanatip;
CREATE TABLE profesor of type persoanatip;
Observm c obiectelor i claselor din modelul orientat obiect le corespund tupluri i
tabele n modelul obiectual-relaional.
De remarcat faptul c n legtur cu metodele sau aa numitele rutine definite de
utilizator (UDR) exist o adevrat filozofie sub aspectele elaborrii lor n diferite limbaje de
programare sau n legtur cu clasificarea acestora. Toate acestea comport anumite
particulariti n funcie de limbajul de programare folosit, versiunile acestuia sau n funcie
de sistemul de gestiune a bazei de date obiectual-relaional (SGBDOR) care le
implementeaz. Ca o cerin, un SGBDOR trebuie s ofere o flexibilitate sporit n ceea ce
privete permisiunea ca rutinele UDR sa returneze valori complexe, care s poat fi
manipulate mai departe, cum ar fi tabelele. Totodat, un SGBDOR trebuie s ofere suportul
pentru suprancrcarea denumirilor funciilor cu scopul de a simplifica dezvoltarea de
aplicaii.
n SQL metodele pot fi de tip procedur sau funcie, ca i n alte limbaje de
programare. Ele la rndul lor pot fi clasificate ca metode constructor, de tergere sau de
manipulare (denumirea acestora sugereaz i scopul fiecreia). Metodele pot fi definite
complet n limbajul SQL sau ntr-un alt limbaj de programare standard, cum ar fi C/C++. n
situaia n care definirea metodelor se realizeaz n SQL , codul metodei va fi ncadrat ntr-un
bloc BEGIN END iar n final va fi stocat mpreun cu schema bazei de date n
dicionarul bazei de date. Dac corpul metodei este scris n limbajul C se va recurge la
specificarea unei clauze externe care va identifica ,,codul compilat stocat ntr-un fiier al
sistemului de operare. De exemplu, dac am dori s efectum o prelucrare a pozei
persoanelor stocate n baza de date i cunoscnd faptul c limbajul SQL nu poate realiza acest
lucru am fi nevoii s utilizm o metod furnizat din exterior, de forma:

METHOD poza ( ) RETURN BOOLEAN
CREATE METHOD poza ( ) FOR persoana
LANGUAGE C
EXTERNAL NAME file: /home/admin/poza;

ntr-o astfel de situaie, definirea tipului persoana include doar semntura metodei nu
i corpul acesteia. Actuala definire este dat folosind instruciunea CREATE METHOD, care
este asociat cu tipul persoana prin clauza FOR. Instruciunea precizeaz faptul c metoda
este scris n limbajul C i totodat indic mecanismelor SGBD legtura cu acea metod i
unde poate fi gsit spre a fi lansat n execuie.
Limbajul SQL3 ofer aceleai operaii ca i SQL2 pentru integrarea i actualizarea
tabelelor ns vine i cu anumite extensii pentru manipularea obiectelor, cum ar fi cele
referitoare la invocarea unor metode definite de utilizatori.

Exemplu 1. Se cere s se listeze numele, prenumele i ctigul angajailor care au
studii superioare:
SELECT A. nume, A. prenume, A. ctig
FROM angajat A
WHERE A. studii = superioare;
n cadrul cererii se observ c este invocat i funcia Ctig definit de utilizator.

Exemplul ., Se cere s se listeze marca, numele i prenumele tuturor angajailor ce au
un ctig mai mare de 2000 euro:

Capitolul 8
266
SELECT A.marca, A.nume, A.prenume
FROM angajat A
WHERE A.ctig > 2000;

In acest caz metoda Ctig este invocat n construcia unui filtru (A.ctig > 2000),
pe cnd n primul exemplu metoda era invocat n cadrul listei int a frazei SELECT.

Metodele n cadrul unui tip pot fi definite nc din faza de proiectare a bazei de date
sau pot fi adugate n timp. n cele ce urmeaz vom ilustra modul n care poate fi adugat o
nou metod la tipul ANGAJATTIP. n primul rnd este necesar adugarea unei declaraii la
structura deja existent, astfel:

ALTER TYPE Angajattip
ADD METHOD constructorangajat (
data-nasterii DATE,
CNP INTEGER,
marca INTEGER,
prenume CHAR (15),
nume CHAR (15),
strada CHAR (20),
numar INTEGER,
bloc CHAR (3),
apartament INTEGER,
salariu INTEGER,
comision INTEGER,
studii CHAR (15),
sex CHAR (1),
RETURN Angajattip;

Urmeaz s definim corpul metodei, astfel:

CREATE METHOD constructorangajat (
data-nasterii DATE,
CNP INTEGER,
marca INTEGER,
prenume CHAR (15),
nume CHAR (15),
strada CHAR (20),
numar NTEGER,
bloc CHAR (3),
apartament INTEGER,
salariu INTEGER,
comision INTEGER,
studii CHAR (15),
sex CHAR (1),
FOR angajattip
RETURN angajattip
LANGUAGE SQL

267
BEGIN
RETURN NEW angajattip ( )
data-nasterii (data-nasterii),
CNP (CNP),
marca (marca),
prenume (prenume),
nume (nume),
localitatea (localitatea),
strada (strada),
numar (numar),
bloc (bloc),
apartament (apartament),
salariu (salariu),
comision (comision),
studii (studii),
sex (sex),
END;

Pe lng cele precizate, o serie de alte detalii, pot fi gsite n capitolul urmtor cu
privire la implementarea SQL3 n ORACLE.
Din cele prezentate se poate desprinde concluzia c, actualmente avem de a face cu
trei mari categorii de SGBD-uri i anume SGBDR, SGBDOO i SGBDOR.
Compararea celor trei tipuri de SGBD-uri apreciem c este necesar i bine venit,
motiv pentru care n cele ce urmeaz vom recurge la acest lucru.

8.3. Compararea SGBDR cu SGBDOR

Comparnd SGBDR cu SGBDOR pot fi desprinse urmtoarele aspecte:
- Un SGBDOR este un SGBD relaional cu extensiile SQL3;
- Extensiile SQL3, includ: tipuri rnd, tipuri definite de utilizator, rutine definite de
utilizator, polimorfismul, motenirea, referine, identitatea obiectului, tipuri
colecii (set, liste, ARRAY), noi construcii de limbaj ce fac SQL3 complet
relaional, triggers i suport pentru obiecte mari Binary Large Objects (BLOBs)
i Character Large Objects (CLOBs). In acest mod putem construi tipuri de date
mult mai complexe plecnd de la tipuri atomice i tipuri definite de utilizatori
utiliznd constructori de tip. Exist constructori de tip i operatori corespunztori
tuturor tipurilor de date.
- Prin multitudinea tipurilor de date precum i posibilitatea implementrii
proprietii de motenire, SGBDOR ne ofer faciliti privind proiectarea unei
structuri de baz de date mai apropiat de starea natural a lucrurilor i totodat
mai eficient;
- Un SGBDR se caracterizeaz printr-o simplitate i stabilitate sporit fa de un
SGBDOR, ceea ce i confer o mai mare uurin de folosire;
- SGBDR tradiional folosete indexurile de tip arbore-B
+
, pentru a accelera accesul
la date;
- Ambele SGBD se caracterizeaz printr-o simplitate de dezvoltare datorit faptului
c asigur independena datelor fa de programare (aplicaii);
Capitolul 8
268
- Pentru SGBDR exist standardul SQL2 (ANSI X3H2), iar pentru SGBDOR exist
standardul SQL3;
- SGBDR apar ca produse software foarte mature, pe cnd SGBDOR sunt produse
software nc n formare/perfecionare;
- n ceea ce privete suportul pentru programare, n cazul limbajelor de programare
aparinnd SGBDOR apare posibilitatea reutilizrii codului, datorit proprietii de
motenire, ceea ce duce implicit la reducerea efortului de programare;

8.4. Compararea SGBDOO cu SGBDOR

Din compararea celor dou tipuri de sisteme de gestiune a bazelor de date pot fi
desprinse cteva concluzii, astfel [66]:
- SGBDOO i SGBDOR suport tipuri de date abstracte (n SQL3 tipuri definite de
utilizator), tipuri structurate, identificatori obiect, tipuri referin i motenirea;
- Ambele tipuri de SGBD au un limbaj de cereri pentru manipularea coleciilor de
date de tip SET, liste i ARRAY;
- SGBDOR suport o extensie a SQL, iar SGBDOO suport limbajele ODL i OQL;
- SGBDOR ncearc s adauge trsturi ale SGBDOO unui SGBDR, iar SGBDOO
la rndul lor au dezvoltat limbaje de cereri bazate pe limbajele de cereri
relaionale;
- Att SGBDOO ct i SGBDOR asigur sistemelor de gestiune a bazelor de date
funcionalitatea de control a concurenei de acces precum i de regsire a datelor;
- Diferena fundamental ntre SGBDOO i SGBDOR const n faptul c SGBDOO
ncearc s-i mbogeasc limbajele de programare pe cnd SGBDOR ncearc
s adauge tipuri mai bogate de date unui SGBD relaional;
- Facilitile de cereri ale OQL nu au suport eficient n majoritatea SGBDOO, n
timp ce facilitile de cereri sunt piesa central a SGBDOR.
- Un SGBDOR este indicat pentru aplicaii ce implic colecii mari de date, obiecte
ce pot avea structuri complexe/bogate i relativ mari;

Oracle-SGBD obiectual relaional
269

Capitolul 9
Oracle-SGBD obiectual-relaional

SGBD-ul Oracle este un SGBD obiectual-relaional ce implementeaz modelul
orientat obiect ca o extensie a modelului relaional. Se pot implementa conceptele de baz ale
modelului orientat obiect i anume:
- conceptul de clas de obiecte;
- conceptul de motenire simpl nu i multipl;
- toate tipurile de asocieri ntre clase;
- conceptul de agregare.

9.1. Tipuri de obiecte (Object types )

Tipul este identic cu o clas din Java sau C++ i reprezint un set de obiecte cu
structur (atribute) i comportament similar. Metodele (proceduri i funcii PL/SQL definite la
momentul definirii tipului) sunt opionale pentru un tip i definesc comportamentul obiectelor
de acest tip. Instana unui tip se numete obiect .
Pentru a crea un tip se utilizeaz comanda Create Type. Definirea unui tip nu aloc
spaiu de stocare pentru acest tip. De exemplu, se va crea tipul Persoana_t caracterizat prin
atributele CNP, nume, prenume i telefon i prin dou metode: funcia returneaza_cnp() i
procedura afiseaza_detalii. Se va utiliza instrumentul SQL Developer (figura 9.1, figura 9.2).
Un tip poate fi utilizat pentru a defini un atribut al unei tabele sau o variabil de acest
tip. De exemplu, tabela Curs are atributul profesor de tip persoana_t. In acest caz, obiectele
tipului persoana_t se numesc obiecte coloan :

create table curs
(curs_id varchar2(10), curs_denumire varchar2(20), profesor student.persoana_t)

Pentru a aduga un tuplu n tabela Curs se utilizeaz comanda:
insert into curs values
('BD', 'Baze de date', persoana_t(2610925400129, 'Muntean', 'Mihaela', '3440652'))

Metodele sunt funcii sau proceduri ce pot fi declarate la momentul definirii tipului
pentru a implementa comportamentul.

Capitolul 9
270

Fig. 9.1. Definirea tipului Persoana_t

Fig. 9.2. Metodele tipului Persoana_t

271
Metodele pot fi scrise n PL/SQL sau n orice limbaj de programare. Metodele scrise
n PL/SQL sau Java sunt stocate n baza de date, iar cele scrise n alte limbaje cum ar fi C sunt
stocate extern.
Metodele permit accesul la datele unui obiect. De exemplu, comanda SELECT poate
utiliza metoda returneaz_CNP() a tipului persoana_t pentru a afia CNP-ul profesorilor din
tabela Curs:

Select c.profesor.returneaza_CNP() from curs c

Metodele pot fi: membru, pentru comparare de obiecte (metode de mapare i de
ordonare), statice, constructor.
Metodele membru permit unei aplicaii s acceseze datele unui obiect. Se definete o
metod membru pentru fiecare operaie pe care dorim s-o executm pe obiectele tipului
respectiv. De exemplu metoda volum() calculeaz volumul unui obiect de tip cub_t (opereaz
pe atributul latura) i este o metod membru. Aceste metode au un parametru predefinit SELF
ce specific obiectul pentru care metoda este invocat. In urmtorul exemplu, se definete un
tip cub_t cu trei metode: o funcie suprafata(), o funcie volum() i o procedur afieaz.
Metodele sunt scrise n PL/SQL:

create type cub_t as object ( latura integer, member function suprafata return integer,
member function volum return integer, member procedure afiseaza (self in out nocopy cub_t))

Pentru fiecare metod se specific codul PL/SQL :

create type body cub_t as
member function volum return integer is
begin
return latura* latura * latura;
end;
member function suprafata return integer is
begin
return 6 * (latura * latura);
end;

Se utilizeaz pachetul dbms_output pentru a afia latura, volumul i suprafaa unui
obiect de tip cub_t:

member procedure afiseaza (self in out nocopy cub_t) is
begin
dbms_output.put_line('latura cubului este : ' || latura) ;
dbms_output.put_line('volumul cubului este : ' || volum) ;
dbms_output.put_line('suprafata cubului este : ' || suprafata) ;
end;
end;

Se creeaz o tabel cuburi n care se vor stoca obiecte de tip cub_t (de exemplu cubul
cu latura 10). Metoda volum() poate fi apelat ntr-o comanda SELECT (figura 9.3):

create table cuburi (id number, cub cub_t)
insert into cuburi values(1, cub_t(10))
Capitolul 9
272

Pentru tabela cuburi se specific alias-ul c. In apelul metodei se specific alias-ul
tabelei, denumirea coloanei care va stoca obiectele de tip cub_t i denumirea metodei:

select c.cub.volum() from cuburi c

Fig. 9.3. Apelul unei metode n comanda SELECT

Procedura afiseaza poate fi apelat ntr-un bloc PL/SQL (figura 9.4):

declare
-- se definete o variabil v care va stoca obiecte de tip cub_t
v cub_t;
begin
select c.cub into v from cuburi c where c.id=1;
-- denumirea metodei este precedat de denumirea variabilei
v.afiseaza;
end;

Metode pentru comparare de obiecte. Dou obiecte pot fi comparate dac sunt de
acelai tip. Metodele de mapare i cele de ordonare permit compararea a dou obiecte.
Metoda de mapare este o funcie membru fr parametri ce permite compararea
obiectelor unui anumit tip prin maparea lor la unul din tipurile de date: date, number, varchar2
i apoi ordonarea lor n funcie de poziia lor pe ax.

273

Fig. 9.4. Apelul unei metode ntr-un bloc PL/SQL

Urmtorul exemplu definete o metod de mapare aria() ce permite compararea
obiectelor de tip dreptunghi n funcie de aria lor :

Create type dreptunghi_t as object (lungime number, latime number,
map member function aria return number)

Create type body dreptunghi_t as
Map member function aria return number is
Begin
Return lungime*latime;
End;
End;

Metoda de ordonare permite compararea direct a obiectelor (specific dac obiectul
curent este mai mic, egal sau mai mare dect alt obiect cu care este comparat, pe baza unui
criteriu de comparare utilizat de metod). Este de fapt o funcie cu un parametru declarat
pentru un alt obiect de acelai tip cu obiectul curent i care returneaz un numr negativ, zero
sau un numr pozitiv. O metod de ordonare este mai puin eficient, deoarece ea poate
compara numai dou obiecte la un moment dat, spre deosebire de metoda de mapare care
poate compara mai multe obiecte la un moment dat.
Un tip are cel mult o metod de mapare sau o metod de ordonare. Intr-o ierarhie de
motenire numai supertipul poate avea o metod de ordonare. Dac supertipul are o metod de
mapare, orice subtip poate avea o metod de mapare care poate nlocui metoda de mapare a
supertipului.

Metode statice. O metod static nu are parametru SELF. Metodele statice pot fi
utilizate pentru a defini constructori.

Capitolul 9
274
Metode constructor. O metod constructor este o funcie ce returneaz o nou instan
a tipului i seteaz starea acestei instane. Fiecare tip are o metod constructor definit n mod
implicit de sistem. De exemplu, se consider tipul persoana_t (figura 9.1). Metoda
constructor a acestui tip are aceeai denumire cu tipul. Pentru a crea un obiect de tip
persoana_t se apeleaz aceast metod: persoana_t(2134913456411, Ionescu, Doina,
3440244). Obiectul creat va fi stocat n tabela de obiecte Persoane (figura 9.5 ).

Create table persoane of persoana_t
insert into persoane values (persoana_t (2110461123400, 'Ionescu', 'Doina', 3440244))

Fig. 9.5. Utilizarea metodei constructor

9. 2. Tabela de obiecte

Tabela de obiecte este un tip special de tabel n care fiecare tuplu reprezint un
obiect. De exemplu, tabela Persoane va stoca obiectele tipului Persoana_t. Aceast tabel se
poate vizualiza n dou moduri:
- ca o tabel cu mai multe atribute - atributele tipului Persoana_t. Pe aceast tabel se
pot executa operaii relaionale. De exemplu, se adaug un obiect de tip persoana_t n tabela
Persoane :

insert into persoane values ( persoana_t(1670603400129, 'Nicolae', 'Dan', '6485361') )

275
- ca o tabel cu un singur atribut. Fiecare tuplu al tabelei este un obiect de tip
Persoana_t. Pe aceast tabel se pot executa operaii orientate obiect. De exemplu, se execut
o cerere pe tabela Persoane utiliznd funcia VALUE() ce returneaz un obiect :

SELECT VALUE(p) FROM persoane p WHERE p.prenume = 'Dan'

Obiectele ce sunt stocate ca tupluri ntr-o tabel de obiecte se numesc obiecte-tuplu,
iar obiectele ce sunt stocate ca atribute ntr-o tabel sau sunt atribute ale altor obiecte se
numesc obiecte-coloan.
Se pot defini restricii pe atributele unui tip sau pe o tabel de obiecte. De exemplu, se
definete tipul locatie_t i tabela de obiecte locaie. Se definete o restricie de cheie primar
pe tabela locaie:

create type locatie_t as object(cod_cladire number, denumire varchar2(20) )
create table locatie of locatie_t (cod_cladire primary key )

In unele situaii se impune utilizarea alias-urilor pentru tabele. De exemplu, se
consider tabela de obiecte persoane i tabela Curs ce conine atributul profesor de tip
persoana_t:
create table curs
(curs_id varchar2(10), curs_denumire varchar2(20), profesor student.persoana_t)

Urmtorul exemplu utilizeaz un alias pentru tabel. Atributul CNP este un atribut a
unui obiect de tip persoana_t obiect stocat n coloana Profesor. Denumirea atributului
trebuie precedat de denumirea coloanei i de alias-ul tabelei (figura 9.6 ):

select c.profesor.cnp from curs c

Fig. 9.6. Utilizarea unui alias pentru tabel

Capitolul 9
276
n urmtorul exemplu nu se utilizeaz un alias pentru tabel, atributul CNP este un
atribut al tabelei persoane:

select cnp from persoane

9.3. Tehnica de referire a obiectelor

Tehnica de referire a obiectelor este similar cu restricia de cheie extern din modelul
relaional. REF este un pointer logic la un obiect-tuplu, construit din identificatorul (object
identifier-OID) obiectului referit i ofer un mecanism simplu pentru navigare ntre obiecte.
Se poate modifica o referire (se face referire la alt obiect al aceluiai tip) sau i se poate asocia
valoarea null. De exemplu, se creeaz tipul Angajat_t. Un obiect de acest tip se caracterizeaz
prin atributele nume i sef. Atributul Sef va stoca referiri ctre alte obiecte ale tipului
Angajat_t. Altfel spus un angajat are un nume (de exemplu Dumitru Ion) i un ef ierarhic
superior (de exemplu Ionescu Diana). eful este i el un angajat, deci un obiect de tip
Angajat_t:

create type angajat_t as object (nume varchar2(30), sef ref angajat_t )

Obiectele de tip angajat_t vor fi stocate n tabela Angajat_obj_tabela:

create table angajat_obj_tabela of angajat_t

Angajatul Ionescu Diana nu are ef sau altfel spus se specific valoare null pentru
obiectul referit:

insert into angajat_obj_tabela values ( angajat_t ('Ionescu Diana', null))

Atributul Sef al obiectului Dumitru Ion va stoca referirea ctre obiectul Ionescu Diana
(eful lui Dumitru Ion este Ionescu Diana) (figura 9.7):

insert into angajat_obj_tabela select angajat_t ('Dumitru Ion', REF(a)) from
angajat_obj_tabela a where a.nume = 'Ionescu Diana'

Operatorul REF se utilizeaz pentru a returna referirea unui obiect-tuplu. Este posibil
ca obiectul referit s nu mai fie valabil datorit tergerii lui sau anulrii drepturilor. O astfel de
referire se numete izolat (dangling). Se pot evita aceste situaii prin definirea de restricii de
integritate.
Pentru a afia numele efului unui angajat, se poate utiliza comanda (figura 9.8) :

Select a.nume, a.sef.nume from angajat_obj_tabela a where a.nume='Dumitru Ion'

n acest exemplu, a.sef.nume folosete referirea specificat atunci cnd s-a creat tabela
angajat_obj_tabel i returneaz numele efului. Este permis numai n SQL, nu i n PL/SQL.

277

Fig. 9.7. Utilizarea tehnicii de referire a obiectelor

Fig. 9.8. Afiarea obiectului referit

Capitolul 9
278
9.4. Motenirea

Conceptul de motenire este suportat de Oracle ncepnd cu versiunea 9i. Anterior
acestei versiuni, motenirea era implementat utiliznd asocieri cheie primar-cheie extern
(se simula asocierea ntre o superclas i subclasele ei). In figura 9.9 se prezint un exemplu
de motenire n care fiecare obiect al supertipului Pers_t aparine cel puin unui subtip. O
persoan poate fi angajat i student.

Fig. 9. 9. Un exemplu de motenire

9.4.1. Implementarea motenirii n Oracle anterior versiunii 9i

Se va crea o tabel pentru superclasa Pers_t i pentru fiecare din subclasele sale:
Student_t i Angaj_t. Pentru a simula motenirea, tabelele Studenti i Angajati vor moteni
cheia primar a tabelei Persoane. Cheile externe ale tabelelor Angajati i Studenti sunt i chei
primare. Se asigur astfel c fiecare student i fiecare angajat este de asemenea, o persoan.

Create table persoane (marca number(4) not null, nume varchar2(20),
data_nasterii date, Primary key(marca))

Create table studenti(marca number(4) not null, specializare varchar2(20),
an_studiu varchar2(4), Primary key(marca),
Foreign key(marca) references persoane on delete cascade)

Create table angajati(marca number(4) not null, salariu number,
functia varchar2(20), Primary key(marca),
Foreign key(marca) references persoane on delete cascade)

279
9.4.2. Implementarea motenirii utiliznd clauza under

ncepnd cu versiunea 9i, motenirea este implementat utiliznd clauza under
atunci cnd se creeaz subtipurile Student_t i Angaj_t. Pentru a implementa subtipuri, trebuie
s definim tipurile ca not final. n mod implicit tipul va fi tratat ca final i nici un subtip
nu poate fi derivat din acest tip. Pentru fiecare subtip se va crea o tabel de obiecte. De
asemenea, se va crea o tabel de obiecte pentru supertipul Pers_t pentru a stoca persoanele
care nu sunt nici studeni, nici angajai (de exemplu sunt colaboratori):

Create or replace type pers_t as object
(marca number(4), Nume varchar2(20), Data_nasterii date) not final

Create table persoana of pers_t(marca primary key)

Create or replace type student_t under pers_t
(specializare varchar2(20), an_studiu varchar2(4))

Create table student of student_t(marca primary key)

Create or replace type angaj_t under pers_t
(salariu number, functia varchar2(20))

Create table angajati of angaj_t(marca primary key)

9.4.3. Motenirea multipl

Oracle suport numai motenire simpl. Clauza under este utilizat numai pentru
motenire simpl. Totui conceptul de motenire multipl este adesea simulat utiliznd alte
tehnici existente. De exemplu, se poate utiliza clauza under pentru a implementa un printe
motenit i se utilizeaz un tip de asociere pentru a lega subclasa de cellalt printe. Problema
este c numai printele implementat utiliznd clauza under poate fi motenit i de aceea
trebuie s fim ateni care printe este motenit i care este asociat.

9. 5. Relaii de asociere

n Oracle exist dou moduri de implementare a asocierilor ntre clase:
- prin cheie primar i cheie extern. Stabilirea cheilor externe se bazeaz pe
cardinalitatea asocierii ntre entitile modelate (1:1, 1:m, m:m). Se va utiliza diagrama
de clase din figura 9.10.
Asocierea dintre clasele Student_t i Curs_t este de tip (m:m). La implementare, se va
crea o tabel intermediar Inscriere. Cheile primare ale celor dou tabele Student i Curs
migreaz n tabela intermediar Inscriere sub form de chei externe i mpreun formeaz
cheia primar a acestei tabele. Asocierea dintre clasele Profesor_t i Curs_t este de tip (1:m).
La implementare, cheia primar a tabelei Profesor devine cheie extern pentru tabela Curs.
Asocierea dintre clasele Profesor_t i Birou_t este de tip (1:1). La acest tip de asociere trebuie
s se stabileasc obligativitatea participrii la asociere a celor dou clase: obligatoriu/opional.
Capitolul 9
280
In exemplul dat, fiecare profesor trebuie s fie localizat ntr-un singur birou (deci obligatoriu).
Pe de alt parte, un birou poate fi liber (participarea clasei Birou n asociere este opional).
La implementare, cheia primar a tabelei Birou devine cheie extern a tabelei Profesor.

Fig. 9.10. Un exemplu de diagram de clase implementat n Oracle

Utilizarea restriciilor de integritate refereniale determin o validare automat n
tabela referit, nainte de a se executa operaia de manipulare n tabela care refer. Se pot
aduga politici de reacie (cascade, restrict i nullify) prin restriciile refereniale definite sau
prin triggeri:

Create table student
(nrmatricol number(4) not null, nume varchar2(20), Primary key(nrmatricol))

Create table Birou(cod varchar2(10) not null, den_cladire varchar2(20), Primary key(cod))

Create table profesor(marca number(4) not null, nume varchar2(30), cod varchar2(10),
Primary key(marca), Foreign key(cod) references birou (cod) on delete cascade)

Create table curs (cod_curs varchar2(10) not null, denumire varchar2(30), marca number(4),
Primary key(cod_curs), Foreign key(marca) references profesor (marca) on delete cascade)

Create table inscriere(cod_curs varchar2(10) not null, marca number(4) not null,
Primary key(cod_curs, nrmatricol),
Foreign key(cod_curs) references curs(cod_curs) on delete cascade,
Foreign key(nrmatricol) references student(nrmatricol) on delete cascade)

- prin tehnica de referire a obiectelor. n loc de a asocia dou tabele prin valorile cheii
primare i a cheii externe asociate, aceast tehnic permite legtura direct a dou tabele prin
atribute de referire.

Implementarea asocierii (m:m) dintre clasele Student i Curs, utiliznd atribute de
referire se realizeaz astfel (figura 9.11):

--se creeaz tipul student_t
Create or replace type student_t as object(nrmatricol number(4), Nume varchar2(20))
281
--se creeaz tipul curs_t
Create or replace type curs_t as object
(cod_curs varchar2(10), denumire varchar2(30))

--se creeaz tabela de obiecte student care va stoca obiecte de tip student_t
Create table student of student_t(nrmatricol Primary key)

-- se creeaz tabela de obiecte curs care va stoca obiecte de tip curs_t
Create table curs of curs_t(cod_curs Primary key)

--se creeaz tabela inscriere. Atributul student va stoca referiri la obiectele de tip student_t,
iar atributul curs va stoca referiri la obiectele de tip curs_t
Create table inscriere(student ref student_t, Curs ref curs_t)

Implementarea asocierii (1:m) dintre clasele Profesor_t i Curs_t utiliznd atribute de

--se creeaz tipul profesor_t
Create or replace type profesor_t as object(marca number(4),nume varchar2(30))

--se creeaz tipul curs_t. Atributul profesor va stoca referiri la obiectele de tip profesor_t
Create or replace type curs_t as object
(cod_curs varchar2(10), denumire varchar2(30), profesor ref profesor_t)

--se creeaz tabela de obiecte profesor
Create table profesor of profesor_t(marca Primary key)

--se creeaz tabela de obiecte curs
Create table curs of curs_t(cod_curs Primary key)

Implementarea asocierii (1:1) dintre clasele Birou_t i Profesor_t utiliznd atribute de

--se creeaz tipul birou_t
Create or replace type birou_t as object(cod varchar2(10), den_cladire varchar2(20))

--se creeaz tipul profesor_t. Atributul birou va stoca referiri la obiectele de tip birou_t
Create or replace type profesor_t as object
(marca number(4),nume varchar2(30), birou ref birou_t)

--se creeaz tabela de obiecte birou
Create table birou of birou_t(cod Primary key)

--se creeaz tabela de obiecte profesor
Create table profesor of profesor_t(marca Primary key)

Utilizarea tehnicii de referire a obiectelor nu implic nici o restricie de integritate
referenial. De asemenea, exist posibilitatea ca o referire s fie izolat dac obiectul
referit este ters. Pentru a evita aceast situaie se poate aduga o restricie referenial.

Capitolul 9
282

Fig. 9.11. Implementarea asocierii (m:m) utiliznd atribute de referire

Fig. 9.12. Implementarea asocierii (1:m) utiliznd atribute de referire

283

Fig. 9.13. Implementarea asocierii (1:1) utiliznd atribute de referire

9.6. Agregarea

Oracle ofer dou tehnici pentru implementarea agregrilor: tehnica cluster i tehnica
tabelelor imbricate.
9.6.1. Implementarea agregrii utiliznd tehnica cluster

Clusterul este un grup de dou sau mai multe tabele stocate fizic mpreun, deoarece
au atribute comune i sunt adesea folosite mpreun n jociuni. Deoarece tuplurile corelate
sunt stocate fizic mpreun, timpul de acces se mbuntete. Tehnica cluster se utilizeaz
pentru a implementa agregarea compus In figura 9.14, ntre clasa Facultate_t i clasa
Catedra_t exist o agregare compus (agregarea exclusiv n care existena obiectelor parte
depinde complet de obiectul ntreg).
Agregarea compus se implementeaz prin definirea unei chei primare compuse ce
include i cheia cluster, pentru tabela parte Catedra i utilizarea cheii cluster drept cheie
extern. Tuplurile tabelei Facultate i tuplurile tabelei Catedra sunt stocate fizic mpreun.
Indexul pentru cluster este creat n scopul de a mbunti performana stocrii clusterului:

--se creeaz cluster-ul Fac_cluster, iar atributul cod_fac este cheie cluster
Create cluster fac_cluster(cod_fac varchar2(5))

--se creeaz tabela Facultate corespunztoare clasei ntreg Facultate_t i este inclus n
cluster
Create table facultate
Capitolul 9
284
(cod_fac varchar2(5) not null, den_fac varchar2(50), decan varchar2(30),
Primary key(cod_fac)) Cluster fac_cluster(cod_fac)

--se creeaz tabela Catedra corespunztoare clasei parte Catedra_t i este inclus n cluster
Create table Catedra(cod_fac varchar2(5) not null, cod_cat varchar2(5) not null, den_cat
varchar2(50), Sef_catedra varchar2(30), Primary key(cod_fac, cod_cat),
Foreign key(cod_fac) references facultate(cod_fac)) Cluster fac_cluster(cod_fac)

--se creeaz indexul pentru cluster
Create index fac_cluster_index on cluster fac_cluster

9.6.2. Implementarea agregrii utiliznd tehnica tabelelor
imbricate

Aceast tehnic este utilizat numai pentru implementarea agregrii compuse. Dac
obiectul ntreg este ters, toate obiectele parte asociate vor fi terse. n tehnica tabelelor
imbricate se poate aduga o nou nregistrare parte n tabela imbricat, numai dac exist
nregistrarea ntreg corespunztoare. Se va utiliza exemplul din figura 9.14.

1

1..

Fig. 9.14. Agregare compus

--se creeaz tipul Catedra_t
Create or replace type catedra_t as object
(cod_cat varchar2(5), den_cat varchar2(50), sef_catedra varchar2(30))

--se creeaz tipul Catedra_tabela (tip colecie)
Create or replace type catedra_tabela as table of catedra_t

--se creeaz tipul Facultate_t. Pentru acest tip se definete i o metod i anume procedura
afiseaza_catedre care va fi apoi utilizat ntr-un bloc PL/SQL. Atributul catedra este de tip
colecie.
Create or replace type facultate_t as object(cod_fac varchar2(5),
den_fac varchar2(50), decan varchar2(30), catedra catedra_tabela,
member procedure afiseaza_catedre (self in out nocopy facultate_t))

Facultate_t
Cod_fac
Den_fac
Decan
Catedra_t
Cod_cat
Den_cat
Sef_catedra
285
--se creeaz tabela de obiecte Facultate_tabela n care se vor stoca obiecte de tip facultate_t.
Informaiile despre catedre sunt stocate n tabela imbricat catedra_tab
Create table facultate_tabela of facultate_t
(primary key(cod_fac) ) Nested table catedra store as catedra_tab

-- se definete corpul metodei afiseaza_catedre utiliznd limbajul PL/SQL. Procedura
afiseaza_catedre utilizeaz un cursor explicit c_catedra, precum i o structur repetitiv
pentru a selecta i afia informaii despre catedrele corespunztoare obiectului de tip
facultate_t specificat ca parametru :
create or replace type body facultate_t as
Member procedure afiseaza_catedre(self in out nocopy facultate_t ) is
Cursor c_catedra is select den_cat, sef_catedra
from the (select catedra from facultate_tabela where cod_fac=self.cod_fac);
Begin
dbms_output.put_line(cod_fac||' '||den_fac );
dbms_output.put_line('Decan: '||decan);

Dbms_output.put_line
('Catedra'||' '||'sef catedra');
Dbms_output.put_line('_______________________________');
For v_catedra in c_catedra loop
Dbms_output.put_line(v_catedra.den_cat||' '||v_catedra.sef_catedra);
End loop;
End;
end;

--un tuplu n tabela facultate_tabela se adaug astfel
INSERT INTO facultate_tabela VALUES
('CSIE','Cibernetica, Statistica, Informatica Ec', null,
catedra_tabela(catedra_t('IE', 'Informatica Ec', 'Bogdan Ghilic'),
catedra_t('CIB', 'Cibernetica Ec', NULL), catedra_t('STAT', 'Statistica Ec', null)))

Urmtorul bloc PL/SQL selecteaz facultatea CSIE i execut procedura
afiseaza_catedre a tipului facultate_t pentru a afia catedrele acelei faculti (figura 9.15).
Funcia VALUE() returneaz un obiect de tip Facultate_t:

declare
Facultate facultate_t;
begin
select value(f) into facultate from facultate_tabela f where f.cod_fac = 'CSIE';
facultate.afiseaza_catedre;
end;

Capitolul 9
286

Fig. 9.15. Exemplu de utilizare a unei metode ntr-un bloc PL/SQL

9.6.3. Implementarea agregrii simple

n figur 9.16 se prezint o agregare simpl ntre clasa ntreg Catalog_t i clasa
parte Adidas_t. Un obiect parte (de exemplu Adidas Racer, cod 3395081) se poate gsi
n cataloagele diferitelor magazine cu profil sportiv.
In tehnica tabelelor imbricate se poate aduga o nou nregistrare parte n tabela
imbricat, numai dac exist nregistrarea ntreg corespunztoare. Din acest motiv, pentru
acest tip de agregare se poate utiliza o combinaie ntre tehnica tabelelor imbricate i tehnica
de referire a obiectelor:

--se creeaz tipul adidas_t i tabela de obiecte Adidas_tabela n care se vor stoca obiecte de
tip adidas_t:
Create or replace type adidas_t as object
(cod number, denumire varchar2(30), culoare varchar2(30))
create table adidas_tabela of adidas_t(primary key(cod))

--se creeaz tipul Lista (tip colecie):
Create or replace type lista as table of ref adidas_t

--se creeaz tipul Catalog_t. Atributul adidas este de tip colecie:
Create or replace type catalog_t as object (cod number,
denumire varchar2(30), sezon varchar2(30), an varchar2(4), adidas lista)

--se creeaz tabela de obiecte Catalog_tabela. In tabela imbricat Adidas_tab se stocheaz
referirile la obiectele de tip adidas_t:
create table catalog_tabela of catalog_t (primary key(cod_cat))
Nested table adidas store as adidas_tab

287

Fig. 9.16. Agregare simpl

--se adaug urmtoarele tupluri n tabela adidas_tabela:
Insert into adidas_tabela values(adidas_t(3395081, 'Adidas Racer', 'alb'))
Insert into adidas_tabela values(adidas_t(3397016, 'Adidas Racer', 'negru alb'))

--se adaug un catalog n tabela Catalog_tabela:
insert into catalog_tabela values(1, 'OTTO', 'primavara', '2007', lista())

-- tabela imbricat specificat de funcia TABLE() va stoca referirile la produsele prezentate
n acest catalog:
insert into table(select c.adidas from catalog_tabela c where c.cod_cat=1)
select ref(a) from adidas_tabela a where a.cod=3395081
insert into table(select c.adidas from catalog_tabela c where c.cod_cat=1)
select ref(a) from adidas_tabela a where a.cod=3397016

9.6.4. Implementarea agregrii multi-nivel utiliznd tabele
imbricate

SGBD-ul Oracle permite tabele imbricate pe mai multe nivele care pot fi utilizate pentru a
implementa o ierarhie de agregare multi-nivel. De exemplu, ntre clasa Regiune_t, clasa
Judet_t i clasa Oras_t exist o ierarhie de agregare multi-nivel:

--se creeaz tipul Oras_t :
Create or replace type oras_t as object
(denumire_oras varchar2(30), populatie number)

--se creeaz tipul Oras_tabela (tip colecie):
Create or replace type oras_tabela as table of oras_t

--se creeaz tipul Judet_t. Atributul oras este de tip colecie:
Capitolul 9
288
Create or replace type judet_t as object
(judet_id varchar2(3), denumire_judet varchar2(30), oras oras_tabela)

--se creeaz tipul judet_tabela (tip colecie):
Create or replace type judet_tabela as table of judet_t

--se creeaz tabela Regiune_tabela. Atributul judet este de tip colecie. Tabela imbricat
judet_tab include o alt tabel imbricat oras_tab:
Create table regiune_tabela(Denumire_regiune varchar2(30) primary key,
Judet judet_tabela) Nested table judet store as judet_tab
(nested table oras store as oras_tab)

--un tuplu n tabela Regiune_tabel se poate aduga astfel:
insert into regiune_tabela values('Dobrogea',
judet_tabela(judet_t('CT', 'Constanta', oras_tabela
(oras_t('Cernavoda', 10000), oras_t('Mangalia', 10000)))))

--tuplul adugat anterior se poate afia (figura 9.17):
SELECT r.denumire_regiune, j.denumire_judet, o.denumire_oras FROM regiune_tabela r,
TABLE (r.judet) j, table(j.oras) o where r. Denumire_regiune='Dobrogea'

Fig. 9.17. Exemplu de interogare a tabelelor imbricate pe mai multe nivele

Baze de date distribuite
289

Capitolul 10
Baze de date distribuite (BDD)

10.1 Definiie i obiective

10.1.1 Definiie

Generalizarea utilizrii calculatoarelor n toate domeniile economico-sociale generat,
pe de o parte de acumulrile cantitative i, pe de alt parte, de explozia n dezvoltarea de noi
tipuri de sisteme de calcul accesibile la nivel individual (personal) determinat de producerea
unor microprocesoare din ce n ce mai performante, a dus implicit la posibilitatea emulrii
oricrui nivel de producere i utilizare a informaiilor prin reele de calculatoare (reele locale,
reele ale unor ramuri de activitate, reea naional, reele private virtuale pe Internet).
Acest lucru a fcut posibil i oportun utilizarea bazelor de date distribuite (BDD).
Bazele de date distribuite au rspuns unei necesiti pragmatice de gestiune a datelor: ele
rspund cererii ca arhitectura managementului datelor s se adapteze necesitilor de producere
i utilizare a datelor n ntreprinderi, care sunt n mod natural, structural distribuite.
Evoluia progresiv a unui sistem informatic n curs de exploatare cere din partea sa
suplee n ceea ce privete adugarea, suprimarea
sau modificarea dinamic a uneia din
componentele sale fr a perturba grav ansamblul
acestuia. Sistemele distribuite pot fi configurate
prin adugiri i modificri progresive ale
componentelor cu un nalt grad de flexibilitate i
modularitate (fa de sistemele bazate pe utilizarea
centralizat a resurselor mainframe care sunt
mult mai rigide).
Definiie: O Baz de date distribuit (BDD) este o
baz de date (BD), logic integrat, dar fizic
distribuit pe mai multe sisteme de calcul
distincte, interconectate ntre ele.
n cele ce urmeaz vom prezenta cele dou
concepte subliniate n definiie mpreun cu
noiunile/conceptele care concur la definirea lor.
Logic integrat. O baz de date distribuit este caracterizat prin prezena a cel puin dou
servere de baze de date care pot prelucra independent unul de cellalt tranzacii locale. Din
punctul de vedere al utilizatorului BDD reprezint o singur BD. Abstractiznd, o baz de date
distribuit, poate fi considerat o colecie unic de date iar serverele de baze de date garanteaz
programelor de aplicaie accesul la resursele de date oferind utilizatorului exact acelai tip de

Fig. 10.1 Interaciunea utilizator - BDD
Capitolul10
290
interaciune ca cea utilizat la sistemele centralizate. BDD are o singur schem conceptual
global iar utilizatorul interacioneaz cu BDD n aceeai manier n care interacioneaz cu o
BD centralizat/local i, n general, nu are informaii despre partiionarea, replicarea i
distribuirea datelor. Prelucrrile iniiate la un nod antreneaz n general prelucrarea informaiilor
aflate n alt nod (figura 10.1). n aceast figur este prezentat o baz de date distribuit format
din bazele de date locale (BDL) BDL
1
, BDL
2
, BDL
3
stocate n nodurile unei reele notate
(corespondent) N
1
, N
2
i respectiv N
3
. Aceste baze de date locale, definite prin tehnica
fragmentrii, se integreaz n baza de date distribuit prin intermediul unei scheme globale (SG)
la care va face referire orice utilizator global (UG). Fragmentarea datelor este o tehnic utilizat
pentru organizarea datelor n scopul asigurrii unei distribuii eficiente a datelor i prelucrrilor.
Aceast tehnic este aplicabil numai dac distribuirea datelor urmeaz o schem bine definit
care este utilizat pe ntreaga durat de proiectare a bazei de date distribuite.
Un utilizator local (UL) reprezint un utilizator dintre oricare din tipurile de utilizatori ai
bazelor de date care are acces i exploateaz o baz de date local. El cunoate i manipuleaz
numai schema acelei baze de date locale (sau o subschem a bazei de date locale). Manipularea
bazei de date locale include oricare din bazele de date locale din reea (chiar dac aceast
manipulare se efectueaz cu terminal virtual, de exemplu un utilizator din nodul N
1
exploateaz
baza de date aflat n N
3
, utiliznd numai facilitile puse la dispoziie de software-ul de reea).
Un utilizator global (UG) aparine oricrui tip din gama de utilizatori ai bazelor de date
cu singura diferen c el cunoate i are acces la schema (sau o subschem) bazei de date
globale. Utilizatorul global exploateaz schema global (sau subschema) conform autorizrilor
i drepturilor sale de acces de aceeai manier n care ar lucra cu o baza de date local (sau
centralizat).
Baza de date distribuit (o mulime de colecii de date i legturile dintre ele) este
fragmentat conform principiilor:
- plasarea datelor memorate n nodul de producere i utilizare a lor;
- minimizarea transportului de date prin reeaua de calculatoare.
Pentru a rspunde acestor principii fragmentarea se realizeaz la dou nivele:
- partiionarea mulimii (ansamblului) de colecii de date n submulimi
(subansambluri) de colecii de date;
- partiionarea unei colecii de date n fragmente.
n acest paragraf vom defini formal fragmentarea i tipurile de fragmentri. Fie o relaie
cu schema R. Fragmentarea lui R const n determinarea unui anumit numr de fragmente
(subscheme) R
i
obinute prin aplicarea unei relaii algebrice lui R (ca operaii pe relaii care
exprim proprieti logice ale datelor). n acest context fragmentarea coleciei de date se poate
realiza n dou moduri:
- orizontal - fragmentele rezultate R
i
au aceeai schem de structur ca i colecia R,
dar difer ntre ele prin datele pe care le conin (n mod normal sunt colecii
disjuncte) i sunt, n mod natural, rezultate ca urmare a aplicrii unei selecii pe R;
- vertical - fragmentele rezultate R
i
conin doar o parte, fiecare, din structura coleciei
R. Ele conin cheia primar a relaiei R pentru a asigura restaurabilitatea i sunt, n
mod natural, rezultate ca urmare a aplicrii unei proiecii pe R.
Este admis i combinarea celor dou moduri (fragmentare mixt).
Fragmentele rezultate constituie elementele de distribuire a datelor. Fragmentarea este
corect dac sunt valide urmtoarele proprieti:
- Completitudine (completeness) orice atribut din R trebuie s se regseasc cel
puin ntr-unul din fragmentele R
i
;
- Recompunere (restorability-restaurabilitate) coninutul lui R trebuie s poat fi
refcut (restaurat/restaurabil) din fragmentele sale.
291
Totalitatea fragmentelor unei baze de date distribuite, memorate pe un nod al reelei i
gestionate de acelai SGBD, formeaz o baz de date local.
Fiecare fragment Ri poate corespunde unui fiier fizic diferit i poate fi alocat pe un
server diferit.
Fizic distribuit pe mai multe faciliti de calcul distincte, aceasta nsemnnd c:
- baza de date este partiionat iar partiiile/fragmentele respective sunt stocate pe
calculatoare diferite (se admit copii ale fragmentelor memorate n noduri diferite).
- fiecare fragment este vzut, n nodul n care exist, ca o baz de date centralizat,
care poate fi exploatat i administrat local.
Sistemul trebuie s asigure transparena fragmentrii i a alocrii. Transparena
fragmentrii se refer la faptul c programatorul nu trebuie s se preocupe de faptul c baza de
date este distribuit i are relaii fragmentate. Cererea pe care o adreseaz el trebuie s fie
identic cu cea pe care ar adesa-o relaiei nefragmentate. Transparena alocrii se refer la faptul
c programatorul cunoate structura fragmentelor dar nu trebuie s indice alocarea lor (mai
mult, dac fragmentele sunt replicate nu trebuie s indice cu care copie se lucreaz). Pe de alt
parte, programatorul, trebuie s fie liber s poat indica o replic sau alta a unui fragment prin
desemnarea localizrii (acest lucru este asigurat prin transparena limbajului de interogare).
Sistemul trebuie s asigure i atomicitatea tranzaciei distribuite: utilizatorul trebuie s poat s
scrie tranzacii care acceseaz i actualizeaz date aflate n diferite situri n acelai mod n care
ar scrie tranzacii pentru o baz de date local.
Raiunea care a condus la apariia bazelor de date dsitribuite nu a fost reprezentat de
maximizarea interaciunii i transmisiei datelor n reele de calculatoare ci de a modela ct mai
bine datele companiilor i interdependenele dintre ele pentru a permite rularea a ct mai multor
aplicaii independente pe un singur server astfel nct s se reduc costurile mari necesitate de
aplicaiile distribuite.
BDD pot fi clasificate din diverse puncte de vedere. O prim clasificare pe care o vom
face aici ia n considerare tipul de SGBD i tipul de reea de calculatoare. Dac toate serverele
de baze de date utilizeaz acelai SGBD atunci este denumit omogen (altfel eterogen). Baza
de date distribuit poate utiliza o reea local de calculatoare (LAN Local Area Network) sau
o reea pe arie extins (WAN Wide Area Network). n tabelul 10.1 sunt prezentate exemple de
aplicaii tipice n cazul acestei clasificri.

Tabelul 10.1 Exemple de aplicaii tipice de BDD n funcie de tipul de SGBD utilizat i tipul de
reea
Tip SGBD Tip reea de calculatoare
LAN WAN
Omogen Gestiunea datelor i aplicaii
financiare
Management transport si aplicaii
financiare
Eterogen Sisteme informatice inter-
divizionale
Systeme bancare integrate i sisteme
inter-bancare
Sursa: Database Systems Concepts, Languages and Architectures , Atezeni, Ceri,
Paraboschi and Torlone, McGraw and Hill, 1999

n cazul n care avem SGBD-uri diferite care acccept numai dialectul lor SQL ne
vom confrunta cu o absen a transparenei iar programatorul va fi obligat s specifice n
cerere fragmentele i alocarea lor n sistem.
Capitolul10
292
10.1.2. Obiectivele sistemelor de baze de date distribuite

n concordan cu definiia dat n 10.1.1 sistemul de baze de date distribuite trebuie s
asigure urmtoarele obiective :
- transmiterea datelor la utilizatorii lor: indiferent care este nodul n care se afl un
utilizator i indiferent unde sunt stocate datele (localizate) acesta trebuie s-i poat
obine informaiile de care are nevoie (numai cu condiia s aib dreptul i
autoritatea de a le accesa);
- evitarea unei foarte nalte centralizri a resurselor (centralizare care cauzeaz
foarte mult eficienei i eficacitii sistemului): o rat nalt a centralizrii resurselor
poate provoca un cost ridicat de prelucrare i transmitere a datelor la utilizatori;
- s sporeasc durabilitatea sistemului: pot fi introduse n orice moment noi structuri
de baze de date (pot fi integrate baze de date noi) prin includerea schemei lor n
schema conceptual global fr a afecta aplicaiile existente;
- s fac mai uoare operaiile de meninere i restructurare a bazei de date cu
meninerea unei rate nalte a disponibilitii: deoarece ceea ce vede un utilizator
global reprezint o schem global, care are drept corespondent diverse scheme
locale, operaia de restructurare a unei scheme locale nu trebuie s afecteaz cu
nimic utilizatorul global;
- s permit proiectarea structurii organizatorice i funcionale a sistemului analizat:
prin faptul c, n general, bazele de date locale se afl n locurile n care se produc
informaiile pe care le conin o arhitectur distribuit permite o emulare mai
puternic, a sistemului informaional, conform structurii organizatorice i
funcionale;
- s mreasc gradul de utilizare al sistemului: prin emularea cadrului organizatoric
i funcional i prin disponibilitatea datelor se obine creterea numrului de
utilizatori ai sistemului.

Aceste obiective atrag dup sine rezolvarea unor probleme tehnice care se refer la:
- posibilitatea accesului la BDD privit ca sistem integrat: baza de date distribuit
trebuie s fie vazut de utilizator ca o baz de date centralizat;
- asigurarea transparenei alocrii fizice a datelor fa de utilizator: exceptnd
utilizatorul (utilizatorii) special(i), administratorul bazei de date (ABD) ceilali
utilizatori nu trebuie s cunoasc locul n care sunt alocate datele pentru a-i formula
ntrebrile adresate bazei de date;
- portabilitatea software-ului: deoarece o baz de date distribuit poate avea n
componen baze de date locale gestionate pe diverse platforme (eterogene) este
necesar asigurarea portabilitii software-ului de gestiune;
- asigurarea unui sistem eficient de catalogare/diseminare a programelor de
aplicaie: programele de aplicaie trebuie s fie disponibile n toate nodurile reelei
pentru a asigura o exploatare eficient a aplicaiilor globale. De asemena, este
posibil ca prin definirea unor subscheme globale, alocate diverselor grupuri de
utilizatori, s fie necesar construirea unor programe de asigurare a corespondenei
schemei locale cu subschema global, programe a cror prezen este obligatorie n
toate nodurile reelei.
- asigurarea independenei logice, fizice i distributive a datelor. Independena logic
i fizic trebuie asigurat similar ca la bazele de date centralizate. Independena
distributiv se refer la faptul c dac schimbm nodul n care este stocat o partiie
293
a bazei de date distribuite acest lucru nu trebuie s influeneze aplicaiile i schema
conceptual global.
Majoritatea acestor probleme ridicate de BDD au fost rezolvate foarte eficient n BD
centralizate. n BDD rezolvrile gsite nu au fost de la nceput pe deplin satisfctoare. De
exemplu, independena datelor trebuie asigurat nu numai la nivelul nodului local ci trebuie s
permit o posibil relocare a datelor n noduri.
n afara acestor probleme comune BDD i BD centralizate au aprut i altele noi ca:
- prevenirea creterii redundanei sau a inconsistenei datelor la dezvoltarea de noi
aplicaii;
- definirea de instruciuni pentru standarde de definire i utilizare a datelor;
- administrarea eficient a cererilor;
- utilizarea eficient a resurselor de telecomunicaie (reelei de calculatoare) etc.

10.1.3. Baze de date relaionale distribuite

O baz de date relaional distribuit (BDDR) const dintr-o colecie de relaii (tabele)
fiecare din ele putnd fi stocat ntr-un singur nod al reelei sau putnd fi rspndit ntr-o reea
de calculatoare numite n acest caz relaii distribuite.
Fiecare relaie distribuit poate fi fragmentat orizontal, vertical sau mixt n acord cu un
criteriu de distribuire.
O relaie este local dac este stocat n ntregime pe un singur nod i global dac
fragmentele sale sunt stocate n diverse noduri ale reelei de calculatoare.
Avantajul utilizrii bazelor de date distribuite este dat de faptul c sistemul de gestiune a
bazelor de date distribuite (SGBDD) funcioneaz ca un sistem centralizat n timp ce fizic se
adapteaz repartiiei componentelor unei ntreprinderi sau administrri.
n figura 10.2 este prezentat arhitectura unui sistem de gestiune a bazelor de date
distribuite (SGBDD).

Fig. 10.2 Arhitectura SGBDD
Capitolul10
294
10.1.4 Arhitectura sistemelor de baze de date distribuite

Arhitectura prezentat n figura 10.2 este propus de raportul ANSI/SPARC prin care
sistemul de gestiune a bazelor de date distribuite este subdivizat n niveluri de descompunere,
trecerea de la un nivel la altul efectundu-se prin procese de corespondene i transformare. n
aceast schem avem dou niveluri de organizare a datelor:
- nivelul global ca element ce permite integrarea bazelor de date locale ntr-o baz de date
global;
- nivelul local ca element care permite tratarea fiecrei baze de date locale, incluse n baza
de date distribuit, ca pe o baz de date centralizat.
Un utilizator global interacioneaz cu baza de date distribuit de aceeai manier cu
care ar interaciona cu o baz de date centralizat. El ii exprim cererile sale (de la
terminale/PC-uri cuplate on-line sau prin programe de aplicaie) sub form de tranzacii globale.
Aceste tranzacii globale sunt evaluate i descompuse prin intermediul informaiilor coninute n
dicionarul sistemului distribuit (DSD) i sunt transmise supervizorului execuiei distribuite.
Acesta are rolul de a transmite fiecare cerere nodului pe care se afl baza de date local pe care
trebuie s o interogheze i, pe de alt parte, de a primi rspunsurile de la diverse baze de date
interogate i a forma rspunsul pentru tranzacia global.
Deoarece diversele baze de date locale pot avea sisteme de gestiune diferite i mai mult
calculatoarele din reea pot fi neomogene este necesar realizarea unei adaptri, a fiecrui
fragment al cererii globale, conforme cu protocolul fiecrui sistem de operare i fiecrui SGBD
specific din fiecare nod. Dup adaptarea cererii la standardele cerute de SGBD-ul nodului local
acesta va trata cererea ca pe orice cerere local.
Tranzaciile pot fi clasificate n diverse categorii n funcie de criteriile de clasificare
considerate. De exemplu, dac se are n vedere numai fragmentarea datelor, toate cererile
adresate sistemului distribuit sunt cereri distribuite.
Considernd tipurile instruciunilor SQL din care sunt construite (conform clasificrii
sugerate de IBM i adoptate i de ali realizatori de SGBD) i localizrile datelor cererile pot fi
clasificate astfel:
- cereri la distan (remote requests) sunt tranzacii numai n citire (read only)
construite dintr-un numr arbitrar de comenzi de selecie (select) adresate unui
singur SGBD la distan;
- tranzacii la distan (remote tranzactions) sunt tranzacii formate din orice tipuri
de comenzi SQL (select, insert, delete, update) i adresate unui singur SGBD la
distan;
- tranzacii distribuite (distributed transactions) sunt tranzacii formate din oricte i
orice tipuri de comenzi SQL (select, insert, delete, update) adresate unui numr
oarecare de SGBD la distan cu fiecare comand adresndu-se datelor stococate
de un singur SGBD;
- cereri distribuite (distributed requests) sunt tranzacii arbitrare formate dintr-un
numr arbitar de comenzi SQL de tipuri diferite care se refer la date stocate de
diverse SGBD-uri.
nainte de execuie, pentru cererile distribuite, se aplic de ctre majoritatea SGBDD
comerciale o optimizare a execuiei cererii. Metoda larg aplicat este reprezentat de
optimizarea bazat pe cost care presupune urmtoarele:
- selectarea tipului de acces la date (secvenial sau direct prin intermediul indecilor);
- selectarea ordinei n care vor fi executate operaiile (de exemplu, ordinea n care vor
fi efectuate jonciunile);
295
- alegerea unei opiuni de execuie atunci cnd sunt oferite mai multe astfel de opiuni
(de exemplu, alegerea metodei de jonciune);
- definirea locului din fluxul de prelucrare a execuiei ordonrii datelor atunci cnd
cererea sau metoda de execuie necesit ordonarea datelor.
Majoritatea alegerilor i optimizrilor cererilor distribuite sunt efectuate pe baza
comensurrii costului total al execuiei cu formula:

tr tr CPU CPU O I O I total
n C n C n C C + + + + + =
/ /

unde:
C
I/O
costul unei operaii de I/O;
n
I/O
numrul de operaii de I/O;
C
CPU
costul unei operaii CPU (unitate central);
n
CPU
numrul de operaii CPU;
C
tr
cantitatea de date transmis n reea;
n
tr
costul unitar de transmisie.

10.1.5. Controlul concurenei

ntr-un sistem distribuit o tranzacie global este descompus n general n subtranzacii
adresate diverselor noduri. Considernd nivelul global sau cel local supervizorul execuiei
nivelului trebuie s serializeze i s planifice execuia acestor tranzacii. Pentru a elimina
inconvenientele generate de concurena care pot apare la execuia tranzaciilor att tranzaciile
adresate bazei de date globale i ct i subtranzaciile pe care le genereaz trebuie s fie global
serializabile. Serializabilitatea global a tranzaciilor distribuite peste nodurile unei baze de date
distribuite cere existena unui planificator serial unic echivalent cu toate planificatoarele locale
produse la fiecare nod.
Pentru rezolvarea conflictelor generate de concuren exist diverse mecanisme i
protocoale de asigurare a accesului concurent dintre care cele mai utilizate sunt metoda de
blocare n dou faze (two-phase locking) i mecanismul de utilizare a mrcilor de timp
(timestamping).
Metoda de blocare n dou faze are la baz urmtoarele principii :
- nici-o cerere nu are acces la date dac acestea nu au fost blocate n prealabil (blocate
n citire sau actualizare);
- dup ce a blocat un element de date, acea cerere nu mai poate bloca nici-un alt
element de date pn nu deblocheaz elementul de date pe care la blocat.

Gestiunea blocrii/deblocrii (lock/unlock) nregistrrilor (obiectelor) poate fi realizat
n unul din modurile:
- Centralizat: un singur nod are sarcina de a manipula cererile de blocare i deblocare
pentru toate obiectele;
- Copie Primar: pentru fiecare obiect una din copii (replici) este desemnat drept copie
primar iar toate cererile de blocare/deblocare ale acestui obiect sunt tratate de
gestionarul blocrilor localizat n situl n care este memorat copia primar;
Fiecare dintre aceste dou moduri are dezavantaje cum ar fi, de exemplu,
vulnerabilitate la cdere n cazul gestiunii centralizate, sau dependen de copia primar care
la orice citire necesit comunicarea a dou situri (copia primar i situl implicat).
- Total Distribuit: cererea de blocare/deblocare a copiei unui obiect memorat n situ
Capitolul10
296
este manipulat de gestionarul blocrilor/deblocrilor din situl n care este stocat
replica (copia).

Fiecare baz de date local (BDL
x
) poate fi exploatat local, de ctre utilizatorii locali
(UL
x
), prin intermediul sistemului de gestiune al bazei de date locale.
Cererile de acces pot solicita date situate pe noduri diferite ale reelei de calculatoare.
Pentru a superviza execuia unor astfel de cereri un nod trebuie s-i asume rolul de
coordonator. Celelalte noduri, care concur la realizarea cererii, se numesc noduri cooperante.
Un nod poate fi n acelai timp i coordonator (pentru cererile lansate din acel nod) i
cooperant (pentru cererile, lansate din celelalte noduri, care solicit acces la acest nod).
Controlul execuiei cererii la distan se realizeaz prin schimb de mesaje (conform unui anumit
protocol) ntre coordonatorul cererii i cooperanii acelei cereri.
Pentru asigurarea coerenei, n caz de incident hardware sau software, se utilizeaz
protocolul de "realizare n dou faze" prin care execuia fiecrei cereri de actualizare este
realizat n dou faze:
- pregtirea execuiei n aceast faz are loc citirea datelor, scrierea n jurnalele
locale a "imaginilor nainte" (date neactualizate) i a "imaginilor dup" (date
actualizate);
- realizarea sau nerealizarea cererii n acest faz are loc introducerea actualizrilor
n baza de date distribuit atunci cnd sistemul funcioneaz corect, sau nlturarea
efectelor acestei cereri de actualizare la apariia oricrui incident pe parcursul
tentativei de realizare a ei.
Cooperarea ntre noduri la realizarea cererii se efectueaz conform urmtorului protocol:
- nodul coordonator trimite mesajul 'PREGTETE' (prepare) tuturor nodurilor
cooperante;
- fiecare nod cooperant realizeaz faza I-a (la primirea mesajului) i returneaz
nodului coordonator mesajul 'PREGTIT' (yes);
- la primirea acestui mesaj, de la toate nodurile cooperante, nodul coordonator
transmite mesajul 'REALIZEAZ'
(commit);
- la primirea acestui mesaj nodurile
cooperante realizeaz faza a II-a. La
ncheierea cu succes a fazei a II-a fiecare
nod cooperant transmite mesajul
'REALIZAT' (ack).
Insuccesul realizrii este anunat prin mesajul
'ABORT' lucru care duce la emiterea, de ctre nodul
cooperant a mesajului 'REVENIRE' care declaneaz
procesul de refacere a bazelor de date la starea n care
se aflau naintea lansrii cererii.
Acest mecanism garanteaz faptul c cererea
se execut corect peste tot sau nu se execut de loc.
Execuia cererilor, n ordinea emiterii lor
(serial), la toate nodurile cooperante este asigurat
prin utilizarea unor mecanisme dintre care cele mai cunoscute sunt:
- mrcile de timp;
- inelul virtual.

Mrcile de timp (figura 10.3). La emiterea ei, fiecare cerere, primete n mod automat o
marc de timp (identificatorul nodului plus timpul ceasului local). Fiecare articol din baza de

Fig. 10.3 Utilizarea mrcilor de timp
297
date distribuit are o marc de timp care este
modificat la fiecare actualizare cu marca de
timp a cererii care a actualizat-o. Sistemul de
gestiune asigur execuia cererilor n ordinea
cresctoare a mrcilor de timp; o cerere este
executat dac marca sa de timp este mai mare
dect marca de timp a articolelor de date la care
solicit accesul. Pentru a se asigura un ceas unic
pentru recepionarea unei cereri nodul respectiv
verific ora local cu ora din marca de timp a
cererii primite. Dac ora local este mai mic
atunci se actualizeaz aceast or mecanism prin
care se ajunge practic, n scurt timp, la o or
unic n reea;

Inelul virtual (figura 10.4). Nodurile
reelei sunt nlnuite logic, formnd un inel
virtual, n care fiecare nod are un predecesor i succesor bine stabilit. Pe acest inel circul
continuu un tichet. Inelul poate fi vzut ca o reea circular de cale ferat pe care circul
"vagoane". Un vagon poate fi ocupat, dac este liber, cu ajutorul rezervrii sale prin
completarea "tichetului"(biletului) de nchiriere. Acest vagon are, deci un furnizor care l
angajeaz i ncarc i un destinatar, care n mod normal il descarc. Este posibil ca destinatarul
s lipseasc, de aceea, eliberarea efectiv se va efectua n momentul n care vagonul reapare la
furnizorul care la ncrcat.
Nodul la care se afla tichetul, dac acesta este liber, poate s emit un mesaj. Tichetul
trece apoi pe la toate nodurile iar mesajul este preluat de nodul cruia i este adresat (nodurile
cooperante). Cnd tichetul ajunge din nou la nodul care a emis mesajul acesta devine liber i
pleac la nodul urmtor.

10.1.6. Dicionarul (catalogul) Sistemului Distribuit

Utilizatorii dicionarului sistemului distribuit (DSD), ca element de baz al arhitecturii
SGBDD, sunt:
- proiectanii sistemului informatic;
- administratorii sistemului;
- utilizatorii BDD (orice cerere de acces).
n schema din fig. 10.5 sunt evideniate funciunile specifice ale DSD pentru fiecare
gam de utilizatori.
Pentru utilizatorii BDD orice cerere de acces la baza de date distribuit (exprimat n
limbaj conversaional de la terminale "on-line", staii de lucru sau prin programe de aplicaie
scrise n limbaj de nivel nalt) parcurge urmtorii pai:
- analiza tranzaciei prin:
- control sintactic efectuat la cel mai nalt nivel al LMD;
- descompunerea tranzaciilor complexe n tranzacii simple;
- translatarea cererilor:
- precompilarea (pentru cereri exprimate cu ajutorul limbajelor de nivel nalt) sau
interpretarea n scopul obinerii unui set de instruciuni exprimat n limbajul
intern al SGBDD;

Fig. 10.4 Utilizarea mecanismului de
"inel virtual"
Capitolul10
298
- utilizarea dicionarelor de coresponden pentru a transforma cererile complexe
n cereri simple (structuri de fiiere, mod de realizare a distribuirii fizice etc);
- includerea apelurilor la metodele de acces disponibile, n cererea tradus;
funcia de translatare are rolul de a identifica limbajul int (limbajul utilizat de
ctre SGBD-ul local creia i este destinat fiecare parte a cererii).

- controlul accesului:
- asigurarea consistenei bazei de date (verificarea corectitudinii datelor,
verificarea accesului concurent, verificarea drepturilor de acces, protecia bazei
de date n cazul funcionrii defectuoase);
- distribuire:
- optimizarea distribuiei cererilor conform unor criterii predefinite (adic s
separe "local" cererile pentru a primi datele de la distan, s gseasc ordinea de

Figura 10.5 Funciunile oferite de DSD

Fig. 10.6. DSD - interfa a reelei
299
execuie a cererilor elementare, s aleag ruta optim n scopul optimizrii
anumitor factori ca timp de acces,
timp de prelucrare, trafic n reea
etc).
Descompunerea tranzaciilor solicit ca DSD
s conin informaii despre date (de exemplu, cum
ar fi localizare, accesibilitate, disponibilitate,
proprieti statistice etc).
Proiectanii de sistem informatic utilizeaz
DSD pentru a afla informaii despre:
- evaluarea performanelor (conform
componentelor software / hardware,
diferitelor arhitecturi etc);
- simularea unor metode de acces pentru
selectarea celor cu performane ridicate;
- modul de efectuare a conversiilor de
fiiere;
- alocarea fiierelor destinate stocrii
fragmentelor bazei de date globale.
Administratorii de sistem pot obine informaii despre:
- schema conceptual a reelei de calculatoare (administrare reea);
- schema extern global pentru toate aplicaiile care utilizeaz BDD (administrare
aplicaie global);
- administrare local BD similar modului de efectuare a administrrii bazelor de date
centralizate.
Funciile de interfa ale DSD cu reeaua (figura 10.6), utilizatorii i programatorii sunt:
- generarea automat a macroinstruciunilor de interfa cu diversele SO (sisteme de
operare) gazd;
- apelul automat al compilatoarelor limbajului de manipulare a datelor (LMD);
- generarea automat a macroinstruciunilor, pentru diversele metode de acces, cu
ajutorul unui catalog al nodurilor, numelor i metodelor de acces la datele locale;
- interfee, prin mijlocirea "maprilor de coresponden" (dicionare) ntre diversele
protocoale de transmisie.
Cererile utilizatorilor sunt descompuse n cereri simple cu ajutorul DSD n conexiune cu
SGBDD iar DSD coordoneaz distribuia i execuia, cererilor n reea, n conexiune cu NOS
(sistemul de operare al reelei).
Pentru realizarea acestor funcii DSD trebuie s ofere informaii despre:
- localizarea datelor (nume fiiere, nodul de stocare, criteriul de fragmentare, copii,
etc);
- structura datelor (numele i formatul atributelor, date statistice, cardinalitatea
fiierelor, etc);
- disponibilitatea datelor;
- utilizarea datelor.
n arhitectura logic prezentat n figura 10.7, sunt evideniate dicionarele logice pe
care le poate conine DSD. n aceast schema dicionarele logice globale evideniate pot face,
ele nsi, obiectul distribuiei (pot fi distribuite).
n general acest DSD se prezint, practic, ca o baz de date relaional n care tabelele
componente reprezint unul din tipurile de dicionare logice evideniate.

Fig. 10.7. Arhitectura logic a DSD
Capitolul10
300
10.2. Niveluri de organizare

Nivelurile de organizare a datelor sunt determinate de modul de structurare a SGBDD
conform nodului ilustrat n figura 10.8.
- Nivel extern reprezint totul sau o parte a BDD aa cum este vzut de un utilizator
particular sau de ctre un ansamblu de programe de prelucrare.
- Nivel conceptual global descrie ansamblul informaiilor care constituie BD fr s
se in cont de aplicaii i de reprezentarea fizic a datelor.
- Nivel local reprezint o viziune omogen asupra bazelor de date locale.

10.3. Interaciunea utilizatorilor cu baze de date
distribuite

10.3.1. Baze de Date Locale - Viziuni locale

Viziunile (vederile) locale apar datorit necesitii stabilirii legturilor ntre baze de date
independente (modul de realizare a cooperrii bazelor locale) care sunt integrate n baza de date
distribuit. ntr-o abordare distribuit dorina descompunerii poate duce la cutarea sistemului
de gestiune cel mai potrivit pentru a obine optimizarea. n acest caz se obine eterogenitatea
sistemelor de gestiune utilizate pentru a gestiona bazele de date locale integrate ntr-o
arhitectur distribuit.
Modelul definit pentru descrierea viziunilor locale trebuie s permit satisfacerea
restriciilor legate de descrierea bazelor de date locale ct i de utilizarea acestor descrieri n
vederea unor cooperri exprimate n descrierea viziunii globale (de exemplu, ncorporarea
restriciilor de integritate generate de viziunea global).
Descrierea viziunii locale comport dou pri :

Fig. 10.8. Structura unui SGBDD
301
- descrierea relaiilor care caracterizeaz obiectele bazei de date locale. Aceast
descriere ridic problema controlului/meninerii coerenei BDL "clasice" (exprimat,
n modelul relaional, prin restricii de integritate a datelor enunate sub form de
predicate).
- descrierea operaiilor de manipulare disponibile pe aceste relaii. Acestea se vor
exprima sub form de programe locale direct interpretabile de SGBD-ul local
realiznd cooperarea ntre viziunea local i BD local.
Determinarea programelor locale i a coninutului lor poate fi efectuat:
- prin decizia administratului BD globale sau administratorului BD locale;
- prin construcia lor mai mult sau mai puin automat plecnd de la caracteristicile
entitilor (relaiilor) i schemele bazelor de date locale.

10.3.2. Baza de date global - Viziuni globale

Scopul unui SGBDD este acela de a pune la dispoziia utilizatorilor datele (sub forma de
baze de date locale) aflate sub controlul mai multor SGBD-uri (eventual de diverse tipuri).
Scopul viziuni globale este acela de a asigura transparen acestei repartiii. Viziunile globale
descriu legturile dintre bazele de date locale n funcie de obiectele acestor viziuni locale.
Proiectantul unei baze de date distribuite trebuie s :
- aleag un model de descriere a viziunii globale;
- aleag un model de exprimare a corespondenelor ntre obiectele viziunii globale i
obiectele viziunii locale;
- ofere o soluie prin care repartiia i cooperarea nu sunt definitive.
Proiectarea BDD este un proces complex. Stadiile care trebuiesc parcurse ar fi:
- proiectarea schemei globale similar ca la o BD centralizat;
- proiectarea schemei unei BDL;
- proiectare schemei de alocare (localizare);
- proiectarea schemei de replicare.
Atunci cnd se ajunge la stadiul de proiectare a schemei de replicare proiectantul are
deja un sistem care poate lucra fr replicare. Se pune ntrebarea atunci, de ce replicare? Exist
trei motive speciale:
- capacitatea mai mare a sistemului (disponibilitatea) vis-a-vis de cderi ceea ce
implic o funcionalitate sporit, mbuntind performana cererilor care solicit
suport mai mare de salvare a informaiilor;
- pentru a mri disponibilitatea datelor i performanele BDD se accept n anumite
cazuri replicarea datelor;
- memorarea de copii multiple ale acelorai date pe mai multe calculatoare (n
general, se justific existena unei copii numai dac costul meninerii ei - memorare
+ actualizare + acces - este mai mic dect costul acceselor la distan pentru a
obine acele date).
Modelul de descriere a viziuni globale ales trebuie s permit considerarea acestei
viziuni globale ca o viziune local pentru o noua descriere.
Descrierea unei viziuni globale se compune din elementele:
- Descrierea structurii datelor globale: descrierea relaiilor globale i a restriciilor de
integritate globale conform viziunii ansamblului aplicaiilor. Cu aceste obiecte se
vor exprima cererile utilizatorilor globali. Modelul de descriere al viziunii globale
trebuite s satisfac urmtoarele exigene :
Capitolul10
302
- s permit descrierea relaiilor globale i a cererilor utilizatorilor care solicit
aceste relaii;
- s permit exprimarea corespondenei global-local tiind c viziunile sunt
exprimate sub form de relaii i programe locale;
- s permit s se construiasc scheme externe adaptate unor clase de aplicaii
diferite.
- Modelul de cooperare sau coresponden global-local: n fapt acesta ncorporeaz
legturile dintre schemele implicate i datele de localizare. De asemenea trebuie s
permit cunoaterea numelui relaiilor locale i a operaiilor disponibile pe acestea
pentru a permite descompunerea i apoi optimizarea cererilor globale.

10.4. Criterii de Distribuire a Datelor

Fie B o baz de date distribuit i P
1
, P
2
, ..., P
j
prile care o compun. Modul n care
informaiile sunt distribuite pe diferite baze se bazeaz pe urmtoarele dou noiuni :
- Partiionarea (sau decuparea n ansambluri disjuncte):
Dac o Baz de Date Distribuit (BDD ) B este partiionat, aceasta nseamn c
prile P1, P2, ...., Pj care o compun formeaz subansambluri disjuncte:
B= {P
1
UP
2
U...UP
j
} cu { P
1
P
2
,,, P
j
}=
- Replicarea (Duplicarea) sau crearea a mai multor copii ale aceleiai informaii. Are
ca scop mrirea disponibilitii datelor (dac un fragment cadereplica sa i poate
lua locul) i mrirea vitezei de evaluare a cererii (cererile pot fi executate mai rapid
prin acces la copii locale i nu n nodurile aflate la distan).
Duplicarea/replicarea (meninerea unei copii de fragment) se justific (din punct de
vedere economic) numai dac se menine inecuaia:

= =
< + +
u
i
u
i
i i
Cad Ca Cal Cmc
1 1

unde:
u numrul de utilizatori ai copiei;
Cmc costul de memorare (stocare) a copiei;
Cal
i
costul accesului local pentru utilizatorul i;
Ca costul de actualizare a copiei;
Cad
i
costul accesului la distan (la copia primar) pentru utilizatorul i.
Gestiunea copiilor multiple este n sarcina SGBDD iar actualizarea acestora se poate
realiza n dou moduri :
- simultan cu actualizarea bazei de originale (replicare sincron);
- actualizarea copiei primare i aducerea la zi a copiilor secundare cu o anumit
ntrziere (replicare asincron).
O baz de date distribuit B replicat poate fi:
- total replicat, aceasta nseamn c diversele baze de date locale sunt copii ale
aceleai baze, adic: B= P
1
=P
2
=....= P
j
;
- parial replicat, aceasta nseamn c aceeai informaie se poate regsi n mai mult
de o baz de date local : - i, j astfel nct Pi Pj =
Pentru exemplificarea acestei noiuni vom considera o baz de date B a crei schem
relaional global R este urmtoarea: R< NF,NP,LOC,PRET,CANT> reprezentat pe tupluri
(n extensie) n figura 10.9. Un tuplu <f
i
,p
i
,o
i
,l
i
,q
i
> eR dac i numai, dac: "fabrica numrul f
i

303
(f
i
eNF) localizat n localitatea o
i
(o
i
eLOC) produce produsul p
i
(p
i
eNP) la preul l
i
(l
i
ePRET) n cantitatea q
i
(q
i
eCANT)".

tuplu NF NP LOC PRET CANT
1 11 100 Bucureti 1500 25.00
2 11 111 Bucureti 170 35.00
3 11 113 Bucureti 120 100.00
4 99 113 Constana 110 150.00
5 99 114 Constana 250 200.00
6 22 111 Braov 170 900.00

Fig. 10.9. O realizare a lui R avnd 6 tupluri

Presupunnd c baza de date B este distribuit pe trei noduri N1, N2 i N3 (cu
poriunile/fragmentele F
1
, F
2
respectiv F
3
) vom examina diversele cazuri de distribuire a
schemei globale:
- schema nepartiionat: aceasta nseamn c poriunile F
1
, F
2
, F
3
au aceeai
structur/schem, astfel: R<NF,NP,LOC,PRET,CANT>. n acest caz se poate spune
c schema este replicat i putem avea urmtoarele cazuri de distribuire a extensiei
sale (obiectelor):
- partiionarea obiectelor: (decupaj orizontal) n acest caz este vorba de o
decupare orizontal a tabelei R, de exemplu:
N1 cu tuplurile 1,2,3
N2 cu tuplurile 4, 5
N3 cu tuplul 6
- replicarea obiectelor:
o replicare total: extensia tabelei R se regsete pe toate nodurile N1,
N2, N3;
o replicare parial, de exemplu :
N1 cu tuplurile 1,2,3,6
- schema partiionat (decupaj vertical):

Vom considera decuparea relaiei R n trei sub-relaii R
1
, R
2
, R
3
astfel nct R =
(R
1
xR
2
xR
3
).
Deci R este compunerea relaiilor care pot avea urmtoarele scheme de structura:
R
1
(NF, LOC) R
2
(NP,PRET) R
3
(NF,NP,CANT)
n aceste condiii putem opta pentru urmtoarele cazuri de realizare a partiionrii:
- partiionarea fr replicare a crei modalitate de producere poate fi exemplificat
prin considerarea repartiiei:
N1 R
1
N2 R
2
N3 R
3

ntre N1 i N2 este o partiionare a schemei dar n acelai timp lipsete legtura logic
i/sau fizic ntre informaiile descrise n timp ce ntre N1 i N3 sau ntre N2 i N3
exist o legtur prin faptul c atributul NF se gsete n N1 i N3 (NP n N2 i N3).
- partiionare cu replicare pentru care vom considera repartiia urmtoare :
N1 R
1
Capitolul10
304
N2 R
2
N3 R
1
,R
2
,R
3

Cel mai bun exemplu de replicare este reprezentat de sistemele suport pentru decizie
care trebuie s colecteze date aflate n diverse noduri pentru a determina diverii indicatori
necesari analizei. Pentru a mri eficiena acestor tipuri de prelucrri de regul se realizeaz o
copie local a datelor necesare (o replic) n colecii denumite data warehousing (depozit de
date). Diferena reprezentat de depozitul de date fa de baze de date distribuite este dat de
faptul c datele nu trebuie s fie neaprat baze de date. Ele pot fi reprezentate i de diverse
tipuri de fiiere disponibile via sisteme de operare, a cror replic este inclus.

10.4.1. Criterii de alegere a distribuiei

Ca i la baze de date clasice exist dou moduri distincte de abordare a concepiei BDD:
- descendent, care corespunde celei mai bune distribuiri (figura 10.10.);
- ascendent, care corespunde celei mai bune cooperri (figura 10.11.).
Aceste moduri independente nu exclud abordarea mixt.
Abordarea descendent. Dac presupunem c BDD este creat cu toate piesele sale
componente atunci activitile de concepie i punere a sa n lucru sunt similare celor de BD
centralizate, exceptnd problemele legate de distribuirea datelor n noduri. La acest mod de
abordare poate fi controlat nivelul redundaei pe care dorim s o introducem lund decizia
asupra datelor care vor fi duplicate. Pentru efectuarea duplicarii i decuprii (fragmentrii)
trebuie s inem cont de natura prelucrrilor i volumul informaiilor manipulate pe fiecare
prelucrare i de asemenea de gradul de fiabilitate pe care dorim s-l obinem.
Abordare ascendent. Aceast abordare presupune existena mai multor baze de date
locale (BDL) implementate i exploatate sub SGBD. Reutilizarea acestor baze de date poate fi
efectuat prin :
- integrarea bazelor de date dup modificri: n aceast ipostaz se restructureaz
BDL pentru a se adapta noilor aplicaii.
- integrare BDL fr modificri: n aceast ipotez se vor utiliza BDL fr a le
modifica structura. Cea mai dificil problem este cea legat de integrarea bazelor
de date eterogene.
10.4.2. Construirea bazei de date distribuite

Modul de construire a unei baze de date distribuite este dependent de tipul abordrii.
Abordarea descendent. Considerm relaia global : SALARIAT(MARCA, NUME,
VIRSTA, SALARIU, LM, SEF) care descrie pentru fiecare SALARIAT identificat prin marca
(MARCA), numele (NUME), vrst (VIRSTA), salariul obinut (SALARIU), locul de munca
(LM) i seful ierarhic (SEF construit pe acelai domeniu cu MARCA).
O posibilitate de distribuire o constituie decuparea ei n trei fragmente F1, F2, F3 (figura
10.10.). Aceast descompunere este de fapt o partiionare fr duplicare care permite un control
total al repartiiei n msura n care fiecare dintre fragmente este stocat ntr-o baz de date
local.

305

Fig. 10.11. Abordarea Descendent

Fig. 10.10. Abordarea Ascendent
Capitolul10
306
Abordarea ascendent. Punctul de plecare poate fi reprezentat, de exemplu, de trei
relaii R1, R2 i R3 (figura 10.11.) cu urmtoarele scheme:
R1(MARCA, NUME, VIRSTA)
R2(MARCA, NUME, VIRSTA)
R3(MARCA,NRO, TARIF, LM, SEF)
cu fiecare relaie stocat ntr-o baz de date local, dar privind salariaii care aparin aceleiai
societi. Plecnd de la aceste relaii vom defini relaia global cu schema:
SALARIAT (MARCA, NUME, VIRSTA, SALARIU, LM, SEF)

Atributele relaiei SALARIAT sunt reprezentate de:
- atribute existente n R1, R2 i R3:MARCA,NUME,VIRSTA,LM,SEF;
- atribute care corespund unor valori calculate plecnd de la cele existente n R1, R2 i
R3: SALARIU ca produs NRO*TARIF.

10.5. Criterii de localizare i regsire a datelor

Elementele rezultate din activitatea de fragmentare i replicare sunt plasate pe diferite
noduri ale reelei de calculatoare. Eementele de date plasate pe un nod al reelei constituie o
baz de date local. Sistemul asigur transparena localizrii i autonomia nodului (a BDL
stocat n nod).
n cazul distribuiei trebuie respectat convenia de unicitate a numelor (a obiectelor n
cadrul unei BDL i a numelor nodurilor BDL). Sinonimele i viziunile (vederile) permit
utilizatorilor s acceseze orice obiect din BDD folosind aceeai sintax ca la accesarea
obiectelor din propria instan a BDL.
Transparena localizrii se refer la faptul c sistemul BDD ascunde fa de utilizatori
localizarea real a datelor. Utilizatorii trebuie s cunoasc numai numele obiectelor BDD i s
aib privilegiile necesare pentru a le accesa cu funciile solicitate. Principalele avantaje ale
transparenei localizrii sunt:
- utilizatorul nu trebuie s rein sau s-i reaminteasc unde sunt localizate datele i
obiectele;
- BDD (tabelele) pot fi mutate ntre BDL fr nici-un impact asupra utilizatorilor sau
aplicaiilor lor.
Autonomia BDL se refer la faptul c fiecare BDL parte a unei BDD este administrat
separat i independent de celelalte BDL. Avantajele autonomiei sunt:
- o mai bun rezisten la incidente;
- BDL este disponibil pentru toi utilizatorii atta timp ct BDL i reeaua de
calculatoare este disponibil;
- nu exist un punct central a crui defectare oprete toate operaiile cu BDD;
- fiecare nod i continu activitatea local dac reeaua a czut;
- refacerea dup cderi este local;
- control local;
- dicionar de date pentru fiecare BDL;
- nodurile pot face actualizarea software-ului (upgrade software) independent.
307
Schimbrile la o BDL afecteaz numai acea BDL i trebuie s fie validate doar de ea. n
acest context domeniul de responsabilitate al ABD este mic i uor de controlat. n cadrul unei
BDD bazele de date locale (BDL) sunt egale i au responsabiliti egale.

10.5.1. Cazuri de distribuie

Considerm mulimea A = { a
1
, a
2,
..., a
p
} ale crei elemente sunt tupluri i o mulime C
de q calculatoare, C = { C
1
, C
2
, ....., C
q
}.
Fiecare calculator este capabil s stocheze totul sau o parte a lui A. Legtura
caracteristic ntre A i C se poate exprima cu ajutorul unei funcii de localizare "loc()":
C A
loc

()

Vom examina diversele cazuri de distribuire prin prisma naturii funciei de localizare.
Vom numi schema de alocare schema care descrie maparea complet a relaiilor sau
fragmentelor lor pe serverele care le stocheaz i care permite transferul de la o descriere logic
la o descriere fizic a datelor. Maparea poate fi:
- non-redundant, atunci cnd fiecare fragment (sau relaie) este alocat() unui singur
nod;
- redundant, atunci cnd un fragment (sau relaie) este alocat n dou sau mai multe
noduri.
Fiind date mulimea de elemente A i mulimea de calculatoare C vom numi grad de
distribuie a lui A (notat gradis(A)) numrul de calculatoare care conin elemente ale lui A.
Mulimea A considerat este o mulime global i n acest caz elementele sale se
situeaz la nivel global.
Cu aceste precizri avem urmtoarele cazuri de distribuie:
- distribuie trivial (gradis(A)= 1). Mulimea A este stocat n totalitatea sa pe un
singur calculator. n acest caz mulimea global i mulimea local coincid.
- partiionare (gradis(A)s q). Mulimea A este decupat n submulimi disjuncte,
fiecare fiind afectat unui singur calculator i numai unuia. Mulimea global este
reuniunea tuturor mulimilor locale.
- replicare total (gradis(A)= q. Mulimea A este copiat pe fiecare calculator.
Mulimea global este una din mulimile locale.
- partiionare cu replicare (1 s gradis(A) sq). Mulimea A este descompus i parial
replicat (duplicat) pe mai multe calculatoare. n acelai timp exist un ansamblu C'
_ C de calculatoare astfel nct reuniunea elementelor pe care le conin formeaz
mulimea A.
- element calculat (gradis(A)=). Nu exist nici un calculator care conine elemente
ale lui A. n acest caz elementele respective se obin prin calcul, pornind de la
elementele care sunt, la rndul lor stocate pe unul sau mai multe calculatoare (de
exemplu SALARIU = NRO*TARIF).

10.5.2. Criterii de distribuire i localizare a elementelor

Un element al lui A este nedecompozabil n raport cu distribuirea dac este stocat n
ntregime pe un singur calculator. n condiiile existenei unui mediu distribuit putem avea
urmtoarea clasificare a distribuirii i localizrii bazelor de date locale:
Capitolul10
308
- distribuie trivial i criterii de localizare direct. Numele mulimii este n
coresponden direct cu un nume de calculator (i numai unul) care conine toate
elementele lui A.
- distribuie prin restricie i localizare direct. Submulimile disjuncte ale lui A sunt
determinate ca restricii ale acestei mulimi. Restricia se aplic pe valorile care
compun elementele lui A. Lund ca exemplu relaia SALARIAT descris anterior,
un criteriu de partiionare pe dou calculatoare C
1
i C
2
ar putea fi efectuat pe
salariu:
- pe C
1
vom avea schema SALARIAT care va admite numai tuplurile bazei de
date care ndeplinesc condiia (SALARIU s 1500 );
- pe C
2
vom avea schema SALARIAT care va admite numai tuplurile care
ndeplinesc condiia (SALARIU >1500).
Fiecare restricie este o expresie predicativ i n cazul unei partiionri aceste
expresii trebuie s fie disjunctive. Acest tip de localizare este direct deoarece una
sau mai multe valori ale unui obiect permit obinerea direct a calculatorului unde se
afl (se va afla) acest obiect.
- partiionarea prin vecintate i localizare tranzitiv. Amplasarea unui element
depinde de cea a altuia (de exemplu repartizarea salariailor n baza de date a unei
societi cu mai multe ntreprinderi se face n locul unde figureaz ntreprinderea la
care sunt angajai).
La nivelul unui element a= (a
1
,a
2
, ...., a
p
) exist un subobiect compus a'=(a
k
,a
k+1
,
......, a
k+l
) al lui a astfel nct A
k
x A
k+1
x ... x A
k+l
reprezint de fapt cheia,
localizarea lui a reducndu-se la localizarea lui a'. Pentru acest gen de localizare ne
vom limita la o tranzitivitate de nivel 1 care semnific faptul c dac o relaie R este
vecina unei relaii S, aceasta din urm nu poate fi definit, ea nsi, prin vecintate
cu alt relaie.
- partiionarea cu duplicarea prin restricie. Fiecare restricie corespunde unei
expresii predicative. n cazul unei partiionri aceste expresii trebuie s fie disjuncte.
Dac expresiile nu sunt disjuncte (total) atunci se realizeaz o decupare care va
antrena duplicri dar va permite o localizare direct prin valoarea unui obiect
(permite obinerea direct a calculatorului pe care se afl/se va afla acest obiect).
De exemplu, dac avem distribuia: pe C
1
relaia SALARIAT cu restricia
800<=SALARIU<=1500 atunci salariaii cu salariul cuprins ntre [800, 1500] vor
avea datele stocate pe calculatoarele C
1
i C
2
.
- duplicare total i localizare direct. Se consider ca A este total duplicat pe o
mulime de calculatoare C
k
, C
k+1
, ..., C
k+p
. Localizarea unui element al lui A este
direct deoarece este suficient localizarea oricrui calculator pentru a regsi datele
cerute.
- partiionarea arbritrar, localizare calculat. n acest caz nu exist un criteriu
explicit de partiionare care s se poat descrie printr-o expresie predicativ sau prin
vecintate. Este necesar utilizarea unor funcii de localizare calculat care depind
de criterii proprii. Acest calcul trebuie s poat fi exprimat cu ajutorul unor reguli
globale explicite.

10.5.3. Optimizarea performanelor

ntroducerea redundanei (prin duplicare) ntr-un sistem distribuit este un factor
fundamental pentru optimizarea performanelor. Redundana are ca efect :
309
- o mai mare disponibilitate a datelor (o cdere a unui nod nu afecteaz prelucrarea n
sensul c cererile adresate acestuia vor fi redirectate ctre nodul care conine copia);
- o ameliorare a tipurilor de rspuns prin cutarea informaiilor n nodul cel mai
apropiat;
- o diminuare a ncrcrii SGBDD (mai multe copii n diverse noduri permite
descongestionarea nodului care ar fi coninut informaia cutat).
Dezavantajele principale ale utilizrii redundanei se refer la:
- asigurarea coerenei diverselor copii;
- problema costului de stocare.
n cazul introducerii redundanei avem urmtoarele soluii posibile pentru duplicare:
- total: dac BDD este duplicat n toate nodurile orice cerere poate fi executat n
ntregime pe un singur nod, deci se reduce la execuia local la un nod. Avantajul
acestei soluii este c avem performane foarte bune dar cu inconvenientul de avea
prea multe duplicri care pun probleme de actualizare i de capacitate de stocare.
- pe regiuni geografice: BDD este total duplicat pe o regiune geografic (un
ansamblu de noduri). Regionalizarea permite limitarea la o singur regiune a
prelucrrii cererii cu avantajul de a avea foarte bune performane fr a avea foarte
multe copii;
- mixt i alocarea copiilor n apropierea nodului utilizatorului avem cazurile :
- duplicare total;
- duplicare pe regiuni geografice;
- duplicare pe subansambluri de regiuni geografice;
- absena a duplicrilor.
O schem de optimizare a prelucrrilor distribuite a cererilor maximiznd performanele
i minimiznd duplicrile se realizeaz parcurgnd etapele :
- apropierea: cutarea, printre realizrile posibile, a realizrii optime care are o
"suprafa logic" minimal cu utilizarea duplicrilor;
- maximizarea prelucrrilor locale i filtraj al relaiilor locale inutile pentru criteriul de
distribuie;
- cutarea unui "baricentru" de execuie: gsirea unui nod unde trebuiesc transferate
rezultatele prelucrrilor locale i unde vor fi executate prelucrrile globale pentru
obinerea unei execuii globale optimale.
O metod de alocare a copiilor n vederea maximizrii performanelor este "cel puin o
copie pe o arie logic".
O arie logic poate fi definit ca un ansamblu de regiuni care sunt apropiate unele fa
de altele la nivelul distanei logice. Distana logic este definit ca timpul de transmisie a unei
entiti de informaie ntre dou noduri.
Pentru relaiile globale care sunt distribuite n ntreaga reea se fac duplicri pentru a
avea cel puin o realizare a fiecrei relaii globale n fiecare regiune logic.
Pentru relaiile globale care sunt distribuite ntr-o regiune geografic, sau ntr-un nod, se
poate evita efectuarea de noi duplicri graie apropierii i determinrii baricentrului.
La acest nivel o relaie globala (RG) poate fi extras dintr-un ansamblu de noduri i
caracterizat de o frecven de utilizare numit "utilizare":
RG = ({noduri}, utilizare)
Pentru utilizare vom distinge dou cazuri :
- "maxim": RG este utilizata foarte des;
- "normal": RG nu este utilizata foarte des.
Suprafaa logic (sl) a fiecrei relaii globale poate fi definit ca:
Capitolul10
310

= =
=
noduri
i
noduri
j
ij
DL sl
1 1
, unde DL
ij
este distana logic a unei uniti de informaie ntre dou noduri i
i j , cu i, i e {noduri} ale unei RG date.
Vom defini prin k media distanelor logice pentru o regiune geografic.
n funcie de valoarea lui sl se poate decide efectuarea duplicrilor pentru fiecare relaie
global, conform cu urmtorul porotocol:
- sl=0, RG distribuit pe un nod. Se vor efectua copii numai n cazul unei utilizri
maxime;
- sl <=k, RG este distribuit pe o regiune geografic. Se vor efectua copii numai n
cazul unei utilizri "maxime".
- sl >k, RG este distribuit n toat reeaua. Duplicarea nu mai depinde de tipul
utilizrii.
- dac a este limita maxim a sl a unei realizri atunci este necesar s facem duplicri
dac sl >=a i sl conine mai mult de o regiune logic.
Dac k=< a <=sl a unei regiuni logice, atunci fiecare RG pentru care sl>k trebuie s
aib cel puin propria s realizare n fiecare regiune logic i suprafaa logic a fiecrei realizri
posibile trebuie s fie inferioar lui a.

10.6. Implementarea distribuiei n SGBDD
comerciale

10.6.1. Implementarea distribuiei n Oracle

Un sistem de baze de date distribuite (figura 10.12) permite aplicaiilor accesul la datele
din baze de date locale i baze de date aflate la distan (remote databases). Setul de baze de
date inclus n sistemul distribuit apare utilizatorului ca o singur surs de date. Oracle distribuit
utilizeaz i o arhitectur de proces distribuit. Procesarea cererilor adresate bazelor de date
distribuite Oracle este realizat prin utilizarea unei arhitecturi client/server (serverul este
software-ul care gestioneaz baza de date iar clientul este aplicaia care cere informaii de la
server).
Figura 10.12 ilustreaz un sistem de baze de date distribuite Oracle n care sunt
implicate dou baze de date localizate pe servere separate: HQ i Sales. Comunicaia ntre
servere este asigurat de Oracle Net iar clientul poate realiza o conectare direct
(CONNECTED TO) sau indirect (IDENTIFIED BY). Cererile sunt adresate direct bazei
de date HQ (adresate local) i indirect bazei Sales (prin intermediul lui HQ care acioneaz ca
un client).

311
Oracle consider c sistemul
distribuit este omogen dac bazele
de date sunt baze de date Oracle (nu
conteaz versiunea). Pentru o
aplicaie client locaia i platforma
sunt transparente. Pentru a asigura
accesul la obiecte la distan cu
aceeai sintax utilizat pentru
obiectele locale pot fi create
sinonime pentru obiectele la
distan.
De exemplu, dac suntei
conectat la baza MFG i vrei s
accesai date din baza HQ prin
crearea unui sinonim pe MFG
pentru tabela la distan DEPT va
trebui s emitei cererea SELECT *
FROM DEPT; In acest mod
utilizatorii MFG nu trebuie s
cunoasc c baza se afl la distan.
Oracle consider c sistemul
distribuit este eterogen dac cel
puin o baz de date este o baz non-
Oracle. Pentru aplicaii baza (bazele) de date eterogen apare ca o singur baz de date Oracle
local. Serverul de baze de date acceseaz baza de date non-Oracle utiliznd Oracle
Heterogenous Services, o component a sa, n conjuncie cu un agent (transparent gateway).
Dac baza de date non-Oracle suport ODBC (Heterogenous Services ODBC) sau protocoale
OLE DB (Heterogenous Sevices OLE DB agent) se poate utiliza conectivitatea generic pentru
accesul la date, ceea ce reduce costul n cazul n care este necesar achiziia unui agent specific
de acces la date. Fiecare baz de date care particip la o baz de date distribuit este identificat
n mod unic prin numele bazei de date globale: numele este format prin prefixarea numelui sau
(DB_NAME) cu numele domeniului reea al bazei de date (specificat de DB_DOMAIN),
conform modului ilustrat n figura 10.13.
Numele bazei de date este format pornind de la o frunz n arbore i urcnd spre
rdcin. De exemplu Finance este n Division1 din ACME_TOOLS din domeniul com, adic:
finance.division1.acme_tools.com. Dac mai multe baze de date pot avea acelai nume local
numele global trebuie s fie unic. De exemplu, numele HQ este utilizat pentru dou baze de
date locale, numele lor global fiind:
hq.division1.acme_tools.com
hq.us.americas.acme_auto.com
Pentru Sales care apare de foarte multe ori putem distinge ntre Sales la diviziunea
Europa i Sales la diviziunea America astfel:
sales.uk.europe.acme_auto.com
sales.us.americas.acme_auto.com

Fig. 10.12 Un sistem de baze de date distribuite
Oracle
Capitolul10
312

Replicarea datelor. Un obiect replicat este un obiect al bazei de date care exist pe
multiple servere ntr-un sistem de baze de date distribuite. Intr-un mediu replicat orice
actualizri ale unui obiect replicat la un situ sunt aplicate la toate copiile la toate celelate situri.
Dac Oracle7 avea dou faciliti pentru a suporta replicarea datelor, snapshot i trigger-ele,
Oracle9i permite replicarea (advanced replication) urmtoarelor tipuri de obiecte: tabele,
indeci, vederi i obiecte vederi, pachete i corp de pachete, proceduri i funcii, tipuri de date
definite de utilizator i corpuri tip, trigger-e, sinonime, indeci tip i operatori definii de
utilizator. Mai mult la replicarea tabelelor sunt suportate faciliti avansate ca tabele partiionate,
tabele organizate ca indeci, tabele coninnd coloane cu tipul de dat definit de utilizator i
obiecte tabele.
Cereri distribuite. n cadrul unei BDD pot fi emise dou tipuri de cereri:
- cereri locale - cereri care se adreseaza unei singure BDL;
- cereri distribuite - cereri care solicit date localizate n mai multe BDL.
Din punct de vedere al utilizatorului nu exist nici-o deosebire ntre cele dou
(transparena localizrii); deosebirea exist doar n modul n care sistemul de BDD trateaz
cele dou tipuri de cereri. Cererea distribuit permite:
- referirea de date din mai multe BDL;
- efectuarea de jonciuni i cereri imbricate pe tabele situate pe noduri diferite;
- definirea de viziuni peste tabele localizate n BDL diferite.
Oracle permite utilizarea n context distribuit a urmtoarelor comenzi ale limbajului de
manipulare a datelor (DML): select (queries), insert, update, delete, select for update
(nealocat n sistemele eterogene) i lock table.
Rolul clienilor i serverelor. Un sistem de BDD este alctuit din clieni i servere. Un
calculator poate fi numai client (dac nu are o BDL localizat pe el), numai server (dac are
localizat o BDL pe el) sau i client i server (dac are localizat o BDL pe el i dac pe el se
execut i aplicaii client). Sistemul de BDD necesit ca legturile ntre BDL-urile care compun

Fig. 10.13. Aranjarea ierarhic a bazelor de date n reea
313
BDD s fie prestabilite. Ele se realizeaz cu ajutorul comenzii SQL CREATE DATABASE
LINK. Clientul este responsabil pentru execuia aplicaiei. El transmite comenzile SQL ale
aplicaiei la serverele care realizeaz funciile lor. Serverele analizeaz i execut aceste
comenzi i transmit rspunsul i/sau codul de retur la client.
Legturile baz de date. Conceptul central al sistemelor de baze de date distribuite
este legtura baz de date (database link), care este o conexiune ntre dou servere de baze de
date fizice care permite clienilor s o acceseze ca pe o baz de date logic. O legtur BD
conine urmtoarele informaii: - protocolul de reea; - numele nodului; - numele BD
[utilizator/parola]; - opiuni protocol. De notat c legturile nu sunt de la nici-un UID
(identificator utilizator) particular din BDL de origine la un UID specific din BDL destinaie.
Fizic, legtura de baze de date, este un pointer (stocat n dicionarul de date) care definete o
cale de comunicare cu sens unic de la un server de baze de date la altul. Pentru a accesa
legtura trebuie s ne conectm la baza de date care conine intrarea (descrierea legturii) n
dicionar. Pentru ca legtura s poat fi realizat fiecare baz de date din sistemul distribuit
trebuie s aib un nume unic global (Global Database Name identific unic server-ul n
sistemul distribuit) n domeniul reea. Legturile de baz de date pot fi create cu instruciunea
CREATE DATABASE LINK:

CREATE [SHARED] [PUBLIC] DATABASE LINK dblink [ CONNECT TO {
CURRENT_USER | user IDENTIFIED BY password [authenticated_clause] }
| authenticated_clause ]
[USING 'connect_string'];

Numele legturii este de regul acelai cu numele global al bazei de date. O legtur
de baze de date este schema unui obiect ntr-o baz de date care permite accesul la obiectele
din alt baz de date. O legtur odat creat permite, de exemplu, referirea tabelelor i
vederilor din alt baz de date.
Legturile de tip baz de date pot fi:
- private, reprezentate de legturi ntr-o schem specific a bazei de date locale. La
aceste legturi numai proprietarul sau procedurile PL/SQL pot accesa obiectele
corespondente din baza la distan. Aceasta legtur este mai sigur deoarece se
asigur un acces controlat. De exemplu, comanda:
CREATE DATABASE LINK sales.uk.europe.acme_auto.com; creeaz o legtur privat care
utilizeaz userid/password ale utilizatorului conectat
CREATE DATABASE LINK link_1 CONNECT TO CURRENT_USER USING 'us_supply';
creeaz o legtur privat numit link_1 la baza de date cu numele serviciului us_supply
- publice, o legtur de baze de date extins. O astfel de legtur poate fi utilizat de
orice utilizator i subprogram PL/SQL din baza de date pentru a accesa baza la
distan. Este eficient deoarece asigur partajarea legturilor dar nu mai este att
de sigur ca cea privat. De exemplu, comanda:
CREATE PUBLIC DATABASE LINK sales.germany.europe.acme_auto.com; creeaz o
legur public care utilizeaz userid/password ale utilizatorului conectat
CREATE PUBLIC DATABASE LINK legatura_publica CONNECT TO CURRENT_USER
USING 'uk_supply'; creeaz o legtur public numit legatura_publica la baza de date cu
numele serviciului uk_supply.
- globale, o legtur extins de reea. O astfel de legtur este posibil la utilizarea
serverelor de nume (acestea creaz i gestioneaz automat legturi de baze de date
globale pentru fiecare baz de date Oracle din reea). O astfel de legtur poate fi
utilizat de oricare utilizator i/sau procedur PL/SQL a bazelor de date pentru a
Capitolul10
314
accesa obiectele n baza la distan indicat de legtur. Aceste legturi permit o
gestiune centralizat i simpl.

Legturile publice respect mai puin securitatea datelor dect cele private, deoarece aici
au fost incluse toate tabelele de la distan i toate privilegiile pentru comunitatea de utilizatori
care folosesc aceast legtur (mai mult dect are nevoie fiecare utilizator n parte), dar n
acelai timp simplific activitatea de creare a legturilor. Asigurarea transparenei locaiei poate
fi fcut prin utilizarea vederilor, definirea de sinonime sau utilizarea de proceduri. Oracle
permite crearea de sinonime pentru tabele, tipuri de date, vederi, vederi materializate, secvene,
proceduri, funcii i pachete.
n unele situaii este necesar s se declare mai multe legturi de acelai tip care s
puncteze la aceeai baz de date dar care s utilizeze alte ci de acces. Oracle permite
declararea legturilor de baze de date cu specificarea numelui serviciului optimal (calificator
de conexiune introdus cu simbolul @). Tipurile de legturi utilizator sunt ilustrate n tabelul
urmtor:

Tabelul 10.2. Tipurile de legturi utilizator
Tip Legtura Descriere
Legtura Utilizator
Conectat
Utilizatorii se conecteaz la baza la distan cu numele i parola
lor (au un cont cu acelai nume de utilizator i parol att n baza
local ct i n cea la distan.
Legtura Utilizator
Fix
Utilizatorii se conecteaz la baza la distan cu numele i parola
lor referite n legtur.
Legtura Utilizator
Curent
Un utilizator se conecteaz ca utilizator global. Un utilizator
local se poate conecta ca utilizator global n contextul
procedurilor stocate fr a memora parola global a
utilizatorului ntr-o definire de legtur.

Fig. 10.14. Database Link
(Sursa: Oracle9i Database Administrator's
Guide Release 2 (9.2) Part Number A96521-01)
315
Legturile BD definite sunt memorate n dicionarul datelor BDL de origine (ca
viziunile USER_DB_LINKS, ALL_DB_LINKS i DBA_DB_LINKS). V$DBLINK permite
vizualizarea conexiunilor deschise n cadrul unei sesiuni, iar GV$DBLINK permite vizualizarea
legturilor deschise in sesiune mpreun cu instanele corespondente.
O legtur poate fi utilizat dedicat sau partajat. O legtur partajat are loc ntre un
proces al bazei de date locale i baza la distan (mai multe procese client pot utiliza aceeai
legtur simultan). Partajarea permite reducerea conexiunilor dintre baza de date local i cea la
distan sau dintre serverul local i serverul la distan.
Administrarea BDD. ABD trebuie s-i asume responsabilitatea pentru ntreaga BDD.
ABD este o singur persoan sau mai multe (un grup). In cazul n care exist mai multe
persoane pe acest rol ele trebuie s-i coordoneze activitatea pe toate aspectele BDD: reea,
proiectarea BDD, securitatea i integritatea datelor distribuite, performane.
Protocolul de realizare n dou faze. O tranzacie distribuit poate implica alterarea
datelor din mai multe baze de date i, n consecin, prelucrarea distribuit este mai complicat
dect cea normal deorece Oracle trebuie s coordoneze revenirea sau realizarea (consemnarea)
schimbrii ca un obiect unitar. Tranzaciile distribuite sunt tranzaciile care fie citesc date din
mai multe BDL fie modific date din mai multe BDL. Pentru a asigura prelucrarea cererilor
Oracle implementeaza Protocolul de Realizare in Doua Faze - 2PC (mecanizmul de realizare n
dou faze). Protocolul de realizare n dou faze asigur fie execuia corect i complet a
tranzaciei, fie anularea peste tot a efectelor tranzactiei. Toate nodurile participante n tranzacia
distribuit trebuie s execute aceeai aciune: ele trebuie fie s realizeze toate fie s revin toate
la starea dinaintea execuiei tranzaciei.
Protocolul de realizare n dou faze asigur transparena actualizrilor distribuite la
multiplele defeciuni care pot aprea n reeaua pe care se lucreaz.
Reluam modul de utilizare a protocolului de realizare n doua faze (ca tratare
implementat de Oracle):
- Faza de pregtire - la lansarea/iniierea unei actualizri distribuite, nodul de unde se
lanseaz tranzacia devine nod coordonator global (global coordinator) pentru acea
tranzacie. El analizeaz tranzacia i determin bazele de date locale ce vor participa
la execuia tranzaciei. Le transmite tranzacia sau pri ale acesteia i ordinul
'PREPARE' (cu excepia nodului Commit Point Site). Dac apar incidente la aceast
transmitere coordonatorul anuleaz tranzacia. Dac totul a decurs normal ateapt
rspuns de la BDL-uril implicate. Dac primete un raspuns de 'ABORT' de la cel
puin una din ele coordonatorul anuleaz tranzacia. Dac primete raspuns
'PREPARED' de la toate atunci faza de pregtire s-a ncheiat i se trece la faza a
doua. Nodul de realizare (Commit Point Site) are ca sarcin iniierea operaiilor de
realizare sau revenire conform instruciunilor primite de la nodul coordonator
global. Pregtirea unui nod nseamn:
- nregistrarea informaiei n fiierele jurnal online redo logs;
- plasarea unei blocri distribuite pe tabelele modificate pentru a preveni citirea
lor.
Paii n faza de pregtire pentru fiecare nod participant cu excepia sitului punct de
realizare (commit point site):
- Nodul cere ca toi descendenii si, adic nodurile referite subsecvent, s se
pregteasc de realizare;
- Nodul controleaz pentru a vedea dac tranzacia modific nsi datele
sale sau ale descendenilor. Dac nu are de modificat date sare peste restul
pailor i returneaz rspunsul numai citire (read-only);
- Nodul aloc resursele necesare realizrii tranzaciei dac datele se schimb;
Capitolul10
316
- Nodul salveaz nregistrrile de revenire corespunztoare tranzaciei n
fiierul jurnal online (online redo log);
- Nodurile garanteaz c blocrile fcute pentru tranzacie sunt capabile s
supravieuiasc unei cderi;
- Nodul rspunde nodului iniiator cu rspunsul PREGTIT sau dac unul
din descendeni nu a putut realiza pregtirea cu rspunsul ABORT.
- Faza de realizare - coordonatorul transmite ordinul 'COMMIT' la BDL-urile
implicate i ateapt mesajul 'TERMINATED' de la fiecare din ele. Dac apare un
incident n cadrul acestei faze rezultatul este neschimbat iar tranzacia este
considerat realizat. La BDL cu incidentul, dup repunerea n funciune, o
procedur automat determin stadiul n care ajunseser tranzaciile care se executau
la momentul cderii, i n funcie de acesta se realizeaz sau se face revenire
(rollback). Faza de realizare const n paii:
- Coordonatorul global instrucioneaz situl punct de realizare s realizeze;
- Situl punct de realizare realizeaz;
- Situl punct de realizare informeaz nodul coordonator global c a realizat;
- Coordonatorii globali i locali transmit un mesaj tuturor nodurilor
instrucionndu-le s realizeze tranzacia;
- La fiecare nod, Oracle realizeaz poriunea local din tranzacia distribuit i
deblochez nregistrrile;
- La fiecare nod, Oracle nregistreaz o intrare adiional n fiierul redo log
local indicnd c tranzacia s-a realizat;
- Nodurile participante notific nodul global coordonator c au realizat.
La Oracle implementarea 2PC are unele particulariti i anume:
- nodul BD de unde se lanseaz tranzacia este Coordonator Global (Global
Coordinator - GC);
- nodul BD care trebuie s fac acces la alte noduri pentru a-i completa partea sa de
tranzacie este coordonator local (Local Coordinator - LC);
- fiecare nod BD al BDD are un CPS (Commit Point Strength - este un parametru de
iniializare COMMIT_POINT_STRENGTH cu valori ntre 0 i 255), care reprezint
importana pe care o joac acel nod de BD n procesul de realizare. Un nod BD cu
CPS mai mare are prioritate mai mare dect un nod BD cu CPS mai mic;
- nodul BD cu CPS cel mai mare dintre nodurile BD care particip la execuia
tranzaciei este Nod de Realizare (Commit Point Site). El nu trece prin faza de
'PREPARE';
- n faza de pregtire nodul GC contacteaz fiecare BD din reea i o ntreab dac are
resurse i este pregtit s participe la execuia tranzaciei. Fiecare BD implicat este
responsabil s anune nodul GC atunci cnd este gata. Pregtindu-se fiecare nod
nregistreaz suficiente informaii nct s poat n egal msur s realizeze sau s
anuleze tranzacia n funcie de decizia luat de GC. Cnd o BDL este n faza de
pregtire, ea blocheaz datele ce vor fi afectate de tranzacie, execut tranzacia
(rezultatele nu sunt scrise definitiv n baza de date) i jurnalizeaz aceste modificri.
Dac nu sosete rspuns de la toate nodurile implicate atunci tranzacia este anulat
(rollback). Dac se returneaz cel puin un mesaj 'ABORT' atunci GC informeaz
fiecare BD implicat sa anuleze (rollback) tranzacia. Dac toate nodurile BD
implicate rspund 'PREPARED' se trece la faza de realizare. Nodul de Realizare
(Commit Point Site) este primul care realizeaza schimbrile n BDL. Apoi i
celelalte noduri implicate, din ierarhia distribuit, realizeaz tranzacia n ordinea
CPS-ului lor. Dup realizare fiecare transmite la GC mesajul de terminare. Cnd a
primit toate mesajele GC l informeaz pe CPS (Commit Point Site) c s-a terminat
317
i apoi marcheaz tranzacia ca realizat. Dac un nod de BD cade la momentul
realizrii, procesul RECO (recovery) al acelui nod va reface automat BDL cnd
aceasta va fi restartat i va decide realizarea sau anularea tranzaciei. Procesul
RECO utilizeaz informaiile din tabela dicionarului DBA-2PC-PENDING.

10.6.2. Implementarea distribuiei n DB2

IBM propune o soluie de distribuire pentru sisteme de gestiune a bazelor de date
relaionase denumit DRDA (Distributed Relational database Architecture) i o soluie de
distribuire care admite surse de date eterogene (fiiere XML, baze de date de orice tip etc)
denumit Federated Database (baza de date federativ).
DRDA. DRDA este un set de protocoale care permit att sistemelor de baze de date
multiple, IBM i non-IBM, ct i aplicaiilor multiple s lucreze mpreun. Orice combinaie
de sisteme de gestiune a bazelor de date relaionale care utilizeaz DRDA pot fi conectate
pentru a forma un sistem relaional distribuit. Sistemul distribuit utilizeaz noiunile de unitate
de lucru (UOW) i unitate de lucru distribuit (DUOW).
O unitate de lucru (UOW Unit Of Work) este o singur tranzacie logic constnd
dintr-o secven de instruciuni SQL care fie este prelucrat cu succes (toate operaiile sunt
realizate cu succes) fie este considerat n ntregime eec (chiar dac numai una din operaii
este eec iar celelalte sunt ncheiate cu succes).
O unitate de lucru distribuit (DUOW Distributed Unit Of Work), cunoscut i sub
numele de actualizare multi-sit, implic mai mult de un server de baze de date i are
caracteristicile:
- unitate de lucru actualizeaz mai mult de un server de baze de date;
- aplicaia direcioneaz distribuia i iniiaz realizarea;
- pot fi mai multe cereri pe unitatea de lucru;
- exist un singur server de gestiune pe cerere;
- realizarea este coordonat pe mai multe servere de baze de date.
Protocolul de realizare n dou faze. n figura 10.14 sunt ilustrai paii parcuri la
realizarea unei tranzacii distribuite utiliznd protocolul n dou faze. Semnificaia
pailor ilustrai n figura 10.15. este:
- Aplicaia este pregtit pentru protocolul de realizare n dou faze (prin opiuni de
precompilare sau configurarea interfeei de apel (CLI-Call Level Interface);
- Atunci cnd un client vrea s se conecteze la baza de date SAVINGS_DB
(economii) va fi mai inti conectat intern la baza de date a managerului de
tranzacii (TM) Dac parametrul de configurare al tm_database este setat la
1ST_CONN atunci SAVINGS_DB devine gestionar al tranzaciei (transaction
manager) pe durata instanei acestei aplicaii;
- Conectarea la SAVINGS_DB este acceptat i efectuat;
- Baza de date client ncepe actualizarea tabelei SAVINGS_ACCOUNT (cont de
economii; depozit). Aceasta incepe unitatea de lucru. Baza de date TM rspunde
bazei de date client furniznd un identificator tranzacie (transaction ID) pentru
unitatea de lucru;
- Dup primirea identificatorului de tranzacie baza de date client nregistreaz
unitatea de lucru cu baza de date care conine tabela SAVINGS_ACCOUNT, baz
care rspunde clientului ca nregistrarea s-a efectuat cu succes;
- Cererile transmise ctre SAVINGS_DB sunt manipulate normal. Rspunsul la
fiecare instruciune ncorporat n program este returnat n SQLCA;
Capitolul10
318
- Identificatorul de tranzacii este nregistrat n baza de date FEE_DB (onorariu)
care conine tabela TRANSACTION_FEE, la primul acces la aceast baz de date
efectuat n cadrul unitii de lucru;
- Toate instruciunile SQL adresate bazei de date FEE_DB sunt manipulate n
modul normal;
- Pe baza de date SAVINGS_DB pot fi rulate cereri SQL adiionale setnd
conexiunea dup cum este necesar. Deoarece unitatea de lucru s-a nregistrat n
SAVINGS_DB n pasul 4 baza de date client nu mai trebuie s parcurg din nou
acest pas;
- Conectarea la i utilizarea bazei CHECKING_DB (cont curent) urmeaz aceleai
reguli descrise n 6 i 7;
- Atunci cnd baza de date client cere realizarea unitii de lucru se trimite mesajul
pregtete (prepare) la toate bazele de date care particip la unitatea de lucru.
Fiecare baz de date scrie o nregistrare PREPARED n fiierul log, i rspunde
bazei de date client;
- Dup ce baza de date client primete un rspuns pozitiv, de la toate bazele de date,
trimite un mesaj bazei de date de gestiune a tranzaciei (TM) pe care o informeaz
ca este gata de realizare (PREPARED). Baza de date de gestiune a tranzaciei scrie
o nregistrarePREPARED n fiierul su log i trimite un rspuns la client pentru
al informa ca poate starta Faza Doi a protocolului;
- Pe durata fazei doi a protocolului de realizare baza de date client trimite un mesaj
tuturor bazelor participante prin care le cere sa realizeze (COMMIT). Fiecare baz
de date scrie o nregistrare COMMITED n fiierul su log i elibereaz
blocrile realizate n timpul lucrului. Cnd o baz termin realizarea trimite un
rspuns clientului;
- Dup ce baza de date client a primit rspunsuri pozitive de la toate bazele de date
participante trimite un mesaj gestionarului de tranzacii prin care confirm
realizarea unitii de lucru. Baza de date de gestiune a tranzaciilor scrie o
nregistrare COMMITED n fiierul su log indicnd c unitatea de lucru este
realizat, i rspunde clientului indicnd c a terminat.
Sistem Federativ. Un sistem federativ (figura 10.16) este un tip special de sistem de
gestiune a bazelor de date distribuite care const din una sau mai multe instane de baze de
date DB2 care opereaz ca server federativ, o baz de date care acioneaz ca o baz
federativ, una sau mai multe surse de date i, clieni (utilizatori i aplicaii) care acceseaz
baza de date i sursele de date. Intr-un astfel de sistem se pot adresa cereri SQL distribuite
multiplelor surse de date pe care le gestioneaz. De exemplu, cu o singur instruciune SQL,
se pot jonciona date localizate ntr-o tabel DB2, o tabel Oracle i un fiier XML. Sursele de
date n sistemul federativ sunt autonome i pot fi reprezentate, de exemplu, de baze de date
relaionale (ca Oracle sau Sybase) sau surse non-relaionale (cum ar fi un fiier XML, de
exemplu). Autonomia surselor de date se refer la faptul c, de exemplu, serverul federativ
poate trimite o cerere la o baz de date Oracle i n acelai timp aplicaiile Oracle pot accesa
aceeai surs. O alt caracteristic important este aceea c prin intermediul unei surse de date
se poate accesa o alte surs de date, acces efectuat cu metoda sau protocolul specific tipului de
surs.
Un sistem federativ are abilitatea de a:
- corela datele din tabelele locale i sursele la distan ca i cum toate datele ar fi
stocate local n baza federativ;
- actualiza datele n sursele relaionale ca i cum datele sunt stocate n baza
federativ;
- muta datele n i din sursa relaional;
319

Fig. 10.15. Paii de realizare a tranzaciilor utiliznd protocolul n dou faze

Baza de date federativ dispune de un catalog global care conine informaii att
despre obiectele bazei de date federative ct i despre obiectele de la sursele de date.
Interaciunea bazei de date federative cu sursele de date este realizat prin intermediul
mecanismelor denumite wrapper (supracoperta) reprezentate de rutine stocate in biblioteci
ca modul supracopert (wrapper module). Funciunile specifice realizate de o
supracopert sunt reprezentate de:
- conectarea la sursa de date (prin conexiunea standard API);
- transmiterea cererilor sursei de date exprimate n SQL, pentru sursele de date care
suport SQL, sau exprimate n limbajul nativ de cereri al sursei, pentru sursele care
nu suport SQL;
- primirea rezultatelor de la surse (prin intermediul unei serii de apeluri API);
- a rspunde cererilor bazei de date federative privind maprile implicite de tipuri de
date pentru o surs de date;
- a rspunde cererilor bazei de date federative privind maprile implicite de funcii
pentru o surs de date.
- profita de puterea de prelucrare a surselor de date prin trimiterea la aceste surse a
cererilor pentru prelucrare;
- compensa pentru limitrile SQL la sursa de date prin prelucrarea unor pri din
cererea distribuit la server-ul federativ.

Capitolul10
320
Aplicaiile nu necesit instruciuni speciale pentru a interaciona cu datele federate ci
interacioneaz similar oricrei aplicaii client DB2: aplicaia trimite cereri SQL bazei de date
federative care distribuie cererea sursei de date propice, colecteaz datele cerute i returneaz
aceste date aplicaiei.

Fig. 10.16. Componentele unui sistem federativ

Depozite de date
321

Capitolul 11
Depozite de date

11.1. Prezentare general

11.1.1. Noiuni de baz

nc de la nceputurile erei informatice, managerii au neles c datele stocate de
sistemele informatice operaionale reprezint o min de aur informaional care se cere
exploatat. Eforturile n aceast direcie au nscut generaii de acronime: MIS (Management
Information Systems - sisteme de management al informaiei), DSS (Decision Support
Systems - sisteme suport de decizie), EIS (Executive Information Systems - sisteme
informatice executive), MSS (Management Support Systems - sisteme suport pentru
management).
Depozitele de date, sub un nume sau altul, au aprut n gndirea comunitii
informatice la sfritul deceniului trecut. Acestea reprezint o cerin acut a organizaiilor
moderne (fie ele ntreprinderi, bnci, administraie etc.) i, totodat, o realitate tehnologic
pus n practic din ce n ce mai frecvent. Ultimele cifre estimate de IDC referitoare la piaa
depozitelor de date indic faptul c aceasta va nregistra o cretere de 9% pn n 2009,
atingnd o valoare de 14.5 miliarde de dolari, unde momentan volumul su este de
aproximativ 10 miliarde de dolari. De asemenea, Gartner Group estimeaz o cretere dubl pe
piaa depozitelor de date n raport cu creterea global a pieei de IT.
Depozitele de date sunt produsul mediului economic i al tehnologiilor avansate. Din
perspectiv economic, globalizarea comerului, acutizarea dramatic a concurenei,
reducerea spectaculoas a ciclurilor de via al produselor datorit dinamicii tehnologiei i
impunerea unor cerine calitative extrem de ridicate au evideniat i mai mult valoarea
strategic a informaiei. Manipularea operativ a informaiei a impus la rndul ei dou modele
manageriale, mai suple i mai adecvate din punct de vedere funcional. Nevoia de a rspunde
n timp optim cerinelor pieei a condus la descentralizare i la reducerea numrului nivelelor
decizionale, consacrnd aa-numitele "ierarhii plate", care se bazeaz pe delegarea puterii
decizionale operative ctre ealonul managerial secund. Practic, clasicul funcionar este pe
cale de a fi nlocuit de "lucrtorul cu informaii". Att la nivelul conducerii strategice, ct i la
nivelul managementului operativ, nevoia de informaie pur, corect i semnificativ a
devenit vital.
Din perspectiv tehnologic, ultimii ani au adus puterea de calcul la preuri accesibile.
Servere paralele bazate pe microprocesoare ieftine rivalizeaz ca putere cu
supercalculatoarele, la o fraciune din preul acestora. Sistemele de baze de date pot exploata
la maximum arhitecturile hardware paralele, iar evoluiile spre sisteme deschise permit o
Capitolul 11
322
conectivitate aproape total la orice fel de surse de date i interoperabilitate ntre diverse
platforme software/hardware. Mediile de stocare magnetice i optice admit volume de ordinul
giga i chiar terabytes.
Microcalculatoarele au ajuns i ele la maturitate. Puterea lor este acum suficient
pentru funciile de analiz i prezentare care le sunt rezervate, iar interfeele grafice intuitive
le fac accesibile utilizatorilor neprofesioniti, n spea managerilor.
Sistemele informatice operaionale exist, datele pot fi accesate oriunde, nevoia de
informaie este acut, puterea de calcul i de stocare este ieftin, instrumentele software sunt
accesibile, toate acestea creeaz un cadru favorabil implementrii depozitelor de date.
Rolul unui depozit de date este de a oferi o imagine coerent asupra datelor referitoare
la activitatea unei organizaii i a contextului n care aceasta acioneaz. Spre deosebire de
coleciile de date utilizate de sistemul operaional - orientate spre optimizarea i sigurana
procesrii datelor - datele dintr-un depozit de date sunt organizate ntr-o manier care s
permit analizarea lor, deci extragerea semnificaiei economice pe care o poart. Depozitul de
date separ spaiul de lucru al analizei de spaiul de lucru al tranzaciilor i ofer posibilitatea
organizaiilor s consolideze datele din mai multe surse. Sursa principal sunt sistemele
operaionale, iar ca surse secundare pot fi att surse interne, ct i surse externe, cum ar fi
bazele de date publice: date statistice furnizate de instituii specializate, date de prognoz
economic furnizate de instituii orientate pe studiul pieei, date obinute n urma unor sondaje
de opinie, etc.
William Inmon, vicepreedintele firmei Prism Solutions, este considerat printele
necontestat al noiunii depozit de date" n nelesul ei curent, deinnd de altfel trademark-ul
termenului data warehouse. Viziunea sa despre depozitele de date se concentreaz asupra
rolului acestora de baz informaional a deciziei manageriale, pstrnd astfel un nivel nalt
de generalitate i permind unor multiple implementri s intre n sfera acestei noiuni.

Definiia lui Inmon este extrem de concis: Un depozit de date este o colecie de date
orientate pe subiecte, integrate, istorice i nevolatile, fiind destinat fundamentrii deciziei
manageriale.

n continuare vor fi prezentate caracteristicile evideniate de aceast definiie.

- Orientare pe subiecte
Datele operaionale sunt orientate pe aplicaii, n sensul c organizarea lor este
optimizat pentru a servi procesului tranzacional, dinamicii sistemului. n contrast, depozitul
de date este orientat pe subiectele importante ale procesului economic, cum ar fi: clieni,
furnizori, produse, activiti. Aceste subiecte necesit informaii din diferite surse pentru a
furniza o imagine complet a domeniului. n loc de a se concentra pe procesarea operaiilor i
tranzaciilor zilnice dintr-o organizaie, un depozit de date se focalizeaz pe modelarea i
analiza datelor pentru luarea deciziilor. Din acest motiv, depozitele de date ofer, n mod
tipic, o viziune simpl i concis, relativ la un subiect specific, excluznd datele care nu sunt
utile n procesul de sprijinire a deciziei.
Un exemplu simplu poate fi edificator: o comand lansat de un client va fi
consemnat de sistemul operaional printr-un set de nregistrri care vor conine informaii
despre client, informaii despre produsele sau serviciile comandate, informaii despre modul
de transport i modul de plat, etc. Atenia sistemului tranzacional este orientat ctre
consistena cheilor, astfel nct operaia s pstreze consisten. Multe dintre datele eseniale
din perspectiv operaional (numrul comenzii, poziiile liniilor n cadrul comenzii etc.) sunt
complet lipsite de relevan din perspectiv informaional.
Depozite de date
323
O consecin important a acestei orientri este redundana datelor. Dac n sistemul
operaional redundana este controlat (prin procesul de normalizare) pentru a evita anomaliile
de actualizare, n depozitul de date redundana este creat n mod intenionat (prin
denormalizare i sumarizare) pentru a permite un acces tematic mai facil.

- Integrare
Este cel mai important aspect al depozitului de date i, n cele din urm, raiunea
pentru care acesta este creat. Datele sunt adunate aici pentru a rspunde nevoilor
informaionale ale ntregii organizaii, asigurnd faptul c rapoartele generate pentru diverse
compartimente vor conine aceleai rezultate. Sistemul operaional este de cele mai multe ori
format din subsisteme semiindependente, create la momente diferite, de echipe diferite, n
maniere diferite, iar rezultatul, dei funcional, este imposibil de folosit pentru analiz.
Integrarea unor multiple surse heterogene: baze de date relaionale, fiiere, nregistrri
privind tranzaciile on-line, impune implementarea unor tehnici de curire a datelor (data
cleaning) i de integrare pentru a se asigura consistenta datelor din depozit.

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

- Persistena datelor
Esena aplicaiilor operaionale este actualizarea continu a coleciilor de date,
actualizare realizat n general pe baza tranzacional. Orice tranzacie procesat implic
adugarea unor noi nregistrri, modificarea sau eventual tergerea altora etc. Cu totul altfel
stau lucrurile n cazul depozitului de date, unde o astfel de dinamic lipsete. n mod uzual
sunt solicitate doar dou operaiuni n accesarea datelor: ncrcarea iniial a datelor i accesul
la date pentru citire. Practic, singura actualizare care se realizeaz este adugarea periodic a
unor date extrase din sistemele operative.
Din punctul de vedere al proiectrii, aceast diferen este extrem de important. n
sistemul operaional, o tranzacie trebuie s duc colecia de date dintr-o stare consistent ntr-
o alt stare consistent, iar aceasta implic mecanisme extrem de complexe de meninere a
integritii datelor, mai ales n situaia sistemelor intens concureniale: mecanisme de
jurnalizare, mecanisme de salvare/restaurare/refacere, mecanisme de detectare a blocrilor
circulare (dead lock) etc. n cazul depozitelor de date, aceste mecanisme sunt inutile, astfel c
gradul de libertate ctigat poate fi utilizat pentru optimizarea accesului la date prin
denormalizare, sumarizare, statistici ale accesrii datelor i reorganizare dinamic a indexrii
etc.

Capitolul 11
324
11.1.2. Obiectivele unui depozit de date

Primele domenii care au adoptat tehnologia depozitelor de date au fost
telecomunicaiile i comerul cu amnuntul. Ulterior, depozitele de date au ptruns i n alte
domenii cum ar fi industria farmaceutic, sistemul sanitar, asigurri, transporturi. Studiile
statistice arat c telecomunicaiile i sistemul bancar se menin n top, ntruct aloc cel puin
15% din bugetul IT pentru proiecte referitoare la depozite de date.

Cteva dintre obiectivele urmrite n construirea unui depozit de date sunt:
- Executarea unor activiti de server/disc asociate cu interogarea i raportarea pe
servere/discuri care nu sunt utilizate de sistemele de procesare a tranzaciilor.
Firmele vor ca sistemele s proceseze o tranzacie ntr-un timp rezonabil.
Rapoartele i interogrile, utiliznd n mod variabil resursele fizice (server/disc),
ncetinesc procesarea tranzaciilor, i fac ca serverele/discurile s fie dificil de
organizat. De aceea, firmele pot considera c implementarea unei arhitecturi data
warehouse care utilizeaz servere/discuri separate este un mod mai ieftin sau/i
mai organizat de a obine un timp de procesare a tranzaciilor acceptabil. Procesele
decizionale i procesele operaionale sunt total divergente arhitectural.
- Utilizarea unor modele de date i/sau tehnologii server care accelereaz
interogarea i raportarea i care nu sunt adecvate pentru procesarea
tranzaciilor. Exist modele de date care accelereaz interogarea i raportarea (de
exemplu, schema stea, vezi 11.4.1) i care nu sunt adecvate pentru procesarea
tranzaciilor, pentru c tehnica de modelare o va ncetini i complica. De
asemenea, exist i tehnologii server care pot mbunti viteza pentru interogare i
raportare, dar ncetinesc procesarea tranzacional (indexarea de tip bitmap) i
anumite tehnologii care acioneaz n sens invers (tehnologii pentru restaurarea
datelor).
- Furnizarea unui acces sporit la date pentru utilizatori. Depozitul de date
furnizeaz accesul la datele integrate ale ntreprinderii, anterior blocat prin ci
neprietenoase. Utilizatorii pot acum s stabileasc, cu un minim de efort, o
conexiune garantat la depozitul de date prin intermediul unui calculator.
- Oferirea unui depozit de date "curat", furniznd o singur versiune a realitii.
Depozitul de date ofer posibilitatea de a cura datele fr modificarea sistemului
de procesare a tranzaciilor. Datele din depozitele de date sunt consistente i au
calitatea asigurat nainte de a fi puse la dispoziia utilizatorilor. n msura n care
se utilizeaz o surs comun de date, depozitele de date pun capt dezbaterilor
privind veridicitatea datelor utilizate pentru realizarea rapoartelor.
- Facilitarea interogrii i raportrii pe date provenite din mai multe sisteme
tranzacionale i/sau din surse externe de date. Mult vreme firmele care aveau
nevoie de rapoarte bazate pe date provenite din mai multe sisteme au rezolvat
aceast problem prin extragerea, sortarea i combinarea datelor, n final lansnd
n execuie rapoarte asupra lor. n multe cazuri aceast soluie este una adecvat.
Dar, dac o companie are multe date care trebuiesc sortate/combinate frecvent,
dac datele din sistemele tranzacionale trebuie "curate", atunci soluia adecvat
este depozitul de date.
- Acces combinat sintez/detaliu la date. Rapoartele dinamice i instrumentele de
integrare OLAP permit utilizatorilor s vizualizeze informaiile din depozitul de
date sub diferite unghiuri i la diferite niveluri de detaliere. Aceste disponibiliti
oferite de depozitele de date reduc timpul i efortul necesar pentru colectarea,
formatarea i filtrarea informaiilor plecnd de la date.
Depozite de date
325
- nregistrarea cu acuratee a trecutului. Datele istorice sunt deseori eliminate din
sistemul de procesare a tranzaciilor pentru a optimiza i controla timpul de
rspuns al sistemului. Pentru interogare i raportare, aceste date i datele curente
pot fi stocate n depozitul de date n cadrul cruia timpul de rspuns ateptat se afl
la un nivel mai ridicat.
- mpiedicarea persoanelor care au nevoie de acces doar pentru raportare i
interogare s aib acces la bazele de date ale sistemului de procesare a
tranzaciilor. Acest punct privete securitatea. De exemplu depozitul de date poate
fi un punct de interes pentru firmele care doresc s permit raportarea i
interogarea prin intermediul Internetulul.

Un proiect pentru depozite de date reprezint ns o investiie riscant i scump.
Costurile tipice pentru dezvoltarea unui depozit de date ntr-un interval de 3-6 luni se situeaz
ntre 0,8 i 2 milioane USD. Ponderea echipamentelor se situeaz ntre 1/2 i 2/3 din costul
total al proiectului. O soluie pentru firmele mici i mijlocii este recurgerea la data marts
pentru care costurile se situeaz sub 100.000 USD ntr-un interval adesea sub 90 de zile.
Uneori investiiile n depozitele de date nu se finalizeaz cu succes. Motivaiile cele mai des
ntlnite pentru eecul unor depozite de date includ:
Lipsa de nelegere a complexitii proiectelor de business intelligence;
Lipsa de nelegere a faptului c soluiile de business intelligence implic cel mai
adesea subunitati multiple ale companiei, ceea ce le face diferite de soluiile stand-
alone;
Reprezentanii companiei sunt indisponibili sau neinteresai;
Lipsa de personal pregtit disponibil sau utilizarea suboptimal a acestuia;
Structura inadecvat a echipei de proiect;
Lipsa unei abordari iterative n dezvoltarea soluiei;
Management de proiect ineficient;
Lipsa de metodologie;
Lipsa de apreciere asupra impactului datelor necurate asupra profitabilitii;
Nu este nteleas necesitatea utilizrii metadatelor;
Utilizarea de metode i instrumente disparate.

11.2. Arhitectura depozitelor de date

Depozitul de date conine date care sunt extrase dintr-unul sau mai multe sisteme,
numite surse de date. Aceasta include o gam larg de sisteme incluznd baze de date
relaionale i baze de date orientate obiect, dar i baze de date prerelaionale i sisteme
motenite (figura 11.1).
Arhitectura unui depozit de date conine urmtoarele componente care nu sunt toate
obligatorii. Primele dou componente opereaz pe sursa de date.
- Componenta Filtru verific acurateea datelor naintea inserrii lor n depozit.
Filtrele pot elimina datele care sunt clar incorecte bazndu-se pe restriciile de
integritate i regulile privitoare la o singur surs de date. Ele pot, de asemenea,
scoate la iveal i inconsistena datelor extrase din surse multiple. n acest fel,
filtrul realizeaz tergerea datelor, lucru esenial pentru a asigura un nivel
satisfctor al calitii. Este important s parcurgem atent construcia depozitului,
verificnd calitatea datelor pe pri mici nainte de a realiza ntreaga ncrcare.
Capitolul 11
326
- Componenta Export este folosit pentru extragerea datelor din sursele de date.
Procesul de extragere este incrementat normal, componenta Export construiete
colecia tuturor modificrilor pe sursa de date, care sunt apoi importate de
depozitul de date.
- ncrctorul este responsabil pentru ncrcarea iniial a datelor n depozitul de
date. Aceast component pregtete datele pentru utilizarea operaional,
ocupndu-se att de ordonarea i agregarea operaiilor, ct i de construirea
structurilor de date n depozitul de date. n mod standardizat, operaiile de
ncrcare sunt realizate pe grupe, caz n care depozitele de date utilizeaz
paralelismul. Acest modul se ocup i cu fragmentarea iniial a datelor. n unele
aplicaii, caracterizate de o cantitate limitat de date, acest model este invocat
pentru ncrcarea ntregului coninut al depozitului de date dup fiecare schimbare
a surselor de date. Cel mai adesea, datele din depozitul de date sunt rennoite
automat de componenta Refresh care va fi discutat n continuare.
- Componenta Refresh nnoiete coninutul depozitului de date, propagnd automat
noutile aprute n sursele de date. Modificrile din sursele de date sunt realizate
cu ajutorul a dou tehnici: transportarea datelor i transportarea tranzaciilor.
- Prima tehnic utilizeaz triggeri pe sursa de date, care, invizibili pentru
aplicaii, nregistreaz tergerile, inserrile i modificrile n fiiere.
Modificrile sunt adesea tratate ca perechi de inserri i tergeri.
- A doua tehnic folosete consemnarea tranzaciilor pentru a construi fiierele
de modificri. n ambele cazuri, fiierele de modificri sunt transmise
depozitului de date i apoi folosite pentru a nnoi depozitele de date; vechile
valori sunt marcate de obicei ca date istorice, dar nu sunt terse.
- Componenta Acces la date este responsabil pentru ndeplinirea operaiilor de
analiza a datelor. n depozitele de date acest modul compune n mod eficient
ntrebri relaionale complexe, cu compuneri, ordonri i agregri complexe.
Compune de asemenea i operaii noi specifice dicionarelor de date, cum ar fi
mpachetri, despachetri i agregarea total a datelor. Acest modul este n strns
legtur cu sistemele client care ofer interfee prietenoase utilizatorilor,
compatibile pentru analize complexe ale datelor.
- Componenta Data mining permite executarea de explorri complexe ale
informaiilor ascunse n date, utiliznd tehnici i algoritmi specifici de data
mining.
- Componenta de Export al datelor e folosit pentru exportarea datelor prezente ntr-
un depozit spre alte depozite, crendu-se astfel o arhitectur ierarhic. n plus,
dicionarele de date sunt adesea dotate cu module care suport formatul i
organizarea lor:
- Un instrument CASE care poate suporta formatul depozitelor de date;
- Un dicionar de date descrie coninutul depozitelor de date este utilizat pentru
a nelege ce fel de analiz a datelor trebuie realizat.
Elementele prezentate legate de arhitectura depozitelor de date trebuie completate de
cteva consideraii privind calitatea datelor.
Calitatea datelor este un element esenial pentru succesul depozitelor de date. Dac
datele stocate conin erori, rezultatul analizei va produce rezultate eronate, i utilizarea
depozitelor de date ar putea fi la un moment dat contraproductiv. Calitatea redus a acestora
se poate datora unor factori dintre cei mai diveri, de la proaste obiceiuri, la lipsa de interes
pentru integrare cu alte zone ale organizaiei. Oricum este un proces care presupune un
consum foarte mare de timp i bani.

Depozite de date
327
Export
Data mining
Accesul la date
Refresh
ncrctor

Fig. 11.1 Arhitectura depozitului de date

Activitile care trebuie realizate n cadrul acestui proces sunt urmtoarele:
1) Analiza datelor de sus n jos (topdown) abordeaz aspectele referitoare la
integrarea i consistena datelor i presupune realizarea modelului logic al datelor
la nivelul organizaiei, relaiile ntre acestea i modalittile de integrare a
modulelor i surselor existente. Rezultatul acestei etape poate fi reprezentat
sintetic sub forma unui model entitate-asociere.
2) Analiza datelor de jos n sus (bottomup) abordeaz aspectele referitoare la
standardizare i calitate. Se definesc reguli de conversie a datelor, reguli de
integritate i reguli referitoare la domeniile de valori.
3) Curarea datelor presupune transformarea i filtrarea surselor de date.
Procesul de extragere, transformare i ncrcarea a datelor (Extract Transform and
Load ETL) este cel mai complicat proces al dezvoltrii unui depozit de date, necesitnd, de
obicei, timp ndelungat. Recomandarea specialitilor este de a se realiza integrarea tuturor
bazelor de date destinaie ntr-un singur mediu i construirea procesului ETL n cadrul
acestuia, i nu separat pe fiecare modul destinaie. Activitile care trebuie realizate n cadrul
acestui proces sunt urmtoarele:
1) Crearea specificaiilor de transformare (mapping) a surselor pe destinaiile
corespunztoare (cu ajutorul unor matrice sau diagrame de transformare);
2) Alegerea i testarea intrumentelor ETL utilizate;
3) Proiectarea procesului ETL presupune proiectarea a diveri operatori de extragere
i transformare (pentru sortri, agregri, joctiuni, divizri, etc);
4) Proiectarea programelor ETL care vor fi rulate adecvate etapelor de ncrcare:
i. ncrcarea iniial cu date operaionale curente;
Export n
Filtru n
Export 2
Filtru 2
Export 1
Filtru 1
Sursa de
date 1

Sursa de
date 2
Sursa de
date n
Capitolul 11
328
ii. ncrcarea cu date istorice cu date istorice arhivate;
iii. ncrcarea incremental cu date curente provenite din sistemele
operaionale.
5) Alegerea mediului n care va fi rulat procesul ETL, fie c este vorba despre un
server dedicat sau fie c procesul va fi divizat i va rula descentralizat.

Instrumentele ETL pot fi grupate astfel:
- Instrumente pentru conexiunea cu alte sisteme: acestea asigur accesul transparent
la sursele de date ce provin din medii eterogene. Exemple de astfel de sisteme
sunt: IBM DataJoiner, Oracle Transparent Gateway, Sybase Entreprise Connect.

- Instrumente de extragere: acestea asigur preluarea datelor n depozitul de date din
diversele surse de date. Alegerea si utilizarea acestor instrumente depind de o serie
de factori, printre care: baza de date i platforma sistemului surs; funcionalitile
de extragere i duplicare existente; intervalele de timp n care sistemele
operaionale sunt disponibile. Exist dou metode de baz pentru realizarea
extragerii datelor:
Extragerea n mas (bulk extraction), care presupune extragerea datelor
corespunzatoare ntregului depozit de date;
Replicarea, care presupune extragerea doar a acelor date care au fost
modificate de la ultima actualizare.
Adesea, instrumentele de extragere a datelor pun la dispoziie faciliti de curare a
datelor, dar exist posibilitatea s fie necesare extensii ale acestora, prin scrierea unor
proceduri de corecie sau pur i simplu corecia manual a datelor. Astfel de faciliti sunt:
completarea valorilor lips, corectarea erorilor de introducere a datelor, stabilirea unor
formate standard, nlocuirea sinonimelor cu identificatori standard. Datele recunoscute ca
fiind eronate i nu pot fi curate sunt respinse. Informaiile culese cu prilejul acestei operaii
pot fi folosite pentru mbuntirea calitii datelor n timp.

- Instrumente de transformare: acestea asigur maparea corect a datelor provenite
din diverse surse, dar care nu au aceeai structur sau acelai format. Principalele
funcii oferite sunt: partiionarea i consolidarea cmpurilor, standardizarea i
deduplicarea (tabelul 11.1).

Tabelul 11.1. Exemple de transformri ale datelor
Sistem surs Tipul transformrii Depozit de date
Cmpul Adresa
Str. Unirii Nr. 123, Municipiul
Arad, 6200, Romnia
Partiionare cmpuri
Nr. Str.: 123
Strada: Unirii
Localitate: Arad
Tip localitate: Municipiu
Cod Postal: 6200
ara: Romnia
Sistem A,
Funcie: Manager general

Sistem B,
Funcie: Director general
Consolidare cmpuri
Funcie: Manager sau
Director general
Depozite de date
329
Data comenzii: 12 Nov. 2007
Data comenzii: 19-09-07
Standardizare
Data comenzii:
12 Noiembrie 2007
Data comenzii:
19 Septembrie 2007
Sistem A,
Nume angajat: Ionescu I. Vasile
Sistem B,
Nume angajat: Ionescu Vasile
Deduplicare
Nume angajat: Ionescu I.
Vasile

- Instrumentele pentru asigurarea calitii datelor: acestea asist la localizarea i
corectarea erorilor fie n sistemele surs, fie n depozitul de date. De preferat este
ca acest lucru s se realizeze n cadrul sistemelor surs, lucru care de obicei este
mai dificil de realizat, deoarece modificrile n cadrul depozitului de date pot
conduce la apariia de inconsistene n momentul n care se realizeaz actualizarea
depozitului.
Statisticile arat c pn la 15% din datele extrase din diferite surse de date sunt
inconsistente sau incorecte, fapt care poate avea o influen puternic negativ asupra
rezultatelor analizelor realizate pe baza acestora. Exemple De astfel de sisteme sunt:Data
Quality Workbench (DataFlux); Content Tracker (Pine Cone Systems); Quality Manager
(Prism); Integrity Data Reengineering (Vality Technology).

- Instrumente pentru ncrcarea datelor: acestea ajut la ncrcarea datelor
transformate n depozitul de date. Aceste instrumente realizeaz preformatarea
datelor n formatul fizic intern cerut de SGBD-ul int i trebuie s asigure
integritatea i consistena datelor preluate din sistemele surs. Indecii pot ncetini
substanial procesul de ncrcare, motiv pentru care, de obicei, se renun la ei
nainte de ncrcare i apoi se recreeaz.

Instrumentele sunt de obicei ncorporate n cadrul unui singur instrument, cunoscut ca
ETL Tool, exemple de astfel de instrumente fiind: Data Junction, Ascential DataStage i
Informatica.

11.3. Obiectele depozitului de date

ntr-un depozit de date se ntlnesc mai multe tipuri de obiecte care prezint o
importan deosebit n analiz:
- Tabelele de fapte sunt tabelele centrale ale depozitului de date. Acestea conin
faptele i cheile externe ctre tabelele de dimensiuni. Faptele sunt, de obicei, date
numerice care pot fi totalizate i analizate pe diferite nivele.
- Dimensiunile sunt nite nite structuri compuse din una sau mai multe ierarhii
care structureaz datele. Tabelele secundare se numesc tabele dimensiuni, i sunt
mult mai mici dect tabelele de fapte. Fiecare tabel dimensiune are cte o cheie.
Cmpurile dintr-o tabel dimensiune sunt de obicei textuale i sunt folosite ca
surs pentru restricii i pentru rndurile din rapoarte. Datele sunt, de obicei,
colectate la nivelul cel mai de jos i mai detaliat i sunt agregate pe nivelele
superioare pentru analiz.
Capitolul 11
330
- Ierarhiile sunt structuri logice utilizate pentru ordonarea nivelelor de
reprezentare a datelor. Sunt utilizate i pentru definirea cilor de navigare n
interiorul datelor. Nivelele ierarhice sunt utilizate de instrumentele de analiz
OLAP, permind detalierea gradual a datelor.

Fig. 11.2. Ierarhii i nivele

- Nivelele reprezint poziii n cadrul ierarhiilor. De exemplu, dimensiunea Timp
poate avea trei nivele de ierarhizare: an, trimestru i luna. Nivelele se structureaz
n funcie de ierarhie de la general la specific, rdcina fiind reprezentat de
nivelul superior, cel mai general al ierarhiei. Relaiile ntre diferite nivele sunt
relaii de tipul printe-copil. Se pot defini ierarhii n care datele fiecrui nivel sunt
agregate la un nivel superior sau se pot sri anumite nivele care sunt independente
(figura 11.2).
- Atribute dimensiunile sunt concretizate prin intermediul atributelor care
reprezint calificative specifice. Orice atribut se asociaz unei singure dimensiuni,
iar o dimensiune se poate exprima prin mai multe atribute. Cu ct aceste atribute
sunt mai descriptive, cu att depozitele de date vor fi mai performante.
- Metrici (msuri) n analiza depozitelor de date se utilizeaz anumite variabile
sau metrici. Aceste corespund faptelor din tabelele de fapte i sunt de regul de
natur numeric. Exemple tipice ar fi: vnzri, costuri, stocuri. Aceste variabile au
sens numai n contextul unor anumite dimensiuni.

11.4. Structura depozitelor de date

Construcia unui dicionar de date, care descrie toate datele prezente n companie, este
un scop ambiios, adesea greu de obinut. Din acest motiv, construirea unui depozit de date
trebuie s se concentreze n mod separat pe subseturi de date ale companiei (cunoscute ca
date de departament), pentru care scopul de analiz este clar. Fiecare schem simplificat a
datelor de departament poart numele de Data Mart. Fiecare colecie de date este realizat n
conformitate cu o structur simpl, numit schem multidimensional, termen care implic
Familie de produse
Categorie
Subcategorie
Marc
Produs
Nivele ierarhice pentru
dimensiunea produs
Depozite de date
331
prezena unor multiple dimensiuni de analiz. Exist mai multe scheme de structurare a unui
depozit de date: schema stea, schema fulg de zpad i schema constelaie de fapte.

11.4.1 Schema stea

Schema stea este cel mai simplu model de structurare a unui depozit de date, model
ilustrat n figura de mai jos cu ajutorul modelului entitate-asociere. O entitate central
reprezint faptele pe care este focalizat analiza. Diferite entiti aranjate sub form de raze n
jurul acesteia reprezint dimensiunile analizei. Mai multe relaii unu la muli conecteaz
fiecare element din domeniul faptelor la exact un element al fiecrei dimensiuni. Schema din
figura de mai jos reprezint managementul unei reele de magazine. Entitatea din centrul
stelei reprezint vnzrile care sunt factori de interes; dimensiunile sunt reprezentate de
produsele vndute, magazinele, promoiile i momentul fiecrei vnzri (figura 11.3.)
Vanzare
Produs
Promotie
Timp
Supermarket (0,N)
(0,N)
(1,N)
(1,N)
(0,N)
(0,N) (1,N) (1,N)

Fig. 11.3. Colecia de date pentru un lan de supermarketuri

Plata
Polita
Problema
Timp
Client (0,N)
(0,N)
(1,N)
(1,N)
(0,N)
(0,N) (1,N) (1,N)

Fig. 11.4. Colecia de date pentru o companie de asigurri
Capitolul 11
332
Figura 11.4. reprezint organizarea plilor unei companii de asigurri. Entitatea din
centrul stelei reprezint plile ctre cei care trebuie onorai de ctre companie; dimensiunile
reprezint poliele de asigurare, clienii, timpul i tipul problemelor care au cauzat aceast
revendicare.
Schema din figura 11.5. reprezint organizarea terapiilor ntr-un grup de spitale.
Entitatea din centrul stelei reprezint terapiile; dimensiunile reprezint mbolnvirile,
pacienii, doctorii n cauz i spitalele n care sunt acceptai pacienii.
Aa cum este prezentat n cele trei colecii de date, principala caracteristic a schemei
stea este folosirea unei structuri regulate, independent de problema n cauz. Desigur,
numrul dimensiunilor poate fi diferit, dar cel puin dou dimensiuni sunt necesare (deoarece,
n caz contrar, modelul se descompune ntr-o simpl ierarhie unu la muli). Un numr ridicat
de dimensiuni este nerecomandat, deoarece analiza de date ar deveni prea complex.

Terapie
Pacient
Boala
Timp
Doctor (0,N)
(0,N)
(1,N)
(1,N)
(0,N)
(0,N) (1,N) (1,N)

Fig. 11.5. Colecia de date pentru un sistem de informaii medical

11.4.2. Schema stea pentru un lan de supermarket-uri

n cele ce urmeaz vor fi analizate coleciile de date pentru organizarea unui lan de
supermarket-uri, ilustrnd schema relaional corespunztoare schemei entitate-asociere.
Relaia unu la muli poate fi transformat prin atribuirea n entitatea central a unui
identificator compus dintr-un set de identificatori pentru fiecare dimensiune.
Fiecare tuplu al relaiei Vnzri are patru coduri: ProdCod, MarketCod, PromoCod,
TimpCod, care, luate mpreun, formeaz o cheie primar.
Astfel, o vnzare elementar poate fi descris ca un set al tuturor vnzrilor care sunt
realizate ntr-o perioad de timp, cu referire la un produs, o promoie dintr-un supermarket.
Fiecare eveniment de vnzare este astfel un articol de date agregate. Atributele noncheie sunt
cantitile vndute i valoarea veniturilor. Se presupune c fiecare vnzare este numai pentru
o promoie i se accept vnzrile produselor ce nu au promoie, considerndu-le ca avnd o
promoie nul.
Informaiile despre atributele celor patru domenii sunt urmtoarele:
Depozite de date
333
- Produsele sunt identificate de cod (ProdCod) i au ca atribute: Nume, Categorie,
Subcategorie, Marca, Greutate, nlocuitor.
- Supermarket-urile sunt identificate prin cod (MarketCod) i au ca atribute: Nume,
Ora, Regiune, Zon, Mrime, Aezarea supermarketului (de exemplu: la etajul 1
sau etajul 2, etc.).
- Promoiile sunt identificate prin cod (PromoCod) i au ca atribute: Nume, Tip,
discount procentual (Procentaj), CuponFlag (care indic prezena de cupoane n
ziare), DataStart, DataSfrit, Cost i Agenie de publicitate.
- Timpul este identificat prin cod (TimpCod) i are atribute ce descriu ziua vnzrii
din timpul sptmnii (ZiSpt: de duminica pn smbta), din timpul lunii
(ZiLuna: 1 la 31), i din an (ZiAn: 1-365), apoi sptmna din luna (SptLuna) i
din an (SptAn), apoi luna din an (LunaAn) i Anotimpul.
n general, dimensiunile prezint redundan i date derivate. De exemplu, n
dimensiunea Timp, cunoscnd o zi dintr-un an i un calendar se pot deriva valori ale tuturor
atributelor de timp relatate. Similar, dac un ora apare de mai multe ori n relaia
Supermarket, regiunile sale sunt repetate. Redundana este introdus pentru a facilita ct mai
mult posibil operaia de analiz de date i a o face ct mai eficient. Schema entitate-asociere
este transformat ntr-o schem logic relaional, rezultatul artnd dup cum urmeaz:

VNZRI(ProdCod, MarketCod, PromoCod, TimpCod, Cantitate, Venit)
PRODUS(ProdCod, Nume, Categorie, Subcategorie, Marca, Greutate, nlocuitor)
SUPERMARKET(MarketCod, Nume, Ora, Regiune, Zona, Mrime, Aezare)
PROMOIE(PromoCod, Nume, Tip, Procentaj, CuponFlag, DataStart, DataSfrit,
Cost, Agenie)
TIMP(TimpCod, ZiSpt, ZiLun,ZiAn, SptLun, SptAn, LunAn, Anotimp).

De fapt, relaia este n form normal Boyce-Codd prin care fiecare atribut care nu este
cheie depinde funcional de cheia relaiei. Pe de alt parte, n general dimensiunile sunt relaii
nenormalizate. n final, sunt patru restricii de integritate ntre fiecare atribut care alctuiete
cheia tabelei de fapte i tabelele dimensiune. Fiecare dintre cele patru coduri care alctuiesc
cheia tabelei de fapte este o cheie extern, referindu-se la tabela dimensiune care o are ca
cheie primar.

11.4.3. Schema fulg de zpad

Schema fulg de zpad este o dezvoltare a schemei stea, n care domeniile sunt
structurate ierarhic. Schema este introdus pentru a lua n calcul prezena unor dimensiuni
nenormalizate. Figura 11.6. ilustreaz colecia de date pentru organizarea supermarketurilor,
reprezentat prin schema fulg de zpad. n timp ce dimensiunea promoiilor e neschimbata,
celelalte dimensiuni sunt organizate ierarhic. Schema fulg de zpad prezint ierarhizri
explicite, acestea reducnd redundana i anomaliile, dar fiind mult mai complex.
- Dimensiunea Supermarket este structurat dup ierarhie: Zon, Regiune, Ora,
Supermarket. Fiecare Zon include multe Regiuni, fiecare Regiune include multe
Orae i fiecare Ora are unul sau mai multe Supermarket-uri.
- Dimensiunea Produs este reprezentat de o ierarhie cu dou noi entiti: nlocuitor
i Categoria Produsului.
- Dimensiunea Timp e structurat dup ierarhia Zi, Lun, An.
Capitolul 11
334
Atributele schemei stea sunt distribuite unor entiti variate ale schemei fulg de
zpad, eliminnd sursele de redundant. Toate relaiile descrise n figura anterioar sunt unu
la muli i fiecare element este conectat la unul i doar un element al nivelului urmtor.
Principalul avantaj a schemei stea este simplitatea ei, care permite crearea unei
interfee foarte simple pentru formularea interogrilor.

Vanzare
Produs
Promotie
Zi
Supermarket (0,N)
(0,N)
(1,N)
(1,N)
(0,N)
(0,N) (1,N) (1,N)
Inlocuitor (0,N) (1,N) Categorie (0,N) (1,N)
Oras
Regiune
Zona
(1,1)
(0,N)
(1,1)
(0,N)
(1,1)
(0,N)
Luna
An
(1,1) (0,N)
(1,1)
(0,N)

Fig. 11.6 Schema fulg de zpad pentru un lan de supermarketuri

11.4.4. Schema constelaie de fapte

Aplicaiile sofisticate pot solicita tabele multiple de fapte care partajeaz tabele
dimensiune. O alt variant a schemei stea este schema constelaie de fapte (sau multistea),
care const n mai multe tabele de fapte, conectate de obicei la una sau mai multe dimensiuni.
Acest gen de schem poate fi vzut ca o colecie de stele.
Pentru depozitele de date, schema constelaie de fapte este n mod curent utilizat, un
depozit de date colectnd date despre subiecte multiple care se refer la ntreaga organizaie.
Un exemplu de astfel de schem poate fi obinut dac la schema stea iniial pentru reeaua de
supermarket-uri se adaug pe lng tabela de fapte iniial, cea de Vnzri, o tabel
Depozite de date
335
suplimentar de fapte pentru Aprovizionri, care se leag la rndul ei de dimensiunile
Supermarket, Produs i Timp.

Vanzare
Produs
Promotie
Timp
Supermarket (0,N)
(0,N)
(1,N)
(1,N)
(0,N)
(0,N) (1,N) (1,N)
Aprovizionare
(0,N) (1,N)
(1,N)
(0,N)
(1,N)
(0,N)

Fig. 11.7 Schema constelaie de fapte pentru un lan de supermarketuri

11.5. Operaii pentru analiza datelor

n acest paragraf vor fi prezentate interfeele pentru formularea interogrilor i cteva
operaii utilizate pentru creterea puterii de exprimarea limbajelor de interogare.

11.5.1. Interfee de formulare a interogrilor

Analiza datelor pentru o colecie de date organizate conform schemei stea, necesit
mai nti extragerea unui subset de factori i dimensiuni bazate pe solicitrile unei activiti
specifice de analiz a datelor. Aceste extrageri de date urmresc un model standard:
dimensiunile sunt utilizate pentru a selecta datele i a le grupa, n timp ce funciile agregate
sunt, de obicei, aplicate faptelor. E posibil astfel realizarea unor module predefinite pentru
consultarea depozitului de date n care sunt oferite opiuni predefinite pentru selecie, agregare
i evaluare a funciilor agregate. Figura 11.8 prezint o interfa de consultare a datelor pentru
Data Mart-ul din seciunea 11.4.2. n ceea ce privete dimensiunile, acestea sunt preselectate:
numele promoiei, numele produsului, numele vnzrii. Pentru fiecare element, sunt selectate
cantitile pentru vnzri. Valoarea Superpromoie este inserat n partea de jos a acestui
modul. Superpromoie identific o promoie particular, indicnd astfel procentul din
valoarea vnzrilor obinut prin aceasta.
n mod similar, sunt selectate Paste i Ulei ( pentru produse) pentru intervalul de
valori Februarie -Aprilie.
n ultimul rnd al interfeei de extragere a datelor se definete structura rezultatelor
care ar trebui s includ dimensiunile Produs (incluznd valorile selectate Paste i Ulei) i
Timp (ntre Februarie i Aprilie) i cantitatea total de vnzri.
Capitolul 11
336

Promoie.Nume Produs.Nume Timp.LunaAn Cantitate
Trei pt. Dou
Cupon 15%
Superpromoie
Vin
Paste
Ulei
IanuarieDecembrie

Superpromoie PasteUlei Februarie...Aprilie
Produs.Nume Timp.Luna Sum

Fig. 11.8. Interfaa pentru formularea unei interogri OLAP

Interfaa corespunde unei interogri SQL cu o structur predefinit, care, este
completat cu opiunile introduse de utilizator. n interogare apar clauze join, care conecteaz
tabela de fapte cu dimensiunile), clauze de selecie (care extrag date relevante), grupri,
ordonri, clauze de agregare.

select D1,C1DnCn, Aggr1 (F.C1), Aggrn(FCn)
from Fact as F, dimension1 as D1,dimensionn as Dn
where conditie-join (F,D1)
and
and conditie-join (F,Dn) and conditie-selectie
group by D1.C1,Dn.Cn
order by D1.C1,Dn.Cn

n cazul specificat, interogarea construit conform cu opiunile utilizatorului arat
dup cum urmeaz:

Select Timp.Luna, Produs.Nume, sum(Cantitate)
From Vnzare, Timp, Produs
Where Vnzare. TimpCod=Timp. TimpCod And Vnzare. ProdusCod =Produs. ProdusCod
And Vnzare. PromoieCod=Promoie. PromoieCod
And (Produs.Nume=Paste Or Produs.Nume=Ulei)
And Timp.LunaAn between Februarieand Aprilie
And Promoie.Nume=Superpromoie Group By Timp.LunaAn, Produs.Nume
Order By Timp.LunaAn, Produs.Nume

Rezultatul interogrii poate fi prezentat de clientul OLAP n forma de matrice sau
grafic. n formatul matrice, dimensiunile corespund rndurilor i coloanelor, iar faptele
corespund celulelor, ca n figura 11.9.
Aceast reprezentare a datelor este destul de des utilizat de uneltele de analiz
deoarece permite operaii de calcul tabelar asupra rezultatelor interogrilor. Graficele clasice
cu bare i cele tip plcint pot fi utilizate pentru vizualizarea datelor; de exemplu graficele
cu bare pot utiliza diferite culori pentru a reprezenta diferite tipuri de produse la diferite
momente de timp.

Feb Mar Apr
Ulei
Paste
5K
45K
5K
50K
7K
51K

Fig. 11.9. Rezultatul interogrii OLAP

Schema
Optiuni
Conditie
View
Depozite de date
337
11.5.2. Drill-down i roll-up

Analogia cu programele de calcul tabelar nu este limitat la prezentarea datelor. De
fapt, exist dou operaii de manipulare primitiv a datelor care deriv din dou operaii tipice
cu tabele: drill-up i drill-down (figura 11.10.)

Timp.LunaAn Produs.Nume Sum(Cant)
Feb
Mar
Apr
Paste
Paste
Paste
45K
50K
51K

Fig. 11.10. Subseturi de rezultate ale interogrii OLAP

Drill-down permite introducerea unei dimensiuni a analizei, realiznd astfel o
dezagregare a datelor. De exemplu, un utilizator ar putea fi interesat de adugarea distribuiei
cantitii vndute pe zone de vnzare, realiznd operaia drill-down pe Zon. Presupunnd c
atributul Zona ia valoarea Nord, Centru i Sud, obinem tabelul din figura 11.11.

Timp.LunaAn Produs.Nume Zona Sum(Cant)
Feb
Feb
Feb
Mar
Mar
Mar
Apr
Apr
Apr
Paste
Paste
Paste
Paste
Paste
Paste
Paste
Paste
Paste
Nord
Centru
Sud
Nord
Centru
Sud
Nord
Centru
Sud
18K
15K
12K
18K
18K
14K
18K
17K
16K

Fig. 11.11. Drill-down pentru tabelele reprezentate n figura 11.10.

Roll-up permite n schimb eliminarea unei dimensiuni de analiz, reagregnd datele.
De exemplu, un utilizator poate s decid c subdivizarea vnzrilor pe zone e mai folositoare
dect cea pe luni. Acest rezultat e obinut realiznd o operaie de roll-up pe luni, obinndu-se
rezultatul afiat n figura 11.12.
Alternnd operaiile roll-up i drill-down, analistul poate evidenia dimensiunile care
au influen mai mare asupra fenomenelor reprezentate de fapte. De notat c operaia roll-up
se realizeaz opernd pe rezultatul interogrii, n timp ce operaia drill-down necesit n
general o reformulare i o reevaluare a interogrii pentru c necesit adugarea unei noi
coloane n rezultatul interogrii.

Produs.Nume Zona Sum(cant)
Paste
Paste
Paste
Nord
Centru
Sud
54K
50K
42K

Fig. 11.12. Eliminarea tabelelor prezentate n figura 11.11.
Capitolul 11
338
11.5.3. Seciuni i rotaii

Asupra cuburilor de date trebuie s se poat predefini viziuni sau imagini (views)
specifice diverselor categorii de utilizatori, prin operaii de secionare. O seciune (slice)
reprezint un membru specific al unei dimensiuni, de ex. Produsul A din dimensiunea Produs.
Secionarea conduce la crearea unei serii de intersecii cu alte dimensiuni pentru seciunea
respectiv. De exemplu, dup lun, dup regiune, dup client. Acest dup ne indic cum
putem realiza vizualizarea datelor prin limitarea unor atribute la anumite valori i obinerea
unui cub de date redus (procedeu numit data dicing). Aceasta intersecie multidimensional i
modul ei de organizare face modelul OLAP foarte puternic. Abilitatea de a schimba
perspectivele asupra datelor intuitiv i instantaneu este o facilitate de baz a tuturor
instrumentelor serioase pentru OLAP.
Alte dou faciliti importante n proiectarea multidimensional OLAP sunt pivotarea
i imbricarea dimensiunilor. Pivotarea presupune schimbarea intre ele a dimensiunilor in
cadrul unei vizualizari, reorientarea cubului de date, de obicei trecerea de pe linii pe coloane
si invers. Imbricarea presupune detalierea dimensiunii imbricate pentru fiecare valoare a
dimensiunii care o conine.

11.5.4. Data cube

Utilizarea recurent a agregrilor a sugerat introducerea unui operator foarte puternic,
cunoscut ca DATA CUBE, pentru a realiza toate agregrile posibile prezente ntr-o tabel
extras pentru analiz. Pentru descrierea operatorului se va folosi un exemplu. Se presupune
c depozitul de date conine urmtoarea tabel care descrie vnzrile de maini. Vor fi afiate
tuplurile unice referitoare la maini Ferrari sau Porsche roii, vndute ntre 2006 i 2007
(figura 11.13).

Productor An Culoare Vnzri
Ferrari
Ferrari
Porsche
2006
2007
2006
Rou
Rou
Rou
50
85
80

Fig. 11.13. Imaginea unei tabele de vnzri

DATA CUBE este construit prin adugarea clauzei cu WITH CUBE la o interogare ce
conine o clauz GROUP BY. De exemplu, se consider urmtoarea interogare:

select Productor,An,Culoare,Sum(Vnzri)
from Vnzri
where (Productor=Ferrari or Productor =Porsche)
and Culoare= Rou and An between 2006 and 2007
group by Productor, An, Culoare with cube

Interogarea extrage toate agregrile construite prin gruparea intr-un mod combinat a
tuplurilor conform cu cele trei dimensiuni ale analizei (Productor, An, Culoare). Agregarea
este reprezentat de valoarea polimorfic ALL care (ca i NULL) e prezent n toate
domeniile i corespunde tuturor valorilor posibile prezente n domeniu ( figura 11.14).
Depozite de date
339
O reprezentare spaial a structurii DATA CUBE este evideniat n figura 11.14.
Diagrama arata un spaiu cartezian construit pe trei axe corespunznd domeniilor celor trei
atribute. n acest exemplu, domeniul Productor ia valorile Ferrari i Porsche, domeniul An ia
valorile 2006 i 2007, iar domeniul Culoare ia valoarea Rou. Punctele n spaiu reprezint
tupluri n figura 11.12. De notat ca nu toate punctele sunt prezente n depozitul de date. n
exemplul considerat, trei din patru sunt prezente. Cele trei planuri carteziene reprezint
agregarea unei dimensiuni, axele carteziene reprezint agregrile pentru dou dimensiuni i
originea axelor carteziene reprezint agregarea pentru toate cele trei dimensiuni.
Evident, o reprezentare cartezian similar din punct de vedere conceptual, ntr-un
spaiu cu n dimensiuni este posibil n cazul unei operaii de DATA CUBE cu un numr
arbitrar de atribute de grupare.

Productor An Culoare Suma(Vnzri)
Ferrari
Ferrari
Ferrari
Ferrari
Ferrari
Ferrari
Porsche
Porsche
Porsche
Porsche
All
All
All
All
All
All
2006
2007
2006
2007
All
All
2006
2006
All
All
2006
2007
All
2006
2007
All
Rosu
Rou
All
All
Rou
All
Rou
All
Rou
All
Rou
Rou
Rou
All
All
All
50
85
50
85
135
135
80
80
80
80
130
85
215
130
85
215

Fig. 11.14. Operaia data CUBE a tabelei reprezentate n figura 11.13

Complexitatea DATA CUBE crete exponenial cu creterea numrului de atribute
care sunt grupate. O extensie diferit de SQL construiete agregri progresive n loc s
construiasc toate agregrile posibile; astfel complexitatea evalurii acestei operaii crete
doar ntr-un mod liniar cu creterea numrului de atribute grupate. Aceast extensie necesit
nlocuirea clauzei WITH CUBE cu clauza WITH ROLL-UP, ilustrat n urmtorul exemplu:

select Productor, An, Culoare, Sum(Vnzri)
from Vnzri
where (Productor=Ferrari or Productor= Porsche)
and Culoare =Rou
and An between 2006 and 2007
group By Productor, An, Culoare with roll-up

Rezultatul evalurii acestei interogri este evideniat n Figura 11.15. Se observ
progresul agregrilor, de la stnga la dreapta, i faptul c rezultatul are mai puine tupluri
dect rezultatul operaiei DATA CUBE.

Capitolul 11
340
Productor An Culoare Sum(Vnzri)
Ferrari
Ferrari
Porsche
Ferarri
Ferrari
Porsche
Ferrari
Porsche
All
2006
2007
2006
2006
2007
2006
All
All
All
Rou
Rou
Rou
All
All
All
All
All
All
50
85
80
50
85
80
135
80
215

Fig. 11.15. Roll-up realizat asupra tabelei reprezentate n figura 11.13

Interogrile cu WITH CUBE i WITH ROLL-UP sunt prezente n multe SGBD-uri
relaionale i nu necesit n mod obligatoriu prezena unui depozit de date. n orice caz, o
interpretare a celor dou interogri conform modelului stea este ntotdeauna posibil,
deoarece atributele clauzei GROUP BY joac rolul domeniilor, n timp ce atributele rmase
ale clauzei SELECT descriu operaiile de agregare aplicate faptelor.

11.6. Dezvoltarea depozitului de date

Exist patru abordri alternative cu privire la dezvoltarea depozitului de date:
- Prima abordare const n utilizarea tehnologiei relaionale, adaptat i extins
corespunztor. Datele sunt stocate utiliznd tabele, dar operaiile de analiz sunt
realizate n mod eficient utiliznd structuri speciale de date. Acest tip de sistem
este numit ROLAP (Relational OnLine Analytic Processing). n ROLAP toate
agregrile sunt stocate n cadrul bazelor de date relaionale surs. ROLAP
reprezint cea mai lent soluie pentru consultarea datelor, deoarece, indiferent
dac exist sau nu o agregare, trebuie accesat direct depozitul de date. Aceast
soluie este recomandat doar pentru implementri de dimensiuni mai mici.

- A doua abordare, mai radical, const n stocarea datelor n form
multidimensional, folosind structuri de date vector. Acest tip de sistem este numit
MOLAP (Multidimensional OnLine Analytic Processing). n MOLAP, att datele
surs ct i agregrile sunt stocate n format multidimensional. MOLAP este
opiunea cea mai rapid pentru consultarea datelor, dar necesit cel mai mult spaiu
de disc (acest criteriu nu mai reprezint o prioritate n ultima vreme, avnd n
vedere scderea costurilor de stocare i procesare).

- HOLAP (Hybrid OnLine Analytic Processing) este o combinaie a primelor dou
modele. Bazele de date HOLAP stocheaz agregrile existente ntr-o structur
multidimensional, lsnd nivelul celulelor de baz n form relaional. Deoarece
datele sunt n form preagregat, HOLAP ofer performanele MOLAP atunci
cnd este nevoie de preluarea datelor din tabele.
- DOLAP (Desktop OnLine Analytic Processing) presupune stocarea datelor pe
maini desktop individuale, fiind ntlnite in aplicaii de dimensiune redus, n
care exist solicitri minime ca mai muli utilizatori s aib acces la o baz de date
Depozite de date
341
central aflat pe un server central. DOLAP este inclus n soluiile oferite de
muli dintre furnizori pentru a facilita analiza n cazurile n care utilizatorii nu se
pot conecta la reeaua companiei.

Soluia MOLAP este adoptat de un numr mare de produse specializate n
managementul Data Mart-urilor, datorit restriciilor legate de hardware i de costul
procesrii. HOLAP ofer performane mai bune n cazul n care se acceseaz o baz de date
stand-alone. Soluia ROLAP este utilizat de un numr mare de productori de soluii
relaionale. Aceasta aduga soluii specifice OLAP experienei tehnologice a SGBD-urilor
relaionale i astfel este foarte probabil ca ROLAP s reziste pe termen mediu i lung.
Soluiile ROLAP sunt preferate cnd cererile de interogare sunt relative reduse i se acceseaz
o baza de date stand-alone. n orice caz, tehnologiile ROLAP i MOLAP utilizeaz soluii
inovative pentru acces la date i cu privire la indeci i materializarea view-urilor.
Aceste soluii iau n considerare faptul c depozitul de date este folosit n principal
pentru operaii de citire i ncrcare iniial sau progresiv a datelor, n timp ce modificrile i
anulrile sunt rare. Depozitele de date mari utilizeaz paralelismul, cu fragmentarea i
alocarea corespunztoare a datelor pentru a face interogrile mai eficiente. n cele ce urmeaz
se vorbete doar despre tehnologiile ROLAP.

11.6.1. Indeci de bitmap i indeci de join

Indecii de bitmap permit crearea eficient a conjunciilor i disjunciilor n condiii de
selecie sau a operaiilor algebrice de reuniune i intersecie. Acestea sunt bazate pe ideea de
a reprezenta fiecare tuplu ca un element al unui vector de bii. Lungimea vectorului este egal
cu cardinalitatea tabelului. n timp ce nodurile rdcin i nodurile intemerdiare ale indecilor
harii de bii rmn neschimbai, frunzele indecilor conin cte un vector pentru fiecare
valoare a indexului. Biii din vectori sunt setai pe valoarea 1 pentru tuplurile care au acea
valoare i 0 altfel.
Se presupune, de exemplu, realizarea unui index de bitmap pe atributele Nume i
Agenie ale tabelei Promoie descrise n seciunea 11.4.2. Pentru a identifica tuplul
corespunztor Nume=Superpromoie i Agenie=Promoplus este nevoie doar de
accesarea separat a celor doi vectori corespunztori constantelor Superpromoie i
Promoplus folosind indeci, extragerea i folosirea lor bit cu bit. Vectorul rezultat va
conine 1 pentru tuplurile care satisfac condiia, care sunt astfel identificate. Operaiile
similare pe bit permit managementul disjunciilor (figura 11.17.)
Operaiile pe bii sunt foarte rapide, dar, evident, un index bitmap este greu de
administrat n cazul n care tabela este supus modificrilor. Este convenabil ca acesta s fie
construit n timpul operaiilor de ncrcare a datelor pentru o cardinalitate dat a tabelei.

Indecii join permit execuia eficient a reuniunii dintre tabelele dimensiune i
tabelele de fapte. Ei extrag acele fapte care satisfac condiiile impuse de dimensiuni. Indecii
join sunt construii pe dimensiune cheie, frunzele lor n loc s lege tuplurile dimensiunilor,
leag tuplurile tabelei de fapte care conin acele valori cheie. Referindu-ne din nou la Data
Mart-urile din seciunea 11.4.2, un index join asupra atributului PromoCod va conine n
frunzele sale referine la tuplurile de fapte corespunztoare fiecrei promoii. De asemenea,
este posibil s construim indeci de join pe seturi de chei ale diferitor dimensiuni, de exemplu:
PromoCod i ProdCod.
Ca de obicei, n cadrul proiectrii fizice, utilizarea indecilor de bitmap i de join este
legat de beneficiul cu privire la costul analizei. Costurile sunt eseniale n ceea ce privete
Capitolul 11
342
necesitatea construirii i stocrii indecilor n mod permanent i beneficiile sunt legate de
utilizarea actual de ctre sistemul depozitului de date pentru rezolvarea interogrilor.

Prom Nume Agentie
Nr
inreg
Trei
pt.
Dou

Cupon
15%

Super-
promoie

Nr
inreg
Promo-
plus
Cupon-
promo
P1
Trei pt.
Dou

Promo-
plus
1 1 0 0 1 1 0
P2
Cupon
15%

Cupon-
promo
2 0 1 0 2 0 1
P3
Super-
promoie
Promo-
plus
3 0 0 1 3 1 0
P4
Trei pt.
Dou

Promo-
plus
4 1 0 0 4 1 0
P5
Cupon
15%

Cupon-
promo
5 0 1 0 5 0 1

Fig. 11.17. Utilizarea indecilor de bitmap

11.6.2. Materializarea view-lor

Multe interogri ale depozitului de date necesit repetate agregri i sinteze laborioase.
n acest caz, este convenabil evaluarea view-lor care exprim date agregate i stocarea lor
permanent. Aceast tehnic este numit materializarea view-lor. De exemplu, n colecia de
date cu privire la organizarea supermarketurilor, un view materializat poate conine datele
vnzrilor agregate pe produs, sau vnzrile lunare pe fiecare magazin. Interogrile despre
aceste agregri sunt realizate n mod direct n materializarea view-lor, n loc s fie realizate n
depozitul de date. Alegerea view-lor materializate este o problem destul de complex, care
necesit cunoaterea interogrilor realizate n mod curent ntr-un Data Mart i frecvena lor de
execuie.
n general, un view materializat este convenabil atunci cnd poate s reduc n mod
sensibil timpul de execuie al unor interogri utilizate frecvent. Materializarea este foarte
convenabil ntr-un mediu ca depozitul de date, n care tabelele de baz nu sunt modificate n
mod continuu. Cnd tabelele sunt modificate n mod corespunztor sau rencrcate, view-le
trebuie oricum actualizate, propagnd efectele modificrilor asupra tabelelor de baz.

Data Mining
343

Capitolul 12
Data Mining

12.1. Introducere n data mining

Termenul de data mining este folosit pentru a caracteriza tehnicile de cutare
utilizate pentru informaiile ascunse n datele dintr-un depozit de date. Data mining este
folosit pentru studii de pia, de exemplu identificarea articolelor cumprate mpreun sau
consecutiv, aceasta pentru a optimiza amplasarea de bunuri pe rafturile unui magazin sau
trimiterea selectiv de materiale cu caracter promoional. Alte aplicaii frecvent ntlnite sunt
analiza comportamental (de exemplu, cutarea de fraude i folosiri ilegale ale cardurilor de
credit) i realizarea de previziuni bazate pe serii istorice (de exemplu, cele referitoare la
tratamente medicale). Data mining are caracter interdisciplinar folosind nu numai tehnologia
de organizare a datelor, dar i statistica (pentru definirea calitii sau observrii) i inteligena
artificial (n procesul de descoperire a cunotinelor generale din date).
Modelele identificate cu astfel de metode pot oferi unui analist de date, puncte de
vedere neateptate i folositoare care pot fi investigate ulterior mai atent, poate utiliznd
eventual instrumente suport de decizie. n acest capitol, vor fi discutate cteva aplicaii de
data mining pentru fiecare din acestea existnd unelte comerciale disponibile de la marii
productori. Importana acestui domeniu crete tot mai mult odat cu trecerea timpului odat
cu dezvoltarea i rspndirea instrumentelor de data mining. n ultima vreme, data mining a
cucerit o popularitate crescnd i a condus la obinerea unui avantaj competitiv pentru multe
firme.
Cea mai important caracteristic ce difereniaz data mining de subdomenii ale
statisticii sau inteligenei artificiale este aceea c volumul de date este foarte mare; dei idei
din aceste subdomenii sunt aplicabile la problemele din data mining, scalabilitatea n raport cu
dimensiunea datelor este un criteriu important n plus.
Un algoritm este scalabil dac timpul de rulare crete (liniar) n proporie cu mrimea
setului de date, depinznd de resursele disponibile ale sistemului (de exemplu, cantitatea de
memorie principal i de hard disk disponibil). Vechii algoritmi trebuie adaptai sau trebuie
dezvoltai noi algoritmi pentru a asigura scalabilitatea .
Gsirea de trenduri utile n seturile de date este o definiie mai larg a data mining.
ntr-un sens se poate crede c interogrile din bazele de date fac deja acest lucru. ntr-adevr,
avem o analiz continu i instrumente de explorare cu interogri SQL pe de o parte, OLAP n
mijloc, i tehnicile de data mining pe de alt parte.
Interogrile SQL sunt construite folosind algebra relaional (cu unele extensii).
OLAP permite interogri de un nivel mai nalt bazate pe modele de date multidimensionale,
iar data mining ofer operaiile de analiz cele mai abstracte. Ne putem gndi la diferite
sarcini n data mining ca la interogri complexe, specificate la nivel nalt, cu civa parametri
care se pot defini de utilizatori i pentru care sunt implementai algoritmi specializai.
Capitolul 12
344
n lumea real, data mining este mult mai mult dect simpla aplicare a unuia din aceti
algoritmi. Datele sunt deseori incomplete sau cu zgomot i dac acest lucru nu este neles i
corectat, este foarte posibil ca multe modele s fie ratate, iar modelele detectate s nu fie
relevante. n continuare, analistul trebuie va decide la ce fel de algoritmi va apela, i i va
aplica unui subset de modele de date i variabile bine ales, va analiza rezultatele i va aplica
alte instrumente suport de decizie i de exploatare, ntregul proces repetndu-se..

Procesul de data mining

Obiectivul data mining este extragerea informaiei utile din seturi mari de date. Acest
lucru este realizat n mod iterativ, prin adaptri succesive, realizndu-se o extragere
progresiv a cunotinelor (Knowledge Data Discovery process - KDD), care este divizat n
patru faze:
- Explorarea domeniului: extragerea de informaii utile este imposibil dac nu se
realizeaz o bun nelegere a domeniului de aplicaii n care se lucreaz.
- Pregtirea setului de date: acest pas necesit identificarea unui subset de date ale
depozitului de date pentru care se va realiza data mining. Este de asemenea
necesar o codificare a datelor pentru a le transforma n intrri corespunztoare
pentru algoritmul de data mining.
- Descoperirea de modele: aceasta const n aplicarea tehnicii de mining pe setul de
date extras mai devreme pentru a descoperi modele repetitive n date.
- Evaluarea modelelor: aceasta const n obinerea concluziilor n urma descoperirii
modelelor, evalund ce experimente vor trebui analizate i ce ipoteze vor trebui
formulate i ce consecine rezult n procesul de descoperire a cunotinelor.
Rezultatul oricrui pas n procesul KDD poate conduce la un pas anterior pentru a
reface procesul folosind noile cunotine ctigate.

12.1.2. Probleme de data mining

Chiar dac fiecare aplicaie are trsturi specifice, exist probleme generale care au o
structur repetitiv regulat. Aceste probleme pot fi formalizate i apoi rezolvate de o gam de
algoritmi de data mining. De obicei, algoritmii de data mining sunt caracterizai de o bun
scalabilitate, ceea ce garanteaz caracteristici de eficien ridicate cnd sunt aplicate pe seturi
mari de date. Vor fi luate n considerare trei probleme clasice:
1. Descoperirea de reguli de asociere.
Regulile de asociere descoper modele regulate n seturi de date mari. Exemplu clasic,
numit analiza coului de cumprturi, reprezint cutarea de bunuri care sunt adesea
achiziionate mpreun. Tabelul urmtor descrie tranzaciile desfurate ntr-un mare magazin,
fiecare tuplu reprezentnd achiziionarea unui anumit produs. Codul tranzaciei este prezent n
toate tuplurile i este folosit pentru a grupa toate tuplurile ce formeaz o achiziie. Regulile
descoper situaii n care prezena unui articol ntr-o tranzacie este legat de prezena altui
articol cu o probabilitate ridicat (figura 12.1.).
Mai concret, o regul de asociere const dintr-o premis i o consecin. Ambele, att
premisa ct i consecina, pot fi un singur articol sau grupuri de articole. De exemplu, regula
schiuri-clpari indic faptul c achiziionarea schiurilor (premisa) este adesea nsoit de
achiziia de clpari (consecin). O regul cunoscut despre vnzrile din supermarket, care
nu este evident la prima vedere, indic existena unei legturi ntre scutece i bere, datorit
faptului c scutecele sunt cumprate de cele mai multe ori de tai (cumprtura fiind simpl i
voluminoas), muli tai fiind atrai i de bere. Simpla mutare a berii lng raionul de scutece
Data Mining
345
a condus la o sporire a profitului. Calitatea regulilor de asociere poate fi exact msurat.
Presupunnd c un grup de tupluri constituie o observaie, putem spune c observaia satisface
premisa unei reguli dac ea conine cel puin un tuplu pentru fiecare articol. Pot fi definite
proprietile de suport i ncredere.

Tranzacie Data Bunuri Cantitate Pre
1
1
2
2
2
3
4
4
17/12/98
17/12/98
18/12/98
18/12/98
18/12/98
18/12/98
19/12/98
19/12/98
Pantaloni-schi
Ghete
Tricou
Geac
Ghete
Geac
Geac
Tricou
1
1
1
1
1
1
1
2
140
130
25
260
70
300
300
325
Fig. 12.1. Baza de date pentru analiza coului de cumprturi

Suportul reprezint acea parte a observaiilor care satisfac att premisa, ct i
consecina regulii.
ncrederea reprezint o parte a observaiilor care satisfac consecina dintre acele
observaii care satisfac premisa.
Intuitiv, suportul msoar importana unei reguli (ct de des premisa i consecina sunt
prezente), n timp ce ncrederea msoar sigurana (dat fiind premisa, ct de des este
prezent consecina).
Problema data mining referitoare la descoperirea regulilor de asociere poate fi enunat
asfel: s se gseasc toate regulile de asociere cu suportul mai mare dect o anumit valoare.
De exemplu, figura 12.2 prezint reguli de asociere cu suport i ncredere ridicate, mai mari
sau egale cu 0.25. Dac, pe de alt parte, intereseaz numai de regulile care au suportul i
ncrederea mai mari de 0.4, trebuie extras regula geac-tricou i tricou-geac.
Exist variante ale acestei probleme, obinute folosind diferite extrageri de date, dar
cu aproximativ acelai algoritm. De exemplu, gsirea produselor vndute mpreun i n
aceeai promoie sau produse vndute mpreun doar dac au fost aranjate mpreun.
Alte variante ale aceleiai probleme, ce necesit un algoritm diferit, permit studiul unor serii
dependente de timp referitoare la vnzri, de exemplu, marfa vndut consecutiv aceluiai
client. De obicei, sunt folosite pentru organizarea de campanii promoionale sau expedierea de
materiale publicitare.

Premisa Consecina Suport ncredere
Pantaloni-schi
Ghete
Tricou
Tricou
Ghete
Ghete
Geac
Geac
{Tricou-Ghete}
{Tricou-Geac}
{Ghete-Geac}
Ghete
Pantaloni-schi
Ghete
Geac
Tricou
Ghete
Geac
Ghete
Geac
Ghete
Tricou
0.25
0.25
0.25
0.5
0.25
0.25
0.5
0.25
0.25
0.25
0.25
1
0.5
0.5
1
0.5
0.5
0.66
0.33
1
0.5
1

Fig. 12.2 Regulile de asociere pentru o baz de date de analiz a coului de cumprturi
Capitolul 12
346
Regulile de asociere i cutarea de modele, permit i studiul altor probleme dincolo de
analiza coului de cumprturi. De exemplu, n medicin se poate evidenia ce rezisten la
antibiotice este simultan prezent ntr-o antibiogram, sau dac diabeticii vor suferi o
deteriorare a vederii n termen de zece ani dup descoperirea bolii.

2. Discreditarea. Este o etap tipic n pregtirea datelor care permite reprezentarea
unui interval continuu de valori folosind cteva valori discrete, pentru a face
fenomenul mai uor de vizualizat. De exemplu, valorile tensiunii arteriale pot fi
descrise simplu de trei clase: ridicat, medie i joas i aceast operaie
poate permite cu succes corelarea unei valori a presiunii sngelui cu o nghiire a
unei pastile.

3. Clasificarea. Are ca scop catalogarea unui fenomen ntr-o clas predefinit.
Fenomenele sunt de obicei prezentate sub forma unor nregistrri elementare ale
observaiei (tupluri). Clasificatorul este un algoritm care realizeaz clasificarea.
Este construit automat, folosind un set predefinit de date de antrenare ce const
dintr-un set de fenomene deja clasificate, apoi este folosit pentru clasificarea unor
fenomene generice. De obicei, clasificatorii sunt prezentai sub forma unor arbori
de decizie n care nodurile sunt etichetate prin condiii care permit luarea
deciziilor. Condiia se refer la atributele relaiei care nregistreaz fenomenul.
Cnd fenomenele sunt descrise de un numr mare de atribute, clasificatorii au i
responsabilitatea de a selecta cteva atribute semnificative, separndu-le de cele
nerelevante. Se dorete clasificarea polielor unei companii de asigurri, atribuind
fiecreia un risc nalt sau sczut. Pornind de la o colecie de observaii care descrie
poliele, clasificatorul determin iniial faptul c atributele semnificative pentru
definirea riscului unei polie sunt doar vrsta oferului i tipul vehiculului. Acesta
construiete apoi un arbore precum cel prezent n figura de mai jos. Un risc nalt
este atribuit tuturor oferilor sub vrsta de 23 de ani sau oferilor care conduc
maini sport sau camioane (figura 12.3.).

Polia (vrst, numr, tipauto)

Age<23

F

A
Tipauto=sport

F
A

Tipauto=autocamion

F
A

Fig. 12.3. Clasificatorul pentru identificarea riscurilor poliei

Data Mining
347
n continuare, vor fi prezentate mai n detaliu cteva din principalele probleme de data
mining.

12.2. Numrarea apariiilor concomitente

Se consider problema numrrii obiectelor care apar concomitent, aceasta fiind
motivat de probleme cum este analiza coului de cumprturi. Coul de cumprturi este o
colecie de obiecte cumprate de un client intr-o singura tranzacie (o singur vizit la
magazin, o singur comand prin pot, sau o singur comand la un magazin virtual pe
Internet). Un obiectiv frecvent pentru vnztorii cu amnuntul este de a identifica obiecte care
au fost achiziionate mpreun. Aceast informaie poate fi folosit pentru a mbunti
prezentarea ofertei de bunuri ntr-un magazin, sau ofertei din paginile unui catalog (figura
12.4.)

Idtranz Idclient Data Produs Cantitate
111 201 5/1/99 Stilou 2
111 201 5/1/99 Cerneala 1
111 201 5/1/99 Lapte 3
111 201 5/1/99 Suc 6
112 105 6/3/99 Stilou 1
112 105 6/3/99 Cerneala 1
112 105 6/3/99 Lapte 1
113 106 5/10/99 Stilou 1
113 106 5/10/99 Lapte 1
114 201 6/1/99 Stilou 2
114 201 6/1/99 Cerneala 2
114 201 6/1/99 Suc 4

Fig. 12.4. Relaia Achiziii pentru analiza costului de cumprturi

12.2.1. Seturi de obiecte frecvente

Relaia Achiziii prezentat n tabelul de mai sus va fi folosit pentru a ilustra
seturile de obiecte frecvente.
nregistrrile sunt sortate n grupuri de o tranzacie. Toate tuplurile dintr-un grup au
acelai Idtrans i mpreun descriu o tranzacie, care implic achiziionarea unuia sau mai
multor obiecte.
O tranzacie apare la o dat prescris, iar numele fiecrui produs cumprat este
nregistrat, mpreun cu cantitatea cumprat. Se observ c exist o redundan n
Achiziii: poate fi descompus prin pstrarea perechilor Idtranz-Idclient separat i
renunnd la Idclient; acesta ar putea fi chiar modul n care datele sunt stocate. Oricum, este
convenabil ca relaia Achiziii s fie considerat cum e prezentat n tabelul anterior pentru
a calcula seturile de date frecvente. Crearea de astfel de tabele denormalizate pentru
uurarea procesului de data mining este realizat n pasul de curare a datelor al procesului
KDD.
Capitolul 12
348
Prin examinarea grupurilor de seturi de tranzacii n Achiziii se pot face observaii
de forma: n 75% din tranzacii i stilourile i cerneala sunt achiziionate mpreuna. Este o
declaraie care descrie tranzaciile n baza de date. Extrapolarea la tranzacii viitoare trebuie
fcut cu grij.
Analiza coului de cumprturi implic utilizarea unei terminologii specifice. Prin set
de obiecte se nelege un grup de obiecte. Suportul unui set de obiecte este acea parte a
tranzaciilor din baza de date care conine toate obiectele din setul de obiecte.
n exemplul analizat, se va considera setul de obiecte {stilou, cerneal} i se observ
c suportul acestui set de obiecte a fost de 75% n Achiziii. Se poate concluziona c
stilourile i cerneala sunt frecvent achiziionate mpreun.
Dac se consider setul de obiecte {lapte, suc} suportul este de doar 25%. Rezult c
laptele i sucul sunt cumprate rar mpreun.
De obicei, numrul seturilor de obiecte care sunt cumprate frecvent mpreun este
relativ mic, n special cnd mrimea setului de obiecte crete. Prezint interes toate seturile de
obiecte al cror suport este mai mare dect un suport minim predefinit de utilizator, numit
minsup. Aceste seturi se numesc seturi de obiecte frecvente. De exemplu, dac suportul
minim este setat la 70% atunci seturile frecvente din exemplu considerat sunt {stilou},
{cerneal}, {lapte}, {stilou,cerneal} i {stilou, lapte}. Prezint interes i seturile de obiecte
care conin doar un singur obiect, deoarece identific obiectele frecvent cumprate.
n continuare, va fi prezentat un algoritm pentru identificarea seturilor de obiecte
frecvente. Acest algoritm se bazeaz pe o proprietate fundamental simpl a seturilor de
obiecte frecvente:
Proprietate a priori: Fiecare subset al unui set de obiecte frecvente trebuie sa fie un
set de obiecte frecvente.
Algoritmul este iterativ, identificnd mai nti seturile de obiecte frecvente cu doar un
obiect. n fiecare iteraie consecutiv, seturile de obiecte frecvente identificate n iteraia
anterioar sunt extinse cu alte obiecte pentru a genera seturi candidate de obiecte mai mari.
Considernd numai seturile de obiecte obinute prin lrgirea setului de obiecte frecvente, se va
reduce foarte mult numrul de seturi de obiecte frecvente candidate; aceast optimizare este
crucial pentru execuia eficient.
Proprietatea a priori garanteaz c optimizarea este corect, asta dac nu se rateaz
nici un set de obiecte frecvente.
O singur scanare a tuturor tranzaciilor (relaia Achiziii) este suficient pentru a
determina care dintre seturile de obiecte candidate generate ntr-o iteraie sunt seturi de
obiecte frecvente. Algoritmul se termin atunci cnd n cadrul unei noi iteraii nu mai este
identificat nici un set de obiecte frecvente (figura 12.5.).
pentru fiecare obiect, // Nivel 1
verific dac este un set de obiecte frecvent //apare n > minsup
k=1
repeta // Iterativ, identificarea n funcie de nivel setului de
obiecte frecvente
pentru fiecare set de obiecte frecvente nou
k
I cu k obiecte,
genereaz toate seturile de obiecte
1 + k
I cu k+1 obiecte,
k
I c
1 + k
I
scaneaz toate tranzaciile odat i verific dac seturile cu k+1 obiecte sunt
frecvente
k=k+1
pn cnd nu mai este identificat nici un set nou de obiecte frecvente

Fig. 12.5 Algoritm pentru aflarea seturilor de obiecte frecvente.
Data Mining
349
Algoritmul va fi ilustrat pentru relaia Achiziii de mai sus, cu minsup setat la 70%. n
prima iteraie (Nivelul 1) va fi scanat relaia Achiziii i se va determina ca fiecare din
aceste seturi de obiecte dintr-un singur obiect este un set de obiecte frecvent: {stilou}, apare
n toate cele patru tranzacii, {cerneal}, (apare n trei tranzacii din patru), iar {lapte } (n trei
tranzacii din patru).
n a doua iteraie (Nivelul 2) se extinde fiecare set de obiecte frecvent cu un obiect
adiional i se genereaz urmtoarele seturi de obiecte candidate {stilou, cerneal}, {stilou,
lapte}, {stilou, suc}, {cerneal, lapte} i {lapte, suc}. Prin scanarea relaiei Achiziii din
nou, se determina c apar urmtoarele seturi de obiecte frecvente: {stilou, cerneal} i {stilou,
lapte}.
n a treia iteraie (Nivelul 3) se extind seturile de obiecte candidate {stilou, cerneal,
lapte}, {stilou, cerneal, suc} i {stilou, lapte, suc}. Se observ c {cerneal, lapte, suc} nu
este generat. O a treia scanare a relaiei Achiziii ne ajut s determinm c niciunul dintre
aceste seturi de obiecte nu este frecvent.
Algoritmul simplu prezentat aici pentru gsirea seturilor de obiecte frecvente
ilustreaz principalele caracteristici ale unor algoritmi mai sofisticai, i anume generarea i
testarea iterativ a seturilor de obiecte candidate. Se va lua n considerare o rafinare
important a acestui algoritm simplu. Generarea seturilor de obiecte candidate prin adugarea
unui nou obiect la un set despre care se tie c este un set de obiecte frecvente este o ncercare
de a limita numrul seturilor de obiecte candidate folosind proprietatea a priori. Aceasta
implic faptul c un set de obiecte poate fi frecvent, daca toate subseturile sale sunt frecvente.
Deci, numrul seturilor de obiecte candidate poate fi redus nainte de scanarea bazei de date
Achiziii prin verificarea dac toate subseturile unui set de obiecte candidat nou generat
sunt frecvente. Doar dac toate subseturile a unui set de obiecte candidate sunt frecvente se
va calcula suportul prin scanarea bazei de date. Comparat cu algoritmul simplu, acest algoritm
rafinat genereaz mai puine seturi de obiecte candidate la fiecare nivel i acest lucru reduce
cantitatea calculelor n timpul scanrii bazei de date Achiziii.
Se consider algoritmul rafinat pentru tabela Achiziii, cu minsup = 70%. n prima
iteraie (Nivelul 1) se determin frecvena seturilor de obiecte de mrimea unu: {stilou},
{cerneal} i {lapte}. n a doua iteraie (Nivelul 2), numai urmtoarele seturi de obiecte
candidate rmn la scanarea tabelei Achiziii: {stilou, cerneal}, {stilou,lapte}, i {cerneal,
lapte}. Deoarece {suc} nu este frecvent, nici seturile de obiecte {stilou, suc}, {cerneal, suc}
i {lapte, suc} nu pot fi frecvente i se vor elimina aceste seturi de obiecte a priori, fr a le
considera n timpul scanrii relaiei Achiziii. n a treia iteraie (Nivelul 3), nu este generat
nici un set de obiecte candidat.
Deci, setul de obiecte {stilou, cerneal, lapte} nu pot fi frecvent dac subsetul su
{cerneal, lapte} nu este frecvent. Astfel, versiunea mbuntit a algoritmului nu necesit o
a treia scanare a tabelei Achiziii.

12.2.2. Interogrile iceberg

Se consider din nou tabela Achiziii. Se dorete gsirea de perechi de clieni i
produse n aa fel nct clientul s fi cumprat produsul de cel puin cinci ori. Aceast
interogare poate fi exprimat n SQL astfel:

Select A.Idclient, A.Produs, sum(A.Cantitate) From Achiziii A Group By A.Idclient A.Produs
Having sum (A.Cantitate) >5

Capitolul 12
350
S presupunem c aceast interogare ar fi evaluat de un SGBD relaional. Pentru
fiecare pereche (Idclient, Produs), trebuie verificat dac suma cmpului Cantitate este mai
mare dect 5. O abordare posibil este de a face o scanare asupra relaiei Achiziii i de a
relua calcularea sumei pentru fiecare pereche (Idclient, Produs). Aceasta este o strategie de
execuie fezabil atta timp ct numrul perechilor este ndeajuns de mic ca s ncap n
memoria principal. Dac numrul de perechi este mai mare dect memoria principal,
trebuie s fie utilizate alte modaliti de evaluare a interogrilor, care implic fie sortare, fie
hashing.
Chiar dac relaia Achiziii este foarte mare i numrul de grupuri (Idclient, Produs)
poate fi uria, rezultatul interogrii va fi probabil relativ mic din cauza condiiei din clauza
Having. Doar grupurile n care clientul a cumprat produsul de mai mult de cinci ori apar
n output. De exemplu, sunt nou grupuri n interogarea relaiei Achiziii, dei output-ul
conine trei nregistrri. Numrul de grupuri este foarte mare, dar rspunsul la interogare -
vrful icebergului - este, de obicei, foarte mic. Deci, o astfel de interogare este denumit
interogare iceberg. n general, avnd o schem relaional R, cu atributele A1, A2,Ak, i B
i o funcie agregat aggr, interogarea iceberg are urmtoarea structur:

Select R.A1, R.A2,R.Ak, aggr (R.B) From Relatia R Group By R.A1,R.Ak
Having aggr(R.B) >=constant

Modalitile tradiionale de realizare ale interogrilor calculeaz nti valorile funciei
de agregare pentru toate grupurile i elimin grupurile care nu satisfac condiia n clauza
HAVING.
Comparnd interogarea cu problema de a gsi seturile de obiecte frecvente, se observ
c exist o similaritate evident. Considerm din nou relaia Achiziii i interogarea iceberg
de la nceputul acestei seciuni. Se caut perechile (Idclient, Produs) care au SUM
(A.Cantitate) >5. Folosind o variant a proprietii a priori, se poate spune c trebuie luate n
considerare doar acele valori pentru cmpul Idclient unde clientul a cumprat cel puin 5
produse per total. Se pot astfel genera obiecte prin urmtoarele interogri:

Select A.Idclient From Achiziii A Group by A. Idclient Having sum (A.Cantitate)>5

Similar, se pot restriciona valorile candidate pentru cmpul produs prin urmtoarea
interogare:

Select A.Produs From Achiziii A Group by A.Produs Having sum (A.Cantitate)>5

Dac se restricioneaz interogarea iceberg original asupra grupurilor (Idclient,
Produs) pentru care valorile cmpurilor sunt ieirile celor dou interogri anterioare, se vor
elimina a priori un numr mare de perechi (Idclient, Produs). Deci, o posibil strategie de
evaluare este de a calcula nti valorile candidate pentru cmpurile Idclient i Produs, i de a
folosi combinaii ale acelor valori care trec de pasul a priori, cum a fost exprimat n cele dou
interogri anterioare. Deci, interogarea iceberg este supus la aceeai strategie de evaluare
bottom-up care este folosit pentru a gsi seturi de obiecte frecvente. n particular, putem
folosi proprietatea a priori astfel: se ia n considerare un grup doar dac componentele
individuale ale grupului satisfac condiia exprimat n clauza Having. mbuntirea
performanelor acestei strategii de evaluare alternativ fa de modul tradiional de realizare a
interogrilor poate fi semnificativ n practic.
Dei strategia de procesare bottom-up elimin a priori multe grupuri, numrul de
perechi (Idclient, Produs) poate fi foarte mare n practic - chiar mai mare dect memoria
Data Mining
351
principal. n acest sens, au fost dezvoltate strategii eficiente care folosesc eantionarea i
tehnici sofisticate de hashing.

12.3. Explorarea pentru descoperirea de reguli

Au fost propui numeroi algoritmi care urmresc descoperirea diferitor forme de
reguli care descriu n mod succint datele.

12.3.1. Reguli de asociere

Relaia Achiziii va fi folosit pentru a ilustra regulile de asociere. Prin examinarea
setului de tranzacii din Achiziii, se pot identifica reguli de forma {stilou} => {cerneal}
Aceast regul trebuie citit astfel: Dac un stilou este achiziionat ntr-o tranzacie,
este probabil c i cerneala va fi procurat n aceeai tranzacie.
Este o declaraie care descrie tranzaciile existente n baza de date; extrapolarea la
tranzaciile viitoare trebuie fcut cu atenie.
Mai general, o regul de asociere are forma LHS=>RHS, unde i LHS i RHS sunt
seturi de obiecte. Interpretarea unei astfel de reguli este c, dac ntr-o tranzacie este
achiziionat fiecare obiect din LHS, atunci este probabil ca i obiectele din RHS s fie
achiziionate.
Exist dou msuri importante pentru o regul de asociere:
- Suportul: Suportul unui set de obiecte este procentajul tranzaciilor care conin
toate aceste obiecte. Suportul pentru o regul LHS => RHS este suportul pentru
setul de obiecte LHS U RHS. De exemplu, se consider regula
{stilou}=>{cerneal}. Suportul acestei reguli este suportul setului de obiecte
{stilou, cerneal}, care este de 75%
- ncrederea: Se consider tranzaciile care conin toate obiectele din LHS.
ncrederea pentru o regul LHS=>RHS este procentul din aceste tranzacii care
conin, de asemenea, toate obiectele din RHS. Fie sup(LHS) procentajul
tranzaciilor care conin LHS, i fie sup(LHS U RHS) procentajul tranzaciilor care
conin att LHS, ct i RHS. Astfel, ncrederea n regula LHS=>RHS este
sup(LHS)/sup(LHS U RHS). ncrederea unei reguli indic tria acestei reguli.
Procentul de ncredere al regulii {stilou}=>{cerneal} este de 75%; 75% din
tranzaciile care conin setul de obiecte {stilou} conin de asemenea i setul de
obiecte {cerneal}.

12.3.2. Algoritm pentru gsirea regulilor de asociere

Un utilizator poate solicita toate regulile de asociere care au un suport minim
specificat (minsup) i o ncredere minim (mincon), i au fost dezvoltai diferii algoritmi
pentru gsirea eficient a acestei reguli. Aceti algoritmi se desfoar n doi pai. n primul
pas sunt calculate toate seturile de obiecte frecvente cu suportul minim precizat de utilizator.
n al doilea pas, sunt generate regulile folosind seturi de obiecte frecvente ca intrri.
Odat ce sunt identificate seturile de obiecte frecvente, pasul urmtor este generarea
tuturor regulilor posibile cu suportul minim specificat de utilizator. Se consider un set de
Capitolul 12
352
obiecte frecvente X cu suportul Sx identificat n primul pas al algoritmului. Pentru a genera o
regul pentru X, vom mpri X n dou seturi de obiecte LHS i RHS. ncrederea regulii
LHS=>RHS este Sx/SLHS. Din proprietatea a priori se tie c suportul lui LHS este mai
mare dect minsup i suportul lui LHS s-a calculat n primul pas al algoritmului. Se pot
calcula valorile ncrederii pentru regulile candidate prin calcularea raportului
suport(X)/suport(LHS) i apoi se verific cu intervalul mincon.
n general, pasul costisitor al algoritmului este calcularea seturilor de obiecte frecvente
i au fost dezvoltai muli algoritmi pentru a realiza n mod eficient acest pas.
Urmtorul pas este generarea regulilor, dat fiind faptul c au fost identificate toate
seturile de obiecte frecvente.

12.3.3. Regulile de asociere i ierarhiile ISA

n multe cazuri se impune o ierarhie ISA sau o ierarhie pe categorii asupra seturilor de
obiecte. n prezena unei ierarhii, o tranzacie conine implicit, pentru fiecare din obiectele
sale toi predecesorii obiectelor n ierarhie. De exemplu, se consider ierarhia categoriilor
prezentate n figura 12.6. Dat fiind aceast ierarhie, relaia Achiziii este conceptual sporit
cu cele opt nregistrri din figura de mai jos. Ca urmare, relaia Achiziii are toate tuplurile
iniiale plus tuplurile ilustrate n figura 12.7.
Ierarhia permite detectarea relaiilor dintre obiecte la diferite nivele ale ierarhiei. De
exemplu, suportul setului de obiecte {cerneal,suc} este de 50%, dar dac se nlocuiete
sucul cu o categorie mai general numit buturi, suportul setului de obiecte rezultat
{cerneal, buturi} crete la 75%. n general, suportul unui set de obiecte poate crete doar
dac un obiect este nlocuit de unul din predecesorii si n ierarhia ISA.
Presupunnd c adugm fizic la relaia Achiziii cele opt nregistrri artate n
figura 12.7, se poate folosi orice algoritm pentru calcularea seturilor de obiecte frecvente din
baza de date mrita. Presupunnd c ierarhia ncape n memoria principal, se poate executa
adugarea n acelai timp cu scanarea bazei de date, ca o optimizare.
Papetrie Buturi

Stilou Cerneala Suc Lapte

Fig. 12.6 Taxonomia categoriilor ISA

111 201 5/1/99 Papetrie 3
111 201 5/1/99 Buturi 9
112 105 6/3/99 Papetrie 2
112 105 6/3/99 Buturi 1
113 106 5/1/99 Papetrie 1
113 106 5/1/99 Buturi 1
114 201 5/15/99 Papetrie 4
114 201 5/15/99 Buturi 4

Fig. 12.7 Adugri conceptuale la relaia Achiziii cu Ierarhia ISA
Data Mining
353
12.3.4. Reguli de asociere generalizate

Dei regulile de asociere au fost studiate pe larg n contextul analizei coului de
cumprturi sau analizei tranzaciilor clientului, conceptul este mai general.
Considerm relaia Achiziii ilustrat mai jos, grupat dup identitatea clientului.
Prin examinarea setului de grupuri de clieni, putem identifica reguli de asociere ca
{stilou}=>{cerneal}. Aceast regul ar trebui citit astfel: Dac un stilou este cumprat de
un client, este posibil ca i laptele s fie achiziionat de acel client. n relaia Achiziii de
mai jos, aceast regul are i suportul i ncrederea de 100%.

112 105 6/3/99 Stilou 1
112 105 6/3/99 Cerneala 1
112 105 6/3/99 Lapte 1
113 106 5/1/99 Stilou 1
113 106 5/1/99 Lapte 1
114 201 5/15/99 Stilou 2
114 201 5/15/99 Cerneala 2
114 201 5/15/99 Suc 4
111 201 5/1/99 Stilou 2
111 201 5/1/99 Cerneala 1
111 201 5/1/99 lapte 3
111 201 5/1/99 Suc 6

Fig. 12.8 Relaia Achiziii sortat dup identitatea clientului.

Similar, se pot grupa tuplurile dup dat i identifica reguli de asociere care descriu
comportamentul de Achiziii din aceeai zi. De exemplu, se consider din nou relaia
Achiziii. n acest caz, regula {stilou}=>{ceneal} este acum interpretat astfel. Dac ntr-o zi
a fost cumprat un stilou, este probabil c se va cumpra i lapte.
Dac folosim cmpul Data ca atribut de grupare, pot fi luate n considerare probleme
mai generale numite analiz calendaristic a coului de cumprturi. n analiza coului de
cumprturi, utilizatorul specific o colecie de calendare. Un calendar este orice grupare de
date, de exemplu, fiecare Mari a anului 2006 sau fiecare nceput de lun. O regul se
consider respectat dac este respectat pentru fiecare zi a calendarului. Fiind dat un
calendar, se pot calcula reguli de asociere pe setul de date pentru care cmpul Data aparine
calendarului considerat. Prin specificarea unor calendare, se pot identifica reguli care pot s
nu aib destul suport i ncredere n raport cu ntreaga baz de date, dar au destul suport i
ncredere pentru subsetul de tupluri al cror cmpuri de date ca n calendar.
Pe de alt parte, chiar dac o regul ar putea avea destul suport i ncredere n raport
cu ntreaga baz de date, ar putea ctiga suportul doar din tupluri care au czut n calendar. n
acest caz, suportul regulii pentru tuplurile din calendar este semnificativ mai mare dect
suportul n raport cu ntreaga baz de date.
Fie relaia Achiziii cu calendarul fiecare nceput al lunii. Cu acest calendar, regula
{stilou}=>{lapte} are suport i ncredere 100% , unde pentru ntreaga relaie Achiziii are
suportul de doar 50%.
Au fost propuse i specificaii mai generale ale condiiilor care trebuie sa fie adevrate
pentru un grup pentru a respecta o regul (pentru acel grup). Putem spune c toate obiectele n
Capitolul 12
354
LHS au fost cumprate ntr-o cantitate mai mic de dou buci i toate obiectele din RHS au
fost achiziionate ntr-o cantitate mai mare dect trei.
Folosind diferite opiuni pentru gruparea atributelor i condiii sofisticate, se pot
identifica reguli care sunt mai complexe care pstreaz structura esenial a unei reguli de
asociere ca o condiie asupra unui grup, cu suportul i ncrederea definite ca de obicei.

12.3.5. Modele secveniale

Consideram relaia Achiziii din figura 12.4. Fiecare grup de tupluri avnd aceeai
identitate a clientului (Idclient), poate fi considerat ca o secven de tranzacii ordonate dup
dat. Aceasta ne permite s identificm n timp modelele de cumprare care apar frecvent.
Fiecare tranzacie este reprezentat de un set de tupluri i prin valorile din cmpul
Produs se identific setul de obiecte achiziionate n acea tranzacie. Deci, secvena
tranzaciilor asociate unui client corespund unei secvene de seturi de obiecte achiziionate de
client. De exemplu, secvena achiziiilor pentru clientul 2 este {stilou, cerneal, lapte, suc},
{stilou, cerneal, suc}.
O subsecven a unei secvene de seturi de obiecte este obinut prin tergerea unuia
sau mai multor seturi de obiecte i este de asemenea o secven de seturi de obiecte. O
secven {ai,..,am} este coninut ntr-o secven S dac S are o subsecven {b1,bm} cu
ai _bi, pentru 1im. Secvena {stilou}, {cerneal, lapte}, {stilou, suc} este coninut n
{stilou, cerneal}, {tricou}, {suc, cerneal, lapte}, {suc, lapte, cerneal}.
Suportul pentru o secven S a unui set de obiecte este procentul secvenelor unui
client pentru care S este o subsecven. Problema identificrii modelelor secveniale const n
a gsi toate secvenele care au un suport minim specificat de utilizator. O secven s1, s2,
s3,.sn cu un suport minim arat c clienii cumpr frecvent obiectele din setul s1 ntr-o
tranzacie, apoi ntr-o tranzacie succesiv cumpr obiectele din setul 2, apoi obiectele din
setul s3, ntr-o tranzacie ulterioar, s.a.m.d.
Ca i regulile de asociere, modelele secveniale sunt afirmaii referitoare la grupurile
de tupluri din baza de date curent. Din punct de vedere al procesrii, algoritmii pentru
gsirea modelelor secveniale frecvenele seamn cu algoritmii pentru gsirea seturilor de
obiecte frecvene. Secvenele lungi cu suportul minim necesar sunt identificate iterativ, ntr-o
manier care este foarte similar cu identificarea iterativ a seturilor de obiecte frecvente.

12.3.6. Folosirea regulilor de asociere pentru predicii

Regulile de asociere sunt folosite la scar larg pentru previzionri, dar este important
s recunoatem c astfel de previzionri nu sunt justificate fr o analiz ulterioar sau alte
cunotine din domeniu. Regulile de asociere descriu exact datele existente, dar pot fi confuze
cnd sunt folosite naiv pentru predicie. De exemplu, fie regul {stilou}=>{cerneal}.
ncrederea asociat acestei reguli este probabilitatea condiionat de a achiziiona
cerneala dat fiind achiziionarea unui stilou, n baza de date curent. Aceasta este o msur
descriptiv. Putem folosi aceast regul pentru vnzarile promoionale viitoare. De exemplu,
putem oferi un discount la stilouri pentru a crete vnzrile de stilouri i astfel cresc vnzrile
i la cerneal.
Oricum, o asemenea promoie presupune c achiziiile de stilouri sunt indicatori buni
ai vnzrilor de cerneala n tranzaciile viitoare. Aceasta presupunere este justificata dac
exist o legtur cauzal ntre achiziionarea de stilouri i achiziionarea de cerneal. Adic,
Data Mining
355
dac cumprarea de stilouri face ca clientul s cumpere i cerneal. Oricum, se pot aplica
reguli de asociere cu suport i ncredere nalte n situaii unde nu exist nici o legtur cauzal
ntre LHS i RHS. De exemplu, se presupune c stilourile sunt achiziionate ntotdeauna
mpreuna cu creioanele, probabil din cauza tendinei clienilor de a comanda instrumente de
scris mpreun. Se poate introduce regula:
{creion}=>{cerneal} cu acelai suport i ncredere ca i regula:
{stilou}=>{cerneal}.
Oricum, nu exist nici o legtura cauzal ntre creioane i cerneal. Dac promovm
creioanele, un client care achiziioneaz mai multe creioane din cauza promoiilor nu are nici
un motiv pentru a cumpra mai mult cerneal. Deci, o promoie care face discount la
creioane pentru a crete vnzrile la cerneal ar fi inutil.
n practic, ar fi de ateptat ca prin examinarea unei baze de date mari ale tranzaciilor
istorice (colectate ntr-o perioad mai mare de timp i o varietate de circumstane) i
restrngnd atenia ctre reguli care apar des (care au suport mare) sa fie minimizate regulile
care ghideaz greit. Oricum, trebuie reinut faptul c vor fi generate i reguli greite,
necauzale. Deci, va trebui s tratm regulile ca posibile, nu concluzive, identificnd relaiile
cauzale. Dei regulile de asociere nu indic relaii cauzale ntre LHS i RHS, ele ofer un
punct de pornire pentru identificarea relaiilor de acest fel, fie analiznd n continuare, fie
apelnd un expert n domeniu; acesta este motivul pentru popularitatea lor.

12.3.7. Relaiile Bayesian

Gsirea relaiilor cauzale este o sarcin solicitant. n general, dac anumite
evenimente sunt intens corelate, exist multe explicaii posibile.
De exemplu, presupunem c stilourile, creioanele i cerneal sunt cumprate frecvent
mpreun. Poate fi pentru c achiziionarea unuia dintre produse (de exemplu, cerneala)
depinde cauzal de achiziionarea unui alt produs (de exemplu, stilou), este puternic corelata cu
achiziionarea altuia (de exemplu, creion) sau poate fi din cauza ca achiziionarea unuia
dintre produse este puternic corelat cu cumprarea altuia din cauza existenei unui fenomen
(de exemplu, tendina de a te gndi la mai multe instrumente de scris mpreuna) care
influeneaz cauzal ambele achiziii. Cum putem identifica relaiile cauzale adevrate
existene evenimente n lumea real?
O posibil abordare pentru a identifica relaiile cauzale reale existente ntre
evenimente este de a considera fiecare combinaie posibil a relaiilor cauzale dintre
variabilele sau evenimentele de interes i de a evalua probabilitatea fiecrei combinaii pe
baza setului de date disponibile. Dac privim fiecare combinaie de relaii cauzale ca pe un
model al lumii reale pe baza datelor colectate, se poate atribui un scor fiecrui model, n
funcie de ct de concordant este cu datele observate. Reelele bayesiene sunt grafuri care pot
fi folosite pentru a descrie o categorie de astfel de modele, care prezint cte un nod pentru
fiecare variabil sau eveniment i un arc ntre noduri pentru a arta cauzalitatea. Figura 12.9
jos reprezint un model posibil al exemplului cu creioane, stilouri i cerneal.

Capitolul 12
356

Fig. 12.9. Reea bayesian pentru indicarea cauzalitii

12.3.8. Reguli de clasificare i regresie

Fie urmtorul view care conine informaii referitoare la o campanie efectuat de o
companie de asigurri:

InfoAsig( vrsta:integer; model_ main: string; risc_major :boolean)

View-ul conine informaii despre clienii actuali. Fiecare nregistrare conine vrsta i
modelul de maina al clientului, precum i un indicator care arat dac persoana este
considerat un client cu risc major. Dac indicatorul este adevrat, clientul este considerat
client cu risc major. Aceste informaii vor fi folosite pentru a identifica reguli care s prezic
riscul de asigurare al noilor solicitani de asigurri a cror vrsta i model de maina sunt
cunoscute. De exemplu, o astfel de regula ar pute fi: Dac vrsta este ntre 16 i 25, iar
modelul de main este sport ori autocamion, atunci riscul este major.
Atributul desemnat pentru realizarea previzionrii se numete atribut dependent.
Celelalte atribute sunt numite atribute predictor. n exemplul considerat, atributul dependent
n analiza informaiilor despre asigurare este riscul de asigurare, iar atributele predictor sunt
vrsta i modelul mainii. Forma general a tipurilor de reguli cutate este:

P
1
(X
1
)^P
2
(X
2
)^P
k
(X
k
)=>Y=c.

Atributele predictor X
1
,.X
k
sunt folosite pentru a prezice valoarea atributului
dependent Y. Ambele pri ale unei reguli pot fi interpretate drept condiii asupra cmpurilor
unui tuplu. P
i
(X
i
) sunt predicate care implic atributul X
i
. Forma predicatului depinde de tipul
atributului predictor. Distingem dou tipuri de atribute: numerice i categorice. Pentru
atributele numerice, putem efectua calcule precum calcularea mediei a dou valori, pe cnd
pentru atributele categorice, domeniul lor este un set de valori. n analiza informaiilor despre
asigurri, vrsta este un atribut numeric pe cnd modelul mainii i riscul sunt atribute
categorice. Revenind la forma predicatelor, dac X
i
este un atribut numeric, predicatul sau P
i

este de forma l
i
X
i
h
i
; dac X
i
este un atribut categoric, P
i
este de forma X
i
e{v
1
..v
j
}.
Dac atributul dependent este categoric, regulile se numesc reguli de clasificare. Dac
atributul dependent este numeric, regulile se numesc reguli de regresie.
De exemplu, fie din nou regula din exemplul precedent: Dac vrsta este cuprins
ntre 16 i 25 iar modelul mainii este ori sport ori autocamion, atunci riscul este major. De
vreme ce riscul este un atribut categoric, aceast regul este de clasificare. Putem exprima
aceast regul formal dup cum urmeaz:
Nevoie de
instrumente de
scris
Cumpra
cerneal
Cumpra
creioane
Cumpra
stilouri
Data Mining
357
(16vrsta25)^(modelul mainii e (sport, autocamion))=> (risc-major=adevrat)

Putem defini suportul i ncrederea pentru regulile de clasificare i regresie, ca i
pentru regulile de asociere:
- suportul: suportul pentru o condiie C este procentul tuplurilor care satisfac
condiia C. Suportul pentru regula C1=>C2 este suportul pentru condiia C1^C2.
- ncrederea: fie acele tupluri care satisfac condiia C1. ncrederea pentru o regul
C1=>C2 este procentul din acele tupluri care satisfac condiia C2.
Pentru o mai ampl generalizare, fie partea dreapt a unei reguli de clasificare sau
regresie: Y=c. Fiecare regul prezice o valoare a lui Y pentru un tuplu dat pe baza valorilor
atributelor predictor X
1
,.X
k.

Regulile de clasificare i regresie difer de regulile de asociere prin analizarea
cmpurilor continue i tip categorie, i nu a unui singur cmp care este set de valori.
Regulile de clasificare i regresie au multiple aplicaii. Exemplele pot include
clasificarea rezultatelor unor experimente tiinifice, unde tipul obiectului de recunoscut
depinde de msurtorile fcute, prospectarea pieei prin pot, unde rspunsul unui client la o
promoie este o funcie de nivelul de trai i vrsta sa. Exemple de aplicaii ale regulilor de
regresie includ preziceri financiare, unde preul cafelei ar putea fi n funcie de ploile din
Columbia n urm cu o luna.

12.4. Reguli structurate sub forma de arbori

n cele ce urmeaz se va discuta descoperirea regulilor de clasificare i regresie dintr-o
relaie, dar vor fi luate n considerare numai regulile care au o structur special, care pot fi
reprezentate printr-un arbore, iar n mod tipic arborele nsi este rezultatul activitii de
cutare a datelor. Arborii care reprezint reguli de clasificare se numesc arbori de clasificare,
iar arborii care prezint reguli de regresie se numesc arbori de regresie.

Fig. 12.10 Arbore de decizie pentru exemplul Riscul de asigurare

n arborele din figura de mai sus, fiecare cale de la rdcin spre o frunz reprezint o
regul de clasificare. De exemplu, calea de la rdcin pn la frunza cea mai din stnga
reprezint regula de clasificare: Dac o persoan are 25 de ani sau mai puin i conduce o
Dacie, atunci este probabil s aib un risc de asigurare sczut. Calea de la rdcin spre
frunza cea mai din dreapta reprezint regula de clasificare: Dac o persoan are mai mult de
25 de ani atunci este probabil s aib un risc de asigurare sczut.
Vrsta
Tip_maina
Nu
Nu Da
>25
<=25
Dacia
Sport,
autocamion
Capitolul 12
358
Regulile structurate sub forma de arbori sunt foarte populare deoarece sunt uor de
interpretat. Uurina nelegerii este foarte important, deoarece rezultatul oricrei activiti de
cutare a datelor trebuie sa fie pe nelesul celor nespecialiti. n plus, studiile au artat c
indiferent de limitrile de structur, regulile structurate n arbori sunt foarte exacte. Exist
algoritmi eficieni pentru a construi reguli structurate ca arbori din date de baze de mari
dimensiuni.

12.4.1. Arbori de decizie

Un arbore de decizie este reprezentarea grafic a unei colecii de reguli de clasificare.
Avnd o nregistrare, arborele conduce nregistrarea de la rdcin spre o frunz. Fiecare nod
intern al arborelui este etichetat cu un atribut predictor. Acest atribut este adesea numit atribut
de scindare, deoarece datele sunt scindate n funcie de condiiile pentru acest atribut. Ieirile
unui nod intern sunt etichetate cu predicate care implic atributul de scindare al nodului;
fiecare nregistrare care intr n nod trebuie s satisfac predicatul, etichetnd astfel o singur
ieire. Informaia combinat despre atributul de scindare i predicatele de pe ieiri este numit
criteriul de scindare al nodului. Un nod fr ieiri este numit nod frunza. Fiecare nod frunz
al arborelui este etichetat cu o valoare a atributului dependent. Vor fi luai n considerare
numai arbori binari, n care nodurile interne au dou ieiri, cu toate c sunt posibili i arbori
cu grade superioare.
n arborele de decizie din figura de mai sus, atributul de scindare al nodului rdcin
este vrsta, atributul de scindare al copilului din stnga al rdcinii este modelul mainii.
Predicatul de pe ieirea din stnga al nodului rdcina este vrsta mai mic sau egal cu 25,
predicatul de pe marginea exterioar dreapt este vrsta mai mare dect 25.
Fiecrui nod frunza din arbore i se poate asocia acum o regul de clasificare, dup
cum urmeaz. Se ia n considerare calea de la rdcina arborelui pn la nodul frunz. Fiecare
legtur de ieire a acestei ci este etichetat cu un predicat. Legtura dintre toate aceste
predicate formeaz partea stng a regulii. Valoarea atributelor dependente n nodul frunz
formeaz partea dreapt a regulii. Aadar, arborele de decizie reprezint o colecie de reguli
de clasificare, cte una pentru fiecare nod frunz.
Un arbore de decizie este construit de obicei n dou faze. n prima faz, faza de
cretere este construit un arbore foarte mare. Acest arbore reprezint nregistrrile n baza de
date interne foarte clar, de exemplu, un arbore ar putea s conin noduri frunz pentru fiecare
nregistrare din baza de date intern. n faza a doua, faz de curare, este determinat
dimensiunea final a arborelui. Regulile reprezentate n arbore n prima faz sunt de obicei
supraspecializate. Reducnd dimensiunea arborelui, se genereaz un numr mai mic de reguli
mai generale, care sunt mai bune dect un numr mare de reguli foarte specializate.
Algoritmii pentru arbori de clasificare construiesc arborele gradat, top-down, n felul
urmtor. n nodul rdcin este examinat baza de date i este calculat cel mai bun criteriu
local de scindare. Baza de date este astfel partiionat, n funcie de criteriul de scindare a
nodului rdcin, n dou pri, o partiie pentru copilul din stnga i una pentru cel din
dreapta. Algoritmul se repet pentru fiecare copil. Aceast schem este prezentat n figura
12.11.
Criteriul de scindare pentru un nod este gsit prin aplicarea unei metode de selecie de
scindare. O metod de selecie de scindare este un algoritm care primete ca intrare o relaie i
are ca rezultat cel mai bun criteriu local de scindare. n exemplul nostru, metoda analizeaz
atributele Tip_main i Vrsta, selecteaz unul dintre ele drept atribut de scindare, iar apoi
selecteaz predicatele de scindare.

Data Mining
359
Contruire_arbore(nod n, partiie_date D, metod_ scindare S)
Se aplic S pentru D pentru a gsi criteriul de scindare
if (e gsit un criteriu de scindare bun)
Creeaz dou noduri copil pentru n, n1 i n2
Partiioneaz D n D1 i D2
Contruire_arbore(n1,D1,S)
Contruire_arbore(n2,D2,S)
endif

Fig. 12.11. Schema de dezvoltare top-down a arborelui de decizie

12.4.2. Un algoritm de construire a arborilor de decizie

Dac baza de date se ncadreaz n memoria principal, se poate urmri direct schema
de inducie pentru arborele de clasificare din figura 12.10. Cum se pot construi arbori de
decizie cnd relaia intrrilor este mai mare dect memoria principal? n acest caz, primul
pas din figur este greit, deoarece baza de date de intrare nu se ncadreaz n memoria
principal. Dar se poate face o observaie important despre metodele de selecie de scindare
care ajuta la reducerea acelei cererii de memorie principale.
Se consider un nod al arborelui de decizie. Metoda de selecie de scindare trebuie s
ia dou decizii dup examinarea partiiei la acel nod (i). Trebuie s selecteze atributul de
scindare, i (ii) trebuie s selecteze predicatele de scindare pentru ieirile sale. O dat ales
criteriul de scindare, algoritmul este aplicat recursiv fiecrui copil al nodului. Are nevoie o
metod de selecie de scindare de ntreaga partiie a bazei de date ca intrare? Din fericire,
rspunsul este negativ.
Metodele de selecie de scindare care calculeaz criterii de scindare ce implic un
singur atribut predictor pentru fiecare nod, evalueaz individual fiecare atribut predictor. Din
moment ce este examinat separat fiecare atribut, metodei de selecie de scindare i se pot
furniza informaii agregate despre baza de date, n loc s se ncarce ntreaga baz de date n
memoria principal. Dac sunt selectate corect, aceste informaii de agregare sunt suficiente
pentru a calcula cel mai bun atribut de scindare.

Vrsta Tip_maina Risc_major
21 Dacie False
32 Sport False
33 Dacie False
24 Autocamion True
34 Dacie False
21 Autocamion True
36 Autocamion False
25 Sport True
19 Dacie false

Fig. 12.12.Relaia Asigurare

Din moment ce metoda de selecie de scindare examineaz toate atributele predictor,
este nevoie de informaii agregate despre fiecare atribut predictor n parte. Aceast informaie
agregat este denumita setul AVC al atributului predictor. Acronimul AVC vine de la Atribut-
Capitolul 12
360
Valoare, etichete de Clase, deoarece valorile atributului dependent sunt de obicei numite
etichete de clase. Setul AVC al atributului predictor X n nodul n este proiecia partiiei bazei
de date a lui n pe X i pe atributul dependent pentru care sunt agregate valorile individuale ale
domeniului atributului dependent. De exemplu, fie relaia InfoAsigurare din figura de mai sus.
Setul AVC al nodului rdcin al arborelui pentru atributul predictor vrsta este rezultatul
urmtoarei interogri:

SELECT I.Vrsta, I.Risc_major, COUNT(*) FROM InfoAsigurare I
GROUP BY I.Vrst, I.Risc_major

Setul AVC pentru copilul din stnga al nodului rdcin pentru atributul predictor
modelul mainii este rezultatul urmtoarei interogri:

SELECT Tip_main, I.Risc_major, COUNT(*) FROM InfoAsigurare I
WHERE I.Vrsta <=25 GROUP BY I.Vrsta, I.Risc_major

Cele dou seturi AVC ale nodului rdcin sunt prezentate n figura 12.13.

Tip_maina Risc_major
= true
Risc_major
= false
Dacie 0 4
Sport 1 1
Autocamion 2 1

Vrsta Risc_major = true Risc_major = true
18 0 1
23 1 1
25 2 0
30 0 3
36 0 1

Fig. 12.13 Seturi AVC ale nodului rdcina

Considerm un grup AVC al nodului n ca fiind setul seturilor AVC ale tuturor
atributelor predictor pentru nodul n. n exemplul cu informaii despre asigurare, exist dou
tipuri de atribute, de aceea grupul AVC al fiecrui nod va conine dou seturi AVC.
Ct de mari sunt seturile AVC? Este bine de tiut ca mrimea unui set AVC a unui
atribut X al unui nod n depinde doar de numrul de valori ale atributului X i de mrimea
domeniului atributului dependent.
De exemplu, fie setul AVC reprezentat n figura 12.13. Setul AVC pentru atributul
predictor tipul mainii are trei intrri, iar setul AVC pentru atributul predictor Vrsta are
cinci intrri, dei informaiile despre asigurare prezentate n figura 12.12 au nou nregistrri.
Pentru baze de date mai mari, mrimea setului AVC este independent de numrul de
tupluri din baza de date, excepie fcndu-se doar n cazul n care exist atribute cu domenii
mari.
Dac se presupune c toate seturile AVC ale nodului rdcin ar ncpea exact n
memoria principal, s-ar putea construi arborele de decizie dintr-o baz de date de mari
Data Mining
361
dimensiuni, dup cum urmeaz: se parcurge baza de date i se construiete n memorie grupul
AVC al nodului rdcina. Apoi se executa metoda aleasa de scindare a seciunii, cu setul
AVC construit ca intrare. Dup ce metod aleas calculeaz cel mai bun atribut de scindare i
predicatele de scindare pentru nodurile de ieire, se partiioneaz baza de date, i se aplic din
nou, recursiv, algoritmul.

12.5. Clusterizarea (gruparea)

n aceast seciune este prezentat problema clusterizrii. Scopul este de a partiiona
un set de nregistrri n grupuri, n aa fel nct nregistrrile dintr-un grup s semene ntre ele,
n timp ce nregistrrile care aparin de dou grupuri diferite nu sunt similare. Fiecare grup se
numete cluster, i fiecare nregistrare aparine exact unui cluster. Similitudinea ntre
nregistrri poate fi msurat printr-o funcie distan. O funcie distan ia ca parametrii de
intrare dou nregistrri i returneaz o valoare care exprim similaritatea dintre ele.
Aplicaiile pot avea noiuni diferite despre similaritate, astfel nct nu exist o msura unic
pentru toate domeniile.

ConstruireArbore(nod n, partiie_date D, metoda_scindare S)
Se parcurge D i se construiete grupul AVC de n n memorie
Se aplica S grupului AVC pentru a gsi criteriul de scindare

Fig. 12.14 Clasificarea arborilor de inducie rafinat cu grupuri AVC

Ca exemplu se poate considera schema InfoClieni:

Clieni(vrsta:interger, salarii:real)

nregistrrile pot fi reprezentate n spaiul bidimensional. Cele dou coordonate ale
unei nregistrri sunt valori ale nregistrrii pentru cmpurile vrst i salariu. Se pot astfel
identifica trei clustere: clieni tineri care au salarii mici, clieni tineri care au salarii mari i
clieni mai n vrst care au salarii mari. De obicei, ieirile unui algoritm de clusterizare sunt
formate din reprezentrile sumarizate ale fiecrui cluster. Tipul reprezentrii sumarizate
depinde foarte mult de tipul i forma clusterelor obinute de algoritm.
Spre exemplu, pot fi grupuri sferice, ca n figura 12.15, i se poate rezuma fiecare grup
prin propriul lui centru i raza, dup cum urmeaz.
Fie o colecie de nregistrri r
1
,., r
n
, cu centrul C i raza R definite ca:
C=
=
n
i
i
r
1
i R=
n
M r
n
i
i
=
1
) (

Exist dou tipuri de algoritmi de clusterizare. Un algoritm de clusterizare partiional,
care mparte datele n k grupuri astfel nct criteriului de evaluare a calitii clusterizrii sa fie
optim. Numrul de clustere k este un parametru a crui valoare este specificat de utilizator.
Un algoritm de clusterizare ierarhic genereaz o secven de partiii ale nregistrrilor. Se
ncepe cu o partiie n care fiecare cluster e format dintr-o singur nregistrare, apoi algoritmul
fuzioneaz cte dou partiii la fiecare pas, pn cnd la sfrit rmne o singur partiie.

Capitolul 12
362
12.5.1. Algoritm de clusterizare

Clusterizarea este o problem foarte veche i au fost deja dezvoltai muli algoritmi n
acest sens. Tradiional, numrul de nregistrri din baza de date de intrare s-a presupus a fi
relativ mic, iar completarea ulterioar a bazei de date s-a presupus a ncpea n memoria
intern. n continuare va fi descris un algoritm de clusterizare numit BIRCH pentru baze de
date mai mari.
Algoritmul reflect urmtoarele dou presupuneri:
- numrul de nregistrri este foarte mare i de aceea se dorete o singur scanare a
bazei de date;
- memoria disponibil este limitat.

Fig. 12.15. nregistrrile din InfoClient

Un utilizator poate seta doi parametri de control ai algoritmului BIRCH. Primul
parametru este un prag al cantitii de memorie principal disponibil. Acest prag al memoriei
principale se transform ntr-un numr maxim k de sumarizri de grupuri care pot fi pstrate
n memoria intern. Al doilea parametru e este un prag iniial pentru raza oricrui grup.
Valoarea pentru e este limit superioar a razei oricrui grup i controleaz numrul de
grupuri gsite n cadrul algoritmului.
Dac e e mai mic, sunt gsite mai multe clustere mici. Dac e este mai mare, sunt
gsite clustere puine de o mrime relativ mare. Un cluster este ca un grup este compact dac
raza sa e mai mic dect e.
Algoritmul pstreaz k sau cteva sumarizri de clustere (C
i
,R
i
) n memoria principal,
unde C
i
e centrul clusterului, iar R raza clusterului. Algoritmul pstreaz ntotdeauna clustere
compacte, pentru care raza fiecrui cluster e mai mic dect e. Dac aceast invariant nu
poate fi memorat dat fiind memoria principal disponibil valoarea dat, e va crete dup
cum se descrie mai jos.
Algoritmul citete secvenial nregistrrile din baza de date i le proceseaz astfel:
- calculeaz distantele dintre nregistrarea r i centrul fiecrui cluster. Fie i un index
pentru clusterul respectiv, astfel nct distana ntre r i C
i
are cea mai mic valoare.
- calculeaz valoarea pentru noul R
i

pentru al i-lea cluster, presupunnd ca acesta este
grupul n care a fost inserat nregistrarea r. Daca R
i
<e, atunci cel de-al i-lea cluster

60k
30k
Salariul
Vrsta
20 40 60
A
B
C
Data Mining
363
rmne compact, i r se asociaz celui de-al i-lea grup, reactualiznd centrul i
setnd raza R
i
. Dac R
i
>e atunci al i-lea cluster nu va mai fi compact dac va fi

inserat r. Din acest motiv, se introduce un nou cluster care va conine doar
nregistrarea r.
Cel de-al doilea pas prezint probleme dac avem deja un numr maxim de sumarizri
de grupuri, k. Dac se citete o nregistrare care necesit crearea unui nou grup, nu va fi
memorie suficient pentru a memora acest grup. n acest caz, se va mri valoarea pentru
pragul e, folosind o metoda euristic pentru a fuziona cu posibilele grupuri existente. O
cretere a lui e are dou consecine. Prima, clusterele existente vor avea mai multe
nregistrri, din moment ce raza maxim a crescut. A doua, este posibil s fuzioneze grupuri
existente, astfel nct grupul rezultat s fie compact. Astfel, o cretere a lui e conduce, de
obicei, la o reducere a numrului de grupuri existente.

12.6. Cercetarea similitudinii n cadrul secvenelor

O mare parte din datele memorate n baze de date sunt formate din secvene. Se
presupune, de exemplu, c un utilizator specific o secven interogare i vrea s consulte
toate secvenele de date care sunt similare cu secvena interogare. Cutarea de similitudini e
diferit de interogrile normale, de aceea nu prezint interes numai secvenele care se
potrivesc exact cu secvena interogare, dar i de secvenele care se potrivesc parial cu
secvena interogare.
O secven date X este o serie de numere X={x
1
,x
k
}. Uneori, X este numit i
serie de timp. Fie k lungimea secvenei. O subsecven Z={z
1
,.z
k
} este obinut din alt
secven X={x
1
,.,x
k
} tergnd numere de la nceputul i sfritul secvenei X. Formal, Z
este o subsecven a lui x, dac z
1
=x
i
; z
2
=x
i+1
.x
j
=z
i+j-1
unde ie{1,,k-j+1}. Fie date dou
secvene X={x
1
.x
k
} i Y={y
1
y
k
} se poate defini norma euclidiana ca distana dintre cele
dou secvene dup cum urmeaz:
||X-Y||=(x
i
-y
i
)
2

Dat fiind o secven interogare a unui utilizator i parametrul prag e, inta este
obinerea tuturor secvenelor de date care se ncadreaz n distanta e fa de secvena
interogare.
Interogrile referitoare la similitudini n cadrul secvenelor pot fi clasificate n doua
tipuri:
- corespondena complet a secvenelor. Secvena interogare i secvenele din baza de
date au aceeai lungime. Dat fiind pragul e specificat de utilizator, scopul este s se
gseasc toate secvenele din baza de date care se gsesc n cadrul distantei e fa de
secvena interogare.
- corespondena subsecvenelor. Secvena interogare este mai scurt dect secvenele
din baza de date. n acest caz se dorete s se gseasc toate subsecvenele din baza de
date care se afl n cadrul distanei e faa de secvena interogare.

12.6.1. Un algoritm pentru gsirea secvenelor similare

Dat fiind o colecie de secvene de date, o secven interogare i pragul pentru
distana e, se dorete gsirea celui mai eficient mod de a gsi toate secvenele care se afl n
cadrul distanei e fa de secvena interogare.
Capitolul 12
364
O posibilitate ar putea fi parcurgerea bazei de date, consultarea fiecrei secvene de
date, i calcularea distanei pn la secvena interogare. Dei acest algoritm este foarte simplu,
el consult fiecare secven de date.
Deoarece se are n vedere cazul n care secvenele se potrivesc complet, toate
secvenele de date i secvenele interogare au aceeai lungime. Cutarea similitudinilor poate
fi privit ca o problem de indexare de mari dimensiuni. Fiecare secven de date i secvena
interogare pot fi reprezentate ca nite puncte ntr-un spaiu k-dimensional. Astfel, dac
inseram toate secvenele de date ntr-un index multidimensional, putem gsi secvenele de
date care se potrivesc exact cu secvena interogare interognd indexul. Dar din moment ce se
urmrete a se gsi nu numai secvenele care se potrivesc exact secvenei interogare, ci i cele
care se afl pe distana e fa de secvena problem, nu se va folosi o interogare punct, cum
a fost definit n secvena interogare. n loc de aceasta, se va interoga indexul cu un hiper-
dreptunghi care are lungimea 2e i secvena interogare ca centru, i vor fi astfel obinute toate
secvenele care se gsesc n interiorul acestui hiperdreptunghi. Apoi se vor nltura
secvenele care sunt la distan mai mare de e fa de secvena interogare.
Folosirea indexul permite o reducere foarte mare a numrului de secvene luate n
considerare, i astfel scade timpul de evaluare a similitudinilor.

12.7. Perspectivele data mining

Data mining a fost dezvoltat recent ca rezultat al cerinelor diverselor aplicaii Este
interdisciplinar, folosete arii tematice mari: baze de date, inteligena artificial i statistica.
Este o disciplin modern, aflat nc n stadiile iniiale ale dezvoltrii, dar ntr-o evoluie
foarte rapid. Observnd dezvoltarea actual a disciplinei, apar unele probleme. n primul
rnd apare necesar i urgent sistematizarea acesteia, pentru a permite diferitelor probleme
de data mining sa fie vizualizate mpreun. Pn acum acestea au fost considerate separate de
ctre specialiti i gestionate folosind sisteme specifice pentru fiecare problem specific. n
viitorul apropiat este de ateptat definirea unor modele standard pentru formularea
problemelor de data mining i tehnici generale pentru rezolvarea lor.
Este astfel necesar gestionarea unor seturi mari de date. Algoritmii actuali de data mining nu
pot garanta nc o msurare standard n faa unei baze de date foarte mari. Problema poate fi
rezolvat folosind tehnici de eantionare care constau n data mining pe eantioane reduse, dar
semnificative ale bazei de date.
n final, este necesar cunoaterea nivelului pn la care instrumentele de data mining
pot fi independente. n multe cazuri, problemele pot fi rezolvate doar dac se iau n
considerare caracteristicile specifice problemei cnd se propune soluia. n afar de
instrumentele generale de rezolvare, exist de asemenea un mare numr de date specifice
fiecrei probleme. Acestea au avantajul incontestabil de a cunoate domeniul aplicaiei i pot
astfel completa procesul de data mining mai uor, n special n privina interpretrii
rezultatelor; dar sunt mai puin generice i refolosibile.

Baze de date multidimensionale

365

Capitolul 13

Termenul de OLAP a fost folosit prima dat n septembrie 1993 de ctre Codd, n
articolul Providing OLAP (On-line Analytical Processing) to User-Analysts: An IT
Mandate. Dup ce a vzut SGBD-ul multidimensional Essbase (Arbor Software) a ajuns la
concluzia c limbajul SQL nu a fost niciodat adecvat pentru analiza multidimensional a
datelor. El a afirmat c exist o diferen semnificativ ntre bazele de date relaionale i
bazele de date multidimensionale .
n 1995, consiliul OLAP definea conceptul de OLAP ca o categorie de instrumente
software, care permit analitilor, managerilor i directorilor s neleag esena datelor
printr-un acces rapid, consistent i interactiv la o mare varietate de viziuni posibile ale
informaiilor, care au fost obinute prin tranformarea datelor primare astfel nct s reflecte
dimensiunile reale ale ntreprinderii aa cum o percepe i o nelege utilizatorul.
Aa cum indic cuvintele folosite pentru a construi acronimul (on-line, analytic,
processing), rolul sistemelelor OLAP ntr-o organizaie este de a oferi un acces interactiv i
uor la resursele analitice necesare procesului decizional i de conducere. n teoria sistemelor
suport de decizie sunt recunoscute dou tipuri de resurse analitice: datele i modelele.
Instrumentele OLAP sunt utilizate frecvent n sistemele suport de decizie, deoarece
permit analiza interactiv a datelor multidimensionale. Avantajul lor principal este c sunt
apropiate de modul de gndire al analitilor i mbuntesc performana execuiei cererilor. n
consecin, tehnologia bazelor de date multidimensionale a ctigat, n ultima perioad, mult
atenie din partea firmelor productoare i a cercettorilor. Indiferent de tipul de arhitectur
implementat, instrumentele OLAP prezint datele la utilizator ntr-un model de date
multidimensional, iar cererile OLAP sunt formulate utiliznd paradigma multidimensional.
In acest capitol vom prezenta:
- conceptele de baz utilizate n modelarea multidimensional a datelor;
- stadiul actual n stabilirea unui model multidimensional conceptual i formal
standard;
- facilitile analitice oferite de limbajul SQL ;
- avantajele unui mediu integrat relaional-multidimensional, precum i arhitectura
sistemelor OLAP.

13.1. Concepte de baz

Modelarea multidimensional este fundamental pentru bazele de date
multidimensionale, depozitele de date i aplicaiile OLAP, iar modelul de date
multidimensional este apropiat de modul de gndire al analitilor.
Pentru a descrie n detaliu modelele de date multidimensionale i a putea fi nelese,
este necesar a se prezenta o serie de concepte de baz utilizate i anume:
Capitolul 13

366
- hypercubul (cub n-dimensional)
- dimensiunile
- ierarhiile
- msurile
- fenomenul de mprtiere
- multicubul
Aceste concepte apar n majoritatea modelelor multidimensionale propuse, dei modul
lor de definire difer uneori foarte mult. De asemenea, consiliul OLAP a propus un glosar de
termeni care se dorete standardizat. De aceea, n prezentarea acestor concepte de baz s-au
utilizat i definiiile date de Consiliul OLAP.

13.1.1. Conceptul de cub n-dimensional

Conceptul de hypercub sau cub cu mai mult de trei dimensiuni (cub n-dimensional)
sau structur multidimensional este fundamental pentru nelegerea sistemelor OLAP, a
bazelor de date multidimensionale i a modelului multidimensional. Instrumentele OLAP
folosesc conceptul de hypercub n acelai mod n care foile de calcul tabelar folosesc
conceptul de foaie de lucru (worksheet) i bazele de date relaionale conceptul de tabel.
Toate vizualizrile, rapoartele i analizele sunt fcute n termeni de hypercuburi (cuburi n-
dimensionale).
Consiliul OLAP definete hypercubul ca un grup de celule de date aranjate dup
dimensiunile datelor. Dimensiunile tipice ale datelor dintr-o ntreprindere sunt timpul,
produsele, regiunile geografice, canalele de distribuie, etc.
Un cub n-dimensional este de fapt un set de msuri (variabile/indicatori) ce utilizeaz
aceleai dimensiuni de identificare. n figura 13.1 se prezint un exemplu simplificat de
hypercub utilizat n analiza vnzrilor. Acest hypercub are trei dimensiuni: Locaie, Produs i
Timp. n celulele cubului sunt stocate valorile msurii analizate i anume cantitatea vndut.
Valoarea acestui indicator variaz n funcie de produsul vndut, de magazinul care vinde
acest produs i de perioada de timp. Se spune c acest indicator este dimensionat dup
Produs, Locaie i Timp. De exemplu, valoarea 57 reprezint cantitatea vndut n 2003 din
produsul X n magazinul A.

Fig. 13.1. Exemplu de hypercub (cub n-dimensional)

Produs

Produs Y
Produs X

magazin A
Locaie

magazin B

2003 2004 2005
Timp

123

127

211

57

45

56

367
13.1.2. Conceptul de dimensiune
Dimensiunile au urmtoarele caracteristici:
- furnizeaz informaii descriptive despre fiecare msur ;
- sunt eseniale pentru analiz;
- ntr-un cub n-dimensional o dimensiune este reprezentat printr-o ax;
- ntr-o schem stea dimensiunile sunt tabele care se dispun radial n jurul tabelei de
fapte i se mai numesc tabele de dimensiuni (dimension tables).
O dimensiune conine mai muli membri. Un membru este un nume distinct sau un
identificator folosit pentru a determina poziia unui element de dat (n schema stea apare sub
denumirea de atribut dimensional). De exemplu, toate lunile, trimestrele i anii formeaz
dimensiunea Timp. Un membru poate aparine unei ierarhii sau mai multor ierarhii sau poate
s nu fie inclus ntr-o ierarhie (independent). In dimensiunea Produs membru culoare nu
este inclus n nici o ierarhie (figura 13.2).

Fig. 13.2. Un exemplu de cub n-dimensional pentru analiza vnzrilor

De exemplu, un cub n-dimensional pentru analiza vnzrilor poate conine informaii
despre venituri (volumul vnzrilor) i cheltuieli (figura 13.2). Dimensiunile cubului sunt:
Client, Produs i Timp. Atributele acestor dimensiuni pot varia n funcie de specificul firmei
analizate. Ca msuri se pot defini: cantitatea vndut, volumul vnzrilor, costurile bunurilor
vndute, numrul de clieni, etc. Pe baza acestor msuri se pot determina alte msuri (msuri
derivate) cu ajutorul formulelor (de exemplu profitul = volumul vnzrilor-costul bunurilor
vndute).
Granulaia cubului n-dimensional este dat de granulaia dimensiunilor (nivelul de
detaliu al datelor stocate). De exemplu, dimensiunea Produs va stoca informaii despre fiecare
produs vndut. Cu acest model se poate realiza o analiz detaliat a vnzrilor i anume

Timp
luna_id
luna_dsc
trimestru_id
trimestru_dsc
an_id
an_dsc
luna_nrzile
trimestru_nrzile
an_nrzile
data_sfarsit_luna
data_sfarsit_trimestru
data_sfarsit_an
etc

Msuri:
Cantitatea vndut
Volumul vnzrilor
Costurile
Numrul de clieni
.......................
Produs

produs_id
produs_dsc
categorie_id
categorie_dsc
total_produs_id
total_produs_dsc
greutate
culoare
etc
.

Client

client_id
client_dsc
oras_id
oras_dsc
judet_id
judet_dsc
total_clienti_id
total_clienti_dsc
etc

Cubul n-
dimensional pentru
analiza vnzrilor
Capitolul 13

368
volumul total al vnzrilor la nivel de lun, trimestru, an, pe o anumit categorie de produse,
pentru un anumit client, ora, jude, etc.

13.1.3. Conceptul de ierarhie

Cele mai multe dimensiuni au o structur ierarhic. Timpul este o dimensiune
ierarhic (ore, zile, sptmni, luni, trimestre i ani). n cele mai multe activiti ale unei
firme, ierarhiile sunt o necesitate. Ar fi imposibil de a funciona o firm, dac toate datele sale
ar fi limitate la nivel tranzacional. De exemplu, este necesar de a pstra informaii despre
volumul vnzrilor lunare, pe trimestru, pe an, pentru a vedea care produse se vnd mai bine.
Criteriile dup care datele sunt agregate pentru analiz i raportare trebuie s fie aceleai cu
factorii folosii n procesul decizional. n figura 13.3 este prezentat o ierarhie simetric (luna-
trimestru-an) n dimensiunea Timp. Luna Ianuarie (I) este un membru al ierarhiei.
n glosarul de termeni OLAP se specific c membrii dimensiunilor pot fi organizai
pe baza relaiilor de tip printe-copil, unde un membru printe reprezint consolidarea
(agregarea) membrilor copil. Rezultatul este o ierarhie i relaiile printe/copil sunt relaii
ierarhice. De exemplu, trimestrul 1 (trim1) este printe pentru lunile Ianuarie (I), Februarie
(F), Martie (M). n general, un membru poate avea un singur printe. Un membru ce nu are
printe se numete membru radcin (root). n figura 13.3 membru An este rdacina ierarhiei.
Membrii care nu au copii sunt numii frunz. Ierarhiile pot fi simetrice sau asimetrice. De
exemplu, n dimensiunea Timp exist o ierarhie simetric.
ntr-o dimensiune pot exista mai multe ierarhii. Alegerea nivelurilor intermediare de
grupare sau agregare este important pentru nelegerea i abilitatea de a lua decizii, deoarece
datele au numai un nivel de detaliu, un nivel de agregare complet, dar multe niveluri
intermediare.

Fig. 13.3. Dimensiunea Timp cu ierarhie simetric

Dei nu toate dimensiunile conin ierarhii, toate aplicaiile din lumea real implic
dimensiuni ierarhice. Unele instrumente OLAP permit numai o singur ierarhie pe
dimensiune. n acest caz, fiecare ierarhie este tratat ca o dimensiune separat.
Conceptul de nivel ntr-o ierarhie este foarte important pentru a determina ce tipuri de
navigri se pot executa n dimensiuni i ce tipuri de calcule suport dimensiunile.
Combinaia de multiple dimensiuni i multiple niveluri pe dimensiune constituie
esena unui cub n-dimensional sau hypercub.
O celul ntr-un cub n-dimensional este definit de intersecia unui membru din
fiecare dimensiune. Unele celule conin date de intrare cum ar fi vnzrile zilnice, altele
conin date derivate. Valorile datelor derivate sunt definite cu ajutorul formulelor.

an
M
Trim1
Trim2 Trim3 Trim4
I F
A M I I A S O N D

369
Dei majoritatea datelor stocate n cuburile n-dimensionale sunt numerice, orice tip de
date poate fi multidimensional. Multe instrumente OLAP ofer abilitatea de a popula cuburile
n-dimensionale cu date text. Datele numerice sunt mai potrivite pentru aplicaiile OLAP,
deoarece au o organizare multidimensional i se pot agrega. Alte tipuri de date pot beneficia
de organizarea multidimensional, dar apar probleme datorate agregrii lor. Totui cele mai
multe date surs, la nivel de ntreprindere, sunt de tip ir de caractere. Din acest motiv, datele
de tip ir de caractere vor deveni mult mai importante pentru instrumentele OLAP. Date cum
ar fi: culoarea, adresa, tipul de ambalaj, tipul de client sunt factori eseniali pentru analiz.

13.1.4. Conceptul de msur

O msur (variabil) este un indicator de performan prin care se poate analiza
performana activitii modelate. Valorile unui indicator se modific continuu. Pentru fiecare
combinaie posibil ntre dimensiuni, exist sau nu o valoare corespunztoare a indicatorilor.
In cazul schemei stea, o msur este de regul un atribut numeric al tabelei de fapte.
Totui nu orice atribut numeric este un indicator. Dac valoarea atributului numeric variaz
continuu (de exemplu: cantitatea vndut, volumul vnzrilor) atunci atributul este un
indicator.
Indicatorii pot fi clasificai n:
- indicatori de baz (de exemplu: volumul vnzrilor, cantitatea vndut,
costurile,numrul de clieni);
- indicatori derivai care se obin prin combinarea indicatorilor de baz (de exemplu
profitul).
O alt clasificare este dat de Ralph Kimball n cartea sa The Data Warehouse
Toolkit i anume dup posibilitatea indicatorilor de a se nsuma dup dimensiuni:
- indicatori care se pot nsuma dup toate dimensiunile. De exemplu, volumul
vnzrilor se poate calcula pentru o categorie de produse sau pentru o anumit regiune
sau pentru a anumit perioad de timp.
- indicatori care se pot nsuma numai dup unele dimensiuni. De exemplu, numrul de
clieni, deoarece se poate calcula numrul de clieni ntr-o anumit perioad de timp
sau pentru o anumit regiune, dar nu este aditiv dup dimensiunea Produs.
- indicatori care nu se pot nsuma dup nici o dimensiune (de exemplu profitul
marginal).

13.1.5. Conceptul de multicub

ntrebarea care apare este dac se poate aduga un numr nelimitat de dimensiuni la
un cub n-dimensional i dac pentru modelarea unei activiti complexe este suficient un
singur cub n-dimensional.
n multe aplicaii OLAP se utilizeaz date din mai multe domenii de activitate (de
exemplu activitatea financiar i activitatea de marketing sau activitatea de producie i
activitatea de desfacere). n aceste cazuri, se utilizeaz mai multe cuburi n-dimensionale sau
structuri multicub. Prin utilizarea structurii multicub este posibil de a integra seturi de date
eterogene. Problema care apare n proiectarea unei structuri multicub este legat de modul
cum se realizeaz legtura ntre cuburile n-dimensionale.
Datele multidimensionale sunt mprtiate (conceptul de mprtiere este frecvent
asociat cu datele multidimensionale i a fost utilizat cu semnificaia de valoare lips, valoare
Capitolul 13

370
inaplicabil i valoare zero) i celulele de date nu sunt distribuite n mod egal n spaiul
multidimensional. Proiectanii de instrumente OLAP au adoptat o varietate de strategii pentru
a trata fenomenul de mprtiere.
n aplicaiile multicub, proiectanii descompun baza de date multidimensional ntr-un
set de structuri multidimensionale, fiecare fiind compus dintr-un subset de dimensiuni ale
bazei de date. Aceste structuri multidimensionale au diferite denumiri (variabile Oracle
Express, Pilot; structuri Holos; cuburi Microsoft OLAP).

13.2. Modele de date multidimensionale

La ora actual, multe firme utilizeaz i dezvolt propriile modele de date
multidimensionale. De asemenea, diferite comitete de standardizare au definit propriile
modele multidimensionale .
Cercettori din diferite domenii de aplicaii au propus o serie de modele
multidimensionale, dar fiecare model prezint o viziune proprie a cerinelor analizei
multidimensionale, o terminologie i un formalism propriu. Multe dintre modelele
multidimensionale propuse sunt modele logice (de exemplu modelul lui Kimball) i numai
cteva pot fi considerate pur conceptuale i anume: modelul lui Golfarelli (Dimensional-Fact
Model), modelul lui Blaschka (multidimensional/ER (M/ER)) i modelul lui Tryfona (starER).
Modelul lui Golfarelli este un model conceptual propus n special pentru depozite de
date, dar poate fi utilizat i pentru baze de date multidimensionale. Modelul este o colecie de
scheme fapt structurate arborescent, ale cror elemente componente sunt: faptele, atributele,
dimensiunile i ierarhiile.
Modelul M/ER este o extensie a modelului entitate-asociere i :
- ofer un set de operaii OLAP de baz ;
- modeleaz comportamentul sistemului OLAP prin diagramele de stare;
- ofer un cadru pentru generarea automat a schemei logice a bazei de date cu un
instrument OLAP (Informix Metacube i Cognos Powerplay);
- permite reprezentarea ierarhiilor multiple.
Modelul StarER este un model de date conceptual care combin construciile
modelului entitate-asociere cu structura stea. Este singurul model care se refer la asocierile
de tip (m:m) ntre fapte i dimensiuni (prin indicarea cardinalitii). Elementele constructive
ale modelului sunt: faptele, entitile, asocierile ntre entiti i fapte (1:1, 1:m, m:n) i
atributele (proprieti statice ale entitilor, asocierilor sau faptelor).
Nici unul dintre aceste modele nu trateaz msurile derivate ca parte a modelului
conceptual. Modelul lui Golfarelli i modelul starER se refer la aditivitatea msurilor prin
reprezentarea n mod explicit a setului de operatori de agregare ce pot fi aplicai pe msurile
neaditive. De asemenea, toate modelele ofer o notaie grafic.
n tabelul 13.1 s-a realizat o evaluare a modelelor multidimensionale conceptuale
prezentate anterior.
La ora actual nu exist nici un model de date multidimensional conceptual acceptat n
unanimitate. Un astfel de model este totui necesar pentru a servi ca o fundamentare pentru
standardizare i cercetarea viitoare.
Aa cum s-a precizat la nceputul acestui paragraf, multe din modelele
multidimensionale propuse sunt modele logice - extensii ale modelului relaional. Cel mai
cunoscut model multidimensional logic este modelul lui Kimball sau schema stea. n cartea
The Data Warehouse Toolkit, Practical Techniques for Building Dimensional Data

371
Warehouses, Ralph Kimball definete schem stea: o reprezentare intuitiv a cubului de
date n-dimensional ntr-un mediu relaional.

Tabelul 13.1. Analiz comparativ a modelelelor conceptuale
Criterii de evaluare Modele conceptuale
Golfarelli M/ER starER
Modelarea asocierilor (m:m) ntre fapte i
dimensiuni
Nu Nu Da
Modelarea msurilor derivate Nu Nu Nu
Aditivitatea Da Nu Da
Modelarea ierarhiilor multiple Da Da Da
Operaii OLAP de baz Nu Da Nu
Modelarea comportamentului sistemului
OLAP
Nu Da Nu
Notaii grafice Da Da Da
Limbaj de interogare propus algebr algebr nu
Arhitectura implementat ROLAP/MOLAP ROLAP/MOLAP ROLAP
Posibilitatea de generare automat a
schemei logice a bazei de date
Nu Da Nu

Schema stea conine o tabel central i un set de tabele de dimensiuni aranjate ntr-o
manier radial, n jurul tabelei centrale. Fiecare tabel de dimensiuni reprezint o
dimensiune a activitii analizate, n timp ce tabela central reprezint coninutul cubului de
date. Schema este foarte asimetric. Exist o tabel dominant n centrul schemei, singura
tabel din schem cu multiple jonciuni, prin care se conecteaz la celelalte tabele. Aceast
tabel se numete tabela de fapte (fact table). Celelalte tabele au numai o singur jonciune,
prin care se leag la tabela central i se numesc tabele de dimensiuni sau dimensiuni
(dimension table). Schema stea reduce numrul de jonciuni ntre tabele, ca urmare a
procesului de denormalizare. Nu exist nici o informaie despre nivelurile ierarhice stocate n
structura schemei stea. n plus, reprezentarea unei dimensiuni printr-o singur tabel conduce
la date redundante. n mediile cu depozite de date, aceasta nu cauzeaz nici o problem,
deoarece datele sunt n cele mai multe cazuri interogate.
Tabel de fapte are urmtoarele caracteristici:
- conine un numr foarte mare de tupluri (posibil milioane). Numrul de tupluri din
tabel reprezint de fapt produsul cartezian al dimensiunilor.
- dimensiunea ei crete dinamic, n funcie de volumul de date ncrcate la fiecare
ciclu de actualizare a bazei de date, precum i n funcie de volumul de date
istorice stocate n baza de date.
- este tabela care reflect performana activitii analizate.
- cheia primar a tabelei este o cheie compus, format din cheile primare ale
tabelelor de dimensiuni. De exemplu, cheia primar a tabelei de fapte Unit este
format din atributele canal_id, produs_id, client_id, luna_id (figura 13.4). De
asemenea, fiecare din aceste atribute sunt chei externe.
- este normalizat i realizeaz de fapt o legtur indirect ntre dimensiuni.
Capitolul 13

372
In figura 13.4 se prezint un exemplu simplificat de schem stea cu tabela de fapte
Unit. Msura cantitate este stocat n tabela de fapte. Dimensiunile Timp, Produse, Clienti i
Canale sunt legate de tabela de fapte printr-o asociere (1:m). Fiecare dimensiune conine
atribute relevante: numrul de zile din lun (luna_nrzile), numrul de zile din trimestru
(trimestru_nrzile), data_sfrit_luna n dimensiunea Timp.

Fig. 13.4. Un exemplu de schem stea

Se poate observa c exist multe aspecte care nu sunt reflectate de schema stea i
anume:
- nu se pun n eviden ierarhiile definite n dimensiuni (de exemplu ierarhia din
dimensiunea Timp);
- nu se specific dac se pot utiliza toi operatorii de agregare pentru toate msurile
dup toate dimensiunile.
In figura 13.5. se afieaz o parte din tuplurile tabelei de fapte Unit, iar n figura 13.6.
tuplurile tabelei Clienti. Se utilizeaz instrumentul Oracle OLAP Worksheet.
Schema stea include dou tabele de fapte (n figura 13.4 este prezentat o singur
tabel de fapte i anume tabela de fapte Unit) ce conin informaii despre o serie de indicatori
(pre unitar, cost unitar, cantitatea vndut) utilizai n analiza vnzrilor unei firme.
Avantajele schemei stea:
- este uor de construit;
- reflect cu exactitate modul cum neleg utilizatorii activitatea modelat;
- furnizeaz o performan ridicat pentru cereri OLAP, prin reducerea numrului de
jonciuni;
- permite modelarea unor structuri multidimensionale complexe;
- toi indicatorii de performan ai activitii modelate sunt stocai n tabela de fapte.

Dimensiunea Timp
luna_id
luna_dsc
trimestru_id
trimestru_dsc
an_id
an_dsc
luna_nrzile
trimestru_nrzile
an_nrzile
data_sfarsit_luna
data_sfarsit_trimestru
data_sfarsit_an
Tabela de fapte
Unit
luna_id
canal_id
produs_id
client_id
cantitatea
Dimensiunea
Produse
produs_id
produs_dsc
categorie_id
categorie_dsc
total_produs_id
total_produs_dsc
Dimensiunea Clienti
client_id
client_dsc
oras_id
oras_dsc
judet_id
judet_dsc
total_clienti_id
total_clienti_dsc
Dimensiunea Canale
canal_id
canal_dsc
total_canal_id
total_canal_dsc

373

Fig. 13.5. Tuplurile tabelei de fapte Unit

Fig. 13.6. Tuplurile tabelei Clienti

Capitolul 13

374
Dezavantajele schemei stea:
- este o schem inflexibil. Adugarea unei noi dimensiuni n schem, poate duce la
modificarea granulaiei tabelei de fapte;
- conine date redundante ce conduc la creterea riscului de inconsisten a datelor;
- pentru a permite analize complexe, trebuie s includ multe tabele de agregate;
- are o scalabilitate limitat;
- este dificil jonciunea ntre tabelele de fapte.

Schema fulg de zpad este o variant a schemei stea. Este rezultatul descompunerii
unei dimensiuni sau a mai multor dimensiuni care au ierarhii. Relaiile de tip (m:1) ntre
membrii unei dimensiuni se descompun n tabele separate formnd o ierarhie de tabele.
Schema fulg de zpad vizualizeaz structura ierarhic a dimensiunilor. Diferena esenial
fa de schema stea este c dimensiunile sunt normalizate. Principala motivaie a normalizrii
este spaiul de stocare. Dac ierarhiile se pstreaz n tabele separate, se consider c spaiul
de stocare se reduce consistent. Totui Ralph Kimball n lucrarea sa Practical Techniques for
Building Dimensional Data Warehouse ncearc s demonstreze contrariul. El afirm c
eforturile de a normaliza tabelele, n scopul de a reduce spaiul de stocare, sunt inutile i
consumatoare de timp. Normalizarea dimensiunilor reduce cu mai puin de 1% spaiul total de
stocare, iar vizualizarea datelor este mai dificil, implicnd un numr mai mare de jonciuni
ntre tabele. Muli proiectani nu consider c salvarea spaiului ar fi o cerin major n
selectarea tehnicii de modelare.
Avantajele schemei fulg de zpad:
- este mai flexibil i se pot defini cerinele utilizatorilor mult mai bine;
- structura normalizat a dimensiunilor este mai uor de modificat;
- este folosit de multe instrumente OLAP;
- reduce redundana datelor;
- mbuntete performana operaiilor de drill down i roll up.

Dezavantajele schemei fulg de zpad:
- este mai complex dect schema stea;
- scade performana la interogare, deoarece sunt folosite multe jonciuni;
- schema este mai dificil de neles de ctre utilizatori, fiind mai apropiat de
modelul entitate-asociere.

Modelele stea i fulg de zpad, precum i variantele lor au devenit o reprezentare
logic bine cunoscut a structurilor de date multidimensionale, n sistemele relaionale.
Selectarea unei scheme potrivite ine cont de raportul dintre costul de stocare i performana
interogrii. Schema stea ofer performane mai bune la interogare, datorit unui numr mic de
operaii de jonciune ntre tabela de fapte i tabelele de dimensiuni, dar costul de stocare este
mai ridicat. Schema fulg de zpad implic mai multe operaii de jonciune, dar presupune o
capacitate de stocare mai mic. Pentru ambele modele exist o mulime de variante. Schema
stea de zpad (starflake) sau schema fulg de zpad degenerat (degenerated snowflake)
sunt o combinaie de schem stea i schem fulg de zpad, n care o parte a tabelelor de
dimensiuni sunt denormalizate.
n schema constelaie (fact constellation) exist tabele de fapte suplimentare ce
stocheaz date agregate. O constelaie este o colecie de stele i const dintr-o stea central
nconjurat de alte stele. Steaua central conine datele la nivel atomic, iar celelalte stele
conin date agregate. Steaua central se leag de celelalte stele prin atribute dimensionale
(figura 13.7).


375

Fig. 13.7. Schema constelaie

13.3. Utilizarea limbajului SQL pentru cereri OLAP.
Operatorii ROLLUP i CUBE

Cererile analitice (OLAP) sunt cereri formulate adesea de ctre manageri i analiti i
presupun agregarea complex a datelor. Cererile OLAP folosesc date de detaliu i/sau
derivate, istorice i/sau curente, iar natura lor nu este ntotdeauna previzibil. De asemenea,
pot accesa milioane de nregistrri i pot executa o mulime de parcurgeri ale tabelelor,
jonciuni i agregri (n cazul sistemelor ROLAP).
Utilizatorii pot executa urmtoarele operaii OLAP:
- Slice i dice sau selecii n cub. ;
- Drill down / roll up ce utilizeaz ierarhiile din dimensiuni i msurile pentru
agregri sau de-agregri;
- Drill across ce combin mai multe cuburi cu una sau mai multe dimensiuni
comune (jonciunea de cuburi);
- Ranking sau top/bottom n ce permite analize de tip primii n sau ultimii n dup
anumite criterii;
- Pivot sau rotirea unui cub pentru a pune n eviden alte aspecte analitice.
Unele operaii OLAP pot fi executate uor i cu ajutorul limbajului SQL (de exemplu
operaia roll up), altele nu. De exemplu, n tabela Clienti (figura 13.6) exist urmtoarea
ierarhie: client oras judet total_clienti. Se poate utiliza limbajul SQL pentru a agrega
valorile msurii cantitatea la diferite nivele ale acestei ierarhii.
In figura 13.8 se realizeaz o operaie de roll up sau de agregare a msurii cantitatea la
nivelul oras din ierarhie, iar n figura 13.9. se realizeaz o operaie de tip pivot (rotirea
cubului) care permite vizualizarea datelor din cub dup dimensiunea Timp i Produs. S-a
utilizat instrumentul Oracle OLAP Worksheet

Capitolul 13

376

Fig. 13.8. Agregarea msurii Cantitate

Fig. 13.9. Rotirea cubului

377
n 1997, Gray propunea doi operatori CUBE i ROLLUP pentru agregarea complex a
datelor stocate n baze de date relaionale. Limbajul SQL standard 1999/2003 a inclus aceti
operatori. De asemenea, multe SGBDR permit deja aceti operatori (Oracle, SQL Server).
Vom exemplifica modul de utilizare a acestor operatori, utiliznd SGBDR Oracle 10g i
instrumentul SQL*Plus. Se consider tabela Persoane cu urmtoarea structur i tupluri:

SQL> desc persoane

Name Null? Type
---------------------------------------------------------------------
CODP NOT NULL NUMBER(3)
NUME VARCHAR2(30)
FUNCTIA VARCHAR2(3)
AN_PROM VARCHAR2(4)
CODCAT VARCHAR2(7)

SQL> select codp, nume, functia, codcat from persoane;

CODP NUME FUNCTIA CODCAT
------------------------------------------------------------------------------------
1 Muntean Mihaela C IE
2 Ionescu Simona A IE
3 Dumitru Ion P IE
4 Lungu Diana L CIB
5 Marin Ion P CIB
6 Popescu Diana A IE
7 Popescu Ion C CIB

Dac dorim s afim pentru fiecare catedr, numrul de persoane corespunztor
fiecrei funcii, se execut urmtoarea cerere:

SQL> select codcat, functia, count(codp) numar from persoane group by codcat, functia;

CODCAT FUNCTIA NUMAR
----------------------------------------------------
IE A 2
IE C 1
IE P 1
CIB C 1
CIB L 1
CIB P 1

Dac dorim s afim pentru fiecare catedr i numrul de persoane angajate, precum
i numrul total de persoane angajate, vom utiliza operatorul ROLLUP n clauza GROUP BY:

SQL> select codcat, functia, count(codp) numar from persoane
group by rollup(codcat, functia);

Capitolul 13

378
------------------------------------------------
IE A 2
IE C 1
IE P 1
IE 4
CIB C 1
CIB L 1
CIB P 1
CIB 3
7

Operatorul ROLLUP genereaz subtotaluri. Primele trei tupluri sunt identice cu
primele trei tupluri ale cererii ce utilizeaz numai clauza GROUP BY. Al patrulea tuplu este
un subtotal al atributului funcia (apare valoarea null n coloan Funcia). n realitate nu
sunt valori nule n aceast coloan (este un artificiu al operatorului ROLLUP). Urmtoarele
trei tupluri sunt tupluri de detaliu, iar tuplu urmtor este un alt subtotal dup atributul
funcia. Ultimul tuplu este un total general.
Urmtoarea cerere este echivalent cu cererea ce utilizeaz operatorul ROLLUP:

group by codcat, functia
union
select codcat, ' ', count(codp) numar from persoane group by codcat, ' '
union
select ' ', ' ', count(codp) numar from persoane group by ' ', ' ';

--------------------------------------------------
7
CIB 3
CIB C 1
CIB L 1
CIB P 1
IE 4
IE A 2
IE C 1
IE P 1

Citirea acestei cereri este mai dificil. De asemenea, tabela se parcurge de mai multe
ori. Operatorul ROLLUP, mai concis i mai uor de citit, este mai eficient (mai ales pentru
seturi mari de date), deoarece tabela se parcurge o singur dat. Sunt posibile i operaii rollup
pariale:

group by codcat, rollup(functia);

---------------------------------------------------
IE A 2

379
IE C 1
IE P 1
IE 4
CIB C 1
CIB L 1
CIB P 1
CIB 3

n acest caz, nu se produce un total general (total dup toate dimensiunile). Dac n
ROLLUP sunt specificate N atribute, atunci se produc N+1 tipuri de subtotal.

Operatorul CUBE realizeaz toate tipurilor posibile de agregare (totaluri pentru fiecare
combinaie posibil de dimensiuni). Cubul poate fi un cub complet sau un cub parial. Pentru
exemplificare se consider tabela Persoane i se dorete s se afieze :
- pentru fiecare catedr, numrul de persoane corespunztor fiecrei funcii (adic
numrul de profesori, numrul de confereniari, numrul de lectori, numrul de
asisteni i numrul de preparatori pentru fiecare catedr);
- pentru fiecare catedr, numrul de persoane angajate;
- numrul total de persoane corespunztor fiecrei funcii (adic numrul total de
profesori, numrul total de confereniari, numrul total de lectori, numrul total de
asisteni, numrul total de preparatori);
- numrul total de persoane angajate.

group by cube(codcat, functia);

----------------------------------------------------
7
A 2
C 2
L 1
P 2
IE 4
IE A 2
IE C 1
IE P 1
CIB 3
CIB C 1
CIB L 1
CIB P 1

Se poate utiliza funcia GROUPING care face distincie ntre valorile null curente i
cele ce rezult prin agregare, returnnd o valoare 0 pentru primul caz i o valoare 1, cnd este
detectat un subtotal.

SQL> select codcat, functia, count(codp) numar, grouping(codcat) t,
grouping(functia) f from persoane group by cube(codcat, functia);

Capitolul 13

380
CODCAT FUNCTIA NUMAR T F
--------------------------------------------------------------------------
7 1 1
A 2 1 0
C 2 1 0
L 1 1 0
P 2 1 0
IE 4 0 1
IE A 2 0 0
IE C 1 0 0
IE P 1 0 0
CIB 3 0 1
CIB C 1 0 0
CIB L 1 0 0
CIB P 1 0 0

Funcia GROUPING poate fi utilizat, de asemenea, pentru filtrarea tuplurilor:

SQL> select codcat, functia, count(codp) numar, grouping(codcat) t,
grouping(functia) f from persoane group by cube(codcat, functia)
having grouping(codcat)=0 and grouping(functia)=0;

CODCAT FUNCTIA NUMAR T F
--------------------------------------------------------------------------
IE A 2 0 0
IE C 1 0 0
IE P 1 0 0
CIB C 1 0 0
CIB L 1 0 0
CIB P 1 0 0

Se pot realiza agregri complexe care presupun utilizarea operatorilor ROLLUP i
CUBE cu mai multe atribute de grupare. De exemplu se utilizeaz operatorul CUBE cu trei
atribute: codcat, funcia i an_prom.

SQL> select codcat, functia, an_prom an, count(codp) numar from persoane
group by codcat, functia, an_prom;

CODCAT FUNCTIA AN NUMAR
----------------------------------------------------------
IE A 2005 1
IE C 2004 1
IE P 2000 2
CIB A 2005 1
CIB L 2004 1
CIB P 2005 1

SQL> select codcat,functia, an_prom an, count(codp) numar from persoane
group by cube(codcat, functia, an_prom);


381

------------------------------------------------------------------
7
2000 2
2004 2
2005 3
A 2
A 2005 2
C 1
C 2004 1
L 1
L 2004 1
P 3
P 2000 2
P 2005 1
IE 4
IE 2000 2
IE 2004 1
IE 2005 1
IE A 1
IE A 2005 1
IE C 1
IE C 2004 1
IE P 2
IE P 2000 2
CIB 3
CIB 2004 1
CIB 2005 2
CIB A 1
CIB A 2005 1
CIB L 1
CIB L 2004 1
CIB P 1
CIB P 2005 1

Clauza GROUPING SETS permite definirea de grupuri multiple ntr-o singur cerere.
Pentru fiecare grup definit, Oracle realizeaz toate tipurile de agregri, apoi combin
rezultatele utiliznd operatorul UNION ALL n mod implicit. Se realizeaz astfel o agregare
mai eficient a datelor, precum i o analiz mai complex a datelor:

group by grouping sets
((codcat, functia, an_prom), (codcat, an_prom), (functia, an_prom));

-------------------------------------------------------------
IE P 2000 2
IE C 2004 1
IE A 2005 1
Capitolul 13

382
CIB L 2004 1
CIB A 2005 1
CIB P 2005 1
IE 2000 2
IE 2004 1
IE 2005 1
CIB 2004 1
CIB 2005 2
A 2005 2
C 2004 1
L 2004 1
P 2000 2
P 2005 1

O alternativ ineficient este exemplul urmtor:

group by codcat, functia, an_prom
union all
select codcat,null, an_prom an, count(codp) numar from persoane
group by codcat, an_prom
union all
select null, functia, an_prom an, count(codp) numar from persoane
group by functia, an_prom;

Operatorul CUBE(a,b,c) este echivalent cu clauza GROUPING SETS((a,b,c), (a,b),
(a,c), (b,c), (a), (b), (c), ()). Operatorul ROLLUP(a,b,c) este echivalent cu clauza GROUPING
SETS ((a,b,c), (a,b), (a), ())
Operatorul CUBE se utilizeaz n special pentru a realiza agregri complexe a datelor
relaionale i a stoca apoi aceste agregate n baze de date multidimensionale.

13.4. Integrarea tehnologiei relaionale cu tehnologia
multidimensional

n pagina Web a firmei IBM, conceptul de Business Intelligence (inteligena afacerii-
BI) este definit astfel: BI nseamn utilizarea tuturor datelor de care dispune o firm, pentru
a mbunti procesul decizional. BI presupune accesul la date, analiza lor i descoperirea de
noi oportuniti de utilizare a lor.
Principalele obiective ale unui sistem BI sunt:
- s permit soluii cu costuri sczute ce ofer avantaje firmei;
- s permit acces rapid i uor la informaiile firmei pentru un numr mare i variat
de utilizatori;
- s ofere suport pentru tehnologiile moderne (tehnici de analiz complexe-
instrumente OLAP, instrumente de tip data mining, etc);
- s ofere un mediu de operare deschis i scalabil.
La ora actual exist o gam variat de produse software pentru a dezvolta soluii BI:

383
Instrumentele de raportare. Cele mai multe organizaii utilizeaz instrumente de
raportare nu foarte complexe pentru a accesa datele stocate n depozitele de date. Aplicaiile
BI construite cu astfel de instrumente:
- furnizeaz rapoarte statice sau parametrizate destinate unui numr mare de
utilizatori din organizaie;
- ofer puine faciliti analitice;
- utilizeaz de regul baze de date relaionale (depozite de date/centre de date) i
limbajul SQL.

Instrumentele de analiz i interogare ad-hoc. Aplicaiile BI construite cu astfel de
instrumente:
- permit un nivel ridicat de interaciune cu utilizatorul (tehnici de navigare i selecie
a datelor);
- utilizeaz de regul baze de date relaionale i limbajul SQL;
- ofer unele faciliti analitice;
- utilizeaz adesea ca model de date multidimensional logic schema stea sau fulg de
zpad;

Instrumentele OLAP (de analiz multidimensional). Instrumentele OLAP utilizeaz
tehnici analitice simple (analiza multidimensional a datelor) pentru a analiza seturi mari de
date. Cele mai multe aplicaii BI construite cu instrumente OLAP (de exemplu pentru: analiza
costurilor, analiza profitului, analiza vnzrilor, analize de marketing, etc) utilizeaz baze de
date multidimensionale ce permit cereri complexe (de exemplu Care a fost procentul de
cretere a volumului vnzrilor anul acesta fa de anul trecut, pentru fiecare din primele 10
produse vndute?). Utilizarea bazelor de date multidimensionale este costisitoare i sunt
destinate de regul managerilor i analitilor (deci unui numr restrns de utilizatori).

Aplicaiile ce utilizeaz instrumente de planificare (de exemplu aplicaii de analiz
financiar i de planificare a bugetului la nivelul organizaiilor) sunt foarte diferite de
aplicaiile ce utilizeaz instrumente de interogare i raportare, deoarece ele genereaz noi date
utiliznd modele pentru previziuni, scenarii de tip what-if, etc. Aceste aplicaii permit
utilizatorilor: s analizeze performanele anterioare i s rspund la ntrebri cum ar fi: Care
produse sunt cele mai profitabile?, s modeleze efectele fluctaiilor valutei asupra
veniturilor, costurilor i profitabilitii, s stabileasc bugete alternative i planuri de investiii,
etc.
La ora actual exist dou tendine n aplicaiile BI:
O corelare ct mai bun ntre activitatea de analiz i cea de planificare. Aplicaiile
BI trebuie:
- s furnizeze acces rapid unui numr mare de utilizatori, distribuii geografic, la un
stoc de date centralizat;
- s permite agregarea complex a datelor;
- s utilizeze facilitile oferite de Internet. Existena unui catalog de metadate
centralizat i a unui stoc de date centralizat poate s le ofere utilizatorilor o viziune
comun asupra datelor. Toi utilizatorii trebuie s acceseze acelai model de date i
aceleai date.
Convergena aplicaiilor BI cu aplicaiile operaionale (tranzacionale). Activitile
operaionale i cele de analiz constituie nucleul activitii unei firme, independent de
mrimea ei, domeniul de activitate, forma legal. Informaiile despre vnzri, producie i
costuri pot fi nregistrate i gestionate n una sau mai multe baze de date, folosite pentru
scopuri operaionale. Activitile operaionale se execut la un interval relativ constant. Datele
Capitolul 13

384
sunt citite i actualizate frecvent i reprezint o fotografie curent a ceea ce se ntmpl n
firm. Fiecare cerere folosete un volum mic de informaii, iar natura ei este n general
previzibil.
Monitorizarea, evaluarea, compararea, planificarea i alocarea strategic a resurselor
sunt exemple de activiti de analiz. Informaia generat prin activitile de analiz este
orientat pe decizie, deoarece este ntr-o form ce o face imediat utilizabil n procesul
decizional. Orientarea spre decizie a analizei este esenial. Datele sunt mai mult citite dect
actualizate n aceste activiti. Cererile analitice folosesc date derivate i natura lor nu este
ntotdeauna previzibil. Ca urmare a acestor diferene, majoritatea firmelor folosesc
instrumente diferite pentru cele dou tipuri de activiti. Astfel:
- se asigur eficien maxim n ambele activiti;
- se realizeaz o actualizare rapid n activitile tranzacionale i calcul rapid n
activitile de analiz.
De asemenea, aplicaiile analitice pot utiliza pentru stocarea datelor fie baze de date
relaionale (depozit de date/centru de date) sau baze de date specializate (de regul
multidimensionale). Stocarea datelor se face ntr-o baz de date relaional atunci cnd:
- volumul de date este prea mare pentru a fi duplicat;
- datele surs se modific frecvent i este mai bine de a citi n timp real dect din
copii;
- se dorete integrarea cu alte sisteme informatice relaionale existente;
- organizaia are o politic de neduplicare a datelor, pentru securitate sau alte
motive,
chiar dac aceasta conduce la aplicaii mai puin eficiente.
De asemenea, depozitele de date pot fi accesate de o mare varietate de instrumente de
raportare i interogare ce utilizeaz limbajul SQL. Totui limbajul SQL nu ofer faciliti
analitice complexe.
La ora actual exist trei soluii pentru a aduga SGBDR-urilor faciliti analitice
complexe:
- integrarea procesrii multidimensionale n sistemul de gestiune a bazei de date
relaionale, fie prin extinderea limbajului SQL (de exemplu operatorii ROLLUP i
CUBE) sau prin adugarea funcionalitii multidimensionale n nucleul SGBD-
ului (de exemplu Oracle 10g cu opiunea OLAP);
- executarea n mai muli pai a comenzilor SQL (multipass SQL). Instrumentul
OLAP realizeaz o serie de comenzi SELECT, n care ieirile comenzilor
anterioare sunt stocate n tabele temporale, care sunt apoi utilizate de comenzile
urmtoare;
- ncrcarea datelor relevante din tabelele corespunztoare pe un server de aplicaie
intermediar, unde este realizat procesarea multidimensional.

Bazele de date multidimensionale ofer faciliti analitice complexe, o performan
mai bun la interogare, dar ntreinerea unei astfel de baze de date este costisitoare. O baz de
date multidimensional cere replicarea datelor, un proces costisitor care poate cauza i o
ntrziere semnificativ n utilizarea datelor de ctre analiti. De asemenea, se cere modelarea
separat a datelor (modelarea multidimensional) i multe baze de date multidimensionale nu
ofer facilitatea de recuperare a erorilor i alte faciliti specifice bazelor de date relaionale.
SGBDMD cer antecalcularea tuturor agregatelor posibile, astfel sunt adesea mai performante
dect SGBDR tradiionale, dar mai dificil de actualizat i administrat. Deoarece, bazele de
date multidimensionale folosesc acelai motor att pentru stocare ct i pentru procesarea
datelor i acest motor are informaii complete despre structurile de date multidimensionale i
manipulrile multidimensionale, este uor pentru instrument de a manipula datele

385
multidimensionale i de a face calcule corecte i complexe. Stocarea fizic a datelor
multidimensionale, precum i fenomenul de mprtiere sunt preocupri majore, n domeniul
bazelor de date multidimensionale. O tehnic de stocare a datelor optim ar trebui s in cont
de muli factori dinamici i anume:
- profilul datelor i volumul lor (numrul de dimensiuni i numrul de membrii ai
dimensiunilor, tipurile de date),
- fenomenul de mprtiere,
- frecvena de modificare a surselor de date (ct de des vor fi actualizate bazele de
date multidimensionale),
- frecvena de modificare a datelor multidimensionale (de exemplu pentru analiza de
tip what if),
- frecvena de modificare a modelului multidimensional, accesul concurent, etc.

Utilizarea separat a celor dou tehnologii implic:
- dou baze de date (baza de date relaional i baza de date multidimensional) ce
trebuie gestionate separat;
- dicionare de metadate separate;
- modele de securitate separate pentru BDR i BDMD;
- instrumente de administrare separate;
- mai mult personal pentru administrare ;
- o interfa OLAP API special proiectat pentru a accesa baza de date
multidimensional;
- replicarea datelor din baza de date relaional n baza de date multidimensional;
- actualizarea datelor n dou etape mai nti depozitul de date, apoi baza de date
multidimensional. Acest proces este consumator de resurse i timp. De asemenea,
crete perioada de timp dintre momentul actualizrii surselor de date i momentul
actualizrii bazei de date multidimensionale;

Din perspectiva unui administrator de baz de date:
- se utilizeaz trei tehnologii diferite (instrumentul de integrare a datelor, tehnologia
relaional i tehnologia OLAP),
- trebuie gestionate trei dicionare de metadate
- i exist dou stocuri de date (depozitul de date relaional i baza de date
multidimensional).

De exemplu, aplicaiile BI construite cu produse Oracle (anterioare versiunilor 9i i
10g) utilizau:
- Oracle Express Server/Oracle Personal Express, un server OLAP (datele sunt
stocate ntr-o baz de date multidimensional);
- Oracle Express Administrator un utilitar grafic pentru definirea, ntreinerea i
popularea bazelor de date multidimensionale Express;
- Oracle Express Relational Access Manager (RAM) care permite ca instrumentul
Express Analyzer s acceseze datele stocate ntr-o baz de date relaional
(configurat cu instrumentul Relational Access Administrator-RAA);
- Oracle Warehouse Builder pentru a crea depozitul de date i pentru a se ncrca
date n depozitul de date. Oracle Warehouse Builder include i instrumentele ETL
(instrumente de extragere, transformare i ncrcare a datelor) (figura 13.10.) .
n 1972 funciile analitice i facilitile de gestiune a datelor au fost integrate ntr-un
limbaj, limbajul Express, destinat pentru aplicaii de marketing. Dup 30 de ani, limbajul
Express rmne una din principalele tehnologii OLAP folosite, conceptele i modelul de date
Capitolul 13

386
fiind neschimbate. n 1995 Oracle achiziioneaz Express, iar n 2002 lanseaz Oracle9i
Release 2 OLAP care integreaz toate facilitile OLAP n baza de date relaional Oracle.

Fig. 13.10. Utilizarea tehnologiei relaionale separat de tehnologia OLAP

Oracle Express este un pachet software de tip sistem de gestiune a bazelor de date
multidimensionale (SGBDMD) cu urmtoarele caracteristici:
- ofer un limbaj de manipulare a datelor foarte puternic;
- utilizeaz un model de date multidimensional;
- utilizeaz o arhitectur client/server (Oracle Express Server)

Arhitectura pe componente a SGBDMD-ului Oracle Express este format din (figura
13.11.):
- Nucleul care include limbajul Express;
- Utilitare pentru administrare (Express Instance Manager, Express Administrator
i Relational Access Manager). Aplicaiile OLAP dezvoltate cu Oracle Express
pot accesa direct date stocate n baze de date relaionale (depozite de date) cu
ajutorul lui Relational Access Manager (RAM). Express Instance Manager este un
utilitar orientat Java ce utilizeaz comunicaii CORBA i care gestioneaz i
configureaz servicii i sesiuni de lucru. Fiecare instan Express Server este un
serviciu ce permite utilizatorilor acces la bazele de date multidimensionale sau
aplicaii prin interfee de tip SNAPI (Structured n-dimensional Application
Programming Interface), XCA (Express Communications Architectures) sau
Express Web Agent. De asemenea, Express Instance Manager permite
modificarea parametrilor de configurare a instanelor Express.
- Instrumente de dezvoltare. Oracle Express Analyzer este un instrument OLAP care
permite utilizatorilor s selecteze, afieze i analizeze datele stocate n baza de date
multidimensional. Oracle Express Objects este un instrument OLAP ce permite
crearea de aplicaii OLAP i briefing-uri complexe care pot fi rulate i n Express
Analyzer, precum i realizarea de programe n limbaj Express, prin care se
controleaz comportamentul aplicaiei. Aplicaiile OLAP dezvoltate cu Oracle
Express Objects acceseaz datele stocate n baze de date multidimensionale sau
baze de date relaionale.

Elementele componente ale unei baze de date Express sunt (figura 13.12.):
Achiziie de date Acces la date
Baza de date Express

Surse externe

Surse de date operaionale

Depozitul de date

Instrumente
ETL
Express
Administrator

Relational Access
Administrator
Express
Analyzer
Express Relational
Access Manager
Express Objects

387
- Variabilele. O variabil este un obiect al bazei de date Express ce stocheaz date, o
matrice multidimensional ale crei celule stocheaz date. Tipul de dat al unei
variabile indic datele pe care le conine. Fiecare variabil este organizat sau
dimensionat dup una sau mai multe dimensiuni (max 32 de dimensiuni). Nu este
necesar ca toate variabilele s aib aceeai dimensionalitate (s utilizeze acelai set
de dimensiuni).
- Dimensiunile. Primele obiecte care trebuie create ntr-o baz de date Express sunt
dimensiunile. Se pot defini trei tipuri de dimensiuni: Timp (valorile reprezint
perioade de timp), Text (valorile sunt descrieri ale entitilor pe care le reprezint)
i INTEGER (valorile sunt identificate prin poziiile lor numerice. O dimensiune
de tip integer este o secven de numere ce ncepe cu 1). O dimensiune ce conine
valori la toate nivelurile de agregare este cunoscut ca dimensiune cu totaluri
incluse (embedded total dimension).
- Relaiile. O relaie descrie corespondena ntre valorile unei dimensiuni i valorile
altei dimensiuni din baza de date. Se pot utiliza relaiile i pentru a defini ierarhiile
n dimensiuni.
- Formulele. O formul este un obiect al bazei de date Express ce definete o
expresie. Valorile formulei sunt calculate ori de cte ori este apelat formula.
Termenul de msur este folosit pentru a referi variabilele, formulele i relaiile.
- Obiectele compuse (composite). Un obiect compus este o dimensiune artificial ce
combin valorile a dou dimensiuni mprtiate.
- Modelele. Un model stocheaz un set de ecuaii interdependente, care utilizeaz
valorile unor variabile sau a unor dimensiuni. Modelele sunt folosite atunci cnd
calculele sunt complexe sau variabilele nu sunt aditive.
- Programele. Un program conine secvene de comenzi ale limbajului Express ce
manipuleaz datele multidimensionale.

Fig. 13.11. Arhitectura pe componente a lui Oracle Express

Oracle Express Administrator se utilizeaz pentru a crea i administra baze de date
Express. Pentru a crea o baz de date multidimensional se parcurg urmtorii pai:
- definirea dimensiunilor bazei de date;

Nucleul (limbajul Express)
Instrumente de dezvoltare
Express
Objects
Express
Analyzer
Express Web
Publisher
Utilitare pentru administrare
Express Instance
Manager
Express
Administrator

BDR (depozite
de date)
BDMD
fiiere
Relational
Access Manager
Financial
Analyzer
Sales
Analyzer
Capitolul 13

388
- definirea msurilor (variabile, relaii, formule);
- definirea seturilor de valori;
- definirea programelor i a modelelor de analiz;

Fig. 13.12. Elementele componente ale unei baze de date Express

Fig. 13.13. Un exemplu de baz de date Express

389
n figura 13.13. se prezint un exemplu simplificat de baz de date Express. n figura
13.14 se prezint un exemplu de aplicaie OLAP construit cu ajutorul instrumentului Oracle
Express Analyzer. Aplicaia permite utilizatorilor:
- s execute cu uurin operaii OLAP ;
- s vizualizeze ierarhiile din dimensiuni;
- s vizualizeze datele analizate sub form grafic i tabular, etc

Fig. 13.14. Exemplu de aplicaie OLAP construit cu ajutorul instrumentului Oracle Express
Analyzer

13.4.1. Avantajele unui mediu integrat relaional
multidimensional

Integrarea tehnologiei relaionale cu tehnologia OLAP permite realizarea de aplicaii
cu o funcionalitate ridicat, mai puin costisitoare i care ofer un suport adecvat att pentru
activitatea de analiz ct i pentru activitile operaionale.
Va exista un singur stoc de date i un singur dicionar de metadate. De asemenea,
trebuie implementat o singur politic de securitate. De exemplu Oracle 10g cu opiunea
OLAP realizeaz integrarea tehnologiei relaionale cu tehnologia OLAP. Oracle 10g utilizeaz
baza de date relaional att pentru aplicaii operaionale ct i pentru aplicaii analitice.
Datele necesare analizelor sunt valabile 24 de ore din 24.
Opiunea OLAP include un motor de calcul multidimensional ce permite analize foarte
complexe pe datele stocate n spaiul analitic i are la baz tehnologia Express. Datele stocate
n spaiile analitice sunt manipulate cu ajutorul limbajului de manipulare OLAP (OLAP
DML). Acest limbaj este echivalentul multidimensional al limbajului PL/SQL i extinde
facilitile analitice ale limbajului SQL. Include funcii pentru analiza seriilor de timp (de
Capitolul 13

390
exemplu funcia LAG()), funcii financiare, funcii statistice, o mare varietate de metode de
agregare (dup nivelul din ierarhie, dup anumii membrii, etc)
Datele pot fi stocate n tabele (tabele de fapte i tabele de dimensiuni) sub form de
schem stea sau fulg de zpad sau n variabilele din spaiul analitic, iar utilizatorii pot accesa
datele printr-o interfa OLAP (de exemplu instrumentul Oracle BI Beans ) sau cu ajutorul
limbajului SQL (de exemplu instrumentul Oracle BI Discoverer)
Spaiul analitic (analytic workspace-AW) :
- conine un numr de obiecte multidimensionale (dimensiuni, ierarhii, msuri) i
poate fi gndit ca o schem multidimensional;
- aparine unui utilizator i ali utilizatori pot avea acces la el;
ntr-o baz de date Oracle se pot crea mai multe spaii de lucru analitice;
Un spaiu analitic n format standard este un spaiu analitic construit cu un set specific
de obiecte cum ar fi dimensiuni ierarhice, asocieri de tip printe, asocieri de tip nivel. Fiecare
obiect trebuie s fie definit cu un set de proprieti ce identific rolul obiectului i asocierile
lui cu alte obiecte din spaiu analitic.

Analytic Workspace Manager (AWM) este un instrument de administrare utilizat
pentru:
- a crea spaii analitice n format standard ce pot fi accesate de aplicaiile construite
cu Oracle BI Discoverer, Oracle BI Spreadsheet Add-In, Oracle BI Beans. n
figura 13.15 este prezentat un spaiu analitic n format standard creat cu AWM i
care are denumirea GLOBAL.
- a actualiza spaiile analitice;
- a crea i executa planuri pentru agregarea datelor;
- a crea msuri derivate;
Un utilizator care cunoate cerinele analitice i are acces la sursele de date poate
construi un spaiu analitic cu AWM, parcurgnd urmtorii pai:
- Definirea modelului multidimensional logic. Trebuie definite dimensiunile,
nivelele, ierarhiile, cuburile i msurile. In figura 13.16 se vizualizeaz nivelele
ierarhice ale dimensiunii Clienti, iar n figura 13.17 ierarhia din dimensiunea
Clienti.
- Maparea modelului multidimensional logic la sursele de date. Sursele de date pot
fi tabele (tabele de fapte i tabele de dimensiuni sub form de schem stea) sau
tabele virtuale. De exemplu, n figura 13.18 este prezentat maparea nivelelor
ierarhice din dimensiunea Client la atributele corespunztoare ale tabelei Clienti.
- Incrcarea datelor. Dup ce modelul multidimensional a fost definit i mapat,
datele pot fi ncrcate i agregate n spaiul analitic .
- Analiza datelor. Datele din spaiul analitic pot fi vizualizate utiliznd AWM
(figura 13.19) i analizate utiliznd instrumentele Oracle Discoverer Plus OLAP,
Oracle BI Spreadsheet Add-Inn sau aplicaii construite cu Oracle BI Beans. De
exemplu, instrumentul Oracle BI Spreadsheet Add-Inn care apare ca submeniu n
Excel (figura 13.20), le ofer utilizatorilor posibilitatea de a utiliza interfaa de tip
foaie de calcul tabelar pentru cereri ad-hoc, n timp ce gestiunea i securitatea
datelor este realizat de SGBD Oracle. Dup conectarea la sursa de date OLAP
(spaiul analitic) se deschide automat opiunea Oracle OLAP Query Wizard care
permite utilizatorilor s creeze cereri analitice (cereri OLAP). Se pot selecta
msurile, dimensiunile incluse n cerere i membrii din fiecare dimensiune. De
asemenea, se pot defini msuri derivate. De exemplu, n figura 13.21 sunt afiai
membrii selectai din dimensiunea Produse, n figura 13.22 o cererea OLAP foarte
simpl n mediul Excel, iar n figura 13.23 modul de definire a unei msuri

391
derivate i anume modificarea procentual a volumului vnzrilor curente fa de
volumul vnzrilor dintr-o perioada anterioar de timp.

Fig. 13.15. Spaiul analitic Global creat cu AWM

Fig. 13.16. Definirea nivelelor ierarhice dintr-o dimensiune

Capitolul 13

392

Fig. 13.17. Definirea ierarhiilor

Fig. 13.18. Maparea modelului multidimensional la sursele de date


393

Fig. 13.19. Vizualizarea datelor din cub

Fig. 13.20. Instrumentul Oracle BI Spreadsheet Add-In

Capitolul 13

394

Fig. 13.21. Crearea unei cereri OLAP

Fig. 13.22. Afiarea unei cereri OLAP n mediul Excel

395

Fig. 13.23. Definirea unei msuri derivate

13.5. Arhitectura sistemelor OLAP

Sistemele OLAP permit analitilor i managerilor s mbunteasc performanele
unei firme, printr-un acces interactiv rapid la o mare varietate de viziuni de date organizate,
pentru a reflecta aspectul multidimensional al datelor dintr-o ntreprindere. Cele mai multe
aplicaii OLAP sunt foarte mprtiate.
n general mai puin de o celul dintr-o mie de celule are date. Deoarece aplicaiile
OLAP sunt de fapt sisteme suport de decizie interactive, este important ca ele s rmn
rapide, chiar dac baza de date este mare i mprtiat. Se urmrete s se consume mai puin
spaiu fizic pentru stocarea informaiilor lips sau a indecilor. Exist multe soluii, fiecare cu
avantaje i dezavantaje.
Factorii care determin alegerea unei soluii sunt :
- Volumul de date curente stocat;
- Gradul de mprtiere a datelor. Dac datele sunt foarte mprtiate, poate fi
necesar o indexare mai complex i compresia datelor, care vor face instrumentul
mai lent;
- Frecvena de actualizare a datelor i modul cum se face actualizarea;
- Numrul de utilizatori;
- Tipul arhitecturii client/server (unde are loc procesarea multidimensional);
- Frecvena de modificare a dimensiunilor bazei de date, etc.
innd cont de aceti factori, proiectanii de instrumente OLAP selecteaz tehnicile pe
care le vor utiliza pentru a stoca i gestiona datele multidimensionale, pentru aceste aplicaii.
Astfel, nici un instrument nu este optim pentru orice aplicaie OLAP. Toate instrumentele
Capitolul 13

396
folosesc o combinaie de tehnici. Prima decizie ce trebuie luat este de a stabili unde sunt
stocate datele din model, cnd sunt procesate i accesate.
n ultimii ani, un numr mare de instrumente OLAP permit stocarea datelor att n
baze de date relaionale ct i multidimensionale. Astfel, modul de stocare a datelor a devenit
un criteriu de clasificare a sistemelor OLAP i anume n: sisteme ROLAP, sisteme MOLAP i
sisteme HOLAP.

13.5.1. Sisteme ROLAP

n ultimii ani, un numr mare de instrumente OLAP permit stocarea datelor
multidimensionale n baze de date relaionale (depozite de date). Chiar dac o aplicaie OLAP
stocheaz toate datele sale ntr-o baz de date relaional, totui ea va lucra separat, pe o copie
separat a datelor (depozite de date/centre de date), nu pe baza de date tranzacional,
utiliznd schema stea sau fulg de zpad. Problema este de a oferi acces rapid i flexibilitate
n manipularea multidimensional. Dac sunt multe variabile, exist posibilitatea de a nu le
putea stoca pe toate ntr-o singur tabel de fapte (gradul de mprtiere poate diferi mult ntre
grupurile de variabile). Datele pot fi ncrcate din multiple surse, astfel actualizrile unei
singure tabela de fapte foarte mare sunt ineficiente. De aceea, n aplicaiile complexe, tabela
de fapte este partiionat n grupuri de variabile dup gradul de mprtiere, stabilindu-se, de
asemenea, dimensiunile corespunztoare i sursele de date. n aplicaiile OLAP complexe pot
exista 10..20 de tabele de fapte. Pentru o bun performan la interogare, unele agregri
trebuie antecalculate i stocate n tabele de agregate. n aplicaiile complexe pot exista mii de
tabele de agregate.
Eficiena la interogare este factorul dominat asupra performanei globale i a
scalabilitii sistemului ROLAP. Strategiile de optimizare sunt factorii principali n
diferenierea sistemelor ROLAP existente. ntruct optimizatorul de cereri al SGBDR ar putea
s nu fie capabil s aleag planul de execuie optim pentru cereri, unele instrumente (de
exemplu DSS Server/Microstrategy) mpart cererea complex n mai multe subcereri, care
sunt executate secvenial (SQL n mai muli pai).

Un sistem OLAP va utiliza o baz de date relaional atunci cnd:
- Volumul de date este prea mare pentru a fi duplicat. Datele atomice nu sunt
copiate n baza de date multidimensional, ci sunt stocate n baze de date
relaionale surs (depozite de date/centre de date) i citite atunci cnd este nevoie;
- Datele surs se modific frecvent i este mai bine de a citi n timp real dect din
copii;
- Se dorete integrarea cu alte sisteme informatice relaionale existente;
- Firma are o politic de neduplicare a datelor, pentru securitate sau alte motive,
chiar dac aceasta conduce la aplicaii mai puin eficiente;

Volatilitatea descrie gradul la care datele i structurile de date se modific n timp.
Datele cu un nivel de volatilitate sczut rmn relativ constante. De exemplu, datele despre
timp au un nivel sczut de volatilitate (zilele sunt grupate ntotdeauna n luni i lunile sunt
ntotdeauna grupate n ani). Datele despre produse, clieni se modific frecvent. Volatilitatea
datelor afecteaz cerinele de procesare ale sistemului. Ori de cte ori datele atomice se
modific, datele agregate, ce au fost antecalculate, trebuie s fie recalculate. De aceea, datele
volatile au un impact mai mare asupra unui sistem, care conine un volum mare de informaii
agregate, dect asupra unui sistem care calculeaz valorile agregate la momentul execuiei.
Att sistemele ROLAP ct i cele MOLAP sunt optime pentru aplicaii cu volatilitate sczut

397
a datelor. Pentru aplicaiile cu volatilitate ridicat a datelor, numai sistemele ROLAP sunt
optime.

13.5.2. Sisteme MOLAP

Sistemele MOLAP ofer o viziune multidimensional direct a datelor, n timp ce
sistemele ROLAP sunt o interfa multidimensional la datele relaionale. SGBDMD cer
antecalcularea tuturor agregatelor posibile, astfel sunt adesea mai performante dect SGBDR
tradiionale, dar mai dificil de actualizat i administrat.
Sistemele MOLAP sunt limitate la 5-10 dimensiuni i sunt adecvate pentru aplicaii cu
volume mici de date i dimensionalitate limitat.
Sistemele MOLAP nu au nc o tehnologie pentru stocarea i gestionarea datelor
unanim acceptat. Stocarea fizic a datelor multidimensionale, precum i fenomenul de
mprtiere sunt preocupri majore, n domeniul bazelor de date multidimensionale.
O alt problem este transferul conceptului de tranzacie aa cum este cunoscut i
acceptat n lumea relaional la SGBDMD. Multe instrumente MOLAP au o noiune foarte
vag a conceptului de tranzacie. Sunt i alte probleme importante, deja rezolvate n SGBDR,
dar care sunt nerezolvate sau numai parial rezolvate n SGBDMD cum ar fi: restaurarea bazei
de date, conceptul de tabel virtual, etc.
Puine instrumente MOLAP (de exemplu Arbor Essbase ) permit acces multiutilizator
concurent att la citire ct i la scriere. Majoritatea instrumentelor MOLAP permit acces
multiutilizator la citire i monoutilizator la scriere. SGBDMD blocheaz ntreaga baz de date
n timpul actualizrilor (o form foarte simpl de acces concurent).
Tabelul 13.2 prezint o analiz comparativ ntre sistemele ROLAP i sistemele
MOLAP.

Tabelul 13.2. Analiz comparativ ntre sistemele ROLAP i MOLAP
Criterii MOLAP/Baze de date
multidimensionale
ROLAP/Baze de date relaionale
Spaiul de disc ocupat mare, dac agregatele sunt
antecalculate (explozia
datelor derivate i
fenomenul de mprtiere)
posibil zero, dac sunt folosite
baze de date existente
nemodificate (depozite de date
virtuale), dar poate fi mare dac
noi structuri sunt create
Performana la ncrcarea
datelor
moderat sczut
Viteza de calcul mare mic
Volumul datelor atomice mediu la mare (Mb-Gb) extrem de mare (Gb-Tb)
Posibilitatea de acces la
date de ctre alte aplicaii
(integrare cu alte sisteme
existente)
limitat excelent n principiu, dar poate fi
limitat dac este folosit o
schem complex
Dimensionalitate mic (modele
multidimensionale simple,
5-10 dimensiuni)
mare (modele multidimensionale
complexe)
Modificarea
dimensiunilor
Bun, dar baza de date
trebuie s fie off-line
bun
Capitolul 13

398
Volatilitatea datelor adecvate pentru volatilitate
sczut
adecvate pentru volatilitate
ridicat
Faciliti de administrare
a SGBD-ului
puine foarte puternice
Uurina de a construi
aplicaii de ctre
utilizatorii finali
moderat aproape imposibil
Arhitectura client/server pe dou sau
trei niveluri, lipsa
standardelor
client/server pe dou sau trei
niveluri, arhitectur deschis,
standarde
Managementul
metadatelor
nu da
Limbaj de interogare specific fiecrui instrument SQL
Faciliti de calcul foarte complexe, n toate
dimensiunile
limitate
Tipul aplicaiilor la nivel departamental la nivelul ntreprinderii

13.5.3. Sisteme hibride (HOLAP)

Un sistem OLAP hibrid (HOLAP) este un sistem care utilizeaz pentru stocarea
datelor att baze de date relaionale ct i baze de date multidimensionale. Sunt diferite
arhitecturi pentru un sistem hibrid OLAP:
- integrarea sistemelor MOLAP i ROLAP printr-o interfa comun. Clientul OLAP
poate fi luat n considerare ntr-o astfel de soluie, ntruct ofer o interfa comun
pentru SGBDMD i SGBDR.
- integrarea mutual a sistemelor ROLAP i MOLAP. Aceasta arhitectur poate fi gsit
la Arbor Essbase, Oracle.
- extensii la SGBDR sau SGBDOR prin utilizarea tehnologiei datablade (de exemplu
Informix cu opiunea Metacube). Totui acesta nu este un sistem OLAP hibrid
(Metacube este un ROLAP, deci nu este nc implicat un SGBDMD).

Baze de date spaiale

399

Capitolul 14

Evoluia tot mai rapid a performanelor sistemului de calcul a determinat
diversificarea tipurilor de date asociate atributelor unei entiti stocate ntr-o baz de date.
Astfel, multe aplicaii utilizeaz date spaiale; dintre acestea cele mai sugestive sunt cele din
clasele:
- sistemelor informatice geografice (GIS);
- proiectrii asistate de calculator;
- multimedia;
- toate avnd n comun faptul c stocheaz i manipuleaz date spaiale.

14.1. Tipuri de date spaiale

Data spaial este un termen utilizat pentru a descrie datele care aparin spaiului
ocupat de obiectele unei baze de date. In sens larg, datele spaiale pot fi: puncte, linii,
poligoane, suprafee, volume (date avnd mai multe dimensiuni).
Punctul este caracterizat prin locaia sa, nu ocup spaiu i nu are asociat o arie sau
un volum. Intr-o baz de date punctul se stocheaz printr-o msur direct a lui sau printr-o
msur indirect (transformare). Data de tip raster este un exemplu de folosire a msurii
directe a unui punct i include harta de pixeli (imaginea bitmap). De exemplu, o imagine
preluat din satelit realizeaz o coresponden direct ntre un pixel de imagine i suprafaa
acoperit de el pe suprafaa terestr.
Linia se caracterizeaz prin existena a dou puncte (cel de nceput i cel de sfrit)
urmnd ca punctele intermediare s fie generate prin ecuaia dreptei. Un obiect spaial este
descris, de obicei, printr-o colecie de segmente ca de exemplu cursul unui ru sau un drum.
O dat spaial de tip regiune se caracterizeaz printr-o locaie i un contur. Locaia
este dat de un punct fix pentru a ancora regiunea n spaiu (de obicei este punctul din centrul
regiunii). In spaiul bidimensional, conturul se vizualizeaz ca o linie iar n spaiul
tridimensional ca o suprafa. Data de tip regiune stocat ntr-o baz de date este o
aproximare geometric a unui obiect spaial (de exemplu, judeele unei ri, lacurile etc).
Datele spaiale sunt frecvent puse n corelaie cu atribute convenionale (date
nonspaiale). De exemplu, un jude se descrie spaial printr-un poligon (regiune) dar i
nonspaial prin nume, suprafa, numr de localiti, populaie etc. Atributele spaiale ca i
cele nespaiale apar i la nivelul conceptual. Astfel, valoarea unui atribut spaial este comun
tuturor atributelor nespaiale dintr-un tuplu. Tuplurile unei tabele care conine un atribut
spaial pot fi vizualizate att geometric (spaial) ct i n mod clasic, relaional (tabelar).
Pentru exemplificare, s presupunem c tabela judee stocheaz judeele Romniei
descrise printr-un atribut spaial de tip poligon (suprafa) i prin atribute nonspaiale:
Capitolul 14

400
simbolul judeului, numele i reedina lui. In figura 14.1 se vizualizeaz tuplurile n form
geometric n timp ce, n figura 14.2, aceeai tabel se vizualizeaz tabelar.

Fig. 14.1. Vizualizarea spaial a tabelei judee

Fig. 14.2. Vizualizarea tabelar a relaiei judee


401
O problem important a sistemului de gestiune a bazelor de date spaiale o constitue
efectuarea legturii dintre datele spaiale ce sunt stocate n structuri de date specifice, cu restul
datelor nespaiale.
Dou legturi sunt menionate ntre aceste tipuri de date care caracterizeaz un anumit
obiect: legturi nainte i napoi. Acestea definesc termenul de relaie spaial.
Legtura nainte (figura 14.3a) este utilizat la accesarea informaiilor spaiale ale
unui obiect, pornind de la informaiile lui nespaiale.
Legtura napoi (figura 14.3b) folosete la regsirea informaiei nespaiale a unui
obiect pornind de la informaia lui spaial.
Deoarece structurile de date spaiale conin toate informaiile necesare pentru a
identifica un obiect, legtura nainte poate folosi o valoare reprezentativ a unui obiect, astfel
ca el s fie selectat n mod unic.
De exemplu, pentru regiunile care nu se suprapun, un element de legtur nainte l
poate constitui un punct din respectiva regiune. Informaiile nespaiale aferente unui obiect se
pstreaz n mod normal ntr-un tuplu al relaiei respective. Legtura napoi poate fi realizat
prin intermediul identificatorului tuplului respectiv.
Menionnd aceste legturi ntre prile spaiale i nespaiale ale unui set de obiecte, se
faciliteaz buna desfurare a procesului de interogare.
Modelul orientat obiect poate fi de asemenea utilizat ca fundament pentru bazele de
date spaiale. Aceast metodologie permite o mai bun structurare a informaiilor, prin
introducerea conceptelor de clas i motenire. ncapsularea datelor i suprancrcarea
funciilor faciliteaz manipularea datelor i fac ca reprezentarea fizic i logic a datelor s fie
independente, una n raport cu cealalt. In cazul bazelor de date spaiale, concepte precum:
clasa, motenire, ncapsulare, tip i metod sunt uor de utilizat. Diferitele tipuri spaiale de
date pot fi implementate ca nite clase cu posibiliti de a fi motenite, construind subclase.

Date nespaiale pentru Regiunea 5
Structuri de date spaiale Atribute nespaiale
Regiunea 5
Regiunea 4 Regiunea 3
Regiunea 2
Regiunea 1
( a )

Capitolul 14

402

Structuri de date spaiale Atribute nespaiale
Regiunea 5
Regiunea 4 Regiunea 3
Regiunea 2
Regiunea 1
( b )
Fig. 14.3 Tipuri de legturi: nainte (a) i napoi (b)

Astfel, datele spaiale pot fi modelate la dou niveluri: hart i geometric. O baz de
date spaial conine un set de hri, unde o hart este o relaie care are cel puin un atribut
spaial. Operaiile cu o hart sunt implementate ca metode ale obiectelor ce aparin hrii.
Nivelul geometric corespunde atributelor spaiale care sunt reprezentate prin tipuri de date
geometrice, ca de exemplu: puncte, linii, poligoane etc.

14.2. Structuri de date pentru reprezentarea i
indexarea datelor spaiale

Dup cum a fost prezentat n paragraful anterior, datele spaiale sunt stocate n
structuri de date spaiale. Dintre acestea, un loc important l ocup cele ierarhice care sunt
bazate pe principiul descompunerii recursive. Avantajele acestor tipuri de structuri rezult din
faptul c sunt compacte, depind de natura datelor i permit realizarea operaiilor de interogare
n mod eficient. O astfel de structur de date este quadtree i are la baz principiul
descompunerii recursive, similar metodei divide-and-conquer. Ea se poate utiliza la descrierea
mai multor elemente aparinnd clasei datelor spaiale ca de exemplu: puncte, linii, poligoane
etc.
O dat spaial ce exprim o regiune poate fi reprezentat fie prin interiorul ei, fie prin
conturul ei. Se presupune, n descrierea procesului de construire a arborelui, plecnd de la o
imagine, c o regiune este reprezentat de interiorul ei (figura 14.4).
Structura quadtree se bazeaz pe subdivizarea succesiv a unei imagini n patru
cadrane de mrimi egale. Dac un cadran nu conine numai valoarea 1 sau numai valoarea 0,
el va fi din nou subdivizat n patru cadrane i aa mai departe pn sunt obinute cadrane ce au
fie valoarea 1 fie 0. Valorile 1 respectiv 0 semnific faptul c zona aparine sau nu regiunii
respective. Pentru exemplificare se va considera imaginea din figura 14.4a i reprezintarea ei
binar (bitmap) n figura 14.4b. Prin mprirea succesiv n cadrane, figura 14.5a se observ
c zonele astfel obinute (cadranele) fie aparin regiunii fie nu. De exemplu, dac regiunea

403
este omogen din punct de vedere a culorii atunci cadranele care acoper regiunea trebuie s
aib aceeai culore.

(a) imagine (b) reprezentarea binar
Fig. 14.4. Reprezentarea binar a unei imagini

I IV

II III

(a)
Descompunerea unei imagini n cadrane

Niveluri
3 O
I II III IV
2 O O O

1 O O O O O O O O

0 O O O O O O O O O O

(b)
Quadtree

Fig. 14.5. Descompunerea imaginii

Cadranele obinute n urma procesului de divizare a spaiului se pot reprezenta prin
intermediul unui arbore numit quadtree. Structura quadtree este n esen un arbore oarecare
ce conine noduri avnd semnificaiile:
- rdcina corespunde imaginii n ansamblu;
- nodurile frunz corespund acelor blocuri pentru care nu mai sunt necesare
subdivizri; blocurile fie aparin regiunii (1) fie sunt n afara ei (0);
- celelalte noduri reprezint cte un cadran al regiunii care a necesitat o subdivizare.
Pentru orice nod ce nu este frunz, fiii lui corespund cadranelor n ordinea NE (I), SE
(II), SV (III), NV (IV).
0 0 0 1 1 0 0 0
0 0 0 1 1 0 0 0
0 0 0 1 1 0 0 0
0 0 0 1 1 1 1 0
1 1 1 1 0 0 0 0
1 1 1 1 0 0 0 0
1 1 1 1 0 0 0 0
1 1 1 1 0 0 0 0

Capitolul 14

404
Structura quadtree poate fi diferit n funcie de:
- Tipul de dat pe care o reprezint i care poate fi: punctul, linia, curba, suprafaa i
regiunea.
- Principiul care st la baza procesului de descompunere care se poate face n pri
egale la fiecare nivel (descompunere regulat) sau n m pri de mrimi diferite n
funcie de data iniial;
- Rezoluia descompunerii care poate fi variabil
Aceast structur poate fi de asemenea utilizat la reprezentarea imaginilor n trei sau
mai multe dimensiuni. Varianta cu trei dimensiuni se numete octree.
Modelul de construire a acestui arbore presupune ca imaginea s fie ncadrat ntr-un
cub care va fi recursiv subdivizat n 8 cuburi egale i aa mai departe pn cnd sunt obinute
regiuni uniforme din punct de vedere a culorii ori se ajunge la un anumit nivel predefinit de
descompuneri.
Dezvoltarea unei structuri ierarhice este avantajoas deoarece se poate folosi la
procesele de interogare a datelor spaiale dar i pentru c se economisete spaiul de memorie
necesar reprezentrii unor astfel de date.
Reprezentarea original a structurii quadtree a fost aceea de arbore care utiliza
pointeri. In acest fel, spaiul de memorie consumat este destul de mare, de aceea s-au propus,
pentru a mbunti acest variant, dou modaliti.
Prima trateaz imaginea ca pe o colecie de noduri frunz, unde fiecare nod este
reprezentat printr-o pereche de numere. Exist un numr n baza 4, numit codul locaiei, care
corespunde secvenei direcionale ce localizeaz frunza i stabilete astfel calea de la rdcin
i un numr ce indic adncimea la care nodul frunz este regsit.
A doua modalitate reprezint imaginea n forma unei traversri a structurii quadtree.
Ea este foarte compact dar nu este uor de folosit cnd se dorete accesul aleator la un anumit
nod.
Reprezentarea punctelor se face n funcie de operaiile care urmeaz s se execute cu
aceste date. Dintre multiplele moduri de reprezentare a punctelor, adecvat este structura de
date PR quadtree (P pentru puncte i R pentru regiuni), deci o adaptare a structurii quadtree la
tipuri bine precizate de date spaiale. Aceast structur se bazeaz pe o descompunere regulat
care urmrete asocierea unui punct cu un cadran. Procesul de construire este similar cu cel al
structurii quadtree, diferena este c nodurile frunz fie nu conin nimic, fie conin puncte prin
valorile coordonatelor lor. In figura 14.6 se poate observa corespondena dintre puncte i
cadrane care st la baza construirii arborescenei.
Dezavantajul metodei const n faptul c, dac punctele sunt foarte apropiate, atunci
nivelul maxim de descompunere poate fi foarte mare. Avantajul este c structura devine
atractiv n cazul n care prelucrarea datelor spaiale implic operaii de cutare. Un exemplu
tipic de folosire a arborelui l constituie determinarea oraelor din nord-estul rii. Oraele vor
fi cutate n regiunile care compun cadranul NE al imaginii (Suceava i Iai), lucru uor de
realizat avnd n vedere modul de construire a structurii quadtree.
In concluzie, se poate spune c structura quadtree este dinamic n sensul c poate fi
adaptat cu uurin la mai multe tipuri de date spaiale.
Pentru manipularea datelor spaiale este nevoie ca acestea s fie reprezentate n
diferite forme. O modalitate const n a utiliza structuri de date bazate pe ocuparea spaial a
datelor. Aceast metod presupune descompunerea spaiului n regiuni numite partiii. De
aceea, metoda este cunoscut sub numele de metoda partiionrii. Partiionarea datelor
spaiale se bazeaz pe conceptul minimizrii ariei ocupate de partiie. In acest caz, obiectele
spaiale sunt grupate n ierarhii i apoi ele sunt stocate n alte structuri de date. Structurile de
indexare a datelor spaiale multidimensionale au la baz dou abordri:

405
- prima se bazeaz pe observaia c data spaial ocup un subspaiu a spaiului
multidimensional;
- cea de-a doua se bazeaz pe faptul c data fiind multidimensional, un numr mic
de dimensiuni stocheaz majoritatea informaiei.

Suceava
-

- Iai
Sebe
- - Braov
- Timioara
-
-Bucureti
-
Mangalia
Nvodari
(100,100)
(100,0) (0,0)
(0,100)
Fig. 14.6. Descompunerea n cadrane a imaginii
pentru construirea structurii PR quadtree

Structura arborescent R (Rectangle tree), face parte din prima categorie i este
similar ca reprezentare i mod de exploatare cu arborele B. Ea are mai multe variante
proiectate n scopul organizrii unei colecii de date spaiale prin reprezentarea lor n
dreptunghiuri n dimensionale. Fiecare nod n arbore corespunde celui mai mic dreptunghi n
dimensional care include fii lui. Nodurile frunz conin pointeri ce refer datele spaiale din
baza de date. Obiectele sunt reprezentate prin cele mai mici dreptunghiuri care le conin.
Arborele R este aplicat unei tabele cu tupluri reprezentnd date spaiale, fiecare tuplu
avnd un unic identificator care poate fi utilizat la regsirea lui.
Arborele R conine noduri frunz de forma ( I, iid ),
unde:
I - un dreptunghi n dimensional ce reprezint o cutie ce mrginete obiectul
indexat;
iid - identificatorul tuplului i se refer la nregistrarea din tabel ce conine
obiectul mrginit de I.
I = ( I
0
, I
1, - - -,
I
n-1
),
unde:
n - numrul de dimensiuni;
I
i
- un interval nchis [a, b] ce precizeaz extinderea obiectului pe dimensiunea i.
Astfel, I
i
poate avea una sau ambele limite egale cu indicnd faptul c obiectul se extinde la
.
Nodurile ce nu sunt frunze n arborele R au urmtoarea form: ( I, pfiu),
unde:
pfiu - adresa nodului mai mic n arborele R;
I - un dreptunghi ce acoper toate dreptunghiurile din intrarea nodurilor mai
mici.
Se presupune c un nod conine maxim M elemente iar ms M/2 este un parametru ce
specific numrul minim de elemente dintr-un nod. Un arbore are proprietatea c un nod
trebuie s conin ntre m i M elemente dac el nu este rdcin. Ca exemplu, se consider
colecia de segmente dat n figura 14.7.
Capitolul 14

406

Fig. 14.7. Colecie de segmente
a
e
d
g
i
f
c
b
h

n figura 14.8 se prezint arborele R asociat coleciei de segmente din figura 14.7,
nodurile avnd capacitatea de maxim dou elemente. Se poate observa n figura 14.8a modul
de partiionare a spaiului n vederea ncadrrii obiectelor spaiale i relaia de incluziune
dintre partiii, iar n figura 14.8b este descris aceeai relaie de partiionare i includere prin
intermediul structurii arborescente R.
Din figura 14.8 reiese c, din partiionarea spaiului nu rezult regiuni disjuncte. Zona
de intersecie reprezint procentul din volum care este acoperit de mai mult de un dreptunghi.
Dac un nod al unui arbore R conine n dreptunghiuri {R
1
,...,R
n
}, zona de intersecie poate fi
definit formal ca n relaia 14.1.
) 1 . 14 (
) (
e intersecti de Zona
} ,..., 1 {
i
n i
j i
j i n}, {1,..., j i,
R
R R
e
= e
=
unde, || A|| - indic volumul acoperit de A.

Un alt concept legat de intersecia suprafeelor este greutatea interseciei care
reprezint procentul de obiecte care aparin poriunii de intersecie din spaiu.
) 2 . 14 (
} / {
)} ( / {
ei intersecti Greutatea
} ,..., 1 {
}, ,..., 1 { ,
i
n i
j i
j i n j i
R p p
R R p p
e
= e
e
e
=
unde:
- |A| , indic numrul de obiecte coninute n A;
- p, obiect spaial.

O dat spaial se asociaz cu un singur dreptunghi, de exemplu, n figura 14.8,
segmentul i este asociat dreptunghiului R5 cu toate c i partiiile R1, R2 i R4 partajeaz o
suprafa din R5. In aceste condiii dac se dorete s se determine care obiect este asociat cu
un punct particular vor fi necesare mai multe cutri n baza de date datorit faptului c acel
punct poate fi coninut n mai multe partiii.
Algoritmii de cutare, inserare i tergere sunt construii folosind aceleai principii
utilizate la implementarea structurii arborescente B
+
. Informaiile ce se manipuleaz se refer
la marcarea dreptunghiului r, la cheia tuplului, respectiv la pointerul la subarborele
corespunztor.

407

Fig. 14.8. Arborele R
d
g
i
f
c
b h
a
R3
R4
R5
e
R6
R1
R2
(a)
R1 R2
R3 R4 R5 R6
a b d g h c i e f
(b)

O problem dificil innd cont de particularitatea datelor spaiale este aceea a
divizrii nodului. Fiind dat o pagin ce conine M elemente este necesar s se divid colecia
de M+1 elemente ntre dou noduri.
Divizarea unui nod S={r
1
,...,r
n
} n dou subnoduri S
1
={r
i1
,...,r
is1
} i S
2
={r
i2
,...,r
is2
},
(S
1
=C i S
2
=C) este definit ca:
Diviz(S)={ (S
1
,S
2
) / S=S
1
S
2
.S
1
S
2
=C }.
In urma procesului de divizare a nodului pot apare cazurile:
- zon de intersecie minimal, dac || r(S
1
) r(S
2
) || este minim;
- zon de intersecie inexistent, dac || r(S
1
) r(S
2
) || = 0;
- echilibru dac -c s |S
1
| |S
2
| s c.
Deoarece decizia de a vizita un nod depinde dac dreptunghiul aferent lui include zona
cutat, rezult c aria total de acoperire a celor dou dreptunghiuri dup divizare trebuie s
fie minim.
Comparnd figurile 14.9 a i b se realizeaz o mai bun ncadrare avnd n vedere
criteriul enunat n figura 14.9a.
In literatura de specialitate sunt prezentai mai muli algoritmi ce realizeaz acest lucru
avnd performane diferite.
Algoritmul de divizare Quadratic este recunoscut datorit eficienei sale i distribuie
un set de M+1 elemente ntre dou noduri.

Capitolul 14

408

Fig. 14.9 Incadrarea zonelor de acoperire
a b

n primul pas se vor alege dou elemente din cele M+1 ce vor fi puse, cte unul, n
cele dou noduri. In acest sens, se va calcula ineficiena gruprii pentru toate elementele.
Astfel, pentru fiecare pereche r
i
, r
j
, se compune un dreptunghi R incluznd ariile r
i
, r
j
. Se
calculeaz:
d = aria (R) - aria (r
i
) - aria(r
j
) i se alege n final perechea pentru care rezult cea mai mare
valoare d.
n al doilea pas se controleaz dac toate elementele au fost distribuite la cele dou
noduri. In caz afirmativ algoritmul se oprete. Altfel, dac un nod are puine elemente, restul
rmase nedistribuite vor fi asignate la el pentru a avea numrul minim m i n acest caz
algoritmul se oprete.
n al treilea pas se selecteaz urmtorul element pentru a fi asignat la unul dintre
noduri. Pentru fiecare element rmas r se calculeaz d
1
aria mrit necesar pentru includerea
dreptunghiurilor elementelor din primul nod plus zona dat prin r. Se calculeaz d
2
similar
pentru elementele nodului al doilea. Se gsete astfel elementul cu cea mai mare preferin
pentru un grup. Se alege acela pentru care diferena ntre d
1
i d
2
este maxim. Acesta se va
aduga la grupul al crui dreptunghi acoperitor va trebui s fie cel mai puin mrit pentru a
cuprinde elementul. Legtura se rezolv i prin adugarea elementelor la nodul cu o arie mai
mic de cuprindere sau la unul cu mai puine intrri. Apoi se continu cu pasul doi.
Acest algoritm nu garanteaz gsirea celui mai mic dreptunghi posibil de ncadrare dar
performanele lui sunt destul de bune lund n considerare necesarul de timp de prelucrare
pentru obinerea rezultatului.
Partiionarea spaiului n partiii disjuncte a dus la crearea unei structuri derivate din
arborele R i anume R
+
. Deoarece regiunile sunt disjuncte, nseamn c pot fi obiecte care nu
se ncadreaz doar ntr-o singur partiie. De aceea, ele se vor descompune n subobiecte,
fiecare aparinnd unor regiuni diferite. Devine, astfel, important s se determine partiiile
care conin o anumit dat spaial.
n figura 14.10 se prezint un arbore tip R
+
pentru aceeai colecie de segmente
(prezentat n figura 14.7). Se observ c fiecare obiect este asociat cu toate partiiile care-l
intersecteaz deci, pot fi mai multe ci de la rdcin pn la unul i acelai obiect. De
exemplu, n figura 14.10 segmentele c i f apar n dou noduri diferite, n timp ce segmentul i
apare n trei noduri.
n literatura de specialitate s-a demonstrat c structurile de indexare bazate pe arbori R
nu sunt adecvate pentru date spaiale reprezentate ntr-un spaiu multidimensional.
O structur performant de indexare a datelor spaiale multidimensionale cu numr
mare de dimensiuni este arborele X (eXtended node tree). Structura arborelui X este
prezentat n figura 14.11.
Se observ c el conine trei tipuri de noduri:
- noduri de date care sunt la nivelul frunzelor i fac legtura cu datele spaiale care
se indexeaz;

409
- noduri directoare normale ce au rol n a dirija cutarea prin arbore i sunt similare
nodurilor interne dintr-un arbore R; i
- supernoduri care sunt n fapt noduri directoare de mrime variabil.

Fig. 14.10. Arborele R
+
d
g
i
f
c
b
h
a
R5
e
R2
(a)
R1 R2
R3 R4 R5 R6
c a b e i f c i f
(b)
d g h i
R3
R4
R6
R1

Scopul principal al acestor supernoduri este s evite divizarea nodurilor directoare,
care ar avea ca rezultat construirea unei structuri ierarhice ineficiente. Arborele X este diferit
de arborele R cu noduri de dimensiuni mari prin faptul c el conine noduri de dimensiuni mai
mari doar dac este necesar. Supernodurile sunt create n timpul inserrii cnd capacitatea
unui nod trebuie depit i nu se poate evita acest lucru prin alte procedee.
Pentru un arbore X sunt dou cazuri extreme:
- nici un nod director nu este supernod;
- exist doar un singur supernod ce formeaz rdcina arborelui, n rest sunt doar
noduri de date.
n primul caz, arborele X are o organizare complet ierarhic a nodurilor directoare i
este similar unui arbore R. In al doilea caz, supernodul rdcin corespunde nivelului celui
mai de jos din ierarhia nodurilor directoare ale unui arbore R. Performanele unui astfel de
arbore depinde de viteza de prelucrare secvenial a supernodului.

14.3. Exploatarea datelor spaiale

ntr-o baz de date spaial, dac operaia efectuat implic un atribut spaial atunci ea
se numete operaie spaial. Astfel, dac se realizeaz reuniunea a dou judee atunci operaia
de reuniune este considerat ca fiind spaial. Manipularea datelor dintr-o baz de date se
bazeaz pe utilizarea operatorilor. De aceea, trebuie menionat tipul de baz de date spaial
Capitolul 14

410
utilizat care poate fi relaional sau orientat obiect iar n strns legtur cu tipul bazei de
date se va preciza i sistemul de gestiune folosit pentru exploatarea ei.

- nod director normal
- supernod
- nod de date
Fig. 14.11. Structura unui arbore X

Unul dintre cele mai cunoscute sisteme de gestiune a bazelor de date spaiale este
ArcGIS creat de ESRI. Acest pachet software a fost dezvoltat mai mult ca o interfa grafic
pentru achiziia i prelucrarea datelor spaiale dintr-o baz de date relaional. ArcGIS nu este
propriu-zis un sistem de gestiune a bazelor de date pentru c el nu are un format propriu de
organizare a bazei de date ci utilizeaz formatele altor sisteme de gestiune a bazelor de date
relaionale cunoscute, cum ar fi: Access, ORACLE, Microsoft SQL Server, Dynamic Server
Informix. El manipuleaz i date spaiale stocate independent de o baz de date de exemplu,
n format shp, memorate ntr-un fiier de sine stttor.
n denumirea software-lui apare i GIS ceea ce sugereaz c este folosit pentru a
implementa sisteme informatice geografice, adic n principal lucru cu hri digitale. Aceste
sisteme au o larg aplicabilitate, principalele domenii de utilizare sunt:
- pentru gestiunea elementelor ce in de mediul nconjurtor (zone protejate, resurse de
ap, culturi, managementul deeurilor, dispersia noxelor n teritoriu etc.);
- pentru gestiunea reelelor de: transport, conducte, cabluri electrice etc;
- pentru rezolvarea problemelor de amplasare de obiective cum ar fi: staii de emisie /
recepie, gropi de gunoi, staii de epurare etc;
- pentru prezentarea informaiilor meteorologice;
- pentru gestiunea cadastral a teritoriului.

ntr-o baz de date spaial, datele spaiale se memoreaz astfel nct o tabel s
conin o caracteristic spaial de acelai tip. De exemplu, tabela judete stocheaz judeele
Romniei iar caracteristica spaial este de tip poligon. Din punct de vedere vizual, n ArcGIS,
datele spaiale sunt prezentate prin straturi tematice (layers). In figura 14.12 se prezint harta
Romniei prin intermediul a dou staturi tematice (drumuri i judee).
Judeele au fost etichetate cu simbolurile utilizate la numerele de nmatriculare a
autovehiculelor.


411

Fig. 14.12. Harta Romniei reprezentat prin dou straturi tematice

Operaia de selecie a datelor spaiale se poate realiza n dou moduri:
- condiia este format pe baza atributelor nonspaiale; astfel se consider tabela
drumuri care conine trei perechi de atribute nonspaiale care identific un drum
prin tipul i numele lui. O poriune dintr-un drum poate fi n acelai timp i drum
naional ct i european iar unele poriuni dintr-un drum european poate avea mai
multe nume n acelai timp (de exemplu, E85 i E81). Dac se dorete selectarea
din tabela drumuri a drumului european E85 atunci comada este:

select * from drumuri where ([TIP2]= 'E' AND [NUME2] ='E85' ) OR ( [TIP3] = 'E'
AND [NUME3] = 'E85')

Dup execuia acestei comenzi, pe hart, drumul european E85 va fi marcat n mod
distinct dup cum se poate observa n figura 14.13.

- condiia implic cel puin un atribut spaial; pentru a determina prin ce judee trece
drumul european E85 se va defini urmtoarea interogare, vizual, utiliznd forma
din figura 14.14.
Se observ c se selecteaz atribute spaiale din relaia judete care intersecteaz
caracteristicile selectate din relaia spaial drumuri. In urma execuiei rezult harta ca n
figura 14.15, adic se observ c judeele prin care trece drumul european E85 au fost i ele
selectate.

Capitolul 14

412

Fig. 14.13. Selecia drumului european E85

Fig. 14.14. Form de interogare spaial

Rezultatul seleciei se poate concretiza ntr-o tabel distinct sau se poate construi un
nou strat tematic. n figura 14.16 se observ c s-a construit stratul tematic Jud_E85 format
din judeele selectate n urma operaiei de selecie spaial adic acele judee prin care trece
drumul european E85

413

Fig. 14.15. Selecie prin localizarea datelor spaiale

Fig. 14.16. Strat tematic format din selecie

O alt operaie relaional cu relevan pentru datele spaiale este cea de reuniune. Prin
aceast operaie se urmrete obinerea unui nou strat tematic constituit din uniunea mai
multor date spaiale. De exemplu, dac se dorete obinerea unei date spaiale corespunztoare
regiunii Nord-Est, ea se poate obine prin reuniunea judeelor care formeaz regiunea.
Produsul software conine o component specializat, numit AcrToolbox pentru efectuarea
de geoprocesri (procesarea datelor spaiale). Fiind definit n sistem deschis, el ofer
Capitolul 14

414
utilizatorilor posibilitatea de a-i defini propriile instrumente de lucru, acestea fiind construite
prin crearea de noi modele i stocate n componenta AcrToolbox. Modelul ajut utilizatorul
s-i defineasc o operaie spaial complex ca o succesiune de operaii elementare, eventual
parametrizabil ca s poat fi folosit n diferite contexte de lucru.
Operaia de formare a regiunii prin reuniunea judeelor ce o formeaz necesit
efectuarea mai multor pai:
- selectarea judeelor care formeaz regiunea;
- reuniunea lor;
- agregarea poligoanelor obinute prin reuniune pentru a rezulta o singur
caracteristic spaial.
Parametrizarea modelului se face n scopul de a oferi mai mult generalitate operaiei
spaiale, n acest caz, ca parametri s-au considerat:
- caracteristica spaial din care se vor selecta elementele care vor intra n operaia
de reuniune;
- expresia de selecie care va fi asociat clauzei where a frazei select.

Fig. 14.17 Componenta ArcToolbox

Fig. 14.18. Contextul de lucru pentru efectuarea operaiei de reuniune

Pentru definirea modelului de utilizator a fost adugat un nou Toolbox cu denumirea
Regiune, iar n cadrul lui s-a creat un model denumit constr_regiune, dup cum se poate

415
observa n figura 14.17. Modelele se definesc i se execut ntr-un context de lucru
(Workspace), care n exemplul nostru este format din harta Romniei descris prin judee ca
n figura 14.18.
Definirea unui model se face vizual prin construirea unei diagrame de flux care indic
succesiunea operaiilor elementare care trebuie realizate pentru a se ajunge la rezultatul final.
Obinerea regiunii presupune definirea modelului ca n figura 14.19.

Fig. 14.19 Descrierea modelului pentru obinerea unei regiuni

In cadrul modelului, o operaie elementar se figureaz ca n figura 14.20.

date de
intrare
rezultat
operaie elementar
Fig. 14.20 Structura de baz a modelului

Din figura 14.19 se observ c operaia de selecie primete dou intrri figurate cu
litera P ceea ce nseamn c ele pot fi parametrizate, adic utilizatorul poate furniza alte date
de intrare cnd ruleaz modelul. Prin selecie se urmrete ca din toate tuplurile unei tabele
spaiale s se pstreze doar cele care vor participa la operaia de reuniune. Operaia de selecie
a fost parametrizat astfel nct utilizatorul sa-i poat alege caracteristica spaial iar pe de
alt parte s poat furniza condiia de selecie, adic expresia asociat clauzei where.
Cnd se ruleaz modelul va apare un dialog n care utilizatorul i poate seta aceti
parametri dup cum se observ n figura 14.21.

Fig. 14.21 Dialogul pentru setarea parametrilor modelului constr_regiune

Expresia de selecie implic atributul nonspaial simbol al tabelei judee. Astfel, s-au
selectat acele judee care formeaz regiunea Nord_Est a Romniei.
Rezultatul operaiei de selecie se constituie ca intrare pentru operaia de uniune.
Reuniunea judeelor se concretizeaz printr-o multime de poligoane care formeaz regiunea
respectiv. Pentru obinerea regiunii ca dat spaial de sine stttoare se efectueaz operaia
Capitolul 14

416
de agregare a judeelor (poligoanelor) (Aggregate Polygons) care formeaz regiunea, rezultnd
un singur poligon. Aceast caracteristic spaial se concretizeaz ntr-un nou strat tematic
(Regiunea_rezultat) dup cum se poate observa n figura 14.22.

Fig. 14.22 Strat tematic rezultat n urma execuiei modelului constr_regiune

Prelucrarea datelor spaiale implic formarea unor regiuni la momentul execuiei,
regiuni necesare pentru a delimita un anumit spaiu. De exemplu, dac e necesar s
identificm localitile care se afl n jurul rului Olt, la maxim 2 km, atunci ar trebui s
delimitm regiunea aflat n jurul rului la o distan de 2 km. Se vor utiliza urmtoarele
caracteristici spaiale, concretizate n straturile tematice: localitile Romniei i rurile.
Primul pas const n a selecta rul Olt pe hart. Acest lucru se realizeaz prin
efectuarea unei selecii implicnd n condiie un atribut nespaial din tabela ruri si anume
den, care stocheaz denumirea rurilor. Operaia propriu-zis se poate declana prin execuia
comenzii:

SelectLayerByAttribute ruri NEW_SELECTION " den = 'Olt' "

ce va fi introdus n fereastra de comenzi numit Command Line.
Dup selecia rului Olt se poate construi regiunea din jurul lui construind un buffer.
Operaia de construire a buffer-ului se declaneaz din componenta ArcToolbox/Analysis
Tool/Proximity/Buffer, setarea parametrilor se face prin dialogul din figura 14.23
Principalii parametri au semnificaiile:
- Input Features - caracteristica spaial n jurul creia se creeaz buffer-ul, n
exemplu este vorba de ruri, mai precis rul Olt anterior selectat;
- Output Feature Class - denumirea caracteristicii spaiale de ieire, implicit este
ruri_Buffer, adic bufferul se va constitui ntr-o caracteristic spaial de sine
stttoare;
- Linear unit - este parametrul prin care se stabilete distana la care se va trasa
buffer-ul n raport cu caracteristica spaial de intrare; pe de alt parte, tot aici se
poate stabili i unitatea de msur a distanei.


417

Fig. 14.23 Dialog pentru setarea parametrilor operaiei de creare a unui buffer

Rezultatul operaiei se poate observa n figura 14.24. Astfel, stratul tematic
ruri_Buffer definete o suprafa, construit n jurului rului Olt la o distan de 2 km.

Pentru obinerea localitilor ce se afl n vecintatea rului Olt se va efectua o
operaie de selecie spaial, mai precis se vor selecta toate localitile care intersecteaz
suprafaa creat prin operaia de buffer-izare (ruri_Buffer), utiliznd comanda:

SelectLayerByLocation localitati INTERSECT ruri_Buffer 0 NEW_SELECTION

Fig. 14.24. Buffer aplicat n jurul rului Olt
Capitolul 14

418

Dup execuia acestei comenzi se poate crea un nou strat tematic numai cu localitile
selectate, rezultatul operaiei de filtrare se poate vedea n figura 14.25.
Pentru dezvoltarea de aplicaii, ArcGIS folosete limbajul Visual Basic cu ajutorul
cruia sunt manipulate prin programare obiecte definite n ArcGIS, ca rspuns la
evenimentele generate de utilizator. Se pot utiliza diferite elemente de interfa cum ar fi cele
specializate n acest sens: bare de instrumente, meniuri, csue de dialog; iar pe de alt parte,
se pot utiliza chiar date spaiale pentru a realiza interaciunea cu utilizatorul.

Fig. 14.25. Selecia localitilor din vecintatea rului Olt

Baze de date multimedia
419

Capitolul 15

15.1. Cadrul conceptual

Utilizarea pe scar larg a calculatoarelor a fcut posibil trecerea de la folosirea unor
structuri statice de prezentare a informaiei (cri, reviste), la unele capabile s realizeze o
uoar actualizare a lor. Primele sisteme de calcul au manipulat i prezentat informaia ntr-o
form alfanumeric. mbuntirea tehnologiilor n direcia dispozitivelor de memorare, a
adaptoarelor grafice, mrimea memoriei principale ct i a celei externe precum i puterea
procesorului a dus la apariia a noi tipuri de date cunoscute sub numele de date
neconvenionale.
Termenul de multimedia este destul de greu de definit deoarece este interdisciplinar.
Din punct de vedere informatic, multimedia se definete ca o combinaie de: text, grafic,
imagine, animaie, sunet, video accesibil utilizatorului prin intermediul sistemului de calcul.
Sistemele informatice multimedia sunt acele sisteme informatice care gestioneaz
informaii multimedia, folosesc multimedia pentru prezentare i utilizeaz instrumente
specifice pentru stocarea, manipularea i regsirea informaiei multimedia. Sistemele pentru
stocarea i regsirea informaiei multimedia au fost proiectate i dezvoltate pentru diferite
tipuri de aplicaii. Multe dintre modurile de gestionare i prezentare a acestor informaii au
fost adaptate i utilizate n contextul acestor sisteme.
Datele tradiionale sunt n esen statice, starea lor este invariabil n timp, afar doar
de cazul n care exist o intervenie extern, explicit a utilizatorului sau a sistemului de
gestiune, iar gradul lor de interactivitate cu utilizatorul este minim. Prin comparaie,
informaia multimedia este dinamic i deci intrinsec activ i reactiv. Reactivitatea se
raporteaz la posibilitatea de modificare chiar a strii mediului prin intermediul unor
evenimente externe, nu numai la o simpl variaie a coninutului. Un video sau o secven
muzical poate fi ntrerupt, eliminat, distribuit dintr-un punct de ntrerupere ori de la
nceput sau i se poate altera coninutul. La fel, o imagine poate fi schimbat, mrit sau
redus. Datorit dinamicii datelor multimedia, metodele i tehnicile de prelucrare sunt mult
extinse fa de o baz de date clasic. Mediul este i el activ, deoarece starea lui poate evolua
n timp n mod independent de fiecare aciune extern. Un video odat activat, poate fi parcurs
pn la sfrit, dac utilizatorul sau sistemul nu intervine explicit. Mai multe medii diverse
pot fi activate simultan i sincronizate ntre ele pe parcursul derulrii. Pe de alt parte
imaginile, datele audio i video pot avea dimensiuni de multe milioane de bytes, ceea ce
presupune gsirea unor noi soluii de prelucrare a datelor. Pentru o gestiune automat,
informaia multimedia este structurat pe obiecte complexe, compuse din diferite uniti de
informaii elementare, conectate natural ntre ele. De exemplu, ntr-o aplicaie salon auto
virtual, informaia relativ la un automobil poate fi compus din imagini corelate cu note
explicative dar poate fi compus i dintr-un film scurt care ne red modul de desfurare a
diferitelor faze din procesul de producie a automobilului respectiv.
Capitolul 15
420
Utilizarea obiectelor complexe rezolv att problema de memorare i de gestiune, ct i
pe cea de prezentare, prin manipularea simultan sub un model unic a mai multor uniti de
informaii de diverse dimensiuni i durate. Datele multimedia necesit un larg spaiu de
memorie pentru a putea fi stocate. Ele sunt frecvent comprimate pentru a reduce spaiul de
memorie necesar, algoritmii de compresie folosii sunt variai i formeaz nite standarde ca:
JPEG, MPEG, PX64 etc. Acest lucru are i dezavantaje n sensul c regsirea unei pri dintr-
o imagine comprimat este dificil de realizat ca i derularea ntr-un sens sau altul dintr-un
punct arbitrar a unei date video sau a unei secvene de sunet comprimat.
Deoarece datele multimedia sunt semistructurate, semantica entitilor este funcie de
semantica prilor componente. Fiecare component a unei entiti multimedia are atribute i
poate participa n relaii. Aceste atribute i relaii se mpart n dou tipuri: cele ce utilizeaz
proceduri corespunztoare de decodificare i cele care nu folosesc astfel de proceduri.
Atributele i relaiile a cror prezen depinde de aplicarea unui procedeu de decodificare sunt
bazate pe context n timp ce celelalte sunt independente de context. Atributele i relaiile
dependente de context se mpart la rndul lor n informaii de legtur i noninformaii de
legtur. Un atribut este informaie de legtur dac nu este explicit codificat n entitatea
multimedia respectiv. Prezena acestui tip de atribut sau relaie adaug noi informaii cu
privire la o anumit entitate multimedia, informaii ce nu pot fi derivate dintr-o codificare
binar. De exemplu, numele unei cldiri afiat ntr-o imagine ar putea fi informaie de
legtur bazat pe context. Diferena ntre informaia de legtur i noninformaia de legtur
este destul de mic i puin conturat. Ca opinie general, ea ar consta n aceea c informaia
apare n reprezentare binar sau nu ntr-o anumit entitate multimedia. Utilizarea relaiilor i a
atributelor bazate pe context determin extinderea semnificativ a unor tipuri de operatori
cum ar fi filtrarea i navigarea ce pot fi folosite de utilizator.

15.2. Un model generic al datelor multimedia

nainte ca informaia s fie manipulat ntr-o baz de date ea trebuie mai nti s fie
reprezentat la nivel logic, independent de arhitectura bazei de date utilizat. Modelul logic al
informaiei multimedia va fi adaptat bazei de date respective. De aceea, pentru acest tip de
informaie se prefer o arhitectur de baz de date orientat obiect; deci va trebui s se
reprezinte informaia multimedia utiliznd modelul orientat obiect. Sunt astfel cinci tipuri de
informaii care ar trebui reprezentate ntr-un astfel de model:
- Informaii multimedia neinterpretabile care sunt de obicei reprezentate printr-un
bloc (binary large obiect) adic un obiect de dimensiuni mari n format binar;
- Informaii independente de context sunt cele care sunt folosite la sincronizri video
(ntre cadre de imagine i audio), cele care se afl n antetul fiierelor i conin
informaii ce caracterizeaz diferitele entiti multimedia cum ar fi cele referitoare
la metoda de digitizare i codificare utilizat, procedurile care le realizeaz etc;
- Informaii alfanumerice care se afl n baze de date convenionale i privesc
proprietile i relaiile ntre diferitele entiti ce nu sunt multimedia.
- Informaii ce realizeaz legtura ntre obiectele multimedia i cele de alt tip; sunt
exemplificate prin entitile care apar n anumite cadre, date video dependente de
context.
- Informaii ce definesc modul de construire i reprezentare a diferitelor legturi
ntre obiectele multimedia. Ele ar putea fi obinute prin specificarea relaiilor
pornind de la interpretarea datelor multimedia de ctre utilizator sau ar putea fi
421
construite parial n mod automat utiliznd variate tehnici de interpretare a datelor
imagine i audio.
Proiectarea unui model pentru un sistem informatic multimedia va trebui s asigure o
comunicare facil ntre datele entitilor obinuite ale aplicaiei i obiectele multimedia. Un
model bun realizeaz legtura ntre atribute i relaii care sunt independente de context,
informaii de legtur dependente de context i informaii de legtur bazate pe context. Cel
mai important aspect n proiectarea unui astfel de model este realizarea descompunerii
obiectuale multimedia n termenii caracteristicilor.
Caracteristicile obiectelor multimedia pot fi simple sau complexe. Cele complexe pot
fi descompuse la rndul lor, n timp ce cele simple sunt tratate ca entiti atomice.
Caracteristicile unui obiect multimedia sunt similare atributelor unei entiti obinuite (care nu
este multimedia) a unei baze de date cu informaii alfanumerice. Exist n acest sens o
excepie, adic un atribut al unei entiti obinuite poate fi informaie de legtur n timp ce o
caracteristic a unui obiect multimedia, bazat fiind pe context constituie informaie de
legtur.
O cheie a unei entiti obinuite este o colecie de atribute care ajut la o unic
identificare a ei. Un obiect multimedia poate avea cheia constituit din caracteristici
dependente de context dar de asemenea poate fi folosit o cheie standard format din atribute
independente de context. Ca i n cazul entitii obinuite, cheia unui obiect ajut la
identificarea unic a lui.
Cheile dependente de context pot fi utilizate la obinerea unor informaii de legtur
necesare definirii de relaii ntre obiectele multimedia i entitile obinuite. In figura 15.1 se
prezint modul de realizare a unor astfel de relaii. O relaie ntre entitatea e
1
(obinuit) i un
obiect multimedia m
1
a fost anterior stabilit prin definirea unei informaii de legtur. Intre
obiectele multimedia m
1
i m
2
nu exist nici o legtur dar au n comun cheia obiectului m
1
.
De aici se poate obine o nou relaie ntre e
1
i m
2
. Se presupune c entitatea e
1
descrie o
anumit persoan i m
1
conine imaginea sa (a lui e
1
). Utiliznd cheile dependente de context
din m
1
i m
2
se poate determina c dac fiecare caracteristic din cheia obiectului m
1
apare n
cheia lui m
2
atunci imaginea lui apare n m
1
i n m
2
. In acest fel s-a obinut o nou informaie
de legtur printr-o relaie dependent de context ntre e
1
i m
2.

Entitatea e
1
Nume: .....
Adres: .....
Telefon: ....
Obiectul multimedia m
1
Obiectul multimedia m
2

Similitudinea cheii dependente
de context.
Relaie bazat pe context
derivat
Relaie bazat pe context
definit de utilzator

Fig. 15.1. Obinerea unei relaii dependente de context

Capitolul 15
422
Aceste consideraii arat ct de important este ca pentru orice model de date
multimedia s se poat preciza variatele caracteristici i organizarea lor. O caracteristic a
unei imagini se poate baza pe textur, culoare, intensitate, geometrie sau alte proprieti ale
imaginii. Deoarece un video conine o secven de cadre (de imagini), caracteristica ar putea
fi o secven de caracteristici ale imaginilor.
Sarcina cheii ntr-un model multimedia este s realizeze legtura ntre semnificaia
domeniului obiectelor i semnificaia caracteristicilor. Deoarece caracteristicile sunt
structurate, semnificaia unei caracteristici complexe ar trebui s fie dat de semnificaia
componentelor ei. Cel mai familiar exemplu este acela de similaritate. Astfel, dou obiecte
multimedia sunt similare dac setul lor de chei dependente de context sunt similare.
Modelele multimedia pot avea nelesuri mai complexe. Se poate evalua o astfel de
interogare n dou moduri diferite. Presupunem c se dorete obinerea datelor video n care
dou persoane (X i Y) danseaz. O cale simpl de realizare a acestei interogri ar fi cea de
obinere a tuturor datelor video n care X i Y sunt n relaia dans. Aceast metod are
dezavantajul c nu se poate generaliza la alte cazuri care nu au fost specificate de utilizator.
Un mod mai robust de realizare este acela prin care se definete dansul n setul de obiecte a
domeniului, n termenii unei secvene de evenimente din mulimea caracteristicilor. Relaia
ntre entitile obinuite ale aplicaiei i imaginea lor se poate realiza pe baza informaiei de
legtur dependente de context. Practic se urmresc cadrele contigue ale unui video i se
extrag acelea care corespund aciunii de dans i apoi din cele obinute se pstreaz doar cele
n care aciunea este desfurat de persoanele precizate. Acest mod de realizare a unei
interogri, prin utilizarea unor tehnici curente de interpretare a imaginii, este destul de greu de
efectuat n situaiile n care condiia devine laborioas. In cazul n care dansul nu a fost definit
n modelul original, utilizatorul ar trebui s aib un set de instrumente pentru a-i permite s
defineasc aceast aciune. Noiuni precum micarea sincron a braelor i a picioarelor
combinate cu alte informaii ar putea defini dansul. Aceasta ilustreaz natura incremental a
operaiei de detectare a unei caracteristici complexe.
Un set bogat de caracteristici de baz i un set de caracteristici pentru diferite operaii
ar fi suficiente pentru definirea de caracteristici complexe la orice moment de timp. De
exemplu, caracteristica intensitatea unui punct poate fi definit ca pi(punct, intensitate) unde,
pi este un constructor care combin dou caracteristici ntr-o nou caracteristic complex.

15.3. Organizarea bazelor de date multimedia ca
extensie a celor orientate obiect

ntr-o lume aproape complet eterogen, cum este cea a bazelor de date multimedia, att
sub aspectul datelor combinate ct i a soluiilor propuse i platformelor utilizate, identificarea
elementelor comune care s stea la baza unei organizri unitare este mai mult dect necesar.
n acest scop se vor pune n eviden nivelurile de structurare a bazelor de date multimedia:
- structura funcional sau tehnologic,
- structura relaional,
- structura de interogare sau dinamic,
- structura de prezentare sau de sistem.
Structura funcional sau tehnologic a bazelor de date multimedia are n vedere
funciile de creare, achiziie, compresie, stocare, manipulare, transmitere la distan,
sincronizare i combinare a informaiilor digitale. De obicei, imaginile statice i datele audio
423
i video se vor elabora n cazul bazelor de date multimedia, separat i integrate cu datele
tradiionale. Nu se va utiliza pentru aceasta tehnologia analog, dei ofer deocamdat
singurele dispozitive corespunztoare din punctul de vedere al cantitii de informaie
memorat (mai cu seam audio i video) dar acestea sunt foarte limitate n ceea ce privete
interogarea i interactivitatea, de aceea se va utiliza tehnologia digital. In acelai scop sunt
necesare i tehnici de compresie a fiierelor audio i video.
Structura relaional privete aspecte ale corelrii statice a tipurilor de date pe care le
suport o baz de date multimedia dup modelul orientat obiect. Segmentul de informaii este
eterogen i poate proveni din medii diverse: date formatate, texte ASCII, imagini raster,
imagini vectoriale, animaii de diferite tipuri, sunet, video etc.
Obiectele ncapsuleaz operaiile specifice ntr-un mod care permite realizarea practic
a structurii funcionale. Fiecare tip de obiect va conine metode orientate pe structura
funcional. Spre exemplu, vizualizarea unui obiect se face difereniat dup tipul obiectului
(imagine, text etc.), dar funcia care realizeaz vizualizarea poart acelai nume, ascunznd
ns un cod executabil diferit.
Fiecare obiect are o structur intern proprie, determinat prin relaiile dintre prile
componente. Intre obiecte, chiar eterogene, exist conexiuni care stau la baza organizrii lor
n obiecte complexe. Gruparea lor n colecii se poate face manual, semiautomat sau automat.
Structura de interogare sau dinamic include metodele specifice de regsire a
informaiei i modul de interaciune dintre utilizator i baza de date multimedia. Sistemul de
gestiune a bazelor de date trebuie s dispun de proceduri pentru implementarea cutrilor
bazate pe tehnica similaritii textului, imaginii, sunetului, precum i pentru cutarea direct
sau aleatoare pe baz de index. Structura de interogare include i o component pentru acces
de tip navigaional, care permite ghidarea utilizatorului n fiecare moment (direcii posibile de
urmat, informaii deja vizitate, istoricul cutrii etc.).
Structura de prezentare sau de sistem ine de aspectele specifice de run-time ale unei
baze de date multimedia, i asigur consultarea bazei de date independent de periferic i de
platforma pe care se face vizualizarea. n acest scop, n afara unei interfee utilizator grafice
avansate, baza de date trebuie s dispun de mecanisme care s permit redarea concurenial
a obiectelor sau a unor pri din obiectele complexe. Obiectele dispun n afar de informaia
propriu-zis i de informaie de vizualizare: formate, metode de compresie, algoritmi de
conversie etc. Baza de date trebuie s dispun de componente pe care s tie s le interpreteze
corect. Pentru aplicaiile n timp real, sistemul de gestiune pentru baze de date multimedia
dispune de primitive de procesare n timp real, care asigur o gestiune a sincronizrii, o
utilizare eficient a resurselor de memorie folosind tehnici de bufferizare specifice.
Se pot pune n eviden mai multe tipuri de obiecte ce urmeaz a fi ncapsulate n
modelul multimedia. La cel mai primitiv nivel, un tip de obiect ar trebui s reprezinte tipuri de
date de baz cum sunt: text, imagine, audio, video. La un nivel mai nalt ar trebui s se
expliciteze natura spaial sau temporar a obiectelor multimedia. Exist dou dimensiuni
temporale ce caracterizeaz datele multimedia de tip audio-video. Prima dimensiune se refer
la coninutul datei multimedia, ca o succesiune de cadre n timp, iar cea de-a doua dimensiune
se leag de etapa de prezentare care trebuie s se fac n timp real.
Lund n considerare aceste trsturi specifice obiectelor ce sunt manipulate n cadrul
bazelor de date multimedia, se pot evidenia particulariti referitoare la indexare, strategi de
cutare, interogare i regsire bazat pe context.

Capitolul 15
424
15.4. Sincronizarea n transferul datelor n timp real

Datele multimedia solicit adesea sincronizarea n procesul de transfer n timp real.
Este de dorit ca datele s ajung ntotdeauna la receptorul final la timp astfel ca s nu existe
ntreruperi n prezentare. In cazul n care dou sau mai multe tipuri de date sunt extrase pentru
prezentare, poate aprea o problem de sincronizare la receptorul final. In cazul asocierii de
video, voce i text de titraj, toate cele trei tipuri de date trebuie s fie sincronizate, adic s
ajung mpreun la receptorul final.
Transferul n timp real i sincronizarea vor depinde de distribuia ratelor de compresie
a diferitelor tipuri de date, spaiu tampon alocat, algoritmii de planificare utilizai, plasarea
datelor pe dispozitivele de memorie secundar, distribuia datelor pe dispozitivele de reea i
lrgimea de band alocat n canalul de comunicaie. Unii cercettori au adoptat abordarea
gsirii condiiilor ce garanteaz transferul n timp real i sincronizarea informaiei la
receptorul final. Este mai uor de realizat acest lucru cnd receptorul se afl pe aceeai staie
de lucru. Dificultatea apare cnd receptorul este ntr-un nod al reelei datorit
impredictibilitii ncrcrii reelei. In acest caz se va sacrifica o parte a cantitii de
informaie n ideea garantrii livrrii n timp real i a sincronizrii.
Evoluia tehnologic va duce la creterea vitezei dispozitivelor de memorare
secundar, ct i a canalelor de comunicaie. Tehnologia fibrelor optice promite s livreze sute
de megabii pe secund. Totui, s-a dovedit c utilizatorii consum orice extra resurs ce li se
ofer. Astfel este important s se dezvolte i s se studieze algoritmi ce garanteaz o livrare
bun n timp real prin sincronizarea informaiilor multimedia. Algoritmii ar putea exploata
reducerea de calitate ct i utilizarea memoriei cache pe reea i ar putea utiliza modele
orientate pe performan ct i modele utilizator de absorbie.

15.5. Navigarea i interogarea bazelor de date
multimedia

Procesul de interogare a unei baze de date multimedia are o serie de particulariti n
special datorit naturii informaiilor ce pot conine text, imagine, audio i video. In acest sens,
sistemul trebuie instruit n ce privete modul de prezentare a rezultatelor interogrii. O alt
particularitate deriv i din faptul c informaiile n bazele de date multimedia nu sunt
structurate ca n bazele de date standard. In plus, nu se cunoate cu siguran ce fel de date
multimedia exist n respectiva baz de date, de aceea formularea cererii devine foarte
important.
Pentru a rezolva aceste probleme se propune modelarea procesului de interogare ca pe
o secven de operaii de filtrare i navigare. Intreaga baz de date multimedia poate fi logic
reprezentat de o reea sau un graf. Nodurile unei astfel de reele corespund entitilor ce pot
fi obinuite: imagine, video, audio, n timp ce arcele reelei corespund relaiilor ntre aceste
entiti. O operaie de filtrare pe o astfel de reea produce o subreea eliminnd entitile i
relaii nedoritele. Pe de alt parte, operaia de navigare permite utilizatorilor s citeasc
textual informaia, s vizualizeze o nregistrare video, s asculte o secven audio sau s
urmeze o anumit rut din reeaua dat, trecnd de la o entitate la alta. Pentru a se nelege
modul de operare se va considera exemplul n care un utilizator navigheaz printr-o secven
de imagini n care apar diferite tipuri de tractoare. In una din ele se recunoate i o combin.
S presupunem c utilizatorul indic sistemului un anume interes n ceea ce privete acel
425
model de combin. In acest caz, sistemul poate prezenta informaii alfanumerice privind acea
combin. El poate disponibiliza o serie de obiecte multimedia, pentru a fi consultate, n care
apar alte modele de combine. Dac utilizatorul dorete s vad proiectanii unei combine
atunci sistemul poate construi o secven de obiecte multimedia n care respectivii proiectani
apar. Abordarea extragerii de informaie sugereaz c o entitate poate fi extras deoarece este
relevant, dei ea poate s nu constituie o valoare sau o relaie care s apar n mod explicit n
interogarea utilizatorului.
Recent, evidenierea a fost introdus n abordrile bazate pe hypertext i hypermedia.
Abordrile hypertext i hypermedia sunt ci de structurare a coninutului bazei de informaie.
Informaia este extras traversnd legturi de un tip particular, nainte i napoi. Modelul de
date hypertext / hypermedia este foarte apropiat modelelor bazelor de date orientate obiect.
Modelele orientate hypertext / hypermedia adesea sugereaz o metod de navigare n scopul
extragerii informaiilor din baza de informare.
n sistemele informatice standard toate cererile sunt alfanumerice iar n cele
multimedia, obiectele multimedia pot participa la orice interogare. Deoarece un modul de
procesare a caracteristicilor extrage caracteristicile tuturor obiectelor multimedia inserate,
acesta poate extrage caracteristicile similare ale unui obiect multimedia ce este parte a unei
interogri. Acest mecanism poate fi sugerat n figura 15.2.

Modul de procesare a caracteristicilor
Caracteristici
interogate
Caracteristici
stocate
Calcularea
similitudinii
Inserarea obiectelor
multimedia
Obiect multimedia
parte a interogrii

Fig. 15.2. Un obiect multimedia ca parte a unei interogri

Toate interogrile complexe pot fi descompuse n componente elementare ce ar putea
fi mprite n patru tipuri. Primul tip de cerere elementar determin toate imaginile cu un
subset de caracteristici avnd valori cunoscute. Al doilea tip de interogare elementar gsete
toate imaginile ale cror set de valori a caracteristicilor furnizeaz un numr ce aparine unui
domeniu dat. Al treilea i al patrulea tip includ un obiect multimedia asociat, dat de utilizator.
n al treilea tip, utilizatorul furnizeaz metode variate de calcul pentru caracteristicile
necesare. Al patrulea tip utilizeaz modulul de procesare a caracteristicilor pentru calculul
caracteristicilor obiectului multimedia implicat n formularea interogrii.
n realitate, n procesul de interogare, gsirea unor caracteristici care s se potriveasc
exact cu cele ale obiectelor ce se afl n baza de date multimedia produce rareori ieiri utile.
Astfel, fiecare caracteristic ar trebui s aib definit propria noiune de similitudine. Pentru
c nu este vorba de o similitudine n sensul strict al cuvntului se va folosi mai bine termenul
de apropiere. Apropierea dintre dou obiecte multimedia ar trebui s se calculeze pe baza unui
grad mediu de apropiere ntre componentele lor. Deoarece caracteristicile extrase se bazeaz
pe tehnici de interpretare a imaginilor i pe recunoaterea sunetelor, rezult c fiecrei
caracteristici extrase ar trebui s-i corespund un factor de siguran care s exprime faptul c
acea caracteristic este relevant pentru procesul de comparare. Acest factor de siguran ar
trebui s influeneze viitoarele calcule de similaritate.
Capitolul 15
426
Pentru a economisi timp se pot obine toate obiectele multimedia avnd caracteristici
aparinnd unui set dat de caracteristici. Acest concept poart denumirea de indexarea
caracteristicilor i este similar unui index standard care determin obinerea tuturor
nregistrrilor avnd o valoare dat pentru un atribut. Majoritatea tehnicilor au la baz
modelul. Scopul unui astfel de sistem este de a precompila descrierea fiecrui obiect
multimedia cunoscut, numit model, apoi utilizarea acelui model la identificarea oricrui obiect
multimedia prezent n formularea interogrii. Un model pentru un obiect multimedia este
dezvoltat utiliznd caracteristicile extrase de la unul sau mai multe prototipuri ale acelui
obiect. Au fost propuse mai multe astfel de tehnici:
- Tehnica model-by-model utilizeaz fiecare din modelele precompilate, pe rnd, ca
pe un model de test. Sistemul caut pentru obiectul multimedia implicat n
interogare una sau mai multe caracteristici al obiectului de test considerat. In cazul
n care o caracteristic se potrivete, atunci el preia o instan a obiectului
multimedia i estimeaz proprietile acelui obiect. In final se verific prezena
obiectului multimedia considerat. Principalul dezavantaj al acestei tehnici este dat
de costul ridicat cauzat de o cutare exhaustiv a unei date imagine pentru o
caracteristic selectat, aparinnd unui model de test.
- O alt cale numit feature-by-feature, formeaz o colecie de caracteristici a
tuturor modelelor. Tehnica asociaz fiecrei caracteristici o list coninnd
obiectele multimedia n care aceasta s-a regsit. Se caut apoi pentru fiecare
caracteristic, obiectul multimedia implicat n interogare. Dac se gsete o
anumit caracteristic, se consult lista aferent ei pentru a face o ipotez i apoi se
verific identitatea i locaia posibilului obiect. Gsirea unor astfel de caracteristici
necesit metode complexe i costisitoare care trebuie s fie repetate de fiecare dat
cnd un model este ters sau inserat.
Figura 15.3 ilustreaz diferenele fundamentale ntre cele dou metode. Modelul
model-by-model (figura 15.3 a) utilizeaz o caracteristic aparinnd unui model dat, n timp
ce modelul feature-by-feature (figura 15.3 b) utilizeaz o caracteristic aparinnd unei
colecii de caracteristici, obinut dintr-o baz de date de modele.
Pentru implementarea acestor tehnici se pot folosi proceduri preluate din gestiunea
datelor convenionale care duc la o cretere a vitezei de regsire a informaiei. De exemplu, se
pot utiliza cutri binare pe seturi de date sortate, n plus operaiile de cutare vor fi
completate cu cele de inserare i tergere care sunt necesare; datele pot fi organizate folosind
structuri de date necesare stocrii i indexrii preluate de la sistemele de gestiune a bazelor de
date convenionale. n plus, s-au fcut eforturi de a furniza o adresare dup coninut pentru
tipuri complexe de date, de exemplu imaginile. Deoarece este dificil s accesm informaia n
timp real utiliznd tehnicile de recunoatere a paternelor, cea mai mare parte a metodelor
furnizeaz un descriptor de coninut pentru imagine care este examinat n comparaie cu o
cerere de utilizator. Descriptorul de coninut poate fi un simplu text, sau poate conine
informaie structurat ce descrie coninutul imaginii. n unele cazuri, tehnicile de extragere
bazate pe similitudine pot fi folosite pentru a potrivi coninuturile bazei de date cu un filtru
grafic furnizat de utilizator. n mod curent, extragerea bazat pe coninut pentru documentele
scanate sau voci este limitat de capacitile vorbirii curente i a tehnologiei de recunoatere a
documentelor. Domeniul adresrii pe coninut a obiectelor multimedia este profund. El
cuprinde probleme dificile din tiina calculatoarelor i ingineriei, cum ar fi nelegerea
limbajului natural, procesarea vorbirii, vizionarea i modelarea utilizator. Adresarea dup
coninut trebuie suplimentat cu tehnici de parcurgere rapid (de exemplu utilizarea
miniaturilor), deoarece este posibil ca n unele medii utilizatorul s nu fie capabil s specifice
precis ceea ce dorete.

427

Obiect
necunoscut
Rezultate
Verificarea
ipotezei
Model de test
Generarea
ipotezei
Determinarea
corespondenei
Reprezentarea obiectului
multimedia
( a)

Rezultate
Verificarea
ipotezei
Model ipotetic
Model de test
Generarea
ipotezei
Determinarea
corespondenei
Reprezentarea obiectului
multimedia
Obiect
multimedia
al interogrii

( b)

Fig. 15.3. Diferene ntre modele

15.6. Gestiunea i procesarea fluxurilor media n
baze de date multimedia

Este bine cunoscut c pentru a vehicula informaiile dintr-o baz de date trebuie s se
foloseasc un sistem de gestiune a bazelor de date. Lund n considerare faptul c datele ce
urmeaz a fi utilizate sunt neconvenionale se urmrete alegerea unui sistem adecvat de
gestiune a bazelor de date, mai precis unul multimedia. Sistemul de gestiune Jasmine este un
sistem de gestiune specializat pentru baze de date multimedia i este orientat obiect. Alte
sisteme de gestiune a bazelor de date, consacrate i foarte utilizate cum ar fi Oracle i-au
dezvoltat componente specializate, astfel versiunea 10 g posed componenta InterMedia
pentru gestiunea tipului media.
InterMedia este o component care extinde funcionalitile sistemului de gestiune a
bazelor de date Oracle permind stocarea, gestiunea i regsirea datelor multimedia: a
imaginilor, a secvenelor video, a datelor audio i a altor tipuri media eterogene, ntr-o
manier integrat cu tipuri de date tradiionale. Oracle interMedia nu controleaz
dispozitivele de captur multimedia i nu are funcii pentru redarea datelor multimedia ci
faciliteaz gestiunea datele multimedia stocate n baza de date.
InterMedia gestioneaz datele multimedia stocate n baza de date sub forma BLOB-
urilor (binary large objects), a fiierelor multimedia gestionate direct de sistemul de operare,
Capitolul 15
428
formatul utilizat n acest caz este BFILE (file-based large objects) i a datelor multimedia
stocate pe un server web.
InterMedia folosete tipuri obiectuale pentru descrierea datelor multimedia, astfel:
- tipul ORDAudio pentru datele audio;
- tipul ORDImage pentru imagini statice;
- tipul ORDVideo pentru secvene video; i
- tipul ORDDoc pentru date eterogene.
Toate aceste tipuri conin i informaii despre sursa datelor, tipul de dat folosit fiind
ORDSource.
Recunoaterea imaginilor bazat pe coninut este o problem important asociat
sistemelor de gestiune a bazelor de date multimedia. Odat cu creterea volumului coleciilor
imaginilor digitale care pot fi eventual stocate n baza de date, crete i dificultatea regsirii
imaginilor relevante. Pentru rezolvarea acestei probleme exist dou metode i ambele
utilizeaz metadate pentru regsirea imaginilor:
- prima utilizeaz informaii introduse manual n tabele, ca de exemplu: titluri,
cuvinte cheie descriptive preluate dintr-un vocabular limitat i scheme de
clasificare predefinite,
- a doua folosete caracteristicile imaginilor, caracteristici extrase automat i
recunoaterea obiectelor pentru clasificarea coninutul imaginii.
InterMedia permite combinarea celor dou alternative prin proiectarea unei tabele ce
conine imagini. Pentru aceasta se folosesc date de tip text pentru descrierea semnificaiei
semantice a imaginii i tipul de dat ORDImageSignature pentru interogri bazate pe coninut
ce folosesc atributele eseniale ale imaginii. Un sistem de recunoatere bazat pe coninut
prelucreaz informaiile din imagine i creeaz o abstractizare a coninutului pentru atributele
vizuale. Interogrile lucreaz cu abstractizarea imaginii i nu cu imaginea propriu-zis.
Criteriile de cutare folosite de InterMedia sunt culoarea, textura i conturul. Poziiile
acestor atribute vizuale n cadrul imaginii sunt reprezentate prin coordonate. Aceste
coordonate nu sunt folosite n mod independent pentru recunoaterea formelor ci doar
mpreun cu unul din cele trei atribute vizuale.
Imaginea odat inserat n baza de date este analizat i este stocat cte o
reprezentare compact a coninutului sub forma unui vector de caracteristici numit semntura
imaginii. Semntura imaginii este extras prin segmentarea acesteia n regiuni, pe baza petelor
de culoare care compun imaginea. Fiecare regiune are asociate informaii despre culoare,
textur i contur. Semntura conine aceste informaii pentru fiecare regiune care formeaz
imaginea i informaii despre culoare, textur i contur pentru reprezentarea acestor atribute n
ntreaga imagine.
Atributul culoare memoreaz informaii despre distribuia culorilor n ntreaga
imagine. Aceast distribuie conine date despre intensitatea fiecrei culori.
Atributul textur reprezint abloanele din cadrul imaginii, precum granularitatea i
smoothness. Spre deosebire de atributul contur, textura este foarte sensibil la caracteristicile
care apar cu mare frecven n imagine.
Conturul este determinat de tehnicile bazate pe segmentare. Conturul este
caracteristica unei regiuni de culoare uniform.
Locaia reprezint poziia componentelor culoare, textur i contur.
Recunoaterea imaginilor stocate ntr-o baz de date se face prin compararea lor cu o
imagine model care poate fi o imagine stocat n baza de date, din afara bazei de date sau o
imagine vectorial.
n procesul de cutare, se atribuie o pondere fiecrui atribut vizual n funcie de
importana lui. Valoarea fiecrei ponderi reflect ct de sensibil trebuie s fie procesul de
429
cutare fa de un anumit atribut. Valorile ponderilor trebuie s fie ntre 0 (atribut
nesemnificativ) i 1 (atribut extrem de important n procesul de cutare).
Asemnarea dintre dou imagini pentru fiecare atribut vizual este calculat ca scorul
sau distana dintre imagini, respectnd atributul. Scorul ia valori n intervalul 0 (nu exist
diferen) 100 (diferen maxim posibil). Scorul ntregii imagini se calculeaz ca sum a
scorurilor atributelor ponderat cu importana fiecrui atribut.
n procesul de cutare se folosete o valoare prag de semnificaie. Dac suma
ponderat este mai mic sau egal cu valoarea pragului atunci imaginile se potrivesc, altfel
nu.
Pentru creterea vitezei de cutare n bazele de date de mari dimensiuni care conin
date multimedia este util crearea i utilizarea unui index folosit pentru cutarea printre
semnturile imaginilor. Pentru aceasta se folosete un index de domeniu sau index extensibil
deoarece acesta suport obiecte complexe. Baza de date Oracle i interMedia coopereaz
pentru definirea, construirea i ntreinerea unui index pentru datele de tip imagine, index de
tip ORDImageIndex. Odat creat, indexul este automat actualizat ori de cte ori imaginile sunt
inserate, modificate sau terse din baza de date. Datele indexului sunt stocate n dou
tablespace-uri care trebuie create n prealabil: unul care conine datele indexului curent i
cellalt este un index intern creat pe aceste date.
Recunoaterea formelor este o procedur complex. Algoritmul de recunoatere a
formelor implementat n Oracle poate fi folosit cu succes dac sunt ndeplinite anumite
condiii i anume:
- dac obiectul cutat ocup o parte semnificativ a imaginii,
- dac nu exist elemente irelevante suprapuse peste o parte a obiectului cutat,
- dac obiectul cutat se afl n aceeai parte a imaginii,
- dac dimensiunile relative ale obiectului n cele 2 imagini, imaginea de referin i
cea n care se face cutarea sunt apropiate,
- dac obiectul cutat este fotografiat din acelai unghi n ambele imagini,
- dac obiectele adiacente din imagine au culori distincte,
- dac imaginea este format doar din cteva forme simple.
Pentru a ndeplini aceste condiii, se pot decupa succesiv zone din imagine, zone n
care se realizeaz cutarea i se pot utiliza diferite combinaii de ponderi ale atributelor
folosite n procesul de cutare.
Pentru exemplificarea operaiilor de crearea a unei tabele cu atribute de tip imagine,
de inserare a imaginilor n baza de date, de import a imaginilor inserate i generare a
semnturilor pentru imaginile din baza de date, pentru crearea tablespace-urilor pentru index
i crearea unui index de domeniu i cutarea unei imagini n baza de date s-a creat cte o
procedur PL/SQL. Procedurile au fost testate pe o baz de date Oracle 10g Release 2. Pentru
realizarea interfeei cu utilizatorul, apelarea procedurilor stocate i pentru afiarea rezultatelor
s-a construit o aplicaie.NET C# .
Se folosete obiectul DIRECTORY pentru administrarea accesului i utilizarea
tipurilor de date BFILE. Obiectul DIRECTORY stabilete un pseudonim pentru un director al
sistemului de fiiere al severului bazei de date unde se afl fiierul care trebuie accesat. Un
fiier extern bazei de date poate fi accesat numai dac se stabilesc depturile de acces necesare
obiectului DIRECTORY. Stabilirea directorului (c:\mydir) de unde vor fi preluate fiierele de
tip imagine pentru inserarea lor n baza de date se face prin secvena:
CREATE OR REPLACE DIRECTORY dirlucru AS 'c:\mydir';
GRANT READ ON DIRECTORY dirlucru TO PUBLIC WITH GRANT OPTION;
Crearea tabelei numit imagini cu structura:
- id NUMBER reprezentnd id-ul imaginii,
- descriere VARCHAR2(255) ce conine o scurt descriere a coninutului imaginii,
Capitolul 15
430
- img de tip ORDSYS.ORDImage pentru obiectul de tip imagine,
- img_semn de tip ORDSYS.ORDImageSignature pentru semntura imaginii,
se realizeaz prin urmtoarea secven de cod:
CREATE TABLE imagini
(id NUMBER,
descriere VARCHAR2(255),
img ORDSYS.ORDImage,
img_semn ORDSYS.ORDImageSignature);
Procedura care insereaz un tuplu n tabel are ca parametrii: vid id-ul imaginii, vdescriere
descrierea imaginii, nfis- numele fiierului de tip imagine.
CREATE OR REPLACE PROCEDURE inserare (vid IN NUMBER, vdescriere IN
VARCHAR2,nfis IN VARCHAR2)
IS
BEGIN
--Metoda static init a ORDImage iniializeaz atributul ORDImage
--Metoda static init a ORDImageSignature creaz un obiect ORDImageSignature vid.
INSERT INTO imagini VALUES (vid, vdescriere,
ORDSYS.ORDImage.init('file','DIRLUCRU',nfis), ORDSYS.ORDImageSignature.init());
END;

Procedura gen_semn este folosit pentru generarea semnturilor imaginilor din tabel:
CREATE PROCEDURE gen_semn
IS
BEGIN
DECLARE
myimg ORDSYS.ORDImage;
mysig ORDSYS.ORDImageSignature;
ctx RAW(4000):= NULL;
BEGIN
-- pentru toate tuplurile
FOR x in (SELECT ID FROM IMAGINI)
LOOP
SELECT S.img, S.img_semn INTO myimg, mysig
FROM imagini S WHERE S.id = x.id FOR UPDATE;
-- genereaz semnturile apelnd metoda generateSignature
mysig.generateSignature(myimg);
-- ncarc semntura generat
UPDATE imagini S
SET S.img_semn = mysig, S.img=myimg WHERE S.id = x.id;
END LOOP;
END;
END;

Crearea tablespace-urilor ce vor fi folosite de indexul de domeniu.

Creare tablespace-urilor pentru index:
CONNECT system/passadmin;
GRANT CREATE TABLESPACE TO mar;
GRANT DROP TABLESPACE TO mar;
CONNECT mar/passmar;
431
CREATE TABLESPACE ordimage_idx_tbs_1 DATAFILE
'C:\oracle\product\10.2.0\ordimage_idx_tbs_1.dbf' SIZE 1M REUSE;
CREATE TABLESPACE ordimage_idx_tbs_2 DATAFILE
'C:\oracle\product\10.2.0\ordimage_idx_tbs_2.dbf' SIZE 1M REUSE;

Crearea indexului de domeniu:

CREATE INDEX idx_imagini ON imagini(img_semn) INDEXTYPE IS
ORDSYS.ORDIMAGEINDEX
PARAMETERS ('ORDImage_Filter_Tablespace = ordimage_idx_tbs_1,
ORDImage_Index_Tablespace = ordimage_idx_tbs_2');

Procedura Cautare este folosit pentru cutarea celei mai asemntoare imagini stocat n
baza de date, folosind ca imagine de referint imaginea coninut n fiierul cu numele nfis.
Procedura are ca parametru de ieire id-ul imaginii obinute n urma cutrii, idrez.

CREATE PROCEDURE CAUTARE (nfis IN VARCHAR2, idrez OUT NUMBER)
IS
BEGIN
DECLARE
vimage ORDSYS.ORDIMAGE;
qsemn ORDSYS.ORDIMAGESIGNATURE;
qimg ORDSYS.ORDIMAGE;

-- se creeaz un cursor pentru selectarea imaginii similare cu cea de referin. Operatorul
IMGSimilar compar semntura imaginii de referin cu semnturile imaginilor stocate n
tabel i stabilete dac ele sunt asemntoare pe baza valorilor ponderilor i a pragului.
Imaginile sunt asemntoare, n condiiile formulate dac distana calculat este mai mic sau
egal cu valoarea pragului, caz n care operatorul IMGSimilar returneaz 1. S-au folosit
urmtoarele ponderi pentru atribute: locaie =1 e cel mai important atribut, culoarea=0,9,
forma=0,8 iar textura=0,1 - cel mai puin important atribut.
CURSOR getimg IS
SELECT id, img FROM imagini WHERE
ORDSYS.IMGSimilar(img_semn, qsemn,
'color="0.9" texture="0.1" shape="0.8" location="1"', 5) = 1;
BEGIN
idrez:=0;
-- Iniializeaz i seteaz proprietile obiectului imagine
qimg := ORDSYS.ORDIMAGE.init('FILE','DIRLUCRU',nfis);
qimg.setproperties;
-- Iniializeaz obiectul semntur
qsemn := ORDSYS.ORDIMAGESIGNATURE.init();
-- Creaz un obiect temporar pentru BLOB-ul obiectului semntur
DBMS_LOB.CREATETEMPORARY(qsemn.signature, TRUE);
-- Genereaz o semntur pentru imaginea folosit la cutare
qsemn.generateSignature(qimg);
OPEN getimg;
LOOP
-- stocheaz valorile id-ului i img pentru tuplul care ndeplinete condiia de asemnare
definit
Capitolul 15
432
FETCH getimg INTO idrez, vimage;
EXIT WHEN getimg%NOTFOUND;
END LOOP;
CLOSE getimg;
DBMS_LOB.FREETEMPORARY(qsemn.signature);
END;
end;

Procedura READIMG este folosit pentru afiarea, n aplicaia C#, a coninutului imaginii
preluate din tabel. Datorit volumului relativ mare al imaginilor, datele de tip imagine s-au
manipulat ca BLOB-uri ceea ce permite utilizarea n aplicaia C# a imaginii stocate n format
ORDImage.

CREATE PROCEDURE READIMG(vid IN number, flux OUT BLOB)
IS
BEGIN
DECLARE
obj ORDSYS.ORDImage;
numbytes BINARY_INTEGER := 32767;
startpos integer := 1;
read_cnt integer := 1;
ctx RAW(4000) := NULL;
BEGIN
SELECT img INTO obj FROM imagini WHERE id = vid;
obj.readFromSource(ctx,startpos,numbytes,flux);
startpos := startpos + numBytes;
read_cnt := read_cnt + 1;
EXCEPTION
WHEN NO_DATA_FOUND THEN
DBMS_OUTPUT.PUT_LINE('Sfarsit ');
END;
End;

Secvena de cod scris ntr-o aplicaie C# de tip WindowsForm pentru testarea
procedurilor stocate, definite anterior, se poate structura astfel:
- declararea unui obiect pentru a realiza conexiunea la o baza de date Oracle:
private OracleConnection con;
- realizarea conexiunii la baza de date:
string myConnString = "User ID=Mar;Password=ciab1100;Data Source=Oracl;";
con=new OracleConnection(myConnString);
- metoda de inserare a unui tuplu in baza de date:
private void Inserare_Click(object sender, System.EventArgs e)
{
con.Open();
ofd.ShowDialog();
OracleCommand cmd=new OracleCommand("SELECT count(*) FROM
mar.imagini",con);
object dr=cmd.ExecuteScalar();
//apelul procedurii stocate pentru inserarea unei inregistrari in baza de date
OracleCommand cmdins=new OracleCommand("inserare",con);
cmdins.CommandType = CommandType.StoredProcedure;
433
cmdins.Parameters.Add("vid",OracleDbType.Int32);
cmdins.Parameters.Add("vdescriere",OracleDbType.Varchar2,255);
cmdins.Parameters.Add("nfis",OracleDbType.Varchar2,24);
cmdins.Parameters[0].Value =nid;
cmdins.Parameters[1].Value =descr.Text;
char [] c=new char[1];
c[0]='\\';
string [] nf=new string[100];
nf=ofd.FileName.Split(c);
cmdins.Parameters[2].Value =nf[nf.Length-1];
cmdins.ExecuteNonQuery();
con.Close();
}
- apelul procedurii gen_semn pentru importul imaginilor din fiierele externe n baza de
date i generarea semnturilor necesare regsirii:
private void Semnaturi_Click(object sender, System.EventArgs e)
{
con.Open();
OracleCommand cmdsemn=new OracleCommand("gen_semn",con);
cmdsemn.CommandType = CommandType.StoredProcedure;
try
{
int nr=cmdsemn.ExecuteNonQuery();
}
catch (OracleException ex)
{
MessageBox.Show(ex.Message);
}
con.Close();
}

- metoda pentru cautarea imagini n baza de date prin parametrizarea indicatorilor de
cutare:
private void Cauta_Click(object sender, System.EventArgs e)
{
ofd.ShowDialog();
con.Open();
OracleCommand cmdcaut=new OracleCommand("cautare",con);
cmdcaut.CommandType=CommandType.StoredProcedure;
cmdcaut.Parameters.Add("nfis",OracleDbType.Varchar2);
cmdcaut.Parameters.Add("idimg",OracleDbType.Int32);
cmdcaut.Parameters[0].Direction=ParameterDirection.Input;
cmdcaut.Parameters[1].Direction=ParameterDirection.Output;
object d=new object();
char [] c=new char[1];
c[0]='\\';
string [] nf=new string[100];
nf=ofd.FileName.Split(c);
cmdcaut.Parameters[0].Value =nf[nf.Length-1];
try
Capitolul 15
434
{
d =cmdcaut.ExecuteScalar();
}
catch (Oracle.DataAccess.Client.OracleException ex)
{
}
if ((int)cmdcaut.Parameters[1].Value!=0)
{
OracleCommand cmdflux=new OracleCommand("readimg",con);
cmdflux.CommandType=CommandType.StoredProcedure;
cmdflux.Parameters.Add("vid",OracleDbType.Int32);
cmdflux.Parameters.Add("flux",OracleDbType.Blob,30000000,d,ParameterDi
rection.Output);
cmdflux.Parameters[0].Direction=ParameterDirection.Input;
cmdflux.Parameters[1].Direction=ParameterDirection.Output;
cmdflux.Parameters[0].Value=cmdcaut.Parameters[1].Value;
try
{
d =cmdflux.ExecuteScalar();
}
catch (OracleException ex)
{
}
Oracle.DataAccess.Types.OracleBlob
t=(Oracle.DataAccess.Types.OracleBlob)cmdflux.Parameters[1].Value;
Bitmap bmp=new Bitmap((System.IO.Stream)t);
pb.Image=bmp;
pb.Height=bmp.Height;
pb.Width=bmp.Width;
}
else
{
pb.Image=null;
MessageBox.Show("Nu exista nici o imagine asemanatoare!");
}
con.Close();
}

Baze de date online
435

Capitolul 16
Baze de date online

16.1. Elemente introductive

Plasarea pe Internet a unor colecii complexe de informaii presupune stocarea
acestora n baze de date care pot fi apoi accesate online de ctre utilizatori. Termenul de baz
de date online poate fi uor neltor, deoarece n realitate sistemul care face vizibil aceast
baz de date pe Internet este mult mai complex.
Nu exist o definiie unanim acceptat a bazelor de date online ns denumirea se
refer la acele baze de date al cror coninut poate fi accesat n timp real pe Internet.
Orice baz de date care ofer informaii utilizatorilor de servicii Internet trebuie
stocat pe un server care este vizibil pe Internet i s foloseasc o tehnologie de acces la baza
de date.
La ora actual, majoritatea covritoare a bazelor de date online sunt accesibile prin
intermediul paginilor web. Tehnologiile anterioare bazate pe aplicaii scrise n limbaje de
nivel nalt sunt rar folosite la dezvoltarea aplicaiilor noi. Exist o tendin ce se contureaz
tot mai intens de a oferi acces la bazele de date prin intermediul serviciilor web. Aceast
modalitate, ce folosete principiile SOA(Service Oriented Architecture), se extinde continuu
ns s-a rspndit puin pn n momentul de fa. Pe parcursul acestui capitol vom prezenta
tehnologiile de acces la bazele de date online folosind paginile web.
Informaiile din baza de date online trebuie extrase n conformitate cu nevoile
specifice ale utilizatorului i apoi formatate astfel nct s fie corect afiate. Spre exemplu,
cnd cineva scrie cuvntul Romnia pe motorul google.com sistemul va prelua solicitarea
din formularul de cutare, va caut n baza de date elementele n care apare cuvntul
Romnia dup care va formata aceste rezultate astfel nct ele s poate fi afiate de un
browser precum Internet Explorer.
Magazine on-line, forumuri de discuii, comuniti online pn la site-uri B2B sau
B2C, sunt exemple de aplicaii online care utilizeaz baze de date pentru generarea dinamic a
paginilor, crearea de conturi virtuale, creare de statistici i multe alte faciliti. Pentru unele se
realizeaz propria baz de date, altele utilizeaz baze de date deja existente, la care se
conecteaz i preiau informaiile necesare.
Din punct de vedere al tehnologiilor, orice SGBD poate fi folosit pentru a pune o baz
de date online. Totui s-a observat c unele SGBD-uri, n mod special Fox Pro i Access, au
rezultate foarte slabe i nu sunt recomandate. Pentru baze de date online cele mai folosite
SGBD-uri sunt: ORACLE, SQL Server i MySQL.
Bazele de date online pot fi instalate att pe sisteme Windows ct i pe oricare din
sistemele de operare din grupa Unix/Linux. Sunt preferate adesea sistemele de operare Linux
datorit costului redus la care aceste sisteme de operare reuesc s ofere performane ridicate.
O vedere general a arhitecturii serverului este oferit n figura 16.1. Dup cum se
observ din schema de mai sus, arhitectura sistemului este structurat pe mai multe nivele. n
Capitolul 16
436
momentul cand utilizatorul extern dorete s acceseze informaii situate pe server, el va folosi
un browser Internet pentru a se conecta la acesta. Accesarea serverul se face prin intermediul
unui URL.

Fig. 16.1 Arhitectura unui server web ce deservete o baz de date online

Elementele principale care intr n componena arhitecturii serverului sunt:
- Serverul de web care este o aplicaie complex responsabil pentru comunicarea cu
browserele externe. Practic serverul de web asculta portul HTTP al mainii pe care
este instalat. n momentul cnd sosete o cerere pe acest port, serverul de web o
interpreteaz pentru a vedea ce informaii au fost solicitate. Informaiile solicitate
de la server sunt de fapt fiiere care se afl pe hard-disk. Serverul de web are rolul
de a mpacheta aceste fiiere, astfel nct ele s poat fi trimise mai departe.
Fiierele solicitate pot fi mparite n dou categorii:
Fiiere care conin informaii statice. Acestea se transmit mai departe
ctre browsere fr nici un fel de modificare. Fiierele statice sunt de
obicei imagini, fiiere HTML, filme, documente oferite spre download,
filme Flash etc.
Scripturi. Acestea sunt practici mici programe care se execut de ctre
un interpretor, trimindu-se spre server-ul de web doar rezultatul
execuiei lor. Principalul rol al acestor script-uri este de a genera n
mod dinamic documente de tip . Tehnica generrii dinamice a
documentelor de tip HTML face posibil accesarea bazelor de date pe
Internet.
Utilizatori externi
Server Web
Interpretor de scripturi tip
server-side
SGBD
Fiiere HTML,
imagini, scripturi,
filme,
i alte fiiere care
conin date utile
Drivere
Baze de date online
437
- Interpretorul de scripturi tip server-side. Are rolul de a executa scripturi la cererea
serverului de web, de a prelua rezultatul unor interogri la nivelul bazelor de date
i de a trimite spre serverul de web rezultatul execuiei scripturilor. n momentul
cnd serverul de web i se solicit rularea unui script, acesta identific n funcie de
extensia fiierului, care din compilatoare trebuie s ruleze scriptul respectiv. n
cazul n care un script are nevoie de nregistrri dintr-o baz de date, acesta va
interaciona cu ea prin intermediul unui driver. El va executa n SQL o cerere la
nivelul bazei de date. n urma execuiei acestei cereri i se returneaz un cursor.
Prelucrnd acest cursor se genereaz cod HTML care odat ajuns la un browser
determin afiarea datelor dorite. Fiecare interpretor de scripturi se asociaz unui
limbaj de server-side scripting. Limbajele populare ale momentului sunt:
PHP(Personal Home Pages) i ASP(Active Server Pages). ASP.NET este o
versiune extins a ASP lansat de compania Microsoft n 2002 care tinde s
nlocuiasc clasica tehnologie ASP pe platformele Windows. La acestea se mai
adaug i o serie de alte tehnologii de interes mai restrns.
- Driverele de acces la baza de date au menirea de a mijloci interaciunea dintre
interpretorul de scripturi i baza de date propriu-zis. Ele sunt instrumente
software foarte specializate care de obicei nu sunt vizibile nici programatorului
nici utilizatorului. Driverele sunt importante deoarece alegerea lor eronat
afecteaz semnificativ performanele sistemului.
- SGBD-ul (sistem de gestiune a bazelor de date) relaional care fie este instalat pe
maina pe care se afl serveul de web, fie este accesibil prin reea sau Internet
(nerecomandat).Pentru aplicaiile web complexe este nevoie de SGBD-uri de mare
performan capabile s ruleze multe cereri simultan. Principalele SGBD-uri
folosite n aplicaiile web sunt:mySQL, SQL Server i Oracle.
- Coleciile de fiiere sunt informaii cu caracter static care sunt trimise utilizatorilor
la cerere.

16.2. Interfee de acces

16.2.1. Pagini Web dinamice

Principala interfa cu bazele de date online sunt paginile web generate dinamic.
Paginile Web dinamice sunt folosite atunci cnd se dorete modificarea dinamic, a
coninutului paginilor Web. Paginile Web realizate n HTML au dezavantajul c sunt statice,
coninutul lor neputnd fi modificat odat ce au fost ncrcate pe un server, dect aducndu-
le napoi pentru a fi editate. Acest lucru este o problem serioas avnd n vedere c operaia
este mare consumatoare de timp. n plus, lucrul cu baze de date nu este posibil n cazul
paginilor statice.
Spre exemplu, dac avem un site de Web format doar din pagini HTML care
afieaz notele i mediile studenilor pe serii i pe grupe i vrem s mai adugm nc un
student va trebui s modificm att pagina grupei ct i pagina seriei, precum i pe cele de
medii. Acest fapt este neplcut i ngreuneaz foarte mult munca.
Soluia care se adopt n astfel de situaii este plasarea informaiilor ntr-o baz de
date i accesarea lor ori de cte ori se cere acest lucru de cineva. Mai exact, n loc s se
creeze 3-4 pagini Web n HTML care s fie modificate ori de cte ori apare o schimbare, se
va crea o baz de date i cteva scripturi pe partea de server ce vor construi dinamic paginile
Capitolul 16
438
HTML care vor fi afiate. Schimbrile se vor face doar la nivelul bazei de date, ceea ce e
mult mai simplu.
Paginile Web se clasific n funcie de natura coninutului n pagini statice i pagini
dinamice.
Principalele caracteristici ale paginile Web statice sunt:
- conin doar elemente HTML;
- codul surs vizualizat n navigator este identic cu cel al fiierului stocat pe disc;
- nu ofer interactivitate.
Paginile Web dinamice se caracterizeaz prin urmtoarele:
- coninutul lor este creat dinamic i poate diferi la accesri diferite. De exemplu, la
acelai URL, coninutul paginii poate varia n funcie de anumii parametri cum ar fi
locaia geografic a utilizatorului, ora, paginile vizitate anterior, profilul
utilizatorului;
- ofer interactivitate;
- posibiliti de interaciune.
n funcie de locul n care este evideniat caracterul dinamic al paginilor exist pagini
dinamice pe parte de client i pagini dinamice pe partea de server.

16.2.2. Pagini dinamice pe partea client

Exist mai multe tehnologii care permit realizarea de pagini dinamice pe partea
de client. Dintre acestea se enumer:
- scripturi pe partea de client (client side scripts) ;
- DHTML (Dynamic HTML);
- Applet-uri Java;
- Controale ActiveX;
- Elemente multimedia
Scripturile pe partea de client (client side scripts) sunt secvene de program incluse
n pagina HTML care se execut de ctre navigator. Secvenele de program sunt incluse
prin marcatorul <SCRIPT> sau n proprietile anumitor componente HTML ca rspuns la
diferite evenimente. Limbajele utilizate pentru a realiza scripturi pe partea de client sunt
JavaScript, Jscript i VBScript. Secvenele de program scrise folosind aceste scripturi nu
ofer acces la resursele sistemului local (fiiere, reea). Scripturile pe partea de client sunt
utilizate pentru asigurarea interactivitii (meniuri), pentru validarea formularelor, pentru a
crea diferite efecte, pentru efectuarea de calcule, diverse elemente de animaie etc.
DHTML (Dynamic HTML) este o tehnologie dezvoltat de Microsoft care combin
HTML, foi de stiluri (CSS) i script-uri pentru a realiza pagini Web dinamice sau
interactive. Permite utilizatorilor s interacioneze cu pagina fr a retrimite o cerere la
serverul Web.
Applet-uri Java reprezint aplicaii de dimensiune redus, scrise n limbajul Java.
Codul binar al aplicaiei este descrcat pe maina client de pe server i executat local, n
maina virtual Java (JVM). Aproape toate calculatoarele permit execuia applet-urilor, ns
pentru funcionarea acestora este necesar instalarea unei maini virtuale Java.
n cadrul paginii HTML, applet-urile sunt incluse prin intermediul marcatorilor
<APPLET> sau <OBJECT>. Din applet-urile Java nu este permis accesul la sistemul local
de fiiere i la reea, astfel riscul ca aceste aplicaii s conin cod maliios sunt reduse.
Controalele ActiveX sunt componente binare incluse n paginile Web pentru a oferi
interactivitate. Sunt asemntoare applet-urilor, ns spre deosebire de acestea ruleaz pe
platforma Windows i au fost dezvoltate n special pentru Internet Explorer. Controalele
ActiveX sunt incluse n cadrul paginii Web prin intermediul marcatorului <OBJECT> spre
Baze de date online
439
deosebire de scripturile pe partea de client i nu au restricii n ceea ce privete accesul la
disc, ceea ce face ca anumite componente de acest tip s fie susceptibile de cod ruvoitor,
asemntor viruilor, viermilor sau cailor troieni. De aceea, n cazul n care o pagin
conine controale ActiveX, navigatorul printr-o fereastr de dialog cere confirmarea
utilizatorului pentru instalarea i rularea acestora.
Elemente multimedia sunt dezvoltate n general folosind produsul Macromedia Flash.
Acestea se prezint sub forma de fiiere SWF multimedia i sunt incluse n pagina Web prin
intermediul marcatorului <OBJECT>. Pentru a putea rula pe partea de client aceste fiiere
este necesar instalarea unui plug-in denumit Macromedia Shockwave Player. Fiierele
multimedia Flash se realizeaz sub forma unor filme, care sunt proiectate cadru cu cadru.
Acestea ofer diverse efecte multimedia (animaie, sunet) i permit interactivitatea cu
utilizatorul. Sunt utilizate pentru meniuri, jocuri, filme de animaie etc.

16.2.3. Pagini dinamice generate pe partea server

Interpretorul de scripturi tip server-side are rolul de a executa scripturi la cererea
serverului de Web, de cele mai multe ori de a prelua rezultatul unor interogri la nivelul
bazelor de date i de a trimite spre serverul Web rezultatul execuiei scripturilor sub forma de
coninut HTML pentru a putea fi afiat de ctre navigator. In momentul n care serverului
Web i se solicit rularea unui script, acesta identific n funcie de extensia fiierului care din
compilatoare trebuie s ruleze scriptul respectiv.

Fig. 16.2. Generarea paginilor dinamice pe server

Fiecrui interpretor de scripturi i se asociaz unui limbaj de server- side scripting.
Limbajele populare ale momentului sunt: PHP (Personal Home Pages), ASP (Active Server
Pages), ASP.NET i JSP (Java Server Pages). La acestea se mai adaug i o serie de alte
tehnologii de interes mai restrns.
Caracteristicile generale ale paginilor Web dinamice generate pe partea de server,
indiferent de limbajul de scripting folosit sunt:
- este necesar un procesor pentru paginile dinamice sau un mediu de execuie;
- ntr-o pagin de script (ASP, JSP, PHP) pot fi mbinate limbajul HTML i secvene
de cod;
- secvenele de cod sunt executate pe partea de server, nainte de a trimite pagina la
client;
- exist astfel posibilitatea de a particulariza paginile n mod dinamic;
- ofer posibilitatea de interaciune cu baze de date diferite;
- au acces la toate resursele serverului Web (fiiere, reea).
n mod uzual prin intermediul scripturilor sunt prelucrare informaiile din cmpurile
formularelor (<FORM>) din cadrul paginilor Web.

Navigator web

Server
web
Script
BD
Capitolul 16
440
16.3. Limbajul de scripting PHP

PHP (acronim pentru "PHP: Hypertext Preprocessor") este un limbaj de scripting de
uz general, cu cod-surs deschis (Open Source), utilizat pe scar larg, i care este potrivit n
special pentru dezvoltarea aplicaiilor Web i poate fi integrat n HTML. PHP este la ora
actual cel mai rspndit limbaj de scripting open-source fiind folosit de milioane de site-uri
de pe mapamond.
PHP a fost nceput n 1994 ca o extensie a limbajului server-side Perl, i apoi de o
serie de CGI-uri compilate de ctre Rasmus Lerdorf, pentru a genera un curriculum vitae i
pentru a urmri numrul de vizitatori ai unui site. Apoi a evoluat n PHP/FI 2.0, dar proiectul
open-source a nceput s ia amploare dup ce Zeev Suraski i Andi Gutmans, de la Technion
au lansat o nou versiune a interpretorului PHP n vara anului 1998, aceast versiune primind
numele de PHP 3.0. Tot ei au schimbat i numele n acronimul recursiv de acum, pn atunci
PHP fiind cunoscut ca Personal Home Page Tools. Apoi Suraski i Gutmans au rescris baza
limbajului, producnd astfel i Zend Engine n 1999. n mai 2000 a fost lansat PHP 4.0, avnd
la baz Zend Engine 1.0. Pe 13 iulie 2004 a fost lansat PHP 5, cu Zend Engine II, ce a adus i
o orientare obiect mai pronunat i suportnd mai multe caracteristici ale acestui tip de
programare.
PHP este simplu de utilizat, fiind un limbaj de programare structurat, ca i C-ul, Perl-
ul sau ncepnd de la versiunea 5 chiar Java, sintaxa limbajului fiind o combinaie a celor trei.
Datorit modularitii sale poate fi folosit i pentru a dezvolta aplicaii de sine stttoare, de
exemplu n combinaie cu PHP-GTK sau poate fi folosit ca Perl sau Python n linia de
comand. Probabil una din cele mai importante faciliti ale limbajului este conlucrarea cu
majoritatea bazelor de date relaionale, de la MySQL i pn la Oracle, trecnd prin MS Sql
Server, PostgreSQL, sau DB2.
PHP poate rula pe majoritatea sistemelor de operare, de la UNIX, Linux, Windows,
sau Mac OS X i poate interaciona cu majoritatea serverelor web. Codul dumneavoastr PHP
este interpretat de serverul WEB i genereaz un cod HTML care va fi vzut de utilizator
(clientului -browserului- fiindu-i transmis numai cod HTML).
Un exemplu de script php, poate fi observat mai jos(clasicul Hello World):
<?php
# comentariu pe o singur linie
// comentariu pe o singur linie
/*
comentariu pe
mai multe linii
se pot comenta linii de cod php
echo 'acesta este un echo comentat';
*/
echo 'Buna ziua';
?>

16.4. Limbajul de scripting ASP

Tehnologia Active Server Pages (ASP) dezvoltat de Microsoft permite realizarea de
scripturi pentru server i este folosit pentru crearea i rularea n mod dinamic a aplicaiilor
Web server interactive.
Baze de date online
441
Cu ASP se pot combina pagini HTML, comenzi de script i controale ActiveX pentru
crearea de pagini Web interactive sau aplicaii Web complexe. Cnd serverul primete o
cerere pentru un fiier ASP, prelucreaz scriptul coninut n fiier pentru a construi pagina de
Web care este trimis apoi la navigator.
ASP ofer totodat posibilitatea de a stoca informaia dintr-un formular HTML ntr-o
baz de date, de a personaliza site-uri Web, oferind diverse opiuni pentru vizitatorii site-ului
sau de a folosi diferite caracteristici HTML bazate pe navigator.
Pentru a prelucra un formular HTML pe server, ar trebui utilizat limbajul Perl sau C
pentru construirea unui CGI convenional. Cu ASP se poate prelua informaia dintr-un
formular HTML care va fi stocat ntr-o baz de date, folosind numai scripturi simple nglobate
n documente HTML.
ASP este proiectat independent de limbaj, deci se poate utiliza orice limbaj pentru care
exist instalat un compilator compatibil COM. ASP are nglobate limbajele VBSscript i
JScript., dar se pot instala i compilatoare pentru limbajele Perl, Rexx sau Python.
Totodat, ASP ofer o cale flexibil pentru a crea pagini Web i de a dezvolta aplicaii
Web ntr-un limbaj de programare ca Visual Basic, C++ sau Java. Se poate include i o sigl a
aplicaiei n module care vor fi apelate i executate de ctre alte componente sau programe.
Un script pentru server ncepe s se execute atunci cnd un program de navigare
solicit un fiier ASP de pe server. La rndul su, serverul apeleaz ASP-ul care prelucreaz
fiierul solicitat i execut fiecare comand din script, dup care trimite pagina ctre
programul de navigare.
Deoarece scripturile se execut mai mult pe server i mai puin pe client, serverul este
responsabil pentru generarea paginii HTML trimis ctre programul de navigare. n acest fel,
sursa scripturilor nu poate fi copiat (furat), deoarece la client (programul de navigare)
ajunge numai rezultatul scriptului, iar utilizatorul nu poate s citeasc comenzile scripturilor
care au creat pagina.
Scripturile ASP se creeaz de fapt n VBScript sau n JavaScript. Indiferent de
limbajul folosit, navigatorul proceseaz scripturile identic, rezultatul HTML formatat fiind
acelai.
Alturi de scripturi simple, ASP poate crea aplicaii complexe, cum sunt colectarea i
procesarea informaiilor de comand n aplicaii de comer electronic.
Un fiier ASP este un fiier text cu extensia (.asp), ce conine orice combinaie a
urmtoarelor elemente: text, marcatori HTML, comenzi de script ASP.
Dac se dorete adugarea unor scripturi la o pagin HTML, mai nti va trebui s se
redenumeasc fiierul, atribuindu-i extensia (.asp). Pentru a-l face accesibil utilizatorilor Web,
este necesar activarea permisiunii de script sau de execuie pentru directorul unde se afl
fiierul respectiv.
Pentru crearea fiierului ASP se poate folosi orice editor de text, dar este preferat un
mediu cu suport pentru ASP cum este Microsoft Visual Studio sau Macromedia
Dreamweaver.
Un script este constituit dintr-o serie de comenzi sau instruciuni. Fa de marcatorii
HTML care formateaz un text sau prelucreaz un format de imagine, de video sau de sunet,
comenzile de script indic serverului Web s execute o aciune.
Comenzile de script sunt difereniate de text prin delimitatori. Un delimitator este un
caracter sau o secven de caractere care marcheaz nceputul sau sfritul unei uniti. ASP
utilizeaz pentru includerea comenzilor, delimitatorii <% i %>.
Comenzile incluse ntre delimitatori sunt comenzi de script primare. Aceste comenzi
sunt procesate folosind un limbaj de script primar. Limbajul implicit este VBScript, dar poate
fi folosit orice limbaj de script pentru care este instalat un compilator.
Capitolul 16
442
ntre delimitatorii ASP se poate include orice expresie, structur, procedur sau
operator valid pentru limbajul de script respectiv.
ASP permite creatorului de pagini Web s scrie proceduri prin folosirea mai multor
limbaje de script. Deoarece fiierele (.asp) sunt interpretate pe server, navigatorul clientului
nu trebuie s aib suport pentru scripturi.
ASP are inclus dou motoare de scripting: Microsoft Visual Basic Scripting Edition
(VBScript)-implicit i Microsoft JScript, dar se pot instala motoare i pentru alte limbaje.
n tabelul 16.1 sunt prezentate principalele caracteristici ale limbajelor VBScript i
JScript, dintre care o parte vor fi detaliate n continuare.

Tabelul 16.1. Caracteristici ale limbajelor de script

Caracteristica VBScript JScript
Cometarii //
Case sensitive NU DA
Variabile Dim var
Constante Const vart

VBScript nu este case sensitive, astfel c un cuvnt scris cu majuscule are aceeai
semnificaie dac este scris i cu minuscule. De exemplu, Request i request se refer la acelai
obiect ASP (Request). Jscript este case sensitive, deci scrierea unui cuvnt cu caractere
majuscule sau minuscule influeneaz semnificaia acestuia.
Declararea unei variabile echivaleaz cu rezervarea unei locaii de memorie n care se
va introduce o dat (un numr sau un text). Data introdus n variabil reprezint valoarea
variabilei.
VBScript nu necesit declararea unei variabile nainte de utilizare, dar este
recomandat efectuarea ei. n acest scop se folosesc cuvintele cheie: Dim, Public sau
Private.
Cu <% Dim UserName %> se declarat o variabil de tip variat, adic
poate s conin orice tip de dat.
Dac la nceputul fiierului (.asp) s-a introdus comanda Option Explicit, atunci
declararea variabilelor VBScript devine obligatorie.
n JScript declararea variabilelor este impus numai pentru variabilele locale din
proceduri, dar este recomandat declararea oricrei variabile nainte de folosire. Pentru
declararea unei variabile se folosete cuvntul cheie var:
<% var UserName; %>
Alturi de variabile locale i globale, se pot declara variabile dup domenii: variabile
de sesiune i variabile de aplicaie. Variabilele globale sunt accesibile numai pentru o singur
pagin (.asp). O variabil avnd domeniul de sesiune este accesibil pentru toate paginile
dintr-o aplicaie ASP rulat de un client. Aceste tipuri de variabile sunt utile pentru stocarea
de informaii pentru un singur client; de exemplu, preferinele sau numele clientului respectiv.
O variabil avnd domeniul de aplicaie, este accesibil pentru toate paginile dintr-o aplicaie
ASP rulat de orice client. Pentru a declara o variabil cu domeniu de sesiune, se folosete
obiectul Session n care se va salva numele i valoarea variabilei. De exemplu, n urmtorul
script sunt salvate valorile a dou variabile de sesiune Nume i Prenume:
< %
Session ( Nume ) = Popescu
Session ( Prenume ) = Ionel
% >

Pentru accesarea variabilei cu domeniu de sesiune se folosete tot obiectul Session:

Baze de date online
443
< % If Session Prenume) = Ionel Then % > Ati vizitat deja
pagina.
< % Else % >
Este prima vizita in aceasta pagina.
< % End If % >
Pentru a declara o variabil cu domeniu de aplicaie, se folosete obiectul
Application, n care seva salva numele i valoarea variabilei. De exemplu:
< % Application (salut) = O zi bun ! % >
O constant este alctuit dintr-un identificator ce nlocuiete un numr sau un ir
de caractere. Unele componente ASP cum sunt ActiveX Data Objects (ADO), definesc
constantele care pot fi folosite n scripturi; declararea constantelor se realizeaz n
componenta type library constituit sub forma unui fiier n care se regsesc informaiile
privind obiectele i tipurile acceptate de o component ActiveX.
Pentru a declara tipul bibliotecii se folosete marcatorul <METADATA> n fiierul
Global al aplicaiei.
n VBScript declararea constantelor se efectueaz cu directiva Const, iar n JScript cu
directiva var.
Paginile ASP pot utiliza cteva directivele care nu aparin limbajului de script propriu
zis. Ele se mpart n dou categorii: directive de ieire i directive de procesare.
Directivele de ieire au rolul de a afia valoarea unei expresii specificate ntre
delimitatori; sunt de forma:
<% =expresie %>
O directiv de ieire este echivalent practic, cu o comand Response.Write.
Directivele de procesare furnizeaz informaii privitoare la modalitatea de procesare a
fiierului (.asp). Formatul unei directive de procesare este:
<% @ cuvnt_cheie %>
Directiva de procesare <%@ LANGUAGE=VBScript %> seteaz VBScript ca limbaj
de script implicit pentru pagin. Directiva trebuie s apar n primul rnd al fiierului (asp).
Observaie: nu se pot specifica directive de procesare ntr-un fiier (.asp) inclus cu
directiva #include.
Cuvintele cheie ce se pot utiliza n cadrul directivelor de procesare sunt:
- LANGUAGE seteaz limbajul de script implicit al paginii;
- CODPAGE seteaz pagina de cod a paginii ASP;
- LCID seteaz identificatorul local al paginii;
- TRANSACTION verific dac pagina va rula n context tranzacional;
- ENABLESESSIONSTATE arat dac se va activa modul sesiune pentru pagina
respectiv.
Ca orice limbaj de programare, VBScript i JScript pun la dispoziie structuri
fundamentale de programare. Exemplul urmtor utilizeaz o structur alternativ
IfThenElse n VBScript:

<%
If Time >=#06:00:00 AM# And Time< #20:00:00 PM#
Then
Else
salut= O zi bun !
salut= Noapte bun !
End If
%>
<% = salut %>
Capitolul 16
444

n funcie de ora la care se solicit execuia, rezultatul ce se afieaz va fi O zi bun
! sau Noapte bun ! . Comanda <% = salut %> trimite valoarea variabilei salut ctre
navigator.
Comenzile ASP pot fi intercalate cu text HTML. n exemplul anterior, se poate realiza
acelai lucru n felul urmtor:

<% If Time>= #06:00:00 AM# And Time< #20:00:00 PM# Then %>
O zi bun !
<%Else%>
Noapte bun !
<% End If %>

16.4.1. Crearea obiectelor

Cheia dezvoltrii aplicaiilor Web complexe sunt componentele ActiveX. Ele
furnizeaz obiectele care se folosesc n scripturi pentru scopuri diverse.
O component ActiveX este un fiier care conine instruciuni pentru realizarea unui
anumit program specific. Componentele sunt reutilizabile. Odat ce s-a instalat o
component pe un server Web, ea poate fi apelat dintr-un script ASP, dintr-o aplicaie
ISAPI, dintr-o alt component sau dintr-un program scris ntr-un alt limbaj compatibil
COM.
O component este un program executabil coninut ntr-un fiier cu extensia .dll
(dynamic link library) sau .exe. O component poate instania obiecte, iar prin obiecte se pot
accesa proprietile i metodele.
Instanierea unui obiect se face cu metoda ASP Server.CreateObject care returneaz
referina ctre obiectul creat, referin ce trebuie pstrat ntr-o variabil.
n ASP, pentru crearea obiectelor nu se folosete funcia limbajului de script
(CreateObject n VBScript i New n Jscript). Exemplul urmtor creeaz o instan a
componentei AdRotator.
<% Set MyAds = Server.CreateObject (MSWC.AdRotator) %>
Obiectele se pot crea i prin intermediul marcatorului HTML <OBJECT>:
<OBJECT RUNAT=Server ID=MyAd PROGID=MSWC.AdRotator>
</OBJECT>
ASP are cteva obiecte incluse, ce conin datele trimise spre server de ctre
formularul HTML. Aceste obiecte nu trebuie instaniate, ele pot fi folosite direct n
scripturi.
Obiectul Application se folosete pentru a partaja informaiile ctre toi clienii unei
aplicaii.
Obiectul Request este folosit pentru a accesa orice informaii trimise printr-o cerere
HTTP. Aceste informaii pot fi:
- parametri trimii dintr-un formular HTML prin metoda POST sau GET,
- cookie-uri;
- alte certificri ale clienilor.
Obiectul Request face totodat posibil accesarea informaiilor trimise sub form
binar, cum sunt transmisiile de fiiere.
Obiectul Response controleaz informaiile transmise ctre client. Controlul include
transmiterea de informaii direct ctre navigator, redirectarea navigator-ului ctre un alt URL
sau setarea unor valori cookie.
Baze de date online
445
Trimiterea de text HTML ctre navigator se poate realiza i prin intermediul
comenzilor de script, situaie n care se va folosi obiectul Response. Exemplul anterior poate fi
realizat astfel:
<%
If Time >=#06:00:00 AM# And Time< #20:00:00 PM# Then
Else
Response.Write O zi bun !
Response.Write Noapte bun !
End If
%>

Funcia Write a obiectului Response are rolul de a trimite textul ctre navigator.
Obiectul Server asigur accesul la metodele i proprietile de pe server. Cea mai
folosit metod este aceea care instaniaz o component ActiveX (Server.CreateObject).
Alte metode sunt codificarea URL sau HTML a irurilor de caractere, maparea cilor
virtuale n ci fizice sau setarea perioadei de timeout pentru un script.
Obiectul Session se utilizeaz pentru a pstra informaii pentru o sesiune particular.
Informaiile din obiectul Session nu sunt pierdute ct timp utilizatorul se plimb printre
pagini, ele persistnd de lungul accesrii paginilor aplicaiei de ctre client.
Obiectul ObjectContext se folosete pentru a realiza sau abandona o tranzacie iniiat
de un script ASP.
Se pot defini i obiecte proprii n Jscript, prin crearea unei funcii constructor care
creeaz i iniializeaz proprietile i metodele unui obiect nou. Obiectul este instaniat cnd
n script se utilizeaz operatorul new care apeleaz constructorul. Dac obiectele JScript
sunt definite cu domeniu de sesiune sau de aplicaie, atunci nu pot fi accesate metodele
lui.
Cnd este prelucrat un script ASP, orice text n afara delimitatorilor ASP sau a
marcatorilor <SCRIPT> este returnat ctre navigator. Informaiile ctre navigator pot fi
trimise explicit prin obiectul Response, metoda Write.

16.5. Exemplu de lucru cu baze de date online

Pentru a putea realiza un script ASP trebuie s avem umtoarele:
- Un calculator pe care s fie configurat un server de web(ex. Internet Information
Server). Orice sistem Windows poate fi uor configurat s suporte scripturi ASP.
- Un editor. Putem folosi Wordpad sau editoare specializate cum este Macromedia
Dreamweaver.
- Un browser web cu care s vedem rezulatul execuiei scriptului.
Avnd n vedere c scripturile ASP sunt realizate de obicei pentru a lucra cu baze de
date putem spune c avem nevoie i de o baz de date pentru a executa scriptul. Aceasta
trebuie s fie pe acelai calculator cu scriptul, preferabil n acelai director. Spre exemplu
baza de date din figura 16.3 care conine o singur tabel numit studeni i este realizat n
Microsoft Access. Ea conine o list de studeni care au susinut un anumit examen:
Vom realiza un script ASP care afieaz aceti studeni. Scriptul ASP realizat de noi
va fi unul minimal i va realiza trei operaii:
- Conectarea la baza de date. Este o operaie care se realizeaz de ctre sistem,
utilizatorul fiind responsabil doar pentru furnizarea parametrilor de
Capitolul 16
446
conectare(denumire baz de date i driver ). Nu vom intra n detalii legate de
aceast parte i rugm cititorul s ia secvena de cod ca atare.
- Interogarea bazei de date. Se realizeaz n limbajul SQL (Standard Query
Language) i se face n baza unei cereri SQL construite de realizatorul scriptului.
- Prelucrarea informaiilor returnate de cererea de cutare i afiarea lor.

Fig. 16.3. Tabela Studeni

Se observ ca secvenele de cod ASP sunt marcate cu <% %>. n felul acesta
serverul poate s le recunoasc i s le ruleze. Ele sunt plasate printre secvene de cod HTML
care sunt ignorate de interpretorul ASP i sunt trimise mai departe spre browser far nici o
prelucrare.
<html
<head>
<title>Scriptul meu</title>
</head>
<body>
//Se creaza obiectul server
set myconn = server.createobject("adodb.connection")
//Se presupune ca baza de date se afla in sub-directorul baza_mea din directorul My
Webs al utilizatorului cm1901
dbpath = server.mappath("/~cm1901\baza_mea")
//Secventa de conectare
Baze de date online
447
connection = "PROVIDER=Microsoft.Jet.OLEDB.4.0;DATA SOURCE=" & dbpath &
"\studenti.mdb"
myconn.open(connection)
//Interogarea bazei de date
set result = server.createobject("adodb.recordset")
sql = "SELECT * FROM studenti"
set result = myconn.execute(sql)
//Afisarea rezultatelor
while not result.EOF
response.write("<br>" & result("nume"))
response.write("<br>" & result("prenume"))
response.write("<br>" & result("nota"))
response.write("<br>" & result("grupa"))
result.movenext()
wend
</body>
</html>

16.6. Aplicaie demonstrativ

In cele ce urmeaz vom prezenta o aplicaie care gestioneaz o baz de date. Aplicaia
este o versiune simplificat a clasicelor interfee web pentru managementul tabelelor. Codul a
fost scris n mod cu comentarii pentru a permite cititorilor interesai de lucrul cu ASP s i
rafineze cunotintele prin rularea ei pe un calculator personal. Tehnologiile folosite sunt ASP
clasic pentru partea de server-side scripting i SQL Server ca SGBD.
Scripturile ASP sunt n numr de apte i au functionaliti specifice administrrii
bazelor de date. Exist un script central (default.asp) i o serie de scripturi funcionale care
conin codul ASP propriu-zis. In general, recomandm cititorilot ca pe parcursul dezvoltrii
scripturilor, s nu se grupeze mai mult de cteva funcii ntr-un script, deoarece astfel se poate
urmri cu uurin firul logic al aplicaiei.

Default.asp

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Microsoft FrontPage 6.0">
<title>Utilitar online de maintenanta a Serverului SQL</title>
</head>

Capitolul 16
448
<body bgcolor="#FFFFFF">
<font face="Verdana">

<center>
<h1><font color="blue">Utilitar online de maintenanta a Serverului SQL</font></h1>

<P>

<table cellpadding=10 border=2 bgcolor="Aqua" width=300><tr><td>
<form action="ServerAdmin.asp" method="POST">
<table border="0">
<tr>
<th align="right">Nume server:</th>
<td><input type="text" size="20" maxlength="256" name="ServerName"
value="<%=Request.ServerVariables("SERVER_NAME")%>">
</td>
</tr>
<tr>
<th align="right">Nume de utilizator:</th>
<td><input type="text" size="20" maxlength="256" name="Login"
value="<%=Request.ServerVariables("LOGON_USER")%>">
</td>
</tr>
<tr>
<th align="right">Parola:</th>
<td><input type="password" size="20" maxlength="256" name="Password">
</td>
</tr>
<tr>
<td></td><td align=left>
<P><input type="submit" value="Conectati-va">
</td>
</tr>
</table>
</form>
</td></tr></table>

</center>
</body>
</html>

Databases.asp

<%@ LANGUAGE = VBScript %>

<HTML>
<HEAD>
<META NAME="GENERATOR" Content="Microsoft Developer Studio">
<META HTTP-EQUIV="Content-Type" content="text/html; charset=ISO-8859-1">
<TITLE>Baza de date Online</TITLE>
Baze de date online
449
</HEAD>

<HTML>
<BODY BGCOLOR="aqua" leftmargin=5 topmargin=5>

<%
On Error Resume Next

If Not IsObject(Session("SQLServer")) Then
Response.Write("Obiectul conexiunii SQL Server nu exista!")
Response.End
End If

Dim oSQLServer
Set oSQLServer = Session("SQLServer")
%>

<FORM ACTION="DBItems.asp" METHOD="GET" TARGET="dbitems">
<table><tr><td><B>Baza de date:</B></td><td>
<SELECT NAME="Database">
<%
For Each SQLDB In oSQLServer.Databases
If Not SQLDB.SystemObject Then
Response.Write "<OPTION VALUE=""" & SQLDB.Name & """>" & SQLDB.Name &
" "
End If
Next
Set oSQLServer = Nothing
%>
</SELECT>
</td><td><INPUT TYPE="submit" VALUE="Arata!"></td></tr></table>
</FORM>

</BODY>
</HTML>

Dbitems.asp


<HTML>
<HEAD>
</HEAD>

<BODY BGCOLOR=#ffffff leftmargin=5 topmargin=5>
<FONT FACE=Arial>

Capitolul 16
450
<%
' On Error Resume Next

If Not IsObject(Session("SQLServer")) Then
Response.Write("Obiectul conexiunii SQL Server nu exista!")
Response.End
End If

Dim oSQLServer
Set oSQLServer = Session("SQLServer")

' acum gasim baza de date de care avem nevoie
Set thisDb = oSQLServer.Databases(CStr(Request("Database")))
If Err.Number > 0 Or Not IsObject(thisDb) Then
Response.Write("Baza de date nu exista pe Serverul SQL!<BR>" & Err.Description)
Response.End
End If

Set Session("ActiveSQLdb") = Nothing
Set Session("ActiveSQLdb") = thisDb
%>
<H2><font color="blue"><%=thisDb.Name%></font></H2>
<A HREF="isql.asp" target="showpane"><I>Utilitar ISQL</I></A><P>
<B>Tabele</B>
<font size=-1>
<UL>
<%
For Each DBTable In thisDb.Tables
If Not DBTable.SystemObject Then
Response.Write "<LI>" & "<A TARGET=""showpane""
HREF=""DBMap.asp?DBOType=Table&DBObject=" & DBTable.Name & """>" &
DBTable.Name & "</A>" & Chr(13)
End If
Next
%>
</font>
</UL>

<P>
<B>Viziuni</B>
<font size=-1>
<UL>
<%
For Each DBView In thisDb.Views
If Not DBView.SystemObject Then
HREF=""DBMap.asp?DBOType=View&DBObject=" & DBView.Name & """>" &
DBView.Name & "</A>" & Chr(13)
End If
Next
Baze de date online
451
%>
</font>
</UL>

<P>
<B>Proceduri Stocate</B>
<font size=-1>
<UL>
<%
For Each DBsp In thisDb.StoredProcedures
If Not DBsp.SystemObject Then
HREF=""DBMap.asp?DBOType=SP&DBObject=" & DBsp.Name & """>" & DBsp.Name
& "</A>" & Chr(13)
End If
Next
%>
</font>
</UL>
<P>

<%
%>

</BODY>
</HTML>

Dbmap.asp


<HTML>
<HEAD>
</HEAD>

<FONT FACE=Arial>

<%

If Not IsObject(Session("ActiveSQLdb")) Then
Response.Write("Nu a fost stabilita nici o conexiune cu baza de date!")
Response.End
End If

Capitolul 16
452
Dim thisDb
Set thisDb = Session("ActiveSQLdb")

Select Case Request("DBOType")
Case "Table"
Set theTable = thisDb.Tables(CStr(Request("DBObject")))
If Err.Number > 0 Then
Response.Write("Tabela nu exista in baza de date!<BR>" & Err.Description)
Response.End
End If
PrintTable theTable
Set theTable = Nothing

Case "SP"
Set theSP = thisDb.StoredProcedures(CStr(Request("DBObject")))
Response.Write("PS nu exista in baza de date!<BR>" & Err.Description)
Response.End
End If
PrintSP theSP
Set theSP = Nothing

Case "View"
Set theView = thisDb.Views(CStr(Request("DBObject")))
Response.Write("Viziunea nu exista in baza de date!<BR>" & Err.Description)
Response.End
End If
PrintView theView
Set theView = Nothing

Case Else
Response.Write("Actiune selectata non valida!")
Response.End
End Select

Set thisDb = Nothing
%>

<SCRIPT RUNAT=SERVER LANGUAGE=VBScript>

Sub PrintView(thisView)
If Not thisView.SystemObject Then
Response.Write "<CENTER><H3>" & thisView.Name & " viziune</H3><CENTER>"
Response.Write "<TABLE BORDER=1 WIDTH=""80%""><tr><td>"
Response.Write "<PRE>" & thisView.Text & "</PRE>"
Response.Write "</td></tr></TABLE>"
End If
End Sub

Baze de date online
453
Sub PrintSP(thisSP)
If Not thisSP.SystemObject Then
Response.Write "<CENTER><H3>" & thisSP.Name & " procedura
stocata</H3><CENTER>"
Response.Write "<TABLE BORDER=1 WIDTH=""80%""><tr><td>"
Response.Write "<PRE>" & thisSP.Text & "</PRE>"
Response.Write "</td></tr></TABLE>"
End If
End Sub

Sub PrintTable(thisTable)
If Not thisTable.SystemObject Then
HasDef = False
Response.Write "<CENTER><H3>" & thisTable.Name & " tabela</H3><CENTER>"
Response.Write "<TABLE BORDER=1 WIDTH=""80%"">"
Response.Write
"<tr><th>Name</th><th>Datatype</th><th>Length</th><th>Indexinfo</th></tr>"

For Each DBField In thisTable.Columns
Indexed = False
PK = False
Response.write "<TR><TH WIDTH=""35%"">"
Response.write DBField.Name & "</TH><TD WIDTH=""15%"">"
Response.write DBField.Datatype & "</TD><TD WIDTH=""15%"">"
Response.write DBField.Length & "</TD><TD WIDTH=""15%"">"
If DBField.InPrimaryKey Then
PK = True
Else
PK = False
End If

If DBField.AllowNulls Then
Nulls = True
Else
Nulls = False
End If

DefID = dbfield.default
DefID = Mid(DefID, 5, Len(DefID))

For Each DBDefault In thisDb.Defaults
If DefID = DBDefault.Name Then
DefArray(I, 0) = thisTable.Name
DefArray(I, 1) = DBField.Name
DefArray(I, 2) = DBDefault.Text
I = I + 1
HasDef = True
End If
Next
Capitolul 16
454

For Each DBIndex In thisTable.Indexes
If DBIndex.Name = DBField.Name Then
Indexed = True
Exit For
End If
Next
If PK Then
Response.write "Cheie & Indexat "
Else
If Indexed Then
Response.write "Indexat "
End If
End If
If Not Nulls Then
Response.write "Not Null"
End If
If HasDef Then
Response.write "<EM>(" & I & ")</EM>"
HasDef = False
End If
Response.write "&nbsp</TD></TR>"
Next
Response.write "</TABLE><BR><BR>"
End If
End Sub

</SCRIPT>

</BODY>
</HTML>

I sql.asp


<HTML>
<HEAD>
<TITLE>Baza de date ISQL Online</TITLE>
</HEAD>

<FONT FACE=Arial>

<%
'On Error Resume Next

If Not IsObject(Session("ActiveSQLdb")) Then
Baze de date online
455
Response.Write("Nu a fost stabilita nici o conexiune cu baza de date!")
Response.End
End If

Dim thisDb
Set thisDb = Session("ActiveSQLdb")
%>
<center>
<H2><font color="blue"><%=thisDb.Name%></font> - Utilitar ISQL</H2>

<%
If Len(Request("isqlhtm"))>0 Then
Select Case Request("isqltype")
Case "nores"
thisDb.ExecuteImmediate Request("isqlhtm"),SQLOLEExec_Default
Case Else
Set qryResults = thisDb.ExecuteWithResults(Request("isqlhtm"))
End Select

nColNumbers = qryResults.Columns
Response.Write "<TABLE BORDER=1><TR>"
For i=1 To nColNumbers
Response.Write "<TH>" & Server.HTMLEncode(qryResults.ColumnName(i)) & "</TH>"
Next
Response.Write "</TR>"

nRowsToReturn = qryResults.Rows
If nRowsToReturn > CLng(Request("isqlrows")) Then nRowsToReturn =
CLng(Request("isqlrows"))

For i=1 to nRowsToReturn
Response.Write "<TR>"
For j=1 to nColNumbers
Response.Write "<TD>" & Server.HTMLEncode(qryResults.GetColumnString(i,j))
& "</TD>" & Chr(13)
Next
Response.Write "</TR>"
Next
Response.Write "</TABLE> <P>"
Response.Write "Maxim " & qryResults.Rows & " de inregistrari vor fi disponibile!<BR>"

Set qryResults = Nothing
Set thisDb = Nothing
%>

<P>
Inapoi la ecranul principal <A
HREF="<%=Request.ServerVariables("SCRIPT_NAME")%>">ISQL</A>!

<% Else %>
Capitolul 16
456
<table border=0>
<tr><td>
<FORM ACTION="<%=Request.ServerVariables("SCRIPT_NAME")%>" method="post">
<TEXTAREA cols=90 rows=20 NAME="isqlhtm">Select * from
tablename</TEXTAREA><BR>
</td></tr>
<tr><td> <BR>
<input type=radio name=isqltype value="nores">Fara rezultate
<input type=radio CHECKED name=isqltype value="res">Returneaza rezultate<P>
Numarul maxim de linii de returnat:
<input type=text name=isqlrows value="25"><P>
<input type=submit value="Ruleaza!">
</FORM>
</td></tr></table>
<% End If %>

</center>
<P>
<P ALIGN=right><font size=1>© 2007 Crystal-System</font></P>

</BODY>
</HTML>

Serveradmin.asp


<HTML>
<HEAD>
<TITLE>Administrare Online a bazei de date pentru
<%=Request.Form("Servername")%></TITLE>
</HEAD>

<%
Dim oSQLServer
Set oSQLServer = CreateObject ("SQLOLE.SQLServer")

Set Session("SQLServer") = Nothing

Response.Write("SQLOLE nu a putut fi initializat!<BR>" & Err.Description)
Err.Clear
Response.End
End If

strServer = Request.Form("ServerName")
strLogin = Request.Form("Login")
Baze de date online
457
strPwd = Request.Form("Password")

oSQLServer.Connect strServer,strLogin,strPwd

Response.Write("Conexiune nereusita cu Serverul SQL!<BR>" & Err.Description)
Err.Clear
Response.End
End If

Set Session("SQLServer") = Nothing
Set Session("SQLServer") = oSQLServer
%>

<FRAMESET FRAMEBORDER="0" FRAMESPACING="0" COLS="300,*">
<FRAMESET FRAMEBORDER="0" FRAMESPACING="0" ROWS="50,*">
<FRAME MARGINWIDTH="2" MARGINHEIGHT="0" SRC="Databases.asp"
NAME="databases" NORESIZE SCROLLING="no">
<FRAME MARGINWIDTH="2" MARGINHEIGHT="0" SRC="pane1.htm"
NAME="dbitems" NORESIZE SCROLLING="auto">
</FRAMESET>
<FRAME MARGINWIDTH="10" MARGINHEIGHT="5" SRC="emptypage.htm"
NAME="showpane">
</FRAMESET>

<BODY BGCOLOR=#ffffff topmargin=0 leftmargin=0>
<Font face=Verdana>

Frames required!

</BODY>
</HTML>

Paginile HTML statice. In aplicaie sunt incluse i dou pagini statice scrise n cod
HTML care sunt necesare pentru buna funcionare a site-ului.

pane1.html

<HTML>
<HEAD>
<TITLE>Online Database</TITLE>
</HEAD>

<FONT FACE=Arial>

<H2><font color="blue">Numele bazei de date</font></H2>
Capitolul 16
458

<B>Tabele</B><font size=-1>
<UL>
<LI>primul tabel</font>
</UL>

<P>
<B>Viziuni</B>
<font size=-1>
<UL>
<LI>prima viziune</font>
</UL>

<P>
<B>Proceduri Stocate</B>
<font size=-1>
<UL>
<LI>prima procedura stocata </font>
</UL>
<P>

</BODY>
</HTML>

Emptypage.html

<HTML>
<HEAD>
</HEAD>

<BODY BGCOLOR=#ffffff>
<Font face=Arial>Pasii necesari pentru a vizualiza baza de date SQL
<OL>
<LI>Selectati o baza de date <LI>Selectati un obiect al bazei de date (momentan doar
Tabela, Viziune si Procedura Stocata)
</OL>
<A HREF="Information.htm" target="_top">Informatii</A> suplimentare.
</BODY>
</HTML>

Bibliografie
459

Bibliografie

1. Avram Vasile, Gheorghe Dodescu Informatics Computer Hardware and
Programming in Visual Basic, Ed. Economic Bucureti.
2. Ashley Friedlein Web project management, Ed. Morgan Kaufman Publischer.
3. C. Bodea, Gh. Sabu, E. Posdarie Sisteme informatice economice. Analiza i
proiectarea orientat obiect utiliznd UML,. INFOREC, Printing House, Bucureti,
2001.
4. Booch G., Rumbaugh H., and Jacobson The Unified Modeling Language User
Guide, Ed. Addison Wesley, 1999.
5. Berson A. and Smith S. J. Data Warehousing, Data Mining & OLAP, New Zork, Ed.
Mc. Graw, Hill, 1997.
6. Booch G. Object Oriented Analysis and Design, Ed. Addison Wesley, 1994.
7. R. Bologa ERP as a support for the Knowlege Age, Revista Informativ Economic,
nr.44, Bucureti, 2007.
8. Brenda Kienan Managing our e-commerce business, Ed. Microsoft Press, 2001.
9. C. Crstea, M. Crstea, Gh. Sabu SGDB Access 2000. Aplicaii i teste gril, Ed.
Omnia Uni SAST, Braov, 2001.
10. Cattell R. and Barry, D. The Object Database Standard: OMG 3.0, Morgan
Kaufmann, San Francisco, 2000
11. R.G.G. Cattell Bases de Donnees Orientees Objets. 2-e edition, Ed. Addison
Wesley, 1997.
12. R.G.G. Cattell Object Data Management Reading, Mass., Ed. Addison Wesley,
1994.
13. Carl H. Speshoch Microsoft SQL-Server 2000, Prentice Hall, 2002.
14. Claude Seidman Data Mining with Microsoft SQL Server 2000, Microsoft Press
2001.
15. Charles J. Lyons Essential Design for Web Professionals, Ed. Prentice Hall, 2001.
16. Chris Todman Designing a data warehouse, Ed. Prentice Hall, 2001.
17. Codd E. The Relational Model for Database Management, Version 2. Addison-
Wesley, Boston, MA, 1990.
18. Codd E. Twelve rules for on-line analytic processing, Computerworld, April 13.
19. Craig Larman Applying UML and Patterns. An Introduction to Object Oriented
Analysis and Design, Ed. Prentice Hall PTR, 1998.
20. C. J. Date The Relational Database Dictionary, Ed. OReilly Media, 2006.
21. C. J. Date An introduction to Database Systems, Ed. Addison Wesley, 2004.
22. O. Diay Advanced database technology and design, Ed. Piattini, 2000.
23. Dan Woods and Thomas Mattern Entreprise SOA: Designing IT for Business
Innovation, Ed. OReilly, 2006.
24. C. J. Date, Hugh Darwen Databases, Types and Relational Model. The Third
Manifesto, Ed. Addison Wesley, 2007.
25. Dan Gookin Digital Scanning and Photography, Microsoft Press, 2000.
26. David Egan, Paul Zikopouls DBAs guide to databases in Linux, Ed. Szngress
Publishing, 2000.
27. David Karlins Corel Draw 9 n 24 ore, Ed. Teora, 2001.
Bibliografie
460
28. Dodescu Gheorghe, I. Roca, Gh. Sabu, I. Ivan, C. Apostol, I. Odgescu
Informatic, Ed. tiinific i enciclopedic. Bucureti, 1987.
29. Florescu Vasile, Berbec Florentina, Nstase Pavel, Stanciu Victoria .a. (Grupul
BDASEIG) Baza de date. Fundamente teoretice i practice, Editura Infomega,
2002.
30. Garcia Molina H., Uman J. and Widon Database System Implementation, Ed.
Prentice Hall, 2000.
31. Grady Booch, Robert A. Maksimchuk Object Oriented Analysis and Design with
Applications, Third Edition, Ed. Addison Wesley, 2007.
32. Gary David Bouton, Barbara Bouton Adobe Photoshop 4 ,Ed. Teora, 1999.
33. Golfarelli M., Rizzi S. Conceptual design of data warehouses from E/R schemes,
Proc. HICSS 31, WII, 1998.
34. Ian Graham Object Oriented Methods. Second Edition, Ed. Addison Wesley
Publishing Company, 1994.
35. Julie C. Meloni nva singur PHP, My SQL i Apache, Editura Corint, Bucureti,
2005.
36. Jacobson I., Christerson M. Jonsson P. Object Oriented Software Enginnering: A
Use Case Driven Approach, Ed. Addison Wesley, Boston, 1992.
37. Joffrey A. Hoffer, Joey F. George Modern Systems Analysis & Design. Second
Edition. Ed. Addison Wesley Longman, 1999.
38. John Beggs, Dylan Thede Designing Web Audio, Ed. OReilly, 2001.
39. Jim Buyenes Step by Step Web Database Development, Ed. Microsoft Press, 2000.
40. Kifer M., Bernstein A. and Lewis P. Databases and Transaction Processing: An
Application Oriented Approach, Addison Wesley, Boston, 2004.
41. Kendall & Kendall Systems Analysis and Design. Sixth Edition, Ed. Pearson
Prentice Hall, 2005.
42. Khoshafian S. i Abnous R Object Orientation: Concepts, Languages, Databases
and Users, Ed. John Wiley, New York, 1990.
43. P. Kruchten The Rational Unified Process: An Introduction, Ed. Addison Wesley,
2000.
44. Keyes, Jessica Knowledge Management Business Intelligence and Content
Management, CRC Press, 2006.
45. I. Lungu, Gh. Sabu, I. Roca Baze de date relaionale. Utilizarea limbajului SQL-
PLUS. Editura ALL, Bucureti, 1992.
46. I. Lungu, Gh. Sabu, M. Velicanu, M. Muntean, S. Ionescu, E. Posdarie, D. Sandu
Sisteme informatice. Analiz, proiectare i implementare, Editura Economic,
Bucureti, 2003.
47. I. Lungu Baze de date ORACLE. Limbajul SQL, Editura ASE, Bucureti, 2005.
48. Leszek A. Maciaszeek Requirements Analysis and System Design. Developing
Information Systems with UML, Ed. Addison Wesley, 2001.
49. Marin Fotache Proiectarea bazelor de date. Normalizare i postnormalizare.
Implementri SQL i Oracle. Editura Polirom, 2005.
50. Mircea Bdu AutoCAD-ul n trei timpi, Editura Polirom, 2006.
51. Michael, Kifer, Arthur Bernstein, Philip M. Lewis Database Systems. An
Application Oriented Approach, Second Edition Pearson Informational Edition, 2006.
52. Mihaela Muntean Iniiere n tehnologia OLAP. Teorie i practic, Editura ASE
Bucureti, 2004.
53. Mary Millhollon, Jeff Castrina Easy Web Page Creation, Ed. Microsoft Press, 2001.
54. Mark Chan, Steven Griffith, Anthony I. Java 1001 secrete pentru programatori, Ed.
Teora, 2001.
Bibliografie
461
55. Menachena Bazian, Jim Booth, Jeb Long, Vin Miller, Celia Silover, Robert Byers
Totul despre Visual FoxPro6, Ed. Teora, 2001.
56. Evidiu Nicolescu, Gh. Sabu, I. Roca, .a. Sistemul informaional managerial al
organizaiei, Editura Economic, Bucureti, 2001.
57. Olson David, Shi Zong Introduction to business data mining, Ed. Mc. Graw Hill,
2007.
58. OBrien James, Marakas George Entreprise Information Systems, Ed. Mc. Graw
Hill, 2007.
59. OBrien James, Marakas George Management Information Systems, Ed. Mc. Graw
Hill, 2006.
60. Oracle Corporation Oracle 9i Database concepts. Chapters 16 and 20 A 96524-01,
Oracle Corporation, 2004.
61. Oracle Corporation Oracle 9i Database Performance and Tuning guide and
Reference A 96533-01, Oracle Corporation, 2004.
62. Oracle Corporation Oracle OLAP Application, Developers Guide, 2004.
63. Oracle Corporation Oracle OLAP Reference 10g Release 2, 2005.
64. Pressman R. Software Engineering: A. Practitioners Approach, 5th edition. Ed. Mc.
Graw Hill, New York, 2002.
65. Paolo Atzeni, Stefano Ceri Database Systems. Concepts, Language & Architectures,
Ed. Mc Graw Hill, 1999.
66. R. Ramakrishnan, J. Gehrke Database Management Systems, Ed. Mc Graw Hill,
2000.
67. G. Riccardo Principles of Database Systems with Internet and Java Applications,
Ed. Addison Wesley, 2001.
68. Rob Peters, Coroner Carlos Database Systems: Design, Implementation and
Management, Ed. Thompson, 2007.
69. Rebecca M. Riordan Designing Relational Database Systems, Ed. Microsoft Press,
1999.
70. Robert Patton, Jennifer Ogle Designing SQL Server 2000, Syngress Publishing,
2001.
71. Robert Sheldon, Ethan Wilansky Database Design and Implementation MCSE
Exam, Microsoft Press, 2001.
72. Sabu Gh., V. Avram Sisteme informatice i baze de date, Editura OSCAR-PRINT,
Bucureti, 1998.
73. Sabu Gh., V. Avram, Al. Sotir .a. Practica bazelor de date, Vol. 1 i Vol. 2.
Editura Tehnic, Bucureti, 1989.
74. Sabu Gh., C. Ioni, V. Avram., C. Crstea Baze de date relaionale. Aplicaii n
turism. Editura CISON, Bucureti, 1998.
75. Sabu Gh., V. Avram, C. Cua Organizarea bncilor de date pentru evaluarea
comparativ a nivelului tehnic i calitativ a produselor, INID, Bucureti, 1989.
76. Sabu Gh., I. Lungu, Tr. Surcel .a. Sisteme Informatice i baze de date, Lito ASE,
Bucureti, 1993.
77. Sabu Gh., V. Avram Sisteme informatice pentru management, Editura Metropol,
Bucureti, 1994.
78. Sabu Gh., V. Avram, I. Lungu Sisteme de gestiune a bazelor de date, Ed. ASE,
Bucureti, 1982.
79. T. Surcel, R. Mranu, R. Bologa .a. Tehnologii web i baze de date, Ed. Tribuna
Economic, 2005.
80. Sommerville I. Software Engineering 6 th Reading, Addison Wesley, 2002.
Bibliografie
462
81. Thomas Connolly, Carolyn Beeg Database Systems. A practical Approach to
Design, Implementation and Management. Fourth Edition, Ed. Addison Wesley,
2005.
82. Thomas W. Shinder, Debra Littlejohn, D. Lynn White Configuring Windows 2000
Server Security, Syngress Publishing, 2000.
83. Thomsen E. OLAP Solutions: Building Multidimensional Information Systems, Ed.
John Wiley & Sons, New York, 1996.
84. Velicanu Manole Baze de date prin exemple, Editura ASE, Bucureti, 2007.
85. William H. Inmon Building the Data Warehouse, Forth Edition, Ed. Wiley
Publishing, 2005.
86. William J. Lewis Data Warehousing and e-Commerce, Ed. Prentice Hall, 2001.
87. D. Zaharie, I. Roca Proiectarea obiectual a sistemelor informatice, Ed. Dual
Tech, Bucureti, 2002.

Carte BD

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Carte BD

Încărcat de

Drepturi de autor:

Formate disponibile

Cuprins

(AB,AC), dac i numai dac R

<e, atunci cel de-al i-lea cluster

>e atunci al i-lea cluster nu va mai fi compact dac va fi

S-ar putea să vă placă și