Semantic integrity constraints

2.3.3 Semantic integrity constraints

A semantic integrity constraint refers to the correctness of the meaning of the data. For example, the street number attribute value from the OWNERS relation must be positive,

because the real-world street numbers are positive.

A semantic integrity constraint can be regarded as a predicate that all correct states of relations instances from the database are required to satisfy.

If the user attempts to execute an operation that would violate the constraint, the system must then either reject the operation or possibly, in more complicated situations, perform some compensating action on some other part of the database to ensure that the overall result is still a correct state. Thus, the language for specifying semantic integrity constraints

Chapter 2 – The relational data model 47 should include, not only the ability to specify arbitrary predicates, but also facilities for

specifying such compensating actions when appropriate. Semantic integrity constraints must be specified typically by a database administrator and

must be maintained in the system catalog or dictionary. The DBMS monitors user interactions to ensure that the constraints are in fact respected. Relational DBMS permits several types of semantic integrity constraints such as domain constraint, null constraint, unique constraint, and check constraint.

2.3.3.1 Domain constraint

A domain constraint implies that a particular attribute of a relation is defined on a particular domain. A domain constraint simply states that values of the attribute in question are required to belong to the set on values constituting the underlying domain.

For example, the Street attribute domain of OWNERS relation is CHAR(20), because streets have names in general and Number attribute domain is NUMERIC, because street numbers are numeric values.

There are some particular forms of domain constraints, namely format constraints and range constraints. A format constraint might specify something like a data value pattern.

For example, the IdentificationNumber attribute values must be of this type XX99XXX , where X represents an alphabet letter and 9 represents a digit. A range constraint requires that values of the attribute lie within the range values. For example, the FabricationYear attribute values might range between 1950 and 2010.

2.3.3.2 Null constraint

A null constraint specifies that attribute values cannot be null. On every tuple, from every relation instance, that attribute must have a value which exists in the underlying attribute domain. For example, FirstName and LastName attributes values cannot be null, this means that a car owner must have a name.

A null constraint is usually specified with the NOT NULL construct. The attribute name is followed by the words NOT NULL for that. Along with NOT NULL, the additional keyword “WITH DEFAULT” can optionally be specified so that the system generates a default value for the attribute in case it is null at the source while inserting. WITH DEFAULT is only applicable for numeric (integer, decimal, float etc.) and date (date, time, timestamp) data types. For other types, default value should be provided explicitly in the DDL.

2.3.3.3 Unique constraint

A unique constraint specifies that attribute values must be different. It is not possible to have two tuples in a relation with the same values for that attribute. For example, in the CARS relation the SerialNumber attribute values must be unique, because it is not

possible to have two cars and only one engine. A unique constraint is usually specified with an attribute name followed by the word UNIQUE. Note that NULL is a valid unique value.

Database Fundamentals

Note:

NULL is not part of any domain; therefore, a basic SQL comparison returns “unknown” when any one of the values involved in the processing is NULL. Therefore to handle NULL correctly, SQL provides two special predicates, “IS NULL” and “IS NOT NULL” to check if the data is null or not. Below is a brief summary table that indicates how NULL ("Unknown") is handled by SQL. Different database vendors/platforms may have a different ways of handling NULL.

A NOT A True

False True

Unknown False

True Unknown

False False

False Unknown Unknown

False

False

Unknown True

Unknown False Unknown

False

False

Unknown Unknown Unknown

Unknown

Unknown

2.3.3.4 Check constraint

A check constraint specifies a condition (a predicate) on a relation data, which is always checked when data is manipulated. The predicate states what to check, and optionally what to do if the check fails (violation response). If this violation response is omitted, the operation is rejected with a suitable return code. When the constraint is executed, the system checks to see whether the current state of the database satisfies the specified constraint. If it does not, the constraint is rejected, otherwise it is accepted and enforced from that time on.

For example, an employee's salary can’t be greater than his manager's salary or a department manager can’t have more that 20 people reporting to him. For our previous relations, for example, the fabrication year of a car can’t be greater than the current year or

a car can be owned by a single person. This type of constraint can sometimes be specified in the database using a CHECK

construct or a trigger. The check constraint can be checked by the system before or after operations like insert, update, and delete.

Chapter 2 – The relational data model 49