ORDBMS – Object-relational database management systems make corporate information easily accessible, improve significantly the way how applications are developed, but they also create some complex management issues. This paper explains the key components and features of Oracle8 as an object-relational database management system for implementing business objects, demonstrates how business objects can be created and evaluate the impact of this new technology into the market.

Paper Contents:

• Business Rules
• OO Features of Oracle8 for Business Objects
• Object Oriented Programming and Oracle8
• Naming Conventions for Objects
• What is a Class?
• Objects and the Benefits
• Building the Address Class
• Using SQL and PL/SQL With Oracle8 Objects
• Creating Methods for Address Class
• Market Analysis
• Recommendations

Business Rules

Taken to the lowest-level of abstraction, all data is nothing but 0’s and 1’s on a storage medium someplace. This medium can be RAM, magnetic disk, optical disk, or several other types of storage media. If you think about what it takes to organize this data and make it usable as part of an organization’s everyday business , you will have to agree that it is business rules.

Business rules are those criteria that are essential to running a business. When you are building an application, there are many intances when you would have to do some special processing to guide the user, so that he or she can navigate the application without having to memorize a lot of rules. These typically have nothing to do with the data, itself. For example, if a particular organization may not accept any orders on weekends, the system has to be written to prevent order entry on weekends. This is a condition that is totally external to the data. This is a business rule that has to be implemented in the program regardless of how the data is stored and organized. In design parlance, these are called business rules and some examples in an order entry system are:

• Ensuring that all orders are at least US$ 10,00;
• Ensuring that certain products are not shiped out of state;
• Checking that the full nine-digit ZIP code is entered and giving a warning message to the user if it is not.

Traditionally, business rules are enforced in code and become a hardwired part of the application. However, this makes the business process that requires the hardwired rule difficult to modify. If for some reason it has to be modified, then the process of that modification could become resource intensive. Newer generation tools such as Oracle 8 gives to developers many facilities to easily implement and maintain business rules within objects.

OO Features of Oracle8 for Business Objects

With Oracle8, Oracle has encorporated basic object capabilities within the Oracle database creating an object-relational database structure.

Object-relational databases combine relational data, typically numbers and text, with object interfaces and unstructured data such as images, maps, and sound. Oracle8 customers can use this object-relational framework to create "business objects".

Business objects can be anything the customer defines such as an insurance policy, a purchase order, or a flight reservation. Instead of having to concentrate on the many places where the data resides, that would constitute an insurance policy, the developer can simply work with the business object inside the data server. This concept of capturing business semantics in the logic significantly reduces the complexity of application development.

Oracle supports many different types of objects. And the major object types available are:

• Abstract Datatypes

Abstract datatypes are datatypes that consist of one or more subtypes. Rather than being constrained to the standard ORACLE datatypes of NUMBER, DATE, VARCHAR2, and CHAR, abstract datatypes can more accurately describe your data.

• Nested Tables

A nested table is a table within a table. A nested table is a collection of rows, represented as a column within the main table. For each record within the main table, the nested table may contain multiple rows. In one sense, it’s a way of storing a one-to-many relationship within one table.

• Varying Arrays

A varying array is, like a nested table, a collection. A varaying array is a set of objects, each with the same datatype. The size of the array is limited when it is created. When you create a varying array in a table, the array is a nested table with a limited set of rows. Another way to store repeating attributes in tables.

• Large Objects

A large object, or LOB, is capable of storing large volumes of data.

• References

References, also known as REFs, are essentially pointers to row objects. A "row object" is different than a "column object" and both are supported by Oracle8. References are tipically among the last OO features implemented when migrating a relational application to an object-relational or OO approach.

• Object Views

Object views allow you to add OO concepts on top of your existing relational tables. For example, you can create an abstract datatype based on an existing table stored in the database.

Object-Oriented Programming Languages and Oracle8

For years hardware has been improving dramatically but software, for some reason, seemed to resist almost every attempt to build it faster and to build it better. Today we are in the middle of a revolution in the way software is being written. This revolution is based on software components and object-oriented programming is currently the fashionable term for various programming languages. These software components are called "objects," more properly, "classes," wich are the "cookie cutters" out of which objects are produced.

The most mature of the well-known object-oriented languages is Smalltlak, developed in the early 1970s at Xerox’s Palo Alto Research Center. But the most widely used object-oriented language is C++ developed by Bjarne Stroustrup and others in the early 1980s at AT&T. Then another serious contender appeared on the scene, the Java object-oriented programming language, developed in the early 1990s by James Gosling and others at Sun Microsystems.

Smalltalk was truly ahead of its time as a research experiment. C++ was right for its time and for today’s high-performance systems programming and applications development needs. Java offered developers the ability to create highly portable multimedia-intensive, and networking-intensive Internet/World Wide Web-based applications.

Knowing the importance of the Internet for many companies to implement their business, Oracle decided to put Java at the center of its tools. Besides rewriting its Enterprise Manager database management in Java, which enables database management via a browser, Oracle is also providing development tools such as Oracle Jdeveloper which is a Java Development tool for building, debugging, and deploying business components and database applications for the Internet.

There are several advantages of using an object-oriented programming language to interact with the OO features of Oracle8 and the main one is related to reusablility. The fact is that it can reduce application development time by creating reusable objects (classes) that are easily maintained. With an object-oriented approach, you can create smaller pieces of code that can be reused throughout the program and treated as objects.

In addition to reusability, object-oriented also means that an object’s properties can be inherited from another base object, and that different attributes can be added to create a new object based on the original. This inheritance feature is the foundation of object-oriented programming languages.

What is a Class?

An object class, also referred to as a class, is a complete description of an object or a group of objects. An object class describes the way an object or group of objects appear, how they interact, and how they interface with the rest of an application. A class specifies the values for all of the properties and methods of all of the objects in a class.

The object class itself is essentially a recipe for creating an object or a group of objects. You can create an intance of a class, which is a particular copy of an object class that is created in an application. The object class itself exists independent of any particular application, and the instances of an object class are linked to the class.

A class is merely a description. This seems rather ephemeral – shouldn’t there be more concrete definition of a class? In fact, the architecture of object classes creates their enourmous flexibility. The description of a class exists separately from an instance of the class. You can change the class, or description, and the concrete intances of the class will also change. In this way, object classes can not only improve your productivity, but they can have a dramatic impact on the way you handle maintenance. If the functionality of a class has to be modified or enhanced you can modify the class and simply recompile any application that use that particular class. The object class acts as a repository for functionality.

You can have a class that is a single object, or dozens of objects. You can add properties to a class or methods. You can create an instance that is an exact implementation of a class, or extend or override any of the functionality of the class. You can even create a class that is made up of other classes.

Adding Logical Integrity to Your Class

During the creation of objects, they inherit the structures of the data elements they are descended from. The ability to create hierarchies of abstract datatypes is one of the most important OO features of Oracle8 when implementing business objects. In addition to inheriting data structures, classes can inherit the behavior of their "parent" classes – a concept called implementation inheritance.

It is easy for a user to create invalid expressions when using a form based on a class. You can add logical integrity to the class by making it difficult, or impossible, for a user to leave a form based on the class unless the user has created a valid selection expression. If you can add logic to your class to prevent errors, you will make developers using the class more productive, since they will not have to add error checking to the form. Even more important, if you create a logically complete class, you can reduce the amount of time that developers and users will have to spend testing the applications that contain instances of the class

Objects and the Benefits

Everybody has data, and everybody has methods of interacting with data. Since the combination of data and methods makes up an object, everybody has object. An object is an entity that has a clearly defined set of public or external behaviors and a private or hiden internal state that are data and function. The external behavior of an object includes how messages sent to an object result in an anticipated behavior.

At 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 data and its relation. Besides simplifying your interactions with data, objects may help you in other ways. There are three visible 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 chance 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.

Before we can start building the Address class let’s get familiar to the convention naming rules that can be adopted by developers to name Oracle objects. For the OO examples in this paper, the following rules will also be enforced:

1. Table and column names will be singular (such as EMPLOYEE, Name, and Phone).
2. Abstract datatype names will be singular nouns with a TY suffix (such as PERSONTY or ADDRES_TY).
3. Table and datatype names will always be uppercase (such as EMPLOYEE or PERSON_TY).
4. Column names will always be capitalized (such as State and Phone).

Building the Address Class

One of the most common elements of most databases in most systems is the address. It is used in several places (for example, in ORDERS record, CUSTOMERS record, EMPLOYEES records, and INVOICE record). No matter where you encounter it, it has almost the same common elements following a standard format that is: one or two ADDRESS lines, CITY, STATE, and ZIP. These information can be used as the basis for an abstract datatype for adresses. In order to understand efectivilly what is a class, how it works, and the clomplex issues that it can create in the way data is managed, let’s create the Address class. First, use the create type command to create an abstract datatype as shown in the following lines :

Zip NUMBER);

The create type command is the most important command in object-relational databases. What the command in this example says is "create an abstract datatype named ADDRESS_TY. It will be represented as having four attributes, named Street, City, State, and Zip, using the defined datatypes and lengths for each column." So far, no methods have been created by the user, but the database has internally created methods that will be used whenever the ADDRESS_TY object is accessed.

Within the create type command, note the as object clause. The as object clause explicity identifies ADDRESS_TY as an OO implementation.

Now that the ADDRESS_TY datatype exists, it can be used within other datatypes. For example, a company may decide to create a datatype for international adresses with the same structure that was given to ADDRESS_TY and followed by the country name. Therefore the company can create the following type:

Country VARCHAR2(50));

First, a name was given to the datatype INTERNATIONAL_ADDRESS_TY that was identified as an object via the as object clause. Then, two columns were defined. The first line:

defines the first column of INTERNATIONAL_ADDRESS_TY’s representation. The second line:

defines the second column of INTERNATIONAL_ADDRESS_TY’s representation. The first column, ADDRESS, uses the ADDRESS_TY abstract datatype previously created. So, this means that an INTERNATIONAL_ADDRESS_TY entry will have a Street, a City, a State, a Zip code, and a Country as columns even though only one of those columns is explicity defined within the INTERNATIONAL_ADDRESS_TY type definition.

Going further, a company may decide to create a standard datatype for people. People have names and addresses that can be national addresses or international addresses depending on the person. People can represent an employee, a customer, or any other kind of person that has a relationship with the company. Therefore, the company can create a datatype for person as shown bellow:

Address ADDRESS_TY);

Again, the datatype was given a name – PERSON_TY – and identified as an object via the as object clause. Then, two columns were defined: This line:

defines the first column of PERSON_TY’s representation and the second line:

defines the second column of PERSON_TY’s representation. The second column, Address, uses the ADDRESS_TY abstract datatype previously created and also used within the datatype INTERNATIONAL_ADDRESS._TY.

Now, after seing these two simple examples, imagine how this capability to define and reuse abstract datatypes can simplify data representation within databases. Abstract datatypes allow you to join different elements together and deal with the whole instead of the parts that constitute the object.

Once the datatypes are created, it’s time to think of inserting records into database. You can’t insert data into PERSON_TY and the reason for that is straighfoward: a datatype describes data, it does not store data. To store data, you first have to create a table that uses your datatype and this is shown bellow:

Person PERSON_TY);

Now with the table created its possible to store data into it. Oracle creates methods, called constructors methods, for data management when you create an abstract datatype. A constructor method is a program that is named after the datatype; its parameters are the names of the attributes defined for the datatype. When you need to insert records into a table based on abstract datatypes, you can use the constructor methods. For example, the EMPLOYEE table uses the PERSON_TY datatype, and the PERSON_TYdatatype uses the ADDRESS_TY datatype. In order to insert a record into the EMPLOYEE table, you will need to insert a record using the PERSON_TY and ADDRESS_TY datatypes. To insert records using these datatypes, you will need to use the constructor methods for the datatypes. In the following example, a record is inserted into EMPLOYEE using the constructor methods for the PERSON_TY and ADDRESS_TY datatypes. The constructor methods for these datatypes are shown in bold; they have the same names as the datatypes:

If you use abstract datatypes to create tables, you can neither insert nor select values for the abstract datatypes attributes without knowing the exact structure of the attributes. For example, you cannot select the EMPLOYEE table’s City values unless you know that City is part of the Address attribute, and Address is part of the Person column. This is probably the complex issue that OO feature of Oracle8 creates when accessing data based on abstract datatypes. The following examples shows how to insert records in a table that has abstract dataypes columns:

Select Person.Name,

When updating data within abstract datatypes, refer to its attributes via the Column.Attribute as shown in the preceding example. For example, to change the City value for a specific employee who live in Miami, FL, execute the following update command:

update EMPLOYEE

As shown in these examples, using abstract datatypes simplifies the representation of the data but may complicate the way in which you query and work with the data. It’s necessary to weigh the bebefits of abstract datatypes – more intuitive representation of the data – against the potential increase in complexity of data access.

Using SQL and PL/SQL With Oracle Objects

SQL was developed by IBM to provide an interface to the relational database they were developing in their San Jose research laboratory in the middle to late ‘70s. Since then, SQL has become the standard language to access most relational databases. SQL is more than a query language, not withstanding its name. Within the SQL language, there are two major components: DDL (data definition language) and DML ( data manipulation language) statements. The DDL statements are those used to define the database and include the CREATE, ALTER, and DROP statements. The DML statements are those used to manipulate and retrieve the data within the database, such as INSERT, UPDATE, DELETE, and SELECT statements.

SQL is a programming language but it is not a procedural language. It does not contain process control statements (WHILE loops, IF statements, etc.), variables, or subroutines.

PL/SQL is an option for Oracle server to provide procedural capabilities to the standard SQL. This language adds more flexibility to SQL, providing methods to control the flow of the execution of SQL statements and create and call procedures. Thinking of objects, besides attributes, abstract datatypes can include methods – PL/SQL functions and procedures that operate on the datatype. If you grant someone the privilege to use your datatype, you are granting the user the privilege to execute the methods you have defined on the datatype.

Creating Methods for Address Class

As said before, an object is a combination of data and methods. The PERSON class created before, that includes the ADDRESS class, is a perfect example of a classs where you would do the validation in one place and then use it where needed. Some methods for the PERSON object could include:

Add_Person For adding a person to a table;

Update_ Person For updating a person’s entry;

Remove_Person For deleting a person from a table;

Count_Person_Dept For counting the number of workers per department;

Get_Age For calculating and returning the age of the person;

Get_Address For returning the addres of the person.

When you create an abstract datatype, you use the create type command. When you create a method, you use the create type body command.

Before creating the body for a method, you must name the method within the type declaration. For example, first let’s complete the datatype PERSON_TY with the birthdate information. The datatype definition for PERSON_TY is shown in the following listing:

Within the create type command, this line:

names the function that is a "member" of the PERSON_TY datatype. Since "AGE" will return a value, it is a function; if no values were returned, it would be a procedure. To define the age function, use the create type body command, whose syntax is shown in the following list:

end;

Let’s create the AGE function as a member function within the PERSON_TY datatype. The AGE function will return the age, in days, of the persons:

If you had additinal functions or procedures to code, you would specify them within the same create body command, before the final end clause.

Now that the AGE function has been created, it is associated with the PERSON_TY datatype. If a table uses this datatype, then it can use the AGE function. However, there is a problem with the way in with the function is specified. The AGE function, as previously defined in the create type body command, does not explicity restrict updates. The AGE function does not update any data, but there is no guarantee that the type body will not later be changed to cause AGE to update data. To call a member function within a SQL statement, you need to make sure that the function cannot update the database. Therefore, you will need to modifty the function specification in the create type command. The necessary modification is shown in bold in the following listing:

The line:

tells Oracle that the AGE function operates in the WRITE NO DATABASE STATE, it cannot modify the database.

You can now use the AGE function within a query. If PERSON_TY is used as the datatype for a column named Person in the table named CUSTOMER, then the table structure could be:

);

You can now invoke the AGE function, wich is part of the PERSON_TY datatype. Like the attributes of an abstract datatype, the member methods are referenced via the column names that use the datatypes, in this case, Customer.AGE:

From CUSTOMER;

and obtain the following as result:

35

The Customer.AGE(Customer.BirthDate) call executes the Age function within the PERSON_TY datatype. Therefore, you do not have to store variable data such as age within your database. Instead, you can store static data, such as birthdate, in your database and use function and procedure calls to derive the variable data.

 Market Analysis

Object orientation is a universal technique that can be applied to many types of systems. Of late, this technique has found wide acceptance in the software industry. In other words, more and more areas of computer technology are converting on object orientation. There is now a consensus that acknowledges object orientation as the plataform most development organizations are choosing and will choose for the future.

Even organizations that don’t have the software development as their main activity are concerned about how object orientation technology can impact in their business. They definetly want to stop focusing on computations and data storegment to focus on business problems or deal with technical issues at a high level of abstraction.

What we observe is that the benefits due to reuse, such as improved time to market, or higher quality systems, or lower overall development costs, increase as the levels of reuse and the sophistication of a reuse program increase. Furthermore, it takes time, investment, and experience with reuse to get to those levels of reuse.

Recommendations

For corporations that are willing to improve their business making use of OO technology it’s important to enphasize that they should adopt reuse systematically and incrementally before they can face success.

The adoption path common to several reuse atrategies is to start with focused pilot projects. As these pilots meet a degree of succcess, expand them incrementally, increasing reuse coverage and penetration into the organization.

To achieve systematic business reuse, an organization must keep this set of principles in mind:

1. Maintain top-management leadership and financial backing over the long term.
2. Plan and adapt the system architecture, the development process, and the organization to the necessities of reuse in a systematic but incremental fashion. Start with samall pilot projects, and then scale up.
3. Plan for reuse beginning with the architecture and an incremental architecting process.
4. Create and envolve reusable components in a real working environment.
5. Realize that object or component technology alone is not sufficient
6. Directly address organization culture and change.
7. Invest in and continuosly improve infrastructure, reuse education, and skills.
8. Measure reuse progress with metrics, and optimize the reuse program.

 Bibliography

Deitel, H. M., and P.J. Deitel, C++ How to Program (Second edition), Upper Saddle River, NJ: Prentice Hall, 1998.

Jacobson, I., Ericsson, M., Jacobson, A., The Object Advantage – Business Process Reengineering With Object Technology, ACM Press, NY, 1995.

Jacobson, I., Griss, M., Jonsson, P., Software Reuse – Architecture, Process and Organization for Business Success, ACM Press, NY, 1997.

Koch, G., and Loney, K., ORACLE8 The Complete Reference, Osborne/McGraw-Hill, CA, 1997.

Alban, H., Object-Oriented Technology, Tutorial Publication - docid 00016811, 1998.

Oracle Corporation - http://www.oracle.com

IEEE Society Studies and Proceeding on Object-oriented Topics - http://www.computer.org/epub/

Object Management Group - http://www.omg.com