Re: A real world example

Brian Selzer wrote:
> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
> news:1155809294.447326.279260_at_m73g2000cwd.googlegroups.com...
>

>>Brian Selzer wrote:
>>
>>>[snip]

[more snip]

> 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.

Stop right there!

On "conceptual model of transactions" we learned of /replacement/ updates and /modification/ updates and some obscure theory of transactions.

Earlier we got /individual/ and /universal/ attributes and some vague requirement that the relational model - or DBMS - keep track of which was which and somehow treat them differently.

Now we see there exist /multiplicity constraints/ and /mutability constraints/ and /entity integrity/ rules and /restrictions against nullable attributes/.

[Such a fertile field, this database theory; so much is unknown!]

Brian, please stop making this stuff up! You say, "I can break it, and that should be addressed somehow." Then you carry on trying to convince us that the database should provide a solution to the problem you face. All along, we've been saying, "If these things are problems, your design is broken."

Relational theory provides all you need to meet the requirements you've described here.

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

Let me ask: is the surrogate immutable? Received on Fri Aug 18 2006 - 05:16:55 CEST