Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

Jon Heggland schrieb:
> In article <42a58ced$1_at_news.fhg.de>, savinov@host.com says...
>

>>Tony Andrews schrieb:
>>
>>>False: your alternative #2 does not represent the tree structure at
>>>all, it is just a bunch of unrelated tables, each of which contains
>>>some items.  Where did the folder tree structure go?  Try again!
>>
>>Yes, you are right, we need to connect the tables so that each table 
>>known its parent table. But it does not change the point - it only even 
>>better demonstrates limitations of relational model.

>>One solution is to connect them statically via your application. 

>>Another solutions is where 
>>you can store this information  a table from #1 where one row represents 
>>one table. 

>>But do not say that #2 is now equivalent to #1. Because the 
>>main issue here is that for each row from Folder table there is one real 
>>table which contains a set of items. Now very important point (for the 
>>solution): if in case #1 each item specifies the parent folder by using 
>>some field, i.e., by using legal relational facility, then in #2 each 
>>item belongs to its folder (table) by using 'instance of' relation, 
>>i.e., it is a row in this table. Thus we use for data modeling two 
>>absolutely different types of relations. 

I did not describe any data model here - you try to see an evil where it does not exist. I provided a couple of examples and a couple of alternative designs and interpreations with the purpose to demonstrate that tables can be viewed as entities - that is all. Moreover, this point has a little to do with the relational model - it is a higher level issue.

>>And again, the whole example 
>>demonstrates that tables should be legal element for use in representing 
>>data semantics.

So why you represent real entities from your problem domain by tables? Again, it is not a matter of necessity, right or wrong. Whenever you create a table you want it to represent some entity. If you define tables Departments, Products and Personel then you defined three kinds of entities and your model consists of three elements already! And you are saying it is not necessary. What is not necessary, representing the state of data in the database? I do not understand. The initial point was that tables represent real entities even if you do not like that. You might define a table ProductItems and then keep your products in one wide table. And then you might find it inconvenient and two additional tables, say, Cars and Houses. So you introduced into your model two additional entities called Cars and Houses. The only problem is that RM does not allow to add properties to these entities because they are represented by tables. This is why we might want to represent them by normal rows is a special table ProductTypes.

>>Here is even simnpler example. Assume you have a number of departments. 
>>There is two ways how you can represent them:
>>1. As records in a table of departments
>>2. As individual tables (possibly with support from one common 
>>meta-table from #1 as you noticed because relational model does not 
>>allow for tables to have fields and to be used as entities)

I do not introduce anything at all and if there is some complexity then it is done deliberatly - I provide examples which demonstrate that tables *are* used for modeling and representing data semantics.

>>I return to the initial point: tables should be considered normal 
>>entities with special role and vice versa normal entities should be able 
>>to play a role of tables.

Because our data has such a property. We always represent entities by tables and want our records to store internal records.

>>Another aspect of this problem. A schema is not part of the relational 
>>model but it is heavily used in complex applications. You know that any 
>>implementation has a table of tables and it is reflects the fact that 
>>tables are rows and have normal properties.

Of course, and I absolutely agree here, tables are not vars - but only in relational model. But in data modeling they are! And it would nice to have a model that formalizes this fact. As I illustrated in several previous examples we frequently use tables as records and vice versa.

You project everything on relational model so it does not make sense to continue. It is the same if I were explaining what a complex number is and you would reply that we do not the imaginable part because real numbers do not need it. Of course, real numbers do not need the imaginable part because they are defined so. But numerous practical applications show that real numbers simply ignore this part of number and in many applications it is much easier to have it explicitly.

-- 
alex
http://conceptoriented.com