L'intégrité référentielle permet de décrire les liens de référence entre deux tables et de préciser les contraintes de mise à jour. Prenons par exemple les tables Pays et Devises. Dans la table Pays nous avons un champ Devise dont la valeur

doit se trouver dans la table Devises. La contrainte d'intégrité entre les deux tables va nous permettre:

 

1) de faire vérifier par Paradox que les valeurs du champ Devise de la table Pays appartiennent à la table Devises,

 

2) de contrôler et répercuter les modifications effectuées dans la table Devises. On peut ainsi interdire ces opérations si une référence est utilisée ou répercuter une mise à jour. Le choix est fait au niveau de la table enfant (ici la table Pays). Si on change par exemple le code devise FRF en FF, cette modification sera automatiquement répercutée pour tous les pays concernés (si l'option mise à jour en cascade est choisie),

 

3) d'interdire la suppression des enregistrements de la table Devise qui sont référencés dans la table Pays.

 

Différence avec la notion de table de référence:

L'intégrité référentielle ne fournit aucune aide en saisie.

La table de référence ne bloque pas les actions effectuées sur la table Devises (vous pouvez supprimer une devise référencée).

Il est donc nécessaire pour avoir un système complet de mettre en oeuvre les deux mécanismes.

 

Les limites de l'intégrité référentielle:

Limites fonctionnelles:

- un seul niveau de profondeur pour la mise à jour en cascade.
- pas de suppression en cascade (utile par exemple dans les structures de type Commandes - Lignes de commande),

 

Limites techniques:

- Seules les tables du répertoire de travail peuvent être prises en compte dans l'intégrité référentielle.

- Paradox stocke le chemin complet des tables en contrôle d'intégrité dans les fichiers .VAL des tables concernées.

- Une table endommagée va bloquer l'accès aux autres tables.

- La mise à jour en cascade est délicate en environnement réseau et peut se révéler coûteuse en ressource, Paradox devant verrouiler l'ensemble

des enregistrements dépendants afin de s'assurer qu'il pourra faire la mise à jour intégralement.

- la copie individuelle de table (par le système d'exploitation) ou le déplacement dans un autre répertoire ne sont plus possibles.

- En cas de corruption du fichier .VAL, il sera nécessaire de supprimer celui-ci avant de récupérer la table.

 

Outre la nécessité de redéfinir l'intégrité référentielle, il sera égalemnent nécessaire de rédéfinir toutes les informations contenues dans ce fichier (valeurs modèles, minium, maximum, par défaut, ...).

 

Autre solution:

Nous préconisons de gérer cette intégrité par programmation.

Une note technique dans la partie ObjectPal fournit un exemple

de programmation:  <link>Programmer les contraintes d'intégrité avec Paradox