Re: On formal HAS-A definition

>On 4 mei, 23:21, Tegiri Nenashi <tegirinena..._at_gmail.com> wrote:
>> Again, I didn't research literature, but here is my shot: the HAS-A is
>> an inclusion dependency.

This disagrees with my definition, once again by dropping one or more constraints. In my definition, every part has exactly one whole. In yours, every part has at least one whole. Also, you are comparing all columns of the tables. but comparing the primary keys should suffice I think. This may be a matter of taste.

>> Example:
>>
>> Dept = [DeptNo DeptName]
>>         10     Accounting
>>         20     Research
>> ;
>>
>> Emp = [DeptNo EmpName]
>>        10     King
>>        10     Smith

If King is also in dept. 20, do we still have a has-a? I say: it depends on what you mean by has-a, but usually we mean composition rather than aggregation, and this is a violation of composition.

>> Formally:
>>
>> Emp v (Dept ^ []) < Dept v (Emp ^ []).

This is really strange. Usually Emp has attributes that Dept doesn't have.

>> I suppose HAS-A shares many unconvenient properties with set
>> membership, for example, it is not transitive.

I don't think I'm bothered by that fact. Belief in strong typing tends to do that to you. An employee just isn't a department so why would an employee ever need to pose as one?

>> Accounts = [EmpName Institution]
>>             Smith   BoFA
>>             Smith   WellsFargo
>> ;
>>
>> the it is not the case that "Dept HAS-A Accounts". Again, the naming
>> problem raises its ugly head: why would the first attributes be called
>> "EmpName" rather than "PersonName"?

Yes, there is something to be said for HAS-A and IS-A notions that allow attribute renaming. If only to allow recursive HAS-A and IS-A (e.g. ancestor as the transitive closure of parent).

>> More important: is this correct formalization? Specifically, shouldn't
>> functional dependency
>>
>> Dept # DeptNo < Dept # DeptName
>>
>> be a part of HAS-A constraint definition?

>My feeling is you are treading slippery territory.
>
>"Each customer has an address" can (and may likely) be modeled as two
>distinct relvars, with an inclusion dependency / FK-like database
>constraint / howyouwanttonameit between the two.

This is neither aggregation (in the weak entity sense) nor composition (in the cardinality sense).

[...]

>As I already stated elsewhere, my feeling is that "is-a" and "has-a"
>are part of the world of informal modeling, database constraints are
>part of the world of formal modeling.

They are not with my (e.g. Silberschatz et al.'s) definitions.

>Those two worlds are disjoint,
>and the only connection between them is that one (informal) may act as
>the input for the designer who is deciding how to define the other.

They are not disjoint at all. They are both perfectly formalizable, one being more specific than the other.

-- 
Reinier