Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
Date: Tue, 07 Jun 2005 17:18:15 +0200
Message-ID: <42a5bac9$1_at_news.fhg.de>
Jon Heggland schrieb:
> In article <e%hpe.7195$F7.5782_at_news-server.bigpond.net.au>,
> hobbit_at_southern_seaweed.com.op says...
>
>>"Tony Andrews" <andrewst_at_onetel.com> wrote in message >>news:1118141746.220955.243690_at_o13g2000cwo.googlegroups.com... >> >>>Alexandr Savinov wrote: >>><SNIP> >>> >>>Which part of the decomposition process reduces 1 row to 0 rows? I >>>must have missed that part... >> >>I imagine this can be done by querying the system table register >>for the name of a table, instead of querying a table for the name >>(value) of a key. >> >>Instead of writing or deleting a row, you could >>create or drop a table with zero rows.
>
>
> In that case, you are using the rows in the "system table register"
> table for your information; the actual tables you create and drop are
> just irrelevant side effects -- you don't use them for anything at all.
Yes, these are side effects if we are not going to insert any rows into those system table rows. But this example was used to demonstrate that tables are used to represent some entities from the problem domain and in this sense it is possible to model the problem domain by using tables. The fact that tables are normally used to include records while records are normally used to include fields simply emphasizes their special use. In general case any entity has two aspects:
- it can be viewed as a collection of other entities (collection here means formally logical sum or a set normally designated as {}),
- it can be viewed as a combination of other entities (combination here means formally logical product designated as <>). If one of these aspects is absent (not implemented) then we get either a table/container or a row/object.
Another point is how can we model the problem domain. Here again we have two ways:
- we can define an entity as a collection of other entities (let's call it 'instance of' relation between a table and its member). In this case the members physically belong to the collection.
- we can use a relation between an object and its value. In this case the record logically belongs to its values (other records), for example, a record <1, 5, 10> belongs to 1, to 5 and to 10 simultaniously.
In relational model tables are simply containers (collection of other entities) and it is impossible to directly define new properties for them. Records are simply objects (combinations of other entities) and we cannot add records to records. And such a definition is really effective and covers a huge number of situations. However, the question was how can we treat tables as entities and can they be treated as entities at all. There was an opinion that tables are not entities and have nothing to do with the data semantics.
> Alternatively, if the "system table register" is not organized as a
> relational table, you are no longer using the relational model, and the
> whole point is lost.
As far as I understand the relational model does not use any system table or a table of tables - it is how RDBMSs are implemented. Relational model works independently of how this meta information is stored and if it exists at all.
-- alex http://conceptoriented.comReceived on Tue Jun 07 2005 - 17:18:15 CEST