Re: Use of the term "hierarchy"

From: Alexandr Savinov <spam_at_conceptoriented.com>
Date: Sat, 27 Aug 2005 18:13:21 +0000
Message-ID: <4310ad6e@news.fhg.de>

Marshall Spight schrieb:
> Alexandr Savinov wrote:
>

>>SQL is aimed at manipulating records, not tables.

>
>
> I don't see how. Maybe you mean things like cursors?
> I suppose so, but I would consider the core of SQL
> to be select/join/restrict etc., which is not at all
> record-oriented.
>
> In fact, even something like
>
> select a from b where c = d
>
> could not really be said to be record-oriented;
> it's a set operation. You can't tell by looking
> at it whether its result will be cardinality 1
> or not; compare with, say, array access in many
> imperative language.
>
> Then you also have things like
>
> select * from a natural join b

Yes, I agree, but I meant different thing. We cannot manipulate tables as easily as we can manipulate (sets of) records. Creation and deletion of records is one operation while creation and deletion of tables is another operation. Records may have properties (columns) while tables do not have them (I mean user-defined properties that can be assinged values). We can aggregate, project, join sets but we cannot do the same with table. For example, if we have our departments represented by separate tables then how can we query properties of those departments? Normally for each table we have a record and then process them - but not tables directly. If a new department is created/deleted then its table has to be created/deleted but these operations are not even transactionsl.

The same can be said about columns (dimensions). We cannot easily work with them if information is represented in this way. Just like in many cases we need to represent entities by tables, we need also to represent something in columns. A simple (I do not say good) example is where one column stores sales for one month. If the sales were represented in records we could easily apply our powerful query language. But if for some reason they are stored in columns then we need to process the data manually.

Again, I did not say that we really need

table-oriented modeling facilities and query language, and/or
column-oriented modeling facilities and query language.

But if we make several assumption about our hypothetical data model then might draw a conclusion that data modeling *can* be carried out by means of tables and by means of dimensions. And then we might want to introduce something that would allow us to query those elements of the model more productively then it is now in SQL or in existing data models.

--
http://conceptoriented.com

Received on Sat Aug 27 2005 - 13:13:21 CDT