Prepare for the second stage of testing

Typical problems

Besides data type in the relational theory the fundamental concept of the domain, as sets of allowable values which can have an attribute. It is possible to tell, that the domain represents a pair {base data type, a predicate}.Thus value belongs to the domain only in the event that it has corresponding type and a predicate calculated on this value, there is a TRUE. Attributes (columns of a table) are defined on the domain that is to say besides the control of types DBMS over each change of the data should check also value of a predicate. Change will be rejected, if kept value does not satisfy to a predicate of the domain.

The domain plays one more important role more precisely the values belonging to one domain can be compared only. Let's consider as an example PC table, namely, columns speed (clock frequency of the processor) and hd (volume of a hard disk). Both these of a columns have integer (or smallint) data type. However it is completely different characteristics. It is enough to tell, that in a subject domain for them different units of measurements - hertz and byte are used. And so, if we shall define these columns on different domains comparison of value of one column with value of other column becomes inadmissible. And it will be supervised DBMS. By analogy with categores and reference integrity such control could be named domain integrity if this term has not been occupied in  A database management system (DBMS) by Microsoft Corporation. SQL(Structured Query Language) is a database computer language designed for the retrieval and management of data in relational database management systems (RDBMS), database schema creation and modification, and database object access control management.SQL Server under check of CHECK constraint imposed on columns of the table. And so determined "domain integrity" in any way does not limit comparison.

Not superfluous will remind of importance of maintenance of integrity on side DBMS. Restrictions of integrity, as a rule, model the restrictions real-life in a subject domain. As these restrictions do not depend on appendices, it is natural to check them (and to write) in a place, the common for all appendices which is DBMS. It besides other:

• Relieves appendices of necessity to build (and to duplicate!) in them necessary checks;

• Guarantees higher level of safety. The restrictions which have been built - in the appendices, it is easy to bypass. To address to a database passing the application enough;

• Facilitates support and development. If restrictions of a subject domain will change, corresponding program changes will need to be made in one place, instead of in all applications working with a database.

Coming back to domains, pertinently to notice, as language standard SQL-92 does not put in concept of the domain of sense of "comparability". That is realized by the standard, no more than an opportunity once to write down restrictions, and then repeatedly to apply them at definition of specifications columns, that is an opportunity to avoid duplications of codes.

In a chain "Theory --> Standard --> Realization" is consistently lost severity of the relational theory therefore we not can is quite transparent to cooperate with relational DBMS different producers. Here I want to show a small example of how it is necessary to address with data types in SQL Server.