Rationalizing Relational and OO

Moving forward with relational: looking for objects in the relational model, Chris Date finds they were there all the time. "The question is how to integrate the good ideas of object-oriented database with relational ideas. The wonderful thing is, it turns out you don't have to do anything to the relational model. Absolutely nothing. The relational model is so solid and so robust..."

"The key notion underlying The Manifesto is thus the equation: domain = object class. A domain, or an object class, is a data type that is encapsulated, which means that the only way you can operate on values of that type is through operators that are defined for the type. You don't actually see the way the data is represented. That's not relevant. You only know that there are certain functions you can perform. It might be a primitive system-defined data type. More generally, it's going to be a user-defined data type. The values of these data types can be arbitrarily complex."

"The values in row and column slots can then be anything you like. They can be simple integers. They can be strings. They can be arrays. They can be books. They can be engineering drawings. They can be videos... They can be anything you like - as long as you can define the data type. In fact, I believe do one of the reasons we're hearing so much hype about object-oriented is because of a failure on the part of the relational vendors to step up to the mark. They haven't supported the relational model. If they had, we wouldn't be having these silly arguments now."

"In my opinion, there are precisely two good ideas. One is the data type concept - user-defined data use of arbitrary complexity, with encapsulation and user-defined functions. The other is inheritance. For example, in a geometric database you might have an object class called polygons, and one called rectangles, where rectangles are a subclass of polygons because every rectangle is a polygon. Therefore it follows that everything that works for polygons automatically works for rectangles too."

"If under the covers, the representation changes - if polygons are represented by a sequence of points for the vertices, and rectangles are represented by just the bottom left and the top right corner or something like that - the code to implement the operator has to change too, but that's implementation. From the model's point of view, if you have a function called area that returns the area of a polygon, automatically it means that you can invoke the area function on a rectangle and get the right answer. Under the covers, it may be desirable to reimplement that function. I don't care. That's implementation."