Re: Multiplicity, Change and MV

"Neo" <neo55592_at_hotmail.com> wrote in message news:1145320787.580351.42240_at_i40g2000cwc.googlegroups.com...
>> but isn't the enforcement of constraints primarily the responsibility of
>> the database engine? If constraint enforcement is up to the application,
>> and more than one application exists for a particular database, then the
>> exact code required to enforce constraints must exist in each and every
>> application, otherwise consistency cannot be guaranteed.
>
> Ideally, there is only one type of constraint: application-defined
> constraints.
>

Then your ideal database can only be manipulated by a single application.

> Ideally, the db engine is completely responsible for data-integrity (ie
> ref intergity). I don't classify it as a constraint as it is not
> optional. It must be done. In exp db, user doesn't deals with data or
> referential integrity. In RMDBs, user is responsible for specifying
> constraints between keys of appropriate tables which the db engine or
> dbms then enforces.
>

What's the point of an optional constraint? If a constraint is defined on the database, it must be enforced, otherwise anarchy reigns.

> Now who is responsible for app constraints? Should it be the db engine
> or application? From a purist point of view, it should be the app. And
> in fact the majority of app-defined constraints (try defining it
> precisely) are implement by applications. Since many apps frequently
> require the same constraints, obviously they shouldn't duplicate the
> effort. In my view, those common app-constraints should not be embedded
> in the db-engine itself but in a layer just above it within the DBMS
> (see diagram below); however one should be able to disable/bypass it.
> If app-constraints are embedded directly in the db-engine, then a
> possibility exists that a future app's needs/flexibility will be
> curtailed. (Currently the experimental db does not have common
> app-constraints implemented in DBMS.)
>

If a constraint can be bypassed, then the contents of the database is suspect. You might as well just return pseudorandom numbers.

> Application
> __DBMS
> ____common app-constraints (bypassable/disablable)
> ______db engine
>
> In RM implementions (not RM model), some constraints fall into a fuzzy
> category, because implementations lack complete independence from
> hardware. For example, RM does not specify any specific data type but
> the actual implementation has them. For example, RMDBs typically have
> several data types (int, char, float, etc) that are closely related to
> memory hardware.
>
> The exp data model's implementation is significantly more hardware
> independent. Data types are not available until created just like types
> person, car, color (yes, these are data types just like integer in exp
> db). Thus constraining instances of integer to some min/max values has
> to be done by app (until implemented as a common app constraint within
> dbms).
>
> Another example of a fuzzy constraint is that RM and therefore RMDBs
> requires data to be stored in relations were tuples must have values
> for required attributes else incur NULL (or be substitued by masking
> values). The exp db doesn't have relation-like constraints but could
> add them making it behave similarly (and thus incur NULLs)!
>
Received on Thu Apr 20 2006 - 07:30:59 CEST