Re: The Practical Benefits of the Relational Model
From: Paul Vernon <paul.vernon_at_ukk.ibmm.comm>
Date: Thu, 29 Aug 2002 18:36:21 +0100
Message-ID: <aklm8g$2jse$1_at_sp15at20.hursley.ibm.com>
sorry about the HTML folks. dratted buggy newsreader.
> Some would say it is the set of static and dynamic constraints
> that should hold for the data in the database.
By dynamic you mean what Date would call transition constraints, yes?
E.g. from http://portal.acm.org/citation.cfm?id=7918&coll=GUIDE&dl=GUIDE
"constraints [that] specify relationships between the database states
before and after an update"
On this subject, don't dynamic constraints just become static constraints
in the case where you keep all history in your database? Besides, that
is, the need to enforce the 'arrow of time' (i.e. can't update the history
tuples). So enforcing the 'arrow of time' becomes the only required
dynamic constraint?
E.g. with table T and attribute A of type INTEGER
and dynamic constraint X: A > A' (where A' is the old value of A)
becomes
with table H and attributes A of type INTEGER and B of type TIMEPOINT
and static constraint Y: H1.A > H2.A FROM H as H1, H as H2 JOIN H1.B
IS_SUBSEQUENT_TO H2.B
with the dynamic constraint B = CURRENT TIMEPOINT at the time of any
Insert or Update
Well I think I understand what I just said even if no-one else does...
Regards
Paul Vernon
Business Intelligence, IBM Global Services
Received on Thu Aug 29 2002 - 19:36:21 CEST
Date: Thu, 29 Aug 2002 18:36:21 +0100
Message-ID: <aklm8g$2jse$1_at_sp15at20.hursley.ibm.com>
sorry about the HTML folks. dratted buggy newsreader.
> Some would say it is the set of static and dynamic constraints
> that should hold for the data in the database.
By dynamic you mean what Date would call transition constraints, yes?
E.g. from http://portal.acm.org/citation.cfm?id=7918&coll=GUIDE&dl=GUIDE
"constraints [that] specify relationships between the database states
before and after an update"
On this subject, don't dynamic constraints just become static constraints
in the case where you keep all history in your database? Besides, that
is, the need to enforce the 'arrow of time' (i.e. can't update the history
tuples). So enforcing the 'arrow of time' becomes the only required
dynamic constraint?
E.g. with table T and attribute A of type INTEGER
and dynamic constraint X: A > A' (where A' is the old value of A)
becomes
with table H and attributes A of type INTEGER and B of type TIMEPOINT
and static constraint Y: H1.A > H2.A FROM H as H1, H as H2 JOIN H1.B
IS_SUBSEQUENT_TO H2.B
with the dynamic constraint B = CURRENT TIMEPOINT at the time of any
Insert or Update
Well I think I understand what I just said even if no-one else does...
Regards
Paul Vernon
Business Intelligence, IBM Global Services
Received on Thu Aug 29 2002 - 19:36:21 CEST