Re: A real world example


"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. 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, 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, 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
    ... 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
    ... use a temporal attribute to make the tuples in the database instance ... I was referring to why tuples between relation-values cannot correspond ... 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: 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)
  • Re: Database design, Keys and some other things
    ... In a typical personnel system, new employee ids are assigned by the HR department, and they are responsible, ultimately, for avoiding duplicate assignments. ... Exposing system owned data to users should be done only when necessary: error codes/messages, ... This excludes any data that might be used exclusively by the database. ... The database should have no other "hestitation" in providing any collected data or metadata within the constraints of security. ...
    (comp.databases.theory)