Oracle 8: The Complete Reference

Read an Excerpt

From Chapter 4: The Basics of Object-Relational Databases

...As of ORACLE8, you can extend your relational database to include object-oriented concepts and structures. In this chapter, you will see an overview of the major object-oriented features available in ORACLE8 and the impact they have on your SQL. You will see detailed descriptions of more advanced object-oriented features in later chapters; this chapter introduces the concepts and provides a general overview.

Do I Have to Use Objects?

Just because you upgrade to ORACLE8, that does not mean you have to use object-oriented (OO) concepts when implementing your database. In fact, the database is referred to as an ORDBMS--an object-relational database management system. The implication for developers is that three different "flavors" of ORACLE are available:

Relational: The traditional ORACLE relational database (RDBMS)

Object-relational: The traditional ORACLE relational database, extended to include object-oriented concepts and structures such as abstract datatypes, nested tables, and varying arrays.

Object-oriented: An object-oriented database whose design is based solely on object-oriented analysis and design.

ORACLE provides full support for all three different implementations--relational, object-relational, and object-oriented. If you have previously used ORACLE as a relational database (the only option available in ORACLE7 and below), you can use ORACLE8 in the same manner. Since the OO capabilities are extensions to the relational database, you can select which OO features you wish to use when enhancing existing relational applications. If you want to redesign andimplement your application using only OO features, you can do that also. Regardless of the method you choose, you should first be familiar with the functions and features of the core ORACLE relational database. Even if you plan to use only OO capabilities, you will still need to know the functions and datatypes available in ORACLE, as well as its programming languages (SQL and PL/SQL).

This part of this book began with an overview of the basic parts of speech in SQL. In this chapter, you will see those same parts of speech extended to include object-relational structures. In the following chapters, you will see detailed descriptions of ORACLE's functions, followed by sections on PL/SQL, triggers, and procedures. Following the chapters on PL/SQL and procedures, you will see several chapters on the implementation of OO features available as of ORACLE8. You should understand ORACLE's functions, structures, and programming languages before implementing the more advanced OO and object-relational structures.

Why Should I Use Objects?

Since you don't have to use objects, should you use them at all? A first, using OO features may seem to complicate the design and implementation of your database systems--just as adding new features to any system may automatically increase its complexity. OO adherents claim that objects reduce complexity by giving you an intuitive way of representing complex data and its relations. For example, if you want to move a car, you can either move the car (an object) or you can break it into its components (tires, steering column, etc.), move the components individually, and then perform a join in the new location. Treating the car as an object is a more natural way of relating to it and simplifies your interaction with it.

Besides simplifying your interactions with data, objects may help you in other ways. In this chapter, you will see examples of three benefits that come from using OO features:

• Object reuse If you write OO code, you increase the chances of reusing previously written code modules. Similarly, if you create OO database objects, you increase the chances that the database objects can be reused.
  

• Standards adherence If you create standard objects, then you increase the chance that they will be reused. If multiple applications or tables use the same set of database objects, then you have created a de facto standard for the database objects. For example, if you create standard datatypes to use for all addresses, then all of the addresses in your database will use the same internal format.
  

• Defined access paths For each object, you can define the procedures and functions that act upon it--you can unite the data and the methods that access it. Having the access paths defined in this manner allows you to standardize the data access methods and enhance the reusability of the objects.
  

Everybody Has Objects

Everybody has data, and everybody has methods of interacting with data. Since the combination of data and methods makes up an object, everybody has objects. Consider Talbot's list of employees again, as shown in Figure 4-1. He has a standard for the structure of an address--it starts with a person's name, followed by a lodging name, street name, and city name. When he adds a new person to his list of Dora's help, he follows the same procedure...

Read More