|
| |
 | |
 (Print
03/14/94) | |||
|
OBJECT-ORIENTED SYSTEMS will change your life especially if you're a database administrator. As these systems come closer to the fore, database administrators will experience changes in their daily routines, and more important, see new opportunities unfold. While some experts say true object systems are not meant for the mainstream, market numbers are growing. Those responsible for safeguarding and distributing information might need to add object management to the mix. In this capacity, an understanding of the object layer and the internal database structure will be required. Unlike traditional systems, which consist of a database and a collection of programs, object-oriented systems are built around a database and an object layer that is, they couple the data and the programs that manipulate it. Like traditional systems, they encapsulate data and data relationships, but they go one step further and encapsulate the behaviors of the objects. It is the object administrator's job to manage these objects. Generally, this involves three major functions: maintenance of object methods (code snippets that govern an object's behavior and performance), documentation of interfaces to objects and management of distributed object systems. The domino effect Object management is the object administrator's greatest challenge. It involves tracking the object class hierarchy and providing impact analysis for any data or behavior changes. Administrators must know the location, name, function, inheritance and polymorphism of every behavior stored within objects. The difficulty arises when a method is altered. Just as changes to a data item may affect many programs, changes to a method may affect lower-level classes. When a change is made to a high-level class (called a base class), an administrator must check all lower-level methods to make sure they properly inherit the changed method. Administrators must also regularly document the methods encapsulated in each object and the messages (triggers that fire off the methods in an application) sent to each object. This road map, which is similar to the entity relationship model used for traditional systems, lets programmers see how objects interact. Add distributed object databases, which manage communications among many databases, and you have a lot of extra responsibilities. The administrator must manage the Object Request Broker, the central software component of the Common Object Request Broker Architecture (CORBA). The CORBA standard has been adopted by most large vendors and guarantees that all objects, regardless of home database, communicate in a standard way. To be successful, object administrators must understand the internals of a database engine, even if an object-oriented database is not used. In many cases developers build object layers, usually in C++ or Smalltalk, and interface them to a traditional relational database. Proficiency in the programming language used by the object layer is also required. The success of an object-oriented system also depends on thorough planning and careful object analysis. Poorly designed object systems are much less flexible than their relational counterparts because of the rigorous class hierarchy and data relationship definitions. Unlike relational implementations, there is no such thing as ad hoc query against object databases unless the access path has been predefined to the system. Eventually, as pure object-oriented databases become robust enough to support mission-critical applications, companies will migrate from object layers on top of relationals to a pure object-oriented approach. When that happens, the object administrator will assume full responsibility for the entire object architecture, and the database administrator's role as we know it will become obsolete.
|
| |
|
|
|||
|
|
