If you are familiar with the concepts of relational databases, you may wonder why object oriented databases and object oriented programming uses different notions for similar concepts. So here is a comparison of the concepts of both technologies.

Relational Notion Object Oriented Notion Comment
Row/Record Object Records are similar because they both contain the atomic data elements like strings or numbers. However there are many important differences.
  1. Records only contain atomic elements, i.e. they do not contain other records as fields. Objects can contain other objects as members.
  2. Members in an object are not always stored directly, but are rather computed on the fly by methods. Therefore objects are active.
ReportWeaver uses objects for modelling data, it makes display of nested objects easy.
Row/Record Definition Class A record definition is usually quite database dependent.
A record definition does not directly map onto a type of a programming language. It must always be converted back and forth.
Classes describe the business objects you are dealing with, so they are much easier to understand for the user. Classes also encapsulate the business logic together with the data, keeping it all conveniently in one place.
A class is a data definition of some standardized programming language like C++ or Java. This allows an object database to pass true Java objects to ReportWeaver directly. This is much faster and safer.ReportWeaver can report directly on Java without the need of conversion.
Table collCollection Tables and collections are similar because they both contain many Records/Objects. They both frequently have indexing structures for faster access. However tables have a very rigid structure because all rows in a table must have the same fields. A collection may contain objects of different classes by using inheritance (Polymorphism). ReportWeaver can display these polymorphic collections and can filter using inheritance.
Field Member A field in a relational database is always atomic (String or Number) and always stored physically.
Members can be structured, i.e. they can be other objects. They can also be computed through a method. ReportWeaver can display both fields and method results.
Query Filter A relational query can only specify a table as a result, which means all records have to be the same type and the result is one dimensional. But relational queries allow the creation of dynamic record definitions using select statements and joins.
Since these dynamic types would have no corresponding class in an object oriented application, selections and joins are usually not supported in object oriented data models. So filters correspond to the where clause of a relational query.
However, since the dynamic views created by SQL queries are often required in reporting tasks, ReportWeaver provides similar views modelled after the OQL standard.
Key Link Records from different tables in a relational database are combined using keys and joins. While this is a very general mechanism, it is slow and keys are hard to maintain.
Object databases use links, which are faster than key lookups and can be maintained by the object database automatically. This prevents data corruption.
Links also map directly onto Java object references or C++ pointers, making them much easier to handle by an application programmer.ReportWeaver uses links for speed and ease of use.
Join Navigation Related records in a relational database are brought together using a join operation. Joins have the disadvantage, that they get very slow when more than a few tables are involved. For two tables there are m*n combinations and for every extra table involved this figure has to be multiplied by the size of the table.
Navigation on the other hand is a very fast single step.
Because ReportWeaver supports navigation, it is fast enough to allow navigation from object to object interactively.