Architectures, modèles et langages de donnéesagamache/pageperso/LivreBDPDF/Chapitre123.pdf · et répond aux requêtes de service en provenance de clients répartis en différents

© 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]

Volume I

Hypercube

Ingénierie des bases de données

OLAP

c,d

André Gamache 2005

Architectures, modèles et langages de données

Fascicule 1

Architecture fonctionnelle du logiciel SGBD et diagramme de classe UML


2

Architectures, Modèles et Langages de Données

Volume 1 Fascicule 1

1- Introduction 1 2- Architecture fonctionnelle du SGBD 21 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 FN1 à FN5 45 11- Optimisation des requêtes relationnelles 117 Annexes :

A- SQLoader B- Projet ALU-Nord : Script de chargement

INDEX


3


4

Chapitre 1 Introduction générale à l’exploitation des données

Introduction Le domaine des bases de données est maintenant quasi un lieu commun pour une vaste clientèle des systèmes informatiques, allant de l’utilisateur occasionnel de la micro‐informatique au spécialiste chargé par les organisations de concevoir, de mettre en oeuvre et de gérer les grands systèmes de gestion de données qui sont essentiels à leurs activités. Les bases de données sont désormais un élément incontournable de tout système de traitement de lʹinformation qui se doit dʹêtre performant et évolutif. La terminologie du domaine des bases de données est parfois ambiguë et polysémique, surtout si elle est prise hors contexte. Nous commencerons donc par présenter quelques concepts clés du domaine avec un certain niveau de généralité parce quʹune seule définition ne peut pas rendre compte facilement de toute la complexité et des nuances qui prévalent dans différents contextes technologiques.

1.1 Base de données Une base de données (BD) est un ensemble de structures créées à l’image d’un modèle de données et gérées pour stocker des informations (représentées par les données) dans le but dʹeffectuer subséquemment des recherches et des mises à jour. Cʹest en quelque sorte la représentation structurée et codée de lʹinterprétation (par le concepteur) dʹune réalité organisationnelle qui est en constante évolution dans le temps. La base de données peut être centralisée ou répartie (distributed) et elle est accessible aux concepteurs dʹapplications et à leurs utilisateurs par lʹintermédiaire dʹune gamme de moyens informatiques soit du simple terminal à la station de travail, et cela pour manipuler les objets ou les structures les plus simples jusquʹaux objets graphiques implémentés avec des structures de données beaucoup plus complexes.

Logiciel de gestion de base de données (SGBD) Le logiciel SGBD est un ensemble de procédures partagées par tous les utilisateurs pour la création et la manipulation des données (1) avec une garantie de cohérence, de consistance dans les opérations et de persistance des ajouts ou des modifications transactionnelles. Les procédures du moteur SGBD coopèrent pour exploiter et gérer les structures de données complexes qui utilisent le chaînage, l’adressage calculé (Hashing), le B‐arbre et le regroupement (clustering) des données, à la fois pour le stockage et la recherche.

Conception dʹune base de données La conception dʹune base de données sʹinscrit dans l’ensemble des opérations d’analyse informatique concernant la définition des données, des types (structures) et des associations entre les données et la spécification des contraintes. Pour effectuer ce travail, les concepteurs utilisent une méthodologie dʹanalyse qui peut privilégier soit une approche globale de l’organisation, soit une autre qui exige lʹintégration des données exploitées pas les applications existantes. Une fois la conception terminée, il faut dresser en quelque sorte les plans et les devis des traitements et des données qui sont notamment représentés sous forme de modèles

Chapitre 2 Architecture fonctionnelle du SGBD


2

documentés avec le diagramme de flux de données (DFD), le modèle conceptuel de données (MCD) et le modèle logique de données (MLD) qui deviendra celui de lʹimplantation. Ces documents de base sont essentiels aux concepteurs pour favoriser une bonne communication avec les utilisateurs et donner au système cible le niveau de maintenabilité exigé par tout système complexe qui doit évoluer en fonction des besoins de l’organisation. Ils permettent aussi d’expliciter et de délimiter le rôle et les fonctions du système de gestion des données et de conscientiser les concepteurs et les utilisateurs quant aux limites de celui‐ci. De nos jours, la modélisation tend à incorporer une vision plus dynamique des données en y incluant les traitements et les événements qui en sont les déclencheurs. Ces activités sont représentées par un modèle de traitement et par un autre dit transactionnel.

1.2 Rôle central du SGBD Le logiciel SGBD doit fournir un environnement riche et efficace pour stocker, retrouver et modifier les données dans une base tout en respectant leurs propriétés structurales ainsi que les contraintes de sécurité qui sʹimposent dans un contexte multiposte où le partage des données et l’accès à celles‐ci sont des privilèges accordés aux utilisateurs dʹaprès leurs fonctions dans lʹorganisation. Le logiciel est en exécution sur une machine serveur ou sur une machine centrale et répond aux requêtes de service en provenance de clients répartis en différents endroits et reliés par lʹentremise dʹun réseau. La communication entre le client et le serveur est assurée par le logiciel qui implémente la couche transport TCP/IP de Ethernet.

Architecture client‐serveur Figure 1.1

En dʹautres termes, le logiciel SGBD se comporte comme un logiciel serveur sur la machine attendant des requêtes des clients sur un port particulier pour ensuite déclencher le calcul de la réponse à partir des données de la base. Les structures de données de la base sont très riches (listes, B‐arbres, adressage calculé, fichier Heap etc.). La structuration détaillée des données devient rapidement impossible à saisir tant la structure est complexe. Il a fallu inventer une représentation générique de ces structures de données pour masquer leur complexité, tout en offrant aux utilisateurs une vision simple leur permettant de représenter les données et leurs associations pour pouvoir par la suite les exploiter efficacement. Le rôle de l’application client est de traiter localement les données obtenues selon une logique propre à chaque application et d’en afficher les résultats en faisant appel à un sous‐système de gestion de fenêtres.

Importance du volume des bases de données

TCP

-IP

Application TCP-IP

SGBD Utilisateur

Côté serveur Côté Client

BD



3

La nécessité de gérer efficacement de plus grands ensembles et de nouveaux types de données s’impose principalement en raison de l’importance croissante des données dans les processus décisionnels. Ce volume de données exorbitant entraîne son lot de problèmes. Il y a déjà longtemps, T. Tomita (2), estimait quʹen 1960 le volume de lʹinformation publique transmise par les journaux était de 0,66 x 1020 bits et quʹil triplerait en 1972. Sa prévision faite à lʹaube de lʹère informatique nous apparaît maintenant bien en dessous de la réalité. La croissance du volume des données se fait sentir particulièrement dans les pays industrialisés où le fonctionnement et la gestion sont tributaires dʹun accès sûr et universel aux données de lʹorganisation (3). Le mot d’ordre dans le fonctionnement des organisations est de fournir directement les données nécessaires aux utilisateurs afin de rapprocher la décision de l’action. Cʹest dʹailleurs la base du concept de lʹentrepôt de données (data warehouse) qui constitue un immense réservoir de données cumulées dont l’exploitation fine permet d’extraire de nouvelles informations au moyen d’outils d’analyse et de synthèse (data mining). La généralisation des accès à lʹInternet et la mise en place de bibliothèques électroniques (digital library) accessibles de par le monde sous‐tendent leur gestion à partir des supports informatiques. La capacité des disques et la vitesse de transmission des données ont atteint des niveaux que lʹon pouvait difficilement prévoir il y a dix ans. Le volume des données est devenu très important. Il suffit de songer à la taille de la base de données nécessaire pour gérer les données de type multimédia acheminées sur l’inforoute de l’Internet. Combien de millions dʹoctets faut‐il pour stocker 60 secondes de son ou une séquence vidéo de deux minutes ? Quel espace faut‐il pour stocker un catalogue de pièces mécaniques pour l’industrie de l’automobile? Quelle est la valeur utilitaire de cette masse de données ? Quels sont les mécanismes d’accès les plus appropriés pour retrouver ces données ? Comment découvrir un ensemble de pièces musicales sur la base de leur contenu? Des centaines voire des millions de mégas octets sont nécessaires pour stocker ces nouvelles informations gérées par ordinateur. Ces quelques faits révèlent lʹimportance du volume des données et laissent entrevoir le rôle des bases de données avec leur environnement technologique pour stocker ces données complexes et en permettre subséquemment le rappel et l’affichage. Sans un logiciel spécialisé, des disques rapides RAID et un processeur de grande puissance, l’accès à une base de données de grande taille ayant des objets de types très divers peut devenir un cauchemar pour qui en est le gestionnaire. Déjà les besoins se faisaient sentir dans les années 80 lorsque le développement économique se profilait au développement du secteur des services et à l’informatisation des moyens de production. En 1979, Williams (4) publia une courbe de croissance des bases de données textuelles, qui laissait voir un rythme qui doublait sur une période de quatre ans. A titre dʹexemple, considérons la croissance estimée du volume des données par Williams4, Bien que la réalité des années 2000 rende ces données largement caduques, elles ont le méritent dʹillustrer la croissance des données depuis la première phase du cycle d’informatisation des organisations.

Description 1975 1977 1979 Nombre de bases de données textuelles (USA) 177 208 259 Nombre d’enregistrements (en millions) 46 58 94 Nombre base de données (autres pays développés) 124 154 269 Nombre d’enregistrements (en millions) 301 362 528



4

Figure 1.2 Ces repères de plusieurs années permettent dʹapprécier les volumes importants de données à stocker et ultérieurement à recouvrer, ce qui ne peut pas se faire sans une augmentation de la puissance des machines, de la capacité de stockage des systèmes et de la puissance des logiciels de gestion des bases de données. Pour terminer, plusieurs auteurs soulignent que seulement 10% des informations sont gérées par des systèmes informatiques et que inévitablement les volumes de données vont augmenter avec la généralisation de la saisie des données à la source! La charge qui sera soumise aux bases de données s’annonce colossale. Plus récemment, Lyman et Varian (5) de l’Université de Californie à Berkeley estimait que l’augmentation du volume d’information avait augmenté de 30% depuis 1999 pour atteindre en 2002 un sommet de 5,4 pecaoctets (1018 octets). Très approximativement, 40% de cette nouvelle information serait produite par les USA dont la moitié serait enregistrée sur un support permettant une lecture digitale. Pour ne pas sombrer dans la pollution ou hégémonie informationnelle aigue, de bons outils de stockage et de recherche pointue voire discriminante seront nécessaires pour répondre aux besoins du marché. Dans une enquête centrée sur les bases de données réalisée par lʹInternational Oracle User Week (IOUW) (6) auprès des DBA (Database Administrator) participant aux conférences annuelles de 1993 et 1994, il appert que la taille la plus fréquente de la base opérationnelle soit de 2,2 Go et que la moyenne se situe autour de 14 Go. En 1994, la taille moyenne est passée à 17 Go, tandis que la taille médiane de la base a augmenté de 38 % par rapport à celle de 1993. Le nombre moyen dʹutilisateurs de bases de données va aussi quadrupler dans cette seule année, pour atteindre près de 210 utilisateurs par base Oracle. Au Québec, la Régie de lʹAssurance Maladie (RAMQ) gère en ligne les trois dernières années de prestations médicales. Par exemple, pour 1993 à 1996, cela représente une base de plus de deux milliards dʹenregistrements. Le volume est tel quʹune réorganisation impliquant un rechargement est une opération lourde puisquʹil faut près de deux mois pour le réaliser et cela, avec des ordinateurs puissants dotés d’une technologie de pointe. Lʹimagination est mise au défi lorsquʹil sʹagit dʹestimer les volumes de données qui seront générés par le commerce électronique dont les spécialistes prédisent une généralisation progressive peu après lʹentrée dans le troisième millénaire! Lʹévolution des bases de données est donc marquée par lʹaugmentation prévisible des volumes de données caractérisés par une plus grande diversité des types de données, notamment pour y inclure les images et le son. Pour mieux illustrer lʹévolution des bases de données, nous les classerons en cinq groupes distincts sur la base de leur volume. Chaque catégorie a ses caractéristiques et ses logiciels de gestion. Il est aussi à prévoir que les grandes bases seront pour les prochaines années une préoccupation majeure pour les grandes organisations tant les investissements en personnel, en matériel et en logiciel seront importants.

1.3 Typologie des bases de données



5

Le classement des bases de données par leur volume donne les catégories relatives suivantes qui mettent en perspective leur importance relative dans le fonctionnement des organisations : La base de données individuelle renferme des données personnelles avec quelques milliers de données utilisant quelques centaines d’octets pour leur stockage. Tout va pour le mieux! Son exploitation est souvent locale et l’accès aux données réalisé avec une bonne performance. Il existe de bons outils sur des ordinateurs de bureau, disponibles à des prix intéressants ou à titre de logiciel libre (Open Source) et qui permettent de gérer ces ensembles de données personnelles relativement importants. Dans les années à venir, certaines de ces bases pourront être davantage individualisées et acquérir le statut de portable sur une carte à puce dotée d’un ordinateur embarqué (smart card avec flash memory) ou stockées dans des ordinateurs portables (laptop, palm computer). Ces bases portables deviendront accessibles à des agents intelligents mandatés pour propager ou collecter des données à partir de bornes Internet de données. La base de données dʹavant 1985: Une base type comprend moins de 200 000 données essentiellement numériques et nécessite près de 2 Mo de mémoire de stockage. Avec cette base, il y a des problèmes de partage de données assorti de performance que le DBA doit surveiller et résoudre. Comme ces données sont souvent jugées essentielles au fonctionnement d’une organisation, il faut un accès relativement rapide avec des outils puissants qui nécessitent un investissement moyen pour le logiciel et le matériel. Ces bases sont souvent associées à des fonctions spécialisées et vitales dʹune organisation comme par exemple lʹinventaire dʹune entreprise manufacturière, le système des ventes ou le système de facturation. La base de données après les années 1995 : La mega base de données (x106) peut comporter autour de 100 000 000 données, ce qui suppose quelques dizaines de gigas octets de stockage. À ce niveau, le volume des données, leur complexité, les problèmes de gestion des structures de stockage, de performance et d’accès apparaissent avec plus dʹacuité. Les logiciels dʹexploitation sont maintenant de type multiposte, plus coûteux et exigeants en termes de ressources informatiques: matériel, logiciel et ressources humaines spécialisées. Les problèmes d’archivage deviennent encore plus évidents et les solutions plus complexes et coûteuses. Le stockage des données multimédias apparaît comme un nouvelle exigence pour les systèmes ce qui accentue le problème de vitesse dʹaccès et dʹespace disque. Lʹinfrastructure de réseau est heureusement en place et les disques rapides de type RAID sont maintenant un atout. Le poste budgétaire de l’informatique est devenu très important pour un grand nombre d’organisations. La base de données des années 2000 : La giga (x109) voire même la térabase de données (x 1012), plus de 1 000 000 000 000 données disponibles en ligne qui occupent un espace de plus de 1 To. Les problèmes critiques sont ceux du stockage, de la performance, de lʹaffichage, de lʹarchivage et de la vitesse du réseau. Les logiciels sont encore plus coûteux et souvent spécialisés. Les disques RAID sont nécessaires, sous‐tendant souvent lʹutilisation des architectures multiprocesseurs pour avoir une performance appréciable. Les données acquièrent de plus en plus leur lettre de noblesse pour nourrir l’intelligence économique mise à jour par les logiciels de data mining. Une entreprise peut alors mieux connaître ses concurrents et d’anticiper les besoins de ses marchés. C’est le début de l’ère de l’entrepôt de données.



6

La base de données du futur: La térabase (x1012) ou l’exabase (x1018) base s’impose graduellement comme une réalité; avec autant de données, tout est ou devient problème! Quelques grandes organisations privées ou gouvernementales commencent à ressentir ces difficultés associées aux volumes de cette importance, particulièrement depuis l’avènement des documents multimédias dans les bases de données et la généralisation planétaire du courrier électronique et des documents digitaux. Pour stocker des images animées couleurs et muettes, il faudra stocker 15 Mo à la seconde! La tendance à fusionner tous les types de données entraîne alors des problèmes d’espace, de vitesse de communication sur réseau (100 Mbps) Les interfaces complexes et robustes pour stocker et surtout rechercher rapidement les données historiques des organisations (data warehouse). A ce niveau de volume, la centralisation des données n’est plus un préalable ; la répartition et l’hétérogénéité des données deviennent des alliés et non des faux amis!

catégorie volume de données (approx.) taille Débutant 5 000 Plus de 250 Ko Avant 1985 200 000 2 Mo 1995 et ... 1000 000 000 000 1 000 000 Mo Années 2000 1000 000 000 000 000 400 Go (109) BD du futur 10 000 000 000 000 000 000 4000 To (1012)

Figure 1.3 Cette plus grande disponibilité des données sʹaccompagne aussi dʹune croissance importante des coûts dʹexploitation et des investissements dans la mise en oeuvre des infrastructures. La figure 1.3 présente les différentes bases de données et leurs volumes repères. Ces chiffres sont des approximations pour illustrer lʹévolution de la taille des bases de données. La réalité risque dʹêtre plus exigeante en matière dʹespace de stockage, ainsi quʹen puissance de traitement et de vitesse des réseaux. Il est évident que les bases de données sont en pleine croissance et cela, en nombre et en volume. Les espaces de stockage et les moteurs SGBD devront être adaptés à ces nouveaux défis en offrant des disques de plus de 500 Go/disque gérés par des contrôleurs multidisques et des systèmes multiprocesseurs dotés de mémoires communes. Les systèmes dʹexploitation sont déjà prévus pour gérer ces types dʹordinateurs et intégrer davantage les fonctionnalités des réseaux. En résumé, lʹévolution rapide des besoins en matière de stockage et de traitement des données a créé des attentes qui imposent de nouvelles fonctionnalités aux SGBD et des conditions dʹexploitation beaucoup plus exigeantes : a) La transparence des données transmises aux applications : formats différents variant du type primitif au type abstrait, cette dernière structure étant nécessaire pour les documents graphiques et sonores, etc. b) La confidentialité des données : gestion de la visibilité des données, des droits d’accès et du suivi de l’usage des données pour les usagers distants utilisant une vue partielle de la base. Le chiffrement par les algorithmes spécialisés bien connus ‐ DES, RSA ou Telepass ‐ et compaction



7

des données multimédias sont maintenant des exigences courantes de la gestion des données et de leur exploitation dans les systèmes de commerce électronique. c) Le renforcement des contraintes de cohérence plus complexes définies dans le modèle de données. Par exemple, une contrainte peut être formulée ainsi : un employé ne peut pas avoir un salaire annuel supérieur à celui de la moyenne des salaires consentis aux cadres de niveau 2, ou encore un solde d’inventaire ne peut pas franchir la barre inférieure de 20 articles lorsque le carnet de commandes est rempli aux deux tiers de sa capacité. Ces contraintes seront implémentées par le SGBD et non par les applications et ce, pour garantir l’uniformité de leur implémentation. Elles sont vérifiées automatiquement par des déclencheurs ou des procédures internes à la BD afin de mieux garantir lʹintégrité des données et cela au regard des règles qui prévalent dans le fonctionnement de l’organisation. d) Lʹaccès multiposte et concurrent aux données s’impose de plus en plus avec un grand volume de transactions peu importe si l’approche est centralisée ou client‐serveur. Les grands systèmes transactionnels doivent maintenant pouvoir traiter des volumes de transactions qui dépassent le cap des 1000 transactions à la minute. L’horizon des débits de transactions de l’ordre de 2000 à la seconde est déjà perceptible! La puissance des processeurs utilisée par les serveurs et la rapidité des disques permettent de répondre à ces exigences d’exploitation. Les organisations doivent cependant y investir des sommes importantes.

1.4 Évolution des logiciels pour la gestion de données Les logiciels SGBD multitâches et parallèles présentement en service sont l’aboutissement d’une évolution technologique des logiciels pour la gestion des données dont les premières versions exploitaient essentiellement le gestionnaire de fichiers du système dʹexploitation hôte (OS‐SGF) comme par exemple, RMS (Record Management Storage) de l’ancienne société Digital Equipment Corporation et VSAM (Virtual Storage Access Method) de la société IBM. Par la suite, les logiciels SGBD ont évolué vers une plus grande autonomie par rapport au système dʹexploitation en prenant à leur charge la lecture et lʹécriture des records et des pages sur les disques, en plus de gérer les transactions et de leur recouvrement en cas de panne.

Fonctionnalités courantes du logiciel SGBD Ce logiciel spécialisé et complexe intègre donc les services de base offerts par les systèmes de gestion de fichiers et offre en sus une gamme étendue de fonctionnalités nouvelles. Parmi celles‐ci, mentionnons les suivantes : a) La description des données (appelée couramment les métadonnées) est ajoutée au dictionnaire et devient incontournable pour accéder au contenu de la base. b) Lʹindépendance des données et des applications est renforcée en reconnaissant plusieurs niveaux de métadonnées. Cette vision multiniveau permet de séparer les aspects logiques et physiques des structures de données. Ainsi, les changements de structure de la base de données nʹont plus dʹimpacts majeurs sur les applications et inversement. c) Lʹusage d’un outil de gestion de l’abstraction des données (l’usage d’un modèle de représentation générique des données et de leurs associations) permet de visualiser plus facilement la complexité des structures de données et de les spécifier par un langage de description compatible avec le logiciel SGBD. Les structures logique et physique des données



8

peuvent être alors obtenues à partir dʹun modèle de haut niveau dit conceptuel qui ne tient pas compte des particularités tributaires de l’implémentation de chaque SGBD. d) Le partage contrôlé et sécurisé des données est généralisé pour toutes les applications développées par une organisation centralisée ou répartie.

1.5 Abstraction des données La notion dʹabstraction des données concerne la représentation générique des données (souvent par un modèle graphique) et des associations qui leur donnent un sens plus riche. De plus, les traitements essentiels sur le modèle sont pris en compte dès l’étape de la spécification du modèle. Plusieurs genres de modèles sont proposés, tous caractérisés par leur indépendance au regard du logiciel SGBD. Ces modèles dits conceptuels sont de plus en plus riches sur le plan de la représentation et visent à décrire les données et leurs traitements pour coller le plus possible à la réalité opérationnelle des organisations. Le processus d’abstraction des données permet essentiellement de spécifier les structures des données à plusieurs niveaux et dʹesquisser la logique de traitement par les applications. Le produit de cette abstraction est le modèle conceptuel de données (MCD).

Niveaux de représentation des données Il y a trois niveaux d’abstraction reconnus dans la modélisation des données lesquels correspondent respectivement aux besoins des utilisateurs, des développeurs et à ceux du DBA : a) Le niveau conceptuel : Cʹest le niveau supérieur où les structures physiques et les fichiers sont ignorés pour accentuer la description sémantique des données vue par rapport à la réalité d’une organisation. On tente de décrire les données de lʹorganisation en conservant le plus possible les liens entre elles. On met aussi lʹaccent sur l’homogénéité et le partage du nom des éléments de données et de leur type ou structure logique. Le modèle conceptuel est stocké dans le catalogue (dictionnaire) du logiciel SGBD. Exemple : Le fait contraignant quʹun employé travaille obligatoirement dans une ou plusieurs usines et cet autre fait que dans une usine travaillent obligatoirement de un à plusieurs employés doivent être représentés le plus fidèlement possible par le modèle conceptuel.

Modèle physique

Modèle logique Détails croissants

Mapping: Externe-Conceptuel

Application-1 (vue-1)



Modèle conceptuel des données

Mapping: Conceptuel-Interne



9

Figure 1.4

b) Le niveau physique : Cʹest la description physique des données faite par le DBA (Database Administrator). Cʹest à ce niveau quʹil faut spécifier lʹorganisation physique, les structures de stockage et les modes d’accès possibles. Ces métadonnées de niveau 2 sont essentielles pour que le SGBD réalise lʹaccès physique aux données. c) Le niveau externe : C'est la vue de la base de données sous l'angle d’une application particulière. Les données doivent être dans un format compatibles avec celui du langage de programmation, sinon le SGBD devrait en assurer la conversion. Les divers niveaux de description seront formalisés par un Langage de Définition des Données (le LDD ou en anglais le DDL) propre à chaque logiciel SGBD. Ce langage doté d’une syntaxe relativement simple permet de définir les données visibles et accessibles à chaque application.

Vues logiques de la structure de la base de données Chaque application utilise un sous‐ensemble de données, c’est‐à‐dire une vue particulière de la base selon les besoins de la logique de son traitement (figure 1.5). La vue est bien sûr définie différemment selon les modèles de données, mais son rôle demeure le même soit de contraindre une application à exploiter que certaines données, soit en mode mise à jour, soit en mode lecture. Elle est aussi dynamique dans le sens quʹelle donne une vision des données qui reflète toujours le dernier état de la base de données. Elle peut être illustrée approximativement par les parties tramées encadrées par une ligne pointillée.

Modèle conceptuel et les vues Figure 1.5

Par exemple, une application nommé ClientIndustriel est autorisée à exploiter qu’une partie des données Client et une autre partie des données Matériau. Les autres attributs lui sont alos interdits d’accès via le modèle externe.

Les parties encadrées sont des vues.

ProduitVue ClientIndustriel

Matériau



10

Description des entités (instances) de la classe Client Considérons une base de données très simple avec quelques classes (connues sous l’appellation Entités ou Entity Type) dont une nommée Client. Celle-ci est définie par son schéma, c'est-à-dire par sa structure spécifiée par un langage de description qui est particulier à chaque système SGBD. Ce langage (DDL pour Data Definition Language) permet de décrire la structure logique de la classe et le type de chaque élément qui la compose sans cependant faire mention des implémentations et des traitements possibles. Le schéma de la base de données comportera donc autant de définitions qu'il y a de classes. Par exemple, la structure de la classe Client est spécifiée différemment selon le niveau de représentation :

a) Au niveau conceptuel, la structure logique du dossier Client pourrait être la suivante :

Client = record, patronyme: string 30, adresse: string 20, ville: string 15, noCompte: integer;

Les libellés et les types de données peuvent être ceux implémentés et rendus disponibles par le logiciel SGBD. Ils sont utilisés pour la description de la classe Client. En principe, une application peut accéder à la classe Client à travers une vue particulière définie avec des types qui correspondent plus précisément aux données dont elle a besoin pour ses traitements et qui de préférence devraient être ceux du langage utilisé pour le traitement. Dans le cas contraire, il y aura une conversion (casting) des données à la charge de l’application ou du logiciel SGBD selon le cas. La structure qui est visible par la vue est dite externe. b) Au niveau externe, la structure exploitée par lʹapplication est généralement légèrement différente en termes de libellés, de types et dʹattributs. Ainsi, la partie du Client visible à une application nommée ClientRegion a une structure définie ainsi :

ClientRegion = record based on Client nom: string 20, null, /*attribut adresse n'est pas utile à l'application*/ municipalite: string 15, compteBancaire: string 5 ;

Les éléments de la vue externe peuvent être différents en nombre, en dénomination et en type au regard de ceux utilisés par le modèle conceptuel. Dans lʹexemple ci‐dessus, la vue ClientRegion représente les clients de Québec. Les applications qui utilisent cette vue nʹexploitent pas lʹélément adresse de sorte que celui‐ci nʹest pas spécifié dans la vue et son gommage virtuel est signalé à l’interne par un indicateur d’absence appelé le null.

c) Le niveau physique Au niveau 3, le physique, les éléments de la structure de Client sont définis par rapport aux caractéristiques des structures de stockage disponibles et mises en oeuvre. Voici un exemple hypothétique du schéma physique :



11

Elément rang position type longueur volume

patronyme 1 1 1 30 rd40 adresse 2 31 1 35 rd40 ville 3 66 1 20 rd40 pointeur de suite 4 86 7 4 rd40

Figure 1.6 Le passage (mapping) d’un niveau de représentation à l’autre est assuré par le SGBD, notamment par des procédures internes qui permettent la consultation et l’utilisation des métadonnées du dictionnaire du SGBD. Ce dernier est stocké dans la base elle‐même en utilisant les même structures que celles des données. Comme il s’agit de données qui décrivent les données de la base, elles sont libellées métadonnées.

Figure 1.7

Dictionnaire de données Le dictionnaire de données (DD) est donc souvent une métabase qui contient les informations pour réaliser les diverses transpositions de schémas, pour exploiter au plus bas niveau d’implémentation les structures des fichiers et pour vérifier les droits dʹaccès, les formats et les contraintes imposées aux données. Le dictionnaire de données est donc un dépôt d’informations essentielles à lʹexploitation de la base. Tout ordre DML de manipulation des données exige un accès au dictionnaire par le noyau du SGBD et cela, afin de trouver le nom interne des éléments de données du schéma et les adresses nécessaires pour accéder aux structures de données sur disque. En cours de traitement, les métadonnées sont généralement chargées à demeure dans la RAM, et cela afin de minimiser les accès aux disques qui ralentissent le temps de réponse aux requêtes des applications.

Opérations de mise en oeuvre de la base de données La mise en oeuvre dʹune base de données comporte de nombreuses activités qui appartiennent à des phases différentes dʹun projet, et qui sont réalisées lors de lʹanalyse informatique : a) Conception: Mise au point du modèle conceptuel, définition des tables, des domaines, des types de données et des contraintes. C’est la création des métadonnées et leur stockage dans le dictionnaire. b) Création : Allocation des espaces physiques et chargement des données de la base.

Application

SGBD

DD

Système de fichiers

BD



12

c) Exploitation: Insertion, suppression, modification et indexation des données en toute sécurité tout en garantissant intégralement la cohérence de la base. d) Gestion de la BD : Définition des droits dʹaccès, de la stratégie de reprise après une panne, gestion des copies de sûreté et indexation des données. Le SGBD fournit un langage de manipulation des données (appelé LMD ou DML pour Data Manipulation Language) composé de clauses dont la syntaxe est relativement simple. Ces clauses DML permettent de spécifier ce qui doit être recherché, mis à jour, supprimé ou ajouté dans la base. Les ordres DML types sont le SELECT, INSERT, le UPDATE et le DELETE. Souvent, la clause SELECT est considérée à part, comme une requête qui est de loin la clause la plus complexe. Depuis quelques années, le langage SQL et le DML proposés par le comité de normalisation ISO sont de plus en plus adoptés par les grands éditeurs de SGBD. Il y a essentiellement trois modes d’implémentation du SQL et du DML :

a‐ Langage de requête autonome Le langage autonome peut être utilisé directement pour manipuler la base de données sans avoir nécessairement besoin de lʹenvironnement dʹun langage hôte. Il permet essentiellement la mise au point des clauses de requête, mais ne permet pas le traitement des données obtenues dans la réponse, sauf s’il est intégré dans un langage de programmation de troisième (L3G) ou de quatrième génération. Voici, par exemple, une question simple à traiter par le système :

«Lister éditeur et le titre du livre répertorié avec le ISBN 4578 » Cette requête traduite en pseudo langage DML serait alors la suivante :

LIST editeur, titre FROM Livre WHERE ISBN = 4578 ; Pour exécuter cette requête et afficher la réponse, l’interpréteur du DML devra lancer une procédure interne LIST dont les paramètres sont le nom de lʹEntité (Livre) et le prédicat de recherche (Where).

b‐ DML intégré dans une application 3ème génération (L3G) Les ordres DML sont placés dans un programme L3G (Pascal, PL/1, ADA, C, C++, Java) et chaque ordre est exécuté séparément. Il y a deux façons de traiter les ordres DML imbriqués : a) Par traduction : le précompilateur reconnaît les ordres DML identifiés par un délimiteur particulier comme le # ou le EXEC SQL, et les transforme en appel de procédure du langage hôte pour ensuite passer à la phase compilation. Par exemple: Le système VAX/DBMS utilise le délimiteur # pour annoncer un ordre DML :

# FIND FIRST editeur FROM Livre USING ISBN = 4578; # FIND FIRST titre FROM CollectionDeLivre USING ISBN = 4578;



13

b) Par compilation avec un compilateur étendu : le compilateur reconnaît les ordres DML identifiés par un marqueur spécial et les traduit directement en code du langage de 3e génération (par exemple en C ou en COBOL). Exemple :

{ int no_isbn; ... gets (no_isbn); -- 4578 editeur_v = dbmslist ('editeur','Publication', 'ISBN = no_isbn'); titre_v = dbmslist ('titre','CollectionDElivre', 'ISBN= no_isbn'); printf('editeur = %s titre = %s \n',&editeur_v,&titre_v); }

Figure 1.8 La fonction dbmslist() permet de transmettre les arguments au processus SGBD avec une adresse de retour utilisée pour récupérer les données de la réponse.

c‐ Langage de quatrième génération (L4G) Le langage de 4e génération est de type autonome auquel on a ajouté les structures de contrôle pour lʹitération et lʹalternative. Lʹenvironnement dʹun L4G inclut généralement une interface graphique pour faciliter la composition des modules et des panoramas : NOMAD, FOCUS, PROC, Developer/Forms (Oracle), PowerHouse, etc. Un programme complet peut alors être élaboré et inclure les ordres DML et cela, avant sa traduction par un compilateur spécialisé.

d‐ Interface d’application (API) Une API est une bibliothèque de fonctions utilisées par les applications pour communiquer directement avec un SGBD. Ces fonctions dotées généralement de plusieurs paramètres réfèrent aux procédures des DML développées par chaque SGBD, dont l’une gère la communication par les sockets. Une telle bibliothèque peut être normalisée afin de fournir une interface commune pour lʹaccès aux données, peu importe le SGBD et cela, par lʹentremise dʹun pilote (driver) particulier. Cela renforce l’indépendance de l’application à lʹégard du SGBD. Les interfaces ODBC (Open Data Base Connectivity) et SAG (SQL Access Group) sont des propositions pour une API normalisée. Ces efforts de normalisation visent à pérenniser les applications en les rendant encore plus indépendantes du SGBD.

1.6 Administrateur de la base de données L’administrateur de la base (DBA) est devenu un acteur incontournable dans la gestion des données corporatives. Sa fonction est de gérer la création et le fonctionnement général de la base de données en surveillant particulièrement le placement des données, la performance des accès et les autorisations consenties aux utilisateurs. Il est aussi souvent responsable du fonctionnement du réseau, de la prise des copies de sûreté et du fonctionnement des ordinateurs‐serveurs. Voici quelques tâches qui incombent généralement au DBA :



14

a) Le contrôle du logiciel et des métadonnées. b) La gestion de la base : localisation, indexation, allocation des espaces sur disque, stratégie de

reprise et de sauvegarde (Backup). c) La coordination du développement modèle conceptuel : arbitrage et médiation entre les

concepteurs de systèmes et les usagers. d) Lʹautorisation des vues et des droits d’accès. e) Le contrôle de l’évolution du MCD ainsi que de la réorganisation de la BD qui en découle. f) La surveillance de la performance du SGBD et la réalisation des mises au point (fine tuning). g) Le choix du matériel au regard des exigences du SGBD et des traitements escomptés. h) La définition des déclencheurs (triggers) et des procédures internes (packages) stockés dans

le dictionnaire de la base de données. Ces dernières permettent dʹimplémenter les règles dʹintégrité et de validité.

La diversité et la spécialisation des tâches exigent une vaste connaissance de la part du BDA.

Typologie des utilisateurs

De nombreux utilisateurs participent à l’exploitation des données et en utilisent les résultats pour les fins de gestion organisationnelle. Dans certaines organisations, ils participent activement à la conception de la base de données. Il est possible de regrouper approximativement les utilisateurs en trois catégories : a) Les utilisateurs occasionnels : Ils privilégient le langage de requête en mode interrogation pour obtenir des réponses courtes du genre factuel ou agrégé. Souvent, les requêtes sont de type décisionnel. Pour les cadres moyens et supérieurs, les requêtes ont un caractère de synthèse sou‐tendant l’agrégation des données : tableau de bord, applications avec menus, OLAP... Ces utilisateurs ont besoin d’un langage de requête performant imbriqué dans une interface très conviviale. b) Les utilisateurs réguliers de niveau opérationnel : Ils utilisent des programmes spécialisés et encapsulés dont les fonctionnalités sont fixées à l’avance pour offrir une gamme limitée de services. Ils génèrent des requêtes transactionnelles. c) Les utilisateurs spécialistes : les concepteurs sont les artisans des applications au nom des utilisateurs. Leur travail est caractérisé par les facettes suivantes :

‐ Usage de L3G, L4G, DML et API. ‐ Traitements complexes pour implémenter une logique d’application et mettre en œuvre des types complexes. ‐ Intervention critique dans les processus d’affaires d’une organisation. ‐ Bonne connaissance du SGBD et des autres environnements. ‐ Implémentation du mode transactionnel et la gestion des données multimédias.

Impacts du logiciel SGBD pour les organisations L’intégration du logiciel SGBD dans le système dʹinformation dʹune organisation a des effets positifs et parfois négatifs sur l’organisation du travail des concepteurs. Voici quelques uns des effets positifs :



15

1. Les applications nʹont plus à gérer la redondance de données, celle‐ci est contrôlée par le SGBD.

2. Chaque application est, par définition, en concurrence pour le partage des données. La concurrence des accès est prise en charge par le SGBD quelle que soit l’architecture de l’environnement : centralisée, répartie, client-serveur ou web.

3. Lʹaccès aux données par une application est validé afin de renforcer la sécurité. 4. Lʹapplication client dispose de plusieurs interfaces spécialisées qui sont adaptées aux

usagers (technologie GUI ou générateur dʹinterfaces). Il en découle une réduction du temps de développement des applications (estimé à 30 %) et une plus grande réutilisation des procédures développées avec ou sans un langage L4G.

5. Le renforcement des contraintes d’intégrité est assuré par le logiciel SGBD. Cela simplifie les applications et garantit la vérification uniforme des règles d’intégrité. Il y a donc au départ une incitation pour établir des standards dans la gestion et le traitement des données dʹune organisation.

6. En cas de panne, le recouvrement est pris en charge par le SGBD grâce à des utilitaires de reprise et de sauvegarde.

7. Le rôle de DBA est exigeant à plusieurs égards. Son titulaire doit manifester à la fois une maîtrise des techniques et avoir des qualités du chef de projet.

Effets négatifs découlant de l’exploitation du SGBD Le logiciel SGBD est parfois vu comme un super‐mécanisme d’accès aux données. Les ressources mises en oeuvre dans ce logiciel sont importantes et, de ce fait, un SGBD demeure un outil particulier quʹil faut utiliser seulement lorsque lʹimportance des besoins de traitement lʹimpose. Malgré lʹusage répandue des SGBD, le concepteur doit être averti de certaines limites inhérentes à lʹintégration du SGBD dans un environnement dʹexploitation de données : a) Les frais dʹacquisition et dʹexploitation (matériel, logiciel, sécurité, personnel) sont

relativement élevés et récurrents. Ils peuvent être bas pour un monoposte, mais ils augmentent rapidement avec le nombre de stations autorisées à accéder aux données.

b) Les applications en temps réel sont difficiles à réaliser avec un logiciel SGBD. En effet, un

temps de réponse inférieur à 0,5 seconde avec un volume élevé de transactions est difficile à respecter, sauf si le SGBD est conçu pour un environnement temps réel.

c) Le temps de réponse est souvent inacceptable pour un nombre de requêtes (transactions)

supérieurs à 1000 Transactions Par Seconde (TPS). Le traitement est cependant excellent pour un TPS qui se situe autour de 400. Toutefois, des machines dotées d’architectures particulières permettent de briser cette barrière et traiter des charges de plus de 1500 TPS.

d) En mode monoposte, l’accès aux données qui sont peu structurées ne nécessite pas

obligatoirement un SGBD : un gestionnaire de fichiers suffirait largement. L’exploitation d’une SGBD pour un tel besoin n’est pas appropriée.



16

e) La gestion des données multimédias (son, couleur, animation) est encore difficile, mais devient possible. Le stockage et le repérage posent problème pour ce qui est des structures de données, leur gestion, leur mise à jour et la gestion des versions. À ces difficultés, il faut ajouter des temps de réponse encore trop lents en raison de la vitesse (largeur de bande) encore insuffisante des réseaux.

f) Le potentiel de déduction logique à partir des données de la base est encore une

fonctionnalité théorique peu ou pas implémentée dans les systèmes commerciaux courants. Toutefois, la tendance est telle qu’il est maintenant difficile de stocker des données sans avoir recours à un SGBD. En effet, le service de fichiers est de plus en plus absent dans les systèmes qui se limitent souvent à offrir un fichier séquentiel élémentaire. Tout autre accès plus complexe tel le direct ou le séquentiel indexé doit être mise en oeuvre par le client.

1.7 Architecture générale du système de gestion de bases de données (SGBD) Lorsqu’une requête parvient au SGBD, par lʹentremise du logiciel de communication ou du réseau, l’enchaînement des opérations pour calculer la réponse sʹappuie sur un ensemble de modules fonctionnels du noyau du SGBD qui sont regroupés sous les appellations fonctionnelles suivantes : EXECUTEUR et ACCESSEUR. Voici le rôle général de chaque module d’un SGBD :

Figure 1.9

Modification du plan d'exécution selon les coûts et les règles

Analyseur Analyse syntaxique Analyse sémantique

Traduction Génération du plan d'exécution Contrôle d'intégrité Contrôle des autorisations

Optimisation

Calcul Contrôle de la concurrence Atomicité de la transaction Exécution des opérateurs

Métabase

Base de données

Accesseur

Sous-système d'affichage



17

Analyseur : Le traitement de la requête reçue de l’application débute par une analyse syntaxique pour vérifier sa conformité avec la grammaire du langage de requête (ou du DML). Par la suite, une analyse sémantique vérifie que seuls les objets connus par la vue sont référés par la clause.

Traducteur : Lorsque la requête utilise une vue (sous‐schéma), le passage des références des objets de la vue et à ceux du schéma est effectué par le module de traduction. De plus, ce module vérifie si la requête a les droits d’accès aux données pour le type de traitement spécifié. Finalement, lorsqu’il s’agit d’une modification ou d’un ajout de données, le module vérifie si les contraintes d’intégrité seront respectées suite aux actions demandées. Optimiseur : Le rôle de ce module est de transformer la requête initiale en une autre équivalente dont le plan d’exécution (la séquence des opérateurs élémentaires) est de nature à fournir un calcul plus rapide de la réponse. Ce plan est une véritable feuille de route pour la réalisation du calcul : lecture de l’index Y, accès aux enregistrements du fichier Z par une méthode d’accès. Ensuite, l’optimiseur établit le coût du calcul de la réponse selon un modèle de performance (temps en fonction du volume de données) et construit le plan d’accès optimisé. Le lancement du calcul de cette requête est maintenant prêt. Calcul : Le plan optimisé est exécuté par ce module conjointement avec le module transactionnel et le répartiteur pour implémenter lʹatomicité de lʹexécution et le multithreading pour assurer un certain parallélisme dans lʹexécution des requêtes concurrentes. C’est le module EXECUTEUR qui implémente la concurrence et assure l’atomicité via un module de Gestion Transactionnel. L’exécuteur est une tâche qui exploite les primitives du système d’exploitation nécessaires pour lʹimplémentation des fonctionnalités du SGBD. Accesseur : C’est le module chargé de trouver et de placer dans la RAM les pages demandées par l’exécuteur. Il est aussi chargé sur demande de les écrire sur disque et dʹen faire la journalisation externe. Cette dernière opération consiste à écrire sur une mémoire stable (le disque par exemple) les données avant les modifications et celles après les modifications effectuées. Il gère les listes de pages (avec une politique de placement LRU) placées dans la ZMP tout en prenant en compte le statut de celles‐ci. Ce module exécute les procédures suivantes : INPUT (no‐page) et OUTPUT (no‐page).

Sommaire La gestion des données occupe une place importante dans le fonctionnement des organisations. Elle est largement tributaire des systèmes de gestion de base de données et des réseaux. L’évolution des logiciels SGBD est marquée par la généralisation de cet outil qui assume des fonctions capitales de stockage, de recherche, de partage et de cohérence des données. Les utilisateurs de ces systèmes sont l’ensemble des acteurs d’une organisation et cela, à tous les niveaux de responsabilité. Le volume des données à gérer est souvent astronomique et leurs types de plus en plus variés. Le rôle essentiel du SGBD consiste à assurer une continuité dans les services dʹaccès aux données des transactions, ce qui sous‐tend un support efficace du personnel technique dont la spécialisation et la compétence sont critiques dans le



18

fonctionnement de la base de données. Les nouvelles architectures, notamment celles de type client/serveur, le traitement distribué (avec une base de données réparties) et le browswer de l’internet favorisent le redéploiement des ressources informatiques selon un mode qui privilégie la décentralisation des traitements et éventuellement celle des données. La prochaine génération sera probablement celle des bases de données via l’Internet conjugée avec une architecture multi‐niveau. Exercices 1‐ Quelles sont les fonctions propres à un système de gestion de bases de données (SGBD) ? 2‐ Quel rôle particulier peut avoir une vue au regard dʹune application ? 3‐ Lʹaccès aux données est assuré par un SGBD et cela, pour chaque application autorisée. Quel est lʹapport des index dans cet accès aux données ? Est‐ce que les index sont essentiels pour assurer lʹexploitation des données? 4‐ Décrire une situation fictive qui exigerait une réorganisation de la base de données par l’administrateur de la base (DBA) ? 5‐ En vous référant à lʹarchitecture à trois niveaux, expliquer comment une partie de la base peut être déplacée sur un autre disque, sans que les applications en production soient perturbées ou rendues non opérationnelles. 6‐ Formuler une question en langage naturel qui pourrait facilement être reformulée par le module optimiseur afin de fournir plus rapidement la même réponse. 7‐ Commenter la notion de métadonnées et expliquer pourquoi celles‐ci doivent être gardées de préférence en RAM de l’ordinateur et non sur disque lorsque le SGBD est en exploitation. 8‐ Expliquer comment les modifications aux métadonnées peuvent invalider l’accès aux données. 9‐ Quel est le rôle du dictionnaire de données dans le traitement d’une requête à la base de données ? Expliquer simplement les étapes qui vous apparaissent évidentes pour son traitement. 10‐ Pour un environnement de travail multiusager, donner deux fonctionnalités importantes du logiciel SGBD et commenter leur rôle respectif. Références Chapitre 1 1 GARDARIN, G., Maîtriser les bases de données; modèles et langages, Paris, Eyrolles, 1993, ISBN 2‐212‐08727‐6. 2 TOMITA, T., The Volume of Information Flow and the Quantum of Media, ITU Telecommunications Journal, v. 42, no 6, 1975, p. 339‐349. 3 NORA, S., MINC, A., L’informatisation de la société, Paris, La Documentation française, 1978. 4 WILLIAMS, M. E., Data Bases and On‐line Statistics for 1979, ASIS Journal, December, 1980, p. 123‐135. 5 How Much Information 2003, Peter Lyman, Hal Varian, School of Information Management and Systems, University of California at Berkeley, 2003. 6 IOUW, How Big Is Your Database?, Oracle Magazine, May‐June 1995, p.113‐116.


19

Chapitre 2 Architecture fonctionnelle du logiciel SGBD

2.1 Système de gestion de base de données Un système SGBD est un progiciel capable de gérer adéquatement au moins un modèle de données et de faire des mises à jour, des suppressions et des ajouts dans une base de données. Il assure aussi la persistance des données pour les applications. Il est un composant essentiel dans lʹarchitecture plus générale que sous‐tend un Système à Base de Données (SBD).

SBD = (n x BD = (données + dictionnaire)) + SGBD avec n >= 1

La complexité du SGBD dépend des fonctionnalités implémentées dans lʹenvironnement informatique. Le Système de Gestion de Base de Données (SGBD) peut être exploité dans lʹenvironnement de la micro ou de l’informatique des grands systèmes avec une architecture centralisée, Client/Serveur ou répartie. Quelle que soit l’approche, le moteur SGBD joue un rôle central dont l’essentiel est presque toujours le même peut importe l’éditeur du système.

Modèle de données C’est un outil externe de représentation générique des données, c’est‐à‐dire qui ne retient que l’essentiel dans la spécification des données et cela, au moyen des éléments de modélisation suivants :

a) Types de données b) Associations c) Contraintes syntaxiques et sémantiques d) Méthodes des classes

Le modèle de données est exploité par un jeu d’opérateurs primitifs capables de réaliser les manipulations sur les données conformément aux contraintes et aux possibilités imposées par la structure du modèle. Il est très souvent représenté par un graphe connexe, cʹest‐à‐dire dont les éléments sont tous reliés.

Modèles conceptuels de données Plusieurs modèles (1) sont proposés pour l'organisation et la représentation générique des données. Seuls quelques-uns marqués par un astérisque s’imposent dans la pratique :

a) Modèle E/R* d) Modèle à objets* b) Modèle relationnel* e) Modèle UML* c) Modèle relationnel-objet* f) Modèle logique ou déductif

Avec le développement des systèmes hypertextes, de nouveaux modèles de données intègrent non seulement les données, le son et les images, mais aussi les mécanismes de navigation possibles prévus pour une application (2,3). Par exemple, le modèle RMDM2 propose une démarche intégrée pour le développement des applications hypertextes: lʹanalyse de besoins concernant les données et la navigation, la modélisation des classes, des facettes et des chemins de navigation, la conception des interfaces, la traduction du modèle RMDM vers le modèle



20

dʹimplantation et finalement, lʹévaluation de lʹapplication hypertexte. La modélisation des bases de hypertextes fait lʹobjet de plusieurs travaux articulés autour des systèmes DEXTER(3), HB(4) et TREILLIS(5).

Schéma de la base de données Le schéma de la base de données est la description complète du modèle logique de données au moyen d’un langage spécialisé de définition, appelé le DDL (Data Definition Language). Cette description change relativement peu en cours d’exploitation de la base. La problématique de la répartition des données pourrait entraîner des modifications de l’emplacement des données, mais pas nécessairement des changements au modèle conceptuel. Dans le contexte du relationnel, le schéma de la base de données est lʹensemble formé avec le schéma de chaque table relationnelle. Instance de la base de données L’instance de la base de données est lʹensemble de données stockées dans la base au moment t. Plusieurs auteurs décrivent les données comme des objets. Lʹinstance de la base de données devient alors un ensemble dʹobjets. Ils supposent que chaque donnée est atomique et qu’elle est associée à un ensemble de méthodes ou de procédures communes pour la recherche, la mise à jour et la suppression. Ces méthodes sont en quelque sorte factorisées au niveau de chaque classe et implémentées par des fonctions. Elles ne sont pas toujours incluses dans le modèle.

Figure 2.1

Architecture ANSI/SPARC

Création du schéma logique

Dictionnaire

Création des schémas externes

Création des schémas internes (physiques)

Transformation des clauses d’accès externe vers le conceptuel

Transformation des clauses d’accès conceptuels en code d’accès interne

Transformation des clauses d’accès externe vers le conceptuel

BD

Application

2 1

3

4

5

6

7

8

9

10



21

On peut voir les données dʹun point de vue différent selon que lʹon est DBA ou développeur d’applications. Une architecture avec plusieurs niveaux favorise une meilleure séparation entre les applications et la structure physique des données de la base. Lʹarchitecture ANSI/SPARC propose trois niveaux de modélisation des données : a) Niveau conceptuel : Description logique de toutes les données selon la réalité perçue par le concepteur. b) Niveau externe : Description des données utilisées par une application selon les caractéristiques imposées par les traitements de chaque application. Il correspond à la notion de vue. c) Niveau interne : Description des structures physiques nécessaires ou disponibles pour la représentation des données sur un ou plusieurs disques. La figure 2.1 illustre le rôle de chaque processeur de schéma et illustre les différentes étapes dans la transformation des ordres du DML.

Indépendance logique L’indépendance logique est la possibilité de modifier le schéma conceptuel en perturbant le moins possible le fonctionnement des applications, c’est‐à‐dire la vue (ou modèle externe). En d’autres mots, une modification au modèle conceptuel n’a pas d’impacts sur les éléments du modèle utilisés par une application. En cours d’exploitation, elle favorise la productivité et une continuité de l’exploitation.

Indépendance physique L’indépendance physique est la possibilité de modifier le schéma interne des données sans modifier le schéma conceptuel. Par exemple, le gestionnaire de la base de données peut déplacer les données sur d’autres disques ou définir des structures de données plus adéquates pour les accès à la base de données sans perturber le fonctionnement des applications.

Langage de données Les niveaux du langage de données correspondent à ceux du modèle exploité, à savoir le conceptuel, l'externe et l'interne. La tendance actuelle est de spécifier ces trois niveaux avec le même langage de données dont certains ordres sont particuliers à chaque niveau. En principe, les quatre facettes sont les suivantes : a) DDL (Data Definition Language ou Langage de Définition de Données): Pour la spécification

du schéma conceptuel ou du modèle d’implantation qui en découle (MCD) et des vues. b) VDL (View Definition Language): Pour définir les vues ou les modèles externes (similaire au

DDL du modèle conceptuel avec quelques restrictions en sus). c) SDL (Storage Definition Language): Pour spécifier les paramètres de stockage physique. d) DML (Data Manipulation Language ou Langage de Manipulation des Données): Pour mettre à

jour et supprimer les données de la base en fonction des structures définies au préalable par le langage de définition de données.



22

Caractéristiques des langages de données Chaque SGBD peut avoir son langage de données qui lui est propre et même cohabiter avec un autre plus universel. Les fonctionnalités d’un langage de données sont caractérisées par les propriétés suivantes : 1. Déclaratoire : La requête formule ce qui est recherché dans la base. 2. Procédural : La requête précise comment rechercher les données dans la base. 3. Intégré dans un langage hôte : Insertion du DML dans une application L3G. 4. Langage de requête : Limité souvent à la recherche. 5. Convivial : Les interfaces conviviales du langage facilitent la construction des requêtes par lʹentremise des interfaces graphiques (GUI).

Manipulations des données Les ordres DML pour l’insertion, la modification et la suppression des données sont disponibles dans tous les systèmes avec une syntaxe propre à chacun. Il en résulte souvent des formes de différentes de DML d’un SGBD à l’autre.

Ajout : INSERT INTO ADD TO STORE Suppression : DELETE FROM DROP, ERASE, Mise à jour : UPDATE, CHANGE MODIFY

La recherche est formulée par un langage de requête propre au SGBD ou de type SQL. Exemples de requêtes formulées dans divers langages: Voici comment peut être formulée dans différents langages, une requête pour trouver les matricules des employés dont le nom contient les lettres ‘tion’. Recherche : a) Oracle : SQL

SELECT nom FROM Employe WHERE nom LIKE '%tion%';

b) INTERBASE : requête en gdml

PRINT nom OF Employe WITH nom matching '*tion*';

c) Vax/DBMS : requête pour le modèle de données réseau

FIND ANY Employe WHERE nom .CONTAINS. '*tion*' PRINT Employe.nom

Langage de définition des données (DDL) Le langage DDL permet de décrire le schéma conceptuel (et souvent le schéma externe) de la base de données. Le schéma est préparé avec un éditeur sous forme d’un fichier de texte qui est par la suite traduit par un compilateur propre à chaque SGBD. Ou encore, il est sous la forme de commandes interactives, lesquelles sont lʹobjet dʹune interprétation et dʹune exécution en ligne.



23

Dictionnaire Le dictionnaire des métadonnées (data dictionary) est en quelque sorte le dépôt de toutes les informations concernant la base de données incluant les procédures stockées et les déclencheurs (triggers) définis sur la base. Le dictionnaire est dit passif lorsqu'il est en différé relativement aux opérations sur la base. Il sert davantage pour les phases d’analyse et permet de renforcer d'uniformiser les libellés et la sémantique des données lors d'une réingénierie des processus. Le dictionnaire actif est, de par sa fonction, essentiel au fonctionnement du SGBD; il est en ligne avec le noyau du logiciel. L’ensemble des dictionnaires d’une organisation est désigné maintenant comme une encyclopédie des données, un concept sous-tendu par le Data Warehousing.

Évolution des modèles et des langages de définition Le dictionnaire de métadonnées est souvent différent d’un système à l’autre. Avec les diverses générations des SGBD, la séparation entre la définition logique et la spécification physique est plus marquée et le langage de définition des modèles plus riche dans sa capacité à capturer la sémantique des données. Cette évolution a marqué sensiblement les caractéristiques des premiers systèmes SGBD. Dans les exemples suivants, cette évolution au niveau du schéma graphique est illustrée à l'aide d'un fragment de modèle conceptuel spécifié au moyen du langage DDL de quelques SGBD, dont certains ne sont plus des logiciels vedettes, bien que toujours opérationnels.

Schéma source d’une base de données de commandes (SGBD IDMS) Voici un fragment du schéma source de la figure 2.3 qui est une partie dʹun modèle réseau spécifié avec IDMS (version 1980). Les liens sont de type 0‐n et représentés par la notion de set.

Figure 2.3 record name is LIGNEARTICLE record id is 621 location mode is via commandeArticle set within regionCommande area

03 noArticle pic X(8), 03 qte 05 qteCom pic 9(7),

Commande noCommande* montant dateCommande

LigneArticle noArticle qte: (comp)

qteCom; qteLiv

prix remarques (mv)

CommandeArticleAera: region-commande



24

05 qteLiv pic 9(7), 03 prix pic 9(4). 03 remarques occurs 0 to 10 times depending on nb-rem.

Après la compilation, le schéma transformé est rangé dans le dictionnaire. Ce schéma exécutable contient certaines informations, non pertinentes au niveau conceptuel, lesquelles concernent l’identification des enregistrements (records), le placement des données et leur mode d’accès. Schéma TOTAL : base de données sur les Ressources humaines Ce schéma TOTAL (version1978) illustré ci‐dessous comporte peu d’indépendance logique et physique en raison de son architecture à un seul niveau, intégrant le conceptuel, le logique et le physique. Ce schéma confond dans son langage les trois niveaux en incluant les informations descriptives du niveau physique avec celles du niveau conceptuel. De plus, l’obligation inutile de fournir la longueur des champs alourdit les modifications subséquentes au schéma du modèle.

Figure 2.4 .

begin-data-base-generation data-base-name= PERSONNEL share-io ioarea = mas1 ioarea = mas2 ... end-io begin-master-data-set data-set-name = Dep ... data-set-name = empl ioarea = mas1 master-data emplroot = 8 --8 octets emplctrl = 6

emplnom = 30 empladr = 50 empltel = 10 end-data drive = 12, 48, mt32 total-logical-records = 200 logical record-length = 104 logical-records-per-block = 9 end-master-data-set ... end-variable-entry-data-set end-data-base-generation

Dans ce schéma, il faut noter la présence d’un fichier indexé qui implémente le fichier-maître Dep (master-data-set). Chaque élément du modèle est nommé en le préfixant du nom du data-set.

Employe nom * adresse telephone

Departement noDep* site

Fichier-maître



25

Schéma ADABAS (version 1983) de la base de données dʹune société de distribution --- Schéma ADABAS (version 1983) ---- clients (001) 01, nc, 5,u,DE -- u indique attribut numérique 01, nm, 15, a,DE -- a un attribut alphabétique 01, pc, 15, a -- DE indique un attribut indexé 01, ac nu -- supprime des blancs dans un champ alpha 02, no,4,u 02, ru,15,a 01, np, 4, u, DE 02, vi, 15,a,de 01, qp, 5, u 02, te, 7, u 01, al 01, es, 3, a, nu 02, ci. 4, u 02, ru, 15,a commandes (002) produits (003) 01, nc, 7, u, de 01, np, 6,u ...

Figure 2.5

Cette partie de schéma ADABAS des années 80 est un exemple de langage de description peu significatif pour les développeurs d’applications. Néanmoins, ce logiciel permet de gérer une base de données avec des structures directement adaptées aux liens complexes de plusieurs à plusieurs (n‐m) et réciproques, sans la création de classes logiques supplémentaires. Ce lien complexe est créé au besoin par une table de couplage (Table Coupling) implémentée par une structure de données inversée. Cette caractéristique en faisait un logiciel fort intéressant parce qu’il est capable de gérer un modèle physique similaire au modèle conceptuel.

Modèle de Vax/DBMS Le schéma d’une base de données réseau gérée par ce système se rapproche de celui recommandé par CODASYL. Les informations ayant trait au niveau conceptuel sont séparées du niveau physique voire même de celles régissant les accès aux données (6). Ce système gère les modèles conceptuel, externe, interne et de sécurité.

Entrepots 04

Clients 001

Commandes 002

Produits 003

Vendeurs 006

ComEntrepot 006

1

n n

n n

n

1

1 1

m

n



26

Schéma DDL/ Vax DBMS *Scénario 2 - Base de données académique schéma name is BD_SC2 *Description de l'entité FACULTE

record name is FACULTE within FACDEPT item CODEFAC type signed longword item NOMFAC type character 30 *Description de l'entité DEPARTEMENT

record name is DEPARTEMENT within FAC_DEPT item CODE_DEPT type signed longword item NOM_DEPT type character 30 * Description de l'entité PROFESSEUR record name is PROFESSEUR within DEPT

item NASPROF type signed longword item NOMPROF type character 20 item ADRESSEPROF type character 15 occurs 3 times item TITRE type character 20

... * Description du groupement INSCRIT set name is INSCRIT owner is DEPARTEMENT member is ETUDIANT set selection is current of set insertion is manual retention is optional order is sorted by ascending MATRICULE duplicates are not allowed . . .

Modèle conceptuel réseau DBMS Figure 2.6

Le langage de schéma de ce SGBD est plus riche en types de données que les précédents permettant ainsi de représenter quelques types complexes comme les groupes et les vecteurs.

Faculte codeFac nomFac

Departement codeDep nomDep

Compose_de

Etudiant matricule nomEtud prenomEtud adresseEtud adressPerm dateNaisEtud dateInscr

Cours titreCours nbCredit

Inscrit Dispense Emploie

Professeur nasProf nomProf adresseProf titre



27

En outre, la description demeure au niveau logique des données et ne fait aucune référence aux aspects physiques. Ces derniers font l’objet d’un schéma interne complètement séparé.

Environnement de traitement centralisé Ce système est encore utilisé dans les grandes organisations. Il est installé sur une seule machine dite centrale cohabitant avec plusieurs autres logiciels étrangers à la base de données. De plus, cet ordinateur gère souvent un grand nombre de terminaux au moyen dʹun logiciel de communication de type moniteur de transactions (TP pour Transaction Processing monitor). Ce dernier permet de fournir et de recevoir des données en transit vers une application particulière qui tourne sur la machine centrale. Dans le cas le plus simple, le SGBD ne répond quʹà une seule requête à la fois (single thread). Les requêtes simultanées qui proviennent de différentes applications sont mises alors en file dʹattente par le moniteur de transactions. Dans le cas d’une configuration dite d’entrelacement d’exécution (multithreading), plusieurs requêtes en provenance d’autant d’applications (terminaux) peuvent être traitées en concurrence. Un tel service exige un OS multitâche et une gestion fine du partage des données.

Multithreading avec un processeur de transactions sur machine centrale Chaque écran transmet les données nécessaires pour effectuer une transaction (en mode autonome) au processeur de transactions (PT) qui les gère en tenant compte des priorités respectives. Le module de traitement des transactions crée un processus pour chaque requête. Ce nouveau processus concurrence les autres processus actifs pour les accès à la BD. Le système de répartition de l’OS se charge de gérer les différentes tâches associées à l’application pour réaliser ainsi l’entrelacement des traitements. Lorsquʹune tâche fait, par exemple, une lecture sur un disque pour une application, une autre tâche peut alors prendre le contrôle du processeur et poursuivre son exécution. Pour une meilleure performance, le processus du moniteur TP de la figure 2.7a une très grande priorité pour le système d’exploitation (OS) de manière à obtenir rapidement le contrôle du CPU. Deux cas sont possibles : Cas 1 : exécution séquentielle (single-thread) Un seul DML d’une application est exécuté à la fois (pas de concurrence entre les applications). C'est une approche non performante, maintenant caduque.

Figure 2.7

file des requêtes

SGBD

BD Une seule transaction traitée à la fois et entièrement par l’application.

Moniteur TP Ecran 1

Ecran 8

Application-1



28

Le processeur transactionnel de transactions (TP) couplé au moteur SGBD améliore quelque peu le traitement en partageant le même moteur SGBD avec les terminaux actifs. Cas 2 : interclassement des transactions en provenance de plusieurs terminaux pour le traitement de données (multithreading). Ces transactions sont exécutées en concurrence et gérées par le répartiteur du système dʹexploitation (OS) tel qu’illustré à la figure 2.8. Chaque transaction est exécutée par un processus dupliqué pour exécuter le code correspondant à l’application. Il y a aura donc autant de processus concurrents que d’écrans actifs. Cette récupération des cycles du CPU par les processus chargés de traiter un ordre DML sera aussi nécessaire dans une architecture client/serveur en mode connecté où le nombre de processus est susceptible d’être encore plus important. De plus, chaque application sʹexécute sur la station‐client et, seul lʹordre DML est transmis au serveur. Il est donc capital d’avoir un système d’exploitation multitâche performant pour la gestion du serveur de bases de données avec une machine capable de répondre à la charge créée par les clients. Les système OS/2, Unix, Windows NT et XP Pro sont les plus utilisés sur les plates‐formes micro, tandis que les systèmes propriétaires IBM‐MVS, IBM‐AIX, Sun‐Solaris et Sun‐OS dominent le matériel de niveau station de travail ou celui des ordinateurs centraux.

Entrelacement d'exécution (Multithreading)

Figure 2.8 Les environnements client‐serveur et les architectures fédérées ne changent pas fondamentalement le fonctionnement général du moteur SGBD, mais le situent dans un contexte opérationnel plus diversifié qui permet notamment une meilleure performance et des ressources matérielles plus adaptées à lʹenvironnement de traitement (scalability). Il faudra une architecture parallèle pour escompter encore des gains importants de performance. L’approche client‐

ecran-1 no-transaction id-application valeur-1 valeur-2 valeur-3

Transaction :

Moniteur de TP

proc-1

proc‐2

proc‐3

SGBD

BD

Table des applications proc-2 proc-1 proc‐3

station 4 station 1



29

serveur est bien adaptée à l’exploitation par réseau. Dans un tel cadre, les applications sont développées au niveau de chaque station en utilisant les ressources logicielles disponibles localement. L’accès à la base de données se fait par lʹentremise dʹun ou de plusieurs réseaux hétérogènes qui véhiculent chaque requête au serveur lequel agit comme une ressource centrale. Plusieurs auteurs préconisent l’approche fédérée dans l’exploitation des données. Cette approche met aussi en oeuvre l’architecture client‐serveur mais en y ajoutant la possibilité de répartir la base de données sur plusieurs serveurs hétérogènes. Bien sûr, une telle base de données doit être gérée de façon à maintenir la cohérence, l’intégrité et la transparence des données peu importe la provenance de la requête.

Modèle fonctionnel du logiciel Nous reprendrons le modèle fonctionnel présenté schématiquement au chapitre 1. On peut décrire un logiciel SGBD sous un angle fonctionnel, car les aspects d’implémentation varient largement selon la plate‐forme, voire même selon les différentes versions du même logiciel. En outre, le développement de nouveaux systèmes d’exploitation offrira sans doute des moyens d’implantation encore plus puissants. Cette description schématique comprendra : a) Les fonctions présentes dans un SGBD; b) La coopération entre les fonctions internes du système pour la gestion efficace et cohérente des données.

2. 2 Architecture générale dʹun SGBD Voici l’architecture fonctionnelle vue auparavant :

Figure 2.9

Modification du plan d'exécution selon les coûts et les règles

AnalyseurAnalyse syntaxique Analyse sémantique

Traduction Génération du plan d'exécution Contrôle d'intégrité Contrôle des autorisations

Optimisation

Calcul Contrôle de la concurrence Atomicité de la transaction Exécution des opérateurs

Métabase

Base de données

Accesseur

Sous-système d'affichage



30

Le SGBD est composé de plusieurs modules agissant en coopération dans l’enchaînement des opérations pour calculer la réponse. Il comprend deux composants majeurs : lʹExécuteur et lʹAccesseur. Voici le rôle général de chaque module d’un SGBD : Analyseur : Le traitement de la requête débute par une analyse syntaxique pour en établir la conformité avec la grammaire. Puis, une analyse sémantique vérifie que seuls les objets typés connus par la vue sont utilisés. Traducteur : Lorsque la requête utilise une vue (sous‐schéma), le passage des références aux objets de la vue à ceux du schéma est effectué par le module de traduction. De plus, ce module vérifie si la requête a les droits d’accès aux données pour les opérations quʹelle compte effectuer. La dernière phase de la traduction consiste à générer un arbre de requête formé avec les opérateurs de l’algèbre relationnelle. Finalement, lorsqu’il s’agit d’une modification ou d’un ajout de données, le module vérifie si les contraintes d’intégrité sont respectées par les actions à faire sur la base de données. Optimiseur : Le rôle de ce module est de transformer la requête initiale en une autre équivalente dont le plan d’exécution est de nature à fournir un calcul plus rapide. Ce plan est une véritable feuille de route pour la réalisation du calcul : lecture de l’index Y, accès aux enregistrements dʹun fichier par une méthode d’accès. Ensuite, l’optimiseur établit le coût du calcul de la réponse selon un modèle de performance (relatif au temps en fonction du volume de données), qui sert de base dans le développement du plan d’accès optimisé. Calcul : Le plan optimisé est exécuté par le module du Calcul du SGBD qui effectue le calcul de la réponse pour lʹopérateur en utilisant au besoin les index et les tables de la base. Il est aussi chargé de la gestion de la concurrence et assure l’atomicité et le recouvrement des transactions. Ce module est notamment composé dʹune fonction de gestion transactionnelle et dʹune autre chargée de la répartition des actions de lecture et dʹécriture. L’exécuteur dédié ou partagé est un processus qui exploite aussi les primitives disponibles dans le contexte d’un système d’exploitation particulier. Accesseur : C’est le module chargé de trouver et de placer en zone de mémoire partagée les pages demandées par l’exécuteur. Il est aussi chargé de les écrire sur disque. Il gère aussi les listes de pages de données (LRU) placées dans la zone commune, la ZMP. Ce module exécute les procédures Input(no‐page) et Output(no‐page). Lʹadresse dʹune page est formée essentiellement dʹun numéro de page et de lʹindice dʹune entrée dans le répertoire de la page. Ce couple est appelé un rid ou un rowid. Dans les pages suivantes, nous ferons un rappel des notions de base implémentées dans les SGBD complexes.

Rôle des processus dans les architectures SGBD

Définition du processus Un processus est une unité (segment de code) d’exécution gérée par le système dʹexploitation; il est doté dʹun espace mémoire propre (RAM), de son code (segment de texte), d’un espace de données (segment de données), d’une pile d’exécution (segment de pile, le contexte) et d’un compteur ordinal. Il a aussi sa propre table de descripteurs, sa table des signaux et ses trois



31

ʺtimersʺ maintenus en son nom par lʹOS. C’est donc un programme en exécution géré par l’OS au moyen de la table de processus Unix proc[]. Toutefois, plusieurs processus différents peuvent exécuter le même programme. Le noyau dʹun SGBD met en oeuvre plusieurs processus coopérants pour stocker et retrouver les données.

États dʹun processus Un processus géré par le système d’exploitation peut avoir plusieurs états mutuellement exclusifs : a) Prêt à l’exécution (ready) : il a toutes les ressources nécessaires sauf celle du processeur; il attend le feu vert du répartiteur de lʹOS pour être lancé. b) En attente bloquée (blocked) : attend la fin d’une autre activité pour poursuivre la sienne; il a déjà démarré son exécution, mais il est suspendu en attente de la libération dʹune ressource qu’il a perdue momentanément. c) En exécution (running) : le processus est actif et effectue sa tâche.

Répartition (scheduling) des tâches Le répartiteur (scheduler) du système dʹexploitation choisit le processus à exécuter parmi ceux qui sont prêts. Cette répartition tient compte du niveau de priorité spécifié pour chacun des processus. Dans le contexte dʹun SGBD, les processus qui font lʹobjet dʹune répartition par lʹOS seront ceux du noyau du SGBD. Le rôle d’un système d’exploitation n’est donc pas neutre dans le fonctionnement du SGBD.

Alternance de processus (swapping) Un processus en attente ou prêt peut être évacué au besoin (swapped) par l’OS pour faciliter l’exécution d’un autre qui exige de la mémoire RAM supplémentaire. Cette vidange (swapping) est réalisée par l’OS et ces pages sont rangées temporairement dans un fichier spécialisé à cette fin sur un disque. Cette opération suppose l’exécution d’un appel au superviseur accompagné d’une sauvegarde du contexte du processus courant.

Conséquence négative de l’alternance La présence de nombreux processus en mémoire accroît l’activité I/O qui affecte directement la performance du SGBD. L’alternance se manifeste par des temps de réponse variables. La première stratégie consistait à évacuer toutes les pages d’un processus afin de libérer la mémoire pour un processus en phase de démarrage. Dans le système SYSTEM V (Unix) une évacuation graduée, à la page (demand paging), a éliminé l’échange inutile de pages (swapping).

Processus sous‐jacents au fonctionnement SGBD Le fonctionnement du SGBD suppose la mise en oeuvre de plusieurs modules coopérant entre eux : 1. Un Exécuteur, éventuellement plusieurs, est créé pour le service aux requêtes. Leur nombre

dépendra de celui des clients actifs. La décision de lancer plusieurs Exécuteurs est prise par le DBA en faisant au démarrage un choix de paramètres appropriés.

2. Plusieurs autres processus pour implanter le noyau du SGBD. Leur taille est souvent

supérieure à 1 Mo. Ils sont la propriété du compte spécial SYSTEM. Leur rôle consiste à gérer la mémoire, le journal des requêtes (transactions), le calcul de la réponse et le lancement de



32

reprise. Ces processus occupent un espace important dans la RAM. En règle générale, pour maintenir une bonne performance en cours d’exploitation d’une base, il faut maintenir au plus bas lʹactivité de la pagination et cela, en agrandissant au besoin la ZMP et faire appel à des disques RAID.

Appel au Superviseur (SVC‐SuperVisor Call) La gestion des différents processus a un effet négatif sur la performance du noyau d’un SGBD. Parmi les facteurs de ralentissement, il y a le nombre d’appels au superviseur (SVC) pour obtenir des services du système d’exploitation comme les opérations de I/O sur disque, certaines communications entre processus (IPC) et leur synchronisation. De plus, la commutation du contexte système demandé à chaque SVC constitue une charge pour le processeur notamment au début et à la fin de chaque SVC, puisque la sauvegarde des registres, des piles et des caches exige une activité I/O relativement importante. La fréquence de la sauvegarde du contexte est variable selon la machine. Elle peut varier de 1500 bascules/sec pour un micro‐ordinateur à plus de 100 000 bascules/sec pour les ordinateurs de grande puissance.

Multiplication des processus Un processus peut en créer d’autres par une fonction système [comme la fonction C fork()] pour diviser, au profit des utilisateurs, le travail global à effectuer par le processus parent. Cette multiplication des processus n’est pas neutre et accroît la charge de travail de lʹOS :

a) Augmentation du nombre de commutations de contexte. b) Accroissement de la charge pour le répartiteur qui doit gérer plus de processus.

Un processus ainsi créé est dit processus enfant et hérite du descripteur du processus parent lui permettant dʹavoir accès aux mêmes fichiers et aux mêmes sockets qui appartiennent au premier (le parent). Pour un SGBD, lʹutilisation de ce mécanisme exige quʹun premier processus soit lancé par le compte DBA et quʹensuite, les autres soient créés par la primitive fork(). Cʹest ainsi que le nombre de processus Exécuteurs pourrait être augmenté lorsque le nombre de clients atteint une certaine limite.

Thread ( comportant un compteur ordinal + pile + code) Un processus peut avoir plusieurs threads pour exécuter en parallèle divers traitements. Le thread se distingue du processus par le fait qu'il a le même espace d'adressage que celui du processus qui l'a lancé. Il a donc accès aux mêmes données en mémoire et aux mêmes ressources de fichiers et de sockets que ceux du parent. Cependant, il a une pile propre, son propre code et son compteur ordinal. Si un même ordre DML est exécuté par plusieurs threads, la performance sera d'autant plus grande si chacun est exécuté par un processeur distinct tout en utilisant une partition différente des données. À terme, la réunion des résultats de chaque thread fournira la réponse à la requête DML. Ce parallélisme dans le calcul de la réponse à une requête permet d’avoir des performances sensiblement meilleures avec les bases de grande taille.

Mécanismes de communication interprocessus La communication avec et entre les processus du noyau (IPC) pour échanger un ordre DML (ex. SQL) ou d'autres données de contrôle ou pour retourner les données de la réponse calculée sous-tend l'exécution de fonctions de système par l'OS afin d'implanter les diverses fonctionnalités à savoir le stockage, le recouvrement et la cohérence de la base de données au niveau du serveur. Deux cas de figure sont importants :



33

a) Communication interprocessus sur une seule machine au moyen des mécanismes suivants : tube, queue et mémoire partagée (ZMP). b) Communication interprocessus sur plusieurs machines par sockets et RPC (pour les bases de données réparties et l'architecture client/serveur). En gros, un SGBD est un ensemble de programmes, donc autant de processus appartenant au même groupe de processus (groupid). Ces processus coopèrent entre eux, se mettent en attente et se réveillent périodiquement pour effectuer des actions de lectures ou de mises à jour sur la base de données, notamment par l'accession à une page de données, la vidange des données de la RAM ou la réalisation d'un point de reprise (checkpoint). Mécanismes IPC sur une seule machine Le tube (pipe) avec le modèle lecteur/écrivain est un mécanisme implémenté directement comme une primitive du système Unix.

Figure 2.10

C’est un mécanisme simple unidirectionnel qui s'apparente aux fichiers et qui est applicable entre processus appartenant au même groupe de processus et ayant le même parent (process group), car c'est par l'héritage d'une table de descripteurs d'un ancêtre commun que les deux processus vont pouvoir communiquer. La fonction pipe(fd) génère deux descripteurs de fichier et alloue un buffer interne, lequel est géré par le noyau du système OS . Par exemple, pour communiquer à un processus 1024 caractères rangés dans un tableau nommé tabA, le processus2 utilisera la fonction write(fd,tabA,1024). Les étapes sont les suivantes : a) création du tube : int pipe(p) Cette fonction de système est exécutée avant le fork(). L'argument p est un tableau p[2] de type entier. Un premier descripteur doit remplacer celui en position 0 (stdin) et le deuxième celui en position 1 (stdout) de la table des descripteurs de l'autre processus qui est identique à celle du premier. Le tampon interne est généralement limité à une taille de 4 Ko.

Processus 1

Processus 2

tube 1

tube 2

Buffer géré par le noyau

table descripteur 0 stdin 1 stdout

table descripteur 0 stdin 1 stdout

Le buffer est créé dans l'espace géré par l'OS

OS OS



34

b) les fonctions read et write sont utilisées pour lire et écrire sur un tube comme dans un fichier. Ces fonctions font un appel SVC (appel au système), donc amorcent une commutation de contexte avec un effet négatif sur la performance. L'écrire de 1024 caractères rangés dans le tableau tabA au moyen du stdout dont le descripteur est 1, est fait par la fonction suivante :

write ( 1, tabA, 1024); -- écrire 1024 car. dans le tube 1 La lecture de 1024 caractères dans le stdin dont le descripteur est 0, est faite par la fonction suivante :

read(0, buf , 1024); ‐‐ lecture du buffer interne Le tube a l'inconvénient d'implémenter un échange sur une même machine et d'avoir un tampon limité à 4096 octets. Si deux processus doivent échanger des données simultanément dans les deux sens, ils doivent avoir un parent commun afin de pouvoir établir deux tubes entre les processus en question. Finalement, le tube est bloquant dans ce sens que si la lecture est moins rapide que l'écriture, le processus écrivain sera suspendu.

Mémoire partagée (ZMP) Ce mécanisme permet à deux processus d'échanger des données en partageant l'accès à une même zone de mémoire RAM par la même adresse du début de la dite zone.

Figure 2.11

En créant cette zone de mémoire commune, l’OS assigne une clé d’accès à cette zone figée qui reste généralement en mémoire principale et qui est accessible sans appel au superviseur (SVC). Cette clé d'accès est rendue accessible aux applications par une fonction système shmat(cle,0,0). Cette zone ZMP est logiquement constituée d'un seul espace, mais selon les OS, elle peut être constituée de plusieurs segments partagés de mémoire RAM, alloués par le système. La zone de mémoire partagée est créée par l'OS qui fournit aussi une clé d'accès à cette même zone. La mise en oeuvre d'une ZMP peut se faire de la façon suivante : a) Création d'une ZMP de 4Ko avec la fonction:

cleZ = shmget(cleU, 4096);

Processus 1 Processus 2

Espace géré par l'OS

Pages de données

Zone non structurée explicitement



35

La clé reçue, cleZ est la donnée essentielle pour le rattachement à la ZMP. Elle est calculée à partir de la cléU (un très grand entier) fournie par le processus ou l'utilisateur au moment de la création de cette zone. b) Un processus serveur, SP, s'attache la ZMP par la fonction: char *shmat(cleZ). Le processus obtient la clé dans la liste de paramètres transmise par un module temporaire chargé du lancement du processus pour ensuite disparaître. L'adresse d'attachement est fournie comme valeur de retour de la fonction. c) Le processus peut alors accéder à la ZMP comme si c'était une mémoire locale, c'est-à-dire comme étant une partie de son espace adressable. Dans le contexte d'un moteur SGBD, c'est un module spécialisé (Accesseur) qui sera chargé d'accéder aux pages de cette zone. d) Chaque processus doit contrôler l'accès à la ZMP et plus particulièrement aux pages par des sémaphores mis en oeuvre par la fonction système shmctl() ou par la définition d'un sémaphore pour chaque page de la ZMP. Il est aussi possible de déléguer à un autre processus la mission de contrôler les accès aux données des pages en gérant une liste de verrous attribués à chaque transaction. Avantage de la zone de mémoire partagée (ZMP) Par cette technique efficace, un processus accède à la ZMP dont il se doit de connaître la structure et cela, afin de pouvoir accéder aux données rangées dans cette zone. L’échange de données est possible sans faire de nombreux appels répétitifs au système (SVC). Lorsqu’un processus réalise son attachement par un premier SVC, il peut par la suite y accéder directement sans autre SVC et sans changement de contexte, puisqu’il utilise la même clé d’accès obtenue lors du premier SVC. Ayant accès à la ZMP, un processus peut accéder aux différentes structures internes au moyen d'une structure de répertoire créée au préalable par le processus qui a créé la ZMP. La ZMP est généralement paginée au cours de sa création de sorte que le processus qui accède aux pages en connaît la structure de page et peut accéder à son contenu par l'entremise d'un répertoire créé pour chaque page. S’il devait y avoir une ZMP pour chaque processus Exécuteur/Accesseur, la ZMP bloquerait une bonne partie de la RAM, avec l'apparition de problèmes concernant la synchronisation des accès. Finalement, bien que cette zone puisse être l’objet d’un échange (swap), il est préférable de la fixer (pin down) pour obtenir une meilleure performance. Une activité de pagination croissante est un indicateur pour le DBA que la mémoire RAM est insuffisante et que le SGBD peut manifester des symptômes de sous-performance. Queue de messages Cette technique permet l'échange de messages entre deux processus en les plaçant dans une queue.



36

Échange d'un message entre deux processus de la même machine Figure 2.12

Chaque message est ensuite repris par un des processus (modèle de la boîte postale). Les primitives SEND() et RECEIVE() utilisent les appels SVC de l'OS (System Supervisor Call) pour lire ou déposer des messages. Il y a donc à chaque écriture, une commutation de contexte. La queue est gérée par le noyau de l’OS (Unix SYSTEM V). Une fois paramétrée correctement, la queue peut accepter un tas de messages de longueur variable. Le processus qui transmet et celui qui reçoit n'ont pas nécessairement un parent commun. La figure 2.12 illustre la communication interprocessus utilisant la queue de messages. Le processus 3 place une requête SQL dans une queue particulière, par exemple la 4. Elle sera reprise par le processus 7 pour être exécutée et fournir les tuples de la BD. À chaque communication, il y a un appel SVC et un changement de contexte afin d’assurer la reprise et la poursuite correcte du programme courant. Cette méthode permet d'échanger des données après que le processus émetteur soit inactif ou disparu. L'utilisation d'une queue de messages fait appel aux fonctions suivantes :

a) Création d'une queue et son ouverture par la fonction : wid = msget(). b) Envoi ou réception d'un message : retour = msgsnd(0) et retour = msgrcv(). c) Contrôle et suppression de la queue par la fonction système msgctl().

Caractéristiques de la queue de messages L’usage d’un appel système SVC pour lire/écrire un message dans une queue génère un changement de contexte donc une charge I/O pour l’échange (swapping). La queue de messages demeure en RAM tant qu'elle n'est pas détruite par le processus qui l'a créée. En cas d'annulation de ce processus, la mémoire doit être libérée par un processus de service de l'OS. La taille d’un message doit être raisonnable, car elle est limitée par l’espace alloué à la queue.

Prise (socket) Cette technique a été implémentée en premier dans Unix BSD 4.x pour être ensuite graduellement adoptée par plusieurs systèmes d'exploitation.

Figure 2.12a

Espace OS

Application Socket client Socket serveur

(no-machine, no-port) (no-machine, no-port)

sd = 4 sd = 9

réseau

Couche TCP du logiciel de communication

queue 4

Processus 3 (pid = 3)

écrire msg( SVC)

Processus -7 (pid = 7)

OS



37

La particularité de cet IPC est la possibilité d’avoir une communication entre processus d’une même machine (famille AF_UNIX) ou de différentes machines distantes (famille de protocole PF_UNIX) pour l'IPC au moyen d'une communication basée sur la technologie TCP/IP. Association des deux extrémités identifiées par le couple (machine, port) mise en œuvre par le système d'exploitation ou par un logiciel de communication. Une prise (socket) est créée par un processus client au moyen de la fonction socket(): un numéro de prise (sd) et deux tampons internes à l'OS sont créés pour la lecture et l'écriture des messages. Le processus émetteur écrit dans une prise par une primitive write() comme il le fait pour un fichier. D'un autre point de vue du logiciel, la prise ou la socket est en quelque sorte une interface de programmation avec les fonctions de la librairie système de TCP/IP. Le descripteur d'une prise est inscrit dans la table des descripteurs du processus de l'application qui l'a créée. Du côté serveur, une prise est aussi créée et l'association technologique entre ces deux prises est établie en utilisant l'adresse Internet des machines et le numéro de port. La prise ou socket peut donc être vue comme un ensemble de primitives - socket(), listen(), bind(), ... d'interface avec l'OS pour implémenter l’échange les données entre deux machines distantes en masquant la couche transport qui sera implémentée par le noyau de l'OS via une technologie de communication appropriée. La communication distante entre deux processus est présumée implémentée par une technologie matérielle et se manifeste au niveau des clients et du serveur par une communication entre deux extrémités logiques appelées extrémités de connexion où chaque processus a accès à une socket. Le mécanisme de communication schématisé ci-dessous fait appel à des tampons-systèmes (buffer) créés de chaque côté par les primitives socket().

Port Un port est identifié par un numéro et associé à une queue de messages gérée par l'OS. Par exemple, une queue de messages associée au port 5 selon lue par un processus en référant au port numéro 5. Les fonctions disponibles pour l’implémentation d’une prise par un appel au système d'exploitation sont les suivantes (7).

Figure 2.12b

TCP-IP

RAM-OS

out

In

socket 7 read() write()

RAM-OS out

In

socket 9

accept() read() write()

socket 6

port 80

Serveur Client



38

a) Création d’une prise côté client : Le système OS construit une prise dans la table des descripteurs de l'application et retourne le numéro de la prise (fd_sock_c), i.e. du descripteur au client. Deux tampons systèmes y sont associés, un premier pour la sortie et lʹautre pour lʹentrée.

fd_sock_c = socket (domaine, type_de_socket, protocole); Exemple :

fd_sock_c = socket (AF_UNIX, TCP, AF_INET); où fd_sock_c est le descripteur (un entier) de la socket dans la table du processus client et qui est aussi gérée par lʹOS du client. Du côté serveur, la fonction exécutée pourrait être la suivante :

fd_sock_s = socket(domaine, type_de_socket, protocole); Dans le cas du serveur c'est une prise dite passive, car il ignore encore l'adresse IP du prochain client. Le processus serveur est à l'affût de tout message écrit dans une prise associée à un port particulier que le serveur va surveiller attentivement. b) Association de l’adresse du descripteur d’une prise, i.e. de point de communication cible (IP, port). • ‐ Pour le processus client • Lʹadresse IP et le port de la machine cible (soit celle du serveur ciblé) doivent être connus,

car ils sont fournis comme arguments dans lʹappel du connect() lancé par le client: •

res_c = connect(fd_sock_c,&sock_c,&sock_s,sizeof(sock_s)) où sock_s fournit le IP et le port du serveur et sock_c fournit le IP et le port local. La fonction peut aussi utiliser la struct prédéfinie sockaddr_in qui contient ces mêmes données. A ce moment, le client a fait connaître à son module local de TCP, le IP et le no du port qu'il entend utiliser pour transmettre et recevoir des informations à distance à partir du client au moyen d'appels read() et write(). • ‐ Pour le processus serveur Le serveur a créé une socket dès son lancement; il a utilisé la fonction socket(). Le point de communication (IP et no de port) est inscrit subséquemment par la fonction bind() lancée par le serveur

Res = bind(fd_sock_s, &adres_sock_s, sizeof(&sock_s)) A ce moment, le serveur a 2 tampons-systèmes: un pour recevoir (IN) et un autre pour transmettre (OUT). c) Envoi d’un message par le client au moyen de sa socket locale et en utilisant son descripteur de socket, c'est-à-dire l'indice de son entrée dans la table du processus :

sf = fdopen(fd_sock_c, "w"); --ouverture de la socket client write(sf, tamponout, 1024);

Si le client ferme la socket, il ne pourra pas recevoir de réponse du serveur, mais son message de sortie sera quand même transmis au point de communication cible, soit le serveur. d) Réception d’un message par un serveur: Listen () et Accept ()



39

La fonction Listen() place la prise du serveur dans son état passif et informe l'OS du serveur de mettre en file les x prochains messages reçus par la socket :

res = Listen(fd_sock_s,5); - 5 messages en queue La fonction Accept() extrait le prochain message de la socket (via son tampon IN) de la manière suivante : création d'une nouvelle socket (fd_sock_ns) où l'OS placera le message trouvé dans le tampon IN. En ce faisant, le serveur garde en disponibilité la socket initiale pour recevoir sans délai un autre message éventuellement d'un client différent. Il pourrait aussi faire un fork()pour traiter le message reçu.

rf = accept(fd_sock_s, NULL, NULL);

Figure 2.12c

Le serveur logiciel boucle à l'infini : do { if ((sd = accept()) == -1) exit(0); -- boucle do { ch = getc(sd); . . . close (fd_sock_ns);-- socket créée par le serveur pour avoir accès -- au contenu de la socket d'origine }; . . . } while (TRUE);

Socket devient active

Transmission des données par le serveur

sfd = socket()

res = bind()

sfd = socket()

processus serveurprocessus client

Association de l'adresse IP du serveur à la socket

Création de la socket serveur

res = listen() La socket devient passive et à l'écoute

connect()

res = accept()

read()

Lecture du message d'une socket particulière et création d'une nouvelle pour le serveur

Acquisition des données de la nouvelle socket write()

write()read()

close() close()



40

e) Fermeture d’une prise avec suppression et libération des tampons-systèmes :

result = close(fd_sock_ns)

La socket fd_sock_ns est fermée. Le serveur continue toujours à recevoir des messages par l'entremise de la socket d'origine (fd_socket_s) qui est toujours active. Ce mécanisme IPC est mis en oeuvre dans certaines composantes d’un SGBD, notamment dans le module de gestion du réseau qui est présent sur chaque station client (module d'écoute). La prise créée par le client utilise l'adresse IP du serveur distant pour établir la connexion. Le serveur connaîtra la provenance de la communication parce que la trame TCP comprend l'adresse IP du client ainsi que le numéro de port du client.

Structure de socket gérée par l'OS-Unix Figure 2.12d

Un module d'écoute au niveau du serveur permet de détecter une connexion TCP spécifiée par une adresse et un numéro de port prédéterminée. Comme nous l’avons décrit, à l'arrivée d’un message, le serveur en attente accepte immédiatement le message et effectue la création d'une nouvelle socket pour y copier le message reçu et cela, pour permettre au serveur de continuer à recevoir des messages (concurrence) sur la socket d'origine. Ce mécanisme fait appel à des fonctions de système pour établir la connexion, mais l'échange peut se faire directement par l'intermédiaire des fonctions TCP de la bibliothèque du logiciel de communication. Cette opération n'est pas très lourde en termes de commutations de contexte pour le serveur et le client. La connexion nécessaire pour la communication entre deux processus distants est considérée comme réalisée au plan technologique dès lors que le quintuplet suivant est déterminé et connu sur chaque site-client et serveur - voulant établir une communication :

{protocole, adresse_serveur, port_site_serveur, adresse_site_client, port_site_client}

Communication RPC entre deux processus (GABASSI, 1992) Le mécanisme de communication RPC (Remote Procedure Call) entre les processus distants est synchrone en mode connecté ou non.

Table des descripteurs ( 1 par processus)

Structure de données d'une socket

IN OUT

socket

famille : PF_INET service: SOCK_STREAM local IP remote IP

local port remote port



41

Figure 2.12d

Il permet de transmettre une information à un autre processus distant de façon similaire à un appel de procédure standard. Le processus appelant émet le RPC() et attend le résultat avant de poursuivre son activité au niveau de la station client. Le serveur reçoit l’appel et les arguments de la procédure, exécute la tâche sous-tendue par cet appel et retourne les résultats. La gestion de la synchronisation et du rendez-vous est prise en charge par les procédures du RPC. Cette technique se prête bien à l’exécution de l'ordre DML d’une application client, car cet ordre doit être exécuté entièrement avant que l’application poursuivre son traitement local. Le RPC est une couche par dessus la socket et constitue de ce fait une interface plus conviviale pour le développement des applications.

Appel dʹune procédure distante dans une architecture client‐serveur Ce mécanisme d'échange de données entre deux processus est de plus en plus utilisé. Le schéma de la figure 2.12d inspiré par celui présenté par Gray et Reuter (8) illustre les étapes d'exécution d'un appel RPC entre deux processus distants. L'encapsulage (packaging) peut être fait par un langage spécialisé comme le IDL (Interface Description Language) qui, une fois compilé donne un code que le serveur cible peut compiler pour générer un code exécutable. Chaque RPC est associé à un point de communication différent (IP, port) de sorte que le retour de l'appel RPC se fait sans ambiguïté. Avec tous ces mécanismes pour la communication, chaque appel à une fonction système génère une commutation de contexte qui n'est pas neutre en terme de charge sur le CPU. C'est souvent un facteur limitatif pour la performance d'un SGBD.

Architecture fonctionnelle générale du SGBD L’architecture générale (9) d’un SGBD a plusieurs variantes entre les deux configurations extrêmes ci-dessous. Le choix d’une variante dépend entre autres choses des ressources du serveur, du nombre de clients sur le réseau et de la nature des traitements effectués par les applications.

Application-RPC . . . sqlrpc('select nas, nom FROM Ouvrier')

Serveur : (désencapsulage de l'appel rpc) exécution de l'ordre (encapsulage du résultat) retour des données par le serveur au processus appelant) suite de l'application :

récupération de la réponse et calcul. . . .



42

Figure 2.13

Exécuteurs dédiés et un Accesseur Avec cette configuration, chaque client est associé à un serveur de processus dédié (Exécuteur) qui est chargé d'exécuter chaque ordre DML reçu de son client. Si aucun client ne transmet un ordre, le serveur est en attente dans la RAM. Les processus d'arrière plan du noyau du SGBD ont le même parent soit le compte DBA. Ils peuvent communiquer entre eux au moyen de tubes, de sockets et par une mémoire partagée. La socket a l'avantage de rendre le noyau portable dans un environnement réparti, tandis que la mémoire partagée privilégie la performance dans l'accès aux données. Avec l’architecture de la figure 2.13, les ordres qui arrivent d’une même station sont traités par le même serveur de processus (SP) dédié à ce client. Il pourra y avoir plusieurs Exécuteurs tant que leur nombre ne dépasse pas celui autorisé par le DBA via le paramètre système approprié. Une fois la réponse calculée, les tuples sont retournés à la station client par lʹexécuteur dédié via le lien TCP/IP entre le serveur Oracle et le client en question. Ce lien reste ouvert tant et aussi longtemps que lʹapplication ne ferme pas la base par un ordre Close. Cette architecture est caractérisée par un usager connecté servi par un exécuteur dédié. Si le nombre dʹusagers dépasse le nombre dʹexécuteurs autorisés, la connexion ne sera pas établie immédiatement. Cette configuration est pratique lorsque le nombre de clients est raisonnable et que les ressources informatiques sont largement disponibles. De plus, cette configuration ne comprend quʹun seul Accesseur chargé des accès aux pages, au service de tous les Exécuteurs.

Avantage Le serveur de processus est dédié à un client; il est en attente lorsque ce dernier effectue des calculs locaux. Il est mis en veilleuse après la fermeture de la communication avec le client. Il demeure inactif tant que le client l’est aussi.

Usager 1 Usager 2

TCP-IP

Usager 3

TCP-IPTCP-IP

Exécuteur Exécuteur Exécuteur

Serveur

Zone Mémoire Partagée

TCP-IP

Accesseur BD

Réseau



43

Inconvénients Le nombre dʹExécuteurs concurrents croît avec celui des usagers. La charge du répartiteur sʹaccroît dʹautant et cela peut se traduire par une diminution de la performance du SGBD, accompagnée dʹun encombrement plus important de la RAM. Cette architecture exige un ordinateur puissant, des disques rapides de préférence de type RAID et une mémoire RAM très importante, afin de réduire au minimum la pagination. En effet, la multiplication des Exécuteurs accapare la mémoire nécessaire pour assurer une bonne performance et minimiser les échanges de pages. Finalement, le partage des données par plusieurs Exécuteurs nécessite un contrôle centralisé des accès à la ZMP qui demeure unique.

Exécuteurs partagés avec un seul Accesseur Une autre configuration met en oeuvre une plus grande coopération entre quelques exécuteurs qui traitent les requêtes en provenance de plusieurs clients. Pour réaliser cette architecture, il faut un module de réponse pour chaque communication établie avec un poste client. C'est le module Dispatcher (le Di) qui joue ce rôle de prendre en note l'adresse du client, de recevoir la requête et de la formater correctement avant de l'insérer dans la queue associée à un Exécuteur. Ce dernier est aussi partagé entre plusieurs clients. Le rôle du répartiteur de l'OS sera de voir au partage du processeur entre les deux Exécuteurs en tenant compte de leur priorité respective. Bien entendu, un système à deux processeurs serait plus performant, car chacun aurait son propre Exécuteur.

Figure 2.14 Dans ce cas de figure, un seul Accesseur gère le transfert des pages de la zone ZMP. En effet, le travail de l’Accesseur est plus léger que celui de l’Exécuteur; il peut donc être partagé avec profit entre plusieurs Exécuteurs et cela, sans perte significative de performance. Pour isoler le client de l'Exécuteur, un processus intermédiaire (Di) est créé avec la mission de recevoir la requête d'un client et d'agir en son nom au niveau du serveur.

Exécuteur Exécuteur

Serveur

Zone Mémoire Partagée

TCP-IP

Accesseur

BD

Usager 1

TCP-IP

Usager 3

TCP-IP

Usager 2

TCP-IP

Réseau

Usager 3

TCP-IP

module D1

IN OUT

module D2

IN OUT



44

L'OS doit être multitâche et préemptif. Les Exécuteurs de même priorité obtiennent à tour de rôle le processeur pour faire progresser leur traitement jusqu’à l’épuisement de leur quanta de temps CPU. À ce moment, le répartiteur de l'OS passe le contrôle du CPU à un autre processus Exécuteur qui retire une requête dans une file d'entrée d'un client.

Avantages de cette architecture multiexécuteur partagé Le nombre d'Exécuteurs est plus petit que celui des clients puisqu'ils sont partagés. Ceci se traduit par un encombrement moindre de la RAM et donc une charge de swapping plus faible. Comme il y a moins de processus actifs, il y a aussi moins de commutations de contexte. Finalement, cette configuration se prête naturellement à l'exécution parallèle lorsqu'il y a plusieurs processeurs partageant la même mémoire RAM. L'inconvénient a trait au temps de réponse avec un système monoprocesseur. En effet, comme le client n'a pas d'Exécuteur dédié, le temps de réponse risque d'être parfois plus long si la transaction précédente ou concurrente est longue.

Ressources du logiciel client Chaque client doit avoir les ressources en logiciels nécessaires pour établir la communication et gérer les échanges. Avec plusieurs versions du système Oracle, il y a notamment le module SQLNET, le module SQLPlus et le Developer/2000. La gestion des échanges avec le serveur est faite par le module SQLNET de la station qui gère la communication réseau, notamment les couches inférieures du modèle OSI. L’exécution d'un ordre DML est sous la responsabilité du serveur de processus (Exécuteur) et, pour certains logiciels clients, le caractère procédural dans une requête complexe peut être pris en charge par un module du serveur capable d'exécuter un bloc PL/SQL.

Communication client‐SGBD avec Oracle L’architecture générale du système Oracle, (version 7.x) comporte plusieurs processus distincts pour le noyau, un processus de communication et une zone de mémoire partagée pour la communication interprocessus au sein de la machine serveur. Nous utiliserons cette architecture comme exemple de référence en précisant que d’autres sont toutefois possibles.

Configuration avec entrelacement de l’exécution (multithreading) Figure 2.15

client 1 client 2 Réseau

SGA

SQLNET

IN OUT

D3

DBWR

Serveur de processus (SP)

Processus de service

Serveur



45

Voici une vue plus détaillée de deux des modules :

Figure 2.16

La communication entre les processus est assurée par les mécanismes IPC connus : zone de mémoire commune (ZMP = SGA) et le RPC, soit l’appel de procédure distante. Du côté de l’usager, le processus client gère les échanges de données avec le noyau du SGBD qui s'exécute sur le serveur.

Connexion dʹun client La procédure générale est la suivante : a) Le client signale sa présence au Module d’Écoute du Réseau (MER ou Listener de SQLNET) au moyen de son adresse (IP, no-port). Après la connexion sur semande du client, ce dernier est averti de l’établissement de la connexion. b) Du côté du MER, il y a un répartiteur (dispatcher) qui reconnaît détecte la requête de connexion. Il y a retour de l’adresse d’écoute (adresse Ethernet) qui est valide pour la session en cours. c) Le client transmet la requête SQL au répartiteur qui la met, s'il y a lieu, en file d’attente avant son traitement par un serveur de processus (Exécuteur). d) En mode entrelacement d’exécution (multithreading), la queue est servie par un nombre limité de serveurs de processus (SP). S’il n’y a pas de serveur de processus disponible (Exécuteur) et si un autre peut être ou est autorisé par le DBA, il y aura création automatique d’un serveur de processus (SP) pour le client concerné. Le nombre de SP ne peut cependant pas dépasser une limite fixée par le DBA.

Fonctionnement schématique d’un SGBD Le fonctionnement général d’un SGBD est représenté à la figure 2.17. Le schéma illustre les principales fonctions généralement implémentées par un moteur de SGBD qui tourne sur un serveur dans une approche client/serveur.

Séquences des traitements Le traitement d'un ordre DML est réalisé complètement avant le passage à l'exécution d'un autre ordre DML du même programme client. La figure 2.18 présente schématiquement les enchaînements dans le traitement d'une requête ou d'un DML :

Processus de service:

RECO CKPT PMON ARCH LGWR SMON

BD + DD Journal

Serveur de Processus (SP)



46

1)Réception de lʹordre DML par lʹExécuteur en vue dʹune première étape dʹanalyse lexicographique. La transaction est ensuite dirigée vers le module dʹanalyse. 2) Vérification syntaxique et sémantique de l’ordre en se référant au dictionnaire de données (DD) afin de valider les attributs. Dans le cas du DDL, il peut y avoir de nouvelles entrées dans le dictionnaire.

Figure 2.17

Analyse lexicographique

Analyse syntaxique et sémantique Dictionnaire

de données

Traduction DML ou requête

ZMP

copie arbre réutilisable

Vérification des droits d'accès

Mapping de la requête schémas :conceptuel externe et interne

Optimiseur

Exécution de l'ordre : gestion de la transaction

BD Accesseur

page 2

RAM Zone de travail

Retour de la réponse au client via le dispatcher de processus

Journal externe

Journal interne

Journalisation



47

3) L’ordre est ensuite traduit pour construire un arbre d’exécution non optimisé qui est rangé dans la ZMP afin de pouvoir être réutilisé au besoin par dʹautres clients (cas des requêtes OLTP). Pour un SGBD relationnel, lʹarbre est constitué avec les opérateurs algébriques et les relations de base qui sont font l’objet de références au niveau des feuilles seulement. 4) Le module de contrôle des accès vérifie les droits d'accès de l’utilisateur pour les données requises par le calcul de la réponse. Il y a aussi accès au dictionnaire. 5) Chargement dans la ZMP des schémas de relation stockés dans le dictionnaire et de la liste des droits d'accès. 6) Pour une requête d’interrogation : remplacement des attributs de la vue par ceux du schéma conceptuel et référence au schéma actuel. 7) L'arbre de requête est optimisé afin d'obtenir une requête arborescente équivalente qui permet un calcul plus rapide de la réponse. Pour la mise à jour : Augmentation de l’arbre par une vérification des contraintes spécifiées dans le schéma. Les procédures sont chargées par le module de vérification de l’intégrité de la BD. 8) Génération du plan d’exécution optimisé, lequel est rangé dans la ZMP. 9) Exécution de chaque plan par le module de calcul. Il y a alors intervention du module de gestion transactionnelle incluant le répartiteur de transactions. L'Exécuteur doit à ce moment avoir toutes les informations nécessaires au calcul de la requête ou à l’exécution du DML. 10) Journalisation interne (redo log buffer) des seules transactions d’écriture et de mise à jour. 11) Lecture ou écriture des pages demandées. L’adresse de la 1re page est lue dans le dictionnaire de données. 12) Au besoin, le recouvrement de la base de données est fait avec le journal des transactions internes pour reconstituer la base de données dans un état cohérent antérieur. 13) La réponse est placée dans la queue de sortie et l'ouverture d'une socket permet le transfert des tuples au client. A l'exécution d'un COMMIT, les écritures de la transaction sont transférées du journal interne vers le journal externe (log file) créé sur le disque dur. Au contraire, avec le ROLLBACK, les modifications et les écritures effectuées sont défaites pour revenir à l'état de la base correspondant à celui du début de la transaction. Cette opération sous-tend l’écriture des anciennes valeurs.

Exemple d’un traitement d’un ordre de requête simple Le MRD de la base utilisée correspond à un MCD fort simple composé d'une seule relation appelée aussi une table et qui décrit les attributs des employés. La clé de cette table est le nas identifiée par un astérisque .



48

Employe (nas*, nom, ville, salaire, noProjet)

Schéma externe (vue de la BD) La vue relationnelle est définie sur la relation de base Employe comme étant une autre vision de la table, soit un sous-ensemble de ses attributs, au besoin différemment nommés :

Employev (matricule*,cite, noProjet) Cette vue Employev définit un mapping entre la table de base et la table virtuelle représentée par la vue. Attributs de la table Attributs de la vue nas ----> matricule (nom différent) nom ----> (attribut absent) ville ----> cite (nom différent) salaire ----> (attribut absent) noProjet ----> noProjet (idem)

La vue correspond à une projection relationnelle des attributs de Employe sur ceux de la vue. Cet opérateur sera étudié au chapitre de l’algèbre relationnelle. Cette vue est associée à l'application lors de l'ouverture de la base de données.

Approche ensembliste Le traitement de la requête ci-dessous n’est présenté qu'à titre d'illustration pour décrire le travail effectuée par le SGBD. La question : Trouver le matricule et la cité des employés assignés au projet 'P9' ? Sous forme d’un DML fictif, cette question pourrait s’écrire :

TROUVER Employev.matricule, Employev.cite AVEC Employev.noProjet = 'P9' Analyse lexicale et syntaxique : validation des mots clés et de la syntaxe de la requête :

TROUVER <liste-attributs> AVEC <prédicat>

Traduction de la requête par l’intégration d’un appel de procédure dans le langage hôte : CALL DMLSGBD

(dml, `matricule, cite’,’Employev’,noProjet = 'P9', reponse, codeRetour) où l'argument dml = 1 correspond à l'ordre TROUVER. La fonction DMLSGBD() assure notamment la communication avec le SGBD via une socket ou un RPC. Au niveau du serveur, il y aura consultation du dictionnaire de données (DD) pour vérifier si la vue utilisée par l’application autorise l’accès aux données (étape 3). Ensuite, il y a génération d'un arbre de requête par le SGBD intégrant la transposition des éléments de la vue pour tenir compte du schéma de la base (étape 4). Pour une requête



49

d’interrogation, il y a optimisation de l’arbre de requête pour privilégier l'usage de l'index existant sur l’attribut noProjet de la table Employe. Un plan d'exécution est préparé pour l'étape suivante. Génération du plan d’exécution de la mise à jour. Les adresses de la première page de l'index et des données sont dans le dictionnaire du SGBD. Ainsi, le système peut savoir quel index utiliser et où le trouver sur le disque :

... WHILE code_succes = SUCCES read index Employe avec noProjet = 'P9'— trouve no de page read page Employe avec l'adresse de la page (no de page) write Employe.nas, Employe.ville (+ mapping des noms d’attributs) Fin while.

8) Exécution du plan : l’accès aux fichiers sur disque est fait par l'Accesseur. 9) Dans le cas d'une modification de la table, il y a écriture dans le journal interne et éventuellement dans le journal externe (à la validation) des données avant et après modification. 10) La page est placée dans le tampon du moteur SGBD (la ZMP) avec un verrou approprié demandé par l'Exécuteur. Ce dernier garantit l'intégrité en refusant ou en autorisant le partage des données avec les autres utilisateurs.

Figure 2.18

11) Le module de recouvrement demeure inactif, car l’opération est présumée avoir été complétée correctement. 12) L'Exécuteur accède à la ZMP pour calculer la réponse et retourner les données à l’application conformément au schéma externe (s'il y a lieu, transposition des noms d'attribut). Remarque : Cette exécution sert seulement d’illustration générale et n’est pas nécessairement typique ni de l’interface entre une application et le SGBD, ni des techniques d’implémentation des SGBD qui varient d'un système à l'autre.

Employe

(1) Recherche du projet P9

(2) Extraction de nas et ville

Début

(3) Transposition : nas devient matricule et ville devient cite

(4) Affichage de la réponse



50

Gestion et répartition transactionnelle par lʹExécuteur Le module Calcul est responsable de construire la réponse et comprend, notamment dans les sous-modules de Gestion Transactionnelle (GT) et de Répartition Transactionnelle (RT) des actions de lecture et d'écriture sur le disque. On peut représenter ces deux derniers modules par le schéma général ci-dessous. Lors du traitement de deux ordres distincts en provenance de deux applications différentes, l'Exécuteur peut les traiter en concurrence par un métissage du traitement des deux transactions. Ainsi l'ordre r1 est une lecture de page appartenant à la transaction T1 et r2 une autre lecture associée à la transaction T2.

Figure 2.18a Le rôle du module GT est de voir à ce que chaque transaction se termine correctement, sinon la transaction en cause est défaite entièrement. Il prend note du début de chaque transaction et lancera au besoin le processus de recouvrement transactionnel (en utilisant le journal interne ou la trace transactionnelle) qui se traduit par défaire toutes les modifications effectuées par une transaction sur la BD, sans perturber les autres transactions en cours. Le rôle du Répartiteur Transactionnel (RT) est plus complexe; il est important pour assurer un meilleur temps de réponse pour l'exécution des diverses requêtes. En effet, l'exécution de chaque ordre SQL correspond à une séquence d'écritures et de lectures qui peut être exécutée intégralement pour fournir un temps de réponse qui pénalise les autres usagers, notamment lorsque la requête en cours est longue. La figure ci-dessus illustre ce problème avec deux transactions {r1, e1, r1,} et {r2, e2, r2}. La première correspond à une suite d'actions sur la base de données composée d’une lecture r1, suivie d'une écriture e1 et qui se termine par une simple lecture r1. Le répartiteur a pour mission d'intercaler les actions de lecture et d'écriture en provenance de différentes requêtes de manière à ce que leur exécution respective progresse en parallèle pour fournir plus rapidement une réponse partielle aux clients. Cet entrelacement des lectures et des écritures ne se fait pas arbitrairement. Il est créé par le répartiteur transactionnel de telle sorte que le résultat final soit identique à celui qu'il serait si l'exécution avait été séquentielle. Il faut remarquer que le SGBD fournit ainsi son propre répartiteur différent de celui de l'OS. Ce répartiteur transactionnel (RT) permet d'avoir une exécution multithreading plus fine des requêtes. De plus, l'accès aux données doit se faire tout en préservant l'intégrité de la base. Si les requêtes étaient exécutées de façon séquentielle, aucun verrouillage sur les données ne serait nécessaire, mais la performance serait médiocre. Par contre, avec l'action du RT, il devient parfois essentiel d'utiliser les verrous sur les données sous le contrôle exclusif du SGBD. Le système d'exploitation hôte n'intervient pas directement, sinon pour donner le contrôle au SGBD qui devrait normalement avoir une plus grande priorité que celle des autres processus qui cohabitent et se concurrencent pour le même CPU.

Train de lectures et écritures de pages :

Répartiteur Transactionnel

RT

c1, r1, e1, r1 c2, r2, e2, r2 c1, r1, c2, r2, e1, r1, e2, r2

T1 T2 séquence modifiée



51

Contenu général de la zone de mémoire partagée L’espace global de la ZMP sert au rangement de données de la base, des métadonnées du dictionnaire, des schémas de table et de certaines données concernant lʹexécution de chaque ordre DML ou de chaque requête.

Figure 2.19

Ces diverses listes sont au cœur du fonctionnement du moteur SGBD : a) Les pages de données de la base qui sont demandées (pages importées) par les requêtes et obtenues par le travail de l'Accesseur sur demande de l'Exécuteur. Au niveau de l'implémentation, cette zone peut être constituée de plusieurs segments physiques dont le contenu varie avec les activités en cours de réalisation par le SGBD. La ZMP est gérée dynamiquement; chaque liste occupe l'espace dont elle a besoin à un instant donné. L’espace ZMP logique est entièrement découpé en pages, lesquelles sont enchaînées pour former différentes listes de la ZMP. Cela est illustré sommairement par la figure 2.19 . b) Les pages où sont rangées les entrées du journal interne comprennent les images avant (AV) et après (AP), le numéro de transaction, l'adresse de la donnée (rowid) et le type de transaction. c) Les pages de métadonnées (dictionnaire) : schéma conceptuel (liste des Entitiés, des attributs,…), schéma interne et les schémas externes. d) Les pages de recouvrement (Rollback Segment) formant la liste LRT permettant de ranger la valeur avant (AV) de chaque donnée modifiée par une même transaction. Ces pages représentent une information aussi inscrite dans le journal interne (JI). Ces pages LRT permettent de recouvrer plus rapidement une transaction particulière sur l'ordre ROLLBACK. Le recouvrement est plus rapide avec le LRT qu'à partir du journal interne et surtout, ne perturbe pas l’exécution des autres transactions.

Zone partagée : Schéma conceptuel, externes, interne Packages et triggers Plans d'exécution réutilisables

Zones privées : PGA pour chaque application : P1 et P2

Processus P1code re retour

Processus P2 code retour

journal interne reprise transactionnelle (LRT)

pages importées pages validées

transactions actives (TA)

fin MRU

liste LRU

ZMP

liste DIRTY

Table des pages modifiées (TPM)

r : page en lecture m : page modifiée c : page cloué

no-trans. 5

m



52

e) Un espace PGA pour chaque application en cours de traitement par un processus serveur (SP). Cet espace contient une référence à l'ordre DML source, une référence à son plan d'exécution dans la cache partageable et le ou les premiers tuples de la réponse et une référence à la queue ou à la liste des tuples de la réponse constituée des tuples calculés par le module Exécuteur. Cette zone de la ZMP permet de poursuivre l'exécution du traitement d'une requête interrompue. f) Un espace pour stocker les triggers et les packages dont les pages peuvent être au besoin clouées dans la ZMP. g) Un espace partagé pour ranger l'arbre de requête source et sa version optimisée de manière à pouvoir le partager ou le réutiliser avec d'autres transactions. h) Dans certains cas, les files de sortie et la file d'entrée des réponses aux requêtes sont implantées dans la ZMP. i) Les pages de la table des transactions actives (TA) : avec le no de transaction et la dernière entrée dans le JI. Les pages rangées dans la ZMP sont insérées dans diverses listes leur conférant un statut particulier : • Page modifiée (m : liste LRU) : Page de la BD lue par lʹAccesseur et éventuellement modifiée

(incluant les ajouts) après leur transfert dans la ZMP. Ces pages modifiées sont validées lorsque toutes les transactions qui ont effectué des modifications ont exécuté un COMMIT. Elles sont non validées si au moins un COMMIT reste à faire pour confirmer un ou plusieurs changements dans la page. Ces pages seront transférées éventuellement dans la liste DIRTY en cours de recherche.

• Page clouée (c ) : une page de la base de données et qui est en cours dʹaccès en modification ou en écriture.

• Page libre (∗) : une page de la base de données entièrement validée ou libérée après lecture. En cas de besoin d'espace dans la ZMP, les pages de la liste Dirty sont en premier transférées sur le disque. Au besoin, les pages de la liste LRU peuvent aussi être stockées temporairement sur disque.

Lecture dʹune page de données de la base a) Lors du calcul d'une réponse, l'Exécuteur accède aux pages de données pour lire les tuples.

Cette opération comprend les étapes suivantes : b) Le serveur de processus, i.e. l'Exécuteur, cherche la page en premier dans la liste LRU et

ensuite dans la liste DIRTY de la ZMP. c) Dès que la page est trouvée, elle est normalement enchaînée vers la partie MRU de la liste

LRU, sauf si le traitement sous-tend un balayage complet d'une table. Dans ce cas, la page pourrait être gardée dans sa position courante dans la liste (LRU).

d) Si la page n’est pas trouvée dans la ZMP, l’exécuteur remplace une page de la liste LRU (partie LRU) par une autre obtenue de l'Accesseur. Si nécessaire, une page de la liste DIRTY sera écrite par l'Accesseur sur disque afin de faire de la place pour ranger de nouvelles pages. Dans le cas limite correspondant à une liste DIRTY vide et à une liste de pages



53

entièrement validées tout aussi vide, alors une page de la partie LRU sera placée sur disque même si elle n'est pas marquée r de manière à pouvoir importer la page demandée.

Modification dʹune page de données de la base Cette opération de mise à jour d'une donnée sous-tend les étapes suivantes : a) Recherche de la page dans les listes LRU; en cours de recherche, transfert des pages

modifiées antérieurement et validées par toutes les transactions : de la liste LRU vers la liste des pages DIRTY.

b) Si la page n’est pas trouvée, il y a un défaut de page. Il s'en suit une lecture de la page demandée sur le disque, suivie de son placement dans la liste LRU (généralement dans la partie MRU de la liste).

c) La page importée dans la ZMP en vue d'une modification est marquée comme étant clouée (pinned page). Après modification, elle sera marquée modifiée jusqu'au COMMIT. Si elle n'est que lue, la page est marquée r pour en permettre le remplacement éventuel.

d) Si la page demandée est trouvée dans la ZMP, elle est marquée clouée en mémoire (pinned page) et l'accès aux données est rendu possible. Par contre, si une page recherchée n'est pas trouvée dans la ZMP et que toutes les pages sont marquées clouées, l'Accesseur évacuera une page clouée pour la remplacer par la page demandée en provenance du disque. Cette page exportée demeure clouée. En cas de panne, le module de recouvrement utilisera les images AV pour défaire les modifications qui n'ont pas été validées par un COMMIT. Ces pages clouées exportées sur disque seront au besoin importées à nouveau dans la cache, dès lors qu'un Accesseur y réfère dans le calcul d'une requête. Pour éviter autant que possible cette évacuation d'une page clouée, il faut favoriser les transactions courtes dont la fin est marquée par l'exécution d'un ordre COMMIT.

Écriture de pages modifiées et validées sur disque par lʹAccesseur L'écriture d'une page de données sur disque est réalisée par l'Accesseur lorsqu’un des événements suivants est activé : ‐ Sur demande de lʹExécuteur ou lorsque la longueur de la liste DIRTY a atteint une valeur critique (lw). - Sur demande de l'Exécuteur, lorsque l'espace disponible est insuffisant et introuvable dans la ZMP. - Sur un dépassement du temps alloué (time-out), par exemple toutes les 2 secondes, l’écriture est demandée par l’Accesseur. - Lors d'un point de reprise (checkpoint), amorcé par le DBA ou par un changement de journal externe. - L’Accesseur peut écrire au besoin un bloc de pages de la liste des pages modifiées (DIRTY) dans une seule opération I/O. Cette écriture en vrac (pipeline) est plus rapide que celle d’une suite de pages exigeant une suite d’opérations consécutives. Les pages écrites en bloc doivent avoir des numéros de page contigus



54

2.3 Journalisation transactionnelle Après chaque modification d'un tuple dans une page de la ZMP, l'Exécuteur (avec Oracle, c'est le Serveur de processus (SP)) écrit certaines informations dans le journal interne (JI) : le numéro de transaction, la nature du DML, l'adresse de la donnée sous forme d'un rid (row identifier), l'heure, l'image avant de la donnée (AV) et l'image après (AP) en plus d'autres informations nécessaires pour gérer les listes du journal interne, notamment un numéro de séquence, JSN, qui identifie chaque entrée dans le journal. La structure du journal des transactions est propre à chaque SGBD. Les entrées du JI peuvent être écrites au besoin dans le JE de manière à libérer de l'espace dans le journal JI. Ex. Entrée type dans le journal interne :

Figure 2.19a Les entrées d'une même transaction peuvent être chaînées les unes aux autres par un pointeur arrière, le JSN_précédent. Ce pointeur permet de parcourir rapidement les entrées d'une transaction lorsque celle-ci fait une opération rollback transactionnelle. Le journal interne est organisé en une liste circulaire de sorte que les entrées finissent par être réutilisées par de nouvelles entrées après l'atteinte de la fin de la liste. Par conséquent, les entrées du JI n'ont pas besoin d'être effacées lors d'un COMMIT ou d'un CHECKPOINT. A titre indicatif, voici le contenu partiel et lisible d’un journal interne. En pratique, les entrées font l’objet d’un codage de sorte à compacter le journal interne. no : JSN précédent no transaction type page_id offset AV AP

1 nil Tr13 U 2 32 24 28 2 nil Tr24 U 6 34 23 9 3 2 Tr24 U 2 3 23 8 4 nil Tr2 D 8 29 4 12

page_id premier JSN compteur no_trans. dernier JSN

2 1 2 Tr13 1 6 1 Tr24 3 8 4 1 Tr2 5

Table des pages modifiées (TPM) avec compteur des modifications

Table des transactions actives (TA)

Journal interne et quelques tables de contrôle du SGBD Figure 2.19b

Chaque page modifiée par une transaction est inscrite dans la Table des Pages Modifiées (TPM) de la figure 2.19b comportant aussi un compteur cpt qui est augmenté après chaque mise à jour. Lors du commit de la transaction t124, les entrées du JI associées à cette transaction sont copiées dans le JE et le compteur cpt est décrémenté. Ainsi, lorsque le compteur est à 0, cela signifie que toutes les modifications de cette page sont validées et que la page pourrait être transférée dans la liste DIRTY, qui est celle qui fournit en priorité les pages à évacuer en cas de manque d'espace

numéro JSN précédent

numéro de la transaction

type de transaction

page_id offset (no de slot)

Image AV

Image AP

Chaque entrée a son numéro de journal (JSN) et les entrées d'une même transaction sont chaînées.



55

dans la ZMP (Défaut de page). La table TPM comprend la première entrée du journal interne correspondant à la modification de cette page; elle fournit le numéro de cette première transaction dans le journal interne à partir de laquelle il faudra refaire les mises à jour en cas de panne de système. N.B. chaque page peut aussi avoir dans son en-tête une petite liste de numéros uniques de transaction qui ont modifié les données de la page ou encore la dernière entrée du journal, soit le dernier_JSN qui a modifié cette page.

Calcul dʹune réponse L'Exécuteur chargé du calcul de la réponse a souvent à manipuler plusieurs tables de base, et parfois autant d'index, pour obtenir tous les tuples de la réponse (active set ou result set).

Figure 2.20 Ce calcul peut être fait en mémoire en rangeant les tuples dans des pages temporaires allouées en dehors de la ZMP ou encore en utilisant des fichiers de travail pour y loger les tuples intermédiaires. Au terme du calcul, l'Exécuteur connaît le nombre de tuples de la réponse. Il place un ou plusieurs tuples de celle-ci (1 par défaut) dans un CURSEUR implicite créé et associé au PGA de l'application. Il peut y avoir plusieurs curseurs implicites ouverts en même temps pour une même application. À l'exécution d'un ordre CLOSE, implicite ou explicite, cet espace de rangement temporaire est libéré et le curseur associé est supprimé. Le premier tuple est retourné immédiatement à l'application, tandis que les autres sont transmis seulement par l'exécution d'un ordre FETCH inséré dans l'application. La queue de sortie (et d'entrée) est implémentée dans la ZMP, elle pourrait être constituée d'une liste de pages contenant les tuples de la réponse. En sortie, une entrée dans la queue est constituée d'un pointeur, éventuellement en indirection par l'entremise du PGA, sur la liste des pages contenant la réponse

Validation dʹune transaction La validation d'une transaction T1 est lancée par l'ordre COMMIT. Tous les changements effectués par T1 deviennent alors visibles aux autres transactions concurrentes qui n'ont pas lu ces tuples auparavant et qui débuteront après la validation.

ZMP (SGA)

PGA de l'utilisateur U2

curseur C1

curseur C2

Pages temporaires pour les tuples de la réponse

Queue de sortie

1er tuple de la réponse



56

Les effets d’un COMMIT sont les suivants : a) La persistance des modifications réalisées par la transaction est assurée grâce à lʹécriture des entrées du journal interne vers le journal externe, et cela depuis le dernier commit inscrit dans le journal interne pour cette transaction. b) Les données modifiées deviennent visibles pour les autres transactions qui débutent après le temps t du Commit. Les modifications restent cependant invisibles aux transactions qui ont débuté avant le temps du Commit (cohérence de lectures répétitives) et qui ont peut être lu les mêmes tuples sans voir leurs modification ultérieures. Par contre, si ces mêmes tuples nʹont pas été lus par dʹautres transactions, ils deviennent alors visibles immédiatement.

c) Le Commit termine une transaction et en débute une autre avec un numéro différent et toujours unique. Après un Commit, il devient impossible de faire un retour arrière par un Rollback. Les données validées sont rendues persistantes.

Journalisation et reprise Une transaction est définie comme une unité logique de traitement sur la BD, définie par le traitement entre deux validations. Elle doit se réaliser entièrement ou pas du tout lorsque survient une panne ou une erreur en cours d’exécution. La panne peut être un arrêt de l'application client, la perte de l'instance du SGBD ou une défaillance sur un média. Actions sur BD Entrées dans le JI Sémantique T1 Début 13:45;T1;Début; début de T1 (V = 25) T1: Lire X->50 T1: Ecrire X->75 13:46;T1;E;X,50,75; modification de X par T1 T2 Début 13:48;T2;Début; début de T2 T2: Lire V-> 25 T2: Ecrire V->10 13:50;T2;E;V,25,10; modification de V par T2 T1: Lire V-> 25 valeur V au début de T1 T1: Lire Z-> 35 T2: COMMIT (msg de confirmation)

13:52;COMMIT; copie JI-> JE; nouvelle transaction T2

T1: Ecrire Z-> 10 13:53;T1;E,35,10; modification de V par T1 T2: Lire V–>10 lecture de V par T2 T2: Ecrire V->15 13 :55;T2;E,10,15; écriture de V par T2 ***panne d'instance ***********

Figure 2.20a Pour recouvrer un état stable et cohérent de la BD, il faut défaire une ou plusieurs transactions. Lorsqu'il s'agit de l'exécution d'un Rollback, la reprise transactionnelle n’implique que cette transaction. Pour une transaction particulière non encore validée, il faut défaire toutes les modifications qu'elle a effectuées depuis son début. Le rollback d'une transaction peut être fait à partir du journal interne, mais il est de préférence fait à partir des segments de rollback (liste LRT) implémentés dans certains SGBD avec les images AV d'une transaction. Le journal interne fournit l'image avant (AV) et après (AP) des données modifiées par chaque ordre DML des transactions. Il est donc possible de revenir en arrière avec les images avant et d'annuler toutes



57

les actions effectuées par une ou plusieurs transactions non validées avant que les applications transactionnelles soient relancées. Dans cet exemple, il y a lecture et ensuite écriture du tuple avec un champ X modifié pour avoir 50 comme nouvelle valeur. Deux transactions (T1 et T2) sont actives au moment de la panne générale. Après la panne du SGBD, la reprise est lancée en défaisant les modifications des deux transactions jusqu'à leur dernier Commit. Dans l'exemple de la figure 2.20a toutes les modifications effectuées par T1 seront annulées, tandis que seule la 2e transaction de T2 sera annulée. La reprise des applications avec de nouvelles données lues après le Commit permet de poursuivre les traitements sans perte de données et d'éviter les incohérences dans la base. Une autre propriété importante de la transaction est son isolement par rapport aux autres transactions. Dès qu'une transaction T1 débute, l'état de la base de données à cet instant apparaîtra à T1 comme étant invariant ou isolé par rapport aux actions des autres transactions concurrentes. En fait, une autre transaction T2 peut lire les données modifiées par T1, mais elle obtiendra la valeur validée au moment du début T2. En effet, le système peut toujours remettre temporairement une donnée dans son état antérieur stable (par exemple, avec les segments de rollback transactionnel) et cela, tant que la donnée n'est pas validée. Après la validation, la donnée devient visible aux autres transactions. En se comportant ainsi, le SGBD satisfait en cela l'isolement transactionnel des transactions. L'exemple de la figure 2.20a du journal interne hypothétique dont les entrées sont celles des deux transactions T1 et T2. Lorsque T1 effectue la lecture de V, elle obtient la valeur qui était validée au moment du début de la transaction T1 et non pas la valeur mise à jour par T2. Lorsque survient une panne d'instance suivie de la perte de la ZMP, les seules données disponibles pour récupérer sont celles du JE. Il faut donc défaire les modifications (UNDO) effectuées par les transactions non validées au moment de la panne, et faire en sorte, s'il y a lieu, que les modifications des transactions validées soient nécessairement toutes reconstituées et écrites sur disque (REDO). Les opérations d'insertion et de suppression sont traitées de façon similaire.

Procédure générale pour le recouvrement après une panne Il y a plusieurs phases dans le recouvrement ou reprise après une panne ou un arrêt imprévu du SGBD : 1‐ Le module de recouvrement fait une lecture inverse des entrées du JE (qui est généralement

un fichier séquentiel sur disque) pour faire une liste des transactions non validées TNV et une autre TV des transactions validées. Toutes les entrées du JE sont traitées jusquʹà la première, i.e. la plus ancienne. Sans une borne dʹarrêt spéciale, le retour sera fait jusquʹau début du journal externe!

2‐ Le ROLLBACK: Avec la liste TNV, les entrées du JE sont lues de la plus récente à la plus ancienne et cela, pour défaire avec lʹimage AV les modifications sur la base de données.

3‐ Le ROLL FORWARD : Avec la liste TV, le module refait en ordre chronologique les modifications sur la base de données avec lʹimage AP. Lʹopération REDO débute avec la plus ancienne entrée du JE.



58

Cette opération devient longue si le nombre d'entrées dans le JE est très important. Pour accélérer les recouvrements, il faudra notamment raccourcir le JE en posant une borne d'arrêt par l'exécution périodique d'un point de reprise générale (nommé CHECKPOINT) . Ce dernier consiste à établir à un moment approprié et sur disque un état cohérent de la BD. En ce faisant, une entrée de point de reprise générale est inscrite dans le JE et joue le rôle d'un butoir dans le retour arrière. La procédure de recouvrement traite les entrées du JE jusqu'au point de reprise générale ou à proximité de celui-ci dépendant de la procédure de checkpoint utilisée. En effet, si le checkpoint est du type synchronisé avec la ZMP, il pourrait être nécessaire de dépasser le checkpoint général pour défaire certaines transactions actives au moment où a eu lieu l'opération de CHECKPOINT.

Point de sauvegarde (PS) Il est possible pour une application de contrôler seulement la reprise de ses actions transactionnelles, particulièrement utile avec une transaction longue, en insérant des points de sauvegarde dans celle-ci. Un point de sauvegarde transactionnel B est généré par la clause SAVEPOINT B. Un point de sauvegarde (PS) d'une transaction est inscrit dans le JI et correspond à un point de retour en arrière d'une transaction contrôlé par l'application.

SET TRANSACTION READ WRITE; USE ROLLBACK SEGMENT rbk_seg1; -- recouvrement transactionnel while code = not OK Update Empl set salaire = 20 0000 where nom = 'Gagnon'; SAVEPOINT A; while code = not OK Insert Into Usine set capital = capital *2; SAVEPOINT B; … If Total_Cap > 100 000 then ROLLBACK TO SAVEPOINT A; else … end if; Commit T;

Figure 2.21

Si une transaction doit être défaite, elle pourrait l'être jusqu'à un de ses points de sauvegarde ou jusqu'au début de sa transaction. et cela, par la commande ROLLBACK TO B. Lors de cette opération, les modifications défaites sont autant d'actions sur la BD qui sont aussi inscrites dans le journal interne, pour éventuellement reprendre les opérations en cas de panne qui surviendrait durant ce retour arrière (Rollback). L’annulation des modifications faites par une transaction (figure 2.21) ne perturbe pas le fonctionnement des autres transactions, puisque celles-ci n’ont pas accès aux données modifiées par la première en raison de l'isolement des transactions. Dans plusieurs systèmes, le point de sauvegarde est inscrit dans le JI et en plus dans une page de la liste LRT de recouvrement propre à chaque transaction (Rollback Segment de Oracle) . Avec la commande ROLLBACK, les tuples modifiés avant le point de sauvegarde A sont conservés verrouillés, tandis que ceux insérés après ce point A sont annulés. Ces dernières données sont aussi déverrouillées et deviennent dès lors visibles aux autres transactions. Les données modifiées avant le point de



59

sauvegarde A demeurent encore invisibles aux autres transactions. Elles sont toutefois toujours disponibles pour la transaction en cours. Si la transaction est relativement courte, le retour en arrière pourra être fait à partir de la liste LRT (segment de rollback). Cette opération est donc rapide.

2.4 Procédure de checkpoint En cas de défaillance, le système doit être capable de recouvrer un état cohérent de la base de données et cela, après le redémarrage du SGBD. Il existe plusieurs approches de checkpoint, chacune ayant une procédure particulière de recouvrement qui se manifeste par un arrêt plus ou moins long des activités transactionnelles sur la BD. Nous en verrons deux : le checkpoint avec une cohérence au regard du Commit et un autre avec une cohérence par rapport à la ZMP.

Checkpoint synchronisé avec le Commit Cette procédure est définie pour synchroniser toutes les validations de transaction et cela afin d'assurer qu'au moment de la réalisation du checkpoint, aucune transaction n'était active et que la base de données était reconnue comme intègre à ce moment (figure 2.22).

Figure 2.22 Les étapes sont les suivantes: 1‐ Après le lancement du checkpoint par le DBA, aucune nouvelle transaction ne peut démarrer.

Le système attend la fin des transactions actives. 2‐ Les opérations transactionnelles en cours sur la base de données se poursuivent tant quʹil y a

une transaction non validée par un COMMIT. 3‐ Lors du checkpoint, les entrées du JI sont copiées dans le JE et toutes les pages de données

(LRU et celles de lʹextrémité MRU) modifiées sont aussi écrites sur disque. A ce moment toutes les pages ont été validées par un Commit puisque toutes les transactions sont validées.

4‐ A la fin de lʹécriture des pages modifiées par le module chargé du checkpoint, il y a inscription dʹune entrée de checkpoint dans le JE et la procédure se termine. Les activités transactionnelles peuvent alors reprendre.

CHKPT

commit

commit

panne

T1

T2

T3

temps



60

Recouvrement La procédure de recouvrement de base avec cette approche permet de revenir au dernier checkpoint pour avoir un état cohérent de la base. Ensuite, il suffit d'appliquer la procédure de reprise.

Checkpoint cohérent avec les données de la ZMP Ce type de checkpoint évite d'attendre celui des transactions actives en leur interdisant cependant, toute nouvelle opération sur la base de données pour la durée du checkpoint (figure 2.23). L'avantage de cette approche est d'affranchir le SGBD des transactions longues. Les étapes de cette approche sont les suivantes : 1‐ Après le début du checkpoint lancé par le DBA, aucune autre nouvelle transaction ne peut démarrer. 2‐ Les transactions actives ne sont ni arrêtées, ni en attente, mais elles ne peuvent plus temporairement effectuer des modifications sur la base. Lʹexécution dʹune transaction est donc interrompue momentanément.

Figure 2.23 3‐ Les entrées du journal JI sont copiées dans le JE et toutes les pages de données modifiées de la

ZMP sont aussi écrites sur disque pour en assurer la persistance. 4‐ À la fin du checkpoint, une entrée spéciale est faite dans le JE pour y inclure la liste des

transactions actives (TA) au début de la procédure de checkpoint.

Recouvrement La procédure de recouvrement débute par un ROLLBACK des transactions actives (TA) suivie par un ROLL FORWARD des transactions actives non validées. Les entrées du journal fournissent pour chaque donnée, la valeur avant (AV) et la valeur après (AP) : 1‐ Le journal est lu dans le lʹordre inverse pour détecter le plus récent checkpoint et obtenir la

liste des transactions actives (TA).

Checkpoint

Panne

T1

T2

T3

T4

temps



61

2‐ Au cours de cette lecture à rebours des entrées du JE, les transactions validées rencontrées sont notées dans une nouvelle liste temporaire TV.

3‐ Lorsque la lecture du JE atteint le CHECKPOINT, la liste TA est alors modifiée pour y enlever les transactions validées.

4‐ Toutes les transactions sont défaites par un ROLLBACK. Ce retour en arrière peut aller en amont du checkpoint et sʹarrête avec le début de la plus ancienne transaction parmi celles de la liste TA.

5‐ Il faut refaire les transactions de la liste TV à partir du checkpoint et cela, en ordre chronologique.

Voici un cas simple illustrant cette procédure de checkpoint avec cohérence des données : Traitements Entrée dans le JI Sémantique : T1: début 18:00;T1;D début de T1 T1: lire X -> 50 T1: écrire X-> 60 18:01;T1;E;X,50,60; T1: Commit 18:02;T1;COMMIT; fin de T1 et JI-> JE et

TA vide T2: début 18:03;T2;D; début de T2 T2: lire Z-> 5 T3: début 18:06;T3;D; début de T3 T3: lire G -> 20 T2: écrire Z->8 18:07;T2;E;Z,5,8; T4: début 18:09;T4;D; début de T4 T4: lire M-> 100 CKPT <--- 18:12;CKPT; tr.actives: T2, T3, T4 T3: écrire G -> 25 18:14;T3;E;G,20,25; T3: Commit 18:15;T3;COMMIT; fin de T3 et JI -> JE T4: lire G->25 T4: écrire G->35 18:16;T4;E;G,25,35; ** panne ** panne : T2,T4 actives D : début CKPT : checkpoint E : écrire TA : liste des transactions actives S : supprimer

Les entrées du journal externe (JE) sont les suivantes :

Entrées du JE phase ROLLBACK(1) phase ROLL FORWARD(2) 18:00;t1-D TA : vide 18:01;T1;E;X,50,60; 18:02;T1;COMMIT; 18:03;T2;D;** 18:06;T3;D;** Début avec T3 18:07;T2;E;Z,5,8;** T2: défaire Z->5 18:09;T4;D;** TA - TV = ( T2, T4) 18:12;CKPT;(T2,T3,T4) TA : T2, T3, T4 18:14;T3;E;G,20,25; T3: refaire G-> 25 18:15;T3;COMMIT; TV: T3 TV : T3 (début du rollback) (début du rollback) (début du roll forward)



62

Pour la procédure du ROLL FORWARD, il suffit, à partir du checkpoint, de refaire les transactions de la liste TV établie lors du rollback. Le retour en arrière est prolongé au delà du point de reprise pour défaire ainsi la transaction active la plus ancienne au moment du lancement du checkpoint. Cette procédure de point de reprise n'arrête pas les traitements locaux des applications. Si le recouvrement est fait avec un journal léger, le temps de reprise pourrait être à peine perceptible par les utilisateurs des applications. Avec l'une ou l'autre des deux procédures, une panne d'instance ou d'application peut être traitée sans l'intervention du DBA. Il en sera autrement pour une panne de média comme un disque. Dans ce cas, le DBA aura un rôle important dans la procédure de recouvrement pour identifier la copie de sécurité à réutiliser pour reconstruire la partie de la base qui était sur le disque en panne.

2.5 Architecture client/serveur L'architecture client/serveur (10) est un environnement qui localise les traitements de l'application sur les données du côté des utilisateurs. Cette architecture vient donc enrichir le fonctionnement général du SGBD en ajoutant des fonctions de traitement au niveau du client qui travaille désormais en coopération avec les fonctionnalités du SGBD. Le serveur offre, pour l’essentiel, les mêmes fonctionnalités que celles implémentées sur une machine centrale à savoir le traitement et l'exécution des ordres DML..

Figure 2.24 La répartition du traitement, et éventuellement des données, tend à maintenir la performance totale même lorsque le nombre de clients augmente. Le point d'inflexion dans la décroissance de la performance (figure 2.24) est reporté vers la droite par rapport à une configuration de traitement centralisé. Avec une approche centralisée, l’augmentation du nombre des terminaux se traduit à partir d'un certain point par une baisse de performance qui peut être compensée par le remplacement de la machine par une autre plus puissante ou par une deuxième machine centrale Une deuxième machine centrale apporte cependant sa propre charge au niveau de la gestion des processus qui annule en partie les effets escomptés au niveau de la performance générale pour les clients. Le traitement est cependant toujours effectué au niveau de la machine centrale. L'architecture client/serveur permet de maintenir plus facilement le niveau de performance en

architecture centralisée architecture client-

serveur

Temps de réponse

Nombre d'utilisateurs

Avec le même CPU



63

dépit de l'augmentation de la charge générale parce que les traitements sont transférés vers les clients. Le protocole de communication entre les machines du réseau est organisé en couches autonomes. Il devient donc possible de concevoir la communication simplement comme un échange entre deux couches de même niveau. Ceci permet de masquer toute modification des couches inférieures aux autres couches de l'architecture. Le modèle OSI favorise l’interopérabilité des systèmes en isolant les caractéristiques des diverses technologies dans des couches spécifiques et en normalisant les interfaces entre celles-ci. Ce modèle normalisé par l’ISO (figure 2.25)

Figure 2.25 se généralise chez les constructeurs et facilite grandement l’intégration des ressources informatiques du monde entier. Il est une des pierres d’assise des inforoutes qui visent à mailler la planète avec des nœuds de communication implémentés par des ordinateurs très divers et utilisant des environnements fort variés. Une configuration en réseau relie les stations par un bus Ethernet utilisant un lien de communication rapide. Ce lien permet des vitesses de l'ordre de 100 mégabits par seconde. Ce type de réseau est diffusant (broadcasting) et donc fait référence à une technologie multipoint. Chaque machine reçoit les messages, mais ne retient que ceux qui la concerne. Ce type de configuration est conforme au modèle ISO/OSI. À titre de rappel, voici les fonctions générales des différentes couches du modèle OSI :

Physique (1) Physique (1) Échange des impulsions

Site 1 Site 2

Application (7) Application (7) Désassemblage de la structure du message reçu

Présentation (6) Présentation (6) Encodage spécifique

Session (5) Session (5) Échange de transactions

Transport (4) Transport (4) Échange de messages ou fichiers

Réseau (3) Réseau (3) Échange de paquets

circuit virtuel (connecté)

Protocole de transport

Liaison (2) Liaison (2) Échange de trames



64

Couche physique (1) La couche physique transmet des bits sur le canal physique de transmission conformément à un standard reconnu (Exemples : RS-232C, RS-449). A ce niveau, la technologie utilisée prend à sa charge la transmission des impulsions électriques ou photoniques, la gestion des pertes de signaux et les reprises inévitables. La couche gère le protocole utilisé pour la transmission physique des bits.

Couche liaison de données (data link) (2) Le paquet d'octets reçu de la couche 3 est divisé en trames (frames). Chaque trame est complétée par une adresse d’origine et une adresse de destination et elle est encadrée par des marqueurs de début et de fin. Ce travail d'établissement de la liaison est réalisé par deux sous-couches : la sous-couche MAC pour s’assurer, par une écoute, que le réseau est libre et, au besoin, gérer les collisions, et la sous-couche LLC pour réguler le flux de transmission des trames et vérifier que la réception d’une trame soit sans parasite. Au besoin, la retransmission des trames est assurée par le LLC. En mode réception, les opérations inverses sont effectuées.

Couche réseau (3)

La couche réseau achemine les paquets obtenus par division du message reçu de la couche 4 vers un noeud du même réseau, incluant la passerelle. A l'inverse, les trames par la couche data link sont regroupées en paquets. Le rôle principal de cette couche est d'établir le routage (routing) selon un algorithme parmi les suivants : prédéterminé, calculé, par répertoire statique, par répertoire dynamique ou routage adapté. Dans un réseau commuté de lignes (ex. service avec connexion), le chemin complet de la source à la destination est déterminé et figé pour toute la session (Dans le cas d'un incident, un nouveau chemin est établi par reconfiguration du routage) . Cette approche connectée est souvent utilisé par les grands réseaux où le trafic justifie la monopolisation des circuits. La couche réseau mise au point dans le réseau ARPANET , appelée protocole Internet (IP), utilise une approche connectée. Dans cette couche, il y a contrôle de flux (avec lecture/écriture bloquantes). Par contre, dans un réseau commuté non connecté et par paquet (ou datagrammes), le chemin est déterminé pour chaque paquet de données (approche sans connexion). Le circuit virtuel est refait à chaque transmission d'un paquet. Cette couche prend donc à sa charge la conversion d'adresses et le routage entre réseaux. Dans un réseau de diffusion comme celui de l'Ethernet, toutes les trames sont diffusées et le rôle de cette couche réseau est plutôt limité.

Couche transport (4) La couche transport communique des messages (en provenanc de la couche 5) entre deux nœuds en utilisant, pour les couches inférieures, la technologie propre au réseau sur lequel sont connectées les machines source et cible. Pour ce faire, le message est divisé en paquets (packets) qui sont réassemblés à destination par la machine réceptrice pour reconstituer le message d'origine. C’est la couche TCP de ARPANET (Transport Control Protocol). Cette couche est généralement utilisée en conjonction avec le protocole IP pour obtenir le protocole appelé TCP/IP. Cette couche prend la relève de l'écriture des octets dans une socket de l'OS, pour générer plusieurs appels de transport sur le réseau. Ces opérations sont effectuées par le logiciel TCP/IP et sont donc masquées à l'application.



65

Couche session (5) La couche session gère l'échange intensif et bi-directionnel entre deux applications. Ce qui est échangé est une transaction composée de données en volume plus ou moins grand selon la nature de l'application. C'est le cas typique des divers services aux utilisateurs, notamment la connexion à distance (remote login), le transfert de fichier (ftp), le Telnet, le Gopher et le fureteur du web (browser). Ces utilitaires sont développés en utilisant les procédures d'interface de la couche session dont les paramètres réfèrent à la notion de transactions. Par exemple, la transaction avec ftp est une transaction longue constituée avec les données du fichier.

Couche présentation (6) Cette couche présente l’information transmise après transcodage approprié (Unicode vers ASCII vers EBCDIC ou vers ISO Latin-1), suivi du déchiffrement et du décompactage des données des transactions. La couche aura aussi un rôle important lorsque l'usage de l'UNICODE sera répandu ou deviendra un standard de facto (les caractères Unicode sont codés sur 16 bits).

Couche application (7) La couche application traite les protocoles particuliers comme la messagerie électronique, le protocole d’échange des données de laboratoire HL-7 (11) l’échange des données commerciales EDI et bientôt le commerce électronique. Ces protocoles définissent la structure des messages échangés en associant une sémantique à chaque champ ou élément du message. Entre deux stations, l'échange est réalisé par un circuit virtuel en ce sens qu'il s'appuie sur les fonctionnalités des couches inférieures.

Vue schématique du protocole IP Par définition, un protocole désigne un ensemble bien défini de règles et de conventions pour assurer la communication entre deux logiciels en exécution. Le protocole IP comporte une trame universelle (couche liaison) qui est indépendante des technologies des divers réseaux. Éclatement d'un message lors de l'échange entre deux ordinateurs Figure 2.25a

Structure dʹune trame technologique (frame) Les données structurées échangées entre deux points identifiés du réseau au moyen du protocole de liaison de données (data link) sont représentées par une trame contigue de bits. Cette trame est encapsulée conformément au protocole Internet. Le schéma général de la trame est donné ci-dessous.

Figure 2.25b

message 1 message 2 … message i

trame 1 trame 2 trame 3

paquet 1 paquet 2 … paquet j

Transaction

Suite de bits transformée en impulsions

en-tête de trame IPsource IP cible données de la trame Internet



66

La trame technologique est transmise d'une adresse IP source à une adresse IP cible (la destination). Chaque adresse IP ( appartenant à une des classes A, B, C) comporte une partie client (machine) et une partie réseau. Selon la classe de l'adresse (identifiée par les deux premiers bits), le nombre de bits alloués pour coder le réseau et la machine varie. Il devient possible de représenter quelques réseaux et de nombreuses machines jusqu'au cas de figure composé d'un grand nombre de réseaux et d'un petit nombre de machines. Cette trame de données peut être transmise à travers les réseaux hétérogènes à la condition qu'un GATEWAY puisse prendre en charge la transposition successive du format de la trame technologique d'origine vers celui des destinations du réseau auquel est connecté le GATEWAY. Chaque adresse dans une trame comporte deux parties spécifiées sur 32 bits : partie numéro du réseau et partie numéro de machine. Par contre, si le lien se fait entre deux réseaux de même nature, un BRIDGE ou un ROUTER (avec plus d'intelligence) est utilisé pour acheminer les paquets. Lorsque qu'une trame est destinée à une site au sein d'un même réseau, la couche IP du logiciel de télécommunication de la station demande à toutes les machines de ce réseau de faire connaître leur adresse physique (adresse de liaison). Une fois l'adresse physique connue et 'cachée' par la station émettrice, le message est transmis en utilisant la trame propre au réseau permettant ainsi de l'acheminer directement sans autre transposition. Si un message doit être transmis à une adresse IP hors du réseau d'origine, il est alors transmis en premier à sa passerelle (gateway) qui l'encapsule avec une trame technologique adéquate avant de l'acheminer à la passerelle ou au router suivant, dit de proximité.

Schéma général d’un réseau incluant différentes technologies Figure 2.25c

Sur réception de la trame par la passerelle suivante, celle-ci peut détecter si le message est arrivé au réseau de destination ou s'il doit être relayé à une autre passerelle. Les passerelles sont de véritables ordinateurs, donc des nœuds essentiels dans un réseau de communication à grande vitesse. Leur vitesse est critique, notamment lorsqu'il s'agit de réseaux ATM ou à bande large. Présentement, les vitesses de communication courantes sont de l'ordre de 100 mégabits par seconde. Une nouvelle technologie de Nortel-Canada (OC-192) offre des possibilités encore plus grande, soit de l'ordre du 10 gigabits par seconde. La technologie des communications se développe donc avec une vitesse effarante. Il est question de vitesse frôlant les Pétabits par seconde, soit un quadrillion de bits par seconde. Avec de telles vitesses, la téléphonie et la

segment réseau 1

50 ohms

gateway1 répéteur

machine 1

transceiver

machine 2

réseau 2 (autre technologie)

Router 2

réseau 3



67

télévision Internet sont maintenant des réalités. Il ne peut pas y avoir plus de 2.5 km entre deux points de segments différents sans faire intervenir un répétiteur. Le protocole IP est nécessaire puisque le transfert de la machine 1 à la machine 2 est effectué à travers des réseaux de technologie différente.

Fonctions générales du client dans lʹexploitation dʹune base de données La station cliente a une certaine puissance de traitement qui est mise à contribution pour des opérations locales (12 ): a) Gestion de l’interface et du traitement local des données transmises par le serveur. La

puissance de traitement local est alors exploitée adéquatement. b) Le client transmet chaque requête (ordre DML) au serveur pour des fins d’analyse et

d’exécution. c) Les fonctions d’un client sont exécutées sur un ordinateur qui est différent de celui du

serveur et plus adapté aux besoins locaux tout en assurant une meilleure extensibilité de l’architecture (scalabitlity).

2.6 SGBD ORACLE Le SGBD Oracle a une architecture générale constituée d'un ensemble de processus (tâches) et de structures de données complexes gérées en mémoire. Ces ressources partagées permettent l'accès concurrent aux données de la base avec une bonne performance pour le service aux clients. La mémoire partagée utilisée par le SGBD ORACLE est représentée sommairement par les entités SGA (System Global Area) et PGA (Program Global Area). L'espace PGA est utilisé par le serveur pour y loger les données propres à l'état de chaque processus client en cours de traitement. Le SGA est accessible à tous les processus de l'instance ORACLE. Cet espace doit être le plus grand possible (>500Mo) et comprend plusieurs zones structurées en listes de pages : a)La zone des pages de données et des pages temporaires pour loger les résultats intermédiaires. b) La zone des pages du journal interne (redo log buffers).

Figure 2.30

station client réseau Dx

Serveur de processus (Accesseur)

Serveur de processus (Accesseur)

DBWR

LGWR

Dx : processus créé pour gérer les échanges avec le client.



68

c) La zone contenant les packages et les triggers, sous forme de code exécutable et optimisé. Un package est chargé lors du premier appel d’une de ses procédures. d) La zone des pages pour les données privées des applications dites PGA. Par exemple, les constantes d’un ordre DML sont stockées dans une zone PGA privée qui est associée au curseur, tandis que l’ordre DML source et son plan dʹexécution sont placés dans un autre espace du SGA et dont lʹadresse est placée dans le curseur. Le curseur d’un ordre contient le nom de cet espace dans le SGA.

Coopération entre les processus du SGBD Oracle en mode multithreading ( MTS) Le système Oracle utilise deux catégories de processus, qualifiés respectivement d’utilisateur et de système. La première est créée lors d’une connexion établie avec le SGBD et cela à travers un réseau. Cette connexion est concrétisée, dans le cas d'une configuration avec des Exécuteurs partagés, par la création d'un processus Dx, créé du côté du serveur et particulier à un protocole de réseau (figure 2.30), dont le rôle est de voir aux échanges avec les clients incluant celui d'acheminer l’ordre DML au serveur de processus (SP). C'est aussi le processus Dx qui retourne la réponse à l'utilisateur. Ces processus Dx jouent en quelque sorte le rôle du client du côté du serveur. Si la connexion entre le serveur de processus et le client est rompue, alors le module Dx pour ce client devient orphelin et le module du SGBD chargé de libérer les ressources (PMON) pourra identifier le processus orphelin et le supprimer. Normalement, la connexion reste ouverte et active tant que l’application n’exécute pas un CLOSE (bd). Cette façon de faire est différente du WEB dont la communication est ouverte et fermée pour chaque requête GET ou POST. La deuxième catégorie comprend plusieurs processus qui coopèrent pour effectuer le calcul de la réponse de la requête :DBWR, LGWR, CKPT, SMON, PMON, ARCH, Dx et LCKx. Ces modules sont associés à un même processus Parent, soit celui correspondant au compte SYS. Nous discuterons brièvement du rôle de chacun.

Serveur de processus (SP) Ce serveur-logiciel est chargé de la communication avec les utilisateurs représentés au niveau du serveur par les processus Dxxx. C'est essentiellement un serveur multi-threads de requêtes en provenance des clients. Ce serveur-logiciel spécialisé est chargé de traduire l’ordre DML, de créer l’espace curseur privé et public pour loger les tuples de la réponse, de demander la lecture des pages de la BD au DBWR. Il a accès au SGA pour extraire les tuples et construire graduellement la réponse. Le client communique avec le SP via un ordre FETCH pour obtenir un ou plusieurs tuples placés au préalable dans un curseur. Généralement, la communication est maintenue jusqu'à la fermeture explicite de la connexion par le client. Instance du noyau du SGBD Oracle La notion d’instance Oracle est associée aux processus du logiciel et non à la base de données. Le couplage entre l'instance et la base donne lieu à un système de BD. Au démarrage du SGBD, un espace SGA est alloué et les processus d'arrière-plan sont lancés.



69

Figure 2.31 Cette combinaison espace mémoire et processus, appelée instance, est identifiée par un suffixe fourni par la variable système SID ou par le nom de la base de données rangé dans le fichier de paramètres INITsid.ORA. Dans un environnement réparti, chaque instance doit avoir un identificateur unique.

Figure 2.33 Une même base de données peut être rendue accessible à plusieurs instances, mais une instance n’a accès qu’à une seule base de données à la fois. Les techniques d’implémentation peuvent changer selon les versions afin de tirer profit des nouvelles architectures matérielles disponibles. Récemment, la commercialisation des serveurs multiprocesseurs a permis de mieux exploiter lʹarchitecture multiserveur du SGBD, qui peuvent utiliser le parallélisme dans le calcul des requêtes et offrir de meilleures performances. Les processus du SGBD Oracle exécutés en arrière-plan constituent l'instance du SGBD :

page i

page 1+ 1

page 1+2

DBWR Sur requête d'un autre module (ex. le SP)

fichiers

ZMP

En cas de saturation, réécriture circulaire dans le JE

ARCH

Fichier archive

page i

page i+ 1

page i+2

LGWR

Journal externe no 1

Journal externe no 2



70

DBWR (Database Writer) Ce processus effectue la lecture et lʹécriture des pages dans le SGA. Lors dʹune recherche amorcée par le serveur de processus (SP), un premier accès au dictionnaire fournit lʹadresse de la première page de chaque table et de chaque index disponible pour le calcul. A partir de ces index, lʹaccès aux pages de données est possible par la fonction INPUT(no‐page). La recherche dʹun emplacement pour lʹinsertion dʹune page de données dans le SGA par lʹAccesseur débute par le parcours de la liste LRU sur une certaine longueur (lw) après quoi, le DBWR évacue les pages DIRTY pour obtenir lʹespace nécessaire. La longueur de la liste à parcourir est déterminée par un paramètre système initialisé dans le fichier ORA.INIT. L’écriture dʹune page modifiée sur disque peut être nécessaire lorsque l’espace manque dans le SGA. Lʹopération peut se dérouler selon une politique LRU de remplacement des pages. Après la validation d’une transaction (par lʹordre COMMIT) les pages modifiées ne sont pas écrites immédiatement sur disque, tandis que les entrées du journal de la transaction validée sont transférées obligatoirement sur disque externe par le module LGWR. Lors de la création dʹune table il est possible de spécifier que chaque page lue de la table soit plutôt placée dans la partie LRU de la liste des pages (option CACHE de lʹordre CREATE TABLE). Ce placement favorise les balayages séquentiels successifs dʹune même table. Lʹécriture des pages sur disque par le DBWR est lancée sur les événements suivants : a‐ Activation dʹun checkpoint par le DBA ou par le changement du journal; b‐ La liste des pages modifiées présentes dans le SGA devient saturée; c‐ La recherche infructueuse dʹune page disponible pour une évacuation, i.e. marquée r; d‐ d-Un time‐out de x sec dʹinactivité du DBWR, i.e. au terme duquel le DBWR ( ex:: x = 3 sec)

amorcera lʹécriture des pages validées.

2‐ Le processus de journalisation, le LGWR (Log Writer) voit à transférer les entrées du journal interne appartement à une transaction sur le disque renfermant le journal externe (JE). Cette écriture est faite lors de la validation d’une transaction ou si l’espace du SGA alloué au journal interne vient à manquer. Lors dʹune validation transactionnelle, seules les entrées de celle‐ci sont écrites sur le journal externe. 3‐ CKPT (Checkpoint) À des intervalles réguliers ou lors de la saturation dʹun journal externe ou lors de la bascule vers le deuxième journal externe, le contenu du SGA est écrit sur disque, ce qui assure que les pages les plus actives (MRU) finissent par y être placées. En effet, avec une politique LRU, ces pages MRU pourraient demeurer indéfiniment dans le SGA. Pour éviter cette situation, le module CKPT signale au DBWR de vidanger périodiquement la liste LRU du SGA. Lors de cette opération, une estampille est écrite dans le journal externe et dans lʹen‐tête des fichiers modifiés suite à lʹécriture des pages transférées. Le module de checkpoint permet donc de vidanger toute la zone ZMP des données validées afin dʹobtenir une base de données cohérente.



71

Figure 2.34

4‐ SMON (System Monitor) et le recouvrement transactionnel. Processus chargé de recouvrer une instance Oracle au moment du démarrage par récupération et libération des segments (espaces) temporaires et les ressources du système OS . Cʹest aussi le module chargé de faire la reprise dʹune transaction avortée et cela à partir des segments de reprise (ROLLBACK SEGMENT). Lors de périodes de faibles activités, SMON réorganise lʹespace des tablespaces en défragmentant celui‐ci pour créer des extents de plus grande taille. 5 ‐PMON (Process Monitor) Processus chargé de surveiller les divers autres processus (du système et des usagers) et en cas dʹarrêt, de libérer les ressources acquises et, au besoin, les relancer. Si une application‐client est annulée, le module PMON est capable de détecter la disparition dʹun usager (processus orphelin) via celle du processus Dxxx et dʹeffectuer un rollback de la transaction en cours qui appartiendrait à ce client. 6‐ ARCH (Archiver) Processus chargé de copier le journal externe saturé vers un espace disque d’archivage. Cʹest la seule façon de garantir la base contre toute défaillance du média du journal externe ou dʹassurer la garde des pages du journal externe, qui seraient écrasées par la réutilisation cyclique de lʹespace du journal externe ( JE). 7‐ Dx (Dispatcher) Ce processus léger est créé lors de l’établissement de la communication d’un client avec le serveur de processus non dédié (SP). Il y aura autant de Dx que de stations connectées. Ce processus est chargé d’acheminer les ordres DML reçus de la station vers le SP et de retourner la réponse calculée par le serveur SP.

Journalisation et segment de recouvrement Lorsqu’un ordre DML d’une transaction est exécuté, les modifications qu’il effectue peuvent être d’abord placées dans un segment de rollback du SGA (image avant seulement). La modification est aussi placée dans un journal interne (JI) qui enregistre toutes les modifications faites par la transaction (images AV et AP) ainsi que celles des autres transactions. Si l’ordre DML ne peut pas être complété correctement ou si l'utilisateur effectue volontairement un retour en arrière (Rollback), le retour en arrière se fait à partir de ces segments de reprise (segment Rollback) piloté par le processus SMON. C'est ainsi que le système garantit l’atomicité

fichiers fichiers

CKPT

page i page i+ 1

page i+2

page …

JI



72

de chaque ordre DML. Ce retour est plus rapide parce que les segments de rollback d'une transaction ne contiennent que les modifications d'une transaction.

Fichiers de contrôle L'instance SGBD utilise deux fichiers de contrôle pour accéder aux différents espaces de données critiques gérés par le noyau SGBD. Au lancement, l'instance n'a pas accès au dictionnaire, car elle ne connaît pas l'emplacement physique de la métabase (dictionnaire). C'est grâce aux fichiers de contrôle que le SGBD peut connaître la localisation physique des divers fichiers, notamment ceux du dictionnaire et des journaux de recouvrement. Tout changement aux ressources physiques de la base de données comme l'ajout d'un fichier, est noté dans le fichier de contrôle par le SGBD. Ces fichiers de contrôle sont essentiels pour lancer et réussir une opération de reprise et ils sont répliqués sur plusieurs disques et tous sont maintenus à jour automatiquement par le SGBD.

2.7 Performance des logiciels SGBD La mesure de la performance du traitement des transactions par un SGBD (en mode OLTP) est complexe en raison des nombreux échanges qui interviennent entre les processus et des diverses technologies qui sont mises en oeuvre dans l'implémentation d'un tel logiciel. Avec une telle complexité, il devient pratiquement impossible d'évaluer la performance du logiciel par la seule analyse des différentes techniques mises en oeuvre. Il faut faire appel aux bancs d'essai. Ces mesures empiriques sont significatives dans la mesure où les bancs d'essai ont des structures équivalentes, qu'un même protocole de test est utilisé et que l'environnement matériel est comparable. Pour les bases de données relationnelles, le groupe Transaction Processing Performance Council (composé de près de 40 sociétés et institutions, TPC) a élaboré un banc d'essai connu sous le nom de TPC-A destiné à mesurer la performance des SGBD relationnels (OLTP) capables de fournir un rendement de l'ordre de 100 transactions par seconde (TPS). Les résultats de ces mesures sont publiées et doivent être utilisés selon un code d'éthique formulé par les membres du TPC. En effet, la concurrence entre les manufacturiers de SGBD est telle que les résultats du TPC-A peuvent devenir un argument de vente pour gagner de nouveaux marchés. Les écarts de conduites sont dénoncés et les délinquants parfois sanctionnés par des rappels à l'ordre (sanction en 3 étapes) et éventuellement par des pénalités financières.

Structure de la base de données du test TPC‐A La base de données est composée de 4 tables relationnelles exploitées par un grand nombre de transactions (1000) concurrentes dont chacune comprend 3 mises à jour et une insertion. Voici la composition de la base de données et de la transaction type utilisée pour les mesures.

Table nb tuples taille du tuple clé primaire Compte 1 000 000 100 octets noCompte Guichet 1000 100 octets noGuichet Succursale 100 100 octets noSuc Journal variable 50 octets noCompte, estampille

Figure 2.35



73

Transaction type La transaction ci-dessous est exécutée sans erreur par 1000 transactions concurrentes : Les valeurs lues par les transactions ont été générées aléatoirement de sorte que la probabilité de mise à jour d'un tuple quelconque soit constante pour le test.

/* read au guichet no-cpt, noSuc, noGuic, montant */ Set Transaction READ WRITE—début de la transaction UPDATE Compte set solde = solde + montant WHERE no-compte = noCpt INSERT into Journal values

(noCpt, noGuichet, noSuc, montant, estampille UPDATE Guichet set Guichet.solde = Guichet.solde + montant UPDATE Succursale set Succursale.solde = Succursale.solde + montant COMMIT /* write 200 octets au guichet */

Contraintes opérationnelles Le temps d'un cycle (TC) est composé du temps de réponse (TR) plus le temps de réflexion de l'utilisateur (TU).

‐‐‐ TC = TR + TU Le TC doit être en moyenne d'environ 10 sec. En outre, 90% des transactions doivent avoir un TR <= 2 sec, et le TU en moyenne égale ou plus grand que 8 sec. Voici un exemple de résultats du banc d'essai TPC-A pour quelques SGBD relationnel.

SGBD Matériel TPS Coût/TPS $ date ORACLE7 Vax cluster 425 16 326 5-92 Unify 2000 Pyramid Server 468 5 971 3-92 Informix 4.1.0 IBM RISC 6000/970 110 2789 7-92 SYBASE Symmetry 2000/250 173 2770 3-92

La mesure de la performance est exprimée par le nombre de transactions par seconde (TPS) qui traduit une puissance transactionnelle brute sans égard aux coûts du matériel. Le facteur coût regroupe les investissements, notamment pour la machine et les disques. Il existe une certaine relation proportionnelle entre le TPS et le ratio Coût/TPS. L'augmentation de la performance TPS entraîne celle du coût par transaction. Ainsi, un même SGBD pourrait avoir une performance bonifiée avec un facteur Coût/TPS. Pour un même ratio coût/TPS, les différences de rendement peuvent être dues à l'implémentation des fonctionnalités du SGBD ou à la configuration matérielle utilisée.

Évolution des bancs dʹessai du TPC Les bancs TPC-A et TPC-B ont été abandonnés en décembre 95 et remplacés par le TPC-C et TPC-E. Le TPC-D a été développé pour mesurer la performance relative des SGBD relationnels en mode décisionnel (Data Warehouse ou Entrepôt de données) et cela pour des tailles de base de données différentes (scaling factor).



74

TPC-D Paramètres @100GB IBM DB2 Teradata delta Throughput 207 217 5% QphD 133 192 44% prix/QphD 33 640 28 272 16%

De nouveaux paramètres sont utilisés (ex.: QphD@100GB, Query per hour qui est calculé en utilisant une moyenne géométrique) et un nouvel ensemble de questions et de transactions a été formulé. On peut consulter les résultats des tests en consultant le site http: //www.tpc.org/.

Sommaire L’évolution des modèles gérés par les SGBD renforce l’indépendance logique et physique des applications et des données. L’importance grandissante des architectures client/serveur modifie la répartition des tâches de traitement en laissant une plus grande place au site client qui pourra maintenant mettre à profit sa capacité locale de traitement et de stockage. En dépit de ce changement d’architecture, le rôle critique dans la gestion des données est toujours assuré par un processeur principal appelé le serveur qui doit gérer adéquatement le multitâche incontournable, l’entrelacement de données (multithreading) devenu essentiel, l’écoute du réseau, synchroniser des actions sur la base de données et assurer la transmission des résultats vers le client. En allégeant la charge du SGBD par l'approche client/serveur, on obtient un gain intéressant dans le rapport performance/prix. Toutefois, cette approche engendre de nouvelles activités à savoir une gestion de réseau et une autre pour la base de données qui deviennent plus importantes lorsque les clients sont distants. Le serveur multiprocesseur augmentera la puissance nette des traitements en divisant la tâche et en la répartissant parmi deux ou quatre processeurs. Avec de bons algorithmes de synchronisation des traitements parallèles, des mémoires RAM et cache de taille inégalée jusqu’ici et des disques RAID, les nouveaux serveurs s’attaquent au défi d’atteindre des performances transactionnelles de l’ordre de plus de 800 TPS (voire même 1000 TPS). Ce niveau de performance exigeant une fraction de l’investissement jusqu’ici nécessaire pour les machines centrales de grande puissance. L’ère des base de données sur les grosses machines n’est pas nécessairement terminée, mais son marché a été modifié considérablement et ramené principalement aux bases de données de très grande taille pour des applications dont les contraintes temporelles et la charge de traitement imposées dépassent encore de beaucoup le potentiel des stations de travail. Lʹévolution de la technologie viendra encore certainement modifier ces configurations. Exercices 1‐ Supposez que la contrainte ci‐dessous soit définie sur la base de données. Identifiez les transactions qui se termineront toujours correctement et celles qui peuvent se terminer incorrectement en entourant le commit dʹune transaction qui se termine correctement. Justifiez chaque réponse pour chaque transaction. Les transactions débutent et se terminent dans lʹordre



75

croissant de leur numéro : T1< T2 < T3. Une transaction est exécutée entièrement avant que la suivante débute. La contrainte définie sur les données : 0 < X < Y. Au début la base de données est cohérente.

set transaction t1 set transaction T2 set transaction t3 lire X lire X lire X lire Y lire Y lire Y X = X + Y X = Y + 1 Y = X + Y update X update X update Y Y = X + Y Y = X + 1 X = X + Y update Y update Y update X commit commit commit

2‐ Complétez le journal interne ci‐dessous pour lʹexécution de la transaction t4. Chaque

SAVEPOINT donne lieu à une entrée SVPT dans le JI et chaque ROLLBACK à un ou plusieurs changements sur la BD. La valeur initiale de X est 5 et celle de Y est 7.

Transaction sur client Journal - Interne ordre-DML AV AP set transaction t4 lire X lire Y X = X + Y SAVEPOINT S1 update X ROLLBACK TO S1 Y = X + Y update Y commit

Références Chapitre 2 1 CODD, E. F., Data Models in Database Management, Proceedings Workshop on Data Abstraction, Databases and Conceptual Modeling, ACM SIGMOD v. 11, no 2, 1981. 2 GARZOTTO, F., PAOLINI, P., SCHWABE, D., HDM: A model‐based approach to hypertext application design , ACM Transactions of Office Information System, v. 11, no 1, 1993, p. 1‐26. 3 HALASZ, F. G., SCHWARTZ, M., The DEXTER hypertext reference model, Communications of the ACM, v. 37, no 2, 1994, p. 30‐39. 4 SCHNASE, J. L., LEGGETT, J. J., HICKS, D. L., SZABO, D. L., Semantic data modeling of hypermedia associations , ACM Transactions of Information System, v. 11, no 1, 1993, p. 27‐50. 5 STOTTS, P. D., FURUTA, R., Programmable Browsing Semantics in TREILLIS, In Hypertext ʹ89 Proceedings, ACM Press, NY, 1989, p. 27‐42.



76

6 GAMACHE, A., Base de données réseau VAX/DBMS, Librairie des Presses de l’Université Laval, Québec, 1993, 100 p. 7 COMER D.E., STEVENS D. L., Internet Working with TCP/IP, Client/Server Programming and Applications, volume 3, p.53 8 GRAY, J. REUTER A., Transaction Processing : Concepts and Techniques, Morgan Kaufmann Publishers, 1993, ISBN 1‐55860‐190‐2 9 ULKA, R., Unix Database Management Systems, Yourdon Press, Computing Series,1990, ISBN 0‐13‐945593‐0. 10 SMINE, Hatem, ORACLE Architecture, Administration et Optimisation, Eyrolles, 1993, ISBN 2‐212‐68016. 11 HL‐7, Health Level Seven, version 2.1, Chicago, Illinois, Heath Level Seven Inc, 1990. 12 MIRANDA, S., RUOLS, A., Client‐serveur : concepts, moteurs SQL et architectures parallèles, Eyrolles, 1994, ISBN 2‐212‐08816‐7.

Chapitre 3 Architecture générale du logiciel SGBD


Chapitre 3 Modèle conceptuel de données

Dans ce chapitre nous allons étudier la modélisation des données et le modèle conceptuel qui en découle en excluant les opérations sur les données qui ne seront pas incluses à ce stade du design. Le formalisme Entité/Association est principalement utilisé pour les exemples. Par contre, les notions de UML pour le diagramme des classes seront brièvement présentées et mis en application dans plusieurs exemples. 3.1 Modélisation Entité/Association (E/A) et UML Le modèle Entité/Association (E/A ou E/R) est un modèle de représentation à caractère sémantique1

2 permettant de spécifier une partie de la réalité au moyen dʹentités et dʹassociations

décrites par les données. Le modèle de données doit donc représenter le mieux possible la réalité, se concentrant sur l’essentiel afin de faciliter la conception (design) de la base de données. Un modèle est aussi un outil de communication avec les utilisateurs engagés, comme spécialistes du domaine de lʹapplication, dans le processus de conception. Cette notation est de plus en plus remplacée par celle du diagramme de classe de UML qui est un composant du Unified Modeling Language pour le développement des systèmes orientés objets. Rôle essentiel du modèle conceptuel (MCD) Le MCD spécifie la structure de la base de données indépendamment du logiciel SGBD utilisé pour l’exploitation des données3 tout en étant la représentation la plus fidèle possible de la réalité organisationnelle telle que perçue à travers les données. Il y a plusieurs modèles conceptuels de données qui ont été développés au cours des années. Nous allons au début étudier très brièvement le modèle Entité/Association (E/A) et par la suite nous verrons une variante enrichie de cette approche qui ouvre la voie à la modélisation orientée objet4. En guise d’introduction, considérons un exemple simple avec les comptes bancaires et leurs clients propriétaires. Chaque instance est définie par des attributs et est caractérisée par une clé ou un identifiant : le noCompte pour lʹEntité CompteBancaire et le matricule pour celle de Client. Cet identifiant caractérise par sa valeur une seule entité parmi toutes celles présentes dans la BD. Il existe des associations entre les entités qui représentent des informations qui sont aussi à modéliser. Par exemple, la propriété de chaque compte bancaire est représentée par une association. Dans notre exemple, les associations particulières sont illustrées par une ligne dans la figure 3.1.

Instances de l’association et des classes Figure 3.1

Instances (objets) de CompteBancaire : c-100, montcalm, 250.00 c-200, desjardins, 350.00 c-300, plateau, 450.00 c‐400, laurier, 550.00

Instances (objets) de Client : n10, Bérubé, des-roses, Québec n20, Cousin, des-lilas, Lévis n30, Vézina, des-saules, Montréal

a1a2

a3

Chapitre 3 Modèle conceptuel


78

Avec cet exemple, nous avons donc : ‐ Un ensemble de comptes bancaires (les instances) : {c‐100, c‐200, c‐300, c‐400} où c‐100 est une valeur de la clé, c’est‐à‐dire une valeur dʹattribut qui identifie chaque compte bancaire de façon non ambiguë. Lʹobjet est défini complètement par plusieurs attributs comme le montre la première instance de CompteBancaire. L’ensemble des instances actuelles et futures est représenté par la classe CompteBancaire. La structure logique de l’Entité CompteBancaire est définie par 3 attributs : noCompte, succursale et solde du compte. On appelle cette structure logique le type de l’Entité. ‐ Un ensemble de personnes inscrites comme des clients : chacune est distincte des autres par la valeur de sa clé : n10 désigne un seul client dans l’ensemble. La structure de la classe Client ou son type comprend quatre attributs : matricule, nom, rue, ville. ‐ Un ensemble dʹassociations : {a1, a2, a3} où chaque association particulière entre les entités est identifiée par un libellé pour distinguer les unes des autres. Il est à remarquer que certaines associations mettent en liaison un objet seulement de chaque sorte, tandis que dʹautres en font intervenir plusieurs. Exemple : Lʹassociation a3 est définie avec l’objet n30 en association avec 2 comptes bancaire, c300 et c‐400. Différence entre entité, Entité, objet et classe Le concept d'entité (avec un 'e' minuscule) correspond en E/A à la représentation par les données d'un objet concret ou abstrait du monde réel. Une entité est dotée d’une existence autonome et est modélisée par des attributs valués. Une entité a plusieurs synonymes selon la méthodologie utilisée : occurrence d'Individu ou d'instance de classe ou encore mieux par la notion d’objet conceptuel. Ce terme est privilégié dans la modélisation UML. Si l'on désire modéliser plusieurs occurrences en soulignant leur caractère générique basé sur le partage d’une même structure, nous utiliserons la notion d'Entité (avec un 'E' majuscule). Toutefois, comme le langage parlé ne peut pas distinguer entre Entité et entité, nous les remplacerons respectivement par les notions de classe et d’objet sans inclure pour l’instant aucune méthode ou opération. Cependant avec UML, la classe inclura la structure et l’interface pour représenter les objets de même structure. Attribut La description d’une Entité (devenant par la suite une classe dans la méthodologie objet) est faite par ses propriétés appelées maintenant <attribut>. Chaque attribut est associé à une valeur faisant partie d’un ensemble particulier de valeurs appelé domaine de cet attribut. Voici un exemple dʹune Entité Ouvrier (classe) dont la structure est défini par ses attributs typés :

Classe Ouvrier Type de la donnée Une entité (instance/objet) matricule char(4) ....................................... 123B nom varchar(40).................................. Boucher ville varchar(50).................................. Montréal dateEmbauche Date.............................................. 12-10-2000

Figure 3.2



79

Modéliser avec une Classe ou un attribut ?

La première difficulté rencontrée lors de la conception du modèle est d’établir ce qui est représenté respectivement par une Entité et par un attribut. En gros, le bon sens et l’expérience viennent à la rescousse de l’absence de critères formels pour faire ce choix. L’existence autonome d’une valeur peut aider : Soit un attribut A qui définit une classe C ou un attribut rattaché à une association R. Le domaine de l'attribut A correspondant à dom(A). Si toutes les entités ou tous les objets qui utilisent une valeur ai du dom(A) sont supprimés de la classe C, alors la valeur ai n’existe plus dans la structure du système d’information5 :

si ce ai∈ dom(A) ne présente plus d’intérêt pour l’entreprise, alors A n’est qu’un attribut; si ce ai ∈ dom(A) a toujours un sens pour l’organisation, même après la suppression du

dernier objet où ai était utilisé, alors ai devrait être traitée comme un objet de classe. Si ai est une valeur de l’attribut A de type multivalué ou composé et que le SGBD n'offre pas ce type au niveau de l'implémentation, il faut transformer l'attribut A en une classe et créer une nouvelle association avec la classe source de A. Par exemple, la modélisation d’une œuvre d’art est faite par diverses caractéristiques comme l’année, le style, le numéro de l’œuvre, le thème, … Qu’en est‐il du peintre ? Est‐il un attribut de l’œuvre ou doit‐il être représenté comme un objet associé à l’œuvre. S’il est représenté par un attribut, l’information fournie est limitée à celle de son nom. Par contre, s’il est représenté comme un objet il devient possible de fournir une information plus complète sur le peintre : date et lieu de naissance, adresse de son atelier, âge au moment de la réalisation de l’œuvre, … Toutes ces informations ne peuvent pas être incluses dans celle de l’œuvre parce qu’elles sont pertinentes au peintre et non à l’œuvre. En outre, si ces informations sont incluses dans la représentation d’une œuvre, il y a insertion de redondance en plus de perdre éventuellement ces informations sur le peintre si toutes les œuvres de ce dernier sont vendues.

Formalisme

L’utilisation du modèle conceptuel repose sur le besoin de raisonner au niveau générique plutôt qu’au niveau des instances et de leurs associations qui sont souvent très nombreuses. Plusieurs formalismes sont proposés, tous sont des variantes du formalisme Entité/Association de lʹaméricain Peter CHEN. Chaque variante (Merise, UML, OMT, …) repose sur à peu près les mêmes notions, mais utilise une représentation graphique particulière. Le premier modèle de la figure 3.3 est un MCD fort simple pour modéliser les comptes bancaires. Les attributs sont listés en dehors (souvent avec un ovale pour chacun) du rectangle utilisé pour représenter l’Entité. Juste en dessous, le même modèle est représenté avec le formalisme de Merise. Les deux représentent la même information.



80

Si l’on veut modéliser complètement les faits de la figure 3.1, il faut aussi contraindre le client à avoir obligatoirement un ou plusieurs comptes bancaires. D’autre part, il faut aussi représenter que seuls les comptes bancaires ayant un propriétaire unique sont représentés. Ces deux informations sont des limites à la représentation du modèle conceptuel qu’il faut établir; elles sont des contraintes qui sont rendues selon le formalisme adopté par les notions de cardinalité ou de multiplicité (UML). Le premier modèle utilise le formalisme initial proposé par Chen dans lequel le losange représente l’association. Le deuxième exploite le langage de Merise. L’association est représentée par un ovale et les attributs qui définissent le type de l’Entité sont insérés dans le rectangle. Les contraintes de l’association sont représentées par le couple (min, max) qui sera étudié un peu plus loin. Formalismes de la modélisation Le formalisme de représentation des modèles a évolué pour donner naissance à une panoplie de langages graphiques de modélisation. (Chen : E/A) (Merise) (UML)

Figure 3.3 Le formalisme de Merise représente le même modèle avec peu de différence lorsqu’il s’agit d’un modèle simple. A part le symbole pour représenter l’association, il y a la façon de représenter les contraintes de l’association avec un positionnement différent de celui des contraintes proposées par Chen. Finalement, le diagramme de classe UML correspondant à ce modèle est similaire à

noCompte* succursale solde Client CompteBancaire Possede

matricule* nom rue ville

verbe

1 n

Client matricule* nom rue ville

CompteBancaire noCompte* succursale solde

Possede(1,n) (1,1)


1 1..*PossedeClient

matricule* nom rue ville

EstPossedePar



81

celui de Chen, mais utilise la notion de multiplicité pour représenter la cardinalité n par 1..*. Avec UML, il s’agit d’une classe au lieu de l’Entité, mais dans les deux cas c’est une représentation générique pour représenter des objets et des entités qui partagent la même structure. Le nom de la classe est parfois écrit au pluriel pour souligner son caractère ensembliste ou générique, tandis que dʹautres préfèrent le singulier pour accentuer sa généricité. Entité (classe) Une Entité est une structure logique générique dont le type global est défini par ses attributs. Chaque objet (synonyme d’entité) est défini par une suite de valeurs. L’ensemble des attributs d’une classe dʹentités est appelé son schéma. Le classement des objets est fait sur la base qu’ils partagent la même structure ou le même type. Lorsque nous utiliserons la notion d’instance, elle signifie un objet selon que le contexte est celui du formalisme E/A ou celui de UML. Une instance est une notion qui peut s’appliquer à tous les formalismes. Par exemple, l’instance Airbus 320 est une entité de l’Entité Avion ou un objet de la classe Avion. Par la suite et pour simplifier, la notion d’objet sera utilisée indifféremment du formalisme. Elle signifie à la fois la notion d’entité et d’instance. Au niveau générique, nous utiliserons de préférence la notion de classe. Dans ce dernier cas, il s’agit seulement de la structure sans les opérations. Ces dernières seront ajoutées subséquemment dans un contexte de développement objet. Aspect fonctionnel dʹun attribut Un attribut est en quelque sorte une fonction définie entre l’ensemble de départ composé des objets d’une classe et l’ensemble des parties de son domaine de valeurs, le dom(attribut). L’attribut a est une fonction attribut V définie ainsi :

E -V-> Σpi(dom(a)) où Σpi(dom(a) est l'ensemble des parties du domaine de a . Caractéristiques de lʹattribut Chaque attribut du schéma d’une Classe est considéré comme une fonction qui peut avoir plusieurs caractéristiques ou propriétés spécifiées au moment de l’implantation de la base avec le Langage de Définition des Données (LDD ou DDL) du SGBD utilisé : a) Complexité de l’attribut Il existe deux sortes dʹattribut quant à la complexité de sa structure informationnelle : ‐ Simple : un attribut simple est atomique et représente une seule propriété accessible comme un tout indécomposable. Par exemple : nom dont la valeur sera une chaîne et l’âge dont la valeur sera un entier. ‐ Composé (ou arborescent) : cʹest un attribut constitué de plusieurs attributs simples en relation hiérarchique. De par sa structure, un attribut composé offre un accès au tout ou à une partie de la valeur dʹattribut.



82

Client nom (1) nomFamille (2) prenom (2) ville (1)

Exemple d’un attribut composé : nom et le prénom comme un seul attribut.

Figure 3.4 Ainsi, la valeur de lʹattribut nom est obtenue par une fonction V(nom) => ʹLassonde Claireʹ, tandis que la valeur du nomFamille est obtenue par la notation pointée: V(nom.nomFamille) => ʹLassondeʹ. La hiérarchie peut avoir plusieurs niveaux. Ainsi, un tel attribut facilite lʹaffectation avec une variable de type struct du langage C. Il est aussi possible de représenter les attributs hiérarchiques par un indice de niveau placé entre parenthèses. Lʹattribut composé nom est alors représenté ainsi dans un formalisme logique dans lequel le chiffre indique le niveau de la hiérarchie. Dans l’exemple ci‐dessous la classe Client est définie avec deux attributs dont le premier est composé avec ses deux niveaux. Si la même information devait être représentée par un attribut simple, elle serait de type chaîne de caractères comprenant le nom et le prénom concaténés et délimités par un symbole adéquat. Pour obtenir seulement le nom de famille, une application devra donc lire toute la chaîne et l’extraire de celle‐ci au moyen du délimiteur et dʹune fonction de chaîne. Exemple : Le nom et le prénom combinés en un seul attribut nomPrenom valué avec la chaîne suivante : ʹ Lassonde$Claireʹ (où le $ agit comme délimiteur dans la chaîne). Pour accéder au prénom, l’application devra donc programmer une recherche dans la chaîne complète pour extraire le prénom en se servant du délimiteur. Notons que l’utilisation d’une expression régulière dans un langage d’interrogation permettrait de faire cette sélection automatiquement. Les versions récentes de plusieurs SGBD offrent cette fonctionnalité (voir Oracle 10g). b) Attribut monovaleur ou multivaleur Lʹattribut peut être valué (néologisme provenant du mot anglais valued) par une ou des valeurs selon le cas :

nom

nomFamille prenom



83

‐ Monovaleur : cʹest un attribut valué par une seule valeur pour chaque entité, cʹest‐à‐dire que la mise en correspondance est limitée avec un élément d’ensemble p(d2) dont la cardinalité est 1. Lʹattribut est aussi nommé atomique ou scalaire. Par exemple, les attributs noCompte et solde sont des scalaires. ‐ Multivaleur (mv) : cʹest un attribut associé éventuellement à plusieurs valeurs pour chaque entité. Un tel attribut correspond à une mise en correspondance avec un élément de lʹensemble p(d2) dont la cardinalité est supérieure à 1. Lʹattribut multivaleur est codé (mv) et sa valeur est un ensemble de données. Ce type d’attribut est rarement présent dans les SGBD relationnels. c) Mode de l’attribut Il y a deux modes possibles pour lʹattribut : Direct : la valeur associée à l’attribut de la classe est stockée explicitement dans la base de données; Dérivé : la fonction est alors une composition de fonctions et la valeur obtenue n’est pas stockée directement avec l’attribut; Exemple : Lʹâge dʹune personne est une fonction (gʹ) qui assigne une année à chaque objet de la classe Personne:

age : E −> anneeNaissance ‐‐> entier, i.e. l’âge calculé (entier) gʹ gʹʹ Les deux fonctions g’ et gʺ sont composées pour donner la fonction g: g : g’ * gʺ : E −> entier g(E) = [dateCourante] ‐ g’(E) = âge de E.

d) Attribut autorisé à ne pas avoir une valeur : indicateur NULL C’est un attribut qui au chargement de l’entité peut ne pas avoir une valeur du domaine. Il en découle parfois une ambiguïté sémantique pour l’utilisateur. Son interprétation est variable : une absence de valeur peut signifier qu’elle est non disponible, mais existante ou que c’est une valeur non disponible, car non existante, ou une valeur inconnue (existe ou non), ou une valeur impossible, etc. A cause de cette polysémie possible de l’absence d’une valeur, il faut de préférence éviter cette situation dans une base. Elle peut générer aussi des résultats faux avec certains traitements. Cette possibilité pour un attribut de ne pas avoir une valeur correspond à un indicateur de valeur nulle (NULL) ou son contraire qui est un indicateur obligeant un attribut à avoir une valeur (NOT NULL). Exemple : Si pour des villes témoins, on enregistre à chaque jour la pression (p), la température (t) et la vitesse du vent (v), on obtient des objets de la classe appelée FicheMétéo. Supposons que suite à un accident, le baromètre soit en panne et que la pression ne soit pas disponible pour la ville inuit de ʹKuujjuaqʹ. Comment représenter la valeur manquante? En optant pour le 0 ? (pression plus quʹimprobable en kPa!), il y a possibilité d’effets de bord. Par exemple, le calcul



84

de la moyenne de la pression à ʹKuujjuaqʹ avec la fonction AVG() donnera un résultat faux! En effet, la valeur 0 étant une valeur du domaine de la pression p, la moyenne en tiendra compte dans la sommation et aussi dans la division nécessaire pour obtenir la moyenne. Lʹutilisation dʹune valeur hors domaine pour représenter la valeur nulle pose aussi problème. En effet, en interrogeant la base pour lister toutes les villes repères avec comme critère composé une pression > 100 ou une pression <100 ou une pression = 100, la réponse exclut alors les villes dont la pression est absente ou inconnue puisque le null pour p est hors domaine et par conséquent ne vérifiera jamais le critère de sélection de la requête. Le fait d’autoriser l’absence d’une valeur est signalée par un indicateur d’absence de valeur, le NULL. Il faudra donc utiliser un prédicat spécial pour faire une sélection avec cet indicateur et prendre ainsi en compte l’absence de valeur. Cet indicateur n’étant pas une valeur du domaine ne peut donc pas être comparé à une autre valeur. e) Clé d’une classe Un ensemble de un ou plusieurs attributs est appelé la clé de la classe parce que sa valeur est différente pour chaque objet. Si la clé est assignée, elle est connue comme un identifiant externe et son sens pour un utilisateur du système n’est pas toujours évident et peut poser problème en cours d’exploitation. Dans le modèle relationnel, une autre condition sera imposée à la clé, à savoir que le nombre dʹattributs soit minimal tout en gardant son rôle de distinguer les tuples (i.e. les objets relationnels) les uns des autres. Il y a essentiellement deux sortes de clé : La clé simple construite avec un seul attribut. Par exemple : nas ou matricule ou noVignette. La clé composée obtenue par juxtaposition d’au moins deux attributs simples. Par exemple, {matricule, noCours} dans la classe BulletinAcademique est une clé composée de deux attributs permettant à un étudiant de suivre plusieurs cours, et un même cours pouvant être suivi par plusieurs étudiants. Pour éviter une clé composée, il faudrait la remplacer par un identifiant dont la valeur est atomique, mais dont la sémantique est très souvent arbitraire en regard de la réalité. Un tel identifiant peut constituer un ajout étranger au système d’information en usage. a) Clé choisie et clé candidate Une classe dʹentités (i.e. une Entité) peut avoir plusieurs clés : ‐ Clé choisie ou principale (primary key ‐ à ne pas confondre avec l’attribut primaire) : s’il existe plusieurs clés possibles pour une classe, une (de préférence simple) est sélectionnée et marquée comme choisie ou principale. Les contraintes sur cette clé sont généralement renforcées par un index défini implicitement par le SGBD à partir de la spécification du schéma. Cet index ne peut pas être supprimé par le DBA. Le ou les attributs de la clé principale sont qualifiés d’attributs primaires. ‐ Clé candidate : toute clé, simple ou composée, non choisie comme primaire est une clé candidate pour sa classe. Tout comme la clé primaire, la clé candidate ne peut pas être nulle. Par



85

exemple, en supposant quʹun seul exemplaire existe pour un livre dans une bibliothèque, la classe Livre peut être définie de la façon suivante :

Livre (cote, titre, auteurs, noLocal, editeur, annee, ISBN, prix) Les clés possibles dans Livre sont les suivantes : ‐ clés simples (ou monoattribut) : {cote} ; {ISBN}; {noLocal}; ‐ clé dite composée (ou formée avec plusieurs attributs) : {annee, titre} ; ‐ clés candidates : toutes les clés ci‐dessus. b) Superclé La notion de superclé est utile dans la recherche dʹune clé. Elle est formée par l’ajout d’un ou de plusieurs attributs à une clé (primaire ou candidate). Dans le modèle relationnel, cette superclé n’est pas une clé primaire, mais un ensemble de plusieurs attributs qui contient obligatoirement une clé. Les attributs non essentiels dans la superclé sont dits étrangers. La superclé n’a pas toutes les caractéristiques d’une clé. Elle est très souvent composée, mais elle nʹest pas nécessairement minimale. Certains modèles, comme le modèle relationnel, ont obligatoirement une superclé formée par définition de tous les attributs d’une classe. Enfin, si une superclé est réputée présente dans une classe du modèle, il y a donc forcément une clé qui est incluse dans chaque classe du modèle. Domaine d’un attribut Le domaine dʹun attribut est un ensemble nommé formé de toutes les valeurs non nulles admissibles pour donner une valeur à une propriété (attribut). Le domaine sert à la validation sémantique que devrait pouvoir effectuer un SGBD indépendamment des applications. Le domaine est spécifié lors de la conception d’une base de données et sa définition est stockée dans le dictionnaire afin d’être accessible à toutes les applications. L’absence d’une valeur correspondant à la présence de l’indicateur NULL qui n’est pas une valeur du domaine. Remarque sur la syntaxe des libellés : Le libellé dʹun attribut ne comporte généralement pas de signes orthographiques sauf ceux admis par le langage de définition de données (DDL). Par exemple, les attributs âge et no‐Compte s’écrivent respectivement age et noCompte à titre dʹattributs dʹune table, car lʹaccent circonflexe et le trait dʹunion ne sont pas admissibles par la syntaxe du langage DDL. Exemples de domaines :

Dom (attribut) Nom du domaine Définition du domaine N.B.les crochets : ] et [ dom(age) d_age_actif 18<= age <= 65 ou [18...65] dom(age) d_age_actif [0...100[ (inclusion du 0 et exclusion de 100 ) dom(name) d1_nom chaîne de 35 caractères dom(nom) d2_nom {‘Audy’, ‘Bilodeau’, ‘Gagnon’} dom(salaire) d3_sal [23000.50 …50000.00]

Figure 3.5



86

Définition formelle de lʹinstance ou objet Une instance e de la classe E, est un obligatoirement un élément du produit cartésien des domaines d’attribut de E :

e ∈ {dom(A1) x dom (A2) x ... dom(An)} Notons aussi qu’une fonction n’est pas nécessairement définie partout dans l’ensemble de départ contrairement à la notion mathématique d’application et que, par conséquent, un attribut peut ne pas avoir de valeur comme cʹest le cas pour une fonction injective. Définition formelle d’une classe Une classe Ct est un sous‐ensemble arbitraire de tous les objets partageant la même définition et qui satisfont une clé primaire K au temps t :

Ct ⊆ {dom (A1) x dom (A2) x ... dom( An)} Objet (instance) et classe La classe est la définition générique de la structure des objets qui sont stockés dans un espace appelé extension. Une instance de Employe est représentée sous la forme dʹune ligne de valeurs dans une table relationnelle. Il y aura autant de lignes dans la table quʹil y a d’instances de Employe dans la base de données. Chaque ligne est aussi appelée un tuple.

Employe : matricule* nom departement <‐ définition de la table Employe m234 Larose réception objet ou instance m45 Jobin atelier fraisage m287 Vachon atelier soudure

Définition de la classe Employe et de ses instances Figure 3.6

Association; entre les instances des classes Une association représente un lien sémantique générique découlant des liens particuliers entre les objets de PosteTravail et ceux de Employe et Materiau.

Figure 3.7

poste1 poste2 poste3

emp5 emp2 emp7 mat3 mat5 mat4

23kg

50kg

34kg 18kg 15kg

Travaille Utilise

Les instances : 2 sortes de liens



87

Dans les exemples qui suivent, nous allégerons les figures en n’utilisant que le minimum dʹattributs pour définir chaque classe. Les instances ci‐dessous modélisent la quantité des matériaux utilisés par différents postes de travail pilotés par des ouvriers habilités à ces postes. Donc lorsqu’un attribut apparaît seul dans une occurrence ou dans une classe, il sera considéré comme la clé de la classe et les autres attributs sont réputés existés. L’association est généralement formulée par un verbe et la première lettre de son libellé est une majuscule. L’association inverse est très souvent implicite et est présumée, c’est‐à‐dire si R => R‐1. Voici un autre exemple, illustré à la figure 3.7 concernant l’approvisionnement des postes de travail flexible. Ainsi, dans lʹinstance du modèle ci‐dessous, lʹemployé ʹemp5ʹ travaille au poste ʹp1ʹ. De même, le matériau ʹmat3ʹ est utilisé par les postes ʹposte1ʹ et ʹposte2ʹ. Ces instances correspondent au MCD de la figure 3.7a.

Modèle conceptuel : E/A et UML Figure 3.7a

Dans les deux versions du MCD, les associations sont représentées sans mention de leur contrainte de cardinalité ou de multiplicité (figure 3.7a). L’état de ce modèle est donc une représentation partielle des instances de la figure 3.7. Le numéro de poste de travail est une clé primaire pour la classe PosteTravail; il en est de même pour les attributs matricule et noMat qui sont les clés respectives des classes Employe et Materiau. Sur le plan de la sémantique, le modèle de la figure 3.7a ne réussit pas à représenter toute lʹinformation que lʹon peut obtenir avec lʹexamen des instances, notamment le fait qu’un poste de travail peut fonctionner avec aucun ou plusieurs opérateurs. Par contre, si lʹon examine les entités de la figure 3.7, ce fait est clairement représenté. Pour enrichir la représentation du modèle, il faudra ajouter des informations concernant la participation des instances aux associations. Cet ajout se fera au moyen de contraintes formelles de participation et de

Employe matricule* nom

Travaille Utilise

qte

PosteTravail noPoste* noBatiment

Materiau noMat* site

Employe matricule* nom

Materiau noMat* site

PosteTravailnoPoste* noBatiment

Travaille qte

Utilise



88

cardinalité pour le formalisme E/A et au moyen de la multiplicité de chaque association UML dans les modèles de la figure 3.7a. Définition formelle de lʹassociation E/A de degré n Soit les classes E1, E2, ... En et les attributs a1 ,a2, ... ak ; une association r entre les classes E1.. En définie avec les attributs a1 à ak est un élément du produit cartésien : {dom(clé de E1) x dom(clé de E2) x ...dom(clé de En) x dom(a1) x ... dom(ak)} où r = (i1, i2, ... in, a1, a2, ... ak) avec ii comme identifiant de Ei ou clé de Ei, Ei = classe d’entités i, et aj = attribut j de l’association.

R ⊆ {dom(clé de E1) x dom(clé de E2) x ...dom(clé En) x dom( a1) x ... dom(ak)} NB : En utilisant la lettre majuscule R, on fait alors référence à l'ensemble des objets de la classe et donc à sa définition. Degré d’une association Soit n le nombre de classes d’entités présentes dans une association. Selon la valeur de n, il y a plusieurs cas de figure possibles : a- si n = 2, alors l'association ou relation est dite binaire (l’association la plus courante) b- si n = 3, alors l'association est dite ternaire (interprétation parfois difficile) c- si n = n, alors l'association est dite n-aire Un modèle conceptuel n’utilisant que les associations binaires (6) est qualifié de binaire. C'est le cas pour le modèle de données NIAM proposé par Nijssen (7). Association ternaire Les associations ternaires et celles de degré supérieur bien qu’admissibles sont presque toujours difficiles à interpréter; elles sont de préférence à éviter. Voici un exemple d’une telle association Realise qui de plus ne porte aucun attribut particulier.

Figure 3.8

En tenant compte des multiplicités de cette ternaire, la sémantique du modèle UML de la figure 3.8 est la suivante :

Client nas* nom

Constructeur nom* ville

Projet noProjet* cout chef

Version UML avec

une ternaire

1..*

1..*

1...* Realise



89

- Un client et un constructeur collaborent à la réalisation de un à plusieurs projets. - Un client et un projet ont engagé un à plusieurs constructeurs. - Un constructeur et un projet réfèrent à un à plusieurs clients. Nous verrons avec la théorie relationnelle, le rôle et la sémantique de la dépendance fonctionnelle (DF) entre les attributs. Nous serons en mesure alors de préciser que la ternaire sous-tend l’absence de dépendances fonctionnelles entre les clés des classes qui participent à l’association ternaire. Par exemple dans une telle ternaire, les DF suivantes ne sont pas validées :

nas -/-> nom, noProjet ; noProjet -/-> nas, nom et nom -/-> noProjet, nas Par contre, le même modèle avec des multiplicités différentes, notamment celles de 1 et 0..1 appliquées une ou deux classes de la ternaire, devient difficile à lire et constitue dans certains cas une représentation erronée ou du moins confuse. Voici un exemple illustré par la figure 3.8a.

Figure 3.8a Les contraintes sous-tendues par la multiplicité de la ternaire ci-dessus sont les suivantes :

1- Un client et un projet sont en contact avec aucun ou un constructeur. 2- Un client et un constructeur réfèrent à un et un seul projet. 3- Un constructeur et un projet font référence à un ou plusieurs clients.

Ainsi les triplets suivants sont valides : ( cl1, co1, pr1), (cl2, co2, pr1), (cl2, co1, pr2) Par contre les triplets suivants sont invalidés par les contraintes de multiplicité du modèle UML : triplet (cl2, co1, pr1) invalidé par la règle 2 , triplet (cl2, co2, pr2) invalidé par la règle 3. Cas spécial : En plus de ces contraintes sur la ternaire, il peut y avoir des contraintes particulières impliquant que deux classes : un constructeur ne peut être associé qu’à un seul projet à la fois peu importe le client. Cette contrainte dite d’intégrité fonctionnelle intervient entre deux classes seulement et interdit tout triplet qui représente un même constructeur associé à deux projets différents. Les triplets ( cl1, co1, pr1) et (cl2, co1, pr2) deviennent ainsi invalides. Une telle restriction entre deux classes peut introduire une contradiction ou une confusion avec les multiplicités de la ternaire. Une telle contrainte, si elle est valide peut indiquer que l’association ternaire n’est pas apporiée pour modéliser correctement cette réalité.

Client nas* nom



Version UML

1..*

1

0..1 Realise



90

Figure 3.8b La représentation avec deux binaires est illustrée ci-dessus constitue un nouveau modèle doté d’une sémantique différente de celle du modèle de la figure 3.8b. 3.2 Classe de rôle : spécialisation des classes et des associations Il arrive que certains attributs d’une classe ne s’appliquent pas à tous les objets de la classe8. Par exemple, les documents de la bibliothèque ont plusieurs formes : papier, support sonore ou visuel, disque optique compact ou CD-ROM. Selon le cas, les deux attributs ISBN et équipement ne s’appliquent pas à toutes les entités de la base modélisées par cette structure. Un livre a un ISBN mais n’a pas de libellé d’équipement. Par contre, un diaporama n’a pas de ISBN. L’indicateur d’absence de valeur (le null) n’est pas acceptable pour l’attribut ISBN puisqu’un diaporama n’a pas de ISBN lequel est réservé qu’aux livres. Un indicateur null laisserait supposer que le ISBN existe mais qu’il est inconnu au moment de la création de l’objet.

Figure 3.9

Un premier modèle E/A présenté à la figure 3.9 permet de représenter le prêt des documents aux abonnés de la bibliothèque. C'est une modélisation avec une structure dont les attributs ne s'appliquent cependant pas à toutes les entités. Comme c’était le cas pour le ISBN, l’attribut équipement ne s’applique pas à tous les documents sauf ceux du genre multimédia. L’attribut équipement n’est donc pas pertinent à la représentation de livres. Pour contourner cette difficulté, on attribue un rôle à la classe Document pour signifier que certains attributs s'appliquent à certains objets et pas à d'autres. Le rôle est concrétisé dans le modèle initial par une division des instances de Document et leur regroupement dans deux nouvelles sous-classes définies par leurs attributs propres. Dans cette même opération, il peut y avoir aussi spécialisation

Document noArticle* isbn local equipement

Personne matricule* nom

Emprunte dateP

L’attribut dateP dans ce modèle est considéré comme une information pertinente à l’emprunt du document par à une personne, c’est-à-dire à l’association entre les deux instances. Ainsi, il sera possible de garder en mémoire deux prêts du même document à la même personne et cela à deux dates différentes.

Document noArticle* isbn local equipement


dateP

E/A UML

Emprunte

Client nas* nom



Version UML

1..* 0..1 0..1 1..*



91

de l'association initiale pour prendre en compte les deux nouvelles classes spécialisées (figure 3.10). La création de ces deux sous-classes est une abstraction de spécialisation représentée par la flèche. Cette spécialisation appliquée à la modélisation conceptuelle n’est pas rendue directement comme tel avec la technologie relationnelle, sauf dans les derniers systèmes qualifiés de système objet-relationnel. Cette abstraction de spécialisation permet de simplifier, voire préciser la sémantique des associations et des classes du MCD. Elle peut contribuer à découvrir de nouvelles associations durant la phase d'analyse. L'inverse de la spécialisation est la généralisation qui consiste à former une superclasse avec les attributs communs à plusieurs sous-classes présentes dans un MCD. Les nouvelles classes spécialisées ont toutes les propriétés de la classe, à savoir qu’elles peuvent participer à des associations et avoir une clé primaire en propre. La spécialisation de la classe Document fournit deux nouvelles classes, le Multimedia et le Livre. Dans le formalisme UML, la spécialisation est représentée par une ou deux flèches et fournit deux sous-classes portant les mêmes noms.

Figure 3.10

Figure 3.10 Les nouvelles classes sont des sous-classes de rôle ou des classes spécialisées. Elles sont obtenues par une spécialisation de la classe Document. Avec la spécialisation, il est possible de préciser des contraintes à la spécialisation, notamment la couverture (t ou p) et le partionnement (e ou o). Dans l’exemple E/A, la spécialisation est partielle (p) et exclusive (e) les entités de Document. Certains documents et pas tous sont spécialisés comme un livre ou comme un document multimédia; il ne peut pas être les deux simultanément. C’est donc en quelque sorte


PreterL datePret

PreterM datePret

Document noArticle* local sorte

Multimedia equipement

Livre

isbn*

p,e

E/A

Document noArticle* local sorte

Livre

isbn*

Multimedia equipement


UML

PreterM datePret

PreterL datePret

Dans l’un et l’autre de ces MCD, les contraintes structurelles et les multiplicités sont à définir.

{i,d}



92

une inclusion telle que l’union des instances qui partagent la structure de l’une des deux sous-classes forme un sous-ensemble de la superclasse. Certains documents ne sont pas spécialisés par exemple les parchemins et ils auront la structure de la superclasse Document. La structure d'une sous-classe est spécifiée avec ses attributs propres auxquels s'ajoutent par héritage ceux de la superclasse. Le modèle indique donc que le type de la sous-classe Livre est défini par une structure logique formée des attributs {isbn*, noArticle, local}, tandis que celui de la structure de Multimédia est défini par les attributs {noArticle*, equipement, local}. Une sous-classe peut cependant ne pas avoir d'attributs propres, mais uniquement des attributs obtenus par héritage de la superclasse. Avec le formalisme UML, les contraintes sont incomplete (i) et disjoint (d). Dans le même MCD E/A de la figure 3.10, si la spécialisation était plutôt (t,e), alors aucune instance ne sera stockée dans la base de données avec la structure de Document. Dans la formulation UML les contraintes de la spécialisation seraient {c, d}. En spécialisant une classe, les sous-classes héritent aussi des associations de la classe source d’origine qui sont aussi spécialisées et renommées. Nous étudierons plus en détails ces notions à la fin de ce chapitre. Entité/Association UML total (t) complete (c) partiel (p) incomplete (i) exclusif (e) disjoint (d) chevauchement (o) overlapping (o)

Tableau des contraintes de spécialisation Attribut discriminant (d) Dans un modèle conceptuel, la spécialisation est avant tout un outil d'abstraction qui facilite dans certains cas la modélisation. Une autre caractéristique de la spécialisation consiste à définir une structure permettant de stocker au besoin, les objets des sous-classes avec ceux de la superclasse. Il y aura dans ce cas, deux structures logiques différentes qui cohabiteront dans la même superclasse. Les instances ainsi mélangées seront distinguées par l'ajout d'un nouvel attribut appelé le discriminant. Dans l'exemple ci-dessus, l'attribut discriminant est sorte dont la valeur peut être 'L' ou 'M' pour identifier un livre ou un multimédia. 3.3 Traitement de lʹassociation réflexive Une association binaire (figure 3.11) dans laquelle les deux classes participantes ont le même nom est dite réflexive. Encore ici, tous les objets de la classe Personne ne sont peut-être pas décrites de la même façon selon que l’entité concerne le médecin ou le patient.



93

Figure 3.11 La notion de rôle permet donc de diviser les entités d’une même classe en fonction de leur rôle ou du traitement particulier dévolu à chaque instance. Une personne pourrait être simultanément patient et médecin. Ceci se traduit par une spécialisation caractérisée par un chevauchement (overlapping (o)). En ce qui concerne la base, il pourra y avoir un objet avec la structure de médecin, et un autre avec le même identifiant ou clé, ayant la structure de patient. Au plan sémantique, ceci signifie que le modèle permet de représenter un médecin qui peut être aussi un patient. Comme cela est illustré à la figure 3.12, l'association réflexive peut être transformée par spécialisation pour obtenir deux sous-classes : Médecin et Patient. Il faut aussi noter que les contraintes sur les associations ne sont pas exprimées dans ces modèles.

Figure 3.12

Traite dateT

Personne matricule* nom specialite diagnostic noDossier

Patient Medecin

Personnematricule* nom specialite diagnostic noDossier

Traite dateT

Medecin

Patient

E/A UML


Medecin specialite

Patient noDossier diagnostic

t,o Consulte


Medecin specialite

Patient noDossier diagnostic

{c,o}

dateT

UML E/A

Consulte

Hopital

Hopital

Hopital

Traite Consulte

Traite dateT



94

Ces deux nouvelles classes peuvent éventuellement participer à de nouvelles associations pour représenter de nouveaux faits. Par exemple, une nouvelle association peut être faite entre médecin traitant et un hôpital pour représenter le fait qu’un médecin peut communiquer avec une équipe médicale spécialisée. Cette même équipe peut agir comme référence à plusieurs médecins, mais cette dernière contrainte d’association n’est pas encore représentée dans l’un et l’autre des modèles. Dans cette base, aucune instance ne peut être représentée qu'avec la seule structure logique de Personne {matricule, nom} et cela en raison de la couverture totale de la spécialisation qui force une personne à être un patient, un médecin ou les deux. La classe Personne est donc une classe abstraite et la convention UML spécifie que son nom doit être en italique. Lorsqu’un médecin est aussi un patient, nous retrouverons le même matricule et le même nom dans deux entités, l’une dans la sous-classe Medecin et l’autre dans Patient. Cette contrainte est modélisée par une spécialisation caractérisée par le chevauchement ou overlapping (o). Voici un autre exemple E/A de la modélisation des liens parentaux au moyen de l’association réflexive ParentEnfant qui sera transformée en une spécialisation exclusive. Dans ce cas, les instances de Personne sont séparées en deux classes mutuellement exclusives. L’association réflexive ACharge représente une génération de parents qui ont la charge d’enfants. Le partionnement exclusif limite la modélisation à une seule génération de sorte qu’un enfant ne peut pas être représenté comme un parent des enfants de la génération suivante.

Figure 3.13

C’est donc un modèle qui a ses limites, notamment à cause de l’absence de contraintes d’association.

Figure 3.13a

personne comme parent

personne comme enfant

A charge dep1

p3

p2

p4

Personne nas* nom employeur age ecole

ACharge Enfant

Parent

Personne nas* nom employeur age ecole

Enfant Parent

ACharge

UMLE/A



95

Une instance de l’association se lit ainsi : un parent p1 a la charge de 2 enfants que sont les personnes p3 et p4. La personne p3 a aussi un autre parent p2. Cette réflexive peut être transformée par spécialisation pour générer deux sous-classes : Parent et Enfant. Ces dernières sont en association pour représenter le lien parental ACharge. Encore une fois, remarquons que l’absence de contraintes sur l’association ne modélise pas entièrement les instances de la figure 3.13a. En effet, selon les instances un parent peut avoir plusieurs enfants et un enfant a au plus 2 parents. La spécialisation du MCD E/A de la figure 3.14 peut fait apparaître clairement deux nouvelles classes qui participent à l'association. La lecture du MCD devient plus simple et facilite la découverte éventuelle de nouvelles associations comme par exemple, l’inscription d’un enfant à un club sportif (partie ombragée).

Figure 3.14

La spécialisation pourrait être pilotée par un attribut spécial comme par exemple l'attribut statut qui permettrait de choisir la classe de spécialisation à laquelle appartient une instance personne à ranger dans la base. 3.4 Contraintes dʹune association Une association entre deux classes a des contraintes qui viennent enrichir la sémantique du MCD. Il y a deux contraintes importantes dans le modèle sémantique E/A, à savoir la contrainte de cardinalité (cc) et la contrainte de participation (cp). Elles sont exprimées de diverses façons selon le formalisme adopté. Leur convention de lecture est particulière à chaque système de codage des contraintes. Par exemple, avec Merise, les contraintes de participation et de cardinalité sont juxtaposées pour donner la paire (min,max). Par la suite, nous utiliserons l’équivalent en terme de multiplicité du diagramme de classe de UML.

ClubSport nomCl*

Personne nas* nom age

t, e

Parent employeur

Enfant ecole

ACharge

Inscrit

E/A

ClubSport nomCl*

Personne nas* nom age

Parent employeur

Enfant ecole

ACharge

Inscrit

UML

{c, d}



96

Contrainte de cardinalité (cc) de l’association La contrainte de cardinalité d'une classe E spécifie le nombre possible d’instances d'une autre classe G en association avec une instance de E. La cardinalité de E se place du côté de G. Notez aussi que le terme instance sera utilisé au lieu de entité. Cas 1 : 1-1 Chaque instance de E peut être associée avec au plus une instance de G et vice-versa.

Figure 3.15 La contrainte de cardinalité se place de part et d’autre des extrémités de l’association. On peut interpréter la cardinalité de l’association de la figure 3.15 de la façon suivante : a) Une instance de E peut participer au plus à une instance de l’association entre E et G. En d'autres mots, une instance de E peut être associée au plus à une instance de G. Il est possible qu’une instance de E ou de G ne soit pas en association. b) Chaque instance de G peut participer au plus à une instance de l’association entre E et G ou affirmer qu'une entité de G peut être associée au plus à une entité de E. Il peut y avoir des entités de E qui ne participent pas à une association. Cas 2 : La cardinalité 1-N

Figure 3.16 Voici l'interprétation proposée : a) Chaque instance de E peut participer à l’association E-G avec plusieurs entités de G, au plus N. Encore ici, cela signifie qu’une instance de E peut participer à N instances de l’association E-G. b) Chaque entité de G peut être en association avec au plus une instance de E.

1- N

E G

1 - 1

E G

E G EG 1 1



97

cas 3 : La cardinalité de plusieurs avec plusieurs : N-M

Figure 3.17 On peut l'interpréter cette association ainsi : a) Chaque instance de E peut participer à l’association avec au plus m instances de G. Ou encore, une instance de E participe au plus à m instances de l’association E-G. b) Chaque instance de G peut participer au plus à n instances de l’association E-G. En d'autres mots une instance de G peut être associée au plus à n instances de E. La contrainte de cardinalité sous-tend une certaine sémantique dans l’association au regard de la réalité à modéliser. Les faits de la réalité qui ne se conforment pas à ces contraintes du modèle ne peuvent tout simplement pas être représentés par le modèle MCD. Voici un autre exemple concret d’un modèle E/A simple permettant de résumer les 3 cas de figure précédents et de leur interprétation :

Figure 3.18 L'interprétation des trois cas modélisés par l'association Possede est la suivante :

N - M

E G

cas 1 : 1 cas 2 : 1 cas 3 : n

1 n m

Client matricule* nom rue ville


Possede

E G EG N 1

E G EG N M



98

Cas 1 : Avec la cardinalité 1-1, un client possède 0 ou 1 compte et inversement. Les comptes en copropriété, c’est-à-dire l'ouverture par la même personne de plusieurs comptes, ne sont pas modélisés par cette structure logique. Il est possible pour un client de ne pas avoir de compte bancaire. Est-ce qu’un compte bancaire peut être ouvert sans un client? Selon la contrainte 1-1, cela est possible. Or, une telle situation n’étant pas réaliste, il faudra un autre type de contrainte, soit celle de participation (rendue par le paramètre min) pour venir interdire la représentation de ce fait. Cas 2 : Avec la cardinalité 1-N, un client possède 0 ou plusieurs comptes bancaires, mais un compte bancaire peut avoir, au plus, 0 ou 1 client propriétaire (1-N). Il est possible de modéliser l'ouverture de plusieurs comptes par la même personne, mais pas la copropriété d’un même compte. Cas 3 : Avec la cardinalité M-N, un compte peut appartenir à 0 ou n clients (m) et un client peut avoir 0 ou plusieurs comptes (m). Cette structure modélise tous les cas mentionnés auparavant; elle est la moins contraignante et très utilisée dans les MCD. Remarque : Il existe plusieurs formalismes de modélisation conceptuelle souvent distincts les uns des autres par la manière de formuler les contraintes de l’association. Le formalisme UML s’inspire des contraintes de cardinalité pour proposer son propre codage des contraintes d’association appelé multiplicité. Contrainte de participation de E/A La contrainte de participation spécifie si la présence d’une instance est liée à celle dʹune autre par son inclusion (sa participation) obligatoire ou pas dans une instance d’association. Elle est aussi dite d’existence, car elle spécifie quʹune entité de la classe peut exister sans ou avec lʹobligation de participer à une association. La participation à une association peut être totale (t) ou partielle (p). Cette notion complète celle de cardinalité introduite précédemment. Participation totale (ou obligatoire) Chaque instance doit participer à une association; en cas de suppression de lʹassociation, l’instance est aussi supprimée puisquʹelle ne peut exister sans participation à lʹassociation.

Figure 3.19 Par exemple, la cardinalité de la figure 3.19, un employé travaille dans 0 ou 1 département et ce dernier a 0 ou plusieurs employés sur la liste de personnel. Avec l’ajout de la contrainte de participation totale (t), si un employé est embauché, il doit être assigné immédiatement à un département. Toutefois, si un employé est libéré, le département reste dans la base tant et aussi longtemps qu’un autre employé y travaille. La participation est une contrainte qui vient restreindre cette de la cardinalité.

Employe nas * nom

Departement no * ville

Travaille t n

t 1

la participation



99

Participation partielle (facultative) Examinons maintenant la contrainte de participation partielle dans le même MCD.

Figure 3.20

Dans la représentation de la figure 3.20, la cardinalité sous-tend qu’un employé travaille dans 0 ou 1 département. Toutefois, en raison de la participation partielle (p) à l’association Travaille, un employé peut être inscrit dans la base sans avoir une assignation de travail dans un département. Un département a cependant l’obligation d’avoir (t) un ou plusieurs (n) employés pour être représenté dans la base. D’autres cas sont possibles et doivent être pris en considération par le concepteur. Par exemple, quelle est l’interprétation de la contrainte de participation partielle attribuée à chaque côté de l’association? Un employé peut être inscrit dans la base sans avoir été associé à un département particulier et un département peut être représenté dans la base sans avoir d’employés. Contrainte d’existence (Existence dependency) La participation totale d’un employé dans une occurrence de l’association Travaille est aussi qualifiée de contrainte d’existence parce que la suppression d’une instance du département où ceux-ci travaillent entraîne non seulement la suppression du département de l'association, mais aussi automatiquement la suppression de ou des employés, puisque ces derniers ne peuvent pas être dans la base sans une participation à l'association, i.e. sans département.

Figure 3.20a Par exemple lors de la suppression du département d1, tous les employés travaillant dans ce département sont enlevés automatiquement de la base parce que leur représentation est interdite sans une participation à une association. L'inverse aussi est vrai, lorsque qu'un employé quitte un département, ce dernier est supprimé s'il cet employé est le dernier travaillant dans ce département, sinon le département persiste en raison des autres employés qui sont au travail dans d1. Lors de l'ajout d'une instance de département, par exemple le d4, il faut obligatoirement que cette nouvelle instance participe dès sa création à une association avec un employé pour avoir au moins un employé y travaillant. De même, l’employé e5 (par exemple défini par le nas e5 et dont le nom est Picard) est ajouté à la base que s’il peut être mis en association avec un département déjà créé.

Employe nas * nom


Travaille t n

t 1

Employe nas * nom


p n

Travaille

la participation

la cardinalité

t 1



100

3.5 Contraintes structurelles (cs) fusionnant la cardinalité et la participation La fusion des contraintes de cardinalité et de participation s’exprime par les contraintes connues sous le vocable de contraintes structurelles (cs) bien connues dans le formalisme Merise sous la forme d'une paire d’entiers (min, max). Cette contrainte est aussi nommée min-max et sa lecture dans un modèle est différente de celle de la cardinalité.

cs = ( contraintes de participation, contraintes de cardinalité)

Figure 3.21 Le premier entier de la paire exprime la participation : 0 pour partielle et 1 pour totale (ou obligatoire). Le deuxième entier de la paire permet de préciser le nombre total d'instances de l’autre classe avec lesquelles une première instance peut être en association. Ainsi, un employé n’est pas obligé de travailler dans un département; au plus, il peut travailler dans un seul. Par contre, un département doit avoir au moins un employé (participation totale) et peut avoir jusqu'à 100 employés. La partie max est précisée que si elle constitue une limite supérieure significative qui devra être renforcée, au moment de l’implantation de la base de données, par un mécanisme de validation de cette contrainte. Si le sens de la valeur max se limite à représenter la notion de plusieurs, sa valeur est indéterminée. Le n ou m (ou encore N ou M) signifie plusieurs. Participation partielle dans une association exprimée avec (min, max) Cette contrainte exprime le fait quʹun employé puisse être représenté sans travailler dans un département (participation partielle); il peut cependant travailler dans plusieurs départements, soit au plus à 3 départements. Voici, deux autres modèles équivalents utilisant un formalisme différent. Le formalisme E/A utilise les notions de participation et de cardinalité et sa lecture est légèrement différente.

Employe nas * nom


Travaille (0,3) (1, 100)

Merise

Employe nas * nom


p 100

E/A

t 3

Travaille

(0, 1) (1, 100) Employe

nas * nom

Travaille Departement no * ville

contrainte structurelle



101

Un employé peut travailler dans au plus 3 départements, mais il peut aussi être dana la base sans participer à l’association (p). Un département peut avoir au plus 100 employés et sa représentation dans la base suppose un assoication avec au moins 1 employé. Diagramme de classe de UML Le formalisme UML s’inspire de Merise, mais les contraintes d’association sont rendues par la notion de multiplicité positionnée de façon inverse au regard de celle du (min,max).

Figure 3.21a

Dans la figure 3.21a, la multiplicité 1..100 du côté Employe équivaut au min‐max de Merise pour la classe opposée, soit Departement. En UML, la lecture doit se faire ainsi : 1 employé travaille dans 0 département et au plus dans 3. Un département a obligatoirement 1 employé et au plus 100. Le triangle indique le sens privilégié, mais non exclusive, de la lecture de l’association. Très souvent l’association inverse est sous‐entendue et partant, non représentée.

Participation totale dans une association exprimée avec la notation (min, max) L’association Travaille du MCD de la figure 3.22 est dotée d’une contrainte min‐max pour coder la participation totale. En effet, un min égale à 1 signifie que chaque instance de Employe est en association obligatoire avec au moins un département. Le max est la cardinalité et représente le plus grand nombre de départements où peut travailler un employé.

Figure 3.22

Le codage des contraintes d’association en UML et les équivalents avec le (min, max) et les cardinalité de E/A sont fournies par le tableau ci‐dessous. E/A Merise UML participation, cardinalité (min, max) multiplicité p, 1 0, 1 0..1 t, 1 1, 1 1 p, n 0, n 0..* t, n 1, n 1..8

Figure 3.21b


Employe nas * nom

(1,3) (1,100) Travaille

Merise

UML

Employe nas * nom


Travaille 1..100 0..3

multiplicité

FaitTravailler



102

3.6 Traitement des attributs directement reliés à une association E/A Une association peut aussi avoir ses propres attributs. Dans certains cas, une telle association peut être transformée par une migration de ses attributs vers l’une des classes participantes et cela, sans que la capacité de représentation du modèle soit affectée. Un employé travaillant x heures à la réalisation dʹun ou plusieurs projets. Le traitement réservé à lʹattribut de lʹassociation dépend de la contrainte de cardinalité de part et dʹautre de cette association.

Figure 3.23 Voici le traitement d’un attribut dʹassociation pour les cas de figure possibles représentés par le point dʹinterrogation dans la figure 3.23. Cas 1‐1 avec participation totale des deux côtés L’attribut nbHeure peut être rattaché à l’une ou lʹautre des classes participantes à lʹassociation. Le choix peut être imposé par la plus grande fréquence d’accès prévue pour un attribut ou la sémantique même de la classe. Si cette structure est principalement fouillée par les applications par le biais de la classe Employe, lʹattribut heure sera placé de ce côté. Or, du point de la sémantique, le nombre d’heures est plus une caractéristique de Employe que de Departement. Dans le cas contraire, l’attribut peut être déplacé du côté Departement.

Figure 3.24

Employe nas * nom


Travaille nbHeure

? ?

Employe nas * nom

Travaille nbHeure


(1,1) (1,1)

Travaille Employe

nas * nom nbHeure


1 1

UML

Employe nas * nom nbHeure


Travaille (1,1) (1,1)

E/A



103

Pourquoi pas une seule classe EmpDep? Un changement anticipé dans la contrainte de cardinalité justifierait de conserver cette association dans le modèle comme une entité autonome avec les deux classes Employe et Departement. Tout changement de multiplicité pour la contrainte d'association n’engendre pas alors une réorganisation importante du modèle (donc de la base de données). Cas 1‐1 avec une participation partielle dʹun seul côté de l’association Lorsque la participation est partielle, l’attribut de l'association migre du côté de la contrainte de participation totale ou demeure attaché à l’association et cela, pour éviter autant que possible l’utilisation de l’indicateur NULL pour l'attribut nbHeure. En outre, la sémantique justifie très bien le nombre d’heures comme étant plutôt une caractéristique de l’employé que du département.

Figure 3.24a

Cas 1‐n avec une participation totale des deux côtés Soit la contrainte structurelle (1,1) du côté Employe et (1,n) du côté Departement. L’attribut nbHeure est alors rattaché au côté (1, 1), soit celui de Employe. Dans la version E/A et UML, l’attribut nbHeure est placé du côté Employe, i.e. de la classe enfant.

Figure 3.25 L'employé qui travaille pour un seul département doit fournir le nombre d’heures de travail pour l'unique département auquel cet employé est associé. Avec cette contrainte, un employé ne peut



Travaille (1,1) (0,1)

Travaille nbHeure

Employe nas * nom


(1,1) (1,n)

(enfant)



Travaille

1..* 1

UML (enfant)



Travaille

(1,1) (1,n)

E/A



104

pas travailler dans plusieurs départements différents. Le transfert de l'attribut nbHeure du côté de Departement est en théorie possible, mais serait plus difficile à lire et devra faire appel à une structure de données physique dynamique ayant autant d’entrées que de départements et cela, pour chaque employé. Il faut donc dans ce cas avoir un attribut multivalué. Avec la technologie relationnelle, cette approche n’est donc pas possible, car les seules structures disponibles pour les attributs sont de type élémentaire. Il en sera autrement avec la technologie objet-relationnelle qui offre des structures de stockage de type ensemble pour un attribut. Cas n‐m avec une participation totale des deux côtés Dans ce cas l’attribut peut rester attaché à l’association Travaille. Il sera traité au moment du passage au modèle logique.

Figure 3.26 Cette structure conceptuelle examinée au niveau des instances de données possède plusieurs caractéristiques sémantiques : a- Un département a obligatoirement 1 employé et au plus 150. b- Un employé travaille obligatoirement dans 1 département et au plus dans 2 départements. La version UML de ce modèle fait appel à une classe d’association dont la structure comprendra l’attribut nbHeure. La classe d’association est rattachée à l’association par une ligne pointillée. La classe d’association peut en sus participer à une autre association dans le même modèle. 3.7 Classe d’entités faibles et fortes du modèle E/A La plupart des classes d'un MCD sont fortes en ce sens que les entités sont distinctes les unes des autres par une clé primaire. Dans certains modèles, cette clé n'est pas toujours disponible ou identifiable comme étant capable de distinguer chaque instance. Il s’agit alors d’une classe dite faible. La modélisation avec une classe faible peut être évitée en la remplaçant par une

Employe nas * nom


1..2 1..150

UML

nbHeure Travaille

Employe nas * nom


Travaille nbHeure

(1, 2) (1, 150)



105

association entre deux classes fortes rendu possible par la migration de la clé primaire de l’autre classe participante. Classe faible dans le modèle E/A Une classe faible est asservie à celle d'une autre classe dite dominante. Supposons que les salles de réunion des ministères sont représentées par une classe Ministere et une autre Salle. Chaque salle de réunion au sein d’un ministère est identifiée par un numéro et ces derniers sont uniques au sein d’un même ministère, mais pas nécessairement dans l’ensemble des ministères. Ce numéro n’est donc pas une clé mais un discriminant (d) parce qu’il permet d’identifier une salle que dans un ministère. Deux salles dans des ministères distincts peuvent donc avoir le même numéro. L’unicité du numéro de salle n’est pas assurée au niveau global.

Figure 3.27 Les instances de Salle associées dans un même ministère sont différentiées par le numéro de la salle (noS). Ce type de Classe est dit faible et l’attribut noS est son discriminant. La modélisation avec une classe faible peut coller davantage à la réalité. Elle peut être toutefois remplacée par une association entre deux classes. Voici un autre exemple dans lequel la classe des enfants est faible parce que plusieurs ont le même prénom, le même nom, le même sexe et sont nés le même jour. Tous les attributs de ;a classe Enfant ne peuvent pas être une clé pour distinguer les instances entre elles.

La participation totale est du côté de la classe faible Figure 3.28

Ministere nomMin* adresse

Salle noS (d) capacite

EstDans

MinisterenomMin* adresse

Sallecapacite

EstDans

noS

MinisterenomMin* adresse

SallenomMin* noS* capacite

EstDans

(a) (b) (c) UML E/A E/A

1, n

1, 1 1, 1

1, 1

1..*

1, n

Employe nas* nom dateNaiss

Enfant prenom (d) nom(d) dateN sexe

ACharge

(0,n) (1,1)

(classe forte) (classe faible)



106

Toutefois, les enfants d’un même employé (sous-ensemble de Enfant) sont distincts les uns des autres par leur prénom et leur nom. Les attributs nom et prénom forment donc un discriminant de la classe faible Enfant dont la classe forte est Employe. Une classe faible est toujours l'objet d'une contrainte de participation totale, (1,1). De sorte que la suppression d'un employé dans la base entraîne aussi celle de ses enfants . Il ne pourrait pas y avoir dans la base deux enfants sans parent (participation partielle), car dans ce cas deux enfants sans parent qui pourraient avoir le même discriminant ne sauraient être distincts. Il peut y avoir plusieurs classes faibles dans un même modèle. Elles peuvent être aussi en cascade comme l'illustre la figure 3.29. Transformation de la classe faible La transformation d’une classe faible en une classe forte est simple et s'effectue normalement lors du passage au modèle logique. La classe faible est transformée ainsi : a) Une classe faible peut être fusionnée avec sa classe propriétaire forte et être représentée par un attribut composé ou multivaleur;

b) Une classe faible peut être transformée en classe forte par l’adjonction des clés primaires des classes fortes associées directement ou indirectement par l'entremise d'une cascade de classes faibles (figure 3.29). Le choix de la représentation est souvent laissé au concepteur, mais il peut être fait en fonction de la performance et en tenant compte des accès prévus à la base. Les classes transformées deviennent des classes fortes et peuvent être mises éventuellement en association avec d'autres classes. La classe au bas du MCD a une clé obtenue par la juxtaposition de la clé de la classe forte avec les discriminants des classes faibles.

Transformation d'une cascade de classes faibles en classes fortes E/A Figure 3.29

A a1* a2

B b1* b2

C c1* c2

A a1* a2

B a1*, b1* b2

C a1*,b1*,c1* c2

clé composée



107

Classe faible dans une association ternaire L'association ternaire est admise dans la modélistion E/A, mais son usage est plutôt rare car elle est difficile à interpréter. Dans l'exemple ci-dessous l’association ternaire est composée de trois classes dont une est faible. Le discriminant est composé des attributs {date et cout}, c'est-à-dire du coût et de la date du projet. Ainsi, deux instances de Projet ayant les mêmes valeurs pour le discriminant peuvent être présentes dans la même classe, à la condition d'avoir un propriétaire différent, soit dans ce cas une instance différente de l'association binaire Realise.

Figure 3.30 Exemple : Deux instances de Projet qui ont le même discriminant (dont les attributs sont identifiés par un (d)) correspondent forcément à deux projets différents, car chacun est associé à une combinaison différente de Client et Constructeur. La transformation de ce modèle pour obtenir seulement des classes fortes est relativement simple. Elle se fait par l’adjonction des clés des classes participantes au discriminant de la classe faible, Client, Constructeur et Offre.

Client nas* nom


Offre no*

Inscrire

Projet date(d) cout (d) chef

Realise

E/A

0,1

1,m

0,n

Client

Constructeur

Offre Projet : 2 instances avec même discriminant



108

Figure 3.31 Deux instances de la nouvelle classe forte Projet sont alors distinctes par leur clé primaire composée. Exclusion et inclusion des associations Par défaut, une instance peut participer à plus de deux associations. Ainsi, les instances du modèle ci‐dessous, figure 3.31, un chef de projet peut travailler avec une équipe internationale au développement de logiciels et il peut en même temps diriger une équipe locale.

Figure 3.31

Voici un exemple d'un ensemble d'instances valides pour ce MCD. L’association Participe est représentée au niveau des instances par le trait continu, tandis qu’une instance de Dirige utilise le trait pointillé.

Offre no*

Inscrire

Projet nas * nom* no* date* cout* chef

nouvelle clé composée de la classe Projet

Client nas* nom


Realise

ChefProjet

EquipeLocal EquipeInter

Participe Dirige

0,n 1,n

1,1 1,1

E/A



109

Figure 3.31a Le chef de projet ‘cp2’ participe à une équipe internationale 'eqIn2' sans autre participation au niveau local. Le chef de projet 'cp3' participe à l'équipe internationale 'eqIn3' et dirige aussi l'équipe locale eqLo1. Si la modélisation imposait qu'un chef d'équipe participe ou dirige, mais pas les deux (le OU exclusif), il faudrait ajouter cette contrainte entre les deux association dans le modèle, comme cela est illustré la figure 3.31b.

Figure 3.31b

Le modèle UML équivalent comporte une ligne pointillée pour représenter l’exclusivité mutuelle des associations.

Figure 3.32

ChefProjet


Participe Dirige

0,n 1,n

1,1 1,1

E/A

+

cp1 cp2 cp3 cp4

eqIn1 eqIn2 eqIn3 eqLo1 eqLo2

E/A Les instances du modèle

Dirige Participe

ChefProjet


0..* 1..*

1..1 1..1

UML

Dirige Participe

Exclusivité mutuelle entre deux associations



110

Les instances valides pour ce modèle sont les suivantes : La figure 3.33 présente un MCD E/A un peu plus complexe avec les contraintes exprimées par le (min, max). Nous conviendrons qu'un attribut composé sera codé (0) et que ses composants hiérarchiques seront notés d'après leur niveau. Ensuite, un attribut multivaleur sera noté (mv). Cette notation a l'avantage d'être plus compacte que celle du modèle d'origine parce que les attributs ne sont pas déployés dans l'espace autour du symbole de classe, mais plutôt regroupés à l'intérieur de celle-ci.

Figure 3.33

(0,n)

Employe nas* patronyme(0) nom (1) prenom(1)

Departement no* nom* localisation (mv) nbEmploye

Travaille

Gere dateDebut

Projet no* nom* site

Controle

Participe

Supervise

Enfant prenom(d) nom(d) dateNaiss sexe

ACharge

(0,1)

(1,1)

(1,1)

(0,n)

(0,1)

(1,n)

(1,1)

(1,n)

(1,n) (0,n)

(1,1)

E/A

cp1 cp2 cp3 cp4

eqIn1 eqIn2 eqIn3 eqLo1 eqLo2 E/A

Les instances du modèle



111

La notion de facette dans les modèles conceptuels complexes Lorsquʹil s’agit de modéliser une organisation beaucoup plus complexe, il peut arriver que lʹanalyse informatique identifie plus de 200 classes différentes. Chacune est définie par plusieurs attributs sensiblement plus diversifiés que ceux des petits modèles académiques. Pour simplifier le modèle et son interprétation, le MCD global peut être divisé en facettes, chacune correspondant à une partie du modèle, à laquelle est rattachée une sémantique complète et cohérente. Ainsi, le MCD ci‐dessus pourrait comporter une facette pour les projets en cours, une autre pour la partie ressources humaines et charges familiales. Toutes ces facettes constituant le modèle conceptuel. C’est aussi une façon d’alléger et de faciliter l’interprétation du MCD en n’utilisant que la facette nécessaire au traitement prévu.

Figure 3.34 Les autres formalismes proposés sont distincts essentiellement par la manière d’exprimer les cardinalités et les contraintes de participation dans les associations. Le langage graphique de ces variantes s'inspire largement du formalisme de représentation à objets comme par exemple le formalisme Object Modeling Tool (OMT) et surtout le langage UML qui regroupe toutes ces notions au sein du même formalisme. Il y a plusieurs autres formalismes proposés par différents auteurs dont la popularité est basée davantage sur des considérations de commercialisation que sur des fonctionnalités particulières qui leur donneraient une plus grande capacité de modélisation et un passage plus direct au développement des applications. Entre la méthode de X et celle de Y, il n’y a hélas trop souvent que des différences syntaxiques! Toutefois, le paradigme objet gagne du terrain (voir UML pour Unified Modeling Language) parmi les développeurs. Le passage vers cet univers objet sera accentué avec l'augmentation des logiciels et des outils de développement orientés objets pour la modélisation des données et des traitements. La publication de normes UML est certainement une façon d’accélérer son usage dans le développement des bases de données et du logiciel. 3.9

Facette A Facette B



112

Agrégation de classes Couplage faible L'agrégation ou la composition correspond à une abstraction qui génère une classe définie, notamment (parce que cette classe peut avoir aussi d’autres attributs) par une ou plusieurs classes existantes. L’agrégation n’a pas obligation d’avoir nom particulier. C’est en quelque sorte une association particulière entre une classe qui représente un tout et une autre, une partie de ce tout. Lorsque les instances d’une classe sont composées avec des objets d’une ou plusieurs autres classes, il s’agit probablement d’une agrégation. Cette abstraction n'est pas courante dans la pratique actuelle de la modélisation conceptuelle des données en E/A mais le deviendra avec le diagramme de classe UML. Son usage est justifié lorsque la modélisation concerne des organisations ou des réalités complexes. La figure ci-dessous est un exemple simple qui pourrait faire appel aux seules associations. Nous l’utiliserons cependant pour présenter de façon équivalente l’agrégation de deux classes. Des instances de Personne et Batiment peuvent être dans la base, même s’il n’y a pas de propriété légale associée. Il s’agit dans ce cas d’une agrégation qui sous-tend un couplage faible. Avec un tel couplage, la suppression d’une propriété légale donnée (instance) n’entraîne pas obligatoirement celle de la personne et du bâtiment. L’instance de Batiment disparaît, mais celle de Personne n’est plus associée avec l’instance de propriété légale, mais reste dans la base parce qu’elle possède un compte bancaire. Une agrégation est en premier une association particulière et à ce titre possède ses contraintes de multiplicité.

Agrégation et leur multiplicité Figure 3.35

Ainsi, la suppression d’un titre de propriété légale n’entraîne pas celle des personnes impliquées si elles participent à l’association Possede. Par contre, le bâtiment qui fait l’objet de l’acte de propriété légale est supprimé. En ajout, un bâtiment peut être créé dans la base sans être associé à un acte propriété légale. Agrégation de composition (couplage fort) Par contre, une agrégation avec un couplage fort est appelée une composition; elle sous-tend l’existence des instances des classes agrégées que si la classe composée est aussi créée. Avec le

ProprieteLegale noActeLegal *

Personnenas* nom adresse

BatimentnoBat* valeur taxe

agrégation

1..1 1..*

0..1 0..1

couplage faible multiplicité de « plusieurs »

CompteBancaire noC* soldeC margeC

Possede 0..1 1..1



113

modèle de la figure 3.36, une instance de document est représentée par la composition de plusieurs chapitres et d’un index du document. Si par la suite, cette instance est supprimée, cela entraîne aussi la suppression des chapitres et de l’index de celui-ci.

Figure 3.36 Dans ce cas, l’existence d’un chapitre ou d’un index est présumée sans intérêt en dehors de l’existence du document. Agrégation et association Dans lʹexemple de la figure 3.35, la classe ProprieteLegale est définie comme lʹagrégation faible des classes Personne et Batiment. Il est possible de représenter en E/A cette classe agrégée par la création dʹune seule classe intégrant les sous‐classes qui la composent et dont la clé est composée avec celle de chaque composante en sus de ses propres attributs.

Représentation de l'agrégation par une association binaire en E/A Figure 3.37

Agrégation avec les classes et les associations E/A Pour représenter le nombre d'heures d'opération d'une machine par un employé dont une partie du temps est consacré à un projet, il faudrait pouvoir modéliser cette information en créant une association entre deux associations (figure 3.37a).

1..* 1

Document ISBN* titre

Chapitre police format

IndexnbEntrees style

couplage fort

1 1

Personne nas* nom adresse

Batiment noBat* valeur taxe

EstProprio(1, n) (1, 1)



114

Association interdite par la modélisation E/A

Figure 3.37a L'attribut nbHeures de l’association Opere représente le nombre d'heures d'opération d'une machine de production par un employé lorsque ce dernier travaille un certain nombre d’heures sur un projet donné. Or la grammaire E/A interdit une telle association. En outre, deux associations binaires ne modélisent pas entièrement toute l’information. La valeur nbHeures de Opere est plus petit que nbHeures de travaille. À la limite, les deux attributs seront égaux. Pour contourner cette difficulté, une association ternaire pourrait être utilisée, mais elle représenterait une seule association héritant des attributs nbHeures de Travaille ou le nbHeures de l'association Opere (figure 3.37b). Or, on ne peut plus savoir avec une ternaire s'il s'agit du nombre d'heures travaillées sur un projet ou celui consacré aux commandes d'une machine! Il y a donc une perte d'information. Le renommage des attributs nbHeures pour nbHeuresProjet et nbHeuresMachine pourrait résoudre cependant l’ambiguïté.

Représentation E/A avec une association ternaire

Figure 3.37b Une autre solution consiste à faire une agrégation des deux classes (Employe et Projet) avec lʹassociation Travaille pour obtenir une nouvelle classe agrégée que lʹon peut nommer EmpProjet. Cette agrégation permet donc de respecter la grammaire du formalisme E/A avec

Travaille nbHeures

(1,m)

Employe matricule* nom adresse

Projet noProjet* ville

Opere nbHeures

Machine noMachine*

(0,n)

Machine noMachine



TravailleOper nbHeures nbHeures

(1,m) (1,n)

(1,2) Ambiguïté possible entre les deux attributs



115

une classe agrégée dont la clé est composée des clés primaires des classes composantes. Les autres attributs sont ceux des classes qui composent lʹagrégation.

Agrégation des classes et dʹune association en E/A Figure 3.37c

Dans cette abstraction de type agrégation, la formation d'une classe (agrégée) n'est pas représentée au moyen d'un symbole spécial, mais simplement par un rectangle représentant la nouvelle classe. Avec une telle modélisation, toute l'information est représentée avec plus de précision. Le passage au modèle relationnel se fait par des règles simples qui seront étudiées dans le chapitre traitant de la transposition du MCD au MRD (relationnel). Voici un autre exemple de la modélisation avec une association ternaire.

Figure 3.37d



Travaille nbHeures

(0,n) (1,m)

Opere nbHeures

Machine noMachine*

EmpProj

(1,2) classe agrégée

InstallationdateInstal

Logiciel noSerie* fournisseur

ServeurIP* categorie

Laboratoire noLabo* budget chef

0..*

1..1

1..*

ULM

Installer

Classe d’association UML

1..1



116

Il s’agit de modéliser l’installation de logiciels outils (traitement de texte, éditeur de HTML, système d’exploitation,…) sur les serveurs et cela suite aux demandes des divers laboratoires scientifiques. Chaque demande d’installation est faite à une date donnée. La classe d’association étant une classe à part entière, elle peut donc être en association avec d’autres classes, voire même être spécialisée. Les multiplicités précisent la sémantique de représentation du diagramme de classe de la figure 3.37d : a- Un couple (Serveur, Laboratoire) peut avoir accès à 0 ou plusieurs logiciels. Par exemple, le serveur 220.234.223.24 du laboratoire de phytologie a accès aux logiciels Word Perfect et à SAS. b- Un couple (Logiciel, Serveur) peut être en association qu’avec un laboratoire Par exemple le couple (ProteinSoft, 220.234.223.24) peut être associé qu’avec un laboratoire soit celui de biochimie. c- Le couple (Laboratoire, Logiciel) peut être associé avec serveurs. Par exemple, le laboratoire de biochimie et le logiciel se retrouvent que sur le serveur 220.234.223.24. En résumé, un logiciel commandé par un laboratoire ne peut être installé que sur un seul serveur. 3.10 Interprétation d’une ternaire Le diagramme de classe UML ci-dessous illustre quelques cas de modélisation et souligne les carences et lourdeurs possibles de la ternaire dans un modèle conceptuel. Il faut aussi noter que la sémantique de la ternaire dépend fortement des multiplicités de l’association. Dans ce modèle, un prospect qui devient un client réel exige de l’application qu’une partie des informations de son instance soit recopiée dans une nouvelle instance de la classe Client malgré le fait que cette information soit déjà dans la base. Finalement, les classes Client, Vendeur et Prospect partagent un certain nombre d’attributs de même domaine. Ce constat doit évoquer chez le DBA l’idée que l’abstraction d’héritage devrait apporter une contribution significative non seulement lors de la modélisation, mais aussi au stade de l’exploitation. 1- Multiplicité * pour les trois classes de la ternaire L’association ternaire a une multiplicité * pour classe participante ce qui permet à celle-ci d’avoir une représentation très vaste. Le MCD comporte une ternaire qui se lirait ainsi lorsque les instances sont représentées par les valeurs de clé comme par exemple v1 pour désigner le matricule (valeur de clé) d’un vendeur particulier, cl1, pour le numéro d’un client particulier et co1 pour le numéro d’une commande particulière : ‐ Un vendeur et un client rédigent 0, 1 ou plusieurs commandes : (v1, c1, co1) , (v1, c1,co2),

(v2, c1, co2), … sont des instances valides de l’association Redige. ‐ Une paire composée d’un vendeur et d’une commande peut être associée à 0, un ou plusieurs

clients : (v1, cl1, co1), (v1, cl1, co2), (v1, cl2, co1), …



117

‐ Une paire composée d’un client et d’une commande peut être associée à 1 ou plusieurs vendeurs : ( v1, cl1, co1), (v2, cl1, co1), …

Entre d’autres mots et compte tenu des multiplicités de la ternaire, toute combinaison des valeurs de clé représente une instance valide de l’association Redige. En faisant référence à la notion de dépendance fonctionnelle entre les attributs, on peut énoncer que cette ternaire Redige dotée des cardinalités (*) n’a aucune dépendance fonctionnelle entre ses attributs i.e. au sein de la définition de la classe :

matricule, noC -/-> noC matricule, noCom -/-> noC noCom, noC -/-> matricule

Toutefois, cela n’exclut pas certaines dépendances fonctionnelles entre les attributs de deux classes, notamment entre les clés primaires. Cette question sera à nouveau soulevée un peu plus loin. N.B. La notion de dépendance fonctionnelle sera étudiée avec le modèle relationnel. Brièvement, une dépendance (DF) existe entre un attribut A et B, si pour chaque valeur de A correspond une seule valeur de B : A B.

Vendeur matricule* nom dateNaiss fonction email tel

Client noC* nom tel email adresse codePostal ville fonction email t l

Commande noCom* dateCom

1..*

0..*

1..*

Prospect email* nom prenom tel adresse ville codePostal

Produit noProd* prixCatalogue TVQ

Redige

Requiert qte

0..*

1..*

Contacte 0..*

1

Recoit

Facture noF* dateF

1..*

1



118

2- Multiplicité * pour deux classes de la ternaire Dans le modèle ci-dessous, il y a une multiplicité est de 1. Dans un tel cas, toute combinaison d’un vendeur avec une commande est associée avec un seul client. Les instances de l’association (v1, co1, cl1) et (v1, co2, cl1), (v2, co1, cl1) sont valides. Par contre, l’instance (v1, co1, cl2) est alors non valide et exclue. Il n’y a pas deux clients sur la même commande et qui relève du même vendeur. Cette exclusion découle aussi de la présence d’une dépendance fonctionnelle déduite de la multiplicité 1 de la ternaire du MCD :

{matricule, noCom} noC Par contre, toute combinaison {Client, Commande} ou {Vendeur, Client} peut être associée respectivement avec une instance quelconque de Vendeur et de Commande. Ces contraintes respectent la multiplicité 1 du côté de la classe Client. 3- Multiplicité * pour une seule classe de la ternaire Dans ce cas de figure, toute combinaison peu importe le Vendeur, mais avec toujours le même Client doit être associée qu’à une seule Commande. C’est une situation d’affaires peu réaliste ! De même, toute combinaison peu importe le Vendeur avec toujours la même Commande doit être associée qu’à un seul Client (i.e. à une seule instance de Client). C’est légèrement plus réaliste si l’importance de la commande l’exige! Par exemple, la vente d’un avion à un client peut exiger l’intervention de plusieurs vendeurs sur la même commande. Bien entendu, c’est la sémantique que sous-tend la réalité à modéliser qui impose ou pas cette multiplicité.


Client noC* nom tel email adresse codePostal ville fonction email


1..*

0..*

1..*



Redige

Requiert qte

1 1..*

Contacte 0..*

1

Recoit

Facture noF* dateF

1..*

1



119

Les dépendances fonctionnelles valides présentes dans ce MCD sont les suivantes :

{matricule, noC} noCom {matricule, noCom} noC Selon les propriétés des dépendances fonctionnelles, il est impossible de dériver les DF matricule noCom et noC noCom de celle {matricule, noC} noCom . 4- Multiplicité 1 pour chaque classe participante à la ternaire Dans ce cas de figure, une combinaison seulement, par exemple {v1, cl1} peut être associée à une seule commande co1. Donc la combinaison (v1, cl1, co1) est admissible. Par contre, la combinaison (v1, cl1, co2 ) est exclue de par la multiplicité de la ternaire. En même temps, la combinaison (v1, co2, cl1) est admissible. Donc à un client donné, il n’ya pas qu’une seule commande. Les dépendances fonctionnelles suivantes sont alors valides :

{matricule, noC} noCom {matricule, noCom} noC {noCom, matricule} noCom




1

0..*

1..*



Redige

Requiert qte

1 1..*

Contacte 0..*

1

Recoit

Facture noF* dateF

1..*

1



120

Autres observations de la réalité qui sous-tend des dépendances entre deux classes Cependant, il peut arriver que la réalité impose une dépendance fonctionnelle (DF) entre deux classes de la ternaire. Par exemple, il est très fréquent que le numéro d’une commande identifie qu’un seul client : noCom noC.


Client noC* nom tel eMail adresse codePostal ville fonction email


1

0..*

1..*



Redige

Requiert qte

1 1

Contacte 0..*

1

Recoit

Facture noF* dateF

1..*

1


Client noC* nom tel eMail adresse codePostal ville fonction email


1..*

0..*

1..*



Redi

Requiert qte

1

1..*

Contacte 0..* 1

Recoit

Facture noF* dateF

1..*

1



121

En outre, il est possible que le client ne fasse affaire qu’avec un seul vendeur peu importe la commande : noC matricule. Si ces contraintes fonctionnelles sont intégrées au MCD doté d’une ternaire (comme c’est le cas avec Merise avec la notion de CIF, soit la contrainte d’intégrité fonctionnelle), il devient parfois possible de transformer le modèle en remplaçant la ternaire par deux associations binaires. Les deux dépendances fonctionnelles ont été ajoutées au MCD. En ce faisant, la sémantique de la ternaire est davantage précisée. Cette situation souligne l’inadéquation dans ce cas de la ternaire telle qu’elle a été formulée initialement sans prendre en compte les dépendances dans une paire de clases. Ce MCD est transformé par le remplacement de la ternaire avec deux associations binaires. Par contre, ces CIF entre deux classes ne simplifient la lecture du modèle du modèle conceptuel si la ternaire y reste présente. En conclusion, la ternaire est difficile à interpréter et si son usage s’avère utile voire parfois nécessaire, il faut apporter une attention particulière au choix des multiplicités. Il est cependant préférable de l’éviter en la remplaçant par une structure incluant une classe faible ou dans certains cas par des associations binaires. Modèle conceptuel de données : Abstractions d’héritage Généralisation et spécialisation La généralisation est le processus de formation d’une classe générique à partir de plusieurs classes existantes. La spécialisation9 est l'abstraction inverse, soit la formation de classes spécialisées à partir d'une classe existante appelée générique. L’abstraction de




1..*

0..*

1..*



Requiert qte

1

1

Contacte 0..* 1

Recoit

Facture noF* dateF

1..*

1

1..*

Dessert

Redige



122

généralisation/spécialisation a des propriétés particulières : couverture et partionnement. La couverture est dite totale, si toute instance de la superclasse est aussi une instance d'une sous-classe. Elle est dite partielle, s'il existe des instances qui ont le type de la superclasse seulement. Le partitionnement est dit exclusif si une instance de la superclasse n’existe qu'avec le type d'une seule sous-classe, tandis que la spécialisation est dite avec chevauchement (non disjointe), si la même instance identifiée existe simultanément avec le type de plusieurs sous-classes. Dans les pages suivantes, nous revenons sur ces notions en les illustrant avec plusieurs exemples. Nous donnerons aussi les modèles avec le formalisme UML. 3.10 Généralisation La généralisation est assortie d’un mécanisme fort important, soit celui de l'héritage par les sous-classes des attributs et des méthodes de la classe supérieure dans une hiérarchie de classes. Dans un contexte objet, une propriété importante est que tout objet qui est stocké avec une sous-classe soit éventuellement stocké dans l'extension de la superclasse parce que les règles de typage de la superclasse sont aussi vérifiées par les instances de la sous-classe. Une sous-classe étend donc la spécification de la superclasse et a la propriété de substitution c’est-à-dire que ses objets peuvent cohabiter sur disque avec ceux de la superclasse. En termes du relationnel, la création d’une instance se traduit par la création de un ou plusieurs tuples rangés par l'application dans les tables relationnelles créées pour implanter la hiérarchie des classes du MCD. Ce passage aux tables se fait selon des règles précises que nous verrons dans un autre chapitre. Pour un environnement de modélisation relationnelle, lorsque deux ou plusieurs classes partagent certains attributs identiques, il est possible de réduire la redondance des attributs au niveau du schéma par la création d’une classe générique dont la structure (le type) est spécifiée par les attributs communs. Cette abstraction de généralisation renforce la sémantique du modèle et permet parfois de faciliter la découverte de nouvelles associations impliquant la nouvelle classe générique. Il en est de même pour les associations qui peuvent être aussi généralisées et regroupées au niveau de la superclasse. Dans l'exemple ci-dessous, les deux classes partagent deux attributs qui justifient la création d'une superclasse VéhiculeDeuxRoues. L’analyse informatique révèle la présence de deux types d’instances regroupées dans deux classes apparemment sans lien. Cependant, ces deux classes partagent des attributs qui serviront à créer la superclasse. Les attributs communs entre Moto et Velo (signalés par la ligne pointillée) ont le même domaine et donnent naissance à une abstraction de généralisation.

Moto noSerie* puissance prix

Velo noSerie* composite prix



123

Figure 3.38a Dans cette abstraction, toute instance d’une sous‐classe vérifie aussi le type de la superclasse. Une moto est aussi un véhicule à deux roues. La généralisation est totale et exclusive. Au niveau conceptuel, ceci signifie que toute instance de la superclasse est soit une moto, soit un vélo (figure 3.38a), mais pas les deux simultanément. Aucun autre véhicule à deux roues ne peut être représenté par ce modèle à moins de redéfinir les propriétés de couverture pour la rendre partielle. Les attributs de la superclasse sont ceux qui sont communs aux sous‐classes. Il en sera de même dans un contexte objet qui permet d’associer des procédures ou des méthodes à la superclasse. Celles‐ci seront alors aussi accessibles par les sous‐classes et cela, par lʹentremise du mécanisme de lʹhéritage. Au besoin, il est aussi possible de redéfinir ces procédures (appelées aussi les méthodes). Le modèle relationnel n’intègre pas directement la propriété de lʹhéritage; une transformation s’imposera donc pour la concrétiser au niveau du schéma relationnel. L'abstraction de généralisation n'exclut par la possibilité que les sous-classes n’aient aucun attribut propre dans le MCD. Par exemple, dans la généralisation des motos et des vélos, il serait possible d'avoir la structure de la figure 3.38b. Les sous-classes peuvent quand même participer à des associations avec d'autres classes du modèle. On peut aussi se faire une image logique de cette spécialisation totale de VehiculeDeuxRoues en concevant un véhicule à deux roues comme un objet en correspondance totale avec son image (voir figure 3.39) au niveau des sous-classes qui sont regroupées autrement : les vélos dans une classe et les motos dans une autre.

VehiculeDeuxRoues noSerie* prix

Moto puissance

Velo composite

t,e

E/A


Moto puissance

Velo composite

UML

{c,d}



124

Figure 3.38b

Il faut se garder de penser que les objets sont dupliqués dans la base de données en raison de leur instanciation dans la superclasse et de leur spécialisation. En fait, il peut y avoir un seul objet qui intègre toutes les structures d’une hiérarchie des classes illustrées par la figure 3.39. Tous les véhicules avec une spécialisation (t,e) sont regroupés totalement en deux groupes disjoints: les motos et les vélos. Si la classe VéhiculeDeuxRoues ne participe pas elle-même à une autre association, elle est abstraite et pourrait être supprimée lors de l'implantation. Une instance moto aura donc une structure imposée par le modèle, à savoir qu’elle est formée avec les attributs hérités auxquels sont ajoutés les attributs spécifiques de la classe Moto.

Figure 3.39 L'image qu'il faut avoir de cette spécialisation est celle de la figure 3.39. Les instances de la superclasse sont classées de deux façons : en moto ou en vélo. En raison de la spécialisation

v1 v2 v3 v4 v5

t, e

Instances de vélo

classe abstraite (avec des instances virtuelles)

v5 m1 m2 v3 v4

Instances de moto

Personne nas* nom

Appartient


Moto

Velo

t,e

E/A


Moto

Velo

UML

{c,d}

Personne nas* nom

Appartient



125

totale, les instances de la superclasse sont illustrées mais elles ne sont pas implémentées. Elles sont en quelque sorte virtuelles puisque leur réalisation se fait dans les sous-classes. Avec une spécialisation partielle, la classe n’est plus abstraite et les objets correspondent alors des instances physiques de la superclasse. Généralisation/spécialisation définie par un prédicat ou par lʹapplication Une instance de la classe générique peut aussi avoir un attribut qui précise la nature de la spécialisation. Dans l'exemple du VéhiculeDeuxRoues, si la superclasse comporte un attribut sorte dont le domaine est {moto, vélo}, tout ajout d'une instance dans la superclasse sous-tend une spécialisation automatique par l'entremise de la valeur de l'attribut de spécialisation sorte. On représente cette spécialisation comme étant déclenchée par un prédicat formulé avec un attribut. Elle est dite spécialisation par prédicat (figure 3.39a).

Figure 3.39a Lorsque la spécialisation est précisée uniquement par l'application qui effectue une opération pilotée par l’utilisateur on parle alors de spécialisation par l'application. C'est cette dernière qui choisit la sous-classe qui modélisera l'instance du véhicule à deux roues qui est ajoutée à la base de données. Après son stockage dans la base, il n’a pas de trace dans l’instance qui justifie son rangement dans une sous-classe plutôt que dans l’autre, car l’attribut sorte est absent dans la base. Propriétés; de la généralisation/spécialisation Comme nous l’avons précédemment, l'abstraction de type spécialisation/généralisation a des propriétés contraignantes de couverture: totale (t), partielle (p) et de partionnement : exclusive (e) et non exclusive (o). Nous allons les étudier avec un peu plus de détails. Couverture de l’héritage : totale et partielle La généralisation est totale (t) si chaque instance de la superclasse en est une de la sous-classe. Elle sera dite partielle (p), si la classe Personne (voir figure 40) représente aussi des instances dont le type ne correspond qu'à celui de la superclasse. Il est aussi possible de formuler les propriétés de la généralisation avec les contraintes structurelles de min-max (Voir plus loin la section sur les notations). Dans l'exemple qui suit, la spécialisation est définie par l'application et

VehiculeDeuxRoues noSerie* prix sorte <-----

Moto puissance

Velo composite

t,e

sorte = 'moto' sorte = 'velo'

E/A



126

elle est totale parce que toute personne représentée est soit un ouvrier, soit un technicien. Les instances de Personne sont partitionnées en deux sous-classes disjointes.

Figure 3.40

Dans la figure 3.40, la superclasse est abstraite; elle ne sera pas instanciée et son rôle se limite à fournir des attributs (et éventuellement des méthodes) aux sous-classes. Le même modèle avec une spécialisation définie directement par un attribut supplémentaire tel que le métier pourrait être exploité dans un prédicat pour enclencher automatiquement une spécialisation à chaque création d'une Personne. La structure d'une instance Personne est celle d'un record défini par les champs : {nas, nom}. Celle de Ouvrier est un record défini par les champs : { nas , nom, syndicat}. Avec une couverture totale, les relations ci‐dessous sont vérifiées : 1) card(Ouvrier) + card(Technicien) = card(Personne) où card() est le nombre d'instances de la base de données qui vérifient le type de la classe Personne. 2) Personne ⊆ Ouvrier ∪ Technicien et Ouvrier ∪ Technicien ⊆ Personne (égalité des ensembles) Toute instance qui a le type de la Classe Personne est soit un ouvrier, soit un technicien. Lʹensemble Personne est un sous‐ensemble de celui obtenu par lʹunion des ensembles Ouvrier et Technicien, car tout élément de Personne est un élément de lʹensemble union. Comme l’inverse est aussi vrai, alors les deux ensembles sont identiques. 3) Ouvrier ⊆ Personne et Technicien ⊆ Personne Toute instance de la classe Ouvrier vérifie aussi le type de la classe Personne. C'est aussi vrai pour une instance de Technicien. A la limite, toutes les personnes peuvent être des ouvriers ou des techniciens. Remarque : Le petit carré dans la structure de généralisation est le symbole de fusion des classes pour indiquer qu’il s’agit de sous-classes impliquées dans une même abstraction de

Personne nas* nom

Ouvrier syndicat

Technicien corporation

t, e

Les instances de Personne (virtuelles)

p5 p2 p4 p3 p1

o1 o2 t3 t4 t5

E/A



127

généralisation/spécialisation. Certains auteurs proposent un petit cercle au lieu du petit carré et d’autres le signe d’inclusion positionné sur l’arête. Dans le langage UML le carré est remplacé par la fusion des lignes comme nous l’avons vu au début de ce chapitre. La généralisation/spécialisation est partielle lorsqu'il existe des instances définies seulement avec les attributs de la superclasse qui cohabitent cependant dans la base avec celles définies avec les attributs des sous-classes.

Figure 3.41 Remarque : Dans les SGBD objets, il y a une distinction entre une classe du modèle et le lieu physique du rangement des objets. Les objets qui ont des structures compatibles mais différentes peuvent être rangés dans une extension physique qui est créée lors de la création des classes ou séparément par la création d’une structure d’ensemble qui agit comme extension de rangement des objets. Dans le SGBD relationnel, cette notion d’extension n’est pas explicite, bien qu’elle corresponde à peu près aux pages de tuples. Les objets en pointillé ne correspondent pas à des instances physiques dans Personne. Elles sont en quelque sorte l’ombre de l’objet réel modélisé comme un ouvrier o1. Avec la spécialisation partielle, les propriétés suivantes sont vérifiées : 1) Ouvrier ⊂ Personne et Technicien ⊂ Personne Cette inclusion (dite properly contained) signifie que toute instance de la classe Ouvrier ou de la classe Technicien en est aussi une de Personne. Les instances p1 et o1 réfèrent au même objet réel, soit une personne donnée, mais leur description en est légèrement différente. Dans un premier regroupement, celui de Personne, la personne p1 est abstraite, tandis que la même personne est représentée comme un ouvrier o1 et à ce titre est décrite par le type : { nas , nom, syndicat}. Cependant, p2 n’étant pas spécialisée aura le type de Personne. A l’implémentation, l’ouvrier o1 a une structure de 3 attributs et cette instance peut cohabiter sur disque avec les instances de Personne qui en possède deux seulement. 2) Ouvrier ∪ Technicien ⊂ Personne avec card(Ouvrier) + card(Technicien) <= card(Personne) Dans la base, il peut y avoir des instances des trois structures ou types : Personne avec ses attributs spécifiques, Ouvrier et Technicien avec ses attributs propres augmentés de ceux hérités

Personne nas* nom

Ouvrier syndicat

Technicien corporation

p, e

Les instances de Personne

p5 p2 p4 p3 p1

o1 t3 t5

E/A

2 instances sont réelles



128

de Personne. Les entités de Personne non spécialisées représentent des entités qui ne sont ni du type Ouvrier, ni du type Technicien. Cependant, toute instance d'une sous-classe en est aussi une de la superclasse parce qu'elle satisfait le type de la superclasse. En effet, dans cet exemple le type de la superclasse impose la présence de deux attributs typés qui sont par héritage aussi présents dans une entité de la sous-classe. La spécialisation partielle ou incomplète peut être vue comme une opération spécialisation avec un ensemble incomplet de sous-classes. Ainsi, la spécialisation de Personne est limitée pour le moment aux classes Ouvrier et Technicien, mais éventuellement d’autres sous-classes pourraient être ajoutées. Par exemple, les sous-classes Ingénieur, Physiciens, Biologiste pourraient être ajoutées pour éventuellement toutes les avoir pour en arriver à une spécialisation totale. Exemple de l’évolution du schéma : ajout d’une nouvelle classe

MCD-1 MCD-2 Figure 3.41a

Les propriétés de la spécialisation dans MCD-1 sont respectivement partiel (p) et exclusif (e) parce qu’il existe un autre sorte d’hélicoptères qui ne sont pas représentées par une classe présentement absente. Plus tard, cette troisième classe pourrait être ajoutée (MCD-2) permettant de spécialiser les instances de Helicoptere, les seules qui ne pouvaient l’être avec le MCD-1. En ce faisant, le modèle enrichi permet maintenant de tout spécialiser vers les sous-classes. De fait, les propriétés deviennent (t, e). Avec le formalisme UML, les propriétés sont {complete, disjoint}. Partitionnement : exclusivité et chevauchement (e, o) La spécialisation est exclusive si une instance de la superclasse est spécialisée en une seule de sous-classe. Il y a non exclusivité (overlapping) si une instance de la superclasse peut être simultanément spécialisée en dans les deux sous-classes. Voici un autre exemple qui ajoute à ce qu’il a été vu précédemment. Avec ce modèle, les véhicules qui ne sont ni une auto ni un camion ne peuvent être représentés par des instances de la superclasse Véhicule parce qu’elles devront être obligatoirement spécialisées dans une sous‐classe qui ne correspond à leur sémantique. Une moto n’est ni une auto, ni un camion ! Dans ce cas, a1 est décrit par les attributs {noSerie, traction}, tandis que l’instance v1 devient une instance virtuelle.

Helicoptere

HelicoTransport HelicoPassager

p,e

Helicoptere

HelicoTransport HelicoPassager

t,e

HelicoGuerre



129

Figure 3.42

Auto ⊆ Vehicule et Camion ⊆ Véhicule

avec card(Véhicule) = card(Auto) + card(Camion) Overlapping (chevauchement) Le MCD de la figure 3.43 modélise seulement les sportifs qui sont joueurs de foot et/ou joueurs de tennis. La spécialisation de cet exemple est pilotée dans l’application par un prédicat formulé avec l’attribut sorte : Si sorte = ‘foot’ alors spécialiser cette instance comme une instance de JoueurFoot.

Figure 3.43

Il est donc possible de retrouver le même sportif à la fois comme JoueurFoot et comme JoueurTennis. Les sportifs dʹune autre discipline ne peuvent pas être représentés avec ce modèle en raison de la couverture totale qui caractérise cette spécialisation. JoueurFoot ⊆ Sportif et JoueurTennis ⊆ Sportif et card(JoueurFoot) + card(JoueurTennis) >= card(Sportif)

Les instances de Vehicule (toutes virtuelles)

v5 v2 v4 v3 v1

a1 c3 c5 a1 c4

Vehicule noSerie*

Auto traction

Camion capacite

t, e

E/A

sorte ='tennis' sorte ='foot'

Sportif nas* club sorte

JoueurFoot J f

JoueurTennis

t, o

Les instances de Sportif

s2 s3 s1

jf1 jt2 jf2 jt3



130

En résumé, les combinaisons possibles pour les propriétés de couverture sont les suivantes : (t,e), (t,o), (p,e), (p,o). La couverture de chaque spécialisation est choisie pour se conformer le plus possible à la réalité à modéliser. Normalement, si la superclasse est obtenue par généralisation, elle est totale, c'est-à-dire que toutes ses instances seront spécialisées. La généralisation partielle apparaît normalement par la voie de la spécialisation d’une classe. Cas particulier: sous‐classe unique dans une hiérarchie d’héritage Cette généralisation/spécialisation particulière est partielle ou totale et forcément exclusive, (p,e), (t,e) puisqu'une seule sous-classe intervient dans l'abstraction. Le carré utilisé pour regrouper les propriétés de la spécialisation peut être supprimé et remplacé par une lettre entre deux chiffres, p ou t.

Figure 3.44 Normalement une telle spécialisation est partielle. Une spécialisation totale de ce type ne comporterait pas beaucoup d’intérêt, car elle correspondrait à une représentation équivalente par une seule sous-classe, soit ici OuvriersPermanents (figure 3.44). en terme de représentation, aucun gain n’est réalisé avec une spécialisation totale. Spécialisation en cascade Une sous-classe de la hiérarchie peut être elle-même spécialisée pour hériter de tous les attributs à partir de la racine. Par exemple, une instance de la classe CEssence de la figure 3.45 décrit donc un véhicule de type camion avec un moteur à essence. La structure d'une instance de CEssence sera composée des attributs de Véhicule obtenus par héritage enrichis avec ceux de Camion et à nouveau augmentés par ceux spécifiques à la classe CEssence. Cet héritage pourrait être implémenté dans un système SGBD qui gère un modèle objet ou relationnel-objet. En relationnel, cet héritage n’est pas implémenté comme tel et doit être simulé par le biais d’un schéma relationnel enrichi. La version 9i du SGBD Oracle, les systèmes Gemstone, O2 et Jasmine implémentent directement cet héritage.

Ouvrier nas* nom

OuvrierPermanent dateConfirmation

(p)



131

Figure 3.45 Héritage (simple et multiple) En raison du mécanisme inhérent à la généralisation, les attributs de la superclasse sont visibles par chaque sous‐classe de sa hiérarchie. C’est l’héritage des attributs est implémenté directement dans les systèmes SGBD objets ou relationnels‐objets.

Héritage simple Figure 3.46

L’héritage est simple si la classe générique ou superclasse est unique; il est multiple s’il y a plusieurs classes génériques pour une même sous-classe. Avec les SGBD relationnels l'héritage n'est pour le moment qu'un outil de modélisation qui permet de découvrir de nouvelles associations et de simplifier parfois la structure du MCD. A l'implémentation, l'héritage dans le MCD se traduit pour le cas (t,e) par l'adjonction des attributs de la superclasse à ceux de la sous-classe. La nouvelle génération de SGBD à objets offre ce mécanisme de spécialisation aux concepteurs de MCD et aux développeurs qui utilisent le modèle logique à objets pour les

Instances de Vehicule (toutes virtuelles)

v5 v2 v4 v3 v1

a1 c3 c5 a1 c4

Vehicule noSerie

Auto traction

Camion capacite

t, e

CDiesel gazole

CEssence octane

p, e

e3 e3

Instances de CEssence

E/A

Instances de Camion 2 virtuelles et 1 réelle

Vehicule noVignette* annee

Auto modele nbPassager

Utilitaire volumeBenne chargeMax

c,d



132

applications (par exemple la méthode UML). L’héritage simple de la figure 3.46 tient au fait qu’une sous-classe n’hérite que d’une seule classe générique. Par contre, si une sous-classe peut hériter des attributs de plusieurs classes génériques, l’héritage est dit multiple (figure 3.47). Voici un exemple E/A pour illustrer cette sorte d'héritage.

Figure 3.47 Héritage multiple des attributs

Un moniteur de labo est un employé et aussi un étudiant. C'est donc une instnce dont le type est spécifié par ses attributs propres en sus de ceux hérités des deux superclasses Employe et Etudiant. L’héritage multiple peut engendrer un conflit de nom d'attribut. En effet, par héritage automatique, un même nom d’attribut peut être hérité de plusieurs classes génériques et avoir une sémantique différente selon la source d'héritage. Le renommage des attributs vient donc préciser la sémantique. Ce problème ne se pose pas dans un SGBD relationnel, car le passage au MCD résout les conflits de nom en préfixant l'attribut hérité par le nom de la superclasse. Ici encore, l'héritage double signifie que toute instance de Moniteur est définie par les attributs hérités de Employe et de Etudiant qui s'ajoutent aux attributs propres de Moniteur. Plusieurs structures de généralisation/spécialisation avec une même classe On peut dans certains cas particuliers spécialiser une même classe générique de plusieurs façons selon les besoins de la modélisation. Lorsqu'une employée est architecte avec en sus la responsabilité administrative de chef d'équipe, la spécialisation selon la tâche avec la couverture (p,e) n'est pas suffisante pour représenter les employés qui ont un rôle de chef d'équipe (voir figure 3.48). Il faut une 2e spécialisation partielle pour représenter ces employés. Pour les différentes spécialisations distinctes, il faut préciser les propriétés de couverture et de chevauchement. Une même classe peut faire l’objet de plusieurs spécialisations, chacune ayant ses caractéristiques.

Employe nas* nom

Etudiant nas* nom adresseLocale

t, e

1erCycle programme

2eCycle dirRech

p, o

Professeur specialite

Moniteur noLabo

Héritage multiple



133

Plusieurs spécialisations de la même classe Figure 3.48

La superclasse Employe est spécialisée de trois façons indépendantes et différentes. Une employée du secrétariat est représentée entièrement par une entité dont les attributs sont ceux de la superclasse Employe et ceux de la sous-classe Secretaire. Une employée architecte qui est permanente et chef d’un projet se retrouvera décrite dans trois sous-classes du MCD. Lorsque les spécialisations sont multiples, il peut y avoir une certaine redondance des attributs. Ainsi, le nas de Employe est hérité par la classe Permanent et aussi par la classe Architecte et par celle du Chef. Cette redondance dans le MCD et dans la base de données qui s'en suit devra être contrôlée automatiquement lors de l'exploitation de la base. 3.11 Catégorie Lorsqu’une généralisation comporte plusieurs superclasses et qu’une sous-classe hérite de l’une ou l’autre des superclasses, mais pas de plusieurs, cette sous-classe est appelée une catégorie (10). Dans le modèle ci-dessous, le propriétaire d’un véhicule a une structure de l’une des trois classes : Personne, Ministere ou Societe. C’est en quelque sorte l’héritage multiple proposée pour enrichir les primitives de modélisation de E/A.

t,e

Permanent salaire

Occasionnel tauxHoraire

Projet noProjet

Gere

Chef mandat

Employe nas* nom

Technicien classification

Secretaire specialiteBur

Architecte titre

p,ep

E/A



134

Figure 3.49 La catégorie est partielle si une partie seulement des instances de la superclasse est spécialisée. La catégorie est totale si toutes ses instances sont spécialisées. Dans cet exemple, la classe Proprio est une catégorie partielle parce que certains ministères ou certaines sociétés ne sont pas propriétaires.

(Catégorie partielle): Proprio ⊂ Personne ∪ Ministere ∪ Societe Par contre, la catégorie Vignette est totale puisque tout véhicule, voiture ou camion, a une vignette. (Catégorie totale): Vignette ⊆ VVoituree ∪ VCamion

Proprio adresse statut sorte

Personne nas* noPermis

Ministere nom* ministre

Societe nomCorpo* secteur

∪

Atelier noAtelier* specialite

p

Vignette noVignette* prix sorte

VVoiture categorie*

VCamion chargeMax*

∪

t

sorte = 'c'

catégorie

Possede

Travaille

Dans ce MCD, les multiplicités ne sont pas



135

Dans cette abstraction, la classe Vignette a aussi été généralisée vers deux superclasses sur la base de la valeur de l'attribut sorte. Elle devient alors une catégorie qui hérite des attributs soit de VVoiture, soit de VCamion selon la valeur de l’attribut de spécialisation sorte. En effet, tout accès à une instance de Vignette accède automatiquement aux attributs de l’une des classes génériques qui correspond à sa généralisation. La catégorie Vignette est aussi une catégorie totale parce que dans cet exemple toute vignette en est une d’une voiture ou d’un camion et inversement. La spécialisation de chaque superclasse en une catégorie est faite sur la base dʹune fonction de catégorisation FC. Cette fonction FC contrôle lʹhéritage des attributs de l’une des superclasses.

Figure 3. 50 Ainsi, en accédant à une entité de Vignette, la valeur de la fonction (FC) utilisée pour la généralisation/spécialisation précise quelle est la superclasse qui est la source des attributs hérités. La catégorie est donc une partition d'une classe (ou Entité) avec des structures différentes. Il est possible de représenter une catégorisation totale par une généralisation totale. Par exemple dans la figure 3.50, la modélisation des usines agréées pour la production peut être faite en les regroupant en usine internationale, usine nationale et usine locale. Catégorisation totale :

UsineAgreee ⊆ Usinter ∪ UsNat ∪ UsLoc UsInter ∪ UsNat ∪ UsLoc ⊆ UsineAgreee

Généralisation totale : UsineAgreee ⊆ UsiInter ∪ UsNat ∪ UsLoc

UsineAgreee noUs* ville sorte-u

UsInter permisEuro siegeSoc

UsNat noCorpo pays

UsLoc ville

t, e

UsineAgree noUs ville sorteUs

UsInter permisEuro* siegeSoc

UsNat noCorpo* pays

UsLoc ville*

∪ t

Généralisation Catégorisation



136

UsInter ∪ UsNat ∪ UsLoc ⊆ UsineAgreee Dans le cas de la spécialisation, les entités de la classe UsineAgreee sont totalement regroupées en trois sous-classes distinctes. Comme la spécialisation est totale toute entité de la réunion des sous-classes appartient aussi à l'ensemble UsineAgreee et inversement. En accédant à une sous-classe, les attributs de celle-ci sont rendus disponibles en plus de ceux hérités de la superclasse UsineAgreee. Dans le cas d'une catégorie, l’accès à une instance de UsineAgreee permet d'obtenir ses attributs propres plus ceux de l’une seulement des superclasses.

Figure 3.51

La catégorie UsineAgreee a donc une structure qui varie selon l'instance obtenue par héritage. La couverture de la généralisation de la figure 3.51 est partielle, alors la sémantique devient différente de celle de la catégorie partielle. En effet, il devient possible d'avoir une usine agréée qui n'est pas spécialisée donc décrite par 3 attributs, tandis qu'avec la catégorie partielle de la figure 3.51, toute usine agréée hérite par la catégorie les attributs lui conférant une structure plus complexe, i.e. composée de 4 attributs. La catégorisation partielle est pilotée par un attribut ajouté dans UsineAgreee, soit sorte-Us qui précise la superclasse qui est la source de l'héritage. Généralisation partielle :

UsInter ∪ UsNat ∪ UsLoc ⊂ UsineAgreee Catégorisation partielle : UsineAgreee ⊆ UsiInter ∪ UsNat ∪ UsLoc

En résumé, la catégorisation totale peut être remplacée par la généralisation totale qui a un équivalent en langage UML. Pour ce qui a trait à la catégorisation partielle, il faut la tolérer ou la remplacer par une abstraction approximative, mais non équivalente. Héritage des associations

Catégorisation

UsineAgreee noUs ville sorteUs

UsInter permisEuro* siegeSoc

UsNat noCorpo* pays

UsLoc ville*

∪ p

Généralisation/Spécialisation

UsineAgreee noUs* ville sorteUs

UsInter permisEuro siegeSoc

UsNat noCorpo pays

UsLoc ville

p, e



137

Une superclasse peut aussi avoir une association (et des attributs propres) avec une autre classe du modèle. Cette association est aussi l'objet de l’héritage par les sous-classes d’une spécialisation et cela, au même titre que les attributs. De plus, l'association peut être l'objet d'une spécialisation pour générer autant de nouvelles associations qu'il y a de sous-classes. Cette spécialisation de l'association en modifie aussi la sémantique (voir les exercices résolus) et justifie parfois le renommage. Type d’une sous‐classe Une sous‐classe a un type (structure) défini par un enrichissement de ses attributs par héritage. Rappelons que le type est en quelque sorte un ensemble nommé de règles, lesquelles doivent être vérifiées par toute instance ou tout objet qui appartient au type. Type de la sous-classe =

{attributs de la sous-classe} + {attributs de la superclasse} De même, une instance de la superclasse appartient à une sous‐classe si chaque valeur dʹattribut de celle‐ci vérifie le type des attributs de la première. Ainsi on peut conclure quʹune instance de sous‐classe appartient aussi à la superclasse puisquʹelle satisfait les règles de la sous‐classe, mais aussi celles de la superclasse pour les attributs obtenus par héritage. Critères de modélisation Tout au long de la modélisation des données, le concepteur doit faire divers choix : a- Représentation par une classe ou un attribut ? La question est de décider si un objet ou un concept du monde réel doit être représenté comme une classe ou un attribut. La décision doit se prendre à partir de la réalité à modéliser et en se référant, au besoin à la règle de l’existence autonome. Il n’en demeure pas moins que ce choix est souvent intuitif et que le résultat est généralement satisfaisant. b- Généralisation La généralisation/spécialisation doit être utilisée avec une classe chaque fois que certains attributs de la classe ne sont pas "valuables" avec certaines de ses instances. c- Attribut composé /simple L’attribut composé est préféré chaque fois qu’un nom significatif peut être donné à un ensemble d’attributs atomiques et qu’un type complexe approprié est implémenté dans le logiciel utilisé. Sinon, les attributs simples sont choisis. 3.12 Les pièges à éviter en modélisation conceptuelle Dans la modélisation, il peut se poser quelques difficultés avec l’exploitation du modèle de sorte que des interprétations fausses découlent de l’exploitation des données du modèle. Le Fan Trap Les associations entre les classes du MCD sont telles que les instances des associations posent des problèmes d’ambiguïté, notamment lorsque associations 1..1 émergent de la même classe.



138

Le MCD précédent doit pouvoir représenter un employé qui travaille dans un seul atelier. Or il y a deux chemins pour aller d’une instance de Employe à une autre de Atelier n’est pas unique Sachant qu’un ouvrier travaille que dans un seul altelier, la réponse à la question suivante est ambigue : dans quel atelier travaille l’ouvrier e1 ? Est-ce dans a1 ou dans a2 ? Solution au fan trap Le MCD est réorganisé de manière à associer l’employé à l’atelier et ensuite au département. En ce faisant, on supprime l’émergence de deux associations 1..1 de la même classe. Le nouveau modèle doit répondre à la question suivante : Dans quel atelier travaille l’employé Turgeon? La réponse est claire lorsque le modèle est réorganisé comme ci-dessous.

Instances de Employe

Instances de AssigneA

Instances de Departement

Instances de Opere

Instances de Atelier

e1 a1

a2

Employe matricule*

Atelier noAtelier*

Departement noDep*

1..*

1..1

UML

Opere

1..1

1..*

AssigneA



139

Cette réorganisation du MCD correspond à une vision plus réaliste de liens administratifs d’un employé. Le Chasm Trap Le MCD présente une association entre deux classes, mais cette association n’existe pas au niveau de toutes les instances en raison de la présence d’une participation partielle i.e. d’un min égale à 0 sur le chemin allant d’une classe à une autre, comme par exemple de Agence à Maison.


Instances de Opere

Instances de Departement

Instances de Assigné-A

Instances de Atelier

d1

d2

e1

Employe matricule*

Atelier noAtelier*

Departement noDep*

1..*

1..1

UML

Opere

1..1

1..*

AssigneA

Employe matricule*

Maison noMandat*

Agence noAgence*

1..1

1..* 0..1

0..*

Travaille Vend



140

Il y a une instance de la classe Employe qui n’est pas atteignable par une instance d’association. Par exemple, il est impossible de répondre à la question suivante : Quelle est l’agence qui a le mandat de vendre la maison du 2345 Belmont? Si le mandat de vendre n’est pas attribué à un employé, il sera impossible d’y répondre. Si le mandat pour cette maison est enregistré dans la base mais que la fiche de vente n’est pas attribué à un employé (comme cela est autorisé par la multiplicité), alors il ne sera pas possible de fournir le nom de l’agence. Cette difficulté n’a pas toujours de conséquences fâcheuses de sorte qu’il n’est pas toujours nécessaire de la supprimer. Correction du Chasm Trap Une solution consiste à créer dans le modèle une nouvelle association AMandat avec une participation obligatoire. C’est un nouveau chemin dans le graphe, entre Agence et Maison.

Employe matricule*

Maison noMandat*

Agence noAgence*

1..1

1..* 0..1

0..*

Travaille Vend

1..*1..1

AMandat

Instances Agence

Instances Travaille


Instances de Vend

Instances de Maison

2345 Belmont



141

Le Fan trap qui apparaît dans la solution est sans conséquence si dans une interrogation le chemin emprunté dans le MCD est exempt de la participation partielle (min= 0). Tel est le cas du chemin de la classe Employe vers la Maison via la classe Agence.

Exercices résolus 1- Le MCD ci-dessous modélise le lieu de travail des personnes. Une même personne peut avoir plusieurs lieux de travail selon qu’elle est pigiste pour une ou plusieurs entreprises. a- Modifier ce MCD pour représenter les personnes qui peuvent travailler à deux endroits: au bureau et au domicile. Lorsque la personne travaille à son domicile, elle travaille dans une ville et peut être jointe seulement par courriel. Lorsqu'elle travaille à son bureau d'affaires elle ne peut être jointe que par téléphone. Solution : Il sʹagit de représenter un nouveau concept, soit celui du moyen de communication qui est varie selon le lieu de travail. Lorsque le travail est au domicile, la personne peut être rejointe par

Personne nas* nom

LieuTravail nomLieu* ville

Travaille (0,n) (1,n)

Instances Agence

Instances Travaille


Instances de Vend

Instances de Maison

Instances de AMandat



142

Internet, tandis qu’au bureau elle peut être rejointe par téléphone. Ce fait peut être représenté par une nouvelle association dotée d’un attribut qui précise le moyen de communication. b-Représenter dans le nouveau modèle le fait qu'une même personne ne puisse pas avoir en même temps un bureau à son domicile et un autre à sa place d’affaires. Solution Il faut exclure la participation simultanée dʹune même personne aux deux associations. Cette exclusion mutuelle est représentée dans le formalisme Merise avec un cercle au centre duquel apparaît le signe +. c‐ Représenter le modèle initial avec les contraintes de lʹassociation par la cardinalité et la participation au lieu des contraintes (min, max) présentement utilisées. Solution : La représentation équivalente est la suivante : Les mêmes contraintes sont exprimées par celles la participation et la cardinalité. d- Formulez le MCD avec UML :

Personne nas* nom

Bureau nomBureau* ville

Travaille p m

t 1

Personne nas* nom

LieuTravail nomLieu* ville

TravailleB

(0,n)

(1,n)

TravailleD

(0,n)

(1,n)

noTel

noInternet

noTel

Personne nas* nom


TravailleB

(0,n)

(1,n)

TravailleD

(0,n)

(1,n)

no Internet

+

Personne nas* nom


Travaille 0..* 1



143

2- Modifiez le modèle ci-dessous pour représenter aussi le suivi des satellites de communications. Il faut pouvoir représenter aussi le suivi des satellites militaires qui sont inaccessibles aux antennes non autorisées, tandis que les satellites civils le sont sans restriction. Chaque satellite militaire est suivi obligatoirement par une écoute en temps réel par l’antenne suiveuse, tandis que le satellite civil est, dans certains cas, non suivi. La communication avec le satellite civil exige la connaissance d’une clé publique pour décoder les signaux, tandis qu’une clé secrète est nécessaire pour communiquer avec le satellite militaire. Voici la situation modélisée initialement. Solution : La spécialisation de Satellite se fait en deux classes exclusives, à savoir la classe du Satellite militaire et celle du Satellite civil. Chaque sous-classe comporte ses attributs propres. L'association Cible peut être déplacée vers les sous-classes en se spécialisant pour devenir Exploite et Suit (Tracking). 3- Comment est-il possible de traiter l’attribut date-mariage dans le modèle ci-dessous avec les cardinalités (0, 1). Solution : (une parmi plusieurs solutions possibles) : On peut le faire par spécialisation des classes d’origine et de l’association vers les sous-classes obtenues. Les contraintes (min, max) sont aussi ajustées.

AntenneTerrestre noAntenne* positionCourante sorte localisation

Satellite noSatellite* trajectoire spectreFrequence encodagePublic encodageSecret

Cible 0,1 0,n

Femme nas* ville

Homme nas* ville

EstMarie dateMariage

0,1 0,1

Suit

AntenneTerrestre noAntenne* positionCourante sorte localisation Exploite

0,1

0,n

Satellite noSatellite* trajectoire spectreFrequence

SatelliteMilitaireencodageSecret

SatelliteCivilencodagePublic

0,1

1,n

t,e

+



144

En cas de divorce, la femme et l’homme concernés ne sont plus en association. Elles sont supprimées de la base de données et, si cela est nécessaire, recréées comme une entité de la superclasse. Dans ce traitement, l'héritage de l'association est fait sans division par spécialisation. Ce traitement par spécialisation permet de supprimer la participation partielle pour l’association. Une autre solution serait de déplacer l’attribut dateMariage vers une des deux classes et de garder la participation partielle pour l’association. Cette solution sous-tend une valeur nulle pour l’attribut mariage, lorsqu’une femme n’est pas mariée, tandis que pour l’homme le fait de ne pas être marié n’est pas clairement modélisé, autrement que par sa non-participation à l’association. 4- Énoncez en français les contraintes structurelles (min, max) du modèle représentant la vente des sièges d'avion et de l’embarquement sur les vols commerciaux. Les clés du modèle illustré ci-dessous ne sont pas identifiées.

Femme nas* ville

Homme nas* ville

1,1 1,1 FemmeMariee dateMariage

HommeMarie

EstMarie p p

1,n

Quai noPorte terminal securite

Passager noTicket nom adresse ville classe

Siege noSiege noAvion

Reserve dateR

1,n

0,1

Vol noVol dateD heureD

Utilise Voyage

A

1,n

0,n

1,1

1,m 1,1

Femme nas* ville dateMariage

Homme nas* ville

EstMarie

0,1 0,1



145

Solution : Les contraintes sont les suivantes : a- Un quai d’embarquement est utilisé par aucun ou plusieurs vols. Chaque vol sous-tend un embarquement à un quai. b- Un passager réserve un ou plusieurs sièges à une date déterminée. Un siège peut ne pas être vendu. c- Une place assise dans un avion correspond à un ou plusieurs vols. Un vol doit avoir des places de passagers. d- Un passager doit voyager sur un seul vol qui pour sa part se fait avec plusieurs passagers. 5- Donnez les clés primaires du modèle ci-dessus et précisez les clés composées. Comment est-il possible de transformer ces dernières en clés simples ? Peut-on transformer la clé composée no-siège et priorité en clé simple noSiege ? Quelles hypothèses faut-il faire pour chaque clé ? Solution : Les clés choisies (primaires) sont les suivantes :

a) noVol : unique dans le système dans l’aviation civile; b) noTicket : global pour le système de transport des passagers. c) Les clés composées sont les suivantes : d) noPorte et terminal parce que le numéro d’une porte d’embarquement est local au

terminal. Pour remplacer cette clé, il suffit de définir un identifiant de porte global, ce qui peut ne pas correspondre à la réalité de l’aérogare;

e) -noSiege et no-avion parce qu’un siège portant un no correspond à celui d’un avion particulier. Le même numéro de siège peut se retrouver dans un autre avion.

Avantages et inconvénients de la modélisation E/A Le formalisme E/A est simple offre plusieurs mécanismes d’abstraction faciles à maîtriser. Il y a que quelques notions de bases : Entité et entité, association, attribut, la spécialisation et la catégorie. Ceux-ci sont suffisants pour représenter les structures statiques dont la complexité varie de faible à moyen. En revanche, la modélisation E/A est non déterministe. Aucun critère objectif ne permet de justifier l’usage d’une Entité ou d’un attribut pour modéliser un concept. Par exemple, dans la modélisation d’une collection documentaire, vaut‐il mieux représenter l’auteur d’un document comme une entité ou comme un attribut? Si l’attribut est privilégié, seul le nom de l’auteur sera inséré dans la base, tandis qu’avec une entité, il devient possible de fournir d’autres informations sur l’auteur et éventuellement les partager pour d’autres documents écrits par un même auteur. La deuxième faiblesse du formalisme E/A est importante. Il ne permet pas d’inclure dans la représentation d’une entité (i.e. d’un objet) les opérations disponibles pour en modifier le contenu. Le formalisme E/A est à la base de presque toutes les méthodes de représentation conceptuelle, mais il est concurrencé par le formalisme utilisé avec le UML. Dans ce dernier cas, les opérateurs sont inclus dans la description d’une entité de sorte qu’elle devienne encapsulée. Finalement, le UML intègre les méthodes OMT, celle de Shlaer‐Mellor, celle de Jacobson et ses use cases, celle de Booch et ses notions de catégorie et sous‐système, …La convergence de ces méthodes a donné lieu à la formulation d’un langage unifié pour représenter la modélisation par



146

objets, le UML. Ce langage de modélisation permet de capturer la structure statique, le comportement des objets, de représenter formellement les besoins des utilisateurs (Use cases de UML), les interactions entre les objets pour fournir les résultats attendus, de découper les unités de traitement et de préciser les détails de leur implémentation. Le grand mérite des formalismes de modélisation conceptuelle est de permettre une représentation graphique des structures de données qui reflète le plus la réalité et qui génère par des règles de transposition un modèle relationnel acceptable. Sommaire La modélisation des données est une étape essentielle dans l’analyse informatique qui précède lʹexploitation des données par un logiciel SGBD. Le formalisme E/A de qui est à l’origine de plusieurs méthodologies d’analyse a de nombreuses variantes, distinctes entre elles notamment par la façon d’exprimer les contraintes de cardinalité et de participation. L’introduction de l’abstraction de généralisation/spécialisation permet souvent de simplifier la modélisation et de ce fait facilite l’interprétation subséquente du MCD. Cette abstraction est aussi constructive dans le sens qu’elle permet de découvrir de nouvelles associations et de les exprimer plus simplement entre les sous‐classes spécialisées. Le passage du MCD au modèle logique d’implantation qu’il soit relationnel (MRD), en réseau ou hiérarchique est assuré par un jeu fini de règles de passage relativement simples. Il en sera autrement avec le modèle à objets dans lequel le passage ne pourra être fait qu’en exploitant de façon appropriée les types de données complexes. A terme il est à prévoir que le formalisme UML remplace tous les autres formalismes. La gestion des données occupe une place importante dans le fonctionnement des organisations. Elle est tributaire des systèmes de gestion de bases de données et des réseaux. L’évolution des logiciels SGBD est marquée par la généralisation de cet outil qui assume des fonctions capitales de stockage, de recherche, de partage et de validation de la cohérence des données. Les utilisateurs de ces systèmes sont l’ensemble des acteurs d’une organisation à tous les niveaux de responsabilité. Le volume des données à gérer est très souvent astronomique et les types de plus en plus variés. Le rôle essentiel du SGBD consiste à assurer une continuité des services dʹaccès aux données qui sous‐tend un soutien efficace du personnel technique dont la spécialisation et la compétence sont critiques dans le fonctionnement de la base de données. Les nouvelles architectures, notamment de type client‐serveur, favorisent le redéploiement des ressources informatiques selon un mode qui privilégie la décentralisation du traitement et, éventuellement, celle des données. La prochaine génération de SGBD qui exploitera davantage la technologie Internet donnera lieu à de nouveaux modèles.



147

Exercices du chapitre 3

ALU‐NORD : Modèle conceptuel La société ALU-NORD fabrique des pièces moulées en aluminium dans différentes usines spécialisées réparties dans le monde. Les usines implantées obligatoirement dans différentes villes produisent diverses pièces sur commande; ces dernières sont le plus souvent stockées sur place et livrées entièrement à la fin de la production. Le matériau en vrac est livré en volume prédéterminé par le fournisseur sur commande de chaque usine. Les fonctions de gestion des ressources humaines se limitent à gérer un dossier sur chaque ouvrier. L’implantation de cette base doit se faire en validant le plus possible les contraintes de participation et de cardinalité et cela sans développer de triggers dans cette première phase de création de la base. Voici quelques-unes de ces contraintes d’exploitation qui découlent du MCD : - La suppression d'un métier entraîne celle de sa participation à l'association Titularise et du même coup, la suppression des ouvriers compétents dans ce métier. - Il est possible de supprimer une entité dans VracMat si et seulement si sa participation à l'association Utilise est aussi supprimée. La suppression d'une usine entraîne aussi celle de ses productions, mais pas de ses ouvriers, ni des matériaux en vrac qu’elle utilise.

Production noPiece* lot* qte dateDebut delai

Realise(1,1)

Client noclient* ville credit

Achete (1,n) (0,1)

Ouvrier nas* nom prenom sexe dNaiss embauche

Metier noMetier* classe-metier taux

Titularise (1,n)

Usine noUsine* ville capacStock surfaceUsine

VracMat noNat* noFourn* volL cat

Travaille (0,1)

(0,n)

Commande (0,n) (0,m) VolC

(0,n)

(1,1)



148

Sémantique de quelques attributs : dNaiss Date de naissance de l'ouvrier comprenant le jour, le mois et l'année. embauche Date du premier contrat de travail exprimée avec le jour, le mois et

l'année. classeMetier Classes de compétence pour un métier identifiées par un entier de 1 à 5. capacStock Nombre de pièces pouvant être conservées à l'usine dans une enceinte

dont la surface représente obligatoirement 10% de celle de l'usine. lot Unité de production d'une sorte de pièces correspondant à une

commande. delai Nombre prévu de jours pour la fin de la production d'un lot de pièces. volL Quantité minimale d'un matériau en vrac pouvant être livré à une usine. noMetier Identifiant pour un métier exercé par plusieurs ouvriers. cat Qualité du matériau en vrac fourni ou livré par un fournisseur. qte Quantité de pièces produites dans un lot de production. VolC Volume de matériau en vrac commandé par une usine. C’est un multiple

du volume. surfaceUsine Surface totale de l'usine dont 10% est consacré à l'entreposage. nas Numéro assurance sociale sous forme d'une chaîne composée de chiffres. Voici, à titre d'information seulement quelques règles plus complexes sous-tendues par le MCD et qui ne seront pas au départ validées dans la base, car cela exigerait l’utilisation de triggers et de packages. Un métier n’est inscrit dans la base que si un ouvrier est qualifié pour le pratiquer dans son travail. Un client n’est représenté que s’il a effectué au moins l’achat d’une production complétée par une usine. Globalement, il ne peut pas y avoir plus de 10 métiers différents dans tout le réseau des usines. Ainsi, le même matériau ne peut pas être fourni par plus de quatre fournisseurs. Ces contraintes seront formulées éventuellement dans le schéma dans la mesure où le SGBD utilisé pour l'exploitation le permet. Le modèle ALU-NORD est un graphe acyclique. Domaines de quelques attributs Certains attributs ont un domaine sémantique particulier défini dans le tableau ci-dessous. Par définition, l’indicateur de null est hors domaine. Le domaine des autres attributs est considéré comme étant implicite et dérivé des extensions des tables.

cat: { 'A', 'B', 'C, 'D’} capacStock: ]10...9999] volL ]0... 1000]

classeMetier : { 1...5} taux: ]10.00 ... 32.75] lot : ['b10'.... 'b99']

noMetier : [‘j1’... ‘j100’[ surfaceUsine:]100...5000] nas : chaîne de 9 car.

sexe : {'F', 'M'} noUsine : ['u10’...’u99’] credit:[1000....10000]

N.B. Un crochet ouvert par la gauche ou par la droite indique une borne exclue du domaine. Un crochet fermé par la gauche ou par la droite indique l'inclusion de la borne dans le domaine. L’indicateur de null n'est pas une valeur du domaine, mais correspond quand même à une réalité



149

pour quelques attributs, notamment les attributs délai et no-usine. Les attributs dont le domaine n’est pas défini explicitement doivent être spécifiés en accord avec les données fournies par les tables. Remarques : 1- De par la contrainte sur la capacité de stockage, toute production inférieure à 11 unités doit quitter l'usine immédiatement et donc être livrée au client. Cette petite production exceptionnelle n'est donc pas inscrite dans la BD et n’est pas stockée dans la BD, ce qui explique la définition du domaine sémantique pour cet attribut. 2- La sémantique de plusieurs attributs peut être dérivée du contexte de la relation. La connaissance des données a aussi permis de formuler quelques règles de validation syntaxiques qui viennent en restreindre le domaine et qui seront renforcées dans le schéma de la base ALU-NORD.

Attribut Validation syntaxique nas chaîne de 9 caractères représentant des chiffres

seulement noFourn 1ère lettre est un 'f' noMetier 1ère lettre est le caractère 'j' et sa longueur max. est 3 noUsine 1ère lettre est le caractère 'u', les autres étant des chiffres.

La longueur max. est 3 noClient 1ère lettre est le caractère 'c' noMat Chaîne dont la 1ère lettre est le caractère 'm ' nom Chaîne de lettres en majuscules prenom 1ère lettre est un haut de casse. Les autres lettres sont des

caractères éventuellement mixtes. noPiece 1ère lettre est un 'p' et la dernière un caractère chiffre lot 1ère lettre est un 'b'

Interprétation du modèle de la BD A moins d'une indication contraire, vous faites seulement référence au MCD et aux contraintes formulées dans le texte pour répondre aux questions ci-dessous qui visent à évaluer votre capacité à interpréter correctement le MCD. Commentez brièvement vos réponses. 1- Est-ce qu'un matériau en vrac (VracMat) utilisé par les usines de la base de données peut l'être par plusieurs usines? 2- Est-ce qu'un même matériau peut être fourni par plusieurs fournisseurs? 3- Est-ce que deux usines distinctes peuvent utiliser un même matériau, mais de fournisseurs différents? 4- Est-ce qu'une usine peut fabriquer plusieurs pièces de même numéro?



150

5- Est-ce qu'un ouvrier peut être inscrit dans la base de données sans travailler dans une usine? 6- Que faut-il spécifier au regard d’un attribut pour que le stockage dans une usine quelconque de ce modèle ne dépasse pas la limite supérieure de 15 000 pièces? 7- Quel effet aura la suppression d'une production dans la base de données? 8- Est-ce qu'une usine peut être représentée dans la base de données sans avoir commandé aucun stock de matériau en vrac (VracMat)? 9- Combien de métiers peuvent être représentés dans cette base de données? 10- En théorie, quelle est la contrainte entre la quantité d'une pièce fabriquée dans une production et la capacité de stockage de celle-ci à l'usine de production? 11- Est-ce qu'une usine sans ouvrier peut utiliser un matériau en vrac pour faire une production? 12- Est-ce qu'un ouvrier doit avoir un métier pour être représenté dans la base de données? 13- Est-ce qu'une usine planifiée par le siège social de la société ALU-NORD qui gère le réseau d'usines peut être représentée dans la base de données même si la ville d'implantation n'est pas encore définitivement choisie? Commenter votre réponse. 14- Commenter le cas d’une production sans client. Imaginez une situation où cela peut être représenté. 15. En cas de fermeture d'une usine, i.e. la cessation de la production, si les productions en stock sont conservées sur place, quelle modification faut-il apporter au MCD sans avoir à créer de nouvelles entités ou associations? 16- Comment faut-il modifier le MCD pour représenter le fait qu'une usine peut commander les matériaux en vrac d'un seul fournisseur? La modification doit être minimale. Quel est l’impact de ce changement sur la représentation du modèle? 17- Décriver brièvement une procédure logique de fouille des données représentées par le MCD pour compter combien d’instances de VracMat n'ont jamais été livrées à une usine. Supposer qu’il existe une fonction Test(assoc) permettant de vérifier si une instance participe ou non à une association. Cette fonction retourne Vrai ou Faux. 18- Comment est-il possible de savoir à partir du MCD si une usine donnée a une production en stock? 19- En principe, quelle est la plus grande densité (nombre de pièces au mètre carré) possible pour le stockage des pièces dans une usine? 20- Quelle est la contrainte entre les attributs volC et volL de l'Entité VracMat et de l'association Utilise?



151

21- La gestion des usines de ALU-NORD est transformée afin de favoriser une approche de décentralisation. Dorénavant, une usine peut avoir un chef assigné sur place aux opérations de gestion d'une usine. Modifier le modèle pour représenter le chef qui dirige obligatoirement une usine. Un même chef peut diriger jusqu'à 4 usines, mais une usine n’a qu’un seul chef. Les attributs du chef sont les suivants : nas, debutMandat, age, sexe, nom. Insérer obligatoirement une généralisation/spécialisation dans le MCD. 22- Représenter le MCD ALU-NORD avec un autre formalisme de votre choix dans lequel les contraintes d'association sont exprimées autrement que par le (min, max). Vous pouvez utiliser le formalisme OMT, UML ou Merise. 23- En vous reportant au MCD RH ci-dessous qui représente les ressources humaines dans une entreprise, décrivez le genre de structures logiques de données possibles (aussi nommées structures conceptuelles) pour les entités (instances logiques) que l'on pourrait retrouver dans la base de données correspondante. Une structure logique est définie comme l’ensemble des attributs (ou valeurs) composant la définition d’une Entité et cela, sans égard à l’implémentation physique du modèle. 24- S'il fallait dans cette base de données représenter le fait que certains actionnaires soient aussi des employés, quelle modification minimale faut-il apporter au modèle pour pouvoir les représenter? Le MCD obtenu est nommé MCD RH1. 24.1 Quelle autre modification faut-il apporter si tous les actionnaires sont aussi des employés? 24.2 Modifiez le modèle pour représenter les propriétés des spécialisations par les contraintes (min-max) équivalentes. 25- Le modèle conceptuel PUBLI ci-dessous représente la publication et la révision des livres et des articles scientifiques publiés par des éditeurs. Compléter le modèle en y ajoutant les contraintes (min, max) pour les associations et les propriétés de spécialisation concernées directement ou indirectement par les faits ci-dessous. Vous ne devez pas modifier le modèle en ce qui a trait aux Entités et aux Associations. Le nom des associations est implicite et n’a pas à être précisé.

Employe salaire dep

Actionnaire nbVote

Client margeCredit

Personne nas* nom adresse

p,e p



152

Voici les contraintes des Entités et des Associations : a- Les livres sont écrits et révisés que par certains employés des éditeurs qui à ce titre reçoivent un salaire. Les articles sont écrits et révisés que par des pigistes bénévoles. b- Les éditeurs peuvent publier plusieurs livres et ils peuvent aussi publier plusieurs revues.

c- Certains éditeurs publient seulement des livres, d'autres seulement des revues et certains à la fois des livres et des revues. d- Un livre ou une revue est publié par un éditeur. e- Un auteur peut écrire des livres et des articles (c’est-à-dire les deux sortes de documents). f- Un livre n’est signé que par un seul auteur, tandis que les articles sont parfois co-signés par plusieurs. g- Un auteur d’article ou de livre ne peut pas réviser son propre document. h- Les pigistes et les auteurs inscrits dans la base ont respectivement révisé ou écrit au moins un article et un livre. Ainsi, un pigiste doit avoir rédigé un article, tandis qu’un auteur doit avoir écrit un livre. i- Une revue publie plusieurs articles. j- Un article est publié dans une seule revue. k- Un livre ou un article doit être révisé, éventuellement par plusieurs réviseurs.

Editeur

Livre Revue

Article

PigisteBenevole

AuteurArticle

ReviseurArticle

AuteurLivre

Auteur

ReviseurLivre

EmployeEditeur



153

l- Chaque réviseur d'un livre et chaque auteur d'un livre est un employé d'un éditeur. m- Un réviseur de livre n'est pas un réviseur d'article. n- Un éditeur embauche plusieurs personnes de fonctions différentes, notamment des rédacteurs et des réviseurs.

26‐ Quelle modification minimale faut‐il apporter au MCD RH si tous les clients sont aussi des actionnaires, mais jamais un employé? 27- Avec le MCD ci-dessous quelle modification faut-il apporter pour représenter le fait qu'un employé travaille dans un atelier et cela pour plusieurs périodes différentes. Une période étant définie par une paire de dates : (dateDebut: 12-3-1998, date-fin: 15-4-1998). 28- Transformez les contraintes (min, max) du modèle PUBLI ci-dessus pour les exprimer par celles de participation et de cardinalité. Inscrivez directement les contraintes sur le schéma. 29- Que faut-il ajouter au modèle PUBLI pour qu'un auteur ne révise pas son propre article ou livre? De même, comme les auteurs et les réviseurs d'articles ne sont pas payés, ils ne sont pas des réviseurs de livres. Comment cette contrainte peut-elle être représentée dans le modèle PUBLI en ajoutant une nouvelle Entité. 30- Vous devez développer un modèle qui doit comprendre une catégorie et une spécialisation. Dans une université, il y a une banque de CoursEnClasse et de CoursEnLaboratoire. A chaque trimestre, la direction de chaque département offre certains cours en les inscrivant à l'horaire-trimestre. Chaque cours à l'horaire d'un trimestre est annoncé par une page web et cette page est consacrée à un seul cours. Chaque page est hébergée sur un serveur géré par une des unités administratives de l'université, ou par un prestataire de services externes (PageWebExterne) ou par les deux. Les informations décrivant les Entités (classes) de ce modèle sont les suivantes :

CoursEnClasse : noCours*, description CoursLabo : noLabo*, materielRequis CoursHoraireTrim: salle, jourHeure et enseignant + autres attributs (1) PageWeb : url* PageWebInterne : uniteAdm, url PageWebExterne : coutJour, tel, url

(1) Les autres attributs sont en nombre variable selon qu'il s'agit d'un coursHoraireTrim qui est un cours en classe ou un cours de laboratoire.

Employe nas* nom adresse

Atelier noAt* budget

Travaille dateDebut dateFin



154

31- Dans une société-conseil, les employés effectuent des tâches de secrétariat, d’autres de technicien et d’autres d’informaticien. Un employé est défini par son nas et son nom de famille, ce dernier étant composé du nom et du prénom. Une personne qui travaille au secrétariat est singularisée par sa maîtrise d’une seule langue étrangère, tandis que le technicien l’est par la connaissance quelques langages de programmation qu’il maîtrise parfaitement. Pour sa part, l’informaticien a une spécialité, notamment parmi les suivantes : réseautique, commerce électronique, analyse-objet et multimédia. Donnez le MCD selon le formalisme E/A de (diagramme avec bulles et ovales) le plus simple possible capable de modéliser ces informations en faisant appel à l’abstraction de spécialisation/généralisation et en tenant compte des caractéristiques propres à chaque attribut. Vous pouvez utiliser les attributs complexes, composés, multivalués et monovalués. La catégorie totale peut être aussi utilisée car une spécialisation totale est équivalente à une catégorie. 32- Modélisation des œuvres d’art d’un musée (MCD ART) Un musée national présente deux collections importantes à savoir les peinture et les sculptures. La première est permanente et les œuvres appartiennent au musée, tandis que certaines sculptures de la deuxième collection appartiennent à des personnes qui en ont fait un prêt au musée. L’importance de certaines sculptures et peintures oblige le musée à prendre une assurance appropriée. Il n’y a rien qui limite la générosité des prêteurs; ceux‐ci peuvent prêter plusieurs oeuvres. Une peinture est décrite par un no de peinture, auteur, année, salle. Une sculpture est décrite par un no de sculpture, auteur, poids et matériau. Finalement, l’œuvre assurée est celle protégée par une assurance contractée, décrite par le nom de l’assureur, le montant, la prime et l’échéance. Les personnes propriétaires de certaines sculptures sont identifiées par leur nas, nom et adresse. Les contraintes sont les suivantes : ‐ Une œuvre est assurée que si sa valeur le justifie selon des critères internes appliqués par les gestionnaires du musée. Il y a des peintures et des sculptures parmi les œuvres protégées par une assurance. ‐ Certaines sculptures appartiennent au musée. Par contre, le musée est propriétaire de toutes les peintures. Répondre aux questions suivantes : a- Donner le modèle conceptuel de données pour représenter toute cette information conformément aux contraintes énoncées. b- Modifier le MCD obtenu pour représenter le fait que toutes les œuvres seront dorénavant assurées. c- Donner un autre MCD équivalent à celui obtenu en b. 33- Modélisation conceptuelle d’un aéroclub. (MCD AERO) Modéliser la gestion des avions d’un aéroclub privé. Plusieurs avions du club appartiennent à des propriétaires dont certains sont habilités à piloter leur avion ou un autre parmi ceux qui appartiennent au club. Le hangar de rangement est décrit par un noHangar et le nombre d’avions



155

qu’il peut loger (sa capacité). Un avion est représenté par son immatriculation, son type et son rayon d’autonomie. Un propriétaire d’avion est identifié par un no de dossier attribué par le système de gestion du club. Un propriétaire d’avion peut être une société commerciale ou une personne. La société est définie par son nomSocial et son adresse, tandis que la personne propriétaire est décrite par son nas, son nom et son téléphone. Finalement, un pilote est caractérisé par son noPermis, la catégorie d’avions qu’il peut piloter et la date d’échéance de son permis. Voici les contraintes qui doivent être représentées par ce modèle : 1- Chaque avion est rangé dans un hangar et ce dernier peut en recevoir jusqu'à 5. Tous les

avions du club sont représentés par le MCD. 2- La propriété des avions personnels (autres que ceux qui appartiennent au club) fait l’objet

d’un dossier de gestion identifié par un numéro et qui inclut toute l’information disponible sur le propriétaire.

3- Tout propriétaire est soit une personne, soit une société. La copropriété d’un avion est interdite. Exceptionnellement, un propriétaire peut avoir plusieurs avions.

4- Lorsque le propriétaire est une personne, celle-ci peut avoir son permis de pilote 5- Un pilote est autorisé à piloter son appareil et des avions de la catégorie autorisée appartenant

à l’aéroclub. Le modèle demandé doit éviter le plus possible l’utilisation des valeurs nulles, i.e. des attributs qui ne peuvent pas être valués. Selon vous, ce MCD est-il unique? Sinon, donnez un deuxième MCD équivalent? Un MCD équivalent est un modèle qui peut représenter les mêmes données et les mêmes contraintes sans en changer la sémantique. 34- Modélisation des matchs de tennis (MCD JMC) Un match de tennis est identifié par la rencontre, à une date déterminée, de deux joueurs dont lʹun est obligatoirement gagnant. Chaque joueur est défini par son nom, prénom, âge et nationalité. Il ne peut y avoir deux joueurs qui ont le même nom. 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 noms des gagnants et des perdants partagent le même domaine sémantique. Chaque joueur inscrit dans la base a participé au moins à un match, mais il nʹa pas nécessairement un commanditaire. Ce dernier lorsquʹil est inscrit dans la base de données a nécessairement souscrit une ou plusieurs commandites pour un montant déterminé et fixe et pour une durée qui peut varier d’un joueur à l’autre. La date est formée avec seulement lʹannée représentée par une chaîne de caractères. Questions : a- Donnez un MCD pour modéliser les joueurs, les commandites et les matchs. Le modèle obtenu est nommé JMC. Pour y arriver, il vous faut faire appel à l'abstraction de spécialisation et en préciser les propriétés. b- Pouvez-vous donner un autre MCD avec une association récursive (ou réflexive) pour modéliser les mêmes informations.



156

c- Quelle est la propriété nécessaire pour représenter un joueur non encore commandité et une société dont le montant de la commandite est encore indéterminé ? d- Un match peut être représenté que s'il a été joué et terminé avec un gagnant. Quel est l'impact de cette contrainte sémantique sur les attributs? e- Comment est-il possible de représenter le fait suivant : un joueur doit avoir un commanditaire et même, il peut en avoir jusqu’à trois ? f- Comment faut-il formuler la contrainte qui exige que l’âge de tout joueur soit supérieur à 17 ans ? g- Comment formuler en français une contrainte qui limite la somme totale commanditée par une société comme étant inférieure ou égale à 50 000.00 et cela en supposant que le montant de la commandite est attribuée sur la base d’une durée d’une année. h- Expliquez pourquoi la contrainte de l’association AJoueG qui représente le fait qu’un joueur a gagné un match contre un autre joueur est (1, n) et non (0, n) ? Références chapitre 3 1 CHEN, P., The Entity‐Relationship Model; Towards a Unified View of Data, ACM TODS, 1976, p. 9‐36. 2 HULL, R., KING, R., Semantic Database Modeling; Survey, Applications, and Research Issues , ACM Computing Surveys, 19, mars, 1987, p. 201‐250. 3 STOREY, VEDA, « Relational Database Design Based on the Entity‐Relationship Model », Data Knowledge Engineering, vol. 7, 47‐83, 1991. 4 BLAHA, M. , PREMERLANI, W., Object‐Oriented Modeling and Design for Database Applications, Prentice Hall, Englewood Cliffs, NJ, 1998. 5 HAWRYSZKKIEWYCZ, I. T., Database Analysis and Design, SRA, 1984, 576 p. 6 ABRIAL, J., Data Semantics, Data Base Management, Proceedings IFIP TC2 Conference, Cargese, Corsica, North‐Holland, 1974. 7 NIJSSEN, G. M., Conceptual Schema and Relational Database Design; A Fact Oriented Approach, Prentice Hall,1989, p. 310, ISBN 0‐13‐167263‐0. 8 BACHMAN, C.W., The Role Concept in Data Models, in Proceedings of the 3nd International Conference On Very Large Databases Tokyo, IEEE NY, October 1977, p. 464‐476. 9 BATINI, C., CERI, S., NAVATHE, S.‐B., Conceptual Database Design, Benjamin/Cummings, 1992, ISBN 0‐8053‐0244‐1. 10 ELMASRI, R., WEELDREYER, J., HEVNER, A., The Category Concept : An Extension to the Entity‐Relationship Model , in International Journal on Data and Knowledge Engineering, v. 1, no 1, 1985.



157

INDEX A

abstraction de type agrégation, 115 Abstraction des données, 8 Accesseur, 17 ACCESSEUR, 30 active set, 55 ADABAS, 25 Administrateur de BD, 13 Agrégation, 113 Agrégation de classes, 112 Agrégation de composition, 112 Analyseur, 17 Analyseur API, 13 Appel au Superviseur (SVC), 32 Architecture, 16 Architecture ANSI/SPARC, 20 Architecture client/serveur, 62 association réflexive, 92 Attribut, 78

B

bancs dʹessai du TPC, 73 Base de données, 4

C

Calcul, 17 Calcul, 30 Calcul dʹune réponse, 55 Caractéristiques des attributs, 81 Cas particulier

sous‐classe unique, 130 catégorie, 133 Catégorie, 133 Chasm Trap, 139 Checkpoint, 70 CHECKPOINT, 58 Checkpoint et recouvrement, 59

chevauchement, 128 Chevauchement exclusivité, 128

Classe dʹentités faibles, 105 Classe faible, 107 Clé composée, 84 Clé simple, 84 Commit, 56 COMMIT, 56 Complexité de l’attribut, 81 Conception de la base de données, 4 confidentialité des données, 6 Connexion dʹun client, 45 Contrainte d’existence, 99 Contrainte de cardinalité, 96 Contrainte de participation :, 98 Contraintes dʹassociation, 95 contraintes de cohérence, 7 contraintes structurelles, 100 couplage faible., 112 couplage fort, 112 Couverture

totale, 125 couverture totale, 126

D

DDL, 21 DDL), 22 de gestion de base de données (SGBD), 4 Degré d’une association, 88 Dictionnaire, 23 Dictionnaire de données, 11 DML, 12, 21 Domaine d’un attribut, 85

E

Entité, 78 Exclusion et inclusion des associations, 108 Exercices, 147



158

Exercices résolus, 141

F

Fan Trap, 137 Fichiers de contrôle, 72 Formalismes de la modélisation, 80

G

Généralisation, 122, 125 Gestion Transactionnelle, 50

H

Héritage, 131 Héritage multiple, 132

I

IDMS, 23 Impacts du logiciel SGBD, 14 Indépendance logique, 21 Indépendance physique, 21 Instance de la BD, 20 IPC, 33

J

Journalisation, 71 Journalisation, 54 Journalisation et reprise, 56

L

Langage de données, 21 Langage de requête autonome, 12 Langages L4G, 13 Le ROLL FORWARD, 57 Logiciel SGBD, 7 LRU, 52

M

Mémoire partagée, 34 MER, 45 mode multithreading ( MTS), 68 Modèle de données, 19 Modèle Entité/Association, 77

Modèle fonctionnel du logiciel, 29 Modèles conceptuels de données, 19 Modéliser avec une Classe ou un attribut ?,

79 MRU, 53

N

niveau conceptuel, 8 niveau externe, 9, 10 niveau physique, 9

O

Optimiseur, 17 Optimiseur, 30 OSI, 63

P

Participation totale, 98, 99 partielle, 125 Performance des SGBD, 72 Point de sauvegarde (PS), 58 Port, 37 processus, 30 Processus du SGBD, 31

Q

Queue de messages, 35

R

recouvrement après une panne, 57 Répartiteur, 50 ROLLBACK, 57

S

Schéma de la base de données, 20 Schéma externe, 48 SDL, 21 Serveur de processus, 68 SGA, 67 SGBD, 4 sous‐classe unique, 130 spécialisation, 95



159

SQL*NET, 63 Superclé, 85 swapping, 31

T

TCP, 64 test TPC‐A, 72 Thread, 32 TOTAL, 24 Traducteur, 17, 30 Trame technologique, 65 Typologie des bases de données, 4

U

utilisateurs, 14

V

Validation dʹune transaction, 55 VDL, 21 Vue schématique du protocole IP, 65 Vues de la BD, 9

Z

ZMP, 34, 51

Documents

Architectures, modèles et langages de donnéesagamache/pageperso/LivreBDPDF/Chapitre123.pdf · et répond aux requêtes de service en provenance de clients répartis en différents