conception de base de donnee

Stéphane Crozat

NF17

Génie Informatique

Université de Technologie de Compiègnehttp://www4.utc.fr/~nf17

© UTC 2005

GÉNIE INFORMATIQUE

NF17

Conception de bases dedonnées

Stéphane Crozat

Version 3.00 du 05/01/2005

Edité par : SCENARI

Edité par : SCENARI

Entête pédagogique dumodule

Objectifs pédagogiquesMaîtriser les outils méthodologiques pour la conception de bases de donnéesSavoir mettre en pratique les outils technologiques classiques pour la réalisation de bases de donnéesAcquérir une expérience de conception et de réalisation informatique en équipe à travers un projet de développement d’unsite webDécouvrir des projets industriels réels en rapport avec les bases de donnéesDévelopper un esprit critique face aux technologies (veille, évaluation, choix)Faire réfléchir sur ce qu’est le métier d’ingénieur (articulation méthode-technique)

RésuméL'objectif de l'UV est de d'amener les étudiants à maîtriser la conception de bases de données relationnelles etrelationnelles-objet. Cette maîtrise reposera sur des compétences méthodologiques de modélisation conceptuelle et logique,ainsi que sur des compétences technologiques de mise en oeuvre au sein de SGBD typiques (tels que Access, MySQL, Oracleet PosgreSQL) et à travers les langages couramment utilisés en BD (tels que SQL, PHP ou Java). Les étudiants mèneront toutau long du semestre un projet qui servira de cadre d'application en situation des concepts préalablement étudiés etexpérimentés. Des présentations de projets réels de conception de BD seront également proposés par des intervenantspraticiens de la discipline.

Table des matières

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Licence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

I- Modélisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Partie A. Introduction aux bases de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Section A1. Vue d'ensemble. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1. Qu'est ce qu'une BD ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212. Qu'est ce qu'un SGBD ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213. Pourquoi des SGBD ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224. Caractéristiques des SGBD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Section A2. Notions générales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1. Notion de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232. Notion de modèle de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243. Notion de schéma de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244. Notion de langage de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255. Notion d'administration de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

En résumé.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Partie B. Le niveau conceptuel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Section B1. Les méthodes de conception de bases de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1. Méthodologie de conception d'une base de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282. La méthode MERISE et le modèle E-A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293. Eléments pour l'analyse de l'existant et des besoins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294. Le MCD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315. Le MLD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Section B2. Le modèle E-A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Le modèle E-A en bref. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311. Entité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312. Association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323. Cardinalité d'une association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334. Modèle E-A étendu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345. Entité de type faible. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346. Illustration d'entités faibles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Section B3. Pratique de la modélisation E-A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Exercice n°1. Centre médical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Exercice n°2. Tournoi de tennis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Exercice n°3. Un journal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Exercice n°4. Une société de transport routier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Section B4. Les diagrammes de classes UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Bref aperçu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401. Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402. Attributs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413. Héritage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414. Classes abstraites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425. Association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436. Cardinalité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447. Classe d'association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458. Composition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469. Des voitures et des conducteurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Section B5. Pratique de la modélisation UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Exercice n°5. Analyse d'un diagramme de classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Exercice n°6. Conception d'un diagramme de classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

En résumé.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Partie C. Quelques questions/réponses sur la modélisation de BD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Question Réponse 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Exercice récapitulatif I. Gestion d'une coopérative viticole. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

II- Relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Partie A. Modèle relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Section A1. Description du modèle relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Le niveau logique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531. Le modèle relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532. Domaine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543. Produit cartésien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544. Relation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545. Attribut et enregistrement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556. La relation Vol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557. Clé. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568. Lien entre relations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579. Eclatement des relations pour éviter la redondance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5710. Clé étrangère. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5911. Schéma relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5912. Exemple de schéma relationnel simple pour la géographie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Section A2. Le passage E-A vers Relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

1. Transformation des entités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602. Transformation des associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613. Remarques concernant la transformation des associations 1:1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614. Transformation des attributs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625. Exemple de passage E-A vers relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626. Transformation de la relation d'héritage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637. Exemple de transformation d'une relation d'héritage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648. Comparaison des modèles E-A, UML et relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Section A3. Pratique du passage E-A vers relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Exercice n°7. La gestion d'une compagnie touristique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Section A4. Le passage UML vers Relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

1. Transformation des classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662. Transformation des associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8 Conception de bases de données

3. Remarques concernant la transformation des associations 1:1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674. Transformation des attributs et méthodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685. Transformation des classes d'association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686. Transformation des compositions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687. Transformation de la relation d'héritage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688. Transformation de la relation d'héritage par référence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709. Transformation de la relation d'héritage par les classes filles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7010. Transformation de la relation d'héritage par la classe mère. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7111. Exemple de transformation d'une relation d'héritage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7212. Héritage et clé primaire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7313. Liste des contraintes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7314. Correspondance entre UML et relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Section A5. Pratique du passage UML vers relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Exercice n°8. Gestion de parc informatique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Partie B. Algèbre relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Section B1. Algèbre relationnelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Concepts manipulatoires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751. Opérateurs ensemblistes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752. Projection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763. Restriction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764. Produit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775. Jointure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776. Jointure naturelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787. Jointure externe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788. Division. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799. Proposition de notations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Exercice n°9. Opérateurs de base et additionnels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Section B2. Pratique de l'algèbre relationnelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Exercice n°10. Inviter ses amis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Exercice n°11. Faire du Cinéma. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Exercice récapitulatif II. Une usine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Exercice récapitulatif II. Gestion d'une agence immobilière. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

En résumé.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

III- SQL LMD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Partie A. Manipulation de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Qu'appelle-t-on SQL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Section A1. Le LMD de SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

1. Sélection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862. Opérateurs de comparaisons et opérateurs logiques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873. Expression du produit cartésien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874. Expression d'une projection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875. Expression d'une restriction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876. Expression d'une jointure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877. Opérateurs ensemblistes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888. Tri. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899. Fonctions de calcul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8910. Agrégats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8911. Requêtes imbriquées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Table des matières 9

12. Sous-requête d'existence IN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9013. Sous-requête d'existence EXISTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9114. Sous-requête de comparaison ALL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9115. Sous-requête de comparaison ANY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9216. Insertion de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9217. Mise à jour de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9218. Suppression de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Section A2. Pratique du LMD SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Exercice n°12. Représentation de représentants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Exercice n°13. Gestion du personnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Exercice récapitulatif IV. Gauloiseries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Exercice récapitulatif IV. Jeanne et Serge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

IV- Normalisation, SQL LDD et LCD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Partie A. La normalisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Section A1. Théorie de la normalisation relationnelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Exercice n°14. Redondance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971. Les problèmes soulevés par une mauvaise modélisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982. Principes de la normalisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983. Dépendance fonctionnelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994. Les axiomes d'Armstrong. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995. Autres propriétés déduites des axiomes d'Armstrong. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006. DF élémentaire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007. Notion de fermeture transitive des DFE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018. Notion de couverture minimale des DFE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019. Notion de graphe des DFE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10110. Définition formelle d'une clé. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10211. Principe de la décomposition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10212. Formes normales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10213. Première forme normale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10314. Deuxième forme normale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10315. Troisième forme normale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10416. Forme normale de Boyce-Codd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Section A2. Pratique de la normalisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Exercice n°15. Dépendances alphabétiques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Exercice n°16. Cuisines et dépendances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Exercice n°17. De quoi dépend un cours ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Partie B. Définition et contrôle de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Bref aperçu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Section B1. Le LDD de SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

1. Types de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072. Création de tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083. Contraintes d'intégrité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094. Création de vues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105. Supression d'objets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1106. Modification de tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107. Exemple de modifications de tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Exercice n°18. Quoi de neuf docteur ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Section B2. Le LCD de SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

1. Attribution de droits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112


2. Révocation de droits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Exercice récapitulatif VI. The show must go on !. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

En résumé.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Normalisation de relations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Exercice récapitulatif VI. Le chemin à l'envers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

V- Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Partie A. Technologie Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Présentation d'Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Section A1. Généralités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

1. Avantages et inconvénient d'Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202. Séparation base de données et application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Section A2. Création de schéma relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

1. LDD et création de tables sous Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212. Domaines et types de données sous Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1223. Contraintes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224. Vues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235. Requêtes LDD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Section A3. Le langage de requêtes QBE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

1. Questions QBE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1232. Manipulation des données en QBE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243. Clause GROUP BY en QBE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Section A4. Formulaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

1. Formulaire liés à une table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1252. Formulaires indépendants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1263. Contrôles listes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Section A5. Macro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

1. Création de macro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1272. Exemple d'actions macro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1283. Appel des macros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1284. Macro AutoExec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Section A6. Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

1. Structure d'un programme VBA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1292. Fonctions à connaître. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1293. Objets à connaître. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1294. Normaliser des chaînes de caractères. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295. Parcourir une table ou une requête stockée. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1296. Parcourir une table passée en paramètre. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307. Parcourir une table et gérer les erreurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1308. Exécuter une requête. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1309. Créer un schéma de BD et initialiser les données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Section A7. Autres aspects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

1. Gestion des droits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302. Run-time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Section A8. Quelques questions/réponses sur Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Question Réponse 1. Alertes et requêtes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Question Réponse 2. Contrôles de sous-formulaire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Question Réponse 3. Parcourir un recordset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Question Réponse 4. DateDiff. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131


Question Réponse 5. Debuggage VBA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Question Réponse 6. ! et .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

En résumé.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Exercice récapitulatif VIII. L'apprenti chimiste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

VI- Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Partie A. Gestion des transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Problématique des pannes et de la concurrence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Section A1. Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

1. Notion de transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362. Déroulement d'une transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1363. Propriétés ACID d'une transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364. Transactions en SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375. Exemple de transaction sous Oracle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1376. Exemple de transaction sous Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1377. Journal des transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Section A2. Fiabilité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

1. Les pannes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1382. Point de contrôle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1383. Reprise après panne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1394. Algorithme de reprise UNDO-REDO.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395. Ecriture en avant du journal.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Section A3. Concurrence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

1. Trois problèmes soulevés par la concurrence.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1412. Le verrouillage.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1433. Le déverrouillage.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1434. Protocole d'accès aux données.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445. Solution aux trois problèmes soulevés par la concurrence.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446. Inter-blocage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Section A4. Illustrations sous Oracle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

1. Validation et annulation de transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1462. Validation conditionnelle de transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1463. Simulation de panne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1474. Mises à jour concurrentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

En résumé.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Exercice récapitulatif IX. Opération bancaires et transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

VII- Oracle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Partie A. Technologie Oracle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Présentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Section A1. SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

1. Types de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1512. Particularités LMD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1523. Opérateur de concaténation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1524. Les séquences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1525. Fonctions à connaître. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536. Dictionnaire de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154


Section A2. SQL*Plus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

1. Présentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1542. Quelques commandes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543. Paramétrage de l'affichage des états. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Section A3. PL/SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

1. Présentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1552. Structure d'un bloc PL/SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1553. Types de bloc PL/SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1564. Types de programmes PL/SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1565. Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1576. Variables scalaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1577. Affectation classique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1578. Affectation par une requête. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1579. Affichage à l'écran. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15810. Structures de contrôle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15811. La gestion d'erreur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15812. Les curseurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15913. Les triggers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15914. Types de triggers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15915. Instructions particulières. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Section A4. Exemple. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

1. Définition de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1612. Triggers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1613. Fonctions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1624. Initialisation de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1625. Procédures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636. Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1637. Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Section A5. Pratique d'Oracle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Exercice n°19. Dictionnaire de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Exercice n°20. SQL sous Oracle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

En résumé.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

VIII- Relationnel-objet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Partie A. Relationnel-objet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Section A1. Introduction : R, OO, RO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

1. Les atouts du modèle relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1672. Les inconvénients du modèle relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1683. Les SGBDOO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1684. Les SGBDRO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Section A2. Le modèle relationnel-objet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

1. Les SGBDRO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1692. Le modèle imbriqué. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1693. Les types utilisateurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1704. Les collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1705. Comparaison relationnel et relationnel-objet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1716. Tables d'objets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1727. Héritage et réutilisation de types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1728. Identification d'objets et références. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172


Section A3. Mapping E-A vers relationnel-objet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

1. Entité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1732. Attributs composites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733. Attributs multi-valués. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734. Attributs dérivés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735. Association 1:N. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736. Association N:M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1747. Héritage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

En résumé.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Partie B. Quelques questions/réponses sur le relationel-objet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Question Réponse 1. Association 1:N. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Question Réponse 2. Association M:N. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Question Réponse 3. Association M:N. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Exercice récapitulatif X. Passage UML vers relationnel-objet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

IX- SGBDRO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Partie A. Implémentation du RO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Section A1. SQL3 (implémentation Oracle 9i). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

1. Les nouveaux types de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1772. Les types de données abstraits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1773. Nested tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1784. Tables d'objets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1785. Insertion d'objets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1786. Sélection dans des objets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1797. Sélection dans des tables imbriquées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1798. Manipulation d'OID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Section A2. Exemples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

1. Gestion de cours. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1812. Gestion de cours simplifiée (version avec OID). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Section A3. Pratique du relationnel-objet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Exercice n°21. Une entreprise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184Exercice n°22. Des voitures et des hommes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Exercice récapitulatif XI. Attributs multi-valués : Réflexion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

En résumé.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Exercice récapitulatif XI. Passage conceptuel logique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

X- Optimisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Partie A. Optimisation du schéma interne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Section A1. Introduction à l'optimisation des BD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Schéma interne et performances des applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1911. Evaluation des besoins de performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1922. Indexation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1923. Dénormalisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1934. Groupement de tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1945. Partitionnement de table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1946. Vues concrètes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Section A2. Pratique de l'optimisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Exercice n°23. Big Brother is Watching You. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195


En résumé.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

XI- Web et Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Partie A. Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Section A1. Architecture trois tiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

1. Notions d'achitecture client-serveur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1972. Notions d'achitecture 3-tier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1983. Notions de serveur Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2004. Architecture Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Section A2. Rappels HTML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

1. Formulaires HTML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Section A3. Introduction à PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

1. Présentation de PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2022. Principes de PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2023. Syntaxe PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2034. Variables en PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2035. Structures de contrôle en PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2036. Boucles en PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2047. Fonctions en PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2048. Objets en PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2049. Envoi de texte au navigateur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20410. Formulaires HTML et PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Section A4. PHP et BD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

1. Interfaçage avec Oracle (API ORA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2052. Interfaçage avec Oracle (API OCI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2063. Architecture PHP/Oracle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Partie B. Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Section B1. Java et BD (JDBC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

1. JBDC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2082. Structure globale d'un appel BD depuis Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2093. Syntaxe d'un appel BD depuis Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2094. Insertion et sélection dans Oracle depuis Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2105. Espace de requête préparé. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2106. Insertion en utilisant un espace préparé dans Oracle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2117. Appel Oracle PL/SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2118. Insertion en utilisant un appel Oracle PL/SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Section B2. Introduction aux servlets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

1. Présentation des servlets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2122. Implémenter une servlet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2133. Quelques méthodes de la classe HttpServlet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2134. Formulaires HTML et servlet (HttpServletRequest). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2135. Création de la réponse (HttpServletResponse). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2136. Cycle de vie d'une servlet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Section B3. Servlets et BD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

1. Exemple d'appel SQL depuis une servlet sous Oracle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2152. Exemple d'appel Oracle PL/SQL depuis une servlet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2163. Architecture servlet/Oracle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Exercice récapitulatif I. Retour sur les fonctions fondamentales des SGBD. . . . . . . . . . . . . . . . . . 219


Exercice récapitulatif I. Gestion de comptes bancaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

XII- Annexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Partie A. Technologie MySQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Section A1. Généralités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

1. Présentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2252. Notions d'achitecture client-serveur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Section A2. Gestion de MySQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

1. Instructions spécifiques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2272. Gestion des droits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Section A3. Spécificités MySQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

1. Types de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2282. BLOB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2283. Fonctions à connaître. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2284. Les tables InnoDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Section A4. Extension MySQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

1. Limites de MySQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2292. MySQL Control Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2303. Questions sur plusieurs BD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Section A5. Pratique de MySQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Exercice n°24. Dictionnaire de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Section A6. MySQL et PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

1. Interfaçage avec MySQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2322. Architecture PHP/MySQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Section A7. Quelques questions/réponses sur MySQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Question Réponse 1. Tables InnoDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Exercice récapitulatif XV. Gestion de projets dans une association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Partie B. Exercices complémentaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Section B1. Modélisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Exercice n°25. Une agence immobilière. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Section B2. Relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Exercice n°26. Le chemin des écoliers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Exercice n°27. Le retour des écoliers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Exercice n°28. Gestion du personnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Section B3. Nomalisation, SQL LDD et LCD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Exercice n°29. Avec modération. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Bibliographie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Glossaire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Signification des sigles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Fiche de synthèse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257


Introduction

Les BD [Base de Données] sont nés vers la fin des années 1960 pour combler les limites des systèmes de fichiers. Les BDrelationnelles, issues de la recherche de Codd, sont celles qui ont connu le plus grand essor depuis plus de 20 ans, et qui resteencore aujourd'hui les plus utilisées. Le langage SQL [Structured Query Language] est une couche technologique, idéalementindépendante des implémentations des SGBDR [Système de Gestion de Bases de Données Relationnelles], qui permet decréer et manipuler des BD relationnelles.Les usages de BD se sont aujourd'hui généralisés pour entrer dans tous les secteurs de l'entreprise, depuis les "petites" BDutilisées par quelques personnes dans un service pour des besoins de gestion de données locales, jusqu'aux "grosses" BD quigèrent centralement pour toute l'entreprise des données partagées par tous les acteurs de l'entreprise. Parallèlementl'accroissement de l'utilisation du numérique comme outil de manipulation de toutes données (bureautique, informatiqueapplicative, etc.) et comme outil d'extension des moyens de communication (réseaux) d'une part et les évolutionstechnologiques (puissance des PC, Internet, etc.) d'autre part ont à la fois rendu indispensable et complexifié la problématiquedes BD.Les conséquences de cette généralisation et de cette diversification des usages se retrouvent dans l'émergence de solutionsconceptuelles et technologiques nouvelles et sans cesse renouvellées.Ce cours se proposera de donner les bases conceptuelles et technologiques qui permettront à l'ingénieur de mobiliser descompétences générales pour la réalisation de projets informatiques mobilisant les BD. Il ne cherchera pas, par contre, àfournir des compétences techniques spécialisées (tel ou tel SGBD), ni à de cas d'exploitation privilégié (Internet, grossystèmes, BD applicatives, etc.). Le travail de l'élève-ingénieur consistera donc, à partir des savoirs généraux et dessavoir-faire particuliers acquis, à chercher à prendre du recul sur le domaine pour être capable, lorsqu'il sera en situationprofessionnelle réelle, d'apprendre rapidement les compétences spécifiques qui seront alors nécessaires dans son contexted'application.Ce support est structuré en 11 cours, correspondant aux 11 cours magistraux de l'UV, en commençant par les basesthéoriques indispensables à la conception des bases de données, en continuant par l'apprentissage du language SQLincontournable dans ce domaine, pour prolonger sur l'application technologique à travers deux SGBD très différents (Accesset Oracle) et pour finir sur des problématiques plus avancées des BD (le relationnel-objet et l'usage dans le contexte Web).

♦ Mes remerciements les plus sincères vont à Dritan Nace, enseignant-chercheur à l'Université de Technologie deCompiègne, qui a enseigné NF17 avant moi jusqu'en 2002, et dont le fonds documentaire en terme de cours et d'exercicesa été largement récupéré pour la constitution de ce support ; ainsi qu'à Yacine Challal, Achene Beneyache et Hamida Sebaqui ont apporté leur contribution à travers quelques exercices et auto-évaluation. Mes remerciements enfin à l'ensembledes acteurs très dynamiques sur le Web qui m'ont aidé sans le savoir dans ce travail (on se reportera à la bibliographiepour les connaître).

♦ Ce support ne saurait être considéré comme un travail achevé ou suffisant pour un auto-apprentissage. Il s'agit de notesorganisées destinées à accompagner le cours, ainsi que les activités de travaux dirigés de NF17. Il n'est certainement pasexempt d'erreurs et j'invite les lecteurs, étudiants et enseignants, à me faire part de leurs remarques pour m'aider dans cetravail sans fin d'amélioration de ce support.

♦ Ce support est disponible à l'adresse www4.utc.fr/~nf17.

Préambule

Licence

IMG. 1 : CREATIVE COMMONS LICENCE - SOME RIGHTS RESERVED

Cette création est mise à disposition sous un contrat Creative Commons (contrat Paternité - Pas d'Utilisation Commerciale -Partage des Conditions Initiales à l'Identique) par Stéphane Crozat - Université de Technologie de Compiègne.

This work is licensed under a Creative Commons License. (Attribution-NonCommercial-ShareAlike licence) by StéphaneCrozat - Université de Technologie de Compiègne .

Ce support a été réalisé avec les technologies SCENARI (www.utc.fr/ics/site_scenari).

Stéphane Crozat : [email protected] / www.utc.fr/ics/~stc

Cours

IModélisation

La modélisation est l'étape fondatrice du processsus de conception de BD. Elle consiste à abstraire le problème réel posé pouren faire une reformulation qui trouvera une solution dans le cadre technologique d'un SGBD [Système de Gestion de Basesde Données]. Après avoir rappelé succintement les fondements et objectifs des SGBD, ce chapitre proposera les outilsméthodologiques nécessaires à la modélisation, à travers les formalismes E-A [Entité-Association] et UML [UnifiedModeling Language].

Partie A. Introduction aux bases de données

Objectifs pédagogiquesComprendre ce qu'est un SGBD.Comprendre l'utilité des BD.Connaître les différences entre modèle conceptuel, modèle logique et implémentation phyique.Comprendre l'importance de la modélisation conceptuelle.

Section A1. Vue d'ensemble

1. Qu'est ce qu'une BD ?Base de donnéesUne BD est un ensemble volumineux, structuré et minimalement redondant de données, reliées entre elles, stockéessur supports numériques centralisés ou distribués, servant pour les besoins d'une ou plusieurs applications,interrogeables et modifiables par un ou plusieurs utilisateurs travaillant potentiellement en parallèle.

Exemple : Compagnie aérienneUne BD de gestion de l'activité d'une compagnie aérienne concernant les voyageurs, les vols, les avions, lepersonnel, les réservations, etc. Une telle BD pourrait permettre la gestion des réservations, des disponibilités desavions en fonction des vols à effectuer, des affectation des personnels volants, etc.

2. Qu'est ce qu'un SGBD ?Système de Gestion de Bases de DonnéesUn SGBD est un logiciel qui prend en charge la structuration, le stockage, la mise à jour et la maintenance d'unebase de données. Il est l'unique interface entre les informaticiens et les données (définition des schémas,programmation des applications), ainsi qu'entre les utilisateurs et les données (consultation et mise à jour).

Exemples de SGBD♦ Oracle est un SGBD relationnel (et Relationnel-Objet dans ses dernières versions) très reconnu pour les

applications professionnelles.

♦ MySQL est un SGBD relationnel libre (licence GPL et commerciale), simple d'accès et très utilisé pour laréalisation de sites Web dynamiques. Depuis la version 4 MySQL implémente la plupart des fonctions attenduesd'un SGBD relationnel.

♦ PosgreSQL est un SGBD relationnel et relationnel-objet très puissant qui offre une alternative open-source auxsolutions commerciales comme Oracle ou IBM.

♦ Access est un SGBD relationnel Microsoft, qui offre une interface conviviale permettant de concevoirrapidement des applications de petite envergure ou de réaliser des prototypes à moindre frais.

3. Pourquoi des SGBD ?Jadis...Avant l'avènement des SGBD, chaque application informatique dans l'entreprise impliquait sa propre équipe dedéveloppement, ses propres supports physiques, ses propres fichiers, ses propres normes, ses propres langages, etc.Conséquences...L'existence conjointe et croissante de ces applications indépendantes a des effets négatifs, tels que :♦ La multiplication des tâches de saisie, de développement et de support informatique

♦ La redondance anarchique des informations dans les fichiers

♦ L'incohérence des versions simultanées de fichiers

♦ La non-portabilité des traitements en raison des différences dans les formats et langages.

♦ La multiplication des coûts de développement et de maintenance des applications.

Problèmes...Les conséquences précédemment citées se répercutent sur l'entreprise en générant des problèmes humains et matériels.Coûts en personnels qualifiés et en formations♦ Remise des pouvoirs de décision entre les mains de spécialistes informatiques

♦ Tout changement matériel ou logiciel a un impact sur les applications

♦ Tout changement de la structure des données nécessite de modifier les programmes

Or...En réalité les applications ne sont jamais totalement disjointes, des données similaires (le coeur de l'information d'entreprise)sont toujours à la base des traitements.On peut citer typiquement :♦ Les données comptables

♦ Les données clients et fournisseurs

♦ Les données relatives à la gestion des stocks

♦ Les données relatives aux livraisons

♦ Les données marketting et commerciales

♦ Les données relatives au personnel

♦ etc.

4. Caractéristiques des SGBDLa conception d'un système d'information pour être rationnelle à l'échelle d'une entreprise se doit d'adopter un certain nombrede principes, tels que :♦ Une description des données indépendante des traitements

♦ Une maintenance de la cohérence de données

♦ Le recours à des langages non procéduraux, interactifs et structurants


Dans ce cadre les SGBD se fixent les objectifs suivants :♦ Indépendance physique des données

Le changement des modalités de stockage de l'information (optimisation, réorganisation, segmentation, etc.) n'impliquepas de changements des programmes.

♦ Indépendance logique des données

L'évolution de la structure d'une partie des données n'influe pas sur l'ensemble des données.

♦ Manipulation des données par des non-informaticiens

L'utilisateur n'a pas à savoir comment l'information est stockée et calculée par la machine, mais juste à pouvoir larechercher et la mettre à jour à travers des IHM [Interface Homme Machine] ou des langages assertionnels simples.

♦ Administration facilitée des données

Le SGBD fournit un ensemble d'outils (dictionnaire de données, audit, tunning, statistiques, etc.) pour améliorer lesperformance et optimiser les stockages.

♦ Optimisation de l'accès aux données

Les temps de réponse et de débits globaux sont optimisés en fonctions des questions posées à la BD.

♦ Contrôle de cohérence (intégrité sémantique) des données

Le SGBD doit assurer à tout instant que les données respectent les règles d'intégrité qui leurs sont imposées.

♦ Partageabilité des données

Les données sont simultanéments consultables et modifiables.

♦ Sécurité des données

La confidentialité des données est assurée par des systèmes d'authentification, de droits d'accès, de cryptage des mots depasse, etc.

♦ Sûreté des données

La persistence des données, même en cas de panne, est assurée, grâce typiquememnt à des sauvegardes et des journauxqui gardent une trace persistante des opérations effectuées.

Section A2. Notions générales

1. Notion de donnéesType de donnéesEnsemble d'objets qui possèdent des caractéristiques similaires et manipulables par des opérations identiques.

♦ Synonyme : Classe.

DonnéesElément effectif, réel, correspondant à une type de données.

♦ Synonymes : Occurence, Instance.

Exemple : Type de données♦ Entier = { 0, 1, 2, ... , N }

♦ Véhicule = (immatriculation, marque, type, couleur)

Exemple : Données♦ L'entier 486

♦ Le véhicule (460HP59, Renault, Megane, Jaune)

Modélisation 23

2. Notion de modèle de donnéesModèle de donnéesEnsemble de concepts et de règles de composition de ces concepts permettant de décrire des données (Gardarin,1999).Un modèle est souvent représenté au moyen d'un formalisme graphique permettant de décrire les données (ou plusprécisément les types de données) et les relations entre les données.

On distingue trois niveaux de modélisation pour les bases de données :♦ Le modèle conceptuel

Il permet de décrire le réel selon une approche ontologique, sans prendre en compte les contraintes techniques.

♦ Le modèle logique

Il permet de décrire une solution, en prenant une orientation informatique générale (type de SGBD typiquement), maisindépendamment de choix d'implémentation précis.

♦ Le modèle physique

Il correspond aux choix techniques, en terme de SGBD choisi et de sa mise en oeuvre (programmation, optimisation, etc.).

Exemple de formalisme de modélisation conceptuelle♦ Le modèle Entité-Association (Chen, "The entity-Relationsheep Model - Towards a Unified View of

Data", "ACM Transactions on Database systems", mars-1976, n°.1) a été le plus répendu dans le cadre de laconception de bases de données.

♦ Le modèle UML, qui se généralise pour la conception en informatique, se fonde sur une approche objet.

Exemple de formalisme de modélisation logique♦ Le modèle relationnel est le modèle dominant.

♦ Le modèle relationnel-objet (adaptation des modèles relationnel et objet au cadre des SGBD) est actuellement enpleine croissance.

♦ Le modèle objet "pur" reste majoritairement au stade expérimental et de la recherche.

♦ Des modèles plus anciens (hiérarchique, réseau, etc.) ne sont plus guère utilisés aujourd'hui.

3. Notion de schéma de données

Schéma de donnéesDescription, au moyen d'un langage formel, d'un ensemble de données dans le contexte d'une BD.

Un schéma permet de décrire la structure d'une base de données, en décrivant l'ensemble des types de données de labase. L'occurence d'une base de données est constituée de l'ensemble des données correspondant aux types duschéma de la base.

Exemple : Schéma de base de donnéesEtudiant (NumEtud, nom, ville)Module(NumMod, titre)Inscription(NumEtud, NumMod, date)

Exemple : Instance de base de donnéesEtudiant (172, 'Dupont', 'Lille')Etudiant (173, 'Durand', 'Paris')Etudiant (174, 'Martin', 'Orléans')Module(1, 'SGBD')Module(1, 'Systèmes d'exploitation')Inscription(172, 1, 2002)Inscription(172, 2, 2002)Inscription(173, 1, 2001)Inscription(174, 2, 2002)

On distingue trois niveaux d'abstraction de schémas :♦ Le niveau conceptuel

Il permet de décrire les entités et les associations du monde réel. Il s'agit du schéma global de la base de données, il enpropose une vue canonique.

Le niveau conceptuel correspond au modèle conceptuel.

♦ Le niveau externe


Il permet de décrire les entités et les associations du monde réel, mais vues d'un utilisateur ou d'un groupe d'utilisateursparticuliers (on parle d'ailleurs également de "vue" pour un shéma externe). Il s'agit d'une restriction du schémaconceptuel orientée vers un usage précis. Il existe généralement plusieurs schémas externes pour un même schémaconceptuel.

Le niveau externe correspond à un sous ensemble du modèle conceptuel restreint aux points de vue de certainsutilisateurs.

♦ Le niveau interne

Il correspond à l'implémentation physique des entités et associations dans les fichiers de la base.

Le niveau interne correspond aux modèles logiques et physiques.

Remarque : ANSI/X3/SPARCLes trois niveaux, conceptuel, externe et interne, sont les trois niveaux distingués par le groupe de normalisationANSI/X3/SPARC en 1975.

SCH. 1 : LES TROIS NIVEAUX DE SCHÉMA SELON ANSI/X3/SPARC

4. Notion de langage de donnéesLangage de donnéesLangage informatique permettant de décrire et de manipuler les schémas d'une BD d'une une manière assimilablepar la machine.

♦ Synonyme : Langage orienté données.

Exemple : SQLSQL est le langage orienté données consacré aux SGBD relationnels et relationnels-objet.

Modélisation 25

Un langage de données peut être décomposé en trois sous langages :♦ Le Langage de Définition de Données

Le LDD [Langage de Définition de Données] permet d'implémenter le schéma conceptuel (notion de table en SQL) et lesschémas externes (notion de vue en SQL).

♦ Le Langage de Contrôle de Données

Le LCD [Langage de Contrôle de Données] permet d'implémenter les droits que les utilisateurs ont sur les données etparticipe donc à la définition des schémas externes.

♦ Le Langage de Manipulation de Données

Le LMD [Langage de Manipulation de Données] permet l'interrogation et la mise à jour des données. C'est la partie dulangage indispensable pour exploiter la BD et réaliser les applications.

Exemple : Définition de données en SQLCREATE TABLE Etudiant (

NumEtu : integer,Nom : string,Ville : string)

Cette instruction permet de créer une relation "Etudiant" comportant les propriétés "NumEtu", "Nom" et "Ville".

Exemple : Contrôle de données en SQLGRANT ALL PRIVILEGES ON Etudiant FOR 'Utilisateur'

Cette instruction permet de donner tous les droits à l'utilisateur "Utilisateur" sur la relation "Etudiant".

Exemple : Manipulation de données en SQLSELECT NomFROM EtudiantWHERE Ville = 'Compiègne'

Cette instruction permet de rechercher les noms de tous les étudiants habitant la ville de Compiègne.

5. Notion d'administration de données

AdministrateurPersonne ou groupe de personnes responsables de la définition des différents niveaux de schéma.

On distingue un type d'administrateur par niveau de schéma :♦ L'administrateur entreprise est en charge de la gestion du schéma conceptuel et des règles de contrôle des

données.

♦ L'administrateur de données est en charge de la gestion des schémas externes et de leur correspondance avec leschéma conceptuel.

♦ L'administrateur base de données est en charge de la gestion du schéma interne et de sa correspondance avec leschéma conceptuel.

Dictionnaire des donnéesLe dictionnaire de données d'un SGBD contient les informations relatives aux schémas et aux droits de toutes lesbases de données existantes au sein de ce SGBD. Il s'agit d'un outil fondamental pour les administrateurs.Les dictionnaires de données sont généralement implémentés sous la forme d'une base de données particulière duSGBD, ce qui permet de gérer les données relatives aux bases de données de la même façon que les autres donnéesde l'entreprise (i.e. dans une base de données).

♦ Synonymes : Catalogue des données, Métabase.


En résumé...

Conception

Modèle ConceptuelSchéma conceptuel canonique et

schémas externes

Modèle LogiqueSchéma interne indépendant d'un

SGBD

Modèle PhysiqueSchéma interne pour un SGBD

particulier

Exemples- E-A- UML

Exemples- Relationnel

- Objet- Réseau

- Hiérarchique

Exemples- Oracle- MySQL

- PosgreSQL- DB2

- Access- SQLServer

* **

Les SGBD assurent la gestion efficace et structurée des données partagées. Leur conception repose sur une approche à troisniveaux : conceptuel et externe, logique, physique.

Partie B. Le niveau conceptuel

Objectifs pédagogiquesComprendre la méthodologie de conception d'une BD.Savoir réaliser et interpréter un modèle conceptuel.Maîtriser la modélisation E-A.Maîtriser la modélisation UML dans le cas particulier de la conception de BD.

Modélisation 27

Section B1. Les méthodes de conception de bases de données

1. Méthodologie de conception d'une base de donnéesEtapes de la conception d'une base de données1. Analyse de la situation existante et des besoins

2. Création d'une série de modèles conceptuels (canonique et vues externes) qui permettent de représenter tous lesaspects importants du problème

3. Traduction des modèles conceptuels en modèle logique et optimisation (normalisation) de ce modèle logique

4. Implémentation d'une base de données dans un SGBD, à partir du modèle logique

IMG. 2 : PROCESSUS DE CONCEPTION D'UNE BASE DE DONNÉES

L'importance de l'étape d'analyseLa première étape de la conception repose sur l'analyse de l'existant et des besoins. De la qualité de la réalisation decette première étape dépendra ensuite la pertinence de la base de données par rapports aux usages. Cette premièreétape est donc essentielle et doit être menée avec soins.Si la première étape est fondamentale dans le processus de conception, elle est aussi la plus délicate. En effet, tandisque des formalismes puissants existent pour la modalisation conceptuel puis pour la modélisation logique, laperception de l'existant et des besoins reste une étape qui repose essentiellement sur l'expertise d'analyse del'ingénieur.

L'importance de l'étape de modélisation conceptuelleEtant donnée une analyse des besoins correctement réalisée, la seconde étape consiste à la traduire selon un modèleconceptuel. Le modèle conceptuel étant formel, il va permettre de passer d'une spécification en langage naturel, etdonc soumise à interprétation, à une spécification non ambigüe. Le recours aux formalismes de modélisation telsque E-A ou UML est donc une aide fondamentale pour parvenir à une représentation qui ne sera plus liée àl'interprétation du lecteur.La traduction d'un cahier des charges spécifiant l'existant et les besoins en modèle conceptuel reste néanmoins uneétape délicate, qui va conditionner ensuite l'ensemble de l'implémentation informatique. En effet les étape suivantessont plus mécaniques, dans la mesure où un modèle logique est déduit de façon systématique du modèle conceptuelet que l'implémentation logicielle est également réalisée par traduction directe du modèle logique.


Remarque : Les étapes de traduction logique et d'implémentationDes logiciels spécialisés (http://www.sybase.com/products/enterprisemodeling pour la modélisation E-A ouwww.objecteering.com pour la modélisation UML) sont capables à partir d'un modèle conceptuel d'appliquer desalgorithmes de traduction qui permettent d'obtenir directement le modèle logique, puis les instructions pour lacréation de la base de données dans un langage orienté données tel que SQL. L'existence de tels algorithmes detraduction montre que les étapes de traduction logique et d'implémentation sont moins complexes que lesprécédentes, car plus systématiques.Néanmoins ces étapes exigent tout de même des compétences techniques pour optimiser les modéles logiques(normalisation), puis les implémentations en fonction d'un contexte de mise en oeuvre matériel, logiciel et humain.

2. La méthode MERISE et le modèle E-AMERISE est une méthode d'analyse informatique particulièrement adaptée à la conception de bases de données.

SCH. 2 : L'ANALYSE SELON MERISE

La méthode MERISE a pour fondement le modèle E-A, qui a fait son succès.Les principales caractéristiques du modèle E-A sont :♦ Une représentation graphique simple et naturelle

♦ Une puissance d'expression élevée pour un nombre de symboles raisonnables

♦ Une lecture accessible à tous et donc un bon outil de dialogue entre les acteurs techniques et non techniques

♦ Une formalisation non ambigüe et donc un bon outil de spécification détaillée

Remarque : L'arrivée d'UMLUML est un autre langage de modélisation, plus récent et couvrant un spectre plus large que les bases de données.En tant que standard de l'OMG [Object Management Group] et en tant qu'outil très utilisé pour la programmationorientée objet, il est très certainement amené à supplenter rapidement la modélisation E-A.

3. Eléments pour l'analyse de l'existant et des besoinsLa phase d'analyse de l'existant et des besoins est une phase essentielle et complexe. Elle doit aboutir à des spécificationsgénérales qui décrivent en langage naturel les données manipulées, et les traitements à effectuer sur ces données.On se propose de donner une liste non exhaustive d'actions à mener pour rédiger de telles spécifications.

L'analyse de documents existantsLa conception d'une base de données s'inscrit généralement au sein d'usages existants. Ces usages sontgénéralement, au moins en partie, instrumentés à travers des documents électroniques ou non (papier typiquement).Il est fondamental d'analyser ces documents et de recenser les données qu'ils manipulent.

Modélisation 29

Exemples de document existants♦ Fichiers papiers de stockage des données (personnel, produits, etc.)

♦ Formulaires papiers d'enregistrement des données (fiche d'identification d'un salarié, fiche de description d'unproduit, bon de commande, etc.)

♦ Documents électroniques de type traitement de texte (lettres, mailing, procédures, etc.)

♦ Documents électroniques de type tableurs (bilans, statistiques, calculs, etc.)

♦ Bases de données existantes, à remplacer ou avec lesquelles s'accorder (gestion des salaires, de la production,etc.)

♦ Intranet d'entreprise (information, téléchargement de documents, etc.)

♦ etc.

Le recueil d'expertise métierLes données que la base va devoir manipuler sont toujours relatives aux métiers de l'entreprise, et il existe desexperts qui pratiquent ces métiers. Le dialogue avec ces experts est une source importante d'informations. Il permetégalement de fixer la terminologie du domaine.

Exemples d'experts à consulter♦ Praticiens (secrétaires, ouvrier, contrôleurs, etc.)

♦ Cadres (responsables de service, contremaîtres, etc.)

♦ Experts externes (clients, fournisseurs, etc.)

♦ etc.

Le dialogue avec les usagersLa base de données concerne des utilisateurs cibles, c'est à dire ceux qui produiront et consommeront effectivementles données de la base. Il est nécessaire de dialoguer avec ces utilisateurs, qui sont les détenteurs des connaissancesrelatives aux besoins réels, liés à leur réalité actuelle (aspects de l'organisation fonctionnant correctement oudéfaillants) et à la réalité souhaitée (évolutions, lacunes, etc.).

Exemples d'utilisateurs♦ Personnes qui vont effectuer les saisies d'information (à partir de quelles sources ? Quelle est leur reponsabilité ?

etc.)

♦ Personnes qui vont consulter les informations saisies (pour quel usage ? pour quel destinataire ? etc.)

♦ Personnes qui vont mettre à jour les informations (pour quelles raisons ? comment le processus est enclenché ?etc.)

♦ etc.

L'étude des autres systèmes informatiques existantsla base de données va généralement (et en fait quasi systématiquement aujourd'hui) s'insérer parmi un ensembled'autres logiciels informatiques travaillants sur les données de l'entreprise. Il est important d'analyser ces systèmes,afin de mieux comprendre les mécanismes existants, leurs forces et leurs lacunes, et de préparer l'intégration de labase avec ces autres systèmes. Une partie de ces systèmes seront d'ailleurs souvent également des utilisateurs de labase de données, tandis que la base de données sera elle même utilisatrice d'autre systèmes.

Exemples d'autres systèmes coexistants♦ Autres bases de données (les données sont elle disjointes ou partiellement communes avec celles de la base à

concevoir ? quelles sont les technologies logicielles sur lesquelles reposent ces BD ? etc.)

♦ Systèmes de fichiers classiques (certains fichiers ont-ils vocations à être supplantés par la base ? à être généréspar la base ? à alimenter la base ? etc.)

♦ Applications (ces applications ont elles besoins de données de la base ? peuvent-elles lui en fournir ? etc.)

♦ etc.


4. Le MCDMCDLe MCD [Modèle Conceptuel de Données] est l'élément le plus connu de MERISE et certainement le plus utile. Ilpermet d'établir une représentation claire des données du SI [Système d'Information] et définit les dépendances desdonnées entre elles.

ExempleLe modèle E-A est un formalisme de MCD.

RemarqueUn MCD est indépendant de l'état de l'art technologique. A ce titre il peut donc être mis en oeuvre dans n'importequel environnement logiciel et matériel, et il devra être traduit pour mener à une implémentation effective.

5. Le MLDOn ne sait pas implémenter directement un modèle conceptuel de données dans une machine et il existe différentes sortes deSGBD qui ont chacun leur propre modèle : SGF [Système de Gestion de Fichiers] (qui ne sont pas vraiment des SGBD),SGBD hiérarchiques (organisés selon une arborescence), SGBD réseau (encore appelés CODASYL), SGBDR, SGBDOO[Système de Gestion de Bases de Données Orientées Objets], SGBDRO [Système de Gestion de Bases de DonnéesRelationnelles-Objets], etc.

MLDUn MLD [Modèle Logique de Données] est une représentation du système tel qu'il sera implémenté dans unordinateur.

ExempleLe modèle relationnel est un formalisme de MLD.

RemarqueIl ne faut pas confondre le MLD (relationnel par exemple) avec le MCD (E-A par exemple).

Il ne faut pas confondre le MLD avec son implémentation logicielle en machine (avec Oracle par exemple)

Section B2. Le modèle E-A

Le modèle E-A en brefLe modèle E-A (ou E-R [Entity-Relationship] en anglais) permet la modélisation conceptuelle de données.Il correspond au niveau conceptuel de la méthode MERISE (méthode d'analyse informatique), le MCD (Tardieu & al., 1983),(Tardieu & al., 1985).La conception E-A est issue des travaux de Chen, (Chen, "The entity-Relationsheep Model - Towards a Unified View ofData", "ACM Transactions on Database systems", mars-1976, n°.1) et se fonde sur deux concepts principaux et un troisièmesous-jacent : l'entité, l'association et l'attribut ou propriété.

1. Entité

EntitéUne entité est un objet du monde réel avec une existence indépendante.

Une entité (ou type d’entité) est une chose (concrète ou abstraite) qui existe et est distinguable des autres entités.L'occurrence d’une entité est un élément particulier correspondant à l’entité et associé à un élément du réel. Chaqueentité a des propriétés (ou attributs) qui la décrivent. Chaque attribut est associé à un domaine de valeur. Uneoccurence a des valeurs pour chacun de ses attributs, dans le domaine correspondant.

Modélisation 31

Syntaxe

IMG. 3 : NOTATION MERISE DE L'ENTITÉ

IMG. 4 : NOTATION CHEN DE L'ENTITÉ

Remarque♦ Un attribut est atomique, c'est à dire qu'il ne peut prendre qu'une seule valeur pour une occurence.

♦ Un attribut est élémentaire, c'est à dire qu'il ne peut être exprimé par (ou dérivé) d'autres attributs.

♦ Un attribut qui identifie de façon unique une occurence est appelé attribut clé.

2. Association

AssociationUne association (ou type d’association) représente un lien quelconque entre différentes entités.

Une occurrence d’une association est un élément particulier de l’association constitué d’une et une seule occurrencedes objets participants à l’association. On peut définir des attributs sur les associations. Le degré d'une associationest le nombre d'entités y participant (on parlera notamment d'association binaire lorsque deux entités sontconcernées).


Syntaxe

IMG. 5 : NOTATION MERISE DE L'ASSOCIATION

IMG. 6 : NOTATION CHEN DE L'ASSOCIATION

RemarqueOn peut avoir plusieurs associations différentes définies sur les mêmes entités.

3. Cardinalité d'une associationCardinalité d'une association binairePour les associations binaires la cardinalité minimale (resp. maximale) d'une association est le nombre minimum(resp. maximum) d'occurrences de l'entité d'arrivée associées à une occurrence de l'entité de départ.

Syntaxe

IMG. 7 : NOTATION DE LA CARDINALITÉ

Exemple

IMG. 8 : LIVRE-AUTEUR

Le diagramme E-A précédent exprime qu'un auteur peut avoir écrit plusieurs livres (mais au moins un), et que toutlivre ne peut avoir été écrit que par un et un seul auteur.

Modélisation 33

Remarque : Trois grands types de cardinalitéIl existe trois grands types de cardinalité :♦ Les associations 1:N (qui incluent les association 0,1:N)

♦ Les associations N:M

♦ Les associations 1:1 (qui incluent les association 0,1:1)

Les autres associations peuvent toujours être ramenées à des associations N:M (dans le cas général) ou à plusieursassociations 1:N (cas des associations 2:N ou 3:N par exemple).

4. Modèle E-A étenduOn peut étendre le modèle E-A "classique" de façon à accroitre son pouvoir de représentation. Cette extension du modèleE-A permet de favoriser la dimension conceptuelle et de s'approcher des représentations objet, telles que UML.Attributs compositesUn attribut peut être composé hiérarchiquement de plusieurs autres attributs.

ExempleUn attribut Adresse est composé des attributs Numéro, Rue, No_Appartement, Ville, Code_Postal, Pays.

RemarqueLe domaine d'un attribut composite n'est donc plus un domaine simple (entier, caractères, etc.).

Attributs multivaluésTout attribut peut être monovalué ou multivalué.

ExempleLes âges des enfants d’un employé.

RemarqueUn attribut multivalué n'est donc plus atomique.

Attributs dérivéLa valeur d'un attribut peut être dérivée d'une ou plusieurs autres valeurs d'attributs.

ExempleL'âge d'une personne peut être dérivé de la date du jour et de celle de sa naissance.

RemarqueUn attribut dérivé n'est donc plus élémentaire.

Sous-type d'entitéUne entité peut-être définie comme sous-type d'une entité plus générale.

ExempleLes entités Cadre et Technicien sont des sous-types de l'entité Employé.

RemarqueLa notion de sous-type est équivalente à la notion d'héritage en modélisation objet.

5. Entité de type faibleCertaines entités dites "faibles" n'existent qu'en référence à d'autres entités dites "identifiantes". L'entité identifiante estappelé "identifiant étranger" et l'association qui les unit "association identifiante".

Entité de type faibleUne entité de type faible, également appelée entité non identifiée, possède une clé locale (appelée identifiant relatif)qui permet d'identifier une de ses occurrences parmi l'ensemble des occurrences associées à une occurrence del'entité identifiante. La clé complète d'une entité faible est la concaténation de la clé de l'entité identifiante et de saclé locale.


Exemple

IMG. 9 : ASSOCIATION IDENTIFIANTE

L'entité Tâche est complètement dépendante de l'entité Projet et sa clé locale (No_tâche) n'est pas suffisante àl'identifier de façon absolue.

AttentionLe repérage des entités de type faible est très important dans le processus de modélisation, il permet de réfléchir à lameilleure façon d'identifier de façon unique les entités et donc de trouver les meilleures clés. Notons de plus que lerepérage d'entités faibles aura une influence importante sur le modèle relationnel résultant.

6. Illustration d'entités faiblesExemple

SCH. 3 : GÉOGRAPHIE

ExplicationDans le schéma ci-avant, on remarque que l'entité "ville" est faible par rapport à l'entité "département", qui est faiblepar rapport à "région", qui est faible par rapport à "pays". Cela signifie que la clé de ville, son nom, est une clélocale et donc que l'on considère qu'il ne peut pas y avoir deux villes différentes avec le même nom, dans un mêmedépartement. Il est par contre possible de rencontrer deux villes différentes avec le même nom, dans deuxdépartements différents. De la même façon chaque département possède un nom qui l'identifie de façon unique dansune région, et chaque région possède un nom qui l'identifie de façon unique dans un pays.Si les entités n'étaient pas faibles, l'unicité d'un nom de ville serait valable pour l'ensemble du modèle, et donc,concrêtement, cela signifierai qu'il ne peut exister deux villes avec le même nom au monde (ni deux départements,ni deux régions).

RemarqueNotons pour terminer que, puisque "pays" n'est pas une entité faible, sa clé "nom" est bien unique pour l'ensembledu modèle, et donc cela signifie qu'il ne peut exister deux pays avec le même nom au monde.

Modélisation 35

Section B3. Pratique de la modélisation E-A

Exercice n°1. Centre médicalSoit le schéma E-A suivant, représentant des visites dans un centre médical.

IMG. 10 : CENTRE MÉDICAL

Question1Analyser ce schéma et discuter ses cardinalités. Chercher par exemple si un patient peut effectuer plusieurs visites,si un médecin peut recevoir plusieurs patients pendant la même consultation, si un médecin peut prescrire plusieursmédicaments lors d'une même consultation, si deux médecins différents peuvent prescrire le même médicament, etc.

Question2A partir de votre analyse, pensez vous que ce modèle soit un bon modèle pour la gestion d'un centre médical ?

Exercice n°2. Tournoi de tennisLe schéma suivant représente des rencontres dans un tournoi de tennis :


IMG. 11 : TOURNOI DE TENNIS

Question1Analyser ce schéma et discuter ses cardinalités. Chercher par exemple si le tournoi permet les matchs de double, siles joueurs peuvent gagner des matchs auxquels ils n'ont pas participé, si deux matchs différents peuvent se déroulersur le même terrain à la même heure, etc.

Question2A partir de votre analyse, pensez vous que ce modèle soit un bon modèle pour la gestion d'un tournoi de tennis ?

Exercice n°3. Un journalVoici le schéma E-A du système d'information (très simplifié) d'un quotiden.

Modélisation 37

IMG. 12 : JOURNAL

Question1Analyser ce schéma et discuter ses cardinalités. Chercher par exemple combien de journalistes peuvent co-signer unarticle, si un article peut être publié deux fois dans le même numéro, si un numéro est associé à un journal, etc.

Question2A partir de votre analyse, pensez vous que ce modèle soit un bon modèle pour la gestion d'un journal ?

Exercice n°4. Une société de transport routierUne société de transport routier veut installer un système d'information pour rendre plus efficace sa logistique.Embauché au service informatique de cette compagnie, vous êtes donc chargé de reprendre le travail déjà effectué (c'est àdire ce schéma Entité-Association).


IMG. 13 : UNE SOCIÉTÉ DE TRANSPORT ROUTIER

Question1Analyser ce schéma et discuter ses cardinalités. Chercher par exemple si les conducteurs peuvent avoir plusieurspermis, si un conducteur peut conduire plusieurs camions, si plusieurs conducteurs peuvent conduire le mêmecamion, etc.

Question2Chercher les cardinalités (A,B), (C,D) et (E,F) manquantes, en fonction de ce qui vous paraît être le plus logique.

Question3Qu'exprime l'association 5-aire "EstLivré" ? Pourquoi associe-t-elle deux instances de l'entité "Entrepôt" ?

Question4Qu'exprime l'association réflexive "EstDistantDe" sur l'entité Ville ?

Question5A partir de votre analyse, pensez vous que ce modèle soit un bon modèle pour la gestion d'une société de transportroutier ?

Section B4. Les diagrammes de classes UML

Si le modèle dominant en conception de bases de données a longtemps été le modèle E-A, le modèle UML se généralise deplus en plus. Nous ne donnons ici (parmi l'ensemble des outils d'UML) qu'un aperçu du diagramme de classes, qui plus estlimité aux aspects particulièrement utilisés en modélisation de bases de données.

Modélisation 39

Bref aperçuUML est un langage de représentation destiné en particulier à la modélisation objet. UML est devenu une norme OMG en1997[OMG est un organisme à but non lucratif créé en 1989 à l'initiative de sociétés comme HP, Sun, Philips, etc.].UML propose un formalisme qui impose de "penser objet" et permet de rester indépendant d'un langage de programmationdonné. Pour ce faire, UML normalise les concepts de l'objet (énumération et définition exhaustive des concepts) ainsi queleur notation graphique. Il peut donc être utilisé comme un moyen de communication entre les étapes de spécificationconceptuelle et les étapes de spécifications techniques.Dans le domaine des bases de données, UML peut être utilisé à la place du modèle E-A pour modéliser le domaine. De lamême façon, un schéma conceptuel UML peut alors être traduit en schéma logique (relationnel ou relationnel-objettypiquement).

1. ClassesClasseUne classe est un type abstrait caractérisé par des propriétés (attributs et méthodes) communes à un ensembled'objets et permettant de créer des instances de ces objets, ayant ces propriétés.

Syntaxe

IMG. 14 : REPRÉSENTATION UML D'UNE CLASSE

Exemple : La classe Voiture

IMG. 15 : EXEMPLE DE CLASSE REPRÉSENTÉE EN UML

Exemple : Une instance de la classe VoitureL'objet V1 est une instance de la classe Voiture.

V1 : Voiture♦ Marque : 'Citroën'

♦ Type : 'ZX'

♦ Portes : 5

♦ Puissance : 6

♦ Kilométrage : 300000

Remarque : CléEn UML on ne repère en général pas les clés. La définition des clés se fera donc au niveau logique.


RemarqueLa modélisation sous forme de diagramme de classes est une modélisation statique, qui met en exergue la structured'un modèle, mais ne rend pas compte de son évolution temporelle. UML propose d'autres types de diagrammespour traiter, notamment, de ces aspects.

2. Attributs

AttributUn attribut est une information élémentaire qui caractérise une classe et dont la valeur dépend de l'objet instancié.

Remarque♦ Un attribut est typé

Le domaine des valeurs que peut prendre l'attribut est fixé a priori

♦ Un attribut peut être multivalué

Il peut prendre plusieurs valeurs distinctes dans son domaine

♦ Un attribut peut être dérivé

Sa valeur alors est une fonction sur d'autres attributs de la classe (il peut donc aussi être représenté comme uneméthode, et c'est en général préférable)

Exemple : La classe Personne

IMG. 16 : REPRÉSENTATION D'ATTRIBUTS EN UML

Dans cet exemple, les attributs Nom, Prénom sont de type string, l'un de 20 caractères et l'autre de 10, tandis queDateNaissance est de type date et Age de type integer. Prénom est un attribut multivalué, ici une personne peutavoir de 1 à 3 prénoms. Age est un attribut dérivé, il peut être calculé par une fonction sur DateNaissance.

3. HéritageHéritageL'héritage est relation entre deux classes permettant d'exprimer que l'une est plus générale que l'autre. L'héritageimplique une transmission automatique des propriétés (attributs et méthodes) d'une classe A à une classe A'.Dire que A' hérite de A équivaut à dire que A' est une sous-classe de A. On peut également dire que A est unegénéralisation de A' et que A' est une spécialisation de A.

Modélisation 41

Syntaxe

IMG. 17 : NOTATION DE L'HÉRITAGE EN UML

RemarqueL'héritage permet de représenter la relation "est-un" entre deux objets.

RemarqueOutre qu'il permet de représenter une relation courante dans le monde réel, l'héritage a un avantage pratique, celuide factoriser la définition de propriétés identiques pour des classes proches.

Exemple : La classe Conducteur

IMG. 18 : REPRÉSENTATION D'HÉRITAGE EN UML

Dans cet exemple la classe Conducteur hérite de la classe Personne, ce qui signifie qu'un objet de la classeconducteur aura les attributs de la classe Conducteur (TypePermis et DatePermis) mais aussi ceux de la classePersonne (Nom, Prénom, DateNaissance et Age). Si la classe Personne avait des méthodes, la classe Conducteur enhériterait de la même façon.

4. Classes abstraitesClasse abstraiteUne classe abstraite est une classe non instanciable. Elle exprime donc une généralisation abstraite, qui necorrespond à aucun objet existant du monde.

Classe abstraite et héritageUne classe abstraite est toujours héritée. En effet sa fonction étant de généraliser, elle n'a de sens que si des classesen héritent. Une classe abstraite peut être héritée par d'autres classes abstraites, mais en fin de chaîne des classesnon abstraites doivent être présentes pour que la généralisation est un sens.


Syntaxe : Notation d'une classe abstraite en UMLOn note les classes abstraites en italique.

IMG. 19 : NOTATION D'UNE CLASSE ABSTRAITE EN UML

Exemple de classe abstraite

IMG. 20 : DES CHIENS ET DES HOMMES

Dans la représentation précédente on a posé que les hommes, les femmes et les chiens étaient des objetsinstanciables, généralisés respectivement par les classes mammifère et humain, et mammifère.Selon cette représentation, il ne peut donc exister de mammifères qui ne soient ni des hommes, ni des femmes ni deschiens, ni d'humains qui ne soient ni des hommes ni des femmes.

5. AssociationAssociationUne association est une relation logique entre deux classes (association binaire) ou plus (association n-aire) quidéfinit un ensemble de liens entre les objets de ces classes.Une association est nommée, généralement par un verbe. Une association peut avoir des propriétés (à l'instar d'uneclasse). Une association définit le nombre minimum et maximum d'instances autorisée dans la relation (on parle decardinalité).

Modélisation 43

Syntaxe

IMG. 21 : NOTATION DE L'ASSOCIATION EN UML

RemarqueUne association est généralement bidirectionnelle (c'est à dire qu'elle peut se lire dans les deux sens). Lesassociations qui ne respectent pas cette propriété sont dites unidirectionnelles ou à navigation restreinte.

Exemple : L'association Conduit

IMG. 22 : REPRÉSENTATION D'ASSOCIATION EN UML

L'association Conduit entre les classes Conducteur et Voiture exprime que les conducteurs conduisent des voitures.

6. CardinalitéCardinalité d'une associationLa cardinalité d'une association permet de représenter le nombre minimum et maximum d'instances qui sontautorisées à participer à la relation. La cardinalité est définie pour les deux sens de la relation.

SyntaxeSi mina (resp. maxa) est le nombre minimum (resp. maximum) d'instances de la classe A autorisées à participer àl'association, on note sur la relation, à côté de la classe A : mina..maxa.Si le nombre maximum est indéterminé, on note n ou *.

AttentionLa notation de la cardinalité en UML est opposée à celle adopté en E-A. En UML on note à gauche (resp. à droite)le nombre d'instances de la classe de gauche (resp. de droite) autorisées dans l'association. En E-A, on note à gauche(resp. à droite) le nombre d'instances de la classe de droite (resp. de gauche) autorisées dans l'association.

RemarqueLes cardinalité les plus courantes sont :♦ 0..1 (optionnel)

♦ 1..1 ou 1 (un)

♦ 0..n ou 0..* ou * (plusieurs)

♦ 1..n ou 1..* (obligatoire)


Exemple : La cardinalité de l'association Possède

IMG. 23 : REPRÉSENTATION DE CARDINALITÉ EN UML

Ici un conducteur peut possèder plusieurs voitures (y compris aucune) et une voiture n'est possédée que par un seulconducteur.

7. Classe d'association

Association de compositionOn utilise la notation des classes d'association lorsque l'on souhaite ajouter des propriétés à une association.

Syntaxe : Notation d'une classe d'association en UML

IMG. 24 : NOTATION D'UNE CLASSE D'ASSOCIATION EN UML

Modélisation 45

Exemple de classe d'association

IMG. 25 : EMPLOIS

8. CompositionAssociation de compositionOn appelle composition une association particulière qui possède les propriétés suivantes :♦ La composition associe une classe composite et des classes parties, tel que tout objet partie appartient à un et un

seul objet composite. C'est donc une association 1:N.

♦ La composition n'est pas partageable, donc un objet partie ne peut appartenir qu'à un seul objet composite à lafois.

♦ Le cycle de vie des objets parties est lié à celui de l'objet composite, donc un objet partie disparaît quand l'objetcomposite auquel il est associé disparait.

RemarqueLa composition est une association particulière.

Syntaxe : Notation d'une composition en UML

IMG. 26 : NOTATION D'UNE COMPOSITION EN UML


Composition et cardinalitéLa cardinalité côté composite est toujours de exactement 1.

Côté partie la cardinalité est libre, elle peut être 0..1, 1, * ou bien 1..*.

Exemple de composition

IMG. 27 : UN LIVRE

On voit bien ici qu'un chapitre n'a de sens que faisant partie d'un livre, qu'il ne peut exister dans deux livresdifférents et que si le livre n'existe plus, les chapitres le composant non plus.

Remarque : Composition et entités faiblesLa composition permet d'exprimer une association analogue à celle qui relie une entité faible à une entitéidentifiante en modélisation E-A. L'entité de type faible correspond à un objet partie et l'entité identifiante à un objetcomposite.

Modélisation 47

9. Des voitures et des conducteursExemple

IMG. 28 : EXEMPLE TRÈS SIMPLE DE DIAGRAMME DE CLASSES

Les relations de ce diagramme expriment que les conducteurs sont des personnes qui ont un permis ; que toutevoiture est possédée par une unique personne (qui peut en posséder plusieurs) ; que les voitures peuvent êtreconduites par des conducteurs et que les conducteurs peuvent conduire plusieurs voitures.

RemarqueLes mots clés in, out et in/out devant un paramètre de méthode permettent de spécifier si le paramètre est unedonnée d'entrée, de sortie, ou bien les deux.

RemarqueLe but d'une modélisation UML n'est pas de représenter la réalité dans l'absolu, mais plutôt de proposer une visiond'une situation réduite aux éléments nécessaires pour répondre au problème posé. Donc une modélisation s'inscrittoujours dans un contexte, et en cela l'exemple précédent reste limité car son contexte d'application est indéfini.

Section B5. Pratique de la modélisation UML

Exercice n°5. Analyse d'un diagramme de classesUn groupe industriel construisant des moteurs cherche à organiser la gestion des défauts observés sur des moteurs confrontésà des tests en situation réelle. Pour cela un de ses ingénieurs modélise le processus de gestion des défauts, tel qu'il existeactuellement, par le diagramme de classes suivant.


IMG. 29 : DIAGRAMME DE CLASSES DE GESTION DES DÉFAUTS

Question1Décrivez en français ce que représente ce diagramme.

Question2Etant donné ce modèle, est-il possible de savoir dans quelle usine a été fabriqué un moteur et qui est responsable desa production ?

Question3La responsabilité d'un modèle est elle toujours assumée par un employé travaillant dans l'usine dans laquelle cemodèle est produit ?

Question4Pourquoi avoir fait le choix d'une classe Type pour codifier les défauts, plutôt qu'un attribut de type énumérédirectement dans la classe Défaut ?

Question5Pourquoi l'attribut kilométrage apparait-il à la fois dans les classes Défaut et Moteur et pourquoi avoir faitapparaître la méthode SetKilométrage ?

Question6Ce diagramme permet-il de répondre à la question : Quel est le nombre moyen de défauts rencontrés pour un moteurdont le modéle a été mis en service avant 2000 ? Quelles sont les classes et attributs utiles ?

Question7Peut-on également répondre à la question : Quel est le kilométrage moyen pour lequel un moteur est concerné parau moins deux défauts de gravité supérieure à 5 ?

Modélisation 49

Exercice n°6. Conception d'un diagramme de classesLe service de gestion du personnel d'une entreprise désire s'équiper d'un outil lui permettant de gérer informatiquement sesemployés, leurs salaires et leurs congés. Les spécifications suivantes ont pu être mises en exergue par une analyse des besoinsréalisée auprès des utilisateurs du service du personnel.Généralités :♦ Tout employé est identifé par un nom, un prénom et une date de naissance.

♦ Tout employé remplit une fonction et appratient à un service.

♦ Pour chaque employé on gère la date d'embauche et la quotité (c'est à dire le pourcentage de temps travaillé par rapport autemps plein, en cas de travail à temps partiel)

Gestion des salaires :♦ Pour chaque employé on gère l'historique de ses salaires dans l'entreprise, chaque salaire étant affecté à une période de

temps.

♦ Un salaire est composé d'un salaire brut, de charges patronales et de charges salariales.

♦ On cherchera à partir des ces données à obtenir également le salaire chargé (brut + charges patronales), et le salaire net(brut - charges salariales), et ce en particulier pour le salaire en cours (celui que touche actuellement le salarié).

Gestion des congés :♦ Pour chaque employé, on mémorise chaque congé pris (posant qu'un congé concerne toujours une ou plusieurs journées

entières)

♦ Chaque employé a le droit aux jours de congés suivants :- 25 jours (pour une quotité de 1) et 25 x quotité sinon

- Chaque fonction ouvre les droits à un certain nombre de jours de RTT

- Chaque service ouvre les droits à un certain nombre de jours de RTT

- Chaque tranche de 5 ans passés dans l'entreprise donne droit à 1 jour supplémentaire

- Les employés de plus de 40 ans ont un jour supplémentaire, et ceux de plus de 50 ans deux.

♦ Pour chaque employé on cherchera à connaître le nombre total de jours de congés autorisés, le nombre de jours pris et lenombre de jours restants sur l'année en cours.

Question1Réaliser le diagramme de classes permettant de modéliser ce problème.


En résumé...

Schéma conceptuelUn schéma conceptuel peut être

représenté sous forme de modèle E-Aou sous forme de diagramme de classe

UML.

Entité ou Classe Relation

Propriété ouAttribut

- Typé- Multi-valué

- Dérivé

Méthode- Paramètres

- Valeur de retour

Héritage- Héritage d'attributs

- Héritage de méthodes

Association- Verbe

- Cardinalité

Partie C. Quelques questions/réponses sur la modélisation de BD

Question Réponse 1.

Est ce qu'il y'a des règles particulières pour le passage E-A à UML ?

Il n'y a pas de règle de passage UML à E-A car normalement on fait l'un ou l'autre. Mais les deux modèles sonteffectivement équivalents, à part quelques détails (méthodes, classes abstraites, etc.).

Exercice récapitulatif I. Gestion d'une coopérative viticoleCet exercice a été insipiré par (Gardarin, 1999).On considère une base "Coopérative" qui possède les caractéristiques suivantes :Un vin est caractérisé par un numéro entier unique nv, un cru, une année de production et un degré.Un viticulteur est caractérisé par un numéro entier unique nvt, un nom, un prénom et une ville.Un viticulteur produit un ou plusieurs vins et réciproquement, un vin est produit par un ou plusieurs producteurs(éventuellement aucun).Les buveurs sont caractérisés par un numéro de buveur nb, un nom, prénom et une adresse (limitée à la ville pour simplifier).Un buveur peut passer des commandes pour acheter une certaine quantité d'un vin précis.

Question1Lister toutes les types d'entité à considérer et les attributs associés à chaque type d'entité. Indiquer aussi pour chaquetype d'entité sa clé et les domaines de valeurs de ses attributs.

Modélisation 51

Question2Lister toutes les associations à considérer, leurs attributs et indiquer leurs cardinalités.

Question3Donner le diagramme E-A de cette situation.

Question4Donner le diagramme UML de cette situation.


Cours

IIRelationnel

Le modèle relationnel, à la base des SGBDR, est historiquement et aujourd'hui encore le modèle théorique dominant pour lareprésentation logique en BD. Le modèle relationnel permet de reformuler le modèle conceptuel dans un formalismebeaucoup plus proche de son implémentation en machine, tout en restant encore indépendant d'une solution technologiquedonnée.Le modèle relationnel, à travers l'algèbre qui lui est associée, est également le fondement théorique du langage normaliséSQL qui permettra d'exploiter les données stockées en BD

Partie A. Modèle relationnel

Objectifs pédagogiquesConnaître les fondements du modèle relationnel.Savoir effectuer le passage d'un schéma conceptuel à un schéma relationnel.

Section A1. Description du modèle relationnel

Le niveau logiqueLe niveau logique est le lien entre le niveau conceptuel et l'implémentation effective de l'application. Le modèle conceptuelétant un modèle formel, le modèle logique a pour vocation d'être également un modèle formel, mais spécifiant non plus laréalité existante ou recherchée comme le modèle conceptuel, mais les données telles qu'elles vont exister dans l'applicationinformatique.Pour assumer cette fonction, le modèle relationnel s'est imposé (Codd, "A relational model for large shared databanks", "Communications de l'ACM", juin-1970, n°.6, pp.377-387) , en réaction aux insuffisances des modèles précédents,les modèles hiérarchique et réseau, et de part la puissance de ses fondements mathématiques.Encore aujourd'hui dominant le modèle relationnel est un fondement indispensable à la conception de bases de données. Deplus le modèle émergeant actuellement est le modèle relationnel-objet, et ce dernier est bien une extension du modèlerelationnel qui le renforce et s'y appuie.

1. Le modèle relationnelLe modèle relationnel a été introduit par Codd, en 1970 au laboratoire de recherche d'IBM de San José (Codd, "A relationalmodel for large shared data banks", "Communications de l'ACM", juin-1970, n°.6, pp.377-387) . Il s'agit d'un modèle simpleet puissant à la base de la majorité des bases de données aujourd'hui.

Modèle relationnelEnsemble de concepts pour formaliser logiquement la description d'articles de fichiers plats, indépendamment de lafaçon dont ils sont physiquement stockés dans une mémoire numérique.Le modèle relationnel inclut des concepts pour la description de données, ainsi que des concepts pour lamanipulation de données.

Les objectifs du modèle relationnel, formulés par Codd, sont les suivants :♦ Assurer l'indépendance des applications et de la représentation interne des données

♦ Gérer les problèmes de cohérence et de redondance des données

♦ Utiliser des langages de données basés sur des théories solides

Remarque : Extension du modèle relationnelLe modèle relationnel est un standard, normalisé par l'ISO à travers son langage, le SQL. Il se veut néanmoins dèsl'origine extensible, pour permettre de gérer des données plus complexes que les données tabulaires. Le modèlerelationnel-objet est né de cette extension.

2. Domaine

DomaineEnsemble, caractérisé par un nom, dans lequel des données peuvent prendre leurs valeurs.

RemarqueUn domaine peut-être défini en intention (c'est à dire en définissant une propriété caractéristique des valeurs dudomaine) ou en extension (c'est à dire en énumérant toutes les valeurs du domaine)

Exemple : Domaines définis en intention♦ Entier

♦ Réel

♦ Booléen

♦ Chaîne de caractères

♦ Monétaire : réel avec deux chiffres après la virgule

♦ Date : chaîne de 10 caractères comprenant des chiffres et des tirets selon le patron "00-00-0000"

♦ Salaire : Monétaire compris entre 15.000 et 100.000

Exemple : Domaines définis en extension♦ Couleur : {Bleu, Vert, Rouge, Jaune, Blanc, Noir}

♦ SGBD : {Hiérarchique, Réseau, Relationnel, Objet, Relationnel-Objet}

3. Produit cartésienProduit cartésienLe produit cartésien, noté "X", des domaines D1, D2, ... , Dn, noté "D1 X D2 X ... X Dn" est l'ensemble des tuples(ou n-uplets ou vecteurs) <V1,V2,...,Vn> tel que Vi est une valeur de Di et tel que toutes les combinaisons devaleurs possibles sont exprimées.

ExempleD1 = {A, B, C}D2 = {1, 2, 3}D1 X D2 = {<A,1>, <A,2>, <A,3>, <B,1>, <B,2>, <B,3>, <C,1>, <C,2>, <C,3>,}

4. RelationRelationUne relation sur les domaines D1, D2, ..., Dn est un sous-ensemble du produit cartésien "D1 X D2 X ... X Dn". Unerelation est caractérisée par un nom.

♦ Synonyme : Table.


SyntaxeOn peut représenter la relation R sur les domaine D1, ... , Dn par une table comportant une colonne pour chaque domaine etune ligne pour chaque tuple de la relation.

D1 ... Dn

V1 ... Vn

... ... ...

V1 ... Vn

TAB. 1 : RELATION R

RemarqueUne relation est toujours définie en extension, par l'énumération des tuples la composant.

5. Attribut et enregistrementAttributOn appelle attribut d'une relation, une colonne de cette relation. Un attribut est caractérisé par un nom et undomaine dans lequel il prend ses valeurs.

♦ Synonymes : Champs, Propriété, Colonne.

EnregistrementOn appelle enregistrement d'une relation, une ligne de cette relation. Un enregistrement prend une valeur pourchaque attribut de la relation.

♦ Synonymes : Tuple, N-uplet, Vecteur, Ligne.

Exemple

A B

1 1

1 2

2 2

TAB. 2 : RELATION R

La relation R comporte les deux attributs A et B et les trois enregistrements <1,1>, <1,2> et <2,2>

Remarque : Attribut, domaine, ordreUn attribut se distingue d'un domaine car il peut ne comporter que certaines valeurs de ce domaine.

Les colonnes de la relation ne sont pas ordonnées et elles ne sont donc repérées que par le nom de l'attribut.

Remarque : Valeur nulleUn enregistrement peut ne pas avoir de valeur pour certains attributs de la relation, parce que cette valeur estinconnue ou inapplicable, sa valeur est alors "null".

6. La relation VolExemple

Numero Compagnie Avion Départ Arrivée Date

AF3245 Air France 747 Paris Oulan Bator 01-08-2002

AF6767 Air France A320 Paris Toulouse 30-07-2002

KLM234 KML 727 Paris Amsterdam 31-07-2002

TAB. 3 : RELATION VOL

Relationnel 55

7. Clé

CléGroupe d'attributs minimum qui détermine un tuple unique dans une relation.

Attributs de clés toujours valuésAfin d'être déterminants pour l'identification d'un enregistrement, tous les attributs d'une clé doivent être valués,c'est à dire qu'aucun ne peut avoir de valeur "null".

Remarque : Clé primaireToute relation doit comporter au moins une clé, ce qui implique qu'une relation ne peut contenir deux tuplesidentiques.Si plusieurs clés existent dans une relation, on en choisit une parmi celles-ci. Cette clé est appelée clé primaire. Laclé primaire est généralement choisie de façon à ce qu'elle soit la plus simple, c'est à dire portant sur le moinsd'attributs et sur les attributs de domaine les plus basiques (entiers ou chaînes courtes typiquement).

Remarque : Détermination d'une cléDéfinir un groupe d'attributs comme étant une clé nécessite une réflexion sémantique sur les données composant cesattributs, afin de s'assurer de leur unicité.

Exemple♦ L'attribut numéro de sécurité sociale d'une relation personne est une bonne clé car son unicité est assurée

sémantiquement.

♦ Le groupe d'attributs nom, prénom d'une relation personne est en général une mauvaise clé, car les homonymesexistent.

Remarque : Clé artificielleS'il est impossible de trouver une clé primaire, ou que les clés candidates sont trop complexes, il est possible defaire appel à une clé artificielle. Une clé artificielle est une propriété supplémentaire ajoutée au schéma de larelation, qui n'est reliée à aucune signification, et qui sert uniquement à identifier de façon unique lesenregistrements et/ou à simplifier les références de clés étrangères.

Remarque : Clé artificielle et niveau logiqueAu niveau du modèle logique, il faut éviter la simplicité consistant à identifier toutes les relations avec des clésartificielles, et ne réserver cet usage qu'aux cas particuliers.

Remarque : Clé artificielle et niveau physique, évolutivité, maintenance et performanceAu niveau de l'implémentation physique par contre, il est courant que des clés artificielles soient utilisées de façonsystématique.Du point de vue de l'évolutivité de la BD, il existe toujours un risque qu'une clé non-artificielle perde sa propriétéd'unicité ou de non-nullité.Du point de vue de la maintenance de la BD, il existe toujours un risque qu'une clé non-artificielle voit sa valeurmodifiée et dans ce cas, la répercution de ce changement pour mettre à jour toutes les références peut poserproblème.Du point de vue de la performance de la BD, les clés non-artificielles ne sont pas en général optimisées en terme detype et de taille, et donc peuvent limiter les performances dans le cadre des jointures. Précisons néanmoinsqu'inversement les clés artificielles ont pour conséquence de systématiser des jointures qui auraient pu être évitéesavec des clés primaires signifiantes.

Exemple : Problème d'évolutivité posé par une clé signifianteSoit le numéro de sécurité sociale la clé primaire d'une table d'une BD française, elle ne permettra pas d'entrer unindividu non-français issu d'un pays ne disposant pas d'un tel numéro.

Exemple : Problème de maintenance posé par une clé signifianteSoit le numéro de sécurité sociale la clé primaire d'une table d'une BD centrale dont les données sont exploitées pard'autres tables d'autres BD qui viennent "piocher" dans cette BD pour leurs propres usages, sans que la BD centralene connaisse ses "clients". Soit une erreur dans la saisie d'un numéro de sécurité sociale dans la BD centrale, si cenuméro est corrigé, il faudrait (ce qui n'est pas possible dans notre cas) impérativement en avertir toutes les basesutilisatrices pour qu'elles mettent à jour leurs références.


Exemple : Problème de performance posé par une clé signifianteSoit le numéro de sécurité sociale la clé primaire d'une table comptant un million d'enregistrements, ce numéro estgénéralement un nombre à 13 chiffres ou une chaîne à 13 caractères, ce qui dans les deux cas est supérieur aunombre à 7 chiffres suffisant pour identifier tous les individus de la BD. Les performances seront donc toujoursmoins bonnes, lors des jointures, si une clé prend deux fois plus de place en mémoire que son optimum. Maisajoutons que cette perte de performance n'a pas toujours de conséquence sur la réalité perceptible par les utilisateursde la BD.Inversement, soit une clé artificielle la clé primaire d'une table T1, par ailleurs référencée par une autre table T2.Soit le numéro de sécurité sociale un attribut clé de T1. Si l'on veut par requête disposer des infos de T2 ainsi quedu numéro de sécurité sociale de T1, alors il faudra faire une jointure, tandis que si ce numéro signifiant avait étéchoisi comme clé primaire, cela n'aurait pas été nécessaire.

8. Lien entre relationsLe modèle relationnel a pour objectif la structuration de données selon des relations. L'enjeu est de parvenir à traduire unmodèle conceptuel en modèle logique relationnel. Typiquement si le formalisme conceptuel utilisé est le modèle E-A, ilfaudra pouvoir traduire les entités et les associations en relations. Afin que la représentation des données ne soit pasredondante, il est nécessaire que les données soit réparties dans de multiples relations et non regroupées dans une seule. Or unmodèle conceptuel informe sur les liens entre les entités et associations, cela est traduit graphiquement par les lignes qui lesrelient. Il est donc fondamental que le modèle relationnel puisse également maintenir cette information, à savoir les liensentre les données réparties dans les relations.Afin de représenter des liens entre relations dans un modèle relationnel, la seule solution est de stocker l'information dans unerelation, et donc que certains attributs d'une relation servent à pointer sur d'autres relations.

LienLe lien entre deux tuples A=>B de deux relations différentes est matérialisable par une référence depuis l'un destuples, A, à la clé primaire de l'autre tuple, B.

Exemple

SCH. 4 : ILLUSTRATION

L'attribut "Attribut2" de la relation "Relation1" référence l'attribut "Attribut1" de la relation "Relation2"("Attribut1" est la clé primaire de "Relation2").

Remarque : Direction du lienDans un modèle relationnel, un lien est toujours unidirectionnel.

9. Eclatement des relations pour éviter la redondanceRelation redondante

Numero Date Gare1 Gare2 Train Vitesse Nom Prénom

1010 01-01-2001 Paris Lyon TGV 450 Dupont Joëlle

1011 02-01-2001 Paris Limoges TER 200 Durand Jean-Pierre

1012 03-01-2001 Paris Madrid TGV 450 Dupont Joëlle

1013 03-01-2001 Lyon Limoges TER 200 Dupont Jean-Pierre

TAB. 4 : RELATION VOYAGEENTRAIN

Relationnel 57

Dans la représentation précédente, les voyages en train sont représentés dans une unique relation, qui contient desinformations relatives au voyage lui même (numéro, date, départ, arrivée), mais aussi au train utilisé pour le voyage (type detrain et vitesse maximale), et au conducteur du train (nom et prénom).Cette représentation, bien que très simplifiée par rapport à la réalité (on imagine facilement plusieurs dizaines d'attibutspossibles) est redondante. En effet chaque fois qu'un voyage mobilisera un train TGV, la vitesse maximale de 450 km/h devraaussi être rappelée. De même pour chaque conducteur, il faudra rappeler le nom et le prénom.Cette redondance pose un certain nombre de problèmes :♦ Incohérence

Imaginons qu'une faute de saisie se glisse dans l'orthographe du nom de Dupont (un "d" à la place du "t") pour le voyage1010, il sera impossible de savoir que c'est la même personne qui conduit le train pour le voyage 1012 (car Joëlle Dupondpeut exister et être conductrice de train).

♦ Mise à jour

Imaginons que Joëlle Dupont se marie et change de nom, il faudra changer cette information pour tous les voyagesauxquels participe cette conductrice. Ceci est également un risque d'erreur, qui renvoie au risque d'incohérenceprécédemment mis en exergue.

♦ Perte d'information

Imaginons que temporairement plus aucun voyage n'existe pour des TGV. Tous les enregistrements portant sur les TGVdisparaitront. On perdra alors l'information comme quoi la vitesse d'un TGV est de 450 km/h, car cette informationn'existera plus dans la base. Or l'information intrinsèque au TGV, qui est sa vitesse maximale, n'est pas liée à un voyageen particulier, et donc il est dommage de ne pas conserver cette information indépendamment du fait que les TGV sont ounon utilisés à un instant t.

♦ Dépendance des insertions

Imaginons que nous souhaitions représenter dans la base de données un nouveau conducteur, qui n'est encore affecté àaucun voyage. Il est impossible d'ajouter une telle information, car l'insertion d'une personne est dépendant de l'insertiond'un tuple complet portant également sur un voyage. Il est évidemment très mauvais d'imaginer des solutions decontournement, telles que par exemple un tuple avec des valeurs nulles sur toutes les propriétés sauf les nom et prénom.

Relation éclatéeLe bon usage du modèle relationnel consiste donc à éclater les informations dans de multiples relations, afin de ne pasconserver de redondance. Dans le cas précédent, on préfèrera donc un découpage de la relation VoyageEnTrain en troisrelations, Voyage, Modele et Conducteur, chacune représentant des informations correspondant à des objets différents(notons l'ajout d'une clé artificielle numéro pour la nouvelle relation conducteur, non identifiable de façon unique par lesattributs nom et prénom).

Numero Date Gare1 Gare2

1010 01-01-2001 Paris Lyon

1011 02-01-2001 Paris Limoges

1012 03-01-2001 Paris Madrid

1013 03-01-2001 Lyon Limoges

TAB. 5 : RELATION VOYAGE SANS LIEN

Modele Vitesse

TGV 450

TER 200

TAB. 6 : RELATION MODELE

Numero Nom Prénom

1 Dupont Joëlle

2 Durand Jean-Pierre

TAB. 7 : RELATION CONDUCTEUR

Relation éclatée avec liensDans cette représentation éclatée des données précédemment regroupées dans la même relation, on a perdu des informationsimportantes, relatives aux liens entre les voyages, les modèles de train et les conducteurs. En effet on ne sait plus que levoyage numéro 1010 s'effectue sur un TGV avec la conductrice Joëlle Dupont. Il est indispensable, pour conserverl'ensemble des informations, de matérialiser à nouveau ces liens, en ajoutant des références dans la relation Voyage, auxtuples de Modele et Conducteur.


Numero Date Gare1 Gare2 Modele Conducteur

1010 01-01-2001 Paris Lyon TGV 1

1011 02-01-2001 Paris Limoges TER 2

1012 03-01-2001 Paris Madrid TGV 1

1013 03-01-2001 Lyon Limoges TER 2

TAB. 8 : RELATION VOYAGE AVEC LIENS

10. Clé étrangèreClé étrangèreGroupe d'attributs d'une relation R1 devant apparaître comme clé dans une autre relation R2 afin de matérialiser unlien entre les tuples de R1 et les tuples de R2. La clé étrangère d'un tuple référence la clé primaire d'un autre tuple.

Contrainte d'intégrité référentielleUne clé étrangère respecte la contrainte d'intégrité référentielle si sa valeur est effectivement existante dans la cléprimaire d'un tuple de la relation référencée, ou si sa valeur est "null".Une clé étrangère qui ne respecte pas la contrainte d'intégrité référentielle exprime un lien vers un tuple qui n'existepas et donc n'est pas cohérente.

Remarque : Suppression et mise à jour en cascadePour que la cohérence soit conservée, lors de la suppression d'un tuple référencé par d'autres tuples, les tuplesréférençants doivent également être supprimés. Sinon leur clé étrangère pointerait vers des tuples qui n'existent pluset la contrainte d'intégrité référentielle ne serait plus respectée. Afin de maintenir la cohérence, il faut donc procéderà une supression en cascade (sachant que les tuples référençant peuvent également être référencés par ailleurs).La problématique est la même lors d'une mise à jour de la clé primaire d'un tuple : il faut alors mettre à jour toutesles clés étrangères référençant ce tuple.Notons que certains SGBD peuvent se charger automatiquement de ces suppressions et mises à jour en cascade.

11. Schéma relationnelSchéma d'une relationLe schéma d'une relation définit cette relation par intention. Il est composé du nom de la relation, de la liste de sesattributs avec les domaines respectifs dans lesquels ils prennent leurs valeurs, de la clé primaire, et des clésétrangères.

Schéma relationnel d'une base de donnéeLe schéma relationnelle d'une BD est la définition en intention de cette BD (par opposition à l'instance de la BD quiest une extension de la BD). Il est composé de l'ensemble des schémas de chaque relation de la BD.

Syntaxe : RelationRelation (Attribut1:Domaine1, Attribut2:Domaine2, ... , AttributN:DomaineN)

La relation "Relation" contient N attributs chacun défini sur son domaine.

Syntaxe : Clé primaireRelation (Attribut1:Domaine1, ... , AttributM:DomaineM, ... , AttributN:DomaineN)

La clé de la relation "Relation" est composée des attributs "Attribut1" à "AttributM".En général on note la clé primaire en premier dans la relation.

Syntaxe : Clé étrangèreRelation1 (..., AttributM=>Relation2, ... , AttributN=>Relation2)

La relation "Relation1" comporte une clé étrangère (composée des attributs "AttributM" à "AttributN") référençant la cléprimaire de "Relation2". Bien sûr il peut exister plusieurs clés étrangères vers plusieurs relations distinctes. Une cléétrangère et sa clé primaire référencée sont toujours composées du même nombre d'attributs. Il n'est pas nécessaire depréciser les domaines des attributs appartenant à la clé étrangère car ce sont forcément les mêmes que ceux de la clé primaireréférencée. Il n'est pas non plus en général nécessaire de préciser dans le schéma relationnel quels attributs de la cléétrangère référencent quels attributs de la clé primaire (cela est généralement évident) mais il est possible de la faire onnotant "Attribut=>Relation.Attribut".En général on note les clés étrangères en dernier dans la relation, sauf pour les clés étrangères qui font partie de la cléprimaire (clés identifiantes).

Relationnel 59

Clés candidatesOn ne représente pas, en général, sur le schéma relationnel les clés candidates afin de ne pas alourdir la notation. Onrecommande néanmoins de dresser la liste des clés candidates (non choisies comme clés primaires) en annotation duschéma relationnel afin d'en conserver la mémoire.On peut néanmoins noter les clés candidates en les soulignant en pointillé.

12. Exemple de schéma relationnel simple pour la géographieExemple

Personne (Numero:Entier, Nom:Chaîne, Prénom:Chaîne, LieuNaissance=>Ville)Pays (Nom:Chaîne, Population:Entier, Superficie:Réel, Dirigeant=>Personne)Région (Pays=>Pays, Nom:Chaîne, Superficie, Dirigeant=>Personne)Ville (CodePostal:CP, Nom:Chaîne, Pays=>Région.Pays, Région=>Région.Nom,Dirigeant=>Personne)

Le schéma relationnel précédent décrit :♦ Des personnes

Elles sont identifiées par un numéro qui est en fait une clé artificielle. En effet, même une clé composée de tous lesattributs (Nom, Prénom, LieuNaissance) laisse une possibilité de doublons (homonymes nés dans la même ville).

La clé étrangère LieuNaissance fait référence à la relation Ville, et plus précisément à sa clé primaire CodePostal, ce quiest est laissé implicite car évident.

♦ Des pays

Ils sont identifiés par leur nom, puisque deux pays ne peuvent avoir le même nom.

Les pays sont dirigés par des personnes, et ce lien est matérialisé par la clé étrangère Dirigeant.

♦ Des régions

Elles font partie d'un pays et ont un nom. Deux régions de pays différents pouvant avoir le même nom, il faut utiliser uneclé primaire composée à la fois du nom de la région et du nom du pays, qui est une clé étrangère (le nom est appelé clélocale car il n'est pas suffisant pour identifier un tuple de la relation Région, et la clé étrangère vers la relation Pays estappelée clé identifiante).

♦ Des villes

Elles sont identifié par un code postal qui est unique dans le monde (en utilisant le prefixe de pays de type "F-60200"). Cecode postal à pour domaine CP qui est une chaîne composée d'une ou deux lettres, d'un tiret, puis d'une série de chiffres.

Le lien d'appartenance entre une ville et une région est matérialisé par la clé étrangère composée des deux attributs Pays etRégion. Cette clé référence la clé primaire de la relation Région, également composée de deux attributs. Pour clairementexpliciter les références (bien que sémantiquement la dénomination des attributs ne laisse pas de place au doute) on utilisela syntaxe Région.Pays et Région.Nom.

Section A2. Le passage E-A vers Relationnel

Afin de pouvoir implémenter une base de données, il faut pouvoir traduire le modèle conceptuel en modèle logique. Celasignifie qu'il faut pouvoir convertir un modèle E-A ou un modèle UML en modèle relationnel. Dans les deux cas, E-A ouUML, les modèles conceptuels sont suffisamment formels pour ce passage soit systématisé. Nous étudions à présent lesrègles permettant de réaliser ce passage, en nous concentrant sur le passage du modèle E-A au modèle relationnel. Les règlesde passage de UML au modèle relationnel seront suffisamment similaires pour ne pas être détaillées.

1. Transformation des entitésEntité identifiéePour chaque entité (identifiée) E, on crée une relation R dont le schéma est celui de l'entité. La clé primaire de R estune des clés de E.

Entité non identifiéePour chaque entité non identifiée I ayant un identifiant étranger E, on crée une relation R qui comprend tous lesattributs de I, ainsi que les attributs clés de la relation correspondant à E. La clé de R est la concaténation de la clélocale de I et de la clé de E.


2. Transformation des associationsAssociation 1:NPour chaque association binaire A de type 1:N (le cas échéant 0,1:N) entre les entités S et T (représentés par lesrelations RS et RT respectivement) on inclut dans la définition de RS comme clé étrangère la clé de RT ainsi quetous les attributs simples de A.

Association M:N et associations de degré supérieur à 2Pour chaque association binaire A de type M:N ou pour chaque association A de degré supérieur à 2, on crée unenouvelle relation RA pour représenter A. On met dans RA comme clé étrangère, les clés de toutes les relationscorrespondant aux entités participant à A et dont la concaténation formera sa clé. On ajoute également à RA (etéventuellement dans sa clé pour les attributs clés) les attributs définis sur A.

Association 1:1Pour chaque association binaire A de type 1,1:1,1 ou 1,1:1,0 entre les entités S et T (représentées par les relationsRS et RT respectivement) on substitut dans la définition de RS l'éventuelle clé primaire (si RS était identifiée) par laclé primaire de RT qui est également définie comme clé étrangère vers RT. On ajoute également à RS l'ensembledes attributs de A. Notons que dans le cas d'une association 1,1:1,1 RT peut-être choisie à la place de RS pouraccueillir la clé étrangère.Pour chaque association binaire A de type 0,1:0,1 entre les entités S et T (représentées par les relations RS et RTrespectivement) on inclut dans la définition de RS comme clé étrangère la clé de RT ainsi que tous les attributssimples de A. La clé étrangère vers RT incluse dans RS est également définie comme étant unique, afin d'assurer lacardinalité maximum de 1. Notons qu'il n'était pas possible dans ce cas 0,1:0,1 que la clé étrangère vers RT inclusedans RS soit également la clé primaire, car la cardinalité de 0 supposerait que la clé primaire puisse être "null", cequi est illégal pour une clé.

Remarque : Cardinalité minimale 0 ou 1Selon que la cardinalité minimale est 0 ou 1 (ou plus) du côté de la relation référençante on ajoutera ou non unecontrainte de non nullité sur la clé étrangère.Selon que la cardinalité minimale est 0 ou 1 (ou plus) du côté de la relation référencée on ajoutera ou non unecontrainte d'existance de tuples référençant pour chaque tuple de la relation référencée.

3. Remarques concernant la transformation des associations 1:1Remarque : Choix de la relation référençante pour la traduction de l'association 1:1La traduction d'une association 1,1:1,1 ou 0,1:0,1 conduit à devoir faire un choix entre les deux entités composantl'association, afin de déterminer laquelle est référencée de laquelle est référençante[Dans le cas d'une association0,1:1,1, c'est toujours l'entité coté 1,1 qui sera choisie pour référencer.]. Ce choix peut-être arbitraire, mais peutégalement être éclairé par la sémantique des relations, et l'on choisira alors celle qui est de plus faible importance dupoint de vue de la modélisation pour référencer (et donc intégrer la clé étrangère).

Exemple de choix de la relation référençante pour une relation 1:1Soit deux entités, "homme" et "femme" et une association "mariage" de cardinalité 1,1:1,1 (hommes et femmes sontdonc obligatoirement mariés) unissant ces deux entités. Les entités "homme" et "femme" sont identifiées par unattribut "nom". S'il serait plus galant de choisir "femme" comme entité principale, il sera dans la pratique plusopportun de choisir "homme", car le "nom" de l'entité "homme" sera effectivement une propriété pertinente pourl'entité "femme" et donc aura plus de sens en tant que clé primaire et en tant que clé étrangère (dans le cas inverse,la clé de l'homme serait le nom de sa femme, ce qui ne correspond pas à la réalité administrative du mariage). Onchoisira donc plutôt la représentation :

homme (nom)femme (nomMariage=>homme, nomJeuneFille) avec nomJeuneFille clé

Si l'association avait été de cardinalité 0,1:0,1 (certains hommes et femmes ne sont pas mariés), le même choix seserait imposé et l'on aurait abouti au résultat suivant:

homme (nom)femme (nomJeuneFille, nomMariage=>homme) avec nomMariage unique

Remarque : Fusion des relations dans le cas de la traduction de l'association 1:1Il est possible, dans le cas d'une association 1,1:1,1 de décider de fusionner les deux relations en une seule. Larelation résultante est alors composée de l'ensemble des attributs de chacune des deux relations, en choisissant l'unedes deux clés de l'une des deux relations pour identifier la nouvelle relation[C'est également possible pour lesassociations 0,1:1,1, mais c'est généralement moins pertinent, puisque cela conduira à un certain nombre de champsnull. Ce n'est jamais pertinent dans le cas de relations 0,1:0,1.].Ce choix sera conduit par une appréciation du rapport entre :♦ La complexité introduite par le fait d'avoir deux relations là ou une suffit,

♦ La pertinence de la séparation des deux relations d'un point de vue sémantique,

Relationnel 61

♦ Les pertes de performance dues à l'éclatement des relations,

♦ Les pertes de performance dues au fait d'avoir une grande relation,

♦ Les questions de sécurité et de sureté factorisées ou non au niveau des deux relations,

♦ etc.

Dans le doute il est préférable d'adopter l'approche systématique consistant à séparer les deux relations.

4. Transformation des attributsAttributs simplesPour chaque attribut élémentaire et monovalué A d'une entité E (idem pour les associations), on crée un attributcorrespondant à A sur la relation RE correspondant à E.

Attributs compositesPour chaque attribut composite C, comprenant N sous-attributs, d'une entité E (idem pour les associations), on créeN attributs correspondants à C sur la relation RE correspondant à E.

Attributs multivaluésPour chaque attribut multivalué M d'une entité E (idem pour les associations), on crée une nouvelle relation RM quicomprend un attribut monovalué correspondant à M ainsi qu'une clé étrangère vers RE (relation représentant E). Laclé de RM est la concaténation des deux attributs.On gère donc M comme s'il s'agissait d'une entité faible RM, dont la clé locale serait M, et qui serait associée à Epar une relation 1:N.

Attributs dérivésOn ne représente pas en général les attributs dérivés dans le modèle relationnel, ils seront calculés dynamiquementsoit par des procédures internes à la BD (procédures stockées), soit par des procédures au niveau applicatif.On peut néanmoins décider (pour des raisons de performance essentiellement) de représenter l'attribut dérivécomme s'il s'agissait d'un attribut simple, mais il sera nécessaire dans ce cas d'ajouter des mécanismes de validationde contraintes dynamiques (avec des déclencheurs par exemple) pour assurer que la valeur stockée évolue en mêmetemps que les attributs sur lesquels le calcul dérivé porte. Notons qu'introduire un attribut dérivé dans le modèlerelationnel équivaut à introduire de la redondance, ce qui est en gérénal déconseillé, et ce qui doit être dans tous lescas contrôlé.

5. Exemple de passage E-A vers relationnelExemple

IMG. 30 : TRANSFORMATION AVEC UNE RELATION 1:N


Exemple

IMG. 31 : TRANSFORMATION AVEC UNE RELATION M:N

6. Transformation de la relation d'héritageLes entités non finales sont abstraitesEn modélisation E-A on considèrera toujours que les entités non finales (c'est à dire qui sont héritées par d'autresentités) sont abstraites.Une entité abstraite est une entité qui ne peut pas être instanciée.Donc si E2 hérite de E1 (et que E2 est finale c'est à dire qu'aucune classe n'hérite de E2), il existera des objets deE2, mais pas des objets de E1. Si l'on veut disposer d'objets de E1, il suffit de créer une classe E1' qui hérite de E1sans apporter de propriété supplémentaire.En modélisation UML on pourra différencier les classes abstraites des classes instanciables.

Relationnel 63

7. Exemple de transformation d'une relation d'héritageExempleSoit le modèle E-A suivant :

SCH. 5 : REPRÉSENTATION DE DOCUMENTS

Il existe trois façons de traduire la relation d'héritage : par référence, par absorption par les sous-types d'entité, parabsorption par l'entité générale.

Remarque : Type d'héritageSi une thèse peut également être un livre (et dans la réalité c'est bien le cas puisqu'une thèse peut-être publiée), alorsl'héritage n'est pas exclusif puisque un même document peut être une thèse et un livre.L'héritage n'est pas non plus complet, puisque l'on observe que les thèses et les livres ont des attributs qui ne sontpas communs (la discipline pour la thèse et l'éditeur pour le livre).En toute rigueur, il faudrait donc appliqué le cas général (ni exclusif, ni complet) et appliqué une traduction del'héritage par référence. Observons néanmoins les avantages et inconvénients que chacun des trois choix porterait.

Héritage représenté par une référenceDocument(Titre:Chaîne, Auteur:Chaîne)These(Titre=>Document, Discipline:Chaîne)Livre(Titre=>Document), Editeur:Chaîne

Remarque : Avantages du choixIl n'y a ni redondance ni valeur nulle inutile dans les relations These et Livre, c'est la traduction la plus juste pour leproblème posé.

Remarque : Inconvénient du choixIl est relativement lourd de devoir créer un tuple dans Document pour chaque tuple dans These ou Livre, alors quela relation Document ne porte que l'information concernant l'auteur, juste pour assurer les cas, par ailleurs plutôtrares dans la réalité, où les thèses sont publiées sous forme de livres.


Héritage absorbé par les sous-types d'entitéThese(Titre, Discipline:Chaîne, Auteur:Chaîne)Livre(Titre), Editeur:Chaîne, Auteur:Chaîne

Remarque : Avantages du choixIl est plus simple que le précédent, puisque la représentation d'une thèse ou d'un livre ne nécessite plus que d'ajouterun seul tuple. Il évite donc les clés étrangères, toujours plus délicates à gérer d'un point de vue applicatif.

Remarque : Inconvénient du choixLorsqu'une thèse est publiée sous la forme d'un livre, alors une information sera dupliquée (l'auteur), ce quiintroduit de la redondance. Si une telle redondance peut-être tolérée pour des raisons de simplification ou deperformance (si on considère que le cas est rare par exemple et donc que l'héritage est "presque" exclusif), il seranéanmoins nécessaire d'assurer son contrôle par un moyen supplémentaire.Dans le cas général, il n'est pas souhaitable de tolérer une telle redondance.

Héritage absorbé par l'entité généraleDocument(Titre, Discipline:Chaîne, Editeur:Chaîne, Auteur:Chaîne,Type:{These|Livre|These+Livre})

Remarque : Avantages du choixIl est plus simple que le premier, puisque la représentation d'une thèse ou d'un livre ne nécessite plus que d'ajouterun seul tuple. Il évite donc les clés étrangères, toujours plus délicates à gérer d'un point de vue applicatif.

Remarque : Inconvénient du choixPuisqu'il est rare que les thèses soient publiées sous forme de livre alors les tuples de la relation Documentcontiendront la plupart du temps une valeur nulle soit pour l'éditeur soit pour la discipline.Cette introduction de valeurs nulles est moins problématique que l'introduction de redondance observée dans le casprécédent, aussi elle peut-être plus facilement tolérée. On considère alors que l'héritage est "presque" complet,puisque seuls deux attributs sont distingués. Cela dit ils s'agit de deux attributs sur quatre, soit une proportionimportante d'une part, et il est regrettable que l'héritage soit également "presque" exclusif puisque l'introductiond'une valeur nulle sera quasi-systématique.

En conclusionConseilL'héritage est toujours délicat à traduire en relationnel, ce qui est dommage car son pouvoir de représentationconceptuel est fort.Un conseil pour assumer une gestion correcte de la traduction de la relation d'héritage serait d'appliquer à la lettreles règles de transformation (ce qui conduira le plus souvent à un héritage par référence) et, l'expérience aidant, detolérer dans des cas bien maîtrisés des digressions à cette règle.

8. Comparaison des modèles E-A, UML et relationnel

Modèle E-A Modèle UML Modèle relationnel

Entité Classe Relation

Occurence d'une entité Objet Nuplet

Attribut simple Attribut simple Attribut atomique

Attribut composite Attribut composite Ensemble d'attributs

Attribut multivalué Attribut multivalué Relation

Attribut dérivé Attribut dérivé Procédure stockée ou contraintedynamique

- Méthode Procédure stockée

Entité faible - Relation

Association 1:N Association 1:N Attributs

Association N:M Association N:M Relation

Association de degré 3 ousupérieur

Association de degré 3 ousupérieur Relation

Occurence d'une association Occurence d'une association Nuplet

Héritage Héritage Vue

TAB. 9 : SYNTHÈSE E-A ET UML VERS RELATIONNEL

Relationnel 65

Section A3. Pratique du passage E-A vers relationnel

Exercice n°7. La gestion d'une compagnie touristiqueCet exercice est extrait de (Foucault & al., 1996)Une agence de voyage organise des circuits touristiques dans divers pays. Ses règles de gestion sont celles énoncées ci après.RG1 - On garde trace de tous les clients connus même s'ils n'ont pas participé a des circuits touristiques depuis longtemps.RG2 - On répertorie un seul hôtel par ville.RG3 - Toutes les villes sont désignées par des noms distincts.RG4 - Il y a un seul accompagnateur par voyage.RG5 - Toute nuit pendant le circuit est passée dans un hôtel.RG6 - Toute circuit concerne au moins deux villes.RG7 - Toutes les villes répertoriés ne sont pas obligatoirement utilisées dans un circuit à chaque période.RG8 - A une même date, aucun circuit ne part plus d'une fois d'une même ville ni n'arrive plus d'une fois dans une mêmeville.RG9 - Les demandes de réservations donnent lieu à des réponses positives dans la mesure de places disponibles.RG10 - Un client ne peut obtenir une réservation qu'après une réponse positive et le versement d'un acompte.RG11 - Une réservation ne sera définitive qu'après le règlement du solde dû par un deuxième versement.RG12 - Après une date limite D1 (p.ex. un mois avant le départ) les réservations qui n'ont pas donné lieu au deuxièmeversement sont annulées, l'agence pouvant ainsi redisposer des places correspondantes sans que les clients concernés puissentexiger le moindre remboursement.RG13 - Après une date limite D2 (p.ex. 15 jours avant le départ) :♦ S'il n'y a pas assez de réservations définitives, le circuit est annulé et les clients dont la réservation est définitive, sont

remboursés intégralement

♦ S'il n'y a aucune réservation définitive, le circuit est a fortiori annulé,

♦ S'il y a assez de réservations, le circuit est maintenu.

Question1Etablissez une version simplifiée du dictionnaire de données, en présentant dans un tableau : Les entités, les clés, lespropriétés avec leur signification.

Question2Lister les associations reliant les entités.

Question3Donnez le schéma Entité-Association correspondant et décrivez les associations figurant dans le schéma.

Question4Définissez le schéma relationnel correspondant.

Question5Présentez les contraintes d'intégrité que l'on pourrait associer au schéma relationnel.

Section A4. Le passage UML vers Relationnel

Afin de pouvoir implémenter une base de données, il faut pouvoir traduire le modèle conceptuel en modèle logique. Celasignifie qu'il faut pouvoir convertir un modèle UML en modèle relationnel. Les modèles conceptuels sont suffisammentformels pour ce passage soit systématisé.

1. Transformation des classesClassePour chaque classe C non abstraite, on crée une relation R dont le schéma est celui de la classe. La clé primaire de Rest une des clés de C.

Les classes abstraites sont ignorées à ce stade, et n'étant pas instanciables, ne donnent jamais lieu à la création derelation.


2. Transformation des associationsAssociation 1:NPour chaque association binaire A de type 1:N (le cas échéant 0,1:N) entre les classes S et T (représentés par lesrelations RS et RT respectivement) on inclut dans la définition de RS comme clé étrangère la clé de RT.

Association M:N et associations de degré supérieur à 2Pour chaque association binaire A de type M:N ou pour chaque association A de degré supérieur à 2, on crée unenouvelle relation RA pour représenter A. On met dans RA comme clé étrangère, les clés de toutes les relationscorrespondant aux classes participant à A et dont la concaténation formera sa clé.

Association 1:1Pour chaque association binaire A de type 1,1:1,1 ou 1,1:1,0 entre les classes S et T (représentés par les relations RSet RT respectivement) on substitut dans la définition de RS l'éventuelle clé primaire (si RS était identifiée) par la cléprimaire de RT qui est également définie comme clé étrangère vers RT. Notons que dans le cas d'une association1,1:1,1 RT peut-être choisi à la place de RS pour accueillir la clé étrangère.Pour chaque association binaire A de type 0,1:0,1 entre les classes S et T (représentés par les relations RS et RTrespectivement) on inclut dans la définition de RS comme clé étrangère la clé de RT. La clé étrangère vers RTincluse dans RS est également définie comme étant unique, afin d'assurer la cardinalité maximum de 1. Notons qu'iln'était pas possible dans ce cas 0,1:0,1 que la clé étrangère vers RT incluse dans RS soit également la clé primaire,car la cardinalité de 0 supposerait que la clé primaire puisse être "null", ce qui est illégal pour une clé.

Cardinalité minimale 0 ou 1Selon que la cardinalité minimale est 0 ou 1 (ou plus) du côté de la relation référençante on ajoutera ou non unecontrainte de non nullité sur la clé étrangère.Selon que la cardinalité minimale est 0 ou 1 (ou plus) du côté de la relation référencée on ajoutera ou non unecontrainte d'existance de tuples référençant pour chaque tuple de la relation référencée.

3. Remarques concernant la transformation des associations 1:1Remarque : Choix de la relation référençante pour la traduction de l'association 1:1La traduction d'une association 1:1 ou 0..1:0..1 conduit à devoir faire un choix entre les deux classes composantl'association, afin de déterminer laquelle est référencée de laquelle est référençante[Dans le cas d'une association1:0..1, c'est toujours la classe coté 0..1 qui sera choisie pour référencer.]. Ce choix peut-être arbitraire, mais peutégalement être éclairé par la sémantique des relations, et l'on choisira alors celle qui est de plus faible importance dupoint de vue de la modélisation pour référencer (et donc intégrer la clé étrangère).

Exemple de choix de la relation référençante pour une relation 1:1Soit deux classes, "homme" et "femme" et une association "mariage" de cardinalité 1:1 (hommes et femmes sontdonc obligatoirement mariés) unissant ces deux classes. Les classes "homme" et "femme" sont identifiées par unattribut "nom". S'il serait plus galant de choisir "femme" comme classe principale, il sera dans la pratique plusopportun de choisir "homme", car le "nom" de la classe "homme" sera effectivement une propriété pertinente pourla classe "femme" et donc aura plus de sens en tant que clé primaire et en tant que clé étrangère (dans le cas inverse,la clé de l'homme serait le nom de sa femme, ce qui ne correspond pas à la réalité administrative du mariage). Onchoisira donc plutôt la représentation :

homme (nom)femme (nomMariage=>homme, nomJeuneFille) avec nomJeuneFille clé

Si l'association avait été de cardinalité 0..1:0..1 (certains hommes et femmes ne sont pas mariés), le même choix seserait imposé et l'on aurait abouti au résultat suivant:

homme (nom)femme (nomJeuneFille, nomMariage=>homme) avec nomMariage unique

Remarque : Fusion des relations dans le cas de la traduction de l'association 1:1Il est possible, dans le cas d'une association 1:1 de décider de fusionner les deux relations en une seule. La relationrésultante est alors composée de l'ensemble des attributs de chacune des deux relations, en choisissant l'une desdeux clés de l'une des deux relations pour identifier la nouvelle relation[C'est également possible pour lesassociations 1:0..1, mais c'est généralement moins pertinent, puisque cela conduira à un certain nombre de champsnull. Ce n'est jamais pertinent dans le cas de relations 0..1:0..1.].Ce choix sera conduit par une appréciation du rapport entre :♦ La complexité introduite par le fait d'avoir deux relations là ou une suffit,

♦ La pertinence de la séparation des deux relations d'un point de vue sémantique,

♦ Les pertes de performance dues à l'éclatement des relations,

♦ Les pertes de performance dues au fait d'avoir une grande relation,

♦ Les questions de sécurité et de sureté factorisées ou non au niveau des deux relations,

Relationnel 67

♦ etc.

Dans le doute il est préférable d'adopter l'approche systématique consistant à séparer les deux relations.

4. Transformation des attributs et méthodesAttributs simplesPour chaque attribut élémentaire et monovalué A d'une classe E (idem pour les associations), on crée un attributcorrespondant à A sur la relation RE correspondant à E.

Attributs compositesPour chaque attribut composite C, comprenant N sous-attributs, d'une classe E (idem pour les associations), on créeN attributs correspondants à C sur la relation RE correspondant à E.

Attributs multivaluésPour chaque attribut multivalué M d'une classe E (idem pour les associations), on crée une nouvelle relation RM quicomprend un attribut monovalué correspondant à M plus la clé de RE (relation représentant E). La clé de RM est laconcaténation des deux attributs.

Attributs dérivés et méthodesOn ne représente pas en général les attributs dérivés ni les méthodes dans le modèle relationnel, ils seront calculésdynamiquement soit par des procédures internes à la BD (procédures stockées), soit par des procédures au niveauapplicatif.On peut néanmoins décider (pour des raisons de performance essentiellement) de représenter l'attribut dérivé ou laméthode comme s'il s'agissait d'un attribut simple, mais il sera nécessaire dans ce cas d'ajouter des mécanismes devalidation de contraintes dynamiques (avec des triggers par exemple) pour assurer que la valeur stockée évolue enmême temps que les attributs sur lesquels le calcul dérivé porte. Notons qu'introduire un attribut dérivé ou unrésultat de méthode dans le modèle relationnel équivaut à introduire de la redondance, ce qui est en gérénaldéconseillé, et ce qui doit être dans tous les cas contrôlé.

5. Transformation des classes d'association

Classe d'association 1:NLes attributs de la classe d'association sont ajoutés à la relation issue de la classe côté N.

Classe d'association N:MLes attributs de la classe d'association sont ajoutés à la relation issue de l'association N:M.

Classe d'association 1:1Les attributs de la classe d'association sont ajoutés à la relation qui a été choisie pour recevoir la clé étrangère. Bienentendu si les deux classes ont été fusionnées en une seule relation, les attributs sont ajoutée à celle-ci.

6. Transformation des compositionsRemarque :Une composition est transformée comme une association 1:N, mais on ajoute à la clé de la classe partie (dite clélocale) la clé étrangère vers la classe composite.

CompositionsSoit la composition entre la classe composite C et la classe partie P (représentés par les relations RC et RPrespectivement) on inclut dans la définition de RP comme clé étrangère la clé de RC. La clé de RP est redéfiniecomme la concaténation de la clé de P (clé locale) avec la clé étrangère vers RC.

Remarque : Composition et entités faibles en E-AUne composition est transformée selon les mêmes principes qu'une entité faible en E-A.

7. Transformation de la relation d'héritageLe modèle relationnel ne permet pas de représenter directement une relation d'héritage, puisque que seuls les concepts derelation et de référence existent dans le modèle. Il faut donc appauvrir le modèle conceptuel pour qu'il puisse être représentéselon un schéma relationnel.


Trois solutions existent pour transformer une relation d'héritage :♦ Représenter l'héritage par une référence entre la classe mère et la classe fille.

♦ Représenter uniquement les classes filles par des relations.

♦ Représenter uniquement la classe mère par une relation.

Choisir le bon mode de transformation d'une relation d'héritageLa difficulté consiste donc pour chaque relation d'héritage à choisir le bon mode de transformation, sachant quechaque solution possède ses avantages et ses inconvénients.

Mode detransformation Limite Cas d'usage Exemple Vue

Par référence

Lourdeur liée à lanécessité dereprésenter lesdonnées desclasses filles surdeux relations

Adapté à tous lescas d'héritage niexclusif, nicomplet -particulièrementadapté lorsque laclasse mère n'estpas abstraite.

Etudiant etEmploye héritentde Personne (unétudiant peut êtreemployé et lespropriétés desétudiants et desemployés sontdifférentes, deplus despersonnespeuvent exister quine sont niemployés niétudiants).

Une vue doit êtrecréée pour chaqueclasse fille(réalisant lajointure avec laclasse mère).

Par les classesfilles

Redondance liée àl'existancesimultanée detuples dansplusieurs classesfilles

Adapté à l'héritageexclusif -particulièrementadapté lorsque laclasse mère estabstraite.

Homme et Femmehéritent dePersonne (untuple de Hommene peut pas êtreun tuple deFemme etPersonne estabstraite, iln'existe pas dePersonne qui nesoit ni un Homme,ni une Femme).

Une vue doit êtrecréée, uniquementdans le cas où laclasse mère n'estpas abstraite, pourunir les tuples desclasses filles avecceux spécifiques àla classe mère.

Par la classe mère Nullitésystématique pourles attributs d'uneclassefille n'existant paspour une autreclasse fille (et pourla classe mère sicelle-ci n'est pasabstraite)

Adapté à l'héritagecomplet -particulièrementadapté lorsque laclasse mère n'estpas abstraite.

Responsable et Salariéhéritentde Employé (unresponsable estsalarié et aucunattribut n'estspécifique ni àResponsable, ni àSalarié, de plus ilexiste desstagiaires parexemple qui sontjuste employés,mais non salariéset nonresponsables)

Une vue doit êtresystématiquementcréée pour chaqueclasse fille(réalisant larestriction et laprojection depuisla relation uniquecréée).

TAB. 10 : CHOIX DE LA BONNE TRANSFORMATION

Relationnel 69

Mode detransformation

Classemèreabstraite

Classemère nonabstraite

Héritageexclusif

Héritagenonexclusif

Héritagecomplet

Héritagepresquecomplet

Héritagenoncomplet

Parréférence - - + = = - = =

Par lesclassesfilles

+ - + + - - = = =

Par laclassemère

- + +. = + + = -

TAB. 11 : CHOIX DE LA BONNE TRANSFORMATION

8. Transformation de la relation d'héritage par référenceHéritage représenté par une référenceChaque classe, mère ou fille, est représentée par une relation. La clé primaire d'une classe mère est utilisée pouridentifier chacune de ses classes filles (cette clé étant pour chaque classe fille à la fois la clé primaire et une cléétrangère vers la classe générale).Si une classe fille avait une autre clé primaire candidate dans le modèle conceptuel, cette clé n'est pas retenue pourêtre la clé primaire, étant donné que c'est la clé étrangère référence à la classe mère qui est retenue.La cardinalité d'un lien entre une classe fille et une classe mère est (1,1):(0,1). En effet toute classe fille référenceobligatoirement une et une seule classe mère (pas d'héritage multiple) et toute classe mère est référencée une ouzéro fois (zéro fois si un objet peut être directement du type de la classe mère) par chaque classe fille .Une vue devra être créée pour chaque classe fille en réalisant une jointure sur la classe mère.

Exemple : Héritage représenté par une référenceSoit la classe A avec la clé K et les attributs A1 et A2. Soit la classe B, classe fille de A, comprenant la clé K' et lesattributs B1 et B2. Le modèle relationnel correspondant selon cette transformation est [on remarquera que K' n'estpas retenue comme clé primaire de B] :

A (K, A1, A2)B (K=>A, K', B1, B2)

Remarque : Classe mère non abstraiteCette solution est particulièrement adaptée lorsque la classe mère n'est pas abstraite, car cela en autorisel'instanciation sans aucun bruit dans la relation lié aux classes filles. Par contre si la classe mère est abstraite il fautintroduire une contrainte dynamique complexe pour imposer la présence d'un tuple référençant dans une des classesfilles.Ainsi dans l'exemple précédent, un A peut être instancié en toute indépendance par rapport à la relation B.

Solution généraleCette solution est la plus générale, elle fonctionne correctement dans tous les cas. Le seul problème est lacomplexité de la structure de donnée qu'elle induit.

9. Transformation de la relation d'héritage par les classes fillesHéritage absorbé par les classes fillesChaque classe fille est représenté par une relation. Tous les attributs de la classe mère sont répétés au niveau dechaque classe fille .Si une classe fille a une clé primaire propre, cette clé n'est pas retenue, et c'est bien la clé héritée de la classe mèrequi devient la clé primaire (mais la clé est bien entendu maintenue comme clé candidate)Si la classe mère n'est pas abstraite, elle est également représentée par une relation qui ne contiendra que les tuplesqui ne sont pas aussi des instances de classes filles. La classe mère est alors représentée par une vue qui unit sespropres tuples avec les tuples de toutes ses classes filles et en les projetant sur les attributs hérités uniquement.

Exemple : Héritage absorbé par les classes fillesSoit la classe abstraite A avec la clé K et les attributs A1 et A2. Soit la classe B, classe fille de A avec les attributsB1 et B2. Soit la classe C, classe fille de A avec les attributs C1 et C2 Le modèle relationnel correspondant seloncette transformation est :

B (K, A1, A2, B1, B2)C (K, A1, A2, C1, C2)


Si A n'avait pas été abstraite elle aurait donné naissance à une relation A possédant les attributs A1 et A2 et quin'auraient alors contenu que les tuples qui ne sont ni des B ni des C.

Remarque : Classe mère abstraiteCette solution est particulièrement adaptée lorsque la classe mère est abstraite, car elle permet de ne pas matérialisercette classe mère par une relation.En revanche dans le cas où la classe mère n'est pas abstraite, la solution est moins adaptée, car il faut alors passerpar une vue pour retrouver tous les tuples de la classe.

Héritage exclusifCette solution est optimum dans le cas d'un héritage exclusif, c'est à dire si aucun objet d'une classe fille n'appartientaussi à une autre classe fille. Dans le cas contraire, le problème est que des redondances vont être introduitespuisqu'un même tuple devra être répété pour chaque classe fille à laquelle il appartient.

10. Transformation de la relation d'héritage par la classe mèreHéritage absorbé par la classe mèreLa classe mère est représentée par une relation, mais ses classes filles ne sont pas représentées par des relations.Tous les attributs de chaque classe fille sont réintégrés au niveau de la classe mère.Un attribut supplémentaire, dit de discrimination, est ajouté à la classe mère, afin de distinguer les tuples desdifférentes classes filles. Cet attribut est de type énumération et a pour valeurs possibles les noms des différentsclasses filles. Afin de gérer l'héritage non exclusif (un objet peut être de plusieurs classe fille à la fois), le domainede l'attribut de discrimination, peut être étendu à des combinaisons de noms des différents classes filles. Si la classemère n'est pas abstraite, une valeur supplémentaire peut-être ajoutée au domaine, ou bien l'on peut autoriser lavaleur null qui désignera alors un objet de la classe mère.Si une classe fille a une clé primaire propre, cette clé sera réintégrée à la classe mère, au même titre qu'un autreattribut, mais bien entendu n'officiera pas en tant que clé primaire (et en général pas non plus en tant que clécandidate car elle pourra contenir des valeurs nulles).Chaque classe fille est représentée par une vue qui sélectionne les tuples de la classe mère qui appartiennent à laclasse fille et les projete sur les attributs de la classe fille.

Exemple : Héritage absorbé par la classe mèreSoit la classe A avec la clé K et les attributs A1 et A2. Soit la classe B, classe fille de A avec les attributs B1 et B2.Soit la classe C, classe fille de A avec les attributs C1 et C2 Le modèle relationnel correspondant selon cettetransformation est [on remarquera l'attibut supplémentaire de discrimination D dont le domaine est l'énumérationdes noms des classes filles, avec ici la prise en compte d'un héritage non exclusif.] :

A (K, A1, A2, B1, B2, C1, C2, D:{'B','C','BC'})

Si l'on pose que A n'est pas abstraite, alors un tuple sera un A s'il a la valeur null pour sa propriété D. Si l'on poseque A est abstraite, on ajoutera la contrainte NOT NULL à la propriété D.

Remarque : Classe mère non abstraiteCette solution est particulièrement adaptée lorsque la classe mère n'est pas abstraite, car cela en autorisel'instanciation naturellement, en ne renseignant pas l'attribut de discrimination. Lorsque la classe mère est abstraitedes contraintes supplémentaires doivent être ajoutées pour assurer que l'appartenance à une classe fille est toujoursspécifiée.

Héritage completCette solution est optimum dans le cas d'un héritage complet, c'est à dire si les classes filles ne définissent pasd'attributs autre que ceux hérités. Dans le cas contraire cela engendre des valeurs null.En pratique l'héritage complet est rare, mais nombre d'héritages le sont presque et pourront alors êtreraisonnablement gérés sellon cette approche, a fortiori si la classe mère n'est pas abstraite.

Autre représentation de la discriminationSi l'héritage concerne un nombre élevé de classes filles et qu'il est principalement non exclusif alors le domaine del'attribut de discrimination peut impliquer une combinatoire importante de valeurs. Pour contourner cette lourdeur ilest possible d'utiliser, en remplacement, un attribut de domaine booléen pour chaque classe fille spécifiant si untuple est un objet de cette classe.Dans cette configuration la classe mère sera logiquement considérée comme non abstraite et un objet appartiendra àla classe mère si tous ses attributs de discrimination valent "faux". Seule une contrainte dynamique permettra dedéfinir la classe mère comme abstraite, en précisant que les attributs de discrimination ne peuvent être tous à "faux".

Relationnel 71

11. Exemple de transformation d'une relation d'héritageExempleSoit le modèle UML suivant :

SCH. 6 : REPRÉSENTATION DE DOCUMENTS

Il existe trois façons de traduire la relation d'héritage : par référence, par absorption par les classes filles, parabsorption par la classe mère.

Remarque : Type d'héritageSi une thèse peut également être un livre (et dans la réalité c'est bien le cas puisqu'une thèse peut-être publiée), alorsl'héritage n'est pas exclusif puisque un même document peut être une thèse et un livre.L'héritage n'est pas non plus complet, puisque l'on observe que les thèses et les livres ont des attributs qui ne sontpas communs (la discipline pour la thèse et l'éditeur pour le livre).En toute rigueur, il faudrait donc appliqué le cas général (ni exclusif, ni complet) et appliqué une traduction del'héritage par référence. Observons néanmoins les avantages et inconvénients que chacun des trois choix porterait.

Héritage représenté par une référenceDocument(Titre:Chaîne, Auteur:Chaîne)These(Titre=>Document, Discipline:Chaîne)Livre(Titre=>Document), Editeur:Chaîne

Remarque : Avantages du choixIl n'y a ni redondance ni valeur nulle inutile dans les relations These et Livre, c'est la traduction la plus juste pour leproblème posé.

Remarque : Inconvénient du choixIl est relativement lourd de devoir créer un tuple dans Document pour chaque tuple dans These ou Livre, alors quela relation Document ce porte que l'information concernant l'auteur, juste pour assurer les cas, par ailleurs plutôtrare dans la réalité, où les thèses sont publiées sous forme de livres.


Héritage absorbé par les classe fillesThese(Titre, Discipline:Chaîne, Auteur:Chaîne)Livre(Titre), Editeur:Chaîne, Auteur:Chaîne

Remarque : Avantages du choixIl est plus simple que le précédent, puisque la représentation d'une thèse ou d'un livre ne nécessite plus que d'ajouterun seul tuple. Il évite donc les clés étrangères, toujours plus délicates à gérer d'un point de vue applicatif.

Remarque : Inconvénient du choixLorsqu'une thèse est publiée sous la forme d'un livre, alors une information sera dupliquée (l'auteur), ce quiintroduit de la redondance. Si une telle redondance peut-être tolérée pour des raisons de simplification ou deperformance (si on considère que le cas est rare par exemple et donc que l'héritage est "presque" exclusif), il seranéanmoins nécessaire d'assurer son contrôle par un moyen supplémentaire.Dans le cas général, il n'est pas souhaitable de tolérer une telle redondance.

Héritage absorbé par la classe mèreDocument(Titre, Discipline:Chaîne, Editeur:Chaîne, Auteur:Chaîne,Type:{These|Livre|These+Livre})

Remarque : Avantages du choixIl est plus simple que le premier, puisque la représentation d'une thèse ou d'un livre ne nécessite plus que d'ajouterun seul tuple. Il évite donc les clés étrangères, toujours plus délicates à gérer d'un point de vue applicatif.

Remarque : Inconvénient du choixPuisqu'il est rare que les thèses soient publiées sous forme de livre alors les tuples de la relation Documentcontiendront la plupart du temps une valeur nulle soit pour l'éditeur soit pour la discipline.Cette introduction de valeurs nulles est moins problématique que l'introduction de redondance observée dans le casprécédent, aussi elle peut-être plus facilement tolérée. On considère alors que l'héritage est "presque" complet,puisque seuls deux attributs sont distingués. Cela dit ils s'agit de deux attributs sur quatre, soit une proportionimportante d'une part, et il est regrettable que l'héritage soit également "presque" exclusif puisque l'introductiond'une valeur nulle sera quasi-systématique.

En conclusionConseilL'héritage est toujours délicat à traduire en relationnel, ce qui est dommage car son pouvoir de représentationconceptuel est fort.Un conseil pour assumer une gestion correcte de la traduction de la relation d'héritage serait d'appliquer à la lettreles règles de transformation (ce qui conduira le plus souvent à un héritage par référence) et, l'expérience aidant, detolérer dans des cas bien maîtrisés des digressions à cette règle.

12. Héritage et clé primaire

Dans tous les cas, notamment en cas d'héritage à plusieurs niveaux, c'est la clé primaire de la classe la plus généralequi est retenue pour identifier les classes filles héritant directement ou indirectement de cette classe.

Exemple :Ainsi si C hérite de B qui hérite de A, c'est la clé de A qui permettra d'identifier les classes A, B et C, et ce quelquesoit le mode de transformation retenu.

13. Liste des contraintes

Contraintes exprimées sur le diagrammeLes contraintes exprimées sur le diagrammes sont reportées dans un tableau qui accompagnera le modèle logique.

Extension des contraintes expriméesOn s'attachera lors de la modélisation logique à exprimer l'ensemble des contraintes dynamiques pesant sur lemodèle, même celles qui ont été considérées comme secondaires ou évidentes lors de la modélisation conceptuelle.

Relationnel 73

14. Correspondance entre UML et relationnel

Modèle UML Modèle relationnel

Classe instanciable Relation

Classe abstraite Rien

Objet Nuplet

Attribut simple Attribut atomique

Attribut composite Ensemble d'attributs

Attribut multivalué Relation

Attribut dérivé Procédure stockée ou contrainte dynamique

Méthode Procédure stockée

Association 1:N Attributs

Association N:M Relation

Association de degré 3 ou supérieur Relation

Composition Attributs

Classe d'association Attributs

Occurence d'une association Nuplet

Héritage Vues

TAB. 12 : SYNTHÈSE UML VERS RELATIONNEL

Section A5. Pratique du passage UML vers relationnel

Exercice n°8. Gestion de parc informatiqueVous avez en charge la réalisation d'un modèle de base de données pour la gestion d'un parc informatique.L'analyse des besoins révèlent les informations suivantes : tout matériel informatique est identifié de façon unique par unnuméro de série et est décrit par une désignation. Il existe trois types de matériel informatique : les PC, les serveurs et lesimprimantes. Pour les PC les informations que l'on veut gérer sont la taille de la mémoire vive et la cadence dumicro-processeur, pour les serveurs on veut gérer leur volume de disque dur et pour les imprimante leur résolution maximaled'impression. On veut également gérer les connections réseau sachant que tout PC peut être relié à un ou plusieurs serveur etque chaque serveur sert bien entendu plusieurs PC ; et qu'un PC peut être rélié à une imprimante, qui est également utiliséepar plusieurs PC. Quand un PC est relié à un serveur, on veut gérer le quota de disque dont il dispose sur ce serveur.

Question1Réaliser le modèle conceptuel E-A ou UML de ce problème.

Question2Réalisez le passage au modèle logique relationnel.

Partie B. Algèbre relationnel

Objectifs pédagogiquesConnaître les fondements du modèle relationnel.Savoir effectuer le passage d'un schéma conceptuel à un schéma relationnel.Maîtriser l'algèbre relationnelle.


Section B1. Algèbre relationnelle

Concepts manipulatoiresLa représentation d'information sous forme relationnelle est intéressante car les fondements mathématiques du relationnel,outre qu'ils permettent une modélisation logique simple et puissante, fournissent également un ensemble de concepts pourmanipuler formellement l'information ainsi modélisée.Ainsi une algèbre relationnelle, sous forme d'un ensemble d'opérations formelles permet d'exprimer des questions, ourequêtes, posées à une représentation relationnelle, sous forme d'expressions algébriques.L'algèbre relationnelle est composée par les cinq opérateurs de base et les trois opérateurs additionnels suivants :♦ Opérateurs de base

- Union

- Différence

- Projection

- Restriction

- Produit cartésien

♦ Opérateurs additionels

- Intersection

- Jointure

- Division

Remarque : Algèbre relationnelle et SQLLes questions formulées en algèbre relationnelle sont la base du langage SQL, qui est un langage informatiqued'expressions permettant d'interroger une base de données relationnelle.

Remarque : Algèbre relationnelle et objetL'algèbre relationnelle est étendue à une algèbre permettant de manipuler des objets autres, et a priori pluscomplexes, que des relations. Cette algèbre étendue permet l'interrogation d'informations modélisées sous formerelationnelle-objet.

1. Opérateurs ensemblistesAttentionLes opérateurs ensemblistes sont des relations binaires (c'est à dire entre deux relations) portant sur des relations demême schéma.

UnionL'union de deux relations R1 et R2 de même schéma produit une relation R3 de même schéma constituée del'ensemble des tuples appartenant à R1 et/ou à R2.

DifférenceLa différence entre deux relations R1 et R2 de même schéma produit une relation R3 de même schéma constituéede l'ensemble des tuples de R1 n'appartenant pas à R2. Notons que la différence entre R1 et R2 n'est pas égale à ladifférence entre R2 et R1.

IntersectionL'intersection de deux relations R1 et R2 de même schéma produit une relation R3 de même schéma constituée del'ensemble des tuples appartenant à la fois à R1 et à R2. Notons que l'intersection n'est pas une opération de base,car elle est équivalent à deux opérations de différence successives.

ExempleSoit les deux relations suivantes :

Homme (Nom, Prénom, Age)Femme (Nom, Prénom, Age)

Soit les tuples suivants pour ces deux relations respectivement :

(Dupont, Pierre, 20)(Durand, Jean, 30)

(Martin, Isabelle, 20)(Tintin, Hélène, 30)

Relationnel 75

Soit l'opération suivante :

R = Union (Homme, Femme)

On obtient alors la relation R composée des tuples suivants :

(Dupont, Pierre, 20)(Durand, Jean, 30)(Martin, Isabelle, 20)(Tintin, Hélène, 30)

La différence entre Homme et Femme (respectivement entre Femme et Homme) renvoie la relation Homme(respectivement Femme), car aucun tuple n'est commun aux deux relations. L'intersection entre Homme est Femmeest vide, pour la même raison.

Remarque : Union externeIl est possible de définir une opération d'union externe, qui permet de réaliser l'union de deux relations de schémadifférent, en ramenant les relations aux mêmes schémas, et en les complétant avec des valeurs nulles.

2. ProjectionProjectionLa projection est une opération unaire (c'est à dire portant sur une seule relation). La projection de R1 sur une partiede ses attributs {A1, A2, ...} produit une relation R2 dont le schéma est restreint aux attributs mentionnés enopérande, comportant les mêmes tuples que R1, et dont les doublons sont éliminés.

Remarque : Elimination des doublonsAprès suppression d'une partie des attributs du schéma, la relation peut comporter des doublons. Etant donné quel'on ne pourrait plus identifier ces doublons les uns par rapport aux autres, la seule solution sensée est donc deconsidérer que deux doublons sont équivalents, et donc de n'en garder qu'un seul dans la relation résultante.

ExempleSoit la relation suivante :

Personne (Nom, Prénom, Age)

Soit les tuples suivants :



R = Projection (Personne, Nom, Age)


(Dupont, 20)(Durand, 30)

3. RestrictionRestrictionLa restriction est une opération unaire (c'est à dire portant sur une seule relation). La restriction de R1, étant donnéeune condition C, produit une relation R2 de même schéma que R1 et dont les tuples sont les tuples de R1 vérifiant lacondition C.

ExempleSoit la relation suivante :

Personne (Nom, Prénom, Age)

Soit les tuples suivants :



R = Restriction (Personne, Age>25)

On obtient alors la relation R composée de l'unique tuple restant suivant :

(Durand, Jean, 30)


4. ProduitProduit cartésienLe produit cartésien est une opération binaire (c'est à dire portant sur deux relations). Le produit de R1 par R2(équivalent au produit de R2 par R1) produit une relation R3 ayant pour schéma la juxtaposition de ceux desrelations R1 et R2 et pour tuples l'ensemble des combinaisons possibles entre les tuples de R1 et ceux de R2.

♦ Synonyme : Produit.

RemarqueLe nombre de tuples résultant du produit de R1 par R2 est égal au nombre de tuples de R1 multiplié par le nombrede tuples de R2.


Homme (Nom, Prénom, Age)Femme (Nom, Prénom, Age)



(Martin, Isabelle, 15)(Tintin, Hélène, 40)


R = Produit (Homme, Femme)


(Dupont, Pierre, 20, Martin, Isabelle, 15)(Durand, Jean, 30, Martin, Isabelle, 15)(Dupont, Pierre, 20, Tintin, Hélène, 40)(Durand, Jean, 30, Tintin, Hélène, 40)

5. JointureJointureLa jointure est une opération binaire (c'est à dire portant sur deux relations). La jointure de R1 et R2, étant donnéune condition C portant sur des attributs de R1 et de R2, de même domaine, produit une relation R3 ayant pourschéma la juxtaposition de ceux des relations R1 et R2 et pour tuples l'ensemble de ceux obtenus par concaténationdes tuples de R1 et de R2, et qui vérifient la condition C.


Homme (Nom, Prénom, Age)Enfant (Nom, Prénom, Age)



(Dupont, Georges, 1)(Dupont, Jacques, 3)


R = Jointure (Homme, Enfant, Homme.Nom=Enfant.Nom)


(Dupont, Pierre, 20, Dupont, Georges, 1)(Dupont, Pierre, 20, Dupont, Jacques, 3)

Remarque : Opération additionnelleLa jointure n'est pas une opération de base, elle peut être réécrite en combinant le produit et la restriction.

Relationnel 77

6. Jointure naturelleJointure naturelleLa jointure naturelle entre R1 et R2 est une jointure pour laquelle la condition est l'égalité entre les attributs demême nom de R1 et de R2. Il est donc inutile de spécifier la condition dans une jointure naturelle, elle reste toujoursimplicite.

ExempleSoit deux relations R1 (A, B, C) et R2 (A, D), l'opération Jointure(R1,R2,R1.A=R2.A) est équivalente à l'opérationJointureNaturelle(R1,R2).

RemarquePour appliquer une jointure naturelle, il faut que les deux relations opérandes aient au moins un attribut ayant lemême nom en commun.

7. Jointure externeLa jointure est une opération qui entraîne la perte de certains tuples : ceux qui appartiennent à une des deux relationsopérandes et qui n'ont pas de correspondance dans l'autre relation. Il est nécessaire dans certains cas de palier cette lacune, etl'on introduit pour cela la notion de jointure externe.

Jointure externeLa jointure externe entre R1 et R2 est une jointure qui produit une relation R3 à laquelle on ajoute les tuples de R1et de R2 exclus par la jointure, en complétant avec des valeurs nulles pour les attributs de l'autre relation.

Jointure externe gaucheLa jointure externe gauche entre R1 et R2 est une jointure externe pour laquelle on ajoute seulement les tuples deR1 (c'est à dire la relation de gauche) ayant été exclus.

♦ Synonyme : Jointure gauche.

Jointure externe droiteLa jointure externe droite entre R1 et R2 est une jointure externe pour laquelle on ajoute seulement les tuples de R2(c'est à dire la relation de droite) ayant été exclus.Bien entendu une jointure externe droite peut être réécrite par une jointure externe gauche (et réciproquement) ensubstituant les relations opérandes R1 et R2.

♦ Synonyme : Jointure droite.


Homme (Nom, Prénom, Age)Enfant (Nom, Prénom, Age)



(Dupont, Georges, 1)(Martin, Isabelle, 15)


R = JointureExterne (Homme, Enfant, Homme.Nom=Enfant.Nom)


(Dupont, Pierre, 20, Dupont, Georges, 1)(Durand, Jean, 30, Null, Null, Null)(Null, Null, Null, Martin, Isabelle, 15)

Une jointure externe gauche n'aurait renvoyé que les deux premiers tuples et une jointure externe droite n'auraitrenvoyée que le premier et le troisième tuple.


8. DivisionDivisionLa division est une opération binaire (c'est à dire portant sur deux relations). La division de R1 par R2, sachant queR1 et R2 ont au moins un attribut commun (c'est à dire de même nom et de même domaine), produit une relation R3qui comporte les attributs appartenant à R1 mais n'appartenant pas à R2 et l'ensemble des tuples qui concaténés àceux de R2 donnent toujours un tuple de R1.


Homme (Nom, Prénom, Métier)Métier (Metier)


(Dupont, Pierre, Ingénieur)(Dupont, Pierre, Professeur)(Durand, Jean, Ingénieur)

(Ingénieur)(Professeur)


R = Division (Homme, Métier)


(Dupont, Pierre)

Remarque : Réponse aux questions : Pour tous les ...La division permet de répondre aux questions du type : "Donnez toutes les personnes qui pratiquent tous les métiersde la relation métier".

Remarque : Opération additionnelleLa division n'est pas une opération de base, elle peut être réécrite en combinant le produit, la restriction et ladifférence.

9. Proposition de notationsIl existe plusieurs syntaxes pour écrire des opérations d'algèbre relationnelle, certaines inspirées de l'algèbre classiques,d'autres reposant sur des notations graphiques. Nous proposons une notation fonctionnelle qui a le mérite d'être facile à écrireet d'être lisible. Si cette notation peut parfois perdre en simplicité, lorsqu'elle concerne un nombre élevé d'opérateurs, il estpossible de décomposer une opération compliquée afin de l'alléger.Syntaxe

R = Union (R1, R2)R = Différence (R1, R2)R = Intersection (R1, R2)R = Projection (R1, A1, A2, ...)R = Restriction (R1, condition)R = Produit (R1, R2)R = Jointure (R1, R2, condition)R = JointureNaturelle (R1, R2)R = JointureExterne (R1, R2, condition)R = JointureGauche (R1, R2, condition)R = JointureDroite (R1, R2, condition)R = Division (R1, R2)

Exemple : Notation synthétiqueR = Projection( Restriction(R1, A1=1 AND A2=2), A3)

Exemple : Notation décomposéeR' = Restriction(R1, A1=1 AND A2=2)R = Projection (R', A3)

Exercice n°9. Opérateurs de base et additionnelsRéécrivez les opérateurs additionnels suivants, à partir d'opérateurs de base :

Question1Réécrivez Intersection à partir de Différence

Relationnel 79

Question2Réécrivez Jointure à partir de Produit et Restriction

Question3Réécrivez Division à partir de Produit, Restriction et Difference

Section B2. Pratique de l'algèbre relationnelle

Exercice n°10. Inviter ses amisUne maîtresse de maison s'est constitué une base de données sur les personnes (probables) qu'elle invite et les plats qu'elleleur sert. Cette base de données est composée de trois relations :♦ REPAS (date, invité) donne la liste des invités qui ont été reçus et à quelle date

♦ MENU (date, plat) donne le menu servi à chaque date

♦ PREFERENCE (personne, plat) donne pour chaque personne ses plats préférés

N.B. : les attibuts "personne" et "invité" ont même domaine.A l'aide de l'algèbre relationnelle exprimer les requêtes suivantes :

Question1Quels sont les invités du repas du 01/05/97 ?

Question2Quels sont les plats qui ont été servis à Alice ?

Question3Quels sont les invités qui lors d'un repas ont eu au moins un de leur plat préféré ?

Question4Quelles sont les personnes qui n'ont jamais été invitées ?

Question5Quels sont les invités qui sont venus à tous les repas ?

Exercice n°11. Faire du CinémaOn considère les deux relations suivantes :

LESFILMS (TITRE, PAYS,ANNEE, REALISATEUR, DUREE)LES ACTEURS (TITRE, ACTEUR)

où les attibuts ont les significations et les types suivants :♦ TITRE : titre d'un film (chaîne 50 caractères)

♦ PAYS : pays d'où un film est originaire (chaîne 10 caractères)

♦ ANNEE : année de sortie du film (entier 4 chiffres)

♦ REALISATEUR : nom du réalisateur du film (chaîne 20 caractères)

♦ DUREE : durée du film en minutes (entier 3 chiffres)

♦ ACTEUR : nom d'acteur (chaîne 20 caractères)

La relation LESFILMS donne pour chaque film, identifié par son titre, le pays, l'année de sortie, réalisateur et la durée.La relation LESACTEURS donne pour chaque film l'ensemble des principaux acteurs.A l'aide de l'algèbre relationnelle exprimer les requêtes suivantes :

Question1Lister les films français (titre, année, réalisateur).


Question2Donnez les années de sortie des fims où a joué GABIN.

Question3Trouver les acteurs qui ont tourné avec TRUFFAUT comme réalisateur.

Question4Trouver tous les acteurs qui ont été partenaires de DENEUVE.

Question5Lister les films dans lesquels le réalisateur est aussi acteur.

Question6Lister les réalisateurs n'ayant joué comme acteurs que dans des films qu'ils ne réalisaient pas eux-mêmes.

Question7Lister les réalisateurs ayant joué comme acteurs dans des fims qu'ils ne réalisaient pas eux-mêmes.

Question8Donnez les acteurs qui jouent dans tous les fims de TRUFFAUT.

Exercice récapitulatif II. Une usineUne usine cherche à modéliser sa production de véhicules et de moteurs :♦ Les véhicules sont identifiés par un numéro d'immatriculation alphanumérique et caractérisés par une couleur, dont la

dénomination est une chaîne de caractères. Chaque véhicule peut comporter un unique moteur et/ou un nombrequelconque de pneus.

♦ Chaque moteur est monté sur un et un seul véhicule et est identifié par le numéro d'immatriculation de celui-ci. Un moteurest caractérisé par une puissance, en chevaux.

♦ Tout pneu est monté sur un unique véhicule et est identifié localement par sa position sur ce véhicule (Dn pour les pneusde droite et Gn pour les pneus de gauche). Un pneu est caractérisé par un diamètre et une largeur en pouces.

♦ Les moteurs, les pneus et les véhicules sont fabriqués sous une marque. Les mêmes marques peuvent fabriquerindifféremment des moteurs, des pneus et/ou des véhicules, et un véhicule d'une certaine marque peut comporter unmoteur et/ou des pneus de marque différente.

Question1Réaliser le modèle E-A ou UML de ce problème en faisant apparaître les domaines et les clés candidates, ainsi queles éventuelles entités faibles.

Question2Réaliser le passage au modèle relationnel, en faisant apparaître les clés primaires et les clés étrangères.

Question3Ecrivez en algèbre relationnelle la question permettant de connaître les numéros d'immatriculation des voituresrouges sur lesquelles sont montées un moteur et au moins un pneu de même marque que la voiture.

Exercice récapitulatif II. Gestion d'une agence immobilièreEnoncé n°1Une agence immobilière cherche à créer une base de données pour la gestion des biens immobiliers mis à sa disposition etpour l’exploitation statistique et/ou fiscale des informations accumulées.

Relationnel 81

Pour chaque logement on possède plusieurs informations comme l'adresse, le nom du propriétaire, le type(maison/appartement), le nombre de pièces, la surface habitable, l’état de l’habitation (neuf, bon état, très bon état, àrénover), l’objectif de gestion (vente, location), le prix de mise en vente ou de location mensuelle, la date de disponibilité, laville, etc. Chaque propriété peut avoir un ou plusieurs garages. Ces derniers sont caractérisés par le type (box, emplacementnumérotés, etc.) et dans certain cas peuvent avoir des adresses différentes de celle de la propriété.Une personne, qui sera identifiée par son nom et son adresse, peut mettre en location ou en vente un de ses logements auprèsde l’agence.Un logement à vendre (resp. à louer) peut être acheté (resp. loué) par une personne. Pour chaque transaction de vente,l'agence touche une commission qui correspond à un pourcentage du prix de vente (qui est composé d’une valeur fixe àlaquelle on additionne entre 3 et 5% en fonction du montant de la transaction et des négociations particulière). Un logementvendu ou loué est rendu indisponible pour d’autres éventuels clients. Un locataire peut donner son préavis, l’agence signalantalors le logement disponible dans un délai de trois mois.L’agence organise et gère également les visites faites par ses clients (les acheteurs ou locataires potentiels).

Question1.1Reformuler l'énoncé du problème sous la forme de règles claires afin de poser les connaissances sous une formelittérale. Formuler des hypothèses, si nécessaire, pour compléter les informations manquantes.

Question1.2Réaliser le modèle Entité-Association du problème.

Repérer le domaine de valeur des propriétés. Repérer les clés. Repérer les entités de type faible. Répérer les attributsdérivés.

Question1.3Réaliser le modèle relationnel en appliquant les règles de passage E-A vers relationnel.

Indiquer les règles appliquées. Expliquer et détailler les cas particuliers.Utiliser la notation textuelle du modèle relationnel, du type : RELATION (PROP1, PROP2, PROPn). Souligner laclé primaire (les propriétés concernées seront en premier dans la liste). Les clés étrangères seront placées en dernierdans la liste, et l'on indiquera par un "=>" à quelle relation elles font références. Indiquer dans un tableau pourchaque propriété, son domaine de valeur et les contraintes supplémentaires qui la concerne (existentielle, parrapport à d'autres propriétés du tuple, etc.),

Enoncé n°2L'agence cherche à présent à interroger sa base de données, afin d'en exploiter les informations recueillies.Ecrire à l'aide de l'algèbre relationnelle les requêtes ci-après. On utilisera les notations suivantes :♦ R = Restriction(Relation, Condition)

♦ R = Projection(Relation, Propriété1, Propriété2, ...)

♦ R = Jointure(Relation1, Relation2, Condition)

♦ R = JointureExterne(Relation1, Relation2, Condition)

♦ R = JointureNaturelle(Relation1, Relation2)

♦ R = Union(Relation1, Relation2)

♦ R = Difference(Relation1, Relation2)

♦ R = Intersection(Relation1, Relation2)

♦ R = Produit(Relation1, Relation2)

Question2.1Pour constituer un fichier client complet, lister toutes les personnes.

Question2.2Pour relancer les anciens clients de l'agence, lister les noms et prénoms de tous les clients ayant effectué au moinsune location ou un achat.

Question2.3En vue d'une enquête de satisfaction et de suivi par courrier, lister les noms et adresses des propriétaires ayant louédes logements à Lyon avant l'année 2000.

Question2.4En vue d'optimiser l'organisation du personnel et de préparer le passage aux 35 heures pour l'antenne deCompiègne, lister les jours pendant lesquels il y a eu au moins une visite pour des logements à Compiègne.


Question2.5Pour répondre à une demande particulière d'un client exigeant, chercher, si cela existe, à quelles adresses on peuttrouver des F6 neufs, disponibles avant le 31 novembre 2002, de plus de 150m2, avec garage à la même adresse, ruede la Paix à Paris.

Question2.6Pour mettre en valeur l'activité de l'agence lors d'un conseil d'administration, préparer la liste de toutes lescommissions réalisées pour des ventes supérieures à 500.000 euros.

Question2.7Pour convaincre un propriétaire d'accepter une proposition d'achat inférieure à son prix de mise en vente, listertoutes les transactions (date, montant, prix de vente, nom du client et nom du propriétaire) pour lesquelles lemontant de vente est inférieur de plus de 10% au prix de mise en vente.

Question2.8Pour vérifier si quelques solutions idéales ne sont pas latentes, chercher les clients toujours en recherche (i.e.n'ayant jamais effectué de transaction) et habitant à une adresse à laquelle se trouve un logement disponible.

Question2.9Pour leur faire des offres particulières, chercher les personnes qui sont à la fois clients et propriétaires.

Question2.10Pour occuper votre temps pendant l'inactivité chronique du mois d'août, chercher les rues qui se retrouvent danstoutes les villes.

En résumé...

Schéma relationnelUn schéma relationnel permet uneformalisation d'un modèle logique.

Relation ou tableSous-ensemble d'un produit cartésien

Clé

Attribut oucolonne

Prend ses valeurs dansun domaine

Enregistrementou ligne

Pose une valeur (ycompris la valeur "null"

pour chaque attribut

Clé primaireIndentifie de façon

unique unenregistrement

Clé étrangèreRéférence la clé

primaire d'un tupled'une autre relation

Relationnel 83

Cours

IIISQL LMD

SQL est un langage standardisé, implémenté par tous les SGBDR, qui permet, indépendemment de la plate-formetechnologique et de façon déclarative, de définir le modèle de données, de le contrôler et enfin de le manipuler.Ce chapitre traite du LMD de SQL, c'est à dire de la partie de ce langage, fondé sur l'algèbre relationnelle, qui permetd'interroger les données stockées en BD.

Partie A. Manipulation de données

Objectifs pédagogiquesMaîtriser les bases du SQL pour écrire des questions exigeant des jointures, projections, restriction, des tris et desagrégats.Etre capable d'apprendre des notions particulières de SQL liés à un SGBD en particulier ou à des évolutions futures deSQL.

Qu'appelle-t-on SQL?

[Copyright 2003 Jean-François Pillou - Ce document issu de CommentCaMarche.net est soumis à la licence GNU FDL] SQL(pour langage de requêtes structuré) est un langage de définition de données (LDD, ou en anglais DDL Data DefinitionLanguage), un langage de manipulation de données (LMD, ou en anglais DML, Data Manipulation Language), et un langagede contrôle de données (LCD, ou en anglais DCL, Data Control Language), pour les bases de données relationnelles.Le modèle relationnel a été inventé par E.F. Codd (Directeur de recherche du centre IBM de San José) en 1970, suite à quoide nombreux langages ont fait leur apparition :♦ IBM Sequel (Structured English Query Language) en 1977

♦ IBM Sequel/2

♦ IBM System/R

♦ IBM DB2

Ce sont ces langages qui ont donné naissance au standard SQL, normalisé en 1986 par l'ANSI pour donner SQL/86. Puis en1989 la version SQL/89 a été approuvée. La norme SQL/92 a désormais pour nom SQL 2.

Remarque : SQL est un langage de définition de donnéesSQL est un langage de définition de données (LDD), c'est-à-dire qu'il permet de créer des tables dans une base dedonnées relationnelle, ainsi que d'en modifier ou en supprimer.

Remarque : SQL est un langage de manipulation de donnéesSQL est un langage de manipulation de données (LMD), cela signifie qu'il permet de sélectionner, insérer, modifierou supprimer des données dans une table d'une base de données relationnelle.

Remarque : SQL est un langage de protections d'accèsIl est possible avec SQL de définir des permissions au niveau des utilisateurs d'une base de données. On parle deDCL (Data Control Language).

Section A1. Le LMD de SQL

1. SélectionLa requête de sélection ou question est la base de la recherche de données en SQL.

SélectionLa selection est la composition d'un produit cartésien, d'une restriction et d'une projection (ou encore la compositiond'une jointure et d'une projection).

SyntaxeSELECT <liste d'attributs projetés>FROM <liste de relations>WHERE <condition>

La partie SELECT indique le sous-ensemble des attributs qui doivent apparaître dans la réponse (c'est le schéma de larelation résultat).La partie FROM décrit les relations qui sont utilisables dans la requête (c'est à dire l'ensemble des attributs que l'on peututiliser).La partie WHERE exprime les conditions que doivent respecter les attributs d'un tuple pour pouvoir être dans la réponse.Une condition est un prédicat et par conséquent renvoie un booléen. Cette partie est optionnelle.Afin de décrire un attribut d'une relation dans le cas d'une requête portant sur plusieurs relations, on utilise la notation"RELATION.ATTRIBUT".

ExempleSELECT Nom, PrenomFROM PersonneWHERE Age>18

Cette requête sélectionne les attributs Nom et Prenom des tuples de la relation Personne, ayant un attribut Agesupérieur à 18.

ExempleSELECT Parent.Prenom, Enfant.PrenomFROM Parent, EnfantWHERE Enfant.Nom=Parent.Nom

Cette requête sélectionne les prénoms des enfants et des parents ayant le même nom. On remarque la notationParent.Nom et Enfant.Nom pour distinguer les attributs Prenom des relations Parent et Enfant.On notera que cette sélection effectue une jointure sur les propriétés Nom des relations Parent et Enfant.

Remarque : SELECT *Pour projeter l'ensemble des attributs d'une relation, on peut utiliser le caractère "*" à la place de la liste desattributs à projeter.

ExempleSELECT *FROM Avion

Cette requête sélectionne tous les attributs de la relation Avion.Notons que dans cet exemple, la relation résultat est exactement la relation Avion

Remarque : SELECT DISTINCTL'opérateur SELECT n'élimine pas les doublons (i.e. les tuples identiques dans la relation résultat) par défaut. Il fautpour cela utiliser l'opérateur "SELECT DISTINCT".

ExempleSELECT DISTINCT AvionFROM VolWHERE Date=31-12-2000

Cette requête sélectionne l'attribut Avion de la relation Vol, concernant uniquement les vols du 31 décembre 2000et renvoie les tuples dans doublons.

Remarque : Renommage de propriétéIl est possible de redéfinir le nom des propriétés de la relation résultat. Ainsi "SELECT p AS p' FROM relation"renvoie une relation ayant comme propriété p'. Cette possibilité est offerte à partir de SQL2 (niveau entrée).


Remarque : Projection de constanteIl est possible de projeter directement des constantes. Ainsi "SELECT 'Bonjour' AS Essai" renverra un tuple avecune propriété Essai à la valeur 'Bonjour'.

2. Opérateurs de comparaisons et opérateurs logiquesLa clause WHERE d'une instruction de sélection est définie par une condition. Une telle condition s'exprime à l'aided'opérateurs de comparaison et d'opérateurs logiques. Le résultat d'une expression de condition est toujours un booléen.

ConditionCondition Elémentaire ::= Propriété <Opérateur de comparaison> ConstanteCondition ::= Condition <Opérateur logique> Condition | Condition Elémentaire

Les opérateurs de comparaison sont :♦ P = C

♦ P <> C

♦ P < C

♦ P > C

♦ P <= C

♦ P >= C

♦ P BETWEEN C1 AND C2

♦ P LIKE 'chaîne'

♦ P IN (C1, C2, ...)

♦ P IS NULL

Les opérateur logique sont :♦ OR

♦ AND

♦ NOT

3. Expression du produit cartésienSyntaxe

SELECT *FROM R1, R2, Ri

4. Expression d'une projectionSyntaxe

SELECT P1, P2, PiFROM R

5. Expression d'une restrictionSyntaxe

SELECT *FROM RWHERE <condition>

6. Expression d'une jointureSyntaxe : Jointure par la clause WHEREEn tant que composition d'un produit cartésien et d'une restriction la jointure s'écrit alors :

SELECT *FROM R1, R2, RiWHERE <condition>

Avec Condition permettant de joindre des attributs des Ri

SQL LMD 87

Syntaxe : Jointure par la clause ONOn peut également utiliser la syntaxe dédiée suivante :

SELECT *FROM R1 INNER JOIN R2ON <condition>

Et pour plusieurs relations :

SELECT *FROM (R1 INNER JOIN R2 ON <condition>) INNER JOIN Ri ON <condition>

Exemple : Une jointure naturelleSELECT *FROM R1, R2WHERE R2.NUM = R1.NUM

Remarque : Auto-jointurePour réaliser une auto-jointure, c'est à dire la jointure d'une relation avec elle-même, on doit utiliser le renommagedes relations. Pour renommer une relation, on note dans la clause FROM le nom de rennomage après le nom de larelation : "FROM NOM_ORIGINAL NOUVEAU_NOM".

Exemple : Auto-jointureSELECT E1.NomFROM Employe E1, Employe E2WHERE E1.Nom= E2.Nom

Remarque : Jointure externe gauche ou droitePour exprimer une jointure externe on se base sur la syntaxe INNER JOIN en utilisant à la place LEFT OUTERJOIN ou RIGHT OUTER JOIN.

Exemple : Jointure externe gaucheSELECT NumFROM Avion LEFT OUTER JOIN VolON Avion.Num=Vol.Num

Cette requête permet de sélectionner tous les avions, y compris ceux non affectés à un vol.

RemarqueRemarquons que "Avion LEFT OUTER JOIN Vol" est équivalent à "Vol RIGHT OUTER JOIN Avion" en termede résultat.Intuitivement, on préfère utiliser la jointure gauche pour sélectionner tous les tuple du côté N d'une relation 1:N,même si il ne sont pas référencés ; et la jointure droite pour pour sélectionner tous les tuples d'une relation 0:N, ycompris ceux qui ne font pas de référence. Cette approche revient à toujours garder à gauche de l'expression "JOIN"la relation "principale", i.e. celle dont on veut tous les tuples, même s'ils ne référencent pas (ou ne sont pasréférencés par) la relation "secondaire".

7. Opérateurs ensemblistesLes opérateurs ensemblistes ne peuvent être exprimés à l'aide de l'instruction de sélection seule.Syntaxe : Union

SELECT * FROM R1UNIONSELECT * FROM R2

Syntaxe : IntersectionSELECT * FROM R1INTERSECTSELECT * FROM R2

Syntaxe : DifférenceSELECT * FROM R1EXCEPTSELECT * FROM R2

RemarqueLes opérations INTERSECT et EXCEPT n'existe que dans la norme SQL2, et non dans la norme SQL1. CertainSGBD sont susceptibles de ne pas les implémenter.


8. TriOn veut souvent que le résultat d'une requête soit trié en fonction des valeurs des propriétés des tuples de ce résultat.Syntaxe : ORDER BY

SELECT <liste d'attributs projetés>FROM <liste de relations>WHERE <condition>ORDER BY <liste ordonnée d'attributs>

Les tuples sont triés d'abord par le premier attribut spécifié dans la clause ORDER BY, puis en cas de doublons par lesecond, etc.

Remarque : Tri décroissantPour effectuer un tri décroissant on fait suivre l'attribut du mot clé "DESC".

ExempleSELECT *FROM PersonneORDER BY Nom, Age DESC

9. Fonctions de calculFonction de calculUne fonction de calcul s'applique à l'ensemble des valeurs d'une propriété d'une relation avec pour résultat laproduction d'une valeur atomique unique (entier, chaîne, date, etc).Les cinq fonctions prédéfinies sont :♦ Count(Relation.Propriété)

Renvoie le nombre de valeurs non nulles d'une propriété pour tous les tuples d'une relation ;

♦ Sum(Relation.Propriété)

Renvoie la somme des valeurs d'une propriété des tuples (numériques) d'une relation ;

♦ Avg(Relation.Propriété)

Renvoie la moyenne des valeurs d'une propriété des tuples (numériques) d'une relation ;

♦ Min(Relation.Propriété)

Renvoie la plus petite valeur d'une propriété parmi les tuples d'une relation .

♦ Max(Relation.Propriété)

Renvoie la plus grande valeur d'une propriété parmi les tuples d'une relation.

SyntaxeSELECT <liste de fonctions de calcul>FROM <liste de relations>WHERE <condition à appliquer avant calcul>

ExempleSELECT Min(Age), Max(Age), Avg(Age)FROM PersonneWHERE Qualification='Ingénieur'

Remarque : Utilisation de fonctions pour les agrégatsDans le cas du calcul d'un agrégat, les fonctions peuvent être utilisées dans la claude HAVING ou dans la clauseORDER BY d'un tri. Les fonctions ne peuvent pas être utilisées dans la clause WHERE.

Remarque : Comptage d'une relationPour effectuer un comptage sur tous les tuples d'une relation, appliquer la fonction Count à un attribut de la cléprimaire. En effet cet attribut étant non nul par définition, il assure que tous les tuples seront comptés.

10. AgrégatsAgrégatUn agrégat est un partitionnement horizontal d'une table en sous-tables, en fonction des valeurs d'un ou plusieursattributs de partitionnement, suivi de l'application d'une fonction de calcul à chaque attribut des sous-tablesobtenues (Gardarin, 1999).

SQL LMD 89

SyntaxeSELECT <liste d'attributs de partionnement à projeter et de fonctions de calcul>FROM <liste de relations>WHERE <condition à appliquer avant calcul de l'agrégat>GROUP BY <liste ordonnée d'attributs de partitionnement>HAVING <condition sur les fonctions de calcul>

ExempleSELECT Societe.Nom, AVG(Personne.Age)FROM Personne, SocieteWHERE Personne.NomSoc = Societe.NomGROUP BY Societe.NomHAVING Count(Personne.NumSS) > 10

Cette requête calcul l'âge moyen du personnel pour chaque société comportant plus de 10 salariés.

Remarque : RestrictionUne restriction peut être appliquée avant calcul de l'agrégat, au niveau de la clause WHERE, portant ainsi sur larelation de départ, mais aussi après calcul de l'agrégat sur les résultats de ce dernier, au niveau de la clauseHAVING.

Remarque : ProjectionSi dans la clause SELECT, un attribut est projeté directement, sans qu'une fonction lui soit appliquée, alors il fautimpérativement que cet attribut apparaisse dans la clause GROUP BY (car ce ne peut être qu'un attribut departionnement).

Remarque : Fonctions de calcul sans partitionnementSi une ou plusieurs fonctions de calcul sont appliquées sans partionnement, le résultat de la requête est un tupleunique.

Remarque : Intérêt de la clause GROUP BYPour que l'utilisation de la clause GROUP BY ait un sens, il faut qu'au moins une fonction de calcul soit utilisée,soit dans la clause SELECT, soit dans la clause HAVING.

Remarque : Contrôle imposé par quelques SGBDRNotons que dans le cas de certains SGBDR (par exemple Oracle), l'ensemble des attributs de l'agrégation (clauseGROUP BY) doivent être préalablement projetés (donc déclarés dans la clause SELECT).

11. Requêtes imbriquéesIl est possible d'imbriquer des requêtes les unes dans les autres pour procéduraliser les questions, et ainsi répondre à desquestions plus complexes, voire impossibles, à écrire en algèbre relationnel classique.

Sous-requêteRequête incluse dans la clause WHERE d'une autre requête.

♦ Synonymes : Sous-question, Requête imbriquée.

SyntaxeSELECT <projections>FROM <relations>WHERE <sous-requête>

ExempleSELECT NomFROM ChercheurWHERE Nom IN

(SELECT Nom FROM Enseignant)

12. Sous-requête d'existence INCette sous-requête permet de vérifier que la projection d'un tuple de la requête principale est présent dans la sous-requête.Syntaxe

SELECT <projections>FROM <relations>WHERE (<projection d'un tuple>) IN

(<requête imbriquée>)

La projection du tuple de la requête principale doit conduire à un schéma relationnel identique à celui de la requêteimbriquée.


Exemple : Sous-requête IN à une colonne et plusieurs lignesSELECT Chercheur.NomFROM ChercheurWHERE Chercheur.Universite IN

(SELECT Universite.NomFROM UniversiteWHERE Universite.Ville='Paris')

Exemple : Sous-requête IN à plusieurs colonnes et plusieurs lignesSELECT N°SSFROM ChercheurWHERE (Nom, Prenom, Age) IN

(SELECT Nom, Prenom, AgeFROM Enseignant)

Exemple : Imbrication multiple de requêtesSELECT NomFROM ChercheurWHERE Universite='Paris6' AND Nom IN

(SELECT NomFROM EnseignantWHERE Universite IN

(SELECT NomFROM UniversiteWHERE Ville='Paris'))

Remarque : Jointure par la sous-requête INLa sous-requête IN est une troisième voie, avec les clauses WHERE et JOIN, pour réaliser des jointures entrerelations. On préfèrera néanmoins éviter d'utiliser à cette unique fin cette version plus procédurale.

Remarque : NOT INOn peut tester la non existence du tuple dans la sous requête en utilisant la clause NOT IN à la place de la clause IN.

13. Sous-requête d'existence EXISTSCette sous-requête permet de vérifier que la sous-requête contient au moins un tuple.Syntaxe

SELECT <projections>FROM <relations>WHERE EXISTS


La requête imbriquée faisant référence à des propriétés (éventuellement non projetées) de la requête principale.

ExempleSELECT Chercheur.NomFROM ChercheurWHERE EXISTS

(SELECT *FROM UniversiteWHERE Universite.Nom=Chercheur.Universite)

Remarque : Projection dans la sous-requêtePuisque la sous-requête n'est destinée qu'à valider l'existence d'un tuple, il est inutile de procéder à une projectionparticulière pour cette sous-requête. On utilise donc en général la clause SELECT * pour une sous-requête avec uneclause EXISTS.

Remarque : NOT EXISTSOn peut tester la non présence de tuple dans la sous-requête en utilisant la clause NOT EXISTS à la place de laclause EXISTS.

14. Sous-requête de comparaison ALLCette sous-requête permet de vérifier que les tuples de la requête principale vérifient bien une condition donnée avec tous lestuples de la sous-requête.Syntaxe

SELECT <projections>FROM <relations>WHERE <propriété> <opérateur de comparaison> ALL


La requête imbriquée renvoyant un tuple ne comportant qu'une propriété de même domaine que la propriété testée de larequête principale.

SQL LMD 91

ExempleSELECT NomFROM ChercheurWHERE Age > ALL

(SELECT AgeFROM Etudiant)

15. Sous-requête de comparaison ANYCette sous-requête permet de vérifier que les tuples de la requête principale vérifie bien une condition donnée avec au moinsun tuple de la sous-requête.Syntaxe

SELECT <projections>FROM <relations>WHERE <propriété> <opérateur de comparaison> ANY


La requête imbriquée renvoyant un tuple ne comportant qu'une propriété de même domaine que la propriété testée de larequête principale.

ExempleSELECT NomFROM ChercheurWHERE Age < ANY

(SELECT AgeFROM Etudiant)

Remarque : SOMESOME peut être utilisé comme un synonyme de ANY.

16. Insertion de donnéesLe langage SQL fournit également des instructions pour ajouter des nouveaux tuples à une relation. Il offre ainsi uneinterface standard également pour ajouter des information dans une base de données.Il existe deux moyens d'ajouter des données, soit par fourniture directe des valeurs des propriétés du tuple à ajouter, soit parsélection des tuples à ajouter dans une autre relation.

Syntaxe : Insertion directe de valeursINSERT INTO <Nom de la relation> (<Liste ordonnée des propriétés à valoriser>)VALUES (<Liste ordonnée des valeurs à affecter aux propriétés spéficiées ci-dessus>)

Exemple : Insertion directe de valeursINSERT INTO Virement (Date, Montant, Objet)VALUES (14-07-1975, 1000, 'Prime de naissance')

Syntaxe : Insertion de valeurs par l'intermédiaire d'une sélectionINSERT INTO <Nom de la relation>, (<Liste ordonnée des propriétés à valoriser>)SELECT ...

L'instruction SELECT projetant un nombre de propriétés identiques aux propriétés à valoriser.

Exemple : Insertion de valeurs par l'intermédiaire d'une sélectionINSERT INTO Credit (Date, Montant, Objet)SELECT Date, Montant, 'Annulation de débit'FROM DebitWHERE Debit.Date = 25-12-2001

Dans cet exemple tous les débits effectués le 25 décembre 2001, sont recrédités pour le même montant (et à lamême date), avec la mention annulation dans l'objet du crédit. Ceci pourrait typiquement réalisé en cas de débitserrronés ce jour là.

RemarqueLes propriétés non valorisées sont affectées à la valeur null.

Il est possible de ne pas spécifier les propriétés à valoriser, dans ce cas, toutes les propriétés de la relation serontconsidérées, dans leur ordre de définition dans la relation (à n'utiliser que dans les cas les plus simples).

17. Mise à jour de donnéesLe langage SQL fournit une instruction pour modifier des tuples existants dans une relation.


Syntaxe : Mise à jour directe de valeursUPDATE <Nom de la relation>SET <Liste d'affectation Propriété=Valeur>WHERE <Condition pour filtrer les tuples à mettre à jour>

Exemple : Mise à jour directe de valeursUPDATE CompteSET Monnaie='Euro'WHERE Monnaie='Franc'

Exemple : Mise à jour par calcul sur l'ancienne valeurUPDATE CompteSET Total=Total * 6,55957WHERE Monnaie='Euro'

18. Suppression de donnéesLe langage SQL fournit une instruction pour supprimer des tuples existants dans une relation.Syntaxe

DELETE FROM <Nom de la relation>WHERE <Condition pour filtrer les tuples à supprimer>

Exemple : Suppression de tous les tuples d'une relationDELETE FROM FaussesFactures

Exemple : Suppression sélectiveDELETE FROM FaussesFacturesWHERE Auteur='Moi'

Section A2. Pratique du LMD SQL

Exercice n°12. Représentation de représentantsSoit le schéma relationnel suivant :

REPRESENTANTS (NR, NOMR, VILLE)PRODUITS (NP, NOMP, COUL, PDS)CLIENTS (NC, NOMC, VILLE)VENTES (NR, NP, NC, QT)

Ecrire en SQL les requêtes permettant d'obtenir les informations suivantes.

Question1Tous les détails de tous les clients.

Question2Les numéros et les noms des produits de couleur rouge et de poids supérieur à 100.

Question3Les différents représentants ayant vendu au moins un produit.

Question4Les noms des clients de Lyon ayant acheté un produit pour une quantité supérieure à 180.

Question5Les noms des représentants et des clients à qui ces représentants ont vendu un produit de couleur rouge pour unequantité supérieure à 100.

Question6Le nombre de clients.

SQL LMD 93

Question7Le nombre de produits de couleur rouge.

Question8Le nombre de clients par ville.

Question9La quantité totale des produits rouge vendus par chaque représentant.

Question10La quantité totale des produits rouge par chaque représentant ayant vendu plus de 10 produits rouges.

Question11Les noms des vendeurs qui n'ont jamais rien vendu.

Question12Les numéros de tous les produits tel qu'ils n'en existe aucun autre ayant un poids plus faible.

Question13Les noms des représentants ayant vendu quelque chose à tous les clients.

Question14Les noms des représentants ayant vendu quelque chose aux clients NC1 et NC2.

Question15Les numéros des produits vendus à un client par un représentant issu de la même ville.

Question16Les numéros des produits vendus à un client de Lyon par un représentant de Lyon.

Question17Les numéros des clients ayant acheté quelque chose à au moins un représentant issu de la même ville.

Question18Les numéros des clients qui n'ont rien acheté d'un représentant de Lyon.

Question19Les couples des représentants et le nom de la ville dans laquelle le premier a vendu plus que le second.

Exercice n°13. Gestion du personnelSoit le schéma relationnel :

Employe (Num, Nom, Prenom, Age, Salaire, Fonction=>Fonction, Societe=>Societe)Fonction (Intitule, SalaireMin, SalaireMax, NbHeures)Societe (Nom, Pays, Activite)

Question1Ecrivez une requête SQL permettant de sélectionner les noms de tous les directeurs de France.

Question2Ecrivez une requête SQL permettant de vérifier que les salaires de chaque employé correspond bien à ce qui estautorisé par leur fonction.

Question3Ecrivez une requête SQL permettant de licencier tous les employés qui travaillent en Allemagne.


Question4Ecrivez une requête SQL permettant le passage aux 35 heures, en modifiant le nombre d'heures travaillées pourchaque fonction, et en réajustant les échelles de salaire au pro-rata du nombre d'heures travaillées avant le passageaux 35 heures.

Question5Ecrivez une requête SQL permettant de calculer le nombre d'employés dans chaque société. Les sociétés présentantle plus grand nombre d'employés seront présentées en premier.

Exercice récapitulatif IV. GauloiseriesUn vieux druide perdant la mémoire souhaite réaliser une base de données pour se souvenir de la composition de ses potions.Un de ses apprentis ayant suivi un cours sur les bases de données lors de son initiation druidique, il réalise le schémaconceptuel suivant :

IMG. 32 : MODÈLE UML

Question1Réaliser le modèle logique correspondant en relationnel, en faisant apparaître les clés primaires et étrangères.

Question2Ecrivez une requête SQL permettant de préparer l'implémentation de la méthode NbIngrédients. Cette requête devrarenvoyer le nombre d'ingrédients pour chaque potion. La méthode n'est bien entendu pas à écrire.

Question3Ecrivez une requête SQL permettant de trouver la recette de la potion magique.

Question4Ecrivez une requête SQL permettant de trouver les ingrédients utilisés par aucune potion.

Question5Critiquer le schéma conceptuel de l'apprenti : Est-ce qu'un même ingrédient peut apparaître deux fois dans la mêmepotion ? Peut-on gérer la quantité d'ingrédients pour chaque potion ? Proposer une solution et redessiner le schémaconceptuel en Entité-Association, en y intégrant votre amélioration.

Exercice récapitulatif IV. Jeanne et SergeVous avez en charge la réalisation d'une base de données pour gérer un tournoi de Volley-Ball. Les équipes, identifiées parun nom, sont composées de deux à six joueurs idéntifiés par leur prénom (étant donnée l'équipe à laquelle ils appartiennent).Un match oppose deux équipes, à une date donnée, dont une est gagnante, et sont joués en deux sets gagnants (le score estdonc toujours de 2 pour le gagnant et 0 ou 1 pour le perdant, on décide donc de ne gérer que le score du perdant). On noteraque deux équipes se rencontrent au plus une fois.

Question1Réaliser le modèle conceptuel de la BD en utilisant le formalisme E-A. Enoncer les éventuelles contraintes nonreprésentables en E-A.

Question2Traduire le MCD en modèle logique relationnel. Enoncer les éventuelles contraintes non représentables enrelationnel.

SQL LMD 95

Question3Proposer une implémentation SQL du modèle relationnel, en intégrant le maximum de contraintes. Enoncer leséventuelles contraintes non représentables en SQL.

Question4Ecrivez en algèbre relationnel l'expression permettant de sélectionner les équipes ayant gagné au moins un match etperdu au moins un match.

Question5Ecrire une requête SQL permettant de lister toutes les équipes ayant gagné un match, avec leur nombre de points(un match gagné valant 2 points et un match perdu 0 point), triées par leur nombre de points (avec l'équipe ayant leplus de points en premier).


Cours

IVNormalisation, SQL

LDD et LCD

La théorie de la normalisation relationnelle est très importante pour la conception de BD, dans la mesure où elle donne lecadre théorique pour la gestion de la redondance, et dans la mesure où une bonne maîtrise de la redondance est un aspectmajeur de cette conception.Après avoir expliqué la théorie de la normalisation et donné les outils méthodologiques pour la gestion de la redondance, cechapitre terminera la description du langage SQL par la description des instructions des langages LDD et LCD, quicomposent avec le LMD les trois parties du langage SQL.

Partie A. La normalisation

Objectifs pédagogiquesComprendre la problématique de la redondance et des dépendances fonctionnelles.Savoir créer des schémas relationnels en troisième forme normale.

Section A1. Théorie de la normalisation relationnelle

Exercice n°14. RedondanceSoit la relation R suivante, définie en extension :

A B C D E F G

0 1 1 10 5 X A

0 2 1 10 9 X G

0 1 2 10 6 X S

0 1 3 10 7 X D

1 2 3 20 7 Y D

0 3 3 10 9 X G

1 4 3 20 8 Y F

1 1 4 20 9 Y G

TAB. 13 : RELATION R

Question1Proposez une clé primaire pour cette relation. Justifiez brièvement.

Question2Cette relation contient-elle des redondances ? Si oui lesquelles ? Justifiez brièvement.

Question3Si la relation contient des redondances, proposez une solution contenant exactement la même information, maissans redondance.

1. Les problèmes soulevés par une mauvaise modélisationAttentionIl y a toujours plusieurs façons de modéliser conceptuellement un problème, certaines sont bonnes et d'autresmauvaises. C'est l'expertise de l'ingénieur en charge de la modélisation, à travers son expérience accumulée et sacapacité à traduire le problème posé, qui permet d'obtenir de bons modèles conceptuels.

S'il est difficile de définir un bon modèle conceptuel, on peut par contre poser qu'un bon modèle logique relationnel est unmodèle où la redondance est contrôlée. On peut alors poser qu'un bon modèle conceptuel est un modèle conceptuel quiconduit à un bon modèle relationnel, après application des règles de passage E-A ou UML vers relationnel. Mais on ne saitpas pour autant le critiquer avant ce passage, autrement qu'à travers l'oeil d'un expert.A défaut de disposer d'outils systématiques pour obtenir de bons modèles conceptuels, on cherche donc à critiquer lesmodèles relationnels obtenus. La théorie de la normalisation est une théorie qui permet de critiquer, puis d'optimiser, desmodèles relationnels, de façon à en contrôler la redondance.

Exemple : Un mauvais modèle relationnelImaginons que nous souhaitions représenter des personnes, identifiées par leur numéro de sécurité sociale,caractérisées par leur nom, leur prénom, ainsi que les véhicule qu'elles ont acheté, pour un certain prix et à unecertaine date, sachant qu'un véhicule est caractérisé par un type, une marque et une puissance. On peut aboutir à lareprésentation relationnelle suivante :

Personne(NSS, Nom, Prénom, Marque, Type, Puiss, Date, Prix)

Imaginons que cette relation soit remplie par les données suivantes :

NSS Nom Prénom Marque Type Puiss Date Prix

16607... Dupont Paul Renault Clio 5 1/1/96 60000

16607... Dupont Paul Peugeot 504 7 2/7/75 47300

24908... Martin Marie Peugeot 504 7 1/10/89 54900

15405... Durand Olivier Peugeot 504 7 8/8/90 12000

15405... Durand Olivier Renault Clio 5 7/6/98 65000

15405... Durand Olivier BMW 520 10 4/5/2001 98000

TAB. 14 : RELATION PERSONNE

On peut alors se rendre compte que des redondances sont présentes, et l'on sait que ces redondances conduiront àdes problèmes de contrôle de la cohérence de l'information (erreur dans la saisie d'un numéro de sécurité sociale),de mise à jour (changement de nom à reporter dans de multiples tuples), de perte d'information lors de lasuppression de données (disparition des informations concernant un type de véhicule) et de difficulté à représentercertaines informations (un type de véhicule sans propriétaire).

DELMAL P, "SQL2 SQL3, applications à Oracle", De Boeck Université, 2001.

On conseillera de lire le chapitre 2 (pages 42 à 49) qui propose une très bonne démonstration par l'exemple desproblèmes posés par une mauvaise modélisation relationnelle.

2. Principes de la normalisation

La théorie de la normalisation est une théorie destinée à concevoir un bon schéma d’une BD sans redondanced’information et sans risques d'anomalie de mise à jour. Elle a été introduite dès l'origine dans le modèle relationnel(Codd, "A relational model for large shared data banks", "Communications de l'ACM", juin-1970, n°.6, pp.377-387) .


La théorie de la normalisation est fondée sur deux concepts principaux :♦ Les dépendances fonctionnelles

Elles traduisent des contraintes sur les données.

♦ Les formes normales

Elles définissent des relations bien conçues.

La mise en oeuvre de la normalisation est fondée sur la décomposition progressive des relations jusqu'à obtenir des relationsnormalisées.

3. Dépendance fonctionnelleDépendance fonctionnelleSoient R(A1, A2, ... , An) un schéma de relation, X et Y des sous-ensembles de A1, A2, ... , An. On dit que Xdétermine Y, ou que Y dépend fonctionnellement de X, si est seulement s'il existe une fonction qui à partir de toutevaleur de X détermine une valeur unique de Y.Plus formellement on pose que X détermine Y pour une relation R ssi quelle que soit l'instance r de R, alors pourtous tuples t1 et t2 de r on a :Projection (t1,X) = Projection (t2,X) ⇒ Projection (t1,Y) = Projection (t2,Y)

SyntaxeSi X détermine Y, on note : X→ Y

ExempleSoit la relation R suivante :

Personne(NSS, Nom, Prénom, Marque, Type, Puiss, Date, Prix)

On peut poser les exemples de DF [Dépendance Fonctionnelle] suivants :♦ NSS→ Nom

♦ NSS→ Prénom

♦ Type→ Marque

♦ Type→ Puiss

♦ (NSS, Type, Date)→ Prix

♦ etc.

Remarque : Comment trouver les DF ?Une DF est définie sur l'intention du schéma et non son extension. Une DF traduit une certaine perception de laréalité. Ainsi la DF (NSS, Type, Date)→ Prix signifie que personne n'achète deux voitures du même type à la mêmedate.La seule manière de déterminer une DF est donc de regarder soigneusement ce que signifient les attributs et detrouver les contraintes qui les lient dans le monde réel.

Remarque : Pourquoi trouver les DF ?Les DF font partie du schéma d'une BD, en conséquence, elles doivent être déclarées par les administrateurs de laBD et être contrôlées par le SGBD.De plus l'identification des DF est la base indispensable pour déterminer dans quelle forme normale est une relationet comment en diminuer la redondance.

4. Les axiomes d'ArmstrongLes DF obéissent à des propriétés mathématiques particulières, dites axiomes d'Armstrong.

RéflexivitéTout groupe d'attributs se détermine lui même et détermine chacun de ses attributs (ou sous groupe de ses attributs).

Soient X et Y des attributs :XY→ XY et XY→ X et XY→ Y

AugmentationSi un attribut X détermine un attribut Y, alors tout groupe composé de X enrichi avec d'autres attributs détermine ungroupe composé de Y et enrichi des mêmes autres attributs.Soient X, Y et Z des attributs :X→ Y ⇒ XZ→ YZ

Normalisation, SQL LDD et LCD 99

TransitivitéSi un attribut X détermine un attribut Y et que cet attribut Y détermine un autre attribut Z, alors X détermine Z.

Soient X, Y et Z des attributs :X→ Y et Y→ Z ⇒ X→ Z

5. Autres propriétés déduites des axiomes d'ArmstrongA partir des axiomes d'Amstrong, on peut déduire un certain nombre de propriétés supplémentaires.

Pseudo-transitivitéSi un attribut X détermine un autre attribut Y, et que Y appartient à un groupe G qui détermine un troisième attributZ, alors le groupe G' obtenu en substituant Y par X dans G détermine également Z.Soient, W, X, Y et Z des attributs :X→ Y et WY→ Z ⇒ WX→ ZCette propriété est déduite de l'augmentation et de la réflexivité :X→ Y et WY→ Z ⇒ WX→ WY et WY→ Z ⇒ WX→ Z

UnionSi un attribut détermine plusieurs autres attributs, alors il détermine tout groupe composé de ces attributs.

Soient X, Y et Z des attributs :X→ Y et X→ Z ⇒ X→ YZCette propriété est déduite de la réflexivité, de l'augmentation et de la transitivité :X→ Y et X→ Z ⇒ X→ XX et XX→ XY et YX→ YZ ⇒ X→ YZ

DécompositionSi un attribut détermine un groupe d'attribut, alors il détermine chacun des attributs de ce groupe prisindividuellement.Soient X, Y et Z des attributs :X→ YZ ⇒ X→ Z et X→ YCette propriété est déduite de la réflexivité et de la transitivité :X→ YZ ⇒ X→ YZ et YZ→ Z ⇒ X→ Z

6. DF élémentaireDépendance fonctionnelle élémentaireSoit G un groupe d'attributs et A un attribut, une DF G→ A est élémentaire si A n'est pas inclu dans G et qu'iln'existe pas d'attribut A' de G qui détermine A.

Exemple : DF élémentaires♦ AB→ C est élémentaire si ni A, ni B pris individuellement ne déterminent C.

♦ Nom, DateNaissance, LieuNaissance→ Prénom est élémentaire.

Exemple : DF non élémentaires♦ AB→ A n'est pas élémentaire car A est inclu dans AB.

♦ AB→ CB n'est pas élémentaire car CB n'est pas un attribut, mais un groupe d'attributs.

♦ N°SS→ Nom, Prénom n'est pas élémentaire.

RemarqueOn peut toujours réécrire un ensemble de DF en un ensemble de DFE [Dépendance Fonctionnelle Elémentaire], ensupprimant les DF triviales obtenues par réflexivité et en décomposant les DF à partie droite non atomique enplusieurs DFE.

Exemple : Réécriture de DF en DFEOn peut réécrire les DF non élémentaires de l'exemple précédent en les décomposant DFE :♦ AB→ A n'est pas considérée car c'est une DF triviale obtenu par réfléxivité.

♦ AB→ CB est décomposée en AB→ C et AB→ B, et AB→ B n'est plus considérée car triviale.

♦ N°SS→ Nom, Prénom est décomposée en N°SS→ Nom et N°SS→ Prénom.


7. Notion de fermeture transitive des DFEFermeture transitiveOn appelle fermeture transitive F+ d'un ensemble F de DFE, l'ensemble de toutes les DFE qui peuvent êtrecomposées par transitivité à partir des DFE de F.

ExempleSoit l'ensemble F = {A→ B, B→ C, B→ D, A→ E}.

La fermeture transitive de F est F+ = { A→ B, B→ C, B→ D, A→ E, A→ C, A→ D }

8. Notion de couverture minimale des DFECouverture minimaleLa couverture minimale d’un ensemble de DFE est un sous-ensemble minimum des DFE permettant de générertoutes les autres DFE.

♦ Synonyme : Famille génératrice.

RemarqueTout ensemble de DFE (et donc tout ensemble de DF) admet au moins une couverture minimale (et en pratiquesouvent plusieurs).

ExempleL'ensemble F = {A→ B, A→ C, B→ C, C→ B} admet les deux couvertures minimales :

CM1 = {A→ C, B→ C, C→ B} et CM2 = {A→ B, B→ C, C→ B}

9. Notion de graphe des DFEOn peut représenter un ensemble de DFE par un graphe orienté (ou plus précisément un réseau de Pétri), tel que les noeudssont les attributs et les arcs les DFE (avec un seul attribut en destination de chaque arc et éventuellement plusieurs en source).

Exemple : Relation VoitureSoit la relation Voiture(NVH, Marque, Type, Puis, Couleur) avec l'ensemble des DF F = {NVH→ Type, Type→Marque, Type→ Puis, NVH→ Couleur}. On peut réprésenter F par le graphe ci-dessous :

IMG. 33 : GRAPHE DES DFE DE LA RELATION VOITURE

Exemple : Relation CodePostalSoit la relation CodePostal(Code, Ville, Rue ) avec l'ensemble des DF F={Code→ Ville, (Ville,Rue)→ Code}. Onpeut réprésenter F par le graphe ci-dessous :


IMG. 34 : GRAPHE DES DFE DE LA RELATION CODEPOSTAL

10. Définition formelle d'une cléCléSoient une relation R(A1,A2,...,An) et K un sous-ensemble de A1,A2,... ,An. K est une clé de R si et seulement siK→ A1,A2,...,An et il n'existe pas X inclu dans K tel que X→ A1,A2,...,An.Une clé est donc un ensemble minimum d'attributs d'une relation qui détermine tous les autres.

Remarque : Clés candidates et clé primaireSi une relation comporte plusieurs clés, chacun est dite clé candidate et l'on en choisit une en particulier pour être laclé primaire.

RemarqueToute clé candidate détermine les autres clés candidates, puisque qu'une clé détermine tous les attributs de larelation.

11. Principe de la décompositionDécompositionL'objectif de la décomposition est de "casser" une relation en relations plus petites afin d'en éliminer lesredondances et sans perdre d'information.La décomposition d'un schéma de relation R(A1,A2,...,An) est le processus de remplacement de ce schéma par unecollection de schémas R1,R2,...,Rn telle qu'il est possible de reconstruire R par des opérations relationnelles dejointure sur R1,R2,...,Rn.

Décomposition préservant les DFUne décomposition d'une relation R en relations R1,R2,...Rn préserve les DF si la fermeture transitive F+ des DF deR est la même que celle de l'union des fermetures transitives des DF de R1,R2,...,Rn.

Exemple : Décomposition préservant les DF d'une relation VoitureSoit la relation Voiture(Numéro,Marque,Type,Puissance,Couleur) avec la fermeture transitive suivante :♦ Numéro→ Marque

♦ Numéro→ Type

♦ Numéro→ Puissance

♦ Numéro→ Couleur

♦ Type→ Marque

♦ Type→ Puissance

On peut décomposer Voiture en préservant les DF en deux relations R1(Numéro,Type,Couleur) etR2(Type,Puissance,Marque).

12. Formes normalesLes formes normales ont pour objectif de définir la décomposition des schémas relationnels, tout en préservant les DF et sansperdre d'informations, afin de représenter les objets et associations canoniques du monde réel de façon non redondante.


On peut rescencer les 6 formes normales suivantes, de moins en moins redondantes :♦ la première forme normale

♦ la deuxième forme normale

♦ la troisième forme normale

♦ la forme normale de Boyce-Codd

♦ la quatrième forme normale

♦ la cinquième forme normale

La troisième forme normale est généralement reconnue comme étant la plus importante à respecter.

13. Première forme normale

1NFUne relation est en 1NF [Première Forme Normale] si elle possède une clé et si tous ses attributs sont atomiques.

Attribut atomiqueUn attribut est atomique si il ne contient qu'une seule valeur pour un tuple donné, et donc s'il ne regroupe pas unensemble de plusieurs valeurs.

Exemple : Avoir plusieurs métiersSoit la relation Personne instanciée par deux tuples :

Personne(Nom, Profession)

(Dupont, Géomètre)(Durand, Ingénieur-Professeur)

La relation n'est pas en 1NF, car l'attribut Profession peut contenir plusieurs valeurs.Pour que la relation soit en 1NF, on pourrait par exemple ajouter Profession à la clé et faire apparaître deux tuplespour Durand, on obtiendrait :

Personne(Nom, Profession)

(Dupont, Géomètre)(Durand, Ingénieur)(Durand, Professeur)

Une autre solution aurait été d'ajouter un attribut ProfessionSecondaire. On obtiendrait ainsi :

Personne(Nom, Profession, ProfessionSecondaire)

(Dupont, Géomètre, Null)(Durand, Ingénieur, Professeur)

Remarque : Relativité de la notion d'atomicitéL'atomicité d'un attribut est souvent relative : on peut décider qu'un attribut contenant une date n'est pas atomique(et que le jour, le mois et l'année constituent chacun une valeur), ou bien que l'attribut est de domaine date et doncqu'il est atomique.

14. Deuxième forme normaleLa deuxième forme normale permet d'éliminer les dépendances entre des parties de clé et des attributs n'appartenant pas à uneclé.

2NFUne relation est en 2NF [Deuxième Forme Normale] si elle est en 1NF et si tout attribut qui n'est pas dans une cléne dépend pas d'une partie seulement d'une clé. C'est à dire encore que toutes les DF issues d'une clé sontélémentaires.

Exemple : Echelle de salaireSoit la relation Personne :

Personne(Nom, Profession, Salaire)

Soit les DF suivantes sur cette relation :♦ Nom,Profession→ Salaire

♦ Profession→ Salaire


On note alors que la première DF est issue de la clé et qu'elle n'est pas élémentaire (puisque Profession détermineSalaire) et donc que le schéma n'est pas en 2NF.Pour avoir un schéma relationnel en 2NF, il faut alors décomposer Personne en deux relations :

Personne(Nom, Profession)Profession(Profession, Salaire)

On remarque que ce schéma est en 2NF (puisque Salaire dépend maintenant fonctionnellement d'une clé et non plusd'une partie de clé).On remarque aussi que la décomposition a préservé les DF, puisque nous avons à présent :♦ Profession→ Salaire (DF de la relation Profession)

♦ Nom,Profession→ Profession (par Réflexivité)

♦ Nom,Profession→ Salaire (par Transitivité)

RemarqueLa définition de la 2NF doit être vérifiée pour toutes les clés candidates et non seulement la clé primaire (dans le casoù il y a plusieurs clés).

RemarqueSi toutes les clés d'une relation ne contiennent qu'un unique attribut, et que la relation est en 1NF, alors la relationest en 2NF.

15. Troisième forme normaleLa troisième forme normale permet d'éliminer les dépendances entre les attributs n'appartenant pas à une clé.

3NFUne relation est en 3NF [Troisième Forme Normale] si elle est en 2NF et si tout attribut n'appartenant pas à une cléne dépend pas d'un autre attribut n'appartenant pas à une clé. C'est à dire encore que toutes les DFE vers desattributs n'appartenant pas à une clé, sont issues d'une clé.

Exemple : Echelle de salaire et de primeSoit la relation Profession :

Profession(Profession, Salaire, Prime)

Soit les DF suivantes sur cette relation :♦ Profession→ Salaire

♦ Profession→ Prime

♦ Salaire→ Prime

Cette relation n'est pas en 3NF car Salaire, qui n'est pas une clé, détermine Prime.Pour avoir un schéma relationnel en 3NF, il faut décomposer Profession :

Profession(Profession, Salaire)Salaire(Salaire, Prime)

Ce schéma est en 3NF, car Prime est maintenant déterminé par une clé.On remarque que cette décomposition préserve les DF, car par transitivité, Profession détermine Salaire quidétermine Prime, et donc Profession détermine toujours Prime.

Remarque : 3NF et 2NFUne relation en 3NF est forcément en 2NF car :♦ Toutes les DFE vers des attributs n'appartenant pas à une clé sont issues d'une clé, ce qui implique qu'il n'existe

pas de DFE, issues d'une partie de clé vers un attribut qui n'appartient pas à une clé.

♦ Il ne peut pas non plus exister de DFE issues d'une partie de clé vers un attribut appartenant à une clé, pardéfinition de ce qu'une clé est un ensemble minimum.

On n'en conclut qu'il ne peut exister de DFE, donc a fortiori pas de DF, issues d'une partie d'une clé, et donc quetoutes les DF issues d'une clé sont élémentaires.

Il est souhaitable que les relations logiques soient en 3NF. En effet, il existe toujours une décomposition sans perted'information et préservant les DF d'un schéma en 3NF. Si les formes normales suivantes (BCNF [Forme Normale deBoyce-Codd], 4NF [Quatrième Forme Normale] et 5NF [Cinquième Forme Normale]) assurent un niveau deredondance encore plus faible, la décomposition permettant de les atteindre ne préserve plus les DF.


Remarque : Limite de la 3NFUne relation en 3NF permet des dépendances entre des attributs n'appartenant pas à une clé vers des parties de clé.

16. Forme normale de Boyce-CoddLa forme normale de Boyce-Codd permet d'éliminer les dépendances entre les attributs n'appartenant pas à une clé vers lesparties de clé.

BCNFUne relation est en BCNF si elle est en 3NF et si tout attribut qui n'appartient pas à une clé n'est pas source d'uneDF vers une partie d'une clé. C'est à dire que les seules DFE existantes sont celles dans lesquelles une clé détermineun attribut.

Exemple : EmployésSoit la relation Personne :

Personne(N°SS, Pays, Nom, Région)

Soit les DF suivantes sur cette relation :♦ N°SS,Pays→ Nom

N°SS,Pays→ Région

Région→ Pays

Il existe une DFE qui n'est pas issue d'une clé et qui détermine un attribut appartenant à une clé. Cette relation est en3NF, mais pas en BCNF (car en BCNF toutes les DFE sont issues d'une clé).Pour avoir un schéma relationnel en BCNF, il faut décomposer Personne :

Personne(N°SS, Région, Nom)Région(Region, Pays)

Remarquons que les DF n'ont pas été préservées par la décomposition puisque N°SS et Pays ne déterminent plusRégion.

Remarque : SimplicitéLa BCNF est la forme normale la plus facile à appréhender intuitivement et formellement, puisque les seules DFEexistantes sont de la forme K→ A où K est une clé.

Non préservation des DFUne décomposition en BCNF ne préserve en général pas les DF.

* **

La normalisation permet de décomposer un schéma relationnel afin d'obtenir des relations non redondantes.La 3NF est souhaitable car toujours possible à obtenir, sans perte d'information et sans perte de DF. La BCNF est égalementindiquée, car elle est un peu plus puissante, et plutôt plus simple que la 3NF.La BCNF n'est pas encore suffisante pour éliminer toutes les redondances. Il existe pour cela les 4NF et 5NF qui ne sont pasabordées dans ce cours. Notons également que les cas de non-4NF et de non-5NF sont assez rares dans la réalité.

Section A2. Pratique de la normalisation

Exercice n°15. Dépendances alphabétiquesConsidérons le schéma de la relation suivante :

r (A, B, C, D, E)

Cette relation est instanciée par les tuples :♦ (a1, b2, c2, d3, e2)

♦ (a1, b2, c2, d1, e4)

♦ (a2, b3, c2, d1, e5)

♦ (a2, b4, c5, d1, e5)


Question1Parmi les dépendances fonctionnelles suivantes, lesquelles ne s'appliquent pas à r ?

♦ E-->D

♦ D-->E

♦ C-->A

♦ E-->B

♦ E-->A

♦ B-->C

♦ B-->D

♦ B-->A

Question2Trouver une clé pour r.

Question3En quelle NF est cette relation ?

Exercice n°16. Cuisines et dépendancesOn considère une relation R construite sur les attributs Propriétaire, Occupant, Adresse, Noapt, Nbpièces, Nbpersonnes, unnuplet (p, o, a, n, nb1, nb2) ayant la signification suivante :La personne o habite avec nb2 personnes l'appartement de numéro n ayant nb1 pièces dont le propriétaire est p.Une analyse de cette relation nous fournit un ensemble initial E de dépendances fonctionnelles :

occupant --> adresseoccupant --> noaptoccupant --> nbpersonnesadresse, noapt --> propriétaireadresse, noapt --> occupantadresse, noapt --> nbpièces

Question1Donner l'ensemble des dépendances fonctionnelles élémentaires engendrées par E.

Question2Quelles sont les clés candidates de R ?

Question3R est elle en 3ème forme normale ?

Exercice n°17. De quoi dépend un cours ?On considère le schéma relationnel R défini sur les attributs suivants : C : cours, P : professeur, H : heure, S : salle, E :étudiant, N : note.Un nuplet (c, p, h, s, e, n) a pour signification que le cours c est fait par le professeur p à l'heure h dans la salle s pourl'étudiant e qui a reçu la note n.L'ensemble E des dépendances fonctionnelles initiales est le suivant :

C --> PH,S --> CH,P --> SC,E --> NH,E --> S

Question1Donner l'ensemble des dépendances fonctionnelles élémentaires engendrées par E.

Question2Quelle est la clé de la relation R ? Montrer qu'elle est unique.


Question3On décompose la relation R en quatre relations : R1(C,E,N), R2(C,P), R3(C,H,S), R4(C,H,E).

Pour chacune de ces relations, donner sa clé et sa forme normale. Cette décomposition est-elle sans perted'information ? Préserve-t-elle les dépendances fonctionnelles ? Justifiez votre réponse.

Partie B. Définition et contrôle de données

Objectifs pédagogiquesMaîtriser les bases du SQL pour créer des tables, attribuer des droits et entrer, modifier et effacer des données dans lestables.

Bref aperçu

SQL est un langage déclaratif destiné aux SGBD et plus particulièrement aux SGBDR. Ce langage est défini par une normeISO datant de 1986 pour SQL1 et 1992 pour SQL2[La norme SQL3 en 1999 étend SQL aux SGBD Relationnels-Objets].SQL n'est pas a proprement parlé un langage de programmation, mais plutôt une interface standard pour accéder aux bases dedonnées.Il est composé de trois sous ensembles :♦ Le LDD pour créer et supprimer des objets dans la base de données (tables, contraintes d'intégrité, vues, etc.).

♦ Le LCD pour gérer les droits sur les objets de la base (création des utilisateurs et affectation de leurs droits).

♦ Le LMD pour la recherche, l'insertion, la mise à jour et la suppression de données.

Le LMD est basé sur les opérateurs relationnels, auxquels sont ajoutés des fonctions de calcul d'agrégats et desinstructions pour réaliser les opérations d'insertion, mise à jour et suppression.

Section B1. Le LDD de SQL

Le LDD permet de créer les objets composant une BD de façon déclarative. Il permet notamment la définition des schémasdes relations, la définition des contraintes d'intégrité, la définition de vues relationnelles.

1. Types de donnéesUn attribut d'une relation est défini pour un certain domaine. On peut également dire qu'il est d'un type particulier. Les typesde données disponibles en SQL varient d'un SGBD à l'autre, on peut néanmoins citer un certain nombre de types standardsque l'on retrouve dans tous les SGBD.

1.1. Les types numériques♦ Les nombres entiers

INTEGER(X), où X est optionnel et désigne le nombre de chiffres maximum pouvant composer le nombre. Il existeégalement un certain nombre de variantes permettant de définir des entiers plus ou moins volumineux, tels que TINYINT,SMALLINT ou LONGINT.

♦ Les nombres décimaux

DECIMAL(X,Y), où X et Y sont optionnels et désignent respectivement le nombre de chiffres maximum pouvantcomposer le nombre avant et après la virgule. NUMERIC est également utilisé de façon équivalente.

♦ Les nombres à virgule flottante

REAL(X,Y), avec X et Y optionnels et définissant le nombre de chiffres avant et après la virgule.

Il existe également un certain nombre de variantes permettant de définir une précision plus grande, telles que DOUBLE.


1.2. Les types chaîne de caractèresOn distingue principalement les types CHAR(X) et VARCHAR(X), où X et obligatoire et désigne la longueur de la chaîne.CHAR définit des chaînes de longueur fixe (complétée à droites par des espaces, si la longeur est inférieure à X) etVARCHAR des chaînes de longueurs variables. CHAR et VARCHAR sont généralement limités à 255 caractères. La plupartdes SGBD proposent des types, tels que TEXT ou CLOB (Character Long Object), pour représenter des chaînes de caractèreslongues, jusqu'à 65000 caractères par exemple.

1.3. Les types dateLes types date dont introduits avec la norme SQL2. On distingue le type DATE qui représente une date selon un format detype "AAAA-MM-JJ" et le types DATETIME qui représente une date avec un horaire, dans un format tel que"AAAA-MM-JJ HH:MM:SS". Il existe également des restrictions de ces types, tels que YEAR, TIME, etc.

1.4. Les autres typesEn fonction du SGBD, il peut exister de nombreux autres types. On peut citer par exemple les types monétaires pourreprésenter des décimaux associés à une monnaie, les types ENUM pour représenter des énumérations, les types BLOB (pourBinary Long Oject) pour représenter des données binaires tels que des documents multimédia (images bitmap, vidéo, etc.).

1.5. Le type absence de valeurL'absence de valeur, représentée par la valeur NULL, est une information fondamentale en SQL, qu'il ne faut pas confondreavec la chaîne espace de caractère où bien la valeur 0. Il ne s'agit pas d'un type à proprement parler, mais d'une valeurpossible dans tous les types.

2. Création de tablesLa création de table est le fondement de la création d'une base de données en SQL.

Création de tableLa création de table est la définition d'un schéma de relation en intension, par la spécification de tous les attributs lecomposant avec leurs domaines respectifs.

SyntaxeCREATE TABLE <nom de table> (

<nom colonne1> <type colonne1>,<nom colonne2> <type colonne2>,...<nom colonneN> <type colonneN>,

);

ExempleCREATE TABLE Personne (

Nom VARCHAR(25),Prenom VARCHAR(25),Age INTEGER(3)

);

Contrainte d'intégritéLa définition des attributs n'est pas suffisante pour définir un schéma relationnel, il faut lui adjoindre la définition decontraintes d'intégrité, qui permette de poser les notions de clé, d'intégrité référentielle, de restriction de domaines,etc.


3. Contraintes d'intégritéContraintes d'intégritéUne contrainte d'intégrité est une règle qui définit la cohérence d'une donnée ou d'un ensemble de données de laBD.Il existe deux types de contraintes :♦ sur une colonne unique,

♦ ou sur une table lorsque la contrainte porte sur une ou plusieurs colonnes.

Les contraintes sont définies au moment de la création des tables.Les contraintes d'intégrité sur une colonne sont :♦ PRIMARY KEY : définit l'attribut comme la clé primaire

♦ NOT NULL : interdit l'absence de valeur pour l'attribut

♦ UNIQUE : interdit que deux tuples de la relation aient la même valeur pour l'attribut.

♦ REFERENCES <nom table> (<nom colonnes>) : contrôle l'intégrité référentielle entre l'attribut et la table et sescolonnes spécifiées

♦ CHECK (<condition>) : contrôle la validité de la valeur de l'attribut spécifié dans la condition dans le cadred'une restriction de domaine

Les contraintes d'intégrité sur une table sont :♦ PRIMARY KEY (<liste d'attibuts>) : définit les attributs de la liste comme la clé primaire

♦ UNIQUE (<liste d'attibuts>) : interdit que deux tuples de la relation aient les mêmes valeurs pour l'ensemble desattributs de la liste.

♦ FOREIGN KEY (<liste d'attibuts>) REFERENCES <nom table>(<nom colonnes>) : contrôle l'intégritéréférentielle entre les attributs de la liste et la table et ses colonnes spécifiées

♦ CHECK (<condition>) : contrôle la validité de la valeur des attributs spécifiés dans la condition dans le cadred'une restriction de domaine

SyntaxeCREATE TABLE <nom de table> (

<nom colonne1> <type colonne1> <contraintes colonne1>,<nom colonne2> <type colonne2> <contraintes colonne2>,...<nom colonneN> <type colonneN> <contraintes colonneN>,<contraintes de table>

);

Remarque : Clé candidateLa contrainte UNIQUE NOT NULL sur un attribut ou un groupe d'attributs définit une clé candidate non primaire.

RemarqueLes contraintes sur une colonne et sur une table peuvent être combinées dans la définition d'un même schéma derelation.Une contrainte sur une colonne peut toujours être remplacée par une contrainte sur une table.

ExempleCREATE TABLE Personne (

N°SS CHAR(13) PRIMARY KEY,Nom VARCHAR(25) NOT NULL,Prenom VARCHAR(25) NOT NULL,Age INTEGER(3) CHECK (Age BETWEEN 18 AND 65),Mariage CHAR(13) REFERENCES Personne(N°SS),Codepostal INTEGER(5),Pays VARCHAR(50),UNIQUE (Nom, Prenom),FOREIGN KEY (Codepostal, Pays) REFERENCES Adresse (CP, Pays)

);

CREATE TABLE Adresse (CP INTEGER(5) NOT NULL,Pays VARCHAR(50) NOT NULL,Initiale CHAR(1) CHECK (Initiale = LEFT(Pays, 1)),PRIMARY KEY (CP, Pays)

);

Dans la définition de schéma précédente on a posé les contraintes suivantes :♦ La clé primaire de Personne est N°SS et la clé primaire de Adresse est (CP, Pays).


♦ Nom, Prénom ne peuvent pas être null et (Nom, Prénom) est une clé.

♦ Age doit être compris entre 18 et 65 et Initiale doit être la première lettre de Pays (avec la fonction LEFT quirenvoie la sous chaîne à gauche de la chaîne passée en premier argument, sur le nombre de caractères passés ensecond argument)

♦ Mariage est clé étrangère vers Personne et (Codepostal, Pays) est une clé étrangère vers Adresse.

4. Création de vuesVueUne vue est une définition logique d'une relation, sans stockage de données, obtenue par interrogation d'une ouplusieurs tables de la BD. Une vue peut donc être perçue comme une fenêtre dynamique sur les données, ou encoreune requête stockée (mais dont seule la définition est stockée, pas le résultat, qui reste calculé dynamiquement).Une vue permet d'implémenter le concept de schéma externe d'un modèle conceptuel.

♦ Synonymes : Relation dérivée, Table virtuelle calculée.

SyntaxeCREATE VIEW <nom de vue> <nom des colonnes>AS <spécification de question>

La spécification d'une question se fait en utilisant le LMD.Le nombre de colonnes nommées doit être égal au nombre de colonnes renvoyées par la question spécifiée. Le nom descolonnes est optionnel, s'il n'est pas spécifié, c'est le nom des colonnes telle qu'elles sont renvoyées par la question, qui serautilisé.

ExempleCREATE VIEW Employe (Id, Nom)AS

SELECT N°SS, NomFROM Personne

La vue Employe est ici une projection de la relation Personne sur les attributs N°SS et Nom, renommésrespectivement Id et Nom.

Remarque : Vue en lecture et vue en écritureUne vue est toujours disponible en lecture, à condition que l'utilisateur ait les droits spécifiés grâce au LCD. Unevue peut également être disponible en écriture dans certains cas, que l'on peut restreindre aux cas où la question neporte que sur une seule table (même si dans certains cas, il est possible de modifier une vue issue de plusieurstables).Dans le cas où une vue est destinée à être utilisée pour modifier des données, il est possible d'ajouter la clause"WITH CHECK OPTION" après la spécification de question, pour préciser que les données modifiées ou ajoutéesdoivent effectivement appartenir à la vue.

Remarque : Vue sur une vueUne vue peut avoir comme source une autre vue.

5. Supression d'objetsIl est possible de supprimer des objets de la BD, tels que les tables ou les vues.Syntaxe

DROP <type objet> <nom objet>

ExempleDROP TABLE Personne;DROP VIEW Employe;

6. Modification de tablesL'instruction ALTER TABLE permet de modifier la définition d'une table (colonnes ou contraintes) préalablement créée.Cette commande absente de SQL-89 est normalisée dans SQL-92Syntaxe : Ajout de colonne

ALTER TABLE <nom de table> (ADD (<définition de colonne>);


Syntaxe : Suppression de colonneALTER TABLE <nom de table> (

DROP (<nom de colonne>);

Syntaxe : Modification de colonneALTER TABLE <nom de table> (

MODIFY (<redéfinition de colonne>);

Syntaxe : Ajout de contrainteALTER TABLE <nom de table> (

ADD (<définition de contrainte de table>);

Remarque : Modification de table sans donnée sans la commande ALTERPour modifier une table ne contenant pas encore de donnée, la commande ALTER n'est pas indispensable, l'on peutsupprimer la table à modifier (DROP) et la recréer telle qu'on la souhaite. Notons néanmoins que si la table estréférencée par des clauses FOREIGN KEY, cette suppression sera plus compliquée, car il faudra égalementsuprimer et recréer les tables référençantes (ce qui ce complique encore si ces dernières contiennent des données).

Remarque : Modification de table avec données sans la commande ALTERPour modifier une table contenant des données, la commande ALTER n'est pas absolument indispensable. On peuten effet :1. Copier les données dans une table temporaire de même schéma que la table à modifier

2. Supprimer et recréer la table à modifier avec le nouveau schéma

3. Copier les données depuis la table temporaire vers la table modifiée

7. Exemple de modifications de tablesTable initialeSoit une table intiale telle que définie ci-après.

create table t_personnes (pk_n number (4),nom varchar(50),prenom varchar (50),PRIMARY KEY (pk_n)

);

ModificationsOn décide d'apporter les aménagements suivants à la table : on passe la taille du champ "nom" de 50 à 255 caractèresmaximum, on définit "nom" comme UNIQUE et on supprime le champ "prenom".

alter table t_personnesmodify (nom varchar(255));

alter table t_personnesadd (UNIQUE (nom));

alter table t_personnesdrop (prenom);

Table finaleLa table obtenue après modification est identique à la table qui aurait été définie directement telle que ci-après.

create table t_personnes (pk_n number (4),nom varchar(255),PRIMARY KEY (pk_n),UNIQUE (nom)

);

Exercice n°18. Quoi de neuf docteur ?Soit un modèle conceptuel E-A représentant :♦ un type d'entité "chercheur", identifié par le numéro de sécurité sociale, et possédant les autres propriétés suivantes : le

nom, le nom de l'université à laquelle il appartient, la ville dans laquelle est basée cette université.

♦ un type d'entité "professeur", héritant de "chercheur"

♦ un type d'entité "doctorant", héritant de "chercheur"

♦ une association de type "encadrement" entre professeur et doctorant (un professeur pouvant encadrer plusieurs doctorantset un doctorant n'ayant qu'un et un seul directeur de thèse).


Question1Dessinez le modèle E-A.

Question2Traduisez le modèle E-A en modèle logique relationnel.

Question3Après avoir identifié les DF, normalisez le modèle relationnel en BCNF.

Question4Ecrivez les instructions SQL de création d'un tel modèle.

Section B2. Le LCD de SQL

Le LCD permet de créer les utilisateurs et de définir leurs droits sur les objets de la BD de façon déclarative. Il permetnotamment l'attribution et la révocation de droits à des utilisateurs, sur l'ensemble des bases du SGBD, sur une BD enparticulier, sur des relations d'une BD, voire sur certains attributs seulement d'une relation.

1. Attribution de droitsSQL propose une commande pour attribuer des droits à des utilisateurs sur des tables.Syntaxe

GRANT <liste de droits> ON <nom table> TO <utilisateur> [WITH GRANT OPTION]

Les droits disponibles renvoient directement aux instructions SQL que l'utilisateur peut exécuter :♦ SELECT

♦ INSERT

♦ DELETE

♦ UPDATE

♦ ALTER

De plus il est possible de spécifier le droit ALL PRIVILEGES qui donne tous les droits à l'utilisateur (sauf celui detransmettre ses droits).La clause WITH GRANT OPTION est optionnelle, elle permet de préciser que l'utilisateur a le droit de transférer ses propresdroits sur la table à d'autres utilisateur. Une telle clause permet une gestion décentralisée de l'attribution des droits et nonreposant uniquement dans les mains d'un administrateur unique.La spécification PUBLIC à la place d'un nom d'utilisateur permet de donner les droits spécifiés à tous les utilisateurs de laBD.

ExempleGRANT SELECT, UPDATE ON Personne TO Pierre;GRANT ALL PRIVILEGES ON Adresse TO PUBLIC;

Remarque : Droits sur un SGBDCertains SGBD permettent de spécifier des droits au niveau du SGBD, c'est à dire pour toutes les tables de toutesles BD du SGBD. La syntaxe dans le cas de MySQL est "*.*" à la place du nom de la table.Dans ce cas les droits CREATE et DROP sont généralement ajoutés pour permettre ou non aux utilisateurs de créeret supprimer des BD et des tables.

Remarque : Droits sur une BDCertains SGBD permettent de spécifier des droits au niveau d'une BD, c'est à dire pour toutes les tables de cettebase de données. La syntaxe dans le cas de MySQL est "nom_bd.*" à la place du nom de la table.Dans ce cas les droits CREATE et DROP sont généralement ajoutés pour permettre ou non aux utilisateurs de créeret supprimer des tables sur cette BD.

Remarque : Droits sur une vueIl est possible de spécifier des droits sur des vues plutôt que sur des tables, avec une syntaxe identique (et un nomde vue à la place d'un nom de table).


Remarque : Catalogue de donnéesLes droits sont stockés dans le catalogue des données, il est généralement possible de modifier directement cecatalogue à la place d'utiliser la commande GRANT. Cela reste néanmoins déconseillé.

Remarque : Création des utilisateursLes modalités de création d'utilisateurs, voire de groupes d'utilisateurs dans le SGBD, reste dépendantes de celui-ci.Des commande SQL peuvent être disponibles, telles que CREATE USER, ou bien la commande GRANT lorsquequ'elle porte sur un utilisateur non existant peut être chargée de créer cet utilisateur. Des modules spécifiquesd'administration sont généralement disponibles pour prendre en charge la gestion des utilisateurs.

2. Révocation de droitsSQL propose une commande pour révoquer les droits attribués à des utilisateurs.Syntaxe

REVOKE <liste de droits> ON <nom table> FROM <utilisateur>

ExempleREVOKE SELECT, UPDATE ON Personne TO Pierre;REVOKE ALL PRIVILEGES ON Adresse TO PUBLIC;

Remarque : Révocation du droit de donner les droitsPour retirer les droits de donner les droits à un utilisateur (qui l'a donc obtenu par la clause WITH GRANTOPTION), il faut utiliser la valeur GRANT OPTION dans la liste des droits révoqués.

Remarque : Révocation en cascadeLorsque qu'un droit est supprimé pour un utilisateur, il l'est également pour tous les utilisateurs qui avait obtenu cemême droit par l'utilisateur en question.

Exercice récapitulatif VI. The show must go on !

Enoncé n°1Soit le schéma relationnel suivant décrivant un système de réservations de places de spectacles :

SPECTACLES (nospectacle, nom, durée, type)SALLES (nosalle, nbplaces)REPRESENTATIONS (nosalle, date, nospectacle, prix)BILLETS (nobillet, date, nosalle, nospectacle, nomclient)

En faisant les suppositions suivantes :♦ On gère un espace de spectacles ayant un ensemble de salles (décrit par la relation SALLES).

♦ On suppose que pour un jour donné et une salle donnée, il n'y a qu'un seul spectacle représenté.

♦ Un spectacle peut être représenté plusieurs fois, à des dates (toujours) différentes et en des salles (éventuellement)différentes.

Question1.1Donner les principales contraintes d'intégrité associées à ce schéma (en français).

Question1.2Proposer une définition du schéma en SQL qui prenne en compte le plus possible de contraintes.

Enoncé n°2On suppose que 3 classe d'utilisateurs ont accès à tout ou partie de ce schéma relationnel :♦ L'administrateur de la base, qui initialise la base et donne notamment en début de saison tous les spectacles avec toutes les

représentations associées.

♦ Les guichetiers qui gèrent les réservations à ces réprésentations et donc émettent les billets.

♦ Et enfin les clients potentiels qui peuvent consulter la base pour connaître les spectacles joués (éventuellement par type) etsavoir les représentations où il reste des places disponibles.

Question2.1Proposer un schéma externe sous forme de vues pour chacune de ces différentes classes d'utilisateurs.


Question2.2Donner les droits associés à chaque classe d'utilisateurs.

En résumé...

Langage SQLLe langage SQL permet la création, lecontrôle et la manipulation d'une BD.

LDDPermet de créer, modifier et

supprimer les objets d'une BD

LCDPermet de définir les droits des

utilisateurs sur les objets de la BD

LMDPermet d'entrer et sortir des

données dans la BD

CREATETABLE

CREATEVIEW

GRANT REVOKE INSERT,UPDATE,DELETE

SELECT

Normalisation de relationsSoit un modèle conceptuel E-A représentant :♦ un type d'entité "chercheur", identifié par le numéro de sécurité sociale, et possédant les autres propriétés suivantes : le

nom, le nom de l'université à laquelle il appartient, la ville dans laquelle est basée cette université.

♦ un type d'entité "professeur", héritant de "chercheur"

♦ un type d'entité "doctorant", héritant de "chercheur"

♦ une association de type "encadrement" entre professeur et doctorant (un professeur pouvant encadrer plusieurs doctorantset un doctorant n'ayant qu'un et un seul directeur de thèse).

♦ Dessiner le modèle E-A.

♦ Traduire le modèle E-A en modèle logique relationnel.

♦ Après avoir identifié les DF, normaliser le modèle relationnel en BCNF.

♦ Ecrire les instructions SQL de création d'un tel modèle.


Modèle E-A

IMG. 35

Modèle relationnelProfesseur ( N°SS:int(13), Nom:char(20), NomUniv:char(50), VilleUniv:char(20))Doctorant(N°SS:int(13), Nom:char(20), NomUniv:char(50), VilleUniv:char(20),EncadrePar=>Professeur)

Dépendances FonctionnellesProfesseur :♦ N°SS→ Nom, NomUniv, VilleUniv

♦ NomUniv→ VilleUniv

Doctorant :♦ N°SS→ Nom, NomUniv, VilleUniv

♦ NomUniv→ VilleUniv

Formes normalesLa schéma n'est pas en 3NF :NomUniv→ VilleUniv

Normalisation en BCNFProfesseur (N°SS:int(13), Nom:char(20), NomUniv=>Univ)Doctorant (N°SS:int(13), Nom:char(20), NomUniv=>Univ, EncadrePar=>Professeur)Univ(Nom:char(50) , Ville:char(20))


Implémentation SQLCreate Table Professeur (

N°SS INTEGER(13) PRIMARY KEY,Nom CHAR(20) NOT NULL,NomUniv CHAR(50) REFERENCES Univ(Nom));

Create Table Doctorant (N°SS INTEGER(13) PRIMARY KEY,Nom CHAR(20) NOT NULL,NomUniv CHAR(50) REFERENCES Univ(Nom),EncadrePar INTEGER(13) REFERENCES Professeur(N°SS) );

Create Table Univ(Nom CHAR(50) PRIMARY KEY,Ville CHAR(20) );

Exercice récapitulatif VI. Le chemin à l'enversSoit une base de données, composée d'une seule table et de deux vues, permettant de gérer les chanteurs préférés desfrançaises et des français.Cette base est définie par le code SQL LDD ci-après.

create table t_personnes (pk_n number (4),numss char(13) UNIQUE NOT NULL,nom varchar(50) NOT NULL,prenom varchar (50),sexe char(1),conjoint char(13) UNIQUE,chanteur_préféré char(50),nationalité_chanteur_préféré char(20),PRIMARY KEY (pk_n),CHECK (sexe IN ('H', 'F'))

);

create view v_hommes (pk_n, numss, nom, prenom, conjoint, chanteur_préféré,nationalité_chanteur_préféré)

asselect pk_n, numss, nom, prenom, conjoint, chanteur_préféré, nationalité_chanteur_préféréfrom t_personneswhere sexe='H';

create view v_femmes (pk_n, numss, nom, prenom, conjoint, chanteur_préféré,nationalité_chanteur_préféré)

asselect pk_n, numss, nom, prenom, conjoint, chanteur_préféré, nationalité_chanteur_préféréfrom t_personneswhere sexe='F';

On notera que, selon ce modèle, le conjoint d'une femme ou d'un homme est un homme ou une femme ; que X est conjoint deY n'implique pas que Y est conjoint de X ; et que X peut être conjoint de X.

Question1Quel attribut est la clé primaire de "t_personnes" ? Comment appelle-t-on ce genre de clé ? Quel est le statut de"numss" ? Quel est le statut de "conjoint" ?

Question2Expliquez pourquoi si "conjoint" référence la table "t_personnes", alors son domaine n'est pas correct.

Modifiez le domaine de "conjoint", puis ajouter une contraite à la table "t_personnes" pour que "conjoint" soit uneclé étrangère vers "t_personnes", en s'assurant que les contraintes d'intégrité référentielles seront respectées. Vousutiliserez pour cela deux instructions ALTER.

Question3Enoncez les DF du modèle relationnel sous-jacent à cette implémentation (en se fondant sur la vraisemblance) sousla forme d'une couverture minimale des DFE.A partir de la couverture minimale des DFE, prouvez que ce schéma est en 2NF mais pas en 3NF.

Question4Proposez un programme SQL permettant de décomposer le schéma de cette BD afin qu'il soit en 3NF, sans perdred'information, sans perdre de DF et sans perdre les données déjà existantes dans la BD.Pour ce faire vous utiliserez une instruction CREATE TABLE permettant de créer la nouvelle table engendrée parla décomposition, puis une instruction INSERT permettant d'initialiser correctement cette nouvelle table avec lesvaleurs existantes dans "t_personnes", et enfin deux instructions ALTER pour modifier la table "t_personne" defaçon à en supprimer la redondance et à établir la référence à la nouvelle table.On fera l'hypothèse que la BD ne contient pas d'incohérence.


Question5A l'aide d'UML rétro-concevez le MCD qui aurait permis d'arriver directement à votre modèle après normalisation.Justifiez.On notera la présence des vues dans le schéma initial de la BD et l'on ne reportera pas sur ce schéma les clésartificielles.

Question6Ecrivez une requête qui compte le nombre de personnes qui ont le même chanteur préféré que leur conjoint.

On notera que cette requête est équivalente sur le schéma avant ou après normalisation.

Question7Ecrivez un trigger en PL/SQL qui à assure que : X conjoint de Y implique Y conjoint de X ; X conjoint de X estimpossible ; et X conjoint de Y implique que X et Y sont de sexes opposés.


Cours

VAccess

Access est un SGBDR du monde Microsoft Windows qui présente des particularités intéressantes dans le cadre de ce cours. Ilpropose une implémentation sticte des concepts relationnels, et ce dans un cadre facile d'accès techniquement : il constitue unbon moyen d'accès aux technologies des BD. C'est également un outil intéressant pour prototyper des applications de BD oupour réaliser des applications finales dans des cadres d'usage restreint ou bureautique.

Partie A. Technologie Access

Objectifs pédagogiquesDécouvrir un SGBD simple d'usageDécouvrir des principes de maquettage rapide d'application BDConnaître les principes du langage de requête QBE et savoir lire une requête QBEConnaître les éléments techniques de base pour apprendre à créer une BD sous AccessConnaître les éléments techniques de base pour apprendre à créer une application sous Access

Présentation d'Access

Access est un SGBDR et un outil de création d'application qui permet de :♦ Créer des schémas relationnels et donc créer des tables, des contraintes sur les champs de ces tables et des contraintes

référentielles entre ces tables

♦ Saisir des données dans les tables, à travers une interface graphique standard, sans passer par l'instruction LMD INSERT

♦ Ecrire des requêtes en utilisant le langage SQL ou bien le formalisme graphique QBE [Query By Example]

♦ Réaliser des formulaires permettant d'alimenter ou interroger la BD

♦ Réaliser des états permettant de mettre en forme des résultats de requête

♦ Réaliser des macros permettant de programmer une application complète

♦ Réaliser des modules VBA permettant également de programmer une application complète, avec un spectre plus évoluéque celui des macros

IMG. 36 : LISTE ET FONCTIONS DES OBJETS MANIPULABLES AVEC ACCESS

Section A1. Généralités

1. Avantages et inconvénient d'Access

1.1. Avantages♦ Rapidité de mise en oeuvre

♦ Facilité de maintenance ou reprise

♦ Rapidité de création d'IHM

♦ Langage graphique permettant un apprentissage rapide

♦ Schéma de données robustes (intégrité référentielle, contraintes, type de données, etc.)

♦ Utilisation restreinte aux plateformes Microsoft Windows

1.2. Inconvénient♦ Fiabilité douteuse

♦ Résistance faible à la montée en charge

♦ Peu adapté à des logiques réseaux

♦ Système de sécurité non standard, complexe et inadapté

♦ Faiblesse des IHM pour des applications complexes

1.3. Cas d'usageAccess est recommandé pour :♦ L'apprentissage des BD

♦ Le prototypage rapide de BD et d'application (précision de cahier des charges, dialogue démonstratif avec les utilisateurs,phase avant la réalisation avec un SGBD industriel, etc.).

♦ Les petites applications locales ou LAN, avec peu d'utilisateurs (dizaines) et un volume de données raisonnable (centainesde milliers d'enregistrements, méga-octets).

♦ Les applications ne pouvant être maintenues par des informaticiens.


2. Séparation base de données et applicationConseilAccess est à la fois un SGBDR permettant de créer des BD et à la fois un outil de développemet d'application. Il estrecommandé, pour des raisons méthodologiques et pratiques de bien séparer ces deux aspects du problème.

Séparation BD / ApplicationPour créer une application complète sous Access, créer deux fichiers ".mdb", l'un contiendra la base de données(uniquement les tables et les vues sous forme de requêtes), l'autre l'application (les formulaires, états, macros etmodules VBA).Pour relier les deux applications, créer des tables liés dans le fichier "application", à l'aide du menu "Fichier /Données externes / Lier les tables"

Remarque : Avantages de cette séparation♦ Séparation des problèmatiques de développement

On ne fait pas à la fois le travail de modélisation de la BD et le travail de réalisation d'une applicationd'exploitation de cette BD.

♦ Utilisation en réseau LAN

Une BD centrale sur un serveur et N applications clientes locales.

♦ Diminution des risques de crash

Le crash de l'application cliente n'affecte pas la BD contenant les données.

♦ Facilité de maintenance

La mise à jour de l'application ne remet pas en cause la BD et ne nécessite pas de couper temporairement l'accèsau données. Les développements d'évolution de l'application Version N peuvent se poursuivre en parallèle del'exploitation de la version N-1, sans avoir besoin de remettre à jour les données. L'extension du schémarelationnel peut se faire de façon transparente pour les applications.

♦ Sécurité

Plusieurs applications différentes peuvent utiliser la même base de données, tout en travaillant sur des tablesdifférentes.

Section A2. Création de schéma relationnel

1. LDD et création de tables sous AccessEn général la création de la base se fera en utilisant le menu "Créer une table en mode Création", puis en déclarant leschamps un par un en mode interactif.

Remarque : Création du schéma en mode interactifL'inconvénient de cette façon de créer la base est qu'il est impossible de recréer automatiquement le schéma de labase une seconde fois.

Remarque : Création du schéma en utilisant le LDDIl est possible de créer le schéma relationnel dans Access en utilisant des instructions LDD. Il faut pour cela créerune nouvelle requête, passer en mode SQL et écrire chaque requête SQL une par une. Cette solution est donc peuefficace, à moins d'avoir écrit un petit programme VBA qui lit une suite d'instructions LDD et peut ainsi procéder àla constitution complète de la base à partir d'un seul fichier externe.

Access 121

2. Domaines et types de données sous Access

2.1. Types de données♦ Texte

♦ Numérique

♦ Date/Heure

♦ Oui/Non

♦ Monétaire

♦ NuméroAuto

♦ Mémo

♦ Objet OLE

♦ Lien hypertexte

2.2. DomaineRemarqueLe domaine est un type de données pour lequel on a éventuellement ajouté certaines contraintes supplémentaires(telles que la taille du champs, la précision d'un numérique, des contraintes de validité restreingnant les valeurspossibles, la présence ou non de la valeur de nullité, etc.)

Remarque : EnumérationPour créer un type énumération, il faut partir d'un type de données standard, et restreindre le domaine aux valeursautorisées spécifiées par l'énumération. On utilise pour cela la propriété "Valide si" relative à l'attribut concerné,avec une expression du type "Valeur1 ou Valeur2 ou ValeurN".

3. Contraintes

3.1. Contraintes d'intégrité référentiellesMenu Relations♦ Menu "Outils", sous menu "Relations".

♦ Toujours cocher la case "appliquer l'intégrité référentielle"

IMG. 37 : INTÉGRITÉ RÉFÉRENTIELLE


AttentionDans Access le mot "relation" désigne en fait les contraintes d'intégrités référentielles, et non les tables comme c'estle cas dans la terminologie relationnelle. Ceci est un abus de langage.

3.2. Autres contraintesMenu Création de Table♦ Primary Key : Sélectionner le ou les attributs concernés puis choisissez menu "Edition", commande "Clé primaire"

♦ Not Null : Null interdit

♦ Unique : Indexé = Oui - Sans doublons (ou menu "Affichage", sous-menu "Index")

♦ Check : Valide si

♦ Check sur une table entière : Menu "Affichage", sous-menu "Propriétés", puis "Valide si".

4. VuesSous Access, les objets "Requête" sont en fait des vues.

5. Requêtes LDDIl est possible de spécifier des créations de schémas relationnel en utilisant le LDD de SQL classique sous Access.Pour cela créer un objet requête, puis spécifier que c'est une requête SQL LDD à l'aide du menu "Requête", sous menu"Spécifique SQL", commande "Définition de données".

Section A3. Le langage de requêtes QBE

1. Questions QBEQBE permet la création de requête LMD en mode interactif, sans écrire de code.Il faut pour cela :1. Ajouter les tables

2. Réaliser les jointures en glissant-déposant une des propriétés à joindre sur l'autre.

3. Glisser-déposer les propriétés à projeter sur la grille

4. Effectuer les restrictions sur la ligne "critère" de la grille.

Exemple : Equivalence QBE-SQL

IMG. 38 : UNE REQUÊTE QBE ANNOTÉE EN SQL

Access 123

Remarque : Jointure externePour représenter une jointure externe gauche ou droite, cliquer que le bouton "Type jointure..." après avoir créé lajointure.

IMG. 39 : UNE JOINTURE EXTERNE GAUCHE

2. Manipulation des données en QBE♦ UPDATE

Pour réaliser une requête de type UPDATE, modifier le statut de la requête avec la commande "Menu Requête / Mettre àjour une requête"

♦ INSERT

Pour réaliser une requête de type INSERT, modifier le statut de la requête avec la commande "Menu Requête / RequêteAjout"

♦ DELETE

Pour réaliser une requête de type DELETE, modifier le statut de la requête avec la commande "Menu Requête /Supprimer une requête"

Problèmes de traductionDes problèmes de traduction dans certaines versions d'Access conduisent à des formulations hasardeuses desmenus. Ainsi "Mettre à jour une requête" signifie "Requête de mise à jour" et "Supprimer une requête" signifie"Requête de supression". L'erreur de traduction vient probablement du double sens de "Update query" et "Deletequery" en anglais...

3. Clause GROUP BY en QBEAppliquer la clause GROUP BY se nomme en Access, faire un regroupement. L'interface QBE ne le permet pas par défaut, ilfaut au préalable activer le menu "opération", qui fera apparaître une ligne supplémentaire sur l'interface : "Menu Affichage /Opérations".

Exemple : Regroupement en QBE sous Access et GROUP BY en SQL

IMG. 40 : REGROUPEMENT EN QBE

SELECT Effet, Avg(Durée) AS MoyenneDeDuréeFROM TPotionGROUP BY Effet;

Remarque : HAVINGPour ajouter une clause HAVING, il suffit d'utiliser la ligne "critère" sous une propriété à laquelle est appliquée uneopération.


Section A4. Formulaires

1. Formulaire liés à une table

Formulaire liéUn formulaire lié est un formulaire qui offre un accès direct à une (et une seule) table.

Pour lier un formulaire à une table il faut désigner le nom d'une table dans la propriété "Source" du formulaire.

IMG. 41 : SOURCE D'UN FORMULAIRE

Remarque : Contrôle liéDans le cadre d'un formulaire lié, il est possible (et c'est même le seul intérêt) de créer des contrôles liés. De telscontrôles référencent directement un attribut d'une table (grâce à leur propriété "Source contrôle") et permettentdonc une saisie directe d'information dans la base sans écrire de code SQL LMD.

IMG. 42 : SOURCE D'UN CONTRÔLE

Remarque : Usage des formulaires liésIl est plutôt déconseillé de recourir aux formulaires liés, qui, s'ils offrent une première approche très simple pourcréer des interfaces de saisie, reste très limités fonctionnellement. On leur préfèrera rapidement les formulairesindépendants et les requêtes LMD de type INSERT et UPDATE.

Formulaire lié et pages multiplesUn formulaire lié, lorsqu'il est en "Mode simple" (valeur de la propriété "Affich par défaut") comporte autant de"pages" qu'il y a d'enregistrements dans la table liée.Chaque page permet de modifier l'enregistrement qu'elle matérialise, et la dernière page permet d'ajouter un nouvelenregistrement.Par défaut le fomulaire s'ouvre toujours sur le premier enregistrement, et il faut donc se déplacer après le dernierpour en ajouter un nouveau.Il faut pour cela utiliser les boutons en bas à gauche du formulaire :

Access 125

IMG. 43 : DÉPLACEMENT DANS LES DIFFÉRENTS ENREGISTREMENTS D'UN FORMULAIRE LIÉ

2. Formulaires indépendants

Formulaire indépendantsLes formulaires indépendants ne sont pas liés à une table (leur propriété "Source" est vierge).

Ils servent à récupérer des valeurs en mémoire, dans des variables, avant d'en faire un traitement par programmation(on pourra par exemple utiliser cette valeur dans une requête SQL LMD de type INSERT pour ajouter desenregistrements dans une table.Il est toujours possible de faire, avec un formulaire indépendant et une requête SQL, ce qu'il est possible de faireavec un formulaire lié (et l'on peut bien entendu faire beaucoup plus)

Remarque : Contrôles et formulaires indépendantsLes contrôles d'un formulaire indépendant ne peuvent bien entendu pas être liés à une table. Ils ne peuvent servirqu'à stocker une valeur en mémoire pour un usage donné. Ils sont de ce fait comparable à des variables.

Syntaxe : Utiliser une valeur saisie dans le contrôle d'un formulaire indépendantPour utiliser les valeurs indépendantes (en mémoire) de contrôle d'un formulaire, dans d'autres objets (formulaires, états,requêtes, macros ou modules), utiliser la syntaxe suivante :

Formulaires!NomDuFormulaire!NomDuContrôle

Exemple : Mise à jour de plusieurs tables1. Saisie de valeurs relatives à plusieurs enregistrrements, de tables différentes, dans un formulaire

2. Utilisation de ces valeurs dans des requêtes d'insertion pour ajouter les valeurs dans les tables

Exemple : Requêtes paramétrées1. Saisie de valeurs relatives à des paramètres dans un formulaire

2. Exécution d'une requête de sélection s'appuyant sur ces paramètres

SELECT * FROM TVillesWHERE Pays = Formulaires!FChoix!Pays

3. Contrôles listesLes listes déroulantes sont des contrôles très intéressants qui permettent de récupérer des valeurs dynamiques grâce à unerequête ou de spécifier des valeurs statiques parmi lesquelles l'utilisateur choisira.♦ Pour que les valeurs de la liste soit définies dynamiquement à partir du résultat d'une requête, fixer la propriété "Origine

source" à la valeur "Table/Requête", puis écrire la requête dans la propriété "Contenu".

♦ Pour que les valeurs de la liste soit définies statiquement, fixer la propriété "Origine source" à la valeur "Liste Valeurs",puis lister les valeurs en les séparant par des points-virgules dans la propriété "Contenu".


IMG. 44 : CONTENU D'UN CONTRÔLE LISTE

Remarque : Liste à plusieurs colonnesIl est possible de réaliser des listes déroulantes à plusieurs colonnes. Il suffit pour cela que la requête spécifiée dans"Contenu" projette plusieurs attributs.Il faudra dans ce cas régler correctement les propriétés "Nbre colonnes" (le nombre de colonnes) et "Colonne liée"(le numéro de la colonne principale, qui renvoie la valeur à stocker reéellement dans la variable associée aucontrôle).

Remarque : Récupération de la valeur d'une colonne d'une listeFormulaires!NomDuFormulaire!NomDuContrôleListe.column(X)

Avec X de 0 à N-1, N étant le nombre de colonnes

Section A5. Macro

1. Création de macroAttentionUn objet "macro" est en fait un objet "groupe de macro". Il faudra toujours :♦ Afficher la colonne "nom de macro" (menu Affichage / Nom de macro)

♦ Afficher la colonne "condition" (menu Affichage / Condition)

IMG. 45 : INTERFACE DE CRÉATION DE MACROS

Access 127

Une macro est définie par un nom (première colonne) et une succession d'instructions (actions dans la dernière colonne)éventuellement soumises à des conditions d'exécution (seconde colonne). Chaque action requiert de fixer un certain nombrede paramètres qui s'affiche dans la partie basse de l'interface après que l'action ait été sélectionnée.

2. Exemple d'actions macro♦ OuvrirFormulaire

Ouvre un formulaire

♦ OuvrirEtat

Ouvre un état

♦ BoîteMsg

Crée une boîte de dialogue avec l'utilisateur.

♦ AtteindreEnregistrement

Dans un formulaire lié, permet d'atteindre un enregistrement particulier.

♦ DéfinirValeur

Permet de fixer la valeur de n'importe quelle propriété d'un contrôle de formulaire. Cette action est très utile pour rendreles interfaces plus dynamiques.

♦ ExécuterMacro

Exécute une autre macro. Cette action est utile pour modulariser le code Macro (bien que sans passage de paramètres,cela reste sommaire).

♦ Fermer

Ferme un objet de type fomulaire, état, etc.

♦ TrouverEnregistrement

Dans un formulaire lié, permet de se rendre à un enregistrement particulier en fonction de la valeur de l'un de sescontrôles.

♦ AtteindreContrôle

Permet de sélectionner un contrôle particulier dans un formulaire. Cette action est utile avant d'effectuer unTrouverEnregistrement par exemple.

♦ Actualiser

Permet de rafraîchir un contrôle (après un DéfinirValeur ou pour ré-exécuter la requête source d'une liste déroulante parexemple )

♦ Avertissements

Active ou désactive les avertissements lors de l'exécution de requêtes.

♦ ExécuterCommande

Permet d'exécuter une des commandes disponible dans les menu d'Access

♦ ArrêtMacro

Stoppe la macro, sans exécuter les instructions restantes. Cette actions est utile pour terminer la macro après un test parexemple.

3. Appel des macrosLes macros sont en général appelées par des évènements particuliers survenus lors de la manipulation des formulaires et états(programmation évènementielle des formulaires et états).Les macros peuvent également être appelées par d'autres macro, voire du code VBA.

4. Macro AutoExecSi une macro porte le nom "AutoExec", elle sera exécutée automatiquement à l'ouverture de la base de données.Cette macro peut servir typiquement à afficher un menu général d'entrée dans l'application.

Remarque : Un petit truc...Pour désactiver l'exécution automatique de la macro AutoExec, maintenez la touche "shift" de l'ordinateur appuyéelors du lancement de l'application.


Section A6. Modules

1. Structure d'un programme VBA♦ Fonction (function)

Retourne une valeur, utilisable dans les requêtes, les formulaires et les états.

♦ Procédure (sub)

Effectue des opérations, en général sur les tables, notion de procédures stockées

Syntaxe{Sub | Function} nom (param1 As type, ...) {As type retourné}Dim variable1 As type...programme{End Sub | End Function}

2. Fonctions à connaître♦ Traitement de chaîne : LCase(S), UCase(S), Left(S, 1), Right(S, 1), Len(S), +, ...

♦ Génération aléatoire : Randomize, Rnd

♦ Gestion nombre : Cast : Int(),

3. Objets à connaître♦ Recordset : méthodes MoveNext, MoveFirst, MoveLast, AddNew, Update, RecordCount, !nom_champs, ...

♦ QueryDef : méthode OpenRecordset, SQL, ...

♦ CurrentDb : méthodes openRecordset, CreateQueryDef, ...

4. Normaliser des chaînes de caractèresFunction NormaliserChaine(s As String) As String

Result = ""For i = 1 To Len(s)

C = Right(Left(s, i), 1)Select Case C

Case "é", "è", "ê"C = "e"

Case "à"C = "a"

Case "ï"C = "i"

End SelectResult = Result + C

Next iResult = UCase(Left(Result, 1)) + LCase(Right(Result, Len(Result) - 1))NormaliserChaine = Result

End Function

5. Parcourir une table ou une requête stockéeSub ParcoursTable()

Set vRs = CurrentDb.OpenRecordset("MaTable")For i = 1 To vRs.RecordCount

Debug.Print vRs!MonChampsvRs.MoveNext

Next iEnd Sub

Access 129

6. Parcourir une table passée en paramètreSub ParcoursTable(pTable As String, pChamps As String)

Set vRs = CurrentDb.OpenRecordset(pTable)Set vChamps = vRs.Fields

For i = 0 To vChamps.Count - 1If vChamps(i).Name = pChamps Then NumChamps = i

Next i

For i = 1 To vRs.RecordCountDebug.Print vRs.Fields(NumChamps)vRs.MoveNext

Next iEnd Sub

7. Parcourir une table et gérer les erreursSub ParcoursTable(pTable As String, pChamps As String)

On Error GoTo Erreur_ParcoursTableSet vRs = CurrentDb.OpenRecordset(pTable)Set vChamps = vRs.Fields

For i = 0 To vChamps.Count - 1If vChamps(i).Name = pChamps Then NumChamps = i

Next i

For i = 1 To vRs.RecordCountDebug.Print vRs.Fields(NumChamps)vRs.MoveNext

Next iExit_ParcoursTable:

Exit SubErreur_ParcoursTable:

Debug.Print "Erreur"MsgBox "Erreur"

End Sub

8. Exécuter une requêteSub ExecuterRequete(pTable As String, pChamps As String)

Dim vCodeSql As String

vCodeSql = "select " + pChamps + " from " + pTableSet vRs = CurrentDb.CreateQueryDef("", vCodeSql).OpenRecordsetFor i = 1 To vRs.RecordCount

Debug.Print vRs.Fields(0)vRs.MoveNext

Next iEnd Sub

9. Créer un schéma de BD et initialiser les donnéesSub InitBD()

Const NbLignesSql As Integer = 3Dim vCodeSql(NbLignesSql) As StringvCodeSql(1) = "drop table Table1"vCodeSql(2) = "create table Table1 (Champs1 String(150))"vCodeSql(3) = "insert into Table1 (Champs1) values (""test"")"For i = 1 To NbLignesSql

CurrentDb.CreateQueryDef("", vCodeSql(i)).ExecuteNext i

End Sub

Section A7. Autres aspects

1. Gestion des droits♦ Non standard

♦ Fichier .MDW

♦ Pas simple ...


2. Run-time♦ Ca existe

Section A8. Quelques questions/réponses sur Access

Question Réponse 1. Alertes et requêtes

Comment supprimer les messages d'alertes lors de l'exécution des requêtes ?

VBADoCmd.SetWarnings False

MacroAvertissements=Non

http://access.developpez.com/faq/

Question Réponse 2. Contrôles de sous-formulaire

Comment atteindre un contrôle d'un sous formulaire ?

Exemple : Pour une zone de texteForms![NomFormulaire].form![NomSousFormulaire]![MaZoneDeText]


Question Réponse 3. Parcourir un recordset

Comment parcourir un recordset en VBA?

Rst.MoveFirstWhile not rst.EOF

' coderst.MoveNext

Wend

ou

Do Until rst.EOF' coderst.MoveNext

Loop


Question Réponse 4. DateDiff

Comment calculer la difference entre 2 dates en VBA ?

DateDiff("d", date1, date2)'donne le nombre de jour entre date1 et date2


Question Réponse 5. Debuggage VBA

Comment mettre un point d'arret dans un code VBA ?

Quand Access passe sur un point d'arrêt l'exécution du code s'arrête et attends une manoeuvre de votre part pour continuer.

Access 131

Quand le code est arrêté vous pouvez connaître la valeur des variables de votre code simplement en passant le pointeur de lasouris dessus.Vous pouvez choisir de continuer à exécuter le code en mode pas à pas en appuyant sur F8.Vous pouvez poursuivre l'exécution du code normalement avec F5.


Question Réponse 6. ! et .

Quel est la diference entre "." et "!" ?

L'opérateur "!" (point d'exclamation) indique que l'élément qui suit est défini par l'utilisateur (un élément d'une collection).Par exemple, vous pouvez utiliser l'opérateur "!" pour faire référence à un formulaire ouvert, à un état ouvert, ou à uncontrôle figurant sur un formulaire ou sur un état.L'opérateur "." (point) indique généralement que l'élément qui suit est défini par Microsoft Access. Par exemple, vous pouvezutiliser l'opérateur "." pour faire référence à une propriété d'un formulaire, d'un état, ou d'un contrôle.


En résumé...

AccessA la fois un SGBDR pour créer des BD

et un outil de développementd'applications

BDDimension relevant de la conception de

BD.

ApplicationDimension relevant de la conception

d'application.

LDD LMD IHM Programmation

Tables Requêtes Formulaires Etats Macros ModulesVBA

Exercice récapitulatif VIII. L'apprenti chimisteSoit la requête suivante exprimée en QBE sous Access :


IMG. 46 : REQUÊTE EN QBE

Question1Qu'exprime cette requête ?

Question2Ecrivez une requête équivalente en SQL.

Access 133

Cours

VITransactions

Les transactions sont une réponse générale aux problèmes de fiabilité et d'accès concurrents dans les BD, et en particulierdans les BD en mode client-serveur. Elles sont le fondement de toute implémentation robuste d'une BD. Des systèmescomme Oracle ne fonctionnent nativement qu'en mode transactionnel.

Partie A. Gestion des transactions

Objectifs pédagogiquesComprendre les principes et l'intérêt des transactionsApréhender la gestion des pannes dans les SGBDApréhender la gestion de la concurrence dans les SGBDConnaître les syntaxes SQL standard, Oracle et Access pour utiliser des transactionsMaîtriser les modalités d'utilisation des transactions

Problématique des pannes et de la concurrence

Une BD est un ensemble persistant de données organisées qui a en charge la préservation de la cohérence de ces données. Lesdonnées sont cohérentes si elles respectent l'ensemble des contraintes d'intégrité spécifiées pour ces données : contraintes dedomaine, intégrité référentielle, dépendances fonctionnelles, etc.La cohérence des données peut être remise en cause par deux aspects de la vie d'une BD :♦ La défaillance

Lorsque le système tombe en panne alors qu'un traitement est en cours, il y a un risque qu'une partie seulement desinstructions prévues soit exécutée, ce qui peut conduire à des incohérences. Par exemple pendant une mise à jour encascade de clés étrangères suite au changement d'une clé primaire.

♦ La concurrence

Lorsque deux accès concurrents se font sur les données, il y a un risque que l'un des deux accès rende l'autre incohérent.Par exemple si deux utilisateurs en réseau modifient une donnée au même moment, seule une des deux mises à jour seraeffectuée.

La gestion de transactions par un SGBD est à la base des mécanismes qui permettent d'assurer le maintien de la cohérencedes BD. C'est à dire encore qu'il assure que tous les contraintes de la BD seront toujours respectées, même en cas de panne etmême au cours d'accès concurrents.

Section A1. Transactions

1. Notion de transactionTransactionUne transaction est une unité logique de travail, c'est à dire une séquence d'instructions, dont l'exécution assure lepassage de la BD d'un état cohérent à un autre état cohérent.

Cohérence des exécutions incorrectesLa transaction assure le maintien de la cohérence des données que son exécution soit correcte ou incorrecte.

Exemples d'exécutions incorrectesL'exécution d'une transaction peut être incorrecte parce que :♦ Une panne a lieu

♦ Un accès concurrent pose un problème

♦ Le programme qui l'exécute en a décidé ainsi

2. Déroulement d'une transaction1. DEBUT

2. TRAITEMENT

- Accès aux données en lecture

- Accès aux données en écriture

3. FIN

- Correcte : Validation des modifications

- Incorrecte : Annulation des modifications

RemarqueTant qu'une transaction n'a pas été terminée correctement, elle doit être assimilée à une tentative ou une mise à jourvirtuelle, elle reste incertaine. Une fois terminée correctement la transaction ne peut plus être annulée par aucunmoyen.

3. Propriétés ACID d'une transactionUne transaction doit respecter quatre propriétés fondamentales :♦ L'atomicité

Les transactions constituent l'unité logique de travail, toute la transaction est exécutée ou bien rien du tout, mais jamaisune partie seulement de la transaction.

♦ La cohérence

Les transactions préservent la cohérence de la BD, c'est à dire qu'elle transforme la BD d'un état cohérent à un autre (sansnécessairement que les états intermédiaires internes de la BD au cours de l'exécution de la transaction respectent cettecohérence)

♦ L'isolation

Les transactions sont isolées les unes des autres, c'est à dire que leur exécution est indépendante des autres transactions encours. Elles accèdent donc à la BD comme si elles étaient seules à s'exécuter, avec comme corrolaire que les résultatsintermédiaires d'une transaction ne sont jamais accessibles aux autres transactions.

♦ La durabilité

Les transactions assurent que les modifications qu'elles induisent perdurent, même en cas de défaillance du système.

RemarqueLes initiales de Atomicité, Cohérence, Isolation et Durabilité forme le mot mnémotechnique ACID.


4. Transactions en SQLLe langage SQL fournit trois instructions pour gérer les transactions.Syntaxe : Début d'une transaction

BEGIN TRANSACTION

Cette syntaxe est optionnelle (voire inconnue de certains SGBD), une transaction étant débutée de façon implicite dèsqu'instruction est initiée sur la BD.

Syntaxe : Fin correcte d'une transactionCOMMIT TRANSACTION (ou COMMIT)

Cette instruction SQL signale la fin d'une transaction couronnée de succès. Elle indique donc au gestionnaire de transactionque l'unité logique de travail s'est terminée dans un état cohérent est que les données peuvent effectivement être modifiées defaçon durable.

Syntaxe : Fin incorrecte d'une transactionROLLBACK TRANSACTION (ou ROLLBACK)

Cette instruction SQL signale la fin d'une transaction pour laquelle quelque chose s'est mal passé. Elle indique donc augestionnaire de transaction que l'unité logique de travail s'est terminée dans un état potentiellement incohérent et donc queles données ne doivent pas être modifiées en annulant les modifications réalisées au cours de la transaction.

Remarque : ProgrammeUn programme est généralement une séquence de plusieurs transactions.

5. Exemple de transaction sous OracleExemple de gestion de compte toujours positif sur Oracle en PL/SQL

DECLAREvTotal number;

BEGINUPDATE compteSET total=total-1000WHERE nom="dupont";

SELECT total INTO vTotalFROM compteWHERE nom="dupont";

IF vTotal<0 THENROLLBACK;

ELSECOMMIT;

END IF;END;

6. Exemple de transaction sous AccessExemple de transfert financier sous Access

Sub TransactionBeginTransCurrentDb.CreateQueryDef("", "UPDATE Compte1 SET Solde=Solde+100 WHERENum=1").ExecuteCurrentDb.CreateQueryDef("", "UPDATE Compte2 SET Solde=Solde-100 WHERENum=1").ExecuteCommitTrans

End Sub

Remarque : VBA et transactionsSous Access, il n'est possible de définir des transactions sur plusieurs objets requêtes qu'en VBA.

Remarque : Transactions automatique sous AccessSous Access, toute requête portant sur plusieurs lignes d'une table est (sauf paramétrage contraire) encapsulée dansune transaction.Ainsi par exemple la requête "UPDATE Compte SET Solde=Solde*6,55957" est exécutée dans une transaction etdonc, soit toutes les lignes de la table Compte seront mises à jour, soit aucune.

Transactions 137

7. Journal des transactionsJournalLe journal est un fichier système qui constitue un espace de stockage redondant avec la BD. Il répertorie l'ensembledes mises à jour faites sur la BD (en particulier les valeurs des enregistrements avant et après mise à jour). Lejournal est donc un historique persistant (donc en mémoire secondaire) qui mémorise tout ce qui se passe sur la BD.Le journal est indispensable pour la validation (COMMIT), l'annulation (ROLLBACK) et la reprise après panne detransactions.

♦ Synonyme : Log.

Section A2. Fiabilité

1. Les pannesUne BD est parfois soumise à des défaillances qui entraînent une perturbation, voire un arrêt, de son fonctionnement.On peut distinguer deux types de défaillances :♦ Les défaillances système

ou défaillances douces (soft crash), par exemple une coupure de courant ou une panne réseau. Ces défaillances affectenttoutes les transactions en cours de traitement, mais pas la BD au sens de son espace de stockage physique.

♦ Les défaillances des supports

ou défaillances dures (hard crash), typiquement le disque dur sur lequel est stockée la BD. Ces défaillances affectentégalement les transactions en cours (par rupture des accès aux enregistrements de la BD), mais également les donnéeselles-mêmes.

Remarque : Annulation des transactions non terminéesLorsque le système redémarre après une défaillance, toutes les transactions qui étaient en cours d'exécution (pas deCOMMIT) au moment de la panne sont annulés (ROLLBACK imposé par le système). Cette annulation assure leretour à un état cohérent, en vertu des propriétés ACID [Atomique, Cohérent, Isolé, Durable] des transactions.

Remarque : Ré-exécution des transactions terminées avec succèsAu moment de la panne certaines transactions étaient peut-être terminées avec succès (COMMIT) mais non encore(ou seulement partiellement) enregistrées dans la BD (en mémoire volatile, tampon, etc.). Lorsque le systèmeredémarre il doit commencer par rejouer ces transactions, qui assurent un état cohérent de la BD plus avancé.Cette reprise des transactions après COMMIT est indispensable dans la mesure où c'est bien l'instruction COMMITqui assure la fin de la transaction et donc la durabilité. Sans cette gestion, toute transaction pourrait être remise encause.

Remarque : Unité de repriseLes transactions sont des unités de travail, et donc également de reprise.

Remarque : Défaillance des supportsTandis que la gestion de transactions et de journal permet de gérer les défaillances systèmes, les défaillances dessupports ne pourront pas toujours être gérés par ces seuls mécanismes. Il faudra leur adjoindre des procédures desauvegarde et de restauration de la BD pour être capable au pire de revenir dans un état antérieur cohérent et aumieux de réparer complètement la BD (cas de la réplication en temps réel par exemple).

2. Point de contrôlePoint de contrôleUn point de contrôle est une écriture dans le journal positionnée automatiquement par le système qui établit la listede toutes les transactions en cours (au moment où le point de contrôle est posé) et force la sauvegarde des donnéesalors en mémoire centrale dans la mémoire secondaire.Le point de contrôle est positionné à intervale de temps ou de nombre d'entrées dans le journal prédéfinis.Le dernier point de contrôle est le point de départ d'une reprise après panne, dans la mesure où c'est le dernierinstant où toutes les données ont été sauvegardées en mémoire non volatile.

♦ Synonyme : Syncpoint.


3. Reprise après panneLe mécanisme de reprise après panne s'appuie sur le journal et en particulier sur l'état des transactions au moment de la panneet sur le dernier point de contrôle.

Le schéma ci-après illustre les cinq cas de figure possibles pour une transaction au moment de la panne.

SCH. 7 : LES CINQ TYPES DE TRANSACTIONS AU MOMENT DE LA PANNE

♦ Transactions de type T1

Elles ont débuté et se sont terminées avant tc. Elles n'interviennent pas dans le processus de reprise.


Elles ont débuté avant tc et se sont terminées entre tc et tf. Elles devront être rejouées (il n'est pas sûr que les donnéesqu'elles manipulaient aient été correctement inscrites en mémoire centrale, puisque après tc, or le COMMIT impose ladurabilité).


Elles ont débuté avant tc, mais n'était pas terminées à tf. Elles devront être annulées (pas de COMMIT).


Elles ont débuté après tc et se sont terminées avant tf. Elles devront être rejouées.


Elles ont débuté après tc et ne se sont pas terminées. Elles devront être annulées.

RemarqueLes transactions sont des unités d'intégrité.

4. Algorithme de reprise UNDO-REDO.L'algorithme suivant permet d'assurer une reprise après panne qui annule et rejoue les transactions adéquates.

1. SOIT deux listes REDO et UNDO1a. Initialiser la liste REDO à vide1b. Initialiser la liste UNDO avec toutes les transactions en cours au dernier point decontrôle

2. FAIRE une recherche en avant dans le journal, à partir du point de contrôle

Transactions 139

2a. SI une transaction T est commencée ALORS ajouter T à UNDO2b. SI une transaction T est terminée avec succès alors déplacer T de UNDO à REDO

3. QUAND la fin du journal est atteinte3a. Annuler les transactions de la liste UNDO (reprise en arrière)3b. Rejouer les transactions de la liste REDO (reprise en avant)

4. TERMINER la reprise et redevenir disponible pour de nouvelles instructions

Exemple

SCH. 8 : LES CINQ TYPES DE TRANSACTIONS AU MOMENT DE LA PANNE


Non prises en compte par l'algorithme.


Ajoutées à la liste UNDO (étape 1b) puis déplacée vers REDO (étape 2b) puis rejouée (étape 3b).


Ajoutées à la liste UNDO (étape 1b) puis annulée (étape 3a).


Ajoutées à la liste UNDO (étape 2a) puis déplacée vers REDO (étape 2b) puis rejouée (étape 3b).


Ajoutées à la liste UNDO (étape 2a) puis annulée (étape 3a).

5. Ecriture en avant du journal.

On remarquera que pour que la reprise de panne soit en mesure de rejouer les transactions, la première action que doiteffectuer le système au moment du COMMIT est l'écriture dans le journal de cette fin correcte de transaction. En effetainsi la transaction pourra être rejouée, même si elle n'a pas eu le temps de mettre effectivement à jour les données dansla BD, puisque le journal est en mémoire secondaire.

* **


On voit que la gestion transactionnelle est un appui important à la reprise sur panne, en ce qu'elle assure des états cohérentsqui peuvent être restaurés.

Section A3. Concurrence

1. Trois problèmes soulevés par la concurrence.Nous proposons ci-dessous trois problèmes posés par les accès conccurents des transactions aux données.

1.1. Perte de mise à jour

Temps Transaction A Transaction B

t1 LIRE T

t2 ... LIRE T

t3 UPDATE T ...

t4 ... UPDATE T

t5 COMMIT ...

t4 COMMIT

TAB. 15 : PROBLÈME DE LA PERTE DE MISE À JOUR DU TUPLE T PAR LA TRANSACTION A

Les transaction A et B accèdent au même tuple T ayant la même valeur respectivement à t1 et t2. Ils modifient chacun lavaleur de T. Les modifications effectuées par A seront perdues puisqu'elle avait lu T avant sa modification par B.

Exemple

Temps A : Ajouter 100 B : Ajouter 10

t1 LIRE COMPTEC=1000

t2 ... LIRE COMPTEC=1000

t3 UPDATE COMPTEC=C+100=1100 ...

t4 ... UPDATE COMPTEC=C+10=1010

t5 COMMITC=1100 ...

t6 COMMITC=1010

TAB. 16 : DOUCLE CRÉDIT D'UN COMPTE BANCAIRE C

Dans cet exemple le compte bancaire vaut 1010 à la fin des deux transactions à la place de 1110.

1.2. Accès à des données non validées


t1 UPDATE T

t2 LIRE T ...

t3 ROLLBACK

TAB. 17 : PROBLÈME DE LA LECTURE IMPROPRE DU TUPLE T PAR LA TRANSACTION A

La transaction A accède au tuple T qui a été modifié par la transaction B. B annule sa modification et A a donc accédé à unevaleur qui n'aurait jamais dû exister (virtuelle) de T. Pire A pourrait faire une mise à jour de T après l'annulation par B, cettemise à jour incluerait la valeur avant annulation par B (et donc reviendrait à annuler l'annulation de B).

Transactions 141

Exemple

Temps A : Ajouter 10 B : Ajouter 100 (erreur)

t1 LIRE COMPTEC=1000

t2 UPDATE COMPTEC=C+100=1100

t3 LIRE COMPTEC=1100 ...

t4 ... ROLLBACKC=1000

t5 UPDATE CC=C+10=1110

t6 COMMITC=1110

TAB. 18 : ANNULATION DE CRÉDIT SUR LE COMPTE BANCAIRE C

Dans cet exemple le compte bancaire vaut 1110 à la fin des deux transactions à la place de 1010.

1.3. Lecture incohérente


t1 LIRE T

t2 ... UPDATE T

t3 ... COMMIT

t4 LIRE T

TAB. 19 : PROBLÈME DE LA LECTURE NON REPRODUCTIBLE DU TUPLE T PAR LA TRANSACTION A

Si au cours d'une même transaction A accède deux fois à la valeur d'un tuple alors que ce dernier est, entre les deux, modifiépar une autre transaction B, alors la lecture de A est inconsistente. Ceci peut entraîner des incohérences par exemple si uncalcul est en train d'être fait sur des valeurs par ailleurs en train d'être mises à jour par d'autres transactions.

RemarqueLe problème se pose bien que la transaction B ait été validé, il ne s'agit donc pas du problème d'accès à des donnéesnon validées.

Exemple

Temps A : Calcul de S=C1+C2 B : Transfert de 10 de C1 à C2

t1 LIRE COMPTE1C1=100

t2 ... LIRE COMPTE 1C1=100

t3 ... LIRE COMPTE 2C2=100

t4 ... UPDATE COMPTE 1C1=100-10=90

t5 ... UPDATE COMPTE 2C2=100+10=110

t6 ... COMMIT

t7 LIRE COMPTE 2C2=110

t8 CALCUL SS=C1+C2=210

TAB. 20 : TRANSFERT DU COMPTE C1 AU COMPTE C2 PENDANT UNE OPÉRATION DE CALCUL C1+C2

Dans cet exemple la somme calculée vaut 210 à la fin du calcul alors qu'elle devrait valoir 200.


2. Le verrouillage.Une solution générale à la gestion de la concurrence est une technique très simple appelée verrouillage.

VerrouPoser un verrou sur un objet (typiquement un tuple) par une transaction signifie rendre cet objet innaccessible auxautres transactions.

♦ Synonyme : Lock.

Verrou partagéUn verrou partagé, noté S, est posé par une transaction lors d'un accès en lecture sur cet objet.

Un verrou partagé interdit aux autres transaction de poser un verrou exclusif sur cet objet et donc d'y accéder enécriture.

♦ Synonymes : Verrou de lecture, Shared lock, Read lock.

Verrou exclusifUn verrou exclusif, noté X, est posé par une transaction lors d'un accès en écriture sur cet objet.

Un verrou exclusif interdit aux autres transactions de poser tout autre verrou (partagé ou exclusif) sur cet objet etdonc d'y accéder (ni en lecture, ni en écriture).

♦ Synonymes : Verrou d'écriture, Exclusive lock, Write lock.

Remarque : Verrous S multiplesUn même objet peut être verrouillé de façon partagée par plusieurs transactions en même temps. Il sera impossiblede poser un verrou exclusif sur cet objet tant qu'au moins une transaction disposera d'un verrou S sur cet objet.

Règles de verrouillageSoit la transaction A voulant poser un verrou S sur un objet O1. Si O n'est pas verrouillé alors A peut poser un verrou S

2. Si O dispose déjà d'un ou plusieurs verrous S alors A peut poser un verrou S

3. Si O dispose déjà d'un verrou X alors A ne peut pas poser de verrou S

Soit la transaction A voulant poser un verrou X sur un objet O1. Si O n'est pas verrouillé alors A peut poser un verrou X

2. Si O dispose déjà d'un ou plusieurs verrous S ou d'un verrou X alors A ne peut pas poser de verrou X

Verrou X présent Verrou(s) S présent(s) Pas de verrou présent

Verrou X demandé Demande refusée Demande refusée Demande accordée

Verrou S demandé Demande refusée Demande accordée Demande accordée

TAB. 21 : MATRICE DES RÈGLES DE VERROUILLAGE

Remarque : Promotion d'un verrouUne transaction qui dispose déjà, elle-même, d'un verrou S sur un objet peut obtenir un verrou X sur cet objet siaucune autre transaction ne détient de verrou S sur l'objet. Le verrou est alors promu du statut partagé au statutexclusif.

3. Le déverrouillage.DéverrouillageLorsqu'une transaction se termine (COMMIT ou ROLLBACK) elle libère tous les verrous qu'elle a posé.

♦ Synonyme : Unlock.

Transactions 143

4. Protocole d'accès aux données.Règles de verrouillage avant les lectures et écritures des donnéesSoit la transaction A voulant lire des données d'un tuple T :1. A demande à poser un verrou S sur T

2. Si A obtient de poser le verrou alors A lit T

3. Sinon A attend le droit de poser son verrou (et donc que les verrous qui l'en empêchent soient levés)

Soit la transaction A voulant écrire des données d'un tuple T :1. A demande à poser un verrou X sur T

2. Si A obtient de poser le verrou alors A écrit T

3. Sinon A attend le droit de poser son verrou (et donc que les verrous qui l'en empêchent soient levés)

Soit la transaction A se terminant (COMMIT ou ROLLBACK) :1. A libère tous les verrous qu'elle avait posé

2. Certaines transactions en attente obtiennent éventuellement le droit de poser des verrous

Remarque : Liste d'attenteAfin de rationnaliser les attentes des transactions, des stratégies du type FIFO [First In First Out] sont généralementappliquées et donc les transactions sont empilées selon leur ordre de demande.

5. Solution aux trois problèmes soulevés par la concurrence.Le principe du verrouillage permet d'apporter une solution aux trois problèmes classiques soulevés par les accès auxconcurrents aux données par les transactions.

5.1. Perte de mise à jour


t1 LIRE TVerrou S

t2 ... LIRE TVerrou S

t3 UPDATE TAttente... ...

t4 ...Attente...

UPDATE TAttente...

... Inter-blocage

TAB. 22 : PROBLÈME DE LA PERTE DE MISE À JOUR DU TUPLE T PAR LA TRANSACTION A

RemarqueLe problème de perte de mise à jour est réglé, mais soulève ici un autre problème, celui de l'inter-blocage.

5.2. Accès à des données non validées


t1 UPDATE TVerrou X

t2 LIRE TAttente... ...

t3 ROLLBACKLibération du verrou X

t4 Verrou S

TAB. 23 : PROBLÈME DE LA LECTURE IMPROPRE DU TUPLE T PAR LA TRANSACTION A


5.3. Lecture incohérente


t1 LIRE TVerrou S

t2 ... UPDATE TAttente...

t3 LIRE TVerrous S

...

... ... libération des verrous ... ... reprise de la transaction ...

TAB. 24 : PROBLÈME DE LA LECTURE NON REPRODUCTIBLE DU TUPLE T PAR LA TRANSACTION A

RemarqueLa lecture reste cohérente car aucune mise à jour ne peut intervenir pendant le processus de lecture d'une mêmetransaction.

6. Inter-blocageInter-blocageL'inter-blocage est le phénomène qui apparait quand deux transactions (ou plus, mais généralement deux) sebloquent mutuellement par des verrous posés sur les données. Ces verrous empêchent chacune des transactions dese terminer et donc de libérer les verrous qui bloquent l'autre transaction. Un processus d'attente sans fin s'enclenchealors.Les situations d'inter-blocage sont détectées par les SGBD et gérées, en annulant l'une, l'autre ou les deuxtransactions, par un ROLLBACK système. Les méthodes utilisées sont la détection de cyle dans un graphe d'attenteet la détection de délai d'attente trop long.

♦ Synonymes : Deadlock, Blocage, Verrou mortel.

Cycle dans un graphe d'attentePrincipe de détection d'un inter-blocage par détection d'un cycle dans un graphe représentant quelles transactionssont en attente de quelles transactions (par inférence sur les verrous posés et les verrous causes d'attente). Un cycleest l'expression du fait qu'une transaction A est en attente d'une transaction B qui est en attente d'une transaction A.La détection d'un tel cycle permet de choisir une victime, c'est à dire une des deux transactions qui sera annulée pourque l'autre puisse se terminer.

♦ Synonyme : Circuit de blocage.

Délai d'attentePrincipe de décision qu'une transaction doit être abandonnée (ROLLBACK) lorsque son délai d'attente est troplong.Ce principe permet d'éviter les situations d'inter-blocage, en annulant une des deux transactions en cause, et enpermettant donc à l'autre de se terminer.

♦ Synonyme : Timeout.

Remarque : Risque lié à l'annulation sur délaiSi le délai est trop court, il y a un risque d'annuler des transactions en situation d'attente longue, mais non bloquées.

Si le délai est trop long, il y a un risque de chute des performances en situation d'inter-blocage (le temps que lesystème réagisse).La détection de cycle est plus adaptée dans tous les cas, mais plus complexe à mettre en oeuvre.

Remarque : Relance automatiqueUne transaction ayant été annulée suite à un inter-blocage (détection de cycle ou de délai d'attente) n'a pas commisde "faute" justifiant son annulation. Cette dernière est juste dûe aux contraintes de la gestion de la concurrence.Aussi elle n'aurait pas dû être annulée et devra donc être éxécutée à nouveau.Certains SGBD se charge de relancer automatiquement les transactions ainsi annulées.

Transactions 145

Section A4. Illustrations sous Oracle

1. Validation et annulation de transactionCREATE TABLE TransTest (X number(1));Table créée.

INSERT INTO TransTest VALUES (1);1 ligne créée.

COMMIT;Validation effectuée.

INSERT INTO TransTest VALUES (2);1 ligne créée.

ROLLBACK;Annulation (rollback) effectuée.

SELECT * FROM TransTest;X-----1

2. Validation conditionnelle de transactionCREATE TABLE TransTest (X number(1));INSERT INTO TransTest VALUES (1);INSERT INTO TransTest VALUES (1);COMMIT;

SELECT * FROM TransTest;

DECLAREminX TransTest.X%TYPE;

BEGINUPDATE TransTest SET X=X-1;SELECT min(X) INTO minX FROM TransTest;IF minX < 0 THEN

ROLLBACK;ELSE

COMMIT;END IF;

END;

SELECT * FROM TransTest;

Première exécutionX---12

Procédure PL/SQL terminée avec succès.

X---01

Seconde exécutionX---01

Procédure PL/SQL terminée avec succès.

X---01


3. Simulation de panneCREATE TABLE TransTest (X number(1));INSERT INTO TransTest VALUES (1);COMMIT;

INSERT INTO TransTest VALUES (2);SELECT * FROM TransTest;

DECLAREi number(5);

BEGINi:=0;WHILE i=0 LOOP

i:=0;END LOOP;

END;

COMMIT;

ExécutionTable créée.1 ligne créée.Validation effectuée.

1 ligne créée.X---12

... Attente dans la boucle infinie ...Simulation de panne (en brisant la connection)

SELECT * FROM TransTest;X---1

4. Mises à jour concurrentesPréparation

CREATE TABLE TransTest (X number(1));INSERT INTO TransTest VALUES (1);COMMIT;

Début exécution 1UPDATE TransTest SET X=X+1 WHERE X=1;1 ligne mise à jour.


Début exécution 2SELECT * FROM TransTest;X---1

UPDATE TransTest SET X=X+1 WHERE X=1;-- ... Mise en attente ...

Fin exécution 1COMMIT;Validation effectuée.

Fin exécution 2-- ... Reprise et exécution du UPDATE.0 ligne(s) mise(s) à jour.-- NB : X ne vaut plus 1, mais 2 après le COMMIT de la première exécution

COMMIT;Validation effectuée.


Transactions 147

En résumé...

TransactionsUnité logique de travail pour assurer lacohérence de la BD même en cas de

pannes ou d'accès concurrents.

PanneMême en cas de panne, la BD

doit rester cohérente.

ConcurrenceDimension relevant de laconception d'application.

ProgrammationUn programme peut décider del'annulation d'une transaction.

DéfaillancessystèmeCoupure decourant, deréseau, etc.

Défaillancesdu

supportCrash

disque (dansce cas les

transactionspeuvent être

insuffisantes).

Perte demise à

jour

Accès àdes

donnéesnon

valides

Lectureincohérente

RollbackInstruction

SQLd'annulation

d'unetransaction.

Exercice récapitulatif IX. Opération bancaires et transactionsEnoncé n°1On désire réalisation une BD permettant de gérer les comptes bancaires des clients selon les modalités suivantes :♦ Chaque client possède un compte courant et éventuellement un compte d'épargne.

♦ Un compte est identifié par un numéro unique composé d'un numéro de pays, d'un numéro de ville (relatif au pays), d'unnuméro d'agence (relatif à la ville), et d'un numéro propre (fourni par l'agence). A des fins d'identification du compte parun opérateur humain, on gardera dans la BD un intitulé pour les pays, villes et agences.

♦ Il est possible de faire des transferts d'un compte sur l'autre

♦ Il est possible de débiter (enlever) de l'argent depuis le compte courant

♦ Il est possible de créditer (ajouter) de l'argent sur les deux comptes

♦ Les comptes doivent toujours être positifs

♦ On ne garde pas la mémoire des opérations, seules les soldes sur les comptes sont gérés

♦ Un client est décrit par son nom, son prénom, sa civilité.

Question1.1Réaliser la conception complète de la BD


Enoncé n°2Soient les évènements suivants survenants sur la BD :♦ Le client Robert Dupont est créé dans l'agence du centre ville de Compiègne, qui vient d'ouvrir.

♦ Le client Alphonse Durand est créé dans la même agence, mais il veut également un compte d'épargne sur lequel il déposetout de suite 1000€ .

♦ Le client Robert Dupont dépose deux chèques de 100€ sur son compte courant.

♦ Le client Alphonse Durand transfère 500€ de son compte d'épargne à son compte courant.

Question2.1Ecrire le code SQL permettant de traiter ces évènements, sans utiliser de transactions.

Enoncé n°3Suite à des problèmes de coupure réseaux, on constate des problèmes sur les comptes. Ainsi suite à l'exécution des opérationsprécédentes, la requête suivante renvoie des résultats érronés.

SELECT tCompteCourant.fkClient AS N, tCompteCourant.aSolde + NVL(tCompteEpargne.aSolde,0) ASSoldeDeTousComptesFROM tCompteCourant LEFT JOIN TCompteEpargne

ON tCompteCourant.fkClient=TCompteEpargne.fkClient ;

N SoldeDeTousComptes2 5001 100

Question3.1Expliquez à quoi peuvent être dus les problèmes rencontrés

IndiceLa fonction NVL renvoie comme valeur le second paramètre, si le premier à pour valeur NULL.

Question3.2Proposez une solution permettant d'assurant la cohérence des opérations, en aménageant cotre code SQL.

Transactions 149

Cours

VIIOracle

Oracle est un SGBD très intéressant du point de vue de ce cours. Historiquement c'est le premier SGBDR a avoir été mis surle marché, c'est encore aujourd'hui le leader mondial du domaine. Oracle propose une implémentation très large des principesavancées de SGBD (triggers, RO [Relationnel-Objet], etc.). Si Oracle (à l'instar des autres produits commerciaux tels queSQL Server de Microsoft ou DB2 d'IBM) est de plus en plus concurrencé par les produits Open Source (tels que PosgreSQLet MySQL), il reste un bon terrain d'apprentissage généraliste sur le sujet. Ainsi la connaissance d'Oracle permettra le passageà PosgreSQL ou MySQL sans difficulté.Les principaux inconvénients d'Oracle restent son coûts d'achat ainsi que sa complexité dès lors que l'on s'attache à desimplémentations robustes et performantes en situation réelle.

Partie A. Technologie Oracle

Présentation

♦ Le premier SGBDR commercialisé en 1979

♦ Il occupe actuellement la première place dans le marché des SGBDR (avec IBM)

♦ Evolutions du produit :- depuis la version 7, architecture client-serveur

- depuis la version 8, le serveur est objet-relationnel

- depuis la version 8i, intégration de couches applicatives Web et multimédia

- depuis la version 9i, intégration de types de données XML, extension des couches Web et introduction de fonctions dedata warehousing et de business intelligence

♦ Il fonctionne sous Unix, Linux, Windows.

♦ Site officiel en France :

♦ Il est possible de télécharger gratuitement Oracle à des fins de développement et de prototypage :

Section A1. SQL

1. Types de données♦ NUMBER(e,d)

♦ DATE

♦ CHAR(l), VARCHAR2(lmax)

♦ LONG, CLOB, BLOB, BFILE

Remarque♦ Pas de données booléennes

Pour entrer dans le détailVous pouvez consulter http://www.loria.fr/~roegel/cours/iut/oracle-sql.pdf, page 2 et 3, pour avoir une descriptionplus détaillée des types de données.

2. Particularités LMD♦ L'opération relationnelle de différence s'écrit MINUS (au lieu de EXCEPT en SQL)

♦ UNION ALL (une opération d'union qui ne supprime pas les doublons)

♦ LEFT JOIN peut s'écrire grâce à l'opérateur "(+)" utilisé dans la clause WHERE : SELECT x,y FROM t1,t2 WHEREy(+)=x;

RemarqueLes expressions mathématiques contenant une valeur Null sont systématiquement évaluées à Null.

"SELECT x+y FROM t;" renverra des valeurs Null, si x ou y ont la valeur Null.

RemarqueLe AS servant pour le renommage de colonne est optionnel.

3. Opérateur de concaténation♦ Concatène des colonnes ou chaînes de caractères avec d'autres colonnes

♦ Est représenté par deux barres verticales : ||

♦ La colonne résultante est une expression caractère

ExempleSELECT Attribut1 || Attribut2 AS "A1+A2" FROM...

4. Les séquences♦ Objet partageable, s'utilise en générale pour créer une valeur de clé primaire artificielle.

♦ Génère automatiquement des numéros uniques

Syntaxe : Création de séquenceCREATE SEQUENCE nom_sequence

Syntaxe : Valeur d'une séquencenom_sequence.CURRVAL

Syntaxe : Incrément de séquencenom_sequence.NEXTVAL

Remarque : user_sequencesTable du catalogue où se trouvent les informations concernant les séquences.

Pour entrer dans le détailVous pouvez consulter http://www.loria.fr/~roegel/cours/iut/oracle-sql.pdf, page 7, pour avoir une description plusdétaillée de la syntaxe des séquences et disposer d'exemples.


5. Fonctions à connaîtreLes fonctions "mono-ligne" :♦ Manipulent des éléments de données

♦ Acceptent des arguments et rendent des valeurs

♦ Agissent sur chaque ligne

♦ Ramènent un seul résultat par ligne

♦ Peuvent modifier les types de données

Remarque : Fonctions mono-lignePar opposition aux fonctions de calcul SQL qui s'appliquent sur toute la table pour réaliser des agrégats (en nerenvoyant qu'une seule valeur par regroupement), les fonctions "mono-ligne" sont des fonctions au sens classique,qui s'appliquent à une ou plusieurs valeurs et renvoient une valeur en retour.

On distingue les types de fonctions suivantes :♦ Traitement de chaîne

- Concat, substr, length, insrt, lpad, trim

- Lower, upper, initcap

♦ Traitement de date

- Months_between, Add_months, next_day, last_day,

- SELECT Sysdate FROM dual;

- Opérations mathématiques sur les dates : SELECT sysdate + 10 from dual

♦ Traitement numérique

- Round

- Trunc

- Mod

♦ Conversion

- Conversion implicite

- Conversion explicite : TO_DATE, TO_NUMBER, TO_CHAR

- Format :

♦ Générales

- NVL (par exemple NVL(X,0) renvoie 0 si X vaut Null)

- CASE WHEN condition1 THEN valeur1 WHEN condition2 THEN valeur2 ELSE valeur3 END

- Imbrication de fonctions : F3(F2(F1(col,arg1),arg2),arg3)

MéthodeUtiliser les fonctions mono-ligne pour :♦ Transformer les données

♦ Formater des dates et des nombres pour l'affichage

♦ Convertir des types de données de colonnes

♦ Etc.

Pour entrer dans le détailVous pouvez consulter http://www.loria.fr/~roegel/cours/iut/oracle-sql.pdf, page 9 à 12, pour avoir une descriptionplus détaillée des fonctions disponibles sous Oracle.

Oracle 153

6. Dictionnaire de donnéesCollection des tables créées et maintenues par le serveur Oracle.Contient des informations sur les objets de base de données existants.

♦ Describe nom_objet

♦ Afficher les différents types d'objets appartenant à l'utilisateur :

select object_type from user_objects;

♦ Afficher la liste des objets appartenant à l'utilisateur :

select * from user_catalog

♦ Lister les tables appartenant à l'utilisateur :

user_tables (un enregistrement par table)

Exemple : select table_name from user_tables

♦ user_sequences

♦ user_procedures

♦ user_views

Section A2. SQL*Plus

1. Présentation♦ Environnement Oracle d'exécution du SQL.

♦ L'environnement SQL*PLus ne travaille ni sur le contenu ni sur la structure.

2. Quelques commandes

2.1. Exécuter une commande dans SQL*PLUS♦ depuis le prompt SQL (terminer par / ou ;)

♦ depuis un fichier script : @ filename

2.2. Récupérer les résultats d'exécution♦ SPOOL filename

3. Paramétrage de l'affichage des états

3.1. Liste des paramètres♦ COLSEP {_ | text}

♦ FEEDBACK {6 | n |OFF | ON}

♦ HEADING {OFF | ON}

♦ LINESIZE {80 | n}

♦ PAGESIZE {24 | n}

♦ PAUSE {OFF | ON | text}

♦ TERMOUT {OFF | ON}

♦ depuis un fichier script : @ filename


3.2. Contrôler les paramètres♦ Lectures des paramètres : SHOW param

♦ Ecriture des paramètres : SET param valeur

3.3. Formattage d'une colonne de requêteSyntaxe

COLUMN nom_colonne FORMAT format

♦ Largeur de la colonne : An

♦ Chiffre (avec ou sans zéro à gauche) : 9 / 0

♦ Symboles monétaires : $ / L

♦ Séparateurs de virgule et de milliers : . / ,

♦ etc.

ExempleCOLUMN ename FORMAT A15COLUMN sal FORMAT $99,990.00COLUMN mgr FORMAT 999999999

Options supplémentaires♦ HEADING nom de l'entête

♦ JUSTIFY left | right | center

♦ NULL text

♦ etc.

Section A3. PL/SQL

1. Présentation

1.1. Description♦ Langage de programmation d'Oracle.

♦ Permet une manipulation procédurale de requêtes SQL.

1.2. Avantages♦ Intégration

Il est possible d'écrire des fonctions complexes de manipulation de données sans recourir à un langage externe.

♦ Amélioration des performances

Le code PL/SQL est très proche du moteur Oracle. De plus pour le code stocké, les requêtes qu'il manipule sontpré-compilées, et donc son exécution est optimisée.

2. Structure d'un bloc PL/SQLSyntaxe

[Declare]Variables, curseurs, etc.

BeginInstructions SQL et PL/SQL

[Exception]Gestion d'erreur.

End

Oracle 155

3. Types de bloc PL/SQL

3.1. AnonymeSyntaxe

[DECLARE]...

BEGIN...

[EXCEPTION]...

END

3.2. ProcédureSyntaxe

PROCEDURE nom_procIS

...BEGIN

...[EXCEPTION]

...END

3.3. FonctionSyntaxe

FUNCTION nom_funcRETURN type_retourné

IS...

BEGIN...RETURN valeur;

[EXCEPTION]...

END

4. Types de programmes PL/SQL

4.1. Bloc anonyme, procédure ou fonction applicativeUsage de type script, batch ou niveau applicatif.

4.2. Procédure ou fonction stockéePré-compiléSyntaxe : Procédure stockée

CREATE PROCEDURE nom_procIS...

Syntaxe : Fonction stockéeCREATE FUNCTION nom_funcIS...

4.3. TriggersBloc anonyme stockés dont l'exécution est contrôlée par des évènements sur les données.


5. Variables♦ Scalaires

VARCHAR, DATE, CHAR, LONG, BOOLEAN, INTEGER

♦ Composées

RECORD

Déclaration d'un type RECORD : TYPE nom_type IS RECORD (déclaration de propriétés);

Déclaration d'une variable enregistrement de ce type : nom_variable nom_type;

♦ Curseurs

Permettent de manipuler des résultats de requête.

6. Variables scalairesSyntaxe

identifiant [CONSTANT] type [NOT NULL] [:= valeur];

Exemplev_deptno NUMBER(2) NOT NULL := 10;v_hiredate DATE;v_location VARCHAR2(13) := 'Atlanta';c_comm CONSTANT NUMBER := 1400;

Remarque : Référence à un type de colonne existantOn peut faire référence au type d'une colonne d'une table par la syntaxe suivante en remplacement du type dedonnées :

nom_table.nom_colonne%TYPE

Exemple : Référence à un type de colonne existantExemple : vPersonne tEmploye.aNom%TYPE

7. Affectation classiqueSyntaxe

variable := valeur | variable

Exemplex:=10;x:=y;

8. Affectation par une requêteSyntaxe

SELECT propriété1, propriété2, ...INTO variable_name1, variable_name2, ...FROM relationsWHERE condition;

A condition que la requête ne renvoie qu'un tuple et qu'elle projète autant de propriétés de ce tuple que de variablesréférencées dans la clause INTO.

ExempleDECLARE

v_deptno NUMBER(2);v_loc VARCHAR2(15);

BEGINSELECT deptno, locINTO v_deptno, v_locFROM deptWHERE dname = 'SALES';...

END;

Oracle 157

Remarque : Syntaxe %TYPECette syntaxe est largement recommandée pour l'affectation depuis une requête.

Remarque : Affectation d'une variable RECORDIl est possible avec la clause INTO d'affecter des résultats de requête à plusieurs colonnes dans une variableRECORD.

9. Affichage à l'écranSyntaxe

SET SERVEROUTPUT ONBEGIN

DBMS_OUTPUT.PUT_LINE ('Hello World');END;

10. Structures de contrôle

10.1. Structure conditionnelleSyntaxe

IF THENinstructions

ELSIF THENinstructions

ELSEinstructions

END IF;

10.2. Boucle FORSyntaxe

FOR compteur IN [REVERSE] inf...sup LOOPinstructions

END LOOP;

10.3. Boucle WHILESyntaxe

WHILE condition LOOPinstructions

END LOOP;

10.4. Boucle REPEATSyntaxe

LOOPinstructionsEXIT [WHEN condition];

END;

11. La gestion d'erreur

11.1. Qu'est-ce qu'une exception ?♦ Un identifiant PL/SQL, de type erreur, déclenché pendant l'exécution du bloc

11.2. Comment est-elle déclenchée ?♦ Implicitement, par une erreur Oracle (NO_DATAFOUND, INVALID_CURSOR, TOO_MANY_ROWS, etc.)

♦ Explicitement, par le programme (défini par l'utilisateur) : commande "RAISE nom_exception"

♦ Par le développeur : Raise_application_error( -20023 , 'message')


11.3. Comment la traiter ?♦ En interceptant les exceptions

♦ En la propageant à l'environnement appelant

12. Les curseurs

12.1. Qu'est-ce qu'un curseur ?♦ Un pointeur sur un résultat de requête.

12.2. Comment l'utiliser ?DECLARE

CURSOR c_moncurseur ISSELECT prop1, prop2, propN FROM relations;

BEGINFOR c_montuple IN c_moncurseur LOOP

instructionsEND LOOP;

END;

13. Les triggers

13.1. Qu'est-ce qu'un trigger ?TriggerBloc PL/SQL associé à une table pour déclencher une action avant ou après un insert, update ou delete sur cettetable.Les triggers sont stockés dans la base.

13.2. A quoi servent les triggers ?♦ Ils permettent de renforcer l'intégrité des données (mais on préférera des contraintes "check", "unique" ou "foreign key"

quand c'est possible).

♦ Ils permettent d'auditer des actions sur une table.

♦ Ils permettent de calculer des valeurs dérivées pour d'autres colonnes de la table.

Ils constituent ainsi une des solutions pour l'implémentation des attributs dérivés.

♦ etc.

Remarque : ErreurSi l'exécution du trigger échoue, l'action (insert, update ou delete dans la table) est annulée (et retourne une erreurOracle).

14. Types de triggersIl existe deux types de triggers :♦ Trigger sur ligne

le trigger est exécuté pour chaque ligne concernée par l'instruction insert, update ou delete (option "for each row").

♦ Trigger sur instruction

le trigger est exécuté une seule fois pour l'instruction insert, update ou delete, même si elle traite plusieurs lignes d'uncoup.

Syntaxe : Triggercreate [or replace] trigger nom_trigger {before|after}[insert or][update [of nom_colonne] or][delete]on nom_Table[for each row [when (condition)] ]begin

instructionsend;

Oracle 159

Remarque : Avant ou après ?En général les triggers sont de type "before", en particulier pour les triggers sur ligne, c'est à dire qu'ils s'exécutentavant que l'action considérée soit exécutée, ce qui permet d'infléchir le résultat de cette action. Alors qu'un trigger"after" ne pourra plus modifier le tuple considéré et agira seulement sur d'autres tuples. Les triggers "after" sontrares.

Remarque : Triggers multiplesUne même table peut avoir plusieurs triggers, mais cela reste à éviter en général, pour des raisons de facilité demaintenance et de performance.

15. Instructions particulières

15.1. Manipulation des anciennes et nouvelles valeursPour les triggers de type "for each row", les anciennes et les nouvelles valeurs des colonnes de la ligne courante peuvent êtreréférencées :Syntaxe

:old.nom_colonne:new.nom_colonne

Remarque : Anciennes valeurs en lecture seuleIl n'est jamais possible de modifier une colonne ":old".

Remarque : Valeurs en lecture seule aprèsPour les trigger "after", il n'est plus possible de modifier les colonnes ":new".

Remarque : Valeurs nullesPour les triggers "on insert" les colonnes ":old" ont la valeur NULL.

Pour les triggers "on delete" les colonnes ":new" ont la valeur NULL.

AttentionIl ne faut pas modifier de données dans les colonnes des "primary key", "foreign key", ou "unique key" d'une table.

AttentionIl ne faut pas lire des données d'une table en cours de modification autrement que par les accès ":old" et ":new".

15.2. Prédicats d'évènement♦ INSERTING

♦ DELETING

♦ UPDATING

♦ UPDATING(nom_colonne)

Prédicats pour savoir dans quel contexte d'appel du trigger on est, ce qui permet dans un même trigger de s'adapter auxdifférents cas de déclenchement.


Section A4. Exemple

1. Définition de donnéesCréation des tables

CREATE TABLE tIntervenant (pkNom char(20) primary key,aPrenom char(20) not null,aPoste number(4),aBureauCentre char(2) check (aBureauCentre='BF' or aBureauCentre='R' oraBureauCentre='PG'),aBureauBat char(1) check (aBureauBat>'A' and aBureauBat<'M'),aBureauNum number(3));

CREATE TABLE tCours (pkAnnee number(4) check (pkAnnee>2000 and pkAnnee<2100),pkSemestre char(1) check (pkSemestre='A' or pkSemestre='P'),pkNum number(2),aTitre char(50),aType char(2) check (aType='C' or aType='TD' or aType='TP') not null,aContenu char(300),fkIntervenant char (20) references tIntervenant(pkNom) not null,aDateDebut date,aDateFin date,aDuree number(1) check (aDuree>0 and aDuree<5),PRIMARY KEY(pkAnnee, pkSemestre, pkNum));

Création de séquenceCREATE SEQUENCE tCoursSeq;

TestsDESCRIBE tCours;

Nom NULL? Type---------------------------PKNOM NOT NULL CHAR(20)APRENOM NOT NULL CHAR(20)APOSTE NUMBER(4)ABUREAUCENTRE CHAR(2)ABUREAUBAT CHAR(1)ABUREAUNUM NUMBER(3)

SELECT sequence_name FROM user_sequences;

SEQUENCE_NAME------------------------TCOURSSEQ

2. TriggersCalcul de valeur dérivée

CREATE TRIGGER trCoursafter insert on tCoursBEGIN

UPDATE tCoursSET aDateFin=aDateDebut+5;

END;/

Archivage de donnéesCREATE TABLE tIntervenantSav (

pkNom char(20) primary key,aPrenom char(20) not null);

CREATE TRIGGER trIntervenantafter delete or insert on tIntervenantfor each rowBEGIN

IF deleting THENinsert into tIntervenantSav values (:old.pkNom, :old.aPrenom);

ELSIF inserting thendelete from tIntervenantSav where pkNom = :new.pkNom;

END IF;END;/

Oracle 161

3. FonctionsEtude de lien inverse

CREATE FUNCTION fIntervient (pIntervenant varchar2)RETURN varchar2

ISvNbInterventions number;

BEGINSELECT Count(fkIntervenant) INTO vNbInterventionsFROM tCoursWHERE fkIntervenant=pIntervenant;

IF vNbInterventions > 0 THENRETURN 'OUI';

ELSERETURN 'NON';

END IF;END;/

Renvoi de la date du jourCREATE FUNCTION fDateDuJour RETURN dateIS

vDate date;BEGIN

SELECT Sysdate into vDate from dual;RETURN vDate;

END;/

4. Initialisation de donnéesAjout de données

INSERT INTO tIntervenant (pkNom, aPrenom, aPoste)VALUES ('CROZAT', 'STEPHANE', '4287');

INSERT INTO tCours (pkAnnee, pkSemestre, pkNum, aTitre, aType, aDateDebut, fkIntervenant)VALUES ('2003', 'P', tCoursSeq.NEXTVAL, 'Introduction','C', '01-JAN-2001', 'CROZAT');

INSERT INTO tCours (pkAnnee, pkSemestre, pkNum, aTitre, aType, aDateDebut, fkIntervenant)VALUES ('2003', 'P', tCoursSeq.NEXTVAL, 'Introduction','C', '01-JAN-2001', 'CROZAT');

SELECT pkNum, aDateFin FROM tCours;

PKNUM ADATEFIN--------------1 06/01/012 06/01/01

Suppression de donnéesDELETE FROM tCours;DELETE FROM tIntervenant;

SELECT * FROM tIntervenantSav;

PKNOM APRENOM--------------------CROZAT STEPHANE

INSERT INTO tIntervenant (pkNom, aPrenom, aPoste)VALUES ('CROZAT', 'Stephane', '4287');

SELECT * FROM tIntervenantSav;

aucune ligne sélectionnée

Reprise de donnéesINSERT INTO tCours (pkAnnee, pkSemestre, pkNum, aTitre, aType, aDateDebut, fkIntervenant)VALUES ('2003', 'P', tCoursSeq.CURRVAL, 'Introduction','C', fDateDuJour(), 'CROZAT');

SELECT pkNum FROM tCours;

PKNUM----------2


5. ProcéduresAjout de données et exception

CREATE PROCEDURE pInsertIntervenant (pNom varchar2, pPrenom varchar2)ISBEGIN

INSERT INTO tIntervenant (pkNom, aPrenom)VALUES (pNom, pPrenom);

EXCEPTIONwhen DUP_VAL_ON_INDEX then

DBMS_OUTPUT.PUT_LINE('Intervenant déjà existant : ' || pNom);when others then

RAISE;END;/

Traitement de données et curseurCREATE PROCEDURE pAfficheIntervenantsIS

CURSOR cIntervenants ISSELECT pkNom, aPrenom FROM tIntervenant;

vNom varchar2(20);vPrenom varchar2(20);

BEGINDBMS_OUTPUT.PUT_LINE('** Liste des intervenants **');OPEN cIntervenants;LOOP

FETCH cIntervenants INTO vNom, vPrenom;EXIT WHEN cIntervenants%NOTFOUND;DBMS_OUTPUT.PUT_LINE('-' || vPrenom || vNom);

END LOOP;END;/

6. QuestionsMise en forme d'état

SET LINESIZE 100SET PAGESIZE 100COLUMN Titre FORMAT A30COLUMN Intervenant FORMAT A30COLUMN aDateDebut HEADING DuCOLUMN aDateFin HEADING AuCOLUMN Sem FORMAT A5

SELECT pkSemestre||pkAnnee AS Sem,aTitre AS Titre,INITCAP(pkNom||aPrenom) AS Intervenant,aDateDebut, aDateFin

FROM tCours, tIntervenantWHERE fkIntervenant=pkNom;

SEM TITRE INTERVENANT Du Au----------------------------------------------P2003 Introduction Crozat Stephane 29/03/03 03/04/03

Utilisation de fonctionCOLUMN pkNom HEADING Nom FORMAT A20COLUMN I HEADING Intervient FORMAT A10

SELECT pkNom, fIntervient(pkNom) AS I FROM tIntervenant;

Nom Intervient--------------------CROZAT OUIJouglet NON

Agrégat et jointure gaucheUPDATE tCours SET aDuree=2;

SELECT pkNom, sum(NVL(aDuree,0)) AS ChargeFROM tIntervenant, tCoursWHERE fkIntervenant (+)= pkNomGROUP BY pkNom;

Nom CHARGE--------------------CROZAT 2Jouglet 0

Oracle 163

7. ScriptsExécution

SET SERVEROUTPUT ON

@ "C:\nf17.oracle\nf17.ldd.sql";@ "C:\nf17.oracle\nf17.ldd.fonctions.sql";@ "C:\nf17.oracle\nf17.lmd.init.sql";@ "C:\nf17.oracle\nf17.lmd.question.sql";

Test de procéduresBEGIN

DBMS_OUTPUT.PUT_LINE('*** Programme indépendant ***');pInsertIntervenant('Jouglet', 'Antoine');pAfficheIntervenants;

EXCEPTIONwhen others thenRAISE;

END;/

Section A5. Pratique d'Oracle

Exercice n°19. Dictionnaire de donnéesOn souhaite créer la table EMPLOYEE de telle façon que le dictionnaire de données graphique d'Oracle affiche le tableauci-dessous.

IMG. 47 : LA TABLE EMPLOYEE

Question1Ecrivez le code SQL pour créer cette table sous Oracle.

Question2Vérifier que la table a bien été créée.

IndiceUtiliser DESCRIBE.

Question3Modifier la table EMPLOYEE pour pouvoir allonger les noms de famille des employés à 50 caractères. Vérifiezcette modification.

Question4Vérifiez l'existence de la table EMPLOYEE dans le dictionnaire de données.

IndiceFaites une requête de sélection sur la table du dictionnaire USER_TABLES.

Question5Ajouter une contrainte PRIMARY KEY de niveau de table dans la table EMPLOYEE en utilisant la colonne ID.

Question6Vérifier que la contrainte a bien été ajoutée en utilisant la table USER_CONSTRAINTS ainsi que dans le modegraphique.


Question7Rechercher les noms et types d'objets dans la vue USER_OBJECTS du dictionnaire de données correspondant à latable EMPLOYEE.

Question8Modifier la table EMPLOYEE. Ajouter une colonne SALARY de type NUMBER avec une précision 7.

Question9Renommez la table EMPLOYEE en EMPLOYEE2.

Question10Supprimez la table EMPLOYEE2.

Exercice n°20. SQL sous OraclePour chacune des questions suivantes, écrivez le code SQL permettant de répondre à la question sous Oracle. On considère latable "emp" décrite ci-dessous.

emp (ename, job, hiredate, sal)

Question1A partir de la table "emp", afficher le nom des employés ("ename") concaténé avec leur poste ("job") en les séparantpar une virgule suivi d'une espac et donner comme titre à la colonne "EMPLOYE ET FONCTION"

Question2Afficher le nom et la date d'embauche ("hiredate") des employés embauchés entre le 20 février 1981, et 1 mai 1981.Classez le résultat par date d'embauche.

IndiceAttention à l'utilisation du format "YY" qui pose des problème vis à vis du passage à l'an 2000, préférer le format"YYYY".

Question3Afficher le nom de tous les employés, dont le nom contient deux fois la lettre "L".

Question4Afficher le nom, poste et salaire ("sal') de tous les personnes qui ont comme poste 'Clerk' ou 'Analyst' et dont lesalaire est différent de $1000, $3000, ou $5000.

Question5Afficher le nom de chaque employé et calculer le nombre de mois qu'il a travaillé jusqu'à ce jour (après l'avoirarrondi celui-ci à la plus proche valeur entière). Nommer la colonne MONTHS_WORKED.

Question6Ecrivez la requête qui affiche pour chaque employé le résultat suivant :

"X" gagne "Y" par mois mais il veut "3 fois Y".Nommer la colonne SALAIRES DE REVES.

Question7Afficher le salaire maximum, minimum, la somme des salaires et le salaire moyen de tous les employés. Nommerles colonnes respectivement Maximum, Minimum, Sum, and Average. Arrondissez les résultats à zéro décimales.

Oracle 165

En résumé...

Oracle

SQLDéfinition de la structure et du

contenu de la BD.

SQL*PlusEnvironnement d'exécution duSQL, de scripting simple et deformattage des résultats des

requêtes.

PL/SQLProgrammation procéduralesavancée des accès à la BD.

SQLstandard

Extensions Lignede

commande

Fichiersde

commandeexternes

Etatstextuels

Blocsanonymes

Procédureset

fonctions

Triggers


Cours

VIIIRelationnel-objet

Si le modèle logique relationnel a prouvé sa puissance et sa fiabilité au cours des 20 dernières années, les nouveaux besoinsde l'informatique industrielle ont vu l'émergence de structures de données complexes mal adaptées à une gestionrelationnelle. La naissance du courant "orienté objet" et des langages associées (Java et C++ par exemple) ont doncégalement investi le champ des SGBD afin de proposer des solutions pour étendre les concepts du relationnel et ainsi mieuxrépondre aux nouveaux besoins de modélisation.

Partie A. Relationnel-objet

Section A1. Introduction : R, OO, RO

Objectifs pédagogiquesComprendre les limites du modèle relationnelComprendre pourquoi et comment le modèle relationnel peut être étendu

1. Les atouts du modèle relationnel♦ Fondé sur une théorie rigoureuse et des principes simples

♦ Mature, fiable, performant

♦ Indépendance programme et données

♦ SGBDR : les plus utilisés, connus, maîtrisés

♦ SQL une implémentation standard du modèle relationnel, avec des API [Application Program Interface] pour la plupartdes langages de programmation

♦ Les SGBDR incluent des outils performants de gestion de requêtes, de générateurs d'applications, d'administration,d'optipmisation, etc, ...

2. Les inconvénients du modèle relationnel♦ La structure de donnée en tables est pauvre d'un point de vue de la modélisation logique

♦ Le mapping MCD vers MLD entraîne une perte de sémantique

♦ La manipulation de structures relationnelles par des langages objets entraîne une impedance mismatch, c'est à dire undécalage entre les structures de données pour le stockage et les structures de données pour le traitement (ce qui impliquedes conversions constantes d'un format à l'autre)

♦ La 1NF est innapropriée à la modélisation d'objets complexes

♦ La normalisation entraîne la genèse de structures de données complexes et très fragmentées, qui peuvent notamment poserdes problèmes de performance ou d'évolutivité

♦ Le SQL doit toujours être combiné à d'autres langages de programmation pour être effectivement mis en oeuvre

♦ La notion de méthode ne peut être intégrée au modèle logique, elle doit être gérée au niveau de l'implémentation physique

♦ Les types de données disponibles sont limités et non extensibles

3. Les SGBDOOLes SGBDOO ont été créés pour gérer des structures de données complexes, en profitant de la puissance de modélisation desmodéles objets et de la puissance de stockage des BD classiques.

Objectifs des SGBDOO :♦ Offrir aux langages de programmation orientés objets des modalités de stockage permanent et de partage entre plusieurs

utilisateurs

♦ Offrir aux BD des types de données complexes et extensibles

♦ Permettre la représentation de structures complexes et/ou à taille variable

Avantages des SGBDOO :♦ Le schéma d'une BD objet est plus facile à appréhender que celui d'une BD relationnelle (il contient plus de sémantique, il

est plus proche des entités réelles)

♦ L'héritage permet de mieux structurer le schéma et de factoriser certains éléments de modélisation

♦ La création de ses propres types et l'intégration de méthodes permets une représentation plus directe du domaine

♦ L'identification des objets permet de supprimer les clés artificielles souvent introduites pour atteindre la 3NF et donc desimplifier le schéma

♦ Les principes d'encapsulation et d'abstraction du modèle objet permettent de mieux séparer les BD de leurs applications(notion d'interface).

Inconvénient des SGBDOO :♦ Gestion de la persistance et de la coexistence des objets en mémoire (pour leur manipulation applicative) et sur disque

(pour leur persistance) complexe

♦ Gestion de la concurrence (transactions) plus difficile à mettre en oeuvre

♦ Interdépendance forte des objets entre eux

♦ Gestion des pannes

♦ Complexité des systèmes (problème de fiabilité)

♦ Problème de compatibilité avec les SGBDR classiques

ExplicationLes SGBDOO apportent donc des concepts fondamentaux pour l'évolution des BD, mais leur réalité est encore engrande partie du domaine de la recherche ou d'applications "de niche".Ils apportent donc une innovation sur des aspects que les SGBDR ne savent pas faire, mais sans être au mêmeniveau sur ce que les SGBDR savent bien faire.

"http://www.w3architect.com/static/people/fgaillard/these/04-LesSGBDO.html", Les bases de données objet, GAILLARD F,février, 2004.


Une description des principes et apports des SGBDOO, en perspectives des autres modèles de gestion de données.

4. Les SGBDROLes SGBDRO sont nés du double constat de la puissance nouvelle promise par les SGBDOO et de l'insuffisance de leurréalité pour répondre aux exigences de l'industrie des BD classiques. Leur approche est plutôt d'introduire dans les SGBDRles concepts apportés par les SGBDOO plutôt que de concevoir de nouveaux systèmes.

Objectifs additionnels des SGBDRO :♦ Gérer des données complexes (temps, géo-référencement, multimédia, types utilisateurs, etc.)

♦ Rapprocher le modèle logique du modèle conceptuel

♦ Réduire l'Impedance mismatch

Section A2. Le modèle relationnel-objet

Objectifs pédagogiquesConnaître les caractéristiques principales du modèle relationnel-objetComprendre les avantages du modèle relationnel-objet

1. Les SGBDROModèle relationnel-objetModèle relationnel étendu avec des principes objet pour en augmenter les potentialités.

♦ Synonyme : Modèle objet-relationnel.

Les apports principaux du modèle relationnel-objet sont :♦ Les types utilisateurs et l'encapsulation (recours aux méthodes)

♦ La gestion de collections

♦ L'héritage et la réutilisation

♦ L'identité d'objet et les références physiques

2. Le modèle imbriqué♦ nested model

♦ La 1NF est relachée pour permettre d'affecter des valeurs non atomiques à un attribut, pour modéliser des objetscomplexes.

♦ Gestion directe des attributs multivalués, sans passer par une nouvelle relation

♦ Gestion directe des attributs composés

♦ Un attribut ne sera plus seulement valuée par une valeur simple, mais pourra l'être par une collection d'objets complexes

Exemple

IMG. 48 : EXEMPLE DE TABLE IMBRIQUÉE

Relationnel-objet 169

3. Les types utilisateursType de données utilisateurType de données créé par le concepteur d'un schéma relationnel-objet, qui encapsule des données et des opérationssur ces données. Ce concept est à rapprocher de celui de classe d'objets.

♦ Synonymes : Type utilisateur, Type de données abstrait.

SyntaxeType nom_type : <

attribut1 typeattribut1,attribut2 typeattribut2,...attributN typeattributN,=methode1 (paramètres) typeretourné1,=methode2 (paramètres) typeretourné2,=...=methodeN (paramètres) typeretournéN

>

RemarqueLes type des attributs ou des méthodes d'un type peuvent également être des types utilisateurs.

Exemple : Adresse en relationnelemploye (nom:chaîne, prenom:chaîne, ad_num:chaîne, ad_rue:chaîne, ad_ville:chaîne,ad_cp:chaîne, ad_ville:chaîne, ad_pays:chaîne, societe=>societe)

societe (nom:chaîne, ad_num:chaîne, ad_rue:chaîne, ad_ville:chaîne, ad_cp:chaîne,ad_ville:chaîne, ad_pays:chaîne)

Exemple : Adresse en relationnel-objet avec typeType adresse : <num:chaîne, rue:chaîne, ville:chaîne, cp:chaîne, ville:chaîne,pays:chaîne>

employe (nom:chaîne, prenom:chaîne, ad:adresse, societe=>societe)

societe (nom:chaîne, ad:adresse)

Exemple : Type adresse avec méthodeType adresse : <num:chaîne,

rue:chaîne,ville:chaîne,cp:chaîne,ville:chaîne,pays:chaîne,=CPprefixé() chaîne

>

Remarque : Première forme normaleLe recours aux types utilisateurs brise une règle de la première forme normale, celle de l'atomicité des valeursd'attribut.Ce non respect de la 1NF ne pose pas de problème car la déclaration de type permet d'accéder à la structure internedes attributs composés.Dans le modèle relationnel classique, le problème du non respect de la 1NF était bien l'opacité de la structureinterne des attributs ainsi constitués qui interdisait l'accès à des sous informations extraites de la valeur de l'attribut(par exemple un attribut comprenant le nom et le prénom ensemble interdit l'accès à l'information "nom" ou àl'information "prénom" indépendamment). L'usage de type éclaire cette opacité et rend ainsi le respect de l'atomicitésuperflu.

4. Les collectionsCollectionUne collection est un type de données générique défini afin de supporter les attributs multi-valués.

♦ Synonyme : Collection d'objets.


SyntaxeType nom_type : collection de <type_objet>

RemarqueLes objets d'une collection peuvent être d'un type utilisateur.

Exemple : Collection d'entiersType liste_telephone : collection de <entier>

Exemple : Collection d'objets complexeType adresse : <num, rue, ville>Type liste_adresse : collection de <adresse>

5. Comparaison relationnel et relationnel-objetExemple : Documents en relationnel

document (ISBN:entier, titre:chaîne, soustitre:chaîne, editeur:chaîne, annee:entier)

auteur (id:entier, nom:chaîne, prenom:chaîne)

motscles (document=>document, motcle=>motcle

auteurslivres(idauteur=>auteur, ISBN=>document

Exemple : Documents en relationnel-objetType titre : <titre, soustitre>Type edition : <titre, soustitre>Type liste_motscles : collection de <chaîne>Type liste_auteurs : collection de <auteur>Type auteur : <nom, prenom>

document (ISBN, titre:titre, edition:edition, motscles:liste_motscles,auteurs:liste_auteurs)

Remarque : Perte de sémantiqueLa transformation précédente du modèle initiale, a éliminé l'entité auteur. La notion d'auteur n'est donc plus qu'unepropriété des livres et non un objet défini indépendamment dans le schéma de donnée. Dans le cas général cettemodélisation ne sera pas souhaitable et on préfèrera conserver l'entité auteur. Bien entendu l'existance préalable d'unschéma conceptuel permet de lever l'ambiguïté puisque selon que les auteurs seront définis commes des entités oubien comme des propriétés de l'entité livre, le choix de modélisation sera effectué.

Exemple : Documents et auteurs en relationnel-objetType titre : <titre, soustitre>Type edition : <titre, soustitre>Type liste_motscles : collection de <chaîne>Type liste_auteurs : collection de <number>

document (ISBN, titre:titre, edition:edition, motscles:liste_motscles,auteurs:liste_auteurs)

auteur (id:entier, nom:chaîne, prenom:chaîne)

Remarque : Association N:M imbriquéeDans l'exemple ci-dessus, le schéma relationnel-objet a permis de se débarrasser de la table "auteurslivres" dumodèle initial et qui n'existait que pour modéliser l'association N:M entre les livres et les auteurs. Dans l'exempleci-dessus l'utilisation d'une collection a permis de simplifier le schéma en le débarassant de cette relation artificielle.Notons néanmoins que le fait d'avoir choisi d'imbriquer les auteurs dans les livres (et non l'inverse qui étaitégalement possible) est porteur de sens tant au niveau conceptuel (ce sont plutôt les livres qui nous intéressent queles auteurs), qu'au niveau opérationnel (il sera plus facile et plus efficace de trouver les auteurs d'un livre que leslivres d'un auteur).


On conseillera de consulter l'exemple (pages 331-338) qui offre une comparaison entre deux implémentations, unerelationnelle et une relationnelle-objet, d'un même modèle conceptuel (UML).


6. Tables d'objetsUne table peut être définie en référençant un type de données plutôt que par des instructions LDD classiques.On parle alors de table d'objets.

Syntaxenom_table de nom_type (attributs_clés)

Remarque : OIDUne telle définition de table peut permettre d'identifier les objets par un OID [Object Identifier]

Remarque : HéritageCette modalité de définition de schéma permet de profiter de l'héritage de type pour permettre l'héritage de schémade table.

7. Héritage et réutilisation de types

Héritage de typeUn type de données utilisateur peut hériter d'un autre type de données utilisateur.

SyntaxeType sous_type hérite de type : <

attributs et méthodes spécifiques>

Remarque : Héritage de schéma de tablePour qu'une table hérite du schéma d'une autre table, il faut définir les tables depuis des types.

L'héritage entre les types permet ainsi l'héritage entre les schémas de table.

8. Identification d'objets et référencesLe modèle relationnel-objet permet de disposer d'identificateurs d'objet (OID)Caractéristiques♦ L'OID est une référence unique pour toute la base de données qui permet de référencer un enregistrement dans une table

d'objets.

♦ L'OID est une référence physique (adresse disque) construit à partir du stockage physique de l'enregistrement dans la basede données.

Avantages♦ Permet de créer des associations entre des objets sans effectuer de jointure (gain de performance).

♦ Fournit une identité à l'objet indépendamment de ses valeurs (clé artificielle).

♦ Fournit un index de performance maximale (un seul accès disque).

♦ Permet de garder en mémoire des identificateurs uniques dans le cadre d'une application objet, et ainsi gérer la persistanced'objets que l'on ne peut pas garder en mémoire, avec de bonnes performances (alors que sinon il faudrait exécuter desrequêtes SQL pour retrouver l'objet)[Voir exemple "Cadre d'usage" ci-après].

Inconvénient♦ Plus de séparation entre le niveau logique et physique.

♦ L'adresse physique peut changer si le schéma de la table change (changement de la taille d'un champs par exemple)

♦ Manipulation des données plus complexes, il faut un langage applicatif au dessus de SQL pour obtenir, stocker et gérerdes OID dans des variables.

Exemple : Cadre d'usageL'usage d'OID est pertinent dans le cadre d'applications écrites dans un langage objet, manipulant un très grandnombre d'objets reliés entre eux par un réseau d'associations complexe.


En effet si le nombre d'objets est trop grand, les objets ne peuvent tous être conservés en mémoire vive parl'application objet qui les manipule. Il est alors indispensable de les faire descendre et remonter en mémoirerégulièrement. Or dans le cadre d'un traitement portant sur de très nombreux objets, la remonté en mémoire d'unobjet est un point critique en terme de performance. A fortiori si l'identification de l'objet à remonter demande uneinterrogation complexe de la BD, à travers de nombreuses jointures. Le fait d'avoir conservé en mémoire un OIDpermet de retrouver et de recharger très rapidement un objet, sans avoir à le rechercher à travers des requêtes SQLcomportant des jointures et donc très couteuses en performance.

Remarque : Débatla communauté des BD est plutôt contre les OID, qui rompent avec la séparation entre manipulation logique etstockage physique des données.La communauté objet est à l'origine de l'intégration des OID dans SQL3, en tant qu'ils sont une réponse auproblème de persistence dans les applications objets.

Syntaxe : Référence en utilisant l'OIDDans une définition de table ou de type :

attribut REF nom_table_d_objets

Section A3. Mapping E-A vers relationnel-objet

Objectifs pédagogiquesSavoir déduire un modèle logique relationnel-objet depuis un modèle conceptuel E-A ou UML.Intégrer les apports du modèle relationnel-objet par rapport au relationnel dans ce processus

1. EntitéPour chaque entité, créer un type d'objet avec les attributs de l'entité.Créer une table d'objets de ce type pour instancier l'entité, en ajoutant les contraintes d'intégrité.

Remarque : Table d'objetLa fait d'instancier l'entité via une table d'objets plutôt qu'une relation classique, permet l'accès à l'héritage de type,à l'implémentation des méthodes de l'entité et éventuellement à l'usage d'OID à la place de clés étrangèresclassiques.Si aucun de ces aspects n'est utilisé, il est possible d'instancier directement l'entité en table. Mais le passage par untype est a priori plus systématique.

Remarque : Mapping des méthodesSi le modèle conceptuel autorise l'expression de méthodes (UML ou extension de E-A), alors on ajoute la définitionde ces méthodes sur le type d'objet créé pour de chaque entité (ou classe).

2. Attributs compositesPour chaque type d'attribut composé, créer un type d'objet.

3. Attributs multi-valuésPour chaque attribut multi-valué créer une collection du type de cet attribut.

Remarque : Attributs composites multi-valuésSi l'attribut multi-valué est composite, alors créer une collection d'objets.

4. Attributs dérivésPour chaque attribut dérivé créer une méthode associée au type d'objet de l'entité.

5. Association 1:NLes associations 1:N sont gérées comme en relationnel.On peut néanmois favoriser l'usage d'objets pour les clés étrangères composées de plusieurs attributs, ainsi que pour lesattributs migrants de l'association vers le relation côté N.Il est aussi possible de gérer la clé étrangère avec un OID à la place d'une clé étrangère classique.


6. Association N:MLes associations N:M peuvent être gérées comme en relationnel.Il est aussi possible de gérer ces relations, en utilisant une collection de références (une collection de clés étrangères) (NB :on favorise ainsi une des deux relations).Il est aussi possible de gérer ces relations en utilisant un OID comme clé étrangère.Il est aussi possible de gérer ces relations en utilisant une collection de référence OID.

Remarque : Collection de clés étrangèresOracle n'autorise pas (à ma connaissance ...) la spécification de contraintes d'intégrité référentielle dans une tableimbriquée. Ce qui limite l'utilisation de telles tables pour gérer des relations N:M avec des collections de clésétrangères.Par contre cela fonctionne avec des références à des OID.

7. HéritageL'héritage est géré comme en relationnel classique, avec la possibilité de profiter de l'héritage de type pour éliminer laredondance dans la définition des schémas.

En résumé...

Types

Pré-définis Définis par l'utilisateur

Domainesclassiques

Chaîne, Entier, Date,Booléen, etc.

RelationComme dans le

modèle relationnelclassique

ObjetsTypes utilisateurs

CollectionsTables imbriquées

Partie B. Quelques questions/réponses sur le relationel-objet

Question Réponse 1. Association 1:NQuand on a une association 1:N entre deux classes (par exemple une equipe a plusieurs athlètes)est-ce qu'il faut : creer un nouvel attribut dans athlète qui soit une référence à l'équipe ou biencréer une nested table d'athlètes dans équipe?

En général il est préférable de transformer comme pour le relationnel, avec une clé étrangère. Il est néanmoinspossible d'utiliser des nested tables, mais dans ce cas les tuples de la table côté N deviennent de simples attributs(composites) de la table côté 1 (il ne pourront plus être référencés à leur tour par exemple). Si cela ne pose pas deproblème et que cela simplifie l'implémentation, le modèle imbriqué peut être choisi à la place du référencement parla clé étrangère.


Question Réponse 2. Association M:NLorsqu"il y a une association N:M entre deux classes, et que l'on transforme passe en relationnel,il y a une liste de clé étrangères (collection de références) dans une des relations et pas dansl'autre, pourquoi ?

Lorsque l'on choisit une transformation de l'association N:M par une collection de références, la référence ne se faitque dans un sens, au choix, le sens inverse peut-être retrouvé par parcours de la table référençante. Bien sûr, dans cecas, une relation est favorisée par rapport à l'autre en terme de performance de recherche notamment.Recopier la référence dans les deux sens n'est pas souhaitable, car elle introduit de la redondance, mais l'on peutnéanmoins le faire si les performances l'exige et si l'on contrôle cette redondance.

Question Réponse 3. Association M:N

Est ce que l'on peut transformer une association M:N comme pour le relationnel, mais enremplaçant les clé étrangère par des références à des OID ?

Oui, c'est une des quatres solutions possibles.

Exercice récapitulatif X. Passage UML vers relationnel-objetEcrivez les règles de traduction d'un diagramme de classe UML en modèle logique relationnel-objet.

Question1Transformation des classes instanciables et abstraites

Question2Transformation des associations, en fonction des cardinalités. Transformation des compositions. Transformation desclasses d'association.

Question3Transformation des attributs, en gérant les attributs multi-valués et dérivés.

Question4Transformation des relations d'héritage.

Question5Transformation des méthodes.


Cours

IXSGBDRO

Objectifs pédagogiquesConnaître les extensions SQL proposées par l'implémentation du modèle relationnel-objetSavoir implémenter un modèle logique exprimé en relationnel-objet dans un SGBDRO

Les SGBDRO sont un compromis entre les SGBDR classiques, fiables et puissants, mais limités conceptuellement pour lagestion de données complexes et les SGBDOO conceptuellement très intéressant, mais technologiquement limités pour desapplications industrielles classiques.Oracle propose à partir de sa version 8 et plus encore depuis la 9i des extensions qui permettent une implémentation demodèle logique relationnel-objet. Ce nouveau modèle, encore naissant dans le monde industriel, semble promis à un avenirintéressant et d'autres systèmes, comme PosgreSQL, en proposent également des implémentations évoluées.

Partie A. Implémentation du RO

Section A1. SQL3 (implémentation Oracle 9i)

Objectifs pédagogiquesConnaître l'extension du LDD, et en particulier les types abstrait, les relations imbriquées et l'héritage.Connaître l'exension du MDL pour naviguer dans les objets manipulés

1. Les nouveaux types de donnéesSQL3 introduit de nouveaux types de données :♦ Large Object (CLOB and BLOB)

♦ Boolean

♦ Array

♦ Row

2. Les types de données abstraitsImplémentation des types utilisateurs.

Syntaxe : Déclaration de type de donnéesCREATE TYPE nom_type AS OBJECT (

nom_attribut1 type_attribut1...MEMBER FUNCTION nom_fonction1 (parametre1 IN|OUT type_parametre1, ...) RETURNtype_fonction1...

) [NOT FINAL];

CREATE TYPE BODY nom_typeISMEMBER FUNCTION nom_fonction1 (...) RETURN type_fonction1

ISBEGIN...END

MEMBER FUNCTION nom_fonction2 ......

END

Syntaxe : Héritage de typeCREATE TYPE sous_type UNDER sur_type (

Déclarations spécifiques ou surcharges)

Remarque : NOT FINALPour être "héritable", un type doit être déclaré avec la clause optionnelle NOT FINAL.

3. Nested tablesImplémentation des collections sous forme de tables imbriquées.Syntaxe : Déclaration de type de données

--Création d'un type abstrait d'objetCREATE TYPE nom_type AS OBJECT (...);

-- Déclaration d'un type abstrait de collectionCREATE TYPE liste_nom_type AS TABLE OF nom_type;

-- Déclaration d'une table imbriquant une autre tableCREATE TABLE nom_table_principale (

nom_attribut type_attribut,...nom_attribut_table_imbriquée liste_nom_type,...)NESTED TABLE nom_attribut_table_imbriquée STORE AS nom_table_stockage;

4. Tables d'objetsImplémentation d'une définition de table depuis un type.Syntaxe : Déclaration de type de données

CREATE TABLE nom_table_principale OF nom_type (;PRIMARY KEY(attribut1),attribut2 NOT NULL,UNIQUE (attribut3)FOREIGN KEY (attribut4) REFERENCES ...

);

Remarque : MéthodesSi le type sur lequel s'appuie la création de la table défini des méthodes, alors les méthodes seront associées à latable.

Remarque : ContraintesIl est possible, sur une table ainsi définie, de spécifier les mêmes contraintes que pour une table créée avec uneclause CREATE TABLE (contraintes de table). Ces contraintes doivent être spécifiées au moment de la création dela table, et non au moment de la création du type. (bien que la définition d'objet permet de spécifier des contraintesdu type NOT NULL, etc.)

5. Insertion d'objetsLa manipulation de données est étendue pour assurer la gestion des objets et des collections.


Remarque : Constructeur d'objetPour tout type d'objet est automatiquement créée une méthode de construction, dont le nom est celui du type et lesarguments les attributs du type.

Syntaxe : Insertion d'objetsINSERT INTO nom_table (..., attribut_type_objet, ...)VALUES(..., nom_type(valeur1, valeur2, ...), ...);

Syntaxe : Insertion de collections d'objetsINSERT INTO nom_table (..., attribut_type_collection, ...)VALUES (

...nom_type_collection(

nom_type_objet(valeur1, valeur2, ...),nom_type_objet(valeur1, valeur2, ...),...);

...);

6. Sélection dans des objetsSyntaxe : Accès aux attributs des objets

SELECT alias_table.nom_objet.nom_attributFROM nom_table AS alias_table

Syntaxe : Accès aux méthodes des objetsSELECT alias_table.nom_objet.nom_méthode(paramètres)FROM nom_table AS alias_table

Remarque : Alias obligatoireL'accès aux objets se fait obligatoirement en préfixant le chemin d'accès par l'alias de la table et non directement parle nom de la table.

7. Sélection dans des tables imbriquéesSyntaxe : Accès aux tables imbriquéesSoit "nt" une table imbriquée dans la table "t".

SELECT t2.*FROM t t1, TABLE(t1.nt) t2;

Remarque : Jointure avec la table imbriquéeLa jointure entre la table principale et sa table imbriquée est implicitement réalisée, il n'est pas besoin de laspécifier.

Remarque : Accès à la colonne d'une table imbriquée de scalairesLorsque la table imbriquée est une table de type scalaire (et non une table d'objets d'un type utilisateur), alors lacolonne de cette table n'a pas de nom (puisque le type est scalaire la table n'a qu'une colonne). Pour accéder à cettecolonne, il faut utiliser la syntaxe dédiée :

COLUMN_VALUE

Exemple : Nested table pour gérer une collection de clés étrangèresSoit la gestion de deux relations pour gérer des livres et des auteurs, avec une relation N:M entre elles. On décide degérer cette relation par une collection de clés étrangères dans la table des livres.

CREATE TABLE tAuteur (Id integer PRIMARY KEY,Nom char(20),Prenom char(20));

CREATE TYPE ListeFkAuteur AS TABLE OF integer;

CREATE TABLE tLivre (Titre char(20) PRIMARY KEY,fkAuteurs ListeFkAuteur) NESTED TABLE fkAuteurs STORE AS tLivresAuteurs;

SGBDRO 179

INSERT INTO tAuteur VALUES (1, 'Merle', 'Robert');INSERT INTO tAuteur VALUES (2, 'Barjavel', 'René');INSERT INTO tLivre VALUES ('Malvil', ListeFkAuteur(1, 2));

SELECT t1.Titre, t2.COLUMN_VALUEFROM tLivre t1, TABLE(t1.fkAuteurs) t2;

TITRE COLUMN_VALUE-----------------------------Malvil 1Malvil 2

SELECT t1.Titre, t3.NomFROM tLivre t1, TABLE(t1.fkAuteurs) t2, tAuteur t3WHERE t2.COLUMN_VALUE=t3.Id;

TITRE NOM-----------------------------Malvil MerleMalvil Barjavel

8. Manipulation d'OIDUne table d'objets, i.e. créée depuis un type, dispose d'un OID pour chacun de ses tuples.Cet OID est accessible depuis la syntaxe REF dans une requête SQL.

Syntaxe : REFSELECT REF(alias)FROM nom_table alias

Exemple : OID0000280209DB703686EF7044A49F8FA67530383B36853DE7106BC74B6781275ABE5A553A5F01C000340000

Syntaxe : Clé étrangère par l'OIDCREATE TYPE type_objet AS OBJECT ...

CREATE TABLE table1 OF type_objet ...

CREATE TABLE table2 (...clé_étrangère REF type_objet,SCOPE FOR (clé_étrangère) IS table1,);

Remarque : SCOPE FORRenforce l'intégrité référentielle en limitant la portée de la référence à une table particulière (alors que REF seulpermet de pointer n'importe quel objet de ce type)

Syntaxe : Insertion de données en SQLINSERT INTO table1 (champs1, ..., clé_étrangère)

SELECT 'valeur1', ..., REF(alias)FROM table2 aliasWHERE clé_table2='valeur';

Syntaxe : Insertion de données en PL/SQLDECLARE

variable REF type_objet;BEGIN

SELECT REF(alias) INTO variableFROM table2 aliasWHERE clé_table2='valeur';

INSERT INTO tCours (champs1, ..., clé_étrangère)VALUES ('valeur1', ..., variable);

END;

Syntaxe : Navigation d'objetsLa référence par OID permet la navigation des objets sans effectuer de jointure, grâce à la syntaxe suivante :

SELECT t.clé_étrangère.attribut_table2FROM table1 t;


Section A2. Exemples

Objectifs pédagogiquesSavoir déduire un modèle logique relationnel-objet depuis un modèle conceptuel E-A ou UML.Intégrer les apports du modèle relationnel-objet par rapport au relationnel dans ce processus

1. Gestion de coursModèle conceptuel

IMG. 49 : MODÈLE CONCEPTUEL EN UML

SGBDRO 181

Modèle logiqueType Bureau : <

poste:entier,centre:chaîne,bâtiment:chaîne,numéro:entier,=coordonnées():chaîne

>

Type Personne : < nom:chaîne, prénom:chaîne >

Type Intervenant hérite de Personne : < bureau:Bureau >

tIntervenant de Intervenant (nom, prénom)

Type RefIntervenant : <nom:chaîne, prénom:chaîne>Type ListeRefIntervenants: collection de <RefIntervenant>Type Cours(semestre:chaîne, num:entier, titre:chaîne, type:enum, contenu:chaîne,lIntervenant:ListeRefIntervenant)

tCours de Cours (semestre, num)

Remarque : Méthode coordonnées()On a choisi de mettre la méthode coordonnées au niveau du type Bureau plutôt que du type Personne, pouraugmenter les possibilités de réutilisabilité (car d'autres entités que Intervenant pourraient utiliser le type Bureau).C'est une possibilité offerte par le fait que les attributs composés donnent naissance à des types utilisateurs (ondécide donc de remonter certaines méthodes qui ne concerne que cet attribut composé au niveau de ce type).

ImplémentationCREATE TYPE Bureau AS OBJECT (

poste number(4),centre char(2),batiment char(1),numero number(3),MEMBER FUNCTION coordonnees RETURN varchar2);

CREATE TYPE BODY BureauIS

MEMBER FUNCTION coordonnees RETURN varchar2ISBEGIN

RETURN centre||batiment||numero||' - poste '||poste;END;

END;

CREATE TYPE Personne AS OBJECT(pkNom varchar2(50),pkPrenom varchar2(50)

) NOT FINAL ;

CREATE TYPE Intervenant UNDER Personne (aBureau Bureau

);

CREATE TABLE tIntervenant OF Intervenant (PRIMARY KEY(pkNom,pkPrenom)

);

CREATE TYPE RefIntervenant AS OBJECT (nom varchar2(50),prenom varchar2(50)

);CREATE TYPE ListeRefIntervenants AS TABLE OF RefIntervenant;

CREATE TYPE Cours AS OBJECT(pkSemestre char(5),pkNum number(2),aTitre varchar2(50),aType char(2),aContenu varchar2(300),lIntervenant ListeRefIntervenants

);

CREATE TABLE tCours OF Cours (PRIMARY KEY(pkSemestre, pkNum),CHECK (aType='C' or aType='TD' or aType='TP')

)NESTED TABLE lIntervenant STORE AS ntCoursIntervenants;


InitialisationINSERT INTO tIntervenant VALUES ('CROZAT', 'Stéphane', Bureau('4287','R','A',108));INSERT INTO tIntervenant VALUES ('JOUGLET', 'Antoine', Bureau('4423','R','C',100));

INSERT INTO tCours VALUES ('P2003',1,'Conception','C','E-A et UML',ListeRefIntervenants(RefIntervenant('CROZAT','Stéphane')));INSERT INTO tCours VALUES ('P2003',5,'Access','TP','Initiation',ListeRefIntervenants(RefIntervenant('CROZAT','Stéphane'),RefIntervenant('JOUGLET','Antoine')));

QuestionsSET LINESIZE 60SET PAGESIZE 10COLUMN Quand FORMAT A5COLUMN Quoi FORMAT A10COLUMN Qui FORMAT A20COLUMN Ou FORMAT A19

SELECT t.pkNom||' '||t.pkPrenom AS Qui, t.aBureau.coordonnees() AS OuFROM tIntervenant t;

QUI OU-------------------------------------CROZAT Stéphane R A108 - poste 4287JOUGLET Antoine R C100 - poste 4423

SELECT c.pkSemestre AS Quand,c.aTitre AS Quoi,ci.Nom AS QuiFROM tCours c, TABLE(c.lIntervenant) ci;

QUAND QUOI QUI------------------------------P2003 Conception CROZATP2003 Access CROZATP2003 Access JOUGLET

SELECT c.pkSemestre AS Quand,c.aTitre AS Quoi,i.pkNom AS Qui,i.aBureau.coordonnees() AS OuFROM tCours c, TABLE(lIntervenant) ci, tIntervenant iWHERE ci.nom=i.pkNom AND ci.prenom=i.pkPrenom;

QUAND QUOI QUI OU-------------------------------------------------P2003 Conception CROZAT R A108 - poste 4287P2003 Access CROZAT R A108 - poste 4287P2003 Access JOUGLET R C100 - poste 4423

2. Gestion de cours simplifiée (version avec OID)Modèle conceptuel

IMG. 50 : MODÈLE CONCEPTUEL EN UML

Modèle logiqueType Intervenant : < nom:chaîne, prénom:chaîne >tIntervenant de Intervenant (nom)

Type Cours(num:entier, titre:chaîne, fkIntervenant REF tIntervenant)tCours de Cours (num)

SGBDRO 183

ImplémentationCREATE TYPE Intervenant AS OBJECT (

pkNom varchar2(50),aPrenom varchar2(50)

);

CREATE TABLE tIntervenant OF Intervenant (PRIMARY KEY (pkNom));

CREATE TYPE Cours AS OBJECT (pkNum number(2),aTitre varchar2(50),fkIntervenant REF Intervenant

);

CREATE TABLE tCours OF Cours (SCOPE FOR (fkIntervenant) IS tIntervenant,PRIMARY KEY(pkNum)

);

Initialisation de la table d'objets tIntervenantINSERT INTO tIntervenantVALUES ('CROZAT', 'Stéphane');

Insertion de données dans la table d'objets tCours (SQL)INSERT INTO tCours

SELECT 2, 'Modélisation', REF(i)FROM tIntervenant iWHERE pkNom='CROZAT';

Insertion de données dans la table tCours (PL/SQL)DECLARE

ri REF Intervenant;BEGIN

SELECT REF(i) INTO riFROM tIntervenant iWHERE i.pkNom='CROZAT';

INSERT INTO tCoursVALUES (1,'Conception',x);

END;

Sélection : Clé étrangère sous forme d'OIDSELECT * FROM tCours;

PKNUM ATITRE FKINTERVENANT------------------------------------------------------------1 Conception 0000220208DE4BD8F3191044589847E31E64B83EBB5807280A335B44C4AD958EDF20D185B52 Modélisation 0000220208DE4BD8F3191044589847E31E64B83EBB5807280A335B44C4AD958EDF20D185B5

Sélection : Jointure sur l'OIDSELECT c.pkNum, i.pkNomFROM tCours c, tIntervenant iWHERE c.fkIntervenant=REF(i);

PKNUM PKNOM-------------------------1 CROZAT2 CROZAT

Sélection : Navigation d'objetsSELECT pkNum, c.fkIntervenant.pkNomFROM tCours c

PKNUM PKNOM-------------------------1 CROZAT2 CROZAT

Section A3. Pratique du relationnel-objet

Exercice n°21. Une entrepriseSoit le schéma UML représentant la production d'entreprises. On considérera que tout produit qui est produit est vendu.



Soit le schéma logique suivant, correspondant à ce diagramme UML.

Type Directeur : <nom :chaîne, prenom : chaîne, date_nais date, =Age() : entier>Type Produit : <num: entier, designation: chaîne, prix: réel>Type RefProduit :<oidProduit REF Produit, qte: entier>Type ListRefProduit : collection de <RefProduit>Type Entreprise : <n_siret : entier, nom : chaîne, oidDirecteur REF Directeur, lProduit :ListRefProduit, =impot(percent IN réel) : réel>

tDirecteur de Directeur (nom, prenom)tProduit de Produit (num)tEntreprise de Entreprise (n_siret)

Les tables tProduit et tDirecteur contiennent les données suivantes :

Nom Prenom date_nais

Dupont1 Jacques 04-02-1977

Dupont2 Emilie 07-03-1967

TAB. 25 : TDIRECTEUR

Num Désignation Prix

1 Chocolat BIGHAND 2

2 Bonbon TICTOC 4

3 Mecano3 140

4 BiBa4 200

TAB. 26 : TPRODUIT

Question1Soit la méthode impot implémentée comme suit.

create or replace type body entreprise ismember function impot(percent in number) return number isimp number;i number;prod produit;refProd refProduit;

SGBDRO 185

beginimp:=0;for i in 1..self.lProduit.count loop

refProd:=self.lProduit(i);select deref(refProd.oidProduit) into prod from dual;imp:=imp+refProd.qte*prod.prix;

end loop;return imp*percent;

end;end;

Cette méthode peut-elle servir à renvoyer l'impôt à payer si cet impôt est un pourcentage du chiffre d'affaire ?Justifier.

Question2Soit le déclencheur monTrigger implémenté comme suit.

CREATE OR REPLACE TRIGGER monTriggerAFTER INSERT OR UPDATEON tEntreprise FOR EACH ROWDECLAREprod Produit;refProd refProduit;i INTEGER;temp NUMBER;oidEntreprise REF Entreprise;direc Directeur;BEGIN

temp:=0;for i in 1..:new.lProduit.count loop

refProd:=:new.lProduit(i);select deref(refProd.oidProduit) into prod from dual;temp:=temp+prod.prix*refProd.qte;

end loop;select DEREF(:new.oidDirecteur) into direc from dual;dbms_output.put_line('MONSIEUR : '||direc.nom);IF temp > 10000 THEN

dbms_output.put_line('EXCELLENT !!!');ELSIF temp < 5000 THEN

dbms_output.put_line('FAIBLE');ELSE dbms_output.put_line('MOYEN');END IF;

END;

Dites ce qui sera affiché après l'execution du programme suivant.

SET SERVEROUTPUT ON ;

DECLAREprod2 REF Produit;prod1 REF Produit;prod3 REF Produit;prod4 REF Produit;direc2 REF Directeur;direc1 REF Directeur;BEGIN

select ref(d) into direc1 from tDirecteur d where d.nom='Dupont1';select ref(d) into direc2 from tDirecteur d where d.nom='Dupont2';select ref(p) into prod1 from tProduit p where p.num=1;select ref(p) into prod2 from tProduit p where p.num=2;select ref(p) into prod3 from tProduit p where p.num=3;select ref(p) into prod4 from tProduit p where p.num=4;

insert into tEntreprise values (1,'Entreprise Confiserie',direc1,listRefProduit(refProduit(prod1,60),refProduit(prod2,100)));

insert into tEntreprise values (2,'Entreprise Jouets',direc2,listRefProduit(refProduit(prod3,60),refProduit(prod4,40)));

update tEntrepriseset lProduit=listRefProduit(refProduit(prod1,6000),refProduit(prod2,4000))where n_siret=1;

update tEntrepriseset lProduit=listRefProduit(refProduit(prod3,10),refProduit(prod4,20))where n_siret=2;END;


Question3Ecrivez une requête permettant de calculer le chiffre d'affaire généré par chacun des directeurs pour toutes lesentreprises qu'ils dirigent.

Question4Ecrivez la méthode de la classe directeur permettant de calculer son age.

Exercice n°22. Des voitures et des hommesSoit le diagramme de classe UML suivant :

IMG. 52 : DES VOITURES...

Question1A partir de ce modèle conceptuel établissez un modèle logique en relationnel-objet, sachant que le coeur duproblème concerne la gestion des voitures.

IndiceOn utilisera des OID pour disposer de clés artificielles.

Question2Proposer une implémentation sous Oracle de votre modèle logique.

Exercice récapitulatif XI. Attributs multi-valués : Réflexion

Le logiciel Documentum gère les attributs multi-valués selon une logique particulière qui consiste à créer une table pour lesattributs monovalués (de façon classique) et à ajouter une seconde table uniquement pour la gestion des attributsmulti-valués.

SGBDRO 187

IMG. 53 : EXEMPLE DE GESTION D'ATTRIBUTS MULTI-VALUÉS SOUS DOCUMENTUM

Question1A partir de ce que vous pouvez déduire de l'exemple ci-avant, citer les quatre attributs, ainsi que leurs valeurs, pourl'objet dont l'OID est 0900055080005f2d.

Question2Rappeler la façon dont on gère les attributs multi-valués sous Oracle en relationnel-objet.

Question3Comparez et critiquez les deux approches.


En résumé...

Modèle RO

Modèle imbriqué Type utilisateur

Tabled'objets

Collection OID Héritage detype

Méthode

CREATETYPE

CREATETABLE

OF

NESTEDTABLE

REF SCOPEFOR

NOTFINAL

UNDER MEMBERFUNCTION

CREATETYPEBODY

Exercice récapitulatif XI. Passage conceptuel logique


On notera que un B ne peut pas être un C.

SGBDRO 189

Question1Proposez un modèle logique relationnel correspondant au modèle conceptuel UML.

Question2Si vous avez fait le bon choix de traduction de la relation d'héritage, une des classes du modèle conceptuel doit-êtrereprésentée sous forme de vue. Proposez l'opération relationnelle qui permet de calculer la vue.

Question3Proposez le code SQL2 permettant l'implémentation du modèle relationnel.

Question4Proposez le code SQL2 permettant l'implémentation de la vue.

Question5Proposez un modèle logique relationnel-objet correspondant au modèle conceptuel UML.

On utilisera les OID.NB : On notera que la création de la vue est identique au cas relationnel, aussi l'on ne s'en préoccupera plus pour lasuite de cet exercice.

Question6Proposez le code SQL3 permettant l'implémentation du modèle relationnel-objet.

NB : On utilisera les OID et les collections seront implémentées sous forme de NESTED TABLE.


Cours

XOptimisation

Objectifs pédagogiquesAssimiler la problématique de la performance en bases de donnéesConnaître les grandes classes de solutions technologiques existantes aux problèmes de performanceConnaître et savoir mobiliser les techniques de conception permettant d'optimiser les performances d'une BD

La conception des SGBDR exige qu'une attention particulière soit portée à la modélisation conceptuelle, afin de parvenir àdéfinir des modèles logiques relationnels cohérents et manipulables. De tels modèles relationnels, grâce au langage standardSQL, présentent la particularité d'être implémentables sur toute plate-forme technologique indépendamment deconsidérations physiques.Néanmoins l'on sait que dans la réalité, il est toujours nécessaire de prendre en considération les caractéristiques propres dechaque SGBDR, en particulier afin d'optimiser l'implémentation. Les optimisations concernent en particulier la question desperformances, question centrale dans les applications de bases de données, qui, puisqu'elles manipulent des volumes dedonnées importants, risquent de conduire à des temps de traitement de ces données trop longs par rapport aux besoinsd'usage.Chaque SGBDR propose généralement des mécaniques propres pour optimiser les implémentations, et il est alors nécessaired'acquérir les compétences particulières propres à ces systèmes pour en maîtriser les arcanes. Il existe néanmoins desprincipes généraux, que l'on retrouvera dans tous les systèmes, comme par exemple les index, les groupements ou les vuesmatérialisées. Nous nous proposerons d'aborder rapidement ces solutions pour en examiner les principes dans le cadre de cecours.Nous aborderons également quelques techniques de conception, qui consistent à revenir sur la structure proposée par l'étapede modélisation logique, pour établir des modèles de données plus aptes à répondre correctement à des questions deperformance. La dénormalisation ou le partitionnement en sont des exemples.

Partie A. Optimisation du schéma interne

Objectifs pédagogiquesAssimiler la problématique de la performance en bases de donnéesConnaître les grandes classes de solutions technologiques existantes aux problèmes de performanceConnaître et savoir mobiliser les techniques de conception permettant d'optimiser les performances d'une BD

Section A1. Introduction à l'optimisation des BD

Schéma interne et performances des applicationsLa passage au schéma interne (ou physique), i.e. l'implémentation du schéma logique dans un SGBD particulier, dépend deconsidérations pratiques liées aux performances des applications.Les possibilités d'optimisation des schémas internes des BD dépendent essentiellement des fonctions offertes par chaqueSGBD.

On peut néanmoins extraire certains principes d'optimisation des schémas internes suffisamment généraux pour êtreapplicables dans la plupart des cas.

1. Evaluation des besoins de performanceEléments à surveillerPour optimiser un schéma interne, il est d'abord nécessaire de repérer les aspects du schéma logique qui sont succeptible degénérer des problèmes de performance.On pourra citer à titre d'exemple les paramètres à surveiller suivants :♦ Taille des tuples

♦ Nombre de tuples

♦ Fréquence d'exécution de requêtes

♦ Complexité des requêtes exécutées (nombre de jointures, etc.)

♦ Fréquence des mises à jour (variabilité des données)

♦ Accès concurents

♦ Distribution dans la journée des accès

♦ Qualité de service particulière recherchée

♦ Paramétrabilité des exécutions

♦ etc.

Evaluation des coûtsUne fois les éléments de la BD à évaluer repérés, il faut mesurer si oui ou non ils risquent de poser un problème deperformance.L'évaluation des performances peut se faire :♦ Théoriquement

En calculant le coût d'une opération (en temps, ressources mémoires, etc.) en fonction de paramètres (volume de données,disparité des données, etc.). En général en BD le nombre de paramètres est très grand, et les calculs de coûts tropcomplexes pour répondre de façon précise aux questions posées.

♦ Empiriquement

En réalisant des implémentations de parties de schéma et en les soumettant à des tests de charge, en faisant varier desparamètres. Ce modèle d'évaluation est plus réaliste que le calcul théorique. Il faut néanmoins faire attention à ce que lessimplifications d'implémentation faites pour les tests soient sans influence sur ceux-ci.

Proposition de solutionsUne fois certains problèmes de performance identifiés, des solutions d'optimisation sont proposées, puis évaluées pourvérifier leur impact et leur réponse au problème posé.Parmi les solutions d'optimisation existantes, on pourra citer :♦ L'indexation

♦ La dénormalisation

♦ Le regroupement (clustering) de tables

♦ Le partionnement vertical et horizontal

♦ Les vues concrètes

2. IndexationIndexUn index est une structure de données qui permet d'accélérer les recherches dans une table en associant à une cléd'index (la liste des attributs indexés) l'emplacement physique de l'enregistrement sur le disque. Les accès effectuéessur un index peuvent donc se faire sur une liste triée au lieu de se faire par parcours séquentiel des enregistrements.

Cas d'usageLes index doivent être utilisés sur les tables qui sont fréquemment soumises à des recherches. Ils sont d'autant pluspertinents que les requêtes sélectionnent un petit nombre d'enregistrements (moins de 25% par exemple).


Les index doivent être utilisés sur les attributs :♦ souvent mobilisés dans une restriction, donc une jointure [sans que des fonctions leurs soient appliquées]

♦ très discriminés (c'est à dire pour lesquels peu d'enregistrements ont les mêmes valeurs)

♦ rarement modifiés

Les index diminuent les performances en mise à jour (puisqu'il faut mettre à jour les index en même temps que lesdonnées). Les index ajoutent du volume à la base de données et leur volume peut devenir non négligeable.

Syntaxe OracleCREATE INDEX nom_index ON nom_table (NomColonneClé1, NomColonneClé2, ...);

Remarque : Index implicitesLa plupart des SGBD créent un index pour chaque clé (primaire ou candidate). En effet la vérification de lacontrainte d'unicité à chaque mise à jour des données justifie à elle seule la présence de l'index.

Attributs indexés utilisés dans des fonctionsLorsque les attributs sont utilisés dans des restrictions ou des tris par l'intermédiaire de fonctions, l'index n'estgénéralement pas pris en compte. L'opération ne sera alors pas optimisée. Ainsi par exemple dans le code suivant, lerestriction sur X ne sera pas optimisée même s'il existe un index sur X.

SELECT *FROM TWHERE ABS(X) > 100

Cette non prise en compte de l'index est logique dans la mesure où, on le voit sur l'exemple précédent, une foisl'attribut soumis à une fonction, le classement dans l'index n'a plus forcément de sens (l'ordre des X, n'est pas l'ordredes valeurs absolues de X).Lorsqu'un soucis d'optimisation se pose, on cherchera alors à sortir les attributs indexés des fonctions.Notons que certains SGBD, tel qu'Oracle à partir de la version 8i, offrent des instructions d'indexation sur lesfonctions qui permettent une gestion de l'optimisation dans ce cas particulier (Delmal, 2001).

3. DénormalisationLa normalisation est le processus qui permet d'optimiser un modèle logique afin de le rendre non redondant. Ce processusconduit à la fragmentation des données dans plusieurs tables.

DénormalisationProcessus consistant à regrouper plusieurs tables liées par des références, en une seule table, en réalisantstatiquement les opérations de jointure adéquates.L'objectif de la dénormalisation est d'améliorer les performances de la BD en recherche sur les tables considérées,en implémentant les jointures plutôt qu'en les calculant.

Remarque : Dénormalisation et redondanceLa dénormalisation est par définition facteur de redondance. A ce titre elle doit être utilisée à bon escient et desmoyens doivent être mis en oeuvre pour contrôler la redondance créée.

Quand utiliser la dénormalisation ?Un schéma doit être dénormalisé lorsque les performances de certaines recherches sont insuffisantes et que cetteinsuffisance à pour cause des jointures.La dénormalisation peut également avoir un effet néfaste sur les performances :♦ En mise à jour

Les données redondantes devant être dupliquées plusieurs fois.

♦ En contrôle supplémentaire

Les moyens de contrôle ajoutés (triggers, niveaux applicatifs, etc.) peuvent être très couteux.

♦ En recherche ciblée

Certaines recherches portant avant normalisation sur une "petite" table et portant après sur une "grande" tablepeuvent être moins performantes après qu'avant.

Optimisation 193

4. Groupement de tablesGroupement de tableUn groupement ou cluster est une structure physique utilisée pour stocker des tables sur lesquelles doivent êtreeffectuées de nombreuses requêtes comprenant des opérations de jointure.Dans un groupement les enregistrements de plusieurs tables ayant une même valeur de champs servant à unejointure (clé du groupement) sont stockées dans un même bloc physique de la mémoire permanente.Cette technique optimise donc les opérations de jointure, en permettant de remonter les tuples joints par un seulaccès disque.

Clé du groupementEnsemble d'attributs précisant la jointure que le groupement doit optimiser.

Syntaxe sous OracleIl faut d'abord définir un groupement, ainsi que les colonnes (avec leur domaine), qui constituent sa clé. On peut ainsiensuite, lors de la création d'une table préciser que certaines de ses colonnes appartiennent au groupement.

CREATE CLUSTER nom_cluster (NomColonneClé1 type, NomColonneClé2 type, ...);

CREATE TABLE nom_table (...)CLUSTER nom_cluster (Colonne1, Colonne2, ...);

RemarqueLe clutering diminue les performances des requêtes portant sur chaque table prise de façon isolée, puisque lesenregistrements de chaque table sont stockés de façon éclatée.

Remarque : Groupement et dénormalisationLe groupement est une alternative à la dénormalisation, qui permet d'optimiser les jointures sans créer deredondance.

5. Partitionnement de tablePartitionnement de tableLe partitionnement d'une table consiste à découper cette table afin qu'elle soit moins volumineuse, permettant ainsid'optimiser certains traitement sur cette table.On distingue :♦ Le partitionnement vertical, qui permet de découper une table en plusieurs tables, chacune ne possédant qu'une

partie des attributs de la table initiale.

♦ Le partitionnement horizontal, qui permet de découper une table en plusieurs tables, chacune ne possédantqu'une partie des enregistrements de la table initiale.

Implémentation de projectionPartitionnement verticalTechnique consistant à implémenter deux projections ou plus d'une table T sur des table T1, T2, etc. en répétant laclé de T dans chaque Ti pour pouvoir recomposer la table initiale par jointure sur la clé (Gardarin, 1999).

RemarqueCe découpage équivaut à considérer l'entité à diviser comme un ensemble d'entités reliées par des associations 1:1.

Cas d'usageUn tel découpage permet d'isoler des attributs peu utilisés d'autres très utilisés, et ainsi améliore les performanceslorsque l'on travaille avec les attributs très utilisés (la table étant plus petite).Cette technique diminue les performances des opérations portant sur des attributs ayant été répartis sur des tablesdifférentes (une opération de jointure étant à présent requise).Le partitionnement vertical est bien entendu sans intérêt sur les tables comportant peu d'attributs.

Implémentation de restrictionPartitionnement horizontalTechnique consistant à diviser une table T en plusieurs sous-table T1, T2, etc. selon des critères de restriction(Gardarin, 1999) et tel que tous les tuples soit conservés de T. La table T est alors recomposable par union sur lesTi.


Cas d'usageUn tel découpage permet d'isoler des enregistrements peu utilisés d'autres très utilisés, et ainsi améliore lesperformances lorsque l'on travaille avec les enregistrements très utilisés (la table étant plus petite). C'est le castypique de l'archivage. Un autre critère d'usage est le fait que les enregistrements soient toujours utilisés selon unpartitionnement donné (par exemple le mois de l'année).Cette technique diminue les performances des opérations portant sur des enregistrements ayant été répartis sur destables différentes (une opération d'union étant à présent requise).Le partitionnement horizontal est bien entendu sans intérêt sur les tables comportant peu d'enregistrements.

6. Vues concrètesUn moyen de traiter le problème de requêtes dont les temps de calcul sont très longs et les fréquences de mise à jour faible estl'utilisation de vues concrètes.

Vue concrèteUne vue concrète est un stockage statique (dans une table) d'un résultat de requête.

Un accès à une vue concrète permet donc d'éviter de recalculer la requête et est donc aussi rapide qu'un accès à unetable isolée. Il suppose par contre que les données n'ont pas été modifiées (ou que leur modification est sansconséquence) entre le moment où la vue a été calculée et le moment où elle est consultée.Une vue concrète est généralement recalculée régulièrement soit en fonction d'un évènement particulier (une mise àjour par exemple), soit en fonction d'un moment de la journée ou elle n'est pas consultée et où les ressources decalcul sont disponibles (typiquement la nuit).

♦ Synonyme : Vue matérialisée.

Section A2. Pratique de l'optimisation

Exercice n°23. Big Brother is Watching YouSoit une base de données composée d'une seule table destinée à recevoir un enregistrement pour chaque personne vivante aumonde. Le schéma de la base est le suivant :

Habitant (Numero, Nom, Prenom, N°Rue, Rue, Quartier, Ville, Etat, Pays, DateNaissance,PaysNaissance, VilleNaissance)

On dispose également des informations concernant les questions qui seront posées à cette base ainsi que les performanceattendues quand aux réponses à ces questions :1. Recherche d'individus

Sélection d'enregistrements étant donné un nom et un pays, projection sur les noms et prénoms et tri alphabétique sur lesnoms.

Cette requête doit être le plus performante possible.

2. Recensement

Comptage de tous les habitants d'un pays.

Cette requête doit être performante.

3. Informations sur un individu

Sélection d'un enregistrement étant donné un numéro et projection de l'ensemble des informations.

Si cette requête est performante, tant mieux, mais elle n'est pas exécutée très souvent et la réponse peut généralementattendre.

4. Statistiques

Calcul de l'age moyen de la population mondiale étant donné une tranche d'age.

Aucune performance n'est attendue de cette requête qui s'exécute assez rarement et toujours en tâche différée.

Question1Ecrivez en SQL les questions qui seront posées à la BD.

Indice--On pose :--[X] désigne le paramètre X-- Now() est une fonction qui renvoie la date du jour

Optimisation 195

Question2Proposez des solutions pour optimiser l'implémentation physique de cette base de données.

IndiceOn cherchera à utiliser les partionnement horizontaux et verticaux, les index et les vues matérialisées.

Question3Réécrivez les requêtes avec le nouveau schéma de la base.

En résumé...

OptimisationModification du schéma interne d'une

BD pour en améliorer lesperformances.

Techniques au niveauphysique

Techniques de modélisation

Indexation Regroupementphysique

Vueconcrète

Dénormalisation Partionnement

Horizontal Vertical


Cours

XIWeb et Java

Si les SGBD offrent les technologies de modélisation et de gestion des données, ils nécessitent la plupart du temps d'êtreinterfacés avec des applications qui fournissent un accès orienté métier aux utilisateurs, notamment à travers des IHMévoluées. Même des systèmes comme Oracle ou PostgreSQL qui proposent un langage procédural (comme PL/SQL) audessus de la couche SQL, ne sont pas auto-suffisants. Les langages évolués comme Java, C ou Perl sont couramment utiliséspour implémenter la couche applicative d'exploitation des BD.Les applications de BD sont aujourd'hui généralement réalisées selon des architectures réseaux. L'explosion d'Internet de soncôté a favorisé le langage HTML pour implémenter les IHM et a vu la naissance de langages de script pour implémenter lacouche applicative côté serveur, tels que PHP, ASP ou JSP, plus simples que les langages classiques.

Partie A. Web

Objectifs pédagogiquesComprendre les principes des architectures d'applications (en particulier 3-tier et Web) de BDComprendre le rôle des langages applicatifs comme sur-couche au dessus des SGBD et SQLSavoir appliquer les principes d'une architecture Web dans le cadre des technologies Servlets ou PHP, et HTML

Section A1. Architecture trois tiers

1. Notions d'achitecture client-serveurFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

1.1. Présentation de l'architecture d'un système client/serveurDe nombreuses applications fonctionnent selon un environnement client/serveur, cela signifie que des machines clientes (desmachines faisant partie du réseau) contactent un serveur, une machine généralement très puissante en terme de capacitésd'entrée-sortie, qui leur fournit des services. Ces services sont des programmes fournissant des données telles que l'heure, desfichiers, une connexion, ...Les services sont exploités par des programmes, appelés programmes clients, s'exécutant sur les machines clientes. On parleainsi de client FTP, client de messagerie, ..., lorsque l'on désigne un programme, tournant sur une machine cliente, capable detraiter des informations qu'il récupère auprès du serveur (dans le cas du client FTP il s'agit de fichiers, tandis que pour leclient messagerie il s'agit de courrier électronique).Dans un environnement purement Client/serveur, les ordinateurs du réseau (les clients) ne peuvent voir que le serveur, c'estun des principaux atouts de ce modèle.

1.2. Avantages de l'architecture client/serveurLe modèle client/serveur est particulièrement recommandé pour des réseaux nécessitant un grand niveau de fiabilité, sesprincipaux atouts sont :♦ des ressources centralisées

étant donné que le serveur est au centre du réseau, il peut gérer des ressources communes à tous les utilisateurs, commepar exemple une base de données centralisée, afin d'éviter les problèmes de redondance et de contradiction

♦ une meilleure sécurité

car le nombre de points d'entrée permettant l'accès aux données est moins important

♦ une administration au niveau serveur

les clients ayant peu d'importance dans ce modèle, ils ont moins besoin d'être administrés

♦ un réseau évolutif

grâce à cette architecture ont peu supprimer ou rajouter des clients sans perturber le fonctionnement du réseau et sansmodifications majeures

1.3. Inconvénients du modèle client/serveurL'architecture client/serveur a tout de même quelques lacunes parmi lesquelles :♦ un coût élevé

dû à la technicité du serveur

♦ un maillon faible

le serveur est le seul maillon faible du réseau client/serveur, étant donné que tout le réseau est architecturé autour de lui!Heureusement, le serveur a une grande tolérance aux pannes (notamment grâce au système RAID)

1.4. Fonctionnement d'un système client/serveur

IMG. 55 : SCHÉMA DE FONCTIONNEMENT D'UN SYSTÈME CLIENT/SERVEUR

Un système client/serveur fonctionne selon le schéma suivant:♦ Le client émet une requête vers le serveur grâce à son adresse et le port, qui désigne un service particulier du serveur

♦ Le serveur reçoit la demande et répond à l'aide de l'adresse de la machine client et son port

2. Notions d'achitecture 3-tierFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

2.1. Présentation de l'architecture à deux niveauxL'architecture à deux niveaux (aussi appelée architecture 2-tier,tier signifiant étage en anglais) caractérise les systèmesclients/serveurs dans lesquels le client demande une ressource et le serveur la lui fournit directement. Cela signifie que leserveur ne fait pas appel à une autre application afin de fournir le service.


IMG. 56 : ARCHITECTURE 2-TIER

2.2. Présentation de l'architecture à trois niveauxDans l'architecture à 3 niveaux (appelée architecture 3-tier), il existe un niveau intermédiaire, c'est-à-dire que l'on agénéralement une architecture partagée entre:1. Le client

le demandeur de ressources

2. Le serveur d'application

(appelé aussi middleware) le serveur chargé de fournir la ressource mais faisant appel à un autre serveur

3. Le serveur secondaire

(généralement un serveur de base de données), fournissant un service au premier serveur

IMG. 57 : ARCHITECTURE 3-TIER

RemarqueEtant donné l'emploi massif du terme d'architecture à 3 niveaux, celui-ci peut parfois désigner aussi les architecturessuivantes :♦ Partage d'application entre client, serveur intermédiaire, et serveur d'entreprise

♦ Partage d'application entre client, base de données intermédiaire, et base de données d'entreprise

Web et Java 199

2.3. Comparaison des deux types d'architectureL'architecture à deux niveaux est donc une architecture client/serveur dans laquelle le serveur est polyvalent, c'est-à-dire qu'ilest capable de fournir directement l'ensemble des ressources demandées par le client. Dans l'architecture à trois niveaux parcontre, les applications au niveau serveur sont délocalisées, c'est-à-dire que chaque serveur est spécialisé dans une tâche(serveur web/serveur de base de données par exemple). Ainsi, l'architecture à trois niveaux permet :♦ une plus grande flexibilité/souplesse

♦ une plus grande sécurité (la sécurité peut être définie pour chaque service)

♦ de meilleures performances (les tâches sont partagées)

2.4. L'architecture multi-niveauxDans l'architecture à 3 niveaux, chaque serveur (niveaux 1 et 2) effectue une tâche (un service) spécialisée. Ainsi, un serveurpeut utiliser les services d'un ou plusieurs autres serveurs afin de fournir son propre service. Par conséquence, l'architecture àtrois niveaux est potentiellement une architecture à N niveaux.

IMG. 58 : ARCHITECTURE N-TIER

3. Notions de serveur WebFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

Un serveur web est un logiciel permettant à des clients d'accèder à des pages web, c'est-à-dire en réalité des fichiers au formatHTML à partir d'un navigateur (aussi appelé browser) installé sur leur ordinateur distant.Un serveur web est donc un "simple" logiciel capable d'interpréter les requêtes HTTP arrivant sur le port associé au protocoleHTTP (par défaut le port 80), et de fournir une réponse avec ce même protocole.Les principaux serveurs web sur le marché sont entre autres :♦ Apache

♦ Microsoft IIS (Internet Information Server)

♦ Microsoft PWS (Personal Web Server)

♦ ...

4. Architecture WebFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.


IMG. 59 : EXEMPLES D'ARCHITECTURE WEB

Section A2. Rappels HTML

1. Formulaires HTMLFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

Grâce à la balise FORM du langage HTML, il est très simple de créer des formulaires comprenant :♦ des cases à cocher

♦ des champs de saisie

♦ des boutons radio

♦ des listes à choix multiples

♦ ...

Exemple : Formulaire<FORM Method="GET" Action="test.php3">

Nom : <INPUT type=text name=nom><BR>Prénom : <INPUT type=text name=prenom><BR>Age : <INPUT type=text name=age><BR><INPUT type=submit>

</FORM>

IMG. 60 : EXEMPLE DE FORMULAIRE HTML

Web et Java 201

Section A3. Introduction à PHP

1. Présentation de PHPFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

PHP est un langage interprété (un langage de script) exécuté du côté serveur (comme les scripts CGI, ASP, ...) et non du côtéclient (un script écrit en Javascript ou une applet Java s'exécute sur votre ordinateur...). La syntaxe du langage provient decelles du langage C, du Perl et de Java.Ses principaux atouts sont :♦ La gratuité et la disponibilité du code source (PHP est distribué sous licence GNU GPL)

♦ La simplicité d'écriture de scripts

♦ La possibilité d'inclure le script PHP au sein d'une page HTML (contrairement aux scripts CGi, pour lesquels il faut écriredes lignes de code pour afficher chaque ligne en langage HTML)

♦ La simplicité d'interfaçage avec des bases de données (de nombreux SGBD sont supportés, le plus utilisé avec ce langageest MySQL).

♦ L'intégration au sein de nombreux serveurs web (Apache, Microsoft IIS, ...)

Exemple : SGBD supportés par PHP♦ dBase

♦ Informix

♦ MySQL

♦ Oracle

♦ PostgreSQL

♦ Sybase

♦ ...

2. Principes de PHPFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

2.1. L'interprétation du code par le serveurUn script PHP est un simple fichier texte contenant des instructions écrites à l'aide de caractères ASCII 7 bits (des caractèresnon accentués) incluses dans un code HTML à l'aide de balises spéciales et stocké sur le serveur. Ce fichier doit avoir uneextension particulière (qui dépend de la configuration du serveur HTTP, en général ".php") pour pouvoir être interprété par leserveur.Ainsi, lorsqu'un navigateur (le client) désire accéder à une page dynamique réalisée en php :1. Le serveur reconnait qu'il s'agit d'un fichier php

2. Il lit le fichier php

3. Dès que le serveur rencontre une balise indiquant que les lignes suivantes sont du code php, il "passe" en mode php, cequi signifie qu'il ne lit plus les instructions: il les exécute.

4. Lorsque le serveur rencontre une instruction, il la transmet à l'interpréteur

5. L'interpréteur exécute l'instruction puis envoie les sorties éventuelles au serveur

6. A la fin du script, le serveur transmet le résultat au client (le navigateur)

Remarque : Code PHP et clients WebUn script PHP est interprété par le serveur, les utilisateurs ne peuvent donc pas voir le code source !

Le code php3 stocké sur le serveur n'est donc jamais visible directement par le client puisque dès qu'il en demandel'accès, le serveur l'interprète ! De cette façon aucune modification n'est à apporter sur les navigateurs...


2.2. Implantation au sein du code HTMLPour que le script soit interprété par le serveur deux conditions sont nécessaires :♦ Le fichier contenant le code doit avoir l'extension .php3 et non .html

♦ Le code php3 contenu dans le code HTML doit être délimité par les balises "<?php" et "?>"

Exemple : Hello world<html><head><title>Exemple</title></head><body><?phpecho "Hello world";?></body></html>

3. Syntaxe PHPFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

Une instruction se termine par un ";"♦ Les espaces, retours chariot et tabulation ne sont pas pris en compte par l'interpréteur.

♦ Les commentaires sont écrits entre les délimiteurs "/*" et "*/" sur une seule ligne.

♦ Le langage est case-sensitive (sauf pour les fonctions).

4. Variables en PHPFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

♦ Les variables ne sont pas déclarées

♦ Les variables commencent pas un $.

♦ Les variables ne sont pas typées.

Les variables en langage PHP peuvent être de trois types :♦ Scalaires (entiers, chaîne, réels).

♦ Tableaux (un tableau pouvant être multidimensionnel et stocker des scalaires de types différents).

♦ Tableaux associatifs (indexés par des chaînes).

Exemple$Entier=1;$Reel=1.0;$Chaine="1";$Tableau[0]=1$Tableau[1]="1"$TableauMulti[0][0]="1.0"$TableauAssoc["Age"]=18

5. Structures de contrôle en PHPFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

if (condition réalisée) {liste d'instructions

}elseif (autre condition réalisée) {

autre série d'instructions}...else (dernière condition réalisée) {

série d'instructions}

Remarque : Switchswitch / case / default / break

Web et Java 203

6. Boucles en PHPFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

for (compteur; condition; modification du compteur) {liste d'instructions

}

while (condition réalisée) {liste d'instructions

}

7. Fonctions en PHPFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

function Nom_De_La_Fonction(argument1, argument2, ...) {liste d'instructions...return valeur_ou_variable;...

}

8. Objets en PHPFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.Syntaxe : Déclaration d'une classe

class Nom_de_la_classe {// Déclarations des données membresvar $Donnee_Membre_1;var $Donnee_Membre_2;...// Déclarations des méthodesfunction Nom_de_la_fonction_membre1(parametres) {

liste d'instructions;}...

}

Remarque : ThisLe mot clé $this permet d'accéder à l'objet en cours lors de la déclaration des méthodes.

Syntaxe : Instanciation d'objets$Nom_de_l_objet = new Nom_de_la_classe;

Syntaxe : Accès aux propriété$Nom_de_l_objet->Nom_de_la_propriété = Valeur;

Syntaxe : Accès aux méthodes$Nom_de_l_objet->Nom_de_la_méthode (parametre1,parametre2,...);

9. Envoi de texte au navigateurFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.Syntaxe

echo Expression;

Remarque : PrintLa fonction "print" est iso-fonctionnelle avec "echo" et printf plus complexe permet en plus le formattage desdonnées (peu utilisée).

L'importance de l'implantation du code php au sein du code HTMLLe code PHP peut être implanté au sein du code HTML. Cette caractéristique n'est pas à négliger car le fait d'écrireuniquement du code PHP là où il est nécessaire rend la programmation plus simple (il est plus simple d'écrire ducode HTML que des fonctions echo ou print, dans lesquelles les caractères spéciaux doivent être précédés d'unantislash sous peine de voir des erreurs lors de l'exécution). L'exemple le plus simple concerne les pagesdynamiques dont l'en-tête est toujours le même: dans ce cas, le code PHP peut ne commencer qu'à partir de la balise<BODY>, au moment où la page peut s'afficher différemment selon une variable par exemple.Mieux, il est possible d'écrire plusieurs portions de script en PHP, séparées par du code HTML statique car lesvariables/fonctions déclarées dans une portion de script seront accessibles dans les portions de scripts inférieures.


10. Formulaires HTML et PHPFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

Php rend très simple la récupération de données envoyées par l'intermédiaire de formulaires HTML.Lorsque l'on soumet un formulaire à un fichier PHP, toutes les données du formulaire lui sont passées en tant que variables,c'est-à-dire chacun des noms associés aux champs (ou boutons) du formulaire précédés du caractère $.

Exemple : Page d'appel<HTML>

<BODY><FORM Method="GET" Action="test.php">

<INPUT type=text size=20 name=MaVar><INPUT type=submit>

</FORM></BODY>

</HTML>

Exemple : Page appelée (test.php)<?php

echo $MaVar;?>

Remarque : $HTTP_GET_VARS[]Selon la configuration du module PHP, il est possible que la récupération directe des données issue du formulaireHTML ne fonctionne pas. On peut dans ce cas utiliser les tableaux associatifs $HTTP_GET_VARS['variable'] ou$HTTP_POST_VARS['variable'].

<?php$MaVarLocale=$HTTP_GET_VARS['MaVar']echo $MaVarLocale;

?>

Section A4. PHP et BD

1. Interfaçage avec Oracle (API ORA)Fait à partir de .L'API ORA est l'API officielle d'Oracle

1.1. Connection à la base de données"Ora_Logon" établit une connexion entre le serveur PHP et un serveur Oracle.Syntaxe

int ora_logon(string user@instance, string password);

Exempleif (! $conn=Ora_Logon($user, $passwd)) {

echo "Impossible d'établir la connexion ";exit;

}

1.2. Création d'un curseur"Ora_Open" ouvre un curseur Oracle sur une connexion.Syntaxe

int ora_open(int connection);

Exempleif(! $cursor=Ora_Open($conn)) {

echo "Impossible de créer le curseur";exit;

}

Web et Java 205

1.3. Préparation d'une requête"Ora_Parse" analyse une requête SQL ou un bloc PL/SQL et l'associe avec un curseur.Syntaxe

int ora_parse(int cursor_ind, string sql_statement, int defer);

Exempleif(! Ora_Parse($cursor, $sql, $defer)) {

echo "Impossible de préparer la requête";exit;

}

1.4. Exécution d'une requête"Ora_Exec" exécute une requête préparée sur un curseur.Syntaxe

int ora_exec(int cursor);

Exempleif(! Ora_Exec($cursor)) {

echo "Impossible d'exécuter la requête";exit;

}

Remarque : Auto-commitCette fonction active la validation automatique après chaque ora_exec().

int ora_commiton(int conn);

1.5. Récupération d'enregistrement"Ora_Fetch_Into" déverse l'enregistrement pointé par un curseur dans un tableau PHP et passe le curseur à l'enregistrementsuivant.Syntaxe

int ora_fetch_into(int cursor, array() result);

Exemple$results=array();while (ora_fetch_into($cursor, $results)) {

echo $results[0];echo $results[1];echo $results[2];

}

1.6. Déconnection de la base de données"Ora_Logoff" ferme une connexion Oracle.Syntaxe

int ora_logoff(int connection);

Exempleif (! Ora_Logoff($conn)) {

echo "Impossible de fermer la connexion ";exit;

}

2. Interfaçage avec Oracle (API OCI)Fait à partir de .L'API OCI est plus souple que l'API ORA "officielle".

2.1. Connection à la base de données"OCILogon" établit une connexion entre le serveur PHP et un serveur Oracle.Syntaxe

int OCILogon(string username, string password, string bd); ;


Exempleif (! $conn=OCILogon($user, $passwd, $bd)) {

echo "Impossible d'établir la connexion ";exit;

}

2.2. Préparation d'une requête"OCIParse" analyse une requête SQL et retourne un pointeur sur un statement (espace de requête).Syntaxe

int OCIParse(int conn, string query);

Exempleif(! $statement=OCIParse($conn, $sql)) {

echo "Impossible de préparer la requête";exit;

}

2.3. Exécution d'une requête"OCIExecute" exécute une commande déjà préparée avec OCIParse. Il est possible de spécifier le mode d'exécution destransactions (par défaut, il est en auto-commit, c'est à dire que l'ordre commit est passé automatiquement après chaqueinstruction SQL). Il est préférable d'utiliser le mode OCI_DEFAULT qui permet de contrôler les commits.Syntaxe

int OCIExecute(int statement, [int mode]);

Exempleif(! OCIExec($statement, OCI_DEFAULT)) {

echo "Impossible d'exécuter la requête";exit;

}

2.4. Commit d'une transaction"OCICommit" valide la transaction en cours sur une connection.Syntaxe

int OCICommit(int connection);

Exempleif(! OCICommit($conn)) {

echo "Impossible de valider la transaction";exit;

}

Remarque : Rollback"OCIRollback" permet d'annuler une transaction.

2.5. Récupération d'enregistrement"OCIFetchInto" retourne la ligne suivante (pour une instruction SELECT) dans un tableau. OCIFetchInto() écrasera lecontenu du tableau. Par défaut, le tableau sera un tableau à index numérique, commencant à 1, et qui contiendra toute lescolonnes qui ne sont pas NULL.Syntaxe

int OCIFetchInto(int statement, array result, [int mode]);

Exemple$results=array();while (OCIFetchInto($statement, $results, OCI_RETURN_NULLS)) {

echo $results[0];echo $results[1];echo $results[2];

}

Remarque : ModeLe mode OCI_RETURN_NULLS permet de retourner toutes les colonnes, même si elles sont nulles. Le modeOCI_ASSOC permet de retourner un tableau associatif au lieu d'un tableau à index numérique. Il est possible de lescombiner en les aditionnant : OCI_RETURN_NULLS+OCI_ASSOC.

Web et Java 207

Remarque : OCIFetch et OCIResultOCIFetch et OCIResult sont deux instructions alternatives pour gérer le traitement de résultat de requête SELECT.

2.6. Déconnection de la base de données"OCILogOff" ferme une connexion Oracle.Syntaxe

int OCILogOff(int connection);

Exempleif (! OCILogOff($conn)) {

echo "Impossible de fermer la connexion ";exit;

}

3. Architecture PHP/OracleFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

IMG. 61 : EXEMPLE D'ARCHITECTURE 3-TIERS : PHP/ORACLE

Partie B. Java

Objectifs pédagogiquesComprendre le rôle des langages applicatifs comme sur-couche au dessus des SGBD et SQLConnaître les principes de l'interfaçage d'un langage de programmation avec une BDSavoir appliquer les principes de l'interfaçage d'un langage de programmation avec une BD en Java

Section B1. Java et BD (JDBC)

1. JBDCJDBC [Java DataBase Connectivity] est une API permettant la communication entre un programme Java et un serveur de BDJDBC permet donc à la fois une indépendance vis à vis de la machine accueillant l'application (pourvu qu'elle dispose d'unemachine virtuelle Java) et vis à vis du serveur de BD (pourvu qu'il dispose d'un pilote JDBC).


Remarque : ODBCODBC [Open DataBase Connectivity] est équivalent à JDBC, dans le monde Windows (i.e. il offre une API decommunication entre une application Windows et un serveur de BD possédant un pilote ODBC).

2. Structure globale d'un appel BD depuis Java1. Déclarer le pilote JDBC lié à la base interrogée

2. Se connecter à la BD (et définir éventuellement des paramètres sur cette connexion)

3. Créer un espace pour les requêtes (statement)

4. Exécuter une requête SQL et récupérer le résultat (s'il s'agit d'une requête de sélection) dans un objet dédié (ResultSet)

5. Traiter le résultat

6. Fermer la connexion

Remarque : Gestion d'exceptionUn tel programme Java doit impérativement ajouter une boucle de traitement des exceptions Try / Catch

3. Syntaxe d'un appel BD depuis JavaSyntaxe : Package

import java.sql.*

Syntaxe : Déclaration du pilote JDBCDriverManager.registerDriver (new pilote JDBC);

Driver Oracle : oracle.jdbc.OracleDriverDriver MySQL : com.mysql.jdbc.Driver

Syntaxe : Connexion à la BDConnection vCon = DriverManager.getConnection(paramètres de connexion);

Paramètres Oracle : "jdbc:oracle:thin:user/password@host:port:database"Paramètres MySQL : "jdbc:mysql://host/database","user","password"

Syntaxe : Création d'un espace de requêteStatement vSt = vCon.createStatement();

Syntaxe : Exécution d'une requêteResultSet vRs = vSt.executeQuery("requête SQL");

Syntaxe : Traitement des résultatswhile(vRs.next()) {

...}

Web et Java 209

4. Insertion et sélection dans Oracle depuis Javapackage nf17.exemple;

import java.sql.Connection;import java.sql.DriverManager;import java.sql.ResultSet;import java.sql.Statement;import oracle.jdbc.OracleDriver;

public class ExempleNx17 {public static void main(String[] args) {try {

DriverManager.registerDriver (new OracleDriver());Connection vCon =DriverManager.getConnection("jdbc:oracle:thin:nf17/nf17@localhost:1521:test");vCon.setAutoCommit(true);Statement vSt = vCon.createStatement();

vSt.execute("INSERT INTO tIntervenant (pkNom, aPrenom, aPoste) VALUES ('CROZAT','STEPHANE', '4287')");ResultSet vRs = vSt.executeQuery("SELECT t.pkNom, t.aPrenom FROM tIntervenant t");

while(vRs.next()){String vNom = vRs.getString(1);String vPrenom = vRs.getString(2);System.out.println("Nom="+vNom+"Prenom="+vPrenom);

}} catch (Exception e) {

e.printStackTrace();}}

}

5. Espace de requête préparéRemarque : StatementL'objet Statement est le plus simple à utiliser pour créer un espace de requête. Il présente néanmoins l'inconvénientde ne pas gérer la protection des caractères spéciaux et de ne pas être paramétrable. Ainsi, par exemple, on nepourra pas insérer de caractère contenant une apostrophe "'".

Syntaxe : Espace préparéPreparedStatement vSt = fCon.prepareStatement(requête SQL avec des ?);

Des "?" peuvent être insérés dans la requête, ils correspondent à des valeurs qui seront paramétrées par les méthodessetString, setInt, etc.

vSt.setString (index?, valeur);vSt.setInt (index?, valeur);...

"index?" correspond au numéro d'ordre du point d'interrogation dans la requête SQL.

vSt.execute();

ExemplePreparedStatement vSt = fCon.prepareStatement("SELECT * FROM t1 WHERE x=?");vSt.setString(1, "test")vSt.execute()


6. Insertion en utilisant un espace préparé dans Oraclepackage nf17.exemple;



DriverManager.registerDriver (new OracleDriver());Connection vCon =DriverManager.getConnection("jdbc:oracle:thin:nf17/nf17@localhost:1521:test");vCon.setAutoCommit(true);PreparedStatement vSt = fCon.prepareStatement("INSERT INTO tIntervenant (pkNom,aPrenom) VALUES (?, ?)");vSt.setString (1, "CROZAT");vSt.setString (2, "Stéphane");vSt.execute();

} catch (Exception e) {e.printStackTrace();

}}

}

7. Appel Oracle PL/SQLSyntaxe : Espace d'appel PL/SQL

CallableStatement vSt = fCon.prepareCall(bloc PL/SQL avec des ?);

Des "?" peuvent être insérés dans la requête, ils correspondent à :♦ des valeurs qui seront passées en paramètre (setString, setInt, etc.)

♦ et à des valeurs de retour (registerOutParameter et getString, getInt, etc.)

vSt.setString (index?, valeur);vSt.setInt (index?, valeur);...vSt.registerOutParameter(index?, Types.TYPEBD);...

"index?" correspond au numéro d'ordre du point d'interrogation dans la requête SQL.Types.TYPEBD correspond au type retourné par la fonction PL/SQL (VARCHAR, INTEGER, etc.)

vSt.execute();vRs = vSt.getString(index?)vRs = vSt.getInt(index?)...

ExempleCallableStatement vSt = fCon.prepareCall("begin ?:=pInsertIntervenant(?,?); end;");vSt.setString(2, "CROZAT");vSt.setString(3, "Stéphane");vSt.registerOutParameter(1, Types.VARCHAR);vSt.execute();String vRs = vSt.getString(1);

Web et Java 211

8. Insertion en utilisant un appel Oracle PL/SQLpackage nf17.exemple;



DriverManager.registerDriver (new OracleDriver());Connection vCon =DriverManager.getConnection("jdbc:oracle:thin:nf17/nf17@localhost:1521:test");

CallableStatement vSt = fCon.prepareCall("begin ?:=pInsertIntervenant(?,?); end;");vSt.setString(2, vNewNom);vSt.setString(3, vNewPrenom);vSt.registerOutParameter(1, Types.VARCHAR);

vSt.execute();String vRs = vSt.getString(1);System.out.println(vRs);


}}

}

Section B2. Introduction aux servlets

1. Présentation des servletsservletLes servlets sont des applications Java exécutées sur un serveur d'application, permettant de générer des réponsesdynamiques pour répondre aux requêtes d'un client Web (i.e. des pages HTML construites dynamiquement).

Remarque : appletNe pas confondre les servlets avec les applets, qui sont des applications Java exécutées côté client (téléchargées parle navigateur Web et exécutées par une machine Java locale)

Remarque : PortabilitéEn tant que programme Java, les servlets peuvent être exécutées sur toutes plates-formes.

Les servlets sont exécutée grâce à un moteur de servlet (tels que Tomcat, Jserv, etc.) Le moteur de servlet est indépendant duserveur HTTP (Apache , IIS, etc.) et doit lui être connecté (pour que le serveur HTTP redirige les exécutions des servlets aumoteur de servlet). Un moteur de servlet peut néanmoins faire office de serveur HTTP.


IMG. 62 : ARCHITECTURE SERVLET (DEPUIS COMMENTCAMARCHE.ORG, COPYRIGHT 2003 JEAN-FRANÇOIS PILLOU, IMAGE SOUMISEÀ LA LICENCE GNU FDL).

Remarque : Comparaison servlet / PHPLes servlets sont plus performantes que le code PHP, car le pseudo-code Java est précompilé alors que les scriptsPHP sont interprétés.Les servlets fournissent un niveau de programmation plus élevé, en tant que langage o bjet, que les scripts PHP,elles sont aussi plus complexes à écrire.

2. Implémenter une servletPackage : javax.servlet.* et javax.servlet.http.*1. Créer une classe qui hérite de HttpServlet

2. Surcharger les méthodes de la classe HttpServlet pour récupérer les paramètres de la requête et construire la réponse

3. Quelques méthodes de la classe HttpServlet♦ doGet(HttpServletRequest vReq, HttpServletResponse vRes)

Invoquée lors de l'appel de la servlet par une méthode GET

♦ doPost(HttpServletRequest vReq, HttpServletResponse vRes)

Invoquée lors de l'appel de la servlet par une méthode POST

♦ service(HttpServletRequest vReq, HttpServletResponse vRes)

Invoquée à chaque requête du client (GET ou POST), elle est donc utilisable à la place de DoGet et DoPost, sans besoinde différencier les deux types d'appel.

♦ init()

Invoquée à chaque instanciation de la servlet.

4. Formulaires HTML et servlet (HttpServletRequest)La méthode "getParameter" de l'objet de type "HttpServletRequest" permet de récupérer les paramètres issus du formulaireHTML :

ExempleString vNom = pReq.getParameter("nom");

5. Création de la réponse (HttpServletResponse)L'objet de type "HttpServletResponse" permet de créer la réponse à la requête HTTP (donc la page HTML)

Web et Java 213

Il faut pour cela :1. Instancier un objet "PrintWriter" lié à l'objet "HttpServletResponse" : "PrintWriter vOut = pResp.getWriter();"

2. Ecrire dans l'objet "PrintWriter" le code HTML de la réponse : vOut.println("code HTML");

ExemplePrintWriter vOut = pResp.getWriter();vOut.println("<html><body>Hello World</body></html>");

6. Cycle de vie d'une servletFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.1. La servlet est chargée au démarrage du serveur ou lors de la première requête

2. La méthode init() est invoquée à l'instanciation

3. Lors de la première requête, les objets Request et Response sont créés spécifiquement pour la requête

4. La méthode service() est appelée à chaque requête dans une nouvelle thread. Les objets Request et Response lui sontpassés en paramètre

5. Grâce à l'objet Request, la méthode service() va pouvoir analyser les informations en provenance du client

6. Grâce à l'objet Response, la méthode service() va fournir une réponse au client


Section B3. Servlets et BD

1. Exemple d'appel SQL depuis une servlet sous Oraclepackage nf17.exercice;import java.io.IOException;import java.io.PrintWriter;import java.sql.Connection;import java.sql.DriverManager;import java.sql.ResultSet;import java.sql.Statement;import javax.servlet.ServletException;import javax.servlet.http.HttpServlet;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;import oracle.jdbc.OracleDriver;

public class ExempleNf17Servlet extends HttpServlet {Connection fCon = null;

public void init() throws ServletException {try {

DriverManager.registerDriver (new OracleDriver());fCon = DriverManager.getConnection("jdbc:oracle:thin:nf17/nf17@localhost:1521:test");fCon.setAutoCommit(true);


}super.init();}

protected void service(HttpServletRequest pReq, HttpServletResponse pResp) throwsServletException, IOException {try {

String vNewNom = pReq.getParameter("nom");String vNewPrenom = pReq.getParameter("prenom");PreparedStatement vSt = fCon.prepareStatement("INSERT INTO tIntervenant (pkNom,aPrenom) VALUES (?,?)");vSt.setString(1, vNewNom);vSt.setString(2, vNewPrenom);

vSt.execute();

PrintWriter vOut = pResp.getWriter();vOut.println("<html><body>");vOut.print("OK");vOut.println("</body></html>");

} catch (Exception e) {PrintWriter vOut = pResp.getWriter();e.printStackTrace(vOut);

}}

}

Remarque : PreparedStatementLa syntaxe utilise ici l'objet Prepared Statement plutôt que directement un objet Statement.

Web et Java 215

2. Exemple d'appel Oracle PL/SQL depuis une servletpackage nx17.exercice;import java.io.IOException;import java.io.PrintWriter;import java.sql.CallableStatement;import java.sql.Connection;import java.sql.DriverManager;import java.sql.Types;import javax.servlet.ServletException;import javax.servlet.http.HttpServlet;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;import oracle.jdbc.OracleDriver;

public class ExerciceNx17Servlet extends HttpServlet {Connection fCon = null;

public void init() throws ServletException {try {

DriverManager.registerDriver (new OracleDriver());fCon = DriverManager.getConnection("jdbc:oracle:thin:nf17/nf17@localhost:1521:test");fCon.setAutoCommit(true);


}super.init();}

protected void service(HttpServletRequest pReq, HttpServletResponse pResp) throwsServletException, IOException {try {

String vNewNom = pReq.getParameter("nom");String vNewPrenom = pReq.getParameter("prenom");CallableStatement vSt = fCon.prepareCall("begin ?:=pInsertIntervenant(?,?); end;");vSt.setString(2, vNewNom);vSt.setString(3, vNewPrenom);vSt.registerOutParameter(1, Types.VARCHAR);

vSt.execute();String vRs = vSt.getString(1);

PrintWriter vOut = pResp.getWriter();vOut.println("<html><body>");vOut.print(vRs);vOut.println("</body></html>");

} catch (Exception e) {PrintWriter vOut = pResp.getWriter();e.printStackTrace(vOut);

}}

}

Remarque : CallableStatementL'usage de l'objet Callable Statement est obligatoire pour faire des appels PL/SQL.

3. Architecture servlet/OracleFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.


IMG. 63 : EXEMPLE D'ARCHITECTURE 3-TIERS : SERVLETS/ORACLE

Web et Java 217

Exercicerécapitulatif

IRetour sur les

fonctionsfondamentales des

SGBD

Pour chacune des fonctions citées ci-après, rappeler comment les SGBD les mettent en oeuvre conceptuellement ettechnologiquement, en donnant des exemples concrêts.

Question1Indépendance physique des données

Question2Indépendance logique des données

Question3Manipulation des données par des non-informaticiens

Question4Administration facilitée des données

Question5Optimisation de l'accès aux données

Question6Contrôle de cohérence (intégrité sémantique) des données

Question7Partageabilité des données

Question8Sécurité des données

Question9Sûreté des données


Exercicerécapitulatif

IGestion de comptes

bancaires

Enoncé n°1Nouvel employé d'une entreprise bancaire, vous avez pour mission de restructurer une base de données existante pour lagestion des opérations bancaires (débits et crédits sur un compte).La base de données existante a été conçue sous MS Access, avec une unique table.

IMG. 64 : SCHÉMA DE LA SEULE TABLE DE LA BD

NB : Un débit est différencié d'un crédit par la valeur de MontantOperation : Si elle est négative il s'agit d'un débit, si elle estpositive il d'agit d'un crédit.

En vue de préparer la re-conception de cette base, un stagiaire a effectué le rescencement des DF de ce schéma.Voici le résultat de ses travaux, sous la forme de la fermeture transitive des DF :♦ NumClient→ Nom, Prenom

♦ NumCompte→ NumClient, Nom, Prenom, Agence, Ville, Pays, Monnaie

♦ Agence→ Ville, Pays, Monnaie

♦ Pays→ Monnaie

♦ DateOperation, NumCompte→ MontantOperation

Question1.1En quelle forme normale est le schéma de la base existante ? Justifier.

Question1.2Trouvez la meilleure clé primaire pour ce schéma. Justifier.

Question1.3Afin de préparer la décomposition du schéma relationnel, trouvez une couverture minimale des DFE pertinente.

Question1.4Décomposer le schéma relationnel de la base existante, en préservant les DF, pour aboutir à un schéma en 3NF.Choisissez la meilleure clé primaire pour chaque relation. Présentez le schéma relationnel resultant et justifiez.

Question1.5A des fins de documentation, retro-concevez le MCD, à l'aide du formalisme E-A, qui aurait permis d'aboutirdirectement à ce schéma relationnel.

Enoncé n°2Une équipe technique est désignée afin de réaliser la nouvelle base de données que vous avez préconisée sous Oracle. Unefois le schéma relationnel créé, elle fait appel à vous pour récupérer les données existantes.

Question2.1Ecrivez une série d'instructions SQL permettant la récupération des données depuis l'ancienne base de données versla nouvelle.

Enoncé n°3L'équipe technique ne connaissant pas Access, elle fait appel à vous pour traduire les requêtes qui existaient dans l'anciensystème. On s'attache en particulier à la requête QBE suivante :

IMG. 65 : REQUÊTE RTOTALPARPERSONNEETPARMONNAIE

Vous avez accès à son équivalent SQL grâce au générateur automatique de SQL de Access :

SELECT TBank.NumClient, TBank.Monnaie, Sum(TBank.MontantOperation) AS SommeDeMontantOperationFROM TBankGROUP BY TBank.NumClient, TBank.Monnaie;

Question3.1En SQL (fonctionnant sous Oracle), créez une vue équivalente à cette requête QBE.

Enoncé n°4L'équipe technique fait à présent appel à vous pour certains aspects particuliers de l'application.Notez la table suivante qui a été ajoutée au schéma relationnel :


CREATE TABLE TDeficit (NumCompte number(10));

Question4.1Ecrivez un trigger qui, lorsque l'on insère une opération de débit qui conduit à un solde négatif du compte, insère lenuméro du compte dans la table "TDeficit".

Question4.2Ecrivez une méthode booléenne Java qui prend en paramètre d'entrée un numéro de client et renvoie vrai si ce clienta déjà été en déficit. On notera que la base se nomme "bank", qu'elle est accédée par la méthode sur la machine"www.oracle.bank.com" (port "1521"), par l'utilisateur "Java" (mot de passe "Tango").

Enoncé n°5L'équipe informatique fait maintenant appel à vous pour fiabiliser la base de données, à présent utilisée. Un problèmerécurrent survient sur la procédure PL/SQL "pVirement" donnée ci-dessous. En effet suite à des micro-coupures réseau, ilarrive que le débit du "Compte1" soit effectué, tandis que le crédit du "Compte2" n'est jamais effectué.

CREATE procedure pVirement (Compte1 number, Compte2 number, Montant number, DateOp date)ISBEGIN

INSERT INTO TOperation VALUES (Compte1, DateOp, Montant * -1);INSERT INTO TOperation VALUES (Compte2, DateOp, Montant);

END;

Question5.1Expliquez pourquoi le problème survient. Proposer une solution générale au problème. Implémentez cette solutionen réécrivant la procédure PL/SQL.

Enoncé n°6L'équipe informatique fait enfin appel à vous pour optimiser la base, et en particulier la requête suivante qui, étant donné unnombre d'opérations très grand existant, est trop longue à s'exécuter.

SELECT NumCompte, MontantOperationFROM TOperationWHERE MontantOperation > 10000;ORDER BY MontantOperation;

Question6.1Expliquez pourquoi cette requête sera longue à s'exécuter si le nombre d'enregistrements est très grand dans la tableTOperation. Proposer une solution générale au problème. Proposer une définition SQL implémentant cette solutionpour ce cas particulier.

Gestion de comptes bancaires 223

Cours

XIIAnnexes

Dans cette rubrique on retrouvera des éléments de contenus qui ne figurent pas au programme du cours mais pourrontnéanmoins servir à l'étudiant, à des fins d'approfondissement et dans le cadre du projet.

Partie A. Technologie MySQL

Objectifs pédagogiquesDécouvrir un SGBDR libre et répandu dans le monde InternetSavoir utiliser un SGBDR avec une interface SQL standardConnaître les éléments techniques de base pour apprendre à créer une BD sous MySQLSavoir manipuler un dictionnaire de données

MySQL est un SGBDR du monde "open source" (licence libre GPL et licence commerciale). Il propose une implémentation,lacunaire dans ses premières version, mais assez complète depuis la version 4, des concepts relationnels. MySQL est facile àinstaller et à administrer, performant, facilement interfaçable avec des couches applicatives Web. En particulier la plupart deshébergeurs, y compris gratuits, proposent la mise à disposition d'une BD MySQL et d'un serveur PHP.MySQL constitue donc à la fois un bon cadre d'apprentissage par son interface SQL standard et une technologie aisémentdéployable en conditions réelles pour des applications Internet ou Intranet.

Section A1. Généralités

1. Présentation♦ MySQL est un SGBDR.

♦ Unix, Linux, Windows.

♦ Licence GPL (et licence commerciale).

♦ Version de production MySQL 4 en 2004.

♦ Site officiel :

MySQL compte plusieurs millions d'applications dans le monde en 2003.(Dubois & al., 2004)

2. Notions d'achitecture client-serveurFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

2.1. Présentation de l'architecture d'un système client/serveurDe nombreuses applications fonctionnent selon un environnement client/serveur, cela signifie que des machines clientes (desmachines faisant partie du réseau) contactent un serveur, une machine généralement très puissante en terme de capacitésd'entrée-sortie, qui leur fournit des services. Ces services sont des programmes fournissant des données telles que l'heure, desfichiers, une connexion, ...Les services sont exploités par des programmes, appelés programmes clients, s'exécutant sur les machines clientes. On parleainsi de client FTP, client de messagerie, ..., lorsque l'on désigne un programme, tournant sur une machine cliente, capable detraiter des informations qu'il récupère auprès du serveur (dans le cas du client FTP il s'agit de fichiers, tandis que pour leclient messagerie il s'agit de courrier électronique).Dans un environnement purement Client/serveur, les ordinateurs du réseau (les clients) ne peuvent voir que le serveur, c'estun des principaux atouts de ce modèle.

2.2. Avantages de l'architecture client/serveurLe modèle client/serveur est particulièrement recommandé pour des réseaux nécessitant un grand niveau de fiabilité, sesprincipaux atouts sont :♦ des ressources centralisées

étant donné que le serveur est au centre du réseau, il peut gérer des ressources communes à tous les utilisateurs, commepar exemple une base de données centralisée, afin d'éviter les problèmes de redondance et de contradiction

♦ une meilleure sécurité

car le nombre de points d'entrée permettant l'accès aux données est moins important

♦ une administration au niveau serveur

les clients ayant peu d'importance dans ce modèle, ils ont moins besoin d'être administrés

♦ un réseau évolutif

grâce à cette architecture ont peu supprimer ou rajouter des clients sans perturber le fonctionnement du réseau et sansmodifications majeures

2.3. Inconvénients du modèle client/serveurL'architecture client/serveur a tout de même quelques lacunes parmi lesquelles :♦ un coût élevé

dû à la technicité du serveur

♦ un maillon faible

le serveur est le seul maillon faible du réseau client/serveur, étant donné que tout le réseau est architecturé autour de lui!Heureusement, le serveur a une grande tolérance aux pannes (notamment grâce au système RAID)

2.4. Fonctionnement d'un système client/serveur

IMG. 66 : SCHÉMA DE FONCTIONNEMENT D'UN SYSTÈME CLIENT/SERVEUR

Un système client/serveur fonctionne selon le schéma suivant:♦ Le client émet une requête vers le serveur grâce à son adresse et le port, qui désigne un service particulier du serveur

♦ Le serveur reçoit la demande et répond à l'aide de l'adresse de la machine client et son port


Section A2. Gestion de MySQL

1. Instructions spécifiques

1.1. Administration♦ USE Nom_Base

♦ SHOW DATABASES

♦ SHOW VARIABLES

♦ SHOW STATUS

♦ PASSWORD(chaîne)

1.2. Conception♦ SHOW TABLES

♦ DESCRIBE Nom_Table

♦ DESCRIBE Nom_Table Nom_Champs

1.3. Divers♦ SELECT DATABASE()

♦ SELECT USER()

2. Gestion des droitsLa métabase mysql sert à gérer les droits.

♦ user

Droits de connection d'un utilisateur (nom, hôte, mot de passe) et privilèges sur toutes les bases de données du serveur.

♦ db

Droits d'un utilisateur sur une base de données.

♦ tables_priv

Droits d'un utilisateur sur une table d'une base de données.

♦ columns_priv

Droits d'un utilisateur sur une propriété d'une table d'une base de données.

Remarque : Priorité des droitsPour déterminer si un droit existe, une relation OU est appliquée entre les niveau de droit. Donc des droits générauxne peuvent pas être diminués à un niveau plus fin.

Remarque : hostTable "host" sans fonction (ancien usage)

Annexes 227

Section A3. Spécificités MySQL

1. Types de données♦ INT (TINY, SMALL, MEDIUM, BIG)

♦ FLOAT, DOUBLE, DECIMAL, etc.

♦ DATE, DATETIME, TIME, YEAR, etc.

♦ CHAR, VARCHAR

♦ TEXT, BLOB

♦ ENUM, SET

2. BLOB♦ load_file("c:/chemin_fichier/nom_fichier")

3. Fonctions à connaître

3.1. Structure de contrôle♦ IF(Expr1, Expr2, Expr3)

♦ IFNULL(Expr1, Expr2)

♦ CASE value WHEN [compare_value] THEN result [WHEN [compare_value] THEN result ...] [ELSE result] END

♦ CASE WHEN [condition] THEN result [WHEN [condition] THEN result ...] [ELSE result] END

3.2. Fonctions numériques♦ RAND()

♦ LEAST(X, Y, ...), GREATEST(X, Y, ...)

♦ TRUNCATE(X,d)

3.3. Fonctions de traitement de chaînes♦ CONCAT

♦ LENGTH

♦ POSITION

♦ LEFT, RIGTH, SUBSTRING

♦ TRIM, REPLACE, UCASE, LCASE

3.4. Fonctions de traitement de dates♦ DAYOFWEEK(date), DAYOFMONTH(date), DAYOFYEAR(date), MONTH(date), WEEK (date)

♦ DAYNAME(date), MONTHNAME(date)

♦ HOUR(date), MINUTE(date), SECOND(date)

♦ ADDDATE, SUBDATE

♦ DATE_FORMAT


4. Les tables InnoDBTable InnoDBLes tables InnoDB, disponibles en standard depuis la version 4 de MySQL, permettent des traitements plus avancés(d'un point de vue des fonctions classiques proposées par les SGBDR) que les tables traditionnelles (ditesMyISAM) de MySQL.En particulier les tables InnoDB permettent :♦ La gestion des transactions (avec les instructions COMMIT et ROLLBACK)

♦ La reprise après panne grâce à une journalisation des transactions.

♦ La gestion de clés étrangères avec contrôle d'intégrité référentielle, suppressions et mises à jour en cascade.

Syntaxe : Créer des tables InnoDBCREATE TABLE nom_table (...) TYPE = InnoDB

Remarque : Conversion en tables InnoDBPour convertir une table existante en table InnoDB utiliser l'instruction ALTER TABLE suivante.

ALTER TABLE nom_table TYPE = InnoDB

Utilisation des tables InnoDBDans le cas général il est conseillé d'avoir recours aux tables InnoDB plutôt que MyISAM.

Des considérations techniques plus pousées (notamment d'optimisation) peuvent amener à contredire ce choix.

Section A4. Extension MySQL

1. Limites de MySQL♦ Sous requêtes

En général, on peut s'en passer. Prévu dans les versions à venir.

♦ Transactions

Alternative avec LOCK TABLE/UNLOCK TABLE.

Depuis MySQL 4, les tables de type InnoDB permettent la gestion réelle de transactions avec "commit" et "rollback" etrécupération de pannes.

♦ Procédures stockées

A venir.

♦ Triggers

Non prévu.

♦ Clé étrangères

Ni contrôle d'intégrité référentielle, ni mise à jour en cascade.

Depuis MySQL 4, les tables de type InnoDB permettent une gestion réelle de clés étrangères avec contrôle d'intégritéréférentielle et mises à jour et supressions en cascade.

♦ Vues

A venir.

Annexes 229

2. MySQL Control CenterClient graphique pour faciliter la mise au point des BD MySQL :♦ LDD

Création, maintenance de schéma de BD

♦ LCD

Création, suppression d'utilisateurs, gestion de leurs droits

♦ LMD

Exécution de requêtes SQL, insertion, suppression, modification directe d'enregistrements

♦ Gestion du serveur (connections, process, variables, etc.)

IMG. 67 : GESTION DES SCHÉMAS RELATIONNELS (LDD)

IMG. 68 : GESTION DES UTILISATEURS ET DES DROITS (LCD)


IMG. 69 : INTERFACE D'ÉXÉCUTION DE REQUÊTE (LMD QUESTIONS)

IMG. 70 : INTERFACE D'INSERTION DIRECTS D'ENREGISTREMENT (LMD AJOUT, MISE À JOUR, SUPPRESSIONS)

3. Questions sur plusieurs BDIl est possible avec MySQL de poser des question sur plusieurs BD. Il suffit pour cela de préfixer le nom des tables dans laclause FROM par le nom des BD.

Exemple : Question multi-BDmysql> show databases;+----------+| Database+----------+| mysql| test+----------+

mysql> select test.pays.n, mysql.user.user from test.pays, mysql.user;+------+--------+| n | user |+------+--------+| 1 | root| 2 | root| 1 | invite| 2 | invite+------+--------+

Section A5. Pratique de MySQL

Exercice n°24. Dictionnaire de donnéesLe dictionnaire de données du SGBD MySQL s'appelle "mysql".L'instruction "connect mysql; show tables;" renvoie le résultat suivant :

+-----------------+| Tables_in_mysql+-----------------+| columns_priv| db| func| host| tables_priv| user+-----------------+6 rows in set (0.00 sec)

Toutes ces tables sont vides, à l'exeption de la table user qui contient un enregistrement autorisant l'utilisateur "root" à seconnecter depuis une machine locale avec tous les droits.

L'utilisateur root tape l'instruction suivante :

Annexes 231

grant select on mysql.* to invite@localhost identified by "invite";

Question1Quelles sont les tables du dictionnaire de données modifiées par cette instruction ? Expliquez en quelques mots.

Question2Quelle(s) table(s) contiennent une ou plusieurs valeurs 'Y' pour l'utilisateur invite, une valeur 'Y' signifiant quel'utilisateur a des droits ? Expliquez en quelques mots.

Question3Pour chaque table, combien de colonnes sont-elles concernées par la valeur 'Y' pour l'utilisateur invite ? Expliquezen quelques mots.

Question4Réécrivez l'instruction grant en intervenant directement dans les tables en SQL.

Section A6. MySQL et PHP

1. Interfaçage avec MySQLFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.

1.1. Connection au serveurmysql_connect($host,$user,$passwd) or die("erreur de connexion au serveur $host");

1.2. Connection à la base de donnéesmysql_select_db($bdd) or die("erreur de connexion a la base de donnees");

1.3. Exécution de requête SQL$result=mysql_db_query($query)

1.4. Traitement de résultat de requête SELECT

1.4.1. Récupération d'enregistrement (FETCH) (1)while($row = mysql_fetch_row($result)) {

... $row[1] ... $row[2] ...}

1.4.2. Récupération d'enregistrement (FETCH) (2)while($row = mysql_fetch_row($result)) {

foreach ($row as $field) {... $field ...

}}

1.4.3. Test d'exécution de la requêteif (! mysql_fetch_row($result)) {

echo "Aucun enregistrement ne correspond\n";}else {... traitement ...}

1.5. Déconnection de la base de donnéesmysql_close();

2. Architecture PHP/MySQLFait à partir de . Copyright 2003 Jean-François Pillou. Document soumis à la licence GNU FDL.


IMG. 71 : EXEMPLE D'ARCHITECTURE 3-TIERS : PHP/MYSQL

Section A7. Quelques questions/réponses sur MySQL

Question Réponse 1. Tables InnoDB

Qu'est ce qu'une table InnoDB ?

C'est une table qui utilise le moteur InnoDB.

Cela permet de gérer des transactions avec commit, rollback, et restauration apres crash. Au niveau verouillage cemoteur gere le verouillage de lignes. Il ajoute le support des clés etrangeres.Le précedent moteur etait MyIsam, qui utilisait un fichier par table. Pour InnoDB, le moteur stocke les tables dansun tablespace reparti sur plusieurs fichiers. (cela permet de s'affranchir sur certains systeme de la limite de2go/fichier).Il y a un site dédié : www.innodb.com/

Exemple : Gestion de clés étrangèresCREATE TABLE parent(id INT NOT NULL,

PRIMARY KEY (id)) TYPE=INNODB;

CREATE TABLE child(id INT, parent_id INT,INDEX par_ind (parent_id),FOREIGN KEY (parent_id) REFERENCES parent(id)

ON DELETE CASCADE) TYPE=INNODB;

Exercice récapitulatif XV. Gestion de projets dans une association

Objectifs pédagogiquesExpérimenter le langage SQLUtiliser basiquement MySQL

Consigne

Pour chaque exécution de code SQL, il vous est demandé de produire le code entré et le résultat obtenu.

Annexes 233

Enoncé n°1Soit le schéma relationnel d'une base de données pour le gestion des projets dans une association :

Projet (Num, Nom, Debut, Fin, ChefDeProjet=>Membre, Specialite=>Specialite)Tache (Num, Projet=>Projet, Nom, Debut, Fin)Specialite (Intitule)Membre (Prenom, Nom, Specialite=>Specialite)Partenaire (Nom, Description)Participe (Prenom=>Membre, Tache=>Tache, Projet=>Tache, Fonction)EstAssocie (Nom=>Partenaire, Projet=>Projet, Role)

Question1.1Ecrivez le schéma E-A ayant permis de déduire ce modèle relationnel.

Enoncé n°2Pour faire fonctionner MySQL, il faut un serveur et un client. Pour lancer le serveur le programme est "mysqld" et pourlancer le client le programme est "mysql".L'option "mysqld --standalone" permet de lancer un serveur dans un process autonome.Pour connaître les options exécutable sur le client "mysql" exécuter : "mysql -h"."mysql -user utilisateur -pmotdepasse -D basededonnées" permet de se connecter en tant qu'utilisateur "utilisateur" avec lemot de passe "motdepasse" sur la base de données "basededonnées".Pour se connecter à une base de données exécuter "connect basededonnées".Pour créer une base de données, utiliser l'instruction "create database".Utiliser la commande "show databases" pour voir toutes les bases existantes et "show tables" pour voir les tables d'une basede données.

Question2.1Lancer un serveur et un client mysql, connectez vous.

Question2.2Initialiser une nouvelle base de données "Projetxx", avec xx votre numéro de binôme.

Enoncé n°3Par défaut, à l'installation de MySQL, n'importe qui peut se connecter en "root", sans mot de passe. Inutile de préciser que,l'utilisateur root ayant tous les droits, cela est la plus mauvaise situation possible du point de vue de la sécurité !Pour mettre en place la sécurité dans le SGBD MySQL, il faut au minimum :♦ Affecter un mot de passe à l'utilisateur "root" qui sera administrateur du SGBD. Ce mot de passe devra être complexe, car

toute personne le possédant à tout pouvoir de nuisance sur toutes les bases de données.

♦ Faire en sorte que les autres utilisateurs aient uniquement des droits sur les bases de données applicatives et non sur labase "mysql" qui spécifie tous les droits au sein du SGBD.

Les droits sont spécifiés dans la base "mysql" et sont ainsi organisés :♦ Les droits généraux sur toutes les bases de données sont spécifiés dans la table "mysql.user"

♦ Les droits sur chaque base de données sont spécifiés dans la table "mysql.db"

Il est possible de définir tous les droits en travaillant directement dans la base mysql. On peut également faire appel à descommandes plus spécialisée.Ainsi par exemple :♦ La commande "grant all privileges on db.* to 'user' identified by 'motdepasse' with grant option" permet de donner tous

les privilèges à l'utilisateur "user" sur la base de données "db" y compris le droit de donner les droits, de redéfinir le motde passe de l'utilisateur, et même, si l'utilisateur n'existait pas, de le créer.

♦ La commande "show grants for user" permet de voir les privilèges d'un utilisateur.

♦ La commande "set password for user=password('pass')" permet d'affecter le mot de passe "pass" à l'utilisateur "user". Lacommande "set password for user=''" permet de supprimer le mot de passe de l'utilisateur "user".

♦ La suppression d'un utilisateur se fait en supprimant l'enregistrement dans la table "mysql.user" et éventuellement dans lesautres tables de la base mysql pour les droits particuliers.

♦ La commande "flush privileges" permet de rendre actifs les changement effectués concernant les droits.

Question3.1En travaillant directement dans les tables de la base mysql et/ou en utilisant les commandes spécialisées, organisezla sécurité du SGBD de façon à ce que :♦ L'utilisateur "root" ait à présent le mot de passe "nx17"

♦ Les accès ne puissent se faire que depuis le "localhost"

♦ Un utilisateur "nx170xx" (avec xx votre numéro) ait le mot de passe "u" et l'accès complet à la base Projetxx


♦ Un utilisateur "invite" (sans mot de passe) ait les droits en lecture seul sur la base Projetxx

♦ Aucun n'autre accès ne soit autorisé sur la base

Travailler à présent avec l'utilisateur "nx170xx" sur la base "Projetxx".

Enoncé n°4A présent que le SGBD est correctement protégé et que la base de données est disponible pour créer l'application, il s'agitd'implémenter le shéma de la base de données de gestion de projet.Pour se faire, on utilisera MySQL en mode "batch", c'est à dire que plutôt que de taper chaque commande en ligne, on utiliseun fichier, qui contient plusieurs commandes qui seront ensuite exécutées d'une seule traite. L'avantage du mode batch estqu'il permet de refaire plusieurs fois une même séquence d'opérations SQL.L'instruction "mysql -u nx17000 -pu -D Projet00 < c:\mysql\create.sql -t > c:\mysql\out.txt" permet d'exécuter le fichier"create.sql" en mode batch, sur la base de données "Projet00", par l'utilisateur "nx17000" (ayant le mot de passe "u") ; lerésultat est mis dans le fichier "out.txt" ; le paramètre optionnel "-t" signifie que la mise en forme est tabulaire (avec noms etséparateurs de colonnes) ; bien entendu, il est possible de ne pas spécifier de fichier de sortie, auquel cas le résultat estprésenté à l'écran.

Question4.1Créer les relations nécessaires pour implémenter le modèle relationnel.

Question4.2Définissez les contraintes (clé primaires, nullité et unicité) et des domaines pertinents pour chaque propriété. Notezque MySQL ne gère pas les contraintes de clés étrangères (et donc pas l'intégrité référentielle).

Question4.3Définissez des index pertinents.

Enoncé n°5On dispose des informations suivantes :♦ L'association gère pour le moment trois projets, "Comédie Musicale" gérée par Nathalie sur les trois premiers mois du

semestre d'automne 2002, "Science en fête" gérée par Pierre sur tout le semestre de printemps 2003. et "Nuit du picolo"gérée par Julien en novembre 2002.

♦ Les specialités ressencées pour le moment sont : Ville, Université, Sport, Entreprise, Culture, International.

♦ L'association dispose de dix membres, que je vous laisse libre d'imaginer (sans oublier les chefs de projet déjà investis !).

♦ Aidez l'association à diviser ses projets en tâches.

♦ Les partenaires existants sont : la mairie pour la comédie musicale et la science en fête, qui apporte un soutien financier ;le ministère de la culture qui apporte son soutien logistique à la science en fête ; l'association des commerçants de la villequi apporte son soutien publicitaire à la comédie musicale ; 1664 qui offre ses bières à moitié prix pour la nuit du picolo.

Question5.1Initialiser les relations.

Enoncé n°6On reporte à présent les évènements suivants :♦ 1664 n'apporte plus son soutien suite au refus des étudiants de faire de la publicité pour la bière dans les lycées de la ville.

♦ Le projet de comédie musicale est renommé projet "Chance aux chansons" suite à une décision unilatérale du chef deprojet (par ailleurs président de l'association et fils du ministre de l'intérieur).

♦ Le projet "Chance aux chansons" et reporté d'un an suite à la démission du chef de projet (pour cause d'incompatibilitéd'humeur avec le reste des membres).

On pourra utiliser l'instruction "describe nom_table" pour revoir les schémas des tables créées.il est possible de faire des opération sur les dates, avec des fonctions telles que "DATE_ADD(date, INTERVAL valeurtype)". Par exemple : "select DATE_ADD('2001-01-01', INTERVAL 1 DAY)" renvoie "2001-01-02".

Question6.1Gérer ces évènements en procédant aux mises à jour nécessaires dans la base de données

Enoncé n°7L'association désire à présent exploiter sa base de données pour obtenir les informations suivantes :

Annexes 235

♦ La liste de tous les projets avec les noms des projets, les chefs de projet et tous les membres participants. Cette requêteest-elle exécutable par un utilisateur "invite" ? Si oui assurez vous-en.

♦ Une liste mettant en correspondance tous les chefs de projet qui n'ont pas la spécialité requise pour un projet.

♦ Une liste de tous les partenaires, avec les projets soutenus et leur rôle dans chaque projet.

♦ Le nombre de tâches en retard pour chaque projet.

♦ Les chefs de projet qui sont en relation avec au moins deux partenaires.

Question7.1Créer et exécuter les requêtes permettant de répondre à ces questions.

Partie B. Exercices complémentaires

Section B1. Modélisation

Exercice n°25. Une agence immobilièreUne agence immobilière voudrait créer une base de données pour la gestion des biens immobiliers mis à sa disposition etpour l'exploitation statistique et/ou fiscale des informations accumulées. Pour chaque logement on possède plusieursinformations : l'adresse, le nom du propriétaire, le type (maison/appartement), le nombre de pièces constituant, superficiehabitable, l'état d'habitation (neuf, bon état, très bon état, mauvais état), prix de mise en vente, la date de disponibilité, laville. Chaque propriété peut avoir un ou plusieurs garages. Ces derniers sont caractérisés par le type (box, emplacementnumérotés, etc.) et dans certain cas peuvent avoir des adresses différentes de celle de la propriété. Un logement peut êtrevendu ou acheté par une personne caractérisée par son nom et son adresse de contact. Pour chaque transaction de vente,l'agence touche une commission qui correspond à un pourcentage du prix de vente (qui est composé d'une valeur fixe de 1000euros à laquelle on additionne entre 3 et 5% en fonction de la négociation). L'agence organise et gère également les visitesdes propriétés que les acheteurs potentiels (clients) pourraient réclamer. Pour des besoins d'exploitation fiscale, l'agencesouhaite garder la trace du montant total de chaque transaction de vente effectuée (prix de vente) ainsi que de la somme descommissions.

Question1Proposez un modèle conceptuel permettant de répondre à ce problème.

Section B2. Relationnel

Exercice n°26. Le chemin des écoliersSoit le schéma relationnel suivant :

IMMEUBLE (ADI, NBETAGES, DATEC, PROP)APPIM (ADI, NAPR, OCCUP, TYPE, SUPER, ETAGE)PERSONNE (NOM, AGE, PROF, ADR, NAPR)ÉCOLE (NOMEC, ADEC, NBCLASSES, DIR)CLASSE (NOMEC, NCL, MAITRE, NBEL)ENFANT (NOMP, PRENOM, AN, NOMEC, NCL)

Avec la signification suivante :♦ Relation IMMEUBLE

ADI : adresse d'immeuble, clé; on fait l'hypothèse pour simplifier, que l'adresse identifie de manière unique un immeuble

NBETAGES : nombre d'étages d'un immeuble

DATEC : date de construction (année)

PROP : nom du propriétaire de l'immeuble qui est une personne

♦ Relation APPIM (Appartement)

ADI : adresse d'immeuble

NAPR : numéro d'appartement

OCCUP : occupant de l'appartement (nom de la personne ayant signé le contrat de location, éventuellement aucun)

TYPE : type de l'appartement (Studio, F2, ...)


SUPER : superficie de l'appartement

ETAGE : étage où se situe l'appartement

♦ Relation PERSONNE

NOM : nom de personne, clé; on fait l'hypothèse pour simplifier, que ce nom est unique sur l'ensemble des personnes quel'on considère dans la base

AGE : âge de la personne

PROF : profession de la personne

ADR : adresse de la résidence d'une personne, il s'agit d'un immeuble


♦ Relation ÉCOLE

NOMEC : nom d'une école, clé

ADEC : adresse d'une école

NBCLASSES : nombre de classes

DIR : nom du directeur

♦ Relation CLASSE

NOMEC : nom d'une école

NCL : nom de la classe, e.g., CP1, CE2, CE3, etc...

MAITRE : nom de l'instituteur

NBEL : nombre d'élèves dans la classe

♦ Relation ENFANT

NOMP : nom de la personne responsable de l'enfant, clé e.g., père, mère etc...

PRENOM : prénom de l'enfant

AN : année de naissance


NCL : nom de la classe

La relation IMMEUBLE décrit un ensemble d'immeubles. Chaque immeuble a un propriétaire. La relation APPIM décritpour chaque immeuble l'ensemble des appartements qui le compose. Chaque appartement peut héberger plusieurs personnesmais il y en a une qui est responsable (par exemple la personne qui a signe le contrat de location) et qui est désignée par leconstituant OCCUP. Si l'appartement est inoccupé, ce constituant prend la valeur NULL. La relation PERSONNE décrit unensemble de personnes. ADR et NAPR représentent l'adresse où réside une personne. Une personne peut avoir plusieursenfants décrits par la relation ENFANT. Pour simplifier, on ne considère que les enfants allant à l'école primaire. Les écoleset les classes sont décrites dans les relations ÉCOLE et CLASSE.

Question1Identifier les clés étrangères dans chaque relation.

Question2Retro-conception : reconstruire le schéma E/A.

Exercice n°27. Le retour des écoliersSoit le schéma relationnel suivant :

IMMEUBLE (ADI, NBETAGES, DATEC, PROP)APPIM (ADI, NAPR, OCCUP, TYPE, SUPER, ETAGE)PERSONNE (NOM, AGE, PROF, ADR, NAPR)ÉCOLE (NOMEC, ADEC, NBCLASSES, DIR)CLASSE (NOMEC, NCL, MAITRE, NBEL)ENFANT (NOMP, PRENOM, AN, NOMEC, NCL)

Avec la signification suivante :♦ Relation IMMEUBLE

ADI : adresse d'immeuble, clé; on fait l'hypothèse pour simplifier, que l'adresse identifie de manière unique un immeuble

NBETAGES : nombre d'étages d'un immeuble

Annexes 237

DATEC : date de construction (année)

PROP : nom du propriétaire de l'immeuble qui est une personne

♦ Relation APPIM (Appartement)

ADI : adresse d'immeuble


OCCUP : occupant de l'appartement (nom de la personne ayant signé le contrat de location, éventuellement aucun)

TYPE : type de l'appartement (Studio, F2, ...)

SUPER : superficie de l'appartement

ETAGE : étage où se situe l'appartement

♦ Relation PERSONNE

NOM : nom de personne, clé; on fait l'hypothèse pour simplifier, que ce nom est unique sur l'ensemble des personnes quel'on considère dans la base

AGE : âge de la personne

PROF : profession de la personne

ADR : adresse de la résidence d'une personne, il s'agit d'un immeuble


♦ Relation ÉCOLE

NOMEC : nom d'une école, clé

ADEC : adresse d'une école

NBCLASSES : nombre de classes

DIR : nom du directeur

♦ Relation CLASSE


NCL : nom de la classe, e.g., CP1, CE2, CE3, etc...

MAITRE : nom de l'instituteur

NBEL : nombre d'élèves dans la classe

♦ Relation ENFANT

NOMP : nom de la personne responsable de l'enfant, clé e.g., père, mère etc...

PRENOM : prénom de l'enfant

AN : année de naissance


NCL : nom de la classe

La relation IMMEUBLE décrit un ensemble d'immeubles. Chaque immeuble a un propriétaire. La relation APPIM décritpour chaque immeuble l'ensemble des appartements qui le compose. Chaque appartement peut héberger plusieurs personnesmais il y en a une qui est responsable (par exemple la personne qui a signe le contrat de location) et qui est désignée par leconstituant OCCUP. Si l'appartement est inoccupé, ce constituant prend la valeur NULL. La relation PERSONNE décrit unensemble de personnes. ADR et NAPR représentent l'adresse où réside une personne. Une personne peut avoir plusieursenfants décrits par la relation ENFANT. Pour simplifier, on ne considère que les enfants allant à l'école primaire. Les écoleset les classes sont décrites dans les relations ÉCOLE et CLASSE.Répondez aux questions suivantes à l'aide de l'algèbre relationnelle.

Question1Donner l'adresse des immeubles ayant plus de 10 étages et construits avant 1970.

Question2Donner les noms des personnes qui habitent dans un immeuble dont ils sont propriétaires.

Question3Donner les noms des personnes qui ne sont pas propriétaires.


Question4Donner les adresses des immeubles possédés par des informaticiens dont l'âge est inférieur à 40 ans .

Question5Donner la liste des occupants (nom, âge, profession) des immeubles possédés par DUPONT.

Question6Donner le nom et la profession des propriétaires d'immeubles dans lesquels il y a des appartements vides.

Question7Donner les noms des maîtres qui habitent dans le même immeuble (à la même adresse) qu'au moins un de leursélèves (on suppose que les enfants vivent sous le même toit que leur parents).

Question8Donner l'adresse de l'immeuble, la date de construction, le type d'appartement et l'étage où habitent chacun desmaîtres des enfants de DUPONT.

Exercice n°28. Gestion du personnelSoit les deux relations EMP et DEPT suivantes :Relation des Employés (EMP) :

EMP (ENO, ENOM, PROF, DATEEMB, SAL, COMM, DNO)

♦ ENO : numéro d'employé, clé

♦ ENOM : nom de l'employé

♦ PROF : profession (directeur n'est pas une profession)

♦ DATEEMB : date d'embauche

♦ SAL : salaire

♦ COMM : commission (un employé peut ne pas avoir de commission)

♦ DNO : numéro de département auquel appartient l'employé

Relation des Départements (DEPT) :

DEPT (DNO, DNOM, DIR, VILLE)

♦ DNO : numéro de département, clé

♦ DNOM : nom du département

♦ DIR : numéro d'employé du directeur du département

♦ VILLE : lieu du département (ville)

A l'aide de l'algèbre relationnelle exprimer les requêtes suivantes :

Question1Lister les employés ayant des revenus supérieurs à 10.000 euros.

Question2Trouver le nom et la profession de l'employé de numéro 10.

Question3Lister des noms des employés qui travaillent à Paris.

Question4Trouver le nom du directeur du département ''Commercial''.

Question5Trouver les professions des directeurs des départements.

Annexes 239

Question6Trouver le nom des directeurs de département ayant comme profession "Ingénieur".

Section B3. Nomalisation, SQL LDD et LCD

Exercice n°29. Avec modération

ConsigneRappelons qu'une question est généralement de la forme : SELECT ... FROM ... WHERE

ConsigneUne vue est un ensemble de relations déduites d'une BD, par composition des relations de base. Dans la normeSQL, la notion de vue à été réduite à la notion de relation déduite. La déclaration d'une vue s'effectue par lacommande : CREATE VIEW <nom de vue> [(liste d'attributs)] AS <question>La suppression d'une vue s'effectue par la requête : DROP <nom de vue>

Exercice inspiré de (Gardarin, 1999)Soit la BD VITICOLE composée des relations suivantes :

BUVEURS (NB, NOM, PRENOM, VILLE, AGE)VINS (NV,NOM, REGION, MILLESIME, DEGRE)ABUS (NB, NV, DATE, QUANTITE)

Question1Donnez les commandes SQL permettant de créer les vues suivantes décrivant les buveurs et les vins de Beaujolais :

♦ BUVEURB (NB, NOM, PRENOM, NV, DATE, QUANTITE)

♦ VINB (NV, CRU, MILLESIME, DEGRE)

Question2Un utilisateur ayant droit d'interroger à partir des vues précédentes pose la question suivant :

"donner le nom de buveurs ayant bu du Beaujolais de millésime 1983 en quantité supérieur à 100, le même jour".Exprimez cette question telle que doit le faire l'utilisateur en SQL.


Bibliographie

ABBEY M, COREZ M, ABRAMSON I, "Oracle 9i : Notions fondamentales", CampusPress, Paris, 2001.

CELKO J, "SQL avancé : Programmation et techniques avancées.", Vuibert, 2000.

"ACM Transactions on Database systems", CHEN P, . "The entity-Relationsheep Model - Towards a Unified View of Data".mars 1976, n°.1.

"Communications de l'ACM", CODD E, . "A relational model for large shared data banks". juin 1970, n°.6, pp.377-387.


DUBOIS P, HINZ S, PEDERSEN C, "MySQL : Guide officiel", 702 pages, CampuPress, Paris, 2004.

FORD A, "Apache précis et concis", 125 pages, Précis et concis, pages, O'REILLY, France, 2000.

FOUCAULT O, THIÉRY O, KAMEL S, "Conception des systèmes d'information et programmation événementielle : de l'étapeconceptuelle à l'étape d'implantation.", ?, 1996.

GARDARIN G, "Bases de données : objet et relationnel", Eyrolles, 1999.

LERDOF R, "PHP précis et concis", 133 pages, Précis et concis, pages, O'REILLY, France, 2002.

LIMING C, "Conception de bases de données", UTC, 1997.

MATA-TOLEDO R, CUSHMAN P, "Programmation SQL", Ediscience, 2003.

MATHIEU P, "Des bases de données à l'internet", Vuibert, 2000.

MOJERON J, "Principes et conception d'une base de données relationnelle", Les éditions d'organisation, 1992.

MULLER P, "Modélisation objet avec UML", Eyrolles, Paris, 1998.

NACE D, "Conception de bases de données", UTC, 2002.

PRATT P, "Initiation à SQL : Cours et exercices corrigés", Collection Noire, pages, Eyrolles, 2001.

ROQUES P, VALLÉE F, "UML 2 en action : De l'analyse des besoins à la conception J2EE", 385 pages, architecte logiciel, pages,Eyrolles, Paris, 2004.

SOUTOU C, "De UML à SQL : Conception de bases de données", Eyrolles, 2002.

TARDIEU H, ROCHFELD A, COLLETI R, "Méthode MERISE Tome 1 : Principes et outils", Les Editions d'Organisation, Paris,1983.

TARDIEU H, ROCHFELD A, COLLETI R, PANET G, VAHEE G, "Méthode MERISE Tome 2 : Démarche et pratiques", LesEditions d'Organisation, Paris, 1985.

THIBAUD C, "My SQL 4 : Installation, mise en oeuvre et programmation", Collection Ressources Informatiques, pages, EditionsENI, 2003.

WONG C, "HTTP précis et concis", 77 pages, Précis et concis, pages, O'REILLY, France, 2000.

"http://access.developpez.com/", Les meilleurs cours, tutoriels et docs sur Access, WWW.DEVELOPPEZ.COM , décembre, 2003.

"http://access.developpez.com/faq/", Access FAQ, WWW.DEVELOPPEZ.COM , décembre, 2003.

"http://cedric.cnam.fr/vertigo/Cours/BD-B/", SGBD Valeur B7 1/2 UV 19786, CNAM , 2002.

"http://developpeur.journaldunet.com/dossiers/alg_uml.shtml", UML en 5 étapes, MORLON J, avril, 2004.

"http://developpeur.journaldunet.com/tutoriel/cpt/031013cpt_uml5conseils.shtml", Cinq petits conseils pour un schéma UMLefficace, BORDERIE X, avril, 2004.

"http://eric.univ-lyon2.fr/~jdarmont/docs/sise-bd-ex_rel.pdf", Exercices - Modèle Relationnel, DARMONT J, janvier, 2004.

"http://eric.univ-lyon2.fr/~jdarmont/docs/sise-bd-ex_uml.pdf", Exercices - Modèle UML, DARMONT J, janvier, 2004.

"http://eric.univ-lyon2.fr/~jdarmont/docs/sise-bd-exam0203.pdf", Examen de bases de données, DARMONT J, janvier, 2004.

"http://eric.univ-lyon2.fr/~jdarmont/docs/sise-bd-exam0203.pdf", Examen de bases de données, DARMONT J, janvier, 2004.

"http://eric.univ-lyon2.fr/~jdarmont/docs/sise-bd-td1.pdf", TD1 : Oracle SQL, DARMONT J, janvier, 2004.

"http://eric.univ-lyon2.fr/~jdarmont/docs/sise-bd-td1isea.pdf", Relationnel-objet, Relationnel étendu, DARMONT J, janvier, 2004.

"http://eric.univ-lyon2.fr/~jdarmont/docs/sise-bd-td2.pdf", TD2 : Oracle SQL, DARMONT J, janvier, 2004.

"http://eric.univ-lyon2.fr/~jdarmont/docs/sise-bd-td2isea.pdf", TD2 : SQL Dynamique, DARMONT J, janvier, 2004.

"http://eric.univ-lyon2.fr/~jdarmont/docs/sise-bd-td34.pdf", TD3/4 : Oracle SQL, DARMONT J, janvier, 2004.

"http://eric.univ-lyon2.fr/~jdarmont/tutoriel-sql/", Comprendre les jointures dans Access, HUBICHE M, avril, 2004.

"http://eric.univ-lyon2.fr/~jdarmont/tutoriel-sql/", Tutoriel SQL, DARMONT J, janvier, 2004.

"http://inforge.unil.ch/Hec1/H02/02c_AccessIntroduction.ppt", Introduction à Access, BENDAHAN S, MONZANI J, décembre,2003.

"http://penarvir.univ-brest.fr/%7Eead/CDL/ORACLE/oracle-node3_mn.html", Accélération des performances et organisationphysique, RIBAUD V, janvier, 2004.

"http://solutions.journaldunet.com/0402/040210_postgresql.shtml", MySQL ou PostgreSQL ? Des arguments pour comprendre,CROCHET-DAMAIS A, février, 2004.

"http://solutions.journaldunet.com/0404/040401_base.shtml", Bases de données : SGBDR, XML, Open Source, le tour de l'offre,CROCHET-DAMAIS A, avril, 2004.

"http://ugweb.cs.ualberta.ca/~c391/manual/title.html", Computing Science 291/391 : Laboratory Manual, UNIVERSITY OFALBERTA , janvier, 2004.

"http://www.bd.enst.fr/~dombd/polyv7/chap0.htm", Systèmes de Gestion de Bases de Données, CHEINEY J, PICQUET P,SAGLIO J, avril, 2004.

"http://www.developpez.com/sgbd/access/sql.htm", SQL Access, ALEXANDRE LE GRAND , décembre, 2003.

"http://www.docsdunet.com/doc_sgb.html", Bases de données, sytèmes de gestion de bases de données, janvier, 2004.

"http://www.eudil.fr/~ocaron/enseignement/", Enseignement Polytech'Lille : Introduction aux bases de données et Cours SGBDavancés, CARON O, janvier, 2004.

"http://www.info.uqam.ca/~godin/DiaposParChap/ChapI-5.ppt", Introduction au modèle relationnel, GODIN R, avril, 2004.

"http://www.loria.fr/~roegel/cours/iut/oracle-plsql.pdf", Le langage procédural PL/SQL, ROEGEL D, janvier, 2004.

"http://www.loria.fr/~roegel/cours/iut/oracle-sql.pdf", Oracle : SQL, ROEGEL D, janvier, 2004.

"http://www.sybase.com/products/enterprisemodeling", Sybase PowerDesigner, septembre, 2002.

"http://www.w3architect.com/static/people/fgaillard/these/04-LesSGBDO.html", Les bases de données objet, GAILLARD F,février, 2004.

"http://www-db.stanford.edu/~ullman/fcdb/oracle.html", Notes on the Oracle DBMS, STANFORD UNIVERSITY , janvier, 2004.

"http://www-inf.int-evry.fr/COURS/BD/BD_REL/SUPPORT/poly.html#RTFToC30", Contrôle des accès concurrents et reprise,DEFUDE B, janvier, 2004.

"http://www-inf.int-evry.fr/COURS/BD/DOC_ORACLE/myplsql.html", PL/SQL, DEFUDE B, janvier, 2004.

"http://wwwlsi.supelec.fr/www/yb/poly_bd/tdm.html", BD et SGBD : Table des Matières, BOURDA Y, janvier, 2004.

"uml.free.fr", UML en Français, septembre, 2002.

"www.objecteering.com", Objecteering software, septembre, 2002.


Glossaire

API

Une API est une définition d'un ensemble de fonctions ou méthodes (en programmation objet) dont l'appel paramétré permetde piloter une application. Une API permet donc d'utiliser un librairie informatique sans avoir besoin d'en connaître lefonctionnement interne.

Client

Un client est un programme informatique qui a pour fonction d'envoyer des requêtes à un autre programme informatique,appelé serveur, d'attendre le résultat de cette requête et de traiter le résultats de la requête. Notons qu'un programme peut-êtreclient vis à vis d'un programme et serveur vis à vis d'un autre. On ne prend pas ici le terme client dans son acceptionmatérielle, qui signifie alors un ordinateur qui a pour fonction d'héberger des programmes clients.

Constructeur d'objet

En programmation orientée objet, un constructeur d'objet est une méthode particulière d'une classe qui permet d'instancier unobjet de cette classe. L'appel à cette méthode de classe a donc pour conséquence la création d'un nouvel objet de cette classe.

Exception

Une exception est un évènement généré par un système informatique pour signifier une erreur d'exécution. La gestion desexceptions est un aspect de la programmation informatique, qui consiste à intercepter ces évènements particuliers et à lestraiter pour, soit les corriger automatiquement, soit en donner une information appropriée à un utilisateur humain.

Impedance mismatch

Le terme d'impedance mismatch renvoie au décalage qui peut exister entre le niveau d'abstraction de deux langages qui ont àtravailler sur des structures de données communes, par exemple un langage applicatif objet et un langage de donnéesrelationnel. L'impedance mismatch a des conséquences négatives en terme de complexification de l'implémentation et enterme de performance, puisqu'il faut constamment passer d'une strucuture de données à l'autre.

RAID

La techologie RAID pemet de répartir de l'information à stocker sur plusieurs "petits" disques, au lieu de la concentrer sur unseul "gros" disque. Cette technologie permet donc d'améliorer les performances (les accès disques pouvant être parallélisés)et d'améliorer la sureté (en répartissant les risques de crash et en jouant sur une redondance des données). Il existe plusieurstypes d'architecture RAID, privilégiant ou combinant la parallélisation et la redondance.

Serveur

Un serveur est un programme informatique qui a pour fonction de recevoir des requêtes d'un autre programme, appelé client,de traiter ces requêtes et de renvoyer en retour une réponse. Notons qu'un programme peut-être serveur vis à vis d'unprogramme et client vis à vis d'un autre. On ne prend pas ici le terme serveur dans son acception matérielle, qui signifie alorsun ordinateur qui a pour fonction d'héberger des programmes serveurs.


Signification des sigles

1NF Première Forme Normale

2NF Deuxième Forme Normale

3NF Troisième Forme Normale

4NF Quatrième Forme Normale

5NF Cinquième Forme Normale

ACID Atomique, Cohérent, Isolé, Durable

API Application Program Interface

BCNF Forme Normale de Boyce-Codd

BD Base de Données

DF Dépendance Fonctionnelle

DFE Dépendance Fonctionnelle Elémentaire

E-A Entité-Association

E-R Entity-Relationship

FIFO First In First Out

IHM Interface Homme Machine

JDBC Java DataBase Connectivity

LCD Langage de Contrôle de Données

LDD Langage de Définition de Données

LMD Langage de Manipulation de Données

MCD Modèle Conceptuel de Données

MLD Modèle Logique de Données

ODBC Open DataBase Connectivity

OID Object Identifier

OMG Object Management Group

QBE Query By Example

RAID Redundant Array of Independant Disks

RO Relationnel-Objet

SGBD Système de Gestion de Bases de Données

SGBDOO Système de Gestion de Bases de Données Orientées Objets

SGBDR Système de Gestion de Bases de Données Relationnelles

SGBDRO Système de Gestion de Bases de Données Relationnelles-Objets

SGF Système de Gestion de Fichiers

SI Système d'Information

SQL Structured Query Language

UML Unified Modeling Language

VBA Visual Basic for Application

Index

1:N p. 173

1NF p. 103, 169, 170

2NF p. 103

3NF p. 104, 105

3-tier p. 198, 200

Abstraite p. 42

Acces p. 137

Access p. 119, 119, 119, 120, 121, 125, 127, 129, 130, 131,132, 221

ACID p. 136

Administration p. 22, 26

Agrégat p. 89, 89, 163

Algèbre p. 54, 75, 75, 75, 76, 76, 77, 77, 78, 78, 79, 79, 80, 81

ALL p. 91

ALTER TABLE p. 110, 111

Analyse p. 28, 28, 29, 29

AND p. 87

Annulation p. 136

ANY p. 92

API p. 209

Application p. 121, 126, 127, 131, 132, 154, 154, 154, 166, 197

Architecture p. 197, 197, 198, 200, 200, 208, 216, 225, 232

Armstrong p. 99, 100

Association p. 32, 43, 45, 46, 57, 57, 61, 67, 68, 68, 173, 174

Association 1:1 p. 61, 67

Atomicité p. 103

Attente p. 144

Attribut p. 34, 41, 45, 55, 55, 56, 59, 62, 68, 68

Attribut composite p. 173

Attribut dérivé p. 161, 173

Attribut multi-valué p. 173

AutoExec p. 128

BCNF p. 105

BD p. , 21, 21, 21, 21

BETWEEN p. 87

BLOB p. 177

Boolean p. 177

Boucle p. 204

Calcul p. 89

Cardinalité p. 33, 44

Cartésien p. 77

Catalogue p. 26

Chaîne de caractères p. 129

CHECK p. 109

Classe p. 23, 40, 42, 48, 48, 50, 66, 68, 170, 204

Clé p. 34, 56, 59, 102, 152

Clé artificielle p. 56

Clé étrangère p. 171, 173, 179

Clé primaire p. 56, 221

Client p. 197, 198, 200, 216, 225

Client-serveur p. 197

Cluster p. 194

Codd p. 53

Cohérence p. 135, 136, 136, 141

Collection p. 170, 173, 174, 178, 179

COMMIT p. 137, 140

Comparaison p. 87

Composition p. 46, 68


Conception p. , 21, 21, 23, 28, 28, 48, 50, 81, 98

Conceptuel p. , 24, 24, 27, 28, 28, 29, 31, 31, 31, 39, 40, 51, 60,65, 66, 74, 81, 221

Concurrence p. 135, 135, 141, 144, 147, 148

Condition p. 87

Constructeur p. 178

Contrainte p. 122, 178

Contraintes p. 73, 161

Contrôle p. 22, 112

Couverture minimale p. 221

CREATE INDEX p. 192

CREATE TABLE p. 108, 161, 178

CREATE TYPE p. 177, 178

CREATE VIEW p. 110

Création p. 107

Critique p. 120

CurrentDb p. 129, 130

Curseur p. 129, 129, 130, 130, 157, 159, 163

CURSOR p. 159, 163

DBMS_OUTPUT p. 158, 163

Déclaratif p. 107

Déclencheur p. 156, 159, 159, 160, 161

Décomposition p. 98, 102

Défaillance p. 135

DELETE p. 93, 124, 162

Dénormalisation p. 193, 194

Dépendance p. 97

Déverrouillage p. 143

DF p. 99, 99, 100, 100, 101, 101, 101, 102, 221

Diagramme p. 39, 48, 48, 50

Dictionnaire p. 26, 154, 161, 164

Différence p. 75

DISTINCT p. 86

Index 249

Division p. 79

Domaine p. 54, 54, 54, 107, 122, 151

Données p. 23

Driver p. 209

Droits p. 112

DROP p. 110

Durabilité p. 138

E-A p. 24, 28, 29, 31, 31, 31, 31, 32, 33, 34, 34, 36, 43, 44,51, 53, 60, 60, 61, 62, 62, 63, 64, 65, 66, 74, 75, 81, 221

Ecriture p. 143

Enregistrement p. 55, 55

Entité p. 31, 34, 34, 60, 173

Enumération p. 122

Erreur p. 158

Etat p. 154, 154, 163, 164

Evaluation p. 192

EXCEPT p. 88

Exception p. 158, 159, 163, 164

Exécution p. 136

EXISTS p. 91

Extension p. 167, 177, 189

Externe p. 24, 27, 78

Fermeture p. 101

Fiabilité p. 135, 148

Fonction p. 89, 129, 129, 153, 156, 156, 162, 164, 177, 204

Fonctions p. 165

FOR p. 158

FOREIGN KEY p. 109

FORM p. 201

Forme normale p. 221

Formulaire p. 126, 126, 201, 213

Formulaires p. 125

FROM p. 86


FUNCTION p. 177

Gestion d'erreur p. 130

GRANT p. 112

GROUP BY p. 89, 124

Groupement p. 194

HAVING p. 89, 124

Héritage p. 34, 41, 42, 63, 64, 68, 70, 70, 71, 72, 73, 172, 174

HTML p. 201, 202, 202, 204, 205, 213, 213

HTTP p. 200

IF p. 158, 162, 203

IN p. 87, 90

Index p. 192, 195, 221

INNER p. 87

INSERT p. 92, 124, 162

INSERT INTO p. 178, 180

Instance p. 23, 24

Intégrité référentielle p. 122

Inter-blocage p. 144, 145

Interne p. 24, 27

INTERSECT p. 88

Intersection p. 75

INTO p. 157

IOD p. 180

IS NULL p. 87

Java p. 208, 209, 209, 210, 210, 211, 211, 212, 212, 215,216, 221

JavPHPa p. 204

JBDC p. 208, 209, 209, 210, 211, 212

JOIN p. 87

Jointure p. 77, 78, 78

Jointure externe p. 163

Journal p. 138, 138, 140

Langage p. 22, 25, 85, 85, 86, 97, 107, 155, 155, 157, 157, 157,

Index 251

164, 197, 208

Langage de programmation p. 129

LCD p. 25, 107, 112, 130

LDD p. 25, 107, 107, 121, 122, 123, 130, 172

Lecture p. 143

LEFT p. 87

Lien p. 57, 57

LIKE p. 87

Liste déroulante p. 126

LMD p. 25, 86, 107, 123, 124, 152, 152, 165

Logique p. , 22, 24, 27, 31, 53, 53, 53, 53, 60, 65, 66, 74, 75,81, 87, 97, 167, 221

Macro p. 127, 128, 128, 128

Manipulation p. 75

MERISE p. 29, 31, 31

Méthode p. 170, 173, 173, 178, 179

Modèle p. , 23, 24, 27, 31, 31, 31, 48, 53, 53, 53, 59, 60, 75,81, 97, 167, 169, 187, 221

MySQL p. 209, 225, 232, 232

N:M p. 174

Naturelle p. 78

NESTED TABLE p. 178, 179

Nomalisation p. 97

Normalisation p. 97, 97, 98, 99, 99, 100, 100, 101, 101, 101, 102,102, 103, 103, 104, 105, 168, 193

NOT p. 87

NOT NULL p. 109

OBDC p. 208

Objet p. 129, 167, 168, 172, 172, 174, 177, 178, 204

Occurence p. 23

OID p. 172, 183, 187

OMG p. 40

On Error p. 130

Opérateur p. 87


Opération p. 54

Optimisation p. 22, 97, 191, 192, 195, 196

OR p. 87

Oracle p. 137, 146, 146, 147, 147, 151, 151, 166, 205, 206,208, 209, 210, 211, 211, 212, 215, 216, 221

ORDER BY p. 89

OUTER p. 87

Panne p. 138, 138, 138, 139, 139, 147, 221

Partitionnement p. 194, 195

Passage p. 60, 62, 65, 66, 74

Performance p. 192, 221

Perte p. 141

PHP p. 202, 202, 203, 203, 203, 204, 204, 204, 205, 205,206, 208, 212, 232, 232

Physique p. 22, 24, 27

PL/SQL p. 137, 151, 180, 211, 212, 216, 221

Point de contrôle p. 138, 139, 139

PRIMARY KEY p. 109

Problème p. 98

Procédure p. 156, 156, 163, 164

Produit p. 54, 54, 77

Programme p. 129, 209

Projection p. 76, 194

Propriété p. 34, 41, 45

Prototypage p. 120

QBE p. 123, 124, 124

QueryDef p. 129, 130, 130

Question p. 80, 81, 86, 123

Recordset p. 129, 129, 130, 130

Redondance p. 22, 97, 98, 193

Référence p. 171, 172

REFERENCES p. 109

Relation p. 54, 55, 55, 56, 57, 57, 59, 59

Index 253

Relationnel

p. 21, 24, 31, 53, 53, 53, 53, 54, 54, 59, 60, 60, 60, 61,62, 62, 63, 64, 65, 66, 66, 66, 67, 68, 68, 68, 68, 70, 70,71, 72, 73, 73, 74, 74, 75, 75, 75, 79, 80, 81, 83, 97, 105,167, 168

Relationnel-objet p. 53, 53, 167, 169, 177, 181, 183, 187, 189

REPEAT p. 158

Requête p. 80, 86, 123, 123, 129, 130, 130

Restriction p. 76, 194

REVOKE p. 113

RIGHT p. 87

ROLLBACK p. 137, 138, 145

Schéma p. , 23, 24, 27, 51, 59, 60, 172, 191

Script p. 164

Sécurité p. 22, 130

SELECT p. 86, 87, 87, 123, 157, 179

Séquence p. 161, 162

Serveur p. 197, 198, 200, 200, 202, 212, 216, 225

Servlet p. 213, 213, 213, 213, 214, 215, 216

Servlets p. 212

SGBD p. , 21, 21, 21, 21, 22, 24

SGBDOO p. 168

SGBDRO p. 169, 177, 181, 183, 187

SGBR p. 22

Sous-requêtes p. 90, 90, 91, 91, 92

Spécifications p. 29

SQL p. 25, 80, 85, 85, 86, 93, 97, 107, 107, 107, 112, 114,137, 146, 146, 151, 177, 221

Statement p. 210

Table p. 107, 121, 122

TABLE p. 179

Table imbriquée p. 169, 171, 178, 179

Tables imbriquées p. 174

Transaction p. 22, 136, 137, 137, 146, 146, 147, 147, 148

Transactions p. 135, 221


Tri p. 89

Trigger p. 221

TRIGGER p. 159, 159, 160, 161

Tuple p. 55

type p. 157

Type p. 23, 107, 170, 170, 172, 172, 173, 173, 174, 177, 178

Types p. 122

UMLp. 24, 28, 39, 40, 40, 41, 41, 42, 45, 46, 48, 48, 48, 50,

51, 65, 66, 66, 67, 68, 68, 68, 68, 70, 70, 71, 72, 73, 73,74, 187

UNDO-REDO p. 139

Union p. 75

UNION p. 88

UNIQUE p. 109

Unité p. 136, 136, 138, 139

UPDATE p. 92, 124

Utilisateur p. 112

Validation p. 136

Variables p. 203

VBA p. 129, 129, 129, 129, 129, 130, 130, 130, 130, 137

Verrou p. 143, 143, 144, 144, 145

Vue p. 123, 195, 221

Vue matérialisée p. 195

Web p. 200, 200

WHERE p. 86, 87, 87

WHILE p. 158

Index 255

Fiche de synthèse

Vue d'ensemble

En quoi une base de données est-elle plus intéressante qu'un système de fichier classique ?.

.

.

.

.

Quelles sont les fonctions remplies par un SGBD ?.

.

.

.

.

Notions généralesPourquoi est-ce que l'on distingue trois niveaux de modélisation lors de la conception d'une basede données ?.....

Quelles est la différence entres le schéma conceptuel et le ou les schémas externes ?.

.

.

.

.

Quelles sont les fonctions d'un langage orienté données ?.

.

.

.

.

A quoi et à qui sert un dictionnaire de données ?.

.

.

.

.

Les méthodes de conception de bases de données

Pourquoi est-il fondamental mais difficile de parvenir à un MCD correct ?.

.

.

.

.

Enoncer quelques actions à mener pour réaliser une spécification générale de l'existant et desbesoins ?.....

Qu'est ce qui différencie fondamentalement un MCD d'un MLD ?.

.

.

.

.

Le modèle E-A

Enoncer les principaux éléments composants le modèle E-A ?.

.

.

.

.

Quels sont les avantages apportés par l'extension du modèle E-A ?.

.

.

.

.

Que permet d'exprimer une entité de type faible ?.

.

.

.

.

Les diagrammes de classes UML

Quels sont les principaux éléments du diagramme de classes UML ?.

.

.

.

.

Quelles sont les différences et points communs entre la diagramme de classe UML et le modèleE-A étendu ?.....


Description du modèle relationnel

Qu'est ce qu'un domaine ?.

.

.

.

.

Quel rapport y-a-t il entre une relation et une table ?.

.

.

.

.

Comment identifie-t-on un attribut d'une relation ?.

.

.

.

.

Comment identifie-t-on un enregistrement d'une relation ?.

.

.

.

.

Quelle problème pose la redondance et comment le résoudre ?.

.

.

.

.

Le passage E-A vers RelationnelLe passage E-A ou UML vers relationnel est-il systématique ou soumis à interprétation ?Pourrait-il être réalisé par un algorithme ?.....

Est ce que l'un des deux modèles conceptuels, E-A ou UML, est plus adapté au passage aurelationnel ?.....

Pourquoi dispose-t-on de trois méthodes pour traduire l'héritage dans un modèle relationnel ?Ces trois méthodes sont-elles équivalentes ?.....

Fiche de synthèse 259

Le passage UML vers RelationnelLe passage UML vers relationnel est-il systématique ou soumis à interprétation ? Pourrait-il êtreréalisé par un algorithme ?.....

Pourquoi dispose-t-on de trois méthodes pour traduire l'héritage dans un modèle relationnel ?Ces trois méthodes sont-elles équivalentes ?.....

Algèbre relationnelleQuels sont les opérateurs algébriques de base ? Quels sont les autres opérateurs ? Qu'est ce quiles différencie ?.....

Quels sont les opérateurs ensemblistes ? Qu'est ce qui les caractérise ?.

.

.

.

.

Pourquoi la jointure est-elle un opérateur essentiel ?.

.

.

.

.

Qu'est ce qui différencie une jointure externe d'une jointure classique ?.

.

.

.

.

Le LMD de SQL

A quoi sert le LMD ?.

.

.

.

.

Quel rapport y-a-t il entre le SQL et l'algèbre relationnelle ?.

.

.

.

.


Pourquoi SQL n'est-il pas un langage de programmation ?.

.

.

.

.

Théorie de la normalisation relationnelle

En quoi peut-on dire que certains schémas relationnels sont mauvais ?.

.

.

.

.

Pourquoi est-il primordial de repérer les dépendances fonctionnelles sur un schéma relationnel ?.

.

.

.

.

Comment repère-t-on ces dépendances fonctionnelles ?.

.

.

.

.

Que sont les axiomes d'Armstrong et à quoi servent-ils ?.

.

.

.

.

Qu'est ce que la décomposition d'une relation ?.

.

.

.

.

Pourquoi le respect de la première forme normale reste-t-il en partie subjectif ?.

.

.

.

.

Quelle forme normale est généralement souhaitable pour un schéma relationnel ?.

.

.

.

.


Le LDD de SQL

A quoi sert le LDD ?.

.

.

.

.

En quoi le LDD est il un langage déclaratif ?.

.

.

.

.

Quel rapport y-a-t il entre le LDD et le concept de relation ?.

.

.

.

.

Le LCD de SQL

Quels types de droits peuvent être accordés ou révoqués en SQL ?.

.

.

.

.

Pourquoi peut-on dire que la gestion des droits est décentralisée en SQL ?.

.

.

.

.

Généralités

Citez un bon et un mauvais cas d'usage d'Access..

.

.

.

.

Expliquer pourquoi Access est à la fois un SGBDR et un outil de création d'application. Est-ceque des précautions particulières doivent-être prises à ce propos ?.....

Création de schéma relationnelAccess peut-il être considéré comme un "vrai" SGBDR du point de vue de la création du schémarelationnel ? Pourquoi ?.....


Expliquer pourquoi les objets "requête" d'Access sont en fait des vues ?.

.

.

.

.

Le langage de requêtes QBEAccess peut-il être considéré comme un "vrai" SGBD du point de vue de l'interrogation desdonnées ? Pourquoi ?.....

Qu'est ce que QBE par rapport à SQL ? Quels sont ses avantages et inconvénients ?.

.

.

.

.

Formulaires

A quoi servent les formulaires ?.

.

.

.

.

Quelle est la différence entre un formulaire lié et un formulaire indépendant ?.

.

.

.

.

Quel type de formulaire faut-il préférer en général et pourquoi ?.

.

.

.

.

Macro

A quoi servent les macros ?.

.

.

.

.

Faut-il préférer l'usage des macros ou bien de code plus bas niveau ?.

.

.

.

.


Modules

A quoi servent le code VBA ?.

.

.

.

.

VBA peut-il être assimilé à un "vrai" langage de programmation ?.

.

.

.

.

VBA est-il complète-t-il ou bien remplace-t-il SQL lors de la réalisation d'application ?.

.

.

.

.

Que peut-on faire avec un langage comme VBA que l'on ne peut pas faire en SQL en terme demanipulation de données ?.....

Transactions

Pourquoi une transaction est-elle atomique ?.

.

.

.

.

Pourquoi une transaction est-elle cohérente ?.

.

.

.

.

Pourquoi une transaction est-elle isolée ?.

.

.

.

.

Pourquoi une transaction est-elle durable ?.

.

.

.

.


Fiabilité

A quoi sert le journal des transactions ?.

.

.

.

.

Qu'est ce qu'un point de contrôle ?.

.

.

.

.

L'aglorithme de reprise UNDO-REDO terminera-t-il toutes les transactions qui étaientcommencées au moment de la panne ?.....

ConcurrenceLaquelle des propriétés ACID des transactions est-elle particulièrement utile pour gérer les accèsconcurrents ?.....

Le verrouillage est-il une solution parfaite pour la gestion de la concurrence ?.

.

.

.

.

Illustrations sous OraclePourquoi peut-on dire que les transactions sont les unité logique de travail, les unités d'intégrité,les unités de reprise et les unités de concurrence ?.....

SQL

A quoi servent les séquences sous Oracle ?.

.

.

.

.

Citer quelques fonctions essentielles propres à Oracle ?.

.

.

.

.


A quoi sert un dictionnaire de données ?.

.

.

.

.

SQL*Plus

L'environnement SQL*Plus fournit-il des instructions pour accéder à la BD ?.

.

.

.

.

Pourquoi le paramétrage de la présentation des résultats de requête est-il utile ?.

.

.

.

.

PL/SQLUn langage procédural est-il toujours utile à la réalisation d'une application d'exploitation d'uneBD ?.....

A quoi sert un curseur ?.

.

.

.

.

A quoi sert un trigger ? Donnez un exemple pertinent d'usage de trigger..

.

.

.

.

Exemple

Un trigger permet-il d'améliorer le contrôle des données ?.

.

.

.

.

Oracle, avec les langages SQL, SQL*Plus et PL/SQL est-il, à votre avis, suffisant pour laréalisation d'une application complète de base de données ?.....


Introduction : R, OO, RO

Quels sont les atouts du modèle relationnel-objet par rapport au modèle relationnel ?.

.

.

.

.

Le modèle relationnel-objetQuels sont les extensions les plus importantes apportés par le modèle relationnel-objet aumodèle relationnel ?.....

En quoi le modèle relationnel-objet peut-il être considéré comme plus proche que le modèlerelationnel du modèle conceptuel ?.....

Mapping E-A vers relationnel-objetEn quoi le mapping E-A vers relationnel-objet est-il plus fidèle que le mapping E-A versrelationnel ?.....

Dans quel cas l'utilisation de collections peut-il être destructeur de sémantique ?.

.

.

.

.

En quoi l'implémentation de l'héritage en relationnel-objet simplifie-t-il le mapping ? En quoi ne lesimplifie-t-il pas ?.....

SQL3 (implémentation Oracle 9i)Qu'apporte les OID par rapport aux clés étrangères classiquement manipulées dans le modèlerelationnel ?.....

Quelles solutions de modélisation apporte les instructions de création de type sous Oracle ?.

.

.

.

.


ExemplesL'utilisation d'OID pour les références est-elle préférable à l'utilisation de clés étrangèresclassique, en particulier dans le cas où la clé étrangère est composée ?.....

Introduction à l'optimisation des BD

Citer des paramètres propres à une BD que l'on doit surveiller dans le cadre de la performance ?.

.

.

.

.

Peut-on anticiper sur des problèmes de performance futurs lors de la conception d'une BD ?.

.

.

.

.

Pourquoi n'indexe-t-on pas tous les champs d'une BD ?.

.

.

.

.

Quels problèmes pose la dénormalisation ?.

.

.

.

.

Quels problèmes pose le clustering ?.

.

.

.

.

Quels problèmes pose le partionnement ?.

.

.

.

.

Quels problèmes pose les vues concrètes ?.

.

.

.

.


Architecture trois tiersQuelle sont les atouts d'une architecture 3-tier par rapport à une architecture client-serveurclassique ?.....

Qu'est ce qu'une architecture Web ?.

.

.

.

.

Rappels HTML

A quoi sert un formulaire en HTML ?.

.

.

.

.

Introduction à PHP

Comment se situe PHP dans une architecture Web ?.

.

.

.

.

Pourquoi un langage comme PHP s'est-il développé ces dernières années à votre avis ?.

.

.

.

.

Quels inconvénients peut-on trouver à un langage comme PHP ?.

.

.

.

.

PHP et BD

A quoi sert une API PHP d'accès à une base de données ?.

.

.

.

.

Java et BD (JDBC)Pourquoi un langage comme Java est-il appelé à être mobilisé dans le cadre de la conception deBD ?.....


Quelle est la fonction d'une API JBDC ?.

.

.

.

.

Introduction aux servlets

A quoi sert une servlet ?.

.

.

.

.

Quelle est la différence entre une servlet et une applet ?.

.

.

.

.

Quelle sont les avantages des servlets par rapport à un langage comme PHP ?.

.

.

.

.

Quelle sont les inconvénients des servlets par rapport à un langage comme PHP ?.

.

.

.

.

Servlets et BDPuisque Java et PL/SQL sont tous deux des langages de programmation applicatifs, quel estl'intérêt de combiner Java et PL/SQL ?.....

MySQL et PHP

A quoi sert une API PHP d'accès à une base de données ?.

.

.

.

.
