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

Paul schrieb:
> 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!

Yes, I absolutely agree. But there exist another opinion, namely, that relational model is the only and the ultimate model. And the last argument for that statement is "because it is based on set theory". It is the same if I said that my new processor is the best one because it is based on quantum physics in its semiconductor. What in our world is NOT based on set theory and quantum physics?

> 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.

Yes.
Names are a primitive form of having a sructure and in data modeling they are almost useless. We want to have some rich functionality to be associated with our structure (security, transactions, physical allocation, business logic, access control etc.) Many things we can do by using database system (partitioning, security etc.). But the main question is that we would like to have it all within our model. In other words, we want to have a model that would make other technolgies (application servers, transaction monitors, firewalls, partitioning etc.) unnecessary because this model already has all their functions and methods. Ok, 10% of that would be enough (but goals should be unreachable).

> 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.

Definitly.
Centralization cannot be avoided - it can be only minimized to a certain degree (if it is necessary). And it is very important to have control over it.

> 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?)

RM is an excellent solution but everthing has its limitations.

>>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.

Hierarchies is only an example where there is a chance to demonstrate something that does not exist and cannot be modeled in RM. (I do not means semantic hierarchies or graphs easily modeled in RM.) Having a hierarchal structure may serve very different purposes because we can assign very different functions and parameters to our scopes/folders/local databases. For example, physical allocation, transaction scope (it is inefficient to have one global transaction scope if many operations are known to involve only local data), business logic, security, access control. So actually this thread establishes a priority of structure over what is inside, i.e., all important functions and data are concentrated and executed on borders (when they are intersected during access process).

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