 |
|
Methods and Database Objects
Oracle Database Tips by Donald Burleson
|
If we review the evolution of databases
from the earliest hierarchical systems to today's object-oriented
databases, the single most important new feature is the coupling of data
with the behavior of data. While the flat-file systems brought us data
storage, the Hierarchical and Network databases added the ability to
create relationships between data, and the Relational database brought
declarative data query, we now see the coupling of the data with the
behavior of the data. For the purposes of this book, we will use the
terms behavior, process code, and method interchangeably, since
different vendor implementations use these synonymous terms to describe
embedded process code.
One of the huge benefits of the
object-relational architecture is the ability to move procedures out of
application programs and into the database engine. In addition to providing a
more secure repository for the code, the ability to tie data and behavior
together also enhances the ability to re-use routines. When combined with the
ability to directly represent aggregate objects, we now have a framework for
coupling all data processes directly with the object that contains the data that
will be manipulated.
While this may seem a trivial feature at first
glance, there are tremendous ramifications for systems development. Since the
process code now moves into the database along with the data, the job of
Database Administrators (DBA's) and System Developers will change radically.
The DBA, whose exclusive domain was the proprietorship of the data, must now
take on additional responsibility for management of the behaviors that are
stored in the database. Systems development also changes. Programmers will no
longer have the freedom to write custom-crafted code anytime they wish. With
the introduction of reusable methods, the programmer will change from a custom
craftsman to a code assembler, very much like the jobs of craftsmen changed with
the introduction of mass production in the industrial revolution of the late
18th century.
But why were methods introduced into the
database object model? Some of the most commonly cited reasons include:
1. Code re-usability - Process code only needs
to be written once, and the fully tested and reliable process code can then be
included in many different applications.
2. Control over the environment - By making the
database a central repository for process code, all of the processes are stored
in a common format and in a central location. The benefits from this approach
include the ability to quickly find code, as well as the ability to scan the
process code with text-search ability.
3. Proactive tuning - Since all of the SQL is
present in the database, the DBA can extract and test the access methods used by
all SQL for the application. This information can be used to identify indexes
that need to be created, tables that may benefit from caching in the buffer
pool, and other DBA tuning techniques. In addition, the developers can use this
central repository to tune their SQL, adding hints and changing the SQL in order
to obtain an optimal access path to the data.
4. Application portability - Since all of the
application code resides in a platform independent language within the database,
the application consists exclusively of calls to the methods that invoke the
processes. As such, an application front-end can easily be ported from one
platform to another without any fear that the process code will need to change.
5. Cross-referencing of processes - Since the
data dictionary for the database will keep track of all of the programs that
call the data, it is very easy to keep track of where a method is used, and what
methods are nested within other methods. This feature greatly simplifies
systems maintenance, since all applications that reference a particular entity
can be easily and reliably identified.
Another nice feature of the coupling of data and
behavior is the elimination of the "code hunt" and the subsequent code
reusability that will result. In order to meet the promise of code reusability
for database objects, the programmer must first know where to find the method.
By using a methods browser, the programmer could quickly scan the methods
attached to each database object, and hopefully find the proper method, thereby
alleviating the need to re-write the code.
and include the URL for the page.
