Constraints on Relational database model

On modeling the design of the relational database we can put some restrictions like what values are allowed to be inserted in the relation, what kind of modifications and deletions are allowed in the relation. These are the restrictions we impose on the relational database.

In models like ER models, we did not have such features.

Constraints in the databases can be categorized into 3 main categories:

  1. Constraints that are applied in the data model is called Implicit constraints.
  2. Constraints that are directly applied in the schemas of the data model, by specifying them in the DDL(Data Definition Language). These are called as schema-based constraints or Explicit constraints.
  3. Constraints that cannot be directly applied in the schemas of the data model. We call these Application based or semantic constraints.

So here we will deal with Implicit constraints.

Mainly Constraints on the relational database are of 4 types:



  1. Domain constraints
  2. Key constraints
  3. Entity Integrity constraints
  4. Referential integrity constraints

Let discuss each of the above constraints in detail.

1. Domain constraints :

  1. Every domain must contain atomic values(smallest indivisible units) it means composite and multi-valued attributes are not allowed.
  2. We perform datatype check here, which means when we assign a data type to a column we limit the values that it can contain. Eg. If we assign the datatype of attribute age as int, we cant give it values other then int datatype.

Example:

  \begin{center} \begin{tabular}{ |c|c|c|c| }  \hline EID & Name & Phone \\ \hline \001 & Bikash Dutta & 123456789 \\   & & 234456678\\  \hline \end{tabular} \end{center}

Explanation:
In the above relation, Name is a composite attribute and Phone is a multi-values attribute, so it is violating domain constraint.

2. Key Constraints or Uniqueness Constraints :

  1. These are called uniqueness constraints since it ensures that every tuple in the relation should be unique.
  2. A relation can have multiple keys or candidate keys(minimal superkey), out of which we choose one of the keys as primary key, we don’t have any restriction on choosing the primary key out of candidate keys, but it is suggested to go with the candidate key with less number of attributes.
  3. Null values are not allowed in the primary key, hence Not Null constraint is also a part of key constraint.

Example:

  \begin{center} \begin{tabular}{ |c|c|c|c| }  \hline EID & Name & Phone \\ \hline \001 & Bikash & 6026526747 \\  \002 & Paul &  7002494274\\  \001 & Tuhin & 9234567892\\   \hline \end{tabular} \end{center}



Explanation:
In the above table, EID is the primary key, and first and the last tuple has the same value in EID ie 01, so it is violating the key constraint.

3. Entity Integrity Constraints :

  1. Entity Integrity constraints says that no primary key can take NULL value, since using primary key we identify each tuple uniquely in a relation.

Example:

  \begin{center} \begin{tabular}{ |c|c|c|c| }  \hline EID & Name & Phone \\ \hline \001 & Bikash & 7002494274 \\  \002 & Paul &  6026526747\\   NULL & Sony & 9234567892\\   \hline \end{tabular} \end{center}

Explanation:
In the above relation, EID is made primary key, and the primary key cant take NULL values but in the third tuple, the primary key is null, so it is a violating Entity Integrity constraints.

4. Referential Integrity Constraints :

  1. The Referential integrity constraints is specified between two relations or tables and used to maintain the consistency among the tuples in two relations.
  2. This constraint is enforced through foreign key, when an attribute in the foreign key of relation R1 have the same domain(s) as the primary key of relation R2, then the foreign key of R1 is said to reference or refer to the primary key of relation R2.
  3. The values of the foreign key in a tuple of relation R1 can either take the values of the primary key for some tuple in relation R2, or can take NULL values, but can’t be empty.

Example:

  \begin{center} \begin{tabular}{ |c|c|c|c| }  \hline EID & Name & DNO \\ \hline \001 & Divine & 12 \\  \002 & Dino &  22\\  \004 & Vivian & 14\\   \hline \end{tabular} \end{center}

  \begin{center} \begin{tabular}{ |c|c|c|c| }  \hline DNO & Place \\ \hline \112 & Jaipur \\  \113 & Mumbai \\  \114 & Delhi \\   \hline \end{tabular} \end{center}

Explanation:
In the above, DNO of the first relation is the foreign key, and DNO in the second relation is the primary key. DNO = 22 in the foreign key of the first table is not allowed since DNO = 22
is not defined in the primary key of the second relation. Therefore Referential integrity constraints is violated here

Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.




My Personal Notes arrow_drop_up

Check out this Author's contributed articles.

If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to contribute@geeksforgeeks.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.

Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.