Re: A research effort on a computing model...
Date: Fri, 08 Feb 2008 19:39:34 GMT
Message-ID: <Wd2rj.6478$0w.3614_at_newssvr27.news.prodigy.net>
"Cimode" <cimode_at_hotmail.com> wrote in message
news:bd675683-86ad-40a5-9985-a810cef1d2bc_at_y5g2000hsf.googlegroups.com...
> On Feb 8, 3:56 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>> "Cimode" <cim..._at_hotmail.com> wrote in message
>>
>> news:aea0bb14-be40-4f56-aada-7edbd4501fd7_at_e23g2000prf.googlegroups.com...
>>
>> > [Snipped]
>>
>> >> 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.
>>
>> > Actually Keys are initially a physical concept in IBM mainframes that
>> > Codd reused to clarify the relational model. I do not believe it to
>> > be such a determining factor. On the other hand, domains are a much
>> > more powerful concept to describe functionnal dependencies.
>>
>> What does it matter that the physical concept in IBM mainframes uses the
>> same term? I don't think Codd's use was merely for clarification. Keys
>> and
>> foreign keys are fundamental. I suggest you read Ronald Fagin's paper on
>> DKNF.
> Done thanks. > > I have not stated that keys were useless but simply that the concepts > they underline can be expressed differently. Their importance in RM > seems overrated. > >>> >> misguided.
>> >> Also, you're assumption that foreign keys should be implicit is
>> >> Consider:
>>
>> >> MachinesEmployeesAreTrainedOn {Employee, Machine}
>> >> KEY{Employee, Machine};
>>
>> >> MachinesEmployeesAreRunning {Employee, Machine}
>> >> KEY{Employee, Machine}.
>>
>> > I do not see any real contradiction, except on the imperative use of
>> > KEY terminology to clarify JOIN dependency, using your example...
>>
>> > Assuming a M:N cardinality between Machines and Employee, associative
>> > relations such as MachinesEmployeesAreTrainedOn and
>> > MachinesEmployeesAreRunning are simply sub types of Machine_Employee
>> > domain defined according to relation/type Employee and Machine. In
>> > other words, MachinesEmployeesAreTrainedOn and
>> > MachinesEmployeesAreRunning relations are subsets of Machine_Employee
>> > cartesian product.
>>
>> >> 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.)
>> > I do see your point. Fair enough. Suppose the following relations
>>
>> > EMPLOYEE
>> > MACHINES
>> > EMPLOYEE_MACHINE (representing the associative relation between
>> > EMPLOYEE and MACHINES)
>>
>> > Nothing prevents from declaring MachinesEmployeesAreTrainedOn and
>> > MachinesEmployeesAreRunning as independet subsets of EMPLOYEE_MACHINE
>> > or as subset of one another. In the case they would not be
>> > independent functional dependency can simply be expressed by adding
>> > additional constraints on both MachinesEmployeesAreTrainedOn and
>> > MachinesEmployeesAreRunning relation definition. At definition time
>> > we can simply write:
>>
>> How far do you want to go?
> Quite frankly: as far as possible from current implementations. I > have nevertheless answered your question based on an example. As I > have mentionned in the header, some choices I made are not > conventional among which the fact that I do not place so much emphasis > on the concept of key. >
>> Any juxtaposition of two attribute values could
>> refer to an individual in the Universe of Discourse. Consider the case
>> of a
>> relation that is in 3NF but not in BCNF due to overlapping keys. If A,
>> B,
>> and C are prime attributes in a relation,
>> {A, B, C, D} with keys {A, B}, {B, C} and {A, C},
>> would you have a separate relation for A*B, a separate relation for B*C,
>> and
>> a separate relation for A*C so that the result would be {AB, BC, AC, D}?
> The above reason and questions only applies when keys are central to > the problem. When this is not the case, BCNF somehow becomes moot > concept. The overlapping example is a specific problem I have not yet > adressed but it is in my top list for next year (as well as temporal > data). >
>> What would be the point? Why not just use IDENTITY fields.
> Why use them if we can simply use custom made typing and superkeys. >
I brought that up because it appears that you're going to require that every key be unary. Whether you call it a unique identifier or whatever, there are problems associated with forcing all keys to be unary, and I think that before there can be general acceptance of your ideas, you will have to address those issues thoroughly. On the one hand, unique identifiers bear a striking resemblance to object identifiers, and on the other hand, there are issues, particulary due to redundancy, with nested relations. How to you propose to get around those?
>> > EMPLOYEE: fname(string), lname(string)
>> > MACHINES: model(string), number(string)
>> > EMPLOYEE_MACHINE: employee(employee), machine(machine)
>> > MachinesEmployeesAreTrainedOn: employee_machine(employee_machine WITH
>> > first set of constraints) and assuming Employee can run only machines
>> > they have been trained on, simply define
>> > MachinesEmployeesAreRunning:employee_machine(MachinesEmployeesAreTrainedOn)
>> > and in this case MachinesEmployeesAreRunning is necessarily a subset
>> > of MachinesEmployeesAreTrainedOn. Functional dependencies is
>> > preserved without having to use the KEY concept.
>>
>> > [Snipped]
>> >> 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.
>> > See above.
>>
>> > I believe mentionned that the unique identifier (equivalent of primary
>> > key) necessarily constitutes a superkey and that I express the foreign
>> > key concept implicitely through subtyping.
>
Received on Fri Feb 08 2008 - 20:39:34 CET