Re: Multiplicity, Change and MV

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

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.

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

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 Tue Apr 18 2006 - 02:39:47 CEST