Re: Multiplicity, Change and MV
Date: Tue, 18 Apr 2006 13:08:41 GMT
Message-ID: <tx51g.61657$VV4.1151645_at_ursa-nb00s0.nbnet.nb.ca>
x wrote:
> "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.
>>
>>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.)
> > > I think you are right when you say the constraints are defined by the > applications. > But think about this scenario: > - one application define its constraints and enter the data according to > them > - other application define its constraints and enter the data according to > them > - the data from the two applications overlaps > - the common data entered by the second application is less constrained > - the first application query the common data > - the retrieved data don't follow the constraints of the first application > and the application was developed with the assumption it does > > Guess what will happen. > >
>>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.
> > > Only lists of strings are needed :-) > >
>>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).
> > > One goal of the RM was removing the dependency on the growth in data types. > :-)
Actually, boolean is mandated by the RM. Everything else is whatever one can imagine.
>>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)!
>
> There is nothing bad about nulls.
> Only the SQL style null is bad. > You can choose if you prefer to use relations with nulls or sets of > relations.
Unfortunately, if your DMBS has to allow for NULL, it will generally not function as well as one that does not. Even if the DBMS implementation detects all cases without NULL for optimization purposes, the DBMS will require more executable code and have more branches of execution. As a general rule, these properties will translate into slower code (ie. more page faults) and buggier code (ie. less complete coverage during testing). Received on Tue Apr 18 2006 - 15:08:41 CEST