Re: Relational model versus object model

From: Alfredo Novoa (alfredo_at_ncs.es)
Date: 02/19/04 

Date: Thu, 19 Feb 2004 12:04:27 GMT

On 18 Feb 2004 19:15:43 -0800, vertleyb@hotmail.com (Arkadiy Vertleyb)
wrote:

>"H. S. Lahman" <h.lahman@verizon.net> wrote in message news:<YlPYb.59220$KV5.54472@nwrdny01.gnilink.net>...
>
>> The short answer is: Don't Do That. Solve the customer problem first
>> using OO. Then service that solution with the subsystem or layer that
>> handles DB access for persistence. That subsystem has a pure data
>> transfer interface designed around the solution's programmatic data
>> needs. With a pure data transfer interface all you need is some shared
>> notion of identity across the interface (e.g., "Here's a pile of data I
>> call 'X'. Save it and give it back later when I ask for 'X'").
>
>So, you are assumming the relational model is only good for
>persistence...

He is saying that you shoulld manage the data in the application
transversing pointer labyrinths and misuse a DBMS as a file manager.

A great blunder.

>> There are two reasons. The first is the efficiency argument above. One
>> would have to be nutty to employ explicit identifiers and referential
>> attributes for relationship navigation in a memory addressing
>> environment. Relationship navigation is implemented quite differently
>> using OOPLs than it is implemented in an RDB.
>
>Your assumption is that refferring by pointers is more efficient,
>correct? Let me provide an example:

None of what he said makes sense.

>Suppose we have a list of employees, sorted by id. One of our tasks
>would be to select all of those employees joined in this year, and
>output them in the name order.
>
>1. So, we can traverse the list, selecting employees by the joined
>date, and write them in some kind of map or set that would sort them
>by name. The next time we have to do the same, we repeat.
>
>2. Of course, we can create some sort of index on date. We then would
>have to maintain this index, updating it as the list of employees
>changes. Since we use unrestricted object model, the only way to do
>it is by hand. If we have to maintain a significant amount of such
>indexes, we'd better avoid doing that, otherwise we'll most likely get
>in trouble forgetting to change an index somewhere. So, we resort to
>the approach number 1.
>
>3. Let's use the relational approach for the same task. We use the
>table of employees, and we index it by the joined date. We select a
>range of employees by this index, and then, we index this range by
>name.

If you use the relational approach you only have to say what you want
and you will get it. Selecting by an index does not make sense.

> This top-level index is our relational expression, that we can
>now use to immediately produce the result.

This statement does not make any sense.

>We are assumming that our (hypothetical so far) relational facility
>allows us any types in fields. So, we'll put the phone number in the
>field as an object, rather than as a string.

It is a requirement for the correct implementation of The Relational
Model.

>> Second consider an RDB Account table with attributes {Account ID,
>> Balance, ...} and a Customer table with attributes {Customer ID,
>> Address, Account ID, ...}. What does that look like in a GUI? There
>> will be an instance of Window for each tuple of both the Account and
>> Customer tables. IOW, the same Window class abstracts instances of both
>> Account and Customer.

They migth look as grids or forms.

>> The point is that the OO representation of a GUI is barely recognizable
>> in RDB terms and the RDB schema is not directly reflected at all. It is
>> an entirely different view of the data with quite different paradigms.
>> The only thing they share is that both views follow the relational model
>> and are normalized in their subject matter context. That allows
>> unambiguous mapping between them in terms of {identity, data} messages.
>
>This is correct.

This is plain nonsense. The application has to transform the user
input in DB requests and to show the responses in the screen.

> However, I don't suggest to replace objects with
> relations

It is impossible and absurd, they are completely different things and
relations are plenty of objects. A DB relation is a relationship among
objects. The intersection between a tuple and an attribute is an
object.

>, or OO approach with relational approach.

There is no commonly agreed definition of what "OO approach" means.

If OO approach means the network approach then the relational approach
was intended to replace it.

>To have relational tables as some
>object's attributes?

Relational tables are variables or values, like objects.

> To store objects (and pointers) in table fields?
> etc.

To store pointers in tables is a bad idea.

Regards
   Alfredo

Relevant Pages

  • Re: too complex for me!
    ... My report query is pulling data from the 'Time', ... 'Employees' and 'Accounts' tables. ... The idea, I guess, is to sum up the LaborHours from each account and show ...
    (microsoft.public.access.reports)
  • Re: echange email
    ... we have an e-mail acount hosted by an isp. ... The acount is a pop 3 account and ... all 4 employees to see the incoming and out going mails ...
    (microsoft.public.windows.server.sbs)
  • Re: How to secure the Administrator account?
    ... >>Administrator Account: We regularly rename and place strong passwords ... >>company and never to the normal "administrator" of the network. ... > 1) As you pointed out, your employees have to have system authority ...
    (microsoft.public.win2000.security)
  • Re: Computer accounts unused for more than 120 days
    ... the HR department notifies IT when an employee leaves so ... > that we can disable their account. ... > times I have had employees delete what they considered to be unimportant ... > recover any lost data in the event that the user did as I mentioned ...
    (microsoft.public.win2000.active_directory)