On specialization constraints time of application
Cimode
implemented in the case of relations runtime-only (I call them virtual
- they can *roughly* be assimilated to functions/views)
representations. I thought that it is necessity for a TRDBMS to allow
the implementation of constraints over the domains of attributes that
are part of these relations. As a consequence, the question came out
about the modalities of constraint implementations in declarative
mindset:
> Since a TRDBMS should allow constraint specialization in a declarative way, how could a TRDBMS allow constraint declaration of virtual relations in a way that does not require a representation of the virtual relation in order to validate that its constraints are verified.
> Are virtual relations to be considered a part of the database relation.
> So far, I have by default taken the approach of considering attributes of virtual relations as being subjected to ANY constraint that carries on some attribute that allows these attributes to be built. I wander about the risks and opportunities of such approach and whether some work has been done on that subject.
I would to have the opinion of some people here and any material that
dealt with the specific subject at hand.
Thank you/
Brian Selzer
"Cimode" <cim...@hotmail.com> wrote in message
news:bba2f111-0023-499a...@h11g2000yqb.googlegroups.com...
> Lately, I stumbled about the problem of how constraints are to be
> implemented in the case of relations runtime-only (I call them virtual
> - they can *roughly* be assimilated to functions/views)
> representations. I thought that it is necessity for a TRDBMS to allow
> the implementation of constraints over the domains of attributes that
> are part of these relations. As a consequence, the question came out
> about the modalities of constraint implementations in declarative
> mindset:
>
I'm not sure exactly what you're driving at here. Are you concerned with
implementing constraints defined on relational expressions, such as a unique
constraint defined on a view?
> > Since a TRDBMS should allow constraint specialization in a declarative
> > way, how
> could a TRDBMS allow constraint declaration of virtual relations in a way
> that does
> not require a representation of the virtual relation in order to validate
> that its
> constraints are verified.
Are you seeking a deterministic solution for mapping inserts, updates and
deletes that target a relation derived from a set of base relations to those
base relations? I don't think there is one.
> > Are virtual relations to be considered a part of the database relation.
I don't think so. Despite the good intentions of Date and Darwen, among
others, in advocating for the Principle of Interchangability, it still has
huge unresolved issues that relegate it to being just wishful thinking. For
example, how do you map an assignment to a relvar that is defined as a union
or a join to assignments to the base relvars in the union or the join?
> > So far, I have by default taken the approach of considering attributes
> > of virtual
> relations as being subjected to ANY constraint that carries on some
> attribute that
> allows these attributes to be built. I wander about the risks and
> opportunities of
> such approach and whether some work has been done on that subject.
I'm not sure what it is you're trying to say here. If you're saying that
the contstraints defined on the base relation schemata impact the set of
possible derived relations (values), then I would agree, since the predicate
of the virtual relation schema includes in its definition the predicates of
the base relations that appear in the definition of the virtual relation
schema.
Tegiri Nenashi
> > Since a TRDBMS should allow constraint specialization in a declarative way...
IMO, TRDBMS is not a good term. First, why relational model applied to
database management field only? Somewhere on databasecolumn.com I
remember reading that Dr.Codd's initial intention was general purpose
programming language; narrowing the scope to DBMS allowed to avoid
competition with traditional PL.
Also I consider the other TRDBMS features such as elimination of NULLs
and duplicates as trivial. If there only for these one could challenge
TRDBMS added value, which brings us to the TRDBMS crux feature --
declarative constraints.
What are constraints? They are equations and inequalities in
relational algebra, or some propositions in relational calculus.
Comparing the two, textbooks always point to the fact that RA has more
procedural feel to it, compared to RC. Indeed, query has to specify RA
operations is order, much like commands in traditional PL. This idea
always bothered me, and only recently I found a satisfactory answer to
it.
A good illustration for declarative specification is an often cited
SQRT example. Consider solving quadratic equation:
x*x = 9
Programmatic system where a user asks the system a question about the
roots of x*x = 9 is declarative. Contrast this to procedural solution
-- a function that returns a square root of number. It has to
implement some algorithm, and algorithms are inherently procedural.
Let's write what the function is doing as a formula
x = SQRT(9)
Now, compare both identities. The first one is constraint, the second
one is query! So if a user is allowed to write a query as a
constraint, that is using algebraic expressions with variables on both
sides of equal sign, then we immediately have declarative query.
So suppose we allow relation variables in a query and elevate queries
from being written as RA expressions (which are simple identities
"x=queryExpr") to RA equations. This is already done in one case!
Transitive closure written as Common Table Expression is an equation
that has a variable on both sides of the identity. Can we benefit from
writing some other (nonrecursive) queries as equations too? My
proposed term for those "genuine declarative queries".
Using algebra for constraint specialization and genuine declarative
queries, however, has a major obstacle. One can accomplish very little
if the algebra is (utilizing Marshall's term) misshapen.
Cimode
> On Jun 10, 6:07 am, Cimode <cim...@hotmail.com> wrote:
>
> > > Since a TRDBMS should allow constraint specialization in a declarative way...
>
> IMO, TRDBMS is not a good term. First, why relational model applied to
> database management field only? Somewhere on databasecolumn.com I
> remember reading that Dr.Codd's initial intention was general purpose
> programming language; narrowing the scope to DBMS allowed to avoid
> competition with traditional PL.
By TRDBMS, I meant a system that allows an inner logical
representation that allows to operate soundly relations (thanks to a
relation declarative operating language) and that truly implements
independence between the physical and logical layers as defined
according to RM. TRDBMS is here to be understood as a hypothetic
objective for what a relational system (be it inside or outside the
scope of databases) should do.
> Also I consider the other TRDBMS features such as elimination of NULLs
> and duplicates as trivial. If there only for these one could challenge
> TRDBMS added value, which brings us to the TRDBMS crux feature --
> declarative constraints.
I wish I had your confidence. Since decomposition is the only correct
way to deal with missing information, I can tell you that buidling a
non direct image system that automatically decomposes relations and
implements Darwen approach to missing information is not what I would
call a trivial task. It took me one year to get this one to work.
> What are constraints? They are equations and inequalities in
> relational algebra, or some propositions in relational calculus.
Both have advantages that unfortunately mutually exclusive. RA has
stronger expressive power while RC allows better abstraction. I am
trying to get the best of both by developping a language whose
specifications I began to some monthes ago.
> Comparing the two, textbooks always point to the fact that RA has more
> procedural feel to it, compared to RC. Indeed, query has to specify RA
> operations is order, much like commands in traditional PL. This idea
> always bothered me, and only recently I found a satisfactory answer to
> it.
Yes. See above.
> A good illustration for declarative specification is an often cited
> SQRT example. Consider solving quadratic equation:
>
> x*x = 9
>
> Programmatic system where a user asks the system a question about the
> roots of x*x = 9 is declarative. Contrast this to procedural solution
> -- a function that returns a square root of number. It has to
> implement some algorithm, and algorithms are inherently procedural.
> Let's write what the function is doing as a formula
>
> x = SQRT(9)
>
> Now, compare both identities. The first one is constraint, the second
> one is query! So if a user is allowed to write a query as a
> constraint, that is using algebraic expressions with variables on both
> sides of equal sign, then we immediately have declarative query.
It is interesting to compare viewpoints but you are using an argument
of traditional algebra to solve relational algebra.
To clarify...Since I assume that a relational system does operates
only through relational algebra and I consider x as a relation x*x = 9
is not equivalent to x = sqrt(9) as it would dbe the case in
traditional algebra. I consider "*" as a cartesian product between
two unknown relations named x.
x in equation would be solved as x = 9
while x = 3 in the second equation.
> So suppose we allow relation variables in a query and elevate queries
> from being written as RA expressions (which are simple identities
> "x=queryExpr") to RA equations. This is already done in one case!
> Transitive closure written as Common Table Expression is an equation
> that has a variable on both sides of the identity. Can we benefit from
> writing some other (nonrecursive) queries as equations too? My
> proposed term for those "genuine declarative queries".
Once they get adequately represented as a set of constraints
associated with a header set, nothing in fact precludes the assignment
of relations to other relations in a system, since the assignement of
the constraints and header becomes the assignment of the relation. If
I write down R1 = (R2 * R3), I only assign the set of constraints of
R2 * R3 at compile time to ato a specific header set called R1.
> Using algebra for constraint specialization and genuine declarative
> queries, however, has a major obstacle. One can accomplish very little
> if the algebra is (utilizing Marshall's term) misshapen.
Agreed. I am working on a different layer than RM. My effort is at
building a computing system (and subsequent engine) while keeping some
consistence with previous work. Much more of work remains to be done
on that layer than on the layer of RM itself.
Brian Selzer
The relational algebra and the calculus have equivalent expresive power,
even when extended with aggregate functions. See
"Equivalence of Relational Algebra and Relational Calculus Query Languages
Having Aggregate Functions", Anthony Klug, Journal of the ACM, July, 1982.
Incidentally, Date references this paper in the chapter on relational
algebra in the eighth edition of /Introduction/.
Brian Selzer
"Cimode" <cim...@hotmail.com> wrote in message
news:e8559d73-1998-4caf...@i28g2000prd.googlegroups.com...
Decomposition is only one way to deal with missing information, and all it
does is move the problem. Under the Closed World Interpretation, the
absence of a tuple in a relation does not indicate that information is
missing, but instead denies it. Decomposition as a mechanism for dealing
with missing information, therefore, is in my opinion incompatible with the
Closed World Interpretation. Darwen's is an inconsistent approach because
some relations represent what is true, and some represent what is known to
be true. Those that represent what is known to be true fall under the Open
World Interpretation. That's one problem.
Darwen's approach is directed at the elimination of nulls, but there are in
fact two basic sorts of nulls: nulls that indicate that there should be a
value, but it hasn't yet been supplied, and nulls that indicate that a
particular attribute is not applicable to what is represented by the tuple.
Darwen's approach is in accord with the Closed World Interpretation when it
is applied only to nulls of the 'inapplicable' sort. Decomposition is
therefore a good, and in my opinion, the correct mechanism for dealing with
inapplicable nulls. But of course, that leaves nulls of the 'applicable'
sort.
It is my opinion that nulls are not inherently flawed, but that it is the
misinterpretation, and the consequent misuse of nulls that are. If each
instance of null is /always/ an indication that information should have been
supplied, but hasn't--that is, if there is always only the one accepted
interpretation of the symbol, null, then each null can be replaced by an
expression of the form,
'Exactly one d such that d is an element of D'
where D is the domain of the constant that should have been supplied.
In this way, each tuple that can be in a 'relation'--even if it is
incomplete--maps to a formula in a first order language that can be assigned
a truth value under an interpretation. I'm quoting 'relation' here because
in a relation, every tuple has exactly the same number of components as the
schema has attributes, but if incomplete tuples are permitted, which is the
case when nulls are allowed, then some of the tuples can have fewer
components than the schema has attributes. It should be noted, however,
that an instance of the schema /is/ a relation just in case all values have
been supplied, which isn't true when inapplicable nulls are permitted.
This interpretation of null is in accord with the Closed World
Interpretation because each tuple that appears in a 'relation' represents
something that is true, not just what is known to be true. The distinction
is subtle, and some might call it nitpicking, but I think it bears directly
on how each tuple maps to something in the Universe. I think it is
counterintuitive for a tuple in a base relation to represent the fact that
something is not known, which is one of the consequences of Darwen's
approach.
Cimode
next one on my bookself.
Walter Mitty
"Brian Selzer" <br...@selzer-software.com> wrote in message
news:SO0Zl.25789$as4....@nlpi069.nbdc.sbc.com...
> It is my opinion that nulls are not inherently flawed, but that it is the
> misinterpretation, and the consequent misuse of nulls that are.
Agreed.
Having said that, my preferred interpretation of NULL is different from
yours.
Cimode
> Decomposition is only one way to deal with missing information, and all it
> does is move the problem. Under the Closed World Interpretation, the
> absence of a tuple in a relation does not indicate that information is
> missing, but instead denies it.
> Decomposition as a mechanism for dealing
> with missing information, therefore, is in my opinion incompatible with the
> Closed World Interpretation. Darwen's is an inconsistent approach because
> some relations represent what is true, and some represent what is known to
> be true. Those that represent what is known to be true fall under the Open
> World Interpretation. That's one problem.
> Darwen's approach is directed at the elimination of nulls, but there are in
> fact two basic sorts of nulls: nulls that indicate that there should be a
> value, but it hasn't yet been supplied, and nulls that indicate that a
> particular attribute is not applicable to what is represented by the tuple.
> Darwen's approach is in accord with the Closed World Interpretation when it
> is applied only to nulls of the 'inapplicable' sort. Decomposition is
> therefore a good, and in my opinion, the correct mechanism for dealing with
> inapplicable nulls. But of course, that leaves nulls of the 'applicable'
> sort.
I agree that decomposition as described by Darwen is far from being a
perfect solution. As far as I am concerned, the mecanism also
describes *applicable* that leaves the applicable type of null at the
level of intent by programmers. Since I only inspired myself from
Darwen mecanism and use subtyping as method for decomposing I would
not be able to say. I have created in the programming language a
tools and functions that allow the programmer to decide the type of
missing information that may be faced.
> It is my opinion that nulls are not inherently flawed, but that it is the
> misinterpretation, and the consequent misuse of nulls that are. If each
> instance of null is /always/ an indication that information should have been
> supplied, but hasn't--that is, if there is always only the one accepted
> interpretation of the symbol, null, then each null can be replaced by an
> expression of the form,
Well NULLS are just a method that revealed its limitations. Under
POCW, there is no need for such method since we are dealing primarily
with missing information. But I agree that the role of interpretation
by final user has been underestimated into applying POCW.
> 'Exactly one d such that d is an element of D'
>
> where D is the domain of the constant that should have been supplied.
>
> In this way, each tuple that can be in a 'relation'--even if it is
> incomplete--maps to a formula in a first order language that can be assigned
> a truth value under an interpretation. I'm quoting 'relation' here because
> in a relation, every tuple has exactly the same number of components as the
> schema has attributes, but if incomplete tuples are permitted, which is the
> case when nulls are allowed, then some of the tuples can have fewer
> components than the schema has attributes. It should be noted, however,
> that an instance of the schema /is/ a relation just in case all values have
> been supplied, which isn't true when inapplicable nulls are permitted.
>
> This interpretation of null is in accord with the Closed World
> Interpretation because each tuple that appears in a 'relation' represents
> something that is true, not just what is known to be true. The distinction
> is subtle, and some might call it nitpicking, but I think it bears directly
> on how each tuple maps to something in the Universe. I think it is
> counterintuitive for a tuple in a base relation to represent the fact that
> something is not known, which is one of the consequences of Darwen's
> approach.
Interesting. However, I am not working at the moment in the layer of
RM.
Brian Selzer
"Walter Mitty" <wam...@verizon.net> wrote in message
news:fA1Zl.926$P5....@nwrddc02.gnilink.net...
There are a number of interpretations. Raymond Reiter in "A Sound and
Sometimes Complete Query Evaluation Algorithm for Relational Databases with
Null Values," Journal of the ACM, April 1986, argues that nulls are
constants for which there is no unique name axiom. Codd, in his book, RMv2,
states that nulls are not values, but indicators and distinguishes between
inapplicable nulls and applicable nulls by using two separate null
indicators and 4VL. Others argue that there are many different kinds of
null, but what that boils down to is that that there are many different
reasons that a value either should have been supplied but hasn't, or is not
applicable, and that reason should somehow be encoded as the kind of null
value. The interpretation that I take issue with the most is the one that
uses the same symbol to indicate both that there can't be a value and that
there can be a value but it hasn't been supplied.
Brian Selzer
<snip>
> Interesting. However, I am not working at the moment in the layer of
> RM.
I understand.
Cimode
Thank you. To clarify further...
The point of the post was to point out a important question to be
answered when designing a relation operating engine. The question is
about the timing at which constraints are to be implemented. At the
moment, I implement constraints at compile time comes the problem of
implementing constraints on virtual relvar representation. Since
these are represented at run time only, I was wandering if anybody had
feedback on that matter.
But thanks for bringing some insight on missing information.
Walter Mitty
Interesting.
In the case of "no value supplied, by reason of inapplicability", I
consider the "by reason of inapplicability" qualifier to be metadata, not
data. As such, there should be room in the definition (header?) for the
proviso that if nulls appears in this context, all these nulls are
inapplicable. I note in passing that, when a null is inapplicable, if a
value had been supplied, that would have been an error. And, as you and
others have pointed out, inapplicable nulls can be removed by decomposition.
I can't think of a good reason not to decompose at the logical level. The
physical level is another story, maybe.
In the case of "a value should have been supplied, but none was" I think
of this as an exception, kinda like the exception that happens when an
attempt is made to divide by zero. All the null marker does is convey the
exception from the context in which the data was stored to the context in
which it is to be used. If there are some queries that are unaffected by
the presence of nulls in some places, I'm going to call that a specialized
case of data independence, which might be called "data exception
independence" or "data absence independence". .
The world of practice is full of people whose professional development
consists almost entirely of OOP, and who are suddenly coming up to speed on
both SQL and database design. Not only that, but they have a very short
deadline to produce deliverables, and an intentionally narrow view of the
value of stored data. These people often unconsciously associate meanings
with nulls that go way beyond anything that you or the experts you cite
would accept as a useful meaning for that symbol. If you ask them, they
will revert to the meaning that they attach to a pointer that doesn't point
anywhere. In that world, promoting some sort of "best practice" in
restricting the use of null tends to fall on deaf ears.
Walter Mitty
>The point of the post was to point out a important question to be
>answered when designing a relation operating engine. The question is
>about the timing at which constraints are to be implemented. At the
I'm not sure what you mean by "are to be implemented". Does this mean the
same thing as "are to be enforced"?
Cimode
at compile time and constraint enforcement at run time...
Cimode
> The world of practice is full of people whose professional development
> consists almost entirely of OOP, and who are suddenly coming up to speed on
> both SQL and database design. Not only that, but they have a very short
> deadline to produce deliverables, and an intentionally narrow view of the
> value of stored data. These people often unconsciously associate meanings
> with nulls that go way beyond anything that you or the experts you cite
> would accept as a useful meaning for that symbol. If you ask them, they
> will revert to the meaning that they attach to a pointer that doesn't point
> anywhere. In that world, promoting some sort of "best practice" in
> restricting the use of null tends to fall on deaf ears.
using NULLS will crunch time over the entire system lifecycle. For
instance the time of maintainance of a system using NULLS is far more
important than a system that does not use them, increasing TCO by
orders of magnitude.
Because they ignore RM definitions about, SQL developpers also ignore
that drawbacks of using nulls far outweights any advantages.
Promoting best practices can not replace a formal education about RM.
Brian Selzer
I would have used 'misusing nulls' instead of 'using nulls' because
judicious use of nulls can actually reduce both development and execution
time, as well as maintenance, especially if decomposition would introduce
complicated interrelational constraints. For example, a schema for married
employees,
MarriedEmployees {EMP#, NameOfSpouse}
where NameOfSpouse can be null is a lot easier to maintian than a pair of
schemata,
MarriedEmployeesWithSpouseName {EMP#, NameOfSpouse},
MarriedEmployeesWithoutSpouseName {EMP#}
and the interrelational constraint that prevents an instance of EMP# from
appearing in both relations.
> Promoting best practices can not replace a formal education about RM.
But what counts as 'formal education' these days is in many cases worse than
being worthless.
Cimode
a good thing or not. I can only say that it is not my experience. As
DBA fixing lots of performance issues on mission critical systems, I
observed that designs using NULLS produces the following effects (to
quote a few from memory):
1> To maintain data correctness, an additional layer of ISNULL, IS
NOT NULL, IS NULL SQL predicates become almost mandatory. You just
need to take a look at how business intelligence SQL lookalikes (MDX)
languages are designed.
2> Since 1 happens, perfomance is strongly degraded since additional
scans that would not happen if they were no NULLS. As a consequence
the lifespan of applications scanning a specific table using NULLS is
shortenned due to overhead due to NULLS.
3> In general, since the use of NULLS force the use of IS NULL/IS NOT
NULL clauses on *each* procedure accessing the table, there is a
multiplying factor over the overhead described in 2> which is a
performance killer.
As a consequence of 1, 2 and 3 I can not say that I can only deny what
you claim.
> MarriedEmployeesWithSpouseName {EMP#, NameOfSpouse},
> MarriedEmployeesWithoutSpouseName {EMP#}
>
> and the interrelational constraint that prevents an instance of EMP# from
> appearing in both relations.
>
> > Promoting best practices can not replace a formal education about RM.
>
> But what counts as 'formal education' these days is in many cases worse than
> being worthless.
As far as I am concerned as a daily database practitionner, a basic
formal education in sound database theory has helped me a lot simplify
my job since I understand what to expect as a general trend. Formal
education has a power of making things more predictable while learning
tricks and hacks has only a single mission lifespan. The fact that
formal education would or not count in eyes of uniformed audiences has
a limited importance. the same audiences in fact pay me big box to
fix errors their incompetent ignorant designers could have easily
avoided if they bothered doing some reading.
That is my experience.
Brian Selzer
<snip>
> > > Because they ignore RM definitions about, SQL developpers also ignore
> > > that drawbacks of using nulls far outweights any advantages.
> >
> > I would have used 'misusing nulls' instead of 'using nulls' because
> > judicious use of nulls can actually reduce both development and
> > execution
> > time, as well as maintenance, especially if decomposition would
> > introduce
> > complicated interrelational constraints. For example, a schema for
> > married
> > employees,
> >
> > MarriedEmployees {EMP#, NameOfSpouse}
> >
> > where NameOfSpouse can be null is a lot easier to maintian than a pair
> > of
> > schemata,
> I do not want ot make this an offtopic debate about whether NULLS are
> a good thing or not. I can only say that it is not my experience.
My experience is different, but I also don't want this to turn into a
pissing contest.
Cimode
Thank you for understanding. Appart of the fact that people loose
sight of respectfully disagreeing, I have found out that one of the
things that also hurts the emergence of new ideas is the fact that
people get quickly diverted to general subjects that have been
discussed a million times. Many times I have posted threads where I
would submit a specific subject for discussion and somehow it often
ends up on the same subjects:
NULL vs NON NULL use
SQL vs OO
SQL vs RM
RM vs OO
Not that I am claiming that all of the above do not deserve discussion
but I have hard time relating them to for instance a discussion that
is not in the layer of RM but for instance the layer of computing
models related to RM.
My two cents...
Brian Selzer
> On 14 juin, 11:28, "Brian Selzer" <br...@selzer-software.com> wrote:
> > "Cimode" <cim...@hotmail.com> wrote in message
> >
> > news:af92f612-e800-46b2...@r10g2000yqa.googlegroups.com...
> >
> > <snip>
> >
> > > Interesting. However, I am not working at the moment in the layer of
> > > RM.
> >
> > I understand.
>
> Thank you. To clarify further...
>
> The point of the post was to point out a important question to be
> answered when designing a relation operating engine. The question is
> about the timing at which constraints are to be implemented.
I would argue that it can only be when new information is submitted. A user
submits a set of deletes, updates and/or inserts that describe exactly which
tuples in base relations represent things that no longer exist, which tuples
in base relations represent things that differ in appearance, and which
tuples should now be in base relations because things have come into
existence. The point in time that that set of deletes, updates and/or
inserts is submitted is the time that constraints should be evaluated. The
set of deletes, updates and/or inserts can be packaged as a set of
relations, up to three for each relation schema involved, one for tuples
targeted by deletes, one for tuples targeted by updates and one for tuples
slated to be inserted. In this way, constraints can be declared in terms of
exactly what is different between the current database and a proposed
database, and the constraint engine need only be concerned with what is
different, which may obviate the need to materialize a virtual relation. I
think that most if not all constraints defined in terms of just the base
relations in the proposed database (state constraints) can be translated to
constraints defined in terms of what is being deleted, what is being updated
and what is being inserted, combined with the current database. Accesses to
the current database can be just plain index seeks, and the indexes that
need to be maintaned for constraint enforcement should be able to be
determined as a consequence of the constraints defined on the database. The
approach I would take to implementing constraints on relational expressions
would be to examine how a typical insert, update or delete or combination
thereof affects the result of the expression, to discover a deterministic
mechanism for translating the constraint so that it is defined in terms of
what is being deleted, what is being updated and what is being inserted.
For those expressions for which there isn't a translation, the result of the
expression would probably have to be materialized, at least partially.
Cimode
one naturally the operations updating a relation body. However, I
discovered that constraints may play a role outside of that scope
because the representation scheme of the relation on a non direct
image system can actually allow to enforce it *once* at compile time.
To clarify...
Since relations de facto define types and decomposition is just
another term for relation subtyping, the process of building a subtype
is in fact the inheritance of a constraint set from the supertype
relation. Therefore, the declaration of a subtype in further
definitions is in fact an implicit declaration and enforcement of the
constraints. Starting from that, it is possible to design a system,
whose relation representation scheme would reflect the inheritance
relationship between the two relations by allowing the constraint to
be enforced through the storage mechanism itself. As a consequence of
that, the constraints are not enforced as a part of the traditional
execution process at the time of relation change but as a part of the
deisgn effort.
Your response has pointed out that the subject should have been
formulated otherwise. I think I am going to create a new thread.