 | |
#41
 
| |||
| |||
|
Re: A different definition of MINUS, part 4 -
12-28-2008
, 10:37 AM
|
Brian Selzer wrote: "paul c" <toledobythesea (AT) oohay (DOT) ac> wrote in message news:Zma5l.8523$fc3.1985 (AT) newsfe02 (DOT) iad... Parts one, two and three have various mis-steps and confusions. Let me start again emphasizing what I think was McGoveran's paramount point - the desire for logical data independence. I interpret the meaning of this in an algebra to be that substituting some non-logical aspect of an implementation for another will not require any logical aspects to be removed, ie., any true statements to be falsified. Base and virtual relvars are non-logical aspects in that there is no notion of them in the algebra or calculus. In Codd's logic, ie. his algebra and calculus, they are no different than colours, for example it does not matter in the D&D A-algebra whether a relation is 'red' or 'green'. This does not mean that an implementation cannot be logical, only that if its results are to be validated logically, it must define all the concepts involved in those results in logical, eg., algebraic, terms. Can you be more specific in what you mean by logical data independence? ... Beyond my interpretation (which you quote above!), I could say that I think I can say the algebraic significance is: Logical independence means that multiple algebraic expressions that are algebraically equal signify the same extension. I'm not sure that this is anything really different from saying that we want logical consistency to be demonstrable in a dbms implementation. Part of my point is that I suspect Date, as far as I've read, has not started by asking what logical consistency requires of a relvar assignment result. I'm guessing this is part of McGoveran's point too. I understood it to be a property of equivalent database schemes--characterized with respect to the Relational Model by the ability to house exactly the same information using differing sets of relations. ... One might presume that two schemes that are equivalent are in a way "independent" if two monkeys defined them (but they might not be equivalent for long). Logically (algebraically in my preference) if one wants them to be equivalent, one must use a formal logic to state that. This is not the same as some human viewer of the two db's merely understanding or stating that they are equivalent. The difference is in whether one wants the machine to make the guaranntee, in which case we humans must agree on a machine definition of equivalence. The concept is orthogonal to whether relations are virtual or not. ... Hardly. For starters, D&D don't talk of virtual relations. They distinguish relvars (variables) this way which is their means of deciding what variables need to change in an imperative language that implements their 'update' notion. Their 'assignment' goes hand in hand with that. From a pure (logical) model point of view, what is happening is they are permitting certain relations (values) to replace others, then implying that algebraic relation symbol names that are operands of some expression, say a join expression, can be substituted for relvar names. Effectively, they have involved our interpretation of algebraic symbols in the implementation notion of 'updating' (and vice versa) which removes any orthogonality one might have pre-conceived. If D&D had chosen to distinguish such relvars by calling them green instead of base, that involvement would still lurk for us to deal with. What is important is that being able to transform the set of relations that conforms to one database scheme into the set of relations that conforms to another database scheme is a prerequisite for the schemes to be equivalent. What that means is that for a view to be uncontingently updatable, there has to be an equivalent database scheme in which the heading of a base relation matches the heading of the view. For example, suppose you have two database schemes scheme 1: EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY{EMPID} |
scheme 1:
EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY {EMPID}
EMP1 = EMPLOYEE[EMPID, LAST, FIRST, MIDDLE]
EMP2 = EMPLOYEE[EMPID, SSAN]
Quote:
|
scheme 2: EMP1 {EMPID, LAST, FIRST, MIDDLE} KEY{EMPID} and EMP2 {EMPID, SSAN} KEY{EMPID} such that EMP1[EMPID] = EMP2[EMPID] EMPLOYEE = EMP1 JOIN EMP2 Here the circular inclusion dependency guarantees that any update through the EMPLOYEE view can be transformed into a legal set of updates against EMP1 and EMP2. I don't see how anything short of schema equivalence could be permitted--for instance, relaxing the circular inclusion dependency--without changing the information content of the database. I don't argue with that (assuming '=' here means equal, not assignment). If this is meant to be a counter-example, I don't know what it is a counter-example of. 'Schema equivalence', depending on how it is defined, might be a result of what I'm arguing, but my purpose is making sure logical consistency prevails, so I don't (yet) need to talk about that. So far, I've not found it necessary to involve circular dependences, for example. |
equations. In scheme 2 above, we have our base relation declaration(s)
and two equations: one constraint equation and one view equation.
I agree logical independence demands we be able to use either scheme
equally without having any concern for which sheme we actually have.
#42
| |||
| |||
|
|
Brian Selzer wrote: "paul c" <toledobythesea (AT) oohay (DOT) ac> wrote in message news:Zma5l.8523$fc3.1985 (AT) newsfe02 (DOT) iad... Parts one, two and three have various mis-steps and confusions. Let me start again emphasizing what I think was McGoveran's paramount point - the desire for logical data independence. I interpret the meaning of this in an algebra to be that substituting some non-logical aspect of an implementation for another will not require any logical aspects to be removed, ie., any true statements to be falsified. Base and virtual relvars are non-logical aspects in that there is no notion of them in the algebra or calculus. In Codd's logic, ie. his algebra and calculus, they are no different than colours, for example it does not matter in the D&D A-algebra whether a relation is 'red' or 'green'. This does not mean that an implementation cannot be logical, only that if its results are to be validated logically, it must define all the concepts involved in those results in logical, eg., algebraic, terms. Can you be more specific in what you mean by logical data independence? ... Beyond my interpretation (which you quote above!), I could say that I think I can say the algebraic significance is: Logical independence means that multiple algebraic expressions that are algebraically equal signify the same extension. I'm not sure that this is anything really different from saying that we want logical consistency to be demonstrable in a dbms implementation. Part of my point is that I suspect Date, as far as I've read, has not started by asking what logical consistency requires of a relvar assignment result. I'm guessing this is part of McGoveran's point too. I understood it to be a property of equivalent database schemes--characterized with respect to the Relational Model by the ability to house exactly the same information using differing sets of relations. ... One might presume that two schemes that are equivalent are in a way "independent" if two monkeys defined them (but they might not be equivalent for long). Logically (algebraically in my preference) if one wants them to be equivalent, one must use a formal logic to state that. This is not the same as some human viewer of the two db's merely understanding or stating that they are equivalent. The difference is in whether one wants the machine to make the guaranntee, in which case we humans must agree on a machine definition of equivalence. The concept is orthogonal to whether relations are virtual or not. ... Hardly. For starters, D&D don't talk of virtual relations. They distinguish relvars (variables) this way which is their means of deciding what variables need to change in an imperative language that implements their 'update' notion. Their 'assignment' goes hand in hand with that. From a pure (logical) model point of view, what is happening is they are permitting certain relations (values) to replace others, then implying that algebraic relation symbol names that are operands of some expression, say a join expression, can be substituted for relvar names. Effectively, they have involved our interpretation of algebraic symbols in the implementation notion of 'updating' (and vice versa) which removes any orthogonality one might have pre-conceived. If D&D had chosen to distinguish such relvars by calling them green instead of base, that involvement would still lurk for us to deal with. What is important is that being able to transform the set of relations that conforms to one database scheme into the set of relations that conforms to another database scheme is a prerequisite for the schemes to be equivalent. What that means is that for a view to be uncontingently updatable, there has to be an equivalent database scheme in which the heading of a base relation matches the heading of the view. For example, suppose you have two database schemes scheme 1: EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY{EMPID} |
scheme 1:
EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY {EMPID}
EMP1 = EMPLOYEE[EMPID, LAST, FIRST, MIDDLE]
EMP2 = EMPLOYEE[EMPID, SSAN]
Quote:
|
scheme 2: EMP1 {EMPID, LAST, FIRST, MIDDLE} KEY{EMPID} and EMP2 {EMPID, SSAN} KEY{EMPID} such that EMP1[EMPID] = EMP2[EMPID] EMPLOYEE = EMP1 JOIN EMP2 Here the circular inclusion dependency guarantees that any update through the EMPLOYEE view can be transformed into a legal set of updates against EMP1 and EMP2. I don't see how anything short of schema equivalence could be permitted--for instance, relaxing the circular inclusion dependency--without changing the information content of the database. I don't argue with that (assuming '=' here means equal, not assignment). If this is meant to be a counter-example, I don't know what it is a counter-example of. 'Schema equivalence', depending on how it is defined, might be a result of what I'm arguing, but my purpose is making sure logical consistency prevails, so I don't (yet) need to talk about that. So far, I've not found it necessary to involve circular dependences, for example. |
equations. In scheme 2 above, we have our base relation declaration(s)
and two equations: one constraint equation and one view equation.
I agree logical independence demands we be able to use either scheme
equally without having any concern for which sheme we actually have.
#43
| |||
| |||
|
|
Brian Selzer wrote: "paul c" <toledobythesea (AT) oohay (DOT) ac> wrote in message news:Zma5l.8523$fc3.1985 (AT) newsfe02 (DOT) iad... Parts one, two and three have various mis-steps and confusions. Let me start again emphasizing what I think was McGoveran's paramount point - the desire for logical data independence. I interpret the meaning of this in an algebra to be that substituting some non-logical aspect of an implementation for another will not require any logical aspects to be removed, ie., any true statements to be falsified. Base and virtual relvars are non-logical aspects in that there is no notion of them in the algebra or calculus. In Codd's logic, ie. his algebra and calculus, they are no different than colours, for example it does not matter in the D&D A-algebra whether a relation is 'red' or 'green'. This does not mean that an implementation cannot be logical, only that if its results are to be validated logically, it must define all the concepts involved in those results in logical, eg., algebraic, terms. Can you be more specific in what you mean by logical data independence? ... Beyond my interpretation (which you quote above!), I could say that I think I can say the algebraic significance is: Logical independence means that multiple algebraic expressions that are algebraically equal signify the same extension. I'm not sure that this is anything really different from saying that we want logical consistency to be demonstrable in a dbms implementation. Part of my point is that I suspect Date, as far as I've read, has not started by asking what logical consistency requires of a relvar assignment result. I'm guessing this is part of McGoveran's point too. I understood it to be a property of equivalent database schemes--characterized with respect to the Relational Model by the ability to house exactly the same information using differing sets of relations. ... One might presume that two schemes that are equivalent are in a way "independent" if two monkeys defined them (but they might not be equivalent for long). Logically (algebraically in my preference) if one wants them to be equivalent, one must use a formal logic to state that. This is not the same as some human viewer of the two db's merely understanding or stating that they are equivalent. The difference is in whether one wants the machine to make the guaranntee, in which case we humans must agree on a machine definition of equivalence. The concept is orthogonal to whether relations are virtual or not. ... Hardly. For starters, D&D don't talk of virtual relations. They distinguish relvars (variables) this way which is their means of deciding what variables need to change in an imperative language that implements their 'update' notion. Their 'assignment' goes hand in hand with that. From a pure (logical) model point of view, what is happening is they are permitting certain relations (values) to replace others, then implying that algebraic relation symbol names that are operands of some expression, say a join expression, can be substituted for relvar names. Effectively, they have involved our interpretation of algebraic symbols in the implementation notion of 'updating' (and vice versa) which removes any orthogonality one might have pre-conceived. If D&D had chosen to distinguish such relvars by calling them green instead of base, that involvement would still lurk for us to deal with. What is important is that being able to transform the set of relations that conforms to one database scheme into the set of relations that conforms to another database scheme is a prerequisite for the schemes to be equivalent. What that means is that for a view to be uncontingently updatable, there has to be an equivalent database scheme in which the heading of a base relation matches the heading of the view. For example, suppose you have two database schemes scheme 1: EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY{EMPID} |
scheme 1:
EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY {EMPID}
EMP1 = EMPLOYEE[EMPID, LAST, FIRST, MIDDLE]
EMP2 = EMPLOYEE[EMPID, SSAN]
Quote:
|
scheme 2: EMP1 {EMPID, LAST, FIRST, MIDDLE} KEY{EMPID} and EMP2 {EMPID, SSAN} KEY{EMPID} such that EMP1[EMPID] = EMP2[EMPID] EMPLOYEE = EMP1 JOIN EMP2 Here the circular inclusion dependency guarantees that any update through the EMPLOYEE view can be transformed into a legal set of updates against EMP1 and EMP2. I don't see how anything short of schema equivalence could be permitted--for instance, relaxing the circular inclusion dependency--without changing the information content of the database. I don't argue with that (assuming '=' here means equal, not assignment). If this is meant to be a counter-example, I don't know what it is a counter-example of. 'Schema equivalence', depending on how it is defined, might be a result of what I'm arguing, but my purpose is making sure logical consistency prevails, so I don't (yet) need to talk about that. So far, I've not found it necessary to involve circular dependences, for example. |
equations. In scheme 2 above, we have our base relation declaration(s)
and two equations: one constraint equation and one view equation.
I agree logical independence demands we be able to use either scheme
equally without having any concern for which sheme we actually have.
#44
| |||
| |||
|
|
Brian Selzer wrote: "paul c" <toledobythesea (AT) oohay (DOT) ac> wrote in message news:Zma5l.8523$fc3.1985 (AT) newsfe02 (DOT) iad... Parts one, two and three have various mis-steps and confusions. Let me start again emphasizing what I think was McGoveran's paramount point - the desire for logical data independence. I interpret the meaning of this in an algebra to be that substituting some non-logical aspect of an implementation for another will not require any logical aspects to be removed, ie., any true statements to be falsified. Base and virtual relvars are non-logical aspects in that there is no notion of them in the algebra or calculus. In Codd's logic, ie. his algebra and calculus, they are no different than colours, for example it does not matter in the D&D A-algebra whether a relation is 'red' or 'green'. This does not mean that an implementation cannot be logical, only that if its results are to be validated logically, it must define all the concepts involved in those results in logical, eg., algebraic, terms. Can you be more specific in what you mean by logical data independence? ... Beyond my interpretation (which you quote above!), I could say that I think I can say the algebraic significance is: Logical independence means that multiple algebraic expressions that are algebraically equal signify the same extension. I'm not sure that this is anything really different from saying that we want logical consistency to be demonstrable in a dbms implementation. Part of my point is that I suspect Date, as far as I've read, has not started by asking what logical consistency requires of a relvar assignment result. I'm guessing this is part of McGoveran's point too. I understood it to be a property of equivalent database schemes--characterized with respect to the Relational Model by the ability to house exactly the same information using differing sets of relations. ... One might presume that two schemes that are equivalent are in a way "independent" if two monkeys defined them (but they might not be equivalent for long). Logically (algebraically in my preference) if one wants them to be equivalent, one must use a formal logic to state that. This is not the same as some human viewer of the two db's merely understanding or stating that they are equivalent. The difference is in whether one wants the machine to make the guaranntee, in which case we humans must agree on a machine definition of equivalence. The concept is orthogonal to whether relations are virtual or not. ... Hardly. For starters, D&D don't talk of virtual relations. They distinguish relvars (variables) this way which is their means of deciding what variables need to change in an imperative language that implements their 'update' notion. Their 'assignment' goes hand in hand with that. From a pure (logical) model point of view, what is happening is they are permitting certain relations (values) to replace others, then implying that algebraic relation symbol names that are operands of some expression, say a join expression, can be substituted for relvar names. Effectively, they have involved our interpretation of algebraic symbols in the implementation notion of 'updating' (and vice versa) which removes any orthogonality one might have pre-conceived. If D&D had chosen to distinguish such relvars by calling them green instead of base, that involvement would still lurk for us to deal with. What is important is that being able to transform the set of relations that conforms to one database scheme into the set of relations that conforms to another database scheme is a prerequisite for the schemes to be equivalent. What that means is that for a view to be uncontingently updatable, there has to be an equivalent database scheme in which the heading of a base relation matches the heading of the view. For example, suppose you have two database schemes scheme 1: EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY{EMPID} |
scheme 1:
EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY {EMPID}
EMP1 = EMPLOYEE[EMPID, LAST, FIRST, MIDDLE]
EMP2 = EMPLOYEE[EMPID, SSAN]
Quote:
|
scheme 2: EMP1 {EMPID, LAST, FIRST, MIDDLE} KEY{EMPID} and EMP2 {EMPID, SSAN} KEY{EMPID} such that EMP1[EMPID] = EMP2[EMPID] EMPLOYEE = EMP1 JOIN EMP2 Here the circular inclusion dependency guarantees that any update through the EMPLOYEE view can be transformed into a legal set of updates against EMP1 and EMP2. I don't see how anything short of schema equivalence could be permitted--for instance, relaxing the circular inclusion dependency--without changing the information content of the database. I don't argue with that (assuming '=' here means equal, not assignment). If this is meant to be a counter-example, I don't know what it is a counter-example of. 'Schema equivalence', depending on how it is defined, might be a result of what I'm arguing, but my purpose is making sure logical consistency prevails, so I don't (yet) need to talk about that. So far, I've not found it necessary to involve circular dependences, for example. |
equations. In scheme 2 above, we have our base relation declaration(s)
and two equations: one constraint equation and one view equation.
I agree logical independence demands we be able to use either scheme
equally without having any concern for which sheme we actually have.
#45
| |||
| |||
|
|
Brian Selzer wrote: "paul c" <toledobythesea (AT) oohay (DOT) ac> wrote in message news:Zma5l.8523$fc3.1985 (AT) newsfe02 (DOT) iad... Parts one, two and three have various mis-steps and confusions. Let me start again emphasizing what I think was McGoveran's paramount point - the desire for logical data independence. I interpret the meaning of this in an algebra to be that substituting some non-logical aspect of an implementation for another will not require any logical aspects to be removed, ie., any true statements to be falsified. Base and virtual relvars are non-logical aspects in that there is no notion of them in the algebra or calculus. In Codd's logic, ie. his algebra and calculus, they are no different than colours, for example it does not matter in the D&D A-algebra whether a relation is 'red' or 'green'. This does not mean that an implementation cannot be logical, only that if its results are to be validated logically, it must define all the concepts involved in those results in logical, eg., algebraic, terms. Can you be more specific in what you mean by logical data independence? ... Beyond my interpretation (which you quote above!), I could say that I think I can say the algebraic significance is: Logical independence means that multiple algebraic expressions that are algebraically equal signify the same extension. I'm not sure that this is anything really different from saying that we want logical consistency to be demonstrable in a dbms implementation. Part of my point is that I suspect Date, as far as I've read, has not started by asking what logical consistency requires of a relvar assignment result. I'm guessing this is part of McGoveran's point too. I understood it to be a property of equivalent database schemes--characterized with respect to the Relational Model by the ability to house exactly the same information using differing sets of relations. ... One might presume that two schemes that are equivalent are in a way "independent" if two monkeys defined them (but they might not be equivalent for long). Logically (algebraically in my preference) if one wants them to be equivalent, one must use a formal logic to state that. This is not the same as some human viewer of the two db's merely understanding or stating that they are equivalent. The difference is in whether one wants the machine to make the guaranntee, in which case we humans must agree on a machine definition of equivalence. The concept is orthogonal to whether relations are virtual or not. ... Hardly. For starters, D&D don't talk of virtual relations. They distinguish relvars (variables) this way which is their means of deciding what variables need to change in an imperative language that implements their 'update' notion. Their 'assignment' goes hand in hand with that. From a pure (logical) model point of view, what is happening is they are permitting certain relations (values) to replace others, then implying that algebraic relation symbol names that are operands of some expression, say a join expression, can be substituted for relvar names. Effectively, they have involved our interpretation of algebraic symbols in the implementation notion of 'updating' (and vice versa) which removes any orthogonality one might have pre-conceived. If D&D had chosen to distinguish such relvars by calling them green instead of base, that involvement would still lurk for us to deal with. What is important is that being able to transform the set of relations that conforms to one database scheme into the set of relations that conforms to another database scheme is a prerequisite for the schemes to be equivalent. What that means is that for a view to be uncontingently updatable, there has to be an equivalent database scheme in which the heading of a base relation matches the heading of the view. For example, suppose you have two database schemes scheme 1: EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY{EMPID} |
scheme 1:
EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY {EMPID}
EMP1 = EMPLOYEE[EMPID, LAST, FIRST, MIDDLE]
EMP2 = EMPLOYEE[EMPID, SSAN]
Quote:
|
scheme 2: EMP1 {EMPID, LAST, FIRST, MIDDLE} KEY{EMPID} and EMP2 {EMPID, SSAN} KEY{EMPID} such that EMP1[EMPID] = EMP2[EMPID] EMPLOYEE = EMP1 JOIN EMP2 Here the circular inclusion dependency guarantees that any update through the EMPLOYEE view can be transformed into a legal set of updates against EMP1 and EMP2. I don't see how anything short of schema equivalence could be permitted--for instance, relaxing the circular inclusion dependency--without changing the information content of the database. I don't argue with that (assuming '=' here means equal, not assignment). If this is meant to be a counter-example, I don't know what it is a counter-example of. 'Schema equivalence', depending on how it is defined, might be a result of what I'm arguing, but my purpose is making sure logical consistency prevails, so I don't (yet) need to talk about that. So far, I've not found it necessary to involve circular dependences, for example. |
equations. In scheme 2 above, we have our base relation declaration(s)
and two equations: one constraint equation and one view equation.
I agree logical independence demands we be able to use either scheme
equally without having any concern for which sheme we actually have.
#46
| |||
| |||
|
|
Brian Selzer wrote: "paul c" <toledobythesea (AT) oohay (DOT) ac> wrote in message news:Zma5l.8523$fc3.1985 (AT) newsfe02 (DOT) iad... Parts one, two and three have various mis-steps and confusions. Let me start again emphasizing what I think was McGoveran's paramount point - the desire for logical data independence. I interpret the meaning of this in an algebra to be that substituting some non-logical aspect of an implementation for another will not require any logical aspects to be removed, ie., any true statements to be falsified. Base and virtual relvars are non-logical aspects in that there is no notion of them in the algebra or calculus. In Codd's logic, ie. his algebra and calculus, they are no different than colours, for example it does not matter in the D&D A-algebra whether a relation is 'red' or 'green'. This does not mean that an implementation cannot be logical, only that if its results are to be validated logically, it must define all the concepts involved in those results in logical, eg., algebraic, terms. Can you be more specific in what you mean by logical data independence? ... Beyond my interpretation (which you quote above!), I could say that I think I can say the algebraic significance is: Logical independence means that multiple algebraic expressions that are algebraically equal signify the same extension. I'm not sure that this is anything really different from saying that we want logical consistency to be demonstrable in a dbms implementation. Part of my point is that I suspect Date, as far as I've read, has not started by asking what logical consistency requires of a relvar assignment result. I'm guessing this is part of McGoveran's point too. I understood it to be a property of equivalent database schemes--characterized with respect to the Relational Model by the ability to house exactly the same information using differing sets of relations. ... One might presume that two schemes that are equivalent are in a way "independent" if two monkeys defined them (but they might not be equivalent for long). Logically (algebraically in my preference) if one wants them to be equivalent, one must use a formal logic to state that. This is not the same as some human viewer of the two db's merely understanding or stating that they are equivalent. The difference is in whether one wants the machine to make the guaranntee, in which case we humans must agree on a machine definition of equivalence. The concept is orthogonal to whether relations are virtual or not. ... Hardly. For starters, D&D don't talk of virtual relations. They distinguish relvars (variables) this way which is their means of deciding what variables need to change in an imperative language that implements their 'update' notion. Their 'assignment' goes hand in hand with that. From a pure (logical) model point of view, what is happening is they are permitting certain relations (values) to replace others, then implying that algebraic relation symbol names that are operands of some expression, say a join expression, can be substituted for relvar names. Effectively, they have involved our interpretation of algebraic symbols in the implementation notion of 'updating' (and vice versa) which removes any orthogonality one might have pre-conceived. If D&D had chosen to distinguish such relvars by calling them green instead of base, that involvement would still lurk for us to deal with. What is important is that being able to transform the set of relations that conforms to one database scheme into the set of relations that conforms to another database scheme is a prerequisite for the schemes to be equivalent. What that means is that for a view to be uncontingently updatable, there has to be an equivalent database scheme in which the heading of a base relation matches the heading of the view. For example, suppose you have two database schemes scheme 1: EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY{EMPID} |
scheme 1:
EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY {EMPID}
EMP1 = EMPLOYEE[EMPID, LAST, FIRST, MIDDLE]
EMP2 = EMPLOYEE[EMPID, SSAN]
Quote:
|
scheme 2: EMP1 {EMPID, LAST, FIRST, MIDDLE} KEY{EMPID} and EMP2 {EMPID, SSAN} KEY{EMPID} such that EMP1[EMPID] = EMP2[EMPID] EMPLOYEE = EMP1 JOIN EMP2 Here the circular inclusion dependency guarantees that any update through the EMPLOYEE view can be transformed into a legal set of updates against EMP1 and EMP2. I don't see how anything short of schema equivalence could be permitted--for instance, relaxing the circular inclusion dependency--without changing the information content of the database. I don't argue with that (assuming '=' here means equal, not assignment). If this is meant to be a counter-example, I don't know what it is a counter-example of. 'Schema equivalence', depending on how it is defined, might be a result of what I'm arguing, but my purpose is making sure logical consistency prevails, so I don't (yet) need to talk about that. So far, I've not found it necessary to involve circular dependences, for example. |
equations. In scheme 2 above, we have our base relation declaration(s)
and two equations: one constraint equation and one view equation.
I agree logical independence demands we be able to use either scheme
equally without having any concern for which sheme we actually have.
#47
| |||
| |||
|
|
paul c wrote: Brian Selzer wrote: .... equivalent. What that means is that for a view to be uncontingently updatable, there has to be an equivalent database scheme in which the heading of a base relation matches the heading of the view. For example, suppose you have two database schemes scheme 1: EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY{EMPID} Scheme 1 is incomplete. scheme 1: EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY {EMPID} EMP1 = EMPLOYEE[EMPID, LAST, FIRST, MIDDLE] EMP2 = EMPLOYEE[EMPID, SSAN] scheme 2: EMP1 {EMPID, LAST, FIRST, MIDDLE} KEY{EMPID} and EMP2 {EMPID, SSAN} KEY{EMPID} such that EMP1[EMPID] = EMP2[EMPID] EMPLOYEE = EMP1 JOIN EMP2 Here the circular inclusion dependency guarantees that any update through the EMPLOYEE view can be transformed into a legal set of updates against EMP1 and EMP2. I don't see how anything short of schema equivalence could be permitted--for instance, relaxing the circular inclusion dependency--without changing the information content of the database. .... In scheme 1 above, we have our base relation declaration(s) and two view equations. In scheme 2 above, we have our base relation declaration(s) and two equations: one constraint equation and one view equation. I agree logical independence demands we be able to use either scheme equally without having any concern for which sheme we actually have. |
(unless there is some difference between the braces and square brackets that eludes me).
I don't say there is anything 'wrong' here that results from including keys, I would like to know why that is presumably necessary. If that is necessary, does it mean that some other key than EMPID, say {EMPID, SSAN} is somehow wrong or unnecessary?
#48
| |||
| |||
|
|
paul c wrote: Brian Selzer wrote: .... equivalent. What that means is that for a view to be uncontingently updatable, there has to be an equivalent database scheme in which the heading of a base relation matches the heading of the view. For example, suppose you have two database schemes scheme 1: EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY{EMPID} Scheme 1 is incomplete. scheme 1: EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY {EMPID} EMP1 = EMPLOYEE[EMPID, LAST, FIRST, MIDDLE] EMP2 = EMPLOYEE[EMPID, SSAN] scheme 2: EMP1 {EMPID, LAST, FIRST, MIDDLE} KEY{EMPID} and EMP2 {EMPID, SSAN} KEY{EMPID} such that EMP1[EMPID] = EMP2[EMPID] EMPLOYEE = EMP1 JOIN EMP2 Here the circular inclusion dependency guarantees that any update through the EMPLOYEE view can be transformed into a legal set of updates against EMP1 and EMP2. I don't see how anything short of schema equivalence could be permitted--for instance, relaxing the circular inclusion dependency--without changing the information content of the database. .... In scheme 1 above, we have our base relation declaration(s) and two view equations. In scheme 2 above, we have our base relation declaration(s) and two equations: one constraint equation and one view equation. I agree logical independence demands we be able to use either scheme equally without having any concern for which sheme we actually have. |
(unless there is some difference between the braces and square brackets that eludes me).
I don't say there is anything 'wrong' here that results from including keys, I would like to know why that is presumably necessary. If that is necessary, does it mean that some other key than EMPID, say {EMPID, SSAN} is somehow wrong or unnecessary?
#49
| |||
| |||
|
|
paul c wrote: Brian Selzer wrote: .... equivalent. What that means is that for a view to be uncontingently updatable, there has to be an equivalent database scheme in which the heading of a base relation matches the heading of the view. For example, suppose you have two database schemes scheme 1: EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY{EMPID} Scheme 1 is incomplete. scheme 1: EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY {EMPID} EMP1 = EMPLOYEE[EMPID, LAST, FIRST, MIDDLE] EMP2 = EMPLOYEE[EMPID, SSAN] scheme 2: EMP1 {EMPID, LAST, FIRST, MIDDLE} KEY{EMPID} and EMP2 {EMPID, SSAN} KEY{EMPID} such that EMP1[EMPID] = EMP2[EMPID] EMPLOYEE = EMP1 JOIN EMP2 Here the circular inclusion dependency guarantees that any update through the EMPLOYEE view can be transformed into a legal set of updates against EMP1 and EMP2. I don't see how anything short of schema equivalence could be permitted--for instance, relaxing the circular inclusion dependency--without changing the information content of the database. .... In scheme 1 above, we have our base relation declaration(s) and two view equations. In scheme 2 above, we have our base relation declaration(s) and two equations: one constraint equation and one view equation. I agree logical independence demands we be able to use either scheme equally without having any concern for which sheme we actually have. |
(unless there is some difference between the braces and square brackets that eludes me).
I don't say there is anything 'wrong' here that results from including keys, I would like to know why that is presumably necessary. If that is necessary, does it mean that some other key than EMPID, say {EMPID, SSAN} is somehow wrong or unnecessary?
#50
| |||
| |||
|
|
paul c wrote: Brian Selzer wrote: .... equivalent. What that means is that for a view to be uncontingently updatable, there has to be an equivalent database scheme in which the heading of a base relation matches the heading of the view. For example, suppose you have two database schemes scheme 1: EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY{EMPID} Scheme 1 is incomplete. scheme 1: EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY {EMPID} EMP1 = EMPLOYEE[EMPID, LAST, FIRST, MIDDLE] EMP2 = EMPLOYEE[EMPID, SSAN] scheme 2: EMP1 {EMPID, LAST, FIRST, MIDDLE} KEY{EMPID} and EMP2 {EMPID, SSAN} KEY{EMPID} such that EMP1[EMPID] = EMP2[EMPID] EMPLOYEE = EMP1 JOIN EMP2 Here the circular inclusion dependency guarantees that any update through the EMPLOYEE view can be transformed into a legal set of updates against EMP1 and EMP2. I don't see how anything short of schema equivalence could be permitted--for instance, relaxing the circular inclusion dependency--without changing the information content of the database. .... In scheme 1 above, we have our base relation declaration(s) and two view equations. In scheme 2 above, we have our base relation declaration(s) and two equations: one constraint equation and one view equation. I agree logical independence demands we be able to use either scheme equally without having any concern for which sheme we actually have. |
(unless there is some difference between the braces and square brackets that eludes me).
I don't say there is anything 'wrong' here that results from including keys, I would like to know why that is presumably necessary. If that is necessary, does it mean that some other key than EMPID, say {EMPID, SSAN} is somehow wrong or unnecessary?
 |
« 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.