Re: A research effort on a computing model...

"Cimode" <cimode_at_hotmail.com> wrote in message news:6333f0b5-936e-49b1-96eb-ffb386362626_at_s12g2000prg.googlegroups.com...
> On Feb 8, 1:00 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>> "Cimode" <cim..._at_hotmail.com> wrote in message
>
>> Trivializing functional dependencies? Eliminating inclusion
>> dependencies?
>> Sounds to me like you'll have a big job selling that.
> Thanks for the comments.
> Quite frankly, I do not recall mentionning anything about dependencies
> which are logical concepts that can be supported otherwise than by
> using keys. Instead of keys, a concept prior to RM, I prefered the
> concept of unique identifier, type and un-ary type. Just keep in mind
> that this is not a SQL system. Besides, I really am not trying to
> sell anything (the db core is designed to be open source) but rather
> as a way to explore new pathes and open up the ground for new ideas
> and perspectives to emerge .
>
> To give you an idea:
>
> if you consider...
>
> PART: NUMBER(integer), NAME(string) and CAR: MODEL(string),
> PART(part) , PART in CAR has type PART , therefore *foreign key* is
> implicit though use of user defined type. I mentionned that a
> relation *de facto* constitutes a type with limited number of values
> that some other relation can draw from. I somehow believe that the
> concept was to use by Codd as a marketing effort to convince his IBM
> audience
>
> Hope this clarifies...

It does not.

Keys are also a logical concept. Keys imply join dependencies (including functional dependencies), and due to the Principle of Full Normalization, join dependencies can imply keys.

Also, you're assumption that foreign keys should be implicit is misguided. Consider:

MachinesEmployeesAreTrainedOn {Employee, Machine}

    KEY{Employee, Machine};

MachinesEmployeesAreRunning {Employee, Machine}

    KEY{Employee, Machine}.

Without any foreign key, the two are unrelated: an employee can be running a machine that he /is not/ trained on, an employee can be running a machine that he /is/ trained on, or an employee can be trained on a machine that he is not running. (Or neither, assuming, of course, that there is an Employees relation.)

With a foreign key, on the other hand, from MachinesEmployeesAreRunning to MachinesEmployeesAreTrainedOn, an employee can only run a machine that they're trained on.

Without the foreign key, each tuple in

MachinesEmployeesAreTrainedOn JOIN MachinesEmployeesAreRunning

represents an instance where an employee is running a machine that he is trained on.

With the foreign key, on the other hand, each tuple in MachinesEmployeesAreRunning represents an instance where an employee is running a machine that he is trained on. Received on Fri Feb 08 2008 - 11:23:23 CET