6.12 Object and Relational Conflicts

 < Day Day Up > 



Relational and object data model structures are completely different to each other. There is great potential for conflict when combining these two methodologies into what is called an object-relational database. These conflicts can hamper performance in a relational database such as Oracle Database.

6.12.1 Large Binary Objects in a Relational Database

The biggest benefit to the combination of objects and relations is that of including large binary objects into a relational structure, such as multimedia objects. However, there is a twist. In both relational and object databases the most efficient storage method for multimedia objects is to use a BFILENAME pointer. A BFILENAME pointer does not store the object itself in the database but contains a path and file name for the object. The object is stored externally to the database in the file system. Storing large binary objects in any database is inefficient because those binary objects can span multiple blocks, both Oracle Database blocks and operating system blocks. Even with Oracle9i Database multiple block sizes and specific storage structures for LOB datatypes large multimedia objects will span more than one block. Storing data into a database which spans more than a single block is effectively row chaining where a row is "chained" from one block to another. Chaining is not really an issue if the blocks are physically next to each other. Also the DB_FILE_MULTIBLOCK_READ_COUNT parameter can help to counteract this. The fact is contiguous, defragmented block storage is extremely unlikely in any database environment. It is usually best to store large singular binary objects in the file system.

Note 

 Oracle Database 10 Grid   BIGFILE tablespaces can possibly help to alleviate these issues somewhat.

6.12.2 Object-Relational Collections

Including TABLE and VARRAY collections inside relational tables and within PL/SQL is generally a very bad idea. Collections are an object methodological approach to object data abstraction and encapsulation. Object methodologies are completely opposed to those of relational databases. An object structure is spherical allowing access from any point to any point within an entire database. A relational database is more two-dimensional in nature and requires that access to data be passed through or down semi-hierarchical structures or into subset parts of a data model. Since PL/SQL is merely an extension of SQL, and SQL is a purely relational database access language, any type of object coding is best avoided using PL/SQL. If you want to write object code use Java. Java is built for object structures.

The same approach applies to including object structures in tables. There are various instances in which collection substructures can be utilized in relational database tables. 1st Normal Form master detail and 2nd Normal Form foreign key static table inclusion relationships are possibilities. However, storage structures remain applicable to a relational methodology and are still ultimately stored in rows (tuples). Tables and rows are two-dimensional. Object structures are multi-dimensional. The two do not fit together. If you must contain collections in tables in Oracle Database there are various object collection types that could be used. Associative arrays are the most efficient.

  • Nested Table.   A nested table is a dynamic array. A dynamic array is a pointer. A pointer does not require a specific size limit and thus the use of the term dynamic. Dynamic implies that it can have any number of rows or entries in its array.

  • VARRAY.   A VARRAY is a fixed-length array. A fixed-length array is a reserved chunk of memory saved for multiple array rows. Unlike a dynamic array a fixed-length array has space in memory reserved for the whole array structure.

  • Associative Array.   An associative array is an indexed dynamic array and can potentially be accessed faster than a nested table because it can be accessed using an index.

Problems with objects in relational models are more often than not a misunderstanding of object-modeling techniques. It is common knowledge that the approach required for object data modeling is completely different to that of relational modeling. The same is very likely to apply to object-relational modeling using object types such as nested table, VARRAY or associative array collections in Oracle Database tables. Using these collection data types requires object and relational modeling skills, not only relational modeling skills.

That ends this chapter on examining the basics of how to create efficient SQL. In the next chapter we will look at indexing and start to delve a little deeper into Oracle Database specifics.



 < Day Day Up > 



Oracle High Performance Tuning for 9i and 10g
Oracle High Performance Tuning for 9i and 10g
ISBN: 1555583059
EAN: 2147483647
Year: 2003
Pages: 164

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net