Re: ID field as logical address

"none (Reinier Post)" <rp_at_raampje.> wrote in message news:4a2c2344$0$6254$703f8584_at_news.kpn.nl...
> Brian Selzer wrote:
>
>>[...] But in
>>theory, using just the before and after values of the Bins relvar, how can
>>one declare the transition constraint?
>
> You're right that it's impossible without making some further assumption,
> Designing your database schema to have immutable keys is clearly
> preferable but I agree with you that in some situations this isn't
> possible. Changing the situation to allow it would still be a good idea,
> as I think your bins example clearly shows: it's a design begging
> for trouble.

I don't see how it begs for trouble. The system works: pickers can rapidly find the bins where inventory is to be or is stored, and that information is easily and reliably maintained by the system. Trouble only rears up as a direct consequence of adopting Date and Darwen's databases-as-collections-of-relvars paradigm under which deletes, updates and inserts are shortcuts for relational assignments.

> The alternative you suggest, if I understand you correctly, is to
> impose a strict policy of use for update, insert and delete statements,
> in which an update to a primary key value must always mean that the
> identification of the entity is being changed, while a sequence of
> deletions and insertions never changes this identification.

I'm not sure that you do understand me correctly. The alternative is not to impose policy, but rather to treat deletes, updates and inserts as primitive operations instead of relational assignments. A transition is a set of deletes, updates and inserts that together assert what in the Universe is different and exactly how. A delete targets a set of tuples and asserts that the thing in the Universe that each targeted tuple maps to no longer exists. An update targets a set of tuples and asserts that the thing in the Universe that each targeted tuple maps to has changed in appearance. An insert does not target any tuples in the database, but instead asserts that some things in the Universe have come into existence.

> I think this does resolve the issue, not that of formulating transition
> constraints in general, but the more specific problem of formulating
> transition constraints in terms of entity names ("supplier", "bin")
> that map one-to-one, but not immutably, to the tuples of a relation.
>

I think it does both. The way I see it, a transition can be represented as a set of relations, three for each relation schema in a database schema. One for "deleted" tuples; one for "updated" tuples; and one for "inserted" tuples. For example, suppose that the database schema consists of the following relation schemata

R {A, B, C} and S {A, D},

then the database is comprised of an instance of each of these schemata, r and s;

a transition can then be represented by an instance of each of the following relation schemata,

R- {A, B, C}, R~ {A, B, C, A', B', C'}, R+ {A', B', C'}, S- {A, D}, S~ {A, D, A', D'}, S+ {A', D'},

r-, r~, r+, s-, s~, s+;

and the result of applying the transition to the database can be represented as instances of the following schemata,

R' {A, B, C} and S' {A, D},

r' and s'.

It should therefore be possible to write constraints in terms of any or all of

r, r-, r~, r+, r', s, s-, s~, s+, s'.

Constraints written in terms of just r' and s' are state constraints; all others are transition constraints.

This provides a means for declarative specification of not only state constraints but also transition constraints--all transition constraints, because every transition can be exactly represented.

> But that doesn't mean it is the only way of addressing this issue.
> A simpler way is to just not use such designs or formulations.
>

Abstinence is the only certain method to prevent pregnancy, but where's the fun in that? Received on Mon Jun 08 2009 - 04:59:18 CEST