Re: the relational model of data objects *and* program objects

erk schrieb:
> 1. It's fairly simple to model hierarchies using relations

It is not a hieararchy in data semantics which can be easily implemented in RM (although still think that here RM is not very natural). I mean that we cannot create a hierarchy of tables. For example, I want to create a subspace with some tables (like a folder). Or I want my database with a (always flat) set of tables to be included and feel a part of some external database.

In any case, I do not want to model hierarchies myself - I want my system does it for me. In the same sense I can implement any OO program in a procedural language and say that OO is not needed. The problem is how we view our system (data model): as a list of tables, as a number of layers, as a set of objects etc. These approaches are incompatible and we can only believe in one or another method or apply whatever one is more appropriate.

> 2. Hierarchies are far less useful than they seem at first - they have
> the advantage of being easy for humans to understand, but the emergence
> of the "matrix organization" is just one manifestation of its
> limitations.

Hierarchies can be useful or then could be useless in different situations but this mechanism should exist because of its fundamental importance. Again, why not to have a file system with only one level of folders? I could say that I developed a search engine and now store all my files in the only folder while the search engine retrieves information by query. Yet other people do not have such a search engine and want to create their own folder structure.

> 3. "Obviously" a serious drawback? Obvious to whom?

I thought that the necessity to have means for describing a structure and particularly hierarchies is something obvious for most people. Do not you think so? In RM we do not have a structure at all, so is not it a drawback?

> So the main problem is not the absence of hierarchies, but that the
> theory hasn't evolved? A theory that hasn't evolved is either of no
> interest (and therefore no one wants to work to evolve it), or is
> useful enough not to require evolution. Relational is both.

Yes, nobody argues that RM is powerful and simple enough to satisfy almost all needs. But not all and not forever. So it should not be considered a religion and if something does not work we simply should say that it does not work and that is all. For example, a model consists of a list of tables (not a hierarchy, not a graph but simply a flat list). So what? It was designed so. And if I need to have an internal stucture then I need to choose some other model. Then the question is if having a structure and hierarchies is really of fundamental importance or not. I say yes. You say no. We can only believe in that.

> So because I don't possess a 15' tall automated filing cabinet and a
> robot to search it, and thus must store papers in different places, our
> systems should work the same? This is just more useless
> anthropomorphism. Presumably we want systems that help us work around
> our deficiencies, right?

Here we come to the question why do we need structure for? Your point is that we need it for performance reasons, i.e., if our access process is not fast enough then we might think about introducing some structure. If our computer and disks are powerful enough then we can put everthing in one place. Here I agree but only taking into accout the conventional approach to computing and data modeling (which I do not support).

There is an alternative point of view. Here we assume that structure is actually more important than what is inside (for large systems). In other words, for large (data or computing) systems a structure accounts for most its complexity. For example, we might want to inroduce a hierarchy in order to carry out security checks or we might want to have different transaction scopes or we might want to have different caches and business logic. In contemporary systems these operations account for most of complexities and they are executed on borders rather then inside. So hierarchies make sense by themselves and not only as a human-oriented anthropomorpic access accelerator.

> How would such a structure help us avoid problems, and which problems
> do you mean?

Security - I want different tables to be in different scopes/containers/databases and to have different permissions and security checks for them.

Physical location - I want to have complete control in my model where and how tables are positioned.

Access system - I want to control how different tables are accessed.

Transactions - currently we have a situation where one database establishes one transaction scope. What if I want to have an internal (local) transaction scope? Or I want to include my database into an external transaction scope?

Business logic - I want some functions to be executed whenever some process intersects my private scope or accesses some data.

Currently I have no problem to implement all these functions but I want to have all these things in one model. If you do not want then I am surprised so this is why I am using the term "obvious".

> I'd be happy to see a coherent critique of relational, as it would help
> my understanding of it and alternatives. If you care to present one,
> I'd like to read it.

Relational model cannot critisized just procedural programming or oo-programming or other closed theories. It serves its goals, it was designed so. You can only believe in it.

>>So hierarchies in data modeling are not simply desirable. They must
>>exist because any system has a hierarchical natural (fundamental
>>principle).

Have you ever seen a non-hierarchical system? A relational model sits over some file system but it simply fails to describe this connection. You can argue that it is an advantage but I would like to have a control what happens when some table is accessed. If I do not need this then I will not use it but the model and the system should have such a facility. What if I want to have my own model on top of my database?

> Although I don't agree with all he says, I'll quote Bertrand Meyer on
> this: "Real systems have no top."

I would say, that real systems always have a top but have no bottom. Any system can be represented by one point at the most abstract level but it cannot be reduced to any lower level because the bottom does not exist (we always can find a lower level).

But may be it is one and the same if we invert the meaning of top and bottom :-)

Ok, returning to the question of importance of having hierarchies and structure the problem is how to model this connection between top and bottom.

alex
http://conceptoriented.com Received on Tue Apr 19 2005 - 17:20:59 CEST