3.2 Object Applications and the Relational Database Model

 < Day Day Up > 



How do object applications affect the structure of relational database models? The point is that object application SDKs do not have to change the structure of a data model but in general they probably should. In order to impose an object-oriented architecture on top of a relational database certain small changes can be made to a relational data model. We will examine these in due course. Let us first take a look at a very simple description of the object database model in order to help explain recent trends in relational data modeling.

3.2.1 The Object Database Model

The object model is somewhat different to the relational model. Object databases are much more capable at handling complex data structures. What are the parts making up the object model?

  • Class: defines a structure. Equivalent to a relational entity.

  • Attribute: specific slots within classes. Equivalent to a relational entity column.

  • Methods: processing executed on objects declared as repetitions of classes. Vaguely equivalent to relational stored procedures, far more powerful in an object database.

  • Unlike a relational model an object model supports relationships between objects through the structure of objects and the classes defining those objects. Classes are defined as containing collections of pointers to other classes, as being inherited from other classes above in a hierarchy or as being abstractions of other classes below in the hierarchy.

  • This leads us to observing that classes can be both specialized and abstracted. A specialized class is a more specific form of a class inheriting everything from its parent class but allowing local overriding changes and additions. An abstracted class is a more general form of a class containing common aspects of inherited classes.

  • It should be understood that there is a distinct difference between a class and an object. An object only exists at run time. As a result the structure of classes can often be very different to the structure of objects created from a class hierarchy. Many object models are designed incorrectly because the difference between a class and an object is not understood. In general, class structure will never look like the object structure. Class structure is an abstraction of object structure.

Figure 3.2 shows an object database class structure on the left and a relational database entity structure on the right. Note a number of differences:

  1. The object model has no types (TypeCode). Types are represented by the specializations of the Person class, Employee class, and Manager class.

  2. The relationships between the different classes in the object model are represented in the actual class structure, those relationships being both collection inclusion and inheritance. Thus the object model contains objects containing pointers to other contained objects.

  3. An invisible difference is the power of black-box processing using methods in an object database. PL/SQL can perform some of these tasks but inadequately.

The Person class is a collection included within the Payroll class, as is the Task class in both the Employee class and the Manager class. The Employee class and the Manager class are both specializations of the Person class. The Person class is an abstraction where the Employee class and the Manager class are inherited from the Person class. The run time object structure is shown in Figure 3.3 for the object model in Figure 3.2. As you can see the object structure in Figure 3.3 is not the same as the object model class structure in Figure 3.2.

click to expand
Figure 3.2: The Object versus the Relational Model


Figure 3.3: The Run Time Objects

The object model uses data abstraction to conceptualize both data and encapsulated functionality using methods. Inheritance allows the passing of data definition and functionality onto specialized objects and extensive coding reuse. The crux and greatest benefit of objects is in their simplicity. The more that objects are broken down the more powerful and efficient the structure becomes. A relational database cannot be broken down to the level of an object structure. A relational structure can only be made more granular using Normalization, a certain distance, before the amount of Normalization becomes detrimental to performance. Since an object structure can be broken down into an extreme of granularity it is highly efficient at handling small, precise transactions. However, an object structure is dreadful at handling any kind of reporting. A relational structure can do both fairly well.

So what is the answer? Perhaps the object-relational model is the solution.

3.2.2 The Object-Relational Database Model

The object-relational model attempts to combine the relational and the object worlds. The problem is that the underlying storage structure of an object database is totally different to that of a relational database. The relational database storage method uses tables and rows (tuples) and is not terribly compatible with an object structure of containment of objects within other objects in a hierarchy, allowing exact searching anywhere into the entire object database.

The best product of the object-relational model is the ability to store and reference large binary objects such as multimedia. Most of the collection aspects such as table contained array types are hopelessly complex and inefficient. Additionally methods can be created in PL/SQL, whose coding implementation is far too complex and convoluted to be of any real use.

So the object-relational model simply includes some aspects of the object model, more successful in some areas than in others.

My experience of working with both multiple relational and object databases is that the two should not be mixed to any great extent. Relational and object methodologies are completely opposed to each other and the two simply do not mix very easily.

3.2.3 The Benefits of Overlaying Objects onto Relations

So far in this chapter we have examined an example object model and briefly discussed what the object-relational model attempts to achieve. Many ideas have been put forth in attempting to map object structures from an SDK such as Java onto a relational model. The best option I have come across has been that as shown in the previous chapter in Figure 2.10. This diagram is repeated in this chapter in Figure 3.4 for convenience. The data model in Figure 3.4 is a partially abstracted form of the data model shown in Figure 3.1. In Figure 3.4 every entity has a unique identifier, generated using Oracle Database sequences. The only problem with a structure of the form in Figure 3.4 is that, as with an object database, re-ordering the data to generate reports can be exceedingly slow without extensive alternate indexing. Too much indexing uses too much physical space and will slow down database change activity.

click to expand
Figure 3.4: The Employees Schema

The data model in Figure 3.4 would allow a different version of the join statement shown previously in this chapter. Note how this SQL join statement shown has a much smaller WHERE clause since fewer matching conditions are required.

SELECT de.name, pr.name, pt.name, prd.revenue - prd.cost FROM department de, project pr, projecttype pt, product prd WHERE de.department_id = pr.department_id AND pr.projecttype_id = pt.projecttype_id AND pr.project_id = prd.project_id; 

That covers just about everything we need to look at for relational data model tuning, including a brief glimpse at the object data model. Overall there is not much that can be said about tuning a relational data model other than changes to granularity. Increase granularity using Normalization and decrease granularity using Denormalization, amongst other simple tricks. The secret about relational data model design is that it is probably simpler than it appears. The object model, on the other hand, allows inclusion of extensive functionality in an object database directly. As a result the object model is probably much more difficult to design. Objects by their very nature demand more up-front design and planning work. It should be said however that most of the work required in building a relational data model is analysis and understanding of requirements, particularly with regards to potential applications. Understand applications fully prior to sitting down and drawing out entity relationship diagrams. Putting more time into data model design prior to beginning coding will absolutely benefit performance immensely at a later stage. The data model is the most important part in the development of any custom application because every other piece of the puzzle depends on it. Applications rely on the integrity, applicability to application usage and serviceability of the data model.

The next chapter will present a brief history of data modeling and gradually lead up to using and tuning of SQL in Part II.



 < 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