Download Integrity constraints and more Lecture notes Information Systems in PDF only on Docsity!
Integrity Constraints
Before one can start to implement the database tables, one must define the integrity constraints. Intergrity means something like 'be right' and consistent. The data in a database must be right and in good condition.
There are the domain integrity, the entity integrity, the referential integrity and the foreign key integrity constraints.
Domain Integrity
Domain integrity means the definition of a valid set of values for an attribute. You define
- data type,
- lenght or size
- is null value allowed
- is the value unique or not for an attribute.
You may also define the default value, the range (values in between) and/or specific values for the attribute. Some DBMS allow you to define the output format and/or input mask for the attribute.
These definitions ensure that a specific attribute will have a right and proper value in the database.
Entity Integrity Constraint
The entity integrity constraint states that primary keys can't be null. There must be a proper value in the primary key field.
This is because the primary key value is used to identify individual rows in a table. If there were null values for primary keys, it would mean that we could not indentify those rows.
On the other hand, there can be null values other than primary key fields. Null value means that one doesn't know the value for that field. Null value is different from zero value or space.
In the Car Rental database in the Car table each car must have a proper and unique Reg_No. There might be a car whose rate is unknown - maybe the car is broken or it is brand new - i.e. the Rate field has a null value. See the picture below.
The entity integrity constraints assure that a spesific row in a table can be identified.
Picture. Car and CarType tables in the Rent database
Referential Integrity Constraint
The referential integrity constraint is specified between two tables and it is used to maintain the consistency among rows between the two tables.
The rules are:
- You can't delete a record from a primary table if matching records exist in a related table.
- You can't change a primary key value in the primary table if that record has related records.
- You can't enter a value in the foreign key field of the related table that doesn't exist in the primary key of the primary table.
- However, you can enter a Null value in the foreign key, specifying that the records are unrelated.
Examples
Rule 1. You can't delete any of the rows in the CarType table that are visible in the picture since all the car types are in use in the Car table.
Rule 2. You can't change any of the model_ids in the CarType table since all the car types are in use in the Car table.
Rule 3. The values that you can enter in the model_id field in the Car table must be in the model_id field in the CarType table.
Rule 4. The model_id field in the Car table can have a null value which means that the car type of that car in not known
Foreign Key Integrity Constraint
There are two foreign key integrity constraints: cascade update related fields and cascade delete related rows. These constraints affect the referential integrity constraint.
Cascade Update Related Fields
Any time you change the primary key of a row in the primary table, the foreign key values are updated in the matching rows in the related table. This constraint overrules rule 2 in the referential integrity constraints.
If this contraint is defined in the relationship between the tables Car and CarType, it is possible to change the model_id in the CarType table. If one should change the model_id 1 (Ford Focus) to model_id 100 in the CarType table, the model_ids in the Car table would
