Fascicule 2 Modèle relationnel, algèbre relationnelle et ...

Hypercube

Ingénierie des bases de données

OLAP

c,d

André Gamache 2005

Architectures, modèles et langages de données

Modèle relationnel, algèbre relationnelle et transposition du conceptuel au relationnel

Fascicule 2

Architectures, Modèles et Langages de Données

Volume 1 Fascicule 1

1- Introduction 1 2- Architecture fonctionnelle du SGBD 20 3- Modèle conceptuel des données 79 - Index

Fascicule 2 4- Modèle relationnel : théorie et contraintes d’intégrité 1 5- Algèbre relationnelle 57 6- Transposition du MCD au MRD 137 - Index

Volume 2 Fascicule 3

7- Langage de données SQL 1 8- Indexation, vue relationnelle et base réactive 123 - Index

Fascicule 4 9- Langage de programmation et SQL 1

10- Théorie de la normalisation relationnelle : les formes normales FN1 à FN5 45 11- Optimisation des requêtes relationnelles 117 Annexes : A- SQLoader B- Projet ALU-Nord : Script de chargement des données - Index

Chapitre 4 Modèle relationnel et normalisation

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université Laval, Québec, Qc, Canada, G1K 7P4. Courriel : [email protected]

3



4

Chapitre 4

Modèle relationnel: théorie et contraintes d’intégrité

Dans ce chapitre, nous allons étudier le modèle relationnel (MRD) en abordant les bases théoriques. Afin d’éviter une démarche trop désincarnée, nous introduirons les éléments d’implémentation et le langage SQL-DDL pour illustrer leur utilisation dans la création d’une base de données. Nous étudierons aussi plusieurs implémentations des mécanismes de validité et de cohérence pour les données inhérentes à ce modèle, débordant les technologies à la mode de l’heure. Il s’agit en premier d’une étude du MRD et non une étude exhaustive du système Oracle. Vous y trouverez donc des notions théoriques implémentées et définies différemment selon le SGBD auquel font référence les exemples. Le SGBD Oracle est en trame de fond dans de nombreux exemples et illustrations des concepts sous-jacents au modèle relationnel.

4.1 Modèle relationnel Le modèle relationnel proposé par l’article phare de Codd (1) est une représentation logique et tabulaire des données stockées et cela dans une perspective propre aux usagers. En d’autres mots, les utilisateurs voient les données sous forme tabulaire sans connaître les détails de leur implémentation physique. L’exploitation des données fait appel à la même vision externe des données. Les tables qui sont appelées relations dans la théorie relationnelle sont obtenues par la transformation du modèle relationnel MCD vers le modèle relationnel (MRD) selon un ensemble de règles de transposition appliquées à chaque classe et à chaque association du MCD. Une relation est implémentée par une table logique. Cette dernière est nommée dans le langage SQL par un libellé unique qui est inscrit dans le dictionnaire. L'en-tête de la table est composé des attributs de la relation. Les lignes de la table sont les tuples qui correspondent aux instances de la classe d’entités représentée par la table. Il ne peut pas y avoir deux tuples identiques dans l’extension d’une même relation. Chaque table correspond à une sémantique précise qui peut être explicitée par une interprétation d’un tuple en langage naturel. Le passage du modèle conceptuel au logique est fait selon des règles précises appliquées à chaque élément du modèle : attribut, classe, association et spécialisation. A ce stade de notre étude, le passage sera illustré par quelques modèles conceptuels simples qui permettront de justifier la structure des tables utilisées et dʹétudier les propriétés particulières au modèle relationnel. Les autres règles de passage seront étudiées dans un prochain chapitre. Exemple : Gestion des comptes bancaires individuels modélisée par le diagramme des classes UML du MCD suivant :

Client nom* rue ville

Compte noCompte* nomSucc solde

EstProprio 1..* 1



5

Ce MCD est capable de représenter (modéliser) les instances suivantes :

Figure 4.1 Le ou les attributs de la clé primaire de chaque classe sont identifiés par un astérisque dans le MCD. En appliquant les règles de transposition du MCD de la figure 4.1, nous obtenons le modèle relationnel (MRD) composé des deux tables ci-dessous : Client (nom*, rue, ville) Compte (noCompte*, nomSucc, solde, nom) N.B. Dans une clause SQL, le trait d'union utilisé dans le libellé d'un mot sera remplacé par le souligné puisque le premier n'est pas admissible dans la plupart des langages de définition des tables (SQL-DDL). De même, un libellé d’attribut pu de classe ne peut pas avoir d’accent. La règle de transposition de ce MCD simple ayant une association de type 1 à plusieurs vers le modèle relationnel ci-dessus consiste à représenter chaque classe qui participe à l'association par une table de même nom et dotée des mêmes attributs. L'association de un à plusieurs n'est pas représentée, mais plutôt simulée par l'ajout, dans la table correspondant à la classe située du côté 1..n, des attributs spécifiques à l'association et ceux de la clé primaire de la classe située du côté de la multiplicité 1. Au niveau des instances, chaque entité devient un tuple formé de valeurs scalaires. À noter que le modèle de cet exemple simple a des limites évidentes de représentation. Par exemple, la clé étant le nom du client, on ne peut pas représenter des clients ayant le même patronyme! En effet, le nom doit identifier les clients et les distinguer les uns des autres! Pour contourner cette difficulté, il faudrait choisir une autre clé, le nas par exemple, et l'ajouter aux attributs de la classe Client. Dans le modèle ci-dessus, le nom est donc présumé être la clé de la relation. La clé de la deuxième relation présume aussi que le numéro de compte bancaire est global pour une même banque, car autrement le numéro de compte ne serait pas nécessairement unique parmi les comptes des différentes succursales. Avec un MCD légèrement plus complexe doté d’une association de plusieurs à plusieurs, le passage se fait selon une règle quelque peu différente. Par exemple, lorsque les contraintes de multiplicité de part et d'autre d'une association sont de plusieurs à plusieurs, chaque classe et chaque association sont respectivement transformées en une table pour chaque élément. Au total, le MRD comprend alors 3 tables. Client (nom*, rue, ville) Compte (noCompte*, noSucc, solde) EstProprio (nom*, noCompte*, dateS)

Instances de Compte c-100, Montcalm, 250.00 c-200,Desjardins, 350.00 c-300, Plateau, 450.00 c-400, Laurier, 550.00

Instances de Client Bérubé, des-roses, Québec Cousin, des-lilas, Lévis Vézina, des-saules, Montréal



6

Diagramme UML de classes avec une classe d’association Figure 4.1c

L’attribut dateS représente la date de validité de la signature d’un client pour le compte bancaire partagé entre plusieurs personnes.

Le schéma logique de la table EstProprio qui modélise l'association comprend la clé primaire de chaque classe UML participante et les attributs propres à l'association, c’est-à-dire ceux de la classe d’association. Il existe aussi des règles de transformation pour les autres structures utilisées dans les MCD. Elles seront étudiées avec plus de détails dans un chapitre subséquent.

Interprétation du modèle Le modèle relationnel représente parfois de façon approximative une certaine réalité organisationnelle. La sémantique du MRD est souvent précisée par une phrase qui interprète chaque association et chaque table. Par exemple la table Client dérivée du MCD de la figure 4.1 a une sémantique particulière : Un client nommé Jacques habite sur la rue des Lilas à Québec. Un client peut avoir plusieurs comptes dans une succursale bancaire et au moins un, peu importe la succursale. Un compte doit être la propriété d’une seule personne. Dans ce modèle très simple, le client est présumé être identifié sans équivoque par son nom, lequel joue le rôle de clé! Il est bien sûr possible de représenter une réalité plus complexe en changeant la définition des classes et des contraintes des associations du MCD et en multipliant les tables.

Conventions dʹécriture pour la relation et son extension Nous conviendrons d'une notation particulière pour désigner une relation du MRD et une autre pour référer à son extension, c’est-à-dire à son contenu : a) Lorsqu’il y a référence à une relation (ou table), le nom commence par une majuscule ou est entièrement en majuscules. Si la référence est faite à son extension, le nom de celle-ci commence par une minuscule ou est entièrement en lettres minuscules. De façon générale, l'extension de la relation R est notée par r(R), tandis que son schéma relationnel est noté R. On peut en pratique utiliser indifféremment dans les expressions soit le schéma Client, soit son extension client. Dans les deux cas, le système réfère aux données de la table. b) Les attributs de la clé primaire sont marqués par un astérisque ou soulignés. Les attributs de la

clé primaire sont regroupés de préférence au début de la table. c) Le type des attributs - exemples : numérique, chaîne de caractères et date - n'est pas obligatoirement précisé dans le modèle relationnel (logique). Il devra l’être cependant lors de la création de chaque relation. Il est parfois utile d’ajouter le domaine de chaque attribut dans le MRD.

Client nom* rue ville

Compte noCompte* nomSucc solde

1..* 1..*

dateS EstProprio



7

Par exemple, le MCD de la figure 4.1 est implémenté par les deux tables ci-dessous dans lesquelles les clés sont respectivement nom et noCompte. Voici deux extensions relationnelles valides de ce modèle : Client : Compte :

nom* rue ville noCompte* nomSucc solde nom Bérubé des-roses Québec c-100 Montcalm 250.00 BérubéCousin des-lilas Lévis c-200 Desjardins 350.00 CousinVézina des-saules Montréal c-300 Plateau 450.00 Vézina c-400 Laurier 550.00 Vézina Figure 4.2 L’extension de Compte (pouvant être notée compte) regroupe dans cet exemple quatre tuples valides de la table. L’extension d’une table est dynamique et varie donc dans le temps selon les mises à jour effectuées par les différentes applications autorisées à exploiter la base de données. L’en-tête de la table est le schéma de la relation et est défini par le nom de la table et les attributs. Les tuples constituent son extension dont le nom débute par une lettre minuscule.

Relation unique pour un MRD Pourquoi alors ne pas représenter toute l'information sur les clients et les comptes bancaires par une seule table au lieu de deux comme cela est préposé par les règles de transposition ? Une telle approche éviterait une multiplication des tables et partant, allégerait le calcul de certaines réponses qui exigent la consultation de deux ou de plusieurs tables. Par exemple, à la figure 4.3, on a l'extension de la relation CompteClient qui contient toute l'information des deux tables précédentes. La réponse à une question du genre trouver le nom et le solde d'un client est alors obtenue par la consultation d'une seule table, soit CompteClient. CompteClient : nom* rue ville noCompte* solde nomSucc Bérubé des-roses Québec c100 250.00 Montcalm Cousin des-lilas Lévis c200 350.00 Desjardins --> Vézina des-saules Montréal c300 450.00 Plateau --> Vézina des-saules Montréal c400 550.00 Laurier Figure 4.3 Par contre, avec cette relation, le fait que la cliente Vézina ait deux comptes bancaires à des succursales différentes est représenté par deux tuples. Du même coup, il y a redondance pour les valeurs des attributs non primaires, rue et ville du client. Cette redondance peut devenir importante avec la croissance du schéma de la table et/ou l'augmentation de la taille de l'extension. Elle est une source d'erreurs en cas d'une mise à jour incomplète. En effet, la mise à jour d'une table est précédée par une recherche dont le prédicat peut être formulé de manière à ne pas retrouver tous les tuples correspondant aux comptes de Vézina. Ainsi, lorsque la propriétaire du compte c300 change d’adresse et que cette modification n’est enregistrée par l'application que pour ce compte, il en résulte que Vézina aura deux adresses différentes dans la base, et cela même si ce n’est pas le cas dans la réalité. La base est donc devenue incohérente. Par exemple, l'application ci-dessous effectue une telle mise à jour partielle de la table CompteClient pour modifier l’adresse de Vézina propriétaire du compte bancaire c300 : {Ouvrir CompteClient; noCompte = 'c300';



8

nom = ' Vézina'; -- recherche par la clé 'Vézina + c300' Lire un tuple t dans CompteClient ; Tant que ( t.nom != 'Vézina' et t.noCompte != 'c300') Lire un tuple t dans l’extension de CompteClient; fin ; t.adresse = 'Berry'; -- mise à jour d’un tuple fin } Pour éviter une mise à jour partielle de la table, et pour simplifier la programmation des applications, il suffit d'avoir deux relations plutôt qu’une seule. Ainsi, l'adresse de chaque client n’apparaîtra que dans un seul tuple qui sera celui maintenu à jour par l'application. En poussant le raisonnement à sa limite, nous pourrions demander pourquoi ne pas avoir que des relations binaires ? Par exemple, chaque attribut de Client faisant l'objet d'une relation : ClientRue (nom*, rue) ClientVille (nom*, ville) . . . De toute évidence, la modélisation relationnelle avec seulement des relations binaires multiplie le nombre de relations à consulter dans le calcul d'une réponse. Par exemple, pour obtenir toute l’information sur un client, il faudra consulter autant de tables qu’il y a d’attributs le caractérisant. Cette multiplication des lectures aura donc un effet négatif sur la performance du logiciel SGBD et sur la complexité de l’application. D’autre part, il suffit d’imaginer une base opérationnelle ayant par exemple une table nommée Assurance définie par 20 attributs. Il est inconcevable de faire près de 20 relations lorsque quelques unes suffisent pour représenter correctement le contrat d’assurance de chaque client. Certaines relations sont donc préférables (ce sont les formes dites normales) à d’autres parce qu’elles ont une structure qui bloque certaines anomalies potentielles pouvant apparaître en cours d'exploitation et mettre en péril l'intégrité de la base. Ces relations dites normales constituent le schéma optimal de la base. Nous verrons dans une autre section sur les formes normales comment vérifier qu’une table est en forme normale et comment la transformer au besoin. Dans certains cas, la recherche des formes normales aboutit à une multiplication des relations qui alourdit le traitement subséquent. Dans la conception d’une base, il faudra faire la part des choses entre la cohérence et l’efficacité. Nous discuterons de cet aspect plus loin dans ce chapitre en abordant la question de la dénormalisation.

Domaines des attributs : sémantique et syntaxique Chaque attribut d’une relation peut avoir un domaine sémantique propre, défini comme l’ensemble des valeurs atomiques (i.e. scalaires) admissibles pour valuer cet attribut (to value an attribute signifie lui assigner une valeur). Deux attributs ayant des libellés différents peuvent cependant partager le même domaine sémantique. Ils sont alors considérés compatibles. Par exemple, le schéma de la table Menage ci-dessous est défini avec deux attributs, le premier est le nas du conjoint et l'autre celui de la conjointe. Les deux attributs partagent le même domaine, soit d-nas. Le schéma peut être formulé ainsi : Menage (conjoint*:d_nas, conjointe*:d_nas)



9

Les deux attributs primaires de cette table Menage partagent le même domaine, d-nas quelle que soit la définition explicite que l’on puisse donner à ce domaine. Les valeurs d’un domaine partageront un même type. Par contre, il peut arriver dans certains schémas que deux attributs de même libellé aient un domaine sémantique différent. Cette situation peut engendrer des problèmes d’ambiguïté qu’il faudra savoir résoudre au moment de l’exploitation. L’extension r d’une relation R sera toujours un sous-ensemble du produit cartésien du domaine des attributs : r ⊆ d1 x d2 x d3 x ... di Le domaine exclut la valeur nulle qui représente l’absence d’une valeur. Celle-ci, qui est une réalité lors de l’implantation, devra être traitée de façon particulière et systématique par le SGBD. Comme un attribut ne peut pas être comparé à une valeur nulle (qui est hors domaine), il faudra représenter cette valeur particulière (le null) par un code interne nommé indicateur d’absence de valeur. Ce dernier ne pourra être testé que par un prédicat spécial, le IS NULL. Souvent par abus de langage, cet indicateur est aussi appelé une valeur nulle ou null ! Cette dernière est hors du domaine.

Domaine syntaxique Lorsque le domaine sémantique ne peut pas être spécifié par un ensemble de valeurs (ex. les noms de client n’étant pas tous connus à priori), il est remplacé par le domaine syntaxique qui correspond aux valeurs autorisées par le type des données du domaine. Ex. nom est une chaîne de caractères de type VARCHAR2(50). Toute chaîne de caractères dont la longueur est égale ou inférieure à 50 sera considérée comme une valeur du domaine nom, même s’il est peu réaliste. Par exemple, la chaîne ‘ABCDEF’ est une valeur autorisée ! Le domaine syntaxique d’un attribut est formalisé au moment de la création du schéma d’une relation : Create table Client ( nas Number (8,0), nom VARCHAR2(50); <--toute chaîne de 50 car.ou moins est valide) Cette commande SQL-DDL Create table lance la création d’une structure de table qui servira par la suite pour ranger des données. Les métadonnées (le schéma) qui définissent cette structure sont logées dans le dictionnaire du SGBD. Au plan logique, la table Client est composée de deux colonnes libellées respectivement nas et nom. Les données qui peuvent être rangées dans chaque colonne sont assujetties éventuellement aux contraintes imposées par le domaine de chaque attribut. Par exemple, il n’est pas possible de ranger un nom dépassant les 50 caractères ou d’y ranger un nas qui est une chaîne de caractères. Plusieurs attributs peuvent partager le même domaine et ses contraintes. Pour faciliter l’écriture de ces domaines, il est possible de créer un domaine nommé. La commande SQL-92 CREATE DOMAIN permet de définir à la fois les domaines syntaxique et sémantique : - domaine syntaxique : CREATE DOMAIN d_nom Varchar2(50); --d_nom est le nom du domaine syntaxique - domaine sémantique (numérique dans cet exemple) : CREATE DOMAIN d_solde Number(8,2) CHECK (solde >0 and solde < = 10000.00);



10

Le domaine d’un attribut est alors spécifié en faisant référence au nom d’un domaine prédéfini. Create table Client ( nas number (8,0), nom varchar(45) not null, solde d_solde) ; <- référence au domaine nommé d_solde L’obligation pour un attribut de respecter son domaine est une contrainte d’attribut spécifiée au niveau du schéma. Dans le cas d'une contrainte impliquant plusieurs attributs d’une même relation, elle est formulée de préférence par une clause de contrainte de table. Dans certains cas, elle peut être renforcée par une procédure lancée automatiquement par le serveur SGBD à chaque fois qu'un des attributs est modifié (vérification par trigger). La définition du domaine sémantique est aussi possible au niveau du schéma. Par exemple, l’attribut solde précise que la valeur du solde bancaire d’un client doit toujours être positif : Create table Client ( nas number (8,0), nom VARCHAR2(50), solde Number(8,2)CONSTRAINT c_Compte CHECK(solde > 0)); Une contrainte un peu plus complexe peut être formulée au niveau de la table, exigeant que tout ajout ou toute modification du solde d’un client puisse devenir négatif avec une marge de 1000.00 seulement pour les clients de la succursale Montcalm. Dans les autres cas, le solde doit être positif. Create table noSucc Number(5), nomSucc Varchar2(45) not null, solde Number(8,2) not null, CONSTRAINT c_soldeCompte CHECK(solde>= 0 OR (solde>= -1000.00 and nomSucc = ‘Montcalm’)); Cette contrainte a un caractère sémantique, puisque les valeurs admissibles définies par le prédicat fixent le niveau plancher du solde d’un compte pour les succursales bancaires tout en permettant par le OR logique que le solde soit déficitaire de 1000.00 pour la succursale Montcalm. Avec SQL-92, la contrainte d’attribut peut être formulée avec un CHECK() faisant référence aux attributs d’une autre table de la base. Cette nouvelle fonctionnalité du langage de définition des tables ajoute de la souplesse, mais alourdit aussi le travail à effectuer par le moteur SGBD qui doit accéder à plusieurs autres tables pour vérifier la contrainte d’attribut à chaque fois qu’une modification est réalisée sur la table.

Métafonctions spéciales Pour faciliter la description et l'étude du modèle relationnel, deux métafonctions sont définies : a) une métafonction dom() pour fournir les valeurs du domaine. Par exemple, on aura : dom(d2) = {v1, v2, v3, ...}, c’est-à-dire les valeurs du domaine d2;



11

b) une métafonction [ ], appelée projection de tuple. Elle fournit la valeur de l'argument pour un tuple courant désigné par la variable tuple t . Il est possible de parcourir l'extension d'une table en variant le tuple désigné par t. La métafonction pourrait être notée ainsi : [ ] (t , attributi). En pratique, on adopte la convention d’écriture suivante pour désigner la valeur de l'attributi du tuple courant t : t [attributi] = valeurj ∈ dom(attributi) Par exemple, la valeur de l’attribut ville du tuple courant t est donnée par l'expression suivante: 'Québec' = t [ville] et non par 'Québec' = [ ] (t, ville) . Souvent, la valeur obtenue de la fonction sera comparée à une constante par l’expression t [ville] = 'Québec' Cette métafonction sera utile dans l'étude des opérateurs relationnels. En résumé, t[A] est une fonction qui retourne la valeur de A pour le tuple courant désigné par la variable de tuple t.

Schéma logique d’une relation Le schéma logique de la relation Rk est l’ensemble sk formé des attributs de la relation Rk dans laquelle chaque attribut est associé à un domaine, de préférence sémantique. Très souvent cependant le SGBD permet une référence au seul domaine syntaxique et la vérification de l’appartenance d’une valeur au domaine sémantique d’un attribut est effectuée par le biais du typage ou par une procédure spéciale appelée déclencheur (trigger), laquelle est programmée par l'administrateur de la base.

Modèle logique de la base de données Un modèle logique est formé de l’ensemble S des schémas relationnels sk : S = {s1, s2, ... sk}. Par exemple, la base de données Dotation est définie par l’ensemble des schémas logiques des relations qui composent cette base. Souvent dans la théorie, le domaine n’est pas explicitement associé à l’attribut pour alléger la représentation. Dans un tel cas, deux attributs avec le même libellé sont présumés avoir le même domaine sémantique. Par exemple les deux formulations ci-dessous de la même relation Job sont équivalentes. La base Dotation : Employe(matricule*, nas, nom, metier, noAtelier) Job(numero*, rubriqueJob) Assignation(matricule*, numero*, dateA) Deux formulations avec et sans le type des attributs : Job(numero*, rubriqueJob) Job(numero* Number(4,0), rubriqueJob varchar(50))

Relation de base Chaque relation du MRD est une relation de base, car elle est implémentée sur disque au moyen d’une structure physique et ses caractéristiques sont inscrites dans le dictionnaire. La clé des relations Employe et Job est monoattribut, tandis que celle de Assignation est composée de deux attributs. Ce MRD correspond aussi à un diagramme de classes que vous pouvez facilement établir en notant que la relation Assignation correspond à une classe d’association dans un diagramme de classe.



12

4.2 Dépendance fonctionnelle (‐‐>) Pour vérifier si le schéma d’une relation est acceptable dans une base, il faut avoir recours à la notion de forme normale qui est définie au moyen de la notion de dépendance fonctionnelle. Une dépendance fonctionnelle (notée DF) est définie entre un ou plusieurs attributs d'une même relation pour imposer une contrainte aux valeurs qui peuvent entrer dans la construction des tuples de l'extension. Il existe une dépendance entre l’attribut A et C dans R si à chaque fois que la valeur a1 pour A apparaît dans un tuple, on y retrouve aussi la valeur c5 pour C. On dit alors que l’attribut A détermine l’attribut C. Cette contrainte de dépendance est notée A --> C. Une clé dans une extension identifie un seul tuple de l'extension, de sorte qu’une valeur donnée de son domaine apparaît que dans un seul tuple de l’extension. On dit aussi que la clé détermine tous les attributs de la relation. Par exemple, l’analyse informatique a permis de formuler le schéma de la table Employe et des DF ci-dessous : Employe (matricule*, nas, nom, age, metier, noAtelier) L’ensemble des dépendances fonctionnelles F valides est le suivant : {matricule --> nas, nom, age, metier, noAtelier ; -- La définition de la clée sous-tend la DF suivante : nas --> matricule, nom, age, noAtelier; noAtelier --> metier }. L'ensemble F regroupe toutes les DF valides dans la relation Employe. La première DF se lit ainsi : le matricule détermine les attributs nas, nom, metier, noAtelier, i.e. tous les attributs du schéma de la relation. En d'autres mots, lorsqu'une valeur du matricule apparaît dans l'extension, la valeur des autres attributs composant la partie droite de la DF est aussi fixée pour toute l'extension, peu importe le temps et le tuple. Il faut aussi noter qu'une DF peut être formulée avec des attributs non primaires, c’est-à-dire qui n’entrent pas dans la composition de la clé primaire ou d’une clé candidate. Si une DF existe entre deux attributs non primaires (noAtelier --> metier), elle représente la contrainte suivante : dans un atelier donné, il y a que des ouvriers pratiquant un seul et même métier. Cette dépendance fonctionnelle est donc l'expression d'une contrainte sur l'extension de la relation qui est bien sûr justifiée par la réalité à modéliser. Dans la relation formelle R(A*, B, C ), la clé est définie comme étant l'attribut A. Elle définit de ce fait la DF A --> B, C. La réalité pourrait aussi imposer une DF entre B et C dans R, comme celle-ci : B --> C. Cette dernière DF est vérifiée si pour toute paire de tuples ti et tj de r, c’est-à-dire les tuples de rang i et celui de rang j, la proposition suivante est vraie : si ti[B] = tj[B], alors ti[C] = tj[C] -- définition de la DF avec les indices variables i et j Par exemple, cette DF est vérifiée dans l'extension ci-dessous. Les tuples 1 et 4 vérifient la DF formulée entre B et C et de plus, aucun tuple de l'extension ne doit contredire cette DF. Qu’en est-il pour les tuples de rang 1 et 2 ? La DF est aussi vérifiée, car la partie gauche étant fausse, la proposition qui définit la DF est vraie quelle soit la valeur de vérité de la partie droite. F = { A--> B, C; B--> C}



13

r : A B C rang du tuple --> 1 a1 b2 c3 ** 2 a2 b5 c3 3 a5 b4 c4 4 a1 b2 c3 **

Dans cette extension, lorsque deux valeurs des attributs du déterminant (partie gauche de la DF) coïncident dans deux tuples différents (**), les valeurs déterminées (partie droite) coïncident obligatoirement. Dans l’exemple ci-dessus, un des deux tuple est redondant puisqu’il a les mêmes valeurs. La DF est similaire à une implication logique; elle n'est cependant pas une équivalence logique. On ne peut pas déduire d'une DF valide que son inverse est aussi valide. Elle peut être invalidée dans une extension; elle est alors notée C -/-> B.

Déterminant, déterminé et dépendance fonctionnelle élémentaire Les attributs de la partie gauche d'une DF forment le déterminant, tandis que ceux de la partie droite constituent le déterminé. Dans la relation Employe, la DF matricule --> metier est une DF formée du déterminant matricule et du déterminé metier. Lorsque le déterminé (membre droit) est composé d’un seul attribut, la DF est dite élémentaire; elle est notée df. Toute DF peut être transformée en un ensemble équivalent de dépendances élémentaires.

Dépendance fonctionnelle et analyse informatique En termes d'analyse, la dépendance fonctionnelle traduit une partie de la sémantique des données du système d'information qui est formalisé par l'analyste. La DF n'est pas suffisante cependant pour représenter toute la sémantique des données. Par exemple, si l'analyste remarque qu'une assignation de travail dans la relation Assignation est complètement identifiée par la combinaison des valeurs (matricule, numéro), cela signifie aussi qu'une assignation particulière sera faite à une seule date. Cette information sur les données est formulée par la DF suivante qui est valide dans la relation Assignation : matricule, numero -> date De même, si le système d'information exclut la représentation d'un employé qui a deux métiers, l'analyste formulera cette contrainte par la DF suivante : matricule --> metier. Cependant, le fait qu'un employé ne puisse pas être assigné à plus de trois jobs n'est pas spécifié par une DF. Il faudra implémenter une contrainte de multiplicité (cardinalité) au niveau de la relation pour renforcer cette limite dans la BD. Une DF est valide dans une table dans la mesure où tous les attributs de celle-ci, déterminant et déterminé sont dans son schéma. Si un attribut est absent, la DF n’est pas valide dans la table, mais demeure valide dans la base.

Dépendance fonctionnelle triviale Une dépendance fonctionnelle dont le déterminé (partie droite) est inclus dans le déterminant (partie gauche) est dite une dépendance fonctionnelle triviale.

Dépendance fonctionnelle totale ( =>) Il y a une dépendance fonctionnelle totale (DFT) entre les ensembles d'attributs X et Y de la relation R, notée X=>Y, s'il n'existe pas un sous-ensemble propre de X qui détermine Y. Formellement, si un attribut quelconque de X est enlevé, la dépendance fonctionnelle résiduelle avec Y n'est plus vérifiée : X - {A} -/->Y. La négation d'une DFT se formule ainsi : X =/=> Y. Par exemple, la clé d'une relation détermine totalement tous les attributs de la relation. En effet, en supprimant un attribut de la clé composée d'une relation, l'ensemble obtenu ne détermine plus tous les autres attributs du schéma.



14

Exemple: ProduitLivre(noMateriau*, noFournisseur*, prix, categorie) Un fournisseur peut livrer différents matériaux à divers prix et un matériau peut être fourni par divers fournisseurs et à divers prix. Cependant un fournisseur ne peut livrer un même matériau qu'à un seul prix, peu importe la catégorie. Il en découle que la clé doit être composée des attributs (noMateriau et noFournisseur). Dans ce cas, les attributs déterminent totalement tous les attributs de la relation ProduitLivre. C'est la clé au sens du relationnel. (noMateriau, noFournisseur) => prix, categorie Cette dernière DF peut être formulée d'une façon équivalente en divisant le déterminé de la DF pour former autant de DF élémentaires qu'il y a d'attributs dans le déterminé : noMateriau, noFournisseur ==> prix et noMateriau, noFournisseur ==> categorie DFT :{noMateriau, noFournisseur} ==> {prix, categorie } Ces dépendances peuvent être notées avec la notation utilisée dans les livres de C. Date : Figure 4.4a Les dépendances fonctionnelles élémentaires obtenues sont équivalentes à la DF ayant un déterminé composé. En effet, il n'y a pas de sous-ensemble de la clé qui détermine prix et catégorie, il faut en conclure que les DFT ci-dessus sont vérifiées. En effet, si l'attribut noFournisseur est enlevé du déterminant, on n’a alors plus que noMateriau -/-> prix. Finalement, toute DFT est une DF, mais l'inverse n'est pas vrai. Si une partie de la clé, soit le noMateriau, soit le noFournisseur, déterminait tous les attributs non primaires de la relation ProduitLivre, la DFT ne serait pas vérifiée.

4.3 Clé de relation Chaque relation de base du modèle relationnel a obligatoirement une clé et parfois plusieurs. Une clé est définie pour avoir certaines propriétés particulières décrites ci-dessous. La clé garantit que chaque tuple de l’extension est unique à tout moment. En d'autres mots, elle assure qu'un même fait ou objet n'est représenté qu'une seule fois dans la relation. Il peut y avoir d'autres attributs ou ensembles d'attributs qui vérifient les mêmes propriétés de clé, mais un seul de ces ensembles sera choisi comme la clé dite primaire ou principale. Les autres seront dites des clés candidates. Les attributs qui composent une clé primaire ou candidate sont dits primaires.

Propriétés dʹune clé de relation La clé d’une table doit avoir trois propriétés essentielles : a) L’ensemble des attributs de la clé détermine tous les attributs du schéma de la relation. Cette propriété est notée ainsi : clé -> tuple de R, i.e. tous les attributs de R sont déterminés par la clé.

prix, categorie noMateriau, noFournisseur



15

b) La deuxième propriété stipule qu'il n’existe pas un sous-ensemble quelconque de la clé capable d’identifier de façon unique chaque tuple de la relation. La clé est donc minimale et correspond à une DFT entre la clé et tous les attributs du schéma. En d’autres mots, la DF suivante est fausse : (clé)’-/-> {tous les attributs de R} où (clé)’ signifie un sous-ensemble de l’ensemble des attributs de la clé. La négation signifie qu’un sous-ensemble de la clé ne détermine pas tous les attributs. S'il y a lieu, une clé est choisie parmi les clés candidates. Cette dernière sera appelée à jouer un rôle particulier tout en gardant son statut de clé candidate. Cette clé choisie devient alors la clé primaire ou principale de la relation. Sa définition dans une table permet d'implémenter la notion de clé étrangère dans une autre table qui y réfère. Sans la clé primaire, il ne peut pas y avoir une autre clé dite clé étrangère dans une autre relation. Comme nous le verrons plus loin cette clé étrangère permet de définir une contrainte d’intégrité référentielle entre deux relations. c) La clé d’une relation de base doit avoir une valeur pour chaque tuple de la relation. Aucun indicateur de l’absence d’une valeur (le null) n’est acceptable pour un attribut de la clé, c'est-à-dire un attribut primaire. Cette particularité ne s’applique pas obligatoirement aux relations intermédiaires et temporaires obtenues lors du calcul d'une réponse à une requête.

Superclé dʹune relation de base Une superclé d’une relation de base est un ensemble d’attributs (pas nécessairement minimal) qui vérifie la première propriété de la clé. Soit R le schéma d’une relation dont l’extension est r , alors K ⊆ R est une superclé si, pour deux tuples quelconques de l'extension r, soit ti et tj, on a que ti[K] ≠ tj[K]. Une clé est un cas particulier de la superclé puisqu’elle correspond à la plus petite superclé. En dépit du terme, toute superclé n'est pas une clé au sens propre parce qu’elle n’a pas toutes les propriétés d’une clé. La notion de superclé est utilisée dans les algorithmes de synthèse relationnelle, notamment dans celui bien connu de Bernstein. Exemple : Employe (matricule*, nas, nom, age, metier, noAtelier) Dans cet exemple, la clé primaire est composée du seul attribut matricule. Les ensembles {matricule, nom}, {matricule, metier} et {matricule, nom, metier} sont parmi d'autres, trois superclés de la relation Employe.

Clé candidate Une clé candidate est aussi une clé de relation, et à ce titre admissible comme clé primaire. Par exemple, les attributs nas et matricule dans la relation Employe sont deux clés candidates. Une d'entre elles sera choisie afin de jouer un rôle supplémentaire à savoir celui de la clé primaire (on dit aussi clé principale). Les deux demeurent cependant des clés candidates. Il y a une équivalence logique entre les clés candidates : nas <--> matricule. On peut aussi écrire : nas -> matricule et matricule -> nas . Les attributs d’une clé candidate sont aussi des attributs primaires (Codd, 1970).

Clé étrangère dans une relation Généralement, une clé étrangère est un ensemble d’attributs d'une relation lesquels forment obligatoirement une clé primaire ou candidate déclarée dans une autre relation de la même base de données. La relation qui renferme la clé primaire est dite parent, tandis que celle qui a la clé étrangère est qualifiée de relation enfant. La clé étrangère implémente en quelque sorte l'association entre deux classes du modèle conceptuel. C'est par ces attributs que deux tables



16

peuvent être jointes afin d'avoir accès aux données via leur association. Pour trouver les employés d’un département, il faut pouvoir explorer la table Employe et retenir ceux qui travaillent dans ce département. La clé étrangère permet d’effectuer rapidement cette recherche. C’est aussi par ce moyen qu’une contrainte dite référentielle est imposée aux tuples des tables parent et enfant. Un tuple enfant ne peut pas être ajouté dans une table si sa clé étrangère ne correspond pas à un tuple dans la table parent. Par exemple, dans le MRD suivant composé de deux relations : Employe(nas*, nom, ville, no) Departement(no*, site) L'attribut no de la relation Employe est une clé étrangère dans cette relation, puisque ce même attribut est une clé primaire déclarée dans la relation parent Departement. Plus formellement, un ensemble d’attributs {C, E} d’une relation R2 est une clé étrangère si l'ensemble {C, E} satisfait aux deux critères intemporels suivants : a) Chaque attribut de la clé étrangère {C, E} peut avoir valué par l’indicateur de null, sinon chacun a une valeur provenant de son domaine respectif; b) Il existe une relation de base R1 avec une clé primaire ou une clé candidate déclarée {A, B} dans laquelle chaque valeur non nulle de la clé étrangère {C, E} correspond à une valeur de la clé primaire de R1. Les attributs doivent partager respectivement le même domaine, même s'ils n'ont pas le même libellé dans le modèle logique. Exemple : Soit les relations R1 (C*, E*, G, H) et R2( J*, C, E ) avec {C, E} comme clé étrangère appariée avec la clé primaire {C, E} de la relation R1. Cette association est faite sur la base de l’identité des libellés pour les attributs des clés primaire et étrangère, C et E. Le fait d’avoir le même libellé implique qu’ils ont le même domaine. Toutefois, deux attributs, un de la clé étrangère et l’autre de la clé primaire pourraient avoir des libellés différents et le même domaine. La validation de la contrainte référentielle entre deux relations peut être techniquement réalisée de plusieurs façons selon le SGBD .

Spécification en SQL‐DDL du modèle relationnel Le modèle relationnel (logique) est défini comme un ensemble de relations (ou de tables) dont les extensions de la BD sont composées de tuples vérifiant les types et les contraintes spécifiées dans le schéma. Chaque extension de table est un sous-ensemble du produit cartésien du domaine des attributs de son schéma. La spécification du MRD par un langage de définition de données (DDL) particulier est appelée le schéma relationnel de la base. Ce schéma revêt des formes différentes d’un SGBD à l’autre, mais il est généralement une transposition formelle du modèle de données relationnel. Selon le système, le domaine sémantique peut être implémenté ou remplacé par le

nas* nom ville no

Employe

no* site

Contrainte référentielle déclarée

Departement



17

domaine syntaxique. On trouve ci-dessous un schéma relationnel du système MRDS spécifié avec son propre langage DDL différent du SQL-DDL courant. Déjà lors de cette implémentation par Honeywell-Bull, la notion de domaine était disponible au moyen du CHECK_Proc. A titre d'exemple, voici un schéma relationnel MRDS de la 1ère génération (1985) qui n'a rien à voir cependant avec les schémas relationnels plus récents spécifiés avec le SQL-DDL. Dans cet exemple, tous les schémas et les index sont définis dans un seul fichier et la notion de domaine syntaxique partageable est implémentée. En outre, une procédure peut être lancée pour vérifier le domaine sémantique, une contrainte d'attribut, voire même une contrainte logique complexe formulée avec plusieurs attributs d'une relation. Schéma relationnel du SGBD MRDS du système DPS/Multics /*schéma du modèle CodeRoute MRDS (multics/Unix CERT-Toulouse) */ /* Avec les domaines */ Domain : d_nom char(30) varying, d_code char(5) CHECK_proc >uud>317700>gamache>val_codes, /*pour valider la contrainte ref. sur code_infraction*/ d_vignette char(8), d_annee fixed dec (4,0), d_permis char(12), d_modele char(10), d_prix fixed dec (8,2), d_descrip char(100) varying, date char(6); /* Attributs et leur domaine respectif */ Attribute : nomP d_nom, codeInfract d_codes,-- notez la définition du domaine dateInfract d_annee, noVignette d_vignette, fabricant d_nom, annee d_annee, noPermis d_permis, description d_descrip /* Relations du modele */ Relation : infraction (nomP* codeInfract* dateInfract*), proprio (nomP* noPermis), descInfract (codeInfract* description), auto (noVignette* fabricant annee modele nomP), prixV (fabricant* annee* modele*); /* Index sur les attributs non primaires */ index:

proprio (noPermis), auto (fabricant modele); -- index avec une entrée composée

/* fin du schéma */



18

Le schéma ci-dessus utilise une procédure en langage PL/1. Cette procédure est exécutée à chaque mise à jour d’un attribut dont le domaine est d_codes. Ce mécanisme est une des premières implémentations des contraintes logiques, puisqu’elle permettait de consulter un fichier externe au SGBD pour valider la valeur d’un attribut en fonction de son domaine, ou encore de faire un calcul de validation complexe qui ne pouvait pas être formulée au niveau de la spécification de l’attribut du schéma.

Propriétés des relations de base Une relation de base est une relation définie et implémentée physiquement dans la base de données, tandis que toute autre relation intermédiaire générée par des opérations sur la table de base est dite temporaire. Toute relation de base a les propriétés suivantes : a) Chaque relation de base a obligatoirement une superclé formée, dans le pire des cas, avec tous les attributs du schéma. Une clé primaire est choisie parmi les clés candidates et, si elle est monoattribut, joue alors le rôle d'un identifiant. En théorie, il n'y a pas de doublets dans une extension de relation dotée d'une clé primaire déclarée et activée. b) Chaque attribut d'une clé primaire d’une relation de base doit être valué1 (i.e. instancié) et ne peut pas être sans valeur. Dans le reste du texte, lorsqu'on mentionne le mot relation seulement, cela fait référence à une relation de base. Les relations intermédiaires n’ont pas nécessairement une clé. c) Les attributs d'une relation de base sont associés à un domaine atomique (condition pour avoir la première forme normale). Cela veut dire que pour chaque ligne ou tuple, il y a seulement une valeur dans chaque colonne. Le domaine de chaque attribut est spécifié dans le dictionnaire de façon implicite ou explicite. Par exemple, spécifier que l'attribut nom est une chaîne de 25 caractères, définit implicitement le domaine syntaxique comme étant formé par toutes les chaînes, significatives ou non, d'au plus 25 caractères. d) L’ordre des tuples dans une extension n’est pas significatif et varie dans le temps. Cependant, l'ordre des valeurs dans un tuple est fixé selon l’ordre des attributs du schéma. Lors de l'ajout d'un tuple, les valeurs fournies devront respecter l'ordre imposé aux attributs dans la définition du schéma. Au niveau physique, les valeurs qui forment un tuple à ajouter sont aussi ordonnées conformément à l'ordre fixé par le schéma de la relation et chacune peut être référencée par son rang. Les tuples sont rangés dans une page physique et pas nécessairement de façon contiguë. e) Chaque tuple a une adresse interne unique connue sous le nom de ROWID (ROw IDentifier). Ce dernier constitue en principe un jeton identificateur unique dont la durée de vie est celle de la BD. Dans certains systèmes, par exemple le relationnel Oracle, le ROWID peut être modifié par le système lorsque dans une réorganisation, il y a déplacement d'un tuple vers la zone de débordement ou lorsque les tuples sont compactés à l’intérieur de la même page. Dans ce cas, le ROWID est une adresse logique rarement utilisée par les applications. Il ne peut donc pas être assimilé à un identificateur d’objet comme l'OID (Object Identifier) qui ne change pas de valeur au cours de son cycle de vie.

4.4 Contraintes dʹintégrité du modèle relationnel

1 Le mot valuation est un calque de l’anglais to value an attribute or a predicate. Il pourrait être vu comme un néologisme signifiant donner une valeur à

un attribut ou instancier un attribut.



19

Le modèle relationnel a plusieurs contraintes d’intégrité inhérentes. Rappelons qu’une contrainte d’intégrité est une assertion toujours vérifiée pour chaque attribut, chaque tuple, chaque table ou pour la base de données entière. Les principales contraintes inhérentes sont celles de la clé primaire et référentielle. La nature de l’assertion est fixée au préalable et est valide pour toute table pour laquelle elle est définie. Il y aussi les contraintes explicites définies sur les attributs, les tuples et les tables. Leur nature varie selon la formulation de l’assertion. Par exemple, une contrainte d'attribut associé à un domaine peut énoncer que le salaire annuel d'un employé a un type numérique et ne peut pas dépasser 75 000.00 $. Les contraintes permettent de déplacer certains contrôles de validation des applications vers le SGBD qui gère la BD. Cette migration du contrôle des données garantit une meilleure uniformité dans la vérification des contraintes. Il en découle une meilleure qualité pour les données de la base. Le moment du renforcement des contraintes peut varier; une contrainte peut être vérifiée immédiatement après l'exécution d'une clause d'insertion SQL-DML ou être reportée à la fin du traitement portant sur une ou plusieurs relations.

Contrainte de clé (unicité des tuples) Toute valeur d'une clé candidate identifie un et un seul tuple dans une extension de relation. La contrainte donne alors naissance à une dépendance de clé toujours vérifiée dans la relation. La clé peut être monoattribut ou composée de plusieurs attributs. Comme cela a été vu antérieurement, une clé définit une dépendance fonctionnelle sur tous les attributs de la relation. L’implémentation de la contrainte de clé varie d’un SGBD à l’autre. Elle peut être réalisée par une procédure interne au SGBD appelée déclencheur (trigger) qui vérifie l'unicité de la valeur de clé lors de toute modification apportée à l'extension d'une relation. Elle est généralement vérifiée par la création d'un index système qui exclut les doublets et les valeurs nulles pour les attributs primaires. Cette implémentation est automatique dès lors que la clé est formellement spécifiée dans le schéma (Oracle).

Contrainte d’entité (obligation d’avoir une valeur pour les attributs primaires) En règle générale, la clé primaire ou un de ses attributs ne peut pas être nul. Par conséquent, un tuple avec un indicateur NULL pour un attribut primaire ne peut pas être ajouté dans une extension d’une relation de base. C'est la contrainte d'entité. Par contre, une clé candidate peut être totalement ou partiellement valuée par l’indicateur NULL.

Contrainte d’unicité et de clé candidate La contrainte d’unicité définie sur un ensemble d’attributs interdit à deux tuples de l’extension d’avoir les mêmes valeurs pour ces attributs. L’unicité de l’attribut siteD est vérifiée par les six premiers tuples de la table Departement. La contrainte de clé candidate spécifie qu’il n’existe pas deux tuples de l’extension de R qui ont les mêmes valeurs du domaine pour les attributs de la clé candidate en excluant aussi tout indicateur d’absence de valeur, le NULL considéré non inclus dans le domaine. Un attribut déclaré UNIQUE peut être alors considéré comme une clé candidate si le NOT NULL est aussi spécifié.

departement : noD * nomD siteD 23 vente Lévis 34 R/D Québec 12 pub Montréal 11 finances null 14 siège-soc null + 9 distribution Lévis rejet du tuple



20

Figure 4.5 Dans l'exemple de la figure 4.5, les six premiers tuples respectent la contrainte d’unicité définie pour l’attribut siteD de Departement, et cela en dépit de la présence des indicateurs null (indicateur de l’absence d’une valeur). L’ajout du tuple (9, distribution, Lévis) est cependant impossible, car cette action viole la contrainte d’unicité définie pour l’attribut siteD. Toutefois, l’ajout du tuple (9, distribution, null) est possible, car ce nouveau tuple est réputé différent de ceux déjà dans la table. Cependant, toute mise à jour de ce tuple n’est pas acceptable. Par exemple, il est impossible de représenter le fait que le nouveau département de distribution soit localisé à Québec ! La contrainte d'unicité définie par UNIQUE sur l'attribut siteD exclut un deuxième tuple avec le siteD à Québec. Voici comment sont formulées la table Departement et toutes les contraintes au moyen du langage SQL-DDL : Create table Departement (

noD integer NOT NULL, nomD varchar2(35) NOT NULL, siteD varchar(10) NULL UNIQUE Check(site_d IN (‘Québec’, ‘Lévis’, ‘Montréal’)), CONSTRAINT cp_Departement Primary Key (no_d));

N.B. Chaque contrainte est identifiée par un nom de sorte qu’en cas d’erreur, le système fera une référence à ce nom de contrainte impliquée. Dans l’exemple ci-dessus, toute violation à la contrainte de l’unicité de la clé noD activera une erreur qui fera référence à la contrainte cp_Departement. La mise au point des clauses SQL-DDL est ainsi rendue plus facile.

Écriture différente des contraintes : niveau table La contrainte peut être aussi formulée au niveau de la table après celle des attributs puisqu’elle comprend le nom de l’attribut qu’elle contraint. Create table Departement (

noD integer NOT NULL, nomD varchar2(35) NOT NULL, siteD varchar(10) NULL UNIQUE, CONSTRAINT C_siteD Check(siteD IN (‘Québec’,‘Lévis’, ‘Montréal’));

Toutefois, si la contrainte d’unicité était définie différemment dans le schéma de la table pour inclure dorénavant les deux attributs, nomD et siteD, serait-il alors possible d’ajouter le tuple (9, distribution, Lévis) ? Le tuple pourrait être ajouté car la combinaison de valeurs (distribution, Lévis) est unique et vérifie la contrainte UNIQUE formulée différemment au niveau de la table et non plus au niveau de l'attribut. Create table Departement (

noD number(4,0) NOT NULL, nomD varchar2(35) NOT NULL, siteD varchar(10) NULL, Constraint u_nom_site UNIQUE(nomD,siteD), Constraint cp_Departement (noD) primary key));



21

Pour ce qui est de l'implémentation, cette contrainte est souvent réalisée par la création automatique d’un index de système avec une entrée unique pour les attributs spécifiés dans la contrainte. Les indicateurs null ne sont pas indexés, mais ils sont généralement tolérés dans une table pour certains attributs. Les nouvelles versions des SGBD renforcent de plus en plus cette contrainte en interdisant les valeurs nulles y compris pour un attribut déclaré UNIQUE. Cet attribut devient alors une clé candidate. C'est le cas de la version 8 du SGBD Oracle.

Contrainte référentielle Toute clé étrangère (simple ou composée) dans une relation sous-tend une contrainte référentielle imposée aux tuples de la relation qui la contient, à savoir qu'un tuple ajouté correspond obligatoirement à un tuple dans une autre relation où les mêmes attributs de la clé étrangère constituent une clé primaire déclarée dans le schéma . C'est une contrainte du genre interrelation. Par exemple, la clé primaire de la table Specialite est constituée de la paire d'attributs (noSpecialite, classe) qui est aussi une clé étrangère dans la relation Atelier. Le couple clé primaire et clé étrangère partage obligatoirement le même domaine. Specialite (noSpecialite*, classe*, description, syndicat) Atelier (noAtelier*, chef, site, capital, debit, noSpecialite, classe)

Diagramme de contraintes référentielles (CR) Il peut y avoir plusieurs contraintes référentielles dans un modèle. Elles sont représentées par un diagramme ou graphe fléché qui relie la classe qui contient la clé étrangère (dite enfant) vers celle qui a une clé primaire correspondante (dite parent). Figure 4.5a Dans ce diagramme, il y a absence de tout cycle ce qui signifie que l'ajout de tuples dans la relation parent peut se faire librement, mais que tout ajout dans la relation enfant doit obligatoirement vérifier la contrainte de clé étrangère (CR). De même, une suppression dans la table enfant est toujours possible, mais pas dans la table parent et cela aussi longtemps qu’un tuple enfant y réfère. La présence d'un cycle pour les CR indiquerait que l'ajout de tuples dans une des relations du cycle pose éventuellement un problème de vérification récursive des contraintes référentielles. En effet, pour réussir à ajouter un atelier ayant une spécialité, il faut que la spécialité existe déjà dans la base. Or, en cas de cycle dans le diagramme, cette spécialité n’existe que si un atelier en fait la sienne! Il faut briser le cycle en supprimant la CR de la table Specialite vers Atelier pour sortir de cette impasse.

table enfant

noSpecialite* classe* description …

noAtelier* noSpecialite classe Atelier :

table parent Specialite :



22

Une contrainte référentielle comporte deux parties : 1- les règles de validation 2- les actions référentielles. Nous verrons un peu plus loin les différentes actions référentielles possibles, sans se limiter à celles implémentées dans un SGBD particulier.

Implémentation de la contrainte référentielle La condition essentielle pour que cette contrainte référentielle soit implémentée est que la clé primaire ou une clé candidate de la relation parent soit déclarée dans le schéma, et non pas seulement comme étant NOT NULL. De plus, cette contrainte fait appel à une fonction d’appariement qui détermine s’il y a ou non violation de la contrainte. Le niveau d'implémentation de cette contrainte par rapport à la norme SQL varie d'un système à l'autre, notamment en ce qui a trait aux actions référentielles. En SQL-92 (avec le niveau full level ou implémentation complète), l’appariement (match) entre la clé primaire et la clé étrangère, qui définit en quelque sorte la règle de vérification de la contrainte référentielle, est spécifié de plusieurs façons.

Règles d’appariement ou de vérification de la contrainte référentielle a) Appariement complet (FULL) : L’égalité des valeurs avec la table parent est obligatoire et la présence de l’indicateur NULL pour un sous-ensemble de la clé étrangère est exclue. Cependant, la clé étrangère peut être entièrement composée d’indicateurs NULL. C'est une implémentation complète de la contrainte étrangère. Si la clé étrangère entièrement formée qu’avec des indicateurs NULL est par la suite mise à jour, la contrainte sera à ce moment vérifiée à nouveau par le SGBD. Voici les clés étrangères dans l'extension de la figure 4.5b pour un appariement complet : - clés étrangères possibles : {'s9', 'c2'} , {null, null} - clés étrangères interdites : {null, 'c2'} , {'s9', null} b) Appariement partiel (PARTIAL) : L’indicateur NULL est permis pour un sous-ensemble des attributs de la clé étrangère seulement si les autres attributs non nuls sont appariés avec une valeur d'un attribut de la clé primaire de la table parent. Elle tolère aussi une clé entièrement formée avec l’indicateur NULL. C'est une implémentation partielle limitée à la vérification de la sous-clé étrangère non nulle. Par exemple, dans la BD de la figure 4.5b, les clés étrangères possibles et non acceptées pour la relation Atelier sont les suivantes : - Clés étrangères possibles : {'s9', 'c2'} , {null, null}, {null, 'c2'} - Clés étrangères interdites : {'s9', 'c4'} et {'s1', null} c) Absence d'appariement (VIDE) : L'absence de la clause d'appariement (match) implique que l’indicateur NULL est accepté pour quelques-uns ou encore pour tous les attributs de la clé étrangère sans l'obligation pour les attributs non nuls de correspondre à des valeurs dans un tuple de la table parent. La vérification est reportée au moment où tous les attributs de la clé étrangère auront une valeur, suite à une ou plusieurs mises à jour. Clés étrangères possibles : {'s9', 'c2'} , {null, 'c5'} , {'s8', null} et {null, null} Avec une clé étrangère formée qu’avec les indicateurs NULL, (entendre par cela que la valeur est inconnue mais existante), la contrainte est réputée potentiellement vérifiable et le tuple peut être ajouté immédiatement dans la table.



23

Dans la figure 4.5b, si l’appariement est partiel pour la table Atelier, le dernier tuple ajouté (235) ne viole pas la contrainte référentielle en raison de la valeur nulle. Cependant, la classe c4 du tuple doit être comprise parmi les valeurs d’un attribut de la clé primaire de la table Specialite. La mise à jour subséquente du tuple de l'atelier 235 pour lui donner un numéro de spécialité soit 's5', sera refusée puisque la contrainte référentielle n'est pas vérifiée par cette modification. (Relation parent)

specialite : noSpecialite* classe* description syndicat s10 c4 fraiseur csn s9 c2 ajusteur ftq

(Relation enfant)

atelier: noAtelier* chef site capital debit noSpecialite classe 234 lyse Québec 20K$ 50 s9 c2 + --> 235 paul Montréal 45K$ 39 -- (ou null) c4

Figure 4.5b Il faut remarquer que les attributs communs entre deux ou plusieurs tables n'exigent pas la définition d'une contrainte référentielle (CR) pour que le traitement des données impliquant les deux tables soit possible. Toutefois, la définition de la contrainte référentielle accélère cette opération en imposant l’existence d'un index système sur la clé primaire de la relation parent. C’est la raison de l’exigence que la table parent ait une clé primaire ou une clé candidate déclarée. N.B. La clause MATCH FULL est proposée par la norme SQL-92 comme spécification supplémentaire à la contrainte référentielle de base. Elle n'est pas nécessairement implémentée dans les SGBD courants. Voici un énoncé DDL du SQL-92 pour effectuer la création de la table Atelier : CREATE TABLE Atelier ( noAtelier integer NOT NULL, chef varchar2(40) NOT NULL, capital number(8,2) CONSTRAINT c_capital CHECK (capital<1000000.00), debit number CHECK (debit < 150), noSpecialite char(4), classe char(4), CONSTRAINT cp_atelier Primary key (no_atelier), CONSTRAINT FK_AtelierSpecialite FOREIGN KEY (noSpecialite, classe) REFERENCES Specialite(noSpecialite, classe) ON DELETE CASCADE ); La clause ON DELETE CASCADE dans la table enfant est une action référentielle qui précise l'impact de la suppression d’un tuple dans la table parent. Cette suppression peut entraîner celle de tous les tuples de la table enfant qui lui sont associés par la clé étrangère (ON DELETE CASCADE). D'autres comportements référentiels sont possibles à savoir refuser la suppression du tuple parent ou accepter la suppression en mettant la clé étrangère des tuples enfants à NULL. Cette dernière



24

action référentielle (ON DELETE SET NULL) correspond au renforcement de la contrainte de participation partielle des objets de la table enfant définie dans le MCD par la multiplicité 0..* de l’association.

Ordre de création des tables imposé par la contrainte référentielle Lors de la création des tables, il faut créer en premier les tables qui ont uniquement le rôle de parent (table référée) et ensuite les tables enfants qui réfèrent aux tables parents créées. Les tables qui sont à la fois parent et enfant sont créées avant la création des tables enfant. La suppression des tables est faite selon l'ordre inverse. La validation lors de la création d'une table qui réfère à une autre table suppose que cette dernière soit déjà créée dans le dictionnaire. Une référence ombrée, i.e. à une table non encore créée, est interdite dans les SGBD relationnels, mais est permise dans certains SGBD orientés essentiellement objet comme le système O2 (IBM et O2 Technology).

Désactivation des contraintes de clé et validation rétroactive Les contraintes de clé peuvent être désactivées et réactivées par le DBA qui a les droits nécessaires pour le faire. S'il y a lieu, la clé étrangère doit être désactivée en premier, ensuite la clé primaire correspondante. Comme nous l’avons vu précédemment, il doit en être ainsi puisque la clé primaire est une condition préalable pour l’établissement d’une contrainte référentielle. ALTER TABLE Atelier DISABLE constraint fk_specialite; - (désactivation de la clé étrangère de la table enfant) ALTER TABLE Atelier DISABLE constraint cp_atelier; -(désactivation de la clé primaire de la table parent) Après la désactivation, la contrainte référentielle n’est plus vérifiée lors de modifications des tables parent et enfant. Cela permet, par exemple, un chargement en vrac des données réputées validées. Lors de la réactivation de la contrainte, les données déjà chargées sont vérifiées. Il y a donc un effet rétroactif associé à la contrainte référentielle. Il en sera ainsi pour la contrainte de clé primaire. ALTER TABLE Atelier ENABLE constraint fk_specialite; ALTER TABLE Atelier ENABLE constraint cp_atelier; Contrainte référentielle de type intrarelation (auto-référentielle) Si une table a une contrainte référentielle intrarelation (self-referencing constraint), l’insertion des tuples peut entraîner quelques problèmes si l’opération ne suit pas un protocole particulier. Dans l'exemple ci-dessous, un chef est aussi un employé. La même table est à la fois parent et enfant. Ce MRD correspond à un MCD avec une association réflexive. Personnel (noEmpl*,adresse, noChef) Le schéma logique de la même table peut être aussi écrit avec un domaine pour chaque attribut : Personnel (noEmpl*: d_empl, noChef :d_empl) Cette deuxième notation a le mérite de bien souligner que les deux attributs, noEmpl et noChef partagent le même domaine qui est une condition essentielle pour définir une contrainte référentielle.



25

personnel : noEmpl* adresse noChef - 890 7 rue Rose NULL 250 25 rue Jaune 890 + 990 8 rue Rouge 890 + 999 25 rue Brune NULL

Une contrainte référentielle est définie entre les attributs noChef et noEmpl. Chaque employé a normalement un chef qui doit être aussi un employé. L’insertion d’un tuple pour représenter le chef qui n'a pas de chef ne pose pas de problème puisque la contrainte référentielle le permet (clé étrangère autorisant l’indicateur NULL). Ainsi l'ajout du tuple (990, ‘8 rue Rouge’, NULL) est possible. L'ajout d'un autre tuple, par exemple (250, ‘16 rue Jaune’, 890), sera soumis à la contrainte référentielle normale et finalement ajouté à l’extension. Toute tentative de donner un chef à l’employé 890 par une mise à jour qui changerait le NULL pour le chef 999 serait un échec puisque cet employé 999 n’est pas représenté dans la base. Il faudra ajouter en premier le chef dont le numéro est 999 avant d'y faire référence comme chef de l’employé. La suppression des tuples dans la table parent se fera conformément à l’action référentielle définie dans le schéma de la table enfant. Si l’action référentielle de la table Personnel (qui est à la fois enfant et parent) est du genre ON DELETE CASCADE, la suppression du tuple (890, ‘7 rue Rose’, NULL) va entraîner la suppression de ou des tuples qui y réfèrent par la clé étrangère. Dans l’exemple ci-dessus, deux tuples seront supprimés soit (250, 25 rue Jaune, 890) et (990, ‘8 rue Rouge’, 890). Si l’action référentielle est du genre ON DELETE SET NULL, les deux mêmes tuples resteront dans la table avec un indicateur NULL pour leur clé étrangère. Le schéma de la relation Personnel est défini en SQL-DDL en spécifiant que la clé est primaire. CREATE TABLE Personnel(

noEmpl number NOT NULL, noChef number DEFAULT NULL, -- null si valeur absente constraint cp_Personnel primary key (noEmpl), CONSTRAINT fk_Personnel FOREIGN KEY (noChef)

REFERENCES Personnel(noEmpl) ON DELETE CASCADE); Il peut être utile parfois de définir temporairement la table sans clé étrangère et de l'ajouter par la suite au schéma avec la commande ALTER TABLE. Le nom d'une contrainte étant un repère dans le dictionnaire, elle peut être plus facilement identifiée et désactivée selon les besoins. Les contraintes doivent être publiées à l'intention des développeurs. Voici une commande pour ajouter une contrainte référentielle à une table existante : ALTER TABLE Personnel ADD (CONSTRAINT fk_noChef_noEmpl FOREIGN KEY (noChef) REFERENCES Personnel(noEmpl) ON DELETE CASCADE );

noEmpl* adresse noChef Personnel :



26

Cette contrainte référentielle définie après la création de la table peut être désactivée ou réactivée à volonté. ALTER TABLE Empl DISABLE constraint fk_noChef_noEmpl; et par la suite, ALTER TABLE Empl ENABLE constraint fk_noChef_noEmpl; Toute violation de contrainte est signalée à l'utilisateur en référant au nom de la contrainte définie dans le schéma. En l'absence d'un nom de contrainte, le SGBD l'identifie par un nom interne, sans référence avec le schéma.

Ajout et suppression de tuples dans une table parent L'ajout de tuples dans une table parent est tout à fait libre, sans être tributaire de la table enfant. L’ajout des tuples est bien sûr assujetti au respect des contraintes d'attribut spécifiées, incluant la clause NOT NULL. La suppression d'un tuple dans la table parent est toutefois limitée par la contrainte référentielle. La spécification minimale est que la suppression dans la table parent est impossible s'il existe un tuple dans la table enfant, référant au premier par sa clé étrangère.

Actions référentielles La norme SQL-92, enrichit la contrainte référentielle par la spécification explicite des actions référentielles, c'est-à-dire celles qui découlent de la suppression (ON DELETE) ou de la mise à jour de la clé primaire (UPDATE) des tuples de la table parent. Les actions possibles qui sont spécifiées dans la table enfant sont les suivantes : CASCADE, SET NULL, NO ACTION et RESTRICT. Très souvent, une seule des actions référentielles est implémentée dans les SGBD. Par exemple, Oracle v.8 n'implémente que l'action ON DELETE CASCADE, tandis que la version 8i en implémente deux, soit CASCADE et SET NULL. Une seule action référentielle peut être spécifiée par action sur la table (UPDATE ou DELETE). Voici un schéma d'une autre base dans laquelle différentes actions référentielles peuvent être définies selon les contraintes imposées par le système d'information. Il en découle une sémantique différente selon les actions référentielles retenues.

Departement (noD*, ville, specialite) – table parent Employe (matricule*, nom, ville, noD) – table enfant

Voici la clause SQL-DDL pour créer la table enfant Employe dotée d’une action référentielle : CREATE TABLE Employe ( matricule number primary key, -- clé définie à ce niveau lorsqu’elle est mono attribut. nom varchar2(40)NOT NULL, ville varchar2(35)NOT NULL, noD number(6), constraint fk_EmployeDepartement foreign key(noD) references Departement(noD) <action référentielle à préciser>);



27

Par exemple, avec lʹaction référentielle ON DELETE CASCADE, la suppression dʹun département, entraînera la suppression de tous les employés. Avec l’action ON UPDATE CASCADE, la mise à jour de la clé primaire d’un département se propage avec la mise à jour automatique de la clé étrangère des tuples de la table Employe. Si l’action est ON DELETE SET NULL, la suppression d’un département se traduit par la mise à jour de la clé étrangère des employés concernés qui devient NULL.

Actions référentielles avec deux clés étrangères Le modèle précédent est enrichi par une nouvelle relation, soit le Syndicat auquel les employés peuvent adhérer. Departement(noD*, ville, specialite) – table parent Syndicat (noS*,nomS) – table parent Employe(matricule*, nom, ville, noD, noS) – table enfant avec 2 clés étrangères : noD et noS Dans ce nouveau MCD formulé en UML, il y a maintenant deux associations émanant de la classe Syndicat. Voici la clause SQL-DDL pour créer la table enfant Employe avec deux actions référentielles : CREATE TABLE Employe ( matricule number primary key, -- clé définie au niveau de l’attribut si clé monoattribut. nom varchar2(40)NOT NULL, ville varchar2(35)NOT NULL, noD number(6), noS number(6), Constraint fk_Employe_Departement foreign key(noD) references Departement(noD) <action référentielle-1 à préciser> , Constraint fk_EmployeSyndicat foreign key(noS) references Syndicat(noS) <action référentielle-2 à préciser>);

Departement noD* ville specialite

Employe matricule* nom ville

Syndicat noS* nomS

1..* EstMembre Travaille 1..*

1 1



28

Si les deux actions référentielles sont du genre ON DELETE CASCADE, alors la suppression d’un département n’entraîne pas celle des employés lorsque ceux-ci adhèrent à un syndicat. En effet l’employé écarté d’un département doit être supprimé de la base tout en restant membre du syndicat. Cette contradiction justifie le refus de supprimer le département. Pour contourner cette difficulté, il faudra supprimer tous les employés du département et ensuite supprimer le département. Par contre, si la première action référentielle est ON DELETE SET NULL et la deuxième ON DELETE CASCADE, la suppression d’un département entraîne seulement celle de l’association des employés avec ce département par la clé étrangère qui devient NULL. Si par la suite, le syndicat voit son accréditation annulée, sa suppression de la table Syndicat est accompagnée de la suppression des employés qui adhèrent à ce syndicat et qui n’ont pas d’assignation à un département particulier. L'action référentielle ON DELETE NO ACTION signifie que la suppression d'un tuple parent échoue lorsque qu’au moins un tuple enfant y réfère. Cet échec sous-tend l’annulation de toutes les modifications faites par la transaction en cours. S'il y a plusieurs actions référentielles dans une table, celle du NO ACTION est vérifiée après les actions de type CASCADE. Finalement, certains SGBD (exemple : DB2 V2) permettent une action référentielle ON DELETE RESTRICT dont la sémantique est similaire à celle du NO ACTION, mais elle en diffère légèrement du fait qu'elle est vérifiée avant les actions du type CASCADE. Ceci est normal puisque toute violation de cette contrainte n’entraîne pas l’annulation de plusieurs tuples.

Mise à jour de la clé primaire dans une table parent La mise à jour de la clé primaire d'un tuple de la table parent risque de laisser certains tuples de la table enfant sans appariement avec un tuple parent si la mise à jour n’est pas propagée aux tuples enfant. Certaines actions référentielles sont possibles dans un pareil cas. Elles sont aussi définies dans la table enfant et exigent une référence à la clé primaire ou à la clé candidate active. L'action ON UPDATE NO ACTION impose que suite à la mise à jour la clé primaire d’un tuple parent, les tuples de la table enfant dont la clé étrangère n’est pas NULL soient toujours associés à un tuple de la table parent sans imposer qu'il soit le même que précédemment (rowid). Dans le cas contraire, la mise à jour est refusée (NO ACTION) avec annulation des modifications faites à la table enfant. Par exemple, si dans la table Dep ci-dessous le numéro de chaque département est modifié systématiquement, entraînant par le fait même une nouvelle affectation de travail pour chaque employé. L'ordre DML suivant réalisera cette mise à jour : Update Dep set noD = noD + 2; --résultats entre parenthèses Exemple :

Empl : nas * nom noD Dep : noD* projet (enfant) 500 Berri 3 (parent) 1 (3) p1 510 Vézina 5 3 (5) p2 5 (7) p3 7 (9) p4

La mise à jour de la clé primaire de Dep est acceptée puisqu'à la fin de l'ordre DML, chaque tuple de la relation enfant est encore associé à un tuple de la relation parent, bien qu'il ne soit pas le

tuples avec un rid différent



29

même. Le 2e tuple de Empl est associé au départ au 3e de Dep et à la fin il est associé au 2e de la même table. L’action référentielle ON UPDATE CASCADE permet donc de modifier la clé primaire d’un tuple parent et de répercuter, s’il y a lieu, la modification aux tuples de la table enfant. Cette action est maintenant disponible avec la version Oracle 8i et les suivantes. L'action ON UPDATE RESTRICT est similaire à l'action précédente en y ajoutant une condition, à savoir que les tuples de la table enfant après la mise à jour de la clé primaire soient appariés avec les mêmes tuples de la table parent (même rowid). Cette action référentielle vient interdire en quelque sorte la mise à jour de la clé primaire de la table parent pour les tuples déjà référencés par une clé étrangère. Par exemple, cette action référentielle interdirait la mise à jour effectuée dans l'exemple ci-dessus. Exemple DB2 avec le ON UPDATE RESTRICT Dep(noD*, usine) -- table parent Projet (noP*, cout) – table parent Emp (maricule*, noD, noP) – table enfant CREATE TABLE Dep( noD number(2) not null CHECK (noD > 5 and noD < 50), usine char(3) NULL, Constraint cp_dep primary key (noD); CREATE TABLE Projet( noP number(2) not null CHECK( noP < 75), cout number(7,2), not null, Constraint cp_dep primary key (noP); CREATE TABLE Emp( matricule char(6) NOT NULL, noD number (2) NOT NULL CHECK (noD > 5 and noD < 50), noP number not null CHECK( noP < 75), Constraint cp_emp PRIMARY KEY (matricule), (1) Constraint fk_Emp_Dep FOREIGN KEY noD REFERENCES Dep(noD) ON UPDATE CASCADE, (2) Constraint fk_no_projet FOREIGN KEY noP REFERENCES Projet(noP) ON UPDATE RESTRICT); Avec DB2, la mise à jour du noD se répercute sur la clé étrangère de la table Emp (1), tandis que la mise à jour du noP est interdite par le UPDATE RESTRICT (2).

Ajout et suppression dʹun tuple dans une table enfant Il n’est possible d'ajouter un tuple dans la table enfant (avec INSERT INTO) que si la valeur de sa clé étrangère correspond à une clé primaire existante dans la table parent ou encore si la clé étrangère a un indicateur d’absence de valeurs, le NULL. Par contre, il est toujours possible de supprimer un tuple dans la table enfant sans aucune restriction au regard de la table parent, sauf si cette table enfant participe à une autre association en tant que table enfant.



30

Mise à jour des attributs non primaires Il est possible de modifier toute valeur non primaire des tuples des tables parent et enfant (UPDATE) en respectant bien sûr les contraintes d'attribut et celles des triggers actifs sur cette table.

Confidentialité mise en échec par la clé étrangère Supposons que l’assignation des employés à des projets soit confidentielle et accessible qu’aux utilisateurs autorisés à la lecture de la table Projet. En l'absence de toute contrainte sur la référence aux tables, un utilisateur qui a accès à la table Emp peut découvrir quels sont les projets inscrits dans la table Projet qui n’ont pas encore d’assignation même si cette information ne doit pas lui être accessible ou interdite. En effet, en utilisant la table Emp qui référence la table Projet, et en insérant successivement des tuples dans la table Emp, soit en simulant le numéro de projet, il est alors possible de connaître les projets sans assignation, seulement par le succès ou l'échec de l'insertion. Pour éviter cette brèche de la confidentialité de la base, un utilisateur de T2 ne pourra pas référencer la table T1 par la contrainte référentielle, donc lui donner une valeur, à moins d'y être autorisé par le privilège REFERENCES associé à son compte (voir implémentation DB2, Oracle). Exemple : GRANT REFERENCES to User2 ON table Projet; --cette autorisation est faite par le proprio de Projet Avec ce privilège, l'utilisateur User2 pourra créer une table EmpTempo et y déclarer un attribut noD comme clé étrangère qui réfère à la table Dep à laquelle il n’a pas les droits d’accès. Ce privilège ne lui confère pas automatiquement le droit de consulter les tuples de la table Dep, mais seulement de la référencer par une clé étrangère.

4.5 Interdiction de l’indicateur d’absence de valeur pour un attribut Il est possible de spécifier pour chaque attribut d’une relation si l’indicateur d’absence de valeur est autorisé ou pas. Par défaut, il est autorisé pour un attribut, sauf si le contraire est spécifié dans le schéma de la relation d’une table. De plus, dans la norme SQL-92, la clause PRIMARY KEY spécifiée pour un ensemble d'attributs exclut de facto les valeurs nulles pour chacun. Toutefois, si la clé est désactivée, l'absence du NOT NULL peut mettre en péril l'intégrité de la BD en acceptant temporairement et par défaut le NULL. Le NULL pour une clé candidate est autorisée (voir UNIQUE de Oracle) sauf si elle est exclue explicitement par le NOT NULL des attributs de la clé candidate. EmployeCandidat(nas*, matricule, nom, ville, noD) Les candidats sélectionnés ont une fiche avec un matricule suffixé par la lettre 'C' et leur fiche est stockée dans la BD. Si une offre d'emploi est faite et acceptée par un candidat, le matricule est modifié par la suppression de la lettre 'C'. L'attribut matricule est une clé candidate pour laquelle l’indicateur NULL est interdit. Create table EmployeCandidat ( nas char(9) not null, matricule char(10) NOT NULL, nom varchar2(40) not null, ville varchar2(50) null), noD nuber(3) null)



31

CONSTRAINT cp_employe_candidat Primary key (nas), CONSTRAINT u_employe_candidat_matricule UNIQUE (matricule), CONSTRAINT fk_employe_candidat_departement Foreign key (noD) References Departement(noD)) ;

Contrainte référentielle en chaîne Il peut y avoir une chaîne de contraintes référentielles dans laquelle les actions référentielles s'appliqueraient alors à tous les niveaux. Si la contrainte référentielle est violée à un niveau, toute la transaction est défaite par une opération dite de ROLLBACK lancée par le SGBD. La contrainte référentielle est vérifiée en premier parmi les autres contraintes définies.

Figure 4.5c Une transaction effectue une mise à jour de la table T1. Pour la réaliser le système doit valider en cascade deux contraintes référentielles. Si l’une d’entre elles n’est pas validée, alors la mise à jour sur T1 est défaite avec un retour au début de la transaction.

Contrainte logique sur un attribut en SQL‐92 (CHECK constraint) Une contrainte définie sur un attribut est vérifiée à chaque ajout ou mise à jour de l'attribut. Généralement il s'agit de la vérification du domaine sémantique de l'attribut Par exemple, le salaire mensuel d’un employé doit être inférieur à 5000.00 $. La contrainte génère pour le SGBD un test pour chaque tuple ajouté qui ajoute un nouveau salaire ou pour chaque modification de salaire d'un employé dont la valeur n'est pas nulle. CREATE TABLE Ouvrier( ... salaire float NULL CHECK (salaire > 0 and salaire<5000.00), metier varchar2(30),...); Cette contrainte de type attribut est rétroactive. Elle est vérifiée lors d'un ajout ou d'une modification pour cet attribut ou lors de sa réactivation. Elle est sans effet lors d'une suppression ou lorsque l'attribut est NULL. Rien en théorie ne s’oppose à ce qu’une contrainte d'attribut peut être aussi formulée en faisant référence à une autre table. Voici un exemple d'une contrainte d'attribut qui vérifie que le produit ajouté dans la table est bien fabriqué par une usine de l'organisation. Dans ce cas, la contrainte d'attribut formulée engendre une recherche dans une autre table au moyen du numéro de produit qui est en cours d'ajout. En SQL-92 , une phrase Select peut être incluse dans la contrainte :

T3

CR

T1

T2

CR

Début de la mise à jour Suppression de t3 dans T1

Propagation en cascade jusqu'à T3



32

CREATE TABLE Produit ( noP number CHECK(noP IN ( SELECT noP FROM Usine U WHERE U.noP = Produit.noP) nonP Varchar2(30) Not NULL ); Notez aussi que le contexte du CHECK est le tuple courant qui fournit la valeur de l'attribut noP dans le tuple Produit. Dans l'expression d'une contrainte d'attribut, il n'est pas possible d'utiliser des fonctions intégrées USER et SYSDATE qui sont sans argument.

Contrainte de tuple (table) En étudiant la notion de domaine, nous avons vu qu’une contrainte formulée au niveau de la table peut faire référence à plusieurs attributs de la même table. Cette contrainte est dite de tuple et son application est rétroactive. Elle est définie dans le schéma en la plaçant après la définition des attributs. Par exemple, un nouvel ouvrier n’est ajouté à la relation que si sa ville où il travaille est différente de celle où il habite et que son salaire mensuel est supérieur à 4500.00. CREATE TABLE Ouvrier(... nom varchar2(45), villeB varchar2(30), villeD varchar2(30), salaire float CHECK ((salaire > 1000 and salaire < 10000.00)), metier varchar2(30)), CONSTRAINT c_villeDiffSalSup CHECK((villeB != villeD) AND salaire > 4500.00)); Avec une telle contrainte, une modification de la ville de son trvail peut être refusée sur la base de la contrainte de tuple, soit c_villeDiffSalSup. En effet, un employé gagnant plus de 4500.00 ne pourra pas habiter la ville où il travaille !

Activation des contraintes dʹattribut Une contrainte d'attribut ou de tuple n’est vérifiée que si elle est activée et si la valeur de l'attribut associé n'est pas nulle au moment de l'ajout ou de la modification. Elle est bien sûr sans effet lors d'une suppression. Si elle est désactivée en cours d'exploitation, les actions d'ajout ou de mise à jour sur la BD sont validées lors de la réactivation de la contrainte. ALTER TABLE Ouvrier DISABLE CONSTRAINT c_ville_metier; ALTER TABLE Ouvrier ENABLE CONSTRAINT c_ville_metier; Une telle suppression temporaire des contraintes risque cependant de conduire à des incohérences malgré la présence des contraintes d'attribut. Il revient au DBA d'utiliser avec une grande prudence cette fonctionnalité.

4.6 DML et la validation des contraintes Un ordre DML est une action de mise à jour (UPDATE), de suppression (DELETE) ou d’ajout (INSERT). A moins d’indication contraire, la modification d'un ou de plusieurs tuples par un UPDATE est suivie de la vérification immédiate des contraintes d’attribut et de table. Si une contrainte n'est pas respectée par l'opération, les modifications déjà effectuées depuis le début du DML sont alors toutes défaites par un ROLLBACK automatique lancé par le SGBD. L'atomicité d'un ordre DML est donc assurée automatiquement par le SGBD : le DML est complété



33

entièrement par le succès de toutes ses actions, sinon il est entièrement annulé ce qui signifie que les tuples modifiés sont remis dans leur état initial. Avec un même ordre DML qui modifie plusieurs tuples d'une même table, il peut y avoir une violation temporaire et acceptable d'une contrainte en cours d'exécution d’un ordre DML. C'est un état incohérent transitoire de la table. Par exemple, la figure 4.6 donne une extension valide de la relation Personnel qui a été créée et ensuite mise à jour avec vérification des contraintes de clé et référentielle, laquelle est de type intrarelation. Voici un exemple d'une contrainte intraréférentielle: Personnel (noE*, noC) La spécification DDL-SQL-92 de la relation est la suivante : CREATE TABLE Personnel ( noE integer not null, noC integer), CONSTRAINT cp_Personnel PRIMARY KEY (noE), CONSTRAINT cf_Personnel FOREIGN KEY (noC) REFERENCES Personnel(noE) on DELETE cascade; Pour les fins de cet exemple, nous supposerons que l'ordre des tuples dans l'extension de la table Personnel de la figure 4.6 est présumé correspondre à celui de leur parcours lors d'une recherche. Supposons que lors de la fusion de deux entreprises, le système d’attribution des matricules des employés doit être modifié par l’ajout d’une constante 2000 afin de libérer les premiers matricules réservés aux cadres et aux chefs d'équipes de la nouvelle entreprise.

Personnel : noE* noC (avant la mise à jour) 601 1000 1000 NULL 602 601 603 602

Figure 4.6 Pour faire cette modification, il faut lancer un seul ordre UPDATE qui touchera plusieurs tuples : UPDATE Personnel SET noE = noE + 2000, noC = noC + 2000; Dans cette mise à jour, la contrainte référentielle n’est vérifiée qu’à la terminaison du DML UPDATE, i.e. dans cet exemple après la mise à jour de tous les tuples qui vérifient le prédicat du UPDATE. Voici la trace des états de la table Personnel au cours de l'exécution du UPDATE. Etats successifs de la table (fin du DML et validation)

Etat 1 Etat 2 Etat 3 Etat 4 modif1 --> modif2 --> modif3 --> modif4 2601 3000 * 2601 3000 2601 3000 2601 3000 1000 NULL 3000 NULL 3000 NULL 3000 NULL 602 601 602 601 2602 2601 * 2602 2601 603 602 603 602 603 602 2603 2602

Figure 4.7



34

Le résultat est cohérent parce que la validation de la contrainte est effectuée à la toute fin de l'exécution de l'ordre DML. Si la contrainte était vérifiée en cours de modification de chaque tuple, la mise à jour de la table deviendrait alors impossible, car la première modification viole la contrainte d'intégrité référentielle. A la fin de l'ordre UPDATE, la contrainte référentielle est cependant à nouveau vérifiée. Pour ce faire, le SGBD génère une transaction interne qui force la validation à la toute fin de l'opération sous-tendue par chaque ordre DML.

Contrainte multitable: règle dʹaffaire ou de gestion des données Lorsqu'il s'agit de faire des actions plus complexes sur la base comme une insertion dans une table suivie d’une mise à jour dans à une autre table sous réserve qu’un condition soit vérifiée par les données de 2ème table, il faut utiliser un trigger, i.e. une procédure interne du SGBD pour effectuer cette vérification. Le trigger est programmé et est déclenché avant ou après la mise à jour sur la 2ème table. Nous verrons plus loin comment programmer un tel trigger dont la version compilée est stockée dans le dictionnaire.

Contrainte globale: assertion sur la base de données Une assertion est une contrainte globale ou générale qui est toujours vraie quelles que soient les manipulations faites sur une des tables de la base. Cette contrainte sur un objet du schéma est formulée par un ordre particulier en SQL-92, CREATE ASSERTION. Cette assertion SQL permet de formuler une contrainte impliquant une ou plusieurs relations. Elle est rétrospective, mais ne peut être différée, c’est-à-dire que toute action sur la base est suivie immédiatement de la vérification de l’assertion. Syntaxe : CREATE ASSERTION <nom_assertion> CHECK(<condition>) ; Exemple: CREATE ASSERTION limit_total_salaire CHECK ((SELECT Sum(salaire) FROM Employe)<500 000.00); L’ajout d’un employé dans la base est effectué que si le total des salaires après l’ajout est inférieur au demi million. Cette assertion est stockée dans le dictionnaire du système SGBD et elle est vérifiée après chaque accès à la relation Employe autre qu'une lecture. Elle doit être toujours vraie, sinon l'action en cours est refusée. Si une assertion est supprimée temporairement, sa remise en service implique la validation rétrospective de tout l'état de la base. C'est une opération qui peut être lourde et pénalisante pour les utilisateurs. Le CREATE ASSERTION n’est pas encore disponible avec Oracle.

Activation et temporisation dʹune contrainte action non rétroactive des triggers Lorsqu’une contrainte est active, toute opération sur la base est interdite si le résultat final sur la base ne la vérifie pas. Ces contraintes sont spécifiées par le DBA dans le schéma et aussi au moyen d'assertions ou de déclencheurs (triggers). Avec la plupart des SGBD, les contraintes peuvent être actives ou non. Lorsqu'une contrainte est inactive, la vérification de la contrainte est inhibée temporairement. Après la réactivation d'une contrainte, les actions antérieures faites sur la abse sont validées, sauf s'il s'agit d'une contrainte formulée par trigger. Dans ce dernier cas, la réactivation du trigger ne vérifie pas les modifications faites antérieurement. Les contraintes d'assertion, de tuple et d'attribut ont cependant une portée rétroactive. Dans la norme SQL-92, les contraintes sont nommées pour en faciliter la gestion et informer l'utilisateur avec plus de précision et cela, lorsqu'il y a une violation en cours d'exploitation.

Report de la vérification de la contrainte dans une transaction implicite La norme SQL-92 permet de définir qu'un ordre DML d’ajout, de mise à jour et de suppression est, par défaut, exécuté entièrement et qu’ensuite il y a immédiatement vérification des contraintes pertinentes. Au besoin cependant cette vérification peut être différée jusqu'à la fin de



35

l’exécution de plusieurs DML enchâssés par une transaction implicite et reportée jusqu’à l'exécution du COMMIT. Une transaction implicite est définie automatiquement dès l’exécution du premier ordre DML d’une application et elle se termine avec le prochain COMMIT qui donne le signal de la fin de transaction et le début de la vérification des contraintes. Une contrainte est donc par défaut IMMEDIATE, c'est-à-dire vérifiée après chaque ordre DML. Cette vérification peut être reportée au moment de la validation par le COMMIT ou lorsque la contrainte revient en mode IMMEDIATE par un énoncé SET IMMEDIATE. Pour différer la vérification d’une contrainte, il s’agit d’utiliser la commande suivante : SET CONSTRAINT c_x DEFERRED; Où c_x est le nom de la contrainte dont la validation est différée. Il est possible de différer toutes les contraintes par la commande suivante : SET CONSTRAINTS ALL DEFERRED; Les validations de chaque DML sont alors reportées au prochain COMMIT.

Report de la vérification de la contrainte dans une transaction explicite Dans plusieurs actions combinées d’une application sur la base, le problème de la cohérence des données sera résolu par la notion de transaction et du report de la vérification des contraintes à la fin cette transaction explicite. Une transaction explicite est une unité de traitement délimitée par les ordres SET TRANSACTION READ WRITE et COMMIT. Ce traitement transactionnel explicite est pris en charge par le gestionnaire de transactions qui en assure l'atomicité, i.e. que les actions de la transaction sont toutes exécutées correctement et entièrement ou rien n’est fait. Exemple : Toute transaction sur la base de données doit vérifier la contrainte d’attribut qui spécifie que le niveau de chaque pièce dans l’inventaire est supérieur à 99, sinon la commande est refusée. Create table Inventaire( noP number (5) not null, qte number(4) not null Constraint c_qte CHECK(qte >99) DEFERRABLE INITIALLY IMMEDIATE, . . . ); Afin de pouvoir vérifier les contraintes à la fin de la transaction, il faut spécifier que celles-ci peuvent être différées, même si initialement elles sont vérifiées immédiatement. La transaction suivante est définie par le set transaction et le commit. Elle permet de retirer des pièces de l’inventaire sous le niveau critique de 99, d’en ajouter 25 et cela sans que la première opération soit refusée. SET TRANSACTION READ WRITE; SET CONSTRAINT c_qte DEFERRED; -- cette contrainte est différée -- retrait de 125 pièces, l’inventaire passe sous 100, soit 90 UPDATE Inventaire set qte = qte-125 WHERE noP = 'p166'; -- ajout de 25 nouvelles pièces pour porter l’inventaire à 115 UPDATE Inventaire set qte = qte + 25 where noP = 'p166', ...); COMMIT; -- vérification des contraintes



36

Avec une telle transaction explicite et avec la clause DEFERRABLE pour l’attribut qte, la vérification de la contrainte d’attribut est reportée à la fin de la transaction. Si elle est vérifiée, la mise à jour et l’insertion dans la table Inventaire sont complétées avec succès. Voici un exemple d’une transaction qui aboutit à un échec : CONNECT TO bd1@vega identified by bd123 -- IMMEDIATE par défaut SET TRANSACTION READ WRITE; SET CONSTRAINTS ALL DEFERRED ; -- la qte est 150 SET CONSTRAINT c_qte IMMEDIATE; -- retour en mode immédiat pour la -- contrainte c_qte UPDATE Inventaire set qte = (qte – 100) WHERE noP = 'p166'; -- vérification immédiate de c_qte qui doit être > 99.

*** Echec de la transaction et Rollback des opérations *** UPDATE Inventaire set qte= qte + 90 where noP = 'p166',

***. . . *** COMMIT; Cette transaction ne sera pas complétée parce que, la contrainte c_qte étant maintenant activée pour une vérification immédiate, la mise à jour sera invalidée et toute la transaction annulée. Pour qu'une contrainte d'attribut puisse être reportée, il faut qu'elle soit définie comme DEFERRABLE dans le schéma de la table. Sinon, une contrainte d'attribut est par défaut non différable. Exemple : Le schéma de la table Vente peut avoir une contrainte différée ainsi : CREATE TABLE Vente ( noV integer primary key constraint limNoV CHECK(noV < 9999), montant number(6,2) not null constraint c_limite_montant CHECK(montant<5000.00)INITIALLY IMMEDIATE DEFERRABLE; Après la création de la table, la contrainte c_limite_montant est vérifiée immédiatement après chaque ajout ou modification, mais peut être reportée par un ordre SET DEFERRED placé dans une transaction. Au contraire, la contrainte limNoV ne peut pas être reportée, car par défaut elle est non reportable et vérifiée immédiatement (IMMEDIATE).

Report des contraintes de clé Les contraintes de clé primaire et la contrainte référentielle sont différables jusqu’au prochain commit. Au moment de la validation, celle-ci n’est pas complétée si tous les tuples de la table ne les vérifient point. Create Table Empl (

nas number(4,0) Primary key, noDep number(2,0) , Constraint fk_Empl foreign key (noDep) References Dep(noDep) DEFERRABLE); SET CONSTRAINT fk_Empl DEFERRED;

Cette commande reporte la vérification de la contrainte référentielle jusqu’au Commit. Le retour à la vérification avant même le Commit est fait par la commande : SET CONSTRAINT fk_Empl IMMEDIATE; La contrainte de clé primaire peut être aussi reportée avec la même commande.



37

Variable de tuple :new et :old Lorsqu'une insertion (ou une modification) est effectuée dans une table, le tuple en ajout est placé par le moteur SGBD en premier dans un espace temporaire pointé par la variable de tuple :new qui est gérée par le système et pour chaque application. Dans le cas d'une mise à jour d'un tuple, une copie de ce tuple est d'abord placée dans un deuxième espace temporaire pointé par la variable de tuple :old et la copie du tuple mise à jour est placée dans l'espace temporaire pointé par :new. Ensuite, si la contrainte référentielle est en cause, elle est vérifiée et cela, avant l'exécution éventuelle d’un trigger.

Figure 4.8e

Dans le cas d'une insertion, la variable de tuple :old pointe sur NULL, tandis que celle :new

pointe sur les valeurs du nouveau tuple. Les variables de tuple désignées par :new et :old peuvent être au besoin redéfinies pour être libellées autrement.

4.7 Déclencheur (Trigger) non rétroactif C'est une sorte de procédure "démon" stockée dans le dictionnaire de données qui est lancée automatiquement par le SGBD lorsque survient un événement prédéterminé associé à une table ou à un autre objet de la base. Par exemple, un trigger peut être formulé pour lancer une insertion dans une ou plusieurs tables de la base suite à une insertion ou à une suppression de tuples dans une autre table. C’est une propagation des mises à jour. Le corps d'un trigger est composé d'une ou de plusieurs clauses SQL intégrées au besoin dans une procédure complète développée en PL/SQL de Oracle, en GDML du système Interbase ou avec le langage des triggers de DB2-V2 . Un trigger est capable de faire des ajouts, des suppressions ou des insertions de tuples dans une ou plusieurs tables. L'action du trigger prend effet au moment de sa définition ou de son activation et elle n'est pas rétroactive. Le trigger est notamment utilisé pour implanter des règles d'affaires complexes. Le traitement d’un trigger est formulé par un langage relativement simple qui s’apparente à tout langage de programmation. Il doit avoir un caractère procédural et permettre l’intégration de clauses SQL. Il ne faut perdre de vue que le déclenchement d’un trigger monopolise le processeur et peut étendre le temps de réponse. Il faut donc les utiliser avec parcimonie pour des validations critiques pour conserver la cohérence dans la base.

Trigger de tuple versus trigger d’énoncé Un trigger de tuple est une procédure attachée à une table qui est exécutée pour chaque tuple touché par l’ordre DML. Le trigger d’énoncé, (Statement trigger) est aussi une procédure attachée à une table qui est exécutée une seule fois, soit à la fin de l’ordre DML. Exemple : Augmentation de 10% du salaire des 50 employés représentés dans une table. UPDATE Employe set salaire = salaire * 1.10 ;

BAApplication : . . . . . . UPDATE T1 set B=45 WHERE A = 1 0;

BD SGBD 10, 20, 69

10, 45, 69

:new :old

ZMP

page P2

1 2

3

4

5



38

Le trigger de tuple attaché à la table Employe sera exécuté 50 fois, tandis que le trigger d’énoncé sera exécuté qu’une seule fois, à la fin de la mise à jour de s 50 employés présents dans la table.

Définition dʹun trigger avec Interbase (Borland) Examinons brièvement la programmation d'un trigger du SGBD Interbase dont le rôle est d'implémenter la contrainte référentielle qui n’est pas définie comme telle dans le schéma. L’attribut code indique que l’instance peut être supprimée (pour D), mise à jour (pour U) ou est permanente (pour P). Le maph est le matricule du patient hospitalisé qui identifie une personne lors de sa première hospitalisation. Par exemple, la contrainte référentielle définie entre la classe Patient, DossierAdmission et FicheConsultation doit interdire la suppression d'un patient s'il n'y a pas aussi suppression des tuples associés dans les tables enfants. Cette règle est implantée dans Interbase par un trigger du type PRE ERASE, c'est-à-dire que ce dernier sera déclenché avant la suppression d'un tuple dans la table Patient.

Figure 4.8 MCD E/A de la base PCDF

Voici un graphe de triggers du MCD, illustré à la figure 4.8a.

Graphe de triggers Figure 4.8a

Patient

CompteRAMQ DossierAdmission FicheConsultation

D-supp-no-1 D-maj-1

Tr-A -> Tr-B trigger défini dans A et fait une action dans B

CompteRAMQ noCompte* cout maph

FicheConsultation noFiche* dateCons maph code

DossierAdmission noDossier* maph nbJour code

Patient maph* nom

PossedeA Un Genere

(1,1)

(1,1) (1,n) (1,n)

(0,1) (1,1)



39

Pour ce modèle (notez l'absence de cycle dans le MCD) pour représenter le comportement dicté normalement par les clés étrangères. Par exemple, le trigger nommé D-supp no 1 est associé à

une suppression dans la table Patient et son action porte sur les tables DossierAdmission et sur la table FicheConsultation.

Le trigger D_supp_no_1 est exécuté avant la suppression d'un patient; il entraîne la suppression de son dossier d'admission et de ses fiches de consultation si l'attribut code est 'D', sinon les fiches sont gardées avec l’attribut maph mis à nul. Une telle action simule la contrainte référentielle. L'exemple ci-dessous est programmé pour une version antérieure du SGBD Interbase. La variable de tuple old pointe sur le tuple de Patient qui est en cours de suppression. Define trigger D_supp_no1 for Patient PRE ERASE 0: begin for da in Dossier_Admission with da.maph = old.maph – tuple à supprimer if da.CODE = 'D' then erase da else da.maph = null; end_for; for fc in Fichier_Consultation with fc.maph = old.maph if fc.CODE = 'D' then erase fc – suppression du tuple pointé else fc.maph = null; end_for; end; end D_supp_no1; Lorsque le trigger est défini, il est automatiquement activé et le demeure tant que le DBA ne le fait pas passer en mode inactif par la commande Interbase MODIFY : MODIFY trigger D_supp_no_1 INACTIVE; (commande Interbase) Voici un autre trigger Interbase du genre POST ERASE qui permet de vérifier s'il existe une instance de CompteRAMQ ayant le même maph que celui du patient supprimé. Dans le cas affirmatif, la suppression du patient est annulée ou défaite par la commande ROLLBACK. Define trigger D_supp_no_2 for Patient POST ERASE 0: begin IF any c in CompteRAMQ with c.maph = old.maph begin ROLLBACK; -- annulation de la transaction et restauration des valeurs abort 1;-- arrêt et affichage du message 1 end; end; end_trigger D_supp_no_2; message 1: ‘un dossier de la RAMQ présent pour ce maph’;



40

Dans un diagramme des triggers, les cycles doivent être évités dans le déclenchement. Le graphe des triggers permet de les détecter et ainsi d’éviter les boucles infinies. La détection et l'élimination des cycles est généralement la responsabilité du DBA.

Trigger du SGBD Oracle Avec Oracle, un déclencheur est un bloc du langage PL/SQL qui inclut au besoin des énoncés SQL. Le trigger peut être déclenché avant ou après un événement associé à une action sur une table. Les ordres INSERT, UPDATE et DELETE peuvent déclencher un ou plusieurs triggers. Voici un trigger en PL/SQL qui, au moment de la suppression d'un patient établit le coût de l'hospitalisation et tient compte d'un arrérage dans le paiement d'une hospitalisation antérieure. CREATE TRIGGER cumul_cout BEFORE DELETE ON Patient FOR EACH ROW DECLARE arrerage number (5,2); duree number(4); montant number(6,2); BEGIN SELECT sum(cout) INTO arrerage FROM CompteRAMQ WHERE maph = old.maph; SELECT nbJ into duree FROM DossierAdmission WHERE maph = old.maph; montant := arrerage + duree * 300.00; UPDATE DossierRAMQ set cout = montant WHERE maph = old.maph; END;

Tables en mutation (particulier à Oracle, avant la version 8) Le système Oracle ne permet pas d'interférences entre les triggers sur les tables. Dans le modèle ci-dessous, il y a une contrainte référentielle définie entre les deux relations de la BD et on présume l'existence de quelques règles d'affaires qui devraient être implémentées par des triggers. Employe (nas*, nom, ville, noD) Departement(noD*, site) CREATE TABLE Departement( noD number(2) not null, site char(3) null CHECK SITE in ('Québec', 'Montréal', 'Gaspé') constraint cp_departement primary key (noD); CREATE TABLE Employe( nas char(6) not null, nom varchar2(45),

nas* nom ville noD

Employe

noD* site

Departement

Contrainte référentielle



41

ville varchar2(50), noD number(2)not null, CONSTRAINT cp_employe PRIMARY KEY (nas), CONSTRAINT fk_employe_departement_no_dep FOREIGN KEY(noD) REFERENCES Departement(noD) ON DELETE CASCADE); La contrainte référentielle entre les deux tables est souvent implémentée par un trigger système défini par le SGBD et associé à la table Departement ( une table parent) de sorte que toute suppression d'un département amorce l’exécution d’un trigger associé qui fait une lecture dans la table Employe (soit indirectement par l'index créé avec la clé étrangère de Employe) pour autoriser ou interdire la suppression dans la table parent Departement. Au cours de cette opération, la table Departement est dite en mutation, c'est-à-dire en cours de traitement (par le DELETE) et la table Employe est aussi en mutation (de type constraining) suite à la suppression engendrée éventuellement par la présence du ON DELETE. L’une et l’autre des ces opérations sont effectuées par des processus internes différents (pid particulier à chacun). Pour éviter des reprises inutiles ou des comportements trop restrictifs, le SGBD Oracle (version antérieure au 8i) interdit à tout autre trigger de lire ou de modifier les tables en mutation. Les règles d'affaires sont souvent implémentées par des contraintes complexes impliquant plusieurs relations du même schéma de la base. Par exemple, les contraintes suivantes peuvent être définies sur les relations Employe et Departement : 1) Il ne peut pas y avoir au total plus de deux départements sur le même site géographique; 2) Lorsqu'il y a création d'un nouveau département, il y a aussi création automatique d'un chef 'virtuel' dont le nas est composé du numéro de département, la ville est celle du site et son nom est 'chef'. 3) Il est impossible de mettre à jour la clé primaire de Departement, car cela risquerait d'invalider une contrainte référentielle existante. La première contrainte pourrait être réalisée par un trigger de type PRE INSERT associé à la table parent Departement. Avant chaque ajout d'un département, il suffit de tester si le nombre total sur le site particulier est inférieur à 2. Dans l'affirmative, un nouveau département peut être ajouté. La deuxième contrainte est concrétisée par un trigger POST INSERT associé à la table Departement de sorte que l'insertion d'un nouveau tuple dans une autre table est effectuée avec une ou des valeurs lues dans la table Département. Or, de telles solutions conduisent une erreur de table en mutation (mutating table error) qui est provoquée notamment par le verrouillage sous-jacent à l'exécution du DML qui vient en conflit de verrouillage exclusif avec les triggers du système Oracle. Il y a quelques solutions à ce problème, notamment celle d’utiliser les packages.

Table en mutation (mutating table) Avec les versions antérieures de Oracle (8.0 et moins), certaines actions sur les tables conduisent à un état système dit de table en mutation. Une table de base T1 d'une base Oracle est dite en mutation lorsqu'une des actions suivantes se produit sur cette table : a- T1 est en cours de modification par l'exécution d'un INSERT, UPDATE ou DELETE; b- T1 est en cours de lecture par Oracle pour la vérification d'une contrainte référentielle; c- T1 est en cours de mise à jour par Oracle pour exécuter une contrainte ON DELETE CASCADE.



42

Table sous contrainte référentielle (constraining table) Une table de base parent est dite sous contrainte par rapport à l'exécution d'un trigger (d’utilisateur ou de système) si elle est l'objet d'une lecture ayant pour objet de vérifier une contrainte référentielle déclaratoire et de poser un verrou dans l'index système sur l'entrée correspondant à la clé de la table parent. Dans l'opération d'ajout d'un tuple dans une table enfant, la table parent est sous contrainte puisqu'elle doit être lue pour vérifier la présence de la clé étrangère. Dans la suppression d'un tuple dans la table enfant, la même lecture s'impose et la table parent est sous contrainte. Voici deux tables d'une base de données dans laquelle plusieurs triggers sont définis sur la table Employe et dont le traitement consiste à lire son contenu. Departement (noDep*, site) Employe (nas*, nom, ville, noDep)

Le trigger ci-dessous est associé à Employe. Il est présumé déclenché par l'événement associé : le trigger fait une lecture de Employe. S : DML ou Statement R : pour tuple ou row

BEFORE INSERT (S) OK BEFORE INSERT (R) OK si insertion d'un seul tuple AFTER INSERT (S) (1) OK AFTER INSERT (R) (2) table Employe en mutation BEFORE UPDATE (S) OK BEFORE UPDATE (R) table Employe en mutation AFTER UPDATE (S) OK AFTER UPDATE (R) table Employe en mutation BEFORE DELETE (S) OK BEFORE DELETE (R) table Employe en mutation AFTER DELETE (S) OK AFTER DELETE ( R) table Employe en mutation

Figure 4.8d (1) S L'insertion de tous les employés est réalisée avant de déclencher le trigger d'énoncé, soit le

After Insert. Sachant que le DML est terminé, le trigger peut lire toute la table Employe et effectuer la validation en utilisant éventuellement une condition complexe faisant référence à tous les tuples de la table.

(2) R L'insertion d'un employé est réalisée et le tuple est immédiatement verrouillé. Avant de poursuivre avec les autres insertions, le trigger de tuple After Insert est déclenché pour faire une lecture de la table Employe. Or, pour vérifier une condition il ne peut lire que le tuple inséré, ignorant les autres qui sont à venir et cela par l’action du même ordre DML. Si la condition n'est pas vérifiée, le DML est immédiatement interrompu à tort et l'insertion annulée. Ce type de trigger ne tolère pas un état transitoire incohérent puisqu'il effectue la validation après chaque insertion d'un tuple.

Règle A Une table en mutation ne peut pas être lue ou modifiée par un trigger dont le traitement implique une table en mutation. La conséquence de l'application de cette règle est que tout trigger de tuple de type insertion, suppression ou modification sur une table en mutation génère une erreur. Il y a cependant une exception avec le trigger BEFORE INSERT (concernant l'insertion d'un seul tuple



43

par DML) puisque, le tuple n'étant pas encore inséré dans la table, celle-ci n'est pas en mutation au regard d'un autre trigger et que le tuple n'est pas encore verrouillé dans la table.

Règle B Une table parent sous contrainte référentielle ne peut pas être modifiée par l'exécution d'un trigger. Si une des deux règles est violée par une application, le SGBD signalera une erreur de type table en mutation : ORA-04091 ''Table is mutating''. Cette contrainte se manifeste donc avec le trigger UPDATE, INSERT et DELETE de tuple et parfois d'énoncé.

Remarque importante Le phénomène de la table en mutation semble être absent avec les versions récentes du SGBD Oracle 8i et les suivantes. L’implémentation est maintenant faite pour éviter les problèmes d’interférence ou d’interverrouillage entre les divers triggers impliqués dans la vérification de la contrainte référentielle.

Exemple de lʹeffet restrictif dʹun trigger de tuple (Row) La table Inventaire(noP, qte) a un trigger de tuple exigeant que la somme des soldes de chaque pièce en inventaire soit positive (donc une lecture de la table Inventaire par le trigger). Or, dans une application, un Insert doit ajouter deux tuples dans cet ordre ('p2', -10) et ('p2', +15); le solde de piece 'p2' est de 5 juste avant le moment de faire le premier ajout. Après l'insertion du premier tuple, le trigger sera lancé et se terminera par un échec et un retour en arrière de la première insertion. Pour éviter cette dépendance sur l'ordre des insertions, il faudrait utiliser un trigger d'énoncé (S).

Solution à la mutation des tables La difficulté posée par la mutation d’une table lors de l’exécution d’un trigger de tuple est contournée, notamment par l’usage de triggers d’énoncé. Il faut alors utiliser une variable globale créée par un package (rangée au niveau du serveur) pour remplacer le rôle de la variable de tuple :NEW et ainsi permettre de sélectionner un sous-ensemble de tuples d’une table avec un trigger d’énoncé et ensuite utiliser un trigger d’énoncé AFTER pour vérifier les conditions imposées pour la continuation de l’opération DML sur la base. La solution sera développée pour un exemple concret dans le chapitre ultérieur sur l’indexation et les triggers.

Traitement par trigger de tuple sans lecture de la table en mutation Un trigger de tuple peut être formulé pour vérifier une condition qui ne nécessite pas une lecture de la table par un SELECT. L'exemple ci-dessous illustre bien ce traitement d'ajout d'un tuple dans une table MutationP qui est validé que si la valeur d'un attribut du nouveau tuple vérifie une condition dont l'évaluation n'exige pas la lecture de la table. Pour y arriver, il faut utiliser la variable de tuple :OLD qui donne accès au tuple avant une suppression. /* creation de deux tables et insertion de tuples */ drop table mutationE; drop table mutationP; create table MutationP( a number primary key, b number, dateP date); INSERT INTO MutationP values ( 1, 1, sysdate -1); Create Table mutationE (c number primary key, a number references MutationP(a)); INSERT into mutationE values(1,1); /* trigger before delete */



44

CREATE or replace trigger trig_avant_mutation BEFORE DELETE on MutationP FOR EACH ROW Declare nb number; begin if :old.dateP < SYSDATE then Raise_application_error('-20030','MSG : suppression interdite'); end if; end; /*impossible si suppression antérieure à la date du jour */ SQL> delete MutationP WHERE trunc(d) = trunc(sysdate-1) * ERROR at line 1: ORA-20030: MSG : jour antérieur à la date du jour ORA-06512: at "AGAMACHE.TRIG_AVANT_MUTATION", line 4 ORA-04088:error during execution of trigger 'GAMACHE.TRIG_AVANT_MUTATION' Au cours de l'exécution du trigger, aucune lecture de la table MutationP n'est effectuée. Le rejet est basé sur une comparaison de la valeur du tuple pointé par la variable :old ( le champ utile est obtenu par :old.dateP) et la date du jour fournie par la fonction SYSDATE. Le trigger d'énoncé ne présente pas autant de difficultés lorsque l'action porte sur la même table que celle à l'origine de son déclenchement. En effet, le trigger n’est lancé qu'à la fin du DML et à ce moment, la validation peut être faite sans risquer de mettre fin à une action encore incomplète. Si l'action d'un trigger porte sur une autre table de la BD qui n'est pas dans la chaîne référentielle, les limitations imposées par la mutation des tables ne s'appliquent plus.

Trigger du système DB2 (IBM) Un trigger du SGBD IBM-DB2 réagit aussi à un seul événement et sa syntaxe est similaire à celle des triggers de Oracle. La notion de table en mutation n’existe pas avec ce SGBD. L'événement est défini comme étant un ordre DML de SQL : Insert, Delete ou Update. Avec la base suivante composée de deux tables, il est possible de définir un trigger qui bloque la mise à jour de la clé étrangère à NULL. L'événement est l'exécution de l'ordre UPDATE sur la relation Pieces.

Pieces : noPiece* cout nomV Vendeur : nomV* ville prov p1 350 Paul Paul Québec Québec p2 600 Sylvie Sylvie Montréal Québec p3 200 Eric Eric Bary Ontario p4 800 Paul

La contrainte référentielle DB2 est définie avec la clé étrangère nomV de la table Pieces. CREATE TRIGGER VENDEUR_OBLIGATOIRE BEFORE UPDATE ON PIECES ON NOM_V REFERENCING NEW AS N FOR EACH ROW WHEN (N.NOM_V IS NULL) SIGNAL SQLSTATE'70005'(Impossible avec un fournisseur inconnu')



45

Il est aussi possible de définir un trigger qui référence une table avant sa mise à jour pour y compter le nombre de tuples et ajouter un nouveau tuple dans une table appelée Audit. L'image avant de la table mise à jour est appelée OLD_TABLE Pieces, tandis que l'image après de cette même table est connue sous le nom NEW_TABLE Pieces. CREATE TRIGGER AUDITFOURN AFTER UPDATE ON PIECES REFERENCING OLD_TABLE AS TAV FOR EACH STATEMENT; INSERT INTO AUDIT VALUES(USER,CURRENT_DATE,(SELECT COUNT(*)FROM TAV));

4.9 Formes normales des tables relationnelles Dans cette partie, nous étudierons les formes normales des tables et nous en donnerons la raison d’être pour assurer d’abord et avant tout l’intégrité des données. Pour définir les formes normales, nous utiliserons une notion déjà vue, soit celle de la dépendance fonctionnelle. Le modèle relationnel (MRD) obtenu par transformation du MCD E/R ou UML peut être raffiné par le processus de normalisation. Un modèle relationnel normalisé est composé de tables dont le schéma formé par les divers attributs de la table doit posséder des propriétés particulières et souhaitables pour éviter diverses anomalies lors des opérations de mise à jour, de suppression et d'ajout. On dit alors que les tables sont normalisées. La normalisation des tables est donc une opération qui débute avec la conception de la base de données et qui doit être revue au cours de son cycle de vie. En outre, lors de l’évolution d’un schéma, il faut appliquer à nouveau les algorithmes de normalisation pour garantir que les modifications apportées à la base ne sabordent la normalité des relations.

Formes normales Les formes normales sont définies principalement à partir des dépendances fonctionnelles (DF) identifiées lors de l'étape de l'analyse informatique. Une DF dans une relation R entre les attributs A et B est notée A --> B et est définie de la façon suivante : soit deux tuples quelconques t1 et t3 de r et t1[A] étant la valeur de l'attribut A dans la tuple t1,

Si t1[A] = t3[A] alors t1[B] = t3[B]. La notation A -> B est une implication logique qui affirme que, dans une extension quelconque de la table dont le schéma contient les attributs A et B, pour toute paire de tuples ayant deux valeurs qui coïncident sur A, les valeurs sur B coïncident obligatoirement. Dans le cas contraire la dépendance fonctionnelle n'est pas valide. La même définition s'applique pour les ensembles d'attributs. La notion de DF sera au cœur des algorithmes de transformation et de synthèse des schémas relationnels; elle intervient aussi dans les formes normales d'une relation. La notation A --> B se lit de deux façons : A détermine B ou B est en dépendance fonctionnelle sur A. Le meilleur choix est le vôtre !

Première forme normale (FN1) Une relation R est en forme normale FN1 (ou en 1FN) si le domaine de chaque attribut du schéma de R est atomique (scalaire), c’est-à-dire qu'aucune valeur du domaine n’est un ensemble de valeurs. Du point de vue de l'utilisateur, l'atomicité d'un attribut se traduit au niveau de l'extension par la présence dans chaque tuple d'une seule valeur pour chaque attribut. Plus formellement, une relation en FN1 a une clé principale qui détermine chaque attribut atomique du schéma. Cette clé peut être cependant simple ou composée. Une relation qui n'est pas en forme FN1 possède un groupe dit répétitif de valeurs qu'il faudra supprimer et déplacer éventuellement dans une autre relation.



46

Dans l'exemple suivant, la relation Patient a un schéma composé seulement d'attributs atomiques ou scalaires et sa clé est simple. Patient (noPatient*, nom, adresse, sexe, noMd)

Patient : noPatient* nom adresse sexe noMd p10 Lise 2 des roses f md2 p20 Arthur 5 des chênes m md5

Chaque tuple de l'extension de Patient est constitué de valeurs atomiques. Comme nous l'avons déjà vu, la clé définit implicitement un ensemble de dépendances fonctionnelles en plus de celles explicitement formulées lors de l'analyse informatique. Ces DF induites par la clé sont les suivantes : noPatient --> nom noPatient --> sexe noPatient --> adresse noPatient --> noMd On peut aussi les formuler plus succinctement ainsi : noPatient --> nom, adresse, sexe, noMd Par contre, si la réalité exige que dans un même tuple un même patient ait plusieurs adresses alors cette relation Patient n'est pas en FN1, car l’attribut adresse n’est plus atomique. Dans ce cas, pour un patient particulier, l'attribut adresse a comme valeur un ensemble d'adresses plutôt que par une seule.

Patient : noPatient* nom adresse sexe noMd p10 Lise (2 des roses ; 1 des lilas) f md2 p20 Arthur (5 des chênes) m md5

Cet ensemble n'est donc pas une valeur atomique comme cela est exigée par la forme FN1. De plus, le noPatient dans un tuple ne correspond pas alors à une seule valeur de l’adresse, mais plutôt à un ensemble ou groupe de valeurs. Il y a donc négation de la DF qui est notée : noPatient -/-> adresse (l'attribut adresse est aussi désigné groupe répétitif) La relation pourrait être remise en FN1 si les tuples sont multipliés autant de fois qu'un patient a d'adresses. Cette nouvelle relation aura aussi une nouvelle clé, cette fois composée de l'ensemble des attributs {noPatient, adresse}.

Patient : noPatient* nom adresse* sexe noMd p10 Lise 2 des roses f md2 p10 Lise 1 des lilas f md2 p20 Arthur 5 des chênes m md5

La redondance dans cette table Patient se manifeste de différentes façons. Par exemple, le patient p10 est traité par le même médecin md2 quelle que soit son adresse. Une mise à jour partielle subséquente pour modifier le médecin traitant du patient p10 ayant domicile au 1 des lilas qui sera dorénavant suivi par md6 viendrait invalider la DF qui contraint un même patient à avoir qu’un médecin traitant. Bien sûr, cette situation découle d’une mise à jour partielle effectuée par une application qui ignorait que le patient p10 est inscrit dans la base avec deux domiciles, voire même plusieurs.



47

Patient : noPatient* nom adresse* sexe noMd p10 Lise 2 des roses f md2 *** p10 Lise 1 des lilas f md6 p20 Arthur 5 des chênes m md5

Avec invalidation de la DF : noPatient -/-> noMd Voici un autre exemple d’une relation nommée Allocation normalisée en FN1 et qui, malgré cela, a une extension redondante. Cette relation a un ensemble F de dépendances fonctionnelles qui sont spécifiées au terme de l'analyse informatique. Allocation (chefProjet*, projet*, noBureau) Avec F = chefProjet, projet --> noBureau ; chefProjet --> noBureau} Dans cet exemple, il y a une DF non induite par la clé composée, soit chefProjet--> noBureau. La forme FN1 de cette relation n'est pas suffisante pour éviter la redondance et les anomalies qui en découlent. En effet, si Fortin, qui travaille au projet 'p817', change de bureau et occupe le 'b450', il faudrait mettre à jour, outre le premier tuple, tous les autres représentant les projets auxquels travaille Fortin. Dans le cas contraire, il y aura une anomalie de mise à jour parce que l'extension indiquera que Fortin du projet 'p817' a dorénavant son bureau au b450, tandis que le même Fortin qui travaille au projet 'p818' a toujours son bureau au 'b400' ! L'extension deviendrait incohérente par rapport à la réalité à représenter. En pratique, il est possible que la mise à jour soit formulée de manière à trouver seulement le premier tuple dans la base des données. UPDATE Allocation set noBureau = 'b450' WHERE chefProjet = 'Fortin' and projet = 'p817'; Après cette mise à jour, Fortin a deux bureaux et l'extension invalide la DF qui impose qu'un chef de projet n'ait qu'un seul bureau. Est-il possible d’éviter cette incohérence au niveau de la conception même des tables, sans faire intervenir un trigger ?

Allocation : chefProjet* projet* noBureau --> Fortin p817 b400 -> (b450) Dubé p805 b400 Dubé p819 b400 Dussault p851 b243 Dussault p831 b243 Fortin p818 b400 ?? Pagé p817 b404

Figure 4.9 La forme normale FN1 n’évite donc pas cette anomalie de mise à jour, du moins avec cet exemple. Une forme normale supérieure est nécessaire.

Deuxième forme normale (FN2) Une relation Ri est en forme normale FN2 : a- Si son extension ou son schéma est en FN1, b- Si chaque attribut non primaire, s'il en existe, est en dépendance fonctionnelle totale avec chaque clé candidate de Ri. Autrement dit, il faut que chaque attribut non primaire soit en dépendance fonctionnelle avec tous les attributs de la clé et non pas avec une partie de celle-ci.



48

La FN2 pour une relation sous‐tend qu’il nʹexiste pas dʹattributs ne faisant pas partie d’une clé qui sont fonctionnellement dépendants dʹun attribut faisant partie d’une clé. La relation Allocation de la figure 4.9 n’est pas en FN2, car la DF {chefProjet ‐‐> noBureau} viole la deuxième condition de la forme normale. Par contre, la relation Patient présentée ci‐dessous est en FN2 parce que la clé de la relation est monoattribut (ou simple) et que forcément les DF induites sont toutes totales. Patient (noPatient*, nom, adresse, sexe, noMd) La relation PatientSejour ci-dessous a une clé composée et elle ne sera en FN2 que si chaque attribut non primaire est en DFT par rapport à chaque clé candidate de cette même relation. Ceci imposera qu’un patient soit traité par le même médecin quels que soient les séjours à l’hôpital. PatientSejour (noPatient*,dateIn*, nom, adresse, sexe, noMd) Les dépendances suivantes sont présentes dans cette relation : F = {{noPatient, dateIn} -> nom, adresse, sexe, noMd ;(DF de la clé) ; noPatient --> nom, adresse, sexe} Si la réalité modélisée par cette relation est légèrement différente à savoir qu’un patient peut être traité par différents médecins lors de divers séjours à l’hôpital, PatientSejour n’est pas en FN2. Il y a au moins un attribut non primaire, le nom, qui n'est pas en DFT sur {noPatient, dateIn}, car un sous-ensemble propre, soit {noPatient} détermine le nom, l’adresse et le sexe dans F. Pour la transformer en FN2, il suffit d'isoler dans une toute nouvelle table la DF qui contrevient à la dépendance totale et de la nommer : PatientIdentification(noPatient*, nom, adresse, sexe) L'autre relation est obtenue à partir de la table d’origine en enlevant le déterminé (nom, adresse, sexe) de son schéma. Il en résulte une nouvelle table qui peut être renommée PatientMd : PatientTraitement(noPatient*, dateIn*, noMd) Cette dernière relation doit être à nouveau testée pour la FN2. Si elle n’est pas en FN2, elle devra être décomposée à nouveau.

Pourquoi pas utiliser un identifiant de relation ? La création artificielle d’un identifiant monoattribut en remplacement d’une clé composée apporte souvent une solution à ce problème créé par l’absence de dépendance fonctionnelle totale qui accompagne la clé composée, mais elle introduit cependant un élément artificiel et quelque peu arbitraire voire inconnu dans le système d’information. Ce dernier identifiant peut devenir une source d’erreurs pour les utilisateurs du système d’information. De plus, il n'est pas toujours possible de remplacer une clé composée par un identifiant, sans perdre le sens de ce qui est représenté ou sans introduire un bruit informationnel souvent déroutant pour les utilisateurs du système. Malgré cela, l’usage de l’identifiant s’impose parfois pour avoir la garantie que la relation est dans une forme normale supérieure. Nous y reviendrons avec la discussion de la forme normale FN5.



49

Troisième forme normale (FN3) La FN2 est insuffisante pour éviter des anomalies comme cela sera illustré par la table de la figure 4.10. Pour corriger ces anomalies encore présentes, il faudra passer à une forme normale supérieure, soit la FN3. Une relation R est dite en FN3 si elle satisfait les conditions suivantes : a) si r est en FN2; b) et si chaque attribut non primaire est déterminé uniquement par une clé (primaire ou candidate) de la relation. Rien d’autre ne contraint les attributs primaires qui peuvent cependant apparaître dans les autres DF. Voici une table présentée à la figure 4.10 qui est une relation en FN2, mais qui possède encore des anomalies. F = {societe −−> style,prix ; style −−> prix}

constructeur : societe* style prix --->Modif. Cardieux Inc. duplex 65 K$ Delna Ltée duplex 65 K$ Dupont canadien 60 K$ Uniquo ranch 50 K$ ---> Supp. Métro Inc. bungalow 45 K$ Mozart Ltée duplex 65 K$ Windex Inc. ranch 50 K$ Térou Inc. ranch 50 K$

Figure 4.10 La table Constructeur représente les sociétés de construction agrées pour construire certains styles maison qui seront vendues à un prix conventionné. L'ensemble des dépendances de cette table Les anomalies résiduelles dans l’extension de la figure 4.10 sont les suivantes : a)Ajout : il est impossible d’ajouter un style de maison vendue à un prix conventionné sans avoir une société pour la construire. En effet, société est un attribut primaire qui ne peut pas être sans valeur. b) Suppression : la dernière suppression du tuple avec le style bungalow fait perdre une information sur son prix conventionné; c) Mise à jour : la modification du prix du style de duplex qui passe de 65 K$ à 70 K$ peut être incomplète si elle est seulement sous la responsabilité d’une application incorrectement programmée. Ainsi, le premier du bungalow construit par Cardieux Inc. passe de 65K$ à 70K$, mais non celui de Delan Inc. suite à cette mise à jour incomplète, alors DF style -/-> prix. Ceci est contraire à F. Pour corriger cette anomalie présente dans la FN2, il faudra passer en FN3. Ce passage en FN3 se fera par division de la relation en deux tables de préférence indépendantes en utilisant les dépendances de F et l’algorithme utilisé précédemment.



50

Algorithme de transformation du schéma relationnel logique Lorsque le schéma d’une relation ne vérifie pas la normalité recherchée, il peut être transformé par l’algorithme élémentaire suivant : 1- Choisir une première DF valide dans R et former une nouvelle relation en faisant l'union du déterminant et du déterminé. L'extension de cette relation est obtenue par projection ou par extraction des colonnes de données pertinentes dans la relation d'origine. 2- Enlever le déterminé du schéma initial pour obtenir un nouveau schéma de relation. 3- Tester la nouvelle relation pour la forme normale FN3. Au besoin, recommencer la transformation si la nouvelle relation ne satisfait pas à la forme normale recherchée. 4- À la fin, renommer les relations obtenues avec un libellé significatif au regard des attributs du schéma. Ainsi, la table Constructeur qui n’est pas en FN3 est transformée par l’algorithme ci-dessus pour obtenir deux nouvelles tables indépendantes (voir le théorème de Rissanen) qui doivent être testées à nouveau pour en connaître le degré de normalité.

r1 : societe* style Cardieux duplex Delna duplex Uniquo ranch Mozart duplex Térou Inc. ranch Windex ranch Métro Inc. Bungalow

r2 : style* prix duplex 65K$ bungalow 45K$ ranch 50K$

Figure 4.11 La table R1 et R2 ont respectivement des clés simples et sont en FN3. L’anomalie observée précédemment est disparue, car la mise à jour du prix du bungalow ne peut plus être partielle, puisque ce style apparaît que dans un seul tuple de la nouvelle table R2.

Théorème de Rissanen sur les projections indépendantes Ce théorème permet de vérifier que la décomposition d’une relation R donne bien deux relations indépendantes. Une relation R est décomposée en deux relations R1 et R2 qui sont dites indépendantes si les deux conditions suivantes sont vérifiées : 1- Toute DF valide dans R peut être logiquement déduite des dépendances de R1 et R2. 2- Les attributs communs de R1 et R2 forment une clé candidate pour au moins une des deux relations. Exemple : La décomposition de la table Constructeur fournit deux relations R1 et R2 indépendantes. En transformant F pour obtenir un ensemble F1 formé de 3 DF, on peut



51

facilement vérifier que chacune peut être déduite des DF de R1 ou de R2. Finalement, l’attribut commun, soit style, est une clé candidate de R2.

Relation en FNBC Une relation en FN3 présente moins d’anomalies, mais certaines tables en FN3 ont toujours quelques anomalies qui risquent de porter préjudice à l’intégrité de la base. Nous illustrons cette situation avec la base de la figure 4.12. Les anomalies observées seront corrigées en passant à une forme normale dite FNBC (pour Forme Normale de Boyce Codd). Une relation en FNBC est plus stricte que la forme FN3.

Horaire : cours* section* campus* periode pavillonSalle ift-10540 B Nord 8:30-11:20 plt-2348 ift-10542 A Nord 12:30-15:20 desj-2350 ift-10540 B Sud 16:30-18:30 vch-3756 Ift-10540 A Nord 8:30-12:20 Vch-1234

Figure 4.12 La clé est composée de trois attributs : {cours, section, campus}, c’est-à-dire le plus petit ensemble d’attributs qui permet de distinguer les tuples les uns des autres. Les dépendances fonctionnelles valides dans la table Horaire sont les suivantes regroupées dans l’ensemble F : F = {cours, section, campus --> periode, pavillonSalle ; pavillonSalle --> campus } Cette relation est en FN3, car tous les attributs non primaires (periode et pavillonSalle) sont en dépendance fonctionnelle que sur une clé. Il faut noter que l’attribut campus est primaire et le fait qu’il soit déterminé par un attribut non primaire ne contrevient pas à la définition de la FN3. Les anomalies encore présentes dans cette relation FN3 sont les suivantes : 1- Ajout : Il est impossible de représenter les salles d’un nouveau campus si aucun cours n’y est offert, puisque les attributs primaires seront nuls. 2- Suppression : Si la section B du cours ift-10540 est supprimée, le premier doit être enlever et en ce faisant, on perd l’information que la salle plt-2348 est située au campus Nord. Pour corriger ces anomalies, il faut transformer la relation en FN3 pour obtenir que des relations en FNBC. Une relation R est en FNBC si : a) R est en FN1; b) et chaque attribut de la relation, primaire et non primaire, est déterminé uniquement par une clé candidate (incluant aussi la clé principale). Soit la relation Horaire qui représente l'horaire des cours offerts par un collège dont les activités sont réparties sur plusieurs campus. Est-ce que la relation Horaire est en FNBC? Non, car il y a au moins dans F un attribut primaire (campus) impliqué dans une DF dans laquelle le déterminant (pavillonSalle) n'est pas une clé de Horaire, ni primaire ni candidate. Pour obtenir une relation en FNBC, il faut transformer la relation Horaire en la scindant en deux parties dont l'une est formée par les attributs de la DF qui



52

fait échec à la forme FNBC, soit pavillonSalle --> campus. Cette nouvelle relation sera nommée Localisation au regard des attributs de son schéma. Le libellé de la nouvelle relation est quelque peu subjectif, car il dépend du sens attribué à l'ensemble des attributs qui forment le nouveau schéma. Le schéma de la deuxième relation est obtenu en enlevant les attributs du déterminé du schéma initial. Les deux nouvelles relations Localisation et Horaire1 sont en FNBC et leur jointure (combinaison des deux tables sous une condition particulière) éventuelle fournit l'extension de la relation Horaire. Cette division de la relation initiale se fait donc sans perdre de données parce que les attributs communs aux deux nouvelles relations déterminent tous les attributs dans l'une des deux relations obtenues par division. Localisation : pavillonSalle* campus Horaire1: cours* section* pavillonSalle* periode plt-2348 Nord ift-10540 B plt-2348 8:30-11:20 desj-2350 Nord ift-10542 A desj-234 12:30-15:20 plt-3756 Sud ift-10540 B plt-3756 16:30-18:30 vch-1234 Nord ift-10540 A vch-1224 8 :30-12 :30

Figure 4.13

Ces nouvelles tables corrigent les anomalies d’ajout et de suppression observées précédemment. En effet, la suppression de la section B du cours ift-10540 n’entraîne plus la perte de la localisation des salles utilisées par ce cours supprimé. A chaque division d’une relation, il faut préciser, s’il y a lieu, les nouvelles clés et vérifier que les DF sous-tendues par la nouvelle clé sont bien valides ou dérivables à partir de F. Celle de la table Localisation est évidente puisqu’une DF de F l’identifie directement. Par contre, celle de la table Horaire1 ne l’est pas. Cependant, avec les règles de dérivation des DF que nous verrons plus loin, la clé sera dérivée comme étant formée de l’ensemble (cours, section, pavillonSalle). Le DBA a la responsabilité de la normalisation des schémas de la base. Il doit aussi vérifier que toute réorganisation subséquente du schéma de la BD imposée par les applications respecte les formes.

4.10 Formes normales supérieures : FN4 et FN5 La normalisation en FNBC est jugée généralement adéquate pour la plupart des bases de données commerciales et industrielles. Il ne faut en conclure qu’elles sont pour autant exemptes de certaines anomalies. Il existe des formes normales d’ordre supérieur, les FN4 et FN5 (ou dépendance de jointure). Elles sont respectivement définies par rapport à de nouvelles dépendances les dépendances multivaluée (DMV) et de jointure (connue sous le sigle de PJ). Leur découverte dans certaines applications spécialisées permet d’éviter certaines anomalies associées à l'ajout, à la suppression et à la mise à jour dont les effets peuvent être parfois importants pour des applications particulières. La détection et les propriétés de ces dépendances font l'objet d'une étude plus avancée au chapitre sur la théorie de la normalisation. Les méthodologies de conception et d’analyse privilégient les formes normales en proposant une démarche qui conduit méthodiquement vers la formulation de relations normalisées, généralement en FN3 ou en FNBC. Toutefois, le choix définitif des structures pour les relations reste à faire lorsqu'il faut tenir compte de certains critères qui favorisent l’obtention d’un niveau de performance recherchée. Après la normalisation d’un schéma, l’exploitation particulière de la BD par les applications amène parfois le DBA à dénormaliser les relations pour obtenir une meilleure performance dans



53

le calcul de certains opérateurs relationnels, notamment celui de la jointure. Cette opération interviendra obligatoirement après la normalisation des relations de la base. La dénormalisation consistera à dupliquer essentiellement les attributs qui interviennent dans le calcul de la jointure et d'y ajouter ceux qui sont spécifiés dans la réponse.

Recherche et formulation des dépendances fonctionnelles Rien ne garantit que toutes les dépendances fonctionnelles seront formulées par le concepteur ou l'analyste. La mise en oeuvre de la base est parfois faite avec seulement les contraintes de dépendance perçues et formulées, même si celles-ci sont incomplètes. En outre, le concepteur peut formuler des dépendances de manière à ce que certaines dépendances, bien que non formulées explicitement, existent avec les données de la base. Par exemple, si le concepteur formule que le nas détermine le nom d'une personne et le numéro de la société qui l'embauche, il peut aussi formuler dans une autre dépendance que le numéro de la société détermine le nom de la société. Alors, il est implicitement énoncé par transitivité que le nas de la personne détermine le nom de la société. Formellement, cette dernière dépendance est déduite des précédentes par une des six règles principales d'inférence des DF.

nas --> nom, noSoc noSoc --> nomSoc

Alors le nas --> nomSoc est une DF valide même si elle n'est pas explicitement énoncée. Avec ces règles d'inférence, il est donc possible d'augmenter les dépendances fonctionnelles initiales de F formulées au cours de l'analyse informatique pour obtenir un nouvel ensemble plus riche que nous appellerons la fermeture de F. Cette dernière sera notée F+. Celle-ci est généralement composée d’un grand nombre de DF, elles-mêmes redondantes entre elles. Certaines n’ont pas besoin d’être formulées explicitement puisque certaines règles permettent de les dériver à partir des DF existantes. Ces règles énoncées ci-dessous sont valides et complètes. Ceci signifie qu’à partir d’une DF de F qui est valide, ces règles conduisent aussi à d’autres DF valides. Finalement, elles sont complètes parce qu’il est possible de générer toutes les DF dérivables de F en les appliquant successivement.

4.10.1 Règles dʹinférence pour les DF de R(X, Y, Z, W) Soit les ensembles d'attributs X, Y, Z et W du schéma d'une même relation R. A la limite, ces ensembles sont des attributs simples. Les règles d’inférence ci-dessous permettent de générer de nouvelles DF valides qui ne sont pas énoncées explicitement dans F.

1‐ Réflexivité Pour tout X de R, X --> X' où X' est sous-ensemble de X. En d'autres mots, un ensemble d'attributs détermine toujours un de ses sous-ensembles. Les réflexives sont des dépendances triviales.

2‐ Augmentation Si X --> Y et X -> Z dans R, alors X --> Y, Z dans R.

3‐ Augmentation du déterminant avec une réflexive Si X --> Y dans R, alors Z, X --> Z, Y pour tout Z ∈ R

4‐ Transitivité Si X --> Y et Y --> Z, alors X --> Z 5- Pseudo-transitivité Si X --> Y et Y, W --> Z, alors X, W --> Z . 6- Décomposition Si X --> Z, W est valide dans R, alors X --> Z et X --> W sont aussi valides dans R.



54

Ici, on a donc une règle de réécriture des DF dont le déterminé est composé de plusieurs attributs. Les DF obtenues sont équivalentes à celles du départ. Ces règles sont démontrées comme valides seulement à l'intérieur d'un même schéma de relation, c’est-à-dire que les tous les attributs du déterminant et déterminé doivent être dans la même table. En appliquant ces règles tant qu'une dérivation est possible, la fermeture transitive de l'ensemble de départ est obtenue et toutes les DF peuvent et devraient être disponibles pour vérifier la normalité d'une relation. Bien sûr, une DF ne s'applique à une relation que si le déterminé et le déterminant sont des sous-ensembles du schéma de cette même relation. Finalement, deux ensembles de DF sont équivalents s'ils ont la même fermeture transitive.

Exemples de dérivation de dépendances fonctionnelles 1- Démontrer que A, B --> C lorsque A--> C Avec B --> B (réflexive), il peut y avoir augmentation du déterminant pour obtenir A, B --> C, B. Par décomposition, on obtient A, B --> C et A, B --> B. C.Q.F.D. 2- Démontrer que A, C , D --> C, D lorsque A--> D Avec D --> D (réflexive), il peut y avoir augmentation du déterminant pour obtenir A, D --> D. Avec C --> C, on a que A, D, C --> D, C 3- Démontrer que A--> E lorsque A--> D et D --> E, G dans R Par transitivité, on a que A --> E, G Par décomposition de cette première DF : A --> E et A --> G . C.Q.F.D.

Dérivation de la clé de la relation Horaire1 Cette relation (figure 4.13) est obtenue par décomposition de la table de la figure 4.12 dont les DF sont regroupées dans F = { cours, section, campus ‐‐> periode, pavillonSalle; pavillonSalle ‐‐> campus } Comme le schéma de Horaire1 est composé que des attributs (cours, section, pavillonSalle, periode), la clé est dérivée sans connaître les données de son extension : 1- De (1) pavillonSalle --> campus on a par augmentation de (1) par la réflexive cours, section --> cours, section 2- cours, section, pavillonSalle --> cours, section, campus (2) 3- On obtient par transitivité avec que cours, section, campus --> periode, pavillonSalle de F (2) et (3) cours, section, pavillonSalle --> periode, pavillonSalle (4) de (4) par décomposition on a : (3) cours, section, pavillonSalle --> periode et cours, section, pavillonSalle --> pavillonSalle Donc la DF induite correspond à la clé de la table Horaire1.

Synthèse relationnelle Plusieurs algorithmes sont proposés pour synthétiser le schéma relationnel à partir des diverses dépendances, dont les dépendances fonctionnelles. Bernstein (2) a proposé un algorithme basé sur les DF pour obtenir un schéma par synthèse en tenant compte de plusieurs cas particuliers qui



55

posaient problème avec les autres approches. Plus récemment, Smith(3) a mis en valeur le diagramme des dépendances pour composer des tables entièrement normalisées. Quelques exercices résolus 1-Voici le SQL-DDL pour définir une structure de table (schéma initial de la table) afin de représenter des projets. Create table Projet ( noProjet number(5)not null, site varchar2(40)not null, budget number (8,2) , nbOuvrier number(3,0)not null, nbContremaitre number(2) not null, constraint cp_Projet primary key(no_Projet) ); Définir en SQL-DDL une contrainte sur les données pour que le budget soit connu lors de l’inscription d’un projet dans la BD et que ce budget soit inférieur à 1 million de dollars, mais toujours supérieur à 10 000.00 dollars. Réponse : CONSTRAINT c_budget CHECK(budget > 10000.00 and budget <1000000.00 and budget is NOT NULL) 2- Cette table relationnelle Projet représente une classe du MCD. Si ce dernier est modifié pour que la classe Projet soit mise en association avec la classe Société Immobilière qui commandite le projet, quelles modifications faut-il apporter à la définition SQL-DDL du schéma initial de la table Projet (voir la définition de la table Projet ci-dessus)? La société immobilière est identifiée par son noCorporatif et peut commanditer plusieurs projets, tandis qu’un projet a un seul commanditaire identifié par un noCorporatif. Réponse : Ajout d’une clé étrangère dans Projet : noCorporatif et une contrainte référentielle : CONSTRAINT fk_societe_immo foreign key (noCorporatif) REFERENCES SocieteImmobiliere (noCorporatif); 3- Définir en SQL-DDL une contrainte complète pour vérifier qu’il n’y a pas plus de 10 ouvriers par contremaître. Réponse : Il faut définir une contrainte de table qui fait référence à deux de ses attributs. CONSTRAINT c_rat_Ouvrier_Contre CHECK(nbOuvrier/nbContremaitre<= 10); ou CHECK(nbOuvrier < 10 * nbContremaitre) ou CHECK(nbContremaitre * 10 <= nbOuvrier) ;



56

Exercices sur les contraintes 1. Créez deux tables Dep (noD*, ville) et Ouvrier (nas*, nom, age, anExp, noDep) qui constituent la base DEPOUV. Un ouvrier peut être inscrit sans avoir encore d’affectation de travail et un département doit avoir un ouvrier dès son inscription dans la base de données. Lorsqu’un département est supprimé, les ouvriers qui y travaillent sont débauchés immédiatement par l’entreprise. 1.1 Donnez les clauses SQL nécessaires pour créer les deux tables. 1.2 Renforcez la contrainte de participation obligatoire de la classe Dep à l’association entre les deux tables. S’il y a lieu, formulez le trigger approprié nécessaire pour la validation de la contrainte de participation partielle. 2- Insérez dans la table Dep deux tuples de votre choix et insérez ensuite trois tuples dans la table Ouvrier dont l’un seulement sans affectation départementale. 2.1 Procédez maintenant à une mise jour des départements localisés à Ste-Foy, pour indiquer dorénavant Québec. Supprimez un tuple dans la table parent et commentez le résultat. 3- Avec l’utilitaire SQL*Plus, créez le trigger ci-dessous qui est associé à la table Dep. Create OR Replace trigger trigDep Before Update on Dep For Each Row Begin Update Ouvrier Set noDep =:New.noDep Where noDep = :Old.noDep; end; -- Pour sortir de l’éditeur entrez un point (.). 3.1 Effectuez la mise à jour de la clé de la table Dep et commentez le résultat. 3.2 Effectuez la mis à jour de la clé étrangère dans un tuple de la table Ouvrier de sorte que ce dernier soit maintenant affecté à un autre département inscrit dans la base de données. Commentez le résultat. 4- Avec la base DEPOUV, modifiez le schéma des relations de la façon suivante : 4.1 Ajoutez à la table Dep une contrainte nommée C_Ville d’attribut de sorte que tout département soit localisé à Québec, Montréal ou Sherbrooke. Ajoutez à la table Ouvrier une contrainte pour que l’âge de tout ouvrier soit compris entre 18 et 65 ans inclusivement. Ajoutez une contrainte pour que le nombre d’années passées sa majorité soit supérieur ou égale

au nombre d’années d’expérience reconnues dans son métier. Dans les exercices ci-dessous, le contexte et la sémantique sont sous-entendus par les dépendances fonctionnelles explicites (voir F) et implicites lorsque la clé de la relation est identifiée par l'énoncé. Les autres dépendances, non explicitement énoncées sont réputées ne pas exister, sauf indication contraire. 1- Soit R (A, B, C, D) avec F = {A --> B; A --> C; A --> D}. Démontrer au moyen des DF que l'attribut A est une clé candidate ? 2- Soit R (A, B, C, D) F: {A --> B; A --> C ; A --> D} Est-ce que R est en FN 3 ?

Exercices sur les formes normales



57

3- Soit la relation Production (no_Prod, nomClient, dateLivraison, prix) avec F = {noProd --> nomClient; noProd --> dateLivraison, prix}. Trouver une clé et une superclé pour la relation Production. 4- Soit R (A, B) avec F = { A --> B; B --> A}. Est-ce que A et B sont des clés ? 5- Est-ce que R (A, B) avec F = { A --> B; B --> A} en FNBC? Expliquer votre réponse. 6- Soit R (A , B, C ) avec F = { A --> B, C ; B --> A, C ; C --> A}. Est-elle en FN2 ? 7- Soit la relation Elections qui représente les résultats des élections de la dernière décennie : Elections (date*, region*, depute, premierMin) Avec F= {date -> premierMin; date, region -> depute, premierMin}. Les autres DF sont considérées invalides et notées ainsi au besoin : region -/-> depute; -- une région a un seul député en même temps depute -/-> premierMin; region -/-> premierMin; premierMin -/-> depute. N.B. le -/-> représente la négation de la dépendance fonctionnelle. Est-ce que cette relation est en FNBC? Justifiez votre réponse. 8- Soit R (A, B, C) avec F = { A, B --> C; C --> A}. Est-ce que {A, B} est une clé ? 9- Est-ce que R (A, B, C) avec F = {A, B --> C; C --> A} est en FN3 ? 10- Est-ce que la relation R (A, B, C) avec F = { AB --> C; C --> A} est en FNBC? 11- R (A, B, C) avec F = { C --> A}. Est-ce que R est en FN3 ? 12- Est-ce que R (A, B, C) avec F = { C --> A} est en FNBC si la clé étant est { B, C}. 13- Soit la représentation des jumeaux par la relation suivante: Jumeaux (nas1, nas2) Avec F = { nas1 -> nas2 ; nas2 -> nas1} L'attribut nas1 est le numéro d'assurance sociale du premier jumeau. Est-ce que la relation Jumeaux est en FNBC ? 14- Soit R (A, B, C, D) avec F = { A --> B; C --> D}. Est-ce que la clé est {A, B, C} ? Démontrez que R n’est pas en FN3. 15- Soit R (A B C ) avec F = { A, B --> C; A, C --> B; B, C --> A}. Est-ce que A est une clé candidate? 16- Voici une table qui modélise la publication par des éditeurs de documents dont le contenu est autorisé par la signature des scientifiques concernés et employés par différentes sociétés de recherche. Vérifier la normalisation de la table et, s'il y a lieu transformer son schéma pour obtenir une base en FNBC.



58

Document :

noDoc editeur nasA nomA adrA noS nomS adrS a b c d e g h i 42 Québcor 100 Genois Lévis s70 XRAY Qc 42 Québcor 101 Biron Mtl s70 XRAY Qc 42 Québcor 102 Marois St-Lin s70 XRAY Qc 55 PUM 103 Ferland Qc s80 Sound Mtl 55 PUM 104 Genois Mtl s80 Sound Mtl 55 PUM 102 Marois St-Lin s80 Sound Mtl 60 Québcor 107 Dion Rouyn s85 ABTech Qc

N.B. Pour faciliter les manipulations, les attributs sont renommés par des lettres pour obtenir la relation suivante : D ( a, b, c, d, e, g, h, i) Les DF validées par cette extension sont les suivantes : 1- a --> b, g, h, i 2 - c --> d, e 3- g --> h, i 4- h --> i La clé candidate est {a, c}. Par conséquent, la DF a, c --> b, d, e, g, h, i est donc valide. 17- Est-ce que la relation Interim est en FN2 ? Interim (I) :

nas * noContrat* heure nomEmp noHotel siteHotel a b c d e f 135 c1 20 Savard H30 Montréal 157 c1 28 Henri H30 Montréal 168 c2 32 Watson H9 Québec 135 c2 28 Savard H9 Québec 140 c3 35 Jobin H25 St-Georges 150 c4 14 Audy H5 Montréal

18- Voici une autre table Interim pour gérer les employés intérimaires et leurs travaux dans le domaine du service hôtelier. 18.1 Identifier les anomalies d'ajout, de modification et de suppression dans cette table Interim. 18.2- Quelles sont les DF valides dans cette extension ? Les DF non infirmées par les données sont valides. 19- Soit R (A, B , C ) avec F = { A, B --> C; A, C --> B; B, C --> A}. Est-ce que R est en FN3 ? 20- Soit R (A, B, C ) avec F = { A, B --> C; A, C --> B}. Est-ce que A, B, C est une superclé ? 21- Soit R (A, B, C ) avec F = {A, B --> C; A, C --> B}. Est-ce que {A, C} est une clé candidate ? 22- Soit R en FN3, R (A, B, C) avec F ={ A, B --> C; A, C --> B}. Est-ce que l’attribut B ne dépend que d'une clé? 23- Soit R (A*, B, C), est-ce que la relation est en FNBC ?



59

24- Voici une autre table Livraison pour modéliser la livraison interurbaine des colis. Livraison (L) :

noLiv origine destination distance nomDestinataire a b c d e 49 Québec Chicoutimi 200 Remy 68 Montréal Rouyn 500 Marie 73 Hull Toronto 350 Marie 84 Chicoutimi Sept-Iles 500 Marie 69 Gaspé Rimouski 650 Renée 85 Québec Toronto 800 Jean 87 Montréal Rouyn 500 Christine

24.1 Quelles sont les DF validées par cette extension? 24.2 Quelles sont les anomalies possibles dans la table Livraison ? 24.3 Quelles sont les clés candidates de cette table ? 24.4 Quelle la plus grande normalité de la table Livraison ? 25- Transformer, s'il y a lieu, la table Livraison pour obtenir une base en FNBC. 26- Voici une table pour modéliser l'encadrement assuré par les conseillers auprès des étudiants. ConsEtud (noEtudiant, mineure, conseiller)

ou plus simplement en représentant chaque attribut par une lettre : ConsEtud(n, m, c). Voici les règles sémantiques sous-tendues par cette relation : a- Pour chaque programme de 15 crédits appelé une mineure, un étudiant a un seul conseiller pédagogique; b- L’encadrement des étudiants d'une mineure peut être assuré par plusieurs conseillers; c- Chaque conseiller encadre plusieurs étudiants d'une mineure; d- Chaque conseiller ne dispense un encadrement que dans le cadre d’une mineure. 26.1 Formulez les dépendances fonctionnelles de cette table. 26.2 Quelle est la plus grande normalité de cette table? Justifiez votre réponse. 26.3 Transformez s’il y a lieu la table initiale pour obtenir une base en FNBC.

Chapitre 5 Algèbre relationnelle


61

Chapitre 5

Algèbre relationnelle Après avoir étudié le modèle relationnel et ses propriétés inhérentes pour renforcer la cohérence et l’intégrité des données, il nous faut maintenant voir un langage capable d’exploiter ce modèle peu importe l’implémentation privilégiée par un constructeur. Ce langage de données, indépendant des implémentations de SGBD possède un minimum d’opérateurs algébriques qui permettent de traiter les relations de manière à obtenir les réponses aux questions plus ou moins complexes. Ces réponses sont reprises par les applications pour un traitement local destiné à répondre à une logique d’affaire. La connaissance des opérateurs relationnels permet de formuler les expressions algébriques complexes facilitant souvent le passage aux requêtes SQL.

5.1 Algèbre relationnelle C’est un langage formel à caractère déclaratif4 constitué d'opérateurs unaires et binaires qui permettent les manipulations des tables du modèle relationnel. Il comprend un ensemble minimal d’opérateurs capables de manipuler les tables de la BD de manière à calculer une réponse à une requête si complexe soit-elle. Ce langage est complet avec six opérateurs de base dont la sémantique est bien définie. Les SGBD relationnels traduisent les requêtes formulées avec SQL en une requête interne construite avec les opérateurs algébriques, requête qui sera par la suite optimisée pour en générer un plan d’exécution équivalent, dont l’exécution fournit la réponse. Les opérateurs canoniques de l’algèbre relationnelle sont les suivants :

Projection Renommage Union Restriction (sélection) Jointure Différence

Tous les langages destinés à la manipulation des données relationnelles sont construits à partir de ces opérateurs de base. L’exécution de chaque opérateur de ce langage canonique donne un résultat qui, même vide, a une structure de relation (ou de table). Ces relations calculées ou temporaires ont aussi une propriété particulière, soit celle de ne pas avoir une clé primaire obligatoire comme c’est le cas pour les relations dites de base. Il existe plusieurs autres opérateurs relationnels différents de ceux de cet ensemble minimal. Ces autres opérateurs facilitent la formulation des opérations complexes sur les tables. Ainsi, cet ensemble est souvent augmenté de l'opérateur de la division relationnelle, de l'intersection et des jointures externes. La division relationnelle permet d’exprimer le quantificateur universel (et indirectement le quantificateur existentiel) dans une proposition logique qui formalise la requête. Ce n'est pas un opérateur essentiel (non canonique) parce que sa sémantique peut être exprimée par composition des opérateurs de base : jointure et différence. Il en est de même pour l’intersection et certaines jointures spécialisées qui sont des opérateurs algébriques utiles, mais non nécessaires pour assurer la complétude du langage.

Familles de langages de données L'algèbre relationnelle est la base de la définition de langages de données plus conviviaux qui sont classés en deux familles : a) Calcul relationnel : cette famille de langages spécifie le résultat recherche, et non les étapes pour l’obtenir. Ces langages sont essentiellement non procéduraux. Par exemple, pour obtenir une réponse représentée par la table Rep donnant le nom et la ville où travaillent les ouvriers. Il faut formuler la requête ainsi :



62

(Rep (nom, villeProjet)|nom d’ouvrier de la table Ouvrier et villeProjet, une ville de la table Projet) La partie à la droite de la barre verticale est le prédicat qui doit être vérifié par chacun des tuples de la réponse. b) Calcul Algébrique : Cette famille de langages spécifie comment obtenir le résultat de manière procédurale. La question précédente est alors formulée différemment en algèbre : (Π nom,villeProjet (Employe |x| Projet )) Les différentes étapes du calcul sont spécifiées par les opérateurs de l’algèbre relationnelle, dont le premier, la jointure (|x|) est binaire et nécessite deux tables comme opérandes et l’autre, la projection (Π) est unaire ne requérant qu’une seule table résultat de la jointure. La fin du calcul doit donner la réponse recherchée sous la forme d’une table. Des langages de plus haut niveau intègrent maintenant l'approche procédurale avec celle du calcul. C’est le cas du langage SQL (descendant de SEQUEL d'IBM) dont les opérateurs s’inspirent à la fois de l’algèbre relationnelle et du calcul relationnel. D’autres langages sont proposés, mais utilisés plus rarement :QBE, ALPHA, CUPID, QUEL. Malgré une certaine lacune du côté de l’orthogonalité du langage (Miranda et Codd (5)), notamment pour les versions avant le SQL/92 et, grâce aux efforts de standardisation de l’ISO, le langage de données SQL demeure un outil important pour le développement actuel des applications. Il est toutefois possible que les langages graphiques redeviennent à la mode grâce aux interfaces graphiques de haut niveau (GUI) de plus en plus disponibles sur les stations de travail et dont la puissance autorise le traitement efficace de ce type de langages.

5.2 Opérateurs relationnels et le typage Le langage algébrique a une loi de composition interne fermée au sens où le résultat d'un opérateur sur un ou deux opérandes de type table donne aussi une table. Dans une expression, lorsqu'il faut comparer une valeur avec une table qui est le résultat d'une opération algébrique, il doit y avoir une conversion (souvent automatique) du type de la table en une valeur scalaire. Cette opération est similaire à celle du CASTING des langages de programmation. Par exemple, une table intermédiaire composée d'un seul attribut peut être convertie en un ensemble de valeurs ou, à la limite, en une seule valeur avant d'être utilisée dans un prédicat de comparaison ou d'inclusion. Si un opérateur est binaire, il exige au moins deux tables, tandis qu'un opérateur unaire en nécessite une seule. En plus des tables opérandes, un opérateur relationnel particulier peut avoir d'autres arguments constitués d’une liste d’attributs, d’une liste de fonctions ou d’un prédicat.

Opérateur uninaire: Op-unaire(<table-opérande>, [argument1, argument2]) Opérateur binaire : <table-opérande> Op-binaire <table-opérande>



63

5.2.1 Projection C’est un opérateur unaire qui permet d’enlever des attributs dans une relation et de renommer, au besoin, un ou plusieurs attributs retenus. On note la projection par le symbole ∏A, B, F (R), où R (A, B, C, D, F) est l'opérande de la projection et les attributs (A, B, F) la liste des attributs de projection. Avec cet exemple, le résultat est une table de degré 3 et de schéma (A, B, F). Le degré de la relation réponse correspond au nombre d’attributs dans son schéma et pour la projection, il est normalement plus petit que celui de la table opérande. Par exemple, on aura la projection de la table Compte sur deux de ses attributs : ∏ nom, solde (Compte) - - résultat est une table de degré 2, soit réponse ∏ noCompte (Compte) - - résultat esy une table de degré 1 La définition de la projection est la suivante : soit la relation R(A, B, C) dont l'extension est r, alors la projection de r sur A et B est notée : ∏A,B (R) = {(a,b) | ∃ c et (a, b, c) ∈ r} Syntaxe générale : ∏<liste-attributs> (<expression-algébrique-table>) où <expression-algébrique-table> est une table ou une expression de type table qui résulte de l’évaluation de l’expression.

Usages de la projection La projection permet d'effectuer les opérations suivantes sur une table : a) Suppression des colonnes dans une extension finale ou intermédiaire. Dans l'expression ci-dessous il n’y a qu'une seule opération, soit la projection, et l'extension obtenue est dite finale puisqu'elle n'est pas reprise par un autre opérateur.

∏ solde, nom (Compte) = solde nom

2000.00 Renée 1500.00 Christine 1000.00 Sylvie 2500.00 Thomas 3000.00 Renée 4000.00 Christine

Figure 5.1 Remarque : L’ordre et le libellé des attributs de la réponse correspondent à ceux de la liste de projection et non à l'ordre des attributs dans le schéma de la table Compte. L’ordre des tuples est quasi aléatoire. b) Création d'alias ou renommage des attributs dans la relation réponse.

∏ noCompte folio (Compte)



64

folio <--- alias c100 c200 c300 c150 v400

Figure 5.2 La colonne noCompte est renommée avec l'alias folio qui remplace le libellé noCompte dans l'affichage du résultat. Ce renommage temporaire peut être aussi effectué par l'opérateur algébrique de renommage (représenté par la lettre grecque rhô) que nous verrons plus loin. L'opérateur de projection permet donc de modifier dans la réponse, le nom affiché pour un attribut ou le résultat d'un calcul, et cela sans modifier la sémantique et le domaine des attributs dans le dictionnaire de la base de données. Lorsque le libellé d'un attribut est remplacé par un alias, ce dernier devient le nom temporaire de la colonne correspondante dans la réponse et au besoin, peut être réutilisé par un opérateur subséquent de l’expression algébrique. Un alias composé avec plusieurs mots doit être encadré avec des guillemets simples. Par exemple : ‘folio bancaire’. Voici une expression algébrique composée d’une projection et d’une sélection σ(cite = 'Montréal' or cite = 'Québec') ∏ville cite (Clientr)) Dans cette expression, l'alias cite défini par la première opération de projection est repris par un autre opérateur appelé la sélection qui utilise l'alias (et non l’attribut ville) dans son argument-prédicat. Le résultat affiche une table dont la seule colonne est libellée cite . c) Effectuer un calcul avec les attributs de la projection : Les valeurs des attributs de la projection peuvent être transformées par une expression arithmétique ou de chaîne ou par des fonctions. ∏ solde * .05 finteret (Compte) Le premier élément de la liste des attributs est une expression arithmétique qui transforme la valeur du solde pour chacun des tuples de la table Compte, tandis que le deuxième élément est un alias à l'expression pour identifier la colonne du résultat affiché. d) Supprimer les tuples identiques dans le résultat de la projection. La projection d'une relation Personne qui contient 10 000 tuples sur l'attribut sexe donnera 2 tuples après élimination des doublets. Cette opération peut être lourde à réaliser avec une table volumineuse, car elle exige un tri des tuples du résultat avant même son affichage. Cette suppression des doublets n’est pas implémentée directement dans les SGBD; il faut le préciser avec un paramètre DISTINCT qui lance l’opération de tri.

Projection en SQL L'algorithme pour formuler une projection de base en SQL est le suivant : 1- La liste formée avec les attributs, les alias ou les expressions de transformation des valeurs de projection est placée dans la clause SELECT. Normalement, cette liste est un sous-ensemble de la relation opérande. 2- L'opérande simple ou celui obtenu par l'évaluation d'une autre expression algébrique est placé dans la clause FROM.



65

3- Si les doublets doivent être supprimés comme le veut la sémantique de l'opérateur de projection, il faut utiliser la clause SELECT DISTINCT. Dans le cas contraire, les doublets sont conservés. Exemples : ∏nom, noCompte folio , solde /4 solde_corrige(Compte)

SELECT nom, noCompte [as] folio, solde/4 [as] solde_corrige FROM Compte; SELECT solde - 5000.00 [as] “solde réduit” FROM (SELECT noCompte, solde FROM Compte) WHERE nomSucc = ‘Plateau’) ;

Opérande est une expression qui calcule une table temporaire dont le schéma est composé des attributs de la liste de la sélection.

Estimé de la cardinalité de la projection La taille du résultat de la projection dépend de la taille de l'extension de l'argument et de la nature de l'attribut. Si l’attribut de projection est une clé alors card (rép) = card (r) . Si l’attribut de projection n’est pas une clé, la taille de la réponse dépend de la probabilité d de doubles dans lʹextension avec les attributs de la liste de projection. Cette dernière peut être estimée en fonction du facteur de sélectivité de lʹattribut. card(rép) = card(r) - d * card(r) = (1-d) card(r) où d est la probabilité dʹavoir deux tuples ayant les mêmes valeurs pour les attributs de projection. Alors, (1‐d) est la probabilité d’avoir deux tuples ayant des valeurs différentes pour les attributs de projection. Lʹestimé de cette probabilité repose sur lʹhypothèse simplificatrice que toutes les combinaisons de toutes les valeurs des attributs sont également présentes dans lʹextension. De sorte, que lʹestimé obtenu est une valeur de borne supérieure. Cas 1: liste avec un seul attribut Pour la projection sur un seul attribut, on aura que card(rép) = card(r) - d* card(r); où d est la proportion des tuples dans r qui ont des valeurs différentes. En transformant légèrement cette expression, on a : card(rép) = (1-d) * card(r) Le terme (1-d) = V(a,r)/card(r) avec le facteur V(a, r) défini comme étant le nombre de valeurs différentes de l'attribut a dans l'extension r. Donc card(rép) = (V(a,r) */card(r))* card( r) = V(a,r) En normalisant le V(a,r) par rapport à l'extension card(r), on obtient le facteur de sélectivité défini comme le ratio fs = V(a,r) /card(r). La cardinalité de la réponse est donc proportionnelle au facteur de sélectivité de l'attribut de projection. Plus un attribut a un fs près de 1, plus il est sélectif. Plus le fs est inférieur à 1, plus il est non sélectif.



66

Cas 2 : liste de deux attributs Pour deux attributs, la probabilité d'avoir deux tuples qui coïncident sur les valeurs des attributs de projection a et b est estimée par la probabilité conditionnelle suivante : card(rép) = (1-d) * card(r) = (V(a,r) * V(b,r)) * card(r)/ card(r) = V(a,r) * V(b,r)) où V(a,r) est le facteur de sélectivité non normalisé par rapport à card(r) de l'attribut a dans R. Cette formule fournit une limite supérieure en assumant que l'extension est formée du produit cartésien des valeurs de tous les attributs de r. Exemple : Soit une extension de 4000 tuples de la table Choix (nas*, nom, age) dont les valeurs du domaine respectif sont uniformément utilisées. Il y a 50 noms différents dans la base et 25 âges différents. Quel est l’estimé de la réponse à la question suivante : quelles sont les personnes (distinct par leur nom) inscrites dans la table Choix ?

fs (nom) = V(nom, choix) / card( choix) fs(nom) = 50/ 4000 = .012

Donc card(réponse) = .012 * 4000 = 50 tuples Pour la requête suivante : Lister le nom et l'âge des personnes inscrites dans la base, le nombre de tuples anticipés est de l’ordre de 1000. card(réponse) = V(nom, choix) * V(age, choix) = 50 * 25 = 1000 tuples. La taille de la réponse surprend, car la réalité peut être bien en dessous de 1000 tuples. L'estimé est une limite supérieure qui suppose que l'extension contient toutes les combinaisons possibles de nom et de l'âge. Cela revient à une distribution uniforme des valeurs. card(réponse) = V(n1, choix) * V(agen1, choix) + V(n2, choix) * V(agen2, choix) + … Or, V(agen1, choix) = 1 et de même pour les autres; de sorte que la cardinalité de la réponse est précisément la somme du nombre total d'occurrences de chaque nom dans l'extension, soit le nombre de tuples dans la table Choix. Un calcul plus précis est possible si le système fournit la répartition réelle des valeurs dans la base. Or cette statistique est calculée périodiquement par le moteur SGBD et rangée dans le dictionnaire. Elle sera utile au module optimiseur pour réarranger la requête afin de minimiser le temps d’exécution.

Algorithme de projection Pour calculer la projection d'une relation de base R, il faut enlever les attributs absents de la liste de projection et supprimer aussi les doublets.

1- Balayage de l'extension de R avec la suppression en pipeline des attributs non demandés dans la réponse. La notion de pipeline signifie qu’en cours d’accès aux tuples, seules les valeurs qui correspondent aux attributs de la projection sont retenues. 2- Tri des tuples en utilisant les attributs de la projection comme critères de tri avec la suppression des doublets.

Le coût du balayage est m lectures de pages de R, le coût de l'écriture des pages temporaires est de n pages ( n < m), puisque il y a eu suppression des tuples identiques . Le coût du tri pour les pages sur disque est de l'ordre de nlogn. Au total, le coût est de l'ordre de (m + n) + nlogn. Un algorithme tout aussi performant pour la projection est possible avec une fonction de Hashing.



67

5.2.2 Sélection (restriction) Cet opérateur sélectionne des tuples dans une relation au moyen d'un prédicat. Le résultat est une relation dont le schéma est identique à celui de la relation argument. La cardinalité du résultat est moindre que celle de son argument. Syntaxe générale :

σ<prédicat-sélection> (<expression-algébrique>)

Le prédicat ou condition de sélection est évaluée à V ou F pour chaque tuple de l’opérance qui est une relation de base ou une autre expression algébrique dont l’évaluation donne une table. Par exemple, l'expression algébrique dans la sélection doit donner au terme de son évaluation une table comme le sous-tend le contexte de cet opérateur. Le prédicat de sélection est formulé qu’avec les attributs de son opérande et son évaluation fournit un booléen, vrai ou faux. Exemple : Voici la base formée de deux relations : Client (nom*, age, rue, ville) -- nom est la clé primaire Ventes (noTrans*, article, nom, villeT) La requête pour trouver les clients de Montréal est formulée ainsi :

σ ville = ‘Montréal’(Client)

L'expression est de type table et le résultat du même type contient les tuples qui correspondent aux clients de Montréal. La relation réponse a un schéma identique à son opérande et son extension est la suivante :

Client : nom* age rue ville jacques 23 11 des pins Montréal sylvie 24 30 des lilas Montréal

Figure 5.3

Définition formelle de la sélection relationnelle La sélection est définie par la formule logique ci-dessous où t est une variable de tuple de la relation r et p le prédicat de sélection qu'il satisfait. σp(r) = {t | ((t ∈ r) ∧ (p(t) = TRUE) } et card (σp(r) < = card (r)) La formule est évaluée par l’instanciation de la variable t avec chacun des tuples de la table opérande.

Formulation SQL de la sélection Remarque : Parallèlement à l’étude des opérateurs, il est intéressant d’observer comment chacun est implémenté dans le langage SQL. L’objectif recherché n’est pas d’étudier SQL, mais de voir le lien sémantique entre l’algèbre et le SQL. Rappelons que toute formulation SQL est articulée autour de trois clauses de base : SELECT, FROM et WHERE.



68

- Sélection simple : σ ville = ‘Montréal’(client)

La formulation d'une sélection algébrique en SQL est fort simple. La table opérande de la sélection est spécifiée par la clause FROM, le prédicat avec le WHERE et les attributs du schéma de la réponse sont listés avec le SELECT. La sélection est dite simple puisque le schéma de la table réponse correspondant à celui de l’opérande. La sélection précécente se traduit ainsi :

Select nom, age, rue, ville –- attributs de la table réponse From Client -- table opérande Where ville = ‘Montréal’ ; -- prédicat de sélection

ou encore

SELECT * --(*signifie tous les attributs de la table opérande) FROM Client WHERE ville = 'Montréal';

- Sélection avec une projection

∏nom,rue, ville (σ age > 20(Client)) Dans ce cas, la liste des seuls attributs de la projection apparaît dans le SELECT. Exemple :

SELECT nom, rue, ville FROM Client WHERE age > 20;

Une sélection avec une projection utilise une liste partielle du schéma de la table opérande.

Suppression des doublets dans la réponse La suppression des doublets est indiquée par le mot clé DISTINCT.

SELECT DISTINCT nom --liste des attributs de projection FROM Client WHERE age >= 20 And age <= 35; --prédicat de sélection

Le filtrage des doublets peut alourdir la sélection puisqu'il nécessite parfois un tri, notamment en l'absence d'un index approprié sur l'attribut nom. Dans l'exemple suivant, le prédicat de sélection est de type inclusion et l'ensemble de comparaison utilisé par le prédicat est calculé une seule fois par une expression de table appelée couramment une sous-requête et dont la table réponse est convertie automatiquement en un type d’ensemble de valeurs.

∏nom (σville IN (σville = ‘Québec’ (ClientDebiteur)) (Client))

Nous verrons plus loin que l’expression algébrique peut être aussi représentée par un arbre de requête qui est souvent plus facile à écrire et à interpréter que la forme linéaire ci-dessus..

SELECT DISTINCT nom FROM Client WHERE ville IN



69

(SELECT ville FROM ClientDebiteur WHERE region = 'Québec');

Le prédicat peut faire appel à une sous-requête qui retourne un ensemble de valeurs dont la plus grande valeur est choisie par la fonction MAX(). Cette fonction a donc un opérande de type ensemble de valeurs.

∏nom (σage = MAX((∏age(Client)))(Client))

La clause SQL correspondante est la suivante :

SELECT nom FROM Client WHERE age = MAX(SELECT age FROM Client);

Cette clause SQL fournit le nom des clients les plus âgés du groupe. On peut donc voir par ces quelques exemples que la complexité de la sélection est concentrée dans la formulation de son prédicat dans lequel la table résultat d’une sous-requête est convertie en un ensemble de valeurs du type imposé par la condition.

Formes possibles du prédicat de sélection Le prédicat est une formule logique (sans quantificateur) évaluée à vrai ou faux et dont la complexité varie de la simple condition formulée avec une constante à celle faisant intervenir une expression algébrique complexe. S’il y a lieu, la conversion des résultats intermédiaires est automatique pour respecter la compatibilité des types. 1- Prédicat de la forme : ai θ k où k est une constante ou une expression algébrique scalaire du même type que celui de l’attribut ai comme par exemple une chaîne, un type numérique ou un type défini par le système - θ est un des opérateurs binaires suivants : =, ¬ ' =, >, <, < =, > =' . Exemples de prédicats : salaire > 25000.00 And salaire < 75000.00 age = 25 OR dateNaissance < ’25-JAN-1968’ La constante de type chaîne est convertie en type date, soit le type de l’attribut dateNaissance Voici un exemple d'une constante obtenue par l'évaluation d'une sous-requête :

ageVendeur = ( ∏ age(σ nom = 'jacques' (Client)))

Dans ce dernier exemple, l'expression algébrique du prédicat correspond à une sous-requête. Cette dernière fait l'objet d'une évaluation dont le résultat est une table avec obligatoirement une seule valeur et qui est convertie en scalaire pour avoir un type compatible avec celui de l'attribut ageVendeur. 2- Prédicat de la forme ai θ aj, où ai et aj sont des attributs simples ou des conditions logiques formulées avec les attributs simples qui appartiennent au schéma de la relation; Exemples : Ventes(no-article, cout, prix) Where cout > prix Where cout > prix * .90



70

3- Prédicat d'inclusion: ai ∈ (ensemble de valeurs). Cet ensemble peut être énuméré, calculé par une autre expression (ou par une sous-requête) ou formulé sous forme d'un intervalle borné et fermé. Dans ce cas, la sous-requête fournit une table qui est convertie automatiquement en un ensemble de valeurs.

Exemple d’ensembles spécifiés de diverses façons :

ai ∈ (1, 4, 8, 23, 45, 90) -- ensemble énuméré ai ∈ (50 - 90) -- ensemble borné ai ∈ ( ∏ age (Client)) – ensemble calculé (sous-requête)

À noter que le prédicat d'inclusion peut être aussi l'objet d'une négation : ai ∉ (∏ age (σnom = 'jacques' (Client))) En SQL, le prédicat d'inclusion dans un intervalle fermé (bornes incluses) peut aussi s'exprimer avec la syntaxe BETWEEN x AND y. Les bornes sont présumées ordonnées, de sorte que le prédicat x < y soit vérifié.

ai Between x And y

σage Between 15 and 40(Employe) Exemple SQL du prédicat :

SELECT * FROM Employe WHERE age Between 15 and 40; -- ensemble défini par des bornes

Par contre, si les bornes ne sont pas données en ordre croissant, il y aura une erreur.

SELECT * FROM Employe WHERE age Between 40 and 15; --**ERREUR, bornes inversées**

Il y aura une erreur signalée lors de la compilation de cette requête parce que la borne inférieure est plus grande que la borne supérieure dans le prédicat d’inclusion. 4- Le prédicat peut aussi comparer un attribut avec une valeur retournée par l'exécution d'une fonction d'agrégation ou d'une fonction de tuple. La table réponse ne contient qu’une seule valeur et elle est convertie en un scalaire : ai = Max(∏ age(Client)) L'argument de la fonction Max est une table temporaire dans laquelle la plus grande valeur est choisie. Celle-ci est retournée sous la forme d'un scalaire (avec conversion automatique de type). En SQL :

SELECT nom, ville FROM Client WHERE age = (Select Max(age) From Client);



71

Il faut remarquer que la fonction est utilisée dans la liste des attributs du Select de la requête imbriquée. Pour afficher les articles inscrits dans une table Transaction (noArticle*, cout, prix) et vendus avec profit ou perte, il faut utiliser la fonction Least() dont l’argument est composé de deux attributs. Pour chaque tuple, la fonction examine les attributs et retourne la valeur la moins grande : ∏ noArticle (σprix - Least(prix, cout) > 0 (Transaction))

5- Prédicat pour tester la présence de l’indicateur de l’absence d’une valeur. Quelques prédicats particuliers sont disponibles en SQL pour vérifier si l'attribut est associé à NULL ou pas : IS NULL et IS NOT NULL.

σ ville is NULL(Client) En SQL : SELECT *

FROM Client WHERE ville IS NULL ;

Propriétés de la sélection La sélection affiche quelques propriétés intéressantes qui peuvent être utilisées dans la formulation des clauses SQL. a) Commutativité de la sélection: σp1(σp2(r)) = σp2(σp1(r));

En SQL, l’expression algébrique de gauche est formulée ainsi :

SELECT * FROM (SELECT * FROM R WHERE p2) WHERE p1; -- p1 est un prédicat simple ou complexe

Comme le résultat d'une requête est une table intermédiaire, elle peut donc apparaître dans la partie du FROM de la clause principale. La commutativité admet cette deuxième expression ci-dessous comme étant équivalente à la précédente .

SELECT * FROM (SELECT * FROM R WHERE p1) WHERE p2 ;

où p1 et p2 sont des prédicats SQL. Si le prédicat p1 est plus restrictif que p2 et si par surcroît p1 est indexé, alors le calcul de la table intermédiaire sera vraisemblablement plus rapide et le résultat moins volumineux. b) La transformation de la cascade des opérateurs logiques AND ( ∧ ): •p1 (•p2 (•r ) ) =

•p1•p2 (r) = ••p2•p1(r)

En SQL la sélection avec p2 est formulée comme une sous-requête

SELECT nom, rue, ville FROM (SELECT nom, rue, ville FROM Client WHERE nom = 'Gagnon') WHERE ville = 'Lévis' ;



72

Cette requête est équivalente à la suivante au regard de la règle des cascades :

SELECT nom, rue, ville FROM Client WHERE nom = 'Gagnon' AND ville = ‘Lévis’ ;

Le prédicat conjonctif est évalué avec chaque tuple et cela lors d’un seul parcours des tuples de la table Client.

c) Identité avec la sélection σp2 (r) = r, si le prédicat p2 est absent de la sélection, donc de la clause

WHERE, alors tous les tuples sont réputés choisis par un prédicat implicitement vérifié par chaque tuple de la table.

SELECT * FROM Client; --tous les clients vérifient le prédicat absent!

Optimisation des requêtes Ces propriétés algébriques des opérateurs sont utilisées par le SGBD au cours de l'optimisation syntaxique d'une requête, c'est-à-dire avant sa transformation en un plan d'exécution par le SGBD relationnel. Par exemple, il sera plus efficace de remplacer une cascade de sélections par une seule sélection dont le prédicat est formulé avec une conjonction des prédicats de la cascade. Une telle transformation permet alors de vérifier le prédicat conjonctif par un seul parcours des tuples de la table.

Sélectivité de l’opérateur de sélection La sélectivité de l'opérateur de sélection, soit fs, s'exprime par rapport à son prédicat p et correspond à la fraction des tuples d'une extension r qui vérifie le prédicat p. L'évaluation de ce facteur dépend de la forme du prédicat de sélection. Le résultat est un estimé qui repose sur l'hypothèse de la distribution uniforme des valeurs des domaines. La cardinalité de la réponse d’une sélection est la suivante : card(σ p (r)) = fs * card(r) où fs est la proportion des tuples qui vérifient le prédicat de sélection p .

Formes du prédicat de sélection et les fs correspondants Rappel : La fonction V(a,r) retourne le nombre de valeurs distinctes de a dans la présente extension de la table r. Une distribution uniforme de a est aussi présumée dans l’extension. 1- ( a = k ) => fs = 1/ V(a, r) 2- (a > k ) => fs = ( max(a) - k) / (max(a) - min(a)) 3- (a <k ) => fs = (k - min(a)) / (max(a) - min(a)) 4- ( a IN <liste-valeurs> => fs = ( 1/V(a, r) ) * card(listeDesvaleurs), car fs = 1/V(a1, r) +1/V(a2, r) +... +1/V(aj, r) où aj est la dernière valeur dans la liste. 5- ( p et q) => fs(P) * fs(Q) où fs(P) est le facteur de sélectivité du prédicat P. 6- p ou q => fs(p) + fs(q) – fs(p * q) 7- (not p ) => 1 - fs(p) où :

min (a) est la borne inférieure du domaine actif de l'attribut a; max (a ) est la borne supérieure du domaine actif de l'attribut a;



73

V(a, r) peut être aussi définie comme la cardinalité de la projection de r sur a.

Implémentation de la sélection : Forme Normale Conjonctive (FNC) Le calcul de la réponse de la sélection est fortement conditionné par la forme de son prédicat et par l'existence d'un index sur les attributs utilisés dans le prédicat de sélection. Pour évaluer une sélection, la condition est en premier transformée en Forme Normale Conjonctive (FNC), i.e. en une suite de facteurs (en conjonction les uns avec les autres) évaluée par les lois de l'algèbre de Boole. Chaque facteur peut cependant inclure des termes, composés avec d'autres opérateurs, tels ceux de comparaison et d'inégalité. Exemple : Voici une condition complexe pour une sélection de la forme : ( d ∧ n ) ∨ m (dateN < '19-jan-1998' AND nom = 'Clément') OR (mat = '1234') La transformation en FNC donne la condition ci-dessous de la forme (d ∨ m ) ∧ ( n ∨ m) , deux facteurs en conjonction, dont chacun comprend deux termes disjonctifs. (dateN <'19-jan-1998' OR mat='1234')AND(mat='1234' OR nom = 'Clément') (FNC1) L'expression en FNC1 est formée de deux facteurs : le premier est composé d'un terme disjonctif incluant l'inégalité < . Cet opérateur relationnel est une notation abrégée pour une suite de termes disjonctifs : dateN = '19-jan-1998'OR dateN = ’18-janv-1998’OR dateN = ’17-janv-1998’OR . . . De même la condition ci-dessous est en FNC puisque chaque facteur est composé d'un seul terme. (nom = 'Bouchard') AND ( noAtelier = 'a1') (FNC2)

Évaluation dʹune condition de la clause Where Avec la condition FNC2 de l’exemple précédent, le SGBD peut vérifier la présence d'un index du genre Hashing sur l'entrée composée des attributs <nom, no-atelier>. S'il existe, l'index peut identifier directement les tuples de la réponse à cette sélection. On dit alors que la sélection utilise l'index comme chemin d'accès (ACCESS PATH). Si un des deux attributs n'est pas connu, l'index Hashing devient inutile. Avec un index en B-arbre dont l'entrée composée comprend les attributs <nom, noAtelier>, l'absence du 2e attribut n'empêche pas l'exploitation de l'index. Ce dernier sera cependant inutilisable lorsque le premier attribut de l'index n'apparaît pas dans la condition. Si aucun index n'est disponible, le SGBD fera un balayage séquentiel de la table (Full table scan). Avec la FNC1 de l’exemple précédent, s'il y a un index de type Hashing sur le matricule mat et un autre sur nom, il devient possible de sélectionner rapidement les tuples qui seront par la suite testés (en pipeline) avec les éléments du terme disjonctif, soit la date. S'il est du type composé avec ces deux attributs, il ne sera pas très utile en raison de l'opérateur OR! En l'absence de tout index, le SGBD fera un balayage de la relation Employe.

Évaluation dʹun terme disjonctif Un terme disjonctif contient l'opérateur OR : ( nas = '124' OR noAtelier = 'a1'). La condition de cet exemple est formée d'un facteur et de deux termes. S'il y a un index sur chaque attribut, les tuples de la réponse sont obtenus rapidement. S'il n'y en a pas, un balayage séquentiel de l'extension de la table sera nécessaire (full scan table). S'il n'y a qu'un attribut d'indexé, il n'est pas très utile, car il faudra faire quand même faire le balayage complet de l'extension de la table.



74

Procédure algébrique Une procédure algébrique correspond à une expression algébrique complexe formulée avec plusieurs opérateurs algébriques dont l'évaluation fournit une table réponse. Cette procédure est composée de plusieurs façons : a) Par imbrication des opérateurs: ∏ nom, ville (σprenom = 'Marie-Claude' (Client)) Cette expression linéaire peut être aussi représentée par un arbre de requête qui se lit et est exécuté de bas vers le haut. La sélection est exécutée dans une première étape, suivie de la projection. La réponse est une table :

nom ville Julien Québec Prévert Montréal

Figure 5.4

Expression algébrique et le SQL Voici une expression algébrique pour lister l’information sur les comptes bancaires dont le numéro est supérieur à 3000 et qui sont la propriété du client Vézina. ∏nom, noCompte folio(σnom =ʹVézinaʹ and noCompte >3000(Compte)) Cette sélection suivie de la projection est formulée simplement en prenant le prédicat de la sélection et en le formulant avec la clause Where de SQL, la liste des attributs de la projection devient les attributs de la clause Select et finalement, l’opérande de table Compte est référencé au niveau de la clause From.

SELECT nom, noCompte [as] folio FROM Compte WHERE nom = 'Vézina' And noCompte > 3000;

Lʹarbre de requête de l’expression algébrique est le suivant :

σ prenom = ‘Marie-Claude’

Client

∏ nom, ville

∏ nom, noCompte folio

Compte

σ nom = ‘Vézina’ and noCompte > 3000 1

2



75

A noter, que la sélection est exécutée en premier (1) et quʹà cette étape, lʹalias ou le synonyme folio nʹest pas encore connu et ne peut pas être utilisé dans le prédicat de la sélection. Le prédicat de sélection ne peut référencer que les attributs de la relation de base, Compte. La deuxième opération, la projection (2) inclut la présence de lʹalias précédé éventuellement du mot clé AS (SQL‐2) afin de redéfinir de lʹattribut noCompte. L’alias est alors connu au moment d’afficher la table réponse. Le même calcul peut être fait avec une table calculée dans le FROM au moyen dʹune sous‐requête. Avec cette formulation l’alias peut être référencé dans le Where.

SELECT nom, folio FROM (SELECT nom, noCompte [as] folio FROM Compte) WHERE nom = 'Vézina' and folio > 3000 ;

La sous-requête placée entre parenthèses dans la clause FROM est calculée en premier et, la réponse devient une table temporaire utilisée pour le reste du calcul. La table temporaire a une colonne renommée avec l’alias folio. On dit que la sous-requête est matérialisée puisqu’elle correspond à une table physique temporaire. La dernière partie du calcul peut utiliser l'alias folio puisque la table correspondant à la projection est calculée. Dans certains systèmes (exemple : INGRES-IBM), il est possible de définir une variable temporaire du type relation et de lui assigner une extension. Le type relation a un schéma correspondant à celui de la réponse. Exemple avec une variable de table Ces variables du type table peuvent être aussi implémentées sous forme d'une vue relationnelle. Voici une variable du type table dont le schéma est identique à celui de Client, mais dont l'extension ne contient que des tuples concernant la cliente Marie-Claude :

clientr = (σnom = ‘Marie-Claude’ (client)) La réponse est obtenue par une projection de cette variable de table sur l'attribut ville. réponse = (∏ville (clientr)) Le schéma de Clientr est (nom, rue, ville). Il est celui d'une table intermédiaire ou d'une vue relationnelle du même nom définie par le SQL. La relation réponse est celle affichée ou rangée dans un fichier externe nommé réponse. La table clientr est normalement supprimée automatiquement à la fin du calcul de la réponse.

σ nom = ‘Vézina’ and folio> 3000

∏ nom folio

∏ nom, noCompte folio Compte

La sous-requête



76

5.2.3 Renommage dʹune relation et de ses attributs Il existe un opérateur unaire ρ (rhô) qui permet de renommer une relation intermédiaire et ses attributs. Il permet donc de définir un alias de relation ou un alias d'attribut comme cela peut être fait en partie par l’opérateur de projection. ρR(A, B, C) (T(X, Y, Z)) Le résultat du calcul de cet opérateur est une relation temporaire R(A, B, C) dont le degré est identique à celui de la relation T, mais avec un schéma renommé (A, B, C ). Cet opérateur permet aussi de nommer temporairement un attribut qui représente le résultat d'une expression. Dans l'expression algébrique ci-dessous, la relation T est renommée R et l'augmentation de 20% de la valeur de X est renommée A. σ(A > 25) ( ρR(A, W, Z) (∏ X * 1.20, W, Z (T))) On peut aussi écrire le renommage global dʹune relation par lʹexpression suivante : ρR(T). La relation T est renommée R et les noms dʹattribut restent les mêmes. Ce renommage global permet de donner deux noms différents à la même relation de manière à pouvoir la manipuler concurremment avec deux opérateurs différents. Cet opérateur définit un alias sans traitement sur les données de la table, tandis que la définition d’un alias par la projection en sous‐tend un. De plus, le renommage ne change pas le type des colonnes. Exemple : Renommmage de la table Ouvrier(matricule, nom, ville) en Empl(nas, nom, cite) ρEmp(nas, nom, cite) (Ouvrier(matricule, nom, ville) L’arbre de requête correspondant : En SQL, le renommage est fait avec la définition des alias pour les attributs et/ou pour les relations.

SELECT matricule [as] nas, nom, ville [as] cite FROM Ouvrier [as] Emp ; SELECT CL.nom [as] debiteur, C.noCompte FROM Compte [as] C, Client [as] CL WHERE C.noCompte = CL.noCompte and C.solde < 0 ;

La table Compte est renommée C, tandis que la table Client est renommée comme alias CL. Lʹattribut nom de la table Client est renommé debiteur. N.B. le [as] est facultatif et n’est pas toujours disponible. ; il est souvent remplacé par l’espace.

5.2.4 Produit cartésien de deux relations L’opérateur produit cartésien est de type binaire et permet de générer une relation dont le schéma est obtenu en juxtaposant celui des deux relations arguments. Sa notation est : r x w, où r est l’extension de la relation R et w est l’extension de la relation W.

∏

Ouvrier (matricule, nom, ville)

Emp(nas, nom, cite)



77

L’extension est toutefois construite par la combinaison sans restriction de tous les tuples des deux extensions. Le produit cartésien r x w est une nouvelle relation dont le schéma est obtenu par l’union des schémas de R et W. Ainsi on aura Client x Compte qui fournira toutes les combinaisons possibles entre les tuples de la table client et ceux de la table compte.

Compte: noCompte* nomSucc solde nom c100 Montcalm 2000.00 Thomas c200 Limoilou 1500.00 Sylvie

Figure 5.5 Le résultat de cet opérateur est constitué de tuples qui ne correspondent pas tous à la sémantique de la base. Par exemple, le produit cartésien ci-dessus associe les clients avec un compte dont ils ne sont pas nécessairement les propriétaires. Le produit cartésien seul est peu utile dans l'exploitation d'une base de données. Il est généralement combiné avec une sélection pour donner la jointure. Le résultat du produit cartésien est obtenu en prenant chaque tuple de la relation client pour le combiner avec chaque tuple de la relation compte. La relation obtenue est la suivante : (relation temporaire) : partie Client ** partie Compte

nom* rue ville noCompte nomSucc solde nom Thomas 20 des roses Québec c100 montcalm 2000.00 Thomas Thomas 20 des roses Québec c200 limoilou 1500.00 Sylvie Sylvie 35 des lilas Montréal c100 montcalm 2000.00 Thomas Sylvie 35 des lilas Montréal c200 limoilou 1500.00 Sylvie

Figure 5.6 De toute évidence, le produit cartésien seul n'est pas un opérateur très intéressant, car il génère des faits faux ou encore des incohérences temporaires parmi les tuples de la réponse intermédiaire. Le schéma de la relation résultat (les attributs) est cependant correct. Par exemple, le deuxième tuple représente thomas de la rue des roses, propriétaire d'un compte bancaire à limoilou et dont la propriétaire est Sylvie! Il y a une contradiction dans ce tuple. Pour corriger cette réponse, il suffit de filtrer les tuples du produit cartésien avec un prédicat de sélection approprié constitué des attributs communs aux deux relations. En combinant ainsi ces deux opérateurs, on crée un nouvel opérateur dit de jointure, puisque le schéma résultant correspond à la jointure des schémas des relations. Si l’on veut connaître le nom de la succursale où Thomas et Sylvie déposent leur argent, il suffit de sélectionner les tuples du produit cartésien où apparaissent des noms identiques pour l’attribut nom. Le filtrage des tuples est réalisé avec le prédicat : Client.nom = Compte.nom

nom* rue ville noCompte* nomSucc solde nom Thomas 20 des roses Québec c100 Montcalm 2000.00 Thomas Sylvie 35 des lilas Montréal c200 Limoilou 1500.00 Sylvie

Figure 5.7

Client: nom* rue ville Thomas 20 des roses Québec Sylvie 35 des lilas Montréal



78

Le résultat de cette combinaison d'opérations donne un résultat significatif et correct, exempt de tuples l’interprétation serait fausse.

5.2.5 Jointure de relations La combinaison indissociable de la paire d'opérateurs de sélection et du produit cartésien est formalisée par un nouvel opérateur binaire appelé la jointure. Cette suite d’opérations est indissociable pour éviter de retenir des tuples faux du produit cartésien. réponse = (σp (r x w)) ≡ r |x|p w où p est la condition du filtre, c'est-à-dire le prédicat de la jointure : Client.nom = Compte.nom Cette expression est représentée sous la forme d’un arbre de requête : Dans le cas d'un filtre (prédicat) spécifié implicitement par l'égalité des valeurs pour les attributs communs, la jointure est dite naturelle. La forme du prédicat p déterminera d'autres jointures : la jointure thêta et l’équijointure.

Définition formelle du produit cartésien Si R et W sont respectivement les schémas des extensions r et w, le produit cartésien (r x w) est une relation de schéma (R ∪W) dont l’extension est formée des tuples t qui vérifient le prédicat suivant : {t ∈ r x w | ∃t1∈ r et ∃t2 ∈w et t[r] = t1 [r] et t [w] = t2 [w]} Rappelons que le produit cartésien, sans filtre ou sélection, fournit des tuples qui ne correspondent pas toujours à la sémantique des tuples recherchés. Certains représentent des faits faux éliminés par le prédicat de la sélection.

Jointure naturelle (|x|) et jointure thêta (|x|θ ) Il y a au moins deux jointures importantes en algèbre relationnelle : a) La jointure naturelle avec un prédicat p est définie implicitement par une égalité sur les valeurs de tous les attributs de même libellé pris successivement deux à deux. Les colonnes redondantes sont supprimées dans la réponse. La jointure naturelle est notée simplement : r |x| w. Le prédicat de jointure est donc sous-entendu dans la définition de la jointure naturelle. Celle-ci est un cas particulier de la jointure thêta laquelle peut avoir un prédicat complexe qui enrichit l’égalité. Ainsi, on aura : Client |x| Compte = (σnom = nom (Client x Compte)) Pour éviter toute ambiguïté dans la référence aux attributs, il est possible, et souvent nécessaire, de préfixer ceux-ci par le nom de la relation à laquelle ils appartiennent respectivement : Client |x| Compte = (σ Client.nom = Compte.nom (Client x Compte)) Dans certains cas, la condition de jointure doit être formulée autrement que par l'égalité. Par exemple, avec l'inégalité : (Client.solde > Ventes.total) . C'est une jointure valide qui doit cependant avoir un sens pour l'utilisateur qui formule la requête et qui utilisera le résultat!

|x| p

r w



79

b) Jointure thêta (θ) : Lorsque le prédicat de filtrage est complexe (faisant intervenir des attributs des deux relations avec divers opérateurs logiques ou avec des opérateurs de comparaison), il est appelé prédicat thêta (θ). Ce dernier définit le filtre de la jointure. Avec cette jointure, la sélection des tuples du produit cartésien est faite après évaluation du prédicat thêta pour chaque combinaison de tuples. Le prédicat est formulé avec les attributs des deux opérandes dont les libellés ne sont pas nécessairement les mêmes ; ils doivent avoir cependant des domaines compatibles. Sa notation est la suivante : r |x|θ w. Le prédicat θ peut comprendre les opérateurs et prédicats suivants :

Opérateurs: =, <, >, != ) Prédicats: IS NULL, IS NOT NULL, IN et NOT IN

Très souvent, le prédicat θ comprend une égalité sur au moins deux attributs de même domaine en plus des autres parties de la condition de filtrage. Une jointure thêta avec un prédicat vide correspond au produit cartésien des deux relations. Exemples : a) L'équivalent de la jointure naturelle : client |x|θ compte où le prédicat complexe θ est défini comme suit : Client.nom = Compte.nom AND (Compte.solde > 15000.00 OR Compte.solde = 0). Cette requête fournit toute l’information sur les clients et leurs comptes dont le solde est zéro ou supérieur à 15000.00. Cette jointure thêta formulée en SQL :

SELECT nom, noCompte, solde FROM Client, Compte WHERE Client.nom = Compte.nom and (Compte.solde >15000.00 OR Compte.solde = 0.00) ;

Requête complexe sous forme dʹune arborescence Une requête est une formule algébrique plus ou moins complexe dont les opérateurs unaires et binaires sont représentés par les noeuds internes d'un arbre de requête dont les opérandes en sont les sous-arbres. L'arbre de requête est compilé, et une copie est souvent conservée dans la zone de mémoire partagée (shared RAM) du SGBD pour une réutilisation éventuelle par d'autres applications.

Figure 5.7a

L'arbre de requête est toujours exécuté logiquement du bas vers le haut. Ainsi, dans l'arbre ci-dessus, la jointure est la première opération effectuée, suivie par la sélection, et le calcul se termine par la projection. Le calcul d'un opérateur binaire ou unaire donne un résultat

|X| θ = Compte.nom = Client.nom

Π nom, noCompte, solde

σ solde >15000.00 OR solde = 0.00

Compte Client Ordre logique d’exécution de l’arbre de requête



80

intermédiaire qui est aussi une relation qui peut servir comme opérande à l'opérateur suivant dans l'arbre de la requête. En pratique, l’ordre d’exécution sera celui équivalent établi par l’optimiseur et matérialisé par le plan d’exécution.

Procédure de calcul de la jointure de deux relations r et w : ( r |x|θ s ) Une requête est traitée par le calcul de ses divers opérateurs et au terme duquel la réponse est obtenue. Dans la jointure, le prédicat θ est spécifié par une formule aussi simple que R.a > S.b et dans lequel il existe une compatibilité obligatoire entre les domaines des attributs a et b.

Algorithme par boucles imbriquées sans indexation Cet algorithme parcourt les deux tables. Pour chaque tuple de la première table, il y a parcourt de tous les tuples de la deuxième table.

i = 1 ! indice de position du tuple dans l’extension r t.q. r ≠ ø et i < = card (r) faire lire ti ∈ r -- lire un tuple de l'extension r r = r - ti -- marquer le tuple ti comme lu j = 1 !indice de position d’un tuple dans l'extension s t.q. s ≠ ø et j < = card(s)

faire lire lj ∈ s si ti[a] = lj [b] alors ti || lj --concaténation j = j + 1 <- tuple suivant dans la 2e extension

fin i = i + 1 fin fin.

Algorithme avec boucles imbriquées Figure 5.7b Cette procédure n’utilise aucun mécanisme rapide d’accès pour accéder aux tuples, i.e. ni index ni tri. Elle est formée par deux boucles imbriquées pour comparer tous les tuples des deux relations. Cette procédure, quoique simple est rarement utilisée en raison de sa lourdeur pour la jointure, sauf pour celle faite entièrement en RAM et avec des petites extensions. Elle sera de préférence remplacée par autre procédure exploitant les index sur les attributs de jointure, voire des index dynamiques, pour éviter d’effectuer un produit cartésien complet.

Coût dʹexécution de la jointure Les extensions de R et S utilisent respectivement m et n pages sur disque. La relation R sera lue une fois page par page au coût de m pages. La relation S sera lue du disque autant de fois qu'il y a de pages utilisées pour stocker l'extension de R, soit m* n. Au total, il y aura m + (m*n) pages d'échangées. Si m = 1000 pages et n = 5000 pages, et si une lecture de page prend 10 ms, alors le temps de jointure sera de 1 x 103 * (5 x 103) = 5 000 000 * 10 ms, soit près de 14 heures! Cette procédure est la plus coûteuse. En principe, pour alléger le coût d'exécution, il y a avantage théorique à placer la plus petite relation comme premier opérande (6) afin de minimiser les échanges de pages de données avec l'extension la plus importante. D’autres algorithmes plus performants sont bien connus : jointure par boucles imbriquées avec indexation, jointure par adressage calculé (Hashing) et la jointure par tri-fusion. Le choix dépendra de plusieurs variables, notamment de l’ordre des tuples



81

préexistant dans les extensions, de la cardinalité des relations et du facteur de sélectivité des attributs de jointure. Le moteur SGBD tiendra compte de ces paramètres pour établir sa stratégie de jointure

Jointure par boucles imbriquées avec indexation La présence d'un index sur un attribut de jointure permet d'accélérer le calcul de la jointure de R et S. La relation indexée s devient la relation intérieure de la boucle imbriquée.

Algorithme de jointure avec indexation Dans ce cas, il s’agit encore d’une seule boucle à l’intérieure de laquelle les tuples de la 2 ème table sont obtenus via l’index :

Faire pour chaque tuple de r∈R -- R est non indexée {Pour chaque tuple s ∈ S – S est indexée jointure <r, s>; --index pour trouver les tuples de S ayant la valeur r.A }

Cet algorithme est encore plus efficace si l'index exploite un regroupement physique des tuples qui partagent une même valeur de jointure et qui sont rangés dans la même page de données (clustering des pages).

Jointure par Hashing avec deux dispersions des tuples Deux relations R et S ont respectivement m et n pages de tuples. Les extensions sont trop volumineuses pour être stockées totalement dans la RAM et la card(R) << card(S). L'algorithme consiste essentiellement à partitionner les tuples de R et de S sur la base d'une fonction de Hashing h1. Le résultat du Hashing avec l'attribut de jointure R.A détermine la partition où le tuple sera temporairement stocké. Lorsqu'une partition est complète, elle peut être placée sur disque pour permettre la formation des autres partitions. Les débordements éventuels sont gérés par chaînage ou par un deuxième Hashing, h2. Pour chaque ti ∈ r, on a h1(ti.A) = k où k est le no de la 1ère partition-cible. Les tuples de R et ceux de S qui ont la même valeur de jointure sont rangés dans des partitions différentes, mais de même indice k. Il peut y avoir aussi d'autres valeurs pour l'attribut de jointure qui donnent la même valeur calculée. C'est très souvent le cas avec le Hashing à quelques collisions près. En distribuant correctement les tuples de R et de S, on peut alors conclure que les tuples de la partition k de R ne seront joints qu'avec ceux de la partition k de S. Lors de la jointure, il faudra aussi vérifier qu'une même valeur de l'attribut de jointure A est partagée par les deux tuples, celui de la partition de R et celui provenant de la partition de S. Ensuite une autre table est créée avec la fonction h2 et les tuples de R (la moins volumineuse). Cette deuxième dispersion gère les collisions. La table est composée du rowid et de la valeur de l'attribut de jointure du tuple. Pour une partition de R, il y a une deuxième dispersion des tuples pour créer une table de Hashing, i. e. calculer une adresse où le tuple de R de la partition est momentanément rangée. Chaque partition de l'extension de S est ensuite balayée pour vérifier la présence d'un tuple dans la table de Hashing. Lorsque le test est positif, la jointure des deux tuples est effectuée et le résultat est placé sur disque. Phase 1 : Partitionnement des tuples de R Les tuples de R et S sont rangés dans différentes partitions sur la base de leur valeur de Hashing.



82

La création de ces partitions permet le regroupement respectif des tuples de R et de S sur la base de leur valeur de Hashing calculée avec h1. Ces partitions sont placées au besoin sur disque par le module de calcul du logiciel SGBD. Chaque partition est indicée par une constante k qui varie de 0 à une borne supérieure fixée par la fonction de Hashing. Par exemple, la fonction modulo Np où Np est un nombre premier fixe la borne à la valeur de ce nombre. Dans l'exemple ci-dessous, h1= modulo 5 et permet d'avoir 5 partitions indicées de 0 à 4. L'application d'une 2e fonction de Hashing permettra de résoudre les collisions de sorte que dans une même partition, on y retrouve que des tuples ayant des valeurs de Hashing différentes. Par contre, si deux tuples différents donnent la même valeur de Hashing, ils sont en collision. Phase 2 : Création de la table de Hashing avec la fonction h2 (r.A) Chaque partition de R fait l’objet de la construction d’une deuxième table de Hashing avec la fonction h2.

Partitions de R

Partitions de S

collisions

R rid1: a, b, 6 rid3: d, e, 11

k=0

k=2

k=1 rid1: 6 rid3: 11

k= 3

mod 5

S rid4 : x, w, 11 rid8: x, y, 6

k=0 k=1 rid4: 11 rid8: 6

k=3 k=2 mod 5

Hashing h2 pour la partition k =1 de R k=0

k=2

k=1 rid1: 6 rid3: 11

k= 3

Partitions de R

collisions

rid3 : 11 rid1: 6

1 2 3 4 5 6 7

h2 = mod7



83

La fonction h2 disperse à nouveau les tuples de R afin de résoudre les collisions du Hashing et obtenir une valeur unique et discriminante comme indice. Chaque partition de R aura sa table de Hashing utilisée immédiatement pour tester si les tuples de la partition S de même indice doivent être concaténés pour former un tuple de la table réponse.

Phase 3 : Balayage de chaque partition de S Pour chaque tuple, il y a un test avec la table de Hashing h2 de la partition k de R.

Figure 5.7c Algorithme de jointure par Hashing -- Dispersion de R en k partitions, card(R) < card (S); Pour chaque tuple r ∈ R ( plus exactement tr ⊆ R ) lire r; calcul k= h1(r.A); -- quelques valeurs de r.A donnent le même k ajout de r dans la partition Pk de R; -- Partitionnement de S en k partitions; lire s; calcul k = h1(s.A); -- quelques valeurs de r.A donnent le même k ajout de s dans la partition Pk de S; -- création de la table et testing Pour chaque partition j = 1, ..., k de R { -- construire la table de Hashing courante. Autant de tables que de partitions Pour chaque r ∈ R { lire r; k = h2(r.A); -- nouvelle dispersion des tuples d'une partition de h1 placement de r en position k dans la table de Hashing de cette partition; } --test des tuples de S de la partition de même k Pour chaque tuple s ∈ S -- balayage de S { lire s; k = h2(s.A); -- Test table de Hashing à l'adresse k, écrire <r, s> sur disque et -- vidanger la table de Hashing de la partition courante et fin du traitement }

rid3 || rid4 rid3 : 11 rid1: 6

1 2 3 4 5 6 7 8 9

Partitions de S

k=1 rid4: 11 rid8: 6

rid = adresse logique du tuple



84

Coût de l’exécution : la phase de partitionnement effectue m + n lectures de pages de R et S écrites à nouveau sous forme de partitions nouvellement formées. Le coût est donc de 2* (m + n ) lectures de pages. En ne présumant aucun débordement, la phase de création et de testing exige la lecture des partitions, soit m + n pages. Au total, le coût est de l'ordre de 3*(m + n) lectures. Avec m = 1000 pages et n = 5000 pages et 10 ms pour chaque lecture de page, seulement 3 minutes seront nécessaires pour effectuer la jointure. Cet algorithme peut aussi être utilisé avec une jointure sur plusieurs attributs. La fonction de Hashing s'applique alors sur la combinaison des champs de jointure. Elle ne peut pas cependant être utilisée avec une jointure thêta comportant une inégalité. Dans ce dernier cas, la jointure sera calculée par boucles imbriquées avec indexation (B+arbre) des attributs de la jointure thêta.

Cardinalité de la jointure La cardinalité du résultat d’une jointure est certainement plus petite que le produit cartésien en raison du prédicat θ qui agit comme un filtre de sélection . card( r |x|θ w ) <<< card(r x w ) La cardinalité d'une jointure dépendra du facteur de sélectivité de son prédicat de jointure. La taille de la jointure est généralement estimée, car son calcul exige la connaissance de la distribution effective des valeurs des attributs de jointure. card( r |x|θ w ) = fj * ( card(r) * card(w) ) où fj est le facteur de sélectivité de la jointure.

En supposant l’indépendance des attributs de jointure r.a et w.a et une distribution uniforme des valeurs de r.a et w.a , le nombre de tuples de r qui sont joints à un tuple w est donné par le ratio (card(r) / V(a, r)) . Donc, comme il y a card(w) tuples dans w, la jointure avec un prédicat d’égalité contient alors (card(r) / V(a, r) ) * card(w). Par conséquent, on peut déduire que fj = 1/V(a,r). card( r |x|θ w ) = ( 1/V(a,r)) * card(r) * card(w) où V(a, r) est le nombre de valeurs distinctes de l’attribut de jointure dans la table R.

Propriétés des opérateurs de jointure : x et |x| et |x|θ La jointure a quelques propriétés utiles pour transformer une expression en une autre équivalente. Ces transformations peuvent donner des plans d’exécution qui sont équivalents tant qu’aux résultats, mais plus rapide en ce qui a trait au calcul. a) Commutativité : Le produit cartésien et la jointure sont considérés comme étant commutatifs. Pour cela, il faut supposer que les valeurs d’un tuple sont implicitement typées par le nom de l’attribut correspondant. r |x| w ≡ w |x| r Cette commutativité vaut aussi pour le produit cartésien des relations R et W : r x w ≡ w x r Il en est de même pour la jointure thêta. Exemple : Deux extensions simples pour R1 et R2 :



85

R1 : a : number b : float R2 : a : number y : float 2 2.5 2 3.5 R1 |x| R2 : a b y 2 2.5 3.5 R2 |x| R1 a y b 2 3.5 2.5 Apparemment le résultat n’est pas le même tuple, sauf s’il est lu en tenant compte des domaines ou du nom des colonnes : (2 : a, 2.5 : b, 3.5 : y) = (2 : a, 3.5 : y, 2.5 : b) b) Associativité du produit cartésien et de la jointure : ((r x w) x u) ≡ (w x (r x u)) (produit cartésien) ((r |x| w) |x| u) ≡ (r |x| (w |x| u)) (jointure naturelle) Il en est de même pour la jointure thêta. Cette propriété permet d’exécuter en premier la jointure dont on sait que la réponse sera moins volumineuse que celle de l’autre produit. En ce faisant, il pourrait y avoir théoriquement moins lectures sur disque pour obtenir les pages de données nécessaires pour le calcul de la réponse à la jointure.

Produit cartésien En SQL, le produit cartésien est formulé sans clause WHERE. C’est cette absence de prédicat et la présence d’au moins deux tables dans la clause From qui singularisent de la jointure. Par exemple, voici une base formée avec les tables suivantes qui définissent les localisations des aéroports majeurs, des vols progammés et des villes capitales comme destination. AeroportMajeur (nomA*, villeA), Vol (noV*, nomA, nomC) Capitale (nomC*, pays) Un vol est un trajet défini comme un segment entre un aéroport (nomA) et une capitale (nomC). La table Vol représente les vols actuellement opérationnels entre un aéroport et une capitale. Cette base permet aussi de simuler tous les vols possibles entre un aéroport et une capitale. Avec deux tables ayant respectivement 1000 et 10 tuples, la cardinalité du produit cartésien est card(AeroportMajeur x Capitale) = 10 000 de tuples, soit autant de vols directs possibles. Π AeroportMajeur.ville, Capitale.pays ((AeroportMajeur x Capitale))

Ce résultat donne tous les vols possibles entre les capitales et les aéroports importants. La clause SQL équivalente est la suivante :

SELECT AI.nomA, C.nomC FROM AeroportMajeur AI, Capitale C;

-- absence du WHERE sous-tend le produit cartésien



86

Complément d’un ensemble La différence entre les projections de la table Vol et le résultat du produit cartésien fournit la liste des vols possibles et encore disponibles pour relier les capitales à partir des aéroports jugés importants. Synthèse : formulation d’une expression algébrique en SQL Une requête SQL comporte généralement 3 clauses ou parties : SELECT, FROM et le WHERE. Rappelons que lors du calcul d'une réponse, l'expression du prédicat de sélection est évaluée pour avec chaque tuple de la table utilisée comme opérande. Pour faire le passage au SQL, il faut distinguer plusieurs cas de figure impliquant la sélection, la projection et la jointure.

R : A B C 2 4 8 16 32 64 128 512 1024

a- Projection uniquement : La liste de projection - les attributs, les expressions et les alias - est insérée dans la partie SELECT. La relation opérande de la projection ou une expression équivalente est placée dans la partie FROM de la clause. L'expression équivalente peut entraîner le calcul d'une table temporaire. Exemple : La projection sur les attributs A, B de la relation opérande R(A, B, C)

SELECT A, B FROM R;

Si un attribut de la projection est transformé par une expression arithmétique, c'est le résultat qui est affiché avec au besoin la colonne de la table réponse est libellée par un alias:

SELECT A+30 [as] A_Plus, B FROM R;

Le résultat est une table dont le schéma comprend 3 attributs soit A_plus, B et E. la valeur de la première colonne, soit A-Plus est la valeur de A augmentée de 30. réponse: A_Plus B 32 4 46 32 158 512 b- Sélection seule Le prédicat de sélection est placé dans le WHERE et la liste des attributs de la réponse est placée dans le SELECT. Ce prédicat peut prendre toutes les formes étudiées précédemment.

SELECT A, B, C FROM R WHERE A >30 And B < 900;

Le prédicat de la sélection peut être aussi du type inclusion. La clause SQL se construit alors de façon similaire en utilisant soit une énumération de l’ensemble de référence ou soit en formulant



87

une autre expression pour le calculer. Notez bien qu’un ensemble de valeurs est noté par les parenthèses. - Ensemble énuméré de valeurs admissibles :

SELECT A, B, C FROM R WHERE A >30 And B < 900 And A IN (2, 4, 56, 158, 200);

- Ensemble défini par deux bornes :

SELECT A, B, C FROM R WHERE A >30 And B < 900 And (A>2 And A >200);

- Ensemble calculé par une autre clause SQL (dite sous-requête) :

SELECT A, B, C FROM R WHERE A >30 And B < 900 And (Select AA From ValeursAdmissibles);

Dans ce dernier exemple, le prédicat de la sélection est de type inclusion dans un ensemble qui est calculé par l’évaluation d’une autre clause SQL. Cette dernière est calculée une seule fois au tout début pour former un ensemble énuméré temporaire. Le résultat de ce calcul donne une table temporaire convertie automatiquement en un ensemble de valeurs typées et compatibles avec la valeur de A. Le calcul de la réponse consiste donc à parcourir la relation R pour ne retenir que les tuples qui vérifient le prédicat évalué pour chaque tuple lu dans R. c- Combinaison d'une projection et d'une sélection Si la liste du SELECT comprend moins d'attributs que le schéma de la table opérande R, cela indique une projection. Le prédicat de sélection est précisé dans la clause Where.

SELECT A, B <--liste partielle des attributs de la table R FROM R WHERE A >30 and C IN (SELECT C FROM T);

d- Combinaison de projection, sélection et jointure thêta La présence d’au moins deux tables dans le FROM indique une jointure. Le WHERE fournit la condition de jointure et éventuellement en sus le prédicat de sélection. Si la liste du SELECT est un sous-ensemble du schéma de l'opérande formé avec le résultat de la jointure, cela sous-tend aussi une projection. Avec les relations Client et Compte, la jointure thêta de l’algèbre se formule en SQL de la façon suivante :

SELECT C.nom, Co.solde FROM Client C, Compte Co WHERE C.nom = Co.nom And Co.solde between 3000 and 5000;



88

Les alias C et Co sont des alias de table obtenus par renommage des tables (opérateur rhô). En principe, la sélection pourrait est faite en premier; elle est suivie s'il y a lieu de la jointure, pour se terminer par la projection. Toutefois la présence de sous-requêtes bouleverse légèrement cet ordre, car les sous-requêtes sont toujours évaluées en premier. Il y a aussi la présence des index sur les attributs du prédicat qui peut influencer le plan d’exécution cde cette clause. Quant à la jointure naturelle, sa formulation fait appel à une condition de jointure qui est souvent une égalité entre les attributs ayant le même libellé :

SELECT C.nom, C.ville, V.total_achat FROM Client [as] C, Ventes [as] V WHERE C.nom = V.nom;

Union (∪) et intersection (∩) des relations L’union permet l’ajout de tuples dans l’extension d’une relation existante ayant le même schéma. Cet opérateur exige donc la compatibilité des domaines et des schémas. La notation algébrique est la suivante : r1 ∪ r. Exemple : Lister les clients emprunteurs ou déposants à la succursale Ste-foy.

(∏ nomC (σ nomS = ʹSte‐Foyʹ(Pret)))

∪ (∏ nomC (σ nomS = ʹSte‐Foyʹ(Depot)))

L’opérateur d’intersection se formule aussi comme un opérateur binaire. Les opérandes sont soit l’extension (prêt), soit selement le nom de la relation (Prêt).

5.2.6 Union en SQL L'union de deux extensions est réalisée avec la suppression des doublets, sauf indication contraire avec le mot clé ALL. La formulation SQL de l’expression algébrique est directe avec une table opérande placée de part et d’autre de l’opérateur binaire de l’union.

(SELECT nomC FROM Pret WHERE nomS = 'Ste-Foy') UNION [FOR ALL] sans suppression des doublets (SELECT nomC FROM Depot WHERE nomS = 'Ste-Foy');

Implémentation de lʹunion par le tri des extensions Cet opérateur ensembliste peut être implémenté par un tri ou par Hashing. Le calcul de (D ∪ E) par le tri est fait par l'algorithme suivant : 1- Tri de R et de S en utilisant tous les attributs comme critères; 2- Balayage en parallèle et alterné des extensions triées, accompagné d’une fusion avec une suppression des doublets. L'algorithme peut être accéléré en créant des monotonies triées (sous-lots de tuples triés sur les mêmes attributs) et en procédant à leur fusion parallèle au moyen de plusieurs processeurs.



89

Implémentation de lʹunion par calcul de Hashing Les extensions des relations D et E sont partitionnées au moyen d'une fonction de Hashing h. Les critères de Hashing sont tous les attributs du schéma. Les tuples qui génèrent le même entier sont classés dans la même partition.

Algorithme général de lʹunion 1- Partitionnement des extensions D et E avec la fonction h pour donner respectivement les partitions Dj et Ej 2- Traitement de chaque Dj de la façon suivante : 2.1 Construire une table de Hashing Hj avec la fonction h2; chaque entrée de la table est formée de chaque tuple de la partition Pj en traitement. Cette fonction permettra une meilleure dispersion des tuples donnant la même valeur de Hashing. 2.2 Pour chaque tuple de la partition Ej , si le tuple est dans la table de Hashing construite avec la partition de Dj , il est supprimé, sinon il est ajouté dans la table de Hashing. 2.3 Écrire la table de Hashing et vidanger la table en RAM. 3. fin.

Tri du résultat d’une union La condition essentielle pour faire l’union de deux relations est d’avoir le même degré et le même domaine pour les attributs de même rang. Le résultat de l’union est trié par la sous-clause ORDER BY et le nom de l’attribut (ou son rang) du premier opérande qui agit comme critère de tri. Exemple : Union des tables R et S dont le schéma est compatible.

SELECT A, B, C FROM R UNION SELECT X, Y, Z FROM S ORDER BY A;

5.2.7 Différence (-) (MINUS dans Oracle) La différence entre deux relations exige que celles-ci aient un schéma compatible, c'est-à-dire que les attributs de même rang aient le même domaine : (r1 - r2) = {t | t ∈ r1 ∧ t ∉ r2} La différence permet la suppression de tuples dans l’extension d’une relation, c’est-à-dire l’obtention des tuples présents dans une relation et absents dans une autre de même schéma. Exemple : Soit le modèle relationnel suivant :

Succursale (nomS*, capital, villeS) Client (nomC*, rueC, villeC) Depot (nomS, noCompte*, nomC, solde) Pret (nomS, noPret*, nomC, montant)

a) Lister les clients qui sont des épargnants sans emprunt à la succursale ‘Loubet’. (∏ nomC (σ nomS =‘Loubet‘ (Depot))) - (∏ nomC (σ nomS = ‘Loubet’ (Pret))) b) Lister les emprunteurs qui ne sont pas des épargnants à la succursale ‘Loubet’ :



90

réponse = (∏ nomC (σ nomS = ‘Loubet’ (Pret))) ‐‐ (∏nomC (σ nomS =‘Loubet‘ (Depot)))

La différence exige la compatibilité des schémas d’opérande, i.e. identité des domaines pour les attributs de même rang. La différence permettra éventuellement de formuler l’opération ensembliste d’intersection lorsque ce dernier opérateur n'est pas implémenté dans le langage de données du SGBD en usage.

Différence en SQL La différence est formulée avec deux sous‐requêtes, chacune fournissant une table opérande dont les schémas sont compatibles.

(SELECT nomC FROM Pret WHERE nomS = 'Loubet') DIFFERENCE -- (ou MINUS pour le SGBD Oracle) (SELECT nomC FROM Depot WHERE nomS = 'Loubet');

Chaque opérande de la différence peut être une expression algébrique aussi complexe que nécessaire.

5.2.8 Intersection (∩) entre deux relations Une intersection entre deux relations sous-tend une identité des schémas respectifs. Elle peut s’exprimer seulement par des différences. Le schéma de la réponse est identique à celui de l'un des deux opérandes R1 ou R2 . R1 ∩ R2 = (R1 - (R1 - R2)) Cet opérateur n’est pas commutatif : (R1 – R2) ≠ (R2 - R1) et (R1 - (R1 - R2)) ≠ ((R1 - R2) - R1)

Intersection en SQL Pour trouver les clients qui déposent et empruntent à la succursale de Ste-foy, la requête SQL-92 est la suivante:

(SELECT nomC FROM Pret WHERE nomS = 'Ste-Foy') INTERSECT (SELECT nomC FROM Depot WHERE nomS = 'Ste-Foy');

Π nomC Π nomC

σ nomS =’Loubet’


Pret Depot



91

Chaque partie de la requête retourne un ensemble de tuples de même schéma et l'intersection donne les tuples communs aux deux ensembles.

Implémentation de lʹintersection Le calcul de l'intersection est effectué comme celui de la jointure avec une condition d’égalité sur tous les attributs.

Cette expression est transformée en une jointure avec égalité de tous les attributs : (Prêt |x|θ Depot ) avec θ = Pret.nomC = Depot.nomC And Pret.nomS = Depot.nomS And … Le calcul de la réponse utilise les algorithmes de la jointure.

5.2.9 Division relationnelle Cet opérateur complexe permet d’implanter le quantificateur universel et, de ce fait, le quantificateur existentiel, puisque ∀x P(x) est identique à ¬ ∃x ¬P(x). Avec ce quantificateur, il devient possible de se représenter une requête comme une formule de la logique du premier ordre. Voici le schéma de la base de données sur les activités bancaires :

Succursale (nomS*, capital, villeS) Client (nomC*, rueC, villeC) Depot (noCompte*, nomS, nomC, solde) Pret (noPret*, nomS, nomC, montant)

Par exemple, lister le nom des déposants dans toutes les succursales de la ville de Québec. La variable (attribut), soit nomS, quantifiée universellement fournit la relation qui devient le diviseur et qui, ajouté au schéma de la réponse, devient la relation dividende. Ces relations peuvent correspondent à deux relations de base ou être calculées au préalable par une expression algébrique appropriée. Le domaine et les propriétés de chaque attribut commun au diviseur et au dividende doivent être les mêmes. L’attribut exclusif au dividende est celui de la réponse.

réponse = r2 (Depot.nomC, Depot.nomS) ÷ r1 (Succursale.nomS) La relation r2 fournit les noms de client qui déposent dans toutes les succursales pour autant que la sémantique et le domaine de nomS dans r2 soient les mêmes que ceux de l’attribut nomS dans r1. S’il faut trouver cependant les noms de client qui déposent dans toutes les succursales de la ville de Québec, il suffit de spécifier, s’il y lieu, la procédure algébrique pour calculer au préalable les opérandes de la division afin d’avoir que les succursales de la ville Québec pour chaque opérande. r2 = ∏Depot.nomC, Depot.nomS (depot) [dividende] r1 = ∏ Succursale.nomS (σ Succursale.ville-s = ‘Québec’ (succursale)) [diviseur]

Π nomC Π nomC



Pret Depot

∩



92

En examinant la figure ci-dessus, on visualise facilement la réponse, soit Fortin comme étant le seul déposant à toutes les succursales de la ville de Québec (traits pleins). En effet, il est le seul déposant relié par un arc à toutes les succursales de Québec. Invariance de la réponse de la division L’ensemble diviseur peut être une relation de base sans redondance ou une relation intermédiaire obtenue par calcul et comportant des données redondantes. Il en va de même pour la table dividende. La réponse doit aussi être invariante par rapport à l’ajout d’un nouveau déposant dans une succursale quelconque. Ainsi, Si le déposant Dussault s’inscrit à la succursale de Québec-Centre, la réponse obtenue auparavant ne varie pas. De plus, l’ajout d’une deuxième inscription Québec-Nord dans l’ensemble diviseur ne doit pas modifier le résultat. Cette redondance est plausible lorsque la table intermédiaire est obtenue par calcul, comme par exemple une sélection sur la ville de la succursale dans une table décrivant à la fois les succursales bancaires et les bureaux de ventes des assurances. Dans la formulation de la requête il faudra tenir compte de cette invariance pour avoir une clause algébrique ou SQL correcte. Il est plus simple de concevoir la division avec des relations calculées ayant respectivement deux et un attributs. Cet opérateur est cependant plus général et permet de tenir compte de schémas d'un degré supérieur notamment pour le dividende. Par exemple, il est possible de formuler une division relationnelle pour trouver le nom et la ville des clients qui déposent dans toutes les succursales et Québec et de Ste-Foy.

Définition de la division généralisée Soit le dividende r (R) et le diviseur s (S) pour lesquels S ⊆ R. La réponse est r’(R’). Le schéma de R’ = R ‐ S . La division algébrique est définie ainsi : r ÷ s = r’ (R’) = {t ∈ r’ | ∀ts ((ts∈ s) ∧ ∃ tr(tr ∈r) et (tr[S] = ts[S] et tr[R’] = t[R’]))} L'expression R-S est une différence de schéma et donne les attributs de R (dividende) qui ne sont pas dans S (diviseur) et qui sont les attributs de la réponse. Naturellement, le degré de la relation R est supérieur au degré de la relation S et les attributs du quotient sont toujours ceux qui sont présents que dans le schéma de R. Chaque attribut du diviseur doit obligatoirement partager le même domaine avec l'attribut correspondant du dividende. Soit les relations de base Terminus et GrandeVille ci-dessous. La deuxième table regroupe les villes dont la population est supérieure à 700 000 personnes et qui sont considérées comme étant des grandes villes.

Québec-Centre

Québec-Sud

Québec-Ouest

Québec-Nord

Fortin Gingras

Turgeon

Dionne

Bion

diviseurdividende



93

Terminus : societe ville GrandeVille : ville Collins-t Trois-Rivières New York Orleans Toronto Montréal Collins-t Louisville Toronto Orleans Montréal Orleans Syracuse Rapid-t Toronto Suite: Orleans new york Orleans Rimouski

Figure 5.8 L’attribut Teminus.ville et GrandeVille.ville n’ont pas exactement le même domaine. En effet. le premier domaine est composé de villes peu importe la taille de sa population, tandis que le deuxième est composé que des villes considérées comme des grandes villes. Le domaine sémantique de l’attribut GrandeVille.ville est inclu dans celui de Terminus.ville. Lorsqu’une ville apparaît dans la relation GrandeVille, cela signifie qu’elle est considérée comme telle parce que la population est supérieure à un critère donnée, soit par exemple que sa population soit supérieure à 700 000 personnes. Quelles sont les sociétés qui ont un service de car avec un terminus dans toutes les grandes villes ? Ici, il s'agit de trouver les sociétés qui ont un terminus dans chaque grande ville représentée dans la relation GrandeVille au moment du calcul de la réponse. La division relationnelle algébrique est formulée ainsi :

Réponse = Terminus* (societe, ville) ÷ GrandeVille (ville) * L’étoile signale que cette relation diffère de celle de base par le domaine de ville En effet, le domaine de Terminus.ville n’est pas le même que celui de GrnadeVille.ville. . Le schéma de la table réponse est composé que de l’attribut societe. R’ = R – S = { societe, ville) } – {societe} = {societe} Par contre, l’attribut ville de chaque opérande doit avoir le même domaine sémantique, soit celui des grandes villes. Pour que le domaine Terminus.ville soit celui de GrandeVille.ville, il faudra faire une sélection par la jointure des terminus situés dans les grandes villes. Lorsque qu'un langage de données possède cet opérateur, la formulation de la division consiste essentiellement à fournir l’expression des opérandes si ceux-ci ne correspondent pas aux relations de base. Le calcul de la division suppose donc l’implémentation d’un algorithme efficace.

Expression algébrique équivalente à la division En l'absence d'un opérateur de division relationnelle dans le langage de données, il y a une expression algébrique équivalente qui permet de calculer la réponse :

r ÷ s = ΠR-S(r) – ΠR-S((ΠR-S(r) x s) - r)

où : R est le schéma de la relation formé des attributs du dividende et S est le schéma de la relation diviseur formé avec le ou les attributs du diviseur (attribut quantifié dans la question). Rappelons que l’extension est représentée par une lettre minuscule. Par exemple r représente les tuples de la relation R. La formule algébrique est complexe ! Exemple : Quelles sont les sociétés ayant un service desservant les gares terminus de toutes les grandes villes ?



94

réponse = Terminus* (societe, ville) ÷ GrandeVille* (ville) Où l’attribut societe est le seul attribut de la réponse et l’attribut ville dans les deux opérandes sont compatibles puisque le domaine du premier inclut celui du deuxième. Calcul de l’expression : r ÷ s = ∏R - S (r) - ∏ R - S ((∏R-S (r) x s) - r) Nous allons détailler le calcul de la réponse en faisant une trace de l’exécution de l’expression algébrique ci‐dessus. Le schéma R’ = R - S = {societe, ville} - {ville} = {societe}, soit le schéma de la réponse obtenue par par ∏R-S . ∏R-S (r)= ∏societe(terminus) = temp1

temp1 : terminus Orleans Rapid-t Collins

Cette extension temp1 fournit tous les transporteurs présents dans la BD sans aucune restriction. Le calcul de toutes les combinaisons des sociétés et des grandes villes, comme si tous les transporteurs avaient un terminus dans toutes les grandes villes est formulé par l’expression suivante : temp1 x grande-ville = temp2 = (∏R-S (r) x s)

temp2 : societe ville Collins New York Collins-t Montréal Collins-t Toronto Orléans New York Orléans Montréal Orléans Toronto Rapid-t New York Rapid-t Montréal Rapid-t Toronto

Figure 5.9 Cette relation intermédiaire correspond à une table dans laquelle plusieurs tuples représentent des faits non vérifiés concernant le terminus des transporteurs dans les grandes villes. Le calcul suivant consiste donc à trouver les tuples erronés dans cette relation intermédiaire (temp3) de la figure 5.9 et à effectuer une différence qui donnera la réponse recherchée.

temp2 - terminus = temp3 : societe ville Collins-t New York Collins-t Montréal Collins-t Toronto Rapid-t Montréal Rapid-t New York

Figure 5.10 L'extension temp3 fournit les transporteurs qui ne vont pas dans au moins une grande ville. ∏societe (temp3) = {Collins-t, Rapid-t} = temp4



95

Finalement la réponse est donnée par la différence entre les deux extensions : réponse = temp1 - temp4 = {Orléans} La société Orléans est le seul transporteur ayant un terminus dans toutes les grandes villes, tout au moins celles listées dans la relation Grande-Ville au moment de l'exécution de la requête. La division relationnelle est rarement implémentée dans le SQL des SGBD; il faut la formuler avec les clauses SQL disponibles. Nous verrons dans le chapitre sur SQL un algorithme pour en faciliter la formulation. Les opérandes de la division peuvent être aussi restreints par un prédicat. Par exemple, trouver les sociétés ayant un terminus dans toutes les grandes villes canadiennes : Montréal, Toronto. Le diviseur doit exprimer le résultat d'une première sélection.

∏ ville(σ ville = ‘Montréal’ or ville = 'Toronto'(succursale))

L’opérande dividende doit aussi être formé en effectuant une projection de la table Terminus pour ne retenir que les terminus situés dans les deux villes canadiennes.

∏ville(σ ville = ‘Montréal’ or ville = 'Toronto'(Terminus))

5.3 Jointure externe La jointure externe est un opérateur qui étend la sémantique de la jointure en incluant dans sa réponse les tuples qui satisfont à la condition de jointure et en y ajoutant (par l’union) ceux de r1 et de r2 n'y participent pas. Le NULL sont ajouté pour les tuples qui ne participent pas à la jointure. La condition de jointure est: θ = R1.A = R2.A.

R1 : A B R2 A C R1 οθ R2 = A B A C a1 b2 a2 c5 a1 b2 a1 c8 a2 b1 a1 c8 a2 b1 a2 c5 a3 b4 a4 c2 a3 b4 null null null null a4 c2

Figure 5.11 N.B. le symbole ο représente la jointure externe complète et le θ la condition de la jointure externe. L’ajout d’un tiret à sa gauche ou à sa droite donnera le symbole de la jointure externe gauche ou droite : -oθ et θo- . La réponse externe est une table dans laquelle les attributs primaires ont un NULL! En effet, pour une relation autre que celle de base, il n’est pas nécessaire que tous les attributs primaires aient une valeur du domaine. En réalité, le système les considère comme une relation dont la clé est un attribut caché, soit le rowid (i.e. l’adresse logique de chaque tuple) de SQL, c’est-à-dire l’adresse du tuple dans la base. La jointure externe complète n’est cependant pas très utile. C'est une opération plus limitée qui a une valeur pratique, à savoir la jointure externe gauche et la jointure externe droite.

Jointure externe gauche ‐oθ Cet opérateur gauche ajoute les tuples de l’opérande de gauche qui ne participent pas à la jointure naturelle ou à la jointure thêta initiale. En d’autres mots, tous les tuples de gauche sont de la réponse. On a ainsi :



96

R1 -οθ R2 = A B A C a1 b2 a1 c8 a2 b1 a2 c5 a3 b4 null null

Figure 5.12

Jointure externe droite θ ο− C’est une jointure naturelle suivie de l’ajout les tuples de l’opérande de droite qui ne participent pas à la jointure initiale. On a donc :

R1 θο− R2 = A B A C a1 b2 a1 c8 a2 b1 a2 c5 null null a4 c2

Figure 5.13 Exemple de l’usage de la jointure externe gauche. Dans ce cas précis avec les relations Employe et Departement on a :

Employe(nas*,nom,dateNaiss,noDep) Departement(noDep*,nasG) Employe : nas* nom dateNaiss noDep Departement : noDep* nasG 311 Christine 2.4.62 d2 d2 225 225 Lyse 1.2.44 d2 d3 220 220 Christine 1.9.64 d3 456 Madiha 6.2.67 d3 201 André 8.3.48 d2

Figure 5.14 Lister les noms d’employé. Si l’employé est aussi gérant, donner le numéro du département dont il a la responsabilité : réponse = ∏ E.nom, D.noDep (employe −οθ departement) avec θ : E.nas = D.nasG En SQL, la jointure externe se formule ainsi :

SELECT E.nom, D.noDep FROM Employe E, Departement D WHERE E.nas = D.nasG(+);

Le symbole (+) se place à la droite de l’attribut de jointure qui aura éventuellement un NULL dans la table résultant du calcul de la jointure externe. La relation temp1 obtenue par la jointure externe gauche est la suivante :

temp1 : nom <-- nas* dateNais noDep noDep <-- nasG Christine 311 2.4.62 d2 null null Lyse 225 1.2.44 d2 d2 225 <-- Christine 220 1.9.64 d3 d3 220 <-- André 201 8.3.48 d2 null null Madiha 456 6.2.67 d3 null null

Figure 5.15



97

Les tuples qui participent à la jointure thêta sont identifiés par la flèche -->; les autres sont ajoutés parce qu’ils ne participent pas à la première jointure. La réponse est obtenue par une projection sur les attributs nom et noDep (soit le second noDep). Ainsi, on effectue la projection sur l'attribut qui représente le numéro de département dirigé, s'il y a lieu, par la personne dont le nom est affiché.

nom noDep * Christine null Lyse d2 * Christine d3 André null Madiha null

Figure 5.16 Dans le cas d’un préfixage incorrect pour l'attribut noDep qui se retrouve avec le même libellé dans deux relations différentes, la réponse pourrait être fausse. On pourrait obtenir l'extension : réponse = ∏ nom, noDep (temp1) Cette opération utilise l’attribut noDep de la table Departement (le premier noDep dans le schéma de la table intermédiaire) et la réponse aura une sémantique bien différente :

réponse: nom noDep Christine d2 Lyse d2 Christine d3 André d2 Madiha d3

Figure 5.17 Ce résultat permet-il d’affirmer qu’il n’y a qu’une seule employée Christine, soit celle qui est gérante du département d2 ? Non, car il y a une autre employée Christine qui n’est pas gérante, mais seulement employée.

Jointure externe complète par l’union Soit deux relations R1 et R2 avec lesquelles il faut calculer la jointure complète au moyen des opérateurs existants de l’algèbre. Pour ce faire, il suffit de faire l’union de la jointure externe gauche avec celle de la jointure externe droite. R1 οθ R2 ≡ ( R1 θο− R2 ) ∪ ( R1 -οθ R2) Il devient alors possible de formuler en SQL les clauses équivalentes. Pour lister les employés et les départements pour lesquels ils travaillent, il suffira de faire l’union des jointures gauche et droite.

SELECT E.nom, D.noDep FROM Employe E, Departement D WHERE E.nas = D.nasG(+); UNION SELECT E.nom, D.noDep FROM Employe E, Departement D WHERE E.nas(+) = D.nasG;



98

Avec la nouvelle norme SQL, l’opérateur FULL OUTER JOIN est proposé pour réaliser cette opération.

5.4 Traitement dʹune requête réflexive en algèbre relationnelle Soit le MCD E/R ayant une association récursive avec la classe Employe. Ce modèle récursif est transformé par spécialisation pour en supprimer le cycle. La spécialisation de la Figure 5.18 est de type (t, o) parce qu’un superviseur est aussi un employé qui a aussi un superviseur et ainsi de suite. L'exploitation récursive est implémentée par des itérations algébriques.

Figure 5.18 La spécialisation de la classe Employe permet d’insérer une nouvelle association de type (1-n) entre les sous-classes créées par la spécialisation. Il devient alors possible de transformer directement cette association dans le formalisme relationnel. Le MRD est le suivant :

Employe (nas*, nom, adresse) Ouvrier (nasOuv*, noDep, nasSeur) Superviseur (nasSeur*, dateDebut)

La suite de requêtes qui sous-tend une fouille itérative est alors plus facilement formulée. Par exemple, lister le nas des ouvriers supervisés par la ou les personnes nommées jean. Cette supervision est soit directe, soit indirecte par l’internédiaire d’une autre personne. La première opération consiste à trouver le nas du ou des employés nommés jean. temp1 = ∏nas (σ nom = ‘jean’ (Employe))

Ensuite, il faut obtenir par projection le nas des employés supervisés et superviseurs : temp2 = ∏nasOuv, nasSeur (Ouvrier) Finalement, il faut identifier les personnes nommées jean qui sont des superviseurs : réponse1 = ∏nasOuv(temp1 |x|nas = nasSeur temp2)

Employe nas* nom adresse dateDebut

supervise superviseur

1 1..n Employe nas* nom adresse

t, o

Superviseur dateDebut

Ouvrier noDep

1..n 1 Supervise



99

Cette supervision est de premier niveau organisationnel et concerne les employés directement supervisés par un employé Jean. Employe : nas* nom adesse Ouvrier : nasOuv noDep nasSeur

75 marie 23 rue A 75 d3 77 80 rémy 32 rue P 55 d4 80 55 josée 67 rue C 34 d6 22 77 jean 28 rue V 22 d2 75 34 renée 12 rue Y 22 jean 3 rue Z

Superviseur : nasSeur dateDebut 77 3.3.86 80 6.1.90 75 4.8.75 22 2.3.89

Figure 5.19 Première opération pour trouver le nas des employés nommés Jean : une sélection suivie d ‘une projection permet d’obtenir une table avec 2 tuples qui représentent une personne nommée jean.

temp1 : nas 77 22

Deuxième opération : recherche des ouvriers supervisés par une personne nommée jean :

temp2 : nasOuv nasSeur 75 77 <--- 55 80 34 22 22 75

Figure 5.20 La réponse attendue est composée des tuples représentant les employés sous la supervision d'une personne nommée jean, peu importe le niveau de supervision.

Recherche des personnes par niveau de supervision : absence de récursivité dans l’algèbre Trouver le nas des employés supervisés directement par jean dont le nas est 77 (premier niveau de supervision). ∏ nasOuv (σnasSeur = 77 ( Ouvrier))

réponse2 : nasOuv 75

La table réponse est formée du nasOuv de l’employé sous la supervision directe de jean.



100

c) Trouver le nas des employés supervisés par les employés supervisés par jean (nas = 77) (deuxième niveau de supervision) : réponse3 = ∏nasOuv (Ouvrier |x| nasSeur = nasOuv temp1)

réponse3 : nasOuv 22

La réponse est 22, soit le nas de jean qui travaille sous la supervision de marie. En résumé, pour lister le nas des employés supervisés à tous les niveaux par jean (nas = 77) il faut, à défaut d’un mécanisme de récursivité, faire une répétition de jointures et cela, tant que la réponse ne soit pas vide. Dans une hiérarchie élaborée, cette fouille peut vite devenir lourde. L’algèbre relationnelle n’est pas récursive. Il faudra un modèle à base logique comme celui de DATALOG pour avoir une réponse élégante à ce problème ou l’implantation de SQL3. Certaines implémentations de SQL (Oracle et de DB2) ont un opérateur particulier pseudo récursif permettant de faire une recherche en profondeur dans une arborescence de tuples. Nous les étudierons dans le chapitre sur le langage SQL.

Complétude et validité de lʹalgèbre relationnelle L'algèbre relationnelle est complète et valide : Complète : Les opérateurs de l’algèbre permettent de composer, plus ou moins facilement, toutes les requêtes possibles sur la base de données. La réponse obtenue est une relation formée des attributs des relations de base. Valide : Les réponses obtenues sont elles-mêmes des relations (propriété de fermeture de l’algèbre) et ont leur propre schéma. À ce titre, la réponse peut faire aussi l’objet d’un traitement subséquent par tout opérateur algébrique. Seule la contrainte d'entité n'est pas obligatoirement vérifiée pour la table temporaire ou les tables réponses.

5.5 Bonification de l’algèbre relationnelle Bien qu’il soit complet, le langage algébrique est un langage minimaliste n’offrant qu'un jeu restreint d'opérateurs. En pratique et pour des raisons de souplesse et d’efficacité, le DML utilisé dans le développement des applications est plus riche que l’algèbre relationnelle. Par exemple, il est utile d'utiliser des fonctions et des opérations spécialisées pour mieux répondre aux besoins des utilisateurs. A l’algèbre de base, il faut ajouter les fonctionnalités suivantes : Les fonctions arithmétiques : +, -, *, /; Les fonctions de groupement et d’agrégation; Les fonctions d’affichage et d’assignation; Les fonctions de chaîne; Les fonctions de mise à jour, d’insertion et de suppression (implantation plus directe de ce que permet l’algèbre avec les opérateurs union et différence); Quelques opérateurs binaires : Intersection, division, jointures spécialisées et semi-jointure. Un filtrage des groupes par le HAVING (le prédicat du Group by).

Fonctions et opérateurs arithmétiques et de chaîne de l’algèbre relationnelle+ Ces opérateurs sont utilisés dans le traitement de chaque tuple examiné lors du traitement d’une requête. L’algèbre de base n’a pas d’opérateurs arithmétiques qui sont utiles dans l’exploitation d’une base de données. On distingue les opérateurs arithmétiques et de chaîne :



101

a) Opérateurs arithmétiques : soustraction, addition, division et multiplication impliquant des constantes, des fonctions et des expressions arithmétiques; b) Opérateurs d’appariement de chaîne (pattern matching) : - || (concaténation). Le symbole | utilisé dans certains systèmes (Interbase) - LIKE pour la recherche de chaînes avec des paramètres de recherche : % et _ On utilise aussi des opérateurs de chaîne dans le prédicat de sélection, de jointure dans la liste de projection, partout où il peut y avoir un attribut.

Recherche avec l’opérateur d’appariement LIKE Une telle recherche est très rapide pour trouver une chaîne qui contient une autre chaîne. L’opération d’appariement de la chaîne est formulée ainsi :

<chaîne à fouiller> LIKE <chaîne recherchée> Il faut préciser un ou plusieurs critères positionnels supplémentaires au moyen du souligné (_) et du % : % Pour représenter une chaîne de longueur quelconque; _ Pour représenter un caractère quelconque à la position où apparaît le souligné.

Utilisation de fonctions et d’opérateurs dans les requêtes L’algèbre ne serait pas très utile sans les diverses fonctions numériques et de chaîne qui s’appliquent à chaque tuple ou à un ensemble de tuples.

Expression arithmétique dans le prédicat : - Lister les employés dont le salaire actuel, augmenté de 10% est supérieur à 25 000.00$. Il suffit d’exécuter cette expression algébrique : σ salaire * 1.10 > 25 000.00 (Employe) Le salaire de chaque employé est augmenté de 10% avant l’évaluation du prédicat de la sélection. - Pour sélectionner les employés travaillant à des projets dont le nombre d'heures estimé pour la réalisation est inférieur à celui du total des heures travaillées par un employé. Employe |x|θ Projet θ = Employe.noProjet = Projet.noProjet And Employe.total-h > Projet.hProjet + 15 - Pour afficher le salaire des Tremblay augmenté de 15 %. ∏ salaire * 1.15 (σ nom = ‘Tremblay’ (employe)) Expression de chaîne avec l’opérateur d’appariement de chaîne - Pour afficher les employés dont le nom commence par la chaîne 'Gagn'. σ nom LIKE 'Gagn%' (employe) Les employés sélectionnés ont un nom similaire à Gagné, Gagnon, Gagnot. La chaîne recherchée de droite est comparée avec celle de gauche. S'il y a lieu, cette comparaison est faite après l’évaluation des expressions de chaîne.



102

σ nom LIKE 'ville%’ (employe) Cette dernière expression sélectionne les employés dont le patronyme débute par le mot ville.

Opérateur de concaténation dans la liste de projection - Afficher le nom et le prénom séparés par un trait d’union des employés de Québec : ∏ nom || '-' || prenom ( σ ville = 'Québec' (employe)) Les traitements effectués sur les données affichées sont temporaires et ne sont pas enregistrés dans la base de données.

Fonctions de l’algèbre+ Il y a deux classes de fonctions ajoutées aux opérateurs de base : les fonctions de tuple et les fonctions d’agrégation. Les premières traitent les fonctions du genre scalaire et les autres du genre chaîne. Ces fonctions sont exécutées sur chacun des tuples sélectionnés dans une relation de base ou dans une relation intermédiaire. Elles sont utilisées partout où il est possible d’insérer une constante, une variable ou un attribut dans une expression algébrique. La fonction retourne toujours une valeur typée. Voici quelques-unes de ces fonctions de tuple dont la sémantique sera étudiée avec plus de détails dans le chapitr sur le langage SQL.

Fonctions arithmétiques ABS (L) Valeur absolue de la variable L. GREATEST (A, B) La plus grande valeur entre deux attributs A et B et pour chaque tuple. LEAST(A, B) La plus petite valeur entre les deux attributs A et B pour chaque tuple. ROUND (salaire, 2) Arrondi de salaire avec deux chiffres après le point. TO_NUMBER (ch1) Conversion d’une chaîne ch1 en valeur numérique. TRUNC (salaire, 2)* Troncature de la valeur de salaire avec deux chiffres après le point. TRUNC(dateProd)* Troncature pour enlever la partie temps de la date codée en format interne. MOD(m, n) Calcul du reste de la division de m par n. TO_DATE (ch1, ‘DD-MM-YYYY’) Conversion de la chaîne ch1 représentant une date en un format spécifié par le gabarit. TO_CHAR (dateEx, ‘YYYY-MM-DD') Conversion de la date en chaîne selon le gabarit indiqué (incluant la suppression du temps). *Cette fonction effectue une troncature avec un résultat différent selon que l'argument est un nombre ou une date. Il faut ajouter à cette liste partielle, les fonctions trigonométriques usuelles. Exemple : Employe (nas*, nom, age, tel, ville, noDep, salaire) ∏ nom, trunc(salaire,0), Trunc(salaire, 2) (σage >35 (Employe))

réponse : nom Trunc (salaire, 0) Trunc (salaire, 2) mathieu 12456 12456.25 suzanne 17345 17345.83

Figure 5.21 En l'absence d'un libellé particulier, le système affiche dans la table réponse la fonction et son argument comme le libellé de la colonne. Supposons que le noDep soit un entier, mais représenté par une chaîne. Alors l’affichage de cet attribut comme un nombre entier se fait ainsi :



103

∏ nom, To_number(noDep)(σ ville = ‘Québec’ (Employe))

réponse : nom To_number (noDep) sylvie 4552 <- entier richard 6814

Figure 5.22 Le nom et le numéro de département, sous la forme d’un entier sont affichés pour chaque employé de la ville de Québec.

Fonctions de chaîne de niveau tuple Une telle fonction utilise une chaîne comme argument d’entrée et retourne une chaîne en sortie. Elle peut être utilisée partout où une variable ou un attribut de chaîne est accepté. Les fonctions de chaîne sont nombreuses et leur nombre peut augmenter selon les versions d'un SGBD.

Fonctions de chaîne UPPER (nom) Conversion du nom en lettres majuscules (haut de case). LOWER (nom) Conversion du nom en lettres minuscules (bas de case). LENGTH (nom) Longueur de la chaîne de l’attribut nom (entier). INSTR (nom, ‘a’) Position de la première occurrence de ‘a’ dans la chaîne nom. SUBSTR (ville, 1, 3) Retourne trois caractères de la chaîne de l'attribut ville et cela à partir du premier caractère. TRANSLATE (nom, 'aeiou', '88999') : Remplace chaque voyelle dans nom par un chiffre fournit le gabarit. La chaîne de l'attribut nom est balayée pour y remplacer chaque caractère de la chaîne fournie par le 2e argument par celui qui, dans le 3e argument occupe le même rang. Ce dernier ne pouvant pas être le NULL. En effet, la plupart des fonctions retournent un null si un de leur argument est aussi un null. Si le rang du caractère à remplacer est plus grand la chaîne de remplacement, alors le caractère est tout simplement supprimé de la chaîne initiale. REPLACE(c1, c2, c3) Dans la chaîne c1, remplacement de toute occurrence de la chaîne c2 par la chaîne c3. Cette dernière pouvant être le NULL. DECODE (score, ‘A’, 4, ‘B’, 3.78, ‘C’ , 2, ‘D’, 1, ‘0’) Pour transposer la valeur de l'attribut score de la manière suivante : si A alors 4 sinon si B alors 3.78, sinon si C alors 2 sinon si D alors 1, autrement 0. Les arguments peuvent être des attributs, des expressions ou des fonctions. Exemples : ∏ nas, age (σ Upper(nom) = 'TREMBLAY' (Employe))

∏nom, matricule (σ To_number(matricule) > 350 (Employe)) ∏nom, matricule ( (DECODE (salaire, salaire < 10000, salaire*1.01, salaire)) (Employe) D'autres fonctions sont aussi implémentées dans les diverses versions de SQL, dont la dernière norme SQL-92, notamment Instr(), NVL() Trim() et Convert(). Elles seront étudiées avec plus de détails au chapitre consacré au langage SQL.



104

5.6 Opérateur de groupement des tuples et fonction d’agrégation Cet opérateur est appliqué à une relation de base ou à une table, résultat intermédiaire d’un calcul et permet de grouper les tuples de la réponse en fonction d’un critère de groupement ou de calculer une donnée d’agrégation pour remplacer les tuples regroupés dans un même groupe. L’opérateur de groupement est noté G et a comme opérande une table et deux arguments : une liste des attributs pour effectuer le groupement, une liste de fonctions d'agrégation applicables à chaque groupement formé avec les tuples de la table opérande. (liste des attributs de groupement) G(liste de fonctions d’agrégation) (expression-algébrique) Ordre d'exécution-> : (2) (3) (1) Cette fonction G( ) est exécutée en plusieurs étapes selon l'ordre indiqué : en premier, l’expression algébrique est évaluée pour obtenir une table, ensuite l'opération de groupement est effectuée avec les tuples de cette tuples et finalement les fonctions d'agrégation sont appliquées sur chaque groupe formé. Le résultat est une table réponse. Cet opérateur est dit unaire parce qu'il utilise un seul opérande de table. On peut par exemple vouloir calculer la moyenne des salaires et le nombre d’employés dans chaque département d'une usine. Ces calculs sont faits avec les tuples de chaque groupement en utilisant les fonctions d'agrégation appropriées.

noDepG(Avg(salaire), Count(*))(Employe) Toutes ces fonctions constituent les services standards d’un bon langage de requête. Les arguments de l’opérateur G sont définis de la façon suivante: a) Attributs de groupement : Obligatoirement des attributs de la table opérande qui peuvent être inclus dans la réponse. Ils servent de critères à la formation des groupes. Dans la réponse, chaque ligne correspond à un groupe de tuples. Ces attributs du groupement limitent en quelque sorte la portée des fonctions d’agrégation et aussi de la réponse. Une projection ne peut être exécutée avant le groupement que si elle ne fait pas disparaître un attribut de groupement ou un attribut d’agrégation; b) Fonctions d’agrégation : Elles servent à agréger les valeurs fournies par les tuples de chaque groupe de la réponse. Elles sont peu nombreuses et bien connues : Avg(). Max(), Min(), Count(),… Une telle fonction est appliquée à chaque groupe formé par la fonction F. En cas d’absence de la liste de groupement, chaque fonction d’agrégation sera appliquée à tous les tuples. L'opérande d'une fonction d'agrégation est un ensemble de valeurs obtenues suite à une opération sur une relation ou par énumération. Le résultat d'une agrégation est généralement un scalaire numérique.

Schéma de la relation réponse de l’opérateur G Il est constitué des attributs de groupement plus les fonctions d'agrégation renommées au besoin par un alias. Les attributs de la liste du groupement peuvent cependant être absents du schéma de la réponse. Exemple : Le groupement est spécifié par la clause GROUP BY et la fonction d'agrégation est placée dans la liste des résultats attendus. L’arbre de requête avec une fonction de groupement est le suivant :



105

Cet arbre de requête est exécuté du bas vers le haut. L’expression algébrique correspondante est formulée en SQL avec un clause spéciale de groupement, soit le GROUP BY.

SELECT cat, Avg(salaire) FROM Employe WHERE age between 20 and 35 and cat IN (1,3,5,7) GROUP BY cat;

Les attributs de la réponse sont fournis par le Group By auquel est ajoutée la seule fonction d’agrégation soit le calcul de la moyenne des salaires pour chaque groupe formé. Voici une expression avec une liste d'attributs de groupement vide. Dans ce cas, toute l'extension de l'opérande devient implicitement le seul groupement pris en compte pas les fonctions d’agrégation.

G(fonctions agrégation) (expression-algébrique de table) Exemple : G Avg(salaire) (Employe)

En SQL : SELECT Avg(salaire) FROM Employe;

La fonction d’agrégation sous-tend un Group By implicite formé avec tous les tuples de la table Employe. Un groupement sans fonction d’agrégation, mais comportant une liste de groupement est formulé ainsi : (attributs de groupement) G (relation) Exemple algébrique : (nom) G (Employe) En SQL :

SELECT nom FROM Employe GROUP BY nom;

La clause FROM est formulée avec l’opérande de G, tandis que la liste des attributs devient obligatoirement celle du GROUP BY. Dans ce cas, le GROUP BY est similaire à un tri nécessaire pour réaliser ce groupement.

cat G Avg(salaire)

σ

Employe

Age Between 20 and 35 and cat IN (1, 3, 5, 7)



106

Arbre de requête avec lʹopérateur G Voici une expression algébrique incluant l'opérateur de groupement G, représentée par un arbre de requête illustrant l'opérateur G et son opérande fourni par le résultat d'une jointure.

Figure 5.23 Cette expression fournit le nombre d’ouvriers de plus de 18 ans ayant le même nom. Le schéma de cette réponse est formé de l'attribut et de l’expression suivantes : (nom, Count(nom)).

nom Count (nom) Desmeules 2 Gagné 1 Rousseau 3

En SQL : SELECT nom, Count(nom) FROM Ouvrier O, Projet P WHERE O.nas = P.nas AND O.age > 18 Group By nom;

Filtrage des groupes Une fois les groupes formés par l’opérateur de groupement G, ceux-ci sont tous utilisés pour la formation de la table de sortie. Toutefois, dans certaines circonstances, il faut filtrer les groupes formés avec la table de base pour en utiliser que quelques unes. L ‘algèbre ne permet pas de formuler directement un filtrage au niveau du groupement, mais autorise une sélection dans la table de sortie de G. Cependant, le langage SQL le permet plus simplement par la sous-clause HAVING p, où p comme une sorte de prédicat de filtrage. Implémentation algébrique équivalente au Groupement Le filtrage des groupes formés par l’opération de G peut être aussi fait par une combinaison des opérateurs de sélection, de renommage et de groupement. Par exemple : Empl (nas*, nom, ville, salaire) Cette table représente le salaire et le lieu du domicile de chaque employé d’une organisation. Pour lister les villes où habitent plus de 5 employés, il faudra recourir à la formation de groupes et les filtrer. L’expression algébrique qui réalise cette opération est la suivante :

(nom) G Count(nom) ∏ nom σ age > 18 Θ = Ouvrier.nas = Projet.nas

Ouvrier Projet

opérande de

|x|



107

Lorsqu’il y a une suite d’opérateurs comprenant un groupement G, un renommage et une sélection, il s’agit probablement d’un filtrage des groupes. Cette sélection est formulée avec un prédicat qui ne peut pas être formulé avec une fonction d’agrégation. Il faut donc renommer la colonne libellée Count(*) qui affiche le comptage par l’alias nb et cela, pour pouvoir y référer dans le prédicat de sélection. En SQL ce filtre est formulé avec la sous-clause Having qui est en quelque sorte un prédicat spécialisé pour la table résultat de G. Le schéma est formé avec les arguments de G.

R_inter : ville Count(*) Montréal 3 Québec 6

SELECT ville, Count(*) [nb] FROM Empl GROUP BY ville Having Count(*) > 5; --comptage des tuples dans chaque groupe

Le filtrage ne peut pas être fait par un Having nb > 5, car au stade du filtrage des groupes, l’alias nb n’est pas encore défini par la projection. La table intermédiaire de sortie n’a qu’un seul attribut, soit la ville où habite plus de cinq employés. Pour obtenir les autres attributs de Empl, il faut faire une autre requête dite de premier niveau en utilisant un prédicat d’inclusion avec les villes sélectionnées par la clause précédente.

SELECT nom, nas, salaire, ville FROM Empl WHERE ville IN (SELECT ville FROM Empl GROUP BY ville Having Count(*) > 5);

σ nb > 5 ρ Empl (ville, nb) ville G Count(*) Empl

Πville

renommage des attributs

Groupement des tuples

Filtrage des groupements



108

Cette requête comporte deux blocs, un premier de niveau 1 et un 2e bloc de niveau 2 correspondant à la sous-requête. Pour afficher le plus grand salaire des employés qui habitent une ville où résident aussi plus de 5 employés, il faudra utiliser un autre niveau de sous-requête en combinaison avec la fonction d’agrégation Max().

SELECT Max(salaire) FROM Employe WHERE Salaire IN ( SELECT salaire FROM Empl WHERE ville IN (SELECT ville FROM Empl GROUP BY ville Having Count(*) > 5));

La formulation de l’arbre avec une telle requête peut faciliter l’écriture de la clause SQL correspondante.

Imbrication des fonctions dʹagrégation en algèbre et en SQL Les fonctions d’agrégation peuvent être imbriquées au niveau 1 du bloc, i.e. la requête principale. Toutefois, dans certains systèmes (DB2) cela est encore interdit, tandis que dans les systèmes Oracle et Informix cette imbrication est possible dès le premier niveau de la clause SQL. Toutefois, dans une sous-requête de niveau 2, il peut y avoir une imbrication des fonctions, car à partir de ce niveau, les sous-requêtes sont matérialisées, i.e. qu'il y a calcul d’une relation intermédiaire avec son extension sur laquelle est appliquée la deuxième fonction d’agrégation. La matérialisation du résultat de la première fonction d'agrégation fournit ainsi l'opérande à la deuxième fonction d'agrégation. Exemple : Soit une base de données formée des relations Patient et DossierAdmission :

Patient (maph*, nas, nom, ville) DossierAdmission (noAdm*, dateIn, dateOut, maph)

N.B. La clé primaire de Patient est l'attribut maph défini comme le matricule du patient hospitalisé. Le nas est une clé candidate de la même relation.

SELECT maph FROM DossierAdmission WHERE ville = 'Québec' GROUP BY maph HAVING Count(*) = (SELECT Max(Count(maph)) <-bloc niv. 2 FROM DossierAdmission GROUP BY maph);

Dans le calcul de cette clause, il y a en premier le calcul de la sous-requête (bloc 2) qui donne lieu à une matérialisation du résultat intermédiaire, c’est-à-dire la création physique d'une table temporaire dotée d’une seule colonne libellée Count(maph). L'opération se fait en deux étapes : le comptage pour obtenir une table de schéma R1(Count(maph)). Son extension est formée avec le nombre d’hospitalisations pour chaque personne différente présente dans la relation DossierAdmission.



109

R1 : Count(maph)

2 6 <-- 1 3

Ensuite la fonction d'agrégation Max() est appliquée sur la table R1 pour obtenir la constante 6. Cette valeur représente le plus grand nombre d'hospitalisations pour une même personne inscrite dans la base de données. C’est grâce à la matérialisation de la première relation temporaire que le calcul de la fonction Max() donne une réponse unique à la sous-requête, soit dans cet exemple l'entier 6.

temp : Max(Count(maph)) 6

La constante numérique est substituée à la sous-requête et le calcul se poursuit avec le premier niveau de la clause.

SELECT maph FROM DossierAdmission WHERE ville = 'Québec' GROUP BY maph HAVING Count(*) = 6;

Quelques exemples de fonctions d'agrégation utilisant la table Employe.

Employe(nas*, nom, salaire, age, noDep, ville)

a) Trouver le nombre d’employés dans chaque département et leur salaire moyen : ∏noDep as dep, Count(nas), Avg(salaire) ((noDep)G Count(nas), Avg(salaire) ( Employe)) Arbre de requête correspondant à cette expression algébrique : La projection sert à définir l'alias dep pour l’attribut noDep. Cet alias n'est connu que pour la dernière opération, soit la projection. En SQL :

SELECT noDep as dep, Count(nas), Avg(salaire) FROM Employe GROUP BY noDep;

∏ noDep as dep, Count(nas), Avg(salaire) (noDep) G Count(nas), Avg (salaire) Employe



110

Le schéma de la réponse est le suivant :

dep Count(nas) Avg(salaire) 1er groupement --> c2 18 20K$ 2e groupement --> u1 25 22K$

Figure 5.24 Il est impossible de faire afficher les autres attributs qui n'apparaissent pas parmi les arguments de G, car leur interprétation serait ambiguë. Pour exemple, que signifierait le nom avec Avg(salaire) ? Le nom d'un employé n'est pas celui d'un groupement qui a un salaire moyen! Les seuls attributs pertinents sont ceux de la fonction de groupement et le résultat des fonctions d'agrégation. Par contre, la clause suivante est incorrecte puisque au moment de l'exécution du groupement l'alias dep est inconnu. Il ne peut donc pas être utilisé par l'opérateur G. En effet cet alias est défini dans la projection qui est la dernière opération effectuée, i.e. après le groupement. Ce dernier ne peut donc pas y référer dans le GROUP BY.

SELECT noDep as dep, Count(nas), Avg(salaire) FROM Employe GROUP BY dep;<--inconnu au moment de l’exécution du Group By

b) Regrouper les employés par groupe d'âge en plus du groupement sur la base des deux premiers caractères du noDep. Ensuite, afficher le numéro de département, l'âge et le salaire moyen. Il peut y avoir des fonctions de tuple dans l'expression du GROUP BY (ex. Substr()) Le résultat escompté est le suivant :

(Subtr(noDep,1,2), age)G(Avg(salaire) (Employe) En SQL:

SELECT Substr(noDep,1,2), age, Avg(salaire) FROM Employe GROUP BY Substr(noDep,1,2),age;

Substr(noDep,1,2) age Avg(salaire)

u1 20 18K$ 21 20K$ c2 19 18K$ 20 20K$ 21 23K$

Figure 5.25 Remarque : Chaque ligne est un groupe et l'affichage des tuples est contrôlé par un format de sortie spécifié par les paramètres de l'environnement (voir affichage par SQLPLUS). Voici un autre exemple illustrant un regroupement mal formulé : G(Count(nas)(∏nom(σville ='Québec' OR ville = ‘Montréal’(Employe)))

Dans le calcul de cette expression algébrique, la fonction G est appliquée à des tuples dont le schéma est composé d’un seul attribut, soit le nom. La fonction G ne peut donc pas être calculée puisqu’elle réfère au nas qui n'est pas inclus dans le schéma de la relation intermédiaire. En



111

ajoutant l'attribut nas à la projection, la requête devient acceptable pour le calcul de la réponse. Cependant, si le nas est remplacé par *, alors la première expression redevient valide, car il s’agit de compter le nombre de tuples dans la relation intermédiaire. G(Count(*)) (∏ nas, nom(�ville = 'Quebec' or ville = ‘Montréal’ (Employe))) En SQL : -- comptage des tuples par une agrégation sur l’extension de la table

SELECT Count(*) FROM Employe WHERE ville = 'Québec' OR ville = ‘Montréal’ ;

résultat : Count(nas) 28

Schéma logique de la réponse formée par un groupement Lorsque des fonctions d'agrégation et des attributs de groupement sont utilisés dans une expression algébrique, les attributs et le résultat des fonctions qui peuvent être affichés dans la réponse par projection sont ceux qui apparaissent dans les deux listes de G : la liste de groupement et la liste des fonctions d'agrégation. Il est cependant possible d'afficher les autres attributs qui n'apparaissent pas dans les listes de groupement en utilisant une sous-requête avec un prédicat d’inclusion approprié. Voici un exemple pour afficher une liste d'attributs plus riche que celle du groupement. Cela n'est possible que par l'usage de sous-requêtes (niveau 2) calculées dans une première opération. Exemple : Soit la BD définie précédemment :

Patient (maph*, nas, nom, ville) DossierAdmission (noAdm*, dateIn, dateOut, maph)

Affichez les nas, nom et ville des patients de Québec ou de Montréal qui ont été hospitalisés plus de 2 fois. La formation des groupes sur la base du maph et le filtrage permet d’obtenir le matricule (maph) des personnes concernées.

SELECT nas, nom, ville FROM Patient WHERE maph IN (SELECT maph FROM Dossier_Admission WHERE ville = 'Québec' or ville = 'Montréal;' GROUP BY maph Having Count(*) > 2); <--

La sous-requête fournit le maph des personnes de Québec hospitalisées plus de 2 fois. La requête englobante permet alors de contourner la contrainte imposée par le GROUP BY en faisant une sélection avec le prédicat d'inclusion IN. La projection sur les attributs nas, nom et ville de la relation Patient devient possible.

5.7 Fonctions d’agrégation



112

Ces fonctions ont comme argument un ensemble de tuples à partir desquels un scalaire d'agrégation est calculé. Voici quelques fonctions d’agrégation dont la portée est limitée par le groupement G.

AVG(attribut) MIN(attribut) COUNT(attribut) COUNT(*) SUM(attribut) MAX(attribut)

Quelques exemples avec ces fonctions d’agrégation utilisées dans une expression algébrique : Trouver le nombre d’employés dans chaque département. ∏noDep, Count(nas) ((noDep)G(Count(nas))(Employe)) En SQL : La liste de groupement est utilisée par le Group By, et la liste de fonctions est placée dans le SELECT.

SELECT noDep, Count(nas) FROM Employe GROUP BY noDep ;

noDep Count(nas) 1er groupement --> u1 25 2e groupement --> d2 18

Figure 5.26 Il est impossible de faire afficher les autres attributs non présents parmi les arguments de G, comme par exemple, le nom, car leur interprétation serait ambiguë. Les seuls attributs pertinents sont ceux de la fonction de groupement et le résultat de ces fonctions. Très souvent l'expression algébrique est plus lisible lorsqu'elle est écrite sous forme d'une arborescence. La feuille de l'arbre est une relation de base et les noeuds internes sont des opérateurs ou une fonction G().

∏ noDep, Count(nas) (noDep) G Count(nas), Avg(salaire) Employe

� noDep, Count(nas), Avg(salaire) Salaire_Moyen

(noDep) G Count(nas), Avg(salaire) Employe



113

Trouver le nombre d'employés actifs de plus de 45 ans et afficher leur âge moyen. Pour ce calcul, utiliser une vue relationnelle nommée EmployeActif. G(Count(nas),Avg(age))(σ age >= 45(EmployeActif)) La vue correspond à une table calculée à partir de la relation de base Employe. Cette vue correspondant à une table virtuelle contenant tous les employés de moins de 65 ans. Lʹexpression relationnelle pour la vue est la suivante : Vue relationnelle : ∏nas, age(σage < 65(Employe))

EmployeActif : nas age 279 29 145

324 48 35

Figure 5.27

L'arbre de requête est présenté ci-dessous. La liste d’attributs du groupement est vide ce qui signifie que tous les tuples de la table opérande de G constituent le seul groupement sur lequel seront appliquées les fonctions de comptage et de calcul de la moyenne.

Pour renommer les colonnes de sortie, il faudrait traiter la table résultats avec l’opérateur de renommage rhô.

5.8 Ajout de tuples dans une relation La mise à jour d’une relation consiste à ajouter au moins un tuple dans l’extension. Cette opération peut être vue comme l’union de l’extension courante d’une table de base avec une relation temporaire constituée avec le ou les tuples à ajouter. Cette mise à jour peut sous-tendre un ajout de tuples (Insert), une modification des valeurs de tuples (Update) ou une suppression de tuples (Delete). Exemple : Mise à jour de la relation Employe par l’ajout du tuple ci-dessous.

Employe (nas, nom, salaire, age, noDep, ville) Soit temp1 = {2345, ‘Martine’, 24 K$, 25, ‘d4’, ‘Sherbrooke’}, une relation temporaire contenant le tuple à ajouter. La mise à jour est donc simplement l’union des extensions : celle avant et celle formée avec le ou les tuples ajoutés.

G Count(nas), Avg(age)

σ age >= 45 ∏ nas, age EmployeActif



114

(employe ∪ temp1) En SQL, l'ajout sera fait par l'ordre Insert :

Insert into Employe values (2345,'Martine', 24 000, 25, 'd4', 'Sherbrooke') ;

L’ajout peut se faire en vrac avec des tuples d’une autre relation. Les tuples à insérer sont sélectionnés par une sous-requête.

Insert into Employe (SELECT * FROM Disponible WHERE metier = ‘carossier') ;

Cette mise à jour suppose la compatibilité des schémas Employe et Disponible. Il est aussi conseillé de fournir le schéma des attributs dans l’ordre correspondant aux valeurs du tuple à ajouter. En ce faisant, l’ordre des valeurs peut être différent de celui imposé par les attributs du schéma.

INSERT INTO Employe (nas, nom, salaire, noDep, ville) values (2345, ‘Martine’, 24 000, ‘d4’, ‘Sherbrooke’) ;

L'attribut âge est absent de liste des attributs accompagnant le INSERT. Cet attribut aura donc un indicateur de NULL pour marquer l’absence de valeur. Il pourrait obtenir aussi une valeur par défaut spécifiée dans le schéma de cette même table. Insertion de lots de tuples Une autre forme de l’insertion est celle utilisant une sous-requête pour charger des tuples en lot :

INSERT INTO Employe (nas, nom, salaire ) SELECT nas, nom, salaire FROM Syndiques WHERE societe = ‘Electrochima’;

Les tuples ajoutés sont réservés exclusivement au compte qui effectue l’opération. Ils deviendront visibles qu’à la validation avec un COMMIT.

5.9 Suppression de tuples dans une relation La suppression sous-entend une recherche préalable pour identifier le ou les tuples à supprimer. Le résultat donne un ensemble de tuples dont le schéma est identique à celui d’une relation de base. Cet ensemble temporaire est soustrait de l’extension d’une relation de base. La recherche est effectuée avec le critère formulé dans le WHERE. Exemple : Supprimer les employés de la ville de Montréal membres du FTOQ. Pour y arriver, il faut en premier rechercher ces employés et ensuite les supprimer de la base : a) Recherche des employés : temp1 = (∏ ville = ‘Montréal’ AND syndicat = 'FTOQ' (Employe))

b) Suppression par la différence entre la relation de base Employe et la relation intermédiaire :

employe = employe - temp1 Ou encore par l’expression suivante qui effectue une différence entre l’extension de Employe et la table réponse de la sélection. Employe-(σville = 'Montréal' AND syndicat = 'FTOQ'(employe))



115

Si la relation intermédiaire qui résulte de la sélection contient plusieurs tuples, ceux-ci seront tous supprimés de l’extension de la relation Employe. En pratique, les opérations de mise à jour DELETE et UPDATE de SQL sont implémentées par des procédures internes qui intègrent la phase recherche et celle de la mise à jour : –suppression de plusieurs tuples DELETE FROM Employe WHERE ville = 'Montréal' AND syndicat = 'FTOQ';

Il est aussi possible de faire des suppressions en vrac au moyen d’une sous-requête :

DELETE FROM Employe WHERE nas IN (SELECT nas FROM Etudiant WHERE age <20);

5.10 Modification de la valeur des attributs d’une relation Une modification comprend une recherche préalable d’un ou de plusieurs tuples, leur suppression et leur remplacement par l’ajout de tuples avec des valeurs modifiées. Il y aura donc une sélection des tuples à modifier, leur suppression et un ajout de nouveaux tuples incluant les nouvelles valeurs. Ces trois opérations se feront sans interruption ou interférence avec les autres opérations sur la base. En SQL, la modification est faite par l’ordre DML Update. Pour fixer le nouveau salaire de l’employé dont le nas est 2350 à 35 0000 et augmenter sont âge d’une année, il suffit de formuler l’ordre DML suivant :

UPDATE Employe SET salaire = 35000,age = age+1, departement = 'peinture' WHERE nas = 2350;

Un seul tuple sera mis à jour puisque le nas est une clé primaire de la relation Employe. Par contre, si plusieurs tuples vérifient le prédicat, il y aura autant de tuples modifiés. Par exemple, pour augmenter de 10% le salaire de tous les employés, il suffit de formuler le DML suivant qui modifiera les 225 employés inscrits dans la base.

Update Employe SET salaire = salaire * 1.10 ; Il peut y avoir une liste de valeurs de la mise à jour. La réalisation de cette opération de mise à jour comportera 250 modifications par un seul ordre DML. Le SGBD devra les exécuter tous, sinon pas un seul sera fait. Il existe une panoplie de logiciels qui revendiquent le "label" relationnel. Ils ne le sont pas tous au même degré. Un SGBD peut être du type relationnel et n'offrir qu'une partie des fonctionnalités du système relationnel. Selon les règles proposées par Codd, on peut examiner un logiciel SGBD d'après plusieurs critères et identifier ceux qui sont pleinement relationnels.

Systèmes relationnels à des degrés divers



116

Représentation unique de l’information pour les métadonnées et les données Cette représentation n'est faite qu'avec des tables, et cela, pour les données et les métadonnées que sont les schémas, les déclencheurs, les statistiques d’accès, les autorisations, etc. Dans une BD relationnelle, les données sont représentées uniquement par les notions de tuple et de relation dont les attributs sont atomiques. La même représentation est utilisée pour les métadonnées (schémas). Toute cette information est accessible par le même langage de données utilisé pour exploiter la base.

Accès garanti à chaque donnée Chaque valeur (par l'entremise du tuple) stockée dans la BD est logiquement accessible en spécifiant le nom de la table à laquelle elle appartient, le nom de la colonne et la valeur de la clé primaire du tuple qui la contient. Par exemple, un attribut de type BLOB a comme valeur interne un pointeur à l’image correspondante. Toutefois, si l'on spécifie le nom de la table, une recherche avec une valeur de clé suivie d’une projection sur l’attribut du type BLOB ne doit pas fournir le pointeur sur l'image, mais plutôt l’image correspondante.

Traitement systématique des valeurs nulles Un attribut non primaire pour lequel on ne possède aucun renseignement (valeur inapplicable ou inconnue) doit faire l’objet d’un traitement systématique par les opérateurs et les fonctions internes et externes selon une logique à trois valeurs : {T, F, null}. À titre d’exemple, on considère que l’évaluation d’une fonction d'agrégation doit se faire sans tenir compte des NULLS, sauf pour la fonction Count (*). Le calcul de la moyenne n'en tient donc pas compte.

Dictionnaire de données de la base de données relationnelle C’est un dictionnaire accessible aux usagers autorisés avec le même langage de requête que celui utilisé pour les données. Seuls les droits d’accès limitent les usagers dans l’exploitation des données du dictionnaire.

Langage de données complet Le SGBD doit offrir un langage de manipulation de données qui peut être utilisé en mode interactif ou dans un programme de troisième génération. Le SGBD doit aussi avoir un langage capable de définir le schéma, la mise à jour des relations, la notion de transaction, les contraintes d’intégrité et les processus de validation et de recouvrement. Le langage doit avoir la puissance de l’algèbre relationnelle et vérifier la propriété de fermeture, c’est-à-dire que toute expression définit une table, qui peut être utilisée comme argument d’une autre expression ou clause du langage de données.

Mise à jour par lʹentremise des vues Les vues sont utilisées pour la mise à jour par le SGBD sous réserve des restrictions imposées par la théorie. Les vues sont qualifiées de modifiables si elles autorisent la mise à jour, sinon elles sont uniquement du type recherche. Les vues sont modifiables (updatable) si la mise à jour peut être faite par le SGBD au moyen d'une procédure interne unique tout en respectant entièrement toutes les contraintes d'intégrité de la BD .

Opération pipeline d’insertion, de suppression et de modification des tuples Les ordres DML INSERT, UPDATE et DELETE sont du type ensembliste. Le traitement sous-jacent à un ordre DML peut donc impliquer plusieurs tuples, i.e. tous ceux qui vérifient le prédicat.

Indépendance physique Le placement et les structures de données peuvent être modifiés sans perturber les applications. Une ou plusieurs tables peuvent être déplacées vers un nouveau disque plus rapide, sans nuire au fonctionnement des applications ou exiger des modifications de programmation.



117

Indépendance logique Le DBA peut modifier le schéma conceptuel sans invalider les vues des applications. Par exemple, une relation de base exploitée par une application peut être divisée en deux relations nouvelles sans perturber le traitement d'une application. Cela est rendu possible en modifiant la vue initiale pour la remplacer par une jointure de deux nouvelles relations créées.

Indépendance des contraintes Les contraintes ne sont plus placées dans les applications mais plutôt stockées dans le dictionnaire de la BD. En ce faisant, les nouvelles applications sont forcées de respecter les contraintes de la base.

Indépendance de distribution (transparence de site) Les applications en exploitation ne sont pas touchées par une migration de la base de données centralisée vers une BD répartie ou par un nouvel aménagement de la répartition des données. Seul le dictionnaire est modifié par le DBA pour refléter ce changement. Selon qu’un SGBD vérifie pleinement ou en partie les règles ci-dessus, il sera qualifié de pleinement relationnel ou de relationnel. Mise à jour à travers une vue relationnelle

5.11 Vue relationnelle Par définition, une vue relationnelle est une sorte de table virtuelle dont la matérialisation en cours de traitement n'est pas persistante. Elle disparaît normalement après la fin du calcul. Cette table virtuelle est définie par une expression de requête formulée en algèbre relationnelle ou par un autre langage équivalent (exemple : GDML de Powerhouse ou en SQL ). Elle correspond aux données qu’un utilisateur peut voir et, sous certaines restrictions, mettre à jour conformément aux droits d’accès accordés par le DBA. Cette notion de vue facilite la gestion de la de sécurité des données mise en place dans une organisation. Ce mécanisme est nécessaire, mais toutefois insuffisant pour une gestion complète de la sécurité d'une base de données organisationnelle. Sur un autre plan, la vue implémente indirectement la notion de variable de type table, ce qui permet de simplifier la formulation de plusieurs questions ou expressions algébriques. En effet, la vue peut être utilisée partout où une table de base peut apparaître dans une requête ou dans une expression algébrique.

Substitution et matérialisation dʹune vue Les vues sont traitées par substitution ou par matérialisation selon le SGBD. La substitution consiste à remplacer dans une expression le nom de la vue par son expression algébrique, tandis que la matérialisation consiste à calculer la vue lors de l'exécution et de la traiter par la suite comme une table temporaire de la BD. Lorsque la substitution ne fournit pas une expression valide au sens de la grammaire du langage de requête utilisé, le SGBD peut alors tenter une matérialisation pour calculer la réponse.

Limites imposées à la mise à jour à travers une vue La mise à jour de la base de données à travers une vue est un problème indécidable(7), c'est-à-dire qu'il n'existe pas d'algorithme général qui permet à un système de déterminer seul si une opération de mise à jour par l'entremise d'une vue relationnelle peut être effectuée correctement ou pas. Cette difficulté peut être résolue par l'apport d'une connaissance externe de nature sémantique ou, au cas par cas, au regard des intentions de l'application effectuant la mise à jour. Cependant, cette approche n'est pas toujours possible, car l'utilisateur n'est pas toujours présent pour fournir l'information nécessaire pour résoudre les ambiguïtés ou valider la mise à jour. Le SGBD est donc contraint de traiter seulement un nombre réduit de cas de mise à jour, et cela, en tenant compte de la nature de l'opérateur, du prédicat et du schéma de la vue. La mise à jour de



118

l'extension d'une vue génère donc des effets secondaires indésirables qui obligent les concepteurs de SGBD à limiter les vues admissibles pour la mise à jour. Dans les exemples ci-dessous, nous allons illustrer les comportements "pathologiques" de ces opérations sur la base de données pour justifier les restrictions imposées par un grand nombre de SGBD.

Atelier (no*, chefNas, site) Contrat(no*, noProjet*, noTache*, duree) Job(noProjet*, noTache*, description, nas) Employe (nas*, nom, salaire)

Figure 5.28 La vue relationnelle associée à une application est le sous-ensemble des données de la base pour lequel l'application a des droits d'accès appropriés (Insert, Update, Delete, Select) lui permettant d'exécuter les traitements. Nous allons examiner, au moyen d'un exemple, les limites imposées aux traitements sur la BD par l'usage de la vue relationnelle. Voici une base concernant la gestion de la production de produits par des ateliers spécialisés effectuant des tâches particulières dans le cadre de la réalisation de projets. Des ouvriers effectuent une tâche pour un projet réalisé par un atelier. La transposition du MCD fournit les relations : Atelier, Job, Contrat et Employe. La relation Atelier donne le numéro de l'atelier, le nas du chef qui est aussi un ouvrier, et le site de l'atelier. Tous les ouvriers ont au moins participé à une réalisation (identifiée comme la notion de job), et de ce fait sont inscrits dans la table Job. Finalement, le chef travaille sur des projets comme les autres employés. Voici l'état de quelques-unes des tables.

Atelier : no* chefNas site a20 10 Québec

Figure 5.29 La table Job représente les tâches effectuées par les employés dans différents projets.

Job noProjet* noTache * description

Atelier no* chefNas site

Employe nas* nom salaire

1..m

1

1..n

1..n

Travaille

Contracte duree



119

Job : noProjet* noTache* description nas p2100 t10 laquage 10 p2100 t20 fraisage 20 p2112 t70 laquage 190 p2400 t20 polissage 40 p3000 t100 soudure 20 p4500 t70 rivetage 20 p4000 t10 peinture 130 p5000 t60 forage 40

Figure 5.30 La table Contrat permet de représenter la durée des jobs qui sont sous la responsabilité d'un chef d’atelier.

Contrat : no* noProjet* noTache* duree a20 p2100 t10 5 a20 p2100 t20 3 a20 p2112 t70 2 a20 p3000 t100 2 a20 p4500 t70 4 a20 p2400 t20 5 a20 p4000 t10 3 a20 p5000 t60 1

Figure 5.31 Les trois tables sont en FN3 avec les DF de clé habituelles, plus la DF suivante :

noProjet, noTache --> nas.

Expression algébrique pour une vue relationnelle La vue relationnelle définie pour une ou plusieurs applications est formulée par une expression algébrique simple (une projection et une sélection sur une seule relation) ou complexe intégrant une projection et une jointure avec au moins deux relations de base de la BD. Lorsqu'une colonne de la vue est transformée par une fonction, elle doit être renommée par un alias. Voici une vue simple V1 définie avec une seule relation, Atelier. V1 : ∏ no, chefNas ( Atelier)

V1 : no* chefNas a20 10

Figure 5.32 b- Vue complexe V2 (avec 2 relations) : ∏ no, projet, tache, site (Atelier |x|θ Job) avec θ : chefNas = nas Cette vue représente les jobs d’employés dans lesquels les chefs d'atelier contractent une tâche. Le calcul de l'extension de cette vue fait appel aux relations de base Atelier et Job. Le schéma de V2 est (no, noProjet, noTache, site), soit les attributs de la dernière projection. Les données visibles par cette vue sont celles de l'extension virtuelle suivante.



120

V2 : no* noProjet* noTache* site a20 p2100 t10 Québec

Figure 5.33 Dans cette jointure légale, nous avons utilisé deux tables non contiguës, sans faire appel à la table Contrat qui intervient pour en faire l’association. Cette jointure reste cependant légale puisqu’elle exploite une clé primaire et une clé étrangère partageant le même domaine. c- Vue complexe V3 avec une transformation d'une colonne par une fonction de comptage : V3 : ∏ count(*) as nb_projet, site( site G count(*) (Atelier |x|θ Job)) L’arbre de requête est le suivant :

V3 : nb_projet site 1 Québec

Cette vue relationnelle comporte un alias créé par la projection.

Modification de la base de données Une application peut modifier les données de la base à travers les vues pour lesquelles elle a un droit de mise à jour (UPDATE), d’ajout (INSERT) et de suppression (DELETE). Les seules données de la base accessibles à l'application sont celles visibles par la vue relationnelle. Toutefois, une opération de mise à jour lancée à travers une vue a un impact très concret sur les relations de base sous-jacentes à la vue. Elle doit les modifier. Le seul critère pour juger du succès ou de l'échec de l'opération de mise à jour par l'application est la relecture par la vue pour observer si les données sont effectivement modifiées. Le traitement effectué par le moteur SGBD doit être réalisé en utilisant seulement des ordres DML de même nature que ceux utilisés par l'application avec au besoin, des sélections référant aux seules constantes fournies par l'application. Pour réaliser la mise à jour demandée, le SGBD tentera d'exploiter les relations présentes dans la vue afin de réaliser cette première à travers une vue.

Modification dʹune vue définie sur une relation La première opération est une mise à jour à travers la vue V1. Le chef de l'atelier a20 est remplacé par le chef dont le nas est 99. Pour réaliser ce changement, l'application doit modifier l'état initial de la vue en transformant le tuple (a20, 10 ) pour qu’il soit à la fin (a20, 99). Le SGBD saura le faire puisqu'il existe une seule procédure pour identifier le tuple au moyen de sa clé (a20). DML de l'application : UPDATE V1 set chef_nas = 99 WHERE no = 'a20'; -- (basée sur Atelier)

V1 : no* chefNas a20 99

Figure 5.34

site G count(*) as nb_projet

|x|θ

Atelier Job



121

Au niveau du SGBD, la table de base Atelier sera mise à jour par la commande suivante : UPDATE Atelier set chef_nas = 99 WHERE no = 'a20';

L'effet de la mise à jour sur la table de base Atelier :

Atelier* : no* chefNas site a20 99 Québec

Figure 5.35 En général, une vue composée seulement de sélections et de projections sur une seule relation est modifiable pour autant que la valeur de la clé soit fournie et que l'opération ne viole pas une contrainte d'attribut définie dans le schéma. Par contre, si la vue mono relation comporte un groupement ou des calculs de fonctions, elle est non modifiable, puisque ce groupement ou cette agrégation est absent dans les relations de base. Exemple : Supposons une nouvelle vue V1* définie par l'expression : ∏ Count(no) [as] nbTotal GCount(no) (Atelier)) La mise à jour de cette nouvelle vue est faite par l'ordre DML :

UPDATE V1* set nbTotal = nbTotal + 1 ; Cette mise à jour est impossible, car elle ne peut pas se faire dans la relation Atelier puisque l'attribut d'agrégation nbTotal est absent du schéma de cette table de base.

5.12 Modification dʹune vue définie sur deux relations Les modifications à travers une vue comportant au moins une jointure revêtent un caractère plus complexe. Leur réalisation peut, dans certains cas, dépendre de la connaissance des deux clés. Pour d'autres requêtes, même avec les clés, la réalisation de la mise à jour n'est pas possible sans risquer de créer une incohérence dans les relations de la base. La vue V2 comporte une jointure de deux relations (Atelier et Job), mais le schéma de V2 n'inclut qu'une seule des deux clés des relations de base. Par exemple, suite à un changement dans les spécifications, le projet p2100 fait par l'atelier a20 et comportant la tâche t10 dans V2 est renommé p2112 et il est maintenant réalisé par la tâche t70, toujours par l’atelier a20. A la suite de ce changement, la vue devrait voir son extension modifiée.

UPDATE V2 set projet = 'p2112', tache= 't70' WHERE no = 'a20' and no_projet = 'p2100’ and tache ='t10';

V2+ : no* noProjet* noTache* site Avant : a20 p2100 t10 Québec Après : a20 p2112 t7 0 Québec

Figure 5.36 N.B. V2+ représente l'extension de la relation escomptée après avoir le chapitre la modification. La partie tramée indique les attributs de la vue qui sont mis à jour. Cette mise à jour sera donc effectuée au niveau des relations de base par le SGBD qui n'a pas d'autres connaissances de la sémantique des relations. Le seul critère pour valider la procédure est que le résultat de la vue modifiée reflète bien le traitement demandé et que ce premier soit visible à travers la vue. La procédure interne de la modification ci-dessus n'est pas unique ce qui rend la vue V2 non modifiable. Il peut y avoir au moins deux procédures, P1 et P2 pour implémenter cette opération, et dans les deux cas l’état final de la BD n’est pas le même.



122

P1- Une première procédure est la suivante: Changer le chef de l'atelier a20 dans la table Atelier pour le remplacer par l'employé qui dans la table Job effectue la tâche t70 pour le projet p2112 (soit le nas 190). Au niveau de la BD, la clause SQL-DML exécutée par le SGBD peut être la suivante :

UPDATE Atelier set chef_nas = (SELECT nas FROM Job WHERE no_projet = 'p2112' and no_tache = 't70') WHERE no = 'a20';

La sous-requête donne un résultat correct grâce à la présence de la DF dans la table Job : noProjet, noTache --> nas.

Atelier +: no* chef site a20 190 Québec

Figure 5.37 En calculant la jointure avec Atelier+ et Job, on obtient l'extension attendue pour V2+ .

(vue attendue) V2* : no* noProjet* noTache* site Avant : a20 p2100 t1 0 Québec Après : tuple modifié -> a20 p2112 t7 0 Québec

Figure 5.38 En modifiant une seule table de base, nous arrivons à calculer correctement l'extension correspondant à celle de la vue V2+. Or, comment le SGBD peut-il décider d'utiliser deux relations plutôt qu’une seule? Comment aussi interdire cette modification au niveau de la base parce qu'elle sous-tend une mutation du chef d'atelier ? Le moteur SGBD n'a pas la connaissance nécessaire pour prendre une telle décision. P2- Une deuxième procédure, P2 conduit au même résultat attendu par l'application. Elle consiste à mettre à jour la relation Job en modifiant le tuple de l'ouvrier 10 qui est le chef de l'atelier 'a20' et qui est aussi chargé du projet p2100. Dans la table Job : (p2100, t10, laquage, 10) – après modif -> ( p2112, t70, laquage, 10)

UPDATE Job SET no_projet = 'p2112', noTache = 't70' WHERE noProjet = 'p2100' and noTache ='t10');

Job*: noProjet* noTache* descriptionJob nas Après MAJ p2112 t70 laquage 10 p2100 t20 fraisage 20 p2112 t70 laquage 190 p2400 t20 polissage 40 p3000 t100 soudure 20 p4500 t70 rivetage 20 p4000 t10 peinture 130 p5000 t60 forage 40

Figure 5.39 Une seule table est utilisée dans cette deuxième procédure.



123

Calcul de l'extension de la vue V2* ∏ no, projet, tâche, site (Atelier |x|θ Job*) donne l’extension escomptée suivante :

V2: no* noProjet* noTache* site a20 p2112 t7 0 Québec

Figure 5.40 Les données visibles par la vue V2 sont les mêmes que celles visibles avec la procédure P1 . Conclusion sur la mise à jour En dépit des mêmes données visibles par la vue, , l'état de la BD (les tables utilisées) varie selon la procédure utilisée par le SGBD. Avec P1, l'extension de Atelier est modifiée, tandis qu'avec P2, c'est celle de Job qui a été mise à jour. En conclusion, une vue comportant deux tables n'est pas toujours modifiable sans risque de perte de cohérence dans les données.

Fonction et groupement dans une vue Toute vue comportant le calcul d'un groupement ou d'une fonction n'est pas modifiable. Par exemple, la vue V4 est utilisée pour compter le nombre d'ouvriers qui travaillent aux projets. V4 : ∏ count(nas) nbTotal, noProjet (noProjet Gcount (nas) (∏ nas, noProjet (Job))

V4 : nbTotal noProjet* 2 p2100 1 p2112 1 p2400 1 p3000 1 p4500 1 p4000 1 p5000

Figure 5.41 Si un ouvrier est ajouté au projet p2100 pour en porter le nombre à 3, il faut faire une mise à jour à travers la vue V4. Cette modification est impossible, car le système n'a pas suffisamment d'informations pour répercuter cette modification au niveau de la table Job par l'insertion d'un nouveau tuple dans la relation. En effet, l'application ne connaissant pas le numéro de la tâche qui est un attribut primaire de Job, l'ajout sera interdit sur la base de la contrainte de clé. En effet, il est impossible d'ajouter un tuple dont la clé primaire ou une de ses parties est nulle. UPDATE V4 set nbTotal = nbTotal + 1 WHERE noProjet = ‘p2100’; Ces quelques cas de figure illustrant la mise à jour des tuples à travers une vue relationnelle soulignent l'incapacité pour le SGBD d'effectuer, dans certains cas, le traitement demandé par une application sans risquer de mettre en péril la cohérence de la base de données. Dans d'autres cas, la mise à jour est impossible en raison d'une contrainte sur un attribut de la relation de base. Par exemple, la vue V1(no, chefNas) définie par la projection permet la mise à jour de l'attribut chefNas à null (clé candidate), seulement si la contrainte spécifiée dans le schéma de la BD pour cet attribut autorise les valeurs nulles. En général, si le schéma d'une vue est composé des attributs de plusieurs relations, il sous-tend au moins une jointure. Cette vue pourrait être modifiable, si au moins, la valeur de chaque clé primaire des tables de base référées dans la vue est connue lors de la modification et si la vue n'incorpore pas le calcul d'un groupement ou d'une



124

fonction non réversible. Toutefois, si la relation n'est pas normalisée, il arrive que même dans ces conditions, la mise à jour conduise à des incohérences.

5.13 Insertion de tuples dans la base de données à travers une vue Un autre traitement sur la BD consiste en l'ajout de tuples à travers une vue, ajout qui doit être exécuté par le SGBD sans violation d'une contrainte d'attribut et par une procédure unique d'insertion. L'ajout d'un nouvel atelier à travers la vue V1 n’est possible que si le no de l'atelier et les autres attributs NOT NULL dans le schéma sont fournis par l'application. Par exemple, il est possible d'ajouter le tuple ('a30', 77) dans la relation Atelier parce que le schéma spécifie que l'attribut site de la table de base accepte le NULL. De plus, si la vue comporte aussi une sélection pour ne garder que les ateliers du site 'Québec', l'ajout d'un atelier pour Montréal pourra être acceptable si le SGBD ne teste pas le prédicat de sélection défini dans la vue pour savoir s'il est vérifié ou pas par cet ajout.

INSERT INTO V1 (no, chef_nas) values ('a30', 77)); Au niveau du SGBD, il y aura exécution de l'ordre suivant :

INSERT into Atelier values ('a30', 77, null) ; L'ajout est réussi en raison du fait que le nouveau tuple ne contredit pas une contrainte de la table Atelier. Dans le cas contraire, le SGBD annule l’insertion et défait les données déjà inscrites dans la zone de mémoire partagaée (ZMP).

Ajout dans une vue formulée avec une jointure Prenons le cas de l'ajout du tuple ('a11', 'p4000' , 't80', 'Québec') dans la vue V2 pour enregistrer le fait que le nouvel atelier 'a11' de Québec travaille au projet 'p4000' pour y effectuer la tâche dénommée 't80'. INSERT INTO V2(no, noProjet, noTache, site) values ('a11', p4000, 't80', 'Québec') ; La vue escomptée après la mise à jour est V2* :

V2* : no noProjet noTache site a20 p2112 t7 0 Québec Après : a11 p4000 t80 Québec

Figure 5.42 Puisque l'atelier 'a11' est un nouvel atelier dans cette base, il suffit d'ajouter dans la table Atelier le tuple (a11, null, ‘Québec’), même si on ignore le chef de ce nouvel atelier de Québec. INSERT INTO Atelier values ('a11', null, 'Québec');

Atelier* : no* chefNas site a20 10 Québec + a11 null Québec

Figure 5.43 Ensuite, un nouveau tuple est ajouté dans la table Job avec les valeurs fournies par le DML : INSERT Into Job : ('p4000', 't80', null, null);

Job*: noProjet* noTache* description nas p2100 t10 laquage 10 p2100 t20 fraisage 20 p2112 t70 laquage 190



125

p2400 t20 polissage 40 p3000 t100 soudure 20 p4500 t70 rivetage 20 + p4000 t80 null null p4000 t10 peinture 130 p5000 t60 forage 40

Figure 5.44 Cette insertion est acceptable dans Job. Elle pourrait être refusée si la clé étrangère est spécifiée NOT NULL. Dans ce cas, l'ajout effectué dans la table Atelier est annulé et l’état préalable de la base de données est restauré. 5.14 Suppression de tuples La suppression à travers la vue V2 du tuple (‘a11’, ‘p4000’, ‘t80’) est tout à fait possible, mais il peut y avoir des effets de bord indésirables. La procédure pour réaliser cette opération n’est pas unique risquant ainsi d’engendrer une incohérence au niveau de la base. Soit V2*, un nouvel état de la vue d’origine V2 dans lequel il y a maintenant plusieurs ateliers travaillant sur des jobs avec respectivement les chefs ‘a20’ et ‘a11’.

V2* : no* noProjet* noTache* site a20 p2100 t10 Québec a11 p4000 t80 Québec a11 p4000 t10 Québec

Figure 5.45 DELETE V2 WHERE no = ‘a11’ and noProjet = ‘p4000’ and noTache = ‘t80’; Pour y arriver, le SGBD peut supprimer le tuple identifié dans la table Atelier ainsi que celui dans la table Job. Pour le SGBD : DELETE Atelier WHERE no = ‘a11’ ;

Atelier * : no* chefNas site a20 10 Québec (-) a11 130 Québec

Figure 5.46 Cette suppression est répercutée dans la table Job avec le DML suivant :

DELETE Job WHERE projet = ‘p4000’ and no_tache = ‘t80’;

Job* : noProjet* noTache* description nas p2100 t10 laquage 10 p2100 t20 fraisage 20 p2112 t70 laquage 190 p2400 t20 polissage 40 p3000 t100 soudure 20 p4500 t70 rivetage 20

p4000 t80 null 130 p4000 t10 peinture 130 p5000 t60 forage 40

Figure 5.47



126

Finalement, un nouveau calcul de la vue V2 donne l'extension de la figure 5.48 dans laquelle un tuple est supprimé. L’opération est assortie de la suppression d'un autre tuple dans la vue (‘a11’, ‘p4000’, ‘t10’, ‘Québec’) comme effet de bord.

V2* après: no noProjet noTache site a20 p2100 t10 Québec

Figure 5.48

Mise à jour à travers une vue de jointure comportant les deux clés On peut aussi illustrer par un exemple que même si les clés des deux relations sont connues, la mise à jour n'est pas toujours possible sans effet secondaire. Voici un exemple avec les 2 clés dans la vue définie à partir du MCD suivant :

Figure 5.59

Le MRD partiel est le suivant :

Client : cid * cNom cVille cRemise c1 Turing LA 10 c2 Bader Mtl 5 c3 Anger Mtl 8 c4 Arthur Qc 3 c6 Arthur Lévis 5

Vendeur : vid* vNom vVille vBonus v1 Savard Mtl 5 v2 Joncas Qc 6 v3 Begin Toronto 7 v4 Gagnon NY 6 v5 Oscar Tunis 5 v6 Sirois Qc 4

Figure 5.59a

Client cid* cNom cRemise cVille

Vendeur vid* vNom vVille vBonus

Commande noCom* coTotal

Produit pid* pPrix

1..n

1..n

1..m 1..n

1 Prend

Comprend

Placer 1

1..n

1..m



127

Les données sont visibles à travers la vue relationnelle : CREATE VIEW VJ as SELECT C.cid, C.cnom, V.vid, V.vNom, V.vVille FROM Client C, Vendeur V

WHERE C.ville = V.ville; La vue VJ matérialisée correspond aux deux premiers tuples ci-dessous. Le troisième correspond au deuxième tuple après avoir été modifié par un ordre UPDATE :

VJ : cid* cNom vid* vNom vVille c2 Bader v1 Savard Mtl c3 Anger v1 Savard Mtl après modification : c3 Anger v1 Begin Mtl

Figure 5.59b Mise à jour d'un seul tuple :

UPDATE VJ set vnom = 'Begin' WHERE cid = 'c3' and vid = 'v1';

Le moteur du SGBD exécute le DML ci-dessous pour modifier, comme on le suppose, un seul tuple identifié avec la valeur de sa clé.

UPDATE Vendeur set v_nom = 'Begin' WHERE vid = 'v1'; La table de base Vendeur devient alors : Vendeur* : vid* vNom vVille vBonus

v1 Begin Mtl 5 v2 Joncas Qc 6 v3 Begin Toronto 7 v4 Gagnon NY 6 v5 Oscar Tunis 5 v6 Sirois Qc 4

Figure 5.59c SELECT * FROM VJ ; -- pour lister les tuples de la vue VJ

VJ : cid* cnom vid* vNom ville c2 Bader v1 Begin Mtl après la MAJ --> c3 Anger v1 Begin Mtl Figure 5.59d Deux tuples ont été modifiés, alors qu’un seul devrait l'être! Cet effet secondaire est indésirable. Outre l'indécidabilité de l'opération de mise à jour avec une vue sur deux tables, il y a aussi des raisons de performance sous-jacentes aux modifications de la BD à travers un vue relationnelle qui limitent ces opérations aux vues comportant une seule relation de base. Et cela en dépit du fait que plusieurs vues basées sur une jointure soient théoriquement modifiables avec certaines opérations. Pour déterminer si une vue est modifiable, le SGBD devrait confirmer l'unicité de la



128

procédure de modification, faire l'usage d'opérateurs de même nature, garantir l'absence d'effets de bord et respecter les contraintes définies au niveau du schéma de la base de données. Toutes ces vérifications lorsqu’elles sont possibles prennent du temps et des ressources affectant négativement la performance du logiciel SGBD. Par contre, avec un apport de connaissances externes, par exemple un trigger qui se déclenche lors de la mise à jour à travers une vue (Oracle: trigger INSTEAD OF), il devient alors possible de réaliser sans ambiguïté certaines mises à jour.

5.14 Suppression à travers une vue Par contre, si l'on désire supprimer le vendeur Savard et ses clients à travers la vue, cela est possible à la condition que cette vue comprenne la clé de chaque table de base : Vendeur et Client.

Perte de mise à jour suite à un ajout légal à travers une vue relationnelle Les données mises à jour à travers une vue doivent demeurer visibles pour celle-ci, sinon il y a ambiguïté du point de vue de l’application. La mise à jour des tables de base par un ajout à travers une vue peut être effectuée correctement, mais le nouveau tuple pourrait demeurer inaccessible à l'application. Par exemple, soit la vue SalairePlus définie avec les employés dont la rémunération est supérieure à 30K$ : Vue Salaire-Plus :

∏nas, nom, salaire (σ salaire > 30K$ (Employe)) En SQL, cette vue est formulée ainsi :

CREATE VIEW SalairePlus as SELECT nas, nom, salaire FROM Employe WHERE salaire > 30K$;

L’ajout du tuple <29, ‘Marie’, 25 K$> par l'entremise de la vue Salaire-Plus est possible si le SGBD ne dispose pas d'une information supplémentaire pour filtrer cet ajout. En effet, s’il travaille par substitution de la vue par son expression algébrique, aucune clause n’exclut l’ajout du tuple au niveau du schéma. Il en est de même si la vue est au préalable matérialisée.

INSERT INTO SalairePlus values (29, 'Marie', 25K$') ; La relation intermédiaire n’a pas de contrainte spécifique qui empêche l’ajout. La procédure de mise à jour de la table Employe utilisée par le SGBD sera la suivante :

INSERT into Employe values (29, 'Marie', 25K$) ; Toutefois, cet ajout est réalisé, mais elle est perdue pour cette application, car la seule extension obtenue est celle calculée par l’expression algébrique de sélection. Or, la avue ne retient que les employés dont le salaire est supérieur à 30K$.

∏nas,nom,salaire (σsalaire > 30K$(Employe))

Employe : nas* nom salaire 20 Benoit 31K$ 21 Christine 39K$ 22 Audrey 38K$

Figure 5.60



129

Le tuple ajouté n'est donc pas visible à travers la vue. Pour cette application, l'ajout n'a pas été effectué! Pour contourner cette difficulté, il faudrait pouvoir interdire toute mise à jour qui ne satisfait pas le prédicat de sélection. Dans certains systèmes (Oracle) ce mécanisme a été ajouté de manière à éviter ces pertes virtuelles des données.

5.15 Rappel du principe de base pour la mise à jour à travers une vue La vue étant une expression algébrique, de nombreuses vues ne pourront pas être utilisées pour la mise à jour et certaines seraient acceptables pour l’insertion, mais inadéquates pour les mises à jour. La définition des classes des vues modifiables reste partielle et tributaire du cas par cas. Seules quelques catégories de vues sont qualifiées pour la mise à jour et l'insertion directe. Les SGBD en sont réduits à formuler des règles d'acceptation assez strictes pour identifier facilement les vues modifiables sans avoir à investir une trop grande énergie. Une mise à jour demandée à travers une vue d’usager sera permise ou effectuée correctement par le système si, et seulement si, le noyau du SGBD seul, et cela sans apport de connaissances externes autres que celles dont il dispose dans le dictionnaire de données, n’a qu’une seule procédure interne pour mettre à jour les relations de base visées par l’opération. Comment vérifier que cette condition est respectée avec toutes les requêtes possibles ? Il est impossible de le faire pour tous les cas, car il faudrait définir des règles pour toutes les formules de requête possibles, c'est-à-dire pour toutes les questions éventuelles. On peut cependant repérer quelques classes restreintes de formules et définir ainsi certaines règles de mise à jour à travers une vue. En règle générale, la mise à jour n'est possible que si la vue est définie sur une seule table et que si elle ne contient ni fonction d'agrégation, ni fonction de transformation des attributs. Une vue V dans une BD est définie par la fonction X :

V = X (BD) ou X : BD → V (fonction) Il y a une transposition (mapping) des tuples visibles par la vue V avec ceux de la BD. Une mise à jour U par l'entremise d'une vue V est définie comme une opération pour modifier l’extension d’une relation de base : U(V), soit U: V --> BD* avec BD* ⊂ BD.

Substitution dans une vue Cette technique consiste à remplacer la vue par son expression équivalente (algébrique ou SQL) et à poursuivre par une optimisation avant d’effectuer le calcul de la réponse. L’expression qui est alors exécutée peut avoir une forme très différente tout en donnant un résultat identique à celui de la première formulation. L'énoncé formel de la mise à jour est présenté par C. Date : U(V) + U (X(BD)) L’optimisation consiste donc à trouver une procédure T équivalente à la composition des fonctions U et X de sorte que U(V) = T (BD), soit T = U * X. La réalisation de la mise à jour se résume donc à trouver une expression U’ formulée en termes de relations de base, les seules présentes dans la BD, de telle manière que l’effet de la mise à jour réelle soit le même que celui obtenu à travers la vue. Cette équivalence peut s’exprimer ainsi : U(X(BD)) ≡ X(U’(BD)) L’unicité de la fonction (ou procédure) U' est la seule condition pour qu’une mise à jour, par l'entremise d'une vue, soit admissible. La fonction U' doit être unique pour assurer aussi l'unicité du résultat dans la BD elle-même. Or, il est très difficile de démontrer si l’équivalence ci-dessus existe, sauf dans des cas relativement simples.



130

Indicateur NULL et vue relationnelle L’autorisation du NULL pour les attributs de la clé étrangère peut engendrer un problème d'incohérence, notamment lorsque les opérations algébriques utilisent une vue relationnelle. Soit la BD suivante composée de deux relations : Empl et Dep. Empl : nas eNom naiss noDep 123 Savard 10-dec-1975 d2 350 Wang 15-sep-1980 d5 525 Begin 12-jan-1982 null 625 Bedard 7-jan-1981 null

Dep : noDep * nomD chef d2 vente 123 d5 recherche 350

Figure 5.61 Supposons qu'il soit demandé de produire une liste des employés comportant le nom et, s’il est disponible, le numéro de département. Idéalement, quelle que soit la procédure utilisée, le schéma de cette réponse est (e-nom, noDep), la liste devrait être correcte. Supposons qu'une vue relationnelle existe avec le schéma recherché et qui est définie par la jointure suivante : Vue10(eNom, noDep)

Le calcul de l’extension se fait par la jointure (Empl |x| Dep).

La simple projection de la vue Vue10 devrait fournir la bonne réponse (Figure 5.62).

Vue10 : eNom noDep Savard d2 Wang d5

Figure 5.62 Cette liste est incomplète, car elle n'inclut pas les employés dont l'affectation n'est pas encore précisée. D'autre part, une autre application qui exploiterait la seule projection de Empl sur les attributs eNom et noDep fournirait la bonne réponse! On voit donc que la présence de valeurs nulles pour les attributs de la clé étrangère peut conduire à des résultats faux, selon la nature de la procédure utilisée par les applications.

Sommaire Le modèle relationnel a été défini en 1970 de façon formelle, ce qui lui donne une assise rigoureuse. Ce modèle théorique détaillé comprend des contraintes de clé, les contraintes référentielle et logique qui jouent un rôle de premier plan. Pour la première fois, l’étude a porté sur un modèle complètement détaché de son implémentation et assorti de son propre langage de données. Le MRD a un langage de manipulation des tables fondé sur une algèbre relationnelle dont la sémantique des opérateurs est aussi définie avec précision. L’algèbre relationnelle est complète et valide, c’est-à-dire qu’elle permet de traiter toute requête de recherche et de modification sur des données de la base. Elle fournit comme réponse à chaque opérateur une extension dont le schéma est valide et qui vérifie aussi la relation universelle qui présume que la BD est dérivable par la simple projection avec une relation dont le schéma est composé de tous les attributs. De tous les opérateurs de l’algèbre, la jointure est de loin le plus critique. Le calcul



131

de cette jointure engendre la charge la plus importante pour un SGBD. Selon la technique utilisée, la performance varie énormément en fonction de son implémentation, tributaire d’une mémoire RAM importante, plus particulièrement, d'une plus grande zone de mémoire partagée en RAM. Le schéma relationnel est normalisé afin d’avoir uniquement des relations dites normales dont la forme normale ultime est la FN5. Ces formes ont la propriété de minimiser les anomalies d’ajout, de suppression et de modification, assurant par le schéma un appui direct et efficient à la cohérence des données de la base. Plusieurs langages de données de haut niveau ont une base algébrique et génèrent, à la suite d'une compilation ou d'une interprétation, un plan d’exécution exprimé par une chaîne de procédures qui implémentent les opérations algébriques. Toutefois, certaines opérations, notamment la quantification universelle, sont implémentées par une expression algébrique équivalente trop lourde pour être utile. Certaines propositions récentes apportent une réponse à ce problème par un opérateur de division intégré au langage de données. La mise à jour d’une BD relationnelle à travers une vue pose toujours des problèmes parce qu’il est impossible de résoudre l'ambiguïté pour les traitements sur les relations de base, simplement par un algorithme général (cas indécidable). Plusieurs concepteurs de SGBD sont alors amenés à poser des contraintes strictes quant à l’exploitation des vues pour la mise à jour de la BD, tandis que d’autres proposent une variante un peu plus riche grâce à la matérialisation des vues. Le modèle relationnel et son langage algébrique ont été abondamment étudiés et décrits dans de nombreux articles et livres récents, notamment ceux de Abiteboul, Delobel, Date, Desai, Gardarin, Navathe, Miranda, O’Neil, Ullman, Widom et Fabian. Exercices résolus 1- Soit la BD LR composée de la relation Livraison, qui représente le nom et le nas de l'expéditeur ainsi que le nas du receveur pour une livraison d'un colis, et de la relation Reception, qui comprend les données de la personne qui a réceptionné le paquet. Les attributs concernant le receveur peuvent avoir des valeurs nulles :

Livraison (noLiv*, nomExp, nasExp, nasRec, cout) Reception (nasRec*, nomRec, ville, tel)

Les seules DF de cette base sont celles définies par les clés primaires : F = { les DF des clés} a) Identifier la ou les clés étrangères dans ce MRD. Réponse : Il n'y a qu'une seule clé étrangère dans ce modèle, soit le nas du receveur, nasRec, puisque cet attribut de Livraison est une clé choisie dans la relation Reception. b) Donner l'arborescence de la plus simple expression algébrique pour lister le numéro des livraisons pour lesquelles le receveur du colis en était aussi l'expéditeur. Réponse : Ce cas est résolu facilement parce que la relation Livraison contient les attributs nasExp et nasRec. Il suffit donc de faire une sélection avec un prédicat d'égalité entre le receveur et l'expéditeur (via leur nas). Finalement, il faut faire une projection pour n’obtenir que le numéro des livraisons en question. La procédure peut être aussi formulée sous forme d'une arborescence. La procédure est exprimée ainsi : ∏noLiv (σ nasExp = nasRec (Livraison)) La forme arborescente de cette même procédure est la suivante :



132

La requête est exécutée de bas en haut. Une première opération est la sélection dans la relation Livraison, suivie par la projection du résultat sur l'attribut no-liv. Lors de l'implémentation, la sélection et la projection sont exécutées au cours de la même lecture des tuples. On dit alors que ces deux opérateurs sont exécutés en mode pipeline. c) Donner l'arborescence de l'expression algébrique pour lister la ville de livraison pour les cas où l'expéditeur est aussi le receveur. Réponse : d) Donner l'arborescence de l'expression algébrique pour lister le numéro et le coût de chaque livraison faite à Québec. e) En supposant que la réponse précédente soit représentée par la relation Rep, donner une expression algébrique pour faire la somme des coûts pour les colis livrés à Québec. Utiliser la fonction générale de groupement, ()G() (). Réponse : Le schéma de Rep est formé des attributs noLiv et cout: Rep (noLiv, cout) G (Sum(cout)) (∏ cout (rep)) La forme linéaire de la formule est moins lisible que l’arbre de requête correspondant. La fonction Sum() est appliquée à tous les tuples de la table Rep qui représentent les livraisons à Québec. 2- Un distributeur d'ordinateurs assemble ses propres systèmes caractérisés par la présence de deux disques durs dont la capacité de l'un est le double de l'autre. Les disques dont il dispose sont représentés dans la relation Disque. Donnez une expression algébrique pour lister toutes les configurations possibles des disques que ce distributeur peut offrir, en affichant le numéro de chaque disque de la paire possible. Voici un exemple de l'extension de la relation Disque:

∏ noLiv

σ nasExp = nasRec Livraison

GSum(cout)

Πcout

Rep

∏ Reception.ville |XLiraison.nasRec = Reception.nasRec and ivraison.nasExp=Livraison.nasRrec

Livraison Reception



133

disque : noDisq capacite Prix D10 100 50 D200 200 75 D21 200 65 D11 100 40 D50 500 175 D55 500 170 D56 250 140

Réponse : Il suffit de faire un produit cartésien de la relation Disque avec elle-même et de filtrer le résultat par le prédicat qui ne retiendra que les configurations pour lesquelles le deuxième disque a une capacité double de celle du premier disque de la configuration. C'est donc une autojointure qui est effectuée. b) Donner l'arborescence algébrique de la requête SQL ci-dessous et formulez en français la sémantique de la réponse. Réponse :

Livraison (noLiv*, nomExp, nasExp, nasRec, cout) Reception (nasRec, nomRec, ville, tel) SELECT L.nasRec, R.ville, L.cout * 0.15 as ‘Total_Taxe’ FROM Livraison L , Rec R WHERE L.nasRec = R.nasRec and L.cout * 0.15 > 150.00;

En français, c'est-à-dire en langage naturel, les tuples de la réponse représentent le nas, la ville des receveurs de colis et le total des taxes payées pour les colis recus dont le prix avant les taxes est supérieur à 150$. 3- Soit la relation Elections pour représenter les résultats des élections de la dernière décennie. Elections (date*, region*, depute, premierMinistre) et F = { date --> premierMinistre; date, region --> depute; date, region --> premierMinistre}. Les dépendances qui ne sont par formulées explicitement sont réputées être absentes ou non valides. Exemples :

region -/-> depute; depute -/-> premierMinistre; region -/-> premierMinistre;

∏ Disque.noDisq, Disque.noDisq |X| Disque.capacite * 2 = Disque.capacite Disque Disque

∏ Livraison.noLiv, Livraison cout |X| Livraison.nasRec = Reception.nasRec and Livraison.cout * 0.15 > 150.00 Livraison Reception



134

premierMinistre -/-> depute. NB : le -/-> est la négation de la dépendance fonctionnelle. Est-ce que cette relation est en FNBC? Justifiez votre réponse. Réponse : Elle doit être en premier en FN3. La clé est composée. Les attributs non primaires sont député et premierMin. À cause de la DF date ‐‐> premier‐min, la relation nʹest pas en FN3 et donc pas en FNBC. 4- Voici un MRD pour modéliser les cours et les inscriptions pour un trimestre.

Inscription(matricule*, cours*, section) Enseignement(prof*, cours*, section) Supervise(prof*, matricule*) Pre-requis(cours*, prealable *) Notes(matricule*, cours*, note, annee) Etudiant(matricule*, nom)

4.1 Donnez l’expression algébrique pour lister les noms d’étudiants qui suivent un cours avec le professeur Dufour ou le professeur Ducepte . Réponse : Π nom (Etudiant |x| (σ prof = 'Dufour' or prof = 'Ducepte' ( Inscription |x| Enseignement))) ou cette autre expression : ( (σ section IN ((σ prof = 'Dufour' or prof = 'Ducepte' (Enseignement)) (Inscription) |x| Etudiant) 4.2 Donnez l’expression algébrique pour lister les noms d’étudiants qui ont pris au moins un cours avec leur superviseur de recherche. Réponse : Avec une jointure naturelle (qui a une condition de jointure implicite sur les attributs de même libellé ). Π nom (Supervise |x| (( Inscription |x| Etudiant ) |x| Enseignement)))

5- Soit les relations suivantes : Employe(nas*, nom)

Projet(code*, nomProj, nasChef) Affectation(code*, nas*) N.B. Certains projets sont modélisés sans avoir d’employés affectés à leur réalisation. Une expression algébrique peut être formulée sous la forme d’arbre ou d’une formule avec les parenthèses appropriées. 5.1 Donnez l’expression algébrique pour lister les noms de projets auxquels travaille l’employé dont le nas est 107. Réponse : Π nomProj (σ nas = ‘107’ ( Projet |x| Affectation))



135

5.2 Donnez la clause SQL équivalente à l’expression algébrique précédente. Réponse :

SELECT P.nomProj FROM Projet P, Affectation A -- alias non obligatoires WHERE P.code = A.code and nas = ‘107’;

5.3 Donnez l’expression algébrique pour obtenir la liste des nas des employés affectés aux projets supervisés par le chef dont le nas est 120. Réponse : Π nas (σ nasChef = '120' (Projet) |x| Affectation) 5.4 Donnez l’expression algébrique pour lister les noms de projets auxquels l’employé dont le nas est 110 n’est pas affecté. Réponse : (jointure naturelle et différence puisque les projets sans affectation doivent être inclus dans la réponse. Π nomProj (Projet)) - (Π nomProj (σ nas = '110' (Projet) |x| Affectation)) Une jointure thêta peut être aussi utilisée à la place de la jointure naturelle et de la sélection : (Π nomProj (Projet)) – ( Π nomProj (Projet |x|θ Affectation)) θ : Projet.code = Affectation.code and nas != ‘110’ -- pour obtenir les projets avec affectations et auxquels l’employé 110 ne travaille pas. 5.5 Donnez l’expression algébrique pour lister des nas et des noms des employés qui sont affectés aux projets auxquels l’employé 130 n’est pas affecté. Réponse : (avec jointure naturelle) nas, nom(Employe |x| (σ nas != '130' (Projet) |x| Affectation)) Une jointure thêta peut être aussi utilisée à la place de la jointure naturelle et de la sélection : nas, nom (Employe |x||θ2 (Projet) |x|θ1 Affectation)) 1 : Projet.code = Affectation.code and nas != ‘130’ 2 : Employe.nas = Affectation.nas Exercices Voici une base de données Joueur-Match-Commandite (JMC) composée de trois (3) tables. Les clés sont indiquées avec l'astérisque. Par exemple, la relation Joueur utilise le nom comme clé; elle ne peut donc pas représenter deux joueurs de même nom dans cette base fictive. Pour contourner cette difficulté, il aurait fallu utiliser le matricule comme clé.



136

BD JMC : Joueur(nom*, prenom, age, nationalite, societe) Match(dateM*, lieu*, score, nomG, nomP) Commanditaire(societe*, montant, duree)

Avec F = { les DF sous-tendues par les clés primaires} Un match de tennis est identifié par la rencontre, à une date déterminée, de deux joueurs dont l'un est obligatoirement gagnant. Une commandite est toujours associée au joueur et non au match et elle est toujours du même montant, déterminé par le commanditaire. Les attributs nom, nomG (nom du gagnant) et nomP (nom du perdant) partagent le même domaine sémantique.

Joueur : nom* prenom age nationalite societe Tremblay Patricia 22 fr CGI Gagnon Jacques 23 ca Bell Marois Sherly 20 usa Bell Beaumont Michel 24 fr Bell Dery Paul 19 ca null Fournier Nadine 22 ca DMR

Match : dateM* lieu* score nomG nomP 1998 Qc 12 Beaumont Gagnon 1995 Mtl 3 Marois Fournier Qc 12 Fournier Gagnon 1998 Qc 8 Tremblay Dery 1999 Qc 2 Beaumont Gagnon 1999 Paris 7 Tremblay Gagnon

Chaque joueur a participé au moins à un match, mais n'a pas nécessairement un commanditaire. Ce dernier lorsqu'il est inscrit dans la BD a nécessairement souscrit une ou plusieurs commandites pour un montant déterminé. Les clés de chaque relation sont identifiées par les astérisques et sous-tendent les seules DF valides dans ces tables. La date est formée avec seulement l'année. Le score inscrit est celui du gagnant.

Commanditaire : societe* montant duree Bombardier 5000 2 CGI 2000 5 LGS 3000 2 DMR 6000 3 Bell 5000 2 Caisse-Pop 5000 5

Section A 1- Donner les clés étrangères des relations Match et Joueur. Ensuite, formuler explicitement toutes les dépendances fonctionnelles (DF) valides dans ces trois relations de la BD JMC. 2- Déterminer la plus grande forme normale de chaque relation du modèle JMC; commenter votre réponse.



137

3- Expliquer sous quelles conditions il serait possible de représenter un joueur non commandité ainsi qu’une société dont le montant de la commandite est indéterminé. 4- Un match ne peut être représenté dans la base de données que s'il a été joué et s'est terminé avec un gagnant. Quel est l'impact de cette contrainte sur la relation Match? 5- Faire la ré ingénierie du MRD JMC pour obtenir le MCD correspondant.

Section B : expression algébrique présentée comme une formule ou un arbre Formuler les expressions algébriques les plus simples pour répondre aux questions ci-dessous. Présumer aussi que tous les opérateurs étudiés sont implémentés par le SGBD. Lorsque la question fait référence au nom de la table ce sont tous ses attributs qui doivent être affichés. Si vous le jugez nécessaire, vous pouvez construire une extension avec des données fictives afin de calculer la réponse des expressions algébriques et en vérifier la justesse. 6- Donner le nom et l'âge des joueurs gagnants, peu importe la date, et qui ont participé au moins à un match en 1994. 7- Préciser le nom, l'âge des joueurs et le montant de la commandite de Bombardier pour ceux et celles qui ont participé à au moins un match entre 1985 et 1995, sauf pour 1990. 8- Déterminer le nom des joueurs qui ont joué des matchs sans en perdre un seul. 9- Fournir le nom des gagnants et la date de leurs victoires entre 1985 et 1995, sauf pour celles de 1990. 10- Donner la liste des lieux de matchs joués en 1995 et les regrouper par lieu de compétition. 11- Préciser le nom des sociétés qui ont commandité au moins un joueur de toutes les nationalités représentées dans la table des Joueurs. Formuler l'expression algébrique la plus simple en supposant que les opérateurs suivants sont disponibles dans le langage de données : sélection, projection, jointure, division, union, intersection, différence. 12- Donner la liste des joueurs inscrits qui n'ont pas encore joué un match.

Questions avec des fonctions de tuple et de groupement. 13- Donner la société commanditaire qui a signé la commandite la plus longue (durée la plus longue). 14- Donner la liste des joueurs qui sont commandités par une société dont la commandite est la plus longue parmi celles inscrites dans la BD. 15- Donner le score moyen par année des matchs joués.

Section C Pour les questions suivantes, donner l'expression algébrique (arborescente) équivalente à chaque requête SQL. Noter aussi que la syntaxe du langage SQL oblige de transposer le trait d'union (-) dans un libellé par le souligné ( _ ). Les quelques clauses SQL nécessaires pour répondre aux questions de cette section ont été étudiées comme étant équivalentes à des opérateurs algébriques de base.



138

16- SELECT * FROM Joueur WHERE age BETWEEN 23 and 39 AND societe = 'Cascades';

L'astérisque représente le schéma complet du tuple, i.e. dans le cas d'une sélection tous les attributs de la relation Joueur. 17-

SELECT J.nom, J.nationalite, M.date_m FROM Joueur [AS] J, Match [AS] M WHERE J.age > 40 and J.nom = M.nomG;

N.B. L'alias est défini par le mot clé AS. Il est possible que le SGBD que vous utilisez, ne définisse pas l’alias au moyen du AS. Par exemple, un espace (SQL-89) plutôt que par le mot clé AS est utilisé SQL 89. En algèbre relationnelle, l'alias de nom de table est défini par l'opérateur ρ (rhô) . 18-

SELECT distinct M.nomG FROM Match [as] M, Match [as] P WHERE M.nomG = P.nomP ;

19 - SELECT 3* montant [as] 'Prévision-de-financement' FROM Commanditaire WHERE montant >12000.00;

N.B. Dans le contexte d'une expression, l'astérisque représente l'opérateur de multiplication et non l'ensemble des attributs d'une projection. 20-

(SELECT nomG FROM Match WHERE dateM = 1996) MINUS (SELECT nomP FROM Match WHERE dateM > 1990);

21- Formuler en français, ce que représente la réponse obtenue pour les questions 4 et 5. Il ne s'agit pas de transposer la clause SQL en français en la décrivant, mais bien de formuler en qulque sorte la question qui exigerait cette clause.

Section D 1-Voici un MCD pour représenter la production des pièces par les ateliers et leur utilisation par les usines. Dans la base de données correspondante, les attributs ville, description et eMail sont des chaînes de caractères de longueur variable, tandis que les autres attributs sont des entiers. Lorsqu’une usine ferme, les pièces inutilisées restent inscrites dans la BD.



139

22- Transformer ce MCD en MRD (modèle relationnel de données). Ne pas spécifier les domaines à ce stade. Les attributs primaires sont identifiés par un astérisque. 23- Au départ, la BD est vide. Quelles sont alors les tables qui seront chargées en premier? Expliquer votre réponse. 24- Écrire le schéma de la table Pièce en utilisant les clauses SQL-DDL. Une clause DDL en est une qui permet de créer les structures et de spécifier les contraintes. 25- Voici une table pour modéliser l'encadrement assuré par les conseillers auprès des étudiants.

ConsEtud(noEtudiant, mineure, conseiller) On peut écrire le schéma en remplaçant chaque attribut par une lettre : ConsEtud (e, m, c) Voici les règles sémantiques qui sont sous-tendues par cette relation : Chaque étudiant peut obtenir son diplôme après avoir réussi plusieurs mineures (programme d'études); Pour chaque mineure, un étudiant a un seul conseiller; L'encadrement des étudiants d'une mineure peut être assuré par plusieurs conseillers; Chaque conseiller encadre plusieurs étudiants d'une mineure; Chaque conseiller dispense un encadrement pour une seule mineure. Voici un exemple d'une instance de la base valide :

ConsEtud : noEtudiant mineure conseiller e1 m1 c3 e2 m1 c5 e1 m2 c4 e6 m1 c3

25.1 Formuler les dépendances fonctionnelles de cette table en considérant qu'elles sont toutes validées par cette instance. 25.2 Quelle est la clé de cette table? 25.3 Quelle est la plus grande normalité de cette table? Justifier votre réponse en vous référant aux définitions des formes normales. 25.4 Transformer s'il y a lieu la table initiale pour obtenir une base en FNBC. 26- La base de données de GESPRO pour la gestion de ses propriétés comprend les tables suivantes :

Piece noP* description

Atelier noAtelier* ville

Usine noU* eMail

Fabrique qte

Utilise nbP



140

Immeuble (nomI*, adresseI, nbEtages, anneeConstruc, gerant) Appart(nomI*, noApp*, superficie, etage) Occupant ( nomI*, noApp*, nasOcc*, anneeArr, anneeDep) Personne(nas*, nom, age, profession)

Formulez les expressions algébriques pour répondre aux questions ci-dessous.

Affichez le nom des immeubles ayant plus de 10 étages. Le nom des personnes ayant occupées un appartement avant 1965. Quel est le nas des personnes qui habitent le Louis Riel ? Affichez le nom des informaticiens de plus de 30 ans. Qui gère l’immeuble où habite Lysa ? Qui a emménagé au moins 10 ans après la construction de son immeuble. Quelles sont les professions des occupants de l’immeuble Le Grand Large ? Affichez le nom des personnes qui habitent présentement un appartement situé au dernier étage de leur immeuble. Donnez le nom du gérant qui habite l’immeuble qu’il gère. Affichez le nom des personnes qui habitent présentement l’immeuble La Brise du Nord. Affichez le nas des personnes qui habitent un immeuble depuis plus de 2 ans. Affichez le nom des personnes qui habitent La Brise depuis 1990.

Chapitre 6 Transposition du MCD en MRD


141

Chapitre 6 Transposition du modèle conceptuel au modèle relationnel

Dans ce chapitre, nous allons étudier les règles de transposition du modèle conceptuel E/A au modèle relationnel que nous avons étudié au chapitre précédent. Cette transformation du MCD au MRD n′est pas déterministe. Le MRD cible obtenu dépend de certains choix faits par l’administrateur de la base de données en fonction des facteurs comme les propriétés de certains attributs, la performance attendue dans l’exploitation de la base et l’évolution prévisible du schéma initial. Des règles similaires sont appliquées avec le diagramme de classes. À la fin du chapitre nous verrons un cas complet de transposition d’un MCD UML. Le passage du MCD E/A au modèle logique relationnel (MRD) consiste à appliquer récursivement un certain nombre de règles de transposition (8,9) (mapping rules) aux attributs, aux classes et aux associations. Au cours d'une telle transformation, il peut y avoir des choix à faire en fonction des traitements prévus sur la base. Cette transposition sous-tend souvent une simplification du modèle comme par exemple la suppression d’une association présente dans le MCD et qui n’apparaît pas directement dans le MRD suite à son inclusion dans une table. Cette opération doit se faire sans introduire de préférence de nouveaux attributs. Toutefois, lors d’une telle réingénierie de système ou de la base, il peut arriver qu'un identifiant soit ajouté dans une table pour avoir une clé primaire simple, et cela même si ce nouvel attribut n’est pas significatif aux utilisateurs. Ces règles de passage ont favorisé la mise au point de méthodes de conception des applications à l’aide des outils CASE dont l'intérêt est de générer un schéma relationnel quasi opérationnel à partir du MCD (10). Rappelons aussi que le terme Entité appartient à la terminologie de la méthodologie E/A et qu’il est le synonyme de Classe. Traitement du MCD 6.1 Transformation d'un attribut composé en une Entité Dans le modèle relationnel, seuls les attributs atomiques (simples) sont admissibles.

Figure 6.1 Deux transformations préalables sont possibles avec le modèle conceptuel pour obtenir des attributs simples : a) Remplacement de l’attribut composé par les attributs atomiques de ses composants (linéarisation de l'attribut composé). L’Entité Personne sera par la suite remplacée par une table relationnelle. Pour accéder seulement à la valeur de l’attribut ville, il suffit d’utiliser la variable pointée Personne.ville.

Personne nom* age adresse : (composé) - no -rue -ville -code-postal

Personne nom* age no rue ville code-postal

Attribut composé du MCD Attributs simples du MCD



142

b) Conservation du nom de l’attribut composé (adresse), mais en le traitant comme un attribut simple à la condition qu’il soit constitué par la concaténation des valeurs de ses éléments. L’accès à un de ceux-ci sera alors un traitement supplémentaire pour chaque application Par exemple, l'attribut composé est transformé en une chaîne obtenue par concaténation des données séparées par un délimiteur. Une application peut alors obtenir la chaîne de l’adresse – accès par la fonction val()- mais elle doit en extraire la ville par une recherche des délimiteurs. val(adresse) = ‘34#DesRosiers#Québec#G4E2W1’ La chaîne de caractères obtenue par l’application comprend le numéro, la rue, la ville et le code postal. Pour obtenir seulement la ville, l’application devra faire une recherche supplémentaire dans la chaîne en exploitant la présence du délimiteur. Ce traitement s’impose en raison de l'absence de types complexes dans le modèle relationnel standard.

Transformation de l’attribut multivaleur (mv) Le traitement d’un attribut multivaleur (aussi dénommé multivalué) du MCD exige l’insertion d’une nouvelle classe (ou Entité). Il y aura une nouvelle association dans le MCD pour chaque attribut multivaleur.

Figure 6.2 Un produit fini utilise 0 ou plusieurs composants, et ce dernier peut entrer dans la composition de plusieurs produits. La nouvelle structure du MCD respecte donc cette contrainte au moyen de la participation partielle de la nouvelle association Utilise.

Transformation de l’attribut multivaleur dʹune association Un attribut multivaleur caractérisant une association génère une nouvelle classe incluant l'attribut multivaleur considéré comme atomique et la clé en provenance d'une des classes participant à l'association. Cette nouvelle classe hérite de l’association existante. Rappel : Une association est dite 1-1 si la cardinalité (i.e. le max dans la notation (min, max)) est 1 des deux côtés de l'association. Une association est dite 1-n ou 1-N si la cardinalité est 1 d'un côté et n de l'autre et cela peu importe la participation. Finalement, elle est dite n-m, si la cardinalité est de plusieurs à plusieurs. Le n et le m signifient donc plusieurs sans autres précisions. Deux cas sont possibles pour le traitement de l’attribut multivaleur d’une association :

Composant codeP* codeComposant*

Utilise

0..*

0..*

Produit codeP* description prix composants (1) (mv)

(1) mv = signifie multivaleur

Produit codeP* description prix



143

a) Si l’association est du type n-m, elle est transposée en une association ternaire avec une nouvelle classe formée avec les deux clés primaires augmentées de l’attribut multivaleur de l'association ternaire. Pour chaque instance du couple (Produite, Distributeur) il y a plusieurs instances de ProdDist. En d’autres mots, un distributeur d’un produit peut le vendre à différents prix. b) Si l'association est du type 1-M , seule la clé primaire de la classe 1..m est ajoutée à la classe de l'association ternaire :

Figure 6.3

mv = attribut multivaleur

Produit code* description

1..*

Distributeur matricule*

1..*

AccordeA prix(mv)


1..*

1..*


1..* ProdDist code* matricule* prix*

mv = attribut multivalué


1..*


1

AccordeA prix (mv)


1

1..*


1..* ProdDist code* prix*



144

6.2 Transposition de la ternaire en une relation Chaque classe est représentée par une table ou relation du MRD; les attributs de la classe et sa clé deviennent ceux d’une relation du modèle MRD. La participation de la classe à l’association ternaire sera traitée ultérieurement. La figure 6.4 illustre ce passage d’une ternaire et la création de trois relations distinctes. L’association ternaire AccordeA est représentée par une autre table dont tous les attributs sont primaires i.e. composent la clé de cette table.

Figure 6.4

Transposition de lʹassociation binaire La représentation d'une association binaire du modèle conceptuel dépend des multiplicités.

a‐ Transposition de lʹassociation 1‐1 avec participation totale Il y a fusion des Entités du MCD (classes) et de l'association en une seule relation du modèle relationnel.

Figure 6.5

La fusion de l'association et des deux classes donne une relation définie avec tous les attributs du modèle conceptuel d'origine. Si les deux classes participantes ont la même clé, celle-ci n’apparaît qu’une fois dans la nouvelle relation. Sinon, la clé est formée avec l'une des deux clés d'origine, tandis que l'autre est un attribut interdit de l’indicateur null, et cela, afin d'implémenter la multiplicité 1..1 du MCD. Un client ne peut pas alors exister sans participer à l'association Place et sans avoir un numéro de bordereau de commande. Il en est de même pour une livraison qui ne peut pas être représentée si le matricule du client n'est pas aussi enregistré. Le fait que les deux multiplités soient 1..1 sous-tend la participation totale et l’ajout d’un client doit se faire avec une

ClientLivraisonCommande (matricule*, description, noBordereau, adresseLivraison)

MRD : Produit (code*, description) Distributeur (matricule* ) ProdDist(code*, prix) AccordeA (code*, matricule*, code*, prix*)

N.B. L'association AccordeA fera par la suite l'objet d'un traitement particulier


1

1..*


1..*

ProdDist code* prix*

LivraisonCommande noBordereau* adresseLivraison

1..1 1..1 Client matricule* description

Place



145

commande dans une transaction. La vérification des cardinalités devra se faire qu’au terme de la transaction c’est-à-dire après les deux ajouts.

b‐ Transposition avec la participation partielle dʹun seul côté de l’association Si une multiplicité est 0..1, c’est-à-dire qu’il y a une participation partielle, alors quelques transformations sont possibles. Le choix pourrait dépendre de l’évolution anticipée du modèle comme, par exemple, une modification des multiplicités.

Figure 6.6

MRD 1 : Pour obtenir cette version, il y a fusion des deux classes en une seule relation dont la clé est matricule puisque la multiplicité prévoit qu’un client n’a pas l’obligation de participer à l’association (0..1). Les attributs noDossier et limiteCredit peuvent être avoir un null conformément à la spécification du MCD. Un client peut alors être représenté même s'il n'a pas encore de dossier de crédit. Au contraire, il est impossible de représenter un dossier de crédit s'il n'est pas associé à un client connu. En outre, une application a accès à toutes les informations en traitant qu’une seule relation. C’est le MRD optimal pour une telle association. MRD 2 : Si l'évolution anticipée du modèle met en cause un changement de la multiplicité de l'association, la seconde transposition présente l'avantage de minimiser la réorganisation ultérieure de la base. L'obligation pour le dossier de crédit de participer à une association pourrait être renforcée en interdisant le null pour la clé étrangère, soit l'attribut matricule. Ce modèle est de toute évidence un peu plus élaboré et sous-tend un calcul en cours d'exploitation des données pour établir l’association entre les données des deux tables.

Transposition impliquant deux contraintes de participation partielle : 0..1 Lorsque la contrainte est de type 0..1 des deux côtés, comme dans l'exemple ci-dessous, l’association entre les deux relations associées peut être implémentée par une clé étrangère. Les femmes non mariées sont représentées avec le null pour la clé étrangère. La liste des couples peut être obtenue par le balayage d'une seule relation, sans exiger de jointure, à moins que le nom ne soit demandé par la réponse.

0..1 DossierCredit noDossier* limiteCredit

MRD 1: ClientDossierCr (matricule*, description, noDossier, limiteCredit)

MRD 2: Client (matricule*, description) DossierCredit ( noDossier*, limiteCredit, matricule)

1..1

Client matricule* description

Possede



146

a- Association implémentée par la clé étrangère

Figure 6.7 Chaque relation a une contrainte référentielle définie avec l’autre relation. Les clés étrangères sont matriculeF et matriculeH. L’action référentielle pourrait être selon le contexte de la modélisation, le SET NULL et cela, afin de permettre la représentation des femmes et des hommes qui divorcent subséquemment.

b‐ Fusion des deux classes Si les classes sont fusionnées pour obtenir une seule relation Mariage, il devient impossible de représenter les hommes et les femmes non mariés puisque la clé est composée en exigeant une valeur pour les deux attributs primaires. Mariage(matriculeH*, nomH, matriculeF*, nomF) La modélisation relationnelle avec une seule relation impose alors que les hommes non mariés devront avoir un matriculeF correspond ainsi à un modèle plus strict que celui de la figure 6.7.

c‐ Spécialisation des classes Une autre transformation possible est de spécialiser les classes Homme et Femme pour obtenir deux nouvelles classes, HommeMarie et FemmeMariee, de manière à supprimer la participation partielle de l’association. Il y a donc héritage d’une association totale par les sous-classes (Figure 6.8).

Figure 6.8 Cette nouvelle association Marier a une multiplicité 1..1 conduisant à la création d'une relation unique intégrant les classes participantes et les attributs hérités de leur superclasse respective. En raison de la spécialisation partielle, les classes Homme et Femme sont alors transposées en relations pour représenter que ceux et celles qui ne sont pas mariés. Le renommage des relations spécialisée par un libellé plus adéquat permet de préciser au besoin leur sémantique respective : HommeCelibataire et FemmeCelibataire. Une telle transposition génère cependant plusieurs tables, ce qui oblige éventuellement les applications à faire des jointures supplémentaires.

Homme matriculeH* nomH

Femme matriculeF* nomF

HommeMarie FemmeMariee Marier 1..1 1..1

p p

Marier Homme

matriculeH* nomH

Femme matriculeF* nomF

0..1 0..1

Homme(matriculeH*, nomH, matriculeF) Femme (matriculeF*, nomF, matriculeH)



147

Dans le cas du modèle de la figure 6.8, l'ajout d'un homme célibataire correspond à l’ajout d’un tuple dans la relation Homme avec un null comme clé étrangère. L'ajout d'un homme marié doit se faire cependant avec trois actions solidaires : ajout du tuple avec une clé étrangère nulle, ajout s'il y a lieu de sa conjointe dans la relation Femme avec la clé étrangère appropriée et finalement, mise à jour de la clé étrangère du conjoint inséré. C’est une transaction. En contrepartie, la suppression d'un tuple dans la relation Femme ou Homme ne doit pas engendrer une suppression dans l'autre relation, mais seulement par l’attribution du null à la clé étrangère (par exemple avec le SET NULL de SQL-92).

6.3 Transposition de lʹassociation binaire 1‐n Deux cas sont possibles, selon les contraintes de participation de l'association. a- Cas de multiplicité 1..n Deux relations, Ville et Province, sont créées. La relation correspondant à l’association est fusionnée avec la relation Ville dans le MRD.

Figure 6.9

La clé de Ville n’est pas composée, puisque chaque ville est unique par son nom, peu importe la province (unicité globale présumée). Finalement, la clé de la classe Province, est intégrée du côté 1..n à titre de clé étrangère. La contrainte référentielle doit être activée et l'attribut nomP de la relation Ville est spécifié NOT NULL afin de renforcer le fait qu'elle doit obligatoirement être associée à une province existante dans la base de données. Cependant, un tuple de la table Province peut être ajouté sans avoir, dans la même opération, à inscrire aussi une ville. La multiplicité 1..n du côté Ville n'est pas implémentée, i.e. qu’il n’y a pas de vérification qu’une province soit associée à plusieurs villes. Si elle devait l’être, il faudrait la renforcer au moyen d’un trigger. b- Cas de la multiplicité 0..n avec un attribut d’association La transposition conduit à un MRD de deux relations avec une clé étrangère et migration de l'attribut de l'association dans la relation Commande, c'est-à-dire du côté 0..n. En outre, l'attribut de l'association doit permettre au besoin l’indicateur null. De plus la contrainte structurelle 1..1 de Vendeur est renforcée par le fait que le ou les attributs de la clé étrangère de la classe Commande seront spécifiés NOT NULL dans le schéma.

Ville nomV* popV

Province nomP* popP

Creer 0..1 1..*

Province (nomP*, popP) Ville(nomV*,popV, dateV, nomP)

HommeCelibataire(matriculeH*,nomH) –que les hommes célibataires FemmeCelibataire(matriculeF*,nomF) –que les femmes célibataires HommeMarie (matriculeH*, nomH, matriculeF) FemmeMariee (matriculeF*, nomF, matriculeH)



148

Figure 6.10 La multiplicté 0..n du côté Commande est admissible puisque tout ajout de Vendeur est possible même s'il n'a pas encore rédigé une commande. Par contre, une commande doit référer obligatoirement à un vendeur. En spécifiant que la clé étrangère ne peut pas être un null, on est assuré que toute commande est attribuée obligatoirement à un vendeur.

6.4 Transposition de lʹassociation binaire N‐M La transposition d'une association de plusieurs à plusieurs se fait en deux étapes : créer une classe intermédiaire de jonction et deux associations 1-n. Ensuite, traiter ces nouvelles associations selon la règle de transposition pour l’association 1-n.

Figure 6.11 La nouvelle classe de jonction est constituée par la clé primaire de chacune des classes participantes à l’association n‐m d’origine, plus les attributs spécifiques à lʹassociation.

Etudiant (matricule*, adresse, tel) Cours (noCours*, intitule) InscCours (matricule*, noCours*, dateIn)

Etudiant matricule* adresse tel

Cours noCours* intitule

1..* 1..*

Etudiant matricule* adresse tel

Cours noCours* intitule

1..* 1..*

1..1 InscCours matricule* noCours* dateIn

1..1

Inscrire dateIn

Vendeur (nom*, tel) Commande (noCommande*, dateC, nom)

Vendeur nom* tel

Commande noCommande* nom 0..* 1..1

PlaceCommande

PlacerCommande dateC



149

Le résultat de cette transformation en deux étapes peut être aussi obtenu directement en créant une relation avec les clés primaires et les attributs spécifiques de l’association n-m.

Transposition de lʹassociation ternaire Le traitement d'une association ternaire ou plus généralement n-aire, est similaire à celui de l'association binaire n-m. Il consiste à représenter l’association par l'entremise d'une nouvelle association.

Figure 6.12 Les trois contraintes référentielles de la relation Approvisionne sont activées tout en permettant au besoin de représenter un fournisseur qui n'a pas encore livré de pièces. Dans ce cas, l’attribut codeFourn doit pouvoir un null auquel cas l’attribut qte de la relation Approvisionne doit aussi avoir un null.

Traitement de l’association quaternaire Le traitement consiste à représenter l’association quaternaire comme une relation constituée de la clé primaire de chaque classe participante à l’association en sus de ses attributs propres.

Piece(noPiece*, description) Fournisseur(codeFourn*, nomFourn, telFourn) Produit(noProd*, nomProd) Approvisionne (noPiece*,noProd*,codeFourn*, qte)

qte

1..* Piece noPiece* description

Produit noProd* nomProd

Fournisseur codeFourn* nomFourn telFourn

0..*

1..*

Approvisionne

Vendeur noVendeur* nomVendeur

Voiture noAuto* modele

Client nasC* nomC adresseC

Banque noBanque* nomBanque

1..*

1..*

1..*

1..*

Contracte Prix taux



150

Figure 6.13 La procédure de traitement est similaire à celui de la ternaire. La sémantique d’une telle association est complexe et son interprétation difficile de sorte qu’en pratique et à l’instar de la ternaire, elle est peu utilisée.

6.5 Transformation de la généralisation /spécialisation Le traitement de l’abstraction de généralisation dépend en partie de ses caractéristiques, mais aussi dans certains cas de la taille prévue pour les extensions. Plusieurs cas sont possibles et la transposition présentée ci-dessous n'est pas unique. En effet, parfois lorsque qu'il y a seulement quelques attributs dans les sous-classes et que le null est autorisé, il peut y avoir simplement fusion de la superclasse et des sous-classes.

a‐ Cas 1 : (c, d) ou (c,e) Cette spécialisation de la classe repose sur l’équivalence de l’union des sous-classes avec la classe générique. Le modèle conceptuel est transformé en trois relations correspondant aux sous-classes ci-dessous. La superclasse est abstraite et n'est pas implémentée par une relation.

Figure 6.15

La classe générique est dans ce cas-ci abstraite et de ce fait disparaît donc du modèle logique relationnel (MRD). L’attribut code n’est pas une clé étrangère puisque la superclasse n’est pas implémentée dans le MRD. Il est parfois nécessaire de renommer les attributs hérités par les sous-

VehiculeAerien (code*, description, autonomie) VehiculeTerrestre (code*, description, nbRoues) VehiculeMarin (code*, description, tirantEau)

Client (nasC*, nomC, adresseC) Voiture(noAuto*, modele) Vendeur(noVendeur*, nomVendeur) Banque(noBanque*,nomBanque) Contracte(nasC*, noBanque*, noVendeur*, noAuto*, prix, taux)

<<Vehicule>> code* description

VehiculeMarin tirantEau

VehiculeTerrestre nbRoue

VehiculeAerien autonomie

c,d



151

classes afin d’éviter toute ambiguïté d’interprétation et répondre aux exigences de la relation universelle (Rappelons que cette hypothèse de relation universelle est la condition pour assurer que les relations obtenues par projection soient recomposables). Celle-ci exigeant que chaque attribut dont le libellé est identique corresponde à la même sémantique. De toute évidence, le code du véhiculeAerien a une sémantique différente de celle du véhiculeMarin. Pour bien marquer cette différence, il suffit de leur donner des intitulés différents. Exemple de renommage des attributs : code renommé codeVa description renommée descriptionVa code renommé codeVt description renommée descriptionVt code renommé codeVm description renommée descriptionVm

b‐ Cas 2 : (c, o) ou (t,o) Les sous-classes héritent seulement de la clé principale de la superclasse. Ainsi, il n’y a pas de redondance suite à une instance qui serait à la fois un patient et un médecin. Cet héritage partiel exige cependant de faire un calcul de jointure lorsqu’il faut réunir toute l’information au sujet d’un patient. Ce modèle peut représenter où toute personne dans le système est un patient ou un médecin et parfois les deux simultanément.

Figure 6.16 La classe générique est conservée et représentée par une relation autonome de manière à réduire la redondance possible avec le chevauchement. Les sous-classes spécialisées sont aussi représentées par une relation incluant seulement la clé de la relation générique. Cette façon de faire diminue la redondance en évitant de multiplier le nom des personnes lorsqu’un patient est aussi un médecin, et cela pour ainsi réduire les risques d’incohérence dans la base. Toutefois,

Personne (nas*, nom, age, ville)--toutes les personnes Patient (nas*, noDossier) Medecin (nas*, noCorpo)

Personne nas* nom age ville

Patient noDossier

Medecin noCorpo

c,o



152

lorsqu'il s'agit de trouver le nom d'un patient, il faudra faire une jointure pour accéder aux attributs de la superclasse. Si la sous-classe n'a pas de clé primaire propre, alors la clé obtenue par héritage de la superclasse devient à la fois la clé de la sous-classe et sa clé étrangère. Par exemple dans l’exemple de la figure 6.16, le nas a un rôle dual, soit d’être à la fois une clé primaire et étrangère dans Patient et Medecin. Pour éviter ce calcul qui peut devenir lourd avec des tables volumineuses, il suffit de tolérer la redondance en intégrant les attributs de la superclasse dans les deux sous-classes. Dans ce cas-ci, aucune contrainte référentielle n’étant déclarée, la redondance des données qui correspond à un patient qui est aussi médecin (cas de chevauchement) peut être contrôlée s’il y a lieu par un trigger de mise à jour dont le rôle est de propager vers l'autre toute mise à jour faite dans une des deux relations vers l'autre. Finalement, si le nombre d'attributs spécifiques aux sous-classes n'est pas trop grand, il est aussi possible de fusionner les trois classes en une seule relation en y ajoutant un attribut-discriminant sorte qui identifie le type de l'instance. Cette transformation est cependant une source d’indicateurs de null tout en supprimant le besoin de faire une jointure pour trouver le nom et l'âge d'un patient. Le nouvel attribut sorte permet de distinguer parmi les instances de Personne celles qui sont des patients seulement (sorte = 1) et les autres qui sont des médecins-patients (sorte =2).

b‐ Cas 3 : (i, d) ou (p, e)

Dans le cas présenté à la figure 6.17, les sous‐classes et la classe générique sont conservées dans le MRD pour pouvoir représenter quelques employés qui ne sont pas des biologistes ou des routiers. Dans le MCD ci‐dessous, un employé peut être autre chose quʹun biologiste ou un routier, par exemple un administrateur. Les sous‐classes peuvent avoir leur propre clé, mais il nʹest pas obligatoire quʹil en soit ainsi.

Patient (nas*, noDossier, nom, age, ville) Medecin (nas*, noCorpo, nom, age, ville)

Personne (nas*, sorte*, nom, age, noDossier, noCorpo)

Employe nas* nom age ville

i,d

Routier noPermis* experience cat

Biologiste noCorpo* salaire specialite



153

Figure 6.17 En effet, à défaut d'une clé spécifique, la sous-classe en hérite une, soit celle de la superclasse. La première transformation fournit le MRD1 avec les attributs communs dans la classe générique pour diminuer la redondance des données dans la BD. Avec la deuxième transposition, une redondance est créée et la sémantique de la superclasse est aussi modifiée (MRD-2) pour représentée tous les autres employés. Ce modèle avec une spécialisation (i, e) peut représenter des biologistes, des routiers, mais aussi des employés pratiquant d’autres métiers qui ne sont pas modélisés par une sous-classe particulière. Une sous-classe peut offrir de nouvelles possibilités de modélisation. Par exemple, si un biologiste travaille en collaboration avec un laboratoire, ce fait est alors représenté par une nouvelle association entre la sous-classe Biologiste et une autre classe Laboratoire. Avec le modèle relationnel MRD1, les informations concernant tous les employés sont stockées dans la relation Employe. Pour trouver la ville où habite un routier, il faut faire une jointure entre Routier et Employe. La contrainte référentielle doit être aussi activée afin de vérifier que tout ajout dans une sous-classe (Biologiste ou Routier) correspond bien à un employé existant dans la relation Employe. Aucune redondance de donnée n'est créée par cette transposition ayant recours à la spécialisation. Avec le modèle MRD2, la relation Employe représente maintenant seulement ceux qui ne sont ni routier, ni biologiste. Toute l'information concernant les instances des sous-classes est stockée dans la table même de la sous-classe. Aucune jointure nécessaire pour obtenir toute l’information concernant un biologiste. L'attribut nas des relations Biologiste et Routier n'est pas spécifié comme une clé étrangère, puisque la classe Employe ne représente pas le routier, mais bien les autres employés qui ne sont ni routier, ni biologiste. La contrainte référentielle ne peut pas être activée, car il faut pouvoir ajouter des biologistes sans l’ajout de son nas dans la table Employe.

d‐ Cas 4 : (i, o) ou (p, o) Dans le cas (i,o), la spécialisation ne concerne pas toutes les instances de la classe Employe. Les instances sont spécialisées avec l'une ou les deux sous-classes : un employé est biologiste et peut avoir aussi son permis de routier. La transposition du MCD vers le modèle relationnel se fait par

MRD1 : Employe (nas*, nom, age, ville) -- toutes les personnes Biologiste (noCorpo*, salaire, specialite, nas) – que les biologistes Routier (noPermis*, experience, cat, nas) – que les routiers

MRD2 : Employe(nas*, nom, age, ville)--que les autres personnes… Biologiste(noCorpo*,salaire,specialite, nas, nom, age, ville) Routier(noPermis*, experience, cat, nas, nom, age, ville)



154

une relation pour chaque classe spécialisée et une autre pour la classe générique. La seule redondance qui persiste est contrôlée par la contrainte de clé et la contrainte référentielle. Deux modèles relationnels sont possibles : MRD 1 et MRD 2.

Figure 6.17a Avec le MRD‐1, l’attribut nas des tables Biologiste et Routier est à la fois une clé primaire et une clé étrangère. L’ajout d’un routier ne peut se faire correctement que si ce dernier est aussi inscrit au préalable comme employé.

Avec le MRD-2, la spécialisation est représentée par une seule relation, soit Employe. Elle devient cependant une source de nulls lorsque les attributs ne s’appliquent pas à un employé. Cette dernière transposition exige aussi la présence d’un nouvel attribut-discriminant sorte pour distinguer les instances les unes des autres dans la table Employe.

Transformation d’une participation partielle en une participation totale Comment sont traitées les cardinalités de l’association lors d’une spécialisation ? Chaque fois qu’une association est partielle, la classe avec une telle contrainte peut être spécialisée en une sous-classe pour obtenir une association totale. Voici un exemple d’une association partielle pour représenter la compétence des employés à conduire un camion de livraison.

MRD-1: Employe (nas*, nom, age, ville) -- tous les employés Biologiste (nas*, noCorpo, salaire, specialite) Routier (nas*, noPermis, duree, cat)

MRD-2: Employe (nas*, sorte, nom, age, ville, noCorpo, salaire, specialite, noPermis, duree, cat)

Biologiste noCorpo* salaire specialite

Routier noPermis* duree cat

Employe nas* nom age ville

i,o

CamionLivraison noVignette* categorie

Employe nas* nom noPermis

0..1 1..* Conduire



155

Le MRD avec une spécialisation :

Le MRD sans spécialisation :

Figure 6.18 La spécialisation Employe fait disparaître la participation partielle. Le passage au MRD-1 avec une spécialisation partielle fournit trois relations. Il y a deux contraintes référentielles définies avec la superclasse Employe. Par contre le passage au MRD-2 sans spécialisation ne fournit que deux relations : la cardinalité partielle de Employe est alors implémentée en autorisant le null pour la clé étrangère, soit le noVignette de la table Employe. La contrainte totale (c) du côté de la classe CamionLivraison ne peut être vérifiée que par un trigger chargé d’ajouter le noVignette dans le tuple d’un employé au moment même de l’ajout d’une instance de CamionLivraison dans la base. Avec ce deuxième modèle la recherche des employés conducteurs est nécessaire et doit se faire avec la clé de Employe afin de trouver un tuple dont la clé étrangère est non null.

MRD-1 : Employe (nas*, nom) /*représentant tous les employés */ Conducteur (nas*, noPermis, noVignette) /*les employés conducteurs */ CamionLivraison (noVignette*, categorie)

MRD-2 : Employe (nas*, nom, noPermis, noVignette) -- tous les employés CamionLivraison (noVignette*, categorie)

Employe nas* nom

Conducteur noPermis

p

CamionLivraison noVignette* categorie

1..1 1..*

Transformation préalable du MCD en introduisant une spécialisation

Conduire



156

6.6 Transposition de l’association récursive Une association récursive peut être transformée pour avoir une meilleure lisibilité du modèle et souvent pour faciliter la spécification relationnelle.

Figure 6.19 La transformation de la réflexive est une spécialisation (t, e) qui fait apparaître les classes de rôle sous-tendues par cette association. La spécialisation est totale parce que la participation de la récursive est totale. Il y a héritage et, s’il y a lieu, renommage des attributs. L’association (1-n) Gere est intégrée dans une relation du modèle. À noter que dans cet exemple, il n'y a pas de clé primaire propre pour les sous-classes du MCD. Chacune hérite de la clé de la superclasse renommée pour tenir compte du contexte. Les attributs renommés partagent cependant le même domaine.

Gerant (matriculeG*, nomG, debutGerance) Ouvrier (matriculeO*, nomO, atelier, matriculeG)

Employe matricule* nom atelier debutGerance

1..11..*

rôle de chef rôle d'employé

Gere

Ouvrier atelier

Gerant debutGerance

t,d

Gere 1..1 1..*

<<Employe>> matricule* nom



157

Si, au contraire, l'association récursive avait une cardinalité (n-m), alors le traitement fournirait une troisième relation, soit Gere du MRD ci-dessous : Figure 6.20 Une telle transposition est valide que pour un niveau hiérarchique. Un chef gère des employés, mais il serait difficile de modéliser les employés qu’un employé gère au deuxième niveau.

6.7 Héritage des associations par la spécialisation Les associations avec la superclasse sont aussi l’objet d’une spécialisation avec les sous-classes avec au besoin, un renommage approprié pour ces nouvelles associations.

Figure 6.21 Ainsi, l'association Traite de la superclasse Patient peut être transformée par spécialisation en deux associations : la première avec la sous-classe PatientExterne que l'on peut nommer TraiteExterne et l'autre héritée par la sous-classe PatientInterne, est nommée TraiteInterne.

Figure 6.22

Ouvrier (matriculeO*, nomO, atelier) Gerant (matriculeG*, nomG, debutGerance) Gere (matriculeO*, matriculeG*)

PatienExterne prochaineVisite

PatientInterne dateSortie

c,e

Patient noP* dateIn*

Md noMd* nomMd 1..1 1..*

Chambre noCh* telCh nbLit

1..1 0..* Loge

Traite

Patient noP* date-in*

Md noMd* nomMd

1..* PatientExterne prochaineVisite

PatientInterne dateSortie

c,d

1..1

Chambre noCh* telCh nbLit

1..1 0..*

TraiteInterne

TraiteExterne

Loge

1..1

1..*



158

Le modèle, transformé par la spécialisation de l'association Traite aura une association en plus, mais chacune est particularisée par des attributs pertinents à chaque type de patients. Par exemple, le traitement d'un patient externe oblige le médecin traitant à rédiger à chaque traitement un rapport mentionnant la date de la prochaine visite qui est remis à la personne. Le modèle relationnel (MRD) correspondant est le suivant :

Les classes et l'association agrégées sont modélisées en relationnel comme si elles étaient autonomes.

6.8 Traitement de la classe faible (ou subordonnée) d’un modèle E/A La particularité de la classe faible est sa dépendance par rapport à la suppression d’une instance de la classe forte dominante, soit ici Employe : la suppression d’un employé entraîne la suppression automatique de ses enfants. On a vu qu’il est possible de traiter une classe faible et la transformer en classe régulière par l’ajout de la clé de la classe dominante.

Figure 6.23 C’est en quelque sorte une association obligatoire : ainsi un employé qui a la charge d’un enfant conserve cette charge tant qu’il est représenté dans la BD. Si cet employé est supprimé de la BD, les enfants dont il a la charge le seront aussi. Le traitement consiste donc à transformer l'association en une autre de type forte en remplaçant le discriminant de la classe faible par une clé formée du discriminant concaténé avec la clé de la classe dominante. Dans l’exemple ci-dessus, le résultat de cette transformation génère une classe forte Enfant dont la clé composée est {nas, prenom}.

Figure 6.24b

L’attribut nas de la Classe Enfant est à la fois un attribut primaire et une clé étrangère. La clé étrangère de la classe Enfant permet de définir la contrainte référentielle de manière à ce qu'un enfant ne soit inscrit dans la table que si l'employé qui en a la charge l'est aussi.

6.9 Traitement de la catégorie La catégorie UsineAgreee de la figure 6.25 a plusieurs superclasses et elle hérite sélectivement des attributs des superclasses.

PatientExterne (noP*, dateIn*, prochaineVisite, noMd) PatientInterne (noP*, dateIn*, dateSortie, noMd, noCh) Md (noMd*, nomMd) Chambre (noCh*, telCh, nbLit)

Employe (nas*, nom, adresse) Enfant (nas*, prenom*, dNaiss, sexe)

ACharge

Employe nas* nom adresse

Enfant Prenom dNaiss (d) sexe discriminant

(0,n) (1,1)



159

Figure 6.25

Comme toutes les instances de UsineAgreee n'ont pas la même structure et doivent cohabiter dans la même classe, la catégorie n'a donc pas une clé unique pour distinguer ses instances, car la clé qui est héritée varie selon la superclasse source. Dans le modèle relationnel, une relation doit avoir une clé déclarée qui ne peut pas être nulle et qui a le même libellé et le même type pour tous les tuples de la relation. Ces conditions ne sont pas vérifiées par toutes les instances de UsineAgreee, car la clé que cette dernière hérite n’a pas nécessairement le même nom et le même type. Comme cette condition ne peut pas être remplie pour toutes les instances d'une catégorie totale ou partielle, le passage au MRD se fait en créant, de toute pièce, un identifiant qui joue le rôle de la clé artificielle (surrogate key). Dans de la figure 6.25, le nouvel attribut noUsine jouera ce rôle d'identifiant pour la relation qui modélisera la catégorie.

Figure 6.25a Le passage de la catégorie au MRD génère quatre relations dérivées des trois superclasses, chacune étant aussi enrichie d'une clé étrangère formée par le nouvel identifiant (noUsine) créé pour la sous-classe UsineAgreee. Les attributs de la sous-classe sont ceux de l'identifiant et les attributs propres à la première. Le nouvel identifiant de la catégorie UsineAgreee est une clé étrangère active dans chaque superclasse. Dans le cas d’une catégorie qui partagerait la même clé (libellé et type) avec les superclasses, aucun identifiant externe au système d’information ne serait alors nécessaire, évitant ainsi l’insertion de nouveaux attributs. Il est aussi possible de représenter cette catégorie par une seule relation dans laquelle il y aura plusieurs indicateurs null et à laquelle il faudra ajouter un nouvel attribut sorte pour identifier la sorte d'usine représentée par chacun des tuples. Cette relation unique devient cependant une source potentielle de nulls.

UsineNationale (noNat*, noUsine) UsineMulti (noInter*, noUsine) UsineLocale (noLoc*, noUsine) UsineAgreee (noUsine*, chef, volProd)

UsineAgreee (noUsine*,sorte, chef, volProd, noLoc, noInter, noNat)

UsineNationale noNat*

UsineInternationale noInter*

UsineLocale noLoc*

∪

UsineAgreee chef volProd

t Catégorie totale



160

6.10 Traitement de l’agrégation L’agrégation faible est une association sans nom. Elle peut être traitée comme une association. S’il le faut, un nom lui peut être attribué ce qui permet de traiter le cas d’une agrégation dont la multiplicité est 1..* ou 0..* de part et d’autre. Dans l’exemple de l’hypothèque légale des bâtiments, la multiplicité de la première agrégation représente la signature d’un acte d’emprunt par plusieurs personnes.. Elle a aussi été nommée « SigneePar ». La deuxième agrégation représente l’objet hypothéqué soit le bâtiment.

Figure 6.26 Ce qui caractérise l’agrégation, c’est le comportement de la classe agrégée lors d’une suppression. Dans l’exemple ci-dessous, l’agrégation faible sous-tend que toute suppression d’une hypotuèque légals n’entraîne pas obligatoirement celle ni des personnes signataires, ni du bâtiment concerné, notamment lorsque cette personne participe à la co-propriété de plusieurs bâtiments. Dans le cas d’une agrégation forte, la suppression est automatique et complète. Il y a deux sortes d’agrégation : faible et forte.

a‐ Traitement des agrégations avec couplage faible (agrégation dite de partage) L’agrégation avec Batiment est représentée par l’ajout sa clé primaire dans ProprieteLegale. HypothequeLegale (noActeLegal*) Le Batiment est représentée par une relation (table). Batiment (noBat*, valeur, taxe) L’agrégation avec Personne est une association qui est nommée SigneePar, concrétisée par une nouvelle relation formée avec les clés primaires : SigneePar (noActeLegal*, nas*) Une contrainte référentielle est formulée au moyen de la clé étrangère noActeLegal et de celle du nas. Finalement, la classe personne est représentée par la relation correspondante sans contrainte référentielle : Personne (nas*, nom, adresse)

HypotequeLegale noActeLegal *

Personnenas* nom adresse

BatimentnoBat* valeur taxe

1..*

0..* 0..1

1SigneePar

HypothequeLegale noActeLegal *

Personne nas* nom adresse

BatimentnoBat* valeur taxe

1 1..*

0..1 0..*



161

b‐ Traitement de l’agrégation avec couplage fort (la composition) Le traitement suit la même logique avec la contrainte supplémentaire que si un tuple de la table Document est supprimé les tuples associés dans la table Chapitre et Index doivent aussi l’être soit par action référentielle, soit par trigger.

Figure 6.27 La première agrégation se traduit par la création d’une clé étrangère qui ne pourra pas être nulle. La spécification de l’action référentielle SET NULL est donc exclue ; de plus l’indicateur de null est interdit pour la clé étrangère. La deuxième agrégation étant de multiplicité 1, les attributs sont intégrés dans la classe Document ; il y a interdiction de null pour les nouveaux attributs. Toute suppression d’un document supprime de facto l’index et ses chapitres.

6.11 Simplification du MRD par la règle de projection Les relations obtenues au terme de l'application des règles de passage sont finalement examinées pour supprimer celles dont le schéma est un sous-ensemble de celui d'une autre relation et dont la classe correspondante a une participation totale. Dans un tel cas, l'extension de la première peut toujours être calculée par la projection de la deuxième relation dont le schéma englobe les mêmes attributs. Exemple : (1) Employe (nas*, nom, prenom, ville, age, salaire) (2) EmployeConsultant (nas*, nom, ville) La deuxième relation peut être supprimée, car les employés qui sont des consultants peuvent être représentés par la relation Employe. La relation EmployeConsultant correspond à une sous-classe de spécialisée de Employe. Elle a donc une participation implicite totale. Tout employé consultant est aussi un employé. Le domaine des attributs est le même pour tout attribut ayant le même libellé. Par conséquent, une simple projection de la classe Employe fournit la deuxième table.

Dénormalisation des tables Le modèle relationnel obtenu par ces transpositions est généralement acceptable, mais dans bien des cas il peut être encore amélioré au regard des critères de performance d’accès aux données. La théorie de la normalisation relationnelle viendra affiner le MRD fourni par les transformations appliquées au modèle E/A en éliminant la redondance et surtout en évitant certaines anomalies

1..* 1

Document ISBN* titre

Chapitre noChapitre* police format

Index nbEntrees styleIndex

1 1

Document(ISBN*, titre, nbEntrees, styleIndex) Chapitre(noChapitre*, police, format, ISBN)



162

qui risqueraient d’apparaître lors de l’exploitation ultérieure de la base de données. D’autre part, des impératifs de performance pour un contexte de traitement particulier peuvent conduire subséquemment à une dénormalisation des tables. Cette opération sur les schémas introduit une certaine redondance qu’il faudra contrôler de préférence au moyen des déclencheurs internes du SGBD (les triggers du logiciel SGBD). La dénormalisation se justifie principalement par la simplification du schéma relationnel, concrétisée par la diminution du nombre de tables dans la base. Elle doit faciliter l’accès aux données en introduisant une certaine redondance des données et en évitant des jointures aux applications. Ce processus de normalisation introduit certaines anomalies dans le schéma et doit être mis en balance avec les avantages qu’elle procure au plan de l’exploitation des données.

Exercices résolus Le MCD ci-dessous modélise la chaîne de production d'unités de visiophone. Elle est composée de plusieurs postes de travail : Planification, Chargement, Assemblage et Testing.

MCD E/A de la chaîne de montage des visiophones La planification de la production est faite par le chef de chaîne qui charge les données dans une table nommée Commande et dont le schéma est fait des attributs suivants : numéro de lot (unique), date de production du lot, modèle, quantité à produire, nom du chef et couleur des postes du lot. Les autres attributs du modèle sont ceux renseignés par l’une ou l’autre des interfaces des stations de travail de la chaîne de production. Ils sont affichés à l’écran du poste de travail visé. Les éléments d’interface sont les boutons et les alarmes (avertissement affiché) et ne correspondent pas à des attributs du modèle conceptuel, mais ils sont utilisés essentiellement comme éléments d'interactivité avec le système. Il ne s’agit pas de modéliser le fonctionnement physique de la

UniteVisiophone noSerie*

0..* 1..1

LotPlanifie numeroLot* dateProd qteCom qteChargee chef

Modele noModele*

UniteAssemblee codeAss chefAss inspecteur

UniteTestee voltageBornes volDecibel codeFonction luminosite codeTest testeur

c, o

CodeFonction code*

A_Un

Inclut

1..1

1..*

1..*

1..*

Implemente

0..*

1..1

Comprend couleur



163

chaîne (i.e. son aspect dynamique et temporel), mais sa production, c'est-à-dire les données produites par chaque poste de travail et l'information associée à ces visiophones. Une fois l'unité de visiophone acceptée à l'assemblage, elle fait partie de l'inventaire, soit comme une unité vérifiée, soit comme une unité mise de côté en raison des normes de qualité imposées. Réponse : Le MRD est obtenu par une application successive des règles de transposition pour les associations et les classes du MCD avec suppression de la redondance. La première version du MRD obtenu est redondante, car certaines relations peuvent être obtenues par projection d'une autre relation plus riche en attributs. LotPlanifie(numeroLot, noModele, dateProd, qteCom, qteChargee, couleur, chef) Modèle (noModele) <-- peut être obtenue par projection de (3) ModeleCodeFonction (noModele*, code*) (3) CodeFonction (code*) <-- peut être obtenue par projection de(3) UniteTestee (noSerie, noModele, voltageBornes, volDecibel, codeFonction, luminosite, codeTest, testeur) UniteAssemblee(noSerie, noModele, codeAss, chefAss, inspecteur) Simplification du MRD par la projection Le modèle logique relationnel intermédiaire obtenu comporte des relations redondantes et peut être simplifié. Par exemple, la relation Modele est redondante parce que la projection de la relation ModeleCodeFonction sur l'attribut noModele donne la même extension. Il en est de même pour la relation CodeFonction. Cependant, la projection de la relation Lot-Planifie sur l'attribut noModele ne donne par la même extension, car certains modèles peuvent ne pas avoir encore été mis en production. Ceci correspond à la sémantique sous-jacente à la contrainte de participation partielle. En supprimant la redondance, quelques clés étrangères disparaissent du modèle logique et les relations résiduelles peuvent être, par commodité, renommées dans le modèle. Le modèle logique relationnel résultant est le suivant : C’est à ce stade, et selon les besoins des applications, qu’une dénormalisation peut être faite en introduisant à nouveau des attributs redondants dont la validité sera obligatoirement contrôlée par un déclencheur(trigger) (Contrôle des numeroLot et dateProd). Notez aussi la présence de la même clé pour les relations Test et Tas. A la limite, si la performance n'entrait pas en compte, ces deux relations pourraient être fusionnées. La dénormalisation d’un modèle peut éviter le calcul de jointures, mais il augmente le travail de contrôle à faire pour éviter les anomalies que la normalisation bloquait par la structure même du modèle. Lors d’une dénormalisation, ce rempart structural contre les anomalies disparaît, et il

LotPlanifie (numeroLot,noModele, dateProd, qteCom, qteChargee, couleur, chef) ModeleCodeFonction (noModele*, code*) UniteTestee (noSerie, noModele, voltageBornes, volDecibel, codeFonction, luminosite, codeTest, testeur) UniteAssemblee (noSerie, noModele, codeAss, chefAss, inspecteur)



164

faudra compenser par le travail d’un ou plusieurs triggers qui verront à éviter l’insertion des anomalies de suppression et de mise à jour. 2- Voici un MCD qu’il faut transformer en MRD au moyen des règles de passage. Les nulls sont tolérés pour les tables, tandis que la redondance des données doit être minimale.

Réponse : La clé de la classe de la table Piece est l’objet d’un héritage par les deux sous-classes. Elle devient la clé de chaque sous classe qui n'en possède pas dans le modèle conceptuel. La clé héritée peut être renommée pour en faciliter l'interprétation. Le numéro de moule et le métal pourraient être éventuellement des clés candidates, mais rien dans le MCD ne le précise clairement.

Piece (noPiece*, poids, cat) PiecePlastique ( noPiece*, noMoule, polymere%) PieceMetal (noPiece*, noMetal, carbone%, noFourn) Fournisseur (noFourn*,nomFourn, ville) Mouler (noPiece*, noFourn*, prix

Sommaire Le passage du MCD au modèle relationnel est relativement simple. Il existe plusieurs outils de modélisation qui assistent le concepteur de BD et qui génèrent automatiquement le schéma du modèle relationnel logique. L’association de type généralisation/spécialisation peut aussi être traitée sans difficulté au même titre que les autres associations du modèle. Ce mécanisme de modélisation est implémenté directement dans les systèmes orientés objets. La redondance apparente introduite par la transformation du MCD en MRD ne concerne que les clés primaire et étrangère. Normalement, la redondance est contrôlée par le SGBD relationnel à l'aide des

Piece noPiece* poids cat

PiecePlastique noMoule polymere%

PieceMetal noMetal carbone%

i,d

Fournisseur noFourn* nomFourn ville

1..11..*

1..*1..*

Usiner Mouler prix



165

déclencheurs (triggers) ou par des procédures internes stockées dans la base de données. Toute modification aux données d’une relation est vérifiée et n’est acceptée que si les contraintes définies sur les clés sont aussi respectées. La cohérence de la base est ainsi renforcée en partie par la nature même des relations. Ces règles de passage confirment le rôle général du MCD lequel est indépendant de toute plate-forme et favorise les reconversions incontournables de la BD pour des environnements qui évoluent rapidement. Exercices Voici un MCD dans lequel les contraintes de multiplicité sont absentes. 1.1- Formulez les contraintes de ce MCD au regarde de la sémantique suivante: Une usine approvisionne un projet avec des matériaux. Un projet reçoit les matériaux d’une Usine, mais aussi de d’autres sources. La direction d’une usine peut aussi gérer un projet, mais ne peut pas en même temps fournir les matériaux pour ce projet. 1.2- Transformez le MCD ci-dessous en un modèle relationnel et précisez ses contraintes au regard du MRD obtenu. 2- Le modèle ci-dessous représente la structure d'une base comportant deux spécialisations distinctes.

Citoyen nas* nom

Ouvrier metier

Electeur noElecteur arrondissement

i c

Usine noUs* villeUs

Projet noProjet* site echeance

Gere Fournir



166

2.1- Transformez ce MCD en MRD et précisez les contraintes de clé primaire et référentielle. 2.2- Donnez le SQL-DDL pour implémenter ces deux tables. 2.3- Formulez une contrainte dans ce modèle qui ne peut pas être vérifiée autrement que par un trigger. 3- Modifiez le MCD de l’exercice 2 pour représenter les différents métiers qu’un ouvrier peut pratiquer, et cela sans ajouter une classe ou une association. 4- Voici le modèle relationnel JMC (JoueurMatchCommanditaire) que nous avons utilisé précédemment. BD JMC:

Joueur (nom*, prenom, age, nationalite, societe) Match (dateM*, lieu*, score, nomG, nomP) Commanditaire (societe*, montant, duree)

Un match du tournoi des maîtres est identifié par la rencontre, à une date déterminée, de deux joueurs dont l'un est obligatoirement gagnant. La commandite est toujours associée au joueur et non au match. Une commandite peut ne pas être encore accordée. Les attributs nom, nomG (nom du gagnant) et nomP (nom du perdant) partagent le même domaine sémantique. Les clés de chaque relation sont identifiées par les astérisques et sous-tendent les seules DF du modèle. Pour les fins de cet exercice, la date du match ne comprend que l'année sous forme d'une chaîne de caractères. Certains joueurs peuvent ne pas avoir joué un match. Cependant, tous les joueurs sont commandités et doivent l'être pour être présents dans la base de données. 4.1- Par rétro-ingénierie, représenter le MCD du modèle relationnel JMC. Pour y arriver, il vous faut faire appel à l'abstraction de spécialisation et à ses propriétés de couverture. Validez la transposition de votre modèle conceptuel en vérifiant qu’elle fournit bien les relations du MRD ci-dessus. 4.2- Donnez un autre modèle MCD équivalent au précédent et qui comporte une association réflexive et au besoin de nouvelles associations sans cependant créer de nouvelles Entités. 4.3- Formulez les dépendances fonctionnelles de chaque relation et déterminez leur plus grande forme normale. 5- Voici un MCD composé d’une seule association ternaire.

5.1 Formulez en français les contraintes de ce MCD. 5.2 Transposez ce MCD en MRD.

Ingenieur matricule*

Site noSite* Chantier

noChantier* 1..1

1..1

1..* Travaille



167

5.3- Identifiez et formulez les deux dépendances fonctionnelles valides dans ce MRD. 5.4 Donnez une extension de la BD avec suffisamment de tuples pour illustrer la validation des dépendances fonctionnelles formulées. 5.5- Donnez le code SQL-DDL pour créer cette base de données et pour implémenter les contraintes observées. 6. Le MCD BATPUB ci-dessous modélise certains activités concernant la vente de bâtiments appartenant à des organismes publics ou privés. Certains immeubles peuvent être offerts au public au moyen d’un avis fait dans un grand journal. Les vendeurs-propriétaires privés sont cependant tenus de déposer un montant de caution au journal lors de la publication d’un avis de vente. Les propriétaires-publics ne le sont pas lors de la publication d’un tel avis. Le MCD BATPUB est le suivant :

6.1 De par ce modèle, lorsqu’une université désire disposer d’un bâtiment, peut-elle le vendre à un autre organisme public sans le publier dans un journal? Expliquez votre réponse en vous basant sur MCD.

BatimentAVendre noB* adrB prixB

Proprio nomP* adrP statut

ProprioPrive nas* age

ProprioPublic noTaxe* gestionnaire villeSS

Journal nomJ* catJ

c,d

1..*

0..*

0..*

1..1

1..*

0..*

Universite noU* recteur campus noReg

p

Appartient

Annonce dateFin

Depose montant



168

6.2 Expliquez en vous référant à la sémantique du MCD, si le recteur d’une université est obligatoirement aussi un gestionnaire d’un organisme public. 6.3 Complétez le passage du MCD BATPUB au MRD ci-dessous :

BatimentAVendre (noB*, adrB, prixB, nomP) ProprioPublic (nomP*, adrP, statut, noTaxe, gestionnaire, villeSS) Journal ( nomJ*, catJ) Annonce (noB*, nomJ*, dateFin)

7- Voici le même MCD dont une contrainte structurelle a été légèrement modifiée.

7.1 Formulez en français les contraintes structurelles de ce MCD. 7.2 Transposez ce MCD en MRD en appliquant les règles de passage. 7.3- Formulez l’unique dépendance fonctionnelle valide dans ce MRD. 7.4 Donnez une extension de la base de données avec suffisamment de tuples pour illustrer la validation des DF formulées. 7.5- Donnez le code SQL-DDL pour créer cette base de données et implémentez les contraintes observées.

Ingenieur matricule*

Site noSite* Chantier

noChantier*

1..*

1..1 1..* Travaille



169

INDEX

:

:new, 37 :old, 37

A

Algorithme de .i.jointure, 81 Algorithme de projection, 66 algorithmes de normalisation, 45 ALTER TABLE, 24 appariement, 22 Arbre dʹune requête complexe, 79 assertion, 34 association binaire 1‐n, 147 association quaternaire, 149 association récursive, 156 Attributs de groupement, 104 attributs multivaleurs, 142 attributs non primaires, 12 attributs primaires, 15 Augmentation, 53

B

boucles imbriquées, 80

C

calcul de la jointure, 80 Caractérisation des systèmes relationnels,

115 Cardinalité de la jointure, 84 Cardinalité de la projection, 65 catégorie, 158 classe d’association, 6 classe d’entités faibles (ou partiellement

associées), 158 Clé candidate, 15 Clé de relation, 14 Clé étrangère, 15 COMMIT, 35 Confidentialité, 30 Contrainte d’entité, 19 Contrainte d’unicité, 19 contrainte dans une transaction, 34, 35

Contrainte de clé, 19 Contrainte de clé candidate, 19 Contrainte de tuple, 32 Contrainte logique, 31 Contrainte référentielle, 21 Contrainte référentielle en chaîne, 31 CREATE ASSERTION, 34 CREATE DOMAIN, 9

D

déclencheur, 40 Déclencheur (Trigger), 37 Dépendance fonctionnelle, 12 Dépendance fonctionnelle totale, 13 Dépendance fonctionnelle triviale, 13 dépendance triviale, 13 dépendances triviales, 53 Désactivation des contraintes de clé, 24 déterminant, 13 déterminé, 13 Deuxième forme normale, 47 Différence, 89 Différence en SQL, 90 Division relationnelle, 91 domaine syntaxique, 9 Domaine syntaxique, 9 Domaines

sémantique, 8

E

équijointure, 78 Exercices, 56, 135, 165 Exercices résolus, 131, 162 extension, 7

F

fermeture transitive, 54 FN1, 45 FN2, 47 FN3, 49 FN4, 52 FN5, 52 FNBC, 51 FNC, 73



170

Fonctions arithmétiques, 102 fonctions d’agrégation, 111 Fonctions d’agrégation, 104 Fonctions de chaîne, 103 Fonctions de l’algèbre+, 102 Forme Normale Conjonctive, 73 Formes normales supérieures, 52

G

groupement dans une vue, 123

H

hashing, 81 Héritage des associations, 157

I

IMMEDIATE, 35 Implémentation de lʹintersection, 91 Indépendance des contraintes, 117 Indépendance logique, 117 intersection, 88 Intersection en SQL, 90

J

jointure, 81 Jointure de relations, 78 Jointure externe, 95 Jointure externe droite, 96 Jointure naturelle, 78 Jointure par hashing avec deux dispersions,

81 jointure thêta, 78 Jointure thêta, 79

L

Lʹarbre de requête est le suivant:, 113 LIKE, 101

M

MINUS, 89 Mise à jour, 117 Modèle logique, 11 modèle relationnel, 4, 18 Modification dʹune vue, 120

O

ON DELETE SET NULL, 24 Opérateurs relationnels et le typage, 62

P

Perte de mise à jour, 128 prédicat de sélection, 69 Première forme normale, 45 Procédure algébrique, 74 Produit cartésien, 85 Pseudo‐transitivité, 53

R

Réflexivité, 53 Règles dʹinférence, 53 relation, 4 Relation de base, 11 Relation en FNBC, 51 relations de base, 18 renommage des attributs, 151 requête réflexive, 98 ROWID, 18

S

Schéma logique, 11 Sélection, 67 Sélection en SQL, 67 Sélectivité de la sélection, 72 sémantique, 8 SET IMMEDIATE, 35 SET TRANSACTION, 35 Simplification du MRD, 161 SQL, 62 Substitution dans une vue, 129 superclé, 15 Superclé dʹune relation de base, 15 Suppression, 114

T

table en mutation, 43 Table en mutation, 41 table enfant, 29 table parent, 26 Table sous contrainte, 42 Tables en mutation, 40 temporisation dʹune contrainte, 34



171

Traitement de la généralisation, 150 Traitement du MCD, 141 transaction implicite, 35 Transitivité, 53 Transposition de lʹassociation, 144 Transposition de lʹassociation binaire N‐M,

148 Trigger, 40 Troisième forme normale, 49

U

un identifiant, 48 Union, 88 Union en SQL, 88

V

Valeur non nulle, 30 Valeur nulle, 130 validation des contraintes, 32 vue formulée avec une jointure, 124 vue relationnelle, 130

Références chapitre 4 1 CODD, E. F., A Relational Model of Data for Large Shared Data Banks, Communications of ACM, v.13, no 6, 1970, 337-387. 2 BERNSTEIN, P. A., Synthesizing Third Normal Form Relations FROM Functional Dependencies , ACM Transaction on Database Systems, vol. 1, no 4, 1976, p. 277-298. 3 SMITH, H., Database Design : Composing Fully Normalized Tables from a Rigorous Dependency Diagram, Communications of the ACM, 28, 8, 1985, p. 826-838. 4 Le SQL est déclaratif parce qu’il n’exige pas de l’utilisateur une connaissance de l’implémentation des opérateurs et des tables ou des chemins d’accès pour une formulation de la requête qui doit qualifier les tuples qui doivent être inclus dans la réponse ainsi que des conditions à vérifier par ces tuples. Références chapitre 5 5 CODD, E. F., The Relational Model for Database Management, version 2, Addison‐Wesley, 1990. 6 GOTLIEB, R. L., Computing Joins of Relations, in Proceedings of the ACM SIGMOD International Conference on the Management of Data, 1975, p. 55‐63. 7 BUFF, H. W., The View Update Problem Is Undecidable, published as Why Coddʹs Rule No.6 must Be reformulated, ACM SIGMD Record 17: 4, 1988. Références chapitre 6 8 JAJODIA, S., NG P., Translation of Entity‐Relationship Diagrams into Relational Structures, Journal Systems and Software, vol. 4, no 2‐3, 1984, p. 123‐133. 9 TEOREY, T. J., YANG, D., FRY, J. P., A Logical Design Methodology for Relational Databases Using Extended E/A Model, ACM Computer Surveys, vol. 18, no 2, 1986, p. 197‐222. 10 TEOREY, Toby, Database Modeling and Design, Morgan Kaufmann, 1999, ISBN 1‐55860‐500‐2.



172

Fascicule 2 Modèle relationnel, algèbre relationnelle et ...

Documents

Transcript of Fascicule 2 Modèle relationnel, algèbre relationnelle et ...