Exploitation du modèle de données

d’entité revient à valider les données au sein d’une ligne. Les clés primaires et les contraintes uniques permettent aux développeurs d’identifier de manière univoque chaque ligne d’une table, et donc d’éliminer les doublons. Examinons la figure 1, laquelle présente le modèle de données pour trois tables, Account_Type, Customer et Account. Le code DDL complet servant à créer ces tables est disponible dans le listing Web 1 (http://www.itpro. fr, Club Abonnés). L’extrait de code du listing 1 montre que l’entité Account_Type contient une clé primaire (account_ type_id), que j’ai mise en oeuvre au moyen d’une contrainte de clé primaire. J’ai également défini une clé de remplacement sur la colonne de description, à l’aide d’une contrainte unique. Cette conception garantit l’unicité des lignes, de deux manières : les lignes sont différenciées par la clé account_type_id et par la description. Cette approche procure l’avantage d’assurer l’unicité du nom des types de compte et d’améliorer les performances tout en réduisant le stockage en utilisant account_type_id pour appliquer toute relation de clé étrangère potentielle.

Un autre exemple d’intégrité d’entité consiste à employer une contrainte check de niveau table pour valider ou comparer plusieurs colonnes dans une ligne. Par exemple, dans le bloc C du listing 2, la contrainte account_balance_ck de la table Account vérifie que la somme de opening_balance et de current_balance est supérieure ou égale à zéro pour que la ligne soit valide.

Les contraintes de clé étrangère aident les développeurs à appliquer l’intégrité référentielle. Comme vous pouvez le constater dans le bloc D du listing 2, une contrainte de clé étrangère assure l’intégrité référentielle sur la colonne Account.account_type_id. Elle vérifie que toutes les valeurs dans la colonne enfant ont une valeur correspondante unique dans la colonne parent.

Il existe plusieurs options pour l’application de l’intégrité de domaine. Les contraintes check de niveau colonne garantissent ce type d’intégrité en limitant une valeur de colonne à une certaine plage. Par exemple, la contrainte account _opening_balance_ck sur la table Account (bloc B) fait en sorte que opening_balance soit toujours supérieure ou égale à zéro. De même, la combinaison d’un type défini par l’utilisateur (UDT) avec des contraintes check limite toute colonne définie par l’UDT au domaine de valeurs spécifié. D’autre part, vous pouvez utiliser des contraintes de clé étrangère pour appliquer l’intégrité de domaine en limitant une colonne à l’ensemble de valeurs défini dans la table parent.

Le choix entre une contrainte check et une contrainte de clé étrangère pour appliquer l’intégrité de domaine peut être ardu. Bien que les deux approches vous rapprochent de la validation intelligente des données, leur mise en oeuvre a un impact sur les performances et la maintenance. Soupesez avec soin la solution la mieux adaptée à votre situation particulière. Une règle générale consiste à utiliser une contrainte check en cas de nombre réduit de valeurs statiques et des contraintes de clé étrangères via l’intégrité référentielle pour un nombre de valeurs élevé, à caractère plutôt dynamique.

Au royaume de la validation intelligente des données, les déclencheurs peuvent offrir un moyen d’appliquer l’intégrité métier (le concept consistant à employer des règles complexes sur les lignes et tables) et n’importe lequel des trois types d’intégrité déjà abordés. Bien que des déclencheurs mal écrits soient souvent la cause de nombreux problèmes de performances, cette approche peut se révéler un bon outil pour valider les données. Il suffit de les utiliser avec précaution.