Re: A real world example


"JOG" <jog@xxxxxxxxxxxxx> wrote in message
news:1155816327.644741.10320@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Brian Selzer wrote:
"JOG" <jog@xxxxxxxxxxxxx> wrote in message
news:1155809294.447326.279260@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Brian Selzer wrote:
[snip]
If you've read the rest of my argument, then I ask you: how can you
possibly
use a temporal attribute to make the tuples in the database instance
preceding a change correspond to tuples in the database instance
succeeding
a change?

I'm running out of ways to explain why this doesn't make sense Brian,
so let me summarize:


I understand why it doesn't make sense.

I was referring to why tuples between relation-values cannot correspond
if they do not have a common key.


And I agree entirely.

That's my entire argument. If
something can have its appearance altered and still be the same thing,
and
if the only way to compare things is by their appearance, then you can't
tell if two sets contain the same things unless you know how each of
their
appearances has changed or unless you know that the appearance of only
one
of them has changed.

* Tuples can /only/ correspond if they have a common key attribute. To
do so otherwise makes no logical sense.


If you know that the tuples in the proposed instance correspond to those
in
the current instance,

You can /only/ know that by comparing a key value that maintains
identity over the lifetime of the item, as specified by your design
choice.


The database can /only/ know that. The originator of the change can know,
however. But again, that pushes the responsibility to enforce constraints
onto the user.

and you know that only one tuple has a different key
value, then the one that doesn't correspond by the key values is the one
that is different.

If you know how to identify tuples in one instance and you know how to
identify tuples in another and if you know how they're supposed to
correspond,

wuh? Now you are referring to a schema change? If not, tuples are
identified the same way across relation values.


No. Not if "you" is the originator of the change.

Perhaps bob was right, I give up. I think your notion of how we record
identity is flawed. Maybe oid's are what you are looking for if that is
the case.

then instead of issuing a single assignment containing all of
the changes, you can issue a series of individual assignments where only
one
tuple is different in each. (e.g., FOR EACH ROW)

Of course, issuing a series of assignments introduces its own problems.
For
example, consider a self-referencing relation. If any of the assignments
changes the only key in a tuple that is referenced by another, then the
database will be inconsistent until the new value for the referencing
tuple
is assigned.

* If there is /no/ attribute value that remains the same, then the
items the propositions refer to have no correspondence. They are
different.


This is true only if by "attributes" you mean the properties of
something,
including those that are not included in the propositions about it. If
you
are referring to "attributes" as the set of attributes included in a
proposition, then "They are different." must become "You can't tell
whether
or not they're the same."

* This isn't a problem because there is /always/ an attribute that will
identify something. If your aim is to model the entity that consists of
an 'item over its lifetime', then it is up to the designer to determine
that key to identify that lifetime.


Then the model should take this into account in its definition. That may
embody changing the definition of a key, or changing its treatment of
attributes in the definition of a relation schema, or both. You can
define
multiplicity constraints, and that is defined in the model. Maybe you
could
define mutability constraints, and include that in the model. Maybe the
entity integrity rule could be changed to include restrictions against
mutable attributes as well as nullable attributes. I don't know. All I
know is that I can break it, and that should be addressed somehow.

* If no natural key is recordable then the designer must use an
artificial surrogate for it (remember the underlying natural attribute
it represents does exist somewhere). That artificial surrogate /must
not/ be hidden as it is an external identifer.


I would have said, "If no natural key is both recordable and immutable
then
the designer must use an artifical surrogate for it."

That's it. Nothing more to it. Can anyone else see any holes in this
logic, or am I losing the plot?




.

Relevant Pages

  • Re: A real world example
    ... use a temporal attribute to make the tuples in the database instance ... preceding a change correspond to tuples in the database instance ... issuing a series of assignments introduces its own problems. ... including those that are not included in the propositions about it. ...
    (comp.databases.theory)
  • Re: A real world example
    ... I was referring to why tuples between relation-values cannot correspond ... if the only way to compare things is by their appearance, ... issuing a series of assignments introduces its own problems. ... including those that are not included in the propositions about it. ...
    (comp.databases.theory)
  • Re: A real world example
    ... Brian believes tuples in seperate relation values should correspond to ... Isn't NULL/NOT NULL a multiplicity constraint? ... different in successive database states, ... surrogate key with inconsistent natural keys. ...
    (comp.databases.theory)
  • Re: What so special about PostgreSQL and other RDBMS?
    ... your alternative propositions are much clearer than the ... >> application and the underlying database management system. ... and using free software is becoming more and more ... > even if this means being dependent upon that platform. ...
    (comp.lang.php)
  • Re: Another view on analysis and ER
    ... Broken database. ... If you're issuing assignments, that is, deletes and inserts, then ... By not using the VIN, ... since there is a 1:1 correspondence between that which is ...
    (comp.databases.theory)