We claim that delete anomality is due to table not being i..

On Sun, 26 Oct 2008 13:51:08 -0700 (PDT), wrote:

(snip)
>1) Third Normal Form prohibits transitive dependencies ( non_key
>attribute CLASSROOM is dependent on other non key attribute
>TEACHER_NAME). One of the arguments why we should put a table in 3NF
>form is because of delete anomalies, which for SUBJECT_TEACHER table
>means, that if we remove certain subject from the table, then all of
>the data about certain teacher could also be lost ( in cases where
>teacher teaches just one subject ).
>
>
>SUBJECT_TEACHER( SUBJECT_ID, SUB_NAME, TEACHER_NAME, CLASSROOM )
>
>
>
>But same argument could be used for the following table:
>
>SUBJECT_TEACHER( SUBJECT_ID, SUB_NAME, TEACHER_NAME )
>
>But this time we don’t have any non-key attribute in a table dependent
>on some other non-key attribute, and as such SUBJECT_TEACHER is in
>3NF. But despite table being in 3NF, all of data ( name of the
>teacher ) about certain teacher could still be lost.

Hi Srubys,

Uhm, no. Normalising shouldnot be done by simply removing attributes,
but by moving them to seperate tables. So when you removed CLASSROOM
from the SUBJECT_TEACHER table, you should at the same time have
introduced a new table for the CLASSROOM and the attrribute it depends
upon, TEACH_NAME:

TEACHER (TEACHER_NAME, CLASSROOM)

Now, if the last subject a teacher teaches is removed, the existence of
the teacher and the classroom assigned to her are still known in the
database.

(snip)
>2) Say we have a relation with attributes A, B and C, where A is also
>a primary key. I know that transitive dependency means that a non-key
>attribute ( say C ) is dependent on other non key attribute ( B ) .
>
>* I also assume that with transitive dependency C is also ALWAYS
>dependent on A?!

Yes. If any value of A relates to only one value of B, and any value of
B relates to only one value of C, then it follows automatically that any
value of A relates to only one value of C. Which is the definition of
functional dependency.

>* But is C always dependent on A simply because B is dependent on A or…
>I mean, B will be dependent on A regardless of whether we have C
>attribute, but I assume that is not the case with C?

I'm afraid I don't understand the question. Could you give an example?

Best, Hugo
 >> Stay informed about: We claim that delete anomality is due to table not being i.. 

greetings

Sorry for not replying sooner

> > But is C always dependent on A simply because B is dependent on A or…
> > I mean, B will be dependent on A regardless of whether we have C
> > attribute, but I assume that is not the case with C?
> I'm afraid I don't understand the question. Could you give an example?

I can’t think of any examples and I’m also not quite sure how to ask
differently, but I’ll try. In most transitive dependencies C is
dependent on A simply because B is dependent on A. Meaning if we
removed B from the relation then C would no longer be dependent on A.

But can there be transitive dependencies where C would still be
dependent on A even if we removed B from the relation ( BTW - I
realize that if we removed B from the relation that we wouldn’t have
transitive dependency anymore)?





> Delete anomalies can surface in more than one normal form. I haven't
> thought about the sepcific case you raise. It seems like a different kind
> of delete anomaly. In one case, the data that's lost is a relationship
> (e.g. Jane Smith always teaches in classroom 13).

But existence is also lost here.

> In the other case, it's an existence (e.g. There is a teacher named Jane
> smith). Existence assertions based on non key values in tables eventually
> result in a separate table to assert the existence, like
> TEACHERS(TEACHER). But I forget how that relates to normal forms.

So lost of existence anomaly may still exist in 3NF?

> > 1) Third Normal Form prohibits transitive dependencies ( non_key
> > attribute CLASSROOM is dependent on other non key attribute
> > TEACHER_NAME). One of the arguments why we should put a table in 3NF
> > form is because of delete anomalies, which for SUBJECT_TEACHER table
> > means, that if we remove certain subject from the table, then all of
> > the data about certain teacher could also be lost ( in cases where
> > teacher teaches just one subject ).
>> SUBJECT_TEACHER( SUBJECT_ID, SUB_NAME, TEACHER_NAME, >>CLASSROOM )
> > But same argument could be used for the following table:
> > SUBJECT_TEACHER( SUBJECT_ID, SUB_NAME, TEACHER_NAME )
> > But this time we don’t have any non-key attribute in a table dependent
> > on some other non-key attribute, and as such SUBJECT_TEACHER is in
> > 3NF. But despite table being in 3NF, all of data ( name of the
> > teacher ) about certain teacher could still be lost.
> Uhm, no. Normalising shouldnot be done by simply removing attributes,
> but by moving them to seperate tables. So when you removed CLASSROOM
> from the SUBJECT_TEACHER table, you should at the same time have
> introduced a new table for the CLASSROOM and the attribute it depends
> upon, TEACH_NAME:
> TEACHER (TEACHER_NAME, CLASSROOM)
> Now, if the last subject a teacher teaches is removed, the existence of
> the teacher and the classroom assigned to her are still known in the
> database.

I’m not sure, but I think you’ve missed the point of my question.


Table SUBJECT_TEACHER( SUBJECT_ID, SUB_NAME, TEACHER_NAME )
is not the result of me normalizing the following table:

SUBJECT_TEACHER( SUBJECT_ID, SUB_NAME, TEACHER_NAME, CLASSROOM )

Thus the two relations above are two separate, non related tables. I
was just pointing out that my book used the argument that if we don’t
put a relation into 3NF, then due to delete anomalies ( which are the
result of transitive dependencies ) the information about certain
teacher could be lost ( if certain row gets deleted). But I argued
that book’s argument is weak ( in a sense that book gave the
impression that once you have any table in 3NF, then the kind of
delete anomaly described above won’t happen, but I argued that with
some tables that particular delete anomaly could still happen ) since
information about a teacher could be lost even if table is in 3NF ( to
get my point across I used a bit different relation, one that never
had CLASSROOM attribute ). Thus, even though table is in 3NF, we might
still have same kind of delete anomalies. Namely, if all we want to
know about a certain teacher is her name, then we might be OK with the
following table, which is also in 3NF:
SUBJECT_TEACHER( SUBJECT_ID, SUB_NAME, TEACHER_NAME )

But this time, if teacher teaches just one class, and if remove that
particular row, then data about that teacher will also get lost,
despite the relation being in 3NF.

thank you
 >> Stay informed about: We claim that delete anomality is due to table not being i.. 

wrote:

> greetings
>
> Sorry for not replying sooner
>
>>> But is C always dependent on A simply because B is dependent on A or…

Please don't delete the attributions. It makes it impossible to figure
out who said what.
 >> Stay informed about: We claim that delete anomality is due to table not being i.. 

wrote:
> 1) Third Normal Form prohibits transitive dependencies ( non_key
> attribute CLASSROOM is dependent on other non key attribute
> TEACHER_NAME). One of the arguments why we should put a table in 3NF
> form is because of delete anomalies, which for SUBJECT_TEACHER table
> means, that if we remove certain subject from the table, then all of
> the data about certain teacher could also be lost ( in cases where
> teacher teaches just one subject ).
>
> SUBJECT_TEACHER( SUBJECT_ID, SUB_NAME, TEACHER_NAME, CLASSROOM )

I think what is causing difficulty is the phrase "the data about certain
X"---it is not immediately clear what that means.

You don't explicitly state the FDs for the above table, but I will
assume { SUBJECT_ID } -> { SUB_NAME, TEACHER_NAME, CLASSROOM } and {
TEACHER_NAME } -> { CLASSROOM }. I agree that this design exhibits
delete anomalies, because we could lose data about teachers (loosely
speaking, as you'll see). But what is "data about teachers", and why? I
posit that "data about teachers" in this context is just CLASSROOM,
because of the FD { TEACHER_NAME } -> { CLASSROOM }.

> But same argument could be used for the following table:
>
> SUBJECT_TEACHER( SUBJECT_ID, SUB_NAME, TEACHER_NAME )

Assuming { SUBJECT_ID } -> { SUB_NAME, TEACHER_NAME }: I would say not,
because here there are no non-trivial FDs with { TEACHER_NAME } on the
left side. In other words, there is no "data about teachers" here.

Of course, there is "data about teachers" in the sense that the table
above indicates what subjects a teacher teaches. But that is not really
relevant for the 3NF/anomalies discussion, which further indicates that
"data about" here means just "attributes determined by" (again loosely
speaking). This is confusing and unfortunate; it's what you often get
when you try to explain formal concepts informally.

> But this time we don’t have any non-key attribute in a table dependent
> on some other non-key attribute, and as such SUBJECT_TEACHER is in
> 3NF. But despite table being in 3NF, all of data ( name of the
> teacher ) about certain teacher could still be lost.

Another cause for confusion is the distinction between an attribute and
what the attribute represents. We talk about "teachers", but the tables
don't mention teachers---only teacher /names/. It is perhaps natural to
regard the TEACHER_NAME attribute in the second table as "data about
teachers"---it is in the real world---but it isn't in this design. It's
just a name. So when you delete a row, it would be more correct
(disregarding grammar) to say that "all of data (name of the teacher)
about certain teacher name could still be lost"---which is trivial and
unproblematic. The table exhibits no more delete anomalies than the
table SUBJECT_TEACHER(SUBJECT_ID, SUB_NAME, TEACHER_ID) does.

> So how can we claim that delete anomality is due to table not being in
> 3NF, when it is obvious this situation ( in our case data about
> certain teacher being lost ) can arise even when table complies to
> third form?

It is not obvious. There is no anomaly.

> 2) Say we have a relation with attributes A, B and C, where A is also
> a primary key. I know that transitive dependency means that a non-key
> attribute ( say C ) is dependent on other non key attribute ( B ) .
>
> * I also assume that with transitive dependency C is also ALWAYS
> dependent on A?!

Since A is a key, by definition all attributes are dependent on A.

> * But is C always dependent on A simply because B is dependent on A or…

The reason for the dependency is found in the real world. If this is
just an abstract example, there are no reasons as such. But maybe I'm
not understanding you correctly.

Consider SUBJECT(SUB_ID, TEACHER_ID, TEACHER_NAME), with { SUBJECT_ID }
-> { TEACHER_ID } and { TEACHER_ID } -> { TEACHER_NAME }, attempting to
model a situation where subjects have only one teacher, and teacher IDs
are unique (speaking loosely). By FD transitivity rule, we can establish
that { SUB_ID } -> { TEACHER_NAME }. This also makes sense in the real
world: If we know the (sole) teacher id of a given subject, and we know
the (sole) teacher name of a given teacher id, then we obviously know
the teacher name given a subject. Does this answer your question?

> I mean, B will be dependent on A regardless of whether we have C
> attribute, but I assume that is not the case with C?

If A is a key, all attributes are dependent on it, regardless of other
attributes and dependencies. You question doesn't make sense.
--
Jon
 >> Stay informed about: We claim that delete anomality is due to table not being i.. 

On Tue, 28 Oct 2008 17:32:49 -0700 (PDT), wrote:

>greetings
>
>Sorry for not replying sooner
>
>> > But is C always dependent on A simply because B is dependent on A or…
>> > I mean, B will be dependent on A regardless of whether we have C
>> > attribute, but I assume that is not the case with C?
>> I'm afraid I don't understand the question. Could you give an example?
>
>I can’t think of any examples and I’m also not quite sure how to ask
>differently, but I’ll try. In most transitive dependencies C is
>dependent on A simply because B is dependent on A. Meaning if we
>removed B from the relation then C would no longer be dependent on A.
>
>But can there be transitive dependencies where C would still be
>dependent on A even if we removed B from the relation ( BTW - I
>realize that if we removed B from the relation that we wouldn’t have
>transitive dependency anymore)?

Hi Srubys,

Functional dependencies stem from reality. Whether or not you choose to
include B in your model does not change the situation where, apparently,
C depends on A through some intermediary B (that is not in the DB).

In a DB that stores PersonID and EyeColour, one might argue that the
actual dependency goes back to the parents of the person and their
genetic patterns - but those will typically not be stored, and yet the
EyeColour still depends on PersonID.

>> Delete anomalies can surface in more than one normal form. I haven't
>> thought about the sepcific case you raise. It seems like a different kind
>> of delete anomaly. In one case, the data that's lost is a relationship
>> (e.g. Jane Smith always teaches in classroom 13).
>
>But existence is also lost here.

Existence was never properly represented. If existence of a teacher is
worth storing in your DB, then you need a table of teachers. Otherwise,
you may be implying existence of a teacher as a side effect of storing
attributes of other entities, but yoy fail to actively and explicitly
store it.

(snipped the rest - I think the above addresses your questions)

Best, Hugo
 >> Stay informed about: We claim that delete anomality is due to table not being i.. 

Greetings

On 29 okt., 09:16, Jon Heggland wrote:
> wrote:
> > 1) Third Normal Form prohibits transitive dependencies ( non_key
> > attribute CLASSROOM is dependent on other non key attribute
> > TEACHER_NAME). One of the arguments why we should put a table in 3NF
> > form is because of delete anomalies, which for SUBJECT_TEACHER table
> > means, that if we remove certain subject from the table, then all of
> > the data about certain teacher could also be lost ( in cases where
> > teacher teaches just one subject ).
>
> > SUBJECT_TEACHER( SUBJECT_ID, SUB_NAME, TEACHER_NAME, CLASSROOM )
>
> I think what is causing difficulty is the phrase "the data about certain
> X"---it is not immediately clear what that means.
>
> You don't explicitly state the FDs for the above table, but I will
> assume { SUBJECT_ID } -> { SUB_NAME, TEACHER_NAME, CLASSROOM } and {
> TEACHER_NAME } -> { CLASSROOM }. I agree that this design exhibits
> delete anomalies, because we could lose data about teachers (loosely
> speaking, as you'll see). But what is "data about teachers", and why? I
> posit that "data about teachers" in this context is just CLASSROOM,
> because of the FD { TEACHER_NAME } -> { CLASSROOM }.
>
> > But same argument could be used for the following table:
>
> > SUBJECT_TEACHER( SUBJECT_ID, SUB_NAME, TEACHER_NAME )
>
> Assuming { SUBJECT_ID } -> { SUB_NAME, TEACHER_NAME }: I would say not,
> because here there are no non-trivial FDs with { TEACHER_NAME } on the
> left side. In other words, there is no "data about teachers" here.
>
> Of course, there is "data about teachers" in the sense that the table
> above indicates what subjects a teacher teaches. But that is not really
> relevant for the 3NF/anomalies discussion, which further indicates that
> "data about" here means just "attributes determined by" (again loosely
> speaking). This is confusing and unfortunate; it's what you often get
> when you try to explain formal concepts informally.
>
> > But this time we don’t have any non-key attribute in a table dependent
> > on some other non-key attribute, and as such SUBJECT_TEACHER is in
> > 3NF. But despite table being in 3NF, all of data ( name of the
> > teacher ) about certain teacher could still be lost.
>
> Another cause for confusion is the distinction between an attribute and
> what the attribute represents. We talk about "teachers", but the tables
> don't mention teachers---only teacher /names/. It is perhaps natural to
> regard the TEACHER_NAME attribute in the second table as "data about
> teachers"---it is in the real world---but it isn't in this design. It's
> just a name. So when you delete a row, it would be more correct
> (disregarding grammar) to say that "all of data (name of the teacher)
> about certain teacher name could still be lost"---which is trivial and
> unproblematic. The table exhibits no more delete anomalies than the
> table SUBJECT_TEACHER(SUBJECT_ID, SUB_NAME, TEACHER_ID) does.
>
> Jon

So in essence, we don't consider just the loss of existence an
anomaly?




On 29 okt., 22:07, Hugo Kornelis
wrote:
> >> Delete anomalies can surface in more than one normal form. I haven't
> >> thought about the sepcific case you raise. It seems like a different kind
> >> of delete anomaly. In one case, the data that's lost is a relationship
> >> (e.g. Jane Smith always teaches in classroom 13).
>
> >But existence is also lost here.
>
> Existence was never properly represented. If existence of a teacher is
> worth storing in your DB, then you need a table of teachers. Otherwise,
> you may be implying existence of a teacher as a side effect of storing
> attributes of other entities, but yoy fail to actively and explicitly
> store it.
>
>
> Best, Hugo

I understand ( to a point ) what you are saying here, but still, even
though the existence is just implied in a relation

SUBJECT_TEACHER( SUBJECT_ID, SUB_NAME, TEACHER_NAME, CLASSROOM )

would it be so wrong to say that due to transitive dependency we have
a delete anomaly, which may cause a lost of relatioship ( thus lost of
data ) and also a loss of existence ( I realize lost of existence is
not considered an anomaly )?


Thank you
 >> Stay informed about: We claim that delete anomality is due to table not being i.. 

Hugo Kornelis wrote:
....
> Functional dependencies stem from reality. Whether or not you choose to
> include B in your model does not change the situation where, apparently,
> C depends on A through some intermediary B (that is not in the DB).
>
> In a DB that stores PersonID and EyeColour, one might argue that the
> actual dependency goes back to the parents of the person and their
> genetic patterns - but those will typically not be stored, and yet the
> EyeColour still depends on PersonID.
> ...


Assuming you're saying it's improper to depend on any notion of absolute
reality, I think I'd agree. Doesn't a db aimed toward aiding some
present function necessarily stand for a very fractional/partial (or
even distorted) reality? Eg., if it's not fractional it's probably
unwieldy and untoward. Seems to me that the EyeColour dependency hints
at this - when the purpose of a particular set of tables isn't concerned
with dna, one likely ignores blood lines. Further, I suspect that no db
ought to introduce fd's that aren't patently implicit in the user's
requirements/biz rules/application intent. In the USA, I gather that an
address that is complete enough for a mailman to deliver to, along with
a city and a state will determine zipcode, yet I suspect there are many
tables in non-postal db's that have a column set such as (Customer,
unit, streetaddress, city, state, zip).
 >> Stay informed about: We claim that delete anomality is due to table not being i.. 

wrote:
> So in essence, we don't consider just the loss of existence an
> anomaly?

I wouldn't (and didn't) put it that way without defining precisely what
I mean by "existence". Are you talking about the existence of a teacher
as such? Or about the existence in the table of some particular name? if
so, why single out the TEACHER_NAME? Why not consider the "loss of
existence" of the SUBJECT_ID or SUB_NAME?

The loss of the last appearance of some TEACHER_NAME value does not
imply that the corresponding teacher does not exist. The table does not
talk about the existence of teachers, only what subjects are taught by
what teachers. You can imply the existence of a teacher from the table,
but not the non-existence, despite the closed-world assumption. Thus, if
a teacher does not teach any subjects, it is perfectly correct (i.e. not
anomalous) that hir name does not appear in the table.
--
Jon
 >> Stay informed about: We claim that delete anomality is due to table not being i.. 

On Wed, 29 Oct 2008 22:59:25 GMT, paul c wrote:

>Hugo Kornelis wrote:
>...
>> Functional dependencies stem from reality. Whether or not you choose to
>> include B in your model does not change the situation where, apparently,
>> C depends on A through some intermediary B (that is not in the DB).
>>
>> In a DB that stores PersonID and EyeColour, one might argue that the
>> actual dependency goes back to the parents of the person and their
>> genetic patterns - but those will typically not be stored, and yet the
>> EyeColour still depends on PersonID.
>> ...
>
>
>Assuming you're saying it's improper to depend on any notion of absolute
>reality, I think I'd agree. Doesn't a db aimed toward aiding some
>present function necessarily stand for a very fractional/partial (or
>even distorted) reality? Eg., if it's not fractional it's probably
>unwieldy and untoward. Seems to me that the EyeColour dependency hints
>at this - when the purpose of a particular set of tables isn't concerned
>with dna, one likely ignores blood lines. Further, I suspect that no db
>ought to introduce fd's that aren't patently implicit in the user's
>requirements/biz rules/application intent. In the USA, I gather that an
>address that is complete enough for a mailman to deliver to, along with
>a city and a state will determine zipcode, yet I suspect there are many
>tables in non-postal db's that have a column set such as (Customer,
>unit, streetaddress, city, state, zip).

Hi Paul,

This is cdt, not alt.philosophy. I was not after an existential
discussion on absolute reality.

You're reading way more into my example than I intended. The point I
tried to make is that functional dependencies are not determined by what
is or is not stored in the database, but by how entities and their
interactions in reality. The DB is a model of reality and changing the
model won't change reality.

I already considered the example pretty bad when I wrote it, and now
that I see what you read into it, I'm really embarassed...

Best, Hugo
 >> Stay informed about: We claim that delete anomality is due to table not being i.. 

On Wed, 29 Oct 2008 18:32:13 -0700 (PDT), wrote:

(snip)
>So in essence, we don't consider just the loss of existence an
>anomaly?

Hi Srubys,

If the model was designed to explicitly store existence, then loss of
existence would be considered an anomaly. If the model doesn't store
existence, then it can't be lost.

Consider this (simplified) model for a savings account:

ACCOUNT (AccountNo, Balance)

If I make a withdrawal taking my balance from $1300.75 to $1200.75, and
at that time no other account happens to have a balance of $1300.75,
would you consider that loss of existence? And would you worry about the
database no longer explicitly representing $1300.75 as a possible
balance?

(snip)
>I understand ( to a point ) what you are saying here, but still, even
>though the existence is just implied in a relation
>
>SUBJECT_TEACHER( SUBJECT_ID, SUB_NAME, TEACHER_NAME, CLASSROOM )
>
>would it be so wrong to say that due to transitive dependency we have
>a delete anomaly, which may cause a lost of relatioship ( thus lost of
>data ) and also a loss of existence ( I realize lost of existence is
>not considered an anomaly )?

You can't lose what you don't store. If you want to persist existence,
you need to add a relation for it in your model. If you don't have such
a relation, then you're obviously not interested in storing existence,
so you shouldn't worry about losing it.

Best, Hugo
 >> Stay informed about: We claim that delete anomality is due to table not being i.. 

Hugo Kornelis wrote:
> On Wed, 29 Oct 2008 22:59:25 GMT, paul c wrote:
>
>> Hugo Kornelis wrote:
>> ...
>>> Functional dependencies stem from reality. Whether or not you choose to
>>> include B in your model does not change the situation where, apparently,
>>> C depends on A through some intermediary B (that is not in the DB).
>>>
>>> In a DB that stores PersonID and EyeColour, one might argue that the
>>> actual dependency goes back to the parents of the person and their
>>> genetic patterns - but those will typically not be stored, and yet the
>>> EyeColour still depends on PersonID.
>>> ...
>>
>> Assuming you're saying it's improper to depend on any notion of absolute
>> reality, I think I'd agree. Doesn't a db aimed toward aiding some
>> present function necessarily stand for a very fractional/partial (or
>> even distorted) reality? Eg., if it's not fractional it's probably
>> unwieldy and untoward. Seems to me that the EyeColour dependency hints
>> at this - when the purpose of a particular set of tables isn't concerned
>> with dna, one likely ignores blood lines. Further, I suspect that no db
>> ought to introduce fd's that aren't patently implicit in the user's
>> requirements/biz rules/application intent. In the USA, I gather that an
>> address that is complete enough for a mailman to deliver to, along with
>> a city and a state will determine zipcode, yet I suspect there are many
>> tables in non-postal db's that have a column set such as (Customer,
>> unit, streetaddress, city, state, zip).
>
> Hi Paul,
>
> This is cdt, not alt.philosophy. I was not after an existential
> discussion on absolute reality.
>
> You're reading way more into my example than I intended. The point I
> tried to make is that functional dependencies are not determined by what
> is or is not stored in the database, but by how entities and their
> interactions in reality. The DB is a model of reality and changing the
> model won't change reality.
>
> I already considered the example pretty bad when I wrote it, and now
> that I see what you read into it, I'm really embarassed...
>
> Best, Hugo


Sorry Hugo, consider it my fault entirely. In order to keep my reason
short, I'll just blame it on the grape. Maybe one day, I'll figure out
a way to put it better than I did.

best,
p
 >> Stay informed about: We claim that delete anomality is due to table not being i.. 

Hugo Kornelis wrote:

> You're reading way more into my example than I intended. The point I
> tried to make is that functional dependencies are not determined by what
> is or is not stored in the database, but by how entities and their
> interactions in reality. The DB is a model of reality and changing the
> model won't change reality.

The DB is NOT a model of reality. It is a model of the testimony users
give about the bit of reality that interests them. And for the purposes
of understanding what the database needs to do, we don't even have to
require that the testimony be correct or even given in good faith.
(Which is just as well because we can't do that.)

So, bottom line, the content of a database is only very indirectly
connected to the real world, and is always suspect.

Furthermore, the only thing we can insist on being able to rely upon is
that the derivations we get from the content of the database are
correct derivations from that content. To be assured of that we need to
model the form of the testimony with proper fidelity. And that is what
decides the appropriate functional dependencies.

It's just math, not metaphysics.

--
Roy
 >> Stay informed about: We claim that delete anomality is due to table not being i.. 

On Oct 30, 11:23 pm, Hugo Kornelis
wrote:
> On Wed, 29 Oct 2008 22:59:25 GMT, paul c wrote:
> >Hugo Kornelis wrote:
> >...
> >> Functional dependencies stem from reality. Whether or not you choose to
> >> include B in your model does not change the situation where, apparently,
> >> C depends on A through some intermediary B (that is not in the DB).
>
> >> In a DB that stores PersonID and EyeColour, one might argue that the
> >> actual dependency goes back to the parents of the person and their
> >> genetic patterns - but those will typically not be stored, and yet the
> >> EyeColour still depends on PersonID.
> >> ...
>
> >Assuming you're saying it's improper to depend on any notion of absolute
> >reality, I think I'd agree.  Doesn't a db aimed toward aiding some
> >present function necessarily stand for a very fractional/partial (or
> >even distorted) reality?  Eg., if it's not fractional it's probably
> >unwieldy and untoward.  Seems to me that the EyeColour dependency hints
> >at this - when the purpose of a particular set of tables isn't concerned
> >with dna, one likely ignores blood lines.  Further, I suspect that no db
> >ought to introduce fd's that aren't patently implicit in the user's
> >requirements/biz rules/application intent.  In the USA, I gather that an
> >address that is complete enough for a mailman to deliver to, along with
> >a city and a state will determine zipcode, yet I suspect there are many
> >tables in non-postal db's that have a column set such as (Customer,
> >unit, streetaddress, city, state, zip).
>
> Hi Paul,
>
> This is cdt, not alt.philosophy. I was not after an existential
> discussion on absolute reality.
>
> You're reading way more into my example than I intended. The point I
> tried to make is that functional dependencies are not determined by what
> is or is not stored in the database, but by how entities and their
> interactions in reality. The DB is a model of reality and changing the
> model won't change reality.

I too would disagree that a DB is a model of reality - it is a model
of data (i.e. comments about the world from some individual
standpoint). That data /already existed/ in the wild, and the DB
simply models it in a form amenable to querying and manipulation. Its
algebra hence deals with statements and not the items they discuss.

>
> I already considered the example pretty bad when I wrote it, and now
> that I see what you read into it, I'm really embarassed...
>
> Best, Hugo
 >> Stay informed about: We claim that delete anomality is due to table not being i..