 | |
A research effort on a computing model...
comp.databases.theory comp.databases.theory
 |
| | Thread Tools | Display Modes |
#81
 
| |||
| |||
|
Re: A research effort on a computing model... -
02-08-2008
, 06:00 PM
|
"Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:bd675683-86ad-40a5-9985-a810cef1d2bc (AT) y5g2000hsf (DOT) googlegroups.com... On Feb 8, 3:56 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:aea0bb14-be40-4f56-aada-7edbd4501fd7 (AT) e23g2000prf (DOT) 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. 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}. 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. Noted. I just have not mentionned that I was forcing use of un-ary |
un-ary key.
Quote:
|
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? |
<<<<<<<<<<<<<<<<<<<<<<<
What are these issues. Providing an example I can attempt bringing an
anwser to may help. As I mentionned, dupplicates are systematically
rejected. They are inherently impossible. as a part of the logical
model for the system.
Quote:
again. I don't think a recap would serve any purpose. The problems with
nested relations are due to having the same information recorded in the
database several times, possibly in several relations. This does not
necessarily mean that there are duplicates, as there can be in a SQL table.
A relation that is in 1NF but not in 2NF exhibits redundancy due to the fact
that there is unrelated information represented in a relation. A relation
that is in 2NF but not in 3NF exhibits redundancy because there is
information that depends on a set of attributes that is not a key, and
therefore there is redundancy whenever more than one instance of that set of
attributes appears. Similarly, when relations are nested, and a value that
appears both several tiers down one path of the hierarchy and a few tiers
down another, and that value is composed of several other values (subtrees,
if you will), the fact that that value appears several places can cause
problems, the most obvious being the need to update the value in several
places whenever the individual it represents changes or whenever any of the
components of that individual lower in the heirarchy changes.
#82
| |||
| |||
|
|
"Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:fee28a96-a126-4b79-8681-eb6a53b1320b (AT) p69g2000hsa (DOT) googlegroups.com... On 8 fév, 20:39, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:bd675683-86ad-40a5-9985-a810cef1d2bc (AT) y5g2000hsf (DOT) googlegroups.com... On Feb 8, 3:56 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:aea0bb14-be40-4f56-aada-7edbd4501fd7 (AT) e23g2000prf (DOT) 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. 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}. 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. Noted. I just have not mentionned that I was forcing use of un-ary keys...The example provided of associative entity certainly is not an un-ary key. 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? (My newsreader is not quoting correctly again. Sorry about this.) What are these issues. Providing an example I can attempt bringing an anwser to may help. As I mentionned, dupplicates are systematically rejected. They are inherently impossible. as a part of the logical model for the system. The problems with object identifiers have been discussed here time and time again. I don't think a recap would serve any purpose. The problems with nested relations are due to having the same information recorded in the database several times, possibly in several relations. This does not necessarily mean that there are duplicates, as there can be in a SQL table.. A relation that is in 1NF but not in 2NF exhibits redundancy due to the fact that there is unrelated information represented in a relation. A relation that is in 2NF but not in 3NF exhibits redundancy because there is information that depends on a set of attributes that is not a key, and therefore there is redundancy whenever more than one instance of that set of attributes appears. Similarly, when relations are nested, and a value that appears both several tiers down one path of the hierarchy and a few tiers down another, and that value is composed of several other values (subtrees, if you will), the fact that that value appears several places can cause problems, the most obvious being the need to update the value in several places whenever the individual it represents changes or whenever any of the components of that individual lower in the heirarchy changes. |
how you can come up to te conclusion that I am using object
identifiers as unique identifier based on the posted examples. Let me
describe the process by which the system allows t identify tuples.
Once a specific candidate key is identified by designer as a valid
identifier, the system *internally* decomposes the relation into 2
relations as a single relation on which the candidate key is stored
and a 2nd relation that implements a 1:0 cardinality to the first
relation. I have never mentionned that the first relation to have an
un-ary unique identifier. Here is an example:
suppose we have a PERSON relation : fname, lname, dob...suppose that
lname, dob constitues the unique identifer for PERSON...The system
internally (invisible) and logically decomposes PERSON as PERSON_PRIME
with lname,dob and implements unicity on lname and dob only then it
declare PERSON_SECOND with a reference to PERSON_PRIME and consider
lname, dob as a type of its own. ON a designer perspective, the
system still allows to manipulate PERSON as a relation only that it
internally considers it as a view. In such example, redudancy is
impossible and missing data is dealt way internally by the system.
I do not see then how that could lead anyone to the conclusion that
there may be some kind of un-ary relation prerequisite of any kind.
Subtyping is a process by which one can easily implement a reference
without having to go through the hassle of per-attribute analysis.
The methods decomposition and subtyping have been clarified over and
over by Hugh Darwen in thirdmaifesto.com even though he did it for
the purpose of clarifying correct ways of hadling missing information.
Hope this clarifies...
#83
| |||
| |||
|
|
"Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:fee28a96-a126-4b79-8681-eb6a53b1320b (AT) p69g2000hsa (DOT) googlegroups.com... On 8 fév, 20:39, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:bd675683-86ad-40a5-9985-a810cef1d2bc (AT) y5g2000hsf (DOT) googlegroups.com... On Feb 8, 3:56 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:aea0bb14-be40-4f56-aada-7edbd4501fd7 (AT) e23g2000prf (DOT) 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. 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}. 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. Noted. I just have not mentionned that I was forcing use of un-ary keys...The example provided of associative entity certainly is not an un-ary key. 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? (My newsreader is not quoting correctly again. Sorry about this.) What are these issues. Providing an example I can attempt bringing an anwser to may help. As I mentionned, dupplicates are systematically rejected. They are inherently impossible. as a part of the logical model for the system. The problems with object identifiers have been discussed here time and time again. I don't think a recap would serve any purpose. The problems with nested relations are due to having the same information recorded in the database several times, possibly in several relations. This does not necessarily mean that there are duplicates, as there can be in a SQL table.. A relation that is in 1NF but not in 2NF exhibits redundancy due to the fact that there is unrelated information represented in a relation. A relation that is in 2NF but not in 3NF exhibits redundancy because there is information that depends on a set of attributes that is not a key, and therefore there is redundancy whenever more than one instance of that set of attributes appears. Similarly, when relations are nested, and a value that appears both several tiers down one path of the hierarchy and a few tiers down another, and that value is composed of several other values (subtrees, if you will), the fact that that value appears several places can cause problems, the most obvious being the need to update the value in several places whenever the individual it represents changes or whenever any of the components of that individual lower in the heirarchy changes. |
how you can come up to te conclusion that I am using object
identifiers as unique identifier based on the posted examples. Let me
describe the process by which the system allows t identify tuples.
Once a specific candidate key is identified by designer as a valid
identifier, the system *internally* decomposes the relation into 2
relations as a single relation on which the candidate key is stored
and a 2nd relation that implements a 1:0 cardinality to the first
relation. I have never mentionned that the first relation to have an
un-ary unique identifier. Here is an example:
suppose we have a PERSON relation : fname, lname, dob...suppose that
lname, dob constitues the unique identifer for PERSON...The system
internally (invisible) and logically decomposes PERSON as PERSON_PRIME
with lname,dob and implements unicity on lname and dob only then it
declare PERSON_SECOND with a reference to PERSON_PRIME and consider
lname, dob as a type of its own. ON a designer perspective, the
system still allows to manipulate PERSON as a relation only that it
internally considers it as a view. In such example, redudancy is
impossible and missing data is dealt way internally by the system.
I do not see then how that could lead anyone to the conclusion that
there may be some kind of un-ary relation prerequisite of any kind.
Subtyping is a process by which one can easily implement a reference
without having to go through the hassle of per-attribute analysis.
The methods decomposition and subtyping have been clarified over and
over by Hugh Darwen in thirdmaifesto.com even though he did it for
the purpose of clarifying correct ways of hadling missing information.
Hope this clarifies...
#84
| |||
| |||
|
|
"Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:fee28a96-a126-4b79-8681-eb6a53b1320b (AT) p69g2000hsa (DOT) googlegroups.com... On 8 fév, 20:39, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:bd675683-86ad-40a5-9985-a810cef1d2bc (AT) y5g2000hsf (DOT) googlegroups.com... On Feb 8, 3:56 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:aea0bb14-be40-4f56-aada-7edbd4501fd7 (AT) e23g2000prf (DOT) 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. 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}. 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. Noted. I just have not mentionned that I was forcing use of un-ary keys...The example provided of associative entity certainly is not an un-ary key. 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? (My newsreader is not quoting correctly again. Sorry about this.) What are these issues. Providing an example I can attempt bringing an anwser to may help. As I mentionned, dupplicates are systematically rejected. They are inherently impossible. as a part of the logical model for the system. The problems with object identifiers have been discussed here time and time again. I don't think a recap would serve any purpose. The problems with nested relations are due to having the same information recorded in the database several times, possibly in several relations. This does not necessarily mean that there are duplicates, as there can be in a SQL table.. A relation that is in 1NF but not in 2NF exhibits redundancy due to the fact that there is unrelated information represented in a relation. A relation that is in 2NF but not in 3NF exhibits redundancy because there is information that depends on a set of attributes that is not a key, and therefore there is redundancy whenever more than one instance of that set of attributes appears. Similarly, when relations are nested, and a value that appears both several tiers down one path of the hierarchy and a few tiers down another, and that value is composed of several other values (subtrees, if you will), the fact that that value appears several places can cause problems, the most obvious being the need to update the value in several places whenever the individual it represents changes or whenever any of the components of that individual lower in the heirarchy changes. |
how you can come up to te conclusion that I am using object
identifiers as unique identifier based on the posted examples. Let me
describe the process by which the system allows t identify tuples.
Once a specific candidate key is identified by designer as a valid
identifier, the system *internally* decomposes the relation into 2
relations as a single relation on which the candidate key is stored
and a 2nd relation that implements a 1:0 cardinality to the first
relation. I have never mentionned that the first relation to have an
un-ary unique identifier. Here is an example:
suppose we have a PERSON relation : fname, lname, dob...suppose that
lname, dob constitues the unique identifer for PERSON...The system
internally (invisible) and logically decomposes PERSON as PERSON_PRIME
with lname,dob and implements unicity on lname and dob only then it
declare PERSON_SECOND with a reference to PERSON_PRIME and consider
lname, dob as a type of its own. ON a designer perspective, the
system still allows to manipulate PERSON as a relation only that it
internally considers it as a view. In such example, redudancy is
impossible and missing data is dealt way internally by the system.
I do not see then how that could lead anyone to the conclusion that
there may be some kind of un-ary relation prerequisite of any kind.
Subtyping is a process by which one can easily implement a reference
without having to go through the hassle of per-attribute analysis.
The methods decomposition and subtyping have been clarified over and
over by Hugh Darwen in thirdmaifesto.com even though he did it for
the purpose of clarifying correct ways of hadling missing information.
Hope this clarifies...
#85
| |||
| |||
|
|
"Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:fee28a96-a126-4b79-8681-eb6a53b1320b (AT) p69g2000hsa (DOT) googlegroups.com... On 8 fév, 20:39, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:bd675683-86ad-40a5-9985-a810cef1d2bc (AT) y5g2000hsf (DOT) googlegroups.com... On Feb 8, 3:56 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:aea0bb14-be40-4f56-aada-7edbd4501fd7 (AT) e23g2000prf (DOT) 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. 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}. 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. Noted. I just have not mentionned that I was forcing use of un-ary keys...The example provided of associative entity certainly is not an un-ary key. 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? (My newsreader is not quoting correctly again. Sorry about this.) What are these issues. Providing an example I can attempt bringing an anwser to may help. As I mentionned, dupplicates are systematically rejected. They are inherently impossible. as a part of the logical model for the system. The problems with object identifiers have been discussed here time and time again. I don't think a recap would serve any purpose. The problems with nested relations are due to having the same information recorded in the database several times, possibly in several relations. This does not necessarily mean that there are duplicates, as there can be in a SQL table.. A relation that is in 1NF but not in 2NF exhibits redundancy due to the fact that there is unrelated information represented in a relation. A relation that is in 2NF but not in 3NF exhibits redundancy because there is information that depends on a set of attributes that is not a key, and therefore there is redundancy whenever more than one instance of that set of attributes appears. Similarly, when relations are nested, and a value that appears both several tiers down one path of the hierarchy and a few tiers down another, and that value is composed of several other values (subtrees, if you will), the fact that that value appears several places can cause problems, the most obvious being the need to update the value in several places whenever the individual it represents changes or whenever any of the components of that individual lower in the heirarchy changes. |
how you can come up to te conclusion that I am using object
identifiers as unique identifier based on the posted examples. Let me
describe the process by which the system allows t identify tuples.
Once a specific candidate key is identified by designer as a valid
identifier, the system *internally* decomposes the relation into 2
relations as a single relation on which the candidate key is stored
and a 2nd relation that implements a 1:0 cardinality to the first
relation. I have never mentionned that the first relation to have an
un-ary unique identifier. Here is an example:
suppose we have a PERSON relation : fname, lname, dob...suppose that
lname, dob constitues the unique identifer for PERSON...The system
internally (invisible) and logically decomposes PERSON as PERSON_PRIME
with lname,dob and implements unicity on lname and dob only then it
declare PERSON_SECOND with a reference to PERSON_PRIME and consider
lname, dob as a type of its own. ON a designer perspective, the
system still allows to manipulate PERSON as a relation only that it
internally considers it as a view. In such example, redudancy is
impossible and missing data is dealt way internally by the system.
I do not see then how that could lead anyone to the conclusion that
there may be some kind of un-ary relation prerequisite of any kind.
Subtyping is a process by which one can easily implement a reference
without having to go through the hassle of per-attribute analysis.
The methods decomposition and subtyping have been clarified over and
over by Hugh Darwen in thirdmaifesto.com even though he did it for
the purpose of clarifying correct ways of hadling missing information.
Hope this clarifies...
#86
| |||
| |||
|
|
"Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:fee28a96-a126-4b79-8681-eb6a53b1320b (AT) p69g2000hsa (DOT) googlegroups.com... On 8 fév, 20:39, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:bd675683-86ad-40a5-9985-a810cef1d2bc (AT) y5g2000hsf (DOT) googlegroups.com... On Feb 8, 3:56 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:aea0bb14-be40-4f56-aada-7edbd4501fd7 (AT) e23g2000prf (DOT) 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. 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}. 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. Noted. I just have not mentionned that I was forcing use of un-ary keys...The example provided of associative entity certainly is not an un-ary key. 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? (My newsreader is not quoting correctly again. Sorry about this.) What are these issues. Providing an example I can attempt bringing an anwser to may help. As I mentionned, dupplicates are systematically rejected. They are inherently impossible. as a part of the logical model for the system. The problems with object identifiers have been discussed here time and time again. I don't think a recap would serve any purpose. The problems with nested relations are due to having the same information recorded in the database several times, possibly in several relations. This does not necessarily mean that there are duplicates, as there can be in a SQL table.. A relation that is in 1NF but not in 2NF exhibits redundancy due to the fact that there is unrelated information represented in a relation. A relation that is in 2NF but not in 3NF exhibits redundancy because there is information that depends on a set of attributes that is not a key, and therefore there is redundancy whenever more than one instance of that set of attributes appears. Similarly, when relations are nested, and a value that appears both several tiers down one path of the hierarchy and a few tiers down another, and that value is composed of several other values (subtrees, if you will), the fact that that value appears several places can cause problems, the most obvious being the need to update the value in several places whenever the individual it represents changes or whenever any of the components of that individual lower in the heirarchy changes. |
how you can come up to te conclusion that I am using object
identifiers as unique identifier based on the posted examples. Let me
describe the process by which the system allows t identify tuples.
Once a specific candidate key is identified by designer as a valid
identifier, the system *internally* decomposes the relation into 2
relations as a single relation on which the candidate key is stored
and a 2nd relation that implements a 1:0 cardinality to the first
relation. I have never mentionned that the first relation to have an
un-ary unique identifier. Here is an example:
suppose we have a PERSON relation : fname, lname, dob...suppose that
lname, dob constitues the unique identifer for PERSON...The system
internally (invisible) and logically decomposes PERSON as PERSON_PRIME
with lname,dob and implements unicity on lname and dob only then it
declare PERSON_SECOND with a reference to PERSON_PRIME and consider
lname, dob as a type of its own. ON a designer perspective, the
system still allows to manipulate PERSON as a relation only that it
internally considers it as a view. In such example, redudancy is
impossible and missing data is dealt way internally by the system.
I do not see then how that could lead anyone to the conclusion that
there may be some kind of un-ary relation prerequisite of any kind.
Subtyping is a process by which one can easily implement a reference
without having to go through the hassle of per-attribute analysis.
The methods decomposition and subtyping have been clarified over and
over by Hugh Darwen in thirdmaifesto.com even though he did it for
the purpose of clarifying correct ways of hadling missing information.
Hope this clarifies...
#87
| |||
| |||
|
|
"Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:fee28a96-a126-4b79-8681-eb6a53b1320b (AT) p69g2000hsa (DOT) googlegroups.com... On 8 fév, 20:39, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:bd675683-86ad-40a5-9985-a810cef1d2bc (AT) y5g2000hsf (DOT) googlegroups.com... On Feb 8, 3:56 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:aea0bb14-be40-4f56-aada-7edbd4501fd7 (AT) e23g2000prf (DOT) 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. 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}. 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. Noted. I just have not mentionned that I was forcing use of un-ary keys...The example provided of associative entity certainly is not an un-ary key. 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? (My newsreader is not quoting correctly again. Sorry about this.) What are these issues. Providing an example I can attempt bringing an anwser to may help. As I mentionned, dupplicates are systematically rejected. They are inherently impossible. as a part of the logical model for the system. The problems with object identifiers have been discussed here time and time again. I don't think a recap would serve any purpose. The problems with nested relations are due to having the same information recorded in the database several times, possibly in several relations. This does not necessarily mean that there are duplicates, as there can be in a SQL table.. A relation that is in 1NF but not in 2NF exhibits redundancy due to the fact that there is unrelated information represented in a relation. A relation that is in 2NF but not in 3NF exhibits redundancy because there is information that depends on a set of attributes that is not a key, and therefore there is redundancy whenever more than one instance of that set of attributes appears. Similarly, when relations are nested, and a value that appears both several tiers down one path of the hierarchy and a few tiers down another, and that value is composed of several other values (subtrees, if you will), the fact that that value appears several places can cause problems, the most obvious being the need to update the value in several places whenever the individual it represents changes or whenever any of the components of that individual lower in the heirarchy changes. |
how you can come up to te conclusion that I am using object
identifiers as unique identifier based on the posted examples. Let me
describe the process by which the system allows t identify tuples.
Once a specific candidate key is identified by designer as a valid
identifier, the system *internally* decomposes the relation into 2
relations as a single relation on which the candidate key is stored
and a 2nd relation that implements a 1:0 cardinality to the first
relation. I have never mentionned that the first relation to have an
un-ary unique identifier. Here is an example:
suppose we have a PERSON relation : fname, lname, dob...suppose that
lname, dob constitues the unique identifer for PERSON...The system
internally (invisible) and logically decomposes PERSON as PERSON_PRIME
with lname,dob and implements unicity on lname and dob only then it
declare PERSON_SECOND with a reference to PERSON_PRIME and consider
lname, dob as a type of its own. ON a designer perspective, the
system still allows to manipulate PERSON as a relation only that it
internally considers it as a view. In such example, redudancy is
impossible and missing data is dealt way internally by the system.
I do not see then how that could lead anyone to the conclusion that
there may be some kind of un-ary relation prerequisite of any kind.
Subtyping is a process by which one can easily implement a reference
without having to go through the hassle of per-attribute analysis.
The methods decomposition and subtyping have been clarified over and
over by Hugh Darwen in thirdmaifesto.com even though he did it for
the purpose of clarifying correct ways of hadling missing information.
Hope this clarifies...
#88
| |||
| |||
|
|
"Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:fee28a96-a126-4b79-8681-eb6a53b1320b (AT) p69g2000hsa (DOT) googlegroups.com... On 8 fév, 20:39, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:bd675683-86ad-40a5-9985-a810cef1d2bc (AT) y5g2000hsf (DOT) googlegroups.com... On Feb 8, 3:56 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:aea0bb14-be40-4f56-aada-7edbd4501fd7 (AT) e23g2000prf (DOT) 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. 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}. 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. Noted. I just have not mentionned that I was forcing use of un-ary keys...The example provided of associative entity certainly is not an un-ary key. 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? (My newsreader is not quoting correctly again. Sorry about this.) What are these issues. Providing an example I can attempt bringing an anwser to may help. As I mentionned, dupplicates are systematically rejected. They are inherently impossible. as a part of the logical model for the system. The problems with object identifiers have been discussed here time and time again. I don't think a recap would serve any purpose. The problems with nested relations are due to having the same information recorded in the database several times, possibly in several relations. This does not necessarily mean that there are duplicates, as there can be in a SQL table.. A relation that is in 1NF but not in 2NF exhibits redundancy due to the fact that there is unrelated information represented in a relation. A relation that is in 2NF but not in 3NF exhibits redundancy because there is information that depends on a set of attributes that is not a key, and therefore there is redundancy whenever more than one instance of that set of attributes appears. Similarly, when relations are nested, and a value that appears both several tiers down one path of the hierarchy and a few tiers down another, and that value is composed of several other values (subtrees, if you will), the fact that that value appears several places can cause problems, the most obvious being the need to update the value in several places whenever the individual it represents changes or whenever any of the components of that individual lower in the heirarchy changes. |
how you can come up to te conclusion that I am using object
identifiers as unique identifier based on the posted examples. Let me
describe the process by which the system allows t identify tuples.
Once a specific candidate key is identified by designer as a valid
identifier, the system *internally* decomposes the relation into 2
relations as a single relation on which the candidate key is stored
and a 2nd relation that implements a 1:0 cardinality to the first
relation. I have never mentionned that the first relation to have an
un-ary unique identifier. Here is an example:
suppose we have a PERSON relation : fname, lname, dob...suppose that
lname, dob constitues the unique identifer for PERSON...The system
internally (invisible) and logically decomposes PERSON as PERSON_PRIME
with lname,dob and implements unicity on lname and dob only then it
declare PERSON_SECOND with a reference to PERSON_PRIME and consider
lname, dob as a type of its own. ON a designer perspective, the
system still allows to manipulate PERSON as a relation only that it
internally considers it as a view. In such example, redudancy is
impossible and missing data is dealt way internally by the system.
I do not see then how that could lead anyone to the conclusion that
there may be some kind of un-ary relation prerequisite of any kind.
Subtyping is a process by which one can easily implement a reference
without having to go through the hassle of per-attribute analysis.
The methods decomposition and subtyping have been clarified over and
over by Hugh Darwen in thirdmaifesto.com even though he did it for
the purpose of clarifying correct ways of hadling missing information.
Hope this clarifies...
#89
| |||
| |||
|
|
"Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:fee28a96-a126-4b79-8681-eb6a53b1320b (AT) p69g2000hsa (DOT) googlegroups.com... On 8 fév, 20:39, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:bd675683-86ad-40a5-9985-a810cef1d2bc (AT) y5g2000hsf (DOT) googlegroups.com... On Feb 8, 3:56 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "Cimode" <cim... (AT) hotmail (DOT) com> wrote in message news:aea0bb14-be40-4f56-aada-7edbd4501fd7 (AT) e23g2000prf (DOT) 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. 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}. 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. Noted. I just have not mentionned that I was forcing use of un-ary keys...The example provided of associative entity certainly is not an un-ary key. 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? (My newsreader is not quoting correctly again. Sorry about this.) What are these issues. Providing an example I can attempt bringing an anwser to may help. As I mentionned, dupplicates are systematically rejected. They are inherently impossible. as a part of the logical model for the system. The problems with object identifiers have been discussed here time and time again. I don't think a recap would serve any purpose. The problems with nested relations are due to having the same information recorded in the database several times, possibly in several relations. This does not necessarily mean that there are duplicates, as there can be in a SQL table.. A relation that is in 1NF but not in 2NF exhibits redundancy due to the fact that there is unrelated information represented in a relation. A relation that is in 2NF but not in 3NF exhibits redundancy because there is information that depends on a set of attributes that is not a key, and therefore there is redundancy whenever more than one instance of that set of attributes appears. Similarly, when relations are nested, and a value that appears both several tiers down one path of the hierarchy and a few tiers down another, and that value is composed of several other values (subtrees, if you will), the fact that that value appears several places can cause problems, the most obvious being the need to update the value in several places whenever the individual it represents changes or whenever any of the components of that individual lower in the heirarchy changes. |
how you can come up to te conclusion that I am using object
identifiers as unique identifier based on the posted examples. Let me
describe the process by which the system allows t identify tuples.
Once a specific candidate key is identified by designer as a valid
identifier, the system *internally* decomposes the relation into 2
relations as a single relation on which the candidate key is stored
and a 2nd relation that implements a 1:0 cardinality to the first
relation. I have never mentionned that the first relation to have an
un-ary unique identifier. Here is an example:
suppose we have a PERSON relation : fname, lname, dob...suppose that
lname, dob constitues the unique identifer for PERSON...The system
internally (invisible) and logically decomposes PERSON as PERSON_PRIME
with lname,dob and implements unicity on lname and dob only then it
declare PERSON_SECOND with a reference to PERSON_PRIME and consider
lname, dob as a type of its own. ON a designer perspective, the
system still allows to manipulate PERSON as a relation only that it
internally considers it as a view. In such example, redudancy is
impossible and missing data is dealt way internally by the system.
I do not see then how that could lead anyone to the conclusion that
there may be some kind of un-ary relation prerequisite of any kind.
Subtyping is a process by which one can easily implement a reference
without having to go through the hassle of per-attribute analysis.
The methods decomposition and subtyping have been clarified over and
over by Hugh Darwen in thirdmaifesto.com even though he did it for
the purpose of clarifying correct ways of hadling missing information.
Hope this clarifies...
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.