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

Alexandr Savinov wrote:

>> This relies on the fact that domain names are a hierarchy, so I'm not
>> sure how a similar idea would work with the standard relational model
>> though.

The relational model doesn't have hierarchies because it's based on first order predicate logic. I guess this was chosen as the basis because it's simple enough to implement yet powerful enough to be useful. That doesn't mean to say it's the only possible model to use for databases though!

> Having hierarchies is only one thread leading to a new model. Indeed,
> why we have to store (to model) all our tables in one space/scope? We
> never do it with our own files or other things so why do we do it with
> tables? Because there are no other means.

Logically there is no need for separate namespaces because it's the data in the tables that is important. The names of the tables are irrelevant really. You can have namespaces in SQL tables if you want: just call them namespace1_table1, namespace2_table1, secondlevel1_namespace1_table1, etc. Or use database permissions to restrict access to certain tables for certain people.

Physically, there is nothing to stop you organising tables into a hierarchy, or even distributing them across several machines. That's independent of the logical structure.

> Let us assume that there exist
> several departments so why not to model their data structure separately
> in their own spaces which are subspaces of one common space? It would
> absolutely natural and we could avoid very serious problems frequently
> encountered in complex systems.

What if separate departments independently decide to model the same thing in each of their namespaces. And then store inconsistent data? You end up like the internet where half the sites will tell you one thing and the other half will tell you the opposite. To avoid that, some degree of centralisation is inevitable.

> But we prefer to cheat ourselves by repeating that the relational
> model is the ultimate model and it can model any possible situation
> and if not then you are have low qualification.

I suppose they are just solving slightly different problems. The relational model is for tightly controlled situations where things are either right or wrong. A distributed model gives you less assurances as to accuracy but has advantages in other areas (scalability, maybe?)

> So hierarchies in data modeling are not simply desirable. They must
> exist because any system has a hierarchical natural (fundamental
> principle). But if we introduce them then it will be already a
> completely new model.

So is your motivation for considering hierarchical models the fact that they are easier to distribute over many physical machines (like DNS)?

Or are there other reasons?

Paul. Received on Tue Apr 19 2005 - 15:52:42 CEST