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

Alexandr Savinov wrote:
> 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.

You still have to model it - there are many types of hierarchies, unless you're simply talking about "nesting" in some generic sense. But given that RM supports the following:

1. user-defined types (e.g. HIERARCHY)
2. joins to support various "hierarchical" views of data
3. relations defined to implement hierarchies per se

Is there an advantage in something more?

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

Often systems require more than one of these - in essence, applications/views/queries/reports over a common set of data. So you want a "data model" that can support all of these.

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

Your example demonstrates my point: different people want different things. Different user roles require different views of the data. Some want to view the files as a list; some as a hierarchy as they define it; others, perhaps, as a hierarchy of file types. Look at Windows: most users relate to it not as C:\..., but as My Documents and My Network Places etc. The implementation may still be hierarchical, but the view is less so. Symlinks, mount points, etc. are similar examples.

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

No, I don't think so.

> In RM we do not have a structure at all, so is not it a drawback?

Of course there's "structure" (the word is wearing very thin), but the point is that it lets you model your data, and can support hierarchies as described above.

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

Agreed, on all counts. But going from "powerful and simple enough to satisfy almost all needs" to "does not work" is a large leap.

> For example, a model consists
> of a list of tables (not a hierarchy, not a graph but simply a flat
> list).

Flat? Here's a flat list: (0,0,0), (0,0,1), (0,1,0), (0,1,1), (1,0,0), (1,0,1), (1,1,0), (1,1,1). It's also a cube. Here's something very "flat" as well: w^2+x^2+y^2+z^2=1, a hypersphere. We can't assume from a Mercator projection map that the earth is flat, nor are paper or screen representations of relations "flat." You can't make vague assertions about the "flatness" of a model based on representations of query output.

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

Structure is to be defined by the user, unless you think one size fits all.

> Here we come to the question why do we need structure for?
> Your point is that we need it for performance reasons,

Actually, I wasn't talking about performance. Structure is critical long before performance considerations.

> There is an alternative point of view. Here we assume that structure
is
> actually more important than what is inside (for large systems).

You're assuming the two are orthogonal. Presumably you're structuring something? In what way, in a real system, is a hierarchy more important than the data being stored? Certainly the hierarchy enables some forms of manipulation and access; relations (proper to the domain predicates) enable far more.

> For example, we might want to inroduce a
> hierarchy in order to carry out security checks

If hierarchies fit the bill, then fine. But you're still assuming the utility of hierarchies, and that they need to be first-class (is there a better term for this, anyone?) entities.

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

Hierarchies don't make any inherent sense to me for any of the above. But your next list is very interesting:

> Security - I want different tables to be in different
> scopes/containers/databases

Why? I have yet to understand the value of "scopes/containers."

> and to have different permissions and security checks for them.

Certainly this is desirable - how is it hierarchical?

> Physical location - I want to have complete control in my model where

> and how tables are positioned.

In a model? Certainly that's a model at a different layer of abstraction (and hence non-conflicting) from the RM. Presumably different DBMS vendors offer different physical distribution mechanisms, but this problem is of a different order than the rest we're discussing.

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

Understandable - how does a hierarchy assist modeling this?

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

Transaction scopes can certainly be nested, and standards like XA offer distributed transaction capabilities. Nesting in this manner isn't necessarily indicative of hierarchy, at least at the data level; the data manipulations controlled by transactions are part of an application. Functional languages, for example, offer nesting that has no bearing on data per se.

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

Most triggers are substitutes for the lack of adequate integrity declarations, or are pieces of applications. Hierarchies?

> Currently I have no problem to implement all these functions but I
want
> to have all these things in one model.

Why "one model"? The computing industry makes inadequate use of the models it has, and I think focused models offer more than premature attempts to develop the computing equivalent of string theory, especially when the industry has flocked to a OO, a largely theory-free, model-free bit of tripe for which metrics have demonstrated no advantage.

> If you do not want then I am
> surprised so this is why I am using the term "obvious".

The above list is a mostly desirable set of properties, but are completely orthogonal to the question of hierarchies as a basic structuring principle for data.

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

"Closed theories" as opposed to... ? Criticism is a good thing, don't get me wrong, but it must be based on something other than "X is limited, therefore we need Y" without ever defining the limitation or Y.

> Have you ever seen a non-hierarchical system?

Yes, I'm working on one now.

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

Me too. How do hierarchies help?

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

It's called an "application." The RM was specifically designed for shared data store; if you're not sharing data with others, then your personal preferences have a far greater weight in your decision-making.

> 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

If you define "system" as "something that can be reduced a single point" (whatever that means), then this is trivially true. So is your axis of hierarchical decomposition "contains"? "Includes"? "Implements"? Again, a useless distinction, as we can find any number of hierarchies to superimpose over any number of other structures (e.g. a relational database).

> but it
> cannot be reduced to any lower level because the bottom does not
exist
> (we always can find a lower level).

A lower level beyond machine code? Beyond magnetic fields?

> Ok, returning to the question of importance of having hierarchies and

> structure the problem is how to model this connection between top and

> bottom.

So is your question whether hierarchies are useful in modeling systems or data? If both, then I'd ask why a unified model is critical.

• erk