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

From: Alexandr Savinov <savinov_at_host.com>
Date: Fri, 17 Jun 2005 10:55:01 +0200
Message-ID: <42b28fe7$1@news.fhg.de>

Jan Hidders schrieb:
> Jon Heggland wrote:
>

>> In article <42b16163$1_at_news.fhg.de>, savinov_at_host.com says...
>>
>>> Jan Hidders schrieb:
>>>
>>>> For a very short explanation and a link to Jeffrey Ullman's sheets:
>>>>
>>>> http://app.deklarit.com/kb/article.aspx?id=10038&cNode=8J8X2Y
>>
>>
>> I looked at Ullman's slides and found a strange thing. I quote:
>>
>> Suppose we have relations ED, EO, EP, and DM,
>> connecting employees to departments, phones, and
>> offices, respectively, and departments to managers.
>> [...]
>> Consider a query "find the offices of employees
>> managed by Sally."
>>
>> (End quote)
>>
>> Note that the relations do not say that *employees* have managers, 
>> just that *departments* do. Is it the case that an employee in a given 
>> department is always managed by the manager of that department? It is 
>> possible, even probable, but the database (as presented) does not say! 

>
>
> IMO that's not really a fair criticism. Whether you use the UR
> assumption or not, you always have to know what the columns of the
> relation(s) mean in order to understand what a query means. So in this
> case the querier can be assumed to know that the 'manager' column
> contains the manager of the department of the employee. If there is also
> another manager that is separately assigned to employees then the UR
> would probably contain a column 'dept-manager' and another column
> 'emp-manager' to distinguish the two concepts.

I want to make these things clear in COM so that any ambiguity and informality is removed and at the same time make the model less complex. I see already a couple of solutions but I need to read those papers about UR model. In COM all tables are hierarchically ordered so tables E, O, P, and D are at level 1 while tables ED, EO, EP, and DM are at level 2 (normally we have more levels). If we have constraints in some tables (say, M.name='Sally') then it needs to be propagated downward till the bottom concept where it is imposed on other possible constraints. After that in order to get the result we need to propagate this result upward in the direction of the target table, say, Employees). I shortly described in some paper but did not focuse on (very important and intresetning) details.

Let's take three tables E, D, and M and two subtables ED and DM. If we impose constraints on M then we are not able to infer anything on E. The reason is formally clear: ED and DM are independent (orthogonal) because they do not have a common subtable (a formal criterion). This means that the canonical semantics (or primitive semantics) is represented as a sum of two tables ED and DM without intersection like this one:

emp1, dept1, null, null
emp2, dept2, null, null
null, null, dept1, mng1
null, null, dept2, mng2

It consists of two isolated sections so it is not a fault of the database that it cannot infer anything about employees given information about managers. We need somehow connect two department columns in the middle. In the RM it is not a problem because everything is done manually without any rules, i.e., there is SQL and do whatever you want including specifying arbitrary joins and where criteria. The real problem is to do it without complicating the model so that the mechanism can be qualified as natural and simple.

-- 
http://conceptoriented.com

Received on Fri Jun 17 2005 - 03:55:01 CDT